A Metho dology for Migration of Legacy Applications to Distributed

Ob ject Management

E. R. Hughes R. S. Hyland S. D. Litvintchouk

A. S. Rosenthal A. L. Schafer S. L. Surer

The MITRE Corp oration

Bedford, MA 01730-142 0

Many organizations wish to con gure and recon g- Abstract

ure systems from reusable, replaceable comp onents,

Much of today's software development involves

each of which provides a sp eci c service. In older

reengineering legacy applications, but the bulk of

or current systems here called the legacy systems,

research and tools address new software develop-

application-sp eci c co de is entwined with co de that

ment. The Distributed Object Management Integra-

implements rather generic services, such as map dis-

tion System DOMIS, 1993-96 project investigated

play, data replication, or event noti cation. As a re-

how legacy applications can be incremental ly modi ed,

sult, this generic functionality is unavailable for use

or migrated, by using distributed object management

by other applications, and must b e duplicated and

DOM technology. This paper describes a methodol-

maintained separately within each application. We

ogy for such migration using DOM technology.

use the term \duplicated" lo osely; in extreme cases

our metho dology might b e applied to a legacy imple-

1 Intro duction

mentation and services which di er in terms of sp eed,

2

Our domain is command and control C  systems,

accuracy, and p ossibly even b ehavior. However, more

consisting of large amounts of legacy software that

similar duplicated functionality makes the metho dol-

have b ecome very dicult to change and extend. We

ogy more attractive.

have found that a DOM architecture such as the Com-

Our approach to migration is to de ne a set of

mon Ob ject Request Broker Architecture CORBA

target services, many of whichmay b e encapsula-

[3] reduces the cost and risk of reengineering i.e.,

tions of existing service mo dules, and to reengineer

mo difying the source co de of  systems within this do-

legacy applications to rely on a common implemen-

main.

tation of these services. This approach alleviates the

We b egan byinvestigating coarse-grained DOM en-

need to maintain a customized implementation of the

capsulation of legacy software, in whichentire ex-

service in each system. Migration may o ccur in several

ecutable applications are encapsulated as ob jects.

phases, each of which encapsulates some functionality

Coarsely encapsulated applications can b e accessed

as a common service and eliminates some dep endence

via DOM relatively indep endent of lo cation, platform,

on the legacy services. Services are then invoked us-

and programming language. We then reengineered

ing a distributed request broker, preferably one that

legacy software to employ ner-grained encapsula-

conforms to a DOM standard.

tion, replacing duplicated functionality with ob ject-

By service,we mean a conceptually coherent set

oriented invo cations of a reusable common service.

of functions, indep endentofany implementation. A

We p erformed an exp eriment to reengineer a stand-

service interface can b e discussed even if the system

alone legacy application, implementing its map display

currently contains no software that actually supp orts

functionalitybyinvoking a b etter, o -the-shelf, DOM-

the interface. An interface is typically sp eci ed in an

encapsulated map display service. Coarse-grained en-

Interface Description Language IDL; suchaninter-

capsulation is relatively easy to apply to a legacy

face is reasonably human-readable and can b e com-

application, so this pap er concentrates on the more

piled into executable co de.

challenging migration of existing systems using ner-

grained encapsulation. We also describ e our lessons A legacy service is an implemented service within

ab out the e ort and risk involved. a legacy system. Frequently a legacy service will have

p o orly do cumented dep endencies and back-do or com- 2 Finer-Grained Encapsulation

munications. Typically, a legacy service has di erent

The purp ose of our metho dology is to migrate a

functional b oundaries than the services available to-

legacy application to use the target functionality made

day.For example, the develop ers of our legacy system

available by new services created from b est-of-breed

did not consider map display capability as a replace-

implementations. The legacy functionality of the ap-

able service but rather as an integral part of airspace

plication and its asso ciated maintenance costs are

con ict detection.

eliminated. The metho dology has an obvious exten-

Some of the services to b e extracted may b e used

sion for migrating multiple legacy applications at once,

across the industry, while others may b e sp eci c to the

whichmay reduce the total cost of the migrations.

2

C problem domain. When two or more applications

Figure 1 illustrates our approach. Here, the strip ed

have implemented very similar functionality,itmay

boxes represent duplicated functionality, whichisbe-

b e advantageous to turn this functionalityinto a com-

