The purpose of this document is to present and explain UML diagram notation and semantics.

UML Diagrams

1. Activity Diagrams
   
2. Class Diagrams
   
3. Collaboration Diagrams
   
4. Component Diagrams
   
5. Deployment Diagrams
   
6. Sequence Diagrams
   
7. Statechart Diagrams
   
8. Use-Case Diagrams
   

Extensions to UML

1. Object Constraint Language
   

General purpose elements help to organize elements and express details of visual communication. In UML the general purpose elements are as follows:

1. Package Diagrams and Packages

   A package is a group of UML diagrams. A package diagram shows the organization of packages.

2. Keywords and Stereotypes

   UML keywords are labels that distinguish representation elements that use the same symbol. For example, the classifier symbol -- a rectangle with compartments -- can be used to represent a type, a class, a meta-class, or an object. A double bracketed label defines a kind of classifier, for example: <<class>>, <<type>>, <<metaclass>> and <<object>>. Keywords are reserved.

3. Expressions, Constraints and Comments

   An expression is a string from an executable language that can be evaluated to a result. A constraint is a predicate expression on model elements. which expresses a relationship within the system under study. Constraints are shown as text enclosed in braces. Although the interpretation of predefined UML constraints is fixed, the syntax and interpretation of user-specified constraints are user-defined. Constraints may be written in natural language, mathematical expressions, code or the Object Constraint Language (OCL).

4. Notes

   Notes may be connected to diagram elements or free standing.

5. Element Properties

   The properties of an element are displayed in braces and designated by a tag expression.

When the flow of events is linear (i.e., contains little iteration or conditional logic), a textual description of behavior is often sufficient to capture the system behavior. For all other cases, a graphical means of displaying flows of information/events is needed.

Activity diagrams (like the well known flowchart diagram) provide a visual reference for documenting sequences of tasks making up a single activity. They are especially useful for activities governed by conditional logic, and flows of event running concurrently.

Notation and Semantics

Activity diagrams are an assembly of nodes and elements:

1. The nodes in an activity diagram represent processes and process control: action state, decision, synchronization point, object box, signal receiver and senders,and swim lanes.

2. The edges show what activities may follow one another and, optionally, which objects may participate in an activity: control flow, message flow and signal flow.

Summary of Activity Diagram Elements (adapted from Binder, 2000)

Activities and States

An activity is a unit of work that needs to be completed. Activities are drawn as horizontal capsules (i.e. rectangles with rounded ends). The name of the activity is drawn within the rounded rectangle, as shown in the adjacent figure.

Figure : Format for Activities and States

Activity nodes may be expanded to include a list of individual actions making up the activity.

Figure : Activity expanded to include list of actions

which in turn may be expanded to lower-level activity diagrams.

A state in an activity diagram is a point where some event needs to take place before an activity can continue, and is drawn as a rectangle with round corners. In other words, states in an activity diagram imply "waiting for an event" rather than "doing actions." See the adjacent figure.

In each activity diagram, there are two special states -- the start and end states. A start state is drawn as a solid black dot. An end state is drawn as a solid back dot enclosed within a circle.

Example 1. Format of Simple Activity Diagram

Figure : Format for a Simple Use-Case Oriented Activity Diagram

Points to note are as follows (see Amour, pg. 145):

• Activity diagrams are composed of activity states (which will map to individual activities within a use case).

• Actions may be triggered in one of four ways:

  • On entry: These actions are triggered when the activity starts.
  • Do: These actions take place during the lifetime of the activity.
  • On event: These actions take place in response to an event.
  • On exit: These actions take place just before completion of the activity.

• For those cases where the activity diagram models the behavior in a use case, the start state will map to the use case preconditions, and the end state will map to the use case postconditions.

• Directed lines between activities model transitions between individual activities, and indicate a change in system state. A transition normally occurs when all of the actions in an activity have been completed.

Example 2. Branching in an Activity Diagram

Figure : Use of Branching Constructs in an Activity Diagram

Points to note are as follows (see Amour, pg. 145):

• A diamond represents a transition to different branches in an activity diagram. The condition causing the branch should be shown along the directed line leaving the diamond.

Example 3. Looping in an Activity Diagram

Looping constructs in activity diagrams are implemented in much the same way as branching constructs.

Figure : Use of Looping Constructs in an Activity Diagram

Points to note are as follows (see Amour, pg. 145):

• All of the activities inside the looping construct will be repeated until the condition evaluates to true.

Example 4. Use of Synchronization Bars

Synchronization bars give activity diagrams the ability to model flows of event that are concurrent.

Figure : Use of Synchronization Bars in an Activity Diagram

Points to note are as follows (see Amour, pg. 145):

