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: UP-Intro ................................................................................................... 4
1.1. Objectives: UP-Intro .................................................................................. 5
1.2. Introduction to the software process used in the case study .................... 5
1.3. Lesson: UP-based software method ......................................................... 5
1.4. Lesson: The Unified Process: Phases and Workflows .............................. 7
1.5. Lesson: The Unified Process: Models and Roles .................................... 17
1.6. Summary: UP-Intro .................................................................................. 33
A. Case Studies ...................................................................................................... 36
A.1. Hospital Information System ................................................................... 36
A.1.1. Requirements of a Hospital Information System .......................... 36
Index ....................................................................................................................... 37
Glossary ................................................................................................................. 38

Up2UML

1. Lesson: UP-Intro
[id: UP-intro ]

This lesson provides an introduction to the UP as a software development method.

1.1. Objectives: UP-Intro

[id: UP-intro-objectives ]

You should
understand the basic principles of the Unified Process
be able to identify and define UP phases
know what kind of models are used in UP workflows
know which roles are involved in the UP and
how roles and UP models are related to each other.
1.2. Introduction to the software process used in the case study

The software development methodology used in our case study is providing a framework for applying software engineering practices. It consists of two main parts:
1. a (visual) modeling language (the UML2)
2. a software development process (the Unified Process) which
provides guidance to the order of the activities
specifies what artifacts should be developed using the UML2
directs the tasks of system analysts, software architects, software developers
and project managers involved in the development process.

Up2UML

1.3. Lesson: UP-based software method

[id: UP_basedSW-method ]

In this lesson, the basic principles of the Unified Process as a method for software
development are presented.

1.3.1. Definition: Unified Process

[id: o-20070628115122340 ]

The Unified Process is an open standard from the authors of the UML2. It is closely
related to the Rational Unified Process which is a commercial version of the UP from
IBM.
Being a generic software development process, the UP has to be customized and instantiated for each particular project.
1.3.2. Introduction to the UP The 3W
[id: o-20070628115549780 ]

The UP models the who, what, and when of developing software.

WHO is a role in the project played by an individual or a team.
WHAT is an activity performed by a role or an artifact produced in the project.
WHEN is a sequence of related activities that brings value to the project (workflow).
1.3.3. Fundamental Elements of the UP
[id: o-20070628120059040 ]

The UP employs four fundamental elements:

1. Roles
2. Activities

Up2UML

3. Artifacts
4. Workflows.
To model the "who", UP uses the concept of the worker (or role).
The "what" is modeled as activities and artifacts.
Activities are tasks that are performed by individuals or teams
Artifacts are things that are inputs and outputs to the project (e.g., source code,
executable programs, documentation, etc.)
The "when" is modeled as workflows that provide a meaningful way to describe the
sequence of activities. Workflows are further broken down and detailed in order to
denote the activities, roles and artifacts involved in the workflow.
1.3.4. Main Principles of the UP
[id: o-20070628120756240 ]

The main principles of the UP are:

Use Case focused: Collection and refinement of user requirements. For each iteration within the UP a use case is taken all through the following phases.
Based on system architecture: Development of a system architecture during the
elaboration phase and its validation during subsequent phases.
Iterative and incremental: Iterations (i.e., breakdown of a project into small subcomponents and use cases) and increments (delivery of software in parts). Each
iteration results in an increment, which is a release of the system.

Up2UML

1.4. Lesson: The Unified Process: Phases and Workflows

[id: UP_phasesandworkflows ]

This lesson gives a short introduction to Unified Process phases. You will learn
that the software lifecycle is structured into four phases.
which tasks are being performed and
what the outcomes of each one of the phases are.

1.4.1. The five core workflows in the UP

[id: o-20060805220952350 ]

Every iteration of the UP goes through five core workflows:

Requirements: .
Analysis: .
Design: .

Refine and structure the requirements.

Plan the system architecture.

Implementation: .
Test: .

Determine what the system should do.

Build the software.