ing removed from legacy applications A and B and re-

mon service. Then, one can make a server function

placed with invo cations of a DOM-based service con-

f accessible to outside clients by providing a wrapper

structed by encapsulating co de from B. This gure

function that can b e invoked by a DOM request and

assumes that there is not already an established stan-

that invokes f.

dard service, and that the strip ed mo dule in B is

appropriate for reuse as a service. The arrows from

1.1 Structure of this Pap er

legacy mo dules to the DOM framework illustrate the

We b egin by reviewing DOM technology and the

evolution emb o died in our metho dology. The legacy

b ene ts it provides for distributed applications. We

co de for duplicated functionality in A is retired and

then present our metho dology and discuss the steps

no longer maintained as part of the migration e ort.

involved. Finally,we give some conclusions and fur-

2.1 Our Exp eriments with Finer-Grained

ther discussion.

Encapsulation

1.2 DOM Technology and Bene ts

We p erformed two exp eriments motivated bya

We assume that the reader has a working famil-

suite of Air Force planning systems, collectively com-

iarity with DOM software; intro ductory information

prising many millions of lines of co de. In b oth, the

can b e found in [3] and [4]. Our DOM software is a

goal was to learn ab out migration, not to pro duce an

commercial CORBA Ob ject Request Broker ORB,

op erational system. The exp eriments attempt to pro-

whichwe nd provides the advantages of:

vide insight to the managers who plan acquisitions to

upgrade these systems, and also to the engineers who

 platform and language indep endence might carry out the upgrades.

The rst exp erimentwas brief, involving the map

 network lo cation transparency

display service from the Airspace Planning System

APS. This exp erimentwas terminated b ecause we

 increased fault tolerance the ability to transpar-

concluded that APS was to o large and complex to

ently restart services on demand

reengineer with our resources, and b ecause map dis-

play is not central to APS.

 reduced development e ort by reusing common

The second exp eriment reengineered part of the

services

Airspace Decon iction System ADS, an application

that provides spatial analysis and editing capabilities

 consistent do cumentation of interfaces

to detect and repair con icts b etween air routes. Our

goal was to replace the legacy map display functional-

ity with brokered invo cations of a map display service.

CORBA do es not sp ecify the level of granularity

The map display capabilitywas selected b ecause it is

for ob jects. Ob jects can b e entire systems, subsys-

present in many military systems, improvements were

tems, applications, services, real world ob jects planes,

desired, it is imp ortant to ADS, and a new map dis-

targets, etc., or programming ob jects. This exibil-

play service was available to us.

ity allows CORBA to b e used to integrate systems,

bridging legacy and mo dern, ob ject-oriented software The ADS application currently provides its own im-

development paradigms. Ob jects can b e integrated plementation of map display, in which airspace infor-

with other ob jects at any level of granularity, includ- mation is overlaid on maps constructed from World

ing ob jects that are encapsulations of entire legacy Data Bank I I data using a Graphical Kernel System

systems. GKS graphics package. GKS is not a suitable basis

ality of the application. In short, we found the migra-

Enterprise Portfolio tion depicted in Figure 1 to b e infeasible for duplicated

functionality which is closely tied to the user interface, hnologies do not supp ort in-

Application A Application B partly b ecause DOM tec

tegration of user interfaces. However, our approachis

promising for other more limited forms of integration

that are supp orted by DOM.

A more radical approachmay b e preferable to the

e underto ok. We tried to keep the main appli-

RETIRE one w

cation logic and replace a single service or, by ex- services provide evolve to

services to use evolve

tension, set of services. An alternativewould b e to

start by obtaining a base of services|buying generic

endors and encapsulating key parts of

Methodology services from v

the legacy application. One would then rewrite the

legacy system using a mo dern framework e.g., Java-

Beans or ActiveX. The following sections p oint out

the advantages and risks for our metho dology, which

can b e used to determine a go o d approach for a par- ticular migration pro ject.

Object Request Broker (ORB)

3 Metho dology

This section presents a metho dology for migrating

applications to use DOM-encapsulated services. It

guides pro ject managers through the steps to take,

kinds of resources that will b e needed, diculties that

pro jects are likely to encounter, and, where p ossible,

ays to reduce risk. The complex issue of duplicated it prop oses w

functionality

