1 / 44

UML -Part 3

UML -Part 3. Dynamic Diagram Types. Interaction Diagrams - Set of objects or roles and the messages that can be passed among them. Sequence Diagrams - emphasize time ordering Communication Diagrams - emphasize structural ordering State Diagrams

ferris
Download Presentation

UML -Part 3

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. UML -Part 3

  2. Dynamic Diagram Types • Interaction Diagrams - Set of objects or roles and the messages that can be passed among them. • Sequence Diagrams - emphasize time ordering • Communication Diagrams - emphasize structural ordering • State Diagrams • State machine consisting of states, transitions, events and activities of an object • Activity & Swimlane Diagrams • Emphasize and show flow of control among objects

  3. Sequence Diagrams • Describe the flow of messages,events, actions between objects • Show concurrent processes and activations • Show time sequences that are not easily depicted in other diagrams • Typically used during analysis and design to document and understand the logical flow of your system

  4. Sequence Diagram

  5. Sequence Diagram Time Increasing --> All lines should be horizontal to indicate instantaneous actions. Additionally if ActivityA happens before ActivityB, ActivityA must be above activity A

  6. Components Objects: aStudent is a specific instance of the Student class Generic (unnamed)objects Generic (unnamed)objects of class type Seminar and Course Specific Instance of an Object

  7. Components execution lifeline

  8. Components Method call Return value

  9. Components c : Client o : ODBCProxy : Transaction create() setActions(a, b, c) setValues(a, 3, 4) setValues(b, c, 7) (committed) destroy() create() destroy() Synchronous message Asynchronous message Return message

  10. Asynchronous Message Example There are problems here… what are they? Synchronous message Asynchronous message Return message

  11. Components: alt/else

  12. Components: option

  13. Components: loop

  14. Rules of thumb • Rarely use options,loops,alt/else • These constructs complicate a diagram and make them hard to read/interpret. • Frequently it is better to create multiple simple diagrams • Create sequence diagrams for use cases when it helps clarify and visualize a complex flow • Remember: the goal of UML is communication and understanding

  15. Summary • Sequence diagrams model object interactions with an emphasis on time ordering • Method call lines • Must be horizontal! • Vertical height matters! “Lower equals Later” • Label the lines • Lifeline – dotted vertical line • Execution bar – bar around lifeline when code is running • Arrows • Synchronous call (you’re waiting for a return value) – triangle arrow-head • Asynchronous call (not waiting for a return) – open arrow-head • Return call – dashed line

  16. In class exercise • Draw a sequence diagram for: • Getting on a flight. Start at home, check in at the counter, go through security, and end up at the gate. (If you have time during the exercise, get yourself to your seat.) • You may get searched in security

  17. In class exercise • Draw a sequence diagram for: • Getting money from an ATM machine • Treat each part of the ATM as a class • Money dispenser • Screen • Keypad • Bank computer • Etc…

  18. State Diagrams • Depicts object behavior across use cases • State: collection of values of attributes • State-behavior relationship • state is updated by some behavior carried out • Notation • States: rounded rectangles • Arrows: state transitions • Labels on Arrows: event/action/use case

  19. Example 1:Book in a Library System start Reserved release New reserve Borrowed borrow activate return Available

  20. What Are Statechart Diagrams? • A statechart diagram shows a state machine, which specifies the sequences of states that an object can be in, the events and conditions that cause the object to reach those states, and the actions that take place when those states are reached. Sample Sample State 1 State 2

  21. Sample Sample State 1 Activity Drawing States • A state is represented as a rounded rectangle on a statechart diagram. • As a comparison, note the subtle difference between a state versus an activity.

  22. State and Attributes • States may be distinguished by the values of certain attributes. The maximum number of students per course is 10. numStudents < 10 numStudents > = 10 Open Closed

  23. States and Links • State may also be distinguished by the existence of certain links. • Instances of class Professor can have two states • Teaching when a link to a course exists. • On sabbatical when no link exists. <<entity>> <<entity>> Professor Course 1 1 0..* 0..*

  24. Special States • The initial state is the state entered when an object is created. • An initial state is mandatory. • Only one initial state is permitted. • The initial state is represented as a solid circle. • A final state indicates the end of life for an object. • A final state is optional. • More than one final state may exist. • A final state is indicated by a bull’s eye. Sample Sample State 1 State 2

  25. What Are Events? • An event is the specification of a significant occurrence that has a location in time and space. • An event is an occurrence of a stimulus that can trigger a state transition. • Example • Adding a student to a course • Creating a new course Event State A State B

  26. What Are Transitions? • A transition is a change from an originating state to a successor state as a result of some stimulus. • The successor state could possibly be the originating state. • A transition may take place in response to an event. • Transitions can be labeled with events. Event State A State B Transition

  27. What Are Guard Conditions? • A Boolean expression that is evaluated when the transition is triggered by the reception of the event trigger. If the expression evaluates to True, the transition is eligible to fire. If the expression evaluates to False, the transition does not fire. Event[ thisAttribute >= 3 ] State A State B Guard Condition

  28. What Are Actions? • Executable atomic computations that result in a change in state of the model or the return of a value • Associated with a transition • Take an insignificant amount of time to complete • Non-interruptible Event[ thisAttribute >= 3 ] / Action State B State A entry/ Action Actions

  29. What Are Activities? • Ongoing, non-atomic executions within a state machine • An operation that takes time to complete • Starts when the state is entered • Can run to completion or can be interrupted by an outgoing transition State B Event[ thisAttribute >= 3 ] / Action State A entry/ Action Activities do/ on Undefined/

  30. Send Events • One event may trigger the sending of another event. • An activity can also send an event to another object. State A Event[ thisAttribute >= 3 ] / Action ^Send Event State B entry/ Action do/ on Undefined/ ^Send Event

  31. What Are Substates? • Statechart diagrams can become very complex. • Substates (nested states) can be used to simplify complex diagrams. • A superstate is a state that encloses nested states called substates. • Any number of levels of nesting are permitted. • Nested states can lead to substantial reduction of graphical complexity, allowing us to model larger and more complex problems.

  32. Statechart Diagram Without Substates add student / numStudents = numStudents + 1 / numStudents = 0 remove student / numStudents = numStudents - 1 Unassigned closeRegistration cancel Cancelled addProfessor do: Send cancellation notices close cancel removeProfessor [ numStudents = 10 ] cancel Full close[ numStudents < 3 ] close add student / numStudents = numStudents + 1 closeRegistration [ has Professor assigned ] [ numStudents = 10 ] closeRegistration[ numStudents >= 3 ] Assigned Committed do: Generate class roster close[ numStudents >= 3 ] remove student / numStudents = numStudents - 1

  33. Statechart Diagram with Substates superstate / numStudents = 0 Open Closed closeRegistration Cancelled close Unassigned do: Send cancellation notices cancel substate cancel Full close[ numStudents < 3 ] remove a professor close [ numStudents = 10 ] add a professor closeRegistration [ has Professor assigned ] closeRegistration[ numStudents >= 3 ] Committed Assigned do: Generate class roster add student / numStudents = numStudents + 1 close[ numStudents >= 3 ] H remove student / numStudents = numStudents - 1

  34. When to DrawState Diagrams • State diagrams are good at describing the behavior of an object across several use cases • Use state diagrams only for those classes that exhibit interesting behavior, often the main classes of the system

  35. State Diagrams Help Complete System Design • State diagrams often reveal use cases overlooked in earlier analyses of the system • State diagrams provide hints on which attributes are necessary for a given class

  36. Activity Diagram • Represents sequence of activities • Depicts condition, iteration, and parallel activities • When to use: • Analyzing use cases • Alternate way of describing a use case • Depicting use case sequences/workflow • Describing method behavior

  37. Activity Diagram Notation • Oval - activity • Start and end buttons • Links between ovals to depict sequence • Diamond – conditional branch and merge • Bar – fork and join (concurrent activities)

  38. About Activity Diagrams • Helps in understanding system behavior, but … it does not provide an object-oriented perspective! • Suggestion: just use as a tool to clarify complex sequential/parallel relationships between behavioral components

  39. CRC Cards • Not really part of the UML • But helps in construction of Class Diagrams and Interaction Diagrams • CRC: Class-Responsibility-Collaboration • Role-playing: • Team members represent classes • Each member/class holds an index card

  40. CRC Cards, continued • Team goes through each use case and role-play object interaction • Responsibilities (which end up being methods) are noted on the index card • Use of an index card is deliberate • Responsibilities ought to be evenly distributed across the classes that interact • Overloaded classes become immediately apparent

  41. CRC Cards and UML Diagrams • Role-playing activity for each use case maps directly to interaction diagram construction • Each card provide class details (methods) for the class diagram

  42. Activity Diagram • Supplements the use-case by providing a diagrammatic representation of procedural flow • Details: • Start is a single circle • End is a bulls-eye • Decisions are diamonds (guards must be on both branches of the diamond!) • Questions: • Do we always have a start? • Do we always have an end?

  43. Swimlane Diagrams Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle

  44. Activity Diagram Example Fork/Branch To show concurrent activity, activity diagrams allow branches and joins. You can also reference or include other activity diagrams Join

More Related