1. Sequence & Statechart Diagrams Month Day, Year

2. Agenda Training Plan Overview Actors and Use Case Diagrams Sequence Diagrams Diagram Elements Evolution in the Models Statechart Diagrams State Machines States Exercise Next Steps

3. Training Plan Overview Introduction Using Rational Administrator Using ClearCase Using ClearQuest Using Rational Rose XDE Identifying & Creating Use-Cases – Part 1 Identifying & Creating Use-Cases – Part 2 Detailing Requirements with RequisitePro Actors and Use-Case Diagrams Sequence and Statechart Diagrams Collaboration and Class Diagrams Integration and Development with the.NET Framework

4. Review - Actors & Entities Business Actor Represents a role played in relation to the business by someone or something in the business environment Business Worker Represents an abstraction of a human that interacts within the system Active Business Entity Represent an object that business workers access, inspect, manipulate, produce, … Provide the basis for sharing Passive Actor Represents someone in a role who interacts with the system Interacts with but have no control over use-cases Entity Represents an object used to model information and associated behavior May be persistent May be active or passive

5. Review - Use-Case Diagrams Define Associations Includes –Used to partition out parts of a workflow for which the base use case only depends on the result, not the method for reaching the result. Extends –Optionally, or conditionally, add a flow to a business use case that is already complete in itself Generalizes –Specialization into one or more child use cases that represent more specific forms of the parent

6. Review – Actor Detail Attributes Not typical of actors Select Attribute tab

7. Review - Uses Association Uses Association shows which processes the actor is involved Right cick and select Properties Window Select UML section Enter Name

8. Review – Use Case Diagram Details

9. Interaction Diagrams

10. Collaboration diagrams show order of messages that implement an operation or a transaction Sequence diagrams show object interaction in a time- based sequence

11. Sequence Diagrams - Overview Uses Show object interaction in a time-based sequence Establish the roles of objects Provide essential information to determine class responsibilities and interfaces

12. Sequence Diagrams - Elements Two dimensions Vertical representing time Horizontal representing different objects

13. Sequence Diagrams – Elements Objects/Classes Lifelines Focus of Control Text (Scripts) Note Note Anchor Class Object Message Message To Self Return Message Destruction Marker Procedure Call Asynchronous Message

14. Sequence Diagrams – Elements

16. Sequence Diagrams – Lifeline UML Section Is Specification Collections Stereotypes Documentation

17. Sequence Diagrams – Messages UML Section Message Name Simple English Alias Guard Condition Is Specification Collections Stereotypes Message Signature Documentation

18. Sequence Diagrams – Messages Collections Arguments Name Type Value Stereotype

19. Sequence Diagrams – Messages Detail Tab Synchronization Simple –The message has a single thread of control Synchronous –The operation proceeds only when the client sends a message to the supplier and the supplier accepts the message Balking –The client passes a message only if the supplier is immediately ready to accept the message; the client abandons the message if the supplier is not ready Timeout –The client abandons a message if the supplier cannot handle the message within a specified amount of time.

20. Sequence Diagrams – Messages Detail Tab Synchronization Procedure Call –The operation only proceeds on return and may return results Asynchronous –The client sends a message to the supplier for processing and continues to execute its code without waiting for or relying on the supplier's receipt of the message NotASyncType –Unspecified Return –Returns control and may return results Frequency Aperiodic Periodic

21. Sequence Diagrams – Control Flow Goal Achieve independent objects To delegate various tasks to the objects most naturally suited to perform them Reality Mix of centralized and decentralized behavior

22. Sequence Diagrams – Control Flow Centralized control of a flow of events or part of the flow of events means that a few objects steer the flow by sending messages to, and receiving messages from other objects

23. Sequence Diagrams – Control Flow Centralized control Use If the order in which the sub-event phases will be performed is likely to change To insert new sub-event phases To keep parts of the functionality reusable as separate pieces To recognize look for fork-shaped structure

24. Sequence Diagrams – Control Flow Decentralized control arises when the participating objects communicate directly with one another, not through one or more controlling objects

