View
217
Download
5
Category
Preview:
Citation preview
;{/ _”
Complexity Measurement of a Graphical Programming Language and Comparison of a Graphical
and a Textual Design Language
byl Roger Allen Goff
Thesis submitted to the Faculty of the
Virginia Polytechnic Institute and State University
in partial fulfillment of the requirements for the degree of
Master of Science
in
Computer Science and Applications
APPROVED:
(P°
Dr. Sallie M. Henry, Chairmanl
Ä, @2. xy H' / 2/ .Dr. H. Rex Hartson ' Dr. Denn} G. Kafura
1
Blacksburg,Virginiai1
1
„ 11
II
SComplexity Measurement of a Graphical Programming Language and Comparison of a Graphical
VI and a Textual Design LanguageU by
Roger Allen Goff
Dr. Sallie M. Henry, Chairman
Computer Science and Applications(ABSTRACT)
For many years the software engineering community has been attacking the software reliability
problem on two fronts. First via designmethodologies, languages and tools as a precheck on
quality and second by measuring the quality of produced software as a postcheck. This research
attempts to unify the approach to creating reliable software by providing the ability to measure the
quality of a design prior to its implementation. Also presented is a comparison of a graphical and
a textual design language in an effort to support cognitive science research frndings that the human
brain works more effectively in images than in text.
I
II
Acknowledgements
I would like to thank my advisor, Sallie Henry, for her support and guidance in this research. Her
quick solutions to problems in times of cnsis helped to keep my sanity. I would also like to thank
Jeff Vining in the statistics consulting lab who advised me not only on what statistical analysis I
should perform, but on how to interpret the results and Rex Hartson and Dennis Kafura for serving
on my committee.
Acknowledgements iii
l
Table of Contents
Chapter l. Introduction ................................................... 1
Introduction .......................................................... 1
Flowcharts ........................................................... 2
IIIPO Diagrams .................................................,..... 3
Pseudocode ........................................................... 3
PDL ...........................................,....................4
GDL ............................................................... 4
Existing GDL's ........................................................ 5
Conclusion ........................................................... 7
Chapter 2. Overview of Metrics ............................................. 9
Introduction .......................................................... 9
Micro Metrics ........................................................ 10
Structure Metncs ...................................................... 15
Hybrid Metrics ....................................................... 18
The Software Quality Metric Analysis Tool .................................. 20
Conclusion .......................................................... 23
Table of Contents iv
2
Chapter 3. Graphical Language Translation .................................... 24
Introduction .........................,............................... 24
GPL ............................................................... 24
Introduction24
The Computational Design Symbols in a SPD .............................. 25
The Supervisor ..................................................... 31
Observations ....................................................... 31
The Relation Language ................................................. 32
Introduction ....................................................... 32
Relation Language Constructs .......................................... 32
Observations ....................................................... 36
The Translation Prom GPL to The Relation Language .......................... 36
Introduction ....................................................... 36
Procedure Header Generation ........................................... 37
Local Variable Declarations Generation.................................... 37
Relation Language Code Generation for SPD Members ......i................. 37
The Generation of Micro Metric Values ..................................... 41
Conclusion .......................................................... 44
Chapter 4. Complexity Measurement ........................................ 45
Introduction ......................................................... 45
The Experiment ...................................................... 45
Data Preparation ...................................................... 46
Data Presentation Information ............................................ 47
Comparison of Initial and Revised Designs ................................... 47
Regression Analysis of GPL and ADLIP .................................... 50
GPL ............................................................. 51
ADLIP ........................................................... 52
Table of Contents v
Conclusion .......................................................... 52
Chapter 5. Comparison of Design Tools ....................................... 59I
Introduction ......................................................... 59
Comparison of GPL and ADLIF Design Complexities ..................,....... 59
Comparison of GPL and ADLIF Designed Source Code ......................... 61
Conclusion .......................................................... 65
Chapter 6. Additional Nieasuremcnts ......................................... 66
Introduction ......................................................... 66
Intermetric Correlations ................................................. 66
Prelirninary Data Set .............................,..................... 72
Conclusion .......................................................... 73
Chapter 7. Conclusions ................................................... 78
Conclusions ......................................................... 78
Future Work ......................................................... 80
Bibliography ........................................................... 81
Appendix A. Sample GPL Design ........................................... 83
Appendix B. Sample Generated Relation Language Code .......................... 113
Appendix C. Sample Pascal Source Code ..................................... 181
Appendix D. Operating Systems Assignment .................................. 217
Motivation ......................................................... 21 8
Table of Contents vi
11
Constraints ......................................................... 218
Input ............................................................. 219
Output ............................................................ 221
Grading ........................................................... 222
Appendix E. GPL Regression Line and Conlidence Interval Plots .................... 223
Appendix F. ADLIF Regression Line and Conlidence Interval Plots .................. 233
Appendix G. Software Engineering Assignment ................................. 243
CS4980 Final Exam ................................................... 244
Commands ......................................................... 245
The Play ........................................................... 246
Death ............................................................. 246
Scoring ............................................................ 247
The Robots ....................................,................... 247
The Assignment ..................................................... 247
Vita ................................................................ 249
14 111
I11' Table of Contents vii I1
I111
1
List of Illustrations
Figure 1. Logical Structure of the Software Quality Metxic Analyzer ................. 21
Figure 2. Computational Design Symbols in GPL .............................. 26
Figure 3. A GPL Supervisory Cell ......................................... 27
Figure 4. Constructs in the Relation Language ................................ 33
Figure 5. Multiple Exit Point Handling for Cyclomatic Complexity ................. 42
Figure 6. Regression Line and 95% Confidence lines for Information Flow Complexity inGPL ....................................................... 55
Figure 7. Regression Line and 95% Coniidence lines for Infonnation Flow Complexity inADLIF ..................................................... 57
Figure 8. GPL Length Regression and 95% Coniidence Lines .................... 224
Figure 9. GPL N Regession and 95% Conlidence Lines ........................ 225
Figure 10. GPL Volume Regression and 95% Confidence Lines.................... 226
Figure 11. GPL Effort Regression and 95% Coniidence Lines ..................... 227
Figure I2. GPL Cyclomatic Regression and 95% Confidence Lines ................. 228 1
Figure 13. GPL Information Flow Regression and 95% Confidence Lines ............ 229 lFigure 14. GPL Information Flow with Length Regression and 95% Confidence Lines . . . 230 ;
Figure 15. GPL Information Flow with Effort Regression and 95% Confidence Lines .... 231 IFigure 16. GPL Information Flow with Cyclomatic Regression and 95% Coniidence Lines
232Figure17. ADLIF Length Regression and 95% Coniidence Lines .................. 234 :Figure 18. ADLIF N Regression and 95% Confidence Lines ...................... 235 '
Figure 19. ADLIF Volume Regression and 95% Confidence Lines .................. 236 ‘
Figure 20. ADLIF Effort Regression and 95% Confidence Lines ...................
237Listof Illustrations viii ‘
Figure 21. ADLIF Cyclomatic Regression and 95% Confidence Lines ............... 238
Figure 22. ADLIF Information Flow Regression and 95% Confidence Lines .......... 239
Figure 23. ADLIF Information Flow with Length Regression and 95% Confidence Lines . 240
Figure 24. ADLIF Information Flow with Effort Regression and 95% Confidence Lines . . 241
Figure 25. ADLIF Infonnation Flow with Cyclomatic Regression and 95% Confidence Lines 242
List of Illustrations ix
II
List of Tables
Table I. Metric Abbreviations Used in Data Presentation...,..................... 48
Table 2. Correlations of Initial to Revised Designs ................,............. 49
Table 3. Correlations of Revised Designs to Designed Source ...................... 53
Table 4. Regression Line Equations and Statistics for GPL Designs ................. 54
Table 5. Regression Line Equations and Statistics for ADLIF Designs ............... 56
Table 6. Mean Complexities of Initial and Revised Designs ....................... 60
Table 7. Mean Module Complexities for GPL and Adlif Designed Pascal Source Code . . . 62
Table 8. Average Ratio of Complexities of GPL to ADLIF Designed Source .......... 63
Table 9. t-values from the Student T distribution ............................... 64
Table 10. Intermetric Correlations for GPL Revised Designs ....................... 68
Table ll. Intermetric Correlations for GPL Designed Pascal Source Code ............. 69
Table I2. Intermetric Correlations for ADLIF Revised Designs ..................... 70
Table I3. Intermetric Correlations for ADLIF Designed Pascal Source Code ........... 71I
Table 14. Correlations of Designs to Designed Source Code .............,.......... 74
Table 15. Mean Module Complexities for GPL and Adlif Designed Pascal Source Code . . . 75
Table 16. Average Ratio of Complexities of GPL to ADLIF Designed Source .......... 76
Table I7. t-values from the Student T distribution ............................... 77 IIIIIIIII
List of Tables x I‘ I
I
Chapter 1. Introduction
Introduction
The software design phase can generally be divided into two major stages, namely architectural or
general design, and detailed design [YAUS 86]. General design is responsible for translating re·
quirement speciiications into system structure. This stage places emphasis on module definition
and on the interrelationships among modules. Design techniques include the concepts of top-down
design and functional decomposition. The system architect begins by analyzing the requirements
specification and decomposing the system into functional units or modules. The major concems
are not how a problem is to be solved, but instead, differentiating the sub-problems of the problem
and documenting the communication which must occur among the sub-problems. The process
of identifying the sub-problems of a problem is commonly referred to as functional decomposition
and its recursive application within the sub-problems defines the system structure and leads to the
detailed design stage where the architectural design is transformed into the procedural description
of a software system. This second stage or detailed design phase emphasizes the selection and i
evaluation of algorithms. Design techniques for this level include the concepts of bottom-updesignand
stepwise retinement. Once the structure of a system is defined to a point where the solution I
to the sub-problem becomes obvious, a designer may discontinue the top-down designapproachChapter
I. Introduction l
and begin designing bottom-up via the definition of utility routines to be used in the solution. The
solution to the sub-problem is then defined by application of these utilities within specific routines.
Some designers never revert to designing in a bottom-up fashion, instead, they continue the top-
down approach by laying out the algorithmic structure within procedures while avoiding actual
representation details as long as possible. The continuance of top-down design is called stepwise
refinement. The two stage definition of design aides in the discussion of the different design meth-
odologies previously and currently employed.
The detailed design phase of the software life cycle is the focus of this thesis. With this in mind,
tools to assist the designer with this phase are briefly described.
Flowcharts
Flowcharting is the traditional means for specifying and documenting the algorithmic details in a
software system and over the years a great controversy has developed conceming its usefulness
[FAIR 85]. Flowcharts have been called everything from "an essential tool in problem solving"
[BOHM 7l] to "an obsolete nuisance" [BROF 75}. Flowcharts are generally accepted as a useful
tool for diagrarnming program flow of control, however, problems arise when a flowchart gets large
and no longer fits on a single page. Other wealcnesses include the inability to represent complex
decision predicates legibly in the small space of a decision diamond and the frustration associated
with drawing flowcharts and having no easy way to modify them. Therefore other representationsevolved. [‘ Chapter 1. Introduction 2
HIPO Diagrams
A derivative of flowcharts called IIIPO diagrams (Hierarchy-Process-Input-Output) were developed
at IBM as " design representation schemes for top-down software development, and as extemal
documentation aids for released products" [FAIR 85]. HIPO charts consist of three parts; a visual
table of contents, a set of overview diagrams, and a set of detail diagrarns. The table of contents
is a tree structured or graph structured directory of the contents of the overview diagrams. The table
of contents also includes a legend of symbol defrnitions. The overview diagrams specify the inputs,
processing steps and outputs of a functional unit of the system. The overview diagrarn format
consists of boxes that are filled with English-like phrases describing the execution process and
connected with arrows to indicate the flow of control. The intemals of the boxes may also contain
a description of the procedure interface, local data structures, timing constraints, side effects, and
procedure lirnitations. Detail diagrams have the same format as overview diagrarns. HIPO charts
are an attempt to bypass the obvious problems found with flowcharts, and are a step in the right
direction in terms of the elimination of off-page connections and the use of English-like phrases for
decision predicate specification. However, the inability to easily modify the charts still exists.
Pseudocode
Another widely used design tool is pseudocode. Like flowcharts and HIPO diagrams, pseudocode
can be used to represent both detailed and architectural designs. Using pseudocode, the designer
uses english—like language phrases intermixed with keywords like WHILE, and IF-THEN-ELSE.
The use of the keywords combined with indentation shows the flow of control within the system,
and the english phrases describe the processing. Since there are no structuring rules, each individual
uses his own style and syntax. Upon examination of several designers’ concepts of pseudocode
format, the need for some sort of standardization becomes apparent.
Chapter 1. Introduction 3
u
PDL
By adding syntactic requirements to pseudocode, standardization of pseudocode format is achieved
and one defines what is called a program design language or PDL. Program design languages can
be used in both the architectural and detail design stages. A good PDL is adaptable to its envi-
ronrnent, is farniliar to both designers and programmers, and has a nonrestrictive syntax to allow
the designer to freely express himself. Among the advantages of PDL’s is the ease of modification,
since they can be stored in text files. Other advantages are the ability to syntactically check the
design and easily translate a design to high level code. A study comparing PDL's to flowcharts
found PDL’s to be a superior design tool ]RAMH 83]. PDL’s, however, have some disadvantages
not found in flowcharting. Like high level programs, PDL’s do not provide a clear representation
of the flow of control in a system, and their use requires the burden of an irnposed syntax.
GDL
Psychological studies have shown that the brain processes visual information faster than verbal in-
formation and that humans actually think in pictures. These findings are the motivation for de-
signing with graphs. Bill Benzon, a researcher in cognitive science, has stated that, "if you want to
think about how ideas fit together and to teach this material to others then graph notation is the
most useful" [BENB 85]. Graphs perinit the designer to visualize all the components of a system
quickly and easily, thus allowing the thought process to concentrate on development. A textual
listing of the same system requires the designer to read each line and painstakingly assemble a view
of the system and its components. Design graphs are also easily understandable by inexperienced
programmers and nonprogrammer managers since there is little syntax to learn and only a small set
of symbols with which to become familiar. Graphical design languages are excellent tools for ar-
chitectural design, and in contrast to their graphical ancestors are well suited to detailed design.
Chapter I. Introduction 4
IGDL’s can also have the added feature of automated translation to high level programming lan-
guage code. Versatility and ease of use are responsible for the wider acceptance and application ofGDL’s in real world environments.
Existing GDL’s
Progam Visualization
The Program Visualization environment, which was developed at the Computer Corporation of
America, is devoted primarily to the dynamic graphical execution of systems. The graphical system
"simulation", is concerned mainly with the changes made to structured data. The developers
maintain that the depictions of flow of control do not need to be as complex as the depictions of
data [BROG 85]. Program Visualization uses multiple windows to display both code and graphics
while showing control flow within the windows by highlighting the portions of the system being
executed The graphical depiction of data has the capability to monitor and display changes in such
common data structures as numeric variables, arrays, linked lists, and trees. The user can create
graphical pictures and link them to code and data, thus establishing high-level icons that can be
used during execution monitoring. The level of abstraction displayed can be chosen by the pro-
grarnmer, with choices ranging from top~level drawings of the whole system being developed to
bottom-level depictions of language code. The construction of programs and static graphics by
assembly can be viewed as an extension of current practices, in particular, the use of subroutine li-
braries. The Program Visualization system provides a navigational aid facility for access to the li-
brary routines. Typically the library would contain both graphical and code templates for
commonly used data structures and graphical symbols or building blocks. Kits are mixed col-
lections of building blocks and templates. An example of the use of the library might be the storage
of standard flowchart notation in a kit. The user can then create flowcharts by simply copying
symbols from the kit into the diagram window, filling in the text as is necessary.
Chapter l. Introduction 5
PegaSys
PegaSys is an experimental system whose main purpose is to use graphical images as formal, ma-.
chine processable, documentation and an explanation of system designs. A program design is de-
scribed in PegaSys by a hierarchy of interrelated pictures. Each picture describes data and control
dependencies among such entities as "subprograms," "processes," "m0dules," and "data objects"
[MORM 85]. Particularly interesting is the PegaSys system’s ability to: check whether pictures are
syntactically meaningful, enforce a design development methodology throughout its functional de-
. composition, and determine whether a resulting program meets its pictorial documentation. These
abilities are achieved through the use of a graphical calculus formulae representation of diagrams.
A grammar for the graphical calculus allows for syntactic checking and for enforcement of the de-
composition process. PegaSys also provides a full featured graphical editing system for the creation
and refinement (functional decomposition) of diagrams.
Pict
The Pict system is a departure from the approach of the preceding systems in that it is designed to
aid program implementation rather than algorithm design and selection. Pict is actually a program
development environment, providing all the tools users need to compose, edit, and run their pro-
grams while being integrated within a simple consistent command structure ]GLIE 84]. Once Pict
is entered, the user need not touch the keyboard; communication with the system is by some suit-
able input device like a joystick or mouse. Programs are constructed using graphical icons to rep-
resent data structures, parameter passing modes, variables, and program operations. Even
subprogram names are represented by icons that are created by the user with an icon editing facility. EControl structures are represented by colored directed paths. Program syntax is continuously I
checked during development, and inconsistencies are eliminated even when a program or sub- Iprogram is only partially specified. Once a subprogram is developed, the icon representing its nameE
Chapter l. Introduction 6 E
‘ I
is inserted into a menu tree, this icon can then be accessed to reuse the subprogram in other de-
velopments. A user may also delete an icon from the menu tree, and all links to that icon are au-
tomatically removed.
GPL
GPL is the graphical programming language of the Dialogue Management System, DMS, being
developed at Virginia Tech [IIARII 85]. GPL follows the Supervised Flow design methodology
which dictates that each program and subprogram has a supervisor which supervises all the flow
of information within a diagram. The diagrams of the programs are called Supervised Flow Dia-
grams, or SFDs. The DMS environment provides a graphical editor for the creation of SFD’s
which consist of a small set of icons representing decisions, subprogram calls, input/output oper-
ations, statement blocks, start, return, and control and data flow lines. GPL, like Pict, is unique
in the sense that it too is a programming language rather than just a design language. The DMS
system has a coder, which takes the SFD’s for a progam and generates high level language code.
Currently the coder generates ’C’ code, however, eventually a user will have a choice of languages
to generate. The DMS project also has plans for a Behavioral Demonstrator which will dynam-
ically execute a program, while allowing the user to examine and change vaiiable values, and ex-
haustively test parts of a program [CAL.] 85], [SMIE 86].
Conclusion
Having recognized the need for a structured design methodology, many different design tools and
techniques developed including: flowcharts, HIPO diagrams, pseudocode, program design lan-
guages and graphical design languages. The transition to each new technique is motivated by the
inadequacies of currently available techniques. The most recent transition from PDL’s to GDL’s
” Chapter I. Introduction 7
u
has sound theoretical support from the field of cognitive science which concludes that the human
brain processes pictorial information more efficiently. In this research an automated software
quality metric analysis tool is used to verify that the cornplexity of graphical designs can be meas-
ured and, more irnportantly, that programs designed using a graphical design language are less
complex than those designed with a PDL.
Chapter two gives a brief description of some of the established software quality metrics along with
a description of the software quality metric analysis tool used in this study. In chapter three is a
detailed description of the graphical design language, used in this study, and a technique for ana-
lyzing the language. The results of measuring the graphical language are presented in chapter four
and a comparison of the graphical language and a textual design language is given in chapter five.
Chapter six contains an intermetric analysis that supports the findings of an earlier metric study and
a description of some earlier results. Finally, chapter seven recounts conclusions and identifies fu-
ture work.
Chapter 1. Introduction 8
I
Chapter 2. Overview of Metrics
Introduction
\Vhile some of the software engineering community has been dedicating time to developing tools
and methodologies to aid in the design process, another sector of the community has been devel-
oping the means to measure and analyze the quality of software. An enormous amount of literature
has been written covering a broad spectrum of proposed measurements. For this study the qual-
itative, nonautomatable and nonintuitive metrics are ignored. Nonautomatable or qualitative
metrics are not of interest to the practitioners. Measuring a real system of 500,000 lines of code is
not practical unless the measuring technique has been automated. In this chapter some of the more
significant automatable metrics are described along with an automated software quality metric
analysis tool.
Three classifications of automatable metrics to be examined are micro, or code metrics, macro, or
structure metrics and hybrid metrics. The micro metrics are concemed with measuring features
taken directly from source code, for example, length of a program and the number of decision
constructs in program are considered micro metrics. Macro metrics, however, are concemed with
measuring the complexity of the structure of a software system, for example, measuring the com-
Chapter 2. Overview of Metrics 9
I
I
plexity of the decision process that leads to the invocation of a module. Finally, hybrid metrics are
those metrics that utilize a combination of code and structure metrics to produce complexity
measures.
‘ Micro Metrics
Length
The most familiar software measurement is lines of code, or length [CONS 86]. This may seem to
be a simple metric that can be easily derived, yet there is no general agreement as to what constitutes
a line of code. Conte, Dunsmore and Shen [CONS 86] propose the following definition:
line of code A line of code is any line of program text that is not a comment or blank line, re-
gardless of the number of statements or fragrnents of statements on the line. This spe-
cifically includes all line containing program headers, declarations, and executable and
non-executable statements
Most researchers agree that the line of code measure should not include comments or blank lines
since their presence or absence does not affect the functionality of a program. Interpretation of the
above definition for various source languages could include such counts as the number of semi-
colons, in Pascal or the number of carriage returns in ’C’.
McCabe’s Cyclomatic Complexity
McCabe’s Cyclomatic Complexity [MCCT 76] denoted l/(G), has its foundations in graph theory.
This code metric measures the number of basic paths in a routine, and is derived from the repre-
sentation of a procedure as a strongly connected graph. The nodes in the graph represent blocks
Chapter 2. Overview of Metrics l0
I
of code in the procedure where the processing is sequential and the arcs correspond to branches
taken. Each program graph must have a unique entry and exit point. In order to perform the
complexity analysis, a procedure’s control graph must be strongly connected, a single arc from theI
unique exit point is drawn back to the unique entry point to satisfy this criterion.
A result from graph theory states that in a strongly connected graph G , the cyclomatic number,
I/(G), is equal to the maximum number of linearly independent circuits, where
V(G) = E — N —+— 2 and where
E = the number of edges in the graph
N = the number of nodes in the graph
In this way l\/IcCabe defines the cyclomatic complexity, V(G), of a procedure to be the cyclomatic
number of the procedure’s strongly connected control graph.
The reasoning behind MCCHÖC/S definition is that the complexity of a procedure is going to be
proportional to the cyclomatic number or, alternatively, the number of linearly independent circuits
in the procedure’s control graph.
The complexity of a program of p procedures would be the sum of the complexities of each of the
p procedures and is given by:
PV(G) = E1 V(Gz)P
= —— rz, + 2)
= 6 — rz + 2pI
where, I
G, = procedure i’s graphI
6, = the number of edges in procedure i’s graph
n, = the number of nodes in procedure i’s graph
IChapter 2. Overview of Metrics ll
I
I
e = the total number of edges in all graphs
n = the total number of nodes in all graphs
For structured programs N1cCabe simplified the calculation of the cyclomatic complexity to a count
of the number of simple predicates in a routine plus one utilizing results derived by Mills [MILH
72].
Halstead's Software Science
Halstead’s code metrics [HALM 77] take the view that algorithms have physically measurable
characteristics. The resulting theory, called Software Science, states that certain algorithmic prop-
erties may be derived from the following four counts:
nl = the number of unique operators appearing in a program
n2 = the number of unique operands appearing in a program
N1 = the total number of occurrences of all operators in a program
N2 = the total number of occurrences of all operands in a program
Two defmitions, derived from the above counts, are used in the calculation of the Software Science
metrics. The sum of the counts nl and n2, define the size of the vocabulary of a program and is
denoted by n. The length of a program, denoted N, is similarly defined as the sum of N1 and N2.
In the following sections three Software Science metrics, their derivation, and intuitive meanings
will be described.
Chapter 2. Overview of Metrics 12
I
I
Program Volume
An important algorithmic characteristic is size. The following formula estirnates the size of an al-
gorithm based on the size of the algorithm’s vocabulary and length:
V = N >< log2(r2)
The derivation of this fomiula is subject to two interpretations. The first treats V as a measure of
the number of bits required to store the algorithm since it takes a minimum log2(n) bits to represent
each of the symbols in the vocabulary. The second interpretation treats V as the number of mental
comparisons required to generate the algorithm. The second interpretation assumes that a pro-
grammer must make a binary search through the vocabulary each time an element in the algorithm
is selected.
lt is important to note that the program volume metric’s value will vary in size, based on the ex-
pressive power of the algorithm’s implementation language. Similarly, in any one language some
algorithms are smaller in size than others. These features are required of the volume metric in order
that such changes may be studied.
Program Level
The program level metric is defined as the ratio of the potential volume , V', to the actual volume,
V, of the algorithm:
I/*L i _l-
V
where the potential volume is the most succinct form in which an algorithm could ever by ex-
pressed. Since the value of V' cannot be established, it is necessary to derive an estimator in terms
of operands and operators.
Chapter 2. Overview of Metrics I3
III
The least number of operators that could ever be employed is two, where the pair would be a
function call and an assignment operator. However, there appears to be no limit to the number
of operators that one might employ. From this we have the ratio:
L ~ Lnl
with respect to operators.
On the other hand, operands exhibit no unique minimum value, so they must be treated on an
intuitive level. Whenever an operand is repeated, it is an indication that the algo1ithm’s imple-
mentation is at a lower level. This effect may be demonstrated by the ratio:
L ~ 22..AN2
Combining these two ratios gives us the program level metric’s estimator:
^ _ 2 nzL ‘ W X N,
A second interpretation of the program level measurement is the relative intellectual ease with
which a programmer makes a single mental comparison.
Programming Ejfort
The programming effort metric can be thought of as a measure of the mental activity required to
translate a collection of ideas regarding a problem solution into an actual implementation of the
algorithm in some language known to the programmer. The formula for the effort metric is:
E = V >< D
Chapter 2. Overview of Metrics I4
where V is the program volume metric, and D is the reciprocal of the program level metric L. D
represents the difficulty of making the mental comparisons required to irnplement the algoxithm and
is measured in units referred to as elementary mental discriminations (EMD). Replacing D in the
equation yields:
VE l'L
By substituting in L’s theoretical value we denve another equation from which significant conclu-
sions can be cited:
2 .E = ———V*
V
This equation implies that the mental effort required to implement any algorithm vaxies by the
square of its volume, not linearly, and therefore that proper modulanzation of algonthms can def-
initely reduce programming effort.
Structure Metrics
McClure’s Module Invocation Complexity
McClure’s structure metric [MCCC 78] examines two characteristics of a module ir1 order to define
a complexity. The first characteristic is a measure of the complexity of the circumstances under
which the module was invoked and the second is a measure of the complexity of of a module in-
voking another module.
The complexity of invoking a module is dependent on two factors, and requires the definition of a
module’s invocation control variable set. The invocation control variable set for a module is the
Chapter 2. Overview of Metrics IS
set of variables whose values effect a particular invocation of a module. For example, suppose the
following code is used to irrvoke module B:
. while (varl < var2) or (var} = 0) doy’(var4 = var5) then
invokeend while;
The set {var}, var2, var}, var4, var5}, forms an invocation control variable set for module B. It is
possible for a module to have more than invocation control variable set if it is invoked conditionally
in more than one place. Given this definition, the complexity of the invocation of a module is a
function of the number modules that invoke the module, and the average invocation control vari-
able set complexity where the complexity of an invocation control variable set is given by:
Eb
Xwith,b = 2 if any K. is a control variable of a repetition structure
= l otherwise
C(Id) = Control Variable Complexity ]MCCC 78]
e = the number of variables in the invocation control variable set
The complexity of a module invoking another module is a function of the number of modules
which it invokes and the average complexity of all invocation control variable sets used by the
module in invoking its direct descendants.
Combining the above two characteristics gives the following formula for the complexity of a mod-
ule B:
MU?) = [FP X X(P)l + [GP
Xwhere, IChapter 2. Overview of Metrics I6 :
I, II
IIQ, = the number of modules that invoke B.
X(p) = the average complexity of all invocation control variable sets used
to invoke module B.
GP = the number of modules invoked by module B.
Y(p) = the average complexity of all invocation control variable sets used
by module B to invoke other modules.
Henry and Kafura’s Information Flow Nietrie
Henry and Kafura [HENS 79], [HENS 81] have developed a structure metric which derives a pro-
cedure’s complexity from the procedure’s connections with its environment. These environment
connections are taken from the tlows of information in and out of the routine, termed fan-ins and
fan-outs respectively. The fonnal defrnitions of fan-in and fan-out are as follows:
fan-in the number of local flows into a procedure plus the number of global data
structures from which a procedure retrieves information
fan-out the number of local tlows from a procedure plus the number of global data
structures which the procedure updates.
The fan-ins and fan-outs for a routine are determined in a two step process. The first step involves
the generation of a set of relations which represent the flow of information within a routine via in-
put and output parameters, updates of global data structures, reads from global data structures and
returns from function calls. From these relations a forest of trees is built which has as its roots
global data structures. The leaves represent data structures and function returns whose information i
will ultimately end up in the global data structure at the root of their tree. The intemal
nodesrepresentinterfaces through which the information at the leaves will travel on their way to the root. Pli
Chapter 2. Overview of Metrics I7 ]uil
[
Thus, each tree represents all possible paths of information flow into a particular global data
structure.
The formula defining the complexity value of a procedure is given by:
C], = (fan-in >< /Em-0uz)2
where,
C, = the complexity of procedure p.
fan-in = the number of fan-ins to procedure p.
fan-0ut = the number of fan-outs from procedure p.
The term (fan-in >< fan-out) represents the total possible number of combinations of an input
source and an output destination, and is raised to the power of 2 similarly with Brook’s law of
programmer interaction [BROF 75] and Belady’s formula for system partitioning [BELL 76].
Two other related complexities are defined, a module complexity and a level complexity. The
module complexity with respect to a global data structure is the sum of the procedure complexities
of those procedures that retrieve information from or update information to the data structure.
When viewing a system as a hierarchy of levels, the complexity of a level is defined to be the sum
of the complexities of the modules which comprise that level.
Hybrid Metrics
WoodlieId’s Syntactic Interconnection Model
Woodfield’s Syntactic Interconnection Model [WOOS 80] is a hybrid metric which attempts to
measure programming effort in terms of time. The general equation of the model is given by:
Chapter 2. Overview of Metrics l8[I
I
fan_in, ··ICB= Cm >< Z RC
k = 2
where,
CB = the complexity of module B’s code
CB = the intemal complexity of module B’s code
fcm_in, = the sum of the control and data connections for module B’s codeI
RC = a review constant
It is important to note that the intemal complexity for a module may be any code metric, however,
in Woodfield’s model definition Halstead’s Program Effort metric was used.
The model uses a review constant of lg-, which is a number previously suggested by Halstead
[HALM 77}. Woodfield completes his model by defining the fan_in of a module to be the combi-
nation of control and data connections for the module. A control connection exists for a module
each time it is invoked, while two modules, A and B are data connected if there is some variable
V such that the following two conditions are true:
1. the variable V is modified in B and referenced in A
2. there exists at least one data path set D(BA), between B and A, such that the same
variable V is not referenced in any d where d is a member of D(BA)
where a data path set, D(BA) is an ordered set of one or more modules {d,, dz, dz, ..., d„} such that
one of the following conditions is true:
1. B calls D,; D, calls Dz; ; D„-, calls D„; D„ calls A.
2. A calls D,; D, calls Dz; ; D„-, calls D,,; D„ calls B.
Chapter 2. Overview of Metrics 19
III
3. There exists some D, in D(AB) such that D, calls both D,-, and D,i, ; D,_, calls
D,_2; D,_2 calls D,_,; ...; D2 calls D,; D, calls B; and also D,+, calls D,+2 ; D,,2 calls
D,,3; ; D„-, calls D„; D„ calls A.
Henry and Kafura's Information Flow Metric
Henry and Kafura’s Information Flow metric may also be applied as a hybrid metric, in fact, the
metric has been tested in its hybrid form on the UNIX operating system [HENS 81], ]KAFD 85].
The formula for the Information Flow metric in its hybrid form is as follows:
Cp = C,p >< (fan-in >< fan-0ut)2
where,
C, = the complexity of procedure p.
C,,, = the internal complexity of procedure p.
fan-in = the number of fan·ins to procedure p.
fan-our = the number of fan-outs from procedure p.
Note that C], may be any micro metric’s measure of procedure p’s complexity. In this study the
Information Flow metric is combined with the length, effort and cyclomatic complexity measures.
The Software Quality Metric Analysis Tool
The software quality metric analysis tool, subsequently referred to as the analyzer, used in this study
has been developed over the last three years, at Virginia Tech, under the direction of Dr. Sallie
Henry and Dr. Dennis Kafura. The development of the analyzer has been an ambitious project
and preliminary results of its use are encouraging.I
Chapter 2. Overview of Metrics 20 II I
I
INTRI TSICBNP PIIi.\ESQQQSS.-AI TRANSLATOR I msg 1
WCODE RELATION
METRICS LANGUAGECODE
RELATIONMANAGER sus; z
(LEX) (YACC)
RELATIONS
METRIC 3czuzamok STM
CODE STRUCTURE HYB RIDMETRICS METRICS METRICS _
Figure 1. Logical Structure of' the Software Quality Metric Analyzer
Chapter 2. Overview of' Metrics 21
The analyzer takes source code as input, and calculates the values of the metrics discussed earlier
in this chapter. The first two stages process source code one procedure at a time, while the third
stage requires the information files from the entire system. A translation stage, a relation processing
stage and a metric generation stage comprise the transition from source code to metric values.
Figure 1 on page 21 shows the logical structure of the analyzer. The three stage approach to
complexity analysis is motivated by the syntactic and semantic differerrces of analyzeable languages.
Each source language to be analyzed must have its own code processor and translator, however,
there is only one relation processor.
The translation stage of the analyzer is the only language dependent stage involved in the metric
analysis. This stage simultaneously performs two functions. The first function involves the calcu-
lation of micro metric values for each procedure. The micro metric values are output to a file that
serves as input to the metric generation stage. The second function of the translation stage trans-
lates the source code to an intermediate language, the relation language [HENS 88]. The relation
language code preserves control and information flow while hiding proprietary information. The
translation stage of the analyzer has been implemented for the Pascal, ’C’, FORTRAN, and THLL
programming languages.
The relation processing stage of the analyzer takes the relation language code, produced in the
translation stage, and outputs information flow relations [KAFD 82]. The information flow re-
lations serve as input to the metric generation stage.
The metric generation stage, or "back end", of the analyzer has as input the two files, micro metric
file from stage one and the relations from stage two, and provides, via a menu driven interface, the
means to run, examine and output each of the previously mentioned micro, structure and hybrid
metrics. Module and level definition, analysis and output facilities are also provided.
Chapter 2. Overview of Metrics 22J
IFConclusionThe
software quality measurement and analysis sector of the software engineering community has
made great strides in the analysis of real time software systems. Studies have shown that many of
the metrics developed do in fact identify stress points and areas with high error counts in existing
systems. Language independence and the ability to identify different types of complexities in soft-
ware have also been demonstrated. However, until recently, few attempts have been made to unite
the processes of design and analysis. This unification is necessary to provide software engineers the
ability to create reliable software systems. This study is one of two attempts to provide this unifi-
cation. The other study focuses on use of a textual design language ]SELC 87].
l
EChapter 2. Overview of Metrics 23 I
Chapter 3. Graphical Language Translation
Introduction
This Chapter describes the translation of the graphical language to its analyzeable form. Trans-
lation of GPL is a twofold process. First the source code is analyzed to generate code metrics used
by stage three of the analyzer. The second process is the generation of relation language code while
preserving the control and information flow of the corresponding source code. A detailed de-
scription of the graphical language, the relation language and the actual translation process is pre-
sented.
GPL
Introduction
The Dialogue Management System is a software system development environment being developed
at Virginia Tech. Its underlying methodology is called SUPERvisory Methodology and Notation,
Chapter 3. Graphical Language Translation 24
Eor SUPERMAN [HARII 85]. One of SUPERMAN’s primary targets in software design is the
separation of dialogue, communication between a user and the system, and computational design.
This separation of system design is motivated by the impression that the best dialogue designers are
not necessanly programmers and vice versa. The Dialogue Management System provides a
graphical programming language, GPL, with which each type of designer may specify his design.
GPL has a set of symbols specifically used for dialogue design and a set of symbols used for com-
putational design with some symbols appearing in both dialogue and computational designs. These
"linking" symbols tie the two parts of a system’s design together. In this study, the computational
development environment and the symbols in GPL used to create the computational portion of a
system’s design are of interest.
The basic building block for a GPL computational design is a Supervisory Cell which contains a
supervisor and a Superyised Flow Diagram, or SFD. The SFD shows the flow of control and in-
formation within the cell. Intuitively, a supervisory cell represents the definition of a single sub-
routine in a system. Figure 2 on page 26 presents the symbols in GPL used for computational
design and Figure 3 on page 27 presents a simple example of a supervisory cell. A nontrivial
sample design appears in Appendix A with the corresponding source code located in Appendix C.
The following sections discuss the syntax and semantics of each symbol and the infonnation asso-
ciated with each supervisor.
· The Computational Design Symbols in a SFD
Control Flow Arcs
Control flow arcs show the flow of control throughout an SFD. These arcs can connect any two
symbols of GPL together with the exception of databoxes, defined below. The arc labeled x = l
in Figure 3 on page 27 is a control flow arc. Control flow arcs may or may not have a conditional
associated with them. If there is only one control flow arc leaving a symbol there is no conditional
Chapter 3. Graphical Language Translation Z5
I
oc—r¤«•¤m¤ omoguc F¤¤¤ü¤¤ ¤CB
® OÄDecisionSUN Rei urn Daß DW
Cont rol Flov Li ne
Data Fl ov Li ne
Figure 2. Computational Design Symbols in GPL
Chapter 3. Graphical Language Translation 26
' II
*i'*“'9°' factor integer
factorialX
: lI Dbox I
I
factor t=—+ factorial-+‘x•t X ' gfact0r*x;
u-————-lI+— Dbox
Figure 3. A GPL Supervisory Cell
Chapter 3. Graphical Language Translation 27
uI
on the arc, however, if there is more than one arc leaving a symbol there must be a conditionalI
associated with each arc that leaves the symbol. A conditional associated with an arc is a valid
boolean expression.
Data Flow Arcs
Data flow arcs are used to bind databoxes, defined below, to functions, also defined below. There
can only be one data arc connecting a subroutine and a databox, and there is never a condition
associated with a data arc. The dashed arcs leading into and out of the box labeled faczorial in
Figure 3 on page 27 are data flow arcs.
Start
There is exactly one start symbol per SFD. The start symbol marks the beginning of the execution
of an SFD. lt has no arcs coming into it, yet, it may have any number of arcs leaving. The circle
in Figure 3 on page 27 is a start symbol.
Return
There is at least one retum symbol per SFD. Retums have no arcs out of them, but they may have
any number of arcs entering them. The return symbol represents the termination of execution of
an SFD. Returns have no parameters and therefore are not used to return variable values. The
conclusion is that there are no functions that retum values in GPL. The two triangles in
Figure 3 on page 27 are return symbols.
Chapter 3. Graphical Language Translation 28
u
Decisions
A decision symbol may have any number of arcs entering it and any number of arcs leaving it. Its
semantics resemble those of the Pascal "case" and ’C’ "switch" statements. Each arc that leaves a
decision must have a boolean expression associated with it. There are a minimum of two arcs
leaving a decision symbol. The diamond in Figure 3 on page 27 is a decision symbol.
Databoxes
GPL databoxes are used to specify the actual input and output parameters to a subroutine call.
They are sometimes called binding boxes since their content consists of the actual parameters and
the names of their respective formal parameters. Databoxes have either a data flow arc leading into
the box, i.e. an output parameter, or out of the box to identify an input parameter. The two rec-
tangles labeled Dbox in Figure 3 on page 27 are databoxes.
Inner Code Block (ICB)
An ICB is a symbol that contains the actual code of a system. The code is syntactically and se-
mantically correct high level language code. In theory, all of a program’s code could be in an ICB,
however, this use of an ICB is not intended. An ICB in a completely refined design contains only
assignment statements. Any number of arcs may enter and leave an ICB. The symbol labeled
x: = x — 1; in Figure 3 on page 27 is an ICB.
Chapter 3. Graphical Language Translation 29
Functions
The function symbol represents a call to a subroutine that contains no dialogue. A GPL function
is unlike a Pascal function since it does not retum a value. Each function symbol contains a name
used to identify the corresponding supervisor for that function’s definition. Functions may have
any number of arcs leading into and out of them. Any time a function has more that one arc
leaving it, each of the arcs must contain a conditional indicating the conditions necessary to follow
that arc. If the function has input and output parameters in its definition, then there must be input
and output databoxes attached, via data flow arcs. If the function does not have both input and
output parameters, it is only necessary to have the appropriate databox (or none). Function defi-
nitions are not nested in GPL, therefore, references to the same function name in different SFDs
refer to the same function definition. The box labeled factorial in the SFD in Figure 3 on page
27 is a GPL function.
Dialogue
Dialogue symbols represent input and output operations and may have any number of arcs leading
to them and leaving from them. In the Dialogue Management System, this is where the dialogue
designer, or author, takes over the design process. Computational designers either get information
from a dialogue function, input, or give information to a dialogue function, output and are not
concerned with how the information is manipulated. In the development of an SFD, a computa-
tional designer does not expand or further develop dialogue functions. Dialogue symbols, like
functions, may have databoxes attached to them, via data flow arcs. There are no dialogue symbols
in Figure 3 on page 27.
Chapter 3. Graphical Language Translation 30
DC—Functions
p DC-Functions, or Dialogue—Computation Functions, represent subroutines that contain both di-
alogue and computational operations. Aside from containing calls to dialogue functions,
DC—Functions have the same syntax, semantics and requirements as functions. There are no
DC-Functions in Figure 3 on page 27.
The Supervisor
There is only one supervisor per SFD, and it appears at the top of the diagrarn. Associated with
the supervisor is a list of input parameters, a list of output parameters, a list of local variables, a
name, and an SFD. \Vhen defining a supervisor’s pararneters and local variables, each < ID >
given has a named type associated with it, however, as far as GPL is concemed there are no
meaningful types or ways to define them. Therefore the types specified, are meant to be meaningful
only to the designer and programmer. The box at the top of Figure 3 on page 27 labeled
factorial is a
supewisor.ObservationsGPL supports many desirable concepts of software engineering. First, there is no means of defining
global variables. To some this may appear as a disadvantage, however, eliniinating the ability to ‘
define a global variable is an excellent means to control its use. Secondly, and more importantly, Ä
by limiting the size of the work area, the definition of shorter more modular routines becomes na-
tural. TChapter 3. Graphical Language Translation 3l :
lÄ l
I
I
GPL has some limitations that are particularly annoying. First is the inability to define system
constants, needed for readability purposes and second, the inability to defme libraries of routines
for the purpose of reusability.
The Relation Language
Introduction
The relation language [HENS 88] was developed to address one of the major problems facing
software engineering rescarchers, acquiring "real world" data to perform Validation experiments.
One good source of data, software organizations, is unavailable due to the proprietary nature of the
products. Software organizations do not want their algorithrns or the error history of their products
released into public domain. With this in mind, the relation language was designed to serve as an
intermediate language that can protect the software organizations’ right to privacy while providing
sufficient information for software engineers to test their measurements. In this discussion a brief
description of the relation language constructs, presented in Figure 4 on page 33, is given.
Relation Language Constructs
Variables
A relation language program allows for the declaration of three types of variables: local , szmct and
const. The Variable type one chooses is dependent upon the usage of the Variable in the original Isource code. Distinctions are made between data objects as being local variables, complex struc- I
tures and constants, Variables defined as type local are considered local to the routine in which they Iare declared. Determination of local variables is not always a simple process due to the presence I
II
Chapter 3. Graphical Language Translation 32 I
I
I
I
Déttlafatldn statements
LOCAI. · local variable declarationSTFIUCT · non—local variable declarationCONST · defined constantEXTEFINAL · external procedure declarationPBOCEDUBE — procedure declarationFUNCTION - function declarationINTBINSIC · built—in function
Executable statementsCOND · all conditionals‘l00 · all constantsz- · assignment; · statement separationBEGIN END · grouping statement& · conditional variable separator
Figure 4. Constructs in the Relation Language
Chapter 3. Graphical Language Translation 33
u
of complicated high level language constructs like Pascal’s "with" statement and FORTRAN’s
"comrnon" block. Variables defined as type struct, are treated as global variables, they may be
defined anywhere in a program, but, they are accessed globally. Variables defined to be type const
represent declared constants.
Statements
The four types of statements that can be identified in a relation program are: assignments, condi-
tions, procedure calls and retums. Each of these statement types is discussed individually.
Assignmcnts
Assignment statements are similar to those in any high level language, with one exception, any
arithmetic operators appearing in the original source code are replaced by "&"’s. It is not necessary
to know the identity of the original operator in order to perform structure metric analysis, so the
substitution disguises the content of the original source.
Conditions
As with arithmetic operators, it is unnecessary to know the type of conditional represented in order
to derive the flow of control that is present. One only needs to know that the condition existed,
and the variables that are needed to evaluate the decision. Looping constructs are simply replaced
by a condition statement and corresponding block of statements that the loop encompasses. De-
cision statements similar to Pascal’s "case" and "if then (else)" are replaced by a condition
statement, cond, that contains the original decision construct’s boolean expression variables. A
corresponding block of statements associated with the conditional includes those blocks of state-
Chapter 3. Graphical Language Translation 34
l
ments from the original source code that are executed as a result of the conditional’s value. This
means that the statements from each of the specific choices in a Pascal case statement would be
grouped together to form a single block of statements to be associated with a single condition
statement.
Procedure Calls
Procedure calls are identical to those in other high level block structured languages like Pascal and’C’.
Returns
The return statement in a relation language program is similar to one in the ’C’ programming lan-
guage and is used to represent the return value of a function.
Procedure Declarations
Procedures in a relation program must be declared prior to their use. Three methods of procedure
declarations are available. The first method is to give the procedure heading, including a procedure
identifier and a list of formal parameter names, followed by the relation language statements that
are included ir1 the procedure. This is the most common method of procedure declaration and is
used to define procedures local to the current module. Declaring a procedure as external is the
second method of procedure declaration. This method serves a dual purpose that allows relations
to be defined over many separate modules and provides for the translation of subroutines that call
each other. The final method provides for the declaration of intrinsic functions. The relation lan-
Chapter 3. Graphical Language Translation 35
—
II
I
guage has no intrinsic functions and therefore requires all intrinsic functions called in the original
source code to be defined in the corresponding relation program.
Obscrvations
It is apparent that a relation program bears little resemblance to the source program from which is
derived and that the relation language provides all of the necessary constructs to represent the code
from a myriad of source languages. In this study the relation language is used to represent GPL
source code in order to perform structure metric analysis. The translation from GPL to the Re-
lation language is presented next.
The Translation From GPL to The Relation Language
Introduction
The Dialogue Management System provides a graphical editor for the creation and modification
of system designs and the GPL relation language translator uses the same database as the editor for
retrieval of SPD information. Much of the translation from GPL to relation language is straight
forward and involves simple database information retrieval. The description of the translation is
presented from the point of view of the target statements that need to be generated to correctly
represent the flows of information and control for a single subroutine definition and declaration in
the relation language. Since there are no global variables or constants in GPL, it is sufficient to
discuss the translation of a single subroutine. The translation of the design, found in Appendix A,
is located in Appendix B and the algorithm for translation follows:
Chapter 3. Graphical Language Translation 36
I
I
I
Routine Translate_GPL_Design;for here each SPD;
{generate procedure header;generate local variable declarations;Translate_SPD;}
end;
Procedure Header Generation
Generation of the procedure header involves little processing other than information retrieval. The
procedure name is retrieved from a database relation in addition to a list of the input and output
parameters for the procedure. GPL parameters may be identified as input parameters, output pa-
rarneters or as both input and output parameters. Since the relation language does not distinguish
between input and output parameters, it is necessary to perform an intersection on the lists of input
and output parameters and generate the resulting set of parameters for the procedure header.
Local Variable Declarations Generation
Generating local variable declarations involves the retrieval of the list of variables for the procedure
and the generation of a declaration for each one.
Relation Language Code Generation for SFD Members
The term "member" refers to each symbol in a SPD. Many of the member types in a SPD require
no code to be generated in the relation language. These member types include: start, return,
databox, decision, data arc and control arc. Elimination of these member types leaves only those
Chapter 3. Graphical Language Translation 37
I
member types for which there is a corresponding statement type in the relation language. The al-
gorithm for translation of a SPD follows:
Routine Translate_SPD;for each function, DC-function, dialogue function
and ICB;{generate_conditional;generate_code;l
end;
One might believe that the decision member type ought not appear on this list due to the existence
of the condition statement in the relation language, however, the decision symbol and the condition
statement have different semantics. A decision symbol dictates the flow of control within an SPD,
where a condition statement dictates the flow of information within a procedure. The condition
statement contains the list of those variables whose values determine whether or not a certain
statement gets executed. The statements that are effected by the values of "condition" variables are
easily found during visual examination of a SPD. Program constructs like loops and "if then (...
else)"s are quickly recognized. Control flow, however, is difficult to discem given the limited in-
fomiation available in the database, including which member each arc starts at, goes to and whether
or not the arc has a conditional on it. Therefore, a backwards approach is taken to determine the
flows of information. Por each of the member types, function, DC-function, dialogue function and
ICB, a single conditional is generated that contains each of the conditionals from any of the paths
that might have been traversed to reach the current member. This generated conditional is forrned
by following all of the paths that end at the current member backwards to the start symbol. Each
time an arc containing a conditional is traversed a decision node has been found and it must be
determined whether or not its conditionals must be included in the generated conditional. All paths
out of the decision node are followed until a retum symbol or the original node is reached. The
method for generating a conditional in algorithrnic form is:
Chapter 3. Graphical Language Translation 38I
Routine generate_conditional;if ( not at the start symbol)
{if ( current node is a decision node)
{if ( conditionals_belong )
add conditionals;}
follow all input arcs backwards;l generate_conditional;W1
end;
If all of the paths out of the decision node lead to the orignal node, the conditionals are not in-
cluded since the node will be executed regardless of the values of the condition variables, however,
if any of the paths lead to a return symbol, the conditionals are included in the generated condi-
tional. An algorithm for tracing conditionals is:
Routine conditionals_belong;for each outgoing arc;
{follow paths forward;if (any path reaches a retum symbol)
include conditionals;else (path reaches node for which a conditional is being generated)
do not include conditionals;}
end;
Since there is only one start symbol per SFD and all paths eventually terminate at a retum symbol,
this algorithm is guaranteed to terminate. No check to see if a variable is already a part of the
generated conditional is made because redundancy of flows of information is removed by the metric
generation stage of the analyzer. The algorithm for code generation for DC—functions, functions,
dialogue functions and ICBs followsz
Chapter 3. Graphical Language Translation 39
nl
Routine generate_code;if ( member is a DC-function or function)
generate procedure call;if( member is a dialogue function)
generate appropriate updates to INPUT and OUTPUT structs;if( member is an ICB)
call target language translator;end;
Functions and DC—Functions
For the member types function and DC-function a condition statement and a procedure call are
generated. The condition statement is generated as above, and the procedure call is generated by
matching up the actual parameters with the corresponding formal parameters.
Dialogue Functions
For dialogue members it is necessary to declare two global structures INPUT and OUTPUT since,
any input or output operation is actually an update to or an access to a global structure, standard
input or standard output. For input dialogue operations an assignment statement of the following
form is generated:
< variable> = INPUT
For output dialogue operations an assignment of the following form is generated:
OUTPUT = < variable >
Chapter 3. Graphical Language Translation 40
—
Inner Code Blocks
For ICBs a conditional statement is generated, and a call is made to the translator for the target
high-level language to output the proper relation language code for the code in the ICB. This call
is possible since the contents of an ICB are syntactically and semantically correct code.
The Generation of Micro Metric Values
Micro metric value calculations are performed concurrently with the translation of GPL to relation
language and are discussed in the following sections.
Length
Length appears to be something difficult to measure in a graphical language and perhaps it is a
meaningless measure, however, if one views the length of a design as a predictor of lines of code in
the resulting system, a measure is feasible. Length of a GPL design is given by:
length = #members + length of ICB code + #decisions
The formula is derived from intuition. Each member of an SFD is likely to produce a line of code,
regardless of the member type, so initially length is set to this value. Then, each time an ICB is
encountered, the ICB length, retumed by the target language’s translator, is accumulated. Finally,
the number of decisions is added to account for an additional label that is likely to be present in the p
resulting source code.
*Chapter 3. Graphical Language Translation 4l,
1
1 1___....,L>
Q 1-;-:1ZT'...£
vt 61 = 1
1 1 ,4;1
1 1
V1 G) = 3
Figure 5. Multiple Exit Point Handling for Cyclomatic ComplexityCalcuiationChapter
342 I
II
McCabe’s CyclomaticComplexityThe
cyclomatic complexity, I/(G), is perhaps the easiest micro metnc value to caleulate. Recall,
from chapter two, that graph theory states that a graph’s cyclomatic number is given by:
V(G) = E — N + 2
where,
I/(G) = the cyclomatic number of a graph
E = the number of edges in a graph
N = the number of nodes_or members in a graph
The value of I/(G) in GPL is initialized to the number of arcs minus the number of members. This
alone, however, is not sufficient since GPL allows for any number of returns in a SPD. Cyclomatic
complexity requires that the graph have unique entry and exit points. To account for this, each
time a return symbol is encountered during translation, the cyclomatic number is increased by one,
then instead of adding two at the end we only add one, to take out a single node for the unique exit
point. Pigure 5 on page 42 displays two SPDs, that are semantically equivalent, and their corre-
sponding Cyclomatic Complexities, calculated without taking the multiple exit points into consid-
eration. The complexities are different, even though the graphs are semantically the same.
IHaIstead’s Software Science I
II
Perhaps the most difficult micro metrics to calculate, due to the ambiguity in determining what is Ian operand and what is an operator, are Halstead’s Software Science metrics. This study defines I
the required counts, unique and total operands and unique and total operators, on a graphical 1language. The counts of operands are straight forward and include anything that appears as text I
in a SPD: the supervisor name, parameter and variable names, variables that appear in conditionals, I
Chapter 3. Graphical Language Translation 43 I
I
variables from the databoxes and the names of called subroutines. The counts of operands are also
modified by the high level language translator used to translate the code in the ICB’s. The counts
of operators in GPL are less intuitive than that of operands, however, bearing in mind Halstead’s
intuitive definition of the N value, the vocabulary of a routine, the counts become more obvious.
The counts of operators in ICBs, performed by the high level language translator, are accumulated
with those returned by the conditional parser, with identification of operators being performed as
in conventional, textual languages. The number of members in a SPD and the number of control
and data flow arcs in a SPD are also accumulated. lntuitively, the counts of members and arcs as
operators is necessary since the members and arcs and their semantics are part of a designer’s
working vocabulary.
Conclusion
The methods presented do not represent the first attempt at translation and micro metric calcu-
lation, they are the result of many hours of thought and experimentation. A great deal of time was
spent in attempting to make the translator behave logically in recognizing the farniliar programming
constructs in a SPD. The resulting solution is motivated by the recognition that GPL is not a block
structured language and that it is very difficult to impose such a structure with the available infor-
mation. Chapter four presents the results of metric analysis after applying the above transforrnation
to GPL designs.
II
Chapter 3. Graphical Language Translation 44 I
I
II
Chapter 4. Complexity Measurement
Introduction
In this chapter, the results of analyzing GPL design complexities are given. Complexity measures
of GPL designs are presented along with equations, for each of the metrics, that allow the com-
plexity of code corresponding to a GPL design to be predicted. An examination of GPL as a design
tool is also briefly reported. A parallel measurement and prediction analysis of ADLIF, a general
purpose PDL used in this study, is given as well.
The Experiment
The data in this study was collected from an assignment, given in a graduate level operating systems
course consisting of twenty~two graduate students. Students simulated the management of
consumeable and reusable operating system resources to detect and prevent deadlock, respectively.
The banl<er’s algorithm is used for deadlock prevention and knot detection algorithrns are used for
deadlock detection. In this study, one half of the class designed the program using GPL and the
Chapter 4. Complexity Measurement 45
I
other half used a general purpose textual design language, ADLIF, which is the subject of another
complexity analysis study [SELC 87]. ADLIF is an attempt to structure pseudocode, i.e. a PDL.
A copy of the assignment can be found in Appendix D. The assignment required the students toA
submit an initial design, one week prior to the assignment due date, a revised design, on the due
date, and the Pascal source code and simulation results. Pascal was required to eliminate any dif-
ferences resulting from using different programming languages. The revised designs were included
as a part of the assignment for two reasons. First, to enable the evaluation of the two design tools
in terms of the amount of change required to achieve a working system and second, to allow for
the iterative refinement of the initial designs. Only the eighteen correct projects were used with nine
of the projects coming from each group.
Data Preparation
In order to perform statistical the correlations of initial design to revised design and revised design
to source, and to perform the regression analysis, it is necessary to have the same number of data
observations, procedures, in the data being compared. It is possible and in fact likely that a design
will not have the same number of routines as the source code. Often the source code will use many
routines to perform the function of a single routine specified in the design. Another cause of ex-
traneous routines in the source code may be the inability to refine a particular type of function in
the design language like dialogue functions in GPL. Similarly, a routine may appear in a design,
but, its function is combined into another routine in the resulting source code. It is necessary to
incorporate the complexity measures of all of the routines in the source code into the data to be
analyzed. When a routine exists in the source and does not have a corresponding routine in the
design one accumulates the complexities of the more refined routines with the complexity of their
parents. This is a valid operation since the design required the function to be performed and
therefore its complexity is present in the design. The case where a routine is present in the design
but not in the source code identifies a design that is not properly refined. One problem arises as a
Chapter 4. Complexity Measurement 46
l
result of the accumulation process. The complexity of the main program in the source code be-
comes unrealistic since many routines are accumulated into it. This occurs when programmers do
not nest procedure declarations and as a result the only place for a routine’s complexity to be ac-
cumulated is in the main program. Beyond programming style, it is possible that the language
being used, for example GPL and ’C’, may not allow procedure nesting and again the routine’s
complexity must be accumulated in the main program. As a result of language limitations and the
programming style, the main program’s complexity no longer reflects the actual complexity of the
code. In this study the main programs were removed from the data prior to perforrning the statis-
tical analysis. Three hundred and twenty—three procedures from eighteen projects were used in this
analysis.
Data Presentation Information
Table 1 on page 48 contains the abbreviations that are used in the tables displayed throughout this
study. An abbreviation for each of the nine metrics calculated is given. ‘
Comparison of Initial and Revised Designs
Comparing the initial and revised designs provides a measure of the change required inorder to
achieve a working system. This measure is meaningful only if there is a good correlation between
revised design and source code [VINJ 87]. In this study there is a good correlation between revised
design ar1d source code, and that correlation is in the next section. Table 2 on page 49 displays the
correlations of initial to revised designs for both the GPL and ADLIF groups. The correlations
between the micro metrics in GPL designs are higher than those in ADLIF designs, however, the
converse holds true for the structure and hybrid metrics. Neither of these results is significant due
to the high degree of correlation found in all cases. One concludes that the design languages are
Chapter 4. Complexity Measurement 47
I
I
I
Table l. Metric Abbreviations Used in Data Presentation
Metric AbbrcviationLength LOC
NVolume VEffort ECyclomatic Complexity CCInformation Flow INFOInformation Flow with Length INFO-LInformation Flow with Effoit INFO-EInformation Flow with Cyclomatic INFO-CC
Chapter 4. Complexity Measurement 48
Table 2. Correlations of Initial to Revised Designs
GPL
LOC N V E CC INFO INFO·L INFO—E INFO-CC0.884 0.917 0.972 0.942 0.935 0.877 0.955 0.710 0.952
_ ADLIF
L()C N V E CC INFO INFO-L INFO-E INFO—CC0.881 0.859 0.891 0.890 0.825 0.982 0.988 0.988 0.932
GPL Design Corre/azions wi:/1 no Outliers
LOC N V E CC INFO INFO-L INFO—E INFO-CC0.905 0.943 0.974 0.978 0.944 0.924 0.829 0.926 0.865
Chapter 4. Complexity Measurement 49
F
equally effective at helping the designer to create a good design, where a good design is one that
accurately reflects the structure of the corresponding working source code. Looking at Table 6 on
page 60, which gives the mean complexities of GPL and ADLIF designs, it is interesting to note
that the complexity of GPL designs actually went down, for the structure and hybrid metrics, from
the initial to the revised designs. Further investigation revealed that two procedure’s complexities
are responsible for the difference, rernoval of these routines produced complexities that are closer
together. The two outlying procedures were found to be routines that had been reorganized and
actually performed different functions in the revised design while keeping the same name as in the
initial design. The revised mean complexities are found in Table 6 on page 60 and the revised
correlations are in Table 2 on page 49.I
Regression Analysis of GPL and ADLIF
Explanation
Regression analysis involves the comparison of sets of data between which there is some assumed
inherent relationship. In simple linear regression one is concemed with a single independent and
a single dependent variable and an attempt to derive a linear prediction, or regression, equation
]WALR 78]. In this study, a simple linear regression is performed, with the complexity of design
as the independent variable and complexity of the source as the dependent variable, in an attempt
to derive equations which would allow a designer to estimate the complexity of the system being
developed prior to its implementation. Regression analysis is performed for each of the calculated
metrics.
Chapter 4. Complexity Measurement 50
GPL
A Prior to the performance of the regression analysis on the GPL revised designs and GPL designed
source code, a correlation between the two sets of values was performed to see if there was any re-
lationship between the two. Table 3 on page 53 gives the results of the coxrelation. The high
correlations indicate that a relationship between the data sets may exists, so the regression analysis
is performed. Table 4 on page 54 contains the equations that result from the regression analysis
of the GPL revised designs and the GPL designed source code. The column labeled Coef gives the
value of the y·axis intercept and the slope of the regression line for the corresponding metric. The
column labeled Std Err gives the standard error found in the calculation of the coefficient and the
column labeled t- Va/ue gives the value from the Student T distribution and is used for significance
and confidence testing. The coefficient will fall within the range of plus or minus two times the
standard error. A t-Value of greater than two generally represents ninety-five percent confidence
that the corresponding coefficient is correct. The t-Values for each of the metric’s slope are well
above two and ninety-nine percent confidence in their values can easily be assumed. Ninety-nine
percent confidence in all of the y-axis intercepts, except Cyclomatic and Information Flow with
Cyclomatic, can also be assumed. The intercepts for the Cyclomatic complexity and the Informa-
tion Flow Complexity combined with the Cyclomatic complexity can be assumed to be zero be-
cause of the low t-value [VINJ 87]. Figure 6 on page 55 gives a plot of the actual data observations,
the regression line and the ninety-five percent confidence lines for the GPL information flow
measure. The information flow metxic was selected for this example and similar plots for each of
the GPL measures are found in Appendix E. The prediction equation for a procedure’s informa-
tion flow complexity is as followsz
y = 1.103x + 205.167
where,
y = the predicted source code information flow complexity of the procedure
x = the calculated design information flow complexity of the procedure
Chapter 4. Complexity Measurement 51
With ninety·five percent confidence the predicted y value will fall within the confidence interval. iSimilar equations for each of the other metrics may be obtained by reading the coefficient values
in Table 4 on page 54.
ADLIF
A correlation analysis between the ADLIF revised designs and the ADLIF designed source code
was performed prior to doing the regression analysis to determine if there was any relationship be-
tween the two sets of data. Table 3 on page 53 contains the results of the correlation. The high
correlations indicate that a relationship between the data sets may exist, so the regression analysis
is performed. Table 5 on page 56 displays the equations that result from the regression analysis
of the ADLIF revised designs and the ADLIF designed source code. The table is shown in the
same format as for the GPL regression analysis and the values given represent the same items. The
t-Values for each of the met1ic’s slope are, once again, well above two and ninety-nine percent
confidence in their values can is assumed. Ninety-five percent confidence in all of the y—axis inter-
cepts is assumed and in many cases ninety-nine percent confidence can be assumed. Figure 7 on
page 57 gives a plot of the actual data observations, the regression line and the ninety—five percent
confidence lines for the ADLIF information flow complexity measure. Similar plots for each of the
ADLIF measures are found in Appendix F. Note, when comparing the GPL and ADLIF plots
that the scales may vary.
Conclusionl
The results presented in this chapter indicate that it is possible, given the complexity of a GPL or i
ADLIF design, to predict the complexity of the corresponding source code. However, it is im-
portant to note that designs with different levels of refinement may produce different results. The
Chapter 4. Complexity Measurement 52
*
1
Table 3. Correlations of Revised Designs to Designed Source
GPL
LOC N V E CC INFO INFO-L INFO-E INFO—CC0.78 0.702 0.66 0.508 0.793 0.808 0.788 0.737 0.752
ADLIF
LOC N V E CC INFO INFO·L INFO-E INFO-CC0.849 0.834 0.843 0.749 0.711 0.901 0.887 0.832 Q
Chapter 4. Complexity Measurement 53
Table 4. Regression Line Equations and Statistics for GPL Designs
GPL Regression Line Information_—
Cecf StdE¤LengthIntercept 3.878 0.871 4.454
Slope 0.826 0.055 15.105N Intercept 22.258 8.781 2.535
Slope 1.141 0.096 11.947‘ Volume lntercept 211.697 42.367 4.997
Slope 1.639 0.154 10.643Effort Interccpt 12892.83 2666.116 4.836
Slope 2.222 0.311 7.15Cyclomatic lntercept -0.03 0.334 -0.09
Slope 1.325 0.084 15.799Information Intercept 205.167 77.814 2.637Flow Slope 1.103 0.066 16.629Info. with Intereept 4985.403 1709.029 2.917Length Slope 1.278 0.082 15.524Info. with Imtcrcept 14976060 4711310 3.178Effort Slope 3.025 0.229 13.235Info. with Intercept 1284.167 735.014 1.747Cyclomatic Slope 1.539 0.111 13.812
Chapter 4. Complexity Measurement 54
I
__ I
Q_
1. hJ Uvv~ l'l
«’
SCSI — I,X ,'
,,’
• V 1,’ ,’’
’
,','
I,. 1 / ',’ /
„·‘’ 1
' 1
7SCI —Q Q,
1,’
I 1
SCSI ·„ , ,,
ll vl
I 1 lal
-I"
SÜÜ. • lv ,’I 1
‘
.' _' ,,'2 l' I1
Inge * 1,Ide- ° b •
Q' F ,1
:
"
lv
Q,’ "/ ,·
I 1V 1
Q ,„ »" ‘ ’/ ,’e¤UL' ° I; ,'
, ,'Q I 1
V 1
V II l' • •¤ un lv
,
V IECC} ·.’ ‘ ,‘
v s _'P ,'
xx:, • ,'
A I‘
1CCII·_ */;_„,v 1 P ',’
_ in Dr v l'I
vu,‘l
Gkxu { 1
; j:. · . :«P
cfgßf •!¤P**
L •eI•IL See- ;ee- Hee- edees eee- 'ee- evee -·ee- •eee-
ZESISM
Figure 6. Regression Line and 95% Conlidence lines for Information Flow Complexity in GPL
Chapter 4. Complexity Measurement 55
Table 5. Regression Line Equations and Statistics for ADLIF Designs
ADLIF Regression Line Information—— Coef Std Ed t·V@d¤@Length Intercept 2.25 0.829 2.714
Slope 0.854 0.041 21.101N lntercept 16.452 6.563 2.507
Slope 0.947 0.048 19.802Volume Intercept 87.143 33.769 2.581
Slope 0.943 0.046 20.529Effort Intercept 5698.626 2032.574 2.804
Slope 1.079 0.073 14.833Cyclomatic lntercept 1.166 0.313 3.723
Slope 0.776 0.059 13.262Information lntercept 347.4512 106.084 3.275Flow Slope 0.707 0.026 27.197Info. with Intercept 13294.48 2605.205 5.103Length Slope 0.48 0.019 25.235Info. with Intercept 22514560 5495677 4.097Effort Slope .712 0.036 19.633Info. with Intercept 3076.348 755.927 4.07Cyclomatic Slope 0.501 0.029 17.505
Chapter 4. Complexity Measurement 56
L
\
SSURZE‘
•
. ee L' 7 v
lB.'J0I2 ·‘. ·
° ,'I·,
xeoon -1„‘)„ l'
lr,
158037• 1, ,"
Z300i
—12083·Z20CC ~__,·'1008355083·1v
•J;
,,usoo.- -_
/_,
~r~•«' _: • -,n x
v,
F Hüs „ e 2 l'
. ,' • .’P I D ;
ESGE · ,· -..,·"
; .‘ ‘ /• ve
ÄÖÜ: • r ,‘, 3 •° .’,. -·' •
•=soc:-17,",
rf}:",
ÄQQP I '{ben ° / 4lr I/• v_ Ä D l'
· ··' ° ·’• 90b P lr
Ü
" ·' ;v,
g inhntn
s .,-ee, äeee, Zeeb,?
IE5 Z Sk ·
Figure 7. Regression Line and 95% Confidence lines for Information Flow Complexity in ADLIF
Chapter 4. Complexity Measurement 57
lil
designs used in this study are at a very detailed level of refinement and the accuracy of the equations
reflects the detail.
Chapter 4. Complexity Measurement 58
Chapter 5. Comparison of Design Tools
Introduction
In this chapter a comparison of GPL and ADLIF is presented. Speciiically, the complexities of the
designs and the complexities of the corresponding source code are compared. Both the initial and
revised design complexities are given.
Comparison of GPL and ADLIF Design Complexities
Table 6 on page 60 presents the mean complexities of both the revised and initial designs for all
of the GPL and ADLIF data. The complexities of the GPL designs are significantly lower than
the ADLIF designs. The difference in complexities, however, is misleading due to the extreme
difference in the nature of the languages. The semantics that can be expressed in a single symbol
in GPL may take several keywords and symbols in ADLIF. Therefore, lower complexities of GPL
designs are not necessarily an indication of less complex systems. Given a GPL and an ADLIF
design for the same system, the GPL desigr1 should be measurably lower in complexity.
Chapter 5. Comparison of Design Tools 59
I
Table 6. Mean Complexities of Initial and Revised Designs
GPL
Design LOC N V E CC INFO INFO-L INFO-E INFO-CCinitial 14.032 85.948 251.656 6374.66 3.552 14129.62 1362948 808062000 337889revised 14.519 87.89 261.617 6442.96 3.643 1003.13 28336.84 18113410 8164.23
ADLIF
Design LOC N V E CC INFO INFO-L INFO-E INFO-CCinitial 18.166 118.429 617.606 18489.24 4.2 16456.74 718024 678874000 48765.1revised 19.536 128.219 675.426 21049.67 4.47 21447.1 882221 845066000 61844.7
GPL Mean Design Comp/exities wir/1 no Out/iers
Design LOC N V E CC INFO INFO-L INFO—E INFO—CCinitial 13.375 80.678 233.974 5698.52 3.375 688.395 10431.23 7348219 2930.033revised 14.151 84.618 246.842 6009.91 3.52 686.559 12050.82 8206303 3302.488
Chapter 5. Comparison of Design Tools 60
II
Comparison of GPL and ADLIF Designed Source Code
In comparing the GPL and ADLIF designed source code, the proeedures were divided into five
functional units, or modules, including: tape request processing, tape release processing, message
sending processing, message receiving processing and deadloek detection. A sixth unit was defined
as the complexity of the entire system. Table 7 on page 62 presents the average module complex-
ities for both the GPL and ADLIF designed source code. The complexities of the GPL designed
source code are considerably lower than those of the ADLIF designed source code. Table 8 on
page 63 presents the average ratio of complexity of the GPL designed source to the complexity of
ADLIF designed source. The ratios of the micro metries are higher than those of the structure and
hybrid metries with an average ratio of 71.7%. The average ratio of the structure and hybrid met-
rics is 17.4%. These ratios and complexities indicate that GPL is the better tool for designing
program structure. The structure and hybrid metric ratios in Table 8 on page 63 show that the
structure of the GPL designed source code is nearly six times less complex than the ADLIF de-
signed source code. Due to the small sample size it is necessary to perform a statistical significance
test on the module complexities. Table 9 on page 64 gives the calculated t-values from the Student
T distribution for each of the metries in each module. In order to be eighty percent confident that
the results are statistically significant the t-value must be greater than 1.337, for ninety percent
confidence, 1.746 and for ninety-five percent confidence 2.12. In most of the cases the t-values
ensure more than eighty percent confidence that the results are statistically significant. The send
and deadloek module’s t-values are lower than the eighty percent confidence level in many cases
and therefore those results are not considered signiücant. Concentrating only on the entire system’s
confidence measures, the all module, there is better than ninety percent confidence, except for the
effort and cyclomatic complexities, that the results are statistically significant.
Chapter 5. Comparison of Design Tools 61
II
Table 7. Mean Module Complexities for GPL and Adlif Designed Pascal Source Code
GPL
Module LOC N V E CC INFOall 332.778 2438.222 12553.44 515028.5 95.000 122431400request 100.889 749.556 3781.000 147167.3 33.778 1153413release 128.000 963.556 4839.444 186975.2 40.778 2599250send 52.444 391.667 1963.222 81965.9 14.222 46490.44receive 66.667 537.667 2686.556 113073.8 22.222 1269498deadlock 65.333 519.556 2621.111 124036.3 19.222 165059.7
Module rxro-L xxro-E um-cc —all 4.923059610 6.570745613 1.277843610request 1.93144368 2.03743261l 5.61180567release 4.32957668 4.50700861 1 1.25369568send 1.21039767 2269016610 3.38279266receive 2.16529868 2458338611 6.92645767deadlock 2.47289866 3.75329909 6.55480405
ADLIF
Module LOC N V E CC INFOall 412.778 2981.222 15588.11 612871.9 106.00 319512544request 140.667 1052.222 5388.889 199651.3 45.333 3035089release 184.889 1355.666 6977.556 247801.3 54.000 17837226send 99.222 749.556 3799.333 167877.7 26.222 7370219receive 100.333 740.556 3712.000 49763.6 27.667 6031054deadlock 91.778 691.888 3536.778 133350.0 26.000 5641381
Module INFO-L rxro-1:mm-ccall1.48861961l 2.037372614 3.8205976l0
request 4.78758368 6.03435261 1 1.57445868release 4.06581069 5.220383612 1.21756969send 1.67413969 1864659612 3.94564268receive 1.09736569 1.2683346l2 2.79795168deadlock 1.20650969 1.238027612 3.35839968I
III
Chapter 5. Comparison of Design Tools 62 I
II
1
1
Table 8. Average Ratio of Complexities of GPL to ADLIF Designed Source
LOC N V E CC INFO INFO—L INFO-E INFO-CC0.687 0.707 0.696 0.744 0.75 0.194 0.172 0.16 0.169
Chapter 5. Comparison of Design Tools 63
—
Table 9. t-values from the Student T distribution
Module LOC N V E CC INFO INFO-L INFO—E INFO-CCall 1.982 2.165 2.293 1.408 1.359 1.880 1.885 1.895 1.868request 2.226 2.574 2.791 2.073 2.220 1.736 1.568 1.811 1.734release 2.660 2.739 2.990 2.003 2.169 2.028 1.960 1.773 1.852send 1.638 1.670 1.745 1.638 1.453 1.280 1.183 1.259 1.213receive 2.819 2.877 2.938 2.943 2.691 1.709 1.497 1.655 1.576deadlock 0.762 0.640 0.697 0.413 0.355 1.279 1.321 1.318 1.257
Chapter 5. Comparison of Design Tools 64
l
Conclusion
In this chapter results have been presented that indicate that systems designed in GPL are signif-
icantly less complex than systems designed in ADLIF thereby adding quantitative support to the
work done by cognitive science researchers which finds that the human brain thinks and works
more effectively in images. The inability to compare GPL and ADLIF designs directly is also
shown.
lChapter 5. Comparison of Design Tools 65
Chapter 6. Additional Measurements
Introduction
In this chapter the intermetric correlations for the GPL and ADLIF revised designs and the GPL
and ADLIF designed source code are displayed to replicate the results of two earlier studies [HENS
81] [KAFD 84]. Also presented is a preliminary data set that was collected and found to be inad-
equate for analysis. An explanation of why the data was inadequate and how the inadequacies
came about is given. Also shown is a comparison of the source code written for the first data set.
Intermetric Correlations
Table 10 on page 68, Table ll on page 69, Table 12 on page 70 and Table 13 on page 71, present
the intermetric correlations for GPL and ADLIF revised designs and GPL and ADLIF designed
source code. Both sets of GPL correlations and the ADLIF revised design correlations reflect the
results of another study with the micro metrics having high correlations to the other micro metrics
and low correlations with the structure and hybrid metrics and the structure and hybrid metrics
Chapter 6. Additional Measurements 66
having high correlations with the other structure and hybrid metrics and low correlations with the
micro metrics ]HENS 81]. These correlations indicate that the structure and hybrid metrics measure
different properties of software than the micro metrics. The fourth set of correlations, ADLIF de-
signed source code, demonstrates the same relationship between micro metrics and other micro
metrics and structure and hybrid metrics with other structure and hybrid metrics, however, the
correlations between the micro metrics and the structure and hybrid metrics are not as low as in
previous studies. It is unclear why the correlations are this way.
Chapter 6. Additional Measurements 67
Table 10. lntermetric Correlations for GPL Revised Designs
GPL Revised Designs
Metric LOC N V E CC INFO INFO-L INFO-E INFO-CCLOCN 0.855V 0.826 0.891E 0.636 0.684 0.702CC 0.902 0.830 0.790 0.603INFO 0.033 0.359 0.224 0.225 0.096INFO-L 0.245 0.547 0.405 0.376 0.315 0.914INFO-E 0.179 0.480 0.341 0.437 0.278 0.815 0.922INFO-CC 0.205 0.518 0.378 0.366 0.312 0.899 0.983 0.957
Chapter 6. Additional Measurements 68
1
Table ll. lntermetric Correlations for GPL Designed Pascal Source Code
GPL Designed Source
Nletric LOC N V E CC INFO INFO-L INFO-E INFO-CCLOCN 0.897V 0.897 0.997E 0.814 0.941 0.943CC 0.700 0.763 0.767 0.763INFO 0.223 0.221 0.227 0.203 0.176INFO-L 0.450 0.427 0.440 0.435 0.372 0.919INFO-E 0.485 0.529 0.548 0.613 0.496 0.735 0.901INFO-CC 0.351 0.373 0.382 0.405 0.478 0.819 0.888 0.883
Chapter 6. Additional Measurements 69
Table 12. Intermetric Correlations for ADLIF Revised Designs
ADLIF Revised Designs
Metric LOC N V E CC INFO INFO—L INFO—E INFO-CCLOCN 0.961V 0.965 0.995E 0.825 0.905 0.889CC 0.432 0.538 0.500 0.654INFO 0.258 0.236 0.252 0.120 -0.080INFO-L 0.439 0.397 0.423 0.248 -0.038 0.889INFO-E 0.521 0.474 0.508 0.338 0.006 0.777 0.964INFO-CC 0.486 0.453 0.477 0.317 0.040 0.695 0.900 0.963
Chapter 6. Additional Measurements 70
Table 13. Intermetric Correlations for ADLIF Designed Pascal Source Code
ADLIF Designed Source
Metric LOC N V E CC INFO INFO-L INFO-E INFO—CCLOCN 0.960V 0.956 0.992E 0.780 0.878 0.904CC 0.829 0.882 0.843 0.702INFO 0.703 0.699 0.620 0.405 0.746INFO-L 0.685 0.682 0.600 0.388 0.735 0.998INFO-E 0.692 0.689 0.608 0.395 0.740 0.999 1.000INFO-CC 0.682 0.680 0.597 0.385 0.734 0.997 1.000 0.999
Chapter 6. Additional Measurements 71
Preliminary Data Set
Introduction
A preliminary data set was collected prior to the collection of the data set used ir1 this study. The
set of data came from a senior level software engineering class whose curriculum consisted of design
methodologies and software development and analysis. The class was divided into two sections,
as in the data set analyzed above, and designed their assignments using the two design languages.
The GPL group used a paxtially completed automated version of GPL for a design tool. Several
key parts of the automated version of GPL were not working, including SFDS, dialogue functions
and computational functions. As a result no low level design could be performed and the resulting
design data had no relation to the corresponding source code. In the next few sections an analysis
of the available information is given.
The Experiment
The class of fourteen seniors was asked to irnplement the "robots" game that is available on some
UNIX systems. They were required to submit a design of their system one week prior to the due
date of the entire system. A copy of the assignment is located in Appendix G.
Data Analysis
Table 14 on page 74 shows the correlations of design to source code for GPL and ADLIF. While
the correlations for the ADLIF group are similar to those in the previous data set, indicating a
strong relationship between design and source, the GPL correlations, by virtue of their low values,
indicate no relationship and therefore, no regression analysis was performed[VINJ 87]. However,
Chapter 6. Additional Measurements 72
a comparison of the GPL and ADLIF designed source code is presented. As in the previous data
set, the source code was partitioned into functional units, or modules. The complexities of the
modules were averaged and the results are given in Table 15 on page 75. As in the previous data
set, the complexities of the GPL designed source code are sigrificantly lower than the complexities
of the ADLIF designed source code. Table 16 on page 76 shows the ratio of the average com-
plexity of the GPL designed source code modules to the average complexity of the ADLIF designed
source code modules and as before their is a measurable difference between the ratios of the nnicro
metric complexities and the structure and hybrid metric complexities. The mean ratio for the nnicro
metric complexities is 76.5%, wlnich is within 5% of the ratios found in the previous data set, and
the ratio for the structure and hybrid metrics is 4.4%, which is much less tharn that of the previous
data set but none the less repeats the trend for measurably lower structure and hybrid metric com-
plexities in GPL designed source code. Table 17 on page 77 presents the calculated t-values for the
modules and the results are very close to those from the previous data set. However, one must
down-play the significance of these results since there was such a low correlation between GPL
design and GPL designed source code and as a result of the low correlation it is difficult to say how
much of the difference is due to the larnguage used for design as opposed to programrner ability.
Conclusion
This chapter shows that the complexity measures of GPL designs replicate the results of another
study with the nnicro metrics correlating well with the other micro metrics and not the structure and
hybrid metrics. The additional data set demonstrates that some minimum level of refinement of
design is necessary in order to perforrrn complexity analysis.
Chapter 6. Additional Measurements 73
Table 14. Correlations of Designs to Designed Source Code
GPL
LOC N V E CC INFO INFO-L INFO-E INFO—CC0.403 .344 0.311 0.273 0.422 0.154 0.268 0.802 0.55
_ ADLIF
LOC N V E CC INFO INFO-L INFO-E INFO-CC0.774 0.774 0.832 0.689 0.627 0.657 0.588 0.793 0.832
Chapter 6. Additional Measurements 74
Table 15. Mean Module Complexities for GPL and Adlif Designed Pascal Source Code
GPL
Module LOC N V E CC INFOa11 337.375 2669.50 13580.62 759748.8 115.375 4.31774168m0du161 66.625 482.25 2390.750 21498.1 17.250 1.23373965m0d11162 73.250 750.00 4011.125 341337.9 34.375 7.58852965
Module INFO-L INFO-E um-cc —al1 1.59611361l 3.516355614 $.428607610modulel 9.90453866 2.43694261O 2.92718766modu162 7.50060267 4.11509161l 3.32060167
ADLIF
Module L()C V E CC INFOa11 475.333 3374.167 17006.50 835998 125.167 3.22151569m0du161 124.500 782.667 3714.500 166930 20.500 6.77200466m0du162 127.167 1094 5501.834 276823 45.333 1.08463068
Module INFO-L INFO-E mm-cc —2111 1.719255612 3.076734615 4.87923461lmodulel 1.02849169 l.946416612 1.70427468modul62 2.69617061O $.111443613 9.86183569
Chapter 6. Additional Measurements 75
Table I6. Average Ratio of Complexities of GPL to ADLIF Designed Source
LOC N V E CC INFO INFO—L INFO-E INFO-CC” 0.607 0.698 0.724 0.957 0.841 0.053 0.035 0.045 0.044
Chapter 6. Additional Measurements 76
III
Table 17. t—valucs from the Student T distribution
Module LOC V E CC INFO INFO-L INFO—E INFO—CCall 3.556 2.469 2.492 0.534 0.720 2.274 2.257 2.386 2.030modulel 2.575 2.229 1.893 0.644 0.902 1.826 1.819 1.498 1.694m0du1e2 2.308 1.750 1.489 0.67 1.201 1.317 1.289 1.292 1.286
I
II
Chapter 6. Additional Measurements 77 IIII
Chapter 7. Conclusions
Conclusions
This study was begun with a twofold purpose. First, to determine whether the complexity of a
graphical language could be measured, using established software quality metrics and second, to
explore the hypothesis that systems designed using a graphical language are less complex than sys-
tems designed using a textual design language.
In Chapter three a technique for measuring GPL design complexities was presented. The technique
involves the translation of a GPL design into an intermediate language, the relation language, from
which an existing analyzer draws the needed information to produce the measures. Then in chapter
four the results of measuring GPL designs are given. Chapter four also gave a set of equations to
predict, with more than 95% confidence, the complexity of source code. Plots of the equations and
the confidence intervals are contained in the appendix. These equations will allow the selection of
the single least complex design, from a group of designs, that perform the same task and it will serve
to shorten the design-code-measure- redesign cycle to a design-measure-redesign cycle.
Chapter 7. Conclusions 78
Chapter five compared GPL designed source code with ADLIF designed source code. The mean
complexities of GPL designed source code were significantly lower than the mean complexities of
ADLIF designed source code and a statistical signiiicance test revealed more than ninety percent
confidence in the results for most metrics. Taking a closer look showed that the GPL designed
source code has far less complex structure, indicating its superiority over ADLIF for designing
system structure. These results support the hypotheses of cognitive science researchers who state
that humans think in images and that the human brain works more effectively in images.
In summary, with a very limited dataset, we can:
• Measure GPL Design Complexities
• Predict the complexity of GPL designed source code with 95% confidence
• Show less complex source code
¤ micro metrics are 71.7% as complex in GPL designed source
¤ structure and hybrid metrics are 17.4% as complex in GPL designed source
¤ 95% confidence that the results are statistically significant
These results indicate that GPL is a much better tool than ADLIF for designing system structure.
The design languages were presented to the students in the form of written documents. Soon after
the documents were handed out a help session was held to answer any questions concerning their
use. Many questions were asked in regards to ADLIF and very few were asked in regards to GPL.
This leads to one final conclusion that GPL is easier to learn to use than ADLIF.
Chapter 7. Conclusions 79 p
I
Future Work
There is much work to be done in the measurement and comparison of gaphical and textual design
languages. First, it is necessary to collect and analyze more data. The initial findings irndicate that
GPL is a better design tool than ADLIF in tennis of the complexity of designed source code, but
a much larger set of data is necessary. Second, GPL needs to be tested against other textual design
languages before it can be stated that gaphical design languages are better than textual design lan-
guages. The complexities of other gaphical design languages need to be measured and compared
to both textual design languages and to GPL. Comparison of gaplnical design larnguages will help
to identify the most effective features of gaphical design larnguages and could lead to the definition
of a starndard gaphical design language. Finally, more historical data relating to the design process
needs to be collected includirng: design time, implementation time and debugging time.
IIIIChapter 7. Conclusions 80
Bibliography
Belady, L., Lehman, M., "A Model of Large Program Development", IBM Systems Journal, No.3, 1976, 225-252
Benzon, B., "The Visual Mind and The Maclntosh", Byte, January 1985
Bohl, M., Flowcharting Techniques, Palo Alto, CA, Science Research Associates, 1971
Brooks, F. JR., The Mythical Man Month, Reading, MA, Addison-Wesley Publishing Company,1975
Brown, G., Herot, C., Souza, P., "Program Visualization: Graphical Support for Software Devel-opment", IEEE Computer, August 1985
Callan, J.E., Behavioral Demonstrations: An Approach to Rapid Prototyping and Requirements Ex-ecution., Masters Thesis, Virginia Tech, Department of Computer Science, 1985
Conte, S.D., Dunsmore, H. E., Shen, V. Y., Software Engineering Metrics and Models, MenloPark, CA, The Benjamin/Cumrnings Publishing Company, Inc., 1986
Fairley, R., Software Engineering Concepts, New York, Mcgraw-Hill Book Company, 1985
Glinert, E., Tanimoto, S., "Pict: An Interactive Graphical Programming Environment", IEEEComputer, November 1984
Halstead, M., Elements of Software Science, New York, NY, Elsevier North Holland, Inc., 1977
Hartson, H.R., Advances in Human—Computer Interaction, Norwood, NJ, Ablex Publishing Com-pany, 1985
Henry, S., Information Flow Metrics for the Evaluation of Operating Systems' Structure, Ph. D.Disertation, Iowa State University, Computer Science Department, 1979
Henry, S.M., Kafura, G.D., "Software Structure Metrics Based on Information Flow", IEEEJ
Transactions on Software Engineering, September 1981
Bibliography 81
Henry, S.M., Kafura, G.D., Harris, K., "On the Relationships Among Three Software Metrics",Performance Evaluation Review, Vol. 10, No. 1, Spring 1981
Henry, S.M., ”A Technique for Hiding Proprietary Details While Providing Sufficient Informationfo Researchers", Journal ofSystems and Software, 1988 (to appear)
Kafura, D., Canning, J., ’”Ihe Independence of Software Metrics Taken at Different Life-CycleStages", Proceedings: Ninth Annual Software Engineering Workshop, NASA Goddard SpaceFlight Center, November 1984
Kafura, D., Henry, S., "Software Quality Metrics Based on Interconnectivity”, Journal of Systemsand Software, Vol. 2, 1982
McCabe, T., "A Complexity Measure", IEEE Transactions on Software Engineering, December1976
McClure, C., "A Model for Program Complexity Ana1ysis", Proceedings Third International Con-ference on Software Engineering, Atlanta, GA, May 1978, 149-157
Mills, H., "Mathematica1 Foundations for Structured Programming", Federal System Division,IBM Corp., Gaithersburg, MD, FSC 72-6012, 1972
Moriconi, M., Hare, D., Wlisualizing Program Designs Through Pegasys", IEEE Computer, August1985
Ramsey, I1. Rudy, Atwood, Michael E., Van Doren, James R., "F1owcharts Versus Program De-sign Languages: An Experimental Comparison", Communications of the ACM, June 1983
Selig, C.L., ADLIF - A Structured Design Language for Metric Anahrsis, Masters Thesis, VirginiaTech, Department of Computer Science, June 1987
Smith, E.C., System Support for Design and Development Environments, Masters Thesis, VirginiaTech, Department of Computer Science, 1986
Vining J., Consultant, Virginia Tech Statistics Laboratory, personal discussion, 1987
Walpole, Ronald E., Myers, Raymond H., Probability and Statistics for Engineers and Scientists,New York, NY, Macmillan Publishing Co., Inc., 1978
Woodlield, S., Enhanced Eßfort Estimation by Extending Basic Programming Models to IncludeModularity Factors, Ph. D. Disertation, Purdue University, Computer Science Department,1980
Yau, Stephen S., Tsai, Jeffery J .-P., "A Survey of Software Design Teclmiques", IEEE Transactionson Software Engineering, Vol. SE-12, No. 6, June 1986
Bibliography 82
I
I
I
LwI;;°°—*E E;° gz 2/
—f 3I __i s
V4-v~——]—\·—··
——· QI .,. ägÜ #2 LC
ä' ^“.¢
zu Kg 3 Q*3(~
S
Qä < C“ QQ€
Q L' °°I·ä'*1 Q.
¤.„ « °2‘ I «· 2 < 3-‘=;=·_ä z 2*123 ·
II
Appendix A. Sample GPL Design 84 :I
^\xD „
""""°”f1-—-— 1 ¤11 ° 11 Z _
Ü 1<·—·—* 1 3 ¢1.1 1 1;*2 1
.....-..... ; _1 1° '1 1 1O 1
°'°:§ A 1 1 1°§?*‘ ¤—• ‘ 1 1 A-+**.2 F-—-——— 1 1 1
L *4;; Ü 1 1 1Q _1 1 1
111 1 1 1 11-11 1T 1 1 1 1 T1 1 A 1
1 6g E A , 11_; 1 .: 1 E2‘ : 1 v 2d1~1 1
"'*·§’
"°" 1 IQ 1·== 1 W;,1 .: 1 Q 1 G1
l¤""1;nä11
AE}
1 1 , 1Tbul 1 1
121 1 11 61 1 1 •‘11' 1
·‘S 12 1 IE16 1
"‘°ul‘5 M1 1 sd 121*
I.•
.i 1 ’C‘¥:2•1 1 gg-; a1
„ „„ ..:11«·_ 1<·—- ,:1 1 Q'? si .1
° 1ä·1¤"<l 1 Z e-1·1'*1{ 1E A1
:1KX 1·— 1 11** ”
1¢——' 1:1* 1‘ <' '!:1 Y1 A••°°.‘
[O? 1 _g !«g_,é1 @{:2*L___; •
·O Ü: b
5: 14 •‘ • • Ü1 2
·• _' 5A°“E{ 1 1
*°‘ §~'??Q?1?‘1:°'*’ä°?-6 , •¢1· ‘°° U19 vs II
· 1$ ·*‘j, U .41 °•2¤Z gA 1::1 111**../1 11-1 · ·1Q~&~ ..?•·‘·‘
,."
gu“"T"' 1 ~··-~„ 1 1:*, ·° XY ’ ?*:¢?§ 2·—‘E.13 gi 1 2·‘¥··°·-<»~*1-°·‘
O 41 A‘
Sie '
Ap cndix A. Sam Ic GPL Dcsi n 86P P 2
I
1
O
$2.-}Q?.th
I „ 1 tI•"· IdIE.
I _: ‘ Iik J, de
II IQ- I=§‘Z Ik&.•II gII \u1
,5% I = 2 I
I 1 I 11 1I I1 1 „1
OI
I alle11Ica I **1
I 5* I I 5
IAppendixA. Sample GPL Design 87
11I
¥-*-‘;"‘-"Ü -7*
‘
-.¤>
gw
¤> 19wm
; x Q_-
Ü""-"‘;‘*"‘ 77
Ö 1§‘gg.- -7*
1-1I
I .-*1
‘* ’g' *-1 I 1
I °” 7
Ö_—‘•
/1I<I "‘1 Iä7 *°*1
:2 S3 1
,•~gg1¤¤1 .1- . I —·
I ,1
IQII I¤1 ‘ —
1 1 ¤·w¢
1°ä1·- E--
- I E8-
— -———-_-_E" °, *’1v„I
_
)</
·O·1:6*
»¤. I I·¤ ¤
,, {-.
- dä 6 I XL7
_,_’*S·
:ré__I·•;..:
Z:L¢„<·°¤
1QgK
/Ye 7 .1
• ••,1. f77—F
s A 2 ; ‘"
S G-1.
( II
*·
"7'*<>·<—I.; 1U I m .66/,
IE I U
S' Ä IC
Is I ß
= ———j-1E I E,-..
7
- I L"I SI ,,
..1 m
GII '0
tg ;_~ g1_ 6 ä 2 I I °I 1 I<·
-r-—^,: I'^‘-fg? 1 —-~*"'“
1 E
S
I,,
'„~eg.„0 % E-]A gg E 2
0 g I I I7·
'°1
' 7
I
Ü _:-§ I
\\ %
L‘
.IIEI7\
7 ß E Q _;
—* ‘T
U
15 I‘vI
I{1
7E
."S°’I__I I“-‘¥
v FNI
u ‘J
Ä
Lä„
U_$ 0I 1 2
Q
E
J
I
I°-<
I-
O*7
I
Z 6 £ §- _I äg E
I88 IGpLDcsig¤Appcndix A. Samplc
Ä
LJJU
JU
A
xs Ä
Ä 47 .4) ' Äx V9 J‘~ sa
.4U.
ä “ 1
x1 •-ei ÜVl..C
.-4 klQ° Ä1
Appendix A. Sample GPL Design 89
I
. )
I In ILI °Ö’ III "I I
I I.„ I {i I U I2 ¤ ,II I II II ·—> U 1
„‘L =°‘: I I•"i ——- ~· I IIEi III ‘é I :6
1 IvqÜ! : I H II
A /\
L‘I I.-= i ..,1.
Ü r‘¤•/ Ä
: \_\ i' I {
ggéüüIIj‘~€’="I¢I I
{ig: I I e-- ‘°' I Zrj I”"—„I I .§ ""— I r' I I g I .
‘{ gg IOI < X IQII I
I‘“
sQ•·£ I I tu I · . I ·-—-—^-—- MI ä;•S~§.•L2 ·—-I I-I I I I · I I- -·I1 I (I,I . g I I gl!I·
rf In M ;I Ä':1 m I · · Q 1 1 7 ·_„ JI •2 v I ^I w · ··I J I ·= ' ~I ‘ I-4 IK---: ’° H II ‘{¢*·.EI ÜIIIÜ ¥III"’Is**II I L. ‘ I, >: I 3+ „ “
2 I I—--——‘I~I—$¢I*·* ··=II"€éI „; 1 IJ-FI T1}? < L
° ° IMI &;I‘•Z*'. •ß=$’•..— _ „, IÜI+——I g Jä g I gä
E I _I. · I ILL§QI IMEI °·;·—I 3 FI I { I -
I°° I gy I . ( ÜI ·•I
II_-Ä I PI I I E« IIu
I l Z I:4 I,.II *1;,+1 In T
I: I°Iä ä .„; 1**. -.. 7 s z Ü
Appendix A. Sample GPL Design 90
I
I
}
- I ·‘=% .ÄJ .11 2*• 1 1 3* *
gi „% V••l l E ul li
{JI L1 1 _: _i••I••I g¤''Y·•-gl__ U' ÜN
UI e 0 ·2*:1 ¤ 2 731= si V2 il. U.‘i;'*· 2 ; TQ. äl
·· I-Ii’7= .2- 51 TI··I ·" ÄZei L-"i•g
•l·I ;°·••s1 Igg zi :1;g~~ä
I= · ° •
x\¢\:Q ¥* ZEI\_Il;{jl"l gi {I L<I
s*· ‘ uf ey-<¢I~
x.•; dlÖ}; °-1 äi ä„1gu- vg *
• U1,-1 gc L •¤—·LL Li
LC
Appendix A. Sample GPL Design 9l
//*%,2
\\
-6-** ‘*
Ä 1""' ton ‘:~~ 1•o-—>§¤.-yq;.
1 1G.
}Q’_'
Ö1 1 1°“ 1 1 1
ak / 1 1 1· 1 @1 1
^ mgi **12 j”q g1 S,UsA
1Z 1 1
- u 1 1 v ~ “‘V?1° 1
1 g 1 · 1 •——=1 1.. , ——-—-— 1 11 2 *1 1 2 1/\ 1 ”""‘1 '
ext V7 1 111 1 1l •1l
1 1 8 1 1 1 011‘° . *-1; 4u-er "
1 é 1 11c ll¢xä.$$ Ü “" ""Y" “' 1 Pi; '°1•
1 1 Sgé 1
1 1 E11 ;P‘*""""""2 wr 1 1 +.11 91 =ääiiz 1 -51 f1 "Ü1 1 é·.; 11 2;,1./
g·
·— 22 1 12¤1 2. 2;A CE1 ‘I v ‘^
1 1 tx1 :13,1,,;1 . 1 uni 31 *‘*""l"' 1 •• q~ 01
•·* 1 7°^1"‘”—”—”——
Ü 1 2 Ä11-1;1 1-* °_61«-{1-11 E 7
71ul
‘I11-1 ·~: 1:1.:;.-1 +21 E- „,2 6
1 x.«1-3 •12 P9. ••o " {YS“°-1 *::-:1
Appendix A. Sample GPL Design 92
I
•* nc II¤'t ¤ §°:~—•- IU:";: I II? IIV‘ ' *7**<.°· I .
I I-I ...··*£ I ai? ._...Z2. I 6_Ij 1 ,„_ T
A I.„g,_ •-•
-Im
I Z6II I Jnv, Icli* ; I A V I ;‘I:-—I I :~ :·—— —I..:; I 2- 2IG*I ·
<__<2-———„ I *.„„ I%•••°-l I·~„-Z I I"I.:< -i;¤—‘° *2iAI
-I I
I 12 32 II .2I“‘·‘I -'““=“I eiÖ II"; Id
I g •·• 1$I ¤ 2§'i‘=:I¤..„I I
II «a‘II 21 I ~ I .-„I II I·I? —r·‘ I
-6- UI ..L"I.•• NI xI4 § „.6- A N-IN<I
¢ ÜÖ Ö ~>I "-·ä6 I·I ;I"Ig„U j I
.2 ~
Appendix A. Sample GPL Design 93
I
/K
IfjIH I.GYJI'!
( *2}% I58 I „‘-·Ic¤°—"’I ¥‘—·—ä.„.~‘s I ,:I .£I¤ I I·¢·I IIQ
U I ‘ si•:¤ __%
~Ä- E Ii Z
‘
V Y•·/
„ ‘°I
·€
(llU[-‘>‘°_’·•^I I .
‘{-Ylu I · 1-1 I
I I YZI II : I ZI
mai I I an; ·—Z<I Issäg;7 = käzg •.‘ I
I I I _Q§” '°‘ C ui •'*_I
IIé“‘I__
··• . as
I4-•II IIÖI I "‘9I 3 gg 7; I_°“„ ‘ •·~
I°;I ¢ :I¤I -,5GI TrCL;I\ I ey. . S ‘ •I
.j 9.+ ‘L; ‘^I ¢$•^ .„, „--
I — :*7;, IEI .,*1 Z I I‘“·Z°12;I".:.. I §§ E j
-< ·~ 2·" §‘ ä J
•·I
•·*I . ·° 2 :-·‘2 I Q I¥Üé
( IH II I fig zi 2 * :I °_ gß
I 5 I H I 1% II ~I ,,;,,.;¤ I Ice 5I O • • 0 '
· 1 1 {I-I C 1 V· ci
¢‘ Q ZI 1 -^ 9cI‘D
I _g § EIQ < { uI•(6’•-I s¢L
QI 0q•.« Q..1: V, " . ws ~I 9°{ Q;) • O 9 • vs • ‘· y ,
- 5 V „ ‘ Z 9* •* $
"I
q, ¤-c V
I
al!
I
Appendix A. Sample GPL Design 94 I
I
,&i________ E ,.U Q2Q
Qi
!I“{_ ‘!n:äé ‘ä!‘;§2 fi {Q4;€ ¥§ ¤°'Ü<
:.4 2 u.l.__¤_; «32 22(
22 ‘ H {'2 "——" gi.¤ i2 52 „, V1 >Q S"$ 1 ..‘lÄ Ä28 Q 3
-=Q Uf'°°°/A-°‘ ·\/. M Q2 •.
* *""“""'“Q U Q E Q Q_;
Q Q23(-5
Ä 2 ,......... 1 3 U 33*7* 3 2; 22 2 2* 2i 2*L';, 2 ~» ** 1
’·‘O QE f Q 1 _
.4. gv z H 3 S2 ^ QEeb __, 2 U2 V Q~ < 5 32 Q "‘
'*1* = ·« 2 .. 2 =J W 26Q Q Q¤. ‘ 2 H ·'°‘ ¢2 4. 3EQ { * Q H Q 5bQ/ JF, ä'§S\——@·"1"‘ Q **
Q Q2gc2
··• < 2 *Q<: )-J-——-—·>& />' gg U 5*2 q, ‘_ / vl 2Q-{Q
BI {^
,_;,._..—•—/
3 U· Ä II I ) 2 Q _ä 3, J 2 M S
\ // 1 Q2 H YQ< ^ '
"‘Q°”<
"° 2 Ü Q2' l H Q2T: ve
•-* Ä ¤L2:
A · 2c2·2„¤‘ 95ppcndux A. Samp c csngn
1 gw1 i 31
U.1
1
1
1Y"1 1
*
F
I > E ä
{
4 3
11
“ { 11
1
E T3 1
1
1$1
‘1
1
I 1 11
1
7 1 · ¤ 11
·‘1 { 1 Ä_\'U
'L
‘ 11
1_; ge 1 _
X 11
I 2‘B 1
' I I 1 E
16 1; I 1
6 1 1 1
1 ' . 1 11 ·« J 1
I 1
1;1“ 5 1 3 1 E ;_ i 1
1 -: u IÄ
1 1
1 \ °_
h 1
3
111 “ 1
1 El 1 =
1 Z' " °' 11 ii 1 E
Ä. Nb °•1
1•i 1
I
, U
I
6*1 Y?€- 7 E 1 ; ;,·1I
" 1 E 7 __Q 3 $1 1i°‘ Q‘·
° .-I IJ•-1
• 1 r1 Q„;‘1' S 1 jl
_,1
.-
es I *1 °° H ‘ ‘ J: J. H ·· Z 1 11 1 ·—”
U g__. u g > 4 Q I1 ~·¤• M Ä I, ~ - .. 1
H_: Ü U 7* J Q1 ·
G " jf 0 „ s 11 1~• Q 3 Ä„,, E 3
J U.;;_; I1 U
(1E 5
,• aß Us I ..
E 1 6 °‘ H ""6 > "
~1 ‘° n TU A 1 0•' 1*1
{ • V 6 H— H
„ _ 71
5U > .- Ä U
• ( ¢ ( 1..1
,.
< Q L *· JL.‘* Q " L g
·:.’ 11-1 J 'U « 1g ,i 1*1 .8 11-11:
AppcndixA.5 .°mpI° GPL Dcsugn96
I
I II
W I
2 I "'I LIB6é
Im;II Y "’
'° Wd ..,*1^I 2, I väa„I
II I II
:1% E ¥~L
Zail I1 IA-EI _;
ma I I ·~IH I I I I E I §~III I I II ~’ III ¤> I· I °I„ZZ WI TI-III<‘*I __UI
I ·——;.··—* I °I {GI 'ZI II I I I
L "IEI 6 I I I
ZZ I _‘I I FJ
I‘ ° 6 I I·I I · TIx 4/ I °• I
I{II,I I IT( (Q I -I I * "jßgzs I "I 2 S .<•,„: _, 6I II= E >I I 6 ‘ •-*""'
I I I""‘ I 3 {I U I I {I I
I EI I ;--<>I·I IIII :I .·II < *2I ßILII I ¤~ · 5:%1-•I .·III •_ QI I'
-I··I•—*€I **=I E ‘?I—%I I?
er I•‘L ·‘_;,„;I I :I < 3I—« ,_I3‘ZI I I"“I VI ·* I
“" ä IH I° IIZ IH; IH ‘I ,I'I _;Y- O Q ÜY ·I·? IYII III— ISI.; “
I"AppendixA. Sample GPL Design 97
Q1
1061j-1¤·1 P PgijL—•
1,.........,
r—·1 1-YP"Q Ü‘·‘ -# 7 ·~? °°°••
1 1_,
1 „ 1 V\
.,°·=¤ 1 1¤1 e. 2 $° 1 lw 1_ ·
,_ · I 1 s
2 ¢— 1 « ——-—-7-**7P 1 3: P 13 S
_1„1 1 „ 1 ~¤. 11.5%
-1-1-*-l**'· \. · ' U!
Q v 1 XL' *2-> 1 g
7gAU
H 1:u 1 —'
P Y /€;———--————- gw :11 7 ’
——-— P $-**7 3 1 i1,„f' 1 6~1g ‘=é~-
/\ 1§¤•* q, --•1„11 7 _l Q ;1 6
_}y1U°°·"°
nm °.l . l •' ‘c L 11QH<·T";·~¤ ~~ r11 „·"‘.—¤ "5 ‘ QM (.4.*:, 1g
il .2 ,..! *-.2Y“'.·:;1•-—
‘£‘°·· gl •~ 1 Q fl J °"_,!P 6P U
¢¢E 7:*··¢ P Y 7'”‘l1 "
“1 w :...-—-—————$ ~/ i‘ ••1 Glen"? ¤* '$'8|1 " l1 ..;.*’ .« ; ·zätzé 1
·P Ä: l'¢‘°I > ·‘ '
V-Y Ä _ SPl
A F": ESS
§_ 1 1
1 T5'¢Q1 s27~
· · U '-P 1-+ 1 0. P Q ,. ll g :1; 1§ .1.; ,,;°° vx Ü U gl
J .• «~•v * Ls s V•· s1 s °P L
< < l ~n Q s ,l""L= 1
•-Z'; 1Q 11¤’ €"‘r··<„..;1„.,l;Ä€iFQ Q 1Q1 gn¢/ Q E $1 < Q_
1 • Q2 1 P 2 af :.2.1 l.2 Q Q 1..., °' 1
oe .I ·v •v -.,AppcndixA. Sample GPL Design 98
1
(g (6 v I:·!“—"380
uiélr ,11
,4-·~ 7-I , J ~li I„„E 2 .i ’¤¤·‘ätagA
Im; J-T ‘EIi ‘·¤ 2 ‘
S 62 I2,, v2 Ä2ä"? fn *““T ‘*‘*""*’ IÄÄ v ng}A 2•·•— ={w{ <Iäf'*‘ *5 Ü‘°>@!
I e 2‘°I.$~°.s;-Y·§'€——· *-7:** i·‘
U; c__ I,
ÜVQÄÖT'- I Ä Iki :16•\li
61:2“: 1"? °In ( 5 u°I2I , Q -2
2
5 2 2 II
422 mv I72 0BÜEII2
ii 2¤° _ä2 _„„ I2 *’ 82 w • I
Evbl gk Iws;} *¤ 2
Appendix A. Sample GPL Design 99
I
I
IQ
1 gl‘ä 7T..6 241 1 1 . .._ .,<ri
L
TT \\ 11I1
1 /I ‘}II \ 1 .„ ··‘°i11
1 I 1,I J 1I 3 IT16
3 1 'I 1 ,1 1,2q 1 11 •q„ IM1I 1 E. IE;1 1 / \1«"
1Y I 1 1•„ 1 1 :~ 1° :1 IT"? 6 ">g1 I1 I I1Z; 1151,1 ·<>- E 311 1 Ü 1,
1 6 ..1 i 1.1 I, 1-1 .11......./‘ 1 :1 QJ Ä 1 3,L13 g 1 61 J ,1 VIL ·= 1 —: W 61 1:I Ä i 1 Q1 ° .*21I V ' I d1 nn 1
/1 I -61 ° __ ,.._.... ___V < 1 1 1 I 16- 6 <$ 1 *61 J6 ,,1 7 E E61 °°I -. 1-) ..1 ·-»°°I1.»‘8"-’ • 1 -61 °°‘ ·•- ·°·• IJ SJ 1 31 *6 1°11 6_§1I°1L3 § J-- 1 1 3 1 1
L1ga6 8.1 1 ,.| 2 I6 u s ’1 V1 1- 1¤„~<’Ö ‘ 1 V 11 $1 -1 11 v1 S 1I CI 3 I
1 *6 6 1I 1 V""""'7
( 1"" 1'362 2 3 11I-1 E1M T
1*:..;1,; .7 .1 21 2 M1
.„
IGPLD' ‘°° 1Appcndnx A. Samp e esugn
. >
„ ’ 1 ‘4 1
—·1 521„~; —^; $1 ss1 zu J1
‘°Ö ß1Q7-··s1<'9
Q 1 ;äJ1¤·g2" ¤·¤‘· s J1 1 1~L=
| Ä*2 Ä J1 rw ¤Q1~
°T 1 ,,.: V . ”
·" 1• ‘-_ 1 .y§
L ..°M.£~l1 n1Q-;
1 :3 väciäé¢ rl U1 ··::· • · ·· , °Q'·€=”i“1§1’°131°@1* 1;'Q“” Q"'$ -1 'U m rt 1
O2 i‘ uv .~*’·§E*;§"*§l""*;"‘1—i2.. „ I3? 1: 1 -‘ä
&4]‘ Z' Q < 1-3 lg;.,•·-$,34:
“ O ii 1 3 ' 2$’sv=»·¢
Appendix A. Sample GPL Design 101
Q I 1--*-*"""1 “ U 1 11
11
1 1"' 1A U ‘
¢Q 1
* **1* < *-4*** 111 ~·= ·; s·;1 1
•:‘ ‘ 111}; 14 s v1;.'Zi‘ ii 73 ·—————— *-******
1 if 1 1§ 1 1,, 51 z/«\•~ 1 —¤ 1 :2* :1 1 an 2 / \I E1 1 1-1 ·‘ ‘—— /
11 \h~ 1 1 1 1 11”· ht-11--1 EUngl
· v1•!
x1 1 ·<‘¤
1 E 1 v:
1 *1 1 1*1 1 T: °l i ;
****" ^1 S X!\11
K J1.:=&— sg *:1:*7 1a' \2 ‘$1
er ‘~ -‘ j1l
\._„/ 1 y;= ^ 1 ‘g**""""" 111 1 211 ·~ i :1 1 ·~ 111 S9 1 :1 1 E w1 111* -1 1 1*1 1s-——•— _‘ _-—1——•¢-¢"
O1 S1 1^1 1:1 1vi x1617121
’il *1 { °
‘ 1 1ä«E
I1; 16·§ O1: -O gg
.‘ U«.
Appendix A. Sample GPL Design 102
v 1 1 1LQ ; : 1 15 . Ä 2 ‘~ 1 1
6 3 ; 1 nk ·w1 ’ 1Y;1 1 1 1 f * 1 1
1 1 •1‘ 11 .
‘ 1 '.
= I 3 1 1** :1 1 1' 1 L 1 °‘ 1 6JT 11 1 1 1 .1 *1 1 » 1
1 1 1 : **1 1 1-E 1~1 1 Ä Ä
- ·· 1 ll 13 1 1 1 x.. 1
__R 1 El
’$l 1
L gs; 1 i.2 1
*. 1 11 7 ~1 1 1 " éwG? 1 Ä i ä r-RI 1 1 i* @1
11.1 1 1 { ~ -6 1 1 *:1 Q1ü 1
Fi ‘ _ 1 x, 1
1 · 1 ¢ 1 * ' 1
:*3* t :1 ZI 1 1 1 -1
I $1 5***.11 1 Y *Ä 111ZL1 ° « ,. :1 1 1 3 "I
1 1 °·_ S, . • g er
M U1 1 • 3, . ·-'Ü- g „••.:‘ 1 ·'11 •—
° 1 6 ¤*1 -:1 2 _ ~1 ,.1 >1
_ - ° 1 I 1 .. . ~ ' -31 8 *11..,1*31 @*:;,-4 3
(1 I < -•5„ Q1 Ädb 1
j :1 ,1* g. ,-4 E1 31 Q, - s S 1.1 ST —·:«1 I ‘° “ * •1= · 2 3§‘·;·1s1¤¤1!‘U—$“Lk?i.11„‘Y‘°2°*"“1Q .-» *3 _ 1 45 ,® Q.; 1
..1 •— IV S V‘b 1U ~*1 *··‘ “
<‘§ *“
" I0 U
YU ’ U { Y U gi 11'1 'QZ {1 E 11*11;} Z. • H Ü 1*11
°’ 1
v. ’ä- ¥ Q Ä P ‘~ 2 D
I
Appendix A. Sample GPL Design 1031I
I
S —
II I
I
4 Q 2I2 U ‘*"‘”"'”I H II 2 I
6 <r 7Ii .U g '*6 E I0?J
0 1Öl I
II
4 .2\l\Jg 2 .1
QQÄ
A 1
I 1 Ä _I 1 .•-11 .,6 ‘I=E 1 ·¤¤-—> ”% ·—>.„I6 g I I7 '* I «‘.2I,°;
U ti In 1 I—— :’* z' Is I ,, I 12—— „I = 1 1 1 1_ 2~ e I ’< 5 I 'K '° In I U ' 3 I;; 1__
I g Z I ·· 11.. 3 I I . ‘~“ 1~ 1
Ü Q IG *6 I GI f°· ä · “>———-———*<‘ Ä IG ,, I
1 2· 1 .·· 1III•~l ‘ nr.I1
Q 1I ~I . I 1 fi1 1 I I '._ < ’ H I E·-·sU2 1 . I E I:_I-·Ä
•1qI I< -2
I QII .4JI
gc
Ö I ¤¤•1QU ' FI 1·¤ ·;‘
··· I 'v—I ÄI G6 4 I 2jI I 2
Q ¢ Q UI 1 L0 °; 1 g_._ IN:
°-
Q.?
Appendix A. Sample GPL Design I04
K?l O1Ä Ä:~
•, Q
I ">
1 ¢» .21
O1 L)
1 Q Z<Ä v ,__,_l_
-I I1*6I
I" ÄI *·11 ‘¤ v1
El {
Ä F H I¢‘
.! —...-—--l ,1. *·
Ü IZ? R
_, 1 .§ ,———-—··—«
IÜ 1 M 11
1
e 11„
U
/’
/\ Ä
1 ‘$ 1 i ** ll1 j 1
, ¤ _1
1 1 1cg1Z 1 1 1
U g/\Ill
$• lU Ü
I
C7°I
L"HI
S; 1; iq— :5 —
·::‘
U
.
CÄ{/”\= 1
Ä
zh}
1/v
1Q
\:
I‘ qj
Qu I•~IÄ*
I Ü 1 W1
1,
1{ lE " 1 *-1
'TI X1 1-2 1,u*ll7I '*^ ‘,
il 12·¤ Ä 1*== 1 1
éPI
1U 0 U °·
Q - ( I·H·I°ll
S x
Ä Igl
""'‘ a, ~
“ E I
J°·5 ~·
..-—-————+-——-—x «I
E6. gg ll
, ,
..I ,:1, Ii
gi Q1I g,-
$,4
———·‘ .. ».El .*1 1 Q
I U.2 1l-1 . ,„‘C
A end'pp Ix A*SamPl¢ GPL Design105
11
. 4/
U
‘ 1'B
U·· 11 _/1 1‘
ÄÄ 1
J1 1
Q11
j1 ’° 11 1
^1 1 11 1l 1
1......-.. 1 *-*1 11 1
1 1 1 1 ~¤ 11 K, 1-·-g 1 ;—· Q 11 1 „, 1 A _ ‘
.: 1 1 1*1 ‘1 — 1 — I 1 11
.0 1 1 .. -.-.-1 ‘*„ Q . » ;’ 11 ?^ ig; > Z Q 11
{ s v 1 Q ‘ .2 Q L 1-1 =1,.·~• 2 1 E' ;:*1 : ........*1:-F"? 1 Q zu *~ E ~
‘ Ss. (1 1 ~_ /1, .(ZYä ~^
-61 Ag ß v 1 ä 1
°' ¤• ‘ . 1 ~•11 Q: v1 ü
l' 11 ··E .:1 -6
1 •· =; 1 3 in 111 Q ,; 1 _/1 v / ‘ V ‘
1 \/ *1
Y1 Q2. 1k
U 1
Q ,§_ ·. ......_‘? U ‘ ÄU
‘ , 1~¢·
‘ 1 Q 1.5 1 v 1
1-1
5V7: - bÜV ‘—¢
Appendix A. Sample GPL Design 106
I
I
jf "‘ I gi I -2 ·* ·-; I 3. 1 3 I .: „ ,1 ~¢ I°"
—:Q 1• Ä M { 5 14 U11T,3I.:I=;1·¢.I:1I·e,-,;~5-,
l Q „ U v i U 1 U : Ü l Ü, · O I _:
Q C
i 1 1 .¤ E
I
Appendix A. Sample GPL Design 107
I1
7
1 in 1Ü Ö1 1* ’
1 M111 1 1
6. T \**1 6 ~•
+1/1 *1,,....1 * 1Ü _~ VIZ_<
,5 ( ‘" __________,_1
•·~ ·6*} zu . ·
11 U1/\
/ 1 11-112 x~ 1 -1*2 1 .·
1U 1 , I 2V ¤. 1
=’ I3 ; ‘ :1°1v-· 1 t 1 t x v 1
5 1 1 1 ·~ 3/ 1-1 11.... -1 1 1 I1 2, _____,.....
^1 é- <•·
\?U\ "‘ /vz" 1 1 1‘
••"
_________ 11 \ ./ 1 1ll 1 1 11 ·== 11 1 2 .:1 1
( • 1 U Ä] 1 1 1 . 1
2 ,.1 ..%....1*1 1 I 11 1 TD11 rs 1 °1
1 -‘1 1 —• *1121 °
1 1 *1 1 1- °*21 E. 11 1 ;—1E1¤~1f€1•¤ $51n1 ___ . ¢1;1 mi 1U "1N1 C 9*1 611-;;11..11
5 1 1 1{1<.E :’ l 1
1ei1 / 1··-°“~Ä~'“1 *1.1 „—·1
:: -·· ~ : ·· 1 ·" ~1 .L :12 _< < vg •* $1 1
°° ° ° 1 I( 1 "'-1Z
--—(°‘E11^‘1‘ v*1^'1¥*1, 1 „1•~·„¢..f'f‘Z111°g•;?
f O Ji ¤-"€» ""* -— *’ 1*1 1.*1 g 2_ ‘i
Appendix A. Sample GPL Design 108
I
ab-*• *1.•· .:5 •s
Ü? ,E
é lvvi
^1I
1 v 71 j ,
( I11U1 m {Ä 1 {
/\ t Ä i1•¢s 1{ ° j .L°11..··— { *.3..61 {* U21
vu Q 1 {U Ü;£ x l1 1 11 va M1ät-: •• Ä l
.‘ ·~ .·Ä
S ' . 1 1= 1 Z *-1{ \\ Ä 5gg1
Y + f Y1 1 < 3 1122 6 1 \ 1 M1 ¥<· <"
. 0 11 1 H J- -•"· Q 1 1 U {1
i.
‘ U { {Ä =. H 1 { 1- 11 ä1 1 „
Ä ”€ 1 1 1T1 ·· 1 =
<* " 1 < -s ·¤LIil Ä { ",
_;
ÄZ UÄ ä <
‘
,. 1 < · 1· <' 1. 11 ‘ _ ·- 11 1 ·- _g 11-1 __§1
1 an 1O = ” — 1° 2- 1ä J. 4 J. 1
vl
Appendix A. Sample GPL Design mg
I 3*¤”* 131 ""_'“K"° 1If ~•
1 ÜI Ä wI •~
)̂
I -*1 ~—-·****I \„ E 1
‘^ 11> E
Q IT'1°
’ 21 11 ·
^“1 · 1 1
,..„.J—-—-— T*L° 1
II n — 1
I=·1— I · IY 1 1(Ü 1IKS
1 H 'I 11,_.........,
I rx 1 M 1I ,...‘
I ß 1I
gs 1 l-I
ä 1 1 1 Id 1 I‘•I
;-¢ Y 1 . 1 I 10 I I¤1
Y 2 2. 1 ; 1 -1**-»°* 1 ·-—-’°I
1: “
___,£
1
-7** ¤? \^ 1 1 ¥ ~ 1 I? Y
01 2 1f
'— °**
11-—-——-—•-—? T 1 1
1•r~
gl:IL-
I 11 II I I*1- I II 1 Ä ' 1 IM
• ••.; " 1 3 II 1 II 111 1 1 I 1 1 1
‘°
(I
°I 1 1***
0 { I ¤J 1 >I N, 1 I 1
C,:
I};
uzä1 51 1 Cl 1,:11
I e11 1 -———————~1 1 1
1 gg I Q 1 #:1 ·-*°;. s J „ **‘
I>I
ä
I -__
J s1Q
^1
—-—-·**' 1 1
I > I ISIÄ 1 _° 1' I01
\/’ 1 ° II
11** II
......4,,..-—-I
‘T
g E, 1 -1 I1U F
1H .1
+ ·C ,,__,.Ä-—4-.i '
6 Iv Q O° J.: E
Appendix A. Sample GPL Design ll0
1 U1 Q1 Q
k ¤ V131
°1_§ —» >
,,1TS 1V1 —-1 ‘ ¤¤1T„' 1Q1 “. Q1 v 111 1
1E 1 EN 'JQ1 1( 1 Q1
:,11*011:• \—J 1—*1‘—
T 11, i 8. ‘= 1<.: 1 1
d "' G1 1W 7 ·
“117* u~¤1
1)*1 .,1 1. *11 .11 51 ""1 Q 1C
,,„ va; cl ,.11 g ,.„ 1, Z 2 Q1 Q1 Q1 3 1
L 1 1·1'
•i {
i 1 °1 1 ' 1 .2 1 11 1 1 ,/1 . 1 1 J é ·1 ·1”1 1 1 ‘1 J? 1 L 1 Z1 11 J 1 L Ü ·; 2
'• 1 E°’ 1
1 ä 1 V 1 11 1 = 2 1. ¤ 1
‘ 1 F =ä' ' 1 ‘· : 1
1—11 Q 1** ·
1 1**1 — ä 1 1
1 11 •Ä
' 1‘ , 11 ~_1 ·x1 ,1. G
1< 'O
2 ¤ 21 3 1 ·-1 ~ 111 *1 .I1
“ g { 1 ;••1 1;••
S ‘ Q Q-•
1 · **1 >1 2 § 1 1. > 3 :1 1 i ¤* ' · 1 U
• °
1 Ä E 1 7 '° 1-X1 *11 1"*"?1 1 " 1 3 1-% >' '* 1* Ö:
‘ ° 1 1 1 V \ß—-
.,1 17 °-:1 1 M i' i T il V 3 C 1 "“"
°1—¤“·• “ *" -" ··“‘ 1 <¤ 3 f °° > °° LJ 1 V " ° '$ *1°
Il°
"“ ‘*‘ ‘ ° 1 U .,l‘ U V1 P1 > °'‘
1 \) an 1 Q•
v v ~» ,1 1 «1 1,..1 ,1 , _§1H > 1.1 2 Q 1 L 1 2 L
‘¥ 1U L ¤„
Appendix A. Sample GPL Design lll
11
·•-
ä „-—-————Y 1 d ·
...i ¤¤1 Q Q1 1-1 L••- 1 1r 1 ·r7x"""A Q
L Z 1 Ä. vr1 E 1 1 E Evi 1"'^
J .1
„:1
11 1.: -I----5-·-1 L1 g Q1 U 11-1-_t-1
T1c: _Al °',,1 <ÄQ II
1 11 .. 1 :1 T ,1
/ \ 1 — 1 Q 0-&•“‘
A 1 ·— £ 1 < $,.21... 1 1 ¤¤ .. 1 „-1 ·*= 1V, 1 U .. Q Q A; Q ll Q;
ÖK ll
°
••
• Q 1 E 1 ·• x ¥,.s 1 .12 1 H -1; L1: H- 1 ;; *3 **2;: ?'
Il
. GPLD- 112Appcndnx A. Sample cslgn
Appendix B. Sample Generated Relation Language
Code
Appendix B. Sample Generated Relation Language Code ll3
I
const true, TRUE;
const false, FALSE;
const not, NOT;I
const eof, EOF;
const eoln, EOLN;
struct INPUT;
struct OUTPUT;
Appendix B. Sample Generated Relation Language Code ll4 I
l
procedure displist ( list )
beginlocal temp;
cond (
( list & nil )
& ( list & nil )
)
begintemp = list;
end;
cond (( temp & nil )
& ( temp & nil )
& ( list & nil )
& ( list & nil )
)
beginlist = list;
temp = list;end;
Appendix B. Sample Generated Relation Language Code IIS
procedure flushsys ( proc, res, nump )
beginlocal lcv;
local reslcv; I
beginlcv = 100;
end;
cond (
( lcv & nump )
& ( lcv & nump )
& ( proc & 100 )
& ( proc & 100 )
& ( reslcv & 100)
& ( reslcv & 100 )
)
beginproc = 100;
proc = 100;
end;
cond (
Appendix B. Sample Generated Relation Language Code 117
( proc & 100 )
& ( proc & 100 )
& ( lcv & nump )
& ( 1cv & nump )
& ( reslcv & 100)
& ( reslcv & 100 )
)
beginreslcv = 100;
end;
cond (( reslcv & 100 )
& ( reslcv & 100)
& ( proc & 100 )
& ( proc & 100 )
& ( 1cv & nump )
& ( lcv & nump )
)
beginreslcv = reslcv & 100;
end;
cond (
Appendix B. Sample Generated Relation Language Code 118
( proc & 100 )
& ( proc & 100 )
& ( 1cv & nump )I
& ( 1cv & nump )
)
beginproc = 100;
_ proc = 100;
end;
begin1cv = 100;
end;
cond (( lcv & 100 )
& ( lcv & 100 )
& ( 1cv & nump )
& ( 1cv & nump )
& ( proc & 100 )
& ( proc & 100 )
& ( reslcv & 100)
& ( reslcv & 100)1I
beginI
I
Appendix B. Sample Generated Relation Language Code 119 |
I
1
displist ( res )end;
cond (
( lcv & 100 )
& ( lcv & 100 )
& ( lcv & nump 1
& ( lcv & nump )
& ( proc & 100 )
& ( proc & 100 )i
& ( reslcv & 100 )
& ( reslcv & 100 )
1
beginres = nil;
res = 100;
end;
begin1
displist ( res )
end;
begindisplist ( res )
end;
Appendix B. Sample Generated Relation Language Code 120
beginres = nil;
res = nil;
res = 100;
end;
end;
1
1Appendix B. Sample Generated Relation Language Code 121
Ä
1
I
procedure enque ( pnum, mum, q, tail )
begin
cond (( q & M1 )
& ( q & nil )
)
beginM11 = q;end;
begin
tail = pnum;
tail = mum;
tail = nil;
end;
cond (( q & nil I
& ( q & nil ))
begin
Appendix B. Sample Generated Relation Language Code l22
l
procedure deque ( pnum, q, tail ) l
begin
local trail;
local t;
cond (( q & pnum )
& ( q & pnum )
)
begin
t = q;
Q = Cl?
t = nil;
end;
cond (
( q & pnum )
& ( q & pnum )
)
begin
trail = q;t = q;
Appendix B. Sample Generated Relation Language Code l24
l
end;
cond (( t & pnum )
& ( t & pnum )
& ( q & pnum )
& ( q & pnum )
)
begin
trail = t;
t = t;
end;
cond (
( q & pnum )
& ( q & pnum )
)
begin
trail = t;
end;
cond (( t & rail )
Appendix B. Sample Generated Relation Language Code 125
& ( 1 & tail )
& ( t & pnum )
& ( t & pnum )
& ( q & pnum )
& ( q & pnurn )
)
begin
tail = trail;
end;
cond (
( q & pnum )
& ( q & pnum )
)
begin
t = nil;
end;
end;
Appendix B. Sample Generated Relation Language Code I26
procedure blocked ( proc, procnum, res, blocked )
beginlocal resind;
cond (( proc & 100 )
& ( proc & 100 )
)
begin
blocked = 100;
end;
cond (( proc & 100 )
& ( proc & 100 )
)
beginresind = 100;
end;
cond (
Appendix B. Sample Generated Relation Language Code 127
l
( resind & 100 & not & proc )
& ( not & resind & 100 & not & proc)
& ( proc & 100 )
& ( proc & 100 )
)
beginresind = resind & 100;
end;
cond (
( res & proc )
& ( res & proc )
& ( resind & 100)
& ( resind & 100)
& ( resind & 100 & not & proc )
& ( not & resind & 100 & not & proc )
& ( proc & 100 )
& ( proc & 100 )
)
beginblocked = 100;
end;
cond (1
Appendix B. Sample Generated Relation Language Code 128
P
( resind & 100 )
& ( resind & 100)
& ( resind & 100 & not & proc )i
& ( not & resind & 100 & not & proc )
& (proc & 100)
& ( proc & 100 )
1
beginblocked = 100;
end;
cond (( res & proc )
& ( res & proc )
& ( resind & 100)
& ( resind & 100)
& ( resind & 100 & not & proc )
& ( not & resind & 100 & not & proc )
& ( proc & 100 )
& ( proc & 100 )
1
begin
blocked = 100;
end;
Appendix B. Sample Generated Relation Language Code 129
procedure isolated ( proc, procnurn, isol )
begin
local resind;
cond (( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 ) _
)
beginresind = 100;
end;
cond (
( proc )
& ( not & proc )
& ( resind & 100)
& ( resind & 100)
& ( proc & 100)&
( proc & 100 )I
& ( proc & 100 )t& ( proc & 100 ) i
Appendix B. Sample Generated Relation Language Code 131
i
)
begin
resind = resind & 100;
end;
cond (( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
)
beginisol = 100;
end;
cond (
( resind & 100 )
&(resir1d & 100)
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc )
& ( not & proc )
Appendix B. Sample Generated Relation Language Code 132
1
)
begin
isol = 100;
end;
cond (( proc )
& ( not & proc )
& ( resind & 100)
& ( resind & 100)
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
)
begin
isol = 100;
end;
end;
Appendix B. Sample Generated Relation Language Code 133
1l
procedure allisolated ( proc, nump, isol )
beginlocal procind;
beginprocind = 100;
isol = 100;
end;
cond (( procind & nump )
& ( procind & nump )
& ( not & isol )
& ( isol )
)
beginisolated ( proc, procind, isol )
end;
cond (
( not & isol )
& ( isol )& ( procind & nump )
Appendix B. Sample Generated Relation Language Code 134
I
& ( procind & nump )
)
beginprocind = procind & 100;
end;
end;
Appendix B. Sample Generated Relation Language Code 135
I
procedure reduce ( procind, proc, res )
beginlocal resind;
cond (( proc & 100 )
& ( proc & 100 )
)
beginres = res & proc;
proc = 100;
end;
cond (( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
)
begin
resind = 100;
end;
Appendix B. Sample Generated Relation Language Code 136
1
cond (
( resind & 100 & not & proc )
& ( resind & 100 & proc)
& ( proc & 100 )
. & ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
)
begin
resind = resind & 100;
end;
cond (
( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
)
beginres = res & proc;
proc = 100;
proc = 100;
end;
Appendix B. Sample Generated Relation Language Code 137
begin
resind = 100;
end;
cond (( resind & 100 )
& ( resind & 100)
& ( resind & 100 & not & proc)
& ( resind & 100 & proc )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( proc & 100 )
& ( resind & 100 & not & proc )
& ( resind & 100 & proc )
)
begin
proc = 100;
res = 100;
end;
cond (
( resind & 100 & not & proc )
& ( resind & 100 & proc )
Appendix B. Sample Generated Relation Language Code 138
& ( proc & 100 )& ( proc & 100 )
& ( proc & 100 )n
& ( proc & 100 )
& ( resind & 100 & not & proc )
& ( resind & 100 & proc )
1
beginresind = resind & 100;
end;
end;
Appendix B. Sample Generated Relation Language Code I39
1
extern reducedead;
procedure deadlock ( proc, res, nump, dead, allisol )
beginlocal procind;
local isol;
local block;
beginprocind = 100;
dead = 100;
allisol = 100;
end;
cond (( procind & nump & not & dead & not & allisol )
& ( procind & nump & dead & allisol )
& ( block )
& ( not & block )& ( dead )
& ( not & dead )
)
begin
isolated ( proc, procind, isol )end;
Appendix B. Sample Generated Relation Language Code 140
cond (
( isol )& ( not & isol )
& ( procind & nump & not & dead & not & allisol )
· & ( procind & nump & dead & allisol )
& ( block )
& ( not & b10ck )
& ( dead ) Ä& ( not & dead )
)
beginprocind = procind & 100;
end;
cond (
( isol )
& ( not & isol )
& ( procind & nump & not & dead & not & allisol )
& ( procind & nump & dead & allisol )
& ( dead )& ( not & dead )
)
begin
Appendix B. Sample Generated Relation Language Code 141
I
blocked ( proc, procind, res, block )
end;
cond (( block )
& ( not & block )
& ( isol )
& ( not & isol )
& ( procind & nump & not & dead & not & allisol )
& ( procind & nump & dead & allisol )
)
beginreducedead ( proc, procind, res, nurnp, dead, allisol )
end;
cond (( allisol )
& ( not & allisol )
& ( procind & nump & not & dead & not & allisol )
& ( procind & nump & dead & allisol )
& ( isol )
& ( not & isol )
& ( block )
& ( not & block )
& ( dead )
Appendix B. Sample Generated Relation Language Code 142
1
& ( not & dead )
)
lbeginallisolated ( proc, nump, a11iso1 )
end;
~ cond (( allisol )
& ( not & allisol )& ( allisol )
& ( not & allisol )
& ( procind & nurnp & not & dead & not & a11iso1 )
& ( procind & nump & dead & a11iso1 )
& ( isol )
& ( not & isol )
& ( block )A
& ( not & block )
& ( dead )& ( not & dead )
)
begin
dead = 100;
end;
Appendix B. Sample Generated Relation Language Code 143i
' 1
cond (( a11is01 )
& ( not & allisol )
& ( allisol )
& ( not & al1is01 )
& ( procind & nump & not & dead & not & allisol )
& ( procind & nump & dead & a1lis01 )
& ( is01 )
& ( not & is01 )
& ( block )
& ( not & block )
& ( dead )
& ( not & dead )
)
begindead = 100;
end;
end;
Appendix B. Sample Generated Relation Language Code 144
procedure reducedead ( proc, procnum, res, nump, dead, allisol )
begin
begin
reduce ( procnum, proc, res )end;
begindeadlock ( proc, res, nurnp, dead, allisol )
end;
end;
Appendix B. Sample Generated Relation Language Code l45
procedure receive ( res, proc, mum, pnum, nump )
beginlocal req;
local dead;
local allisol;
begin
req = INPUT;
end;
cond (
( req & res )
& ( req & res )
)
beginproc = 100;
res = res & req;
end;
cond (
( req & res )
& ( req & res )
)
Appendix B. Sample Generated Relation Language Code 146
beginproc = req;
proc = 100;
_ proc = 100;
end;
cond (( req & res )
& ( req & res )
)
beginenque ( pnum, req. res, res )
end;
cond (
( req & res )
& ( req & res )
)
begindeadlock ( proc, res, nump, dead, allisol )
end;
Appendix B. Sample Generated Relation Language Code 147
—
II_ I
cond (( not & dead )
& ( dead )
& ( req & res )
& ( req & res )
)
beginflushsys ( res, proc, nump )
end;
cond (( not & dead )
& ( dead )
& ( req & res )
& ( req & res )
)
beginOUTPUT = res;
end;B
end;
Appendix B. Sample Generated Relation Language Code l48
l
procedure sendmess ( res, proc, mum )
beginlocal mess;
local t;
beginmess = INPUT;
end;
beginres = res & mess;
end; ·
cond (
( res & nil )
& ( res & nil )
)
begin
t = res;
end;
cond (
( t & ml )
Appendix B. Sample Generated Relation Language Code 149
[
u
& ( t & nil )& ( res & nil )
& ( res & nil )
)
begin
t = t;
end;
cond (
( t & res ) .
& ( t & res )
& ( t & nil )& ( t & nil )& ( res & nil )
& ( res & nil )
)
begin
deque ( t, res, res )
end;
cond (
( t & res ) l
& ( t & res ) :& (t & ml) '
Appendix B. Sample Generated Relation Language Code 150
i
& ( t & nil )
& ( res & nil )
& ( res & 1111 )
)
begin
res = res & t;i
proc = 100;
proc = 100;
end;
end;
Appendix B. Sample Generated Relation Language Code 151
I
procedure bankers ( proc, nump, dead )
begin
local numtapes; ‘
local lcv;
local flag;
begin
numtapes = 100; I
end;
cond (
( lcv & nump )
& ( lcv & nump )
)
begin
nurntapes = numtapes & proc;
proc = 100;
proc = proc & proc;
lcv = lcv & 100;end;
cond (( lcv & nump )
Appendix B. Sample Generated Relation Language Code 152
1
& ( lcv & nurnp )
& ( flag )
& ( not & flag )1
& ( lcv & nump )
& ( lcv & nump )
1
beginlcv = lcv & 100;
end;
begin
flag = 100;
end;
cond (
< flag 1& ( not & flag )
& ( lcv & nump )
& ( lcv & nurnp )
& ( lcv & nump )
& ( lcv & nurnp )
& ( not & ·proc & proc & numtapes )
& ( proc & proc & numtapes )
1
begin'
Appendix B. Sample Generated Relation Language Code 153ß
flag = 100;
lcv = 100;
end;
cond (( not & proc & proc & numtapes )
& ( proc & proc & numtapes )
& ( 1cv & nump )
& ( lcv & nump )
& ( flag )
& ( not & flag )
& ( 1cv & nump )
& ( lcv & nurnp )
)
begin
proc = 100;
numtapes = numtapes & proc;
flag = 100;
end;
cond (( numtapes & 100
numtapes & 100 )
& ( llag )
& ( am & mag ) I
Appendix B. Sample Generated Relation Language Code 154
I
1
& ( lcv & nump )
& ( lcv & nump )
& ( lcv & nump )
& ( 1cv & nump )
& ( not & proc & proc & nurntapes )
& ( proc & proc & numtapes )
)
begin
dead = 100;
end;‘
cond (
( numtapes & 100 )
& ( numtapes & 100 )
& ( flag )
& ( not & 11ag )
& ( lcv & nump )
& ( 1cv & nump )
& ( 1cv & nump )
& ( lcv & nump )
& ( not & proc & proc & numtapes )
& ( proc & proc & numtapes )
)
begindead = 100;
Appendix B. Sample Generated Relation Language Code 155
procedure trystart ( pnum, proc, nump, mum, res )
beginlocal dead; „
begin
proc = proc & mum;
proc = 100;
end;
begin
bankers ( proc, nump, dead )
end;
cond (
( dead )
& ( not & dead )
)
begin
proc = proc & mum;proc = 100;
end;
cond (
Appendix B. Sample Generated Relation Language Code 157
I
( dead )& ( not & dead )
I
beginproc = 100;
proc = 100;
res = res & mum;
end;
cond (( not & proc )
& ( proc )
& ( dead )
& ( not & dead )
)
begin
enque ( pnum, mum, res, res )
end;
end;
Appendix B. Sample Generated Relation Language Code 158
procedure grantreq ( res, proc, nump )
beginlocal t;
begin
t = res;
end;
cond (( 1 & ml )
& ( 1 & ml )
)
begint = t;
end;
cond (( t & res )
& ( t & res )
& ( 1 & ml )
& ( 1 & nil )
)
Appendix B. Sample Generated Relation Language Code 159
n
begin
trysta.11 ( t, proc, nump, t, res )
end;
end;
Appendix B. Sample Generated Relation Language Code 160
procedure release ( res, proc, mum, pnum, nump )
begin
begin
res = res & mum;
proc = proc & mum;
end;
cond (
( proc & 100 )
& ( proc & 100 )
)
begin
deque ( pnum, res, res )
end;
cond (( proc & 100 )
& ( proc & 100 )
)
begin iproc = 100; k
Appendix B. Sample Generated Relation Language Code 161l
end;
cond ( ·
( res & nil )
& ( res & nil )
& ( proc & 100 )
& (proc & 100)
)
begin ‘
grantreq ( res, proc, nump )
end;
end;
Appendix B. Sample Generated Relation Language Code 162
”
II
procedure request ( res, proc, mum, pnum, nump )
beginI
local dead;
begindead = 100;
end;
cond (
( res & mum )
& ( res & mum )
& ( dead )
& ( not & dead )
)
begin
proc = 100;
proc = 100;
end;
cond (
( res & mum )
& ( res & mum )
& ( dead )
Appendix B. Sample Generated Relation Language Code 163
1
& ( not & dead )
)
beginenque ( pnum, mum, res, res )
end;
cond (( res & mum )
& ( res & mum )
1
beginproc = proc & mum;
proc = 100;
end;
cond (
( res & mum )
& ( res & mum )
)
beginbankers ( proc, nump, dead )
end;
Appendix B. Sample Generated Relation Language Code I64
cond (( dead )
& ( not & dead )
& ( res & mum )
& ( res & mum )
)
begin
proc = proc & mum;
end;
cond (
( not & proc )
& ( proc )
& ( dead )
& ( not & dead )
& ( res & mum )
& ( res & mum )
)
beginenque ( pnum, mum, res, res )
end;
cond (
Appendix B. Sample Generated Relation Language Code 165
( not & proc )
& ( proc )
& ( dead )
& ( not & dead )
& ( res & mum )
& ( res & mum )
)
begin
proc = 100;
end;
cond (
( dead )& ( not & dead )& ( res & mum )
& ( res & mum )
)
begin
proc = 100;
res = res & mum;
end;
end;
Appendix B. Sample Generated Relation Language Code 166
procedure skipblanks ( ch )
begin
cond (
( ch & 100 )
& ( ch & 100 )
)
beginch = INPUT;
end;
end;
Appendix B. Sample Generated Relation Language Code 167
{
procedure processline ( res, proc, nump )
beginlocal ch;
local pnum;
local com;
local mum;
beginskipblanks ( ch )
end;
cond (
( ch & 100 )
& ( ch & 100 )
)
beginch = INPUT;
end;
cond (( ch & 100 )
& ( ch & 100 )
1 T
Appendix B. Sample Generated Relation Language Code 168
I
begin
pnum = INPUT;
end;
cond (( ch & 100 )
& ( ch & 100 )
1 .begin
skipblanks ( com )end;
cond (
( ch & 100 )
& ( ch & 100 )
)
beginch = INPUT;
end;
cond (( ch & 100 )
Appendix B. Sample Generated Relation Language Code 169
|
& ( ch & 100 ) I
)
beginmum = INPUT;
end;
cond (( com & 100 )
& ( com & 100 )
& ( com & 100 ) _
& ( com & 100 )
& ( ch & 100 )
& ( ch & 100 )
)
beginrequest ( res, proc, mum, pnum, nump )
end;
cond (
( com & 100 )& ( com & 100 )
& ( com & 100 )
& ( com & 100 )
& ( ch & 100 )
Appendix B. Sample Generated Relation Language Code 170
}
& ( ch & 100 ) 1) 1
beginrelease ( res, proc, mum, pnum, nump )
end;
cond (
( com & 100 )
& ( com & 100 )
& ( com & 100 )
& ( com & 100 )
& ( ch & 100 )
& ( ch & 100 )
)
begin
sendmess ( res, proc, mum )
end;
cond (
( com & 100 )& ( com & 100 )
& ( com & 100 )
& ( com & 100 )
& ( ch & 100 )
Appendix B. Sample Generated Relation Language Code 171 ,
1
I
& ( ch & 100 )
)
beginreceive ( res, proe, mum, pnum, nump )
end;
cond (( ch & 100 )
& ( ch & 100 )
)
begin „
OUTPUT = res;
end;
cond (
( ch & 100 )
& ( ch & 100 )
)
beginOUTPUT = 100;
end;
Appendix B. Sample Generated Relation Language Code 172
—
procedure sirnulate ( res, proc, nump )
begin
cond (( not & eof )
& ( eof )
)
begin
processline ( res, proc, nump )
end;
end;
Appendix B. Sample Generated Relation Language Code I74
procedure initprocess ( process, res, proc, nump )
beginlocal ch;
local demand;
local resource;
beginskipblanks ( ch )end;
beginch = INPUT;
end;
begindemand = INPUT;
end;
cond (( not & eoln )
& ( eoln )
)
beginresource = INPUT;
Appendix B. Sample Generated Relation Language Code l75
end;
cond (( not & eo1n )
& ( eo1n )
)
begin
res = 100;
res = process; ‘
res = nil;
proc = 100;
proc = 100;
proc = 100;
end;
begin
proc = demand;
proc = 100;
nump = nump & 100;
proc = 100;
end;
end;
Appendix B. Sample Generated Relation Language Code 176
I
procedure initsys ( res, proc, nump )
begin
local processnum; »
local ch;
beginprocessnum = 100;
res = 100;
end;
begin
skipblanks ( ch )
end;
beginch = INPUT;
end;
beginprocessnum = INPUT;
end;
cond (
( processnum & 100 )
& ( processnum & 100 )
Appendix B. Sample Generated Relation Language Code 177
)
begininitprocess ( processnurn, res, proc, nump )
end;
cond (( processnurn & 100 )
& ( processnurn & 100 )
)
beginskipblanks ( ch )
end;
cond (( processnum & 100 )
& ( processnum & 100 )
)
beginch = INPUT;
end;
cond (
Appendix B. Sample Generated Relation Language Code 178
I
I
( processnum & 100 )
& ( processnum & 100 )
)
begin
processnum = INPUT;
end;
begin
ch = INPUT;
end;
end;
Appendix B. Sample Generated Relation Language Code 179
local res;
local proc;
local nump;
\
begin
initsys ( res, proc, nump )
end;
beginsimulate ( res, proc, nump )
end;
null
Appendix B. Sample Generated Relation Language Code 180
l
Appendix C. Sample Pascal Source Code
program deadlock (input, output);
const
TAPES = 6;
MAXPROC = 10;
BLANK = ’ ’;
MAXTAPES = 10;
type
intlist = —·intrec;
intrec = record
pnum : integer;
req zinteger;
Appendix C. Sample Pascal Source Code l8l
lnext : intlist;
end;
resrec = record
toarc : intlist; V
toarctail : intlist;
avail 2 integer;
q : intlist;
1:111 : 1r1111s1;
end;
restype = array [1..TAPES] of resrec;
procreslist = record
requested : boolean;
allocated : boolean;
producer xboolean;
end;
reslist = array [l..TAPES} of procreslist;
procrec = record
demand : integer;
resources : reslist;
alloc : integer;
maynotfm : boolean;
claim : integer;
req : integer;
end;
Appendix C. Sample Pascal Source Code 182 ,
I_ I
proctype = may [1..3/IAXPROC] of procrec;
VBI
I”€S I I°CStyp€Ä
pI'OC Z pI‘OCtyp€;
nump : integer;
Appendix C. Sample Pascal Source Code 183
l
procedure printq ( q : intlist );
var
t : intlist;
beginif ( q < > nil ) then
begint := q;
writeln; writeln;
wtiteln (’ Process Number Units Requested’ );
while ( t < > nil ) do
beginwriteln .pnum:1,
’ ’, t—* .req:l );
t := t"* .next;
end;
end
else
beginV
writeln;
writeln ( ’ The Queue is Empty’ );
end;
end;
Appendix C. Sample Pascal Source Code l84
procedure display ( res 2 restype );
var lcv : integer;
begin
writeln;
for lcv: = l to TAPES do
begin
if( lcv < > TAPES ) then
begin
writeln ( ’Message Area ’, lcvzl, ’ (jueue’ );
writeln(’====================’);
endelse
begin
writeln ( ’Tape Queue' );
writeln(’==========’);
end;
printq ( res[lcv].q );
writeln; writeln; writeln; writeln;
end;
end;
Appendix C. Sample Pascal Source Code l85
procedure displist ( var list : intlist );
var
temp : intlist;
begini
if(list < > nil) then
begin
temp := list;
while (temp < > mil) do
beginlist := list—‘ .next;
dispose ( temp );
temp := list;
end;
end;
end;
Appendix C. Sample Pascal Source Code l86
procedure flushsys ( var proc : proctype; var res : restype;
nump : integer );
var V
lcv : integer;reslcv : integer;
beginfor lcv := l to nump do
begin
proc[lcv].a1loc := 0:
proc[lcv].resources[TAPES]allocated := false;
if( proc[lcv].req > 0 ) then
begin
reslcv := l;
while ( (reslcv < = TAPES) and
not proc[1cv].resources[reslcv]requested ) do
reslcv := reslcv + l;
proc[lcv].resources[reslcv]requested := false;
proc[lcv].req := 0;
end;
end;
for lcv := 1 to (TAPES - 1) do
begin
displist ( res[lcv].q );
res[lcv].tail := nil;
res[lcv].avail := 0;
Appendix C. Sample Pascal Source Code l87
end;
displist ( res[TAPES].q );
res[TAPES].tai1 := nil;1
displist ( res[TAPES].t0arc );
res[TAPES|.toarctai1 := ni];
res[TAPES].avail := MAXTAPES;
end;
111111
Appendix C. Sample Pascal Source Code 1881
I
Iprocedure enque ( pnum, mum : integer; var q, tail : intlist ); I
beginif (q = nä)
then beginnew ( q );
tail := q;
endelse ubegin
new (tail ‘* .next);
tail := tail*‘ .next;end;
tail—· .pnum := pnum;
tai1·· .req := mum;
= tai1‘·.next := nil;
end;
I
I
Appendix C. Sample Pascal Source Code 189I
I
procedure deque ( pnum : integer; var q, tail : intlist );
var
trail, t : intlist;
begin
if (q‘*.pnum = pnurn)
then begin
l Z: Q? .
q := q‘· .next;
dispose ( t );
end
else
begin
trail := q;
t := q: next;
t while ( t‘· .pnum < > pnum ) do
begintrail := t;
t := t: .next;
end;
trail: .next := t" .next;
if (t = tail) then
tail := trail;
dispose ( t );
end;end;
Appendix C. Sample Pascal Source Code 190
ll
function blocked ( proc : proctype; procnum: integer;
res 2 restype ) : boolean;
var
resind : integer;
beginif (proc[procnum].req = 0)
then blocked := false
else
beginS
resind := 1;
while ( (resind < = TAPES) ar1d
not (proc[procnurr1].resources[resind].requested)) do
resind := resind + 1;
ifnot (resind > TAPES) then
begin
if (res[resind].avail < proc[procnurn].req) then
blocked := true
else
blocked := false;
end
elseblocked := false;
end
end;
Appendix C. Sample Pascal Source Code l9l
- —
l
function isolated ( proc 2 proctype; procnum 2 integer )
: boolean;
var
resind 2 integer;
ibegin
if(proc[procnum].alloc > 0)
then
isolated := false
else
if (proc[procnum].req > 0)
then
isolated := false
else begin
resind := l;
, while ( (resind < TAPES) and
not (proc[procnum].resources[resind].producer)) do
resind := resind + 1;
if(resind < TAPES)
then isolated := false
else
isolated := true
endend;
Appendix C. Sample Pascal Source Code 192 ,
function allisolated ( proc 1 proctype; nump : integer )
: boolean;
var
procind : integer;
isol : boolean:
beginprocind := 1;
isol := true;
while ( isol and (procind < = nump)) do
begin
isol := isolated ( proc, procind );
procind := procind + l;
end;
allisolated := isol;
end;
n
Appendix C. Sample Pascal Source Code 193
{
l
procedure reduce (var proc : proctype; var res : restype;
procind : integer );
var
resind : integer;
beginif(proc[procind].alloc > 0)
then begin
res[TAPES].avail := res[TAPES].avail + proc[procind].alloc;
proc[procind].alloc := O;
end;
if(proc[procind].req > 0)
then beginresind := O;
while ( (resind < TAPES) and
not (proclprocind].resources{resind].requested)) do
resind := resind + l;
res[resind].avail := res[resind].avail - proc[procind}.req;
proc[procind].req := 0;
proc[procind].resources[resind].requested := false;
end;
resind := 0;
while ( (resind < TAPES) and
not (proc[procind].resources[resind].producer)) do
resind := resind + 1;
Appendix C. Sample Pascal Source Code I94
if (resind < TAPES)
then beginpr0c[pr0cind],res0urces[resind]producer := false;
res[resind].avai1 := 1000000;
end;
end;
Appendix C. Sample Pascal Source Code 195
I
procedure reducedead (proc : proctype; procnumzinteger;
res : restype; nump : integer;
var dead, allisol : boolean);forward;
procedure deadlock ( proc : proctype; res : restype;
nump : integer; var dead, allisol : boolean);
var
procind 2 integer;
block : boolean;
isol : boolean; .
beginprocind := l;
dead := false;
allisol := false;
while ((procind < = nump) and (not dead) and (not allisol)) do
beginisol := isolated (proc, procind);
if (not isol)
then beginblock := blocked (proc, procind, res);
if (not block) then
begin
reducedead (proc, procind,res,nump, dead,
allisol);
Appendix C. Sample Pascal Source Code 196
—
end;
end;
procind := procind + l;
end;
if (not allisol) thenbegin
allisol := allisolated (proc, nurnp);l
if (allisol) then
dead := false
else _
begindead :== true;
end;
end;
end;
Appendix C. Sample Pascal Source Code I97
(1
procedure reducedead;
beginreduce (proc, res, procnum);
deadlock (proc, res, nump, dead, allisol);
end;
Appendix C. Sample Pascal Source Code 198
l
procedure receivemess (var res : restype; var proc 1 proctype;
mum, pnum, nump : integer);
lvar
req 1 integer;
dead, allisol : boolean;
beginreadln ( req );
if(req < = res[rnum].avail)
then beginproc[pnum].resources[mum}.requested := false;
res[mum].avail := res[mum].avail - req;
end
else begin
proc[pnum].req := req;
proc[pnum]resourceslrnum].allocated := false;
proc[pnum].resources[mum]requested := true;
enque (pnum, req, res[mum].q, res[mum].tail);
deadlock (proc, res, nump, dead, allisol);
if (dead) then
beginpage(output);
writeln;
writeln ( ’The System is Deadlocked’ );
writeln;
display ( res );
Appendix C. Sample Pascal Source Code 199
l
procedure sendmess (var res : restype; var proc : proctype;
mum: integer);
var
mess : integer;
t : intlist;
begin
readln ( mess );
res[mum].avail := res[mum].avail + mess;
if(res[rnum].q < > nil)
then beginl
t := res[mum].q;
while (t < > nil) do
begin
if (tn .req < = res[murn].avail)
then beginres[mum].avail := res[mum].avail — tm .req;
proc[t—· .pnum].resources[mum].requested := false;
proc[t—· .pnum}.req := 0;
deque ( t—· .pnum, res[mum|.q, res[mum].tail );
end;
t := t—· next;
end;
end;
end;
Appendix C. Sample Pascal Source Code 20l
function bankers (proc 1 proctype; nump : integer) : boolean;
var
numtapes : integer:lcv 1 integer;
‘ flag : boolean;
beginnurntapes := MAXTAPES;
for lcv := l to nump do
beginnumtapes := numtapes - proc[lcv].alloc;
proc[lcv].maynotf1n := true;
proc[lcv].claim := proc[lcv].demand · proc[lcv].alloc;
end;
flag := true;
while flag do
begin
flag := false;
lcv := 1;
while (lcv < = nump ) do
begin
if ( (proc[lcv].maynotf1n) and
(proc[lcv].claim < = nurntapes))
then beginproc[lcv].maynotf1n := false;
Appendix C. Sample Pascal Source Code 202
l
Inumtapes := numtapes + pr0c[lcv].all0c;
flag := true;
end;
lcv := lcv + l;
end;
end;
if (nurntapes = MAXTAPES)
then bankers := false
else
bankers := true;
end;
IAppendix C. Sample Pascal Source Code 203 ,
procedure trystart (var res : restype; var proc : proctype;
pnum, nump, mum : integer );
Vvar
dead : boolean;
beginproc[pnum].alloc := proc[pnum].alloc —+— mum;
proc[pnum].resources[TAPES].requested := false;
dead := bankers (proc, nump);
if (dead)
then beginproc|pnum].alloc := proc[pnum].alloc ~ mum;
proc[pnum].resources[TAPES].requested := true;
end
else
begin
if (not proc[pnum].resources[TAPES].allocated) then
enque(pnum,mum,res[TAPES].toarc, res[TAPES].toarctail);
deque ( pnum, res[TAPES].q, res[TAPES].tail );
proc[pnum].req := 0;
proclpnuml.resources[TAPES}.allocated := true;
res[TAPES].avail := res[TAPES].avail - mum;
end;end;
Appendix C. Sample Pascal Source Code 204
j‘
procedure grantreq ( var res : restype; var proc : proctype;
nump : integer );
var
1 : intlist;
begin
t := res[TAPES].q;
while (t < > nil) do
beginif (t* .req < = res[TAPES].avail) then
txystart (res, proc, t“ .pnum, nump, t‘* .req);
tz = t—· .next;
end;
end;
Appendix C. Sample Pascal Source Code 205
I
procedure release (var res : restype; var proc : proctype;
mum, pnum, nump : integer );
beginreadln;
res[TAPES].avail := res[TAPES].avail + mum;
proc[pnum].alloc := proc[pnum].a1loc - mum;
if (proc[pnum].al1oc = 0) thenbegindeque (pnum, res[TAPES].toarc, res[TAPES].toarctai1 );
proclpnuml.resources[TAPES].a11ocat·ed := false;
end;
ifres[TAPES].q < > nil
then grantreq ( res, proc, nump );
end;
Appendix C. Sample Pascal Source Code 206
procedure request (var res 1 restype; var proc : proctype;
mum, pnum, nump : integer );
var
dead : boolean;
beginreadln;
dead := true;
if (res['I"APES].avail > = mum) then
begin
proc[pnum].alloc := proc[pnum].alloc + mum;
proc[pnum].resources[TAPES].requested := false;
dead := bankers (proc, nump);
if (not dead)
then begin
if (not proc[pnum].resources[TAPES].al1ocated)
then begin
enque (pnum, mum, res[TAPES].toarc,
res[TAPES].toarctail);
proc[pnum}.resources[TAPES].al1ocated := true;
end;
proc[pnum].req := 0;
res[TAPES].avail := res[TAPES].avail - mum;
end
else
Appendix C. Sample Pascal Source Code 207
pr0c[pnum].a11oc := pr0c[pnum].aLl0c - mum;
end;
if deadthen beginpr0c[pnum|.res0urces[TAPES]requested := true;
pr0c[pnum].req := mum;
enque ( pnum, mum, res[TAPES].q, res[TAPES].tail );
end;
end;
Appendix C. Sample Pascal Source Code 208
ß
II
I
procedure skipblanks (var ch : char);
beginI
read ( ch );
while (ch = BLANK) do
read ( ch );
end;
Appendix C. Sample Pascal Source Code 209
1procedure processline (var res : restype; var proc : proctype;
nump : integer);
varP
ch : char;
pnum : integer;
com : char;
mum : integer;
beginskipblanks ( ch );
if (ch = ’D’) then
beginreadln;
page ( output );
writeln;
display ( res );
end Aelse
begin
read ( ch );
read ( pnum );
skipblanks ( com );
read ( ch );
read ( mum );
case com of
Appendix C. Sample Pascal Source Code 210
_ l
'Q' : request (res, proc, mum, pnum, nump);’L’ 2 release (res, proc, mum, pnum, nump);’S’ : sendmess (res, proc, mum);’R’ : receivemess (res, proc, mum, pnum, nump);
end;
end;
end;
Appendix C. Sample Pascal Source Code 211
procedure simulate (var res : restype; var proc 1 proctype;
nump : integer );
begin
while not eof do
processline ( res, proc, nump );
end;
Appendix C. Sample Pascal Source Code 212
II
procedure initprocess ( var res : restype; var proc 2 proctype;
process 1 integer; var nump 2 integer );
var
ch 2 char;
demand 2 integer;
resource 2 integer;
begin
skipblanks ( ch );
read ( ch );
read ( demand );
if not eoln then
begin
readln ( resource );
new ( res[resource].toarc );
res[resource].toarc‘· .pnum := process;
res[resource].toarc—· .next := nil;
proc[process]resourceslresource}.producer := true;
proc[process].resources[resource}.requested := false;;
proc[process].resources[resource].allocated := false;
end;proc[process].demand :=
demand;proc[process].alloc:= 0; I
proc[process].req := 0; :nump := nump + l; I
I
Appendix C. Sample Pascal Source Code 213 II I
I
I
procedure initsys (var res : restype; var proc : proctype;
var nump : integer );
var
processnum 2 integer;
ch : char;
beginprocessnum := -1;
res[TAPES].avail := MAXTAPES;
skipblanks ( ch );
read ( ch );
read ( processnum );
while (processnum < > 0) do
begininitprocess ( res, proc, processnurn, nump );
skipblanks ( ch );
read ( ch );
read ( processnum );1
end;
readln;
end;
Appendix C. Sample Pascal Source Code 215
l
begininitsys ( res, proc, nump );
simulate ( res, proc, nump );
end.
Appendix C. Sample Pascal Source Code 2l6
I
CS566l
Spring, 1987
Dr. Sallie Henry
Due Dates
Design: April 23, 1987
Code, Revised Design, and Output: April 30, 1987
Points: 50
Motivation
The motivation for this assignment is twofold. First, you will use a modern design language to aide
in the architectural and detailed design phases of the software lifecycle. Design languages are tools
created to make the desigi process easier, and more efficient. This in tum helps to expedite the
implementation and testing phases of the software lifecycle, and to help us to produce more reliable
software. Second, you will simulate management of consumeable and reusable operating system
resources to prevent and detect deadlock.
Constraints
Our system will use the following constraints:
1. 10 tape drives (our reusable resource!)
2. 5 message areas (our consumeable resource!)
Appendix D. Operating Systems Assignment 218
1l
3. Any number of active processes
4. A FIFO queue associated with each appropriate resource
5. Barikers algorithm for automatic deadlock prevention of the reusable resource
6. A deadlock detection algorithm for the message areas.
note:
a single queue is needed for management of the tape drives, because a process doesn’t care
which tapes it gets, but, each message area will require its' own queue. \Vhen resources
become available, the first member of a queue is checked to see if there are enough avail-
able. lf so, the resources are granted. If not, continue checking the queue and grant any
of the resources that you can.
When deadlock is detected simply flush the inventory and queues of each of the 5 message
areas.
Input
At the beginning of the input there will be a series of initialization lines that give the maximum
demand for tapes and the number of the consumeable resource for which the process is a producer,
if it is one. The end of the initialization section will be flagged by reading in a process number of
0.
The initialization cards will have the following format:
Appendix D. Operating Systems Assignment 2l9
1. Producer process initialization
process max. demand produces
P = 3 D = 2 l
2. Non—procducer process initialization
P = 2 D = 5
Input consists of the following types and formats:
1. Tape request
process number of tapes
P = 1 Q = 4
2. Tape release
process number of tapes
P = 3 L = 1I
3. Send a message
process resource number number of messages
P = 5 S = 3 4
4. Receive a messageÄ
Appendix D. Operating Systems Assignment 2201
process resource number number of messages
P=2 R=l 2
5. A display of all of the jobs in the system
D
All input will be syntactically correct, and there will also be at least one blank after every number.
Output
Output should consist of the following:
1. Whenever a display is called for in the input file, the contents of each queue should be dis-
played
2. Whenever deadlock is detected, output a message to that effect, and display the contents of
each queue.
Appendix D. Operating Systems Assignment 22l
Grading !
Your design will be an integral part of your grade (so don’t just throw something together!). It
will be graded on both quality and completeness. The design you hand in with your working sys-
tem code should reflect any changes that were made during the implementation process. If you’ve
done a good job of designing these changes should be minimal at best.
Initial Design : 50%
Revised Design and Code : 25%
Results: 25%
There will be a help session on the design languages at 4:00 on Monday the 20th in McB 328.
I
Appendix D. Operating Systems Assignment 222 I
I
Appendix E. GPL Regression Line and Conlidence
Interval Plots
IIII
Appendix E. GPL Regression Line and Conlidence Interval Plots 223 tII
I
I
SSUFIIESC J. xl
1~.• .'.
• .'
uß _i.‘,·l
Jjl
.jl 7
„ I "·
·Q·•'l vl _
BL °, -'ri
,ll
4 , , I,,,I
.',’
{ 1•
I ,' .'1
, Y I I I I ,.
.' j 7 7 7 7 7,‘
Jjl 7 7 7 7. 7 7
,‘
.jl 7 7 7
,’
jl 7 7 7 7 ,' l
.' j 7: 7 7 7 I1 7 7 „',‘ ll
•‘ j 7 7 7 7 7 7 7 ’,°Ä
jl 7 7 7 7 ,'I ¤
,’„ ,' 7 7 7 7 7 l,
6• 7 7 7 7 'zl
,4 7 7 7 7 7 7 1-'• I 7 I _-I
•' 7 7: 7 7 7 vl
q QI
I,
J L-• I I I I- I '¤•: 7 7 7 7· 7 7 7 '·°{ 7 7 7 7 7 7 _·'J 7 7 7 7 ·': ,·•’ 7 7 _«7• •7 7 7 I,
· ·
[{ll
.
IO I‘ I
{ I• [
·
II •!
O I
I P 00 Q! .,0 0
7 7 S 7 $7 % 7 :»•
Ziiiöx
Appendnx E. GPL Regression Line and Conlidence lnterval Plots 224
I
I
I
SQUFL.HUC ,·'
•I '"
I j
Wse I,
•- ,'
{ ·'I X
I’BUG7 ' .'‘
I
·
IlÄ
'II
'Ü, V"
l: I IV ,1
Ijr ,
IV}
nl ill I'!I e ·
1
', fr P l;
ZUG 7 ,' ."1 ü' ußu zu v j
I "' I I— 'll
I X nu; *,·‘
•. 'li:
I,
I I".
·
,I"
. Ijl v *
XI
I I V · ' '",·”
{ 1l ' l"I" { .'{ I g
’ 1,
•I ·· V I·
.1·I
, 1,
• ÖIaU» •„ ,_ V V V ,·
{ ., l ,·
InL- ·
. I * ·I1_A ·_ „ U ng • lg
I-
xr I ; I1°
I 1
I ° • { ° * , ¤ IX°i ' : v•I ° • „·I ' =·; ÜP Ü ,'
*._
lt{av
•I 5*1:
7I~
,_ •:r·*,
{ 1 gg {UG"‘I‘
CEE E GN ”
Figure 9. GPL N Regression and 95% Confidence Lines
Appendix E. GPL Regression Line and Conlidence Interval Plots 225
V
VV
~
SOUFZIESOUL-IV aeV )
VVI ·»<
VV .
V 3
V!J
3 U -J".
UV f.·'
7 ,·'l
•
V 3 „" V
V .·" ’
I‘/Il •
„ '• IV ."J r"V 3 3
’
3JOCYJV. . , '°V
J'.'
2*" 3 I ,•°'
I ·~ .'•·'T.! Q
Ü- ,•"'l
J ·-
D*
‘_
..0.--
.V • '··’ „.··'
I 3 , '· 3 _l ·”6
,· U
·
'-I
V7* °
’° 3
,3 J'._V3
·
ip! , ¤ • _•'
·I ‘ 3.
'_•
V Ux .•°·
3 :U3•°$ * 3 H-
I bnr _•'
V ¥ 3, _¤'„ ¥ ; U '•'V * .·
IOC EOS SOL QUL 532 ECC 7GI EDI :6:
Zäälßu
Figure IO. GPL Volume Regression and 95% Confidence Lines
Appendix E. GPL Regression Line and Confidence lnterval Plots 226
— 1
I
I
I
I_I11-3 ISUUEZE I
16¤¤¤¤I . „* II I
Ä7CÜÜC· j_,'
IEOOOÜI „¤' „I
*"'
ISOOOC ·“II
«
;s¤o¤c{ ' _„"
:2o¤¤¤{_«”
I ·‘ .='
:1000:1¤¤¤¤¤{„“
I'I „”_•'
I-
•° ;
IBOOOZ ‘
v¤¤¤:{ _«'·•„'·*
'_•'
6¤¤¤:{ ·’ _»"
: * ·"I
Is¤¤¤:{_· ‘
',· _„"
°I · U |·
-•"·
moon: { „-'Jg-Ö
-* I
'•°•
E r ¤ _•'
scc¤:{ ’ _ , -I„·
L I*
F * "«
•~•« er I’·
· ·
•·•' I
•I
*-
'0.t
4 tur er ._„'
JZIUÜÜI;§:T“‘·
«·”[ 4* ‘¤ „'
E ECGOC QSGCZ SUSE! LJCCCI SCOCZEEEZGK
II I
IIFigure ll. GPL Eflort Regression and 95% ConüdenceLinesI
II
. . . IAppendnx E. GPL Regression Lme and Conlidence lnterval Plots 227 I
IIII
II
S¤U?ZEZU •j ' IX
1 E ,I·„' •
J>‘16'*1
>~'16 4 *
J -‘1 ’
°'. ': ·
‘ .'
1;.J-· I
l
I134 » .' *I
.‘7
vl
12 5J ,·' „. . I
XI ·'; . 1 ' ,·
_.'
1 .' ,·1 ,' ,·
l '
•
1:-5 ···1 .'I °i .·'
K- · 7 7 x «
°IErx
·Ü-1 ,* 1 7 7 s 1 ,'
E Ä K, 7 7 1 x s ’•"
E • x • 1 x Q71
'I,
A 1 7 7 Q"
E 1 7 7 7 ,"
II.•Q
1 7 7 •'
Z E E E ¥ E ‘ 7 E E 3 C1 1 1 L?
EBS K GN
Figure I2. GPL Cyclomatic Regression and 95% Confidence Lines
Appendix E. GPL Regression Line and Confidence lnterval Plots 228
I
‘ 'I
SOURCEJOOOG ,· ,I zu '„’
‘ I n"rl,
· BODCsooo
-, __Iv'
al,
7 •l Xi
• Il
-1":00C ·I ,· ,·
IIa, ,1,
Ü I I
i Q ["’
QIl,
g 'll
_ I 1; • • ,"BÜÜL al ,'I
Irl, 'll
I"
• I _ 3 ,°I rl vl
PDOC ~• ,'¤‘I '¤'I Q y
"1 ,'I I I
·3
jl
zoo: -*·Q Q ;·-_ tf I l'_ Q 3 y I"I '•Hr { ,'
'• :.'
E IOUG ZCSC SCOE HBOC EOCG SUSE 7'CCC SOOC SOOC ZCSCCEisisw
Figure I3. GPL Information Flow Regression and 95% Confidence Lines
Appcndix E. GPL Regression Line and Confidence Interval Plots 229
I
ISUUEZE3¤¤¤¤£¤ _
I X =·I >· ,"
I ·'
I ·'7 .·
E*‘ „'
I| I
II ·' ‘
I ·20000CjIr' ,"
II·" "1' X .'J .· .·
I lv lvI ll ll
•iP vi ¢,
z I J" ,'
JOOOOC ·‘,'I," r'
J v r KI •·* .,' • ,'j . ‘ "'I I'!
! v'
vl
Ä I lvl lvl
·I Ü/I {I!I vl F Xvl
JII, ‘I
I r'I,
nv i XI
T •-‘ ·,': • X ,·
.‘ X 'X Xx XX/azW v. * * ,-1; XX
Ü SOCCZ JCOCOG ZSUOCC ZSCSSCZEEIGN
Figure 14. GPL Information Flow with Length Regression and 95% Confidence Lines
Appendix E. GPL Regression Line and Confidence lnterval Plots 230
I
” SOURCE7 . OE • OE -{ _
1 1 'I’ ’
{’L "l Il"
Elvl t
I1,
E . G: ·· DE — _· _«7 ,1 I!
31/
I"
E.CE·OEÄ,I·' ,"XI ·'
.I {vl
1„_Qg•g£,é I; x,
A· I"
1/
j "I Ill
E.EE*DE5*j.4Ku! ,'
I ,; I''1‘
2 • I": ," l
1,,
i 1, /•_ ‘/ ,1
3: ,"4 „ G:·*OE T
_ _„J ' ·'4 Q;
lr,
Wal;vl
L— . 1.
Av- „‘·„ Q
*
'I
° Ir n:.~· ä ·• • •• U s '
C . EE • ’ · .: 4 .°° z.cs~osEiälax ‘
Figure 15. GPL Information Flow with EfTort Regression and 95% Confidence Lines
Appendix E. GPL Regression Line and Conlidence lnterval Plots 231
SOUHZE:¤c¤¤c{ 2 ·
7l[ 1SUOOC- {_
Il
1 ,·, 22 ,1 _·
6¤¤¤:·_
v¤¤¤cSOÜU[·{
x gi ,·' ,
SOOOC { ,·1 ,· .’l
llI"
u¤¤¤:—
·3131102-g
Il"
¢"’
2¤¤¤:— -E‘
H I -
—al
[ Irl"
1000:- -Ö."6•1 ¤ ,'
i°°•=5a;[-sv ."
C JOOOG ZOUUG SODOC- NOD32 53332 60332 73332u
EESIGN ·
Figure 16. GPL Information Flow with Cyclomatic Regression and 95% Confidencc Lines
Appendix E. GPL Regression Line and Conlidence lnterval Plots 232
Appendix F. ADLIF Regression Line and
Confidence Interval Plots
Appendix F. ADLIF Regression Line and Confidence Interval Plots 233
III
I
SSUEIEvita x
._l
1’°‘ ll
._I y'
J ’,,1,
,, 1.’
UOI
_g'
4 ll
I• ,·'
sc—iIll
. ’„' {X•' ll! ’lIII •” ·’ ' 'IE
X,v"
-·‘ ‘
".‘ D li .".
• ,l' '.‘
:·'•' D D „"
. „· eu. ,'_ '¤ III ,'
=r. 4 • „‘ '• ·'4 "‘ _; ,' ¤D/ X
g 1 ·‘
"
p I Ia'Q X D D
D/Yll Il
1 .· ·' •¤ • .l•l {V,
I I $/ I IV I
. ; D r/’,’
J g' D: tn ,4
,’ ¤/ D Dv 'XJ D' D II D «‘“'- •' X ue IRJI •'
{ L , , v• 1 ID uv gl ¤• er l.‘ X eupl • D _·.‘ X D D D rn em ll_‘ 'X ¢•¤eeD D ,'{ Il / ¤¤D D ,'.Q ll - ;¢ D D ,'Q ,' ßen IX•" D guhusux D '•J ßID '«
Q •; es/D ¤D _•. zu D _·.· ID D ,'4 II BI ,'4 ¤¤D
,’•' D II X4 D D IX•‘ [ 1J g XJ «'
C L C 2£· EC XI SZ EC ».
ZESZBN
Figure 17. ADLIF Length Regression and 95% Conlidence Lines
Appendix F. ADLIF Regression Line and Conlidence Interval Plots 234
I
I
SOURCEROG -1
_
1,’l >«
I7 rl
I ,1 [
Igl
Ä‘l
Ä•'
J ' • ·'I ··II ·‘ X
BOB j °„·Ü
I •' C X
I"
1,
J -•" r
X,
I·I ·~·°1X ‘ u X
EIll
·ggg.I J. • _ I I,I l
•
"T,’ •· ,*' ,'
J X ¤ rn XI I" l y
'l
•, 1 * >° Xn I F
Ä ,· FJ; ,*1 ’, • > , s ll
I l" ‘ — ig"1
lvl>
·_ I,f I"°· „*1¤ · „_‘
' {Ä v, 1 1Z IX
I I!‘ vl
'„ gr TX,
j r * XI2* "
_‘ ¤ XI • X
rI lll -
s ° ·
C E GC E CZ E CC Q C2EZSISN
Figure 18. ADLIF N Regression and 95% Confidence Lines
Appendix F. ADLIF Regression Line and Confidence lnterval Plots 235
III
‘ ’"SOUn-:
3006 •I _.
2* Ir
I',
I ’ ·'I ,·I
’II ·' ‘
IUX {X
I
ll1,
2006-'I.‘ KI I I"
'II
„ I I 1
I "·
'lll "I
Y"l'
·"I
IW , » lf ,·
,"I
" ~ "_ X‘ s/
,’. I
·
I
' _ I I1 • • g ‘Xll,Ü:r
'• 8 1'
l¤¤L•
I" ' g r'I . • I/hn „'
I„' r ·°I vr z
-X.·
·; x ' . ··I-I'I . . 'I
ÄI'1
·-5 "1
I 5, ,,!¤ .'• ~§*
"I 3"I
IÄ·°;*?"?- ."I W" IX
I..';·1• „’L O I
[I 2006 200S 3006
ZESZSK
Figure 19. ADLIF Volume Regression and 95% Confidence Lines
Appendix F. ADLIF Regression Line and Confidence lnterval Plots 236
?*„
SGUEEEIBOOUEJ . ;
Ix_
': X F
: Flvl
I ·'I
,"
J¤OO¤E¢ x
IZBOSOD '.' ’lI
'I
I':2000:-I‘
11000Dq ;' _ ' _:
I *X, _·'
I ¤ y'.’
1¤¤¤¤c- I,·
I I'l•
I 1" r 'X.
.IBOSS.¢ „· -,·
I X us 'XI, I" I I I
·I"
7¤¤"*· .' /I• ;
l
I SSOGI °„I,· ,'
I.! "I
ESSSI ___/
2.II I I '1
•
"
I 1
y'°‘ •._ • lf
HOSSE1‘ .'
I:‘ rr IX
I I 1
' I I II le3ÜÜÜ»* •I '°‘• F /::’: X
I · ' Ä;} 'I
vl
Ü —{I1
I"-'älIJ • 1,
P'
I!_ zocat ‘ ,·C. Je
jl
. Z ZSSGE QCSEG ESGE? ESGE? ZSSSSE LZEEEE ZQEGGE2€$3;x
Figure 20. ADLIF Effort Regression and 95°/• Confidence Lines .
Appendix F. ADLIF Regression Line and Conlidence lnterval Plots 237
suunzi3C%I
II7 ;
JIII
I
I7I.I, I
2sJ 7I
I
I".;
•I ,¤'• '• I·
J .·" •
I1 I_•'
*
I1 ,-·"} [. .JIJ
• ,.·° • • ',·IJ _•’° I • I I
I I 7 7 • II•
I I I I I ',•'
I,•'
•; I I — I I I'•°•
• I 7 I I I IJM'.
•¤ I I III1
2 E é E E 7 E E ZI ll L2 12 Ze LE ZE
J ZESZGN
Figure 2l. ADLIF Cyclomatic Regression and 95% Confidence Lines
Appendix F. ADLIF Regression Line and Conlidence Interval Plots ggg
I
SUUFIZE15000 1* /:2:0:7.
Ü '"I III
l700£·
·1600C1Öl I"
‘1'l
:s¤¤c~{I 1,‘• 1, ,'
Juoocq g ,*
'
'I 1/
Z300: ·I ·' .'I
I,
"
1200:1 / X
I .' .'Z 1 0CC .' ,'
1'¢’ .’
‘I I
1¤¤¤:~4 ,· ,·l ,1 'I
1I I
i I 'I
SOS; · ,·I .· x
W.’ 1'
, I « 1S¤¤t·1 .· " .· ·I
700Z •I i'-nr· ‘ ’ /Guy: { ,' • ¤ 1
I 1, 1l
i II {I, I 1 l 1:0CC ,,
1/ • I1;$00: •' ¤ ,' ° Ü .’
.I -7”
BCC!{P',
",’_
'°; 1-:1:00.•— -4
',‘_ I
"• Uvv ° 1l1:*'
IK •= • '
Ü EGBGB 20303 3000EZiilöu
Figure 22. ADLIF Information Flow Regression and 95°/• Conlidence Lines
Appendix F. ADLIF Regression Line and Conüdence lnterval Plots 239
SOUEZÄ6¤¤¤¤€{.·7'~
'„rl 1,
TI„' „
SUOCG:· f ,7
.' ·47 ."
NOOOOC< ; X
: If l.’
{4.73¤OOOCey ;·:
Il ‘l
E Ilr, I',
ZUUCCÜ··,,'E
,4 °Y
ll,g
1,
°—·
{ I1l
J'
ll III„ I
'. *·‘ xlÜÜÜUa •i I"
s‘ ,·2
IIIY
I 1/_~ • ,'.' ' V.,} _7• I
·• vls • F, v• {
In
•I,
4
Z II 7
C SCCÜUÜ ICCECZÄ ZBGGDCIZiälßx
Figure 23. ADLIF Information Flow with Length Regression and 95% Contidence Lines
Appendix F. ADLIF Regression Line and Contidence lnterval Piet; 240
I
SSUEZEE. . Di · OE J . _·
l >< gl ,’-
l ·' ,'
, "~'E . Ü: ‘ U E ,’ ,'
.· . G: • OE , I,Ü
Ill "I
I ·' •l
E. . EE • DE J * ·° ·'
E . EE ‘ D E J’
· ,'
,"I,
¤..¤s·¤a—j‘l- X) I
J1 II. I
. 7 ß l·l{E
. EE • C E •' ,' ·‘I ll
i lf ,'
. ,„ . ['I4• 4: • O: •„ f I.
Ä ,’ " ·I
1/ * ·'
• • HE •E Jr ’ I• G ‘
ä g : 'I‘ ll
.••§ ' gl¥'·• ,’
Z.§E·.'1I·F· ·’
Z.Gi·SC E.C·E•ÜE i.ZE·Eé L.Ei•€:E Z.EE•DEZiiißx
Figure 24. ADLIF Information Flow with Elfort Regression and 95% Conlidence Lines
Appendix F. ADLIF Regression Line and Conlidcnce Interval Plots 24}
S U U F Z EzzcconqI I', I,
I I{I
l ‘: I,
1 O C O O E ,· „·I
r
sooo:I fl Ü,
1 ÄIl
aooocjwos:-{.·, J „
I ' Ip I
ll Il
5C U U c ·g g ,·I
,’ll Ü ll
sooo: ·QI· '• I '
I, HOOCZ •QJI1,'
'·'l ‘ „"
Ial
' /’l
I ,‘ · X3 O O C Z •„ ,· • ,·
é rx J!
"
• ,'
I(1, I {z'
2¤¤:: -_ ,,'.6• ·'‘ •·
1l' : •¤ .'. •. ,
I••~
¤gg { •h ;" Il
J U u • ;_·\ 4*
-Il
i 0lg ['"I: ,’•? l'
{ fl!I"_
[ ZCCUOC PCGZZZZ ECG332 .
ZE E E G N
Figure 25. ADLIF information Flow with Cyclomatic Regression and 95% Confidence Lines
Appendix F. ADLIF Regression Line and Conüdence Interval Plots 242
CS4980 Final Exam
I Your assignment, should you decide to accept it (well, actually you must accept it), is to design and
implement the "robots" game. The following is what the board to the game must look like:
| < --·-----—·~---·-60 spaces------—------—---- > I
+ --·------------——--—--·-·----------·------——· + MOVES
I II I y u 1I I \ I /
I I h · I · kI I / I \| | n m ,
I II I| I COMMANDS
I I| | t - teleport| | s · last stand
I I q - quit| L · redraw |
I II I| | KEY
I I
Appendix G. Software Engineering Assignment 244
| I I - you
| | = - robot
I | @ - junk heap
I I+ --——---------—--------·-------·-------—------ + SCORE
0
The object of the "robots" game is to get all the robots, who are trying to get you, to run into each
other, or into junk heaps. \Vhen two robots collide they both die, and a junk heap is created. You
can move around the playing area using the keys shown ir1 the MOVES area of the display. You
may not move outside the playing area, any attempt to do so should be counted as a move. For
example, if you are on the lefthand edge of the playing area and you attempt to do an "n" you
should leave yourself on the lefthand edge but move yourself down one row. If you tried to do an
"h" you should leave yourself in the same place, etc,. Every time that you make a move, each robot
also makes a move.
Note:
Striking any other keys than those of the commands or moves does nothing, and does not
count as a move.
Commands
• The "teleport" command randomly generates a new position for you in the playing area. You
can teleport at anytime. Teleporting counts as a move so, after your new position has been
deterinined and yOl1 have moved there, the robots all get a move.
Appendix G. Software Engineering Assignment 245 I
• The "last stand" command has the same effect as doing "j"s, i.e. don’t move anywhere, until ,
you die or all the robotsdie.•
The "quit" command quits the game.
• The "redraw" command simply redraws the screen.
The Play
Initially the playing area has ten robots and you on it. You get the first move, then all the robots
get a move, then you, and so on. lf you succeed in lgilling all of the robots you have won the round.
The next round will start with twenty new robots and none of the junk heaps created in the previ-
ous round, then thirty new robots and none of the old junk heaps, then forty, etc., Play is ended
when you die.
Note:
Don’t forget that when you are generating positions for the robots it is possible that you
will generate two robots to be on the same position. This is called a collision, and your
program must handle collisions by providing a different position for the colliding robot.
Death
Death is signified by printing "*MUNCH*" at the position on the screen where you died, and is
achieved in one of three ways:
l. A I'ObOI IHOVES OHIO the space where you are
Appendix G. Software Engineering Assignment 246
2. You move onto a junk heap
3. Teleporting onto a place where there is already a robot
Scoring E
Your score is printed in the lower right hand comer of the screen (see the diagram above) and is
updated continuously. Every robot that you kill is worth the same number of points that there
were robots on the screen at the beginning of the round.
The Robots
The robots are not too intelligent, and their moves are very simple. If you are on the same row
or in the same column, the robots simply take one step in your direction. Otherwise, the robots
take one diagonal step in your direction. The robots are not intelligent enough to look and see if
some other robot is going to move to the same place that they are, nor do they look to see if there
is a junk heap already on the spot they are going to move to.
The Assignment
You are to design, in ADLIF or GPL, and implement, in PASCAL, the "robots" game.
The ADLIF group Will be using the VAX35 account:
Appendix G. Software Engineering Assignment 247
CS49800Fpassword: adliff
The GPL group will be using Zonker, under Roger’s supervision, for their designs and the VAX35accountCS4980l5password:graphicI
Th VAX35 accounts have a sub—directory, by last names, for each of the persons who will be using
that account. Please work only under your sub-directory.
Appendix G. Software Engineering Assignment 243
Recommended