TRANSFORMATION OF LEGACY BUSINESS SOFTWARE INTO

CLIENT-SERVER ARCHITECTURES

Thomas Rauber

Department of Computer Science, University of Bayreuth, Germany

Gudula R

unger

Department of Computer Science, Chemnitz University of Technology, Germany

Keywords:

Legacy software, incremental transformation, transformation toolset, client server.

Abstract:

Business software systems in use contain speciﬁc knowledge which is essential for the enterprise using the

software and the software has often grown over years. However, it is difﬁcult to adapt these software systems

to the rapidly changing hardware and software technologies. This so-called legacy problem is extremely cost

intensive when a change in the software itself or the hardware platform is required due to a change in the busi-

ness processes of the enterprise or the hardware technology. Thus, a common problem in business software

is the cost effective analysis, documentation, and transformation of business software. In this paper, we con-

centrate on the transformation issue of software systems and propose an incremental process for transforming

monolithic business software into client-server architectures. The internal logical structure of the software

system is used to create software components in a ﬂexible way. The transformation process is supported by a

transformation toolset which preserves correctness and functionality.

1 INTRODUCTION

Software systems implement business processes of

an enterprise and capture essential expert knowledge

built up over decades. Due to changes in software and

hardware technologies, many enterprises need to con-

sider a change of their business software. Also, the

process of changing within an enterprise requires its

business software to be adapted or enriched with addi-

tional functionality. Thus, enterprises have to face the

fact of modernizing their software systems in order

to guarantee full functionality. The changes may con-

cern aspects of security, performance, usability, main-

tainance, as well as interactions with other software

systems or cost of the hardware platform used. Of-

ten the software also lacks features such as distributed

components, adaptivity to heterogeneous platforms or

scalability, whose current importance has been un-

known when the software systems were built. How-

ever, it is extremely difﬁcult to incorporate these fea-

ture in today’s running business software. The inte-

gration of distributed and adaptive behavior may re-

quire a complete restructuring of a software system

and might effect many aspects of an enterprise and its

business process.

In this paper we consider the generation of dis-

tributed business software starting from a mono-

lithic legacy software system. The implementation

of effective distributed software has been studied in

many different ways, including management decision

strategies for software replacement, business process

modeling or software design principles comprising

framework approaches (Lewandowski, 1998), dis-

tributed objects (Emmerich, 2000), distributed com-

ponents (Emmerich, 2002), and middleware integra-

tion (Bernstein, 1996). Distributed software design

for the legacy problem has been treated with wrapper-

and middleware approaches. Both approaches do not

meet the requirements of highly complex business

software in use. Therefore, distributed and adaptive

aspects are lacking in most business software sys-

tems although managers and software experts are well

aware of these deﬁciencies.

The contribution of this paper lies in the area

of transforming business software systems into dis-

tributed software systems with extended functionality.

The speciﬁc approach comprises the following novel

issues in treating legacy software:

Rauber T. and Rünger G. (2007).

TRANSFORMATION OF LEGACY BUSINESS SOFTWARE INTO CLIENT-SERVER ARCHITECTURES.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - DISI, pages 36-43

DOI: 10.5220/0002348400360043

 SciTePress

• The transformation of legacy software into dis-

tributed software takes the internal logical soft-

ware structure into account. This results in an

explicit representation of the modular structure

which can be exploited as distributed component

structure.

• The modular structure can be used to enrich the

functionality by including conﬁgurative features

and explicit workﬂow integration. This is sup-

ported by the creation of conﬁguration ﬁles or ex-

plicit workﬂows, depending on the speciﬁc needs.

• The transformation of software is performed in an

incremental transformation process organized in

several steps. The incremental approach enables

a separation of different concerns such as logical

and modular structure, component building and

efﬁciency. Also the transformation process al-

lows interactive decisions during the transforma-

tion process concerning the distributed target ar-

chitecture and/or the logical conﬁguration level.

• The incremental transformation implements as-

pects from model driven software development.

The model driven architectures (MDA) approach

proposes an incremental development of dis-

tributed software for different middleware plat-

forms. This paper applies the idea of MDA to

legacy software.

• The transformation process is supported by a

transformation toolset for transforming mono-

lithic legacy software into client-server architec-

tures. The transformation toolset uses compiler

based methods which is possible due to separa-