Verify the products quality.

Up2UML

Figure 1. UP workflows

1.4.2. The four sequential phases of the UP

[id: o-163900050 ]

The software lifecycle of the Unified Process is decomposed over time into four sequential phases:
Inception,
elaboration,
construction, and
transition.

Up2UML

Figure 2. The four sequential phases of the UP

The purpose of the inception phase is to initiate the project. In the second phase, the
elaboration phase, the product vision and its architecture are defined. The main purpose
of the construction phase is to complete the development of the system based upon
the baselined architecture. The transition phase ensures that the software is ready
for delivery to its users.
Since UP is an incremental process, mainly the Elaboration, Construction and Transition
phases are divided into a series of iterations.

10

Up2UML

1.4.3. UP Inception Phase

[id: o-125708140 ]

Figure 3. UP Inception Phase

Goal

In the UP Inception Phase, the goal is to decide upon the feasibility of the system that
has to be developed. The following things can help in getting an idea of the possible
functionalities of the system:
Statement of major requirements, in the form of use cases
Definition of the system borders
Rough picture of the possible software architecture
Identification of potential risks
Presentation of the proposed system to customers and users.
Outcomes of the UP Inception Phase

The outcome of the UP Inception Phase is:

a vision document

11

Up2UML

an initial business case

a list of initial project risks
a project plan, showing phases and iterations
an initial use case model (10-20% complete).
1.4.4. UP Elaboration Phase
[id: o-130441450 ]

Figure 4. UP Elaboration Phase

Goal

The goal of the UP Elaboration Phase is the preparation and planning of the UP
Construction Phase.
This means that
the architectural foundation is established
the development process is refined
quality attributes are defined
the functional requirements are documented, and

12

Up2UML

the UP Construction Phase is planned.

Outcomes of the UP Elaboration Phase

The outcome of the UP Elaboration Phase is:

a use case model (at least 80% complete)
a software architecture description
an executable architectural prototype
a revised risk list and a revised business case
a development plan.
1.4.5. UP Construction Phase
[id: o-130734290 ]

Figure 5. UP Construction Phase

Goal

The main purpose of the UP Construction Phase is to finalise the requirements, analysis and design of the system. The focus is on the realisation of the planned system,
and the iterative and incremental development of a complete product that is ready to
transition to its user community. The essential activities include:

13

Up2UML

Resource management, control and process optimisation

Complete system development and testing against the defined evaluation criteria
Assessment of product releases against acceptance criteria for the vision.
Outcome of the UP Construction Phase

The outcome of the UP Construction Phase is a product ready to put in hands of its
end users. At minimum, it consists of:
the software product integrated on the adequate platforms
the user manuals
the UML2 model
a description of the current release.
1.4.6. UP Transition Phase
[id: o-130953470 ]

Figure 6. UP Transition Phase

14

Up2UML

Goal

During the UP Transition Phase, the system is transferred from the development environment to the user environment. This includes
preparation of the usage site of the software,
instruction of the customer,
upgrading of the environment,
production of user manuals and documentation,
adaptation of the software to the user environment, and
debugging.
Outcome

The outcome of the UP Transition Phase is:

the final product
user support material
deployable elements incorporated in the final product.
1.4.7. Exercise: Define UP Transition phase
[id: o-162240630 ]

Which of the following statements is NOT correct?

During the transition phase

15

Up2UML

(1)

user support material is produced

(2)

the software is adapted to the user environment

(3)

customers are instructed on how to use the system

(4)

the non-functional requirements are identified

(5)

the system is transferred from the development environment to the user environment
(4)

1.4.9. Exercise: List UP phases

[id: o-142236210 ]

Please select from the list below those terms that are used to denominate UP
phases:
(1)

inception

(2)

requirements

(3)

analysis

(4)

elaboration

(5)

construction

(6)

design

(7)

transition

(8)

implementation

(9)

test
(1) (4) (5) (7)

1.4.10. Exercise: Define UP Inception phase

