Umlmethod v0 3

©2000-2005 John N.
Kostaras
MA in Management Studies, Essex University
MSc in Telecommunications & Information Systems, Essex University
BSc Computer Science – University of Athens
December 2000
©2000-2005 John N. Kostaras
INDEX
Preface........................................................................................................................ 3
Introduction ................................................................................................................. 3
1. What is UML........................................................................................................ 5
2. Description of the methodology........................................................................... 7
3. Step 1.: Description of the system (a real example)............................................ 8
4. Step 2.: Use case analysis .................................................................................. 9
4.1. Use case view.................................................................................................9
4.2. Description of the methodology...................................................................13
4.3. Example System...........................................................................................14
5. Step 3.: Requirements tracing........................................................................... 18
6. Step 4.: Package analysis ................................................................................. 18
6.1. Package view ...............................................................................................18
7. Step 5.: Domain analysis .................................................................................. 21
7.1. Class diagrams I...........................................................................................21
7.3. Example system ...........................................................................................26
8. Step 6.: Robustness analysis ............................................................................ 26
8.1. Robustness view...........................................................................................26
9. Step 7.: Interaction diagrams ............................................................................ 28
9.1. Sequence diagrams.......................................................................................28
9.2. Collaboration diagrams................................................................................29
10. Step 8.: Static view........................................................................................ 32
10.1. Class diagrams II......................................................................................32
10.2. Description of the methodology...............................................................35
11. Step 9.: Object view ...................................................................................... 40
11.1. State transition diagrams..........................................................................40
11.2. Activity diagrams.....................................................................................42
12. Step 10.: Implementation view ...................................................................... 44
12.1. Component diagrams ...............................................................................44
12.2. Deployment diagrams ..............................................................................45
References................................................................................................................ 47
1
Figures
Figure 1 Iterative life cycle phases ................................................................................4
Figure 2 The macro development process .....................................................................5
Figure 3 The 4+1 View Model of Architecture ............................................................6
Figure 4 Components of a use case diagram ...............................................................10
Figure 5 A use case diagram........................................................................................11
Figure 6 Use case relationships....................................................................................11
Figure 7 A first cut use case diagram for the example system ....................................15
Figure 8 A Package diagram........................................................................................19
Figure 9 Components of a class diagram.....................................................................24
Figure 11 Example association relationship ................................................................24
Figure 12 Example of an association class ..................................................................24
Figure 13 Aggregation and composition example .......................................................25
Figure 14 A window with a scrollbar ..........................................................................25
Figure 15 Example robustness diagram.......................................................................27
Figure 16 Example sequence diagram .........................................................................30
Figure 17 Example collaboration diagram...................................................................31
Figure 18 Class notation details...................................................................................33
Figure 19 A parameterised class, T: an object type, k: FArray length ........................33
Figure 20 Name discriminator example.......................................................................36
Figure 21 Composition notation ..................................................................................37
Figure 22 Components of a state transition diagram ...................................................41
Figure 23 Example state transition diagram ................................................................42
Figure 24 Activity diagram notation............................................................................43
Figure 25 An example Activity diagram .....................................................................44
Figure 26 Component diagram notation ......................................................................45
Figure 27 Components of a deployment diagram........................................................45
2
Preface
The purpose of this book is to provide you with some basic knowledge of the Unified
Modelling Language (UML at short) as well as what other books lack of, i.e. to give
you some sort of methodology of how to use UML. UML by itself does not come
shipped with a methodology. It only provides the notation and lets the systems
analyst and the designer the way to use it. Unified Modelling Language is a modelling
language that tells you what to use to model your work but does not tell you how to
model it. This book is an attempt to provide a methodology on how to use UML in
software systems development.
The methodology consists of ten steps; hence the book is structured in ten chapters,
one for each step. In each step, first a description of the UML notation is given, then
a description of the methodology is provided, and finally all this is applied to an
example system under development.
Introduction
The history of Software Analysis and Design steps back to the early 1970s. Then,
Structured Analysis and Design was perhaps the first family of software development
methods to be used widely. That methodology followed the traditional software life
cycle. The traditional software life cycle is linear, with well-defined, sequential
phases. Each phase normally starts when its previous phase terminates. This
methodology has some serious drawbacks, as that it is very costly to change
requirements in later phases, and there is no proof that the system will run properly
until late in the life cycle. It applies to the functional programming languages, such as
C, Fortran or Cobol.
By the late 1980s there was a move towards the Object-Oriented paradigm.
“In general, object-oriented techniques addressed issues of complexity management
and were much more suited to the iterative development process” [Rosenberg,
1999]. In the iterative life cycle, a non-linear evolutionary approach to development is
used. In the iterative life cycle each phase consists of analysis, design1 and
implementation (see Figure 1) and this cycle is repeated in the following phases, too.
This way, changes in the requirements are anticipated throughout all phases. The
1
Object-oriented analysis is a method of analysis in which requirements are expressed in terms of the
objects found in the problem (what to model).
In object-oriented design the analysis model is transformed into a design model by refining the model,
adding detail and capturing design decisions needed to implement the model (how to model).
3
iterative life cycle exposes problems early in the project schedule and there is proof
that major pieces of the system will run properly throughout the life cycle. The result
is better quality code.
Figure 1 Iterative life cycle phases
A problem that emerged early in the object-oriented process was the focus to
model the vocabulary of the problem in a way that captured the user needs and
provided an accurate blueprint of the system. Some of the most famous methods
developed by that time were the Booch method by Grady Booch [Booch, 1991], the
Object Modeling Technique (OMT) by Jim Rumbaugh et al. [Rumbaugh et al., 1991],
and Ivar Jacobson’s Object Oriented Software Engineering (OOSE) [Jacobson et al.,
1992]. Each one of them had its strengths and weaknesses. In the mid 1990s the
three amigos, Grady Booch, Jim Rumbaugh and Ivar Jacobson were motivated to
produce a unified modeling language that combined each ones’ methods
advantages. In January 1997 the UML 1.0 was offered for stardadisation to the
Object Management Group (OMG) and was released as a standard in November
1997. Today, UML is at version 1.5.
The phases that each software project goes into are the following five [Booch,
1991; Detsis, 2000]:
♦ Requirements capture
♦ Analysis
♦ Design
♦ Implementation
4
♦ Maintenance
The macro development process [Booch, 1991; Detsis, 2000] is iterative and risk-
oriented. It consists of the following phases: inception, elaboration, construction,
transition and evolution.
Figure 2 The macro development process

♦ During the first phase (inception) the project scope is specified and an initial
business case (including success criteria, risk assessment and estimate of
required resources) is created.
♦ During the second phase (elaboration), an analysis of the requirements, of
the resources and the risks is made and an executable architecture is
developed.
♦ The third phase (construction) consists of a number of the development
cycles described above (i.e. analysis, design, implementation and testing).
♦ In the transition phase, the final release of the product is delivered, the
documentation etc.
♦ The final phase (evolution) consists of the updates, new versions, bug fixes
that were missed during transition phase etc.
The book consists of eleven chapters. In the first chapter a definition of UML
is given, while in chapter 2 a general description of the methodology is provided.
Then, in each chapter a specific part of this methodology is described. First, the
theoretical concepts and UML notation for this part of the methodology are given.
Then, we describe how to use these notions in each step to produce the deliverables
for our project. A real example is used to apply the theoretical notions and the
methodology. Finally, these notes lean towards the Java programming language, so
the specific notations for this language are emphasized (letting less emphasis to
other object-oriented languages such as C++).
1. What is UML
Unified Modelling Language (UML) is a language for specifying, constructing,

visualizing, and documenting the artifacts of a software-intensive system. It consists
of modeling elements, i.e. abstractions drawn from the system being modeled.
5
UML consists of 7 diagrams which we shall describe in the rest of this book, namely:
use case diagrams, class and object diagrams, collaboration diagrams, sequence
diagrams, state transition diagrams, activity diagrams, component diagrams and
deployment diagrams. The diagrams are the actual graphs that show model element
symbols arranged to illustrate a particular part or aspect of the system.
UML consists of the following four views of the system under development (see
Figure 3) [Eriksson & Penker, 1998; Kruchten, 2000]:
Figure 3 The 4+1 View Model of Architecture
• Use case view: shows the functionality of the system as perceived by

