Presentation by:

Chakradhar
 UML
• UML stands for Unified Modeling Language.

• UML is accepted by the Object Management

Group (OMG) as the standard for modeling
object oriented programs.

• UML is a common language for creating

models of Object Oriented Programming.
 UML
• An additional perspective

• Who should use UML?

• How and when should they use it?

• Individual vs. group benefits

 UML

• Java is an Object Oriented language

• Thinking with objects is different

• How can we best teach objects?

 UML
• Dealing with complexity
• Faster development
• Reuse
• Easier maintenance

The above are only achieved successfully

through the proper application of quality
object oriented analysis and design.
 UML
Different members of the development team
• Managers
– need to understand what everybody is doing
• Analysts
– capture business needs and propose solutions
• Designers
– Map solutions to a design architecture
• Coders
– Component builders and component users
• Integrators
• Testers
 UML
Doing Object Modeling: the “correct” way
• Step 1: Write down the scenarios…
• stories about your business processes
• Step 2: Identify class candidates…
• What are the business objects?
• Step 3: Assign major responsibilities…
• What do the objects do?
• Step 4: Identify collaborators…
• An objects provides services for other objects
• Step 5: Walk through the scenarios…
• Work as a group to role play each scenario
• Step 6: Revisit the model…
• redo steps again and again
 UML
Barriers to the “correct” way: Cost and Complexity
• Not everyone has the opportunity to buy all the
tools
• It takes a lot of time to read the books, take
classes and study with a mentor
• So what can the masses of programmers do in
the meantime?
• Developers should be able to use UML as a
navigational map for understanding and to
promote reuse
 UML
A Construction Metaphor
• Think of Programmers as construction
workers
• An analyst/ designer would be an
architect
• UML is like a blueprint
• Construction workers shouldn’t have to
pass architecture courses before being
able to benefit from using blueprints.
 UML
Different Approaches to UML and reverse engineering
• Reverse engineering requires no previous
knowledge of object technology
• Different ways to reverse engineer:
– 1. View an entire library at once
• a lot to swallow
– 2. Explore libraries by building a diagram and
your understanding one step at a time
• active learning produces better mental models that
are more easily retrieved from memory to aid reuse
 UML
UML is comprised of two major components:
• The Meta-model
– UML is unique in that it has a standard data
representation.
– It describes the objects, attributes, and relationships
necessary to represent the concepts of UML within a
software application.
• The Notation
– The UML notation is rich and powerful.
– Two major subdivisions
• notation for modeling the static elements
– design such as classes, attributes, and relationships.
• notation for modeling the dynamic elements
– design such as objects, messages and finite state machines.
 UML
types of diagrams in UML
– Class Diagrams
– Package Diagrams
– Object Diagrams
– Use Case Diagrams
– Sequence Diagrams
– Collaboration Diagrams
– State chart Diagrams
– Activity Diagrams
– Component Diagrams
– Deployment Diagrams
 UML
Class Diagrams Class
These are the backbone of almost Attribute
every object oriented method,
including UML. They describe the Operation()
static structure of a system.
A class icon is simply a rectangle divided into three
compartments.

In an object oriented application, classes have

attributes (member variables), operations (member
functions) and relationships with other classes.
 Class Diagrams
Member variable is followed Class Name
by a colon and by the type of
attribute :Type=initialValue
the variable. If the type is
redundant, or otherwise operation(arg list):return type
unnecessary, it can be
omitted. Example:

Member functions are Circle

followed by Return values. - itsRadius : double

Member function arguments - itsCenter : Point

are just types. Return values + area() : double

+ setRadius(double d)
and Arguments can be
+ setCenter(Point p)
omitted.
 Class Diagrams
Active Class
initiate and control the flow of
activity, while passive classes Active Class
store data and serve other
classes. Illustrate active classes
with a thicker border.

Visibility + Public
Use visibility markers to signify
who can access the information
- Private

contained within a class. # Protected

 Class Diagrams
Composition Relationships
Team
contains Captain

Each instance of type Team seems to contain an

instance of type Captain.
The black diamond represents composition. It is
placed on the Team class as it is the Team that is
composed of a Captain. The arrowhead on the
other end denotes that the relationship is
navigable in only one direction. That is, Captain
does not know about Team.
 Composition Relationship
Composition also indicates that the lifetime
of Captain is dependent upon Team.
If Team is destroyed, Captain will be
destroyed with it.
Example:
class Team
{
private int teamSize;
private Captain skipper;
}
 Class Diagrams
