Modeling System Behavior. Events Scenarios Sequence Diagrams Collaboration Diagrams

Transcription

1 References: Jacquie Barker,Beginning Java Objects ; Booch, Rumbaugh and Jacobson, The Unified Modeling Language User Guide; internet notes; Martin Fowler,UML Distilled; 10/8/ Events Scenarios Sequence Diagrams Collaboration Diagrams 10/8/ Modeling System Behavior State of an object: set of all the object s attribute values at a given point in time, including values of all simple attributes values of all reference variable attributes representing links to other objects An object s dynamic behavior can result in changes to the static structure of the system Object collaborations are triggered by events -- occurrences (messages) that trigger a state transition 10/8/

2 Events Events can be: user initiated (e.g. a mouse or button click) initiated by another system initiated by another object within the same system Objects may respond to events in several ways: the object changes its state the object resends the message to another object the object returns a value the object reacts with external system boundary the object ignores the message intended to trigger an event 10/8/ Scenarios A scenario is one path through a use case -- can be called an instance of a use case One use case can involve many different scenarios A scenario is a specific sequence of actions that illustrates behavior of objects in the system Scenarios are represented in UML as sequence diagrams 10/8/ Interaction Diagrams Interaction diagrams model the dynamic parts of a system. Other types of interaction diagrams include use case diagrams, collaboration diagrams, statechart diagrams and activity diagrams They capture the behavior of a single use case Sequence diagrams are focused on the time ordering of messages. They model the lifeline of an object The lifeline represents the existence of the object at a given time 10/8/

3 Generic Sequence Diagram Focus of control lifeline 10/8/ Sequence Diagrams 1. The vertical dimension represents time, the horizontal dimension represents objects. Time moves top to bottom. 2. A solid line arrow from an actor or object to another object represents a message. If possible, objects are arranged along the top so that most messages flow left to right. 3. Usually only the class name is given, ie :Vector, but the name of the object can also be given (courselist:vector) 4. Method calls may include parameters 10/8/ Sequence Diagrams 1. The vertical dashed line represents an object's lifeline. An open box over an object's lifeline indicates that a method of that object is active called an activation box. 2. A method in an object may call another method within the same object (i.e. send a message to itself). If so, a second overlapping activation box is shown. 3. Return arrows are dashed and optional. They run from the end of a callee's activation back to the caller's activation. 4. Objects that are created as part of the sequence of methods are introduced at the point of creation. 10/8/

4 Use case: Prepare Orders The Order Entry window sends a prepare message to an Order The Order sends prepare to each Order Line on the Order Each Order Line checks the given Stock Item If this check returns true, the Order Line removes the appropriate quantity of Stock item from stock and creates a delivery item If the Stock Item has fallen below the reorder level, that Stock Item requests a reorder. 10/8/ Example from Fowler, UML Distilled An Order Entry window prepare() anorder anorderline astockitem *prepare() hasstock := check() Sequence Diagram for the Prepare Order use case iteration [hasstock ] remove() condition needsreorder:= needstoreorder() [needsreorder] new areorder Item deletion [hasstock]new creation adelivery Item 10/8/ Example from Fowler, UML Distilled Sequence diagram for Scenario#1 of SRS system 10/8/

5 Use Sequence Diagrams to Determine Methods Once you have sequence diagrams, you can use them to flesh out methods If a solid line arrow touches an object, it means that object should define a method to carry out the request Dashed arrow lines indicate return values for the methods represented by the solid lines Loops represent private helper methods or other public methods that can be called by clients 10/8/ Locus of Control A good OO design distributes work among many objects. If the sequence diagram illustrates one class sending out all the messages, then it is procedural code get this get that is the sign of a controller. one object controls the process. Other objects provide data. The next two slides illustrate this problem and its solution 10/8/ Order as Controller (Fowler,OOPSLA 99 Tutorial) anorder anorderline aproduct acustomer price getquantity getproduct getpricingdetails calculateprice calculatediscounts getdiscountinfo 10/8/

6 Distributed Control (Fowler,OOPSLA 99 Tutorial) anorder anorderline aproduct acustomer price *[all order lines]price getprice(quantity.number) Control is given to object that has the data getdiscountedvalue(anorder) getbasevalue 10/8/ Collaboration Diagrams Objects are shown as icons Arrows indicate messages sent within the use case being described Messages are numbered to correspond with the execution of a particular scenario UML uses decimal numbering (1, 1.1, 1.1.1,1.1.2, , etc.) Can use simple numbering (1,2,3, etc.) The layout of objects indicate how objects are statically connected 10/8/ General Collaboration Diagram Links With sequence diagrams you have to infer the collaboration from messages sent. In a collaboration diagram links are shown in addition to messages. 10/8/

7 Associations exist between classes, links exist between objects. Associations are between classes Links are between objects 10/8/ Mary:Student Mary s Plan of Study: PlanOfStudy 1.Log on 7. Add to course load 4. Verify plan of study Mary:Student 3.request seat OBJECTS101 Sec1: Section 6. Confirm seat availability 5. Check prerequisite 2. Request display of schedule :ScheduleOfClasses Mary s Transcript: Transcript Collaboration diagram for SRS Scenario #1 10/8/ :OrderEntryWindow 1:prepare() Collaboration diagram for PrepareOrder use case :Order 1.1#[for all order lines]:prepare() : needsreorder := needtoreorder() 1.1.1:hasStock := check() 1.1.2:[hasStock]:remove() Linnea :OrderLine Linnea stock : StockItem :DeliveryItem 1.1.3[hasStock]:new [needsReorder]: new :ReorderItem 10/8/2003 Example from Fowler, UML Distilled 21 7