Software design is both a process and a model. The
design process is a sequence of steps that enable the designer to describe all
aspects of the software to be built. It is important to note, however, that the
design process is not simply a cookbook. Creative skill, past experience, a
sense of what makes ―good‖ software, and an overall commitment to quality are
critical success factors for a competent design. The design model is the
equivalent of an architect‘s plans for a house. It begins by representing the
totality of the thing to be built (e.g., a three-dimensional rendering of the
house) and slowly refines the thing to provide guidance for constructing each
detail (e.g., the plumbing layout). Similarly, the design model that is created
for software provides a variety of different views of the computer software.
Basic design principles enable the software engineer to navigate the design
process. Davis [DAV95] suggests a set of principles for software design, which
have been adapted and extended in the following list:
design process should not suffer from “tunnel vision.” A good
designer should consider alternative
approaches, judging each based on the requirements of the problem, the
resources available to do the job.
design should be traceable to the analysis model. Because a
single element of the design model
often traces to multiple requirements, it is necessary to have a means for
tracking how requirements have been satisfied by the design model.
design should not reinvent the wheel. Systems are constructed using a
set of design patterns, many of
which have likely been encountered before. These patterns should always be
chosen as an alternative to reinvention. Time is short and resources are
limited! Design time should be invested in representing truly new ideas and
integrating those patterns that already exist.
design should “minimize the intellectual distance” between the software and the
problem as it exists in the real world. That is, the structure of the
software design should (whenever
possible) mimic the structure of the problem domain.
design should exhibit uniformity and integration. A design
is uniform if it appears that one
person developed the entire thing. Rules of style and format should be defined
for a design team before design work begins. A design is integrated if care is
taken in defining interfaces between design components.
design should be structured to accommodate change. The
design concepts discussed in the
next section enable a design to achieve this principle.
design should be structured to degrade gently, even when aberrant data, events,
or operating conditions are encountered. Well- designed software should never ―bomb.‖ It should be designed to accommodate unusual circumstances, and if it
must terminate processing, do so in a graceful manner.
not coding, coding is not design. Even when detailed procedural
designs are created for program
components, the level of abstraction of the design model is higher than source code. The only design decisions made at the coding level address the
small implementation details that enable the procedural design to be coded.
design should be assessed for quality as it is being created, not after the
fact. A variety of design concepts
and design measures are available to assist the designer in assessing quality.
design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus on
minutiae when the design is reviewed, missing the forest for the trees. A design
team should ensure that major conceptual elements of the design (omissions,
ambiguity, inconsistency) have been addressed before worrying about the syntax
of the design model.