An Introduction to the

Unified Modeling
Language (UML)

Presented By
Atin Jain
Confidential to Zensar Technologies
Software Development Life Cycle

Confidential to Zensar Technologies

 What is UML?
The Unified Modeling Language™ - UML - is OMG's most-used specification,
and the way the world models not only application structure, behavior, and
architecture, but also business process and data structure.  

The UML is a graphical language for

visualizing
specifying
constructing
documenting
artifacts of a software-intensive system.

Confidential to Zensar Technologies

 Visualizing
explicit model facilitates communication
some structures transcend what can be represented in programming
language
each symbol has well-defined semantics behind it

Specifying

The UML addresses the specification of all important analysis, design and
implementation decisions.

Constructing
Forward engineering: generation of code from model into programming
language
Reverse engineering: reconstructing model from implementation
Round-trip engineering: going both ways

Confidential to Zensar Technologies

 Documenting
Artifacts include:
deliverables, such as requirements documents, functional
specifications and test plans
materials that are critical in controlling, measuring, and communicating
about a system during development and after deployment

Confidential to Zensar Technologies

 Unified Modeling Language(UML)

History of UML
Object Oriented Modeling languages appeared in between 1970s and the late 1980s
OMT : Rumbaugh(General Electric)
OOSE : Jacobson (objectory)
OOD : Booch (rational Software Corporation)
OOA : Coad and Yourdon etc..
 During 1984 and 1994 the number of object-oriented methods increased to 50,
which lead to trouble in using a standard object oriented modeling language by
the users to according to requirements.
 UML effort started officially in October 1994.
& UML consortium was established and invited other organization to contribute
to UML to built a strong and complete UML.
 Presently UML 2.0 in usage.

Confidential to Zensar Technologies

 Creating the UML
UML 2.0
OMG Acceptance, Nov 1997
Final submission to OMG, Sep ‘97 UML 1.1
public First submission to OMG, Jan ´97
feedback
UML partners UML 1.0

Web - June ´96 UML 0.9

OOPSLA ´95 Unified Method 0.8

Other methods Booch method OMT OOSE

Confidential to Zensar Technologies

 Contributions to the UML
Harel
Meyer Gamma, et al
Statecharts
Before and after Frameworks and patterns,
conditions
HP Fusion

Booch method Operation descriptions and

message numbering

Embley
Rumbaugh OMT Singleton classes and
high-level view

Wirfs-Brock
Jacobson OOSE
Responsibilities
Shlaer - Mellor Odell

Object lifecycles Classification

Confidential to Zensar Technologies

 Why do we model?
 Provide structure for problem solving
 Experiment to explore multiple solutions
 Furnish abstractions to manage complexity
 Reduce time-to-market for business problem solutions
 Decrease development costs
 Manage the risk of mistakes

Confidential to Zensar Technologies

 UML Goals

 Define an easy-to-learn but semantically rich visual modeling

language
 Unify the Booch, OMT, and Objectory modeling languages
 Include ideas from other modeling languages
 Incorporate industry best practices
 Address contemporary software development issues
 scale, distribution, concurrency, executability, etc.

 Provide flexibility for applying different processes

 Enable model interchange and define repository interfaces

Confidential to Zensar Technologies

 UML Diagrams

User View Environment View

6. Deployment diagrams
1. Use case diagrams

Structural view

2. Class diagrams
3. Object Diagram

Behavioral View

4. Sequence diagrams
5. Activity diagrams

Confidential to Zensar Technologies

Confidential to Zensar Technologies
 Use Case Diagram

Use case diagrams describe what a system does from the standpoint of an
external observer. The emphasis is on what a system does rather than how. A
use case diagram is a collection of actors, use cases, and their
communications.

A use case is a sequence of actions, including variants, that a system performs

to yield an observable result of value to an actor.

An actor is a coherent set of roles that human and/or non-human users of use
cases play when interacting with those use cases.

