TOOL SUPPORT FOR COLLABORATIVE SOFTWARE

PROTOTYPING

Elliot A Shefrin y

James M Purtilo z

Computer Science Department

University of Maryland College Park MD

Decemb er

ABSTRACT Prototyping is a means by which requirements for software pro jects can b e dened

and rened b efore they are committed to rm sp ecications for the nished software pro duct

By this pro cess costly and timeconsuming errors in sp ecication can b e avoided or minimized

Reconguration is the concept of altering the program co de bindings b etween program mo d

ules or logical or physical distribution of software comp onents while allowing the continuing

execution of the software b eing changed Combining these two notions suggests the p otential for

a development environment where requirements can b e quickly and dynamically evolved This

pap er discusses recongurationbased prototyping RBP that is the simultaneous consideration

of requirements software b ehavior and user feedback within a running system in order to derive

a clear sp ecication of an intended pro duct To ols enabling RBP can co ordinate the eorts of

designers prototyp ers users and sub ject matter sp ecialists as they work towards concensus on

an applications sp ecication by means of a prototyp e The authors describ e the scop e of the

mo dications that can b e eected by an integration of prototyping and reconguration proto

cols and they then demonstrate that the technology exists to create such an environment They

conclude by describing a software development environment based on RBP

KEYWORDS Reconguration Prototyping M Technology

y Elliot Shefrins research has b een supp orted by the Longitudinal Studies Branch Gerontol

ogy Research Center National Institute on Aging National Institutes of Health United States

Public Health Service He can b e contacted at mazelcsumdedu

z With oversight by the Oce of Naval Research James Purtilos research has b een supp orted

by ARPA in conjunction with the Common Prototyping Language pro ject contract numb er

NC He can b e contacted at purtilocsumdedu

INTRODUCTION

During the development of software systems a prototyping phase is often employed to ne tune

various asp ects of the system or to discover user requirements preferences or op erational imp er

atives PFW These asp ects may include development of the user interface testing of various

structures for the database or optimizing internal algorithms From this viewp oint prototyping

can b e regarded as an information acquisition activity whose principal goal is to reinforce the

condence of the system develop er and the user in the correctness of the system sp ecication

In Pur the author describ es the traditional approach to the tuning pro cedure as an iterative

pro cess of program execution halting mo dication and restarting Such a technique can b e

timeconsuming and frustrating esp ecially when the system takes a while to reach a steadystate

or when each iteration of the tuning lo op requires many steps

A pivotal p oint illustrated in PFW is that a prototyp e need not implement the underlying

algorithms of the system under development Rather all relevant data may b e loaded from tables

and pro cessing on that data may b e simulated Furthermore not all asp ects of a design require

a prototyp e It is up to the designer to identify the elements of risk the areas of uncertainty

that can b e reduced by the implementation of a prototyp e The ingenuity then of the system

develop er lies in deciding which asp ects of the design need to b e prototyp ed and what information

is to b e extracted from the prototyp e A further challenge is to involve the user to such a level

that they feel they have a vested interest in pro ducing the b est pro duct p ossible Stated another

way it is the ends and not the means that concern the prototyp e develop er The observation

that platforms and scenarios can b e contrived to elicit necessary information leads to the useful

conclusion that the to ols and vehicles used to construct the prototyp e do not need to b e the

same as those used to construct the nished pro duct Indeed since it can b e built on a simplied

testb ed the prototyp e should b e capable of cutting quickly to the core of the problem and can b e

emp owered to use whatever technology is most ecient and eective to obtain the information

that is the end pro duct of that particular prototyp e This p oint obtains relevance b ecause we

will contend that there is no need to justify the choice of a prototyping host technology or to b e

concerned with the applicabili ty of the technology used in the prototyp e to the design pro ject at

large

The traditional approach to prototyping can b e compared to attempting to tune the engine of

an automobile by the following series of steps

start the car

observe the output on an engine analyzer

stop the engine

make an adjustment

restart the car to see how close we have come to the correct setting

This aords no ability to receive realtime feedback from the engine the ob ject under study

In contrast the way it is done in practice is that the technician observes the output of the engine

analyzer while the motor is running in steadystate and he is making incremental adjustments In

this actual practice the technician is reconguring the op eration of the engine while it continues

to run Applied to software we b elieve that the concept of reconguration dynamically

mo difying an executing piece of software can b e employed to advantage in order to make the

tuning pro cess more ecient

The current state of understanding regarding reconguration is summarized in Pur It is

stated that the options for reconguration are limited to those anticipated by the develop er of

the software Fundamental problems arise b ecause to ols for reconguration are weak and the

steadystate may b e easily disturb ed by those to ols that do exist However in this pap er we will

describ e an approach to reconguration that allows a great amount of exibility We will outline

the framework that should b e employed in order to attain this level of adaptability and we will

demonstrate that it is in fact achievable In the next section we will illustrate our p osition

