Block 2

Object Oriented Design
UNIT 2 OBJECT DESIGN

Structure Page Nos.
2.0 Introduction 20
2.1 Objectives 20
2.2 Object Design for Processing 20
2.3 Object Design Steps 21
2.4 Choosing Algorithms 23
2.4.1 Selecting Data Structure
2.4.2 Defining Internal Classes and Operations
2.4.3 Assigning Responsibility for Operation
2.5 Design Optimization 24
2.6 Implementation of Control 26
2.6.1 State as Location within a Program
2.6.2 State Machine Engine
2.6.3 Control as Concurrent Tasks
2.7 Adjustment of Inheritance 27
2.7.1 Rearranging Classes and Operations
2.7.2 Abstracting Out Common Behavior
2.8 Design of Associations 28
2.8.1 Analyzing Association Traversal
2.8.2 One-way Associations
2.8.3 Two-way Associations
2.9 Summary 29
2.10 Solutions/Answers 29
2.0 INTRODUCTION
Strategies that are selected in system design are carried out in object-oriented design.
In this process, objects that are identified during the analysis are implemented in a
way that it minimizes memory, execution time and other associated costs. All this is
done by the selection of appropriate algorithms, optimizations, and by enforcing
proper. Controls.
In this unit, we will cover the concepts of object design for process, proper algorithm
selections, design optimization and control implementation, with proper adjustment of
inheritance.
2.1 OBJECTIVES
After going through this unit, you should be able to:
explain the steps of object design;
discuss algorithms that minimize costs;
select appropriate data structure to the algorithm;
define new internal classes and operations;
assign responsibility for operation to the appropriate classes; and
explain different types of associations.
2.2 OBJECT DESIGN FOR PROCESSING

The object design phase comes after the analysis and system design. The object design
phase adds implementation details such as restructuring classes for efficiency, internal
data structures and algorithms to implement operations, implementation of control,
20
implementation of associations and packaging into physical modules. Object design Object Design
extends the analysis.
As you know, there are three models that define the operations on classes:
1) Object model: This describes the classes of objects in the system, including
their attributes, and the operations that they support. The analysis object model
information definitely exists in some form in design. For this, sometimes new
redundant classes are added which increase efficiency.
2) Functional model: This defines the operation that the system must implement.
For each operation, from the analysis model must be assigned an algorithms that
implements clearly and efficiently, according to the optimization goals selected
during system design. In this model, we map the logical structure of the analysis
model into a physical organization of a program.
3) Dynamic model: The dynamic model describes how the system responds to
external events. The implementation of control of flow in a program must be
realized either explicitly or implicitly. Explicit means by the internal scheduler
that recognizes events and map them into operation calls. Implicit means by
choosing algorithms that perform the operations in a specified order.
Now let us see how object design is done for systems.
2.3 OBJECT DESIGN STEPS

Object design is a very iterative process in which several classes (maybe newly
created), relationships between objects, are added when you move from one level to
another level of the design.
There are certain steps to be followed in this design:
1) Classify the operations on classes
This step basically means all the three models, functional, object and dynamic
(studied in last section) must be combined so as to know what operations are to be
performed on objects.
We can make a state diagram describing the life history of an object. A transition is a
change of state of object and it maps into an operation on the object. It helps in
visualizing state changes. We can associate an operation with each event received by
an object. Also, sometimes an event may represent an operation on another objects
i.e., where one event triggers another event. Thus, in this case, the event pair must be
mapped into an operation performing action and returning control, provided that the
events are on a single thread of control passing from object to object.
Any action initiated by transition in a state diagram can be expanded into an entire
data flow diagram in the functional model. The processes in a data flow diagram
consist of sub-operations which may be operational on the original target object, or on
other objects. We can determine the target object of a sub-operation as follows:
i) If the process extracts a value from I/P flow=> input, flow is target.
ii) If the process has the same type of input and output flow and O/P value is
the updated version of I/P => I/O, flow is target.
iii) If the process has an I/P from or an O/P to a data source => data, source
is a target of the process.
iv) If the process constructs O/P value from a number of inputs => operation
is class operation on the output class.
2) Design an algorithm to implement operations
Each and every operation specified in a functional model should be formulated as an
algorithm. The algorithm indicates how the operation is done rather than what it does,
as in analysis specification.
21
Object Oriented Design The algorithm designer must:
i) Select the proper algorithm so as to minimize implementation cost
ii) Find the most appropriate data structure for the selected algorithm
iii) Define new internal classes and operations, if required
iv) Assign responsibility for operations to appropriate classes.
In the next section, we will discuss algorithm selection in more detail.

3) Optimization of data access paths
Optimization is a very important aspect of any design. The designer should do the
followings for optimization:
i) Add redundant associations, or omit non-usable existing associations to
minimize access cost and maximize convenience
ii) Rearrange the order of computational tasks for better efficiency
iii) Save derived attributes to avoid re-computation of complicated expressions.
4) Implementing software control
To implement software control the designer must redesign the strategy of the state
event model that is present in the dynamic model.
Generally, there are three basic approaches to implement the dynamic model. These
approaches are:
i) Storing state of program as location within a program, i.e., as a procedure
driven system
ii) Direct implementation of a state machine mechanism i.e., event driver
iii) Using concurrent tasks.
5) Adjustment of inheritance
The inheritance can be increased as the object design progresses by changing the class
structure. The designer should:
i) Adjust, or rearrange the classes and operations
ii) Abstract common behavior out of groups of classes
iii) Use delegation to share behavior when inheritance is semantically incorrect.
6) Design of associations
During the object design phase we must make a strategy to implement the
associations. Association can be unidirectional or bi-directional. Whichever
implementation strategy we choose, we should hide the implementation, using access
operations to traverse and update the associations. This will allow us to change our
decision with minimal effort. The designer should:
i) Analyze the path of associations.
ii) Implement every association either as a distinct object, or as a link to another
object.
7) Determine object representation
As a designer, you must choose properly when to use primitive types in representing
objects, and when to combine groups of related objects, i.e., what is the exact
representation of object attributes.
8) Package classes and associations into models
Programs are made of discrete physical units that can be edited, complied, imported or
otherwise manipulated. The careful partitioning of an implementation into package is
important for group work on a program. Packaging involves the following issues:
22
a. Information hiding Object Design
b. Collection of entities
c. Constructing physical modules with strong coupling within each module.
) Check Your Progress 1

1) Describe briefly the models that define the operations on classes.

2) What is object design?

3) In object oriented design, what steps must the designer take to adjust
inheritance?

Algorithm selection is a very important part of design. It reflects the happening in the
system. In the next section we will discuss algorithm selection.
2.4 CHOOSING ALGORITHMS

In general, most of the operations are simple and have a satisfactory algorithm
because the description of what is to be done also indicates how it is to be done. Most
of the operations in the object link network simply traverse to retrieve or change
attributes or links. Non-trivial algorithms are generally required for two reasons:
i) If no procedural specification is given for functions
ii) If a simple, but inefficient algorithm serves as a definition of function.
There are a number of metrics for selecting best algorithm:
i) Computational complexity: This refers to efficiency. The processor time
increases as a function of the size of the data structure. But small factors of
inefficiency are insignificant if they improve the clarity.
ii) Ease of use: A simple algorithm, which is easy to implement and understand,
can be used for not very important operations.
iii) Flexibility: The fully optimized algorithm is generally less readable and very
difficult to implement. The solution for this is to provide two implementations
of crucial operations:
A complicated but very efficient algorithm
A simple but inefficient algorithm.
Now, let us see the basic activities that are involved in algorithm selection and
expression.
2.4.1 Selecting Data Structure
Algorithms work on data structure. Thus, selection of the best algorithm means
selecting the best data structure. The data structures never add any information to the
23
Object Oriented Design analysis model, but they organize it in a form that is convenient for the algorithms that
uses it. Many such data structure include arrays, lists, stacks, queues, trees, etc.
Some variations on these data structures are priority queues, binary trees, etc. Most
object oriented languages provide various sets of generic data structures as part of
their predefined class libraries.
2.4.2 Defining Internal Classes and Operations
When we expand algorithms, new classes can be added to store intermediate results. A
complex operation can be looked at as a collection of several lower level operations
i.e., a high level operation is broken into several low level operations. These lower
level operations should be defined during the design phase.
2.4.3 Assigning Responsibility for Operation
Many operations may have obvious target objects, but some of these operations can
be used at several places in an algorithm, by one of several objects. These operations
are complex high level operations which may be overlooked in laying out object
classes as they are not an inherent part of any one class.
Now, the obvious question is, how do you decide what class owns an operation? It is
easy when only one object is involved in the operation: You are simply informing an
object to perform the operation. But when more than one object is involved in an
operation it becomes quite difficult. Thus, we must know which object plays the main
role in the operation. For this, ask yourself the following questions:
Is an object acted on when another object performs action? In general, we
should associate the operation with the target of the operation, instead of the one
initiating it.
Whether an object is modified by the operation or when other objects are only
performing query for getting some information from it. The object that is
changed as in the whole process known as the target of the operation.
Which class is the center of all classes and associations involved in the
operation? If the classes and associations form a star around a single class, it is
the target of the operation.
If the object is some real world object represented internally, then what real
object would you push, move, activate, or otherwise manipulate to initiate the
operation?
2.5 DESIGN OPTIMIZATION

