UML.pdf

Introduction to UML
Dr.S.Neelavathy Pari
Assistant Professor (Sr. Grade)
Department of Computer Technology
Anna University, MIT Campus

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, but some have been proposed
using UML
– Independent of implementation language

Why use UML ?
• Open Standard, Graphical notation for
– Specifying, visualizing, constructing, and documenting software systems
• Language can be used from general initial design to very specific
detailed design across the entire software development lifecycle
• Increase understanding/communication of product to customers
and developers
• Support for diverse application areas
• Support for UML in many software packages today (e.g. Rational,
plugins for popular IDE’s like NetBeans, Eclipse)
• Based upon experience and needs of the user community

UML
• OMG is continuously making efforts to create a truly industry standard.
– UML stands for Unified Modeling Language.
– UML is different from the other common programming languages such as C++,
Java, COBOL, etc.
– UML is a pictorial language used to make software blueprints.
– UML can be described as a general purpose visual modeling language to
visualize, specify, construct, and document software system.
– Although UML is generally used to model software systems, it is not limited
within this boundary. It is also used to model non-software systems as well.
For example, the process flow in a manufacturing unit, etc.
• UML is not a programming language but tools can be used to generate
code in various languages using UML diagrams.
• UML has a direct relation with object oriented analysis and design.
• After some standardization, UML has become an OMG standard.

UML
• For now, understand that UML is a language – it is used to
communicate information
• We will use UML to describe the problem domain, describe
the activities that occur, and eventually describe the software
classes
• Since it is a language, UML has specific rules, and we will see
these later in the course
• You need to be able to read UML diagrams, as well as create
them Here are some examples (we will learn more about how
to create these diagrams later …)

UML
• Conceptual Perspective – defining the
problem domain: Raw class diagrams, maybe
mention some attributes (Domain Model)
• Specification Perspective – defining the
software classes: Design Class diagram, which
shows the actual software classes and their
methods, attributes

A Conceptual Model of UML
• A conceptual model can be defined as a model which is
made of concepts and their relationships.
• A conceptual model is the first step before drawing a UML
diagram.
• It helps to understand the entities in the real world and how they
interact with each other.
• As UML describes the real-time systems, it is very
important to make a conceptual model and then
proceed gradually. The conceptual model of UML can
be mastered by learning the following three major
elements −
– UML building blocks
– Rules to connect the building blocks
– Common mechanisms of UML

Systems, Models and Views
• A model is an abstraction describing a subset of a system.
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules for depicting
views
• Views and models of a single system may overlap each other
Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system

Object-Oriented Concepts
• UML can be described as the successor of object-oriented
(OO) analysis and design.
• An object contains both data and methods that control the
data.
– The data represents the state of the object.
– A class describes an object and they also form a hierarchy to
model the real-world system.
– The hierarchy is represented as inheritance and the classes
can also be associated in different ways as per the
requirement.
• Objects are the real-world entities that exist around us
and the basic concepts such as abstraction, encapsulation,
inheritance, and polymorphism all can be represented
using UML.

Fundamental concepts of the object-
oriented world
• Objects − Objects represent an entity and the basic
building block.
• Class − Class is the blue print of an object.
• Abstraction − Abstraction represents the behavior of
an real world entity.
• Encapsulation − Encapsulation is the mechanism of
binding the data together and hiding them from the
outside world.
• Inheritance − Inheritance is the mechanism of making
new classes from existing ones.
• Polymorphism − It defines the mechanism to exists in
different forms.

• The purpose of OO analysis and design can
described as
– Identifying the objects of a system.
– Identifying their relationships.
– Making a design, which can be converted to
executables using OO languages.
OO Analysis → OO Design → OO implementation using OO languages

• The conceptual model of UML can be mastered
by learning the following three major elements
1. UML building blocks
2. Rules to connect the building blocks
3. Common mechanisms of UML

1. UML building blocks
The building blocks of UML can be defined as
 Things
 Relationships
 Diagrams

1. UML building blocks - Things
Things are the most important building blocks of
UML. Things can be
– Structural
– Behavioral
– Grouping
– Annotational