external actors; it is described in use case diagrams and occasionally in
activity diagrams.
• Logical view: shows how this functionality is designed inside the system, in
terms of the system’s static structure and dynamic behaviour; it is described
in class and object diagrams (static model) and state transition, sequence,
collaboration and activity diagrams (dynamic model)
• Component view: shows the organisation of the software components; it is
described in component diagrams.
• Deployment view: shows the physical configuration (deployment) of run-time
processing nodes within computers and devices and the components,
processes, and objects that live on them; it is described in deployment
diagrams.
6
• Process view: shows the concurrent aspect of the system at runtime, like
tasks, threads, processes and interactions and addresses problems with
communication and synchronisation of these threads; it is described in
dynamic diagrams (state transition, sequence, collaboration and activity
diagrams) and implementation diagrams (component and deployment
diagrams).
Each system consists of the static and the dynamic model. The static model is
depicted in the class diagrams. However, it reveals little concerning system behavior.
System behavior is captured graphically using scenarios (i.e. use case diagrams),
collaboration diagrams, sequence diagrams, state transition and activity diagrams.
These consist the dynamic model of the system. System behaviour is the total
behaviour of all objects belonging to the system.
If we want to map the above five views to the iterative life cycle phases of Figure
3, we could say the following:
• Object Oriented Analysis (OOA), which develops a model of users'
requirements from the user's perspective, maps to the Use case view.
• Object Oriented Design (OOD) adds details and design decisions (from
the developer's perspective) to the analysis and maps to the logical view.
• Finally, Implementation or Object Oriented Programming (OOP) maps to
the process, deployment and component view.
However, it should be mentioned that this mapping is not as strict as it appears

above.
2. Description of the methodology

The methodology that we shall use is outlined below. We must note here that
there are many methodologies in the bibliography, as the Rational Unified Process
(RUP) [Kruchten, 2000], or the ICONIX method [Rosenberg, 1999], to name a few.
Our methodology consists of the following general steps:
2.1. Short description of the system taking into account the requirements of the
system.
2.2. Use case analysis: Identification of use cases and use case diagrams
development.
7
2.3. Package analysis: Identification of packages and development of a package

diagram of use cases.
2.4. Domain analysis: An initial class diagram (or set of class diagrams), which
consists of domain classes from the use case diagrams documentation that
correspond to the real world.
2.5. Robustness analysis to define objects and their attributes from the use case
diagrams
2.6. Interaction analysis: Creation of interaction models (sequence and
collaboration) from robustness analysis.
2.7. Creation of class diagrams (static model).
2.8. Creation of state and activity diagrams for the most important classes of the
system.
2.9. Implementation analysis (creation of component and deployment diagrams).
3. Step 1.: Description of the system (a real example)
The first step is to write a short description of the problem we have to solve. This
description will help the development team to get a draft knowledge of what they
have to produce as well as of system requirements. The description will be in plain
English (or another natural language) and will be the system’s analyst understanding
of the system. Typically, s/he should contact the end users to verify that his/her
understanding of the system is correctly and fully specified in this description2.
In this step we can also write down some assumptions for our system under
development, we shall analyse the risk factors for the development or not of the
system (i.e. factors of success or failure) and look at the market factors (how
competitive shall our system be?).
The description papers we have to produce during this step are summarized
below [Schneider & Winters, 1998]:
o System description
o System assumptions
o Risk analysis
o Market analysis
2
In real systems, this description will not be needed as it will be covered by the actual requirements of
the system to be developed provided by the client/user.
8
A real example system description (that we shall use in our analysis in the rest of the
book) is as follows:
There is a need for an automated library system that permits the

registration of books, magazines, documents, electronic data storage
software (CD, floppy, zip etc.) etc. The system must be able to
provide distributed access. A user must be able to browse a library
catalogue and be able to do a search to the catalogue (by author, by
title, by ISBN and/or by keyword). The user will be able to apply
electronically for a book loan and after approval, a token will be
returned to him/her and s/he will be able to borrow the item from its
physical location in the library. If the item is not available, s/he
will be able to make a reservation on the item. Reservations will be
stored in a FIFO list for the users. Once a book is returned to the
library, the reservations list for the book is searched and the first
user in the list is notified by email.
Each item will be registered to the library with the following

information: ISBN, title, author(s), editor, publication date,
keywords, and a short description.
Each user should borrow an item for a specific time period. A user
may extend the borrow time period of an item (i.e. re-borrow it) only
if there is no reservation for the item by another user. Each user
has a limit on the number of items s/he can borrow. If a user does
not return an item in the specified time limit, s/he will be given a
fine for each day of delay. The system should be able to notify a
user by email if s/he has delayed to return an item. A list of the
delayed items will be reported each morning to the librarian.
The information for each user to be stored to the system will be:
User ID, name, phone number, address, email and number of books s/he
is allowed to borrow. The system should also store a list of the
borrowed items (ISBN, loan date, return date, borrower).
How do we proceed then?
4. Step 2.: Use case analysis
4.1. Use case view

The use case view of the system consists of use case diagrams. A use case diagram
shows the relationships among actors and use cases within the system. A use case
diagram consists of actors, use cases and relationships between them.
• An Actor is someone or something outside the system that interacts with the
use cases developed for the system. In other words, everything that must
exchange information with the system.
• A use case is a pattern of behavior a system exhibits. A sequence of related
transactions performed by an actor and the system in a dialogue. Use cases
9
are discovered by examining the actors and defining everything they can do
with the system. Use cases provide a starting point for identifying scenarios.3
• A Use case (communication) relationship shows interactions between
actors and use cases. The following kinds of relationships are defined:
o An association denotes the participation of an actor in a use case, i.e.
an actor communicates with a use case. This is the only relationship
between actors and use cases.
o Two special relationships (also called stereotypes4) between use
cases are:
<<include>>: An include relationship from use case A to use
case B indicates that use case A will also include the behavior
specified by use case B;
<<extend>>: An extend relationship from use case A to use
case B indicates that use case B may include (subject to
specific conditions specified in the extension) the behavior
specified in use case A.
o The generalisation relationship is applied only between actors or
between use cases. A generalization from use case (actor) A to use
case (actor) B indicates that A is a specialization of B, i.e. that B has
the same functionality as A and additional functionality.
In Figure 4, the components of a use case diagram are shown. Figure 5 displays an
example use case diagram that shows how the components are used. Figure 6
shows use case relationships as of UML 1.5.
<< include>>
<< extend>>
Actor - Use case Use case Stereotype

Actor relationship Generalisation
Figure 4 Components of a use case diagram
3
A scenario is a sequence of steps describing an interaction between a user and a system
[Fowler, 2000].
4
A stereotype is a modeling element that may be used as additional communication (classification)
mechanism that allows us to extend UML notation.
10
Figure 5 A use case diagram
Figure 6 Use case relationships
The essence of the use case model is [Eriksson & Penker, 1998]:
• to capture user requirements by identifying all possible scenarios that the

system's users might follow;
• during the analysis, design and implementation phases to give a clear picture
of what the system should do;
11
• to contribute to testing and system documentation;

• to provide the ability to trace from system nodes, classes etc. back to system
requirements.
The actor depicts the role of a user or users with respect to the system who
exist outside of the system but interact with it. An actor might be a user, a database
or another system that communicates with our system via a communications link.
The sum of actors depicts everything that needs to exchange information with our
system. Actors are identified as adjectives or nouns in the short description of the
system. Examples of actors are shown in Figure 5.
A use case is a sequence of actions that the actor executes in a system to
accomplish a task. A use case is described, from the user point of view, as a verbal
sentence in present tense in active voice. A correct and complete use case describes
a part of the use of the system without assuming anything about its design or
implementation. The result is that all the functionality of the system will be described
by use cases. According to [Fowler, 2000a], a use case describes a main
functionality of the system, which is complete from beginning to end. A use case
should deliver something useful to its actor.
A use case consists of a number of statements expressed in a natural
language. The statements are time-ordered (i.e. they appear in the order things
happen in the system) and simple and declarative (i.e. they do not include
alternatives or IF-THEN-ELSE constructs).
To create use cases we focus in the various scenarios. During this step it
would be desirable for the manual of the system to be produced. Thus, the various
scenarios would correspond to the manuals’ chapters.
In every use case we describe scenarios in a basic as well as alternative action
flows. Each use case is described with the following piece of information:
• ID (use case identity)

• DESCRIPTION (the part of the short description that relates to this use case)
• ACTORS (that appear in the use case diagram)
• PRECONDITION (what must hold before the use case)
• BASIC FLOW (flow of action that leads to successful execution of the use
case)
• EXCEPTIONS/ALTERNATIVE FLOWS (flows of actions that do not lead to
successful execution of the use case)
• POST CONDITIONS (what holds after the use case)
12
• SUB USE CASES (see stereotypes e.g. INCLUDES/EXTENDS)

• EXTENTION POINTS (extension points list)
• REQUIREMENTS TRACES
• NOTES
The <<include>> relationship (see Figure 6) refers to a use case that makes a
complete use of another use case. This normally happens when we find ourselves to
use the same text in many parts of our diagram. We can then move this text in a new
use case and update our diagram with an <<include>> relationship. The use case
that includes the new use case is not complete by itself anymore, but the new use
case is complete and it does not know that it is being used elsewhere.
The <<extend>> relationship is used when we have an alternative flow that we
wish to include in the use case. It is used when we wish to demonstrate alternative
behaviour, i.e. behaviour that is executed only under certain conditions. A use case
that contains extension points is shown in Figure 6. Every extension point should
have a unique name. An <<extend>> relationship is used to show:
• Optional behaviour
• Behaviour that holds under certain conditions
• Alternative flows of action that may be valid due to the actor’s choice.
In the use case documentation there should be stated what happens in the
extension points. The extension consists of conditions, which once satisfied, the
steps of the use case description that relate to the extension point are executed.
4.2. Description of the methodology
The methodology we follow is summarised below:
• We begin by identifying the actors of the system. Every actor needs to have a
unique descriptive name and a short description that defines the actor’s role
with the system.
• Then we identify a first cut of use cases by finding out how the actors interact
with the system. We have then produced our first use case diagram.
• We document each use case with the formula we described above (i.e. id,
description etc.).
13
• We try to analyse use cases further by means of includes, extends

stereotypes and generalisations relationships. From this analysis new use
cases are produced (and maybe new actors) which we document too.
Once our use case diagram(s) describe fully the system under development and its
requirements and we have fully documented use cases, we are ready to proceed
with the next step.
4.3. Example System
Let’s see how we can apply this methodology to our example system under
development. From the system description we identify the actors. We can identify two
actors, the user and the librarian, and if we consider that we shall use a database
management system to store the information stated in the description, then this
database shall be a third actor.
The next step is to find out how our actors interact with the system. This will help us
identify a first cut of use cases. We can do this by going through the description
again. The first statement states:
“There is a need for an automated library system that permits the

registration of books, magazines, documents, electronic data storage
software (CD, floppy, zip etc.) etc.”
There must be a way to insert (register) all these items with the library. This is the
responsibility of the librarian even though it is not stated in the description. Hence, we
can create a use case Registers item for this case.
The next statement:
“A user must be able to browse a library catalogue and be able to do

a search to the catalogue (by author, by title, by ISBN and/or by
keyword).”
notifies us that there should be a use case Search for item that contains also another
use case Browse library catalogue. But for now, let’s assume only the use case
Search for item.
14
“The user will be able to make an application electronically to

borrow a book and after approval, a token will be returned to him/her
and s/he will be able to borrow the item from its physical location
in the library.”
From the above statement, another use case will be Borrow item.
“If the item is not available, s/he will be able to make a

reservation on the item. Reservations will be stored in a FIFO list
for the users.”
The user can also interact with the system with the use case Reserve item.
Continuing the same way we have produced the use case diagram of Figure 7.
Figure 7 A first cut use case diagram for the example system
Next, we must register each actor and use case using the formula described in §4.1.
For example, a short documentation for the actor user would be: “A user can be
anyone who has rights to use the system to search for and borrow an
item”.
15
The documentation for a use case will be:

Use case RESERVE ITEM
ID Reserve item. 5
Description A user can reserve an item if another user has
borrowed it.
Actor(s) User
Preconditions The user is a valid system user (has been
successfully logon into the system) and another
user has borrowed the item s/he wishes to
borrow.
Basic flow of action 1. The user fills in a form with his/her user id
and the item’s id s/he wishes to reserve
2. The user clicks on the reserve button
3. The user is added in the reserve FIFO list for
this item and the system notifies the user
about this.
Post conditions The user has been added in the reserve FIFO
list for the item.
Exceptions/Alternative flows • If the item has not been borrowed by another
user, then the user should be able to directly
borrow it
• If the reserve list is full, the user is notified
about it and is requested to try later.
• If there is a system or communications error
while the user is processing the reservation
form, then no update to the reservation list
should be made and the database should
backtrack the changes.
Sub use cases
Extension points
Requirements tracing “If the item is not available, s/he will be able to
make a reservation on the item. Reservations
will be stored in a FIFO list for the users.” 5
Notes
We see that some fields are empty in the above use case documentation. These
fields will be completed later during the analysis phase.
Once we have documented all use cases, we can now proceed further with our
analysis by rectifying our use case diagram. First, we can analyse more the relation
5 In a real system a use case ID will be of the form: #13. Similarly, requirements come will some sort of numbering, so in the "Requirements
tracing" row, instead of a description of the requirement we would have something like: #906, #45, #34 etc. if the use case refers to more than
one requirement statements.
16
between the user and the librarian. We can assume that the librarian can also be a
normal user of the system, i.e. be able to borrow items, make reservations etc.
However, a librarian has additional responsibilities such as to register new items or
users, receive fine payment etc. Or, we may decide that the librarian cannot perform
what a normal user can do. In this case if the librarian wishes to borrow items too,
then s/he must have a second id with the library, that of a normal user. In
our system, we decide for the first case. Hence, we have to provide a
generalization relationship between the librarian and the user as is shown
in the following diagram.
This relationship means that the librarian can perform all the use cases
the user can perform, plus additional ones, but not the other way round.
We are now in a position to further rectify out use case diagram by use of
associations. We saw in our previous analysis that Search for item use
case also includes a use case Browse items which is not shown in the
use case diagram. The basic flow of action for Search for item use case
is:
Use case SEARCH FOR ITEM
ID Search for item
Description A user can search for an item by author, by title,
by ISBN and/or by keyword.
Actor(s) User
Preconditions The user is a valid system user (has been
successfully logon into the system).
Basic flow of action 1. The user selects search method (by author, by
title, by ISBN and/or by keyword)
2. The user clicks on the ‘search’ button
3. The system returns a list of the item(s) that
satisfy the search criteria or nothing if no item
has been found.
Post conditions
Exceptions/Alternative flows • If there is a system or communications error
before or while the user is searching for an
item, then a relevant message is displayed.
Sub use cases
Extension points
Requirements tracing “A user must be able to browse a library catalogue

and be able to do a search to the catalogue (by
author, by title, by ISBN and/or by keyword).”
17
Notes
5. Step 3.: Requirements tracing
A requirement is a criterion specified by the user that the system must satisfy.
System requirements specify the behaviour and functionality the users demand from
the system. Requirements are normally stated as statements that contain the words
shall or must. There are many types of requirements, like:
• functional requirements,
• data requirements,
• performance requirements,
• capacity requirements,
• test requirements.
We should keep reports from each use case (class) for every requirement that is
satisfied by the use case (class). A use case may refer to more than one
requirements and a combination of use cases may satisfy more than one
requirements.
The procedure to follow up to code generation should be the following:
1. Creation of a list of requirements,

2. System manual production in the form of use cases.
3. Tracing of each part of the design back to system requirements and of each
requirement back to the respective part of the design.
6. Step 4.: Package analysis

6.1. Package view
One of the oldest and most difficult questions in software design is how do we break
down a large system into smaller systems? This is because as systems get larger
and larger, it becomes difficult to understand and maintain them. Package analysis is
UML's method of breaking down large systems.
A package is a container of modeling elements, a general-purpose mechanism for
organizing elements into groups.
18
A package diagram can be used in every step of the UML. It may be a

container of use cases, of classes, of components etc. In the case of use cases,
every package should correspond to a chapter or a main paragraph of the program’s
manual. A package diagram is shown in Figure 8.
Figure 8 A Package diagram
The relationship that connects two packages is called a dependency. A dependency

relationship from package A to package B means that A depends on B playing the
role of a client/supplier relationship (A:client, B:supplier). A dependency exists
between two packages if changes to the definition of one package may cause
changes to the other. A dependency between two packages exists if a dependency
exists between any use cases (or classes for package diagrams containing classes)
in the packages. E.g. because a use case in BorrowRequest package depends on a
use case in SearchRequest package, the two packages are connected with a
dependency relationship (see Figure 7). Good system architecture tries to minimise
dependencies among packages.
In the case of package diagrams containing classes, this means that a class inside
the client package is dependent on a public method of a public class in the supplier
package. Hence, a package's interface contains only the public methods of it public
classes. A good system design technique is to reduce the interface of a package by
exporting only a small subset of the operations associated with the package's public
19
classes. We can do this by giving all classes package visibility, so that they can be
viewed only by other classes in the same package, and by adding extra public
classes in the same package, for the public behaviour of the package. These extra
classes are called facades [Gamma et. al., 1995] and delegate public operations to
their syer companions in the package.
Packages can include other packages, called sub-packages.
Generalisation relationships can also be used with packages [Fowler, 2000a]. This
means that the specific package must conform to the interface of the general
package. The general package may be marked as {abstract} to show that it merely
defines an interface that is implemented by one or more specific packages.
Generalisation implies a dependency relationship from the subtype to the supertype.
You can mark a package as «global», which means that all packages in the system
have a dependency to this package (e.g. a Utilities package). When you show a
package’s contents, you put the name of the package in the tab of the package icon
and the package contents inside the main box. These contents can be a list of
classes, another package diagram, or a class diagram.

This is not a compulsory step but it is very useful in large systems. To create a
package diagram, we begin from a general package diagram that we identify for our
system and we try to allocate use cases inside one of these packages by reading the
basic and alternative descriptions of the use case. During the process we might need
to create new packages or new dependency relationships between existing
packages. Every step that is described in the basic and alternative flows of action
should refer to a use case that is already included inside the same package. If this is
not true, then we should create a dependency relationship between the two
packages.
To summarise:
• From the description of the problem and the use case diagram identify the
packages of the system
• Try to allocate each use case inside a package
• If a use case of a package refers to a use case in another package create a
dependency relationship among the two packages.
20
7. Step 5.: Domain analysis

7.1. Class diagrams I
A domain class diagram contains objects of the real world [Detsis, 2000; Rosenberg,
1999]. A class diagram describes the types of objects in the system and the kinds of
relationships that exist among them. UML class diagrams depict the structural view of
the system and capture the classes involved and the static relationships between
them. [Fowler, 2000a; UML Class Diagrams].
An object is a concept, abstraction, or thing with sharp boundaries and meaning for
an application [Rumbaugh et al., 1991]. An object has: state, behaviour and identity.
The state of an object is one of the possible contditions in which an object may exist.
State is represented by the values or properties or attributes of an object at a given
time. The object state changes over time. Behaviour determines how an object
reacts, i.e. how its state changes with interaction with other objects. Behaviour is
determined by the set of operations or methods the objects can perform. Behaviour
may cause a state change. Finally, identity is the nature of an object that
distinguishes it from all other objects. It is normally a unique attribute that
characterises the object [Detsis, 2000].
A class diagram consists of the following modeling elements: classes and their
structure and behaviour, relationships among classes, multiplicity and navigation
indicators and role names.
A class is a set of objects that share a common structure (represented by attributes),

a common behaviour (represented by operations) common relationships and
common semantics. In other words, a class is a template for creating objects. Every
object is an instance of a class. Classes are usually static while objects are dynamic
(they can be created and destroyed during program execution).
• A class is a collection of objects with similar structure, behaviour, relationships

and semantics. A class consists of attributes and operations.
o An attribute is a named property or a data definition held by instances of
the class. An attribute has a name and a value. An attribute value is the
value of an attribute for a particular object. Attribute names should be
unique within the class. Each instance of a class has a value for every
attribute defined for that class. The syntax of an attribute expression is:
21
stereotype visibility name : type-expression = initial-

value { property-string }
o An operation is a service that can be requested from an object to

affect behavior. Operations access or modify attribute values
belonging to an object. All instances of a class can use the operations
defined for that class. Operations correspond to methods of a class.
However, [Fowler] distinguishes among operations and methods in
that, "an operation is something that is invoked on an object (the
procedure call), whereas a method is the body of procedure"
[2000a:59]. The syntax of an operation expression is:
stereotype visibility name (parameter-list): return-type-

