Lecture 5

1. Lecture 5 • …a bit more about UML • Sequence diagrams • Collaboration diagrams • State-chart diagrams • CRC cards

2. Misc • “Missing” seminars for OOMPA E • Monday 15/10 10-12 in Q32 • Wednesday 17/10 10-12 in V35 • Seminars • It is mandatory to hand in your notes for the chapters you prepared for presentation after the seminar • Labs • Lab1 is due next Friday 28/9 • JAVA syntax highlighting in Emacs • Press “M-x” and type “font-lock-mode” • Add the line (require ‘jde) to your .emacs file

3. System Model • Scenarios - As-is scenarios, visionary scenarios • Use case model - Actors and use cases • Object model - Data dictionary - Class diagrams (classes, associations, attributes and behaviors) • Dynamic model - State diagrams for classes with significant dynamic behavior - Sequence diagrams for collaborating objects (protocol)

4. Dynamic Modeling with UML • Diagrams for dynamic modeling • Interaction diagrams describe the dynamic behavior between objects • Statecharts describe the dynamic behavior of a single object

5. Dynamic Modeling with UML • Interaction diagrams • Sequence Diagram: • Dynamic behavior of a set of objects arranged in time sequence, new objects added to the right • Good for real-time specifications and complex scenarios • Derived from use case scenario • Collaboration Diagram : • Shows the relationship among objects. Does not show time • Objects are arranged in a graph or network format

6. Sequence Diagrams vs Collaboration Diagrams • Sequence diagram :ClassA :ClassB message2() message1() message3()

7. Sequence Diagrams vs Collaboration Diagrams • Collaboration diagram message1() :ClassA 1. message2()  2. message3()  :ClassB

8. Sequence Diagrams vs Collaboration Diagrams • Sequence diagrams : • Strength: clearly show sequence or time ordering of events, simple notation • Weakness: forced to extend to the right when adding new objects • Collaboration diagrams : • Strength: space economical flexibility to add new objects in two dimensions, better to illustrate complex branching, iteration and concurrent behavior • Weakness: difficult to see sequence of messages, more complex notation

9. Dynamic Modeling with UML • 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: • Special type of statechart where all states are action states

10. State Chart Diagram vs Sequence Diagram • State chart diagrams help to identify: • Changes to objects over time • Sequence diagrams help to identify • The temporal relationship between objects over time • Sequence of operations as a response to one ore more events

11. Dynamic Modeling • Definition of dynamic model: • A collection of multiple state chart diagrams, one state chart diagram for each class with important dynamic behavior. • Purpose: • Detect and supply methods for the object model • How do we do this? • Start with use case or scenario • Model interaction between objects => sequence diagram • Model dynamic behavior of single objects => statechart diagram

12. Start with Flow of Events from Use Case • Flow of events from “Process Sale” Use case: • 1. Customer arrives at POS checkout with goods and/or services • 2. Cashier starts new sale • 3. Cashier enters item identifier • 4. System records sale line item and presents item description, price and running total. Cashier repeats steps 3-4 until indicates done • 5. System presents total with taxes calculated • 6. Cashier tells customer the total and asks for payment • 7. Customer pays and system handles payment

13. What is an Event? • Something that happens at a point in time • Relation of events to each other: • Causally related: Before, after, • Causally unrelated: concurrent • An event sends information from one object to another • One distinguishes between • The instance of an event : enterItem • The attributes of an event : itemID, quantity

14. Sequence Diagrams • From the flow of events in the use case or scenario proceed to the sequence diagram • A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (directed acyclic graph) notation • Relation to object identification: • Objects/classes have already been identified during object modeling • Objects are identified as a result of dynamic modeling • Heuristic: • An event always has a sender and a receiver. Find them for each event => These are the objects participating in the use case

15. Sequence Diagrams • Use cases and participating objects are found. What now? • Sequence diagram - A diagram that shows object interactions arranged in time sequence for a specific use case or scenario. • A sequence diagram includes time but does not include object relationships. • Sequence diagrams are used to describe use cases (i.e., all possible interactions between participating objects) and scenarios (i.e., one possible interaction) • In other words: A sequence diagram is useful to model a use case or scenario with its participating objects. It often leads to the detection of new participating objects.

