OBJECT ORIENTED

ANALYSIS & DESIGN

MARK ESPIRITU
OBJECT-ORIENTED
ANALYSIS
Object–Oriented Analysis (OOA) is
the procedure of identifying
software engineering requirements
and developing software
specifications in terms of a software
system’s object model, which
comprises of interacting objects.
THE PRIMARY TASKS IN OBJECT-
ORIENTED ANALYSIS (OOA) ARE…
•Identifying objects
•Organizing the objects by creating object model diagram
•Defining the internals of the objects, or object attributes
•Defining the behavior of the objects, i.e., object actions
•Describing how the objects interact
OBJECT-ORIENTED
DESIGN
Object–Oriented Design (OOD) involves
implementation of the conceptual model
produced during object-oriented analysis.
In OOD, concepts in the analysis model,
which are technology−independent, are
mapped onto implementing classes,
constraints are identified and interfaces
are designed, resulting in a model for the
solution domain, i.e., a detailed
description of how the system is to be
built on concrete technologies.
THE IMPLEMENTATION
DETAILS GENERALLY
INCLUDE −
•Restructuring the class data (if necessary),
•Implementation of methods, i.e., internal data
structures and algorithms,
•Implementation of control, and
•Implementation of associations
OBJECT-ORIENTED
PROGRAMMING
Object-oriented programming (OOP) is
a programming paradigm based upon objects
(having both data and methods) that aims to
incorporate the advantages of modularity and
reusability. Objects, which are usually instances
of classes, are used to interact with one another
to design applications and computer programs.
THE IMPORTANT FEATURES
OF OBJECT–ORIENTED
PROGRAMMING ARE −
•Bottom–up approach in program design
•Programs organized around objects, grouped in classes
•Focus on data with methods to operate upon object’s data
•Interaction between objects through functions
•Reusability of design through creation of new classes by
adding features to existing classes
 SOME EXAMPLES OF OBJECT-ORIENTED
PROGRAMMING LANGUAGES ARE C++, JAVA,
SMALLTALK, DELPHI, C#, PERL, PYTHON, RUBY,
AND PHP.
THE IMPORTANT FEATURES
OF OBJECT–ORIENTED
PROGRAMMING ARE −
•Bottom–up approach in program design
•Programs organized around objects, grouped in classes
•Focus on data with methods to operate upon object’s data
•Interaction between objects through functions
•Reusability of design through creation of new classes by
adding features to existing classes
OBJECTS AND CLASSES
MARK ESPIRITU
OBJECT
An object is a real-world element in an object–oriented environment that
may have a physical or a conceptual existence. Each object has −
Identity that distinguishes it from other objects in the system.
State that determines the characteristic properties of an object as well as
the values of the properties that the object holds.
Behavior that represents externally visible activities performed by an
object in terms of changes in its state.
Objects can be modelled according to the needs of the application. An
object may have a physical existence, like a customer, a car, etc.; or an
intangible conceptual existence, like a project, a process, etc.
CLASS
A class represents a collection of objects having same characteristic
properties that exhibit common behavior. It gives the blueprint or
description of the objects that can be created from it. Creation of an
object as a member of a class is called instantiation. Thus, object is an
instance of a class.
The constituents of a class are −
A set of attributes for the objects that are to be instantiated from the
class. Generally, different objects of a class have some difference in the
values of the attributes. Attributes are often referred as class data.
A set of operations that portray the behavior of the objects of the class.
Operations are also referred as functions or methods.
INHERITANCE
Inheritance is the mechanism that permits new classes to be
created out of existing classes by extending and refining its
capabilities. The existing classes are called the base
classes/parent classes/super-classes, and the new classes are
called the derived classes/child classes/subclasses. The subclass
can inherit or derive the attributes and methods of the super-
class(es) provided that the super-class allows so. Besides, the
subclass may add its own attributes and methods and may
modify any of the super-class methods. Inheritance defines an
“is – a” relationship.
TYPES OF INHERITANCE
Single Inheritance − A subclass derives from a single super-class.
Multiple Inheritance − A subclass derives from more than one super-
classes.
Multilevel Inheritance − A subclass derives from a super-class which in
turn is derived from another class and so on.
Hierarchical Inheritance − A class has a number of subclasses each of
which may have subsequent subclasses, continuing for a number of levels,
so as to form a tree structure.
Hybrid Inheritance − A combination of multiple and multilevel
inheritance so as to form a lattice structure.
GENERALIZATION AND
SPECIALIZATION
MARK ESPIRITU
GENERALIZATION
In the generalization process, the common
characteristics of classes are combined to form
a class in a higher level of hierarchy, i.e.,
subclasses are combined to form a generalized
super-class. It represents an “is – a – kind – of”
relationship. For example, “car is a kind of land
vehicle”, or “ship is a kind of water vehicle”.
SPECIALIZATION
Specialization is the reverse process of
generalization. Here, the distinguishing
features of groups of objects are used to
form specialized classes from existing
classes. It can be said that the subclasses are
the specialized versions of the super-class.
LINKS AND ASSOCIATION
MARK ESPIRITU
LINK
A link represents a connection through which an
object collaborates with other objects. Rumbaugh
has defined it as “a physical or conceptual
connection between objects”. Through a link, one
object may invoke the methods or navigate
through another object. A link depicts the
relationship between two or more objects
ASSOCIATION
Association is a group of links having common
structure and common behavior. Association
depicts the relationship between objects of one or
more classes. A link can be defined as an instance
of an association.
DEGREE OF AN
ASSOCIATION
Degree of an association denotes the number of classes
involved in a connection. Degree may be unary, binary, or
ternary.