Shape
Inheritance Relationship {abstract}

The inheritance relationship in

Draw()
UML is depicted by a peculiar
Erase()
triangular arrowhead.
This arrowhead, points to the
base class. One or more lines
proceed from the base of the
arrowhead connecting it to Circle Square
the derived classes.
In this diagram Circle and Square
both derive from Shape.
 Inheritance Relation
Name of class Shape is Shape
{abstract}
shown in italics. This
indicates that Shape is Draw()
an abstract class. Note Erase()

also that the operations,

Draw() and Erase() are
also shown in italics.
This indicates that they Circle Square
are pure virtual (abstract
methods).
 Class Diagrams
Aggregation Relationship
WINDOW has a * Shape
Its Shapes {abstract}

The weak form of aggregation is denoted with an

open diamond.
This relationship denotes that the aggregate class
(Window) is in some way the “whole”, and the
other class (Shape) in the relationship is somehow
“part” of that whole.
The Window class contains many Shape instances.
 Aggregation Relationship
has a
class Window
WINDOW * Shape
{abstract}
Its Shapes
{
private vector<Shape*> itsShapes;
}

In UML the ends of a relationship are referred to as

its “roles”. The role at the Shape end of the
aggregation is marked with a “ * ” which indicates
Window contains many Shape instances.
The role has been named by which Window knows
its Shape instances (name of the instance variable)
within Window that holds all the Shapes.
 Class Diagrams
Association Relationship Its Parent

The association has an FRAME

arrowhead to denote that Frame
does not know anything about
Window.
An association is nothing but a
line drawn in between the
WINDOW
participating classes.
Once again note the name on Frame is a Window
the role. This relationship will
almost certainly be implemented
with a pointer of some kind.
 Class Diagrams
Dependency Relationship
The Dependency Relation is represented by a
dashed arrow between two classes where one
class is somehow depends on another class.

If 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.
 Dependency Relationship
Shape
WINDOW has a *
ItsShapes
Draw(DrawingContext)

ItsContext

DrawingContext

Shape class somehow depends upon

DrawingContext. For example, the Draw function
of the Shape class which takes an argument of
type DrawingContext.
 Class Diagrams
Multiplicity (Cardinality)
Place multiplicity notations near the ends of an
association. These symbols indicate the number of
instances of one class linked to one instance of the
other class. For example, one company will have
one or more employees, but each employee works
for one company only.

1 No more than one 0..1 zero or one

* many 0..* zero or many
1..* one or many
 Class Diagram
CLASS CLASS

ATTRIBUTE 1 Has a * ATTRIBUTE

OPERATION() OPERATION()
1

inherit
contains

0...*
CLASS CLASS CLASS

ATTRIBUTE ATTRIBUTE ATTRIBUTE

OPERATION() OPERATION() OPERATION()

Static model of a Cellular Phone
 Class Diagram
Interfaces <<type>>

Interface is an element with all ClassName

abstract methods (pure virtual
functions). Operation()

The primary icon for an interface is just like a class

except that it has a special denotation called a
stereotype the «type» string at the top of the class.

The «type» stereotype indicates that the class is an

interface. This means that it has no member
variables, and that all of its member functions are
pure virtual (abstract).
 Interfaces
Stereotypes are one of the mechanisms that can
be used to extend UML. When a stereotype is
used above the name of a class it indicates that
this class is a special kind of class that conforms
to a rather rigid specification.

The two surrounding characters “«»” are called

guillemets (pronounced Gee-may).
A word or phrase surrounded by guillemets is
called a “stereotype”.
 Interfaces
UML supplies a shortcut for «type» classes. The
“lollypop” notation can be used to represent an
interface. The dependency between Shape and
DrawingContext is shown as usual. The class
WindowsDC is derived from the DrawingContext
interface. This is a shorthand notation for an
inheritance relationship between WindowsDC and
DrawingContext.

Interface Lollypop

Shape WindowsDC
DrawingContext
Turnstile FSM designed with the State pattern.
 Turnstile FSM implemented using the State pattern.

interface TurnstileState
{
protected static LockedState LOCKED;
protected static UnlockedState UNLOCKED;

public void coin(TurnstileFSM tfsm);

public void pass(TurnstileFSM tfsm);
}
 Turnstile FSM implemented using the State pattern.

class LockedState implements TurnstileState