[id: o-143811600 ]

Please select those terms that define best the inception phase:

16

Up2UML

(1)

use cases

(2)

system borders

(3)

coding

(4)

customer presentation

(5)

preliminary architecture

(6)

debugging
(1) (2) (4) (5)

1.4.11. Exercise: Define UP Elaboration phase

[id: o-155430980 ]

Please select those terms that define best the elaboration phase:
(1)

architecture

(2)

user environment

(3)

risk management

(4)

customer presentation

(5)

quality attributes

(6)

planning of construction phase

(1) (3) (5) (6)

1.4.12. Exercise: Define UP Construction phase

[id: o-152727240 ]

Please select from the list below those elements that define best the construction
phase:
resource management

(2)

debugging

(3)

complete system development

(4)

process optimisation

(5)

documentation
(1) (3) (4)

(1)

17

Up2UML

1.5. Lesson: The Unified Process: Models and Roles

[id: UP_modelsandroles ]

In this lesson you will learn more about UP models and their relation to the specific
roles involved in the software development process.

1.5.1. Objectives: Lesson: UP-Models and Roles

[id: UP_modelsandroles-objectives ]

You should be able to

define what kind of models are used in UP workflows.
define which roles are involved in the UP and
identify how roles and UP models are related to each other.
1.5.2. UP models - Overview
[id: o-161937930 ]

Models are an abstract representation or simulation of a "system" that provide a

complete description of the system from a particular perspective. Models are often
used to gain a better understanding of how the system works or to document design
decisions for the actual implementation.
Figure 7, UP model shows the different models that are used in UP workflows.

18

Up2UML

Figure 7. UP model

1.5.3. Dependencies between models

[id: o-20070723143121730 ]

There are dependencies between many models of the Unified Process. Figure 8,
Dependencies between models shows the dependencies between the use-case
model and the other models.

Figure 8. Dependencies between models

19

Up2UML

1.5.4. UP models: The UP Use Case Model

[id: o-163740920 ]

The UP Use Case Model describes the functionality of a system. It structures the external view on the system and represents the functional and non-functional requirements. Since a UP Use Case Model contains the language of the customer, it allows
both the customer and the developers to agree on the requirements of a system. The
UP Use Case Model leads to the UP Analysis Model and the UP Design Model.

Figure 9. UP Use Case Model

A UP Use Case Model may contain one or more UML Use Case Diagrams. To detail
the behaviour of selected use cases, the analyst may also use UML Sequence Diagrams, UML Activity Diagrams, and UML State Machine Diagrams. Static structures
can be described with UML Class Diagrams and UML Package Diagrams.
1.5.5. UP models: The UP Analysis Model
[id: o-164510490 ]

The UP Analysis Model

is always in the language of the business;
captures the big picture;
explains the problem domain and contains artifacts that model the problem domain;
is useful to as many stakeholders as possible.

20

Up2UML

Figure 10. UP Analysis Model

The UP Analysis Model may have the following properties:

Analysis packages
Analysis classes
Use-case realisations
The most important diagram within this model is the UML Class Diagram. It is used
to define an initial architecture and find analysis classes. The UML Package Diagram
may be used to group the identified analysis classes. The behaviour of the use cases
may be detailed by UML Sequence Diagrams, UML State Machine Diagrams or UML
Activity Diagrams.

21

Up2UML

1.5.6. Comparison: Use case model vs. Analysis model

[id: o-20070723151137040 ]

Use case model

Analysis model

Uses customer language.

Uses business language.

External view on the system.

Internal representation of the system.

Structured by use cases.

Structured by stereotyped classes.

Is used as a contract between custom- Is mainly used by developers to show the

er and developer that fixes what the future system architecture (designed and
system is supposed to do.
implemented).
May contain redundancies and incon- Should not contain any redundancies or
sistencies.
inconsistencies between requirements.
Represents system functionality (in- Represents the implementation of functioncluding architecture).
ality; first step towards design.
Defines use cases that are further Defines use case realisations, each represrefined in the analysis model.
enting the analysis of a use case of the
use case model.
Table 1. Use case model vs. Analysis model

