OOAD using UML

Emmanuel Pilli
OBJECT ORIENTED SOFTWARE
ENGINEERING (OOSE)

⚫ OOSE is a process of systematical building of

Software using classes and objects.

⚫ OOSE is an object – oriented, graphical modeling

notation, that provides a clear and precise model,
that allows us to describe an architecture and
components, that will ensure the development of
robust, reuse – supporting systems.
SOFTWARE ENGINEERING (SE)
- A Team Process

⚫ Software Engineering, is a process in which,

a team of people build Software Systems,
using systematic Engineering Principles and
Techniques; such as
– Model building,
– Simulation,
– Estimation, and
– Measurement.
THE IMPORTANCE OF MODELING

⚫ A model is a simplification of reality.

– We build models so that we can better understand the system we are
developing.
⚫ Models help us to visualize a system as it is or as we want it to be.
⚫ Models permit us to specify the structure or behavior of a
system.
⚫ Models give us a template that guides us in constructing a system.
⚫ Models document the decisions, we have made.
– We build models of complex systems because we cannot comprehend
such a system in its entirely.
⚫ Every model may be expressed at different levels of precisions.
⚫ The best models are connected to reality.
OBJECT ORIENTED
SYSTEM DEVELOPMENT

System Development
USE
ANALYSIS DESIGN IMPL. TEST
CASE
Requirements MODEL
MODEL MODEL MODEL MODEL System
OBJECT ORIENTED SOFTWARE
ENGINEERING MODELS

⚫ USE-CASE MODEL
⚫ DOMAIN OBJECT MODEL
⚫ ANALYSIS MODEL
⚫ DESIGN MODEL
⚫ IMPLEMENTATION MODEL
⚫ TEST MODEL
OBJECT ORIENTED SOFTWARE
ENGINEERING MODELS

Use-case Model

Express it Tested in
Stand by Realized by Implemented by

OK
NOT OK

Domain Analysis Design Implementation Testing

Object Model Model Model Model
Model
OBJECT ORIENTED SOFTWARE
ENGINEERING MODELS

⚫ USE CASE MODEL

– The Use–case Model defines the outside actors and inside use–cases of
the system’s behavior.
⚫ DOMAIN OBJECT MODEL
– The objects of the real world are mapped into the Domain Object Model.
⚫ ANALYSIS MODEL
– The Analysis Object Model presents hoe the source code (implementation)
should be carried out and written.
⚫ IMPLEMENTATION MODEL
– The Implementation Model represents the implementation of the system.
⚫ TEST MODEL
– The Test Model constitutes the plan, specifications and reports.
UNIFIED MODELING LANGUAGE (UML)

⚫ What is UML?
⚫ Why UML?
UNIFIED MODELING LANGUAGE (UML)

⚫ What is UML?
– A model is a simplification of reality.
– we build models of complex systems because we cannot
comprehend such a system in entirety.
– Architects design buildings, Builders use the designs to
create buildings. The more complicated the building, the
more critical the communication between architect and
builder.
– Blueprints are the standard graphical language that both
architects and builders must learn as part of their trade.
UNIFIED MODELING LANGUAGE (UML)

⚫ What is UML?
– Writing software is not unlike constructing a building.
– The more complicated the underlying system, the more
critical the communication among every one involved in
creating and developing the software.
– In the past decade, the UML has emerged as the software
blueprint language for analysts, designers, and
programmers alike.
– It is now part of software trade.
– The UML gives everyone from business analyst to designer
to programmer a common vocabulary to talk about software
design.
UNIFIED MODELING LANGUAGE (UML)

⚫ Why UML?
– The UML is applicable to object oriented problem solving.
– Anyone interested in UML must be familiar with the
underlying tenet of object-oriented problem solving – it all
begins with the construction of a model.
– A model is an abstraction of the underlying problem.
– The domain is the actual world from which the problem
comes
UNIFIED MODELING LANGUAGE (UML)

⚫ History of UML
⚫ Evolution of UML
⚫ Common Modeling Techniques
UNIFIED MODELING LANGUAGE (UML)

⚫ History of UML
– Object oriented modeling languages appeared sometime between
the mid 1970’s and the late 1980’s.
– Most notably Grady Booch, Ivan Jacobson’s – OOSE
(Object Oriented Software Engineering) and James Rumbaugh’s
OMT (object modeling techniques).
– The Booch was particularly expressive during the design and
construction phases of the projects.
– OOSE provides excellent software requirements capture, analysis,
design. OMT-2 was useful for analysis and data intensive
information system. Grady Booch (Rational software corporation),
Ivan Jacobson (objectory) and James Rumbaugh (General
Electric).
– The UML effort started affectively in 1994,when Rumbaugh joined
Booch at Rational.
UNIFIED MODELING LANGUAGE (UML)

⚫ Evolution of UML
First Gen Booch’91 OMT-1 Other Methods
fragmentation And modeling
(mid 1970’s mid 1990’s) Booch’93 Languages
OMT-2
Second Gen
Methods and Modeling
language Unified Methods
[October 1995]
OOSE
UML 0.9
[june’96]

UML 0.91 UML Partners

[OCT’96]

UML 1.0
Standardization [JAN’97]
[later half of’97] UML 1.1
[NOV’97]
Products Services
Industrialization Vendors
Organizations
Common Modeling Techniques

⚫ Modeling the Architecture of a system.

Vocabulary System assembly
functionality Configuration management

Design view Implement view

Use case
view
Behavior

Process view
Deployment view

Performance System topology

Scalability Distribution
throughput Delivery
installation
Common Modeling Techniques

⚫ The following activities apply to the system, as well as

its subsystems:
– Use Case View
⚫ Encompassing the use cases that describe the behavior of the
system as seen by its end users ,analysts and testers.
⚫ Apply use case diagrams to model static aspects and interaction
diagrams, state chart diagrams and activity diagrams to model the
dynamic aspects
– Design View
⚫ Encompassing the classes, interfaces and collaborations that
form the vocabulary of the problem and its solution.
⚫ Apply class diagrams and object diagrams to model static
aspects, interaction
⚫ diagrams, state chart diagrams and activity diagrams to model the
dynamic aspects.
Common Modeling Techniques

– Process View
⚫ Encompassing the threads and processes that form the systems
concurrency and synchronization mechanisms
– Implementation View
⚫ Encompassing the components that are used to assemble and
release the physical system.
⚫ Apply component diagrams to model static aspects and
interaction diagrams, state chart, activity diagrams to model the
dynamic aspects.
– Deployment View
⚫ Encompassing the nodes that form the systems hardware
topology on which the
⚫ system executes. Apply deployment diagrams to model static
aspects.
UNIFIED MODELING LANGUAGE (UML)

⚫ Introduction to UML
⚫ Overview of UML
⚫ Unification and approaches in UML
⚫ Goals of UML
⚫ Methodologies in UML
⚫ Applications of UML
⚫ Building Blocks of UML
UNIFIED MODELING LANGUAGE (UML)

⚫ Introduction to UML
– The unified modeling language (UML) is a
standard language for writing software blueprints.
– The UML may be used to
⚫ Visualize,
⚫ Specify,
⚫ Construct, and
⚫ Document.
UNIFIED MODELING LANGUAGE (UML)

⚫ An Overview of UML
– The UML is a language for
⚫ Visualizing,
⚫ Specifying,
⚫ Constructing, and
⚫ Documenting.
– A language provides a vocabulary and the rules for
combining words in that vocabulary for the purpose of
communication.
– A modeling language is a language whose vocabulary and
rules focus on the conceptual and physical representation of
a system.
– UML is for specifying means building models that are
precise unambiguous and complete.
UNIFIED MODELING LANGUAGE (UML)

⚫ Unification in UML

Specify construct

System

Visualize Document
UNIFIED MODELING LANGUAGE (UML)

⚫ Unification and approaches in UML

– Grady Booch’s method
– James Rumbough (OMT) method
– Ivar jacobson’s (OOSE) method
UNIFIED MODELING LANGUAGE (UML)

⚫ Unification and approaches in UML

– Grady Booch’s method
⚫ A design and construction oriented approach supporting
excellent expressiveness for engineering-intensive
systems.
⚫ Grady booch’s work has involved the use of Ada and the
application of data abstraction and information hiding
with an emphasis on iterative software development and
software architecture.
UNIFIED MODELING LANGUAGE (UML)

