Composite state entry and exit points

Gallery
Tutorial
TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo
Section
01:03: UML Behavior: StateMachines quick start
Topic level
ESSENTIAL
UML keywords
StateMachine
StateMachine Diagram
State
Transition
Transition::effect
State::entry
State::exit
State::doActivity
Activity
Behavior
composite State
State::/isComposite
PseudostateKind::exitPoint
PseudostateKind::entryPoint
compound transition
default entry rule
PseudostateKind::fork
Keywords
Slide kind
UML StateMachine Diagram
NOTATION REFERENCE ONLY: This diagram is not meant to be executable!
The absence of explicit triggers or guards on Transition symbols in this diagram is for brevity only and does not imply completion Transitions with implicit triggers.
Click on the image to view it full size
The diagram here excludes shallow and deep histories, see however the next slide.
Up next
Submachines: entryPoint and exitPoint
Notes
[TOOL, WARNING]{INFORMATIVE} MagicDraw/Cameo: GOTCHA: ‘entry’, ‘exit’, ‘doActivity’ are all subsets of ‘ownedElement’; to use an existing Activity without changing its owner you need to create a “wrapper” Activity. Beware the tool does not simply move your Activity!
Snippets (quotes/extracts)
  [UML-2.5.1] When exiting a State, regardless of whether it is simple or composite, the final step involved in the exit, after all other Behaviors associated with the exit are completed, is the execution of the exit Behavior of that State.
  [UML-2.5.1] If the State has a doActivity Behavior that is still executing when the State is exited, that Behavior is aborted before the exit Behavior commences execution.
  [UML-2.5.1] When exiting from a composite State, exit commences with the innermost State in the active state configuration. This means that exit Behaviors are executed in sequence starting with the innermost active State.
  [UML-2.5.1] If the exit occurs through an exitPoint Pseudostate, then the exit Behavior of the State is executed after the effect Behavior of the Transition terminating on the exit point.
  [UML-2.5.1] When exiting from an orthogonal State, each of its Regions is exited. After that, the exit Behavior of the State is executed.
  [UML-2.5.1] Regardless of how a State is exited, the StateMachine is deemed to have “left” that State only after the exit Behavior (if defined) of that State has completed execution.
  [UML-2.5.1] A State may have an associated entry Behavior. This Behavior, if defined, is executed whenever the State is entered through an external Transition.
  [UML-2.5.1] In addition, a State may also have an associated exit Behavior, which, if defined, is executed whenever the State is exited.
  [UML-2.5.1] A State may also have an associated doActivity Behavior. This Behavior commences execution when the State is entered (but only after the State entry Behavior has completed) and executes concurrently with any other Behaviors that may be associated ...
  [UML-2.5.1] ... if a doActivity Behavior is defined for the State, this Behavior commences execution immediately after the entry Behavior is executed. It executes concurrently with any subsequent Behaviors associated with entering the State, such as the entry ...
  [UML-2.5.1] If the composite State is also an orthogonal State with multiple Regions, each of its Regions is also entered, either by default or explicitly.
  [UML-2.5.1] If the Transition terminates on the edge of the composite State (i.e., without entering the State), then all the Regions are entered using the default entry rule above.
  [UML-2.5.1] If the Transition explicitly enters one or more Regions (in case of a fork), these Regions are entered explicitly and the others by default.
  [UML-2.5.1] Regardless of how a State is entered, the StateMachine is deemed to be “in” that State even before any entry Behavior or effect Behavior (if defined) of that State start executing.
Visit also
HOWTO simulate UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit - Operation-driven Transition case study
Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: StateMachine with entry Activity and Transition guard
Screencast: Mini tutorial: UML/SysML: Cameo Simulation Toolkit: StateMachine with doActivity and a Transition with a ChangeEvent trigger
Screencast: Tutorial: UML/SysML: StateMachines vs Activities: Operation-driven Transition case study - UML-2.5.1 'Figure 14.7 Composite State with two States' in Cameo Simulation Toolkit
StateMachine diagram for comparing action language access to an operation for a guard
Visit also (backlinks)
Related slides (includes other tutorials)
UML2 StateMachine - metaclasses - ADVANCED REFERENCE ONLY
StateMachine diagram for comparing action language access to an operation for a guard
Overview: Controller class (and its Activity), Dialer Class (and its StateMachine), Number class
StateMachine for the Dialer class
Behavior StateMachines can be used to specify any of the following
The number.append Activity as entry Behavior for the PartialDial State
The number.print Activity as exit Behavior for the PartialDial State
Figure D.8 - Finite State Machine Associated with “Drive the Vehicle”
Figure 13-1: Block definition diagram with state machines as blocks associated with submachines and types of parameters
Related slides (backlinks, includes other tutorials)