Allenhouse Institute of Technology (UPTU Code : 505)

OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Object Oriented Techniques

Unit-3
Module 1
Introduction: object oriented development-modeling concepts – object oriented methodology – models –
object oriented themes-Object Modeling– links and associations – advanced links and association
concepts – generalization and inheritance - grouping constructs – a sample object model

1 Introduction
(i)Object
Data can be quantized into discrete, distinguishable entities which are called objects.
(ii) Object Oriented Approach means organizing software as a collection of discrete objects that
incorporate both data structure and behavior.
2 Object Oriented Development is a new way of thinking about software based on abstractions
that exist in the real world as well as in the program.
3 Object Oriented Methodology is a methodology for object oriented development and a graphical
notation for representing objects oriented concepts. We can call this methodology as OMT. The
methodology has the following stages:
1. Analysis - An analysis model is a concise, precise abstraction of what the desired system must do,
not how it will be done. It should not contain any implementation details. The objects in the model
should be application domain concepts and not the computer implementation concepts.
2. System design - The designer makes high level decisions about the overall architecture. In system
design, the target system is organized as various subsystems based on both the analysis structure
and the proposed architecture.
3. Object design - The designer builds a design model based on the analysis model but containing
implementation details. The focus of object design is the data structures and algorithms needed to
implement each cycle.
4. Implementation - The object classes and relationships developed during object design are finally
translated into a particular programming language, database, or hardware implementation. During
implementation, it is important to follow good software engineering practice so that the system can
remain the traceability, flexibility and extensibility.
The OMT methodology uses three kinds of models
Object Model-describes the static structure of the objects in a system and their relationships. This
model mainly contains object diagrams.
Dynamic Model-describes the aspects of a system that change over time. This model mainly
contains state diagrams.
Functional Model-describes the data value transformations within a system. This model contains
the data flow diagrams

4 Object Oriented Themes:

There are several themes in an object oriented technology. These themes are not unique to object
oriented systems. We can see some important themes:
Abstraction-Abstraction consists of focusing on the essential, inherent aspects of an entity and
ignoring its accidental properties. In system development, it focuses only on what an object is and
does, before deciding how it should be implemented.
Encapsulation- It can also be called as information hiding. It consists of separating the external
aspects of an object, which are accessible to other objects, from the internal implementation
details of the object, which are hidden from other objects. It is not unique to object oriented
languages.

Subject Notes # Odd Semester 2014-15 Page 1

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Combining Data and Behavior-The caller of an operation need not consider how many
implementations of a given operation exist. Operator polymorphism shifts the burden of deciding
what implementation to use from the calling code to the class hierarchy. As an example, let us talk
about an object oriented program calling a draw procedure for drawing different figures say a
polygon, circle, or text. The decision of which procedure to use is made by each object, based on its
class.
Sharing- Inheritance of both data structure and behavior allows a common structure and behavior
allows common structure to be shared among several similar subclasses without redundancy. The
sharing of code using inheritance is one of the main advantages of object oriented languages.

(5) Object Modeling: A model is an abstraction of something for the purpose of understanding it
before building it. It is easier to manipulate than the original entity.
An object model captures the static structure of a system, relationships between the objects, and
the attributes and operations that characterize each class of objects.
This model is the most important one. Some basic concepts covered in object modeling:
(a) Objects: We can define an object as a concept, abstraction, or thing with crisp boundaries and
meaning for the problem at hand. All objects have identity and are [Link]:- Two apples
can be described as 2 different objects even though they have the same descriptive properties.
(b) Classes: An „object class‟ or „class‟ describes a group of objects with similar properties,
common behavior, common relationships to other objects, and common semantics.
Eg: - Suppose you have a person class –you can term J S, M S, etc. to be objects of that class.
(c)Object Diagrams: They provide a formal graphic notation for modeling objects, classes and their
relationships to one another.

Fig.2.1 Classes and Objects

Class Diagram: It is a schema, pattern or template for describing many possible instances of data.
An Instance Diagram describes how a particular set of objects relate to each other. An instance
diagram describes object instances. As the example above shows the symbol for an object instance,
while that of class diagram is a rectangle.
In the above example, JS, MS are instances of class Person.
(d)Attributes: An attribute is a data value held by objects in a class. Eg: - In the above example,
Name, age, [Link] a person are attributes. Attributes are listed in the second part of the class box.
So in the above example,

Subject Notes # Odd Semester 2014-15 Page 2

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Fig.2.2 Attributes and values

(e) Operations and methods: An operation is a function or transformation that may be applied to or
by objects in a class. Operations are listed in the lower third of the class box. Eg: - consider the
above example, change –job and change-address on Person class.

Fig.2.3 Operations
Each attribute name may be followed by operational details, list of attributes and list of operations.
Each operation name may be followed by operational details such as operational details such as
argument list and result type.
6 Links and associations: They are used for establishing relationships among objects and classes.
Link- A link is a physical or conceptual connection between object instances .We can say that a link
is an instance of an association. Eg: - J S works for Simplex company.
Association –Describes a group of links with common structure and common semantics‟:- A person
works for a company.
They are inherently bidirectional. It means that a binary association can be traversed in both
directions. They are implemented as pointers.
The below figure shows a 1-1 association and corresponding links.

Fig. 2.4 Class Diagram

Subject Notes # Odd Semester 2014-15 Page 3

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Fig.2.5 Instance Diagram

Multiplicity –specifies how many instances of one class may relate to each instance of another class. The
solid balls,”2+” are multiplicity symbols. Associations may be binary, ternary or higher order.

Fig.2.6 Ternary associations and links

7. Advanced Link and Association Concepts:
(i) Link Attributes –A link attribute is a property of the links in an association. In the below figure access
permission is an attribute of „Accessible by‟.

Fig.2.7 Link attribute for a many-many association

* The OMT notation for a link attribute is a box attached to the association by a loop
ii) Role names – A role is an end of an association. Role name is a name that uniquely identifies one end of an
association. Eg: - “Person works for a Company.” Here the person plays the role of an employee and the
company the role of the employer.

Fig.2.8 Role names for an association

Subject Notes # Odd Semester 2014-15 Page 4

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

(iii)Ordering -Sometimes, the objects are explicitly ordered. For example, the figure below shows a
workstation screen containing a number of overlapping windows. The windows are explicitly ordered, so
only the topmost window is visible at any point on the screen.

Fig.2.9 Ordered sets in an association

iv) Qualification – Qualifier is a special attribute that reduces the effective multiplicity of an association. It
reduces the effective multiplicity of an association. We can qualify a one to many and many to many
association.
For eg: - In the below figure a directory has many files .A file may only belong to a single directory. Within
the context of a directory, the file name specifies a unique file .A file corresponds to a directory and a file
name.

Fig.2.10 A qualified association

(v) Aggregation: Aggregation is the “part-whole” relationship in which objects representing the components
of something are associated with an object representing the entire assembly. The figure shows a portion of
an object model for a word processing. Here a document consists of many paragraphs, each of which
consists of many sentences.

Fig. 2.11 Aggregation

8 Generalization and Inheritance: Generalization is the relationship between a class and one or more refined
versions of it. The class being refined is called the „superclass‟ and each refined version are called a
„subclass‟. For example, Equipment is the superclass of Pump and tank. Attributes and operations that are
common to a group of subclasses are attached to the superclass and shared by each subclass. Generalization
is sometimes called a „is-a‟ relationship. Each instance of a subclass is an instance of the superclass. The
notation for generalization is a triangle connecting a superclass to subclass.

