Behavior Diagrams Update
UML 2.0: Updated State Diagram
The major changes of the state machine concept in UML2.0 compared to UML1.4 are:
Composite state with entry/exit points that increase the scalability and independence of behavior specification.
State machine generalization that enables inheritance and specialization of behavior.
Protocol state machines that enable allowed sequences of signals and operation calls to be specified.
State machines that have operations that enable calls on state machines.
State groups that enable common behavior of events in different states.
A state machine is used to model discrete behavior triggered by events. In addition to expressing the behavior of a part of the system, state machines can also be used to express the protocol through a port. These two kinds of state machines are referred to as behavioral state machines and protocol state machines. The state machine formalism used in UML2.0 is an object-oriented variant of Harel state charts.
A state machine is triggered by different kind of triggers: signals, timeouts, operation calls and change in values. A trigger causes a transition if the trigger is specified for the current state for that state machine. A transition is described by actions that may cause new trigger events to be generated.
The most important improvements of the state machine concept in UML2.0 are encapsulation of behavior in a composite state and inheritance of behavior in sub types. These are described in more detail in the following sub chapters.
Composite state
UML1.4 has no limitations on how to enter and exit composite states. It is legal to enter directly to internal states of composite states and it is therefore difficult to specify composite states that can be reused in other state machines. UML2.0 has introduced exit and entry points that control access to a composite state. Figure 5 shows an example of a state machine with entry and exit points. Exit and entry points are named points that are placed on the frame of the state machine.
Definition of Exit / Entry points
Figure 6 shows an example on how the ATM state machine uses the state machine ReadAmountSM. The transition rejectTransition ends in the entry point again of the state ReadAmount. If we look at Figure 5 again, we can see that transitions through this entry point ends in the state EnterAmount. The same semantic applies on transitions from states inside the composite state. The transition triggered by the signal abort exits the composite state through the exit point aborted and ends in the state ReleaseCard.
Use of Exit / Entry points
Use of exit and entry points enables the design of components of behavior that can be more easily used in different places. This is analogous to use of procedures to obtain reusable operations.
An unnamed entry or exit point represents default behavior. A composite state may have several named entry and exit points.
Generalization of behavior
The generalization and specialization concepts have been an important part of the UML language. It has not been possible until now to inherit the behavior of state machines. As shown in Figure 7 this has now been added to UML in the same way as ordinary inheritance of classes. New state machine types can also be specified using inheritance independent of classes. New behavior specification can be added and parts of existing behavior can be replaced as follows:
States and transitions can be added
States can be extended
Transitions can be replaced or extended
Targets of transitions can be replaced
Submachine states can be replaced.
Signals and operations may be added.
Specialization by extension
Figure 8 shows how the composite state ReadAmount may be extended adding two new states (SelectAmount, EnterAmount), three transitions (OtherAmount, ok rejectTransaction), and one port. The figure also shows that it is allowed in UML2.0 to enter a composite state without going through an entry point. The transition rejectTransaction in state VerifyTransaction ends directly in the state EnterAmount.
Specialization of state machines
Notational enhancements
Backward Compatibility
In general all UML 1.4 state machine concepts are preserved in the 2.0.
New core constructs added
(Action Language)
State machine
specialization/redefinition
Transitions pre/post conditions
Connection points replace nested State Diagrams
Interaction Diagrams UML 2.0:
Interaction context
Control structures (sequence, iteration, selection, parallel)
Nested sequence diagrams
Interaction overview diagram
Timing diagram
Other new notation
Activity Diagrams UML 2.0:
separated from state diagram
Better alignment with Petri nets
Parallelism
UML 1.X
Token queuing
Better support for workflow modeling
streaming parameters
hierarchical partitions
UML profiles
UML defines three standard extension mechanisms: stereotypes, constraints and tagged values. They are used to define extended meta classes in packages that are called UML profiles. Profiles can be used to for instance, to tailor a UML meta model to a specific platform such as EJB or .NET. It can also be used to make new concepts to be used in models. An UML profile for animals will for instance contain a meta class Cat as shown in Figure 9. The class Cat is tagged with the keyword stereotype. Cat is an extension of the meta class Class and Cat can therefore only be applied on instances of the meta class Class. The stereotype can extend an existing meta class or a stereotype.
Defining UML extensions
A stereotype can have constraints. Constraints are expressed either by using OCL or as informal text. In the example above there are two constraints defined. The stereotype cat must have the attribute isActive equal true and its interfaces can only contain signals. Stereotypes are defined in a UML Package tagged with <<profile>>.
A stereotype is used to tag instances of the metaclass as shown in Figure 10. Attributes can be given values when the stereotype is applied.
Use of stereotypes
Summary
This paper has presented the major features in UML2.0. It has shown that UML2.0 has been improved with respect to modeling of behavior and composition. Behavior can now be extended, which is important when more complex behavior is modeled. It is also possible to make fully encapsulated behavior components, state machines, which may enable reuse of behavior. It seems that UML2.0 now has concepts that better support modeling of systems that have to cope with conflicting initiatives and communication between loosely coupled components. UML also has an extension concept called profiles. Profiles are used to define meta classes in UML to tailor a UML model to a specific platform such as EJB.