1. 1 Object Oriented Analysis System modeling = Functional modeling + Object modeling + Dynamic modeling Functional modeling = Use cases Object modeling =class diagrams Dynamic modeling –Interaction Diagrams Sequence diagrams Collaboration diagrams –State diagrams (activity diagrams) Describe the static structure of the system

2. 2 Dynamic Modeling with UML Two UML diagrams types for dynamic modeling: –Interaction diagrams describe the dynamic behavior between objects –Statechart diagrams describe the dynamic behavior of a single object. Purpose: –Detect and supply operations for the object model.

3. 3 UML Interaction Diagrams Two types of interaction diagrams: –Sequence Diagram: Describes the dynamic behavior of several objects over time Good for real-time specifications –Collaboration Diagram: Shows the temporal relationship among objects Position of objects is based on the position of the classes in the UML class diagram. Does not show time,

4. 4 UML State Chart Diagram State Chart Diagram: –A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events). Activity Diagram: –A special type of state chart diagram, where all states are action states (Moore Automaton). Classes without interesting dynamic behavior are not modeled with state diagrams

5. 5 Collaboration Diagrams Message1() :Class A instance MyB: B instance

6. 6 Sequence Diagram Message1() :Class A instanceMyB: B instance

7. 7 Sequence Diagram Properties UML sequence diagram represent behavior in terms of interactions Useful to identify or find missing objects Time consuming to build, but worth the investment Complement the class diagrams (which represent structure).

8. 8 Interactive Diagrams Notations Class Instance Message expression –Return:= name (param: param type): return type Link (in collaboration diagrams): –A connection path between 2 objects where multiple messages flow –Put messages ordered by numbers and have arrows to show their direction Class Name :Class NameC1:Class Name

9. 9 How do we detect Operations? Good starting point: Flow of events in a use case description From the flow of events we proceed to the sequence diagram to find the participating objects. –An event always has a sender and a receiver Find them for each event => These are the objects participating in the use case.

10. 10 What is an Event? Something that happens at a point in time An event sends information from one object to another Events can have associations with each other: –Causally related: An event happens always before another event An event happens always after another event –Causally unrelated: Events that happen concurrently

11. 11 Flow of events in “Sale process” use case : 6. The controller Finds Item ID from the product catalog 7. The controller Gets item price from the product description 8. The controller Calculate subtotal in the SaleLineItem Where are the objects? An Example

12. 12 Sequence Diagram for “Sale Process” GetPrice () price CalSubTotal() ControllerProduct Catalog Product description FindItem (ID) 6. The controller Finds Item ID from the product catalog 7. Get item price from the product description 8. Calculate subtotal in the SaleLineItem. time SaleLine Item

13. 13 Sequence Diagrams Used during analysis –To refine use case descriptions –to find additional objects (“participating objects”) Used during system design –to refine subsystem interfaces Instances are represented by rectangles. Actors by sticky figures Lifelines are represented by dashed lines Messages are represented by arrows Activations are represented by narrow rectangles. selectZone() pickupChange() pickUpTicket() insertCoins() TicketMachine Passenger Focus on Controlflow Messages -> Operations on participating Object zone2price selectZone() insertCoins() pickupChange() pickUpTicket() TicketMachine

14. 14 Execution Specification Sequence diagram: Basic Notation Sequence diagrams represent the behavior of a system as messages (“interactions”) between different objects. Lifeline Message

15. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Lifeline and Execution Specification A lifeline represents an individual participant (or object) in the interaction A lifeline is shown using a symbol that consists of a rectangle forming its “head” followed by a vertical line (which may be dashed) that represents the lifetime of the participant An execution specification specifies a behavior or interaction within the lifeline An execution specification is represented as a thin rectangle on the lifeline.

16. 16 Sequence Diagrams can also model the Flow of Data The source of an arrow indicates the activation which sent the message Horizontal dashed arrows indicate data flow, for example return results from a message Passenger selectZone() ZoneButtonTarifScheduleDisplay lookupPrice(selection) displayPrice(price) price Dataflow …continued on next slide...

17. 17 Sequence Diagrams: Iteration & Condition Iteration is denoted by a * preceding the message name Condition is denoted by boolean expression in [ ] before the message name Passenger ChangeProcessor insertChange(coin) CoinIdentifierDisplayCoinDrop displayPrice(owedAmount) lookupCoin(coin) price [owedAmount<0] returnChange(-owedAmount) Iteration Condition …continued on next slide... …continued from previous slide... *

18. 18 Sequence Diagrams Notations [test1] [NOT test1] Mutually Exclusive conditional messages

19. 19 Sequence Diagrams Notations Iterative messages :Simulation : Random Run simulation() * num:=nextInt()

20. 20 Sequence Diagrams Notations Iteration of a group of messages :Simulation : Random Run simulation() num:=nextInt() Work (hours) * [i=1..N]

21. 21 Sequence Diagrams Notations If the message is repeated on a collection of object instances, use the “multi object” notation and (*) at the end of the link :SalesLineItem

22. 22 Creation and destruction Creation is denoted by a message arrow pointing to the object Destruction is denoted by an X mark at the end of the destruction activation –In garbage collection environments, destruction can be used to denote the end of the useful life of an object. Passenger ChangeProcessor …continued from previous slide... Ticket createTicket(selection) free() Creation of Ticket Destruction of Ticket print()

23. 23 Sequence Diagrams Notations “Self” messages: directed from the object to itself Create instance messages are indicated with > or call it create

24. 24 Heuristics for Sequence Diagrams Creation of objects: Create control objects at beginning of event flow The control objects create the boundary objects Access of objects: Entity objects can be accessed by control and boundary objects Entity objects should not access boundary or control objects. Layout: 1st column: Should be the actor of the use case 2nd column: Should be a boundary object 3rd column: Should be the control object that manages the rest of the use case

25. 25 The impact of sequence diagram on the class diagram The sequence diagram supplies us with many new classes and operations Question: – Who owns these operations? Answer: – For each object that receives an event there is a public operation in its associated class

26. 26 The impact of sequence diagram on the class diagram