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 message2() :ClassB message1() message3()

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

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 makenewSale() : System 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 makenewSale() : System 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 makenewSale() : System 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 [x < 15] calculate() obj2: Class message()

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 [x < 15] calculate() obj2: Class message() obj3: Class [x > 20] calculate()

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

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

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

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 :Register :Payment 1: makePayment(cash)  1.1 create(cash)  :Sale makePayment(cash) 1.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. :Register 1: makePayment(cash)  2: foo()  :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. :Register 1: msg2()  2: msg3()  3: msg4()  :Sale 3.1: msg5()  msg1() 

32. Collaboration Diagrams Creation of instances : the stereotype > and the property new are used to indicate the creation of new instances. :Register > 1: make(cashier)  :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 :Register :Payment 1: msg2()  1.1 msg3()  :Sale msg1() 

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

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

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

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 Target State Event [Guard] / Action

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 3: Checked entry/ Loan.L2 : Archive Loan 1: Shelved entry/ UpdateTimeShelved() exit / UpdateTimeOut() 2: Signed Out entry/ Loan.L1 : Request Link to Subscriber exit / UpdateTimen() Event B3: Librarian shelves book Event B1: Subscriber requests loan Event B2: Subscriber returns book

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

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 ResponsibilitiesCollaborators

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