2. UML building blocks - Relationship
• Relationship. It shows how the elements are
associated with each other and this association
describes the functionality of an application.
• There are four kinds of relationships available.
– Dependency
– Association
– Generalization
– Realization

2. UML building blocks - Relationship

3. UML building blocks - UML Diagrams
• UML includes the following nine diagrams
– Class diagram
– Object diagram
– Use case diagram
– Sequence diagram
– Collaboration diagram
– Activity diagram
– State chart diagram
– Deployment diagram
– Component diagram

UML - Architecture
• UML plays an important role in defining different
perspectives of a system namely
– Design of a system consists of classes, interfaces, and
collaboration. UML provides class diagram, object
diagram to support this.
– Implementation defines the components assembled
together to make a complete physical system. UML
component diagram is used to support the
implementation perspective.
– Process defines the flow of the system. Hence, the
same elements as used in Design are also used to
support this perspective.
– Deployment represents the physical nodes of the
system that forms the hardware. UML deployment
diagram is used to support this perspective.

Class Notation
class is represented by the
following figure
• The top section is used to
name the class.
• The second one is used to
show the attributes of the
class.
• The third section is used to
describe the operations
performed by the class.
• The fourth section is optional
to show any additional
components.

Object Notation
• As the object is an actual
implementation of a class,
which is known as the
instance of a class

Behavioral Things
• Dynamic parts are one of the most important
elements in UML.
• UML has a set of powerful features to represent the
dynamic part of software and non-software systems.
• These features include interactions and state
machines.
Interactions can be of two types −
• Sequential (Represented by sequence diagram)
• Collaborative (Represented by collaboration diagram)

Interaction Notation
Interaction is basically a
message exchange
between two UML
components

State Machine Notation
Describe different states of system component (active , idle)

Relationships
• A model is not complete unless the relationships
between elements are described properly.
• The Relationship gives a proper meaning to a UML
model.
Following are the different types of relationships available in UML
– Dependency
– Association
– Generalization
– Extensibility

Component diagrams
• Component diagrams are different in terms of nature and
behavior.
• Component diagrams are used to model the physical aspects
of a system.
• Now the question is, what are these physical aspects?
– Physical aspects are the elements such as executables, libraries, files,
documents, etc. which reside in a node.
• Component diagrams are used to visualize the organization
and relationships among components in a system.
• These diagrams are also used to make executable systems.

How to Draw a Component
Diagram?
• Component diagrams are used to describe the
physical artifacts of a system.
– This artifact includes files, executables, libraries, etc
• The purpose of this diagram is different. Component
diagrams are used during the implementation phase
of an application. However, it is prepared well in
advance to visualize the implementation details.

How to Draw a Component
Diagram?

Where to Use Component
Diagrams?

UML - Deployment Diagrams
• Deployment diagrams are used to visualize the
topology of the physical components of a
system, where the software components are
deployed.
• Deployment diagrams are used to describe
the static deployment view of a system.
Deployment diagrams consist of nodes and
their relationships.

Purpose of Deployment Diagrams
• Deployment diagrams are used for describing the hardware
components, where software components are deployed.
Component diagrams and deployment diagrams are closely
related.
• special diagrams used to focus on software and hardware
components.
• The purpose of deployment diagrams can be described as
– Visualize the hardware topology of a system.
– Describe the hardware components used to deploy software
components.
– Describe the runtime processing nodes.

How to Draw a Deployment
Diagram?
• Deployment diagrams are useful for system engineers. An efficient deployment
diagram is very important as it controls the following parameters −
– Performance
– Scalability
– Maintainability
– Portability
• Before drawing a deployment diagram, the following artifacts should be identified
− Nodes
– Relationships among nodes
• Following is a sample deployment diagram to provide an idea of the deployment
view of order management system. Here, we have shown nodes as −
– Monitor
– Modem
– Caching server
– Server

How to Draw a Deployment
Diagram?
• The application is assumed to be
a web-based application, which is
deployed in a clustered
environment using server 1,
server 2, and server 3.
• The user connects to the
application using the Internet.
• The control flows from the
caching server to the clustered
environment.