granularity of each migration step is deferred to Sec-

tion 4.

This metho dology is an initial e ort in the area. It

Figure 1: Approach to Finer-Grained Encapsulation.

abstracts the techniques we used, or in some cases

wish we had used. But our task involved limited re-

sources in two small pilot studies that did not aim to

for a reusable service, for several reasons b eyond the

pro duce op erational systems. No doubt some of the

scop e of this pap er. For the replacement service, we

lists of criteria are incomplete. Wehave not exp er-

1

encapsulated the Spatial DisplayTo ol SDT appli-

imentally compared our metho dology to alternative

cation, whichwas intended to b e a reuseable service,

metho dologies. Despite these caveats, we found that

and we used Orbix 2.0.1 from Iona Technologies as the

do cumenting the metho dology has clari ed our think-

ORB.

ing and that our exp eriments were essential in devel-

The reengineering e ort was partly successful. It

oping the metho dology. Moreover, we b elieve that the

greatly improved our understanding of migration is-

metho dology will help us plan future e orts more re-

sues and risks, to the p oint where we could prop ose a

alistically and execute them more eciently.

useful metho dology.We b elieve that we learned many

As we mentioned earlier, our main exp erimentwas

useful lessons, whichwe present in this pap er. We did

limited to a mo derate-sized application. ADS is ab out

not endeavor to eld a complete system, so some parts

100,000 lines of C co de. SDT is larger but we did not

of the metho dology have not b een deeply explored.

need to reengineer it, so its size was not a factor. Our

Our exp eriments attempted to preservemuch of the

team consisted of 5 p eople working various fractions of

legacy application. In retrosp ect, we mighthave b een

their time for a total of 3 sta -years over a single scal

able to do more signi cant reengineering if we had cho-

year. Although wesketched the metho dology early in

sen a service with less user interface functionality,as

the exp eriment, the details and many of the lessons

this was dicult to disentangle from the core function-

emerged when we revisited our exp erience.

1

Our metho dology consists of the following ten steps.

SDT was develop ed by the Mapping Application Client-

Server MACS pro ject at Rome Lab oratory. The ordering of the steps is approximate, since in re-

ality the steps will overlap and some steps will b e re- In this metho dology,we concentrate on maintain-

p eated. ing exibility throughout a pro ject's duration to mini-

mize the risk and cost of unanticipated problems. The

1. Identify services and a migration applica-

following sections describ e the steps in further detail,

tion. Determine whether the cost and b ene t of

emphasizing steps 1, 5, 7 and 8.

migration is favorable for an application and a

Step 1: Identify Services and a Migration

candidate set of services which can replace some

Application

functionality within the application.

The pro ject team should meet with management

2. Assess the impact of the deploymentenvi- and chief architects to select candidate functionality

ronment and goal architecture. Identify the to b e replaced by reusable services, de nitions and

execution environment in which the migrated ap- implementations of those services, and applications to

plication will b e deployed. Describ e the impact b e reengineered. Our pro ject b ene ted from this kind

of the di erences b etween this deploymentenvi-

of communication by ending our rst exp eriment when

ronment and the execution environment of the it was learned to b e of lesser value than our second

original application. exp eriment. Step 1 will largely b e driven by the goals

and constraints of management and chief architects.

3. Establish a reengineering development en-

Additional criteria for evaluating candidates are given

vironment. Identify the developmentenviron-

b elow, roughly in order of imp ortance.

ment and to ols needed to reengineer the legacy

First, the services should b e b est-of-breed and in-

application.

tended for reuse. Services provided by the computing

infrastructure or DOM framework should b e consid-

4. Baseline the legacy application. Obtain,

ered if appropriate. Implementations' p erformance,

build, install, con gure, and test the legacy co de

price, future supp ort, and required environmentmust

in the reengineering environment.

b e considered.

5. Obtain a reusable service. Identify and in-

Next, the application should have lasting value

stall a new service, which can b e invoked via an

within the p ortfolio to merit migration, and the ser-

ob ject interface. The service could b e newly de-

vice should b e imp ortant to the application.

velop ed, purchased from a third party, or a DOM

The maintenance costs of the duplicated functional-

encapsulation of some existing functionality i.e.,

ity are an imp ortant consideration. Typically, the du-

a wrapp ed service.

