OBJECT ORIENTED ANALYSIS AND DESIGN

(UNIFIED MODELING LANGUAGE)

OBJECT ORIENTED ANALYSIS AND

DESIGN
SYLLABUS
UNIT - I
Introduction to UML: Importance of modeling, principles of
modeling, object oriented modeling, conceptual model of
the UML, Architecture, Software Development Life Cycle.
UNIT - II
Basic Structural Modeling: Classes, Relationships, common
Mechanisms, and diagrams. Advanced Structural Modeling:
Advanced classes, advanced relationships, Interfaces, Types
and Roles, Packages.
UNIT - III
Class & Object Diagrams: Terms, concepts, modeling
techniques for Class & Object Diagrams.
UNIT - IV
Basic Behavioral Modeling-I: Interactions, Interaction
diagrams.
2

UNIT-V
Basic Behavioral Modeling-II:
Diagrams, Activity Diagrams.
UNIT - VI

Use

cases,

Use

case

Advanced Behavioral Modeling: Events and signals,

state machines, processes and Threads, time and
space, state chart diagrams.
UNIT - VII

Architectural Modeling: Component, Deployment,

Component diagrams and Deployment diagrams.
UNIT - VIII

Case Study: The Unified Library application

TEXT BOOKS
1. Grady Booch, James Rumbaugh, Ivar Jacobson : The
Unified Modeling Language User Guide, Pearson Education.
2. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David
Fado: UML 2 Toolkit, WILEY-Dreamtech India Pvt. Ltd.
REFERENCES:
1. Meilir Page-Jones: Fundamentals of Object Oriented Design in
UML, Pearson Education.
2. Pascal Roques: Modeling Software Systems Using UML2,
WILEY-Dreamtech India Pvt. Ltd.
3. Atul Kahate: Object Oriented Analysis & Design, The McGrawHill Companies.
4. Mark Priestley: Practical Object-Oriented Design with
UML,TATA McGrawHill
5. Craig Larman Appling UML and Patterns: An introduction to
Object Oriented Analysis and Design and Unified Process,
Pearson Education.

UML

UML stands for Unified Modeling Language.

Why Unified ?
James
Rumbaugh, Grady Booch, and Ivar Jacobson
developed 3 different notations.
But later agreed to adopt as standard a variation on a
notation originally developed by David Embley and his
colleagues.

UML is accepted by the Object Management

Group (OMG) as the standard for modeling
object oriented programs.

UML is a common language for creating

models of Object Oriented Programming.

But what is the need to study

UML?
An Analogy
Ground Floor Plan
1.Floor Area

: 66 sq m
2.Min Lot Area : 120 sq m
3.Living Area, Kitchen and Dining Area
4.Dining is right to the kitchen.
5.Entrance is on right with living space,
following the kitchen and dining.
6.2 bedrooms
7.2 T&B

Written specifications or the model?

Que: What is more appealing?

The reason we want to see a picture is that

human beings naturally want to
communicate in the simplest form
possible.
We say, a picture is worth a thousand
words.

Unit I : Introduction to UML

Contents
Chapter -1 : Why we model?
1. Importance of modeling,
2. Principles of modeling,
3. Object oriented modeling,
Chapter 2 : Introducing the UML
1. Conceptual model of the UML,
2. Architecture,
3. Software development life cycle.
8

CHAPTER-1

Why We Model

Firstly, understand what is Successful

software

The Primary product of a development team is good

software that satisfies the needs of its users and
the business.

To develop software rapidly, efficiently, effectively and

minimum software rework, we need right people, right
tools, and right focus.

Modeling is a central part of all the activities that lead

to the development of good software.

Modeling is a proven and well accepted engineering

tech.

10

We build models to
1.

2.

To Communicate the desired structure and behavior of

our system.
To visualize and control the systems architecture.

3.

To better understanding the system we are building

often exposing opportunities for simplification and
reuse.

4.

To manage risk.
11

1. Importance of Modeling

What is a model?
A Model is a simplification of reality.
It provides the blue prints of a system.
A good model includes the elements which have greater
importance and omits minor elements which are of lower
importance