expression { property-string }
o Stereotypes for classes: boundary, entity, control, exception, utility and

persistent.
• Relationships provide a pathway for communication between objects.
o Association is a simple bi-directional relationship that describes the set of
links between the objects in the related classes. From the conceptual
perspective, associations represent conceptual relationships between
classes. Each association has two association ends, the classes of the
association. Each end can be named with a label called a role.
Role names denote the purpose or capacity wherein one class
associates with another. It is placed along the association line
close to the class it modifies. (e.g. the Trade Administrator plays
the role of the manager in the association to the Trade)
Multiplicity is the number of instances of one class related to one
instance of another class. (e.g. in Figure 10, the class on the left is
associated with exactly one instance of the class on the right while
an instance of the class on the right is associated with 0 or more
instances of the class on the left). Multiplicity is an indication of
how many objects may participate in the given relationship. We
don't deal with multiplicity at this stage of the analysis but we
mention it here for completeness.
o Aggregation illustrates the relationship between a whole and its parts
(“has” or “contains” relationship). It is transitive, antisymmetric and knows
the location of its parts.
22
Composite aggregation is an aggregation that its parts cannot

stand on their own (implies exclusive ownership).* Additionally, the
part object may belong to only one whole, and the parts are
expected to live and die with the whole (see Figure 12).
o Navigation restricts association to one direction only. (e.g. an instance of
the class on the left can ‘talk’ to an instance of the class on the right but
not the other way round). We don't deal with navigation at this stage
either. Associations turn into navigations in step 8.
o Dependency: One class (the client) depends upon another class (the
supplier) for a particular service (a semantic relationship). The client does
not have semantic knowledge of the supplier. This means that when the
supplier changes the client may also change. Classes are related via a
dependency relationship when:
an object of the class playing the role of the supplier is global, or
an object of the class playing the role of the supplier is passed as
an argument to an operation of the class playing the role of the
client or
an object of the class playing the role of the supplier is declared
locally.
Dependencies are not transitive [Fowler, 2000a]. Again, dependencies
normally show up during step 8.
o Inheritance: one class shares the structure and/or behaviour of one or
more other classes. It defines a hierarchy of abstractions in which a
subclass inherits from one or more superclasses. It is a relationship
between a superclass and its subclasses where commonality is held at
the superclass level and uniqueness is held at the subclass level (a is-a or
kind-of relationship). There are no multiplicities, roles or names for this
type of relationship. There are two methods to discover inheritance,
generalisation and specialisation [Fowler, 2000a]. In the first method we
seek to create superclasses that encapsulate the common behaviour and
structure of subclasses. In the second method we seek to create
subclasses that are specialisations of the superclasses.
• Constraint rules are functional relationships between entities of a class diagram
(i.e. classes, attributes, relationships etc.). UML allows you to use anything to
describe constraints. The symbol for a constraint is {} (e.g. { top speed < 180 mph
*
In Rational Rose we double click on the aggregation link, we select “Role B Detail” and click on “By
Value” radio button
23
}). Typical constraints in UML are: {ordered}, {bag}, {set}, {hierarchy} [Fowler,
2000a].
Figure 9 shows class icon details.
<<stereotype>>
:Class 0..* 1 Composite
association aggregation
Attributes
Methods aggregation
interface
client supplier
generalisation navigation dependency
Figure 9 Components of a class diagram
Figure 10 shows an example association relationship. The relationship is named with