The inefficient but correct analysis model can be optimized to make implementation
more efficient. To optimize the design, the following things should be done:
a) Adding Redundant Associations for Efficient Access
Redundant associations do not add any information, thus during design we should
actually examine the structure of object model for implementation, and try to establish
whether we can optimize critical parts of the completed system. Can new associations
be added, or old associations be removed? The derived association need not to add
any information to the network, they help increasing the model information in
efficient manner.
We can analyze the use of paths in the association network as follows:
Evaluate each operation
Find associations that it must pass through to get information. Associations can
be bi-directional (generally by more than one operation), or unidirectional,
which can be implemented as pointers.
24
For each operation, we should know the followings: Object Design
How frequently is the operation needed, and how much will it cost?
What is the fan-out along a path through the network? To find fan-out of the
complete path, multiply the average count of each many associations found in
the path with individual fan-outs.
What are the objects that satisfy the selection criteria (if specified) and are
operated on? When most of the objects are rejected during traversal for some
reason, then a simple nested loop may be inefficient at finding target objects.
b) Rearranging the Execution Order for Efficiency
As we already know algorithm and data structure are closely related to each other, but
data structure is considered as the smallest but very important part of algorithm. Thus,
after optimizing the data structure, we try to optimize the algorithm itself.
In general, algorithm optimization is achieved by removing dead paths as early as
possible. For this, we sometimes reverse the execution order of the loop from the
original functional model.
c) Saving Derived Attributes to Avoid Recomputation
Data which is derived from other data should be stored in computed form to avoid
re-computation. For this, we can define new classes and objects, and obviously, these
derived classes must be updated if any base object is changed.
Attribute Attribute
Attribute
{ordered} text list {ordered} Text /
Class box
location
Class box region
{ordered}
Location
Operation location
Operation
text list {ordered} Operation
region Text /
location
Figure 1: Derived attribute to avoid recomputation
Figure 1 shows a use of derived object and derived attribute in OOM. Each class
box contains an ordered list of attributes and operations, each represented as a next
string (Figure 1(a)). We can find the location of any attribute by adding the size of all
elements in front of it, to the location of the class box itself [note: it is quite similar to
the array address calculation]. If a new attribute string is added to the list, then the
locations of the ones after it in the list are simply offset by the size of the new
element. If an element is moved or deleted, the elements under it must be redrawn.
Overlapping elements can be found by scanning all elements in front of the deleted
element in the priority list for the sheet and comparing them to the deleted element.
If the number of elements is large, this algorithm grows linearly in the number of
elements.
As discussed earlier, the change in base object should update the related derived
classes. There are three ways to know when an update is required: by explicit code,
by periodic recomputation, or by using active values.
Explicit update: Every derived attribute is expressed as set of basic base objects. The
designer finds the derived attributes that were affected by change in basic attributes.
Then, he inserts code into the update operation on the base object to explicitly update
the depending derived attributes.
Periodic re-computation: Generally, base values are updated in groups. Thus, all the
derived attributes can be recomputed periodically, instead of after every base value
change.
25
Object Oriented Design Active Value: An active value is a value that has dependent values and update
operations. Each dependant value is registered to an action value. Updation operation
of base value triggers that updates of all dependant values and the calling code need
not explicitly invoke the updates.

1) What are the metrics for choosing the best algorithm?

2) What are the ways of finding out whether an update is required or not for
derived attributes?

3) Give an example of an active value.

Every program passes through several states, and these states are defined by
implementing appropriate controls. In the next section, we will discuss
implementation of controls.
2.6 IMPLEMENTATION OF CONTROL

As we know, controls are implemented around states and tasks (maybe concurrent
tasks). Now, let us see three different implementation:
2.6.1 State as Location within a Program
In this traditional approach, the location of control within a program implicitly defines
the program state. Any finite state machine can be implemented as a program (easily
by using gotos).
One technique for converting a state diagram to code is as follows:
i) Identify the main control path. Starting with the first state, find a path from the
diagram which corresponds to the expected sequence of events. Keep the names
of states in a linear sequence that now forms a sequence of statements in the
program.
ii) Identify alternate paths that branch off the main path and later joined again.
These become conditional statements in the program.
iii) Identify loops i.e., the backward paths branching off from main path, and
earlier. Multiple backward paths that not crossing over form nested loops.
iv) Left out states transitions correspond to exception conditions which can be
tackled by exception handling, or error routines, or even by setting and testing
of status flags.
2.6.2 State Machine Engine
The most direct approach to implement control is to have some way of explicitly
representing and executing state machines. With this approach, we can make outline
of the system where classes from object model are defined, state machines from
dynamic model are given, and stubs of action routines can be created. A stub is the
minimal definition of a function of a subroutine without any internal code. By
using of object oriented language, the state machine mechanism can easily be created.
26
2.6.3 Control as Concurrent Tasks Object Design
As you know, any object can be implemented as a task in the programming language,
or operating system. This is the most general approach because it keeps the inherent
concurrency of real objects. Events are implemented as inter-task calls and as such,
the task uses its location within the program to keep track of its state.
As we have discussed adjusting inheritance is one of the steps of object design. In the
next section, we will discuss how inheritance is adjusted.
2.7 ADJUSTMENT OF INHERITANCE

During object design, inheritance is readjusted by rearranging classes and operations,
and abstracting common behavior.
2.7.1 Rearranging Classes and Operations
The different, yet similar, operation of different classes can be slightly modified so
that they can be covered by a single inherited operation. The chances of inheritance
can be increased by the following kind of adjustments:
i) Some operations needs less arguments than other similar operations, like
drawing an object, e.g., circle, rectangle, etc., with, or without, color fill. Thus,
the attribute color can be accepted, or ignored for consistency with color
displays.
ii) Some operations need less argument than other, because they are special case of
general arguments. Thus, varied newer operation can be implemented by calling
general operation and new argument values. For example, insertion in the
beginning or end of the list are special cases of insertion in the list.
iii) Different classes can have similar attributes, but different names. Thus, they can
be combined and placed in the base class so that the operation to access the
attribute may match in different classes.
iv) Sometimes an operation is required by a subset of classes. In this case, declare

the operation in base class, and all those derived classes that do not need it can
be declared as no-operation.
2.7.2 Abstracting Out Common Behavior

Inheritance is not always recognised during the analysis phase of development, so it
is necessary to re-evaluate the object model to find common operations between
classes. Also, during design, new classes and operations may be added. If a set of
operations and/or attributes seems to be repeated in two classes, then it indicates that
the two classes are specialised variation of the same general class.
When common behavior is recognised, a common super class can be created which
implements the shared features, leaving only the specialized features in the derived
classes. This transformation of the object model is called abstracting out a common
super class or a common behavior.
The creation of an abstract super class also improves the extensibility of a software
product.
Associations are useful for finding access paths between objects in the system. During
object design itself, we should implement associations. In the next section we will
discuss the designing of a association.
27
2.8 DESIGN OF ASSOCIATIONS
Before designing associations, it is necessary to know the way they are used. For this,
analysis of association traversals is necessary. It also important to find out whether the
association is one-way association or two-way association.
2.8.1 Analyzing Association Traversal
Till now, we have assumed that associations are bi-directional. But in the case of
traversal in only one direction in any application, the implementation becomes easier.
However, for finding unidirectional associations we need to be extra cautious, as any
new operation added later may be required to traverse the association in the opposite
direction also. The bi-directional association makes modification, or expansion easier.
To change our decision of implementation strategy with minimum effort, we should
hide the implementation, using access operations to traverse and update the
association.
2.8.2 One-way Associations
When an association is traversed in only one direction, then it is implemented as a
pointer, i.e., an attribute that contains an object reference. If the multiplicity is one
as shown in Figure 2, then it is simple pointer; otherwise it is a set of pointers.
Work-for
Teacher School
Teacher School
Math _Teacher Math_Students
Figure 2: Implementation of a one-way association using pointers
2.8.3 Two-way Associations

Mostly, associations are traversed in both directions, although not usually with equal
frequency. There are three approaches for implementation.
In bi-directional associations, if one direction association is rarely used, then we
should implement this as unidirectional association. Searching can perform the
reverse association. This way, we can reduce the storage and update cost.
Implementing it as a bi-directional association using the different techniques
discussed in previous sections will turn up as shown in Figure 3. This approach
gives faster access but also requires the updation of other attributes in case of
any change a otherwise the link will become inconsistent.
Work-for
Teacher School
Teacher School
English_ Students
Teacher
Set
English Students
Figure 3: Implementation of two-way association, using pointer
28
Implementing it as a distinct association object, i.e., independent of either class Object Design
as shown in Figure 4. The association object may be implemented using two
objects: one in forward direction, and the other in the reverse direction. This
increases efficiency when hashing is used, instead of attribute pointer.
Teacher (School)
Teacher
Teacher
Teacher (School)
Teacher
Figure 4: Implementation of association as an object
This approach is suitable in situations where modify action is minimal, or almost nil.

1) List the steps for converting the state diagram to code.

2) What kinds of adjustments are required to increase the chances of inheritance.

3) What is the advantage of two-way association?

2.9 SUMMARY
This unit explains that the design model is driven by the relevance to computer
implementation. The design model must be reasonably efficient and practical to
encode. It consists of optimizing, refining and extending the object model, dynamic
model and functional model until they are detailed enough for implementation.
In this unit, we have discussed the steps taken in object design: what the approach
should be for algorithm selections, how design is optimized by providing efficient
access and rearranging execution order, by avoiding recomputation. This unit also
discussed controls implementations, and in the last section of this unit, issues related
to design of associations were discussed.
2.10 SOLUTIONS/ANSWERS
Check Your Progress 1
1) The three models that are used to define operations on classes are:
Object Model = Object model diagram + data dictionary
Dynamic Model = State diagrams + global event flow diagram
Functional Model = Data flow diagrams + constraints.
2) Object design is a very interactive process, which decides the relationship
between objects, classifies operations on classes, designs algorithms
associations, and determines overall system representation.
29
Object Oriented Design 3) To readjust the inheritance the following steps should be taken:
i) Rearrange and adjust classes operations to increase inheritance.
ii) Abstract common behaviour out of groups of classes.

