UML Tutorial

The Unified Modeling Language (UML) has quickly become the de-facto standard for
building Object-Oriented software. This tutorial provides a technical overview of the 13
UML diagrams supported by Enterprise Architect. UML 2 semantics are explained in detail
in the new UML 2.0 tutorial.

Firstly... What is UML?

The OMG specification states:

"The Unified Modeling Language (UML) is a graphical language for visualizing,

specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual
things such as business processes and system functions as well as concrete things such
as programming language statements, database schemas, and reusable software
components."

The important point to note here is that UML is a 'language' for specifying and not a method
or procedure. The UML is used to define a software system; to detail the artifacts in the
system, to document and construct - it is the language that the blueprint is written in. The
UML may be used in a variety of ways to support a software development methodology
(such as the Rational Unified Process) - but in itself it does not specify that methodology or
process.

UML defines the notation and semantics for the following domains:

- The User Interaction or Use Case Model - describes the boundary and interaction between
the system and users. Corresponds in some respects to a requirements model.
- The Interaction or Communication Model - describes how objects in the system will
interact with each other to get work done.
- The State or Dynamic Model - State charts describe the states or conditions that classes
assume over time. Activity graphs describe the workflows the system will implement.
- The Logical or Class Model - describes the classes and objects that will make up the
system.
- The Physical Component Model - describes the software (and sometimes hardware
components) that make up the system.
- The Physical Deployment Model - describes the physical architecture and the deployment
of components on that hardware architecture.

The UML also defines extension mechanisms for extending the UML to meet specialized
needs (for example Business Process Modeling extensions).

Part 2 of this tutorial expands on how you use the UML to define and build actual systems.

See also Business Process Modeling (pdf).

The Use Case Model
A Use Case Model describes the proposed functionality of a new system. A Use Case
represents a discrete unit of interaction between a user (human or machine) and the system.
This interaction is a single unit of meaningful work, such as Create Account or View Account
Details.

Each Use Case describes the functionality to be built in the proposed system, which can
include another Use Case's functionality or extend another Use Case with its own behavior.

A Use Case description will generally includes:

 General comments and notes describing the use case.

 Requirements - The formal functional requirements of things that a Use Case must
provide to the end user, such as <ability to update order>. These correspond to the
functional specifications found in structured methodologies, and form a contract that
the Use Case performs some action or provides some value to the system.
 Constraints - The formal rules and limitations a Use Case operates under, defining
what can and cannot be done. These include:
o Pre-conditions that must have already occurred or be in place before the use
case is run; for example, <create order> must precede <modify order>
o Post-conditions that must be true once the Use Case is complete; for example,
<order is modified and consistent>
o Invariants that must always be true throughout the time the Use Case operates;
for example, an order must always have a customer number.
 Scenarios – Formal, sequential descriptions of the steps taken to carry out the use
case, or the flow of events that occur during a Use Case instance. These can include
 multiple scenarios, to cater for exceptional circumstances and alternative processing
paths. These are usually created in text and correspond to a textual representation of
the Sequence Diagram.
 Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios
but graphically portrayed.
 Additional attributes, such as implementation phase, version number, complexity
rating, stereotype and status.

Actors

Use Cases are typically related to 'actors', which are human or machine entities that use or
interact with the system to perform a piece of meaningful work that helps them to achieve a
goal. The set of Use Cases an actor has access to defines their overall role in the system and
the scope of their action.

Includes and Extends relationships between Use Cases

One Use Case could include the functionality of another as part of its normal processing.
Generally, it is assumed that the included Use Case is called every time the basic path is run.
For example, when listing a set of customer orders to choose from before modifying a
selected order, the <list orders> Use Case would be included every time the <modify order>
Use Case is run.

A Use Case can be included by one or more other Use Cases, so it helps to reduce duplication
of functionality by factoring out common behavior into Use Cases that are re-used many
times.

One Use Case can extend the behavior of another, typically when exceptional circumstances
are encountered. For example, if a user must get approval from some higher authority before
modifying a particular type of customer order, then the <get approval> Use Case could
optionally extend the regular <modify order> Use Case.

Sequence Diagrams

Sequence diagrams provide a graphical representation of object interactions over time. These
typically show a user or actor, and the objects and components they interact with in the
execution of a use case. One sequence diagram typically represents a single Use Case
'scenario' or flow of events.
Sequence diagrams are an excellent way of documenting usage scenarios and both capturing
required objects early in analysis and verifying object use later in design. The diagrams show
the flow of messages from one object to another, and as such correspond to the methods and
events supported by a class/object.

