Unified Modeling Language

Chapter5

Object Oriented Systems Development 1

Introduction
A model is an abstract representation of a
system, constructed to understand the
system prior to building or modifying it.
The term system is used here in a broad
sense to include any process or structure.
A model provides a means for
conceptualization and communication of
ideas in a precise and unambiguous form.

Object Oriented Systems Development 2

Introduction
Most modeling techniques used for
analysis and design involve graphic
languages.
These graphic languages are sets of
symbols.
The symbols are used according to certain
rules of the methodology for
communicating the complex relationships
of information more clearly than
descriptive text.
Object Oriented Systems Development 3
Introduction
Objectory is built around several different
models:
◦ Use-case model. The use-case model defines the
outside (actors) and inside (use case) of the system's
behavior.
◦ Domain object model. Objects of the "real" world are
mapped into the domain object model.
◦ Analysis object model. The analysis object model
presents how the source code (i.e., the
implementation) should be carried out and written.
◦ Implementation model. The implementation model
represents the implementation of the system.
◦ Test model. The test model constitutes the test plans,
specifications, and reports.

Object Oriented Systems Development 4

STATIC AND DYNAMIC
MODELS
A static model can be viewed as a snapshot
of a system's parameters at rest or at a
specific point in time.
Static models are needed to represent the
structural or static aspect of a system.
For example, a customer could have more
than one account or an order could be
aggregated from one or more line items.
Static models assume stability and an
absence of change in data over time.
The unified modeling language class
diagram is an example of a static model.
Object Oriented Systems Development 5
STATIC AND DYNAMIC
MODELS
A dynamic model, in contrast to a static
model, can be viewed as a collection of
procedures or behaviors that, taken together,
reflect the behavior of a system over time.
Dynamic relationships show how the
business objects interact to perform tasks.
For example, an order interacts with
inventory to determine product availability.

Object Oriented Systems Development 6

WHY MODELING?
Building a model for a software system prior
to its construction is as essential as having a
blueprint for building a large building.
Good models are essential for
communication among project teams.
As the complexity of systems increases, so
does the importance of good modeling
techniques.
Many other factors add to a project's success,
but having a rigorous modeling language is
essential.

Object Oriented Systems Development 7

WHY MODELING?
A modeling language must include:
◦ Model elements—fundamental modeling
concepts and semantics.
◦ Notation—visual rendering of model
elements.
◦ Guidelines—expression of usage within the
trade.

Object Oriented Systems Development 8

WHY MODELING?
The use of visual notation to represent or
model a problem can provide us several
benefits relating to clarity, familiarity,
maintenance, and simplification.
◦ Clarity.
 We are much better at picking out errors and
omissions from a graphical or visual representation
than from listings of code or tables of numbers.
 We very easily can understand the system being
modeled because visual examination of the whole is
possible.

Object Oriented Systems Development 9

WHY MODELING?
◦ Familiarity.
 The representation form for the model may turn out
to be similar to the way in which the information
actually is represented and used by the employees
currently working in the problem domain
◦ Simplification.
 Use of a higher level representation generally
results in the use of fewer but more general
constructs, contributing to simplicity and conceptual
understanding.

Object Oriented Systems Development 10

WHY MODELING?
◦ Maintenance.
 Visual notation can improve the maintainability of a
system.
 The visual identification of locations to be changed
and the visual confirmation of those changes will
reduce errors.
 Thus, you can make changes faster, and fewer errors
are likely to be introduced in the process of making
those changes.

Object Oriented Systems Development 11

Advantages of modeling:
Turban cites the following advantages of
modeling:
◦ Models make it easier to express complex
ideas. For example, an architect builds a model
to communicate ideas more easily to clients.
◦ The main reason for modeling is the reduction
of complexity. Models reduce complexity by
separating those aspects that are unimportant
from those that are important. Therefore, it
makes complex situations easier to understand.

Object Oriented Systems Development 12