plicated functionality is p erceived as exp ensive \bag-

gage" asso ciated with the application.

6. Analyze the legacy co de. Identify co de in the

The source co de of the application must b e avail-

legacy system that invokes duplicated functional-

able, reasonably well understo o d, mo dularized, and

ity and determine how to mo dify that co de to use

of reasonable size. Programmers and to ols should b e

new services.

available for the languages involved. In addition, the

languages and compilers should supp ort ORB bind-

7. Remo dularize the legacy co de. Remo dular-

ings unless the team is considering a complete rewrite

ize the legacy application to separate duplicated

in a new language.

functionality from the core functionality of the

The duplicated functionality in the legacy applica-

application.

tion should match as closely as p ossible the function-

8. Reengineer the legacy co de to invoke

ality provided by the service. This allows calls to the

reusable services. Connect the remo dularized

service to replace the duplicative co de fairly directly.

application to the new services, using mediation

The team must also consider the computational accu-

to adapt to small mismatches.

racy of the duplicative co de.

A service should provide a convenient level of ab-

9. Integration test the migrated application.

straction, e.g., at the business pro cess of the enterprise

Demonstrate that the migrated application meets

or at the level of common infrastructure comp onents.

the goals of the migration when running in the

This level of abstraction reduces the amount of reengi-

target environment with the new services.

neering necessary in the future.

Step 1 is time consuming and involvesavarietyof 10. Do cument the migrated application. De-

skills, including domain exp ertise, an understanding scrib e the ob ject de nitions, service calls, and

of the work ow of the enterprise with resp ect to the reengineered co de of the migrated application.

culties we encountered stem from distribution, and af- legacy application, and p ossibly the user interface as-

fect development and redevelopment in similar ways. p ects of the legacy application.

Con gurations spanning multiple machines must b e

Changes in direction are quite likely, b ecause im-

kept consistent. Di erent compiler versions maybe

pressions derived from a surface examination are un-

needed for di erent parts of the system.

reliable. A rst pass pro duces a list of candidate ser-

vices and applications for migration. Leading candi-

Con guration management to ols are quite imp or-

dates are investigated in gradually increasing depth,

tant. Because one is not building mo dules from

revising estimates and p erhaps changing priorities if

scratch, it takes less time to pro duce new versions

other candidates app ear to o er b etter cost/b ene t.

for inclusion. Interfaces may b e undergoing ma jor

changes. We encountered diculties in reconciling

Step 2: Assess the Impact of the Deploy-

versions of the various legacy mo dules and versions

mentEnvironment and Goal Architecture

created in our reengineering. Ideally, one would use

The future architecture and deploymentenviron-

con guration management to ols that are friendly to

mentmay b e outside the control of the migration

\foreign" versions of individual comp onents.

team. The migration team may need to conform to

During the migration, we found it dicult to man-

others' sp eci cations for the future deploymentenvi-

age the server interfaces and the connections e.g.,

ronment and architecture. For example, the ADS de-

function calls in application co de b etween applica-

ploymentenvironment sp eci es the use of certain di-

tions and servers. To reduce this burden, we de ned

rectories and UNIX environmentvariables. The team

each service interface in a single lo cality e.g., direc-

must discover such dep endencies in b oth the current

tory that was easy to control under versioning and

software and the future environment, and may need

con guration management. From this, we derived a

to mo dify the legacy application to reduce the dep en-

list under similar control of all functions in the server

dencies b etween it and its current deploymentenvi-

interface. This list was often used to search client

ronment.

mo dules for calls to the server. These measures con-

The team must understand di erences among the

siderably simpli ed migration and testing. We recom-

environments of the services, of the legacy deployment

mend the use of one such con guration unit for each

environment, and the new deployment and reengineer-

service involved.

ing environments. At the time of our exp eriment,

Early redevelopment steps should attempt to b e

many asp ects of the new deploymentenvironment

compiler neutral, b ecause one may discover at later

were not decided, so wechose an environment and

stages that certain comp onents applications, servers,

goal architecture based on our understanding of typ-

request brokers, or even make les require a particular

ical requirements. The ORB made it unnecessary to

compiler. Make les can b e extremely complex, and

reconcile manyenvironment di erences of the legacy

like the application co de, may require reverse engi-

application and the newly-encapsulated map display