The following example of a sequence diagram shows the user or actor on the left initiating a
flow of events and messages that correspond to the Use Case scenario. The messages that
pass between objects become class operations in the final model.

Implementation Diagram

A Use Case is a formal description of functionality that the system will have when
constructed. An implementation diagram is typically associated with a Use Case to document
which design elements (for example, components and classes) implement the Use Case
functionality in the new system. This provides a high level of traceability for the system
designer, the customer and the team that will actually build the system. The list of Use Cases
that a component or class is linked to documents the minimum functionality that must be
implemented by the component.
The example above shows that the use case 'Login' implements the formal requirement '1.01
Log On to the website'. It also shows that the 'Business Logic' component and 'ASP Pages'
component implement some or all of the 'Login' functionality. A further refinement is to
show the 'Login' screen (a web page) as implementing the 'Login' use case. These
implementation or realization links define the traceability from the formal requirements,
through use cases on to components and screens.

The Dynamic Model

The dynamic model is used to express and model the behaviour of the system over time. It
includes support for activity diagrams, state diagrams, sequence diagrams and extensions
including business process modelling.

Sequence Diagrams
Sequence diagrams are used to display the interaction between users, screens, objects and
entities within the system. It provides a sequential map of message passing between objects
over time. Frequently these diagrams are placed under Use Cases in the model to illustrate the
use case scenario - how a user will interact with the system and what happens internally to
get the work done. Often, the objects are represented using special stereotyped icons, as in the
example below. The object labelled Login Screen is shown using the User Interface icon. The
object labelled SecurityManager is shown using the Controller icon. The Object labelled
users is shown using the Entity icon.
Activity Diagrams
Activity diagrams are used to show how different workflows in the system are constructed,
how they start and the possibly many decision paths that can be taken from start to finish.
They may also illustrate the where parallel processing may occur in the execution of some
activities.
State Charts
State charts are used to detail the transitions or changes of state an object can go through in
the system. They show how an object moves from one state to another and the rules that
govern that change. State charts typically have a start and end condition.
Process Model
A process model is a UML extension of an activity diagram used to model a business process
- this diagram shows what goal the process has, the inputs, outputs, events and information
that are involved in the process.
The Logical Model
A logical model is a static view of the objects and classes that make up the design/analysis
space. Typically, a Domain Model is a looser, high level view of Business Objects and
entities, while the Class Model is a more rigorous and design focused model. This discussion
relates mainly to the Class Model

The Class Model

A Class is a standard UML construct used to detail the pattern from which objects will be
produced at run-time. A class is a specification - an object an instance of a class. Classes may
be inherited from other classes (that is they inherit all the behavior and state of their parent
and add new functionality of their own), have other classes as attributes, delegate
responsibilities to other classes and implement abstract interfaces.

The Class Model is at the core of object-oriented development and design - it expresses both
the persistent state of the system and the behavior of the system. A class encapsulates state
(attributes) and offers services to manipulate that state (behavior). Good object-oriented
design limits direct access to class attributes and offers services which manipulate attributes
on behalf of the caller. This hiding of data and exposing of services ensures data updates are
only done in one place and according to specific rules - for large systems the maintenance
burden of code which has direct access to data elements in many places is extremely high.

The class is represented as below:

Note that the class has three distinct areas:

1. The class name (and stereotype if applied)

2. The class attributes area (that is internal data elements)
3. The behavior - both private and public

Attributes and methods may be marked as

- Private, indicating they are not visible to callers outside the class
- Protected, they are only visible to children of the class
- Public, they are visible to all

Class inheritance is shown as below: an abstract class in this case, is the parent of two
children, each of which inherits the base class features and extends it with their own
behavior.
Class models may be collected into packages of related behavior and state. The diagram
below illustrates this.

The Component Model

The component model illustrates the software components that will be used to build the
system. These may be built up from the class model and written from scratch for the new
system, or may be brought in from other projects and 3rd party vendors. Components are
high level aggregations of smaller software pieces, and provide a 'black box' building block
approach to software construction.

Component Notation
A component may be something like an ActiveX control - either a user interface control or a
business rules server. Components are drawn as the following diagram shows:

The Component Diagram

The component diagram shows the relationship between software components, their
dependencies, communication, location and other conditions.

Interfaces
Components may also expose interfaces. These are the visible entry points or services that a
component is advertising and making available to other software components and classes.
Typically a component is made up of many internal classes and packages of classes. It may
even be assembled from a collection of smaller components.
Components and Nodes
A deployment diagram illustrates the physical deployment of the system into a production (or
test) environment. It shows where components will be located, on what servers, machines or
hardware. It may illustrate network links, LAN bandwidth & etc.

