Introduction to UML
Prepared By:
Prof. U. Verma
MPSTME Shirpur Campus
upendra.verma@nmims.edu
psg/1
What is UML?
Modeling involves
understanding ( semantics) a subject (system)
and
capturing and communicating this knowledge
The Unified Modeling Language ( UML) is:
A complete language for capturing knowledge (semantics) about a subject
(system) and communicating the knowledge (syntax)
the result of unifying the IT industrys best engineering practices
proposed by Booch, Rumbaugh and Jacobson-the Three Amigos
upendra.verma@nmims.edu
psg/2
..What is UML?
UML is the standard language for visualizing, specifying,
constructing, and documenting the artifacts of a software
intensive system
It can be used with all processes, throughout the development
life cycle, and across different implementation technologies
upendra.verma@nmims.edu
psg/3
..What is UML?
Visualizing UML is more than just a bunch of graphical
symbols. For each symbol in the UML notation is a well defined
semantics.
Specifying Building models that are precise, unambiguous,
and complete.
Constructing models can be directly connected to a variety of
programming language. It is possible to map model in the UML
to a programming language like JAVA, C++, or VB.
Documenting UML addresses the documentation of a
systems architecture and all of its details, provides language for
expressing requirements, for test, for modeling the activities of
project planning and release management.
upendra.verma@nmims.edu
psg/4
Evolution of the UML
Unification
James Rumbaugh, Grady Booch and Ivar Jacobson joined Rational
Software Corporation to unify their methods.
Rumbaugh - Analysis oriented (OMT)
Booch - Design and Construction oriented
Jacobson - Use case oriented (OOSE)
Since the independent methods were evolving towards one
another, continue evolution by unification.
Identify and incorporate fundamental concepts, building a meta
model and a notation to describe them.
upendra.verma@nmims.edu
psg/5
Standardization
More companies joined the UML partners consortium to
contribute their ideas and produce version 1.1 of the UML with
Increased formalism
Improved structural packaging
Improved mapping of notation to semantics
UML 1.1 is accepted by OMG as a standard in fall 1997.
upendra.verma@nmims.edu
psg/6
The UML Scope
Fusing concepts of Booch, OMT and OOSE.
Focusing on a standard modeling language (common notation
and semantics)
Incorporating the object-oriented communitys consensus on
core modeling concepts.
Providing sufficient notation to address contemporary modeling
issues directly and economically.
Providing extensibility mechanisms to extend UML for individual
projects.
upendra.verma@nmims.edu
psg/7
The UML enables and promotes a use-case-driven, architecturecentric, iterative, and incremental process that is object oriented
and component based.
upendra.verma@nmims.edu
psg/8
The UML Definition
Defined by a set of documents
UML Semantics
UML Notation Guide
upendra.verma@nmims.edu
psg/9
The UML Semantics Document
Constitutes the single, common, formal and comprehensive
specification of the UML (inside view).
Primarily used by tool vendors.
Specifies the UMLs layered architecture, organization and
defines modeling elements.
Enables consistent usage of the UML.
upendra.verma@nmims.edu
psg/10
The UML Notation Guide
Constitutes the notational or visual representation of the UML
and provides examples (outside view)
Primarily used by practitioners applying the UML
Specifies UML diagrams and their modeling elements
upendra.verma@nmims.edu
psg/11
A Conceptual Model of UML
To understand UML You need to form a conceptual model of the language.
This requires learning three major elements.
The UMLs basic building blocks
The rules that dictate how those building blocks may be
put together
Some common mechanism that apply throughout the UML
upendra.verma@nmims.edu
psg/12
Basic Building Blocks of UML
Three kinds of building blocks Things
Relationships
Diagrams
upendra.verma@nmims.edu
psg/13
Basic Building Blocks of UML - Things
Things
The abstractions that are first-class citizens in a model.
There are four kinds of things in the UML
1.
2.
3.
4.
Structural
Behavioral
Grouping
Annotational
upendra.verma@nmims.edu
psg/14
Basic Building Blocks of UML Things Structural
Structural
These are nouns of UML models which are static parts
represent elements that are either conceptual or physical.
There are seven kinds of structural things in the UML
1.
2.
3.
4.
5.
6.
7.
class
interface
collaboration
Use case
Active class
Component
node
upendra.verma@nmims.edu
psg/15
Basic Building Blocks of UML Things
Structural Class, Interface
Class
Description of as set of objects that share same attributes,
operations, relationships, and semantics.
Graphically, a class is rendered as a rectangle.
interface
A collection of operation that specify a service of a class or
component.
Describes externally visible behavior of a class or
component or only a part of that behavior.
Defines set of operation specifications
Graphically, an interface is rendered as a circle.
upendra.verma@nmims.edu
psg/16
Basic Building Blocks of UML Things
Structural Collaboration
Collaboration
Defines an interaction and is a society of classes, interfaces
and other elements work together to provide some
cooperative behavior.
A given class might participate in several collaborations
Represents the implementation of patterns that make up a
system
Graphically, a collaboration is rendered as an ellipse with
dashed line, usually including only its name.
upendra.verma@nmims.edu
psg/17
Basic Building Blocks of UML Things
Structural Use case
Use case
It is a description of set of sequence of actions that a
system performs that yields an observable result of value to
a particular actor.
It is used to structure the behavioral things in a model.
It is realized by a collaboration.
Graphically, a use case is rendered as an ellipse with solid
line, usually including only its name.
upendra.verma@nmims.edu
psg/18
Basic Building Blocks of UML Things
Structural Active class, Component
Active Class
The objects of active class own one or more processes or
threads so initiate control activity.
Graphically, an active class is rendered as a rectangle with
heavy lines.
Component
It is a physical and replaceable part of a system that
conforms to and provides the realization of a set of
interface.
Graphically, a component is rendered as a rectangle with
tabs, usually including only its name.
upendra.verma@nmims.edu
psg/19
Basic Building Blocks of UML Things
Structural Node
Node
It is a physical element that exists at run time.
It represents a computational resource.
It has some memory and often processing capabilities.
Graphically, a node is rendered as a cube, usually including
only its name.
upendra.verma@nmims.edu
psg/20
Basic Building Blocks of UML Things
Behavioral
Behavioral
These are dynamic parts of UML model.
These are verbs of a model.
Represents behavior over time and space.
There are two primary kinds of behavioral things
1. Interaction
2. State machine
upendra.verma@nmims.edu
psg/21
Basic Building Blocks of UML Things
Behavioral - Interaction
Interaction
It comprises a set of messages exchanged among set of
objects within a particular context to accomplish a specific
purpose.
It includes messages, action sequences, and links.
Graphically, a message is rendered as a directed line,
usually including name of its operation.
upendra.verma@nmims.edu
psg/22
Basic Building Blocks of UML Things
Behavioral State Machine
State Machine
It is a behavior that specifies the sequence of state an
object or an interaction goes through during its lifetime in
response to events, together with its responses to those
events.
It includes events and activities.
Graphically, a state is rendered as a rounded rectangle,
usually including its name and its substates.
upendra.verma@nmims.edu
psg/23
Basic Building Blocks of UML Things
Grouping
Grouping
These are the organizational parts of UML model.
There is one primary kind of grouping thing, namely,
packages.
Package
It is a general purpose mechanism for organizing element
into groups.
Structural, behavioral and grouping things may be placed in
a package.
Graphically, a package is rendered as a tabbed folder,
usually including only its name and sometimes its contents.
upendra.verma@nmims.edu
psg/24
Basic Building Blocks of UML Things
Annotational
Annotational
These are the explanatory parts of UML model.
These are the comments.
There is one primary kind of annotational thing, called a
note.
Note
Its a symbol for rendering constraints and comments
attached to an element or a collection of elements.
Graphically, a note is rendered as a rectangle with a dogeared corner, together with a textual or graphical comment.
upendra.verma@nmims.edu
psg/25
Basic Building Blocks of UML
Relationships
Relationships
It tie things together.
There are four kinds of relationships in the UML.
1.
2.
3.
4.
Dependency
Association
Generalization
realization
upendra.verma@nmims.edu
psg/26
Basic Building Blocks of UML
Relationships - Dependency
Dependency
It is a semantic relationship between two things in which a
change to one thing may affect the semantics of the other
things.
Graphically, a dependency is rendered as a dashed line,
possibly directed, and occasionally including a label.
upendra.verma@nmims.edu
psg/27
Basic Building Blocks of UML
Relationships - Association
Association
It is a structural relationship that describes a set of links, a
link being a connection among objects.
Aggregation is a special kind of association representing a
structural relationship between a whole and its parts.
Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label, and often
containing multiplicity and role names.
upendra.verma@nmims.edu
psg/28
Association
1
Guides
Teacher
Student
Aggregation
1
Institute
Department
upendra.verma@nmims.edu
psg/29
An association is a bi-directional connection between classes
An association is shown as a line connecting the related classes
An aggregation is a stronger form of relationship where the relationship is
between a whole and its parts
An aggregation is shown as a line connecting the related classes with a
diamond next to the class representing the whole
A dependency relationship is a weaker form of relationship showing a
relationship between a client and a supplier where the client does not have
semantic knowledge of the supplier
A dependency is shown as a dashed line pointing from the client to the
supplier
upendra.verma@nmims.edu
psg/30
Relationships - contd..
An association class is an association that also has class properties(or a
class has association properties)
A constraint is a semantic relationship among model elements that
specifies conditions and propositions that must be maintained as true:
otherwise, the system described by the model is invalid
An interface is a specifier for the externally visible operations of a class
without specification of internal structure. An interface is formally
equivalent to abstract class with no attributes and methods, only abstract
operations.
A qualifier is an attribute or set of attributes whose values serve to
partition the set of instances associated with an instance across an
association.
upendra.verma@nmims.edu
psg/31
Association
1
Guides
Teacher
Student
Guide
RS
Navigation
Aggregation
1
Institute
Department
upendra.verma@nmims.edu
psg/32
Association Vs Composition
1
Page
Frame
Window
Menu
Header
upendra.verma@nmims.edu
Slider
psg/33
Dependency
uses
Window
Button
access
Employee
Salary
upendra.verma@nmims.edu
psg/34
Association Classes
1
Teaches
Teacher
Course
Offering
No of students
Venue
Slot number
1
employs
Company
*
Employee
Job
Designation
Salary
upendra.verma@nmims.edu
psg/35
Realization
<interface>
Iaccount
AccountImpl
Deposit()
withdraw()
upendra.verma@nmims.edu
psg/36
Basic Building Blocks of UML
Relationships - Generalization
Generalization
It is a specialization/generalization relationship in which
objects of the specialized elements are substitutable for
objects of the generalized element.
The child share the structure and the behavior of the parent.
Graphically, a generalization is rendered as a solid line with
a hollow arrowhead pointing to the parent.
upendra.verma@nmims.edu
psg/37
Generalization/Specialization
Superclass, Subclass, or Inheritance comes into picture in
generalization/Specialization.
upendra.verma@nmims.edu
psg/38
Generalization/Specialization..Continued
Bees and grasshoppers are specialized versions of an insect
upendra.verma@nmims.edu
psg/39
Basic Building Blocks of UML
Relationships - Realization
Realization
It is a semantic relationship between classifier, wherein one
classifier specifies a contract that another classifier
guarantees to carry out.
Realization encounter in two places
Between interfaces and the classes or components that
realize them
Between use cases and the collaborations that realize them.
upendra.verma@nmims.edu
psg/40
Realization
<interface>
Iaccount
AccountImpl
Deposit()
withdraw()
upendra.verma@nmims.edu
psg/41
Basic Building Blocks of UML Diagrams
Diagrams
It is the graphical presentation of a set of elements, most
often rendered as a connected graph of vertices (things)
and arcs (relationships).
UML includes nine different diagrams.
upendra.verma@nmims.edu
psg/42
UML Diagrams
Use Case diagram
For High level business scenarios
Sequence diagram or Collaboration diagram
For detailed activities within a scenario
Class diagram
For a view of the static structure of the system
State chart diagram and Activity Diagram
For classes with a dynamic behavior
Component diagrams
For describing organization and dependencies among software components
Deployment diagrams
For describing the configuration of resource elements and mapping of software
implementation components on to them
Package diagram
For Modules
upendra.verma@nmims.edu
psg/43
Model Views and UML
Diagrams
Structural View
Class
Object
Behavioral View
Sequence
Collaboration
State Chart
Activity
Implementation View
Component
User view
User
View
* Use
case
Use
Case
Environment View
Deployment
upendra.verma@nmims.edu
psg/44
Library Management System- A Case Study
The Library has:
three categories of members
a librarian and assisting staff
an accounts section
The Library Management System should provide the
following functionality:
borrowing and returning of books
querying, reserving and recommending books
acquiring books
issuing overdue notices to members
upendra.verma@nmims.edu
psg/45
Use Case Diagram
Represent the interaction between users
and the system
Identifies users (roles) and external systems
Determines the functional scope of the
package (module)
upendra.verma@nmims.edu
psg/46
Use Case Diagram Notation
Actor
Association
Use Case
Use case with Extension points
<<Uses>>
<<Extends>>
upendra.verma@nmims.edu
psg/47
Use Case Diagram
upendra.verma@nmims.edu
psg/48
Use case diagram for RMS
upendra.verma@nmims.edu
49
Interaction Diagram
Interaction diagrams describe how use cases are
realized as interactions among objects
Show classes, objects, actors and messages
between them to achieve the functionality of a
UseCase
Two types of interaction diagrams
Sequence diagrams
Collaboration diagrams
upendra.verma@nmims.edu
psg/50
..Sequence Diagram
Is used to elaborate a use case
Describes a scenario - it is normal that a use
case has multiple scenarios
Helps to describe the expected system
behavior to a user
Follows an event from inception to
completion of processing by the system
upendra.verma@nmims.edu
psg/51
Sequence Diagram Notation
Actor
Class
Synchronous message
Asynchronous message
Focus of Control
Return message
Termination
lifeline
upendra.verma@nmims.edu
psg/52
Sequence Diagram
Library
member
UI
Member
upendra.verma@nmims.edu
Book
Copy
psg/53
..Collaboration Diagram
describes interactions among Classes (
objects)
can be drawn instead of a sequence diagram
Message sequencing is shown using
sequence numbers
upendra.verma@nmims.edu
psg/54
Collaboration Diagram Notation
Class
Messages with
sequence
numbers
( Collaborates
with Class)
Actor
upendra.verma@nmims.edu
psg/55
Collaboration Diagram
upendra.verma@nmims.edu
psg/56
..Class Diagram
Shows the static structure of the system classes and their relationships
Classes
structure (attributes)
behavior (operations)
Relationships
Association, aggregation, dependency, and
inheritance
Multiplicity and navigation indicators
names
upendra.verma@nmims.edu
psg/57
Class Diagram Notation
1 Class with a compartment
2 Nary Association
4
3 Class
4 Binary Association
5 Constraint
6 Realizes Interface
7 Interface
upendra.verma@nmims.edu
psg/58
Class Diagram
Accountant
1
Book
no
hasBooks
1
Library
1
Visibility
Attribute
Title
Author
Publisher
Subject
Key words
edition
Price
orders
InitVal
* Ty peScope
a
a
a
a
a
a
a
hasLibrarian
OrderInf o
hasCopies
hasMembers
Visibility
Attribute
supplierId
NoOfCopies
*
1
CopyInLib
Librarian
Visibility
Attribute
isRef erence
accessionNo
isIssued
copyNo
Ty peScope
InitVal
a
a
a
a
0..5
Library Member
0..200
Visibility
Attribute
name
memberId
borrows
Ty peScope
InitVal
a
a
upendra.verma@nmims.edu
psg/59
Relationships
An association is a bi-directional connection between classes
An association is shown as a line connecting the related classes
An aggregation is a stronger form of relationship where the relationship is
between a whole and its parts
An aggregation is shown as a line connecting the related classes with a
diamond next to the class representing the whole
A dependency relationship is a weaker form of relationship showing a
relationship between a client and a supplier where the client does not have
semantic knowledge of the supplier
A dependency is shown as a dashed line pointing from the client to the
supplier
upendra.verma@nmims.edu
psg/60
Relationships - contd..
An association class is an association that also has class
properties(or a class has association properties)
A constraint is a semantic relationship among model elements
that specifies conditions and propositions that must be
maintained as true: otherwise, the system described by the model
is invalid
An interface is a specifier for the externally visible operations of
a class without specification of internal structure. An interface is
formally equivalent to abstract class with no attributes and
methods, only abstract operations.
A qualifier is an attribute or set of attributes whose values serve
to partition the set of instances associated with an instance across
an association.
upendra.verma@nmims.edu
psg/61
Association
1
Guides
Teacher
Student
Guide
RS
Navigation
Aggregation
1
Institute
Department
upendra.verma@nmims.edu
psg/62
Association Vs Composition
1
Page
Frame
Window
Menu
Header
upendra.verma@nmims.edu
Slider
psg/63
Dependency
uses
Window
Button
access
Employee
Salary
upendra.verma@nmims.edu
psg/64
Association Classes
1
Teaches
Teacher
Course
Offering
No of students
Venue
Slot number
1
employs
Company
*
Employee
Job
Designation
Salary
upendra.verma@nmims.edu
psg/65
Realization
<interface>
Iaccount
AccountImpl
Deposit()
withdraw()
upendra.verma@nmims.edu
psg/66
Qualifier
Bank
Factory
Account #
Item #
Customer
Itemproduced
upendra.verma@nmims.edu
psg/67
..State Chart Diagram
A state chart (transition) diagram is used to
show
The life history of a given class, UseCase,
operation
The events that cause a transition from one state to
another
The actions that result from a state change
State transition diagrams are created for objects
with significant dynamic behavior
upendra.verma@nmims.edu
psg/68
State Chart Diagram Notation
upendra.verma@nmims.edu
psg/69
State Chart Diagram
upendra.verma@nmims.edu
psg/70
..Activity Diagram
Activity diagrams are similar to State Chart
diagrams.
However they describe the behavior of a Class in
response to internal processing.
Transitions are triggered by completion of
activity
For describing behavior of Use Cases or
operations
upendra.verma@nmims.edu
psg/71
Activity Diagram Notation
upendra.verma@nmims.edu
psg/72
Activity Diagram
upendra.verma@nmims.edu
psg/73
..Component Diagram
Describe organization and dependency
between the software implementation
components
Components are distributable physical units
-e.g. source code, object code.
upendra.verma@nmims.edu
psg/74
Component Diagram Notation
Component
Dependency
upendra.verma@nmims.edu
psg/75
Component Diagram
upendra.verma@nmims.edu
psg/76
..Deployment Diagram
Describe the configuration of processing
resource elements and the mapping of
software implementation components onto
them
contain components - e.g. object code, source
code, and nodes - e.g. printer, database, client
machine
upendra.verma@nmims.edu
psg/77
Deployment Diagram Notation
Component
Interface
Dependency
Node
Connector
upendra.verma@nmims.edu
psg/78
Deployment Diagram
LibServ er
LibMgmtSys
tcp-ip
tcp-ip
LibClient2
LibClient1
ClientLibrarian
ClientMember
upendra.verma@nmims.edu
psg/79
Package Diagram
A Package is :
an application view
exploded into a set of modules
linked to the diagrams that model that
application view
upendra.verma@nmims.edu
psg/80
Package Diagram Notation
Container package
Package
Dependency
Generalization
upendra.verma@nmims.edu
psg/81
Package Diagram
upendra.verma@nmims.edu
psg/82
upendra.verma@nmims.edu
psg/83
Modeling Process
Break up the system into packages. Draw a
high level Package Diagram for the system.
Draw Use Case diagrams for each package
Analyze each use case in detail - identifying
variations, common use cases, scenarios of
interest
Draw a Sequence /Collaboration diagram
for each scenario
upendra.verma@nmims.edu
psg/84
.. Modeling Process
Draw a Class Diagram for each package
classes will be shared across the entire
application model
a class will be owned by a package - others
will use it
Refine the inheritance hierarchy (this will
be across the application)
Identify attributes and keys for the classes
upendra.verma@nmims.edu
psg/85
..Modeling Process
Draw
State Chart Diagrams or Activity Diagrams for
classes that exhibit a significantly dynamic
behavior
Component Diagrams to elucidate the
intercomponent dependencies
Deployment Diagrams to describe the
configuration of resource elements and mapping of
the software implementation components onto
them
upendra.verma@nmims.edu
psg/86
