Your SlideShare is downloading. ×
0
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
5. state diagrams
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

2,262

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,262
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
72
Comments
0
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

    ×