Up2UML

Learn the Unified Modeling Language

V2 within distinct Software Development Processes

Up2UML

Alpha-Release
2007
Copyright 2007 Fraunhofer IESE, Kaiserslautern

Fraunhofer
Institut
Experimentelles
[http://www.iese.fraunhofer.de]

Software

Engineering

(IESE)

Institut National Polytechnique de Toulouse (INPT) [http://www.inp-toulouse.fr]

National College of Ireland (NCI) [http://www.ncirl.ie]

SOFTWIN [http://www.intuitext.com/]

New Bulgarian University, (NBU) [http://www.nbu.bg/]

The Up2UML project is co-funded by the European Vocational Training programme

"LEONARDO DA VINCI"; co-operation partners come from Germany, France, Ireland,
Romania and Bulgaria.

Up2UML

Abstract

The purpose of this course is to help you learn the Unified Modeling Language V2.
It is being developed by the Up2uml Consortium.
Responsible for the content in accordance with 6 TDG:
Up2UML Consortium
c/o Fraunhofer Institute Experimental Software Engineering Fraunhofer-Platz 1
67663 Kaiserslautern
E-Mail: sonja.trapp@iese.fraunhofer.de
Tel.: +49 (631) 6800-2182
Web: http://www.up2uml.org/
All published contents (layout, texts, images, graphics etc) are subject to copyright.

Up2UML

Table of Contents
1. Lesson: Theory of the UML Use Case Diagram ................................................... 4
1.1. Objectives: UML Use Case Diagram ......................................................... 5
1.2. Definition: UML Use Case Diagram ........................................................... 5
1.3. Range of use ............................................................................................. 6
1.4. Example: UML Use Case Diagram ............................................................ 6
1.5. Elements of the UML Use Case Diagram .................................................. 7
1.6. Definition: Actor ......................................................................................... 7
1.7. Definition: Use Case .................................................................................. 7
1.8. Relationship between Actor and Use Case ............................................... 8
1.9. The "system boundary" ............................................................................. 8
1.10. Dependencies between Use cases ......................................................... 9
1.11. The include dependency ...................................................................... 9
1.12. The extend dependency .................................................................... 10
1.13. Generalisation in the UML Use Case Diagram ...................................... 11
1.14. Further Dependencies in UML Use Case Diagrams ............................. 12
1.15. Overview of elements used in the UML Use Case Diagram ................. 12
1.16. Exercise: Define the term "use case" .................................................... 13
1.17. Exercise: List elements of a UML Use Case Diagram (Actors, Use
cases) ............................................................................................................... ?
1.18. Exercise: Identify relationships in a UML Use Case Diagram ............... 14
1.19. Exercise: Explain a UML Use Case Diagram ........................................ 15
1.20. Summary: UML Use Case Diagram ...................................................... 15
A. Case Studies ...................................................................................................... 17
A.1. Hospital Information System ................................................................... 17
A.1.1. Requirements of a Hospital Information System .......................... 17
Index ....................................................................................................................... 18
Glossary ................................................................................................................. 19

Up2UML

1. Lesson: Theory of the UML Use Case Diagram

[id: UML-UCD ]

In this section you will learn

what UML Use Case Diagrams are,
what UML Use Case Diagrams are used for and who designs them,
which elements UML Use Case Diagrams are composed of and how these are
graphically represented and
what kind of relationships exist between the elements of UML Use Case Diagrams.

1.1. Objectives: UML Use Case Diagram

[id: UML-UCD-objectives ]

You should be able

to define the terms "use case", "use case diagram", and "actor".
to identify and list actors, use cases and their relationships and heritage in a use
case diagram.
to explain use cases and use case diagrams as well as the relationships within a
use case diagram.
1.2. Definition: UML Use Case Diagram
[id: o-20061127122342790 ]

Use cases are a technique for capturing the functional requirements of a system. By
describing the typical interactions between the users of a system and the system itself,
they provide a narrative of how the system is used.
A use case describes usages and behaviours of a system from the viewpoint of a user
or connected (interacting) systems.

Up2UML

Use cases are usually written down in a document which describes the details of the
use case in a table (use case model). However, within the UML2, the structure of this
document is not defined. Hence, we do not present such a document in this unit.
1.3. Range of use
[id: o-20061127123102330 ]

A use case diagram is used

to gather the requirements for a system,
to integrate and delimit a system in its environment
to accompany the system implementation
to generate test cases and
to validate the system architecture.
Use case diagrams are normally designed by analysts and domain experts at the
beginning of the development of a system.
1.4. Example: UML Use Case Diagram
[id: o-20061127125301830 ]

Example 1. UML Use Case Diagram

Example 1, UML Use Case Diagram shows a simple UML Use Case Diagram. It
consists of an actor, two associated use cases and a system boundary.

Up2UML

1.5. Elements of the UML Use Case Diagram

[id: o-20061127134327520 ]

A UML Use Case Diagram mainly consists of the elements "Actor" and "Use Case".
The use case diagram shows the actors, the use cases, and the relationships between
them. The relationships between the use cases can be specified more closely.
1.6. Definition: Actor
[id: o-20061127150710310 ]

The element "actor" is a person, an organisation or an external system outside of the

system, that has to be modelled. The actor directly interacts with the system by way
of the use cases. Different users of the system are represented by different actors.

Example 2. Actors displayed using various symbols

Notation. An actor is represented by a "stick-man" icon with the name of the actor
in the vicinity (usually above or below). An actor may also be shown as a class rectangle with the keyword "actor", with the usual notation for all compartments. By defining
further stereotypes it is possible e.g., to use a computer icon as actor symbol.
1.7. Definition: Use Case
[id: o-20061128125656330 ]

Use cases describe typical scenarios of users interacting with a system. A scenario
is a sequence of steps describing an interaction between a user and a system. The
scenarios are defined depending on the goals the user wants to achieve by means of
the system. A single use case stands for a set of behaviours with observable results
performed by the system.

Up2UML

Example 3. Use Case

Notation.
A use case is shown as an horizontal ellipse, either containing the name
of the use case or with the name of the use case placed below the ellipse.
1.8. Relationship between Actor and Use Case
[id: o-20061129110610820 ]

An association (actor relationship) is a relationship between an actor and a use case.

Hence, by way of the associations, every user is assigned a different scenario within
the system.

Example 4. Relationship between an actor and a use case

Notation.

Associations are represented by a simple solid line.

1.9. The "system boundary"

[id: o-20061129120157650 ]

The system boundary indicates which actions and functions (use cases) of a system
belong to a specific system and which are outside the system (e.g., actors, other
systems).

Up2UML

Example 5. System boundary

Notation. The system boundary is represented by a rectangle around the relevant

use cases.
1.10. Dependencies between Use cases
[id: o-20061129133525850 ]

The element "dependency" represents a directed relationship between two use cases.
The UML2 has many varieties of dependency, each with particular semantics and
keywords. Such dependencies are indicated by Stereotypes which are defined within
the UML2.

Example 6. Dependencies between use cases

Notation.

Dependencies are modelled as a dashed line with an open arrowhead.

1.11. The include dependency

[id: o-20061129142802370 ]

The include-construct is used for use cases that can be subdivided into several
steps. It is also used for use cases that are included in several superior use cases.

Up2UML

This means that the execution of one use case always includes the execution of the
other use case.

Example 7. include dependency

Notation. The include dependency is represented by a dashed line with an open

arrowhead. The arrow of the include relationships points to the use case that should
be included.

Clearly separable functions within a use case should always be represented

as separate use cases. The include-dependency then integrates the
functions into the main use case. If the level of abstraction is very high,
this might not be necessary.
1.12. The extend dependency
[id: o-20061129144204240 ]

The extend-dependency ( ) shows that the behaviour of a use case ( ) can be

extended by another use case ( ) under a certain condition ( ). The use case is extended, once the condition is true. In this case, the first use case is extended by the
behaviours of the extending use cases.
An extend-dependency is used to conditionally include the behaviour of secondary
use cases at a given point in the execution of the initial use case. This point is called
"extension point" ( ).

10

Up2UML

Example 8. extend-dependency

Notation. The extend dependency is represented by a dashed line with an open

arrowhead. The arrow of the extend relationships points from the extending use case
to the use case that should be extended.
1.13. Generalisation in the UML Use Case Diagram
[id: o-20061130103936810 ]

A generalisation is used for use cases describing a scenario similar to that of another
use case, which is possibly extended or slightly changed. This behaviour corresponds
to inheritance in object orientation.

Example 9. Generalisation in the UML Use Case Diagram

Notation.

The generalisation is represented by a solid line with an unfilled arrowhead.

11

Up2UML

1.14. Further Dependencies in UML Use Case Diagrams

[id: o-20061130105935240 ]

Dependencies between use cases can also be denoted by other predefined stereotypes, for example use. The use-dependency indicates that a service from another
use case in the system or of another system is used without being included within an
include-dependency.

12

Up2UML

1.15. Overview of elements used in the UML Use Case Diagram

[id: o-20061130110541530 ]

The actor is a role outside of the system to be modelled. The actor directly interacts
with the system by way of the use cases. The use case represents a typical activity
carried out by a user using the system. Associations between actors and use cases
assign different scenarios to the users of the system.

Relationships between use cases have the following meanings:

include means that a use case is subdivided into several steps or that it is included
in several subordinated use cases.
extend shows that the behaviour of a use case can be extended by another use
case.
A generalisation is used for a use case describing a scenario similar to that of another use case which is possibly extended or slightly changed.
use as a predefined stereotype indicates that a use case is using services from
another use case in the system or from another system.
Use cases are enclosed by the system border which delimits them from actors outside
of the system.
1.16. Exercise: Define the term "use case"
[id: o-20061205110730110 ]

Select from the list those words that define best the concept of use cases:

13

Up2UML

(1)

Actors

(2)

Requirements

(3)

Classes

(4)

Dependency

(5)

Stereotype

(6)

Timing
(1) (2) (4) (5)

1.18. Exercise: Identify relationships in a UML Use Case Diagram

[id: o-20061207111810270 ]

14

Up2UML

1.19. Exercise: Explain a UML Use Case Diagram

[id: o-20061207100509890 ]

(1)

(2)

(3)

look

at

the

diagram

and

select

the

correct statement(s)!

A foreign customer wants to transfer money at an ATM. The account management system checks whether the user entered the right PIN and then
proceeds to the money transfer.
A customer wants to withdraw money from an ATM. First he has to identify
himself by entering a personal PIN. After successful authentication, the customer withdraws money from the ATM.
A bank customer wants to transfer money. He successfully enters the PIN
and the amount of money he wants to transfer. The account management
system checks the balance of his account and then transfers the money.
(2) (3)

Have

15

Up2UML

1.20. Summary: UML Use Case Diagram

[id: o-20061205120038910 ]

The UML Use Case Diagram describes services and functions of a system from the
user's point of view or from the perspective of further connected (interactive) systems.
The purpose of a UML Use Case Diagram is
to gather the requirements of a system;
to integrate and delimit a system in its environment;
to accompany the implementation of the system and to generate test cases, and
to validate the system architecture.
The main elements of the UML Use Case Diagram are
actor
use case
association
dependency and
system boundary.

16

Up2UML

A. Case Studies

A.1. Hospital Information System

[id: casestudy_hospital ]

A.1.1. Requirements of a Hospital Information System

[id: casestudy_hospital_requirements ]

The City Hospital is planning to introduce an information system, in order to process

medical and administrative data. The hospital information system is supposed to make
the hospital more efficient and to improve a number of administrative functions.
These functions include:
Administration of patient data and collection of disease data
Planning and collection of medical services
Payment transactions with health insurance companies and paying patients
Archiving of reports and support for the documentation of surgery, care and the ordering of material
Administration and provision of laboratory data and data from radiological examination (e.g., X-rays)
The first version of the system should deal mainly with the treatment of a patient in
the emergency unit and includes a set of system specifications corresponding to the
items named above. These are further described by the following scenario:
A patient with minor injuries enters the emergency unit. The reception officer first takes
up all personal data including identification of the payment details of the patient. The
patient reports that he had a sports accident and is experiencing a lot of pain in his
knee. Accordingly, the reception officer arranges for a physical examination. This includes finding an available and suitably qualified physician and, if necessary, finding
available medical equipment/special rooms that are required in order to conduct the
examination. Furthermore, the patient may have to be transferred to the corresponding
ward.
The emergency physician on duty conducts the first examination. He has a list of upcoming appointments provided by the information system which include the appointment
for the examination of the newly arrived patient. After the examination he formulates
a diagnosis, orders medicine and/or prescribes a therapy and enters these data into
the hospital information system. If further examinations are needed to better circumstantiate the diagnosis, he may instruct a nurse to arrange for some extra examinations.

17

Up2UML

This may involve a check of certain laboratory values or X-rays in order to see if the
patient has some fractures.
In this case, X-rays of the knee have to be made. The arrangement of the extra examination includes checking whether an X-ray machine and a radiologist are available.
The patient is then sent to the radiology ward for an X-ray. To transfer the patient, the
nurse enters the transfer into the system and then brings him to the radiology ward
where the radiologist conducts his examination. After the examination, the radiologist
enters his diagnosis into the system and the nurse transfers the patient back to the
emergency physician.
Depending on the results of the special examination, which are available in the system,
the emergency physician decides whether the patient must stay in hospital or if he
can go home. If the patient can go home, he is transferred to the reception where the
reception officer takes care of the hospital discharge. This includes the creation of an
invoice and the handing-out of a prescription.

18

Up2UML

Index

A
actor, 7
association, 8

D
dependency
extend, 10
include, 9
use, 12

G
generalisation, 11

U
UML Use Case Diagram, 5, 6, 13, 15, 16
association, 8
system boundary, 8
use case, 7
dependency, 9
generalisation, 11
use case diagram, 5

19

Up2UML

Glossary

activity diagram

The activity diagram depicts all the process elements

within the scope of an activity. It is used to visualise the
execution of a use case, an operation or of a complete
business process. Concurrencies, alternative decision
paths etc. can be modelled and retraced.

actor

Someone or something, outside the system that interacts

with the system.

analysis

The aim of the analysis is to describe what the system

should be able to perform.

analysis class

Analysis classes are part of the analysis model. They

map in a clear and unambiguous way to real-world
business concepts. Analysis classes model important
aspects of the problem domain and present only a very
high-level set of attributes and operations. Normally,
analysis classes will evolve directly into elements in the
Design Model: some become design classes, others
become design subsystems.

analysis packages

Analysis packages are collections of semantically related

analysis classes.

API

Application programming interface

architectural foundation

The baseline at the end of the elaboration phase, at

which time the foundation structure and behaviour of
the system is stabilized.

artifact

A piece of information that is produced, modified, or

used by a process.

association

An association represents a structural relationship that

connects two classifiers, like, e.g., classes or use cases.

behaviour

The observable effects of an operation or event, including its results.

black-box testing

Black box testing takes an external perspective of the

test object to derive test cases. These tests can be
functional or non-functional, though usually functional.

20

Up2UML

The test designer selects valid and invalid input and

determines the correct output. There is no knowledge
of the test object's internal structure. (Source: Wikipedia)
business activities

A description of system behaviour, in terms of sequences of actions. A business activity should yield an
observable result of value to a business role.

class

A description of objects that share the same attributes,

operations, methods, relationships and semantics. It is
a template for creating objects and models the data and
behaviour an object will have. Classes can be domain
(or analysis) classes, design classes, or implementation
classes.

class diagram

A class diagram shows a collection of static model elements, such as classes, types, and their contents and
relationships.

cohesion

Cohesion is a measure of how strongly-related and focused the responsibilities of a systems are.

communication diagram

Formerly named collaboration diagram, a communication

diagram describes a pattern of interaction among objects; it shows the objects participating in the interaction
by their links to each other and the messages they send
to each other.

component

A non-trivial, nearly independent, and replaceable part

of a system that fulfils a clear function in the context of
a well-defined architecture.

component diagram

The component diagram depicts the software components that compose an application, system or enterprise.
Their components, their interrelationships, interactions,
and their public interfaces are depicted.

concurrency

The occurrence of two or more activities during the same

time interval. Concurrency can be achieved by interleaving or simultaneously executing two or more threads.

construction phase

The third phase of the UP in which the software is

brought from an executable architectural baseline to the
point at which it is ready to be transitioned to the user
community.

control flow

Control flow is the order in which the individual elements

are executed or evaluated.

21

Up2UML

coupling

Coupling is a measure for the degree to which each part

of a system relies on each one of the others. Coupling
is usually contrasted with cohesion. Low coupling often
correlates with high cohesion, and vice versa.

CRC

Class - Responsibility - Collaborator

deployment diagram

The deployment diagram shows the configuration of

run-time processing nodes and the components, processes, and objects that live on them. It depicts the
hardware, software and middleware configuration of a
system.

design

In the software domain design is a process of problemsolving and planning for a solution.

design class

Classes whose specifications have been completed to

such a degree that they can be implemented.

design model

An object model describing the realisation of use cases;

serves as an abstraction of the implementation model
and its source code.

design package

A collection of classes, relationships, use-case realisations, diagrams, and other packages. It is used to
structure the design model by dividing it into smaller
parts.

design subsystem

A model element that represents a part of a system.

The design subsystem encapsulates behaviour by
packaging other model elements (classes or other
design subsystems) that provide its behaviour.

elaboration phase

The second phase of the process where the product

vision and its architecture are defined.

extend relationship

The extend-relationship shows that the behaviour of a

use case can be extended by another use case. It is
used in cases where a new use case is integrated into
an existing use case.

functional requirement

Functional requirements capture the intended behaviour

of the system. This behaviour may be expressed as
services, tasks or functions the system is required to
perform.

generalization

inheritance

GUI

Graphical User Interface

22

Up2UML

IBM

Industrial Business Machines

implementation

A discipline in the software engineering process, the

purpose of which is to implement software components
that meet an appropriate standard of quality.

implementation model

The implementation model is a collection of components,

and the implementation subsystems that contain them.

inception phase

The first phase of the Unified Process , in which the

business context, success factors, and financial forecast
is established.

include relationship

The include-relationship is used for use cases that can

be subdivided into several steps. It is also used for use
cases that are included in several superior use cases.

inheritance

inheritance

integration test

Phase of software testing in which individual software

modules are combined and tested as a group.

interface

Defines the communication boundary between two entities, such as a piece of software, a hardware device,
or a user.

iterations

Repetition of a sequence of instructions. A fundamental

part of many algorithms.

JDBC

Java Database Connectivity

lifecycle

A lifecycle is one complete pass through the four

phases, i.e. the span of time between the beginning of
the inception phase and the end of the transition phase.

lifeline

A lifeline is a part of the sequence diagram. Messages

are drawn between lifelines. Activation bars are drawn
on top of lifelines to represent that processes are being
performed in response to the message.

message flow

Order of messages

Multiplicities

Multiplicities specify the number of objects that can

participate in a relationship at any point in time.

non-functional requirement

Non-functional requirements are requirements which

specify criteria that can be used to judge the operation
of a system, rather than specific behaviours. Typical

23

Up2UML

non-functional requirements are reliability, efficiency,

scalability, and cost.
object diagram

An object diagram encompasses objects in a system

and their relationships at a point in time. It shows instances of classes, components, nodes, links (instances
of association) and values of attributes (slots). An object
diagram is often called an instance diagram.

object orientation

A programming approach based on the concepts of data

abstraction and inheritance. Unlike procedural programming techniques, object-oriented programming concentrates on those data objects that constitute the problem
and how they are manipulated, not on how something
is accomplished.

object-oriented analysis

Object-oriented analysis is an approach that models a

system as a group of interacting objects. It applies object-modeling techniques to analyse the functional requirements for a system. (Source: Wikipedia)

object-oriented design

Object-oriented design is part of the object-oriented

methodology. The main concept behind all design decisions is the "object" which provides data and procedures (methods).

object-oriented modelling

A paradigm for modelling systems according to object

orientation.

object-oriented programming

Object-oriented is a programming technique that uses

"objects" and their interactions to design systems. It is
based on several techniques, including inheritance,
modularity, polymorphism, and encapsulation. (Source:
Wikipedia)

quality attribute

Software quality attributes are the benchmarks that describe the system's intended behaviour within the environment for which it was built. They provide the means
for measuring the fitness and suitability of a product.

Rational Unified Process

The Rational Unified Process is a software development

process framework which claims to provide a disciplined
approach to assigning tasks and responsibilities within
a development organisation. Its goal is the production
of high quality software that meets user needs within a
predictable time schedule and budget.

requirements

The first stage of software development which defines

what the potential users want the system to do.

24

Up2UML

requirements workflow

In this workflow, the requirements of the system that

has to be developed are identified and documented.
This means that
a list of potential requirements is drawn
the system context is defined, and
the functional
and non-functional requirements are identified.

role

A role is a definition of the behaviour and responsibilities

of an individual, or a set of individuals working together
as a team, within the context of a business organisation.

RUP

Rational Unified Process

scenario

A specific sequence of actions that illustrates behaviours. A scenario may be used to illustrate an interaction or the execution of one or more use-case instances.

sequence diagram

A diagram that shows object interactions arranged in

time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages
exchanged.

singleton pattern

A pattern used for the design of software systems. It

helps to ensure that exactly one instance of an object
exists.

SQL

Simple Query Language

stakeholder

Stakeholders are an integral part of a project.They are

the end-users or clients, the people from whom requirements will be drawn, the people who will influence the
design and, ultimately, the people who will reap the benefits of your completed project.

state machine diagram

A state machine diagram describes the states an object

may be in, as well as transitions between states.
(Formerly referred to as a "state diagram" or "statetransition diagram"). A state machine specifies the behaviours of a model element, defining its response to
events and the life cycles of the object.

stereotype

Represents a variation of an existing model element

with the same form but with a modified intent. With ste-

25

Up2UML

reotypes, you can introduce new modeling elements

based on existing elements.
subsystem

A model element which has the semantics of a package,

such that it can contain other model elements, and a
class, such that it has behaviour. The behaviour of the
subsystem is provided by classes or other subsystems
it contains.

system architecture

The design or set of relations between the parts of a

system.

system border

Marks the border between the use cases and the actors.

system test

Testing conducted on a complete, integrated system to

evaluate the system's compliance with its specified requirements.

transition phase

The fourth phase of the process in which the software

is turned over to the user community.

UML-AD

UML Activity Diagram

UML-CD

UML Class Diagram

UML-CompD

UML Component Diagram

UML-ComuD

UML Communication Diagram

UML-DD

UML Deployment Diagram

UML-OD

UML Object Diagram

UML-PD

UML Package Diagram

UML-SD

UML Sequence Diagram

UML-SMD

UML State Machine Diagram

UML-UCD

UML Use Case Diagram

UML2

Unified Modeling Language V2

Unified
guage

Modeling

Lan-

A language for visualising, specifying, constructing, and

documenting the artifacts of a software-intensive system.

Unified Process

The Unified Process (UP) is a software development

process framework .

UP

Unified Process

26

Up2UML

use case

A description of system behaviour, in terms of sequences of actions. A use case should yield an observable result of value to an actor.

use case diagram

A use case diagram describes users, use cases, and

their interrelationships, thus showing the external behaviour of a system from the users' perspective. A user
can be a person or a neighbouring system.

use case model

The use case model describes a system's functional

requirements in terms of use cases. It also defines the
actors of the system and helps to mark the system border.

use case realisations

Describes how a particular use case is realised within

the design model. The goal of the use-case realisation
is to produce a well-structured object-oriented design
for implementation of the behaviour defined in a use
case.

use-case realisation

Describes how a particular use case is realised within

the design model. The goal of the use-case realisation
is to produce a well-structured object-oriented design
for implementation of the behaviour defined in a use
case.

validate

Finding or testing the truth of something.

validation

The stage in the software lifecycle at the end of the development process where software is evaluated to ensure that it complies with the requirements.

white-box testing

White box testing uses an internal perspective of the

system to design test cases based on internal structure.
It requires programming skills to identify all paths through
the software. The tester chooses test case inputs to
exercise paths through the code and determines the
appropriate outputs. Since the tests are based on the
actual implementation, if the implementation changes,
the tests probably will need to also. While white box
testing is applicable at the unit, integration and system
levels of the software testing process, it's typically applied to the unit. So while it normally tests paths within
a unit, it can also test paths between units during integration, and between subsystems during a system level
test. (Source: Wikipedia)

27