Requirements
Components may have requirements attached to indicate their contractual obligations - that
is, what service they will provide in the model. Requirements help document the functional
behaviour of software elements.

Constraints
Components may have constraints attached which indicate the environment in which they
operate. Pre-conditions specify what must be true before a component can perform some
function; post-conditions indicate what will be true after a component has done some work
and Invariants specify what must remain true for the duration of the components lifetime.

Scenarios
Scenarios are textual/procedural descriptions of an object's actions over time and describe the
way in which a component works. Multiple scenarios may be created to describe the basic
path (a perfect run through) as well as exceptions, errors and other conditions.

Traceability
You may indicate traceability through realisation links. A component may implement another
model element (eg. a use case) or a component may be implemented by another element (eg.
a package of classes). By providing realisation links to and from components you can map
the dependencies amongst model elements and the traceability from the initial requirements
to the final implementation.
An Example
The following example shows how components may be linked to provide a
conceptual/logical view of a systems construction. This example is concerned with the server
and security elements of an on-line book store. It includes such elements as the web server,
firewall, ASP pages & etc.

Server Components
This diagram illustrates the layout of the main server side components that will require
building for an on-line book store. These components are a mixture of custom built and
purchased items which will be assembled to provide the required functionality.

Security Components
The security components diagram shows how security software such as the Certificate
Authority, Browser, Web server and other model elements work together to assure security
provisions in the proposed system.
The Physical Model
The Physical/Deployment Model provides a detailed model of the way components will be
deployed across the system infrastructure. It details network capabilities, server
specifications, hardware requirements and other information related to deploying the
proposed system.

Deployment View

Physical Model
The physical model shows where and how system components will be deployed. It is a
specific map of the physical layout of the system. A deployment diagram illustrates the
physical deployment of the system into a production (or test) environment. It shows where
components will be located, on what servers, machines or hardware. It may illustrate network
links, LAN bandwidth & etc.
A node is used to depict any server, workstation or other host hardware used to deploy
components into the production environment. You may also specify the links between nodes
and assign stereotypes (such as TCP/IP) and requirements to them. Nodes may also have
performance characteristics, minimum hardware standards, operating system levels & etc.
documented. The screen below illustrates the common properties you can set for a node.
UML Tutorial - Part 2
We have established in Part 1 that the UML is a language for specifying the artifacts and
interactions of a software system. We have also seen that it deals with 6 major domains -
from Use Case models, through dynamic and logical models to the final physical deployment
model - and that extension mechanisms have been included to allow for specialised additions
to the model notation.

So... How do you use the UML?

The UML is typically used as a part of a software development process, with the support of a
suitable CASE tool, to define the requirements, the interactions and the elements of the
proposed software system. The exact nature of the process depends on the development
methodology used. An example process might look something like the following:

1. Capture a Business Process Model. This will be used to define the high level business
activities and processes that occur in an organization and to provide a foundation for the
Use Case model. The Business Process Model will typically capture more than a software
system will implement (ie. it includes manual and other processes).
2. Map a Use Case Model to the Business Process Model to define exactly what
functionality you are intending to provide from the business user perspective. As each Use
Case is added, create a traceable link from the appropriate business processes to the Use
Case (ie. a realisation connection). This mapping clearly states what functionality the new
system will provide to meet the business requirements outlined in the process model. It
also ensures no Use Cases exist without a purpose.
3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and
scenarios. This information unambiguously describes what the Use Case does, how it is
executed and the constraints on its execution. Make sure the Use Case still meets the
business process requirements. Include the definition of system tests for each use case to
define the aceptance criteria for each use case. Also include some user acceptance test
scripts to define how the user will test this functionality and what the acceptance criteria
are.
4. From the inputs and outputs of the Business Process Model and the details of the use
cases, begin to construct a domain model (high level business objects), sequence
diagrams, collaboration diagrams and user interface models. These describe the 'things' in
the new system, the way those things interact and the interface a user will use to execute
use case scenarios.
5. From the domain model, the user interface model and the scenario diagrams create the
Class Model. This is a precise specification of the objects in the system, their data or
attributes and their behaviour or operations. Domain objects may be abstracted into class
hierarchies using inheritance. Scenario diagram messages will typically map to class
operations. If an existing framework or design pattern is to be used, it may be possible to
import existing model elements for use in the new system. For each class define unit tests
and integration tests to thoroughly test i) that the class functions as specified internally
and that ii) the class interacts with other related classes and components as expected.
6. As the Class Model develops it may be broken into discrete packages and components. A
component represents a deployable chunk of software that collects the behaviour and data
of one or more classes and exposes a strict interface to other consumers of its services. So
 from the Class Model a Component Model is built to define the logical packaging of
