450 likes | 625 Views
6/8/2012. Duminda Wijesekera. 2. Object Constraint Language. (OCL). 6/8/2012. Duminda Wijesekera. 3. Why OCL ?. UML is a pictorial language for software design, now becoming widely popular.Although popular UML by itself is not enough to capture many aspects of software design.This set of transpar
E N D
1. 6/8/2012 Duminda Wijesekera 1 SWE 623- Formal Methods
What we cover: OCL, formal specifications, program correctness, model checking.
Office Hrs: Tuesday 6.00 to 7.00 pm
Assignments: As posted o the web page
E-mail: dwijesek@gmu.edu
Class Web page:
http://www.ise.gmu.edu/~duminda/classes/fall02/swe623.html
2. 6/8/2012 Duminda Wijesekera 2 Object Constraint Language (OCL)
3. 6/8/2012 Duminda Wijesekera 3 Why OCL ? UML is a pictorial language for software design, now becoming widely popular.
Although popular UML by itself is not enough to capture many aspects of software design.
This set of transparencies review UML and introduce OCL.
Information on OCL available at http://www.klasse.nl/ocl/index.htm
Reference book: The Object Constraint Language –Precise Modeling with UML by Jos Warmer and Anneke Kleppe. (Addison Wesley Series on Object Technology)
4. 6/8/2012 Duminda Wijesekera 4 Review UML Use Case Diagrams
Class Diagrams
Statecharts
Sequence Diagrams
Object Collaboration Diagrams
5. 6/8/2012 Duminda Wijesekera 5
6. 6/8/2012 Duminda Wijesekera 6 Use Cases Define system functional requirements in terms of Actors and Use cases
Each use case defined in terms of sequence of interactions between Actor and System
Narrative description
Simple use cases may involve only one interaction
More complicated use cases may involve several interactions
7. 6/8/2012 Duminda Wijesekera 7
8. 6/8/2012 Duminda Wijesekera 8 Objects and Classes Objects represent “things” in real world
Provide understanding of real world
Form basis for a software solution
An Object is a single “thing”
E.g., John’s car
Mary’s account
A Class (object class) is a collection of objects with the same (similar) characteristics
E.g., account, employee, car, customer
An object is underlined in class diagrams
E.g., object:class or :class
Each object has an identity and is distinguishable from others in the class
9. 6/8/2012 Duminda Wijesekera 9
10. 6/8/2012 Duminda Wijesekera 10 An Example Class Diagram
11. 6/8/2012 Duminda Wijesekera 11 Statechart Statechart
Graphical representation of finite state machine
States are rounded boxes
Transitions are arcs
Statechart relates events and states
Event
Causes change of state
Referred to as state transition
State represents interval between successive events
Initial state
Arc with black ball at end
12. 6/8/2012 Duminda Wijesekera 12
13. 6/8/2012 Duminda Wijesekera 13
14. 6/8/2012 Duminda Wijesekera 14 Hierarchical Statecharts OR decomposition
When object is in superstate
It is in one and only one of substates
Transition into superstate
Must be to one and only one of substates
Aggregation of state transitions
If same event causes transition out of every substate
Then aggregate into transition out of superstate
15. 6/8/2012 Duminda Wijesekera 15 Hierarchical Statecharts Concurrent statecharts
State of an object described by more than one statechart
Show different aspects of object, may not be concurrent
AND decomposition
Object is in one substate on each statechart
Object’s state is union of all substates
Same event
May cause transitions on more than one statechart
Output event on one statechart
May be input event on other statechart
Substate on one statechart
May be condition on other statechart
16. 6/8/2012 Duminda Wijesekera 16 Sequence Diagram Shows sequence of object interactions in use case
Emphasis on messages passed between objects
Objects represented by vertical lines
Actor is on extreme left of page
Messages represented by labeled horizontal arrows
Only source and destination of arrow are relevant
Message is sent from sending object to receiving object
Time increases from top of page to bottom
Spacing between messages is not relevant
Message sequence numbering is optional
17. 6/8/2012 Duminda Wijesekera 17
18. 6/8/2012 Duminda Wijesekera 18
19. 6/8/2012 Duminda Wijesekera 19 Object Collaboration Diagrams Graphically depicts objects participating in a use case
Show objects as boxes
Show their message interactions as arrows
Number sequence of messages
Message
Message = Event + Attributes
E.g, ATM card inserted (Card id, expiration date)
Object Collaboration Diagram for each use case
Some objects only appear on one Object Collaboration Diagram
Some objects appear in several Object Collaboration Diagrams
20. 6/8/2012 Duminda Wijesekera 20
21. 6/8/2012 Duminda Wijesekera 21
22. 6/8/2012 Duminda Wijesekera 22 Object Constraint Language Developers claim: OCL is easier than Z, VDM.
Need some mathematical background in Set Theory and Logic, but is based on UML.
Constraints in OCL is an extension of Assertions of Bertrand Meyer, implemented in Eiffel.
Assertions = pre-conditions + post-conditions + invariants
Assertions (Graham) = above + conditions holding when methods are running.
23. 6/8/2012 Duminda Wijesekera 23 Other Notions of Constraints Rambaugh: Functional relationships between entities of the object model.
Restricts values that entities can take.
Booch: Expression of semantics conditions that must be preserved.
Only properties of steady states must be stated.
Design by Contract: Obligations of a client to a server
24. 6/8/2012 Duminda Wijesekera 24 Declarative vs. Operational Constraints Declarative: What must hold, not what should be done to enforce a constraint. Advantages:
Do not worry about enforcement or penalty for violation.
Implementation independent behavior.
Atomic checking of enforcement.
Operational: Doing what by a runtime system will enforce a constraint.
Breaking of a Constraint: Raise an exception
Exception to be raised can be determined by using some rules such as given in Soma (Ian Graham)
25. 6/8/2012 Duminda Wijesekera 25 Constraints of OCL Definition of a Constraint: A restriction on one or more value of (part of) an object oriented model.
Properties of OCL:
Expresses properties useful to modelers.
Precise syntax and semantics (modulo UML)
Declarative language
Typed languages
26. 6/8/2012 Duminda Wijesekera 26
27. 6/8/2012 Duminda Wijesekera 27 Constraints on Attribute Values Constraints on Attribute Values
customer
age >= 18
dob.isBefore($now)
28. 6/8/2012 Duminda Wijesekera 28 Constraints on Associations Can place constrains on attributes that are connected over associations
CustomerCard
PrintedName = customer.title.
concat(customer.name)
CustomerCard
PrintedName = owner.title.
concat(owner.name)
29. 6/8/2012 Duminda Wijesekera 29 Collections of Objects Not all associations are one-to-one. Hence, have to deal with sets of objects in some associations.
OCL has collection operations for this purpose.
notEmpty( set of objects ), notEmpty(set of objects )
includes(object) – for membership test
union( set of objects )
Intersection( set of objects )
sum( set of objects)
Iterate, exists, forAll, includesAll
30. 6/8/2012 Duminda Wijesekera 30 Iterations Over Collections Select, reject, iterate, forAll, exists.
CustomerCard
self.transactions->select(points > 100)
LoyaltyAccount
transaction->collect( points)
Transaction->collect( points) -> exists( p : Integer | p = 500 )
Self.customer->forAll( c: Customer | c.age() <= 90)
Notice the duality between select and reject:
self.transactions->select(points > 100)
self.transaction->reject(points =< 100)
31. 6/8/2012 Duminda Wijesekera 31 Iterate Construct Most General Construct.
ProgramPartner
self.service.transaction->iterate(
t : transaction;
result : integer = 0 |
if oclType = Burning then
result + points
else
result
endif )
32. 6/8/2012 Duminda Wijesekera 32 Pre Conditions, Post Condition and Invariants Two Options
Can use operations in constraints
Can write constraints about operations
Pre and Post Conditions:
@pre indicates value before method call
Pre: Post: used to indicate conditions
Example
LoyaltyProgram
pre: not customer->includes(c)
post: customer = customer@pre->including(c)
33. 6/8/2012 Duminda Wijesekera 33 Modeling Constraints Invariant
An expression holding true for all instances.
Precondition
Must be true at the start of execution of a method.
Postcondition
Must be true at the end of execution of a method.
UML has no way to denote pre and post conditions other than state them in note boxes.
OCL has a syntactic way to denote them.
34. 6/8/2012 Duminda Wijesekera 34 Statecharts and OCL State charts have states, actions, activities etc.
They are all constraints on the class diagrams of the corresponding object.
Hence all information of stat charts have to be translated to class diagrams.
35. 6/8/2012 Duminda Wijesekera 35
36. 6/8/2012 Duminda Wijesekera 36 Account Class Diagram Need to define
good standing
Overdrawn
For account
Need to ensure
Id is unique within class
Close(Id) is allowed only for accounts with 0 balance.
Withdraw and deposit act according to state chart
37. 6/8/2012 Duminda Wijesekera 37 Example Continued Uniqueness of ID
Account
self->forAll( c1, c2 | c1 <> c2 implies c1.id <> c2.id)
Definability of State: (Option 1)
Add an extra attribute, say minBalance.
GoodStanding = (balance >= minBalance)
AccountOverdrawn = (balance < minBalance)
Definability of State: (Option 2)
Add an extra BOOLEAN attribute, say Sanding
State invariant: Standing = (balance >= minBalance)
38. 6/8/2012 Duminda Wijesekera 38 Stating Pre and Post Conditions Regular Withdraw
Account::regWithdraw(id, amount)
Pre: (account.balance >= account.minBalance) and
(amount >= 0) and (id = self.id)
Post: (account.balance = account.@pre->balance -amount) and
(account.balance >= account.minBalance)
39. 6/8/2012 Duminda Wijesekera 39 Stating Pre and Post Conditions Overdraft
Account::overdraft(id, amount)
Pre: (account.balance >= account.minBalance) and
(amount >= 0) and (id = self.id)
Post: (account.balance = account.@pre->balance -amount) and
(account.balance < account.minBalance)
40. 6/8/2012 Duminda Wijesekera 40 Events, Activities Events should be mapped to methods, with the appropriate parameters, conditions, state changes etc.
Activities, entry actions, and exit actions must also be mapped to method calls.
Calling activities and actions must be post conditions of events that have them.
41. 6/8/2012 Duminda Wijesekera 41 Inheritance and Constraints Liskov Substitution Principle
Whenever an instance of a class is expected, an instance of it s subclass can be substituted.
Implications
An invariant of a super-class is inherited by its subclass. Hence a subclass may strengthen it, but not weaken it.
A pre-condition may be weakened, not strengthened in a re-definition of the method.
A post-condition may be strengthened, not weakened in a redefinition of an operation.
42. 6/8/2012 Duminda Wijesekera 42 Action Semantics Extending OCL to Include Actions by Kleppe and Warmer (UML 2000) conference.
Syntax:
Action: If <condition>
to <targetSet>
send <eventSet>
43. 6/8/2012 Duminda Wijesekera 43 Examples of Actions- 1 Example 1:
Context: cutomerCard::invalidate()
Pre: none
Post: valid = false
Action: if customer.special to customer
send polliteInvalidLetter()
Action: if not customer.special to customer
send invalidLetter()
44. 6/8/2012 Duminda Wijesekera 44 Examples of Actions- 2 Example 2:
Context: cutomerCard
inv: validFrom.isBefore(goodThru)
Action: if goodThru.isAfter(Date.now)
to self
send invalidate
45. 6/8/2012 Duminda Wijesekera 45 Issues with Action Semantics When is <condition> evaluated?
At postcondition time of operation
Reason:
To be called in a context where Pre-condition is true is callers responsibility.
Method has no control over pre-condition.
Hence, after method execution, <condition> will be evaluated and action executed.
46. 6/8/2012 Duminda Wijesekera 46 Underlying Assumptions Every object (component) has two queues
Output queue, to include outgoing events.
Input queue to include incoming events.
Only events generated by current operation should be specified.
Events send by operations called by the current operation should not be included.- They need to be defined in called operations.