{
public virtual void coin(TurnstileFSM t)
{
………………..
}

public virtual void pass(TurnstileFSM t)

{
……………….
}
}
 Turnstile FSM implemented using the State pattern.

class UnlockedState implements TurnstileState

{
public virtual void coin(TurnstileFSM t)
{
………………
}

public virtual void pass(TurnstileFSM t)

{
………………
}
}
 Turnstile FSM implemented using the State pattern.

abstract class Turnstile

{
abstract public void lock();
abstract public void unlock();
abstract public void thankyou();
abstract public void lock();
}
 Turnstile FSM implemented using the State pattern.

class TurnstileFSM implements Turnstile

{
private TurnstileState itsState;

public void setState(TurnstileState itsState)

{
……………………
}
public void coin()
{
……………………
}
public void pass()
{
……………………
}
}
 UML
Package Diagrams Package Name

Use a tabbed folder to illustrate + ATTRIBUTE 1

packages. Similar to classes, # ATTRIBUTE 2
you can also list the attributes …ATTRIBUTE 3
of a package.

Package diagrams are a subset of class diagrams,

but developers sometimes treat them as a separate
technique.
Package diagrams organize elements of a system
into related groups to minimize dependencies
between packages.
 Package Diagrams
PACKAGE NAME

+ATTRIBUTE 1
<< import >>
# ATTRIBUTE 2
…ATTRIBUTE 3 PACKAGE NAME

+ ATTRIBUTE 1
+ ATTRIBUTE 2

PACKAGE NAME …ATTRIBUTE 3

# ATTRIBUTE 1
# ATTRIBUTE 2
…ATTRIBUTE 3
 UML
Object Diagrams
Object Name: CLASS
Object diagrams describe
Attribute Type = ‘Value’
the static structure of a
Attribute Type = ‘Value’
system at a particular
Attribute Type = ‘Value’
time. They can be used to
test class diagrams for
accuracy.

Object diagrams are also closely linked to class

diagrams. Just as an object is an instance of a
class, an object diagram could be viewed as an
instance of a class diagram.
 Object Diagrams
Basic Object Diagram Symbols and Notations

Each object is represented as a Object name : Class

rectangle, which contains the Named Object
name of the object and its class
: Class
underlined and separated by a
Unnamed Object
colon.
Object name : Class :: Package
Named Object with path name
Active Object :
Objects that control action flow
Object name : Class are called active objects.
Active Object Illustrate these objects with a
thicker border.
 Object Diagrams
Basic Object Diagram Symbols and Notations
Object with attributes :
Object Name: CLASS
As with classes, you can list
Attribute Type = ‘Value’ object attributes in a separate
Attribute Type = ‘Value’ compartment. However, unlike
Attribute Type = ‘Value’ classes, object attributes must
have values assigned to them.
Object with attributes

Multiple Objects :
You can illustrate multiple
Object name : Class
objects as one symbol if the
Multiple Objects
attributes of the individual
objects are not important.
 Object Diagrams
Basic Object Diagram Symbols and Notations
Links :
Links are instances of associations.
You can draw a link using the lines
used in class diagrams.
Self Linked :
Objects that fulfill more than
Object name : Class
one role can be self-linked.
Self Linked

Ex: If Mark, an administrative assistant, also

fulfilled the role of a marketing assistant, and the
two positions are linked, Mark's instance of the two
classes will be self-linked.
 Object Diagrams
Object Name: CLASS
Attribute Type = ‘Value’
Attribute Type = ‘Value’
Attribute Type = ‘Value’
Object Name: CLASS Object Name: CLASS
Attribute Type = ‘Value’ Attribute Type = ‘Value’
Attribute Type = ‘Value’ Attribute Type = ‘Value’
Attribute Type = ‘Value’ Attribute Type = ‘Value’

Object Name: CLASS Object Name: CLASS

Attribute Type = ‘Value’ Attribute Type = ‘Value’
Attribute Type = ‘Value’ Attribute Type = ‘Value’
Attribute Type = ‘Value’ Attribute Type = ‘Value’
 UML
Use Case Diagrams
Use case diagrams model the functionality of
system using actors and use cases. Use cases
are services or functions provided by the system
to its users.
USE CASE

USE CASE

USE CASE

<<USES>>

ACTOR USE CASE

 Use Case Diagrams

System:
USE CASE
Draw your system
boundaries using a
USE CASE
rectangle that contains
use cases. ACTOR

Place actors outside USE CASE

the boundaries.
 Use Case Diagrams