the name employs. On the bottom of the relationship we see the multiplicity
(cardinality) of the relationship. A company employs many persons. A person is
employed in one company. As we see, a relationship is read from left to right. The
relationship also contains role names. The company, as the employer, employs many
persons. A person is employed, as an employee, by one company.
Figure 10 Example association relationship

An association class is a relationship that has structure and behaviour. This happens
when the information refers to the link between two objects and not to one of the
objects. An example is shown in Figure 11. A student may choose up to 10 courses
and 3 to 15 students can participate in each course. Grade class does not belong to
the Student class as a student may have different grades for each course. Grade
class does not belong to the Course class either, as a course may have different
grades for each student. Hence, it belongs to their link.
Figure 11 Example of an association class
24
The next figure shows an example of an aggregation and a composition. An instance

of Polygon consists of 3 or more instances of Point. Composition means that a Point
can exist only inside one Polygon only and that when the polygon is deleted all its
points will be deleted as well. Multiplicity of one in the composition on the side of the
Polygon is implied (a specific instance of a Point cannot exist in another instance of
Polygon at a specific time). The aggregation, however, means that a Colour may be
shared by many polygons.
Figure 12 Aggregation and composition example

The next figure shows an example of a generalisation and aggregation relationships.
A WindowWithScrollbar is a Window but is not a Scrollbar. A Scrollbar is a part of a
WindowWithScrollbar. Finally, this is a composite aggregation as a scrollbar can not
stand on its own in an application.
Figure 13 A window with a scrollbar
25