Advantages of modeling:
Models enhance and reinforce learning
and training.
The cost of the modeling analysis is much
lower than the cost of similar
experimentation conducted with a real
system.
Manipulation of the model (changing
variables) is much easier than
manipulating a real system.
Object Oriented Systems Development 13
Summary of Modeling
To summarize, here are a few key ideas
regarding modeling:
A model is rarely correct on the first try.
Always seek the advice and criticism of
others. You can improve a model by
reconciling different perspectives.
Avoid excess model revisions, as they can
distort the essence of your model. Let
simplicity and elegance guide you through
the process.
Object Oriented Systems Development 14
INTRODUCTION TO THE
UNIFIED MODELING
LANGUAGE
The unified modeling language is a language
for specifying, constructing, visualizing, and
documenting the software system and its
components.
The UML is a graphical language with sets
of rules and semantics.
The rules and semantics of a model are
expressed in English, in a form known as
object constraint language (OCL).
OCL is a specification language that uses
simple logic for specifying the properties of a
system.
Object Oriented Systems Development 15
INTRODUCTION TO THE
UNIFIED MODELING
LANGUAGE
The UML is not intended to be a visual
programming language however, the UML does
have a tight mapping to a family of object-
oriented languages, so that you can get the best of
both worlds.
The goals of the unification efforts were to keep it
simple; to cast away elements of existing Booch,
OMT, and OOSE methods that did not work in
practice; to add elements from other methods that
were more effective; and to invent new methods
only when an existing solution was unavailable.

Object Oriented Systems Development 16

GOALS IN THE DESIGN OF
UML
The
primary goals in the design of the
UML were as follows:
◦ Provide users a ready-to-use, expressive visual
modeling language so they can develop
and exchange meaningful models.
◦ Provide extensibility and specialization
mechanisms to extend the core concepts.
◦ Be independent of particular programming
languages and development processes.

Object Oriented Systems Development 17

GOALS IN THE DESIGN OF
UML
◦ Provide a formal basis for understanding the
modeling language.
◦ Encourage the growth of the OO tools market.
◦ Support higher-level development concepts.
◦ Integrate best practices and methodologies.

Object Oriented Systems Development 18

UML DIAGRAMS
The UML defines nine graphical diagrams:
Class diagram (static)
Use-case diagram
Behavior diagram (dynamic):
 Interaction diagram:
 Sequence diagram
 Collaboration diagram
◦ State chart diagram
◦ Activity diagram
Implementation diagram:
◦ Component diagram
◦ Deployment diagram

Object Oriented Systems Development 19

UML CLASS DIAGRAM
 The UML class diagram, also referred to as
object modeling, is the main static analysis
diagram.
These diagrams show the static structure of
the model.
A class diagram is a collection of static
modeling elements, such as classes and their
relationships, connected as a graph to each
other and to their contents; for example, the
things that exist (such as classes), their
internal structures, and their relationships to
other classes.
Object Oriented Systems Development 20
UML CLASS DIAGRAM
Class diagrams do not show temporal
information, which is required in dynamic
modeling.
Object modeling is the process by which the
logical objects in the real world (problem
space) are represented (mapped) by the
actual objects in the program (logical or a
mini world).
This visual representation of the objects,
their relationships, and their structures is for
ease of understanding.
Object Oriented Systems Development 21
Class Notation: Static Structure
A class is drawn as a rectangle with three
components separated by horizontal lines.
The top name compartment holds the
class name, other general properties of the
class, such as attributes, are in the middle
compartment, and the bottom
compartment holds a list of operations.

Object Oriented Systems Development 22

Class Notation: Static Structure
Either or both the attribute and operation
compartments may be suppressed.
The class name and other properties
should be displayed in up to three
sections.
A stylistic convention of UML is to use
an italic font for abstract classes and a
normal (roman) font for concrete classes.

Object Oriented Systems Development 23

 Person

Person

Name: Character
Height: meters
Person