tion of different concerns and the incremental ap-

proach. Speciﬁcation languages are used to spec-

ify module and component structures on several

levels.

The entire transformation approach brings to-

gether recent technology from software engineering,

distributed systems, compiler design, and software

development of modern business software. The de-

sign and implementation of the transformation pro-

cess proposed in this paper is performed as part of

the TransBS

project by researcher and practitioners

in these areas including software development com-

panies.

The rest of the paper is organized as follows: Sec-

tion 2 presents background information about dis-

tributed systems, workﬂow technologies, and MDA.

Section 3 discusses requirements of effective software

transformation. Section 4 outlines the transforma-

tion process and the architecture of the transformation

toolset. Section 5 concludes.

http://www.transbs.de

2 BACKGROUND

The design and implementation of the transformation

process combines several different areas, including

distributed systems, component based software de-

sign, transformation approaches, MDA, and workﬂow

technology.

2.1 Component-based Software Design

Different approaches have been proposed to support

the communication between distributed objects in

heterogeneous distributed environments. An exam-

ple is the Common Object Request Broker Architec-

ture (CORBA) deﬁned by the Object Management

Group (OMG). For the development of solutions that

are independent from a speciﬁc programming lan-

guage, an Interface Deﬁnition Language (IDL) can be

used which allows the deﬁnition of interfaces of ob-

jects and data structures to be exchanged. Based on

CORBA and the remote procedure call (RPC) mech-

anism, the remote method invocation (RMI) of Java

has been developed. A distributed execution of the

Component Object Model (COM) can be obtained by

the DCOM extension. These approaches are useful

for the implementation of the distributed framework

into which the generated components can be mapped.

Distributed interacting components can be real-

ized with different systems:

• COM+ from Microsoft supports the execution of

COM components;

• Enterprise Java Beans (EJB) from Sun allows the

distributed execution of Java components;

• the CORBA component model (CCM) extends

the EJB approach to other programming lan-

guages.

These systems provide a general framework for dis-

tributed components, but they do not provide support

for a speciﬁc application area. Moreover, these ap-

proaches are not primarily intended for the distributed

execution of workﬂows and there is no direct support

for such an execution.

The development of component-based software

systems is considered by Component-based Software

Engineering (CBSE) approaches (Crnkovic and Lars-

son, 2002). CBSE approaches are mainly based on

component approaches like COM+, EJB or CORBA,

and provide techniques for developing modular soft-

ware systems. These approaches often comprise tech-

niques for an incremental development of software

systems (Mehta and Heineman, 2002) and for com-

posing existing components according to given re-

quirements and speciﬁcation (Cao et al., 2005; Zhao

TRANSFORMATION OF LEGACY BUSINESS SOFTWARE INTO CLIENT-SERVER ARCHITECTURES

et al., 2003). Techniques of Generative Program-

ming (Czarnecki and Eisenecker, 2000) and Aspect-

Oriented Programming (AOP) (Kiczales et al., 1997)

can also be integrated. The re-use of software

components is especially important for long-running

projects. CBSE techniques can be used as a gen-

eral framework to support the distributed execution

of workﬂows.

2.2 Business Software Transformation

The transformation of legacy software has been con-

sidered by many research groups. Most approaches

concentrate on the transformation of legacy software

into modular or object-oriented systems or on the

extraction of the business logics. New approaches

also consider distributed solutions, e.g. by providing

middleware for data integration (Akers et al., 2004;

Menkhaus and Frei, 2004). For distributed systems,

performance aspects play an important role (Litoiu,

2004), since additional latency and transfer times may

be necessary, e.g., when replacing legacy software by

web services using protocols like SOAP (Simple Ob-

ject Access Protocol) (Brunner and Weber, 2002). For

the transformation of software systems, approaches

like DMS (Baxter et al., 2004) have been developed

and have been applied to large software systems (Ak-

ers et al., 2004). Graph-based visualization tools are

often useful for the transformation (Balmas, 2004).

Clustering methods can be applied for identifying

modules of the legacy software and will be one choice

for providing modules in the TransBS project (Al-

Ekram and Kontogiannis, 2004; Lung and Zaman,

2004; Andritsos and Tzerpos, 2003).

Although there are many different approaches,

there exists no generally accepted method for the in-

cremental transformation of software systems. An