Subject Notes # Odd Semester 2014-15 Page 5

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Fig. 3.1 An inheritance hierarchy

The dangling ellipsis in the above figure indicates that there are additional subclasses that are not shown in
the diagram. This may be since there is no room on the sheet and they are shown elsewhere or may be
because enumeration of subclasses is still incomplete. You can also see equipment type written next to the
triangle. This is called as a discriminator.
“A discriminator is an attribute of enumeration type that indicates which property of an object is being
abstracted by a particular generalization relationship.”
What is the use of generalization? Generalization is a useful construct for both conceptual modeling and
implementation.
Overriding Features:
I think you are all familiar with this term. A subclass may override a superclass feature by defining a feature
with the same name. Here you can see that the subclass feature refines and replaces the superclass feature.
What is the need for this feature? The reasons are many
 to specify behavior that depends on the subclass
 to tighten the specification of a feature.
 better performance

Fig. 3.2 Inheritance for graphic figures

In the above figure, you can see that display must be implemented separately for each kind of figure,
although it is defined for any kind of figure.
Subject Notes # Odd Semester 2014-15 Page 6
 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

10 Grouping Constructs:
a) Module- A module is a logical construct for grouping classes, associations, and generalizations. It captures
one view of a situation.
For example: Let us say, electrical, plumbing, etc. are different views of a building.
An object model consists of one or more modules. Class names and association names must be unique
within a module. Module names are usually listed at the top of each sheet. The same class may be
referenced in many modules.
b) Sheet- A sheet is a mechanism for breaking a large object model down into a series of pages. A sheet is a
single printed page. Each module consists of one or more sheets.
Each sheet has a title and a name or number. Each association/generalization appears on a single sheet.
Classes may appear on multiple sheets.

Module 2
Analysis: Analysis in object modeling, dynamic modeling and functional modeling, Adding operations-
Iterating the analysis
System Design: Breaking system into subsystems - Identifying concurrency-allocating subsystems to
processors and tasks, managing of data stores. Handling of global resources- handling boundary conditions-
Common Architectural Frameworks
Problem statement
The first step to develop anything is to state the requirements. Being vague about your objective only
postpones decisions to a later stage where changes are much costly. The problem statement should state
what is to be done and not how it is to be done. It should be a statement of needs, not a proposal for a
solution. The requestor should indicate which features are mandatory and which are optional; to avoid
overly constraining design decisions. The requestor should avoid describing system internals.
A problem statement may have more or less detail. Most problem statements are ambiguous, incomplete or
even inconsistent. Some requirements are wrong. Some requirements have unpleasant consequences on the
system behavior or impose unreasonable implementation costs. Some requirements seem reasonable first.
The problem statement is just a starting point for understanding problem. Subsequent analysis helps in fully
understanding the problem and its implication.
Object Modeling
The first step in analyzing the requirements is to construct an object model. It describes real world object
classes and their relationships to each other. Information for the object model comes from the problem
statement, expert knowledge of the application domain, and general knowledge of the real world. If the
designer is not a domain expert, the information must be obtained from the application expert and checked
against the model repeatedly. The object model diagrams promote communication between computer
professionals and application domain experts.
The steps for object modeling are:

1. Identifying Object Classes

The first step in constructing an object model is to identify relevant object classes from the application
domain. The objects include physical entities as well as concepts. All classes must make sense in the
application domain; avoid computer implementation constructs such as linked lists. Not all classes are
explicit in the problem statement; some are implicit in the application domain or general knowledge.

[Link] the Right classes

Now discard the unnecessary and incorrect classes according to the following criteria:
Redundant Classes - If two classes express the same information, the most descriptive name should be kept.
Irrelevant Classes - If a class has little or nothing to do with the problem, it should be eliminated .this
involves judgment, because in another context the class could be important.
Vague Classes - A class should be specific .Some tentative classes may have ill-defined boundaries or be too
broad in scope.
Attributes - Names that primarily describe individual objects should be restated as attributes. If independent
existence of a property is important, then make it a class and not an attribute.

Subject Notes # Odd Semester 2014-15 Page 7

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Operations - If a name describes an operation that is applied to objects and not manipulated in its own right,
then it is not a class.
Roles - The name of a class should reflect its intrinsic nature and not a role that it plays in an association.
Implementation Constructs - Constructs extraneous to real world should be eliminated from analysis model.
They may be needed later during design, but not now.

3. Preparing a data dictionary

Prepare a data dictionary for all modeling entities .Write a paragraph precisely describing each object class.
Describe the scope of the class within the current problem, including any assumptions or restrictions on its
membership or use. Data dictionary also describes associations, attributes and operations.

4. Identifying Associations
Identify associations between classes .Any dependency between two or more classes is an association. A
reference from one class to another is an association. Associations often correspond to stative verbs or verb
phrases. These include physical location (next to, part of), directed actions (drives), communication (talks to),
ownership (has, part of) or satisfaction of some kind (works for). Extract all the candidates from the problem
statement and get them down on to the paper first, don‟t try to refine things too early. Don‟t spend much
time trying to distinguish between association and aggregation. Use whichever seems most natural at the
time and moves on.
Majority of the associations are taken from verb phrases in the problem statement. For some associations,
verb phrases are implicit. Some associations depend on real world knowledge or assumptions. These must
be verified with the requestor, as they are not in the problem statement.

5. Keeping the right Associations

Discard unnecessary and incorrect associations using the following criteria:
i. Associations between eliminated classes
If one of the classes in the association has been eliminated, then the association must be eliminated or
restated in terms of other classes.
ii. Irrelevant or implementation Associations
Eliminate any association that are outside the problem domain or deal with implementation constructs.
iii. Actions
An association should describe a structural property of the application domain, not a transient event.
iv. Ternary Association
Most associations between three or more classes can be decomposed into binary associations or phrased as
qualified associations. If a term ternary association is purely descriptive and has no features of its own, then
the term is a link attribute on a binary association.
v. Derived Association
Omit associations that can be defined in terms of other associations because they are redundant. Also omit
associations defined by conditions on object attributes.
vi. Misnamed Associations
Don‟t say how or why a situation came about, say what it is. Names are important to understanding and
should be chosen with great care.
vii. Role names
Add role names where appropriate. The role name describes the role that a class in the association plays
from the point of view of other class.
viii. Qualified Associations
Usually a name identifies an object within some context; mostly names are not globally unique. The context
combines with the name to uniquely identify the object.
A qualifier distinguishes objects on the “many” side of an association.
ix. Multiplicity
Specify multiplicity, but don‟t put too much effort into getting it right, as multiplicity often changes during
analysis.
x. Missing Associations
Add any missing associations that are discovered.

Subject Notes # Odd Semester 2014-15 Page 8

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

6. Identifying Attributes
Identify object attributes. Attributes are properties of individual objects, such as name, weight, velocity, or
color. Attributes shouldn‟t be objects, use an association to show any relationship between two objects.
Attributes usually correspond to nouns followed by possessive phrases, such as the „color of the car‟.
Adjectives often represent specific enumerated attribute values, such as red. Unlike classes and associations,
attributes are less likely to be fully described in the problem statement. You must draw on your knowledge
of the application domain and the real world to find them. Attributes seldom affect the basic structure of the
problem. Only consider attributes that directly relate to a particular application. Get the most important
attributes first, fine details can be added later. Avoid attributes which are solely for implementation. Give
each attribute a meaningful name. Derived attributes are clearly labeled or should be omitted. e.g.:- age.
Link attributes should also be identified. They are sometimes mistaken for object attributes.