1) Matrices for choosing the best algorithms are:
Computational complexity
Ease of implementation and understandability
Flexibility.
2) The ways to find out whether an update is required or, not are:
Explicit update
Periodic recomputation
Active values
3) One example of active value is gross salary, which has values as TA, DA, HRA,
etc.
1) a) Finding main control path
b) Finding conditional statements
c) Finding loops
d) Finding exception handling, and error routines.
2) a) Some attributes can be added, or ignored in base class operation
b) Some variations can be made in derived class from abstract classs.
c) If an operation is not required by some classes in a group, then can it be
declared as no-operation.
d) Similar attributes can be combined in one abstract base class.
3) Two-way association has following advantages:
a) Independent of classes.
b) Useful for existing predefined classes which are not modified.
30
Advance Object Design
UNIT 3 ADVANCE OBJECT DESIGN
Structure Page Nos.
3.0 Introduction 31
3.1 Objectives 31
3.2 Control and its Implementation 32
3.2.1 Control as a State within Program
3.2.2 Control as a State Machine Engine
3.2.3 Control as Concurrent Task
3.3 Inheritance Adjustment 35
3.4 Association: Design 37
3.5 Object Representation 38
3.6 Design Optimization 39
3.7 Design Documentation 43
3.8 Summary 43
3.0 INTRODUCTION
As discussed earlier analysis is the first step of the OMT methodology. It is concerned
with devising a precise, concise, understandable and correct model of the realworld.
For example, before building any complex thing, such as a house, a bridge, or a
hardware-software system, the builder must understand the requirement of the user,
and it is also necessary to know the realworld environment in which it will exist.
The advanced object design is a complex task. The objects discovered during analysis
serve as a skeleton of the design. The operations identified during analysis should be
expressed as algorithms. Advanced object oriented design is basically a process of
refinement, or adding the details to the body of an object.
In this unit, you will learn how to design a formal and rigorous model of real-world
problems by applying the findings of the analysis phase of OMT. The object design
phase determines the complete definition of classes and associations used in the
implementation. The advanced object design is a process to create architecture of the
realworld problems. The advanced object design is analogous to the preliminarily
design phase of the traditional software development cycle.
3.1 OBJECTIVES
After studying this unit, you should be able to:
combine the three OOAD models to obtain operations on classes;
design algorithms to implement operations on classes;
optimize access paths to data;
implement control for external interactions;
adjust class structure to increase inheritance;
design association;
determine object representation, and
package classes and association into modules.
31
3.2 CONTROL AND ITS IMPLEMENTATION
In this unit, we will start our discussion with explanation of state-event models.
Let us define an state-event model. State-event model is a model which shows the
sequence of events happening on an object, and due to which there are changes in the
sate of an object. In the state-event model, the events may occur concurrently and
control resides directly in several independent objects. As the object designer you
have to apply a strategy for implementing the state event model. There are three basic
approaches to implementing system design in dynamic models. These approaches are
given below:
Using the location within the program to hold state (procedure-driven system).
Direct implementation of a state machine mechanism (event-driven system).
Using concurrent tasks.
3.2.1 Control as State within Program

1. The term control literally means to check the effect of input within a program.
For example, in Figure1, after the ATM card is inserted (as input) the control of
the program is transferred to the next state (i.e., to request password state).
2. This is the traditional approach to represent control within a program. The
location of control within a program implicitly defines the program state. Each
state transition corresponds to an input statement. After input is read, the
program branches depending on the input event produce some result. Each input
statement handles any input value that could be received at that point. In case of
highly nested procedural code, low-level procedures must accept inputs that
may be passed to upper level procedures. After receiving input they pass them
up through many levels of procedure calls. There must be some procedure
prepared to handle these lower level calls. The technique of converting a state
diagram to code is given as under:
a) Identify all the main control paths. Start from the initial state; choose a path
through the diagram that corresponds to the normally expected sequence of
events. Write the names of states along the selected path as a linear sequence.
This will be a sequence of statements in the program.
b) Choose alternate paths that branch off the main path of the program and rejoin it
later. These could be conditional statements in the program.
c) Identify all backward paths that branch off the main loop of the program and
rejoin it earlier. This could be the loop in the program. All non-intersecting
backward paths become nested loops in the program.
d) The states and transitions that remain unchecked correspond to exception

conditions. These can be handled by applying several techniques, like error
subroutines, exception handling supported by the language, or setting and
testing of status flags.
To understand control as a state within a program, let us take the state model for the
ATM class given below in Figure 2 showing the state model of the ATM class and the
pseudo code derived from it. In this process first, we choose the main path of control,
this corresponds to the reading of a card querying the user for transaction information,
processing the transaction, printing a receipt, and ejecting the card. If the customer
wants to process for some alternates control that should be provided. For example, if
the password entered by the customer is bad, then the customer is asked to try again.
32
Main Screen
insert card
Request Password
enter password
Verify account
account OK
bad account
Request type
enter type
Request amount
enter amount
Process transaction
transaction failed transaction succeed
Dispense cash
take cash
Request continuation
Finish
Take card Take card
Card rejected
Figure 1: Control of states and events in ATM

Pseudocode of ATM control. The pseudocode for the ATM is given as under:
do forever
display main screen
read card
repeat
ask for password
read password
verify account
until account verification is OK
repeat
repeat
ask for type of transaction
read type
ask for amount
read amount
start transaction
wait for it to complete
until transaction is OK
dispense cash
wait for customer to take it
ask whether to continue
until user asks to terminate
eject card
wait for customer to take card
33
Object Oriented Design These lines are the pseudocode for the ATM control loop, which is another form of
representation of Figure 1. Furthermore, you can add cancel event to the flow of
control, which could be implemented as goto exception handling code. Now, let us
discuss controls as a state machine engine.
3.2.2 Control as a State Machine Engine
First let us define state machine: the state machine is an object but not an
application object. It is a part of the language substrate to support the syntax of
application object. The common approach to implement control is to have some way
of explicitly representing and executing state machines. For example, a general state
machine engine class could provide the capability to execute a state machine
represented by a table of transitions and actions provided by the application. As you
know, each object contains its own independent state variable and could call on the
state engine to determine the next state and action.
This approach helps to quickly progress from the analysis model to a skeleton
prototype of the system by defining classes from the object model, state machines
from the dynamic model, and creating stubs of the action routines. A stub could be
stated as the minimal definition of a function or subroutine without any internal
code. Thus, if each stub-prints out its name, this technique allows you to execute the
skeleton application to verify that the basic flow of control is correct or not.
State machine mechanisms can be created easily using an object oriented language.
3.2.3 Control as Concurrent Tasks
The term control as concurrent task means applying control for those events of the
object that can occur simultaneously. An object can be implemented as a task in the
programming language or operating system. This is the most general approach of
concurrency controls. With this you can preserve the inherent concurrency of real
objects. You can implement events as inter-task calls using the facilities of the
language, or operating system.
As far as OO programming languages are concerned, there are some languages, such
as Concurrent Pascal or Concurrent C++, which support concurrency, but the
application of such languages in production environments is still limited. Ada
language supports concurrency, provided an object is equated with an Ada task,
although the run-time cost is very high. The major object oriented languages do not
yet support concurrency.
1) Briefly explain state diagram by taking one example.

.
..
2) Explain concurrent task by taking a suitable example.
.
..
..
3) Explain the following terms.
Event, State, and Operation with respect to the advanced object modeling
concept.
.
.
34
3.3 INHERITANCE ADJUSTMENT
As you know in object oriented analysis and design the terms inheritance defines a
relationship among classes, wherein one class shares the structure or behavior defined
in one or more classes. As object design progresses, the definitions of classes and
operations can often be adjusted to increase the amount of inheritance. In this case, the
designer should:
Rearrange and adjust classes and operations to increase inheritance
Abstract common behavior out of groups of classes
Use delegation to share behavior when inheritance is semantically invited.
Rearrange Classes and Operations

Sometimes, the same operation is defined across several classes and can easily be
inherited from a common ancestor, but more often operations in different classes are
similar, but not identical. By slightly modifying the definitions of the operations or the
classes, the operations can often be made to match so that they can be covered by a
single inherited operation. The following kinds of adjustments can be used to increase
the chance of inheritance:
You will find that some operations may have fewer arguments than others. The
missing arguments can be added but ignored. For example, a draw operation on
a monochromatic display does not need a color parameter, but the parameter can
be accepted and ignored for consistency with color displays.
Some operations may have fewer arguments because they are special cases of
more general arguments. In this case, you may implement the special operations
by calling the general operation with appropriate parameter values. For
example, appending an element to a list is a special case of inserting an element
into list; here the insert point simply follows the last element.
Similar attributes in different classes may have different names. Give the
attributes the same name and move them to a common ancestor class. Then
operations that access the attributes will match better. Also, watch for similar
operations with different names. You should note that a consistent naming
strategy is important to avoid hiding similarities.
An operation may be defined on several different classes in a group, but be
undefined on the other classes. Define it on the common ancestor class and
declare it as a no-op on the classes that do not care about it. For example, in
OMTool the begin-edit operation places some figures, such as class boxes, in a
special draw mode to permit rapid resizing while the text in them is being
edited. Other figures have no special draw mode, so the begin-edit operation on
these classes has no effect.
Making Common Behavior Abstract

Let us describe abstraction Abstraction means to focus on the essential, inherent
aspects of an entity and ignoring its accidental properties. In other words, if a set of
operations and/or attributes seems to be repeated in two classes. There is a scope of
applying inheritance. It is possible that the two classes are really specialised variations
of the something when viewed at a higher level of abstraction.
When common behavior has been recognised, a common super class can be created
that implements the shared features, leaving only the specialised features in the
subclasses. This transformation of the object model is called abstracting out a
common super class or common behavior. Usually, the resulting super class is
abstract, meaning that there are no direct instances of it, but the behavior it defines
belongs to all instances of its subclasses. For example, again we take a draw operation
35
Object Oriented Design of a geometric figure on a display screen requires setup and rendering of the
geometry. The rendering varies among different figures, such as circles, lines, and
spines, but the setup, such as setting the color, line thickness, and other parameters,
can be inherited by all figure classes from abstract class figure.
The creation of abstract super classes also improves the extensibility of a software
product, by keeping space for further extension on base of abstract class.
Use Delegation to Share Implementation

