OBJECT ORIENTED ANALYSIS & DESIGN

OBJECT DESIGN
COMBINING THREE MODELS
 DESIGNING ALGORITHMS

Selecting Algorithms:
Selecting Data Structure:

Selecting Internal Classes & Operations:

Assigning Operations to Classes:

 DESIGN OPTIMIZATION

Adding Redundant Associations:

Redundant Associations do not add any useful information to the analysis model, hence such
associations are not to be present in analysis model. However, in design the redundant
associations are not considered to be useless. In fact they are utilized in such a way that the
efficient access to the classes can be possible. Hence in design, many associations from
analysis model are rearranged, added or omitted for getting optimized performance.
In analysis model the efficient network of associations is not created. But in design model, the
access patterns and relative frequencies for accessing the class are the two factors that are
considered for optimization.
For example – Consider Online Course Reservation System. Following figure represents some
portion of analysis model. The operation Course.findSportman() returns the name of the
students who play sports.

Analysis Model
Now if there are 1000 students out of which only 10 students have skills for sports then for
finding sport-persons a simple loop will execute for 1000 times. This leads to inefficient
execution. To eliminate this problem some improvements can be made. For example, we can
create a hashed instead of unordered linked list. Another solution is to create index for
retrieving the objects that are accessed more frequently.
Referring to above example, if we want to find out the students who speak German and play
sport then we need to iterate through the number of students for many times. Naturally we
will get the less efficient model of execution. In order to improve the performance, we can
use the derived association. The derived association does not add useful information but is
used for fast access. Following figure illustrates this idea

Design Model

Rearranging Execution Order:

IMPLEMENTATION OF CONTROL
As part of the system design, the designer must implement state diagram of the dynamic
model. There are three basic approaches to implement it:

• To use location within the program to hold state.

• Direct implementation of state machine mechanism
• Using concurrent tasks
State as location within a program: The location of control within a program can be used to
represent state of the program. Each state transition corresponds to an input statement. The
control of the program branches depending upon the input event received. In highly nested
procedural code, there must be a procedure, which can handle the supplied input. The state
diagram can be converted to code as follows:
a) Identify the main path through the diagram that leads to normal execution of events.
Identify the names of states along this path. This becomes a sequence of statements
in the program.
b) Identify alternate paths, which branch off the main path. This becomes the conditional
statements in the program.
c) To identify the loops, find out backward paths that branch off the main path. Multiple
backward paths become nested loops in the programs.
d) Remaining states and conditions correspond to exceptional conditions. These
exceptional conditions can be handled through exception handling or including error
subroutines.
However, in this approach the lack of modularity is biggest drawback.

Direct implementation of state machine mechanism: The most direct

approach to implement control is to have a state machine engine class that keeps track of
execution of states and actions. Each object instance maintains its own independent variables
but would call on the state engine to determine the next state and action. The basic flow of
control can be traced by creating stubs of the action routines. A stub contains the minimal
piece of information regarding functions or subroutines. Teach stub can provide its print out
to which it can be combined with other printouts to find the skeleton of the application.

Using concurrent tasks: An object can be implemented as a task in the programming

language or operating system. Events are implemented as inter-task calls using the features
of the language or operating system. Languages, which allow concurrency such as ADA,
Concurrent C etc., can be used to execute tasks concurrently.

Maximize Inheritance: The specialization and generalization relationships are both

reciprocal and hierarchical. Specialization is just the other side of the generalization coin:
Mammal generalizes what is common between dogs and cats, and dogs and cats specialize
mammals to their own specific subtypes. These relationships are hierarchical because they
create a relationship tree, with specialized types branching off from more generalized types.
As you move "up" the hierarchy, you achieve greater generalization. You move up toward
Mammal to generalize that dogs, cats, and horses all bear live young, nurses with milk, have
hair. As you move "down" the hierarchy you specialize. Thus, the cat specializes Mammal in
having claws (a characteristic) and purring (a behavior).
Similarly, when you say that ListBox and Button are Windows, you indicate that there are
characteristics and behaviors of Windows that you expect to find in both of these types. In
other words, Window generalizes the shared characteristics of both ListBox and Button, while
each specializes its own particular characteristics and behaviors.

The definition of classes and operations can be adjusted to make the inheritance tree as
large as possible. It can be done in the following ways.

• Rearranging and adjustment of classes and operations to increase inheritance.

• Abstracting common behavior out of group of classes.
• Use of delegation to share behavior when inheritance is semantically invalid.

Rearranging and adjustment of classes and operations to increase

inheritance: Inheritance leads to reusability of already existing functionality. Inheriting
more and more functions can increase the level of reusability. However, greater inheritance
requires that functions definitions must be modified in a sense that same function can serve
the purpose for multiple classes. The following adjustments can be used to increase the level
of inheritance.

• Some operations may have fewer arguments than others. The missing arguments can
be supplied in the function definition and they may be ignored.
• Similar attributes in different classes may have the different names. These attributes
may be moved to a common ancestor class.
• Some operations may have fewer arguments because they are special cases of more
general arguments. These special operations can be implemented by calling the
general operations with appropriate parameters
• An operation may be defined on several different classes in a group but may not be
required in other classes. In that case the operation can be defined as a common
ancestor class and can be declared as no-operation on the classes that don’t care
about it.

Abstracting common behavior out of group of classes: During the design