Where to Use Deployment
Diagrams?
• Deployment diagrams are mainly used by system engineers.
• These diagrams are used to describe the physical components
(hardware), their distribution, and association
Deployment diagrams can be used −
– To model the hardware topology of a system.
– To model the embedded system.
– To model the hardware details for a client/server system.
– To model the hardware details of a distributed application.
– For Forward and Reverse engineering.

UML - Use Case Diagrams
• To model a system, the most important aspect is to capture
the dynamic behavior.
• Dynamic behavior means the behavior of the system when it
is running/operating
• These internal and external agents are known as actors.
• Use case diagrams consists of actors, use cases and their
relationships.
• The diagram is used to model the system/subsystem of an
application.
• A single use case diagram captures a particular functionality
of a system..

Purpose of Use Case Diagrams
• Used to gather the requirements of a system.
• Used to get an outside view of a system.
• Identify the external and internal factors
influencing the system.
• Show the interaction among the requirements
are actors.

How to Draw a Use Case Diagram?
• Use case diagrams are considered for high level requirement analysis of a
system.
• When the requirements of a system are analyzed, the functionalities are
captured in use cases.
• Actors can be defined as something that interacts with the system. Actors
can be a human user, some internal applications, or may be some external
applications.
When we are planning to draw a use case diagram, we should have the
following items identified.
– Functionalities to be represented as use case
– Actors
– Relationships among the use cases and actors.
– System Boundary (System of interest in relation to the world around it)

• Use case diagrams are drawn to capture the functional requirements of a
system.
• After identifying the above items, we have to use the following guidelines
to draw an efficient use case diagram
– The name of a use case is very important. The name should be chosen in such a way so
that it can identify the functionalities performed.
– Give a suitable name for actors.
– Show relationships and dependencies clearly in the diagram.
– Do not try to include all types of relationships, as the main purpose of the diagram is to
identify the requirements.
– Use notes whenever required to clarify some important points.

Relationships in Use Case Diagrams
• There are five types of relationships in a use
case diagram.
Association between an actor and a use case
Generalization of an Actor
Extended Relationship between two use cases
Include relationship between two use cases
Generalization of the use case

Association Between Actor and Use Case

Extend Relationship Between Two Use Cases

Include Relationship Between Two Use Cases

Generalization of a Use Case
• This is similar to the generalization of an actor.
The behavior of the ancestor is inherited by
the descendant. This is used when there is
common behavior between two use cases and
also specialized behavior specific to each use
case.
• For example, in the previous banking example,
there might be a use case called “Pay Bills”.
This can be generalized to “Pay by Credit
Card”, “Pay by Bank Balance” etc

• Following is a sample use case
diagram representing the order
management system. Hence, if we
look into the diagram then we will
find three use cases (Order,
SpecialOrder, and NormalOrder) and
one actor which is the customer.

Where to Use a Use Case
Diagram?
• Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.

Business USE CASE
• A business use case is described in technology-free
terminology which treats the business process as a black box
and describes the business process that is used by its business
actors, while an ordinary use case is normally described at the
system functionality level and specifies the function or the
service that the system provides for the user.
• Business use case represents how the work to be done
manually in the currently situation and it is not necessarily
done by the system or intend to be automated in the scope of
target system.

Examples : ATM use case diagram

Document Management System
(DMS)

Draw packages for logical categorization of use
cases into related subsystems.

UML - Interaction Diagrams
• This interactive behavior is represented in
UML by two diagrams known as Sequence
diagram and Collaboration diagram.
• Sequence diagram emphasizes on time
sequence of messages and collaboration
diagram emphasizes on the structural
organization of the objects that send and
receive messages.

UML - Interaction Diagrams
• The purpose of interaction diagram is −
– To capture the dynamic behavior of a system.
– To describe the message flow in the system.
– To describe the structural organization of the objects.
– To describe the interaction among objects.
• Following things are to be identified clearly before
drawing the interaction diagram
– Objects taking part in the interaction.
– Message flows among the objects.
– The sequence in which the messages are flowing.
– Object organization.

