A Visual Programming Language for Data Flow Systems

Rochester Institute of Technology

RIT Scholar Works

Theses

Thesis/Dissertation Collections

10-14-1988

A Visual Programming Language for Data Flow

Systems

Timothy J. Wilson

Follow this and additional works at:

http://scholarworks.rit.edu/theses

Recommended Citation

Rochester Institute of Technology

School of Computer Science and Technology

A Visual Programming Language for Data Flow

Systems

by

Timothy

J.

Wilson

A thesis submitted to

The Faculty of the School of Computer Science and Technology

in partial fulfillment of the requirements for the degree of

Master of Science in Computer Science.

Approved by:

Dr. Peter Lutz

10-18-88

Dr. Andrew Kitchen

10-18-88

Dr. Peter Anderson

10-18-88

Abstract

Theconceptof visual_programminglanguagesisdescribedand some_{necessary terms}

are defined. The value of visual languages ispresentedand anumber ofdifferent

visual languages are described. Various

issues,

such as userinterface

design,

are

discussed.

Asanexampleofavisual_programming

language,

a graphicaldata flow programming

environment is developed for the Macintosh workstation which functions as a

preprocessor to a data flow simulator developed at RIT. Examples are presented

demonstrating

the use ofthe language environment. Issues related to the devel opmentof_{the programming}environment aredescribed and conclusions_{regarding the}

developmentof visual_programminglanguagesingeneralare presented.

CR CategoriesandSubject Descriptors:

D.l.l

[Programming

Techniques]: Applicative(Functional)

Programming;

D.2.1 [Software Engineering]: Requirements/ Specifications

-Languages;

D.2.2 [Software Engineering]: ToolsandTechniques- Structured

Programming;

User

Interfaces;

D.2.6 [Software Engineering]:

Programming Environments;

D.3.2

[Programming

Languages]: LanguageClassifications- Data Flow

Languages;

1.3.6 [ComputerGraphics]:

Methodology

andTechniques- Interaction

Techniques;

Languages;

I.3.m [ComputerGraphics]:Miscellaneous.

General Terms: Data

Flow,

Graphical

Programming,

Visual

Languages,

Acknowledgments

I would like to acknowledge the _generosity of the Eastman Kodak

Company

for

funding

my Masters Degree program and _{my supervisors,} Mr. Jack

O'Grady,

Mr. John

Strickland,

Mr. Donald BarnesandMr. Stephen Hinman forsupportingmy

efforts.

Table

of

Contents

Chapter

1

-

Overview.

1

1.1 Introduction 1

1.2 Definitions. 1

1.3 The ValueofVisual Languages 3

Chapter

2

-

Issues in Visual

Programming

5

2.1 Introduction 5

2.2 TheApplicationofGraphics. 6

2.2.1 The UseofGraphicsvs.Text 6

2.2.2

Naming

andQualities 6

2.2.3 Animation 7

2.3 User InterfaceConsiderations. 7

2.4 The Problem DomainandtheCompletenessofDomainState

Presentation 8

2.5 OperationalConsiderations 8

2.6 SomeUseful

Programming

Paradigms 9

2.6.1 ControlFlow Programming. 9

2.6.2 Data Flow Programming. 10

2.7 A ReviewofSome

Existing

Visual LanguageSystems 11

2.7.1 PECAN 11

2.7.2 ThinkPad 12

2.7.3 OMEGA 13

2.7.4 GAL 13

2.7.5 PICT 14

2.7.6

Programming

by

Rehearsal. 14

2.7.7 PiP 15

2.7.8 FGLandGPL- Data Flow Languages 16

2.7.9 PROGRAPH 16

2.7.10

ThinkerToy

17

2.7.11 ARK 18

2.7.12 LabVIEW 20

2.8

Summary

21

Chapter

3

-

An Example

_of

Graph

Creation

_with

FlowGraph

23

3.1 Introduction 23

3.1.1 SomeBasics 23

3.1.2

Starting

FlowGraph 24

3.1.3 Definitions 26

3.1.7 ConstantNodes 31

3.1.8

Changing

NodesontheGraph 33

3.1.9

Adding

theRestoftheNodes 36

3.1.10

Adding

Nodes

Representing

Procedures. 38

3.1.11

Adding

Arcs 40

3.1.12

Editing

Arcs 45

3.1.13 TheMainProgram Graph 46

3.1.14

Setting

_{Trace Options 48}

3.1.15

Saving

aFlowGraphGraph File 48

3.1.16

Translating

theGraphsinto theSimulatorInput Files. 49

3.1.17

Printing

theGraphs 51

3.1.18

Running

theSimulator. 52

Chapter

4

-

Project Description

53

4.1 Introduction 53

4.2 Project Implementation 53

4.2.1 The User Interface DesignofFlowGraph 54

4.2.1.1 Menus 55

4.2.1.2 TheNode Palette 56

4.2.1.3 Graph Windows. 57

4.2.1.4 DialogsandAlerts 58

4.2.2 DataStructures 59

4.2.2.1 SignificantToolbox DataStructures 60

4.2.2.2 DataStructuresin FlowGraph 61

4.2.3 ProgramOrganization 66

4.2.3.1 The Event

Loop

.66

4.2.3.2 MouseEvents 67

4.2.3.3 Update Events 70

4.2.3.4 ActivateEvents 71

4.2.3.5 Keyboard Events 71

4.2.4 ProgramStructure 72

4.2.5 OtherIssues. 75

Chapter 5

-

Conclusions

77

5.1 Introduction 77

5.2 The

Viability

ofVisual

Programming

Languages 77 5.3 The UseofVisual Languages in Data Flow Programming. 78 5.4 Issues in the General DevelopmentofVisual Languages. 78

5.5 ImprovementsonFlowGraph 79

5.6 Final Conclusions 80

Appendix A

-

FlowGraph

Users

Manual

81

A.1 Introduction 81

A.2General Operation 81

A.2.1.ThePartsofFlowGraph 81

A.3 FlowGraphMenuCommands 82

A.3.1 The AppleMenu 83

A.3.2 The File Menu 84

A.3.3 The Edit Menu 86

A.3.4 TheProcedure Menu 88

A.3.5 The Preferences Menu 89

A.3.6 TheCompileMenu 91

A.3.7 TheWindowsMenu 92

A.4 TheNodePalette 92

A.4.1 A DescriptionofEach Node Type 93

A.5 The Graph Window 101

A.6 Mouse Operations 101

A. 7 ErrorMessages 102

Appendix

B

-

Data Flow Simulator Information

103

B.l Introduction 103

B.2 InstructionSetDesign 103

B.3 Simulator InstructionSet 105

B.4 Simulator Syntax

Summary

107

B.5 DetailedDescriptionoftheSimulator InstructionSet 109

B.5.1 MathOperators 109

B.5.2 Predicate Instructions. 110

B.5.3 BooleanInstructions Ill

B.5.4 BranchInstructions 112

B.5.5

Loop

Instructions 113

B.5.6 Procedure Instructions 114

B.5.7 I-structure Instructions 115

B.5.8 Output Instructions 115

B.5.9 CommentandConstantInstructions 116

B.6 Debugging. 116

B.7 Other Files Required

by

theSimulator 117

B.7.1 ProcessorConfigurationFile 118

B.7.2 InstructionSetConfiguration File 118

B.8

Running

theSimulator 120

B.9 Simulator Errors 120

Appendix

C

-

Data Flow

Graph Example

122

C.l Introduction 122

C.2 Background 122

C.3 Implementation 123

C.4 Conclusions 129

Table

of

Figures

Figure3.1- theFlowGraphProgram

andDocument Icona 23

Figure3.2- The FlowGraphScreen

24

Figure3.3- A Data FlowGraph

representing the Recursive Factorial

Algorithm 26

Figure3.4

-Creating

aNew Procedure Window 27

Figure3.5

-Setting

aProcedure's Name. 28

Figure3.6