important reason for this lies in the fact that there

are many different distributed platforms like CORBA

or EJB that cannot be combined in an arbitrary way.

Therefore, a distributed realization often requires a

new implementation of the business logics.

The Model Driven Architecture (MDA)

approach

(Siegel, 2005) addresses this problem and uses a

model-based approach for the step-wise generation

of distributed, component-based software. The step-

wise generation starts with an UML speciﬁcation of

the static interfaces and the dynamic behavior of the

components in a platform-independent model (PIM).

A series of mappings that are given as UML exten-

sions like CORBA proﬁles or Enterprise Application

Integration (EAI) proﬁles leads to the generation of a

platform-speciﬁc model (PSM). Based on this, MDA

http://www.omg.org/mda

tools are used for generating program code for a spe-

ciﬁc platform.

Another important aspect of distributed business

software is the transparency of the distributed execu-

tion and the integration of explicit workﬂow deﬁni-

tions. The usual feature of transparency of distributed

execution seems to be un-appropriate for business

software systems, since expensive remote requests

may be generated if there is no knowledge of the dis-

tributed nature of execution.

The workﬂow technology for the formal descrip-

tion of the execution of business processes consti-

tutes an important contribution for developing ﬂexi-

ble business software. Many workﬂow management

systems have been realized, but few of these consider

distributed workﬂows. The Workﬂow Management

Coalition (WFMC)

deﬁnes standards for workﬂow

architectures also comprising aspects of a distributed

execution. A direct integration of workﬂows in the

technology of distributed components has not been

considered often (Emmerich, 2002). The TransBS

project described in this paper addresses this deﬁ-

ciency and combines technologies for the transfor-

mation of legacy software, distributed platforms and

workﬂow execution.

3 TRANSFORMATION

REQUIREMENTS

The transformation of an existing business software

system S into a distributed software system DS can

be done in many different ways, depending on the re-

quirements on the resulting software system DS. In

our approach the requirements are determined by the

goal to keep the given functionality but to increase

the ﬂexibility of the code so that it can be adapted to

different distributed or heterogeneous platforms and

enterprise requirements.

We concentrate on business software as it is used

in services and commercial enterprises, but our ap-

proach is not limited to this line of business. The typ-

ical method is to modify and to extend big standard

software packages such that the needs of the speciﬁc

company are met. This is the most cost effective way

to create speciﬁc business software but still requires

a great deal of programming effort since typical soft-

ware packages in use are of monolithic character. A

more ﬂexible standard software package could ease

software adaptation for speciﬁc enterprises tremen-

dously. This leads to the following main requirements

for a transformed software product DS.

http://www.wfmc.org

ICEIS 2007 - International Conference on Enterprise Information Systems

• The resulting software system DS should be exe-

cutable on different distributed or heterogeneous

platforms in an efﬁcient way. This includes that

remote method or function calls are made explicit

in contrast to most distributed software, but that

the software can also be adapted easily to a dif-

ferent distributed structure. We call this property

hardware ﬂexibility.

• The resulting software system DS should be ﬂex-

ible such that business software for a speciﬁc en-

terprise with reduced or enriched functionality

can be built easily. This kind of software ﬂexibility

is another goal for the resulting software system.

• The transformation into a software system with

hardware and software ﬂexibility should preserve

functionality and correctness of a given system S.

• The resulting software system should be efﬁcient

in the sense that remote method and function calls

are implemented with low communication and

packing overhead.

To meet these requirements for the resulting software

system we propose a transformation process which

transforms a given software system S into a ﬂexible

distributed software system DS.

• An intermediate representation given as auxiliary

program structure is used to support the transfor-

mation process. This representation is language

independent and appropriate for the transforma-

tion goals. The auxiliary program structure is a hi-

erarchical structure which captures the static soft-

ware structure. The highest level of the hierarchi-

cal structure is the coordination structure. This

level calls speciﬁc modules which encapsulate the

original functionality and which can exhibit a fur-

ther hierarchical structure. The hierarchical pro-

gram structure is the basis for a module structure

which decomposes the given monolithic program

code. This module structure is exploited to create

a) a ﬂexible program structure which can be used

for enterprise speciﬁc software (software ﬂexi-

bility) and

b) for deciding about explicit distributed heteroge-

neous execution (hardware ﬂexibility).