• The top horizontal bar models a transition to two or more parallel paths (i.e., flow of events).

• The bottom horizontal bar models the join in flow of events.

Example 5. Use of Swim Lanes

Swim lanes are a notation for indicating where an activity takes place (e.g., in a business, or perhaps, within a complex system). In other words, they divide the activity states into groups and assign these groups to objects that perform the activities.

Swim lanes are defined by columns in an activity diagram, and activities in the diagram are organized into swim lanes.

Figure : Use of Swim Lanes in an Activity Diagram

Points to note are as follows (see Amour, pg. 145) -- the work flow for this activity diagram is executed by objects A, B and C. More complicated examples can include notation for branching and looping constructs.

Example 6. Objects on Activity Diagrams

Sometimes it is useful to indicate on an activity diagram how a flow of work affects an object. As explained below, activity diagrams have a special notation for this situation.

Figure : Displaying objects on an Activity Diagram

Points to note are as follows:

• Rectangular boxes contain the object name and variable name, and state of the variable as the result of the work flow. After activity 2 is complete, the variable "Flag Status" in objects 1 and 2 (shown as o1 and o2) will be True and False, respectively.

• Activity boxes are connected/tied to objects through a dependency relationship. Such dependencies are known as object flows because the indicate how an object is used in a flow of control.

Example 7. Use of Signal Flow Notation

An advanced technique for making a behavior model object-oriented is to associate each step with the changes to objects that the step is intended to cause, and associate those changes with the steps that they initiate.

Figure : Modeling the effects and causes of a step

In the adjacent figure, the effects of fixing a roof are shown, namely, a fixed roof and workers available for another job. Each participant has their own effect, billing the customer and assigning workers, respectively. The figure uses the UML signal flow notation in activity diagrams to notate the effect of each step. This is unfortunate because it forces the user to employ object flow to model cause and effect. For example, a fixed roof would not necessarily be an input to billing a customer, only the reason for doing so.

This technique is not normally applied to data flow, because effects of a step are implicitly modeled in the structure of objects returned for consumption by later steps. When applied to state machines, this technique should not be confused with the events that trigger the beginning of steps in a state machine. State machine events model object changes, but they are caused by external factors, not by a step in the state machine.

Subtle Points and Limitations

The limitations of activity diagrams are as follows:

1. Object orientation distinguishes between an operation and the specific behavior that carries out the operation, which is called the method in UML terminology. In many cases, functional implementations can be converted to object-oriented solutions in just a couple of steps (Bock, 1999):

   1. The simplest way to make the various behavior models object-oriented is to use them as methods.

   2. Another way to make a behavior model object-oriented is to invoke operations instead of functions in each of its steps.

   The control-flow model in the adjacent is not acceptable to an OO practitioner because it does not relate the steps or the entire behavior to objects responsible for them. This is an incomplete use of the UML activity notation.

   

   Figure : Non Object-Oriented Control Flow

   Applying the two techniques listed above produces the object-oriented model shown in the adjacent figure.

   

   Figure : Object-Oriented Control Flow

   Points to note are as follows:

   • It uses the OOIE convention that the type of object receiving a message is specified in parentheses below the name of the operation that it supports. For example, the operation "fix order" is available on the object type "customer support," because supporters are responsible for contacting the customer and helping them correct the order. UML unfortunately does not have a concise notation for this yet.

   • It provides swim lanes, wherein each step is assigned to a column on the diagram corresponding to the type of object responsible for that step. Figure 2 also makes the entire control-flow model into a method by connecting it to the operation it implements, namely the operation "process order" on the object "sales department." UML uses the "realize" dependency to model this, notated by a dashed arrow. These two additions make the model object-oriented by relating the steps and entire behavior to objects that handle them.

   • In passing it should be mentioned that it is a common mistake to assume messages are passed between steps.

     In the second figure, for example, it might be mistakenly taken that when step "receive order" is done, it sends a message for "review order" to begin. Such an interpretation would impair the reusability of the steps, because a step would imply what others must be executed after it, rather than allowing the sequence of steps to be determined by control-flow links in each diagram where the step is used.

     A better interpretation is that messages are passed from the method containing the steps to the operation in each step. For example in the second figure, the method for the "process order" operation on the "sales department" object invokes the "ship order" operation on the "shipping" object. This way the operations invoked by the steps have no dependence on each other. The method containing the steps coordinates the steps by defining their order and the conditions under which they are invoked, without making the operations in them dependent on each other.

Functional Flow Block Diagrams

Except for some notational details, functional flow block diagrams are identical to activity diagrams.

A class diagram is essentially an enhanced entity-relationship diagram, where the entities are classes with name, attribute and actions. A software class can be viewed as a template from which instances are created during the software execution. Class diagrams incorporate several types of relations, including generalization, association and aggregation.