⚫ Unification and approaches in UML

– James Rumbough (OMT) method
⚫ An analysis – oriented approach supporting excellent
expressiveness for data-intensive systems.
⚫ James Rumbough’s work has involved various topics
concerning research and development with in the
context of complex algorithm and data structures
UNIFIED MODELING LANGUAGE (UML)

⚫ Unification and approaches in UML

– Ivar jacobson’s (OOSE) method
⚫ A usecase – oriented approach supporting excellent
expressiveness for business engineering and
requirements analysis.
⚫ Ivar jacobson’s work has involved the application of
object – oriented to the context of business
reengineering and the industrialization of software
development.
⚫ He is often known as the father of use cases.
UNIFIED MODELING LANGUAGE (UML)

⚫ GOALS of UML
– Be a reader to use expressive visual modeling language
⚫ Have Extensibility
⚫ Be implementation independent
⚫ Be process independent
⚫ Support all level concepts collaborations, patterns, Frameworks and
components
⚫ Be widely applicable and usable
⚫ Be scalable
Rumbaugh
Booch Jacobson

Odell
Classification

Shlaer-Mellor UML
Havel (State charts)

Wirfs-Block (responsibilities)
Gamma
Frameworks, patterns
Embly Fusion
UNIFIED MODELING LANGUAGE (UML)

⚫ Methodologies in UML
– Grady Booch’s Methodology
⚫ This method focuses more on the Object Oriented
Design than the Object Oriented Analysis.
⚫ It identifies the classes and object.
⚫ It identifies the semantics of classes and objects.
⚫ It identifies the Relationships.
⚫ Conduct a series of refinements.
UNIFIED MODELING LANGUAGE (UML)

⚫ Methodologies in UML
– Jacobson’s Methodology
⚫ Identify the users of the system and their overall
responsibilities.
⚫ Build a requirement model.
⚫ Build analysis model.
UNIFIED MODELING LANGUAGE (UML)

⚫ Methodologies in UML
– Rumbaugh’s Methodology
⚫ Developed the OMT (Object Modeling Techniques) for
Analysis, System Design and Object Design.
⚫ Develop a statement of scope for the problem
⚫ Build an object model (object, classes, hierarchies and
relationships)
⚫ Build a dynamic model (Object and system behavior)
⚫ Construct functional model (Information flow)
UNIFIED MODELING LANGUAGE (UML)

⚫ Applications of UML
– Where can the UML be used ?
⚫ Enterprise Information Systems
⚫ Banking and Financial Systems
⚫ Telecommunications
⚫ Transportation
⚫ Defense /Aerospace
⚫ Medical, Electronics, Scientific
⚫ Distributed web-based services
UNIFIED MODELING LANGUAGE (UML)

⚫ Building Blocks of UML

– Things
– Relationships
– Diagrams
BUILDING BLOCKS OF UML

⚫ Things
– There are four types of things in UML.
⚫ Structural Things
⚫ Behavioral Things
⚫ Grouping Things
⚫ Annotational Things
BUILDING BLOCKS OF UML

⚫ Things
– Structural Things
⚫ These are STATIC PARTS of model, which might be
either conceptual or physical
⚫ There are seven kinds of Structural Things.
– Class
– Interface
– Collaboration
– Use Case
– Active Class
– Component
– Node
BUILDING BLOCKS OF UML

⚫ Things
– Behavioural Things
⚫ These are DYNAMIC PARTS of UML. These are verbs of a
model representing behavior over time and space.
⚫ There are two types of behavioral things.
– Interactions
⚫ Interaction is a behavior that is a set of messages exchanged among
a set of Objects.
⚫ They involve elements like messages, actions sequences and lines.
Display
– State Machine
⚫ It is a behavior that specifies the sequences of states when an Object
or an interaction goes through during its life time in response to
events.
Waiting
BUILDING BLOCKS OF UML

⚫ Things
– Grouping Things
⚫ These are the organizational parts of the UML..
⚫ These are boxes into which a model can be decomposed.
– Eg: Package <<Subsystem>>
Billing

⚫ Package is a general purpose mechanism for organizing

things (Structural,Behavioral) into Groups or Packages.
– Annotational Things
⚫ These are the explanatory parts of UML models, like
comments and remarks.
– Eg: Note
BUILDING BLOCKS OF UML

⚫ Relationships
– A relationship is a connection among things.
– There are four types of relationships in UML.
⚫ Dependencies
⚫ Generalizations
⚫ Associations
⚫ Realizations
– Graphically, a relationship is rendered has a path, with
different kinds of lines used to distinguish the kinds of
relationships.
BUILDING BLOCKS OF UML

⚫ Relationships
– Dependency
⚫ A dependency is a using relationship that states a change in specification
of one thing may affect another thing that uses it, but not necessarily the
reverse.
⚫ Graphically, a dependency is rendered as a dashed directed line,
directed to the thing being depended on.
⚫ Use dependencies when you want to show one thing using another.
⚫ Example: class A class B

FilmClip
name Channel

playOn(c:Channel)()
BUILDING BLOCKS OF UML

⚫ Relationships
– Generalization
⚫ A generalization is a relationship between a general thing (called the
super-class or parent) and a more specific kind of that thing (called the
subclass or child).
⚫ It is sometimes called an “is-a-kind-of” relationship. Use generalizations
when you want to show parent/child relationships.
⚫ Graphically, generalization is rendered as a solid directed line with a large
open arrowhead, pointing to the parent.
Shape

Rectangle Circle Triangle

BUILDING BLOCKS OF UML

⚫ Relationships
– Association
⚫ An association is a structural relationship that specifies that objects of one
thing are connected to objects of another.
⚫ Given an association connecting two classes, you can navigate from an
object of one class to an object of other class, and vice versa.
⚫ Use associations when you want to show structural relationships.
⚫ Graphically, an association is rendered has a solid line connecting the
same or different classes.
⚫ Example:
Person Company
BUILDING BLOCKS OF UML

⚫ Relationships
– Navigation
⚫ Given a plain, unadorned association between two classes, it’s possible to
navigate from objects of one kind to objects
⚫ You can explicitly represent the direction of navigation by adorning an
association with an arrowhead pointing to the direction of traversal.
⚫ Example:

User Password
BUILDING BLOCKS OF UML

⚫ Relationships
– Name
⚫ An association can have a name, and you use that name to describe
the nature of the relationship. Name
⚫ Example:
Person Works for... Company
– Role
⚫ When a class participates in an association, it has a specific role that it
plays in that relationships; a role is just the face the class at the near
end of the association presents to the class at the other end of the
association. Works for...
Person Company
⚫ Example: employee... employer

Role
BUILDING BLOCKS OF UML

⚫ Relationships
– Multiplicity
⚫ An association represents a structural relationship among objects. In many
modeling situations, it’s important for you to state how many objects may be
connected across an instance of an association. This “how many” is called the
multiplicity of an association’s role, and is written as an expression that evaluates
to a range of values or an explicit value.
1
⚫ Example: Person 1..* Works for... *... Company
– Association employee... employer

⚫ Sometimes, you will want to model a “whole/part” relationship, in which one class
represents a larger thing (the “whole”) , which consists of smaller things(the
“parts”). This kind of relationship is called aggregation.
⚫ Example:
Customer Department
BUILDING BLOCKS OF UML

⚫ Relationships
– Realization
⚫ Realization is a semantic relationship between classifiers,
wherein one classifier specifies a contract that another classifier
guarantees to carry out. You will encounter realization
relationships in two places : between interfaces and the classes
or components that realize them and between use cases and the
collaborations that realize them.
⚫ Graphically, it is rendered as a cross between a generalization
and a dependency relationship..
⚫ Example:
BUILDING BLOCKS OF UML

⚫ Diagrams
– Different Types of Modeling Techniques used in UML
⚫ Structural Modeling: It consists of
– Class Diagrams.
– Object Diagrams.
⚫ Behavioral Modeling: It consists of
– Use case Diagrams
– Activity Diagrams
– State Chart Diagrams
– Interaction Diagrams
⚫ Sequence Diagrams
⚫ Collaboration Diagrams

⚫ Architectural Modeling: It consists of

– Component Diagrams
– Deployment Diagrams
BUILDING BLOCKS OF UML

