Object Technology & UML

Introduction to UML

Mr. Harinandan Tunga

Sr. Lecturer, Dept. of CSE,RCCIIT
E-Mail: harinandan.tunga@gmail.com
Mob: 9339877213
UML stands for Unified Modeling Language.
Aspects of the UML
Each of these words speaks to an important
aspect of the Unified Modeling Language
Unified because it …
– Combines main preceding OO methods
Modelling because it is …
– Primarily used for visually modelling systems.
Many system views are supported by
appropriate models
Language because …
– It offers a syntax through which to express
modelled knowledge
• UML is the international standard notation for object-
oriented analysis and design.
defined by the Object Management Group (OMG).

of UML
m unified refers to the fact that the Object
ent Group (OMG), an industry-recognized
dization organization and Rational software
tion created the UML to bring together the information
tion systems and technology industry’s best
ring practices. Booch by Grady Booch, OMT by Jim
Rumbaugh and OOSE by Ivar Jacobson
baugh, Ivar Jacobson and Grady Booch decided at
at the end of 1994 to unify their work within a single
method – “The unified method”.
Definition of UML:
A visual language for modeling and communicating
about systems through the use of diagrams and
supporting text this is known as Unified Modeling
Language.

• The UML is a third-generation method for specifying,

visualizing and documenting the artifacts of an object-
oriented system under development.

• The UML is represents the unification of the Booch,

objectory and OMT (Object Modeling Technique)
methods and is their direct and upwardly compatible
successor.
OMT Methodology:
OMT methodology is a methodology of software engineering to
develop the software using the steps of software development
life cycle.
Advantages of Modeling:
• Testing a physical entity before building original system.
• Communication with customers to show and understand.
• Visualization to show the idea of designer.
• Reduction of complexity
Why UML Modeling? UML is a Modeling language because
• Support the understanding of the model.
• Allow easy navigation through the model.
• Express (Visualize) specific syntactical properties of the model.
• All model components are used consistently.
• A model is free of redundancies.
• Support simple application of changes.
Three categories of UML modeling.
They are
– Functional Models
Describes the functionality of the system from the
user’s point of view. For example, Use Case
diagrams.
– Static Models
Describes the structure and substructure of the
system using objects, attributes, operations, and
associations. For example, Class diagrams and
Object diagrams.
– Dynamic Models
Describe the internal behavior of the system. For
example, Sequence diagrams, Collaboration
diagrams, Activity diagrams and State diagrams.
The primary goals in the design of the UML
• Ready to use and Expressive: Provide users with a ready-
to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
• Extensibility and Specialization: Provide extensibility and
specialization mechanisms to extend the core concepts.
• Implementation-independent: An implementation-
independent language may be used independently of any
specific implementation technologies, such as JAVA or .NET
• Process-independent: A process-independent language
may be used with various types of processes.
• Modeling language: Provide a formal basis for
understanding the modeling language.
• Development concepts: Support higher-level development
concepts such as collaborations, frameworks, patterns
and components.
• Best practices : Integrate best practices.
OBJECT MODEL
• Object-oriented modeling languages are based on
an abstract object model, which views a running
system as being a dynamic network of interacting
objects. This model also provides an abstract
interpretation of the run-time properties of object-
oriented programs.
• Object is a single thing or concept, either in a model of
an application domain or in a software system, that
can be represented as an encapsulation of state,
behaviour and identity and a member of a class that
defines a set of similar objects.
• Every object has following three characteristics –
a state, a behavior, and an identity
Object = State + Behavior + Identity.
LINKS
• Links are the means for building the relationships
among the objects. These objects or instance may be
same or different in data structure and behaviour.

• A link is a physical or conceptual connection between

instances or objects i.e. Links are relationships among
the objects

• The links always exist the relationships between two

or more objects

• The OMT notation for a link is a line between the

objects
For example, Gopa works-for TCS company. In this example
‘works-for’ is the link between “Gopa” and “TCS company”

Gopa works-for TCS

(Person) (Company)

OR Gopa is employee of TCS company. In this example

‘employee’ is the link between “Gopa” and “TCS
company”.
Gopa
1 employee 1 TCS
(Person) (Company)
one-to-one links
• Link Relationship is an association among two or more
objects. Relationships can have different connectivity
• one-to-one (1:1)
• one-to-many (1:N)
• many-to- One (M:1)
• many-to-many (M:N)
For examples,
• one-to-many (1:N) Kolkata
(City)
India
(Country)
Metro City Mumbai
(City)

Chennai
(City)

• many-to- One (M:1)

Rahul
(Person)

Prosun works-for CTS

(Person) (Company)
Partha
(Person)
• many-to-many (M:N)

Debnath Team Member HR-System

(Employee) (Project)

Arpita
(Employee)

Arijit Team Member A/C-System

(Employee) (Project)

Figure Show the relationships between many objects to many

objects this type of links called many-to-many links.
ASSOCIATION
• An association is a logical connection, usually
between different classes although in some
circumstances a class can have an association with
itself.

• An association is the relationship among classes

