Object Oriented analysis

and design with UML

 Why Model ?
Analyse the problem-domain
simplify reality
capture requirements
visualize the system in its entirety
specify the structure and/or behaviour
of the system

Design the solution

document the solution - in terms of its
structure, behaviour, etc.
 Principles of Modeling
Choose your model well - the choice of model
profoundly impacts the analysis of the problem and the design of
the solution.

Every model may be expressed at

different levels of precision - the same model
can be scaled up (or down) to different granularities.

The best models are connected to reality -

simplify the model, but dont hide important details.

No single model suffices - every nontrivial system

has different dimensions to the problem and its solution.
 What is UML ?
UML - Unified Modeling language
UML is a modeling language, not a
methodology or process
Developed by Grady Booch, James
Rumbaugh and Ivar Jacobson at Rational
Software.
Accepted as a standard by the Object
Management Group (OMG), in 1997.
 More on UML...
UML is a modeling language for visualizing,
specifying, constructing and documenting
the artifacts of software systems.

Visualizing - a picture is worth a thousand words;

a graphical notation unambiguously communicates the
overall view of the system (problem-domain).
 More on UML...
Specifying - UML provides the means to
model precisely, unambiguously and completely,
the system in question.

Constructing - models built with UML have a

design dimension to it; these are language
independent and can be implemented in any
programming language.
 More on UML...
Documenting - every software
project involves a lot of documentation -
from the inception phase to the
deliverables.

Documentation is UML provides the

(among others) for: notations for documenting
some of these artifacts
Requirements
Design
Tests
 UML Usage: Overview
The UML may be used to:
Represent the Elements of a system or a
domain and their Relationships in a Static
Structure using class and object diagrams
Model the Behavior of objects with state
transition diagrams
Reveal the Physical Implementation
Architecture with component & deployment
diagrams
Display the Boundary of a System & its major
Functions using use cases and actors
Illustrate Use Case Realizations with
interaction diagrams
 Where UML can be used?
UML is intended primarily for software-
intensive systems like,
Enterprise information systems
Banking and financial services
Telecommunication
Transportation
Defense/aerospace
Retail
Medical electronics
Scientific
Distributed web-based services
 Where UML can be used?
The UML is not limited to modeling
software. In fact, it is expressive
enough to model nonsoftware systems,
such as workflow in the legal system.
The Conceptual model of UML
This requires learning 3 major elements:
The UMLs basic building blocks
The rules that dictate how those
building blocks may be put together.
And some common mechanism
 UML Building Blocks
Things
Diagrams
Structural Class Diagram
Behavioral Object Diagram
Grouping Use Case Diagram
Annotational Behaviour Diagram
Implementation Diagram
Relationships
Dependency
Association
Generalisation
Realization
 Things in UML
(1) Structural things.
Structural things are nouns of UML models.
These are mostly static parts of a model which
represents either conceptual or physical.
There are 7 kinds of structural things
Class
Interface
Collaboration diagram
Use case
Active class
Component
node
 Structural things: class
Class: class is a description of a set of objects that
share the same attributes, operations,
relationships and semantics.

Class is represented by rectangle with its name ,

attributes and operations
Notation: Login_master Window

User name Height

password width

Login() Open()
Logout() Close()
Move()
Structural things: Interface

An interface is a collection of operations that

specify a service of a class or component.

Notation:
Isensor

An Interface is graphically denoted by a circle

together by its name.
Structural things: Collaboration
Collaboration:
a collection of UML building blocks (classes, interfaces,
relationships) that work together to provide some
functionality within the system.
Graphically, it is denoted by ellipse with dashed lines,
usually including only its name.
Notation:
Accounts
System

Collaboration defines an interaction and a society

of roles and other elements that work together
to provide some cooperative behavior.
 Structural things: Use case
Use case:
A use case is a description of set of sequence of
actions that a system performs.

Use case is denoted by an ellipse with solid lines,

usually including only by its name.

Notation: Process
Order
 Structural things: active class
Active class:
An active class is a class whose objects own one or
more processes or threads and therefore can
intimate control activity.
When an active object is created, the associated flow of
control is started. When the active object is destroyed,
the associated flow of control is terminated.
Graphically, an active class is rendered just like a
class, but with heavy lines, usually including its
names, attributes, and operations.
Event Manager

Suspend()
Flush()
 Structural things: Component
Component:
A component is a physical and replaceable part of a
system that conforms to and provides the
realization of a set of interfaces.