The primary use of class diagrams is in the support of descriptions of system structure (Ogren, 2000). The entities and relationships in a class diagram for a particular application typically represent the structure of the classes in a library.

Notation and Semantics

Class diagrams are an assembly of nodes and elements:

1. The nodes in a class diagram indicate various types of classes, objects, and interfaces.

2. The edges indicate various types of association among classes, including composition, aggregation and generalization relationships.

An association between two classes means that both implement a mutual constraint or dependency in their implementation (e.g., customer owns account). Association relationships are depicted by a line joining the two class boxes. An association has a name, and optionally, a small arrowhead to depict the direction in which the association name should be read.

Multiplicity parameters appear at the ends of the association line, and define how many instances of one class may be associated with an instance of another class.

Summary of Class Diagram Elements (adapted from Binder, 2000)

Example 1. Generalization/Specialization

This is an is-a relationship. Generalization relationships identify classifiers that share common elements, and are shown by a line with an unfilled triangle whose apex points to a more general classifier.

A superclass generalizes a subclass. For example, in the next figure, the "Checking Account" and "Saving Account" classes specialize the upper-level Account class.

Points to note are as follows:

1. The Account class stores information common to all classes -- in this case, an account number and a balance. Information is added to the "Checking Account" class for the last deposit amount (this could affect the account fees), and an interest rate is added to the "Savings Account."
2. A discriminator is an attribute that indicates which property of the object is be abstracted by the generalization relationship. In this example, the "Account Type" attribute (an optional label for the UML diagram) discriminates the specialized classes.

Example 2. Aggregation Hierarchy

This is a whole/part relationship. A simple aggregation hierarchy is shown by a line with an unfilled diamond at the container end. This indicates that the constituent classifier is created and destroyed independently of the container classifier.

In the adjacent figure, "Class Whole" is an aggregation of "Class Part 1" and "Class Part 2." And because the relationship is aggregation, "Class Whole" is created and destroyed independently of "Class Part 1" and "Class Part 2."

Example 3. Composition Hierarchy

This is a whole/part relationship. A composition hierarchy is shown by a filled diamond at the using end. This indicates that the constituent classifier is created and destroyed with the container classifier.

Care is needed to distinguish the composition and aggregation cases. As pointed out by Binder (Binder, 2001, pg. 257), good test for whether a relationship is a composition relationship is to ask the question:

    If the part moves, can one deduce that the whole moves
    with it in normal circumstances?

For example, among other things, a car is composition of wheels and an engine. If you drive the car to work, hopefully the wheels go to!

In the adjacent figure, "Class Whole" is a composition of "Class Part 1" and "Class Part 2." Because the relationship is composition, "Class Whole" is created and destroyed with "Class Part 1" and "Class Part 2."

Example 4. Multiplicity in Class Associations

The multiplicity of an association can be one (1), optional (0..1), zero or more (*), one or more (1..*), or numerically specified (m..n), where m and n have numeric values.

Points to note are as follows:

1. An association between two classes is called a "binary association."
2. If an association is labeled, then an arrow-head should be used with the association name to indicate the direction in which the text of the association name should be interpreted.

Example 5. Class Hierarchy for a Banking System

