Introduction

to
UML
Introduction to UML by Jan Pettersen Nytun, page 1

UML Is Based on Object-

oriented Concepts
• A program will typically consist of objects that
cooperate to solve a task.
• An object will typically have attributes (data) and
methods (behavior), this defines the state of the object
and the manner in which the object operates.
• Objects communicate by sending messages to each
other. Sending a message to an object is (typically) the
same as calling a method of the object.

Introduction to UML by Jan Pettersen Nytun, page 2

1
 Class and Object as Defined by
Booch, Rumbaugh and Jacobson

• Class: A description of a set of objects that

share the same attributes, operations,
relationships, and semantics.
• Object: A concrete manifestation of an
abstraction; an entity with a well defined
boundary and identity that encapsulates
state and behavior; an instance of a class.

Introduction to UML by Jan Pettersen Nytun, page 3

UML
• The UML is a language for
– visualizing
– specifying
– constructing
– documenting
the artifacts of a software-intensive system

• UML can also be applied outside the domain

of software development.
Introduction to UML by Jan Pettersen Nytun, page 4

2
 Unified:
Unified

U~
• Unification of earlier object-oriented analysis
and design methods.
• Same concepts and notation for different
application domains and different
development processes.
• Same concepts and notation through the
whole development lifecycle.

M~ Modeling:
• Making a semantically* complete abstraction
of a system.
(* The formal specification of the meaning and behavior of something)

L~ Language:
• A graphical language

Introduction to UML by Jan Pettersen Nytun, page 5

Introduction to UML by Jan Pettersen Nytun, page 6

3
 Some of the UML Goals
• Define an easy-to-learn but semantically rich visual modeling
language.
• Unify ideas from other modeling languages and incorporate
industry best practices.
• Support higher-level development concepts such as collaborations
(design patterns), frameworks and components.
• Provide flexibility for applying different processes and mapping
to different programming languages.
• Support extensibility and specialization mechanisms so that the
core concepts can be extended.
• Provide a formal basis so that model interchange between
different OO tools will be possible.
Introduction to UML by Jan Pettersen Nytun, page 7

The Value of UML

• Open standard.
• Supported by many tools.
• Supports the entire development lifecycle.
• Support diverse application areas.
• Based on experience and needs of the user
community.
Introduction to UML by Jan Pettersen Nytun, page 8

4
 UML 1.3 Is Not a Visual
Programming Language?!
• “UML 1.3 is a visual modeling language. It does not
have all necessary visual and semantic support to
replace programming languages.
But the introduction of Action Semantics into UML has
changed this!”
However, not all will agree on this – State Charts
already existed and can be used instead of Action
Semantics.
• (UML has a tight mapping to a family of OO languages,
e.g., code generation to C++ and Java are common.)
Introduction to UML by Jan Pettersen Nytun, page 9

[6] “Action Semantics UML Extensions let you

express actions as UML objects. An Action object may
take a set of inputs and transform it into a set of outputs
(although one or both sets may be empty), or may
change the state of the system, or both. Actions may be
chained, with one Action's outputs being another
Action's inputs. Actions are assumed to occur
independently - that is, there is infinite concurrency in
the system, unless you chain them or specify this in
another way. This concurrency model is a natural fit to
the distributed execution environment of modern
enterprise and Internet applications.”

Introduction to UML by Jan Pettersen Nytun, page 10

5
 Executable UML
• Abstracting away:
– programming language, software organization
• Class diagrams – showing “things” and structure
(data):
– classes, attributes, associations, constraints
• Statechart diagrams – showing object lifecycle
(control):
– states, events, transitions, procedures
• Action language – showing behavior (algorithm):
– actions
Introduction to UML by Jan Pettersen Nytun, page 11

[2]: The MDA Process

PSM
Bridge
[1]: “… separates the specification of system
functionality from the specification of the
implementation of that functionality on a specific Code
Bridge
technology platform.”

[2]: First, you build a model with a high level of abstraction, that is
independent of any implementation technology. This is called a Platform
Independent Model (PIM).

Next, the PIM is transformed into one or more Platform Specific Models
(PSMs). A PSM is tailored to specify your system in terms of the
implementation constructs that are available in one specific
implementation technology, e.g. a database model, an EJB model.

The final step is to transform a PSM to code. Because a PSM fits its
technology very closely, this transformation is rather trivial. The complex
step is the one in which a PIM is transformed to a PSM.
Introduction to UML by Jan Pettersen Nytun, page 12

6
 MDA Example 1
