Chapter Four

Object-Oriented
Paradigm
1
 Introduction
The object-oriented paradigm took its shape from the
initial concept of a new programming approach,
while the interest in design and analysis methods
came much later.
The first object–oriented language was Simula
(Simulation of real systems) that was developed in
1960
In 1970, the first pure object-oriented programming
language (OOPL) - Smalltalk, for programming
In the 1980s, Grady Booch published a paper titled
Object Oriented Design that mainly presented a
design for the programming language
2
In the 1990s, Coad incorporated behavioral ideas to
 Cont…
In the object-oriented approach, the focus is on
capturing the structure and behavior of
information systems into small modules
The main aim of Object Oriented Design (OOD)
is to improve the quality and productivity of
system analysis and design by making it more
usable.
In analysis phase, OO models are used to fill the
gap between problem and solution.
3It identifies the objects in problem domain,
 Cont…
The object oriented analysis part does not
do well on how the system should be build.
This gap is filled by the design phase that
provides such details for the
implementation.
There are various artifacts that would be
used to model the design of the system that
evolve from the analysis phase

4
 Cont…
The OO model is beneficial in the following
ways
It facilitates changes in the system at low
cost.
It promotes the reuse of components.
It simplifies the problem of integrating
components to configure large system.
It simplifies the design of distributed
systems.
5
 What it is?
• Designing of object oriented design requires
– the definition of a multilayered software
architecture,
– the specification of subsystems that perform
required functions and provide infrastructure
support such interface, business logic and
database layer
– a description of objects (classes) that form the
building blocks of the system such as main
menu, form, etc and
6 – a description of the communication mechanisms
 Cont…
The input for object-oriented design is provided
by the output of object oriented analysis
Realize that an output artifact does not need to
be completely developed to serve as input of
object-oriented design.
Some typical input artifacts for object-oriented
design are; Class diagram, Conceptual model,
Use case, Sequences Diagram and User
interface.
7
 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
Minor Elements − By minor, it is meant that
these elements are useful, but not
indispensable part of the object model. The
three minor elements are −
Typing
Concurrency
8

 Cont….
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. The four major elements are −
Abstraction
Encapsulation
Modularity
Hierarchy

9
Object-Oriented Analysis and
Design

Analysis Design Construction

Investigation
Logical solution Code
of problem
 Object-Oriented Analysis
What is needed? Required functions?
Investigate domain objects.
Do the right thing (analysis)
An investigation of the problem
an emphasis on finding and describing the
objects (or concepts)i.e domain objects.
For example, concepts in a Library
Information System include Book and
Library.
 High level views found in the application
11
domain.
 Cont…
Analysis emphasizes an investigation of the
problem and requirements, rather than a
solution.
In software development, we are primarily
concerned with two forms of analysis.
Requirements Analysis is discovering the
requirements that a system must meet in order
to be successful.
Object-Oriented Analysis is investigating the
12 objects in a domain to discover information
 Cont….
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
13 Describing how the objects interact
 Cont….
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.
14 Object-oriented analysis technique are
 Object Modeling
Object modeling develops the static structure of the
software system in terms of objects.
It identifies the objects, the classes into which the
objects can be grouped into and the relationships
between the objects.
It also identifies the main attributes and operations
that characterize each class.
The process of object modeling can be visualized in the
following steps
Identify objects and group into classes
Identify the relationships among classes
Create user object model diagram
Define attributes user object
15
Define the operations that should be performed on the classes
 Dynamic Modeling
It can be defined as “a way of describing how an
individual object responds to events, either
internal events triggered by other objects, or
external events triggered by the outside world”.
The process of dynamic modeling can be
visualized in the following steps −
Identify states of each object
Identify events and analyze the applicability of
actions
Construct dynamic model diagram, comprising of
state transition diagrams
16
Express each state in terms of object attributes
 Functional Modeling
It shows the processes that are performed within an
object and how the data changes as it moves between
methods.
It specifies the meaning of the operations of object
modeling and the actions of dynamic modeling.
It corresponds to the data flow diagram of traditional
structured analysis.
The process of functional modeling can be
visualized in the following steps −
Identify all the inputs and outputs
Construct data flow diagrams showing functional
dependencies
17
State the purpose of each function
 Object-Oriented Design
Emphasizes a conceptual solution that fulfills
the requirements.
Need to define software objects and how they
collaborate to meet the requirements.
For example, in the Library Information
System, a Book software object may have a title
attribute and a getChapter method.
What are the methods needed to process the
attributes?
Designs are implemented in a programming
18
language.
 Cont…