1.5.7. UP models: The UP Design Model

[id: o-164717080 ]

The UP Design Model defines the static structure of the system as subsystems, classes
and interfaces, and defines the use cases as collaborations of subsystems, classes
and interfaces. It serves as an abstraction of the implementation model and its source
code.

22

Up2UML

Figure 11. UP Design Model

UML2 diagrams used:

The UP Design Model may contain all kinds of UML2 diagrams. Most important are UML Class Diagram and UML Component Diagram.
1.5.8. UP models: The UP Implementation Model
[id: o-165653130 ]

The UP Implementation Model is a collection of components (representing source

code), and the implementation subsystems that contain them.
An implementation subsystem is a collection of components used to structure the implementation model by dividing it into smaller parts.

23

Up2UML

Figure 12. UP Implementation Model

UML2 diagrams used.

UML2 diagrams:

The UP Implementation Model may contain the following

UML Component Diagram

UML Sequence Diagram
UML Deployment Diagram
UML Communication Diagram.
1.5.9. UP models: The UP Test Model
[id: o-170003580 ]

The UP Test Model is a collection of test cases, test procedures, test components
and the expected test results.

24

Up2UML

Figure 13. UP Test Model

UML2 Diagrams used.

The UP Test Model refers to all other models and uses
corresponding UML2 diagrams.
1.5.10. UP models: The UP Deployment Model
[id: o-170154010 ]

The UP Deployment Model specifies the hardware and network connections. It shows
the configuration of processing nodes at run-time, the communication links between
them, and the component instances and objects that reside on them.

Figure 14. UP Deployment Model

25

Up2UML

UML2 Diagrams used.

diagrams:

The UP Deployment Model may contain the following UML2

UML Deployment Diagram

UML Sequence Diagram
UML Communication Diagram.
1.5.11. UP roles - overview
[id: o-20060906150723510 ]

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.
The UP assigns tasks to a number of specific roles, e.g. system analyst, architect,
use-case engineer, component engineer, test engineer, etc. For simplicity reasons,
we summarise these under the following main role titles:
Analysts
Architects
Implementers
Testers
1.5.12. Definition of the roles within UP
[id: o-20060804214925570 ]

Analyst
The analyst is responsible for eliciting and interpreting the requirements and for use case modelling.

26

Up2UML

Architect
The architect defines the architecture depending
on technical constraints like system type, interfaces
to legacy systems, non-functional requirements,
including design, implementation, and deployment
"views" of the system.

Implementer
The implementer builds prototypes for analysis and
design, writes source code and provides binary
components for integration.

Tester
The tester sets up test plans and a testing environment and performs all kinds of tests.

1.5.13. UP Roles and UP Models

[id: o-20060804215726020 ]

Workers in UP are involved with different tasks in the software development process.
Table 2, Assignment of UP models to the roles shows the assignment of UP models
to the roles.

27

Up2UML

UP roles

UP models

analyst

UP Use Case Model

UP Analysis Model

architect

UP Use Case Model

UP Analysis Model
UP Design Model
UP Deployment Model
UP Implementation Model

implementer UP Implementation Model

tester

UP Test Model

Table 2. Assignment of UP models to the roles

1.5.14. Further Readings on the UP

[id: o-20070723163831470 ]

Jim Arlow. Ila Neustadt. UML2 and the Unified Process. Practical Object-Oriented Analysis
and Design. Second Edition. Addison-Wesley. 2005.
Ivar Jacobson. Grady Booch. James Rumbaugh. The Unified Software Development Process.
Addison-Wesley. 1998.
Wolfgang Zuser. Thomas Grechenig. Monika Khle. Software-Engineering mit UML und dem
Unified Process. Addison Wesley in Pearson Education Deutschland . 2004.
1.5.15. Exercise: List UP models
[id: o-20060802145139020 ]