The following pair of diagrams show a conceptual model for an ATM system (this example is adapted from Goamma, pg's 151).

The first diagram shows the relationship of ATM machines to a bank -- that is, each bank will have at least one DTM machine.

Lower-level details of the ATM machine architecture and operation are shown in the second diagram. Here we see that the ATM machine is a composition of a keyboard, card reader, cash dispenser and receipt printer. The lowest level of the diagram implies interaction of the ATM components with a customer -- for example, the cash dispenser delivers cash to the customer.

Limitations. The limitations of class diagrams are as follows:

Like the sequence diagram , a collaboration diagram describes the details of communication between object instances (or classes) in an interaction. These interactions are modeled as exchanges of messages between classes through their associations.

Collaboration diagrams can represent interactions at various levels of generality:

• Specification-level Collaborations

  A specification-level collaboration show the generic case of a collaboration, including possible alternative paths, loops that may execute an unspecified number of times and class roles rather than instance roles.

• Instance-level Collaborations

  An instance-level collaboration shows a specific instance of interactions that take place between objects. It will show the results of following a particular path where there is a choice.

Notation and Semantics

Collaboration diagrams depict the structural organization of the objects -- that is, they are an assembly of nodes and elements:

1. The nodes in a collaboration diagram represent a collaboration role. Such a node can represent any object of a class/system that may fulfill the role/interaction. These nodes do not represent specific objects, however. They may be simple or composite.

2. The edges are links that are shown with solid undirected lines. They represent that visibility is required from one role to another. The sending of messages and related control mechanisms is represented by a small arrow near the link.

Summary of Collaboration Diagram Elements (adapted from Binder, 2000)

Points to note about collaboration diagrams are as follows:

1. The objects in rectangles represent the class roles.
2. The links (lines or paths) represent association roles.
3. The arrows between class roles indicate message flows exchanged between objects.
4. The message flows are labeled with both the sequence number of the message and the message that is sent between the objects. A message triggers an operation in the receiving objects.

Object and Class Notation

UML has a well-defined syntax for instance names.

Figure : Examples of object instance names

A summary of the syntax is as follows:

Message Flow Notation and Sequence Numbers

Collaboration diagrams employ four arrow types for different types of messages.

Message Type	Description
	Procedural or Synchronous. A message is sent by one object to another, and the first object waits until the resulting action has completed. This may include waiting for actions in the second object (and so forth) to complete.
	Flat. Each arrow shows a progression from one step to the next in a sequence. Normally, the message is asynchronous. A flat message can be used when it is not known whether the actual message will be synchronous or asynchronous.
	Asynchronous. A message is sent by one object to another, but the first object does not wait until the resulting action has completed. Instead, it carries on with the next step in its own sequence of actions.
	Return. This arrow represents the explicit return of control from the object to which the message was sent. Often, this arrow is omitted from collaboration diagrams, and more frequently found on sequence diagrams.

The sequence numbers indicate the sequence of messages within the next higher level of nesting (or passing of control). Message numbering works as follows:

1. Messages that differ in one integer for a sequence at the same level of nesting.
2. Among nesting levels (or when messages originate from different instances of classes), messages are concurrent. For instance, messages 1 and 2 will be concurrent when the originate from different sources.

Use of Associations and Links

Associations between classes can be added to the collaboration diagram if they are required to support the collaboration. For example,

Figure : Use of Associations in Collaboration Diagrams

From a practical standpoint, collaboration diagrams will become very cluttered if association roles are used throughout. Therefore, association roles are best used when it is important to distinguish between roles that a class will participate in. For example, the same instance of a class might participate in the same collaboration in different roles.

Links between object instances can be added to collaboration diagrams. They may be instances of associations that are shown on the class diagram, or they may be temporary links between object instances that enable message passing. Links may be stereotyped as <<local>> or <<parameter>> (useful for representing local variables in software development).

Example 1. Use of Associations in Collaborations

In the adjacent figure (taken from Bennett et. al):

Figure : Use of Associations in a Collaboration Diagram

a new payment schedule is added to an insurance policy. Each Policy has an association with one current PaymentSchedule, and a set of zero or more previous instances of PaymentSchedule.

Associations can also support the direction of messaging:

Figure : Direction of Message Passing added to Associations

For example, here we see that the :Policy role needs to be able to send messages to the PaymentSchedule roles.

Example 2. Use of Message Names and Sequence Numbers (See Goamma, 2000).

This small example shows the various styles of notation supported by collaboration diagrams.

As indicated above, the sequence of messages passed between objects is numbered. An optional iteration is indicated by a *, which means a message is sent more than once. An optional condition means that a message will be sent only if the condition is true.

Example 3. Use of Guard Conditions (See Bennett et al., 2001).

A guard condition is a condition that must evaluate to true before the message can be sent. Typically, this condition will be written in the Object Constraint Language. The condition can be in terms of parameters of the message, attributes of the current object, concurrent states of the current object, or states of other objects that are reachable via links from the current object.

In the adjacent figure,

Figure : Use of a Guarded Message

the class ConnectionControl sends a message open() to the class ModemDriver. Should the modem respond, details of the connection (e.g., baud rate, parity bit) are established by by sending a second initialize() method to ModemDriver.

The second figure,

Figure : Message with a condition in Sequence Expression

shows an expanded model that uses a time and a condition-clause to determine success/failure for opening of the connection.

Limitations. The limitations of collaboration diagrams are as follows:

1. Because links among collaboration diagram nodes allow more than one message to be sent, execution paths cannot be traced directly from the links.
2. Although the diagram can be used to represent the structure of an implementation, this is not the primary purpose. The diagram is abstract (it does not require binding to specific objects) and is a slice of the modeled scope.

A component diagram shows:

1. The organization of and dependencies among implementation components. Components are physical units containing, for example, source code, object code, and so forth.

2. Physical containment of components, and interfaces and calling components, using dashed arrows from components to interfaces on other components.

Component diagrams are particularly suited to the representation of software components.

Notation and Semantics Component diagrams are an assembly of components and links:

1. Components are drawn as rectangles with two small boxes on one side.
2. Links are drawn as dashed lines. Compiler dependencies are shown by dashed arrows.

Summary of Component Diagram Elements (adapted from Binder, 2000)

Example 1.

In the adjacent component diagram,

Figure : Component Diagram for simple Client-Supplier System

the development-time relationship between clients and suppliers is indicated with the dashed arrow. The arrow direction indicates that client components are dependent on supplier components.

Component diagrams may also be stereotyped to indicate an implementation-specific time-dependent dependency.

Example 2.

The adjacent component diagram,

Figure : Component Diagram for simple network of Components

has four dependency relationships. Component 3 depends on Component 1, which in turn, depends on Component 2. At the same time, Component 3 also depends on Component 4, which in turn, depends on Component 2.

Limitations

The limitations of component diagrams are as follows:

1. Component diagrams are design specifically for software systems, and as such, are not currently used in object-oriented systems engineering methods (Meilich, 2001).

Deployment diagrams describe the configuration of processing resource elements and the mapping of software implementation components onto them. The components (or nodes) in a deployment diagram represent processing or computational resources, such as computers, printers, scanners, and so forth.

Notation and Semantics

Deployment diagrams are an assembly of nodes and elements:

1. The nodes in a deployment diagram represent all kinds of computer systems, manual and mechanical processors. Nodes are connected by communication associations, indicated by a solid line (no arrow);

2. The edges in a deployment diagram represent channels of communication.

Summary of Deployment Diagram Elements (adapted from Binder, 2000)

Example 1.

The adjacent figure shows the interfaces and a networked ATM system.

Figure : Deployment of Networked ATM System

In a typical networked ATM system, there will be tens-of-thousands of ATMs, hundreds of regional transactions nodes, and perhaps a thousand institutional servers.

Limitations

The limitations of deployment diagrams are as follows:

1. They are really only suitable for modeling of software systems.

2. Object-oriented systems engineering methods (Meilich, 2001) use equivalent class diagrams to capture deployment of software and stores.

Like the collaboration diagram , sequence diagrams provide a graphical representation for how a task is accomplished by passing a sequence of messages among objects. These interactions define the system behavior.

Typically, sequence diagrams are used hand-in-hand with use case diagrams, and are used to design the collaboration necessary to implement a use case.

Notation and Semantics

Sequence diagrams are an assembly of nodes and elements:

1. The nodes in a sequence diagram represent runtime properties of executable components and provide drafting features, including objects, object lifelines and activation, conditional branching, and recursive activation.

2. The edges represent generic properties of runtime behavior, including various types of procedure call (or task execution), loops and delays.

A sequence diagram is a two-dimensional diagram in which the objects participating in the interaction are depicted horizontally, and the vertical dimension represents time.

Summary of Sequence Diagram Elements (adapted from Binder, 2000)

Object and Class Notation

UML has a well-defined syntax for instance names.

Figure : Examples of object instance names

A summary of the syntax is as follows:

Message Flow Notation and Sequence Numbers

Like the collaboration diagram, sequence diagrams employ four arrow types for different types of messages.

Message Type	Description
	Procedural or Synchronous. A message is sent by one object to another, and the first object waits until the resulting action has completed. This may include waiting for actions in the second object (and so forth) to complete.
	Flat. Each arrow shows a progression from one step to the next in a sequence. Normally, the message is asynchronous. A flat message can be used when it is not known whether the actual message will be synchronous or asynchronous.
	Asynchronous. A message is sent by one object to another, but the first object does not wait until the resulting action has completed. Instead, it carries on with the next step in its own sequence of actions.
	Return. This arrow represents the explicit return of control from the object to which the message was sent. Often, this arrow is omitted from collaboration diagrams, and more frequently found on sequence diagrams.

The sequence numbers indicate the sequence of messages within the next higher level of nesting (or passing of control). Message numbering works as follows:

1. Messages that differ in one integer for a sequence at the same level of nesting.
2. Among nesting levels (or when messages originate from different instances of classes), messages are concurrent. For instance, messages 1 and 2 will be concurrent when the originate from different sources.

Example 1. Sequences of Messages

This small example shows the various styles of notation supported by sequence diagrams.

Points to note are as follows:

1. As indicated above, the objects participating in the interaction are arranged horizontally across the diagram, and the vertical axis represents time.
2. The vertically-oriented dashed line emanating from each object is called a life line.
3. The actor is usually shown on the left-hand side of a sequence diagram.
4. Labeled horizontal arrows represent messages passed between objects.
5. Only the source and the destination of the arrow are important (i.e., the message is sent from the source object to the destination object).
6. Time increases from the top of the diagram to the bottom of the diagram.
7. The spacing between messages is not relevant.

Example 2. Return and Activation Notation

The adjacent figure shows the basic notation for return messages and active object status.

Figure : Sequence Diagram Return and Activation Notation

Points to note are as follows:

1. When a message is passed from one object to another, the focus of control for the latter is shown as a narrow rectangle positioned over the object lifeline.
2. We can highlight regions of time in which an object will be activated by filling the appropriate sections of the narrow rectangle drawn over the object lifeline.
3. The return of control in procedural interactions is shown as a dashed arrow.

Example 3. Asynchronous Messages and Active Objects

UML provides four arrow notations to represent various types of flow of control. When the flow of control is procedural or synchronous, there is only one thread of execution and activity passes temporally from one object to another.

When the flow of control is asynchronous, more than one object can be active at the same time. One object can send a message to another object and carry on with its execution without waiting for a reply.

Figure : Asynchronous Messages and Active Objects

In the adjacent figure, a message is sent from the WordProcessor to PrintSpooler objects, And from this point on, both objects are active (see Bennett et al, pg's 186). The PrintSpooler object sends messages to both PrintFile and Printer objects, but activities associated with these communications are synchronized (i.e., one task must finish before another can begin).

Example 4. Creating and Destroying an Object

Messages for creating and destroying objects can be stereotyped, as shown in the adjacent figure (see Bennett et al, pg's 185).

Figure : Notation for Creating/Destroying an Object

This diagram also shows use of a large 'X' to indicate the destruction (or end of lifetime) of an object.

Example 5. Use of Iteration

When a sequence of messages takes place within an iteration construct (e.g., a while looping construct in C), the messages can be grouped together within a rectangle

Figure : Notation for Iteration

with the test condition for continued loops positioned at the bottom of the rectangle (see Bennett et al, pg's 186).

Example 6. Use of Textual Annotations

When comments are added to a sequence diagram, the usual positioning is along the left-hand side at the same vertical positioning as the message or activation applies to.

Figure : Annotating a sequence diagram with comments

Here, a file is opened, and the spooler reads blocks from the file and sends them to the printer until an end-of-file is reached. Finally, resources associated with the file are released.

Limitations

The limitations of sequence diagrams are as follows:

1. Sequence diagrams highlight the behavior of systems through interactions among objects. They do not show the structural relationships among objects.

A finite state machine is a conceptual machine with a finite number of known states. A state transition diagram is a graphical representation of a finite state machine in which the nodes represent states and the arcs represent transitions between state. In the UML notation, a state transition diagram is referred to as a Statechart diagram. They have the following elements:

1. States

   States represent the situations during the life on an object in which it is active (e.g., performs an activity; waits for an event; satisfies a condition).

2. Transitions

   A state transition is a change in state that is caused by an input event. In response to the event, the system may choose to move from one system state to another. Alternatively, the system may choose not to respond to the event and the system state will remain unchanged.

Statecharts have the advantage of being hierarchical, having a well defined relationship to functions, and states to represent concurrency (we will get to the latter in a moment).

Statecharts in OMT (need to check UML??) use the Moore formalism, which implies functions and activities occur within the state. In the statechart diagram, states are shown as rounded contours with transitions appearing as arrows.

Notation and Semantics

Statechart diagrams are an assembly of nodes and elements:

1. The nodes represent the starting and finishing states and, of course, all of the allowable system states.

2. The edges represent the transitions among states.

Transitions

State transitions are a composition of three elements:

1. State invariants

   State invariants define the subset of legal value vectors allowed by the system. Before and after the execution of a well-defined transition, the system will have a value vector.

2. An event

   Generally speaking, an event is a kind-of stimulus that can be presented to an object or system. The stimulus might be a message, or perhaps an interrupt or similar external control action that the system must respond to.

3. A guard

   A guard is a predicate expression associated with an event.

Each transition results from an event and produces zero or more actions (e.g., a message sent from one object to another; or perhaps a change in system state).

Example 1. Statechart Basics

The following statechart diagram represents the various levels of water storage for a hydro-electric dam. When the dam is built, no water is stored (i.e., the water storage is Empty). Subsequent rises in water level move the storage state from Empty, to Drought, to Normal, to Flood. Reductions in water level move the state from Flood back down to Empty.

Figure : Statechart for a Simple Hydroelectric Dam Model

Points to note are as follows:

1. Beginning states are drawn as a large black dot. End states are drawn as a black dot with a surrounding circle.
2. States are drawn as rectangles with rounded corners. They are considered to exist for some finite period (albeit, sometimes very short) of time.
3. A transition is a movement between states. Transitions (or actions) can be triggered in a number of ways including, on entry, on event, and on exit. Transitions are drawn as arrow lines between pairs of states.

Example 2. Statechart with Multiple Exit Points

Statecharts may have multiple exit points. In this example, we diagram the states of a "research proposal" as it progresses through the phases of development, company-level approval, and submission.

Figure : Statechart for Proposal Development and Submission

Points to note are as follows:

1. Preparation of the proposal draft may be abandoned because there aren't any good ideas....
2. A final draft of the proposal may not happen, perhaps because there is insufficient time to work on it.
3. Proposals can be rejected because of budget and regulatory concerns.

Example 3. Use of Guard Conditions in a Savings Account

In the previous examples, actions have been described using simple English statement. We now extend the action description to include guard conditions. Generally, the syntax is:

    action-label / action

Some actions will automatically occur soon after the state has been entered. Some actions will automatically occur immediately before the state is exited. Other types of actions can occur (sporadically) during the lifetime of the state. For those cases where an action is triggered by an event, the syntax is:

    event-name ( parameters ) [ guard-condition ] / action 

Here, parameters is a comma-separated list of parameters supplied by the event, and guard-condition is a condition that must be true for the event to trigger the action. To see how this works in practice, the following statechart diagram is for the operation of a debit/credit account (Bennett et al, 2001).

Figure : Debit/Credit Account

Points to note are as follows:

1. Here we assume that the account is opened and closed with a "Zero Balance" state.
2. After the account is opened, a payment will move the account into a "Credit" state. Conversely, a charge will move the account into a "Debit" state.
3. The state of the account in subsequent transactions is governed by the guard conditions. If the quantity of money in the account is positive, then the account will have a "Credit"...and so forth.

Example 4. Hierarchal/Composite States.

States may be simple or composite. A simple state is not broken down further, and for a simple object, is likely to be represented by a few attribute values. Some examples of systems with simple states are shown above. Composite states, on the other hand, can be be broken down further indicating a hierarchy of statecharts.

Suppose, for example, a family of temperature sensors can be organized into the class hierarchy shown in the adjacent diagram. The generic temperature sensor (shown in the super-class) contains attributes for the temperature, the sensor weight, and the mean time before failure (MTBF). Methods are provided to monitor, reset and test the sensor status. Application specific "air" and "water" sensors are developed through extension of the generic sensor class.

Now let's consider the problem of creating a statechart for the system states and transitions that will occur for the sensor operation. States and transitions can be organized into two levels of detail. At the upper level, we can partition operations into "Testing Sensors" and "Operating Sensors." The high-level statechart diagram is as follows:

Figure : High-level Statechart Diagram for Temperature Sensors

The task "Reset Needed" moves the system state from "Sensor Operation" to "System Test," and "Test Completed" from "System Test" to "Sensor Operation." Lower-level detail includes information on testing procedures for the individual sensors and states associated with normal operation and various modes of failure. The expanded state-chart diagram is:

Figure : Multi-level Statechart Diagram for Temperature Sensors

Points to note are as follows:

1. The "System Test" state is expanded into a pathway of test procedures for the air and water temperature sensors. Similarly, the "Sensor Operation" state is expanded to "Normal" and "Failure Mode" states of operation.
2. When the test procedure is completed successfully, the system state automatically moves from the "System Test" state to the "System Operation" state.
3. When one or more of the individual system test procedures fails. the system state automatically moves to the "Failure Mode" state.

Example 5. Concurrent Substates.

It is possible for a composite state to exist as multiple, concurrent substates (Bennett et al., 2001).

Figure : ....

The adjacent diagram shows, for example, a composite statechart diagram for the student application process. First, a person applies to become a student. The application process is a composition of two tasks -- (1) review of the student record, and (2) processing of the application fee -- which can occur concurrently. The person will become a student if and only if steps (1) and (2) are approved.

Note. Statecharts versus Flowcharts

For any functional flow-block diagram (FFBD) a state diagram can be constructed to model the same set of functions (Oliver, pg's 63-67). The conversion procedure is really quite straight forward. Functions in the FFBD become states in the statechart diagram. Each statchart bubble can be decomposed into a finer level of granularity.

Limitations

The limitations of statechart diagrams are as follows:

1. A basic state machine can only recognize one event at a time.

2. System concurrencies cannot be modeled. Only a single state may be active at any time, and the model cannot accommodate two or more simultaneous transition processes.

3. The model has limited scalability. Statechart diagrams quickly become unmanageable with increasing problem size.

4. The UML definition provides most of the information necessary for state-based testing, but permits the development of non-testable constructs and ambiguities.

5. State machines have not been developed with object-oriented principles in mind. For example, inheritance mechanisms are not easily modeled by state machines. Although, in principle, a complete object-oriented system could be modeled using a (large) state machine, in practice, finite state machines tend to be contained within a single object.

In object-oriented approaches to development, use cases are the dominant form of system-level requirements specification. Because the collection of use cases encapsulates the complete functionality of the system, they are said to drive the unified development process -- they are the primary representation of system requirement types, including:

1. Functional requirements;
2. Allocation of functionality to classes/objects;
3. Object interaction and object interfaces; and
4. User interfaces.

Related activities in which use cases can participate include:

1. Determine of development increments;
2. Establishment of traceability;
3. Conceptualization and prototyping;
4. Determination of system boundaries;
5. Development of resource and effort sizing;
6. Architectural partitioning.

A use case is an abstraction of a system response to external inputs, and accomplishes a task that is important from a user's point of view. When a user uses a system, they will perform a behaviorally related sequence of transactions in a dialog with the system. Such a sequence of transactions is called a use case.

Points to note are as follows:

1. A system boundary is an abstraction of the implementation interface that accepts and transports external inputs and outputs.

2. A use case focuses on only those features visible at the external interfaces, and represents a dialog between the system and the external actors (e.g., human users, computer systems, electromechanical sensors and actuators, who submit and receive information to/from the system under test). A use case instance defines a specific set of input values and expected results.

3. A use case is composed of operations -- an operation is a particular sequence of messages exchanged between objects, initiated by external input. Operations cause a particular path to be traced through a sequence diagram .

Notation and Semantics

Use case diagrams are an assembly of nodes and elements:

1. The nodes in a use case label the actors, individual use cases, and the complete system encompassing the use cases.
2. The edges link actors to the use cases, and indicate dependencies among use cases,

Summary of Use Case Diagram Elements

Relationships among Use Cases (determine <include>, <extend> and <generalization> relationships)

Relationships are used to link two elements (e.g., use cases, actors, or packages) in a use case diagram. For example, a use case may incorporate one or more other use cases, or perhaps, may be a kind-of some other use case.

These relationships are denoted:

• <<extends>>

  A use case is an extension of another (base) use case. The base use case contains the main body of the use case, and the extending use case(s) describes the extending behaviors that may be needed to fulfill additional requirements.

  To avoid an excessive number of use cases, extended use cases should be reserved for significant optional behaviors (not just exceptions to normal behavior).

• <<include>>

  The include use case allows one use case to include in its flow of events, behaviors specified in another use case. Behavior in the additional use case is inserted into the base use case (UML 1.3).

  Include relationships provide a means for capturing and separating out commonality among use cases, and improving readability of the use case model.

and graphically drawn:

Figure : Use case <<extend>> and <<include>> relationships

The extend and include relationships may be applied to use cases. In the adjacent figure, use cases B and C provide extended behavior to the base use case A. Similarly, use cases E and F include the flow of event captured by use case D.

An actor may inherit behavior from another actor using the generalization relationship.

Limitations The limitations of use-case diagrams are as follows:

1. Use cases take a functional approach to developmnet -- they really aren't object-oriented at all!!!

The object constraint language (OCL) expresses relationships and properties of modeled elements (Warner, 1999). OCL is a declarative language; that is, none of its operations may change the state of the modeled system. Operations are modeled by what must be true after the operation is completed. The computation or transformation that activates this condition cannot be expressed.

Notation and Semantics

OCL uses keywords to define (as a constraint or expression) basic relationships that are not easily shown with UML diagrams. These include:

1. Class and type invariants;
2. Type invariants for stereotypes;
3. Pre- and post-conditions on operations/methods;
4. All forms of guards;
5. Specification of the result of a computation in a nonprocedural manner.

Summary of OCL Elements

Examples. Get details later ...

Limitations

The limitations of the object constraint language are as follows:

1. Add details soon ...

• Bennett S., Skelton J., and Lunn K., UML: Schaum's Outlines , McGraw-Hill, January, 2001.
• Binder R.V., Testing Object-Oriented Systems: Models, Patterns and Tools , Addison-Wesley, 2000.
• Gomaa H., Designing Concurrent, Distributed, and Real-Time Applications with UML, Addison-Wesley, 2000.
• Meilich A., Friedenthal S., Lykins H., "Object-Oriented Systems Engineering," Notes from Tutorial Program F6, INCOSE 2001, Melbourne, Australia, July 2001.
• Object Constraint Language (OCL) Center
• IBM Application Development : Object Constraint Language (OCL)
• Ogren I., "Possible Tailoring of the UML for Systems Engineering Purposes," Systems Engineering , Vol. 3, No. 4, pp. 212-224, 2000.

Developed in March 2001 by Mark Austin
Copyright © 2001, Mark Austin, University of Maryland