• The object modeling describes as a group of links with

common structure and common semantics. All the
links among the object are the forms of association
among the same classes
For example, Gopa works-for TCS company, Here
Nandana is an object of Person class and TCS
company is the object of Company class and the
relationship called links.
Nandana Work-for TCS
(Person) (Company)

Whereas ‘Person works-for Company in this example

Person and Company both are classes, thus the
relationship between them is called association.
works-for
Person Company

(Association)
• Associations are descriptions of links or a set of links
with a common implementation.
• Associations –
• Are classes that relate other classes.
• Are to links as classes are to objects.
• Define an implementation for their links.
• Association can have the following –
• Name: Identifies the association type.
• Multiplicity: Indicates that how many objects can
participate in the association.
• Role: Meaning of the classes involved.
• Associations have a multiplicity attribute. The
multiplicity denotes the cardinality of the
association. The multiplicity of an association
end is the number of possible instances of the
class associated with a single instance of the
other end. Multiplicities are single numbers or
ranges of numbers.

Most common Multiplicities:

• 0..1 Æ Zero or one instance.
• 0..* or * Æ No limit on the number of instances.
• 1 Æ Exactly one.
• 1..* Æ At least one instance.
Degree of Association:
The degree of association defines the number of classes
connected by association. The most common and
frequent association are based on the degree:
• Unary association or Reflexive: managed by
0…1

Employee
0..n manager of

• Binary Association: The association which contain

the degree of two classes is called binary association
Person *..1 *..1 Company

works-for
• Ternary Association: The association which contain
the degree of three classes is called binary
association

• Quaternary Association: The association which

contain the degree of four classes is called binary
association
AGGREGATIONS
• Association can be two types
(i) Aggregation (ii) Composition
• The aggregation is an extension of association mean
aggregation is a strong form of association in which an
aggregate object is made of components.
Components are part of the aggregate i.e. aggregation
is the ‘part-whole’ or ‘a-part-of’ relationship. For
example, keyboard is a part of computer.
• Aggregation has three formal properties –
The first property is antisymmetry, which simply means that
a link which is an instance of an aggregation cannot be used
to link an object to itself that if X is a part of Y, Y is not a part
of X.
• The second property is transitivity, which is based on the
observation that if X is a part of Y and Y is a part of Z then X is
also a part of Z. More formally, if object X is linked to Y and Y to
Z by links that are instances of the same aggregation, then X
should also be thought of as linked to Z.
• The third property is Propagation. The environment of the part
is the same as that of the assembly
Definition:
Aggregation is the “part-whole” or “a-part-of” relationship
among classes.

Garden Plant Flower

0..* 0…*

Figure Shows a class diagram with aggregation, diamond

indicates the assembly end of the relationship. It shows the
plant is the part of garden and flower is part of plant.
Class diagram showing Aggregation between two
classes

• Aggregation may have number of levels.

Aggregation types:
• Fixed aggregation
• Variable aggregation
• Recursive aggregation
• Fixed aggregation: A fixed aggregation has the
particular numbers and types of the component parts
are pre-defined.
• Variable aggregation: The number of levels of
aggregation is fixed, but the number of parts may vary.
• Recursive aggregation: The object contains
components of its own type.
COMPOSITIONS
Composition is a strong form of aggregation with a
lifetime dependency between each part and the whole.
No part can belong to more than one composition at a
time and if the composite whole is deleted its parts are
deleted with it.
• Composition is a strong association in which the
part can belong to only one whole – the part
cannot exist without the whole.
• It is indicated by a line with strong diamond at the
end.
Differences between Composition and Aggregation
• The whole of a composition must have a multiplicity of
0..1 or 1, indicating that a part must be for only one
whole. The whole of an aggregation may have any
multiplicity.
• When attempting to represent real-world whole-part
relationships, e.g., an engine is part of a car, the
composition relationship is most appropriate.
However, when representing a software or database
relationship, e.g., car model engine ENG01 is part of a
car model CM01, an aggregation relationship is best,
as the engine, ENG01 may be also part of a different
car model. Thus the aggregation relationship is often
called "catalog" containment to distinguish it from
composition's "physical" containment.
Association vs aggregation
Both concepts provide the relationship among the
classes. Aggregation is not an independent concept, it
is a special form of association. Aggregation is the
“part-whole” or “a part of” relationship among the
classes.
Aggregation exists after the existing of association.
Thus we can say aggregation is a strong form of
association in which an aggregation object is made of
components. Components are part of the aggregate.
Aggregation is a tightly coupled form of association
with some extra semantics.
associations are bidirectional whereas aggregations
are anti-symmetric.
COUPLING AND COHESION
• Coupling:
Coupling is relates to the degree of
interconnectedness between design components
and is reflected by the number of links and degree of
interaction an object has with other objects.
Coupling is a measure of the strength of the
connections between parts.
• Cohesion: Cohesion is a measure of how parts of a
whole are logically related to each other and the
overall whole.
Higher cohesion indicates that changes will more
likely be localized. This is maximized by the use of
modularity.
TYPES
• Types are descriptions of objects or a set of objects with a
common specification or interface.
Types
• Are concerned with the specification of uniform structural
characteristics and behavioral characteristics.
• Encapsulate structural characteristics called attributes. They
are specified by the type and may be object attributes or class
attributes.
• Encapsulate behavioral characteristics called operations. They
are specified by the type and may be object operations or
class operations, etc.
NOTE
• Notes are graphical constructs or notational items containing
and rendering textual information.Note attached to a
Diagram<<Stereotype>>
Notes
• Are denoted as rectangles with a bent upper right corner.
• Are used to render comments, constraints, properties, method
bodies, and so forth.
METACLASS AND METAMODEL
Meta class:
A class whose instances are classes, it contains data
and operations that are specific to a class rather than
its instances. Meta types are types whose instance
are types.

