Unified Modeling Language

Introduction to the modeling world

1
 Introduction
UML or Unified Modeling Language comes
from Rumbaugh, Booch, and Jacobson (the
three amigos) who combined efforts to
standardize on one modeling language
This is primarily a graphical communication
mechanism for developers and customers
We will learn some, but not all, of the UML
it is very complex, few understand all of it

2
 What is a model ?
A model is a simplification of reality.
Model provides a blueprint of a system
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

3
 Principles of modeling
Principle 1: The choice of what models to create has a
profound influence on how the problem is attacked and the
solution is shaped.
Principle 2: Every model may be expressed at different level
of precision.
Principle 3: The best models are connected to reality.
Principle 4: No single model is sufficient.

4
 Why UML ?
UML is a Language for
Visualizing
Specifying
Constructing
Documenting

5
 UML is a Language
A language provides a vocabulary and some
rules for combining words in the vocabulary.
The vocabulary and rules of modeling
language focuses on the conceptual and
physical representation of a system.
For modeling language the notations are their
vocabulary and there are some predefined
rules for using them.

6
 UML is a language for Visualizing
Most of us when given a programming problem, we just
think it and we code it.
Still we are doing some modeling
but mentally
However there are several problems with this
Communication is harder.
Hard to reconstruct.
Some important property of the s/w can sometimes
be skipped.
Modeling can be
Textual
Graphical
Since UML has some well defined notations and 7
semantics so any designer can visualize the system.
 UML is a language for Specifying
Specifying means building a model that is
Precise
Unambiguous
Complete
UML addresses the specification of all the important
decision of
Analysis
Design
Implementation

8
 UML is a language for Constructing

UML is not a programming language.

But it can be directly used to construct code in variety
of languages.
UML expresses the things graphically while
programming language expresses the things textually.
Forward engineering : Construction of a code from a
model.
Reverse Engineering : Reconstruction of the model
from the code itself.

9
 UML is a language for Documenting
The following documents should also be maintained
by s/w developers
Requirement
Architecture
Design
Source code
Project plan
Tests
Prototype
Releases

10
 Where can we use UML ?
Enterprise information system
Banking and financial services
Telecommunication
Transportation
Defense/ aerospace
Retail
Medical electronics
Scientific
Distributed webbased services

11
 Conceptual Model
Building blocks
Things
Relationships
Diagrams
Things are the abstractions that are the first
class citizens in a model.
Relationship ties things together.
Diagram groups interesting collection of
things.
12
 Things
Four kinds of things are in UML
Structural things
Behavioral things
Grouping Things
Annotational things

13
 Structural Things
These are the nouns in UML.

These are the mostly static parts of a model,

representing elements that are either conceptual
or physical.

Mostly there are seven kind of structural thing

14
 Structural Things
Class: Set of objects sharing same attribute,
operations, relationship and semantics.

15
 Structural Things
Interface: 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.

An interface defines a set of operation specifications

(that is, their signatures) but never a set of
16
operation implementations.
 Structural Things
Collaboration: A collaboration defines an interaction and is
a society of roles and other elements that work together to
provide some cooperative behavior that's bigger than the sum
of all the elements. Therefore, collaborations have structural,
as well as behavioral, dimensions.

A given class might participate in several collaborations. These

collaborations therefore represent the implementation of
patterns that make up a system.
17
 Structural Things
Use Case: 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. A use case is used to structure the
behavioral things in a model.

18
 Structural Things
Active Class A class whose object owns a process
or a thread. ClassName
attributes

operations

Active Class

Components A physical and replaceable part of a

system.
name

Component
19
 Structural Things
Server A node with some memory and processing
capability.

Name

Server

20
 Structural Things

These seven elementsclasses, interfaces, collaborations,

use cases, active classes, components, and nodesare the
basic structural things that you may include in a UML
model. There are also variations on these seven, such as
actors, signals, and utilities (kinds of classes), processes
and threads (kinds of active classes), and applications,
documents, files, libraries, pages, and tables (kinds of
components).

21
 Behavioral Things
Dynamic part of a model
Acts as the verb of the model
Two kinds of behavioral things are present
Interaction massage, action sequence, links etc.
display

Message

State machine states, events, transitions

Waiting

States
22
 Grouping Things
Organizational part of UML.
One kind of grouping things are available in
UML
Packages General purpose mechanism for
organizing.

Package name

Package

23
 Annotational Things
Explanatory part of UML.
Usually notes are used.

24
 Relationships
Dependencies Directed to the things being
depended on.
Dependencies

Association Connections between objects.

0..1 *
Associations

Generalization
Generalization

25
 Relationship
Realization Used in the context of interface
and collaborations.

Realization ?????

????

26
 Diagrams
Class Diagram
Object Diagram
Use case Diagram
Sequence Diagram
Collaboration Diagram
State chart Diagram
Activity Diagram
Component Diagram
Deployment Diagram

27
1. Class diagram
A class diagram shows a set of classes, interfaces, and
collaborations and their relationships. These diagrams are
the most common diagram found in modeling object-
oriented systems. Class diagrams address the static design
view of a system. Class diagrams that include active
classes address the static process view of a system.
2. Object diagram
An object diagram shows a set of objects and their
relationships. Object diagrams represent static snapshots
of instances of the things found in class diagrams. These
diagrams address the static design view or static process
view of a system as do class diagrams, but from the
perspective of real or prototypical cases.
3. Use case diagram
A use case diagram shows a set of use cases and actors
(a special kind of class) and their relationships. Use case
diagrams address the static use case view of a system.
4. Sequence diagram & Collaboration diagram
Both sequence diagrams and collaboration diagrams are
kinds of interaction diagrams. An interaction diagram
shows an interaction, consisting of a set of objects and
their relationships, including the messages that may be
dispatched among them. Interaction diagrams address
the dynamic view of a system.
5. Statechart diagram
A statechart diagram shows a state machine, consisting
of states, transitions, events, and activities. Statechart
diagrams address the dynamic view of a system.
6. Activity diagram
An activity diagram is a special kind of a statechart
diagram that shows the flow from activity to activity
within a system. Activity diagrams address the dynamic
view of a system.
7. Component diagram
A component diagram shows the organizations and
dependencies among a set of components. Component
diagrams address the static implementation view of a
system.
8. Deployment diagram
A deployment diagram shows the configuration of run-
time processing nodes and the components that live on
them. Deployment diagrams address the static
deployment view of an architecture.
 Common Mechanism in UML
adornments : Transaction

+ execute()
+ rollback()
# priority()
timestamp()
Adornments

Common Divisions: Jan: Customer

: Customer
Elyse

32
 Common Mechanism in UML
Extensibility Mechanism:
Stereotype
Tagged Values EventQueue
Constraints {version = 3.2}
<<exception>>
Overflow
add() {ordered}
remove()
flush()

33
 Reference
UML user Guide
Chapter 1,2

34