Conceptual solution that meets
requirements.
Not an implementation
The Solution Domain
The ‘Hows’ of the system
Do the thing right (design)
Define how these software objects
collaborate to meet the requirements.
Attributes and methods.
19
E.g. Describe a database schema and
 Cont…
Object-oriented design includes two main stages,
namely, conceptual design and detailed design.
Conceptual Design
The complete architecture of the desired system is
designed.
It recognizes all classes required to build the
system
Responsibilities are allocated to each class
Use class diagram to analyze relation between
20 class
 Detailed design
Attribute and operation are allocated to each class
based on their interaction diagram
State machine chart is developed to explain the
next detail of design is so called low level design
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.
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
21

 Cont…

22
 UML Perspectives
Conceptual perspective – the diagrams are
interpreted as describing things in a
situation of the real world or domain of
interest.
Specification (software) perspective – the
diagrams describe sw abstractions or
components with specifications and
interfaces, but no commitment to a
particular language implementation.
Implementation perspective – the diagrams
23 describe sw implementations in a particular
 Cont…

24
 Describing an architecture using
UML
All UML diagrams can be useful to describe aspects
of the architectural model
Some UML diagrams are particularly suitable for
architecture modelling and for implementation issues:
Class Type architecture (not in UML)
Component diagrams
Deployment diagrams
Persistent diagram
Package/subsystem diagram
Evolving UI
25
 Class Type Architecture (not in
UML)
A common architectural strategy, some might
call it a pattern, is to layer the architecture of a
system into several layers
Some strategies simply define N layers stacked
on top of each other where layer J interacts only
with layers J-1 and J+1. 
That's an interesting theory, and it clearly makes
sense from a logical point of view, but in
practice it is found that it isn't quite so simple. 
26
 Cont…
The following slide Presents a high-level
layering strategy for a software application.  
The various layers are represented by the
rectangles and collaboration between layers by
the arrows. 
The primary name of a layer is indicated first,
and other common names in parenthesis

27
 Layered class type architecture

28
 Cont…
Interface:
There are two categories of interface class –
user interface (UI) classes that provide people
access to your system and system interface (SI)
classes that provide access to external systems
to your system
Domain
This layer implements the concepts pertinent
to your business domain such as Student or
29 purchase, focusing on the data aspects of the
 Cont…
Process
The process layer implements business logic that
involves collaborating with several domain classes or
even other process classes. Example – student
registration, purchasing
Persistence
Persistence layers encapsulate the capability to store,
retrieve, and delete objects/data permanently without
revealing details of the underlying storage technology.  
Often implement  between your object and database
schema and there are various available to you. 
System
System classes provide operating-system-specific
30 functionality for your applications, isolating your
 Class Modeling
The class model at the design level will add
some additional details than that of the analysis
level class model.
Here the focus will be the solution domain
rather than the problem domain.
In practice, the analysis level class model will
evolve into a design level class model.
This gives the developers the chance to make
amendments and modification to improve the
31 quality of the system.
 Cont…
The design level class model will concentrate on
how to implement attributes methods,
inheritance, association, aggregation,
composition and the likes.
Modeling Methods
Methods, also called operations or member
functions, are the object-oriented equivalent of
functions and procedures.
The design level will model more information
32 about methods than the analysis.
 Cont…
The design level may include:
Visibility: the level of access to methods by
external objects.
To reduce the effect of coupling within a
system, more restrictions on access of methods
should be set.
In other words, if a method does not have to
be public then make it protected and if it does
not have to be protected then make it private.
33
 Cont…
Visibility Symbol Description Proper Usage
Public + A public method can be When the method must be
invoked by any other accessible by objects and classes
method in any other object outside of the class hierarchy in
or class. which the method is defined.

Protected # A protected method can be When the method provides behavior

invoked by any method in needed internally within the class
the class in which it is hierarchy, but not externally.
defined or any subclasses
of that class.

Private - A private method can only
be invoked by other
methods in the class in
which it is defined, but not
in the subclasses.
34
When the method provides behavior
specific to the class. Private
methods are often the result of
refactoring.
 Cont…
Name: Descriptive name for the method. A good name
is the one that is capable of explaining the purpose of
the methods just by looking at its name.
In giving a name to methods the designer needs to know what
programming language will be used for the development so
that the naming convention of that language will be used here.
Parameters: The names of parameters, and optionally
their types and default values (if any);
Return value type: The data type of the return value (if
available)