phase, new classes and operations are often added which generally may lead to commonality
between classes. In this case, a common super class can be created that implements the
shared features of the classes. The subclasses may be derived from super class and may
implement their own specialized features. Usually the resulting super class is an abstract class,
meaning that there are no direct instances of it, but all its operations can be defined and
implemented by subclasses. This leads to reusability of the code.
Sometimes there may be only one subclass, even in that case it is advisable to abstract out a
super class. It is quite possible that new subclasses may be added during project development
life cycle or in future the scope of the project may be increased. The splitting of a class into
two classes that separate the specific aspects from the more general aspects is a form of
modularity. The creation of abstract super classes also improves the extensibility of a software
product.
Use of delegation to share behavior when inheritance is semantically
invalid:
• Inheritance is the most commonly used method of implementation of generalization
where the behavior of a super class is shared by all its sub classes. Operations of the
subclass that override the corresponding operation of the super class have a
responsibility to provide the same services as provided by the super class.
• Sometimes the concept of inheritance is used to utilize already existing functionality
with no intention to provide similar behavior of sub class as of super class. For example
there may exist a class list, which implements a no. of operations i.e addition, deletion
or modification of elements at any place in the list. Any programmer who wants to
create a stack class may be tempted to use already existing list class. However, stack
just requires two main operations i.e. push and pop. Extra operations already existing
in the list class will also be inherited in the stack class, which may cause some side
effects.
• This can be avoided by making one class an attribute or associate of the other class. In
this way, one object can selectively invoke the desired functions of another class, using
delegation rather than inheritance.

OBJECT REPRESENTATION
The object designer has to choose when to use primitive types in representing the objects or
when to combine the groups of objects. A class can be defined in terms of other classes but
ultimately all data members have to be defined in terms of builtin data types supported by a
programming language. For example, roll no. can be implemented as integer or string. In
another example, a two dimensional can be represented as one class or it can be
implemented as two classes – Line class and Point class.

PHYSICAL PACKAGING
Modularity is the property of a system that has been decomposed into a set of cohesive and
loosely coupled modules. Modules serve as the physical containers in which we declare the
classes and objects of our logical designs. A module can be edited, compiled or imported
separately. Different object-oriented programming languages support the packing in different
ways. For example, Java supports in the form of package, C in the form of header files etc.

Modules are program units that manage the visibility and accessibility of names. Following
purposes can be solved by modularity.
A module typically groups a set of class definitions and objects to implement some service
or abstraction.

• A module is frequently a unit of division of responsibility within a programming team.

A module provides an independent naming environment that is separate from other
modules within the program.
• Modules support team engineering by providing isolated name spaces.
Packaging involves the following three issues:

• Information Hiding
• Coherence of Entities
• Constructing Physical Modules

Information Hiding: During analysis phase we are not concerned with information
hiding. So, visibilities of class members are not specified during analysis phase. It is done
during object design phase. In a class, data members and internal operations should be
hidden, so, they should be specified as private. External operations form the interface so they
should be specified as public.
The following design principles can be used to design classes:

• A class should be given the responsibilities of performing the operations and proving
information contained in it to other classes.
• Calling a method of that class should access attributes of other class.
• Avoid traversing associations that are not connected to this class.
• Define interfaces at the highest level possible.
• External objects should be hidden. Defining interface classes could do this.
• Avoid applying a method to the result of another class unless the result class is already
a supplier of methods to the caller class.

Coherence of Entities: Module, class, method etc. are entities. An entity is said to
coherent, if it is organized on a consistent plan and all its parts fit together toward a common
goal.

• Policy is the making of context-dependent decisions while implementation is the

execution of fully specified algorithms. Policy involves making decisions, gathering
global information and interacting with the external agents. Policy and
implementation should be separated in different methods i.e. both should not be
• combined into a single method.
• A policy method does not have complex algorithms rather invokes various
implementation methods. It can contain I/O statements, conditional statements and
can access data stores.
• An implementation method does exactly one operation, without making any decision,
assumption, default or deviation. All its information is supplied by arguments. These
 methods do not contain any context-dependent decision so they are likely to be
reusable.

Constructing Physical Modules: Modules of analysis phase have changed as more

classes and associations have been added during object design phase. Now, the object
designer has to create modules with well-defined and minimal interfaces. The classes in a
module should have similar kinds of things in the system. There should be cohesiveness or
unity of the purpose in a module. So the classes, which are strongly associated, should be put
into a single module.
 Difference between SA/SD & OMT

Sr.
SA/SD OMT
No.

It manages system around real

1 It manages a system around procedures.
world objects.

More importance is on object

More importance is on functional model and less
2 model and less on functional
on object model.
model.

Dominance order is object,

3 Dominance order is functional, dynamic and object.
dynamic and functional.

4 It is a historical approach. It is much advanced approach.

It clearly marks the system boundaries across System boundries can be easily
5 which software procedures should communicate extending by adding new objects,
with real world. It is difficult to extend boundries. relationships.

Decomposition of process to sub-process is not Decompsition is based on objects

6 standardized. Different people provide different so different people provide similar
decomposition. decomposition.

Reusablity of components across

Reusability of components across projects is less
7 projects is more as compared to
as compared to in OMT.
SA/AD.

8 Not easily modifiable and extensible. Easily modifiable and extensible.

Used when data is more important

9 Used when functions are more important than data.
than functions.

Difficult to merge programming code organized It better integrates data with

10 about functions while database is organized around programming code as database is
data. organized around data.