1 / 25

UML Object Modelling: Static, Dynamic, and Interactive Models

This lecture discusses the different models in UML object modelling, including static models that represent the state of an object, dynamic models that capture changes in object state, and interactive models that focus on interactions between objects.

almam
Download Presentation

UML Object Modelling: Static, Dynamic, and Interactive Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 CS551 - Lecture 9

  2. 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) CS551 - Lecture 9

  3. Dynamic Model: Action • Action: specified by its effect on the state of the object and any information exchanged in the course of that action. • E.g. 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. • Action Specification: behavior of a type CS551 - Lecture 9

  4. Dynamic Model: Action Spec • 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 CS551 - Lecture 9

  5. Action and Pre/Post Conditions actionschedule_course (reqCourse: Course, reqStart: Date) pre: 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. CS551 - Lecture 9

  6. Action and Rely/Guarantee Conditions • less often utilized, and only for non-atomic actions with significant duration (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. CS551 - Lecture 9

  7. CS551 - Lecture 9

  8. CS551 - Lecture 9

  9. Dynamic Model: Action • Action-occurrence: abstract a whole series of interactions and smaller changes. • Action type: The set of action-occurrences that conform to a given action-spec. • Action spec: A specification of an action type. • An action spec characterizes the effects of the occurrences on the states of the participating objects CS551 - Lecture 9

  10. CS551 - Lecture 9

  11. CS551 - Lecture 9

  12. Two Kind of Actions • Localized Actions: operations • a one-sided specification of an action, focused entirely on a single object and how it responds to a request. • Joint Actions: use-cases • abstract multiple interactions and specific protocols for information exchange, • the net effect on all participants and the summary of information exchanged. CS551 - Lecture 9

  13. CS551 - Lecture 9

  14. More-Precise Action Specification • Using snapshots to guide postconditions: informal --> snapshots --> formal action assign_mentor (subject: Instructor, watchdog : Instructor) post -- the watchdog is now the mentor of the subject subject.mentor = watchdog CS551 - Lecture 9

  15. From Attributes to Operation Specification • List the operations: addEvent, isFree, removeEvent, etc. • Write informal operation descriptions of each one with identified inputs and outputs • Working from your initial type diagram, sketch a pair of snapshots before and after each operation • Draw a static type diagram of the object being specified, generalizing all snapshots. CS551 - Lecture 9

  16. From Attributes to Operation Specification • Describe any input/output parameter types and their attributes and opertions 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 • schedulethe set of events instructor is currently scheduled for • freeif an instructor is free on a date, no event on his schedule overlaps with that date • Improve the model or design by some factoring. CS551 - Lecture 9

  17. 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 & end >= d) • Specify operations. action Calendar::addEvent (d1: Date, d2: Date, i: Instructor, o: Object): Event pre: d1 < d2 & {d1..d2}->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)) CS551 - Lecture 9

  18. 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. CS551 - Lecture 9

  19. Interpreting an Action Specification CS551 - Lecture 9

  20. 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 CS551 - Lecture 9

  21. 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 ands.course <> nil and s.course.duration : Days post:s.start = d and s.end = d + course.duration CS551 - Lecture 9

  22. 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. CS551 - Lecture 9

  23. Dynamic Invariants • inv effect Calendar::count_invocations post: count += 1 • 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 CS551 - Lecture 9

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

  25. An Action Spec Is Not an Implementation • Action Spec: • a Boolean expression, a relation between the inputs, initial state, final state, and outputs. • Implementation: • a particular algorithmic sequence of steps, • select a data representation or specific internal access functions, • work through iterations, branches, and many intermediate states before achieving the “final” state. CS551 - Lecture 9

More Related