Sequence & Statechart Diagrams Month Day, Year

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

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

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

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

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

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

Review – Use Case Diagram Details

Interaction Diagrams

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

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

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

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

Sequence Diagrams – Elements

Sequence Diagrams – Lifeline UML Section Is Specification Collections Stereotypes Documentation

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

Sequence Diagrams – Messages Collections Arguments Name Type Value Stereotype

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Statechart Diagrams - Elements

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

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

State Properties - General

State Properties - Actions

State Properties - Other

State Properties

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”

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

State Transitions

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

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

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

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

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

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

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