• Starting with this program representation an in-

cremental transformation process transforms the

given software system S into a modular system

and then into speciﬁc distributed software sys-

tem. The transformation steps are syntax based

and guarantee correctness. Interactive decisions

guide the transformation process.

• Efﬁciency in the resulting software system and its

speciﬁc derivations is achieved by the possibility

to design the speciﬁc functionality and distributed

execution in an explicit way.

To support the transformation process we propose a

transformation toolset to interactively transform soft-

ware. The next section describes this toolset in more

detail. The transformation process starts with the in-

put program and the speciﬁcation of the module struc-

ture, which is essential and has to be provided by soft-

ware experts, e.g. by a clustering method and interac-

tive design. The software experts are also responsible

for making the business processes explicit by using a

workﬂow description as described in the next section.

4 TRANSFORMATION PROCESS

In this section, we describe software modes of the re-

sulting software system, give an overview of the trans-

formation process, and sketch the different compo-

nents of the framework into which the transformed

components are included.

4.1 Software Modes

The transformation process for creating modular ﬂex-

ible distributed software from a given monolithic soft-

ware package is based on an intermediate software

representation which we call Flexible Software Rep-

resentation (FSR). This representation is the starting

point for a stepwise transformation of the given soft-

ware package S into a software package with the same

execution behavior but different properties concern-

ing the mode of execution.

We distinguish three software modes:

• The Software Subsystem mode (SSu) has an ex-

plicit modular structure derived from S from

which subsystems can be built easily. SSu mode

systems are executed on the same platform in the

same way as S. SSu allows the selection of sub-

systems representing parts of the execution behav-

ior of S. The goal is to extract speciﬁc functional-

ities provided by S as a separate subsystem.

• The Explicit Workﬂow mode (ExW) describes spe-

ciﬁc business processes by explicit workﬂows (in

a workﬂow description language such as XML).

ExW captures the business logics of S in the form

of an explicit workﬂow. This is the basis for a

modiﬁcation of the workﬂow to adapt the result-

ing system to the needs of different enterprises. It

also allows the generalization of the workﬂows to

conﬁgurable workﬂows that can easily be adapted

to different situations. ExW is executed on the

same platform in the same way as S.

TRANSFORMATION OF LEGACY BUSINESS SOFTWARE INTO CLIENT-SERVER ARCHITECTURES

Explicit

Workflow

Software Software

with as

configurable

Flexible Software Package

FSP

Subsystem Subsystem

Distributed

SystemWorkflow

FSR

Software

Subsystem

Distributed

Software

Distributed

Software

guided by

explicit

Workflow

Flexible Software Representation

Figure 1: Transition diagram for Flexible Software Repre-

sentation (FSR).

• The Distributed Software mode (DS) has an ex-

plicit structure of cooperating components which

can be mapped onto a speciﬁc distributed system.

The structure of DS is based on the modular struc-

ture of S as expressed by SSu. Additionally, DS

allows the mapping of modules to the entities of

a distributed system in the form of components.

The execution behavior of DS can be expressed

implicitly within the components or by explicit

workﬂows.

All three representation modes are created from

the FSR. A mixture of these three representation

modes results in software representations with en-

riched properties. The coarse structure of the trans-

formation from the FSR into SSu, ExW, or DS and

then into the mixed formats is depicted in Figures 1.

For example, the SSu style with explicit workﬂows

leads to a software package which can use conﬁg-

urable workﬂows to easily specify speciﬁc software

subsystems for a speciﬁc enterprise. A combination

of ExW and DS, on the other hand, describes an exe-

cution mode with explicit workﬂows that are executed

by components in a distributed system. All three fea-

tures together result in the most ﬂexible software rep-

resentation called Flexible Software Package (FSP),

from which a distributed software subsystem can eas-

ily be speciﬁed by conﬁgurable workﬂows.

The advantage to distinguish the three software

modes and to transform the FSR in incremental steps

is that not all software products have needs for all fea-

tures. Due to efﬁciency reasons only those features

which are really needed should be incorporated, since

more advanced software features have higher comput-

Table 1: Software parts for the three speciﬁc software

modes SSu, ExW, DS resulting from FSR.

Flexible Software Representation – FSR

Software Explicit Distributed

Subsystem Workﬂow Software

SSu ExW DS

