Anda di halaman 1dari 15

830

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987

A Conceptual Analysis of the Draco Approach to

Constructing Software Systems

PETER FREEMAN, MEMBER, IEEE

Abstract-This paper analyzes theconcepts ofsoftware construction

embodied in the Draco approach. The analysis relates specific aspects of Draco to particular software engineering (SE) principles and sug- gests future research needed to extend the approach. The purpose of

this analysis isto help researchers understand Draco better and thus to enhance future research.

Index Terms-Domain-based development, reusability, SE princi-

ples, transformational development.

CONSTRAINTS REQUIRaAeMNT,

TWFORM.ATION

ON tHIS TASr. Kpi-

 

PERFORZM SE

IWFORAKflO

TASK

FFROM1PREV~

TASKS

tR.ESUL.TS

INFORMATgON

USEFUL. iN FuJ-URe

SS SFFCrTS

Fig. 1. Central idea ofreusable software engineering.

I. CONTEXT

DRACO [15], [16], [17] is an approach to the co-n- struction of similar software systems from reusable

software components. A prototype ofa tool based on the

approach has been built and its usage is being explored. The principles of the approach are being further devel- opedinthecontext ofabroaderefforttoimproveourabil- ity to reuse previous software engineering results [11].

ThispartofthepaperdescribesthecontextinwhichDraco

exists.

  • A. Reusable Software Engineering Thetwinforcesofescalatingcostsanddemands forim-

proved quality have driven the creation of new software development technology foralmost 20 years [6], [4], [8]. Whilecost (bothinitialandlifetime)hasbeen theprimary driver, the demand for increased quality in software-in-

tensive systems isemerging asanequally importantforce.

Reusable software engineering [9], [11] isone way ofad- dressing these concerns.

Fig. 1 presents the fundamental concept of reusable software engineering. Any software engineering activity

(the analysis ofrequirements, creation ofa design, plan- ning-ofa series oftests, and so on) should be organized

and based on principles that permit and encourage two

specific subactivities-the explicit use ofinformation de- veloped in a previous occurrence of the activity and the creation of information (in addition to the immediate workproduct) thatmay be reused ina laterinstanceofthe

activity.

Manuscript receivedOctober31, 1984; revisedJuly 31, 1986. This work was supported by the National Science Foundation under Grant MCS-83- 4439 from theSoftware Engineering program oftheDivisionofComputing

Activities.

The author is with the Department of Information and Computer Sci-

ence, University ofCalifornia, Irline, CA 92717.

IEEE Log Number 8714560.

The prima'y objectiveofreusable softwareengineering is to reduce the system-lifecycle cost and improve the quality of systems. This objective includes the specific goals ofreusing designs as well as code, capturing prob- lem-domain information ina manner thatpermits itseasy reuse, avoiding redundant work wherever possible, and amortizing thecost ofapieceofsoftwareoverthelargest

possible number of systems. We and others are working

towardfulfillingtheseobjectivesinvariousways [1], [14].

The Draco approach, a specific paradigm, permits the

reuse ofanalysis (by capturing understanding in domain-

specific languages) and the reuse of design (in the com-

ponents that implement the languages). A broad under- standing ofDraco however, must include this largercon- text of reusable software engineering that motivates our

work on it.

B. Supporting Technologies

The Draco approach utilizes several notions from com- puter science and software engineering including:

* meta-compiler techniques,

* high-level languages, * refinement into lower-level languages,

* modeling application domains,

* source-to-source program transformations,

* software components.

While these concepts have been explored and utilized

in countless ways, Draco brings them together in a new

and productive way. As we analyze Draco, bear in mind

that itexists in the context ofthese technologies.

C. Paper Overview

This paper analyzes the Draco approach and places it in a spectrum of software engineering/computer science

concepts and objectives. While practitioners may be in-

terested in the approach, our intended audience is com-

0098-5589/87/0700-0830$01.00 © 1987 IEEE

FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS

831

posed ofresearchers interested in further development of the concepts embodied in Draco. Neighbors' thesis has been widely distributed and still provides themost detailedpublished descriptionofDraco.

Reference [17] provides a summary while [16] provides operational information on Draco. Our paper has four additional sections and an Appen- dix. Section II provides an overview of the Draco ap-

proach, explains the operational context inwhich itis in-

tended to be used (which is further detailed in the

Appendix), defines several key roles involved initsusage,

and discusses the operational status of the experimental

tool. Section III analyzes Draco from the standpoint of

the primary concepts on which it is based and their rela-

tionship to SE objectives. Sections IV and V discuss our

interpretation of results and suggest paths for further de- velopment of the Draco approach to software construc-

tion.

II. DESCRIPTION

Inthissectionwe willreview what Draco does and how it does it (see [15] and [17], for more detail). This de- scription, although brief, will permit you to understand our analysis oftheunderlying technology even ifyou have not read the earlierpapers. The Draco paradigm can be viewed, and thus charac- terized, from several viewpoints. The original motivation for itsdevelopment was to provide a way ofconstructing software systems from preexisting components not nec- essarily constructed with a particular target system in mind. A closely alliedviewpoint isthatitisan extendable program generator; that is, that the tool itself plus a set ofdomains can beconfiguredto generate a classofsimilar software systems ofa specific kind, but thatthe class can

be easily changed. (Another way of stating this particular

characterization is to considerita program-generator gen-

erator.) A third view is that it permits one to build an open-ended set of specification languages to be utilized with itsmechanism fortransforming specifications intoan executable form. Two things should be kept in mind as you read this pa-

per. First, all of these viewpoints are accurate, simply expressing different characterizations of the same thing'.

Second, a cleardistinction should be maintained between

theDracoapproach, orparadigm, andtheDracotool. The approach includes a number ofthings not included in the tool (for example, how to obtain the information needed to define a specification language), and a particular ver- sion of the tool (such as our current prototype) may im- plementcertainfacetsoftheparadigm in particularways.

Our focus here will primarily be on those aspects of the

paradigm thatwe are reasonably confident can be realized in a tool, although not necessarily the specific one on which we are currently working. In addition to its functional operation, one should un-

derstand theorganizational setting envisioned forDraco's

deployment (as this is somewhat different from "tradi- tional" software engineering tools and techniques). This

is illustrated ina partial SADTT model intheAppendix.1 Several assumptions about Draco must be made explicit:

* Draco is intended for use in situations in which nu- merous, similar systems will be created over time (e.g.,

payroll systems, project scheduling systems, educational

programs, etc.); * For a given application domain (e.g., statistical re- port generation) an analysis ofthis domain must be made and defined to Draco before it can be used to generate programs in the domain; * Draco isnotafullyautomaticprogram generator, but

rather aids the system creator in an interactive manner. (The amount of interaction can be kept small, however,

thru the use of a rudimentary "surrogate designer" con-

cept called tactics.)

  • A. What Does Draco Do?

From the standpoint ofsoftwaretechnology, Draco can be viewed as a system thatprovides two main functions:

1) the definition and implementation oflanguages ofvar- ious types (properly viewed as specification languages) and 2) assistance in and partial automation ofthe task of

refining a specification of a desired system (given in one

ofthe languages known to Draco) into another language, presumably more concrete or executable, (also known to

Draco). Draco provides assistance inoptimizing the pro- grams produced, managing the librariesoflanguages and

their implementations, and performing other housekeep- ing details. Fig. 2 represents the main functionality of

Draco. The use of Draco can be understood by studying Fig. 3, starting at the top left of the diagram. Ifit is decided that it is worth the investment to provide Draco the ca-

pability of dealing with programs for a specific applica- tion domain (call itA), then a domain analysis is carried out by a highly skilled analyst (called adomain analyst). A domain analysis can be viewed loosely as a generali-

zation of the classical systems-analysis activity that

precedes development of a computerized system: a sys-

tems analyst studies particular instances in which a com- puterized system is to operate, identifying the data ele-

ments and processes thatare tobe computerized. A more

precise characterization is that domain analysis is a pro-

cess offormulating a limited theoryoftheapplicationdo-

main.

IntheDraco realm, a classofsituations isstudied(Step 1) (each one of which might be a candidate for comput-

erization) in orderto identify allofthe objects (data) and operations (processes) that exist in any situation belong- ing to this domain. The result of this domain analysis is

a description oftheobjects, operations, and relationships

that are needed to specify systems inthatdomain.

The next actorthat isinvolved is adomain designer, a

language designer who also understands how to build the domain definitionsthatmust be giventoDraco. He or she

MSADT is a trademark of SofTech, Inc.

'Due to Neighbors [15].

832

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987

LAWGUAG e

DF-FtN1X10NS

(EN-eRED

PER

LANGUAGE)

ONCE

SPECIFICATIONS

DFIDNIED

LANG6UPAGEzS

(C-NTF-ItED

PENR

0W-Z

CREATeD)

SYSTEM

DRAC

XcvtAL

SPE&C4PV4)

Sys-re-M

(110lT-PLEVERSIONS

POSSI

eLE)

Fig. 2. Primary function ofDraco.

APPLACATIOlb4

DOMA&s~ ~ ~

(

~\ /

,

-

PO,'A9N ANALYST

DOAI

A

-ALN

T

\

IAStV3 PC~~~~~~~stex~peri'encp

tSe

ProQbSCVV does. DD)MAIN

wi+h

~~~~~~~ANALySIS

)D0MAIN DESI1jNER

o USer/Customer

f6rc,

XnIirhe

Sys-teri

appl

ic"tno

Dcwnain A-l

\

APPLICATIONS

-

SPCA LlSr

y

(ffi)

/

Uts%

%reMUt

cand

thc necds

n+s

a

and

f -the

/ng

user

*ret aneysis of

w,4ncriWoAAn of J,hC

oi

iOt

iPi

&

SY$,TEb

LefinIe

Y.NIN

_

DrFINI11ON AND

DE-FINIT)ON

LOPE

RA-i

AND>

oNs

mec.g,oJ,sm k4iow

cdes'gns

g

a

aLnAap

ed(ge-

_

-

_

/

MAN

81

_arserfoe_ Wrn9Lage

Pret4yprin*er for LA

_

LA (Synt-as)

m

-COmpontnt L

*t~~~~~~~~~Wih

1efiefflent Foe LA

brary

o

L . Transforrp-ons, fD

|

h

IACOExrECuTA1bL.E

x

'

IoI

SVsIr-Te t

LEGEND: D- executable programs

Cl-

otr represew)tAtiov)-s

V)c**~cjLu-~e w;jcbcd-c'

rothes

tliav

ujF41&-

d:ed- mwYpauk-hlbv

$;

i PRACO SYSTEMS

DES I QN e

uskng

knrowlecdge

o thfeenvrnrsvov+nianc

uCdre

relAirE4

Srenefs rnee1s

**

perfomcanceneeds,

t+Wt4 +aCti>s

or

srerr\csi9n

rterac,h1Or

*e dCSign Ln *ne component

Fig. 3. Organizational'contextand usage of Draco.

then takes the domain analysis (the list of objects, oper-

ations, and relationships, coupled with theirsemantic def- initions) and defines a language incorporating them (Step

2) which forms theexternal aspect ofa domain definition. Itis sufficient to think ofthis as a high-level specification

language for systems in that particular application do-

main. For example, we can envision a wide spectrum of

have domains for the specification of systems. These might range from very low-level "computer science" do-

mains (e.g., binary arithmetic) to broader service do-

mains (e.g., operating systems, database management

systems) to even more encompassing, (yet specific user oriented), application domains (e.g., navigation control)

which integrate and reuse intermediate and lower-level domains. At thisjunction (forgetting forthe moment thatthe do- main analysis and design activities may have to be reiter-

ated just like any other design and analysis activities),

Draco is ready to be used to help generate systems foruse

in this particular application domain. We say that Draco

isnow operational in theA domain.

Suppose now that a Draco applications specialist is

called upon to create an A type system for some specific

situation (not necessarily one of those originally investi-

gated for the domain analysis). He or she will perform a

traditional requirements analysis and definition condi-

tioned by the existence of the specification languages available in Draco. Their next step, however, will begin

touse Draco explicitlyby specifyingthesystem to becre-

atedusingthedomain languageLA forapplicationdomain

A (Step3). Thissystem specificationisthenfedintoDraco by a Draco systems designer skilled in the technical use of Draco; this person guides Draco in the production of

theexecutable code (Step4). The executable code isthen ready forinstallation inthe user environment.

So farin our description we have ignored a number of important and in some cases difficult aspects of systems development using Draco. What ifDraco cannot produce

FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS

833

'3

AI 8 C.

0a A J B

-

'1.

|ANALYSIS|plkFIWITION

I

I

DOM4AN

DOhKIA

I

IR

iC

*4 AI B

C

A- APPLICATION ANALysIs

*5s A

C

*S Al E1 C

0

TiME

B- APPLICATION SPeCIPIrATiON IN DONiAIN LANGUAG.

C- GERNERATION OF APPLiCAlION SYSTeM

Fig. 4. Summary of Draco usage.

asystem because ofconstraints encountered inproducing

executable code, even though a syntactically legal input specificationisgiven?What isdone ifchangesaredesired

inthetarget system atsome laterdate? Clearly, these are

importantconcerns; however, thisidealizedanderror-free usage pattern will suffice forourdiscussions here. Fig. 4 summarizes the steps of Draco usage. After a domain iscreated (and validated) Draco isused anumber oftimes (often inparallel) over a long period ofelapsed

time to develop specific application systems ofa particu- lartype. This figure should actually be replicated a num- beroftimes, one foreach domain.

  • B. How Does Draco Work?

Pursuing the model of Draco given in Fig. 2-a black

box thattakes system specifications written in high-level languages (domain languages) and produces executable (or compilable) code-we will now indicate briefly how this is done. Note firstthat there are two distinct phases

of Draco operation: domain definition and specification

refinement.

A domain language is defined in Draco during the do-

main definition phase, using meta-compiler techniques similartotheMETA-II procedures describedin[23]. The design ofthe domain language, and, even more, the de- termination of its semantics are nontrivial tasks. Indeed, we believe that is the area where the greatest need for

researchexistsand iswhere we arepresentlyfocusingour

attention. In this paper, however, we will not be further concerned with the domain-definition phase. In order to understand the operation of Draco in the specification refinement phase, let us look at its internal

logical structure. Fig. 5 portrays the four elements of a Draco domain description: a parser definition which de-

scribes how Draco isto recognize and translate sentences expressed in the domain's language to an internal form

which Draco can subsequently manipulate; aprettyprinter

definition which describes the reverse mapping-Draco

internal form to sentences in a particular domain lan-

guage; a set of transformations used to optimize or oth- erwise change expressions in the language, and a set of components thatprovide the semantics ofthelanguage.

Thesecomponents arethekeytoDraco's abilitytogen- eratecode. Essentially, thereisacomponent foreach op-

eration and each object in the domain language that cap- tures the behavior (semantics) expressed by that element of the language; in fact, there may be multiple require- ments (instantiations) forasingleelement, corresponding

Fig. 5. Elements ofa domain.

to different performance characteristics (e.g., a "fast"

versus a "slow and more accurate" implementation).

Thus, eachcomponent (alongwithitsassociatedlanguage element) isessentiallyan abstractdatatype(possiblywith several performance choices). Each of these code fragments (or set of data declara- tions) may be written in any language known to Draco, including the language of the domain itself. As noted above, there may be several refinements (implementa-

tions) for each

element of the domain language (we are

using "domain language" and "specification language"

interchangeably) which can be chosen depending on the

objectives of a particular

system
saythatthecomponentprovidesarefinement2ofthepar-

construction task. We

ticularconstruct inthelanguage intothe otherlanguage.

The transformations are used to change the form ofan expression in a domain language either to gain a desired

performance characteristic (e.g., greater accuracy at the

expense ofspeed) orto put itina form more amenable to

refinementintoanotherdomain. This ofteninvolves strip-

pingaway generality ofa component not needed ina spe- cificinstance. The basic logic ofDraco's specificationrefinementcan

now be easily described. Given a system specification in

a particular domain language, appropriate parts of the

specification are chosen for refinement and a refinement

applied. Assuming this can be done (no constraints are violated) this refinement results in a new specification in

which some parts ofthe original specification have been

logically replaced by their refinements. This process is iterated until the entire specification is expressed in the

desiredtarget domain (usually one whose language isex-

ecutable) orappropriate refinements cannot be found (for example, when a refinement does not existthatmeets the

desired performance criteria). This logic is displayed in

Fig. 6. A final characterization can be offered at this point:

Draco is a production system in which the production/

transformation base is modularized by domain-specific knowledge. Thisdomain-basedapproachtoorganizingthe

transformation process makes Draco ratherdifferentfrom mosttransformation systems, withtheexceptionof4NIX

[3].

2Whatwecall"refinements"inDracocorrespondtowhattheliterature

in transformational systems [18] call "transformations." In Draco we re-

servethatterm foroptimizingtransformations.

834

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987

ACCEPT SYSTErM

SPECIFICATION

IN KNOVVNJ LANGUAGE

REFINEMENT INTO

LOWER- LEVEA- DONMAIN - PO SSIBLE ?

REFINE UNDER

DESIGNER GVIDANCE

EXECUTABLE CODE

AcHkIEVED Fox ENrNRE

FAIL

succe.ED

Fig. 6. Logic ofDraco's operation.-

III. CONCEPTUAL ANALYSIS OF DRACO

Artifacts are often described as though they have been

derivedfromprinciplesinatop-downfashioneven though

that is seldom the way things happen. Thus, itis impor-

tanttounderstandthatwe aretryingtoexplainthereasons underlying Draco inan expostfactomanner, notdescrib- ing precisely how it was created in the first place. Our

analysis centers on showing the relationship between six important SE objectives and four primary mechanisms

found in Draco.

  • A. Conceptual Context ofDraco

Softwareengineering isconcernedwithanumberofob- jectives, including:

* meeting currentcustomer/user needs economically; * increasing system quality; * providing tools to increase the intellectual capabili-

ties ofsystem developers inorderto meet furtherneeds; * increasing productivity ofdesigners. A number of approaches are being pursued to reach these objectives, including the creation ofsoftware engi- neering environments, the application ofartificial intelli-

gence techniques, retraining of personnel, development

of automated tools, utilization of mathematical tech-

niques, and so on. The Draco technology combines as-

pects ofseveral areas.

In general terms, Draco is the result of a long-range

attempt tobuilda production-quality tool fortheworking

softwareengineer. Itincorporatesimportantconcepts from

several areas, including language design, language trans- lation, information modeling, specificationmethods, heu- ristic techniques, and automatic programming. It is an- chored in the traditional system specification and code

production phases ofthelifecycle, butradicallyaltersthe intervening stages. In terms of reusability, it provides a mechanism that

facilitates the reuse ofthe results ofanalysis and design.

Specifically, we are able to capture and reuse a deep un-

derstanding of an application area (analysis information)

through the design and utilization of domain languages,

whiledesignknowledge iscaptured inthecomponents that provide the semantics ofthe domain languages. Although

thiscan bedonewithoutDraco (forexample, innumerous specializedapplications sytems, such as SPSS) thepoten-

tialpower ofDraco isthatitfacilitatesthis form ofreuse.

The following sections will make these connections more explicit.

  • B. Conceptual Objectives

We listed several objectives of software engineering above. These are utilization, or external, objectives ofSE in that they relate to the activity of creating software-in- tensive systems for some larger reason. In working with SE as a discipline, we usually focus on a set of internal concepts that we want SE techniques to possess. These desirable conceptual properties of a SE artifact apply to

Draco. Expressing itanother way, there are an established set of properties that it is believed the practice of software

engineering should have in order to reach the utilization

objectives mentioned above. For example, itis generally accepted that if an SE technique helps us use levels of abstraction that this will advance us toward our goal of

dealing with complexity.

Our primary mode of analysis in this section is to es-

tablisha set ofinternalconceptual objectivesthatwe want to reach and then show how Draco contributes to those objectives. Ourpurpose indoing thisisto evaluateif,and

in what ways,

Draco is a useful SE tool. (Attainment of

the utilization objectives of lower cost, and so on, will

provide the definitive answer to this question; however, that analysis takes much longer to achieve and does not provide information on the source ofDraco's power.)

We have chosen a six-partconceptual frameworkto an- chor our analysis on:

1) AbstractionLevels: Beingabletoabstractfroma sit- uation and deal only with a name that stands fora partic- ularpiece ofthe complexity ofthe situation isa key con-

cept in almost

all of SE. Coupling that with hierarchy is

a standard and necessary aspect of systems work.

2) StructureofProducts: Thesoftwareartifactsthatwe