7. Keeping the Right Attributes

Eliminate unnecessary and incorrect attributes with the following criteria:

object.
e.g.:- Boss is an object and salary is an attribute.
The distinction often depends on the application .An entity that has features of its own within the given
application is an object.
consider restating the attribute
as a qualifier. e.g.:- Employee number is not a unique property of a person with two jobs, it qualifies the
association company employs person.

referencing an object. Do not list these object identifiers in object models, as object identifiers are implicit in
object models. One list attributes which exist in application domain.

and not of related objects. Link attributes are usually obvious on many to many associations, they can’t be
attached to the “many” objects without losing information. Link attributes are also subtle on one-one
association.
Internal values: If an attribute describes the internal state that is invisible outside the object, then
eliminate it from the analysis.
ne detail: Omit minor attributes which are unlikely to affect most operations.

attributes may indicate a class that should be split into two distinct classes.

8. Refining with Inheritance

The next step to organize classes by using inheritance to share common structure .inheritance can be added
in two directions: - by generalizing common aspects of existing classes into a superclass (bottom up), refining
existing classes into specialized subclasses (top down).

9. Testing Access Paths

Trace access paths through object model diagram to see if they yield sensible results. Where a unique value
is expected is there a path yielding a unique result? For multiplicity is there a way to pick out unique values
when needed? Are there useful questions which can’t be answered? Thus we will be able to identify if there
is some missing information.

10. Iterating Object Model

Object model is rarely correct after a single pass. Continuous iteration is needed. Different parts of a model
are iterated often at different stages of completion. If there is any deficiency, go a back to an earlier stage to
correct it. Some refinements are needed only after the functional and dynamic models.
11. Grouping Classes into Modules
Group the classes into sheets and modules. Reuse module from previous design.

Subject Notes # Odd Semester 2014-15 Page 9

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Dynamic Modeling:
Dynamic Modeling shows the time-dependent behavior of the system and the objects in it. Begin dynamic
analysis by looking for events-externally visible stimuli and responses. Summarize permissible event
sequences for each object with a state diagram. Dynamic model is insignificant for a purely static data
repository. It is important in the case of interactive systems. For most problems, logical correctness depends
on the sequences of interactions, not the exact time of interactions. Real time systems do have specific
timing requirements on interactions that must be considered during analysis.
The following steps are performed in constructing a dynamic model:
(i) Preparing a Scenario
Prepare one or more typical dialogs between user and system to get a feel for expected system behavior.
These scenarios show the major interactions, external display format and information exchanges.
Approach the dynamic model by scenarios, to ensure that important steps are not overlooked and that the
overall flow of the interaction is smooth and correct. Sometimes the problem statement describes the full
interaction sequence, but most of the time you will have to invent the interaction format.
The problem statement may specify needed information but leaves open the manner in which it is obtained.
In many applications gathering information is a major task or sometimes the only major task. The dynamic
model is critical in such applications.
First prepare scenarios for “normal “ cases , interactions without any unusual inputs or error conditions
Then consider “special “cases, such as omitted input sequences, maximum and minimum values, and
repeated values.
Then consider user error cases, including invalid values and failures to respond. For many interactive
applications, error handling is the most different part of the implementation. If possible, allow the user to
abort an operation or roll back to a well defined starting point at each step.
Finally consider various other kinds of interactions that can be overlaid on basic interactions, such as help
requests and status queries.
A scenario is a sequence of events .An event occurs when information is exchanged between an object in the
system and an outside agent, such as user. The values exchanged are parameters of the event. The events
with no parameters are meaningful and even common. The information in such event is the fact that it has
occurred a pure signal. Anytime information is input to the system or output from the system.
For each event identify the actor (system, user or other external agent) that caused the event and the
parameters of the event.
The screen layout or output format generally doesn‟t affect the logic of the interaction or the values
exchanged.
Don‟t worry about output formats for the initial dynamic model; describe output formats during refinement
of the model.

(ii) Interface Formats

Most interactions can be separated into two parts:
 application logic
 user interface

Analysis should concentrate first on the information flow and control, rather than the presentation format.
Same program logic can accept input from command lines, files, mouse buttons, touch panels, physical push
buttons, or carefully isolated. Dynamic model captures the control logic of the application. It is hard to
evaluate a user interface without actually testing it .Often the interface can be mocked up so that users can
try it. Application logic can often be simulated with dummy procedures. Decoupling application logic from
user interface allows “look and feel” of the user interface to be evaluated while the application is under
development.

(iii) Identifying Events

Examine the scenario to identify all external events. Events include all signals, inputs, decisions, interrupts,
transitions, and actions to or from users or external devices. Internal computation steps are not events,
except for decision points that interact with the external world .Use scenarios to find normal events, but
don‟t forget error conditions and unusual events. An action by an object that transmits information is an

Subject Notes # Odd Semester 2014-15 Page 10

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

event. Most object to object interaction and operations correspond to events. Some information flows are
implicit. Group together under a single name event that have the same effect on flow of control, even if their
parameter values differ. You must decide when differences in quantitative values are important enough to
distinguish. The distinction depends on the application. You may have to construct the state diagram before
you can classify all events; some distinctions between events may have no effect on behavior and can be
ignored. Allocate each type of event to the object classes that send it and receive it. The event is an output
event for the sender and an input event for the receiver. Sometimes an object sends an event to itself, in
which case the event is both an output and input for the same class. Show each scenario as an event trace –
an ordered list of events between different objects assigned to columns in a table. If more than one object of
the same class participates in the scenario, assign a separate column to each object. By scanning a particular
column in the trace, you can see the events that directly affect a particular object. Only these events can
appear in the state diagram for the object. Show the events between a group of classes (such as a module)
on an event flow diagram. This diagram summarizes events between classes, without regard for sequence.
Include events from all scenarios, including error events. The event flow diagram is a dynamic counterpart to
an object diagram. Paths in the object diagram show possible information flows; paths in the event flow
diagram show possible control flows.

(iv) Building a State Diagram

Prepare a state diagram for each object class with non trivial dynamic behavior , showing the events the
object receives and sends .Every scenario or event trace corresponds to path through the state diagram
.Each branch in a control flow is represented by a state with more than one exit transition. The hardest thing
is deciding at which state an alternative path rejoins the existing diagram. Two paths join at a state if the
object “forgets” which the one was taken. In many cases, it is obvious from your knowledge of the
application that two states are identical. Beware of two paths that appear identical but which can be
distinguished under some circumstances. The judicious use of parameters and conditional transitions can
simplify state diagrams considerably but at the cost of mixing together state information and data. State
diagrams with too much data dependency can be confusing and counterintuitive. Another alternative is to
partition a state diagram into two concurrent subdiagrams, using one subdiagram for the main line and the
other for the distinguishing information. After normal events have been considered, add boundary cases and
special cases. Handling user errors needs more thought and code than normal case. You are finished with the
state diagram of a class when the diagram handles all events that can affect an object of the class in each of
its states. If there are complex interactions with independent inputs, we use nested state diagrams. Repeat
the above process of building state diagrams for each class of objects. Concentrate on classes with important
interactions. Not all classes need state diagrams. Many objects respond to input events independent of their
past history, or capture all important history as parameters that do not affect control. Such objects may
receive and send events. List the input events for each object and output event sent in response to each
input event, but there will be no further state structure. Eventually you may be able to write down state
diagram directly without preparing event traces.

