0% found this document useful (0 votes)
6 views43 pages

Object-Oriented Analysis and Design Overview

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views43 pages

Object-Oriented Analysis and Design Overview

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

CSC 409 (OOAD)

Lecture 03

OBJECT ORIENTED SYSTEM


OBJECT ORIENTED MODEL

• The object model visualizes the


elements in a software
application in terms of objects.
• The concepts of objects and
classes are intrinsically linked
with each other and form the
foundation of object–oriented
paradigm
OBJECT ORIENTED SYSTEM
Any software development approach goes
through the following stages −
Analysis,
Design, and
Implementation.

In object-oriented software engineering, the


software developer identifies and organizes
the application in terms of object-oriented
concepts, prior to their final representation
in any specific programming language or
software tools
Phases in Object-Oriented Software
Development

The major phases of software


development using object–oriented
methodology are object-oriented
analysis (OOA), object-oriented
design (OOD), and object-oriented
implementation/ Programming (OOP).
Object–Oriented Analysis

Inthis stage, the problem is formulated,


user requirements are identified, and
then a model is built based upon real–
world objects. The analysis produces
models on how the desired system
should function and how it must be
developed. The models do not include
any implementation details so that it can
be understood and examined by any
non–technical application expert.
Object–Oriented Design
Object-oriented
design includes two main stages,
namely, system design and object design

System Design
In this stage, the complete architecture of the
desired system is designed. The system is conceived
as a set of interacting subsystems that in turn is
composed of a hierarchy of interacting objects,
grouped into classes.

System design is done according to both the system


analysis model and the proposed system
architecture. Here, the emphasis is on the objects
comprising the system rather than the processes in
the system
Object Design
In this phase, a design model is developed
based on both the models developed in the
system analysis phase and the architecture
designed in the system design phase. All the
classes required are identified.

The designer decides whether

new classes are to be created from scratch,


any existing classes can be used in their
original form, or
new classes should be inherited from the
existing classes
Object Design
The associations between the identified
classes are established and the
hierarchies of classes are identified.
Besides, the developer designs the
internal details of the classes and their
associations, i.e., the data structure for
each attribute and the algorithms for the
operations.
Object–Oriented Implementation
and Testing

In this stage, the design model developed


in the object design is translated into code
in an appropriate programming language
or software tool. The databases are
created and the specific hardware
requirements are ascertained. Once the
code is in shape, it is tested using
specialized techniques to identify and
remove the errors in the code
Principles of Object-Oriented Systems
Principles of Object-Oriented Systems

The conceptual framework of object–


oriented systems is based upon the object
model. There are two categories of
elements in an object-oriented system

Major Elements − By major, it is meant


that if a model does not have any one of
these elements, it ceases to be object
oriented.

Minor Elements − By minor, it is meant


that these elements are useful, but not
indispensable part of the object model.
Principles of Object-Oriented Systems

Major elements are −


Abstraction
Encapsulation
Modularity
Hierarchy

Minor elements are −


Typing
Concurrency
Persistence
Major Elements: Abstraction

Abstraction means to focus on the essential


features of an element or object in OOP,
ignoring its extraneous or accidental
properties. The essential features are
relative to the context in which the object is
being used.
Grady Booch has defined abstraction as
follows “An abstraction denotes the
essential characteristics of an object that
distinguish it from all other kinds of objects
and thus provide crisply defined conceptual
boundaries, relative to the perspective of
the viewer.”
What is Abstraction?

Salesperso
n
Not saying
Which
salesperso
n – just a
salesperso
n in Product
Customer
general!!!
What is Abstraction?
Major Elements:
Abstraction
Example − When a class Student is
designed, the attributes
enrolment_number, name, course, and
address are included while characteristics
like pulse_rate and size_of_shoe are
eliminated, since they are irrelevant in
the perspective of the educational
institution.
Major Elements:
Encapsulation
Encapsulation is the process of binding
both attributes and methods together
within a class.

Through encapsulation, the internal


details of a class can be hidden from
outside. The class has methods that
provide user interfaces by which the
services provided by the class may be
used.
Encapsulation
Major Elements:
Modularity
Modularity is the process of decomposing a
problem (program) into a set of modules so
as to reduce the overall complexity of the
problem

Booch has defined modularity as


“Modularity is the property of a system
that has been decomposed into a set of
cohesive and loosely coupled modules.”

Modularity is intrinsically linked with


