CS3773 Software Engineering Lecture 06 UML State Machines.
-
Upload
hilda-richardson -
Category
Documents
-
view
222 -
download
0
Transcript of CS3773 Software Engineering Lecture 06 UML State Machines.
CS3773 Software Engineering
Lecture 06UML State Machines
2 UTSA CS3773
State Diagram
Recall the delays in a sequence diagram, between when an object receives a message and when it outputs another message
State diagram shows what the object does in between the receiving and the sending of messages
Show the behavior of an object across several use cases
One state diagram per class to describes possible behavior for each instance of the class
UTSA CS37733
State Diagram
State diagram shows how a system or an object's behavior changes over time depending on the input, rather than represent end-to-end behavior
Shows how a system or an object reacts to messages received
– Which state the object shall go to– When it outputs messages to other objects– How an object changes the values of its attributes by
assignments
UTSA CS37734
State Diagram – An Example
UTSA CS37735
State Diagram
Elements of a state diagram – State represents the mode of the system
Always an initial state (starting state)
Sometimes a final state– Transition describes a change in state due to the
occurrence of an event
From one state to another state
UTSA CS37736
State
Partitions object behavior
e.g., not being able to check out a borrowed book Represents the history of inputs so far Affects what input the object will react to
e.g., ignoring most input in the state “lost” Is an assignment to a collection of attributes
UTSA CS37737
Transition
Elements of a transition– event(s)– [condition]– /activities
Each of these parts is optional Form
srcevent [cond]/activity
dest
UTSA CS37738
Event
An event triggers the transition– A change in the environment
e.g., offHook– A message from another object (operation call)– A change in a condition: going from “false” to “true”
e.g., when(temperature > 100 degrees– An occurrence of a specific date/time or passage of time
e.g., after (20 minutes)
UTSA CS37739
Event
An event occurs instantaneously and it doesn’t persist Events make an object change state If the object is in a state and there is no outgoing
transition triggered by an event, the event is ignored Multiple events on a transition label are ORed
together
UTSA CS377310
Condition
A condition is a Boolean expression The value of a condition persists until the variables
involved in the condition change their values The transition cannot fire unless the guard condition is
“true”, Examples
– x > 10 – patronHasNoOverdueFine
UTSA CS377311
Activity
An activity is what an object does in response to events An activity is simple, fast, non-interruptible Most common activities are
– variable assignment– send a message to an object
Multiple activities on a transition are separated by “;” and executed sequentially
UTSA CS377312
State Activities
A state can have activities associated with it Two types of state activities can manipulate object
attributes or other variables– Activity: simple, non-interruptible
Associated with a transition or a state Performed on state entry or exit or event
– Do activity: interruptible; may require much computation Associated with a state Interrupted by a transition
UTSA CS377313
State Activities
States can be annotated with entry or exit activities, internal activities, and do activities:
entry/activity event/activity (way to describe reactions to events
that don't cause a state change -- internal transitions) exit/activity do/activity
UTSA CS377314
State Activities
In a transition, the order of effects: – Exit activities of source– Transition activities– Entry activities of destination, and– State activities
UTSA CS377315
Self-Transition
A self-transition will cause reactivation of exit and then entry events
If you want a self-transition that does not activate these events, you can use an internal transition, labeled with the event and the associated activity
e.g., “req/reply” in state “S”
UTSA CS377316
Self-Transition
Compared to an activity on a transition, one could achieve the same behavior
– as activity in state– as activity in another, special state
UTSA CS377317
More on Transition
If a transition has no event label, it can occur once any activity associated with the state is complete
Guards on transitions (triggered by the same event) leaving a state should be mutually exclusive
UTSA CS377318
Summary on State and Transition
State Name____________
Entry/activityExit/activity
Event/activitydo/activity
State Nameevent1 [condition] / activity1; activity2
UTSA CS377319
State Hierarchy
Composite state: a state can contain other states Composite combines states and transitions that work
together towards a common goal If a transition leaves a composite state, this transition
applies to all the sub-states The sub-states “inherit” the transitions of the
composite state Basic state: a state do not contain other states
UTSA CS377320
State Diagram Without Composite State
UTSA CS377321
State Diagram with Composite State
UTSA CS377322
Orthogonal Composite State
An orthogonal state captures two or more behaviors of the object that happen concurrently each with its own control thread
If there are many orthogonal states for one object, you should consider dividing the behavior between more objects
UTSA CS377323
Orthogonal State – An Example
UTSA CS377324
Types of Orthogonal States
Aggregation concurrency– State diagram for an aggregate object is a collection of
state diagrams, each of which corresponds to a constituent object
Synchronization of concurrent activities within one object
– Object performs two or more activities concurrently– Object completes both activities before it progress to
anther state
UTSA CS377325
History
History is a mechanism by which a re-entered composite state can continue executing from the sub-state that was current when control last transitioned out of the composite state
Deep history Shallow history
UTSA CS377326
History
History is a pseudostate whose meaning is to designate the immediate sub-states at this level in the hierarchy that system was in when the immediate parent state was last exited
History state can be the destination state of a transition
A transition leaving a history state indicates what sub-states to enter if the system has ever been in this state
Syntax
H
UTSA CS377327
Deep History
Apply history at all levels in the hierarchy below the history pseudostate
Enter the sub-states that an object was last in when the state was exited
Syntax H*
UTSA CS377328
History State – An Example
UTSA CS377329
Process for Making State Diagram
Decide what the states of an object are Determine what transitions can move the system
from states to states Represent effect of the execution of a transition
– Variable value changes– State changes– Messages sent
UTSA CS377330
Validation of State Diagram
Consistency: multiple transitions leave same state under the same event should have mutually exclusive conditions
Problem in hierarchical state machine Completeness: all possible inputs should be
considered Compatibleness: state diagrams have the same
behavior with the sequence diagrams
UTSA CS377331
Reading Assignments
UML and The Unified Process– Chapter 21, “Basic state machines”– Chapter 22, “Advanced state machines”