create must have structure to permit us to modify them,

measure them, and fitthem with othersystems. A goal of most SE isto produce well-structured systems. This con- cept is usually interpreted in a broad fashion so that it includes a number ofdefinitions of "good" structure.

3) SystematicProcesses: A keyprincipleinallaspects

of software engineering is that of doing things in a sys-

tematic, well-ordered way.

4) Modeling: The invisibility ofsoftware forces us to

do allofour SE work through themanipulation ofmodels ofthe actual machine states we wish to create; this basic factextends allthe way back to the requirements analysis activity in which we build models of real-world situa- tions.

5) Compartmentalization of Knowledge: One of the

primary contributors of complexity isthe fact that at any

FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS

835

 

MECHRAIINISS

UlSED

iN DRACO

CONCEPTUAL multiple hi-level components/ transformations

refinements

OBJECTIVES

specialized

assemblies

specification

languages

 

permit

 

provide

capture

specifications

abstraction

references

implement

relations

at one level to

levels

(names)

levels

between

be converted to

to levels

abstractions

another level

shifts

structure

alters

force

concerns from

traceability

structure

structuring

structure

code to

of

at the

of

specifications

individual

specification

products

parts

level

 

provide

provide

perm-it

permit

systematic

explicit

focus for

optimizations

breakup

process

starting

design

in

ofprocess

point

assurance

controlled

into small

 

ways

steps

 

direct

provide

provide

provide

representation

change of

for

for

modeling

ofobjects

representation

customiza-

change to

and operations

ofexternal

tionof

different

to be

objects

representations

nodeling

modeled

levels

compartment-

focus

design

capture

pernmit

alization

language

knowledge

optimization

knowledge

of

on

captured

information

to be

knowledge

problem

invery

grouped

at hand

small pieces

by level

captures

captures

captures

captures

reusability

analysis

design

optimization

alternative

information

information

information

performance

 

aspects

Fig. 7. How Draco mechanisms relate to conceptual objectives.

point in development there are many separate pieces of knowledge orinformation thatmay potentiallybearon the

decisions that must be made. A successful strategy is to

break the applicable knowledge up into subsets that per- mit one to deal with less information. 6) Reusability: Standard engineering practice in other fields is to reuse parts, assemblies, tests, and techniques wherever possible. The same philosophy can be applied to software engineering as described above.

We assume thatthe widespread acceptance ofthese ob-

jectives demonstrates their importance to software engi-

neering. Our task in the remainder of this section is to

demonstrate in what specific ways Draco meets these ob-

jectives.

  • C. Analysis ofDraco Mechanisms

Fig. 7 presents a summary of our analysis of how the

mechanisms ofDraco contribute to certain SE objectives.

For each offourmain mechanisms in Draco, theircontri- bution to each of six specific SE objectives is analyzed.

The remainder of this section presents our analysis by mechanism. 1) Multiple High-Level Languages:

Abstraction Levels: Simple programming languages provide for a single level of abstraction in describing computations via subroutine of function calls; this some-

what rudimentary level in the past was often further re-

duced ineffectivenessbecause ofthe restrictions inlength

and format of the identifiers that could be used. Some

more modem languages (for example Ada^) have im- proved this situation by providing mechanisms for creat- ing and naming new operations and operands; the naming capabilities, however, are still within the confines of the syntax and semantics ofthe host language. Draco permits a network of domain connections. This

fully supports the concept of levels of abstraction, since one can build up an arbitrary hierarchy of independent languages corresponding to whatever hierarchy of ab-

straction levels is desired. The network of languages in Draco is not itself a strict hierarchy, however, in which things are implemented only on lower levels. For example, conceptually it might be desirable from

a SE 'perspective to establish levels of abstraction cor-

responding to arbitrary algebraic computations, calcula- tions on data sets ofreal numbers, statistical calculations,

and statistical calculations on sets ofreadings from a par- ticular class of sensors. Draco would easily provide for this through the creation of individual domain languages corresponding to each levelofconceptual abstraction. Fig. 8 portrays this situation and illustrates how the languages created might be utilized in the realization of several do-

mains other than the one initially desired. If one had to create an entire new language for each

new level of abstraction, itwould be a definite disadvan- tage.3 This is the central reason that Draco is