-Placing

Primative OperationNodes from the Palette into the

GraphWindow 29

Figure3.7

-Some Primative Operation Nodesin the GraphWindow 29

Figure3.8

-"Mini-Palette"

for

Selecting

Conditional Nodes 30

Figure3.9- Grid

Dialog

Box 31

Figure 3.10

-Setting

thevalue ofaConstantNode 32

Figure 3.11- Various Displays

ofaConstantNode 32

Figure3.12

-Adding

aConstant 33

Figure3.13 34

Figure3.14-_{ASelectedNode isdisplayedwith aGrayed}"Body"

34

Figure 3.15- The"ChangeNode

Type..."

fromtheEdit Menuallows_changing

SelectedNodetoanother"Equivalent"Type 35

Figure3.16-_{TheMini-Palette}

displaying

the"Equivalent"

Types 35

Figure 3.17- The Graph_aftertheChange

36

Figure 3.18- Node Layout for

theFactorialGraph 37

Figure 3.19- Comparison_ofVirtualGraph

Space,

Allocated GraphSpaceand

the GraphWindow 38

Figure3.20

-Selecting

aProcedure Name tobe Addedto theGraphwiththe

Apply

Palette Operator 39

Figure3.21- An Inactive

Apply

OperatorandanActive

Apply

Operator 39 Figure 3.22- AProcedure Node

40

Figure 3.23- A "Rubber

Band"

Arc 41

Figure 3.24- A

Final,

Connected Arc 41

Figure3.25- Connected Factorial Graph 42

Figure3.26- The Standard WindowSizeExposes the Palette 44

Figure3.27- The Window Zoomed to FullSizeCovers the Palette

.44

Figure 3.28- The_arcbetween the

"True"

output portoftheSwitch Node

shouldnot goto the Multiplicationnode 45

Figure3.29- Select AnArc

By Clicking

ontheInput Port it isConnectedto 45 Figure3.30- Delete_aSelected Arc(or

Node)

by

usingthe Clearmenuitem 46

Figure3.31-_TheMain Program Graph 47

Figure3.33- The Standard OutputFile

Dialog

for the

Saving

the Graph 49

Figure3.34- The

Assembly

Langauge File 50

Figure3.35- Output File

for Simulator Data Input 51

Figure3.36- The Page

Setup

Dialog

- Use TallAdjustedfor_allFlowGraph

graphs 51

Figure3.37- The Print

Dialog

- Faster

Quality

is

Usually

Sufficient 52

Figure4.1 - Parts_of

theFlowGraph

Display

55

Figure4.2- The Menusin FlowGraph

56

Figure4.3- The Node Palette

57 Figure 4.4- Parts_oftheGraph Window

58 Figure 4.5- A Typical FlowGraph

Dialog

Box 59

Figure4.6- FlowGraph DataStructure Inter-Relationships 62 FigureCl- Graph_ofthe Trapezoidal Rule Example

124

Figure C2- Data Flow Graph_of

the TrapezoidalRule Made

by

FlowGraph

-Main Program 125

FigureC3- Data Flow Graph_oftheTrapezoidal Rule Made

by

FlowGraph

-Subprogramfor

Calculating

x2 126

Figure C3- FlowGraphOutputFile for Simulator 128

Figure C4- Test Data File for Simulator. 129

Chapter

1

Overview

1.1

Introduction

Ascomputer workstationshave becomemorepowerful and more_{widely available,} as

well as _{less expensive,} there has been a proliferation ofapplicationsthatallow the endusermore"programmability"in theapplication. Ratherthan

developing

specific

applications through the use of expensive resources such as professional

programmers,powerful applications allowthe specification of a probleminadomain understood

by

theuser.

Conventional programming techniques involvespecifying theproblem anditsmethod

of solution asacollection ofprimitiveoperationsappliedin a_sequential,linear fash

ion. The translationoftheproblemdomain tothecomputer'sexecution domain has

beentherole oftheprogrammer.

Toprovide aprogrammable environmentthat is_easilyunderstood

by

the user, many

techniqueshave beendeveloped to provide amethod of_{presenting the} problemand its method of solution to the computer system (i.e. programming). One class of

methodsisvisualprogramming.

1.2 Definitions

For thepurposes ofthis_thesis,visual _programmingisdefinedas theapplicationofa

systemor environmentthat allowsthatuser_{to specify} aprogram in a multidimen

sional

fashion,

utilizingaspatial arraignment of programprimitives and constructs

textual

languages

isa _{one-dimensional, linear}processthatmimicstheclassical se

quentialexecution modelofcomputers.

Anumber of other termsare relatedto (orconfusedwith)visualprogramming. The terms graphical language andgraphical _programming are used to designate lan

guages orparadigmsthat usegraphicsto asignificantdegree. Allofthe languages

discussedin this thesisare examplesof graphicallanguages.

Programvisualizationis theuse of graphicaltechniquestoillustrate somefeaturesof

a computer programor systembutnotitsspecification.

They

areappliedafter a pro

gram has been specified or in conjunction with _{the programming} specification.

Programvisualizationtechniquescanbepresentedin a

taxonomy

thatisdivided into

code representation versusdatarepresentationand staticillustrationversusdynamic

illustration. [Myers 1986] Staticillustrationpresents a"snapshot"of some aspect of theexecution environmentwhiledynamicillustrationprovides a real-timeanimation oftheexecutionenvironment.

Anothertermusedinconjunctionwith visual _{programming is}

Programming

bvEx

ample. Some systems ofthis typerequire that theuser demonstrate an algorithm

through anumber of examples and thenthe systeminfersa general program struc ture. ThishasbeenanareaofArtificial Intelligenceresearch. Othersystemsrequire theuserto completely specify the approach without _{any inference}onthepartofthe

system,althoughtheusersupplies a_specifyexample. Thisapproachhas beencalled

as

Programming

with Examples.

Programming

with Examplescanbe describedas

"DoWhat I Did"

while the inferential

Programming by

Example systems should"Do

What I Mean". As with program visualization _systems, graphical techniques are

sometimes utilizedin

Programming

by

Examplesystemsbut

they

are notintrinsicto

thespecification oftheprogramasis thecasewith visualprogramming.

keyboard

_{entry in}responsetoaspecific prompt or

they

_maybemore_complex,suchas

pickingon objectfromapalettedisplayedinone window ofanoutputdevice_usinga

mouseand then"placing"theobjectinanother windowor area. The userinterface

design encompasses the application ofinput / output

(I/O)

devices such as _mice,

tactileresponse

devices,

light_pens,graphicstabletsandbit-mappedgraphics screens as well as _many different methods of_{information presentation,} such as _scrolling windows,menus,palettes and

dialog

boxes.

In the design of _{any programming}

language,

_{it is the} application of a specific

grammartoa setofsymbolsthatdefinesthelanguage anditsproblemdomain.

Avisuallanguage has itsgrammardefined

by

the spatial orientationofthe graphic

elementsthat form thelanguagesymbols. Auserinterfacedefinesthe setofopera

tionson thesymbolsfortheirmanipulation and management. Inthedevelopmentof avisual

language,

the languageimplementor isnowfacedwiththe the definitionof allthree elements

(grammar,

_symbols,and

interface),

ratherthanjust thegrammar and symbolsof aconventionaltextuallanguage.

1.3 The Value

of

Visual Languages

Thisthesisreviews theissues in thedevelopmentandimplementationof visualpro

gramminglanguages. Thebasic issues oftextversus graphics are discussedin the context of_programminglanguages and the power of visual language systems are shown. Important considerations in visual languages are shown to be the user

interface,

therepresentationoftheproblem

domain,

andtheoperationalfeaturesand

characteristics oftheprogrammingsystem.

Programming

paradigmsare also describedwithrespecttovisual_{programming lan}

guages. Theseparadigmsinclude classicalcontrolflow programmingand data flow

programming. The advantages ofthe data flow paradigmfor visual_programming