As we now know, inheritance means the sharing of to the behavior of a super class by
its subclass. Let us see how delegation could be used for this purpose. Before we use
delegation, let us try to understand that what actually delegation can do.
The term delegation Delegation consists of catching an operation on one object
and sending it to another object that is part, or related to the first object. In this
process, only meaningful operations are delegated to the second object, and
meaningless operations can be prevented from being inherited accidentally. It is
true that Inheritance is a mechanism for implementing generalization, in which the
behavior of super class is shared by all its subclasses. But, sharing of behavior is
justifiable only when a true generalization relationship occurs, that is, only when it
can be said that the subclass is a form of the super class.
Let us take the example of implementation of inheritance. Suppose that you are about
to implement a Stack class, and you already have a List class available. You may be
tempted to make Stack inherit from List. Pushing an element onto the stack can be
achieved by adding an element to the end of the list and popping an element from a
stack corresponds to removing an element from the end of the list. But, we are also
inheriting unwanted list operations that add or remove elements from arbitrary
positions in the list.
Often, when you are tempted to use inheritance as an implementation technique, you
could achieve the same goal in a safer way 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, by using delegation rather than applying inheritance.
A safer implementation of Stack would delegate to the List class as shown in
Figure 2. Every instance of Stack contains a private instance of List. The Stack ::
push operation delegates to the list by calling its last and add operations to add an
element at the end of the list, and the pop operation has a similar implementation
using the last and remove operations. The ability to corrupt the stack by adding or
removing arbitrary elements is hidden from the client of the Stack class.
List
Body: list {private} List
Add Body: list {private}

Remove Push Add
First Pop Remove
last First
last
Stack
Push
pop
Discouraged Recommended
Figure 2: Alternative implementations of a Stack using inheritance (left) and delegation (right)
36
By Figure 2, it is obvious that we should discourage the use of inheritance to share the Advance Object Design
operations between two related classes. Instead, we should use delegation so that one
class can selectively invoke the desired functions of another class. Now, you are
aware of the concept of inheritance and its adjustment. In the next section, we will
discuss association design and different types of associations.
3.4 ASSOCIATION: DESIGN

Before we define association design let us define association Association is the
group of links between two objects in an object model. It is helpful in an finding
paths between objects. It is a conceptual entity, which can be used for modeling and
analysis. At the final phase of advance object design, you must use strategy for
applying association in the object model. Association is also defined as a group of
links between two objects with common structure and common semantic.
Analyzing Association Traversal
Association Traversal should be understood properly for an association design
explanation. Analyzing association traversal means analyzing traversal between the
objects. Associations are inherently bi-directional, which is certainly true in an
abstract sense. But, if some associations in your application are only traversed in one
direction, in this case implementation can be simplified.
One-way Associations
If an association is only traversed in one direction, then it is called one-way
association. It is implemented as a pointer, or an attribute that contains an object
reference. If the multiplicity is one, as shown in Figure 3, then it is a simple pointer;
otherwise, if the multiplicity is many, then it is a set of pointers. If the many end
is ordered, then a list can be used, instead of a set. A qualified association with
multiplicity one can be implemented as a dictionary object.
Person Company
Works-for
Person Company
Employer employees
Figure 3: Implementation of one-way association using pointers
Two-way Associations
Many associations are traversed in both directions, and these are called two-way
associations. You may observe that it is not essential to have some frequency of
traversal from both sides. It can be implemented by using the following three
methods:
Implement as an attribute in one direction only, and perform a search when a

backward traversal is required. This approach is useful only if there is a great
disparity in traversal frequency in the two directions, and when minimizing both
the storage cost and the update cost are important. It is observed that the rare
backward traversal will be expensive.
You should try to implement the attributes in both directions, as shown in

Figure 4. This approach is good because it permits fast access, but if either
attribute is updated then the other attribute must also be updated to keep the link
consistent. This approach is useful in the case to access outnumber updates.
37
Person Work for Company
Person Company
Employer Employees
Set
Figure 4: Implementation of two-way association using pointers
Implement as a distinct association object, independent of either class, as shown

in Figure 4. An association object is a set of pairs of associated objects stored in
a single variable-size object. For efficiency, you can implement an association
object using two dictionary objects, one for the forward direction and other for
the backward direction. This idea is useful for extending predefined, the classes
from a library which cannot be modified. Distinct association objects are also
useful for sparse associations. In sparse associations most objects of the classes
do not participate because space is used only for actual links.
Works-for
(Person) (Company)
(Person)
(Person)
(Person)
(Company)
(Person)
Figure 5: Implementation of association as an object

Objects are representated using certain symbols. Now we will discuss object
representations.
3.5 OBJECT REPRESENTATION

The term object representation means to represent object by using objects model
symbols. Implementing objects is very simple. The object designer decides the use of
primitive types or to combine groups of related objects in their representation.
We can define a class in terms of other class. The classes must be implemented in
terms of built-in primitive data types, such as integers, strings, and enumerated types.
For example, consider the implementation of a social security number within an
employee object which is shown in Figure 6. The social security number attribute can
be implemented as an integer or a string, or as an association to a social security
number object, which itself can contain either an integer or a string. Defining a new
class is more flexible, but often introduces unnecessary indirection. It is suggested that
new classes should not be defined unless there is a definite need it.
38
Employee Employee SSN SS number
SS: string SS: integer
Employee Employee SSN SS number
SSN: string SSN: string
Figure 6: Alternative representations for an attribute
In a similar way, the object designer decides whether to combine groups of related
objects or not.

1) Explain inheritance with support of suitable example.
..
..
.
2) Describe the association design of an object by giving one example of it.
.
.
.
3) The definition of classes and operation can often be adjusted to increase the
amount of inheritance. Justify this statement.
.
.
.
Optimization is one of the areas of computing which gets great importance and
considerations. Now, let us discuss the optimization possibilities of a design.
3.6 DESIGN OPTIMIZATION

In the previous Section, we have seen various ways of representing objects. This
Section will cover very interesting and important aspects of design optimization. The
basic design model uses the analysis model as the framework for implementation. The
analysis model captures the logical information about the system. To get better result,
the design model should contain details to support efficient information access. The
inefficient, but semantically-correct analysis model can be optimized to make
implementation more efficient, but an optimized system is more obscure, and less
likely to be reusable in another context. For the design optimization, as a designer,
you must strike an appropriate balance between efficiency and clarity.
During design optimization as a designer you must keep the following points in his
mind:
Add redundant associations to minimize access cost, and to maximize

convenience
Rearrange the computation for greater efficiency up to possible instant.
Save derived attributes to avoid recomputation of complicated expressions.
Now let us discuss these issues one by one:
39
Object Oriented Design Adding Redundant Associations for Efficient Access
The term redundant association means using duplicate association for efficient
access. During analysis, it is not a good idea to have redundancy in the association
network because redundant associations do not add any information. During design,
however, you should evaluate the structure of the object model for implementation.
This can be done by asking questions:
i) Is there a specific arrangement of the network that would optimize critical
aspects of the completed system?
ii) Will adding new associations that were useful during analysis restructure the
network? All this sometimes may not produce the most efficient network, one
that can handle complex access patterns, as well as the related frequencies of
various kind of access.
To describe the analysis of access paths, consider the example of the design of a
companys employee skills database. A part of the object model from the analysis
phase is shown in Figure 7. The operation Company:: find-skill returns a set of
persons in the company with a given skill. For example, we may ask for the data of all
employees who speak Japanese.
Employs Has-skill
Company Person Skill
Figure 7: Chain of associations between objects
For this example, suppose that the company has 1000 employees, each of whom has
10 skills on average. A simple nested loop would traverse Employs 1000 times and
Has-skill 10,000 times. If only 5 employees actually speak Japanese, then the test-to-
hit ratio is 2000.
Now, let us see whether this figure can be improved or not. Actually, we can make
many possible improvements in this Figure. First, Has-skill need not be implemented
as an unordered list a hashed set. The hashing can be performed in a fixed interval of
time so that the cost of testing whether a person speaks Japanese is constant, provided
a unique skill object represents speaks Japanese. This rearrangement reduces the
number of tests from 10,000 to 1,000, or one per employee.
For those cases where the number of hits from a query is low (since only a fraction of
objects satisfy the test) we can build an index to improve access to objects that must
be frequently retrieved. For example, we can add a qualified association Speaks
language from Company to Employee, where the qualifier is the language spoken
(Figure 8). This permits us to immediately access all employees who speak a
particular language with no wasted accesses. But there is a cost to the index: It
requires additional memory, and it must be updated whenever the base associations
are updated. The object designer must decide when it is useful to build indexes.
Here, we have to consider the case where most queries return all of the objects in the
search path, then an index really does not save much because the test-to-hit ratio in
this case is very close to 1.
Speak language
Company language
Figure 8: Index for personal skills database
From Figure 8, it is obvious that speaks language is a derived association, defined in