A unary relationship connects objects of the same class.

A binary relationship connects objects of two classes.
A ternary relationship connects objects of three or more
classes.
CARDINALITY RATIOS OF
ASSOCIATIONS
Cardinality of a binary association denotes the number of instances
participating in an association. There are three types of cardinality ratios,
namely −
One–to–One − A single object of class A is associated with a single object
of class B.
One–to–Many − A single object of class A is associated with many
objects of class B.
Many–to–Many − An object of class A may be associated with many
objects of class B and conversely an object of class B may be associated
with many objects of class A.
AGGREGATION OR
COMPOSITION
Aggregation or composition is a relationship among classes by which a class can be
made up of any combination of objects of other classes. It allows objects to be
placed directly within the body of other classes. Aggregation is referred as a “part–
of” or “has–a” relationship, with the ability to navigate from the whole to its parts.
An aggregate object is an object that is composed of one or more other objects.
Example
In the relationship, “a car has–a motor”, car is the whole object or the aggregate,
and the motor is a “part–of” the car. Aggregation may denote −
Physical containment − Example, a computer is composed of monitor, CPU,
mouse, keyboard, and so on.
Conceptual containment − Example, shareholder has–a share.
BENEFITS OF OBJECT
MODEL
The benefits of using the object model are −
•It helps in faster development of software.
•It is easy to maintain. Suppose a module develops an error, then
a programmer can fix that particular module, while the other
parts of the software are still up and running.
•It supports relatively hassle-free upgrades.
•It enables reuse of objects, designs, and functions.
•It reduces development risks, particularly in integration of
complex systems.
BENEFITS OF OBJECT
MODEL
The benefits of using the object model are −
•It helps in faster development of software.
•It is easy to maintain. Suppose a module develops an error, then
a programmer can fix that particular module, while the other
parts of the software are still up and running.
•It supports relatively hassle-free upgrades.
•It enables reuse of objects, designs, and functions.
•It reduces development risks, particularly in integration of
complex systems.
WE KNOW THAT THE OBJECT-ORIENTED
MODELLING (OOM) TECHNIQUE
VISUALIZES THINGS IN AN APPLICATION
BY USING MODELS ORGANIZED AROUND
OBJECTS. ANY SOFTWARE
DEVELOPMENT APPROACH GOES
THROUGH THE FOLLOWING STAGES −
Analysis,
Design, and
Implementation.
WE KNOW THAT THE OBJECT-ORIENTED
MODELLING (OOM) TECHNIQUE
VISUALIZES THINGS IN AN APPLICATION
BY USING MODELS ORGANIZED AROUND
OBJECTS. ANY SOFTWARE
DEVELOPMENT APPROACH GOES
THROUGH THE FOLLOWING STAGES −
Analysis,
Design, and
Implementation.
PHASES IN OBJECT-ORIENTED
SOFTWARE DEVELOPMENT
MARK ESPIRITU
OBJECT–ORIENTED ANALYSIS
In this 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–ORIENTED DESIGN
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–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.
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.
UML ANALYSIS MODEL
MARK ESPIRITU
UNIFIED MODELING
LANGUAGE
The Unified Modeling Language (UML) is a
graphical language for OOAD that gives a standard
way to write a software system’s blueprint. It helps
to visualize, specify, construct, and document the
artifacts of an object-oriented system. It is used to
depict the structures and the relationships in a
complex system.
SYSTEMS AND MODELS IN
UML
System − A set of elements organized to achieve certain
objectives form a system. Systems are often divided into
subsystems and described by a set of models.
Model − Model is a simplified, complete, and consistent
abstraction of a system, created for better understanding of
the system.
View − A view is a projection of a system’s model from a
specific perspective.
CONCEPTUAL MODEL OF
UML
The Conceptual Model of UML
encompasses three major elements −
•Basic building blocks
•Rules
•Common mechanisms
BASIC BUILDING BLOCKS
The three building blocks of UML are −
•Things
•Relationships
•Diagrams
THINGS
Structural Things − These are the nouns of the UML models representing the
static elements that may be either physical or conceptual. The structural things
are class, interface, collaboration, use case, active class, components, and nodes.
Behavioral Things − These are the verbs of the UML models representing the
dynamic behavior over time and space. The two types of behavioral things are
interaction and state machine.
Grouping Things − They comprise the organizational parts of the UML
models. There is only one kind of grouping thing, i.e., package.
Annotational Things − These are the explanations in the UML models
representing the comments applied to describe elements.
RELATIONSHIPS
Relationships are the connection between things. The four types of
relationships that can be represented in UML are −
Dependency − This is a semantic relationship between two things such that a
change in one thing brings a change in the other. The former is the
independent thing, while the latter is the dependent thing.
Association − This is a structural relationship that represents a group of links
having common structure and common behavior.
Generalization − This represents a generalization/specialization relationship
in which subclasses inherit structure and behavior from super-classes.
Realization − This is a semantic relationship between two or more classifiers
such that one classifier lays down a contract that the other classifiers ensure to
abide by.
DIAGRAMS
A diagram is a graphical representation of a system. It comprises of a group of elements generally in the form of a graph. UML
includes nine diagrams in all, namely −