Forabackgroundinthedevelopmentof visual_programming

languages,

anumber of

different

systems are described.

They

are presented in an order thatroughly rep

resents theimportantdevelopments of visual _programminglanguages andsystems.

Somerelevantissuesarediscussed withrespectto eachlanguage. It is shownthat

visual _programming languages started as a method to visualize control flow

programmingandthen evolvedinto systemsthatmove to specific problemdomains

that takeadvantage ofthe users

familiarity

withthe abstract objectsoftheproblem

domain.

Thevisual_programminglanguage developed forthis

thesis,

FlowGraph,

isthenpre

sented through the developmentofa simple example program. The specific issues

thatwereencounteredin thedevelopmentofFlowGrapharethendescribed.

Basedonthe background discussionandtheissuesencounteredin the development

Chapter

2

Issues in

Visual

Programming

2.1

Introduction

With the advent of

fast,

_{inexpensive bit-mapped} graphics workstations and the in crease in so-called "non-technical" computer _users, research _{is proceeding in} the development of systemsthatpresent a computersystem paradigm which iseasierfor

the enduser to understand and control. Much ofthis work is in the field ofUser Interface Management

Systems,

which are _usually used to enhance _{the operating} system software. These systemsuse graphical representationsof objectsto present

themachine stateinformationorprovidetools forapplicationstogenerate consistent,

easy-to-use user interfaces. As the user interface research matures and the

workstationsbecomemoreavailable, theresearchis_{moving toward}applicationsthat providepowerfulmethodsforthe userto utilizethe computerto solve problemsina

fashionmore_closelyrelatedto theproblemdomain.

This section describes approaches used to

develop

computer _programming envi

ronments_usinggraphical objectstorepresentthe abstract entitiesthatare manipu

latedinacomputerprogram. Therange ofapproachesto thisproblemis

fairly broad,

with the utilization of graphics

being

used in different degrees and for different reasons.

[Halbert1984] hasshownthatnon-programmers can create

fairly

complexprograms

with visual languages. Visual languagesprovidethe tools to express aproblem in

2J.,,,TheJ^plicaiiQn^

Historically,

visual_programming languages canbe tracedback _{to two early devel} opments:SKETCHPAD [Sutherland

1963],

an _earlyinteractivegraphicsworkstation

developedatMITand a projecton

drawing

flowcharts_usingacomputer[Knuth1963] to assistinprogramdevelopment. Bothofthese types ofsystems representthetwo

early developments that have paved the _way for modern graphical _programming

languages,

with SKETCHPAD _{providing the} interactive graphics and the Knuth system _usingthe computerto

develop

some graphical outputfor_providingprogram

visualization.

2,2.1

The

Use

of

Graphics

vs.

Text

The stress on graphics versus text is derived from the manner in which humans

assimilateinformation. Ithasbeen shownthatinformationrepresentedinpictures

canbe more _rapidly and _completelyunderstood. The human eye _rapidly scans an

entire scenebefore it focuses onthe area ofinterest. Asthe brainattemptstopick

out those areas ofthe scene which are

important,

the whole scene is _repeatedly

rescanned andthe

key

pointsofinterestare registered. When thisprocessis applied to

text,

the brain tends to scan for

illustrations,

headings andhighlights before it

beginstheprocess of_rigorously

following

the linear flowofthetext.

By

_allowingthe

eye/brainsystemto functionon graphical

data,

the brainspreferredpattern of scene

scanningcanbeusedtogatherandassimilatethe informationquite rapidly.

2.2.2

Naming

and

Qualities

Another attribute of graphical informationis its abilityto portray information and

2.2.3

Animation

Graphical programs and representations can also be used to present an execution

modelthrough theuseofanimation. Animationtechniquescanbeusedtoshowmuch

oftheinformationabouttheprogram's execution state(s).

2.3,

Interface

Considerations

One of the major concerns in software development is programmer productivity.

Many

people are _{studying the} methods

by

which user and programmer_productivity

canbe increased. The designanddevelopmentof userinterface systemshasthegoal

of_providinga more complete pictureofthecurrent state of a_computingsystemto the

user,beyondthatwhichisprovided

by

_manycurrent_{operatingsystems,} such asthe

classic

fromtheUNLXc-shell_operatingsystem.

Therehas beenalargenumber ofstudiesontheappropriatedesignof userinterfaces

for computing. Theserangefrom theergonomicsof computerhardwaredesignto the

appearance andinteractiveapproaches of system software. Themajor consideration

is thatuserinteraction techniques mustbe designedto supportthree types ofbasic

humanprocesses: cognition,perceptionandmotoractivity.Acomprehensive_studyin

this area is provided

by

[Foley,

Wallace and Chan 1984] and

[Foley

and Wallace

1974].

These considerationsare alsoimportant in the areaof programmersupport. Thatis

the fundamentalreasonbehindgraphical_programmingandvisuallanguagesystems.

Some ofthe systems describedabove were developed_solelytoincreaseprogrammer

program(see_{especially the PECAN}system[Reiss 1984b]). Othersattempttoprovide

a better fundamental model for _{programming, using} a model with an interactive

visual representation(i.e. PROGRAPH [MatwinandPietrzkowski

1985],

PiP [Raeder

1985 and Raeder

1984],

Programming by

Rehearsal [Finzer and Gould

1984]),

ThinkerToy

[Gutfreund 1987]andARK [Smith 1986]. Thegoal of_providinga_visual,

graphical environment that betterrepresents the problem domain or model to the

userisa commongoalofthesesystems andofthesystemthatwasdevelopedforthis

thesis. (Additionalreferencestouserinterfacedesignconsiderations areincluded in

the

Bibliography

andthe Further

Reading

section).

2.4

The

Problem Domain

andthe:..

Completeness

of

Domain

State Presentation

Visuallanguagesprovide a methodof_presentingalargeamountofinformationat one

time.

By

keying

graphicsto the users problem

domain,

information ismorerapidly

communicatedtotheuser.

Tying

thegraphicstotheproblemdomain isbothabenefit

and a limitation invisuallanguages. The benefit is the amount ofinformationthat

can bepresented to the user. The user is expected tounderstand thisinformation

because ofthe users knowledge ofthe properties ofthe objects that the graphics

represent. The limitation is that if the userdoesnothaveaknowledgeoftheobjects

represented in the program, the information presented is not as useful. The

concentration ontheproblem_{domain may}alsolimitthe applicabilityofthe language.

A tradeoffin visual languages is the level of_complexity ofthe properties that the

objects in the language represent. As the problem domain of the language is

narrowed,theamount of_propertyinformationthatan object can_conveycanincrease.

The programeditor

(

graphicortext

)

issyntax-directedtoeliminate syntax errors

in thecode whileitis

being

entered;

Theusermanipulatesthegraphics whiletheprogramis

being

createdoredited and

then thesystemanimatesthegraphics

during

execution. Thisshouldleadtoabetter

understanding

by

theprogrammerof_{his algorithm;}

In_manycasestheprograms are

incrementally

compiledorinterpretedsothat

they

couldbe executed at_{any time in the}development[Reiss

1984a,

Schwartz,

Delisleand

Begwani 1984].

Many

systems allowed the execution of unfinished orincomplete

programs, so that

debugging

the algorithm could begin before the program was

complete.

Allofthesepoints are aimed atthegoal of_{making the} systemresponsiveto theuser

and_{giving the} userthe maximum

flexibility

in the approaches _{to solving his} prob

lems.

2.6

Some

Useful.Programming

Paradigms

It is important to

briefly

discuss some ofthe differentprogrammingparadigms that

are

being

studied. Control flow programming and data flow programming are

discussed below. It is importantto note which _programming paradigms are more

applicabletovisuallanguagessystems.

2.6.1 Control Flow

Programming

Control flow systems represent the conventional computer processors of today.

Control flow programs are stored and executed in a sequential manner. No in