terms of underlying base associations. The derived association does not add any
information to the network, but permits the model information to be accessed in a
more efficient manner.
40
You can analyse the use of paths in the association network in the following steps: Advance Object Design
Examine each operation and see what associations must traverse in order to
obtain information. For this it is not necessarily those associations traverse in
both directions.
For each operation, you should note the following points:
How often is the operation called? How costly is the operation to perform?
What is the fan-out along a path through the network? Estimate the average
count of each many association encountered along the path. Multiply the
individual fan-outs to obtain the fan-out of the entire path, which represents the
number of accesses on the last class in the path. Note that one links do not
increase the fan-out, although they increase the cost of each operation slightly.
But there is no need to worry about such small effects.
What is the fraction of hits on the final class, (objects that meet selection
criteria, if any, and are operated on? If most objects are rejected during the
traversal for some reason, then a simple nested loop may be inefficient for
finding target objects.
Rearrange the Execution Order for Efficiency
Rearranging the execution order for efficiency means executing such job which has
less execution time. By rearranging the object in the increasing order of their
execution time, we can increase the efficiency of the system.
After adjusting the structure of the object model to optimize frequent traversals, the
next thing to optimize is the algorithm itself. Actually, data structure and algorithms
are directly related to each other, but we find that usually the data structure should be
considered first.
The way to optimize an algorithm is to eliminate dead paths as early as possible.
For example, suppose we want to find all employees who speak both Japanese and
French, and suppose 5 employees speak Japanese and 100 speak French. In this case,
it is better to test and find the Japanese speakers first, then test if they speak French. In
general, it pays to narrow the search as soon as possible. Sometimes the execution
order of a loop must be inverted from the original specification in the functional
model to get efficient results.
Saving Derived Attributes to Avoid Recomputation
As we have already discussed, redundancy means duplication of same data. But, If
multiple copies of the same data is present in a system, then it can increase
availability of data, but the problem of computing overhead is also associated with it.
To overcome this problem we can cache or store redundant data in its computed
form and objects or classes may be defined to retain this information. The class that
contains the cached data must be updated if any of the objects that it depends on are
changed.
Figure 9 shows a use of a derived object and derived attribute in OMTool. Each class
box contains an ordered list of attributes and operations, each represented as a text
string (left of diagram). Given the location of the class box itself, the location of each
attribute can be computed by adding up the size of all the elements in front of it. Since
the location of each element is required frequently, the location of each attribute string
is computed and stored. The region containing the entire attribute list is also computed
and saved. In this way we can avoid the testing of input points against attribute text
element. It is shown on the right side in Figures 9 (a) and (b). If a new attribute string
is added to the list, then the locations of the ones after it in the list are simply offset by
the size of the new element.
41
Object Oriented Design {ordered} Attribute Attribute Attribute
list
Text
Class box text Region
Class box location
Location location
Operation Operation
list Operation
text region
Region
Location
Figure 9 (a) Figure 9 (b)

Figure 9: Derived attribute to avoid recomputation
You can see the use of an association as a cache which is shown in Figure 10. In this
figure a sheet contains a priority list of partially overlapping elements. If an element is
moved or deleted, the elements under it must be redrawn. Scanning all elements in
front of the deleted element in the priority list of the sheet, and comparing them to the
deleted element can uncover overlapping elements. If the number of elements is large,
this algorithm grows linearly in the number of elements. The Overlaps association
stores those elements that overlap an object, and precede it in the list. This association
must be updated when a new element is added to it, but testing for overlap using the
association is more efficient.
Priority
list
next
Diagram
element Previous
over
under
Overlaps
Figure 10: Association as a cache
After the base value is changed, you should update derived attributes. Now, the
question is how to recognise the need of update. There are three ways to recognize
when an update is needed: by explicit code, by periodic recomputation, or by using
active values. Now, let us three ways one by one.
Explicit update: In explicit update, each derived attribute is defined in terms of
one, or more fundamental base object(s). The object designer determines which
derived attributes are affected by each change to a fundamental attribute, and
inserts code into the update operation on the base object to explicitly update the
derived attributes that depend on it.
Periodic recomputation: Base values are often updated in bunches.
Sometimes, it is possible to simply recompute all the derived attributes
periodically without recomputing derived attributes after each base value is
changed. Recomputation of all derived attributes can be more efficient than
incremental update because some derived attributes may depend on several base
attributes, and might be updated more than once by an incremental approach.
Also, periodic recomputation is simpler than explicit updates and less prone to
bugs. On the other hand, if the data set changes incrementally, a few objects at a
time, periodic recomputation is not practical because too many derived
attributes must be recomputed when only a few are affected.
Active values: An active value is a value that has dependent values. Each
dependent value registers itself with the active value, which contains a set of
dependent values and update operations. An operation to update the base value
triggers updates of all the dependent values, but the calling code need not
explicitly invoke the updates.
Now, let us discuss design documentation in the designing of an object.
42
3.7 DESIGN DOCUMENTATION
The Design Document should be an extension of the Requirements Analysis Design.
The Design Document will include a revised and much more detailed
description of the Object Model in both graphical form (object model diagrams)
and textual form (class descriptions). You can use additional notation to show
implementation decisions, such as arrows showing the traversal direction of
associations and pointers from attributes to other objects.
The Functional Model can also be extended during the design phase, and it must be
kept current. It is a seamless process because object design uses the same notation as
analysis, but with more detail and specifics. It is good idea to specify all operation
interfaces by giving their arguments, results, input-output mappings, and side effects.
Despite the seamless conversion from analysis to design, it is probably a good idea to
keep the Design Document distinct from the Analysis Document. Because of the shift
in viewpoint from an external users view to an internal implementers view, the
design document includes many optimizations and implementation artifacts. It is
important to retain a clear, user-oriented description of the system for use in validation
of the completed software, and also for reference during the maintenance phase of the
object modeling.

1) Improve the object diagram in Figure 11 by generalizing the classes Ellipse and
Rectangle to the class Graphics primitive, transforming the object diagram so
that there is only a single one-to-one association to the object class Boundary. In
effect, you have to changing the 0,1 multiplicity to exactly one multiplicity. As
it stands, the class Boundary is shared between Ellipse and Rectangle. A
Boundary is the smallest rectangular region that will contain the associated
Ellipse or Rectangle.
Ellipse Rectangle
Boundary
Figure 11: Portion of an object diagram with a shared class
.
..
2) Assign a data type to each attribute in Figure 12.
Page Column Line
Width x location text

Length y location
Left margin width
Right margin length
Top margin
Bottom margin
Figure 12: Portion of an object diagram of a newspaper
.
..
43
Object Oriented Design 3) Improve the object diagram in Figure 13 by transforming it, adding the class
(Political party). Associate Voter with a party. Discuss why the transformation
is an improvement.
Voter
Party A Party B Party C
Figure 13: Object diagram representing voter membership in a political party
.
..
..
..
4) Figure 14 is a state diagram for a garage door opener. Implement it by using
state as, location within a program. You may use pseudocode, or any structured
programming language.
Depress/start opening door Opening Door open
Closed Open
Depress/start opening door
Closing
Door closed Depress/start opening door
Figure 14: State diagram for a garage door opener
3.8 SUMMARY
Object design follows analysis and system design. The object design phase adds
implementation details, such as restructuring classes for efficiency, internal data
structures and algorithms to implement operations, implementation of control,
implementation of associations, and packaging into physical modules. Object design
extends the analysis model with specific implementation decisions and additional
internal classes, attributes, associations, and operations.
During object design, the definitions of internal classes and operations can be adjusted
to increase the amount of inheritance. These adjustments include modifying the
argument list of a method, moving attributes and operations from a class into a super
class, defining an abstract super class to cover the shared behavior of several classes,
and splitting an operation into an inherited part and a specific part. Delegation should
be used rather than inheritance when a class is similar to another class but not truly a
sub class.
44
Associations are the glue of our object model, which provides access paths between Advance Object Design
objects. An association traversed in a single direction can be implemented as an
attribute pointing to another object, or a set of objects, depending on the multiplicity
of the association. A bi-directional association can be implemented as a pair of
pointers, but operations that update the association must always modify both
directions of access. Associations can also be implemented as association objects.
The exact representation of objects must be chosen. At some point, user-defined
objects must be implemented in terms of primitive objects, or data types supplied by
the programming language. Some classes can be combined. Programs must be
packaged into physical modules for editors and compilers, as well as for the
convenience of programming teams. Design decisions should be documented by
extending the analysis model, by adding detail to the object, dynamic, and functional
models.
3.9 SOLUTIONS/ANSWERS
1) State Diagram
An object can receive a sequence of input instructions. The state of an object can vary
depending upon the sequence of input instructions. If we draw a diagram which will
represent all the processes (input) and their output (states) then that diagram is known
as state diagram. Processes are represented by arrow symbol, and states by oval
symbol. For example, the screen of ATM machine has many states like main screen
state, request password state, process transaction state, etc.
2) Concurrent Task
The simultaneous occurrence of more than one event is called a concurrent task.
Operating systems can handle concurrent tasks efficiently. The Air Traffic Control
system (ATC) for examples, can manage concurrent tasks in fractions of a second.
3) Event
Happening of a process is called event. In other words, an object can receive many
input instructions. The changes that occur due to these instructions are called events.
For example, tossing a coin is input, but the appearance of HEAD or TAIL is an
event.
State
The position of an object at any moment is called its state. An object can have many
states. After receiving some input instructions, an object can change its state from one
to another.
1) Inheritance
Inheritance is one of the cornerstones of object-oriented programming language
because it allows a creation of hierarchical classifications. Using inheritance you can
create a general class that defines trails common, to a set of related items. More
specific classes can inherit this class, and each could add a certain unique thing to the
resulting new class. The class that inherits from another, class, or classes is called a
derived class or subclass, and the class/classes from which the derived class is made is
called, a base class or a super class.
For example, racing cars. Pick up cars and saloons, etc. are all different kinds of cars
in object-oriented terminology racing cars. Pick up cars, and saloons, etc. are all
subclasses of the car class. Similarly, as illustrated in Figure15, below, the car class is
the super class of sub classes like racing cars, saloons, sedans, convertibles, etc.
45

Cars Cars
Zen Alto Esteem
Figure 15: Hierarchy of Classes
Inheritance can be of various types, such as:

1. Single inheritance
2. Multiple inheritance
3. Hierarchical inheritance
4. Multilevel inheritance
A A
B B C D
Single Inheritance Hierarchical Inheritance
A B
B
C C
Multiple Inheritance Multiple Inheritance
Figure 16: Forms of inheritance
2) The Design of Associations