12

Why model software?

Software is already an abstraction: why model software?

Software is getting larger, not smaller

NT 5.0 ~ 40 million lines of code
A single programmer cannot manage this amount of
code in its entirety.

Code is often not directly understandable by developers

who did not participate in the development

We need simpler representations for complex systems

Modeling is a mean for dealing with complexity

Why

do we model?
The fundamental reason to have a model is we can
better understand the system we are developing.

Through modeling, we can achieve the following 4 aims:1) Models help us to visualize a system as it is or as we
want it to be.
2) Models permits us to specify the structure or
behavior of a system.
3) Models give us a template that guides us in
constructing a system.
4) Models document the decision we have made.

14

2. Principles of Modeling

1.

The use of modeling has a rich history in all the

engineering disciplines.
The four basic principles of modeling are:
The choice of what models to create has a profound
influence on how a problem is attacked and how a
solution is shaped.
In other words, choose your models well. The right
models will brilliantly illuminate the most wicked
development problems, the wrong models will mislead
you, causing you to focus on irrelevant issues.
15

In software, the models you choose can greatly affect

your world view. If you build a system through the eyes
of a database developer, you will likely focus on ? And
so on

2. Every model may be expressed at different levels of

precision.
For a building sometimes you need a 30,000 feet view
for investors look and feel other times, you need to get
down to some other level like pipelines etc.
Similarly analyst or an end user will focus on issues of
what, a developer will want to focus on issues of how.

2.

The best models are connected to reality.

3.

No single model is sufficient. Every non trivial system is

best approached through a small set of nearly
independent models.

17

To understand the architecture of a system, you

need several complementary and interlocking
views:A Use Case view
A Design process view
A Process view
An implementation view
A Deployment view
18

A Use Case view: Exposing the requirements of the

system.
A Design process view: Capturing the vocabulary of the
problem space and the solution space.
A Process view: Modeling the distribution of the systems
processes and threads.
An Implementation view: Addressing the physical
realization of the system.
A Deployment view: Focusing on systems engineering
issues.
These views represent the blueprints of the software
system.
19

3. Object-Oriented Modeling

In software, the two most common approaches used

are algorithmic perspective and an object-oriented
perspective.

1.

In algorithmic perspective, the main building block of all

software is the procedure or function. This view leads
developers to focus on issues of control and the
decomposition of larger algorithms into smaller ones.

2. In object-oriented perspective, the main building block

is the object or the class.
20

2.

In object-oriented perspective, the main building block is

the object or the class.
In this approach, the main building block of all software
systems is the object or class. Simply put
An object is a thing, and a class is a description of a set
of common objects.

3.

Visualizing, specifying, constructing and documenting

object-oriented system is exactly the purpose of UML

Summary of chapter 1
1.

Importance of modeling

2.

Principles of modeling,

3.

visualize a system.
specify the structure or behavior of a system.
template that guides us in constructing a system.
document the decision

what models to create

Every model may be expressed at different levels of precision.
The best models are connected to reality.
No single model is sufficient.

Object oriented modeling

algorithmic perspective,
object-oriented perspective

22

INTRODUCTION TO UML

CHAPTER 2

Chapter 2 : Introducing the UML

In this chapter
Overview of the UML
Three steps to understanding the
UML
Software Architecture
The Software Development Process

Introduction To UML

The Unified Modeling Language (UML) is a standard

language for writing software blue prints.

It is appropriate for modeling systems ranging from

enterprise information systems to distributed web-based
applications and even real time embedded systems.

Very expressive, easy to learn and use.

The UML is process independent.

Overview of UML
The UML is a language for
a)
b)
c)
d)

Visualizing
Specifying
Constructing
Documenting
the artifacts of software-intensive system.

26

The UML is a Language.

What is a Language?
What is a modeling language?

Its a language whose vocabulary and rules focus on

the conceptual and physical representation of a
system.

Modeling yields an understanding of a system

27

a. UML is a language for

visualizing

For many programmers, the distance between thinking of

an implementation, and then delivering it out in code is
close to zero. Means you think and you code or do directly