struction can execute until all previousinstructions haveexecuted.Regardlessofthe

The principles behind todays computers_generally reflectthose ideas developed

by

vonNeuman. Von Neuman systems are sequentialin_nature, with separatecentral

processingunitsand memory. Thesecomponents are connected

by

a singlechannel, in which _only one word or address _maypass at one time. This system provides a

seriouslimitto theexpansion of_computingpower[Backus 1978].

Programming

languages have been developed around these machine architecture

concepts and so providelittle

help

in theadvancementof_computingcapability.

2,6.2

Data

Flow

Programming

Inresponseto this

dilemma,

anumber ofdifferentcomputerarchitectureshave been

proposed. Onearea of_research,pioneered

by

Jack DennisatMIT [Dennis

1975],

is the development ofdata flow systems. These data flow

(

or data driven

)

systems

provide an architecture that supports parallel _processing quite naturally. It also

eliminatessequential_processing,

by

_allowinganyoperationsto occur whenevertheir

required operands are available. Theseoperandsare passed as

tokens,

ratherthan

being

maintainedinstatic_memory

locations,

sothe processor/_memory

"bottleneck"

iseliminated[Backus 1978].

Asan example ofthe difference between data flow andcontrol flow programs, con

siderthe

following

sequence of

instructions,

as representedinacontrolflowsystem:

P = _{X + Y}

Q

= _P

/

_Y

R = _X * _P

S = _R

-Q

T = _R * _P

RESULT = S/T

In parallel_processing data flow systems, these instructions canbeprocessed more

P = _{X + Y}

Q

= _{P/Y & R} = _X * _P

S=R-Q

& T = _R*P

RESULT - _S/T

Theparallel natureofthealgorithmisutilized

by

thedata flowsystem.

The principles are

being

applied in hardware througha numberofdifferentmulti

processor,data flowcomputer_{designs. Some}ofthemajor systemsinclude the M.I.T. Data Flow

Computer,

theManchester Data Flow

Computer,

the Irvine Data Flow

Machine,

the Texas InstrumentsDistributed Data

Processor,

the Utah Data-Driven

Machine,

the LAU system andthe Newcastle Data-Control Flow Computer. These

dataflowarchitectures aredescribedinmoredetail in

[Treleaven,

Brownbridge and Hopkins

1982],

[Torsone

1985],

[Lawson 1986]and [Benjamin 1988].

Data flow languagesprovidethe tools to

directly

supportthesesystemarchitectures. The most naturalrepresentationis thatofthe directedgraph. Thismakesdata flow

languages attractive to implement with visual _{programming systems,} such as the

systemdeveloped here.

2.7

A Review

of

Some

Existing

Language

Systems

Differentvisuallanguage systemshavebereviewedto

identify

thecriticalissuesand

insights that

they

provide.

They

represent a cross section of implementation

techniques,

from the utilization of some visual or graphicaltechniquesto languages

thatare

highly

visualtosupporttheirproblemdomain.

2.7.1 PECAN

The PECAN system [Reiss

1984a,

1984b] essentially provides different views ofa

program

being

developedinaconventional,controlflowstyle. Theseviewsinclude a

view oftheprogramdeclarations. Theseprovide viewsoftheprogram syntax. Views ofthe symbol table

being

_{generated, the} program's defined data

types,

expression trees andflowofcontrol charts provide semantic viewsoftheprogram. The PECAN

systemdevelopersare

integrating

a systemofexecution viewsbasedontheirBALSA algorithmanimation system

[Brown,

Meyrowitz andvan Dam 1983]. Thisprogram visualization system wasdevelopedatBrownUniversity.

PECAN is utilizes the techniques described above to support conventional pro

gramming techniques. Its use ofmultipleviews ofcode and

data,

syntax directed

editingandincrementalcompilation arethehighlightsofthe system.

However,

it is not abletoutilize more advanced graphicalor visualtechniquesbecauseit isso

heavy

tied to conventional,controlflow_programminglanguages.

2.7.2

ThinkPad

The Think Pad system

[Rubin,

Collin andReiss 1985] uses a

programming-by-ex-ample system which allows the user to create graphical representations of data structures. Thesegraphicaldatastructure representations canthenbecombinedto form

functions,

which are then combined to form programs. Although the user is

manipulating graphics, he must also provide some textual information about the graphic object. As the programmer manipulates the various data structures that

were_{created, the}functionsemantics aredefined. Aseach objectis_created,ThinkPad

creates a

Prolog

program. This is the finaloutput oftheThink Padsystem. Current work

being

done includes the _{inverse mapping} of

Prolog

programs to Think Pad graphics representations. This would also allow the trace function in

Prolog

to provideinput foraformof algorithm animationin Think Pad. Itwasalso developed atBrown University.

structures. The graphicalinterface _merelyprovidesabetter userinterface forma nipulating the text thatrepresentsthedatastructures.

2,7.3

OMEGA

TheOMEGA System at

Berkeley

[Powelland Linton 1984] isa systemthat allows usersto manipulate graphical objects and structures.

They

useicons torepresent a abstract_programming concept (such as _sorting a

database, defining

a _variable, a variable

itself,

acontrol_structure,adatatype). Thegraphical_{icons simply}represent objectswhose complete specification isstillgiveninatextualform. OMEGAallows manipulation ofthe defined

icons,

but at alower

level,

itstill requires textfor the

detailedspecificationsoftheprogram which makesitusefulforprogram visualization ratherthanvisualprogramming.

OMEGA actually is iconic innature,with abstract representations of objectsthatcan

be picked

by

the user in a syntax-freemanner.

However,

OMEGA is still

heavily

dependant on text andessentially uses the icons to represent complex objects. It mixestextandicons inamanner suchthat theiconsbecome"words"

thatextendthe

vocabularyofthelanguage. Once again, thegraphics areusedto enhance the user interfaceof a_{textual system,}ratherthanavisualsystem.

2,7.4 GAL

The GALsystem[Albizuri- Romero

1984a,

1984b]wasdevelopedatthe

University

of Sussexanduses graphicsinamanner similarto

PECAN,

althoughnot as_extensively

as PECAN.

Basically,

it provides a method to imbed textual code into Nassi-Shneidermancharts. This isreallynotvisual _programmingbutadvanced graphical

2.7.5 PICT

ThePICTsystemisa graphical approachto traditionalvonNeuman languages. The

PICTsystemwas _developedasavisuallanguageatthe

University

ofWashington in

Seattle,

WA. [Glinert and Tanimoto 1984]. The PICT system uses no textin the

development ofprograms. The program's flow of control and its data are

totally

represented

by

graphical objects. The user interacts with the system through a

joystickwhich controls a cursor on a color graphics CRT. Theusercreates colored

icons that represent _{operations, data} structures and variables.

Directed,

colored

paths representcontrolstructureswhichdirecttheprogramflow. Theuser'sactions

are managed

by

a syntax-directed _editor,which eliminates syntacticinconsistencies

during

program developmentand editing. Atrun

time,

theprogram's graphics are

animatedto showits_operation,whichgivesit_{the ability to} support program visual

ization. Thus the program is representedboth in development andexecution

by

a

consistent graphical structuretotheuser.

The PICTsystemisusefulfor

doing

some simple computer programming.

However,

it has some drawbacks. Eachmodule (program or subprogram) hasavailable _only

fourvariables (represented

by

four colors: red, green, blue and orange) which are

restrictedin type to

being

six-digit,non-negativeintegers. Thesystemalsohasonly

16 primitive _operations, of which two are for system _control, five are boolean

operations and_{the remaining}nine are primitiveoperations on variables.

2.7.6

Programming

by

Rehearsal

Programming

by

Rehearsal [Finzerand Gould 1984] was developed to aid

nonpro-grammersin creatingeducational software. Thissystemdefinesatheatermetaphor

whereadirectorcan audition performers with variousattributes,place required per

attributes into

"troupes",

i.e. basic data types

(text,

integers)