Notation: DML_Parser.C

java beans is a kind of component.

Graphically, a component is rendered as a rectangle

with tabs, usually including only its name.
 Structural things: Node
Node:
A node is a physical element that exist at run time
and represents a computational resource.
Graphically a node is rendered as a cube, usually
including only its name.

PrintServer
Notation:
 Behavioral things
Behavioral things are the dynamic parts of UML
models. It represents the behavior of the
system.

There are 2 primary kinds of behavior things:

(1) An Interaction
(2) A state machine
Behavioral things: Interaction
An Interaction:
Is a behavior that comprises a set of messages
exchanged among a set of objects within a
particular context to accomplish a specific
purpose.

Graphically, a message is rendered as a directed

line, including the name of its operation.
display
Notation:
Behavioral things: State machine
Is a behavior that specifies the sequences of states an
object goes through during its lifetime.

A state is a condition or situation during the lifetime of

an object during which it exhibits certain characteristics
and/or performs some function.

Graphically, a state is rendered as a rounded rectangle

including its name.

Waiting
Behavioral things: State machine
A state machine involves a number of other
elements, including
States
Transitions( the flow from state to state)
Events(things that trigger a transition)
Activities(the response to a transition)
 Grouping things: Package
Grouping things are the organizational part of UML
models.
Package is a general purpose mechanism for
organizing elements into groups. Structural
things, behavioral things may be placed in a
package.

Accounts
Department
 Annotation things: Note
Annotational things are the explanatory parts of
UML.
Comments can be applied to describe any element
in a model
Remark about any element in a model
There is one primary kind of annotational thing,
called a note. A note is simply a symbol for
rendering constraints and comments for an
element.
Graphically, a note is rendered as a
Parses user-query and builds rectangle with a dog-eared corner
expression stack (or invokes with comment.
ErrorHandler)
 Relationships in UML
There are 4 kinds of relationships
(1) Dependency
(2) Association
(3) Generalization
(4) Realization
 Relationships: Dependency
Dependency:
a semantic relationship where a change in one thing (the
independent thing) causes a change in the semantics of
the other thing (the dependent thing).

Notation:
(arrow-head points to the independent thing)
 Relationships: association
association:
a structural relationship that describes the connection
between two things.
1..*
Notation:
Employer Employee

Graphically, an association is denoted by solid line.

Aggregation is a special type of association,

representing a structural relationship between a
whole and its parts.
 Relationships: Generalization
a relationship between a general thing (called parent or
superclass) and a more specific kind of that thing
(called the child or subclass), such that the latter
can substitute the former.
Graphically, it is denoted by a solid line with a hollow
arrowhead pointing to a parent.

Notation:
(arrow-head points to the superclass)
 Relationships: Realization
a semantic relationship between two things wherein one
specifies the behaviour to be carried out, and the other
carries out the behaviour.
Notation:
(arrow-head points to the thing being realized)
 diagrams in UML
The graphical presentation of the model. Represented as a
connected graph - vertices (things) connected by arcs
(relationships).

Class Diagram Statechart Diagram

Object Diagram Activity Diagram
Use Case Diagram Component
Sequence Diagram Diagram
Collaboration Deployment
Diagram Diagram
 diagrams in UML
Class Diagram - the most common diagram found
in OOAD, shows a set of classes, interfaces,
collaborations and their relationships. Models the
static view of the system.
Object Diagram- shows the set of objects and
their relationships.
Use case diagram- shows a set of Use Cases
(sets of functionality performed by the system), the
actors (typically, people/systems that interact
with this system[problem-domain]) and their
relationships. Models WHAT the system is expected
to do.
 diagrams in UML
Sequence Diagram - models the flow of control
by time-ordering; depicts the interaction between
various objects by of messages passed, with a
temporal dimension to it.
Collaboration Diagram - models the interaction
between objects, without the temporal dimension;
merely depicts the messages passed between
objects.
Statechart Diagram - shows the different state
machines and the events that leads to each of these
state machines. Statechart diagrams show the flow
of control from state to state.
 diagrams in UML
Activity Diagram - shows the flow from activity
to activity; an activity is an ongoing non-atomic
execution within a state machine.
Component Diagram - shows the physical
packaging of software in terms of components and
the dependencies between them.
Deployment Diagram - shows the configuration
of the processing nodes at run-time and the
components that live on them.
 Architecture of system(software)
The architecture of a software intensive system can
best be described by five views.

Implementation
Design view view