Several Application
Platform
PIM Independent
Model
Reverse engineer
First transformation

PSM CORBA EJB XML/SOAP Other

Model Model Model Models

Second transformation

CORBA EJB XML/SOAP Other

Implementation Code Code Code Code

Introduction to UML by Jan Pettersen Nytun, page 13

MDA Example 2
Three Tier Solution – One Application

PIM

PSM PSM PSM

Relational DB EJB Comp. Web

PSM PSM PSM

SQL Code EJB Code JSP Code

Introduction to UML by Jan Pettersen Nytun, page 14

7
 Software Engineering
Methods
• Most methods consist of both a modeling
language and a process (who is doing what and when).
• The modeling language, the notation, typically
include some visual language (different types of
diagrams).
• A tool to support the method is also crucial.

Introduction to UML by Jan Pettersen Nytun, page 15

Three of the most popular methods

(What is the difference between a methodologist and a terrorist? Answer: You can negotiate with a terrorist.)

• Object Modeling Technique, OMT,

OMT introduced by Jim
Rumbaugh. OMT is considered to be strong on analysis and
weaker in the design area.

• Booch,
Booch introduced by Grady Booch (Rational Software). This
method is considered to be strong in design and weak when it
comes to analysis.

• OOSE,
OOSE (use cases ) introduced by Ivar Jacobson. OOSE is
considered to be strong when it comes to behavior analysis and
weaker in the other areas.

Introduction to UML by Jan Pettersen Nytun, page 16

8
 UML Is Not a
Development Process
A development process defines:
- Who is doing What,
- When to do it, and
- How to reach a certain goal

• The UML is intentionally process independent, and defining a

standard process was not a goal of UML. Different domain may
require different processes.
• But the UML authors promote a development process that is use-
case-driven, architecture centric, iterative and incremental.
(Example of method: RUP)
Introduction to UML by Jan Pettersen Nytun, page 17

Abstraction
• Abstraction is a fundamental human capability, it
let us filter out nonessential details about a
complex problem or structure.

• Through abstraction a system can be viewed at

different levels.Often there is a hierarchic structure,
each level of model is more precise than its parent.
When developing a software system, code will be the
lowest and most detailed level.

Introduction to UML by Jan Pettersen Nytun, page 18

9
 Modeling
• When you make a model you are making a mapping
from the problem domain to a representation of the
system you are modeling.

Reality
System
System

• When you work object-oriented the model tends to be

close to the system modeled, and a program execution
can be regarded as a simulation of the behavior of
the system.
Introduction to UML by Jan Pettersen Nytun, page 19

Why Do We Model?
• Models give us a template that guides us in
constructing a system.
• If you want to make a building you first make a
blueprint of the building to make, in the same way
you should make a model of the system you want to
make. As the complexity of systems increases, so does
the importance of good modeling techniques.
• Models help us visualize a system at different levels
of abstraction, this makes it easier to manage
complexity and to understand the system.

Introduction to UML by Jan Pettersen Nytun, page 20

10
 More Arguments -
Why Do We Model?

• It is not expensive to experiment with multiple

solutions when you operate on a high level of
abstraction.
• Models document the decisions we have made.
• Models help for communication between
different stakeholders.

Introduction to UML by Jan Pettersen Nytun, page 21

References
[1] OMG Editor: Model Driven Architecture (MDA) (ormsc/01-07-01)
http://www.omg.org/cgi-bin/doc?ormsc/2001-07-01
Accessed 19 August 2002
[2] Addison-Wesley, MDA Explained: The Model Driven Architecture™: Practice and Promise
Anneke Kleppe, Jos Warmer, Wim Bast
(Klasse Objecten, Soest, the Netherlands
http://www.klasse.nl/english/mda/mda-introduction.html)
[6] Introduction to OMG's Unified Modeling Language™ (UML™)
[accessed Aug. 2002] http://www.omg.org/gettingstarted/what_is_uml.htm
Grady Booch, James Rumbaugh and Ivar Jacobson:
The Unified Modeling Language User Guide.
Addison-Wesley, 1999
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy and William Lorenzen:
Object-Oriented Modeling and Design.
Prentice Hall, 1991
Martin Fowler with Kendall Scott:
UML Distilled.
Addison-Wesley, 1997
Terry Quatrani:
Visual Modeling with Rational Rose and UML.
Addison-Wesley, 1998
Rational software:
http://www.rational.com/uml/documentation.html

Introduction to UML by Jan Pettersen Nytun, page 22

11