Text is a wonderful, minimal and direct way to write

expressions and algorithms.
In such cases, the programmer is still doing modeling (Of
course mentally).
Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

There are several problems with this

1) Communicating the conceptual models to others is
error-prone unless everyone involved speaks the same
language.
So

UML is more than a bunch of graphical symbols and

each UML notations have a well defined semantics.
Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

2) There are some things about a software system you

cant understand unless you build models that transcend
the textual programming language. (Example : Class
hierarchy)

Some things are best modeled textually, others are best

modeled graphically. Indeed, in all interesting systems,
there are structures that transcend what can be
represented in a programming language. The UML is
such a graphical language.
Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

3) If the developer who cut the code never wrote down the
models that were in his/her head, that information would
be lost forever or, at best, only partially recreatable from
the implementation, once that developer moved on.

Writing models in the UML addresses the third issue: An

explicit model facilities communication.

Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

b. UML is a language for

Specifying

Specifying means building models that are precise,

unambiguous and complete.

The UML addresses the specification of all the

important analysis, design and implementation
decisions that must be made in developing and
deploying a software system.
Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

c. UML is a language for

Constructing
The UML is not a visual programming language, but its models
can be directly connected to a variety of programming
languages, such as JAVA, C++ or Visual Basic or even to Tables
of database.
Forward Engineering: generation of code in programming
language from UML model.
Reverse Engineering : reconstructing an UML model from an
implementation
Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

33

d. UML is a language for

Documenting
A software organization produces all sorts of artifacts in
addition to row executable code. The artifacts including
the following:
-Requirements
-Architecture
-Design
-Source Code

-Project Plan
-Tests
-Prototypes
-Releases.

Overview of UML
a)Visualizing
b)Specifying
c)Constructing
d)Documenting

Where can be UML used

The UML is intended primarily for Software intensive

systems. It has been used effectively for such domains
as follows:
Enterprise information systems
Banking and financial services
Telecommunications
Transportation
Defense
Medical Electronics,
Scientific
and Distributed web-based services.

4. A Conceptual Model of the

UML

1.
2.
3.

To understand the UML, a conceptual model of the

language is needed to form,
it requires the three major elements:
Building blocks of the UML.
Rules that dictate how these building blocks may be put
together.
Common mechanisms that apply throughout the UML.

36

1. Building blocks of the

UML
The UML consists of three kinds of building blocks:

a)

Things- These are the abstractions that are first-class

citizens in a model.

b)

Relationships-Tie the above things together.

c)

Diagrams-Group interesting collections of things,

37

UML Terminology
Building blocks

Things
Structural (7)

Behavioral (2)

Grouping (1)

Annotational (1)

Relationships

Diagrams

Class, Interface,
Active class, Use case,
Dependency,
Component,
Generalization,
Collaboration, Node
Interaction,
State Machine
Package

Note

Associations,
Realization

Use case,
Class,
Object,
Sequence,
Collaboration,
State chart,
Activity,
Component,
Deployment.

Things in the UML

There are 4 kinds of things in the UML
1. Structural Things
2. Behavioral Things
3. Grouping Things
UML Terminology
4. Annotational Things
Building blocks
Things

Relationships

Diagrams

Structural (7)

Behavioral (2)
Grouping (1)
39

Annotational (1)

1. Structural Things

Nouns of UML models. Mostly static parts of a model,

representing elements that are either conceptual or
physical.
7 kinds of Structural things:
UML Terminology
Building blocks

1.
2.
3.
4.
5.
6.
7.

Class
Interface
Collaboration
Use case
Active class
Component
Node

Things

Relationships

Diagrams

Class, Interface,
Structural (7)Active class, Use case,
Component,
Collaboration, Node
Behavioral (2)

Grouping (1)

Annotational (1)

40

UML Terminology
Building blocks
Things

Relationships

Diagrams

Class, Interface,
Active class, Use case,
Behavioral (2) Component,
Collaboration, Node
Grouping (1)
Structural (7)

(1)

Class:Annotational (1)
A class is a description of a set of objects that share
the same attributes, operations, relationships and
semantics.
A class implements one or more interfaces.
Window