Each use case can be partitioned to represent a single activity of an object. These
partitions represent the simple sentences of the basic and alternative flows of events
described in step 2. From these sentences we can identify objects (hence classes)
by applying the following rules [Rosenberg, 1999; Rumbaugh et al., 1991;
Siddalingaiash, 2000]:
• Nouns become objects or attributes.

• Verbs become methods or relationships.
• Possessive clauses denote that the nouns should become methods instead of
objects.
Hence, we have a first cut of a class diagram. In this step we can identify classes and
at most some attributes that are derived from the domain analysis. Further attributes
and methods are discovered later in the methodology (namely by robustness and
interaction diagrams respectively).
[Fowler, 2000a] identifies three categories of class diagrams:
• Conceptual view: this represents the concepts of the domain under study, the
domain class diagrams we describe in this chapter.
• Specification view: this looks at the interfaces of the software, not the
implementation.
• Implementation view: where we actually draw classes for implementation
purposes.
7.3. Example system
8. Step 6.: Robustness analysis

8.1. Robustness view
Robustness analysis is the link between the use case diagram and the sequence
diagram that we describe next. It is the link between analysis – the what – and the
design – the how. This sort of analysis is an examination of the logic of the behaviour
of the system, an examination of completeness, a discovery of new objects and an
26
initial design. By analyzing the use cases descriptions from the previous step we try
to categorise the objects that participate in the use case into three object categories:
• Boundary objects: objects that actors of the system

communicate with. These objects are usually windows,
menus, dialog boxes etc.
• Entity objects: they refer to persistent objects, i.e. database
tables or files that need to store information that will exist
beyond the program’s completion.
• Control objects: they contain all the logic of the application.
They constitute the links between boundary objects and
entity objects. They are usually implemented as methods
that are related with the other object types.
The rules that apply to a robustness diagram are the following:
1. Actors may communicate only with boundary objects.

2. Boundary objects may communicate only with control objects and actors.
3. Entity objects may communicate only with control objects.
4. Control objects may communicate with entity objects and boundary objects but
not with actors.
An example of a robustness diagram is shown in Figure 14.
Figure 14 Example robustness diagram
27
To summarize:
• For each use case create a robustness diagram which depicts the basic and
the alternative flows of action
• Identify the types of objects (i.e. boundary, control or entity objects)
• Create the links between them (basic and alternative flows of action)
according to the description of the use case
• This is a good start to initiate the class diagram of the system and identify
most of the attributes of the classes.
Robustness diagrams are not to be delivered in the final documentation of the

system. They are simple assist diagrams that will help us to identify the objects of the
system, which will help us to produce the sequence diagrams of the following step.
They are created in order to be thrown away once they accomplish their job.
9. Step 7.: Interaction diagrams

9.1. Sequence diagrams
A sequence diagram is a graphical view of a scenario that depicts object interactions
arranged in a time sequence. It shows the functionality of the use cases. Typically,
an interaction diagram captures the behaviour of one use case. It shows a number of
objects and the messages communicated between them within the use case.
In a sequence diagram:
• objects are represented by boxes at the top of a dashed vertical line;

• dashed vertical lines are called lifelines and represent the object's life during
the interaction;
• events (or messages or object interactions) are indicated by horizontal
arrows which are directed from the lifeline representing the client object to the
lifeline representing the supplier object. A self-call is a message that an
objects sends to itself.
o Horizontal arrows are labelled with the event name (the message
name and its argument values)
28
o Time ordering of events is indicated by vertical position, with the

earliest event appearing on top.
• A return message indicates a return from a message (they are represented by
dashed arrows); return messages are usually drawn from right to left.
• An asynchronous message is indicated by half-arrowheads. A caller is not
blocked by an asynchronous message; hence the caller can carry on with its
own processing. An asynchronous message can: create a new thread, create
a new object, or communicate with an already running thread.
• An activation box (focus of control) shows the period of time during which an
object is performing an action either directly or through a subordinate
procedure. An activation is shown as a tall thin rectangle whose top is aligned
with its start time and whose bottom is aligned with its termination time.
• Object deletion is represented with a large X (objects can self-destructed or
be destroyed by another message)
Two kinds of control information worth mentioning [Fowler, 2000a]:
• A condition, which indicates when a message is sent, i.e. the message will be
sent only if the condition holds true (example of a condition is: [usersList not
empty])
• An iteration marker shows that a message is sent many times to multiple
receiver objects (example: *[for all users in UsersList])
An example sequence diagram is shown in Figure 15.
9.2. Collaboration diagrams
A collaboration diagram is a graphical view of a scenario that depicts object

interactions around objects and their links to one another. It captures a snapshot of
the stream of events exchanged between objects during a scenario.
• An object is represented by a rectangle with the name of the object only (A),
or the object class only (:C – anonymous object), or the object and class
name (A:C) as in sequence diagrams
• An interaction link is represented as a line connecting objects. A link indicates
that an event is sent from one object to another. A link may exist between two
objects only if there is an association between their corresponding classes
29
• A message is represented as an arrow on top of the link from the client object
to supplier object and is named with a sequence number (e.g. 1:), the event
name and an argument list in parentheses.
Figure 15 Example sequence diagram

A free standing parameterised collaboration with a well-known name is called a
design pattern [Detsis, 2000; Gamma et al., 1995; Muller, 1999].
Collaboration diagrams are usually applied in real-time and/or embedded
systems. A collaboration diagram demonstrates how the objects of a use case
collaborate to achieve critical parts of the behaviour of the use case. In comparison
to sequence diagrams, collaboration diagrams add information about the timing of
the messages. There are four kinds of messages that are propagated between the
objects of a collaboration diagram:
1. A synchronous message corresponds to an object method which receives it
and which initiates execution only when the sender object has sent the
message and the receiver object is ready to accept the message.
2. A balking message is the same as a synchronous message, but the sender
object cancels the message if the receiver object is unable to accept it.
3. A timeout object is as a synchronous object, but the sender object waits for
the receiver object to be ready to accept the message.
4. An asynchronous message refers to send a message no matter if the receiver
object is ready to receive it or not.
A sample collaboration diagram is shown in Figure 16.
30
5: ac tionP erform ed( ) c learB utton :

1: s how()
JB utton
loginDia logB ox
: JD ialog 6: c lear()
: us er
4: di spl ay authent ic ati on fai le d() 2: ac t ionP erform e d( )
user s Lis t : loginB utton :

Us ers Lis t J Bu tton
3: validateUs er()
Figure 16 Example collaboration diagram
Sequence vs. collaboration diagrams:
• Both diagrams present primarily the same information