35
 Cont…
Modeling Attributes
Attributes are the data aspects of objects.
The design level will model more information
about attributes than the analysis.
The design level may include:
Visibility: This is the level of access external
objects have to an attribute.

36
 Cont…
Visibility Symbol Description

Public + A public attribute can be accessed by any other

method in any other object or class.

Protected # A protected attribute can be accessed by any

method in the class in which it is declared or by
any method defined in subclasses of that class.

Private - A private attribute can only be accessed by

method in the class in which it is declared, but
not in the subclasses.
37
 Cont…
Type: The data type of an attribute should be
determined (could be a primitive type, such as
string or int, or a class such as Address.)
Initial value: The initial value for an attribute
should also be indicated (if available).

38
 Cont…
Modeling Association
Objects in any system cannot exist and work alone. For
this reason they need to depend one another or
collaborate with each other.
The dependency and collaboration will help the
development team to define how they interact with each
other.
The collaboration is important as an object needs to know
about another object to work with it.
For each association multiplicity should be modeled,
one on each end of the association line
39
 In Design Minimize coupling and Maximize
cohesion

Coupling is a measure of how much two items, such as classes or

methods, are interrelated. When one class depends on another
class, we say they are coupled.
When one class interacts with another class, but does not know
any of the implementation details of the other class, we say they
are loosely coupled.
A class is coupled to another class when it has knowledge of that
other class.
Low Coupling is important to reduce maintenance.
In high coupling Class A and Class B, a change in B could
necessitate a change in A.
40
 Cont…
Cohesion is a measure of how much an item,
such as a class or method, makes sense.
A good measure of the cohesiveness of
something is how long describing it takes using
only one sentence: the longer it takes, the less
cohesive it likely is. You want to design methods
and classes that are highly cohesive.

41
 Cont…
In other words, it should be completely clear what a
method or class is all about.
A good rule of thumb is if you cannot describe a class
or method with one sentence in less than 15 seconds,
then it probably is not cohesive.
Classes should represent only one kind of object, and
methods should do one thing and one thing well.

42
 Following is an example to compare
Analysis and design versions of a class

Analysis Level Design Level

43
 Collaboration Diagrams
Collaboration Diagrams show the same
information as a sequence diagram.
The emphasis is on the organization of the
objects.
Sequence is shown by including a sequence
number on the message.

18-44
 Collaboration Diagram Example

18-45
 Building Collaboration Diagram
1. place participating objects on the diagram
2. draw the links between the objects using the class
diagrams as your guide
3. add each event by placing the message arrow parallel
between the two objects
4. position the arrow to point from the sender to the receiver
5. number the messages in order of execution
6. repeat steps 3 and 4 until the entire scenario has been
modeled

46
 Statechart Diagrams
Statechart diagrams show class states and the
events that cause them to transition between
states.
It is also called a state transition diagram
An event happens at a specific time and place.
They cause a change of state, or the transition
“fires”
Each time an object changes state, some of its
attributes must change.
18-47
There must be a method to change the attributes.
 Cont…
Statechart diagrams are not created for all classes.
They are created when:
A class has a complex life cycle.
An instance of a class may update its attributes
in a number of ways through the life cycle.
A class has an operational life cycle.
The object’s current behavior depends on what
happened previously.

18-48
 Statechart Example

18-49
 State chart …
A statechart diagram defines the behaviour of a
single object
or of a set of objects related by a collaboration.
It captures the changes in an object throughout
its lifecycle as
they occur in response to internal and external
events.
The scope of a statechart is the entire life of one
object.
50
 State …
Statecharts are composed of:
1) states
 a) initial state
 b) final state
2) events
 a) guard conditions
 b) actions
 c) event syntax
3) complex states
 a) activities
 b) entry actions
 c) exit actions

51
 State
State is the current condition of an object
reflected by the values of its attributes and its
links to other objects.
The initial state identifies the state in which an
object is created or constructed.
The initial state is called a pseudo-state because
it does not really have the features of an actual
state, but it helps clarify the purpose of another
state of the diagram.
52
 Cont…
The final state is the state in which once reached, an
object can never do a transition to another state.
The final state may also mean that the object has
actually been destroyed and can no longer be accessed.
Event is an occurrence of a stimulus that can trigger a
state transition
An event may be:
1) the receipt of a signal, e.g. the reception of an
exception
2) the receipt of a call, that is the invocation of an
operation,
53e.g. for changing the expiration date of a license
Thank You!