(v) Matching Events between Objects.

Check for completeness and consistency at the system level when the state diagram for each class is
complete .Every event should have a sender and a receiver, occasionally the same object .States without
predecessors or successors are suspicious; make sure they represent starting or termination points of the
interaction sequences .Follow the effects of an input event from object to object through the system to
make sure that they match the scenario. Objects are inherently concurrent; beware of synchronization errors
where an input occurs at an awkward time. Make sure that corresponding events on different state diagrams
are consistent. The set of state diagrams for object classes with important dynamic behavior constitute the
dynamic model for the application.

Functional Modeling
The functional model shows how values are computed, without regard for sequencing, decisions or object
structure. It shows which values depend on which other values and which function relate them. The dfds are
useful for showing functional dependencies .Functions are expressed in various ways, including natural
language, mathematical equations and pseudo code. Processes on dfd corresponds to activities or actions in

Subject Notes # Odd Semester 2014-15 Page 11

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

the state diagrams of the class. Flows on dfd correspond to objects or attribute values on attribute values in
object diagram. Construct the functional model after the two models. The following steps are performed in
constructing functional model:
(i) Identifying input and output values
List input and output values. The input and output values are parameters of events between system and
outside world. Find any input or output values missed.
(ii) Building DFD
Now construct a DFD, show each output value is completed from input values. A DFD is usually constructed
in layers. The top layer may consist of a single process, or perhaps one process to gather inputs, compute
values, and generate outputs. Within each dfd layer, work backward from each output value to determine
the function that computes it. If the inputs are operations are all inputs of the entire diagram, you are done;
otherwise some of the operation inputs are intermediate values that must be traced backward in turn. You
can also trace forward from inputs to outputs, but it is usually harder to identify all users of an input, than to
identify all the sources of an output.
o Expand each non trivial process in the top level DFD into a lower level DFD.
o Most systems contain internal storage objects that retain values between iterations. An internal store can
be distinguished from a data flow or a process because it receives values that don‟t result in immediate
outputs but are used at some distant time in the future.
o The DFD show only dependencies among operations. They don‟t show decisions.(control flows)

iii) Describing Functions

When the dfd has been refined enough, write a description of each function. The description can be in
natural language, mathematical equations, pseudocode, decision tables, or some appropriate form.
o Focus on what the function does, and not how it is implemented.
o The description can be declarative or procedural.
o A declarative description specifies the relationships between input and output values and the relationships
among output values.

For example, “sort and remove duplicate values”

Declarative: “Every value in the input list appears exactly once in the output list, and the values in the output
list are in strictly increasing order.”
Procedural:-specifies function by giving an algorithm to compute it. The purpose of the algorithm is only to
specify what the function does.
A declarative description is preferable; they don‟t imply implementation but if procedural is easy it should
be used.
iv) Identify constraints between objects
Identify constraints between objects. Constraints are functional dependencies between objects that are not
related by an input output dependency. Constraints can be on two objects at the same time, between
instances of the same object at different times (an invariant) or between instances of different object at
different times.
-> Preconditions on functions are constraints that the input values must satisfy.
-> Post conditions are constraints that the output values are guaranteed to hold.
-> State the times or conditions under which the constraints hold.
v) Specifying Optimization criteria
Specify values to be maximized, minimized or optimized. If there is several optimization criteria that conflict,
indicate how the trade-off is to be decided.

System Design
System design is the high-level strategy for solving the problem and building a solution.
The steps involved in system design are:
1. estimating system performance
Prepare a rough performance estimate. The purpose is not to achieve high accuracy, but merely to
determine if the system is feasible.
2. making a reuse plan

Subject Notes # Odd Semester 2014-15 Page 12

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

There are 2 different aspects of reuse – using existing things and creating reusable new things. It is much
easier to reuse existing things than to design new things. Reusable things include models, libraries, patterns,
frameworks etc.

Breaking a system into subsystems

First step of system design is to divide the system in a small number of subsystems. Each subsystem
encompasses aspects of the system that share some common property such as similar functionality, same
physical location, execution on same kind of hardware.
A subsystem is a package of classes, associations, operations, events and constraints interrelated and have a
well defined small interface with other subsystems. Subsystems are identified by the services provided.
Determining subsystems allow a division of labor so each can be designed by a separate team.
Most interactions should be within subsystems rather than across boundaries and it reduces dependencies
among subsystems.
Relationship between two subsystems can be client-supplier or peer-to-peer. In a client-supplier
relationship, the client calls on the supplier for service. Client must know the interface of the supplier but not
vice versa. In a peer-to-peer relationship, each can call on the other and therefore they must know each
others interfaces. One way communication (client-supplier) is much easier to build, understand and change
than two way (Peer-to-Peer).
The decomposition of systems into subsystems may be organized as a sequence of layers or partitions.
Layered system is an ordered set of virtual worlds, a layer knows about the layer below but not above. A
client supplier relationship exists between lower layers and upper layers.
Partitions divide into several independent SS, each providing a type of service. A system can be a hybrid of
layered and partitioned

Choosing the system topology

System Topology defines the flow of information among subsystems. The flow may be a pipeline (compiler)
or star which has a master that controls all other interactions. Try to use simple topologies when possible to
reduce the number of interactions between subsystems.
In analysis as in the real world and in hardware all objects are concurrent. In implementation not all software
objects are concurrent because one processor may support many objects. An important goal of system
design is to identify which object must be active concurrently and which objects have activity that is mutually
exclusive (not active at the same time). The latter objects can be folded into a single thread of control or task
(runs on a single processor).

Identifying Concurrency
Dynamic Modeling is the guide to concurrency - Two objects are said to be inherently concurrent if they can
receive events at the same time without interacting. If the events are unsynchronized, the objects cannot be
folded into a single thread of control. (engine and wing control on an airplane must operate concurrently)
Two subsystems that are inherently concurrent need not necessarily be implemented as separate hardware
units. The purpose of interrupts, Operating System and tasking mechanism is to simulate logical concurrency
in a uniprocessor - so if there are no timing constraints on the response then a multitasking Operating
System can handle the computation.
All objects are conceptually concurrent, but many objects are interdependent. By examining the state
diagram of individual objects and the exchange of events between them, many objects can be folded into a
single thread of control. A thread of control is a path through a set of state diagrams on which only a single
object at a time is active - thread remains in a state diagram until an object sends an event to another object
and waits for another event.
On each thread of control only a single object is active at a time. Threads of control are implemented as tasks
in computer systems.

Estimating Hardware Resource Requirements

The decision to use multiple processors or hardware functional units is based on the need for higher
performance than a single CPU can provide (or fault tolerant requests). Numbers of processors determine
the volume of computations and speed of the machine.

Subject Notes # Odd Semester 2014-15 Page 13

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

The system designer must estimate the required CPU power by computing the steady state load as the
product of the number of transactions per second and the time required to process a transaction.
Experimentation is often useful to assist in estimating.