Use Case:
USE CASE Draw use cases using ovals. Label
with ovals with verbs that represent
the systems’ function

Actor:
Actors are the users of a system.
ACTOR
When one system is the actor of
<<ACTOR>> another system, label the actor
System A system with the actor stereotype.
 Use Case Diagrams
Relationship:
USE CASE
Illustrate Relationship <<
US
ES
between an actor and a ACTOR
>>
use case with a simple USE CASE
>
line. For relationships DS>
E N
XT
among use cases, use < < E

arrows labeled either USE CASE USE CASE

“uses” or “extends”.
USES relationship indicates that one use case
is needed by another in order to perform a task.
EXTENDS relationship indicates alternative
options under a certain use case.
System Boundary Diagram
System Boundary Diagram
 Use Case Diagrams
The one thing to remember about use cases is,
tomorrow they are going to change.

No matter how diligently you capture them

No matter how fastidiously you record the details
No matter how thoroughly you think them through
No matter how much effort you apply to exploring
and analyzing the requirements
tomorrow they are going to change.

Think of use cases as: Just In Time Requirements.

 Use Case Diagrams
A use case is a description of the behavior of a
system. That description is written from the point
of view of a user who has just told the system to
do something particular.

Use cases don’t discuss the hidden mechanisms

of the system. They only describe those things
that a user can see.

Of all the diagrams in UML, use case diagrams are

the most confusing, and the least useful.
 Use Case Diagrams
Use Case Relationships

Use case relationships fall into the category of

things that “seemed like a good idea at the time”.

They’ll add no value to your use cases, or to your

understanding of the system, and they will be the
source of many never ending debates about
whether or not to use «extends» or
«generalization».

It is better to ignore the Use Case relationships.

 UML
Sequence Diagrams
Sequence diagrams describe interactions among
classes in terms of an exchange of messages over
time.
Object: Class Object: Class

ACTOR

[condition]
Message Name

[condition] [condition]

Message Name Message Name

 Sequence Diagrams
Class roles describe the way an object
Object: Class will behave in context. Use the UML
object symbol to illustrate class roles,
but don't list object attributes.

Object: Class Object: Class

ACTOR

Activation
boxes represent the time an
object needs to complete a
task.

Activations
 Sequence Diagrams
Messages are arrows that
Object: Class Object: Class
ACTOR
represent communication
between objects.
Use half-arrowed lines to
represent asynchronous
messages.
Asynchronous messages
Messages are sent from an object that
will not wait for a response
Simple from the receiver before
continuing
Synchronous

Asynchronous Balking Time out

 Sequence Diagrams
ACTOR
Object: Class Object: Class
Lifelines are vertical dashed
lines that indicate the
object's presence over time.

Object: Class
ACTOR
Lifelines

Destroying Objects can be

terminated early using an
arrow labeled "<<destroy>>"
that points to an X. <<destroy>>
 Sequence Diagrams
Object: Class Object: Class
ACTOR

Loops A repetition or loop

within a sequence diagram
is depicted as a rectangle.
[condition to exit]
Place the condition for
exiting the loop at the
bottom left corner in square
Loop
brackets [ ]
Race condition between dialing and answering.
Asynchronous Messages and Concurrency
 UML
Collaboration Diagrams: Collaboration diagrams
represent interactions between objects as a series of
sequenced messages. Collaboration diagrams represent
a combination of information taken from class,
sequence, and use case diagrams describing both the
static structure and dynamic behavior of a system.
Object: Class
1.2 [condition]
1. message Message
2. message
Object: Class Object: Class
ACTOR
2.3 [condition]
Message
Object: Class
 Collaboration Diagrams
Class roles describe how objects
Object: Class behave. Use the UML object symbol
to illustrate class roles, but don't list
object attributes.

Association roles describe how

<<global>> an association will behave given a
particular situation. You can draw
association roles using simple lines
labeled with stereotypes.
 Collaboration Diagrams
Messages Unlike sequence
diagrams, collaboration diagrams do
not have an explicit way to denote
1.2 [condition]: time and instead number messages
message name in order of execution. Sequence
numbering can become nested using
1.2 * [loop expression]: the Dewey decimal system. For
message name
example, nested messages under the
first message are labeled 1.1, 1.2, 1.3,
and so on. The a condition for a
message is usually placed in square
brackets immediately following the
sequence number. Use a * after the
sequence number to indicate a loop.
Collaboration Diagram of “Make Phone Call” use case.
Reconciled static model
ADAPTED SERVER pattern for decoupling Button from Dialer
Interface Segregation of the Display
Iterated Dynamic Model
 UML
