A COMPARATIVE STUDY OF SOFTWARE DESIGN METHODOLOGIES
by
Michael Tzu-cheng Yeh
SUBMITTED IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE
DEGREES OF
BACHELOR OF SCIENCE
and
MASTER OF SCIENCE
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
May 1982
Michael Tzu-cheng Yeh 1982
,Jl
Signature of
Author
/
-- I
Department of EtctricalifrgIneering and
Computer Science, May 7, 1982
Certified by
Stuart E. Madnick
Academic Supervisor, Department of Management
Certified by
Paul A. Szulewski
Company Supervisor, C. S. Draper Laboratory
Accepted by
A. C. Smith, Chairman
Department Committee on Graduate Students
A COMPARATIVE STUDY OF SOFTWARE DESIGN METHODOLOGIES
by
Michael Tzu-cheng Yeh
Submitted to the Department of Electrical Engineering and
Computer Science on May 7, 1982 in partial fulfillment
of the requirements for the Degrees of
Bachelor of Science and Master of Scie'nce in
Computer Science
ABSTRACT
four
out using
carried
study -was
comparative
A
an experimental
methodologies to design
software design
designs were evaluated in
The resulting
stream editor.
coupling.
module
and
strength
module
of
terms
done with a design aid
Documentation of the designs were
system called Design Aids for Real-Time Systems (DARTS).
examine one methodology
this study is to
The goal of
Methodology (SDM).
Design
Systematic
the
in particular above
used in the
methodologies
the
one of
SDM was
editor
of the
the evaluation
and through
experiment,
Also,
designs several weaknesses in SDM were discovered.
as a result of the experiment, several extensions for SDM
were found.
Thesis Supervisor:
Title:
Thesis Supervisor:
Title:
Professor Stuart E. Madnick
Professor of Management
Mr. Paul A. Szulewski
Member of Technical Staff,
C. S. Draper Laboratory
ACKNOWLEDGEMENTS
I wish to express my sincere thanks to my supervisors,
Szulewski
Paul
Mr.
(MIT),
Stuart Madnick
professor
to
Professor Madnick,
Barton DeWolf.
and Dr.
(CSDL),
has been
thesis,
the original idea for this
whom I owe
Paul has been
work with.
the most delightful person to
throughout
spiritually
and
technically
both
most helpful
Paul a warm thanks for
I especially owe
the project.
To Bart I
correcting the numerous errors in my thesis.
a VI-A
taking me on as
owe an extra special thanks for
topic of my
for me to work on a
and arranging
student,
own choice.
Jim Lattin for
of thanks also goes to
A sincere note
I wish to thank Mei,
Also,
the use of his SDM package.
for
at the Sloan School)
Rich and Tarak (PhD candidates
the many fruitful discussions.
During the course of the research I had the priviledge
to obtain the servicen of the CSDL library staff, without
Therefore
whose help this thesis would not be possible.
I also
I wish to thank the librarians for their efforts.
had the priviledge to have my thesis proofread by Natalie
Lozoski who corrected my numerous grammatical errors.
Towards the end
as well.
I wish to thank Susan Wang
Susan provided
of the project when things became hectic,
Her help
spiritual support.
me with encouragements and
is deeply appreciated.
Finally I would like to thank the Charles Stark Draper
Funding
Laboratory for providing the financial support.
for this project has been most generously provided by the
Internal Research and Development program.
to the
of this thesis
assign the copyright
I hereby
Cambridge,
Inc.,
Laboratory,
Draper
Stark
Charles
Massachusetts.
Michael Tzu-cheng Yeh
Stark
the Charles
granted by
is hereby
Permission
Draper Laboratory, Inc. to the Massachusetts Institute of
Technology to reproduce any or all of this thesis.
CONTENTS
pacre
Chapter
I.
INTRODUCTION
. . . . . . . . . . . . . . . . . . .
1
II.
DESIGN THEORIES . . . . . . . . . . . . . . . . . .
4
. . . . . .
Design Theories
Discovering the Structure
Problem Solving . . . . .
Reducing the Difference .
Software Design
III.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
System Life-cycle
and the
THE DESIGN METHODOLOGIES
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
5
5
7
8
.
.
.
9
.. . . . . . . . . 11
Hierarchical Development Methodology (HDM) . . .
. . . . . . . . . . . . .
The Decision Model
The Procedure . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
Jackson Methodology
The Procedure . . . . . . . . . . . . . . . .
Data Structure Definition . . . . . . . . . .
. . . . . . . .
Program Structure Definition
> Unique Features . . . . . . . . . . . . . . .
Structured Design (SD) . . . . . . . . . . . . .
The Procedure . . . . . . . . . . . . . . . .
Data Flow Graph (DFG) . . . . . . . . . . . .
. . . . . . . . . . . . .
Select a Technique
. . . . . . . . . . . . .
Transform Analysis
. . . . . . . . . . . .
Transaction Analysis
. . . . . .
Systematic Design Methodology (SDM)
. . . . . . . . .
Requirements Specification
Interdependency Assessment of Requirements
Graph Modelling of Requirements . . . . . . .
. . . . . . .
Graph Decomposition Techniques
. .. .. .
.
Other Design Methodologies *.....
Event-based
.
(EDM)
Design Methodology
.
.
.
13
14
17
20
21
21
22
24
25
26
27
29
29
30
31
32
33
35
35
36
36
Higher Order Software (HOS) . . . . . . . . . 38
. . . 40
Logical Construction of Programs (LCP)
. . . . . . . . . . . . . . . . . . 42
WELLMADE
IV.
AN EXPERIMENT IN SYSTEM DESIGN
Requirements for a
.
Data Structures
Internal Buffer
Buffer Position
. . . . . . . . . . 45
Stream Editor
. . . . . . .
. . . . . . .
Indicator . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
49
50
52
Simulated Screen
. . . . . . . . . . .
Screen Position Indicator . . . . . . .
The Package Structure . . . . . . . . .
Design Representation
. . . . . . . . . .
DARTS Call Graph
. . . . . . . . . . .
DARTS Trees . . . . . . . . . . . . . .
Functional Description
. . . . . . . .
Editor Designs . . . . . . . . . . . . . .
Hierarchical Development Methodology
.
Jackson Methodology . . . . . . . . . .
Structured Design . *.......
.
........
Systematic Design Methodology . . . . .
Design Evaluation
. . . . . . . . . . . .
Module Strength . . . . . . . . . . . .
Module Coupling . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . .
V.
CONCLUSION
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
. 53
. 53
. 53
. 54
. 55
. 57
. 57
. 58
. 83
111
121
130
130
131
142
. . . . . . . . . . . . . . . . . . .
145
The Complexity Problem . . . . . . . . . .
Strategies For Developing A Methodology
.
Modifications for SDM
. . . . . . . . . .
Suggestions For Further Research . . . . .
.
.
.
.
.
.
.
.
Appendix
pacre
. . . . . . . . .
154
. . . . . . . . . . . . . . . . . .
156
. . . . . . . . . . .. . . . . . . . . . .
158
A.
SDM INTERDEPENDENCY ASSESSMENTS
B.
SDM CLUSTERS
BIBLIOGRAPHY
145
147
149
152
-
ii
-
LIST OF FIGURES
Pacre
Ficrur e
1.
The System Development Life-cycle.
.
.
.
.
.
.
2.
Sequence of Decisions
.
.
.
.
.
.
.
.
.
.
14
3.
Dependencies Among Decisions Form a Tree-like
Structure . . . . . . . . . . . . . . . . . .
.
.
15
.
.
.
23
.
.
.
.
.
.
.
.
.
4.
The Three Basic Structuring Components
5.
The Mosque Shape of Low-cost Systems (adapted
[YOUR79]) . . . . . . . . . . . . . . . . . . . . 25
6.
An Example of DFG (Adapted from [YOUR791)
7.
Data Structure
8.
Three Different
9.
DARTS Tree Components
.
.
.
.
.
28
Definition for LCP
.
.
.
.
. . . . . 42
Buffer Structures
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 56
10.
HDM's Abstract Machines for the Editor .
.
.
.
.
.
. 59
11.
EDITOR Machine
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
59
12.
BUFFER Machine
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
60
13.
SCREEN Machine
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
60
14.
HDM Architecture
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
60
15.
Jackson's Input and Output Data Structures
.
.
.
.
. 84
16.
Jackson's Input Handler
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
17.
Jackson's Output Handler
.
.
.
.
.
.
.
.
. .
.
.
.
.
85
18.
Jackson System Architecture
.
.
.
.
.
.
.
.
.
.
.
. 86
19.
DFG for the Editor
.
.
.
.
.
.
.
.
20.
The Transaction Architecture
.
.
.
.
.
.
. .
.
.
.
112
.
.
.
-
.
.
.
iii
.
-
.
.
.
51
21.
The Reduced DFG
.
.
.
.
.
.
.
.
.
.
.
112
22.
Structured Design Architecture
.
.
.
.
.
.
.
.
.
.
113
23.
SDM Architecture
24.
Evaluation of HDM
25.
Evaluation of Jackson's Methodology
26.
Evaluation of Structured Design
27.
Evaluation of SDM
.
.
.
28.
Summary of the Evaluations
.
29.
3-D Clustering
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
.
.
.
.
.
.
123
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
135
.
..
..
.
137
.
.
.
.
.
.
.
.
-
iv
-
.
.
.
.
.
.
.
.
.
139
.
.
.
.
.
.
.
.
.
.
14 1
.
.
.
. .
.
.
.
.
.
.
142
.
.
.
.
.
.
.
.
.
150
Chapter I
INTRODUCTION
As computer systems become more complex,
software devel-
opment and maintainance costs begin to dominate.
lem is that software has become
age,
and it
large and difficult to man-
is evident that the ad-hoc
What
only makes matters worse.
The prob-
way of programming
is needed is a disciplined
methodology for software development.
Past research has revealed various phases in the software
development life-cycle
(see figure 1).
r--------------------------------------------------------------------------I
User Requirements
System Requirements Specification
Architectural Design
Detailed Design
Programming
Debugging
Testing Operation and Monitoring
Maintainence
Figure 1:
The System Development Life-cycle.
L-------------------------------------------------------------------------------------
-
1 -
2
that problems arising in
it has been found
Furthermore,
debugging and testing usually have their roots in an earlier
In the case of ad-hoc programming, the cause is the
phase.
absence of any architectural design effort.
an attempt has
In recent years,
of technology called
result is a body
The
above problem.
been made to attack the
"Software Design Methodologies".
These methodologies differ
Some pro-
in approach and in specific areas of application.
design can be mechanically de-
vide techniques with which a
give guidelines and require
Others merely
rived.
-signer to work out the design.
size,
programs of small
designs.
final
Some can be applied best on
for large system
others are meant
these methodologies are united in their
However,
objective -
the de-
to fill
the
void between
requirements
specification and actual coding.
design methodologies attempt ta provide de-
Essentially,
signers with
The framework
software planning.
a structural framework for
is designed
complexity of the design task (usually
vide-and-conquer tactic).
way to
to provide a
manage the
in the form of a di-
It is also designed to embed de-
sirable qualities
in the software under
most importantly,
it
development.
is designed to allow
But
the designer to
think about the program carefully before he starts the actual coding.
One methodology
this thesis:
in particular
is the
integral part
The Systematic Design Methodology
(SDM).
of
SDM
3
is a methodology
agement.
developed by the MIT Sloan
It has been used in the design of a Database Manan Operating System, a Budgeting Sys-
agement System (DBMS),
tem,
School of Man-
preparation facility.
and a test program
reports on the methodology have been encouraging.
So far the
However,
to get a better idea of SDM's potential, it would be beneficial to compare it against other methodologies.
Thus the goals of this thesis
other methodologies,
are to compare SDM against
develop qualitative as well as quanti-
tative evaluations of methodologies,
and to suggest exten-
sions or improvements for SDM.
The project proceeds
from an examination of
design problem to specific
methodologies.
the general
Five stages are
identified:
1.
Design Theories.
2.
Design Techniques,
3.
Design Methodologies,
4.
Comparing design methodologies through actual design,
5.
Extending SDM.
The rest of this thesis is organized in a similar manner.
Chapter II presents a few of the popular views on the nature
of design problems.
methodologies.
Chapter III
presents a list of design
Chapter IV describes
paring several design methodologies.
an experiment in comFinally, the conclud-
ing chapter presents suggestions for modifying and extending
SDM.
Chapter II
DESIGN THEORIES
Before a study of design methodologies can be undertaken,
it is necessary
tive.
a broad perspec-
to understand design from
Peter Freeman speaks of this need [FREE771:
broad classes of phenome"Without an understanding of
na, one is condemned to understand each new instance by
itself."
Indeed,
the essence
of science is to
characteristics in the environment
knowledge,
Furthermore,
discover unifying
Having this
around us.
outcome of specific actions.
we can predict the
knowledge to choose those ac-
we can use this
tions which yield desired results.
The purpose of
this chapter,
therefore,
is
to present
popular views on the nature of design, and how it relates to
software development.
The first
different viewpoints on design.
section describes
three
These viewpoints are col-
lected from three different disciplines - Architecture, Civil Engineering,
section puts
and Artificial Intelligence.
design in
perspective with
ment.
-
4 -
The second
software develop-
DESIGN THEORIES
2.1
Although software
subject of
time.
these
design is
design in
a recent
general has
development,
been around
for a
the
long
Consider the Egyptian Pyramids and Roman Cathedrals,
are all
complex
structures
which required
significant understanding of
design from the fields
chitecture and Civil Engineering.
views on the
In
fact,
the first two
who received his edu-
His views on design [ALEX64]
cation from MIT and Harvard.
Marvin Manheim is a pro-
have become the backbone of SDM.
Civil Engineering
of Ar-
from these fields.
nature of design are taken
Christopher Alexander is an architect
fessor of
to expect a
Therefore it is logical
planning and design.
careful
at MIT.
Professor Manheim's
work in Urban Planning [MANH64,67] also represents an unique
view on design.
A third area from which
is Artificial Intelligence.
negie Mellon looks
tive.
2.1.1
interesting results have emerged
Professor Herbert Simon of Car-
at design from a
psychological perspec-
His views can be found in [SIM069J.
Discovering the Structure
The first approach to design
by Christopher Alexander
presented here is advocated
[ALEX64J.
It is of special inter-
est because it is the basis for the SDM approach.
In Alexander's view, the major difficulties in design are
caused by the complexity of the design problems.
The number
6
keep track of all of them.
large that it is not possible to
Therefore,
it is necessary to have
ducing the
design problem
a systematic way of re-
into manageable
pieces.
satisfactory solution
to the original
These
and a more
then be attacked one by -one
separate pieces can
become so
must consider has
of competing factors a designer
problem can
be pro-
duced.
Before proceeding further,
it is necessary to understand
size of the
It is not merely the
what causes complexity.
problem, for surely we can solve a thousand arithmetic problems easily;
others.
when
do with the
each problem has nothing to
Alexander points out that
the solu-
In other words,
interaction among requirements.
tion to one requirement is
the real culprit is the
often dependent on the solutions
to many of the other requirements.
Thus,
Alexander proposes a way to model the interactions
between requirements,
from that model.
with a graph.
and extract the optimal decomposition
is to model the situation
The basic idea
The requirements are the nodes,
teraction between requirements are the links.
and the inThe designer
can then apply an algorithm to the graph and find the decomposition which minimizes the interaction among the resulting
components.
with each
This decomposition allows the designer to deal
component independently,
plexity faced by the designer.
thus reducing
the com-
This process is, in effect,
the search for the problem structure, where structure is de-
7
and their,
underlying components
be the
fined to
interac-
tions.
2.1.2
Problem Solving
open to a
The variety
in design.
management is the major difficulty
of options
complexity
view that
expressed the
Manhiem [MANH64,67]
designer are
so numerous that
difficult just to list them exhaustively.
it is
To find the opti-
mal solution is somewhat an unrealistic goal.
Manheim proposes a model called
The basic activities of'the PSP are search and
cess (PSP).
select.
the Problem Solving Pro-
Search generates a set
of alternatives
and select
makes a decision on which alternative to follow.
and select procedures are
The search
until a satisfactory solution is found.
the search
procedure generates
feeds into the select procedure.
evaluation techniques to
options.
further,
The option
a set
More specifically,
which it
of options
Select then employs some
assign a priority ordering
with the highest priority
and the search-select process
to the
is pursued
is repeated until a
The designer must decide
when the op-
sufficient decision space and
the solution
solution is found.
tions provide a
used repetitively,
is satisfactory.
Manheim also suggests that a computer be used in PSP, especially the graphic capabilities because the human mind can
work much better with a
picture than with senteng;es.
Fur-
8
thermore,
the entire
PSP can be automated
efficiency as well as its effectiveness.
asserts that the
to increase its
Moreover, Manheim
complexity of design problems
provably optimal solution.
precludes a
Nevertheless, one can still de-
velop an optimal design process.
2.1.3
Reducing the Difference
In yet another view,
sign as
a process
Herbert
of reducing
Simon [SIM069]
the difference
present state and the desired state.
design, some sensors
state of the
world,
sired state.
(e.g.,
defines debetween the
At every stage of the
human or machine)
describe the
then the state is compared
to the de-
A set of differences is generated,
and solu-
tions are devised to resolve the differences.
Simon models the above process
ver (GPS).
At any moment in
as a General Problem Solthe GPS asks the
the design,
question, "What shall I do next?".
To answer this question,
the GPS stores information in its memory about states of the
world and about
actions.
in states
tween changes
these changes.
Now
It also stores
and the
associations be-
actions that
the GPS's question can
searching for a series of
bring about
be answered by
actions which produce the desired
changes in the state of the world.
The difficulty
procedure.
in the
above scheme
lies in
Simon suggests a breadth-wise
search.
the search
The GPS
starts with a set of alternative actions, and assigns a val-
9
ue to each.
that the
hood
The GPS
path.
corresponds to the relative likeli-
The value
desired state
investigates several of the
most promising
is eliminated as more
An alternative
actions in parallel.
and the path begins
information is gathered,
that
reached through
can be
to look less
In effect, the GPS is building up a
promising than others.
decision tree in its memory.
It
gathers more and more inThis
formation about the design as decisions are explored.
process
a
continues until
path to
the
desired state
is
found.
Note that Simon does not
mization in his model.
be
best described
words,
the problem.
In fact he believes that design can
by the
most designs
incorporate any notion of opti-
word
"satisficing".
are merely a satisfactory
Optimization
In
other
solution to
is not possible because
of the
enormous complexity of most design problems.
SOFTWARE DESIGN AND THE SYSTEM LIFE-CYCLE
2.2
Early in the growth of software engineering research,
it
was found that typical software systems go through 9 different phases:
1.
User requirements specification,
2.
System requirements specification,
3.
Architectural design
4.
Logical design
5.
Programming.,
(or detailed design),
6.
Debugging,
7.
Testing,
8.
Operation and monitoring,
9.
Maintainence.
incurred
This
when components
are
put
planning or architectu'ral design.
be effectively
defined as
together and
Thus,
the bridge
debugged.
of overall
the lack
caused by
phenomenon is
costs were
the greatest
revealed that
Further research
system
software design can
between requirements
It is the activity of look-
specification and programming.
ing ahead and planning out the organization of the program.
Software design can be further divided into architectural
design and logical design.
Architectural design deals with
It usually involves decomposition, set-
the entire system.
ting up communication between
components,
(e.g.,
sions that have global effects
handle file I/0,
and making deci-
creating a module to
or an executive module to do dispatching).
In effect, the architectural design is analogous to the bone
structure in the human body.
hand,
deals with local issues.
each component (e.g.,
put into a buffer,
ber 0).
Logical design,
on the other
It involves the details of
how data is taken out of the file and
or what to do when the input is the num-
This subphase can be thought of as the flesh which
envelops the framework of bones.
Together the flesh and the
bones perform the functions of the system.
Chapter III
THE DESIGN METHODOLOGIES
The last chapter identified the
design.
basic issues in software
This chapter looks at the technology which addressThe technology is called "Software Design
es these issues.
Methodology".
Formally, a software design methodology has the following
properties (see also
1.
A structured
[HUFF79]):
This property
approach.
requires the
methodology to have a definite view on how the design
It may be top-down, bottom-up, or a
should proceed.
mixture of the two.
The important thing is that the
methodology provides
the designer with
a direction.
It can be thought of as a compass, a top level strategy, or an overall plan.
2.
A procedure.
steps in
The procedure specifies
carrying out the structured
adds a sense of mechanization
More specifically,
the detailed
approach.
to the design process.
the procedure
provides clear in-
structions and specifies well defined tasks.
sence,
the procedure is like
the designers
are the workers
parts together.
-
11
-
It
In es-
an assembly line,
who actually
and
put the
12
3.
Tools.
er.
Tools are mechanical helpers for the designThey
may vary from simple
graphic representa-
tions of design to design languages, or even programs
which produce programs.
The rest of the chapter describes a collection of methodologies.
The first 4
sections describe methodologies that
(chapter 4).
are used in the experiment
contains
descriptions of
4
The final section
other methodologies,
overviewed and included for completeness.
briefly
HIERARCHICAL DEVELOPMENT METHODOLOGY
3.1
[ROBI791,
HDM ([LEVI80,
(HDM)
is primarily an aid
[SILV791)
the de-
recording decisions made during
in structuring and
Based on a decision model, HDM employs sever-
sign process.
al different software engineering concepts for the structurHDM also emphasizes the
ing and the grouping of decisions.
need for flexibility
an error
stances where
Citing in-
in a design methodology.
in early
cata-
decisions produced
strophic results, HDM proposes that some methodologies force
designers
premature
make
to
HDM
proceduralized ver-
flexibility in its
strongly emphasizes
Therefore
decisions.
sion.
The basic idea
into levels of abstract machines.
ordered,
of a program
in HDM is the decomposition
The machines are linearly
and each machine can only communicate with the ma-
chines directly
above and below
itself.
Within
stract machine further decomposition takes place.
chine also has its own abstract
abstract operations.
These operations are
cannot be accessed
Each ma-
data structure and a set of
the machine of the next lower level.
each machine
each ab-
implemented on
The data structure of
from the
outside,
through the defined operations of that machine.
except
The Decision Model
3.1.1
design as a process
HDM views software
ing.
of decision mak-
At any stage of its development, the software results
Each decision depends only on
from a sequence of decisions.
the decisions occurring before it.
Although decisions occur
as in figure 2,
in reality each decision
linearly in time,
depends only on
a subset of the
decisions occurring before
This can be thought of as partial sequences,
it.
possibly
intersecting at some point (see figure 3 ).
-----------------------
r--------------------------------------------
d 1 m.
d 2 ..
Figure 2:
d3 mm-m
d4...
=em.d n
Sequence of Decisions
L-------------------------------------------------------------------------------------
Two issues
of importance in
the decision model
are the
time when decisions are made, and the dependency between decisions.
Organizing the decision-making process to address
these issues,
1.
HDM uses the following concepts
Abstraction
-
Abstraction is defined as the process
of isolating a subset
ing a system,
as guidelines-
of the properties characteriz-
such that the system can be understood
----------------------------
------------
----------------
dod
d3
Figure 3:
,
d
d4
d5
d
d
d10
d
d6
d
d12
Dependencies Among Decisions Form a Tree-
I
like Structure
--------------------------
L -----------------------------------------------------------
niore easily and the system can be used as if it possThe concept of
essed only that subset of properties.
levels of abstraction provides a
interdependence between decisions
way to describe the
(i.e.,
and to minimize
only depends on the level before it),
that dependence
(i.e.,
each level
abstract only
the necessary
features of decisions on the level below).
2.
Hierarchies of Abstract Machines
applying the
hierarchy.
idea of abstraction
-
The next step in
is the
concept of
Any programming problem can be thought of
as a set of instructions to an abstract machine.
The
16
stract machine,
another ab-
in turn realized by
abstract machine is
and so on.
design eventually
The
reaches a level where the abstract machine can be realized by
machine (e.g.,
a physical
language processor).
a programming
In HDM, an abstract machine has
the following properties.
a) A set of internal data structures which define the
state of the machine.
operations by which the
b) A set of
data structures
can be manipulated and changed.
c) A data
can be
structure internal
machine which
to each
defined opera-
through the
accessed only
tions of that machine.
The
hierarchy
of abstract
machines
provides
a
structure for decision making. It also enables the
grouping of decisions into individual machines.
3.
Modularity
- As defined by HDM, modules are parts of
a system which can be
be easily replaceable,
easily replaced.
HDM requires a module to have
a well-defined external interface.
other module
terface to
This allows an-
satisfying the requirements
replace the
In order to
original module
knowledge of internal details.
localize the. effect of decisions
of
the in-
without any
Modularity is used to
and to minimize de-
pendencies between decisions of different modules.
17
4.
-
Formal Specification
Formal specification in HDM
provide a complete documentation
is meant to
cisely described
of
Language).
and Assertion
formal
is pre-
language called
by a specification
SPECIAL (SPECIfication
further goal
Each module
during design.
decisions made
of all
is
specification
A
machine-
checked consistency and well-formedness.
5.
-
Formal Verification
techniques
programs can
whereby
proven correct.
Formal verification refers to
be
mathematically
HDM employs the inductive assertion
technique developed by Floyd ([LEVI801).
The purpose
of verification is to provide a means for determining
the consistency among decisions.
6.
-
Data Representation
Many situations arise in pro-
gramming where mathematical concepts
data structures.
are modelled by
Verification of the model is often
therefore a technique called "data repre-
difficult,
sentation function" is used.
This function defines a
mapping between mathematical concepts and data structures.
Verification
can be performed
by examining
the mappings.
3.1.2
The Procedure
HDM warns against strict step-by-step procedures.
roneous decision
made in
discovered until it
an early step
became too costly to
often did
An ernot get
change that deci-
18
Instead, HDM provides guidelines for decision-making
sion.
and
a seven
development
stage
progress can be measured.
ordered in time,
Although the seven stages appear
HDM emphasizes that it is not necessary to
In fact HDM encourages
carry out the design in that order.
the designer
development
milestones by which
to provide a series of
scheme is meant
The
scheme.
natural course of
to follow the
the decision
making process.
The seven stage scheme is as follows:
1.
Conceptualization of identifying
Conceptualization is the process
the design problem,
problem as requirements.
This is
and
stating the
also known as re-
quirements specification.
2.
External Interface Definition -
Defining the abstract
machines that interact with the outside world.
This
consists of the top-most machine in the hierarchy and
the bottom-most machine in the hierarchy.
during this
step is the
decomposition of
Also done
these ma-
chines into modules.
3.
System Structure Definition ate abstract machines
ules.
and
Defining the intermedi-
decomposing them into mod-
Intermediate machines can be defined in three
different directions:
Top-down, bottom-up, or middle-
out.
4.
Module Specification SPECIAL
This step is carried out using
(SPECIfication and Assertion Language).
Pre-
19
explicit descriptions of decisions
cise and
made in
stages 2 and 3 are recorded in SPECIAL.
5.
Data Representation -
the data structures of
Define
every non-primitive machine (i.e.,
cept the bottom
most machine)
every machine ex-
in terms
of the data
structures of the machine on the next lower level.
6.
Abstract
each
Implementation -
Implement operations
an abstract
as
non-primitive machine
program
running on the machine of the next lower level.
are written in
abstract programs
of
The
ILPL (Intermediate
Level Programming Language).
7.
Concrete
grams,
Implementation -
written
in stage
This can be done by
Translate abstract
6,
into
pro-
executable code.
translating ILPL programs into a
modern programming' language, or directly compile ILPL
into machine code.
JACKSON METHODOLOGY
3.2
The Jackson Methodology
phy
that the
[JACK75]
program structure
is based on the philoso-
should
match the
problem
To discover the problem
structure as closely as possible.
the data
structure re-
flects the problem structure very accurately.
Once the in-
structure,
Jackson
theorizes that
put and output data structures are
found,
a program can be
created to transform input data into output data.
more,
data structures can be
Further-
expressed with the same kinds
of components as those used for the program structure
(i.e.,
the sequence component, the iteration component, and the selection component).
to build the
This observation
enables the designer
which can be
data structure out of components
directly translated into program components.
However,
anomalies
between input
and output
rise to situations where it is impossible to
late data structure into program structure.
fies two typical situations:
data give
irectly transJackson identi-
structure clash and backtrack-
ing.
Structure clash occurs when an
not match the output data
input data structure does
structure.
This mismatch can be
caused by a different ordering among components,
to-one mapping,
or by a one-to-many mapping.
if the input data are rows of a matrix,
by a manyFor example,
and output data are
columns of the matrix, then a structure clash occurs.
21
Backtracking problems arise
dependent upon
but the
a condition,
checked unless the task is executed.
table lookup,
forming a
value of an
However,
the
retrieving the
should actually exist.
exists or
In this case,
one would
then determine the value of
have to perform the task first,
a point
For example, when per-
determine whether the entry
not unless a lookup is performed.
the condition.
be
condition cannot
condition for
entry is that the entry
one cannot
task is
when execution of a
If the condition is false then backtrack to
before the
task was
performed,
and
take another
path.
3.2.1
The Procedure
Jackson's methodology can be divided into three stages:
1.
Define the input and output data structures.
2.
Create
the program
tures.
In other words, transform data structure com-
structure from
the data
struc-
ponents into program modules.
3.
List the program tasks as executable operations,
and
allocate each task to a program component.
3.2.2
Data Structure Definition
Jackson's methodology provides a graphical representation
of the three structuring components.
They are given in fig-
ure 4.
The components are represented in a hierarchical fa-
shion.
This implies that the program structure is also hi-
22
because program structure is expressed with the
erarchical,
same components.
3.2.3
Program Structure Definition
Jackson
also provides
each of the
a general
problems caused by data
anomalies.
data structures.
Structure
Recall that structure
clash is solved by program inversion.
clash is caused by inconsistencies
solving
heuristic for
between input and output
The program inversion technique breaks in-
put data into elementary components, then recombines them to
For .example,
form the output data.
in the matrix problem
considered earlier, the rows could be broken into individual
elements,
then recombined later to form the columns.
Backtracking problems are solved by a three step process:
1.
Structure the problem as a sequence, ignoring the impossibility of evaluating the condition,
Recall that a back-
one branch of the conditional.
tracking problem arises when
the condition cannot be
a task whose exe-
evaluated without first performing
cution
depended on
the
and execute
condition.
This step
is
equivalent to executing the then-clause.
2.
Determine whether an incorrect
then either proceed
choice has been made,
or do a conditional
transfer to
the else-clause.
3.
Consider the side effects caused
then-clause,
by execution of the
and make appropriate corrections before
the original else-clause is executed.
------------------------------------
------------------
The Sequence Component
The Iteration Component
The Selection Component
Figure 4:
The Three Basic Structuring Components
L----------------------------------------------------------------------------------------
I
3.2.4
Unique Features
Jackson
First,
makes
claims
several
about
the
methodology.
the methodology provides a simple criterion by which
to judge whether a program structure is correct.
More spe-
cifically, if the program structure matches the correct data
structure, then the program structure leads to a "good" proof constructing the data struc-
gram (but the critical step
tures is not at all trivial).
Second, the methodology has a
and every aspect of the methodology can
unifying principle,
The principle is:
be validated from that principle.
structure reflects
problem structure,
should reflect the problem structure.
gy is easy to learn, easy to use,
individual designer's ability.
covering data structures
and a
Data
good solution
Third, the methodolo-
and does not depend on an
That is, the process of dis-
and transforming them into
a pro-
gram structure is very mechanical, therefore requires little
ingenuity.
Finally,
the methodology produces a hierarchi-
cally structured program.
onymous to good design.
According to Jackson this is syn-
STRUCTURED DESIGN (SD)
3.3
The SD
by a study
[YOUR791 approach is inspired
It is found that
morphology of systems.
of the
low-cost systems
are usually shaped like a mosque (see figure 5).
r--------------------------------------------------------------------
Figure 5:
The Mosque Shape of Low-cost Systems
(adapted from [YOUR791)
L--------------------------------------------------------------------------------------
Furthermore these
low-cost systems
are centered
various aspects of the system functions.
the different types of centers
the transaction
center.
around
Most important of
are the transform center and
The transform center
consists of
those modules which transform the input data stream into the
output data stream.
The transaction center refers to places
in the system where the data
stream is split into many sub-
streams.
To identify these
(DFG).
centers,
SD uses the
Data Flow Graph
The DFG is a pictorial way to describe the transfor-
mation of input data into output data.
26
SD provides two techni-
Having identified these centers,
ques
for constructing
Transform
system architecture:
a
These techniques will be
Analysis and Transaction Analysis.
discussed in the following sections.
3.3.1
1.
The Procedure
Translate
the
design
problem into
(See
DFG.
a
[YOUR791 chapter 10 for examples of DFG)
2.
represents a sequence of
If the DFG
performed, then use Transform Anal-
of which must be
ysis.
transforms each
a selection among many
If the DFG represents
alternative routes then use Transaction Analysis.
Transform Analysis:
1.
Identify
the input
These elements
stream
of the DFG
data elements and efferent
and
the output
are also
stream.
called afferent
data elements respective-
ly.
2.
Identify the transform center.
The transform center
consists of one or more transform elements.
3.
Translate the DFG into a system structure as follows:
; TPNSFO141
COORDINqA'IOR
CENTER
AFFERENT
ELEMENTS
EFFERENT
ELEMENTS
27
4.
Go back
to step
1 and apply
the procedure
to each
module in the system.
Transaction Analysis:
1.
Identify the transaction center.
2.
Translate the DFG into a system structure as follows:
TRANSACTION
DISPATCE
.
KOPACENTER
ALTERNATE
PATHS
3.
Go back
to step
1 and apply
the procedure
to each
module.
3.3.2
Data Flow Graph
The DFG can
(DFG)
be thought of as a
decomposition tool.
It
allows the designer to describe the processing of input data
in terms of well defined transformations.
For example, fig-
ure 6, shows the processing of inputs from a medical monitor
device.
However,
it
is not
problem into a DFG.
always easy
to translate
a design
SD does not provide a systematic way to
Figure
solve this
They are
1.
6:
An Example of
a set
of guidelines
I
are given.
summarized below:
Work from different d irections:
put
to
middle
input,
switch to
2.
[YOUR791)
(Adapted from
DFG
Instead,
problem.
NTF
NURSE
FIND
UNSAFE
FACIOPS
S'IORE
FACTORS
ADM
FACIORS
Input to output,
When one
out.
out-
approach fails,
another.
In other words,
Do not show control logic.
what needs
to
be
done
to
the
data,
just show
not how
it is
d one .
3.
Ignore initialization and termination.
4.
Label data elements.
5.
Use
of
6.
*
(AND)
and +
(OR)
symbols
to indicate the type
data stream splitting.
Do not
show unnecessary
details,
show more detail rather than
but if
too little.
in doubt,
3.3.3
Select a Technique
The difference between Transform Analysis and Transaction
is applied whenever
Transform Analysis
another way.
Analysis can be viewed in
AND relationship
the DFG represents an
between the bubbles in the
Transaction Analysis,
DFG.
on
the other hand, is applied when the DFG represents an OR relationship between the bubbles in the DFG.
3.3.4
Transform Analysis
of afferent,
The identification
efferent
elements is not a clearly defined task.
input data
becomes output data depend
taste of the designer.
and transform
When and where the
a great deal
on the
SD offers the following definitions
toward the resolution of the above problem:
1.
Afferent data elements are
of data that
those high-level elements
are furthest removed from
physical in-
put, yet still constitute inputs to the system.
2.
Efferent data elements are
of data that are furthest
those high-level elements
removed from physical out-
put, yet still constitute outputs to the system.
3.
The transform elements are
everything in between the
afferent elements and the efferent elements.
The translation of
mechanical process.
the DFG into a system
structure is a
Each bubble in the DFG becomes a module
and a coordinate module is created to manage them.
30
3.3.5
Transaction Analysis
The transaction
center is much
the transform center.
identify than
easier to
The unmistakable characteristic of a
transaction center is the two
or more "OR" branches extend-
ing from a bubble.
Having identified the transaction center,
step to create the system
created
paths.
to
perform
structure.
the selection
it is a simple
A dispatch module is
among
the
alternative
SYSTEMATIC DESIGN METHODOLOGY
3.4
(SDM)
Alexander's work on de-
SDM's philosophy is adopted from
sign theory
sign as a
Essentially, this approach views de-
[ALEX64].
being the
Structure
the problem.
structure can be applied
This idea of
other words,
In
underlying sub-
set of
interact with each other.
problems and how the sub-problems
as well.
inherent structure of
process of discovering the
to each sub-problems
the sub-problems
themselves can
have sub-problems.
software perspective,
Looking at it from a
losophy involves
the SDM phithe design
discovering a decomposition of
problem into modules,
or
These modules are
sub-problems.
themselves decomposed into still
smaller modules,
and this
process could be carried to any degree of detail.
To carry out the top-down decomposition, SDM uses a graph
model (see [HUFF79]).
guirements
links.
as nodes,
The idea
and
is to model individual rebetween nodes
interactions
as
However, because interactions can be weak or strong,
every link is given a weight between 0 and
Having translated the design problem
1.
into a graph decom-
position problem, the next step is to formulate the decomposition criteria.
The SDM approach
is to maximize the fol-
lowing conditions:
1.
Strong interdependencies between members of a group.
2.
Weak interdependencies
between members
of different
groups.
In summary, SDM's procedure can be divided into 4 steps:
1.
Specification of the functional requirements,
2.
Determine the
degree of interdependency
between all
pairs of requirements,
3.
Represent the requirements as
nodes and the interde-
pendencies as links between nodes,
4.
Apply a decomposition algorithm to the graph.
Each of these steps is further
expanded upon in the fol-
lowing subsections.
3.4.1
Requirements Specification
Requirements specification
done,
oriented,
not
Put another way, specifications should be
process oriented.
non-procedural,
is capability
it should not state
how something is to be
merely what is to be done.
Specifications must have the following three characteristics
1.
Unifunctionality
-
Each statement describes a single
function to be incorporated in the target system.
2.
Implementation Independence be non-procedural.
In other
Each statement should
words,
should specify what needs to be
done,
each statement
not how it is
to be done.
3.
Common Conceptual Level -
All requirements should be
on the same level of generality.
A set of seven requirement statement templates was developed to meet the above criteria, and also to ease the trans-
33
lation of requirements stated
list
templates
the
of
is
in other forms/languages.
given
below
(adapted
A
from
[HUFF79]).
The 7 Templates:
1.
Existence
There
2.
(can/will) be <mod> <obj>
Property
<mod> <obj>
3.
(can/will) be <mod> <property>
Treatment
<mod> <obj> (can/will) be <mod> <treatment>
4.
Timing
<mod> <obj> (can/will) <timing relationship> <mod>
<obj>
5.
Volume
<mod>
<obj>
be
(can/will)
<order
statement>
<index> <count>
6.
Relationship
(Subsetting)
<mod> <obj>
7.
(can/will) contain <mod> <obj>
Relationship (Independence)
<mod> <obj>
(can/will)
be
independent of
<mod>
<obj>
3.4.2
Interdependency Assessment of Requirements
The next
step is the determination
of interdependencies
between all pairs of requirement statements.
pendencies are expressed as weights.
These interde-
A weight is a number
34
The smaller the number the weaker the in-
between 0 and 1.
while a
terdependence,
fect.
opposite ef-
larger number has the
Therefore the value of 0 means absolute independence,
while a value of 1 means absolute dependence.
Through experience,
breakdown
fall
assessments
interdependency
Strong(0.8),
SDM users
average(0.5)
is much
have discovered that most
This three way
and weak(O.2).
easier to
categories:
three
into
still providing
use while
a
meaningful measure of interdependency.
There still remains the question of how interdependencies
are determined.
SDM does not provide a systematic method to
meet this need.
However, SDM offers the following points as
guidelines:
1.
at least some idea of
The designer must have in mind
how to implement related requirements.
plementation scheme,
From this im-
the designer can then
If it is possible to
assessment of interdependency.
develop several schemes for implementation,
designer can
give an
evaluate the different schemes
then the
and as-
sign weights according to how important a pair of requirements is within each of
words,
if a pair of
in all the
schemes,
the schemes.
requirements
2.
seem to be related
then a weight of
assigned to it.
In other cases, trust intuition.
In other
0.8 should be
3.4.3
Graph Modelling of Requirements
Each requirement stated using the
template method can be
represented by a node, and the interdependencies can be repThe weights can be record-
resented by links between nodes.
ed in
a square matrix,
and
the square matrix can
then be
used in the decomposition process.
3.4.4
Graph Decomposition Techniques
Several different clustering algorithms
oped in connection to SDM.
Algorithm and the Hierarchical
tailed discussion of
[WONG80] and
[LATT801.
have been devel-
Among them are the Interchange
Clustering Techniques.
the algorithms are found
De-
in [HUFF79],
OTHER DESIGN METHODOLOGIES
3.5
In this section we describe
These
4 other methodologies.
methodologies were not chosen for
the design experiment for
they
still provide interesting
However,
various reasons.
insights to software design.
3.5.1
(EDM)
Event-based Design Methodology
EDM [RIDD79]
a methodology based on
is
the top-down de-
sign approach, and it is particularly good for the architectural design phase.
The methodology consists of iteratively
These steps form a stage of the
applying four basic steps.
design.
is a partial design,
The input to a stage
corre-
sponding to the current state of the design effort.
The four steps are as follows:
1.
Identify events occurring
the system
in the part of
An
which is being considered in
the present stage.
event could be a "happening"
in the system which re-
quires the
shion.
system to respond
Or an event could be
an action taken by the
system in response to some stimuli.
events definition
specified fa-
in some
In other words,
is specification of the
input and
required system behavior in response to these inputs.
2.
on the occurrences
of events.
is basically the specification
of correct
Establish constraints
This step
system behavior in response to stimuli.
The differ-
1 lies
in the scope
ence between this
step and step
37
of consideration.
desired system behav-
1,
In step
iors are stated in term of what needs to be done.
It
does not consider how it is done nor does it consider
There-
interactions with other parts of the system.
fore by establishing constraints such as the sequence
in which events
place,
(i.e., system responses)
should take
the designer can gradually evolve requirements
into functional modules.
Define components which would perform tasks specified
3.
defines a module for each
This step
by the events.
of the events that correspond to a desired system beThe defined module can be completely new or
havior.
it can be an existing
module created during a previ-
ous stage.
4.
Define
the necessary
interactions between
The interactions would be
of step 2.
to provide
subject to the constraints
The developers
of this methodology plan
based on
verification capabilities
is,
if during
step.
That
stage,
the designer
the constraints,
modules.
this step
can prove he has
within every
satisfied all
be the basis
then it could
this
for a
proof of correctness.
This
methodology presents
top-down approach described earlier.
tion
procedure has
proach,
to the
a variation
been extracted
and given more freedom in
strictly
The basic decomposifrom
the top-down
its use.
ap-
The four step
38
procedure, described above is actually a formalization of the
basic decomposition process in the top-down approach.
over,
procedure can be treated
this formalized
More-
as a basic
building block with which a complete design procedure can be
constructed.
A direct consequence of the above is the increased flexibility over a strictly top-down approach.
proach,
but in
the design problem is decomposed in an orderly way,
the only input
dently
time.
This is true because
a partial de-
to the four step procedure is
This partial design need not
ries of decomposition
defined.
be the result of a se-
because it could
steps,
This
be ap-
desomposition step can
this methodology the
plied to any subproblem at any
sign.
In a top-down ap-
feature is
especially
be indepenuseful
in
combining the top-down approach with other approaches.
3.5.2
HOS
Higher Order Software
(HOS)
[HAMI76] was born out of
designing and implementing NASA
many years of experience in
projects.
is oriented toward large real-time systems.
The methodology
Because of the
complexity usually associated with such systems,
ported by a
system of tools called
Development System
(ISDS).
HOS is sup-
the Integrated Software
The designer interacts with ISDS
to produce a specification of
the target system.
Then the
specification is fed into the Design Analyzer and the Structuring Executive Analyzer.
The output of the Analyzers is a
39
complete system specification.
Given this specification the
designer can perform architectural design.
The HOS procedure can be split into three phases:
1.
Specify requirements according to a set of axioms.
2.
Feed specifications
Designer Analyzer
into the
and
Structuring Executive Analyzer.
3.
Produce architectural layers.
HOS provides
a metalanguage
specify the requirements.
called AXES
with which
to
The metalanguage is based on six
They are as fol-
axioms to which the designer must adhere.
lows:
1.
A given module controls the
invocation of the set of
and only its imme-
valid functions on its immediate,
diate, lower level.
2.
A given
module is responsible
for elements
of only
its own output space.
3.
A given module controls the access rights to each set
of variables whose values define
the elements of the
output space for each immediate,
and only each imme-
diate,
4.
lower level function.
A given module controls the access rights to each set
of variables whose values
define
the elements of the
input space for each immediate, and only each immediate, lower level function.
5.
A given
module can
reject invalid
own, and only its own, input set.
elements of
its
40
6.
A given module controls the ordering of each tree for
the immediate, and only the immediate, lower levels.
are specified in AXES,
After the requirements
fed into the analyzers.
of the axioms
The
they are
analyzers check for violation
The
in the specifications.
Design Analyzer
checks for static consistency, and the Structuring Executive
Analyzer checks for dynamic consistency.
study can be done in
In addition to consistency checks,
the following areas:
Fault tolerance, error detection, tim-
ing and accuracy, security requirements, system reliability.
Having the analyzed specifications,
gin the architectural
design.
the designer can be-
In this phase
the designer
the available
develops a
system architecture and allocates
resources.
The architecture is constructed in layers, simi-
lar to the concept of a hierarchy of abstractions.
resources
are allocated
to the system components
Resource Allocation Tool (RAT).
Then the
using the
The RAT uses the architec-
tural form to analyze the target system in terms of time and
memory optimization.
An optimal
module configuration
is
produced by the RAT.
3.5.3
The
Logical Construction of Programs
LCP philosophy
[WARN74] is
should be derived from the
CLCP)
that program
structure
input and output data structures
(similar to Jackson's methodology).
The data structures are
constructed from three basic elements:
Sequence, Iteration,
41
pressed in a
the data structures
Furthermore,
and Selection.
hierarchical format called the
are ex-
data structure
diagram.
structs a flow chart.
The flow chart would express the logThe chart is then
ical sequence of actions to be performed.
translated
into an
designer con-
the
structures,
the data
Having defined
instruction list,
which finally
gets
translated into code.
LCP does not provide a
step by step procedure,
however,
the following steps are implied:
1.
Define input and output data structures.
2.
Construct a flow chart based on the data structures.
3.
List operations to
be performed by each
part in the
flow chart.
4.
Translate the list of operations into code.
The LCP data
structure diagram is based
on the building
blocks shown in figure 7.
The data
structure diagrams
into a flow chart.
of nodes.
can be
directly translated
The sequence element becomes a sequence
The iteration element becomes a loop and the se-
lection element becomes a decision box.
Finally,
the designer generates a list of operations for
each node in the flow chart.
tended to be a buffer from
the designer
code.
By
had translated
The list of operations is inthe confusion which may occur if
the flow
listing all the operations
chart directly
for each box
into
of the
l
litem
item lItem
(n
Item
Item 21
timves)
-tn
-tn
Item 2
SELETION
ITERATION
.SEQUENCE
Figure 7:
Data Structure Definition for LCP
L-------------------------------------------------------------------------------------
the designer can take the design one step lower
flow chart,
in detail without
of a pro-
being tied down by the details
gramming language.
3.5.4
WELLMADE
The primary goal of WELLMADE is to add a mathematical dimension to the conventional top-down approach.
ers of WELLMADE
[BOYD78] claim
The design-
that the major difficulty in
software development is the lack of mathematical discipline.
Therefore,
WELLMADE has focused
on proving the correctness
of a program.
- The general approach to proof
of correctness is based on
Dijkstra's idea of predicate transformer
ly,
a program can be regarded
[BOYD781.
Basical-
as a transformation of input
43
one
this point of view,
From
into output.
can then work
backwards from the output states and derive all the possible
inputs under
the transformation.
statement of all output states
of the transforms
space,
is needed.
do this
To
an explicit
and a mathematical statement
resulting input state
If the
contains the speci-
derived from the above process,
fied legal input states, then the program performs correctly
for all legal inputs.
In terms
of system
layered design.
wise refinement.
architecture,
WELLMADE
advocates a
The concept is similar to the idea of stepfrom a highly abstract
The design begins
machine with abstract data and abstract program declaration.
are decomposed in
Then the modules
in the abstract machine
greater detail.
Often the decomposition results in another
The decomposition
abstract machine.
shion until
a level
of detail is
continues in this fa-
reached where
coding is
possible.
There are
only two phases
in the
WELLMADE methodology.
They are applied repetitively until the design is finished.
1.
Requirement Specification,
2.
Program Design.
WELLMADE does
not have
its own
specification language.
However, the following features are needed in the specification in order to prove correctness:
1.
Be able to represent assertions, predicates,
program
states, invariant relationships and requirements.
44
2.
Include first-order predicate calculus.
3.
Include notations for describing data types.
4.
Be able to record performance information.
WELLMADE does not
sign.
There is,
provide a method to
decompose the de-
instead, a program design language for rep-
resenting detailed procedural logic and data structures.
.Chapter IV
AN EXPERIMENT IN SYSTEM DESIGN
In this chapter,
four different designs of a text editor
produced by four different design methodologies are presented.
a
The purpose of this exercise is twofold.
learning experience
into design.
intended to
First, it is
increase one's
the experiment provides a
Secondly,
insight
way to
compare different methodologies in a concrete manner.
The target system for the
experiment is a stream editor.
In this system, text is considered as a sequence
of characters.
feed are just
(or stream)
carriage return and line-
In other words,
characters which produce a
special effect on
the screen.
The rest of the chapter is organized as follows:
one is a list of user requirements for the editor.
two specifies the data
structures.
Section
Section three explains
Section four contains the ac-
documentation of the designs.
tual designs.
Section
Finally, section five is a comparative evalu-
ation of the methodologies.
-
45
-
REQUIREMENTS FOR A STREAM EDITOR
4.1
The following requirements were derived for an experimenThat is,
tal system.
the target system does not have realInstead, the terminal is
time interaction with a terminal.
Also, the target sys-
simulated by a matrix of characters.
tem is intended to be
not include
Lastly,
therefore we did
device independent,
any specific
operating system
PL/I was thosen as a
considerations.
model language for the design
to provide the necessary data structures.
1.
the view
should support
The system
that text
is a
stream of characters.
2.
The
design shall
be independent
of any
particular
system.
3.
The programming language is PL/I compatible.
4.
The screen is represented by an 80x30 matrix of characters.
5.
The editor shall accept the full set of Ascii characters.
6.
A portion of the text is
displayed on the screen au-
tomatically.
7.
A cursor
shall be provided
to indicate
the current
point of reference.
8.
Text
is
automatically inserted
after
the
cursor,
there is no need to issue an insert command.
9.
The editor shall have an
the text.
internal buffer for storing
10.
Multiple editor commands can be issued in sequence.
11.
Text input and command input
12.
Multiple
i).
(e.g.,
trol character
are
editor commands
That
characters.
are separated by a con-
command is
every individual
is,
control
separated by
preceeded by a control character.
13. Editor commands are preceeded by a control character.
14.
The following commands should be implemented:
a) Read File - Format is
"@r <file-name>".
in the in-
the content of a file
mand will store
This com-
ternal buffer of the editor.
b) Write File
-
is "3w
Format
<file-name>".
This
command will write the content of the editor's internal buffer onto a file.
c) Character Forward -
Format is "@cf".
This command
moves cursor to the next character.
d) Character Back
-
Format
is "@cb".
This command
moves the cursor back by one character.
e) Character Delete removes
(i.e.,
Format is "@cd".
from
current character
the
This command
the
buffer
the character pointed to by the cursor).
f) Word Forward:
Format is "awf".
This command moves
the cursor to the first character of the next word
(words are delimited by a space).
g) Word Back:
Format is
"@wb".
This command moves
cursor to the last character of the previous word.
48
This command re-
"@wd".
Format is
h) Word Delete:
buffer beginning
current word from the
moves the
at the cursor.
Format is
i) Next Line:
the cursor to the line
carriage re-
Cursor is left in the same relative posi-
turn).
tion,
immediately after the cur-
are delimited by a
(lines
rent line
This command moves
"ilf".
unless the previous line is too short.
put at the
case the cursor is
the latter
In
end of
the previous line.
Format is
j) Previous Line:
moves the
cursor to the line
the current line.
same rules as
k) Delete Line:
moves the
command
This
"alb".
immmediately
before
Cursor positioning follows the
alf.
Format is
This command re-
"ald".
buffer beginning
current line from the
at the cursor.
1) Top of File:
the cursor to
Format is "@t".
This command moves
the current
the first character in
buffer.
m) Bottom of
File:
Format
is "ab".
This command
moves the cursor to the last character of the current buffer.
n) String Search:
Format is "as <String>".
mand will place the cursor
This com-
at the first character
of the next occurrence of <String>.
49
o) String
Search
will
This command
<New-string>".
for <String>,
do a
String
replace <String>
then
cursor is
The
<New-string>.
<String>
"cur
is
Format
Replace:
left at
by
the first
character of the replaced string.
p) End:
Format is "@e".
This command terminates the
editor program.
DATA STRUCTURES
4.2
During this phase of the design process,
the data struc-
the system are identified.
There are two
tures needed by
types of data objects:
ments.
position indicators and storage ele-
The need for storage elements
the systems.
store the text.
First,
arise in two parts of
there must be an
internal buffer to
Secondly, the screen must hold a portion of
the text at all times.
Therefore the matrix which simulates
the screen is also a storage element.
Each of the storage elements
cator.
also needs a position indi-
Therefore a cursor is used
his position on the screen.
to indicate to the user
A cursor is also needed to in-
dicate to the system its position within the buffer.
The
specific requirements
subsections.
are stated
in the
following
Internal Buffer
4.2.1
First,
Two issues arise in the design of a buffer.
buffer contents from/to datasets
system must read/write the
access facilities available in
Therefore file
(or files).
PL/I must be considered.
Secondly, the kinds of buffer opFurther-
erations used by the system has to be considered.
more,
the buffer
the
should be designed in such a
way so that
these operations can be performed efficiently.
kinds of
Two
PL/I:
Stream I/O and Sequential I/0.
which in
in
Stream I/O views text
Sequential I/0 is record ori-
as a sequence of characters.
ented,
are available
facilities
file access
means that
this case,
read/write is done
line by line.
The kinds of
are insertion and text editing.
any special
treatment because
terminal would
Editing of text,
sponse time.
Three types of
however,
from the
computer's prorequires
fast re-
(see figure 8).
line linked structure for the
This structure gives a close representation of text
a close resemblance to reality).
the terminal is selected to
proach.
of input
character linked structure, word linked struc-
The final selection is the
(i.e.,
the rate
structures are considered for
ture, and line linked structure
buffer.
Insertion does not require
compared to the
be so slow
cessing rate.
the buffer:
will be doing
buffer operations the system
Sequential I/O
Stream input from
support the stream oriented ap-
is selected for file
tions because the buffer is record oriented.
access func-
r -----------------------------------------------------Character
T
Linked:
H.--
BUFFER
A
s
THISE
Lne d :
**
THIS IS A BUFFER
I
Line
|
Linked:
Three Different Buffer Structures
Figure 8:
The basic component of the line linked buffer is the line
structure.
The line structure has two pointers,
line structure and the other
to the previous
next
The storage
line structure.
longer than 80 characters,
then the
and the remainder of the line
(this
is
status
bit
line structure
words,
the
string of characters
of the
capacity
line
the user inputs a line of text
If
screen.
points to the
This number is chosen to match
structure is 80 characters.
the width of the
one points
status bit will be set
will be continued on the next
referred
to as overflow).
indicates whether or
In
other
not the stored
ends with a carriage-return
character.
4.2.2
Buffer Position Indicator
In order to position the cursor at any point in the buffer,
two things are necessary:
a pointer to the line struc-
ture, and an offset indicating the position of the character
within the text string.
more pointers
are
the buffer and
Also, for efficiency reasons,
added.
The first points to
the other points to the
tail.
two
the head of
Finally,
a
three element array is provided
to record incremental move-
ments of the position indicator
(This will expedite the re-
positioning of the cursor on
the screen).
The "inc"
array
is used only by Jackson's methodology and Structural Design.
The position indicator will be called "BUFFER".
dcl BUFFER
1 line-ptr ptr
1 offset
fixed binary
1 head ptr
1 tail ptr
1 inc
4.2.3
array(3)
Simulated Screen
The screen is simulated by an 80x30 matrix.
In PL/I this
is represented by a string array with 80 elements.
ement is a string of
30 characters.
Each el-
4.2.4
Screen Position Indicator
Associated with the screen is
a position indicator which
points to the user's current position on the screen.
simply 2 integers.
The first
It is
integer represents the hori-
zontal position (the x-coordinate),
and the second integer
represents the vertical position (the y-coordinate).
dcl SCREEN
1 scr string(30) array(80)
1 x-coord fixed binary
1 y-coord fixed binary
4.2.5
The Package Structure
In order to simplify the passing of the above data structures, the package data structure is creatd.
ments:
a pointer to a BUFFER structure,
It has 2 ele-
and a pointer to a
SCREEN structure.
dcl PACKAGE
1 Buff-ptr ptr
1 Scr-ptr
4.3
ptr
DESIGN REPRESENTATION
The system designs are described in three different ways:
DARTS call graph, DARTS trees,
DARTS call graphs are used
and functional descriptions.
to describe system architecture.
DARTS trees are used to describe the logic with the modules.
Functional description specifies the name of the module, the
parameter and the module's functions.
54
Each of
techniques will
the above design representation
be discussed in the ensuing
In the remainder
subsections.
of this introductory section, a general description of DARTS
is presented.
(DARTS)
Design Aids for Real-Time Systems
Draper Laboratory.
veloped at the C. S.
in the definition
of computer systems.
increase productivity,
and improve
is a tool de-
It is used to aid
It
is intended to
quality and efficiency.
In order to accomplish this, DARTS provides diagrams and tables to document the design, consistency checks, quality metrics,
and simulations.
DARTS represents
describe a
systems as trees.
set of communicating entities
These
design trees
called processes,
consists of nested sequential
control logic.
This scheme encourages top-down development,
and structured
each of which
The hierarchical
control flow.
tree structure also allows
the design to be viewed from different levels of detail.
4.3.1
DARTS Call Graph
A call graph is a graph which describes the communication
between modules.
of the system.
gular boxes.
Thus,
it also describes the architecture
The graph consists of interconnected rectanEach box represents a module,
box is the name of the module.
and inside the
Two boxes are connected by a
line if one module calls the other.
55
4.3.2
DARTS Trees
To describe the logic of a module,
DARTS provides an hiBasically,
the de-
signer describes his design using three components:
the it-
erarchical tree structured technique.
erator,
the selector and the
each type of component is self
sequencer.
evident.
The functions of
The DARTS tree is
represented graphically by elliptical shapes in figure 9.
------------------------------------------------------------
14.3
0 0 e
Sequencer
*
(Do tasks 1 through n sequentially)
142.3
*0
*0
Iterator (Do tasks 1 through n repetitively until
the stopping condition is satisfied)
Selector (The if-then-else selector)
Figure 9:
----------------
DARTS Tree Components
------------------------
------
-------
Functional Description
4.3.3
In addition to the graphical representations, each module
in terms of
is described
its parameters and
function.
A
freehand format is used, the following is an example:
Module name:
Parameter:
Print
<filename>
Function: Place a copy of file <filename> in the
printer queue.
EDITOR DESIGNS
4.4
As was
mentioned earlier,
are used for this design
different methodologies
four
They are the Jackson
experiment.
Methodology, Structured Design, Systematic Design, Systematic Design Methodology and the Hierarchical Development Methodology.
A problem that is immediately
from biasing results of
earlier designs
later.
apparent is how to prevent
methodologies used
Certainly design is a refinement process, therefore,
having thought
through a design
once would
surely improve
the quality and efficiency of the second design.
nate this bias would be impossible,
maintained by strict adherence to
each methodology.
Furthermore,
To elimi-
but some control can be
the procedures defined by
the order they are used is
HDM, Jackson, SD and SDM, where HDM is the methodology which
is
the least
mechanical.
58
The following subsections present briefly the design profor each methodology.
cess
tion technique and
Then a discussion of the evalua-
the results of the
evaluations are pre-
sented.
4.4.1
Hierarchical Development Methodology
HDM consists
of 7
Then the
specified.
First
the requirements
are
machines are
top and bottom abstract
This is followed by the specification of the in-
specified.
termediate machines.
chine is
steps.
Then the data structures for each ma-
determined and- the
operations of each
machine is
implemented as a program on the next lower machine.
Lastly,
the abstract machines are translated into a programming language.
First,
HDM does not
we identify the abstract machines.
provide any guidelines for doing this, therefore a trial and
error method is used to derive the hierarchy of abstract machines shown in figure 10.
The data representation for each machine is self evident.
Each of the abstract machines
is further modularized.
EDITOR machine consists of 17 modules.
A DISPATCH, and one
module for each editor command (see figure
The BUFFER machine
the buffer.
11).
consists of modules which
They are divided into five types:
12).
operate on
Constructors,
Selectors, Mutators, Testers, and Cursor Movers.
ure
The
(see fig-
------------------------------
SCPEEN MACHINE
I
Figure
HDM's
10:
Abstract Machines for the Editor
I
L--------------------------------------------------------------------------------------.
------------------------------------------------------------
Figure 11:
I
EDITOR Machine
------------------------------------------------------------
The SCREEN
machine provides operators to
screen (see figure
13).
manipulate the
The entire architecture is shown in
figure 14.
The DARTS tree representation for
ules
is given.
straightforward,
given for them.
Many of
the BUFFER
a selected set of modmachine modules
are
therefore only functional descriptions are
I---------------------------------------------------------- I
SF'TEC'IOPS
CONSTRUCIORS
CREATE
BUFF
CRFATE
LINE
COPY
BUFF
CURSOR MOVERS
TESTERS
MUTATORS
PUT
TEXT
ADD
EMPTY
LINE
BUFF
EMPTY?
LINE
EMPTY?
LINE
EWD
LINE
BACK
CHAR
FWD
LINE
DLT
CHAR
DLT
HEAD?
TAIL?
CHAR
BACK
FIRST
LINE
LAST
LINE
Figure 12:
BUFFER Machine
------------------------------------------------------------
------------------------------------------------------------
FILL
SCREEN
FIX
CURSOR
Figure 13:
---------------------------------------------
FILL
LINE
SCREEN Machine
-------------
61
Module Name:
Parameter:
Function:
EDITOR
none
Get a word from the input stream, and dispatch.
Module Name:
Parameter:
Function:
DISPATCH
PACKAGE, WORD
Dispatch WORD to the appropriate subroutine.
52J2-2
63
.Module Name: INSERT
Parameter:
PACKAGE, WORD
Function:
Insert WORD before the cursor.
Module Name:
Parameter:
Function:
READ
PACKAGE, FILENAME
Insert contents of file
sor.
FILENAME before the cur-
Module Name:
WRITE
Parameter: PACKAGE, FILENAME
Function:
Copy the entire buffer into a file under FILENAME.
A.
Module Name:
CHeAR-FWD
Parameter: PACKAGE
Function: Move
cursor
forward
one
character
(Just
call
BUFF-CHAR-FWD).
Module Name: CHAR-BACK
Parameter:
PACKAGE
Function: Move
cursor
back
one
character
(Just
call
BUFF-CHAR-BACK).
Module Name:
Parameter:
Function:
CHAR-DLT
PACKAGE
Delete character
pointed to
call BUFF-CHAR-DLT).
by the
cursor
(Just
67
Module Name:
WORD-BACK
Parameter: PACKAGE
Function: Move cursor to the tail of the previous word.
68
Module Name: WORD-FWD
Parameter:
Function:
PACKAGE
Move
word.
PACKAGE's cursor
to the
head
Uses buffer machine operators.
of the
next
69
Module Name: WORD-DLT
Parameter:
Function:
PACKAGE
Delete everything between the
space.
cursor and the next
Module Name: LINE-FWD
Parameter: PACKAGE
Function: Move cursor to the next line.
short,
the
cursor is placed
line.
W..3
5a
TP-
BUPP--
GET-Tr-BEf
CALL BUFM-
LINU-FW
TKMP2- BUFM-
GEf-TEZ
If next line is too
at the tail
of the
Module Name:
Parameter:
Function:
LINE-BACK
PACKAGE
Move cursor
to the
previous line.
If
previous
line is too short, cursor is placed at the tail of
the line.
0=1O4
TEMP1-BUFFGBT-TEIT-BEF
CALLBUFFIM-BACK
TEMP2- BU2FGfr - TK
5.HA2
Module Name: LINE-DLT
Parameter: PACKAGE
Function:
Delete everything
line.
from cursor to
the end
of the
If line is empty, remove it from the buff-
er.
5..2
73
Module Name: TOP
Parameter:
Function:
PACKAGE
Place cursor at the first character of the buffer.
Module Name:
Parameter:
Function:
BOTTOM
PACKAGE
Place cursor at the last character of the buffer.
Module Name:
Parameter:
Function:
SEARCH
PACKAGE, STR
Find first occurrence of STR after cursor.
cursor at the head of STR.
)NJf= CURB==4
)
TRMP-BUFFV-
Place
Module Name:
Parameter:
Function:
REPLACE
PACKAGE, STR1,
STR2
Replace the first occurrence
by STR2.
Ma=a
of STR1
after cursor
Module Name:
CREATE-BUFF
Parameter: none
Function:
Return a pointer to a buffer structure.
Module Name:
Parameter:
Function:
COPY-BUFF
PACKAGE
Return a
pointer to a
copy of the
buffer struc-
ture.
Module Name:
Parameter:
Function:
CREATE-LINE
none
Return a pointer to a line structure.
Module Name: BUFF-GET-TEXT
Parameter:
Function:
PACKAGE
Return the contents of the current line.
Module Name:
Parameter:
Function:
PACKAGE
Return text string before the cursor.
Module Name:
Parameter:
Function:
BUFF-GET-TEXT-BEF
BUFF-GET-TEXT-AFT
PACKAGE
Return text string after the cursor.
Module Name:
Parameter:
Function:
BUFF-PEEK-FWD
PACKAGE
Return the next character
without moving the cur-
SOX.
Module Name: BUFF-PEEK-BACK
Parameter:
Function:
PACKAGE
Return the
cursor.
previous character without
moving the
Module Name: BUFF-PUT-TEXT
Parameter: PACKAGE, STR
Function:
Insert STR after the cursor.
Module Name:
ADD-EMP-LINE
PACKAGE
Paramerter:
Function: Add an empty line after the current line.
Module Name:
BUFF-LINE-DLT
Parameter: PACKAGE
Function:
line of text beginning
Delete the current
at the
cursor, then merge with the next line.
Module Nante:
Parameter:
Function:
BUFF-CHAR-DLT
PACKAGE
Remove character
function
at the
and
cursor.
Use
substring
Call
concatenation.
SCREEN-FILL-LINE.
Module Name:
Parameter:
Function:
BUFF-LINE-EMPTY?
PACKAGE
Return true
if contents
null string.
Module Name:
BUFF-BUFF-EMPTY?
Parameter: PACKAGE
of current
line is
the
Function:
Return true if there is nothing in the buffer.
Module Name:
Parameter:
Function:
BUFF-HEAD?
PACKAGE
Return true if cursor points
to the first charac-
ter in the bufer.
Module Name:
Parameter:
Function:
BUFF-TAIL?
PACKAGE
Return true if cursor points to the last character
of the buffer.
Module Name: BUFF-LINE-FWD
Parameter:
PACKAGE
Function: Move cursor to the next
mains the same unless the
If the latter
line.
Cursor offset re-
next line is too short.
is true then put cursor
at the end
of the next line.
Module Name:
Parameter:
Function:
BUFF-LINE-BACK
PACKAGE
Move cursor to the previous line.
Cursor position
follows the same rules as BUFF-LINE-FWD.
Module Name:
BUFF-CHAR-FWD
Parameter:
Function:
PACKAGE
If re-
Increment the offset of current line by 1.
line boundary,
sult crosses
length of previous line,
and current line pointer
call
Finally,
line.
previous
to
offset to
then set
SCREEN-MOVE-CURSOR.
Module Name: BUFF-CHAR-BACK
Parameter: PACKAGE
Function:
Decrement
the offset.
boundary,
then put
previous line.
Module Name:
Parameter:
Function:
Function:
result crosses
the cursor at the
line
end of the
Call SCREEN-MOVE-CURSOR.
BUFF-FIRST-LINE
PACKAGE
to the
pointer to
Set current
lihe pointer
first line.
Call SCREEN-FILL-SCREEN.
Module Name:
Parameter:
If
the
BUFF-LAST-LINE
PACKAGE
Set current
line.
Module Name:
line pointer to
to last
Call SCREEN-FILL-SCREEN.
SCREEN-CREATE-SCREEN
Parameter: none
the pointer
Module Name: SCREEN-MOVE-CURSOR
Parameter:
Function:
PACKAGE, X, Y
Add X to horizontal index,
and add Y to vertical
index.
Module Name:
Parameter:
Function:
SCREEN-FILL-SCREEN
PACKAGE
Refill the screen.
dle.
Place current line at the mid-
Jackson Methodology
4.4.2
As was stated
in chapter 3,
methodology con-
Jackson's
sists of 3 steps:
1.
Define the input and output data structures.
2.
Transform
the data
structures
into program
struc-
tures.
3.
List the program tasks as executable operations,
and
allocate each task to a program component.
output data structures for
The input and
as shown in figure
the editor are
15.
There is a structure clash between the input and the outHowever, there is a substructure which
put data structures.
both the
output share
input and
-
the
text substructure.
We can use
This leads us to the buffer structure directly.
the program
ture:
to contruct
inversion technique
Input
the architec-
Output
Buffer
separates the problem into
Program Inversion
two parts.
The first part deals only with the transformation from input
into the buffer.
The second part deals
with transforming
the buffer to output.
The input.conversion can be
ture shown in figure
16.
handled by the system struc-
Notice
gous to the "Command" substructure
ture.
that it is exactly analoof the input data struc-
n
-----------------------------------------------------------
Jackson System Input Data Structure
Jackson System Output Data Structure
I
Figure
15:
Jackson's Input and Output Data
L--------------------------------------------------------------------------------------
r-------------------------------------------------------------------I
Figure
16:
Jackson's Input Handler
-----------------------------------------------------------
gtructures
85
The output
handler is
contructed from
the output
data
structure as shown in figure 17.
---------------------------------------- -------------------
Figure
17:
Jackson's Output Handler
L----------------------------------------------------------
The entire
system architecture. is shown
in figure
18.
Detailed design is done with DARTS.
The logic of each mod-
ule is displayed using DARTS Trees.
They are listed in the
following pages.
Module Name:
EDITOR
Parameter:
none
Function:
Coordinates activities between input and output.
3.L3
Module Name:
INPUT-HANDLER
Parameter:
PACKAGE, INSTREAM
Function:
Dispatch on the type of the input string.
If in-
then call DISPATCH,
other-
put word is a command
wise call INSERT.
3=1
NuT-CffAR-UAM-4AR
TnAYYAAD
3=22
89
Module Name: INSERT
Parameter: PACKAGE, INSTREAM
Function:
Driver-loop for insertion of words one at a time.
90
Module Name:
Parameter:
Function:
INSERT-WORD
PACKAGE, WORD
Add word to the buffer.
Put PACKAGE's cursor at
the end of WORD.
3.4
iDTRt-WpiD
WORDT-OR
I--
91
Module Name: DISPATCH
Parameter:
Function:
COMMAND, PACKAGE, INSTREAM
Dispatch the command
processor.
to the appropriate command
Module Name:
OUTPUT-HANDLER
Parameter: PACKAGE
Function:
Determine whether
to refill
one
screen or refill the entire screen.
line of
Also coordi-
nates the adjustment of the screen cursor.
3.4,
3Aw2
the
93
Module Name:
Parameter:
Function:
REFILL-LINE
PACKAGE
Copy
the current line
.nto the screen.
of text from
the buffer
94
Module Name:
REFILL-SCREEN
Parameter:
PACKAGE
Function:
Refill the screen array, placing the current line
at the middle of the screen.
95
Module Name:
Parameter:
Function:
FIX-SCREEN-CURSOR
PACKAGE
If refill status is 0 or 1 the adjust the xcoordinate.
if
it is 2
(middle of the screen),
before.
then set ycoordinate
to
15
and adjust xcoordinate as
96
Module Name:
READ
Parameter: PACKAGE, FILENAME
Function:
Copy the contents of the file into the buffer.
Module Name: WRITE
Parameter:
Function:
PACKAGE, FILENAME
Copy
the
entire
buffer
FILENAME.
__WRITI
3M-u
*nITPAE
oi'zr nrz, PUT
CUM AT EAD
OF BUFME
LOOPUPUT
I"D OF BUYI
into
a
file
under
-Module Name: CHAR-FWD
Parameter:
PACKAGE
Function:
Move cursor position forward one character.
~2Z
99
Module Name: CHAR-BACK
Parameter: PACKAGE
Function:
Move the cursor position back one character.
100
Module Name:
CHAR-DLT
Parameter:
PACKAGE
Function:
Remove the character pointed to by the cursor.
343
101
Module Name: WORD-FWD
Parameter:
Function:
PACKAGE
Move
cursor position
to the
head of
word.
aWs
the next
102
Module Name:, WORD-BACK
Parameter: PACKAGE
Function:
Move the cursor position to the tail of the previous word.
:us
103
Module Name:
Parameter:
Function:
WORD-DLT
PACKAGE
Remove the string of non-space characters beginning at the current position
character.
until the next space
104
Module Name:
LINE-FWD
Parameter:
PACKAGE
Function:
Move cursor to the next line. The offset does not
change
short.
unless the
length
next line
of
In the latter case,
is
too
the cursor is placed
at the tail of the next line.
131&=
105
-nodule Name:
Parameter:
Function:
LINE-BACK
PACKAGE
Move
cursor to the
previous line.
Offset un-
changed unless text on previous line is too short.
13.19
106
Nodule Name:
M
Parameter:
Function:
LINE-DLT
PACKAGE
Deletes text
line.
from the cursor to the
Cursor is left where it was.
line to the remainder of current line.
end of the
Adjoin next
107
Module Name: TOP
Parameter:
PACKAGE
Function:
Place cursor at the head of the buffer.
108
Module Name:
BOTTOM
Parameter:
PACKAGE
Function:
Place cursor at the end of the buffer.
109
Module Name:
Parameter:
Function:
SEARCH
PACKAGE, STRING
Place cursor at the
of string oafter
end of the first occurrence
the cursor.
leave cursor alone.
If not
found then
110
Module Name:
REPLACE
Parameter: PACKAGE, STR1,
Function:
STR2
Find STR1 using SEARCH, and replace STR1 by STR2.
If not found then nothing happens, if found,
cursor is placed at the head of STR2.
1z"*
TBW
RIWLAW
"II
then
111
4.4.3
Structured Design
consists of two simple
Structured Design
translate the design problem into
ond,
steps.
a data flow graph.
First
Sec-
Analysis or Transaction Analysis
use either Transform
to create the architecture.
The data flow graph is as shown in figure
This
DFG is
a selection
among different
Therefore Transaction Analysis is used
19.
alternatives.
to construct the ar-
chitecture.
r.--------------------------------------------------------------------------------------
MMDY
BUFFER
CUPSOR
MOVE
SCREEN
CURSOR
INPUT
STREAMl
MODIFY
SCIEE
MODIFY
BUFFER
Figure
DFG for the Editor
19:
L--------------------------------------------------------------------------------------
The transaction center is the bubble "Input Stream", because
at that point
ferent paths.
the input data stream branches
The
three input bubbles can
to three difbe replaced by
the dispatch architecture in figure 20.
Now the DFG reduces to a
21),
sequence of bubbles
(see figure
and we can use Transform Analysis to derive the archi-
tecture for the remainder of
the system.
tecture thus derived is shown in figure 22.
The entire archi-
112
n
-----------------------------------------------------------
Figure 20:
The Transaction Architecture
-----------------------------------------------------------
n
-----------------------------------------------------------
MOVE
BUFFER
CURSOR
IINPUT
STREAM
/
s
MODIFY
SCREEN
'
MOVE
SCREEN
CURSOR
BUFFER
Figure 21:
The Reduced DFG
I----------------------------------------
The detailed design of each module
ing subsection.
ing modules in
-------------------
is listed in the follow-
Many of the modules are similar to correspondJackson's editor design,
therefore
lected group have been illustrated with DARTS Trees.
all of the modules are described functionally.
only a seHowever,
114
Module Name: EDITOR
Parameter:
Function:
none
Input-output driver loop.
.-.
.-
-.
-.
--
..
.J
&L3
CALLI M-
CA LLROW ,L-
GEwoUD(IsmR1Jo
4TRMP-
115
Module Name:
Parameter:
Function:
INSERT
PACKAGE, WORD, INSTREAM
Read text from
instream and insert them
into the
buffer, until a command is encountered.
9.3,3U
116
Module Module Name: MODIFY-BUFFER
Parameter:
Function:
COMMAND, PACKAGE
Dispatch Command to the appropriate subroutine.
117
Name:
INSERT-WORD
Parameter: WORD, PACKAGE
Function:
Add WORD
into existing buffer.
WORD is
placed in
front of the cursor.
Module Name: READ
Parameter:
Function:
PACKAGE, FILENAME
Copy the contents of the file into the buffer.
Module Name: WRITE
Parameter:
Function:
PACKAGE, FILENAME
Copy the entire buffer into a file under FILENAME.
Module Name:
Parameter:
Function:
Function:
CHAR-DLT
PACKAGE
Remove the character pointed to by the cursor.
Module Name:
Parameter:
.
WORD-DLT
PACKAGE
Remove the
string of non-space
at the current position until
ter.
Module Name: LINE-DLT
Parameter:
PACKAGE
characters beginning
the next space charac-
118
Function:
Deletes text from the cursor to
Cursor is left where it was.
the end of the line.
Adjoin next line to the
remainder of current line.
Module Name:
Parameter:
REPLACE
PACKAGE, STR1,
STR2
Function: Find STR1 using SEARCH, and replace STR1 by STR2.
not found then nothing happens,
if found, then cursor
is placed at the head of STR2.
Module Name: MOVE-PACKAGE-CURSOR
COMMAND, PACKAGE
Parameter:
Function:
Dispatch COMMAND to the appropriate subroutine.
Module Name:
Parameter:
Function:
Parameter:
Function:
CHAR-FWD
PACKAGE
Move cursor position forward one character.
Module Name:
CHAR-BACK
PACKAGE
Move the cursor position back one character.
Module Name: WORD-FWD
Parameter:
Function:
If
PACKAGE
Move cursor position to the head of the next word.
119
Module Name: WORD-BACK
Parameter:
PACKAGE
Function: Move the cursor position to
the tail of the previous
word.
Module Name:
Parameter:
Function:
LINE-FWD
PACKAGE
Move cursor
to the next
change unless the
In the latter case,
line.
The offset
length of next line
does not
is too short.
the cursor is placed at the tail
of the next line.
Module Name:
LINE-BACK
Parameter: PACKAGE
Function: Move cursor
to the previous line.
Offset unchanged
unless text on previous line is too short.
Module Name:
Parameter:
Function:
TOP
PACKAGE
Place cursor at the head of the buffer.
Module Name:
BOTTOM
Parameter: PACKAGE
Function:
Place cursor at the end of the buffer.
120
Module Name:
Parameter:
Function:
SEARCH
PACKAGE, STRING
Place cursor
at the end
string after
the cursor.
of the first
If
occurrence of
not found
then leave
cursor alone.
Module Name: FIX-SCREEN-CURSOR
Parameter:
Function:
PACKAGE
Fix the x
and y coordinates of
the screen's cursor.
Use the information in the status codes.
Module Name:
Parameter:
Function:
REFILL-SCREEN
PACKAGE
Fill the screen with 30 new lines of text.
The line
pointed to by buffer's cursor is ilaced in the middle
(i.e.,
the
15th line).
121
4.4.4
Systematic Design Methodology
SDM can be
steps.
simplified to 4 basic
Then assess the interde-
the requirements using templates.
pendencies between requirements.
First specify
Next, apply the clustering
algorithm to the interdependencies.
Finally, create an ar-
chitecture from the clusters.
The requirements
4.1.
have already been specified
in section
However, in order to use the clustering program,
requirements are replaced by integers from
1 to 29.
the
The in-
terdependency assessments are given in appendix A.
The resulting clusters are as
follows
(also see Appendix
B):
Cluster
1: 1,7,16,17,18,19,20,21,22,23,24,25,26,27,28.
Cluster
2:
Cluster
3:
Cluster 4:
8,9,14,15.
10,11,12,13.
2,3,4,5,6.
The sub-clusters of cluster
1 are:
1:
16,19
(Char-fwd, Word-fwd).
Cluster 2:
17,20
(Char-back, Word-bacR).
Cluster 3:
18,21
(Char-dlt, Word-dlt).
Cluster
122
Cluster 4:
22,23,24,25,26,27,28
(Line-fwd,
Line-back,
Line-dlt, Top, Bottom, Search, Replace).
After the clusters are determined,
ganize the clusters into a system.
vide any guidelines for the designer.
ily made to follow the
the designer must orHere SDM does not proA choice is arbitrar-
pipelined architecture of HDM
(i.e.,
data goes in one end and comes out the other, unlike Jackson
and SD which have a tree traversal type behavior).
The com-
plete architecture is shown in figure 23.
Detailed design is listed in
ever,
only a selected few have
general flavor of the design.
the following pages.
How-
been used to illustrate the
124
Module Name: EDITOR
Parameter:
Function:
none
Driver loop for
dispatch.
Read a word
stream and send it to dispatch.
C1A" BUFFE
scamW
GwrTRWOWDD3RM
V.1=Z
from in-
125
Module Name:
INSERT
Parameter: WORD, PACKAGE
Function:
Add WORD into existing buffer.
WORD is placed in
front of the cursor.
SAME1S 80
CHASINW
t
PUT Rnfr DMO
LM
(i(
fCALL MLCUemm
RznjiNEWu
126
Module Name: DISPATCH
Parameter:
Function:
PACKAGE, WORD
Send WORD to the appropriate command processors
Module Name:
Parameter:
READ
PACKAGE, FILENAME
Function: Copy the contents of the file into the buffer.
Module Name:
Parameter:
Function:
PACKAGE, FILENAME
Copy the entire buffer into a file under FILENAME.
Module Name:
Parameter:
Function:
Function:
CHAR-FWD
PACKAGE
Move cursor position forward one character.
Module Name:
Parameter:
WRITE
WORD-FWD
PACKAGE
Move cursor position to the head of the next word.
Module Name: CHAR-BACK
Parameter:
Function:
PACKAGE
Move the cursor position back one character.
127
Module Name:
WORD-BACK
Parameter: PACKAGE
Function: Move cursor to the tail of the previous word.
Module Name:
Parameter:
Function:
CHAR-DLT
PACKAGE
Remove the character pointed to by the cursor.
Module Name: WORD-DLT
Parameter:
Function:
PACKAGE
Remove the
string of non-space
characters begin-
until the next space
ning at the current position
character.
Module Name:
Parameter:
Function:
LINE-FWD
PACKAGE
Move cursor-to the next line.
change
short.
unless the
length
of
In the latter case,
at the tail of the next line.
Module Name:
Parameter:
LINE-BACK
PACKAGE
The offset does not
next line
is
too
the cursor is placed
128
Function:
Move cursor to the previous line. Offset unchanged
unless text on previous line is too short.
Module Name:
LINE-DLT
Parameter: PACKAGE
Function:
Deletes text
line.
from the
cursor to
of the
the end
Cursor is left where it was.
Adjoin next
line to the remainder of current line.
Module Name:
Parameter:
Function:
SEARCH
PACKAGE, STRING
Place cursor at the end of the first occurrence of
string oafter the cursor.
If not found then leave
cursor alone.
Module Name:
Parameter:
Function:
REPLACE
PACKAGE, STR1,
STR2
Find STR1 using SEARCH,
and replace STR1
by STR2.
If not found then nothing happens, if found,
cursor is placed at the head of STR2.
Module Name: TOP
Parameter:
Function:
PACKAGE
Place cursor at the head of the buffer.
then
129
Module Name: BOTTOM
Parameter:
Function:
PACKAGE
Place cursor at the end of the buffer.
Module Name:
Parameter:
REFILL-SCREEN
PACKAGE
Function: Fill the screen array with 30 new lines.
The line
pointed to by the buffer's cursor is placed at the
15th line.
Module Name:
Parameter:
Function:
REFILL-LINE
PACKAGE
Get the line
pointed to by buffer's
copy it into
the line pointed to
cursor,
and
by the screen's
cursor.
Module Name:
Parameter:
Function:
MOVE-CURSOR
)
X, Y
Replace the x and y
by X and Y.
coordinate of screen's cursor
130
DESIGN EVALUATION
4.5
The best way
to
judge the soundness of
Thus it is the object of this sec-
to examine its product.
reflect on the
tion to
the designs.
design methodologies
to obtain
clustering algorithm
SDM
graph
employs a
modules which
are strongly
and weakly dependent between modules.
dependent internally,
Therefore the
by evaluating
here is directly aimed at
The approach taken
Systematic Design. Methodology.
the
a methodology is
measure the designs
strategy is to
with re-
spect to the above criteria.
the evaluation
measures the strength
of each module's internal dependency,
and the looseness of
More specifically,
dependency between modules.
These measures are called mod-
ule strength and module coupling respectively
4.5.1
[Myer751.
Module Strength
The basic intent of module strength is to provide a measure of the cohesiveness of the module.
module is considered to be
Furthermore, if the
a functional transformation over
some data, then the task can be reduced to an examination of
the functionality and data structures of a module.
ample,
a module which performs
tion over
a single
strength than
a single well defined func-
data structure
one that
single data structure.
For ex-
clearly possesses
performs several
more
functions over
a
131
Thus the following ranking for classifying modules is attained (see
They are listed in order
[MYER75] chapter 3).
of increasing strength:
1.
Multiple and un-
Multiple functions related in time.
related data structures.
2.
Multiple
related over
functions logically
functions
(i.e.,
data structures
multiple
transforming from
one data structure into another).
3.
Single function over multiple data structures.
4.
Multiple functions over a single data structure.
5.
Single function over a single data structure.
4.5.2
Module Couplina
about one
are
another.
generally
how much
is determined by
Module coupling
three
global variables, data items
modules
(e.g.,
In the
arrays,
editors designed
there are no global variables.
can
communicate:
variables) passed as pa-
rameters, and data structures (e.g.,
as parameters.
languages there
In modern programming
ways that
modules know
trees)
passed
for this
thesis
The only forms of communica-
tion were direct passing of arguments and passing of control
information in the buffer structures.
Again a ranking is achieved by considering typical module
communication techniques
(see [MYER75] chapter 4):
of increasing amount of coupling).
(In order
132
Only data items are used,
1.
and they are all passed as
arguments.
Data structures
2.
are used,
(includes data items)
and
are all passed as arguments.
Control information is used (such as flags,
3.
function
code).
4.
One module references an
internally defined variable
of another module (e.g.,
free variables in dynamical-
ly scoped Lisp).
The designs
and two
are evaluated in
kinds of analysis
couplings per module.
are made:
/
average
design (i.e.,
number of couplings).
a measure of the complexity of
couplings /
module coupling,
coupling and
Average coupling is the average rank-
ing for the couplings in the
ranks
terms of
sum of coupling
Couplings per module provides
the design
(i.e.,
number of
number of modules).
The results of the evaluation are listed in the following
tables.
133
HIERARCHICAL DEVELOPMENT METHODOLOGY
Module Coupling
Module Strengthl
Module Namel
Editor
1
5
1 2- Dispatch
Dispatch
I
2
I 2x16- Each command
processor
Insert
I
5
I 2- Buff-get-text-bef
I 21 2| 2I 2-
Read
|
Write
Buff-get-text-aft
Buff-put-text
Buff-add-emp-line
Buff-line-fwd
3
1 2- Buff-add-emp-line
I 2- Buff-line-fwd
I 2- Buff-put-text
3
I 2- Buff-copy-buff
2I 2I 2I 2-
Buff-top
Buff-tail?
Buff-get-text
Buff-line-fwd
Char-fwd
I
5
I 2- Buff-char-fwd
Char-back
I
5
1 2- Buff-char-back
-'Char-deletel
5
1 2- Buff-char-delete
|
5
I 2- Buff-peek-fwd
Word-fwd
|
Word-back
I
Word-deletel
5
I 2I 2-
Buff-peek-back
Buff-char-back
5
I 22-
Buff-peek-fwd
Buff-char-delete
I 2-
Buff-get-text-bef
1|
Line-fwd
I
2- Buff-char-fwd
5
I 2- Buff-line-fwd
I 2- Buff-get-text
I 2- Buff-char-back
2222-
I
5
I
I
I
|
Line-deletel
5
I 2-
Line-back
| 2I 2-
Buff-get-text-bef
Buff-line-back
Buff-get-text
Buff-char-back
Buff-line-kill
Buff-line-empty?
Buff-get-text-bef
134
1 2- Buff-put-text
1
Top
I
5
I 2- Buff-first-line
I 2- Buff-get-text-bef
I
2- Buff-char-back
Bottom-
5
I 2- Buff-last-line
I 2- Buff-get-text-aft
I 2- Buff-char-fwd
Search
5
I 2- Buff-get-text-aft
I 2- Buff-line-fwd
I 2- Buff-get-text
I 2- Buff-tail?
Replace
I
4
I 2- Search
I 2- Buff-char-delete
I 2- Insert
1 -
1
Buffcreate-buffl
5
I
I
5
I
-
1
BuffCreate-linel
5
I
-
Buffget-text
I
I
5
I
-
Buff-gettext-bef
I
5
I
-
Buff-gettext-aft
I
I
5
I
-
Buff-puttext
I
5
I
-
Buff-peekfwd
|
5
I
I
-
Buff-peekback
I
5
I
I
-
Buff-linefwd
I
I
5
I 2- Screen-move-cursor
Buff-lineback
I
I
5
I 2-
Screen-move-cursor
Buff-linedelete
I
5
I 2I
Screen-fill-line
Buffcopy-buff
I
I
I
135
Buff-lineempty?
I
I
5
I
-
Buff-buffempty?
I
5
I
-
Buff-head?
I
5
I -
Buff-tail?
I
5
I -
Buff-charfwd
I
I
5
1 2- Screen-move-cursor
Buff-charback
I
I
5
I 2- Screen-move-cursor
Buff-chardelete
I
5
I 2- Screen-fill-line
I
I
Buff-first-I
line
I
5
I 2- Screen-fill-screen
Buff-lastline
I
I
5
I 2-
Screen-fill-screen
Buff-addemp-line
I
5
I 2-
Screen-fill-screen
ScreenCreate-scr
I
I
5
I
-
I
Screenmove-cursorI
5
I
-
Screenfill-line
I
I
3
I 2- Buff-get-text
Screenfill-screenl
I
3
I 2-
I
Number of Modules
Average Strength
Average Coupling
Coupling per Mod.
=
=
=
=
Figure 24:
Buff-get-text
44
4.71
2
1.7
Evaluation of HDM
136
JACKSON METHODOLOGY
Module Namel
Edit
I
Module Strengthl
1
Module Coupling
I 2- Input-Handler
I 2- Output-Handler
InputHandler
I
Insert
1
Insert-wordI
Dispatch
5
I 2- Dispatch
I 2- Insert
2
I 2- Insert-Word
4
1 3 Output-Handler
I
I
2
I 2x15- Each command
I
processor
4
I 3x15- Each command
I
processor
3
I
-
3
|
-
Fix-screen-I
cursor
I
3
1 -
Read
I
3
I 2- Insert-word
Write
1
3
1 -
Charforward
5
5
I
I
Char-back
1
5
I-
4
I
-
OutputHandler
I
I
Refill-line l
Refillscreen
I
I
Char-deleteI
I
-
Wordforward
I
I
5
I
Word-back
I
5
1 -
4
1 -
Word-deletel
Lineforward
I
I
5
|
Line-back
1
5
1 -
Line-delete 1
4
I -
-
137
Top
I
5
I
Bottom
1
5
1 -
Search
I
5
I
Replace
I
4
1I 2- Search
Number of Modules = 24
= 3.92
Average Strength
= 2.39
Average Coupling
Coupling per Mod. = 1.71
Figure 25:
-
-
(Sum of
number
(Number
number
couplings/
of couplings)
of couplings/
of modules)
Evaluation of Jackson's Methodology
138
STRUCTURED DESIGN
Module Strength! Module Coupling
Module Namel
1
Editor
I 2- Insert
I 2- Mod-buff
I
2- Move-buff-cursor
I 2- Fix-screen-cursor
I 2- Refill-screen
1
5
1 2- Insert-word
Insert-word!
1
4
I 3- Fix-screen-cursor
Modify-buffl
2
Insert
3- Refill-screen
I 2x6- Each buffer
modifying command
II
-
Char-deletel
4
|
Word-deletel
4
I -
Line-deletel
4
1 -
3
I 2- Insert-word
3
I-
Read
I
-
Write
Replace
1
4
1 2-
Move-buff
cursor
I
2
|
|
Char-fwd
I
Char-back
search
I
2x9- Each Cursor
moving command
5
|
-
|
5
|
-
Word-fwd
1
5
|
-
Word-back
1
5
| -
Line-fwd
1
5
|
-
Line-back
|
5
I
-
Top
I
5
1-
Bottom
I
5
1 -
Search
I
5
I
Fix-screen-I
I
cursor
3
I 3x15- Each command
|
-
processor
139
Refillscreen
--------
processor
I
-----------------------------------
Number of Modules
Average Strength
Average Coupling
Coupling per Mod.
Figure 26:
I 3x15- Each command
3
I
|
=
=
=
=
22
3.95
2.58
2.5
Evaluation of Structured Design
140
SYSTEMATIC DESIGN METHODOLOGY
Module Coupling
Module Strengthl
Module Namel
Editor
I
5
I 2- Dispatch
Dispatch
I
2
I 2x16- Each command
processor
Insert
I
2
I 2- Refill-screen
Read
I
3
1 2- Refill-screen
Write
I
3
I 2- Refill-screen
Char-fwd
I
5~
I 2- Move-cursor
Word-fwd
I
5
1 2- Move-cursor
Char-back
I
5
I 2- Move-cursor
Word-back
I
5
I 2- Move-cursor
Char-deletel
4
1 2- Refill-line
Word-deletel
4
I 2- Refill-line
Line-fwd
I
5
I 2- Move-cursor
Line-back
1
5
I 2- move-cursor
4
I
2- Refill-screen
-
Line-deletel
Search
I
5
I
Replace
I
4
I 2- Search
Top
I
5
1 -
Bottom
I
5
1 -
Refillscreen
I
3
I
Refill-linel
3
1 -
Move-cursorI
5
I
-
|
-
141
Number of Modules
Average Strength
Average Coupline
Coupling per Mod.
=
=
=
=
Figure 27:
21
4.1
2
1.43
Evaluation of SDM
142
- - - - - - - - I
rI - - - - - - - - - - - - - -- - - - - -
I
--
-
-
-
-
-
-
IJacksonl
HDM
-
No. of Modulesl
-
-
-
I
44
---------------------------------------Avg. Strength
1
--
-
-
24
-
1
I
SD
-
-
-
-
1
22
I
SDM
-
-
-
I
I
-
I
|
21
---------------
4.71
I
3.92
1
3.95
I
4.1
I
1
------------------------------------------------------Avg. Coupling 1 2
1 2.39 1 2.58 1 2
1
Coupl
/
I
Mod
Figure 28:
1.7
1
1.71
1
2.5
I
1.43
I
I
I
Summary of the Evaluations
L-------------------------------------------------------------------------------------.
4.5.3
Summary
After analyzing the designs, two underlying architectures
are
discovered.
ture of HDM and SDM.
into the system at
bottom.
is the pipelined architec-
The first one
In
this
organization,
the data goes
the top and the output comes
out at the
There are no coordinator modules to coordinate the
Each module has the responsibili-
activities in the system.
ty to pass control to the next module.
The
second architecture
Jackson and SD),
system,
branch.
is a
(e.g.,
where the data goes down one branch of the
gets returned back up,
In this type of system,
by coordinator modules.
the input goes to the
the EDITOR module,
tree organization
and then goes down another
activities are controlled
For example,
INPUT-HANDLER,
in Jackson's design,
then gets returned to
and finally the EDITOR module passes the
data to the OUTPUT-HANDLER.
143
strength (4.71
for
system is organized in layers.
the EDITOR machine only knows
in the HDM design,
The
the line linked
about the
does not know
It
buffer abstractly.
line linked implementation.
For
one data structure.
Each layer deals exclusively with
about the
can be ex-
This
HDM and 4.1 for SDM).
plained by the fact that the
example,
in module
proved to be stronger
The pipelined structure
BUFFER machine knows about
modules that ma-
structure and it contains
The EDITOR machine would then per-
nipulate the structure.
form its tasks by calling on the BUFFER machine modules.
On the other hand,
manipulate both
modules in the tree architecture must
the BUFFER and
linked structure.
the line
This caused many of them to have a module strength of 3.
The tree organization
is also weaker in
(2.39 for Jackson and 2.58 for SD).
higher average
The major cause of the
coupling measure is the
passed through the INC array.
module coupling
control information
Recall that the INC array was
used to store incremental movements of the cursor.
This in-
formation was passed from the command processors to the output modules.
The coupling
ture.
tree
The
can
problem is inherent
only way modules
communicate
through the coordinator.
is by
in the
tree architec-
on different branches
passing
Otherwise
control
of the
information
a global variable must
be used, but that often leads to high debugging cost.
144
Overall,
case.
the HDM design is
and coupling rankings for
The strength
HDM are the
It is also easiest to add extra editor
best among the four.
commands to HDM's
the best for this particular
design.
really a meta-language
The BUFFER machine
modules are
and new commands can
be easily com-
that SDM's
clusters could
posed from it.
Finally,
it is
have been organized
was purely
ture.
worth noting
into either type of
arbitrary that SDM
had the
architecture.
It
pipelined architec-
Chapter V
CONCLUSION
This chapter
The first section discusses
project.
software design.
approaches
methodologies.
through the
the basic problem in
section discusses the various
The second
to develop
out the
points
presents the insights gathered
The third
a methodology.
SDM in
weaknesses of
section
comparison to
other
Finally, this chapter concludes with sugges-
tions for further research.
5.1
THE COMPLEXITY PROBLEM
difficulty in software design
By far the most dominating
is complexity.
Often
the designer knows all
the require-
ments but cannot think about all of them simultaneously,
or
it might be that the designer has ideas for satisfying individual requirements, but can not put all the different solutions into
The problem
one system.
is not
the lack
of
ideas, but the lack of unity and cohesion.
Where exactly
does complexity
come from?
Through the
study in design theory, it is evident that complexity arises
from the interaction between
from the
requirements
numerous options available as
The key word here is interaction.
-
145
-
[Alexander
I,
and
solution iManheiml.
Complexity arises because
146
earlier decisions often add to the requirements of later decisions since decisions interact with each other.
complexity as
think of
One might
is trying to fly off in its own direction,
it alters the flight of all
signer's
job is to try and
of equilibrium,
Each molecule
some complicated way.
tied to each other in
of molecules
a bunch
and in doing so,
The de-
molecules tied to it.
get these molecules into a state
'or to get the whole network of molecules to
move in one direction.
Thus,
design is really a task
the task of architectural
in complexity management.
Having the architecture, the de-
signer can then devise solutions
He
for each requirement.
now knows that his solution must somehow fit into the architecture.
Furthermore, he knows that if individual solutions
conform to the
will function
conventions of the architecture,
then they
the
problem is
together.
shifted from "dealing with all
"dealing with the architecture".
design is in
the other requirements",
Therefore,
many ways analogous to
tional structure.
then solve
words,
In other
architectural
providing an organiza-
Given such a structure, the designer can
the problem of
quirement integrate
to
"How can
the solution to
into the structure?",
rather
a re-
than the
much more difficult problem of "How can the solution of this
requirement co-exist
ments?".
with the
solutions of
other require-
147
STRATEGIES FOR DEVELOPING A METHODOLOGY
5.2
methodologies.
approaches
basic
are two
There
in designing
software
The first is to survey existing systems, and
select those systems that are successful.
These systems are
Having iden-
then scrutinized to identify similar features.
tech-
tified the constant factors among successful systems,
derive system architectures from
niques can be developed to
For example, Jackson's methodology
those constant factors.
and Struc-
derives an architecture from the data structure,
tured Design derives an architecture from data flow graphs.
The second
ment
Methodology's decision
In HDM,
composition criteria.
good de-
machines;
and abstract
module de-
the
design process is modA hier-
sequence of interdependent decisions.
elled by a
structure is
abstract machine
grouping decisions.
clusters are
dependency and minimizes
gies surveyed,
way that
maximizes
These
intra-cluster
inter-cluster dependency.
to point out that of
only SDM
methodologies suggest
all the methodolo-
provides a -sense of
one architecture,
claim it to be the best architecture.
the best modularization.
for
models design
requirements into clusters.
formed in a
It is important
then provided
SDM, on the other hand,
as a process of grouping
Most
model
Methodology's graph model and
Systematic Design
upon
approach are Hierarchical Develop-
Examples of this
archical
theory,
what constitues
are made about
which conjectures
sign.
adopt a design
approach is to
optimality.
but do
not
Whereas SDM provides
148
Also,
methodologies
takes
leads to the
black
a
toward
envisioned as
data and
kind of
in some
This trend
aiming
methodology is
A
technology.
are
returns an
a box
box
which.
architecture.
tools which
development of design
will eventually generate programs automatically.
One important strategy that has emerged is that architecconstructed to match the
ture should be
This concept has
problem structure.
an obvious justification in
have real life interpretations.
systems which
But even in abstract appli-
cations it also makes sense to construct the system to match
the mental
picture.
Having this close
correspondence be-
tween system architecture and mental picture, the system can
then be modified
and debugged with ease.
That perhaps is
the reason several methodologies (such as Structured Design)
go through a problem analysis
phase before constructing the
architecture.
However,
the task of creating a system architecture that
matches problem structure
is not trivial.
There
are con-
straints imposed by the -programming language and the computer hardware.
For example, the typical programming language
has three kinds of control flow constructs, sequence,
ate,
and branch.
iter-
Therefore the system architecture must use
these control constructs and nothing else.
149
5.3
MODIFICATIONS FOR SDM
One weakness of SDM arises from the way interdependencies
SDM suggests that the designer should have an
are assessed.
idea of how the requirements
can be implemented,
Dif-
This method is too subjective.
weights accordingly.
ferent designers will most assuredly
come up with different
and abso-
the sense of reproducibility
Therefore
wights.
and assign
luteness is lost.
A
way to
deal with
whether the
data
Weights can now be assigned
structures used in the system.
according to
to identify
problem is
this
with the
requirements deal
same
data structure.
Another thing to do is to separate requirements into levRequirements
els of generality.
fault
tolerance
are
such as modifiability and
effects.
their
in
highly universal
Whereas a requirement like "implement a delete command" is a
much more detailed requirement.
To perform this separation,
according to their
very close
nodes can be linked together
If
level of generality.
in generality,
then they
two nodes are
are assigned
weight, otherwise they are weighed lightly.
a high
Then the clus-
tering algorithm can be applied to the graph to obtain clusters which represent different levels of generality.
After grouping requirements this way,
cedures can
clusters for
be performed on
each level of
each group.
generality,
the usual SDM proThis
results in
which can
then be
150
treated as a single node.
The result is a three dimensional
clustering situation as shown in figure 29
------------------------------------------------------------
Figure 29:
3-D Clustering
L--------------------------------------------------------------------------------------
Now the
problem is
describe each
cluster-node.
be applied here.
Each cluster
how to
The idea of abstraction can
would probably have some general characteristic.
For exam-
ple the editor commands character-forward and line-back have
the common characteristic of
these requirements
can be
moving the cursor.
described by
a new
Therefore
node called
cursor movement.
Another weakness
architecture.
of SDM is that
it does not
produce an
SDM tells'the designer which requirements are
151
highly dependent on each other,
and therefore must be con-
Furthermore,
SDM claims that the clusters
sidered together.
this
However,
should correspond to modules in the system.
the difficult task of organ-
still leaves the designer with
izing the modules into a structure.
concentrated on exactly
Other methodologies have largely
Jackson, Structured Design and HDM, all
the above problem.
HoTever,
these methodologies provide a system architecture.
in the area of
they are weak
Therefore,
the natural
problem structure definition.
combine SDM with
thing to do is to
other methodologies.
One such combination
data
be
Weights can
flow graph.
the combination.
derive Structured Design's
be used to help
SDM can
First,
ways to do
There are two
tured Design.
SDM and Struc-
can be made between
assigned according
two requirements are doing the
whether or not
data transformation.
The resulting
the individual bubbles
in the
data flow graph,
to
same kind of
clusters would provide
data flow graph.
Having the
can proceed according to the
the designer
procedure of Structured Design.
The second way to combine SDM and Structured Design is to
use the data flow graph
Weights
can be
nodes relate
assessed by
to the
This method of weight
dent.
for SDM interdependency assessment.
considering
same bubble
in the
how strongly
data flow
two
graph.
assessment is implementation indepen-
However, there is a drawback in that the set of clus-
152
ters would
probably have a
one to one
correspondence with
the bubbles of the DFG.
Another combination is HDM and
SDM.
stract machines can be identified,
A hierarchy of ab-
then
link each requirement to a machine.
SDM can be used to
Otherwise,
used to determine the machines themselves.
assigned according to whether two
the same machine.
SDM can be
Weights would be
requirements should be in
Then the resulting clusters would repre-
sent the machines.
5.4
SUGGESTIONS FOR FURTHER RESEARCH
The major weakness of SDM is its one-sidedness.
tacks the problem
analysis phase but does
help in constructing the architecture.
fore,
in the experiment,
organized into either
the
not provide much
As was mentioned be-
SDM clusters could have been
the Jackson type architecture
HDM type architecture.
SDM at-
Thus the
or the
area of architecture con-
struction definitely needs more attention.
A second weakness of SDM
sessment phase.
lies
A method to
in the interdependency as-
assign weights independent of
designers' personal biases is needed.
Data structures pro-
vide a promising path in this direction.
Finally,
it is worthwhile to
another methodology.
consider coupling SDM with
SDM is strong in the problem analysis
phase while other methedologies are
ture construction phase.
strong in the architec-
If used together, each could com-
153
plement the other.
The next step in this
define formal interfaces.
direction is to
Appendix A
SDM INTERDEPENDENCY ASSESSMENTS
The weights shown on the next page are arranged in a format recognizable
to the clustering program
the short form option
This is
(see [LATT81]).
(the other option
is called
regular form).
All of
the nodes linked to
each node are listed
same row but in the second column.
digit numbers.
three
Nodes are represented by
Underneath the
list of
nodes are the weights for the corresponding links.
ample,
suppose node
001 is linked to nodes 002
2 and 8 respectively,
the wights of
the short form representation:
001 002003
2
8
-
154
-
on the
then
"neighbor"
For exand 003 by
the following is
028
001 007
8
002 004005006007
8 5 5
8
003 004005007009
8
2 8
8
004 002003006007008
8 8 8
5 8
005 002003
5
2
006 002004007009014
5
8 5
2 2
007 001002003004006008014016017018019020021022023024025026027028
8 8 8 5 5 2
5 8 8 8 8 8 8 8 8
8 8 8 8 8
008 004007009014
8 2 8
8
009 003006008014015
8 2 8
8 8
010 001011012013
2
8 8
8
011 001010012013
28
8 8
012 001010011013
2 8
8 8
013 001010011012
2 8 8
8
014 006007008009
2 5
8 8
015 009
8
016 007019027028
8
8 8
8
017 007020
8 8
018 007021028
8 8 8
019 007016027028
8 8 8 8
020 007017
8 8
021 007018
8 8
022 007
8
023 007027028
8 a 8
024 007
8
025 007
8
026 007
8
027 007016019023028
8 8 8 8 8
028 007016018019023027
8 8 8 8 8 8
Appendix B
SDM CLUSTERS
The SDM clustering algorithm has been implemented in Fortran by Jim Lattin
(see [WONG80]
and (LATT81]).
ly resides under the CMS account LATTINA in MIT.
It currentAccess to
the program can be obtained from Jim Lattin.
To use the
program one must first define
the weights as
shown in appendix A, then run the exec program FIDEF4.
The
session during which the editor requirements were decomposed
is shown on the next page.
-
156
-
fidef4 mtv4 data
Tu0,16/0.36 14130123
EXECUrION itfoINS...
900
NODLIM =
ARCLIM = 4500
INPUT FORMATI
(1) REGULAR
(2) SHORT
.2
TOTAL NODES =
28
TOTAL ARCS a
53
AVERAGE NUMBER OF ARCS INCIDENT TO EACH NODE
26
27
29
DENSITIES CALCULATED IN
TREE FORMED IN
PRINT TREE 101
(1)
FILE
(2) T1Y
I
*
1.89
3 HUNDREDTHS CPU SECS
I HUNDREDTHS CPU SECONDS
---------------------------------------------------------
TREE FORMED IN
I HUNDREDTHS CPU SECONDS
PRINT TREE TO
(1) FILE
12)
TlY
.2
1-------------------------------------------------------------I
0.076190
2
7-------------------------------------------------- i
0.266666
I
1 1
3
28-----------II----------I-------------------III
1
0.685714
11
1
11
27----------- 11
4
0,666666
1
I
I
5
19--1
1
0.800000
6
16--1--------I
0.533333
7
23-----------------------I
I
I
0.300000
9
0.600000
9
1
1
it
18-----------------I
II
1
1 1
21-----------------I-----------------------1
I I
it
0.179571
10
0.414285
It
0.350000
12
- 0.281250
13
0.243750
14
0.456333
15
0.371420
16
0.266667
17
0.166667
19
0.114286
19
0.800000
20
0*076190
21
0.076190
22
0.076190
23
0.076190
24
0.0
25
0.690000
26
0.680000
27
0.680000
28
4--------------------------------I----I----1--I
I
1
1
2---------------------------------I
I
I
1
I 1
6-------------------------------------I
3-
----------------------------------------- I
9----------------------------
-
I
III
I
if
I
I
I
------I
14-----------------------------I
9-----------------------------------I
it
If
15--------------------------------------------1
I
5-----------------------------------------------------I
20---I
1
17---I-
I
--------------------------------------------------
26
25
24
22-
---------------------------------------------------------
13-----------I
12
11
10----------------------------------------------------
TREE FORMED IN
PRINT TREE TO:
(1) FILE
(2) TTY
I
0-076190
2
0.266666
3
0 HUNDREDTHS CPU SECONDS
1------------------------------------------------------------I
7------------------------------------------- I
I
29-------------a--------I
0.695714
1|
1
I
a
1
1
1
27
11
0.680000
-----
28
I
-----------------
TREE FORMED IN
0 HUNDREDTHS CPU SECONDS
PRINT TREE TU:
(1) FILE
(2) TTY
.2
1--------------------------------------------------------0.076190
2
7--------------------------------------------0.266666
3
28 ----------- I---------0.685714
1
I
4
27 ----------- I
0.533333
5
23 ----------------------- I--------------------I
0.076190
6
26
0.076190
7
25
0.076190
8
24
0.076190
9
22 --------------------------------------------------------0.0
21 ------------------ I
10
0.600000
18-----------------11
0.0
12
20 --- 1
I
0.000000
13
17 --- I
0.0
14
19 -- I
0.800000
1
16 -- 1
15
0.0
15 -----------------------------------------16
0.266667
9-----------------------------------I
17
1
0.371428
14 ----------------------------- I
19
I
0.458333
I
a --------------------------------- I-------I
19
0.0
13 ----------20
0.680000
12
21
0.680000
11
22
0.680000
10 ----------- I
23
0.0
24
6 ------------------------------------I----I---------I
0.350000
25
0.414285
26
2---------------------------------I
1
4----------------------------------
0.291250
3 ------------------------------------------- I
27
0.166667
5 -------------------------------------------------- I------------I
28
164 HUNDREDTHS CPU SECS
TIME FOR ENTIRE PROCESSt
REACHED OLDPAR
2 HUNDREDTHS CPU SECS
BUILDING PARTITION TOOK
1
CLUSTER NUMBER
1
7
16
0.0
15 ------------------------------------------
16
0.266667
9 ----------------------------------
17
0.371428
18
14 -----------------------------0.458333
19
t
1
6 --------------------------------- I-------I
0.0
20
13 -----------
I
12
I
0.680000
21
0.680000
22
11
0.680000
10 -----------
23
I
0.0
24
6 -----------------------------------------------0.350000
2 ---------------------------------I
25
I
I
t
0.414285
4 -------------------------------- ---- I
26
0.281250
27
3 -----------------------------------------
I
0.166667
28
5 -------------------------------------------------- I-------------I
TIME FOR ENTIRE PROCESSI
164 HUNDREDTHS CPU SECS
REACHED BLDPAR
2 HUNDREDTH8 CPU BECS
BUILDING PARTITION TOOK
CLUSTER NUMBER
1
1
7
16
17
16
19
20
21
22
23
24
25
26
27
29
2
CLUSTER NUMBER
8
9
14
15
3
CLUSTER NUMBER
10
11
12
13
4
CLUSTER NUMDER
3
4
5'
EVALUATION MEASURE EOUALS 0.105
4
MINPER a
(1)
(2)
KEEP PARTITION
ENTER DIFFERENT MINPER
ENTER NEU MINPER (IN FMT 13)
.002
REACHED DLDPAR
BUILDING PARTITION TOOK
I
CLUSTER NUMBER
1
7
22
I HUNDREDTHS CPU SECS
16
17
18
19
20
221
23
24
25
26
27
29
CLUSTER NUMBER
a
9
14
15
CLUSTER NUMBER
10
11
12
13
CLUSTER NUMDER
5'
6
EVALUATION MEASURE EOUALS 0.105
4
MINPER w
(1)
(2)
KE;.P PARTITION
ENTER DIFFERENT MINPER
92
ENTER NEW MINPER (IN FMT 13)
.002
REACHED DLDPAR
BUILDING PARTITION TOOK
I
CLUSTER NUMBER
1
7
22
23
24
25
26
37
28
CLUSTER NUMBER
18
21
CLUSTER NUMBER
17
20
CLUSTER NUMBER
16
19
CLUSTER NUMER
8
9
14
15
CLUSTER NUMBER
10
11
12
13
CLUSTER NUMER
2
3
4
5
6
7
2
3
4
5
6
EVALUATION MEASURE EQUALS 0,124
mIMPrR a
2
I HUNDREDTHS CPU SECS
6
EVALUATION MEASURE EQUALS 0.105
4
MINPER =
(1)
(2)
KEEP PARTITION
ENTER DIFFERENT MINPER
ENTER NEU MINPER (IN FMT 13)
.002
REACHED DLDPAR
BUILDING PARTITION TOOK
1
CLUSTER NUMBER
1
7
23
24
25
26
27
20
CLUSTER NUMBER
18
21
CLUSTER NUMBER
17
20
CLUSTER NUMBER
16
19
CLUSTER NUMBER
8
9
14
15
CLUSTER NUMBER
10
11
12
13
CLUSTER NUMBER
2
3
4
5
6
7
2
6
EVALUATION MEASURE EQUALS 0.124
2
MINPER a
(1) KEEP PARTITION
(2) ENTER DIFFERENT MINPER
.1
CHANGE CURRENT PARTITION?
(1) YES
(2) NO
.2
T=0.76/2.17 14136155
RI
I HUNDREDTHS CPU SECS
BIBLIOGRAPHY
IATWO78]
Hooper,
Ransey H.R.;
Atwood, M.E.; Turner, A.A.;
Cognitive
the
of
"An Exploratory Study
J.N.,
the Comprehension of SoftStructures Underlying
Science Publications Inc.,
ware Design Problems";
Army Research Institute for the Behavioral and Social Sciences, Alexandria, VA.
[ALEX64]
"Notes On the Synthesis of Form";
C.;
Alexander,
Press, 1964.
University
Harvard
[BASI8 1
Basili, V.; Reiter, R.W., "A Controlled Experiment
Quantitatively Comparing Software Development ApIEEE Transations on Software Engineerproaches";
SE-7, No. 3, May 1981.
ing, Vol.
[BATE77]
Procedure";
Design
"Software
R.R.,
Bate,
ConferAerospace
in
Computer
AIAA/NASA/IEEE/ACM
ence, Collection of Technical Papers, Published by
1977.
AIAA, New York, NY.
[BATE78I
"Software Development
G.T.,
LIgler
R.R.;
Bate,
ProMethodology: Issues, Techniques, and Tools";
ceedings of 11th Internation Conference on Systems
CA.
North Hollywood,
West Period Co.,
Science,
1978.
[BERG78I
"Software Design
W.H.;
Tranter,
Bergland, G.D.;
Techniques"; Proceedings of the National Electron, Oct, 1978.
ic Conference, Vol. 32, Chicago, IL.
IBERG81 I
Bergland G.D.;
Methodologies";
[BOYD78]
"Introduction to the
Pizzarello, A.;
Boyd, D.L.;
IEEE Transaction on
WELLMADE Design Methodology";
Software Engineering, Vol. SE-4, No. 4, July 1978,
pp 276-282.
[BR00771
Brooks, F.P.; "The Mythical Man-month";
rial
on Software
Design
Techniques,
18-2j.
[BRUG791
Bruggere, T.H.; "Software Engineering: Management,
Personnel and Methodology"; Proceedings of 4th InEngineering,
Software
Conference on
ternational
1979, pp361-368.
Program Design
"A Guided Tour of
IEEE Computer, Oct. 1981.
-
158
-
IEEE Tuto1977,
pp
159
[CAIN751
Caine, S.H.; Gordon, E.K.; "PDL - A Tool for SoftAFIPS National ComProceedings of
ware Design";
puting Conference, May 1975, pp271-276.
[CAMP80I
to
Design Applied
"Computer-Aided
J.W.;
Camp,
Nationof
Proceedings
IEEE
Software Engineering";
NAECON 1980,
Conference,
al Aerospace Electronic
Vol. 1, pp33-37.
[CAMP781
"SARA Aided Design of
G.;
Estrin,
Campos, I.M.;
Proceedings of
Systems";
Software for Concurrent
1973,
Conference,
Computing
National
AFIPS
pp325-358.
ICHES800
Chester, D.; Yeh, R.T.; " An Integrated Methodology and Tools for Software Development"; University
and Data Base EngiSoftware
of Texas at Austin,
neering Group, TR 411983.
[CHOW78]
"Analysis of Software Design Modelled
Chow, T.S.;
by Multiple Finite State Machines"; Proceedings of
COMPSAC, 1978.
[CHU75I
"Methodology for Software Engineering";
Y.;
Chu,
Vol.
Engineering,
on Software
IEEE Transactions
SE-1, No. 3, Sept. 1975, pp262-270.
[CORN791
Corner, C.; Halstead M.H.; "A Simple Experiment in
on Software
IEEE Transactions
Top-down Design";
1979.
March
2,
No.
SE-5,
Engineering Vol.
[DAHL741
Dahl, W.J.; Nunamaker, J.F.; "Interactive InformaProceedings of 5th
tion Systems Design Software";
Annual Pittsburgh Conferecce on Modelling and Simulation, 1974, pp24-26.
[DELF80]
"Design of a Software
Delfino, A.B.; Begun, R.A.;
Productivity";
Emphasizing
Development Methodology
MIcrocomputers,
and
MINI
of
Applications
IEEE
March 1980.
[DEW0781
Dewolf, J.B.; Whitworth, M.; "Methodology Research
Measures"; C.C. Draper Lab. Technical Report 1167,
August 1978.
[ELEC81
Tomorrow's Tool
Tools Point to
"Today's Software
Systems"; Electronic Design, July 23, 1981.
[ENOS81
Enos, J.C.; Van Tilburg, R.L.; " Software Design";
Tutorial Series 5, IEEE Computer, February 1981.
[FREE77]
Freeman, P.; "The Nature of Design";
on Software Design Techniques, 1977,
IEEE Tutorial
pp29-36.
160
[GOMA79]
Software Engineering
"Comparison of
Gomaa, H.;
Methods for System Design"; Proceedings of NationOctober
IL.,
Chicago,
Conference,
al Electron
1979.
[GRAH731
Graham, B.M.; Clancy G.J.; DeVaney, D.B.; "A Software Design and Evaluation System"; Communications
of the ACM, Vol. 16, No. 2, February 1973.
[HAMI761
Hamilton, M.; Zeldin, S.; "Higher Order Software IEEE TransA Methodology for Defining Software";
actions on Software Engineering, Vol. SE-2, No. 1,
March 1976.
[HAMM78 I
"System for Analysis
Murphy P.L.;
Hammond, L.S.;
Proceedings
and Verification of Software Design";
of COMPSAC '78.
[HUFF79]
"A Systematic Methodology for DesignHuff, S.L.;
ing the Architecture of Complex Software Systems";
M.I.T.,
of Management,
Sloan School
PhD thesis,
1979.
[JACK75]
Jackson, M.A.; "Principles of Program Design";
ademic Press, New York, N.Y., 1975.
[JENS81
"Structured Programming", IEEE ComJensen, R.W.;
puter, March 1981.
[LATT81 1
"Implementation and Evaluation of a
Lattin, J.M.;
on a High-denGraph Partitioning Technique Based
sity Clustering Model"; Technical Report #15, Center for Information Systems Research, Sloan School
of Management, M.I.T., 1981.
[LEVI80]
Levitt, K.N.; Newmann, P.G.; Robinson L.; "The' SRI
Hierarchical Development Methodology (HDM) and its
Softof Secure
Development
to the
Application
ware"; SRI International, Menlo Park, CA., 1980.
[MANH64 1
Manheim, M.L.; "Hierarchical Structure: A Model of
7,
Design and Planning Processes"; MIT Report No.
Civil Engineering Dept.
[MANH671
Manheim, M.L.; "Problem-Solving Processes in PlanDept.
ning and Design"; Professional Paper P67-3;
of Civil Engineering, MIT.
[MAYF77]
"Software Development Methodology
Mayfield, J.P.;
AIAA/NASA/IEEE/ACM Computer
Selection Criteria";
Collection of technical
Conference,
in Aerospace
papers, 1977.
Ac-
161
I McCl75 I
McClure C.L.; "Top-Down, Bottom-Up, and Structured
IEEE Transactions on Software EngiProgramming";
neering, Bol. SE-1, No. 4, December 1975.
[McG076]
McGowan C.L.; Kelly J.R.; "A Review of Some Design
Softech TR053, Sept 1976.; InvitMethodologies";
Art
of the
Tech State
ed Presentation for Info
1976.
October
Design,
Structured
on
Conference
[MYER75]
"Reliable Software Through Composite
G.J.;
Myer,
Design"; Petrocelli/Charter, New York, 1975.
[PETE77]
"Comparing Software Design
Tripp, L.;
Peter, L.;
11, No23, No.
Methodologies"; Datamation, Vol.
1977.
vember
[RAMA73]
Ramamoorthy, C.V.; Meeker, R.E.; Turner, J.; " DeSoftware
an Automated
of
and Construction
sign
Evaluation System"; IEEE Symposium on Software Reliability, May 1973, pp28-37.
[RAMS791
"An
Campbell, G.D.;
Atwood, M.E.;
Ramsey, H.R.;
SciDesign Methodologies";
Analysis of Software
Reseasrch Institute
Army
Inc.,
ence Application
for the Behavioral and Social Sciences, Alexandria
VA., 1979.
IRICH79]
"Computer
Waters, R.C.;
Shrobe, H.E.;
Rich, C.;
EngineerSoftware
for
Design
Aided Evolutionary
MemoranLab.,
Intelligence
MIT Artificial
ing";
dum, January 1979.
[RICH77]
Richards, P.K.; "Developing Design Aids for an InSystem";
Development
Software
tegrated
Aerospace ConferAIAA/NASA/IEEE/ACM Computing in
ence, Collection of technical papers; published by
AIAA, New York, N.Y., 1977.
[RIDD78]
"BehavRiddle, W.E.; Wilden, J.C.; Sayler, J.H.;
ior Modelling During Software Design"; Proceedings
on Software Engiof 3rd International Conference
neering, 1978.
[ RIDD79]
"An Event Based DeRiddle, W.E.; Schneider H.J.;
Formal Modsign Methodology Supported by DREAM";
Systems
for Information
Practical Tolls
els and
Design, Oxford, England, April 1979.
[RZEV791
"On the Design of EngiAdey, R.A.;
Rzevski, G.;
Software, SouthampEngineering
neering Software";
1979.
Sept
ton, England,
162
"The Sciences of the Artificial"; MIT
[SIM069]
Simon, H.A.;
Press, 1969.
[SUTT81]
Sutton, S.A.; Basili, V.R.; "The Flex Software DeIEEE
Designers Need Languages Too";
sign System:
Computer, November 1981, pp95-102.
[WARN74]
Warnier, J.D.; "Logical Construction of Programs";
Van Nostrand Reinhold Co., New York, N.Y., 1974.
[WILL79]
Willis, R.R.; Jensen, E.P.; "Computer Aided Design
Proceedings of 4th Internaof Software Systems";
1979,
Software Engineering,
tional Conference on
pp116-125.
[WONG80]
Wong, M.A.; "A Graph Decomposition Technique Based
Model on Graphs";
Clustering
on A High-density
Sloan School of Management,
Technical Report #14,
M.I.T., 1980.
[YOUR79]
Fundamentals of
Yourdon, E.; "Structured Design:
Systems Deof Computer Program and
a Discipline
sign"; Prentice-Hall, 1979.