class

Origin
Size
Open( )
Close( )
Move( )
Display( )

Name
Attributes
Operation

(2)

Interface

Interface is a collection of operations that specify a

service of a class or component.

An interface describes the externally visible behavior of

that element.
UML Terminology
Building blocks
Things

Relationships

Class, Interface,
Structural (7)Active class, Use case,
Component,
Collaboration, Node
Behavioral (2)
Grouping (1)
Annotational (1)

Diagrams

42

An interface defines a set of operation specifications

but never a set of operation implementations.

Graphically, an interface is represented as a circle

with its name.

ISpelling
Interface

UML Terminology
Building blocks
Things

Relationships

Diagrams

Structural (7) Class, Interface,

Collaboration, Use case,
Behavioral (2) Component,
Active class, Node
Grouping (1)

(3) Collaboration:Annotational (1)

defines an interaction and is a society of roles and
other elements. they work together to provide some
cooperative behavior.

Therefore, collaboration have structural as well as

behavioral dimensions.

Graphically a collaboration is represented as an

ellipse with dashed lines, usually including only its
name.
Chain of
responsibility

UML Terminology
Building blocks
Things

Relationships

Structural (7)

Class, Interface,
Collaboration, Use case,
Component,
Active class, Node

Behavioral (2)

Diagrams

Grouping (1)
Annotational (1)

(4) Use case: A Use case is a description of set of sequence of actions

that a system performs, which results a value to a
particular actor.

A use case is used to structure the behavioral things in a

model.

UML Terminology
Building blocks
Things

Relationships

Structural (7)

Class, Interface,
Collaboration, Use case,
Component,
Active class, Node

Behavioral (2)

Diagrams

Grouping (1)
Annotational (1)

A use case is realized by a collaboration.

Withdraw money

Use case
46

UML Terminology
Building blocks
Things

Structural (7)
Behavioral (2)

Relationships

Diagrams

Class, Interface,
Collaboration, Use case,
Component,
Active class, Node

Grouping (1)
Annotational (1)

The remaining three things- Active classes, components

and nodes- all are class like,
ie., they also describe a set of objects that share the
same attributes, operations, relationships and semantics.

UML Terminology
Building blocks
Things

Relationships

Diagrams

Structural (7) Class, Interface,

Collaboration, Use case,
Behavioral (2) Component,
Active class, Node
Grouping (1)
Annotational (1)

(5) Active class: An active class is a class whose objects own one or more
processes or threads and therefore can initiate control
activity.

An Active class is like a class except that its objects

represent elements whose behavior is concurrent with
48
other elements.

UML Terminology
Building blocks
Things

Relationships

Diagrams

Structural (7) Class, Interface,

Collaboration, Use case,
Behavioral (2) Component,
Active class, Node
Grouping (1)
Annotational (1)

Graphically, an active class is represented like a class, but

with heavy lines, usually including its name, attributes and
operations.
Event manager

Suspend()
Flush()
Active class

49

The remaining two elements component and nodesthey represent physical things, where as previous five
things ( class, interface, collaboration, usecase, active
class) represent conceptual or logical things.
UML Terminology
Building blocks
Things

Structural (7)
Behavioral (2)

Relationships

Diagrams

Class, Interface,
Collaboration, Use case,
Component,
Active class, Node

Grouping (1)
Annotational (1)

50

(6) Component: A component is a physical and replaceable part of a

system that conforms to and provides the realization of a
set of interfaces.

A component represents the physical packaging of

logical elements such as classes, interfaces and
collaborations.

51

orderform.java

Component

(7) Node: A node is physical element that exists at run-time and

represents a computational resource, generally having
some memory and processing capability.

A set of components may reside on a node and may also

migrate from node to node.

UML Terminology
Building blocks

Things
Structural (7)
Behavioral (2)

Relationships

Diagrams

Class, Interface,
Collaboration, Use case,
Component,
Active class, Node

Grouping (1)
Annotational (1)

Database
server

Node

2. Behavioral Things

These are the dynamic parts of UML models.