and motivation regarding the desirability of a synthesis of prototyping and reconguration A

discussion of language issues relating to our work will comprise section In section we

will describ e the elements which underlie the concept of recongurability and link them to the

prototyping pro cess Then we will describ e a metho dology which enables a develop er to avoid

the requirement of anticipating all p ossible p oints of mo dication and demonstrate how easy it

is to accomplish a high level of recongurability Section will describ e the course of research by

which we are validating our assertions We will draw our conclusions in section

MOTIVATION

We b elieve that the broadening of the prototyping pro cess to incorp orate reconguration tech

nology will result in a more ecient discovery of the needed information Furthermore if the

user can b e actively involved in the pro cess then the outcome is more likely to b e acceptable

some of the mystery of problem resolution will have b een mitigated and the user will have a

p ersonal interest in the quality of the end pro duct The development cycle that we anticipate

is illustrated in Figure Starting from an initial design sp ecication the develop er identies

zones of risk or uncertainty These are the elements of the design that must b e rened in order

for the nal pro duct to have the greatest acceptability and utility to the user Having identied

these areas the designer must articulate alternatives along with a metho dology for evaluating

these alternatives The goal is to arrive at a rened sp ecication and a decision as to whether

the pro cess is complete or needs another iteration

The metho dology employed by the designer subsumes several critical comp onents The rst is

a suite of test data or a hyp othetical problem to b e solved using each alternative of the system

under test These problems must b e formulated to provide the user the opp ortunity to make

contributions to the renement and evaluation of the alternatives this is the critical stage where

the user b ecomes a partner in the design pro cess A means must b e sp ecied to quantify the

merit of each outcome so that alternatives can b e ob jectively compared We shall use the term

discriminant function to refer to this evaluation proto col that will allow the user and the develop er

to quantify dierences in the identied alternatives assign a merit value to each and recognize

when the ob jective has b een reached And nally diering scenarios must b e envisioned so that

the design will in fact meet the sp ecications over the entire op erational domain

A critical part of this prototyping metho d is the ability to interactively and dynamically re

congure the executing software in order to p erform the test and evaluation We are working

on a proto col that sp ecies and implements prototyping in a development environment that in

corp orates dynamic software reconguration Such a RecongurationBased Prototyping RBP

mo del as describ ed in greater detail in section is b eing constructed with design concepts and

software to ols using suciently p owerful and exible languages as discussed in section RBP

includes the capability to mo dify parameters algorithms interfaces and database structure

thereby enhancing the prototyping eort in a manner outlined in section

Figure Prototyping Reconguration Development Cycle

BACKGROUND

The concept of prototyping has b een a part of engineering philosophy for many years and it

is only natural that it should have b een incorp orated into the design approach for software

development Dynamic reconguration on the other hand is a topic more sp ecic to software

systems and we nd ourselves earlier in the evolution of this technology The issue of language

choice has b een raised in the previous section and there is much prior information ab out sp ecial

capabilities of various languages In the next part of this section we lo ok at some of these issues

and examine one existing technology that facilitates the work we are doing

LANGUAGE ISSUES

We can envision an environment for recongurationbased prototyping We can articulate the

capabilities that separately facilitate prototyping and reconguration combine them and add

any extra features suggested by the merging of the two proto cols For prototyping we would

like to b e able to quickly and easily convert ideas and algorithms into op erational programs this

implies the use of some higher level computer language We would like the ability to emb ed

instrumentation in the prototyp e and to observe the output of that instrumentation in an on

line mo de We would like a shared runtime environment where system state and data can b e

examined to further understand the op eration of the prototyp e For reconguration we would

like the capability to monitor the currently op erating conguration and the state of p otential

reconguration options Dynamic mo dule bindings would b e necessary for interchanging mo dules

Though not a necessity mo diable co de would op en a broad range of revision options Here to o

a shared runtime environment would emp ower the designer to manipulate comp onents on the

same platform that the reconguration is pro ceeding on For the combination it would b e

desirable to b e able to alter the mapping of mo dules onto no des and to b e able to radically

transform the functionality of any comp onent regardless of its level in the execution hierarchy

While there may b e several to ols that provide this desired environment we maintain that it is

only necessary to identify one since the language of the prototyp e need not b e wedded to the

language of the ultimate implementation With this in mind we describ e an existing technology

which provides the facilities that we have identied as emp owering M formerly known as

MUMPS is a p owerful ANSI FIPS and ISO standard thirdgeneration programming language

Part of this standard is an assurance that implementations will b e platform indep endent Thus

prototyp es develop ed under one conguration will b e readily p ortable to other congurations

or platforms Furthermore since the language is in a continuing state of development the

standards are revised p erio dically typically every three or four years to incorp orate new features

of interest to develop ers of stateoftheart applications By incorp orating new developments such

as MWAPI MWindows Adaptable Programmer Interface and OMI Op en M Interconnect

