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