Programming and Problem Solving with Java

6.5 Functional Decomposition | 287

ments; they are concrete steps.Those shown in colored type are abstract steps; they
reappear as subproblems in the next level down. Each box in the figure repre-
sents a module. Modules are the basic building blocks in a functional decompo-
sition. The diagram in Figure 6.7 is, therefore, also called a module structure chart.

Writing Modules

Here’s one approach to writing modules:

1.Think about how you would solve the subproblem by hand.

2.Begin writing down the major steps.

3.If a step is simple enough that you can see how to implement it

directly in Java, it is at the concrete level; it doesn’t need any further re-

finement.

4.If you have to think about implementing a step as a series of smaller steps or as

several Java statements, it is still at an abstract level.

5.If you are trying to write a series of steps and start to feel overwhelmed by

details, you are probably bypassing one or more levels of abstraction. Stand back

and look for pieces that you can write as more abstract steps.

We could call this approach the “procrastinator’s technique.” If a step is cumbersome or
difficult, put it off to a lower level; don’t think about it today, think about it tomorrow. Of
course, tomorrow does come eventually, but the whole process can be applied again to the
subproblem. A trouble spot often seems much simpler when you can focus on it. Ultimately,
the entire problem is broken up into manageable units.
As you work your way down the solution tree, you inevitably make a series of design de-
cisions. If a decision proves awkward or wrong (and many times it does!), you can backtrack
(go back up the tree to a higher-level module) and try something else. You don’t have to scrap
the entire design—only the small part you are working on. You may make many intermedi-
ate steps and try many trial solutions before you reach a final design.
Before OOD was developed, functional decomposition was used to solve entire prob-
lems. However, by itself, it results in designs that lack flexibility. Applications developed en-
tirely this way are hierarchical in nature, and often we find that at the bottom of the
hierarchy we are implementing multiple versions of the same responsibility. With OOD, we
would define a superclass and a set of subclasses to organize these responsibilities and save
ourselves programming effort. But functional decomposition doesn’t allow for this kind of
organization.
Today, we typically use functional decomposition as a way to design the algorithm for
a complex responsibility. For example, in a class that supports image processing, a morph-
ing responsibility that distorts part of an image might have no need of any other collabora-
tion. Yet the algorithm that transforms the image data may include many mathematically

Concrete step A step for

which the implementation de-

tails are fully specified

Abstract step A step for which

some implementation details

remain unspecified

Module A self-contained col-

lection of steps that solves a

problem or subproblem; it can

contain both concrete and ab-

stract steps