into the language standard the M community is assured of continued consistency and p ortability

In using these interfaces and standards the M programmer can write software mo dules which

can function well in a mixedlanguage environment

From a prototyping standp oint M has several areas of strength A feature of the M Technology

is p ositive control over system resources and devices Sp ecic units are op ened and then used

and the programmer is allowed to manipulate the parameters of these units By interp osing an

interface layer many implementations can b e made virtually device indep endent This adds to

p ortability as well as consistency b etween various environments

Various forms of parameter passing and accommo dation of undened values allow programmers

to develop subprograms that are general robust and reusable in nature Mo dern features of

denition of scop e including private and public variables extend this ability While this is not a

feature unique to M it do es p ermit indep endent parallel development of various asp ects of a larger

mo dule by separate groups of programmers once the interface input and output sp ecications

have b een decided up on However M is not a recursive language programs constructed in M

rely instead on iteration

Originally M was strictly an interpreted language As such there were no compile or link steps

in program development Mo dern M implementations p erform a compilation ranging from to

kenization to more comprehensive compile but most still revert to realtime linking Syntax

checking and compilation is often p erformed as a nal step in the program editing pro cess prior

to ling the edited routine This translates into a rapid developmenttrialrevision cycle that is

ideal for debugging segments of a large system Furthermore since M remains essentially inter

preted in nature it is easy to step through routines examine current values of variables and set

traps using the p owerful debugging to ols that have b een provided by implementers

Furthermore M do es not require or allow declaration of typ e size or structure of variables

This applies b oth to lo cal memoryresident variables and to global diskresident data structures

While this may p ose an intimidating abundance of freedom for novice inexp erienced or unskilled

programmers it can b e a p owerful ally for go o d software engineers It can provide the capability to

quickly and painlessly restructure a database as dictated by evolving development and debugging

during the prototyping pro cess Once established the nished structure need only b e formalized

in the do cumentation With resp ect to instrumenting visualizing and monitoring the b ehavior

of the prototyp e M has the p otent prop erty that all of its database globals can with trivial ease

b e made visible to other pro cesses on the system whether in the same or separate computers

This implies that prototyp e b ehavior and status can b e observed recorded and displayed by

noninvasive indep endent pro cedures executing on platforms of the implementers cho osing In

some cases the prototyp e may b e augmented to incorp orate rep orting of status however due to

the ease of variable denition this can b e quickly patched in or removed as the situation requires

The language has the exibili ty to deal with novel and current paradigms such as ob jects and

the relational mo del Also clientserver and p eertop eer networking and distribution of the

database are standard features of many of the implementations of the M Technology Another

inherent feature of the M Technology is the capability to spawn background indep endent parallel

pro cesses These jobs can b e synchronized and co ordinated by use of the global database or by

pip es easily established as devices connecting two pro cesses Coupled with the distributability of

the database this provides a p owerful to ol and ability to develop parallelism as part of the design

of a prototyp e In fact jobs can b e spawned on the same pro cessor as the parent program or

they can b e started on a server which hosts the data on which the pro cess op erates Therefore

by clever design of the distribution of the database and distribution of the computing load

signicant advantages can b e had by parallelism and this is completely under control of the

program designer

From the reconguration standp oint there are two additional key prop erties of the M Technology

that emp ower the develop er indirection and the capability of executing variable co de For

example the following line of M co de illustrates indirection

do variablesub

This statement is a command to invoke the subroutine whose name is stored in the variable

named variablesub as a text string In other words if the current value of variablesub is

output when the ab ove line of co de is encountered then the line is equivalent to

do output

Furthermore variablesub could b e a variable in the lo cal space of the executing mo dule it

could b e inherited from a calling mo dule it could have b een passed as a parameter or most

signicantly it could b e a shared global element of the database

M also includes the ability to execute a variable as an M command Again we employ an example

set variablecommandset xvba write xyz

xecute variablecommand

has precisely the same eect as if

set xvba

write xyz

had b een hard co ded into the routine Analogous to the description of indirection the executed

variable can b e lo cal or global and the eect of executing the command is strictly a function of

the value of variablecommand at the time it is actually encountered during execution

PROTOTYPING AND RECONFIGURATION

In order to pro ceed on the combination of the prototyping approach with the reconguration

capability we need to understand more fully the interactions and overlaps b etween the two con

cepts The rst part of this section explores this in greater depth Building on this understanding

the second part of section prop oses guidelines to ensure that develop ed prototyp es will b e able

to take advantage of reconguration

INTERRELATIONSHIPS BETWEEN THE TECHNOLOGIES

In HP the authors discuss the need to manage three dierent typ es of reconguration mo dule

implementations system logical structure and geometry While their discussion is placed in

a framework of language indep endenc e we contend that many applications are implemented in a

language of choice with very few pieces if any written in other languages A particular example

of this class of application is scientic computing In prototyping for this typ e of software there