upper coordination Workﬂow component

level program description cooperation

lower Modules/ Modules Components

level Functions

static Programming Workﬂow Distributed

support Environment Engine Runtime

System

ing demands.

The transformation of the FSR into SSu, ExW,

DS, or their mixed forms is done on the intermedi-

ate representation level. The intermediate representa-

tion consists of an upper level and a lower level. The

upper level describes the cooperation and coordina-

tion of software parts, thus specifying the possible dy-

namic behavior of the software. The lower part con-

tains software parts incorporating speciﬁc functional-

ities of the business software. Both together specify

the software in an internal format. The transforma-

tion process translates both levels separately into a

software representation including the newly created

features. Upper and lower level constitute the ﬁnal

software (still in an intermediate format) and requires

additional static software products to be executable.

Upper level, lower level, and static software products

for SSu, ExW, and DS are summarized in Table 1.

4.2 Transformation Decisions

The entire transformation is organized in an incre-

mental transformation process including (interactive)

transformation decisions. Figure 2 illustrates the

coarse structure of the transformation process and

the decision tree. One path along the transformation

direction corresponds to one speciﬁc transformation

process producing one business software system us-

ing a speciﬁc software mode. These software sys-

tems can be implemented based on different tech-

niques like EJB or Corba. The transformation process

is performed in the ﬂavor of the MDA approach.

The transformation process starts with a speciﬁ-

cation level that exposes the logical structure of the

given software system and partitions it into code frag-

ments that are intended to be used as modules in

later transformation steps. Currently, the speciﬁcation

level cannot be performed fully automatically. It can

ICEIS 2007 - International Conference on Enterprise Information Systems

ExW

Specification

Level

Intermediate

Represenation

Execution

Mode Software

Modular

StructureStructure

ModulesCode

Fragments

Logical

Program

Workflow

Description

Coordination

Structure

Compontents/

Services

Components

Business

Software

System

Coordination

Modules

Set of

filterselect

transform transform

createcreate

Executable ExecutableExecutable

Software Software

Environment

Programming

Workflow

Engine SystemRuntime

Distributed

include

SSu

FSR

Figure 2: Transformation decision and transformation process.

be supported by clustering techniques and data depen-

dence analysis tools, but still requires manual interac-

tion. In the intermediate representation, the logical

structure is represented explicitly and the code frag-

ments are represented as modules. Based on the mod-

ular structure, the execution mode creates a suitable

description depending on the software mode selected.

This can be a coordination program for the SSu mode,

a workﬂow description for the ExW mode, or a coor-

dination structure for the DS mode. This representa-

tion is the basis for the ﬁlter transformation which de-

termines which of the components should be prepared

for a remote execution. Correspondingly, the modules

are transformed into executable modules for the SSu

mode or components for the ExW or DS modes. De-

pending on the subsystem selected, a selection of the

modules or components is built and included into the

framework for the speciﬁc mode.

4.3 Resulting Software Systems

Figure 3 shows the software system generated in the

SSu mode. The subsystem has been selected by the

transformation process and has been included in the

form of modules. The control is provided by a coordi-

nation program that contains a part of the functional-

ity of the software package S. The modules can issue

data accesses that can be directed to the local database

or can be directed to non-local databases in the form

of remote accesses. Remote accesses are supported by

a data consistency service that is responsible for keep-

ing the database entries in different databases consis-

tent. Further support for remote accesses is provided

by a security service and a communication service.

All three services are provided as a static part of the

framework into which the modules are embedded.

Figure 4 depicts the software system generated for

the ExW mode. The difference to the SSu mode con-

sists in the use of a workﬂow engine which is able

to execute workﬂows comprising the business log-

ics of the software system S. The modules of S are

transformed into components that are activated by the

workﬂow engine according to the workﬂow. Each

component can issue data accesses which are per-

formed as local or remote accesses similar to the SSu

mode. The workﬂow engine is able to activate remote

components via a remote execution service that is pro-

vided as a static part of the software system. Remote

execution is managed via the communication service.

Figure 5 shows the distributed software system

DS generated by the transformation system for the

case that the execution is controlled by a coordina-

tion component which realizes a ﬁxed workﬂow in

the simplest case. This component orchestrates the

execution of the components. All data accesses of the

components are performed via the coordination layer

