SWE 623- Formal Methods

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.