16. Drawing Sequence Diagrams • Each column represents an object that is participating in the interaction. • The vertical axis represents time (from top to bottom). Messages are shown by full arrows. • Labels on full arrows represent message names and arguments. • Activations (i.e., the time it takes to perform an operation) are depicted by a rectangle attached to an object. The height of the rectangle is indicative for the duration of the operation • The vertical rectangle shows that an object is active, that is, it is handling a request made by another object. • The operation can itself send other requests to other objects • An object can request an operation from itself (looping arrow)

17. Sequence Diagrams :Cashier : System makenewSale() enterItem(itemID, quantity) description, total endSale() total makePayment(amount) change due, receipt

18. Sequence Diagrams Iterations • may have square brackets containing a continuation condition (until) specifying the condition that must be satisfied in order to exit the iteration and continue with the sequence • may have an asterisk followed by square brackets containing an iteration (while or for) expression specifying the number of iterations

19. Sequence Diagrams • Iteration in sequence diagrams is denoted by a box with an associated iteration expression. :Cashier : System makenewSale() enterItem(itemID, quantity) description, total *[more items]

20. Sequence Diagrams • Iteration in sequence diagrams is denoted by a box with an associated continuation expression. :Cashier : System makenewSale() enterItem(itemID, quantity) description, total [no more items]

21. Sequence Diagrams • Naming objects • Class name only :Classname • Instance name only objectName • Instance name and class name together object:Class • Most of the time you use the class name, but if you refer to a particular instance in a scenario the object:Class notation is used. • A scenario is an instance of a use case, where we take real or hypothetical people and things and follow them through the steps of the use case.

22. Sequence Diagrams • Conditional messages: A message might contain a guard condition denoted in square brackets obj1:Class obj2: Class message() [x < 15] calculate()

23. Sequence Diagrams • Sequence diagrams may contain branches. Branching involves multiple messages originating at the same time from a single class role. • The branch represents conditionality if the guard conditions on all the branches are mutually exclusive. Thus, only one message is sent. • The branch represents concurrency if the guard conditions are mutually inclusive. Thus multiple messages are sent.

24. Sequence Diagrams • Conditionality obj1:Class obj2: Class obj3: Class [x < 15] calculate() message() [x > 20] calculate()

25. Sequence Diagrams • Concurrency obj1:Class obj2: Class obj3: Class calculate() message() calculate()

26. Sequence Diagrams • Creation and destruction of an object in sequence diagrams are denoted by the stereotypes <<create>> and <<destroy>> :Creator <<create>> : Created Object message() X <<destroy>>

27. Sequence Diagrams • Iteration over a Collection (multiobject) • The message is send to each element rather than repeatedly to the collection itself. :Sale :SalesLineItem t:=total() * st:=subtotal()

28. Collaboration Diagrams • Collaboration diagrams contain • Classes • Associations • Message exchanges within a collaboration • Collaboration diagrams describe a set of classes and associations involved in message exchange sequences, that is a collaboration among class roles and association roles, and their interactions.

29. Collaboration Diagrams makePayment(cash) 1: makePayment(cash) :Register :Sale 1.1 create(cash)  :Payment • The first (external) message makePayment is sent to an • instance of a Register. The sender is not identified. • 2. The Register instance sends the makePayment message to • to a Sale instance. • 3. The Sale instance creates an instance of a Payment.

30. Collaboration Diagrams • Link : A link is a connection path between two objects, it indicates some form of navigation and visibility between the objects. A link is an instance of an association. • Note that multiple messages, and messages both ways can be exchanged along the same link. 1: makePayment(cash) 2: foo()  :Register :Sale 2.1: bar()  link

31. Collaboration Diagrams • Messages : each message between objects is represented with a message expression and a small arrow indicating the direction of the message. A sequence number is added to show the sequential order of messages. 1: msg2() 2: msg3()  3: msg4()  msg1() :Register :Sale 3.1: msg5() 

32. Collaboration Diagrams • Creation of instances : the stereotype <<create>> and the property new are used to indicate the creation of new instances. <<create>> 1: make(cashier) :Register :Sale {new}

33. Collaboration Diagrams • Messages number sequencing : The order of messages is illustrated with sequence numbers. The numbering scheme is: • The first message is not numbered • The order and nesting of subsequent messages is shown with a legal numbering scheme, in which nested messages have a number appended to them. Nesting is denoted by prepending the incoming message number to the outgoing message number msg1()  1: msg2() :Register :Sale 1.1 msg3()  :Payment