o Collaboration diagrams are more graphical
o Sequence diagrams are more tabular
• Collaboration diagrams are often better early in the development cycle before
classes have been defined in detail
• Sequence diagrams allow the display of more interaction and are more
useful later in the development cycle
• Sequence diagrams put emphasis on sequence (order in which things occur)
• Collaboration diagrams show the graphical layout; they indicate how objects
are statically connected
In this step we shall define the methods of the classes that were discovered during
the previous step. In this step we define the behaviour of our system. In other words,
we go for the following targets [Rosenberg, 1999]:
1. Distribution of behaviour to boundary, control and entity objects.

2. Identification of the interactions between the objects of each use case
3. Complete the distribution of the methods to the classes.
31
The methodology that we follow for the creation of sequence diagrams is

summarized as follows:
1. We copy the text of the corresponding use case to the left side of the
sequence diagram.
2. We add the entity objects (from the robustness diagram)
3. We add the boundary objects,
4. Finally, we add the control objects as methods of the respective (boundary
and entity) objects. (Note: A control object may correspond to many methods
in the sequence diagram).
5. Additionally, we can create collaboration and/or activity diagrams to elaborate
further.
The fourth step is the most difficult one and we should make a decision as to which
methods correspond to which objects.
10. Step 8.: Static view

10.1. Class diagrams II
We are finally in the class diagrams, the diagrams where we start the generation of
code! As we mentioned in chapter 7, a class diagram is a graphical representation of
the classes in a system. It is made up of classes and relationships. It depicts the
abstractions into which we have decomposed the problem domain during our
analysis. While step 5 dealt with the conceptual view of the system, this step deals
with the specification and implementation views (see § 7.2). More advanced
concepts of class diagrams are described here.
One way to view a class is that it consists of two parts: the interface and the
implementation. The interface can be seen and used by other objects (e.g. clients of
the class); the implementation is hidden from clients. In other words, the interface is
the set of public methods of the class (see next paragraph). Hiding the
implementation details of an object is called encapsulation or information hiding.
Encapsulation offers two kinds of protection: it protects an object's internal state from
being corrupted by its clients as well as client code from changes in the object's
implementation.
Figure 17 shows class icon details:
32
+ Public visibility means that other classes have direct access to the attribute
or operation
# Protected visibility means that only methods of the class or of a subclass
have access to the attribute or operation
- Private visibility means that only methods of the class have access to the attribute
or operation
/ Derived attribute (association) means that it can be easily calculated from

other attributes (associations). Derived features indicate a constraint between values.
An abstract class is a class that has no instances. It exists primarily to represent a

common abstraction to a number of subclasses. Abstract classes are shown with
their name in italics inside the UML class symbol.
A type is a descriptor for objects with abstract state, concrete external operation
specifications and no operation implementation [Detsis 2000]. It provides a
specification for external behaviour. An interface is the use of a type to describe the
externally visible behaviour of a class. In Java an interface is similar to a protocol.
The notation for an interface in UML has been shown in Error! Reference source
not found.. Interfaces in Java can also have method specification, public static final
constants and structure.
Attribute visibility & properties

+ public attribute or operation GeometricObject
# protected attribute or operation
- private attribute or operation Class attribute
-color : RGB = {10,5,0 }
/ derived attribute or operation #position : Point = (0,0)
+move(delta :Vector=(0,0)):void
+select(p : Point):Boolean
Abstract elements -rotate(angle)
Figure 17 Class notation details

Figure 18 shows the notation for a parameterized class. Java has no support for such
type of class. For more information see [Fowler, 2000a].
T, k: Integer
FArray
1..k
T
Figure 18 A parameterised class, T: an object type, k: FArray length
33
Polymorphism is the ability of different objects to respond differently to the same

message. It allows re-use of a method name by different objects. E.g. a circle and a
rectangle object respond differently when a client calls their draw() methods.
Overloaded methods are new versions of the methods that act on different
arguments of the same class. E.g. the two methods: draw(int x1, int y1, int
x2, int y2) and draw(Point p1, Point p2) are overloaded methods.
Dynamic binding (also known as method resolution) allows a single variable to refer
to different kinds of things, and provides support for leaving until runtime the decision
as to which piece of code is appropriate to implement an opration on that variable. It
allows new objects and code to be interfaced with or added to a system without
affecting existing code and eliminates switch statements. Examples of dynamic
binding are on overloaded and overridden operations.
Overloading uses the same operation name but a different signature (parameters),
while overriding uses the same signature of a superclass in a subclass. Overriding
offers you the ability to call an operation without knowing what kind of object you are
calling.
The produced classes should satisfy the following criteria [Booch, 1991; Detsis,
2000]:
• Coupling: is the measurement of the strength of a connection between classes.
Better decomposition of the system means weaker coupling between its classes,
i.e. classes independent with each other.
• Cohesion: is the measurement of the degree of relation between the attributes
and methods of a class. The stronger the relation the better these elements
cooperate to produce a clear behaviour.
• Sufficiency: implies a minimal interface with which the other parts of the system
can interact.
• Completeness: is the condition on which an interface of a class captures all
relevant aspects of the abstraction. A complete class is theoretically reusable in
a more general framework.
• Primitiveness: is the condition on which a method can be implemented in a
sufficient way only if it has access to the underlying representation of the
abstraction. In other words we can design certain methods, which can be used
as building blocks for the creation of new methods.
34
This is basically the target diagram of the methodology, because this is where coding
begins. The diagrams that follow this step are optional and complementary of the
understanding of the problem. The class diagram is updated constantly in every step
of the methodology. The class diagrams can be created or updated:
• During step 2, in the use case analysis to generate a domain level class
diagram, as we have described in step 5.
• During robustness analysis we should have discovered 70%-80% of our
classes’ attributes. Attributes may also be found by examining class
definitions, the problem requirements, and by applying domain knowledge
[Apostolatos, 1999].
• After interaction analysis we should have discovered the rest of the attributes,
the methods of our classes and we can categorise our classes according to
the following stereotypes [Muller, 1999; Quatrani, 1998] that are commonly
used for classes:
o <<boundary>>: for classes that interface the outside world
o <<control>>: for classes that are responsible for the propagation/
manipulation of information
o <<entity>> : for classes that are abstractions of entities of the real world
o <<exception>> : classes that represent an exception
o <<interface>> : a specifier for actions appearing in the outside world
o <<utility>> : utility classes (e.g. a math class)
o <<persistent>> : for persistent classes
• After every step, organise the classes into packages.
Messages of interaction analysis usually become methods of the class that receives
the message. An exception to this rule are boundary classes which constitute the
graphical part of the system. A message for these classes is a command of the
requirements of the GUI [Quatrani, 1998]. These sort of messages are typically
implemented as a graphic tool (e.g. a button) and they are not transformed to
methods as their behaviour is executed from the graphic tool.
35
Superclasses with several subclasses may have a name discriminator. The

discriminator becomes an attribute of the superclass that identifies the subclass. E.g.
in the following figure, shapeID is a name discriminator which has three possible
values: Line, Circle or Polygon.
Figure 19 Name discriminator example

The target of the designer is now to refine the class diagram(s) further in order to
produce a well-designed system. The following are some guidelines that apply to
class diagrams and good design. [Halbert & O’ Brien, 1997] give the following criteria
regarding whether some functionality should be placed in an object’s interface or give
rise to a new type of object:
• Reusability: would this behaviour be more useful in more than one context?
• Complexity: how difficult is it to implement the behaviour?
• Applicability: how relevant is the behaviour to the type in which it might be
placed?
• Implementation knowledge: Does the behaviour’s implementation depend
upon the internal details of a type?
o During analysis, establish associations among classes. These associations exist

