State machine diagram |
The behavior of an entity is not only a direct consequence of its input, but it also depends on its preceding state. The history of an entity can best be modeled by a finite state diagram. State Machine diagram can show the different states of an entity also how an entity responds to various events by changing from one state to another. |
|
Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram |
|
|
|
State machine diagram |
|
|
|
|
Constraint | | | | Definition | A condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element. | | | Properties | | Name | The name of constraint. It is optional and is commonly omitted. | Expression | The condition that must be true when evaluated in order for the constraint to be satisfied. | Documentation | Description of constraint. | | | | |
|
Choice | | | | Definition | choice vertices which, when reached, result in the dynamic evaluation of the guards of the triggers of its outgoing transitions. This realizes a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same runto-completion step. If more than one of the guards evaluates to true, an arbitrary one is selected. If none of the guards evaluates to true, then the model is considered ill-formed. (To avoid this, it is recommended to define one outgoing transition with the predefined 'else' guard for every choice vertex.) Choice vertices should be distinguished from static branch points that are based on junction points. | | | Properties | | Name | The name of choice. | Visibility | Determines where the choice appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of choice. | | | | |
|
Deep History | | | | Definition | deepHistory represents the most recent active configuration of the composite state that directly contains this pseudostate (e.g., the state configuration that was active when the composite state was last exited). A composite state can have at most one deep history vertex. At most one transition may originate from the history connector to the default deep history state. This transition is taken in case the composite state had never been active before. Entry actions of states entered on the path to the state represented by a deep history are performed. | | | Properties | | Name | The name of deep history. | Visibility | Determines where the deep history appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of deep history. | | | | |
|
Entry Point | | | | Definition | An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region. | | | Properties | | Name | The name of entry point. | Visibility | Determines where the entry point appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of entry point. | | | | |
|
Exit Point | | | | Definition | An exit point pseudostate is an exit point of a state machine or composite state. Entering an exit point within any region of the composite state or state machine referenced by a submachine state implies the exit of this composite state or submachine state and the triggering of the transition that has this exit point as source in the state machine enclosing the submachine or composite state. | | | Properties | | Name | The name of exit point. | Visibility | Determines where the exit point appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of exit point. | | | | |
|
Fork | | | | Definition | fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices (i.e., vertices in different regions of a composite state). The segments outgoing from a fork vertex must not have guards or triggers. | | | Properties | | Name | The name of fork. | Visibility | Determines where the fork appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of fork. | | | | |
|
Final State | | | | Definition | A special kind of state signifying that the enclosing region is completed. If the enclosing region is directly contained in a state machine and all other regions in the state machine also are completed, then it means that the entire state machine is completed. | | | Properties | | Name | The name of final state. | State invariant | Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions. | Redefined state | The state of which this state is a redefinition. | Documentation | Description of final state. | Deferrable Triggers | A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred. | | | | |
|
Initial Pseudo State | | | | Definition | An initial pseudostate represents a default vertex that is the source for a single transition to the default state of a composite state. There can be at most one initial vertex in a region. The outgoing transition from the initial vertex may have a behavior, but not a trigger or guard. | | | Properties | | Name | The name of initial pseudo state. | Visibility | Determines where the initial pseudo state appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of initial pseudo state. | | | | |
|
Join | | | | Definition | join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The transitions entering a join vertex cannot have guards or triggers. | | | Properties | | Name | The name of join. | Visibility | Determines where the join appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of join. | | | | |
|
Junction | | | | Definition | junction vertices are semantic-free vertices that are used to chain together multiple transitions. They are used to construct compound transition paths between states. For example, a junction can be used to converge multiple incoming transitions into a single outgoing transition representing a shared transition path (this is known as a merge). Conversely, they can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. This realizes a static conditional branch. (In the latter case, outgoing transitions whose guard conditions evaluate to false are disabled. A predefined guard denoted "else" may be defined for at most one outgoing transition. This transition is enabled if all the guards labeling the other transitions are false.) Static conditional branches are distinct from dynamic conditional branches that are realized by choice vertices. | | | Properties | | Name | The name of junction. | Visibility | Determines where the junction appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of junction. | | | | |
|
Note | | | | Definition | A note (comment) gives the ability to attach various remarks to elements. A comment carries no semantic force, but may contain information that is useful to a modeler. | | | Properties | | Name | The name of note. | Documentation | Specifies a string that is the comment. | | | | |
|
Shallow History | | | | Definition | shallowHistory represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have at most one shallow history vertex. A transition coming into the shallow history vertex is equivalent to a transition coming into the most recent active substate of a state. At most one transition may originate from the history connector to the default shallow history state. This transition is taken in case the composite state had never been active before. Entry actions of states entered on the path to the state represented by a shallow history are performed. | | | Properties | | Name | The name of shallow history. | Visibility | Determines where the shallow history appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of shallow history. | | | | |
|
State | | | | Definition | A state models a situation during which some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event to occur. However, it can also model dynamic conditions such as the process of performing some behavior (i.e., the model element under consideration enters the state when the behavior commences and leaves it as soon as the behavior is completed). | | | Properties | | Name | The name of state. | Entry | An optional behavior that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal behavior or transitions performed within the state. | Exit | An optional behavior that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution. | Do activity | An optional behavior that is executed while being in the state. The execution starts when this state is entered, and stops either by itself or when the state is exited whichever comes first. | State invariant | Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions. | Redefined state | The state of which this state is a redefinition. | Documentation | Description of state. | Regions | A region is an orthogonal part of either a composite state or a state machine. It contains states and transitions. | Deferrable Triggers | A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred. | | | | |
|
Submachine State | | | | Definition | A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. The regions of the submachine state machine are the regions of the composite state. The entry, exit, and behavior actions and internal transitions are defined as part of the state. Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse. | | | Properties | | Name | The name of state. | Submachine | The state machine that is to be inserted in place of the (submachine) state. | Entry | An optional behavior that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal behavior or transitions performed within the state. | Exit | An optional behavior that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution. | Do activity | An optional behavior that is executed while being in the state. The execution starts when this state is entered, and stops either by itself or when the state is exited whichever comes first. | State invariant | Specifies conditions that are always true when this state is the current state. In protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions. | Redefined state | The state of which this state is a redefinition. | Documentation | Description of submachine state. | Deferrable Triggers | A list of triggers that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). A deferred trigger is retained until the state machine reaches a state configuration where it is no longer deferred. | | | | |
|
Terminate | | | | Definition | Entering a terminate pseudostate implies that the execution of this state machine by means of its context object is terminated. The state machine does not exit any states nor does it perform any exit actions other than those associated with the transition leading to the terminate pseudostate. Entering a terminate pseudostate is equivalent to invoking a DestroyObjectAction. | | | Properties | | Name | The name of terminate. | Visibility | Determines where the terminate appears within different Namespaces within the overall model, and its accessibility. | Documentation | Description of terminate. | | | | |
|
Transition | | | | Definition | A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to an occurrence of an event of a particular type. | | | Properties | | Name | The name of transition. | Source | Designates the originating vertex (state or pseudostate) of the transition. | Target | Designates the target vertex that is reached when the transition is taken. | Kind | TransitionKind is an enumeration of the following literal values: external, internal, local. | Effect | Specifies an optional behavior to be performed when the transition fires. | Redefined transition | The transition of which this is a replacement. | Guard | A guard is a constraint that provides a fine-grained control over the firing of the transition. The guard is evaluated when an event occurrence is dispatched by the state machine. If the guard is true at that time, the transition may be enabled; otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed. | Documentation | Description of transition. | Triggers | Specifies the triggers that may fire the transition. | | | | |
|
Definition of notations is quoted from Object Management Group Unified Modeling Language (OMG UML) Superstructure Version 2.2 and former versions (for notations that do not exist anymore in latest specification). |
|
Use case diagram | Class diagram | Sequence diagram | Communication diagram | State machine diagram | Activity diagram | Component diagram | Deployment diagram | Package diagram | Object diagram | Composite structure diagram | Timing diagram | Interaction overview diagram |
Posting Komentar untuk "Uml State Diagram Visual Paradigm"