Schaum's Outline Series

128
EXAMPLE 9.1
A robot is required to find specific brands of pop cans using a black-and-white
camera and to return the cans to a recycling location. Such a statement can be the
user-oriented requirements and consists of a phenomenon from the environment.
However, the pop cans are hidden phenomenon in the environment. That is, the
implementation will not know about pop cans; it will know about black-and-white
images of pop cans. This is the visible phenomenon. When the specification that
will be used as the starting point for design is written, it needs to talk in terms of
these images. It will be assumed (and may need to be verified) that only real pop
cans will give those images. For example, the problem will be much more difficult if
the walls of the environment are covered with ads that contain images of pop cans.
EXAMPLE 9.2
Identify which phenomenon is in the environment and which is in the
implementation in the library system.
The physical book is an environment-hidden phenomenon. The system never
knows about the book. When the librarian scans the book, he or she is really
scanning a bar code. This bar code is not the ISBN but has to reflect possible
multiple copies of a single book. This bar code is environment-visible. The
implementation probably uses a different identifier or pointer for the book data. This
internal identifier is implementation-hidden.
The specification for development needs to be written in terms of the bar code
on the book. Neither the physical book nor the internal identifier should be
mentioned in the development specification.
9.2 Phases of the DesignProcess
The following are phases in design:
TEAMFLY
CHAPTER 9 Software Design
Data design—This phase produces the data structures.
Architectural design—This phase produces the structural units (classes).
Interface design—This phase specifies the interfaces between the units.
Procedural design—This phase specifies the algorithms of each method.
EXAMPLE 9.3
Design the library classes/data structures from the data items in the object model
shown in Fig. 9-1 for the library problem (see Examples 8.1 and 2.6).
The data design and the architectural phases have been combined in this
example. The concentration in this example is on the loan and checkout
functionality, with little regard for the other necessary tasks, such as administration,
cataloging, assigning overdue fines, retiring books, and patron maintenance.
The domain entity ‘‘book’’ is probably not going to continue into the design. It will
be combined with ‘‘copy’’ into a class/data structure that stores all the information
about a copy. It will probably use the ISBN and a copy number as the unique
identifier. The patron information will be stored in a second data structure. Each
record is probably identified by an unique patron ID number. The loan information
may or may not be a separate data structure. If borrowing information needs to be
saved beyond the return of the book, then it had better be a separate class/data