`

Statechart diagram

 
阅读更多


A statechart diagram shows the sequences of states that an object or an interaction goes through during its life in response to received stimuli, together with its responses and actions.

The semantics and notation described in this chapter are substantially those of David Harel's statecharts with modifications to make them object-oriented. His work was a major advance on the traditional flat state machines. Statechart notation also implements aspects of both Moore machines and Mealy machines, traditional state machine models.

 

Statechart diagram

Semantics

A state machine is a graph of states and transitions that describes the response of an object of a given class to the receipt of outside stimuli. A state machine is attached to a class or a method

Notation

A statechart diagram represents a state machine. The states are represented by state symbols and the transitions are represented by arrows connecting the state symbols. States may also contain subdiagrams by physical containment and tiling.

Mapping

A statechart diagram maps into a StateMachine. That StateMachine may be attached to a Class or a Method but there is no explicit notation for this.

 

States

Semantics

A state is a condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. An object remains in a state for a finite (non-instantaneous) time.

Actions are atomic and non-interruptible. A state may correspond to ongoing activity. Such activity is expressed as a nested state machine. Alternately, ongoing activity may be represented by a pair of actions, one that starts the activity on entry to the state and one that terminates the activity on exit from the state.

Each subregion of a state may have initial states and final states. A transition to the enclosing state represents a transition to the initial state. A transition to a final state represents the completion of activity in the enclosing region; completion of activity in all concurrent regions represents completion of activity by the enclosing state and triggers a ''completion of activity'' event'' on the enclosing state. Completion of the outermost state of an object corresponds to its death.

Notation

A state is shown as a rectangle with rounded corners. It may have one or more compartments. The compartments are all optional. They are as follows:

Name compartment. Holds the (optional) name of the state as a string. States without names are ''anonymous'' and are all distinct. It is undesirable to show the same named state twice in the same diagram, however, as confusion may ensue.

Internal transition compartment. Holds a list of internal actions or activities performed in response to events received while the object is in the state, without changing state. These have the format:

 

event-name argument-list '[' guard-condition ']' '/' action-expression

Each event name or pseudo-event name may appear at most once in a single state.

The following special actions have the same form but represent reserved words that cannot be used for event names:

 

'entry' '/' action-expression An atomic action performed on entry to the state

 

'exit' '/' action-expression An atomic action performed on exit from the state

 

Entry and exit actions may not have arguments or guard conditions (because they are invoked implicitly, not explicitly). However, the entry action at the top level of the state machine for a class may have parameters that represent the arguments that it receives when it is created.

 

Action expressions may use attributes and links of the owning object and parameters of incoming transitions (if they appear on all incoming transitions).

The following keyword represents the invocation of a nested state machine:

 

'do' '/' machine-name (argument-list)

 

The machine-name must be the name of a state machine that has an initial and final state. If the nested machine has parameters, then the argument list must match correctly. When this state is entered, after any entry action then execution of the nested state machine begins with its initial state. When the nested state machine reaches its final state, then any exit action in the current state is performed and the current state is considered completed and may take a transition based on implicit completion of activity.

Example

Mapping

A state symbol maps into a State. See the next section for further details on which kind of state.

The name string in the symbol maps to the name of the state. Two symbols with the same name map into the same state. However, each state symbol with no name (or an empty name string) maps into a distinct anonymous State.

An internal action string with the name ''entry'' or ''exit'' maps into an association: the source is the State corresponding to the enclosing state symbol; the target is an ActionSequence that maps the action expression; the association is the Entry action or the Exit action association.

An internal action string with the name ''do'' maps into the invocation of a nested state machine.

Any other internal action maps into an internal Association from the corresponding State to a Transition. The action expression maps into the ActionSequence and Guard for the Transition. The event name and arguments map into an Event corresponding to the event name and arguments; the Transition has a trigger Association to the Event.

Composite states

Semantics

A state can be decomposed using and-relationships into concurrent substates or using or-relationships into mutually exclusive disjoint substates. A given state may only be refined in one of these two ways. Its substates can may be refined in the same way or the other way.

A newly-created object starts in its initial state. The event that creates the object may be used to trigger a transition from the initial state symbol.

An object that transitions to its outermost final state ceases to exist.

Notation

An expansion of a state shows its fine structure. In addition to the (optional) name and internal transition compartments, the state may have an additional compartment that contains a region holding a nested diagram. For convenience and appearance, the text compartments may be shrunk horizontally within the graphic region.

An expansion of a state into concurrent substates is shown by tiling the graphic region of the state using dashed lines to divide it into subregions. Each subregion is a concurrent substate. Each subregion may have an optional name and must contain a nested state diagram with disjoint states. The text compartments of the entire state are separated from the concurrent substates by a solid line.

An expansion of a state into disjoint substates is shown by showing a nested state diagram within the graphic region.

An initial (pseudo)state is shown as a small solid filled circle. In a top-level state machine, the transition from an initial state may be labeled with the event that creates the object; otherwise it must be unlabeled. If it is unlabeled, it represents any transition to the enclosing state. The initial transition may have an action. The initial state is a notational device; an object may not be in such a state but must transition to an actual state.

A final (pseudo)state is shown as a circle surrounding a small solid filled circle (a bull's eye). It represents the completion of activity in the enclosing state and it triggers a transition on the enclosing state labeled by the implicit activity completion event (usually displayed as an unlabeled transition).

Example

Mapping

A state symbol maps into a State. If the symbol has no subdiagrams in it, it maps into a SimpleState; if it is tiled by dashed lines into subregions then it maps into a CompositeState with the isConcurrent value true, otherwise it maps into a CompositeState with the isConcurrent value false.

An initial state symbol or a final state symbol map into a Pseudostate of kind initial or final.

 

Events

Semantics

An event is a noteworthy occurrence. For practical purposes in state diagrams, it is an occurrence that may trigger a state transition. Events may be of several kinds (not necessarily mutually exclusive):

 

a designated condition becoming true (usually described as a boolean expression). This is a ChangeEvent. These are notated with the keyword when followed by a boolean expression in parentheses. The event occurs whenever the value of the expression changes from false to true. Note that this is different from a guard condition: A guard condition is evaluated once whenever its event fires; if it is false then the transition does not occur and the event is lost. Example: when (balance < 0).

 

receipt of an explicit signal from one object to another. This is a SignalEvent. One of these is notated by the signature of the event as a trigger on a transition.

 

receipt of a call for an operation by an object. This is a CallEvent. These are notated by the signature of the operation as a trigger on a transitions. There is no visual difference from a signal event; it is assumed that the names with distinguish them.

 

passage of a designated period of time after a designated event (often the entry of the current state) or the occurrence of a given date/time. This is a TimeEvent. These are notated as time expressions as triggers on transitions. One common time expression is the passage of time since the entry to the current state; this is notated with the keyword after followed by an amount of time in parentheses. Example: after (10 seconds).

The event declaration has scope within the package it appears in and may be used in state diagrams for classes that have visibility inside the package. An event is not local to a single class.

Notation

A signal or call event can be defined using the following format:

 

event-name '(' comma-separated-parameter-list ')'

A parameter has the format:

 

parameter-name ':' type-expression

A signal can be declared using the «signal» keyword on a class symbol in a class diagram. The parameters are specified as attributes. A signal can be specified as a subclass of another signal. This indicates that an occurrence of the subevent triggers any transition that depends on the event or any of its ancestors.

An elapsed-time event can be specified with the keyword after followed by an expression that evaluates (at modeling time) to an amount of time, such as ''after (5 seconds)'' or after (10 seconds since exit from state A)''. If no starting point is indicated, then it is the time since the entry to the current state. Other time events can be specified as conditions, such as when (date = Jan. 1, 2000).

A condition becoming true is shown with the keyword when followed by a boolean expression. This may be regarded as a continuous test for the condition until it is true, although in practice it would only be checked on a change of values (and there are ways to determine when it must be check). This is mapped into a ChangeEvent in the model.

Signals can be declared on a class diagram with the keyword «signal» on a rectangle symbol. These define signal names that may be used to trigger transitions. Their parameters are shown in the attribute compartment. They have no operations. They may appear in a generalization hierarchy. Note that they are not real classes and may not appear in relationships to real classes.

Example

Mapping

A class box with stereotype «signal» maps into a Signal; the name and parameters are given by the name string and the attribute list of the box. Generalization arrows between signal class boxes map into Generalization relationships between the Signal.

The usage of an event string expression in a context requiring an event maps into an implicit reference of the Event with the given name. It is an error if various uses of the same name (including any explicit declarations) do not match.

 

Simple transitions

Semantics

A simple transition is a relationship between two states indicating that an object in the first state will enter the second state and perform certain specified actions when a specified event occurs if specified conditions are satisfied. On such a change of state the transition is said to ''fire''. The trigger for a transition is the occurrence of the event labeling the transition. The event may have parameters, which are available within actions specified on the transition or within actions initiated in the subsequent state. Events are processed one at a time. If an event does not trigger any transition, it is simply ignored. If it triggers more than one transition within the same sequential region (i.e., not in different concurrent regions), only one will fire; the choice may be nondeterministic if a firing priority is not specified.

Notation

A transition is shown as a solid arrow from one state (the source state) to another state (the target state) labeled by a transition string. The string has the following format:

 

event-signature '[' guard-condition ']' '/' action-expression '^' send-clause

The event-signature describes an event with its arguments:

 

event-name '(' parameter ',' . . . ')'

The guard-condition is a Boolean expression written in terms of parameters of the triggering event and attributes and links of the object that owns the state machine. The guard condition may also involve tests of concurrent states of the current machine (or explicitly designated states of some reachable object); for example, ''in State1'' or ''not in State2''. State names may be fully qualified by the nested states that contain them, yielding path names of the form ''State1::State2::State3''; this may be used in case same state name occurs in different composite state regions of the overall machine.

The action-expression is a procedural expression that is executed if and when the transition fires. It may be written in terms of operations, attributes, and links of the owning object and the parameters of the triggering event. The action-clause must be an atomic operation, that is, it may not be interruptible; it must be executed entirely before any other actions are considered. The transition may contain more than one action clause (with delimiter).

'The send-clause is a special case of an action, with the format:

 

destination-expression '.' destination-message-name '(' argument '.' . . . ')'

The transition may contain more than one send clause (with delimiter). The relative order of action clauses and send clauses is significant and determines their execution order.

The destination-expression is an expression that evaluates to an object or a set of objects.

The destination-message-name is the name of a message (operation or signal) meaningful to the destination object(s).

The destination-expression and the arguments may be written in terms of the parameters of the triggering event and the attributes and links of the owning object.

Branches. A simple transition may be extended to include a tree of decision symbols (see Decisions). This is equivalent to a set of individual transitions, one for each path through the tree, whose guard condition is the ''and'' of all of the conditions along the path.

Transition times. Names may be placed on transitions to designate the times at which they fire. See the section on Transition Times.

Example

right-mouse-down (location) [location in window] / object := pick-object (location)
^ object.highlight ()

The event may be of any of the types; selecting the type depends on the syntax of the name (for time events, for example) but SignalEvents and CallEvents are not distinguishable by syntax and must be discriminated by their declaration elsewhere.

Mapping

A transition string and the transition arrow that it labels together map into a Transition and its attachments. The arrow connects two state symbols; the Transition has the corresponding States as its source (the state at the tail) and destination (the state at the head) States in associations to the Transition.

The event name and parameters map into an Event element, which may be a Signal-Event, a CallEvent, or a TimeExpression (if it has the proper syntax). The event is attached as a trigger Association to the Transition.

The guard condition maps into a Guard element attached to the Transition.

An action expression maps into an ActionSequence attached as an effect Association to the Transition; the target object expression (if any) in the expression maps into a target ObjectSetExpression. Each term in the action expression maps into an Action that is a part of the ActionSequence. A send clause maps into a RaiseAction with an ObjectSetExpression for the destination.

A transition time label on a transition maps into a TimingMark attached to the Transition.

 

Complex transitions

A complex transition may have multiple source states and target states. It represents a synchronization and/or a splitting of control into concurrent threads without concurrent substates.

Semantics

A complex transition is enabled when all of the source states are occupied. After a complex transition fires all of its destination states are occupied.

Notation

A complex transition is shown as a short heavy bar (a synchronization bar, which can represent synchronization, forking, or both). The bar may have one or more solid arrows from states to the bar (these are the source states); the bar may have one or more solid arrows from the bar to states (these are the destination states). A transition string may be shown near the bar. Individual arrows do not have their own transition strings.

Example

Mapping

A bar with multiple transition arrows leaving it maps into a fork Pseudostate; a bar with multiple transition arrows entering it maps into a join Pseudostate. The Transitions corresponding to the incoming and outgoing arrows attach to the pseudostate as if it were a regular state. If a bar has multiple incoming and multiple outgoing arrows, then it maps into a Join connected to a Fork pseudostate by a single Transition with no attachments.

评论

相关推荐

    网络讲坛:LabVIEW状态图(Statechart)(下).rar

    网络讲坛:LabVIEW状态图(Statechart)(下)rar,工程师将通过几个实际程序案例为您展示Statechart与状态机的区别,以及在并发、包含及历史保存这三部分中,Statechart是如何只是通过直观的设计方式就能帮助您轻松完成的...

    软件工程 课程设计

    4、熟悉UML,主要了解UML中的9大图:Use case diagram(用例图)、Class diagram(类图)、Object diagram(对象图,Rose中没有)、Sequence diagram(序列图)、Collaboration diagram(协作图)、Statechart diagram(状态图)...

    设计模式课程作业.zip

    UML定义了九种模型图:用例图(Use Case View)、类图(Class Diagram)、对象图(Object Diagram)、构件图(Component Diagram)、部署图(Deployment Diagram)、状态图(StateChart Diagram)、活动图(Activity...

    软件工程实验1.docx

    * 绘制状态图:状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为,显示了该实体如何根据当前所处的状态对不同的事件做出反应。 三、实验过程 * 绘制用例图:在 UML 用例中拖入系统边界、参与者和 ...

    软件工程上机实习作业人事管理系统rose做的

    6. 状态图(Statechart Diagram),描述系统的状态变化 7. 活动图(Activity Diagram),描述系统的活动过程 8. 组件图(Component Diagram),描述系统的组件结构 9. 配置图(Deployment Diagram),描述系统的配置...

    UML_面向对象模型PowerDesigner.docx

    * 状态图(Statechart Diagram):描述类的对象所有可能的状态以及事件触发的状态转移条件 * 顺序图(Sequence Diagram):显示对象之间的动态合作关系 * 协作图(Collaboration Diagram):强调对象间的动态协作...

    用rose建立活动图和状态图

    其中,活动图(Activity Diagram)和状态图(Statechart Diagram)是UML中的两种重要图形表示方式。活动图主要用于描述业务流程或工作流;状态图则用于描述对象在其生命周期内的行为,包括对象的状态及其转换。本实验...

    使用RationalRose进行UML可视化建模.doc

    在RationalRose中,我们可以使用Statechart Diagram来创建状态图,定义系统的状态转换过程。例如,在《在线选修课程管理系统》中,我们可以创建一个状态图,描述系统的选修课程目录表的状态转换过程。 十一、 构件...

    1BusinessProcessModelingBPM业务流程建模.doc

    3. 状态图(Statechart Diagram)描绘了类的状态随时间和事件变化的情况,反映了类的行为。每个状态代表对象可能存在的一个条件,状态之间的转换则表示了行为的变化。 在IDEner创意孵化项目中,使用BPM和UML进行...

    UML_讲义

    这些图表只是UML的一部分,还有其他如协作图(Collaboration Diagram)、状态图(Statechart Diagram)、类图(Class Diagram)、组件图(Component Diagram)和部署图(Deployment Diagram)等,分别从不同的层面和...

    实验二 系统建模--交互图与行为图.docx

    行为图则是另一种描述系统动态行为的工具,分为状态图(Statechart Diagram)和活动图(Activity Diagram)。状态图关注对象在其生命周期内状态的变化,例如,教师查看学生成绩的场景中,教师可能处于等待信息、接收...

    uml建模语言ppt

    6. **状态图(Statechart Diagram)**:表示单个对象在其生命周期中的状态变化和事件触发的转移。 7. **活动图(Activity Diagram)**:类似于流程图,表示工作流或业务流程,强调控制流和并发。 8. **组件图...

    powerdesigner_OO

    - 状态机图(Statechart Diagram):用于描述对象在不同状态间的转换。 - 活动图(Activity Diagram):类似于流程图,表示业务流程或用例的控制流。 3. 实现图表: - 组件图(Component Diagram):描绘软件系统的...

    UML面向对象编程语言

    3. **状态图(Statechart Diagram)**:状态图展示了对象随时间变化的状态和状态之间的转换,它用于描述对象如何响应特定事件并执行相应的操作。 4. **时序图(Sequence Diagram)**:时序图强调消息的时间顺序,描绘...

    很好的UML 读书笔记

    5. **状态图(Statechart Diagram)**:状态图描绘了一个对象在其生命周期中可能经历的状态以及状态间的转换,通常用于描述单个对象的行为。 6. **活动图(Activity Diagram)**:活动图类似于流程图,它描述了满足用例...

    ArgoUML-0.30-setup

    6. **状态图 (Statechart Diagram)**:描述对象在其生命周期内的状态变化和响应事件的行为。 7. **活动图 (Activity Diagram)**:类似流程图,用于表示系统的工作流程或业务过程。 8. **组件图 (Component Diagram)*...

    人事管理系统设计与实现—管理.pdf

    - **状态图(Statechart diagram)**:描述了对象在其生命周期中的不同状态和转换。 - **活动图(Activity diagram)**:表示了系统中的工作流程或操作序列。 - **组件图(Component diagram)**:展示了系统的...

Global site tag (gtag.js) - Google Analytics