Object Oriented

Analysis and
Design
Object Oriented Analysis :
Object oriented analysis is a method that examines
requirements from the perspective of the classes and
objects found in the vocabulary of the problem domain.

Abstraction :
An abstraction denotes the essential characteristics of an
object that distinguishes it from all other kinds of objects
and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer.
Object Oriented Design :
Object Oriented Design is a methods of design
encompassing the process of object - oriented
decomposition and a notation for depicting both logical
and physical as well as static and dynamic models of the
system under design.

Two important parts to this definition :

1.Leads to an object oriented decomposition and
2.Uses different models of the logical(Class and Object
Structure) and physical (module and process architecture
) design of a system , in addition to the static and dynamic
aspects of the system.
Object Oriented Programming :
It is a method of implementation in which programs are
organized as cooperative collections of objects , each of
which represents an instance of some class , & whose
classes are members of hierarchy of classes united via
inheritance relationships.
Object Oriented Language :
A language is Object - Oriented if and only if it satisfied
the following requirements :
•It supports objects that are data abstractions with an
interface of named operations and a hidden local state.
•Objects have an associated type [Class].
•Types [Classes] may inherit attributes from super
types[Super classes]
 Project Life Cycles :

Testing Requirement
specification

Design

Implementation

Traditional SW life cycles : Major portion of the project life

time is spent on implementing design .
 Testing Requirement
specification

Implementation

Design

Object oriented design aims for robust software that can be

easily reused , refined , tested , maintained and extended ,
thereby ensuring it a productive maturity.
Software is Reused when it is used as a part of software other
than that for which it is initially designed .

Software is Refined when it is used as the basis for the definition

of other software.

Software is Tested when its behavior is determined .

Software id Maintained when errors are found and corrected.

Software is Extended when new functionality is added to an

already existing program.
Software that can be Reused :

Components

Frameworks

Applications
Project Life Cycle :
1. Requirements Specification.
2. Design.
3. Implementation
4. Testing.

==> Maintenance
Refinement and Extension
Requirements Capture :

Current System

New Requirements
Investigating Current System :
•Some of the functionality of the existing system will be
required in the new system.
•Some of the data in the existing system is of value and must
be migrated into the new system.
•Technical Documentation of the existing computer systems
may provide details of processing that will be needed in the
new system.
•The existing system may have defects which we should
avoid in the new system.
•Studying the existing system will help us understand the
organization in genera
•Parts of existing system may be retained.
• To Understand how people do their jobs at present in order to
characterize people who will be the users of the new system.

• To gather baseline information against which we can set and

measure performance targets for the new system.
New Requirements :

•Functional Requirements

•Non Functional Requirements

•Usability Requirements
Functional Requirements :

Functional requirements describe what a system does or

expected to do , often referred to as functionality .
Functional Requirements include the following :

•Descriptions of processing which the system will be required to

carry out.
•Details of inputs into the system from paper forms and
documents , from interactions between people ,such as telephone
calls , and from other systems.
•Details of outputs that are expected from the system in the form
of printed documents and reports , screen displays and transfers
to other systems.
•Details of data that must be held.
Non Functional Requirements :
Non Functional requirements are those which describe
aspects of the system that are concerned with how well it
provides the functional requirements . These include the
following :
•Performance criteria such as desired response times for
updating data in the system or relative data from the
system.
•Anticipated volumes of data , either in terms of throughput
or of what must be stored .
•Security considerations.
Usability Requirements :
Usability requirements are those enable us to ensure that
there is a good match between the system that is developed
and both the users of the system and the tasks that they will
undertake when using it.
•Characteristics of the users who will use the system.
•The tasks which the users undertake , including the goals
they are trying to achieve.
•Situational factors which describe the situations which could
arise during system use.
•Acceptance criteria by which the user will judge the
delivered system.
Fact finding techniques :

•Sampling

•Questionnaires

•Interviewing

•Reading

•Observation
 Analysis Design

What to do Exactly how to

do
Other Activities in Analysis

•Project Management
•Staff Skills and Experience
•Client Decisions
•Choice of Development
Environment
Project Management (Task by Project Manager)
- Budget in terms of Money and Staff.

