UML Diagram Notation and Semantics

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

Features and Uses of UML

Features of UML. The UML is an evolutionary general-purpose, broadly applicable, tool-supported, and industry-standardized modeling language. Few restrictions are placed on its usage -- in fact, it applies to a multitude of different types of systems, domains, and methods or processes.

The UML enables the capturing, communicating, and leveraging of strategic, tactical, and operational knowledge to facilitate increasing value by increasing quality, reducing costs, and reducing time-to-market while managing risks and being proactive in regard to ever-increasing change and complexity.

Uses of UML. The UML is a modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process.

The UML is not:

Fundamentally, the UML is concerned with capturing, communicating, and levering knowledge.

General-Purpose Elements. General purpose elements are used to organize elements and express details. They include:

Built-in Test Strategies. Built-in relationships have corresponding generic test requirements that can be identified by applying a relational test strategy to each UML diagram.

If nothing else, the analysis will establish traceability from each element of the application model to the implementation under test and the corresponding test suite. This exercise nearly always reveals ommisions and inconsistencies.

Activity Diagrams

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

  Diagram Element Symbol Represents
Nodes Action state Horizontal capsule A process
  Decision Diamond Next step may be only one of several sucessors
  Swim lane Parallel vertical lines A group of related processes
  Synchronization point Thick bar All predecessors must terminate before the successor can start
  Object Object box An object, component, or subsystem
  Signal receiver Notched rectangle The successor cannot be started until the signal is received
  Signal sender Pointy rectangle A signal is sent before the successor start
  Initial action state Filled circle Predecessor to the first action state
  Final action state Bull's eye Final action state
Edges Control flow Solid arrow Pre- and post-decessor relationship
  Message flow Dashed arrow Message sent to/from an object
  Signal flow Dashed arrow A pair of sender/reveiver nodes

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.

[Activities and States]

Figure : Format for Activities and States

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

[Activities and States]

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

[Activity Diagram]

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

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

Example 2. Branching in an Activity Diagram

[Activity Diagram]

Figure : Use of Branching Constructs in an Activity Diagram

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

Example 3. Looping in an Activity Diagram

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

[Activity Diagram]

Figure : Use of Looping Constructs in an Activity Diagram

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

Example 4. Use of Synchronization Bars

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

[Activity Diagram]

Figure : Use of Synchronization Bars in an Activity Diagram

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

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 activites in the diagram are organized into swim lanes.

[Activity Diagram]

Figure : Use of Swim Lanes in an Activity Diagram

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

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.

[Activity Diagram]

Figure : Displaying objects on an Activity Diagram

Points to note are as follows:

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.

[Complex Systems]

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.

    [OO Behavior]

    Figure : Non Object-Oriented Control Flow

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

    [OO Behavior]

    Figure : Object-Oriented Control Flow

    Points to note are as follows:

Class 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.

[Object-oriented view of a system]

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 paticular 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

  Diagram Element Symbol Represents
Nodes Type Class box <<type>> A role or entity; may have attribute but no operations
  Class Class box (name, operation, and attribute compartments) An implementation class
  Interface Class box or small circle Abstract class, Java interface, ...
  Parameterized class Class box with parameter box C++ template class, Eiffel generic, ... etc
  Meta-class Class box <<metaclass>> An implementation of a meta-class
  Association class Class box An association as a class
  Object Object box (name and attribute compartments); the name is underlined and in the form Classname:ObjectName The instance of a class
  Composite object Object box with object boxes in the attribute compartment The attributes of a composite object as a graph, allowing relationships to be shown
  Utility Class box <<utility>> A group of global variables and procedures
Edges Association (binary) Undirected element with ornaments A required pair-wise property between instances of the classifier
  Association (n-ary) A large diamond with association lines An association among instances of three or more classifiers
  Association path Undirected dashed line Connects an association class to an association line
  Or association Undirected dashed line (or) Indicates that exactly one of the spanned associations holds for any given set of classifier instances
  Association qualifier Box with attribute(s) names, between an object and an association line The attributes that identify instance-pair subsets of an association; similar to the key of a database or file
  Aggregation Line with a small, unfilled, diamond at the container end The contained classifier is a part of the container classifier and may be created and destroyed independently of the container
  Composition Line with a small, filled, diamond at the container end The container classifier is a part of the container classifier and is created and destroyed along with the container
  Generalization Line with an unfilled triangle at the general end The specialized is a kind of the general classifier (e.g., a subclass of a super-class)
  Dependency Dashed arrow A physical or logical reference such that changing the target classifier may require changing of the source classifier
  Link Line between two objects A list of object references; an instance of an association
  Realizes Dashed line with solid triangular arrowhead Indicates an implementation class for a type

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.

[UML Generalization]

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

[Account Generalization]

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.

