INTRODUCTION

TO

2/17/17
OBJECT OREINTED ANALYSIS (OOA)

BY:- ABDELA A.
 TOPIC TO BE COVERED:
OVER VIEW OF OOAD

2/17/17
INRODUCTION TO OOA
DOMAIN ANALYSIS
OBJECT DESIGN PROCESS

2
 2/17/17
SAD VS OOAD ?

3
OOAD -is popular technical approach used in
OVERVIEW OF OOAD

analyzing and designing of an application

2/17/17
system or business by applying object
oriented paradigm and visual modeling
throughout SDLC for better communication and
product quality.

Is a software engineering approach that models

a system as a group of interacting objects .

Based on objects rather than data or processes4

 OOAD/OOSD
OOAD essential for creating well-designed, robust &
maintainable software system using OO Programming

2/17/17
Language (e.g. C++, Java, smalltalk, etc).
It is the latest and most used way of design now.
UML (Unified Modeling Language) is a modeling
language for OOS.
The object-oriented S/W development Life Cycle (SDLC) consists of
three macro process.

Object-Oriented Analysis

Object-oriented Design and

Object-oriented Implementation 5
 WHAT IS OBJECT ORIENTED DESIGN?
Emphasizes on conceptual solution that fulfills the
requirements specified in the analysis.

2/17/17
Need to define software objects and how they collaborate
to fulfill the requirements.
Designs are implemented in a Programming Language.

Focus on how the system does it.

E.g.:-In a Library Information System, a Book object
may have a title attribute and a get Chapter method and
implemented using any OO programming language; e.g.
6
Java.
WHAT IS OBJECT ORIENTED ANALYSIS?
Object-oriented analysis emphasises on

2/17/17
finding and describing the objectsor
conceptsin the problem domain.

OOA focuses on what the system does.

Emphasizes on investigation of problem and

requirement rather than solution.
E.g. In a Library Information System, some of
the concepts include Book, Library, and Patron. 7
EXAMPLE: LIBRARY MNANAGEMENT SYSTEM

2/17/17
8
ANALYSIS AND DESIGN ACTIVITIES

2/17/17
9
CONVENTIONAL VS. OO APPROACHES

Structured analysis treat the process and

2/17/17
data as components where as OOA
combine the data and process that acts
on the data into objects .

10
CONVENTIONAL VS. OO APPROACHES

2/17/17
11
 OBJECT ORIENTED ANALYSIS?....
Its also called use case analysis

2/17/17
Its performed by system designer/Analyst
The objective of object-oriented analysis is:-

to know what are the different relevant object

How do we relate to one another

How to specify or model a problem to create effective

design.

Examine requirement, analyze and their implication

,etc
12
 THE OOA LANDSCAPE
Different Object Oriented Analysis methods:

2/17/17
The Booch method(Produces detailed object-
oriented design methods. )

The Rumbaugh(Describing the object model or the

static structure of the system. )

The Jacobson method(Good for providing user

driven analysis models. )

The Coad and Yourdon method

13
The Wirfs-Brock method
 THE BOOCH METHOD
The Booch Methodologies is a widely used object-oriented method.
It helps to design our system using object paradigm.

2/17/17
It covers the analysis and design phases of an object-oriented
system.
The Booch method consists of the following diagrams.

Class Diagrams.
Object Diagrams.
State Transition Diagrams.
Process Diagrams
interaction Diagrams.
Encompasses both a "micro development process and a
14
macro development process.
 THE RUMBAUGH METHOD
(OMT) consists of three phase :-analysis, system

2/17/17
design, and implementation .

OMT separates modelling into three different parts:

Object model (Presented by the object model and the
data dictionary. ),

Dynamic model (Presented by the state diagrams

and event flow diagrams. )

Functional model (Presented by data flow and

constraint) 15
 THE JACOBSON METHOD
Jacobson and team came with the concept of:

2/17/17
Object Oriented Software Engineering and

Object Oriented Business Engineering which covers

the entire project life cycle.

Use Case is introduced by this team and later it is

adopted in UML.

Use Case diagram captures the complete

requirements of the user and is used in almost all the
phases of the software development.
16

Use Case represents the interaction between the actor

THE COAD AND YOURDON METHOD
The Coad and Yourdon method is often viewed as
one of the easiest OOA methods to learn and
straight forward.

2/17/17
Modelling notation is relatively simple and
guidelines for developing the analysis model are
straightforward.
This method follow six steps
1. finding for class and object.
2. Define a generalization/specification
structure.
3. Define a whole/part structure.
4. Identify subjects (representations of
subsystem components). 17

5. Define attributes.
 THE WIRFS-BROCK METHOD

Wirfs-Brock, Wilkerson, and Weiner do

2/17/17
not make a clear distinction between
analysis and design tasks.

Rather a continuous process that begins