which transfers the accesses to the corresponding ser-

vices provided by the DS framework. Remote execu-

tion of components can be performed via the remote

executor service. All remote accesses are done via

the communication service that can be performed in

different ways.

TRANSFORMATION OF LEGACY BUSINESS SOFTWARE INTO CLIENT-SERVER ARCHITECTURES

database

local

...

coordination

remote access

communication

service

security consistency

service

network

local

accessprogram

module module

activate

Software Subsystem SSu

data access

activate

Figure 3: Software Subsystem SSu generated by the trans-

formation process.

component component

remote access

executor

remote

communication

service

security consistency

service

network

local

access

Explicit Workflow system ExW

activate

workflow engine

...

activate

use

useactivate

workflow

local

database

Figure 4: Explicit Workﬂow system ExW generated by the

transformation process working with a workﬂow engine.

4.4 Transformation Toolset

The incremental transformation process is performed

by an interactive toolset providing compiler-based

transformation tools and interactive decision tools.

The transformation tools work on internal representa-

tions of the software product to be transformed. The

toolset comprises the following functionalities:

• Build-intermediate-representation builds a hierar-

chical graph structure from a given description of

the logical structure in a speciﬁcation language.

• Create-coordination-program creates a complete

description of a coordination program calling and

coordinating the modules of the software.

• Create-workﬂow creates a complete description of

an explicit workﬂow.

• Create-coordination-structure creates a complete

description of the most general distributed coordi-

nation of components.

• ﬁlter-for-subsystem extracts a subsystem based on

a description of the required subsystem. This de-

scription can be provided interactively based on

the representation of the coordination structure.

• ﬁlter-for-workﬂow selects a workﬂow which de-

scribes the functionality of the resulting business

software. Only instances of this workﬂow will be

component component

database

local

...

component

coordination

coordination layer

controls

remote access

executor

remote

communication

service

security consistency

service

network

access

distributed software DS

access

local

access

Figure 5: Distributed software system DS generated by the

transformation process using a coordination component.

executable by the resulting business software.

• ﬁlter-for-distribution creates a representation of

the upper level of the distributed software which

will be incarnated in the ﬁnal software. This is a

restriction of the most general distributed execu-

tion. The restriction is speciﬁed by the software

expert guiding the transformation process.

The results of the incremental transformation phase is

a complete description of the business software to be

created, its modes and its functionality in the FSP for-

mat. This description is created in an internal format

on which transformations can be executed. The ﬁnal

executable business software is created by the follow-

ing compiler tools:

• Compile-into-subsystem,

• Compile-workﬂow-subsystem, and

• Compile-distributed-system.

Also the toolset comprises the static programming en-

vironments for SSu, ExW, and DS.

4.5 Status of the Implementation

The transformation environment is developed in the

TransBS project comprising tool developers and de-

velopers of business software products. Both, the de-

sign of the transformation process and environment

as well as the resulting business software modes, is

done incrementally with strong cooperation between

the different groups such that the ﬁnal tool will meet

the requirements for creating modern business soft-

ware. The design of the requirements of the resulting

transformed software is ﬁnished and the coarse struc-

ture of the transformation environment has been de-

veloped as described in this paper. The next step is to

implement the complete toolset and to conduct a large

scale validation using a complex business software

system provided by a participating software company.

Parts of the transformation process and runtime sys-

tems are currently being implemented. This includes

ICEIS 2007 - International Conference on Enterprise Information Systems

prototype versions of a transformation tool with upper

and lower level leading to a complete frame program

for parallel or distributed (sub)software, a workﬂow

management system for executing distributed work-

ﬂows speciﬁed in XPDL (for the ExW mode), and a

distributed runtime system for modular applications

in distributed environments. Another important issue

is the integration of those prototype versions which is

done concurrently with testing the resulting business

software systems created by the transformation pro-

cess. Feedback loops in the implementation process

will adapt the prototype versions and its integration.

Also, the structure of the transformation, select, ﬁlter,

create, and include functions has to be reﬁned to yield

a ﬂexible and interactive transformation environment.

5 CONCLUSIONS

We have proposed an interactive toolset to incremen-

tally transform existing monolithic business software

into a modular system that can be distributed and

workﬂow-based. This leads to a ﬂexible software sys-

tem that can be adapted to the characteristics of a spe-