neering to ols. In the ADS exp eriment, the complexity

service, which run under di erent op erating systems

of the make les resulted in at least one hard-to- nd

and thus with di erentversions of the DOM pro duct.

bug. In many other resp ects, guidelines for the reengi-

Step 3: Establish a Reengineering Devel-

neering environment resemble guidelines for an ordi-

opmentEnvironment

nary developmentenvironment. The [re]development

The reengineering developmentenvironmenttypi-

denoting reengineering or development environment

cally augments the deploymentenvironment with sup-

should b e as close as p ossible to the deploymentenvi-

p ort for reengineering and development to ols and for

ronment.

running the legacy applications. We used reverse engi-

Selection criteria for a request broker resemble

neering to ols based on Software Re nery by Reason-

those for an op erating system. The request broker

ing Systems provided by the Software Architecture

must b e widely available and must b e compatible with

Recognition To ol SART group within MITRE. Our

the critical pieces of software to b e deployed, develop-

exp erience with reverse engineering is describ ed in [6].

ment to ols e.g., con guration managers, and reverse

Some asp ects of reengineering may b e dicult to

engineering to ols. Additional factors, as usual, include

p erform in parallel, compared with corresp onding as-

languages supp orted, debugging to ols, do cumentation

p ects of new co de development. Once an architecture

quality, supp ort, and cost.

is in place, development of di erent co de mo dules is

Step 4: Baseline the Legacy Application

relatively indep endent. In contrast, reengineering can

change the architecture, and so much of the reengi- Baselining the legacy application involves obtain-

neering involves multiple legacy mo dules. Other di- ing, installing, compiling, and running the appli-

cation in the reengineering environment. In the  Semantics. A migration often involves semantic

past, contractors hand-installed the application on di erences b etween the services and the legacy

the purchasers' machines. If the application makes co de which uses the services. We recommend a

assumptions ab out the environment in which it will declarative approach in which client and server

b e installed e.g., the existence of sp eci c le path- describ e their interfaces, and a mediator is used

names, environmentvariables, and install lo cation, to translate arguments passed b etween them. We

this metho dology step will b e very risky. Lacking haveworked with another pro ject [5] at MITRE

go o d do cumentation of installation and con guration to develop such an approach.

issues, one may need assistance from an application

exp ert.

Step 5.2: Wrap a Service

Approximately 45 p erson-days were required to

Having designed the interface for a service, the mi-

deal with the installation and con guration of ADS.

gration team will typically need to build a DOM wrap-

Considerable time was devoted to xing problems with

p er which implements the interface. This wrapp er

the source co de given to us, adapting ADS to our en-

may not require mo di cation of the implemented ser-

vironment, and p opulating its database.

vice, but may exp ose de ciencies in the service or in

The migration team should allo cate signi cant re-

the teams understanding of the service. The following

sources to this step. For a longer-term solution, we

factors should b e considered.

recommend that future application develop ers b e re-

quired to deliver software which is installable without

 Architecture. The software architecture or dis-

consulting the develop er. Ideally, one would accept

tribution mechanisms of the service may not have

only software that is self-installing in some default en-

b een designed to supp ort a wrapp er which en-

vironment. If a systems programmer is required, that

capsulates the service. For example, the legacy

programmer should not need to b e familiar with the

SDT interface is implemented by stubs of C co de

application.

that are linked to a client of the service, and that

Step 5: Obtain a Reusable Service

use RPCs to communicate with the main SDT

server. Ideally, one would wrap the main server

The ob jective architecture that we advo cate in-

and discard the stubs and RPCs. Due to time

cludes a set of reusable services that are accessible

constraints, we wrapp ed the legacy interface the

via the DOM infrastructure. A service could b e ei-

stubs, so that the CORBA invo cation was fol-

ther newly develop ed to satisfy an identi ed need, an

lowed by an RPC invo cation. This implementa-

existing DOM-based service, or a DOM encapsulation

tion was exp edient, but incurs extra overhead.

of existing functionality i.e., a wrapped service. In-

stalling an existing service is similar to baselining the

 Arguments. The wrapp er must use IDL's rather

legacy application, describ ed in the previous section.

limited typ es to de ne arguments to the functions

From here on we assume that the service has already

in the interface. Server functions that were in-

b een installed in the reengineering environment.

