ESE Module 3-4
Design Principles
If you want to start a debate, just ask the question,
`What makes a good piece of software?" A harried
manager might argue that software that is on time is
`good." A programmer who spends all his time writing
code would probably talk about the attributes of the
programming language used for implementation. But
what about a software engineer. How would she
answer this question?
To formulate a reasonable answer, it's necessary
to understand "goodness." In the software engineering context, a `good piece of software" exhibits good
quality characteristics. (See ESE Module 7-1 for a
detailed discussion of software quality.) But how do
we achieve high-quality software? The answer lies in
design.
Software design lies at the core of the software
engineering process, and yet, many software developers don't know much about it. To understand
design, you'll have to understand two things: (l) the
basic design principles that lead to high-quality
(good) software, and (2) the design methods that
enable you to implement these principles.
In this ESE module, we'll discuss basic design principles that address topics that every software engineer should understand and apply.
Design
There is something ironic about software design.
Everyone realizes that a well-designed computer program will exhibit all the characteristics of high quality:
it will conform to customer requirements; it will be correct and reliable; it will be relatively easy to change; it
will be modularized in a way that leads to reuse. Most
software professionals recognize these facts, not by
examining well-designed programs but rather by seeing the sometimes disastrous results of poorly designed
ones. Yet, most software professionals do relatively little explicit design: and when they do it, they often
focus on one element of design to the exclusion of
other, possibly more important, design activities.
Readings
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and
presents a discussion of the design process and its
relationship to software quality.
Design is the first step in the development phase for any
engineered product or system. It may be defined as: "...the
process of applying various techniques and principles for
the purpose of defining a device, a process or a system in
sufficient detail to permit its physical realization." [1]
The designer's goal is to produce a model or represen-
tation of an entity that will later be built. The process by
which the model is developed combines: intuition and
judgment based on experience in building similar entities;
a set of principles and/or heuristics that guides the way in
which the model evolves; a set of criteria that enables quality to be judged, and a process of iteration that ultimately
leads to a final design representation.
Computer software design, like engineering design
approaches in other disciplines, changes continually as
new methods, better analysis and broader understanding
evolve. Unlike mechanical or electronic design, software
design is at a relatively early stage in its evolution. We
have given serious thought to software design (as opposed
to programming or writing code) for little more than two
decades. Therefore, software design methodology lacks
the depth, flexibility and quantitative nature that is normally associated with more classical engineering desi~
disciplines. However, techniques for software design do
exist; criteria for design quality are available, and design
notation can be applied.
Software Design and Software Engineering
Software design sits at the technical kernel of the software
engineering process and is applied regardless of the development paradigm that is used. Beginning after software
requirements have been analyzed and specified, software
design is the first of three technical activities-design, code
and test-that are required to build and verify the software.
Each activity transforms information in a manner that ultimately results in validated computer software.
The flow of information during this technical phase of
the software engineering process begins with software
requirements, manifested by information [the data model],
and is followed by the functional and behavioral models.
Using one of a number of design methods, the design step
produces a data design, an architectural design and a procedural design. The data design? transforms the information
domain model created during analysis into the data structures that will be required to implement the software. The
architecturaI design defines the relationship among major
structural elements of the program. The procedural design
transforms structural elements into a procedural description of the software. Source code is generated, and testing
is conducted to integrate and validate the software.
Design, code and test absorb 75 percent or more of the
cost of software engineering (excluding maintenance). It is
here that we make decisions that will ultimately affect the
success of software implementation, and as important, the
ease with which software will be maintained. These decisions are made during software design, making it the pivotal step in the development phase. But why is design so
important?
The importance of software design can be stated with
a single word--quality. Design is the place where quality is
fostered in software development. Design provides us with
representations of software that can be assessed for quality.
3-4.2 ·· Essential Software Engineering
Design is the only way that we can accurately translate a
customer's requirements into a finished software product
or system. Software design serves as the foundation for all
software engineering and software maintenance steps that
follow. Without design, we risk building an unstable system-one that will fail when small changes are made; one
that may be difficult to test; one whose quality cannot be
assessed until late in the software engineering process,
when time is short and many dollars have already been
spent.
encourages good design through the application of fundamental design principles, systematic methodology and
thorough review.
The Design Process
Just what is well-designed software? It's often said that
software developers know the consequences of welldesigned software when they see them, but they
don't understand how to achieve well-designed software in the first place. This is probably unfair but certainly true in some instances.
Software design is a process through which requirements
are translated into a representation of software. Initially
the representation depicts a holistic view of software.
Subsequent refinement leads to a design representation
that is very close to source code.
From a project management point of view, software
design is conducted in two steps. Preliminary design is
concerned with the transformation of requirements into
data and software architecture. Detail design focuses on
refinements to the architectural representation that lead to
detailed data structure and algorithmic representations for
software.
Within the context of preliminary and detail design, a
number of different design activities occur. In addition to
data, architectural and procedural design, many modern
applications have a distinct interface design activity.
Interface design establishes the layout and interaction
mechanisms for human-machine interaction.
Design and Software Quality
Throughout the design process, the quality of the evolving
design is assessed with a series of formaI technical reviews or
design walk throughs. [See ESE Module 7-3] To evaluate the
quality of a design representation, we must establish criteria for good design. Later, we discuss design quality criteria in some detail. For the time being, we present the following guidelines:
1. A design should exhibit a hierarchical organization
that makes intelligent use of control among elements of
software.
2. A design should be modular; that is, the software
should be logically partitioned into elements that perform
specific functions and subfunctions.
3. A design should contain distinct and separable representation of data and procedure.
4. A design should lead to modules (e.g., subroutines or
procedures) that exhibit independent functional characteristics.
5. A design should lead to interfaces that reduce the
complexity of connections between modules and with the
external environment.
6. A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis.
The above characteristics of a good design are not achieved
by chance. The software engineering design process
[1] Taylor, E.S., An Interim Report on Design, MIT, 1959.
Exercise 3-11.
Software Design
1. To explore this seeming anomaly make a list of at
least eight consequences of well-designed software.
That is, what are the beneficial results of a well
designed program?
2. Now, for the more difficult question. Make a list of
the technical characteristics that result in welldesigned software. In other words, if someone placed
a source listing, program documentation, and user
manual on your desk how would you assess whether
the program was well designed?
Design Fundamentals
When you look at a beautiful building or a sleek sports
car you are looking at the aesthetic element of
design. Someone has spent the time to represent form
in a way that is pleasing to the eye. But design is far
more than aesthetics. The building must have an
effective floor plan, good lighting, good elevators
and adequate communication and utilities services.
The sports car must have a powerful yet efficient
engine, a highly tuned suspension, tight steering, and
all the other attributes that make a good high-performance automobile. To be a truly great design, the
building and the sports car must have beauty of form
and beauty of function. Design is involved in both.
You probably had no trouble visualizing a beautiful building or a beautiful automobile. But what jumps
into your mind when we introduce the phrase "beautiful software". It's interesting that we rarely, if ever, use
the adjective "beautiful" when discussing computer
programs. It may be that the adjective is reserved for
Design Principles ·· 3-4.3
those things that have a definite physical manifestation. But it may have more to do with the fact that few
people understand the characteristics that result in
well-designed (beautiful) software.
Readings
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and
presents a detailed discussion of basic design principles.
A set of fundamental software design concepts has evolved
over the past three decades. Although the degree of interest in each concept has varied over the years, each has
stood the test of time. Each provides the software designer
with a foundation from which more sophisticated design
methods can be applied. Each helps the software engineer
to answer the following questions:
 What criteria can be used to partition software into
individual components?
 How is function or data structure detail separated
from a conceptual representation of the software?
 Are there uniform criteria that define the technical
quality of a software design?
M. A. Jackson once said: "The beginning of wisdom for
a computer programmer [software engineer] is to recognize the difference between getting a program to work, and
getting it right." [1] Fundamental software design concepts
provide the necessary framework for "getting it right."
tion is reached when source code is generated.
As we move through different levels of abstraction, we
work to create procedural and data abstractions. A proceduraI abstraction is a named sequence of instructions that
has a specific and limited function. An example of a procedural abstraction would be the word "enter" on a door.
"Enter" implies a long sequence of procedural steps (e.g.,
walk to the door; reach out and grasp knob; turn knob and
pull/push door; step away from opening door, etc.). A
data abstraction is a named collection of data that describe
a data object. An example of a data abstraction would be
"paycheck." This data object is actually a collection of many
different pieces of information (e.g., payee name, gross pay
amount, tax withheld, FICA, pension fund contribution,
etc.). Yet, we can refer to all the data by stating the name of
the data abstraction.
To illustrate software defined by three different levels
of procedural abstraction, we consider the following problem: Develop software that will perform all functions associated with a two dimensional drafting system for lowlevel computer-aided design applications.
Abstraction I. The software will incorporate a computer
graphics interface that will enable visual communication
with the draftsperson and a mouse that replaces the drafting board and T-square. All line and curve drawing, all
geometric computations, all sectioning and auxiliary views
will be performed by the CAD software. ... Drawings will
be stored in a drawing file that will contain all geometric,
text and supplementary design information.
At this level of abstraction, the solution is stated in
terms of the problem environment.
Abstraction
When we consider a modular solution to any problem,
many levels of abstraction can be posed. At the highest level
of abstraction, a solution is stated in broad terms using the
language of the problem environment. At lower levels of
abstraction, a more procedural orientation is taken.
Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution.
Finally, at the lowest level of abstraction, the solution is
stated in a manner that can be directly implemented.
Wasserman [2] provides a useful definition:
... the psychological notion of "abstraction" permits one to
concentrate on a problem at some level of generalization,
without regard to irrelevant low-level details; use of
abstraction also permits one to work with concepts and
terms that are familiar in the problem environment without
having to transform them to an unfamiliar structure....
Each step in the software engineering process is a
refinement in the level of abstraction of the software solution. During system engineering, software is allocated as
an element of a computer-based system. During software
requirements analysis, the software solution is stated in
terms "that are familiar in the problem environment." As
we move from preliminary to detail design, the level of
abstraction is reduced. Finally, the lowest level of abstrac-
Abstraction II.
CAD software tasks:
user interaction task;
2-D drawing creation task;
graphics display task;
drawing file management task;
end.
At this level of abstraction, each of the major software tasks
associated with the CAD software is noted. Terms have
moved away from the problem environment but are still
not implementation specific.
Abstraction III.
procedure: 2-D drawing creation;
repeat until <drawing creation task terminates>
do while <digitizer interaction occurs>
digitizer interface task;
determine drawing request case;
line: line drawing task;
circle: circle drawing task;
.
.
end;
3-4.4 ·· Essential Software Engineering
do while <keyboard interaction occurs>
keyboard interaction task;
process analysis/computation case;
view: auxiliary view task;
section: cross sectioning task;
.
.
.
end;
.
.
.
end repetition;
end procedure.
ally), each of these procedures can be specified without the
need to define details of drawing every time the procedure
is invoked.
Control abstraction is the third form of abstraction used
in software design. Like procedural and data abstraction,
control abstraction implies a program control mechanism
without specifying internal details. An example of a control
abstraction is the synchronization semaphore used to coordinate activities in an operating system.
Refinement
Stepwise refinement is an early top-down design strategy
proposed by Niklaus Wirth [3]. The architecture of a program is developed by successively refining levels of proceAt this level of abstraction, a preliminary procedural
dural detail. A hierarchy is developed by decomposing a
representation exists. Terminology is now software-orient- macroscopic statement of function (a procedural abstraced (e.g., the use of constructs such as do while) and an
tion) in a stepwise fashion until programming language
implication of modularity begins to surface.
statements are reached. An overview of the concept is proThe concepts of stepwise refinement and modularity are vided by Wirth [3]:
closely aligned with abstraction. As the software design
evolves, each level of modules in program structure repreIn each step (of the refinement), one or several
sents a refinement in the level of abstraction of the softinstructions of the given program are decomposed into
ware.
more detailed instructions. This successive decomposition
Data abstraction, like procedural abstraction, enables a or refinement of specifications terminates when all instrucdesigner to represent a data object at varying levels of
tions are expressed in terms of any underlying computer or
detail and, more importantly, specify a data object in the
programming language ... As tasks are refined, so the
context of those operations (procedures) that can be
data may have to be refined, decomposed, or structured,
applied to it. Continuing the CAD software example above, and it is natural to refine the program and the data specifiwe could define a data object called drawing. The data
cations in parallel.
object drawing connotes certain information with no furEvery refinement step implies some design decisions.
ther expansion, when it is considered in the context of the
It is important that ... the programmer be aware of the
drafting system. The designer, however, might specify
underlying criteria (for design decisions) and of the exisdrawing as an abstract data type. That is, the internal details tence of alternative solutions ...
of drawing are defined:
The process of program refinement proposed by Wirth is
TYPE drawing IS STRUCTURE DEFINED
analogous to the process of refinement and partitioning
number IS STRING LENGTH (12);
that is used during requirements analysis. The difference is
geometry DEFINED ...
in the level of detail that is considered, not the approach.
notes IS STRING LENGTH (256)
Refinement is actually a process of elaboration. We
BOM DEFINED ...
begin with a statement of function (or description of inferEND drawing TYPE;
mation) that is defined at a high level of abstraction. That
is, the statement describes function or information concepIn the design language description above, drawing is
tually but provides no information about the internal
defined in terms of it constituent parts. In this case, the
workings of the function or the internal structure of the
data abstraction drawing is itself comprised of other data
information. Refinement causes the designer to elaborate
abstractions: geometry and BOM (bill of materials).
on the original statement, providing more and more detail
Once the type drawing (an abstract data type) has
as each successive refinement (elaboration) occurs.
been defined, we can use it to describe other data objects,
without reference to the internal details of drawing. For
Modularity
example, at another location in the data design, we might
The concept of modularity in computer software has been
say:
espoused for almost four decades. Software architecture
blue-print IS INSTANCE OF drawing:
embodies modularity; that is, software is divided into sepaor
rately named and addressable components, called modschematic IS INSTANCE OF drawing;
ules, that are integrated to satisfy problem requirements.
It has been stated that "modularity is the single
implying that blueprint and schematic take on all characattribute of software that allows a program to be intellectuteristics of drawing as defined above.
ally manageable" [4]. Monolithic software (i.e., a large proOnce a data abstraction is defined, a set of operations
gram comprising a single module) cannot be easily grasped
that may be applied to it is also defined. For example, we
by a reader. The number of control paths, span of refermight identify operations such as erase, save, catalog and
ence, number of variables and overall complexity would
copy for the abstract data type drawing. By definition (liter-
Design Principles 3-4.5
make understanding close to impossible.
It is important to note that a system may be designed
modularly, even if its implementation must be monolithic.
There are situations (e.g., real-time software, microprocessor software) in which relatively minimal speed and mem
ory overhead introduced by subprograms (i.e., subroutines, procedures) is unacceptable. In such situations software can and should be designed with modularity as an
overriding philosophy. Code may be developed in-line.
Although the program source code may not look modular
at first glance, the philosophy has been maintained, and the
program will provide the benefits of a modular system.
Software Architecture
Software architecture alludes to two important characteristics of a computer program: (1) the hierarchical structure of
procedural components (modules) and (2) the structure of
data. Software architecture is derived through a partitioning process that relates elements of a software solution to
parts of a real world problem implicitly defined during
requirements analysis. The evolution of software and data
structure begins with a problem definition. Solution occurs
when each part of the problem is solved by one or more
software elements.
Control Hierarchy
Control hierarchy, also called program structure, represents
the organization (often hierarchical) of program components (modules) and implies a hierarchy of control. It does
not represent procedural aspects of software such as
sequence of processes, occurrence/order of decisions or
repetition of operations.
Many different notations are used to represent control
hierarchy. The most common is the tree-like diagram
shown in Figure 1. In order to facilitate later discussions of
structure, we define a few simple measures and terms.
Referring to Figure 1, depth and width provide an indication of the number of levels of control and overall span of
control, respectively. Fan-out is a measure of the number
of modules that are directly controlled by another module.
Fan-in indicates how many modules directly control a
given module.
The control relationship among modules is expressed
in the following way: a module that controls another module is said to be superordinate to it, and conversely, a module controlled by another is said to be subordinate to the
controller. For example, referring to Figure 1, module M is
superordinate to modules a, b and c. Module h is subordinate to module e and is ultimately subordinate to module
M. Width-oriented relationships (e.g., between modules d
and e) although possible to express in practice, need not be
defined with explicit terminology.
The control hierarchy also represents two subtly different characteristics of the software architecture: visibility
and connectivity. Visibility indicates the set of program
components that may be invoked or used as data by a
given component, even when this is accomplished indirectly. For example, a module in an object-oriented system
may have access to a wide array of data objects that it has
inherited, but may only make use of a small number of
these data objects. All of the objects are visible to the module. Connectivity indicates the set of components that are
directly invoked or used as data by a given component. For
example, a module that directly causes another module to
begin execution is connected to it.
[In ESE Component 5, we explore the concept of inheritance for object-oriented software. A program component
can inherit control logic and/or data from another component without explicit reference in the source code.
Components of this sort would be visible, but not directly
connected. A structure chart (ESE Module 3-5) indicates
connectivity.]
Data Structure
Data structure is a representation of the logical relationship
among individual elements of data. Because the structure
of information will invariably affect the final procedural
design, data structure is as important as program structure
to the representation of software architecture.
Data structure dictates the organization, methods of
access, degree of associativity and processing alternatives
for information.
The organization and complexity of a data structure
are limited only by the ingenuity of the designer. There
are, however, a limited number of classic data structures
that form the building blocks for more sophisticated
structures.
Software Procedure
Program structure defines control hierarchy without
regard to the sequence of processing and decisions.
Software procedure focuses on the processing details of
each module individually. Procedure must provide a
precise specification of processing, including sequence of
events, exact decision points, repetitive operations and
even data organization/structure.
There is, of course, a relationship between structure
and procedure. Processing indicated for each module
must include a reference to ail modules subordinate to
the module being described. That is, a procedural representation of software is layered.
3-4.6 ·· Essential Software Engineering
Information Hiding
Cohesion
The concept of modularity leads every software designer to
a fundamental question: "How do we decompose a software solution to obtain the best set of modules?" The principle of information hiding [5] suggests that modules be
"characterized by design decisions that (each) hides from
all others." In other words, modules should be specified
and designed so that information (procedure and data)
contained within a module are inaccessible to other modules that have no need for such information.
Hiding implies that effective modularity can be
achieved by defining a set of independent modules that
communicate with one another only that information necessary to achieve software function. Abstraction helps to
define the procedural (or informational) entities that comprise the software. Hiding defines and enforces access constraints to both procedural detail within a module, and any
local data structure used by the module.
The use of information hiding as a design criteria for
modular systems provides greatest benefits when modifications are required during testing and later, during software maintenance. Because most data and procedure are
hidden from other parts of the software, inadvertent errors
introduced during modification are less likely to propagate
to other locations within the software.
Cohesion is a natural extension of the information hiding
concept. A cohesive module performs a single task within a
software procedure, requiring little interaction with procedures being performed in other parts of a program. Stated
simply, a cohesive module should (ideally) do just one
thing.
A module that performs a set of tasks that relate to
each other loosely, if at all, is termed coincidentally cohesive. A module that performs tasks that are related logically (e.g., a module that produces all output regardless of
type) is logically cohesive. When a module contains tasks
that are related by the fact that all must be executed with
the same span of time, the module exhibits temporal cohesion.
As an example of low cohesion, consider a module
that performs error processing for an engineering analysis
package. The module is called when computed data exceed
prespecified bounds. It perform the following tasks: (1)
computes supplementary data based on original computed
data; (2) produces an error report (with graphical content)
on the user's workstation; (3) performs follow-up calculations requested by the user; (4) updates a database; (5)
enables menu selection for subsequent processing.
Although the preceding tasks are loosely related, each is an
independent functional entity that might best be performed
as a separate module. Combining the functions into a single module can only serve to increase the likelihood of
error propagation when a modification is made to one of
the processing tasks noted above.
Moderate levels of cohesion are relatively close to one
another in the degree of module independence. When processing elements of a module are related and must be executed in a specific order, procedural cohesion exists. When
all processing elements concentrate on one area of a data
structure, communicational cohesion is present. High
cohesion is characterized by a module that performs one
distinct procedural task.
The following excerpt from Stevens et al [6] provides a
set of simple guidelines for establishing the degree of cohesion (called 'binding' in this reference):
Effective Modular Design
The design fundamentals described in the preceding section all serve to precipitate modular designs. In fact, modularity has become an accepted approach in all engineering
disciplines. A modular design reduces complexity; facilitates change (a critical aspect of software maintainability),
and results in easier implementation by encouraging parallel development of different parts of a system.
Functional Independence
The concept of functional independence is a direct outgrowth of modularity and the concepts of abstraction and
information hiding. Functional independence is achieved
by developing modules with single-minded function and
an aversion to excessive interaction with other modules.
Stated another way, we want to design software so that
each module addresses a specific subfunction of requirements and has a simple interface when viewed from other
parts of the program structure. It is fair to ask why independence is important. Software with effective modularity, i.e., independent modules, is easier to develop because
function may be compartmentalized and interfaces are simplified. (Consider ramifications when development is conducted by a team.) Independent modules are easier to
maintain (and test) because: secondary effects caused by
design/code modification are limited; error propagation is
reduced; reusable modules are possible. To summarize,
functional independence is a key to good design, and
design is the key to software quality.
Independence is measured using two qualitative criteria: cohesion and coupling. Cohesion is a measure of the
relative functional strength of a module. Coupling is a
measure of the relative interdependence among modules.
A useful technique in determining whether a module is
functionally bound is writing a sentence describing the
function (purpose) of the module, and then examining the
sentence. The following tests can be made:
1. If the sentence has to be a compound sentence, contains
a comma, or contains more than one verb, the module is
probably performing more than one function; therefore, it
probably has sequential or communicational binding.
2. If the sentence contains words relating to time, such as
"first", "next", "then", "after", "when", "start", etc., then the
module probably has sequential or temporal binding.
3. If the predicate of the sentence doesn't contain a single
specific object following the verb, the module is probably
logically bound. For example, Edit All Data has logical
binding: Edit Source Statement has functional binding.
4. Words such as "initialize", "clean-up", etc., imply temporal binding.
Design Principles ·· 3-4.7
Functionally bound modules can always be described by
way of their elements using a compound sentence. But if
the above language is unavoidable while still completely
describing the module's function, then the module is probably not functionally bound.
[1] Jackson, M.A., Principles of Program Design, Academic
Press, 1975.
[2] Wasserman, A., "Information Systems Design
Methodology," in Software Design Techniques, 4th edition,
IEEE Computer Society Press, 1983, p. 43.
As we have already noted, it is unnecessary to determine the precise level of cohesion. Rather it is important to
strive for high cohesion and recognize low cohesion, so
that software design can be modified to achieve greater
functional independence.
[3] Wirth, N. "Program Development by Stepwise
Refinement," CACM, vol. 14, no. 4, 1971, pp. 221-227.
Coupling
[5] Parnas,D., "On the Criteria to be Used in
Decomposing Systems into Modules," CACM, vol. 14, no.l,
April, 1972, pp. 221-227.
Coupling is a measure of interconnection among modules
in a software structure. Coupling depends on the interface
complexity between modules, the point at which entry or
reference is made to a module, and what data passes across
the interface.
In software design, we strive for lowest possible coupling. Simple connectivity among modules results in software that is easier to understand and less prone to a "ripple
effect" [6] caused when errors occur at one location and
propagate through a system.
As long as a simple argument list is present between
two modules that communicate with one another (i.e., simple data are passed; a one-to-one correspondence of items
exists), low coupling (data coupling) is exhibited in this
portion of structure. A variation of data coupling, called
stamp coupling, is found when a portion of a data structure (rather than simple arguments) is passed via a module
interface.
At moderate levels, coupling is characterized by passage of control between modules. Control coupling is very
common in most software designs. In its simplest form,
control is passed via a "flag" on which decisions are made
in a subordinate or superordinate module.
Relatively high levels of coupling occur when modules
are tied to an environment external to software. For example, I/O couples a module to specific devices, formats and
communication protocols. External coupling is essential,
but it should be limited to a small number of modules
within a structure. High coupling also occurs when a number of modules reference a global data area.
The highest degree of coupling, content coupling,
occurs when one module makes use of data or control
information maintained within the boundary of another
module. Secondarily, content coupling occurs when
branches are made into the middle of a module. This mode
of coupling can and should be avoided.
The coupling modes discussed above occur because of
design decisions made when structure is developed.
Variants of external coupling, however, may be introduced
during coding. For example, compiler coupling ties source
code to specific (and often nonstandard) attributes of a
compiler; operating system (OS) coupling ties design and
resultant code to operating system hooks that can create
havoc when OS changes occur.
[4] Myers, G., Composite Structured Design, Van NostrandReinhold, 1978.
[6] Stevens, W.G., et al, "Structured Design," IBM Systems
Journal, vol. 13, no. 51974, pp.115-139. r
Exercise 3-12,
Assessing Design Fundamentals
In this exercise, we attempt to accomplish two things:
(l) to develop a design rating checklist, and (2) to
apply it to a computer program.
1. Working with your colleagues, develop a checklist
that will enable you to rate each of the design fundamentals discussed in the video: use of abstraction.
hiding, coupling, cohesion, use of structured programming, etc. The format of the checklist will be a scale of
1 (poor grade) to 5 (best grade). For example, the
technique described by Stevens (in the above reading) might be a useful way to establish grades for
cohesion.
2. Select a computer program from your library and
examine between 5 and 10 modules at the source
code or design level.
3. Grade each module using the design rating
checklist that you've developed.
3-4.8 ·· Essential Software Engineering
Post-Test, Module 3-4
This post-test has been designed to help you assess
the degree to which you've absorbed the information
presented in this ESE module.
Design Principles
1. To develop a stable software design, the first area
of design focus should be:
a. algorithms
b. data
c. program structure
d. interfaces
2. Software design makes use of which of the following elements of the analysis model:
a. data model
b. functional model
c. behavioral model
d. all of the above
e. none of the above
7.
The primary benefit of information hiding is:
a. to improve the code
b. to shorten the program
c. to reduce unintended side effects
d. all of the above
8. When you design, the size of a module should be
dictated by:
a. limitation on number of lines of code
b. its internal characteristics
c. the size of the module interface
d. the number of modules in the system
9. Two costs must be considered when selecting the
right number of modules for an application (select
from this list):
a. module development cost
b. tools cost
c. integration cost
d. communication cost
e. personnel cost
f. measurement cost
3. Most people believe that design should be performed explicitly. This means that:
a. specific design models are created
b. there is explicit reference to code
c. explicit requirements are implemented
d. all of the above
e. none of the above
10. Cohesion indicates:
a. the degree to which data structures are
contiguous across a system
b. the degree to which a module has been
refined in a stepwise fashion
c. the degree to which a module performs a
single, well-defined function
d. none of the above
4. A data abstraction called STACK is to be implemented. It's reasonable to believe that corresponding
procedural abstractions would exist. These would likely
be:
a. push and pop
b. open and close
c. create and delete
d. push and pull
11. To make the transfer of information across a large
system as simple as possible, a designer specifies a
large global data area that is accessible by all modules. How will this affect the coupling of the system?
a. it will improve coupling
b. it will result in high coupling
c. it will result in low coupling
d. it will have no effect on coupling
5.
12. Design metrics can be used to measure which of
the following software design characteristics
a. procedural complexity
b. architecture/structure
c. integration complexity
d. all of the above
e. none of the above
Stepwise refinement is a design approach that:
a. develops more detail with each iteration
b. develops less detail with each iteration
c. results in smaller computer programs
d. results in better data structures
6. Information hiding:
a. encodes all data within a module
b. constrains access to the internal details of a
data structures or a module
c. is used only for data base design
d. is used only for procedural design
Copyright 1995 R.S. Pressman & Associates, Inc. No part of
this material may be electronically copied, transmitted, or
posted without the express written permission of R.S.
Pressman & Associates, Inc.
These materials have been posted on the Local Web Server of
the Department of Computer Science with permission of
R.S. Pressman & Associates, Inc. and are for use only by
students registered for DCS/235 at Queen Mary and
Westfield College.