Meta model:
A model that describes model elements and meta
modeling is the recursive modeling of model elements
from themselves.
OBJECT CONSTRAINT LANGUAGE (OCL)

• Object Constraint Language (OCL) is a formal

language that supplements the graphical notions of
UML. OCL is generally used to give precise definitions
for operation logic or for properties such as invariants.

• OCL expressions are construct from a collection of

pre-defined elements and types and the language has
a precise grammar that enables the construction of
unambiguous statements about the properties of
model components and their relationships to each
other. Most OCL statements consist of the following
structural elements –
• A context that defines a domain within which the
expression in valid. This is often an instance of a
specific type, for example an object in a class
diagram. A link may also be the context for an OCL
expression.

• A property of that instance which is the context for the

expression. Properties may include attributes,
association-ends and query operations.

• An OCL operation that is applied to the property.

Operations include (but are not restricted to) the
arithmetical operators *, +, - and /, set operators such
as size, isEmpty and select and type operators such
as oclIsTypeOf.
GENERALIZATION
• Generalization is the abstraction of common features
among elements (for example, classes) by the
creation of a hierarchy of more general elements (for
example, super classes) that encapsulate the common
features.
• Generalization defines a relationship between
classes where any instance of one class, the
subclass, can be substituted for, or treated as if it was,
an instance of another class, the super class.
• A given class can have any number of mutually
exclusive subclasses. This process can be carried out
as often as required, giving rise to generalization
hierarchies.
• Generalization is a processor of defining a superclass
from a given set of simantically related entity set.
• The notation for generalization is a triangle connecting
a superclass to its subclassses.
• Class diagram showing generalization between one
superclass and two subclasses

Generalization can only be shown on class diagrams

and on Use case diagrams.
SPECIALIZATION
Specialization is the other face of generalization; an
element (for example, a class) is said to be
specialized when it has a set of characteristics that
uniquely distinguish it from other elements.
Distinguishes subclasses from their super class.
Generalization vs. Specialization
Generalization and specialization are two different
viewpoints of the same relationship. Viewed from
super-class to subclasses is called specialization and
viewed from subclasses to super-class is called
generation.
In the process of Generalization we create a
superclass from a given set of semantically related
subclasses whereas in the process of Specialization
we refine the superclass into the specialization
subclasses i.e. we create subclasses from a single
superclass.
The generalization an specialization both are opposite
to each other. Generalization uses bottom up
approach, while specialization uses top-down
approach.
 Human
Top to Bottom
Down to Up

Male Female

Specialization Generalization
When we create a superclass ‘Human’ using two
subclasses ‘Male’ and ‘Female’ this process is called
Generalization whereas When we create two
subclasses ‘Male’ and ‘Female’ using a single
superclass ‘Human’ this is called specialization.
Aggregation vs. Generalization
Aggregation and Generalization both are different
concepts. Aggregation provides the relationship
between objects and classes, while Generalization is a
process to combine the common behaviour and
attributes in a single class or more classes.

Aggregation relates instances, in which tow distinct

objects are involved, where one of them is a part of
the other. Generalization relates classes and is a way
of structuring the description of a single object. Both
super and subclasses refer to properties of a single
object. In generalization, an object is simultaneously
an instance of the superclass and an instance of the
subclass.
 Aggregation is often called “a-part-of” relationship,
while generalization is often called “a-kind-of” or is-a”
relationship. Human

Male Female Legs Hands Head Body

Generalization Aggregation
When we create a super-class ‘Human’ using two
subclasses ‘Male’ and ‘Female’ this process is called
Generalization whereas Legs, Hands, Head and Body
are parts of Human class that show example of
aggregation
Generalization vs. Inheritance
Generalization is the relationship between a class and
one or more refined versions of it. The class being
refined is called the superclass and each refined
version is called subclasses. Attributes and operations
common to a group of subclasses are attached to the
superclass and changed by each subclass. Each
subclass is said to inherit the features of its
superclass.
Generalization and inheritance are transitive across an
arbitrary number of levels.
Actually we use Generalization to refer to the
relationship among classes, while inheritance refers to
the mechanism of sharing attributes and operations
using the Generalization relationship.
ARCHITECTURAL VIEWS AND MODEL VIEWS
Architectural views:
Architectural views are abstractions of models.