Hardware/Software Tradeoffs
Hardware can be viewed as a rigid but highly optimized form of software. The system designer must decide
which subsystems will be implemented in hardware and which in software.
Subsystems are in hardware for 2 reasons:
Existing hardware provides exactly the functionality required – e.g. floating point processor
Higher performance is required than a general purpose CPU can provide.
Compatibility, cost, performance, flexibility are considerations whether to use hardware or software.
Software in many cases may be more costly than hardware because the cost of people is very high.
Hardware of course is much more difficult to change than software.
Allocating Tasks To Processors
Tasks are assigned to processors because:
Certain tasks are required at specific physical locations
Response time or information flow rate exceeds the available communication bandwidth between a task and
a piece of hardware.
Computation rates are too great for single processor, so tasks must be spread among several processors.

8. Management Of Data Stores

The internal and external data stores in a system provide clean separation points between subsystems with
well defined interfaces. Data stores may combine data structures, files, and database implemented in
memory or on secondary storage devices. The different data stores provide trade-offs between cost, access
time, capacity and reliability.
Files are cheap, simple and permanent form of data store. File operations are low level and applications
must include additional code to provide a suitable level of abstraction. File implementations vary from
machine to machine so portability is more difficult.
Databases are powerful and make applications easier to port. They do have a complex interface and may
work awkwardly with programming languages.
The kind of data that belongs in a Database:
 Data that requires access at fine levels of detail by multiple users
 Data that can be efficiently managed by DBMS commands
 Data that must be ported across many hardware and operating system platforms
 Data that must be accessible by more than one application program.
 The kind of data that belongs in a file:
 Data that is voluminous but difficult to structure within the confines of a Database (graphics bit map)
 Data that is voluminous and of low information density (debugging data, historical files)
 Raw data that is summarized in the Database
 Volatile data

Advantages Of Using A Database

 Handles crash recovery, concurrency, integrity
 Common interface for all applications
 Provides a standard access language - SQL

Disadvantages Of Using A Database

 Performance overhead
 Insufficient functionality for advanced applications - most databases are structured for business
applications.
 Awkward interface with programming languages.

Subject Notes # Odd Semester 2014-15 Page 14

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Handling Global Resources

The system designer must identify the global resources and determine mechanisms for controlling access to
them - processors, tape drives, etc
If the resource is a physical object, it can control itself by establishing a protocol for obtaining access within a
concurrent system. If the resource is logical entity (object ID for example) there is a danger of conflicting
access. Independent tasks could simultaneously use the same object ID. Each global resource must be owned
by a guardian object that controls access to it.

Choosing Software Control Implementation

There are two kinds of control flows in a software system: external control and internal control. Internal
control is the flow of control within a process. It exists only in the implementation and therefore is not
inherently concurrent or sequential. External control is the flow of externally visible events among the
objects in the system.
There are three kinds of external control:
Procedure driven systems: control resides within program code; it is easy to implement but requires that
concurrency inherent in objects be mapped into a sequential flow of control.
Event driven systems - control resides within a dispatcher or monitor provided by the language, subsystem
or operating system. Application procedures are attached to events and are called by the dispatcher when
the corresponding events occur.
Concurrent systems: control resides concurrently in several independent objects, each a separate task.

11. Handling Boundary Conditions

We must be able to handle boundary conditions such as initialization, termination and failure.
1. Initialization: The system must be brought from a quiescent initial state to a sustainable steady state
condition. Things to be initialized include constant data, parameters, global variables, tasks, guardian objects
and possibly the class hierarchy itself.
2. Termination: It is usually simpler than initialization because many internal objects can simply be
abandoned. The task must release any external resources that it had reserved. In a concurrent system, one
task must notify other tasks of its termination.
3. Failure: It is the unplanned termination of a system. Failure can arise from user errors, from the
exhaustion of system resources, or from an external breakdown.

Setting Trade-Off Priorities

Cost, maintainability, portability, understandability, speed, may be traded off during various parts of system
design.

Common Architectural Frameworks

There are several prototypical architectural frameworks that are common in existing systems. Each of these
is well-suited to a certain kind of system. If we have an application with similar characteristics, we can save
effort by using the corresponding architecture, or at least use it as a starting point for our design. The kinds
of systems include:
1. Batch transformation: It is a data transformation executed once on an entire input set. A batch
transformation is a sequential input-to-output transformation, in which inputs are supplied at the start, and
the goal is to compute an answer. There is no ongoing interaction with the outside world. The most
important aspect of the batch transformation is the functional model which specifies how input values are
transformed into output values. The steps in designing a batch transformation are:
1) Break the overall transformation into stages, each stage performing one part of the transformation. The
system diagram is a data flow diagram. This can usually be taken from the functional model.
2) Define intermediate object classes for the data flows between each pair of successive stages.
3) Expand each stage in turn until the operations are straightforward to implement.
4) Restructure the final pipeline for optimization.

2. Continuous Transformation: It is a system in which the outputs actively depend on changing inputs and
must be periodically updated. Because of severe time constraints, the entire set of outputs cannot usually be

Subject Notes # Odd Semester 2014-15 Page 15

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

recomputed each time an input changes. Instead, the new output values must be computed incrementally.
The transformation can be implemented as a pipeline of functions. The effect of each incremental change in
an input value must be propagated through the pipeline. The steps in designing a pipeline for continuous
transformation are:
1. Draw a DFD for the system. The input and output actors correspond to data structures whose value
change continuously. Data stores within the pipeline show parameters that affect the input-to-output
mapping.
2. Define intermediate objects between each pair of successive stages.
3. Differentiate each operation to obtain incremental changes to each stage.
4. Add additional intermediate objects for optimization.

3. Interactive Interface: An interactive interface is a system that is dominated by interactions between the
system and external agents, such as humans, devices or other programs. The external agents are
independent of the system, so their inputs cannot be controlled. Interactive interfaces are dominated by the
dynamic model. The steps in designing an interactive interface are:
1. Isolate the objects that form the interface from the objects that define the semantics of the application.
2. Use predefined objects to interact with external agents, if possible.
3. Use the dynamic model as the structure of the program.
4. Isolate physical events from logical events.
5. Fully specify the application functions that are invoked by the interface. Make sure that the information to
implement them is present.

4. Dynamic Simulation: A dynamic simulation models or tracks objects in the real world. The steps in
designing a dynamic simulation are:
1. Identify actors, real-world objects from the object model. The actors have attributes that are periodically
updated. The actors have attributes that are periodically updated.
2. Identify discrete events. Discrete events correspond to discrete interactions with the object. Discrete
events can be implemented as operations on the object.
3. Identify continuous dependencies.
4. Generally a simulation is driven by a timing loop at a fine time scale. Discrete events between objects can
often be exchanged as part of the timing loop.

5. Transaction Manager: A transaction manager is a database system whose main function is to store and
access information. The information comes from the application domain. Most transaction managers must
deal with multiple users and concurrency. The steps in designing a transaction management system are:
1. Map the object model directly into a database.
2. Determine the units of concurrency. Introduce new classes as needed.
3. Determine the unit of transaction.
4. Design concurrency control for transactions.

Module 3
Object Design: Overview of Object design – Combining the three models – Designing algorithms – Design
optimization – Implementation of control – Adjustment of inheritance - Design of association – Object
representation – Physical packaging – Documenting design decisions-Comparison of methodologies