Associations are the glue of advanced object oriented analysis and the design
model. Association provides access paths between the objects. It is a type of
conceptual entity that can be used for analysis and modeling of an object. For
example:
Works for
Person Company
Figure 17: A simple form of Association
In the above example, there are two objects, person and company. These two objects
are linked (associated) with each other by a relation called works for.
46
3) Adjustment of Inheritance
The definition of classes and operations can often be adjusted to increase the amount
of inheritance between the objects. The object designer can rearrange and adjust
classes to increase the inheritance among the different objects and classes. Sometimes
the same operation is defined across several classes and can easily be inherited from a
common ancestor. By slightly modifying the definitions of the operations, or the
classes, the operation often can be made to match. We also can extract common
behavior out of groups of classes to increase the inheritance. Similar attributes in
different classes may have different names, but by giving some common name and
moving them to ancestor class we can increase inheritance. An operation may be
defined on several different classes in a group but be undefined on the other classes.
To increase inheritance, we can define it on the common ancestor class and declare it
as a no-op on the classes that do not care about it. We can also use DELEGATION
instead of inheritance to share only meaningful attributes between a super class and its
sub class.
1) The improved generalized object diagram of class Ellipse and Rectangle is
given in the Figure below.
Graphics Boundary
Primitive
Boundary Boundary
Figure: 18 Object Diagram
Here, in this diagram, class Graphics primitive is the generalized class of both Ellipse
and Rectangle. The class Ellipse and Rectangle have single association with class
boundary. This single association is shown by drawing a line between class boundary
and generalized class Graphics primitive.
2) A derived association supports direct traversal from Page to Line. The line-page
association is derived by composing the line column and column page
association.
This association can be traversed from lines to pages. The Figure is shown below.
Page Column Line
Figure 19: Association between different objects of a news paper.

The data type to the attributes of the Figure is
Attribute Data type
Width integer
Length integer
Left margin real
Right margin real
Top margin real
Bottom margin real
X location x: real
Y location y: real
47
Object Oriented Design 3) The improved object diagram of object voter and object political party is shown
in the diagram below.
Member Register in
Voter Political
Party
Figure 20: Improved object diagram for representing voter membership in a political party
Political party membership is not an inherent property of a voter but a changeable

association. The revised model better represents voters with no party affiliation and
permits changes in party membership. If voters belong to more than one party, then
the multiplicity could easily be changed. Parties are instances of class Political Party
and need not be explicitly listed in the model: new parties can be added without
changing the model, and attributes can be attached to parties.
4) The Pseudo code for a garage door opener is listed below:
<closed> wait for depress event
<opening> start opening door
wait for door opening event
<open> wait for depress event
<closing> start closing door
wait for either depress or door closed event:
if depress event then go to opening
if door closed event then go to closed
In the above pseudo code we are using go to as a jump command to jump from one
statement to other.
48
System Design
UNIT 1 SYSTEM DESIGN

Structure Page Nos.
1.0 Introduction 5
1.1 Objectives 5
1.2 System Design: An Object Oriented Approach 6
1.3 Breaking into Subsystems 9
1.4 Concurrency Identification 11
1.5 Management of a Data Store 13
1.6 Controlling Events Between Objects 16
1.7 Handling Boundary Conditions 16
1.8 Summary 18
1.0 INTRODUCTION
Object oriented design (OOD) is concerned with developing an object oriented model
of a software system to implement the identified requirements. Many OOD methods
have been described since the late 1980s. The most popular OOD methods include
Booch, Buhr, Wasserman, and the HOOD method developed by the European Space
Agency which can yield the following benefits: maintainability through simplified
mapping to the problem domain, which provides for less analysis effort, less
complexity in system design, and easier verification by the user. OOD also provides
reusability, which saves time and costs, and productivity gains through direct
mapping to features of Object-Oriented Programming Languages. Object Oriented
Development (OOD) has been touted as the next great advance in software
engineering. It promises to reduce development time, reduce the time and resources
required to maintain existing applications, increase code reuse, and to provides a
competitive advantage to organizations that use it. While the potential benefits and
advantages of OOD are real, excessive hype has lead to unrealistic expectations
among executives and managers. Even software developers often miss the subtle, but
profound, differences between OOD and classic software development.
In this Unit we will discuss the basics of object oriented design. We will learn how
systems are broken into subsystems, concurrency identification, and how data storage
is managed.
1.1 OBJECTIVES
After going through this unit, you should be able to:
give an overview of object oriented design;
breaking down system to subsystems;
explain how a software design may be represented as a set of interacting
objects that manage their states and operation;
identify concurrent object, and explain how to handle concurrency;
explain methods of storing data and comparison with conventional system
design;
control events between objects; and
explain boundary condition.
1.2 SYSTEM DESIGN: AN OBJECT ORIENTED

APPROACH
5
Any software systems always tends to change and evolve as technology and business
rules change. The evolution of information systems is unavoidable, and it is a natural
phenomenon. Organisations need to support systems evolution to take advantage of
the new technology and to address the changing business rules. The evolutionary
nature of software products requires us to maintain products with their continually
changing nature. Not all software products developed are amenable to these fast
changes. In this ever-increasing competitive business environment, there is hardly
any option but to adopt technology that is adaptable to changes.
Software systems designed with structured design methodology do not support
some of the desired quality attributes such as reusability, portability and mapping to
the problem domain. Many large organisations find that systems designed with
structured approaches are less reusable and less maintainable than those designed
with object-oriented approaches.
OOD techniques are useful for development of large, complex systems. It has been
observed that large projects developed using OOD techniques resulted in a 30%
reduction in development times and a 20% reduction in development staff effort,
as compared to similarly sized projects using traditional software development
techniques.
Although object oriented methods have roots that are strongly anchored back in the
60s, structured and functional methods were the first to be used. This is not very
uncommon, since functional methods are inspired directly by computer
architecture (a proven domain, well known to computer scientists). The separation
of data and program as exists physically in the hardware was translated into
functional methods. This is the reason why computer scientists got into the habit of
thinking in terms of system functions. Later it was felt that hardware should act as
the servant of the software that is executed on it rather than imposing architectural
constraints on system development process.
Moving from a functional approach to an object oriented one requires a translation of
the functional model elements into object model elements, which is far from being
straightforward or natural. Indeed, there is no direct relationship between the two
sets, and it is, therefore, necessary to break the model elements from one approach in
order to create model element fragments that can be used by the other. In the initial
phases of OO design a mixed approach was followed computer scientist tend to use
functional approach in analysis phase and OO approach in design phase. The
combination of a functional approach for analysis and an object-oriented approach for
design and implementation does not need to exist today, as modern object-oriented
methods cover the full software lifecycle.
Traditional System Analysis and Design: Traditional System Analysis and Design
(SAD) has three fundamental life cycle models. A typical software lifecycle consists
of following phases:
Planning
Development
Maintenance
Key Criteria
a well-defined methodology
traceability among steps
documentation
control
Software Life Cycle
The software design consists of a number of stages, or phases
1. Requirement Phase determine use need
2. Specification Phase define requirement
6
System Design
3. Design Phase: design the system

4. Implementation Phase fabricate the system
5. Testing and Integration Phase testing the fabricated system
6. Maintenance phase
7. Retirement.
Shortcomings in the Structured approach
Scalability: The product designed was not scalable
Maintenance cost: high maintenance cost
Data and program are separate and difficult to map a real life situation
Structured methodology treat data and their behaviors (function) separately,
this makes it more difficult to isolate changes. If certain changes requires then
changes in both data structure and algorithms and to be done.
The Proliferation of Object-Oriented Methods
The first few years of the 1990s saw the blossoming of around fifty different object
oriented methods. This proliferation is a sign of the great vitality of object oriented
technology, but it is also the fruit of a multitude of interpretations of exactly what an
object is. The drawback of this abundance of methodologies is that it encourages
confusion, leading users to adopt a wait and see attitude that limits the progress
made by the methods. The best way of testing something is still to deploy it; methods
are not cast in stone they evolve in response to comments from their users.
Fortunately, a close look at the dominant methods allows the extraction of a
consensus around common ideas. The main characteristics of objects, shared by
numerous methods, are articulated around the concepts of class, association
(described by James Rumbaugh), partition into subsystems (Grady Booch), and
around the expression of requirements based on studying the interaction between
users and systems (Ivar Jacobsons use cases).
Finally, well-deployed methods, such as Booch and OMT (Object Modeling
Technique), were reinforced by experience, and adopted the methodology elements
that were most appreciated by the users.
From SAD to OOAD (Structured Analysis and Design (SAD) to Object Oriented
Analysis and Design (OOAD).
We will see here how we can map different models in SAD to different models in
OOAD. We will a consider various levels of abstraction through which this is done.
The data flow diagram (DFD) in SAD is mapped to Use Case diagram in OOAD.
DFD represents a broader model of a system from the process point of view. Hence,
DFD cannot be transformed as it is to equivalent representation in UML.
External
Actor
entity Use Case
Diagram
Process Use Case
Data store Class
Figure 1: Transformation from SAD to OOAD

The processes are transformed those into Use Case, and the external entity in DFD
has similar characteristics to of an actor in OOAD. The data store is transformed into
class and part of the data store to attributes of class.
An object-oriented design process
1. Define the context and modes of use of the system
7
2. Designs the system architecture

3. Identifies the principal system objects
4. Identifies concurrency in the problem
5. Handling boundary conditions
6. Develops design models
7. Specifies object interfaces
Object oriented design is concerned with developing OO model of software systems
to implement the identified requirement during the analysis phase.
Requirements Analysis System Object

Design Design Implementation Testing
Use Case Problem Sub Solution Source Test cases

Model Domain System Domain Code
Objects Object in OO
Language
Figure 2: Software life cycle activity
Software developers, data base administrators (DBAs), need to be familiar with the
basic concepts of object-orientation. The object-oriented (OO) paradigm is a
development strategy based on the concept that systems should be built from a
collection of reusable components called objects. Instead of separating data and
functionality as is done in the structured paradigm, objects encompass both. While
the object oriented paradigm sounds similar to the structured paradigm, as you will
see in this course material it is actually quite different. A common mistake that many
experienced developers make is to applying similar software-engineering principles
to OO design. To succeed one must recognize that the OO approach is different than
the structured approach.
1) Why were functional methods popular in early days?