exists the need to recongure while executing This is b ecause it may take a while for the

prototyp e to either reach steadystate or to reach the place that is of immediate interest to the

designer Point by p oint we will outline the interrelationship of reconguration and prototyping

The need to mo dify the implementation of mo dules encompasses several dierent activities It

may b e necessary in order to replace a mo dule which has b een found to contain a bug It

may b e driven by the desire to install a mo dule implementing a more ecient algorithm or a

dierent slightly or otherwise functionality There may b e a reason to adjust some parameters

emb edded in the program Sp ecicall y in the case of prototyping there may b e the need to

mo dify the instrumentation so that dierent or additional asp ects of program function are made

accessible to observers Relating back to the example reconguration might b e applied to the

task of substituting dierent display or interface algorithms to discern which b est conveys the

information that is appropriate to the ob jective

In a singlethread application where traditionally the entire pro cess is one load mo dule it is

dicult to make mo dications while the application is executing and still maintain the ongoing

execution state Concepts of encode and decode are intro duced in HP to capture and then

reinstall runtime state when a mo dule is to b e recongured However use of these constructs

require the designer to correctly anticipate places in the algorithm where reconguration will

b e desired Furthermore sp ecial provision must b e made to recognize when the program has

reached a recongurable state so that reconguration can b e invoked These considerations are

imp ortant in the prototyping pro cess as they are in any reconguration so that the steadystate

which has b een reached is not disturb ed

The discussion regarding logical structure or top ology of the application can b e approached in the

same manner as changes in implementation It may b e that the attention of the prototyping eort

has b een turned to p erformance considerations of how the task is sub divided among subroutines

or parallel pro cesses Observing the resp onse of the system to such a top ological reconguration

could b e very useful in the development pro cess

As for geometry there are several reasons why the distribution of the pro cessing might b e altered

during execution in addition to load balancing fault tolerance or resource availability It may b e

desired to execute a mo dule closer to the data on which it op erates to measure the p erformance

improvement It may b e useful to direct the op eration of a mo dule toward a dierent lo cal

database op erating on another machine

In summary there exists quite a bit of overlap b etween the availability of a strong dynamic

reconguration to ol and the ecient pursuit of the prototyping pro cess

As discussed in the intro ductory section of this pap er we do not need to justify our choice of a

prototyping host technology or to concern ourselves with the applicabili ty of the technology used

RECONFIGODEV EAS AM Jan

demonstrate Ms reconfiguration capability

set up routines to call initially

set SUBNAMENOHISTSTATDISPDISPLAY

initialize the number of targets to track

set NUMTARGET

now just loop forever until termination flag set

for quitdataRECONQUIT do SUBNAME

kill RECONQUIT quit

Figure Routine RECONFIG

in the prototyp e to the design pro ject at large The prototyp e sub ject to reconguration is a

vehicle for rening the requirements of a pro ject It is not necessarily a means by which program

co de is develop ed for the nished pro duct Since we can and have describ ed a set of problems the

solutions to which are enhanced by combining reconguration and prototyping we can pro ceed

in whatever milieu provides the capability to p erform such a combination

ESTABLISHING RECONFIGURABILITY

In order to initiate reconguration a pro cess must come to a recongurable state HP Accord

ing to KM such a state exists when a pro cess nishes any communication and has pro duced

all output necessary to allow other pro cesses to conclude their tasks and also reach a recon

gurable state We b elieve that this requirement is to o restrictive and that a pro cess can b e

recongured at any time provided that with resp ect to the conguration that it replaces

it supplies at least the same functionality to mo dules ab ove it in the execution hierarchy

and

it can op erate in the same environment

In order to achieve this degree of exibility a program designer should adhere to several basic

rules

use mo dular design to as great a degree as p ossible

try to return to a programming depth of one as often as p ossible

ensure that required information is p ersistent and

utilize parameters drawn from the global database wherever there is the slightest chance

the parameter might b e tweaked in any tuning pro cess

Since the name of a subroutine can b e parameterized using the indirection op eration any branch

to a subroutine can b e a reconguration p oint Therefore the rst requirement using mo dular

design enables a change of conguration to o ccur at whatever frequency subprograms are called

If the designer observing the op eration of the prototyp e decides to make an implementation or

top ological change he could accomplish this by simply replacing the name of the existing routine

in the database with the name of the new routine Then the next time this call is made control

is transferred to the new mo dule

This means that reconguration can o ccur at any programming depth However following the

second rule and returning to the outermost level of program depth implies that the entire mo d

ule can b e swapp ed during a reconguration while execution continues with the steadystate

environment intact In this way recongurations as dramatic as a complete metamorphosis of

software direction scop e and purp ose can b e eected

If the design of the pro cess considers the need to have p ersistent values then these values can

b e set at an outer programming level and will b e an inherited part of the op erating environment

of any sub ordinate scop e unless explicitly redened This ensures that when a reconguration