Object Design
The object design phase determines the full definitions of the classes and associations used in the
implementation, as well as the interfaces and algorithms of the methods used to implement operations. The
object design phase adds internal objects for implementation and optimizes data structures and algorithms.
Overview of Object Design
During object design, the designer carries out the strategy chosen during the system design and fleshes out
the details. There is a shift in emphasis from application domain concepts toward computer concepts. The
objects discovered during analysis serve as the skeleton of the design, but the object designer must choose
among different ways to implement them with an eye toward minimizing execution time, memory and other

Subject Notes # Odd Semester 2014-15 Page 16

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

measures of cost. The operations identified during the analysis must be expressed as algorithms, with
complex operations decomposed into simpler internal operations. The classes, attributes and associations
from analysis must be implemented as specific data structures. New object classes must be introduced to
store intermediate results during program execution and to avoid the need for recomputation. Optimization
of the design should not be carried to excess, as ease of implementation, maintainability, and extensibility
are also important concerns.

Steps of Design:
During object design, the designer must perform the following steps:
1. Combining the three models to obtain operations on classes.
2. Design algorithms to implement operations. 3. Optimize access paths to data.
4. Implement control for external interactions
5. Adjust class structure to increase inheritance.
6. Design associations.
7. Determine object representation.
8. Package classes and associations into modules.

a) Combining the three models to obtain operations on classes.

After analysis, we have object, dynamic and functional model, but the object model is the main framework
around which the design is constructed. The object model from analysis may not show operations. The
designer must convert the actions and activities of the dynamic model and the processes of the functional
model into operations attached to classes in the object model. Each state diagram describes the life history
of an object. A transition is a change of state of the object and maps into an operation on the object. We can
associate an operation with each event received by an object. In the state diagram, the action performed by
a transition depends on both the event and the state of the object. Therefore, the algorithm implementing
an operation depends on the state of the object. If the same event can be received by more than one state
of an object, then the code implementing the algorithm must contain a case statement dependent on the
state. An event sent by an object may represent an operation on another object .Events often occur in pairs ,
with the first event triggering an action and the second event returning the result on indicating the
completion of the action. In this case, the event pair can be mapped into an operation performing the action
and returning the control provided that the events are on a single thread. An action or activity initiated by a
transition in a state diagram may expand into an entire dfd in the functional model .The network of
processes within the dfd represents the body of an operation. The flows in the diagram are intermediate
values in operation. The designer convert the graphic structure of the diagram into linear sequence of steps
in the algorithm .The process in the dfd represent suboperations. Some of them, but not necessarily all may
be operations on the original target object or on other objects. Determine the target object of a
suboperation as follows:
* If a process extracts a value from input flow then input flow is the target.
* Process has input flow or output flow of the same type, input output flow is the target.
* Process constructs output value from several input flows, then the operation is a class operation on output
class.
* If a process has input or an output to data store or actor, data store or actor is the target.
b) Designing algorithms
Each operation specified in the functional model must be formulated as an algorithm. The analysis
specification tells what the operation does from the view point of its clients, but the algorithm shows how it
is done. The analysis specification tells what the operation does from the view point of its clients, but the
algorithm shows how it is done. An algorithm may be subdivided into calls on simpler operations, and so on
recursively, until the lowest-level operations are simple enough to implement directly without refinement
.The algorithm designer must decide on the following:
i) Choosing algorithms
Many operations are simple enough that the specification in the functional model already constitutes a
satisfactory algorithm because the description of what is done also shows how it is done. Many operations
simply traverse paths in the object link network or retrieve or change attributes or links.
Non trivial algorithm is needed for two reasons:

Subject Notes # Odd Semester 2014-15 Page 17

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

a) To implement functions for which no procedural specification

b) To optimize functions for which a simple but inefficient algorithm serves as a definition.
Some functions are specified as declarative constraints without any procedural definition. In such cases, you
must use your knowledge of the situation to invent an algorithm. The essence of most geometry problems is
the discovery of appropriate algorithms and the proof that they are correct. Most functions have simple
mathematical or procedural definitions. Often the simple definition is also the best algorithm for computing
the function or else is also so close to any other algorithm that any loss in efficiency is the worth the gain in
clarity. In other cases, the simple definition of an operation would be hopelessly inefficient and must be
implemented with a more efficient algorithm.
For example, let us consider the algorithm for search operation .A search can be done in two ways like binary
search (which performs log n comparisons on an average) and a linear search (which performs n/2
comparisons on an average).Suppose our search algorithm is implemented using linear search , which needs
more comparisons. It would be better to implement the search with a much efficient algorithm like binary
search.
Considerations in choosing among alternative algorithm include:
a) Computational Complexity:
It is essential to think about complexity i.e. how the execution time (memory) grows with the number of
input values.
For example: For a bubble sort algorithm, time ∞ n2
Most other algorithms, time ∞ n log n
b) Ease of implementation and understandability:
It is worth giving up some performance on non critical operations if they can be implemented quickly with a
simple algorithm.
c) Flexibility:
Most programs will be extended sooner or later. A highly optimized algorithm often sacrifices readability and
ease of change. One possibility is to provide two implementations of critical applications, a simple but
inefficient algorithm that can be implemented, quickly and used to validate the system, and a complicated
but efficient algorithm whose correct implementation can be checked against the simple one.
d) Fine Timing the Object Model:
We have to think, whether there would be any alternatives, if the object model were structured differently.
ii) Choosing Data Structures
Choosing algorithms involves choosing the data structures they work on. We must choose the form of data
structures that will permit efficient algorithms. The data structures do not add information to the analysis
model, but they organize it in a form convenient for the algorithms that use it.
iii) Defining Internal Classes and Operations
During the expansion of algorithms, new classes of objects may be needed to hold intermediate results.
New, low level operations may be invented during the decomposition of high level operations. A complex
operation can be defined in terms of lower level operations on simpler objects. These lower level operations
must be defined during object design because most of them are not externally visible. Some of these
operations were found from “shopping –list”. There is a need to add new internal operations as we expand
high –level functions. When you reach this point during the design phase, you may have to add new classes
that were not mentioned directly in the client‟s description of the problem. These low-level classes are the
implementation elements out of which the application classes are built.
iv) Assigning Responsibility for Operations
Many operations have obvious target objects, but some operations can be performed at several places in an
algorithm, by one of the several places, as long as they eventually get done. Such operations are often part
of a complex high-level operation with many consequences. Assigning responsibility for such operations can
be frustrating, and they are easy to overlook in laying out object classes because they are easy to overlook in
laying out object classes because they are not an inherent part of one class. When a class is meaningful in
the real world, then the operations on it are usually clear. During implementation, internal classes are
introduced.

Subject Notes # Odd Semester 2014-15 Page 18

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

How do you decide what class owns an operation?

When only one object is involved in the operation, tell the object to perform the operation. When more than
one object is involved, the designer must decide which object plays the lead role in the operation. For that,
ask the following questions:
Is one object acted on while the other object performs the action? It is best to associate the operation with
the target of the operation, rather than the initiator.
Is one object modified by the operation, while other objects are only queried for the information they
contain? The object that is changed is the target.
Looking at the classes and associations that are involved in the operation, which class is the most centrally-
located in this subnetwork of the object model? If the classes and associations form a star about a single
central class, it is the target of the operation.
If the objects were not software, but the real world objects represented internally, what real world objects
would you push, move, activate or manipulate to initiate operation?