Please select from the list below those terms that are used to denominate UP
models:

28

Up2UML

(1)

use case model

(2)

analysis model

(3)

architecture model

(4)

design model

(5)

process model

(6)

implementation model

(7)

test model

(8)

deployment model

(9)

function model
(1) (2) (4) (6) (7) (8)

1.5.16. Exercise: Define UP Use Case Model

[id: o-20060804210704210 ]

Please select from the list below those terms that define best the use case model:
(1)

system

(2)

hardware

(3)

requirements

(4)

use case

(5)

components
(1) (3) (4)

1.5.17. Exercise: Define UP Analysis Model

[id: o-20060804211103440 ]

Please select from the list below those terms that define best the UP Analysis
Model:

29

Up2UML

(1)

analysis packages

(2)

use case realisation

(3)

hardware

(4)

analysis classes
(1) (2) (4)

1.5.18. Exercise: Define UP Design Model

[id: o-20060804211528740 ]

Please select from the list below those terms that define best the UP Design Model:
(1)

network

(2)

static system structure

(3)

classes

(4)

system environment

(5)

subsystems

(6)

interfaces
(2) (3) (5) (6)

1.5.19. Exercise: Define UP Implementation Model

[id: o-20060804211733230 ]

Please select from the list below those terms that define best the UP Implementation
Model:

30

Up2UML

(1)

implementation

(2)

rough design

(3)

components

(4)

subsystems

(5)

overview of functionalities
(1) (3) (4)

1.5.20. Exercise: Define UP Test Model

[id: o-20060804212007300 ]

Please select from the list below those terms that define best the UP Test Model:
(1)

packages

(2)

test cases

(3)

classes

(4)

test procedures

(5)

test scripts

(6)

test results
(2) (4) (5) (6)

1.5.21. Exercise: Define UP Deployment Model

[id: o-20060804212233590 ]

Please select from the list below those terms that define best the UP Deployment
Model:

31

Up2UML

(1)

hardware

(2)

network

(3)

system environment

(4)

system

(5)

use case
(1) (2)

1.5.22. Exercise: Identify UP roles

[id: o-20060805164318960 ]

Please select from the list below those roles that are described in the UP:
analyst

(2)

controller

(3)

architect

(4)

tester

(5)

system administrator

(6)

implementer
(1) (3) (4) (5)

(1)

32

Up2UML

1.5.23. Summary: UP models and roles

[id: o-2007072483043340 ]

Six different models are used to describe the system from a particular perspective,
depending on the workflow of the software development process:
UP Use Case Model
UP Analysis Model
UP Design Model
UP Implementation Model
UP Test Model
UP Deployment Model.
Main roles involved in the UP:
architect
analyst
implementer
tester.

33

Up2UML

1.6. Summary: UP-Intro

[id: o-20070723122555970 ]

The UP is a
UML2-based
use-case driven
architecture-centric and
iterative and incremental
software development process. It is a refined, simplified, and non-proprietary version
of the Rational Unified Process.
The four fundamental elements of the UP are
Roles
Activities
Artifacts and
Workflows.
The five core workflows are
Requirements
Analysis
Design
Implementation
Test
.
The UP consists of a sequence of four phases:
Inception
Elaboration
Construction

34

Up2UML

Transition

35

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.

36

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.

37

Up2UML

Index

M
model
model
use case, 20
models, 27

R
roles, 27

U
Unified Process
Fundamental Elements , 6
introduction , 5
Main Principles , 7
Who, What, When , 6
UP , 5
(see also Unified Process)
model, 28
analysis, 20, 29
deployment, 25, 31
design, 22, 30
implementation, 23, 30
test, 24, 31
use case, 29
models, 18
phases, 8
construction, 13
elaboration, 12
inception, 11
transition, 14
roles, 18, 26, 32
workflows, 8
use case, 29

38

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.

39

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.

40

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

41

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

42

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.

43

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-

44

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

45

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)

46