classes. For each component define integration tests to confirm that the component's
interface meets the specifcation given it in relation to other software elements.
7. Concurrent with the work you have already done, additional requirements should have
been captured and documented. For example - Non Functional requirements, Performance
requirements, Security requirements, responsibilities, release plans & etc. Collect these
within the model and keep up to date as the model matures.
8. The Deployment model defines the physical architecture of the system. This work can be
begun early to capture the physical deployment characteristics - what hardware, operating
systems, network capabilities, interfaces and support software will make up the new
system, where it will be deployed and what parameters apply to disaster recovery,
reliability, back-ups and support. As the model develops the physical architecture will be
updated to reflect the actual system being proposed.
9. Build the system: Take discrete pieces of the model and assign to one or more developers.
In a Use Case driven build this will mean assigning a Use Case to the development team,
having them build the screens, business objects, database tables, and related components
necessary to execute that Use Case. As each Use Case is built it should be accompanied
by completed unit, integration and system tests. A Component driven build may see
discrete software components assigned to development teams for construction.
10. Track defects that emerge in the testing phases against the related model elements - eg.
System test defects against Use Cases, Unit Test defects against classes & etc. Track any
changes against the related model elements to manage 'scope creep'.
11. Update and refine the model as work proceeds - always assessing the impact of changes
and model refinements on later work. Use an iterative approach to work through the
design in discrete chunks, always assessing the current build, the forward requirements
and any discoveries that come to light during development.
12. Deliver the complete and tested software into a test then production environment. If a
phased delivery is being undertaken, then this migration of built sofware from test to
production may occur several times over the life of the project.

Note that the above process is necessarily brief in description, leaves much unsaid and may
not be how you work or follow the process you have adopted. It is given as an example of
how the UML may be used to support a software development project.
The Business Process Model
Download PDF version

Introduction

Traditionally, the UML has been associated more with software engineering and systems
design than with analysis and modeling of business processes. However, standard UML 2.x
provides a rich set of behavioral models which are very useful in modeling the processes,
activities, people and information critical to every business.

Beyond the standard UML notation, two well respected and proven UML “extensions” exist
which further enhance the capturing of business process and related constructs. The first is
Business Process Modeling Notation (BPMN), which has gained enormous popularity and is
rapidly becoming a new standard for modeling and designing business processes. The second
is the Ericsson-Penker profile which has less popularity, but still provides a unique and
powerful means of visualizing and communicating business processes and the necessary flow
of information within an organization.

This paper provides a very high-level introduction to both of these “extensions”, showing
how they can be used in Enterprise Architect and some of the common modeling constructs
they use.

Business Process Modeling Notation (BPMN)

BPMN defines a Business Process Diagram (BPD), which is based on a flowcharting

technique tailored for creating graphical models of business process operations. It is a
notation that is readily understandable by all business users, from the business analysts that
create the initial drafts of the processes, to the technical developers responsible for
implementing the technology that will perform those processes, and finally, to the business
people who will manage and monitor those processes.

A BPMN model consists of simple diagrams with a small set of graphical elements.

Flow Elements

1. Activities. An activity is work that is performed within a business process and is represented
by a rounded rectangle.
2. Events. An event is something that happens during the course of a business process which
affects the sequence or timing of activities of a process. Events are represented as small
circles with different boundaries to distinguish start events (thin black line), intermediate
events (double line) and end events (thick black line). Events can show icons within their
shape to identify the trigger or result of the event.
3. Gateways. Gateways are used to control how sequence flows converge and diverge within a
process. Gateways can represent decisions, where one or more paths are disallowed, or they
can represent concurrent forks.
 1. Sequence flows. A sequence flow is used to show the order in which activities are performed
within a process. A sequence flow is represented by a line with a solid arrowhead.
2. Message flows. A message flow is used to show the flow of messages between two entities,
where pools are used to represent entities. A message flow is represented by a dashed line
with a light-colored circle at the source and arrowhead at the target.
3. Associations. An association is used to associate information and artifacts with flow objects.
An association is represented by a dashed line which may or may not have a line arrowhead
at the target end if there is a reason to show directionality.

Swimlanes (Partitions)

1. Pools. A pool represents a participant in a process, where a participant may be a business

entity or role. It is represented as a partition of the process.
2. Lanes. A lane is a sub-division of a pool and is used to organize and categorize activities
within the pool.

Artifacts