.
..

2) What are the shortcomings in structured approach?

.
...

.
...

3) Describe different steps of an object-oriented design process.
8
System Design

...
.

Breaking the system into subsystem involves breaking the problem in to logically
independent and interacting subsystems. Now we will discuss how a system is broken
into subsystems.
1.3 BREAKING INTO SUBSYSTEMS

Decomposition is an important technique for coping with complexity based on the
idea of divide and conquer. In dividing a problem into a subproblem the problem
becomes less complex and easier to overlook and to deal with. Repeatedly dividing a
problem will eventually lead to subproblems that are small enough so that they can be
conquered. After all the subproblems have been conquered and solutions to them
have been found, the solutions need to be composed in order to obtain the solution of
the whole problem. The history of computing has seen two forms of decomposition,
process-oriented and object-oriented decomposition.
Process-oriented decompositions divide a complex process, function or task into

simpler sub processes until they are simple enough to be dealt with. The solutions of
these subfunctions, then, need to be executed in certain sequential or parallel orders,
in order to obtain a solution to the complex process.
Object-oriented decomposition aims at identifying individual autonomous objects

that encapsulate both a state and a certain behavior. Each major components of the
system is called a subsystem. Then communication among these objects leads to the
desired solutions. Decomposition of system in function-data model (SAD) and object
oriented decomposition is given below. Although both solutions help deal with
complexity, we have reasons to believe that an object-oriented decomposition is
favourable because, the object-oriented approach provides for a semantically richer
framework that leads to decompositions that are more closely related to entities
from the real world. Moreover, the identification of abstractions supports heaving
(more abstract) solutions to be reused, and the object-oriented approach supports the
evolution of systems better, as those concepts that are more likely to change can be
hidden within the objects.
Transaction
Open Deposit
Withdraw
SB A/c Current Withdraw Withdraw Deposit Deposit

A/c SB Current SB Current
Figure 3: A Function data decomposition (SAD)
9
Open
Deposit
Withdraw
Account
Other
object(s)
-------- --------
-------- --------
-------- --------
SB A/c Current A/c
Figure 4: OO Decomposition (OOD)
Object-oriented decompositions of systems tend to be better able to cope with

change. Each subsystem has a well-defined interface that communicate with rest of
the system. Each of these interfaces defines all form of interaction that are required
for proper functioning of the whole system, but the internal implementations are left
to the sub-system itself. This is because they manage to encapsulate those items that
are likely to change (such as functionality, sequence of behaviour and attributes)
within an object and hide them from the outside world. The advantage is that the
outside cannot see them, and therefore cannot be dependent on them and does not
need to be changed if these items change. Also, object-oriented decompositions are
closer to the problem domain, as they directly represent the real-world entities in their
structure and behavior. The abstraction primitives built into reuse have a huge
potential of
reuse as commonalities between similar objects can be factored out, and then, the
solutions can be reused. Finally, object-orientation has the advantage of continuity
throughout analysis, design implementation, and persistent representation.
Object-oriented analysis, design and programming are related but distinct.
OOA is concerned with developing an object model of the application

domain.
OOD is concerned with developing an object-oriented system model to

implement requirements.
OOP is concerned with realizing an OOD using an OO programming
language such as Java or C++.
Objects are abstractions of real-world/system entities.
Objects manage themselves.
Objects are independent and encapsulate state and representation.
System functionality is expressed in terms of object services.
Shared data areas are eliminated.
Objects communicate by message passing.
Objects may be distributed and may execute sequentially, or in parallel.

The system can be decomposed into two-layer architecture (referred as layer) vertical
and decomposition (referred as partition).
10
System Design
Data display layer where the

Data display sub- objects of the sub-system are
system concerned only with
presentation of the user
interface
Data processing layer where

Data processing sub-
objects check the integrity of
system
data that goes to the
database.
Data collection The other types of decomposition

subsystem called partition are commonly
found in operating system. Most of
the large system may require a
mixture of both types of
decomposition.
Now, let us see the basic advantages of decomposition.

The Advantages of Decomposition
1. Separate people can work on each subsystem.
2. An individual software engineer can specialize in a domain.
3. Each individual component is smaller, and therefore easier to understand and
manage.
4. Part of the subsystem can be replaced or changed without having to replace or
extensively change other subsystems.
Concurrency identification is very challenging in nature. In the next section, we will
discuss objects concurrency identification.
1.4 CONCURRENCY IDENTIFICATION

While designing the analysis, model we map the real world model into our analytical
model. Real life objects are concurrent in nature, but all design model objects are
not concurrent in nature as a single process may support multiple objects.
Let us see what concurrency actually is: Concurrency in objects can be identified
by the way they change state. Current objects can change state independently.
Aggregation implies concurrency. Concurrency in OOAD study is described and
studied in dynamic modeling.
One of the important issues in system design is to find the concurrency in objects.
Once we identify non-concurrent (mutually exclusive) objects, we can fold all the
objects together in one thread of control, or process. On the other hand, if the
objects are concurrent in nature we have to assign them to, different thread of
control. For example, withdraw and deposit operations related to a bank account may
be executed in parallel (concurrently).
A thread of control is a path through a set of state diagrams on which a single

object is active at a time.
Objects are shared among threads, that is, several methods of the same object
can be active at the same time.
Thread splitting: Object sends a message but does not wait for the completion
of the method.
Identification of concurrency: Concurrency is identified in a dynamic model. Two
objects are said to be concurrent (parallel) if they can receive events at the same
time. Concurrent objects are required to be assigned to different threads of control.
We will see how if is used in this example:
11
Example:
:bankAC (initial balance 300)

Withdraw (100)
get_balance() withdraw(100)
300 get balance()
calculateNewBalance(300,100) 300
setNewBalance(200) calculateNewBalance(300,100)
setNewBalance(200)
:withdraw closing balance 200 ?
:withdraw c2:customer
c1:customer
Figure 6: Concurrency without synchronization
:withdraw
withdraw(100)
get balance()
withdraw(100) 300
calculateNewBalance (300, 100)
setNewBalance(200)
get balance()
c1: customer c2:customer

closing balance 100
Figure 7: Concurrency with synchronization
Refer to the Figure 7 if an object must perform two or more activities concurrently,
then the internal steps of the process must be synchronized. Both the synchronized
activity must complete before the object performing the concurrent activity can go to
the next step.
Concurrency issues
Data integrity: Threads accessing the same object need to be synchronized, for
example: banking account.
Deadlock: One or more threads in the system are permanently blocked
Example: Thread A waiting on Thread B, which is waiting on Thread A.
Starvation: A thread is not getting enough resources to accomplish its work
Example: All requests from one user are being handled before another users
requests.
How to handle concurrency:
Mechanisms
12
System Design
Locks
Semaphores
Monitors
Synchronized methods
Methods
Deadlock avoidance
Verification
Simulation
Key:
1) Develop a clear strategy for dealing with all concurrency issues during system
design.
2) Concurrency must be dealt with during the design process as dealing with
concurrency after the system is implemented is difficult.
A detailed discussion on this topic will be there in MCS 041.

1) What are the advantages of decomposing a system?

2) Differentiate between object oriented decomposition and structured
decomposition?

3) How is concurrency identified?

Data storage is a very important stored aspect involve in any systems. In the next
section we will discuss management of data.
1.5 MANAGEMENT OF DATA STORE

Every system irrespective of their nature of application needs to store permanent data
for subsequent use in problem solving. Some objects in the models need to be
persistent, to store the state of the object permanently in database. Most systems
need persistent data which is not lost when the system closes down. These data are
stored in file system, in a or database. Object-oriented applications often use
relational databases to provide persistence.
Designer needs to:
1. Identify what data needs to be persistent
2. Design a suitable database schema for the database.
13
Persistent classes are shown using tagged value in UML diagram.

Booking
{persistent}
Reservation 1 Customer
{persistent} {persistent}
Figure 8: A UML diagram showing persistent class
For example, in reference to Figure 8, we must save all information related to

customers and booking details.
In most of the cases, persistent class maps to one relational table (leaving aside the
inheritance issue, for the moment). In the simplest model, a class from the logical
model maps to a relational table, either in whole, or in part. The logical extension of
this is that a single object (or instance of a class) maps to a single table row.
Persistent object can be stored with one of the following:
Files
Cheap, simple, permanent storage
Low level (Read, Write)
Applications must add code to provide a suitable level of abstraction.
Relational database
Standardized, easy to port
Supports multiple writers and readers
Mature technology
Object database
One-to-one mapping from the analysis model

Associations are directly represented
Slower than relational databases for complex queries
Data store Data store
d1 d1
Process Process
Accessing of value in data store Updating of value in data store
Figure 9: Functional Model notation of data store
The advantage of using a Database Management System for a data store is that
databases have mechanisms for describing data, managing persistent storage and
for providing a backup and recovery mechanism. It also provides concurrent
access to the stored data with an appropriate locking mechanism. Most of the DBMS
contains information about data in the form of a data dictionary. Most commercial
RDBMS come with an Object-Relational extension which implements an object
database on top of a RDBMS.
Issues when Selecting a Database
Storage space requirement: A database requires about triple the storage space
of actual data.
Response time: The response time of the database for I/O or communication
bound (in case of distributed databases) request.
Locking modes pessimistic locking: Lock before accessing an object and
release when object access is complete.
14
System Design
Optimistic locking: Read and writes may freely occur (high degree of
concurrency).
Administration: Modern DBMS requires specially trained support staff to set
up security policies, manage the disk space, prepare backups, fine-tune the
performance, and monitor performance.
How often is the database accessed?
What is the expected request (query) rate? In the worst case?
What is the size of the typical request and of the worst case requests?
Need for data to be archived.
Table 1
Relational Databases Object-Oriented Databases