is initiated the successor conguration will inherit the same environment as its predecessor and

will b e able to maintain a steadystate op eration If the environment is not preserved then a

reconguration will have to indeed take place only when the system is quiescent so that the

appropriate environment can b e created from the top down

The fourth design criterion is stated to emp ower the prototyp e designer to make incremental ad

justments to the running software just as an auto mechanic makes small corrections to a running

car engine while observing the eect of those adjustments on the instrumentation attached to

the car If a parameter is picked out of the global database each time it is used then replacing

one value with another in that global database will have a near term impact on the op eration of

the pro cess It is interesting to note that if the program is made mo dular enough it may not b e

necessary to anticipate every adjustment p oint In the case where an adjustable value is desired

where none was provided for the designer can revise the routine containing the parameter to b e

adjusted either making it global or changing its hardco ded value and then can swap the revised

program in at the next iteration as describ ed ab ove

Following these rules a prototyp e designer is emp owered to make changes ranging from the

complete metamorphosis of a target tracking system into a banking system though one wonders

how the initial requirements statement could b e so general as to have such a thorough change

b e meaningful to the simple netuning of a computational algorithm The more farreaching

the reconguration the more likely that dierent data structures top ologies and interfaces will

b e part of the change A comprehensive level of change would b e very sp ectacular and would

dramatically illustrate the p ower of reconguration and this degree of change is as easily enacted

as a minor mo dication

This raises the issue then of what kinds of change would b e found useful Recalling that our

approach to prototyping is as a to ol to resolve high risk areas in the sp ecication of a software

pro duct it app ears that the changes would b e on the line of variations on a theme rather

than sensational changes in basic goals and purp oses However within the scop e of the risk to b e

minimized any degree of change that would b e desirable to the resolution would b e supp orted

by RBP The impact would b e as dramatic as appropriate to answering the questions at hand

All of the ab ove are b est illustrated by an example While we could cho ose to give a case in

which an avionics system is changed into a mortuary accounting system it is more realistic and

illustrative to relate an initial example of target tracking to the MTechnology Let us presume

that the designer has identied the information displayed to the user as an element of risk

an asp ect which should b e prototyp ed Initially he has sp ecied as alternatives the option of

displaying either current target information only or current and historical target information

The ob jective that he has dened for the user is to b e able to ascertain when a target b ecomes

a threat Let us further presume that several utility functions are available

STATUStargetnumbertime which returns a delimited string describing all known sim

ulated information ab out the requested target as of the requested time including lo cation

NOHIST EAS AM Jan

demonstrate Ms reconfiguration capability

display status on number of targets in NUMTARGET

at the current time only

then hang for seconds in PAUSE

fix the current time in seconds

set NOWpiecehorolog

for TARGETNUMTARGET do

set STATUSSTRINGSTATUSTARGETNOW

do STATDISP

get pause time use one second as default if not

defined

hang getPAUSE quit

Figure Subroutine NOHIST

co ordinates symb ol time of observation etc

Xstatusstring and Ystatusstring which return resp ectively the X and Y co or

dinate for the target describ ed by the status string and

LINExyxy which draws a line on the display from the p oint with co ordinates

xy to the p oint xy

The plan is by varying the numb er of targets the information displayed the up date frequency

and the historyno history options to arrive at an improved design sp ecication

Figure shows a toplevel program which rep eatedly calls one subroutine Up on initiation the

output device descriptor is passed to the program RECONFIG This value b ecomes part of the lo cal

environment which is available in all sub ordinate scop es Also the program initially sets up to

call the subroutine NOHIST by storing that subroutine name in the global variable SUBNAME In

the M notation a carat in front of a routine name indicates that it is external to the current

routine and a carat in front of a variable name means that variable is part of the external global

database Then the routine establishes the initial display routine to b e used by storing its name

DISPLAY into the global variable STATDISP and the numb er of targets to initially display Next

the routine b egins rep eatedly calling the subroutine named in the global variable SUBNAME until

a ag also part of the external database is set directing it to shut down When this shutdown

o ccurs the ag is removed from the database and the routine exits

Within this subroutine there are several p oints of recongurability which will allow the designer

to interact with the user to solve the problem First the numb er of targets can b e changed for

example to by executing the statement

set NUMTARGET

Also as stated the names of the two subroutines to invoke are variable and can therefore b e

changed to substitute any desired functionality

The subroutine initially invoked is named NOHIST and is shown in Figure This routine inherits

its lo cal variables from the calling routine so ODEV is assigned whatever value it acquired in

RECONFIG and this value will in turn b e available to any routines NOHIST calls The rst

executable statement establishes the current time by retrieving part of the system clo ck available

in the horolog sp ecial variable The routine enters a lo op which will b e rep eated for targets

numb ered through the value found in the global variable NUMTARGET During each iteration

the simulated status is retrieved and displayed Finally the subroutine pauses hangs for the