Interaction diagrams can be used −
– To model the flow of control by time sequence.
– To model the flow of control by structural
organizations.
– For forward engineering.
– For reverse engineering.

Sequence Diagram Notations
• A sequence diagram is structured in such a
way that it represents a timeline which begins
at the top and descends gradually to mark the
sequence of interactions
. Each object has a column and the messages
exchanged between them are represented by
arrows.

Sequence Diagram :Lifeline Notation
• A sequence diagram is made up of
several of these lifeline notations that
should be arranged horizontally
across the top of the diagram.
• No two lifeline notations should
overlap each other.
• They represent the different objects
or parts that interact with each other
in the system during the sequence.
• A lifeline notation with an actor
element symbol is used when the
particular sequence diagram is
owned by a use case.

Sequence Diagram :Lifeline
Notation

Activation Bars
• Activation bar is the box placed on the lifeline. It is used to
indicate that an object is active (or instantiated) during an
interaction between two objects.
• The length of the rectangle indicates the duration of the
objects staying active.
• In a sequence diagram, an interaction between two objects
occurs when one object sends a message to another.
• The use of the activation bar on the lifelines of the Message
Caller (the object that sends the message) and the Message
Receiver (the object that receives the message) indicates that
both are active/is instantiated during the exchange of the
message

Message Arrows
• An arrow from the Message Caller to the Message
Receiver specifies a message in a sequence diagram.
• A message can flow in any direction; from left to
right, right to left or back to the Message Caller itself.
• The message arrow comes with a description, which is
known as a message signature, on it.
attribute = message_name (arguments): return_type
Note : All parts except the message_name are optional.

Message Arrows
• Synchronous message is used when the sender waits
for the receiver to process the message and return
before carrying on with another message.
• The arrowhead used to indicate this type of message
is a solid one, like the one below.
• Asynchronous message is used when the message
caller does not wait for the receiver to process the
message and return before sending other messages to
other objects within the system

Message Arrows
• Return message is used
to indicate that the
message receiver is
done processing the
message and is
returning control over
to the message caller.
• Return messages are
optional

Participant creation message
• Objects do not necessarily live for
the entire duration of the
sequence of events. Objects or
participants can be created
according to the message that is
being sent.
• The dropped participant box
notation can be used when you
need to show that the particular
participant did not exist until the
create call was sent

Participant destruction message
• participants when no
longer needed can also
be deleted from a
sequence diagram.
• This is done by adding
an ‘X’ at the end of the
lifeline of the said
participant.

Reflexive message
• When an object sends a
message to itself, it is
called a reflexive
message.
• It is indicated with a
message arrow that
starts and ends at the
same lifeline as shown
in the example below.

Comment
• UML diagrams generally
permit the annotation of
comments in all UML
diagram types.
• The comment object is a
rectangle with a folded-over
corner as shown below.
• The comment can be linked
to the related object with a
dashed line.

How to Draw a Sequence Diagram
• use case diagram
example of ‘Create New
Online Library Account’,
• we will focus on the use
case named ‘Create
New Library User
Account’ to draw our
sequence diagram

Sequence Diagram – New Library user
account
• Identify the objects or actors
– Librarian
– Online Library Management system
– User credentials database
– Email system
• Write a detailed description on what the use case does.

Sequence Diagram – New Library
user account
• Here are the steps that occur in the use case
named ‘Create New Library User Account’.
– The librarian request the system to create a new online
library account
– The librarian then selects the library user account type
– The librarian enters the user’s details
– The user’s details are checked using the user Credentials
Database
– The new library user account is created
– A summary of the of the new account’s details are then
emailed to the user

Sequence Diagram – New Library
user account

Sequence Diagram : Timing
Slanted Lines show propagation delay of messages
Good for modeling real-time systems
If messages cross this is usually problematic – race conditions

Sequence Example: Alarm System
• When the alarm goes off, it rings the alarm, puts a
message on the display, notifies the monitoring
service