⚫ Diagrams
– We can view the static parts of a system using one of the four
following diagrams:
⚫ Class diagrams
⚫ Object diagrams
⚫ Component diagram
⚫ Deployment diagram
– We can view Dynamic parts of a system by these five diagrams:
⚫ Use case diagram
⚫ Sequence diagram
⚫ Collaborations diagrams
⚫ State chart diagram
⚫ Activity diagram
– The UML defines these nine kinds of diagrams.
Class Diagram

⚫ A class diagram shows a set of classes, interfaces,

collaborations, and their relationships. These diagrams
are the most common diagrams found in modeling.
⚫ Class diagrams are the backbone of almost every
object oriented method, including UML. They describe
the static structure of a system.
Aggregation
class A
attr-1 class B
attr-2 attr-1

op-1() op()
op-2()
Generalization

class C
attr-1

op-1()
Object Diagram

⚫ An object diagram shows a set of objects and their

relationships.
⚫ Object diagrams describe the static structure of a system
at a particular time. They can be used to test class
diagrams for accuracy.

Object name:class
attr type
attr type

Object1 name:class Object1 name: class

attr1 type attr type
attr2 type
Use-case Diagram

⚫ A Use Case shows a set of use cases and actors and

their relationships.
⚫ Use Case Diagrams model the functionality of system
using actors and use cases.
use case
use case

<<include>>
use case

<<extend>>
actor

use case

actor
use case
State-chart Diagram

⚫ A state Chart diagram shows a

state machine, consisting of states,
transitions, events, and activities.
They address the dynamic view of State 1

the system.
⚫ State chart diagrams describe the State 2
dynamic behavior of a system in
response to external stimuli. State State 3

chart diagrams are especially

useful in modeling reactive objects
whose states are triggered by
specific events.
Sequence Diagram

⚫ A sequence diagram is an interaction diagram that emphasizes

the time ordering of the messages.
⚫ Sequence diagrams describe interactions among classes in
terms of an exchange of messages over time.
object:class object:class object:class

message name

message
message
Collaboration Diagram
⚫ A collaboration diagram is an interaction diagram that
emphasizes the structural organization of the objects that
send and receive messages.
⚫ Collaboration diagrams represents interactions between
objects as a series of sequenced messages. Collaboration
diagrams describe both the static structure and the dynamic
behavior of a system.
3: message
1:
object:class object:class
2:

message 4:
5: message

object:class
Activity Diagram

⚫ An activity diagram is a special kind

of state chart diagram that shows
the flow from activity to activity
within a system. Activity 1
⚫ Activity diagrams illustrate the
dynamic nature of a system by
modeling the flow of control from
Activity2
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. Activity 3
Typically, activity diagrams are
used to model workflow or business
processes and internal operation.
Component Diagram

⚫ A component diagram shows the organization and

dependencies among a set of components. Component
diagrams address the static implementation view of a system.
⚫ Component diagrams describe the organization of physical
software components, including source code, run-time
(binary) code, and executables.
Component

note

Component
Deployment Diagram

⚫ A deployment diagram shows the configuration of run-time

processing nodes and the components that leave on them.
They address the static deployment view of an architecture.
⚫ Deployment diagrams depict the physical resources in a
system.

Node Node
UNIFIED MODELING LANGUAGE (UML)

⚫ Software Development Life Cycle (SDLC)

– The UML is largely process independent. You
should consider process that is
⚫ Use case driven
⚫ Architecture-centric
⚫ Interactive and Incremental
⚫ Phases in a Life Cycle
⚫ The life of the Unified Process
Software Development Life Cycle
(SDLC)

⚫ Use case driven approach

– It means that use cases are used as a primary artifact for establishing
the desired behavior of the system for verifying and validating the
systems architecture, for testing and for communication among the
stake holders of the project.
⚫ Architecture centric approach
– It means that a system’s architecture is used as a primary artifact for
constructing, managing and evolving the system under development.
⚫ Iterative process
– An iterative process involves managing a system of executable
releases. An incremental process is one that involves the continuous
interaction of the systems architecture to produce these releases.
Together an iterative and incremental process is risk driven.

⚫ This Use case driven, Architecture-centric and Iterative process

can be broken into phases.
– A phase is the span of time between two major milestones of the process,
when a well defined set of objectives are met, artifacts are completed and
decisions are made whether to move into the next phase.
PHASES IN A LIFE CYCLE

⚫ Core workflows
– There are four phases in the software development
lifecycle:
⚫ Inception: Is the first phase of the process, when the seed
idea for the development is brought up to the point of being.
⚫ Elaboration: Is the second phase of the process, when the
product vision and architecture are defined. In this phase the
systems requirements are articulated and base lined.
⚫ Construction: Is the third phase of the process, when the
software is brought from the executable architecture. Baseline
to being ready to be transitioned to the user community.
⚫ Transition: Is the fourth phase of the process, when the
software is turned in to the hands of the user community.
– One element that distinguishes this process and that
cuts across all four phases is an iteration.
THE LIFE OF THE UNIFIED PROCESS

⚫ The unified process repeats over a series of cycles making up

the life at a system.
⚫ Each cycle consists of four phases : Inception, Elaboration,
construction and Transition

Actor

Specified by
Use case model
Realized by

Analysis model
Distributed by

design model
Implemented by
verifiedby

Deployment model

Implementation model
INTRODUCTION TO CLASSES

⚫ A class is a description of a set of objects that share

the same attributes, operations, relationships, and
semantics.
⚫ Classes are the “blueprints” for objects.
⚫ Graphically, a class is rendered as a rectangle.
⚫ Names
– Every class must have a name that distinguishes it from
other classes.
– Name is a textual string
– Example:
Wall Customer
INTRODUCTION TO CLASSES

⚫ Attributes
– An attribute is a name’s property of a class that describes
a range of values that instances of the property may hold.
A class may have any number of attributes or no
attributes at all.
– Graphically, attributes are listed in a compartment just
below the class name.
– Example:
class name Customer
attribute-1
attribute-2
name
address
attribute-n phone
INTRODUCTION TO CLASSES

⚫ Operations
– An operation is the implementation of a service that
can be requested from any object of the class to affect
behavior.
– A class may have any number of operations or no
operations at all.
– Graphically operations are listed in a compartment just
below the class attributes.
– Example:
class name
Rectangle
opname-1()
opname-2() add()
:() grow()
opname-m() move()
INTRODUCTION TO CLASSES

⚫ Responsibilities
– A responsibility is a contract or an obligation of class
– A class may have any number of responsibilities
– Graphically, responsibilities can be drawn in a separate
compartment at the bottom of the class
– Example:
Responsibilities

class A
attr-1
attr-2

op-1()
op-2()
COMMON MECHANISM

⚫ Notes
– A note is a graphical symbol for rendering constraints
or comments attached to an element or a collection of
elements .
– Notes are also used to specify thing like
requirements, observations, reviews, and
explanations
– A note may contain any formulation of text or
graphics
– Graphically, a note is rendered as a rectangle with a
dog-eared corner, together with a textual or graphical
comment
note
COMMON MECHANISM

⚫ Stereotypes
– A stereotype allows you to create new kinds of building block
similar to existing ones but specific to your problem.
– Graphically, a stereotype is rendered as a name enclosed by
guillemots and placed above the name of another element.
– Example: stereotype <<Subsystem>>
Billing
⚫ Tagged Values
– A tagged value allows you to create new information in that
element’s specification
– Graphically, a tagged value is rendered has a string enclosed
by brackets and placed below the name of another element.
– Example:
<<subsystem>>
Billing Tagged
{version=3.2} Value
COMMON MECHANISM

⚫ Constraints
– A constraint allows you to add new rules or to modify
existing ones.
– Graphically, a constraint is rendered as a string enclosed
by brackets and placed near the associated element or
connected to that element or elements by dependency
relationships

