OCUP2I State Machines and Use Cases

From Training Material
Jump to navigation Jump to search


<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="false" font="Trebuchet MS" >

title
UML 2.5 Certification - OCUP 2 Intermediate Exam Preparation
author

Filip Stachecki (Filip@NobleProg.pl)

</slideshow>

Module 8. State Machines and Use Cases⌘

References⌘

UML 2.5 specification:

TODO

    • Intervals
  • Chapter 12: Packages
    • Packages
  • Chapter 20: Information Flows

State Machines⌘

  • State machine diagram is a behavior diagram which shows discrete event-driven behavior of a part of designed system through finite state transitions.
  • State machine diagrams can also be used to express the valid interaction sequences (protocols) for parts of a system.
  • Two kinds of state machines:
    • behavior state machine,
    • protocol state machine.

Behavior State Machine⌘

Vertex⌘
  • Vertex is named element which is an abstraction of a node (State or Pseudostate) in a state machine graph.
  • It can be the source or destination of any number of transitions.
State⌘

  • State models a situation during which some invariant condition holds.
  • In most cases this condition is not explicitly defined.
Pseudo State⌘

  • Pseudostate is an abstract vertex that describes different types of transient vertices in the state machine graph.
  • Pseudostates are transitive - a compound transition execution simply passes through them, arriving on an incoming Transition and leaving on an outgoing Transition without pause.
Fork⌘

  • Splits an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State.
  • The Transitions outgoing from a Fork cannot have a guard or a trigger.
Join⌘

  • Common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions.
  • Transitions terminating on a Join cannot have a guard or a trigger.
Terminate ⌘

  • Execution of the State Machine is terminated immediately.
  • The State Machine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are automatically aborted.
Entry Point ⌘

  • Represents an entry point for a State Machine or a composite State that provides encapsulation of the insides of the State or StateMachine.
  • In each Region of the StateMachine or composite State owning the Entry Point, there is at most a single Transition from the entry point to a Vertex within that Region.

If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. If multiple Regions are involved, the entry point acts as a fork Pseudostate.

Exit Point ⌘

  • Represents an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or State Machine.
  • Transitions terminating on an exit point within any Region of the composite State or a State Machine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior).

If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Psuedostate.

Shallow History⌘

  • Represents the most recent active substate of its containing Region, but not the substates of that substate.
  • Transition terminating on this Pseudostate implies restoring the Region to that substate.
  • A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State.
  • Shallow History can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State.
Deep History⌘

  • Represents the most recent active state configuration of its owning Region.
  • Transition terminating on this Pseudostate implies restoring the Region to that same state configuration.
  • The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State.
  • Deep History Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State.

Protocol State Machine⌘

  • Is always defined in the context of a classifier.
  • Specify allowed invocation sequences (lifecycle of a classifier).
  • Describes which operations of the classifier can be called in which state and under which condition.
Protocol State⌘
  • A protocol State represents an exposed stable situation of its context Classifier.
  • The States of a ProtocolStateMachine cannot have defined entry, exit, or doActivity actions.
Protocol Transition⌘

  • A Protocol Transition specifies a legal Transition for an operation of the context Classifier.
  • Syntax: [precondition] event / [postcondition]

Events⌘

based on 13.3 Events

Time Events⌘
 <time-event> ::= <relative-time-event> | <absolute-time-event>
 <relative-time-event> ::= ‘after’ <time-expression>
 <absolute-time-event> ::= ‘at’ <time-expression>
  • examples
after 5 seconds
at midnight
at Jan. 1, 2020, 14:34  NOT  when Jan. 1, 2020, 14:34

Use Cases⌘

The Subject and the Owner⌘

  • A Use Case may be owned either by a Package or by a Classifier.
  • The owning Classifier typically represents a subject to which the owned Use Cases apply, but this is not necessarily the case.
  • Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model
  • A Use Case may apply to any number of subjects.
Use Case owned by a Classifier⌘

  • The nesting (owning) of a UseCase by a Classifier may optionally be represented by nesting the Use Case ellipse inside the Classifier rectangle in a separate compartment.
Use Cases owned by Packages⌘

Retrieved from "https://training-course-material.com/index.php?title=OCUP2I_State_Machines_and_Use_Cases&oldid=44556"