Sequence Diagram Example
Hotel Reservation

Collaboration Diagram
• Collaboration Diagrams show similar information to
sequence diagrams, except that the vertical
sequence is missing. In its place are:
– Object Links - solid lines between the objects that interact
– On the links are Messages - arrows with one or more
message name that show the direction and names of the
messages sent between objects
• Emphasis on static links as opposed to sequence in
the sequence diagram

Systems, Models and Views
System
View 1
Model 2
View 2
View 3
Model 1
Aircraft
Flightsimulator
Scale Model
Blueprints
Electrical
Wiring

UML Models, Views, Diagrams
• UML is a multi-diagrammatic language
– Each diagram is a view into a model
• Diagram presented from the aspect of a particular stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views
– Example views

How Many Views?
• Views should to fit the context
– Not all systems require all views
– Single processor: drop deployment view
– Single process: drop process view
– Very small program: drop implementation view
• A system might need additional views
– Data view, security view, …

UML: First Pass
• You can model 80% of most problems by using
about 20 % UML
• We only cover the 20% here

Basic Modeling Steps
• Use Cases
– Capture requirements
• Domain Model
– Capture process, key classes
• Design Model
– Capture details and behaviors of use cases and
domain objects
– Add classes that do the work and define the
architecture

UML Baseline
• Use Case Diagrams
• Class Diagrams
• Package Diagrams
• Interaction Diagrams
– Sequence
– Collaboration
• Activity Diagrams
• State Transition Diagrams
• Deployment Diagrams

Use Case Diagrams
• Used during requirements
elicitation to represent external
behavior
• Actors represent roles, that is, a
type of user of the system
• Use cases represent a sequence
of interaction for a type of
functionality; summary of
scenarios
• The use case model is the set of
all use cases. It is a complete
description of the functionality of
the system and its environment
Passenger
PurchaseTicket

Actors
• An actor models an external entity which
communicates with the system:
– User
– External system
– Physical environment
• An actor has a unique name and an
optional description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS
coordinates
Passenger

Use Case
A use case represents a class of
functionality provided by the system
as an event flow.
A use case consists of:
• Unique name
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements
PurchaseTicket

Use Case Diagram: Example
Name: Purchase ticket
Participating actor: Passenger
Entry condition:
• Passenger standing in front of
ticket distributor.
• Passenger has sufficient money
to purchase ticket.
Exit condition:
• Passenger has ticket.
Event flow:
1. Passenger selects the number of
zones to be traveled.
2. Distributor displays the amount
due.
3. Passenger inserts money, of at
least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.
Anything missing?
Exceptional cases!

The <<extends>> Relationship
• <<extends>> relationships represent
exceptional or seldom invoked cases.
• The exceptional event flows are
factored out of the main event flow
for clarity.
• Use cases representing exceptional
flows can extend more than one use
case.
• The direction of a <<extends>>
relationship is to the extended use
case
Passenger
PurchaseTicket
TimeOut
<<extends>>
NoChange
<<extends>>
OutOfOrder
<<extends>>
Cancel
<<extends>>

The <<includes>> Relationship
• <<includes>> relationship
represents behavior that is
factored out of the use case.
• <<includes>> behavior is factored
out for reuse, not because it is an
exception.
• The direction of a <<includes>>
relationship is to the using use
case (unlike <<extends>>
relationships).
Passenger
PurchaseSingleTicket
PurchaseMultiCard
NoChange
<<extends>>
Cancel
<<extends>>
<<includes>>
CollectMoney
<<includes>>

Use Cases are useful to…
• Determining requirements
– New use cases often generate new requirements as the
system is analyzed and the design takes shape.
• Communicating with clients
– Their notational simplicity makes use case diagrams a good
way for developers to communicate with clients.
• Generating test cases
– The collection of scenarios for a use case may suggest a
suite of test cases for those scenarios.

Use Case Diagrams: Summary
• Use case diagrams represent external
behavior
• Use case diagrams are useful as an index into
the use cases
• Use case descriptions provide meat of model,
not the use case diagrams.
• All use cases need to be described for the
model to be useful.

