The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Terms and Concepts

A state diagram shows a state machine, emphasizing the flow of control from state to state. A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events. A state is a condition or situation in the life of an object during which it satisfies some condition, performs some activity, or waits for some event. An event is the specification of a significant occurrence that has a location in time and space. In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition. A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied. An activity specifies an ongoing execution within a state machine. An action specifies a primitive executable computation that results in a change in state of the model or the return of a value. Graphically, a state diagram is a collection of nodes and arcs.

Note

The state diagrams used in UML are based on the statechart notation invented by David Harel. In particular, the concepts of nested states and orthogonal states were developed by Harel into a precise, formal system. The concepts in UML are somewhat less formal than Harel's notation and differ in some details, in particular, by being focused on object-oriented systems.

Common Properties

A state diagram is just a special kind of diagram and shares the same common properties as do all other diagramsthat is, a name and graphical contents that are a projection into a model. What distinguishes a state diagram from all other kinds of diagrams is its content.

Contents

State diagrams commonly contain

• Simple states and composite states

• Transitions, events, and actions

Like all other diagrams, state diagrams may contain notes and constraints.

Note

A state diagram is basically a projection of the elements found in a state machine. This means that state diagrams may contain branches, forks, joins, action states, activity states, objects, initial states, final states, history states, and so on. Indeed, a state diagram may contain any and all features of a state machine.

Common Uses

You use state diagrams to model the dynamic aspects of a system. These dynamic aspects may involve the event-ordered behavior of any kind of object in any view of a system's architecture, including classes (which includes active classes), interfaces, components, and nodes.

When you use a state diagram to model some dynamic aspect of a system, you do so in the context of virtually any modeling element. Typically, however, you'll use state diagrams in the context of the system as a whole, a subsystem, or a class. You can also attach state diagrams to use cases (to model a scenario).

When you model the dynamic aspects of a system, a class, or a use case, you'll typically use state diagrams to model reactive objects.

A reactiveor event-drivenobject is one whose behavior is best characterized by its response to events dispatched from outside its context. A reactive object is typically idle until it receives an event. When it receives an event, its response usually depends on previous events. After the object responds to an event, it becomes idle again, waiting for the next event. For these kinds of objects, you'll focus on the stable states of that object, the events that trigger a transition from state to state, and the actions that occur on each state change.

Note

In contrast, you'll use activity diagrams to model a workflow or to model an operation. Activity diagrams are better suited to modeling the flow of activities over time, such as you would represent in a flowchart.