numb er of seconds that are stored in the global database variable PAUSE b efore returning to

the calling routine

The nal piece of the example is the subroutine called HIST and shown in Figure Its op eration

is similar to NOHIST However in this routine two statuses are retrieved the interval b etween

which is parameterized in INTERVAL For each the co ordinates are extracted and retained while

the status is displayed Then a line is drawn from prior to current status

This example provides us with several ways to demonstrate dynamic conguration After the

main routine is invoked it quickly reaches steadystate Because it is sp ecically written to b e

mo dular at the top level it only calls one subroutine The p oint at which this subroutine is called

inside a lo op structure b ecomes a recongurable state This is b ecause the prototyp e designer

can substitute the second alternative he has predened by executing the command from his test

platform

set SUBNAMEHIST

and the reconguration is accomplished on the next iteration Furthermore while the prototyp e

is calling DISPLAY to paint the status on the screen the designer can b e writing testing and

HIST EAS AM Jan

demonstrate Ms reconfiguration capability

display status on number of targets in NUMTARGET

at the current time as well as a prior interval

and connect the two with a line

then hang for seconds in PAUSE

fix the current time in seconds

set NOWpiecehorolog

and the prior time interval is a dynamic parameter

set THENNOWINTERVAL

for TARGETNUMTARGET do

set STATUSSTRINGSTATUSTARGETNOW

set XXSTATUSSTRINGYYSTATUSSTRING

do STATDISP

set STATUSSTRINGSTATUSTARGETTHEN

set XXSTATUSSTRINGYYSTATUSSTRING

do STATDISP

do LINEXYXY

get pause time use one second as default if not

defined

hang getPAUSE quit

Figure Subroutine HIST

debugging DISPLAY When he is satised that the new display subroutine is correct he can

execute the command from his test platform

set STATDISPDISPLAY

and this new routine will b e invoked at the next call Finally the designer can dynamically

alter the time interval encompassed by the two status p oints in HIST by varying the numb er of

seconds in the global INTERVAL Similarly he can tune the time b etween up dates by dynamically

changing the value of the variable that directs the pause time

set PAUSE

This will increase the hang time to three seconds at the next iteration of whichever subroutine

is in the execution path Also note that the routine will run forever unless the tester issues the

command

set RECONQUIT

which by creating and dening the global variable RECONQUIT directs the main routine to

terminate This of course is also a form of reconguration

In this example the only entity that is not recongurable is the main routine RECONFIG Below

that level any amount of change is p ossible simply by reconguring the p ointer to which sub

routine is called For example we are not limited to sending b ells to a device or to only one level

of depth The routine p ointed to by SUBNAME could p erform a variety of functions or call other

subroutines which themselves could b e variably invoked

Now that the metho dology has b een crudely demonstrated we would like to oer another very

simplied example again clearly demonstrating the interaction b etween this reconguration ca

pability and prototyping Departing from our previous example of user interface design we will

draw up on a scientic computing scenario Assume that we are developing a longrunning math

ematical analysis program After it reaches steadystate we observe that the results are not

converging as fast as we would like If written according to this proto col we could set dierent

values for some of the computation parameters and observe the eect on the sp eed of convergence

Furthermore supp ose that we as observers of the instrumentation built into the prototyp e nd

that we would like to watch the values taken on by a particular variable that was not initially

anticipated We could edit a renamed copy of the routine and insert a command such as

set NEWOBSERVATIONVARIABLEOFINTEREST

When the revised copy was completed and led we would mo dify the global software switch that

would trigger its invo cation in place of the old copy This would provide us with a new view into

the op eration of the routine allowing us to display the most recent value of the variable we have

sp ecied To do this we would issue the command

write NEWOBSERVATION

and the current value would b e presented to us

These examples have b een presented using the features and the syntax of the M Technology In

a prototyping eort that is based on RBP and M it would b e necessary to have a memb er of the

development team with a basic understanding of the M Technology This requirement is further

discussed in section

UNDERTAKING THE RBP PROJECT

We are implementing the RBP prototyping pro cess in an environment that employs recongura

tion technology rather than the startstopchangerestart technique This includes investigation

into the several asp ects of the RBP proto col as describ ed in section This work will increase

understanding of the applicabili ty of the various prototyping and reconguration techniques and

the synergism and interplay b etween them We intend to incorp orate the results of our research

into a draft guide to the use of RBP

RESEARCH PLAN

From a sp ectrum of research questions and issues we have selected the area that we b elieve

has the broadest implications The resolution of RBP implementation and applicabili ty issues

constitutes the bulk of our work In the rst ma jor step we are building the recongurationbased

prototyping environment so that its viability and features can b e demonstrated and exp erimented

with Details of this implementation are describ ed in section

As the second principal part of our work we will use this mo del to develop an understanding of

the applicabili ty of RBP and cost overhead created by its use As discussed previously there are