1. Data objects. A data object does not have a direct affect on a process but does provide
information relevant to the process. It is represented as a rectangle with the top corner
folded over.
2. Groups. A group is an informal means for grouping elements of a process. It is represented
as a rectangle with a dashed line border.
3. Annotations. An annotation is a mechanism for the BPMN modeler to provide additional
information to the audience of a BPMN diagram. It is represented by an open rectangle
containing the annotation text.

BPMN Examples

Example 1:

The above diagram illustrates a number of key features of BPMN, specifically the ability to
create hierarchical decomposition of processes into smaller tasks, the ability to represent
looping constructs and the ability to have external events interrupt the normal process flow.
"Upstream Activities" and "Downstream Activities" are link-triggered intermediate events; in
other words, off-page connectors.

"Repeat for Each Supplier" is a looping activity, which repeats its three contained activities
either once for each supplier or until a time limit is exceeded. The intermediate event
mounted on the lower edge of the activity is a time-triggered event.

Example 2:

The above diagram shows a process being initiated by an event - in this case a message-
triggered start event which notifies the process that the working group is active. The diagram
also shows a loop being controlled by a timer event, and it shows a decision gateway (in this
case, an XOR decision gateway) controlling when the loop is terminated.

Example 3:

This diagram illustrates the use of pools to show interacting processes and the way that
messages are passed between pools using message flow connectors.
 

Eriksson-Penker Business Modeling Profile

This section provides an introduction to the terminology and icons used in the Business
Process Model, and gives a quick introduction to some Unified Modeling Language (UML)
concepts and how they are applied in Enterprise Architect's Business Process Model.

A business process:

1. Has a Goal
2. Has specific inputs
3. Has specific outputs
4. Uses resources
5. Has a number of activities that are performed in some order
6. May affect more than one organizational unit. Horizontal organizational impact
7. Creates value of some kind for the customer. The customer may be internal or external.

Process Models

A business process is a collection of activities designed to produce a specific output for a

particular customer or market. It implies a strong emphasis on how the work is done within
an organization, in contrast to a product's focus on what a process is. Thus a specific ordering
of work activities across time and place, with a beginning, an end, and clearly defined inputs
and outputs: a structure for action.

Supply link from object Information. A supply link indicates that the information or object
linked to the process is not used up in the processing phase. For example, order templates
may be used over and over to provide new orders of a certain style – the templates are not
altered or exhausted as part of this activity.

 Supply link from object Resource. An input link indicates that the attached object or resource
is consumed in the processing procedure. As an example, as customer orders are processed
they are completed and signed off, and typically are used only once per unique resource
(order).
  Goal link to object Goal. A goal link indicates the attached object to the business process
describes the goal of the process. A goal is the business justification for performing the
activity.
 Object flow link to object Output
 Object flow link from event Event. An object flow link indicates some object is passed into a
business process. It captures the passing of control to another entity or process, with the
implied passing of state or information from activity to activity.

Goal

A business process has some well defined goal. This is the reason the organization does this
work, and should be defined in terms of the benefits this process has for the organization as a
whole and in satisfying the business needs.

Goals link to Processes. A Goal link indicates the attached object to the business process
describes the goal of the process. A goal is the business justification for performing the
activity.

Information

Business processes use information to tailor or complete their activities. Information, unlike
resources, is not consumed in the process – rather it is used as part of the transformation
process. Information may come from external sources, from customers, from internal
organizational units and may even be the product of other processes.

Information items link to Business Processes. A Supply link indicates that the information or
object linked to the process is not used up in the processing phase. For example, order
templates may be used over and over to provide new orders of a certain style – the templates
are not altered or exhausted as part of this activity.

Output

A business process will typically produce one or more outputs of value to the business, either
for internal use of to satisfy external requirements. An output may be a physical object (such
as a report or invoice), a transformation of raw resources into a new arrangement (a daily
schedule or roster) or an overall business result such as completing a customer order.

An output of one business process may feed into another process, either as a requested item
or a trigger to initiate new activities.

Resource

A resource is an input to a business process, and, unlike information, is typically consumed

during the processing. For example, as each daily train service is run and actuals recorded,
the service resource is 'used up' as far as the process of recording actual train times is
concerned.
Resources link to Business Processes. An Input link indicates that the attached object or
resource is consumed in the processing procedure. As an example, as customer orders are
processed they are completed and signed off, and typically are used only once per unique
resource (order).

Additional Resources

Enterprise Architect Resources

Enterprise Architect’s Reviewers Guide:

http://www.sparxsystems.com/downloads/whitepapers/EAReviewersGuide.pdf

Enterprise Architect video walk-through:

http://www.sparxsystems.com/resources/demos/eaoverview/index.html