Work()
Sleep()
Name: Character
Height: meters
Object Diagram
A static object diagram is an instance of a
class diagram.
It shows a snapshot of the detailed state of
the system at a point in time.
Notation is the same for an object
diagram and a class diagram.
Class diagrams can contain objects, so a
class diagram with objects and no classes
is an object diagram.
Object Oriented Systems Development 25
Class Interface Notation
Class interface notation is used to describe
the externally visible behavior of a class; for
example, an operation with public visibility.
The UML notation for an interface is a small
circle with the name of the interface
connected to the class.
A class that requires the operations in the
interface may be attached to the circle by a
dashed arrow.
The dependent class is not required to
actually use all of the operations.

Object Oriented Systems Development 26

Class Interface Notation
For example, a Person object may need to
interact with the BankAccount object to
get the Balance;

Object Oriented Systems Development 27

Binary Association Notation
A binary association is drawn as a solid path
connecting two classes, or both ends may be
connected to the same class.
An association may have an association
name.
Furthermore, the association name may have
an optional black triangle in it, the point of
the triangle indicating the direction in which
to read the name.
The end of an association, where it connects
to a class, is called the association role

Object Oriented Systems Development 28

Binary Association Notation

Object Oriented Systems Development 29

Association Role
A simple association—the technical term for
it is binary association—is drawn as a solid
line connecting two class symbols.
The end of an association, where it connects
to a class, shows the association role.
The role is part of the association, not part of
the class.
Each association has two or more roles to
which it is connected.
In Figure 5-3, the association worksFor
connects two roles, employee and employer.

Object Oriented Systems Development 30

Qualifier
A qualifier is an association attribute. For
example, a person object may be
associated to a Bank object.
An attribute of this association is the
account#.
The account# is the qualifier of this
association (see Figure -5-5).

Object Oriented Systems Development 31

Qualifier

Object Oriented Systems Development 32

Qualifier
A qualifier is shown as a small rectangle
attached to the end of an association path,
between the final path segment and the
symbol of the class to which it connects.
The qualifier rectangle is part of the
association path, not part of the class.
The qualifier rectangle usually is smaller
than the attached class rectangle

Object Oriented Systems Development 33

Multiplicity
Multiplicity specifies the range of
allowable associated classes.
It is given for roles within associations,
parts within and other purposes.
A multiplicity specification is shown as a
text string comprising a period-separated
sequence of integrated intervals, where an
interval represents a range of integers in
this format (see Figure 5-5):
lower bound .. upper bound.

Object Oriented Systems Development 34

Multiplicity
The terms lower bound and upper bound are
integer values, specifying the range of
integers including the lower bound to the
upper bound.
The star character (*) may be used for the
upper bound, denoting an unlimited upper
bound.
If a single integer value is specified, then the
integer range contains the single values. For
example,
◦ 0..1
Object Oriented Systems Development 35
OR Association
An OR association indicates a situation in
which only one of several potential
associations may be instantiated at one
time for any single object.
This is shown as a dashed line connecting
two or more associations, all of which
must have a class in common, with the
constraint string {or} labeling the dashed
line.

Object Oriented Systems Development 36

OR Association

Object Oriented Systems Development 37

Association Class
An association class is an association that
also has class properties.
An association class is shown as a class
symbol attached by a dashed line to an
association path.
The name in the class symbol and the
name string attached to the association
path are the same.

Object Oriented Systems Development 38

Association Class

Object Oriented Systems Development 39

N-Ary Association
An n-ary association is an association
among more than two classes.
Since n-ary association is more difficult
to understand, it is better to convert an n-
ary association to binary association.
An n-ary association is shown as a large
diamond with a path from the diamond to
each participant class.

Object Oriented Systems Development 40

N-Ary Association
The name of the association (if any) is
shown near the diamond.
The role attachment may appear on each
path as with a binary association.
Multiplicity may be indicated; however,
qualifiers and aggregation are not
permitted.

Object Oriented Systems Development 41

N-Ary Association
.An association class symbol may be
attached to the diamond by a dashed line,
indicating an n-ary association that has
attributes, operation, or associations.

Object Oriented Systems Development 42

N-Ary Association

Object Oriented Systems Development 43