34. Collaboration Diagrams msg1()  1: msg2() :classA :classB 1.1 msg3()  2.1 msg5()  2: msg4() :classC 2.2: msg6() :classD

35. Collaboration Diagrams • Conditional Messages : A conditional message is shown by following a sequence number with a conditional clause in square brackets. msg1() 1 [color=red]: msg2() :Foo :Bar

36. Collaboration Diagrams Mutually exclusive messages: msg1()  1a [test]: msg2() :classA :classB 1a.1: msg3()  1b [not test]: msg4()  :classC :classD 1b.1: msg5() 

37. State Chart Diagrams • The state of an object is defined by the set of values currently held by its attributes. • At any moment in time, an object exists in a certain manner or conditon, which we say is a state. Source State Entry and Exit actions Event [Guard] / Action Target State

38. State Chart Diagrams • Statechart diagrams are useful when • A class has an interesting or complex life cycle, e.g. classes that create or delete instances or associations • An instance can update its attributes in a variety of ways as it goes through a life cycle. • If two classes are depending on each other, in that one of them can start the other on its life-cycle, or change the order in which it goes from state to state. • If you find that the object’s current behavior depends on what happened to it before, that is on its past history.

39. Statechart Diagrams • Graph whose nodes are states and whose directed arcs are transitions labeled by event names. • Distinguish between two types of operations: • Activity: Operation that takes time to complete • associated with states • Action: Instantaneous operation • associated with events • associated with states (reduces drawing complexity): Entry, Exit, Internal Action • A statechart diagram relates events and states for one class • An object model with a set of objects has a set of state diagrams

40. Statechart Diagrams • An action is an atomic behavior that is associated with a state or a transition, and is considered part of the life cycle. • Atomic means that it cannot be split any further without losing or changing the meaning of what it was. • An entry action is an action performed each time the object enters or reenters a state, regardless of how it got there.

41. Statechart Diagrams • State diagram for book class showing entry and exit actions Event B1: Subscriber requests loan Event B3: Librarian shelves book 1: Shelved entry/ UpdateTimeShelved() exit / UpdateTimeOut() 3: Checked entry/ Loan.L2 : Archive Loan 2: Signed Out entry/ Loan.L1 : Request Link to Subscriber exit / UpdateTimen() Event B2: Subscriber returns book

42. Statechart Diagrams • The life-cycle of a loan instance <<create>> Event L1: Request Link to subscriber (Book ID No., Subscriber ID No., Date/Time Out) 1: Current Event L2: Archive Loan (Date/Time In) initial state 2: Archived entry/ UpdateTimeIn() Event L3: After (90 days) /delete archived loan final state

43. CRC cards • Class-Responsibility-Collaborators (CRC) cards are a useful tool to assign responsibilities to classes • Not part of UML • Use 10x15 cm index cards • Use one card for each class • A CRC card contains: • Class name • Responsibilities • Collaborations

44. CRC cards Class name Responsibilities Collaborators

45. CRC cards • CRC modeling is carried out by a team of people • The goal of CRC modeling is: • to identify the classes that are appropriate for modeling the problem (similar to domain class model) • To identify their responsibilities and collaborations

46. Finding Responsibilities • Responsibilities • Things a class needs to know about (attributes) a class Person will know things like • name, address, phone number • Things a class needs to be able to do (methods), a class Addressbook needs to be able to • add/remove a person to an addressbook • Look up a person in the adressbook • Sort the the adressbook in alphabetical order

47. Finding Collaborators For each responsibility we must ask: • Does the class have everything it needs to do this? Does it have all the attributes? • What classes are there that can supply this information? If so record these classes as collaborators. There might be a chain of collaborators. • If some of the things needed are not available from any class at all • Add an attribute to an existing class • Define a new class

48. Observer Pattern Observer: Responsibilities • Subscribes to subjects it is interested in. • Implements a strategy to respond to changes of the subjects it subscribed to Collaborators • Subject

49. Observer Pattern Subject: Responsibilities • Maintains and provides information about itself. • Notifies observers about changes of its state as information is updated Collaborators • Observer