Assigning an operation within a generalization hierarchy can be difficult. Since the definitions of the
subclasses within the hierarchy are often fluid and can be adjusted during design as convenient. It is
common to move an operation up and down in the hierarchy during design, as its scope is adjusted.

Design Optimization
The basic deign model uses the analysis model as the framework for implementation .
The analysis model captures the logical information about the system, while the design model must add
details to support efficient information access. The inefficient but semantically correct analysis model can be
optimized to make the implementation more efficient, but an optimized system is more obscure and less
likely to be reusable in another context. The designer must strike an appropriate balance between efficiency
and clarity. During design optimization, the designer must
i) Add Redundant Associations for Efficient Access
During analysis, it is undesirable to have redundancy in association network because redundant associations
do not add any information. During design, however we evaluate the structure of the object model for an
implementation. For that, we have to answer the following questions:
* Is there a specific arrangement of the network that would optimize critical aspects of the completed
system?
* Should the network be restructured by adding new associations?
* Can existing associations be omitted?
The associations that were useful during analysis may not form the most efficient network when the access
patterns and relative frequencies of different kinds of access are considered. In cases where the number of
hits from a query is low because only a fraction of objects satisfy the test, we can build an index to improve
access to objects that must be frequently retrieved.
Analyze the use of paths in the association network as follows:

associations are traversed in both directions, and which are traversed in a single direction only, the latter can
be implemented efficiently with one way pointers.
For each operation note the following items:

-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, don‟t worry about such
small effects.

operated on? If most objects are rejected during the traversal for some reason, then a simple nested loop
may be inefficient at finding target objects. Provide indexes for frequent, costly operations with a low hit
ratio because such operations are inefficient to implement using nested loops to traverse a path in the
network.

Subject Notes # Odd Semester 2014-15 Page 19

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

ii)Rearranging Execution Order for Efficiency

After adjusting the structure of the object model to optimize frequent traversal, the next thing to optimize is
the algorithm itself. Algorithms and data structures are directly related to each other, but we find that
usually the data structure should be considered first. One key to algorithm optimization is to eliminate dead
paths as early as possible. Sometimes the execution order of a loop must be inverted.
iii) Saving Derived Attributes to Avoid Recomputation:
Data that is redundant because it can be derived from other data can be “cached” or store in its computed
form to avoid the overhead of recomputing it. The class that contains the cached data must be updated if
any of the objects that it depends on are changed.
Derived attributes must be updated when base values change. There are 3 ways to recognize when an
update is needed:

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.
all 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 incremental approach. Periodic
recomputation is simpler than explicit update 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.

with the active value, which contains a set of dependent values and update operations. An operation to
update the base value triggers updates all dependent values, but the calling code need not explicitly invoke
the updates. It provides modularity.

Implementation of Control
The designer must refine the strategy for implementing the state – event models present in the dynamic
model. As part of system design, you will have chosen a basic strategy for realizing dynamic model, during
object design flesh out this strategy. There are three basic approaches to implementing the dynamic model:
i) State as Location within a Program:
This is the traditional approach to representing control within a program. The location of control within a
program implicitly defines the program state. Any finite state machine can be implemented as a program.
Each state transition corresponds to an input statement. After input is read, the program branches
depending on the input event received. Each input statement need to handle any input value that could be
received at that point. In highly nested procedural code, low –level procedures must accept inputs that they
may know nothing about and pass them up through many levels of procedure calls until some procedure is
prepared to handle them.
One technique of converting state diagram to code is as follows:
1. Identify the main control path. Beginning with the initial state, identify a path through the diagram that
corresponds to the normally expected sequence of events. Write the name of states along this path as a
linear sequence of events. Write the names of states along this path as a linear sequence .This becomes a
sequence of statements in the program.
2. Identify alternate paths that branch off the main path and rejoin it later. These become conditional
statements in the program.
3. Identify backward paths that branch off the main loop and rejoin it earlier .These become loops in
program. If multiple backward paths that do not cross, they become nested loops. Backward paths that cross
do not nest and can be implemented with goto if all else fails, but these are rare.
4. The status and transitions that remain correspond to exception conditions. They can be handled using
error subroutines , exception handling supported by the language , or setting and testing of status flags. In
the case of exception handling, use goto statements.

Subject Notes # Odd Semester 2014-15 Page 20

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

ii) State machine engine

The most direct approach to control is to have some way of explicitly representing and executing state
machine. For example, state machine engine class helps execute state machine represented by a table of
transitions and actions provided by the application. Each object instance would contain its own independent
state variables but would call on the state engine to determine next state and action. This approach allows
you to quickly progress from analysis model to skeleton prototype of the system by defining classes from
object model state machine and from dynamic model and creating “stubs” of action routines. A stub is a
minimal definition of function /subroutine without any internal code. Thus if each stub prints out its name ,
technique allows you to execute skeleton application to verify that basic flow of control is correct. This
technique is not so difficult.
iii) Control as Concurrent Tasks
An object can be implemented as task in programming language /operating system. It preserves inherent
concurrency of real objects. Events are implemented as inter task calls using facilities of language/operating
system. Concurrent C++/Concurrent Pascal support concurrency. Major Object Oriented languages do not
support concurrency.

Adjustment of Inheritance
The definitions of classes and operations can often be adjusted to increase the amount of inheritance.
The designer should:
i) 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. Before inheritance can be used , each operation must have the
same interface and the types of arguments and results. If the signatures match, then the operations must be
examined to see if they have the same semantics. The following kinds of adjustments can be used to
increase the chance of inheritance.
Some operations may have fewer arguments than others .The missing arguments can be added but ignored.
Some operations may have few arguments because they are special cases of more general arguments
.Implement the special operations by calling the general operation with appropriate parameter values.
Similar attributes in different classes may have different names. Give the attributes the same name and
move them to a common ancestor class. These operations that access the attributes will match better.
Any operation may be defined on several different classes in a group but undefined on the other classes.
Define it on the common ancestor class and define it as no operation on the values that do not care about it.
ii) Abstracting Out Common Behavior
Reexamine the object model looking for commonality between classes. New classes and operations are
often added during design. If a set of operations / attributes seems to be repeated in two classes , it is
possible that the two classes are specialized variations of the sane thing. When common behavior has been
recognized , a common superclass can be created that implements the shared features , specialized features
in subclass. This transformation of the object model is called abstracting out a common superclass / common
behavior .usually the superclass is abstract meaning no direct instances. Sometimes a superclass is
abstracted even when there is only one subclass; here there is no need of sharing. Superclass may be
reusable in future projects. It is an addition to the class library. When a project is completed , the reusable
classes should be collected, documented and generalized so that they may be used in future projects..
Another advantage of abstract superclasses other than sharing and reuse is modularity. Abstract
superclasses improve the extensibility of a software product. It helps in the configuration management of
software maintenance and distribution.

iii) Use Delegation to Share Implementation

Sometimes programmers use inheritance as an implementation technique with no intention of guaranteeing
the same behavior. Sometimes an existing class implements some of the behavior that we want to provide in
a newly defined class, although in other respects the two classes are different. The designer may inherit from
the existing class to achieve part of the implementation of the new class. This can lead to problems –
unwanted behavior.

Subject Notes # Odd Semester 2014-15 Page 21

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

