Upload
mitchell-howard
View
218
Download
0
Embed Size (px)
Citation preview
© 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 <<enumeration>> 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'– 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
© 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 * (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
© 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 '@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
© 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 instance, @T(buttonPressed) means that the value of Boolean buttonPressed goes from False to True
© 2004 Benet Devereux
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
© 2004 Benet Devereux
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)
© 2004 Benet Devereux
Condition Tables
Controlled Variable: powerLED
Off
ACOn, HeatOn
on off
FALSE TRUE
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!