Model-Driven software modernization: concept-based engineering of situation-specific methods / Marvin Grieger [erster Gutachter: Engels, Gregor; zweiter Gutachter: Ebert, Jürgen ...]

Model-Driven Software Modernization Concept-Based Engineering of Situation-Specific Methods Marvin Grieger Faculty of Computer Science, Electrical Engineering and Mathematics Paderborn University Dissertation submitted in partial fulfillment of the requirements for the degree of Doktor der Naturwissenschaften (Dr. rer. nat.) May 2016 Abstract During a software modernization project, a legacy system is transferred into and adapted to a new environment. A transformation method guides this endeavor by prescribing activities to perform or artifacts to generate in order to realize the transition. Thereby, the method used needs to fit to the situation at hand by considering conceptual differences between source and target environment and by automating parts of the transformation whenever suitable. Otherwise, a decreased software quality or increased effort to perform the transformation may result. Although various method engineering approaches have been proposed to support the development of transformation methods, most of them do not provide sufficient flexibility in the development or fall short in guiding the endeavor. In this thesis, we address this problem by introducing a situational method engineering framework to guide the development of situation-specific transformation methods. The framework uses a method base that contains reusable building blocks of transformation methods, based on principles from the domain of model-driven engineering. The development of a method is centered around the identification of concepts within a legacy system that represent its functionality by abstracting from the technology-specific realization. Selecting predefined, model-driven transformation strategies for each concept enables assembling transformation methods that are well-suited for a software modernization scenario. Zusammenfassung In einem Softwaremodernisierungsprojekt wird ein Altsystem in eine neue Umgebung überführt und an diese angepasst. Eine Transformationsmethode leitet dieses Unterfangen an, indem sie auszuführende Aktivitäten oder zu generierende Artefakte beschreibt. Dabei muss die Methode an die Projektsituation angepasst sein, indem sie konzeptionelle Unterschiede zwischen der Quellund Zielumgebung berücksichtigt und eine Automatisierung ermöglicht. Eine nicht angepasste Methode kann eine verringerte Qualität des resultierenden Systems oder einen erhöhten Aufwand für die Transformation zur Folge haben. Bestehende Ansätze zur Erstellung von Transformationsmethoden stellen entweder eine zu geringe Flexibilität in der Entwicklung bereit oder leiten diese nicht ausreichend an. In dieser Arbeit adressieren wir dieses Problem durch die Definition eines Frameworks zur Erstellung situationsspezifischer Transformationsmethoden. Dazu nutzt das Framework eine Methodenbasis, welche wiederverwendbare Bausteine von Transformationsmethoden basierend auf Prinzipen der modellgetriebenen Entwicklung beinhaltet. Im Mittelpunkt der Methodenentwicklung steht die Identifikation von Konzepten innerhalb eines Altsystems, welche dessen Funktionalität repräsentieren und von der technologiespezifischen Realisierung abstrahieren. Die Auswahl von vordefinierten, modellgetriebenen Transformationsstrategien für jedes Konzept ermöglicht den systematischen Aufbau einer Methode für die Modernisierung eines Systems. Danksagung Ich möchte mich zu allererst bei den vielen Personen bedanken, die direkten oder indirekten Einfluss auf die Entstehung dieser Arbeit hatten. Ohne sie wäre diese Arbeit in dieser Form nicht möglich gewesen. Allen voran möchte ich meinem Doktorvater Prof. Dr. Gregor Engels danken. Durch seine intensive wissenschaftliche Betreuung über die Jahre, die vielen Ratschläge, Diskussionen und Denkanstöße hat er die Arbeit maßgeblich geprägt. Gleichzeitig hat sein Auge für das Detail und die Fähigkeit, komplexe Dinge auf das Wesentliche reduzieren zu können, meine Denkweise nachhaltig geprägt. Danken möchte ich auch Dr. Stefan Sauer und Prof. Dr. Jürgen Ebert für die Diskussionen über die Arbeit und für ihre Funktionen in der Promotionskommission. Die Ausarbeitung einer solchen Arbeit ist ein mehrjähriges, anstrengendes Unterfangen. Ich hatte das Glück, während dieser Zeit fortwährende Unterstützung durch meine Familie zu erfahren. Vor allem durch meine kleine Familie, meiner Frau Stefanie und unserer Tochter Marie. Steffi hat die ganze Zeit über zu mir gehalten, mich motiviert und mir Rückhalt gegeben, dafür möchte ich ihr von ganzem Herzen danken. Ein genauso großer Dank geht auch an meine Eltern, Sabine und Ralf. Sie haben mich zu dem gemacht, der ich heute bin und stehen mir immer mit Rat und Tat zur Seite. Dafür danke ich ihnen zutiefst. Ebenso möchte ich meiner Lieblingsschwester Danika und ihrem Mann Jan für die immerwährende Unterstützung danken. Ohne meinen Onkel, Klaus Sonnemann, wäre diese Arbeit vielleicht niemals zu Stande gekommen. Er hat damals einen der Grundsteine für mein Studium gelegt, wofür ich ihm dankbar bin. Diese Arbeit wurde in vielen Diskussionen geschärft, wobei einige Personen besonders hervorzuheben sind. Mit Markus Klenke konnte ich einige Jahre in einem industriellen Kontext eng zusammenarbeiten. Er hat wesentlich dazu beigetragen, die Kernidee dieser Arbeit auszuarbeiten und umzusetzen, wofür ich dankbar bin. Genauso möchte ich Svetlana Arifulina und Masud Fazal-Baqaie danken, für die vielen Diskussionen, die Unterstützung und gegenseitige Motivation. Danken möchte ich auch meinem langjährigen Bürokollegen Barı¸s Güldali, insbesondere für die Einführung in den wissenschaftlichen Kontext. Ich habe das Arbeitsklima in der AG Engels immer als sehr gut empfunden, weshalb ich nicht zuletzt allen meinen Kollegen danken möchte. Table of Contents List of Figures xiii List of Tables xvii I Foundations and Related Work 1 1 Introduction 3 1.1 Software Transformation Methods . . . . . . . . . . . . . . . . . . . . . . . 6 1.2 ProblemStatement ............................... 9 1.3 Requirements.................................. 11 1.4 SolutionConcept ................................ 12 1.5 Overview of Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.6 StructureofthisThesis............................. 15 2 Foundations 17 2.1 Model-Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1 Meta-Object Facility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.2 Model-Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.3 Architecture-Driven Modernization . . . . . . . . . . . . . . . . . . 20 2.2 MethodEngineering .............................. 22 2.2.1 Situational Method Engineering . . . . . . . . . . . . . . . . . . . . 23 2.2.2 Software and Systems Process Engineering Metamodel . . . . . . . . 24 2.2.3 Metamodeling Layers . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3 SoftwareReengineering............................. 26 2.3.1 Software Migration, Transformation & Modernization . . . . . . . . 27 2.3.2 Compiler ................................ 29 2.3.3 Programming Paradigms . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3.4 ConceptModeling ........................... 32 xvi List of Figures 6.21 Integrating a fragmented transformation method specification . . . . . . . . . 174 6.22 Integrated horseshoe model showing method fragments for the table-based view, attribute calculation and view relation concept, specified in MIML . . . 176 6.23 Transformation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 6.24 Instantiation of tool implementation phase fragments . . . . . . . . . . . . . 179 6.25 Tool implementation process and model transformation rules definition process 180 6.26 Excerpt of SPEM-based transformation method specification that defines a method to transform the running example . . . . . . . . . . . . . . . . . . . 183 7.1 Real estate management legacy system in the source environment, the transformed system in the target environment . . . . . . . . . . . . . . . . . . . . 192 7.2 Configured concept model for the real estate management legacy system . . . 194 7.3 Legacy and target realization of the dialog flow concept . . . . . . . . . . . . 195 7.4 Integrated horseshoe model of the real estate management system for the dialog, dialog flow and business module concepts . . . . . . . . . . . . . . . . . . . 198 7.5 Architecture of the generic tool infrastructure . . . . . . . . . . . . . . . . . 199 7.6 Henshin model transformation rule to extract flows between dialogs . . . . . 200 7.7 Enacting a transformation method to transform the dialog, dialog flow and business module concepts of the real estate management legacy system . . . . 202 7.8 Result of a semi-automatic architectural restructuring of the real estate management legacy system by clustering related business modules . . . . . . . . 203 7.9 Effort for transforming the real estate management legacy system, amount of feedback exchanged between involved roles . . . . . . . . . . . . . . . . . . 204 7.10 Legacy report in the development environment of the source environment, transformed report in the development environment of the target environment 206 7.11 Configured concept model for the reports legacy system . . . . . . . . . . . . 208 7.12 Legacy and target realization of the report layout and element concepts . . . . 209 7.13 Integrated horseshoe model for the report layout and report element concepts 211 7.14 Enacting a transformation method to transform the report layout and element concepts of the legacy report . . . . . . . . . . . . . . . . . . . . . . . . . . 213 B.1 Overview of the method enactment process of MEFiSTo . . . . . . . . . . . 245 B.2 Overview of the method development process of MEFiSTo . . . . . . . . . . 246 List of Tables 3.1 Evaluation of selected method engineering approaches against requirements . 46 5.1 Schema to characterize method patterns . . . . . . . . . . . . . . . . . . . . 71 5.2 Language transformation pattern characteristics . . . . . . . . . . . . . . . . 81 5.3 Conceptual transformation pattern characteristics . . . . . . . . . . . . . . . 93 5.4 Reimplementation pattern characteristics . . . . . . . . . . . . . . . . . . . . 102 5.5 Code removal pattern characteristics . . . . . . . . . . . . . . . . . . . . . . 108 5.6 Platform-dependent architecture restructuring pattern characteristics . . . . . 113 5.7 Language transformation-based reimplementation pattern characteristics . . . 122 5.8 Concept recognition-based language transformation pattern characteristics . . 129 6.1 Transferring principles from the domain of architectural design decisions to thedomainofMEFiSTo ............................ 155 6.2 Operations for the integration of method fragments that originate from different method pattern applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 A.1 Concept recognition-based reimplementation pattern characteristics . . . . . 240 A.2 Concept recognition and language transformation-based reimplementation patterncharacteristics.............................. 242 A.3 Platform-dependent architecture restructuring pattern characteristics . . . . . 243 A.4 Architecture restructuring pattern characteristics . . . . . . . . . . . . . . . . 244 “The beginning is the most important part of the work.” – PLATO PART I FOUNDATIONS AND RELATED WORK CHAPTER 1 Introduction Information systems have become a critical asset for most companies as daily business often depends on them. Each system has a lifecycle consisting of multiple stages, as illustrated in Figure 1.1. After a system has been developed initially, it automatically enters the Evolution stage [MD08, pp.1-3]. In this stage, it is feasible to modify the system in order to remove bugs, improve non-functional characteristics or change its functionality due to changed requirements. Just as anything else, information systems are aging over time. This aging process can have various effects on the system like its architectural integrity becoming violated, its documentation becoming outdated or its technological environment becoming obsolete. In each case, the aging process ultimately results in the loss of evolvability, preventing the modification of the information system to meet new or changed requirements. If the system is still valuable for ongoing business, it has become a legacy system. Initial development Evolution Servicing Phaseout Closedown First running version Loss of evolvability Servicing discontinued Switchoff Servicing patches Evolution changes Transition Lifecycle Stage Figure 1.1 Staged software lifecycle [RB00] As information systems becoming legacy is an established problem, four different solutions have emerged in practice [SWH10, pp.7-9]. The first solution is to overwork the legacy system to make it evolvable again. This is feasible if the loss of evolvability is caused by the degradation 4Introduction of the system over time. However, it is not feasible if the loss of evolvability is caused by the degradation of the technological environment on which the legacy system depends on. In this thesis, we focus on the latter case. The second solution is to redevelop the system from scratch. This solution can be applied if the environment of the legacy system became technologically obsolete, since it enables using state-of-the-art technologies and software architectures. Most notably, the resulting information system can be specifically designed to match changed requirements, possibly extending beyond the functionality of the legacy system. However, due to the significant size of the information systems, redevelopment can become time-consuming and risky [Sne05]. Therefore, the third alternative solution is to buy Commercial Off-The-Shelf (COTS) software to replace it. As every COTS software needs to be adapted to match individual requirements, this solution is suitable if the effort for customization is low. However, it involves the risk of loosing undocumented but business-critical functionality contained in the legacy system during the transition. For this reason, the fourth alternative of migrating a legacy system to a new environment is seen as the commonsense solution when dealing with legacy systems [BS95, p.6]. Software migration is the transition of a legacy system to a new environment while retaining its data and functionality [Bis+99]. As in the other solutions, the information system re-enters the evolution stage after the transition has been performed and thereby regains its evolvability. Compared to redevelopment or the use of COTS software, the intention is to exclude the risk of having lost business-critical functionality after the phasing out of the legacy system. This is achieved by systematically transforming the system and thereby preserving its business-critical parts. Then, a software migration shifts the risk of failure to the transformation itself. Software modernization is some kind of software migration that emphasizes the attempt of adapting the software system to the new environment. When modernizing a legacy system, the goal is not only to create an executable version of the system in the new environment that preserves its data and functionality but also to design the system for the new environment [Fle+07]. In this thesis, we focus on modernizing rather than just migrating legacy systems. We assume that this is essential to ensure the longevity of the system. We use a real-world modernization scenario between platforms of the vendor Oracle as a continuous example, namely the transformation from Oracle Forms to Oracle ADF. The platform Oracle Forms, which originated in 1981 1 , has been established to enable the development of information systems that consist of user interfaces which allow users to interact with an underlying database. Systems developed in Oracle Forms are written in a proprietary 1http://www.trivadis.com/sites/default/files/downloads/Kopernikus_de.pdf (accessed March 22th, 2016) 5 Fourth-Generation Programming Language (4GL) and do employ a monolithic architecture. An example of a system developed in Oracle Forms can be seen in the left side of Figure 1.2. In the right side of the figure, the same user interface is shown in the more recent platform Oracle ADF. Oracle ADF is a framework that aims to ease the development of information systems by providing infrastructure services and corresponding development tools. Systems developed in Oracle ADF are written in the object-oriented programming language Java and do employ a layered, service-oriented architecture. The framework extends the capabilities of Oracle Forms, for example, by enabling the development of systems that are optimized for mobile devices. This is one of the reasons why various companies consider transforming their Oracle Forms-based information system to Oracle ADF. Modernization Figure 1.2 User interface of the Summit application, realized in the platform Oracle Forms (left) and in Oracle ADF (right) An essential characteristic of each software modernization is the intended change of the environment [GW05]. This change can be diverse since it can affect every part of the technical environment used by the legacy system, examples being the hardware, operating system or runtime environment. The change of the environment then determines the required change that needs to occur in the transformation of the legacy system. For example, a transformation from Oracle Forms to Oracle ADF will result in a change of the runtime environment, requiring the change of interfaces and the programming language used. Carefully analyzing such characteristics of a software modernization, planning and executing the transformation is the task of a software modernization project. Just like software development projects, software modernization projects are complex and therefore need to be carried out systematically. This can be achieved by enacting a software modernization method. In general, a method describes all relevant aspects to guide a software engineering endeavor, such as a software modernization project [ES10]. A description comprises activities to be performed, artifacts to be generated, roles to be involved, tools to be utilized as well as relation between these concepts. For software development, the Rational Unified Process (RUP) [Kru03] or the V-Model XT [VMXe15] are examples for established methods that are enacted in corresponding projects in order to provide guidance. 6Introduction For software modernization, such methods have been developed as well, an example being the Reference Migration Process (ReMiP) [SWH10, pp.85-131]. The contents of ReMiP have been derived by generalizing established methods, it can be seen as a reference method for software modernization. In Figure 1.3, an overview of its core disciplines is shown. A discipline is a categorization of similar contents within a method, e.g., activities with similar concerns are contained in the same discipline [OMG08a, p.161]. Requirements Analysis Legacy Analysis Target Design Strategy Selection Transformation Test Cut-Over Software Transformation Method Specification design influenced by outcome of developed during enacted during Artifact Discipline Association Figure 1.3 Core disciplines of a software modernization method and their relation to the development and enactment of a transformation method, based on ReMiP [SWH10] When comparing methods to develop software with methods to modernize legacy systems, both have some disciplines in common. In both cases, requirements of the underlying project are analyzed, the target architecture of the resulting information system gets designed and the system is tested. But, there are some disciplines that are specific to software modernization methods, such as the need for analyzing the legacy system, choosing a transition strategy or performing the transformation and cut-over. The Transformation discipline substitutes the Implementation discipline of a software development project, it comprises the use of a previously developed Software Transformation Method. Since a software modernization can be seen as the systematic transformation of artifacts that constitute a legacy system, a software transformation method is the part of a software modernization method which describes how to perform the transformation. 1.1 Software Transformation Methods A software transformation method specifies for every part of the legacy system which activities to perform, roles to involve, tools to apply or artifacts to generate in order to transform the system technically. In other words, the Transformation Method Specification guides the technical transformation of a legacy system. Besides the transformation itself, it can also guide the development of tools that are required to automate parts of the transformation. Transformation methods follow a software transformation strategy which describes a specific way of how to perform the transformation. Established strategies are conversion, reim- 1.1 Software Transformation Methods 7 plementation or wrapping [SWH10, pp.10-13]. A conversion strategy intends to automatically transform a legacy system by defining mappings between the programming languages involved. In contrast, when following a reimplementation strategy, a legacy system gets rewritten manually by developers. A wrapping strategy foresees to encapsulate a system by using a wrapper. The wrapper acts as a connection point to the legacy functionality in the resulting system. Related to processes, transformation methods are instances of the established horseshoe model [KWC98]. This is due to the fact that software modernization is some kind of software reengineering, which comprises the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form [CC90]. In general, reengineering methods consist of the consecutive phases Reverse Engineering,Restructuring and Forward Engineering which is represented by the horseshoe model shown in Figure 1.4. Activity Source Code Artifact Legacy System Transformed System Reverse Engineering Forward Engineering Restructuring Phase Figure 1.4 Conceptual representation of the horseshoe model, consisting of the consecutive phases reverse engineering, restructuring and forward engineering [KWC98] During the transformation, the legacy system is represented by artifacts on different levels of abstraction, e.g., on a syntactical or architectural level. Representations on higher levels of abstraction are reverse engineered by enacting activities that apply parsing or clustering techniques. Then, the representations are restructured to adapt the system to the new environment, for example, by changing its architectural style. Finally, forward engineering is applied to concretize them in the target environment, possibly generating runnable source code. The standardization of artifacts used by a software transformation method has been the goal of the Object Management Group (OMG). For this purpose, the Architecture-Driven Modernization (ADM) task force 2 has been established which aims to apply principles from the domain of Model-Driven Engineering (MDE) on the domain of software modernization. Up to the present day, several standards for these models have been defined in terms of metamodels, others are in development. 2http://adm.omg.org (accessed March 22th, 2016) 14 Introduction Model-Driven Software Modernization Method Engineering MEFiSTo Framework Oracle Feasibility Study Component Reengineering [GGS12] [GS13] [FBGS15] [GFB15] [GFBS16] [Gri+14] [GSK14] [KG14] [DG15] [Der+16] based on foundations of based on foundations of applies principles of Foundations Solution Concept Application of the Solution Concept applies principles of applies [Gri+16] Test Case Reengineering [Jov+16] [JGY16] Figure 1.8 Overview of the publications related to this thesis focused on modeling, i.e., decomposing, a software system by a set of concepts and evaluating the applicability of method patterns. In addition, we discussed the findings of the feasibility studies performed. In [GFB15], we discussed the shortcomings of current method engineering approaches to support the development of transformation methods. In addition, we described how our solution concept addresses these shortcomings. In [GFBS16], we described details of an essential part of the framework, namely the content of its method base. In particular, we described the contained method fragments and method patterns. The MEFiSTo framework was developed as part of an industrial project that was centered around software of the vendor Oracle. We directly applied the framework in this project and published the results. In [GSK14], we described a process to semi-automatically restructure a legacy system during its transformation on an architectural level. The process is based on combining hierarchical and partitioning clustering whereby intermediate results are validated by system experts. In [Gri+14], we described a method to gather feedback from software developers during a transformation to systematically improve a developed transformation method. In [KGB14], we described the principles of MEFiSTo for the Oracle community. We transferred principles of the developed solution concept to other fields in which we were working. In [DG15], we motivated that the flexible definition of transformation methods enables increasing the longevity of Model-Integrating Components (MoCos) [Der+14]. A MoCo is a non-redundant, reusable and executable combination of logically related models and code in an integrated form where both parts are stored together in one component. In [Der+16], 1.6 Structure of this Thesis 15 we briefly described the role of the MEFiSTo framework to transform existing components to MoCos. In [Jov+16] and [JGY16], we sketched the idea of how to perform the model-driven transformation of test cases in the context of a modernization scenario. 1.6 Structure of this Thesis An overview of the structure of this thesis is shown in Figure 1.9. As can be seen, the thesis is essentially separated into three parts, namely Foundations and Related Work,Solution Concept and Evaluation and Conclusion. Part I - Foundations and Related Work Introduction Foundations Scenario and Related Work Conclusion Overview Method Fragments Method Patterns Formalization Situational Context Identification Method Base Transformation Method Construction Tool Implementation Transformation Method Engineering Process Part II - Solution Concept Part III - Evaluation and Conclusion Feasibility Study 1: Forms to ADF Feasibility Study 2: Reports to JReports Feasibility Studies Chp. 1 Chp. 2 Chp. 3 Chp. 4 Chp. 5 Chp. 6 Chp. 7 Chp. 8 Figure 1.9 Overview of the structure of this thesis In Chapter 2, we describe foundations from different research areas that are related to the solution concept. In particular, we describe foundations from the fields of model-driven engineering, method engineering and software reengineering, In Chapter 3, we introduce related work of this thesis. For this purpose, we first describe a modernization scenario that resulted in the problem statement of this thesis. Based on the 16 Introduction scenario, we derive a set of requirements that a solution concept needs to fulfill. We identify and classify existing approaches and evaluate them against the requirements. In Chapter 4, we give an overview of the solution concept defined in this thesis. We describe the general idea of how to construct transformation methods using method fragments and method patterns. We state a set of evaluation criteria whose fulfillment we aim to discuss by feasibility studies and introduce an example that is used continuously in the thesis. In Chapter 5, we introduce the first main constituent of the solution concept, namely the method base. We state a set of requirements that the method base shall fulfill. Thereafter, we introduce the content of the method base, i.e., we introduce the contained method fragments and method patterns. For each pattern, we provide a comprehensive example that we use to discuss the characteristics of the pattern. Additionally, we describe how we formalize the content of the method base and developed transformation method specifications. In Chapter 6, we introduce the second main constituent of the solution concept, namely the method engineering process. We state a set of requirements that the process shall fulfill. Thereafter, we describe the core activities of the process. We discuss the purpose and emphases for each activity. Also, we discuss quality characteristics of arising artifacts and provide detailed examples. In Chapter 7, we describe the feasibility studies performed to demonstrate the applicability of the developed framework in practice. We performed two feasibility studies in which we transformed real-world legacy systems. The systems differed in the technologies in which they have been realized. We use the findings of the studies to discuss the evaluation criteria that were introduced in Chapter 4. In Chapter 8, we summarize the main contributions of this thesis. In addition, we describe how the solution concept fulfills the requirements that were introduced in Chapter 3. Finally, we sketch future work by describing possible enhancements of the MEFiSTo framework. CHAPTER 2 Foundations In this chapter, we give an overview of foundations that are relevant for this thesis. We classified these foundations along the research areas that form the basis for the developed solution concept, as illustrated in Figure 2.1. Subsequently, we introduce essential foundations of Model-Driven Engineering (MDE) (Section 2.1), Method Engineering (Section 2.2), and Software Reengineering (Section 2.3). Software Reengineering Method Engineering MEFiSTo Model-Driven Engineering Sec. 2.1 Sec. 2.3 Sec. 2.2 Figure 2.1 Research areas related to this thesis 2.1 Model-Driven Engineering In this section, we introduce foundations in the area of Model-Driven Engineering (MDE). Intuitively, MDE is a paradigm that uses models as the primary artifacts when performing 18 Foundations a software engineering task [BCW12, pp.9-10]. We first describe the general principles of MDE by introducing the Meta-Object Facility (MOF). Thereafter, we introduce two manifestations of MDE, namely the Model-Driven Architecture (MDA) and the Architecture-Driven Modernization (ADM). 2.1.1 Meta-Object Facility The Meta-Object Facility (MOF) standard [OMG15a] defined by the Object Management Group (OMG) can be seen as a framework for metadata that has been designed to support model-driven engineering. Intuitively, it enables establishing a layered architecture that can serve as a common basis to develop or include models and modeling languages. A MOF-based architecture can consist of an infinite amount of so-called metamodeling layers, while at least two are required. In practice, it is common to use four layers as shown in Figure 2.2. M0 Layer M1 Layer M2 Layer M3 Layer Metametamodel Metamodel Model Real World Objects call_form() name : String FunctionCallExpression Class Attribute Class Instance-Of Instance-OfInstance-Of Instance-OfInstance-Of Instance-Of Figure 2.2 Exemplary Meta-Object Facility-based architecture, based on [BCW12, p.14] On the M0 Layer at the bottom of Figure 2.2, objects of the real world reside. These are the objects that we aim to describe by a model. In this example, textual source code is shown. The source code represents the invocation of a function called call_form. On the M1 Layer, models of real world objects reside. A model is associated with three characteristics: it should be a representation of something existing in the real world (Mapping), while only representing certain aspects (Reduction) that are relevant for an intended goal (Pragmatism) [Sta73]. In this example, we model the function invocation as a FunctionCallExpression which has a name. To express such a model, we need an associated modeling language. Such a language resides on the M2 Layer as a Metamodel. A metamodel defines concepts (as metamodel classes) that shall be represented, relationships between these concepts and possibly logical 2.1 Model-Driven Engineering 19 assertions [BG01]. Existing general-purpose modeling languages for which metamodels are available are, for example, the Unified Modeling Language (UML) [OMG15b] or the Knowledge Discovery Metamodel (KDM) [OMG11b]. However, modeling languages can also be (self-)defined for a specific domain or context. Such a language is called a Domain-Specific Language (DSL). In the example, the FunctionCallExpression is an instance of the Class concept, while its name is an instance of an associated Attribute. We also need a modeling language to express a metamodel. This is the role of a Metametamodel, which resides on the M3 Layer. The MOF standard [OMG15a] defines such a self-describing language which, among other things, defines the concept of a Class . The Eclipse Modeling Framework (EMF) 1 provides an implementation of a part of the MOF standard. The corresponding metamodel is called ECore2. 2.1.2 Model-Driven Architecture The Model-Driven Architecture (MDA) follows the MDE paradigm and was proposed by the OMG [OMG14]. In particular, MDA defines a Model-Driven Development (MDD) process for software systems. An overview of this process can be seen in Figure 2.3. The general idea of MDA is to distinguish several abstraction levels on which different types of models reside. For each type of model, metamodels are proposed by the OMG. Starting on a high-level of abstraction, the abstraction level is stepwise and systematically lowered until the source code for the software system can be derived. The transition from one model to another is realized by model transformations. Finally, a code generator is used to generate the source code of the system. AComputation-Independent Model (CIM) describes the software system to develop, independent of its technical realization [BCW12, pp.40-41]. This comprises, for example, modeling requirements or business processes. The derived Platform-Independent Model (PIM) describes the technical realization of the system, independent of a specific platform, i.e., technology. This comprises, for example, the software architecture of the system or its deployment. Subsequently, the PIM is transformed into a Platform-Specific Model (PSM) which represents the system using technology-specific details. By separating platform-independent and platform-specific representations, PSMs for different technologies can be derived from a single PIM. The PSM should describe the system in sufficient technical detail, so that code can be generated. Thereby, the code can either be generated completely, or partially. The latter case requires that software developers complete the generated code. 1https://eclipse.org/modeling/emf/ (accessed March 22th, 2016) 2http://download.eclipse.org/modeling/emf/emf/javadoc?org/eclipse/emf/ecore/package-summary.html (accessed March 22th, 2016) 20 Foundations System Layer Platform-Independent Design ComputationIndependent Model Source Code PlatformIndependent Model Platform-Specific Model PlatformSpecific Layer PlatformIndependent Layer ComputationIndependent Layer Platform-Specific Design Implementation Model to Text Transformation Model Transformation Model Source Code Figure 2.3 Artifacts and abstraction levels of the Model-Driven Architecture [BCW12, p.41] System Layer Legacy Source Code PlatformSpecific Layer PlatformIndependent Layer ComputationIndependent Layer Model from/to Text Transformation Model Transformation Metamodel Source Code Transformed Source Code Knowledge Discovery Metamodel (KDM) Structured Metrics Metamodel (SMM) Abstract Syntax Tree Metamodel (ASTM) Semantics Of Business Vocabulary And Rules (SBVR) Business Process Model and Notation (BPMN) Figure 2.4 Modeling languages (excerpt) and abstraction levels of the Architecture-Driven Modernization, based on [PCDGP11] and [BCW12, pp.45-47] 2.1.3 Architecture-Driven Modernization The Architecture-Driven Modernization (ADM) also follows the MDE paradigm and was proposed by the OMG, more specifically, by the Architecture-Driven Modernization Task Force (ADMTF) 3 [UN10]. However, it cannot be applied to develop new software systems but to modernize existing ones. An overview of the ADM paradigm can be seen in Figure 2.4. The general idea of ADM is to distinguish several levels of abstractions which can be aligned with the ones of the MDA [BCW12, pp.45-47]. For each level, the OMG proposes various standards like the Abstract Syntax Tree Metamodel (ASTM) or the Knowledge Discovery Metamodel (KDM) [PCDGP11]. Based on this context, a transformation method (cf. Section 2.3.1) shall be enacted that spans over the proposed abstraction levels to transform the existing Legacy Source Code into the desired Transformed Source Code. For this purpose, the ADMTF discusses the possible implications when using the proposed abstraction levels [UN10, pp.18-19]. For example, solely using the platform-specific layer enables a physical transformation but prevents substantial changes to the system. Such kind of changes, i.e., changing the architecture of the system or even its requirements, requires using 3http://adm.omg.org (accessed March 22th, 2016) 2.1 Model-Driven Engineering 21 higher levels of abstraction. However, the specification of a precise transformation method, i.e., which artifacts to generate or activities to enact, is missing [BR15, p.140]. In fact, even the relation between proposed standards is not well-defined [DLGB12]. Subsequently, we provide additional details about two metamodels proposed by the ADMTF that are used within this thesis, namely ASTM and KDM. Abstract Syntax Tree Metamodel The Abstract Syntax Tree Metamodel (ASTM) [OMG11a] is a metamodel that enables modeling the Abstract Syntax Graph (ASG) of source code (cf. Section 2.3.4). An example of the intended use of the ASTM can be seen in Figure 2.5. Generic Abstract Syntax Tree Metamodel (GASTM) Specific Abstract Syntax Tree Metamodel (SASTM) Metamodel Class Inheritance GASTMSyntaxObject name : String Comment : String Dirty : Boolean Block GASTMObject name : String Comment : String Dirty : Boolean Trigger name : String libraryLocation : String PlsqlModule CompilationUnit SourceFile GASTMSourceObject Figure 2.5 Abstract Syntax Tree Metamodel, based on [OMG11a] Core KDM Source Abstractions Layer Runtime Resource Layer Program Elements Layer Infrastructure Layer Code Actions Data Event UI Platform Conceptual Build Structure Layer Source Package Figure 2.6 Packages and layers of the Knowledge Discovery Metamodel, based on [OMG11b] The general idea of ASTM is to distinguish different types of metamodels, whereby two of them are relevant for this thesis. On the one hand, the provided specification defines a Generic Abstract Syntax Tree Metamodel (GASTM). This metamodel provides means to model generic language constructs that are common to programming languages, an excerpt can be seen in the upper part of Figure 2.5. For example, a CompilationUnit is an entity that contains source code, while a GASTMSyntaxObject represents a syntactic element. On the other hand, it is foreseen to define a Specialized Abstract Syntax Tree Metamodel (SASTM). This metamodel shall extend the GASTM and represent a specific programming 22 Foundations language. However, such a metamodel is not defined within the specification but needs to be self-defined. An excerpt of an SASTM for the programming language of Oracle Forms can be seen in the lower part of Figure 2.5. The SASTM defines the syntactic elements of Blocks and Triggers as well as the PlsqlModule which acts as a container for PL/SQL source code. Knowledge Discovery Metamodel The Knowledge Discovery Metamodel (KDM) [OMG11b] is a metamodel that enables the integrated modeling of information about a software system on various levels of abstraction. An overview of the packages and layers defined within the KDM can be seen in Figure 2.6. The lowest layer of abstraction, i.e., the Infrastructure Layer, serves two purposes: First, the packages called Core and KDM define common metamodel classes that are used within other packages. Among other things, these elements provide an extension and annotation mechanism. Second, the Source package establishes the link to the software system that shall be modeled by providing means to describe its artifacts, like its directories or source code files. The packages of the Program Elements Layer can be used to model a detailed representation of the source code. However, while ASTM provides means to model the details of single language elements, KDM is focused on modeling the control and data flow (cf. Section 2.3.4). In this sense, ASTM and KDM complement each other. However, the relation between these metamodels is not well-defined [DLGB12]. The packages of the remaining layers can be used to model information that are usually only implicitly visible by the source code. On the one hand, the Runtime Resource Layer covers information whose extraction usually requires knowledge of the runtime, e.g., event-based states of the system or the structure of user interfaces. On the other hand, the Abstractions Layer covers information whose extraction usually requires knowledge of the domain, e.g., business rules or the architecture of the system. 2.2 Method Engineering In this section, we introduce foundations in the area of method engineering which is the discipline to systematically develop or adapt methods [Bri96]. The purpose of a method is to guide a complex software engineering endeavor, like the development of a software system or its transformation. A method describes this endeavor by specifying the activities to enact, artifacts to generate, tools to use or roles to involve [ES10]. Intuitively, a method is a guideline for the endeavor. As the term of a method is a central one in this thesis, we define it as follows: 2.2 Method Engineering 23 Notation 1 (Method) A method is a description of how to systematically perform an endeavor. This comprises a process and its contained activities, artifacts, roles, tools and relationships between these elements on varying levels of granularity. Subsequently, we first describe a specific manifestation of method engineering, namely Situational Method Engineering (SME). Thereafter, we introduce the Software and Systems Process Engineering Metamodel (SPEM) [OMG08a] which can be used to formally specify methods. In the end, we describe the use of metamodeling in the context of method engineering and discuss differences to MDE. 2.2.1 Situational Method Engineering Situational Method Engineering (SME) is a kind of method engineering which encompasses all aspects of creating a method for a specific situation [HS+14, p.5]. Intuitively, approaches that follow the SME paradigm consider the situational context in which a method will be applied during the development of the method. Due to this, the method can be adapted to the context and is then called situation-specific. An SME approach can be realized in various ways, a general classification is described in Section 3.3.1. For this thesis, the class of approaches that enable the modular construction of situation-specific methods is particularly important. Those approaches usually define two essential constituents as shown in Figure 1.7 on page 12. On the one hand, a method base is provided which constitutes a repository that contains reusable building blocks of methods. On the other hand, a method engineering process is defined to systematically construct a method. The building blocks of methods are called method parts, whereby different types can be distinguished. Common examples are method fragments,method chunks or method components [HS+14, pp.38-45]. A method fragment can be seen as an atomic building block of a method, while chunks as well as components aggregate multiple fragments. In this thesis, we focus on using method fragments as building blocks and define them as follows: Notation 2 (Method Fragment) A method fragment is a reusable, atomic building block of a method, i.e., a single activity, artifact, role or tool. Developing a complete method by solely using method fragments is a cumbersome task, as methods can become large in practice. One way to address this problem is to use larger method parts than method fragments. This increases the efficiency of the method development as fewer 30 Foundations or operators. Based on this Token Stream, the Abstract Syntax Tree (AST) is constructed during the Syntax Analysis activity by a parser. The Semantic Analysis turns the AST into an Abstract Syntax Graph (ASG). The ASG serves as input for the (optional) middle-end. This phase is responsible for transforming the source language into a so-called intermediate language (Intermediate Language Generation) which is optimized subsequently (Machine-Independent Optimization). The use of an intermediate language is motivated by the fact that it enables using different front and back-ends, i.e., it enables supporting different programming languages while reusing the middle-end. Possible optimizations encompass the elimination of redundancy or dead code. The last phase of a compiler is called the back-end. It is responsible for generating the target program. First, Code Generation is performed to transform the intermediate representation into source code of the target environment. Thereafter, environment-specific optimizations are performed on the resulting code. As Abstract Syntax Trees (ASTs) and Abstract Syntax Graphs (ASGs) represent data structures that are often used by examples in this thesis, we describe them in more detail. Abstract Syntax Trees and Graphs An AST results from performing a Lexical & Syntax Analysis on source code. The purpose of these activities is twofold [Aho+06, pp.5-8]. On the one hand, the syntactical consistency with the language definition is verified, i.e., it is ensured that the source code conforms to the grammar of the programming language. On the other hand, the information gathered during this activity is persisted in the form of an AST. An abstract syntax tree is a treebased data structure to represent source code which consists of nodes and edges. The nodes represent syntactic entities, i.e., programming concepts (cf. Section 2.3.4), of the underlying programming language. Intuitively, an AST only preserves the logical information of the source code [KNE92]. In particular, it does not include additional information that is used to increase the readability of the code or assist parsing, like brackets, keywords or indentations. An example of source code and its corresponding abstract syntax tree is shown in Figure 2.10. The source code consists of a single statement in which a function named call_form of the runtime environment is invoked. Thereby, the value rental_contract is passed as an argument. The lower AST represents the source code, while the upper AST represents the runtime environment, i.e., the function that gets invoked. As can be seen, the essential logical information represented by the source code and the runtime environment is captured by the ASTs. However, brackets or keywords are lost. Note that the dashed edges do not belong to the AST, as an AST only consists of nodes and edges that form a tree. Edges belonging to the AST are also called syntactic edges [KGW98]. 2.3 Software Reengineering 31 The dashed edges result from performing a Semantic Analysis. The purpose of this activity is twofold [Aho+06, p.8]. On the one hand, the semantical consistency with the language definition is verified, e.g., it is checked that each variable used has also been defined. On the other hand, the information gathered during this activity is persisted in the form of an ASG. An ASG is an AST which is extended by semantic edges [KGW98], making it a (cyclic) graph. These edges hold additional information related to the syntactic elements used. In the example, the edges associate the invocation of the runtime function with their corresponding definition. 2.3.3 Programming Paradigms A programming paradigm refers to a way of programming a computer based on a set of principles [VR09]. Examples for paradigms are object-orientation,concurrent programming or functional programming. The reason for the variety of paradigms lies in the fact that some paradigms are better suited for solving particular computational problems than others. Thereby, a programming language can realize one or multiple programming paradigms, e.g., Java is an object-oriented language that enables concurrent programming. The examples used in this thesis often discuss the challenges that arise when changing the programming paradigms during a software modernization. In particular, we focus on two paradigms, namely imperative and declarative programming. Intuitively, in imperative programming, a programmer specifies how to perform a computational task by specifying single actions, i.e., by describing what to do. In contrast, in declarative programming, a programmer specifies what shall happen without describing how. To give an idea for the difference between these two paradigms, we give an example by Figures 2.11 and 2.12. The example demonstrates in which way the same functionality can be realized by using the different paradigms. The example shows the realization of attribute validation rules. Thereby, an attribute refers to a field within a data set whose value shall be validated. In the example, the value of the fields date_shipped and date_ordered are compared to validate that a good was not shipped before it has been ordered. In Figure 2.11, the functionality is realized imperatively in Oracle Forms, more specifically, by a code block written in the programming language PL/SQL. The block gets executed by the runtime environment whenever the corresponding data set shall be validated. The validation is realized by describing single actions, i.e., by specifying how to perform the validation. First, the condition of the IF -statement checks whether date_shipped is smaller than date_ordered , i.e., whether a product is shipped before it has been ordered. If this is the case, a message is shown and an error is raised. In Figure 2.12, the same functionality is realized declaratively in Oracle ADF. In this environment a language is provided that enables specifying validation rules. Due to that, the 32 Foundations Figure 2.11 Imperative realization of attribute validation rules in Oracle Forms Figure 2.12 Declarative realization of attribute validation rules in Oracle ADF validation can be realized by describing the condition that shall be ensured and the message that shall be displayed in case of an error, without describing the actions to perform. Here, the underlying platform is responsible for performing the required actions to validate the condition. In the editor shown, it is specified that the attribute DateShipped shall be GreaterOrEqualTo the attribute DateOrdered . Although not shown, the message that is shown in case the validation fails can be specified in the register called Failure Handling. 2.3.4 Concept Modeling Concept modeling is a technique that was introduced in [KNE92] to represent a software system by a set of concepts. Thereby, each concept belongs to a particular level of abstraction and refers to a specific part of the software system‘s source code. The general idea of concept modeling is illustrated in the left side of Figure 2.13. A concrete example is shown in the right side of the figure, based on the source code depicted in Figure 2.10 on page 29. The M1 Layer is shown in the upper part of Figure 2.13, on which concepts are modeled (cf. Section 2.1.1). On the M0 Layer below, instances of the concepts within the actual software system can be identified. Essentially, we distinguish between two classes of concepts, namely language concepts and abstract concepts. On the lowest level of abstraction, language concepts reside. A language concept represents a syntactic entity defined by a corresponding programming language. Therefore, instances of language concepts are nodes within an AST (cf. Section 2.3.2) and can be automatically 2.3 Software Reengineering 33 M2 LayerM1 Layer :L3 :L4 :L5 :L10:L6 :L6 :L1 :L14 :L5 :L9 :P4 :P2 :L6 :L12 :L7 :L11 :P3 :L13:L12 :FunctionCallExpression :ByValueActual ParameterExpression :StringLiteral Value = “rental_contract“ :IdentifierReference Model Abstract Syntax Tree :L1 Language Concept Instance :P1 Programming Concept Instance composition is-a consists-of P1 Programming Concept P2P3 P1 L1 L3 L4 L2 L6 InstanceOf L7 L1 Language Concept UIFlow ASTNode FunctionCallExpression StringLiteral :UIFlow Figure 2.13 Representing a software system as a set of concepts (left), example (right) identified by a parser. Examples for language concepts are FunctionCallExpression or StringLiteral. In this thesis, we define them as follows: Notation 8 (Language Concept) A language concept is a syntactic entity of a programming language. Abstract concepts reside on higher levels of abstraction. They represent a general idea of a computation or problem solving principle [KNE92]. Thereby, they are not associated to a specific programming language but represent language-independent principles. In this thesis, we define an abstract concept as follows: Notation 9 (Abstract Concept) An abstract concept represents a language-independent idea of a computation or problem solving principle. Abstract concepts can be further classified into programming concepts and architectural concepts. A programming concept represents general programming strategies, data structures or algorithms [KNE92]. An example for a programming concept is the UIFlow which represents the navigation between user interfaces. While the realization of such navigation flows depends 34 Foundations on the programming language used (e.g., by using a FunctionCallExpression ), it is a language-independent principle. In this thesis, we define a programming concept as follows: Notation 10 (Programming Concept) A programming concept is an abstract concept and represents general programming strategies, data structures or algorithms. An architectural concept represents components or interfaces that reside within a software system [KNE92]. In contrast to programming concepts, they do not represent some functionality of the system but focus on describing its overall structure. In this thesis, we define an architectural concept as follows: Notation 11 (Architectural Concept) An architectural concept is an abstract concept and represents components or interfaces. Concepts can be related to each other by relations. In this thesis, we focus on two types of relations, namely is-a and consists-of relations. The is-a relation can be used to express a hierarchy between concepts. Intuitively, if concept L3 is-a concept L2 , then L3 is a sub-concept of L2. For example, a FunctionCallExpression is a sub-concept of ASTNode. The consists-of relation can be used to express dependencies between concepts. Intuitively, if the identification of a concept requires identifying others first, then that concept consists of the others. Specifying such dependencies is essential to (automatically) identify an instance of a concept within a software system, but not sufficient. In addition, it is required to specify constraints between dependent concepts, e.g., in terms of data or control flow relations. For example, a UIFlow consists-of a FunctionCallExpression , an IdentifierReference , a ByValueActualParameterExpression and a StringLiteral , as illustrated in the right side of Figure 2.13. The StringLiteral encodes the target of the navigation flow and needs to be a descendant of the FunctionCallExpression within the AST. CHAPTER 3 Scenario and Related Work In this chapter, we give an overview of the related work of this thesis. For this purpose, we first describe a real-world modernization scenario in Section 3.1 that resulted in the problem statement addressed by this thesis. Based on this scenario, we derive a set of requirements which a solution concept need to fulfill in Section 3.2. We identify and classify related work in Section 3.3 and evaluate it against the requirements. The findings of this chapter are summarized in Section 3.4. 3.1 Modernization Scenario The problem statement of this thesis (cf. Section 1.2) originated from a real-world modernization scenario that we observed in an industrial context. In this context, the problem of transforming legacy systems that were developed based on the platform of Oracle Forms was addressed. While Oracle Forms had a large and active installation base, various companies were unsatisfied with the capabilities of the platform. For example, Oracle Forms did not enable to optimize applications for mobile devices. Since, this became an important requirement over time, Forms-based systems were considered to be legacy. One solution to this problem was to transform those systems to the more recent platform called Oracle ADF. While Oracle itself recognized the desire of customers to transform Forms-based systems to ADF, it did not provide a tool-supported transformation method to guide this endeavor [Ora12]. Since there was no transformation method available, customers that wanted to modernize their systems needed to develop a method for their situation at hand. However, due to missing knowledge of how to develop a situation-specific transformation method, we observed that companies started redeveloping their systems from scratch, instead. 36 Scenario and Related Work The solution concept provided by this thesis shall address this problem, i.e., guide the development of situation-specific transformation methods in order to transform Forms-based systems to ADF. However, we observed that companies which used Oracle Forms were often facing additional environmental changes. For example, another platform called Oracle Reports was regularly used in combination with Oracle Forms to automatically generate reports. Since it was desired to transform systems based on this platform, too, the solution concept needs to be generic. Nevertheless, we use the transformation from Forms to ADF as a running example of this thesis. For this reason, we introduce both platforms in more detail subsequently, whereby we focus on their software architecture. 3.1.1 Oracle Forms Oracle Forms is a platform to develop enterprise applications that consist of a set of dialogs. A dialog represents a user interface that enables a user to interact with an underlying data source. In this way, it supports the user in performing an underlying business tasks. An example for such a dialog can be seen in the left side of Figure 1.2 on page 5. Those dialogs are defined declaratively by a proprietary Fourth-Generation Programming Language (4GL) as well as by using imperative PL/SQL source code. The software architecture of an Oracle Forms-based system can be seen in the left side of Figure 3.1. The architecture of Forms-based systems can be described by tiers and layers [Fow02, p.19] as well as components. Tiers describes a physical separation, i.e., a tier represents a distinct device on which components can be executed. In contrast, layers describe a logical separation, i.e., a layer represents a distinct concern that is addressed by contained components. Taken together, these components realize the functionality of the legacy system. Usually three tiers are used by Oracle Forms-based systems, namely a Client Tier, a Middle Tier and a Database Tier. On the client tier, i.e., the end user‘s device, the Presentation Layer is located. The corresponding component is provided by the platform and responsible for rendering the user interface of the system and processing user interaction. It behaves like a thin client as processing is mostly limited to forwarding the interaction events to the middle tier. The actual source files that form the Forms-based system are executed on the middle tier, i.e., on an application server. While various components are located on this tier, they cannot be classified into distinct concerns, i.e., layers. For example, the PL/SQL engine component executes imperative source code blocks. However, the source code can be used for different purposes, e.g., to validate data, to react on system events or to adapt the user interface. Therefore, the middle tier can be seen as monolithic, i.e., it only consists of a single layer. 1Based on http://de.slideshare.net/oracle_imc_team/oracle-forms-modernization-strategies (accessed March 22th, 2016) 3.1 Modernization Scenario 37 Model Layer Record Manager Block Java UI Renderer SQL Interface PL/SQL engine Model Layer Data Services Architectural Layer Architectural Component use SQL Interface Record Manager Block Data Definition Data Logic Block UI Definition Java UI Renderer UI Logic Interpretation Middle Tier Client Tier Server Tier Database Middle Tier Client Tier Database Client Tier Architectural Tier Database Tier Monolithic Layer Presentation Layer Persistence Layer View Layer Persistence Layer Controller Layer Navigation Logic Figure 3.1 Architecture of Oracle Forms-based systems (left), interpreted as Model-ViewController (MVC) architecture (right)1 On the database tier, i.e., the backend server, the Persistence Layer is located. On this layer aDatabase is executed that enables storing and retrieving the persistent data of the application. Besides data sets, executable programs can also be defined here in terms of stored procedures 2 . Related to the modernization scenario considered, we assume that we do not change the content of the database tier, i.e., the database. In addition, we neglect the thin component of the client tier as it just renders the user interface. Instead, our focus lies on transforming the content of the middle tier, i.e., the actual legacy system. One of the challenges of the transformation lies in the fact that systems in the target environment Oracle ADF possess a Model-View-Controller (MVC) architecture. The result of interpreting the architecture of Forms-based systems as an MVC architecture can be seen in the right side of Figure 3.1. In an MVC architecture, components are separated into three layers [Bus+96, pp.125-143]. The Model layer contains those components that provide core data and associated functionality. Components of the View layer display information to a user while components of the Controller layer process user interaction. Aligning the monolithic architecture of Oracle Forms with the MVC architecture requires breaking up existing components. For example, the PL/SQL engine executes source code for different concerns. These concerns need to be separated, i.e., UI Logic, Navigation Logic and Data Logic needs to be distinguished. 2https://docs.oracle.com/cd/B28359_01/appdev.111/b28843/tdddg_procedures.htm (accessed March 22th, 2016) 38 Scenario and Related Work 3.1.2 Oracle ADF Oracle ADF is a platform to develop enterprise applications based on Java EE standards. It provides a set of infrastructure services to ease the development and is not restricted to a specific technology. Rather, a choice between different technologies exists on various layers. The software architecture of an Oracle ADF-based system can be seen in Figure 3.2. ADF Desktop Integration ADF Faces Data Services View Layer Model Layer Architectural Layer use Database Tier Client Tier Middle Tier Data Services Architectural Component Client Tier Architectural Tier Metadata Services (MDS) ADF Security Persistence Layer ADF Controller Controller Layer ADF Business Components ADF Model Model Layer Figure 3.2 Model-View-Controller (MVC) architecture of Oracle ADF-based systems3 As can be seen, ADF-based systems usually use the same three tiers as Forms-based systems. However, in terms of layers, Oracle ADF follows an MVC architecture by design. The components shown are just examples and can be exchanged as desired. For example, the ADF Business Components represent one way to connect to external data sources and to provide access to these data sources within the model layer. An alternative would be to use a self-developed, Java-based database connection instead. Note that some cross-cutting components exist, i.e., components that are present on all layers. They provide cross-cutting functionality, i.e., security or multi-language support. This concludes the description of the modernization scenario, the platforms of Forms and ADF as well as their differences on the architectural level. Subsequently, we use the modernization scenario to derive a set of requirements for the solution concept of this thesis. 3Based on http://docs.oracle.com/middleware/1221/adf/concepts/GUID-422ED063-2643-4F8D-B4BB-A8FA4C8CF536.htm (accessed March 22th, 2016) 3.2 Requirements 39 3.2 Requirements In this section, we discuss challenges related to the definition of a transformation method that arise due to the modernization scenario described in the previous section. Based on these challenges, we derive a set of requirements that any method engineering approach needs to fulfill in order to support the definition of transformation methods in the context of the modernization scenario. We classify the requirements into four categories, namely Controlled Flexibility,Adaptability,Tooling as well as Formalization. Controlled Flexibility The fact that no transformation method was available in the first place was the main problem of the modernization scenario described. In addition, no method engineering approach could be used to develop a method for the situation at hand. The reason for this is that existing approaches provided a low degree of flexibility [HBO94]. Intuitively, this essential characteristic of a method engineering approach determines the degree of freedom given during the development of a method to adapt the method to a prevailing situation. To address this problem, Requirement 1 claims that the solution concept shall provide a high degree of flexibility. Requirement 1 (Flexibility) The method engineering approach shall provide a high degree of flexibility. Nevertheless, some method engineering approaches provided a high degree of flexibility. As an edge case, consider the development of a transformation method from scratch which provides the highest degree of flexibility possible. However, such approaches were not applicable in the modernization scenario, as they provided a low degree of control [HBO94]. Intuitively, this essential characteristic of a method engineering approach determines the degree of guidance given during the development of the method. Without such guidance, it is not possible to ensure the result of the development, e.g., the correctness or quality of the method. To address this problem, Requirement 2 claims that the solution concept shall provide a high degree of control. Requirement 2 (Control) The method engineering approach shall provide a high degree of control. Adaptability Method engineering approaches can support specific environmental changes. For example, related to the modernization scenario, an obvious solution would be to define a method 46 Scenario and Related Work Fixed Configuration Selection Tailoring Construction ID Requirement Sensoria [MH11] ARTIST [Men+14] SOA-MF [RL15] ReMiP [SWH10] MEFiSTo Controlled Flexibility RQ1 The method engineering approach shall provide a high degree of flexibility 6O O 4 4 RQ2 The method engineering approach shall provide a high degree of control 4 4 4 6 4 Adaptability RQ3 The development of transformation methods shall not be limited to a specific environmental change 6 6 6 4 4 RQ4 The development of transformation methods shall not be limited to a specific level of granularity 6 4 O4 4 RQ5 The development of transformation methods shall not be limited to a specific transformation strategy 6 4 O4 4 Tooling RQ6 The use of tools during the enactment of the transformation method shall be guided 4 4 O O 4 Formalization RQ7 Developed transformation methods shall be specified formally 6 4 O4 4 Table 3.1 Evaluation of selected method engineering approaches against requirements Requirement 1 & 2 We already discussed in detail in Section 3.3.1 that none of the approaches provides a sufficient degree of Flexibility and Control at the same time. Fixed methods like Sensoria lack flexibility but provide control, while the opposite is true for tailoring-based approaches (cf. Figure 3.3). The solution concept of this thesis, i.e., the Method Engineering Framework for SituationSpecific Software Transformation Methods (MEFiSTo) (cf. Section 4.1), fulfills both requirements as it is a construction-based approach. Transformation methods are developed in a modular way by assembling predefined building blocks. The endeavor is guided by a corresponding method engineering process. Requirement 3 Generality can be achieved if the reusable method or method building blocks provided by a method engineering approach are not attuned to a specific environmental change. This is only the case for the ReMiP approach as it defines a generic transformation method. All 3.3 Related Work 47 other approaches focus on a specific environmental change, like the transformation to a SOA (Sensoria,SOA-MF) or to a cloud (ARTIST) environment. In MEFiSTo, this requirement is addressed by the method base, i.e., the repository that contains the reusable building blocks for transformation methods. The content of this repository was designed to be independent of a specific environmental change or technology (cf. Sections 5.3 and 5.4). Requirement 4 Varying the Granularity of the developed method can be achieved by various means. One way is to explicitly foresee an adaptation of the granularity during the development of a method as part of the method engineering process. Another way is to formalize the method in a language that enables refinement. For example, the granularity of SPEM-based method specifications can be adapted retroactively. ARTIST and ReMiP follow the latter approach. In contrast, Sensoria does not foresee an adaptation of the granularity and, as the method is not specified formally, it is also not supported by the specification language. In SOA-MF, whether an adaptation of the granularity is possible depends on which method gets selected. In MEFiSTo, this requirement is addressed in two ways. On the one hand, the method engineering process explicitly foresees to specify a decomposition of the legacy system to transform by so called concepts (cf. Section 6.3.1), whereby the granularity can be varied. The decomposition has a direct influence on the granularity of the resulting transformation method. On the other hand, methods are formalized by using SPEM which supports refinement. Requirement 5 Versatility can be achieved by enabling to combine multiple transformation strategies within the resulting method. ARTIST and ReMiP both combine different strategies like conversion and reimplementation. In contrast, Sensoria only foresees a conversion of the legacy system. In SOA-MF, the strategy again depends on which method gets selected. In MEFiSTo, this requirement is addressed by the method base, i.e., the repository that contains the reusable building blocks for transformation method. These building blocks can be used to specify transformation methods that follow a conversion and/or reimplementation-based strategy (cf. Section 5.3). Requirement 6 Continuity can be achieved by various means. One way is to explicitly provide a set of tools along with the method engineering approach. These tools should be aligned with the resulting method, so that they are directly applicable. Another way is to guide the development of required tools as part of the approach. ARTIST follows the former approach, i.e., it provides a set of tools 4 .Sensoria and ReMiP follow the latter approach by specifying the capabilities of required tools. However, while Sensoria describes the required tools in great detail, e.g., by specifying technologies, metamodels or model transformations, ReMiP does 4https://github.com/artist-project/ (accessed March 22th, 2016) 48 Scenario and Related Work not provide many details. In SOA-MF, whether the use of a tool is guided, or not, depends on which method gets selected. In MEFiSTo, this requirement is addressed in two ways. On the one hand, it is explicitly foreseen that a developed transformation method specifies how to develop required tools (cf. Section 5.4). On the other hand, the development shall be based on an associated, generic tool infrastructure (cf. Section 6.5). Requirement 7 Formalization can be achieved by specifying the resulting method formally. For example, a metamodel like SPEM can be used for this purpose (cf. Section 2.2.2). ARTIST and ReMiP both use SPEM to formally specify the proposed methods. In contrast, Sensoria does not provide a formal description. In SOA-MF, whether the resulting method is described formally, or not, depends on which method gets selected. In MEFiSTo, each developed transformation method is specified formally (cf. Section 5.7). First, the MEFiSTo Intermediate Modeling Language (MIML) is used during the development of the method. When the development of a method is completed, the MIML-based specification gets automatically transformed into a SPEM-based specification. 3.4 Summary In this thesis, we aim to provide a solution concept for a problem statement that originated from a real-world modernization scenario. In this chapter, we introduced that scenario and derived corresponding requirements. We introduced related work, i.e. we introduced existing approaches that could have been applied in the modernization scenario and evaluated them against the requirements. We concluded that existing approaches have various shortcomings and discussed how they are addressed by the solution concept of this thesis. First, we introduced the modernization scenario of this thesis in Section 3.1. We described the situation that various companies face in practice, i.e., the desire to transform Oracle Formsbased systems to Oracle ADF. We described both environments on an architectural level and described their differences. In Section 3.2, we discussed a set of challenges that arise due to the considered modernization scenario. Based on these challenges, we derived a set of requirements that a solution concept needs to fulfill in order to be applicable in the modernization scenario. In Section 3.3, we introduced related work of this thesis. In particular, we introduced and classified existing situational method engineering approaches and reengineering frameworks that could have been applied in the modernization scenario. We evaluated them against the identified requirements and concluded that various shortcomings exist. In addition, we discussed how the solution concept of this thesis addresses the requirements. “We cannot solve our problems with the same thinking we used when we created them.” – ALBERT EINSTEIN PART II SOLUTION CONCEPT CHAPTER 4 Overview In the previous chapter, we identified that state-of-the-art approaches fail to provide sufficient controlled flexibility in the development of transformation methods. In this chapter, we give an overview of the solution concept which addresses this issue. First, we explain the general idea of the solution concept and give an overview of its main constituents in Section 4.1. In Chapters 5 and 6, these constituents are revisited and discussed in more detail. In Section 4.2, we state a set of evaluation criteria related to the solution concept whose fulfillment we aim to discuss by the feasibility studies described in Chapter 7. In Section 4.3, we introduce a legacy system which acts as a running example throughout the thesis. Finally, the findings of this chapter are summarized in Section 4.4. 4.1 The MEFiSTo Framework To enable the modular construction of situation-specific software transformation methods, we propose a method engineering framework called MEFiSTo. Compared to state-of-theart approaches to develop methods, the framework provides a higher degree of controlled flexibility. It consists of two main constituents: a method base that provides building blocks to assemble transformation methods and a corresponding method engineering process that guides the development and enactment of situation-specific methods. Subsequently, we first describe the purpose and content of the method base to explain the general idea of how transformation methods are constructed using the framework. Then, we give an overview of the corresponding method engineering process of the framework. In the end of this section, we discuss the design rationale of the main constituents of MEFiSTo. 52 Overview 4.1.1 Method Base The MEFiSTo framework is a Situational Method Engineering (SME) framework. SME is an established engineering discipline to develop situation-specific methods (cf. Section 2.2.1) by considering the situational context in which the method will be applied. Related to the domain of software modernization, this context consists of the characteristics of the legacy system, the intended target design and the characteristics of the modernization project. The distinguishing characteristic between SME approaches is the degree of controlled flexibility they provide. Intuitively, flexibility refers to the degree of freedom to adapt a method to the situation at hand, while control refers to the degree of guidance given for this endeavor. In Section 3.3.1, different classes of SME approaches and their degree of controlled flexibility have been introduced. Related to this classification, the MEFiSTo framework belongs to the class of approaches that enable the modular construction of transformation methods. These kinds of approaches provide a high degree of controlled flexibility as methods are developed by assembling reusable building blocks of methods. Such building blocks are stored in a repository called a method base [Bri96]. In the case of MEFiSTo, we use two different types of building blocks, namely method fragments and method patterns. These constituents of the method base can be seen in the upper part of Figure 4.1. In this thesis, a method fragment is defined as an atomic constituent of a method, i.e., a single activity, artifact, role or tool (cf. Section 2.2.1). The fragments proposed in this thesis are constituents of transformation methods. Solely using the proposed method fragments would provide a high degree of flexibility, as transformation methods could be freely assembled from them. However, we aim for controlled flexibility, i.e., we want to make sure that the assembled method possesses desired properties. For example, we want to ensure that a transformation method can actually be used to transform the legacy system on which it is applied. Then, a necessary prerequisite is that a consistent path starting from the source code of the legacy system to the resulting transformed source code needs to be specified. Such methodological knowledge is encoded by the method patterns that are also contained in the method base. Intuitively, the patterns represent transformation strategies by describing constraints over the method fragments, e.g., by defining which one to use and how to order them. The guidance provided by the method base in the development of transformation methods is restricted to the structure of the method specification to develop. To guide the development itself, we additionally provide a corresponding method engineering process. In MEFiSTo, the development of a method can be seen as being pattern-based. The idea is to first (I) select a method pattern that fits the situational-context observed. The pattern (II) then determines the method fragments to be customized. This is exemplified in the lower part of Figure 4.1. 4.1 The MEFiSTo Framework 53 Selection of Method Pattern Method Fragments Model Discovery Method Patterns Method Base Customization of Method Fragments Transformation Method Specification PL/SQL PlatformSpecific Model Java PlatformSpecific Model PL/SQL Source Code Java Source Code Transformed PlatformSpecific Model Transformed Source Code Code Generation Language Transformation III Java Code Generation PL/SQL Discovery PL/SQL to Java Transformation Legacy PlatformSpecific Model Legacy Source Code Reimplementation Language Transformation Conceptual Transformation Figure 4.1 Pattern-based development of transformation methods To get an intuitive idea for the pattern-based development process, consider a scenario in which the source and target environment use different programming languages, e.g., a transformation from PL/SQL source code to Java source code needs to be performed. In addition, a high degree of automation is required as the legacy system consists of millions of lines of code. First (I), we select a method pattern based on the identified situational context. Here, we choose the Language Transformation pattern. As it encodes a conversion-based transformation by performing automated transformations between the involved artifacts, we assume it to be a good fit for the observed context. Second (II), we customize the method fragments as determined by the pattern. In this example, the pattern prescribes to start with the Legacy Source Code artifact, which gets customized to a PL/SQL Source Code artifact. In this way, we end up with a situation-specific transformation method specification. A detailed description of the proposed method base and its content is given in Chapter 5. In the next section, we give a more detailed overview of the proposed activities that make up the method engineering process. 54 Overview 4.1.2 Method Engineering Process The method engineering process that is part of the MEFiSTo framework describes the activities and related steps necessary in order to develop and enact a situation-specific transformation method. An overview of the core activities of the process and its relation to the proposed method base is shown in Figure 4.2. Converted Source Code Legacy Source Code Situational Context Identification Transformation Method Construction Tool ImplementationTransformation Situation-Specific Tool Chain Situation-Specific Transformation Method Specification Situational Context Model Metamodel M2M Transformed Source Code Method Fragments Model Discovery Architecture Restructuring Method Patterns Source Code L-PSM F-PIM Method Base Tool Developers Software Developers Monolith Layer 1 Layer 2 Layer 3 Legacy Source Code Transformed Source Code Legacy Source Code Legacy Source Code Legacy Source Code Legacy Source Code Legacy Source Code Modernization Expert and Tool Specialist Method Development Method Enactment Sec. 6.6 Sec. 6.5 Sec. 6.3 Sec. 6.4 Sec. 5.3 & 5.4 System Experts Sec. 5.5 & 5.6 Modernization Expert and Tool Specialist Figure 4.2 Overview of the MEFiSTo framework The Legacy Source Code of the system to be transformed is an essential input artifact of the method engineering process. By enacting the process, it will become Transformed Source Code, which constitutes the transformed system in the new environment. The process itself 4.1 The MEFiSTo Framework 55 can be separated into two disciplines, namely Method Development and Method Enactment. By performing activities of the former discipline, a situation-specific transformation method gets developed. The developed method is then performed by activities of the latter discipline to actually transform the legacy system. As can be seen in the figure, the transition between activities of both disciplines is associated with the flow of a Situation-Specific Transformation Method Specification, which is a description of the developed method. Subsequently, we briefly describe the purpose of the four core activities. Developing a situation-specific transformation method essentially requires knowledge of the situational context, as it is a prerequisite to perform informed decisions during the development. For example, it is required to have knowledge about the characteristics of the legacy system and the target design. Systematically discovering this context is the purpose of the Situational Context Identification activity, it is described in detail in Section 6.3. The situational context identified enables performing informed decisions in the construction of a transformation method. As MEFiSTo follows a pattern-based development (see 4.1.1), this essentially encompasses selecting method patterns and customizing method fragments. The purpose of the Transformation Method Construction is to guide that endeavor, it is described in detail in Section 6.4 Ideally, transformation methods employ a high degree of conversion, in order to reduce the overall effort and avoid errors that could result due to manual interactions [SWH10, p.131]. Therefore, for every specified activity that shall either be performed automatically or semiautomatically, a corresponding tool as part of an integrated tool chain needs to be implemented. This is performed as part of the Tool Implementation activity. In Section 6.5, we discuss the capabilities a generic tool infrastructure needs to provide in order to support the development of project-specific tools. When the transformation method has been developed and required tools have been implemented, the actual transformation of the legacy system needs to occur. Corresponding parts of the method are performed within the Transformation activity. In Section 6.6, we discuss challenges when enacting the activities incrementally. 4.1.3 Phases & Roles The method engineering process of MEFiSTo consists of four core activities. The rationale for this segmentation is twofold. On the one hand, the activities proposed are common for SME approaches. They are discussed on a generic level in [Bri96], we adapted them to the domain of software transformation. On the other hand, and more importantly, we aim for a clear separation of concerns in terms of expertise required. For example, developing a transformation method requires knowledge of software modernization, while the enactment of the developed 62 Overview Tree-Based Data Selection When starting the Summit application, the first dialog enables selecting a customer (cf. left side of dialog (a) shown in Figure 4.5). In this dialog, the customers are represented by a tree structure. Besides transforming the user interface elements (i) of the tree, we focus on transforming the expand and collapse behavior (ii). (C6) The dialog provides user interface elements that represent a tree. The tree has a depth of two, whereby the root nodes represent countries and the leafs represent the actual customers. The selection of a leaf triggers a selection of the corresponding data set. (C7) Besides the tree itself, the user interface enables triggering tree-related actions. In particular, it enables expanding and collapsing parts of the tree automatically. (a) Customer Selection (b) Sales Representative Selection (c) Order Management (d) Inventory Overview (e) Product Selection Dialog Dialog Flow Module Figure 4.5 Form Modules of the Summit application, their contained dialogs and the navigation flows between them Modularization Every application has an architecture that describes its fundamental organization [IEEE00]. The architecture of an Oracle Forms-based application is mainly defined by its modules. (C8) Every application developed in Forms consists of a set of modules, i.e., each application has a modularization. Thereby, modules are stored in corresponding source files. Form Modules are the main buildings blocks as they contain the definition of dialogs, connections to underlying data sources as well as source code routines [Ora00a, pp.62-63]. 4.4 Summary 63 The Form Modules of the Summit application and its contained dialogs are shown in Figure 4.5. For each Form Module, the contained dialogs as well as possible navigation flows between them are visualized. When starting the Summit application, the dialog to select a customer (a) is shown. Based on the selection, the sales representative associated can be changed (b) or the associated order can be edited (c) (cf. Figure 4.4). When editing an order, stocking information for an item can be shown (d) and new items can be added (e). 4.4 Summary Current method engineering approaches do not provide sufficient controlled flexibility in the development of situation-specific software transformation methods. In this chapter, we introduced the solution concept of this thesis which addresses this problem. The solution concept consists of a method engineering framework, called MEFiSTo. The framework aims to achieve a high degree of controlled flexibility by enabling a pattern-based development of transformation methods. We described its main constituents in Section 4.1, namely a method base and a corresponding method engineering process. To evaluate characteristics of the MEFiSTo framework, we stated a set of evaluation criteria as questions in Section 4.2. In particular, the questions address characteristics of the core constituents of MEFiSTo. We revisit and answer these questions in Section 7.4 in the context of the feasibility studies performed. To exemplify details of the MEFiSTo framework and demonstrate its application, we introduced a running example in the form of a legacy system in Section 4.3. We gave an overview of the functionality and architecture of the Oracle Forms-based application. It will be revisited in subsequent chapters whereby technical details are discussed. In the next two chapters, we will go into detail on the two main constituents of MEFiSTo. In chapter 5, details on the proposed method base are given, while details of the corresponding method engineering process are described in chapter 6. CHAPTER 5 MEFiSTo Method Base In the previous chapter, an overview of the MEFiSTo framework to define situation-specific transformation methods has been given. In this chapter, we introduce the content of the method base as part of the framework. First, we discuss requirements that specifically address the method base in Section 5.1. In Section 5.2, we refine the structure of the method base and describe its content. Essentially, the method base consists of two constituents, namely method fragments and method patterns. We propose a set of method fragments in Sections 5.3 and 5.4, while a set of method patterns is proposed subsequently in Sections 5.5 and 5.6. In Section 5.7, we formalize the introduced content of the method base. The findings of this chapter are summarized in Section 5.8. 5.1 Requirements Before defining the content of the method base, we discuss related requirements. Thereby, we have to distinguish functional and non-functional requirements. When developing a method, the content of the method base will determine the possible manifestations of a method. For example, if the method base does not include a method fragment that represents an automated activity, it will not be possible to specify a tool-supported transformation method. In this sense, functional requirements are those that describe which methods shall be developable using the content of the method base. The problem statement of this thesis emerged from the real-world problem of transforming Oracle Forms applications to Oracle ADF (cf. Section 3.1). Due to the differences between these environments, a transformation method that is applicable in general is not available. As a result, transformation methods are currently developed in an ad-hoc manner. We intend to address this problem by the solution concept of this thesis, that is, the MEFiSTo framework. 66 MEFiSTo Method Base Therefore, Requirement 1 claims that the content of the method base, i.e., the method fragments and patterns, shall support the development of situation-specific transformation methods for the modernization from Oracle Forms to Oracle ADF. Method Base Requirement 1 (Support for Forms/ADF) The composition of content elements, stored in the method base, shall enable the development of situation-specific transformation methods for the modernization from Oracle Forms to Oracle ADF. While functional requirements describe which methods shall be developable using the content of the method base, we also discuss the form that a developed method should take. In this sense, non-functional requirements are those that relate to the characteristics of the content of the method base. Method Base Scope of MEFiSTo Method Specification Method Engineering Process Technology-Specific Method Base Project-Specific Method Specification D Project-Specific Method Specification E Project-Specific Method Specification F Method Development Method Reengineering Technology-Independent Method Base Project-Specific Method Specification A Method Development Project-Specific Method Specification B Project-Specific Method Specification C Figure 5.1 Use of a technology-independent method base in MEFiSTo (left), reengineering of developed methods to derive a technology-specific method base (right) Requirement 1 states that the content of the method base shall support the development of transformation methods for a specific modernization scenario. More precisely, the specific technologies Oracle Forms and Oracle ADF shall be considered. An obvious solution to this requirement would be to store technology-specific method fragments and patterns in the method base. However, while the problem of transforming systems based on Oracle Forms was the main driver to define MEFiSTo, there exist legacy systems based on related technologies for which transformation methods are also developed in an ad-hoc manner. Most notably, Forms-based systems often invoke the creation of printable reports, developed in the technology Oracle Reports. Using a technology-specific method base would exclude the development of transformation methods for different technologies such as Oracle Reports. 5.1 Requirements 67 An alternative solution is to store technology-independent content inside the method base. Then, a corresponding method engineering process needs to consider technology-specific customization of the content, as proposed in [HV97]. This will enable the development of transformation methods for other modernization scenarios but require manual effort for the customization. However, as an additional advantage we expect that developed methods can be later on reengineered to systematically derive the content of a technology-specific method base (see Figure 5.1). Therefore, Requirement 2 claims that the content of the method base shall not be associated to a specific technology. Method Base Requirement 2 (Technology-independence) The method fragments and patterns shall not be associated to a specific technology. We intend to use the MEFiSTo framework to modernize software systems. While a software migration aims to preserve the functionality of a system while transferring it to a new environment, software modernization additionally emphasizes to adapt the system to the new environment. We assume that Model-Driven Engineering (MDE) (cf. Section 2.1) is a key principle to enable automation in software modernization scenarios. Using models enables representing a software system on higher levels of abstraction, i.e., it enables abstracting from its current technological realization. We assume that this is essential to adapt a system to its new environment. Therefore, Requirement 3 claims that the content of the method base shall be based on principles from the domain of model-driven engineering. Method Base Requirement 3 (MDE principles) The method fragments and patterns shall be based on model-driven engineering principles. The Architecture-Driven Modernization Task Force (ADMTF) is an initiative of the OMG that applies concepts from the domain of model-driven engineering to the domain of software modernization (cf. Section 2.1.3). Its main contribution consists of various standards in the form of metamodels, like the Abstract Syntax Tree Metamodel (ASTM) or the Knowledge Discovery Metamodel (KDM). In the context of a transformation method, artifacts in the form of models can conform to these metamodels. The motivation of the ADMTF to develop these standards is to enable the reusability of tools and foster their integration. To potentially take advantage of existing tools in MEFiSTo, too, Requirement 4 claims that the content of the method base shall consider compatibility to standards from the ADM context. Method Base Requirement 4 (Compatibility to standards) The method fragments and patterns shall be compatible to standards from the ADM context. 68 MEFiSTo Method Base Software transformation methods can be described formally, or not. Providing a formal description of a method requires additional specification effort, but is considered as a key success factor for modernization projects [Cab+15]. For example, it enables providing support in the enactment of a method, e.g., by using a process engine that assigns tasks to involved persons [DF94]. More importantly, we assume that a formal description will be beneficial for reusing a developed method, e.g., it allows reengineering reusable parts. It is common practice to use metamodels for formalization [RDR03]. Therefore, Requirement 5 claims to formalize the content of the method base using the Software and Systems Process Engineering Metamodel (SPEM) which is a standard [OMG08a] defined by the OMG. Method Base Requirement 5 (Formalization in SPEM) The method fragments and patterns shall be described formally by using SPEM. 5.2 Overview of the Structure In this section, we give an overview of the structure of the method base that is part of MEFiSTo. The purpose of the method base is to provide reusable building blocks for transformation method specifications. In Section 4.1.1 we motivated that the method base contains two types of such blocks: method fragments and method patterns. In Figure 5.2, these constituents are further classified. 5.2.1 Method Fragments Reusable method fragments form the basis of the method base. They can be seen as atomic building blocks for methods (cf. Section 2.2.1). At the highest level, we classify the method fragments based on the phase they primarily belong to, namely the tool implementation or transformation phase (cf. Section 4.1.3). While the fragments related to the tool implementation phase can be used to specify tool development activities, the fragments related to the transformation phase can be used to describe the transformation itself. For each phase, we classify the fragments based on their type. In general, the intersection of the fragments contained in the tool implementation and transformation phase is empty, i.e., no fragment is contained in both. However, this does not mean that fragments are exclusively used in their associated phase. Instead, some fragments act as an interface between both phases. For example, model transformations are developed in the tool implementation phases (i.e., they are an output) but used in the transformation phase (i.e., they are an input). The same is true for metamodels or tools. 5.2 Overview of the Structure 69 Composed PatternsTool Implementation Phase Tools Tool Activities Metamodel Definition Artifacts Metamodel Roles Tool Developer Transformation Phase Artifacts Activities Roles Software Developer Basic Patterns Functionality Preserving Architectural Restructuring Functionality Preserving Architectural Restructuring Sec. 5.4 Sec. 5.3 Sec. 5.6 Sec. 5.5 Method Fragments Method Patterns Method Base Program Comprehension Legacy Source Code Tools Parser Figure 5.2 Overview of the structure of the method base in MEFiSTo We exploit this relation between the method fragments of both phases to systematically engineer the method fragments for the tool implementation phase. In particular, we use the fact that the fragments of the tool implementation phase shall be able to express the development of tools or artifacts that are used as part of the transformation phase. Therefore, we first describe the fragments of the transformation phase in Section 5.3 and derive the fragments of the tool implementation phase subsequently in Section 5.4. To engineer the method fragments for the transformation phase, we consider different techniques that have been developed over time. In [Ral04], these techniques are categorized into two main categories, namely the reengineering of existing methods and the ad-hoc construction of new fragments. Techniques of the first category describe different ways to disassemble existing methods into smaller fragments. To reengineer the method fragments for the MEFiSTo framework, we would require specifications of model-driven transformation methods that are not limited to specific environmental changes. As existing methods or method engineering frameworks that fulfill these requirements were not available, we applied an ad-hoc technique to construct the fragments from scratch. For an ad-hoc technique, it is essential to clearly identify the requirements of the domain for which the development of methods shall be supported. In the case of MEFiSTo, these require- 70 MEFiSTo Method Base ments have been discussed in Section 5.1. In this thesis, we meet the functional requirements if the method fragments proposed can be used to develop situation-specific transformation methods for the modernization scenario considered, that is, for the transformation from Oracle Forms to Oracle ADF. We evaluate the fulfillment of this requirement by the feasibility study described in Section 7.2. In addition, we use the feasibility studies to demonstrate the fulfillment of non-functional requirements, like the compatibility of the fragments to ADM. To demonstrate the technology-independence of the method base, we performed a second feasibility study that is described in Section 7.3. In this study, we developed and enacted a transformation method for another modernization scenario, namely the transformation from Oracle Reports to Jasper Reports. 5.2.2 Method Patterns A method pattern is associated with a problem that shall be addressed by enacting a method. For this purpose, it encodes methodological knowledge in the form of construction guidelines for a method. In the case of MEFiSTo, a method pattern specifies which method fragments to customize and how to assemble them (cf. Section 2.2.1). The patterns proposed in this thesis have been observed in practice, when developing transformation methods for the transformation from Oracle Forms to Oracle ADF. Therefore, each proposed pattern is associated with the problem of transforming legacy systems into new environments. In this context, one particular problem is to retain the functionality of the original system [Bis+99]. The functionality preserving patterns address this issue by encoding methodological solutions. In particular, each pattern follows a specific transformation strategy, e.g., a pattern can follow a conversion or reimplementation-strategy. Besides retaining the functionality of a system, another problem is to adapt its structure to the new environment. This issue is addressed by the architectural restructuring patterns, which encode methodological solutions to change the architecture of a legacy system during its transformation. After having identified the patterns, we noticed that we can distinguish at least two types of them: atomic and non-atomic ones. The atomicity of a pattern arises from the fact that a pattern becomes invalid when any mandatory fragment is removed, that is, it does not fulfill its methodological purpose. In this thesis, we call an atomic method pattern a basic pattern. In contrast, non-atomic patterns arise by combining one or more basic patterns. In this thesis, we call them composed patterns. As each basic pattern follows a specific transformation strategy, composed patterns can be beneficial as their solution consists of combining different strategies. We describe basic patterns in Section 5.5, followed by composed patterns in Section 5.6. In MEFiSTo, the development of transformation methods can be seen as being pattern-based (cf. Section 4.1). In order to select one or multiple of the proposed patterns for a situation 5.2 Overview of the Structure 71 observed, it is essential to understand the characteristics of each pattern. Therefore, we describe each pattern according to the schema shown in Table 5.1 that we derived from the schema defined in [Gam+95, pp.6-7]. Intent Which problem does the pattern address? Strategy Which methodological solution does the pattern provide? Structure The structure of the pattern, depicted as a path in the horseshoe model (cf. Figure 5.4) Applicability In which situations is the pattern suitable? What are the most important influence factors on its efficiency or effectiveness? Preparation Which artifacts or tools have to be developed in advance of the transformation when applying the pattern? Example An example of the pattern’s application on the running example (cf. Section 4.3) Known Uses How do existing techniques relate to the pattern? What are examples of existing methods that (partially) conform to it? Related Patterns Relations to other patterns proposed Table 5.1 Schema to characterize method patterns The schema provides a condensed, tabular description that summarizes the most important characteristics of each pattern briefly. To understand these characteristics in detail, i.e., the rationale for each characteristic, we additionally provide an interrelated, extensive description. For this description we use the following structure: 1) Example For each pattern an example is introduced, i.e., a method that conforms to the pattern. The method specifies how to transform parts of the running example that has been described in Section 4.3. The application shall demonstrate how the pattern addresses the problem of transforming selected parts of an application into a new environment. It is used as a reference when discussing specific characteristics. 78 MEFiSTo Method Base Model Textual Artifact Manual Activity Activity Specification Artifact Specification Metamodel Reimplementation Guidance Code Generation Rules Model Transformation Rules Tool Tool Model Transformation Rules Definition Code Generation Rules Definition Reimplementation Guidance Specification Tool Definition Metamodel Definition Tool Specification Tool Developer Role Specification Role Figure 5.5 Method fragments of the tool implementation phase Based on this relation between the fragments of both phases, we derived the fragments for the tool implementation phase from the ones of the transformation phase. The resulting activities, artifacts and tools are shown in Figure 5.5. Artifacts & Activities We foresee six method fragments that constitute activities and corresponding artifacts. As automated transformations are based on the use of models, corresponding metamodels are required. The Metamodel Definition activity represents the definition of a required metamodel, while the artifact itself is specified by the Metamodel fragment. We use the term definition for the activity as we foresee different ways on how to realize the metamodel. First, a metamodel can be developed from scratch. However, in the context of a transformation method, metamodels are required for the programming languages that are used in the source or target environment. These metamodels are in general well-defined and stable. Therefore, secondly, existing metamodels can be reused if available. However, it might still be beneficial to adapt them to specific needs. Therefore, thirdly, profiles [Des00] can be used to adapt an existing metamodel. Various activities require the use of tools. Performing the Model Discovery activity requires using parsers, Program Comprehension can require reverse engineering tools and an Architectural Restructuring might require a clustering tool. The corresponding Tool Definition activity represents the development of such a required tool. Like metamodels, tools can be developed from scratch or an existing one can be used. Note that the output of this activity is not an artifact but a tool, in contrast to the other activities. Activities that constitute transformations between models are realized by automatically executed model transformations. The activity called Model Transformation Rules Definition represents the definition of required model transformation rules. The Model Transformation Rules fragment represents the output of the activity, that is, the resulting artifact. Similar 5.5 Basic Transformation Patterns 79 fragments are required for the Code Generation activity. The activity called Code Generation Rules Definition represents the definition of corresponding rules, while the Code Generation Rules fragment represents the resulting artifact. As the Reimplementation activity is performed manually by software developers, it needs to be guided. The activity called Reimplementation Guidance Specification represents the definition of such guidance. For example, a tool developer can provide a step-by-step instruction on how to perform the reimplementation. The Reimplementation Guidance fragment represents the corresponding artifact. Roles One role is associated with the tool implementation phase, namely a Tool Developer (cf. Section 4.1.3), for which we provide a corresponding method fragment. The tool developer is responsible for the activities introduced, e.g., the definition of metamodels, reimplementation guidance or any tool required. Therefore, we assume that a person in this role has comprehensive knowledge of model-driven engineering and developing reengineering tools. Tools In terms of tools, we have to distinguish between two types of tools: those, which are required by any transformation method and those, which have to be specifically developed for a method. On the one hand, some tools are required by each developed method that specifies to automate part of the transformation. For example, a model transformation engine is required to execute model transformation rules. Method fragments that describe these kinds of tools have already been introduced as part of the transformation phase fragments (cf. Section 5.3). On the other hand, some tools have to be specifically developed for a defined method. Examples encompass semantic analyzers, clustering or reverse engineering tools. We provide a generic fragment to specify these kinds of tools. 5.5 Basic Transformation Patterns In this section, we introduce a set of basic patterns, shown in Figure 5.6. Each pattern is associated with a path in the horseshoe model that we introduced in the previous Section (cf. Figure 5.4). The path visualizes the solution provided by a pattern, as it informally indicates which method fragments essentially or optionally shall be customized when applying it. For example, an application of the Reimplementation Pattern F3 requires customizing the Legacy 80 MEFiSTo Method Base Source Code artifact, the Reimplementation activity as well as the Transformed Source Code artifact. A formal description of the patterns is given at the end of this chapter in Section 5.7. Functionality Preserving Architectural Restructuring Reimplementation F3 Code Removal F4 Language Transformation F1 Conceptual Transformation F2 Platform-Independent Architecture Restructuring A2 Platform-Dependent Architecture Restructuring A1 Automated Activity Artifact or System Model Manual Activity Mandatory Optional Activities colored black Activities colored grey No Activity Figure 5.6 Basic transformation method patterns Subsequently, we begin introducing each pattern with an example, i.e., we describe the enactment of a method that conforms to the pattern. Thereby, the method is used to transform parts of the Summit legacy system which has been introduced as a running example in Section 4.3. We omit a description of the pattern A2 , as it differs only marginally from A1 . Its characterization can be found in the appendix (cf. Section A). So far, we described the functionality and architecture of Summit on a high level of abstraction. In particular, we omitted technical details and a mapping of the functionality into the target environment. In terms of the mapping, we use the one described in [RM11] that has been defined as part of a case study. For each mapping used, we provide a description of the technical background. We assume that a detailed technical example for each pattern is essential to create an understanding of its general characteristics. The first pattern we introduce is the Language Transformation Pattern. Its methodological solution to preserve functionality consists of converting it, using an automated, model-driven tool chain. 5.5.1 Language Transformation (F1) Intent Perform an automated transformation of the legacy system’s functionality into a new environment, following a conversion-based transformation strategy Continued on next page 5.5 Basic Transformation Patterns 81 Strategy Definition of a direct mapping between the programming languages of the environments involved. This is realized by representing the legacy system as a model of its ASG1on a platform-specific layer. A model transformation that transforms this model into an ASG1of the target environment is a realization of the mapping between the programming languages involved Structure Applicability Use when the functionality to transform is realized comparably in the legacy and target environment and the legacy system has a sufficient size. The difference in the realization determines the complexity of the mapping between the programming languages involved, influencing the efficiency and effectiveness of the pattern Preparation Applying this pattern essentially requires realizing a parser, model-to-model transformations and code generation rules. Also, it can be necessary to realize a semantic analyzer or model views Example Figure 5.7 shows the enactment of a method which conforms to the pattern. Thereby, the internal representation of database tables of the running example is transformed (cf. Section 4.3). Known Uses The strategy realized by the pattern is comparable to the strategy followed by a compiler. However, compiler design usually focuses on automating the transformation. In contrast, the pattern also enables developing semi-automatic methods, which can be necessary to end up with a situation-specific method. The method described in [Fuh+12, pp.174-178] conforms to the pattern Related Patterns / Table 5.2 Characterization of the Language Transformation Pattern 82 MEFiSTo Method Base Example This section is separated into three parts. First, we introduce the (i) technical background required to understand the example. Then, we describe the (ii) enactment of a method that conforms to the Language Transformation Pattern. As this is the first pattern we introduce, we describe how the method has been (iii) developed by using the MEFiSTo framework. Technical Background First, we need to understand the concept, i.e., the functionality, which we aim to transform. In this example, we aim to transform a part of the table-based data access functionality realized in the Summit application (cf. Section 4.3). More specifically, we demonstrate the transformation of the internal representation of the tables used (C1). Such an internal data structure is beneficial for a database-intensive application, as the underlying platform can take care of populating it and propagating changes made back to the database. Second, we need an understanding of how the concept is realized in the legacy system. In Oracle Forms-based applications like Summit, provided language constructs can be used to specify the structure of an internal representation, namely Blocks and Items [Ora00a]. We can distinguish two types of Blocks : those, which are associated to a database table (called data Blocks ), and those, which are not (called control Blocks ). Data Blocks can be seen as a placeholder for one or multiple datasets, i.e., rows of a database table. Blocks are an example for declarative language constructs provided by Oracle Forms. Such language constructs have associated properties to specify their details. For example, a Block has the property DatabaseBlock which can be set to True or False , indicating whether the Block is a data Block , or not. If a data Block is defined, the property named QueryDataSourceName is used to indicate the database table whose datasets the Block represents. Related to the Summit application, an excerpt of the definition of the Block called S_ORD can be seen in the artifact called Summit Block Source Code, shown in the lower left of Figure 5.7. It shows that S_ORD is a data Block which refers to the identically named table. In addition, a Block serves as a container for Items . Just like Blocks , there are control and data Items , indicated by the Boolean property DatabaseItem . A data Item can be seen as a placeholder for a field in a dataset, i.e., an entry in a column of a database table. Related to the Summit application, an excerpt of the definition of Items that are part of the S_ORD Block can also be seen in the figure. It shows the definition of various Items that store the ID of an order ( ID ), the ID and the name of a related sales representative ( SALES_REP_ID , SALES_REP_NAME ) as well as the ordering and shipping dates (DATE_ORDERED,DATE_SHIPPED). Blocks and Items can be used to define the structure of the internal representation of datasets. In order to transform this functionality, we also need to have knowledge of how the 1Depending on the situation, using an AST can be sufficient 5.5 Basic Transformation Patterns 83 Summit Block Source Code Summit Database S_ORD ID DATE_SHIPPED DATE_ORDERED SALES_REP_ID S_ORD :RDBTableDefinition ID :RDBColumnDefinition ID :RDBColumnDefinition S_EMP :RDBTableDefinition LAST_NAME :RDBColumnDefinition Summit Database Model Summit Entity Object Model <Entity Name="S_ORD_EO“> <Attribute Name="ID“ /> <Attribute Name="SALES_REP_ID“/> <Attribute Name="DATE_ORDERED“/> <Attribute Name="DATE_SHIPPED“/> </Entity> Summit Entity Object Source Code Discover Summit Blocks and SQL Statements Henshin Model Transformation Engine Discover Summit Database Tables Oracle Forms Source Code Parser and Semantic Analyzer DATE_ORDERED :RDBColumnDefinition Acceleo Code Generation Engine Oracle Database Parser Transform Internal Representation of Summit Database Tables Generate Summit Entity Objects S_ORD :EntityObject ID :EntityAttribute ID : EntityAttribute S_EMP : EntityObject LAST_NAME : EntityAttribute DATE_ORDERED :EntityAttribute SALES_REP_ID :RDBColumnDefinition SALES_REP_ID : EntityAttribute S_EMP ID FIRST_NAME LAST_NAME <Entity Name="S_EMP_EO“> <Attribute Name="ID“/> <Attribute Name="LAST_NAME“/> <Attribute Name="FIRST_NAME“/> </Entity> Data Flow Textual Artifact or System Model, Class or Associaton Control Flow Activity Tool TablesToEntityObjects Transformation EntityObjects Generation Template <Block Name="S_ORD" DatabaseBlock="True" QueryDataSourceName="S_ORD"> <Item Name="ID" DatabaseItem="True"/> <Item Name="SALES_REP_ID“ DatabaseItem="True"/> <Item Name="DATE_ORDERED" DatabaseItem="True"/> <Item Name="DATE_SHIPPED" DatabaseItem="True"/> <Item Name="SALES_REP_NAME“ DatabaseItem="False"/> <Trigger Name="POST-QUERY“ TriggerText="…“/> </Block> System Layer Platform-Specific Layer DATE_SHIPPED :RDBColumnDefinition DATE_SHIPPED :EntityAttribute FIRST_NAME :RDBColumnDefinition FIRST_NAME : EntityAttribute SALES_REP_ID :Item S_ORD :Block ID :Item SALES_REP_NAME :Item Summit Block and SQL Model DATE_ORDERED :Item :RDBSelectExpression E :RDBTableReference POST_QUERY :Trigger DATE_SHIPPED :Item Figure 5.7 Enacting a transformation method to transform the internal representation of database tables of the running example by using the Language Transformation Pattern connection to the underlying database is realized. In general, there are two ways to realize this connection: declaratively and imperatively. If a data Block defines a relation to a table using the QueryDataSourceName property, each Item whose name corresponds to a column in that table is populated automatically. In this way, the connection is realized declaratively, which is the case for most Items in the Summit application. The SALES_REP_NAME Item shown in the lower left of Figure 5.7 reveals that it is a control Item , as the DatabaseItem property is set to False . In fact, this Item is populated imperatively by executing code implemented as part of a Trigger . A Trigger is a declarative language construct that contains program code, written in the programming language PL/SQL. Each Trigger is executed automatically by the Forms runtime when an associated, predefined point in time is reached or an event occurs. Related to the Summit application, the SALES_REP_NAME Item is populated by the code contained in the TriggerText property of the Post-Query Trigger , shown in Listing 5.1. The Trigger belongs to the same Block as the Item and is executed after a dataset has been fetched by the runtime, but before the result is 84 MEFiSTo Method Base displayed to the user. Here, an SQL statement is executed that, among other things, retrieves the name of the sales representative and stores the result in the corresponding Item. 1SELECT E. last_name 2INTO :S_ORD.sales_rep_name 3FROM S_EMP E 4WHERE : S_ORD . sales_rep_id = E. id; Listing 5.1 Source code of the POST-QUERY Trigger which is a part of the S_ORD Block The reason for why different ways are used to realize the connection between the internal representation of datasets and the database can be seen by having a look at the database schema, shown in lower left side of Figure 5.7. While the S_ORD Block and most of its Items correspond to the S_ORD table and its attributes, the value of the SALES_REP_NAME attribute is retrieved from another table called S_EMP . In other words, the imperative program code joins both tables, using the SALES_REP_ID attribute as a foreign key. Besides knowledge of the concept and its realization in the legacy system, we thirdly need an understanding of how the concept shall be realized in the target environment Oracle ADF. Here, we will use the mapping described in [RM11, p.12]. In this case study, Entity Objects are used for the internal representation of the tables used by the application. Like a Block , an Entity Object can be used to represent a dataset stored in a table [Ora13]. It consists of a set of Entity Attributes that can correspond to columns of a table. Based on the description, one could get the impression that each Block needs to be transformed into an Entity Object , while Items need to be transformed to Entity Attributes . However, this is not the case as a Block does not necessarily represent a database table but rather a database view. An example is the S_ORD Block , which aggregates the data of multiple tables. Instead, we need to identify the tables that are actually used by the Summit application and create corresponding Entity Objects for them. Method Enactment The desired transformation is achieved by enacting the transformation method as shown in Figure 5.7. Note that most of the artifacts are presented shortened. The method consists of customized method fragments that have been introduced in Section 5.3 and is an instance of the Language Transformation Pattern. In the beginning, two activities need to be performed that are customizations of the Model Discovery fragment, namely the activities called Discover Summit Database Tables and Discover Summit Blocks and SQL Statements. The activities gather required information related to the functionality to transform and represent them homogeneously as an L-PSM. The Discover Summit Database Tables activity is performed automatically by using an Oracle Database Parser. During its performance, the schema of the database used by the application gets parsed. 5.5 Basic Transformation Patterns 85 This encompasses parsing the tables and their attributes as well as related details, like the data types. The output of the activity consists of a model representing the database schema. Related to the Summit application, the discovery of the tables S_EMP and S_ORD is shown in the lower left of Figure 5.7. Their parsing results in the Summit Database Model which conforms to the Generic Abstract Syntax Tree Metamodel (GASTM) defined in [OMG11a, pp.115-123]. The Discover Summit Blocks and SQL Statements activity is also performed automatically, but using an Oracle Forms Source Code Parser and Semantic Analyzer. Parsing Oracle Forms source code requires parsing the Forms-specific, declarative language constructs, like Blocks , but also the parts written in the imperative programming language PL/SQL. The output consists of a model representing the source code. Related to the Summit application, the discovery of the S_ORD Block is shown. The resulting model represents the Block and its Items as well as a decomposition of the SQL statement that is stored in the related Trigger . The model conforms to a Specialized Abstract Syntax Tree Metamodel (SASTM) [OMG11a] that has been defined for the programming language of Oracle Forms (cf. Section 2.1.3). Note that associations exist between the model of the source code and the model of the database. For example, the relation between the Block called S_ORD and the equally named table is represented by an association between the classes S_ORD:Block and S_ORD:RDBTableDefinition . This is due to the fact that the discovery step not only considers parsing, that is, syntactic analysis, but also semantic analysis [Aho+06, pp.8-9]. This results in the addition of semantic edges [KGW98], i.e., edges that do not belong to the tree structure of the AST, making the L-PSM an ASG (cf. Section 2.3.2). Here, the association between the data Block and the table to which it refers to is an example for such an edge. This analysis is also the reason why the discovery of the source code is performed after the discovery of the database tables. A model representing the tables is a prerequisite to resolve the targets of such edges. After the L-PSM has been created, it gets transformed into a T-PSM by performing the activity called Transform Internal Representation of Summit Database Tables. This activity is a customization of the Language Transformation fragment which prescribes to perform a direct transformation between the programming languages used. Here, this is realized by executing a set of model transformation rules by a corresponding engine that transform the L-PSM into the T-PSM. An excerpt of these rules for the example can be seen in Figure 5.8. Executing the rule TableToEntityObject instantiates an Entity Object class for each table that is referenced within a Form Module by a data Block . The ColumnToEntityAttribute rule instantiates the corresponding EntityAttributes . Note that these rules need to be executed repeatedly, as long as one of them is applicable. The resulting model is shown in the upper right side of Figure 5.7. It conforms to an SASTM [OMG11a] that has been defined for the programming language of Oracle ADF. 86 MEFiSTo Method Base TableToEntityObject :FormModule :RDBTableDefinition :EntityObject CreatePreserve Class or Association ColumnToEntityAttribute from from from from to :Block :Trace :Trace :RDBTableDefinition :EntityObject:Trace from to :EntityAttribute:Trace:RDBColumnDefinition :Trace Forbid from from to :EntityObject to :EntityAttribute to Figure 5.8 Excerpt of the model transformation rules to transform the L-PSM into the T-PSM As a last step, the code is generated based on the T-PSM by performing the activity called Generate Summit Entity Objects. This activity is a customization of the Code Generation fragment which describes the execution of a set of code generation rules by a corresponding engine to transform the T-PSM into textual source code. Here, a code generation technique is applied that is based on the use of an abstract definition of the code to generate [Her03, pp.87-96], which in this case is the role of the T-PSM. The T-PSM can be considered as a parameter for the code generation template in which variable parts are exchanged during execution. The resulting source code can be seen in the lower right side of Figure 5.7. In Oracle ADF, Entity Objects are defined by XML files, as shown. This concludes the description of the enactment of the method. Subsequently, we describe how it has been developed. Method Development The development of the transformation method occurs on the Method Specification Layer (M1) (cf. Section 2.2.3) in advance of its enactment. An overview of the development is shown in Figure 5.9. To clarify the relation between the activities and artifacts on the M0 and M1 Layer, the figure shows both layers and relationships between them. In the upper right of Figure 5.9, the performance of the activities called Situational Context Identification and Transformation Method Construction is shown. Both activities are core activities of the method engineering process of the MEFiSTo framework (cf. Section 4.1.2). Subsequently, we describe the activities in the context of the example. At this point, we do not go into detail but aim to motivate the fact that both activities are critical for the development of situation-specific transformation method. Details of these activities are described in Chapter 6. One purpose of the activity called Situational Context Identification is to gather knowledge that is required to develop the method. This knowledge at least encompasses the technical background that we described in the beginning of this section, i.e., knowledge of the functionality to transform, its realization in the legacy system as well as the desired realization in the target environment. Without this knowledge, informed decisions on how to perform the transformation would not be possible. In the example, without having knowledge of the 5.5 Basic Transformation Patterns 87 Method Base Method Specification Layer (M1) Method Enactment Layer (M0) Summit Block Source Code Summit Entity Object Source Code Discover Summit Database Tables Generate Summit Entity Objects Transform Internal Representation of Summit Database Tables Oracle Database Summit Entity Object Model Summit Block and SQL Model Discover Summit Blocks and SQL Statements Summit Database Model Transformation Method Specification Summit Database Summit Database Model Summit Entity Object Source Code Discover Summit Blocks and SQL Statements Henshin Model Transformation Engine Discover Summit Database Tables Oracle Forms Source Code Parser and Semantic Analyzer Acceleo Code Generation Engine Oracle Database Parser Transform Internal Representation of Summit Database Tables Generate Summit Entity Objects Summit Entity Object Model Removal Legacy Source Code Transformed Source Code Model Discovery Code Generation Language Transformation Database Model of the Transformed System’s Source Code and its Environment (M-PSM) Model of the Legacy System’s Source Code and its Environment (L-PSM) Reimplementation Method Fragments Method Patterns Data Flow Textual Artifact or System Instance Of Model, Class or Associaton Specification Layer (M1) Enactment Layer (M0) Control Flow Activity Tool Language Transformation F1 Enrichment Method Base Method Specification Transformation Method Construction Markus and Jan Summit Block Source Code TablesTo EntityObjects Transformation EntityObjects Generation Template Expert Activity Data Flow Control Flow Situational Context Identification Markus and Jan Summit Situational Context Model Legacy Source Code Summit Block and SQL Model Figure 5.9 Developing a transformation method to transform the internal representation of database tables of the running example by using the Language Transformation Pattern semantics of Blocks and their relation to database tables, it would not have been known that the discovery of the database schema is essential to transform the functionality. Another purpose of the activity is to perform an assessment of the method patterns stored in the method base, based on the gathered knowledge. This encompasses assessing whether a method pattern is applicable and estimating the effort required to apply it, e.g., the effort required to develop tools like parsers or model transformations. Note that this requires knowledge of the content of the method base. Here, we do not discuss whether the Language Transformation Pattern is the best fitting one for the situation observed, but assume that this is the case. The gathered information as well as the result of the assessment is preserved in the form of a Situational Context Model. 94 MEFiSTo Method Base Technical Background First, we need to have an understanding of the functionality to transform. In this example, we aim to transform another part of the table-based data access functionality (cf. Section 4.3). In this instance, we show how the pattern can be used to transform the attribute validation rules of the Summit application (C2). The validation rules are used to ensure that no invalid entries are stored persistently in the database. Second, we need an understanding of how the concept is realized in the legacy system. Oracle Forms provides a set of Triggers that can be used for this purpose, in particular, Triggers whose name begins with WHEN-VALIDATE [Ora00c, p.423]. These Triggers are invoked whenever the internal representation changes, for example due to a user input or a programmatic manipulation. An invocation leads to an execution of the associated, imperative source code that validates the changes made and raises an exception, if the validation fails. In the example, the WHEN-VALIDATE-RECORD Trigger , which is a part of the S_ORD Block , is such a Trigger . It can be seen in the lower left of Figure 5.10, as well as its contained source code. The purpose of this Trigger is to ensure that the shipping date of ordered goods is later than the ordering date of those goods. Technically, this verification is realized by an If -Statement that compares the value of the DATE_SHIPPED Item to the value of the DATE_ORDERED Item . If the shipping date is earlier than the ordering date, a message is shown to the user (cf. Figure 4.4, page 59) and an exception is raised. The exception would cancel an ongoing commit to the database. Besides knowledge of the concept and its realization in the legacy system, we thirdly need to have an understanding of how to realize the functionality in the target environment. In Oracle ADF, there exist two ways to realize such validation rules [Ora13]. On the one hand, the rules can be realized imperatively by using Java code. Such code would get invoked by an event, which is raised when an internal representation, i.e., an Entity Object , needs to be validated. On the other hand, Oracle ADF enables defining validation rules declaratively. For this purpose, a set of language constructs is provided that can be used to express the rules as part of the definition of Entity Objects. While the imperative realization comes close to how the functionality is currently realized in the legacy system, the declarative realization is favored by the mapping described in [RM11, pp.15-16]. This is due to the fact that Oracle suggests to use the declarative realization if possible, as it is associated with various benefits 3 . For example, declarative rules are executed by a dedicated framework which takes care of stacking exceptions. Imperative realizations shall only be used in complex scenarios that cannot be expressed declaratively. Therefore, the challenge is to transform an imperative realization into a declarative one (cf. Section 2.3.3). 3http://docs.oracle.com/middleware/1213/adf/develop/adf-bc-validation-rules.htm (accessed March 22th, 2016) 5.5 Basic Transformation Patterns 95 Rule_0 :CompareValidationBean ModelBundle :PropertiesBundle <validation:CompareValidationBean Name="OrdEO_Rule_0" OnAttribute="DateShipped" OperandType="ATTR" CompareType="GREATERTHANEQUALTO" CompareValue="DateOrdered"> <validation:OnAttributes> <validation:Item Value="DateShipped"/> <validation:Item Value="DateOrdered"/> </validation:OnAttributes> </validation:CompareValidationBean> <ResourceBundle><PropertiesBundle PropertiesFile="summit.model.ModelBundle"/> </ResourceBundle> summit.OrdEO_Rule_0= Ship date is before order date! :Trigger S_ORD :EntityObject DATE_SHIPPED :EntityAttribute DATE_ORDERED :EntityAttribute :BinaryExpression :AttributeOperand onChange onChange leftOperand attribute trigger assertion rightOperand WHEN-VALIDATE-RECORD :Trigger :BinaryExpression :IfStatement condition thenBody Less :BinaryOperatoroperator leftOperand :IdentifierReference DATE_ORDERED :Item S_ORD :Block DATE_SHIPPED :Item rightOperand :IdentifierReference :BlockStatement :FunctionCallExpression :ByValueActualParameterExpression :StringLiteral Value = “Ship date is before order date!“ :ThrowStatement <Block Name="S_ORD" <Trigger Name="WHEN-VALIDATE-RECORD“ TriggerText=" IF :S_ORD.date_shipped < :S_ORD.date_ordered THEN MESSAGE('Ship date is before order date!'); RAISE FORM_TRIGGER_FAILURE; END IF; “/> </Block> S_ORD :RDBTableDefinition DATE_SHIPPED :RDBColumnDefinition Summit Database Model DATE_ORDERED :RDBColumnDefinition Summit Block and Trigger Model Rule_0 :Key Value = “Ship date is before order date!“ errorMsg Summit Entity Validator Model :ValidationRule :ErrorMessage Value = “Ship date is before order date!“ DATE_SHIPPED :ColumnSet DATE_ORDERED :ColumnSet S_ORD :RelationalTable errorMsg :Trigger onChange trigger :BinaryExpression leftOperand rightOperand onChange Summit Validation Rule Model Summit Validation Rule Model Oracle Forms Source Code Parser and Semantic Analyzer Discover Summit Blocks and Triggers Oracle Forms Runtime API Parser Discover Oracle Forms Runtime Environment Oracle Database Parser Discover Summit Database Tables S_ORD DATE_SHIPPED DATE_ORDERED Henshin Model Transformation Engine Extract Summit Validation Rules Henshin Model Transformation Engine Concretize Summit Validation Rules Generate Summit Validation Beans Acceleo Code Generation Engine ValidationBean Generation Template :IdentifierReference ValidationRuleTo ValidationBean Transformation Summit ValidationStatementsTo ValidationRules Transformation Summit Database Data Flow Textual Artifact or System Model, Class or Associaton Control Flow Activity Tool Summit Block Source Code Summit Properties Bundle Source Code Summit Validation Bean Source Code System Layer Platform-Independent LayerPlatform-Specific Layer ValidationRule Restructuring Transformation :ValidationRule :ErrorMessage Value = “Ship date is before order date!“ DATE_SHIPPED :ColumnSet DATE_ORDERED :ColumnSet S_ORD :RelationalTable errorMsg :Trigger onChange trigger :BinaryExpression condition leftOperand rightOperand Oracle Forms Runtime Environment Oracle Forms Runtime Environment GreaterThanEqualTo :CompareType operator LessThan :Operator GreaterThanOrEqual :Operator operator operator Assertion :ValidationFailCondition :Validation validation validation Oracle Forms Runtime Environment Model :FunctionDefinition :FormalParameterDefinition FORM_TRIGGER_FAILURE :ExceptionType MESSAGE :Name MESSAGE_TEXT :Name Henshin Model Transformation Engine Restructure Summit Validation Rules Figure 5.10 Enacting a transformation method to transform the attribute validation rules of the running example by using the Conceptual Transformation Pattern Method Enactment The desired transformation is achieved by enacting the transformation method as shown in Figure 5.10. Note that most of the artifacts are presented shortened. The method consists of customized method fragments that have been introduced in Section 5.3 and is an instance of the Conceptual Transformation Pattern. 96 MEFiSTo Method Base In the method shown, the Model Discovery fragment has been customized three times to gather information associated with the functionality and represent it by an L-PSM. The activity called Discover Summit Database Tables is the same as the one described for the Language Transformation Pattern in Section 5.5.1. It is performed automatically by an Oracle Database Parser to parse the schema of the database used by the Summit application and create a corresponding model. Related to the Summit application, the discovery of the table S_ORD is shown in the lower center of Figure 5.10. Their parsing results in the Summit Database Model which conforms to the GASTM defined in [OMG11a, pp.115-123]. The activity called Discover Oracle Forms Runtime Environment is performed automatically using an Oracle Forms Runtime API Parser. Its purpose is to represent the runtime environment of Oracle Forms by modeling its Application Programming Interface (API). In this example, this comprises defined functions as well as exceptions. A textual description of the API could be a conceivable input for this activity. However, the method specifies to use a management interface of the runtime environment itself. As the interface is Java-based, the API can be extracted using the reflection capabilities of Java. The resulting Oracle Forms Runtime Environment Model conforms to the GASTM defined [OMG11a]. The activity called Discover Summit Blocks and Triggers is also performed automatically, but using an Oracle Forms Source Code Parser and Semantic Analyzer. Performing the activity requires parsing the source code of the Summit application, in particular, the Blocks and Triggers as well as their related properties. Related to the Summit application, the discovery of the S_ORD Block and the contained WHEN-VALIDATE-RECORD Trigger is shown in the lower left of Figure 5.10. The resulting Summit Block and Trigger Model represents these language constructs and, more importantly, the PL/SQL source code that is defined within the Trigger Text property. The model conforms to an SASTM [OMG11a] that has been defined for the programming language of Oracle Forms. Note that there exist edges between the Summit Block and Trigger Model and the Oracle Forms Runtime Environment Model, e.g., modeling the call of a function provided by the runtime environment. These edges are semantic edges that result due to a semantic analysis, making the model an ASG (cf. Section 2.3.2). After the L-PSM has been created, it gets transformed into a Functional Platform-Independent Model (F-PIM) by performing the Extract Summit Validation Rules activity. This activity is a customization of the Program Comprehension fragment and prescribes to perform reverse engineering. In particular, it prescribes to abstract from platform-specific language constructs by interpreting the L-PSM and representing the result on a platform-independent layer. Here, this is realized by executing a set of model transformation rules by a corresponding engine. At this point, we do not go into detail on the rules or how to develop them. The challenge of this transformation is discussed at the end of this section. 5.5 Basic Transformation Patterns 97 Related to the Summit application, the reverse engineering of the rule that validates the shipping and ordering dates is shown. The ASG that is part of the Summit Block and Trigger Model represents an imperative realization of that rule in the programming language PL/SQL. It can be seen that the rule is only described implicitly, i.e., specific knowledge is required to understand that this part of the source code is, in fact, a validation rule. Take for example the String Literal that is a parameter of the function call to the platform-specific function called MESSAGE . Just having knowledge of the semantics of the language constructs itself that are associated with the function call would not enable to understand the meaning of the literal. In this case, the key is on the one hand to know the semantics of the WHEN-VALIDATE-RECORD Trigger and on the other hand the structure of a validation rule. Then, interpreting the literal in this context reveals that it represents the error message for the case that the validation fails. The result of such an interpretation can be seen in the Summit Validation Rule Model, shown in the upper left of Figure 5.10. The model conforms to the KDM [OMG11b] that has partly been extended to represent validation rules. The validation rule of the example is represented by the equally named class Validation Rule. It can be seen that the concept of a validation rule is associated with three characteristics, represented as classes: a Trigger that determines when to evaluate the rule, a Validation that represents the condition to validate as well as an Error Message that shall be displayed in case that the validation fails. After the F-PIM has been created, its structure is changed by performing the activity called Restructure Summit Validation Rules. The activity is a customization of the Restructuring fragment and prescribes to perform changes on the F-PIM by an endogenous model transformation, i.e., the metamodel does not change. In terms of the Conceptual Transformation Pattern, this is an optional activity. Related to the Summit application, the result of the restructuring can be seen in the upper right of Figure 5.10. In the example, this intermediate activity is performed to bring the structure of the validation rule that has been reverse engineered from the legacy system closer to the desired structure in the target environment. In particular, two differences are addressed by the restructuring. First, the Trigger that determines when to evaluate the rule, is changed. In the legacy system, the rule is part of the WHEN-VALIDATE-RECORD Trigger so that it is always evaluated whenever any of the Items of the S_ORD Block changes. This means that it is also evaluated even when neither the DATE_SHIPPED nor the DATE_ORDERED changes. In this case, a triggering results in unnecessary computational effort, negatively influencing the performance. An unnecessary triggering of the rule could have been prevented by using Item -based Triggers , i.e., WHEN-VALIDATE-ITEM Triggers for the DATE_SHIPPED and the DATE_ORDERED Items . In this case, the evaluation would have only been triggered whenever these specific Items change. However, this would require duplicating the code that contains the validation rule, 98 MEFiSTo Method Base negatively influencing the maintainability. In other words, the restrictions in the legacy environment require making cuts in the performance or maintainability, as one validation rule cannot be related to multiple attributes, i.e., Items . In the target environment, this restriction is not present anymore. Therefore, the restructuring addresses the onChange association of the Trigger so that it refers to both attributes (represented as ColumnSets) afterwards. Second, the Validation that represents the condition to validate, is changed. In the legacy system, the condition is realized by an expression that checks for a failure. If the condition DATE_SHIPPED < DATE_ORDERED yields TRUE , then the rule is violated. In the target environment, the opposite needs to be expressed. Here, we do not need to (imperatively) check for a failure, but (declaratively) specify the assertion that needs to hold (cf. Section 2.3.3). In this example, the resulting assertion would be DATE_SHIPPED ≥DATE_ORDERED . Therefore, the restructuring addresses the Validation and Operator class by changing the type of the former and negating the latter. After the F-PIM has been restructured, it gets transformed into a T-PSM by performing the activity called Concretize Summit Validation Rules. The activity is a customization of the Concretization fragment and prescribes to perform forward engineering. In particular, it prescribes to express the functionality represented on a platform-independent layer by platform-dependent language constructs. Related to the Summit application, the result of the concretization can be seen in the center right of Figure 5.10. The Summit Entity Validator Model conforms to an SASTM [OMG11b] that has been defined for the programming language of Oracle ADF. It can be seen that for most classes a one-to-one mapping exists. For example, a Validation Rule is mapped to a Compare Validation Bean , whereby the latter represents a platform-specific construct. For some classes, a more complex mapping is required. For example, the Error Message is stored in separate properties file and only referenced by the validation rule. The intention is to be able to easily exchange the properties file later on, depending of the language chosen by the user. As a last step, code is generated based on the T-PSM by performing the activity called Generate Summit Validation Beans. As this activity does not differ from the one described for the Language Transformation Pattern, we omit a description and refer to Section 5.5.1. This concludes the description of an example for the Conceptual Transformation Pattern. Subsequently, we describe its generic characteristics. Description The Conceptual Transformation Pattern can be applied to transform the functionality of a legacy system into a new environment, following a conversion-based transformation strategy. The basic idea of how to transform the functionality is to explicitly represent it on a platform- 5.5 Basic Transformation Patterns 99 independent layer. This representation is extracted from the source code of the legacy system and mapped to source code in the target environment. More precisely, applying the pattern first requires representing the functionality to transform on the platform-specific layer as a platform-specific model of the legacy environment (L-PSM) by performing a model discovery. Then, the functionality to transform gets reverse engineered from the L-PSM and represented explicitly by a platform-independent model (F-PIM). By performing a concretization, the F-PIM is transformed into a platform-specific model of the target environment (T-PSM), which is subsequently used to generate source code. Just like the Language Transformation Pattern, the transformation strategy described by the Conceptual Transformation Pattern is related to the mechanics of a compiler, too. This is due to the fact that a transformation method which follows one of both patterns, enables transforming functionality, written in a source language, to functionality, written in a target language. The main difference between both patterns lies in the intermediate representations used, i.e., the structure of the middle-end (cf. Section 2.3.2). In the case of the Conceptual Transformation Pattern, an additional intermediate representation on a platform-independent layer is used. For a compiler, the use of a platform-independent intermediate representation is not unusual, especially, if the compiler supports multiple source and/or target languages [FCL09, p.395396]. The representation then enables the exchange of the frontor back-end, so that various combinations of source and target languages can be supported, while the middle-end can be reused. The same motivation led to the definition of the ASTM and KDM metamodels by the OMG. The use of standardized, platform-independent metamodels shall facilitate reusing of tools [UN10, pp.45-48]. In this sense, the pattern can be used to describe the mechanics of a compiler, too. On the other side, we see another important motivation for using a platform-independent intermediate representation, namely facilitating a separation on concerns. For the Language Transformation Pattern, we discussed that the model transformation which transforms the LPSM into the T-PSM needs to fulfill at least two concerns. First, the ASG needs to be interpreted to identify the functionality to transform. Second, the functionality needs to be mapped to language constructs of the target environment. Additionally, as demonstrated by the example, it can be necessary to restructure the functionality. When applying the Conceptual Transformation Pattern, these concerns are separated. First, the Program Comprehension activity addresses the interpretation. Then the functionality is Restructured before the Concretization activity addresses the subsequent mapping in the target environment. Based on our experience, this separation of concerns is especially beneficial if the functionality to transform is only implicitly described by the source code of the legacy system, i.e., an increased degree of program comprehension is required. In the example shown in Figure 5.10, 100 MEFiSTo Method Base interpreting the If Statement contained in the Trigger as a validation rule and identifying the different parts of the rule results in a complex mapping between the syntactic elements involved. Like for the Language Transformation Pattern, this can come at the expense of a decreased degree of automatism, but an increased degree of non-functional properties by enabling a mapping on native language constructs in the resulting system. An application of this pattern is described in [Fle+07]. In this work, an industrial application has been transformed from COOL:Gen to Cobol, using a model-driven transformation method. The method conforms to the Conceptual Transformation Pattern. First, a platform-specific model of the COOL:Gen source code is discovered. Then, this model is transformed into an intermediate representation that conforms to a self-defined, platform-independent metamodel called ANT. Based on this representation some restructurings are performed, before finally source code is generated in the target environment. Another example of a transformation method that conforms to the pattern is described in [SSG14]. In this work, graphical user interfaces developed in Oracle Forms and Borland Delphi are automatically converted to web pages. The transformation method uses platformindependent models of these user interfaces, namely Rapid Application Development (RAD) and Concrete User Interface (CUI) models as intermediate representations. This concludes the generic description of the pattern, whereby we discussed various characteristics. However, so far we did not discuss in which situations an application of the pattern is appropriate. This discussion is part of the next section. Suitability In terms on influences on the effectiveness, the desired target realization needs to be considered as an influence factor. Thereby, the argumentation is the same as for the Language Transformation Pattern: a deviation from the desired realization can reduce the complexity of activities. In the example, using an imperative realization in the target environment would ease the reverse engineering and make the restructuring unnecessary, therefore increasing the efficiency of the method. However, this comes to the expense of a decreased performance and maintainability, as the validation framework and the IDE support of the target environment could not be used. We want to point out that this argument applies for all patterns, also for the ones that are described subsequently. Therefore, we do not mention this factor for subsequent patterns. In general, we do not discuss factors in detail that have already been discussed for other patterns. In terms on influences on the efficiency, we observed the complexity of the program comprehension activity to essentially influence the efficiency of the pattern. For the example, we did not provide any details of how the transformation between the L-PSM and F-PIM is realized but assume that this activity describes the execution of a model transformation. 5.5 Basic Transformation Patterns 101 This is, for example, possible if code conventions exist that can be used to reliably extract the required information. However, often the reverse engineering activity consists of multiple steps, i.e., it is a process itself. For example, in [Cos+12] a framework is described to extract business rules from Java source code. The reverse engineering activity is performed semiautomatically, consisting of multiple steps and intermediate results. Therefore, the way in which some functionality is realized in the legacy system as well as how it shall be realized in the target environment needs to be considered as an influence factor to assess the complexity of the program comprehension activity. Nevertheless, we assume that this pattern is particularly efficient if the functionality to transform is realized in different ways in both environments. Apart from that, as discussed before, each method fragment that gets used when applying the method pattern needs to be evaluated to identify potential influence factors on its efficiency. As this pattern follows a conversion strategy, too, the size of the legacy system is an essential influence factor on its efficiency. In conclusion, we assume that the pattern is particularly suitable if the functionality to transform is realized significantly different in both environments while the source code to transform is sufficiently large. If the source code is not that large, the automation of the transformation might be inefficient. Then, the method pattern we introduce in the next section can be a viable alternative, as it follows a Reimplementation-based transformation strategy. 5.5.3 Reimplementation (F3) Intent Perform a manual transformation of the legacy system’s functionality into a new environment, following a reimplementation-based transformation strategy Strategy Provide guidance for software developers who manually reimplement the functionality in the target environment Structure Applicability Use when automatic approaches are either inefficient or ineffective. The amount of available developers and their experience has an essential influence on the efficiency and effectiveness of the pattern Continued on next page 102 MEFiSTo Method Base Preparation Applying this pattern essentially requires defining guidance documents to systematize the reimplementation. Example Figure 5.11 shows the enactment of a method which conforms to the pattern. Thereby, the internal representation of database views of the running example is transformed (cf. Section 4.3) Known Uses The strategy realized by the pattern is comparable to the implementation activity that is part of a software development endeavor. It can be seen as a specific type of implementation activity as some constraints need to be considered: the legacy system specifies the functionality to realize while guidance documents describe performed design decisions or required restructurings. The method described in [RM11] conforms to the pattern Related Patterns / Table 5.4 Characterization of the Reimplementation Pattern Example This section is separated into two parts. First, we describe the (i) background knowledge covering technical details of the example. Then, we describe the (ii) enactment of a method that conforms to the Reimplementation Pattern. Technical Background First, we need to have an understanding of the functionality to transform. In this example, we aim to transform the view-based data access functionality of the Summit application (cf. Section 4.3) as a whole. Primarily, this requires the transformation of the internal representation of the views (C3), i.e., its structure. Thereby, most attributes of a view are based on fields inside a database. However, in the Summit application, some attributes are calculated (C4) dynamically by an expression. We aim to transform these expressions, too. Lastly, views can be related to each other by view relations (C5), which cause that a selected dataset of one view determines the datasets of another view. Second, we need an understanding of how the concept is realized in the legacy system. As described for the Language Transformation Pattern in Section 5.5.1, data Blocks are used within an Oracle Forms application to specify views. Usually, most Items contained in such a Block relate to an underlying field in a database table. For Items whose value is calculated 5.5 Basic Transformation Patterns 103 dynamically by an expression, the property Calculation Mode is set to Formula , while the Formula property contains the actual expression. To specify relations between views, the Relation language construct can be used which is also contained within a Block . It has several properties to specify the relation, like the Join Condition property. Related to the Summit application, the realization of two views can be seen in the lower left of Figure 5.11. The Block called S_ORD defines a dialog-specific view to access ordering information, while the Block called S_ITEM defines a view on the items of a selected order. This dependency is realized by the Relation called S_ORD_S_ITEM , contained in the S_ORD Block . It defines a join-condition that is evaluated at runtime. In particular, the join is performed on the ID Item of the S_ORD Block and the ORDER_ID Item of the S_ITEM Block . In addition, the ITEM_TOTAL attribute that is part of the S_ITEM Block is not associated with a field in the database, but it is calculated. It represents the total costs of an ordered item, by multiplying the cost of one item with the amount ordered (cf. Figure 4.4, page 59). <ViewLink Name="S_ORD_S_ITEM_Link“> <ViewLinkDefEnd Source="True“/> <AttrArray Name="Attributes"> <Item Value="S_ORD_VO.ID“/> </AttrArray> </ViewLinkDefEnd> <ViewLinkDefEnd Source="True“/> <AttrArray Name="Attributes"> <Item Value="S_ITEM_VO.ID“/> </AttrArray> </ViewLinkDefEnd> </ViewLink> Data Flow Textual Artifact Control Flow Activity Summit View Object Source Code System Layer Reimplement Summit TableBased Views Reimplementation Guidance Identify each Block in the legacy application that is an internal representation of a database view. This is the case, if the property DatabaseBlock is set to True. If the property is False, WHEN-NEW-* Triggers need to be checked for a programmatic initialization. For each identified representation of a view, create a View Object. Thereby, the Items become View Attributes. If an Item is based on a field of a database table, either declaratively or programmatically, the View Attribute shall be based on the corresponding Entity Attribute that represents the field. Reimplement Summit Calculated Attributes Reimplement Summit View Relations Reimplementation Guidance The View Attributes that are not based on Entity Attributes are programmatically calculated. Identify the corresponding calculation rule by checking whether the Formula property of an Item is set. In the target system, set the Value Type property of the View Attribute to Expression and insert the identified calculation rule as Groovy expression. Reimplementation Guidance Database views can be related to each other in a Master-Detail Relationship. Identify such relations by searching for Relations that are contained by a Block. Use the identified Relation to create View Links in the target system. Summit Block Source Code <ViewObject Name="S_ITEM_VO“> <ViewAttribute Name="ID“/> <ViewAttribute Name="ORDER_ID“/> <ViewAttribute Name="ITEM_TOTAL“/> </ViewObject> Summit View Link Source Code Initial Node Final Node Tim and Max <ViewObject Name="S_ORD_VO“> <ViewAttribute Name="ID“/> <ViewAttribute Name="SALES_REP_ID“/> <ViewAttribute Name="DATE_ORDERED“/> <ViewAttribute Name="DATE_SHIPPED“/> <ViewAttribute Name="CUSTOMER_NAME“/> </ViewObject> Software Developers Tim and Max Tim and Max <FormModule Name="ORDERS“ <Block Name="S_ORD" DatabaseBlock="True" QueryDataSourceName="S_ORD"> <Item Name="ID" DatabaseItem="True"/> <Item Name="CUSTOMER_ID" DatabaseItem="True"/> <Item Name="DATE_ORDERED" DatabaseItem="True"/> <Item Name="DATE_SHIPPED" DatabaseItem="True"/> <Item Name="SALES_REP_ID“ DatabaseItem="False"/> <Relation Name="S_ORD_S_ITEM“ JoinCondition="…“/> </Block> <Block Name="S_ITEM“ DatabaseBlock="True" QueryDataSourceName="S_ITEM“> <Item Name="ID" DatabaseItem="True"/> <Item Name="ORDER_ID" DatabaseItem="True"/> <Item Name="ITEM_TOTAL“ CalculationModel="Formula“ Formula="…“/> </Block> </FormModule> Figure 5.11 Enacting a transformation method to transform the view-based data access of the running example by using the Reimplementation Pattern Besides knowledge of the concept and its realization in the legacy system, we thirdly need to have an understanding of how to realize the functionality in the target environment. Here, we will use the mapping described in [RM11, p.10-11,23]. In this case study, View Objects are used as an internal representation of database views. In Oracle ADF, there exist different ways on how to define View Objects . For example, they can be directly based on an 110 MEFiSTo Method Base Data Flow Textual Artifact Control Flow Activity Summit UI Source Code System Layer <FormModule Name="CUSTOMERS“> <Block Name="NAVIGATOR"> <Item Name="TREE_CUST" ItemType="HierarchicalTree“ Canvas="TREE“/> </Block> <Block Name="NAV_CONTROL“> <Item Name="EXPANDALL“ Canvas="TREE“> <Trigger TriggerText="…“/> </Item> <Item Name="COLLAPSEALL“ Canvas="TREE“> <Trigger TriggerText="…“/> </Item> </Block> <Canvas Name="TREE“ ProgramUnitText="…“/> <ProgramUnit Name="COLLAPSE_ALL“ ProgramUnitText="…“/> <ProgramUnit Name="EXPAND_ALL“ ProgramUnitText="…“/> </FormModule> Summit Block, Canvas and Program Unit Source Code <af:facet Name="TREE“> <af:tree id="TREE_CUST“/> </af:facet> Discover Summit Blocks and Canvases Oracle Forms Source Code Parser and Semantic Analyzer TREE: Canvas NAVIGATOR :Block Summit Block and Canvas Model CUSTOMERS :FormModule Item Type = Hierarchical Tree TREE_CUST :Item TREE :Facet Summit JSP Model TREE_CUST :Tree Transform Summit Canvases and UI Elements Henshin Model Transformation Engine UserInterface Transformation Platform-Specific Layer canvas Acceleo Code Generation Engine Generate Summit User Interfaces JSP Generation Template NAV_CONTROL :Block EXPANDALL :Item COLLAPSEALL :Item Model, Class or Associaton Tool Figure 5.13 Enacting a transformation method to transform the tree-based data selection of the running example by using the Code Removal Pattern to the fact that the affected parts of the source code do not need to be considered during the transformation. Therefore, the Code Removal Pattern can only be seen implicitly in Figure 5.13. It is applied on those parts of the source code that are not transformed. In this example, this comprises the Triggers contained by the Items called COLLAPSEALL and EXPANDALL , as well as related Program Units. This concludes the description of an example for the Code Removal Pattern. Subsequently, we describe the generic characteristics of this method pattern. Description The Code Removal Pattern can be applied to preserve the functionality of a legacy system by not transforming it. This is achieved by ignoring corresponding parts in the source code that represent the targeted functionality. 5.5 Basic Transformation Patterns 111 The transformation strategy described by this pattern is related to the mechanics of a compiler. In particular, we refer to a common optimization performed by compilers, i.e., the elimination of dead code [Aho+06, pp.591-592]. In this step, a compiler tries to identify parts of the source code that cannot be executed and are therefore not compiled. In certain instances this can be deduced by considering knowledge gained during the compilation, i.e., the use or the value of variables. Related to the development of transformation methods we need to essentially distinguish two cases, i.e., we need to distinguish for which reason it is not necessary to transform the code. On the one hand, the code might not be used in the legacy system, which can result when a system got continuously advanced. In fact, the presence of dead code is a common problem for legacy systems, wherefore it is usually addressed in a dedicated preparation phase [SWH10, pp. 106-107]. If some code gets removed during the transformation for that reason, then it is comparable to the elimination of dead code that we described. On the other hand, the code might not be necessary in the target environment, as the environment provides the functionality implicitly. An example for this type of code can be seen in Figure 5.13. As the target environment already provides the functionality to expand and collapse a tree, the source code that realizes this functionality imperatively needs not to be transformed. One could argue that the functionality is defined by the Tree construct so that the language constructs, e.g., the Program Units , are not removed but mapped to the Tree . However, we would argue that this is not the case as the model transformation that transforms the L-PSM into the T-PSM does not need to consider the Program Units . In the example, it only transforms Items of the type Hierarchical Tree . As a result, we are not able to continuously trace the Program Units from their definition in the source code of the legacy environment to the source code of the target environment. In general, this can be an indicator for the removal of code. In addition, one could argue if this pattern is required at all since it only prescribes to customize one method fragment that constitutes an artifact. In particular, no activities are defined. While this is true, the pattern enables some kind of marking source code that shall not be transformed. We assume that this is essential to enable the assessment of developed methods. In particular, it would not be possible to evaluate whether a transformation method is complete, i.e., whether it covers the whole legacy system. This concludes the generic description of the pattern, whereby we discussed various characteristics. However, so far we did not discuss in which situations an application of the pattern is appropriate. This discussion is part of the next section. 112 MEFiSTo Method Base Suitability In terms on influences on the effectiveness, the necessity of the source code on which the pattern is applied needs to be considered as influence factor. In fact, the pattern can only be effective if it is applied on source code that is not necessary. Otherwise, it will always be ineffective as functionality will be lost during the transformation Also in terms on influences on the efficiency, the necessity of the source code is the determining influence factor. If the code is not necessary, we assume the pattern to be the most efficient one as it requires the least effort, i.e., no effort. When applying the pattern on necessary code, its efficiency does not need to be considered as it yields an erroneous transformation. In conclusion, we assume that the pattern shall be applied if it is not necessary to transform the functionality, since it is not used by the legacy system or since it is implicitly provided by the target environment. So far, we focused on patterns to transform some functionality. In the next section, we introduce a pattern to restructure the architecture of a legacy system during its transformation. 5.5.5 Platform-Dependent Architecture Restructuring (A1) Intent Perform an automated restructuring of a legacy system‘s architecture during its transformation into a new environment Strategy An intermediate representation of the system’s architecture is used on a platform-independent layer. The representation is reverse engineered from an ASG 4 of the legacy system on a platform-specific layer. After a restructuring, it is transformed into an ASG4of the target environment Structure Continued on next page 5.5 Basic Transformation Patterns 113 Applicability Use when the architecture of the system to transform differs in the source and in the target environment and if the difference is too significant to perform the restructuring implicitly when converting the functionality. In addition, the structures that imply the architecture of the system and those that are affected by the restructuring need to reside in models on the platform-specific layer Preparation Applying this pattern requires realizing model transformations rules. In addition, it can be necessary to realize dedicated architecture recovery algorithms or model views Example Figure 5.14 shows the enactment of a method which conforms to the pattern. Thereby, the modularization of the running example is changed (cf. Section 4.3) Known Uses The strategy realized by the pattern is comparable to the strategy followed by architectural reengineering tools. The method described in [Hec+08] conforms to the pattern Related Patterns Similar to A2 Table 5.6 Characterization of the Platform-Dependent Architecture Restructuring Pattern Example This section is separated into two parts. First, we describe the (i) background knowledge covering technical details of the example. Then, we describe the (ii) enactment of a method that conforms to the Platform-Dependent Architecture Restructuring Pattern. Technical Background First, we need to have an understanding of the concept on which this pattern shall be applied. In contrast to the other patterns introduced, this one does not enable to transform some functionality but to restructure the architecture of a system during its transformation. Therefore, we need to have an understanding of the architectural structure we aim to change. Related to the Summit application (cf. Section 4.3), we aim to change its modularization (C8). In addition, we demonstrate the impact of this change on the transformation of the internal representation of the tables used (C1). 4Depending on the situation, using an AST can be sufficient 114 MEFiSTo Method Base Second, we need an understanding of how the concept is realized in the legacy system. Any Forms-based system consists of a set of modules. While there are different types of modules, each module is stored in a dedicated file. In the example, we only consider Form Modules which contain the definition of user interfaces, source code routines as well as data connections. Related to the Summit application, we use the ORDERS and CUSTOMERS Form Modules to exemplify the application of the pattern. An excerpt of their source code can be seen in the lower left of Figure 5.14. Note that we do not discuss the realization and mapping of the internal representation of the tables used. Instead, we refer to Section 5.5.1 where this has been discussed in great detail. Besides knowledge of the concept and its realization in the legacy system, we thirdly need to have an understanding of how to realize the functionality in the target environment. In Oracle ADF, the modularization can be defined for each layer separately (cf. Section 3.1), e.g., for the data as well as for the view layer. In the example, we focus on the modularization of the data layer and use a Model Project for this purpose. This is a simplification, as the equivalent to a module in Oracle Forms would rather be an Application Module than a Modeling Project . However, we assume that all data connections contained in that project are later on bundled as one Application Module , which acts as a container for defined data connections [Ora13] Finally, we need to have an understanding of the way in which the architecture shall be restructured. In the example, we apply the mapping described in [RM11, p.8] which suggests merging all modules of the application. It is stated that larger applications might require a more complex restructuring, but merging is suitable for the Summit application. For a more complex restructuring, we refer to the feasibility study described in Section 7.2. Method Enactment The desired transformation is achieved by enacting the transformation method as shown in Figure 5.14. Thereby we want to point out that the method does not conform to the Platform-Dependent Architecture Restructuring Pattern. Instead, the combined use of two method patterns is shown: The internal representation of database tables is transformed by applying the Language Transformation Pattern (cf. Section 5.5.1), while the modularization is changed by applying the Platform-Dependent Architecture Restructuring Pattern. The reasons for that equal the reasons for the Code Removal Pattern (cf. Section 5.5.4). On the one hand, the application of the pattern can be observed best when demonstrating its impact on other patterns. On the other hand, it is another example for a composed pattern. Related to the transformation of the internal representation of database tables, we do not provide a detailed description of the method parts but refer to the example provided in Section 5.5.1. First, a syntactic and semantic analysis is performed by enacting the activities 5.5 Basic Transformation Patterns 115 Summit Database Model Summit Block and SQL Model Summit Component Model Henshin Model Transformation Engine Extract Summit Component Architecture Henshin Model Transformation Engine Concretize Summit Component Architecture Henshin Model Transformation Engine Restructure Summit Component Architecture Generate Summit Model Project Acceleo Code Generation Engine ComponentTo ModelProject Transformation Data Flow Textual Artifact or System Model, Class or Associaton Control Flow Activity Tool System Layer Platform-Independent LayerPlatform-Specific Layer MergeModules Transformation ORDERS :Component Discover Summit Blocks and SQL Statements Discover Summit Database Tables Oracle Forms Source Code Parser and Semantic Analyzer Oracle Database Parser S_EMP ID <FormModule Name="ORDERS“> <Block Name="S_ORD" DatabaseBlock="True" QueryDataSourceName="S_ORD"> <Trigger Name="POST-QUERY“ TriggerText="…“/> </Block> </FormModule> <FormModule Name="CUSTOMERS“> <Block Name="S_CUSTOMER“ DatabaseBlock="True" QueryDataSourceName=„S_CUSTOMER“> <Trigger Name="POST-QUERY“ TriggerText="…“/> </Block> </FormModule> S_ORD ID S_CUSTOMER ID ID :RDBColumnDefinition S_CUSTOMER :RDBTableDefinition ID :RDBColumnDefinition S_EMP :RDBTableDefinition ID :RDBColumnDefinition S_ORD :RDBTableDefinition S_CUSTOMER :Block :RDBSelectExpression E :RDBTableReference CUSTOMERS:FormModule POST_QUERY :Trigger S_ORD :Block :RDBSelectExpression E :RDBTableReference ORDERS:FormModule POST_QUERY :Trigger Henshin Model Transformation Engine Transform Internal Representation of Summit Database Tables TablesTo EntityObjects Transformation S_ORD :EntityObject ID :EntityAttribute ID : EntityAttribute S_EMP : EntityObject Summit :ModelProject ID : EntityAttribute S_CUSTOMER : EntityObject <Entity Name="S_ORD_EO“> <Attribute Name="ID“/> </Entity> <Entity Name="S_CUSTOMER_EO“> <Attribute Name="ID“/> </Entity> <JboProject Name="Model“> <Containee Name="entities“ PackageName="oracle.summit.model.entities“/> </JboProject> <Entity Name="S_EMP_EO“> <Attribute Name="ID“/> </Entity> CUSTOMERS :Component Summit :Component Summit Component Model Summit Model Project Model Summit Database Summit Block Source Code Summit Model Project Source Code FormModuleTo Component Transformation Figure 5.14 Enacting a transformation method to transform the architecture of the running example by using the Platform-Dependent Architecture Restructuring Pattern called Discover Summit Database Tables and Discover Summit Blocks and SQL Statements to retrieve a model of the database and the ASG of the source code Then, by performing the activity called Transform Internal Representation of Summit Database Tables, a model transformation is executed that transforms the L-PSM into the T-PSM. In particular, the tables and columns of the database model are transformed to Entity Objects and Entity Attributes . As a last step, performing the activity called Generate Summit Model Project generates corresponding source code for the target environment. 116 MEFiSTo Method Base The three activities shown in the upper part of Figure 5.14 result from applying the PlatformDependent Architecture Restructuring Pattern. At first, an A-PIM gets created by enacting the activity called Extract Summit Component Architecture. This activity is a customization of the Architecture Recovery fragment and prescribes to perform reverse engineering. In particular, it prescribes how to reconstruct the architecture of the application by interpreting the L-PSM and representing the result on a platform-independent layer. Related to the Summit application, we extract the architecture by transforming each Form Module instance into an architectural Component which represents a unit of composition [Szy02, p.548]. In general, components can have dependencies to each other. In the case of the example, this could be navigation flows between contained dialogs (cf. Section 4.3). However, to realize the intended restructuring, it was not required to extract them. The resulting model can be seen in the upper left of Figure 5.11, it conforms to the KDM [OMG11b]. As a second step, the architecture gets restructured by modifying the content of the A-PIM using an endogenous model transformation. This is achieved by enacting the activity called Restructure Summit Component Architecture, which is a customization of the Architecture Restructuring fragment. Related to the Summit application, the restructuring consists of merging all Components. The resulting model can be seen in the upper right of Figure 5.11. Finally, the changed architecture of the application gets concretized in the new environment. In particular, the A-PIM is used to create parts of the T-PSM by applying an exogenous model transformation. This is achieved by enacting the activity called Concretize Summit Component Architecture, which is a customization of the Architecture Concretization fragment. Related to the Summit application, a model transformation creates a Model Project instance in the T-PSM for each Component that is contained in the A-PIM. The resulting model can be seen in the middle right of Figure 5.11. Note that the T-PSM plays an important role in the integration of both patterns, as it is an input to the activity called Transform Internal Representation of Summit Database Tables. This data flow dependency makes the Language Transformation Pattern (cf. Section 5.5.1) dependent on the (result of the) Architecture Restructuring Pattern. From a functional perspective, this is due to the fact that each Entity Object needs to be associated to a Model Project which is only created by the architecture concretization activity. This concludes the description of an example for the Platform-Dependent Architecture Restructuring Pattern. Subsequently, we describe its generic characteristics. Description The Platform-Dependent Architecture Restructuring Pattern can be applied to change the architecture of a legacy system during its transformation into a new environment. The basic 5.5 Basic Transformation Patterns 117 idea of how to restructure the architecture is to use an explicit representation of it on a platformindependent layer. This representation is extracted from the source code of the legacy system and mapped to source code in the target environment. More precisely, applying the pattern first requires extracting the architecture of the system to transform on the platform-independent layer as a platform-independent model (A-PIM) by performing an architecture recovery. Then, an architecture restructuring changes the architecture as desired by modifying the A-PIM. By performing an architecture concretization, the A-PIM is transformed into a platform-specific model, i.e., the architecture is realized by platform-specific concepts. The transformation strategy described by this pattern is related to the strategy followed by architectural reengineering tools. In particular, these tools usually realize three activities, namely architecture recovery,architecture transformation and architecture design [KWC98]. Since the intentions of the processes correspond to the intentions of the three activities that are prescribed by the pattern, the pattern can be used to describe the mechanics of an architectural reengineering tool. The pattern is similar to the Platform-Independent Architecture Restructuring Pattern ( A2 ). Both patterns only differ in the source of the architecture restructuring activity, i.e., whether a platform-specific or platform-independent representation of the legacy system is used. Thereby, the abstraction layer to use depends on where the information is described that is required to extract the architectural model. In the example, the Components are extracted directly from the Form Modules that are represented in the L-PSM. Assume that an F-PIM would be used in which Form Modules are represented by platform-independent Modules . Then, the architectural model could be extracted from the F-PIM instead. We want to point out that the relation between the A-PIM and models on a lower level of abstraction is slightly different than the relation between the F-PIM and models on a lower level of abstraction. If an instance of some functionality to transform is represented in the L-PSM and F-PIM, then the only information that gets lost is how the functionality was realized in the legacy environment. But, the functionality described is the same in both models, i.e., it is redundant. In contrast, this is not the case for the content of the architectural model. The architectural entities contained do not represent the functionalities described by the models on a lower level of abstraction but aim to represent greater coherences. This can, for example, be achieved by aggregating information contained in platform-specific models. This can also be seen in the example when considering the difference between the Form Modules and the Components shown. While both seem to be similar, a Form Module is solely a representation of a source file. The S_ORD Block is contained by it, but the Form Module does not represent it. In contrast, the corresponding Component is a representation of the entire Form Module. 118 MEFiSTo Method Base An application of this pattern is described in [Hec+08]. In this work, a Java-based application that has a two-tier architecture is transformed to conform to a three-tier architecture. This is achieved by extracting an A-PIM that represents the layer each code block belongs to. A restructuring activity on this model introduces a new layer and moves code blocks based on defined rules. Finally, the changes are reflected back to the source code. This concludes the generic description of the pattern, whereby we discussed various characteristics. However, so far we did not discuss in which situations an application of the pattern is appropriate. This discussion is part of the next section. Suitability In terms on influences on the effectiveness, we need to consider that this pattern differs from the other patterns by the fact that it is always optional. Transforming a legacy system as part of a software modernization essentially requires retaining its functionality, which can be achieved by applying any of the patterns introduced earlier. In contrast, the Platform-Dependent Architecture Restructuring Pattern enables performing some restructurings explicitly on an architectural layer, which is not required to preserve the functionality. However, if an architectural restructuring is desired, transformations that preserve the functionality need to implicitly consider this restructuring. For example, in the case of a Language Transformation Pattern, the direct model transformation between the L-PSM and T-PSM needs to realize this restructuring, in addition to the mapping between the programming languages used. As discussed in Section 5.5.1, this would increase the complexity of the model transformation which can, in turn, decrease the effectiveness. By using the Architecture Restructuring Pattern, the concern of extracting and restructuring the architecture can be separated from the preservation of the functionality. Intuitively, the resulting architectural model can be used to parameterize transformations on a lower level of abstraction, possibly making them effective. Therefore, influences on the effectiveness are implicitly given by the influence factors of the other patterns. In terms on influences on the efficiency, we observed the complexity of the architecture recovery and restructuring activities to essentially influence the efficiency of the pattern. In the example, we used a simple one-to-one mapping between Form Modules and Components to extract an architectural model while subsequently merging all resulting Components . However, in general, architecture recovery and restructuring are complex endeavors that can require applying pattern-matching or clustering techniques. In conclusion, we assume that the pattern is particularly suitable if the architecture of the system in the source and in the target environment differs significantly, while large parts of the functionality are converted so that dependent transformations benefit from the architectural 5.6 Composed Transformation Patterns 119 model. As can be seen in the example shown in Figure 5.14, patterns can be related to each other. In the next Section, we introduce a set of composed patterns that result by combining two or more of the method patterns introduced so far. 5.6 Composed Transformation Patterns In this section, we introduce a set of composed patterns, shown in Figure 5.15. A composed pattern results from combining two or more basic patterns. An example is the transformation method described in section 5.5.5. The method is a result of applying the Platform-Dependent Architecture Restructuring Pattern and the Language Transformation Pattern. Based on the example, it could be seen that some integration effort is necessary so that an integrated transformation method results. In particular, the data flow needed to be precisely defined as part of the integration in order to ensure that activities which originate from different patterns are performed in a correct order. In general, the use of a composed pattern always requires integration of the method fragments that originate from different patterns. Therefore, such integration is an essential part of the method engineering process of MEFiSTo. The integration is addressed in detail in Section 6.4.2. To understand the usefulness of this additional set of patterns, we need to distinguish two cases: a composed pattern can either emerge implicitly or be applied explicitly. A composed pattern emerges implicitly if a legacy system is divided into distinct parts, whereby different basic patterns are applied on different parts to transform the contained functionality. Then, the integration needs to be addressed retrospectively. Providing a set of composed patterns as part of the method base enables considering the combined use of basic patterns prospectively. Based on our observations, this offers at least two benefits. On the one hand, it prevents the need for a fine-granular description of the functionality of the system to transform. In this sense, it provides an additional degree of freedom in the specification of the functionality. On the other hand, it enables considering integration effects during the development of a method explicitly. This allows a fine-granular adaptation of the method to the situation at hand. Subsequently, we introduce the composed patterns in the same way as we introduced the basic patterns in Section 5.5. However, in contrast to the basic patterns, we do not describe each composed pattern but only selected ones, i.e., patterns F5 and F7 . This is due to the observation that the difference in the characteristics between the basic and the composed patterns only arises due to integration effects. Therefore, we focus on covering all integration effects but not all patterns. Nevertheless, the characteristics of patterns that have not been described can be found in the appendix (cf. Section A). 126 MEFiSTo Method Base In MDA, models are used on various levels of abstraction during the development, whereby the lowest level is the platform-specific layer [OMG14]. The PSM on that layer is interpreted and executed directly, or, it is used to generate code. Code can be completely or partially generated. In the last case, developers implement missing parts manually [BCW12, p.29]. In comparison, the method that results when applying the Language Transformation-Based Reimplementation Pattern only differs in two main aspects. First, the instantiation of the PSM differs. While in an MDA-based process a PSM results from transforming a PIM, the pattern prescribes to instantiate it from another PSM. Intuitively, a compiler-based approach is applied to enable a lateral entry into an MDA-based development process. From this point on the process is the same except for, secondly, the way in which the developers are guided. In particular, the information source differs. While in an MDA-based process the PSM shall contain all information required for reimplementation [BCW12, p.41], the legacy system always takes this role in case of a modernization. Note that the information source can be shifted, which can be seen based on the method shown in Figure 5.16. In the example, it would actually not be necessary to access the source code in order to reimplement the validation rules, as all required information are contained. This can be beneficial if a context change for the software developers is prevented, i.e., they do not need to leave their development environment but find all relevant information there. On the one hand, this can be seen as a synergy effect resulting from the integration of both pattern. On the other hand, this creates a dependency of reimplementation activities on the output of the language transformation. If the source code of the legacy system is directly used, reimplementation activities could also be performed in parallel. However, integration always needs to be considered, either implicitly or explicitly. To some degree, an application of this pattern is described in [Fuh+12, pp.170-174]. In this work, a model-driven transformation from a client-server to a Service Oriented Architecture (SOA) has been performed as a case study. First, the legacy system was represented as a platform-specific model. However, no language transformation was performed but some kind of restructuring as corresponding parts of the model have been identified that form a service. For each part identified, code has been generated based on the PSM that is not complete but reimplemented manually by developers afterwards. This concludes the generic description of the pattern, whereby we discussed various characteristics. However, so far we did not discuss in which situations an application of the pattern is appropriate. This discussion is part of the next section. 5.6 Composed Transformation Patterns 127 Suitability In terms on influences on the effectiveness, we have to consider the influence factors of the basic patterns that result when decomposing this composed one. For those parts of the functionality that shall be automatically converted, we need to consider the realization in the legacy system as well as the desired realization in the target environment as essential influence factors. As discussed in Section 5.5.1, these factors influence the complexity of the model transformation between the L-PSM and T-PSM. This, in turn, can lead to a deviation from an initially desired realization, negatively influencing the effectiveness. For those parts of the functionality that shall be reimplemented, the skills of the software developer that perform the reimplementation activity need to be considered as an essential influence factor. As discussed in Section 5.5.3, the developers always have a certain degree of freedom when performing reimplementation activities. Therefore, the effectiveness can depend on the micro design-decisions they perform. Also in case of influence factors on the efficiency we need to consider the influence factors of the underlying basic patterns. For those parts of the functionality that shall be automatically converted, the effort to develop a syntactic and/or semantic analyzer, metamodels and code generation rules needs to be considered. In addition, the complexity of the model transformation on the platform-specific layer as well as the size of the functionality to convert are essential influence factors. For those parts of the functionality that shall be reimplemented, the amount of developers available as well as their skills form essential influence factors. Also, the size of the part of the functionality to reimplement needs to be considered. It should be sufficiently small so that an automatic conversion would be inefficient. In conclusion, we assume that the pattern is particularly suitable if large parts of the functionality to transform are realized comparably in both environments while the overall source code to transform is sufficiently large. That parts of the functionality that are realized significantly different should not be too large while developers should be familiar with the target environment. Based on the description of this pattern, it could be seen that the integration of an automated conversion and a manual reimplementation needs to be carefully considered. Subsequently, we describe another special integration effect that can arise when integrating conversion-based transformation strategies that rely on the use of different levels of abstraction. 128 MEFiSTo Method Base 5.6.2 Concept Recognition-Based Language Transformation (F7) Intent Perform an automated transformation of the legacy system’s functionality into a new environment, following a conversion-based transformation strategy Strategy Use an intermediate representation of parts of the functionality to transform on a platform-independent layer to enhance a direct mapping between the programming languages of the environments involved. The intermediate representation is reverse engineered from an ASG6of the legacy system on a platform-specific layer. When the ASG6of the legacy system is transformed into an ASG6of the target environment, the model transformation used is dependent on the transformation of the intermediate representation Structure Applicability Use when the functionality to transform is realized significantly different in the legacy and target environment and when the complexity of a direct transformation becomes low if parts of the functionality are made explicit. Also, the legacy system needs to have a sufficient size. The use of an intermediate representation can reduce the complexity of a direct transformation by separating the concerns of reverse engineering, restructuring and mapping the functionality. The manifestation of these concerns essentially influences the efficiency and effectiveness of the pattern Preparation Applying this pattern essentially requires realizing a parser, model-to-model transformations and code generation rules. In addition, it can be necessary to realize a semantic analyzer, dedicated reverse engineering algorithms or model views Continued on next page 5.6 Composed Transformation Patterns 129 Example Figure 5.17 shows the enactment of a method of a method. Thereby, the internal representation of database views of the running example is transformed (cf. Section 4.3) Known Uses The strategy realized by the pattern is comparable to the strategy followed by a compiler that uses an abstract representation of the source code to compile in order to optimize the result. The method described in [San14, pp.197-199] conforms to the pattern Related Patterns Combines F1, F2and F4 Table 5.8 Characterization of the Concept Recognition-Based Language Transformation Pattern Example This section is separated into two parts. First, we describe the (i) background knowledge covering technical details of the example. Then, we describe the (ii) enactment of a method that conforms to the Concept Recognition-Based Language Transformation Pattern. Technical Background First, we need to have an understanding of the functionality to transform. In this example, we aim to transform the view-based data access functionality (cf. Section 4.3). In particular, we show how the pattern can be used to transform the internal representation of the views (C3). We do not go into detail on how these functionalities are realized in the legacy system and shall be realized in the target environment. Instead, we refer to Section 5.5.3 where this has been described in great detail. In short, database views are defined by Blocks and Items in Oracle Forms, while they are mapped to View Objects and corresponding View Attributes in Oracle ADF. While the pattern exemplifies the transformation of the internal representation of database views, we additionally assume how the internal representation of database tables are transformed. In particular, we assume that the mapping that has been described in detail in Section 5.5.1 is applied. In short, database tables that are referenced by Items or imperative source code in Oracle Forms are represented by Entity Objects and corresponding Entity Attributes in Oracle ADF. 6Depending on the situation, using an AST can be sufficient 130 MEFiSTo Method Base <ViewObject Name="S_ORD_VO“> <ViewAttribute Name="ID“ EntityAttrName="ID“ EntityUsage="S_ORD_EO“/> <ViewAttribute Name="SALES_REP_ID“ EntityAttrName="SALES_REP_ID“ EntityUsage="S_ORD_EO“/> <ViewAttribute Name="DATE_ORDERED“ EntityAttrName="DATE_ORDERED“ EntityUsage="S_ORD_EO“/> <ViewAttribute Name="DATE_SHIPPED“ EntityAttrName="DATE_SHIPPED“ EntityUsage="S_ORD_EO“/> <ViewAttribute Name="SALES_REP_NAME“ EntityAttrName="LAST_NAME“ EntityUsage="S_EMP_EO“/> </ViewObject> Summit View Model Summit View Object Source Code System Layer Platform-Independent LayerPlatform-Specific Layer Summit Block Source CodeSummit Database S_ORD ID DATE_SHIPPED DATE_ORDERED SALES_REP_ID SALES_REP_ID :Item S_ORD :Block S_ORD :RDBTableDefinition ID :RDBColumnDefinition PrimaryKey = True ID :Item Summit Block and SQL Model Summit Database Model DATE_ORDERED :ItemDATE_ORDERED :RDBColumnDefinition SALES_REP_ID :RDBColumnDefinition <Block Name="S_ORD" DatabaseBlock="True" QueryDataSourceName="S_ORD"> <Item Name="ID" DatabaseItem="True" /> <Item Name="CUSTOMER_ID" DatabaseItem="True"/> <Item Name="DATE_ORDERED" DatabaseItem="True"/> <Item Name="DATE_SHIPPED" DatabaseItem="True"/> <Item Name=„SALES_REP_NAME“ DatabaseItem="False"/> <Trigger Name="POST-QUERY“ TriggerText="…"/> </Block> S_ORD :EntityObject ID :EntityAttribute DATE_ORDERED :EntityAttribute SALES_REP_ID : EntityAttribute Summit View Object Model DATE_SHIPPED :RDBColumnDefinition FIRST_NAME S_EMP ID LAST_NAME ID :RDBColumnDefinition S_EMP :RDBTableDefinition LAST_NAME :RDBColumnDefinition FIRST_NAME :RDBColumnDefinition DATE_SHIPPED :Item SALES_REP_NAME :Item :RDBSelectExpression E :RDBTableReference POST_QUERY :Trigger DATE_SHIPPED :EntityAttribute S_EMP :EntityObject ID :EntityAttribute FIRST_NAME :EntityAttribute LAST_NAME : EntityAttribute S_ORD :EntityBasedViewObject PrimaryKey = True ID :ViewAttribute DATE_ORDERED :ViewAttribute SALES_REP_ID :ViewAttribute DATE_SHIPPED :ViewAttribute SALES_REP_NAME :ViewAttribute S_ORD :TableBasedView ID :TableBasedAttribute DATE_ORDERED : TableBasedAttribute SALES_REP_ID : TableBasedAttribute DATE_SHIPPED : TableBasedAttribute SALES_REP_NAME : TableBasedAttribute To From To Oracle Forms Source Code Parser and Semantic Analyzer Discover Summit Blocks and SQL Statements Oracle Database Parser Discover Summit Database Tables Oracle Forms Source Code Parser Generate Summit View Objects ViewObjects Generation Template Extract Summit Views Transform Internal Representation of Summit Database Views :Trace Trace Model Concretize Summit Views Henshin Model Transformation Engine BlocksTo ViewObjects Transformation Henshin Model Transformation Engine Henshin Model Transformation Engine ViewToViewObject Transformation SummitBlockToView Transformation Data Flow Textual Artifact or System Model, Class or Associaton Control Flow Activity Tool Figure 5.17 Resulting models when enacting a transformation method to transform the internal representation of database views of the running example by using the Concept RecognitionBased Language Transformation Pattern Method Enactment The desired transformation is achieved by enacting the transformation method as shown in Figure 5.16. Note that most of the artifacts are presented shortened. The method consists of customized method fragments that have been introduced in Section 5.3 and is an instance of the Concept Recognition-Based Language Transformation Pattern. The two activities shown in the highest layer of Figure 5.17 originate from the Conceptual Transformation Pattern, while the activity on the middle layer originates from the Language Transformation Pattern. In contrast, the activities on the lower layer are part of both patterns. As the enactment of exemplary methods has already been discussed in Sections 5.5.1 and 5.5.2, we do not go into detail on every activity but focus on those parts that are affected by the integration of both patterns. 5.6 Composed Transformation Patterns 131 An example for an affected activity is the activity called Extract Summit Views, shown in the upper left of Figure 5.10. The activity is a customization of the Program Comprehension fragment, its purpose is to extract the database views defined within the Oracle Forms application and represent it as an F-PIM. When applying the Concept Recognition-Based Language Transformation Pattern, the F-PIM does not completely represent the functionality to transform but only a part of it. That part is used to enhance a dependent language transformation. Related to the Summit application, the extraction of the view called S_ORD is shown, which is defined by the equally named Block . The resulting F-PIM does only represent the structure of the view, i.e., the view and its fields, but does not model technical details. For example, key-relations are not modeled on the platform-independent layer as well as the information to which database field a Table Based Attribute corresponds to. Since the missing information is contained in the L-PSM, a Trace Model that links both models is an additional output of the activity. In the example, the contained Trace element links the S_ORD Table Based View element and its origin, namely the S_ORD Block . While the figure only shows one Trace element, we assume that each part of the Summit View Model is traced. For example, each Table Based Attribute is linked to an Item and its data source, i.e., to the associated RDB Column Definition from which the data is fetched. The subsequent activity called Concretize Summit Views is a customization of the Concretization fragment. By enacting the activity, the F-PIM gets transformed into the T-PSM, shown in the middle right of Figure 5.17. In the example, enacting the activity invokes the execution of a model transformation that creates the Entity Based View Object element as well as its contained View Attributes . However, properties are not created, like the Primary Key value of the View Attribute called ID , as well as references to Entity Objects . The Trace Model is updated to reference elements of the Summit View Object Model. The missing technical details are added by enacting the activity called Transform Internal Representation of Summit Database Views, which is a customization of the Language Transformation fragment. Thereby, the model transformation that is executed when performing the activity considers the trace information provided by the Trace Model to retrieve the coherences between the involved models. Note that the data flow dependency of the activity on the Trace Model and the T-PSM realizes the integration of the Conceptual Transformation and the Language Transformation Pattern. As a last step, code is generated in the target environment by enacting the activity called Generate Summit View Objects. This concludes the description of an example for the Concept Recognition-Based Language Transformation Pattern. Subsequently, we describe its generic characteristics. 132 MEFiSTo Method Base Description The Concept Recognition-Based Language Transformation Pattern can be applied to transform the functionality of a legacy system into a new environment, following a conversion-based transformation strategy. The basic idea of how to transform the functionality is to explicit represent a part of it on a platform-independent layer. This representation is extracted from the source code of the legacy system and used to enhance a mapping between the programming languages of both environments. More precisely, applying the pattern first requires representing the functionality to transform on the platform-specific layer as a platform-specific model of the legacy environment (L-PSM) by performing a model discovery. Then, a part of the functionality to transform gets reverse engineered from the L-PSM and represented explicitly by a platformindependent model (F-PIM). By performing a concretization, the F-PIM is transformed into a platform-specific model of the target environment T-PSM. Trace information are maintained so that a subsequent language transformation can add missing parts in the T-PSM by transforming the L-PSM while using trace links. Finally, source code is generated based on the T-PSM. The transformation strategy described by this pattern can be related to the mechanics of a compiler. Besides using an intermediate representation that holds all information of the code to compile, some compilers use an additional representation to enhance the code generation process [Aho+06, p.525-542]. For example, a Control Flow Graph (CFG) can be used that represents an abstraction of the code, i.e., it does not contain all information but focuses on control flow relations. Optimizations can be defined purely on the CFG that are then reflected back on the intermediate representation. This is comparable to the strategy described by the pattern. In the example, the F-PIM abstracts from technology-specific terminology and explicitly represents the structure of the underlying functionality. The pattern enables to perform restructurings on this platform-independent representation, so that it could be used to describe the mechanics of a compiler, too. On the other side, the representation by an F-PIM does not need to be restructured in order to enhance a language transformation. In fact, we assume that it can already be beneficial to just explicitly represent parts of the functionality on a platform-independent layer. We apply the same argument as for the Conceptual Transformation Pattern (cf. Section 5.5.2), namely the fact that the use of a platform-independent layer separates the concerns of interpreting the L-PSM and mapping the result in the target environment. Note that, when applying this pattern, the mapping occurs as part of the concretization and the language transformation. Thereby, the amount of information being transformed per activity can vary. This concludes the generic description of the pattern, whereby we discussed various characteristics. However, so far we did not discuss in which situations an application of the pattern is appropriate. This discussion is part of the next section. 5.7 Formalization 133 Suitability In terms on influences on the effectiveness, we have to consider the influence factors of the basic patterns that result when decomposing this composed one. For the Language as well as for the Conceptual Transformation Pattern, the realization of the functionality to transform in the legacy system and the desired realization in the target environment are essential influence factors. The difference in the realization will determine the complexity of the Language Transformation, which can be counteracted by using a platform-independent layer. This has been discussed in detail in Sections 5.5.1 and 5.5.2. Also, in case of influence factors on the efficiency we need to consider the influence factors of the underlying basic patterns. As both patterns follow a conversion-based transformation strategy, the effort to develop a syntactic and/or semantic analyzer, metamodels and code generation rules needs to be considered. In addition, we assume the effort to develop the model transformation that transforms the L-PSM into the T-PSM as well as the effort to realize the program comprehension activity to be significant. The effort is determined by the differences in the realization. Also, the size of the source code to transform needs to be considered as an influence factor. Only if the code is sufficiently large, the benefits of automating the transformation will compensate the effort for developing tools. In particular, for this pattern, the effort for the development of tools needs to be carefully evaluated. As the pattern relies on the use of trace information between different, possibly large models, developing scalable tools is critical. In conclusion, we assume that the pattern is particularly suitable if the functionality to transform is realized differently in both environments and when the complexity of a direct transformation becomes low if parts of the functionality are made explicit, while the source code to transform is sufficiently large. This concludes an informal description of the composed patterns. In the next section, we describe how we formalized them. 5.7 Formalization In this section, we describe how we formalize the content of the method base, i.e., the proposed fragments and patterns. An overview of the different artifacts involved in the formalization as well as their relations is shown in Figure 5.18. The figure is separated into two layers. Artifacts belonging to the upper layer are projectindependent artifacts. They are defined as part of this thesis and support the development of transformation methods. In contrast, artifacts belonging to the lower layer are projectspecific ones. They are created when enacting the method engineering process of the MEFiSTo framework, described in Section 6. 134 MEFiSTo Method Base In MEFiSTo, we do not directly specify the developed transformation method in SPEM but initially use an intermediate representation instead. That intermediate representation is automatically transformed into SPEM by executing a model transformation. The reasons for this are twofold: First, as SPEM is a comprehensive and therefore complex language, the specification can become a cumbersome task. By using an intermediate representation that only supports specifying essential constituents of a method by abstracting from SPEM-specific constituents, we aim to reduce this complexity. Second, the use of an intermediate language eases the replacement of SPEM. If another language to specify methods shall be used, it is only required to develop a new model transformation that transforms the intermediate representation into that language. Project-Idependent MEFiSTo Intermediate Modeling Language (MIML) Software & Systems Process Engineering Metamodel (SPEM) Summit SPEM Model Summit MIML Model MEFiSTo Method Base SPEM Model instance of instance of MIML To SPEM Transformation MimlToSPEM TransformationRules extends Project-Specific Model Transformation Engine represents abstraction of Data Flow Textual Artifact Package Activity Tool Relation Sec. 5.7.2 Sec. 5.7.1 Sec. 5.7.3 Figure 5.18 Overview of packages and their relations when formalizing a method in MEFiSTo The MEFiSTo Intermediate Modeling Language (MIML) artifact that is shown on the upper left side of Figure 5.18 represents the intermediate language of MEFiSTo. An instance of this metamodel describes a project-specific method, an example is the Summit MIML Model. We go into detail on these two artifacts and their content in Section 5.7.1. The three artifacts in the right side of Figure 5.18 constitute a formal description of a transformation method using SPEM. On the top, the Software And Systems Process Engineering Metamodel resides as defined by the OMG [OMG08a]. The MEFiSTo Method Base SPEM Model is an instance of that metamodel, it specifies the generic method fragments as proposed in Sections 5.3 and 5.4. A project-specific model can extend these method fragments to specify customized ones. An example for such a model is the Summit SPEM Model. We go into detail on these three artifacts and their content in Section 5.7.2. In addition, we discuss the model transformation to transform MIML into SPEM in Section 5.7.3. 5.7 Formalization 135 5.7.1 MEFiSTo Intermediate Modeling Language (MIML) In MEFiSTo, a transformation method gets initially specified by a model of an intermediate language called MIML. In Figure 5.19, an excerpt of the metamodel of MIML and a corresponding model of a project-specific method is shown. MEFiSTo Intermediate Modeling Lanaguage (M2) Fragment ActivityRole Artifact Tool output input tool Summit MIML Model (M1) Associaton Inheritance System :Artifact Object Class Artifact Package role subActivity Transformation ToolDeveloper Model Discovery Language Transformation LPSM TPSM self.output->forAll (artifact | artifact.oclIsTypeOf(LPSM)) Parser Pattern MethodFragment MethodPattern ToolImplementationPhaseFragment TransformationPhaseFragment Basic LanguageTransformationPattern self.transformationphasefragments.methodFragment->forAll(fragment | fragment.oclIsTypeOf(fragment::transformation::ModelDiscovery) or fragment.oclIsTypeOf(fragment::transformation::Enrichment) or fragment.oclIsTypeOf(fragment::transformation::LanguageTransformation) or fragment.oclIsTypeOf(fragment::transformation::CodeGeneration) or …) self.subActivity->forAll (activity | activity.oclIsTypeOf(ModelDiscovery)) subArtifact Fragment Pattern Internal Representation of Database Tables :LanguageTransformationPattern :TransformationPhaseFragment Discover Blocks and SQL Statements :ModelDiscovery Block and SQL Model :LPSM Block Source Code :LegacySourceCode Block and SQL Model :LanguageTransformation Block and SQL Model :TPSM :LPSM :ModelDiscovery:LegacySourceCode :LanguageTransformation :TPSM Discover Oracle Forms Runtime :ModelDiscovery outputinput input output Composition MethodPatternConfiguration LanguageTransformation PatternConfiguration discoverPlatform :Boolean LanguageTransformation PatternConfiguration discoverPlatform = „true“ Constraint Legacy SourceCode Figure 5.19 Model of the transformation method introduced in Section 5.5.1 in MIML (excerpt) The upper layer shows the content of the MIML metamodel. The package called Fragment provides elements to specify the essential constituents of a method, namely roles, artifacts, activities and tools. Sub-packages provide explicit language elements for all proposed method fragments by refining the generic constituents. For example, the package named Transformation provides elements to specify fragments of the equally named phase, e.g., the LPSM artifact or Model Discovery activity (cf. Sections 5.3 and 5.4). Elements of the Fragment package are associated with constraints that specify invariants of method fragment instances. Those invariants are defined in the Object Constraint Language (OCL). For example, an instance of the Model Discovery fragment can only have subactivities of the same type while the output has to consist of LPSM instances. APPENDIX A Characterization of Method Patterns Concept Recognition-Based Reimplementation (F6) Intent Perform a semi-automatic transformation of the legacy system’s functionality into a new environment by combining a conversionand a reimplementation-based transformation strategy Strategy Use an intermediate representation of parts of the functionality to transform on a platform-independent layer to guide a manual reimplementation. The intermediate representation is reverse engineered from an ASG 1 of the legacy system on a platform-specific layer and concretized into an ASG1of the target environment. Subsequently, code is generated in the target environment that forms the basis for manual reimplementation activities performed by software developers Structure Continued on next page 240 Characterization of Method Patterns Applicability Use when the functionality to transform is realized significantly different in the legacy and target environment and when software developers can be pointedly guided if parts of the functionality are made explicit. The use of an intermediate representation can reduce the complexity of a direct transformation by separating the concerns of reverse engineering, restructuring and mapping the functionality. The manifestation of these concerns essentially influences the efficiency and effectiveness of the pattern. Those parts of the functionality, which have not been converted, shall be reimplemented manually. Thereby, the amount of available developers and their experience form influence factors to consider Preparation Applying this pattern essentially requires realizing a parser, model-to-model transformations, code generation rules and guidance documents to systematize the reimplementation. In addition, it can be necessary to realize a semantic analyzer, dedicated reverse engineering algorithms or model views Example In the first feasibility study (cf. Section 7.2), we applied the pattern on the Back Navigation and Business Logic concepts of the Controller concern. The method described in [Fle+07] conforms to the pattern Known Uses The strategy realized by the pattern is comparable to the strategy followed by an MDA-based development process that starts on the platform-independent layer. While parts of the functionality to transform are automatically generated using a model-driven tool chain, remaining parts are completed manually Related Patterns Combines F2, F3and F4; Similar to F5 Table A.1 Characterization of the Concept Recognition-Based Reimplementation Pattern 1Depending on the situation, using an AST can be sufficient 241 Concept Recognition and Language Transformation-Based Reimplementation (F8) Intent Perform a semi-automatic transformation of the legacy system’s functionality into a new environment by combining a conversionand a reimplementation-based transformation strategy Strategy Use an intermediate representation of parts of the functionality to transform on a platform-independent layer to enhance a direct mapping between the programming languages of the environments involved and to guide a manual reimplementation. The intermediate representation is reverse engineered from an ASG2of the legacy system on a platform-specific layer and concretized into an ASG2of the target environment. When the ASG2of the legacy system is transformed into an ASG2of the target environment, the model transformation used is dependent on the transformation of the intermediate representation. Subsequently, code is generated in the target environment that forms the basis for reimplementation activities performed by software developers Structure Continued on next page 242 Characterization of Method Patterns Applicability Use when the functionality to transform is realized significantly different in the legacy and target environment. In addition, the complexity of a direct transformation should become low if parts of the functionality are made explicit while it should also enable to pointedly guide software developers. The use of an intermediate representation can enhance a direct transformation but requires addressing the concerns of reverse engineering, restructuring and mapping the functionality explicitly. The manifestation of these concerns as well as the remaining complexity of the direct transformation influences the efficiency and effectiveness of the pattern. Those parts of the functionality, which have not been converted, shall be reimplemented. Thereby, the amount of available developers and their experience form influence factors to consider Preparation Applying this pattern essentially requires realizing a parser, model-to-model transformations, code generation rules and guidance documents to systematize the reimplementation. In addition, it can be necessary to realize a semantic analyzer, dedicated reverse engineering algorithms or model views Example In the first feasibility study (cf. Section 7.2), we applied the pattern on the Non-Data-Based Dialog Element concept of the View concern Known Uses The strategy realized by the pattern is comparable to the strategy followed by an MDA-based development process that starts on the platform-independent layer. While parts of the functionality to transform are automatically generated using a model-driven tool chain, remaining parts are completed manually Related Patterns Combines F1, F2, F3and F4 Table A.2 Characterization of the Concept Recognition And Language Transformation-Based Reimplementation Pattern 2Depending on the situation, using an AST can be sufficient 243 Platform-Independent Architecture Restructuring (A2) Intent Perform an automated restructuring of a legacy system‘s architecture during its transformation into a new environment Strategy An intermediate representation of the system’s architecture is used on a platform-independent layer. The representation is reverse engineered from a model of the system’s functionality on a platform-independent layer. After the architectural model has been restructured, the changes are reflected back to the model that represents the functionality Structure Applicability Use when the architecture of the system to transform differs in the source and in the target environment and if the difference is too significant to perform the restructuring implicitly when converting the functionality. In addition, the structures that imply the architecture of the system and those that are affected by the restructuring need to reside in models on the platform-independent layer Preparation Applying this pattern requires realizing model transformations rules. In addition, it can be necessary to realize dedicated architecture recovery algorithms or model views Example In the first feasibility study (cf. Section 7.2), we applied the pattern on the Business Module concept of the Modularization concern Known Uses The strategy realized by the pattern is comparable to the strategy followed by architectural reengineering tools Related Patterns Similar to A1 Table A.3 Characterization of the Platform-Independent Architecture Restructuring Pattern 244 Characterization of Method Patterns Architecture Restructuring (A3) Intent Perform an automated restructuring of a legacy system‘s architecture during its transformation into a new environment Strategy An intermediate representation of the system’s architecture is used on a platform-independent layer. The representation is reverse engineered from models of the system’s functionality on a platform-specific and platform-independent layer. After the architectural model has been restructured, the changes are reflected back to the models that represent the functionality Structure Applicability Use when the architecture of the system to transform differs in the source and in the target environment and if the difference is too significant to perform the restructuring implicitly when converting the functionality. Also, the structures that imply the architecture of the system and those that are affected by the restructuring need to reside in models on the platform-specific and platform-independent layer Preparation Applying this pattern requires realizing model transformations rules. In addition, it can be necessary to realize dedicated architecture recovery algorithms or model views Example – Known Uses The strategy realized by the pattern is comparable to the strategy followed by architectural reengineering tools Related Patterns Combines A1and A2 Table A.4 Characterization of the Architecture Restructuring Pattern APPENDIX B Overview of the Method Engineering Process Tool Implementation Transformation Situation-Specific Tool Chain MDE Developers Software Developers Method Enactment Sec. 6.5 Sec. 6.6 Tool Implementation Phase Transformation Phase Situation-Specific Transformation Method Specification Code Generation Rules Definition Reimplementation Guidance Definition Tool Implementation Metamodel Definition Model Transformation Rules Definition Tool Developer Tool Developer Tool Developer Tool Developer Model Transformation Rules Definition Define Table-Based View Concretization Transformation Define Table-Based View Extraction Transformation Define Block to View Object Transformation Define Formular to Expression Transformation Define Relation to View Link Transformation Tool Developer Tool Developer Tool Developer Tool Developer Tool Developer RelationTo ViewLink Transformation TableBased ViewConcretization Transformation TableBased ViewExtraction Transformation FormularTo Expression Transformation BlockTo ViewObject Transformation Transformation Program Comprehension Model Discovery L-PSM Enrichment PlatformIndependent Architecture Recovery PlatformIndependent Architecture Concretization Concretization Architecture Restructuring Language Transformation Code Generation Reimplementation Software Developers System Expert Parser Model Transformation Engine Model Transformation Engine Model Transformation Engine Model Transformation Engine Model Transformation Engine Model Transformation Engine Code Generation Engine Figure B.1 Overview of the method enactment process of MEFiSTo 246 Overview of the Method Engineering Process Method Pattern Integration Method Pattern Selection and Configuration Instantiation of Tool Implementation Phase Fragments Method Completion Situational Context Model Incomplete Transformation Method Specification (SPEM) Fragmented Transformation Method Specification (MIML) Integrated Transformation Method Specification (MIML) Method Patterns Method Fragments Method Base Transformation Method Construction Transformation Method Specification (SPEM) MimlToSPEM TransformationRules Modernization Expert and Tool Specialist Modernization Expert and Tool Specialist Modernization Expert and Tool Specialist MIML To SPEM Transformation Model Transformation Engine PreparationPhase MethodFragment Instantiation TransformationRules Incomplete Transformation Method Specification (MIML) Model Transformation Engine Modernization Expert and Tool Specialist Sec. 6.4.2 Sec. 6.4.3 Sec. 6.4.4Sec. 6.4.1 Sec. 6.4.5 Identify Suitable Method Patterns Identify Legacy and Target Realization per Concept Influence Factor Identification Identify Influence Factors per Suitable Method Pattern Modernization Expert Summarize advantages and disadvantages per Suitable Method Pattern [All Suitable Method Patterns been investigated] Modernization Expert and Tool Specialist Modernization Expert and Tool Specialist [All Concerns have been investigated] Modernization Expert and Tool Specialist Concept Identification per Concern, based on Target System Concern Identification based on Target Architecture Target-Driven Concept Identification Validation of Identified Concepts per Concern, based on Legacy System Modernization Expert (Missing) Concept Identification per Concern, based on Legacy System [All concerns have been investigated] Modernization Expert Modernization Expert Modernization Expert Configure Method Specification (coarse-granular) Select Method Patterns for all Concepts Method Pattern Selection and Configuration Instantiate Customized Transformation Phase Method Fragments Configure Method Specification (fine-granular) Modernization Expert and Tool Specialist Modernization Expert and Tool Specialist Modernization Expert and Tool Specialist Model Transformation Engine Situational Context Model [Method Patterns not selected] Fragmented Transformation Method Specification (MIML) TransformationPhase MethodFragment Instantiation TransformationRules Situational Context Model [Method Patterns selected] Transformation Method Specification (MIML) [Method Fragments Instantiated] Transformation Method Specification (MIML) [Method Patterns Configured] Instantiate Transformation Method Specification TransformationMethod SpecificationInstantiation TransformationRules Model Transformation Engine Transformation Method Specification (MIML) [Instantiated] Influence Factor Identification Situational Context Model Method Patterns Method Fragments Method Base Concept Identification Concept Model Situational Context Identification Modernization Expert Modernization Expert and Tool Specialist Sec. 6.3.1 Sec. 6.3.2 Situational Context Identification Transformation Method Construction Situational Context Model Method Fragments Method Patterns Method Base Method Development Modernization Expert and Tool Specialist Modernization Expert and Tool Specialist Sec. 6.3 Sec. 6.4 Conceptualization Phase Situation-Specific Transformation Method Specification Figure B.2 Overview of the method development process of MEFiSTo Glossary abstract concept An abstract concept represents a language-independent idea of a computation or problem solving principle [KNE92]. abstract syntax graph An abstract syntax graph is an abstract syntax tree that has been extended by semantic edges, e.g., edges that link the use of an identifier to its declaration [KGW98]. abstract syntax tree An abstract syntax tree is a tree whose nodes represent syntactic constructs of source code, while edges represent the hierarchical relation between them [Aho+06, p.41]. architectural concept An architectural concept is an abstract concept and represents components or interfaces. architectural platform-independent model An architectural platform-independent model is a platform-independent model defined by the MEFiSTo framework that represents architectural structures of a software system to transform. architectural style An architectural style describes a family of software systems that share a common software architecture in terms of a pattern or structural organization [GS94, p.6]. architecture-driven modernization The architecture-driven modernization is a software modernization paradigm, based on model-driven engineering concepts. It is defined by the OMG which promotes corresponding standards [BCW12, pp.45-47]. 254 Glossary situation-specific A software transformation method is situation-specific if it is efficient and effective against the background of the associated situation. Efficiency relates to properties of the enacted process, while effectiveness relates to properties of the resulting information system. situational context A situational context is associated to a software modernization project and consists of a set of influence factors. It needs to be considered in order to design a situation-specific transformation method. situational method engineering Situational method engineering is a kind of method engineering which encompasses all aspects of creating a method for a situation at hand [HS+14, p.5]. software and systems process engineering metamodel The software and systems process engineering metamodel is a metamodel defined by the OMG that can be used to formally specify methods [OMG08a]. software architecture The software architecture is the fundamental organization of a software system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [IEEE00]. software migration Software migration is a kind of software reengineering concerned with the transition of a legacy system to a new environment while retaining the system‘s data and functionality [Bis+99]. software modernization Software modernization is a kind of software migration concerned with the transition of a legacy system to a new environment while adapting the system to the new environment. software modernization method A software modernization method is a method that is used guide a software modernization endeavor. Glossary 255 software modernization project A software modernization project is established by a company to carry out a software modernization by defining and enacting a software modernization method. software reengineering Software reengineering is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form [CC90]. software reengineering method A software reengineering method is a method that is used to guide a software reengineering endeavor. software transformation method A software transformation method is an instance of the horseshoe model and used to guide the technical transition of a legacy system into a new environment during a software modernization endeavor. software transformation package A software transformation package represents a part, i.e., an increment, of a legacy system that is used during the incremental transformation of that legacy system [BS95, pp.13-14]. software transformation strategy A software transformation strategy is a specific way of how to perform the technical transition of a legacy system during a software modernization, established examples being reimplementation, wrapping and conversion [SWH10, pp.10-13]. staged software lifecycle The staged software lifecycle is a model that describes stages in the lifecycle of a software system after the initial development [RB00]. syntactic analysis Syntactic analysis is performed by a parser on source code to create an abstract syntax tree which represents that source code [Aho+06, p.8]. technological space A technological space is a working context with a set of associated concepts, body of knowledge, tools, required skills, and possibilities [AKB02]. 256 Glossary transformed platform-specific model A transformed platform-specific model is a platform-specific model defined by the MEFiSTo framework that represents the software system to transform by technologyspecific concepts of the target environment. wrapping Wrapping is a software transformation strategy that aims to transform parts of a legacy system by encapsulating them using a wrapper. The wrapper acts as a connection point in the resulting information system [SWH10, pp.12-13]. Acronyms 4GL Fourth-Generation Programming Language. A-PIM Architectural Platform-Independent Model. ADM Architecture-Driven Modernization. ADMTF Architecture-Driven Modernization Task Force. API Application Programming Interface. ASG Abstract Syntax Graph. AST Abstract Syntax Tree. ASTM Abstract Syntax Tree Metamodel. CDO Connected Data Objects. CFG Control Flow Graph. 258 Acronyms CIM Computation-Independent Model. COTS Commercial Off-The-Shelf. CRUD Create Read Update Delete. DSL Domain-Specific Language. EMF Eclipse Modeling Framework. F-PIM Functional Platform-Independent Model. GASTM Generic Abstract Syntax Tree Metamodel. IDE Integrated Development Environment. JDAPI Java Development API. KDM Knowledge Discovery Metamodel. L-PSM Legacy Platform-Specific Model. LOC Lines of Code. Acronyms 259 MDA Model-Driven Architecture. MDD Model-Driven Development. MDE Model-Driven Engineering. MEFiSTo Method Engineering Framework for Situation-Specific Software Transformation Methods. MIML MEFiSTo Intermediate Modeling Language. MoCo Model-Integrating Component. MOF Meta-Object Facility. MOFM2T MOF Model to Text Transformation Language. MVC Model-View-Controller . OCL Object Constraint Language. OMG Object Management Group. PIM Platform-Independent Model. 270 Acronyms PSM Platform-Specific Model. ReMiP Reference Migration Process. RMC Rational Method Composer . RUP Rational Unified Process. SASTM Specialized Abstract Syntax Tree Metamodel. SME Situational Method Engineering. SOA Service Oriented Architecture. SPEM Software and Systems Process Engineering Metamodel. T-PSM Transformed Platform-Specific Model. UML Unified Modeling Language.