Some work has been carried out to establish design quality metrics to establish whether or not a design is a good design. These have mostly been developed in conjunction with structured design methods.
Quality characteristics are equally applicable to object-oriented and function-oriented design. Because of the inherent nature of object-oriented designs, it is usually easier to achieve maintainable designs because information is concealed within objects. However, inheritance in object-oriented systems can compromise design quality.
Cohesion
The cohesion of a component is a measure of how well it fits together. A component should implement a single logical function or should implement a single logical entity. All of the parts of the component should contribute to this implementation. If the component includes parts which are not directly related to its logical function (for example, if it is a grouping of unrelated operations which are executed at the same time) it has a low degree of cohesion.
There are seven levels of cohesion, which, in order of increasing strength of cohesion are given below:
- Coincidental cohesion: The parts of a component are not
-13-
related but simply bundled into a single component.
- Logical association: Components which perform similar
functions such as input, error handling, etc. are put
together in a single component.
- Temporal cohesion: All of the components which are
activated at a single time, such as start up or shut
down, are brought together.
- Procedural cohesion: The elements in a component make
up a single control sequence.
- Communicational cohesion: All of the elements of a
component operate on the same input data or produce
the same output data.
- Sequential cohesion: The output from one element in the
component serves as input for some other element.
- Functional cohesion: Each part of the component is
necessary for the execution of a singfle function.
These cohesion classes are not strictly defined and
Constantine and Yourdon illustrate each by example. It is not
always easy to decide under what cohesion category a unit
should be classed.
It is not always easy to decide under what cohesion category a unit should be classed. It is obvious that the most cohesive from of unit is the function. However, a high degree of cohesion is also a
feature of object-oriented systems. Indeed, one of the
principal advantages of this approach to design is that the
objects making up the system are naturally cohesive.
-14-
A cohesive object is one where a single entity is
represented and all of the operations on that entity are
included with the object. For example, an object
representing a complier symbol table is cohesive if all of
the functions such as ‘Add a symbol’, ‘Search table’, and so
on, are included with the symbol table object.
Thus, a further class of cohesion might be defined as
follows:
- Object cohesion: Each operation provides functionality
which allows the attributes of the object to be
modified, inspected or used as a basis for service
provision.
Cohesion is a desirable characteristic because it means that
a unit represents a single part of the problem solution. Of
It becomes necessary to change the system, that part exists
in a single place and everything to do with it is
encapsulated in a single unit. There is no need to modify
many components if a change has to be made.
If functionality is provided in an object-oriented system
using inheritance from super-classes, the cohesion of the
object which inherits attributes and operations is reduced.
It is no longer possible to consider that object as a
separate unit. All super-classes also have to be inspected if
the object’s functionality is to be understood completely.
System browsers which display object classes and their super-
classes asist with this process but understanding a component
which inherits attributes from a number of super-classes can
be particularly complex.
-15-
Coupling
Coupling is related to cohesion. It is an indication of the
strength of interconnections between program units. Highly
coupled systems have strong interconnections, with program
units dependent on each other. Loosely coupled systems are
made up of units which are independent or almost independent.
As a general rule, modules are tightly coupled if they
make use of shared variables or if they interchange control
information. This is known as common coupling and control
coupling. Loose coupling is achieved by ensuring that, wherever
possible, representation information is held within a component and that
its data interface with other units is via its parameter list.
Other coupling problem arise when names are bound to
values at an early stage in the developent of the design. For
example, if a program is concerned with tax computations and
a tax rate of 30% is encoded as a number in the program, that
program is coupled with the tax rate. Changes to the tax rate
require changes to the program. If the program reads in the
tax rate at run-time, it is easy to accommodate rate changes.
Perhaps the principal advantage of object-oriented design
is that the nature of objects leads to the creation of
loosely coupled system. It is fundamental to object-oriented
design that the representation of an object is concealed
within that object and is not visible to external components.
The system does not have a shared state and any object can be
-16-
replaced by another object with the same interface.
Inheritance in object-oriented systems, however, leads to
a different from of coupling. Objects which inherit
attributes and operations are coupled to their super-classes.
Changes to the super-class must be made carefully as these
changes propagate to all of the classes which inherit their
characteristics.
Understandability
Changing a design component implies that the person
responsible for making the change understands the operation
of the component. This understandability is related to a
number of component characteristics:
(1) Cohesion Can the component be understood without
reference to other components?
(2) Naming Are the names used in the component meaningful?
Meaningful names are names which reflect the names of the
realworld entities being modelled by the component.
(3) Documentation Is the component documented so that the
mapping between the real-world entities and the compnent
is clear? Is the rationale for that mapping documented?
(4) Complexity How complex are the algorithms used to
implement the component?
High complexity implies many relationship between different parts
of the design component and a complex logical structure which
may involve deeply nested if-then-else statements. Complex
components are hard to understand so the designer should
strive for as simple as possible a component design.
Complexity affects understandability but
-17-
there are a number of other factors which influence the
understandability, such as the data organization and the
style in which the design is described. Complexity measures
can only provide an indicator to the understandability of a
component.
Inheritance in an obect-oriented design affects its
understandability. If inheritance is used to conceal design
details, the design is easier to understand. If one the other
hand, the use of inheritance requires the design reader to
look at many different object classes in the inheritance
hierachy, the understandability of the design is reduced.
Adaptability
If a design is to be maintained, it must be readily
adaptable. Of course, this implies that its components should
be cloosely coupled. As well as this, however, adaptability
means that the design should be well-documented, the
component documentation should be readily understandable and
consistent with the implementation, and that the
implementation should be written in a readable way.
An adaptable design should have a high level of
visibility. There should be a clear relationship between the
different level in the design. It should be possible for a
reader of the design to find related representations such as
the structure chart representing a transformation on a data
flow diagram.
It should be easy to incorporate changes made to the
design in all design documents. If this is not the case,
changes made to a design description may not be included in
-18-
all related descriptions. The design documentation may become
inconsistent. Later changes are more difficult to make (the
component is less adaptable) because the modifier cannot rely
on the consistency of design documentation.
For optimum adaptability, a component should be self-
contained. A component may be loosely coupled in that it only
cooperates with other components via message passing. This is
not the same as being self-contained as the component may
rely on other components, such as systems functions or error
handling functions. Adaptations to the component may involve
changing parts of the component which rely on external
functions so the modifier must also consider the specification of these
external functions.
To be completely self-contained, a component should not
use other components which are externally defined. However,
this is contrary to good practice which suggests that existing
components should be reused. Thus, some balance must be
struck between the advantages of reusing components and the
loss of component adaptability that this entails.
One of the principlal advantages of inheritance in
object-oriented systems is that components may be readily
adapated. The adaptation mechanism does not rely on modifying
the component but on creating a new component which inherits
the attributes and operations of the original component. Only
those atttributes and operations which need ;be ;changed are
modified. Components which rely on the base component are
;not affected by the changes made.
This simple adaptability is one readson why object-
oriented languages are so effective for rapid prototyping.
However, for long lifetime systems, the problem with
inheritance is that as more and more change are made, the
-19-
inheritance network becomes increasingly complex.
Functionality is often replicated at different points in the
network and components are harder to understand. Experience
of object-oriented programming has shown that the inheritance
network must be periodically reviewed and restructured to
reduce its complexity and functional duplication. Clearly,
this adds to the costs of system change.
KEY POINTS
? Design is a creative process. Although methods and
guidlines are helpful, judgement and flair on the part of
the software engineer are still required to design a
software system.
? The main design activities in the software process are
architectural design, system specification, interface
design, component design, data structure design and
algorithm desing.
? Functional decomposition involves considering system as a
set of interacting functional units.
? Object-oriented decomposition consider the system as a
set of objects where an object is an entity with state
and functions to inspect and modify that state.
? A decision on whether a system should be implemented as a
single sequential process or as a number of parallel
proceses is a detailed design decision. The design
process should partition the system into logical,
intercating units which may be realized as either
sequential or parallel components.
-20-
? The most important design quality attribute is
maintainability. Maximizing cohesion in a component and
minimizing the coupling between components is likely
to lead to a maintainable design.
? The use of inheritance in obect-oriented systems can
improve the quality of a design but may make the design
more difficult to understand.
Object-Oriented Design
Object-Oriented Design strategy maximize information hiding
and usually leads the systems with lower coupling and higher
cohesion than the functional approach. Information hiding is a design
strategy where as much information as possible is hidden within design
components.
The basic premise underlying information hiding is the notion
that the binding of logical control and data structures to
their implementation should be made as late as possible in
the design process. Communication through shared state
information (global variables) is minimized, thus increasing
the understandability of the design. The design is relatively
easy to change as changes to a component should not have
unforeseen side-effects on other components.
Object-oriented design is based on information hiding.
It differs from the functional approach to design in that it
views a software system as a set of interacting objects, with
their won private state, rater than as a set of function.
-21-
An object-oriented design is based on entities (object)
which have a hidden state and operations on that state. The
design is expressed in terms of services requested and
provided by interacting objects.
The characteristics of an object-oriented design are:
- Shared data areas are eliminated. Object communicate by
exchanging message rather than sharing variables. This
reduces overall system coupling as there is no
possibility of unexpected modifications to shared
information.
- Object are independent entities that may readily be
changed ;because all state and representation
information is held within the object itself. No
access and hence no deliberate or accidental use of
this information by other objects is possible. Changes
to the representation may be made without reference to
other system object.
- Object may be distributed and may execute either
sequentially or in parallel. Decisions on parallelism
need not be taken to an early stage of the design
process.