with the assessment of a customer
specification and ends with design is
proposed 18
GENERIC STEP TO PERFORM OOA
To perform object-oriented analysis, a software
engineer should perform the following generic

2/17/17
steps:
1. Elicit customer requirements for the
system.
2. Identify scenarios or 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.
19
6. Build an object-relationship model.
7. Build an object-behavior model.
 2/17/17
Unified Approach to OOA

20
UNIFIED MODELLING LANGUAGE (UML)

Over the past decade, Grady Booch, James

2/17/17
Rumbaugh, and Ivar Jacobson have collaborated
to combine the best features of their individual
object-oriented analysis and design methods into
a unified method.

The result, called the Unified Modelling

Language (UML), has become widely used
throughout the industry.

UML allows a software engineer to express an 21

analysis model using a modelling notation that is

 UML
Its a language for modelling software systems.

2/17/17
This language is used for specifying, visualizing,
constructing and documenting software systems
through out the development. (Mostly object oriented
development).
UML is used to model systems build through Unified
Approach. Unified Approach combines the
methodologies of Booch, Rumbaugh and Jacobson.
22
2/17/17
23
2/17/17
24
 VIEWS OF SYSTEMS IN UML
User model view. This view represents
the system (product) from the users

2/17/17
(called actors in UML)
Structural model view. Data and
functionality are viewed from inside the
system.
Behavioural model view. This part of the
analysis model represent.
Implementation model view. The
structural and behavioural aspects of the
system are represented as they are to be
25
built.
Environment model view. The structural
 2/17/17
DOMAIN ANALYSIS

26
 DOMAIN ANALYSIS
The objective of domain analysis is to

2/17/17
define a set of class or object that
encountered through an application
domain.
These can then reused in many application
Analysis for object-oriented systems can
occur at many different levels of
abstraction 27
 DOMAIN ANALYSIS PROCESS
Software domain analysis is the
identification, analysis, and specification of

2/17/17
common requirements from a specific
application domain, typically for reuse on
multiple projects within that application
domain

28
INPUT AND OUTPUT FOR DOMAIN
ANALYSIS

2/17/17
29
 2/17/17
THE OOA PROCESS

30
 OOA PROCESS

Technique that may used to gather basic

customer requirement and then define an

2/17/17
analysis model for the object oriented
systems are:
Use case
CRC card
Defining Structures and Hierarchies
Defining Subjects and Subsystems

31
 USE CASE
A use case is a methodology used in system
analysis to identify, clarify, and organize

2/17/17
system requirements.
A use case is a written description of how
users will perform tasks on your website.
It outlines, from a users point of view, a
systems behaviour as it responds to a
request.
Each use case is represented as a sequence
of simple steps, beginning with a user's goal
and ending when that goal is fulfilled 32
 BENEFITS OF USE CASES
Use cases add value because they help explain

2/17/17
how the system should behave and in the
process, they also help brainstorm what could go
wrong.
They provide a list of goals and this list can be
used to establish the cost and complexity of the
system.
Project teams can then negotiate which functions
becomerequirementsand are built 33
WHEN WE???

2/17/17
34
EXAMPLE USE CASE FOR LIS

2/17/17
35
 CONT. ..
A use case (or set of use cases) has these
characteristics:

2/17/17
Organizes functional requirements
Models the goals of system/actor (user)
interactions
Records paths (calledscenarios) from trigger
events to goals
Describes one main flow of events (also
called a basic course of action), and possibly
other ones, calledexceptionalflows of
events (also called alternate courses of
action) 36
 CRC CARDS
CRC:- stands for Class, Responsibilities,
Collaborations

2/17/17
A brainstorming tool used in the design of
object-oriented software
a CRC card is an index card in a group
setting used to represent:
A class of objects
Their behavior
their interactions

37
 CRC. ..
A collection of standard index cards that have
been divided into three sections

2/17/17
1. A class represents a collection of similar objects.

2. A responsibility is something that a class knows

or does.
3. A collaborator is another class that a class
interacts with to fulfill its responsibilities

38
EXAMPLE

2/17/17
39
 2/17/17
OBJECT DESIGN PROCESS

40
 OBJECT DESIGN PROCESS
Object design is concerned with the detailed design
of the objects and their interactions.

2/17/17
It is completed within the overall architecture
defined during system design and according to
agreed design guidelines and protocols.
Object design is particularly concerned with the
specification of attribute types, how operations
function, and how objects are linked to other
objects.
It is at this stage that the basic concepts and
principles associated with component level design.

41
 OBJECT DESIGN PROCESS
Object design includes the following phases:

2/17/17
Object identification
Object representation, i.e., construction of
design models
Classification of operations
Algorithm design
Design of relationships
Implementation of control for external
interactions
Package classes and associations into modules
42
 2/17/17
THANK YOU!!

43