Knowledge

Model
(Architectu
re)
Architectura Diagrams
l views (Views)
Model
Elements
Model views:

Structural View Implementation View

Use-case

Behavioral View Environment View

Architectural views
• Are perspectives through which models may be
represented or projected as diagrams.
• Organize perspectives or views of models around
specific sets of concerns particular to different
stakeholders involved in the problem-solving effort. A
set of concerns establishes an architectural focus.
• Enable the extraction of architecturally significant
elements of a model via different viewpoints or
perspectives.
• Include the following model views regarding models
of problems and solutions –
The user model view encompasses a problem and
solution from the perspective of those individuals whose
problem the solution addresses. This view presents the
goals and objectives of the problem owners and their
requirements of the solution.
 • The use case diagrams depict the functionality of a system.
The structural model view encompasses the static
or structural, aspects of a problem and solution.
• class diagram depicts the static structure of a system.
• Object diagram depicts the static structure of a system at particular
time.
The behavioral model view encompasses the
dynamic or behavioral, aspects of a problem and
solution and interactions or collaborations among
problem solution elements.
• Collaboration diagrams depict an interaction among the elements
of a system and their relationship organized in time and space.
• Sequence diagrams depict an interaction among the elements of
a system organized in a time sequence.
• Static diagrams depict the status conditions and responses of the
elements of a system.
• Activity diagrams depict the activity of elements of a system.
 The implementation model view encompasses
the structural and behavioral aspects of the
solution’s realization.
– Component diagrams depict the organization of elements use
to realize a system.
The environment model view encompasses the
structural and behavioral aspects of the domain in
which a solution must be realized.
– Deployment diagram depict the configuration of environment
elements and the mapping of elements realizing a system onto
them.

The UML supports the user model view, structural model

view, behavioral model view, implementation model view,
and environment model view to facilitate the organization of
knowledge within problem solving.
UML DIAGRAMS
UML diagrams can be drawn to represent particular runtime
configurations of objects. These diagrams fall into three main
categories –
• Static diagrams: Static diagrams describe the kinds of
connections that can exist between objects and the possible
topologies that the resulting object network can have. Static
diagrams, like the
• Class Diagrams
• Use Case diagrams
• Dynamic diagrams: Dynamic diagrams describe the
messages that can be passed between objects and the effect
on an object of receiving a message. Dynamic diagrams
• Sequence Diagrams
• Object diagrams
• Collaboration diagram
• State diagrams
• Activity diagrams
• Implementation diagrams: The implementation
characteristic of a system describes the different elements
required for deploying a system. Implementation diagram like
• Component diagrams
• Deployment diagrams
CLASS DIAGRAMS
• Class diagrams depict the structure of a system in
general.
• Class diagrams have the following types of
elements.
• A class – Shown as a solid-outline rectangle labeled
with a name, this represents a general concept.
• An association – shown as a solid line path labeled
with a name , this represents a relationship between
classes.
• An attribute – shown as a text string in a class’s
second compartment, this represents what objects of
the class know.
• An operation – shown as a text string in a class’s 3rd
compartment, this represents what objects of the class
can do.
• A class diagram that shows classes with their
attributes and operation, together with the
associations between classes.
• Class diagrams are the backbone of almost every
object oriented method, including UML. They describe
the static structure of a system.
• Class diagrams are widely used to describe the types
of objects in a system and their relationships.
• Class diagrams model class structure and contents
using design elements such as classes, packages and
objects.
• Class diagrams describe three different perspectives
when designing a system, conceptual, specification,
and implementation. These perspectives become
evident as the diagram is created and help solidify the
design.
• Classes are composed of three things:
» name,
» attributes, and
» operations.

Below is an example of a class.

• Class diagrams also display relationships such as

containment, inheritance, associations and others.
Below is an example of an associative relationship:
The association relationship is the most common relationship in
a class diagram. The association shows the relationship
between instances of classes. For example, the class Order is
associated with the class Customer. The multiplicity of the
association denotes the number of objects that can participate
in then relationship. For example, an Order object can be
associated to only one customer, but a customer can be
associated to many orders.
• Another common relationship in class diagrams is a
generalization. A generalization is used when two classes are
similar, but have some differences. Look at the generalization
below:
• In this example, the classes Corporate Customer and
Personal Customer have some similarities such as name
and address, but each class has some of its own attributes
and operations. The class Customer is a general form of
both the Corporate Customer and Personal Customer
classes. This allows the designers to just use the
Customer class for modules and do not require in-depth
representation of each type of customer.

• Class diagrams are the backbone of almost every object-

