1. CS551 - Lecture 6 1 CS551 Modelling with Objects (Chap. 3 of UML) Yugi Lee STB #555 (816) 235-5932 yugi@cstp.umkc.edu www.cstp.umkc.edu/~yugi

2. 2 CS551 - Lecture 6 Object Modelling Static model: the state of an object at any given moment (object attributes, relationships, constraints between objects) Dynamic model: the changes that happen to the state as event occur (actions affect objects, using the changes of objects and attributes in the object state) Interactive model: interactions between objects (the responsibility for achieving goal is divided among collaborating objects)

3. 3 CS551 - Lecture 6

4. 4 Dynamic Model: Object and Action The behavior of a type is specified by the actions it participates in. Each action is specified by actions spec(s). An action spec defines the effects of that action in terms of the attributes of the objects involved, and the conditions under which those effects hold, using: –preconditions: what is expected to be true at the start of the action –rely conditions: what is expected to be maintained true during the action –postconditions: what is correspondingly ensured to become true at the end of the action –guarantee conditions: what is ensured to remain true during the action

5. 5 CS551 - Lecture 6 Action and Pre/Post Conditions action schedule_course (reqCourse: Course, reqStart: Date) pre: Provided there is an instructor qualified for this course who is free on this date, for the length of the course. post:A new confirmed session has been created, with course = reqCourse, startDate = reqStart, and endDate – startDate = reqCourse.length.

6. 6 CS551 - Lecture 6

7. 7 Dynamic Model: Action An action-occurrence may abstract a whole series of interactions and smaller changes. Action type: The set of action-occurrences that conform to a given action-spec. A particular action occurrence may belong to many action-types. Action spec: A specification of an action type. An action spec characterizes the effects of the occurrences on the states of the participating objects (with a postcondition).

8. 8 CS551 - Lecture 6

9. 9 Object and Action Object: anything that presents a definable encapsulated behavior to the world around it –individual programming-language objects, software components, programs, networks, relations, records, hardware, people, and organizations Action: specified by its effect on the state of the object and any information exchanged in the course of that action. –individual programming-language messages, procedure calls, complete dialogs between objects of all kinds. – the effects of an action even without knowing exactly who initiates it or how it works in detail.

10. 10 CS551 - Lecture 6

11. 11 CS551 - Lecture 6 Two Kind of Actions Localized Actions: operations –action Type::actionName (...)... –a one-sided specification of an action, focused entirely on a single object and how it responds to a request, without regard to the initiator of that request. Joint Actions: use-cases –action (party1: Type1, party2: Type2,...) :: actionName (...) –abstract multiple interactions and specific protocols for information exchange, –the net effect on all participants and the summary of information exchanged.

12. 12 CS551 - Lecture 6 Dynamic Model: Action The postconditions and guarantee must hold for any action occurrence, provided its precondition and rely condition were met. The rely and guarantee conditions are less often utilized, and only for non-atomic actions with significant duration, which can happen concurrently with other actions. Order :: fulfill –pre: the order must be in the pending state –rely: while the order is being fulfilled the product specifications had better not change –post: the fulfilled order has been shipped to the customer based on the product specifications, and the order has been inserted into the billing queue –guarantee: true i.e. not particular rule maintained during an order's fulfillment.

13. 13 CS551 - Lecture 6 More-Precise Action Specification Using snapshots to guide postconditions: informal --> snapshots --> formal –the action postconditions what to trying to determine –a snapshot illustrates only one case, a set of snapshots is needed, thinking tool. action assign_mentor (subject: Instructor, watchdog: Instructor) post: The watchdog is now the mentor of the subject. action assign_mentor (subject: Instructor, watchdog : Instructor) post -- the watchdog is now the mentor of the subject subject.mentor = watchdog

14. 14 CS551 - Lecture 6 More-Precise Action Specification Comparing before and after: a postcondition makes an assertion about the states immediately before and after the action has happened. For every object there are two snapshots and two complete sets of attribute values to refer to. action assign_mentor (subject: Instructor, watchdog : Instructor) post subject.mentor = watchdog and let ex_mentee = watchdog.mentee@pre in ex_mentee <> null ==> ex_mentee.mentor = null -- watchdog is now subject’s mentor, and if watchdog had a previous mentee, they now have none

