1 / 49

Lecture 5

Lecture 5. …a bit more about UML Sequence diagrams Collaboration diagrams State-chart diagrams CRC cards. Misc. “Missing” seminars for OOMPA E Monday 15/10 10-12 in Q32 Wednesday 17/10 10-12 in V35 Seminars

macdonaldr
Download Presentation

Lecture 5

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. 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

More Related