are the

BasicTroupe,

pictures are the

GraphicsTroupe,

clockformsarethe

TimeTroupe,

etc. The director

uses a mousetomove the performersto the appropriate positionson the stage orin

the _wings,where

they

arehiddenfrom theprograms end user. The director defines

the interaction ofthe performers

by

_{the way} that

they

respondto cuesfrom other

performers,

on-and off-stage. _{In this system, textual}commands define boththeac

tions andinteractionsofthevarious objectswhiletheirgraphicalrepresentation can

be manipulated to provide the appropriate "view" of the _objects, that

is,

their

presentationto the user.

Programming By

_Rehearsalwasdeveloped atthe Xerox

-PaloAltoResearchCenter (PARC).

Theuse ofthe theatermetaphor andthe objectoriented,message _passingnatureof

theprogramarethe

key

elementsof

Programming by

Rehearsal.

2.7.7 PiP

An importantvisual _programming language is the

Programming

in Pictures

(PiP)

system, developed at the

University

ofSouthern California in 1984 [Raeder

1984,

Raeder 1985]. In this system,pictures areusedtorepresenttheoperations oninput

data. Theusercreatesthesepicturesinafreehandmannerthat thenrepresent the

operations. Thedatapictures arethencombined

by

_pointingatthemand_{then using}

operators to combinetheminto functions. Control structures are available to com

bine small functions into larger ones. The system also uses Backus's functional

programmingmodel.

Becausethe PiPsystem allows users to createtheirown _{pictures, the}graphics _may

moreadequatelyrepresenttotheuserhisproblemdomain.

However,

themetaphors

suggested

by

the pictures can be misleading, since the level of completeness of

2,.?.,.S..FGL

_and

GPL^Data-FlQW

Languages

Two graphical_{programminglanguages} that were designed inconjunction the Uni

versity ofUtah data flowmachine _{project, DDM}

1,

are FGL (Function Graph Lan

guage)[Keller andYen 1981] and GPL (Graphical

Programming

Language)

[Davis

andLowder 1981]. Thesesystems aretwo approachesto the developmentofavisual

programming language are based on the data flow model. Each system takes a

slightlydifferentapproachto thedata flowimplementation [DavisandKeller 1982].

FGLandGPLaregraphicallanguages_verysimilarto thesystemproposedhere. The

papersdon'tpresent sufficientinformationaboutthe programmingenvironment and

implementation to contrast it with this system. Both allow the creation and

manipulation of adata flowgraph asthe _primarymeans of programming. (Seealso

[Maguire 1983]).

2.7.9

PROGRAPH

Oneofthemost

interesting

visualprogramminglanguages is

PROGRAPH,

developed

atthe

University

ofOttawa [Matwin andPietrzkowski 1985]. The language model

for PROGRAPH isacombinationofanumberoffunctional programming

languages;

namely, LISP

[McCarthy

1965],

APL [Iverson

1962],

FP [Backus

1978],

and GPL (GPL isdescribedabove).

PROGRAPHcontains_manyimportant features:

It isessentiallyfunctional innature.

Itoperates ondataof_arbitrarycomplexity.

Itdoesnotrequirethe declarationof variables.

Itprovidesadatabasestructurethatiscompatible with PROLOG.

Thegraphicalrepresentationisalsothebasisof runtimeanimationforprogram

visualization.

With respectto itsgraphical_{programmingaspects,} PROGRAPHallowsthe userto

manipulateasetofprimitive operationsthatare assembledintoadefinition. Eachof theuser's definitions can then bemanipulatedjustlike aprimitive operation, tobe combinedinto furtherdefinitions.

PROGRAPH's importance stems not_{only from its} use ofa graphical _programming

and execution environment, but also from its ability to support and encourage

parallelism,itslistmanipulationfacilities(similarto

LISP)

and_{its ability to interact}

withPROLOGandPROLOGdatabases. These featuresall combinetomakeitone of themost_powerful,state-of-the-artsystems. Intermsof visualprogramming,much of thegraphicalelementsrelyontext to

identify

the functionandthe control structures rather _{than utilizing} some unique graphic portrayal of these characteristics.

However,

this is appropriate since the problem domain ofPROGRAPH is general

programming and the terms and text identifiers are appropriate for the targeted users,who wouldbefamiliarwith_general,controlflow-styleprogramming.

2.7.10

ThinkerToy

ThinkerToy

is a visuallanguage environmentdeveloped atthe

University

ofMas sachusetts at Amherst thatwas developed for modelingdecision support systems [Gutfreund 1987]. Decisionsupportsystemsarethoseputinplace toanalyze

semi-structured decision tasks such asbond

trading,

setting

budgets,

capital acquisition analysisandtimestudy.

ThinkerToy

isan object-oriented systemthatsuppliesanumber ofdifferent

"toolkits"

withdifferentdimensionalcharacteristics:

Id:

Array

Operations

_{for manipulating}tabulardata.

2d:Chart Operationsforcurve

fitting

andextraction nets.

3d:Terrain

Map

Operationsfor managingterrainmaps andthematicmaps.

These operations are applied through the use ofPanelswhich allow access to the

various primitivefunctions. The panels are manipulatedwith a mouse to

directly

apply the tools to data.

ThinkerToy

actually supportstwo types oftoolapplication:

directvisualanalysis and scripting. Anexampleofdirectvisualanalysisistheaction

of_placinga rulertoolover a_mapor acurvefittertooloveradatachart.

Scripting

is

a collection ofgenerictool

handling instructions,

thatcorrespond to complex mouse

operationsonatoolorset oftools.

ThinkerToy

seems quite similar to

Programming By Rehearsal,

with a Panel in

ThinkerToy

being

equivalent to a Troupe in

Programming

By

Rehearsal. This

demonstratesone ofthe attributesof visual

languages,

whichistheirfocus ona spe

cificproblemdomain.

2.7.11 ARK

The Alternate

Reality

Kit

(ARK)

was developed at the Xerox Palo Alto Research

Center

(PARC)

by

Randell Smith [Smith 1986]. ARK is an animated simulation

environmentthatwasdesigned toenablethedevelopmentofintuitive_{understanding}

of abstract physicallaws.

ARKisanobject oriented systemimplemented inSmallTalk-80. Itconsistsof seven

major objects which arethe fundamental tools and

building

blocksofthe language.

Buttonsthatare moved and placed

by

thehadover objectsthat

they

can then send

messagesto. The buttonsnamedescribesthemessageitsends.

The warehouseis thestore of all oftheprototype objects availableto analternate

reality.

They

are extractedfromthewarehouseforuse.

Representatives are objects that

display

a picture or some text

describing

the SmallTalkobject

they

representin thealternate reality.

Message Boxes allowthe developmentof userdefinedmessages which canbe sent

toobjectsthataredefinedtorespondto theparticularmessage. Messageboxes em

ploy visual "plugs" _{to specify the} message receiverand the message arguments (if any). To eliminate syntax _errors, plugs willnot"stick" _{to any} objectthatdoes not recognizeorrespondto the typeofmessage

being

sent. Message

boxes,

oncedefined

by

the_user,canbechangedtobuttonsforrepeateduse.

"Sliderswitches"

area graphicalmethodof_specifyingnumeric valuesto theobjects

thatrequire numbers.

Interactorsarethefundamental methodof

defining