Use case
view
Process
view Deployment
view

Systems architecture
 Architecture of system(software)
The use case view of a system encompasses the use
cases that describe the behavior of the system. the
static aspect of this view is captured in use case
diagram and dynamic view is captured in
interaction, statechart and activity diagram.

The design view of a system encompasses the

classes, interfaces, and collaborations. It supports
the functional requirements of the system.
 Architecture of system(software)
The process view of a system encompasses the
threads and processes that form the systems
concurrency and synchronization mechanism.
The implementation view of a system encompasses
the components and files that are used to assemble
and release the physical system.
Deployment view of a system encompasses the
nodes that form the systems hardware topology on
which the system executes. It addresses the
distribution, delivery and installation of the parts
that make up the physical system.
 Software Development Life Cycle
UML is process independent means it is not tied to
any particular software development life cycle.
To get the most benefit from UML one should
consider process,
Use case driven(usecases are used for establishing
the desired behavior of the system.)
Architecture-centric( Systems architecture is used)
Iterative and incremental.(managing stream of
executable releases.)
 Software Development Life Cycle
This use case, architecture-centric, and
iterative/incremental process can be broken into
phases.
A phase is the span of time between two major
milestones of the process.

There are 4 phases in the software development life

cycle: Inception
elaboration
construction
Transition
 Software Development Life Cycle
Inception:
inception is the first phase of the process, when
the seed idea for the development is brought up to
the point of being entered into the elaboration
phase.

Elaboration:
It is the second phase of the process, when the
product vision and its architecture are defined.
In this phase, the systems requirements are defined
and arranged by certain criteria.
 Software Development Life Cycle
Construction:
it is the third phase of the process, when the
software is actually constructed and being ready for
transitioning to user community. Here also the
systems requirements and evaluation criteria are
constantly reexamined against business needs.
Transition:
It is the fourth phase of the process, when the software
is turned into the hands of user community. Even
during this period, the system is continuously
improved, bugs are rectified and features that were
not there in earlier release are added
 Common mechanisms in UML
4 common mechanism that apply consistently through
out the language.
Specifications
Adornments
Common divisions
Extensibility mechanisms
 Common mechanisms in UML
Specifications:
UML is more than graphical language. Behind every
part of its graphical notation there is a specification
that provides a textual statement of the syntax and
semantics of the building block.
For ex.
Behind a class icon is a specification that provides the
full set of attributes, operations and behaviors that
class renders.
 Common mechanisms in UML
Adornments:
Most elements in the UML have a unique and direct graphical
notation that provides a visual representation of the most
important aspects of the element.
Ex. The class notation exposes the most important aspects of
a class, namely its name, attributes and operations. It can
include other details like, visibility of its attributes and
operations Transaction

+ public
# protected
- private +execute()
+rollback()
#priority()
-timestamp()
 Common mechanisms in UML
Common divisions:
In modeling object-oriented systems, the world often
gets divided in at least a couple of ways.
First, there is a division of class and object

customer
Jan:Customer
Name
Address
phone :Customer

Elyse
 Common mechanisms in UML
Common divisions:
Second, there is a separation of interface and
implementation.
spellingwizard.dll

IUnkown

ISpelling

Interfaces and implementation

 Common mechanisms in UML
Extensibility mechanisms:
UML is opened-ended so it makes possible for you to
extend the language in controlled ways. The UMLs
extensibility mechanisms include,

Stereotypes
Tagged values
constraints
 Common mechanisms in UML
Stereotypes:
A stereotype extends the vocabulary of the UML,
allowing you to create new kinds of building blocks
that are derived from existing ones but that are
specific to your problem.
Ex. If you are working in a programming language, such as java or
C++, you will often want to model exceptions.
EventQueue
{Version=3.2
Author=abc}
Exception
overflow -------------------

Add()
Remove()
Flush()
 Common mechanisms in UML
Tagged value:
It allows you to create new information in the
specification of element.
Ex.
If a product(software) has many releases over time,
you often want to track the version and author of
that version. EventQueue
{Version=3.2
Author=abc}

Add()
Remove()
Flush()
 Common mechanisms in UML
Constraints:
A constraint extends the semantics of a UML building
block, allowing you to add new rules or modify
existing ones. For ex. you might want to constrain
the EventQueue class so that additions are done in
order.
EventQueue
{Version=3.2
Author=abc}
Exception
overflow -------------------

Add()--------------------{ordered}
Remove()
Flush()