15. 15 CS551 - Lecture 6 More-Precise Action Specification Newly created objects: new action schedule_course (reqCourse: Course, reqStart: Date) post: let ns: Session.new [course = reqCourse and startDate = reqStart and endDate – startDate = reqCourse.length ] in ns.instructor.available@pre(startDate, endDate) Collections: set union (+) and set differnce (-) action reassign_course (session : Session, new_inst: Instructor) post: let ex_instructor = session.instructor@pre in ex_instructor.schedule = ex_instructor.schedule@pre – session and new_inst.schedule = new_inst.schedule + session Summary: to avoid unnecessary details and simplify complexity by assuming a parameterized attribute whose values are available later

16. 16 CS551 - Lecture 6 Two Java Implementations of a Calendar The internal representation and interactions differ widely between the implementations. Our behavior specification must abstract these irrelevant “internal” interactions and include only interactions with objects that the client should be aware of.

17. 17 CS551 - Lecture 6 External Object Behavior Abstractions Internal Details

18. 18 CS551 - Lecture 6 From Attributes to Operation Specification List the operations: addEvent, isFree, removeEvent, and calendarFor. Write informal operation descriptions of each one. Identify the inputs and outputs Working from your initial type diagram, sketch a pair of snapshots before and after each operation (draw them on one diagram) Draw a static type diagram of the object being specified, generalizing all snapshots.

19. 19 CS551 - Lecture 6 From Attributes to Operation Specification Document the invariants that the model should satisfy. inv Event:: start <= end inv Instructor:: free(d: Date) = ( self.schedule [overlaps(d)] ->isEmpty ) inv Event:: overlaps(d: Date) = (start = d) Specify operations. Make the operation specs more precise; function is a side-effect free operation action Calendar::addEvent (d1: Date, d2: Date, i: Instructor, o: Object): Event pre: d1 forAll (d | i.free (d)) post: result: Event.new [ info = o & start = d1 & end = d2 & instructor = i & calendar = self] function Calendar::isFree (i: Instructor, d1: Date, d2: Date) : Boolean pre: d1 < d2 post: result = {d1..d2}->forAll (d | i.free (d))

20. 20 CS551 - Lecture 6 From Attributes to Operation Specification Create parameter models. describe any input/output parameter types and their attributes and opertions to the extent that the client and the implementor need to understand and agree on them action Event::delete () pre: true post: -- the same effect as removing the event from the calendar [[ calendar.removeEvent (self) ]] Write a dictionary of terms and improve your informal specifications. –instructor the person assigned to a scheduled event –schedule the set of events instructor is currently scheduled for –free if an instructor is free on a date, no event on his schedule overlaps with that date Improve the model or design by some factoring.

21. 21 CS551 - Lecture 6 Action with Invariants inv Instructor:: qualifiedFor -> includesAll (sessions.course) sessions ->forAll (s1, s2 | s <> s1 implies not s1.overlaps(s2)) inv Session:: confirmed ==> instructor <> null and end = start + course.duration action Scheduler::change_dates ( s: Session, d: Date ) pre:s.start > now and s.course <> nil and s.course.duration : Days post:s.start = d and s.end = d + course.duration after simplified action Scheduler::change_dates ( s: Session, d: Date ) pre:s.start > now post:s.start = d

22. 22 CS551 - Lecture 6 Action with Invariants Static Invariants: hold before and after the actions in its range, required to be true of all the actions in its rage. Dynamic (effect) invariants: an effect that is invariant across all actions in its rage and is implicitly added to the postconditions of those actions.

23. 23 CS551 - Lecture 6 Dynamic Invariants inv effect Calendar::count_invocations post: count += 1 An effect invariant is added to the postcondition of all actions in its range action Calendar::removeEvent (e: Event) pre : -- provided the event is on this calendar schedule->includes (e) post : -- that event has been removed from the calendar and instructor schedules not schedule->includes (e) and not e.instructor@pre.schedule->includes (e) -- and the effect invariant is implicitly applied and count += 1

24. 24 CS551 - Lecture 6 Admin Company schedule pay deliver Session date, topic cost Instructor qualified Students skills fee-due funds Captures important rules accurately without getting into implementation details Enable the Business User to raise and resolve critical issues early Static invariant Attribute constraint in all states Dynamic Invariant A state change rule that applies to all actions assigned Action Spec guarantees and assumptions of action Rules = Actions + Static + Dynamic Invariants “New session created, confirmed if qualified instructor available” “Any change in session must propagate to scheduler” “Assigned instructor is qualified for topic”

25. 25 CS551 - Lecture 6 Context and Control of an Invariant Context: The type in which an invariant is written. Any object to conform to the type –the invariant should be always true. –the invariant can be broken behind the interface, but it must be restored when the operation is complete. Behind that interface are components of the design that have their own nested contexts and invariants that govern them