Page 182 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes Packaging involves the following issues:
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 invalidates them. During
design we try to limit the scope of any one method. We need to 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.
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

176 LOVELY PROFESSIONAL UNIVERSITY