State chart Diagrams:
State chart diagrams describe the
dynamic behavior of a system in
response to external stimuli. This diagram
models the dynamic flow of control from state
to state within a system.

State chart diagrams are especially

useful in modeling reactive objects
whose states are triggered by specific
events.
 State chart Diagrams

State State Event / Action

Do / Activity Do / Activity

Event / Action

State State
Event / Action
Do / Activity Do / Activity
 State chart Diagrams
States represent situations during the
State life of an object. You can easily
Do / Activity illustrate a state in SmartDraw by using
a rectangle with rounded corners.

Event/action Transition A solid arrow represents

the path between different states of
an object. Label the transition with
the event that triggered it and the
Event/action
action that results from it.
 State chart Diagrams
Initial State A filled circle followed by an
arrow represents the object's initial state.

Final State An arrow pointing to a filled

circle nested inside another circle
represents the object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions
entering it represents a synchronization of
control. A short heavy bar with two
SynchroniSplitting of transitions leaving it represents a splitting
zation Control
of control that creates multiple states.
 UML
Activity Diagrams:
Activity diagrams illustrate the dynamic
nature of a system by modeling the flow
of control from activity to activity.
An activity represents an operation on
some class in the system that results in a
change in the state of the system.
Typically, activity diagrams are used to
model workflow or business processes
and internal operation.
 Activity Diagrams
:Class :Class :Class

Activity

Activity
:Class
Activity

:Class
 Activity Diagrams
Initial State A filled circle followed by an
arrow represents the initial action state.
Final State An arrow pointing to a filled
circle nested inside another circle
represents the final
Object Flow refers to the creation and
modification of objects by activities.
An object flow arrow from an action to Activity
an object means that the action creates
or influences the object. An object flow
arrow from an object to an action Object name : Class
indicates that the action state uses the
object.
 Activity Diagrams
Action states represent the no interruptible
Activity actions of objects. You can draw an action
state in SmartDraw using a rectangle with
rounded corners.
Activity
Action Flow arrows illustrate the
relationships among action states.
Activity

Activity
Branching A diamond
represents a decision with
[condition]
alternate paths. The outgoing
Activity alternates should be labeled
[condition] with a condition or guard
Activity expression. You can also label
one of the paths “else”
 Activity Diagrams
Activity Synchronization bar helps illustrate
parallel transitions. Synchronization
is also called forking and joining.
Activity Activity

swim lane 1 swim lane

2
Activity Activity

Object : Class
Swim lanes group related
Activity
activities into one column.
Subway Turnstile
Turnstile with abnormal events.
Turstile with Violation state
Turnstile with Diagnostic Mode
 UML
Component Diagrams
Component diagrams describe the organization of
physical software components, including source
code, run-time (binary) code, and executables.

Component

Component

Component
 Component Diagrams
Component is a physical building block
Component
of the system. It is represented as a

Interface describes a group of operations used

or created by components.

Component
Dependencies Draw
Component Dependencies among
components using dashed
Dependency
arrows.
Component
 UML
Deployment Diagrams depict the physical
resources in a system, in nodes, components and
connections.

Node Component

Name
Component

Node Component
Node Component

Name Name
Component Component
 Deployment Diagrams
Node is a physical resource that Node Name
executes code components.

Association refers to a physical

Node Node
connection between nodes,
such as Ethernet.

Components and Nodes Server

Place components inside the Component

node that deploys them.

Component
CASE STUDY
Initial Temperature Sensor Design.
Initial Scheduler and Display architecture
Initial Scheduler Sequence Diagram
Observer decouples UI from Scheduler.
Decoupled UI sequence diagram
Barometric Pressure Observers
Decoupled Alarm clock
Sensor Structure
Temperature Sensor with API
Station Toolkit
Station Toolkit and Alarm Clock
Creation of the Alarm Clock
Phase I Package Structure
Package Diagram with Cycle Broken
Weather Station abstract interface
Weather Station Component Package Diagram
Temperature Hi Lo structure.
Hi Lo Scenarios.
Proxy pattern applied to HiLo persistence.
Using Abstract Factory to create the Proxy.
Proxy and Factory package structure
Temperature History
Actors
Use Cases
Use Cases
Use Cases
Use Cases
Use Cases
Use Cases
Use Cases