encapsulation. Modularity can be
visualized as a way of mapping
Major Elements:
Hierarchy
In Grady Booch’s words, “Hierarchy is the
ranking or ordering of abstraction”.
Through hierarchy, a system can be made
up of interrelated subsystems, which can
have their own subsystems and so on
until the smallest level components are
reached. It uses the principle of “divide
and conquer”. Hierarchy allows code
reusability.
Major Elements:
Hierarchy
The two types of hierarchies in OOA are
 “IS–A” hierarchy − It defines the hierarchical
relationship in inheritance, whereby from a
super-class, a number of subclasses may be
derived which may again have subclasses and
so on. For example, if we derive a class Rose
from a class Flower, we can say that a rose “is–
a” flower.

 “PART–OF” hierarchy − It defines the


hierarchical relationship in aggregation by
which a class may be composed of other
classes. For example, a flower is composed of
sepals, petals, stamens, and carpel. It can be
said that a petal is a “part–of” flower.
Minor Elements

Typing?
Concurrency?
Persistence?
Object Oriented Analysis
(OOA)
Object Oriented Analysis (OOA)
OOA is categorize into:
 Problem analysis
 System Analysis
 Requirements Elicitation
 Requirements Analysis and
Modeling
 Refining Requirements Model
What is Problem Analysis?
The process of understanding
real-world problems and user
needs and proposing solutions to
meet those needs
The goal of problem analysis is to
gain a better understanding,
before development begins, of
the problem being solved
Problem Analysis Steps:
Gain agreement on the problem
definition
Understand the root causes– the
problem behind the problem
Identify the stakeholders
stakeholders and the and the
users
Define the solution system
boundary
Identify the constraints to be
1. Gain Agreement on the
Problem Definition
Simply write the problem down and see
whether everyone agrees
It is helpful to write the problem in a
standardized format as following
example:
2. Understand the Root
Causes
Variety of techniques to gain
understanding of the real problem
and its real causes --- e.g.,
fishbone diagram
3. Identify the Stakeholders
Understanding of who are the
stakeholders and their particular needs is
an important factor in developing an
effective solution
 The following questions can be helpful in
identifying the stakeholders:

 Who are the users of the system?


 Who is the customer for the system?
 Who else will be effected by the outputs that
the system produces?
 Are there any other internal/external users of
the system whose needs must be addressed?
 Who will maintain the new system?
4. Define the Solution System
Boundary
Defining a system that can be deployed to
address the problem
Determine the boundaries of the solution
system
 System boundary defines the border
between the solution and the real world
that surrounds the solution – describes an
envelope in which the solution system is
contained
System Boundary
The task of defining system
boundary is to determine which
aspects should be covered and
which aspects will not be covered by
the planned system
Need to identify the part of
environment that will interact with
the system – system context
System Boundary
World can be divided into two:
 System – solution system
 Things that interact with the
system
System Context
System Context Using Context
Diagram and Use-Case Diagram
Context Diagrams or Use Case diagrams
are often used to document the system
context
Context diagram – sources and
destinations in the environment (i.e.,
system context) are modeled
 Use Case diagram – actors (e.g. people
or other systems) define the
environment and its relationships with
the use cases of the planned system are
modeled
Context Diagram
Context diagram helps to decide if
requirements applied to the system
or not
Context Diagram shows:
 all external things that communicate with
the system
 Incoming data and information flows the
system must work with
 Outgoing data and information flows produced
by the system
Shows one process – named
‘system’
Context Diagram: An
Example
Context Diagram: An
Example
Use Case Diagram
Structure requirements with use
case diagram (using UML
notation)
Relationship represents
information exchange between
an actor and a use case and
between two use cases
Use Case Diagram: An
Example
5. Identify the Constraints to be
Imposed on the Solution
Constraints are restrictions on the
degrees of freedom we have in
providing a solution
 Potential system constraints:
 Economic – budget
 Political – internal/external issue
 Technical – technology selection
 System – platform and operating
system
 Environmental – standards, legal,
security requirements
 Schedule and resources
Object Oriented Analysis
(OOA)
In the system analysis or object-oriented
analysis phase of software development,
the system requirements are determined,
the classes are identified and the
relationships among classes are identified.
The three analysis techniques that are
used in conjunction with each other for
object-oriented analysis are
• Object modelling
• Dynamic modelling
• Functional modelling

You might also like