ciﬁc environment and meets the needs of software de-

velopers and speciﬁc end user enterprises.

ACKNOWLEDGEMENTS

The research presented is funded by the German min-

istry BMBF 01 ISF 10 A/B/C.

REFERENCES

Akers, R., Baxter, I., and Mehlich, M. (2004). Re-

Engineering C++ Components Via Automatic Pro-

gram Transformation. In Proc. of ACM Symposium on

Partial Evaluation and Program Manipulation, pages

51–55. ACM Press.

Al-Ekram, R. and Kontogiannis, K. (2004). Source Code

Modularization Using Lattice of Concept Slices. In

Proc. of Euromicro Working Conference on Software

Maintenance and Reengineering (CSMR’04), pages

195–203.

Andritsos, P. and Tzerpos, V. (2003). Software Cluster-

ing based on Information Loss Minimization. In

Proc. of Working Conference on Reverse Engineering

(WCRE2003), pages 334–344.

Balmas, F. (2004). Displaying dependence graphs: a hi-

erarchical approach. J. of Software Maintenance and

Evolution: Research and Practice, 16(3):151–185.

Baxter, I., Pidgeon, C., and Mehlich, M. (2004). DMS: Pro-

gram Transformations for Practical Scalable Software

Evolution. In Proc. of the 26th Int. Conf. on Software

Engineering, pages 625–634. IEEE Press.

Bernstein, P. (1996). Middleware - A Model for Distributed

System Services. Commun. of the ACM, 39(2).

Brunner, R. and Weber, J. (2002). Java Web Services. Pren-

tice Hall.

Cao, F., Bryant, B., Burt, C., Raje, R., Olson, A., and

Auguston, M. (2005). A Component Assembly Ap-

proach Based On Aspect-Oriented Generative Do-

main Modeling. Electronic Notes in Theoretical Com-

puter Science, 114:119–136.

Crnkovic, I. and Larsson, M. (2002). Challenges of

component-based development. Journal of Systems

and Software, 61(3):201–212.

Czarnecki, K. and Eisenecker, U. (2000). Generative Pro-

gramming: Methods, Tools, and Applications. Addi-

son Wesley.

Emmerich, W. (2000). Engineering Distributed Objects.

John Wiley & Sons.

Emmerich, W. (2002). Distributed Component Technolo-

gies and their Software Engineering Implications. In

Proc. of Int.Conf.Software Engineering, pages 537–

546. ACM Press.

Kiczales, G., Lamping, J., A.Mendhekar, Maeda, C., Lopes,

C., Loingtier, J.-M., and Iwin, J. (1997). Aspect-

oriented programming. In Proc. Conf on Object-

Oriented Programming (ECOOP’01), LNCS 1241,

pages 327–353.

Lewandowski, S. (1998). Frameworks for component-

based client/server computing. ACM Comput. Surv.,

30(1):3–27.

Litoiu, M. (2004). Migrating to Web Services: a perfor-

mance engineering approach. Journal of Software

Maintenance and Evolution: Research and Practice,

16:51–70.

Lung, C. and Zaman, M. (2004). Applying Clustering Tech-

niques to Software Architecture Partitioning, Recov-

ery and Restructuring. Journal of Systems and Soft-

ware, 73(2):227–244.

Mehta, A. and Heineman, G. (2002). Evolving Legacy Sys-

tem Features into Fine-Grained Components. In Proc.

of Int. Conf. on Software Engineering, pages 417–427.

Menkhaus, G. and Frei, U. (2004). Legacy System Integra-

tion using a Grammar-based Transformation System.

CIT - Journal of Computing and Information Technol-

ogy, 12(2):95 – 102.

Siegel, J. (2005). Why use the Model Driven Architecture to

Design and Build Distributed Applications. In Proc. of

Int.Conf.Software Engineering, page 37. ACM Press.

Zhao, W., Bryant, B., Gray, J., Burt, C. C., Raje, R. R., Au-

guston, M., and Olson, A. (2003). A Generative and

Model Driven Framework for Automated Software

Product Generation. In Proc. 6th ICSE Workshop on

Component-Based Software Engineering: Automated

Reasoning and Prediction, pages 103–108.

TRANSFORMATION OF LEGACY BUSINESS SOFTWARE INTO CLIENT-SERVER ARCHITECTURES