25. Sequence Diagrams – Control Flow Decentralized control Use If sub-event phases are tightly coupled If forming a part-of or consists-of hierarchy To form a conceptual inheritance hierarchy To represent a fixed chronological progression To encapsulate and thereby make abstractions of functionality To recognize look for stairway-shaped structure

26. Sequence Diagrams – Sub-Sequence Use to reduce complexity Recognition Occurs repeatedly in different places Is expected to be performed repeatedly in future iterations Is complex but easily encapsulated Is determined to be encapsulated within a replaceable sequence

27. Sequence Diagrams - Transactions Define a set of operation invocations which are atomic; they are either all performed, or none of them are performed Beginning / End Textual Explicit Message

28. Sequence Diagrams - Evolution Business Use-Case Model Simplicity Plain English Shows interaction between Business Actors –Workers Business Entities

29. Sequence Diagrams - Evolution Business Analysis Model Simple Operations Plain English Shows interaction between Business Actors –Workers Business Entities

30. Sequence Diagrams - Evolution Use-Case Model Simple Plain English Shows interaction between Actors (Business Workers) System (Computer)

31. Sequence Diagrams - Evolution Analysis Model Simple Operations Plain English Shows interaction between Actors –Systems Use-Cases Entities

32. Sequence Diagrams - Evolution Design Model Full Operations Programming Notation Shows interaction between Actors –Systems Use-Cases Entities

33. States & Transitions A state is a condition of an object in which it performs some activity or waits for an event. A transition is a relationship between two states which is triggered by some event, which performs certain actions or evaluations, and which results in a specific end-state

34. State Machines Consists of states, linked by transitions. Used To Model Dynamic Behavior Event-driven aspects of the system's behavior Are required for objects who call events and signal events to implement their operations State-dependent behavior Are required for active objects whose behavior varies base on their state Are not required for passive objects whose behavior does not vary with their state

35. Statechart Diagrams - Elements

36. State Properties Name Entry/Exit Actions Internal Transitions Sub-States Properties Name Trigger Guard Condition Action Pseudo-states Name Initial – Final Transition –No Trigger Deferred States

37. State Properties Internal Transitions Transitions that are handled without causing a change in state Substates The nested structure of a state, involving disjoint (sequentially active) or concurrent (concurrently active) substates Deferred States A list of events that are not handled in that state but are postponed and queued for handling by the object in another state

38. State Properties - General

39. State Properties - Actions

40. State Properties - Other

41. State Properties

42. State Transitions A relationship between two states indicating that an object in the “Source State” will perform certain actions and enter the “Target State” when a specified event occurs and specified conditions are satisfied Transaction state becomes “Firing”

43. State Transitions Event Name Stereotype Event Trigger The event that makes the transition eligible to fire Guard Condition A condition which must be satisfied before the transition can fire Action

44. State Transitions

46. Nested States Machines One Initial and One Final State Composite State Unlimited Depth Control Based on Transition Type Entry/Exit Action To/From Composite To/From Nested State –Via Composite

47. History States Allows the return to a previous sub-state within a nested state

48. Abstract State Machines Need to have more detail added before it can be used for practical purposes Utilize Inheritance Root Class

49. Chained States Transition Extension Separates the internal specification of the containing state from its external environment Encapsulation No internal structure No entry action No internal activity No exit action No transitions triggered by events Any number of input transitions May have an outgoing transition with no trigger event Automatically fires when an input transition activates the state

50. Chained States Elucidation Chained Exit action of S11 Action a11 Exit action of S1 Action a12 Entry action of S2 Action a13 Entry action of S21 Unchained Exit action of S11 Exit action of S1 Action a2 Entry action for state S2 Entry action for state S21

51. Statechart Diagrams - Modeling Set Context Define Initial / Final States Pre/Post Conditions Define Events Define Intermediate States Connect with transitions Define Entry / Actions Define Substates Expand / Consolidate Validate Object/Class Use Analyze & Re- analyze

52. Next Steps Homework Homework Model Add Sequence and Statechart Diagrams –Use modeling elements Classes Ahead Collaboration and Class Diagrams Integration and Development with the.NET Framework