several distinct typ es of and motivations for prototyping and dierent facets to reconguration

We will explore a variety of situations to b e able to evaluate to what extent dierent combinations

are enhanced by the RBP proto col A more sp ecic discussion of this undertaking is presented

in section

Figure Implementation Concept

DESIGN RBP PLATFORM The successful design and implementation of the RBP plat

form as describ ed in this section will conrm the rst part of our hyp othesis we will substantiate

the feasibility of the RBP concept The applicabili ty of the M development environment will b e

armed

The mo del will b e implemented in the M Technology on a host system as illustrated in Figure

M has b een chosen as the development medium b ecause of the emp owering features of the

language that have b een discussed in section Although we recognize that M is not the

language of choice in the academic community we have presented that the prototyping eort

itself can b e indep endent of the language of the overall pro ject and M oers an environment

which is conducive to b oth the development exercise and demonstration of the RBP proto col

There are four ma jor comp onents to the design These may b e envisioned as separate windows

b eing driven by the host Each of these parts is attached to the host by a hard communications

link with the pro cessing b eing p erformed internally to the host However a virtual control

hierarchy is in place by which RBP pro ceeds

The governing pro cess shown as development in the gure is the window at which the

designer works This individual would b e the develop er cited in FD and MC His task

is to interact with the user to tailor the software under test to b est address the problem to b e

solved or risk to b e reduced As describ ed in section his goal in employing the RBP metho d

ology is to reduce lag time b etween prop osal and presentation of alternative ideas From this

development p osition the designer can achieve any extent of reconguration that is consistent

with the ob jective of rening a requirements sp ecication to reduce risk Of course as stated

b efore more dramatic recongurations are always p ossible but are mo ot if they are not oriented

toward solving the problem at hand From this logical p osition the designer has the capability

to

interact with the host system at the executive level

initiate the execution of the prototyp e

write test and debug new mo dules while the prototyp e is continuing to execute prior to

releasing them for insertion into the prototyp e

control the control window by causing alternatives and recongurable parameters to

b e shown as options

optionally exercise direct control over the user window by bypassing the control

and directly manipulating the environment and

control the instrumentation by means of either the display co de or global vari

ables built into the prototyp e or by dynamically revising the mo dule that is tasked with

manipulating the instrumentation window

It is this memb er of the prototyping team that must have a working knowledge of the fundamentals

of the underlying software In the case of our examples it would b e this individual who knew

how to use the resources of the M Technology

The control panel pro cess shown as control in the gure is the window at which pro

totyp e alternatives are shown as selectable options This p osition may b e considered a liaison

function much as the architect in MC This memb er of the development team would have the

resp onsibility for timing the institution of changes and of manipulating the detailed parameters

that would b e provided as options Working at this window a designer may

select from prototyp e alternatives in the form of dierent mo dules routines or versions

that can b e recongured into the executing mo del

establish values for global parameters which will have an impact on the p erformance of the

prototyp e

terminate the prototyping session and

exercise control over the user window by invoking the conguration that has b een

selected

The participant who is p erforming the test of the prototyp e by attempting to reach the established

goal op erates at the user window We have previously discussed the p erceived value of

having the end users involved in the evolution of sp ecications for a pro duct a factor often

overlo oked in practice LSZ By including this station as an integral comp onent of the RBP

proto col we are ensuring that user input will b e considered The duties of this individual are to

interact with the prototyp e presented to him attempting to solve an exp erimental problem

or reach an articulated goal

evaluate available alternatives as they are invoked from the control window and

indicate improvements that the designer working at the development window can

dynamically incorp orate into the prototyp e

The fourth part of this prototyping paradigm is the instrumentation window When we

consider a prototyp e from the engineering p ersp ective it seems natural that the capability exist

to extract p erformance information from the executing program whether it is considered an

exp eriment as in CPP and PLC or a mo del Observing the output at this window the

designer is able to

observe and analyze data extracted from the executing prototyp e including op erational

parameters p erformance indicators and whatever other instrumentation is incorp orated in

to the prototyp e and

track the progress of the prototyp e

TEST AND EVALUATE RBP PLATFORM The second part of our hyp othesis concerns

the exibility of the mo del and the ways in which RBP can b enet the computer software de

velopment pro cess Consideration of this issue is the area in which our work has the p otential

to make a contribution to the b o dy of knowledge in computer science Our goal in this part of

our pro ject is to provide new insights into prototyping and reconguration that can b e used as

reference material for further exp erimentation with the RBP approach

Central to our contention that prototyping can b e more eectively undertaken using our mo del

is the presentation of a caseinp oint We will draw an example from the Baltimore Longitudinal

Study of Aging BLSA which is an ongoing research pro ject of the National Institute on Aging

of the NIH Initiated in this study of human aging has generated a huge database and an

accompanying library of research and administrative software Within the scop e of this computer

system we will demonstrate the solution of a design problem using our RBP approach