Class Diagrams
• Gives an overview of a system by showing its
classes and the relationships among them.
– Class diagrams are static
– they display what interacts but not what happens
when they do interact
• Also shows attributes and operations of each
class
• Good way to describe the overall architecture
of system components

Class Diagram Perspectives
• We draw Class Diagrams under three
perspectives
– Conceptual
• Software independent
• Language independent
– Specification
• Focus on the interfaces of the software
– Implementation
• Focus on the implementation of the software

Classes – Not Just for Code
• A class represent a concept
• A class encapsulates state (attributes) and behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory information.
zone2price
getZones()
getPrice()
TariffSchedule
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
TariffSchedule
Name
Attributes
Operations
Signature
TariffSchedule

Instances
• An instance represents a phenomenon.
• The name of an instance is underlined and can
contain the class of the instance.
• The attributes are represented with their values.
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}
tarif_1974:TariffSchedule

UML Class Notation
• A class is a rectangle divided into three parts
– Class name
– Class attributes (i.e. data members, variables)
– Class operations (i.e. methods)
• Modifiers
– Private: -
– Public: +
– Protected: #
– Static: Underlined (i.e. shared among all members of the class)
• Abstract class: Name in italics
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
Employee

UML Class Notation
• Lines or arrows between classes indicate relationships
– Association
• A relationship between instances of two classes, where one class must know
about the other to do its work, e.g. client communicates to server
• indicated by a straight line or arrow
– Aggregation
• An association where one class belongs to a collection, e.g. instructor part of
Faculty
• Indicated by an empty diamond on the side of the collection
– Composition
• Strong form of Aggregation
• Lifetime control; components cannot exist without the aggregate
• Indicated by a solid diamond on the side of the collection
– Inheritance
• An inheritance link indicating one class a superclass relationship, e.g. bird is
part of mammal
• Indicated by triangle pointing to superclass

Binary Association
myB.service(); myA.doSomething();
Binary Association: Both entities “Know About” each other
Optionally, may create an Associate Class

Unary Association
A knows about B, but B knows nothing about A
Arrow points in direction
of the dependency
myB.service();

Aggregation
Aggregation is an association with a “collection-member” relationship
void doSomething()
aModule.service();
Hollow diamond on
the Collection side
No sole ownership implied

Composition
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
-Name : string
+ID : long
#Salary : double
-adfaf : bool
Employee
-members : Employee
Team
1
*
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Filled diamond on
side of the Collection
members[0] =
new Employee();
…
delete members[0];

Inheritance
Standard concept of inheritance
class B() extends A
…
Base Class
Derived Class

UML Multiplicities
Multiplicities Meaning
0..1
zero or one instance. The notation n . . m
indicates n to m instances.
0..* or *
no limit on the number of instances
(including none).
1 exactly one instance
1..* at least one instance
Links on associations to specify more details about the relationship

Association Details
• Can assign names to the ends of the
association to give further information
+getName
() : string
+setName
()
-calcInternalStuff
(in x : byte, in y : decimal
)
-Name: string
+ID : long
#Salary: double
-adfaf: bool
Employee
-members: Employee
Team -group
1
-individual
*

Static vs. Dynamic Design
• Static design describes code structure and object
relations
– Class relations
– Objects at design time
– Doesn’t change
• Dynamic design shows communication between
objects
– Similarity to class relations
– Can follow sequences of events
– May change depending upon execution scenario
– Called Object Diagrams

Object Diagrams
• Shows instances of Class Diagrams and links
among them
– An object diagram is a snapshot of the objects in a
system
• At a point in time
• With a selected focus
– Interactions – Sequence diagram
– Message passing – Collaboration diagram
– Operation – Deployment diagram

Object Diagrams
• Format is
– Instance name : Class name
– Attributes and Values
– Example:

Objects and Links
Can add association type and also message type

