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 the concepts of software construction CONSTRAINTS REQUIRaAeMNT,

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 is to help researchers understand Draco better and thus TWFORM.ATION
to enhance future research. ON tHIS TASr.Ki-p tR.ESUL.TS
PERFORZM SE
IWFORAKflO TASK INFORMATgON
Index Terms-Domain-based development, reusability, SE princi- FFROM1PREV~ USEFUL. iN FuJ-URe
ples, transformational development. TASKS SS SFFCrTS
Fig. 1. Central idea of reusable software engineering.

I. CONTEXT
The prima'y objective of reusable software engineering
DRACO [15], [16], [17] is an approach to the co-n- is to reduce the system-lifecycle cost and improve the
struction of similar software systems from reusable quality of systems. This objective includes the specific
software components. A prototype of a tool based on the goals of reusing designs as well as code, capturing prob-
approach has been built and its usage is being explored. lem-domain information in a manner that permits its easy
The principles of the approach are being further devel- reuse, avoiding redundant work wherever possible, and
oped in the context of a broader effort to improve our abil- amortizing the cost of a piece of software over the largest
ity to reuse previous software engineering results [11]. possible number of systems. We and others are working
This part of the paper describes the context in which Draco toward fulfilling these objectives in various ways [1], [14].
exists. The Draco approach, a specific paradigm, permits the
A. Reusable Software Engineering reuse of analysis (by capturing understanding in domain-
specific languages) and the reuse of design (in the com-
The twin forces of escalating costs and demands for im- ponents that implement the languages). A broad under-
proved quality have driven the creation of new software standing of Draco however, must include this larger con-
development technology for almost 20 years [6], [4], [8]. text of reusable software engineering that motivates our
While cost (both initial and lifetime) has been the primary work on it.
driver, the demand for increased quality in software-in-
tensive systems is emerging as an equally important force. B. Supporting Technologies
Reusable software engineering [9], [11] is one way of ad- The Draco approach utilizes several notions from com-
dressing these concerns. puter science and software engineering including:
Fig. 1 presents the fundamental concept of reusable
software engineering. Any software engineering activity * meta-compiler techniques,
(the analysis of requirements, creation of a design, plan- * high-level languages,
ning -of a series of tests, and so on) should be organized * refinement into lower-level languages,
and based on principles that permit and encourage two * modeling application domains,
specific subactivities-the explicit use of information de- * source-to-source program transformations,
veloped in a previous occurrence of the activity and the * software components.
creation of information (in addition to the immediate While these concepts have been explored and utilized
workproduct) that may be reused in a later instance of the in countless ways, Draco brings them together in a new
activity. and productive way. As we analyze Draco, bear in mind
that it exists in the context of these technologies.
Manuscript received October 31, 1984; revised July 31, 1986. This work C. Paper Overview
was supported by the National Science Foundation under Grant MCS-83-
4439 from the Software Engineering program of the Division of Computing This paper analyzes the Draco approach and places it
Activities. in a spectrum of software engineering/computer science
The author is with the Department of Information and Computer Sci-
ence, University of California, Irline, CA 92717. concepts and objectives. While practitioners may be in-
IEEE Log Number 8714560. 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
posed of researchers interested in further development of
the concepts embodied in Draco.
Neighbors' thesis has been widely distributed and still
provides the most detailed published description of Draco.
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 in which it is in-
tended to be used (which is further detailed in the
Appendix), defines several key roles involved in its usage,
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
In this section we will review 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 of the underlying technology even if you have
not read the earlier papers.
The Draco paradigm can be viewed, and thus charac-
terized, from several viewpoints. The original motivation
for its development was to provide a way of constructing
software systems from preexisting components not nec-
essarily constructed with a particular target system in
mind. A closely allied viewpoint is that it is an extendable
program generator; that is, that the tool itself plus a set
of domains can be configured to generate a class of similar
software systems of a specific kind, but that the class can
be easily changed. (Another way of stating this particular
characterization is to consider it a 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 its mechanism for transforming specifications into an
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 clear distinction should be maintained between
the Draco approach, or paradigm, and the Draco tool. The
approach includes a number of things 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-
plement certain facets of the paradigm in particular ways.
Our focus here will primarily be on those aspects of the
paradigm that we 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 the organizational setting envisioned for Draco's
deployment (as this is somewhat different from "tradi-
tional" software engineering tools and techniques). This
831
is illustrated in a partial SADTT model in the Appendix.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 of this domain must be made
and defined to Draco before it can be used to generate
programs in the domain;
* Draco is not a fully automatic program 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 of software technology, Draco can
be viewed as a system that provides two main functions:
1) the definition and implementation of languages of var-
ious types (properly viewed as specification languages)
and 2) assistance in and partial automation of the task of
refining a specification of a desired system (given in one
of the languages known to Draco) into another language,
presumably more concrete or executable, (also known to
Draco). Draco provides assistance in optimizing the pro-
grams produced, managing the libraries of languages 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. If it 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 it A), then a domain analysis is carried
out by a highly skilled analyst (called a domain 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 that are to be computerized. A more
precise characterization is that domain analysis is a pro-
cess of formulating a limited theory of the application do-
main.
In the Draco realm, a class of situations is studied (Step
1) (each one of which might be a candidate for comput-
erization) in order to identify all of the objects (data) and
operations (processes) that exist in any situation belong-
ing to this domain. The result of this domain analysis is
a description of the objects, operations, and relationships
that are needed to specify systems in that domain.
The next actor that is involved is a domain designer, a
language designer who also understands how to build the
domain definitions that must be given to Draco. 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-FtN 1X 10NS
(EN-eRED ONCE
PER LANGUAGE)

SPECIFICATIONS DRAC XcvtAL

DFIDNIED SPE&C4 PV 4)
LA NG6UPAG EzS Sys-re-M
(C-NTF-ItED 0W-Z (110lT-PLE VERSIONS
PENR SYSTEM POSS I eLE)
CREATeD)
Fig. 2. Primary function of Draco.

DOMA&s~ ~ ~
APPLACATIOlb4 -ALN
PO,'A9N ANALYST
DOAI A T

~\ / -
tSeIAStV3 PC~~~~~~~stex~peri'encp
ProQbSCVV does. DD)MA wi+h
IN )D0MAIN DESI1jNER
( , \ ~~~~~~~ANALySIS

DrFINI11ON AND
DE-FINIT)ON AND> mec.g,oJ,sm
cdes'gns
g a
k4iow ed(ge-
aLnAap
LOPE RA-i oNs

o USer/ Customer f6r c,

Iirhe
Sys-teri Xn
appl ic"tno
Dcwnain A-l MAN
\ _ - _
_arser foe_ Wrn9Lage
_ LA (Synt-as)
Pret4yprin*er for LA
APPLICATIONS - m
81 -COmpontnt
S PCA LlS r L brary
y (ffi) / *t~~~~~~~~~Wih 1efiefflent Foe LA
Uts%
/ %re
thc necds and
a
MUt n+s f -the user
. o
L
Transforrp-ons, fD h
cand /ng
*ret aneysis of _
w,4ncriWoAAn of J,hC |

iOt
oi i Pi S Y$,TEb
Lef in Ie
&
Y.NIN x
IACOExrECuTA1bL.E
' SVsIr-Te t
IoI

LEGEND: D- executable programs $; i PRACO SYSTE MS

Cl- otr represew)tAtiov)-s
V)c**~cj Lu-~e w;jcbcd-c' ujF41&-
rothes tliav d:ed- mwYpauk-hlbv
Fig. 3.
DESI QNe
uskng knrowlecdgeuC
o thfe envrnrsvov+ni anc perfomcance needs,
** t+Wt4 +aCti>s or
srerr\csi9n dre S renefs rnee1s
rterac,h1Or relAirE4 *e dCSign Ln *ne component
Organizational'context and usage of Draco.

then takes the domain analysis (the list of objects, oper-
ations, and relationships, coupled with their semantic def-
initions) and defines a language incorporating them (Step
2) which forms the external aspect of a domain definition.
It is sufficient to think of this 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 this junction (forgetting for the moment that the 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 for use
in this particular application domain. We say that Draco
is now operational in the A 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
to use Draco explicitly by specifying the system to be cre-
ated using the domain language LA for application domain
A (Step 3). This system specification is then fed into Draco
by a Draco systems designer skilled in the technical use
of Draco; this person guides Draco in the production of
the executable code (Step 4). The executable code is then
ready for installation in the user environment.
So far in our description we have ignored a number of
important and in some cases difficult aspects of systems
development using Draco. What if Draco cannot produce
FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS
'3 AI 8 C.
0a A J B iC
* 4 AI B C *S Al E1 C
'1.
DOM4AN DOhKIA IR
-
|ANALYSIS |plkFIWITION
I I I TiME
A- APPLICATION ANALysIs
B- APPLICATION SPeCIPIrATiON
C- GERNERATION OF APPLiCAlION SYSTeM
Fig. 4. Summary of Draco usage.
a system because of constraints encountered in producing
executable code, even though a syntactically legal input
specification is given? What is done if changes are desired
in the target system at some later date? Clearly, these are
important concerns; however, this idealized and error-free
usage pattern will suffice for our discussions here.
Fig. 4 summarizes the steps of Draco usage. After a
domain is created (and validated) Draco is used a number
of times (often in parallel) over a long period of elapsed
time to develop specific application systems of a particu-
lar type. This figure should actually be replicated a num-
ber of times, one for each domain.
B. How Does Draco Work?
Pursuing the model of Draco given in Fig. 2-a black
box that takes 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 first that 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
similar to the META-II procedures described in [23]. The
design of the 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
research exists and is where we are presently focusing our
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 is to recognize and translate sentences
expressed in the domain's language to an internal form
which Draco can subsequently manipulate; a pretty printer
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 that provide the semantics of the language.
These components are the key to Draco's ability to gen-
erate code. Essentially, there is a component for each 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) for a single element, corresponding
833
*5s A C
0
IN DONiAIN LANGUAG.
Fig. 5. Elements of a domain.
to different performance characteristics (e.g., a "fast"
versus a "slow and more accurate" implementation).
Thus, each component (along with its associated language
element) is essentially an abstract data type (possibly with
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 construction task. We
say that the component provides a refinement2 of the par-
ticular construct in the language into the other language.
The transformations are used to change the form of an
expression in a domain language either to gain a desired
performance characteristic (e.g., greater accuracy at the
expense of speed) or to put it in a form more amenable to
refinement into another domain. This often involves strip-
ping away generality of a component not needed in a spe-
cific instance.
The basic logic of Draco's specification refinement can
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 of the original specification have been
logically replaced by their refinements. This process is
iterated until the entire specification is expressed in the
desired target domain (usually one whose language is ex-
ecutable) or appropriate refinements cannot be found (for
example, when a refinement does not exist that meets 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. This domain-based approach to organizing the
transformation process makes Draco rather different from
most transformation systems, with the exception of 4NIX
[3].
2What we call "refinements" in Draco correspond to what the literature
in transformational systems [18] call "transformations." In Draco we re-
serve that term for optimizing transformations.
834
ACCEPT SYSTErM
SPECI FICATI ON
IN KNOVVNJ LANGUAGE
REFINEMENT INTO
LOWER- LEVEA- DONMAIN - FAIL
PO SS I BLE ?
REFINE UNDER
DESIGNER GVIDANCE
EXECUTABLE CODE
AcHkIEVED Fox ENrNRE
succe. ED
Fig. 6. Logic of Draco's operation.-
III. CONCEPTUAL ANALYSIS OF DRACO
Artifacts are often described as though they have been
derived from principles in a top-down fashion even though
that is seldom the way things happen. Thus, it is impor-
tant to understand that we are trying to explain the reasons
underlying Draco in an ex post facto manner, not describ-
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 of Draco
Software engineering is concerned with a number of ob-
jectives, including:
* meeting current customer/user needs economically;
* increasing system quality;
* providing tools to increase the intellectual capabili-
ties of system developers in order to meet further needs;
* increasing productivity of designers.
A number of approaches are being pursued to reach
these objectives, including the creation of software engi-
neering environments, the application of artificial intelli-
gence techniques, retraining of personnel, development
of automated tools, utilization of mathematical tech-
niques, and so on. The Draco technology combines as-
pects of several areas.
In general terms, Draco is the result of a long-range
attempt to build a production-quality tool for the working
software engineer. It incorporates important concepts from
several areas, including language design, language trans-
lation, information modeling, specification methods, heu-
ristic techniques, and automatic programming. It is an-
chored in the traditional system specification and code
production phases of the lifecycle, but radically alters the
intervening stages.
In terms of reusability, it provides a mechanism that
facilitates the reuse of the results of analysis 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,
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987
while design knowledge is captured in the components that
provide the semantics of the domain languages. Although
this can be done without Draco (for example, in numerous
specialized applications sytems, such as SPSS) the poten-
tial power of Draco is that it facilitates this form of reuse.
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 of SE
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 it another 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, it is 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-
tablish a set of internal conceptual objectives that we want
to reach and then show how Draco contributes to those
objectives. Our purpose in doing this is to evaluate if, 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 of Draco's power.)
We have chosen a six-part conceptual framework to an-
chor our analysis on:
1) Abstraction Levels: Being able to abstract from a sit-
uation and deal only with a name that stands for a partic-
ular piece of the complexity of the situation is a key con-
cept in almost all of SE. Coupling that with hierarchy is
a standard and necessary aspect of systems work.
2) Structure ofProducts: The software artifacts that we
create must have structure to permit us to modify them,
measure them, and fit them with other systems. A goal of
most SE is to produce well-structured systems. This con-
cept is usually interpreted in a broad fashion so that it
includes a number of definitions of "good" structure.
3) Systematic Processes: A key principle in all aspects
of software engineering is that of doing things in a sys-
tematic, well-ordered way.
4) Modeling: The invisibility of software forces us to
do all of our SE work through the manipulation of models
of the actual machine states we wish to create; this basic
fact extends all the 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 is the fact that at any
FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS 835

MECHRAIINISS UlSED iN DRACO The remainder of this section presents our analysis by
CONCEPTUAL multiple hi-level components/ transformations refinements mechanism.
OBJECTIVES specialized
specification
assemblies 1) Multiple High-Level Languages:
languages Abstraction Levels: Simple programming languages
provide for a single level of abstraction in describing
permit computations via subroutine of function calls; this some-
provide capture specifications
abstraction references implement relations at one level to what rudimentary level in the past was often further re-
levels (names)
to levels
levels between
abstractions
be converted to
another level
duced in effectiveness because of the restrictions in length
and format of the identifiers that could be used. Some
shifts more modem languages (for example Ada^) have im-
structure alters force proved this situation by providing mechanisms for creat-
concerns from traceability structure structuring
structure code to of at the ing and naming new operations and operands; the naming
of specifications individual specification capabilities, however, are still within the confines of the
products parts level
syntax and semantics of the host language.
Draco permits a network of domain connections. This
systematic
provide
explicit
provide
focus for
perm-it
optimizations
permit
breakup
fully supports the concept of levels of abstraction, since
process starting design in of process one can build up an arbitrary hierarchy of independent
point controlled into small
assurance
ways steps languages corresponding to whatever hierarchy of ab-
straction levels is desired. The network of languages in
direct provide provide provide Draco is not itself a strict hierarchy, however, in which
modeling
representation
of objects
change of
representation
for
customiza-
for
change to
things are implemented only on lower levels.
and operations of external tion of different For example, conceptually it might be desirable from
to be objects representations nodeling
modeled levels a SE 'perspective to establish levels of abstraction cor-
responding to arbitrary algebraic computations, calcula-
compartment- focus design capture pernmit tions on data sets of real numbers, statistical calculations,
alization
of
language
on
knowledge
captured
optimization
information
knowledge
to be
and statistical calculations on sets of readings from a par-
knowledge problem in very grouped ticular class of sensors. Draco would easily provide for
at hand small pieces by level
this through the creation of individual domain languages
captures captures captures captures
corresponding to each level of conceptual abstraction. Fig.
reusability analysis design optimization alternative 8 portrays this situation and illustrates how the languages
information information information performance created might be utilized in the realization of several do-
aspects
mains other than the one initially desired.
If one had to create an entire new language for each
Fig. 7. How Draco mechanisms relate to conceptual objectives. new level of abstraction, it would be a definite disadvan-
tage.3 This is the central reason that Draco is not well
suited to one-of-a-kind development situations, but rather
point in development there are many separate pieces of
knowledge or information that may potentially bear on the
decisions that must be made. A successful strategy is to ®Ada is a registered trademark of the U.S. Department of Defense (Ada
Joint Program Office).
break the applicable knowledge up into subsets that per- 3As we gain more experience in creating new domain languages, it is
mit one to deal with less information. becoming clear that one often wants to create a new language out of exist-
6) Reusability: Standard engineering practice in other ing languages. For example, if you has a language for describing statistical
calculations and another language for describing tabular report formating,
fields is to reuse parts, assemblies, tests, and techniques you might well want to create a new language formed by putting these two
wherever possible. The same philosophy can be applied languages together.
to software engineering as described above. Other ways of producing new languages out of existing ones are, for
example, enriching an existing language with new objects, operations or
We assume that the widespread acceptance of these ob- relationships, or restricting (i.e., customizing) existing languages. Formal
jectives demonstrates their importance to software engi- definitions for these types of developments are given in [5].
neering. Our task in the remainder of this section is to The current Draco tool enables us to specify applications using "mixed
notations." That is, syntactic mechanisms are available to use on several
demonstrate in what specific ways Draco meets these ob- domain languages in the same specification. However, the current tool does
jectives. not enforce any semantic consistency among the parts specified using dif-
ferent languages. Extensions to the current tools based on the use of po-
lymorphic types are planned to solve this limitation.
C. Analysis of Draco Mechanisms Because Draco does not have mechanisms for dealing with the interac-
tions between domains at the level of language boundaries, we have pushed
Fig. 7 presents a summary of our analysis of how the the problem of tying domains together outside of the Draco tool itself and
mechanisms of Draco contribute to certain SE objectives. turned it into a language design problem. The designer of a new domain
has the responsibility to create a single notation to handle the syntax of
For each of four main mechanisms in Draco, their contri- underlying domains, While limited thus far, our experience indicates this
bution to each of six specific SE objectives is analyzed. is an effective approach
836 8IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987
Fig. 8. Example of levels of abstraction in Draco domains.
is intended to be used in situations in which the overhead
of creating new languages (corresponding to new levels
of abstraction) will pay off in multiple usage.
The advantage is the ability to create and provide the
linguistic means for manipulating levels of abstraction that
closely correspond to the "natural" levels of conceptual-
ization that are dictated by the problem area and by the
problem solving strategies chosen by the software engi-
neer. Because of the importance of representation in de-
sign [10] and problem solving [211 and the centrality of
levels of abstraction to almost all software engineering,
this is a very important contributor to the power of Draco.
Structure of Products: The essential point is that
when utilizing Draco, one will be concerned with the
structure of the specifications, not the code produced. The
fact that Draco has languages closely fitted to particular
application areas will permit one to focus on structuring
the program in the domain. For example, if the problem
consists of application of three basic operators and seven
suboperations to a variety of objects depending on certain
conditions, this problem structure could be easily mod-
eled in the Draco specification by a domain language that
had those operations, operands, and control structures and
no others.
Systematic Process: The Draco approach provides
and enforces a well-defined and systematic process for
creating a system. The contribution of multiple lan-
guages, specifically, is to provide an explicit representa-
tion for the starting point of development (assuming Draco
has a domain language for that particular area). This is a
very important contribution because one of the softest
areas of development is often the starting point due to the
absence of any way of representing the specifications. The
necessity for representing all of the information for a par-
ticular development thus enforces a systematic process
right from the beginning.
Modeling: The specification languages of Draco pro-
vide for direct modeling of the objects and operations from
the application domain of interest. While in theory we can
always model those entities with any computable lan-
guage, the existence of specialized languages results in
effective ways of carrying out the desired modeling.
Object-oriented programming languages such as Small-
talk-80 extend this even further. Draco languages can be
thought of as capturing the "right" objects for the do-
main, conceptually, if not in the actual implementation
(although nothing prevents a Draco-language from being
a full object-oriented language).
Compartmentalization of Knowledge: The narrow
"width" of the languages of Draco automatically focus
one's attention on a narrow domain of knowledge. This
will help achieve the goal of compartmentalization if the
boundaries of the languages correspond to- "natural"
boundaries of the knowledge. If they do, then the multi-
ple-language feature of Draco will provide a very pow-
erful support of the objective of compartmentalizing
knowledge. This very important aspect of Draco serves to
modularize the transformation base via the domain-spe-
cific knowledge.
Reusability: One of the goals of reusability is to make
it possible to reuse the understanding of a problem or
problem domain developed during the analysis portion of
development. The languages that can be created using
Draco permit the capture and reuse of information about
an entire problem domain. Specifically, the languages
capture the domain analyst's understanding of which op-
FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS 837

erators and objects are appropriate for describing opera- permit us to capture design knowledge (about the imple-
tions in a particular domain. Later, when a system analyst mentation of specific operations and objects) in small
picks up that domain language to use it, he or she is then pieces. They permit us to encapsulate this form of system
reusing the analysis of the domain orginally developed by knowledge in minimally small chunks thus focusing our
the domain analyst. attention. Assemblies of components (that result from
2) Components and Assemblies: their use in a higher-level domain's components) then
Abstraction Levels: Components are used to imple- permit us to expand the size of the chunk as desired. Li-
ment levels. The functionality of the components in a braries of components capture further design information
given level implements the functions of that level (and by storing alternative refinements for operations and ob-
similarly for the objects of the level). Since a component jects.
may be written in terms of objects and operations of a Reusability: Components are the mechanism that
lower level, this provides the connection to lower levels; permit us to capture and reuse design information. Each
similarly, the use of the functions (implemented by a component encapsulates a designer's knowledge about
component) at a higher level provides an upward connec- how to implement a particular structure or function. In-
tion. deed, because components provide for alternative refine-
Structure of Products: Components may not show up ments (implementations), there is the possibility of cap-
in the code produced by Draco directly because of the turing and easily reusing design tradeoff information that
refinements and transformations that may be applied. is not normally available in a design representation.
However, through the refinement history [15] one can It should be noted, however, that there is a level of
trace the influence of a given component on a specific design information that is not explicitly captured in this
piece of code (whatever it may be). This provides, then, manner. That is the information about the overall struc-
for one of the primary benefits of well-structured code- ture of a particular system. For example, we may have a
the ability to find a given functional piece for proposes of domain language that permits us to describe inventory
change or repair. Draco changes the traditional idea of control systems. That language, while providing a suffi-
well-structured products in this sense since now modifi- cient set of operators and operands to describe such sys-
cations would be made at the specification level and au- tems, does not tell the system designer what the overall
tomatically refined down to the code level. structure of an inventory control system should be.
We could also view this as two forms of structure: Hor- 3) Transformations:
izontal within a level of representation (e.g., code) and Abstraction Levels: Transformations in Draco are
vertical structure between levels (e.g., between the used to indicate mappings from one construct in a domain
higher-level specifications and the code). language into another construct in the same language.
Systematic Process: The reliance on components This, in effect, captures relations between abstractions in
provides a locus for the application of design quality as- the domain.
surance. Further, the size of the components facilitates Structure of Products: Transformations alter the
the assurance of their quality. From an SE standpoint, this original structure in a specification. This is not necessar-
should help make the process of building a system more ily bad, however, since the transformation is invoked to
systematic. achieve some objective (such as finding a more efficient
Perhaps more importantly, the overall philosophy of implementation).
Draco enforces a strong systematiiation on the process Systematic Process: Transformations are used to ef-
since it forces most internal design decisions to be made fect optimizations and changes in the representation of a
once at domain design time, not repeatedly each time a specification to enable other operations. This will control
system is built. This form of structuring of the process is optimizations and thus contribute, albeit in a minor way,
not possible if monolithic (i.e., noncomponentized) sys- to enforcing a systematic development process. It is the
tems are built. In effect, by utilizing many small compo- overall structure of the process that Draco supports that is
nents, we are able to break up the design process in a way the prime contributor to being systematic; in this sense,
that permits us to carry it out once in many small pieces low-level transformations are important contributors since
(the design of the components) and then reassemble that they permit us to encapsulate and thus control changes to
design process in new ways (semiautomatically) when the each stage of refinement (but not in a version-control
components are utilized. sense).
Modeling: Components provide for the realization of Modeling: Transformations provide us the ability to
the external objects and operations to be modeled in a customize a piece of the system representation so that we
straightforward one-to-one manner. Further, taking a ver- can then refine the representation into a different modeling
tical view, they provide for connection between different domain.
modeling languages. This corresponds to a change of rep- Compartmentalization of Knowledge: Transforma-
resentation. tions provide the physical encapsulation of optimization
Compartmentalization of Knowledge: Components knowledge.
838 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987
Reusability: Most of the information captured by
transformations relates to optimization of expressions in
the language, thus facilitating the reuse of such optimi-
zation information. While important, there is a higher
level of optimization information relating to the'problem
domain that we believe could (and should) be captured by
transformations.
For example, it might be known that in a particular sit-
uation of inventory control, the calculation of expected
inventory levels in the future could be greatly simplified.
If that knowledge could be captured in the form of a trans-
formation then if a specification were written and those
conditions were present, the transformation could be in-
voked to obtain the simpler form of the statements; this
would be a very valuable form of reuse of optimization
information, but one that we have not yet achieved in
Draco.
4) Refinements:
Abstraction Levels: A key element in using the con-
cept of levels of design abstraction is the way in which
connections are made between levels. Of particular inter-
est is the way in which a structure at one level is mapped
into an equivalent at the lower level, since this will have
a great impact on the correctness of the final product. In
this context, the use of refinements is central to the power
of the Draco approach.
Refinements, of course, provide for the translation of a
set of specifications expressed at one level of abstraction
into equivalent specifications at lower levels of abstrac-
tion. There are several key aspects to the way in which
this Draco mechanism contributes to our ability to utilize
levels of abstraction. First, this form permits us to incor-
porate multiple refinements, giving us alternative connec-
tions between levels of abstraction in a controlled man-
ner.
For example, normally we might want a particular com-
putation in an application language to be refined to a func-
tional language. However, we might also want a refine-
ment available directly to a procedural language for use
in special cases. Draco's usage of refinements' permits
this, providing a representation for the alternatives. This
should be compared to the usual programming language
situation in which direct references through a level of ab-
straction can cause difficulties or to the usual design sit-
uation in which normally there is no representation avail-
able for the alternatives.
A second very important aspect is that the refinements
are done by Draco (with human guidance), thus providing
more rigor and correctness in the actual refinement. This
is one of the weak links in the usual top-down refinement
of a design in which refinement from one level of abstrac-
tion to another introduces errors. However, Draco has no
mechanism to force'this and does not check pre-condi-
tions for the refinements.
Structure of Products: Most structuring of SE work-
products takes place at the level of the code (in the sense
of structured programs); this is what we called "horizon-
tal structure" above. While code produced by Draco has
some definable structure, it is not the structure that obeys
one-in, one-out rules. Draco thus forces "vertical struc-
turing," or structuring of the specifications from which
the code is produced.
Systematic Process: Refinements are the main mech-
anism that permit us to break the development process up
into small, well-defined steps in Draco. The process that
is broken up, however, is not the traditional lifecycle (that
is addressed by the overall Draco approach), but is the
process of taking high level specifications and converting
them into exec'utable code.
Modeling: The contribution of refinements to mod-
eling is to permit change of a model to a different level.
In essence, this is the same as the conversion between
levels of abstraction. The refinement library can be vi-
sioned as a hierarchical organization of abstract data types
under the aggregation/part-of relation.
Compartmentalization of Knowledge: This is an-
other key area in which the mechanisms of Draco contrib-
ute directly to the desired SE objectives. Refinements, be-
cause they permit us to have languages at multiple levels,
permit us to group knowledge by level of abstraction (dis-
tance from the machine) as well as by type of content
(division into domains). For example, this permits us to
suppress details of a particular computation or operation.
Reusability: Refinements permit the reuse of lan-
guage elements at a higher level. In addition, alternative
refinements capture and permit the reuse of performance
knowledge.
IV. SUMMARY
A. Results of the Analysis
Our primary purpose here has been to lay bare some of
the connections between Draco and the principles of SE.
There are several points that we believe are illustrated and
supported by this analysis.
First, Draco provides an environment in which several
important mechanisms can work together productively to
achieve a collection of objectives. It is not just an engine
for applying transformations or a meta-compiler or a li-
brary for small pieces of code. Rather it incorporates all
these plus more. Our analysis has looked primarily at the
individual contributions, but scanning across a row in Fig.
7, you can see how several mechanisms work together to
achieve a given objective. For example, the various as-
pects of modeling are provided by the combined efforts of
high-level languages, components, transformations, and
refinements.
Next, this analysis indicates that current mechanisms of
computer science are relatively powerful. For example,
the transformation technology being utilized does not ap-
FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS 839

pear to be a hindrance to achieving the objectives listed. on). This topic is the current focus of our research, but
Quite a lot of power can be obtained from current mech- will not be further discussed here.
anisms and we should probably put more effort on utiliz- Likewise, the operational aspect of Draco (its physical
ing what we have (although not to the detriment of con- construction) needs to be thoroughly analyzed and under-
tinuing the search for new structures in computer science). stood. We are currently (1986) in the midst of this task.
The first three objectives presented-abstraction, struc-
ture of products, and structure of process-are relatively V. RESEARCH DIRECTIONS AND RELATED WORK
straightforward; that is, we know how to achieve them. Consistent with the purpose of the paper, let us briefly
This is supported by the fact that the characterizations in indicate in closing some needed research that will further
Fig. 7 for' those three objectives (for the contribution of the Draco technology:
languages, components and so on) are straightforward and * Specialized languages are only as effective as their
definite; we can readily understand them. capture of real-world knowledge. The connections shown
The next three, however-modeling, compartmentali- in Fig. 7 will be worthless if we cannot effectively create
zation, and reusability- are not so clear in their connec- the languages in the first place. The whole area of creating
tions. Partly this is a result of the fact that they are more domains is the primary research need with respect to de-
complex objectives; but, it is also the case that consider- velopment of the Draco paradigm and the one on which
able work remains to be done on achieving them (in the we are concentrating. How to do domain analysis, how to
context of Draco, as well as more generally). -validate them, how to partition knowledge into domains,
That leads us to the final conclusion: Dealing with how best to combine languages-these are all questions
knowledge (as represented by these last three objectives) needing a great deal of study.
is an objective that is far from being realized in SE. We Neighbors [15] pointed out in his thesis, and we
believe this analysis highlights a more general situation: strongly agree, that a potentially powerful application of
that even the careful application of some powerful mech- transformations is to capture application-level changes in
anisms intended to deal with knowledge manipulation system (or problem) description to effect major economies
raises more questions than it answers. in system generation. This issue has not been attacked in
any systematic way.
B. Operational Results to Date * Refinement histories, enabling a replay of a refine-
ment sequence, would provide an essential part of a pro-
Draco was first developed by Neighbors [15], further duction-quality Draco. We are just beginning to explore
improved by him in its implementation [13] and is still a how to use such histories effectively [7], [22]. Likewise,
research vehicle for exploring a number of concepts. Ul- while refinement tactics (that automatically guide Draco
timately, it must be possible to measure its success against in making local refinement decisions) are operational,
regular system development procedures. We are presently there clearly is a need for smarter strategies that could be
working with several industrial labs here and abroad to utilized to guide automatically entire implementations.
apply Draco to some realistic examples. * The implementation of the Draco approach in the
The largest system generated so far [1] consists of ap- current tool (Draco 1.2) is sufficient for limited research.
proximately 2000 lines of Lisp code. At this stage, how- A new implementation that exploits new hardware and our
ever, it is not a production tool. Key to the eventual suc- enhanced understanding of the paradigm and the tool is
cess of the Draco approach is the existence of an effective needed, however; we plan on exploring this in the near
library of domains that can be built upon. Examples of future.
domains built so far include ones for augmented transition * A complete production-quality application of the ap-
networks, dictionary construction, generation of sen- proach should yield a significantly enhanced understand-
tences in natural language (subset parsed by the ATN do- ing of Draco. Work on this is currently underway by an
main with words in the dictionaries), limited facilities for industrial research group.
simulating parallel processing, and a reuse module defi- There are a multitude of other open research questions
nition language. relating to Draco technology, its operation, and its utili-
In addition, there are several domains that pertain to the zation. Indeed, the analysis presented here should serve
Draco "infrastructure," including ones for parser gener- to highlight and delimit the connections between specific
ation, tactics specification, refinement libraries construc- mechanisms and objectives so that these questions can be
tion, transformation libraries construction, and pretty- readily determined by others.
printer generation. Related work up to 1980 is surveyed in [15]. The Draco
Discussion of the domain construction aspect of Draco paradigm belongs to the class of approaches based on
is quite involved because of the complex nature of the task transformation technology; [18] surveys many of these.
and the connections to several other areas (artificial intel- Reference [2] presents a general scheme with similar
ligence, language design theory, data modeling, and so goals but a different representational approach.
840 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987

APPENDIX
MODEL OF THE USAGE CONTEXT OF DRACO
The SADT model presented in this Appendix, taken from [15] describes in detail the organizational context of the
intended usage of Draco. The model also illustrates the steps of using Draco that are described above in Section II.
If you are not familiar with SADT, a description can be found in [19] and [20].
n
0
USED AT. AUTHOR: Jaines M. Neighbrs DATE: 15-OCT-80 LIWORKING READER DATE CONTEXT:

1- ~PROJECT: Draco 1.0

RE V: 3
DRAFT
_RECOMMENDED_REER _ __

. NOTES: 1 2 3 4 5 6 78910 PUBLICATION

rt areas wlhere thkere is a demand

for nmany similar systems
c
organi zational information about different
C4
goals roblem domains
C:)