because of the nature of the classes, not because of their specific
implementation.
o For whole/part relationships, specify that a particular association is an
aggregation.
o Create generalizations when necessary. During design, inheritance should be
used to signify subtypes according to the Liskov Substitution Principle (LSP)
[Detsis, 2000]. This strict form of inheritance guarantees correct behaviour of all
36
clients of a class if we substitute the class with any of its subclasses and supports
component interchangeability by leveraging polymorphism. Use of inheritance to
be avoided are:
Inheritance to reuse implementation (use delegation instead)
Suppression of inherited operations by subclasses
Conceptually intuitive generalization/specialization relationships that are not
LSP conformant (e.g. a square is not behaviourally compatible to a
rectangle).
o Make an initial estimate of multiplicity in order to expose hidden assumptions
o During design:
Multiplicity estimates will be refined and updated
Associations will be refined further (generalizations might be created)
Much additional detail will be added.
The indication of a method might denote a relationship. If the class type that is part of
the arguments of the method or that is returned belongs to the basic types of the
programming language (e.g. String) then the relationship should not be presented
in the class diagram.
Multiplicity of 1 is implemented as an embedded object, a reference, or a pointer.

Multiplicity greater than 1 is implemented using a container class (e.g. list, vector)
[Quatrani, 1998].
Java does not support aggregation. This is implemented with inner classes.
Composition is supported with components as attributes of the containment class
(see Figure 20).
Figure 20 Composition notation
37
Java supports simple inheritance plus implementation of interfaces.

A dependency relationship between a client C and a supplier S is implemented either
with the supplier class as an argument to the client constructor (i.e. C(S)) or as an
attribute to the client class.
The following table shows the map from UML to the Java programming language:
Java Element UML Element
Package Package in the Component View
Import · Dependencies between components
and packages in the Component View
(forward and reverse engineering)
· Relationships between classes, which

are not located in the same package. In
forward engineering, generates a Java
import
· Dependency relationships for a

compilation unit in which an associated
class (the client) uses the services of
another class (the supplier) if and only if
the supplier is defined in a different Java
package than the client.
Compilation Unit Component (Module Specification) in the
Component View
Class Class
Interface Class with stereotype of “Interface”
Implements Relationship Realizes relationship between Java class
(subclass) and Java interface (superclass).
Extends Relationship · Generalization relationship
between Java classes.
· Generalization relationship between

Java interfaces.
Field Attribute or Supplier relationship between
classes.
· Java instance variables have Static

property value set to FALSE.
· Java class variables have Static

property set to TRUE
Association relationships are mapped to

fields in a Java class declaration based on
the roles the class plays in the association.
38
Method Operation
Class Modifiers The final modifier is implemented using
the class.Final property. The abstract and
public modifiers are part of the class
specification.
Field Modifiers Properties on fields and roles (e.g.
Role.Final, Attribute.Volatile, etc.). Static
{final, transient, volatile} modifiers
modifier is an element of a role and
attribute specification.
{attribute.Final, attribute.Transient,
attribute.Volatile}
Method modifiers Properties on operations
{operation.Static, operation.Final,
{static, final, abstract, native,
synchronized} operation.Abstract, operation.Native,
operation.Synchronized} operation
properties
{public, protected, private} {public, protected, private} access

access
package-level access implementation access
arrays Attributes whose data types contain an
array designation (for example, int[ ]).
Static Static selector of the attribute or method
specification
Table 1 UML - Java mapping
UML and persistent objects
In this sub-section I give some advice on relating UML to persistent objects (i.e.
databases). The material presented here is derived mainly from [Muller, 1999]. I
simply describe how UML class notation is implemented in: relational, object-
relational and object-oriented DBMSs.
In relational databases, each class becomes a table and each attribute becomes a
column in the table (with public visibility). Relational databases use stored
39
procedures and functions for the dynamic part. I recommend to keep the behavioural
part in the class instead of transforming class operations to stored procedures.
“Making a persistent class abstract has no relationship to data in the relational or
object-relational database, unlike its effect on transient objects and OO databases.
Because of the way you translate the OO data model into the schema, the relational
databases do have data for the abstract class. This data represents the part of the
concrete objects that comes from the abstract class, not an instance of the abstract
class itself.” [Muller, 1999 : 138].
Relational and object-relational databases are not able to represent visibility as they
often provide only public attributes, hence no encapsulation [Muller, 1999]. However,
as we shall see in our example system, we usually define classes to map relational
tables. Hence, it’s a good idea to encapsulate attributes regardless of the way they
are stored in the database. You might also wish to have a look at the new standard
called JDO (Java Data Objects).
11. Step 9.: Object view

11.1. State transition diagrams
State transition diagrams show the life history of a given class, the events that cause
a transition from one state to another, and the actions that result from a state change.
This life cycle is expressed in terms of the different states that the various objects
can find themselves and the events that cause the transitions of their states.
o A State is a situation during the life of an object, which satisfies some
condition, performs some activity, or waits for some event, in other words is
one of the possible conditions in which the object can exist. An object has a
limited number of possible states and can be in only one state at a time (see
Figure 21).
State actions:
entry actions: behaviour that is executed when the state is entered;
do actions (activities): behaviour that starts when a state is entered.
The activity may finish or may be interrupted by an outgoing state
transition;
exit actions: behaviour that is executed when the state is exited.
Special states: start state (mandatory, only one permitted) and stop states
(optional, more than one may be indicated).
40
Nested states.
o A Transition is a change from an originating state to a successor state as a
result of some stimulus. Transitions may be automatic (may not be
interrupted) and they may be labeled with an event, condition, and/or action.
The syntax for a transition label has three parts, all of which are optional: a
event [guard condition]6 / action7 (see Figure 21).
o An event triggers a state transition. Events maybe of several kinds [Detsis,
2000]:
A designated condition becoming true (when keyword; e.g. when (speed >
50 mph))
Receipt of an explicit signal from one object to another
Receipt of a call for an operation by an object
Passage of a designated period of time after a designated event (often
the entry of the current state) (after keyword; e.g. after (10 minutes))
o An activity is a behaviour performed by an object while the object is in a given

state (see do actions above).
Actions and activies are implemented the same but are treated differently. Actions
are associated with transitions and are considered to occur quickly and are not
interrupted, while activities are associated with states and can take longer.
o
event name [ guard condition ] / action
Start & Stop states

Transition
Figure 21 Components of a state transition diagram
Figure 22 shows guarded transitions. A guard condition is a conditional expression in

terms of attribute values that prevents a transition from occurring unless the condition
is true. In the following fig. the state moves from OK to Overdrawn if [balance <
amount] which is the guard condition. The transitions that start and end in the same
state are called self-transitions.
6
A Boolean expression that is used to make a transition conditional, i.e. the transition occurs if and
only if the guard condition is true.
7
Behaviour that accompanies a state transition.
41
Figure 22 Example state transition diagram

UML also defines concurrent state transition diagrams (see e.g. Fowler, 2000a). In
the concurrent sections of such a state diagram the given object is in two different
states, one from each diagram. When the object leaves the concurrent states, it is in
only a single state. Concurrent state transition diagrams are useful when a given
object has sets of independent behaviours.
11.2. Activity diagrams
Activity diagrams depict the activities and the results of these activities. UML
provides the following definition for these diagrams “a subset of a state transition
diagram where the states are activity states and the transitions are automatic”
[Schneider & Winters, 1998]. These diagrams stem from Data Flow Diagrams of
functional programming. Activity diagrams provide a very natural notation for
describing [Detsis, 2000]:
Procedural flow of control

Parallelism and synchronization
Abstract or conceptual system behaviour.
An activity is an operation that takes some time to complete.

For a state with an activity, an outgoing transition that has no triggering event or
guard condition will be fired as soon as the activity terminates. Such transitions are
called automatic or implicit transitions.
A state is called an action state when:
• It has an activity or internal action associated with it
• All of its outgoing transitions are automatic
The notation used for activity diagrams is shown in Figure 23. The majority of states
in an activity diagram are action states.
42
An activity diagram is a variant of a state transition diagram in which most, if not all,
the states are action states [Fowler, 2000a]. Activity diagrams support conditional
and parallel behaviour.
action state
transition Start & Stop states
Fork-join decision swimlane
Figure 23 Activity diagram notation
Branches and merges show conditional behaviour; they are both represented with a
diamond (see Figure 24). A branch has a single incoming transition and several,
mutually exclusive, guarded outgoing transitions. A merge has multiple input
transitions and a single outgoing transition. A merge marks the end of a conditional
behaviour started with a branch. Conditional behaviour can also be shown with
multiple guarded transitions coming out of and going into an action state, hence no
need for branches and merges. Use diamonds if you want to make the branches and
merges clear in your diagram.
Parallel behaviour is indicated by forks and joins. A fork has one incoming transition
and several outgoing transitions that occur in parallel. A join has one outgoing
transition and several incoming transitions and is where a fork is terminated. With a
join, the outgoing transition is taken only when all the states on the incoming
transitions have completed their activities.
An example activity diagram is shown in the figure below. The figure demonstrates
one fork and one join, with the activities ReadState, ExecuteControlLaws and
OutputDemands occurring in parallel.
Dynamic concurrency allows for showing iterations without having constructing a