oriented method including UML. They describe the static
structure of a system.
When to Use: Class Diagrams
• Class diagrams are used in nearly all Object Oriented
software designs. Use them to describe the Classes of
the system and their relationships to each other.
How to Draw: Class Diagrams
• Class diagrams are some of the most difficult UML
diagrams to draw. To draw detailed and useful
diagrams a person would have to study UML and
Object Oriented principles for a long time. Therefore,
this page will give a very high level overview of the
process. Before drawing a class diagram consider the
three different perspectives of the system the diagram
will present; conceptual, specification, and
implementation. Try not to focus on one perspective
and try see how they all work together.
• When designing classes consider what attributes and
operations it will have. Then try to determine how
instances of the classes will interact with each other.
These are the very first steps of many in developing a
class diagram. However, using just these basic
techniques one can develop a complete view of the
software system.
Basic Class Diagram Symbols and Notations:
Classes represent an abstraction of entities with
common characteristics. Associations represent the
relationships between classes.
• Classes
Illustrate classes with rectangles divided into
compartments. Place the name of the class in the first
partition (centered, bolded, and capitalized), list the
attributes in the second partition, and write operations
into the third.
• Active Class
Active classes initiate and control the flow of activity,
while passive classes store data and serve other
classes. Illustrate active classes with a thicker border.