[UML Aggregation]

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!

[UML Composition]

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.

[UML Class Multiplicity]

Points to note are as follows:

  1. An association between two classes is called a "binary association."
  2. If an association is labelled, 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).

[UML Class Multiplicity]

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

[UML Class Multiplicity]

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 dispensor delivers cash to the customer.

Limitations. The limitations of class diagrams are as follows:

Collaboration Diagrams

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:

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

  Diagram Element Symbol Represents
Nodes Object role Classifier box An object, component, or subsystem
  Multiobject Stacked classifier box A collection of the same kind of objects
  Active object Classifier box with heavy border An object that runs as an independent process, task, or thread
Edges Link Solid line Visibility required between two object roles
  Procedure call Line with filled arrowhead Suspend/resume message sent to a role
  Flat control flow Line with open arrowhead Predecessor/successor relationship within a method
  Asynchronous control flow Line with open half-arrowhead Nonblocking message sent to a role

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.

[ Object Notation 1 ]

Figure : Examples of object instance names

A summary of the syntax is as follows:

Syntax Description
    o
An object named o.
    o:C
An object named o from class C.
    :C
An anonymouse object from class C.
    /R
An anonymouse object playing the role R.
    /R:C
An anonymouse object of class C playing the role R.
    o/R
An object o playing the role R.
    o/R:C
An object o from class C, playing the role R.

Table : Syntax of instance names

Message Flow Notation and Sequence Numbers

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

Message Type Description
[ Message 1 ]
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.
[ Message 1 ]
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.
[ Message 1 ]
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.
[ Message 1 ]
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,

[ Association ]

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):

[ Association example ]

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:

[ Association example ]

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.

[ UML Collaboration ]

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,

[ Association example ]

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,

[ Association example ]

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.

Component Diagrams

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

  Diagram Element Symbol Represents
Nodes Component Rectangle with two small box extensions on one side A software entity visible to the target environment
  Interface Small unfilled circle A symbolic identifier visible to target environment that supports activation and parameter passing
Edges Message flow Dashed arrow Message sent to/from a component
  Source code dependency Dashed arrow Components cannot operate without one another

Example 1.

In the adjacent component diagram,

[Client-Supplier System]

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,

[Client-Supplier System]

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

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

  Diagram Element Symbol Represents
Nodes Node Rectangle with dropped sides A processor
  Component Rectangle with two small box extensions on one side A software entity visible to the target environment
  Interface Small unfilled circle A symbolic identifier visible to the target environment that supports activation and parameter passing
Edges Communication association Solid line A communication channel
  Component dependency Dashed arrow The node(s) on which a component may run

Example 1.

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

[Deployment of 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.

Sequence Diagrams

Like the colloration diagram , sequence diagrams provide a graphical representation for how a task is accomplished by passing a sequence of messaqes 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 recusive 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

  Diagram Element Symbol Represents
Nodes Object Object box An object box designates an object that participates in and interaction. The object may be a composition; that is, it can represent a component, an entire subsystem, or an interface to an external system.
  Object lifeline A dashed vertical line that connects the object box to an activation interval An activation interval for the object.
  Object activation Narrow rectangle The presence or absense of an object instance during a scenario
  Conditional branch Short narrow rectangle connected by dashed lines to an activation box Conditional code segment within a method; used for diagramming convenience
  Recursive activation Short narrow rectangle, overlaying an object activation box, pointed to by a looping arrow Recursive activation
Edges Suspend/resume procedure call Solid arrow A message that suspends activation of the sender
  Nonblocking procedure call A solid line with a half-open arrowhead A message that does not suspend activation of the sender
  Conditional procedure calls Solid lines leaving the same point on the activation box Only one of the indicated procedure calls will be sent
  Procedure call loop A narrow rectangle that partially overlays an object activation box The condition that selects each call may be written near the line, in brackets
  Recursive call Loop arrow to a recursive activation box Recursive call
  Procedure call delay A downward-sloping arrow Significant message transmit time

Object and Class Notation

UML has a well-defined syntax for instance names.

[ Object Notation 1 ]

Figure : Examples of object instance names

A summary of the syntax is as follows:

Syntax Description
    o
An object named o.
    o:C
An object named o from class C.
    :C
An anonymouse object from class C.
    /R
An anonymouse object playing the role R.
    /R:C
An anonymouse object of class C playing the role R.
    o/R
An object o playing the role R.
    o/R:C
An object o from class C, playing the role R.

Table : Syntax of instance names

Message Flow Notation and Sequence Numbers

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

Message Type Description
[ Message 1 ]
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.
[ Message 1 ]
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.
[ Message 1 ]
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.
[ Message 1 ]
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.

[ UML Sequence ]

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 eminating 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.

[ Sequence Return and Activation ]

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.

[ Asynchronous Messages ]

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).