These are the verbs of a model representing the
behavior over time and space.
There are two types of behavioral things
1. Interaction
UML Terminology
2. State machine.
Building blocks
Things
Structural (7)
Behavioral (2)
Grouping (1)
Annotational (1)

Relationships
Class, Interface,
Active class, Use case,
Component,
Collaboration, Node

Interaction,
State Machine

Diagrams

UML Terminology
Building blocks

Things
Structural (7)
Behavioral (2)
Grouping (1)

Relationships

Diagrams

Class, Interface,
Active class, Use case,
Component,
Collaboration, Node

Interaction,
State Machine

Annotational (1)

(1) Interaction:
An Interaction is a behavior that comprises a set of
messages exchanged among a set of objects within a
particular context to perform a specific purpose.
display

Message

56

An interaction involves a number of other elements,

including messages, action sequences and links.
(connection between objects.)

UML Terminology
Building blocks

Things
Structural (7)
Behavioral (2)
Grouping (1)

Relationships

Diagrams

Class, Interface,
Active class, Use case,
Component,
Collaboration, Node

Interaction,
State Machine

Annotational (1)

2. State machine:A State machine is a behavior that specifies the

sequences of states an object or an interaction goes
through during its lifetime in response to events, together
with its responses to those events.
waiting

State

58

A State machine involves a number of other elements,

including states, transitions( the flow from state to state),
events (things that trigger a transition), and activities
( the response to a transition).

3. Grouping Things
UML Terminology
Building blocks

Things
Structural (7)
Behavioral (2)
Grouping (1)

Relationships

Diagrams

Class, Interface,
Active class, Use case,
Component,
Collaboration, Node
Interaction,
State Machine

Package

Annotational (1)

Grouping things are the organizational parts of UML

models.
In all, there is one primary kind of grouping thing, namely,
Package.
Package:- A Package is a general-purpose mechanism
for organizing elements into groups.

Structural things, behavioral things and even other

grouping things that may be placed in a package.

Unlike component (which exist at run time), package is

purely conceptual (meaning that it exist only at
development time).

Business rules

Package

4. Annotational Things

Annotational Things are the explanatory parts of the

UML models.

These are the comments you may apply to describe,

illuminate and remark about any element in a model.

There is one primary kind of Annotational thing, called

a Note.

62

Note:- A Note is simply a symbol for representing

constraints and comments attached to an element or a
collection of elements.
A note is rendered as a rectangle with a
dog-eared corner.

Return copy of self

Note
63

2. Relationships in the UML

There are four kinds of relationships in the UML.
1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational building blocks
of the UML. These are used to write well-formed models.

64

DEPENDENCY:

A Dependency is a semantic relationship between two

things in which a change to one thing( the independent
thing) may affect the semantics of the other thing
(the dependent thing).

Dependencies
65

In UML, a dependency relationship is a relationship in

which one element, the client, uses or depends on
another element, the supplier.
You can use dependency relationships in class diagrams,
component diagrams, deployment diagrams, and usecase diagrams to indicate that a change to the supplier
might require a change to the client.

ASSOCIATION:-

In UML diagrams, an association class is a class that is

part of an association relationship between two other
classes.
An Association is a structural relationship that describes
a set of links, a link being a connecting among objects.
When two classes are connected to each other in any
way, an association relation is established. For example:
A "student studies in a college" association can be
shown as:

An association is represented as a solid line, possibly

directed, occasionally including a label, and often
containing other adornments, such as multiplicity and
role names.
0..1
employer

*
employee

Association

GENERALIZATION:

A generalization is a specialization/generalization
relationship in which objects of the specialized elements
(the child) are substitutable for objects of the generalized
elements (the parent).
In this way, the child shares the structure and the behavior
of the parent.
Represented as a solid line with a hollow arrow head
pointing to the parent.

Generalization

A Generalization is relationship between a general

thing( called the Super class or parent) and a more
specific kind of that thing( called the Subclass or child).

Generalization
relationship.

Generalization means that objects of the child may be

used anywhere the parent may appear, but not the
reverse.

is sometimes called is-a-kind of

