Object Oriented
Analysis
And
By:
Design
Manish Sharma – 2707
Kanika Dogra – 2717
Gagandeep Singh - 2720
Outline :
Object Oriented Concepts
Object Oriented Analysis
Object Oriented Design
Object Oriented
Concepts
Introduction :
We live in a world of objects
Object-Oriented view is an abstraction that
models the world in ways that help us to better
understand and navigate it
OO approach was first proposed in the late
1960s
As time passes, object technologies are
replacing classical software development
approaches.
Object technologies lead to reuse, OO
software is easier to maintain, to adapt, and to
scale.
OO Paradigm :
For many years, the term OO was used to
denote a software development approach that
used one of a number of OO programming
languages(e.g. Ada 95, C++, Eiffel, Smalltalk)
Today, the OO paradigm encompasses a
complete view of software engineering
Although any one of process models could be
adapted for use with OO, the best choice would
be an evolutionary process model.
The OO Process Model
identify
candidate
classes
Pla n n in g
Risk Ana lysis construct look-up
nth iteration classes
Custo m e r of system in library
Co m m unic a tio n
put new extract
classes classes
in library if available
engineer
classes
C usto m e r Eng ine e ring , if unavailable
Eva lua tio n Co nstruc tio n & Re le a se
OO analysis
OO design
OO programming
OO testing
OO Concepts
Objects
●
Attributes
●
Methods
●
Encapsulation
●
Polymorphism
Messages
Classes
●
Instances
●
Inheritance
●
Abstraction and hiding
Objects
•Object are the basic run time entities in an
object oriented system. They may represent
a person, a place, etc.
•When a program is executed the object
interact by sending message to one another.
•Each object contains data, and code to
manipulate the data
Polymorphism
It is a characteristic that greatly reduces the
effort required to extend an existing OO
system.
Polymorphism enables a number of different
operations to have the same name.
For example: drawing different type of graphs
( e.g. Line, Pie, Histogram )
It decouples objects from one another making
each more independent.
General class graph and one subclass for each
type.
Messages
sender object
attributes:
receiver object
attributes:
operations:
operations:
message:
[sender, return value(s)]
message: [receiver, operation, parameters]
Object Oriented
Analysis
OOA & OOP
OOA is based upon OOP: Classes and members,
Objects and attributes and so on
To define them following tasks should be done:
◦ Basic user requirements should be communicated
between customer and software engineer
◦ Classes must be identified
◦ Class hierarchy should be specified
◦ Object to object relationship should be
presented
◦ Object behavior should be modeled
◦ These tasks should be re-applied iteratively until
model is complete
Generic Steps for OOA
1. Elicit customer requirements for the system.
2. Identify scenarios for use-cases.
3. Select classes and objects using basic
requirements as a guide.
4. Identify attributes and operations for each system
object.
5. Define structures and hierarchies that organize
classes.
6. Build an object-behavior model.
7. Review the OO analysis model against use-cases
or scenarios.
Domain Analysis
OO Analysis can occur at many different levels of
abstraction:
◦ At the business or enterprise level
◦ At the business area level
◦ At an application level
OOA at the middle level called Domain Analysis.
Domain Analysis is performed to create a library of
reusable classes applicable to an entire category of
applications.
Using a robust class library produces the system
faster, cheaper and more reliable.
But where did such a library come from? By
applying domain analysis.
Domain Analysis Process
The goal: to find or create those classes that are broadly
applicable, so that they may be reused.
It can be viewed as an umbrella activity for the software
process.
The role of domain analyst is to design and build reusable
components that maybe used by many people working on
similar but not necessarily the same applications.
Key inputs and outputs for the domain analysis process:
class taxonomies
technical literature
SOURCES OF reuse standards DOMAIN
DOMAIN existing applications DOMAIN ANALYSIS
KNOWLEDGE ANALYSIS functional models MODEL
customer surveys
domain languages
expert advice
current/future requirements
Domain Analysis Activities (1)
Define the domain to be investigated.
◦ Isolate the business area, system type, product
category
◦ Extract both OO and non-OO items.
OO-items such as: application and support (GUI, DB)
classes, Commercial off-the-shelf (COTS) component
libraries and test cases.
Non-OO items such as: policies, procedures, plans,
standards and guidelines; parts of existing non-OO
applications, metrics and COTS non-OO software.
Categorize the items extracted from the domain.
◦ Organize items into categories.
◦ Define the general defining characteristics of the
categories.
◦ Propose a classification scheme for the categories.
◦ Define naming conventions for each item.
◦ Establish classification hierarchy when appropriate.
Domain Analysis Activities (2)
Collect a representative sample of applications in the domain.
◦ Ensure that the application has items that fit into
categories.
Analyze each application in the sample.
◦ Identify candidate reusable objects.
◦ Indicate the reasons that the object has been identified
for reuse.
◦ Define adaption to the object that may also be reusable.
◦ Estimate the percentage of applications in the domain that
make reuse of the object.
◦ Identify the object by name and use configuration
management techniques to control them (chapter 9).
Develop an analysis model for the objects.
◦ As a basis for design and construction of domain objects.
OOA- A Generic View
define use cases
extract candidate classes
establish basic class relationships
define a class hierarchy
identify attributes for each class
specify methods that service the attributes
indicate how classes/objects are related
build a behavioral model
iterate on the first five steps
The OOA Process
The OOA process begins with an understanding of
the manner in which the system will be used by:
◦ People, if the system is human-interactive.
◦ Machines, if the system is involved in process
control.
◦ Programs, if the system coordinates and controls
applications
Once the scenario of usage has been defined, the
modeling of the software begins.
A series of techniques may be used to gather basic
customer requirements.
Object Oriented
Design
Object Oriented Design
OOD transforms the analysis model created using
OOA into a design model that serves as a blueprint
for software construction.
OOD results in a design that achieves a number of
different levels of modularity.
Subsystems: Major system components.
Objects: Data and the operations.
Four important software design concepts:
◦ Abstraction
◦ Information Hiding
◦ Functional Independence
◦ Modularity
Object Oriented Design
The subsystem layer: Representation
of each of the subsystems that enable
the software to achieve its customer
defined requirements.
responsibiliti
es
The class and object layer: The
class hierarchies, (generalization) Message
design
and representation of objects.
Class and
object design
The message layer: The design details
of communication of each object with
its collaborators. (external and
Subsystem
design
internal interfaces)
The responsibilities layer: Data
Structure and algorithmic design
for all attributes and operations.
OOA to OOD
Attributes, operations,
collaborators responsibilities
Object- design
CRC relationship
Index Cards model
message
Use cases design
Class and object
Object-Behavior
design
Model
subsystem
design
THE ANALYSIS MODEL THE DESIGN MODEL
OOA to OOD
Analysis Model Design Model
classes objects
attributes data structures
methods algorithms
relationships messaging
behavior control
Protec tion—a arch itectu ral
UComposability—the
Decomposability—the
Continuity — the abilit ydegree
nderstandability—the
which
s
sub
characteristic
with
malla
which
reduce
that
which
ca
helps
have
can be
design
hanges
sideelves
decompose
(modules),
t hems
reference
c hanges
built,
a in
program
the
program
t hes the
design
method
understood
affects
into
problems
does can
aonce
jus
wit h if
large
other
betreused
occur
orother
other
one or
that
that
inare
modules;
m odules
solve;
systems;
module.
to
a program
designer
components
e changes manif
facility
ease
make
will
method
ensures
component
propagation
without
an ponding
designed
problem
corres
ato
error
information
and
veasier
ery
to
with
toest of
and
into
f ew
create
; a g iven
to
Design Issues
Generic Components for OOD
Problem domain component—the subsystems that
are responsible for implementing customer
requirements directly;
Human interaction component —the subsystems
that implement the user interface (this included
reusable GUI subsystems);
Task Management Component—the subsystems that
are responsible for controlling and coordinating
concurrent tasks that may be packaged within a
subsystem or among different subsystems;
Data management component—the subsystem that
is responsible for the storage and retrieval of
objects.
System Design
client
client request
request server
server
subsystem
subsystem subsystem
subsystem
contract
contract
request
request
peer
peer peer
peer
subsystem
subsystem subsystem
subsystem
request
request
contract
contract contract
contract
Subsystem Example
Control
Control
request
request for
for status
status Sensor
Sensor
panel
panel subsystem
assign to zone
assign to zone subsystem
subsystem
subsystem test
test status
status
request
request for
for system
system status
status request
request for
for alarm
alarm notification
notification
specification
specification of type of alarm
of type of alarm periodic check-in
periodic check-in
periodic
periodic status
status check
check require
require for
for configuration
configuration update
update
Central
Central
communication
communication
subsystem
subsystem
Subsystem Design Criteria
The subsystem should have a well-defined
interface through which all communication with
the rest of the system occurs.
With the exception of a small number of
“communication classes,” the classes within a
subsystem should collaborate only with other
classes within the subsystem.
The number of subsystems should be kept
small.
A subsystem can be partitioned internally to
help reduce complexity.
THANK
THANK
YOU
YOU
