Chester Clinic

 

Model-driven software migration

Model-Driven Software Migration Andreas Fuhr, Tassilo Horn University of Koblenz-Landau Carl von Ossietzky University Oldenburg Abstract: In this paper we propose model-driven techniques to migrate legacy systemsinto Service-Oriented Architectures (SOA). The proposal explores how querying andtransformation techniques on TGraphs enable the integration of legacy assets into anew SOA. The presented graph-based approach is applied to the identification andmigration of services in an open source Java software system.
Today, almost every company runs systems that have been implemented a long time agoand which are still adapted and maintained to meet current needs. Very often, adaptinglegacy software systems to new requirements also requires their migration to new tech-nologies. Migrating legacy systems, i. e. transferring software systems to new environ-ments without changing its functionality [SO08], enables already proven applications tostay on stream instead of passing away after some suspensive servicing [RB00].
A current technological advance promising better reusability of software assets is providedby Service-Oriented Architectures (SOA). SOA is viewed as an abstract, business-drivenapproach decomposing software into loosely-coupled services enabling the reuse of exist-ing software assets for rapidly changing business needs [GKMM04]. A service is viewedas an encapsulated, reusable and business-aligned asset coming with a well-defined servicespecification that provides an interface description of the functionality. The service spec-ification is implemented by a service component which is realized by a service provider.
Its functionality is used by service consumers [AGA+08].
Migrating legacy systems to services enables both, the reuse of already established andproven software components and the integration with newly created services, includingtheir orchestration to support changing business needs. The application of model-driventechniques to software migration, presented here, is part of the SOAMIG project1, whichaddresses the migration to Service-Oriented Architectures.
Software development and maintenance projects require a well-defined methodology. Ma-jor activities in software maintenance projects deal with legacy code. These include legacyanalysis, i.e. understanding legacy systems and identifying reusable software assets andlegacy conversion, i.e. migrating legacy assets. Current process models do not account forthese activities, although approaches to software migration (e.g. [BS95]) are known.
This paper focuses on applying model-driven techniques to migrating legacy assets toSOAs. IBM's SOMA method [AGA+08] provides a process model for SOA development 1SOAMIG is funded by the Ministry of Education and Research (01IS09017C) cf. www.soamig.de .
and evolution, which serves here as a methodological framework to identify and extendmigration activities and their technological support. Service-Oriented Modeling and Ar-chitecture (SOMA) includes seven incremental and iterative phases identifying, specifyingand implementing services. In the first place, SOMA is designed to develop SOAs fromscratch and does not provide support for integrating legacy assets.
The extension of SOMA towards migration, presented here, is based on model-drivenstrategies. Models represent different views on software systems including business pro-cess models, software architecture and programming code [WZ07]. Legacy analysis andconversion is based on queries and transformations on these models. In this paper, theTGraph Approach [ERW08] is applied as one possible model-driven technology. By mi-grating an exemplary service in the open source software GanttProject [Gan09], it will beshown how SOMA can be extended by model-driven technologies to provide a compre-hensive methodology to SOA development, including a broad reuse of legacy code assets.
The paper is organized as follows: Section 2 describes the SOMA method and motivateswhere SOMA can be extended by model-driven techniques. Section 3 introduces theTGraph Approach as one possible technological space. In Section 4, the integrated methodis applied to identify, specify, realize and implement one service by reusing GanttProject'slegacy code. Section 5 briefly contrasts the integrated SOA migration approach presentedhere with current work in model-driven software analysis and migration. Finally, Section 6summarizes and reflects the obtained results.
Service-Oriented Modeling and Architecture (SOMA) IBM's SOMA method [AGA+08] is an iterative and incremental approach to design andimplement service-oriented systems. It describes how to plan, design, implement anddeploy SOA systems. SOMA is designed to be extensible in order to make use of ad-ditional, specialized techniques supporting project-specific needs. The following subsec-tions shortly describe the seven SOMA phases and outline where they can be extendedtowards software migration.
Business Modeling: At the beginning of a project, the business is analyzed during this phase. Business goals and the business vision are identified, as well as business actors andbusiness use cases.
SOA migration does not require to extend Business Modeling.
Solution Management: This phase adapts SOMA to the project needs. This includes choosing additional techniques to solve project-specific problems.
SOA migration requires to extend Solution Management: Customizing SOMA for migra-tion requires the application of reengineering and migration techniques as depicted in thereminder.
Service Identification: In this phase, SOMA uses three complementary techniques to identify service candidates, i. e. functionality that forms a service.
Domain Decomposition is a top-down method decomposing the business domain intofunctional areas and analyzing the business processes to identify service candidates. Goal-Service Modeling identifies service candidates by exploring the business goals and sub- goals. Legacy Asset Analysis finally explores the functionality of legacy systems. Docu-mentation, APIs or interfaces are analyzed to identify service candidates. The source codeis only analyzed coarse-grained. It is merely evaluated which functionality exists and notwhich components manifest the function. All three techniques are performed incremen-tally and iteratively. For each identified candidate, an initial service specification is createdand a trace to the source of identification is established.
SOA migration requires to extend Service Identification: SOMA does not describe how toanalyze legacy systems. In Section 4.3, we extend SOMA by reverse-engineering legacycode, which enables model-driven queries and transformations to identify service candi-dates including their code base.
Service Specification: This phase deals with describing the service design in detail.
The initial service specification is refined, messages and message flows are designed andservices are composed. This phase results in a comprehensive description of the servicedesign. SOMA uses an UML profile for SOAs to describe the service design. Later,the service specification will be transformed into WSDL code in order to implement theservice as a Web Service as is proposed by SOMA.
SOA migration requires to extend Service Specification: To gather the information neededfor the service design, messages and message parameters can be derived from legacy code.
We extend SOMA by queries to support design decisions in Section 4.4.
Service Realization: In this phase, it is decided which services will be implemented in the current iteration and it is constituted how to implement them.
After having chosen a set of services, the implementation strategy must be defined. En-capsulation of services allows to choose different ways to implement each service. Com-mon strategies to form new service components include (1) implementation from scratch,(2) wrapping of legacy components or (3) transforming the required legacy components.
In SOMA, legacy functions are usually wrapped and then exposed as services. This hasseveral drawbacks. The legacy system still requires maintenance, the wrapper needs to becreated and requires maintenance during further evolution. Transforming the legacy codeavoids this wrapping trap but requires appropriate transformation means. After decidingon transformation as implementation technique, legacy systems must be analyzed fine-grained. Functionality that is able to implement services has to be identified in the legacycode. In addition, it is important to clearly understand how this functionality is embeddedin the legacy system, since it has to be separated to build a self-contained service.
SOA migration requires to extend Service Realization: SOMA does not consider how toimplement services by reusing legacy code. In Section 4.5, a model-driven technique ispresented to analyze legacy systems fine-grained in order to understand the implementa-tion of legacy functionality.
Service Implementation: During Service Implementation, services are actually real- ized. According to the decisions derived in the Service Realization phase, services aredeveloped, wrappers are written or legacy code is transformed. Finally, all services areorchestrated and message flows are established.
SOA migration requires to extend Service Implementation: SOMA does not include tech- niques to transform legacy code into services. In Section 4.6 it is shown how transforma-tions are used to transform legacy code into service implementations.
Service Deployment: The final phase of SOMA is Service Deployment. It deals with exposing services to the customer's environment. Final user-acceptance tests are executedand the SOA is monitored to verify that it performs as expected.
SOA migration does not require extensions of Service Deployment.
Concluding, five phases (solution management, identification, specification, realizationand implementation) have been identified where SOMA must be extended to support mi-gration of legacy systems into SOAs. The next section will describe which role model-driven development does play in extending SOMA. In Section 4, the extended SOMAmethod is exemplarily applied to the migration of an example Java application.
Model-Driven Development in Software Migration Migrating legacy systems demands an integrated view on legacy code, software architec-ture and business processes [WZ07] to be able to identify and extract services. Therefore,an integrated representation of all these artifacts is essential. Model-driven approachesprovide these technologies: (a) representation of models (metamodels), (b) querying mod-els (query languages) and (c) transforming models (transformation languages).
Today, many model-driven approaches are known. Metamodels can be described by usingthe OMG's Meta Object Facility (MOF [OMG06]) or INRIA's KM3 [Ecl07]. Well-knowntransformation languages include QVT (Query/View/Transformation [OMG07]) or ATL(Atlas Transformation Language [ATL09]). All these approaches are suited for extendingSOMA. However, in this paper, a graph-based approach is used which has already beenapplied in various reverse- and reengineering projects [ERW08].
The TGraph Approach is a seamless graph-based approach. Models are represented bygraphs conforming to a graph schema (a metamodel). They can be queried with the graphquery language GReQL (Graph Repository Querying Language [BE08]) and can be trans-formed using GReTL (Graph Repository Transformation Language [EH09]).
TGraphs are typed, attributed, directed and ordered graphs. Thus, they are based on ageneral graph model which allows appropriate tailoring for certain modeling purposes.
In contrast to object-oriented modeling, edges are viewed as first-class objects. Hence,they can have attributes and traversal is always bidirectional. An API for accessing andmanipulating TGraphs is given by the graph library JGraLab2.
GReQL is a declarative graph query language and an enabling technology in reengineering,since various analyses of legacy systems can be mapped to graph queries [KW98]. One ofGReQL's especially powerful features are regular path expressions which can be used toformulate queries that utilize the structure of interconnections between nodes and whichsupport transitive closure.
GReTL is a Java framework for programming transformations on TGraphs making heavyuse of GReQL to specify the mappings from source to target elements.
All these technologies are applied in Section 4 to identify, to extract and to migrate aservice candidate of a Java example application within the SOMA methodology.
Extending SOMA by Model-Driven Techniques The previous sections motivated the need of extending SOMA to enable the reuse of legacysoftware assets in software migration and shortly presented the TGraph approach. Ourapproach extends SOMA by applying model-driven techniques when appropriate.
Picking up the structure of introducing the SOMA phases in Section 2, the integratedapproach is applied to the migration of one functionality of GanttProject into a Service-Oriented Architecture [Fuh09, HFW09]. GanttProject [Gan09] is a project planning tool.
It manages project resources and displays project schedules as Gantt charts. GanttProjectis implemented by about 1200 classes. The required migration is exemplified by identify-ing and migrating a service to manage project resources by transforming the appropriatelegacy code.
Business Modeling SOMA's first phase analyzes the current business situation. In this paper we focus on anal-ysis and reuse of legacy software. Business modeling is not considered in detail, althoughit is important to analyze legacy business processes and to define processes to be supportedby the SOA. Here, it is assumed that the business process of managing project resourcesshall be realized by the new SOA and its implementation will rely on GanttProject.
Solution Management Solution Management adapts the SOMA method to the current project needs. SinceGanttProject is a Java system, a TGraph representation for Java systems is required. OurJava 6 metamodel contains about 90 vertex and 160 edge types and covers the completeJava syntax. The GanttProject sources are parsed according to that metamodel, resultingin a graph of 274.959 nodes and 552.634 edges. This graph and the implicit knowledge onresource management, provide the foundation for service identification, service specifica-tion, service realization and service implementation.
Service Identification The identification of services from legacy systems requires coarse-grained analysis. Firstly,the graphical user interface of GanttProject is explored and functionality to manage projectresources is identified as one main feature of the software. Analyzing the GUI is only oneentry point for identifying functionality and could be extended by additional explorations(e.g. test cases or documentation). Quickly scanning the legacy code then detects func-tionality providing the management of project resources.
Identifying pieces of functionality in legacy code is a challenging task and still an open re-search issue [KLS+07]. GReQL queries are used to identify functionality in the graph rep-resentation and corresponding GReTL transformations visualize the query result. String search is used to detect possible code areas referring to "resources". Further interconnec-tions of code objects are specified by declarative path expressions. The resulting subgraphis transformed by GReTL into a TGraph conforming to a simple UML schema. FurtherXMI-based filters (cf. [EW06]) might be used to render these structures in UML tools.
" from t : V { Type } with t . name = " . ∗ [ Rr ] esource . ∗ " r e p o r t S e t t end " ) ;
" from t : keySet ( img_uml$Class ) reportMap t , t . name end " ) ;
createEdgeClass ( " uml . A s s o c i a t i o n " , umlClass , umlClass , " from c : keySet ( img_uml$Class ) , c2 : keySet ( img_uml$Class ) "
+ " with c <−−{I s B l o c k O f } <−−{IsMemberOf } <−−{ I s B r e a k T a r g e t O f , "
+ " r e p o r t S e t c , c2 end " ,
" from t : $ reportMap t ,
f i r s t ( t ) end " , " from t : $$ reportMap t , second ( t ) end " ) ;
createEdgeClass ( " uml . IsA " , umlClass , umlClass , " from c : keySet ( img_uml$Class ) , c2 : keySet ( img_uml$Class ) "
+ " r e p o r t S e t c , c2 end " ,
" from t : $ reportMap t ,
f i r s t ( t ) end " , " from t : $$ reportMap t , second ( t ) end " ) ;
Listing 1: GReTL transformation from Java to UML Listing 1 shows a GReTL transformation supporting coarse-grained legacy code analysis.
For each legacy class or interface containing "resource" in the name, the transformationcreates an UML-class node in the target TGraph (lines 1–4). In addition, associations aredrawn between those class nodes whenever one node uses (e. g. by method calls or variabletypes) another node (5–11). Inheritance is visualized by "IsA" edges (12–17). These edgescan be indirect relations since GReQL path expressions consider transitive closure. Thetransitive path expression in lines 7–9 (the part with ∗) matches indirect relations betweenclasses. The visualized result of this GReTL transformation is shown in Figure 1a.
Looking at the result, the class HumanResourceManager implementing the interface Re-sourceManager is identified as functionality to manage project resources. Based on thisinformation, an initial service specification for the service candidate IResourceManageris created and traces to the legacy code are noted (Figure 1b). Initial service operationsfor the new service are derived from the legacy interface. Only the needed functionalityis transfered into the design. In this phase, no further information about the method sig-natures of the initial service specification is gathered. The following SOMA phases willspecify the service in more detail.
Service Specification Service Specification refines the IResourceManager service specification. A service pro-vider component is created which will later implement the service specification.
In addition, message flows are created to enable communication with the service. Formethod parameters in the legacy interface, request messages are created that are passed + add ( )+ getById ( )+ remove ( )+ getResources ( ) isAbstract = false + getResourcesArray ( ) name = "HumanResourceManager" «Java Interface» + create(String, int) : ProjectResource isAbstract = false isAbstract = true name = "HumanResource" name = "ResourceManager" + add(ProjectResource) : void + getById(int) : ProjectResource + remove(ProjectResource) : void + remove(ProjectResource, GPUndoManager) : void + getResources() : List + getResourcesArray() : ProjectResource[] + save(OutputStream) : void isAbstract = false isAbstract = false + addView(ResourceView) : void name = "ResourceAssignmentImpl" name = "ProjectResource" + importData(ResourceManager) : Map + getCustomPropertyManager() : CustomPropertyManager (a) Visualization of classes and interfaces possibly (b) IResourceManager service identified from providing functionality to manage resources legacy source code Figure 1: Service Identification results to the service. For return types in the legacy system, response messages are defined thatwill be returned by the new service. Request and response messages can be derived fromlegacy code.
Listing 2 shows a GReQL query taking an interface or class name as input and returningmethod parameters (lines 2–5) and return types (lines 6–9) as output. This information isused to derive message parameter types from legacy code.
l e t classname : = " HumanResourceManager " i n tup (
with hrmClass . name = classname and hrmClass <−−{I s C l a s s B l o c k O f }<−−{IsMemberOf }
<−−{IsParameterOfMethod } <−−{IsTypeOfParameter } [<−−{ IsTypeDefOf } ] usedType r e p o r t S e t ( hasType ( usedType , " B u i l t I n T y p e " ) ) ?
usedType . t y p e : theElement ( usedType<−−&{ I d e n t i f i e r } ) . name end ,
with hrmClass . name = classname and hrmClass <−−{I s C l a s s B l o c k O f } <−−{IsMemberOf }
<−−{IsReturnTypeOf } [<−−{ IsTypeDefOf } ] usedType r e p o r t S e t ( hasType ( usedType , " B u i l t I n T y p e " ) ) ?
usedType . t y p e : theElement ( usedType<−−&{ I d e n t i f i e r } ) . name end )
Listing 2: GReQL query retrieving method parameters and return types The result of the specification phase is shown in the class diagram in Figure 2. The ser-vice specification now contains information about parameters (They are hidden in the Re-sourceManagerProvider component since they are already shown in the service specifi-cation). In addition, request and response messages are defined and one parameter type(HumanResourceType) for these messages is derived from legacy code.
+ add ( resource : ResourceManagerRequest ) : Boolean + getById ( id : Integer ) : ResourceManagerResponse + remove ( resource : ResourceManagerRequest ) : Boolean + getResources ( ) : ResourceManagerResponse + getResources ( ) «Java Interface» - resource : HumanResourceType - resources : HumanResourceType [*] Figure 2: Detailed design of IResourceManager service At the end of this phase, the design of the service itself is mostly completed. The next stepwill be to decide how the service should be implemented.
Service Realization The first decision to make during Service Realization is how to implement the IResource-Manager service. Model transformation approaches are also suited for code transforma-tion. Thus, in this paper, the legacy code is transformed into a service implementationto provide the business functionality. If service realization by wrapping would have beendecided on, wrappers could be generated analogously.
Service Identification has already identified one class in the legacy code that may providefunctionality to the IResourceManager service: the class HumanResourceManager (short:HRM). The complete but minimal code realizing this functionality has to be determinedand extracted, including all of the HRM dependencies. These include • HRM calls methods of other classes (HRM →calls method →isMemberO f class),• variables, parameters or return types (e.g. HRM →de fines variable →hasAsType class),• inheritance hierarchy (HRM →specializes class or HRM →implements interface).
Listing 3 describes the GReQL query retrieving these dependencies. The core part of thequery is the path expression in lines 4–9, defining how a dependency relation betweencaller and callee looks like in the Java metamodel. The query returns a list of all classesand interfaces that HRM depends on. In this example, only the directly related classes areretrieved. However, GReQL could retrieve the transitive closure of dependencies analo-gously. Figure 3a shows a (manually created) visualization of the query result.
Next, the business functionality must be integrated into the overall service design. This isdone according to patterns proposed by Wahli [Wah07].
Figure 3b shows the application of these patterns to create a framework to integrate thelegacy code which will be transformed in the next phase. The service component Re-sourceManagerSC implements the service specification. A facade pattern is used to im- with hrmClass . name = " HumanResourceManager "
and hrmClass <−−{I s C l a s s B l o c k O f } <−−{IsMemberOf } hrmMethod
and ( hrmMethod ((<−−{ IsBodyOfMethod } <−−{IsStatementOfBody } <−−{ ReverseEdge } ∗
) (<−−{IsParameterOfMethod } <−−{IsTypeOf } + <−−{IsTypeDefOf } ) (<−−{IsBodyOfMethod } <−−{IsStatementOfBody } <−−{ ReverseEdge } ∗ <−−{I s T y p e O f V a r i a b l e } <−−{IsTypeDefOf } ) (<−−{ IsReturnTypeOf } <−−{IsTypeDefOf } ) ) usedType or hrmClass ((<−−{ I s C l a s s B l o c k O f }<−−{IsMemberOf}<−−{ I s F i e l d C r e a t i o n O f }
<−−{I s T y p e O f V a r i a b l e } <−−{IsTypeDefOf } ) ((<−−{ I s C l a s s B l o c k O f } <−−{IsMemberOf } ) + ) ) usedType ) r e p o r t S e t usedType end
Listing 3: GReQL query retrieving dependencies + add ( resource : ResourceManagerRequest ) : Boolean + getById ( id : Integer ) : ResourceManagerResponse + remove ( resource : ResourceManagerRequest ) : Boolean «Java Interface» + getResources ( ) : ResourceManagerResponse «Java Interface» + getResources ( ) «Java Interface» + add ( resource : ResourceManagerRequest ) : Boolean + getById ( id : Integer ) : ResourceManagerResponse + remove ( resource : ResourceManagerRequest ) : Boolean «Java Interface» + getResources ( ) : ResourceManagerResponse «Java Interface» «Java Interface» - humanResourceManager «Java Interface» «Java Interface» (a) Dependencies of legacy HRM class (b) Implementation design of IResourceManager Figure 3: Service Realization: Designing the service implementation plement the service component. The facade class will delegate service requests to theappropriate service implementation — in this example the HRM class and all its depen-dencies revealed by the GReQL query.
This phase finishes the design of the service. In the next step, this design will be imple-mented.
Service Implementation Service Implementation realizes the IResourceManager service, e. g. as Web Service (assuggested by SOMA). Migrating identified source code (cf. Section 4.5) to realize theresource management service combines functionality provided by the IBM Rational Soft-ware Architect for WebSphere Software V7.53 (RSA) and TGraph technology.
Firstly, the code generation capabilities of the RSA are used to create WSDL code fromthe service specification which is later used to specify the service interface. Then, thedesign of the service framework (Figure 3b) is transformed into Java.
3IBM, Rational and WebSphere are trademarks of International Business Machines Corporation.
So far, the service lacks of business functionality, which is added by transforming legacycode into a service implementation. The GReQL query described in Listing 3 (Section 4.5)is used to mark the HRM class and all legacy software components it depends on.
The Java code generator of JGraLab is used to extract Java code for all marked classes ofthe TGraph. This results in Java classes implementing only the business functionality ofthe IResourceManager service. These classes are not connected to the service frameworkcurrently and so the facade class must be edited manually to delegate service requests tothe HRM class. In addition, the facade class translates message parameters into objectsknown by the HRM class.
Finally, the Web Service Wizard of RSA is used to generate a fully functional Web Ser-vice. This wizard takes the WSDL interface description, the Java classes of the serviceframework and the service implementation and creates a Java EE Web Service.
Service Deployment The Web Service created in the last subsection is deployed to the customer. This phasedoes not have to be extended by our approach. It concludes the migration.
Whereas a plethora on publication on the development of Service-Oriented Architecturesexists, migrating legacy systems to SOA is only addressed in a few papers. The SMARTapproach [Smi07] deals with the planning of SOA migration projects, but does not provideconcrete migration or migration tool support. Correia et al. [CMHER07] and Fleurey et al.
[FBB+07] describe general approaches of model-driven migration into a new technologynot especially focused on SOA. Correia et al. describe a graph-based approach which men-tions SOA as possible target architecture [Mat08]. In contrast to SOAMIG, this approachfocuses on annotating functionality in legacy code instead of directly identifying servicesfrom source code. Marchetto and Ricca [MR08] propose an approach to migrate legacysystems into a SOA, step by step. However, this approach does not focus on model-driventechniques and uses wrapping as general migration strategy. Another approach focusingon wrapping is described in [Gim07].
In contrast to these approaches, the work presented here provides a coherent model-drivenapproach to software migration by integrating an established SOA forward-engineeringapproach with graph-based reengineering technologies. In addition, in SOAMIG softwaresystems are viewed at all levels of abstraction including business processes and code.
Conclusion and Future Work In this paper, we described a model-driven approach to migrate legacy systems, extendingIBM's SOMA method. The approach was applied to the migration of a functionality ofGanttProject towards a Service-Oriented Architecture. This example demonstrated theidentification and specification of services by analyzing legacy code, the identificationof responsible functionality in legacy code and the transformation of legacy code into aservice implementation. As result, a fully functional Web Service was generated whose business functionality was implemented by transforming legacy code.
The example presented in this paper should be understood as first technical proof-of-concept and not as fully developed method. The approach must be extended and thetechniques must be improved. E.g. one issue is the replacement of the string-based ser-vice identification technique (which fails when source code does not follow some namingconventions) by a dynamic approach. As part of the SOAMIG project, we are currentlyexploring the possibility of simulating the execution of business processes while tracingsource code execution. Based on these traces, source code might be mapped to processes,supporting service identification.
Another issue is the application of the approach on systems that are not written in Java.
In addition to plain architectural migrations as presented in this example, languages (e.g.
COBOL → Java) must be migrated in language migration projects, too. All TGraph tech-niques explained in this paper are generic and will work for other languages if metamodelsare provided. Currently, a metamodel for COBOL is being developed and will enable ourapproach to cope with legacy COBOL systems as soon as it is finished. Research will alsoaddress code transformation based on these metamodels.
In contrast to "transformation capabilities" of modern tools like IBM's Rational SoftwareArchitect or Borland's Together Architect, the TGraph approach offers an integrated viewon all models and allows to process all needed queries on one repository. This will allowus to create one homogeneous workflow instead of handling different types of results fromdifferent sources leading to compatibility issues.
The results of this ongoing research will have to be confirmed on larger examples in future.
In collaboration with our industrial project partners, their Java and COBOL systems willbe migrated into Service-Oriented Architectures.
Summarizing, the presented approach already showed first interesting results and promisesto improve model-driven migration in future.
We want to express our thanks to Rainer Gimnich, IBM Software Group, Frankfurt/Main,Germany for his support in understanding SOMA and various fruitful discussions on ap-plying SOMA in software migration.
A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy, and K. Holley.
SOMA: A Method for Developing Service-Oriented Solutions. IBM Systems Jour-nal, 47(3):377–396, 2008.
ATLAS Group. ATL User Guide, 2009.
D. Bildhauer and J. Ebert. Querying Software Abstraction Graphs. In Working Sessionon Query Technologies and Applications for Program Comprehension, 2008.
M. L. Brodie and M. Stonebraker. Migrating Legacy Systems, Gateways, Interfaces& The Incremental Approach. Morgan Kaufmann, 1995.
[CMHER07] R. Correia, C. Matos, R. Heckel, and M. El-Ramly. Architecture Migration Driven by Code Categorization. In Software Architecture, First European Conference, Spain: Proceedings, volume 4758 of Lecture Notes in Computer Science. Springer, 2007.
Eclipse. KM3. http://wiki.eclipse.org/KM3, 2007.
J. Ebert and T. Horn. The GReTL Transformation Language. Projectreport, Koblenz,2009.
J. Ebert, V. Riediger, and A. Winter. Graph Technology in Reverse Engineering: TheTGraph Approach. In R. Gimnich, U. Kaiser, J. Quante, and A. Winter, editors, 10thWorkshop Software Reengineering, volume 126 of GI-Edition Proceedings, pages67–81, Bonn, 2008. Ges. f. Informatik.
J. Ebert and A. Winter. Using Metamodels in Service Interoperability. In Postproceed-ings of 13th Annual International Workshop on Software Technology and EngineeringPractice (STEP'05), pages 147–156, 2006.
F. Fleurey, E. Breton, B. Baudry, A. Nicolas, and J. M. Jezequel. Model-drivenEngineering for Software Migration in a Large Industrial Context. In G. Engels,B. Opdyke, D. C. Schmidt, and F. Weil, editors, Model Driven Engineering Languagesand Systems, volume 4735 of International Conference on Model Driven EngineeringLanguages and Systems, pages 482–497, Berlin, 2007. Springer.
Model-driven Software Migration into a Service-oriented Architecture.
Bachelorthesis, Mainz, 2009.
GanttProject. The GanttProject. http://ganttproject.biz/, 2009.
R. Gimnich. SOA Migration: Approaches and Experience. Softwaretechnik-Trends,27(1), 2007.
[GKMM04] N. Gold, C. Knight, A. Mohan, and M. Munro. Understanding Service-Oriented Soft- ware. IEEE Software, 21(2):71–77, 2004.
T. Horn, A. Fuhr, and A. Winter. Towards Applying Model-Transformations and-Queries for SOA-Migration. In Workshop MDD, SOA und IT-Management, 2009.
K. Kontogiannis, G. A. Lewis, D. B. Smith, M. Litoiu, H. Müller, S. Schuster, andE. Stroulia. The Landscape of Service-Oriented Systems: A Research Perspective. InProceedings of the International Workshop on Systems Development in SOA Environ-ments. IEEE Computer Society, 2007.
B. Kullbach and A. Winter. Querying as an Enabling Technology in Software Reengi-neering. In Proceedings of the 3nd European Conference on Software Maintenanceand Reengineering, pages 42–50. IEEE Computer Society, Los Alamitos, 1998.
C. Matos. Service Extraction from Legacy Systems. In D. Hutchison, H. Ehrig,R. Heckel, T. Kanade, and J. Kittler, editors, Graph Transformations, volume 5214,pages 505–507, Berlin, Heidelberg, 2008. Springer-Verlag.
A. Marchetto and F. Ricca. Transforming a Java Application in a Equivalent Web-Services Based Application: Toward a Tool Supported Stepwise Approach. In Pro-ceedings Tenth IEEE International Symposium on Web Site Evolution, Beijing, China(WSE). IEEE Computer Society, 2008.
OMG. Meta Object Facility (MOF) 2.0: Core Specification – formal/06-01-01, 2006.
OMG. Meta Object Facility (MOF) 2.0: Query/View/Transformation Specification –Final Adopted Specification ptc/07-07-07, 2007.
V. T. Rajlich and K. H. Bennett. A Staged Model for the Software Life Cycle. Com-puter, 33(7):66–71, 2000.
D. B. Smith. Migration of Legacy Assets to Service-Oriented Architecture Environ-ments. In Companion to the proceedings of the 29th International Conference onSoftware Engineering, pages 174–175. IEEE Computer Society, 2007.
H. M. Sneed and S. Opferkuch. Training and Certifying Software Maintainers. In 12thEuropean Conference on Software Maintenance and Reengineering (CSMR), Athens,Greece, pages 113–122. IEEE Computer Society, 2008.
U. Wahli. Building SOA Solutions Using the Rational SDP. IBM Redbooks. 2007.
A. Winter and J. Ziemann. Model-based Migration to Service-oriented Architectures:A Project Outline. In H. M. Sneed, editor, CSMR 2007, 11th European Conferenceon Software Maintenance and Reengineering, Workshops, pages 107–110, 2007.

Source: http://www.se.uni-oldenburg.de/documents/fuhr+2010.pdf