Staff Skills and Experience

- Business Analyst
- Systems Analyst
- Systems Architects
.
Client Decisions
- The clients want to know what they are paying for.
(Decision point)
- Specification of system in terms of requirements.
-Selection of Alternatives from number of Specifications.

Choice of Development Environment

-Hardware / Software Environment.(Dynamic)
Design
 Design

Logical Physical
(Implementation (Implementation
Independent) Dependent)
 In Object -Oriented methodology, the development of a
system is viewed from three perspectives

1. The Essential Model : Equivalent to Analysis Model.

2. The Specification Model : Logical Design.

3. Implementation Model : Physical Design Model.

 Design

System Design Detail Design

System Design

•Overall System Architecture of the system.(e.g.Client

Server(Unix,Windows NT).
•Distribution of Processes and Objects on Different
Machines.(done by systems designer or architect).
•Decomposing the system into different Subsystems and
allocation of processors to different Subsystems.
•Communication between processors and mechanism for
communication between processors..
•Concurrency Needs
•Decisions about the standards to be applied across the whole
system.(e.g. Screen Layouts , Report Layouts, On-line help.
Etc.)
 Detail Design
Traditional Approach
•Designing Inputs
•Designing Outputs
•Designing Processes and
•Designing Files
 Object - Oriented Detailed Design

•Concepts of Business (Analysis Phase)

•Classes
•Use Cases
•User Interfaces and Interfaces with other
Systems Classes (Depending on Hardware
and Software Platform)
Identifying Classes :
Classes often represent the more permanent aspects of an
application domain.
A class is an abstract descriptor for a set of instances with
certain logical similarities to each other.
The class Diagram is a fundamental to object oriented analysis .
Through successive iterations , it provides both a high level basis
for system architecture , and a low level basis for the allocation
of data and behavior to individual classes and object instances
and ultimately for the design of the program code that
implements the system. It is important to identify the classes
correctly.
Object :(Definition by Coad and Yourdan)
An abstraction of something in a problem domain , reflecting
the capabilities of the system to keep information about it ,
interact with or both.
Abstraction: A form of representation that includes only what is
important or interesting from a particular viewpoint.

Objects serve two purposes :

1. The promote understanding of the real world and
2. Provide a practical basis for computer implementation.
All objects have certain similarities :

Every object has

•State - Represents the particular condition that an object

is in at a given time.

•Behavior - Things the object can do.

•Identity - Every object is unique.

UML
UML Diagrams :
•Use Case Diagrams
•Sequence Diagrams
•Collaboration Diagrams
•Class Diagrams
•State Transition Diagrams
•Component Diagrams
•Deployment Diagrams
Use Case Diagrams :

These diagrams show interaction between use cases ,

which represent system functionality, and actors ,
which represent the people or systems that provide
or receive information from the system .
Use Case Diagram for an Automatic Teller Machine :

Transfer Funds
Manager

Deposit Funds Change Pin

Customer

Make Payment
Withdraw Money Credit
System
View Balance
Sequence Diagrams :

Sequence diagrams are used to show the flow of

functionality through a use case.
 Customer Cash
Card Reader ATM Screen Dispenser
Customer Account

1:Accept Card 2:Read Card No.

3:Initialize Screen

4:Open Account
5:Prompt for pin no
6:Enter Pin no
7:Verify Pin no
8:Prompt for Transaction

9:Select Transaction(Withdraw)
10:Prompt for Amount
11:Enter Amount
12:Withdraw Funds
13:Verify Funds

14:Deduct Funds

15:Provide Cash

16:Provide Receipt
17:Eject Card
Collaboration Diagrams :

Collaboration Diagrams show exactly the same

information as the Sequence Diagrams . However
collaboration diagrams show this information in a
different way (I.e. Object actor information without
reference to time) and with a different purpose(I.e
Distribution of processes between objects) .
 6:Accept Pin
9:Select Transaction(withdraw)

Customer 11:Enter Amount ATM

Screen

5:Prompt for Pin 7:Verify Pin

12:Withdraw Funds
8:Prompt for Transaction
10:Prompt for Amount 13:Verify Funds
14:Deduct Funds

3:Initialize Screen Customer Account

2:Read Card No
1:Accept Card 4:Open Account
15:Provide Cash
17:Eject Card 16:Provide Receipt
Card Reader

Cash Dispenser
Class Diagrams :

Class Diagrams show interaction between classes in

the system .Classes can be seen as a blueprint for
objects. Classes contain information and behavior that
acts on that information.
Abbreviated Form Full Form

Some Class
Class Some Class

Attributes

Operations
 ATM Screen
Card Reader
- Card Number + Prompt ()
+Accepting()
+Accept Card()
+Eject Card()
+Read Card()

Account
-Account Number Cash Dispenser

-Pin -Cash Balance

-Balance +Provide Cash()

+Open() +Provide Receipt()
+Withdraw Funds()
-Deduct Funds()
-Verify Funds()
State Transition Diagrams :

State Transition Diagrams provide a way to model the

various states in which an object can exist . State
Transition Diagrams are used to model the more
dynamic behavior of a system.
 Withdrawal [Balance < 0]

Overdrawn
Open
Do:Send notice to Customer

Customer Request
Closure
Deposit [Balance < 0]

Check Balance [Balance<0 for > 30 days]

Closed
Component Diagrams :
Component Diagrams show a physical view of the model .It
shows the software components in the system and the
relationships between them . There are two types of
components on the diagram :
1.Executable Components.
2.Code Libraries.
Component diagrams are used by an individual who is
responsible for compiling the system , so as to know in what
order the components need to be compiled.The diagrams also
show runtime components created as a result of
compilation .Component diagrams show mapping of classes to
implementation components . This is a point where code
generation is initiated.
Shaded Component : Package Specification ATM.exe
I.e. program file(.cpp, .java) Task Specification ,represents
Unshaded Component : Package Specification thread of processing

I.e. .h files in c++

Cash Dispenser

Card Reader

ATM Screen

Card Reader Cash Dispenser

ATM Screen
Deployment Diagrams :

The deployment diagram shows the physical layout of the

network and where the various components will reside .

The deployment diagram tells much about the layout of

the system. These diagrams are used by project manager ,
users , architects and deployment staff to understand the
physical layout of the system and where the various
systems will reside.This diagram helps the Project
Manager to communicate to the users , what the system
will be like.
 Oracle Server Banking Database
Server

<<LAN>>

Regional ATM
ATM Server.exe Server
Printer

<<Private Network>> <<Private Network>>

Street 1 ATM Street 2 ATM

ATM Client.exe ATM Client.exe

 Object Oriented Development

Most of the methods remain tied to a waterfall model.

Unified Software Development Process.
(Booch , Jacobson , Rambaugh)
Object Modeling Technique (OMT) Developed by Rambaugh

Three Phases:
•Analysis
•System Design
•Object Design
(Implementation is regarded out of scope)
Methodology Step Comment
1. Write or obtain an initial A major task
description of the
problem(Problem Statement)
2.Build an Object Model : A major task
 Identify Object Classes. broken down
 Begin an data dictionary into several
containing descriptions of more detailed
classes and associations. tasks.
 Add associations between
classes .
 Add attributes for objects and
links.
 Organize and simplify object
classes using inheritance.
 Test access paths using
scenarios and iterate the
above steps as necessary.
 Group classes into modules ,
based on close coupling and
related function.
=>Object Model Object model An end-of-
diagram + data dictionary phase product
OPEN :(Object - oriented Process, Environment and Notation)
(Tailorable life cycle model)
Components

•Activities : Collection of tasks seen from a project manager’s

perspective .
E.g. project initiation , requirements engineering , analysis
and model refinement , project planning and build.
•Tasks : Developers View
e.g. analyze user requirements, choose project team, design
UI ,perform class testing.
•Techniques : Describe how to carry out one or more tasks
e.g. CRC technique , class internal design
•Deliverables : Post conditions for activities and also preconditions
for other activities
e.g. User requirements statement,requirements
specifications, diagrams such as inheritance diagrams,deployment
diagrams.

•Notation :COMN(Common object modeling notation written in

Object modeling language)
Objectory :

Analysis Construction Testing

Requirements model Design model Test model

Analysis model Implementation
model
More Case Studies