AGGREGATION:

A plain association between two classes represents a

structural relationship between peers.

To model a Whole/part relationship, in which one class

represents a large thing( the whole), which consists of
smaller things ( the Parts).

This kind of relationship is called AGGREGATION,

which represents a has-a relationship, meaning that an
object of the whole has objects of the part.

Aggregation is really just a special kind of association

and is specified by adorning a plain association with
an open diamond at the whole end.
Composition: Composition is a special form of aggregation within
which the parts are inseparable from the whole.

Hand

Finger

REALIZATION:

A realization is a semantic relationship between

classifiers, wherein one classifier specifies a contract
that another classifier guarantees to carryout.

We will encounter realization relationships in two places:

between interfaces and classes or components that
realize them, and between use cases and the
collaborations that realize them.

Realization

3. Diagrams in the UML

A diagram is the graphically presentation of a set of

elements, most often represented as a connected graph
of vertices (things) and arcs (relationships).

Diagrams visualize a system from different perspectives,

so a diagram is a projection into system.

Diagrams in UML
Scenario
Scenario
Diagrams
Use Case
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams

Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams

Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams

State
State
Diagrams
Class
Diagrams
Diagrams

State
State
Diagrams
Object
Diagrams
Diagrams

State
State
Diagrams
Component
Diagrams
Diagrams

Models

Component
Component
Diagrams
Deployment
Diagrams

Activity
Diagrams

Diagrams

The UML includes nine diagrams:

1.
Class diagram
2.
Object diagram
3.
Component diagram
4.
Deployment diagram
5.
Activity diagram
6.
Sequence diagram
7.
Collaboration diagram
8.
State chart diagram
9.
Use case diagram

This describe the

static part of a
system represented

This describe the

dynamic part of a
system represented

1. Class Diagram

It shows a set of classes, interfaces, and collaborations and

their relationships.
most common diagrams found in modeling object-oriented
systems.
address the static design view of a system.

2. Object Diagram

An object diagram shows a set of objects and their

relationships.
Object diagrams represent static snapshots of instances of
the things found in class diagram

3. Component Diagram

A component diagram shows the organizations and

dependencies among a set of components.
Component diagram address the static implementation
view of a system.

4. Deployment Diagram

A deployment diagram shows the configuration of run-time

processing nodes and the components that live on them.
Deployment diagram address the static deployment view
of an architecture.
80

5. Activity Diagram

An activity diagram is a special kind of a statechart

diagram that shows the flow from activity to activity within a
system.
Activity diagram address the dynamic view of a system.

(6) & (7)

Sequence and Collaboration diagrams

Both sequence diagrams and collaboration are kind of

interaction diagrams.

An interaction diagram shows an interaction, consisting

of a set of objects and their relationships, including the
messages that may be dispatched among them.

Interaction diagram address the dynamic view of a

system.

A sequence diagram is an interaction diagram that

emphasizes the time ordering of messages.

A collaboration diagram is an interaction diagram that

emphasizes the structural organization of the objects
that send and receive messages.

Sequence diagrams and collaboration diagrams are

isomorphic, meaning that you take one and transform it
into the other.

8. State Chart Diagram

A statechart diagram shows a state machine, consisting of

states, transitions, events and activities.
Statechart diagram address the dynamic view of a system.

9. UseCase Diagram

Use case diagram shows a set of use case and actors

(a special kind of class) and their relationships.

Use case diagrams address the static use case view of a

system.

These diagrams are especially important in organizing

and modeling the behaviors of a system

2. Rules of the UML:

The UMLs building blocks cant simply be thrown

together in a random fashion.

Like any language, the UML has a number of rules that

specify what a well-formed model should look like.

A Well-formed model is one that is semantically selfconsistent and in harmony with all its related models.

The UML has semantic rules for:

Names- What you can call things, relationships and

diagrams.
Scope- The context that gives specific meaning to a
name.
Visibility- How those names can be seen and used by
others.
Integrity- How things properly and consistently relate to
one another.
Execution- What it means to run or simulate a dynamic
model.