Confidential to Zensar Technologies

Simple Use Case Diagram

Display
Balance

Withdraw
Money

Confidential to Zensar Technologies

 Include

You can use the «include» stereotype to indicate that base use case
“includes” the contents or behavior of common use case. This enables
you to factor out frequent common behavior.

«include» Validate
Display Balance
User

Confidential to Zensar Technologies

 Extends

You can use the «extend» stereotype to indicate that base use case may
include the behavior specified by the “extending” use case.

Withdraw «extends» Money

Money Overdrawn

Confidential to Zensar Technologies

Use Case Example

Confidential to Zensar Technologies

A use case generalization shows that one use case is
simply a special kind of another. Pay Bill is a parent use
case and Bill Insurance is the child. A child can be
substituted for its parent whenever necessary. Generalization
appears as a line with a triangular arrow head toward the
parent use case.

Confidential to Zensar Technologies

 Class Diagrams

to model vocabulary of the system, in terms of which abstractions are

part of the system and which fall outside its boundaries
to model simple collaborations (societies of elements that work
together to provide cooperative behavior)
to model logical database schema (blueprint for conceptual design of
database)

Confidential to Zensar Technologies

 Class
A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics.
An attribute is a named property of a class that describes a range of
values that instances of the property may hold.
An operation is a service that can be requested from an object to affect
behavior.

Class Notation

Class_Name
Attributes

Operation()

Confidential to Zensar Technologies

 Relationships

Connections between classes

Dependency
Generalization
Association

Confidential to Zensar Technologies

 Dependency
A dependency is a “using” relationship within which the change in the
specification of one class may affect another class that uses it.

Sometimes the relationship between a two classes is very weak. They are
not implemented with member variables at all. Rather they might be
implemented as member function arguments.

Example: One class uses another in operation

Printer
Transaction
printTransaction()

Confidential to Zensar Technologies

 Generalization
A generalization is a “kind of” or “is a” relationship between a
general thing (superclass or parent) and a more specific thing
(subclass or child).

Account

Current Account Savings Account

Confidential to Zensar Technologies

 Association
An association is a structural relationship within which classes or
objects have common features. (An association between objects is
called a link.)

User Account

Confidential to Zensar Technologies

 Association Adornments
Name
Role
Multiplicity
Aggregation
Composition

Confidential to Zensar Technologies

 Association Name

describes nature of relationship:

Person works for Company

Association Roles

describe “faces” that classes present to each other within association

class can play same or different roles within different associations

employee
Person Company
employer

Confidential to Zensar Technologies

 Association Multiplicity

Specifies how many objects of the class are associated with a single
object of the other class in the association

Example: a Person is employed by one Company; a Company employs

one or more Persons

1..*
Person Company
1

Confidential to Zensar Technologies

 Aggregation

Aggregation is a “whole/part” or “has a” relationship within which one

class represents a larger thing that consists of smaller things.

Company

Department

Confidential to Zensar Technologies

 Composition

Composition is a special form of aggregation within which the parts

are inseparable from the whole.

Window

Frame

Confidential to Zensar Technologies

Association Multiplicity

1 : Necessary
0..1 : Optional
0..* or * : Unspecified
1..* : One or more
1..n : between 1 and n
n,m,l : n, m or l

Confidential to Zensar Technologies

 Visibility

Each contained element has a visibility relative to the containing

package
• A public element is visible to elements outside the package,
denoted by ‘+’
• A protected element is visible only to elements within
inheriting packages, denoted by ‘#’
• A private element is not visible at all to elements outside the
package, denoted by ‘-’

Same syntax for visibility of attributes and operations in classes

Confidential to Zensar Technologies

 Object Diagram
An instance of a class is known as an Object. The attributes identified
by the class now have values associated with it. There might also be
behavior associated with the methods (or operations) identified by
the class.
The UML provides a diagram to identify the types objects that might
instantiated during the execution of the program.