• Visibility
Use visibility markers to signify who can access the
information contained within a class. Private visibility
hides information from anything outside the class
partition. Public visibility allows all other classes to
view the marked information. Protected visibility allows
child classes to access information they inherited from
a parent class.
• Associations
Associations represent static relationships between
classes. Place association names above, on, or below
the association line. Use a filled arrow to indicate the
direction of the relationship. Place roles near the end
of an association. Roles represent the way the two
classes see each other.
Note: It's uncommon to name both the association
and the class roles.
• Multiplicity (or 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.
• Constraint
Place constraints inside curly braces {}.
Composition and Aggregation
• Composition is a special type of aggregation that denotes
a strong ownership between Class A, the whole, and
Class B, its part. Illustrate composition with a filled
diamond. Use a hollow diamond to represent a simple
aggregation relationship, in which the "whole" class plays
a more important role than the "part" class, but the two
classes are not dependent on each other. The diamond
end in both a composition and aggregation relationship
points toward the "whole" class or the aggregate.
Generalization
Generalization is another name for inheritance or an "is a"
relationship. It refers to a relationship between two classes
where one class is a specialized version of another. For
example, Honda is a type of car. So the class Honda
would have a generalization relationship with the class car.
In real life coding examples, the difference between
inheritance and aggregation can be confusing. If you have
an aggregation relationship, the aggregate (the whole) can
access only the PUBLIC functions of the part class. On the
other hand, inheritance allows the inheriting class to
access both the PUBLIC and PROTECTED functions of
the super class.
OBJECT DIAGRAM:
• WHAT IS A UML OBJECT DIAGRAM?
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 describe the static
structure of a system at a particular time and they are
used to test the accuracy of class diagrams.
Basic Object Diagram Symbols And Notations
Object names:
• Each object is represented as a rectangle, which
contains the name of the object and its class
underlined and separated by a colon. Both names are
optional and the colon is only present if the class is
specified.
• Object attributes
As with classes, you can list object attributes in a
separate compartment. However, unlike classes,
object attributes must have values assigned to them.

• Active object
Objects that control action flow are called active
objects. Illustrate these objects with a thicker border.
• Multiplicity
You can illustrate multiple objects as one symbol if the
attributes of the individual objects are not important.

• Links
Links are instances of associations. You can draw a
link using the lines used in class diagrams.Learn how
to connect objects.
• Self-linked
Objects that fulfill more than one role can be self-
linked. For example, 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.
Assignment:
Draw object diagram for the following object classes,
with association names attributes and additional
object classes if required.
Object classes: college, playground, principal, classroom,
board, book, student, faculty, cafeteria, ruler, door, swing.
USE-CASE DIAGRAMS:
• Use case is a specification technique for functional
needs as perceived by a category of users.
• Use cases can be represented graphically in a use
case diagram, each use case being described in the
data dictionary.
• Use cases may be modeled at varying degrees of
abstraction, essential use cases, the most abstract,
are technologically and implementation independent
whereas real use cases describe how the use case
actually operates in a particular environment.
• So, a use case diagram shows actors and use cases,
together with various relations between them.
• A use case denotes a typical type of task that a user
can perform with a system. An actor represents a role
that a user can play when interacting with a system.
Actors are association can be related by
generalization, to make explicit their shared
capabilities.
• Use case diagrams model the functionality of system
using actors and use cases.
• A use case is a set of scenarios that describing an
interaction between a user and a system. A use case
diagram displays the relationship among actors and
use cases. The two main components of a use case
diagram are use cases and actors.

• An actor is represents a user or another system that

will interact with the system you are modeling. A use
case is an external view of the system that represents
some action the user might perform in order to
complete a task.
• When to Use: Use Cases Diagrams
Use cases are used in almost every project. The are
helpful in exposing requirements and planning the
project. During the initial stage of a project most use
cases should be defined, but as the project continues
more might become visible.

• How to Draw: Use Cases Diagrams

Use cases are a relatively easy UML diagram to draw,
but this is a very simplified example. This example is
only meant as an introduction to the UML and use
cases. If you would like to learn more see the
Resources page for more detailed resources on UML.
• Start by listing a sequence of steps a user might take
in order to complete an action. For example a user
placing an order with a sales company might follow
these steps.
• Browse catalog and select items.
• Call sales representative.
• Supply shipping information.
• Supply payment information.
• Receive conformation number from salesperson.
• These steps would generate this simple use case
diagram:
• This example shows the customer as a actor because
the customer is using the ordering system. The
diagram takes the simple steps listed above and
shows them as actions the customer might
perform. The salesperson could also be included in
this use case diagram because the salesperson is
also interacting with the ordering system.
• From this simple diagram, the requirements of the
ordering system can easily be derived. The system
will need to be able to perform actions for all of the
use cases listed. As the project progresses other use
cases might appear. The customer might have a need
to add an item to an order that has already been
placed. This diagram can easily be expanded until a
complete description of the ordering system is derived
capturing all of the requirements that the system will
need to perform.
• Use case diagrams model the functionality of a system
using actors and use cases. Use cases are services or
functions provided by the system to its users.
• System
Draw your system's boundries using a rectangle that
contains use cases. Place actors outside the system's
boundries.

• Use Case
Draw use cases using ovals. Label with ovals with
verbs that represent the system's functions.
• Actors
Actors are the users of a system. When one system is the
actor of another system, label the actor system with the
actor stereotype.

• Relationships
Illustrate relationships between an actor and a use case
with a simple line. For relationships among use cases, use
arrows labeled either "uses" or "extends." A "uses"
relationship indicates that one use case is needed by
another in order to perform a task. An "extends"
relationship indicates alternative options under a certain
use case.
Assignment:
A State Bank of India (SBI) has installed ATM to offer
basic service round the clock and the functional
requirement of the system are :
• The SBI client must be able to deposit or withdraw an
amount to/from his account using the ATM counter. Each
transaction has to be recorded and the client must be
able to review all transaction performed in his account.
• Access to the SBI account is provided by a PIN code.
• The system should be designed such that it automatically
checks the client account. If the amount to be withdrawn
exceeds the amount in the account of the client then it
should check whether the client could avail the overdraft
facility as per the SBI rules.
Draw a use-case diagram according to the above
scenario.
SEQUENCE DIAGRAMS:
• A sequence diagram or interaction diagram that shows
an interaction between objects arranged in a time
sequence. Sequence diagrams can be draw at
different levels of detail and also to meet different
purposes at several stages in the development life
cycle.
• Sequence diagrams describe interactions among classes in
terms of an exchange of messages over time. A horizontal axis
shows the elements involved in the interaction and a vertical
axis represents time proceeding down the page.
• Sequence diagrams have the following types of elements:
– Classes and Objects
• Classes are shown much the same way as on class diagrams.
Objects may also be shown much the same way as on object
diagrams.
– A lifeline
• Shown as a vertical dashed line from an element, this
represents the existence of the element over time.
– A communication
• Shown as a horizontal solid arrow from the lifeline of the sender
to the lifeline of the receiver and labeled with the name of the
operation to be invoked, this represents that the sender sends a
message or stimulus to the receiver.
• Sequence diagrams describe interactions among classes in
terms of an exchange of messages over time.
Basic Sequence Diagram Symbols And Notations
• Class roles
Class roles describe the way an object will behave in
context. Use the UML object symbol to illustrate class
roles, but don't list object attributes.

• Activation
Activation boxes represent the time an object needs to
complete a task.
• Messages
Messages are arrows that represent communication
between objects. Use half-arrowed lines to represent
asynchronous messages. Asynchronous messages
are sent from an object that will not wait for a
response from the receiver before continuing its tasks.
• Various message types for Sequence and
Collaboration diagrams
• Lifelines
Lifelines are vertical dashed lines that indicate the
object's presence over time.
• Destroying Objects
Objects can be terminated early using an arrow
labeled "< < destroy > >" that points to an X.
• Loops
A repetition or loop within a sequence diagram is
depicted as a rectangle. Place the condition for exiting
the loop at the bottom left corner in square brackets [
].
Assignment:
Draw a sequence diagram for the cellular
phone connection.
COLLABORATION DIAGRAMS
• A collaboration diagram that shows an interaction
between objects and the context of the interaction in
terms of the links between the objects.
• Collaboration diagrams represent interactions
between objects as a series of sequenced messages.

• Collaboration diagrams describe both the static

structure and the dynamic behavior of a system.

• A collaboration diagram describes interactions among

objects in terms 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.
• Collaboration diagrams have the types of elements
that are described in the list shown next.
• Classes and Objects
Classes are shown much the same way as on class
diagrams. Objects may also be shown much the same
way as on object diagrams.
• Associations
These are shown much the way as on class diagrams.
Links may also be shown much the same way as on
object diagrams.
• A communication
This is shown as an arrow attached to a relationship
pointing from the sender toward the receiver. It is labeled
with a sequence number showing the order in which the
communication is sent followed by a colon followed by the
name of the operation to be invoked. It represents that
the sender sends a message to the receiver.
Basic Collaboration Diagram Symbols And Notations
• Class roles
Class roles describe how objects behave. Use the
UML object symbol to illustrate class roles, but don't
list object attributes.

• Association roles
Association roles describe how an association will
behave given a particular situation. You can draw
association roles using simple lines labeled with
stereotypes.
• Messages
Unlike sequence diagrams, collaboration diagrams do
not have an explicit way to denote time and instead
number messages in order of execution. Sequence
numbering can become nested using the Dewey
decimal system. For 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 diagrams are also relatively easy to draw. They
show the relationship between objects and the order of
messages passed between them. The objects are listed as
icons and arrows indicate the messages being passed between
them. The numbers next to the messages are called sequence
numbers. As the name suggests, they show the sequence of
the messages as they are passed between the objects. There
are many acceptable sequence numbering schemes in UML. A
simple 1, 2, 3... format can be used, as the example below
shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2,
1.2.1... scheme can be used.
• The example below shows a simple collaboration
diagram for the placing an order use case. This time
the names of the objects appear after the colon, such
as :Order Entry Window following the objectName:
className naming convention. This time the class
name is shown to demonstrate that all of objects of
that class will behave the same way.
STATE CHART DIAGRAMS or STATE DIAGRAMS:
• Statecharts can be used to specify the behaviour of
classes that display statedependent behaviour. They
illustrate the sequences of messages that can be sent
to an object and the response that an object might
make to a message at different times. A state
diagrams also known as statechart diagram, depict the
lifecycle of an element. The state of an object is
determined by values of some its attributes and the
presence or absence of certain links with other
objects.
• State chart diagrams describe the dynamic behavior of
a system in response to external stimuli. State chart
diagrams are especially useful in modeling reactive
objects whose states are triggered by specific events.
• State diagrams are used to describe the behavior of a
system. State diagrams describe all of the possible
states of an object as events occur. Each diagram
usually represents objects of a single class and track
the different states of its objects through the system.
• A state chart diagram shows the behavior of classes in
response to external stimuli. This diagram models the
dynamic flow of control from state to state within a
system.
Basic State chart Diagram Symbols And Notations
• States
States represent situations during the life of an object.
You can easily illustrate a state in SmartDraw by using
a rectangle with rounded corners.

• Transition
A solid arrow represents the path between different
states of an object. Label the transition with the event
that triggered it and the action that results from it.
 Fig. Initial State Fig. Final State Fig.
• 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 transitions leaving it represents a splitting of
control that creates multiple states.
When to Use: State Diagrams
• Use state diagrams to demonstrate the behavior of an
object through many use cases of the system. Only
use state diagrams for classes where it is necessary
to understand the behavior of the object through the
entire system. Not all classes will require a state
diagram and state diagrams are not useful for
describing the collaboration of all objects in a use
case. State diagrams are other combined with other
diagrams such as interaction diagrams and activity
diagrams.
How to Draw: State Diagrams
• State diagrams have very few elements. The basic
elements are rounded boxes representing the state of
the object and arrows indicting the transition to the
next state. The activity section of the state symbol
depicts what activities the object will be doing while it
is in that state.
• All state diagrams being with an initial state of the
object. This is the state of the object when it is
created. After the initial state the object begins
changing states. Conditions based on the activities
can determine what the next state the object
transitions to.
Assignment:
• Draw a state chart diagram, which explains the
various states of making a phone call.
• A passenger calls the lift from its current floor and
after entering the lift the passenger presses the
destination button. The lift on arrival at destination
will wait for next response up to a time limit. If there
is no response within the time, the lift will go back to
its home floor that is ground floor. Represent these
features with the help of state diagrams.
ACTIVITY DIAGRAMS:
• A activity diagram is a variation of a state chart
diagram that focuses on a flow of activity driven by
internal processing within an object rather than by
events that are external to it. In an activity diagram
most states are action, each of which represents the
execution of an operation.
• 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 describe the workflow behavior of a
system. Activity diagrams are similar to state diagrams
because activities are the state of doing something. The
diagrams describe the state of activities by showing the
sequence of activities performed. Activity diagrams can show
activities that are conditional or parallel.
• An activity diagram illustrates 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. Because an activity diagram
is a special kind of statechart diagram, it uses some of the
same modeling conventions.
Basic Activity Diagram Symbols And Notations
• Action states
Action states represent the noninterruptible actions of
objects. You can draw an action state in SmartDraw
using a rectangle with rounded corners.

• Action Flow
Action flow arrows illustrate the relationships among
action states.
 Fig. Object Flow Fig. Initial State Fig. Final State
• Object Flow
Object flow refers to the creation and modification of objects by
activities. An object flow arrow from an action to an object
means that the action creates or influences the object. An
object flow arrow from an object to an action indicates that the
action state uses the object.
• 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 action state.
 Fig. Branching Fig. Synchronization
• Branching
A diamond represents a decision with alternate paths.
The outgoing alternates should be labeled with a
condition or guard expression. You can also label one
of the paths "else.“
• Synchronization
A synchronization bar helps illustrate parallel
transitions. Synchronization is also called forking and
joining.
• Swimlanes
Swimlanes group related activities into one column. Read this this flowchart
tutorial to learn how to create swimlanes in SmartDraw.

• When to Use: Activity Diagrams

• Activity diagrams should be used in conjunction with other
modeling techniques such as interaction diagrams and state
diagrams. The main reason to use activity diagrams is to
model the workflow behind the system being designed.
• Activity Diagrams are useful for:
¾ Analyzing a use case by describing what actions need to take place and
when they should occur.
¾ Describing a complicated sequential algorithm; and
¾ Modeling applications with parallel processes.
• Activity diagrams should not take the place of interaction
diagrams and state diagrams.
• Activity diagrams do not give detail about how objects
behave or how objects collaborate.
How to Draw: Activity Diagrams
• Activity diagrams show the flow of activities through
the system. Diagrams are read from top to bottom
and have branches and forks to describe conditions
and parallel activities. A fork is used when multiple
activities are occurring at the same time. The diagram
below shows a fork after activity1. This indicates that
both activity2 and activity3 are occurring at the same
time. After activity2 there is a branch. The branch
describes what activities will take place based on a set
of conditions. All branches at some point are followed
by a merge to indicate the end of the conditional
behavior started by that branch. After the merge all of
the parallel activities must be combined by a join
before transitioning into the final activity state.
PHYSICAL DIAGRAMS
There are two types of physical diagrams:
• Deployment diagrams
• Component diagrams
Deployment diagrams show the physical relationship
between hardware and software in a system.
Component diagrams show the software
components of a system and how they are related to
each other. These relationships are called
dependencies.
When to Use: Physical Diagrams
• Physical diagrams are used when development of the
system is complete.
• Physical diagrams are used to give descriptions of the
physical information about a system.
• How to Draw: Physical Diagrams
• Many times the deployment and component diagrams are
combined into one physical diagram. A combined deployment
and component diagram combines the features of both
diagrams into one diagram.
• The deployment diagram contains nodes and connections.
• A node usually represents a piece of hardware in the system.
• A connection depicts the communication path used by the hardware
to communicate and usually indicates a method such as TCP/IP.
• The component diagram contains components and
dependencies.
• Components represent the physical packaging of a module of
code. The dependencies between the components show how
changes made to one component may affect the other components in
the system.
• Dependencies in a component diagram are represented by a dashed
line between two or more components. Component diagrams can
also show the interfaces used by the components to communicate to
each other.
• The combined deployment and component diagram below
gives a high level physical description of the completed
system. The diagram shows two nodes which represent two
machines communicating through TCP/IP. Component2 is
dependant on component1, so changes to component 2 could
affect component1. The diagram also depicts component3
interfacing with component1. This diagram gives the reader a
quick overall view of the entire system.
COMPONENT DIAGRAMS:
• Component is a physical entity that is part of an
application and is usually represented in the
implementation view.
• A component diagram that shows the organization of
and dependencies among components.
• component diagram show the physical components of
a system. It can be combined with deployment
diagrams to show the physical location of components
of the system.

• Component diagrams describe the organization of

physical software components, including source code,
run-time (binary) code, and executables codes.

• A component diagram describes the organization of

the physical components in a system.
Basic Component Diagram Symbols and Notations
Component diagrams have the following types of elements:

Fig. Component Fig. Interface Fig. Dependencies

• Component
A component is a physical building block of the system. It is
represented as a rectangle with tabs.
• Interface
An interface describes a group of operations used or created by
components.
• Dependencies
Draw dependencies among components using dashed arrows.
DEPLOYMENT DIAGRAMS:
• A deployment diagram that shows the run-time configuration of
processing nodes and the components, processes and objects
that are located on them.
• Deployment diagrams depict the physical resources in a
system, including nodes, components, and connections.
Basic Deployment Diagram Symbols And Notations
Deployment diagrams have the following types of elements:
Node
A node is a physical resource that executes code components.
Shown as 3D rectangle, this represents a resource that is
available during execution time.

Association
Shown as a solid line path between nodes. Association refers
to a physical connection between nodes, such as Ethernet.
Components and Nodes
Place components inside the node that deploys them.
CASE STUDIES:
1. Draw a state chart diagram, which explains the
various states of making a phone call.

2. A passenger calls the lift from its current floor and

after entering the lift the passenger presses the
destination button. The lift on arrival at destination
will wait for next response up to a time limit. If there
is no response within the time, the lift will go back to
its home floor that is ground floor. Represent these
features with the help of state diagrams.
3. A State Bank of India (SBI) has installed ATM to
offer basic service round the clock and the
functional requirement of the system are :
• The SBI client must be able to deposit or withdraw an
amount to/from his account using the ATM counter.
Each transaction has to be recorded and the client
must be able to review all transaction performed in his
account.
• Access to the SBI account is provided by a PIN code.
• The system should be designed such that it
automatically checks the client account. If the amount
to be withdrawn exceeds the amount in the account of
the client then it should check whether the client could
avail the overdraft facility as per the SBI rules.
Draw a use-case diagram according to the above
scenario.