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:
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:
The following keyword represents the invocation of a nested state machine:
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):
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:
A parameter has the format:
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:
The event-signature describes an event with its arguments:
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:
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.
发表评论
-
perl
2007-11-07 05:36 834http://www.xlab.net/jochen/perl ... -
unix shell.
2007-08-21 20:51 1068标题: ... -
diplompruefung
2007-08-02 20:05 837Allgemeine VWL I für WiWis [W ... -
GUI
2007-07-13 05:08 887 -
Statecharts
2007-07-13 04:39 977Statecharts Many situations req ... -
UML Modeling for Java with Rhapsody
2007-07-13 04:38 1042UML Modeling for Java with Rhap ... -
Building a Statechart Diagram
2007-07-13 04:33 1691Building a Statechart Diagram T ... -
State Chart XML (SCXML): State Machine Notation for Control
2007-07-13 04:12 1618State Chart XML (SCXML): Stat ... -
Diplomarbeit Writting Materials
2007-07-05 20:09 1292Designing a soft ... -
diplomarbeit
2007-06-10 21:32 3460UML. class , interface, re ...
相关推荐
网络讲坛:LabVIEW状态图(Statechart)(下)rar,工程师将通过几个实际程序案例为您展示Statechart与状态机的区别,以及在并发、包含及历史保存这三部分中,Statechart是如何只是通过直观的设计方式就能帮助您轻松完成的...
4、熟悉UML,主要了解UML中的9大图:Use case diagram(用例图)、Class diagram(类图)、Object diagram(对象图,Rose中没有)、Sequence diagram(序列图)、Collaboration diagram(协作图)、Statechart diagram(状态图)...
UML定义了九种模型图:用例图(Use Case View)、类图(Class Diagram)、对象图(Object Diagram)、构件图(Component Diagram)、部署图(Deployment Diagram)、状态图(StateChart Diagram)、活动图(Activity...
* 绘制状态图:状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为,显示了该实体如何根据当前所处的状态对不同的事件做出反应。 三、实验过程 * 绘制用例图:在 UML 用例中拖入系统边界、参与者和 ...
6. 状态图(Statechart Diagram),描述系统的状态变化 7. 活动图(Activity Diagram),描述系统的活动过程 8. 组件图(Component Diagram),描述系统的组件结构 9. 配置图(Deployment Diagram),描述系统的配置...
* 状态图(Statechart Diagram):描述类的对象所有可能的状态以及事件触发的状态转移条件 * 顺序图(Sequence Diagram):显示对象之间的动态合作关系 * 协作图(Collaboration Diagram):强调对象间的动态协作...
其中,活动图(Activity Diagram)和状态图(Statechart Diagram)是UML中的两种重要图形表示方式。活动图主要用于描述业务流程或工作流;状态图则用于描述对象在其生命周期内的行为,包括对象的状态及其转换。本实验...
在RationalRose中,我们可以使用Statechart Diagram来创建状态图,定义系统的状态转换过程。例如,在《在线选修课程管理系统》中,我们可以创建一个状态图,描述系统的选修课程目录表的状态转换过程。 十一、 构件...
3. 状态图(Statechart Diagram)描绘了类的状态随时间和事件变化的情况,反映了类的行为。每个状态代表对象可能存在的一个条件,状态之间的转换则表示了行为的变化。 在IDEner创意孵化项目中,使用BPM和UML进行...
这些图表只是UML的一部分,还有其他如协作图(Collaboration Diagram)、状态图(Statechart Diagram)、类图(Class Diagram)、组件图(Component Diagram)和部署图(Deployment Diagram)等,分别从不同的层面和...
行为图则是另一种描述系统动态行为的工具,分为状态图(Statechart Diagram)和活动图(Activity Diagram)。状态图关注对象在其生命周期内状态的变化,例如,教师查看学生成绩的场景中,教师可能处于等待信息、接收...
6. **状态图(Statechart Diagram)**:表示单个对象在其生命周期中的状态变化和事件触发的转移。 7. **活动图(Activity Diagram)**:类似于流程图,表示工作流或业务流程,强调控制流和并发。 8. **组件图...
- 状态机图(Statechart Diagram):用于描述对象在不同状态间的转换。 - 活动图(Activity Diagram):类似于流程图,表示业务流程或用例的控制流。 3. 实现图表: - 组件图(Component Diagram):描绘软件系统的...
3. **状态图(Statechart Diagram)**:状态图展示了对象随时间变化的状态和状态之间的转换,它用于描述对象如何响应特定事件并执行相应的操作。 4. **时序图(Sequence Diagram)**:时序图强调消息的时间顺序,描绘...
5. **状态图(Statechart Diagram)**:状态图描绘了一个对象在其生命周期中可能经历的状态以及状态间的转换,通常用于描述单个对象的行为。 6. **活动图(Activity Diagram)**:活动图类似于流程图,它描述了满足用例...
6. **状态图 (Statechart Diagram)**:描述对象在其生命周期内的状态变化和响应事件的行为。 7. **活动图 (Activity Diagram)**:类似流程图,用于表示系统的工作流程或业务过程。 8. **组件图 (Component Diagram)*...
- **状态图(Statechart diagram)**:描述了对象在其生命周期中的不同状态和转换。 - **活动图(Activity diagram)**:表示了系统中的工作流程或操作序列。 - **组件图(Component diagram)**:展示了系统的...