The choice of a particular existing problem on which to demonstrate RBP will not however allow

us to generalize ab out the places and situations where RBP metho ds may b e brought to b ear

There are several scho ols of thought on the motivation for prototyping and dierent approaches

to each LSZ For example prototyping may b e for risk reduction PLC or interface design

MC it may b e rapid or evolutionary WK Similarly reconguration technology includes

the asp ects of top ologic geometric and implementational change HP An understanding of

the interactions of these factors will b e aorded by observation of our RBP mo del as it p ertains

to b oth our BLSA example and other situations We may nd in the exercise of our RBP

mo del that certain reconguration options combine dierently with prototyping metho dologies

and that these combinations are more or less eective dep ending on the goal of the prototyping

eort Of particular value to the eld of computer science would b e a classication that could b e

employed as reference material for these areas of design Our ob jective is to assemble and deliver

such a reference

We are going to do this by testing congurations and using what we learn to p opulate a table of

results We will assemble a series of practical software development scenarios and examine them

to determine what typ es of prototyping metho d and goal are called for we will decide which

facets of reconguration are applicable Then we will use our mo del to simulate each situation

and extract information ab out p erformance under these conditions We exp ect that we will b e

able to construct a three dimensional grid that will serve as a guide to the appropriateness of our

RBP proto col

The axes of this grid will b e prototyping metho d prototyping goal and reconguration

options

As noted ab ove the values along the prototyping metho d axis will include rapid and evo

lutionary the values along the prototyping goal axis will include risk reduction interface

design algorithm renement and eciency optimization and the values along the recon

guration axis will include top ology geometry and implementation

The cells of the grid will provide an indication of how much advantage might b e gained by

using the RBP proto col in this situation

Further cell content will give an indication of the circumstances under which an application

might lo cate in this cell

We b elieve that this taxonomy will provide an insight and guide to the utilization of prototyping

reconguration and RBP Once a draft of this guide is assembled we can apply it to the BLSA

examples In so doing we will b e able to rene the information so that other investigators can

exp eriment indep endently with RBP

CONCLUSIONS

We have briey discussed and illustrated the b enets that can b e had by bringing dynamic

reconguration technologies to b ear on the task of prototyping We have seen that there are

areas relating to ne tuning of algorithms as well as coarse tuning of metho dologies that can b e

facilitated if a software develop er has the p ower to mo dify executing software in place

We have describ ed a metho dology which will allow a designer to include the user in the renement

of design sp ecications in a manner to reduce the uncertainties of the nal design We have made

the prop osition that we can dene the technology necessary to implement these proto cols

In supp ort of this thesis we have intro duced the M Technology as a p owerful platform which

provides the capabilities to make real time mo dications to software without in most cases the

need to stop and restart Rather than losing the steadystate it is preserved and execution can

pro ceed unimp eded

Finally we have describ ed a conguration in which the RBP metho d is b eing implemented

tested and evaluated The outcome of this research will b e a taxonomy that will serve as a guide

to the further use and renement of recongurationbased prototyping

REFERENCES

CPP Chen Chen Adam Porter and James Purtilo To ol Supp ort for Tailored Software Pro

totyping Pro ceedings of Symp osium on Assessment of Quality Software Development

To ols pp June

FD Daniel A Fern and Scott W Donaldson TriCycle A Prototyp e Metho dology for

Advanced Software Development Pro ceedings of the Hawaii International Conference

on System Sciences vol pp January

HP Christine Hofmeister and James Purtilo A Framework for Dynamic Reconguration

of Distributed Programs Computer Science Technical Rep ort Series CSTR De

partment of Computer Science University of Maryland August

KM Je Kramer and Je Magee The Evolving Philosophers Problem Dynamic Change

Management IEEE Transactions on Software Engineering vol no pp

LSZ Horst Lichter Matthias SchneiderHufschmidt and Heinz Zullighoven Prototyping in

Industrial Software Pro jects Bridging the Gap Between Theory and Practice Pro ceed

ings of the th International Conference on Software Engineering pp May

MC R E A Mason and T T Carey Prototyping Interactive Information Systems Com

munications of the ACM vol no pp

PLC James Purtilo Aaron Larson and Je Clark A Metho dology for PrototypingInThe

Large Pro ceedings of the th International Conference on Software Engineering pp

May

PFW James Purtilo Charles Falkenb erg Elizab eth White William Andersen and Tess

Ollove An Exercise with Prototyping Technology

Pur James Purtilo Dynamic software reconguration supp orts scientic problemsolving

activities Invited pap er Pro ceedings of IFIP Conference on Programming Environ

ments and HighLevel Scientic Problem Solving Septemb er Also app ears in

IFIP Transactions edGaney and Houstis North Holland pp

WK David P Wo o d and Kyo C Kang A Classication and Bibliography of Software

Prototyping Technical Rep ort CMUSEITR Software Engineering Institute

Carnegie Mellon University April