Ä, @2. xy H' /2/ - vtechworks.lib.vt.edu · Chapter 2. Overview of Metrics ... HIPO Diagrams A...

;{/ _”

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.


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.


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


' 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


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.


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.


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.


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


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-


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-


—

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:


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


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


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 >


—

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


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


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


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


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


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


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.


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


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


*

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


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


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


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


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


lil

designs used in this study are at a very detailed level of refinement and the accuracy of the equations

reflects the detail.


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


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.


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


—

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


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.


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


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


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


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


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,


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.


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


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


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


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

L

Appendix A. Sample GPLDesignAppendix

A. Sample GPL Design 83

1

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

II

Ö 9IS .;°_

Append°ix A. Sample GPL Design j 85

^\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 Ü


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


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 ~


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


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=»·¢


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«.


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 ‘—¢


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


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


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

I

end;

Appendix B. Sample Generated Relation Language Code ll6

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 (


( 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;


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

tail = 100;

mu = tail;

end;

end;


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;


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 )


& ( 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;


& ( proc & 100 )

)

beginresind = 100;

end;

cond (


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


P

( resind & 100 )

& ( resind & 100)

& ( resind & 100 & not & proc )i


& (proc & 100)

& ( proc & 100 )

1

beginblocked = 100;

end;

cond (( res & proc )

& ( res & proc )

& ( resind & 100)

& ( resind & 100)



& ( proc & 100 )

& ( proc & 100 )

1

begin

blocked = 100;

end;


l

l

l

end;


procedure isolated ( proc, procnurn, isol )

begin

local resind;


& ( 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


i

)

begin

resind = resind & 100;

end;


& ( 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 )


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;


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 )


I

& ( procind & nump )

)

beginprocind = procind & 100;

end;

end;


I

procedure reduce ( procind, proc, res )

beginlocal resind;


& ( proc & 100 )

)

beginres = res & proc;

proc = 100;

end;


& ( proc & 100 )

& ( proc & 100 )

& ( proc & 100 )

)

begin

resind = 100;

end;


1

cond (


& ( 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;


begin

resind = 100;

end;

cond (( resind & 100 )

& ( resind & 100)

& ( resind & 100 & not & proc)

& ( resind & 100 & proc )

& ( proc & 100 )

& ( proc & 100 )

& ( proc & 100 )

& ( proc & 100 )



)

begin

proc = 100;

res = 100;

end;

cond (




& ( proc & 100 )& ( proc & 100 )

& ( proc & 100 )n

& ( proc & 100 )



1

beginresind = resind & 100;

end;

end;


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;


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 )



& ( dead )& ( not & dead )

)

begin


I

blocked ( proc, procind, res, block )

end;

cond (( block )

& ( not & block )

& ( isol )

& ( not & isol )



)

beginreducedead ( proc, procind, res, nurnp, dead, allisol )

end;

cond (( allisol )

& ( not & allisol )



& ( isol )

& ( not & isol )

& ( block )

& ( not & block )

& ( dead )


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 & dead & a1lis01 )

& ( is01 )

& ( not & is01 )

& ( block )

& ( not & block )

& ( dead )

& ( not & dead )

)

begindead = 100;

end;

end;


procedure reducedead ( proc, procnum, res, nump, dead, allisol )

begin

begin

reduce ( procnum, proc, res )end;

begindeadlock ( proc, res, nurnp, dead, allisol )

end;

end;


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 )

)


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;


—

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;


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 )


[

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) '


i

& ( t & nil )

& ( res & nil )

& ( res & 1111 )

)

begin

res = res & t;i

proc = 100;

proc = 100;

end;

end;


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 )


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 )


& ( 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


I

1

& ( lcv & nump )

& ( lcv & nump )

& ( lcv & nump )

& ( 1cv & nump )

& ( not & proc & proc & nurntapes )


)

begin

dead = 100;

end;‘

cond (

( numtapes & 100 )

& ( numtapes & 100 )

& ( flag )

& ( not & 11ag )

& ( lcv & nump )

& ( 1cv & nump )

& ( 1cv & nump )

& ( lcv & nump )

& ( not & proc & proc & numtapes )


)

begindead = 100;


end;

end;


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 (


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;


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 )

)


n

begin

trysta.11 ( t, proc, nump, t, res )

end;

end;


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;


& ( 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;


”

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 )


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;


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 (


( 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;


procedure skipblanks ( ch )

begin

cond (

( ch & 100 )

& ( ch & 100 )

)

beginch = INPUT;

end;

end;


{

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


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 )


|

& ( 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 )


}

& ( 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;


—

I

end;


procedure sirnulate ( res, proc, nump )

begin

cond (( not & eof )

& ( eof )

)

begin

processline ( res, proc, nump )

end;

end;


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;


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;


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 )


)

begininitprocess ( processnurn, res, proc, nump )

end;

cond (( processnurn & 100 )

& ( processnurn & 100 )

)

beginskipblanks ( ch )

end;

cond (( processnum & 100 )


)

beginch = INPUT;

end;

cond (


I

I

( processnum & 100 )


)

begin

processnum = INPUT;

end;

begin

ch = INPUT;

end;

end;


local res;

local proc;

local nump;

\

begin

initsys ( res, proc, nump )

end;

beginsimulate ( res, proc, nump )

end;

null


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;


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;


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;


end;

displist ( res[TAPES].q );

res[TAPES].tai1 := nil;1

displist ( res[TAPES].t0arc );

res[TAPES|.toarctai1 := ni];

res[TAPES].avail := MAXTAPES;

end;

111111


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;


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


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


{

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


Appendix C. Sample Pascal Source Code I94

if (resind < TAPES)

then beginpr0c[pr0cind],res0urces[resind]producer := false;

res[resind].avai1 := 1000000;

end;

end;


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);


—

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;


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 );


flushsys( proc, rcs, nump );

end;

end;

cmd;


~

I

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;


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;


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;


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;


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


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;


ß

II

I

procedure skipblanks (var ch : char);

beginI

read ( ch );

while (ch = BLANK) do

read ( ch );

end;


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


_ 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;


procedure simulate (var res : restype; var proc 1 proctype;

nump : integer );

begin

while not eof do

processline ( res, proc, nump );

end;


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

l

end;l

Appendix C. Sample Pascal Source Code ZI4

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;


l

begininitsys ( res, proc, nump );

simulate ( res, proc, nump );

end.

Appendix C. Sample Pascal Source Code 2l6

Appendix D. Operating Systems Assignmentt

Appendix D. Operating Systems Assignment 217

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!)


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Ä


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


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


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

é

Appendix G. Software Engineering Assignment

Appendix G. Software Engineering Assignment 243

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


| 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


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:


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.


Ä, @2. xy H' /2/ - vtechworks.lib.vt.edu · Chapter 2. Overview of Metrics ... HIPO Diagrams A...

Documents

Transcript of Ä, @2. xy H' /2/ - vtechworks.lib.vt.edu · Chapter 2. Overview of Metrics ... HIPO Diagrams A...