Objectives
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:
·
The
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.
·
The
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.
·
The
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.
·
The
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.
·
The
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.
·
The
design should be structured to accommodate change. The
design concepts discussed in the
next section enable a design to achieve this principle.
·
The
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.
·
Design is
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.
·
The
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.
·
The
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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.