3.Common Mechanisms
The 4 common mechanisms that apply consistently
throughout the language.
1.
2.
3.
4.

Specifications
Adornments
Common Divisions
Extensibility mechanisms

88

1.

Specifications:-

The UML is more than just a graphical language.

Rather, behind every part of graphical notation there is
a specification that provides a textual statement of the
syntax and semantics of that building block.

For example, behind a class icon is a specification that

provides the full set of attributes, operations and
behaviors.

You use the UMLs graphical notation to visualize a

system; you use the UMLs specification to state the
system details.

2. Adornments:

Adornments Textual/Graphical items added to the basic

notation of an element.
Used for visualizing details from the elements
specification
Example: The basic notation of association is a line, but
this could be adorned with additional details, such as the
role and multiplicity of each end.
The most important kind of adornments are notes.
0..1
Employer

*
Employee
90

3.Common Divisions

Abstraction vs. manifestation

Class vs. object
Most UML building blocks have this kind of class/object
distinction.
Customer
name
address
phone

Jan :Customer
:Customer
Elyse

Classes and Objects

Interface vs. implementation

An interface declares a contract, and an implementation

represents one concrete realization of that contract.

IUnknown

SpellingWizard.dll

ISpelling

Interfaces and Implementations

4.Extensibility Mechanisms
Allows you to extend the language by adding new building
blocks derived from existing ones, creating new
properties and specifying new semantics. Includes:
1.
2.
3.

Stereotypes
Tagged values
Constraints

93

Stereotypes
Extend the vocabulary of the UML by creating new model
elements derived from existing ones but that have specific
properties suitable for your domain/problem.

Each stereotype defines a set of properties that are

received by elements of that stereotype.

Graphically, a stereotype is rendered as a name enclosed

by guillemots and placed above the name of another
element (eg, <<name>>)

Alternatively, you can render the stereotyped element by

using a new icon associated with that stereotype

Example:
How many types of classes are there. Like you have
Abstract Class, Derived Class, Exception Class,
Constraint Class etc..

In Java, you sometimes have to model Classes such as

exceptions.
Only want them to be thrown and caught
Can make them first class citizens in your model, ie
treating them like basic building blocks, by marking them
with a suitable stereotype.

Named stereotype

<<metaclass>>
Model Element

Named stereotype with icon <<exceptions>>

Underflow !

Stereotyped element as icon

HumiditySensor

2.Tagged Values:Properties for specifying key-value pairs of model

elements, where keywords are attributes.

Extend the properties of a UML building block, allowing

you to create new information in that elements
specification.

Can be defined for existing elements of the UML

3.Constraints:

Properties for specifying semantics or conditions that

must be maintained as true for model elements.

Extend the semantics of a UML building block, allowing

you to add new rules, or modify existing ones.

Example:- you might want to constrain the EventQueue

class so that all additions are done in order.

Stereotype

<< Exception>>
Overflow

EventQueue
{version =3.2
Author=egb }
add( )

Tagged
value

{ordered}

remove( )
flush( )
Extensibility Mechanisms

Constraints

Architecture
Visualizing,
specifying,
constructing,
and
documenting a software-intensive system demands
that the system be viewed from a number of
perspectives.

Different stakeholders are

end users, analysts, developers,
system integrators, testers, technical writers,
and project managers
each bring different agendas to a project,
each looks at that system in different ways at
different times

System's architecture
Most important artifact
Used to manage different viewpoints; hence controls iterative and
incremental development of a system throughout its life cycle.
Architecture is the set of significant decisions about
1. Organization of a software system
2. Selection of the structural elements and their interfaces by
which the system is composed
3. Their Behavior, specified in the collaborations among elements.
4. Composition of these structural and behavioral elements into
progressively larger subsystems
5. Architectural style that guides this organization: the static and
dynamic elements and their interfaces, their collaborations, and
their composition

Software Architecture
Defined
Software architecture is not only concerned with
structure and behavior, but also with usage, functionality,
performance,
resilience,
reuse,
comprehensibility,
economic and technology, constraints and trade-offs, and
aesthetic concerns.

Modeling a Systems Architecture

