Information Technology Reference
In-Depth Information
encapsulates attributes and program code to behave in a certain manner.
Modularity is a degree to which modules are standardized and independent, and
show variety in use. If any systems design is composed of n modules, the
connections between modules should be maximum n (n - 1) because too many
connections lead to error. Controlling the amount and form of communication
between modules is the essence of modularity, and the key objective of modularity
is autonomous, stand-alone modules. But object-oriented proponents argue that a
structure-oriented approach cannot build designs that are highly independent, or
very loosely tied to other modules.
7.5.2 Top-Down Versus Bottom-Up Design
In the top-down model an overview of the system is formulated without going into
detail for any part of it. Each part of the system is then refined by designing it in
further detail. Each new part may then be refined again, defining it in yet more
detail until the entire specification is detailed enough to validate the model from
the highest-level specification describing the project as a whole, or the application
logic, downwards to individual operations. By contrast in bottom-up design,
individual parts of the system are specified in detail. The parts are then linked
together to form larger components, which are in turn linked until a complete
system is formed. Working up from the specific operations in the problem domain
that you know you will need to perform is a main concept in the bottom-up design.
A designer working from the top down will start by thinking about the program's
main event loop, and plug in specific events later. A designer working from the
bottom up will start by thinking about encapsulating specific tasks and glue them
together into some kind of coherent order later on. The end of the stack you start
with matters a lot because the layer at the other end is quite likely to be constrained
by your initial choices. In particular, if you program purely from the top down, you
may find yourself in the uncomfortable position where the domain primitives your
application logic and your wants don't match the ones you can actually implement.
On the other hand, if you program purely from the bottom up, you may find
yourself doing a lot of work that is irrelevant to the application logic—or merely
designing a pile of bricks when you were trying to build a house. Figure
7.3
shows
an example of the top down approach.
7.5.3 Reusability
The big promise of the object-oriented design approach is reusability. Designers
aim at creating libraries so that systems professionals can look through object class
catalogs to select the appropriate object class and reuse it. In structured design,
SCLC goes through all the phases from user requirements to systems design, to