00} Corporates
>R s1 0
a la nce
Example :- {b

Bank Account

constraint Person

{ Ba
lan
c e>R
s 50
0}
customers
VISIBILITY

⚫ The visibility is a feature that specifies whether it can be used by

other classifiers.
⚫ In the UML, you can specify any of three levels of visibility

1. public ( + ) : Any outside classifier with visibility to the given

classifier can use the feature; specified by
prep ending the symbol
2. protected (#) : Any descendant of the classifier can use the
feature; specified by prep ending the symbol #
3. private (-) : Only the classifier itself can use the feature;
specified by prep ending the symbol -
VISIBILITY

⚫ Example:
Rectangle
Private
length
breadth
Protected area

Implementation
add()
grow()
move()
Public
remove()
INTERFACES

⚫ Interface
An interface is a collection of operations that are used to specify a
service of a class or a component.
⚫ Names
Every interface must have a name that distinguishes it from other
interfaces. A name is a textual string.
Example :-

Interface
INTERFACES

Interface Diagram
Find.exe Component.java

Image
observer

dependency realization

<<Interface>>
Image.java Image observer
Component.java
abort : int
error : int

imageupdate()
PACKAGES

⚫ Package
– A package is a general-purpose mechanism for organizing
elements into groups.
– Graphically, a package is rendered as a tabbed folder

⚫ Name
– Every package must have a name that distinguishes it from other
packages. A name is a textual string.
– A package is typically drawn showing only its name.
– Example :
Business rules
PACKAGES

• Owned Elements
A package may own other elements, including classes, interfaces,
components, nodes, collaborations, use cases, diagrams, and even other
packages. Owning is a composite relationship, which means that the
element is declared in the package. You can explicitly show the contents
of a package either textually or graphically.

• Visibility
You can control the visibility of the elements owned by a package just as you
can control the visibility of the attributes and operations owned by a class

• Generalization
Generalization among packages is very much like generalization
among classes
TYPES OF CLASSES

⚫ Parameterized Class:
A parameterized class is a class that is used to create a family of other
classes . A parameterized class is some sort of container , and is also
known as a template.
Ex: list→ emplist
order list
TYPES OF CLASSES

⚫ Instantitated Class:
An instantiated class is a parameterized class that has actual
values for the arguments . The UML notation for an instantiated
class is a class with the arguments name enclosed in < >.

<class>
TYPES OF CLASSES

⚫ Meta Class:
A meta class is a class whose instances are classes rather than
objects .Parameterized classes parameterized class Utilities are
examples of meta classes

<class>
TYPES OF CLASSES

⚫ Parameterized Class Utility:

A parameterized class utility is a parameterized class that contains
a set of operations

<class>
CLASSIFIERS

Class Interface Data Type Signal

<<type>>
int{values range <<signal>>
Iunknown from-2**31 to +2**31} OffHook

Node
Component Subsystem Use case
egb_server
kernel32.dll <<subsystem>>
customer service
subsystem
process loan
ASSIGNING A CLASS
STEREOTYPES
A stereotype is a mechanism we can use to categories the class.
These are three primary class stereotypes in the UML
⚫ Boundary
⚫ Entity
⚫ Control
Boundary Classes:
Boundary classes are those classes that lie on the boundary between the
system and the rest of the world

Eg:- the forms, reports, interfaces to hardware such as printers or scanners and
interfaces to other systems.
ASSIGNING A CLASS
STEREOTYPES

Entity Classes:
Entity classes hold information that you will save to persist storage

Eg:- we create a table in our database for each entity class

Control Classes:
Control classes are responsible for coordinating the efforts of other
classes. There is typically one control class per use case.
ASSIGNING A CLASS
STEREOTYPES

Account cashier interface withdrawal

<<entity>> <<boundary <<control>>

Account Cashier Withdrawal
Interface
ASSIGNING A CLASS
STEREOTYPES

Example:

order confirmation

order handler

buyer invoice

payment request UI

payment scheduler payment request

STANDARD ELEMENTS

The UML defines four standard stereotypes

That apply to classes
1.Meta class
2.power type
3.Stereotype
4.Utility

Two stereo types apply to dependency relationship among use cases.

1.Extend: The target use case extends the behavior of the source
2.Include: The source use case explicitly incorporate the behavior
of another use case
STANDARD ELEMENTS

The UML defines five standard stereotypes that apply to packages

1.Facade
2.Framework
3.Stub
4.Subsystem
5.System
The UML defines two standard stereotypes that apply to the
dependency relationships among objects and among classes
1.Instance of: specifies that the client object is an instance of the
supplier classifier
2.Instantiate: The client class creates instances of the supplier class
STANDARD ELEMENTS

There are two stereotypes related to objects that apply to messages and
transitions
1.became : Specifies that the client is the same object as the supplier
2.copy:Specifies that the client object is an exact but independent
copy of the supplier
There are four standard constraints that apply to generalization relationships
1.complete:All children in the generalization have been specified
in the model.
2.incomplete:Not all children in the generalization have been
specified and additional children are permitted.
3.disjoint:Objects of the parent may have no more than one of the
children as a type
4.overlapping:Objects of the parent may have more than one of
the children as a type
STANDARD ELEMENTS

There are stereotypes when modeling interaction among objects.

1.became:The target is the same object as the source
2.call:The source operation invokes the target operation
3.copy: The target object is an exact

One stereo type in the context of the state machine is

Send: The source operation sends the target event
There are two stereotypes that apply to dependency among packages
1.Access:the source package is granted the right to reference the
elements of the target package
2.Import:
OBJECT DIAGRAM

An object diagram is a diagram that shows a set of objects and the ir

relationships at a point in time.
Graphically, an object diagram is a collection of vertices and arcs.
Contents

Object diagrams commonly contains

Objects
Links

assign(development)
p:Person :Company

Link Anonymous
Named Object Object
OBJECT DIAGRAM

Named Instance t:Transaction

Anonymous Instance
:Multimedia

Orphan Instance
agent:
OBJECT DIAGRAM
customer Bank
First name : String
Last name : string ATM Machine
Card number : string Address : string
Pin number : String State : string
Account : Account

Verify password()
Has 1
Account
number : string Transaction
balance : float TransID : String
bankClient : BankClient TransDate : Date
1,2 transaction : Transaction * TransTime : Time
TransType : string
deposit() 1 Amount : string
withdraw() PostBalance : float
retriveAccount() account : Account
updateAccount()
createTransaction()

CheckingAccount
SavingsAccount
savings : Account
checking : Account
withdraw() 1 1
INTRODUCTION TO USECASES

⚫ UseCase:
– A use case is a description of a set of sequences of actions,
including variants that a system performs to yield an observable
result of value to an actor.

– A use case represents a functional requirement of your system as

a whole.

– A use case involves the interaction of actors and the system.

– Graphically, a use case is rendered as an ellipse.

INTRODUCTION TO USECASES

Terms And Concepts:

⚫ Name:
– Every use case must have a name that distinguishes it from other
use cases.
– A name is a textual string.
– A use case is drawn showing only its name.
– E.g.
verify password select account
⚫ Actor:
– An actor represents a coherent set of roles that users of use
cases play when interacting with these use cases.
– Actors are rendered as stick figures.

client ATM machine Bank

USECASE DIAGRAMS

A use case diagram is a diagram that shows a set of use cases and actors
and their relationships
⚫ Common Properties:
– A use case diagram is just a special kind of diagram and shares
the same common properties as do all other diagrams—a name
and graphical contents that are a projection into a model.
– You can apply use case diagrams to illustrate the static use case
view of a system,
– They are important in organizing and modeling the behaviors of a
system.
USECASE DIAGRAMS

⚫ Contents:
– Use case diagrams commonly contain
– Use Cases
– Actors
– Dependency ,generalization, and association relationships
– Use case diagrams may also contain notes and constraints.
– Use case diagrams may also contain packages, which are used to
group elements of your model into larger chunks.
⚫ Common Uses:
– To model the context of the system
– To model the requirements of a system
USECASE DIAGRAMS

Basic Use Of Use Case Diagrams Symbols And Notations:

⚫ System:
– Draw your system’s boundaries using rectangle that contains use
cases. Place actors outside the system’s boundaries.
⚫ Use Case:
– Draw use case 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.
USECASE DIAGRAMS

Example Of Use Case:

<<include>>
Bank ATM Approval
transaction process

<<extend>>
<<extend>> <<extend>>
Checking
transition
history Invalid
PIN
Client
<<extend>>
<<extend>>

Withdraw
Deposit amount
saving transaction amount
history
ACTIVITY DIAGRAM

⚫ Introduction:
– Activity diagrams are one of the five diagrams in the UML for
modeling the dynamic aspects of systems.
– An activity diagram is essentially a flowchart, showing the flow of
control from activity to activity.
– You use activity diagrams to model the dynamic aspects of a
system. For most part, this involves modeling the sequential steps
in a computational process.
ACTIVITY DIAGRAM

⚫ Definition:
– An activity diagram shows the flow from activity to activity.
– An activity is an ongoing non atomic execution within a state machine.
– Graphically an activity diagram is a collection of vertices and arcs
⚫ Common Properties:
– An activity diagram is just a special kind of diagram and shares the
same common properties, as do all other diagrams a name and
graphical contents that are a projection into a model.
– What distinguishes an interaction diagram from all other kinds of
diagrams is its content.
ACTIVITY DIAGRAM
⚫ Contents:
– Activity diagram commonly contain
– Activity state and action states
– Transitions
– Objects
⚫ Action States:
– In the flow of control modeled by an activity diagram we call
an operation on an object, send a signal to an object, or even
create or destroy and object. These executable, atomic
computations are called action states because they are
states of the system, each representing the execution of an
action.
– Graphically, it is rendered as a rectangle with rounded
corners

insert a card
ACTIVITY DIAGRAM

⚫ Activity States:
– Activity states are not atomic, meaning that they may be
interrupted and, in general, are consider to take some
duration to complete.
– Action state is a special case of an activity state.
– Action state is an activity state that can not be further
decomposed
Do construction()
Entry action
entry/ ^set lock()

Processbill(b)
Submachine
ACTIVITY DIAGRAM

⚫ Transition:
– An action or an activity of a state completes, flow of control
passes immediately to the next action or activity state. You
specify this flow by using transitions to show the path from
one action or activity state to next action or activity state.
– Graphically, it is represented as a simple directed line.

Activity2
transition

Activity1
ACTIVITY DIAGRAM

⚫ Branching:
– We can include a branch which specifies alternate paths
taken based on some Boolean expression.
– A branch may have one incoming transition and two or more
outgoing ones. On each outgoing transition, you place a
Boolean expression, which is evaluated only once on
entering the branch.
– Graphically, a branch is represented as a diamond. .

Decision box
ACTIVITY DIAGRAM

⚫ Fork And Join:

– A fork represents the splitting of a single flow of control into
two or more concurrent flows of control.
– A fork may have one incoming transition and two or more
outgoing transitions, each of which represents an
independent flow of control.
– A Join represents the synchronization of two or more
concurrent flows of control.
– A Join may have two or more incoming transitions and one
outgoing transition
ACTIVITY DIAGRAM

⚫ An Example Of Join And Fork:

activity1

fork

activity2 activity3

fork
activity4 activity5

join
ACTIVITY DIAGRAM

⚫ 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.

Start state Final state

ACTIVITY DIAGRAM

⚫ Example Of Activity Diagram:

Insert the card

Enter the
password

password not accepted

password accepted
Select type of
transaction

Perform the
transaction
more transactions

Take the card No more transactions

ACTIVITY DIAGRAM

⚫ SwimLanes:
– When you are modeling workflows of business processes, to
partition the activity states on an activity diagram into groups,
each group representing the business organization
responsible for those activities, swimlanes are useful.
– Each swimlane has a name unique within its diagram
⚫ Common Uses:
– To model a workflow
– To model an operation.
ACTIVITY DIAGRAM

⚫ Example Of Activity Diagram Using Swim Lanes:

BankClient Atm machine AccountTransaction

Collect Card

Insert ATM Card

Enter PIN
Number

Enter the Required

Amount

Chek the
Account

Withdraw
Process
Dispense the
money
Collect Amount
ACTIVITY DIAGRAM

⚫ Activity Diagram For Purchasing:

customer sales warehouse

request
product

process
order pull
materials

ship order

receive bill
order customer

paybill

close order
ACTIVITY DIAGRAM

⚫ Activity Diagram For Registration:

Create
curriculum

select courses
to teach

Assign professor
to courses

all
professor...

Create
catalogue

place catalogue in mail catalogue

book store to students

open
registration
ACTIVITY DIAGRAM

⚫ Example Of Activity Diagram : select site

commission
architect

develop
plan

bid plan

not accepted

do site work Do trade

work

finish
construction
INTERACTION DIAGRAM

⚫ Introduction:
– You use interactions to model the flow of control within an
operation, a class, a component, a use case, or a system as a
whole.
– Using interaction diagrams you can reason about these flows in
two ways
– First, you can focus on how messages are dispatched across
time.
– Second, you can focus on structural relationships among the
objects in an interaction and then consider how messages are
passed within the context of that structure.
INTERACTION DIAGRAM

⚫ Definition:
– An interaction is a behavior that comprises a set of messages
exchanged among a set of objects within the context to
accomplish a purpose. A message is a specification of
communication between objects that conveys information with
expectation that activity will ensue.
⚫ Interaction Diagram:
– An interaction diagram shows an interaction, consisting of set of
objects and their relationships, including the messages that may
be dispatched among them.
– It consists of two types
⚫ Sequence Diagram

⚫ Collaboration Diagrams
INTERACTION DIAGRAM

⚫ Content:
– Interaction diagrams commonly contain
⚫ Object
⚫ Links
⚫ Messages
– The objects that participate in an interaction are either concrete things or
prototypical things.
– A link is a semantic connection among objects. Whenever there is a link
between two objects, one object can send a message to the other object.
– A message is the specification of a communication among objects that
conveys information with the expectation that activity will ensue.
t:Transaction :Multimedia agent:

Named Instance anonymous Instance Orphan Instance

SEQUENCE DIAGRAM

⚫ Definition
– A sequence diagram is an interaction diagram that emphasizes the
time ordering of messages.
– Graphically, a sequence diagram is a table that shows objects
arranged along the x-axis and messages, ordered in increasing
time, along the y-axis.
– Typically, you place the object that initiates the interaction at the
left, and increasingly more subordinate objects to the right.
– Next, you place the messages that these objects send and receive
along the y-axis, in order of increasing time from top to bottom
– Sequence diagram gives the reader a clear visual cue to the flow
of control over time.
SEQUENCE DIAGRAM

⚫ Sequencing
– When an object passes a message to another object, the receiving
object might in turn send a message to another object, which
might send a message to yet a different object, and so on. This
stream of messages forms a sequence.

– There are two types of sequencing.

⚫ Procedural sequencing
⚫ Flat sequencing
SEQUENCE DIAGRAM

⚫ Procedural Sequencing
– Most commonly, you can specify a procedural or nested flow of
control, rendered using a filled solid arrowhead as in the following
– Eg:

1: liftHandset 1.1:assertcall
c:caller :Telephone :Exchange
SEQUENCE DIAGRAM

⚫ Flat Sequencing
– Less common but also possible, as in the following example
shows, you can specify a flat flow of control, rendered using
a stick arrowhead, to model the nonprocedural progression of
control from step to step.

– Eg:

1: liftHandset 2: assertcall
c:caller :Telephone :Exchange
MESSAGE SYNCHRONIZATION

⚫ There are five synchronization options:

1.Simple 4.Timeout
2.Synchronous 5.Asynchronous
3.Balking
⚫ Simple:
– This is the default value for messages .This option specifies that the
message runs in a single thread of control.
Object1 object2

Simple
MESSAGE SYNCHRONIZATION

⚫ Synchronous :
– Use this option when the client sends the message and waits until the
supplier has acted upon the message

Object1 object2

Synchronous message
MESSAGE SYNCHRONIZATION

⚫ Balking:
– With this option the client sends the message to supplier and if the supplier
is not ready to accept the message the client abandons the message.

Object1 object2

Balking message
MESSAGE SYNCHRONIZATION

⚫ Timeout:
– Using this option the client sends the message to supplier and waits a for
specified amount of time .If the supplier isn’t ready to receive the message
in that time, the client abandons the message.

Object1 object2

TimeOut
MESSAGE SYNCHRONIZATION

⚫ Asynchronous:
– With this option the client sends the message to the supplier.The
client then continues processing without waiting to see if the
message was received or not.

Object1 object2

Asynchronous
MESSAGE FREQUENCY

⚫ Message frequency lets you mark a message that is sent at regular

intervals .You can set that message to be periodic.
⚫ There are two frequency options:
– Periodic: This option suggests that the message is sent on a regular
periodic basis.
– Aperiodic : This option suggests that the message is not sent on a
regular basis .It may be sent once or at irregular periodic basis.
SEQUENCE DIAGRAM

⚫ ATM TRANSACTIONS:
Bank client ATM machine Account Checking account
Insert ATM card
Request PIN
Enter PIN

Verify PIN

PIN ok
Request kind
Enter kind
Request amount
Enter amount
Process transaction
Withdraw Checking account

Transaction successful
Withdraw successful
Dispense cash
Request take cash

Take cash

Request confirmation

Terminate

Print receipt
SEQUENCE DIAGRAM

⚫ Telephone Call:
s:caller :switch c:conversation r:caller

lift receiver
setdial time()
dial digit

route call
ring()

receive call

connect (S)
connect (r,s)
connect (r)

caller rand s may

exchange
information after
both are connected
COLLABORATION DIAGRAMS

⚫ Definition:
– A Collaboration diagram is an interaction diagram that emphasizes
the structural organization of the objects that send and receive
messages.
– Graphically, a collaboration diagram is a collection of vertices and
arcs.
– You form a collaboration diagram by first placing the objects that
participate in the interaction as the vertices in a graph.
– Next, you render the links that connect these objects as the arcs of
this graph.
– Finally, you adorn these links with the messages that objects send
and receive..
COLLABORATION DIAGRAMS

⚫ Collaboration diagram gives the reader a clear visual cue to the flow
of control of the context of the structural organization of objects that
collaborate.
– Symbols :

Object:class

Message Association
Object
COLLABORATION DIAGRAMS

– Example
1: Insert ATM card
3: Enter PIN
7: Enter kind
9: Enter amount 4: Verify PIN
18: Terminate 10: Process transaction
Bank client ATM machine Account

5: PIN ok
13: Transaction successful
2: Request PIN 11: Withdraw Checking account
6: Request kind
8: Request amount 12: Withdraw successful
14: Dispense cash
15: Request take cash
16: Take cash
17: Request confirmation
19: Print receipt

Checking account

Common Uses:
–To model flows of control by time ordering
–To model flows of control by organization
COLLABORATION DIAGRAMS

4: route call

1: lift receiver
3: dial digit
s:caller :switch

2: setdial time()

8: connect (r,s)

9: connect (r)
5: ring()
7: connect (S)
c:conversation r:caller

6: receive call
SEQUENCE Vs. COLLABORATION

⚫ We use sequence diagrams in modeling a flow of control by

time ordering emphasizes the passing of messages as they
unfold over time.
⚫ Sequence diagrams do a better job of visualizing simple
interaction and branching than do collaboration diagrams.
⚫ We use collaboration diagrams in modeling a flow of control by
organization emphasizes the structural relationships among the
instances in the interaction.
⚫ Collaboration diagrams do a better job of visualizing complex
iteration and branching and of visualizing multiple concurrent
flows of control than do sequence diagrams.
STATE CHART DIAGRAM
⚫ Introduction
– State chart diagrams are one of the five diagrams in the UML for modeling
the dynamic aspects of systems.
– A state chart diagram shows a state machine.
– An activity diagram is a special case of a state chart diagram in which all or
most of the states are activity states and all or most of the transitions are
triggered by completion of activities in the source state.
– Thus, both activity and state chart diagrams are useful in modeling the
lifetime of an object.
– However, whereas an activity diagram shows flow of control from activity to
activity, a state chart diagram shows flow of control from state to state.
– For the most part, this involves modeling the behavior of reactive objects.

⚫ Definition:
– A state chart diagram shows a state machine, emphasizing the flow of
control from state to state.
STATE CHART DIAGRAM

⚫ State Machine
– A state machine is a behavior that specifies the
sequences of states an object goes through during its
lifetime in response to events, together with its
responses to those events.
⚫ State:
– A state is a condition or situation in the life of an object
during which it satisfies some condition, performs some
activity, or waits for some event.
state

⚫ Event:
– An event is the specification of a significant occurrence that
has a location in time and space.
state Event state1
STATE CHART DIAGRAM

⚫ Common Properties
– A state chart diagram is just a special kind of
diagram and shares the same common properties
as do all other diagrams—that is, a name and
graphical contents that are a projection into a
model.
– What distinguishes a state chart diagram from all
other kinds of diagrams is its content.
STATE CHART DIAGRAM

⚫ Contents:
– State chart diagrams commonly contain
⚫ Simple state and composite states
⚫ Transitions, including events and actions
– Transition
⚫ Transition is a relationship between two states indicating that
an object in the state will perform certain actions and enter the
second state when a specified event occurs and specified
conditions satisfied
– Action
⚫ An action is an executable atomic computation that results in a
change in state of model or the return of a value.
⚫ Common Uses:
– To model reactive objects.
– Graphically, a state chart diagram is a collection of vertices
and arcs.
STATE CHART DIAGRAM

⚫ Advanced states and transitions:

– The UML state machines have a number of
advanced features that help you to manage
complex behavioral models. These features often
reduce the number of states and transitions you
will need, and they codify a number of common
and somewhat complex idioms you would
otherwise encounter using flat state machines.
Some of the advanced features include entry and
exit actions, internal transitions, activities, and
deferred events.
STATE CHART DIAGRAM

⚫ State Transition Details

Add student
initialization
set cnt=10^course.create

Add student cnt<10 {Count=10}

closed
open

cancel
cancel
^course.delete
canceled
STATE CHART DIAGRAM

⚫ Example Of State Chart Diagram.

Idle
On hook

Off hook

Dial Tone time out time- out

On hook

digit(n)
time out
On hook Dialing Recorded
message

valid number
number busy
busy tone connecting

routed

On hook Ringing

messagedone

On hook connected

On hook Disconnect
STATE CHART DIAGRAM

⚫ Sub-states
– A sub-state is a state that is nested inside another one.
– A state that has sub-state i.e., nested state is called a
composite state.
– A composite state may contain either concurrent
(orthogonal) or sequential (disjoint) sub-states.
– In UML you render a composite state just as you do a
Simple State, but with an optional graphic compartment.
– Sub-states are two types
⚫ Sequential Sub-state
⚫ Concurrent Sub-state
STATE CHART DIAGRAM

⚫ Sequential Sub-states:
– Here validating, selecting, processing and pointing are sub-
states.
– Notice that the transition from the Active state to the idle
state is triggered by the event cancel.
Sequential SubState

Active

Card inserted
Idle Validating Processing

cancel
Maintain

Maintenance Selecting Printing

Transition from substate

Composite State
STATE CHART DIAGRAM
⚫ Concurrent Sub-states:
– These sub states let you specify two or more state machines that
execute in parallel in the context of the enclosing object.
– Execution of the two concurrent sub-states continues in parallel .
– Each nested state machine reaches its final state if one concurrent
sub-state reaches its final state before the other .
– When both nested state machines reach their final state, control
from the two concurrent sub-states joins back into one flow.
– If all concurrent sub-states reach their final state or if there is an
– explicit transition out of the enclosing composite state, control joins
back into one flow.
– A Nested Concurrent state machine does not have an Initial, Final
or History state.
– A Nested Sequential state machine may have at most one Initial
and one Final state.
STATE CHART DIAGRAM

⚫ Concurrent Sub-states:
Join Idle Fork
Composite State

Maintain
Maintenance

Testing

Testing Self
devices diagnosis
Commanding
Waiting Command

Key process

Concurrent SubState
STATE CHART DIAGRAM

⚫ Concurrent Sub-states:
– When a transition enters a composite state the action of the
nested state machine starts over again at its initial state.
– There are times you like to model an object so that it
remembers the last sub-state that was active prior to leaving
the composite state.
– The symbol ‘H’ designates a shallow history which remembers
only the history of the immediate nested state machine.
– You can also specify Deep history with the shown symbol ‘H’
– Shallow history remembers only the outer most nested state;
– Deep History remembers the innermost nested state at any
depth
STATE CHART DIAGRAM

⚫ History States:
– A state machine describes the dynamic aspects of an object
whose current behavior depends on its past. In uml a history
state allows a composite state that contains sequential sub-
states to remember the last sub-state that was active in its
prior to the transition from the composite state.
Initial State For First Entry

Command Backing Up
H Collecting

Query
Copying

Cleaning up

Shallow History State

COMPONENT DIAGRAM

⚫ Introduction
– Component diagrams are one of the two kinds of diagrams
found in modeling the physical aspects of object-oriented
systems.
– A component diagram shows the organization and
dependencies among a set of components.
– You use component diagrams to model the static
implementation view of a system.
– Component diagrams are not only important for
visualizing, specifying, and documenting through forward
and reverse engineering
COMPONENT DIAGRAM

⚫ Definition
– A Component diagram shows a set of
components and their relationships.
– A component is a physical and replaceable part
of a system that conforms to and provides the
realization of a set of interfaces.
– Graphically, a component is rendered as a
rectangle with tabs.
– E.g.
component
symbol
COMPONENT DIAGRAM
⚫ Common Properties
– A component diagram is just a special kind of diagram and shares the
same common properties as do all other diagrams—a name and graphical
contents that are a projection into a model.
– What distinguishes a component diagram from all other kinds of diagrams
is its particular content
⚫ Content
– Component diagrams commonly contain:
⚫ Components
⚫ Interfaces
⚫ Dependency,
⚫ generalization,
⚫ association, and
⚫ realization relationships
– Like other diagrams, component diagrams may contain notes and
constraints.
– Component diagrams may also contain packages or subsystems, both of
which are used to group elements of your model into larger chunks.
COMPONENT DIAGRAM

⚫ Common Uses:
– To model source code
– To model executable releases
– To model physical databases
– To model adaptable systems
⚫ Components are of three types:
– Deployment Components
– Work Product Components
– Execution Components
COMPONENT DIAGRAM

⚫ Deployment Components:
– There components are necessary to form an executable
system ,like Dynamic Libraries (DLL’s) and Executables
(.exe) and covers all the Object models like WebPages,
Tables and Executables.
⚫ Work Product Components
– These components are residue of the development process
processing things like source code files and data files from
which deployment components are created
⚫ Execution Components
– These components are created as a result of an executing
system such as COM+ object which is instantiated from a
DLL.
COMPONENT DIAGRAM
⚫ There are five standard stereotypes applicable to
components:
⚫ executable: indicates that a component can be executed on a
code.
⚫ library: static or dynamic object library.
⚫ table: component representing a database table .
⚫ file: Indicates a component that represents a document containing
source or data.
⚫ document: Specifies a component that represents a document.
– Eg: Animation
.
exe
log.dll

Render.dll wframe.dll

retrace.dll
COMPONENT DIAGRAM
COMPONENT DIAGRAM

Executable

Find.html

Find.exe

Page
Library

Index.html
Nateng.dll
Dbscs.dll
COMPONENT DIAGRAM

•Modeling Source Code

Signal.h Signal.h Signal.h
{version=4.1}
{version=3.5} {version=4.0}

<<parent>> <<parent>>

signal.cpp
Interp.cpp

irq.h
device.cpp
COMPONENT DIAGRAM
⚫ Subsystems
– We introduce the notion of a subsystem for module diagrams,
which parallel role played by the class category for class
diagrams. Subsystems represent clusters of logically related
modules.
– A subsystem can have dependencies upon other subsystems
modules and a module can have dependencies upon
subsystem.
– A large system has top level module diagram consisting of the
subsystem at the highest level of abstraction.
⚫ Systems And Subsystems <<system>>
Retail Enterprise
System

<<subsystem>> << subsystem>> <<subsystem>>

Customer Service In Store Management Warehouse Management
subsystem subsystem subsystem
MODULE DIAGRAM

⚫ A module diagram is used to show the allocation of classes

and objects to module in the physical design of a system. A
single module diagram represents a view of the module
structure of the system. Certain languages, most notably
Smalltalk, have no concept of physical architecture formed of
modules, in such cases module diagrams are unnecessary.
name Name subprogram specification
name

Main program specification body

subprogram body

Task Specification Task Body

MODULE DIAGRAM

⚫ Types Of Components
– Subprogram specification and body:
⚫ A subprogram is typically a collection of subroutines.
Subprogram do not contain class definitions

SubprogSpecification SubprogBody

– Main Program:
⚫ A main program is the file that contains the root of a program
MainProgram
MODULE DIAGRAM

– Package specification and body::

⚫ A package is the implementation of a class. A package
specification is a header file ,which contains function
prototype information for the class.
⚫ Eg:- In c++, .h files
– A package contains the code for the operations of the class.
⚫ Eg: In c++,package bodies are the .cpp files.
– In java, .java files

Package Specification Package Body

MODULE DIAGRAM

– Task Specification And Body:

⚫ To represent package that have independent threads of
control.
⚫ Eg: An executable file is commonly represented as a task
specification with .exe extension

Task Specification Task Body

MODULE DIAGRAM

⚫ Each module encompasses the declaration or definition of classes,

objects and other language details. we can form in to a module to
see the physical contents of its corresponding file.
⚫ Specification module denote n files and body modules denote .cpp
files.
⚫ A name is required for each module, this name typically denotes the
simple name of the corresponding physical file in the development
directory.
⚫ The main program icon denotes a file that contains the note of a
program.
⚫ The specification icon and the body icon denote files that contain
the declaration and definition of entities.
– Dependencies:
⚫ The only Relationship we may have between two modules is a
compilation dependency represented by directed line pointing to the
module upon which the dependency exits.
MODULE DIAGRAM
Plans cropdefs

cooler
climate

heat Climate defs

MODULE DIAGRAM

Component Diagram For ATM

ATM.exe

Cash Dispenser
Card Reader

ATM Screen
Card Reader

Cash Dispenser

ATM Screen
MODULE DIAGRAM

Modeling Tables,Files,Documents

animator.hlp

ANIMATOR.EXE
dlog.dll

animator.ini

render.dll wrframe.dll

raytrace.dll
shapes.tbl
MODULE DIAGRAM

Modeling Physical Database

school.db

course department instructor school student

MODULE DIAGRAM

Modeling Database System

The school database in
server B replicates the
data base in server A

{location=server A} {location=server B}

<<copy>>

School.db School.db
DEPLOYMENT DIAGRAM

⚫ Introduction
– Deployment diagram are one of the two kinds of diagrams
used in modeling the physical aspects of an object-oriented
system.
– A deployment diagram shows the configuration of run time
processing Nodes and the components that live on them.
– You use deployment diagrams to model the static
deployment view of a system.
– For the most part, this involves modeling the topology of the
hardware on which your system executes.
– Deployment diagrams are essentially class diagrams that
focus on a system’s nodes.
– Deployment diagrams are not only important for visualizing,
specifying, and documenting embedded, client/server,
distributed systems, but also for managing executable
systems through forward and reverse engineering
DEPLOYMENT DIAGRAM
⚫ Definition
– A deployment diagram is a diagram that shows the configuration of
run time processing nodes and the components that live on them
⚫ Node
– A node is a physical element that exists at run time and represents
a computational resource, generally having at least some memory
and, often processing, capability.
– Graphically, a node is rendered as a cube.
– Every node must have a name that distinguishes it from other
nodes.
– A name is a textual string. A node is typically drawn showing only
its name
node symbol
processor
symbol
DEPLOYMENT DIAGRAM
⚫ Common Properties
– A deployment diagram is just a special kind of diagram and shares the same common
properties as all other diagrams—a name and graphical contents that are a projection
into a model.
– What distinguishes a deployment diagram from all other kinds of diagrams is its
particular content
⚫ Content
– Deployment diagrams commonly contain
⚫ Nodes
⚫ Dependency and
⚫ Association relationships
– Like other diagrams, deployment diagrams may contain notes and constraints.
– Deployment diagrams may also contain components, each of which must live on some
node.
– Deployment may also contain packages or subsystems, both of which are used to
group elements of your model into larger chunks.
⚫ Common Uses
– To model embedded systems
– To model client/server systems
– To model fully distributed systems
DEPLOYMENT DIAGRAM

Caching
server caching
server

Local Network

server
Printing Server
server
DEPLOYMENT DIAGRAM

Example:
Banking
Database
server

Regional
Printer
ATM Server

ATM stn1 ATM stn2

Work flows
 THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Software Development Process:

– A process defines who is doing what, when and
how to reach a certain goal. In Software
Engineering the goal is to build a software product
to enhance an existing one.
– An effective process provides guidelines for the
efficient development of quality software.
– We need such a process to serve as a guide for
all the participants customers ,users developers
and executive managers.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ History Of The Unified Process:

– Its development as a product follows a path from the
objectory process (in 1987) via the Rational Objectory
Process (in 1997) to the Rational Unified Process(1998)..
Rational Unified Process

Rational Objectory Process

Objectory Process

The Ericsson Approach

THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Rational Unified Process:

– A process is a set of partially ordered steps internal to reach a
goal.
– The UML is largely process independent meaning that you can
use it with a number of software Engineering processes.
– The Rational Unified Process is one such life cycle approach that
is especially well-suited to the UML.
– The goal of the RUP is to enable the Production of highest quality
software that meets end-user needs within predictable schedules
and budgets.
– The RUP provides a displined approach an how to assign tasks
and responsibilities within a software development
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Characteristics of the process:

– The rational Unified Process is an iterative process.
– The RUP activities emphasize the creation and maintenance of
models rather than paper documents.
– The process focuses on the early development and baselioning of
a software architecture.
– Development activities under the Rational Unified Process are
use case driven .
– The RUP supports Object Oriented techniques.
– The RUP is a configurable Process.
– The RUP encourages objective ongoing quality control and risk
management
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The Process Workflows

– The RUP consists of nine process workflows
⚫ Business modeling –Describes the structure and dynamics of
the organization.
⚫ Requirements- Describes the use case-based method for
eliciting requirements.
⚫ Analysis and design – Describes the multiple architectural
views.
⚫ Implementation – Takes into account software
development,unit test and integration.
⚫ Test- Describes the test cases,procedures and defect –
tracking metrics
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ .Deployment-Covers the deliverable system configuration.

⚫ .Configuration management-Controls changes to and
maintains the integrity of a projects artifacts.
⚫ .Project Management-Describes various strategies of working
with an iterative process.
⚫ .Environment- Covers the necessary infrastructure required to
develop a system.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The Core Workflow

– Requirements Capture
⚫ The term core workflow is an abstraction .It is the process of
finding out, usually under difficult circumstances, what is to
built.
⚫ The essential purpose of the requirements workflow is to aim
development toward the right system.
⚫ This is achieved by describing the system requirements well
enough so that an agreement can be reached between the
customer and the system developers on what the system
should and should not do.
⚫ A major challenge with this is the customer, who we assume
to be a non computer specialist, must be able to read and
understand the results of requirements capture.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The workflow include the following steps

– List the candidate requirements
– Understand system context
– Capture functional requirements
– Capture non functional requirements.
⚫ List candidate requirements:
– During the life of a system, customers, users, analysts and
developers come up with many good ideas that might turn into
real requirements.
⚫ Capturing the requirements as use cases
– Functional requirements are naturally structured as use cases and
since most of the others nonfunctional requirements are specific
to a single use case.
– The remaining nonfunctional requirements those that are known
as the supplementary requirements
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Workers and artifacts involved in requirement phase

System Use case User interface

analyst specifier designer Architect

Glossary
Architecture
description
Use Case User interface prototype
use case model
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ work flow for capturing requirements of use cases

System analyst
find actors and structure the
use cases use case model

Architect
priorities use case

Use case specifier

Detail use case

User interface designer

prototype user
interface
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Capturing the Use Cases:-

– The use case model helps the customer, users and
developers agree on how to use the system.
– The use case model represents the functional requirements
– Actors are the environment if the system
– Analysis, design and implementation to realize the use
cases
– They specify the system.
– During analysis and design, we transform the use case
model via an analysis model into a design model.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Identifying the actors and use cases

THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Analysis
– In analysis we analyze the requirements as described in
requirements capture by refining and structuring them.
– The purpose of analysis is to achieve a more precise
understanding of the requirements and to achieve a
description of requirements
⚫ Use case must be kept as independent of each other as
possible.
⚫ Use case must be described using the language of the
customer
⚫ Each use case must be structured to form a complete and
intuitive specification of functionality.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Creating the analysis model from the use cases:-

– The analysis model grows incrementally as more and more
use cases are analyzed for each iteration, we select a set
of use cases that we realize in the analysis model.
Use case model Analysis model

withdraw money
withdrawmoney

account
Dispenser

cashier withdrawal
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The relationship of a use case in the analysis model:

– In the analysis model the different stereotypes on classes are
used
⚫ .<<boundary class>>
⚫ <<control class>>
⚫ <<Entity class>>.
– In the above example the dispenser & cashier interfaces are
boundary classes that in general are used to model interaction
between the systems and actors.
– Account is an entity class. withdrawal is the control class.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The workers and artifacts involved in analysis:

Use case engineer Component engineer

Architect

Analysis
Architecture package
description use case realization Analysis class

Analysis model
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Workflow of analysis:
– The purpose of the architectural analysis is to out line the analysis
model and the architecture by identifying analysis package.
Architect
Architectural Analysis

Use Case
Engineer

Analyze a use case

Component
Engineer
Analyze a class Analyze a package
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Design :
– In design we shape the system and find its form that lives up to
all requirements including all nonfunctional requirements and
other constraints made on it.
– Design is in focus during the end of elaboration and the
beginning of construction iteration.
⚫ Workers and artifacts involved in design
Use- case Component engineer
Architect
engineer

Interface
Design
model
Design class
Deployment Architecture Design
use case realization
- design
description subsystem
model
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The input and result of designing a class:

Component engineer

use case realization

- design

Design class
Design class

design a class

Interface
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The work flow in design:

Architect

architectural design

Use case engineer

design a use case

Component engineer

design a subsystem

design a class
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Implementation:
– In implementation we start with the result from design and
implement the system in terms of components, that is source
code scripts binaries executables.
– Implementation is the focus during the construction iterations.
– The implementation model denote the actual implementation
of the system in terms of components.
– The implementation model describes how the components are
organized according to the structuring and modularization
mechanisms available in the implementation environment and
the programming language in use and how the components
depend on each other.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Workers:
– Architect:- The architect is responsible for the integrity of the
implementation model and ensures that the model as a whole is
correct, consistent and readable.
– Component Engineer:- He defines and maintains the source code
a several file consonants making sure that each component
implements the correct functioning.
– System Integrator:- This includes planning the sequence of builds
required in each iteration and integrating each build when its parts
have been implemented.
Component engineer
System integrator

Architect

Compo
Architecture nent
Architecture
description description Interface
Implementation
Deployment
model subsystem
model
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The input and result of implementing a class :

Component engineer
Design class

Compo
nent

Implement a class
Interface
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The input and result of architectural implementation :

Architect

Design model Compo

nent

Deployment
model

Architectural Architecture
Implementation description
Architecture
description
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The input and result of a System Integration:

supplementary
requirements

System integrator

use case
model
Integration
Build plan

Design
model

Integrate system

Implementation
model
Implementation
model
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Workflow for implementation:

Architect Architectural
Implementation

System integrator

Integrate system

Component engineer
Implement a class

Implement a subsystem Perform unit test

THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Testing:
– Plan the test required in iteration including iteration testing
and system testing.
– Design and implement the tests by creating test cases that
specify what to test creating test procedures.
– Perform the various tests and systematically handle the
result of each test.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The workers and artifacts involved in testing:

Component
Test engineer
engineer
Integration tester System tester

test test test plan test

procedure evaluation component
test model test case

Defect
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Integration tester:-
– Integration testers are responsible for performing the integration
tests that are required for each build produced in the
implementation workflow.
⚫ Test Engineer :-
– He is responsible for the integrity of the test model, ensuring that
the model fulfill its purpose
⚫ Component Engineer:-
– He is responsible for test components that automate some of the
test procedures
⚫ System Tester:-
– A system tester is responsible for performing the system tests
required for a build manifesting the result of a complete iteration.
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ The Input and result of design test:-

supplementary
requirements Test engineer

use case
model

Analysis
model

Design test case

model

Implementation
model test
procedure

Architecture
description

test plan
THE UNIFIED SOFTWARE
DEVELOPMENT PROCESS

⚫ Workflow for testing:-

Test engineer

evaluation test
plan test Design test

Integretation tester
Perform integration test

System tester

Perform system test

Component engineer

Implement a test