loop. Dynamic concurrency is represented by a (*) inside the action state that is
repeated [Fowler, 2000a].
Swimlanes allocate action states to the classes or entities that are responsible for
them. To use swimlanes one must arrange the activity diagram into vertical zones
separated by lines. Each zone represents the responsibilities of a particular class.
“Swinlanes are good in that they combine the activity diagram’s depiction of logic with
the interaction diagram’s depiction of responsibility” [Fowler, 2000a:137].
43
Figure 24 An example Activity diagram

States can be distinguished by the values of certain attributes and/or the existence of
links [Detsis, 2000].
State transition diagrams are generated during analysis to capture the behaviour
of objects displaying complex dynamic behaviour (as an extend, the overall
behaviour of a system or a subsystem). There is no need to generate state transition
diagrams for classes that demonstrate very little dynamic behaviour.
Activity diagrams may be used to elaborate on use cases, to specify complex
object behaviour that exhibits a procedural flow of control, as flowcharts to specify
algorithmic design for class operations or to understand multithreading [Detsis 2000;
Fowler, 2000a].
12. Step 10.: Implementation view

12.1. Component diagrams
Component diagrams provide the modeling structures needed to visualize the

physical nature of the system. A component diagram addresses the software
organization of the system. It contains information about the software, executable
and library components for the system. A component diagram shows the
organizations and dependencies among components8.
8
A representation of a source file, a library, or an executable.
44
• Source code components (compile dependencies) show compilation

dependencies among files.
• Run-time components (link time dependencies) show the mapping of classes to
run-time libraries.
• Executable components (run-time dependencies) show the interfaces and calling
dependencies among executables.
Finally, communication dependencies show which components communicate with
one another.
Interface
Dependency
relationship
Figure 25 Component diagram notation
12.2. Deployment diagrams
Deployment diagrams show the configuration of run-time processing elements and

the components, processes, and objects living on them. A deployment diagram
visualizes the distribution of components across the enterprise. The deployment
diagram contains:
• Nodes: A run-time physical object that represents a computational resource,
generally having at least a memory and often processing capability as well, and
• Connections: indicate a communication path between two nodes (may have a
stereotype).
Software
process
processor device
Connection
Node
Figure 26 Components of a deployment diagram
45
Examples of components for component diagrams are:
o Main program, i.e. the Java file that contains the root of the program (the
function main())
o Package, that contains a number of classes
o Subprograms, modules that correspond to subroutine declarations
o Tasks, modules that represent packages with independent threads of control
An example of a deployment diagram could be a client / server architecture.
46
References
1. Booch G. (1991), Object-Oriented Design with Applications, Benjamin-
Cummings.
2. Cockburn A. (1999), Surviving Object-Oriented Projects, Addison-Wesley.
3. Detsis G. (2000), UML course, Intracom internal seminar.
4. Eriksson H.-E., Penker M. (1998), UML Toolkit, John Wiley & Sons, Inc.
5. Fowler M. (2000a), UML Distilled, 2nd Edition, Addison-Wesley.
6. Fowler M. (2000b), Refactoring, Addison-Wesley.
7. Gamma E., Helm R., Johnson R., Vlissides J. (1995), Design Patterns:
Elements of Reusable Object-Oriented Software, Addison-Wesley.
8. Graham I., Wills A., UML Tutorial, MMI – Trireme International,
http://www.yahoo.com/software/.
9. Halbert P., O’ Brien (1997), Using Types and Inheritance in Object Oriented
Programming, IEEE Software, September.
10. Jacobson I., Magnus C., Patrik J., Gunnar O. (1992), Object-Oriented
Software Engineering: A Use Case Driven Approach, Addison-Wesley.
11. Kruchten P. (2000), The Rational Unified Process An Introduction, 2nd Edition,
Addison-Wesley.
12. Martin R.C. (2002), UML for Java Programmers, Prentice-Hall.
13. Muller R.J. (1999), Database Design for Smarties Using UML for Data
Modeling, Morgan Kaufmann.
14. Pressman R. S. (1997), Software Engineering - A practitioner's approach, 4th
edition, European adaptation, McGraw Hill.
15. Quatrani T. (1998), Visual Modeling with Rational Rose and UML, Addison-
Wesley.
16. Rosenberg, D. (1999), Use Case Driven Object Modeling with UML – A
practical approach, Addison-Wesley.
17. Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W. (1991),
Object-Oriented Modelling and Design, Prentice-Hall Int.
18. Schneider G., Winters J.P. (1998), Applying Use Cases – A practical guide,
Addison-Wesley.
19. Siddalingaiash M. (2000), Object-oriented Analysis and Design with Java
(Parts I & II), SIGS Conference for Java Development, M3 & M8.
20. [SDM] Software Development Magazine (1998), Inside the UML, Rational
Software Corporation.
21. UML Class Diagrams,http://javaboutique.internet.com/articles/AJ/UML/.
47

Umlmethod v0 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Umlmethod v0 3

Uploaded by

Copyright:

Available Formats

©2000-2005 John N.

Figure 1 Iterative life cycle phases

Figure 2 The macro development process

Unified Modelling Language (UML) is a language for specifying, constructing,

Figure 3 The 4+1 View Model of Architecture

• Use case view: shows the functionality of the system as perceived by

However, it should be mentioned that this mapping is not as strict as it appears

2. Description of the methodology

2.3. Package analysis: Identification of packages and development of a package

3. Step 1.: Description of the system (a real example)

There is a need for an automated library system that permits the

Each item will be registered to the library with the following

How do we proceed then?

4. Step 2.: Use case analysis

4.1. Use case view

Actor - Use case Use case Stereotype

Figure 4 Components of a use case diagram

Figure 5 A use case diagram

Figure 6 Use case relationships

• to capture user requirements by identifying all possible scenarios that the

• to contribute to testing and system documentation;

• ID (use case identity)

• SUB USE CASES (see stereotypes e.g. INCLUDES/EXTENDS)

4.2. Description of the methodology

The methodology we follow is summarised below:

• We try to analyse use cases further by means of includes, extends

4.3. Example System

“There is a need for an automated library system that permits the

The next statement:

“A user must be able to browse a library catalogue and be able to do

“The user will be able to make an application electronically to

“If the item is not available, s/he will be able to make a

The documentation for a use case will be:

Requirements tracing “A user must be able to browse a library catalogue

5. Step 3.: Requirements tracing

1. Creation of a list of requirements,

6. Step 4.: Package analysis

A package diagram can be used in every step of the UML. It may be a

Figure 8 A Package diagram

The relationship that connects two packages is called a dependency. A dependency

Packages can include other packages, called sub-packages.

6.2. Description of the methodology

7. Step 5.: Domain analysis

A class is a set of objects that share a common structure (represented by attributes),

• A class is a collection of objects with similar structure, behaviour, relationships

stereotype visibility name : type-expression = initial-

o An operation is a service that can be requested from an object to

stereotype visibility name (parameter-list): return-type-

o Stereotypes for classes: boundary, entity, control, exception, utility and

 Composite aggregation is an aggregation that its parts cannot

Figure 9 Components of a class diagram

Figure 10 shows an example association relationship. The relationship is named with

Figure 10 Example association relationship

Figure 11 Example of an association class

The next figure shows an example of an aggregation and a composition. An instance

Figure 12 Aggregation and composition example

Figure 13 A window with a scrollbar

7.2. Description of the methodology

• Nouns become objects or attributes.

[Fowler, 2000a] identifies three categories of class diagrams:

7.3. Example system

8. Step 6.: Robustness analysis

• Boundary objects: objects that actors of the system

Composite aggregation is an aggregation that its parts cannot

Procedural flow of control