tended to b e invoked only from their native ma-

Step 5.1: Design the Interface for a Service

chine may use complex typ es that are dicult to

A service must sp ecify functions supp orted, argu-

express in IDL. For example, wewere unable to

ments to b e passed, and results to b e returned, in an

replace functionality which used X/Motif to in-

interface with which clients will communicate. Typ-

teract with a window since that replacement re-

ically, the interface will b e implemented by a DOM

quires IDL de nitions for the complex typ es used

wrapp er for the service. The migration team should

by X/Motif.

consider the following factors when designing an in-

terface.

 Co de generation. A wrapp er contains co de

generated from a high- level description in IDL.

 Standards. One of the ob jectives of the migra- For CORBA, we found that one can inadvertently

tion pro ject is to provide service interfaces that write IDL that includes unnecessarily p owerful

comply with op en or industry standards. This al- constructs that are exp ensive to implement. In

lows the service to b e replaced in the future bya particular, we recommend that the team use typ e-

commercial pro duct, thus preserving the reengi- def rather than interface to de ne ob ject typ es

neering investment and providing a path to the used only as arguments to the functions in the

use of new software. interface.

Step 6: Analyze the Legacy Co de variables, compiler options, etc. X-Windows intro-

duces a particularly dicult dep endency on the struc-

Once the legacy application and services are in-

ture of a secure application, b ecause only one pro cess

stalled in the reengineering environment, the team

is typically allowed to up date a window. Often, a de-

must analyze the legacy application to identify the

p endency is only discovered when a change is made

co de which implements functionality duplicated bya

that breaks it.

new service. This step makes extensive use of reverse

Replacing calls in existing co de may b e so costly

engineering to ols and related software. Exp ertise with

that a rewrite is preferable. First, the ab ove dep en-

the legacy application and reverse engineering to ols

dencies may b e to o complex. Second, an application

should provide high level architectural descriptions,

may contain very many calls to a service e.g., user

detailed dep endency lists, source co de organization

interface, error handling, in nearly every mo dule. If

and naming conventions, and the calls to the func-

intro duction of the new service requires rewriting all

tionality to b e replaced. It is imp ortant to develop

those calls, rewriting the entire application maybe

a parallelizable work plan for this step, as manyof

b est.

the reverse engineering to ols can take hours to p er-

form computations. See [6] for further description of

Step 8: Reengineer the Legacy Co de to In-

this step. Information on reverse engineering can b e

voke Reusable Services

obtained from the Advanced Software and Reverse En-

An application with appropriate mo dules as pro-

gineering group at MITRE and [2].

duced by step 7 is to b e mo di ed so that it actually

Step 7: Remo dularize the Legacy Co de

uses the new DOM-invokable services. Remo dulariza-

tion adjusted the application's mo dule b oundaries to

The existing mo dules of the legacy application may

suit the new service; this step deals with the detailed

not re ect the desired decomp osition into services.

call interface, and connects to an actual implementa-

The team has the option of remodularizing to lo cal-

tion of the new service. Because a client application

ize and separate core functionality from functionality

may include many calls to a server, muchcodemay

which might b e provided by a future service. Such

need to b e rewritten. The following factors should b e

remo dularization can simplify the replacementofthe

considered.

duplicative co de and can make it easier to migrate the

application to use other services in the future.

Mediation. The legacy application is likely to rep-

resent information di erently from the new service.

For example, ADS functionality might b e describ ed

That is, even though the b oundaries may b e essen-

as decon iction i.e., identifying and resolving con-

tially right, there can b e a myriad of small di erences,

icting air routes, pro ducing rep orts of con icts and

often several p er argument.

changes it has made, display of maps and map fea-

tures, display of airspaces, and window and menu ma-

There are three ways to resolve the problem. First,

nipulation. Decon iction is ADS's core functionality.

co de that manipulates arguments could b e rewritten;

A reasonable redesign of ADS might use mo dules for

however, this may b e tantamount to complete reimple-

each of these functions.

mentation. Second, for each call, one might manually

However, remo dularization can b e very costly, for insert translation co de; this is still costly, and leaves

two reasons. First, the ab ove redesign is very di erent the application dep endent on representation details

that may di er among implementations of the service.

from the existing partition of ADS co de into directo-

Finally, for a more exible solution that requires less