c: Company

d1: Department : Contact Info

name = “R&D” phone = “411”
p1: Person
ID = “13”
Confidential to Zensar Technologies
Figure below provides an example of a song object that we might
see in our Juke Box environment.

As shown, the object diagram (right) is very similar to the class diagram (left).
Close examination shows that the object diagram identifies the instance name
followed by the class name. A colon separates the instance name and class
name, and the complete text is underlined. The attributes of the class are filled
out with information associated to the object.

Again, object classes can be a very simple yet effective technique in identifying
the types of entities that a programmer will want to have instantiate in code at
runtime. Object diagrams are typically used to support the activities associated
with the design effort.
Confidential to Zensar Technologies
 Sequence Diagram
A Sequence Diagram is a powerful visual aid for developers in
understanding the interaction of objects within a system. Use
cases can be applied in concert with class and object diagrams to
create the sequence diagrams.

A lifeline is a vertical dashed line that represents the lifetime of an

object.

Confidential to Zensar Technologies

For example Models a portion of the basic course of action for the "Enroll in Seminar" use case.
The boxes across the top of the diagram represent classifiers or their instances, typically use
cases, objects, classes, or actors.  Because you can send messages to both objects and classes,
objects respond to messages through the invocation of an operation and classes do so through the
invocation of static operations, it makes sense to include both on sequence diagrams.  Because
actors initiate and take an active part in usage scenarios they are also included in sequence
diagrams.  Objects have labels in the standard UML format “name: ClassName” where “name” is
optional (objects that have not been given a name on the diagram are called anonymous objects). 
Classes have labels in the format "ClassName," and actors have names in the format "Actor
Name."  Confidential to Zensar Technologies
 Activity Diagrams
An activity diagram, which resembles a flowchart, is useful for modeling
workflows and the details of operations.
While an interaction diagram looks at the objects that pass messages, an
activity diagram looks at the operations that are passed among objects.

Customer Bank

Enter Card

Enter Pin Authorize

Enter Amount

Valid
Pin

Confidential to Zensar Technologies

Fork/Join:

A fork is a way of showing that a single incoming transition triggers

several outgoing transitions.  These activities occur in parallel.  Since all
of the activities must occur synchronously, you must have a join that joins
together the flows of execution started by each fork.

Branch/Merge:

A branch is a way of showing how a single incoming transition may take

one of several outgoing transitions.  Each outgoing transition must have a
guard that makes it mutually exclusive to the others.

Confidential to Zensar Technologies

Confidential to Zensar Technologies
Confidential to Zensar Technologies
 Swim Lanes

This is actually the same as previous diagram, but

organized into Swim Lanes to show the various
elements of activity (responsibility) between the
Confidential to Zensar Technologies
customer and the Juke Box.
 Deployment Diagram
Deployment diagrams show the physical configurations of
software and hardware.

Transaction

Database
Server
Presentation

Confidential to Zensar Technologies

Confidential to Zensar Technologies
The 3D drawn boxes contain objects (or components) that comprise a physical
element of the system. These boxes are called nodes, and each of these nodes
are connected to show the system architecture. In our example, our Juke box
enterprise can consist of the following:

1.Client PC is a processor node which allow user’s to create personal play lists. The
component used (executed) for this node is the Playlist support component.

2.A Web Repository provides an interface device node for storing play lists. Unlike a
processor node, it not’s really capable of executing a component.

3.The JukeBox System, which would be located in stores and restaurants, is a processor
node used to retrieve, bill and play playlists. The components used for this node include
the playback mechanism, playlist support (note: we’re reusing the same one used by the
client PC!), and the payment support.

Deployment Diagrams can be used as early as the requirements gathering

process to identify the systems (and components) to be procured and used.

Confidential to Zensar Technologies

How all diagrams are useful in a software project
development?

Confidential to Zensar Technologies

 Thank You

Confidential to Zensar Technologies