UML Diagram Notation and Semantics

UML Diagram Notation and Semantics

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

UML DIAGRAMS

Activity Diagrams
Class Diagrams
Collaboration Diagrams
Component Diagrams
Deployment Diagrams
Sequence Diagrams
Statechart Diagrams
Use-Case Diagrams

EXTENSIONS TO UML

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.

As a general-purpose modeling language, it focuses on a core set of concepts for acquiring, sharing, and utilizing knowledge coupled with extensibility mechanisms.
As a broadly applicable modeling language, it may be applied to different types of systems (software and non-software), domains (business versus software), and methods or processes.
As a tool-supported modeling language, tools are readily available to support the application of the language to specify, visualize, construct, and document systems.
As an industry-standardized modeling language, it is not a proprietary and closed language but an open and fully extensible industry-recognized language.

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.

Within a system-intensive process, a method is applied as a process to derive or evolve a system.
As a language, it is used for communication. That is, a means to capture knowledge (semantics) about a subject and express knowledge (syntax) regarding the subject for the purpose of communication. The subject is the system under discussion.
As a modeling language, it focuses on understanding a subject via the formulation of a model of the subject (and its related context). The model embodies knowledge regarding the subject, and the appropriate application of this knowledge constitutes intelligence.
Regarding unification, it unifies the information systems and technology industry's best engineering practices across types of systems (software and non-software), domains (business versus software), and life-cycle processes.
As it applies to specifying systems, it can be used to communicate "what" is required of a system, and "how" a system may be realized.
As it applies to visualizing systems, it can be used to visually depict a system before it is realized.
As it applies to constructing systems, it can be used to guide the realization of a system similar to a "blueprint".
As it applies to documenting systems, it can be used for capturing knowledge about a system throughout its life-cycle.

The UML is not:

A visual programming language, but a visual modeling language.
A tool or repository specification, but a modeling language specification.
A process. Rather, it enables processes.

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:

Package Diagrams and Packages. A package is a group of UML diagrams. A package diagram shows the organization of packages.
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 repreent a type, a class, a meta-class, or an object. A double bracketed label defines a kind of clasifier, for example: <<class>>, <<type>>, <<metaclass>> and <<object>>. Keywords are reserved.
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).
Notes. Notes may be connected to diagram elements or free standing.
Element Properties. The properties of an element are displayed in braces and designated by a tag expression.

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.

For each UML diagram representing requirements of the SUT (??) and for each application-specific instance of a UML relationship type that appears in that diagram, at least one actual test achieves the generic test requirements for an implementation intance of that application-specific relationship.

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:

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

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

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 swimlanes, 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.

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.

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:

The nodes in a class diagram indicate various types of classes, objects, and interfaces.
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.

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:

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."
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:

An association between two classes is called a "binary association."
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).

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

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:

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

The objects in rectangles represent the class roles.
The links (lines or paths) represent association roles.
The arrows between class roles indicate message flows exchanged between objects.
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:

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

Messages that differ in one integer for a sequence at the same level of nesting.
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:

Because links among collaboration diagram nodes allow more than one message to be sent, execution paths cannot be traced directly from the links.
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:

The organization of and dependencies among implementation components. Components are physical units containing, for example, source code, object code, and so forth.
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:

Components are drawn as rectangles with two small boxes on one side.
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,

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:

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:

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

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:

They are really only suitable for modeling of software systems.
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:

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

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

Messages that differ in one integer for a sequence at the same level of nesting.
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:

As indicated above, the objects participating in the interaction are arranged horizontally across the diagram, and the vertical axis represents time.
The vertically-oriented dashed line eminating from each object is called a life line.
The actor is usually shown on the left-hand side of a sequence diagram.
Labeled horizontal arrows represent messages passed between objects.
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).
Time increases from the top of the diagram to the bottom of the diagram.
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:

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

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:

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

The nodes ......
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:

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

Beginning states are drawn as a large black dot. End states are drawn as a black dot with a surrounding circle.
States are drawn as rectangles with rounded corners. They are considered to exist for some finite period (albeit, sometimes very short) of time.
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:

Preparation of the proposal draft may be abandoned because there aren't any good ideas....
A final draft of the proposal may not happen, perhaps because there is insufficient time to work on it.
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:

Here we assume that the account is opened and closed with a "Zero Balance" state.
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.
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:

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:

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.
When the test procedure is completed successfully, the system state automatically moves from the "System Test" state to the "System Operation" state.
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:

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:

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

Related activities in which use cases can participate include:

Determine of development increments;
Establishment of traceability;
Conceptualization and prototyping;
Determination of system boundaries;
Development of resource and effort sizing;
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.

Points to note are as follows:

A system boundary is an abstraction of the implementation interface that accepts and transports external inputs and outputs.
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.
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:

The nodes in a use case label the actors, individual use cases, and the complete system encompassing the use cases.
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:

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

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

Tests of the basic flow of events;
Tests of abnormal flow of events;
Tests of line-item requirements traceable to each use case;
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:

Class and type invariants;
Type invariants for stereotypes;
Pre- and post-conditions on operations/methods;
All forms of guards;
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

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.