Class Diagram
Object Diagram
Use Case Diagram
Sequence Diagram
Collaboration Diagram
State Chart Diagram
Activity Diagram
Component Diagram
Deployment Diagram
RULES
UML has a number of rules so that the models are semantically
self-consistent and related to other models in the system
harmoniously. UML has semantic rules for the following −
Names
Scope
Visibility
Integrity
Execution
COMMON MECHANISMS
UML has four common mechanisms −
Specifications
Adornments
Common Divisions
Extensibility Mechanisms
UML BASIC NOTATIONS
MARK ESPIRITU
CLASS
A class is represented by a rectangle having three sections
−

• the top section containing the name of the class

• the middle section containing class attributes
• the bottom section representing operations of the class
THE VISIBILITY OF THE ATTRIBUTES
AND OPERATIONS CAN BE REPRESENTED
IN THE FOLLOWING WAYS −
Public − A public member is visible from anywhere in the
system. In class diagram, it is prefixed by the symbol ‘+’.
Private − A private member is visible only from within
the class. It cannot be accessed from outside the class. A
private member is prefixed by the symbol ‘−’.
Protected − A protected member is visible from within
the class and from the subclasses inherited from this class,
but not from outside. It is prefixed by the symbol ‘#’.
Example − Let us consider the
Circle class introduced earlier.
The attributes of Circle are x-
coord, y-coord, and radius. The
operations are findArea(),
findCircumference(), and scale().
Let us assume that x-coord and y-
coord are private data members,
radius is a protected data member,
and the member functions are
public. The following figure gives
the diagrammatic representation
of the class.
OBJECT
An object is represented as a rectangle with two sections −
The top section contains the name of the object with the name of the
class or package of which it is an instance of. The name takes the
following forms −
object-name − class-name
object-name − class-name :: package-name
class-name − in case of anonymous objects
The bottom section represents the values of the attributes. It takes the
form attribute-name = value.
Sometimes objects are represented using rounded rectangles.