CS3773 Software Engineering Lecture 06 UML State Machines
UTSA CS 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 CS 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 CS State Diagram – An Example
UTSA CS 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 CS 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 CS Transition Elements of a transition – event(s) – [condition] – /activities Each of these parts is optional Form
UTSA CS 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 CS 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 CS 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 CS 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 CS 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 CS 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 CS State Activities In a transition, the order of effects: – Exit activities of source – Transition activities – Entry activities of destination, and – State activities
UTSA CS 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 CS 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 CS 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 CS Summary on State and Transition
UTSA CS 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 CS State Diagram Without Composite State
UTSA CS State Diagram with Composite State
UTSA CS 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 CS Orthogonal State – An Example
UTSA CS 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 CS 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 CS 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 CS 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 CS History State – An Example
UTSA CS 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 CS 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 CS Reading Assignments UML and The Unified Process – Chapter 21, “Basic state machines” – Chapter 22, “Advanced state machines”