ries. Wewould need to design the ab ove mo dules,

programming, one can use mediation. In mediation, a

encapsulate co de for each i.e., remove hidden dep en-

dencies, and build the new mo dules. Second, and rep ository describ es the representations and assump-

more serious, the old service will rarely b e an exact tions that each party uses, and provides a library of

atomic conversion functions. For each call, an auto-

duplicate of the functionality of the new service|the

mated mediator synthesizes and inserts the necessary

old service mayhave a di erent granularity, and may

translation expression. We exp ect such mediators to

assume to o little, or to o much, knowledge of the client

application. b e common within a few years.

It seems preferable to work in small steps. We Co de removal. Ideally, co de related to the old

chose to remo dularize ADS just enough to pull out service would b e removed during reengineering, but

map display functionality. Even this remo dulariza- this may b e exp ensive. Wechose to add the new calls

tion requires an understanding of the dep endencies without removing the old. For map display, the ex-

between the legacy functionality and the rest of the tra workload and extra windows were tolerable; du-

legacy co de, including global variables, environment plication might b e semantically incorrect or to o costly

in some other settings e.g., purchase order entry, re- In this work, we encountered several issues that dif-

mote database access. Retaining old calls reduced ferentiate legacy reengineering from the construction

the amountofcodetobechanged, and was less likely of new software.

to break hidden dep endencies. Also, simultaneous dis-

Encapsulation granularity. Coarse-grained

playby old and new services can b e useful in debug-

DOM encapsulation allows legacy applications to b e

ging.

encapsulated in binary form i.e., without recompil-

Dep endencies. If the duplicativecodeistobere-

ing, which gives the b ene ts of lo cation and language

placed, the dep endencies b etween that co de and other

indep endence without exp ensive reengineering. Finer-

legacy co de may b e broken. The team can uncover

grained encapsulation can b e used to eliminate du-

dep endencies by gradually replacing legacy co de with

plicated functionality within a p ortfolio, resulting in

calls to services, but some areas, such as GUI interac-

signi cant long-term b ene ts but with higher reengi-

tions, mayhavetobetackled as a single unit.

neering costs.

Security. When data or services are made more

To ols. Most of the to ols used in new soft-

widely accessible, administration and security issues

ware development are also useful for legacy migra-

b ecome more severe. A wider range of access options

tion pro jects; still there is a need for more and b etter

means that organizations need to make a wider range

automation. Reverse engineering to ols are particu-

of decisions. DOM software may provide mechanisms

larly imp ortant to a legacy migration pro ject but these

for enforcing these decisions, but these are currently

to ols need to b e more exible, b etter at handling large-

immature. In addition, connecting two pieces of soft-

scale software, b etter at handling information e.g.,

ware may compromise the security mechanisms used

make les outside ordinary programming languages,

by either piece of software; for example, changes to

and easier to use. Reverse engineering to ols should not

windowing implementations might cause leaks.

b e standalone like Software Re nery, but should b e

User interface. User interface functionality is dif-

part of an integrated environment that includes design

cult to migrate incrementally b ecause window and

and forward engineering.

menu construction is very platform-sp eci c and call-

Service separation. Itisvery dicult to con-

back functions are not directly amenable to DOM dis-

struct a new service from existing software that was

tribution. We exp ect that more advanced frameworks

not intended to b e shared bymultiple clients. If the

likeJavaBeans will solve this problem.

existing software has state whichmust b e maintained

Correctness.To test the reengineered system, one

from one call to another, this state may need to b e

needs a sp eci cation of \correct" b ehavior. The old

replicated for each client, or may preclude sharing of

service's b ehavior may provide an approximation, and

the service.

duplicate execution may help. However, it may not

Wrapping. Some imp ortant considerations for

b e necessary or desirable to retain all b ehaviors, and

wrapping are the existence of standards esp ecially

correctness of user interface may b e tougher to sp ecify

standard interfaces in the service domain and the ef-

than correctness of computational results.

ciency of adding a new interface layer.

In our exp eriment, we added and tested the calls

Con guration Management. The software

to SDT one at a time, with separate team memb ers

reengineering task of mo difying an application to use

adding separate calls. Together with con guration

new services is very di erent from building the appli-

management, this allowed the memb ers of our team

cation from scratch. This task involves many small

to work concurrently and to incorp orate new versions

changes to existing co de with frequent testing and co-

of the service as they b ecame available. To reduce re-

ordination of versions. Also, when one integrates soft-

source requirements, we reengineered a subset hop e-

ware from di erent sources such as the application

fully representative of the mo dules that used map

and new service, one may encounter con icts with

display.

the con guration management used on each.

4 Further Discussion

Most software engineering to ols are designed to

Wehave presented a metho dology for migrating supp ort the development of new software, but reengi-

legacy applications with duplicated functionalityto neering of legacy systems may b e more common in

use DOM to invoke shared services. The resources for practice. Metho dologies like ours help by p ointing out

our exp eriment did not p ermit completion of all steps where existing software engineering to ols can b e used

of the metho dology, instead we concentrated on steps in new ways to migrate legacy systems. The dicul-

1, 5, 7, and 8. Wehave omitted discussion of steps ties involved in reengineering systems also p oint out

9 and 10 b ecause they were p erformed only cursorily. ways to b etter engineer new systems, such as designing

mo dules which corresp ond to p otential services. [2] Communications of the ACM, Issue on Reverse

Engineering, Vol. 37, No. 5, May 1994.

The steps of the metho dology presentvarying de-

grees of risk, b oth managerial and technical. We found

[3] Common Object Request Broker: Architecture and

that steps 6-8 presented the highest risks b ecause they

Speci cation, Revision 2.0, Ob ject Management

involved the greatest amountofinvestigative discov-

Group, Inc., Framingham, MA, July 1995, see

ery, dicult problem solving, and ma jor design de-

http://www.omg.org/.

cisions. Roughly half of the e ort exp ended in our

exp erimentwas in these steps.

[4] R. Orfali, D. Harkey, J. Edwards, The Essential

Steps 3-5 presented the next highest risks. We des-

Distributed Object Survival Guide, 1996.

ignated these as medium, rather than low, risk b ecause

[5] S. Renner, A. Rosenthal, J. Scarano, \Data Inter-

of the p otential amount of time and resources that can

op erability: Standardization or Mediation", IEEE

b e consumed in accomplishing these steps. In our ex-

Metadata Workshop, Silver Spring MD, April

p eriment, roughly one third of our e ort was exp ended

1996, see http://www.nml.org/resources/misc/

in obtaining to ols, con guring the reengineering envi-

metadata/pro ceedings/pap er list.html.

ronment, obtaining and building ADS, and obtaining

and wrapping SDT.

[6] S. Surer, E. Hughes, R. Hyland, A. Rosenthal, A.

Our metho dology for ner-grained encapsulation

Schafer, Distributed Object Manage- ment Integra-

represents an intermediate p ointbetween coarse-

tion System DOMIS FY96 Final Report 3 vol-

grained encapsulation of legacy applications and rad-

umes, MTR 96B0000067, The MITRE Corp ora-

ical reengineering of entire applications. Eachof

tion, 1996.

these approaches is appropriate in certain situations.

CORBA can playanintegral role in each approach.

In the future, we plan to investigate more extensive

frameworks likeJavaBeans and their role in more rad-

ical reengineering metho dologies.

Acknowledgments

Our exp erimentwas extremely challenging, and we

would not have b een able to accomplish what we did

without the assistance of some key individuals. We

wish to acknowledge the help of Gerald Friedman, for

his business area leadership and for p ointing us in the

right direction; Melissa Chase and David Harris, for

their insights and software reverse engineering skills

that were key factors in our progress; Barbara Wol n-

ger and Barry Robinson, for providing information

and p ersp ectives on reengineering risks and alternative

approaches; Ioannis Kyratzoglou, for his domain ex-

p ertise, and Ken Brown Lucent, previously AT&T,

for providing assistance in getting our legacy applica-

tion running.

The work describ ed in this pap er was p erformed

by The MITRE Corp oration under a pro ject funded

by the Air Force Electronic Systems Command. The

pro ject oce is at Rome Lab oratory, Griss Air Force

Base, Rome, New York. The pro ject ocer is Carl

DeFranco, RL/C3AB.

References

[1] M. L. Bro die, M. Stonebraker, Migrating Legacy

Systems: Gateways, Interfaces, and the Incremen-

tal Approach, Morgan-Kaufman, 1995.