© 2004 benet devereux lecture #4 ocl and scr/parnas tables

© 2004 Benet Devereux

Lecture #4

OCL and SCR/Parnas Tables


Preamble

● Previously we have discussed object constraints in an informal way– This is fine for elicitation dialogue– And for model inspection and walkthroughs

● More formality is needed for– Formal analysis– Automatic prototype building

● Programming languages are formal!– Why introduce an intermediate formal language?– Declarative specifications avoid implementation

bias


What, not How, Revisited

● Object model should describe the logic of domain activities, not algorithms

● It can be argued that skilled developers can abstract from descriptions in an imperative language– If a specification contains a call to sort(), it is

clearly understood that this stands for a declarative specification of sorting, which everyone understands

– For less familiar tasks, separating implementation from the purpose becomes harder, even with comments


Tools for Requirements Modeling

● In UML:– Object Constraint Language (OCL)– Statecharts

● Outside UML:– Parnas tables

● Implemented in Software Cost Reduction (SCR*) tool– Data-flow modeling (very old, but still used)

● Elements: processes and data-stores● Relations: data passes between elements

– Processes transform, stores simply record


Object Constraint Language

● Developed originally by IBM Insurance division– For modeling business logic in a formal but

readable way– Has roots in Syntropy method of Cook and

Daniels (1994)● Now part of UML 1.5 standard

– Syntax and semantics for other parts of UML are now defined using OCL


Characteristics of OCL

● Subset of typed first-order logic– Existential and universal quantification over

elements of container objects is allowed– .. and over all instances of a class

● Expressions are side-effect-free– No x++ > 10 allowed

● Typed– All expression and terms have type; classes form

a type hierarchy, allowing casting using oclAsType() function


What OCL Is For

● Specifying invariants on classes and types in the object model

● Describing preconditions, postconditions, and invariants for operations

● As a language for navigating through associations (similar to Xpath)


What OCL Isn't For

● Describing algorithms– Use the implementation language or

pseudocode● Specifying dynamic behaviour

– Use UML state-charts


OCL Types

● Basic types– Boolean, Integer, Real, String

● Note this is a specification language, so integers are of arbitrary magnitude, and reals are real and not floats!

● Integers are a subtype of Reals● Enumeration types

– OCL treats enumerations as Singleton classes with an attribute for each value

– Enumeration types appear in the object model, labeled with the <<enumeration>> stereotype


OCL Types, continued

● Parameterized container types– Let T be a type– Set(T), Sequence(T), Bag(T), Collection(T) are

types– All container types are subtypes of Collection(T)– Bag(T) is a multiset of type T