[ Create/Destroy Objects ]

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

[ Create/Destroy Objects ]

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.

[ Textual Annotations ]

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.

Statechart Diagrams

State modeling is the final view of behavior modeling we will consider here. This method provides a good way of capturing the behavior (i.e., pattern of activity) of a system of known structure.

Diagrams for state modeling provide a convenient means for visualizing leaf-level behavior of a system whose development is beyond the trade-off phase. One such diagramming format is the statechart, which describes the states and responses of a class (or system) in response to external stimulii. Statechart diagrams include the following elements:

  1. States. States represent the situations during the life on an object in which it is active (e.g., performs an activitiy; waits for an event; satisfies a condition).
  2. Transitions. Transitions represent relationships between different states of an object. We are interested in: (1) the events causing transitions; (2) the conditions under which a transition can take place (assuming an appropriate event has occurred); (3) actions (if any) taken when the transition happens.

A finite state machine is a conceptual machine with a finite number of states. A state transition is a change in state that is caused by an imput 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.

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 refered to as a statechart diagram. And the latter are derived from Harel's statechart notation (see details below).

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.

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

Explain background and benefits of statecharts -- see, for example, Oliver, pg's 63-67.

Notation and Semantics. Statechart diagrams are an assembly of nodes and elements:

  1. The nodes ......
  2. The edges ......

Summary of Features for UML and Harel Statechart Diagrams

 
UML Statechart [OMG 98]
Harel Statechart [Harel 97]
Basic Semantics Hybrid Mealy
Event content Message parameters, <<signal>> mapping. Any digital or analog signal of interest.
Composite Events Not allowed, unless represented as parameters of a single message. Arbitrary number of external signals.
Built-in Operations after, when, entry, exit, do, history. history, entered(s), exited(s), true(condition), tr!(c) (make true), fs!(c)
Interpretation of concurrency Global visibility of variables defined in the "context" of the statechart and public within the scope of the modeled component. Processes that execute independently; does not model a collection of variables (objects) in the same memory space as concurrent processes.
Broadcast event Not defined, but can be modeled by messages on actions. Built-in broadcasting across boundaries of all processes.
Implicit mechanism Class (as server) with unspecified client. Nonspecific.
Process Not defined; the scope of a state or superstate is a class or a method. An "XOR" group or superstate.
Transition components Limited to message semantics. Any combination of states, transitions, guards and labels.
History Shallow and deep semantics. Built-in function.
Scope/ownership of guards Guards are visible to implicit client unless specified otherwise. As implied by the object-model diagram.
Ordering of actions Default is single-thread synchronous message calling sequence; multi-thread semantics may be modeled. Default is asynchronous; message passing is assumed to be queued.
Transition interval Indefinite nonzero interval. Instantaneous atomoc.

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.

[Statechart Basics]

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.

[Statechart Basics]

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).

[Statechart Basics]

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.

[Temp Sensor] 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:

[Statechart Basics]

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:

[Statechart Basics]

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).

[Statechart Basics]

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. Statechart diagrams can quickly become unmanageagle with increasing problem size.

Use-Case Diagrams

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 dialogue with the system. Such a sequence of transactions is called a use case.

[Use Case Diagram]

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

  Diagram Element Symbol Represents
Nodes Actors Stick figure Any external input source or response sink. Can be a human user, other computer systems, electromechanical systems .... etc.
  Use Cases Oval A collection of interactions that define a user-defined task.
  System Box A system that supports a use case(s).
Edges A communicates with U Arrow Links actors with use cases
  U1 extends U2 Generalization U1's behavior is added to U2
  U1 uses U2 Generalization U1's behavior is added to U2

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:

and graphically drawn:

[UML Usecase Relationships]

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.

Use-Case Testing. Jacobson (1992) suggests four general kinds of tests that can be derived from use cases:

  1. Tests of the basic flow of events;
  2. Tests of abnormal flow of events;
  3. Tests of line-item requirements traceable to each use case;
  4. Tests of features in the user documentation traceable to each use case.

Beyond this classification, guidance is not given on how test procedures should be constructed.

Also note that a use case describes the existence of interactions, but does not specify the interaction content. Hence, use cases as defined in UML are "necessary but not sufficient" for system test design. For system test procedures to be more complete, we need: (1) the domain of each variable that participates in each use case; (2) the required input/output relationships among the use case variables; (3) the relative frequency of each use case; (4) sequential dependecies among use cases. One way of handling this is to create inventories of operational variables at the system boundary, instances of use cases, and definitions of operational variables.

Examples. See Chapt 8 of Binder, 2001.

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

Object Constraint Language

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 achies 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

  Diagram Element Symbol Represents
Nodes
Edges

Examples. Get details later ...

Limitations. The limitations of the object constraint language are as follows:

References


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