Chapter 2. Introducing The UML: The Unified Modeling Language User Guide Second Edition

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 35

Chapter 2.

Introducing
the UML
Chapter 2
The Unified Modeling Language User
Guide
SECOND EDITION
By GradyBooch, JamesRumbaugh,
IvarJacobson

What is UML?
Unified Modeling Language
OMG Standard, Object Management Group
Based on work from Booch, Rumbaugh,
Jacobson

UML is a modeling language to express


and design documents, software:
Particularly useful for OO design
Not a process
Independent of implementation language

Latest Version 2.5 (June 2015)

Why use UML


Standardized graphical notation for

Specifying
Visualizing
Constructing and
Documenting software systems

Language can be used from general initial


design to very specific detailed design
Increase understanding/communication of
product to customers and developers
Support for UML in many software
packages today (e.g. Rational)

The UML is a language for


Visualizing
Some things are best modeled
textually; others graphically
The UML is more than just a bunch of
graphical symbols
One developer can write a model in
the UML, and another developer, or
even another tool, can interpret that
model unambiguously

The UML is a language for


Specifying
Specifying means building models
that are precise, unambiguous, and
complete
In particular, the UML addresses the
specification of all the important
analysis, design, and implementation
decisions that must be made in
developing and deploying a softwareintensive system.

The UML is a language for


Constructing
UML is not a visual programming
language, but its models can be
directly connected to a variety of
programming languages
It is possible to map from a model in
the UML to a programming language
such as Java, C++, or VB, or even to
tables in a RDBMS

The UML is a language for


Documenting
The UML addresses the
documentation of a systems
architecture and all of its details
The UML also provides a language for
expressing requirements and for tests
Finally, the UML provides a language
for modeling the activities of project
planning and release management

Building blocks of the


UML
The vocabulary of the UML
encompasses three kinds of building
blocks:
1. Things - abstractions that are firstclass citizens in a model
2. Relationships - tie these things
together
3. Diagrams - group interesting
collections of things

Things in the UML

Structural things
Behavioral things
Grouping things
Annotation things

Structural things
Structural things are the nouns of
the UML model. These are the mostly
static parts of a model, representing
elements that are either conceptual
or physical. There are seven kinds of
structural things.

Structural things
A class is a description of set of
objects that share the same
attributes, operations, relationships,
and semantics.

Structural things
An interface is a collection of
operations that specify a service of a
class or component. An interface
therefore describes the externally
visible behavior of that element

Structural things
A collaboration defines an
interaction and is a society of roles
and other elements that work
together to provide some
cooperative behavior thats bigger
than the sum of all the elements

Structural things
A Use case is a description of set of
sequence of actions that a system
performs that yields an observable
result of value to a particular actor.

Structural things
An active class is a class whose
objects own one or more processes
or threads and therefore can initiate
control activity. An active class is just
like a class except that its objects
represent elements whose behavior
is concurrent with other elements.

Structural things
A component is a physical and
replaceable part of a system that
conforms to and provides the
realization of a set of interfaces.

Structural things
An artifact is a physical and
replaceable part of a system that
contains physical information ("bits").

Structural things
A node is a physical element that
exists at run time and represents a
computational resource, generally
having at least some memory and
often, processing capability.

Behavioral Things
Behavioral things are the dynamic
parts of UML models. These are the
verbs of a model, representing
behavior over time and space. There
are two kinds of behavioral things

Behavioral Things
An interaction is a behavior that
comprises a set of messages
exchanged among a set of objects
within a particular context to
accomplish a specific purpose.

Behavioral Things
A state machine is a behavior that
specifies the sequences of states an
object or an interaction goes through
during its lifetime in response to
events.

Behavioral Things
An activity is a behavior that specifies the
sequence of steps a computational process
performs. In an interaction, the focus is on the set
of objects that interact.
In a state machine, the focus is on the life cycle
of one object at a time. In an activity, the focus is
on the flows among steps without regard to which
object performs each step.
A step of an activity is called an action.

Grouping Things
Grouping things are the
organizational parts of UML models.
These are the boxes into which a
model can be decomposed. There is
one primary kind of grouping thing,
namely, packages.
There are also variations, such as
frameworks, models, and subsystems
(kinds of packages).

Grouping Things
A package is a general-purpose mechanism for
organizing elements into groups. Structural
things, behavioral things, and even other
grouping things can be placed in a package.
Unlike components (which exists at runtime), a
package is purely conceptual (meaning that it
only exists at development time).

Annotational Things
Annotational things are the explanatory parts of
UML models. These are the comments you may
apply to describe, illuminate, and remark about
any element in a model.
There is one primary kind of annotational thing,
called a note. A note is simply a symbol for
rendering constraints and comments attached to
an element or a collection of elements.

Relationships in the UML


There are four kinds of relationships
in the UML:
1.
2.
3.
4.

Dependency
Association
Generalization
Realization

Relationships in the UML


A dependency is a semantic
relationship between two things in
which a change to one (the
independent thing) may effect the
semantics of the other thing (the
dependent thing).

Relationships in the UML


An Association is a structural
relationship that describes a set of
links. A link is a connection among
objects.

Relationships in the UML


A generalization is a specialization/
generalization relationship in which objects of the
specialized element (the child) and substitutable
for objects of the generalized element (the
parent). In this way, the child shares the structure
and behavior of the parent.

Relationships in the UML


A realization is a semantic
relationship between classifiers,
wherein one classifier specifies a
contract that another classifier
guarantees to carry out.

Diagrams in the UML


A diagram is the graphical
presentation of a set of elements,
most often rendered as a connected
graph of vertices (things) and arcs
(relationships). The UML includes
nine such diagrams.

Diagrams in the UML


1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

Class diagram (Static Design or Process View)


Object diagram (Static Design or Process View)
Component diagram (Static Design Implementation View)
Composite structure diagram (Hybrid)
Use case diagram (Static Use Case View)
Sequence diagram (Dynamic View with Time Ordering)
Communication diagram (Dynamic View with structure)
State diagram (Dynamic View of object)
Activity diagram (Dynamic Process View)
Deployment diagram (Static Deployment View)
Artifact diagram (Static Implementation view)
Package diagram (Static View)
Timing diagram (Dynamic view with specific time)
Interaction overview diagram (Hybrid)

Modeling a System's
Architecture

Software Development
Life Cycle

Software Development
Life Cycle

Inception is the first phase of the process, when the seed idea for the
development is brought up to the point of being at least internally sufficiently
well-founded to warrant entering into the elaboration phase.
Elaboration is the second phase of the process, when the product
requirements and architecture are defined. In this phase, the requirements
are articulated, prioritized, and baselined. A system's requirements may
range from general vision statements to precise evaluation criteria, each
specifying particular functional or nonfunctional behavior and each providing
a basis for testing.
Construction is the third phase of the process, when the software is brought
from an executable architectural baseline to being ready to be transitioned to
the user community. Here also, the system's requirements and especially its
evaluation criteria are constantly reexamined against the business needs of
the project, and resources are allocated as appropriate to actively attack
risks to the project.
Transition is the fourth phase of the process, when the software is delivered
to the user community. Rarely does the software development process end
here, for even during this phase, the system is continuously improved, bugs
are eradicated, and features that didn't make an earlier release are added.
An iteration is a distinct set of work tasks, with a baselined plan and
evaluation criteria that results in an executable system that can be run,
tested, and evaluated.

You might also like