● Object types– Object type hierarchy follows class hierarchy– There is a superclass (what's it called) for all

objects


Expressions

● Valid– 1+2*34 -- type Integer, value 69– 'Foo'.concat('bar') – type String, value 'Foobar'– 12 + 17.5 – type Real (highest common

supertype)– 5 < 2 – type Boolean, value False– True or False – type Boolean, value True

● Invalid– 34 and True– 1 + 'motorcycle'– Color::green * 3


Contexts

● Every OCL statement requires a context● Class context:

– context class● Named class context

– Context c:class– Can refer to instance throughout statement

● Operation context– Context Class::operation (p1:Type, ..) :

ReturnType


Attribute Properties

● Class context:– context Company inv:– self.numberOfEmployees > 50– or– context c: Company inv:– c.numberOfEmployees > 50

● Invariants may be named:– context Company inv enoughEmployees– c.numberOfEmployees > 50

● All invariant expression are of Boolean type!


Operation Properties

● result refers to the returned value– context Circle::area():Real– pre: True– post: result = pi * (self.radius@pre * 2)^2

● Preconditions and postconditions may be given names– pre parametersOK: ...– post resultOK: ..

● Not clear yet why! – But may be useful in coping with inheritance


Recursion

● You may refer to operations recursively– context factorial(n: Integer):Integer

– pre: n >= 0– post: if (n == 0) then result=1 else result = n*factorial(n-1)

● This is, of course, hazardous..– Would be better to give the declarative definition,

but this requires set-comprehension not included in OCL

– Too much implementation bias!– Harder for stakeholders to read


Pre/Post Variables

● We may want to refer to both before and after versions of the object in a postcondition– After variables are unmarked– Before variables have '@pre' catenated to the

end● If attribute 'x' is an object..

– self.x@pre retrieves the object pointed to by x at the start of the operation

– [email protected] retrieves the after value of the attribute y of the object referred to by x at the start


Some Intuition on This..

● Consider a returnBook(b: Book) operation in a library system– A postcondition is that the book that was signed

out is now in state 'Returned'– This is the right idea, but of course we can just

refer to b!● .. or a fire() method for course instructors

– All courses previously taught by the instructor must still have an instructor when the fire() method finishes

– The details of the decision are left unspecified; but the necessity of the decision is encoded


Creation and Destruction

● Recall objects may be created or destroyed during an operation– Referring to the pre-value of an object created

during the operation is undefined– As is the post-value of a destroyed object– If an object x is created during an operation, x.oclIsNew() holds in the postcondition

● Sadly, no symmetric predicate for destroyed objects


Navigation Expressions

● Each association has a role-name– Course -> Teacher “instructor”– Teacher -> Course “coursesTaught”

● One-to-one association navigation is obvious– In the context of type Course, self.instructor retrieves the associated Teacher

● One-to-many / one-to-(zero or one)– Same syntax (self.coursesTaught)– .. but retrieves a Collection of the association

target type


Working with Collections

● Basic operations– size()– includes(x)– count(x) – how many times x appears– includesAll(c) – subset– sum() -- if type is integer or real– exists(expr)– forAll(expr)– select(expr) – subcollection that satisfies

expr● Syntactic sugar..

– isEmpty(), excludes(x)...


The Collect Expression

● Create a new collection by evaluating an expression over each member of a collection– self.teachingAssistants->collect(supervisor)

– Equivalently● self->teachingAssistants->collect(ta | ta.supervisor)

● self->teachingAssistants->collect(ta: gradStudent | ta.supervisor)

● Principally used to navigate associations, but is more general


SCR (Software Cost Reduction)

● Specify observable behaviour of system● Monitored variables (under environment

control) and controlled variables (under system control); including

● Based on Parnas tables– Note: not an object-oriented notation! Though

nothing prevents us from using it in an OO setting

– Treat each object as a subsystem: the sending of a message from A to B is a controlled variable of A, and a monitored one of A


Basic Concepts

● Types: Boolean, Integer, Enumerated (values must be specified)

● Discrete time model – values change instantly from one time step to the next

● A condition holds at one or more time steps; for instance, speed > 65

● An event spans two time steps; for instance, @T(buttonPressed) means that the value of Boolean buttonPressed goes from False to True


Mode Transition Tables

SourceMode

DestinationMode

Off @T(temp > max) ACOn

Off @T(temp < min) HeatOn

....

● Conditions for the same source mode must be disjoint– But not necessarily covering; if no event triggers

a mode transition, the mode stays the same


Event Tables

Controlled variable: Fan Mode class: Thermostat

Fan'= on off

Off

ACOn

HeatOn

NEVER NEVER

@T(ACOn) @F(timeOn < 10)

@T(HeatOn) @F(timeOn < 5)


Condition Tables

Controlled Variable: powerLED

Off

ACOn, HeatOn

on off

FALSE TRUE

TRUE FALSE


Domain Assertions

● Can be either state invariants (holding at every point in time) or transition invariants– State invariant: min < max (not allowed to set

minimum temperature above maximum temperature)

● Note this may still be a design obligation!– Transition invariant: !( (temp > max) && (temp' <

min))


Caveat

● Table notation allows formal analysis using SCR Toolset

● However, this depends on fixing the number of objects of each type!


The Story so Far

● Have started modeling requirements, not just eliciting

● Models have predictive power– Specify behaviour of objects– Can automatically check for erroneous behaviour– Check for inconsistencies in description, report

to stakeholders● Important: formal analysis != proof of

correctness!

© 2004 benet devereux lecture #4 ocl and scr/parnas tables

Documents