Aggregation and Composition (a-
part-of)
Aggregation is a form of association.
A hollow diamond is attached to the end
of the path to indicate aggregation.
However, the diamond may not be
attached to both ends of a line, and it need
not be presented at all.

Object Oriented Systems Development 44

Aggregation and Composition (a-
part-of)

Composition, also known as the a-part-of, is

a form of aggregation with strong ownership
to represent the component of a complex
object.
Composition also is referred to as a part-
whole relationship.
The UML notation for composition is a solid
diamond at the end of a path.
Object Oriented Systems Development 45
Generalization
Generalization is the relationship
between a more general class and a more
specific class.
Generalization is displayed as a directed
line with a closed, hollow arrowhead at
the superclass end.
Ellipses (…) indicate that the
generalization is incomplete and more
subclasses exist that are not shown.
Object Oriented Systems Development 47
Generalization
If a text label is placed on the hollow
triangle shared by several generalization
paths to subclasses, the label applies to all
of the paths.
In other words, all subclasses share the
given properties.

Object Oriented Systems Development 48

USE-CASE DIAGRAM
The use-case concept was introduced by
Ivar Jacobson in the object-oriented
software engineering (OOSE) method.
The functionality of a system is described
in a number of different use cases, each of
which represents a specific flow of events
in the system.

Object Oriented Systems Development 50

USE-CASE DIAGRAM
A use case corresponds to a sequence of
transactions, in which each transaction is
invoked from outside the system (actors)
and engages internal objects to interact
with one another and with the system's
surroundings.

Object Oriented Systems Development 51

USE-CASE DIAGRAM
The description of a use case defines what
happens in the system when the use case is
performed.
In essence, the use-case model defines the
outside (actors) and inside (use case) of the
system's behavior.
Use cases represent specific flows of events
in the system.
The use cases are initiated by actors and
describe the flow of events that these actors
set off.

Object Oriented Systems Development 52

USE-CASE DIAGRAM
An actor is anything that interacts with a use
case: It could be a human user, external
hardware, or another system.
An actor represents a category of user rather
than a physical user.
Several physical users can play the same role.
For example, in terms of a Member actor,
many people can be members of a library,
which can be represented by one actor called
Member.

Object Oriented Systems Development 53

USE-CASE DIAGRAM
A use-case diagram is a graph of actors, a
set of use cases enclosed by a system
boundary, communication (participation)
associations between the actors and the use
cases, and generalization among the use
cases.)
A use case is shown as an ellipse containing
the name of the use case.
The name of the use case can be placed
below or inside the ellipse.

Object Oriented Systems Development 54

USE-CASE DIAGRAM
Actors' names and use case names should
follow the capitalization and punctuation
guidelines of the model.
An actor is shown as a class rectangle
with the label <<actor>>, or the label and
a stick figure, or just the stick figure with
the name of the actor below the figure

55
The three representations of an actor are equivalent.
USE-CASE DIAGRAM
These relationships are shown in a use-case
diagram:
◦ Communication. The communication relationship
of an actor in a use case is shown by connecting
the actor symbol to the use-case symbol with a
solid path. The actor is said to "communicate"
with the use case.
◦ Uses. A uses relationship between use cases is
shown by a generalization arrow from the use
case.
◦ Extends. The extends relationship is used when
you have one use case that is similar to another
use case but does a bit more. In essence, it is like
a subclass. 57
UML DYNAMIC MODELING
(BEHAVIOR DIAGRAMS)
The diagrams we have looked at so far
largely are static.
However, events happen dynamically in all
systems: Objects are created and destroyed,
objects send messages to one another in an
orderly fashion, and in some systems,
external events trigger operations on certain
objects.
Furthermore, objects have states.
The state of an object would be difficult to
capture in a static model.
UML DYNAMIC MODELING
(BEHAVIOR DIAGRAMS)
One can express the dynamic semantics
of a problem with the following diagrams:
Behavior diagrams (dynamic):
◦ Interaction diagrams:
 Sequence diagrams
 Collaboration diagrams
◦ Statechart diagrams
◦ Activity diagrams
UML Interaction Diagrams
Interaction diagrams are diagrams that
describe how groups of objects
collaborate to get the job done.
Interaction diagrams capture the
behavior of a single use case, showing the
pattern of interaction among objects.
There are two kinds of interaction
models: sequence diagrams and
collaboration diagrams.
UML Sequence Diagram
Sequence diagrams are an easy and intuitive
way of describing the behavior of a system
by viewing the interaction between the
system and its environment.
A sequence diagram shows an interaction
arranged in a time sequence.
It shows the objects participating in the
interaction by their lifelines and the
messages they exchange, arranged in a time
sequence.
UML Sequence Diagram
A sequence diagram has two dimensions:
the vertical dimension represents time, the
horizontal dimension represents different
objects.
The vertical line is called the object's
lifeline.
The lifeline represents the object's
existence during the interaction.
UML Sequence Diagram
An object is shown as a box at the top of
a dashed vertical line.
A sequence diagram does not show the
relationships among the roles or the
association among the objects.
An object role is shown as a vertical
dashed line, the lifeline.
UML Sequence Diagram
UML Sequence Diagram
Each message is represented by an arrow
between the lifelines of two objects.
The order in which these messages occur is
shown top to bottom on the page.
Each message is labeled with the message
name.
The label also can include the argument and
some control information and show self-
delegation, a message that an object sends to
itself, by sending the message arrow back to
the same lifeline.
UML Sequence Diagram
 The sequence diagram is very simple and
has immediate visual appeal—this is its
great strength.
A sequence diagram is an alternative way
to understand the overall flow of the
control of a program.
UML Collaboration Diagram
Another type of interaction diagram is the
collaboration diagram.
A collaboration diagram represents a
collaboration, which is a set of objects
related in a particular context, and
interaction, which is a set of messages
exchanged among the objects within the
collaboration to achieve a desired
outcome.
UML Collaboration Diagram
In a collaboration diagram, the sequence
is indicated by numbering the messages.
A collaboration diagram provides several
numbering schemes.
UML Collaboration Diagram
Here 1.2: DialNumber means that the Caller
(1) is calling the Exchange (2); hence, the
number 1.2. The UML uses the decimal
scheme because it makes it clear which
operation is calling which other operation,
although it can be hard to see the overall
sequence
The disadvantage of interaction diagrams is
that they are great only for representing a
single sequential process; they begin to break
down when you want to represent complex
behavior
UML Statechart Diagram
A statechart diagram (also called a state
diagram) shows the sequence of states that an
object goes through during its life in
response to outside stimuli and messages.
The state is the set of values that describes an
object at a specific point in scope and is
represented by state symbols and the
transitions are represented by arrows
connecting the state symbols.
The statechart diagram may contain
subdiagrams.
Object Oriented Systems Development 74
UML Statechart Diagram
A state is represented as a rounded box, which
may contain one or more compartments.
The compartments are all optional.
The name compartment and the internal transition
compartment are two such compartments:.
◦ The name compartment holds the optional name of
the state.
◦ States without names are "anonymous" and all are
distinct.
◦ Do not show the same named state twice in the same
diagram, since' it will be very confusing.

Object Oriented Systems Development 75

UML Statechart Diagram
◦ The internal transition compartment holds a
list of internal actions or activities performed
in response to events received while the object
is in the state, without changing states.
Two special events are entry and exit,
which are reserved words and cannot be
used for event names.

Object Oriented Systems Development 76

UML Statechart Diagram
Idle

Lift receiver and

get dial tone

Start Dial
Entry and start Entry and
dialog. Exit & number.append(n)
stop dial tone

Digit(n)
UML Statechart Diagram
The transition can be simple or complex.
A simple transition is a relationship
between two states indicating that an
object in the first state will enter the
second state and perform certain actions
when a specific event occurs, if the
specified conditions are satisfied, the
transition is said to "fire."

Object Oriented Systems Development 79

UML Statechart Diagram
A complex transition may have multiple
source and target states.
It represents a synchronization or a
splitting of control into concurrent
threads:
◦ A complex transition is enabled when all the
source states are changed, after a complex
transition "fires" all its destination states.
◦ A complex transition is shown as a short
heavy bar.

Object Oriented Systems Development 80

 UML Statechart Diagram

i j

A B

k l

Object Oriented Systems Development 81

UML Activity Diagram
An activity diagram is a variation or special
case of a state machine, in which the states
are activities representing the performance of
operations and the transitions are triggered
by the completion of the operations.
Unlike state diagrams that focus on the
events occurring to a single object as it
responds to messages, an activity diagram
can be used to model an entire business
process

Object Oriented Systems Development 82

UML Activity Diagram
The purpose of an activity diagram is to
provide a view of flows and what is going
on inside a use case or among several
classes.
An activity model is similar to a
statechart diagram, where a token (shown
by a black dot) represents an operation.
An activity is shown as a round box,
containing the name of the operation.
Object Oriented Systems Development 83
UML Activity Diagram
The same operation name may appear more
than once in a state diagram, indicating the
invocation of the same operation in different
phases.
An outgoing solid arrow attached to an
activity symbol indicates a transition
triggered by the completion of the activity.
The name of this implicit event need not be
written, but the conditions that depend on the
result of the activity or other values may be
included
Object Oriented Systems Development 84
UML Activity Diagram
Several transitions with different conditions
imply a branching off of control.
The concurrent control is represented by
multiple arrows leaving a synchronization
bar, which is represented by a short thick bar
with incoming and outgoing arrow.
The concurrent control is represented by
multiple arrows leaving a synchronization
bar, which is represented by a short thick bar
with incoming and outgoing arrow.

Object Oriented Systems Development 85

UML Activity Diagram
Activity and state diagrams express a
decision when conditions are used to indicate
different possible transitions that depend on
Boolean conditions of container object.
Actions may be organized into swimlanes,
each separated from neighboring swimlanes
by vertical solid lines on both sides.
Each swimlane represents responsibility for
part of the overall activity and may be
implemented by one or more objects.

Object Oriented Systems Development 86

UML Activity Decision
Implementation Diagrams
Implementation diagrams show the
implementation phase of systems
development, such as the source code
structure and the run-time implementation
structure.
There are two types of implementation
diagrams:
◦ Component diagrams show the structure of the
code itself.
◦ Deployment diagrams show the structure of the
runtime system.
Object Oriented Systems Development 89
Component Diagram
Component diagrams model the physical
component( such as source code,
executable program, user interface) in the
design.
Components connected by dependency
relationships a component is represented
by the boxed figure

Dependency is shown as a dashed arrow.

Object Oriented Systems Development 90
Component diagrams
Deployment Diagram

Shows the configuration of run-time processing elements

and the software components, process , and objects live in
the system

Deployment diagrams to show how physical modules of

code are distributed on various h/w platform

Object Oriented Systems Development 92

Deployment Diagram

Object Oriented Systems Development 93

Model Management:

Package

•A package is a grouping of model elements.

•Packages themselves may contain other packages.

•A package may contain both subordinate packages and

ordinary model elements.
• A package is a represented as folder, shown as a large
rectangle with a tab attached to its upper left corner.

• If contents of the package are not shown, than the name of

the package is placed within the large rectangle.

• If contents of the package are shown, then the name of the

package may be placed on the tab.
A Package and Its Contents
A Package and Its
Dependencies
UML EXTENSIBILITY

Model Constraints and Comments

Constraints are assumptions or relationships among model

elements specifying conditions and propositions that must be
maintained as true otherwise the system described by the
model would be invalid.
Model Constraints and Comments
UML Meta-Model

•A meta-model is a model of modeling elements.

•The purpose of the UML metamodel is to provide a single,

common, and definitive statement of the syntax and
semantics of the elements of the UML.
UML Meta-Model
The UML meta-model describing the relationship between
association and generalization. Association is depicted as
composition of association roles. Here, we use UML
modeling elements (such as generalization and composition)
to describe the model itself, hence, the term meta-model.