Based on mathematical principles Supports all fundamental object
called relational algebra modeling concepts: Classes,
Attributes, Methods, Associations,
Data are represented by a two
Inheritance
dimensional table with columns and
rows Support for complex objects
Implements standard query language Provides for mapping an object
called SQL model to an OO-database
Most RDBMS supports various Determine which objects are
constraints, like referential integrity. persistent
Perform normal requirement
analysis and object design
Create single attribute indices to
reduce performance bottlenecks.
Most of the object oriented system use relational database to store persistent data.
The advantages and disadvantages of OO database are compared in Table 2.
Table 2
Advantages of OO Database Disadvantages OO Database

Supports all fundamental object Strong opposition from the
modeling concepts like Classes, established players of relational
Attributes, Methods, Associations, database
Inheritance Lacks rigorous theoretical
Maps an object model to an OO- foundation.
databases Retrogressive to the old pointer
Determine which objects are systems
persistents Lacks standard ad hoc query
Performs normal requirement analysis language like SQL.
and object design Lack of standards affects OO
Creates single attribute indices to database design
reduce performance bottlenecks Lack of business data design and
Supports complex objects. management tools
Extensibility of data types. Steep learning curve.
Improves performance with efficient
caching.
Versioning
Faster development and easy
maintenance through inheritance and
reusability.
Other System Design Issue
15
How to realise the subsystems: through hardware or software?

How is the object model mapped on the chosen hardware software?
Mapping objects onto hardware: processor, memory, I/O.
Mapping associations onto networks: Connectivity.
Much of the difficulty of designing a system comes from fulfilling the restriction
imposed by hardware and software constraints. This may include cases where certain
throughput has to be guaranteed for a system, and where certain response time has to
be guaranteed.
1.6 CONTROLLING EVENTS BETWEEN

OBJECTS
Event is the specification of a significant occurrence that has a location in time and
space.
Examples of events are mouse click and flight leaving from an airport. An event does
not have a fixed duration. Each thing that happens modeled as an event. After an
event, objects change their state, and these are represented by a state diagram.
Events are classified as four types in UML
1. Signals
2. Calls
3. Passing of Time
4. Change in State
Events also include inputs, decisions, interrupts and actions performed by users or
any external device. Every event has a sender and receiver. In most of the cases the
sender and receives are the same object. A state without a predecessor and successor
are ambiguous, and care should be taken to represent initiations and termination of
events. Events that have same effect on the control flow must be grouped together
even if their value differs. The events are to be allocated to the object classes that
send/receive it.
Most of the design issues of systems are concerned with steady-state behavior.
However, the system design phase must also address the initiation and finalization of
the system. This is addressed by a set of new uses cases called administration use
cases. Now, let us discuss how these issues are handled.
1.7 HANDLING BOUNDARY CONDITION

These are some conditions which to be handled in any system initialization and
termination
Describes how the system is brought from a non-initialized state to steady-state

(startup use cases). It describes normal operations like start-up, shutdown,
reconfiguration, restart/reset, backup, etc.
Describes what resources are cleaned up, and which systems are notified upon
termination (termination use cases).
Configuration
Describes how the system is adapted to a local installation.
Failure
Unplanned termination of the system.
16
System Design
Many possible causes: failure of system hardware, bugs, operator errors,

external problems (power supply).
Good system design foresees fatal failures (failure use cases).
StartUpServer
ManageServer
ShutDownServer
System Administrator
ReconfigureServer
ConfigureServer
FineTune
Figure 10: Boundary Use Case
Operation Actor Constraints

Start up System Administrator / Availability of power, and
Operator no system fault
Shut down System Administrator / No user is active, and data
Operator has been saved
Fine Tune System Administrator No user is active, database
offline
Reconfigure System Administrator No user is active, system
resources are available
While defining the boundaries of a system we must ascertain what system entities one
does and does not have control over. The level of control is determined for all
identified internal and external entities. The control status can be total, partial, or
none.
1) What is persistency?

2) Why, generally, does an object-oriented system use a relational DBMS?

3) Identify and name a few boundary processes.

17
4) Draw a use case diagram for a typical Flight Reservation System. Identify use
case and actor.

.
1.8 SUMMARY
OOD techniques are useful for the development of large, complex systems. Moving
from a functional approach to an object-oriented one requires a translation of the
functional model elements into object model elements, which is far from being
straightforward. The high-level system design approach involves breaking down the
system into simple and relatively independent sub systems for better manageability.
Systems can be proportioned to horizontal or vertical partitions. Concurrency is
inherent to objects, and concurrent objects cannot be folded into a single thread of
control. Concurrency must be dealt with during the design process as dealing with
concurrency after the system is implemented is difficult.
Most systems need persistent data which is not lost when the system closes down.
Data can be stored in flat files or DBMS. Object-oriented databases provide support
for all fundamental object modeling concepts like Classes, Attributes, Methods,
Associations, and Inheritance. But unlike RDBMS, object-oriented databases lack
theoretical foundation and standards. Although system design is concerned with the
steady state behaviors of the system, the system must be designed to handle boundary
conditions. Boundary use cases are useful to analyse boundary conditions.
1.9 SOLUTIONS/ ANSWERS

1) Functional methods are inspired directly by computer architecture, and thus the
popular among computer scientist in the early days. The separation of data and
program as it exists physically in the hardware was translated into the
functional methods.
2) Structured methodology treats data and their behaviors (functions) separately,
and this makes it more difficult to isolate changes. If changes are required in
the software then one has to change both the data structure and the algorithms
and these changes subsequently require changes in the algorithms where this
data structure is used as well.
3) The broad steps of an object-oriented design process are:
a. Define the context and modes of use of the system
b. Design the system architecture
c. Identify the principal system objects
d. Identification of concurrency in the problem
e. Handling boundary condition
f. Develop design models
g. Specify object interfaces.
1) The advantages of decomposing a system into subsystems are that after
decomposition, each individual components become smaller, and easy to
manage. Changes in these subsystem can be effected without extensively
18
System Design
making changes in other subsystem. Decomposition it also allows software

engineer to specialize in a particular domain of the system.
2) Process-oriented (structural) decomposition divides a complex process,

function or task into simpler subprocesses until they are simple enough to be
dealt with. The solutions of these subfunctions then need to be integrated and
executed in certain sequential or parallel orders in order to obtain a solution to
the large complex system. On the other hand object-oriented decomposition
aims at identifying individual autonomous objects that encapsulate both a state
and certain behavior. Each major component of the system is called subsystem.
Then, communication among these objects leads to the desired solutions.
Object-oriented decompositions of systems tend to be better able to cope with
change. Each subsystem has well-defined interfaces that communicate with rest
of the system
3) Concurrency in objects can be identified by the way they change state. Current
objects can change state independently. Aggregation implies concurrency in the
system.

1) Persistency ensures that data is stored, and that after the object is no longer
available (program stops running), the data will be, available to other users, as
and when needed.
2) The reasons for using RDBMS for OO systems could be any combination of
the following:
a. Many organizations have existing relational databases containing existing
business data.
b. Most commercial RDBMS come with an Object-Relational extension
which implements an object database on top of a RDBMS.
c. Purely object databases are too complicated to use, and lack standards
like SQL.
3) System startup, shutdown, system failure.
4) Actors: Passenger, Ticket clerk.
Book
ticket
Confirm
Ticket
Passenger Check Ticket Clerk

Schedule
Figure 11: Use case for Book Ticket, check schedule and confirm Ticket
19

Block 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Block 2

Uploaded by

Copyright:

Available Formats

Object Oriented Design

UNIT 2 OBJECT DESIGN

2.2 OBJECT DESIGN FOR PROCESSING

2.3 OBJECT DESIGN STEPS

In the next section, we will discuss algorithm selection in more detail.

) Check Your Progress 1

2.4 CHOOSING ALGORITHMS

2.5 DESIGN OPTIMIZATION

Figure 1: Derived attribute to avoid recomputation

) Check Your Progress 2

3) Give an example of an active value.

2.6 IMPLEMENTATION OF CONTROL

2.7 ADJUSTMENT OF INHERITANCE

iv) Sometimes an operation is required by a subset of classes. In this case, declare

2.7.2 Abstracting Out Common Behavior

Math _Teacher Math_Students

Figure 2: Implementation of a one-way association using pointers

2.8.3 Two-way Associations

Figure 3: Implementation of two-way association, using pointer

) Check Your Progress 3

Check Your Progress 2

Ease of implementation and understandability

3.2.1 Control as State within Program

d) The states and transitions that remain unchecked correspond to exception

Take card Take card

Figure 1: Control of states and events in ATM

) Check Your Progress 1

1) Briefly explain state diagram by taking one example.

Rearrange Classes and Operations

Making Common Behavior Abstract

Use Delegation to Share Implementation

Add Body: list {private}

3.4 ASSOCIATION: DESIGN

Figure 3: Implementation of one-way association using pointers

Implement as an attribute in one direction only, and perform a search when a

You should try to implement the attributes in both directions, as shown in

Figure 4: Implementation of two-way association using pointers

Implement as a distinct association object, independent of either class, as shown

Figure 5: Implementation of association as an object

3.5 OBJECT REPRESENTATION

SS: string SS: integer

Employee Employee SSN SS number

SSN: string SSN: string

Figure 6: Alternative representations for an attribute

) Check Your Progress 2

3.6 DESIGN OPTIMIZATION

Add redundant associations to minimize access cost, and to maximize

Figure 7: Chain of associations between objects

Figure 8: Index for personal skills database

From Figure 8, it is obvious that speaks language is a derived association, defined in

Figure 9 (a) Figure 9 (b)

Figure 10: Association as a cache

) Check Your Progress 3

Figure 11: Portion of an object diagram with a shared class

Width x location text

Figure 12: Portion of an object diagram of a newspaper

Party A Party B Party C

Figure 13: Object diagram representing voter membership in a political party

Depress/start opening door Opening Door open

Figure 14: State diagram for a garage door opener

Zen Alto Esteem

Figure 15: Hierarchy of Classes

Inheritance can be of various types, such as: