-_ ---'----_ ....

• --. L-

- .._.

--7----

_ _ _:::_{Tfi _ _£--....

4:: ::: - _=

=:=

=

'j_]

i

z =Z::I ::7

2=:_ ;:d:::a_:_-: £

:)/--i-: 1

= 2

] ]: --__: ;

-4

==: !

i

2 _

: : ITL2L.-d_:q

_: Z=ti ii

=

Z: :;
_ SOFTWARE ENGINEERING LABORATORY SERIES SEL-90-005

COLLECTED SOFTWARE

ENGINEERING PAPERS: VOLUME ViII

NOVEMBER 1990

National Aeronautics and

Space Administration

Goddard Space Flight Canter

Greenbelt, Maryland 20771

FOREWORD

The Software Engineering Laboratory (SEL) is an organization

sponsored by the National Aeronautics and Space Administration/Goddard Space Flight Center (NASA/GSFC) and created for

the purpose of investigating the effectiveness of software

engineering technologies when applied to the development of

applications software. The SEL was created in 1977 and has

three primary organizational members:

NASA/GSFC (Systems Development Branch)

The University of Maryland (Computer Sciences Department)

Computer Sciences Corporation (Systems Development

Operation)

The goals of the SEL are (i) to understand the software

development process in the GSFC environment; (2) to measure

the effect of various methodologies, tools, and models on

this process; and (3) to identify and then to apply successful development practices. The activities, findings,

and recommendations of the SEL are recorded in the Software

Engineering Laboratory Series, a continuing series of reports

that includes this document. The papers contained in this

document appeared previously as indicated in each section.

Single copies of this document can be obtained by writing to

Systems Development Branch

Code 552

NASA/GSFC

Greenbelt, Maryland 20771

iii

6109

PRECEDING PAGE BLANK NOT FILMEb

TABLE OF CORTENTS

Section 1 - Introduction ............... i-i

Section 2 - Software Measurement Studies ....... 2-1

"Design Measurement: Some Lessons

Learned," H. Rombach ............... 2-2

SeCtion $ - Software Models Studies .......... 3-1

Towards a Comprehensive Framework for Reuse:

Model-Based Reuse Characterization Schemes,

V. Basili and H. Rombach ............. 3-2

"Viewing Maintenance as Reuse-Oriented

Software Development," V. Basili ......... 3-36

Section 4 - Software Tools Studies ........... 4-1

"Evolution Towards Specifications Environment:

Experiences With Syntax Editors," M. Zelkowitz . . 4-2

Section 5 - Ada Technolouv Studies ........... 5-1

"On Designing Parametrized Systems Using

Ada," M. Stark .................. 5-2

"PUC: A Functional Specification Language for

Ada," P. Straub and M. Zelkowitz ......... 5-9

"Software Reclamation: Improving PostDevelopment Reusability," J. Bailey and

V. Basili ..................... 5-21

Standard BibliouraDhv of SEL Literature

V

6109 •

P.4GE,..___.INIENItONALtY BtANK PRECEDING PAGE BLANK NOT FILMED

...... =

_-..__ ._ t& :_-:
i

__ |lf
SECTION 1 - INTRODUCTION

This document is a collection of selected technical papers

produced by participants in the Software Engineering

Laboratory (SEL) during the period November 1989, through

October 1990. The purpose of the document is to make

available, in one reference, some results of SEL research

that originally appeared in a number of different forums.

This is the eighth such volume of technical papers produced

by the SEL. Although these papers cover several topics

related to software engineering, they do not encompass the

entire scope of SEL activities and interests. Additional

information about the SEL and its research efforts may be

obtained from the sources listed in the bibliography at the

end of this document.

For the convenience of this presentation, the seven papers

contained here are grouped into four major categories:

• Software Measurement Studies

• Software Models Studies

• Software Tools Studies

• Ada Technology Studies

The first category presents experimental research and

evaluation of software measurement; the second category

presents studies on models for software reuse; the third

category presents a software tool evaluation; the last

category represents Ada technology and includes studies in

the areas of reuse and specifications.

The SEL is actively working to understand and improve the

software development process at Goddard Space Flight Center

(GSFC). Future efforts will be documented in additional

volumes of the Collected Software Engineering Paper_ and

other SEL publications.

6109

i-i

_

_ _:=_--SEC'llON 2-.SOFTWARE MEASUREMENt"

Sl'UO|ES

SECTION 2 - SOFTWARE MEASUREMENT STUDIES

The technical paper included in this section was originally

prepared as indicated below.

• "Design Measurement: Some Lessons Learned,"

H. Rombach, IEEE Software, March 1990

6109

2-1
Design Measurement:

Some Lessons Learned

1_, _ _, UrmFer_ty of Maryian_ a¢ College Park

Most software

measurements are

derived from source

code, A pronsmg

addition to the field is

design measurement,

which applies

measurement

principles to front-end

pmducts and

processe_

Marct_ 1990

easurernent is becoming recognized as a use_d way to soundly

plan and control the execution

of =o_'4re projects. However. current

me-_urement practices are deficient in

fom'w'4y=:

• They ernph=._ze the back end of development, mainly the coding and testing

phases:

• they are biased toward software prodm:ts, as opposed to proce=es;

• they are based on unsound measurement methodologies; and

• they are not integrmed with developmen cactivities. ..........

In short, most soR'waz'e measuzements

are derived solely 8"ore source code. Deem measurement -- as Figure I illustrates -- is the appfical:ion of measurement to design _ (theword I use co

refer ¢o all kinds or'activities) and/or the

resuhmg design _ ( the word I use co

refer to all kinds of documents).

Design measurement is a desirable addi0'740-74_JlO,@_(MO017/S01.00O 1990[E_,._

cJon co cradirionaJ code-based measures

because it lets you capture important aspects of the product and the process earlier in the life .cycle so you can taimcorrecrive acuons earlier. In cure, r.his benefit

leads to a potentially high payoff, since we

know that errorsare more cosdv if committed early in the life cycle and not

caught until much later.

In this article, I extract from several

measurement projecu some of the important lessons I have learned about measurement in general and design me_umment in par_cuiar. I have synthesized

these lessonsinto a de=gn-me_uz_,ment

framework in an attempt m communicate

my personal mea.gzrement experience to

other software engineers.

My general measurement experience

was gained on the Disms/Incas z project at

the University of Kaisersiautem, West

Germany; several projects acthe Nauonal

Aeronaurics and Space Adminisu-auon's

5ofxware gngineenng Laboratory at the

17

6109

2-2
Kmg

Cummtemp_ of me_,urement

Proooseclaclcli.onto measurement

1. The scope of measurement.

Godda._ Space Flight Center in GreenheR.._d.; and the Tailoring a Measurement Environment project at the Universi_ofMarTiand,

My design-measurement experience

was gluned on the DLsms/_cas pro_ec_

which measured inLercomponent dependencies to predict future maintenance beha_or, a study at the Umverslty

of MinT/and that compared the effect of

v'anous design methods; and various studies at the Software Engineering Labortory co develop quanrimuve design base.

lines.

Mmmon_

From each of these projects, I learned

impotent leslor_ about "effective" soft.

ware measurement. These lessom tended

co _aU in aztec are_

• how memurement must be applied in

ind/vidual experiments or case studies,

• how me_uren_nt can help conunuou._ improve an org-anizauon's state of

the prac0ce, and

•why measurement requiresautomated

support.

_emm and mine studies. As part of

the Discos/Incas project on dismbuted

systems, my colleagues and I developed

the object.orientedlanguage Lady) One

objecuve of thislanguage was to improve

the mmntainabilhy of the disu'ibuted software written in it. The funding agency, the

German Ministry, for Research and Technology, requested empirical evidence of

whether (and cO what degree) this objec18

6109

rive had been me_. To find out. we conduped a lar_. controlled _periment in

which we developed 12 systems, six in

Lady and six in a _iidonal pmcedur'_

[an_k_e. We then smcLied their consequent rr_im_mance.:

This experiment h_ caught usseven lessons:

• There are many ,typesof measurement

goal& Mea._urement _oals can differ in the

type of object the measurement focuses

on. in their intended effect on the object,

and in the people interested in them. A

mea_wement goal may focus on object

types such as processes, products, languages, methods, and tools. Its intended

is either passive (when you want to

understand the object) or acw_e (when

you want co predict, control, and improve

the object). The people interested range

from language and cool developers co

customers and users.

In the DLstos/lncas experiment, we had

two main goals. Furor.we wanted to determine and explain differences in the maintenance behavior of systemsimp|emenced

in Lady and those implemented in the

didonal language. Second, we wanted co

predict the maintenance behaviorofLady

systems based on sunacun-A complexity..

The first goal focused on the languages

used; its intended effect was pa_we beit was meant co help us understand

Lady's effect on mamtamabili_, and it re.

flected the interest of the language desil_rners.The second goal foc_aed on the

product and mmntenance process; itsintended effect was acuve because it was

2-3

i ii

me_mt co help us gu/de and control the

appropriate use of Lady co build mai_-

tamable %_ems; and itreflec_d the interest of the managers and developers planning to me Lady.

• ModeLS and memures are inseparable.

Measures are intended co characterize

some aspect of asoftware object in quanticaw_ terms, but different models of the

same aspectare possible. %qthout an explidt spec_carion of the chosen model, i c

is impossible cojudge the appmpriaramess

of the quantitative me_ures _lected,

In the DLstos/Inc_s experiment, the

maintainability model was based on the

cost req_red to perform a change during

maintenance and the effect of the change

on the maint_ned product. W_th this

model, me_ures like "e_orr in sm_hours

co perform a change" and "number of

modules a_ected by a change" werejusrlfled. To predict maintenance behavior

based on s_nacmtalcomplexity, we chose

Sallie Hertz7 and Dennis Ea/m-a's modet

for informauon flow between componen_ J In this model, measures such as

"number of incoming information flows

per moduie" md "number ofou_oing informal/on flows per module" were iusufled.

• YOU need discreet types Of me_a_Iz'e_.

We learned char you need both a_

and _c me_.sure_, _ and p_du_

measures, dir_ and ind/n_measures, and

0_m-o_ an d _ mea.sm'es.

Mo_ measures reported in the lheracure are based on some abstractmodel

(for example, control-flow measures

based on ab_ra_ prog-ram graphs). Such

ab_0r-_c_measures must be _alloredco the

specificr._czensdc_ ofthe objectcobe

measured (forexamp|e. Ado control-flow

measures must be based on Ada's specific

control_qow fe_x_re_).

Product measures (such as deign comple.mty) are not su_cient co support active measurement goals. Planned improvement of quality and productivity Ls

only possible through measurably improved (such as fewer design errors) development processes.

Directmeasures are intended co quanm_v some quality aspect (the number of

smffhours spent on design is a direct measure ofdesi_mcost.for example): indirect

measures of some quality aspect are inIEEE Sofm_are
tended to predict this quality based on

other in[orm_on that can be derived c_rtier (for example, the number of product

requinnnen_ may be an indirect me_ure

m predict the nmnber of _hours you

expect to be spent ou de,a).

Obj_ measures (such as linesof

code) aredefined wellenough m tha_two

people should compute the 'identical

value from the same object independendy. Subjective me'4vara (inch _ stuff

experience) are computed based on a

subjecUve eslimadon or a compromise

among a group of people. ObjecW_ measuresare earner to automate than subjective meaaures.

In the Distos/Inc_ experiment, the

measure "number of incoming informationflows per module" is an absu-ac: measure. To coile_ this me_ure, we had m

determine how "incoming inform_on

flow" could be meamu'ed from

implemenr--d in _. The maintenanceeffort _ arc process me_suur_ the

smacua-al-complexity measures are producc measures. The maintenance-effort

measures are direct measures of cost: the

strucarakomplexity measures are direct

measures of paxxiuct comptemty and indirect measures of maintenance co_zand effec_ _ they do not directly characterize

rnammnance cost and effect but are expected to help predict them.

• Measurement-based anal wis results

are only m good as khe data they are based

on. It is important to recognize the limits

of interpreunz measut'm depending on

their scale (that is, nominal ordinal, interval,or rano) and the v'_idi_of the underlying data. ValidaRng dam isa very

dme-consumin z and ohen underesumated cask. However, the semitive mag of

inmrp_g dam becomes guesswork if

you try to use inappropriate interpretaUons or fail to cormder the ,,-_idity of the

underlying data.

In the Discos/IncaJ experiment, we

the complexity measures only as ordinaL measures because we felttha_they

could predictthata more complex lady

system would require more effort per

rnamtenance change, but not how much

more. About haft my time on the Dbtos/Incas experiment was spent on dam

valiciauon.

• You need a sound experm_ental apMaroh 1990

proach. A mea.mremen_ experiment requires exmnsive planning, cediotm dam collection and walidadon, and

careful imerpremdon of the collected

dam..4.s in other experimental disciplines,

you need a formal approach to experimentzt/on.

In the Distos/Incm experiment, we formuJamd an approach for the experirnenml vaJidadon of structural-complexity

measures. Our approach has six steps:

I. Model the quality ofintereg (mainminability, in dm case) and quanRfyit into

direct me,mutes.

2. .Model the product complexity in a

way that lets you idennfy all the aspects

that maF affect the quality of interest

A mmm_'al_wmN_s_@

• s4_r/mant requ/r_

_tms/ve/_nninll_

amd w//a_on, amd

3. Explicidy state your hypotheses

abom theeffectofproduct complexity on

the quality of interest.

4. Man and perform an appropriate ex.

periment ca"case study, induding the collectionand validanon of the prescribed

data.

5. Ana_e the dam and validate the

hypotheses.

6. Aases_ the just-completed experi.

mental _did_ion and, i/necessary, prepare for f_mre _:p_rimcnmJ v-_lid_iom

by refu_a_ the quality, and product-complexity models, your hypotheses, the experiment imeff, and the procedures

for dam ¢ollecuon. vatidadon, and anaivd._ In a way, this stop is a built-in _-alidanon

and improvement of the experimental

validation ime1£

• You must report specific measurement

results incontext. Itisnot useful to report

measurement results from an experiment

orcasesmdywithout _ _-

ing thesmdy's context.The way you presentyour results should put the reader in

a portion to repeat the experiment or

case study. Only then can the reader agree

or disagre_ with your conclusions. Iris not

only taeies_ to present results out of context. it is also cl_ngerom, because it may

leadto inappmprmm percepdor_

Ihave published some of the results of

the Distos/Inca_ experiment together

with the necessm'y contextint'ormaaon._

The resultssuggest that Lady.programs

are more maintainable than n-adidonallanguage programs and that su'ucmrai

complexity is a useful predictor for a

component's maintainability.

The advantage of prowding the experimental context is char readers can agree

or disagree with the experimental approach chosen. For readerswho disagree

with the approach, the results have no

_alue;, for readers who agree with the approach, the results may confirm or add to

their current underamnding. In the Distos/Incas experiment, we found that

structural complexity cannot be compared acrosslanguage boundaries based

on the suggested language.specificcomplexitymeasures. However. the proposed

abstxactcomplexity measures seem appropnam.

* You mug amem each expenmentad validation i_elf It is important m transfer

knowledge gamed from one experiment

tothenext.This letsyou statebeuer goals,

use betterincarnates, and interpretthe resultsina broader context.

In theDistm/Incas expeaimenr,thisassessmentv_a explicitly inmgr-_-d, as step

6, into our experimental approach. As a

consequence of thispostmormm a.ues_

ment, we posed many new questions,

some cR'which led to thefollow-up expcrimen-- I outline later.

Cam_mm _c A_ the Un/-

vemty of_d, we have developed a

general measurement approach c_ed

the goa//quesdon/metric paradigm."

The GQM paradigm is broader m scope

and formulated in more operational

_emu than the specific experimental appro_ app_ed In the Dmos/ Intas experimmc However, both agree on two major

measurement principles: F'n-_ measurem_t must be top.down _ measurement

gradsdefine what measures should be colleccecL Second, the dam incerpretaUon

mug cake place in the context of some

19

6109

2-4
goal and hypothe_.

The G_M par-_ii_'m has four steps:

I. Sta_ me'_urement goa_ in operadona/_ You do th/s r_ep _ng _mplates, which help you formu_.r.e goals

and re,he them into questions and me_

2. Plan measurement procedures co

support the collection and va_drdion of

dam needed to compute the measures

prescribed in step |.

3. Collec_ and va/idam data.

4. Analyze and interpret the collected

dam and measures in the context of the

que-_iom and goals s_ted in step I.

We have expanded the GQM parad/gm

into the qualivt-improvement paradi_n,

which aims to facilitate continuous improvement of an or_m_on's soRw_

engineering practices) The qua/icy-improvement paradi_n embodies three

basic measurement principles: First,

surement must be applied condnuous/y

to all projects in an orramzxcion. Second.

m_ment must be all in_"_ pare Of

each project _ "development ° mu._ indude _A software conscrucuon and me_

suremenu Third. the experience g-,uned

from e_h project must be recorded in a

measu-ement database and be made

available to future projects.

The qua/ity-impmvement paradigm hLs

sixsteps:

[. Chaa-acterize the project environmenu

2. State improvement _,oals in operationad terms. A_l. this is done through

template_ chat heip you formulate goals

and refine them into questions and mea3. Plan the project (byselecnngappropriare methocis and wois) and the measurement procedures to support the col

lect_n and va/iclacion of data prescribed

in step 2.

4. Perform the proJeCt and the data col

lee-don and valida0on.

5. Analyze and interpret the collected

dam in the context of the questions and

improvement goals _¢aced in step 2.

6. Return to step i armed with the ex.

perience gained from this projecu

Applying the qua/ky_improvement

adigm _ NA.SA's Software Engineering

Lai_r'a_ory has led to a broad body of

measurement experience) '6 At the 5F.L.

2O

the qualie/-impravement panu£gm is now

an inter-a/part of development (and just

recenr_ mainmnance) ac_des to iden-

_y the qualitygera/sof interest,use sumdard me-4surement procedures to coUec_

thenecessary data fi'om ongoing produc.

rion projec_ va]tidate and blterpret the

dam, and mainm/n a corporam _emerit database.

The Goddard ,Space FLight Cenr_" has

beneficed from this mez._rement-based

improvement approach in many wa_,

ranging from a better unders_nding of

the weakne=aes and screngd_ of i_ environment, m be_ planning, to the devetopment of a new standard set ofdevelop

ment methods and tools, to higher

Ine_ducing

to improve

_vetooment prac_cu

rsqu/re_ fundamenta/

changes of

organ/za_on.

productivity and the production of higher

qua//ry so,rare.

My own acuve involvement in the SEL

has helped me bect_" undemand several

issues rela_'d to the in_'oduc_on of measurement into a produc_on environment

• Introducing measurement has farreaching consequences. Introducing"

measurement to improve an organ-

_don's development pract/ces requires

fundamental changes of the oqlanizatinn.

Itdoe_ notju_ add da_ collecuon to c.he

exisdng development activities _ it nn_ 7

chan_'es the ex_mg development acuvities by making them more transparent

In addition, the c'ffec_e incorpo_uon

of measurement into an organization requireschanges inthe m_ard structure so

it b consistent with the grads motived by

measurement and so the addiuona/ elfore spent on dam collection and waJidaUon are _eei All in all measurement

can reveal the advanta_.-s and disadvantages of current practices and spur

changes. Inappropriate measures can be

countereH'ecdve because they' may cause

the r#ro_chan_s.

At the SEL, each project member

OUr a dam<ollecdon form every dine he

makes a chan_e-- to capture the nature,

cost.and efireccof that change _ and

weekly _ m capture the effort spent on

acti_ne_ and produc_ FdEng our these

forms has become as roudne as wri_ng

code. Spec/_l measurement employees

validate the collected forma, rna/nmin the

measurement d,_d_e, and produce pc'-

riodica/reporra.

• You mustjus_ the cost of measuremenu Me-asurement costs/The cost is acceptable ifitisjusd_ed by the _ecled

qua/icyand producd'vicyimprovemen_

Measurement icse_ c:an be used co quartd(y the improvement potenda/by,c_pnarin[ the amount of rework, for example.

The C-,QM paradigm itself helps you build

the case that investmentincapturing certainmessure_ may payoffby wing them to

an organizadon's obvious improvement

nee,-I_

At the SKI, each project spends, on aver'age, 3 percent of'itsbudget on datacollecuon and va/idaaon.The organization

spends an addidona/4 to 6 percent on offline da,_ processing and analys_ How.

ever, you should expect a higher investmen¢ up front to build a new program.

• We must address both technologyand re_arc_ issues. The techno[-

ogy co es_.blish an improvemen_ program

casts, as the SIR. and other org-_nizadons

have shown. Using the a,_/lable technology is mainly a technologT_-ansfer problem.

However, there are important areas chat

need more research. These are_ include

the formalization of me'a_urement planning, rapport for dam interpretation, sup

port for le_a'ningbased on measurement

results and retmng what has been learned

across projects and environments, and

the appropriate automated suppor_ for all

these acd'vitie-,, especially the appropriate

org-aniza_on of corporate measurement

databases.

One of the laz_gest corporate measurement databases exists at the SKI.. Buih

over the last 12 ve'a_ itincludes measurement data on product characteristics (size

and complexity), process characteristics

(effort. changes, and defecu), the effecIEEE Software

6109

2-5
tiveness of methodologies (what types of

faults were easily detected ruing method

X), and project d_aracterisacs (methods

and tools used, and personnel experiemc¢). 6 At first, measurement covered

only the development stages,but maintenance has recendy been addedJ

Automated support. Much research remama to be done to properly inmga-ate

measm-ement into sofmeare development

and maintenance and to provide auto-

_ rapport in the form of software-engineering environments.

In the Tailoringa Measurement Environment project at the Uni,_'_ty of Maryland. we addmm all these measurementrelated issues in the context of the

framework provided by the quality-improvement par_" We a'7 to formalire models and we support chaxacterizmg

corporate env_-onmena, planning conm-uct/on and measurement activities, cob

letting, valldating, and analyzing data.

and learning from the measurement re.

suits m do a better job in the next project.

We are developing a series of TAME protorypesbased on an archi_ thatsupportsallthese activities.

From the TAME project, we have

learned chat:

• You need automated supporL The

amount of information accumulated in

an organizanon thatappliesa measure.

ment-ba.sed improvement approach car/-

not be handled manually. Also, without

automated support, results cannot be

made available to interested people in

real time so they can be used co support

project decisions.

inestabliabingtheSEL program, we initiallyco/letteddata withoutdatabasesupport. After about sixmonths of collecting

maintenance dam from only two projects,

we depended on database support to

maintain control of the data<ollection

process.

It takes more thanjug toolstosupport

the automated coilecuon of product data.

We also need automated support that

spans the entire set ofmeasuroment actr_

ities suggested by the quality-improve.

ment paradigm. In the TAME project, we

are developing tool support for the formulauon of goals,the derivationof incastares, the interpretation of data. the reMarch 1990

porting of measurement results, and the

maintenance of an experience base.

• You must integrate construction and

measurement support. Measurement

processes must be tailored to the constolon processes they are to measure.

The con.su-action procesaes, on the other

hand, mug be designed to be measta'able

to the degree necessary.

Often. meaam'ement is expected to answer questions about the construction

process that cannot be answered based on

the way construction is performed. Very

often, the reason for such incormstencies

is that there exists no expficit agreement

on how consua_on is or should be performed.

I _ia_/mCwmm

two_psmSm:

Mgh4ev_, _ and

a/goHthm/e., or/ow-/evel,

a_g..

It is very hard to tailor measurement to

heuristic construction processes. To address this problem, we are developing a

language that lets us model any development process explicitly and instrument

that process for mes.mremem. 7 The explicit specification of some construction

process may help clarify what the limitsdons formeasuring it are and whether the

need for additional measurements is urgent enough to consider changing the

construction process to make it more

measurable.

Design nmmummamt

I disungq_ between two design step_

architectural, or high-level, design and algorithmic, or low-leveL d,'fign . Architectural design involves identifying software

components and their interconnect/on;

algorithmic design involves identif_'ng

data structures and the control flow

within the architectural components.

Most design measurement reported in

the literature memures product complexit'/at the end of the adgorithmic design

phase from program-design-language

documents. Many of these measures

(such as Tom McCabe's cyclomauc<omplexity measure) capture product aspects

equally well from program-design-language documents and source code. so it is

not surprising that the results derived

through these design measures do not differ from results derived through tortesponding source-code meas_

In this arucle, I use the term "design

measure" to refer to architectural design

measures. In this context, the measuremerit of designs is more complicated because typically less informarlon is documenmd in a formal, measurable way at

this early stage.

When you cry to measure software designs, you realize that the potential for

measurement is limited by the measurability of the design documents. There is

very often a discrepancy between the

need for measuring a destgn aspect (such

as number of sepanm des/go decisions)

and its measurability or lack thereof

(many design decisions are documented

very. informa/ly or not at all).

Therefore, design measurement, more

so than code measurement, can not onty

capto."e design as'pec_ quandtamaely, but

it can also drivethe development and use

of more fortnal, better measurable design

approaches. The same argument can be

made in the case of design processes.

which are typically heuristic rather than

formally specified.

Des_ characterization. We need a way

to characterize soFcveare designs based on

architectural design measures. In the Distos/Incas experiment, we developed des/go measur_ accidentally when we u'ied

to compare the struco.wal complexity of

products implemented in languages

on different structural concepts- To

do so. we had to re.on to compare, ns at

some abstract level.

We defined an abstract model that was

general enough to be insm.ndated into the

precise models underlying each language_ In that regard, the abstract structural model representecl the greatest common denominator between the different

language-specific structural concepu (I

have described the abstract model's in21

6109

2-6
srandaaons eLsewhereS).

We then rea/ized that the abstr'acc

modal could also be _ciated co me'asure in=rcomponenc complexky during

desiBn _ completely for collection at the

end ofa/_or/dun/c de=gn, par_y ar the

end ofare.h/tecnar'a/d_iBn.

From this experience, we have |ezrned:

• Specific measures derived from the

same abm-acc modal c=n _ be compared acrou life.cTde phases. Abm--act

models and mea_u_ lec you insmnd_e

compatible measures to a'ace some desisn aspect acro-- seve_ Li[e-otcle pba._es.

Compatible me_ures help identify the

li/c-¢FJe phases in which the aspect of interest (in our c_e, _ comp|mcky)

is predominandy addres_-d.

In the DLstos/Incas experiment, we

memmred and traced m'ucvar_ complexicy through _-vez-aJ consecutive life-c3v.te

phases _ from archirectura/ design

through coding, h became obviou_ that

most o(the important stru_ dec_ons

had been re=de _bly by the end of

archReaura/de=gn.

• It is difficult to bnla-, and understand

the effec_l of deign methods. This i5 due

in parr co the cream_ nature of the des/gn

proce_ ir.w.Jfand in pan to the heur/sac

and therefore unpred/ctable (2 co their

effea) nature ofmo_des/_ methods.

In the Distos/Inca_ experiment, we

were tempted to am-ibum the observedsuperion_ o_ sy_ems implemenced in Lady

co the lan_J_ge'3 advanced m-ucaa_ features. This seemed to be a valid condus/on becanae we had kept a/1d_e other po-

_tia/ly conmbuan_ factors u co_¢

=s pouible (we bad u-,tined smden= =miLariy, used the same desi_m-¢ool support.

andso on).

However, follow.up interviews ted = co

be/ieve chat the major concr/bumr was the

objea-oncnred design approach chat we

had _ilored co support L_'s m'ucmr_

¢oncepa. This means chat. in _ study,

the syner _ of langtmge concepts and desiBll support conmbuced the re-a/bene._.

HowC-ver. we were com_inced tha_ appropr/ate des/_n support in iso/a_ion promises more payoff'than ian_la_e supponin

isola_/on.Our conclusion agrees with

other experience (inr.heAda.communi_,

for example) that the best language concepts are u.seiess without guidelines and

22

suppor_ for their effecdve u_e.

readies ac the SEL ev-aluamd the

pocencia_ effect of different desiBn approaches on the re_ung design documen=. These resul,- made us quemon

our prev/oum condmion because r.hey revea/ed that the de=_,ner's experience and

background is much more important

d_a the design appro=ch _

• Azr.hi_ design i_o_on h_

more in.fluenceon _n=m_aili_

a/_or/thn_c drdgu iruC'orm_oru Several

publications h=ve described the rehuve

impommce of different a/_oridua/ca/ly

oriented desi_m-compiex/cy measures.

Our experience suggeats _ it may not

be worth dLsm_.@_ng among chem be-

_ humore

im'lumr_a_ on

ais_hmi© desiCn

informatlon.

came they _LI seem m be relaw_ly unimportant compared to in_ercomponenr

complexity.

In the Distos/Inca_ experiment, we

compared some a/gor_dunic design measures (such as line= of code and McCabe's

c-ycinmific-complexic 7 me-a._c_), some

architecmr-aL deign measures (such a.s

Henry and KL_u'a's information-flow

me_ure), and some hybrid design measure= (combina_on= of _rr.h/tecml_ and

aIKorithmic measures) res-ardinE[ their

abilk'f m predict _ce behavinc

As FiEure 2 shows, in isnlacinn, the a/gorithmic measures showed no sisnificanr

correlation w/th mamr_inabiliw. However, the archi_ me*asures did (correlations in the range of O.7 co 0.8, with a

siEnificance level of less th_ 0.01). The

hybrid m_ures h=d only as/ighdv hi_her

correlauon with mamrainabilky than the

_u-chicecmz_ me.urn, bu_ there _'a_ no

dRTerence amon& them based on the algorithmic me_sure used. Overall, the corre/arions of hybrid design me-a_ures with

zn_n_nabiik_ were only about O.l lower

than the correlations of the same me'asures computed from source code.

• The dependent7 between conm-uccion and mmmirement is even more obviom durin_ des_a than it_ dunn_ codin_. If we believe k is import,ant co

measure cerr_in azchiceccural design

product or proce= aspects, we mu=t err

sure their me_u:-abiLity.

Des/_,n produ_ doc'_umen_.don methods vary in forma/i_ _ mn_ng _rom informal En_Oish m (sem/)_orma/graph no-

_mons. Meet design product me_ures are

rz/lored ¢o capture the aspects formagv

specified according to a specific method.

Thus. they c_rmo¢ be applied across envimnments char use diff'e_mt design methods.

The cze-am,e nature of the design prOcess me_u_ d_ many aspects cannot be

forma/_ed, and consequendy measured.

=r all While forma/iz_on (and consequenc ancomauon) is a soiuaon for more

mechanical processes (such as compilation), ic i_ not legible for design processes. The only legible way to make cornplex cre-4m_processes more marm_eable

and measurable is co divide them inco

smaller processes with well-defined incer-

_:es r.ha_ can be checked _ the divideand-conquer principle.

In the Disws/_._ projecc, we applied

the divide-and-conquer principle in the

form of a scepw_e, re_nement-onenced

design process. (The Cleanroom met.hod

uses a similar but much more formal approach?) In our approach, formal speci_-

c:mons were iu_'anvely refined into |ower

levelspec/_:_uions.Aftereach _ement

step. the result is proven correct with respec_ to the input spedfic_zion. This approach let us control the design process

and _enc ic_f co me'asuremenc (such

the number of design deci._'ons and how

much compte.-cky e'achdesign step adds to

the desi_m document).

Design _/Lit 7. We must deveiop

w-_ys co predic_ n_n_Lr_biliw v_th archicecmra/des/_n measures. This means th_

we must understand the relzdorcship benveen a componenc's de=gn chzr_c--r_

t/cs and itsmammnance beh_dor.

In the Di=ms/Incas projec_ we used our

s_ des_'n approach and measured

IEEE Software

6109

2-7
"/_al llhl-clnd| I_mduc_

_ clocumems

Compie3dttmliaamlas

IqlPJm 2.. The c_llies of eom_ measures to predict rn_nlanaDility dunng deign aria coding phases.

thearchitectureofLady.components- We

then memured theirmaintenance behaviorwith some effort-and erro_ measures.

From thb, we learnod din"

• You a_nuse deign measures m predict

maintainability. Generally, the design

phase _scorn/tiered to be where due signature of a sy_em is cr_md. If we can rnea-

_are during that phase, we should be able

to me _is informauon u_ pred/ct ninny

proc¢_ and product mpec_ as the life

cW/ep_

In the Distos/Inc'_ experiment, we

round th_ demfa measures could predict

maintenance, [o¢_li_, isolation effort.

modification, and understandabifi_ almost as wellas the corresponding code

measures.Some ofthe measures were applicableas e-ariy as the end of architectural

deSgn.

• We should expand the defimrion of

design memurm. The Disros/Incm experirnent suppom the belie£ that u'ue leverage is po_ble from measuring and undersb_nding the architectural aspects of

the desa_n product and process, as opM_'_h 1090

posed to the algorithmic aspects measured by. _rmlidonal demgn measures- For

example, design-process measures could

capture des/gn effort., errors commm.od

and corrected dunng deign, the effecuvenem of design methods m suppor_ng

fundamental design principles, and the

human aspect in _.uessing design alternauves and resolving conflicu_ _0

In the Dbu_/In_ experbnenr, we concenu-a_d on memunng the su'ucmr_ as.

pecr.sofdmign producm. However. we also

evaluatod the stability of designs created

according to design methods that supported differents_ucmr_ language concepm Itwas very clear from comparisons

of the evoNing design venions and R-ore

the dengners' cornmenrs char the design

method tailored to the Lady lang_aage

(wh/ch identifies three structural leveLs)

resulted in fewer redesigns than the

method tailored to _-adidonallanguages

(which typicallyiden_y only two strucleveIF),

In the SF.2.,we use a wide specwum of

design measures, ranging from subjective

measures that c_pture the human expertence with design methods, m measures

that capture the effectivenessof desagn

methods in prevennng certainerrors,co

effort and error measures. _

• Itis important m document a/1design

decisions.It has long been recognized

chatmissingdesign information makes ic

extremely d/H_oaltto maintain soRware

eflSciendy.While the finaldesign isimportant.the deign rmionale is at le_ as impor_nt it"you are co undersumd deign

ciec/._ns and avoid recre'anngpreviously

rejec_-d desert alu_rnatives.

In the Distos/Incas experiment, we

used more explicit design documents

than are used in most production environments. However. the information-flow

memures derived fl'om the final design

document had only aver'a@epredicuve capabiliues. Further an .aty_ revealed tha(

whenever a component had impficit dependencies with other components its

maintenance behavior was poorly preciicted.Implicit dependencies between

components included the me ofthe same

consmnu the use of the same algorithm.

and archi_ectur_dependencies- s

23

6109

2-8
These design decbiotu were not reflected _¢piicidy in the final design documenL Fortunately. we had stored all the

versions created during deve|opment, so

we could do a postmortem analysis to

iden_v many implicit dependencies. This

caused us to extend Henry and Kafu_'s

information-flow model with implicit,

globad inform_on flow_ sThe new design

me'a.sure, which combines ex'_ticit rand impliat iz_ormaaon flows, _ significandy

more reliable in predicting maintenance

behavior.

Re_ma_lt framework

Measurement is useful to undermmd,

control, and improve producu and protestes based on objecuve data rat.her than

subjective judgment. [t also helps you

build better models of processes and

producu. However, successful measurement requir¢_ more than a set or"measures, just as successful design require

more than asetofdesign tools.

I suggest the following comprehensive

desigm-measurement framework, which

includes measurement approaches,

mechanisms co model design aspects, the

entire range of candidate design measures, and guidelines for reporting design-m_ement results:'

• Choose and tailor an effecdve measurement approach. I suggest the C,QM

and qualit_mprovement paradigms for

both individual experiments and case

studies as well as continuous or_anizarlonal improvement. Both paradigms theoretically can exmt without me_uremenc.

butyou must measure ifFou want to evaluate and improve based on objective data

rather than ju_c subjecdvej udgment.

Both pazadignu incorporate measurement in agoat.oriented fashion: Measure_

serve goals! Both mtut be instantiated

into an operational approach t_lored co

the specific environment characteristics.*

In the TAME project, we developed templates and guidelines to help formally support the setting ofgoa_ and the detwadon

ofm_eIL*

• Model the destgn aspects of interns

To uze the paradigms properly, you mutt

model the product and proce_ mpectsof

interesL The p_duct aspects of interest

are those addressed and documented

during the design phase (such as data and

24

intercomponent structure, and control

and irdormadon flow). The protein upects of interest are harder to model In a

separate project at the Univem_ of Maryland. we are developing a process-modelo

ing language that acknowledges the need

to speci_ m_cai and creative design

a.,pe_s by combiningimperative and co_

straint-oriented language principles. 7

• Consider a variety of design m_

Candidate design measures addre-, the

design protein and product, characterize

design aspects direcdy and _ design

measures as indirect measures to help predict other qualities of interest (such as

maintainability), and represent design informationobjectively, subjecavely,and on

different sca/es.

Design-proceas measures may capture

effort di._ribudon._ defect profiles, or patterns of design-conflict rmolutions, Design-product m_ include memures

of length, structural complexity, datastructureand dataflow complexity, and information-structure and informauonflow complexi .cy.

A direct desi_m measure chara_erizes a

design aspect. In comparing Lady tylterns

co systems implemented in a _'aditionai

language, r.he me:sure "scruct'urai complexityin terms of incoming and out_oing

information flows" was used as a direct

measure of design-product complexity

and the measure "effort in staff-hours

spent on designing" as a direct measure of

design cost.

Art indirect design measure helps predict the expected vaJue of a direct measure. To measure maintainability, meaningt_d direct measures might be "effort

per maintenance cha_gn." The indirect

design measure "st.ructurai complexi .ty"

has been identified in the Distm/Incas expenment to be a usefu_ indirect measure

for predicting maintainability.

Knowing the relationship between indirect and direct measures for a particular

characteristic le_ you predict whether requirements for this characteristic can be

fulfilled and in turn, where necessary., to

correc_ devetopmen,_

Objective design measures are preferred over subjecOve design measures.

Examples of .typicalobjecuve measures

are "effort in staffhours spent on design"

and "number of design components." E.xamples of _rpicai mbjective me'asures are

"degree to which a design method was

meal" and "expe_ence ofstaffwith the design method." It is important to understand the scale of a given design measure

and the corresponding implications on its

interpretability. "_'_._',_"--"'_'-,_'.._'4-.-

• Detine goideiiaes for reporung measurement resuks.The C.,QM and quali_

improvement paradigms provide not only

a good context for measurement but

sound gtzidelines forreporting measuremerit resulr_asweil. You can use the steps

of the quaii .ty-impmvtmaent pazadigm as a

structuretoreport results: *

1. Characterize the environment to the

degree nec_saz'_ to understand the measurement goals, the experimental design,

and the data muwpretanons.

Describe the mea._aremen t goals.

3. Descmbe the measures chosen.

_.. Describe the experimental design,

including procedures for data collection,

valleY.don, and az_y_, as weft as h_potheses,

._. Ci'mz-accerize the collected data.

_. Present the anai,v=s rmuiCs and vaLidate the hypotheses.

7. Summarize ',heconcribudon of the

resuhs to the original goads and oudine

possible lessons for futuremeasurement

tasks:

ffective design measurement

promLses co contribute co quality

and productavity. Design measurement has many dimensions and should be

closely ued to the design methodolog 7

used. There are components or" designm_ment cechnolog7 avadable today,

including general measurement approac.hes _ the first TAME proto .wpe is

composed largely of available measurement technology.'

Design-memxtrement areas that require

further research include the development of tractable (or measurable) design

methods, the further formalization of

measurement approaches, t.he idencuqcadon of impot-m,nt design pnnoples chat

need tO be better under_tood through design measures, the integration of construction and measurement, and the

quantification of intellectual design activities such _ explorin_ and rejecun_ design

alternauves. 4.

IEEE Software

6109

2-9
Actmewi_lllmeats

My "*ork with Juergen Nehmer and Victor

_mifi and my involvement m the SoCtwa_ Eagineermf Laboratory has conmbuted signifi-

¢=mdv m my _m_Sofd_n

menu I thank Brad Uler7. for reading and

commenungon an eadyver,aon of tim arUcle.

R_

1. J. Nehmer ecaL. "_'y, Concepa_ the In "_*

Mu_icompurer ProjeeL" _ Tmu.

_F_aqr.Au &. i9E7, pp. 913-923.

__ ELD. Romi_ch. "A Con n'olk_ F.Dt

•,,, the Impact c_ SoFtware Su'ucume on

.'4ammna_ty,"rrrr Tea,,..Wi,,,m._.',f..

1997, pp. 3,Ul,.354.

3. S. Hem-f and O. l_ta_. "So_'_tre Su'ucrare Mem_ K,ued on h,.formauon Flow."

_'r_"T,,,u.._,m ,_,.. Sept19SLpp.

Si0-$I&

4. V.P.. Basiliand ELD, Rombach, "TheTAME

Pro_ Tmoads Impmvemem-_riemed

Sof_ [_ro_,=n_." _ Tram.

_F.a_F.Jtme t9_;. pp. 758-773.

5. ELD. t_mbach and B.T. Ulery. "Improving

Soft, ire Maintenance through Men,wemeat." _ _ April 19e9. pp. 581-595.

6. F.E. McGarry, S. Waligum. and T. MeDe_

mo_ "Expene=ces m the _ Applyi'ng

So[rware MemuremenL" Prec. 14¢k Au.

?_mn £_. _ NASA/SELPub.

SET_O07,N_ C,odda_Spa_night

Cammr. GreenbeR. Md.. !999.

7. ELD. Romi0_u:h and L. ,",lark, "Software

P._:maand Product Specifumdom: A Barn

for C.enera_ng Cusmrrazed SE lnforma-

_n Batm.° Pme. 22 nd Hamm l_u _lCa_. ._

_,_m_CSPre_LmAlam_u_,Ca_

19_19. pp. 165-174.

_. I.LD. l_mbach. "sofe_u'e Deem Memos

for Mamtemmce."/_e_ ._m_.4_ Se_m_

004. NASA Goddal_ Space Plight Center,

Grt_nbelr. Md.. 1984.

9. P..W. 5elby, V,R. _mili, and 1". Baker,

"C_nroom Software Development An

Empirical E_," _ Tnm*.

y.=_ Sept tgST.pp, t_27-1.037.

10. B.Curmetal.. "On Euiidingso(r.vireProcem Mode_ Under, the Lamppo_." Proc.

Ni_ lm' l Co_. _Tflwr_ En_. C_ Press. Laas

Alamtco_ Calif.. 1987, pp. 96-103.

1:9.

EL Dieter _ is an aumtcant profesSOr of

computer science at the Univer_ty of

land at College Park. He is abo aH'tliared with

NASA's SoC'tware Engineering Laboratory and

the Univenaty of M .aryland's Insumm for Ad-

_z_ed Gamputer Smdlex His research interinclude software methodolognes, proce_

and produ_measurement and modeling, in _egrated software-development environments.

and dlsmbuted p_g.

Romtmch received a BS in nmthemaucs and

an. _ in mathenum,"- and computer saence

from the Univer_ty of Karlsruhe, West Germany, md a PhD in computer science from the

University. of Ka_ersiautern, West Germany.

He is a member o_ the IE.EE Computer Society,

A_M. and the German Computer Society.

Addresi questions about this article to

Rombar.h at Computer Science Dept.. University of Maryland. College Park. MD 20742:

C_net dieter@a.umcLedu.

6109

2-10
SECTION 3-SOFTWARE MODELS

STUDIES
22_

_--.....__

n

_-T_7

TT_F_

_" 2Z
SECTION 3 - SOFTWARE MODELS STUDIES

The technical papers included in this section were originally

prepared as indicated below.

• TQwards _ Comprehensive Framework for Reuse: ModelBased R_use Characterization Schemes, V. Basili and

H. Rombach, University of Maryland Technical Report

TR-2446, April 1990

• "Viewing Maintenance as Reuse-Oriented Software

Development," V. Basili, IEEE SQftw%re,

January 1990

6109

3-1
UMIACS-TR-90-47

CS-TR-2446

April 1990

Towards a Comprehensive Framework for Reuse:

Model-Based Reuse Characterization Schemes*

Victor R. Basili and H. Dieter Rombach

Institute for Advanced Computer Studies and

Department of Computer Science

University of Maryland

College Park, MID 20742

ABSTRACT

Reuse of products, processes and related knowledge will be the key to enable the

software industry to achieve the dramatic improvement in productivity and quality required to

satisfy the anticipated growing demands. We need a comprehensive framework of models and

model=based characterization schemes for better understanding, evaluating, and planning all aspects of reuse. In this paper we define requirements for comprehensive reuse models and related characterization schemes, assess state-of=the=art reuse characterizauon schemes relative to

these requirements and motivate the need for more comprehensive reuse characterization

schemes. We introduce a characterization scheme based upon a general reuse model, apply it

and discuss its benefits, and suggest a model for integrating reuse into software developmenL

*R=search for this study was suplxarted in part by NASA grant NSG-5123, ONR grant NOOOI4-87-K-0307 and A*rmics grant

DE-miubSdOR21400 to Lhe Uaiversity of Miryland.

6109

3-2
TABLE OF CONTENTS:

1 INTRODUCTION .............................................................................................

BASIC REQUIREMENTS FOR A REUSE CHARACTERIZATION SCHEME

................. o ............... °.......................................................................... • ...........

2.1 Software Developmenl; A_ump_ions ............................................................

2.2 Software Reuse Aa_umptions .......................................................................

2.3 Software Reuse Characteristics ...................................................................

3 STATE-OF-THF_,-ART REUSE CHARACTERIZATION SCHEMES ...............

MODEL-BASED REUSE CHARACTERIZATION SCHEMES ..........................

4.1 The Abstract Reuse Model ..........................................................................

4.2 The First Mode| Refinement Level ..............................................................

4.3 The Second Model Refinement Level ...........................................................

4.3.1 Objects-Before-Reuse ...........................................................................

4.3.2 Objects-After-Reuse .............................................................................

4.3.3 Reuse Process .......................................................................................

5 APPLYING MODEL-BASED REUSE CHARACTERIZATION SCHEMES .......

5.1 Example Reuse Characterizations ................................................................

5.2 De_cribing/Understanding/Ivlo_ivating Reuse Scenarios ...............................

5.3 Evaluating the Cost of Reuse ......................................................................

5.4 Planning the Population of Reuse Repositories ............................................

6 A REUSE-ORIENTED SOFTWARE ENVIRONMENT MODEL ......................

7 CONCLUSIONS ...............................................................................................

8 ACKNOWLEDGEMENTS ................................................................................

9 REFERENCES .................................................................................................

12

12

13

15

15

16

18

20

20

23

26

27

28

31

31

32

6109

3-3
1. INTRODUCTION

The existing gap between demand and our ability to produce high quality software costeffectively calls for an improved software development technology. A reuse oriented development

technology can significantly contribute to higher quality and productivity. Quality should

improve by reusing proven experience in the form of products, processes and related knowledge

such as plans, me_urement data and lessons learned. Productivity should increase by using

existing experience rather than creating everything from scratch. Many different approaches to

reuse have appeared in the literature (e.g., [7, 9, 11, 13, 14, 15, 16, 21, 22, 23]).

Reusing existing experience is a key ingredient to progress in any area. Without reuse

everything must be re-learned and re-created; progress in an economical fashion is unlikely.

The goal of research in the area of reuse is the achievement of systematic approaches for effectively reusing existing experience to maximize quality and cost benefits.

This paper defines and demonstrates the usefulness of model-ba_ed reuse characterization

schemes. From a number of important assumptions regarding the nature of software development

and reuse we derive four essential requirements for any useful reuse models and re[a_ed characterizationschemes (Section2). Existingmodels and characterizationschemes are _ssessedwi_h

respectto theseassumptions and the need for more comprehensive models and characterization

schemes isestablished(Section3).We introducea reusecharacterizationscheme basedon a generalmodel of reuse(Section4),and discussitspractica/applicationand benefits(Section5).

Throughout the paper we use examples of reusing g_nerie Ada packages, de_iqn inspections, and

cost models to demonstrate our approach. Finally, we present a model for integrating and supportingreusein softwaredevelopment(Section6).

-2-

6109

3-4
2. BASIC REQUIREMENTS FOR A REUSE CHARACTERIZATION SCHEME

The reuse approach presented in this paper is based on a number of assumptions regarding

software development in general and reuse in particular. These assumptions are based on more

than ten years of analyzing software processes and product_ [I, 3, 4, 5, 6, 191. This section states

our assumptions regarding development and reuse (Sections 2.1 and 0..2, respectively), and derives

a set of characteristics required for any useful reuse characterization scheme (Section 2.3).

2.1. Software Development Assumptions

According to a common softwaredevelopment projectmodel depictedin Figure I,the goal

of softwaredevelopment is to produce projectdeliverables(i.e.,projectoutput) thatsatisfyprojectneeds (i.e.,projectinput)[25].This goal isachieved accordingto some development process

model which coordinatespersonnel,practices,methods and tools.

development process model

_':iiii_iii!!_i! .............. ods tools

Figure 1: Software Development Project Model

6109

-3-

3-5
With regard to software development we make the followin$ assumptions:

(DI) A sinKle software development_ process model cannot be assumed for all software

development projects: Different project needs and other projec_ characteristicsmay suggest

and justify different development process models. The potential differences may r._nge from

differentdevelopment process models themselves to differentpractices,methods and toolssupporting these development process models to differentpersonnel.

(D2) Practices, methods and tools - including reuse-related ones - need to be tailored

to the project needs and characteristics: Under the assumption that practices, methods

and tools support a particular development project,they need to be tailored to the need_ and

objectives,development process mode[, and other characteristicsof that project.

2.2. Software Reuse Assumptions

Reuse-oriented software development (depicted in Figure 2) assumes _ha_, given the

project-specificneed to develop an object 'x'that meets specification'_, we take advantage of

some already existin$object 'xk' e {'Xl',...,'Xn'} instead of developinz 'x'from scratch. In this

case, ._' is not only the specificationfor 'x'but also the re_e apec_._cationfor the set of reuse

candidates 'xI', ...,'xn"' Reuse includes the identificationof a Set of reuse candidates {'x1', ...,

T

'X.k,'"" Xn )' the evaluation of theirpotential to satisfyreuse specification'._'effectivelyand _he

selection of the best-suited candidate 'xk'' the possible modification of the chosen candidate 'xk'

into 'x',and the integrationof 'x'into the development process of the current project.

6109

3-6
r

C,)

refine proeq ms model

@ .....@ .....@

Figure 2: Reuse-Oriented Software Development Model

With regard to software reuse we make the following assumptions:

(R1) All experience can be reused: Typically, the emphasis is on reusing objects of type

'source code'. This limitation reflects the traditional view that software equals code. It ignores

the importance of reusing software products across the entire life-cycle (which includes _he

planning as well as the production phases of a software development project), software

processes and methods, and other kinds of knowledge such as models, meazuremen_ da_a or lessons learned.

The r¢_s¢ of 'generic Ads packages" represents an example of product reuse. Generic Ada packages represent templates for instantiating specific package objects according to a parameter

mechaniems. The reuse of 'design inspections' represents an example o/ process reuse. Design

inspections are off-line fault detection and isolation methods applied duriag the module design

phas_. They can be based on different techniq_tes for reading (e.g., ad hoc, sequential, control

flaw oriented, stcpwise abstraction oriented). The reuse of 'cost models' r_presentn an example

of knowledge reuse. Goat models are used in the estimation, evaluation and control of project

cost. They predict cost (e.g., in the form of staff-months) based on a number of characteristic

project parameters {e.g., estimated product aize in If.LoG, product complexity, methodology

te_d).

(R2) Reuse typically requires some modification of the object being reused: Under the

assumption that software developments may be different in some way, modification of

-5-

6109

3-7
experience from prior projects must be anticipated.The degree of modification depends on how

many, and to wha_ degree, existing object characteristicsdifferfrom their desired characteristics.

To reuse an Ada package 'list of integers' to organize a 'list of reals' we need to modify it. We

can either modify the ezisting package by hand, or we can use a generic package 'lint' which can

be instamtiated via a parameter mechanism for any base type.

To reuse a design inspection method across projects characterized by significantly different fault

profiles, the underlying reading technique may need to be tailored to the respective fault profiles.

If 'interface faults' replace 'control flow faults' as the most common fault type, we can either

select a different reading technique all together (e.g., step-wise abstraction instead of controlflow oriented) or we can establish .specific guidelines for identifying interface faults.

To reuse a cost model across projects characterized by different application domainn, we may

have to change the number and type of characteristic project parameters used for estimating

cost as well as their impact on cost. If 'commercial software' is developed instead of 'real-time

software', toe may have to consider re-defining 'estimated product size' to be measured in terms

of 'data strnctures' instead of 'lines of code' or re-computing the impact of the ezinting parameters on cost. Using a cost model effectively implies a constant updating of our understanding of

the relationship between project parameters and cost.

(R3) Analysis is necessary to determine when and if reuse is appropriate: The decision

to reuse existing experience as well a.show and when to reuse it needs to be based on an

analysis of the payoff. 'Reuse payoff is not always easy to evaluate. We need to understand (i)

the objectives of reuse, (ii) how well the available reuse candidates are qualified to meet these

objectives, and (iii) the mechanisms available to perform the necessary modification.

Assume the ezistence of a net of Ada generics which represent application-specific components

of a satellite control system. The objective may be to reuse such components to build a new

satellite control system of a similar type, but with higher precision. Whether the ezisting generics are suitable depends on a variety of characteristics: Their correctness and reliability, their

performance in prior instances of reuse, their ease of integration into a new system, the potential for achieving the higher degree of precision through instantiation, the degree of change

nee_d, and the e_istence of reuse mechanisms that support this change process. Candidate

Ada generics may theoretically be well suited for reuse; however, without knowing the answers

to these questions, they may not be reused due to lack of confidence that reuse wall pay off.

Assume the ezistence of a design inspection method based on ad-hoc reading which has been

used successfully on past satellite control software developments within a standard waterfall

model. The objective may be to reuse the method in the context of the Gleanroom development

method [18, 20/. In thin cane, the method needs to be applied in the contezt of a different lifecycle model, different design approach, and different design representations. Whether and how

the ezisting method can be reused depends on our ability to tailor the reading technique to the

stepwise refinement oriented design technique used in Gleanroom, and the required intensity of

6109
reading due to the omission of developer testing. Thin results in the definition of the stepwine

abstraction oriented reading technique [8/.

Aas_,_,le the ezistcnce of a coat model that has been validated for the development o/satellite

control software based on a waterfall life-cycle model, functional decomposition oriented design

techniques, and functional and structural testing. The ob]'eetive may be to reu._e the model in

the contczt of Cleanroom development. Whether the cost model can be tensed at all, how it

needs to be calibrated, or whether a completely different model may be more appropriate

depends on whether the model contains the appropriate variables needed for the prediction of

cost change or whether they simply need to be re-calibrated. This question can only be answered

through thorough analysis of a number of Cleanroom projects.

(R4) Reuse must be integrated into the specific software development: Reuse is intended

to make software development more effective.In order to achieve this objective we need to

tailorreuse practices,methods and toolstowards the respective development process.

We have to decide when and how to identify, modify and integrate ezisting Ada packages. [f we

assume identification of Ada generics by name, and modification by the generic parameter

mechanism, wc req_Lire a repository consisting of Ada generics together with a description of the

instantiation parameters. [f we assume identification by specification, and modification o/ the

9eneric's code by hand, we require a suitable specification of each generic, a definition of

semantic closeness of specifications so we can find suitable reuse candidates, and the appropriate source code documentation to allow for ease of modification. [n the case of identification

by specification we may consider identifying reuse candidates at high-level design (i.e., when the

component specifications for the new product e_ist) or even when defining the requirements.

We have to decide on how often, when, and how design inspections should be integrated into the

development process. [f we assume a waterfall-based development life-cycle, we need to determTne how many design inspections need to be performed and when (e.g., once for all modules at

the end of module design, once for all modules of a subsystem, or once for each module). We

need to state which documents are required as input to the design inspection, what results are

to be produced, what actions are to be taken, and when, in case the results are insufficient, and

who is supposed to participate.

We have to decide when to initially estimate co_t and when to update the initial estimate. [f we

assume a waterfall-based development life-cycle, we may entimate cost initially based on

estimated product and process parameters (e.g., estimated product size). After each milestone,

the estimated cost can be compared with the actual cost. Possible deviations are used to correct

the estimate for the remainder of the project.

2.3. Software Reuse Characteristics

The above software reuse assumptions suggest that 'reuse'is a complex concept. We need to

build models and characterizationschemes that allow us I;odefine and understand, compare and

evaluate, and plan the objectivesof reuse, the candidate objects of reuse, the reuse process itself,

7

6109

3-9
and the potential for effectivereuse. Based upon the above assumptions, such models and characterizationschemes need to exhibit the following characteristics:

(C1) Appllcable to all types of reuse objects: We want to be able to characterize products,

processes and allother types of related knowledge such as plans, measurement data or lessons

learned.

(C2) Capable of characterizing objects-before-reuse and objects-after-reuse: We want

to be able to characterize the reuse candidates (from here on called 'objects-before--reuse')as

well as the object actually being reused in the current project (from here on called 'objectafter-reuse').This will enable us to (i)judge the suitabilityof a given reuse candidate based on

the distance between its actual before--reuseand desired after-reuse characteristics,and (ii)

establish criteriafor useful reuse candidates (object-before-reusecharacteristics)based on anticipated objectivesfor their(re)use(object-after-reusecharacteristics).

(C3) Capable of characterising the reuse process itself:We want to be able to (i)judge

the ease of bridging the gap between differentobject characteristicsbefore- and after-ruse,

and (ii)derive additional criteria for useful reuse candidates based on characteristicsof the

reuse process itself.

(C4) Capable of being systematically tailored to specific project (i.e.,development

and reuse) needs and other characteristics: We want to be able to adjust a given reuse

characterizationscheme to changing needs in a systematic way. This requires not only the ability to change the scheme, but also some kind of rationale that tiesthe given reuse characterization scheme back to its underlying model and assumptions. Such a rationale enables.us to

identify the impact of differentenvironments and modify the scheme in a systematic way.

6109

3-10
3. STATE-OF-THE-ART REUSE CILARACTERIZATION SCHEMES

%

A number of research groups have developed characterizationschemes for reuse (e.g.,[9, 11,

13, 21, 22]). The schemes can be distinguished as _pecialp,rpo_ _chemc_ and rneta_ch_m_.

The large majority of published characterizationschemes have been developed for a special

purpose. They consist of a fixed number of characterization dimensions. There intention is to

characterize software products as they exist.Typical dimensions for characterizing source code

objects in a repository axe "function', "size",or "type of problem". Examples schemes include

the schemes published in [11, 13], the ACM Computing Reviews Scheme, AFIPS's Taxonomy of

Computer Science and Engineering, schemes for functionalcollections(e.g.,GA_MS, SHARE, SSP,

SPSS, I_¢fSL1 and schemes for commercial software catalogs (e.g.,[CP, :DS, IBM Software Catalog, Apple Book). It isobvious that specialpurpose schemes are not designed to satisfythe reuse

modeling characteristicsof section2.3.

A few characterizationschemes can be instantiatedfor differentpurposes. They explicitly

acknowledge the need for differentschemes (or the expansion of existingones) due to differentor

changing needs of an organization. They, therefore,allow the instantiation of any :maginab[e

scheme. An excellent example is Ruben Prieto-Diaz's facet-based reefs-characterizationscheme

[14, 17]. Theoretically, meta schemes axe flexibleenough to allow the capturing of _ny reuse

aspect. However, based on known examples of actual uses of meta schemes, such broadness seems

not intended. Instead, most examples focus on product reuse, are limited t_ the objects-beforereuse, and ignore the reuse process entirely. Meta schemes were also not designed to satisfy the

reuse modeling characteristicsof section 2.3.

We have found that existingschemes - special purpose as well as meta schemes - do not

satisfyour requirements. To illustratethe problems associated with their[imitations,we use the

following example scheme which can be viewed either as a special-purpose scheme or a specific

6109

3-11
i

instantiation of a meta scheme :

Each reuse candidate is characterized in terms of

* name: What is the object% name? (e.g., buffer.ada, sel_inspection, sei_cost_modeI)

• function: What is the functional specification or purpose of the object? (e.g., integer_queue,

<element> buffer, sensor control system, certify appropriateness of design document_,

predict project cost)

• use: How can the object be used? (e.g., product, process, knowledge)

. type: What type of object is it? (e.g., requirements document, code document, inspection

method, coding method, specification tool, graphic tool, process model, cost model)

• granularity: What is the object's scope? (e.g.,system level,subsystem level,component

level,module - package, procedure, function - level,entire lifecycle, design stage, coding

stage)

• representation: How is the object represented? (e.g.,data, informal set of guidelines,

schematized templates, formal mathematical model, languages such as Ada, automated tools)

• input/output: What are the external input/output dependencies of the object needed to

completely define/extract it as a self-contained entity? (e.g.,global data referenced by a

code unit, formal and actual input/output parameters of a procedure, instantiation parameters of a generic Ada package, specificationand design documents needed to perform a design

inspection,defect data produced by a design inspection,variables of a cost model)

• dependencies: What are additional a_sumptions and dependencies needed to understand the

object? (e.g.,assumption on user'squalificationsuch as knowledge of Ada or qualificationto

read, specificationdocument to understand a code unit, readability of design document,

homogeneity of problem cla-_sesand environments underlying a cost model)

• appl|catlon domain: What application classeswas the object developed for? (e.g.ground

support software for satellites,business software for banking, payroll software)

• solution domain: What environment classeswas the object developed in? (e.g.,waterfall

life-cyclemodel, spiral life-cyclemodel, iterative enhancement life-cyclemode[, functional

decomposition design method, standard set of methods)

• object quality: What qualitiesdoes the object exhibit?(e.g.,levelof reliability,correctness,

user-friendliness,defect detection rate,predictability)

Let's assessthe above reuse characterizationscheme relativeto the four desired characteristicsof

section 2.3:

(C1) It is theoreticallypossible to characterize all types of experience according to the above

scheme (in case of a meta scheme we could even crease new ones). For example, a generic Ada

package 'buffer.ada'may be characterized as having identifier'buffer.ada',offering the function

'<element>_buffer', being usable as a 'product' of type 'code document' at the 'package

module level',and being represented in 'Ada'. The self-contained definitionof the package

requires knowledge regarding the instantiation parameters as well as itsvisibilityof externally

" Characterization dimensionsaremarked with'-';examplecategoriesforeachdimensionarclistedinparenthesis.

-- 10 --

6109

3-12
defined objects (e.g., explicit access through WITH clauses, implicit access according to nesting

structure). In addition, effective use of the object may require some basic knowledge of the

language Ada and assume thorough documentation of the object itself. It may have been

developed within the application domain 'ground support software', according to a 'waterfall

life-cycle' and 'functional decomposition design', and exhibiting high quality in terms of 'reliability'.

(C2) The scheme is used to characterize reuse candidates (i.e., objects-before-reuse) only. However, in order to evaluate the reuse potential of an object-before-reuse in a given reuse

scenario, one needs to understand the distance between its characteristics and the characteristics of the desired object (i.e., object-agter-reuse). In the case of the Ada package example, the

required function may be different, the quality requirements with respect to reliability may be

higher, or the design method used in the current project may be different from the one according to which the package has been created originally. Without understanding the distance to

be bridged between reuse requirements and reuse candidates it is hard to (a) predict the cost

involved in reusing a particular object, and (b) establish criteria for populating a reuse repository that supports cost-effective reuse.

(C3) The scheme is not intended t_ characterize the reuse process at M1. To really predict the

cost of reuse we do not only have to understand the distance to be bridged between objectsbefore and objects-agter-reuse (as pointed out above), but a/so the intended process to bridge i_

(i.e., _he reuse process). For example, it can be expected that it is easier to bridge the distance

with respect to function by using a parameterized instantiation mechanism rather than modifying the existing package by hand.

(C4) Their is no explicit rationale for the eleven dimensions of the example scheme. That makes

it hard to reason about its appropriateness as well as modify it in any systematic way. There

is no guidance in tailoring the example scheme to new needs neither with respect to what is to

changed (e.g., only some categories, dimensions, or the entire implicitly underlying model) nor

- 11 -

3-13

6109
how itis to be changed.

The resultof this assessment suggests the urgent need for new, better reuse characterization

schemes. In the next section,we suggest a model-based scheme which satisfiesallfour characteristics.

4. MODEL-BASED REUSE CHARACTERIZATION SCHEMES

In this section we define a model-based reuse characterizationscheme satisfyingthe characteristics(C1-4) stated in section 2.3. We staxt this modeling approach with a very general reuse

model satisfyingsatisfyingthe reuse assumptions, refineit step by step until it generates reuse

characterization dimensions at the level of detail needed to understand, evaluate, motivate or

improve reuse. This modeling approach allows us to deal with the complexity of the modeling

task itself,and document an explicitrationale for the resulting model.

4.1. The Abstract Reuse Model

The general reuse model used in this section isconsistent with the view of reuse represented

in section 2.2. It assumes the existence of objects-before-reuse and objects--after-reuse,and a

transformation between the two:

6109
 iii!!iiiii!!i 

OBJECTS

BEF OILE

REUSE

i!iiiii ii

REUSE

PROCESS

OBJECTS

AFTER

REUSE

Figure 3: Abstract Reuse Model (Refinement level 0)

The objects-before-reuse represent experience from prior projects, have been evaluated as being

of potential reuse value, and have been made available in some form of a repository. The

objects-after-reuse are the (potentially modified) versions of obiects-before-reuse integrated into

some project other than the one they were initially created for. Object-after-reuse characteristics

represent the 'reuse specification' for any candidate 'object-before-reuse'. Both the objectsbefore-reuse and the objects-after-reuse may represent any type of experience accumulated in the

context of software projects ranging from products to processes to knowledge. The reuse process

transforms objects-before-reuse into objects-after-reuse.

4.2. The First Model Refinement Level

Figure 4 depicts the result of the first refinement step of the general model of Figure 3.

- 13 -

6109

3-15
_!!i!iiobject iinterfaCe!iii!i

iiObjeCt i_OnteXt ii

OBJECTS

BEFORE

REUSE

PROCESS

REUSE

Figure 4: Our Reuse Model (Refinement level I)

OBJECTS

AFTER

REUSE

Each ob]ect-be/or_-rcu_e is a specificcandidate for reuse. It has various attributes that

describe and bound the object. Most objects are physically part of a system, i.e.they interact

with other objects to create some greater obiect. Ifwe want to reuse an object we must understand its interaction with other objects in the system in order to extract it as a unit, i.e.object

int,rface. Objects were created in some environment which leaves its characteristicson the

object, even though those characteristicsmay not be visible.We call this the object contezt.

The ob3ect-after-reu_,is a specificationfor a set of before--reusecandidates. Therefore, we

may have to consider different attributes. The 81/sternin which the transformed object is

integrated and the ,!/,tem contezt in which the system isdeveloped must also be classified.

The rcu,c procc,, isaimed at extracting the object-before--reusefrom a repositorybased on

the available object--after-reusecharacteristics,and making it ready for reuse in the system and

context in which it will be reused. We must describe the various r¢u** acti_itic_and clas3ify

them. The reuse activitiesneed to be integrated into the reuse-enabling software development

process. The means of integration constitutethe acti_itvint,rfac,.Reuse requiresthe transfer of

experience across project boundaries. The organizational support provided for this experience

transfer isreferred to as actit_itvcontezt.

- 14-

6109

3-16
B_ed upon the goals for the specific project, as well as the organization, we must evaluate

(i) the required qualities of the object-after-reuse, (ii) the quality of the reuse process, especially

i_ integration into the enabling software evolution process, and (iii} the quality of the existing

objects-before--reuse.

4.3. The Second Model Refinement Level

Each component of the First Model Refinement (Figure 4) is further refined as depicted in

Figures 5(a-c) . It needs to be noted that these refinements are based on our current understanding of reuse and may, therefore, change in the future.

4.3.l. Objects-Before-Reuse

In order to characterize the object itselfl we have chosen to provide the following six dimensions and supplementing categories: the object's name (e.g., buffer.ada), its function (e.g.,

integer buffer), its possible use (e.g., product), its type (e.g., requirements document), its granularity (e.g., module), and its representation (e.g., Ada language). The object interface consists of

such things as what are the explicit inputs/outputs needed to define and extract the object a_ a

self-contained unit (e.g., instantiation parameters in the case of a generic Ada package}, and what

are additionally required assumptions and dependencies (e.g., user's knowledge of Ada). Whereas

the object and object interface dimensions provide us with a snapshot of the object at hand, the

object context dimension provides us with historical information such as the application classes

the object was developed for (e.g., ground support software for satellites), the environment the

object was developed in (e.g., waterfall life-cycle model), and its validated or anticipated quality

(e.g., reliability).

The resulting model refinement is depicted in Figure 5a.

6109

- 15 -

3-17
, -- n__rne

- function

-- use

- type

!- granularity

_- representation

- input/output

- dependencies

OBJECTS

BEF ORE

REUSE

- application domain

- solution domain

- object quality

Figure oa_"• Reuse Model (Objects-Before-Reuse / Refinement level 2)

A detailed definitionof the above eleven dimensions - together with example categorieshas already been presented in Section 3. In contrast to Section 3, we now have (i)a rationale for

these dimensions (see Figure 5a) aJnd (ii)understand that they cover only part (i.e.,the objectsbefore-reuse) of the comprehensive reuse model depicted in Figure 4.

4.3.2. Objects-After-Reuse

In order to characterize objects-after-reuse, we have chosen the same eleven dimensions and

supporting categories as for the objects-before-reuse. The resulting model refinement is depicted

in Figure 5b:

- 16-

6109

3-18
-- n_e

function

use

_[ type

granularity

obj - representation

LJill i m input/output

OBJECTS _ application domain

solution domain

object quality

REUSE

Figure 5b: Reuse Model (Objects-After-Reuse / Refinement level 2)

However, an object may change its characteristics during the actual process of reuse.

Therefore, its characterizations before-reuse and after-reuse can be expected to be different. For

example, an objec_before-reuse may be a compiler (type) product (use}, and may Rave been

developed according to a waterfall life-cycle approach (solution domain). The objec_-_(ter-reuse

may be a compiler (type) process (use) integrated into a project based on iterative enhancement

(solution domain).

This means that despite the similarity between the refined models of objects-before--reuse

and objects-_fter-reuse, there exists a significant difference in emphasis: In the former ca_e the

emphasis is on the potentially reusable objects themselves; in the latter case, the emphasis is on

the system in which the_e object(s) are (or are expected to be} reused. This explains the use of different dimension names: 'system' and 'system context' instead of 'object interface' and 'object

context _.

The distance between the characteristics oi" an object-before-reuse and an object-after-reuse

give an indication of the gap to be bridged in the event of reuse.

6109

- 17 -

3-19
4.3.3. Reuse Process

The reuse process consists of several activities. In the remainder of this paper, we wilt use a

model consisting of four basic activities: identification, evaluation, modification, and integration.

In order to characterize each reuse activitywe may be interested in itsname (e._.,modify pl), its

function (e.g.,modify an identifiedreuse candidate to entirely satisfy given object-after-reuse

characteristics),itstype (e.g.,modification), and the mechanism used to perform itsfunction (e._.,

modification via parameterization). The interface of each activity may consistof such things _s

what the explicitinput/output interfacesbetween the activityand the enablin_ software evolution

environment are (e.g.,in the case of modification: performed during the codin_ pha_e, _ssumes

the existence of a specification),and what other assumptions regarding the evolution environment

need to be satisfied(e.g.,existence of certain configuration control policies).The activity context

may include information about how experience is traasferred from 'the object-before-reuse

domain to the object-after-reuse domain (experience transfer),and the quality of each reuse

activity(e.g.,reliability,productivity).

This refinement of the reuse process isdepicted in Figure 5c.

- name

....... function

:.... :

- type

:i_ il .! :

- mechanism

REUSE

PROCESS

- input/output

- dependencies

- experience transfer

- reuse quality

Figure 5c: Reuse Model (Reuse Process / Refinement level 2)

In more detail,the dimensions and example categoriesfor characterizing the reuse process are:

- 18 -

6109

3-20
* REUSE PROCESS: For each reuse activitycharacterize:

+ Activity:

- name: What is the name of the activity? (e.g.,identify.generics,evaluate.generics,

modify.generics,integrate.generics)

- function: What is the function performed by the activity? (e.g.,selectcandidate objects

{x:} which satisfy certain object categories of the object-after-reuse specification 'Z';

ev_uate the potential of the selected candidate objects of satisfyingthe given system and

system context dimensions of the object-after-reuse specification'._'and pick the most

suited candidate 'xt/; modify 'x '

current development'project) k to entirely satisfy '._';integrate obiect 'x' into the

- type: What is the type of the activity? (e.g.,identification,evaluation, modification,

integration)

- mechanism: How is the activity performed? (in the case of identification:e.g.,by name,

by function, by type and function; in the case of evaluation: e.g.,by subjective judgement,

by evaluation of historicalbaseline measuremen_ data; in the case of modification: e.g.,

verbatim, parameterized, template-based, unconstrained; in the case of integration: e.g.,

according to the system configuration plan, according to the project/process plan)

+ Activity Interface:

- input/output: What are explicitinput and output interfacesbetween the reuse activity

and the enabling software evolution environment? (in the case of identification:e.g.,

specificationfor the needed objec_after-reuse / set of candidate objects-before-reuse; in

the case of modification:e.g.,one selectedobject-before-reuse, specificationfor the needed

object-after-reuse/ object-after-reuse)

- dependencies: What are other implicit assumptions and dependencies on data and information regarding the software evolution environment? (e.g.,time at which reuse activity

is performed - relativeto the enabling development process: e.g.,during design or coding

stages;additional information needed to perform the reuse activity effectively:e.g.,package specification to ins_antiate a generic package, knowledge of system configuration plan,

configuration management procedures, or project plan)

+ Activity Context:

- experience transfer: What axe the support mechanisms for transferring experience across

projects? (e.g., human, experience base, automated)

- reuse quality: What is the quality of each reuse activity? (e.g., high reliability, high

predictability of modification cost, correctness, average performance)

- 19 -

6109

3-21
5. APPLYING MODEL-BASED REUSE CHARACTERIZATION SCHEMES

We demonstrate the applicability of our model-based reuse scheme by characterizing three

hypotheticalreusescenariosrelatedto product,processand knowledge reuse:Ada generics,design

inspections,and costmodels (Section5.1}.The characterizationof the Ada genericsscenariois

furthermore used to demonstrate the benefits of model-based characterizationsto

describe/understand/motivatea given reusescenario(Section5.2),to evaluatethe costof reuse

(Section5.3),and to planthe populationofa reuserepository(Section5.4).

5.1. Example Reuse Characterlzatious

The characterizationscheme of section4 has been appliedto the threeexamples of product,

processand knowledgereuseintroducedin section2. The resultingcharacterizationsare contained

in tables2, 3, and 4:

6109

- 20 -

3-22
Dimensions

name

function

use

type

granularity

representation

dependencies

application domain

solutiondomain

Ado gene_c

buffer.aria

<element> buffer

product

code document,

package

Ado/

genericp_ckage

instantiation pararos

Reuse Examples

design inspection

assumes Adz knowledge

ground support

sw for satellites

waterfall(Fortran)

life--cyclemodel,

functionxldecomposition design

method

object quaJity high reliability

(e.g., < 0.1 defects

)er KLoC for a given

set of acceptance tests)

sel inspection .wzterfMl

certify approprigeness

of design documents

proceSS

inspection method

design stage

inform_lset of

guidelines

specification and

designdocument needed,

defectdata produced

a._umes L readable design.

qualified reader

cost model

m |,

sel cost model.fortran

predict

projectcost

knowledge

cost model

entirelifecycle

formM mathematical

modei

estimated product

size in KLOC,

complexity rating,

methodology level,

costin staff hours

a_umes a relatively

homogeneous cia_s

of problems and environment

ground support

sw for satellites

waterfxll(Fortran)

life-cycle modet

standard set of

methods

ground support

sw for satellites

waterfMl (Fortran)

life-cycle model,

stffindardset of

methods

average defect

detectionrate

(e.g.,> 0.5 defects

detectedper staff hour)

average predictability

(e.g., < G% prediction error)

Table 2: Characterization of Example Reuse Objects-Before-Reuse

- 21-

6109

3-23
Dimensions

n_me

function

use

type

granularity

representa/,ion

input/output

dependencies

spplica_ion domain

solutiondomain

objectqu_dity

Ad_ generies

string_buffer.ads

string_buffer

product

code document,

picksge

Ads

formal .nd a_tual

instsntistion params

a_umes Ads knowledge

ground support

sw for sz_llites

w.terf_dl (Ads)

fife-cyclemodel,

objectoriented

designmethod

high relixbility

(e.g., < 0.1 defects

per KLoC for s given

set of acceptance teem),

high perform_ace

(e.g.,max. response times

for L met of tests)

Reuse Examples

design inspection

sel_inspeetion.clesnroom

certify appropristenees

of design documents

process

inspection method

designsta_e

informal setof

guidelines

speciflcLtion xnd

design document needed,

defect dst* produced

_mumes • readLble design,

qualified re_ler

ground support

sw for satellites

Cleanroom (Fortran)

development model,

stepwise refinement

orienteddesign,

ststistic_ testing

high defect

detectionr_te

(e.g.,> 1.0defects

detected per staff hour)

wrt. interfacefaults

costmodel

sel cost model.a_ls

predict

project cost

knowledge

costmodel

entire life cycle

forma_ mLthemsticsl

model

estimsted product

sizeinKLOC,

complexity rsting,

methodology level,

cost inst_ff hours

a.xsumes _ relxtively

homogeneous class

of problems tnd environmenu

ground support

sw forsstellites

wsterfall (Ads)

life-cycle model,

revisedset of

methods

high predictability

(e.g., < 2% prediction error)

Table 3:Characterizationof Example Reuse Objects-After-Reuse

- 22 -

6109

3-24
Dimensions

na4_c

function

type

mechanism

input/output

dependencies

experience transfer

reuse quality

Ads generics

modify.ge nerics

modify to satisfy

target speci fication

modification

pzrameterized

(generic mechanism)

buffer._da,

reuse specification/

string buffer.ada

performed

during coding stage,

package specification

needed,

knowledge of

system configuration

plan

experience b_e

correctness

Reuse Examples

design inspection

modify.inspections

modify to satisfy

target specification

modification

uncoustrLined

sei_iuspection.w_er fall,

reuse specification/

set_inspecCion.clexnroom

performed

during planning stage,

knowledge of

project plan

human and

experience bue

correctness

co6t model

modify.cost_models

modify tosatisfy

targetspecification

modification

template-bnsed

se[ cost model.fortran

reuse specification/

sei cost model.adz

performed

during planning stage,

knowledge of historicaJ

project profiles

human and

experience base

correctness

Table 4: Characterization of Exalnple Reuse Processes

5.2. Descrlbing/Understanding/MotivaCing Reuse Scenarios

We will demonstrate the benefits of our reuse characterization scheme to describe, understand, and motivate the reuse of Ada generics as characterized in section 5.1.

We a_ume that in some project the need has arisen to have an Ada package implementing

a 'string_buffer' with high 'reliability and performance' characteristics. This need may have been

established during the project planning phase based on domain analysis, or during the design or

coding stages. This package will be integrated into a software system designed according to

- 23 -

6109

3-25
object-oriented principles. The complete reuse specification is contain_ in Table 3.

First, we identify candidate objects based on some subset of the object related characteristics stated in Table 3: string buffer.ada, string_buffer, product, code document, package, Ada.

The more characteristics we use for identification, the smaller the resulting set of candidate

objects will be. For example, if we include the name itself, we will either find exactly one object

or none. Identification may take place during any project stage. We will assume that the set of

successfully identified reuse candidates contains 'buffer.ada', the object characterized in Table 2.

Now we need to evaluate whether and to what degree 'buffer.aria' (as well as any other

identified candidate) needs to be modified and estimate the cost of such modification compared to

the cost required for creating the desired obiect 'string_buffer' from scratch. Three characteristics

of the chosen reuse candidate deviate from the expected ones: it is more general than needed (see

function dimension), it has been developed according to a different design approach (see solution

domain dimension), and it does not contain any information about its performance behavior (see

object quality dimension). The functional discrepancy requires iustantiating object 'buffer.ada' for

data type 'string'. The cost of this modification is extremely low due to the fact that the _eneric

instantiation mechanism in Aria can be used for modification {see Table 4). The remaining two

discrepancies cannot be evaluated based on the information available through the characterizations in section 5.1. On the one hand, ignoring the solution domain discrepancy may result in

problems during the integration phase. On the other hand, it may be hard to predic_ the cost of

transforming 'buffer.ada' to adhere to object-oriented principles. Without additional information

about either the integration of non-object,-oriented packages or the cost of modification, we only

have the choice between two risks. Predicting the cost of changes necessary to satisfy the stated

object performance requirements is impossible because we have no information abou_ the

candidate's performance behavior. It is noteworthy that very often practical reuse seems to fail

because of lack of appropriate information to evaluate the reuse implications a-priori, rather than

because of technical infeasibility.

6109
In case the object characterized in Table 2 has been modified successfully to satisfy the

specificationin Table 3, we need to integrate it into the ongoing development process. This ta_k

needs to be performed consistentlywith the system configuration plan and the process plan used

in this project.

The characterization of both objects (before/after-reuse) and the reuse process allow us to

understand some of the implications and risks associated with discrepancies between identified

reuse candidates and target reuse specification.Problems arise when we have either insufficient

information about the existence of a discrepancy (e.g.,object performance quality in our example),or no understanding of the implications of an ident,ifiediscrepancy (e.g.,solution domain in

our example). In order to avoid the firsttype of problem, one may either constrain the

identificationprocess further by including characterist,icsother than just the object related ones,

or not have any objects without 'performance' data in the reuse repository.If we had included

'desiredsolution domain' and 'object performance' as additional criteriain our identificationprotess,we may not have selected object 'buffer.ada'at all. If every object in our repository would

have performance data attached to it,,we at,least would be able to establish the fact that there

existsa discrepancy. In order to avoid the second type of problem, we need have some (semi-)

automated modification mechanism, or at leasthistoricaldata about the cost involved in similar

past situations. It is clearthat in our example any functional discrepancy within the scope of the

instantiation parameters is easy to bridge due to the availabilityof a completely automated

modification mechanism (i.e.,generic instantiation in Ada). Any functional discrepancy that cannot be bridged through this mechanisms poses a larger and possibly unpredictable risk.Whether

itis more costly to re--design'buffer.ada'in order to adhere to object oriented design principlesor

to re-develop it,from scratch is not obvious without past,experience.

Based on the preceding discussion, the motivational benefits are" that we have • sound

rationale for suggesting the use of certain reuse mechanisms (e.g.,automated in the case of Ada

packages to reduce the modification cost), criteria for populating a reuse repository (e.g.,do

6109

- 25 -

3-27
exclude objects without performance data to avoid the unnecessary expansion of the search

space), criteria for identifying reuse candidates effectively according to some reuse specification

(e.g., do include solution domain to avoid the identification of candidates with unpredictable

modification cost), or certain types of reuse specifications (e.g., require that each reuse request is

specified in terms of all object dimensions, except probably name, and all system context dimensions).

5.3. EvaluatinK the Cost of Reuse

We will demonstrate the benefits of our reuse characterization scheme to evaluate the cost

of reusing Ada generics as characterized in section 5.I.

The general evaluation goals are (i)characterize the degree of discrepancies between a given

reuse specification(see Table 3) and a given reuse candidate (Table 2), and (ii)what is the cost of

bridging the gap between before-reuse and after-reuse characteristics.The firsttype of evaluation

goal can be achieved by capturing detailed information with respect to the object-before--reuse

mud obiect-a/'ter-reusedimensions. The second goal requires the inclusion of data characterizing

the reuse process itselfand past experience about similar reuse activities.

We use the goal/question/metric paradigm to perform the above kind of goal--oriented

evaluation [6,8, 10]. It provides templates for guiding the selectionof appropriate metrics based

on a precise definitionof the evaluation goal. Guidance existsat the level of identifyingcertain

types of metrics (e.g.,to quantify the object of interest,to quantify the perspective of interest,to

quantify the quality aspect of interest).Using the goal/question/metric paxadigm in conjunction

with reuse characterizations like the ones depicted in Tables 2, 3, and 4, provides very detailed

guidance as to what exact metrics need to be used. For example, evaluation of the Ada generic

example suggests metrics to characterize discrepancies between the desired object-after-reuse and

allbefore-reuse candidates in terms of (i)function, use, type, granularity, and representation on a

nominal scale defined by the respective categories,(ii)input/output interface on an ordinal scale

- 20 -

3-28

6109
'numberof instantiationparams',(iii) applicationandsolutiondomainsonnominalscales,and

(iv)qualitiessuchasperformancebasedonbenchmarktests.

5.4. Planning the Population of Reuse Repositories

We will demonstrate the benefits of our reuse characterization scheme to populate s reuse

repositorywith generic Ads packages as characterized in section 5.1.

Reuse is economical from a project perspective if the effort required to bridge the gap

between an object-before-reuse (availablein some experience base) and the desired object-afterreuse is less than the effort required to create the object-after-reuse from scratch. Reuse is

economical from an organization's perspective if the effortrequired for cresting the reuse repository islessthan the sum of allproject-specificsavings based on reuse.

Based on the above statement, populating a reuse repository constitutes an optimization

problem for the organization. For example, high effortfor populating a reuse repository may be

justifiedif (i)small savings in many projects ate expected, or (ii)large savings in a small number

of projects are expected. For example, object 'buffer.ada'could have been _ransformed to adhere

to object oriented principlesprior to introducing it into the repository.This would [lave excluded

the project specificrisk and cost.

The cost of reusing an object-before-reuse from an experience base depends on itsdistance

to the desired object-after-reaseand the mechanisms employed to bridge that distance. The cost

of populating a reuse repository depends on how much effort is required to transform existing

objects into objects-before-reuse.Both effortstogether are aimed at bridging the gap between the

project in which some objects were produced and the projects in which they ate intended to be

reused. The inclusion of a generic package 'buffer.ada' into the repository instead of specific

instances 'integer_buffer.ada'and 're_l-bttffer.ada'requires some up-front transformation (i.e.,

abstraction). The advantage of creating an object 'buffer.aria'is that it reduces the projectspecific cost of cresting object 'string_buffer.ads' (or any other buffer for that matter) and

- 27 -

3-29

6109
quantifies the cost of modification.

Finding the appropriate characteristics for objects-before-reuse to minimize project-specific

reuse costs requires a good understanding of future reuse needs (objects-after-reuse) and the reuse

processes to be employed (reuse process). The more one knows about future reuse needs within an

organization, the better job one can do of populating a repository. For example, the objectbefore-reuse characteristics of Ada generics in Table 2 were derived from the corresponding

object-after-reuse and reuse process characteristics in Tables 3 and 4. It would have made no

sense to include Ada generics into the experience base that (i) are not based on the same instantiation parameters as all anticipated objects-after-reuse because modification is assumed via

parameterized instantiation, (ii) do not exhibit high reliability and performance, and (iii) have not

the same solution domain except we understand the implication of different solution domains.

Without any knowledge of the object-after-reuse and reuse process characteristics, the task of

populating a reuse repository is about as meaningful as investing in the mass-production of concrete components in the area of civil engineering without knowing whether we want to build

bridges, town houses or high-rise buildings.

8. A REUSE-ORIENTED SOFTWARE ENVIRONMENT MODEL

Effective reuse according to the reuse-oriented software development model depicted in Figure 2 of Section 2 needs to take place in an environment that supports continuous improvement,

i.e., recording of experience across all projects, appropriate packaging and storing of recorded

experience, and reusing existing experience whenever feasible. Figure 6 depicts such an environmeat model.

6109

- 28 -

3-30
Reuse-Oriented Software Environment Model

Organizational Process Model

characterize

identify

project

characteristics

set

goals

execute

select

methods & tools

for construction

select

methods & tools

for analysis

SW Development

Process Model

construct

analyze

Record__euse

I

i . objec'_

beforePete:

Experience Base

Figure 8: Reuse-Oriented Software Environment Model

Each project is performed according to an organization process model based on the

improvement paradigm [2, 5]:

1. Characterize: Identify characteristics of the current project environment so that the

- 29 -

6109.

3-31
appropriate past experience can be made available to the current project.

2. Plan: (A) Set up the goals for the project and refine them into quantifiable questions and

metrics for successful project performance and improvement over previous project performances

(e.g., based upon the goal/question/metric paradigm [6]).

(B) Choose the appropriate software development process model for this project with the supporting methods and tools - both for construction and analysis.

3. Execute: (A) Construct the products according to the chosen development process model,

methods and tools.

(B) Collect ;he prescribed data, validate and analyze it to provide feedback in real-time for

corrective action on ;he current project.

4. Feedback: (A) Analyze the data to evaluate the current practices, determine problems, record

findings and make recommendations for improvement for future projects.

(B) Package the experiences in the form of updated and refined models and other forms of

structured knowledge gained from this and previous projects, and save is in an experience ba_e

so it can be available to future projects.

The experience base is not a passive entity that simply stores experience. It is an active

organizational entity in the context of the reuse-oriented environment model which - in addition

to storing experience in a variety of repositories - involves the constant modification of experience

to increase its reuse potential. It plays the role of an organizational "server" aimed at satisfying

project-specific requests effectively. The constant collection of measurement data regarding

object._-after-rense and the reuse proc_es themselves enables the judgements needed to populate

the experience base effectively and to select the best suited objects-before-tense to satisfy

project-specific reuse needs based upon experiences. The organizational process model based on

the improvement paradigm supports the integration of measurement-basedanalysis and construction.

6109

- 30 -

3-32
Formoredetailabout the reuse-oriented environment model, the reader is referred to [71.

7. CONCLUSIONS

The model-based reuse characterization scheme introduced in this paper has advantages

over existing schemes in that it (a) allows us co capture the reuse of any type of experience, (b)

distinguish_ between objects-before-reuse, object.s-after-reuse, and the reuse process itself, and

(c) provides a rationale for the chosen characterizing dimensions. In the past most the scope of

reuse schemes was limited to objects-before-reuse.

We have demonstrated the advantages of such a model-based scheme by applying it to the

characterization of example reuse scenarios. Especially its usefulness for evaluating the cost of

reuse and planning the population of reuse repositories were stressed.

FEaally, we gave a model how we believe reuse should be integrated into an environment

aimed at continuou_ improvement based on learning and reuse. A specific [nstantiation of such

an environment, the 'code factory', is currently being developed at the University of Maryland

[121. In order to make reuse a reality, more research is required towards unde_tanding and conceptualizing activities and a.spect_ related to reuse, learning and the experience base.

8. ACKNOWLEDGEMENTS

We .thank all our colleagues and graduate students who contributed to this paper, especially

all members of the TAME and CARE project.

6109

- 31-

3-33
9. REFERENCES

[i] V.R. Basili,"Can We Measure Software Technology: Lessons Learned from Eight Years of

Trying', in Proc. Tenth Annual Software Engineering Workshop, NASA Goddard Space

Flight Center, Greenbelt, iVfD,December 1985.

[2] V.R. Basili, "Quantitative Evaluation of Software Methodology", Dept. of Computer

Science, University of Maryland, College Park, TR-1519, July 1985 [also in Proc. of

the Fimt Pan Pacific Computer Conference, Australia, September 1986].

[3] V.R. Basili, "Viewing Maintenance a_ Reuse-Oriented Software Development", IEEE

Software Magazine, $anuary 1990, pp. 19-25.

[4] V.R. Basili and H. D. Rombach, "Tailoring the Software Process to Project Goals and

Environments", Proc. of the Ninth International Conference on Software Engineering, Monterey, CA, March 30 -April 2, 1987, pp. 345-357.

[5] V.R. BasiIi and H. D. Rombach, "TAME: Integrating Measurement into Software

Environments", Technical Report TR-1764 (or TAME-TR-1-1987), Dept. of Computer

Science, University of Maryland, College Park, MD 20742, June 1987.

[6] V.R. Basili and H. D. Rombach "The TAME Project: Towards Improvemen_Oriented

Software Environments', IEEE Transactions on Software Engineering, vol. SE-14, no. 6,

June 1988, pp. 758-773.

[7] V.R. Basili and H. D. Rombach, "Towards a Comprehensive Framework for Reuse: .-k

Reuse-Enabling Software Evolution Environment", Technical Report (UMIACS-TR-88-92,

CS-TR-2158), Department of Computer Science, University of Maryland, College Park,

MD 20742, December 1988.

[81 V.R. Basili and R. W. Selby, "Comparing the Effectiveness of Software Testing Strategies", IEEE Transactions on Software Engineering, vol.SE-13, no.12, December 1987,

pp.1278--1286.

[9] V.R. Basili and M. Shaw, "Scope of Software Reuse", White paper, working group on

'Scope of Software Reuse', Tenth Minnowbrook Workshop on Software Reuse, Blue

Mountain Lake, New York, July 1987 (in preparation}.

[10] V. R. Basili and D. M. Weiss, °'A Methodology for Collecting Valid Software Engineering

Data', IEEE Transactions on Software Engineering, vol.SE-10, no.3, November 1984,

pp.728-738.

[11] Ted Biggemta_'f, "Reusability Framework, Assessment, and Directions", IEEE Software

Magazine, March 1987, pp.41-49.

[12] G. Caldier_ and V. R. Basili, "Reengineering Existing Software for Reusability", Technical

Report (UMIACS-TR-90-30, CS-TR-2419), Department of Computer Science, University

of Mm'Tland, College Park, MD 20742, February 1990.

[13] P. Freeman, "Reusable Software Engineering: Concepts and Research Directions", Proc.

of the Workshop on Reusability, September 1983, pp. 63-76.

[14] R. Prieto-DiaT. and P. Freeman, "Classifying Software for Reusability", IEEE Software,

vol.4, no.t, January 1987, pp. 6-16.

[15] IEEE Software, special issue on 'Reusing Software', vol.4, no.l, January 1987.

[1{3] IEEE Software, special issue on 'Tools: Making Reuse a Reality', vol.4, no.7, July 1987.

[17] G.A. Jones and R. Prieto-Diaz, "Building and Managing Software Libraries", Proc. Compsac'88, Chicago, October 5-7, 1988, pp. 228-236.

- 32 -

6109

3-34
[18] A. Kouchakdjian, V. R. Ba-¢ili, and S. Green, "The Evolution of the Cleanroom Process in

the Software Engineering Laboratory", ]EKE Software Magazine (to appear 1990).

[19] F. E. McGarry, "Recent SEL Studies", in Proc. Tenth Annual Software Engineering

Workshop, NASA Goddard Space Flight Center, Greenbelt, MD, Dec. 1985.

[20] R.W. Selby, Jr., V. R. Basili, and T. Baker, "CLEANROOM Software Development: An

Empirical Evaluation", [EEE Transactions on Software Engineering, vo[. SE-13, no. 9,

September 1987, pp.I027-i037.

[21] Mary Shaw, "Purposes and Varieties of Software Reuse", Proceedings of the Tenth

Minnowbrook Workshop on Software Reuse, Blue Mountain Lake, New York, July,

1987.

[22] T. A. Standish, "An Essay on Software Reuse", IEEE Transactions on Software

Engineering, vo[. SE-10, no. 5, September 1984, pp.494--497.

[23] W. Tracz, "Tutorial on 'Software Reuse: Emerging Technology'", IEEE Catalog Number

EHO278-2, 1988.

i24} J. Valett, B. Decker, J. Buell, "The Software Management Environment", in Proc. Thirteenth .A.nnua[ Software Engineering Workshop, NASA/Goddard Space Flight Center,

Greenbelt, MD, November 30, 1988.

[25] M. V. Zelkowitz (ed.), "Proceedings of the University of Maryland Workshop on

'Requirements for a Software Engineering Environment', Greenbelt, MD, May 1986",

Technical Report TR-1733, Dept. of Computer Science, University of ._lary[and, College Park, .'v[D 20742, December 1986 [to be published as a book, Ablex Publ., 1988].

- 33 -

6109

3-35
S6ftwam

Viewing Maintenance

as Reuse-Oriented

Software Development

'VkRIW' R, BSl_i. UnNe_Jil)'of M@ryla¢_at College P8_

Treating maintenance

as a reuse.oriented

development process

provides a choice of

maintenance

approaches and

improves the overall

evolution process.

f v_ believe that soft_are should be developed with the goal of maximizing the reuse of experience in the

form of knowledge, processes, produc_

and tools, the mainmnance process is logically and ideally suited to a reuse-oriented development process. There are

many reuse models, but the key issue is

which process model is best suited to the

maintenance problem at hand.

In this article. [ present a high-level or.

ganizadonaJ paradigm for development

and maintenance in which an orE-anizadon can learn from development and

maintenance ca.sl_ and then apply d'_c

paradigm co several maintenance process

models. Associated with the paradigm is a

mechanism for setting measurable goals

so you can evaluate the process and the

product and learn from experience.

Ane_'_r_mon offl_Um'_de_,rM_m u theIm_,no_

pm_'_0Q at t_ Con_'en_ on So/tw_e ,%_inte.

nance tnOctober 19_L

Maintenance models

Most software s_tems are complex, and

modification requires a deep understanding of the functional and nonfunctional requirements, the mapping of

.F'uncuons ro sv3tem components, and the

interaction of components. Without good

documc'nlanon of the requirements, design, and code with respect to tuncuon,

traceability, and structure, maintenance

becomes a difficult, expentive, and errorprone task. As early as 1976, Les Beladv

and Manny Lehman reported on the

problems with the evolution of IBM

0S/360J The literature is filled with similar examples.

Maintenance compr_es several types of

activities: correcting fauhs in the ,system.

adz.p_ng t.he sy3tem to a changing opet-at.

ing environment (such as new terminah

and operating-system mod_c_ons), and

aclapdng the s_tem to changes in the

original requiremen_ The new s_tem is

January 1990 074o,.74_9/9o/oIoo/(3o19/soi.ooo 19901EE_ 19

6109

3-36
Old =If_m Nm

Requinlments ;eQuinlmmlts--_

Design

I

Cocle_ /

I Code

_ ,1LOuick-fix process rnoctel.

Old system

Requirements

I

Co¢le

I

Test

I

An,lJys_--

Hw m/ztlm

-.R_uirements [---

|

IRIpzrQ 2. lnteralNe-enhaneement model.

Old system Reposito,"y Now sl'slom

Requirements.-.-.(RI)_ R_uirements

I I

Oeslon _(Oi) -..--- Oesign

I J

Co¢le------------(CI)-,-.-- Code

I I

Test_(n)----. Test

Figure 3, Full-reuse model.

like the old system,yet it isalso different in

a specific set of characteristics.

You can view the new version of the system as a moditicadon of the old system or

as a new _Tstem that reuses many of the old

%y_tem's components. Although these two

views have many aspects in common, they

are very different in how you organize the

maintenance process, the effects on future products, and the support environmen ts requirc_L

Consider the following three maintenance process models:

• the quickffix model.

• the icerarive.en hancemen ¢model, and

• the fxtll-reuse model.

All three models reuse the old system

and so are reuse-oriented. Which model

you choose for a paracular modificauon is

determined by a combination of managemerit and technical decisions that depend

on the characteristics of the modification.

the future evolution of the product line.

and the support environment available.

Each model assumes that there is acomplete and consistent set of documents de2O

6109

scribing the existing .system. from require.

ments through code. Although this mav

be a naive assumption in practice, a side

effect of this article's presentation should

b¢ to motivate organizations to g'ain the

benefits of having such documentation.

Quick-fix model. The quick-fix model

represents an abstraction of the wpical approach to software ma/ncenance. In the

quick-fix model, you rake the existing system, usually just the source code. and

make the necessary changes to the code

and the accompanying documentation

and recompile the system as a new version. This may be as straightforward as a

chan_e to some internal component, like

an error correction involving a single

component or a su'ucmraJ change or even

some functional enhancement.

Figure l demonstrates the flow of

change from the old s_stem's source code

to the new version's source code. It is assumed _ but not always true _ that the

accompanying documentation is also updated. You can view this model as reuseoriented, since you can view the model as

creaung a new system by reusing the old

swtem or as simpJy modifying the old swstern. However, viewing it in a reuse orientation gives you more freedom in the

scope of change than viewing it in a modification or patch orientation.

Itm-a_e.en.haneemem model, lterative

enhancement z is an evoluuonary model

proposed for development in environments where the complete set of requirements for a system was not fully understood or where the developer did not

know how to build the fullsystem. Although iterativeenhancement _ proposed as a development model, itiswell

suitedtomaintenance. Itassumes a completeand consistent set of documents de.

scribing the system. The iteradve-enhanccment model

• starts with the existing system's re.

quirements, design, code, test. and analysis documents;

• modifies the set of documents, starting

with the highest-level document affected

by the changes, propagating the changes

down through the full set of documents;

and

• at each step of the evolutionary, pro3-37

tess. lets you redesign the system, based

on anai_is of the exisung system.

The process assumes chat the maintenance organization can anal_e the existing product, characterize the proposed

set of modifications, and redesign the current version where necessary for the oew

capabilities.

Figure 2 demonstrates the flow of

change from the highestdevel document

affected by. the change through the low-

,t-level document. This model supports

the reuse orientation more explicidy. An

environment that supports the iteradveenhancement model clearly supports the

quick-fix model.

Full-reuse model. While iterative enhancement starts with evaluaung the existing system for redesign and modification. a full-reuse process model starts with

the requirements analysis and design of

the new system and reuses the appropriate requirements, design, and code from

any earlier versions of the old system, it

assumes a repository of documents and

components defining earlier versions of

the current system and similar systems.

The fulbreuse model

• starts with the recluirements for the

new system, reusing as much of the old

system as feasible, and

• builds a new s_tem using documents

and components from the old system and

from other systems available in your re.

pository;, you develop new d ocumen tsand

components where necessary.

Here, reuse is explicit, pac 'kaglng of existing components is necessary, and analysis is required to select the appropriate

componen_

Figure 3 demonstrates the flow of vanons documents into the various document repositories (which are all part of

the larger repository,) and how those repositories are accessed for documents for

the new development. There is an assumption that the items in the repository

are classified according to a variety of

characteristics, some of which 1 describe

later in the arucle.

This repository may contain more than

just the documents from the earlier .system _ it may contain documents from

earlier versions,documents from other

products in the product line, and some

IEEESoftware
generic reusable forms of documents. An

environment that supports the fuji-reuse

model clearly supports the other two

models.

Model diffemmem. The difference between the last two approaches is more one

of perspective than s_e. The full-reuse

model frees you to design the new system's solution from the set of solutions of

similar systems. The iterative-enhancement model takes the last version of the

cma_nt system and enhances it.

Both approaches encourage redesign,

but the full-reuse model offers a broader

set of items for reuse and can lead co the

development of more reusable components for future systems. By contrast, the

iterative-enhancement model encourages

you to tmlor exishng s-_tems to get the extensions for the new system.

Reuse framewod¢

The existence of multiple maintenance

models fauns several questions. Which is

the most appropriate model for a particular environment. _ a particular sy, tem? a

particular set of changes? the task at

hand._ How do you improve each step in

the process model you have chosen? How

do you minimize overall cost and maximize overall quality?

To answer these questions, you need a

model of the object of reuse, a model of

the process chat adapts chat object to its

target applicauon, and a model of the reused object within its target application.

Figure 4 shows a simple model for reuse.

In this model, an object is any software

proce_ or product and a transformadon

it the set of activities performed when reumng that o_ect,

The model step= are

• identifying the candidate reusable

pieces of the old object.

• under.aanding them,

• mtxiif_*ng them to your need& and

• integrating them into the process.

To flesh out the model, you need a

framework for categorizing object=, tranv

formations, and their contexL The framework should cover various categories. For

example, is the object of reuse a process or

a product,a In each category, there are

various classificauon schemes for the

product (such as requirements docuJanua_ 1990

Rgum 4. Simple reuse model

ment, code module, and test plan) and

for the process (such as cost estimauon.

dsk analysis, and design).

Fntmework dintemsiom. There are a

variety of approaches to classif,Ang reusable objects, most notably the faceted

scheme offered by, Ruben Prieto-Dfaz and

Peter Fre.manJ I offer here a scheme chat

I offer here a scheme

b'wt cat_or/zu b_ree

aspects ofmuse: _

reusable o_ect_ the

reusable oNect" s

con_xt, and fhe process

of transforming

th=t obj_=t.

categorizes three aspects of reuse: the remable object, the reusable object's context. and the processof transforming chat

object. This scheme owes much to ideas

presented at the 1987 Minnowbrook

Workshop on Software Reuse.

Object dimensions include:

*Reuse-object .type. What is a characterizarlon of the candidate reuse object?

Sample process classifications include a

design method and a test technique:

product classifications include source

code and requirements documents.

• Seif-contmnedness. How independent

and understandable is the candidate ob-

.ject? Sample classifications include s_ntactic independence (such as a dam.cou.

piing measure) and specification

precision (such as functional notation

and English).

• Reuse-object quality. How good is the

candidate reuse object? Sample clatsificadons include maturity. (such as the number"of swtems using it), complexity (such

as _ctomauc complexity), and reliability

Context _ [

Transforrmtion _----- f New oO,ect ]

(such as the number of tailures dunng

previous use).

Context dimensions include:

• Requiremen_ domain. How similar

are the requirements domains of the candidate reuse object and the current proy

ect, _ Sample clattifications are applicauon

(such as ground-support software for _av

eilites) and distance (such as same application or similar algorithms buc different

problem focus).

• Solution domain. How similar are the

evolution processes that resulted m the

candidate reuse objects and the ones used

in the current project.; Sample cla_i|icacions are process model (such as the

waterfall model), design method (such as

funcuon decomposition), and language

(such as Fortran).

• Knowledg, e-ttansfer mechanism. How

is information about the candidate reuse

objects and their context passed to current and future projects? People, such as a

subset of the development team, provide

a common knowledge-transfer mechanism.

Transformation dim nsions include:

• Transformation type. How do you

characterize transformation activities?

Sample classifications include percent of

change required, direction of change

(such as general to domain-specific or

project-specific to domain-specific), modification mechanism (such as verbatim.

parameterized, template-based, or unconstrained), and idenuficauon mechanitro (such as by name or by functional

requirements).

• Activity integration. How do s_u integrate the transfurmation activities into the

new system development? One sampJe

clamification is the phase where the activiv/is performed in the new development

(for example, planning, requiremenra development, and design).

* Transformed quality. What is the contribudon of the reuse object to the new

system compared to the ohjecm'es set for

it? Sample clamificauons are reliability

(such as no failures associated with that

component) and performance (such as

satisfying a dming reqturement).

21

6109

3-38
Com_ the models. When appMng

the reuse framework to maintenance, the

set of reuse objects is a set of product documents. You compare the models co see

which is appropriate for the current set of

changes according to the framework's

three dimensions.

First consider the muse.object dimension:

The objects of the quick-fix and iteradye-enhancement models are the set of

documents representing the old sqstem.

The object of the fuibreuse model is any

appropriate document in the repository.

For self-conc_inedness, all the models

depend on the unit of change. The quickfix model depends on how much evolution has taken place, since the s-,'stem mav

have lost structure over time as objects

were added, modified, and deleted. In iterative enhancement, the evolved system's structure and understandability

should improve with respect to the application and the classesof changes made so

far. In the full-reuse model, the evolved

system's structure, understandability, and

gene_lity should improve: the degree of

improvement will depend on the quality

and maturity of the repository.

For reuse,object quality, the quick-fix

model offers litde knowledge about the

old object's quality. In iterative enhancement, the analysis phase provides a fair asseasment of the s_stem's quality. In full

reuse, you have an assessment of the reuse

object's quality across several systems.

Now consider the context dimensions:

For the requirements domain, the

quick-fix and iterative-enhancement

models assume that you are reusing the

same application -- in fact, the same projeCL The full-reuse model allows manageable variation in the application domain,

depending on what is available in the repository.

For the solution domain, the quick-fix

model assumes the same solution smactare exists dunng maintenance as during

development. There is no change in the

basic design or sn'uctureof the new .swtern. In iterativeenhancement, some

modification to the solution su'ucture is

allowed because redesign is a part of the

model. The full-reuae model allows major

differences in the soludon su'ucmre: You

can completely redesign the system from a

structure based on funcdonal decompo_

don co one based on object-oriented design, for example.

For the knowledge-transfer mechanism,

the quick-fix and iterauve-enhancement

models work best when the same people

are developing and maintaining the system. The full-reuse model can compensate for having a different team. assuming

that you haw application specialists and a

well-documented reuse-object repository.

The quick.fix model's

weaknesses are that the

modMc_ion is usually a

pat_ t_t is not

well.documented, partly

deslroytng the system

_re and hindering

fu/vre evolu//on.

Last. consider the transformation dimension:

For the transformation tTpe, the quickfix model typically uses activities like

source<ode lookup, reading for understanding, unconstrained modification. and recompitation, herative enhancement typically begins with a search

through the highest4evel (most abstract)

document affected by. the modificauon.

changing it and evolving the subsequent

documents to be consistent, using several

modification mechanisms. The full-reuse

model uses a library search and

modification mechanisms; those selected

depend on the type of change. In full

reuse, modification is done off-line.

For activi_ inte_-auon, all activities are

performed at same time in the quick-fix

model. [teraWre enhancement associates

the activities with all the normal development phases. In full reuse, you identify the

candidate reusable pieces dunng project

planning and perform the other activities

dunng development.

For transformed quality, the quick-fix

model usually works best on small, wellcontained modifications because their effects on the s_stem can be understood and

verified in context. [terative enhancemenc is more appropriate for larger

changes where the analysis phase can provide be_terassessmentof the _II effectsof

changes. Full reuse isappropriate for

largechanges and major redesigns.Here.

analysts and performance history, of the

reuse objectssupportquality.

Applying the models, Given these differences, you can analyze the maintenance

process models and recommend where

they. might be most applicable.

But first, consider the relationship between the development and maintenance

process models: _bu can consider development to be a subset of maintenance.

Maintenance environments differ from

development environmenus in the constraints on the solution, customer demand, timeliness of response, and nrganizauon,

Most maintenance organizauons are set

up for the quick-fix model but not for the

iterative-enhancement or full-reuse models, since they are responding to timeliness _ a system failure needs to be fixed

immediately or a customer demands a

modification of the system's functionality.

This is best used when there is little

chance the system ssall be modified ag-mn.

Clearly, these are the quick-fix modet's

strengths. But its weaknesses are that the

modification is usually a patch that is not

wetl-clocumentecL the structure of the s_-

tern has been partly destroyed, making future evolution of the system difficult and

error-ridden, and the model is not com.

patible with development processes.

The iterative-enhancement model allows redesign that lets the ,system structure evolve making future modifications

easier. It focuses on making the svstem as

good as possible. It is compatible with development process models. It is a good approach to use when the product will have

a long life and evolve over time. In this

case. ff timeliness is also a constraint, you

can use the quick-fix model for patches

and the iterative<nhancement model for

long-term change, replacing the patches.

The drawbacks are that it is a more cosdv

and possibly less timely approach (in the

IEEE Software

6109

3-39
short run) than the quick-fix model and

provides little support for generic components orfuture, similar systems.

The full-reuse model gives the maintalner the greatest degree of freedom for

change, focusing on long-range development for a set of produc_ which has the

side effect of creating reu._ble compOnents of all kinds for future developmenu. It is compatible with development

proce_ models and, in fact. is the way development models should evolve. It is best

used when _ou have muitiproduct environments or generic development where

the product line has a long life. Its drawback is that it is more costly in the short

run and is not appropriate for small modLqcauons (although you can combine it

with other models forsuch changesl.

Mv assessment of when to apply these

models is informal and intuitive, since it is

a qualitative anaivsis. To do a quantitative

analysis, you would need quantitative

models of the reuse objects, transformauons, and context. You would need

a measurement framework to characterize (via clarification), evaluate, predict.

and moavate management and technical

decisions. To do this. you would need to

apply to the models a mechanism for generating and interpreting quantitative

measurement, like the goal/question/metric paradigm. *I (See the box on

p. 24 for a description of this paradigm

and its application to choomng the appropriate main tenance process model. )

Rmme mmblem

There are many support mechantsms

nec_ to achieve maximum reuse that

have not been sufficiently emphasized in

the literature. In this article, I have presented several: aset of maintenance models, a mechanism for choosing the appropriate models based on the goals and

characteristics of the problem at hand.

anda measurement and evaluation mechanism. To support these activities, there is

a need for an improvement paradigm that

helps organizations evaluate, learn, and

enhance their software processes and

produc_, a reuse-oriented evolution environment that encourages and supporu

reuse, and automated support for both

the paradigm and environment as well as

for measurement and evaluauon.

January1990

6109

Improvement paradigm. The improvement paradigm _ is a high-level org-anizadonal process model in which the organization learns how to improve iu products

and process. In this model, the org'anizadon should learn how to make better decisions on which process model to _ for

the maintenance of its future products

based on past performance. The paradigm has three parts: planning, analysis,

and learning and feedback.

In planning, there are three integrated

activities that are iterauvely applied:

• Characterize the current project environment to provide a quantitative analysis

of the environment and a model of the

project in the context of that environment. For maintenance, the characteriza.

tion provides product-dimension data.

change and defect data. cost data and

customer-context data for earlier versions

of the system, information about the

cla._.s of candidate components available

in the repository for the new system, and

any feedback from previous projects with

experience with different models for the

types of modificauons required.

* Set up goals and refine them into

quantifiable questions and metrics using

the goal/question/metric paradigm to

get performance that has improved compared to previous projects. This consists of

a top-down analysis of goals that iterativehl

decomposes high-level goals into detailed

subgoais. The iterauon terminates with

subgoais that you can measure direcdy.

• Choose and tailor the appropriate

3-40

construction model for this project and

the supporting methods and tools to satisfv the project goals. Understanding the

environment quantitatively lets you

choose the appropriate process model

and fine-tune the methods and tools

needed to be most effective. For example,

Imo_ng the effect of earlier applications

of the maintenance models and methods

in creating new projects from old systems

lets _ou choose and fine-tune the appropriate process model and methods that

have been most effective in creating new

systems of the type required from older

versions and component parts in the repository.

In analysis, you evaluate the current

practices, determine problems, record

the findings, and make recommendations

for improvement. You must conduct data

analysis during and after the project. The

goal/question/metric paradigm lets you

trace from goals to metrics and back,

which letsyou interpret the measurement

in context to ensure a focused, simpler

analysis. The goal-driven operational

measures provide a framework for the

kind of anal_is you need.

In learning and feedback, you organize

and encode the quantitative and qualitative experience gained from the current

project into a corporate information base

to help improve planning, development,

and azse_ment for future proJects. You

can feed the resulLs of the analysis and interpretation phase back to the organization to change how it does business based

on explicitly determined successes and

failures.

In this way, you can learn how to improve quality, and producuvity and how to

improve goal definition and a.._sessment.

You can _ the next project with the experience gamed from this and prevtous

projec_ For example, understanding the

problems associated with each new version of a system provides insights into the

need for redesign and redevelopment.

Reu_e.oritmted env/mnment. Reuse

can be more effectively achieved in an environment that supporra reuse. (See the

article by Ted Biggerstaff and Charles

Richter; for a set of reusability technotogaes and the arucle by myself and Dieter Rombach s for a set of environment

23
C. oallquestionimc,,bicparadigm

The cJoai/quesaorVmetocmwacligm represents asystemam

pro_ for se_ng pmiect goals (tai_'ea to the needs of an orgamz_ion) ar_ _elinmg them in an ooerab_el, tractaJ0leway. Goals

_e _ w_ aset of qua_tltia_e questions _1 medels

specify maces anti data for collsction. The O'actabiilyof tits software-engineering process sul_oons _e analysis of the coilectm

data algolcomputad metncs in the apl_ognate contextof me qua.

t_on¢ mode_ ar¢l gois, feed_ (by integratingco_ and

anaJyu¢ acWibes), and learning (by defining the &oprognatesynprocedure forlower level into higherlevel pieces of expertenos.)

The goals are defined in terms of gurpose (why _e pmiect is

being anaJyzed), perspectNe (tl_ models of interestand the pont

of view of _ ar_,_ysis),and the enwronment (me context of the

pro_v_. When measuring a ixoduct or process, youask questions

intlll'ee general c_agones:

• I:_,_u_ or processclefini_n,

• clellnitionof the qualityperspec_ves of intemsL and

•feediml_.

Pmcluot 0e(inmon irctudes ptlysicaJ atl_'_oulesof me pm0uct,

co_l, d'k_ngesand detects, en¢lthe contextin_ the product wll

be used. Process defini_Mn inctudas a model of me proceed,an

evalualion of conformance to the medel, and en assessment of me

pmfflct-si::)e¢_c documents _ experience withme applical_n.

Oelinitlonof the qu_'y pef'4DecWes of interestin¢_ucles_e quality models used (suctt as reliai=_ityancl user frienOli_ess)and the

i_te_ of the clamcoile_ed relative to the moclels.

Feeclb_c_ involves the ream of informatmn for imgrow_ the

p_ and pn:x:ess0ased on me qualitypemDecuve of interest.

The folowing _san inform= _tion of the goat/que.on/metde paredigm to a pamcular maintenance pm0lem. The answers to

some o!_ ques_ons are o0vfous. The answem to omem assume

a database of experience that managemer_ mustestzmateif it isnot

avadab_l.

Goai_. The goaPclefinitionprtase has three Dens:

• Purpose: AnaJyze_e new procluctreClu=mmen{sro cleletmine

_he aq:t:lmg_atsew_lutionmoOel.

• Pempeclve: Examine _e cost of me oJrrentenhancement

fulum evolui0n ofthe system from me orgar=zatlons Ix_nt of view.

• En_mnment:. AIol_ witll me star_rcl enmmnmental fac_onl,

like resource ancl pmDlem factors, you woJld like to pay sl_loal

atmrr_on to me context _imensmns in me reuse framework.

In me requlmmen_ clomaR1,you typica_ use p_cluct ob_

from the same a,oOlk:a_onclom_n, although you can ci'K_se of)-

iects from other Oomtns in me repository, if _ey are generally

z_caue.

The solutiondomain delinee _ _ m_els, me.otis, and

tools used in the OevetoOmentofme old produc_ Ifyou olan to use

the same l:xcx:essesfor me evofving producL mere ts no pmOlem

reuse. If fulure evolullon_ (::nangesto _e solutiondomain. me full-reuse rnc_el lets you make mese changes, butat the

co_ of reusalgless oftha old pmduof.

For know_e_je_rans/er _, you must cletermme _t

tofm of dooJment_on is nee_e¢lto trar_ter the mojirecl al_icatio_ _ and I:)rodtJ_ l_rt::n_ec_em me ma,_ta_nem, if the

maJnmnanca groug i= tt_ same as me developme_ groug, the

malorfrankermeohanism is ttle peogle.

Pmdu_ detlnltlon. W'_t_the goaldefined, you _ clellneyour

product. In _le example, mere are several proauc_s:me new product to be _ (the new vers.onof _ sylltem). _e old versions,ar_

any o_"w relevenl aOjec_ in me repos_forymat may be reussd.

For me category of _ atmbutes, samt_e quesions am:

How many requirements are there forthe new system? What is

me reaping otthe requirements to system components inthe old

system? How indel:_ndent are me components to be modified in

me old system? What is the complemty of _e old system and its

indivlduelcomponents? What canclldateol_ectsare availablein

tl_ repositoW and what are their ot_iect,context, and transformation dassdlca_ons? How many now redu_rements, cate<Jorized

by class (such as size, type. and whether it iSa new, modified, or

deleted requirement) are there that am not in the old system?

How many components, categonzed by class(suct_as size ana

type of c_ange) in the old system must be changed, a0cled, and

deleted?

For me category of changes and detects, sarnt_e questions are:

How many errors, faults, arid fa_ums (categonzed by c_ss) are

mere assoaatecl_ _e requ_ments and components mat need

to be changecl?What is theProfileof gast and future changes tothe

system, categonzed by c_ss (suct_as cost and number of times a

component has been and mus_ be _anged)?

For the cate(jon/of cost. sample quemtons are: What was the

cos_ of the on_naJ system? Whal was the cost of eac_ prior Veto

s_n? Wha _sme cost of each nnor requ,'ement change 10yclass?

What is the estimaled cost of mo0ilying me old system to meet the

new re_Jirements? What is tt_ estimated cost of bLul_ng a new

system, reusaxJthe exponence anO_ of the old system and the

repostory?

For me category of customer context, sample cluest_ns are:

What are me variouscustomerclessesanclhow aremey using the

system? What are the estimated fu_Jre en_encements based on

your analystsof customer profiles,past modticaBons, and the state

of tscnnotogy in me alX_r-.a_n domain?

Quality perspective of Inte_mt. With the grocluotdefined, you

now clefine the pe_pect_es for me qua_tias that you am wing to

achieve.

Youshouldmai_ea model of the system'sevolution,along w_h its

a._oaatecl costs. Base¢lon me clamfromthe evofut_onof this system arid _er systems, as well as on _e _ of me set

of new redu_rements, me mo¢lel should let you estimate the cost

i0enef_i assooatsd _th eachof the mree process medets a_

iel you ct+m_oseme al_r_ie one.Parameters for me moael w¢l

in¢_uclesuch items as me omiected system lifesme,the numDer of

future related systems, anO me prelected cost of changes for vanous classes ofreq_rements.

FN_ba¢_ W_h me quat_ persnect=ves cletined, you can now

get me mtom_at_onneeded to ,ml:_ove me pmo_x;t or l:Xocass.The

fee_oa_ st_ould _ with clee_er insgl'_ inlo the moael

our env_0nment.

Sample clues_onsinclude: Is the mode( acoropnate? How can

I1_ be impn3ve_? How c_1 the c_lf_sons be in'l_ed?

goid¢ There are many relevant goaL¢ Consider tha folIow=rK:jex_

• EvaJu_e the modiflcalion acOvit_s in the reuse mode# to improve _ Examine the cost and cotmcmeas oftha resultingaOjects fromme customer's point ofv_ew.

• Eva_m _e components of me ex_ting system to _etarr_ne

_e_t_r toreuse mere. _rr.ne the*rindedanclenceand funcoonaJ

a_oro_ateness from _ ,,_wOont of reuse _ future systems.

. _ the at_irWof a sot of code con'©onents to he integrated

intothe cun'enlsystem from the clevelof:_"s polm a_view.

• Encourage_ reuse of a set of repositorycomponents i0udtfo_

reuse. Examine the rewarO s_uc_ure from me manager's and

de_tfol_r's points of view.

24

6109

3-41

IEEE Soflware
chat-acterisdcs.) Software-eng/neering environments provide such things as a project databases and support the interacdon

ofpeople with methods, tooLs,and project

data. However. experience is not controlledby.the projectdatabase nor owned

by the organucadon _ soreuse existsonly

implicidv.

For effective reuse, you need to be able

to incorporate the reuse process model in

the context of developmenu "_bu need to

combine the developmem and maintenance models to maximize thecontextdimensions. You need to integratecharacterization,evaluation, prediction, and

too,ration into the process. You need to

support learning and feedback to make

reuse viable. I propose that the reuse

model can e.,ast in the context of the improvement paradigm, making it possthle

to support all these requirements.

Amommed support. The improvement

paradigm and the reuse-oriented process

model require automated support for the

database, encoded experience, and the

repository, of pre_ous proJects and reusable components. A special issue of lk2EJ:2

._/hmze' offered a set of automated and

automatable technologqes for reuse. You

need to automate as much of the measurement process as possible and to pro-

_ide a tool environment for managers and

engineers to develop project-specific

goals and generate operational definitions based on these goalsthatspecifythe

metricsneeded forevaluation.This evaZu.

adon and feedback cannot be done inreal

time without automated support.

Furthermore, automated support will

help in the postmortem analysis. For example, a %ystem like Tailoring a Measuremerit Environment. _ whose goad is to instantiate and integrate the improvement

and goal/question/metric paradigms

and help tailor the development process.

can help support the reuse-onenmd process model because it contains mecha.

ncsrns to support systemauc learning and

re%L_'.

ApplTing the TAaME concept to maintenance provides a mechanism for choosing the appropriate maintenance process

model for a particular project and prosides data to help you learn how to do a

better job of maintenance.

he approach you take to maintenance depends on the nature of

the problem and the sizeand complexity of the modification. Viewing

maintenance as a reuse-oriented process in the context of the improvement

paradigm givesyou a choice of maintenance models and a measurement

framework. You can evaluate the

strengths and weaknesses of the different maintenance approaches. Learn how

References

I. L Betadv and M. Lehman. "A Model of

l_urge Program Development. IBM .._'¢.u,nm

f, No.3. 1976,pp. _22_.25Z

%:R.Ba._li and A.J. Turner,-herau_ Enhancement A Practical Technique for

Sol.are Development." f/-_." Tram. &_-

usawEng..Dec. 1975. pp. 390-396.

3. R. Pdeto-Diazand P. Freeman. ""Clalli/_ng

Sol.are tbr ReusabitiW."/7-2.'F.._Raam..Jan.

i987.pp. 6-16.

4. V.R.Baslii."QuantitativeK_-aJ, uauon of

Sofn_-areMethodology," Tech. Report

1519.Computer Science Depc. Univ.of

Maryland.College Park. Md..julv1985.

5. %:_ Bauli and H.D. Roml_u:h. "The TAME

Project:Towards lmprovemem-Onented

Soft,care Enmxonmen*%° _ Tra_L Soft,-

Vk'mr R.lhmifiis a progessorat the Universny of

Maryland at College Park's Institute for .-_-

ranted Computer Studies and Computer Science Dept. Hh research interesut include me-4-

sunng and evaluaung software development in

indusmal and government settings. He is a

founder and principal of the Sofr_.re Eng_-

neenng Laboratory., a joint venturebetween

the Nauonal Aeronautics and Space Admimstrauon, the Univer_tyof MarylancLand CornpurerScienceCorp.

Bas,li received a BS in mathematics from

to refine the various process models, and

create an experience base from which to

support further management and technical decisions.

ffyou do not adapt the maintenance approach, you will find it difficult to know

which process model to use for a particular project, whether you are evolving the

system appropriately, and whether you

are maximizing quality and minimizing

costover the system lifetime. .>

w_e/-'n_..June 1988. pp. 758-773.

6. V.R. Basili a.d D.M. Weis_ "A Methodoiogy for Collecting Valid Software-Engineering Daa_L"_'_/'_."Trans. ,g0fiware Eng..

Nov. 1984.pp. 728-738.

7. V R. Basili and H.D. Rombach,

"Towards a Comprehensave Framework

for Reuse: A Reuse-EnablingSoftware.

Evolution Environment." Tech. Report

UMIAC.S-TR-88-92. Computer Science

Dept.. Univ. of Maryland. College Park.

Md.. Dec. 1988.

8. T. Big_-¢staff. "Remabilkv Framework.Assesunent, and Direcuons." _25 _nm_

March 1987. pp. 41-49.

9. speaal issue on tools for reuse. LEE/'."Soflwa_Julv 1987. pp. 6-72.

Fordham College, an MS in mathemaucsfrom

SylmCUSeUniversity. and a PhD incomputersctence from the Universiw of Texas at Austin. He

is a member of the l FEE Computer Sociewand

is editor.in.chief of Tl_._ Tmn.mmons on.Soflwa_

Kn&n_tw_rig.

Address quesuons about this arucle to Ehsili

at Computer Science Dept.. A.V. Williams

Bldg.. Rm. 4187. University of Marx.land. Coilege Park. MD 20742.

January 1990 Copyright _c_ 1990 The Institute of Electrical and Electronics Engineers, Inc.

Reprintecl with permission from IEEE SOFTWARE,

10662 Los Vaclueros Glrole, Los Alamitos, CA 90720

25

6109

3-42

L .! !
SECTION 4 - SOFTWARE TOOLS STUDIES

The technical paper included in this section was originally

prepared as indicated below.

• "Evolution Towards Specifications Environment:

Experiences With Syntax Editors," M. Zelkowitz,

Information and Software Technology, April 1990

6109

4-1
Evolutiontowardsspecifications

environment:experienceswithsyntaxeditors

M V Zeikowitz

Language-baaed editors have been thoroughly studied over the

last 10 years and have been found to be less effective than originally thought. The paper revJews some relevant aspects of such

editors, describes experiences with one such editor (Support).

and then describes nvo current projects that extend the syntaxediting paradigm to the specifications and destgn phases of the

software life-cycle.

software destgn, environments, specification, syntax editors

SYNTAX EDITORS

Syntax-editing (or alternatively [angnage-based editing)

is a technique that had its beginning about 20 years ago

(e.g., Emily0 and blossomed into a major research

activity 10 years later (e.g., Mentor 2, CPSJ). During the

mid-1980s, major conferences were often dominated by

syntax-editing techniques4.L Many of these projects,

however, have since been terminated or have taken a

much lower profile. There are few widely used commercial products that use this technology. Why'?

This paper briefly introduces the concept of syntax

editing, describes one particular editor, and explains

some experiences in using it. It is then shown how the

syntax-editing paradigm is powerful but perhaps misapplied in the domain of source-program generation.

Just using a syntax, editor for source-code production

does not result in significantly higher productivity. By

integrating specification generation with this source-code

production, however, the author believes that increased

productivity can be provided by making more of the lifecycle visible to the programmer. Two extensions to the

current environment are described that apply syntax

editing within a specifications environment to provide

additional functionality over that of standard syntax

editors.

With a conventional editor, the user may insert an

arbitrary string of characters at any point in a file. and a

later compilation phase will determine if there are any

errors. With a syntax editor, however, only those choices

Department of Computer Science and Institute for Advanced

Computer Studies. University of Maryland, College Park. MD 20742.

USA.

Paper submttted: 27 August t989.

Revised version rece|ved: 20 November 1989.

permitted by the language grammar can be inserted, and

the generation of source program and the processing of

the program's syntax are intertwined operations. For

example, for the statement nonterminal < stmt >, there

are only a limited set of statement types that are permitted and only those legal strings can be entered by the user

in response to that nonterminal on the screen.

The user interface is a major component of syntax

editors. Depending on editor design, syntactic constructs

can be specified via a mouse and pull-down menus, function keys on the keyboard, or special editing prompt

commands, If the cursor is pointing to the <strut>

syntactic unit and the user specifies the if statement, then

the text

if <expr > then

< strut >

else < strut >

will replace < stmt > on the screen. Each nonterminal

<...> is considered as a single editing character and

syntactic constructs must be added or deleted in their

entirety. In essence, the programmer is building the

source-program parse tree in a top-down manner.

Pure syntax-editing is a simple macro-like substitution, and such macro substitutions exist in several conventional editors. For example, Emacs and Digital's

LBE (Language Based Editor) both permit such substitutions anywhere in a program. Here, however, editors

that go beyond simple substitution are being considered.

Screen layout is often specified (e.g. unparsing the program tree to a "pretty-printed' display), semantic information is usually checked (e.g., variable declarations,

mixed types), and often the editor is part of an integrated

package or environment of editor, interpreter, and

debugging and testing tools.

Early on. many advantages of a syntax editor were

stated:

• Source-program generation would be efficient as a

single mouse or function key click would generate an

entire construct.

• Productivity would increase as numerous errors such

as missing begin----end pairs could not occur and mixed

mode expressions would immediately be found by the

editor at the point of insertion. Users could more

easily use an unfamiliar language.

• Screen layout would be predefined, providing a

uniform structure to all programs.

vol 32 no 3 aprtl 1990

6109

0950-5849/90/030191-08(_ 1990 Butterworth& Co (Publishers)Lid

4-2

191
s The integrated package of tools enables testing and

debugging to proceed more rapidly.

As shall be seen, the last of these reasons does indeed

seem to be true: each of the others, however, seems to

have a serious drawback as well as the supposed benefit.

As an example, the Support environment, designed by

the author, is briefly described as an instance of the

integrated syntax-editing genre. It has many of the

features implemented in such tools and is the basis for

the extensions to specifications described later.

Support design

Support is an integrated environment built to process the

CF-PASCAL subset of PASCAL and was used for three

years (until the course contents changed) as the programming tool in the introductory programming course at the

University of Maryland. It runs on both Berkeley Unix

and IBM PC systems.

Design

Major features of Support include the following.

Text input Support uses both the command and function key mechanisms for input. If the cursor (represented

by reverse video) covers the < strut > unit, a menu at the

bottom of the screen gives the available choices. For

example, to insert an if statement, either a response of .2

or depressing function key 2 (on the PC keyboard) will

insert the if construct.

Support also permits textual substitution for any syntactic unit. A user can type in an arbitrary line of characters, and an internal LALR parser builds the subtree

for that construct. If the root of that subtree is permitted

by the current cursor position, then it is attached to the

program tree at that cursor position.

Using either input mechanisms, invalid syntax can

never be entered. Using the menu for input permits only

correct responses, and, for textual input, if the parser

cannot resolve the typed-in text to a correct syntactic

unit, an error is displayed and the program is not modified.

Windows Horizontal windows dividing the CRT screen

are the major interface with the user. Each tool within

Support controls its own window, and from two to four

windows will typically be displayed at any one time.

Tools Various tools within Support aid in program

design and development. The relationship among procedures in a program is handled by the Design window;

an interpreter executes partially developed programs and

includes features such as variable and statement tracing

and breakdown monitoring. Statement trace and statement coverage windows are part of this structure. Data

are displayed via the variable trace and the run-time

display windows.

As an extension to the textual input mode. a small (i.e..

size of screen) text editor called the Character Oriented

EDitor (or COED) was implemented. Users insert or

modify arbitrary sequences of characters in this window.

have the text processed by the LALR parser mentioned

Table I. Background ofsaulents

Semester 1 Semester 2

First university computer course (%) 73 82

Took this course previously (%) 12 9

Took high-school course (%) 59 55

Never previously used computer (%) 26 24

Own microcomputer (%) 49 5[

above, and then have the text inserted into the program

tree at the appropriate place in the program. The user

can also pull an arbitrary section of program text into

this window for modification. This also gave an easy cutand-paste feature and the ability to move sections of

code around in the program as a means to address some

of the syntax-editing deficiencies that turned up.

Language and screen displays The grammar processed

by Support (e.g., CF-PASCAL) is defined via an external

data file that defines the syntax, some semantics, and

screen layout. This feature turned out to be a major

factor in allowing Support to be extended for other

applications.

Experiences

Support was used from 1986 until 1989 in Computer

Science [ by approximately 200 to 300 students each

semester. During the first two semesters data were

collected from the 543 students that enrolled in the

course. The background of the students is summarized in

Table 1. As shown, about 75% had previous experience

with programming and about half own their own

computer.

Based on a 1 to 5 rating scale (l = poor), students who

owned their own computer (and presumably had more

experience in programming) rated satisfaction with Support lower than those without their own computer (2.8 to

3.2). More revealing, students rated Support's text-editing capabilities much lower than those of an IBM mainframe also used during the semester _2.7 versus 3.7 for

one semester, 3.3 versus 3.8 for the other). The author

believes that users with experience with general text

editors felt more restricted by the syntax-editing paradigm. On the other hand, novices with no previous

ex!_rience felt aided by such restrictions.

Students using Support rates its debugging capabilities

higher than those available on the IBM mainframe (3.8

versus 3. I for one semester. 3.0 versus 2.9 for the other).

The PC system was also rated as more available compared with the mainframe (3.9 versus 2.8 for one semester, 3.0 versus 2.9 for the otherL Other results are presented elsewhereL

In summary, syntax editing seems to be viewed as a

restriction on program development, but the integrated

development and testing environment appears to be

desired. A tool that simply develops source text does not

seem to produce a large productivity increase. The

results here are comparable to those found with other

editing environments.

192

6109

4-3

information and software technology
Retrospective

Afterseveral yearsof use and several redesigns and

enhancements based on user needs and experiences, the

four advantages claimed for such editors can be

addressed more clearly. As shall be seen, for most of the

advantages, there are some serious problems to overcome.

Efficient generationofsome prognuns

For enteringmuch of thetextofa program, thisistrue,

but unfortunatelythereare enough complicationsto

slowdown experiencedprogrammers. For example,the

PASCAL ifstatementhasan optionalelseclause.Should

the editorautomaticallyinsertthe elseand have the

programmer deleteitifnot desired,or shoulditnot be

includedwith thecorrespondingneed toadd itifwanted?

Support chose the lattermodel, but ineithercase the

editorwillbe wrong about halfofthetime.

In Support'scase,thescreendisplaysno information

aboutoptionalsyntacticunits,so theuserneedsto know

where such unitsare located.There are two modes of

moving forwardthrougha program:the---key moves to

thenextsyntacticunitdisplayedon thescreen,whilethe

enterkey issimilarbut willinsertany optionalphrases

betweendisplayedsyntacticunitsas itmoves. In POE's

case_ the oppositeoccurs.All optionalunitsare displayedinitially,and the usermust deletethem ifnot

specifically wanted.

A more seriousconsequenceisthatsyntacticunitsare

added top-down, but programmers usuallythink of

algorithmsas sequentialactions.For addingnew statements,thereisnot much differencebetween sequential

insertionand top-clowndevelopmentof theBNF:

<stmtlist> ::= <strut>; <strutlist>I

< strut >

as both generate statements in a left-to-right manner.

Insertion of expressions such as A+ B'C, however,

essentially means to build the tree in postfix order (e.g.,

"+", "'A". "*", "'B", "'C"), which is not the natural

sequence.

In some environments, such as CMU's GandalP, this

top-down linking to the program's parse tree is embedded in the user interface: in Support's case, however, the

LALR parser mentioned earlier was added. Straight text

will be parsed and entered in its true infix format. The

COED editor within Support was a valuable extension

that permitted ix'ogrammers to add small sections of

program text (up to 22 lines of input) without violating

the basic top.down nature of program generation in a

syntax editor.

Earlydetectionofsyntaxand semanticerrors

While true,thisisnot much of a benefitifitsconsequences are considered.Experienced programmers

generallydo not make many syntaxerrorsas theyenter

text,althoughnovicesdo.(This might explain Support's

greaterpopularityamong non-programmersthanamong

programmers. )

There arecaseswhere thissupposed benefitisactually

a hindrance.Ifan experiencedprogrammer thinksof a

sequenceofcode toenterand makes an errorininput,a

standardeditorwillignoretheerrorand continueenteringdata.Afterfinishingenteringcode.the programmer

can fixtheearlierproblem.With a syntaxeditor,however,onlycorrectsyntaxcan beentered.The systemwill

usuallyhaltand beep untilcorrectiveactionistaken.

Thus thereisa disruptionin a trainof thoughtwhere

some deep semantic issueneedsto be put aside(and

forgotten?)to fixsome simplesyntax.

Looking at both of thesereasons,as languagesget

more complex (e.g.,ADA) syntaxeditingmight make

more sense,but in relativelysimplelanguages,likePASCAL and C, thereseemstobe few benefits.There islittle

experiencewith sucheditorsforcomplex languages.Arctutusm isa prototypeof an ADA editor,but itwas not

made commerciallyavailable.

Screen layout is predefined

This is also true, but again the predefined layout might

not be what the programmer wants in all cases. It certainly helps the novice generate nicely indented listings.

but as the programming task grows more complex, the

number of special cases increases.

The placement of comments seems to pose a problem

with all such editors. Comments are generally outside the

language's defining BNF. Where do they appear in the

listing? In Support they are tagged before the defining

nonterminal. This works in some cases, but not all.

Uniform debuggingand testingtools

This againistrue,but a syntaxeditorisnot needed for

this feature. An integrated framework and data repository are needed for a source program. The current interest

in CASE (computer-aided software engineering) tools

exemplifies this. and Support is simply a CASE tool with

a syntaxeditor fora base.

In summary, the experiences with Support are by no

means unique and closely mimic experiences others have

had with syntax editors. For example, Mentor, initially

developed about eight years earlier at INRIA, has had a

similar pattern of development and use". Similar to

experiences with Support:

• Novices used menus but experiencedprogrammers

rarelydid.

• Experienced programmers wanted the full-screen

Emucs editor for textual input and modification (providing functionality similar to the COED editor described here) using automatic parsing and unparsing of

the Mentor input.

• Switching between Mentor and Emacs was difficult

due to the inherent problems in placement of

comments. On the other hand, Mentor was a powerful

source-code maintenance system due to the integration of many program analysis tools for obtaining

semantic information about a program. But just as in

Support's case, such tools are mostly a function of

vol 32 no 3 april 1990

6109

4-4

193
Mentorbeing an integrated environment and not

simply an editor.

In conclusion, the drawbacks seem to be as serious as the

advantage in syntax editing, which probably explains

their lack of growth and popularity since the early '80s.

As a final comment, source-code development is often

stated as 15% of total life-cycle costs. Even if the editor

reduced coding time to zero, that would still mean a

productivity improvement of only 15%. Industry is looking for more than that.

SPECIFICATIONS

The previous discussion indicates that while syntax editing of source programs is a powerful technique, it probably has minimal effect on programmer productivity. As

requirements, specification and coding take up to 75% of

the costs to develop a system, however, improving those

phases of the life-cycle might have a more dramatic

impact on productivity. In addition, a mechanism to

improve the flow between speofications'to design to code

would probably lead to fewer interface errors, hence

decreasing the effort needed in testing and further

increasing improved productivity.

For coding source programs, there are several programming techniques: procedural languages (e.g., PASCAL, C, ADA, COBOL), applicative languages (e.g., LISP,

PROLOGI, object-oriented programming (e.g.. SMALL.

TALK. C+ 4-), etc. Their relative strengths and weaknesses for specific applications are fairly well established.

For specification of a program, there are also several

models (e.g., axiomatic, denotational, algebraic, functional); however, as yet there is no clear consensus as to

which is most effective and how each applies to different

application domains. This is still very much an open

research question, with many ongoing projects studying

various specification strategies.

Given the powerful syntax editing paradigm and its

relative inability at improving source-code generation,

the author decided to investigate it within a specification

domain. After all. most specification languages have a

syntax and semantics more complex than most programming languages, and some anecdotal data do seem to

indicate that programmers would prefer syntax editors

for sufficiently complex languages.

As stated previously, Support processes a language

defined by an external grammar file, and it is constructed

as a set of independent tools, each writing to virtual

windows that are mapped to the actual computer screen.

By modifying this grammar and by adding new support

tools. Support becomes an interface "shell' )'or a series of

integrated environments. It can be used as a language

processing recta-environment by providing the capabilities to read input, parse text, build parse trees, and

manipulate multiple windows simultaneously. Using

Support, two such extensions were developed that are

described here: AS ') (based on algebraic specifications)

and FSQ (based on functional specifications).

(I) sort sequence/ao_ something/ia

(9] constructor

(8} epslion;

f.l) eona : something3equence;

(5) operation head : aequence .* something ia axiom

(a) _eaa(e_silon)===.t

(7) he°a(co,_(x,Y)) == X;

(8) operation count: sequence-,. integer is axiom

O) c*,,nt(epsilo.)=--o;

(lo) co,,nt(co,..,(X,Y))=--i+co,,.tCY);

{12) esad;

Figure 1. E.rample of sequence specification

AS* for executable specifications

An algebraic specification is a series of axioms that link

together the operations that can be applied to an abstract

data type. As an extension to the Support environment, a

specifications extension based on these algebraic axioms

has been defined.

An AS* specification contains three features:

• a set of sort names that define new abstract objects and

their constructors

,, a signature, which defines a set of defined operations

tbr manipulating the abstract objects

• a set of oriented equations (or axioms) that relate the

defined operations and constructors to each other

Figure I gives a simple example of a specification for a

sequence. Line ( I) specifies that a class of objects of sort

(i.e.. type/"sequence' is being defined and indicates that

the new object will require as a parameter a sort "something" that will be specified in a later binding. A generic

class of sequences that will be instantiated by this later

binding to "something" is being defined. Lines (2)----(4)

define the two constructors needed to create an object of

this sort: "epsilon" to return the empty object of sort

"sequence" and "cons', which takes an element and a

sequence and returns a new sequence with the element in

it. The functionality of each constructor is given after its

name with the sort name 'sequence implied as last (e.g.,

"epsilon" returns an empty 'sequence' and "cons" requires

a "something" and a "sequence" and returns a 'sequence'.)

'Epsilon' initializes objects of this sort and "cons" creates

new complex objects.

This object is manipulated by means of a set of defined

operations. In this simple example, operations "head"and

"count" are given with their signatures on lines (5) and

(8). They are defined by the rewrite rules (axioms) on

lines (6)----(10). Head" says to return the element last

included into the sequence by the "cons" function, while

"count" returns 0 for "epsilon' fi.e., an empty list) or I plus

the size of any non-null list with the first element

removed. As can be seen. the formal definitions of each

function includes recursive algorithms for computing its

value by reducing any complex object to a finite set of

applications of the constructor functions. The "?"on line

16}is equivalent to an error condition, and the implementation stops execution and issues an error message when

194

6109

4-5

inlbrrnatlon and soi"twarctechnology
this occurs. (That is, it is illegal to take the "head' of an

empty list.)

For example, the list <X,Y,Z> is created by the

construction:

cons(X.cons(Y,cons(Z,epsilon)))

and the operation "count' uses this construction, as in:

count( < X.Y,Z > )=

I +count( < Y,Z>)=

I + I +count(<Z>) ='

I + I + 1 +count(<epsilon>)=

I+1+I+0=

3

The use of the Knuth--Bendix algorithm _: defines a

proof of adequacy of the resulting algebraic equations by

showing the equivalence of supposedly equal terms to the

same ground (i.e., constant) terms. As the Knuth--Bendix algorithm is based on an ordering transformation

from one term to a 'simpler" term, however, the algorithm defines an operation that can be "executed' and

proven to terminate. Therefore, any set of axioms that is

"Knuth--Bendix" can be transformed mechanically into

a series of transformations that can be executed in some

programming language, in this case PASCAL.

Similar to Larch and Larch/CLU 'J, AS* specifications

are independent of the underlying programming language and must be defined relative to any concrete language, Libraries of generic specifications can be used to

form the basis of a reuse methodology where the generic

specification is refined to an explicit specification in a

spectfic programming language by binding the generic

sorts to specific programming language types. In this

case PASCAL is considered as the implementation vehicle.

so to create ASPascal, the extension to PASCAL that

contains AS" specifications, a link between a PASCAL

object and an AS* sort must be indicated.

An explicit specification is created by a refinement of a

generic specification via the use clause, as in:

sort intsequence is

use sequence [integerl

end:

' which refines the generic sort,'sequence" given earlier and

indicates that a new sort "intsequence' is created by

modifying "sequence' with a binding of PASCAL integers

to the free sort "something" of Figure I. The operations

"head" and "count" in "sequence" become "intsequence_

head' and intsequence_count' in the new sort. although

the actual mapping to their new names is handled automatically and of no concern to the programmer.

The interface assumption is made that an explicit sort

specification

sort newsort is ...

is equivalent to the PASCAL type declaration

Specification PASCALsource Executable

file file file

Figure 2. AS* too/set

type newsort = ...

The primitive PASCAL scalar types (char. Boolean,

integer, real) may all be used in abstract sort definitions.

and any explicit sort may also be used in a refinement.

Thus

var A: intsequence;

simply creates a PASCAL variable A, which is of type

"intsequence'.

The power of this system is in alternative bindings. For

example, real sequences could be created as

sort realsequence is use sequence [real] end:

Similarly. a sort such as a "book' could be used to create

a type "library' as

sort library is use sequence [book] end:

As stated earlier, syntax editors might have greater use

with more complex source languages, and the integrated

tool set forms an effective basis for a CASE tool. Therefore, a prototype AS* system was built on top of the

existing Support environment. Figure 2 represents this

initial system that has been constructed. The four components are as follows.

AS/Suplmrt

AS/Support is a modification to the Support environment described earlier, which provides text-editing capabilities for creating specifications. It is also the control

module that invokes the verification tool, ASJSupport

first checks axioms within operations for syntactic

consistency. Because of the language-based design of the

underlying environment, only syntactically correct

axioms with the syntax

operation_.name( < expression-list > ) = = < expression>

can be entered by the user. After the user builds a sort.

AS/Support formats the sort syntax into an appropriate

format suitable for PROLOG and invokes AS/Verifier as a

subprocess. AS/Verifier reads these axioms and checks

executability. After passing all executability checks

through ASiVerifier, the user may save the ASPascal

program in a library for later translation by AS/PC or

for later incorporation into another ASPascal program.

vol 32 no 3 april 1990

6109

4-6

195
In case of failure, the causing axiom, if it can be deter.

mined, is highlighted to allow the user an interactive

mechanism to change the specifications.

AS/Verifier

AS/Verifier. a PROLOG program, is called by AS/Support

and verifies the set of axioms via the Knuth--Bendix

algorithm. In general the axioms need to be a noetherian

term rewriting system, and, if possible, AS/Verifier

makes this determination. Of course, as the general

problem is undecidable, in some cases the results are

inconclusive. In any case, after one pass through the

axioms, AS/Verifier will either succeed or indicate which

axiom is currently failing so that the user may modify the

definition and try again. As stated previously, if any

error is found, an appropriate message is relayed back to

AS/Support and displayed to the user.

For example, the "sequence" definition of Figure [ will

be converted to the following clauses and passed to AS/

Verifier:

as*--sort (sequence, [epsilon, cons, head. count]).

function (1, epsilon, [], sequence).

function (2. cons, [something, sequence], sequence).

function (3. head, [sequence], something).

function (4. count. [sequence], integer).

axiom (5, head (epsilon), "'?").

axiom (6. head (cons(x,y)),x).

axiom (7. count (epsilon),0).

axiom (8. count (cons(x,y)), 1 +count(y)).

(as,--sort is the internal name for a new "sort'.) The

Knuth--Bendix algorithm either shows convergence of

the axioms or indicates additional axioms that are

needed; it may not indicate, however, when sufficient

axioms have been added in the case of not converging

rapidly enough (the usual problem with undecidability

results). In this case, AS/Verifier does a single pass over

the axioms and then terminates, indicating where the

problem is with the axioms.

AS/PC

AS/PC is the translator, written in YACC, that converts

specifications into standard PASCAL source programs.

The code generally consists of a sequence of if statements, each checking the validity of the left-hand side of

the axiom before executing the Knuth--gendix reduction.

PC

PC is the standard system PASCAL compiler. At this

point, the specifications have been converted to standard

PASCAL, and any comparable compiler can be used for

compilation and execution.

Specifications appear in programs as function calls in the

host programming language. To translate such calls, it is

necessary to determine, for each function reference.

which explicit specification is being used. Thus a reference to "head(thing)' where "thing" is an "intsequence" is

translated to a call to "intsequence_head(thing)', while

"head(realthing)" will result in "realsequence-head(realthing)' for variable "realthing' of sort "realsequence'.

(The details of the AS* implementation appear elsewhere/'.)

It should be clear that this translation does not result

in a particularly efficient implementation; as a specifications or prototyping tool, however, efficiency is not its

overriding purpose. The goal is to provide easily a correct extension to an existing system and to provide a

verification tool, e.g., an oracle, that can be used as a test

against an eventual efficient solution to the problem.

FSQ for software reuse

In the previous section, AS* was described as an environment based on an algebraic specification model for program specifications. Support is also being applied using

the functional correctness model )_. In this model, both a

program and a specification are viewed as functions, and

techniques have been developed to determine if both

represent the same transformation of the data. This

model of program development is briefly summarized

and how Support is modified to aid in this process is then

demonstrated.

Functional correctness

A specification/is a function. A box notation [...] is used

to signify the function that a given string of text

implements, If character string :t represents a source

program that implements exactlyJ_ then [cc] = f, and it is

stated that '_ is a solution tof

Sequential program execution is modelled by function

composition. Ira sequence of statements s = s.;s,_: .., s,,

then [s] = [sl] o ... o [s,] = [s,] ( .,. )[sl])) ... ). Using

techniques from denotational semantics, each statement

s is a function from a program state to another state.

Each program state is a function from variables to values

and represents the abstract notion of data storage. Symbolic trace tables are usedl I to derive the state functions

for if, while, and assignment statements.

Program design is accomplished by converting a specification functionJ_ written in a LiSP-like notation, into a

source program a, and then showing that [a] = J_ The

specification f is called the abstract function and the

program _t the concrete design. Given this functional

model, the basic theorem for functional correctness _* can

then be proved. Program p is correct with respect to

specification function f if and only iff _ [p].

This model can be applied to three separate activities:

• Program verification. Iff is a function and if p is a

program, determine if they are the same function, i.e..

[p] = f, or more generallyf_ [p].

• Program design. If f is a function, then develop a

program p such that [p] = f.

• Reverse engineering. If p is a program, then find a

function/such that [p] = f

196

6109

4-7

information and software technology
_re is the aesning for the sesment

_XJ < _yt _>es=_xp;b|=py_;C:mJx_;

not('x' < 'y') ->a:=_x';b:=_y';c:='y';

I_:_ _ mnmmm

Stat_ent ) Funczional specification

a == 'x_. IT->_:-'x'

b := 'y'.. IT-_:='y'

if a < b the.. [a < b ->c:=a;

I not(a • b) ->c:=b;

program sample (input, output) ; <.decs .... >

beg

IIII

end.

Figure 3. FSQ derived meaning for program fragment

FSQ extensions

The use of existing program fragments when developing

a new program is one technique being studied for

improving programmer productivity. Often. however, it

is first necessary to determine exactly what these program fragments or procedures do. As formal specifications are rarely used, and documentation is generally

quite inadequate, programmers are reluctant to use an

existing procedure written by another from. some previous project since the mental effort to truly understand

that procedure is quite high.

To study this problem, the Support environment was

extended with a new tool, Function Specification Qualifier (FSQ), to aid this process of determining the specifications for an existing component of a system. FSQ-[. a

first prototype of this tool, is described.

FSQ is an additional tool to the basic CF-PASCAL

programming environment in Support and works as

follows:

• A programmer emther budds a program using Support

(and hence uses FSQ as a verification tool) or else

reads one from the file system using the LALR parser

internal to Support to build the parse tree (making

FSQ a reverse engineering tool).

• The cursor is moved over the section of program that

needs to be verified and FSQ is invoked via the command .fsq.

• FSQ symbolically executes each statement and determines its meaning. This is relayed back to the user,

who either accepts this meaning (e.g.. its specification)

or manually simplifies it to another meaning.

• The derived meaning is stored in the Support syntax

tree. If any part of a program is symbolically executed

and already has a derived meaning, then that meaning

will be used without further analysis. This meaning

can then be carried along as part of the file system

repository information on that object. Future users of

that object will not have to derive the meaning again.

Over time, more and more procedures in the system

repository will have such derived meanings, making it

more efficient to reuse such objects frequently.

Figure 3 shows a sample execution of FSQ. The top

meaning window shows the desired result from the

execution, the middle program trace window indicates

each partial result, and the bottom window highlights the

section of the source program that is under study•

FSQ executes over the covered portion of Figure 3 as

follows:

• (I) For a: = "x" the system derives the conditional T --,

a: = 'x'. (This is similar to the LiSP "cond' and means

'True implies a: = 'x'.')

• (2) For b: = "y" the system derives the conditional T

b: = 'y'.

• (3) For c: = a the system derives the conditional T --,

c;=a.

• (4) For c: = b the system derives the conditional T

c..=b.

• (5) For the if statement, FSQ combines steps (3) and

(4) to produce:

not (a < h) _ c: = b:

(a< h)-- c:=a

• (6) Finally, for the entire sequence, FSQ combines the

results from steps (I) through (5) to produce the function described in Figure 3.

Note that this process is simpler than general program

verification (and potentially less accurate) as the programmer can override the system and insert arbitrary

definitions. For example, in the program of Figure 3, the

user, in the process of deriving the meaning of the if

statement at step (5), could have either substituted the

correct simplification

c: = rain (a.b)

vol 32 no 3 apnl 1990

6109

4-8

197

OR!G[N._L PAGE IS

OF POOR QUALITY
or any other correct or incorrect expression for the if.

Thus the user must trade off between "absolute' but

extremely difficult correctness using a verifier and a

system like FSQ, which performs efficient, but possibly

imperfect, verification. The tool is truly interactive, with

FSQ performing all the tedious bookkeeping procedures,

and by having the user required provide for the creative

program derivation activities. This avoids the general

undecidability issues of general verifiers and permits the

data-intensive functional verification mechanism to be

used practically.

CONCLUSIONS

In this paper the basic features of syntax-directed editors

have been described and possible reasons why such

editors have not become more popular outlined. The

author believes that their benefits do not increase productivity sufficiently to compensate )'or their deficiencies.

Source.code generation, although labour intensive, is not

a major cost factor in system development.

However, syntax editors can provide a consistent

interface when system specification is integrated with

source-code generation. To experiment with this, two

specification projects have been described as extensions

to an existing PASCAL development environment, in

these extensions both algebraic specifications and functional correctness models of development were applied

as extensions of automated tool support. Further work is

needed to test the eventual applicability of this form of

environment.

ACKNOWLEDGEMENTS

This work was partially supported by Air Force Office of

Scientific Research grant 87-0130, Office of Naval

Research grant N00014-87-K-0307, and NASA grant

NSG-5123, all to the University of Maryland. Individuals who have contributed include: for Support: Bonnie

Kowalchack. David Itkin. Jennifer Drapkin. Michael

Maggto. and Laurence Herman: for AS*: Sergio Antoy

fof Virginia Tech), Sergio Cardenas, Paola Forcheri and

Maria Teresa Molfino (of I.M.A., Genoa. Italy), Stuart

Pearlman. and Lifu Wu; and for FSQ: Victor Basili and

Sara Qian.

REFERENCES

I Hansel W J "User engineering principles for interactive systems' in Proc. Full Joint Comp. Con]_ Vol 39

(1970 pp 523-532

2 Donzeau-Gouge. V, Kahn, G, Huet, B, Lang, B and

Levy, J 'A structure assisted program editor: a first

step towards computer assisted programming' in

Proc. Int. Computer Svmp. North-Holland, Amsterdam, The Netherlands (1975)

3 Teitlehaum, T and Rel_ T "CPS: the Cornell Program

Synthesizer" Commun. ACM Vol 24 No 9 (1981) pp

563-573

4 Proc. ACM SIGPLAN Syrup. Language Issues m

Programming Environments Seattle, WA. USA (June

1985)

5 Proc. ACM SIGSOFT Practical Software Development Environment Conl_ Pittsburgh. PA, USA (April

1984)

6 Zelkowitz, M V "A small contribution to editing with

a syntax directed editor' in Proc. ACM SIGSOFT

Practical Software Development Environment Cont_

Pittsburgh, PA, USA IApril 1984) pp 1-6

7 Zelkowitz, M V, Kowalehack, B, Itkin. D and Herman, L "A support tool lbr teaching computer programming" in Fairley, R and Freeman. P (eds) Issues in

software engineering education Springer-Verlag, Berlin, FRG (1989) pp 139-167

8 Fischer. C, Pal, A, Stock. D, Johnson, G and Mauney,

J "The POE language-based editor project' in Proc.

,4CM SIGSOFT Practical Sol,ware Development

Environment Con(. Pittsburgh, PA. USA (April 1984)

pp 21-29

9 Habermann, N and Notkin, D 'Gandalf. Software

development environments' IEEE Trans. So[t. Eng.

Vol 12 No 12 (December 1986) pp 1117-1127

10 Standish, T and Taylor R. "Arcturus: a prototype

advanced Ada programming environment' in Proc.

ACM SIGSOFT Practical So]'tware Development

Environment Con]_ Pittsburgh. PA. USA (April 1984)

pp 57-64

11 Lang, B "On the usefulness of syntax directed editors"

in Proc. IFIP Workshop on Advanced Programming

Environments Trondheim. Norway (June 1986) pp

45-5 I

12 Knuth, D and Bendix. P 'Simple word problems in

universal algebras' in Computational problems in

abstract algebra Pergamon Press. New York. NY,

USA (1970) pp 263-297

13 Wing, J 'Writing Larch interface specifications ACM

Trans. Prog. Lang. Svst. Vol 9 No I (1987) pp 1-24

14 Antoy, S, Foreheri, P, Molflno, T and Zelkowitz. M

"Rapid prototyping of system enhancements' in Proc.

1st Int. ConJ_ System Integratwn (April 1990)

15 Gannon. J D, Hamlet. R G and Mills, H D "Theory, of

modules" IEEE Trans. Soft. Eng. Vol 13 No 7 (July

1987) pp 820-829

16 Mills. H D, Basili, V R. Gannon. J D and Hamlet, R G

Principles of computer programming: a mathematical

approach Allyn Bacon (1987)

198

6109

4-9

lnlbrmation and software technology


IT_::__:

_2

!
SECTION 5 - ADA TECHNOLOGY STUDIES

The technical papers included in this section were originally

prepared as indicated below.

• "On Designing Parametrized Systems Using Ada,"

M. Stark, Proceedinqs of the Seventh Washinqton Ada

Symposium, June 1990

• "PUC: A Functional Specification Language for

Ada," P. Straub and M. Zelkowitz, PrQCeedinas of

the T@nth International Conference of the Chilean

Computer Science Society, July 1990

• "Software Reclamation: Improving Post-Development

Reusability," J. Bailey and V. Basili, Proceedinqs

of the Eiqhth Annual National Conference on Ada

Technolouv, March 1990

6109

5-1
On Designing Pammetrized Systems Using Ada

Michael Stark ....

Goddard Space Flight Center

1. Introduction

Aj__ is a sc4twsm systmn that can I_

co,ngemdbym_:fing genera¢_ md_ md p_4d_

sped_ psmmmsr valuu W fit tho_ models Intoa

sUmderdlzed deCge. "l_is/s In co.trast to _o _down

dovelopmem s0Omsch wh_, a symm is dedgned fine and

software is mused only when it _ts Inlo the dedge. The lerm

reeonf_urable is used intor_eGd31y with parametrized

throughout h'_ pap_. This concept is psrdcuk_y useful in a

de_t en_rMmt such as tm Godderd Space Right

Center(GSFC) RightDynamk=Division(FDD)._um

successive systems have similar charantm_lics.

The FDO', SoRwore Sngk,Jemg _ (SEL) hm t_en

em'n_ reuso issues associated _ _ from the beginning

of Its Ada ros4mtuh in lg_.R. The klssons lau'nm:l l'mve been

al_led tooosralk0_,mlAdesysmms, luading_ anlmmedam

nnd towards gemmr reuse than is typic_ fo¢ FORTRAN

systems (McGsny 19e9]. In addfinn, the Get.in.Simulator

pm_ _ (_IM) wu a tim oftm_ = ¢isaige_ a

paramu_ed simulalor system. The lessons learned through

_ use of Ada and Itm GENSIM lxoWtyps am L_dng aporM,d to

_, Co_bmd Op_Uk_ Miss_ P_ing and At_ude

Support System (COMPASS), which is to be a mconfigurab_

system Ior a much larger pordon of the flight dynamics domain.

This paper wfli ¢iscuu the leszo_s learned from _ GENSIM

pmj_K¢ some of r4 rucon6gura_n COHOS= pkmned for

COMPASS, and will define a model for the development o(

mconfigtnble systems. This modet provides techniques for

madizing the potential for "Oornain-Oimcmd Reuse'. as defined

by 8raun and Prk_o-Oisz [Bra,, 1989].

The maj_ motve for reconf_guml_ symms in Itm FOO is cc_t

ruductim_ Hav_ng a v_umd s_ ofreu_ mn_onoms may

also increase m_blty and shoran dov_o0m_t schedules, but

cost is the primary factor in INs _naronrmmt Research done by

the SEL indicates that yed_tim software muse (muse without

modification) can produce major cost savings. The cost of

integm_ng a comgenent _ is_musad verba_m is appmxirrmtoly

10 per cent of the cost of devek_pin9 a new cotangent from

sorsl_t [Sokxm_n 1987_. Analysis done for GENSIM in_¢atod

that approximately 70 to 80 per cent of the code could be mused

ved0_UJm,_ that this should cut simulator development costs in

h=f [M=_W 19871.

2. Re¢onflgumbl. Systems

This sec_on focuses on _ appmad_ taken and lessons

learned f_q_nthe GENSIM and COMPASS projects. These

lessons influenced the reuse conoepts and techniques defined in

the subsequs_ lections of _ paper.

2.1 GENSIM Overvlew

The GENSIM pro_ct was started in I_m 1986, and divided into

two majorphaet. The first phasalas1_d unt/ImJd-1988, with

the nu_x ixodu_ being _'_ cost analysis cited aeow,

mmhematMal s_ons, snd the high _ system design.

From mid-1988 Io mid-1989 a srmdl de_eiopmet_t team started

implementing prototy_ so_=re. The project was tmminawd

before IP4 IXOtotype sys=_m was complmod and evatumed, as

COMPASS incocporatN _dmulaflon _Kluimme_ts into its broader

domain. Nonmt_ieu, enough demlopmem work was done to

learn some useful lessons.

The ge_edc sfinulalor desige consists of a s_ of "modules" d_at

IdUg into a _ simula_ archileccum. Each of U'mse

medUtN WU OX;_:_ _0 haw a cc_sponding ma_'_fiad

sp==i_==_ des_ d== (otss= d_mms sr_ Ad= p=d=ge

specif¢=tions), and source code. The uN of standerdzed

Sl:m¢_slk_s was intended 11oprevent _ r_ight di_ in

spec_:atlons _ often impede ved_lkn muse. In addS/co, It_

GENSIM proje_ inmnded Io maintain test Idans, data. and

software for each module, so that changes in standard modules

coudd be ts=ed rapidly.

The simulator orchbs_um is based on the designs of the first

two Ada simulators deve(oped in the FDD. The enhancements

6109

5-2
Simulator Architecture

suueveu_

ommlmw

and changN to _s archiUcUJmwue intended to ailow differem

sets of moclules to be cor_gumcl into a system, depencing _

_e sim_ requirmnen= for a glven sauaite. Itwu pouible

= generar=e _ e=ly deans, butbecau_ U_=, were eady

designs.GENSIM _noor_ somedesign Esws.evenu

otherswere removed. The majorresultsof GENSIM were

I) The conceptof reusingproductsfromall.lifecyde

pha_ pm_mu_ no_ and _ the an_c_md

benefitof zXanclmedizingmamema_ld specific_omL The

GENSIM team _hly spedfiesthe indviduidsimulator

modules. _, theoonne¢tionsbetween modulu were

made at design time, despite _ fact th==mey repmsmttad

ck_,nds_=_ inhen_ in ths pm_mt. Nots capturing these

dependences in Ihe spe(:/_atk_ was not a ixobiem, since g_e

GENSIM t_m happenedto be knee enoughto m

elsZa fund-t/onn,ed,d by om module wu providedby anolher.

Nor,,e_,km._ do_d._ .ho._ We*.m_y

be calXm,d in e_esp_i6c_,,, soeat developenzw/thk_,

domain_ wi have 1heinformationthey need.

COMPASS mare is mpruenttng problemdomain dependencies

in their standmcized spedlicaflons.

2) The configurationof a systemis done by inmnti_ng all

the neoeumy gened¢ Ads i=mkagesinthe corre_ on:l_r. The

GENSIM turn instmttistsdee_h I_e ss a librmyunit. In

c_es where me same s_ of pa_ages am uwd In eachram,

generk= mm be combinedso_t a subsystemcan be

"instan_ated"through_ instantiationof a siegle generic

package.

3) The leg=cyof _e previoussimulatorarchitecture=made

the implement=ionof st=ndardizedcomponentsmorndifficult.

In _lm'. the storageof input=end resultsfora given

simulationscenariocouldnot I_ adequam(y generalized. This

19sscn is 6_uss_l i_ morn derail in _ next sec_cn.

2.2 GI_M_IM _,, • Stsndsrdlz_ Archite(:tum

The purposeof me fl_ht dynamk= z_mu_eor_genendizedby

GENSIM is Iotest _e f_ghtdynamicsconm01algod_ms fora

sms/_t_b,fo_it/slaund_d. Figure I showsme sn:hitec_m

fora spacecraftsknulatorbuiltfrom GENSIM modules. This

dlagr=_ shows the dep_dendes _ major sirnula_=r

su_s. 11_eTruthModelmpmsentsthe"¢ue'msponseoi

a e,ll_araft m itscon_-dsyswm, and is configuredusingffm

o:_pone_s neededfora specific sazegite. The Spaoacraft

Conlro_=ubsysmm contains new code _hat imptemen=a

pf_¢ular satellite'scontrollaws. The remainingsubsystemsare

/x_Itto r_ppor¢_ _o ¢_sysa_ms, and m_¢ _/¢o

con_gurableto supportvs_ng\sets of mod_es. This

reconr_urab_y b_¢=T_ espec_y cumbersome _or_e C,_s_

Intsdsce, whichis _e subsystemthatmanages input,eta and

results for r,im,_,km s¢,narios (cases). F',gum2 shows _ two

majorpansof Case Interface. All simulationinputsare

managed by ParameterInterface.and aJlresul_ are managed

by ResultsInterface, Thesetwo subsysmmsam accessedby

both the user _td _e _vo simula_onsubsys=ems.

Subsystem

=

--T

.Euum._.

6109

5-3
FSS Module's Vlew of the Case

I_e_ace

r=x,=um_

cem_

O=labme

W

..... Jr • • •

T

0

_T_

!ii: ::_=::_i

iiiii::_

Fiqure 3

V

0

w,w_m'Pm,=

Iiw sun I

0

mT_

2) thepw'mmemrepassedinand out of a pad_ge am

limitedto thedata typesdefined byInterlace Types. Module

spedt_ enumemtlmltypes(such as "type FSS POWER is

(OFF,ON)') cammt passedto _ userexcept by usingthe 'POS

atldbuta to _nvect to an integer which is then displayed.

I

-Figure5 shows =utimprovementto thearchileccumthat

mddnmwm_e firstd_e. The i_e FSS_ADT

exportsanabstm= dam type (ADT) that impleswn= d the

modelingof the llne wn sensor. Now the =t=e o4the FSS

is besed on this 8bslract data type, a_l the module's

_=_.,ay is_=,,m=ntodby¢Jng _., operetlon=onme

type. This allows pedmge FSS ADT to be impkm_entod by a

developer who is awm8 ot =IIthe nuances ol fine sun sensor

_. end the FSS module can be implementad by a

develeperwhois aware of all _ nuanoesof the simulator

m_hitDcture.In eddi_on. FSS ADT andall the otherabstract

data typesdefinedfor the flightdynamicsdmula_ondomaincan

be used to build a system with a ¢oml_iy dflarent

amhitac_um,vWthoutchanginga lineof codein the packages

thatiml_mtentthe modelingo_t_ flightdynamicsproblem. An

=rchim _ addremm thelimita_onsimposed by

In_dac_ Typu ten be builtaroundsuchabsmmtdata types,as

is shownin sen_on4. The separat/onof problemdomainand

systemarchit_xe considerationsis a key elementof the muse

modelsdescribedin_l¢lion 3.

parameter Interface

Des_an

The GENSIM con6gunuion¢onoeptc=dledfor the subsystemsof

the Case Into to be built fromcomponentses=o¢iatad with

eadl module. Rgum3dmw=howa paramet_'md resu_

databaseis cr_md for= Rne Sun Sensor(FSS) moduleby

inm=rm=m_ mend=rcUed gmeri= The "FSS_Oatabese"

package is usedby the moduWs iniliaJizationrou¢ineto get initial

parame=m, =ndthe "FSS Resu_" pad_ageis.used by_

module's oomputa_on mul_nes to store simu_J_d _ The

shaded areasshow _ Ihe individualcomponentsfit into the

Case Interfacepackages. F_gure4 shows howsevendmodule

databasesfit intoItm Parameter Interlace subsystem.

The =dv=ntuge of _ _=_h is that the packages

Intm_¢e_Types and FSS_Tybes cx_mdnall the dedarutive

inlormationneeded to indud_ a module ina simuletor

_f_urs=i_ end _ standwd types and promooisare used to

achie_ this. The _n6_r=io_ paremetars indudedefault

v=iues _r m=lule inputper=metm_, flags indicating

paramme_ a u_r is =ltowed to change, and drnilarflags

whatresultsa user maydisplaydunnga simula_n or

p_t aftera simula_n. The disadvantagesof this design

approachare

I) the cisvek_)er o( a lIIghtdynemics module hes to be

aware of all the _omplexitles inherentin the dmuletor

=rctdte_um, and all the dependenciesshownin Rgures3 and

4, and

i

6109

5-4

ORfGfi',iAL PAGE IS

OF POOR QUALr'_,f
FSS Module°s View of the Case

'.°o°o'o . .'

Int_rl ioo_r:)yliNi4

Exemn_

0 sNe,==t

w

i

Intorflce Types Inlorf_

Fioure 5

2.3 COMPASS

COMPASS is the second FDO project_ isdeveloping

rKonflgumble =oftwam. It has_e same costreductiongoal==

GENSIM, but ¢overs,, much largerproblemdomain.

COMPASS is intendedto supportthe mght dynamic=

r,knuimdo¢_area, rnissk_ plarmingand =nalyd= bo_ belomancl

afterlaurch, =mcl =paoeccaft=tlilude suppoct=yutmnsfor

missionoperations. The estimmedsize of COMPASS hiovera

millionlines (¢o_=U_gd ¢mriagoreturns)of Ads _r_ code,

=ncli=tu_et_l to runon =mNnl differentcomputing. This

_npks both being sbie = conf_um systsms tonm u

¢t=ldbutwdWutmns,and to beable to target ttm mine funcUons

toddfimmt platfon_=LTheseoomidemflons have premiered

refinementsto the reuse mode(de_N_:lin [Booth1989].

COMPASS him also involves defining standaic_.ed

s_Uons to promoteverbatimreuse. UnlikeGENSlM, a

sumc_ud specik:mm meu_xk_oW hu hem deflrmdfar

COMPASS [Seidm,_z 1989]. The COMPASS =_

mnmpts are object-onented,but oomainms=k=ion=_cl tobo_

mm_gurabi_/=rid U)pmiect stancU._ Forexam_, mere =

a rmm_ctionon the numberof level=of =uPerdmmes and

sub¢_msesallowedinan inheritancehierarchy,

& Reu_ Conmp_

To be _de to dedgn f_mm_gurableWstom=, itis neceuary to

hm_ =mineundedyingprin_ _'mt can be um_l a=_=_gn

g_. The ma_orcxx_o_=t'clefinedin dd=pager is a Lwered

_ ¢lopmckmd_ among_ oompomm=. The init=d

modolwu devMopedI a resultof b_ework cloneonGENSIM

m_don In opem_s_l system,the Upper Nmosphem Research

(UARS) TelemeuySimulmoc(UARSl"B.S) [Booth

I_91. Thi=mocl_wu l_mmly driven by the needto =_=p='am

pmbtem clomain and sysun archiWcu_e o_sidsraflons, as is

c_a_ussed in sec_on 2. This moc_ does no_ sddnms i_w u)

incoqxxam very general oomponents _ have pomn_d use

acrossseveralpr_lem clo_mnsand/or archite=ures, nordoes

itaddress the separa_)n of systemdependentfeaturesfrom

potentiallyportablecode. The latter omissionbecameobvious

when a mulliplatformWstem such as COMPASS was

_ormidered.

The Layered R_(me Model

m

An_le=ufe C_o_m

Tm

o=_ FSS__OT

(R_am

SWim

W

c=mn_ (1_

To addm_ u_eshovei==ue=,s "s=m4o_" k_w wu added to

ttm mocld. Thi==ervk_= layeris =plit into s sy=U_ndepeml_t

and x systeminde0endentlayer. The updatm_reusemod_ is

d_ownin F'_um 6. Aoomponentin a given layercanonly

depend onoomponentsinlaye_ betow it,as is _e cue in any

good layeredmodel The laye_ am definedas folksY=:

:_ylSmmArchitectureTemolates - Components=t thislevel

providemternpimeintowhichnmdule=fit- Thesecan be

reoonflgumblesubsystwnssuchss the GENSlM Case Interface

discussedabove, or _heycanbe slandamlcomPonenls_at do

not depend on _e pa_icularconfigum_on. In GENSlM the

Display Interfaceand the Plo(Intm'facewere designedto be

6109

5-5

ORIGINAL PAGE IS

OF POOR QUALrI'Y
standard software, with any needed conf_uration data being

SwdRmM_kdes -This laywconmins maq3ommtst_mtam

c_M_gmKttofit intoa stm_im_ da_ig_. Thue moduim_am t_fft

from camponents at the pmbimn domain and serv_ lev_.

Oomain DeflniUonC,_sses - Thuo cmnponenmdefineclasses

In the pmblwndomain th_ im _ throughdomain

eg_t_g _ data tyva,s, as ts discussed show,.

;_meln LarmtJ_ Clam -- Components,,t this level capture

_ _imy of a i_ulsr domJn, in o_r wo_s. emo

dmm_ a_mumtho _ md I=_o.aOo tl_t (k3..dn

exportsuse goe_10mumo spe¢i_tions fordomain definition

dsunsos. In Iho _ht dynamicsdomain, sud_ classeswould

include"vector',"malzix', *orbit', and'attitude'. The dommn

analystwouldusothese simplerclassesto denne morecoml_ex

c_.ses suchu "FineSunSensor'.

b'vst_mIncq_nckmt Services - This layero_n_n_

_om_nen_mt canbeuudin_._emenUngbo__'_epn_

damainlayor and mrc_it_un layer compommts. "they am

usuallyus_mloin morethan ono problemdomsM _or more

_an one Wltm_ wchillec_m. Ccmponon'e at this level indude

me gene_ d_t_ stmcaJmsa_d IooI_providedbyme Booch

Components(TM) [Booth lgeTL as well as ponaldeinterfaces

togeneral servioessuchas DEC's screenmanagement

_. Thesepomdde tn_dao_ c_nbe movecl_odiffemm

o0mpum_, ,rid new code or a cMenm¢ commn_ product can

be u_l to iml_m_nt Ihe same func_n¢ Thus oneemls up

wi_ _ no_x._de implem_tmiom of a singJe

absrac_on. Calls k) mispacka0o shoukJsc¢_e same, even if

d_y am implemenmdin a machinedependen¢manner.

_tsm _t _ - Thisl_yer _onmins atl mo

components mat am depenclent on a pan_cu/_ computer o¢

operatlng wsWn. Thls generally indudes all non-Ada cmle. as

mos¢ odor Isngueges h_ve diffemm non-stand_l ex_nsions on

dMemnt rrmch_l_s. 1his abo indudes Ad_ code _'_u

inaxpor_ sysmm do_ndom fo_ns such u Oim__lO _es

cn_ed w_ a non.huff FORM paramecer. These syslem

dependem leamms should have system independent interfaces

at a hlgher Jew/.

Tho improvedmodeltakes an obj_t-orientod eppmachto

spedf,/_=_tho Woblemdomain. Tho domain d_ni_n d_=es

and domain i_guaoe dosses form mo two rna_ groupings

wt_in me problem donmin. Each of muo two groups sm Jso

o_mizsd with me rnom domm sl_sci_ dssses _ _n

_m_N "_ott"_d "_mud," ck_ml a_ the morngem_l

cbmes "_r" _ci _nxt

The layeredmusemodel dramnotdepend onAda, but h'mAda

_w_mgo containsfeatures_mt supportIbismodetwei. The

uw o(gen_= pad(ag_ dora ud_ _ _e problemdomJn

das_s tobe implememedas a gene_ un__ha¢i_mm_emly

docoul_ fromd o_ dasNs, inadci_on,me gene_ lom_

_ msodsled wi_ a package ceptum d d_e information

abo_depembmminadngieloca_k_, aswelu distn1_

extomalrefemncu Ihmughoutlhe code. Anotherusefulfemum

is tho sepam_ of padu_ger4)ecifica_ms(and subprogram

snd task st:eci_s as well)from d_ir implemema_ons. This

Is u_ul inhiding_1_m clopendent_m_es, which ten _en

h_e _e _m indepenck_ p_n de_aed _ U_e_pm_te

layer. For exampM, the inmrface to a sysWm dependent nm_

Iibnnrywould bocMssfftedw_tl'dn_o I:_oblem domain, and the

imodacoto _'scroon managementroutines

couldbe sys_n inc_pendentun_:e_. The 5 lop levelsin_s

modotwould thon contain ays_n independent Ada code,which

would be expected Io be _ompletely p(xlable. This is nota

comequem= of attemptingto make mo hi0hest layersportable,

butmd_eri_a benefitof Isol_ng tho knownsysmm

degendenc;_ and usinga mnclan_zed programming

I_guage. UsingAria leads natura_yto havingmostreusable

attainableusingC. It is aknostoe_Jnly not attainal_ewith

FORTRAN, as the diaJectsvarytoo greatlybetween machines.

4. Example

Thissection_esents an improvedGENSIM design as an

oxample of howto use _e leyemcl model. This new designis

pm-,,entodat the same levelof\_ as _e odgin_lGENSIM

dedgn ixe_nt_l in section2.- _gum 7 shows d_e improved

dmulator clwgn.

Imnroved Simulator

Ar(;hitecture

"'="'='"" I \ / I

o...,. _ ( ..........

,__,. \

Layer

F'_um 7

The keydifferencesin thisdesignam the Iocaliono_mo Case

I_ subsystemand the new I/0 m subsystom. In

add_on, tho _:m:ecraft Contrd, Truth _ _1U_l'rties

s_ wo mmbinod In= me _muia_r su_. F_um

8 shows _att d_e del_,ndencies between these throe subsystems

amthe sameas in the original architecture (_um 1). t_t _'_tt

nownoneof _eu subsystemsdependson Case Intorface.

6109

5-6
This extra design level hi not cank_l mmugh to

knplemqmUtion. Subsystems may be implemented as a single

package which provides an inmdace to all me subsystDm's

o0mportent=, but in this oue the Simulator subsystem is merely

SimulatorSubsystem

a logical grouping intended to reduce the design c=mple_ty.

Rgum 7 idso shows lie _me major t=yer= of the recse model

In INs design, _te I/0 services consist of standard Ada pac_ges

such as Text IO or Dim_ IO. and an intadaoe to DEC's Saeen

Management Guid_mes (SMG) routines. Figure g shows the

intemstalk)nehip between the FSS module and b"tesimulator

architesture. Here '_te sbsUact d=ta type for a sensor hicmstod

by instan=dng a generic pac_ge. The genedcADTis

designed so that all extomal dependencies are ¢sptwed in U_

generic format part. These dependencies include types provided

by the srnulator's M_h_Ty_0es package. _ func_ons to r_ect

information from me Sun and Dynamics modules. The

FSS_Obje=s p=:_age uses em AOT Lodva= type) expon_ by

U_e FSS_AOT package to define its package state, and the

F_ Parameters_0isplay package uses visible types exported

by FSS_ADT to define parametm" screens. The

FSS_Pammeter_DIsp_ys package also instantiates

EnumenUk__lO using "type FSS_POWER is (OFF,ON)" es Ihe

acUmi parameter. This removes _e re,lance on using the 'I=_3S

auributs of enumerated types that has been =tfenmm of all FOD

simulators up until now.

Rgum 10 shows how the FSS_Parametor_Dlsplay package fits

into the design of the Case E_tor subsystem. The Case Editor

subsystom is the part of the User_.lntodace that allows a ussr to

chango lmy of the inidaJ _ for i =imulalk:m. The

Parameter_Editor package tracks which Grmplays the user has

se_cted and cans _e appropriate parameter d=p_ padre.

The difference is _t now _e User Intorfac_ cenlxols _e

initiaLzation of simulation pammetors, mlJ'mrthen the simulator

¢omponente requesting intial values from = database contained

w/thin file Case In=erf_e.

In this example, the use of the layer_l moc_ removes _ Truth

Moders mml_ex c_endencieS on the Case Interfa_ packages

shown in Figure 3. This enables the Simulator subsystem

componente to be usable within rnom than cqe erchitectum.

The placing of the system w_hitecture subsystems above the

Simul_or subsystem slse aJOWS general purpose se_oe layer

companente to be enhanced as needed Io intogram a given

module into _ system erchitocaJm. The

FSS_Pammeter_Oisplay demenstnttes this ¢o_ept by using

Enumeradon_lO to add to the general IO services.

FSS Module Desion

Inwd=¢=

5. Future Olrectlorm

This paper desa_s a genera/muse rno_ for designing

rec_nflgurable systems. The next stsp is to map _ layered

muse model to Ad_ design _ implementation oencepts. The

high-b,_ designs _-esenlsd in a_s paper use _ pa,_ges

to heJp pammeu_ze systems. _ m n_ny po_ble ways to

inoorporate gene_ package= into ,, larger design. These "reuse

in the m_i" techn/ClUes indude ne_ng generic im,tantia_ns,

nesting generic definitiens, and cmsdng dependencies between

library instontiations [Booth 1989]. This _ has used _e last

technique so that whilegener__,,,re coupled, each

of the _ units is completely decoupied from _e o_mrs.

The _/erud muse rnodd provides a sound b_s for project

marmgement. By s._y separating the problem domain issues

front the system erd_itecaJre issues, a manager can assign _e

appmlxlate expe_ to implement I_S within esch layer of

the model. Improving the allocation of persennel to tasks should

6109

5-7
improve bo_ _ and software quality. As thla model is

used, an understanclng of what pmpordon of a syutem tails into

User Interface Case Editor

Jz¢._=.

",V

Se_tc_

Fiqure 1 0

which layer _ evolve.

The layered nmse model also cen be used to understand which

softwweismostcdtlcaL _ moclals have seen the most

use in operadng system design. The kernel of an opera,rig

system typk:aJly requires Ihe most attmltJon, despite the fact it

a m_ stud prol:_=rdon _ _e _. l"h_ _ beceu_ =1

o_, LtCem depend on its con,ecme_ and et_mcy. The

analogous layers in the reuse model _,_ the service layers and

the domain language layer. Addidomd evidence lot the

asser_on is that the FDD has observed pedonnance

degradation in its Ad= simulators due to the inefficient

implementadon of _licel utililies packages.

In addition to _m p_mmce p'aOlem= observed above,

;,,a coqx:em that layered im_emantation modet= may be

inbemnW slow clue Io Itm additm of extra lav_ of pmsedum

cells to accompitsh the sane work, Tbe FOO encountwed this

_ w_dt i. _ p¢l_ _ i11_ that

pin,des the firm FORTRAN inledace routines on a VAXor an

IBM mainhme. Whel_mr this la ckm to exlra pro_dure celia or

generally ineffciant imldemenlation is uncles. Ade addresses

the f_'mer problem by providing _ Inline. The latter

problem must be addressed by improving the software. If the

software design and implementation is done I:_Opedy, the

laye_d reuse model r,hou_clnot degrade performance.

6. Conclusion

In "Domain-Oimcted Reuse', Braun and Pdelo..Oiaz extract

pmpen_s that are common to appiice_ns (such as compiler

design) where a high _ of muse is already being obtained

[Braun 1989]. Thasel_ am afoo.m on a _ar

app_ _, u=umpliocm about system arcNtocCum

constraints, and a set of ganemlized and well defined interfaces.

The layered reuse model ixovides design concepts for

examining appiicsdons domains and defining standarcfced

architocmms. These!technlques w_i help realize the potential

inhBrent in the concept of doma/n d/rec_d muse.

Reference=

[Bcoch 19871 Booth, G. Software Comoonents Wilh Ad= Menlo

Park, Calif., Benjamin/Commings, 1987.

[Braun 1989] Briton, C. and R. Pdato-Oiaz, "Oomlan-Oimcted

Reuse," Proceedinas of the Fourteenth Annual Software

• " November, 1989.

[Booth 1989] Booth, E. and M. Stark, "Using Aria Generics to

Maximize Vedoatim Software Reuse," Proceedinos of TRI-Ada

'89. October 1989.

[Mnddey 1988 ! M41ddoy. F. L ;_C. Mendelaoim. M. Shirk and M.

Wcod_,' "Impact Study of Generic Simulator Software

(GENSIM) on Attitude Dynamics Simulator Development Within

The Sys=ems Oeve_ent Branch," Unpublished FDO Study,

1988.

[McGarry 1989] McGany, F., S. Waiigora, and 1". McDermott,

"Experierces in the Software Engineering Laboraton/($EL)

Applying Software MeMumment," Proceedinas of the

Fourteenth Annual So_ Enoineerina Wol_st'Inn November,

1989.

[Seidewitz 1989] Seidewitz, E. Combined C_ml_nal Mission

Plannino and Affitud_ Suo_ort System tCOMPAS_;)

Soecificat_n Concerns_ Goddun:l Spaoe Right Center Right

Dynamics Division. COMPASS-102, 1989.

[Sok)mon 19871 Solomon, D. and W. Agmsd. "Profile of

Software Reu=e in the Fight Dynamice En_onment," Compu=er

Sciences Corporation, CSC/TM_7/6062, November 1987.

6109

5-8
PUC: A Functional Specification Language for Ada*

Pablo A. Straub*

Computer Science Department

University of Maryland

Marvin V. Zelkowitz

Institute for Advanced Computer Studies

Computer Science Department

University of Maryland

Abstract

Formal specifications can enhance the quality, reliability, and even reusability of software; they are

precise, can be complete in some sense, and are

mechanically processable. Despite these benefits,

formal specifications are seldom used in practice

for several reasons: programmers lack an adequate

background; both concepts and notations in specification languages appear obtuse to programmers;

formal specifications are sometimes too high-level,

providing too large a gap from the specification to

the implementation; methods are not tailored to the

environment; and fully formal methods are expensive and time consuming.

In this paper we present PUC (pronounced

POOK), a specificationlanguage for Ada that addressesprogrammers' concerns forunderstandability. PUC is a functionallanguage whose syntax

and data types resemble Ada's, although it has

featureslikeparametric polymorphism and higherorder functions. The paper shows the requirements for the language PUC; presentsan overview

of the language and how itisused in the specificationof Ada programs; and givesthe requirements

and strategiesfora semi-automatictranslatorfrom

PUC to Ada.

1 Introduction

The practical use of formal specifications in program development is an important goal in software engineering because formal specifications can

enhance the quality, reliability, and reusability of

software. Formal specifications are precise, can be

complete (in some sense), and are mechanically processable (e.g., consistency checks). Since one of the

"Research supported in part by NASA Godda.rd Space

FlightCentergrantNSG-5123.

tAdditionalsupportfromODEPLAN and CatholicUniversityofChile.

main problems in software reusability is determining what is the functionality of a subprogram or

module, having a precise description will also improve software reuse, lowering costs and improving

quality by using already tested components.

Despite the benefits of formal methods, few are

used in practice. There are several reasons: programmers do not have adequate background; both

concepts and notation in specification languages

are usually mathematically oriented; there is a big

conceptual gap from a very high level specification

down to the details of the implementation; methods

cannot be tailored to the environment; fully formal

systems are very expensive and time consumming,

and much software is not critical enough to justify

this cost.

A precise mathematical specification is useful

only if it is understood by the persons involved in

the development, so notational considerations are

very important. Two aspects of the specification

language have to be considered: the conceptual or

semantic level and the syntactic level. The concepts

represented in the language have to be very high

level, like the concepts in the domain area, but not

too high level, or else there will be a big conceptual

gap from the specificationto the implementation.

Hence, there isa trade-offin the designof a specificationlanguage: ifitisnot very high level,the

program analystsand designershave a hard time;

ifit is too high level,the implementors must figure out the algorithmsfrom scratch.This trade-off

issummarized by the questionof how much design

should be impliciton the specifications[13].

The second aspectof notation is syntax. Syntacticissues are sometimes dismissed as syntactic

sugar; this is fine for a researcher who knows many

programming languages and can learn another one

very fast, but for most professional programmers

syntax is important. In particular, a syntax that

is similar but conflicting with the implementation

language is confusing.

6109

5-9
This work grew out of studies within the Software

Engineering Laboratory (SEL) of NASA Goddard

Space Flight Center. The SEL has been monitoring the development of ground support software for

unmanned spacecraft since 1976. Our goal is to improve the quality of software specifications within

the SEL, to improve both software development and

testing [13]. We approach this goal by incresing

the use of formal methods in software specifications. The SEL environment is characterized by

large (tens of K lines of code) scientific software

with complex functions and complex structure; potential reuse of products and processes; programs

written in Ada using object-oriented design; few

critical timing constraints; and programmers without background in logic and abstract algebra. To

increase formality of specifications, we designed the

especification language PUC suitable to this kind

of environment; in particular, users of PUC are not

required to know advanced logic or abstract algebra.

Overview of the paper. The next section discusses the need for a new language. Section 3

presents the principal aspects of the PUC language,

along with examples. Section 4 shows how Ada programs can be developed using PUC as the specification language. The example presented is a simplified telemetry processor for satellite data. The

final section contains a summary, conclusions, and

a description of further work.

2 Why Another Language

There are many specification languages, yet we have

not found any that is suitable for our needs. This

section motivates the design of PUC, by presenting

previous work, design objectives and rationale.

2.1 Previous work

Specification languages proposed specifically for the

Ada programming language are based either on first

order predicate logic, Horn clauses, algebraic abstract data types, or procedural description.

Booth proposes to use Ada itself as a specification language for Ada programs. "Not only is Ada

suitable as an implementation language, but it is expressive enough to serve as a vehicle for capturing

our design decisions." [1, page 50] However, most

design decisions that can be written in Ada are of

syntactic nature. This includes functional decomposition, but the meaning of subprograms cannot be

expressed in Ada without writing them in whole.

Anna (ANNotated Ada) is a specification language designed to provide machine-processable explanations of Ada programs [9]. Anna programs are

Ada programs with formal comments, that describe

the functional requirements for the program; properties of its components (variables, subprograms,

modules); and how these components interact. Formal comments are in the form of pr_- and postconditions, module invariants, type constraints, and

other assertions. Anna programs are executable because they are Ada programs, but the specifications

themselves are only executable in the form of runtime testing for consistency.

The PLEASE specification language for Ada is

based on logic restricted to Horn clauses [14].

PLEASE borrows from Anna the idea of writing.

formal comments in Ada programs. Programs in

PLEASE are executable so they can be used to

build prototypes, in which incomplete Ada programs call some procedures specified in PLEASE.

Unfortunately, pure Horn clauses are so inefficient,

that operational semantics (order of evaluation and

PROLOG cut command) have to be explicitly declared complicating the specification.

The specification language Larch/Aria-88 also

uses formal comments within Ada programs [111.

This language is one of the interface languages of

the Larch family of specification languages. Larch

specifications are done at two levels: the meaning

of the abstractions used by the program are defined

using the Larch shared language [5], and then one of

the Larch interface languages is used to state what

the program does in terms of these abstractions.

The Larch shared language is based on algebraic

abstract data types. Using Larch/Ada-88 and the

prototype tools described in [11] it will be possible to develop verified Ada programs, hence this

method is fully formal.

2.2 Design objectives

We set several specific goals in the design of the

language to make it useful in the SEL environment. These goals are sometimes conflicting with

each other.

• The language should bridge the usual gap between very high level logical specifications and

the detailed data and control management in

Ada.

5-10

6109
The language should be expressive and extensible. It should be easy to code domain specific

concepts in a specification library.

Specifications should be easily translated into

Ada programs; only rarely used constructs are

allowed not to have a simple Ada representation.

The language should be easy to learn for an

Ada programmer. It should have few concepts

and very few concepts not present in Ada. Syntax should be Aria-like.

The language should be executable, so that _he

specifications can be used as a prototype and

in preparing test data for the final application.

2.3 Design rationale

Our first design decision is the semantic model on

which PUC is based; that is, whether PUC specifications will consist of Horn clauses, procedural

descriptions, etc., either purely or in combination

with other semantic models.

Some researchers in formal specifications have

advocated using both purely functional languages

[3, 6, 16] and logic-based languages [8] for specifications, based mainly on the separation of concerns

between what is intended and how it is achieved, especially in the management of data structures. The

expressive power of logic languages and functional

languages is not comparable, because logic languages can accomodate non-determinism whereas

functional languages can be higher order [16]. Even

though both logic and functional languages can be

executable, we agree with Hoare in that '% modern functional programming language can provide

a nice compromise between the abstract logic of a

requirements specification and the detailed resource

management provided by procedural programming"

[7, page 90]. These arguments have influenced our

decision to design a purely functional programming

language to specify Ada programs.

Most functional languages have mathematical

notation which makes them amenable to formal

proofs; however, they have been developed for

programmers with extensive mathematical background. Our goal in the design of PUC has been to

make a specification language for Ada programmers

who do not necessarily have this background. If formal proofs are needed, PUC specifications can be

easily translated into recursion equations to prove

properties of them.

Hence, both syntax and semantics of PUC are

similar to familiar programming constructs. For example, instead of free algebras and pattern matclling, in PUC there are variant records and case expression. The few constructs of PUC that are not

present in Ada are explicit. For example, polymorphism is explicit in the declaration of polymorphic objects, and Curring (i.e., creating a higher order function by partial parameterization) is accomplished using predefined functions instead of just

omitting parameters.

3 The Specification Language

PUC

This section presents the main aspects of PUC. A

technical report gives further details and a BNF

description of the grammar [12].

3.1 Overview

PUC is a purely functional programming language

with parametric polymorphism [2] and Aria-like

syntax designed to serve as a specification language

for Ada programs. Because PUC programs are executable, we will call PUC either a specification language or a programming language appropriate for

prototyping.

A PUC program consists of a sequence of declarations of types and objects (functions and data).

Type declarations give a name to a type and are

needed to create new types. Object declarations

give a name to an object, which represents a function or data object; they are either like Ada function

definitions or like Ada assignments, where _he defining symbol := is read as is equal by definition and

represents the relationship of that object to other

objects. This results in implied execution sequences

by virtue of the partial ordering of these object relationships.

Example The following program consists only

of data object declarations. The value of root is

computed from the values of a, b, and c.

roo_; :" (- b + sqr_(b*b - 4*a.c)) / 2;

a :" 2.0;

b :=-4.0;

c :=' 2.0;

Example The program below defines resul_ to

be the factorial of 5. The program consists of two

object declarations: fact and result.

6109

5-ii
result :- fact(5);

function fact (n: in£eger) return integer is

begin

if n _ 0 then 1 else n * fact(n-l) end

end;

3.2 Data types

PUC is a strongly typed language, like Pascal or

Ada. However, PUC types are higher level that Ada

types. For example there are lists instead of arrays;

recursive records instead of records and accesses.

That means that PUC is easier to use, but not as

efficient as Ada. There are four kinds of data types

in PUC: scalar types, list types, record types, and

function types.

The scalar data types in PUC are: integer,

real, boolean, chaxac'cer, and enumerated types.

Numeric types have the usual arithmetic operators

(+ - * / rein); the boolean type has the operators:

not, and, and or; and relational operators (= /= <

<= > >=) axe defined for scalar types. Precedence

rules are the same as Ada.

Lists axe unbounded sequences of objects of the

same type. Constant lists are represented using

square brackets. The catenate operator is _, subscripting and slicing (sublist) is done using parentheses. Strings are simply lists of characters.

Example Given the definition of auras, the following equalities hold.

hUmS :- [10,20,30,40,50,60,?0,80,90,100];

nut_(4) = 40

nut_(2..3) = [20,30]

[20,30,10] - nu1_(2..3) _ nums(1..1)

nut_(8..8) = _n_(8)]

length(ntm) = 10

"string" = ['s','t','r','i','n','g']

PUC records are very similar to Ada records;

component selection uses the typical dot notation.

Records can have variant parts and can be recursive. Variant records have components that depend

on a tag, whose type must be boolean or an enumerated type. For example, type expr isa recursive

record with variants to represent arithmetic expressions of integers.

type expr_kind is (number, plus, minus,

multiply, divide);

•ype expr is

record

case kind: expr_kind is

when number -> val: integer;

when others ffi>left, right: expr;

end;

end record:

The null record--compatible with all record

types and similar to Ada's null access--is used

to build finite recursive records without variant

parts [10]. For example, the recursive record type

in'co'tree represents binary trees of integers. Note

the use of the type name as a constructor for constant records.

type int tree is

record

da1:um: integer ;

left, right : int_tree;

end;

a tree := int_tree'(5, null,

int_tree '(8 ,null ,null) ) ;

[n addition to the arithmetic, list,and record expressions, there are two structured expressions, if

and case. The syntax for these expressions is similar to the corresponding statements in Ada; the difference is that in place of a sequence of statements,

a single expression is expected.

3.3 Functions

Functions in PUC behave like mathematical functions,mainly due to their declarative---asopposed

to imperative--nature. Table I shows the main

differences between Ada and PUC functions. Although functions are declared using a syntax similar to Ada, the text between the begin and the end

is not a sequence of commands, but an expression.

Usually this expression will involve conditionals and

recursion.

Example Function eval evaluates an expression

represented with the type expr from Section 3.2.

function eval (exp: expr) return integer is

function eval_oper (exp: expr) is

1 :" eval(exp.left);

r := eval(exp.right);

begin

case exp.kind is

when plus ffi>1 + r

when minus ffi>1 - r

when mul_iply ffi>1 * r

when divide ffi>1 / r

end

end eval_oper;

begin

if exp.kind = number then exp.val

else eval_oper(exp) end

end eval;

6109

5-12
Ada Functions PUC Functions

Can cause side effects

Can be generic

Cannot return a function as result

Can have local types, functions,

procedures, variables, constants, ...

Body expressed using control flow

statements

No concept of sideeffectsin PUC

Can be polymorphic and higherorder

Fullyhigherorder

Can have localtypes,functionsand constants

No concept of controlflow;only conditionals

and recursion

Table 1: Differences between Ada and PUC functions.

3.4 Polymorphism

An object is polymorphic if it can have more than

one type. PUC has parametric polymorphism,

where the type of an object can depend on another

type [2]. This is similar to generic type parameters, although more general. PUC has polymorphic

functions and polymorphic record types. Polymorphic functions are declared by preceeding the types

of the parameters by a question mark (this declares

an implicit type parameter).

Example The following polymorphic functions

operate on lists of any base type.

function length (L: list of ?element) is

begin

if L = _ then 0 else I + length(rest(L))end

end;

function cons (elem: ?a; L: list of ?a)

return list of a is

( [elen] _ L );

function find (value: ?a; L: list of ?a)

return list of a is

begin

if L ,, [] then L

elsif L(1) - value then L

else find(value, rest(L))

end

end;

Polymorphic recordsare used to definedifferent

records given a base type; they are also called type

constructors. The example below defines a type

constructor for binary trees which is used in the

definition of a binary tree of integers.

type tree of elem is

record

datum : elem;

left, right: tree of elem;

end;

type int_tree is tree of integer;

Polymorphic types are usually used in conjunction with polymorphic functions that operate on the

type. For example, function traverse_tree builds

a list from the in-order traversal of a binary tree.

function traverse_tree (t: tree of ?elem)

return lisz of elem is

begirt

if t s null then []

else traverse_tree(t.left) & It.datum]

traverse_tree(t.right)

end

end;

3.5 Higher order functions

Higher order functions are those that have functions

as parameters or compute a function as a result. A

limited form of higher order functions is present in

languages like FORTRAN or Pascal, where it is possible to specify a subprogram passed as a parameter

to another subprogram. PUC is fully higher order

because it imposes no restrictions on the kinds of

higher order functions (e.g., a function can return

a higher order function). A very limited form of

higher order functions can be simulated in Ada using generics.

Usually higher order functions are polymorphic

because they operate on polymorphic data structures (e.g., lists), but these two language features

are independent. Figure 1 shows the definition

of some standard higher order functions which are

useful in defining other functions without explicitly writing the whole functions; that is, the use

of higher order functions enhances reusability. Figure 2 shows several functions defined in terms of

polymorphic functions; some of them were previously defined explicitly.

6109

5-13
-- APPLY - a list with the application of f to the elements of L

function apply (f: function(?a) return?b; L: list of ?a) return list of b is

begin

if L = [] then [] else If(L(1))] & apply(f, rest(L)) end

end;

-- FOLD_R - the right folding of list L _ith function f

function fold_r (f: function(?a,?b) return ?b; init: ?b; L:list of ?a) return b is

begin

if L ffi[] then init else f(L(1), fold_r(f,init,rest(L))) end

end;

-- FOLD_R_1 - the right folding of nonempty list L with function f

function fold_r_1 (f: function(?a,?a) return ?a; L:list of ?a) return is

begin

fold_r (f, L(1), rest(L))

end;

-- CURRY - a function like f, but with the first parameter fixed

function curry (f: func_ion(?a,?b) return ?¢; paraml: ?a) is

begin

function (param2:b) return c is f(paraml,param2)

end curry;

-- FOLD_TREE - the folding of binary tree t with function f

function fold_tree (f: function(?b,?a,?b) return ?b; init: ?b; t: tree of ?a) return b is

begin

if t = null then init

else f(fold_tree(f,ini¢,t.left), t.datum, fold_tree(f,init,t.right) ) end

end fold_tree;

Figureh Some standard polymorphic functions.

function traverse_tree (t: tree of ?a) return list of a is

function combine (l:list of a; elem:a; r:list of a) return list of a is (i k [elem] & r);

begin

fold_tree(combine, O, t)

end traverse_tree;

function sum_of_nodes (t: tree of integer) return integer is

function adds (i, elem, r: integer) return integer is (i + elem + r);

begin

fold_tree(addS, O, t)

end sum_of_nodes;

function concat (L: list of list of ?a) return list of a is

begin

fold_r("&", [] , L)

end;

Figure2: Functionsdefinedusingpolymorphic functions.

6109

5-14
4 Developing Ada Programs

with PUC

There are several approaches for developing Ads

programs using PUC. One is to use PUC only as a

formal documentation aid, taking advantage of its

defined semantics, but not its executability. Using

PUC simply as a notation requires in principle no

software tool, but this is very limited; at least a

parser and consistency checker has to be provided.

But if there is a parser then it is relatively easy to

build a translator or interpreter, so that specifications in PUC can be used as prototypes.

Another way of using PUC specifications, is to

generate Ads implementations by means of a semiautomatic translation, in which a programmer decides implementation issues and can even modify

the generated code. This choice seems to be more

attractive than the others, because it provides a

smooth transition from specifications to programs,

but the caveat is that not all PUC constructs have

a simple representation in Ada (e.g., Ads has no

higher order functions).

These approaches are not fully formal development systems in the sense that it is still possible to

write a program inconsistent with its specification.

While this is not optimal, we think that our software engineering environment is not mature enough

for a fully formal system, and that experience with

semi-formal specifications (and development) is required before a fully formal development system can

be used effectively.

In order to provide a translator from PUC to Ada

it is first necessary to determine a set of translation rules that will preserve the semantics of the

specification. Although this set will not be sufficient to translate any PUC program into Ads, we

need to be able to translate most PUC programs,

or else the method is impractical. There is an additional restriction we impose on the system: to facilitate manual modification of the generated Ada code

(e.g., for o.ptimization or maintainance) we want the

generated Ada code to resemble the PUC specification.

Since PUC is syntactically similar to Ada, some

PUC constructs require simple translations or even

no translation at all. For example, enumerated

types and simple record types are almost identical

in both languages; recursive record types are translated into an access type and a record containing

access fields. However, not all translations are so

simple, because the semantics of PUC and Ada are

quite different. It is particulary difficult to provide general and efficient translations for the use of

(garbage collected) heap memory, lists, higher order

functions, and polymorphism.

4.1 Memory management and functions

PUC functions can be translated to Ada functions

or procedures. If procedures are used, there are

choices in the parameter modes used (i.e., IN, OUT,

IN OUT). It is not always possible to select any of

the choices, though, because they depend on the

way data is manipulated in the calling functions.

This brings up the issue of how memory is managed. The semantics of functional languages with

automatic allocation and deailocation of memory is

quite different from that of Ada. In Ads only local

variables are allocated and deailocated automatically, because of the activation stack model used,

whereas in functional languages all memory is allocated and deallocated automatically. An immediate

consequence is that we will try to allocate as much

memory as possible in the form of local variables,

avoiding the use of the Ada heap. To do that we

have to recognize when data can be stored safely in

the stack (i.e., when we can be sure that data will

not outlive the function call where the value was

declared). One of the problems of this approach is

that it complicates sharing.

Another important issue in the management of

memory is when to use variables. In functional languages there are no updatable variables and that

means that every value computed needs newly allocated memory. We want to take advantage of Ada

variables to avoid these allocations, even if they

ocurr in the activation stack. For example, tail recursion can be translated into loops that will use

variables for the information that is passed to the

next activation (i.e., iteration).

4.2 Translating lists

There are several ways to translate lists into Ada,

based on arrays or linked lists. When lists have a

fixed known length, they can be translated into Ada

arrays. If the length is not fixed but there is a reasonable upper bound, lists can be represented by a

record with an array and a count of used elements.

When the length of the lists is highly variable or not

bounded then a linked list representation is used,

using a predefined generic package. In the case of

strings, it is desirable to use Ada strings, so that

6109

5-15
string variables are compatible with string literals.

Array representations have advantages over linked

lists because they can be more efficient and generated Ada code resembles closely the PUC code.

It is very difficult for the translator to detect

whether a list can be represented by an array or

not. On the other hand, if an array representation

is chosen some upper bound has to be provided, so

this translation cannot be done automatically. One

solution to this problem is to provide a default representation with linked lists and let the programmer

change that default. The default representation for

strings are Ada strings. For each type that requires

a non-default representation, the programmer has

to specify which translation is desired. This translation applies to all objects of the type.

4.3 Translating higher order functions

Higher order functions are used often in specifications, because they are useful in representing abstract operations. Ada generics can represent uses

of higher order functions in the particular case of

functions passed as parameters, provided that all

function parameters are statically known. This

translation requires defining the function as generic

and providing the corresponding instantiations.

It is hard to make a general translator for higher

order functions. However, most programs use

higher order functions that either satisfy the restrictions in the above paragraphs, or belong to a

standard predefined set (e.g., the examples in Figure 1.) For the first case, the translation scheme

described suffices. For the second case it is possible to have a set of ad-hoc translation rules for the

standard higher order functions. These rules are

semantic-preserving transformations coded into the

translator [15], hence programs written in terms of

standard higher order functions can be automatically translated. The system can be extended by

adding translation rules for domain-specific higher

order functions.

Example Function poly evaluates a polynomial

represented by the list [a0, al,..., a,] of its coefficients, using the factorization

P(x) = a0 + x(a_ + x(a2 +... =a....))-

function pol 7 (as: list of real; x: real) is

function combine (a_i, accum: real) is

(a_i + x (' act tim);

fold_r_l( combine, as )

end;

The use of function fold-_A (defined in Figure 1)

can be transformed into a loop using the rule for

_old..v.1. F_om the definition of fold_r_1, if as

has only one element, then the result is equal to

this element. If as has more than one element (say

as = ['first] /t resl;) then the result is equal to

combine( first, fold_r_l(combine,rest) )

That is,we can firstcompute the folding of the

rest;and then combine the resultwith the :_irsl;

element.This can be achievedby a loopthatexaminesthe elements in reverseorder and accumulates

the resultsof the folding.The firsttime the list

willhave only one element thatisused to initialize

the accumulator. Sincewe know that the loop will

iterate length(as)-I times we can use a for-loop.

accum :- as(length(as)) ;

for i in reverse I .. length(as)-I loop

resulS := combine(as(i), result);

end loop;

To write the above loop in Ada we need to provide

an implementation for lists and perform the corresponding translation on them. Note that this loop

will be inefficient with linked implementations for

lists, because _oZd.x_l accesses the elements in reverse order. Now we can expand the call to combine

and produce a complete Ada function.

4.4 Translating polymorphism

Some polymorphic functions can be translated into

generic functions with type variables. This is not

true of all polymorphic functions, because parametric polymorphism is a type system more powerful

them generic types. The restriction is that all uses of

a polymorphic function must be monomorphic (i.e.,

it should be possible to assign a static type to every

use of a polymorphic function). That means that a

polymorphic function cannot call another function

using polymorphic parameters. This restriction is

in principle rather severe, but does not apply to predefined operators and functions whose invocations

are translated by ad-hoc rules.

The difficulty with this approach is that all functions on the polymorphic type have to be explictly

declared. For example, if we have a function to operate on lists, all list primitives used have to be declared, and the function can be generic on both the

6109

5-16
generic

type a;

type list_of_a;

with function empty_list return list_of_a;

with function first (I: list_of_a) return a;

with function rest (i: list_of_a) return list_of_a;

function find (value: a; L: list_of_a) return lis¢_of_a is

result: list_of_a;

begin

result := L;

chile not((result = empty_list) or else (first(result) = value)) loo 9

result := rest(result);

end loop;

return result;

end find;

Figure 3: Find the longest sublist containing value.

base type and the list type. Figure 3 is the translation to Ada of function find from Section 3.4.

Polymorphic records can be translated into several record declarations, one for each instantiation.

As with functions, all uses of polymorphic records

have to be monomorphic, or else the translation

cannot be done automatically.

Example The polymorphic function fold_].

folds a list into one value by combining values pairwise from the left of the list. Since fold..1 is also

higher order, the techniques discussed above apply

as well.

function fold_l (f: function(?a,?b) return?b;

accum: ?b; L: list of ?a) returI% b is

begin

i2 L = [] then accum

else fold_l(f, f(L(1),accum), rest(L)) end

end;

Fold.2. can be transformed into a while-loop (it is

tail recursive). Consider the following call to fold..l

result "= fold_l(f, value, a_list) ;

From the' definition of fold-l, If a-list Ls the

empty list D, then result is equal to value.

If a.lisl; is not empty (say a_lisl; = [first]

res¢) then the result is equal to

fold_l(f, f(first,value), rest)

so that this is a call to the same function, in which

both value and a_2.ist are updated accordingly.

Hence the following while-loop in pseudo-Aria is a

valid translation:

result :- value;

aux_list := a_list;

_hile aux_list /= [] loop

result := f(aux list(l), result);

aux_list := rest(aux_list);

end loop;

An obvious efficiency improvement is to use an index variable, updating this variable instead of copying a list. Furthermore, since the loop will iterate

length(a_.lis_) times we can use a fo_loop.

result := value;

for j in 1..lensth(a_list) loop

result := f(a_list(j), result);

end loop;

To write the above loop in Ada we need to provide

an implementation for lists and perform the corresponding translation on them. Unlike the translation for fold.r_1, this loop is efficient with linked

implementations for lists because the elements are

accessed in order.

4.5 Example: A simplified telemetry

processor

A _elemetry processor is a program that interprets

telemetry data sent from a spacecraft. Satellite

telemetry data is a sequence of samples, each containing a set of measures representing the status of

the spacecraft systems [4]. Data is transmitted to a

ground station in binary form, packed in fixed-size

bit matrices called master frames.

The telemetry processor takes this coded data

and produces calibrated data in engineering units

6109

5-17
(e.g.,meters,Watts) in floatingpoint format. The

calibrationisdone by extractingeach measure from

themaster frame and evaluatinga polynomial on its

value. Besides,some measures requiremaximum

and minimum limitcheck. The input to a telemetry processorisa master frame and a setof descriptionsofmeasures. The output isa set of calibrated

measures.These setswillbe representedby lists.

The followingPUC type declarationrepresentsa

master frame as a listof listsof bits.

zype bit is (On, Off);

Zype row is list of bit;

type masZer_frame is list of row;

Each row in the master frame is a fixed-length

bitstring considered to be divided into several bitstrings of various lengths representing measures.

Measures are described by the following attributes:

name, position in the master frame, and calibration

parameters. The position in the master frame includes the row number and the first and last bit positions within the row. Calibration parameters for

each measure are: coefficients for the polynomial, a

check-range flag, and minimum and maximum values (used if the flag is true.)

Zype measure_description is

record

name : string;

row_num : inzeger;

first_bit : integer;

last_bi_ : integer;

coeffs : list of real;

do_check : boolean;

min_value : real;

max_value : real;

end;

Calibratedmeasures are describedby the name

of the measure, the resultof the polynomial evaluation,and a range check code that iseitherSmall,

In..range,Large, or l(o_ckeck,depending on the

range check of the value.

type range_code is (Small, In_range,

Large, No_check) ;

type calibrated_measure is

record

name : string;

value : real;

range : range_code;

end;

The main functionof the specificationis ca.Zibral;e_aszer, which returns a listof calibrated

measures given the master frame and a list of measure descriptions. It.is defined apply'ing function calibraze.measmce to each measure description (Figure 4.) Function calibrate.measure uses

function ex'cracZ to obtain the bitstring of the measure, function So.number to convert from binary

to floating point, and function poly_eval to evaluate the corresponding polynomial. The range check

code is computed with a nested ±:E expression.

To generate an Ada program we need to provide

translations for functions like apply, curry, etc.

We also have to decide how each list will be implemented. Figure 5 is the main program in Ada.

The list of measure descriptions in represented by

an array because the number of measure decriptions is fixed for each satellite. The apply function

[s translated into a for-loop because the size of the

list is a constant. The curry function is not explicitly translated: it is only a notation to provide the

additional parameter within the loop. An explicit

list of calibrated measures is built in local variable

resulz, which is the returned value.

5 Conclusions

We have presented a specification language suitable for a specific class of software engineering

environments using Ada. The main purpose of

this language is to bridge the gap between very

high level specifications and detailed algorithms and

data structures, so we have attempted to define constructs that are similar to those in Ada, especially

in data structures. On the other hand, the need to

represent application level concepts has led us to include features like higher order functions and polymophism, to increase the reusability of the specifications.

We had to make several trade-offs in the design

of PUC, because we wanted expressiveness, simplicity and similarity to Ada. We decided not to

include algebraic data types and pattern matching

(present in several functional languages); the more

familiar concepts of variant record and case expression were used instead. We included parametric

polymorphism, higher order functions, and Curring

(i.e., partial parametrization of functions), but since

these are advanced features, we wanted them to

be explicit. Having these constructs complicated

the process of translation from PUC to Ada, but

they provided the abstraction mechanisms needed

in a specification language. Hence, we studied semiautomatic methods of translation.

6109

5-18
function calibrate_master (master : master_frame;

measures: list of measure_description)

return Iist of calibrated_measure is

beg_

apply( curry(calibrate_measure,master), measures )

end.;

function calibrate_measure (master: master_frame; measure: measure_description)

return calibrated_measure is

bits := extract(master, measure);

value := poly_eval(measure.coeffs, to_number(bits));

code := if not (measure.do_check) then No_check

elsif value < measure.min_value then Small

elsif value > measure.max_value then Large

else In_range end;

begin

calibrated_measure'(measure.name, value, code)

end calibrate_measure;

Figure4: Calibrationfunctionsof telemetryprocessor.

function calibrate_master (master : in master_frame;

measures : in list_of_measure_description)

return list_of_calibrated_measure is

result: Iist_of_calibrated_measure;

begin

for j in measures'range loop

res%Llt(j) :- calibrate.measure(master, measures(j)):

end loop;

return result;

end;

Figure 5: Main function in Ada.

6109

5-19
A specification language is not useful unless there

is a software development method that will include

its use. We have presented two non-exclusive methods: use the specifications as a prototype and transform the specification into an Ada program. Both

approaches require the development of supporting

tools. The language, along with its related methods and tools, will provide for a practical semiformal software engineering environment. However,

we have not tested extensively the use of functional

languages in the specification of large scientific software in Ada.

Acknowledgements

Thanks to Sergio Cgrdenas-Garcia and Eduardo

Ostertag for their helpful comments.

References

[1] Grady Booth. Software Engineering with Ada,

The Benjamin/Cummins Publishing Company, Inc., Menlo Park, California, t987.

[2] Luca Cardelli. Basic Polymorphic Type Checkins, Science of Computer Programming , Vol. 8,

1987, pp. 147-172.

[3] William D. Clinger and Ralph L. London. A

Role for Functional Languages in Specifications, Proc. Fourth Int'l Workshop on Software

Specification and Design, CS Press, Los Alaznitos, CA, 1987, pp. 2-7.

[4] General Electric Company, Valey Forge Space

Division. Software Specifications for Ada ReDevelopment Project (DSCS-III Application),

Philadelphia, Pennsylvania, 17 June 1982.

[5] John V. Guttag, James J. Homing, and

Jeanette M. Wing. The Larch Family of Specification Languages, [EEE Software, September

1985, pp. 24-36.

[6] Peter Henderson. Functional Programming,

Formal Specification and Rapid Prototyping,

IEEE Trans. Soft. Eng., Vol. SE-12, No. 2,

February 1986, pp. 241-250.

[7] C.A.R. Hoare. An Overview of Some Formal

Methods for Program Design, IEEE Computer,

September 1987, pp. 85-91.

[8] R. Kowalski. The Relation Between Logic Programming and Logic Specification, Mathematical Logic and Programming Languages, eds.

C.A.R. Hoare and J.C. Shepherdson, PrenticeHall, Englewood Cliffs, N.J., 1984, pp. i1-28.

[9] David C. Luckham and Freidrich W. yon

Henke. An Overview of Anna, a Specification Language for Ada, IEEE Software, March

1985, pp. 9-22.

[10] R. Morrison, A.L. Brown, R. Carrok, R.C.H.

Connor, A. Dearie, and M.P. Atkinson. Polymorphism, Persistence and Software Re-Use

in a Strongly Typed Object-Oriented Environmeat, Software Engineering Journal, November 1987, pp. 199-204.

[11] Norman Ramsey. Developing Formally Verified

Ada Programs, ACM SIGSOFT Engineering

Notes, Vol. 14, No. 3, May 1989, pp. 257-265.

[12] Pablo Straub and Marvin V. Zelkowitz. PUC:

A Functional Specification Language for Ada.

University of Maryland, Department of Computer Science, Technical Report CS-TR-2404,

UMIACS-TR-90-17, February 1990.

[13] Pablo A. Straub. Bias and Design Decisions

in Software Specifications. University of Maryland, Department of Computer Science, Technical Report CS-TR-2476, UMIACS-TR-90-

72, May 1990.

[14] Robert B. Terrwilliger and Roy H. Campbell.

An Early Report on ENCOMPASS, lOth International Conference on Software Engineering,

April 11-15, 1988, Singapore, IEEE Computer

Society Press.

[15] Simon Thomson. Functional Programruing: Executable Specifications and Program

Transformation, ACM SIGSOFT Engineering

Notes, Vol. 14, No. 3, May 1989, pp. 287-290.

[16] D.A. Turner. Functional Programs as fi_xecurable Specifications, Mathematical Logic and

Programming Languages, eds. C.A.R. Hoare

and J.C. Shepherdson, Prentice-Hall, Englewood Cliffs, N.J., 1984, pp. 29-54.

6109

5-20
SOFTWARE RECLAMATION:

Improving Post-Development Reusability

John W, Bailey and Victor R. Oaatli

The UniversW of Man/lend Department of Computer Science

College Park, Me.land 20742

This paper describes part of a multi-year study of

software reuse being pedormed, at me Univenuty of Maryland.

The part of the study which is reported here explores

tecnniques for the transformation of Add programs which

preserve function but whic_ result in program compononls

that am more independenl, and presumal:dy merefore, more

reusable. Goals for the larger study include a precise

specification of the transformation technique and its

aloCdicatton in a targu development ocgunization. Expected

results of the larger study, whioh am partially ooveflKI here.

are the idsntilTcation of reuse promoters and inhibltore both

in the problem space and in the solution space, the

development of a sm of metrics wfllCtl can he apl_ied to both

developing and com131ated software to reveal the degree of

reusability wtlk:_l can be expected of that software, and the

development of guidelines for both clev_0q_trs and reviewers of

software which can help assure that the deveiomid software

will be as reusable as desired.

gains can be realized and further work can be guided i_y

understanOing how software can be develo_ with a minimum

of newly-<jenerated source lines of code.

The work covered in this pager inctudes a feasibility study

and some examples of generalLzing, by transforming, software

source code after it has been initially deveioged, in order to

improve its reusability. The lean software reclamation has

been chosen for this activity since it does not amount to the

development of but rather to the distillation of existing

software. (Rec4amation is defined in the dictionary as

obtaining something from used products or restoring

something to usefulness [3].) By exploring tl_e ability to

modify and generalize existing software, c_aractarizations of

that software can be expressed WtltC21relate to its reusability,

which in _ is related tO itS malnlalnabilily and portability.

This study in(dudes applying _ese generalizations to several

small example programs, to medium sized programs from

different organizations, anO to several fairly large programs

from a single organLtarion.

The advantages of transforming existing software into

reusable components, rather than cradling reusable

components as _rl independem activity, incfude: 1) software

development organizations ellen have an an:hive of prewous

proiectS which can yield reusable ooml_ments. 2) devalopers

of ongoing projects do not need to ad)usl to new and possibly

unproven methods in an attempt to develop reusable

components, so no risk or deveic¢,mmt avemead is introduced.

3) transformation work can be accomplished in parallel with

line developments but be separately funded (this is

particularly _otical01e when sollware is being developed for

an outside customer who may not be willing to sustain the

addifidnal costs and risks of developing reusable code), 4) the

resulting components are guaranteed to be relevant to the

aib_icatton area. and 5) me coSt is low and controllable.

Introduction

Broadly defined, software reuse inck.,des more than the

repealed use of particular code modules. Other lile cycle

products such as speofications or tasl plans can be reused.

software development processes such as varilication

lechniques or cost modeling methods are reusa_e, and even

intangible products such as ideas and experience contribute to

the total picture of reuse [1,2|. Although process and fool

reuse is common practice, life cycle pnxlucf reuse is still in

ils infancy. Ultimately. reuse of early ;ifecycts products

might provide the farthest payol/. For the near term. however,

Earlier work has examined the principle of software

re¢lamalion through generic extraction with small examples.

This has revealed the various levels of difficulty wnictt are

aasooated _lfh generalizing venous kinds of Add dependencies.

For example, it is easkN" to genera_ze a dependency that exists

on encagsulafed data than on visible data, and it is easier To

generalize a dependency on a visible an'ay type |hen on a

visible recotcl type. Following that work. some medium-sized

examples of existing sollware were analyzed for potential

generalization. The limited success of trtese efforts revealed

additional gutdelines for develownenl as well as [imitations ot

the technique. Summaries of this preceding work appear in

the following sections.

Used as data for me current research is Add software Item

the NASA Goddard _ Flight Canter whioh was written over

tf_e past three years to perform spacecretl simulations. Three

programs, ench on the order of t00,000 (editor) lines, were

sluo_l. Software code reuse at NAS/VGSFC has been prectioe_l

for many years, originally with Fortran developments, and

more recently with Add. Since transilioning to Add.

management has observed a steadily increasing amount el

software reuse. One goal whictt is introduced here but wmCh

will be aOdressed in more detail in Ihe larger study is the

understanding of the nature of Ihe reuse being practiced there

and to examine the reasons for 1_e im_'ovemen! seen w=th Aria.

Another goal of this as well as the lan:Jer study is to comoare

the guidelines derived from the examination of how different

programs yield (o or resist generatizatK)n. Several questions

8th Annual National Conference on Aria Technology 1990

6109

5-21
are considered through this comparison,'_,including the

universality of guidelines derived from a single program and

whether the effect of the application domain, or problem

space, on software reusability can be distinguished from the

effect of the implementation, or solution Sp_K:_.

Superficially. tNerefore, this paper describes a technique

for generalizing existing Aria software throu_1 the use of the

generic feature. However, the success and precticality of this

technique is greatly affected by me style of the so(twain being

transformecl. The examination of what cheramenzations of

so,ware are correlated with transformabilily has led to the

derivation of sofl_,_Jre development and review guidelines. It

amsears that most. if not all. of the guidelines suggested by

this examination are consistent with good programming

practices as suggested by omer studies.

_=LmmG..T.smmm=

By studying the de_nder_es among software elements at

me ccx:le level, a determination can be made of the reusability

of those elements in other contexts. For example, if a

component of a program uses or depends upon another

component, then it would not normally be reusa_e in another

progr'_n where that ot_r c=mpomNtt 'as not also present. On

the other hand, a component of a soft,aare pm(Farn wni¢_ does

not depend on any other softwere can be used. in theory at

least, in any m"oitr_'y center. This study concentrates only

on the theoretical reusability of a component of sottware.

whion is defined here as the amount of dependence that exists

between that ¢ont_oneN and other soft,life components. Thus.

it is cortcemed only _ttt the syntax of re_t=le software. If

does not directty address issues o| ptacti,_i reusaOdily, such

as whether a reusal_ component is useh,d enough to encourage

other developers fo reuse it instead of redeveloping its

function. The goal of the _ is to identify end extract the

essential furmtionetity from a program so that lille extracted

essence is not degerK_lt on extern_ declarations, information,

or other knowledge. Transformations are needed to derive

such components from existing software systems since

;nter.component dependencies arise naturally from the

customary design c_:ompo_tion and implementation processes

used for software development.

Ideal examples of r_ sohwm'e code components can

lee defined as those which have no dependencms on other

software. Short of complete independence, any deper_lenc=es

wmcn do exist provide a way of quantifying the reusalmlity of

the components. In other wordS, the reusability of a

component can be thought of as inversely proportional to lhe

amount of external dependence required by that component.

However, some or all of that dependence may be removable

through transformatiOn by generalizing the component. A

measure of a com_nenrs dependence on its externals wncn

quantifies the diffioulty of removing that dependence through

transformation and generalization is slighUy different from

simply measuring the dependence directly, and is more

specifically appropriate lo this study. The amount of such

transformation constitutes a useful indication of the effort to

reuse a I:x)dy of software.

Seth Ihe transformation effort and the degree of success

w,ln performing Ihe Iranstorms can vary from one examine to

the next. The ,dentificatmn of guidelines for developers and

reviewers was made possible by observing whal 0minored or

tnnpeaed the transforma,ons. These gu_elines can also hetg _n

tile select=on of reusable or transtorrn_le parts from existing

8th Annual Natmnai Conference on Aria Technology

sollware. Since dependemmas among software components can

typically be determined from the soft-were desqn, many of the

guidelines apply to the design pease of the life cycle, allowing

earlier analysis of reusability and enabling possible

correctNe action to be taken before a design is implemented.

Althougll the guidelines sure written with respect to the

deveicoment and reuse of sy_ems written in the Ada language.

since Ada is the medlum _" mie study, most _ly in general

to softw_'e deve_ent in any L_guage.

One measure of the e..tent of the transformation required

is the number of 5nas of code mat need to be added, altered, or

deleted [4]. However. some modifications require new

constructs to be added to the software while others merely

require syntactic adjustments that could be performed

automatically. For this reason, a more accurate measure

weighs the changes by their difficulty. A component can

contain dependencies on externals that are so intractable that

removing them would mean also removin_ all of the useful

functionellly of the component Su_ transformations are not

cost-effective. In these cases, either the component in

question must be reused in conjmtction wwthone or more of the

components on which it depends, or it cannot be generalized

into an independenby reusai_e one. Therefore. for any given

component, there is a possibility that il comains some

dependendes on exlernals ,_tich can be eliminated through

transfomtation and also a poestbtlily that it contains some

dependencies wmc_ cannot be ellminalecL

To guide the transformations, a model is used wnich

distinguishes between software fun¢_on and the declarations

on whioJ't that function is performed. In an object-oriented

program (for here. a I_'Ogmm which uses data ai_tr_'lion),

data dec_I/_ticns and a_lOCiated functionality am grouped into

the same component. This component itself becomes the

decJaration Of another obJscL This means the function /

declaration distinction can be thought of as occurring on

multiple levels. The internal_ de_lrations of an object can

be distinguished from the construction and access operations

supplied tO external usem of the oble_, and the objecl as a

whole can be dlStli'KJui_=hed from its external use wt_h al:x_ies

additional function (possibly estaDiishing yet another, higher

level object). The dlstinction beiv_n functions and oOjects is

more obvious where a progrem is not obiect-onented since

declarations are not grouped with their associated

functionality, but rather are established globally within the

program.

At each level, declarations are seen as agplicalion-sDeafk:

while the functions performed on them are seen as the

potentially generalizable and reusable parts of a program.

This may appear backwards initially, since data abstractions

composed ot both de¢_r'alfons and functions are often seen as

reusable components. However, for consistency here,

functions and de_arations withina dam abstraction are viewed

as separaOle in the same way as functions which depend on

declarations contained in external components are separable

from those declarations. In use, the reusable, indel_endent

functional comgonen's are composed with application-specific

decJarations to form obiects, which can further be composed

with other independent functional components to implement an

even larger portion of the overall program.

Figure f shows one way of representing this. All the ovals

are OOlects. The dark ones are primmves which have

predelined operaPons, suctt as inleger or Boolean. The while

ovals represent program-supplied lunctionality wnicn is

composed wdh their contained obiects to form a higher level

t 990

6109

5-22
ooject. The intent of the model is to distinguish this programspecific functionality and to attempt to represent it

;edependently of me obiec N _ wtdcn it a_s.

al_CaO_ _on " "

F'tgum I.

Some Ada w_ic_ migm be r_0msanted as in me above

tigun3mkjhtbe:

package Coun_.e¢ is -- resuffirlg o_e_

procedure Reset: -- al:)l_le function ...

p¢ocedu=e Incremen_:

function Cu=ren_ Value =Qturn Natural;

end Counter;

package body Coun_e¢ is

Co_;n_ : N4_uEal :-0; --S_pleOb_K_

proceduzl Reset £a

Coun_ :_ 0;

end Reset;

procedure Increment i=

begin

Coul1_ :_ Co_t + _;

end Increment:

function Current Value re_urn Natural i3

Dec]in

return Count;

end Currant_Value:

end Counter:

package Hax...Coun_ £= -- _sulUng Ot3i_'l

procedure Rese_; -- al:_icaDle _nctmn...

procedure Zncr_nt;

function Current_Value re_ucn NaturaA;

function Max Ee_urn Natural;

end Max_Cou_:

wi_h Counter:

package body Max Count is

Hax_Val : Natural :-O: --_n_ljt_afo_iect

procedure Rese_ is

begin

Counter. Reset;

•nd Reset;

procedure Incremen_ L3

beg_n

Councer._ncremen_:

;f Max Val < Counter. Current Value _hen

Hax_VaL :" Coun_er.CurrentValua:

en_ if;

end _ncremenc;

function Current_Value re_urn Natural _s

beg_n

re_rn Co_n_eE.CurEen__Va_a;

en_ Curren[Value:

function Max re_urn Natural is

begin

re_urn Max_Val;

end Max;

end Max..Coun_;

In this example, the objects are properly encapsulated,

though, they might not have been. If. for example, the simple

objects were declared in separate components from their

a_ollcab_e tunct/cMls, the result could have been the same

{although the diagram might look different). In actual

p_, Add programs are daveloped with a combination of

encapsulated object-operation groups as well as separately

dec_ed object-operation groups. Often the lowest levels are

encapsuiamd while ff_ hk]/_er levet and larger oD)ec',s tend to

be separate from their applicable function. Pemaps in the

idea_ case, all obiects would be encapsulated wilh tlleir applie(]

function since encapsulaUon usually makes the process of

extracting the functionalily at a later time easier. This,

therm'ore, becomes one of the gmdelines revealerJ by this

model.

If the above example were transformed to separate the

func_onality from each object, the following set of components

might be derived:

gene_£c

type Coun_ Objec_ is (<>);

package GenCountec £3 -- resu_ng o_ect

p=oc_l_uce Reset: -- applicable_nction ...

procedure ZncE,,_,-nt:

function Current_Value return Count Object;

end Gen_Coun_ar:

package body Gen.Counte¢ £3

Count : Count Ob_ec: -- simon o_ec_

:- Count_Object'ricer:

procedure Reset £3

begin

Coun_ :" Count_Objec_'Eirs_;

end Reset:

_rocl_,ure Incremen_ L3

begin

Coun_ :- Count Ob_ecu'Succ (Count):

end Increment;

function Curren_Value ce_urn Count_Objec: _3

beg_n

ce_urn Count;

end Current_Value;

end Gen_Counter;

generxc

type Coun_Objec_ £3 (<>_;

package Gen_Max Count LS -- resulting object

procedure Reset; -- a_lioai_e_nction ...

procedure _ncremen_:

function Curren_VaL_e re_urn Coun_Ob3ec_:

function Max re_urn Coun_Ob]ect:

end GenMax_Count;

_ich GenCoun_er;

package body C.en Max Coun_ ¢s

Max_Val : Coun__Ob3ect -- aOOit_nel oOiec!

:-- Count_Object'First;

package Counter is

new c_nCounter ICountOb]ec_):

8th Annual National Conference on Add Technology 1990

6109

5-23
pcoceduce Reset £3

begi.n

Courir.eE. RQ3Qt ;

end Keser.;

p¢ocedt.l£1 Znc=mnr. i3

_K;in

Count.st. ZncEemmnr.;

if Max v41 < Countec.Cu==ent Value then

Max Val :w Coun¢l=.Cu==ent Value;

e.d :L_';

end Znc_mmnc;

_'unc_ion Cu]:z:en_ Value return Na_;u=aJ. is

_Klin

recuzn Counte¢. Cu=renC_Va lue;

end Cuc=encValue:

function Max Cecum Natural £s

begin

=e ._ u_n, Max Val;

end Max;

e.ci Oen__xCounc:

v£ch Gen _x.Co_c:

p=ocedu,'e Haz_Counr._Use= £',

p4cJ¢aqg Max Count is

new Gen Max Count (Natural) ;

beq_n

Max_Co.nC. Reset;

MaxCounr.. IncEl_snt ;

end Max Coullt User;

Note that the end user oOuUns Ihe same functlonstily thai a

user of Max Coun! has, but the software now allows the

primitive object Natural to be supplied externally 1o the

algonmms tha! wiii _ to it. Further. the user could have

oblamed anaingous functk)naldy for any dis¢:ale type simply

Oy pairing the general OOleCl with a different type (using a

different generic instsntiation).

This model is somewhat analogous to the one used in

Smalltalk programming where o_ects are aasemOled from

other objects plus programmer-supplied speatics. However,

it is meant to apply more gan_dy to Ads and omer _nguagas

that do nol have support for dynamic binding and full

inheritance, features that are in general unavailable when

strong stalk= type cheOdog is reCluCed. Instead, Ads offers the

geneno feature whic_ can be used as shown here to partially

offset the constraints imposed by static checP, ing.

Applying this model to existing sotiwam means that any

lines of code wflk=h represant reusable funcbonaJiW must be

paramalsrized with ganenc formal parameters in order to

make them independent from their sun'oundtng declaralmn

.%pace (if they ate not a_'eady indag_l). Generics that are

extracted by generalizing existiJlg program umts, through the

removal of their dependenca on external declarations, can then

be offered as independently reusable components for other

applications.

Unfortunately. dec_aratNe dependence is only one of the

ways that a program unit can depend on its external

environment. Removing t,le compiler-detectable dec_aratwe

clependenoies by produong a generic unit is no guarantee that

the new unil will aclually be independent. There can be

depenaenc;es on data '.,slues that ate related Io values in

ne_htx)nng software, or even dependenoes on protocols ol

operaUon that are followed et the point where a resource was

originally used but which couk:l be violated at a point of Eater

reuse. (An sxampla of this Idnd of dependency is described in

zhe Measurement section.) To be complete, the transformation

I:,roceas would need to identify and remove these other types of

dependence as wall as ths declaraUve dependence. Although

guk=e_as have been idan_'fledby this study whictl can reduca

me _Uty foe these other types of dependencies to enter a

system, this work only concentratas on mechanisms to

measm and remove decdaratiw depef_enca.

in a language with strong sta_c type cnec_ng, such as Ads.

any information exchanged belween communicating program

units must be of Some type which is available to both units.

Since Ads enforces name equivakmca of types, where a type

name and not jusl the underlying structurs of a type

introduces a new and dfstinct type. the declaration of the _:ype

used to pass infomlalk=n betw_m units must be visible to Ooth

of those units. The user of a rssoums, merefore, is

constralnecl to be in the scope of aH type declarations used in

me interface of that resoum_. In a language with a fixed set of

types this is not a problem since ell pos*ible types will be

globally avali_hle to both the resource and its users.

However. in a language which allows user-declared types and

enforces strong static type C_lec_Ing of those types, any

inter-component communkcabon with such lypas must be

performed in ths scope of those programmar-defined

dacJarallons. This means that ths coupling between two

communicating components increamm from data coupling to

external coupling (or from level two to level five on the

traditional seven-point scats of Myers. wl_ere level one is the

lowest level Of coupling) [5].

Consider, tot example, projeut-sCecJfk= type bec_aralions

whic_ often appear at low, commonly visible levels in s

system. Resources whk=_ build upon those declarations can

then be used in turn by higher level application-specific

components. If a programmer altampts to reuse moss

intermediate-level resoumes in a new context, it is necessary

Is also reuse the low-level declarations on which they are

13uilt. This may not be acc_e, since combining severa_

resources from different original contexts means that the set

of low-level type declarations needed can be extensNe and not

generally compatible. This situalk_l can occur whether or not

data is encapsulated wilh its al_ticable function, but for

clari W, and to contrast with the previous examples, il is

shown here with the data and its operations declared

separately.

For example, imagine thai two existing programs each

contain one of Ule following paJr,J of compilation units:

-- First program contains first pair:

package vs_t i3

type VaciabLe_S_cinq _=

cecorc_

Data : $_.cinq (l.._0) :

Le_qC_ : Na_u_a_ :

e_d _ecor_;

func_ _on var_la $_r_ng _com Usec

:e_uc_ VaciaDle 5tcLng;

end Vs 1 :

8th Annual Natmnal Conference on Ada Tecfmology 1990

6109

5-24
with vs 1;

packaqe Pm...1 is

_ype Phone_Messaqe is

record

Fr_n : Vs_l.Vari_e_String;

To : Vs 1.variable Strinq;

Data : vs_l.Variable String;

end recor(l;

function Phone Messaqe F=om Use=

:e_uEn Fhone_Hessaqe;

end Pro l;

- Second pr0grsmcontains second pair:

packaqe Vs 2 is

type Variable_S_rinq i4

record

. Data : St=inq (i..250t :- (others->' ');

Len_h: Natural :- 0;

end record:

function Variable S_=ing From User

return variable String;

end vs2;

with VS 2;

packe¢]Q Mm 2 is

type MaiiMessage is

record

Prom : VS 2. Variable_S_ring;

To : VS 2. V&rlable $_ring;

S"hject : VS 2.VaEiable_$_rinq;

Text: : VS_2. Va EiaDie_S_ ring;

end record;

function Mail Hessaqe From User

L1_urn HailMessage;

end Mm2;

Now, cons_er the pmgramme_ who is _ to reuse the

a_,e de_s in _e same proqram. A reason_e way to

comOine the use of Mail_Messages with the use of

Phone_Massacre m_ht seem to be as follows:

with vs i;

with Pm_l;

w_th _2:

pcocedure User £s

Name : VS l.Varia_le_Strinq;

?m : _m _.Phone Messaqe :-

Pm 1.Phone Messaqe Fcom User:

: P_ 2.Mail Hessaqe :-

_l 2. Me il_He s saqe __ rom_U 3e r :

beqin

Ne_ := Pro. To;

M.F=om :- Name: -- ileal

end User:

This writ fail to compile, however, since [he types Vs 1.

Variable Siring and Vs_2.Vsriabte_Stnng are distinct and

theretore values of one are not assK3nable to oDiects ot the

other (the value of Name is of type Vs_f.Variable_$lnnq and

the record component Mm.From is of type Vs 2.

Variable_String).

In t,e above example, note that the vana_e string _ypes

were left visible rather than made Orb,ate to make d seem

even more I_ausible for a proqrammer to expect that, al leasl

k:_:j=cally, the assignment altemple¢l is reasona01e. However.

the incompatibility belween the underlying type declarations

used by Mail_Message and PhoneMessage 0ecomas a problem.

One solulion might be to use type conversion. However.

employing %q_ conversion bar,wean elements of the low level

variable string types destroys the abstraction for _he

higher-level units. For instance, the user procedure above

could be written as shown bek:y_, but exposing the detail of the

implementation of the variable s_'ings represents a poor. and

possibly dangerous, programming st_de.

wlth Vs_l:

with _ I:

wlth M_-2:

procedu_ Type_ConverslonUser is

_ame : VS l.Varlable_Strlng;

Pm : Pm_l.Ehone Message :-

Bm_l. Ehone_Message__rcm User:

H_ : Ha 2.Mall Hessage :=

Hm 2. Mall Hessaqe _rc_ User;

_e_n

:= _.To;

Hm.Frcm.Da_a (1..80) :- _ame.,_ata:

H_.From.Lencj1:h :,, Na_e.Lenq_h;

end Type_ConverslonUser:

Notice thai we had to be careful to avoid a constraint error

at the point of the data mignment. This is one example of how

attempts to combine the use of resources which rely on

different context decJarations is difficult in Ado.

Static type checking, therefore, is a mixed blessing. It

prevents many errors from entedn 0 a sotlware system which

might not oth@_i_ be detected until run time. However, _f

limits tl'te pose=Me reuse o! a module if a speofic declaration

environment must also be reused. Not only must. the reused

module be in the scope of those decklratlons, but so must _ts

users. Further. those users are Iorcod to communicate wlm

tibet module using ttte sh_red external types rather than [he*r

own, making _e reSOurCe master over its users insteaa ot me

other way around. The set of types which facilitates

communcalion among the components of a program, therefore.

ultimately prevents most. if not all. of the developed

alqonthms from being easily used in any other program.

This stu_ refers to dea_atmns suc_ as those of the above

vanaO_e stnnq types as contexts, and to components which

build upon those declarations and wnic.n are in turn used 0y

diner components, such as the al0ove Mad_Message and

Phone_Message packages, as resourCes. Components whw.m

depend on resources are referred to as users. The above

illustrates the generat case of a context-resource-user

rela[ionsh=p. It is possible for a component to be both a

resourCe at one level and also a context for a still hk:Jher-level

resource, The cl_ among these three bask: Cetegones

of components can be illustrated with a clirected graph. F_ure

2 stlows a graptt of the kin_ of dependency iltus{rafed in the

examole aOove.

A resource does not always need full type information

odour me data it must access in order to accomplish its task.

In ;he a0ove examples, it would be possible for the Mail and

Phone messaqe resourCes to _mplement their functions via the

funCtions exporled from the variable string packages without

any further information about the structures of those lower

level varla01e string types, Sometimes. even less knowle0oe

8th Annual National Conference on Aria Technology 1990

6109

5-25
of the structure or functionality of the types being

manipuJated by a resource is required by that resource for it

to accom_is_l its funcUon.

user

resourc/_ I

context

A

B

= A depends on B

F'KJure 2.

A common example of 8 situation where a resource nee_s

no structural or operational informabon alx)ut the objects it

man_)ulates is a sirn_e dam _ whic_ stores and retrieves

data but which does not take adventage of the infonnaUon

contameq by that data. It is possJbte to write or transform

such a msoume so _ the comext It requires (i.e.. the type of

the object to be stored and relrieved) is _ by llm users

of [hat resource. Then, only the esslmtlal work of the module

needs to remain. This "essence only" princ_ is the key to

the transformations sought. Only the purpose of a module

remains, with any details needed to produce the executing code,

such as acr,_ type dec_aretlone or specific obera_ne on those

types, being provided lat_ by the user= of _ resource. In

18J1_usQes st_ as Smalllalk whk:tl alfow dynamic binding. [his

informabon is bound at mn lime. In Ada, _ the COml_er

is obligateq to perform all type c_ecking, generics are bound

a! completion time. elimthetlnQ a major soured of tun time

errors caused by attempting to perform inappropriate

operations on an c_ject. Even though they are statically

cnea(ed, however, Aria generics can often allow a resource to

be written so as to tree it from deoen_ng upon external ly13e

definitions.

Using the following arOitrary type declaration and a

siml_ifleq data store package, one posmbie transformation is

illustrated. First lfle example is shown before any

transformation is applied:

-- context:

package DecZ= £=

:ype Typ £= ...

end OecZ=;

-- anything but iimiled wivate

-- resource:

w_th Oecls;

p,_=gage Sto=e Ls

pcoceOu_e Put [Obj : Ln Decl3.Typl:

procedure C,et_La_t (Obj : out O(c_3.Typ):

end Store:

pac._.age body Shore is

Local : Decls.Typ;

p=ocedu,'e Pu'_ (ObJ : in Dec.Ls.T_:)) £3

Z.ocaA :- abe;

end Pul:;

p=ocedLl,gl G4_ Z._8_ [Ob'_ : ou_. DeCL=.TYP) £s

]::_rAn

ObJ :- Lena,L;

en,.i Ge_. t-=8_.;

end S_.o£e;

The =hove resource can be transfotmeq into the following

one when;'1_es no dopendef_ on external declarations:

- general_ed resource:

gene:£c

type 'rlrp £s p:_va_e:

packaqe Gene:aZSto:e £s

p_oc_Lu:n Pu_ (Ob_ : £n Typ):

p=ocedune Ge¢_Las_ (Ob_ : ou_ TTP);

end GeneEaL Stern;

pacJ(aqe body Gene¢&l Stone £"

Local : Type

procedure Pu'.. (ob_ : in Typ) Ls

Lo_al :- Ob_;

en_ Pul=;

procedu,.,._ Get L4sf. (Oh') : ou_. Typ) £s

_jL_

Ob_ := Local;

end. Ge_. rJ,s_.;

end. C-eneEal el=ore:

Note that, by naming the generic formal parameter

appropriately, none of the identifiers in _e code needed to

cringe, and me expended mimes wee merely shortened to

their simt:i names. This minimizes the herding requ_ed to

perform the transformation (although automating the process

woutd make this all t,M1JnlpOtlant issue). This transformation

required the removal of the context ctause, the addition of two

lines {the genenc part) and the shortening of the expanded

names. The _tfon required to converl the package to a

theoretically independent one constitutes a reusability

measure. A user of the resource in the original form would

need to add the following de,preteen in order to obtain an

appreciate instance of the resource:

package S_oEe iS hey Genocal_Store (Decls.Typ) ;

Formal rules for counUnQ program changes have aJrea_'y

been proposed and validated [4J, and a_aptations of these

counting rutes (sucll as using a lower han_lng value for

s_ottening expanded names and a hk_m" one for adding generic

formals) are being considered as pan of this work.

The earlier example with the variable string types can

also be gen_alized to remove me dependencies belween the

mall and phone message pack_es (resources) and the van=hie

string packages (contexts). For example, ignoring el're

implementations (bodies) of the resources, the following

would functionally be =huNalent to tltose examples:

8th Annual National Conference on A_a Technology 1990

6109

5-26
- Contexts. as before:

package Vs i is

type variable String is

recoEcL

Data : String (1..80);

Len : _;atu=ai;

end :ace=d:

function Va=iable S _ :ing_P=om Use=

return Variable String:

end Vs I:

package Vs 2 ia

tFpe Var_able_$t:inq £s

record

Data : String (1..250) :- (others->' ');

Lelt : Natural :m 0;

end race=dfunction Va :labia St ring_From User

return Variable $_ring;

and Vs 2;

- Resources. _ no iong_ depend upon

- the above come_ d_u_ns:

generic

type C_qponest is private:

packaqe Gen_e__1 is

type Phone_Message £s

recoEd

resin : Cumponent;

To : Component;

Data : Component:

end race=d:

function Phone Nessaqe rE¢m_Use=

ceturn Phone Hesaage;

end. Gen Pm i:

generic

type Component is private;

package Gen Hm 2 is

ty_ Mail_Messaqe is

record

from : Components

To : Coml_nent;

SubJ : Component::

TexT. : Component:

end. record:

_unct ion Mail HessageFromUse=

return Hair Message;

end Gen_M_ 2;

NOw. the _rammar who is twing to reuse the above

decJ_tons by comOininQ the use of Ma__MeasaQas _.th the

use at Phone_Messages has anothe¢ stolon. Inslead of t_,ing to

com_ne both contexts, just one can be chosen (in _is case.

Vs_2):

w£_h Gen_Pm 1;

vL,-n Gen Hm 2;

procedure Use= L=

package Pm i LS new

Gen Pm L (vs Z.Vacial)le_$t=£ng):

package Hm_2 £s new

Gen_Mm_2 (vs 2.Yaria_le_$trinq) ;

Name : Vs_2.var£aDLe String;

Pm : Pm_l.Ehone Message :-

Pm 1. P hone Me5 sage F =am User :

Mm : Mm_2.Mall Message :-

MB_2. Mail_Message r =am_Use r:

_egin

Nama :_ Mm.From:

_=. To := _" : - _w OK

end Use_:

An edditlonJ complexity is required for this example. The

rasou_es must be aDle to obtain component _pe values from

whlctl to conslfuc_ m_l and phone messages. Although this is

not obvious from the specifications only. it can be assumed

(hal suc_ func_onaUty mum be avallame in the body. This can

be done by adding a generic formal function parameter to (he

generic parts, requiring the user to supply an additional

parameter to the instsntla_ons as well:

generic

tYl_ Coml_onen¢. is privane;

_£_11 function Componen_ ?=am Use=

_rn Com_onen_;

-- paramete_ess for simpli¢i_

package Gen Fm i is

tY1_e Phone Message ks

record.

_:om : Component:

To : Com_onen_;

Data : Com_)nent;

end records

function Phone Walssage_From User

, re_rn Phone Message;

end Gen Fro_l;

Although the above examples show the context, t_e

resource, and the user as library level units, declaration

dependence can 0coJr. and transformations can be aoplie'ct, in

situations where the three components are nested. For

example, the resource and user can _e co-resident ,n a

dec_-alive area. or the user can contain me resource or v,ce

versa.

This reiterates the earlier c_aim that. at least for the

purpose of this model, it does not mailer if (he data is

encapsulated w_lh its ai_licaDle function, it ius[ makes i_

ea_er to find if i( is. In the programs studied. (be lewes( level

data lypes, w_ch were often _roperly encaosula(ed with tne_r

immediately avmlable operations, were used _o construcz

i_K]h_' leve4 resour_ spealic tO the problem being solved, f(

was unusual for ll10se resources tO be wn_en with me same

level st encapsulalion and indepenOence as me 1owe( level

types, and this resulted in the kind of context.resource-user

dependencies illuslrmed a_ove.

For example, in the case of the generalized simple dam

base. the functK)nality st the data appears in the resource

while the declaration of it appears in the conlext The only

place where the higher-level ooiect comes into ex_smnce is

inside the user come)anent, at the point where ihe instan(Jalion

is declared. If desired, an a0dltional transformation can be

aoplied 10 rectify Ibis problem of lhe apparen_ separation of

iI_e object from its operations. Inslead ot leavmq the

inslanlia(ion st the new generic r_.source u0 Is (he cliem

8th Annual National Conference on Acla Technology 1990

6109

5-27
software, an intermediate pac_rage can be created which

combines the visibility of the context declarations with

instanflatldns of the generic resource. This p_kage, thec,

becomes the direct resource for the client software,

introducing a layer of al0s_ that was not present in the

original (non-general) structure.

For example, the foilowir_ trans_rmallon to the second

example above cosines the msoume General .Swre w_ the

context of choice, type Typ from p_'kage Oecis. The

(:iscla_ion of the package Object performs this service.

(jmneric

type T!,p £a p¢lvaca:

package Genecal_$tcce is

pcoceduce PuC tObj : in Tlrp);

procmduce G4C Laac (ObJ : ouc Typ);

end Gene.-'a J._$ tore:

package Oecls iS

type Typ is ...

end Decla;

wich Oecia:

wic_ GenecalStoEe;

packaqe Ob_mcc £a

subtype Ty_ is Oecls.Tylp;

package State £3 new General_Stets (Typ);

procedure Puc (ObJ : in Typ)

canamas Sto£e._u_;

pcoceduce Gee_Last (Ob_ : out Typ)

cenames Stoce.C.-,etLast;

end Obaect.:

wit.h Ob Jecc;

p¢oceduca Client. J.s

It-" : Object..Typ;

ObJecr..Puc (IPem) ;

Object..Gec_Lasc Citron) ;

end Client.;

Note that no boo'y for _a _ is requ_ed usJ_ the

style shown. If it were preferable to leave the implementation

el Object flexli_e, so that users would not need to be

recoml_led if the context used by the insUmtlatlon were to

c_ange, the context clauses and the instimtistldn could be made

to appear only in the body of _ An atemam, adn_eUly

more complex, example is shown here which accomplishes

this flexibility:

packac_ Object is

type Typ is pcivat.s:

function In£t.ial cetum TTp;

pcocedu.--m Put (Ob_ : in Typ);

procedure GecLasc (Ob 3 : in Typ):

pcivace

uype Designated;

type Typ is access DesicTnaEed;

end Objecu:

with Oecia;

_LCh Genarai$tore:

package body Objec_ is

type Typ is new Oecls.Typ;

fultct.ion Initial cat.urn Typ is

_e=uEn new Designated:

and Znit.ial;

package at.ace is new General Store (Typ) ;

p¢oceduce Put. (ObJ : in Typ) is

begin

at.ecru.Put. (ObJ.all) ;

end Put.;

pcoceduce Gec Last (Ob_ : in Ty1:) £s

begin

Stoce.Get._Last (ObJ.a11) :

and GeL_Last.:

end Object.;

In the alternate example, note that the parameter mode for

the Get Last procedure needed to be changed to aJlow the

mating of me designated object of the actuaJ access parammer.

Also, a simple initialization function was supplied to proves

the clkmt with a way of passing a non-null _¢coss object to the

Put and G,et.Lasl procedures. Normally, there would aJreaOy

be initialization and constructor operations, so this aclditionat

operation would not be needed. The advantage of this

alternative is that the implementation of the type and

ol_rations can change w_hout distud_ng the client soth_'are.

However, the first alternative could be changed in a

compilatlon-comp_Ible way, such that any client software

*cued need recon_letlon but no modification.

It is also posoib_e to provide just an. instantistldn as a

I_)re_ unit by itself, but this requires the user to acquire

independently the visibility to the same context as that

instsotlatlon. This solution resultl in the reconstruction of

the original alluation, where the instentlatlon becomes the

resource degeedent on a context, and the user depends on both.

The important difference, however, is that now the resource

(the inslantlatlon) is not viewed as a reusable component. It

becomes appllcatk)n-sl_fic and can be routinely (pOtentially

automatically) generated from both the generaliz_l reusame

resource and the context of cJ_otce, while the generic from

which the instentiaUon is pmduc_l remains the independent,

reusala|e component The advantage of this structure lies in

the abstraction provided for the user component which is

insulated from the complexities of the instantiatldn of the

reusable generic. Since the result is similar to the initial

architecture, the overall software arcftitecture can be

preserved while utilizing generic resources. The following

illustrates this.

package Oecls is

type T_p is ...

and Decis;

9enecic

_ype Typ is privacs;

package General_Store is

pEocedure Puc (Obj : in Typ);

pcoc_ura Gec _as_ (Ob_ : out Typ);

end C,enera/ State;

w_.r.h Dec.Ls ;

witll Gena.,:al Store;

package Object. is new General SCots (Decls .Typ) :

8th Annual National Conferenc_ on Acla Technology 1990

6109

5-28
with Decls ;

with Object;

proc_u=e Client is

Item : Decls.Typ;

Object.¥ut (Item) :

Object.Get_r--st (Item) :

end Client:

8y modifying the generic resource to "Pass through" the

generic formal types, the useds to(lance on the oomext can be

removed:

generic

type C_n.cyp is private;

package C-,snera£ store is

=ubtype Typ i,s Gen.Typ: - pass me _/pe through

procedure Put (Ob_ : in Typ);

procedure C.et L_st (ObJ : out Typ):

end Generll Sto=e;

package Oe¢l= is

tYPe Typ is ...

end Oecl=;

with DecAs;

with Gene=aAStore;

package Object is new C-eneral_Store(Decls. Typ);

with Object:

proc_:l_re Client is

Item : ObJect.Typ;

bali.

Object.Put (Zteml:

Object.GetLast (Item);

end Client;

iea,cur_rlrleflt

In tt_e a_ove exam, _e ¢ontexl comOonents were never

modified. Resource cOmponenls were modified to eliminale

meir dependence on Context Components. User components

were modified in order to maintain medr functionalily given

the now genera/ resource Components, typically by defining

generic actual parameter o0iec_ and adding an instantialicn.

In ;he case ot the encapsulated ins_an,atmns, an inlerme_ate

component was inW0ducod to free [he user component ot the

complexity of the instantlabon. It is the ease or difficully of

modifying the resource ¢ompon_ts mat is of _mary inlerest

here, and the measurement of this modification effort

constitutes a measurement of the reusability of t.e

components. The _ity of me generalised resources is a/so

of interest, smce some may be difficult to inslanflate.

Considering me a_)ve e_ again, tfle simple data base

resourCe Store required the removal ot the context clause ana

the crealion of a generiC part (Ihese being typical

moclificalions for almosl all transformations o| this kind). In

addition, the formal parameter types for the two subprograms

were changed to me generic formal private type, causing a

change to born me sul:_roqram speclflcatmn and boo'y. No

further changes were required.

.- original:

with Oecls:

package Store £=

proceduce Put (ObJ : in Oecls.Typ);

pEoceduEe Get Last (ObJ : out DOcLs.Ty1=);

end Stote;

package body StoEe is

_ocsl : Oecls.:P11pr

p¢ocedctEe PUt (Obj : in Oecls.T'fp) is

be<;L,

r-,,e.il :- Ob_;

end Put:

p_ocedu¢e Get Last (ObJ : out Oecls.Typ) is

beqL.

ObJ :- Local;

end Ge__Last:

end SloEs;

- t_nsformed:

qene¢ic

tyl_l _ is private; -change

package Genera_Stoz_m is

procedure eut (ObJ : _.n Ty_): -(mange

p..'ocs_u_e Gec_Las¢ IOb_: out T_Z_); -c_ange

end Gene¢al_$toz_:

packaq_ body Gene_slSto_e is

Local : Typ:

procedure Put (Obj : in Typ) is -cnan_e

LOcal :- Ob_:

en_ Put;

p:oceduce Get Last (Obj: out Typ) is -cJ1ange

Ob_ :- Local:

end Get_Last:

end General Store;

The Phone_Massage and Ma_ Massage resources requi_d

me _ele_on of me conte_ c_use, the addison _ a genenc pan

cons_ng of a fontal _ivale _ parameter and a _rmal

subprogram parameter, and the replacement of _hree

occunlmc_s (or _ur0 in the case of MaC_Message) of the type

ma_ Vs_t.Variable_Strin0 with the generic formal type

CommnenL

-- original:

with V=L;

package _m 1 Ls

_ype Phone_Nessage i=

cecotd

Froea : Vs_t.Va¢iabieString:

_o : Vsl.Varia_eStzinq;

0aca : VsL.Veria_leStrinq;

end CardEd:

_unctLon Phone_MessaqeF¢omUser

ceturn Phone_Messaqe;

end Pml:

-- transformed:

generic

type Componen_ £= private: --cnan_e

w_tn function Co_ponent_FcomUaar

_eturn Component: --Chan_e

8th Annual National Conference on Ada Tecl_nology 1990

6109

5-29

ORIGINAL PAGE IS

OF POOR Q(JAI|Ty
package Gen__l__ is

CyI:MI Phone. Messaqe i3

_:ICOEC[

F=o" : Component; -charlQO

1"o : CoJponent;; - cflarlge

Da_a : Cc_po_lnr..; -ch s/IQO

it.m.ed,ion Pitons _essagll F=ol Use=

_t¢l,t_'t PhoneJ, lessag'e:

end Gen _ 1

GeneralizJng the 0odlas of Gen_Pm_t and Gen Me_2

would involve replacing any calls to the Variable String_

FromUser functions with calla to the genedo formal

ComponenLFrom_Usef function. In the case of the sJmpJe

s_:rwn before, fflJs would require three and fo_ sim_e

su0slitutions, for Gee Pm_l and Gen Me_2, reSl)eCtiVely.

In addition to memdng the reusaDWty of a unit by the

amount of transformation required to maximize its

indeoendence, reusal_t_ can Wso _e gauged by me amount of

residual dependency on other units which cannot be

eliminated, or which is unroasonal_y dffl_uit to elkninale. JW

any of the propoud transfonnltiomL For any given unit.

therefore, lwo valuel can be o41_l_ed. The first revere the

number of program _angee whictz wouid he required to

perform any a_ transfonnmio4nL The second indicaWs

Che amount of de_ w_ic_ wouid remain in me unit even

after it was l_ The oflglmll units in the examplas

a_ove would score high on the first scale since the lmndltng

required for its conversion was negliglt_e, imptymg that its

retml_lity was already good (I.e, it was aklady independent

or was easy to make inde_nl of external decorations).

After lhe transfonnalion, there remain no lalent dependenoes,

so the transformed gefler_ wouid receive a perfe_ reusalo_ty

SCOre.

Note tiler the object of any reusability measurement, and

therefore, of any transfom,.mions, need nOl I:)e a single A(;la

unit. If a set of library units were intended co be reused

toQmher d'len the melhc8 as _ al the trensfomlltk_ls cou_

he applied to the entire set. Whereas there might be

su_tantlal inten:ll_mdenco among the unils wilhin the set. it

still might be poss_le to ellrnlnete all dependencies on

external dec4ara_ons.

In me el=ore examples, one reeson that the transformation

was crivial was that t_ only operation performed on ot)_ecls

ot the extomai type was aas_nmem_ (except _or me mml and

phone message examples|. Therefore. it was i=oss_ie to

replace direct vialb_W to the external type definition with a

generic formal pt_vet_ type. A s4N:ond examp_ iJluslr_tee a

stiQhtty more difflcuJt transformation whir.J1 includes more

assumptions aOout the oxternally decJared lype. In the

foliowinQ example, indexing and component assignment are

used by me resource.

Before transformation:

-- conlext

package A¢:: is

_ype E_.em_ar:ay i3

array (Integer ranqe <>_ of Nar.ural:

encl A¢¢:

-* resource

w£r-h _=;

proce_.u=e Clear (I_.em : our. ;_:=.£_e_ A.c]:ay) L=

t_KFLn

_'oz: r Ln [_em'Range ],oop

Z_em CI) :- O;

end !oop;

end CZear-

-- USer

vi_h A=_:, Clea::

pcocedu.:e C1ien_ As

X : Z_'=.Z_.em A=_:ay (1..10);

began

Clea= iX) :

end. Cl£en_;

After transformation:

-- context (same)

package A.¢: £s

mype I__e__J_:ay £s

a=:ay (Znr-ege= canqe <>) of Namu=a.L:

end. A=:;

-- genermtzed resource

_'ene:ic

_._pe Com?_nent £" canqe <>:

_ype Index As =anqe <>;

:ype Gen A.c:ay 1:

a.,::ay (Znd41x range <>) of Component.;

p]:ocedu¢e C,en Clea|: C'n'e_ : our. C-en_Array} ;

pcocedure Gen Clea: (Zl_m : ou_" Gen_Array) is

fo= _ in Z_em'Ranqe loop

ZII:_,,, (Z) :- O:

end loop:

end. Gee Clea=:

-- user

vir.h AXE, Gen Clear:

pEoced_¢e Clienr. £s

X : A._¢.ZICell A_Eay (1..1O);

procedure Clear _.= nllV C.en Clla:

(Na_Eal,

Art. Zr.em_Array) ;

begin

CLea= CX) ;

end CIien_. ;

The alcove Iranstorm_ion removes compilation _ndes, and allows me generic ptncaclure to daso"ibe its essential

function without Ifle visibility o/ external dec_lrotions. As

t_efore,an intermediateoOjec_could be c_ated to free the user

procedure from the c_ore of instantlattng a Clear procedure.

which requires visibility tO _OOtllthe context and the resou_e.

However, it also illustrates an imporlant additional kind of

dependence whic_ can exist _ a resource and its users.

namely information d_ender_e.

In the previous example, the literal value 0 is a due Co the

presence of information that is not general. Therefore, the

following would be an improvement over the transformation

s_own aOove:

8th AnnuaJ NatlonaJ Conference on Ada Technology 1990

5-30

6109
generic

Pype Componen_ £s =anq@ <>;

_.ype Zndex .i.= _anqe <>:

type Gen_AJ:rsy L._

acray ($ndex _anqe <>) oe Component:

Ini_ Va_ : Co_poflen_ :-Componen_'F£rst;

pEocedurn Gen_CleaE (t_m : out Gen Array);

procedure Gen.Clem/ (It: '_s : out Gen Arzay) £s

b_i=

for I in Item'Ranc/e loop

Ztem It) :- _ni_ Val;

end /,cop;

end Gen .Cleat;

Note that the last transformation allows the user to supply

an initial value, but also provides the Ioweat value of the

component type as a cisfaulL An additional refinement would be

to make the. component type private whicJt would mean that

Init Val could not have a default value, information

dependencies such as the,one illustrated here are han:ler to

detect than compilation dependencies. The _ppewance of

literal values in a resource is often an indication of an

info_ dependence.

A _ form of d_0anaanca, _ pro_o_ dm)endence, has

also besn idan_ed. This occum wlwn tml user of a resourco

must obey certain rules Io ensure that the resource behaves

l:_'operty. For example, a Stack wtticn is used to buffer

information between offief uxn; could be iml_tmented in a

" not-so-abslract fashion by exposing the sta_ an'W and top

pointer directly. In this case. all users of the stack must

follow the same pmtocot of daorememthg the pointer before

popping and incrament_ after pushing, and not me othw way

='ound. Beyond me recognition of it, 110 addllioOal treatment

of this form of d_oendenca, between components will al pear in

this study.

,C-Ol'mnliTin_ the Tmnsfmmaflons

The following is a formalization of the objectives of

transformations which are needed lo remove declaration

I. Let P represent a program unit.

2. Lot D represent the set of n object dec_lrelions, dt .. d_,

directly referenced by P such _at cli is of a type decJared

externally Io P.

3. Let O1 - On be sets o! operelions where C_ is the set of

operations al_lled to _k inside P.

4. P is comp4etely transfoexna01e if earl1 operation in eactt of

_e sels, 01 .. On can be reDlaced with a preaetined or genenc

formal operation.

The earlier example transformallon is reviewed in the

context of these definitions:

I. Let P represent a program unit.

P = procedure Clear (Item : out Art.Item_Array) is ..

2. Let 0 represent the set of n object declarations, dl .. dn,

referenced by P suc_ that dq is o! a type declan_l

exlemally to P.

O = ( _Vr.lU__._._ l

3. L_ O1 .. On be sets ot operations where C_ is the set of

operalions applied to _ inside P.

{ indexing by integers, integer assignment to components )

4. P is completely transform-hie if eanh operation in ea_ of

the sea. O_. 0, can be redlac_ with a predefined or generio

formal operation.

Indexing can be obtained through a genen¢ formal array

type. Ntttougll no constraining operation was used, the formal

type could be either constrained or unconstrained since the

only declared object is a formal sul:q:,rngram parameter.

Since _oml_nem assignment is required, the component type

must not be llmilacL Therefore. the following generic formal

parts =re possible:

type Componen_ i= range <>;

type Index is range <>:

followed by either.

type Gen_Array is array (Index) of Component:

or:

r.yp@ _n Array £=

array (Index range <>) of Component..;

Notice that some operations can be replaced _th generic

formal operations more easily than others. For example,

direct access of array structures can generally be re_sce¢l by

making the array type a genetic formal type. However, direct

access into record structures (using "dot" notation)

complicates transformations since this operation must be

replaced w_th a user-definecl access function.

_.nolic_tion [g Exfema/ Snftwam

M_di.m.SJzL=d P mie_'t s

To test the feasibility of the transformations proposed, a

6.000-1inn Ada program written by seven professional

programmers was examined for reuse transformation

possibilities. The program consisted of six library units.

ranging in size from 20 to 2,400 lines. Of the 30

theoretm..ally possible dependencies thai could exist among

these units, ten were required. Four transformations of the

son described above were made to three of the units. These

required an additional 4.4 lines of code (less Ihan a I%

increase) and reduced the numOer ol depen0encies from ten to

five, w_k::h is tl_e minimum possible with six units. Using one

possible program change definition, each transformation

required between two and six chan<jes.

8th Annual National Conference on Aria Technology 1990

6109

5-31
A film modification was made to detach a nasmd unit hem

its patent° This required the addition of 15 lines and resulted

in a tolal of seven units with the minimum six dedandencies.

Next. two other functions were made indepandant el the other

units. Unlike Ule previous trlnaforrrMItion$ which were

targeted for later reuse, however, these tronsiormetions

resulted in a net reduction in code since the resulting

components were reused at multiple points within this

program. Sui_tantial i_ dependency whfo_ would

haw impaired actual reuse was idantifl4d _ remained within

the units, however.

A second medium-sized prolent was studied which

exhibited su_ a high degree of mutual dependence between

pairs of library units that. instead of s_ec_ng smaller units

for generalizations, the question of non-fllerarchicat

dependence was studied at a system level. The ganeral

conclusion from this waS that loops in the dedendency

smcture (where, for example, package A is reiemnced from

pac_ge budy 8 and padwps B Is reMrenced from I=ackage body

A) make gane_ of those components difflcu#. The

program vnm instead analyzed for pomd_e restrue_ring to

remove as much of me _-d_m:_enal do_ as pmc_c_.

This was partially succass_l and suggests that this sort of

redesign might al_ly _ other reuse analyses.

T_A NASA Pmktctl

Currently. the resewch project is examining several

macecmn nk_ simuJaden progranm fmm me NASA Gnddam

Spacl Flight Center. These pcogtrams are earl more than

I00,000 editor tlnes of AdL They 111ve been davMoped by an

organization that originally davek)ped such simulators in

Fortran and has been lrenaltiening to the uSe of Ads over the

past several years. 8ecsu_ all the programs are in me same

appiicxtion domain and were davt;toped by the same

organization there is considerable opport1_ity for reuse. In

me past, the davelo_nsm orgamzation reported the sillily to

reuse at)out 20% of earlier programs vmen a new program

was being davefo_d in Foman. However, since becoming

familiar with Ad&, the same organization is now reporting a

70% reuse rate, or better.

Afler gaining an understanding of the nalum of the reuse

accomplished in Fortran and later in Ads. and flow similar or

0ilferent muse in the two languages was, we would like to test

several mantles aleut _ the Ada reuse has been so muc_

greater. We already know that the reuse is accomplished by

modifying amller components as n_ and not._ general.

by using existing software vematim. 8ecause of this reuse

mode, one meory we v_l be tasting is that the Ada programs

are more reusaDle simply because they are more

understande0io.

For the currant study, the programs were studied to

reveal opportunities to extracl generic components whiclt, had

they been avadaOle when the programs were being devalo_

originally, could .ave been reused without mo_ilfoaticn.

There is an additional advantage to working with this data.

however, since, as mentioned above, the several programs

already exhibit significant functional similarities which can

be studied for possible generalization. In other words.

whereas the inilial discussion of generic extraction has

focussed on atiempts to commtsly free the essential function

of a componem from its static declaration context, this data

gNas examples of similar _ents in two o¢ more different

program ¢ofltlxtS and therefore allows us to study the

poaslbillW of h'eelng a component from only its programspeclfk: context and not from any context which remains

constant acrosa programs.

This gives rise to N notion of domain-spsclfic generic

extraction as opposed to domain-independent generic

extracUon. Given the pmbtemu aasoOated with extra_ng s

comp_tely general component, as examined exr,er, a case can

be made to generalize away only some of the dependence,

leaving the rest in place. The additional problem, then,

becomes how to determine wh_ cispsndlmce is permiss_le and

what s_ouio be removed. The pwmisoibio dependence weuld be

common _ projects in s certain domain, and would

therefore be domain-specific while the dependance to be

removed would be the problem.specific context. When

reused, then, these comps¢_ents wsuld have their problemspecific context supplied as genetic _ parameuws.

This is corren_y a largely manual task, since the

programs must be compared to find corresponding

hmc_onaiily and then examined to detsnnine the intersection

of that fun¢:ffi_nalily. Intere_blgly, on the last project the

developers themselves have also been devising generic

compsrmnts which are inatantiated only one time within that

ixogram. This Im_isd to us N some erich was being spent

to make co_ whlc_1 might be reuseDie with no. or

pe_ only very little, _ in the next l_'OjeC_. We

have confirmed with the devaiopenl that this is in fact the case.

By comparing the results of our generalizaUons with those

done by the developers, we find that ours have much more

complex generic parts but correspondingly much less

dependance on other soflwlm. This is a ressonabio result.

since the _ alroedy have some idea about the comext

for sect1 reuse Of a giverl gelleh_ what aspects of U1W context

are likely to change from _ to ptojec¢ and what aspects

are expected to remain conatsm across several programs. The

pmQram-spec-"ific context, only, alX)eers in the genetic pans

of the generics written by the developers, while our

gen_tiona have generic parls whk_ contain declaratmns

of types and opsrations which apparently do not nescl to che_e

as long as the pm_em domain remains the same. In other

words, when our generic parts are dev_ed by analyzing only a

single instance of a component, w_l cannel distinguish 10e_veen

program-spsOfic and domain-specsflc generalizaticns.

One interesting quenlion we would like to answer is

whether we can dedve the generic part that makes me most

sense within this domain by companng similar components

from different programs and generailzing only on their

differences, leaving the software in the intersection of the

components unchanged. In this way, a component would be

derived which would not be completely independent but. like

the developer-written generics, would be sufficiently

independent for reuse in the domain. Then, a coml=mnson w(th

the generics developed within the or(anization would be

revealing. If the generics are similar men our process rnKJht

be useful on other parts of the softwq,'e _al have not yet been

generalized by the developers. However, if they differ

greatly, it would be useful to characterize that difference and

8trt Annual National Conference on Ads Tect_nology 1990

5-3R

6109

ORIGINAL PAGE "S

OF POOR QUALITY
understand what additional knowledge must be used in

generalizing the repeated softwm'a. Unfortunately. there is

not enough reuse el the developer's generics yet to make mis

final comparison but a project is currently in progress which

shoutd supply some of mis data.

The following exampte Iguatrates the complexity of the

generic pans whP_ were required to complem_y /solata a

typical unit from its context. Here. the procedure

Check Header was removed from a package body and

generalized to be able to stand alone as a librew level generic

procedure.

generic

type Time is p=ivane;

_ype duration is dlqi_s <>-

with function Enable re_urn Sooleen;

_ylpe Hd._Rec ¢lq:m iS private;

with p_:otedure Set S_aL_c

(H : in out Hd_Rec Type; To : Duration);

with function Ge__$_aE_

(H : Hd Re¢ Type) re_urn Durationwith procedure Set_Stop

(H : in OU_ Hd ReC Type: TO : 0ure_ion);

with function Ge_ S_Op

(H : Hd?.e¢ Tylpet retuc'n Duration:

type Reel is digits O:

with funo_ion Ge_ At_ Int

(H : Hd Re¢ ¢lqpe) retu¢'n Real:

with run, ion CenT_Time

(D_F1olt : DuEitlont Ee_urn 0uEatlon:

_eeder.__e¢ : _,, out 8d...Rec_Tyt:m:

Goesim TJ.me SPep : in oul_ Duration;

with furor:ion Seconda_Sknce 1957

(T : £n TtJm) ¢ltu=n Duration;

wi_n procedurt Debug Write (Output : String);

with pro=edure OebuqEndL£ne:

type Direcu_rile Type Ls 1Lmited private;

with procedure DirecU Reed

(rile : Direct File Typel ;

with procedure Direc_ Ge_

(File : in OiEe¢_ File T1rpe:

Zt-- : out Hd..Rec...?Yl_t :

with function Imam_Of_Base_L0

(Z_ell : Ou£at:ion) rntl.tEn String;

with procedure Header Oata_Ztror:

procedure Check HeacLerGene¢i¢

(Simulation apart Time : in TtJml:

SLmuiarion_Stop_TJJne : in Time:

Simulation Time S_ep : in Duration:

Histo_y_F£1e : Ln out Direct_File_Type);

The inslantiatJon of this gene_c pan is corresponOJnQly

complex:

procedure Check Hea_er_1nstance is nay

CheckHeaderGeneric

(AJ_st ra¢_ Calendar. Time,

A_st_act Calendar.Duration,

DeOuq ;'naDle,

AC C i t udeHis t 0 ry_Typ_s. Heade £_Reco c_,

Set Start,

Get_S_art,

Set Stop,

Get_Stop,

Utilitie_ .Read,

Get AtE HiSt Out _nt,

Con ve rced Time,

HistoryData. HeaVe r_Rec,

_istory Date .Goes_m Time Step,

Timer. Seconda_Since _9 5 7,

Error Collec_or. Write,

£r¢or Collector. En_ Line,

Oi¢'ec¢ _Zo. File_Type,

Direct H.%xec__Zo. Read,

Gec_r_o_ euf_e_,

_e_o__aese__ o,

Raise__el¢_¢..Data_£r rot ! ;

In contrast, a rypic_ gane_c part on a unit wt_iCtl was

developed and delivered as _ of the most recent completea

project by the developers themselves is shown here:

with C=s_T1_es;

generic

Hum_er O£_S_naors : Natural :-

Cas_Types. Nu=ber_Ot" Sen-o r= ;

vir21 function Initialize_Sensor

return Css_Typ_s.C_s Database Type iS <>;

packaq_ Generic_Coarse Sun Sensor ia

Note that by allowing the visibility of Css Types, the

generic part was simplified. Being unfamiliar with the

domain, had we mten_med to generaJize Coarse_Sun. Sensor by

examining only the non-generic version of a corresponding

comgonent in _ottmr program we would r_o!be able _o tell

w,eUter the dependence on Css 1"y_s was gtogram-epecific

or domaJn-Sl:_K:_ Here. however, the deve_o0er lea_s us to

be_eve that Css l"ypas is damam-speaflc while the number

of sensors and sensor inflt_dlzatk)n is program specific.

The manual al_ication el (he i_nnciples anO techmques of

generic transformation and extraction rtas revealed several

interesting and intuitively reasona01e _uidelines relative to

the creation and reuse of Ada software, in general. 1hese

guidelines appear to be a._li_lble to programs of any size.

However, the last guideline in (he list, concerning program

structure, was 1he most obrviouS when dealing with medium IO

large programs.

• Avoid direct access into record components except in {he

same declarative rogion as the record type declaration.

Since there is no generic _ormai record type in Aria

(without dynamic binding such a feature would be

imDracttcal) t_ere is no straig.ttorwarO way to replace

record component access w_th S gene_c operation. Instead.

user-supplied access functions are needed lo access the

components and the type must be passeO as a private type.

This is unlike array types for w.ich mere are two generic

formal types (constrained and unconstrained). This SUDporls

tile tindiogs Of others which asBarl (hat dJrec_ reterencmg of

non-local recora components a_versely al/ects maintainaOility

{61

• Minimize non-local access to array components.

Although not as difficult in general as removing deoenclence

6109

OF PC:K_ ":'. ,",

8th Annual National Conference on Aria Technology 1990

5-33
on a record type, removing _ndonc_ on an uray type can be

cumtx_,_ome.

• Keep direr access to data structures local to Iheir

daclem_ns.

This is e s_ronger conduskm than the previous two,

minfomas the I_t_ of _ _ dam types in _1

situations wbem a dam type is _ outside Its

bec_araUve region. Encapsulated types, ate far easier to

separate as renou,'cu thin gk_ de(dared types since the

oderatioes am localized and _.

• Avoid N use of III_,;U values except as constant value

assignments.

Infonnabon dependence is almost always asso_amd wire

the use of a literal vaJue in one unit of software mat has some

hiddsfl relatioclsfl_] to a Ilterai _ in a different untL If a

unit is generalized and extracted /or reuse but contains a

literal value which kxkatos a dependence on some aasun_lion

a0aut its odglnai ¢omaxt. _ unR can fail in unpredictable

ways when reused. Conventional vdsc:iorn aGp_as here. and it

migm be muon/:]le to relax me restriction to a//ow me use ot

0 am_l I. Ho_, eXlPe_ence with a _ =mount of

software wl_ makes the erroneous as_ m-, me first

index o4 any string iS 1 has shown that even this can lead to

problems.

• Avoid mingling resources w_th am specific contexts.

Although the purpose of me vans_rmations is to separate

_noumas from al_ specificsoflvn=rer_ of the

program structure, certa_ sWles of programming resultin

programs which can be transformed more easily and

completely. By staying cons_ous of the ultimate goal of

separating reusable function from al_iio_ton declarations.

whether or not the functionality is initially programmed to be

generic, programmers can simplify the eventual

• ansfonnatton of the code.

• K_ interfaces

Protocol dOlPenderlc_s arise from the exportation el

implementation detailS that should not be present in the

interface to a resource. Such an interface is vulnerable

because it _ a ulage i;xotoc01 wNctl does not have to be

follo_md by its _ The I_d stack exempts illustrates what

can hm_=en ,men a rasoume imm re¢lukes the use el

implementation detads, however even resources w,th an

appropriately abstract interface can export unwanted

addftion_ detail wflioh can kind to Im01o_ot d_.

• Avoid d_rm_ refm to package Stendan_Float

Even when used to define other fioatln_ point types, direct

reference to Float estat)_s_es an trn_ementatlen dependence

mat does not occur w(th anonymous floattn_ paint declarations.

Especially dangerous is a dJrecl relerence 1o

Standard.Long_Float. Standard.Long_Integer. etc.. since they

may not even compile on different implementations. Some

care must also be taken with Integer. Positive. and Natural.

though in generaJ they were not associated w_th as much

dependence as Float. Note mat fixed point types in Ada are

constructed as needed by the compiler. Perhaps the same

Phitosol_ should have been aciogted for Ftoat and Inmger.

RMerence to Character and Bookmn is not a pmOiom sure they

ate me same on all implernentalk)ns.

• Avoid the use of 'Address

Evert though it is not necessary to be in the scope of

package System to use this amg)ute, it sats up a dependency

on Syatem.Acldreas that makes me soLlw_re non.portable. If

this attribute is needad for some low-level pro_rmmming than

it sl_ould be enc_psul_m_ and never be exposed in the interface

to that level.

• Consider me imer-oomponem dependenc_ of a design

By understandlng how funchonaily-equivalent programs

can vary in their de, me of Intar-component <dependence.

designers and deve_ode_ can make deciskms about tow much

dependence will be permitted in an evolving system, and

much effort will be applied tO limit that dependence. For

system developments which am expe_ tO yield reusaDle

components d_'s_ly, a _ _ be made m minimize

_ _mm tr_ outs_. Fo_ devetopments whk:n am not

able to make such an invesmtam in mumbiaty, a decision can

be made tO _IOW _ Idnds Of cispendenaes tO Occur. In

partioular, dependen_Hes which are removable through

st,tl_t tf_rtlllfermation might be aliow_d while those that

wouk:l be too dfficolt to remove later mlgm be avoided. A

particula_ cumlx.'somo type of dependence occurs when _o

library units reference each other, either directly or

indirect. This should be avoided if al all possible. By

making structural decisions explicitly, surprises can be

avoided whi¢_ mk_lt othe/_i_l m'suJt /n unwanted limitations

of the deveio_ software.

This work was supported in par/ by the U.S. Army

tnstitute for Research in Management Information and

Computer Science under gram AIRMICS-01-4-33267, and

NASA under grant NSG-5123. Some of the set, are analysis

was per/re'meal u_ng a Rational com¢,uler at Rafional's eastern

regional office in Ca/vermn, Maryland.

B_aamras

1. Oasili, V. R. and Roml_v.J1. H. D. Sotlwam Reuse: A

Framework. In preparation.

2. Oasgl, V. R. and Roml_w,_. H. O. The TAME Proiect:

Towards Improvement- Oriented Software Environments.

It=_F Transactions on Sofl'w_re _noineeqn_ SE-14. June

t988.

3 Funk & Wagnafls. Standard Collie Oictionarv. New York.

1977.

4. Mye_J, G. Composite/Structured D_sinn. Van Nostrand

Reinhok:l, New York, t978.

8th AnnuaJ Natmna_ Conference on Ada Technology 1990

6109

5-34
5. Dunsmora, H.E. and Gannon, J.D.

Investigation of Programming Comglexity.

ACMINB_ 16th Ann,_l Tact1. Symposium:

So_vam. Washington D.C., June 1977.

Experimental

In Proc_edinqs

Systems and

6. Gannon, J.O.o Kalz, E. and Ba_li, V.R. Characterizir_ Ada

Programs: Penes. In Proce_llrm,= Workshon on Sof'twar(I

Performance. Los Alamos National Laboratory, Los Alamos,

New Mexico, August 1983.

John W. Bailey is a Ph.D, candidate at the University of

Maryland Computer Science OeOlulment; He is a part-time

_ee of Rational and hal been consulting and teactting in

fife ainu of Add and sO_qlm mesIoremem for seven years. In

addition to Add and soflwsre reuse, his interests include

mu_¢, pttotogral_y, mOlOCcyc/ing and home SUl:_Dort Bailey

received his M.S. in ¢olnpullM =l¢_m:e from the University of

Maryland. where he also earned b_ichelor's and master's

deqmes in cello perfomtlce, He is a meml_tr of me ACM.

Victor R. Basdi is a _ofessor ;I the University of MarylanO.

College Park's Institute for Advanced ComDuter S_uOies and

Comguter Scienca Oet_w_nent. His raseamtt interests inc_ucle

measuring and evaluatlng so_Im development. He is a

founder and i_'inaOal of the Sohwero Engineennq La_oralo_.

which is a joint vemum among NASA. the University of

Ms_t'iand and Computer Scmn¢_l Corporation. Basili race.dad

his B.S. in marnernatics from Fordham College. %n MS. in

mathematics from Syracuse University and a Ph.O. _n

computer science from Itm universily of Texas at Austin. He _s

a fellow of the _e IEEE Computer SooeW and is editor-_nctlief of IEEE Transactions on Softwm'e Ena=neenna.

ORIGINAL PAGE IS

OF POOR QUALITy

8th Annual National Conference on Aria Technology 1990

6109

5-35

,:-,...... :7.7Z :: :c

.=-

STAN_DBIBLIOGRAP_

LITERATURE _ ___

--_____-___ _ ....

__

--__ _ - ____ _

._ii]

-2 2 2!Z_--_ ........._

___ - L;:

"- - 112:

..... ... = -._-- ......... ....

_c"

..... _2 __ --

STANDARD BIBLIOGRAPHY OF SEL LITERATURE

The technical papers, memorandums, and documents listed in

this bibliography are organized into two groups. The first

group is composed of documents issued by the Software Engineering Laboratory (SEL) during its research and development

activities. The second group includes materials that were

published elsewhere but pertain to SEL activities.

SEL-ORIGIRATED DOCUMEHTS

SEL-76-001, PrQceedinas From the First Summer Software Enuineerina Workshop, August 1976

SEL-77-002, Proceedinus From the Second Summer Software Engineerinq Workshop, September 1977

SEL-77-004, A Demonstration of AXES for NAVPAK, M. Hamilton

and S. Zeldin, September 1977

SEL-77-005, GSFC NAVPAK Desiqn Specifications Lanauaues

Study, P. A. Scheffer and C. E. Velez, October 1977

SEL-78-005, Proceedinus From the Third Summer Software Enqineerinq Workshop, September 1978

SEL-78-006, GSFC $0f_w_re Enqineerinq Research Reuuirements

Analysis Study, P. A. Scheffer and C. E. Velez, November 1978

SEL-78-007, ADDlicabilitY of the RaYleiqh Curve to the SEL

Environment, T. E. Mapp, December 1978

SEL-78-302, FORTRAN Static Source ¢ode Analyzer Prouram (SAP)

User's Guide (Revision 3), W. J. Decker and W. A. Taylor,

July 1986

SEL-79-002, The Software Enqine@rinq Laboratory: Relationship Equations, K. Freburger and V. R. Basili, May 1979

SEL-79-003, Common Software Module Repository (CSMR) System

Description %nd User's Guide, C. E. Goorevich, A. L. Green,

and S. R. Waligora, August 1979

SEL-79-004, Ev@luation of the Caine. Farber. and Gordon Program Desiqn Lanuuaue (PDL) in the Goddard Space Fliuht Center

(GSFC) Code 580 Software Desian Environment, C. E. Goorevich,

A. L. Green, and W. J. Decker, September 1979

6109

B-I
SEL-79-005, Proceedinas From the Fourth Summer Software Enuineerinq Workshoo, November 1979

SEL-80-002, Multi-Level Expression Desiun LanauaueReuuirement Level (MEDL-R) System Evaluation, W. J. Decker

and C. E. Goorevich, May 1980

SEL-80-003, Multimission Modular Spacecraft Ground SUDDort

Software System (MMS/GSSS) State-of-the-Art Computer Systems/

Compatibility Study, T. Welden, M. McClellan, and

P. Liebertz, May 1980

SEL-80-005, A Study of the Musa Reliability Model,

A. M. Miller, November 1980

SEL-80-006, Proceedinus From the Fifth Annual Software Enuin%erinu Workshop, November 1980

SEL-80-007, An ADDraisal of $@lected Cost/Resource Estimation

Models for Software Systems, J. F. Cook and F. E. McGarry,

December 1980

SEL-80-008, Tutorial on Models and Metrics for Software

Manaqement and Enuineerinu, V. R. Basili, 1980

SEL-81-008, Cost and Reliability Estimation Models (CAREM)

User's Guide, J. F. Cook and E. Edwards, February 1981

SEL-81-009, Software Enaineerinu Laboratory Prourammer Workbench Phase 1 Evaluation, W. J. Decker and F. E. McGarry,

March 1981

SEL-81-011, Evalu_tinq Software Development by Analysis of

¢hanue Data, D. M. Weiss, November 1981

SEL-81-012, The Rayleiqh Curve as a Model for Effort Distribution Over the Life of Medium Scale Software Systems,

G. O. Picasso, December 1981

SEL-81-013, Proceedinqs From the Sixth Annual Software Enqine@rinq Workshop, December 1981

SEL-81-014, A_tomated C011ection of Software Enaineering Data

in the Software Enaineerina Laboratory (SEL), A. L. Green,

W. J. Decker, and F. E. McGarry, September 1981

SEL-81-101, Guide to Data Collection, V. E. Church,

D. N. Card, F. E. McGarry, et al., August 1982

SEL-81-104, Th_ Software Enqineerina Laboratory, D. N. Card,

F. E. McGarry, G. Page, et al., February 1982

6109

B-2
SEL-81-107, Software Enuineerinu Laboratory (SEL) Compendium

of Tools, W. J. Decker, W. A. Taylor, and E. J. Smith,

February 1982

SEL-81-110, Ev%luatiQn of an IndeD@n_ent Verification and

validation (iv&v) Methodolouy for Fliuht Dynamics, G. Page_

F. E. McGarry, and D. N. Card, June 1985

SEL-81-205, Recommended Approach to Software Development,

F. E. McGarry, G. Page, S. Eslinger, et al., April 1983

SEL-82-001, Evalqati0n of Management Measures of Software

Development, G. Page, D. N. Card, and F. E. McGarry,

September 1982, vols. 1 and 2

SEL-82-004, Collected Software Enuineerinu Papers:

ume i, July 1982

VolSEL-82-007, Proceedinus From the Seventh Annual Softwar@

Enuineerinu Workshop, December 1982

SEL-82-008, Evaluatinu Software Dev@lopment by Analysis of

Chanues: The Data From the Software Enuineerinu Laboratory,

V. R. Basili and D. M. Weiss, December 1982

SEL-82-102, FORTRAN Static Source Code Analyz@r Program

(SAP) System Description (R@vision i), W. A. Taylor and

W. J. Decker, April 1985

SEL-82-I05, Glossary of Software Enqineering Laboratory

Terms, T. A. Babst, F. E. McGarry, and M. G. Rohleder,

October 1983

SEL-82-906, Annotated BibliouraDhv of Software Engineering

Laboratory Literat_r@, P. Groves and J. Valett, November 1990

SEL-83-001, An Approach to Software Cost Estimation,

F. E. McGarry, G. Page, D. N. Card, et al., February 1984

SEL-83-002, Measures and Metric_ for Software Development,

D. N. Card, F. E. McGarry, G. Page, et al., March 1984

SEL-83-003, Collected $oftwar_ Engineering Papers:

ume II, November 1983

VolSEL-83-006, Monitorinu Software Development Through Dynamic

Variables, C. W. Doerflinger, November 1983

SEL-83-I06, Monitoring Software Development Through Dynamic

Variables (Revision I), C. W. Doerflinger, November 1989

6109

B-3
SEL-83-007, Pr0ceedinas From the Eiahth Annual Software Enqineerina Workshoo, November 1983

SEL-84-101, Man_qer's Handbook for Software Development,

R@vision 1, L. Landis, F. McGarry, S. Waligora, et al.,

November 1990

SEL-84-003, Investiqation of Specification Measures for the

Software Enuineerinq Laboratory (SEL), W. W. Agresti,

V. E. Church, and F. E. McGarry, December 1984

SEL-84-004, Proceedings From the Ninth Annual Software Enaineerinq Workshop, November 1984

SEL-85-001, A Comparison of Software Verification Techniuues,

D. N. Card, R. W. Selby, Jr., F. E. McGarry, et al., April

1985

SEL-85-002, Ada Tr%_ninq Evaluation and Recommendations From

_h@ Gamma Ray Observatory Ada Development Team, R. Murphy

and M. Stark, October 1985

SEL-85-003, Collected Software Enaineerina Papers:

_me III, November 1985

VO iSEL-85-004, Evaluations of Software Technoloaies: Testinu,

CLEANROOMo and Metrics, R. W. Selby, Jr., May 1985

SEL-85-005, SOftwar@ V@rification and Testinu, D. N. Card,

C. Antle, and E. Edwards, December 1985

SEL-85-006, Proceedinqs From the Tenth Annual Software Enaineerinq Workshop, December 1985

SEL-86-001, PrQqramm@r'_ Handbook for Fliaht Dynamics Softwar@ DeveloPment, R. Wood and E. Edwards, March 1986

SEL-86-002, Gen@ral Obiect-Oriented Software Development,

E. Seidewitz and M. Stark, August 1986

SEL-86-003, Fliqht Dynamics System Software Development Environment Tutorial, J. Buell and P. Myers, July 1986

SEL-86-004, Collect@_ Software Enaineerina Papers:

um@ IV, November 1986

Vo ISEL-86-005, Measurina Software Desiun, D. N. Card, October

1986

SEL-86-006, Proceedinas From the Eleventh Annual Software

Engineerinq Workshop, December 1986

6109

B-4
SEL-87-001, product Assurance Policies and Procedures for

Fliaht Dynamics Software Development, S. Perry et al., March

1987

SEL-87-002, A4a Style Guide (Version i.I), E. Seidewitz

et al., May 1987

SEL-87-003, Guidelines for Applvinu the Composite Specification Model (CSM), W. W. Agresti, June 1987

SEL-87-004, ASSessing the Ada Desiqn Pr0¢ess and Its Implications: A Case Study, S. Godfrey, C. Brophy, et al.,

July 1987

SEL-87-008, Data Collection Procedures for the Rehosted SEL

Database, G. Heller, October 1987

SEL-87-009, Collected Software Enaineerinq Papers:

S. DeLong, November 1987

Volume V,

SEL-87-010, Pr0ceedinqs From the Twelfth Annual Software Enqineerinq Workshop, December 1987

SEL-88-001, System Testing of a Production Ada Proiect: The

GRODY Study, J. Seigle, L. Esker, and Y. Shi, November 1988

SEL-88-002, Collected Software Enuineerinu Papers:

ume VI, November 1988

Vo iSEL-88-003, Evolution of Ada Technolouv in the Fliqht Dynamiq_ Area: Design Phase Analysis, K. Quimby and L. Esker,

December 1988

SEL-88-004, Proceedinas of the Thirteenth Annual Software

Engineering Workshop, November 1988

SEL-88-005, Proceedinus of the First NASA Ada User's Symposium, December 1988

SEL-89-002, Implementation of a Production Ada Project;

GRODY Study, S. Godfrey and C. Brophy, September 1989

The

SEL-89-003, Software Management Environment (SME) Concepts

and Architecture, W. Decker and J. Valett, August 1989

SEL-89-004, Evolution of Ada Technolouv in the Flight Dynamics Area; Implementation/Testing Phase Analysis,

K. Quimby, L. Esker, L. Smith, M. Stark, and F. McGarry,

November 1989

6109

B-5
SEL-89-005, Lessons Learned in the Transition to Ada From

FORTRAN at NASA/Goddard, C. Brophy, November 1989

SEL-89-006, Collected Software Enqineerina Papers:

ume VII, November 1989

VolSEL-89-007, Proceedinus of the Fourteenth Annual Software

Enqineerina Workshop, November 1989

SEL-89-008, Pr0ceedinus of the Second NASA Ada Users' Symposium, November 1989

SEL-89-101, SOftware Enqineerinu Laboratory (SEL) Database

0rqanization and User's Guide (Revision 1), M. So, G. Heller,

S. Steinberg, K. Pumphrey, and D. Spiegel, February 1990

SEL-90-001, Database Access Manauer for the Software Enqineerina Laboratory (DAMSEL) User's Guide, M. Buhler and

K. Pumphrey, March 1990

SEL-90-002, The Cleanro0m Case Study in the Software Enqineerinu Laboratory: Project Description and Early Analysis,

S. Green et al., March 1990

SEL-90-003, A Study of the Portability of an Ada System in

the Software Enqineerinq Laboratory (SEL), L. O. Jun and

S. R. Valett, June 1990

SEL-90-004, Gamma Ray Observatory Dynamics Simulator in Ada

(GRODY) ExPeriment Summary, T. McDermott and M. Stark,

September 1990

SEL-90-005, Collected Software Enqineerinq Papers:

ume VIII, November 1990

Vo ISEL-RELATED LITERATURE

4Agresti, W. W., V. E. Church, D. N. Card, and P. L. Lo,

"Designing With Ada for Satellite Simulation: A Case Study,"

Proceedinqs of the First International Symposium on Ada for

the NASA Space Station, June 1986

2Agresti, W. W., F. E. McGarry, D. N. Card, et al., "Measuring Software Technology," Proaram Transformation and Proqramminq Environments. New York: Springer-Verlag, 1984

IBailey, J. W., and V. R. Basili, "A Meta-Model for Software Development Resource Expenditures," Proceedings of the

Fifth International Conference on Software Enqineerinq.

New York: IEEE Computer Society Press, 1981

6109

B-6
8Bailey, J. W., and V. R. Basili, "Software Reclamation:

Improving Post-Development Reusability," Proceedinus of the

Eighth Ann_al NatiQnal Cgnf_rence Qn Ada Technoloav,

March 1990

iBasili, V. R., "Models and Metrics for Software Management and Engineering," ASME Adv%nces in Computer Technoloav,

January 1980, vol. 1

Basili, V. R., Tutorial on Models and Metrics for SQftware

Management and Enaineering. New York: IEEE Computer Society

Press, 1980 (also designated SEL-80-008)

3Basili, V. R., "Quantitative Evaluation of Software Methodology," Proceedinus of the First Pan-Pacific Computer Conference, September 1985

7Basili, V. R., M_intenanc@ = Reuse-Oriented Software

Development, University of Maryland, Technical Report

TR-2244, May 1989

7Basili, V. R., Software D@v@!opment: A Paradium for the

Future, University of Maryland, Technical Report TR-2263,

June 1989

8Basili, V. R., "Viewing Maintenance as Reuse-Oriented

Software Development," IEEE Software, January 1990

1Basili, V. R., and J. Beane, "Can the Parr Curve Help With

Manpower Distribution and Resource Estimation Problems?,"

Journal of Systems and Software, February 1981, vol. 2, no. 1

iBasili, V. R., and K. Freburger, "Programming Measurement

and Estimation in the Software Engineering Laboratory,"

Journal of Systems and Software, February 1981, vol. 2, no. 1

3Basili, V. R., and N. M. Panlilio-Yap, "Finding Relationships Between Effort and Other Variables in the SEL,"

Proceedinas of the International Computer Software and Applications Conference, October 1985

4Basili, V. R., and D. Patnaik, A Study on Fault Prediction

and Reliability Assessment in the SEL Environment, University

of Maryland, Technical Report TR-1699, August 1986

2Basili, V. R., and B. T. Perricone, "Software Errors and

Complexity: An Empirical Investigation," Communications of

the ACM, January 1984, vol. 27, no. 1

6109

B-7
IBasili, V. R., and T. Phillips, "Evaluating and Comparing

Software Metrics in the Software Engineering Laboratory,"

Proceedinas of the ACM SIGMETRICS Symposium/Workshop: OualitY Metrics, March 1981

Basili, V, R., and J. Ramsey, _tructural Coveraqe of Functional Testinu, University of Maryland, Technical Report

TR-1442, September 1984

3Basili, V. R., and C. L. Ramsey, "ARROWSMITH-P--A Prototype Expert System for Software Engineering Management,"

Proqeedinas of the IEEE/MITRE ExPert Systems in Government

SYmposium, October 1985

Basili, V. R., and R. Reiter, "Evaluating Automatable Measures for Software Development," Proceedinas of the Workshop

on Ouantitative Software Models for ReliabilitY. Complexity.

aE_]___. New York: IEEE Computer Society Press, 1979

5Basili, V., and H. D. Rombach, "Tailoring the Software

Process to Project Goals and Environments," Proceedinas of

the 9th International Conference on Software Enaineerinq,

March 1987

5Basili, V., and H. D. Rombach, "T A M E: Tailoring an Ada

Measurement Environment," Proceedinas of the Joint Ada Conference, March 1987

5Basili, V., and H. D. Rombach, "T A M E: Integrating

Measurement Into Software Environments," University of

Maryland, Technical Report TR-1764, June 1987

6Basili, V. R., and H. D. Rombach, "The TAME Project:

Towards Improvement-Oriented Software Environments," IEEE

Transactions on Software Enaineerina, June 1988

7Basili, V. R., and H. D. Rombach, Towards A Comprehensive

Framework for Reuse: A Reuse-Enablinq Software Evolution

Environment, University of Maryland, Technical Report

TR-2158, December 1988

8Basili, V. R., and H. D. Rombach, Towards A Comprehensive

Fram@work for Reuse: Model-Based Reu$@ Characterization

_, University of Maryland, Technical Report TR-2446,

April 1990

2Basili, V. R., R. W. Selby, Jr., and T. Phillips, "Metric

Analysis and Data Validation Across FORTRAN Projects," !EEE

Transactions on Software Enqineerinq, November 1983

6109

B-8
3Basili, V. R., and R. W. Selby, Jr., "Calculation and Use

of an Environment's Characteristic Software Metric Set,"

Proceedinas of the Eiahth International Conference on Software Enqineerinq. New York: IEEE Computer Society Press, 1985

Basili, V. R., and R. W. Selby, Jr., ComDarinq the Effectiveness of Software Testinu Strateuies, University of Maryland,

Technical Report TR-1501, May 1985

3Basili, V. R., and R. W. Selby, Jr., "Four Applications of

a Software Data Collection and Analysis Methodology," Proceedinqs of the NAT0 Advanced Study Institute, August 1985

4Basili, V. R., R. W. Selby, Jr., and D. H. Hutchens, "Experimentation in Software Engineering," IEEE Transactions on

Software Enqineerina, July 1986

5Basili, V. and R. Selby, Jr., "Comparing the Effectiveness of Software Testing Strategies," IEEE Transactions on

Software Enqineerina, December 1987

2Basili, V. R., and D. M. Weiss, A Methodoloav for Collectina

Valid Software Enqineerina Data, University of Maryland,

Technical Report TR-1235, December 1982

3Basili, V. R., and D. M. Weiss, "A Methodology for Collecting Valid Software Engineering Data," IEEE Transactions on

Software Enqineerinu, November 1984

iBasili, V. R., and M. V. Zelkowitz, "The Software Engineering Laboratory: Objectives," Proceedinqs of the Fifteenth Annual Conference on Computer Personnel Research,

August 1977

Basili, V. R., and M. V. Zelkowitz, "Designing a Software

Measurement Experiment," Proceedinas of the Software Life

Cycle Manaqement Workshop, September 1977

IBasili, V. R., and M. V. Zelkowitz, "Operation of the Software Engineering Laboratory," Proceedinqs of the Second Software Lif_ Cycle Manaqement Workshop, August 1978

iBasili, V. R., and M. V. Zelkowitz, "Measuring Software

Development Characteristics in the Local Environment," _omputers and Structures, August 1978, vol. 10

Basili, V. R., and M. V. Zelkowitz, "Analyzing Medium Scale

Software Development," Pr0_eedinas of the Third International Confer_n_ on Software Enqineerina. New York: IEEE

Computer Society Press, 1978

6109

B-9
5Brophy, C., W. Agresti, and V. Basili, "Lessons Learned

in Use of Ada-Oriented Design Methods," Proceedinus of the

Joint Ada Conference, March 1987

6Brophy, C. E., S. Godfrey, W. W. Agresti, and V. R. Basili,

"Lessons Learned in the Implementation Phase of a Large Ada

Project," Proceedinas of the Washinuton Ada Technical Conference, March 1988

2Card, D. N., "Early Estimation of Resource Expenditures and

Program Size," Computer Sciences Corporation, Technical Memorandum, June 1982

2Card, D. N., "Comparison of Regression Modeling Techniques

for Resource Estimation," Computer Sciences Corporation,

Technical Memorandum, November 1982

3Card, D. N., "A Software Technology Evaluation Program,"

Annais do XVIII Conqresso Nacional de Informatica,

October 1985

5Card, D., and W. Agresti, "Resolving the Software Science

Anomaly," The Journal of Systems and Software, 1987

6Card, D. N., and W. Agresti, "Measuring Software Design

Complexity," The Journal of Systems and Software, June 1988

Card, D. N., V. E. Church, W. W. Agresti, and Q. L. Jordan,

"A Software Engineering View of Flight Dynamics Analysis

System," Parts I and II, Computer Sciences Corporation,

Technical Memorandum, February 1984

4Card, D. N., V. E. Church, and W. W. Agresti, "An Empirical

Study of Software Design Practices," IEEE Transactions on

Software Enqineerinu, February 1986

Card, D. N., Q. L. Jordan, and V. E. Church, "Characteristics of FORTRAN Modules," Computer Sciences Corporation,

Technical Memorandum, June 1984

5Card, D., F. McGarry, and G. Page, "Evaluating Software

Engineering Technologies," IEEE Transactions on Software

Enqineerinq, July 1987

3Card, D. N., G. T. Page, and F. E. McGarry, "Criteria for

Software Modularization," Proceedinas of the Eiqhth International Conference on Software Enqineerinq. New York: IEEE

Computer Society Press, 1985

6109

B-10
iChen, E., and M. V. Zelkowitz, "Use of Cluster Analysis To

Evaluate Software Engineering Methodologies," Proceedinus of

the Fifth International Conference on Software Enaineerina.

New York: IEEE Computer Society Press, 1981

4Church, V. E., D. N. Card, W. W. Agresti, and Q. L. Jordan,

"An Approach for Assessing Software Prototypes," ACM software

Enqineerinu Notes, July 1986

2Doerflinger, C. W., and V. R. Basili, "Monitoring Software

Development Through Dynamic Variables," Proceedinas of the

Seventh International Computer Software and ADolications

Conference. New York: IEEE Computer Society Press, 1983

5Doubleday, D., ASAP; An Ada Static Source Cod@ Analyzer

Program, University of Maryland, Technical Report TR-1895,

August 1987 (NOTE: i00 pages long)

6Godfrey, S., and C. Brophy, "Experiences in the Implementation of a Large Ada Project," Proceedinus of the 1988

Washington Ada Svmoosium, June 1988

Hamilton, M., and S. Zeldin, A Demonstration of AXES for

NAVPAK, Higher Order Software, Inc., TR-9, September 1977

(also designated SEL-77-005)

Jeffery, D. R., and V. Basili, Characterizinu Resource Data:

A Model for Louical Association of Software Data, University

of Maryland, Technical Report TR-1848, May 1987

6jeffery, D. R., and V. R. Basili, "Validating the TAME Resource Data Model," Proceedinus of th_ T_nth International

Conference on Software Enuineerinq, April 1988

5Mark, L., and H. D. Rombach, A Meta Information Base for

Software Enaineerinq, University of Maryland, Technical Report TR-1765, July 1987

6Mark, L., and H. D. Rombach, "Generating Customized Software

Engineering Information Bases From Software Process and Product Specifications," Proceedinas of th_ 22nd Annu_l Hawaii

International Conference on System sciences, January 1989

5McGarry, F., and W. Agresti, "Measuring Ada for Software

Development in the Software Engineering Laboratory (SEL),"

Proceedinus of th_ 21St Annual Hawaii International Conference on System Sciences, January 1988

7McGarry, F., L. Esker, and K. Quimby, "Evolution of Ada

Technology in a Production Software Environment," Proceedings

of the Sixth Washinqton Ada Symposium (WADAS), June 1989

6109

B-II
3McGarry, F. E., J. Valett, and D. Hall, "Measuring the

Impact of Computer Resource Quality on the Software Development Process and Product," ?roceedinus of the Hawaiian International Conference on System Sciences, January 1985

National Aeronautics and Space Administration (NASA), NASA

Software Research Technolouv Workshop (Proceedings), March

1980

3page, G., F. E. McGarry, and D. N. Card, "A Practical Experience With Independent Verification and Validation,"

Proceedinqs of the Eiuhth International Computer Software

and Applications Conference, November 1984

5Ramsey, C., and V. R. Basili, A_ Ev%luation of ExPert Systems for Software Enqineerina Manaqement, University of

Maryland, Technical Report TR-1708, September 1986

3Ramsey, J., and V. R. Basili, "Analyzing the Test Process

Using Structural Coverage," Proceedinas of the Eiahth International Conference on Software Enqineerinu. New York:

IEEE Computer Society Press, 1985

5Rombach, H. D., "A Controlled Experiment on the Impact of

Software Structure on Maintainability," IEEE Transactions on

Software Enqineerina, March 1987

8Rombach, H. D., "Design Measurement:

IEEE Software, March 1990

Some Lessons Learned,"

6Rombach, H. D., and V. R. Basili, "Quantitative Assessment

of Maintenance: An Industrial Case Study," Proceedinus From

the Conference on Software Maintenance, September 1987

6Rombach, H. D., and L. Mark, "Software Process and Product Specifications: A Basis for Generating Customized SE

Information Bases," Proceedinas of the 22nd Annual Hawaii

International Conference on System Sciences, January 1989

7Rombach, H. D., and B. T. Ulery, E_tablishinu a Measurement Based Maintenance Improvement Prouram: Lessons Learned

in th_ SEL, University of Maryland, Technical Report

TR-2252, May 1989

5Seidewitz, E., "General Object-Oriented Software Development: Background and Experience," Proceedinus of the 21st

Hawaii Int@rnational Confgrence on System Sciences, January

1988

6Seidewitz, E., "General Object-Oriented Software Development with Ada: A Life Cycle Approach," Proq@edings of the

CASE Technology Conference, April 1988

6109

B-12
6Seidewitz, E., "Object-Oriented Programming in Smalltalk

and Ada," Proceedinas of th@ 1987 Conference on ObiectOriented Proarammina Systems, Lanuuaaeso and ApPlications,

October 1987

4Seidewitz, E., and M. Stark, "Towards a General ObjectOriented Software Development Methodology," Proceedinus of

th_ First International Symposium on Ada for the NASA Space

Station, June 1986

8Stark, M., "On Designing Parametrized Systems Using Ada,"

Proceedinqs of the Seventh Washinqton Ada Symposium,

June 1990

7Stark, M. E. and E. W. Booth, "Using Ada to Maximize

Verbatim Software Reuse," Proceedinas of TRI-Ada 1989,

October 1989

Stark, M., and E. Seidewitz, "Towards a General ObjectOriented Ada Lifecycle," Proceedings of the Joint A_a Conference, March 1987

8Straub, P. A., and M. Zelkowitz, "PUC: A Functional

Specification Language for Ada," Proc_edinq_ of the Tenth

International Conference of the Chilean Computer Science

Society, July 1990

7Sunazuka, T., and V. R. Basili, Inteuratina Automated Support for a Software Manauem_nt Cycle Into the TAME System,

University of Maryland, Technical Report TR-2289, July 1989

Turner, C., and G. Caron, A Comparison of RADC and NASA/SEL

Software Devel0pm_nt Data, Data and Analysis Center for

Software, Special Publication, May 1981

Turner, C., G. Caron, and G. Brement, NASA/SEL Data Compendium, Data and Analysis Center for Software, Special Publication, April 1981

5Valett, J., and F. McGarry, "A Summary of Software Measurement Experiences in the Software Engineering Laboratory,"

Proceedinus of the 21st Annual Hawaii International Conference on System Science_, January 1988

3Weiss, D. M., and V. R. Basili, "Evaluating Software Development by Analysis of Changes: Some Data From the Software Engineering Laboratory," IEEE Transactions on Software

Enqineerinq, February 1985

6109

B-13
5Wu, L., V. Basili, and K. Reed, "A Structure Coverage Tool

for Ada Software Systems," Proceedinas of the Joint Ada Conference, March 1987

iZelkowitz, M. V., "Resource Estimation for Medium Scale

Software Projects," Proceedinas of the Twelfth Conference on

the Interface of Statistics and Computer Science. New York:

IEEE Computer Society Press, 1979

2Zelkowitz, M. V., "Data Collection and Evaluation for Experimental Computer Science Research," Empiric_l Foundations

for Computer and Information Science (Proceedings),

November 1982

6Zelkowitz, M. V., "The Effectiveness of Software Prototyping: A Case Study," Proceedinus of the 26th Annual Technical Symposium of the Washinaton, D. C., Chapter of the ACM,

June 1987

6Zelkowitz, M. V., "Resource Utilization During Software

Development," Journal of Systems and Software, 1988

8Zelkowitz, M. V., "Evolution Towards Specifications Environment: Experiences With Syntax Editors," Information and

Software Technolouv, April 1990

Zelkowitz, M. V., and V. R. Basili, "Operational Aspects of a

Software Measurement Facility," Proceedings of the Software Life Cycle Manaaement Workshop, September 1977

NOTE__:

iThis article also appears in SEL-82-004, Collected Software Englneerlng Papers: Volum@ I, July 1982.

2This article also appears in SEL-83-003, Collected Software Enalneerlnq Papers: Volume II, November 1983.

3This article also appears in SEL-85-003, Collected Software Enuineerina Papers: Volume III, November 1985.

4This article also appears in SEL-86-004, Collected Software Engln_rmng PaPerS: Vol_me IV, November 1986.

5This article also appears in SEL-87-009, Collected Software Englne@rmnq Papers: Volume V, November 1987.

6This article also appears in SEL-88-002, Collected Software Englneermng Papers: VoIum@ VI, November 1988.

6109

B-14
7This article also appears in SEL-89-006, C911ected Software Enqineerina Papers; Volume VII, November 1989.

8This article also appears in SEL-90-005, CQllected Software Enqineerinq Papers: Volume VIII, November 1990.

6109

B-15

- • _