an_{on-going "physical}

process"

thatoccursin theAlternateReality. Anexampleofthisisa_gravity

interactor,

which is_{constantly effecting the}forces on otherobjectsintheAlternate

Reality

thathavea defined property ofMass.

Any

number ofinteractors can be be specified in an Alternate

Reality

and thenthe properties that

they

represent are availablefor in

spection and manipulation. Thehandcanbeusedto_pickup and"throw" _objects,for example, to study theeffects oftheirdirectmanipulation. Thepropertiesdefined

by

theinteractors in the Alternate

Reality

canbe adjustedto see how theseproperties effecttheobjectsthatcanbemanipulated

by

the hand.

ARKuses graphicalimages andthe ability tomanipulate themin atangible_{way to}

2.7.12 LabVIEW

LabVIEWisacommercialsoftware packagedesignedtosupportdataacquisition and data_processingontheMacintosh

[Kodosky

andDye 1987]. Itcombines_manyofthe features of visual _programming with data flow _programming to provide an

environmentdescribedas avirtualinstrument.

LabVIEWhasbeendesigned tohandle the tasksofdataacquisitioninstrumentcon

trol,

data acquisition, and data processing. It uses a data flow-like paradigm of

wiringa_{circuit, providing}graphical componentsthatrepresent

logical,

mathemati

cal, statistical, stringandI/O functions. Theseare assembledin an"Diagram"win

dowthatrepresents a singlefunctionoroperation. The I/Ofunctionsprovidecontrol

ofinstrumentsthatare connectedtotheMacintoshviaaGPIB bus. Otheravailable

functionsprovide data flow extensionsthatprovide intuitivemethodsfor _specifying

conditional_operations,iterative operations and

"apply

toall"

procedures.

Once functions havebeen

defined,

the"Panel"windowcarriesthethemetaphorofthe

virtual instrument

by

_placing graphic switches,

knobs,

and meters which can

representone source ofI/O to thefunctions. Oncesimplevirtualinstruments have been

defined, they

canbe _readily combinedtocreate morecomplex data_processing

systems.

LabVIEW demonstrates themajor contribution of visuallanguages. It is intuitiveto

personnelthatareused to_workingwithinstrumentsanditmatches well with their

problemdomain. Itprovidesa"rear

view"

of an

instrument,

complete withitswired

interiorcircuits and a"front

view"

M^Sjjmmary

The major problems to be solved at this stage in the development of visual pro

gramming languages have to deal with the development of the appropriate

paradigms. Pure visual_programmingsystems seem toindicate thatstandard pro

gramminglanguage paradigms

(

i.e.

imperative,

procedural languages

)

cannotbe

transformed intogoodvisuallanguages. Becausetheuserinteractstoahigh degree

in the designand specification ofthegraphical_objects,declarativeor object-oriented

approaches _may be better suited to visual languages. The PICT system seems to

sufferbecauseit tries toholdtoaprocedurallanguageapproach.

Graphical programminglanguagetechniqueshaveevolvedintwodifferent branches.

One

branch,

that of_{the programming} visualization _systems, exemplified

by

the

PECANsystemandtheOMEGAsystem,will

develop

systems with_many

"views"

of a

program

(

some graphical and some textual

)

so that the appropriate information aboutthe program's performance willbe available to the _{programmer, along} with

systems that

help

enforce rules of good structuring, high reliability and good

maintainability.

Theotherbranchwillbethatof"pure"visualprogramming environments,wherethe

programmer will manipulate graphical objects. One ofthedifficultiestobeovercome

is the contextof graphical _objects, thefactthat

they

conveyinformation abstractly

(

through theirappearance

)

and_maybe misunderstood or misinterpreted. The need

existsto

develop

a symbol system or rulesandconstraintsfor

designing

symbolsthat

are clearandunambiguous. Also themanagement ofthe graphical databasesthat

are generatedwillhavetobeoptimized.

Visual programminglanguages can provide programmingsystems thatwill solve a

wide range of problems.

They

will allow programsto bewritten

by

personswith an

understanding ofthe problem's domain

by

allowing symbols to be developed that

represent_exactlytheproblem ratherthanfirst

having

toredefinetheproblem witha

Chapter

3

An

Example

of

Graph Creation

With FlowGraph

3,1

Introduction

This chapter gives a demonstration ofFlowGraph as it used to create a data flow

program ofthe classicalfactorialalgorithm. Itdemonstrates_manyofthefeaturesof

FlowGraphand_manyofthe techniquesusedtocreatedata flowgraphs and programs

thatwillexecuteonthe data flowsimulator atRIT [Benjamin 1988].

3.1.1

Some Basics

FlowGraph operates on aMacintosh computer as a preprocessorfor the data flow

simulator atRIT. Itspurposeistoallowtheusertodrawadataflowgraphina_very

intuitive mannerandthen translatethe graphinto atextual _assemblylanguagefor

processingwiththedataflowsimulator.

FlowGraphoperatesthroughthe frameworkof_many ofthe standarduserinterface

paradigms ofthe Macintosh [Rose 1985]. The terms used in thischapter arethose

foundinthe standardMacintoshvernacular. For theuser unfamiliar with theMac

intosh,

theprincipletermsaredefinedin the Glossary. [image:32.540.184.357.539.614.2]

FlowGraph Fact-Test

Figure 3.1 - _theFlowGraph Program

3.,.L2

Starting,

Flowgraph

FlowGraphcanbe launched

by

_{selecting its icon}(Figure3.₁₎in the Macintosh Finder

and _selecting Open from the File menu.

Alternately,

double _clicking on the [image:33.540.74.468.213.481.2]

FlowGraph iconwilllaunch theprogram. TheFlowGraph screen

display

isshownin

Figure 3.2.

File Edit Procedure Preferences Compile Windows Untitled - _Main

a

<E)

o

_____

Y

^

|flND/C>:|

^

#*

f>

f

LOOM CONTtOl

LOOP DOTH "T~

;:;:::|:!i:i|:-:; iiiiiiiiiiiiii

'

"tfflff^

BID

INPUT "T"

OUTPUTI DEBUG _!f_j

Figure3.2-TheFlowGraph Screen

The FlowGraphscreen

display

consists offourmajor objects:themenubaratthe

top

ofthescreen,agraph_window,a nodepaletteandthecursor. Themenusinthemenu barperformfunctions of global nature such asopening

files,

translatinggraphsinto

textual simulatorcommands,and_settinguser preferences. Agraph windowiswhere

It is the first window listed in the window menu. The graphs in the remaining

windowsrepresentprocedures.

Asademonstration of

FlowGraph,

agraph program_representingthe calculation of a

factorialwillbe drawn. Therecursivealgorithmforafactorial is:

mainline

input

(n)

factorial

(n)

output ("factorial =

",n)

end mainline

factorial

(n)

if (n =

1)

_then

return

(n)

else

return (n * _{factorial (n}

-1))

end if

end factorial

FileInput

Procedure

Call Factorial

r

[File

Output]

FileOutput

Mainline

Procedure Input _{f 1}

.0 ]Constant

/Compare forEquality 1.0 1 Constant

Procedure Call

[image:35.540.85.457.64.378.2]

Multiplication

Figure 3.3- A DataFlow

Graph representingtheRecursiveFactorial Algorithm

3.1.3

Definitions

The definitionofsomefundimental terms isappropriate atthispoint. Anodeis the

pictorialrepresentaion of an operatorthat

typically

modifiesdataortheflowofdata. Anarc connects nodes

together,

describing

thepath ofdata betweennodes. Aportis

thepointof connection ofaarctoanode. The typeandsemantic_meaningofthedata

are defined

by

the portthataccepts oremits the data tokento /from the node. A

graph isa collection of nodesand arcsthat describe the flow ofdata

during

the ex

3,1,4

Creating

a

Procedure

It ismostconvenienttocreateall oftheprocedure graphspriorto_{creating the}main

programgraph. Itisnot_{absolutelynecessaryto createthe entire procedure}

graph,

however.

_{It is only necessary to specifyhow}

manyinput and output ports are re

quiredofeachprocedure. Then the appropriatenumberofportswillberepresented

ontheprocedurenodewhenit isspecifiedina graph.

* File Edi t

bjiJinMnnTB

Preferences Compile

ID m New Procedure... K n ^^=

!.hanj;e Procedure

$ann>...

Os>isfc? Procedure.,.

Figure 3.4

-Creating

a_{New Procedure Window}

To create a procedure _graph, create a new procedurewindow with the "New Proce

dure"

commandin the "Procedure"

menu. (Figure 3.4). This creates a new window

with thename "Procedure #1". As new procedures are created

they

are identified

with _{sequentially higher} numbers. To change the name ofa procedure, use the

"Change ProcedureName..."

commandin the"Procedure"menu. A

dialog

box isused

to type in thenew namefor theprocedurethat_{is the currently}activewindow(Figure

3.5). Press the OK button toacceptthenewnameorpressthecancelbuttontocancel

* File Edit Procedure Preferences Compile Windows

Entera new name for the current Procedure:

Factorial

Lsul

[

Cancel

]

Figure3.5

-Setting

aProcedure'sName

In the

dialog

boxespresentedtothe user

by

FlowGraph,

there isusually onebutton

thatisoutlined. That indicates the buttonthatis"pressed"

when thereturn

key

or

theenter

key

is typedonthekeyboard. This isausefulshortcutin textentry

dialog

boxes.

3.1.5

Working

withthe

Node Palette

The actual creation ofthe graph isaccomplished

by

moving the appropriate nodes

from the node palette into the graph window. To pull a _copy of a node offofthe

palette, move the cursor overthe desired node in the palette,hold down the mouse

button, drag

the node to its desired location on the palette, and then release the

mousebutton. Whileyouare

dragging

anode, thenode will appear as a square out

line (Figure 3.6). When the mouse button is released, the node will appear in the

File Edit Procedure Preferences Compile Windows

a

o

I__Q

.

[image:38.540.75.467.68.338.2]

: ... .

...

!:!:':'::!::!:::>:' :. ..::.. . :: .::..:

(E)

Y

^

f

LOOM

tOHTMU

Y

Tr^

injur

^

O

^

MRJTfll ITJ

f

Loor l

p___ I

isa

OUTPUTI

W

V

*

Figure 3.6

-Placing

Primative Operation NodesfromthePaletteintotheGraphWindow

To createthe Factorial _procedure, place an inputport connectornode and a switch nodein the Factorialgraph window as shown in Figure 3.7.

Factorial

&

f,

*

-0

.'_:':

mm

.

0

Q

Allofthe possiblenodes are not shownin thepalette. Nodes tend tobegroupedinto

"equivalent

groups", which are groups ofnodes with _very similar characteristics.

Examples ofequivalent groups include the mathematic _operators, the conditional

operators andthebooleanoperators

(and,

or).Membersof an equivalentgroupcanbe

substitutedforeach otherinthegraph.

Toplace a node_representingaconditionaltestforequivalenceon_{the graph,}a_copyof

thegeneral conditionalispulledoffofthepalette anditsoutlineisusedtopositionit

in thegraph. When themousebutton isreleased,a"mini-palette"appears overthe

left side ofthenode palette (Figure3.8). Thismini-palette containsthemembers of

the equivalent group for the conditional node.

By

_clicking on the appropriate

conditional,thatconditionalisplacedin thegraph.

-e-i---j-r-^----T-Factorial

t

__ _paaaat Li/iJCLLL'imil'I'll'L-LYL-jY^LiriV'.'l-iyi.LlLl.j.LLI.L'-L'.LL'.

@

P

I I i Li. jOx

w ^> <>? <X> <f> .

Wl

r

I

T

U

III

I

[image:39.540.116.427.324.573.2]

HT~ |~T

Figure 3.8

-"Mini-Palette"

MS

User

Preference^

Anumber ofuserpreference_featuresexistin FlowGraph. Oneoftheseisthe_ability

tomakean_{invisiblegridin thegraph windowthatthe}

nodeswill"snap"towhen

they

are placed or moved on the graph. This allows a _cleaner, more organized graph.

Selectthe"GridMode..."

commandfrom the "Preferences"

menu. A

dialog

box will

appear as shownin Figure3.9. The _{spacing is the}numberof screen pixelsbetween

grid points. Ascreen pixelis 1/72of aninch. Thusa quarterinchsquare gridcanbe

specified with a _settingof 18 pixels in both horizontaland vertical. Click the OK

buttonorpress returntoaccepttheentered value.

Set Grid Spacing:

Horizontal:

Vertical:

10

1<

[image:40.540.192.348.288.407.2]

|

OK

"~|

[

Cancel

)

Figure 3.9- Grid

Dialog

Box

3?1-?

Constant

:

Nodes

Whena constant nodeisplacedin the_graph,it hasadefaultvalue of zero. To setthe

value ofa constantnode, double click onthe node. The

dialog

box shownin Figure

3.10isusedto setboth thevalueandthe typeoftheconstant.

Typing

a number sets

the constant to have a

floating

point value.

By

_clicking on the True or the False

buttons,

abooleanconstantisdefined.

Constant nodes are displayedin the graph with an attemptto

display

itsvalue as

well. Figure 3.11 showsthevaluedisplays foranumberof constant nodeswithdif

ferentvalues. Ifareal value cannotbe displayed in thenode because ofits

length,

Information fora Constant Node Ualue: 1.000000

OTrue

O

False

I

OK

)|

