© 2004 Benet Devereux Lecture #4 OCL and SCR/Parnas Tables

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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)

© 2004 Benet Devereux What OCL Isn't For ● Describing algorithms – Use the implementation language or pseudocode ● Specifying dynamic behaviour – Use UML state-charts

© 2004 Benet Devereux 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 > stereotype

© 2004 Benet Devereux 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

© 2004 Benet Devereux Expressions ● Valid – 1+2*34 -- type Integer, value 69 – 'Foo'.concat('bar') – type String, value 'Foobar' – – 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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!

© 2004 Benet Devereux Operation Properties ● result refers to the returned value – context Circle::area():Real – pre: True – post: result = pi * * 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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 ' catenated to the end ● If attribute 'x' is an object.. – retrieves the object pointed to by x at the start of the operation – retrieves the after value of the attribute y of the object referred to by x at the start

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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)...

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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

© 2004 Benet Devereux 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 means that the value of Boolean buttonPressed goes from False to True

© 2004 Benet Devereux Mode Transition Tables Source Mode Destination Mode > max) ACOn < 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

© 2004 Benet Devereux Event Tables Controlled variable: Fan Mode class: Thermostat Fan'= on off Off ACOn HeatOn NEVER < 5)

© 2004 Benet Devereux Condition Tables Controlled Variable: powerLED Off ACOn, HeatOn on off FALSE TRUE FALSE

© 2004 Benet Devereux 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))

© 2004 Benet Devereux Caveat ● Table notation allows formal analysis using SCR Toolset ● However, this depends on fixing the number of objects of each type!

© 2004 Benet Devereux 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!