Your SlideShare is downloading. ×
5.state diagrams
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

5.state diagrams

7,068
views

Published on


1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,068
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
280
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 1
  • Transcript

    • 1. State Diagrams Chapter 5Object-Oriented Software Systems Engineering – Chapter 5 Slide 1
    • 2. Objectives In this chapter we will:  Introduce the terms used with respect to state diagrams  Discuss the context in which state diagrams are used  Introduce substates  Discuss concurrent state diagramsObject-Oriented Software Systems Engineering – Chapter 5 Slide 2
    • 3. Statechart Diagrams  State diagrams describe the life of an object using three main elements:  States of an object  Transitions between states  Events that trigger the transitions  A state diagram or statechart specifies a state machine  A state machine is described for a class  Each object has it’s own state machineObject-Oriented Software Systems Engineering – Chapter 5 Slide 3
    • 4. Why Use Statechart Diagrams?  Statecharts typically are used to describe state-dependent behaviour for an object  An object responds differently to the same event depending on what state it is in  Usually applied to objects but can be applied to any element that has behaviour  Actors, use cases, methods, subsystems, systems  Statecharts are typically used in conjunction with interaction diagrams (usually sequence diagrams)  A statechart describes all events (and states and transitions for a single object)  A sequence diagram describes the events for a single interaction across all objects involvedObject-Oriented Software Systems Engineering – Chapter 5 Slide 4
    • 5. States  Show what the dependencies are between the state of an object and its reactions to messages or other events  State  is a condition or situation during the life of an object within which it performs some activity, or waits for some events  Has a name  Has actions -- execute the state  Has internal transitions -- transitions cause no change in a state  substates -- the nested structure of a state involving disjoint or concurrent substatesObject-Oriented Software Systems Engineering – Chapter 5 Slide 5
    • 6. States  For example: At Work state name entry/unlock door action performed on entry to state do/prepare materials activity performed while in state telephone rings/answer telephone action performed on arrival of named event include/lecture state name of a sub-state machine exit/lock door action performed on leaving stateObject-Oriented Software Systems Engineering – Chapter 5 Slide 6
    • 7. Initial and Final States  The initial state of a state machine is indicated with a solid circle  Known as a pseudo-state  A transition from this state will show the first real state  The final state of a state machine is shown as concentric circles  A closed loop state machine does not have a final state; the object lives until the entire system terminates  An open loop state machine represents an object that may terminate before the system terminatesObject-Oriented Software Systems Engineering – Chapter 5 Slide 7
    • 8. Initial and Final States  An example: At Work go home At Home go to work die dieObject-Oriented Software Systems Engineering – Chapter 5 Slide 8
    • 9. Actions and Activities  Action  is an executable atomic computation  includes operation calls, the creation or destruction of another object, or the sending of a signal to an object  associated with transitions and during which an action is not interruptible -- e.g., entry, exit  Activity is associated with states  Non-atomic or ongoing computation  May run to completion or continue indefinitely  Will be terminated by an event that causes a transition from the state in which the activity is definedObject-Oriented Software Systems Engineering – Chapter 5 Slide 9
    • 10. Events  An event signature is described as Event-name (comma-separated-parameter-list)  Events appear in the internal transition compartment of a state or on a transition between states  An event may be one of four types  Signal event  Corresponding to the arrival of an asynchronous message or signal  Call event  Corresponding to the arrival of a procedural call to an operation  Time event  Change eventObject-Oriented Software Systems Engineering – Chapter 5 Slide 10
    • 11. Events  A time event occurs after a specified time has elapsed  Event name is specified as keyword after  Parameter list is an expression evaluating to a time interval  after(10 seconds after state “At Work” is entered)  No specified start time implies “since entry to the current state”  after(2 seconds)Object-Oriented Software Systems Engineering – Chapter 5 Slide 11
    • 12. Events  A change event occurs whenever a specified condition is met  Event name is specified as keyword when  Parameter list is a boolean expression  The event occurs when both of the following conditions are met, irrespective of the order when they happen  The expression evaluates to true  The object is in the required state  For example  when (state = At Work)  when (date = January 1 2007)Object-Oriented Software Systems Engineering – Chapter 5 Slide 12
    • 13. Transitions A transition is drawn as an arrow between states annotated with a transition string  The transition string denotes the event and consequent action  Only one form of arrowhead is used on statecharts  The distinction between call events and signal events must be deducted from elsewhere e.g. an interaction diagram A transition string is described as  Event-signature [guard-condition]/action-expression^object.message  If the guard condition is met the transition occurs immediatelyObject-Oriented Software Systems Engineering – Chapter 5 Slide 13
    • 14. Transitions  A transition whose string contains neither an event signature nor a guard condition is said to be unlabeled  Occurs immediately  May still carry an action expressionObject-Oriented Software Systems Engineering – Chapter 5 Slide 14
    • 15. Transitions  A transition is triggered when its event occurs  If the guard condition is met, the transition is fired  If the condition is not met the event is discarded  The guard condition is checked only once  If there is no guard condition, triggering will always cause firing  Note the distinction between a guard condition and a change event  A guard condition is evaluated once, when the associated event occurs  A change event occurs whenever its associated condition is met  Behaviour is as if the condition were being continually evaluatedObject-Oriented Software Systems Engineering – Chapter 5 Slide 15
    • 16. State Diagrams notationInitial state event final state name Invoice Invoice created paying destroyed Unpaid Paid transition state Object-Oriented Software Systems Engineering – Chapter 5 Slide 16
    • 17. State Diagram Example This shows the state of an object myBkCpy from a BookCopy class on loan return() on the shelf entry / myBkCpy.borrow() entry / myBkCpy.return() borrow() Entry action : any action that is marked as linked to the entry action is executed whenever the given state is entered via a transition on loan return() on the shelf exit / myBkCpy.returned() exit / myBkCpy.borrowed() borrow() Exit action : any action that is marked as linked to the exit action is executed whenever the state is left via a transitionObject-Oriented Software Systems Engineering – Chapter 5 Slide 17
    • 18. A Class of BookCopy BookCopy onShelf : Boolean value := ‘Y’ on the shelf value := ‘N’ on loan return() action / onShelf=‘Y’ borrow() action / onShelf=‘N’Object-Oriented Software Systems Engineering – Chapter 5 Slide 18
    • 19. State Diagram Example get first item all items in stock [all items checked && *[all items checked] all items available] get next item Checking Dispatching Dispatch items do / check Item b le] do / initiate [all items checked aila delivery av d && some items not tems eive in stock] ll i rec [a m delivery Order Item Itesome items Ordering Deliveringnot in stock cancelled Exit/ Item received entry / deliver do / order Item Items Canceling do / Remove ItemObject-Oriented Software Systems Engineering – Chapter 5 Slide 19
    • 20. State Diagram - Nested States event-1 Super-state A B event-1 A Bevent-2 event-2 C event-2 CObject-Oriented Software Systems Engineering – Chapter 5 Slide 20
    • 21. State Diagram Example including substates get first item *[all items checked] [all items checked && all items available] get next item Checking Dispatch items Dispatching do / check do / initiate Item ble] delivery a v ail [all items checked && ms a ved some items not in stock] l ite ecei Order item [al m r delivery Ite Ordering Exit/ Item received do / order Item Canceling Delivering cancelled do / Remove entry / deliver Item ItemsObject-Oriented Software Systems Engineering – Chapter 5 Slide 21
    • 22. Concurrent State models B s Finishing Starting A C E TExplicit controlbranching(fork) D G F  Orthogonal Components and Concurrency  shown separated by dashed line  supports concurrency  Objects must be in only one state from each of the orthogonal components Object-Oriented Software Systems Engineering – Chapter 5 Slide 22
    • 23. Concurrent State Models Three different ways for orthogonal components to communicate:  Broadcast Events  Propogated Events  IN operatorsObject-Oriented Software Systems Engineering – Chapter 5 Slide 23
    • 24. Concurrent State Models  Broadcast events  events that more than one orthogonal component accepts  For example an event T1 is sent to all active orthogonal components it need not be acted on by all components  what happens if component S1 is in state A, S2 is in state E and S3 is in state G when a T1 event occurs?  what happens if S1 is in state A and S2 is in state D when the event T1 occurs?Object-Oriented Software Systems Engineering – Chapter 5 Slide 24
    • 25. Concurrent State Models  Propagated events are indicated with the caret following the event name (and optional parameters and guard)  IN operators are used as a guard on transition T4. This allows the S3 component to take the transition T4 only if S2 is currently in state DObject-Oriented Software Systems Engineering – Chapter 5 Slide 25
    • 26. Concurrent State Models S S1 H S3 T1 B F A T4[IN(D)] C T2^T3(x,y,z) T5 G S2 H T3(a,b,c) T6 H D T3(a,b,c) T1 EObject-Oriented Software Systems Engineering – Chapter 5 Slide 26
    • 27. Summary In this chapter we have:  Introduced the terms used with respect to state diagrams  Discussed the context in which state diagrams are used  Introduced substates  Discussed concurrent state diagramsObject-Oriented Software Systems Engineering – Chapter 5 Slide 27

    ×