Cancel

Figure3.10

-Setting

thevalue ofaConstantNode

Value=_{10.000 Value}=_FALSE

zp

Gp

GD

Gp

p

After Value=_{TRUE Value}-_{1 986} .75 Creation

Figure 3.1 1- Various Displays_{of a}ConstantNode

[image:42.540.78.468.69.334.2]

Figure 3.12

-Adding

aConstant

3.1.8

Changing

Nodes

on

the

Graph

Figure3.13

Actually,

asubtraction operatorisappropriatefortheFactorialalgorithm. Tochange

anode onthegraphto adifferent"equivalent"

type,

selectthenode

by

_clickingonce

in it. The node will indicate that ithas been selected

by being

displayed with a

grayed"body"as shownin Figure 3.14. Inthe

"Edit"

menu,selectthe "Change Node

Type..."

item. (Figure 3.15). Amini-palette will appear_{showing the} equivalenttypes

forthe additionoperator. (Figure 3.16). Clickonthesubtractionnodetosubstituteit

for theaddition operator(Figure 3.17).

[image:43.540.156.385.65.290.2] [image:43.540.177.367.469.596.2]

* File-IJ1MProcedure Preferences Comp

iimit) X-Z _{Fact_Test}

in^nn

mi -mi

s: opy m:

Pasta Kit

Clear

! Factorial

Y

select mi sen

ftepiicdle m)

Change Node Type...

t

or

.:i:

;.;.:-.;.. :- . .: :;: : :i;!-:;:-:-:i:t::-i::-::i-ir::;;::::i;

f..m.

slN /l\ /I+++I i lxl + l\.m./l\,

Figure 3.15- The"ChangeNode

Type..."

fromtheEditMenuallows_changingSelectedNodeto another

"Equivalent"

Type.

Y

<H

O

Y^#

l^jrtjKll)i

y-LOOP I

INTROI

LOOP DATA

i

i

i -nmi

i

it

[image:44.540.147.392.66.274.2]

Figure 3.17- The Graph_aftertheChange.

3.1.9

Adding

the Rest

ofthe

Nodes

To finish adding therest ofthe elementaryoperator_nodes, refer to Figure 3.18 for

their typeandlocation. Tomoveabout on_{the graph,} usethehorizontaland vertical

Figure3.18-_{NodeLayout fortheFactorialGraph}

The scrollbars allowsthe user toplacethegraph window over_anyposition onthe

large virtual graph plane.

Moving

the slider in a scroll bar moves a proportional

amount of distance in the "allocated graph

plane"

while _{pressing the} arrowheads

moves the window overthevirtual graph planein smallincrements. The allocated

graph space is the theportion ofthevirtual graphplanethathasbeen allocatedto

theparticular graph. To increase theallocated planedimensions ofthe_graph,press

the arrowheads ateitherend ofthe graph. This willallocate small amounts ofthe

virtual graph planeto thegraph and scrolloverthatareaoftheplane. Figure3. 19