Package Diagrams
• To organize complex class diagrams, you can group
classes into packages. A package is a collection of
logically related UML elements
• Notation
– Packages appear as rectangles with small tabs at the top.
– The package name is on the tab or inside the rectangle.
– The dotted arrows are dependencies. One package
depends on another if changes in the other could possibly
force changes in the first.
– Packages are the basic grouping construct with which you
may organize UML models to increase their readability

Package Example
DispatcherInterface
Notification IncidentManagement

Interaction Diagrams
• Interaction diagrams are dynamic -- they
describe how objects collaborate.
• A Sequence Diagram:
– Indicates what messages are sent and when
– Time progresses from top to bottom
– Objects involved are listed left to right
– Messages are sent left to right between objects in
sequence

Sequence Diagram Format
Actor from
Use Case Objects
1
2
3
4
Lifeline Calls = Solid Lines
Returns = Dashed Lines
Activation

Sequence Diagram : Destruction
Shows Destruction of b
(and Construction)

Activity Diagrams
• Fancy flowchart
– Displays the flow of activities involved in a single process
– States
• Describe what is being processed
• Indicated by boxes with rounded corners
– Swim lanes
• Indicates which object is responsible for what activity
– Branch
• Transition that branch
• Indicated by a diamond
– Fork
• Transition forking into parallel activities
• Indicated by solid bars
– Start and End

Sample Activity Diagram
• Ordering System
• May need multiple
diagrams from
other points of view

State Transition Diagrams
• Fancy version of a DFA
• Shows the possible states of the object and the
transitions that cause a change in state
– i.e. how incoming calls change the state
• Notation
– States are rounded rectangles
– Transitions are arrows from one state to another. Events or
conditions that trigger transitions are written beside the
arrows.
– Initial and Final States indicated by circles as in the Activity
Diagram
• Final state terminates the action; may have multiple final states

State Representation
• The set of properties and values describing the
object in a well defined instant are characterized by
– Name
– Activities (executed inside the state)
• Do/ activity
– Actions (executed at state entry or exit)
• Entry/ action
• Exit/ action
– Actions executed due to an event
• Event [Condition] / Action ^Send Event

State Transition Example
Validating PIN/SSN

State Charts – Local Variables
• State Diagrams can also store their own local
variables, do processing on them
• Library example counting books checked out
and returned
Is-Member
Start / N=0
Return /
N=N-1
Borrow /
N = N+1
Clean-Up
Stop / N=0

Component Diagrams
• Shows various components in a system and their
dependencies, interfaces
• Explains the structure of a system
• Usually a physical collection of classes
– Similar to a Package Diagram in that both are used to
group elements into logical structures
– With Component Diagrams all of the model elements are
private with a public interface whereas Package diagrams
only display public items.

Component Diagram Notation
• Components are shown as rectangles with
two tabs at the upper left
• Dashed arrows indicate dependencies
• Circle and solid line indicates an interface to
the component

Component Example - Interfaces
• Restaurant
ordering
system
• Define
interfaces
first –
comes
from Class
Diagrams

Component Example - Components
• Graphical depiction of components

Component Example - Linking
• Linking components with dependencies

Deployment Diagrams
• Shows the physical architecture of the hardware and
software of the deployed system
• Nodes
– Typically contain components or packages
– Usually some kind of computational unit; e.g. machine or
device (physical or logical)
• Physical relationships among software and hardware
in a delivered systems
– Explains how a system interacts with the external
environment

Deployment Example
Often the Component Diagram is combined with the Deployment

Summary and Tools
• UML is a modeling language that can be used independent of
development
• Adopted by OMG and notation of choice for visual modeling
– http://www.omg.org/uml/
• Creating and modifying UML diagrams can be labor and time
intensive.
• Lots of tools exist to help
– Tools help keep diagrams, code in sync
– Repository for a complete software development project
– Examples here created with TogetherSoft ControlCenter, Microsoft
Visio, Tablet UML
– Other tools:
• Rational, Cetus, Embarcadero
• See http://plg.uwaterloo.ca/~migod/uml.html for a list of tools, some
free

UML.pdf

More Related Content

Similar to UML.pdf (20)

Recently uploaded (20)

UML.pdf