:,
010
a
sys tern
requirements
lo cet otaessessoftware
create software systems system
Ef

M)
'0
En
(D (DRA02)

Purpose: To show the use of Draco within an

n
organization which creates software systems.
C) Viewpoint: A researcher attenmpting to increase the productivity
H.
0 of the organization through the reuse of analysis
S and design.

NODE: A TITLE: CREATE SOFTWARE SYSTEMS (CONTEXT) NUMBER: r I

n
0
USED AT: AUTHOR. Jaines M. Neighobors DATE 15-OCT-80 W- RKG READER DATE CONTEXT:
'0 [PROJECT. Drc .0RE V. 3DRAFT_
RECOMMENDED
H. NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION
OQ
Ft
1.4 Cl organizational C2 areas where there is
goals a demand for many
1 Csifflilar systems
detezrniine a problem domain in which the
C:) doina itis oi _ 5organization is interested in
za interest producing software
c:Y
library of domain analysis reports and
research domains which have been described to Draco
crJ C3 information about domain
D different Lroblem Draco library
domains (DR04 of domains
C):r
onstruct O1 software
'S
| XJP > ~~~~softwa r eL Ystl
. ~~1
system/A~
I~~~~~~~
requirements
~ syste! 3
(DRAO3)
a
C:)n
-
H.
10
S ""experience
systems in
with building
a domain

NODE: A0 T

CREATE SOFTWARE SYSTEMS 1NUMBER: DRA02

FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS 841

0
10
USED AT: AUTHOR:
PROJECT: James M. Neighbors DATE:
REV: 15-OCT-80
WORKINGF_ READER DATE CONTEXT:
rc . 3DRAFT_
RECOMMENDED |
_

O0
NOTES: 1 2 3 4 5 6 7 8 9 10 UPULICATION
00
Il information about Cl domain of
the domain interest
\^ , ; ~~~~domain analysis|
analyze
.^
the > 01 domain analysis reports
v 12 experience/'"
with building
domain
omain analysis report with
systems in I jb / enough detail to construct
the domain omain a domain
H. analyst
domain under construction /
construct / errors and unmet needs

CA & 13 librarf-of domain

domain analysi possible target 2
reports and domains for * DRA05)
available Drac refinements DRACO test
10 on domains and the esuccessful
Ct domain domain test
des igner 3
CE
acceptable.
-.domain r
U)) domai n to
lirr 02 Draco domain
NW-.,full Draco domain library lra ry

ND:A2 ITITLE: RESEARCII TIHE D014AINNmE: DRA04

Ca

Ca UISEDAT: AUTHOR: James M. Neighbors DATE: 15-OCT-80 WORKING READER DATE CONTEXT:
0
'1 PROJECT: Draco 1.0 REV: 3 L DRAFT _.
. L ~~~~~~~~~~~~RECOMMENE_ _
NOTES. k I A 4x §c ft I it 10 *PUBLICATION
=r .
El Cl domain analysis report including
| v ~~~detail to construct a domain|
00

4
0P
00
external and logical scoping and relationships prose description
(D
internal formill aggregation to use between the of the semantics
in printing internal objects and of domain objects
| form[31
create | | |operations(5 and operations(71

parser1
I'-
00
Ca language
PARGEN dmi
parse cres prettyprinter
prettydomai0 doma
EnUl
MI
printer ~~~~transformati n partsmai
D
PPGEN crea e
I<Pa
transfor-
r . t s~~~~~~~fibar[ errors i-n
parts
g | ~~~~~~~~~~~ma
tion | _t
a The following notes list the extension l
of the files which capture the associated FMGEN
ca information.
1.DEF 2.PAR transformation domain
Ca 3.PPD 4.DPP catalog component
5.TFM 6.TLBa componen librarytOl
).1
7.REF 8.RLB
| Il~ ~ ~ ~ ~ ~ ~ ~1 possible target 4
1 41r1
domains from Draco
9. All of the mechanisms shown on this library for
diagram are the names of Draco subsystems. refinements

[NODE:A22 T

CONSTRUCT A DOMAIN DNUMBERlOSl I

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

'00
C)
10
USED AT: AUTHOR: James M. Neighbors
Drc
INOTES: 1 2 3 4 5 67 8910
RDEV: 15-OCT-80I0REcOMMENDED
AEADER
~PBLICATION
CONTEXT: I
overview and successes Cl Draco library of domains
of the various Draco
00 doma i ns -

details of the
ri)
C-4 details rIchoice ofavailable domains
o . < KImethod of _
11~ ~ ~~rcreation syedoftware
sfwrsstm sys -,choice to build
a custom system
0 requiemen hierefined
requiremetonbild sing Drac
by from scratch
z: a Draco domain onstruct 01 software
0
pQ <_^ t
sys tem { system
using
o \fine 1
0 details a custom
DRACO one-of-a-kind
D construct software system
|. ta custom
C) system _
0
3 craftsman experience
with the domain

u0 02 experience with
building systeM
Ca experience with a
Draco domain
in the domain

NODE- A3 1TITLE: CONSTRUCT A SOFTWARE SYSTEM [)RAO3

tn

00
0
*
IUSEDAT P~~ROJECT:
ATHR:James M. Neighbors DATE:
REV: WORKINGI __
3DRAFT
15-OCT-80
RECOMMENDED
EADER DATE CONTEXT:

NOTES: 1 2 3 4 5 6 7 8 9 10 PUBLICATION
rc .

:'
I1 detailed system requirements

1 choice C2 details of the available domains

of
Draco
domain syntax of
rt
C- state
domain availability of |-availability
restrictions
and
H. language domain parser on
rqts. in * and transformations
: domain transformation and components
f rlwauacl ]1 1 w 1ibrary
0
systems parse
analyst& to
H designer intesnal refinement
domain language form 2 record
n program /
cr syntax errors PARSE transform
| | 4 'l~~~~~~~and
ref ine
I / s1~~~~~~~~internal 1 source
domain language (DRAcode
0.
0
internal form
with suggested
TFMREF&
system
test
resultin
'00) transformations speciali st
source co e for
system
4
01
acceptahle
U) operations are poor - an executable software
wrong in domain performance target language system
language program problems

problems with the resulting system

ND:A32 I NOD: TITLE CNUMBER

CONSTRUCT SYSTEM USING DRACO I DRA06 I I
I
FREEMAN: DRACO APPROACH TO CONSTRUCTING SOFTWARE SYSTEMS 843

0c0 USED AT: lAUTHOR: James M. Neighbors WORKING

DATE: 15-OCT-80 EADER DATE CONTEXT:
Pt PROJECT: Draco 1.-0 REV: 3DRAFT
§RECOMENDED
NOTES: k 2 3 4 5 6 7 8 9 10 PULICATION
'0:or
re

I1 original 12 poor performance transformation Cl availability and

H' internal in refined system application restrictions on
H'100 form
domain selected
~~~~~~~~policy (1 transformations
C4 / choose ___
S
03
0 domain \ transform
domain internal
D instance form transformed
DOMAIN chose chosen internal
0
H. instance _
<- __> \ | TRANSFORM ;7
form
eq
a,
.

03 INSTANCE choose component C1

a > application availability and
locale 7 policy restrictions on
C 3 | }( (1() components
03
0.L urrent possible LOCALE
01 refinement
internal instances
form of the domain record
in the current refinement refine
10 internal form tactics internal
form
5 02 source code
H' /current * \o for a target
(domain | REFINE executable
0 instance language
current internal form refined internal
form
1. all mechanisms are commands to the TFMREF subsystem
NODE:
A323
TiTL
I TRANSFORM AND REFINE INTERNAL FORM
NUMBER: DRA07

ACKNOWLEDGMENT Nov. 1980a.

G. Arango, I. Baxter, and C. Pidgeon provided incisive
comments on earlier drafts of this paper that materially
improved it; special thanks to J. Leite for Fig. 3 and J.
Neighbors for the Appendix. The word processing acu-
men of L. Caverly-Stauffer was invaluable. Finally, the
continuing support of the National Science Foundation of
this research is very gratefully acknowledged.
REFERENCES
[1] G. Arango, I. Baxter, P. Freeman, and C. Pidgeon, "A transforma-
tion-based paradigm of software maintenance," IEEE Software, vol.
3, pp. 27-39, May 1986.
[2] R. Balzer, T. E. Cheatham, and C. Green, "Software technology in
the 1990's: Using a new paradigm," Computer, vol. 16, pp. 39-65,
Nov. 1983.
[3] D. Barstow, "Domain-specific automatic programming," IEEE
Trans. Software Eng., vol. SE-11, pp. 1321-1336, Nov. 1985.
[4] B. W. Boehm, "Software and its impact: A quantitative assessment,"
Datamation, pp. 48-59, May 1973; reprinted in [12].
[5] R. M. Bustall and J. Goguen, "Putting theories together to make
specifications," in Proc. IJCAI 1977, pp. 1045-1058.
[6] J. M. Buxton, P. Naur, and B. Randell, Software Engineering Con-
cepts and Techniques, Petrocelli/Charter, 1976 (from the 1968-1969
Nato Conference on Software Engineering).
[7] S. Dietzen and W. Scherlis, "Analogy in program development," in
The Role of Language in Problem Solving I. New York: Elsevier-
Science, 1986.
[8] B. C. DeRoze and T. H. Nyman, "The software life cycle-A man-
agement and technological challenge in the Department of Defense,"
IEEE Trans. Software Eng., vol. SE-4, pp. 303-318, July 1978.
[9] P. Freeman, "Reusable software engineering: A statement of long-
range research objectives," Univ. California, Irvine, Tech. Rep. 159,
[10] -, "The central role of design: Implications for research," in Soft-
ware Engineering: Research Directions. New York: Academic,
1980b, pp. 121-132.
[111 -, "Reusable software engineering: Concepts and research direc-
tions," in Proc. Workshop Reusability in Programming, ITT, New-
port, RI, Sept. 1983, pp. 2-16; reprinted in [12].
[12] P. Freeman and A. I. Wasserman, Tutorial of Software Design Tech-
niques, 4th ed. Washington, DC: IEEE Computer Society Press,
1983.
[13] P. Freeman, "Software construction using components," Dep. In-
form. Comput. Sci., Univ. California, Irvine, Final Report on MCS-
81-03718, Apr. 1984.
[14] -' Tutorial on Reusable Software Engineering. New York: IEEE
Computer Society Press, 1987.
[15] J. Neighbors, "Software construction using components," Ph.D. dis-
sertation, Dep. Inform. Comput. Sci., Univ. California, Irvine, 1980.
[16] J. Neighbors, G. Arango, and J. Leite, Draco 1.3 User Manual, Dep.
Inform. Comput. Sci., Univ. California, Irvine, Apr. 1984.
[17] J. Neighbors, "The Draco approach to constructing software from
reusable components," IEEE Trans. Software Eng., vol. SE-10, Sept.
1984.
[18] H. Partsch and R. Steinbriuggen, "Program transformation systems,"
ACM Comput. Surveys, vol. 15, no. 3, pp. 199-236, Sept. 1983.
[19] D. T. Ross, "Structured analysis (SA): A language for communicat-
ing ideas," IEEE Trans. Software Eng., vol. SE-3, no. 1, pp. 16-
34, Jan. 1977; reprinted in [12].
[20] D. T. Ross and K. E. Schoman, "Structured analysis for require-
ments definition," IEEE Trans. Software Eng., vol. SE-3, pp. 69-
84, Jan. 1977; reprinted in [12].
[21] M. Rubinstein, Patterns of Problem Solving. Englewood Cliffs, NJ:
Prentice-Hall, 1975.
[22] W. Scherlis and D. Scott, "First steps towards inferential program-
ming," in Proc. IFIP 9th World Comput. Congress, Paris, France,
1986, pp. 199-212.
[23] D. V. Schorre, "META II: A syntax-oriented compiler writing lan-
guage," in Proc. ACM Nat. Conf., 1964, pp. D1.3-1-DI.3-1 1.
844 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 7, JULY 1987

Peter Freeman (S'62-M'67) received the Ph.D.
degree in computer science from Carnegie-Mellon
Hniversity, Pittsburgh, PA, in 1970.
He is on the faculty of the Department of In-
formation and Computer Science at the University
of California, Irvine. He has been involved in the
analysis, design, and construction of advanced
computer applications and the training of software
engineers since 1961. His research activities are
concentrated in software design and analysis tech-
niques and their application to the development
process. He is active in professional organizations, serves on several edi-
torial boards, and has lectured widely on software design and software en-
gineering. He is the author of Software Perspectives: The System Is the
Message (Addison-Wesley, 1987) and Software System Principles (SRA,
1975) and numerous technical papers. In addition, he has edited or coedited
three books and was the founding editor of the McGraw-Hill Series in Soft-
ware Engineering and Technology.