showsthe_{releationship}oftheconceptsofthevirtualgraph_space,theallocated graph

[image:46.540.151.392.65.444.2]

Virtual Graph Space

Window

Allocated Graph Space

Figure3.19- Comparison_ofVirtual GraphSpace,Allocated Graph SpaceandtheGraphWindow

To add aproceduretothe graph,use the

Apply

operator. Aseach procedureiscre

ated,its nameisaddedto the"Procedure"menu.

By

_selectingthename ofthepro cedureyou wanttoaddfrom the proceduremenu,anode_representingtheprocedure [image:47.540.62.479.80.406.2]

File Edit -OTTCTW^IPreferences Co

NewProcedure...

Change Procedure Name...

in m

Delete Procedure...

Factorial

K

[image:48.540.176.364.355.444.2]

\*r*r/

Figure 3.20

-Selecting

aProcedure Nametobe Addedto theGraphwiththe

Apply

Palette Opera

tor

When there isnoprocedureisselectedinthe"Procedure"

menu, the

Apply

operatoris

grayed on the palette,

indicating

that it cannotbe selected. When a procedureis

selected, a check mark appears

by

it inthe menu andthe

Apply

operatorbecomes

availableforuse (Figure3.21).

rv |\7

PQ JOQ

]

<f

in

u

^

IflPPLVlE₁ SUBIB

v

*

I

s&

vl

+

1

Figure 3.21- An Inactive

Apply

OperatorandanActive

Apply

Operator

When the

Apply

operatoris draggedoff ofthepaletteandreleasedin thegraphwin

dow,

a node representingthe selected procedure iscreated. It is represented with a

double,

round cornerbox containing thename oftheprocedure and numberedinput

and output port connections.PlaceaFactorialprocedure node onthegraph asshown

in Figure 3.22 to allow the use ofthe procedure recursively.

Any

number ofnodes

representing a selected procedure _maybe added to the graph this way. To add a

differentprocedure, select anew namefrom the

"Procedure"

use the

Apply

operatorfrom thepalette. To deactivatethe

Apply

_operator,selectthe

current procedurefrom themenu again.

TaTTTTTfin"

[image:49.540.191.350.136.316.2]

Y

|Factorial||

\

Figure 3.22- AProcedure Node

3.1.11

Adding

Arcs

Arcs are drawn in the graph

by

_moving the cursorinto a node port, pressing and

holding

the mouse

button,

and

dragging

thecursortoanappropriate portonanother

node. While the cursoris

being

dragged,

the arc isrepresented

by

a "rubberband"

line (Figure 3.23). If the mouse button isreleased while the cursor is over an ac

ceptable _port, the programredraws the arc as ajaggedline with darkenedports at

t,

[image:50.540.192.379.70.253.2]

iRFnhitl^k.l

A.

ln^|>^|>M>:

Figure 3.23

-A"RubberBand" Arc

yii.i... ...>t...pr__.

Figure 3.24- A

Final,

Connected Arc

FlowGraphusesa simple setofrulesfor addingarcstoa graph:

Aarc must connectanoutput portofone nodetoaninputport of another node.

Multiplearcs can eminatefrom anyoutput port(except from aconstant node).

Only

one arccanbeconnectedto any inputport.

Theports

being

connectedmusthavethesamedatatype (booleanorreal). [image:50.540.199.368.299.476.2]

window_{area, the}portstobeconnected mustboth bevisiblein thegraph window at

thesametime.

Figure3.25-ConnectedFactorialGraph

In the Factorialexample,connectthenodesas shownin Figure 3.25.

Basedon the rules for connectingarcs,there are anumber ofapproaches thatgive

theuser afairamount offlexibility. For_example, ifaSwitch operatorisused asa

deciderfor twodifferent data_paths, andthe results of either one orthe other data

pathneedstobeconnectedto theinputportofa_node,thereisno_wayto

directly

con

nectthe twoarcsto thesingleinputport.

However,

aconnectionnode existsthathas

twoinputports andone output portwhich canbeusedto channelthe two alternate

[image:51.540.192.351.133.428.2]

Somenodescanprocess eitherboolean or realdata. Ifanarc isdrawn between two

portsthatare notdefinedtohave aspecificdata

type,

a

dialog

boxwillbe presented

topickthe typefor thearc. Thisdatatypewillthenbeassignedto theother relevant

ports onthenode as well. For_example,the Switch operator nodecan switchthe in

putdata basedonthevalueofaboolean input. The inputdatacanbe eitherboolean

or real. Once an arc isconnected to either the inputportor one ofthe two output

ports, thedatatype for thatarcdetermines thedatatype thatmustbe connectedto

theotherportsonthenode. Ifan arc_representinga realdatatypeisconnectedto the

inputportofthe Switchoperator_node,theoutput portsofthe Switch willthencheck

forconnectionstoportsof anothernodethatacceptreal values. It ispossibleto turn

offthe type _checkingwith the "Preferences"menu in FlowGraph. Inthe data flow

simulator,alldataobjects are processed as

floating

pointnumbers, whereavalue of

zeroisreturned

by

abooleanexpression thatevaluatedtofalse and anon-zero value

isconsideredtobetrue.

Circumventing

_{type checking}isnot_recommended,however.

To

help

connect portsina largegraph, thegraph windows can be zoomedouttofill

theentire screen space_usingthezoombox intheupperrighthandcorner ofagraph

windowstitle bar. Figure 3.26 showsthe standard window which exposesthenode

# File Edit Procedure Preferences Compile LUindoms

Fact_Test

Factorial IHI

O

l__s

O

YY^

|lHPUT_|

^

flPPLV

I SUB I

+ . OUTPUT

^

[image:54.540.184.359.291.444.2] [image:54.540.180.366.487.641.2]

3.1.12

Editing

Arcs

Figure 3.28showsan arcthathasbeen

incorrectly

connectedfrom the true sideofa

Switch operatorto the multiplication operator. To selectan _arc, click on the input

portthatitconnectsto. Aselected arcis displayedas a grayedline (Figure3.29). To

remove the _arc, select the "Clear" menu item from the "Edit"

menu or press the

backspace key. This approachofselectan objectand

deleting

itworksfornodesas

well. If the shift

key

is held down while _selectingobjects, multiple objects _maybe

selected at onetime.

Figure3.28- The_arcbetweenthe 'True"

outputportoftheSwitch Nodeshouldnot goto the Multiplicationnode.

* File Procedure Preferences _Comp

Undo s3i2! _{Fact_Test}

Select Rll sen

Change Node Type

Figure3.30- Delete

aSelected Arc (or

Node)

by

_usingtheClearmenuitem.

3.1.13

The

Main Program Graph

Figure 3.31 shows the main program in itsgraphwindow. After creatingthe Fac

torial procedure graph, activate the main window

by

_clicking somewhere on the

window or

by

_{selecting the}main graph windowfromthe"Windows"menu. Themain [image:55.540.146.394.101.308.2]

y~ File Edit Procedure Preferences Compile Windows

Fact-Test

|FILE

1|

1

Factorial

1

o

[File

Output]

a

a

(E)

Y

w

#*

f

I LOOP i

COHTKOtl

UJJLJ

Y^^>

P

BRnTl[

*TT

f

I LOOP I

I MTU I OUTPUT]DEBUGI

Figure3.31-_{The Main Program Graph}

AsFigure 3.31 shows, theprocedureinput/output connectorsinthenode palette are

grayedbecause

they

are not availableinthemain program graph.

Themain program shouldhaveafile inputnode which willbeused asthetriggerfor

thegraph execution

by

thesimulator.

When the output nodeiscreated, theuser will beasked_{to supply the}number ofI/O

ports required. For thisexample, one port was specified.

By

double clickingonthe

file output node,a window will open to enter the textof_anymessagetobe printed

[image:56.540.73.466.71.335.2]

-JUAJSetting

Trace Options

Before generatin