Vocabulary
Functionality

System Assembly
Configuration Management

Design View
Behavior

Use-Case
View
Process View

Performance
Scalability
Throughput

Implementation View

Deployment View

System topology
Distribution
Delivery
Installation

Architecture and the UML

Vocabulary
Functionality

System Assembly
Configuration Management

2. Design View

4. Implementation View

Classes, Interfaces,
Collaborations

Components
Use cases

Behavior

1.Use Case View

3. Process View
Active classes

Performance
Scalability
Throughput

Organization
Package, subsystem

5. Deployment View
System topology
Distribution
Delivery
Installation

Dynamics
Interaction
State machine

Nodes

1. Use Case View

1.
2.
3.
4.
5.

6.

Major Elements: use cases

Describes: the behavior of system
Stakeholders concerned : End Users, analysts,
testers
Deals with : Values that shape the systems
architecture.
Refers static aspects : use-case diagrams and
dynamic aspects by considering interaction
diagrams, state chart diagrams and activity
diagrams.
Does not specify for organization of a software
system.

2. Design View
1.
2.
3.
4.
5.

Major
Elements:
Classes,
Interfaces
and
Collaborations
Describes: vocabulary of problem and solution,
functional requirements of system
Stakeholders concerned : End Users, analysts,
design engineers
Deals with : services that system provides to its
end-users
Refers static aspects :class diagrams +object
diagrams and dynamic aspects by considering
interaction , state chart and activity diagrams.
106

3. Process View
1.
2.
3.
4.
5.

Major Elements: Active classes that represents threads and

processes
Describes: systems concurrency and
synchronization
Stakeholders concerned : system integrators
Deals with : systems performance, scalability and
throughput
Refers static and dynamic aspects same as in
design view ; with focus on threads and processes.

4. Implementation View
1.
2.
3.
4.

Major Elements: Component and Files

Stakeholders concerned : Programmers
Deals with: System assembly, Configuration
management
Refers static aspects :component diagrams and
dynamic aspects by considering interaction,
state chart and activity diagrams.

5. Deployment View
1.
2.
3.
4.

Major Elements: Nodes

Stakeholders concerned : System Engineers
Deals with: System topology, Distribution,
Delivery, Installation
Refers static aspects : deployment diagrams and
dynamic aspects by considering interaction, state
chart and activity diagrams.
Each of 5 views are independent to support
designers to designing process.

Software Development Life Cycle

(SDLC)
UML : modeling language
It is process-independent, not tied to any particular
SDLC
To get most benefits from UML, it should be
considered with process that is
1. Use case Driven
2. Architecture Centric
3. Iterative and Incremental

110

Process
Nature

Primary
artifact

Used for

Use case
driven

use case

Architecture
centric

systems
conceptualizing, constructing, managing,
architectur and evolving system under development.
e

Iterative and
Incremental
and hence
Risk Driven

establishing desired behavior of system,

verifying and validating the system
architecture, testing , communicating
among stakeholders

Iterative process: managing executable

releases.
Incremental process: continuous
integration of systems architecture to
produce releases with incremental
improvements.
Risk driven: each new release is focused
on attacking new risks for success.

Use case Driven, Architecture Centric, Iterative and

Incremental process is broken into phases.
Phase: time-span between two major milestones of the
process.
Milestone: when well-defined objectives are met, artifacts are
completed and decisions made whether to move to next
phase.
Four Phases of SDLC:
1. Inception
2. Elaboration
3. Construction
4. Transition

Lifecycle Phases
Inception

Elaboration

Construction

Transition

time

Inception
Define the scope of the project and
develop business case
Elaboration

Plan project, specify features, and baseline

the architecture

Construction

Build the product

Transition

Transition the product to its users

Software Development Life

Cycle
Phases
Process Workflows

Inception Elaboration

Construction

Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment

Supporting Workflows
Configuration Mgmt
Prj. Management
Environment
Preliminary
Iteration(s)

Iter.
#1

Iter.
#2

Iter.
#n

Iter. Iter.
#n+1 #n+2

Iterations

Iter.
#m

Iter.
#m+1