Design of Associations
During object design phase, we must formulate a strategy for implementing all associations in the object
model. We can either choose a global strategy for implementing all associations uniformly , or a particular
technique for each association.
i) Analyzing Association Traversal
Associations are inherently bidirectional. If association in your application is traversed in one direction, their
implementation can be simplified. The requirements on your application may change, you may need to add a
new operation later that needs to traverse the association in reverse direction. For prototype work, use
bidirectional association so that we can add new behavior and expand /modify. In the case of optimization
work, optimize some associations.
ii) One-way association
* If an association is only traversed in one direction it may be implemented as pointer.
* If multiplicity is „many‟ then it is implemented as a set of pointers.
* If the “many” is ordered , use list instead of set .
* A qualified association with multiplicity one is implemented as a dictionary object(A dictionary is a set of
value pairs that maps selector values into target values.
* Qualified association with multiplicity “many” are rare.(it is implemented as dictionary set of objects).
iii) Two-way associations
Many associations are traversed in both directions, although not usually with equal frequency. There are
three approaches to their implementation:
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 great disparity in traversal frequency and minimizing both the storage
cost and update cost are important.
Implement as attributes in both directions. 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 if accesses
outnumber updates.

Implement as a distinct association object independent of either class. An association object is a set of pairs
of associated objects stored in a single variable size object. An association object can be implemented using
two dictionary object one for forward direction and other for reverse direction.

Subject Notes # Odd Semester 2014-15 Page 22

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

iv) Link Attributes

Its implementation depends on multiplicity .
If it is a one-one association , link attribute is stored in any one of the classes involved.
If it is a many-one association, the link attribute can be stored as attributes of many object ,since each “
many object appears only once in the association.
If it is a many-many association, the link attribute can‟t be associated with either object; implement
association as distinct class where each instance is one link and its attributes.

Object Representation
Implementing objects is mostly straight forward, but the designer must choose when to use primitive types
in representing objects and when to combine groups of related objects. Classes can be defined in terms of
other classes, but eventually everything must be implemented in terms of built-in-primitive data types, such
as integer strings, and enumerated types. For example, consider the implementation of a social security
number within an employee object. It can be implemented as an attribute or a separate class.
Defining a new class is more flexible but often introduces unnecessary indirection. In a similar vein, the
designer must often choose whether to combine groups of related objects.

Physical Packaging
Programs are made of discrete physical units that can be edited, compiled, imported, or otherwise
manipulated. In C and Fortran the units are source files; In Ada, it is packages. In object oriented languages,
there are various degrees of packaging. In any large project, careful partitioning of an implementation into
packages is important to permit different persons to cooperatively work on a program.
Packaging involves the following issues:
i) Hiding internal information from outside view.
One design goal is to treat classes as „black boxes‟ , whose external interface is public but whose internal
details are hidden from view. Hiding internal information permits implementation of a class to be changed
without requiring any clients of the class to modify code. Additions and changes to the class are surrounded
by “fire walls” that limit the effects of any change so that changes can be understood clearly. Trade off
between information hiding and optimization activities. During analysis , we are concerned with information
hiding. During design , the public interface of each class must be defined carefully. The designer must decide
which attributes should be accessible from outside the class. These decisions should be recorded in the
object model by adding the annotation {private} after attributes that are to be hidden , or by separating the
list of attributes into 2 parts. Taken to an extreme a method on a class could traverse all the associations of
the object model to locate and access another object in the system .This is appropriate during analysis , but
methods that know too much about the entire model are fragile because any change in representation

Subject Notes # Odd Semester 2014-15 Page 23

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

invalidates them. During design we try to limit the scope of any one method. We need top define the bounds
of visibility that each method requires.
Specifying what other classes a method can see defines the dependencies between classes. Each operation
should have a limited knowledge of the entire model, including the structure of classes, associations and
operations. The fewer things that an operation knows about, the less likely it will be affected by any changes.
The fewer operations know about details of a class, the easier the class can be changed if needed.
The following design principles help to limit the scope of knowledge of any operation:
Allocate to each class the responsibility of performing operations and providing information that pertains to
it.
Call an operation to access attributes belonging to an object of another class
Avoid traversing associations that are not connected to the current class.
Define interfaces at as high a level of abstraction as possible.
Hide external objects at the system boundary by defining abstract interface classes, that is, classes that
mediate between the system and the raw external objects.
Avoid applying a method to the result of another method, unless the result class is already a supplier of
methods to the caller. Instead consider writing a method to combine the two operations.

ii) Coherence of entities.

One important design principle is coherence of entities. An entity ,such as a class , an operation , or a module
, is coherent if it is organized on a consistent plan and all its parts fit together toward a common goal. It
shouldn‟t be a collection of unrelated parts. A method should do one thing well .a single method should not
contain both policy and implementation.
“A policy is the making of context dependent decisions.”
“Implementation is the execution of fully specified algorithms.”
Policy involves making decisions, gathering global information, interacting with outside world and
interpreting special cases. Policy methods contain input output statements, conditionals and accesses data
stores. It doesn‟t contain complicated algorithms but instead calls various implementation methods. An
implementation method does exactly one operation without making any decisions, assumptions, defaults or
deviations .All information is supplied as arguments(list is long). Separating policy and implementation
increase reusability. Therefore implementation methods don‟t contain any context dependency. So they are
likely to be reusable Policy method need to be rewritten in an application , they are simple and consists of
high level decisions and calls on low-level methods. A class shouldn‟t serve too many purposes.
iii) Constructing physical modules.
During analysis and system design phases we partitioned the object model into modules.
* The initial organization may not be suitable for final packaging of system implementation
new classes added to existing module or layer or separate module.
Modules should be defined so that interfaces are minimal and well defined.
Connectivity of object model can be used as a guide for partitioning modules. Classes that are closely
connected by associations should be in the same module. Loosely connected classes should be grouped in
separate modules.
Classes in a module should represent similar kinds of things in the application or should be components of
the same composite object.
Try to encapsulate strong coupling within a module. Coupling is measured by number of different operations
that traverse a given association. The number expresses the number of different ways the association is
used, not the frequency.

Documenting Design Decisions

The above design decisions must be documented when they are made, or you will become confused. This is
especially true if you are working with other developers. It is impossible to remember design details for any
non trivial software system, and documentation is the best way of transmitting the design to others and
recording it for reference during maintenance.
The design document is an extension of the Requirements Analysis Document.

Subject Notes # Odd Semester 2014-15 Page 24

 Allenhouse Institute of Technology (UPTU Code : 505)
OOT Notes by Hammad Lari for [Link] CSE Vth Sem

-> The design document includes revised and much more detailed description of the object model-both
graphical and textual. Additional notation is appropriate for showing implementation decisions, such as
arrows showing the traversal direction of associations and pointers from attributes to other objects.
-> Functional model will also be extended. It specifies all operation interfaces by giving their arguments,
results, input-output mappings and side effects.
-> Dynamic model – if it is implemented using explicit state control or concurrent tasks then the analysis
model or its extension is adequate. If it is implemented by location within program code, then structured
pseudocode for algorithms is needed.
Keep the design document different from analysis document .The design document includes many
optimizations and implementation artifacts. It helps in validation of software and for reference during
maintenance. Traceability from an element in analysis to element in design document should be
straightforward. Therefore the design document is an evolution of analysis model and retains same names.

Subject Notes # Odd Semester 2014-15 Page 25