Design and Implementation of a UML Model Refactoring Toolhuchard/Documents/Papiers/PhilippSeuringMasterThesis.pdf · Abstract This thesis presents design an implementation of a UML

Hasso�Plattner�Institute for Software Systems Engineeringat the University of Potsdam

Laboratoire Informatique Robotique Microelectronique MontpellierUniversité Montpellier II (UMII) et Centre National de la Recherche Scienti�que (CNRS)

Design and Implementation

of a UML Model Refactoring Tool

Master Thesis

byPhilipp Seuring

Montpellier, September 19, 2005

Supervisor: Prof. Dr.-Ing. Siegfried WendtTutor: Professor Marianne Huchard

Abstract

This thesis presents design an implementation of a UML 2.0 model refactoring tool, calledGaliciaUML, based on the Eclipse Modeling Framework. The mathematical theory of FormalConcept Analysis is used to implement a refactoring algorithm called MultiFCA. This refactor-ing algorithm has been integrated into an usable chain of tools to perform refactoring tasks ondrawn or generated UML 2.0 models. The UML models are transformed into Relational Con-text Family (RCF) models in a �rst transformation step performed. From these RCF modelsthe Multi FCA algorithm deduces Concept Lattices from which refactored UML models will beobtained in a third transformation step.After an introduction in the �rst chapter, the second chapter presents important concepts annecessary terms from the domain of model driven engineering. In the third chapter Standardsand Tools from this domain will be presented. The architecture of the UML refactoring systemwill be presented in chapter four. The Eclipse technology is illustrated in chapter �ve beforein chapter six the Eclipse concepts will be applied to the design of the GaliciaUML tool.Throughout this work architectural plans from the Fundamental Modeling Concepts will beused to illustrate the most important concepts.

Zusammenfassung

Diese Masterarbeit stellt das Design und die Implementierung eines UML 2.0 RefactoringWerzeuges (GaliciaUML) basierend auf dem Eclipse Modeling Framework vor. Die mathe-matische Theorie der Formal Concept Analysis ist Basis des MultiFCA Algorithmus der zumRefactoring benutzt wird. Der MutliFCA Algorithmus wurde in mehrere Werkzeuge integriert,so dass eine tatsächlich nutzbares Refactoring Werkzeug entstanden ist, dass gezeichnete odergenerierte UML Diagramme refactored. Diese UML Modelle werden in einem ersten Schrittin Relational Context Family (RCF) Modelle transformiert. Auf diesen RCF Modellen ar-beitet der MultiFCA Algorithmus dessen Ergebnis Concept Lattices sind. Aus diesen ConceptLattices werden die restrukturieren UML Modelle abgeleitet.Nach einer Einführung im ersten Kapitel wird im zweiten Kapitel auf wichtige Begri�e undKonzepte aus dem Bereich der modellgetriebenen Softwareentwicklung eingegangen. In Kapiteldrei werden in diesem Bereich wichtige Standards und Werkzeuge vorgestellt. Die Architek-tur des GaliciaUML Systems und wichtige Algorithmen werden in Kapitel vier präsentiert. InKapitel 5 wird die Eclipse Platform vorgestellt die Basis fuer die in Kapitel 6 beschriebeneUmsetzung der Architektur in Eclipse Plug-ins darstellt. In der gesamten Arbeit werden dieFundamental Modeling Concepts (FMC) zur Beschreibung architektureller Strukturen verwen-det.

Selbständigkeitserklärung

Hiermit versichere ich, Philipp Seuring, dass ich diese Arbeit selbständig verfasst sowie keineanderen Quellen und Hilfsmittel als die angegebenen benutzt habe.

Philipp Seuring

Contents

1 Selbständigkeitserklärung 5

Table of Contents i

2 Introduction 12.1 Refactoring - Improving Design of Software . . . . . . . . . . . . . . . . . . . . . 12.2 The Formal Concept Analysis Algorithm . . . . . . . . . . . . . . . . . . . . . . 22.3 Incremental Multi FCA Refactoring Tool . . . . . . . . . . . . . . . . . . . . . . 32.4 Previous Work on an FCA Refactoring Tool . . . . . . . . . . . . . . . . . . . . 42.5 Limitations of the Existing Approach . . . . . . . . . . . . . . . . . . . . . . . . 52.6 The new Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.6.2 The Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Models, Metamodels, Transformations 93.1 Refactoring and Model Driven Engineering . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 MDE Technology Space . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Modeling and Metamodeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Model and System under Study . . . . . . . . . . . . . . . . . . . . . . . 133.2.3 Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.4 Modeling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.1 Transformation Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3.2 Transformation Function . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.3 Transformation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.4 Transformation Language and Transformation Metamodel . . . . . . . . 173.3.5 Query, View, Transformation, Mapping . . . . . . . . . . . . . . . . . . . 18

3.4 Classi�cation of Model Transformations . . . . . . . . . . . . . . . . . . . . . . . 193.4.1 Endogenous vs. Exogenous Transformations . . . . . . . . . . . . . . . . 193.4.2 Horizontal vs. Vertical Transformations . . . . . . . . . . . . . . . . . . . 203.4.3 Technological Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.4 Source-driven, Target-driven and Aspect-driven Transformations . . . . . 20

3.5 Model Transformation Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.1 Procedural vs. Declarative Mechanisms . . . . . . . . . . . . . . . . . . . 21

3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

i

CONTENTS

4 Standards and Tools 234.1 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Model Driven Architecture (MDA) . . . . . . . . . . . . . . . . . . . . . 244.1.2 Uni�ed Modeling Language (UML 2.0) . . . . . . . . . . . . . . . . . . . 254.1.3 Meta Object Facility (MOF 1.4) . . . . . . . . . . . . . . . . . . . . . . . 274.1.4 XML Metadata Interchange (XMI 2.0) . . . . . . . . . . . . . . . . . . . 274.1.5 eXtensible Markup Language (XML 1.1) . . . . . . . . . . . . . . . . . . 284.1.6 XML Schema 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.7 Query/View/Transformation (QVT 0.9) . . . . . . . . . . . . . . . . . . 29

4.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.1 UML Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.2 Model Transformation Tools . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Architecture 415.1 The Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 From UML to RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3.1 Transforming an UML model into a Relational Context Family . . . . . . 445.3.2 Transformation Con�guration Requirements . . . . . . . . . . . . . . . . 485.3.3 UML to RCF Transformation Language . . . . . . . . . . . . . . . . . . 485.3.4 UML to RCF Transformation Engine . . . . . . . . . . . . . . . . . . . . 50

5.4 Galicia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.4.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.4.2 Galicia Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.4.3 Concept Lattices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.5 Concept Lattices to UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5.1 Interpreting Concept Lattices . . . . . . . . . . . . . . . . . . . . . . . . 555.5.2 Complete Reconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.5.3 Incremental Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.6 A Transformation Chain with Metamodels . . . . . . . . . . . . . . . . . . . . . 595.7 Decisions - towards an implementation . . . . . . . . . . . . . . . . . . . . . . . 61

5.7.1 Decisions Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.7.2 Decision Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.7.3 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.7.4 Advantages Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Eclipse 656.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.1 Eclipse - Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.1.2 The Eclipse Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.1.3 The Eclipse Community . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 Eclipse Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2.1 Eclipse Runtime OSGi Implementation . . . . . . . . . . . . . . . . . . . 706.2.2 The Eclipse Plug-in Model . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2.3 The Eclipse Extension Mechanism . . . . . . . . . . . . . . . . . . . . . . 77

6.3 Existing Eclipse Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

ii

6.3.1 Eclipse Core Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.3.2 Eclipse Java Development Environment (JDE) . . . . . . . . . . . . . . . 896.3.3 Eclipse Plug-In Development Environment . . . . . . . . . . . . . . . . . 90

6.4 Modeling with Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.4.1 Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . . . 916.4.2 Eclipse UML2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.5 Eclipse Integration Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7 Design - Implementing GaliciaUML in Eclipse 977.1 Plug-ins Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.1.1 The Storage Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.1.2 The Actor Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.1.3 Other Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.2 Plug-in Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.2.1 Dependencies between GalicaUML Plug-ins . . . . . . . . . . . . . . . . 1007.2.2 Depending on EMF and UML2 Plug-Ins . . . . . . . . . . . . . . . . . . 1007.2.3 Depending on basic Eclipse Plug-Ins . . . . . . . . . . . . . . . . . . . . 1017.2.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.3 Inner Plug-in Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1027.3.1 fr.lirmm.galiciauml.uml2rcf . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.3.2 Galicia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.3.3 fr.lirmm.galiciauml.lattice2uml . . . . . . . . . . . . . . . . . . . . . . . . 1087.3.4 fr.lirmm.galiciauml.uml2rcfmodel, edit, editor . . . . . . . . . . . . . . . 109

8 Outlook 111

Appendixes 113

A Installation Manual 113A.1 Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.1.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.2 EMF and UML2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.1.3 Omondo EclipseUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

A.2 GaliciaUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.2.1 Installing Plug-ins in the Eclipse workspace . . . . . . . . . . . . . . . . 116

A.3 Installing Java 5 for Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.4 Launching Plug-ins in a Runtime Workbench . . . . . . . . . . . . . . . . . . . . 117A.5 Installing Plug-ins permanently in Eclipse . . . . . . . . . . . . . . . . . . . . . 118

B User Manual 123B.1 Performing Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.1.1 Creating a new Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123B.1.2 Creating a UML2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 123B.1.3 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125B.1.4 Using Omondo to interpret Results . . . . . . . . . . . . . . . . . . . . . 127

B.2 Generating New Transformation Rules . . . . . . . . . . . . . . . . . . . . . . . 128B.2.1 Using the Transformation Rules Editor . . . . . . . . . . . . . . . . . . . 128B.2.2 Invoking the Rules Generator . . . . . . . . . . . . . . . . . . . . . . . . 131

iii

CONTENTS

Bibliography 135

iv

Chapter 1

Introduction

1The objective of this Master Thesis is to develop tool support for a software refactoring al-gorithm. A special refactoring algorithm (Multi FCA) is used to apply refactorings on UMLmodels. A UML modeling tool and a development environment will be used to draw or generateUML models. These models will be transformed in a �rst step by a model transformation engineinto the FCA speci�c Relational Context Family (RCF) data format. From RCF the algorithmdeduces concepts lattices. Via a second transformation step a refactored UML model will becreated using the concept lattices. The integration of the di�erent tools and transformationsteps will be done by using Eclipse as integration platform and user interface and will be basedon the Eclipse Modeling Framework.

This tool chain allows to validate the use of Multi FCA on refactoring tasks by applying it tolarger projects and visualizing the results. Working with open source Eclipse, EMF and modeltransformations facilitates research cooperations and builds up important knowledge on theevolving �eld of MDE/MDA.

In this introduction �rst the concepts of refactoring and the formal concept analysis are pre-sented. Then a big picture of how tool support for this solution can look like will be introduced.The previous work on tool development and its limitations will be discussed to motivate theplan of this work and present the outline of this thesis.

1.1 Refactoring - Improving Design of Software

The objective of refactoring is to originally ameliorate source code. Refactoring is the processof changing the source code of a computer program without changing the function/observablebehavior of the program. The intension of the changes is to improve understandability, modi-�ability, reusability, modularity, adaptability and lots of other properties of source code. Eachchange (called a 'refactoring') does little, but a sequence of changes can produce a signi�cantrestructuring. Since each refactoring is small, it's less likely to go wrong. A sequence of correctrefactorings (changes of source code that do not change the observable behavior of the softwaresystem) will produce a correct restructuring of the software.

Fowler de�nes in [15] refactoring in its own words: Refactoring is a disciplined technique for re-structuring an existing body of code, altering its internal structure without changing its external

1

1 INTRODUCTION

Galicia

Restructuring

Figure 1.1: Simple Restructuring

behavior. Its heart is a series of small behavior preserving transformations.

Figure 2.1 shows two UML diagrams describing object oriented source code before and aftera refactoring. On the left side two classes with some similar properties and a similar methodare shown. On the right side an additional class is introduced. It is serving as a 'superclass'for the two original classes. This new class contains the properties the two old classes had incommon before. This refactoring is not changing the observable behavior of the software. Wheninstantiating an object from the one of the two classes circle or rectangle the objects behave asthey did before the refactoring. A good reason for this refactoring is that in the original versionthe implementation source code of the move() method did exist two times (redundancy) whichis no more the case after the refactoring. Duplicate code causes problems e.g. when changingthe behavior of the move() method all appearances of the implementation need to be changed.

The process of refactoring is normally referred to as something the programmer has to do on hisown. This work follows the idea that some refactorings can be done automatically or at leastthe need for some refactorings can be detected automatically by the Multi FCA algorithm. Atool integrating refactoring functionality and Multi FCA algorithmic logic can propose certainrefactorings to the programmer. It helps him to improve the design of his software.

Originally refactoring was a task on the source code, but the same logic can be applied to thelevel of modeling, to UML models.

1.2 The Formal Concept Analysis Algorithm

The Galicia working group developed several special FCA algorithms for software refactoringsand implemented it in the Galicia tool1. The most important ones are called 'Incremental MultiFCA' [27] citeDBLP:conf/iccs/2004 .

Other algorithm implemented in the same tool have been previously applied on data fromvarious �elds e.g. social science and data mining always with the intend to extract conceptualstructure from raw data [29].

Figure 2.1 describes one of the most simple refactorings that could be detected by the FCA

1http://galicia.sourceforge.net/

2

INCREMENTAL MULTI FCA REFACTORING TOOL 1

algorithm in the Galicia tool. The original diagram contains two classes with similar properties.If the algorithm could work on this data it would detect the concept of the 'superclass' whichcontains these similar properties. It would also indicate the inheritance relationships in the newdiagram. But the algorithm can not work on UML diagrams directly. As signi�ed in Figure2.2 it works on a set of tables and produces lattices.

The algorithms implemented in the Galicia tool can deal with much more complicated UMLdiagrams (having Associations, Association Classes, Operations with Parameters) and can com-pletely restructure the relations between all elements of the UML model. The possibilities ofthe di�erent algorithms are pointed out in [27].

1.3 Incremental Multi FCA Refactoring Tool

To apply the Multi FCA algorithm to UML diagrams several barriers have to be overcome.Figure 2.2 shows a �rst decomposition of the desired refactoring system and helps us discussingthe di�erent challenges in this section.

Figure 2.2 shows a software designer drawing UML diagrams. These diagrams will be refac-tored2 to 'refactored UML diagrams' (shown on the right side). To create the diagrams thesoftware designer should use an UML modeling tool. If he not only wants to refactor the UMLdiagrams that he had drawn by hand but also wants to apply the refactorings to larger exist-ing software projects the UML tool needs to cooperate with a development environment andprovide diagram generation capabilities.

Figure 2.2 shows that the whole refactoring engine is composed of three smaller parts. Becausethe FCA algorithm works on its proper data format and not directly on UML diagrams the gapbetween these two has to be bridged. The data format the algorithm is working with is wellde�ned. This is necessarily the case for the data format in which the UML diagram is stored bythe UML tool. The transformation mechanism between the UML diagram format and the RCFformat needs to be highly con�gurable because not all the information from the UML diagramis interesting for the FCA algorithm when searching for possible refactoring. E.g. the positionsof the UML classes on the screen or the number of properties of a class are not as importantas the names of the properties which are associated to a class. The question of which is theinteresting subset of information can more appropriately examined when having a working toolto test the hypotheses. That's why the �rst transformation step (component denoted with'UML to RCF' in Figure 2.2 should be de�nable by the user via a 'Transformation Description'in form of rules.

The result of the Multi FCA algorithm is not an UML diagram. Therefore a second trans-formation step 'LAT to UML' needs to be performed to obtain the refactored class diagram.It translates the Lattice structures to the data format the UML tool can understand. Thiscomponent perhaps will need to have access to the original UML diagram.

The architectural details of these components will be extensively discussed in the architecture

2or restructured, terms will be used similar in this document

3

1 INTRODUCTION

Relational

Context FamilyGalicia

incremental

Multi FCA

Lattice

UML to RCF

UML

Diagram

Transformation

Description

R

Invoke Transformation

LAT to RCF

Refactored

UML Diagram

Figure 1.2: FCA Refactoring Tool

part in chapter 5.

1.4 Previous Work on an FCA Refactoring Tool

Previous work on tool support is described in [37]. It su�ered of the fact that no standarddata format for UML diagrams exists. The di�erent UML tools are working on more or lessproprietary data formats. That's why the previous refactoring work focused on using onespeci�c UML tool, Objecteering UML Suite3, to draw the UML diagrams. The Ojbecteeringinternal data format for the UML diagrams has been used by all components of this work.Objecteering is o�ering a programming interface and a proprietary programming languagecalled 'J'. This language was used to transform the internal representation of the UML diagramto the RCF format the Galicia tool can work with. The Galicia tool has been adapted to thistask so it was possible to invoke the algorithm from within Objecteering. The result of thealgorithm (lattice structure) was then transformed into the new UML diagram again using theObjecteering programming language 'J'.

Figure 2.3 shows the static structure of this Objecteering speci�c solution. It is a speci�cimplementation of the abstract concept shown in Figure 2.2. The software designer shown atthe left side designs the class diagram using Objecteering and then invokes the transformationvia the GACCI module. GACCI is the name of the module which contains all the export andimport logic written in 'J'. It also wraps the invocation of the Galicia tool which performsthe algorithm. The GACCI module consists of an export part and an import part whichboth work on the internal diagram format used by the Objecteering company. The 'Exporter'transformed the UML diagrams into the RCF format. This export progress was con�gurableby several preferences pages, but only in a prede�ned way. The interpretation of the resultLattices was done by the 'Importer'. It produced a totally new UML diagram. Integration intoObjecteering was possible because of the 'Objecteering Modules' extension technology.

The results of this work showed that with this approach interesting results could be produced[28]. Unfortunately the most interesting tests were applied on software projects with 'FranceTelecom Research and Development', so the results are only in limited form available to thepublic[6].

3http://www.objecteering.com/

4

LIMITATIONS OF THE EXISTING APPROACH 1

Objecteering Suite

Relational

Context Family

Galicia

Multi FCA

Lattice

Objecteering

Module

GACCI

Exporter

UML Class

Diagram

[Objecteering

Format]

Predifined

Transformation

Descriptions

draw

select

R


Objecteering

Module

GACCI

Importer

Restructured

UML

Diagram

[Objecteering

Format]

Figure 1.3: Objecteering Galicia Integration

1.5 Limitations of the Existing Approach

The existing implementation of the restructuring algorithms is not available in a running in-stallation any more. The developer is not available and documentation of the software doesnot exists. For this and other technical and organizational reasons it is impossible to continuethe work on the Objecteering Tool Suite. To test what has been developed or to examine theimplementation in not possible as well.

Apart from these organizational di�culties also several conceptual limitations of the approachto integrate the Galicia tool into Objecteering Suite turned out and will be shortly discussed.Most of them emerge from the fact that the UML diagram refactoring is only usable with Ob-jecteering/UML Suite because it is implemented as an Objecteering Module using the internalObjecteering programming language.

Limited Availability: Objecteering is a commercial tool basically known in France. As aconsequence of the Objecteering license policy the tool may not be available for every researchgroup which is interested in reproducing results or contributing to the research work. It canbe purchased as an evaluation version but this version does not o�er the possibility to developown modules.

High Dependency: Objecteering is not su�ciently supporting standard data formats. It isnot fully supporting the emerging UML 2.0 and XMI 2.0 standards for diagram interchange.So any further work will depend on the release strategy of the Objecteering company.

Proprietary Objecteering Modules Technology: Modules for Objecteering need to bewritten in the proprietary 'J' language which has very limited debugging possibilities. Thispresumes that contributors and developers learn an additional programming language and getto know the Objecteering module platform.

Further Evolution: Today neither the concepts nor the application domain of the di�erentmodeling languages and techniques is stable. Standards still su�er of an incomplete theoreticalfoundation. They are not widely accepted and not consistently used. A lot of things are subjectto change or have not yet proofed their maturity. It is hard to predict whether an independenttool like Objecteering will master the ongoing changes.

5

1 INTRODUCTION

Transforming existing Systems: As �rst experiments revealed interesting results furtherexperiments should be made on existing software systems. It is not applicable to draw complexUML Diagrams representing existing systems by hand. It is desirable to integrate the Galiciatransformation algorithms into a powerful development and re-engineering tool to be able toanalyze large scale systems.

1.6 The new Approach

This work presents a Multi FCA Refactoring Tool called GaliciaUML. It integrates the incre-mental multi FCA algorithm with an UML modeling tool and development environment. Ona �rst guess this is similar to what has been done in the previous work, but the new approachshould not su�er of the limitations presented above. To achieve that, all single steps of the soft-ware restructuring are based on open and well known technologies. The work is modular andwell documented to build up a knowledge base for UML refactoring and model transformationsin the working group. Further projects should be possible which build up on the experiencesdescribed in this work.

1.6.1 Requirements

UML: The UML Tool which is selected should be freely available and work on a standardUML format which is implementing the UML 2.0 Superstructure speci�cation. It should beintegrated into a development environment to support UML diagram generation from existingJava projects.

Customizable Transformation: The �rst transformation step from the UML diagram tothe RCF format should be performed by a model transformation engine which is working ona user de�ned transformation description. This enables the user to freely choose the subset ofinformation on which the FCA algorithm should work. The transformation description needsto be de�ned with tool support in a simple language so that the user does not have to learn aproprietary language to de�ne the transformation.

FCA is hidden: The FCA algorithm should be invoked transparently to the user. Thereshould be no need to con�gure it, the few con�guration options should be de�nable via the userinterface.

UML Reconstruction: The second transformation step should extract all the important con-ceptual data from the lattice and retranslate it into the same standard conform UML diagramformat which can be visualized by the same UML tool or into a set of refactorings which shouldbe proposed to the user.

Loose Coupling: All this components should be loosely coupled but tightly integrated into aconsistent user interface and usage concept. It should be possible to replace them separatelyto allow division of work.

6

OUTLINE 1

1.6.2 The Plan

UML: As a integration platform the Eclipse Framework will be used. It exists a UML 2.0 Stan-dard implementation for Eclipse for which multiple graphical tools will be available. The UMLtool we use is the freely available EclipseUML from Omondo which can work with the EclipseUML2 format. It is integrated into the Eclipse Java IDE and provides diagram generationsupport.

Transformation Engine: For the �rst transformation step transformation engines can beused that work on standard transformation languages. In this version a simple proprietarytransformation language and transformation engine will be presented. It is based on the EclipseModeling Framework which provides also support for a graphical user interface for the language.

FCA Eclipse Plug-in: The FCA algorithm user interface will not be integrated into theEclipse environment because the development team is not providing any documented interfaces.The integration is possible but only with a new version of the FCA tool. The plan is to wrapthe old tool in an Eclipse plug-in which provides the desired interface, this is a work around.

UML Reconstruction: The 'LAT to UML' transformation step will be performed by aproprietary transformation engine with hard coded transformation rules. It is designed to bereplaced by a standard transformation engine as well. It produces a sequence of refactoringswhich will be applied to the original UML diagram.

Eclipse Integration Platform: All components are implemented as Eclipse plug-ins usingEclipse integration concepts like the extension point mechanism.

1.7 Outline

In this document �rst of all it is important to talk about the vocabulary of concepts and thetheory of model transformations. Model transformations are important concepts in the task.In chapter three important standards and tools in the domain will be presented. At this pointenough knowledge is accumulated to discuss the architecture and the basic decisions whichtools and standards will be used to implement the solution. There we will �nd out that beforestarting to think of implementation details �rst Eclipse needs to be understood. After an indepth Analysis of the main Eclipse concepts in the Design chapter we discuss how the presentedarchitecture is implemented using Eclipse concepts.

7

1 INTRODUCTION

8

Chapter 2

Models, Metamodels, Transforma-

tions

2This chapter will explain the basic theory and vocabulary of concepts to understand the appli-cation of Multi FCA as a refactoring algorithm and a multi-step model transformation. Thewhole refactoring task will be seen as one big model transformation. One UML model will betransformed into another UML model, but this transformation consists of three smaller trans-formations. All these transformations (the big transformation and the three small ones) aremodel transformations because as well in the source domain as in the target range are modelswhich have associated metamodels.

The relation of our refactoring idea to the MDE research area will be discussed, because theterms model transformation and metamodel are widely used in the Model Driven Engineering(MDE) technology space. Basically along the de�nitions of three di�erent authors we will learnabout the concepts of system, model, modeling language and metamodel. This will provide thebasis for this chapter's main concept - the model transformation. We will de�ne what modeltransformations are, what di�erent types of transformations exist and �nally say some basicwords about model transformation engines.

2.1 Refactoring and Model Driven Engineering

Our refactoring approach is not working directly on source code but on models. At this pointwe are close to what Model Driven Engineering does. Model Driven Engineering (MDE) tries touse models as the unit of re�ection in software engineering. In this idea the software developeris not thinking about source code but about source code models. The idea is to describe thewhole software systems with models and then generate most of the source code that is necessaryto obtain a running system. MDE is not the same as Model Driven Architecture (MDA). MDAis a standard of the OMG trying to use UML as a programming language and de�ne di�erenttypes of models (PIM, PSM) which together are su�cient to de�ne a running system. Moredetails on this will be given in the standards chapter.

The domain of MDE as well as other parts of computer science is still su�ering of a lackof common understandings and unclear terms. Only in a few domains which are close tomathematics with a strong theoretical background the wording is clear, such as graph theoryand language theory. For the MDE domain this is not the case. Even in the important UML2standard which can be considered as the heart of the model driven approach no clearness is

9

2 MODELS, METAMODELS, TRANSFORMATIONS

available as illustrated by the following quotation.

UML 2 Superstructure Speci�cation [22], chapter 6.4.2 Semantic Levels and Naming: Alarge number of UML metaclasses can be arranged into 4 levels with metasemantic relation-ships among the metaclasses in the di�erent levels that transcend di�erent semantic categories(e.g., classi�ers, events, behaviors). We have tried (with incomplete success) to providea consistent naming pattern across the various categories to place elements intolevels...[22]

Nevertheless there are some recent approaches trying to build a theoretical fundament for MDE.A selection of approaches will be presented and discussed always with respect to the applicationon refactoring of UML models.

2.1.1 MDE Technology Space

The term Technological Space (TS) is used when classifying a set of technologies and concepts.In this chapter concepts will be discussed in the context of the MDE TS that apply to otherTSs as well. So even if the reader thinks that the described concepts are already known andwell de�ned this is not true for the MDE TS.

De�nition of Technology Space [Kurtev, Bézivin, Aksit]: A TS is a working context with a setof associated concepts, body of knowledge, tools, required skills, and possibilities. It is oftenassociated to a given user community with shared know-how, educational support, commonliterature and even workshop and conference meetings. [31]

An example of other technology spaces is given in Figure 3.1. It shows that a similar conceptexists in various domains. The most important other TS space in the context of this work is theXML TS. The relationship between XML Document and XML Schema is the same as betweena model and a meta model. To express that the model described by the XML Document iscorrect with respect to the metamodel described by the XML Schema the term "valid" is used.The XML Document is valid if it meets all the constraints speci�ed by its XML Schema.

2.2 Modeling and Metamodeling

The basic items for the MDE TS are System, Model and Metamodel which build up theknown MOF model hierarchy (see Figure 3.3). Even if these terms describe a well knownconcept in some domains it is not evident how the exact relations in between these terms are.As described by Favre in [9] most of the Metamodels that describe MDA are inconsistent, whichcan be proved just be trying to express a simple instance scenario with the metamodel relations.In this section three di�erent authors will be compared on how they de�ne these basic concepts,what they have in common and where misunderstandings can come up.

Favre is working on a Megamodel for Model Driven Engineering and most of the quotations

10

MODELING AND METAMODELING 2

Metamodel

Model

MDA

Schema or

DTD

Document

XML

Schema

Data

DBMS

Grammar

Program

Abstract Concrete

Syntaxes

Top-level

Ontology

Ontology

Ontology

engineering

Figure 2.1: Similar Concepts in di�erent Technology Spaces (see [31])

are taken from 'Towards a basic Theory to Model Driven Engineering' [9] and 'Towards a Meg-amodel to Model Software Evolution through Transformations' [10]. Seidewitz is representedby the opinions from his article 'What Models Mean' [38]. Tabeling represents the set of de-�nitions from the 'Fundamental Modeling Concepts' presented in his lecture on 'Systeme undihre Modellierung' [40]1 at Hasso Plattner Institut2 and recently in his book [39] with the samename.

2.2.1 System

Every set of de�nitions has to start at one point. For the domain of modeling one of themost important notions is the notion of system. Here it is presented as the root of all otherde�nitions. The most simple approach to a de�nition of system is made by Seidewitz. Favrefollows the same approach.

Seidewitz (and Favre) for system: Everything is a system.[38]

Tabeling for dynamic system: A concrete, or at least conceivable, thing showing observablebehavior. This behavior can be seen as the result of the system components' interaction.[40]

The main di�erence is that Tabeling argues from an engineering point of view where Seidewitzis closer to a mathematician. An engineer would not consider everything as a system, becausefor an engineer a system is always a dynamical system. It has an observable behavior. Whenthe engineer talks about a system, he has the point of view of someone who wants to build thissystem to satisfy a need.

Figure 3.2 shows how FMC de�nes system and distinguishes system from software. The desiredsystem an engineer wants to build is the hardware executing the software, because this is the

1All translations by the auther2Hasso Plattner Institut for Software Systems Engineering(http://www.hpi.uni-potsdam.de/)

11


Figure 2.2: System and System Description (see www.f-m-c.org)

combination which in the end ful�lls the task. The software is only one ingredient for thissolution.

Mathematicians regard the world from the point of view of a researcher. They search the truth,the abstract mathematical concepts behind our every day live, experiences and observations.An example which illustrates the di�erent idea of system Favre has is the tuple (0011,1101).In [10] Favre argues that this tuple is a system and points out the logic that is in these tuple.

The de�nition of system which is discussed here has to be accepted in the domain of ModelDriven Engineering and should make sense in this context. Even if many concepts in informaticshave their roots in mathematics perhaps in this case also the engineering point of view shouldbe considered important. As discussed before MDE is about how to build software systemswhich is more an engineering than a scientist task.

A second di�erence between Tabeling and the two others is that Tabeling states a basic di�er-ence between abstract and physical systems. An abstract systems is something that exists onlyin mind and a physical system exists in the real world. This abstract system can be describedby a system description.

Favre argues3 that humans distinguish between the real physical world and the abstract worldof 'ideas', but for him the di�erence between abstract and physical systems is not important.In his opinion the abstract system is not entirely abstract but a physical system as well. Ourso called abstract ideas are born in neurons, a physical system.

In the opinion of the author this is a discussion with a philosophical value. For an engineering

3oral discussion on IDM05 conference

12


point of view it is important that in every day live humans do distinguish between 'a real world'and 'ideas and concepts' they have in mind. In the same way we can distinguish abstract andphysical systems and this di�erence is important for our understanding.

Tabeling goes further and introduces the term of informational system, because computerscience mostly deals not with physical but with informational systems.

Tabeling: A system is called informational, if the essential point of the issues that are ob-served in di�erent places in the system is not their material or energetic appearance but theirinterpretation.[40]

A basic di�erence in this �rst section on the de�nition of the term system can be seen inthe importance the di�erent approaches give to this term. On the one hand the idea that'everything is a system' by Favre and Seidewitz and on the other hand the accurate distinctionbetween di�erent types of systems by Tabeling. He distinguishes between dynamical, abstract,physical, informational systems and system descriptions.

2.2.2 Model and System under Study

The de�nition of model is based on the de�nition of system. All the de�nitions describe therelation between the system under study (SUS) and the model. It is not clear whether themodel is abstract or not, which can be considered as the basic di�erence between the followingde�nitions.

Seidewitz: A model is a set of statements about some system under study. Here statementmeans some expression about the SUS that can be considered true or false. [38]

Favre: A model is a simpli�cation of a system built with an intended goal in mind. The modelshould be able to answer questions in place of the actual system. [10]

Tabeling: A model is an abstraction of a system, which shows up only a set of chosen propertiesof the system under study which are interesting from a certain point of view.[40]

The author considers the de�nition of Tabeling more helpful in the most cases. Neverthelessthe di�erences are not as clear as before when discussing the term system. The de�nition ofFavre will be taken as a basis for the next de�nitions.

2.2.2.1 Speci�cation Models vs. Analysis(Descriptive) Models

The basic distinction between speci�cation and analysis models is considered very importantby all of the three opinions discussed in this work. Being representative for all of them thede�nition of Seidewitz will be presented.

Seidewitz: Models are usually descriptive in traditional scienti�c disciplines. The model is

13


correct if all its statements are true for the SUS. Models usually serve as speci�cations intraditional engineering disciplines. When we construct software, we also generally use modelsas speci�cations. In this case, if the as-built software's structure or behavior deviates from thedesign speci�cation, it's the software that's invalid (at least relative to this speci�cation) [38].

Example: The UML models will be descriptive models if they are generated from the underlyingSUS. When UML diagrams are used to design new parts of software or use them to explainconcepts (perhaps not related to software) they need to be considered as speci�cation models.

2.2.2.2 Interpretation of Models

The notion 'Interpretation' is used to describe what humans do with models when using them,say the semantics they give to the models. Again di�erent opinions can be found. On the onehand Seidewitz uses the term to de�ne the way to map from a model to a system and Tabelinguses it to map from an informational system to an understanding.

Seidewitz: An interpretation of a model is a mapping of the model's elements to elements ofthe SUS such that we can determine the truth value of statements in the model from the SUS,to some level of accuracy [38].

Tabeling: Interpretation what is needed to understand a informational system. The process tomap physical facts to information. [40]

Even though there are di�erences in the de�nitions both bring up questions concerning UMLmodels. The interpretation of an UML Class diagram is not commonly de�ned, this meansit is not clear what the SUS (system under study) for this model could be. In the originalinterpretation in the object oriented programming world each rectangle in a Class diagram isinterpreted as a source code class in an object oriented programming language. Another inter-pretation of the UML Class diagram is the interpretation as an Entity Relationship Diagram(ERD). Following this interpretation each rectangle in the class diagram needs to be interpretedas an entity-set.

In our case: The model is the object oriented software model. This model is described by a di-agram in the UML2 language. Sometimes example models just describe concepts (which couldmore accurately been described with ERD diagrams) but this is not important for the refactor-ing task because the result will be another UML model. But dependent on the interpretationperhaps there are interpretations where the refactorings do not make sense any more.

2.2.3 Metamodel

Seidewitz: A metamodel is a speci�cation model for a class of SUS where each SUS in the classis itself a valid model expressed in a certain modeling language. That is, a metamodel makesstatements about what can be expressed in the valid models of a certain modeling language. [38]

14


{fig:Metamodel}

{fig:Metamodel}

Metamodel

Modeling

Language

defined by

Model

lets us

express

System

Model

SUS

Representation of

MOF Metalevels Modeling MDA Technology Space

Metamodel of

Object Oriented

Software

UML

defined by

Class Diagram

lets us

express

Object Oriented

Software

Model

SUS

Representation of

M0 Level

M1 Level

M2 Level

M3 LevelSelf defining

Metamodel

MOF

Self defining

Metamodel

Metamodel

Model

Metamodel

Model

Figure 2.3: Metalevels in MOF, Modeling and MDA

OMG: A meta-model is a model that de�nes the language for expressing a model. [21]

Both de�nitions state that a metamodel is not a model for a model but a speci�cation of alanguage. It expresses what can be described in the language the metamodel speci�es.

In our case: Metamodel UML2 is a speci�cation model (that's why the metamodel descriptionis called speci�cation) and it de�nes the language UML. So when we want to learn UML weneed to understand the concepts of the UML Metamodel. The author thinks that the UMLMetamodel puts emphasis on correctly de�ning all the language details but misses to explainthe intensions behind the de�nitions of the twenty one di�erent diagram types. Even if UML isnot only dedicated to describe (or model) object oriented software, a lot of concepts can onlybe understood in this context.

2.2.4 Modeling Languages

Seidewitz: A modeling language lets us express the statements in models of some class of SUS.In computer since sometimes the modeling languages seem to be more important than the modelsitself. [38]

In our case: The UML Diagrams we use are described in the modeling language UML. UMLlets us express our diagrams. But the statements can only be interpreted (see Interpretation)with respect to a system under study.

15


Transformation

Function

Transformation

Instance

transformable

Models

Library.uml

(Model)

transformed

Models

Library.rcf

(Model)TargetSource

RangeDomain

describes to

be operational

Transformation

Metamodel

defined by

UML

Metamodel

RCF

Metamodel

defined by Defined by

My.uml2rcf

(Transformation

Model)

Modeling

Language

element of element of

element of

element of

defined by

Modeling

Language

element of

defined by

Transformation

Languae

element of

Figure 2.4: Transformation Disambiguation

2.3 Model Transformations

Model Transformations are used to create a new target model from a given source model. Moreinformation about the process or the relation between source and target is not considered at thispoint. First the relationship between the notion of transformation, transformation instance,transformation function, transformation model, transformation language and transformationmetamodel will be discussed.

The relations of these terms are illustrated in Figure 3.4. It shows that the two models arerelated by a transformation instance and that the transformation function is not de�ned on themodels itself but on the level of the metamodels. The vertical axis depicts the di�erent met-alevels which have already been described in Figure 3.3. These metalevels have been applied tothe three di�erent �elds on the horizontal axis (from left to right - source model, transformation(model), target model). It is interesting that the transformation model is on the same heightsas the UML metamodels.

2.3.1 Transformation Instances

Following the set theory a transformation instance is the fact that a system is transformed intoanother system. This fact is mathematically a simple pair of the source and the target model.This pair could be (library.uml2, library.rcf) which then means that there is a transformationthat transforms the UML model 'library.uml2' into the RCF model 'library.rcf'.

16

MODEL TRANSFORMATIONS 2

2.3.2 Transformation Function

A transformation function is a function in the mathematical sense. It is the set of all modelinstances (pairs of source models and target models). The domain of the transformation func-tion is the set of all transformable models. The range is the set of all models that can be theresult of a transformation.

In [10] the domain of a transformation function is referred to as a modeling language. Thisdoes not seem evident when mapping this idea to our approach. The transformation functionwe de�ne, works only on a subset of the models that can be expressed in UML, namely theClass diagrams.

The relation between transformation instance and transformation function is an element ofrelation which is as well used for the relation between the UML Diagram and the UML lan-guage. The author understands that this is correct with respect to the de�nition of 'element of 'taken from the set theory, but he does see a lot of di�erences between the two relations. Theeducational value of using the notion of 'element of ' to describe the model, modeling languagerelationship and the transformation instance, transformation relationships is doubted becauseit is to abstract and hides the complexity of these relations.

2.3.3 Transformation Model

Up to now a transformation (function) is a mathematical expression, a set of pairs. No processor rules can be deduced to �nd an algorithm which performs the transformation. On an abstractlevel the transformation function can be de�ned mathematically when giving the set of pairswhich are the transformation instances but in fact another notion has to be found. This notionwill be used to describe the transformation model. Transformations can be described by existingmodels and their languages, i.e. it can be described in the programming languages C or Java.As we will see the transformation metamodel will de�ne a language to describe the model oftransformation that we use to implement model transformations.

2.3.4 Transformation Language and Transformation Metamodel

The transformation language is a language de�ned especially to describe model transformations.That's why it is speci�ed by a Transformation metamodel. An easy approach to a transfor-mation metamodel is given in Figure 3.5. This transformation metamodel describes the leastcommon denominator of all transformation languages and concepts which are described in thenext chapter.

On the top of Figure 3.5 a transformation instance is shown which is just the relation betweentwo models. Below this simple transformation instance the inner structure of this relation isshown and will be discussed now. A transformation consists of rules. Every rule has a 'SourcePattern'. The 'Source Pattern' is used to match some kind of related elements in the 'Source

17


Target ModelSource Model

Rule

Target PatternSource Pattern

Tracking

Relationships

uses uses

Source Model

(Set of

related

Elements)

Target Model

(Set of

related

Elements)

mapped to

match create

uses for

cross

references

Figure 2.5: A simple Transformation Metamodel [FMC ERD]

Model'. The 'Target Pattern' describes what will be created in the 'Target Model' when a'Source Pattern' matched. It is describing the structure of a set of interrelated elements thatwill be created. These three concepts of 'Rule', 'Source Pattern' and 'Target Pattern' exist inall transformation languages the author studied (see chapter Standards and Tools). What allof them have additionally in common is the need of another concept, here called 'Tracking'.This is due the desire to have more than the power of declarative programming languages todescribe model transformations. Declarative model transformation languages have exactly thesame weaknesses as declarative programming languages in general. No order of the rules isgiven, but often several target patterns create elements in the target model that need to beinterrelated or in the worst case have containment relationships. A 'Target Pattern' can notcreate an element which will be contained in a container element, if the rule which should createthe container did not happen to match before. To manage this with the 'Tracking' concept amechanism is created to have inter rule dependencies. Implicit rule orders and a mapping fromsource to target model elements which lasts over the lifetime of a single rule are introduced

In Figure 3.5 no cardinalities are given because the ERD (entity relationship diagram) shouldjust give an idea of the concepts. It is not a detailed speci�cation model. This is somethingthat should be one of the results of the QVT standard (see 4.1.7) which is near to release.Because of the �rst releases of the QVT standard the author doubts that the metamodel willbe usable, because it will be explained by some dozens of related Classes in an UML diagram.

2.3.5 Query, View, Transformation, Mapping

When talking about model transformations the words query, view, transformation, mappingare used to describe closely related mechanisms. They all operate on a set of objects and resultin a set of objects. The de�nitions given here are abutted to the de�nitions given in the QVT

18

CLASSIFICATION OF MODEL TRANSFORMATIONS 2

proposal in [7].

Queries: are de�ned on a set of objects and describe a ordered subset of this source set. Nonew objects can be explicitly created by a query. The result set can be described by the samemodel as the source set. A common application of queries is the extraction of data out of adatabase. SQL is a language with which queries can be described that extract data out of thedatabase. This data can still be described by the old database schema.

Views: are also de�ned on a set of objects and de�ne a subset of it, but the result needs tobe described by an other model. The result retains links to the source set. A view can beunderstood as a "di�erent point of view" on the old data, which is described by a new model.This shouldn't be mixed up with the term "view" from the database world where a view isde�ned by a query.

Transformations: are evaluated with respect to a set of source objects de�ned by an extentand with respect to a target extent. It results in population of the target extent by a set of newlyconstructed heterogeneous objects. Links to the source object are not necessarily contained.

Mappings: are about relationships between objects (and are inherently bi-directional, and theobjects on both sides are assumed to exist).

In contrast to the mapping a transformation implies the construction of some target objectsfrom some source objects (a directional action) based on a mapping. A transformation can beused to create a instance of a model B reading an instance of model A if a mapping betweenthe two models A and B exists.

2.4 Classi�cation of Model Transformations

Usually classifying transformations the �rst distinction is on 'what' the transformation trans-forms. Since in our case the transformations transform models we only deal with model trans-formations. Nevertheless some criteria mentioned in this section are as well true for everytransformation.

2.4.1 Endogenous vs. Exogenous Transformations

Endogenous transformations are de�ned as transformations between models expressed in thesame language. Exogenous transformations are de�ned as transformations between modelsexpressed in di�erent languages. These attributes (endogenous, exogenous) describe whetherthe transformation passes metamodel boundaries or not.

Example: The whole transformation from the source model to the target model in Figure 2.1is endogenous, because the source model and the target model are written UML. It consists ofthree exogenous transformations (UML to RCF to Lattice to UML).

19


2.4.2 Horizontal vs. Vertical Transformations

A horizontal transformation is a transformation where the source and target models reside atthe same abstraction level. A vertical transformation is a transformation where the source andtarget models reside at di�erent abstraction levels. In this context abstraction level means thatthe level of details of what is described in the source and the target model does not changesigni�cantly.

Example: The transformation Figure 2.1 is a horizontal transformation, the code generationfrom the UML model to Java source code is a vertical transformation.

2.4.3 Technological Space

The question is, whether the source model and the target model reside in the same TechnologySpace. The answer is not always so easy to �nd. Considering the de�nition of the TS (seesection TS) our Transformation passes from the MDA TS to the XML TS because Galiciaworks on XML documents as an input model. An argument against that classi�cation wouldbe that the actual transformation is taking place between a Metamodel UML2 and a MetamodelRCF which both are in the MDA TS. The TS boundaries are just crossed by using XML as aserialization format, not within the transformation. Another approach to this question couldbe that we are passing from the MDA TS to a Technology Space of Formal Concept Analysis.Even if this idea is more evident to the author to say the MDA and FCA are completely di�erentdomains, the de�nition of TS does probably not apply to FCA but does apply to XML.

2.4.4 Source-driven, Target-driven and Aspect-driven Transforma-tions

Source-driven transformations will transform single source model elements to a complex setof target model elements. Target-driven transformations conversely may have a single speci�ctarget model element as the subject of each rule. They match an arbitrarily complex set ofmodel elements in the source model. [8] Aspect-driven transformations center more aroundconcepts than objects. Multiple rules per object can be needed and implicit object creationmust be supported.

The �rst transformation in our case from UML to RCF is neither source driven nor targetdriven. Even if the concept of aspect driven transformation is not evident the author considersthe UML to RCF transformation aspect driven.

20

MODEL TRANSFORMATION ENGINES 2

2.5 Model Transformation Engines

It is not di�cult to write a program in a standard programming language that reads in onemodel and writes out a di�erent one as a 'one shot' operation. This is how many modeltransformation tools are implemented currently. But when there is a need to support incre-mental updates, reconciliation of independent changes and round-tripping an initially simpleprogramming task may turn out complex and di�cult to maintain. Therefore special modeltransformation engines should be implemented which support languages de�ned especially todescribe model transformations.

2.5.1 Procedural vs. Declarative Mechanisms

The major distinction between transformation mechanisms is whether they rely on a declarativeor an operational (imperative) approach. Declarative approaches focus on the what aspect, i.e.they focus on what needs to be transformed into what and are therefore close to the humanunderstanding of a transformation. Operational approaches focus on the how aspect, i.e. theyfocus on how the transformation itself needs to be performed and are therefore the �rst guesswhen we need to implement a transformation engine. [33]

2.5.1.1 Procedural Approach

Like in the world of 'normal' programming languages everything can be expressed in a proce-dural programming model. There is a start up rule and a speci�ed order of rules afterwards.The rules can communicate via global variables.

2.5.1.2 Declarative Approach

The declarative approach, even if very near to the human idea of model transformations su�ersof the same lack of expressiveness as declarative programming languages. Therefore everydeclarative approach includes procedural concepts when coming to its limits. Even if this looksmore evident to the user �rst the transformation description will look di�cult when solvingdi�cult problems.

2.6 Summary

The concepts of modeling and model transformations are very important for the evolutionof MDE. I will present an architecture of the GaliciaUML tool which uses the concepts ofmetamodels and model transformations. This architecture will be described in chapter 5. The

21


next chapter will discuss standards and tools that exist around the concepts discussed in thischapter.

22

Chapter 3

Standards and Tools

3

The world of Model Driven Engineering and related domains builds up on very new technologies,speci�cations, standards and concepts of vocabulary. It is interesting and necessary to have animpression of the latest development. In this chapter in the �rst section the most importantstandards of the domain will be shortly introduced and tools supporting existing standards ortrying to set new standards will be presented.

3.1 Standards

In the last chapter basic concepts of MDE like metamodeling and model transformations havebeen introduced. There is no single standard which is de�ning all these concepts and vocabularyof words but several di�erent standards of the OMG (Object Management Group) like MDA,MOF, UML, XMI and QVT together try to provide some kind of consistency.

The Object Management Group is a consortium aimed at setting standards in object-orientedprogramming as well as system modeling. In 1989, this consortium, which included Hewlett-Packard Company, IBM Corporation, Apple Computer Inc. and Sun Microsystems Inc., mobi-lized to create a cross-compatible distributed object standard. The goal was a common binaryobject with methods and data. It should work using all types of development environments onall types of platforms. OMG created the �rst Common Object Request Broker Architecture(CORBA) standard which appeared in 1991. Since March 2003, the latest standard is CORBA3.0.

The second set of standards important in this domain for our task is the set of XML Standardsstandardized by the World Wide Web Consortium (W3C). In this chapter the family of XMLStandards will be discussed, particularly XML Schema.

The World Wide Web Consortium (W3C) is a consortium that produces the software standards("recommendations", as they call them) for the World Wide Web. The Consortium is headed byTim Berners-Lee, the original creator of URL (Uniform Resource Locator), HTTP (HypertextTransfer Protocol) and HTML (Hypertext Markup Language), the principal technologies thatform the basis of the Web.

The big picture of the standards in the context of this work is described in Figure 4.1. The

23

3 STANDARDS AND TOOLS

Galicia

Restructuring

MDA

UML

QVT

XMI XML Document

XML Schema

MOF

Figure 3.1: Standards: Big Picture

names of the standards are placed approximately where they have their importance in therefactoring task. MOF is describing a metamodel and metamodeling levels in general. MDAdescribes the process of building software with modeling. UML describes the language of thediagrams and XMI describes how these diagrams can be serialized. QVT tells us about modeltransformations and XML Document and XML Schema are used to persist this data for toolinterchange.

3.1.1 Model Driven Architecture (MDA)

MDA promotes the use of UML as a graphical programming language. It is a software designmethodology, proposed and sponsored by the OMG. The basic idea is that the system func-tionality is de�ned as a platform-independent model (abbreviated PIM), using an appropriatespeci�cation language. This model then should be translated to one or more platform-speci�cmodels (PSM) for the actual implementation. The translation between platform-independentmodel and platform-speci�c models is normally performed using automated tools.

MDA development focuses �rst on the functionality and behavior of a application or system,independent of the technology platform on which it will be implemented. In this way, MDA triesto divorce implementation details from business functions. Thus, it should not be necessary torepeat the process of de�ning an application or system's functionality and behavior each timea new technology (e.g. Web Services) comes along. Other architectures are generally tied toa particular technology. With MDA, functionality and behavior should be modeled only once.Mapping from a PIM through a PSM to the supported MDA platforms is being implementedby tools, easing the task of supporting new or di�erent technologies. The chain of models inthe MDA idea is shown on the right side of Figure 4.2.

On the left side of Figure 4.2 the logo of MDA is shown. It presents MDA as the bracket aroundthe di�erent OMG standards and describes how they all can play together to develop softwareon a new and better way. In the view of the OMG MDA can be used for everything.

24

STANDARDS 3

Figure 3.2: Model Driven Architecture (MDA)

3.1.2 Uni�ed Modeling Language (UML 2.0)

The Uni�ed Modeling Language is a collection of primarily graphical description elements forthe modeling of software systems. It has become the common modeling language of the softwaredevelopment community. It is widely used in the world of tool based object oriented softwareengineering and a standard of the OMG (Object Management Group). In its early days it wasonly used for the description of software structures, but it has recently been developed intothe direction of a 'modeling language for everything'. This is made by introducing Pro�les tosupport some notion for semantics for di�erent application domains (via Stereotypes, Keywords,Tagged Values).

As a result of the current development UML has reached a complexity that it is hardly usableby non academics. The standard 2.0 is about 1000 pages and comprises 13 diagram types withmore then 100 basic elements. A use of UML therefore makes it necessary to pick a subset asneeded.

In the context of refactoring especially 'Class' diagrams are interesting and will be shortlypresented. The 'Class' diagram type is also the most reputed diagram type of UML. Also im-portant is the 'Sequence', 'State' and 'Activity' diagrams which describes the dynamic behaviorof the source code.

3.1.2.1 Class Diagram

An example of a 'Class' diagram is shown in Figure 4.1. In general this diagram type describes'Classes' and their relations. It comprises methods ('Operations'), attributes and further detailsfor classes ('Properties'). In Figure 4.1 on the right side a diagram containing three classes isshown. In this case each rectangle should be interpreted as a 'Class' in terms of object orientedprogramming. The arrow between the two lower classes and the upper class is called a 'Depen-dency'. In this particular case it is a 'Generalization' (indicated by the type of arrowhead), its

25


Figure 3.3: Part of the UML Metamodel

interpretation is like the interpretation of a 'is A' relationship known from entity relationshipdiagrams.

Each 'Class' can contain 'Operations' and 'Properties'. In Figure 4.1 the Class 'GeneratedClass'contains two 'Properties' (penWidth, color) and one 'Operation' (move()). The interpretation ofthis should be analogous to the interpretation of 'Class' from the object oriented programmingmodel.

3.1.2.2 UML 2.0 Speci�cation

The speci�cation of UML 2.0 Superstructure (the metamodel) is available in its earliest versionssince 2003. Tool vendors have already implemented major parts and development is still goingon. A '�nal adopted speci�cation1' has recently been published by the Object ManagementGroup (OMG). The most important fact about this speci�cation for our task is not the hugevariety of new diagram types but a totally revised core of the metamodel. The metamodeldescribes all the elements UML 2.0 models may consists of. It de�nes their relations on anabstract level and serves as the basis of the representation of its instances in any format. Themetamodel can be regarded as a big Entity Relationship Diagram describing the UML 2.0 valuerange structures. In Figure 4.3 a small part of the metamodel is shown. It is about the relationsof 'Class', 'Property' and 'Association', exactly the part of UML we also used in Figure 4.1. Inthe UML2 speci�cation UML Class diagrams are used to describe itself.

The small part of the metamodel in Figure 4.3 is part of a big diagram with more than 100 dif-ferent model elements. Unfortunately this is far to detailed to understand the real foundationsof UML. A helpful introduction in the main concepts is missing, but interestingly in the shortintroduction to the UML Speci�cation a lack of consistency and general clearness is stated.

1version names of the OMG

26

STANDARDS 3

3.1.3 Meta Object Facility (MOF 1.4)

The Meta Object Facility (MOF) is an abstract language for the description of metamodels [32].It is used to formally specify syntax and semantics of other languages. It is a set of standardinterfaces that can be used to de�ne and manipulate a set of interoperable meta-models andtheir corresponding models. Saving of UML models for tool based modeling should be a majorwin.

The MOF speci�cation de�nes a framework for specifying, constructing, and managing tech-nology neutral metamodels. A MOF metamodel is an abstract language for some kind ofmetadata. Examples include the metamodels for UML, CWM, and the MOF itself, as wellas various OMG speci�cations in progress. In addition, the MOF de�nes a framework for im-plementing repositories that hold metadata (e.g., models) described by the metamodels. Thisframework uses standard technology mappings to transform MOF metamodels into metadataAPIs. This gives consistent and interoperable metadata repository APIs for di�erent imple-mentation technologies. For example, the MOF IDL mapping has been applied to the MOFmeta-metamodel and the UML metamodel to produce CORBA APIs for representing MOFmetamodels and UML models.

The MOF Speci�cation includes the following:

• a formal de�nition of the MOF meta-metamodel; that is, the abstract language for spec-ifying MOF metamodels,

• a mapping from arbitrary MOF metamodels to CORBA IDL that produces IDL interfacesfor managing any kind of metadata,

• a set of "re�ective" CORBA IDL interfaces for managing metadata independent of themetamodel,

• a set of CORBA IDL interfaces for representing and managing MOF metamodels, and

• an XMI format for MOF metamodel interchange.

In our case the meta-metamodel we use is called Ecore. Ecore means the elementary core ofMOF and will be discussed in the Eclipse chapter.

3.1.4 XML Metadata Interchange (XMI 2.0)

XMI is used to connect the model world with the XML world like shown in Figure 4.4. TheOMG hopes that it helps to interchange UML models between di�erent tools.

XMI is a model driven XML integration framework for de�ning, interchanging, manipulatingand integrating XML data and objects. XMI-based standards are in use for integrating tools,repositories, applications and data warehouses. XMI provides rules by which a schema can be

27


XML WorldModel World

Metamodel

Model

XML Schema

XML Document

is conform

describe same Model

describe same Model

is valid

connected

by XMI

Figure 3.4: XMI

generated for any valid XMI-transmissible MOF-based metamodel. XMI provides a mappingfrom MOF to XML. As MOF and XML technology evolved, the XMI mapping is being updatedto comply with the latest versions of these speci�cations.

XMI describes an algorithm (EBNF production rules) applicable to store models in a persistentform. With XMI any model with an associated metamodel can be transformed in XMI/XML.Additionally XMI describes the creation of a model parsing its XMI/XML representation. Forthe representation of metamodels in XML format XMI 2.0 chose XML Schema (�les with theextension .xsd). XML Schema is an XML dialect used to describe the content model (valuerange structures) of XML �les (the successor of the DTD - Document Type De�nitions knownfrom the �rst days of XML) (see section XML Schema). The process of checking whether thetype of an XML instance �le meets the restrictions of element types and, cardinalities and soon is called validation. This process enables to check a large amount of rules and restrictionsgiven by the metamodel. If a XML �le is generated by XMI from a model which �ts intothis models metamodel the XML �le is valid when checked against the XML Schema which isgenerated from the metamodel. Because XMI is applicable for any type of model and associatedmetamodel compliant to the MOF model de�nition it is a very powerful speci�cation.

Unfortunately not all XMI implementations behave similar because the speci�cation lacks ofexactness or the implementations are simply erroneous. In practice this means that even iftool vendors claim their tools are UML 2.0, XMI 2.1 standard compliant they are often notinteroperable with each other.

The role of XMI in our work is that it is integrated in the Eclipse Modeling Framework (EMF)framework in its recent 2.1 version.

3.1.5 eXtensible Markup Language (XML 1.1)

XML is a text mark-up language for interchange of structured data. Fortunately XML is widelyused, accepted and stable. A wide variety of tools and programming languages support workingwith XML. So this part of the standards is not expected to raise any di�culties. The WorldWide Web Consortium developed some interesting XML dialects, namely XML Schema, XPathand XQuery (to �nd data in XML documents). The predecessor of XML is SGML and the

28

STANDARDS 3

most famous XML dialect is HTML used for Web pages.

In our case: XML is used in this work for the serialized version of formats RCF and Lattice,as well as for UML.

3.1.6 XML Schema 1.0

XML Schema is an XML dialect used to describe the value range of XML documents. It is thesuccessor of DTDs and a particular de�nition is called XML Schema De�nition (XSD). XSDsare far more powerful than DTDs in describing XML languages. They use a rich data typingsystem, allow for more detailed constraints on an XML document's logical structure, and arerequired to be processed in a more robust validation framework. Additionally, XSDs use anXML based format, which makes it possible to use ordinary XML tools to help process them,although WXS (W3C XML Schema) implementations require much more than just the abilityto read XML.

In our case: XML Schema is used in this work to de�ne the XML languages for RCFs andLattices.

3.1.7 Query/View/Transformation (QVT 0.9)

The QVT standard will de�ne a model transformation language and specify the requirementsfor a model transformation tool.

In the submission process for the OMG RFP2 Query/Views/Transformations for MOF 2.0exactly the points concerning model transformations are discussed. In the last proposal amixture of the major precedent proposals seems to become the speci�cation. It makes majordistinctions on di�erent types of transformation and transformation descriptions[25]. The majorideas in this standard are taken from the di�erent working groups which are presented whentalking about model transformation tools. The relations part is like it was in Tefkat and thecore part is like it was in IBM MTF.

Figure 4.5 describes the main idea of the QVT standard proposal. The Transformator trans-forms source models to target models. The Transformator is a processor for transformationdescriptions. Four types of transformation descriptions will be supported3. Two of them followthe declarative approach, the other two more the procedural approach. For these two di�renttypes of approaches to di�erent processors and processing semantics have to be integrated intothe Transformator. It should be possible that one transformation description contains elementsfrom the di�erent descriptions.

For this work the QVT standard is not important yet but a development which should absolutely

2Request for Proposals3Sharp tongues say four transformation languages exist because none of the four major working groups

contributing to the standard wanted to cooperate, but promote their solution.

29


QVT Transformation Description

Transformatoion Engine

Declarative

Descritpion

In relations

language

Declarative

Interpretor

Imperative

Description

In operational

mapping

language

MOF

Black Box

language

core

semantics

any

MOF Operation

(plugged in)

Procedural

InterpretorSource Model Target Model

operational

semantics

In core

language

Figure 3.5: OMG MOF QVT Speci�cation

be monitored in the future. The idea is that a tool implementing this language can replaceparts of the current solution, namely the three transformation steps.

3.2 Tools

Information technology lives from the fact that a lot of tasks have been already solved by others.There is a whole bunch of tools which are available for free or even open source. In this chapterthe tools which seemed to be interesting for the UML refactoring task are discussed. On theone hand tools which serve as UML modeling tools and on the other tools which are solving thetransformation problem. Evaluating tools is very important but time consuming challenge. Itopens up the possibility to reuse work and collaborate with research groups all over the globebut also the danger to get stuck in implementation details, bug �xing and version con�icts.

3.2.1 UML Tools

To evaluate the opportunity to support several di�erent UML tools it is interesting to havea look at the market. Not surprisingly known companies o�er their products but also smallspecialized �rms play a major role. The author will not give a detailed description of the

30

TOOLS 3

di�erent features4 of all the graphical modeling tools even if huge di�erences exist. Everycomparison of tools is nothing that lasts very long, even during the work on this thesis thefeature sets of the di�erent tools changed a lot. The author nevertheless tries to give a quickoverview on the most popular tools which are important in the context of our project and oftenrelated to Eclipse.

The most important fact for a recent UML tool is whether it supports the new UML2 standardon which the work should be based, namely for Class diagrams. To be independent to one UMLtool it is also important whether the tools support the XMI version 1.1 for diagram interchange.

Objecteering UML Suite5: is a tool which is very well known in France because the com-pany Softteam is French. The previous work on the objective of this work has been basedon Objecteering UML Suite and reasons for why not using this tool further have been largelygiven. Nevertheless Objecteering supports a wide range of diagram types and seams to makee�orts to adapt to the UML2 speci�cation in the near future.

objectIF: is a tool from a relatively small German company called microTool6 which is special-ized only on this originally lean product. In the last month a lot of new functionality like codegeneration, use case analysis and simple class diagram refactorings have been added. ObjectIFworks with Visual Studio .NET or Eclipse.

Poseidon UML: by Gentleware7 is one of the tools which are available since the beginning ofUML and with more than 1.000.000 downloads one of the most popular tools worldwide. It isan extension of the open source tool ArgoUML.

Together: by Borland8 is one of the heavy weight tools supporting everything one can imaginebut is very expensive. It can be purchased as a Visual Studio .Net, Eclipse, JBuilder 2005 orC++BuilderX version.

EclipseUML: by Omondo is one of the tools that o�er an unlimited free version with a goodsupport for Class diagrams. Due to the integration into the development environment Eclipseit supports generation of Class diagrams from Java projects and vice versa.

Websphere Studio: by IBM Rational is one of the best known UML tools (known underthe name of Rational Rose) but has been always a heavy weight tool. When purchasing themodeling tool from IBM it is hard not to by the whole Websphere tool suite.

ArgoUML: is the only open source tool in this comparison, hosted on www.tigris.org. with acontinuous development e�ort. At the moment it is still a stand alone solution but based onthe Eclipse Modeling Framework.

4A list with more than 100 UML tools is available at http://www.jeckle.de/umltools.html for a detailedfeature description

5www.objecteering.com6www.microtool.de7www.gentleware.com8http://www.borland.de/together

31


Interoperability: Even if some of the tools pretend to implement the recent XMI version 1.1none of the e�orts to export an UML diagram with one tool and to open it with another suc-ceeded. This was not because of little di�erences in the XML �les but because of big conceptualdi�erences in the interpretation of the XMI algorithm. Also the way of mapping UML elementsto XML elements was completely di�erent which comes from a di�erent implementation of theUML metamodel.

3.2.2 Model Transformation Tools

Model transformation tools are de�ning a model transformation language and are o�ering amodel transformation engine. Several di�erent approaches exist and most of them implementa di�erent part of the QVT standard discussed in the last chapter. Each of the research groupsdeveloping the tools participated in the standardization process.

The evaluation of model transformation tools was done with the objective to �nd a tool toperform the transformation 'UML to RCF' shown in Figure 2.2 which maps UML models toRCF models.

All the model transformation tools evaluated in this chapter have been developed as Eclipseplug-ins. The process of evaluating a tool consists of downloading and installing it with theright versions of Eclipse and other needed plug-ins (most tools require at least the EMF plug-inand the GEF plug-in.) Often the tools provide some kind of documentation and a runningexample that can be tested in the fresh installation. This is the most common situation for�rst errors and exceptions to occur. For questions about their tools the developers maintainmailing lists or newsgroups. This enables the user to search in old threats for similar prob-lems and corresponding answers. Sometimes the newsgroup is the complete replacement fordocumentation. If the �rst example was running (and this was the constraint for all the toolswhich will be presented here) the tool should be applied to a simple but di�erent problem. Atthis point the author did not manage to get a running solution which implemented even thesmallest subpart of the wished transformation.

The result of this evaluation work is that none of the tools has a maturity level that is su�cientto be able to work with it. Even to try out simple examples continuous contact to the developersfor bug �xing support is necessary. Nevertheless a lot of interesting projects are going on and theauthor is sure that the concepts from these tools will soon be used in mature tools implementingthe QVT standard.

3.2.2.1 Model Transformation Framework (MTF)

The Model Transformation Framework9 is an IBM alphaworks product de�ning a rule basedtransformation description language and an engine transforming models according to theserules. An editor and a debugger for the rule de�nitions is part of the tool.

9http://www.alphaworks.com/MTF

32

TOOLS 3

MTF has been developed in order to prototype concepts that may appear in the proposedOMG MOF 2.0 Queries, Views, and Transformations (QVT) standard. The intention is toimplement more of the speci�cation over time. However, this release of MTF is not an attemptto faithfully implement any current proposed QVT speci�cation.

Like all the other tools MTF uses its own language and concepts which are important tounderstand its strengths and weaknesses and how to use it. Some of the most importantconcepts will shortly be explained here.

MTF is basically working on EMF models as input model and output model. The EMF conceptof a transformation in the sense it is de�ned in the previous chapter is a two step process. Itconsists of a mapping in the �rst step which is then followed by the reconciliation.

Mapping: An MTF rule - a mapping rule - de�nes a set of constraints to be checked acrossone or more objects. If the constraints hold, then the objects comply with the rule and don'tneed to be changed. Rules are checked within a mapping session, which tracks which rulesshould hold for which objects.

Reconciliation: The process of modifying mapped model objects in order to �x constraintviolations. Reconciliation is carried out by the transformation engine.

Example: Rule that should map all packages from a UML model to relational context families(RCF) in the RCF model.

MTF needs an Entrypoint Rule:

relate umlpackage2galiciarcf( uml:Package pkg, galicia:RCF rcf ) {

umlclass2galiciabr( over pkg.ownedMember, over rcf.binRelations )

}

relate umlclass2galiciabr( uml:Class class, galicia:BinRel binRel ) {

equals( class.name, binRel.tuple.object )

//no mapping will be created (check only)

}

This describes a mapping from UML Package to an Galicia RCF (Relational Context Family)The arguments in the brackets are the domains of the correspondence - which specify whichset of elements should be mapped to which other set. The keyword over indicates that thearguments are collections and that mappings should be created between the elements of thecollection. Elements which can not be mapped by the umlclass2galicabr() rule/mappingare ignored.

Problems: The mapping mechanism of MTF seamed to produce interesting results on theexample �les but it was not possible to get it to work on other �les. The main problem wasloading the EMF model �les. When writing the transformation source code with the integratededitor the code completion knew the imported models but when running the transformation aruntime exception reported that the model de�nition could not be found.

33


Limits: The procedural mechanism of one entry rule which allows to hierarchically descendin the model tree is not very interesting for how transformation rules should be described forGaliciaUML. One can imagine that to extract an additional chunk of data from the UMLdiagram a lot of additional rules have to be created or rules depending to other logical actionshave to be modi�ed. No clear separation of the di�erent rules for the GaliciaUML conceptcould be reached with this concept.

3.2.2.2 Merlin Generator

Merlin is an open source project hosted by Sourceforge10. It is providing model transformationsupport and the generation of graphical editors (GEF editors) from models. The models need tobe EMF models and the transformation mechanism is based on the EMF mapping mechanism.

EMF Mappings: The Eclipse Modeling Framework is providing a mapping mechanism whereit is possible to graphically map elements of two di�erent models. In Figure 4.6 a samplemapping between two di�erent models is shown. MODEL 1 is the source model and MODEL2 is the target model. Models are presented as tree structures. The mapping between MODEL1 and MODEL 2 is de�ned graphically in the MAPPING view. In the CONSTRAINTS viewmapping constraints can be de�ned in a proprietary constraint language. What is denoted withMODEL here in fact are metamodels, because these models instances are models.

Merlin Generator allows to add additional constraints to the mapping using a simple scriptinglanguage to express more complicated mappings. The mappings de�ned on the models can beinvoked on arbitrary metamodel instances .

Problems: No documentation of the model transformation mechanism was available. Thealgorithm how the transformation engine was traversing the model and when creating newmodel elements was dependent of the positions of the model elements in the element hierarchyand not obvious to understand. It was not possible to create a new model element for athird level model element without creating model elements for the �rst and second level modelelements.

Limits: The graphical declarative approach made it very easy to write some clear and simplerules but when expressing more complicated constraints the approach seamed not to be suitablefor the task.

3.2.2.3 Tefkat

Tefkat11is developed by the DSTC working group of the University of Queensland/Australia.To download the tool via the Eclipse Update Service12 one needs to be registered (but it isfree).

10http://www.sourceforge.net11http://www.dstc.edu.au/Research/Projects/Pegamento/tefkat/12Username: tefkat-user - Password: tarzan

34

TOOLS 3

Figure 3.6: Merlin Generator

35


Figure 3.7: Tefkat Transformation Engine

The Tefkat tool seemed to be the most suitable for the type of transformation needed for Gali-ciaUML because of the combination of declarative and procedural elements and the relativelyhigh quality documentation provided with the QVT proposal. It is build up around an con�gu-ration �le in which the source and target models and metamodels as well as the transformationdescription can be put together. A screenshot of the graphical editor for this con�guration �leis shown in Figure 4.7. The transformation can be invoked from this �le via a menu.

In this section general concepts which are elements of the Tefkat transformation language willbe explained. The most important are Transformations, Rules, Patterns (Source and Target)and Trackings. This model used by Tefkat is very similar to what has been presented in section3.3.4 in Figure 3.5.

Transformation: A transformation is the container of all of the patterns, rules, trackings. Itde�nes a name space for rules, so that name clashes may be avoided.

TRANSFORMATION uml2rel : uml -> rel

IMPORT http://simpleuml

IMPORT http://relational

This is a transformation that works on the to namespaces which are imported and de�nes whichis the source and which is the target model namespace.

Patterns: Patterns are used for the source model and target model. Source patterns are usedto match model elements in the source model. Target patterns (called 'Templates' in the lastversion) are used as a template for new model elements in the target model. Source patternsare evaluating to boolean, so they may be seen as conditions.

PATTERN hasAttr(C,A)

36

TOOLS 3

FORALL Class C, Attribute A, Class C2

WHERE A.owner = C

OR (C.Super = C2 AND hasAttr(C2, A))

This 'Pattern' is a 'Source Pattern' and is evaluating to true if the Class C and the Attribute Ahave the relation that C is the owner of A or a superclass of C is the owner of A. It is a recursivecall and is similar to what is known as a function in conventional programming languages.

Rule: A Rule is used to de�ne how a 'Pattern' in the source model is used to create some partof a target model element. It can have variables which are called assigned values13 when thesource model is matched.

RULE Uclass2Jintf(Cls)

FORALL Class Cls

MAKE Interface Intf

The Rule describes that for each Class in the source model an Interface in the target modelshould be created. Here the 'Source Pattern' and the 'Target Pattern' are extremely simple(Class and Interface) consisting of only one model element.

Trackings: are declarations of the kinds of relationships between source and target modelsthat need to be stored for traceability. They are a mechanism for cross-references betweenrules that address the same types of model element.

RULE Uclass2Jintf(Cls)

FORALL Class Cls

MAKE Interface Intf

LINKING Cls to Intf by Uclass2Jint

This 'Tracking' described by the keyword 'LINKING' creates a relationship between all theClasses in the source model and the Interfaces in the target model. This relationship can beused by other rules.

Problems: It was not even possible to test on of the most simple examples provided on theTefkat Homepage. Outdated documentation with contradictory descriptions for basic syntac-tical elements made it impossible to get the transformations to work.

Limits: In contrast to the other two tools there were no theoretical limitations found on theTefkat approach of mixing procedural and declarative elements in the transformation language.Tefkat seems to be one of the most important committers to the QVT standardization processand could be used to implement the missing GaliciaUML model transformations when reachinga more mature state.

13for more information see the Tefkat Tutorial on the website

37


3.2.2.4 openArchitectureWare

OpenArchitectureWare14 is a suite of tools and components assisting with model driven softwaredevelopment built upon a modular MDA/MDD generator framework implemented in Java. Itsupports arbitrary import (design) formats, metamodels, and output (code) formats. Thedevelopers are more and more engaded also in the Eclipse Community, particularly in theGMF project.

3.2.2.5 OMELET

OMELET is an Eclipse project15. It is a model transformation tool based on XSLT2 to inte-grate di�erent modeling tools. Some basic transformations are already integrated. No furtherdevelopment is expected since OMELET may be one of the initial contributors to the EclipseMDDI project.

3.2.2.6 Graphical Modeling Framework (GMF)

The Eclipse Graphical Modeling Framework project16 provides the fundamental infrastructureand components for developing visual design and modeling surfaces in Eclipse. GMF forms agenerative bridge between EMF (see 6.4.1 and GEF (Eclipse Graphical Editing Framework),whereby a diagram de�nition will be linked to a domain model as input to the generation of avisual editor. The project aims to provide this framework, in addition to exemplary tools forselect domain models which illustrate its capabilities.

An UML modeling tool will be developed in the context of this project as an example whichshould than be used as the frontend for GaliciaUML. The GMF project is currently in theValidation Phase, as de�ned by the Eclipse Development Process. A set of project requirementsare posted while a series of contribution reviews have recently been completed. The �rst releaseis scheduled for spring 2006.

3.2.2.7 Rules Engines for Model Transformations

The concepts implemented in rules engines are very similar to what is implemented in trans-formation engines. Also the languages to specify rules are close. It is not straight forward toapply rules engines to model transformations because even if the transformation logic can beimplemented the technology for working with models/metamodels is not integrated. Two rulesengines will be shortly mentioned.

14http://architecturware.sourceforge.net/15http://www.eclipse.org/omelet/16http://www.eclipse.org/gmf/

38

TOOLS 3

Figure 3.8: MDDI Model Bus (from www.eclipse.org/mddi)

Jess17: Jess was originally inspired by the CLIPS expert system shell, but has grown into acomplete, distinct, dynamic environment of its own. Using Jess, you can build Java softwarethat has the capacity to "reason" using knowledge you supply in the form of declarative rules.

Visual Rules18: is a commercial product developed by the company Innovations as an Eclipseplug-in. The tool enables the user to visually design the rules and its constraints and to changethe rules while the underlying software system is running.

3.2.2.8 Model Driven Development Integration (MDDI)

The Eclipse MDDI project 19 is not a model transformation tool itself but shall serve exactlyat the purpose of model transformations. Its aim is to support model transformations neededin the MDA or more generally MDD approach. They want to build a generic model repositorywhere for example the transformation from the Platform Independent Model (PIM) to thePlatform Speci�c Model (PSM) will be supported.

Figure 4.8 shows that the ModelBus can be compared to a middleware as it o�ers facilitiesfor managing modeling services interoperability. The particularity of ModelBus is that it isdedicated to models. It mainly o�ers facilities at the model layer (M1 in the four layers archi-tecture). It has the charge of model representation, and model transmission. The ModelBusarchitecture is composed of three high-level components: Adapter, Noti�cation Service andRegistry. Those components o�er added value to tools that want to consume or provide mod-eling services. They fully rely on the Eclipse platform and extend it for managing modelingservice interoperability.

17http://herzberg.ca.sandia.gov/jess/18http://www.visualrules.de19http://www.eclipse.org/mddi/

39


3.3 Conclusion

Standards and Tools are very important when working in the domain of Model Driven Engi-neering. The most important standard discussed in this section for this work is the UML 2.0standard, the most important diagram type the class diagram. The most interesting standardthat should be monitored in the near future (release end of this year 2005) is the QVT (QueryView Transformation) standard. This standard will most probably trigger important tool de-velopments concerning model transformation tools. Regarding the di�erent tools it is not soeasy to priorize. A rule of thumb could be that Eclipse projects normally are well organizedand are less likely to die. The GMF project is perhaps the most interesting one. Besides theEclipse projects the Tefkat tool seems to be close to be applicable.

40

Chapter 4

Architecture

4

In this chapter it will be explained how the complete UML refactoring system can be splitup into architectural components to converge to an implementation. The main dependenciesand interfaces as well as basic algorithms of these components will be presented. This will bedone without mentioning any implementation details concerning the programming languageor technologies. How the concepts described in this chapter are implemented using Java andEclipse technology will be described in the Design chapter 7.

4.1 The Big Picture

The complete system is described in Figure 5.1. It consists of three di�erent active componentscommunicating via storages and one simple user interface. Each of these three components andthe storages data formats will be described more in detail throughout this chapter to understandall the architectural decisions prior to talking about implementation details. In this section wewill discuss the top level components and talk about their interaction in the process of usingthe refactoring tool.

The user interface of the tool consists of a UML diagram, some algorithm con�guration and aninvocation channel (see Figure 5.1). To understand this interface and the tool it helps to talkabout what a user of the tool does as described in the Petri Net shown in Figure 5.2.

The user needs to create (draw or generate) a UML diagram that he wants to refactor. Through-out this chapter we will take the UML diagram shown in Figure 5.4 as an example. This diagramneeds to be made available for the algorithm (e.g. by specifying the �lename). Before he canlaunch the algorithm more or less complicated con�guration work can be done. This con�gu-ration depends on the level of con�gurability of the algorithms in the subcomponents and theintention of the user.

When con�guration work is done the user can launch the transformation and wait until therefactored output diagram is generated. In the meanwhile the di�erent transformation stepschained at each other in the refactoring tool do their work. The reason for this pipe structure isthe fact that the Multi FCA algorithm embedded in the Galicia tool should be used to performthe main mathematical transformation �nding the new concepts. The two other transformationscan be considered more or less as format conversions into the Multi FCA speci�c data format

41

4 ARCHITECTURE

Relational

Context FamilyRCF to Lattice

Galicia

Multi FCA

Lattice

UML to RCFUML

Diagram

Transformation

Rules

draw

define

R


Lattice to UML

Restructured

UML

Diagram

Figure 4.1: The complete System

RCF and from the Multi FCA speci�c data format Lattice to UML.

In this chapter we will talk about the interface that will collect the con�guration data forthe di�erent transformation steps and enable the user to invoke the transformation as well asde�ne an UML diagram. After that the UML to RCF transformation will be presented in detail.Its task is far from being a simple data format conversion because the major requirement forthis algorithm was to be extremely con�gurable. In the context of this algorithm the RCFdata format will be presented to enable the reader to understand the reasoning towards thedesign of the transformation language. The presentation of the Galicia Tool will be very shortand just explain on a little example how the Galicia Tool creates sets of concepts latticesfrom RCFs. Neither algorithmic details nor architectural structures of the Galicia tool willbe presented here because it has been considered as a black box throughout the reasoningabout the architecture of the tool whenever possible. Architectural details and two di�erentalgorithms to deduce refactored UML diagrams from concept lattices will be presented in thesection 'Concept Lattices to UML'. After talking about all the components in detail I will pointout why all the reasoning about Models, Meta models and Transformations in chapter 3 wasimportant. We will see how this in�uenced the tools architecture.

4.2 Interface

A UML refactoring tool needs an interface where a UML model can be made available. Inaddition to the UML diagram a description of the �rst transformation (transformation rules)needs to be given by the user. This is necessary because this is some kind of con�gurationthe algorithm needs. The user decides which information the algorithm takes into account tosearch for the new concepts. The third part of the tools interface is a channel to invoke thetransformation process.

In the case of the here presented UML refactoring tool architecture the con�guration interfacefor the �rst algorithm, UML to RCF, is the most complicated one (highlighted in Figure 5.3).The interface, a transformation language with editor, will be presented with its algorithm insection 5.3. The con�guration data for the two other algorithms is much more simple (�ve toten options per algorithm maximum) and can be covered by a simple user dialog or wizard.This fact can change over time to more powerful con�guration needs when in particular the

42

INTERFACE 4

Draw UML Diagram

User Refactoring System

Configure Refactoring

Algorithms

Invoke RefactoringTransform UML to RCF

Transform RCF to

Lattice

Transform Lattice to

UML

Wait for Refactoring

to complete

Enjoy Refactored UML

Diagram

Figure 4.2: The main System Dynamics

43

4 ARCHITECTURE

UML to RCF

Configuration

Input

UML2 Model

R

Invoke

Transformation

UML to RCF(Transformation Language)

RCF to Lattice

Lattice to UML

Configuration

Editors

UML Modeling

Tool

R

Configure

Algorithms

R

Draw

Diagrams

Transformation

Language

Editor

Figure 4.3: The Refactoring System Interface

concept lattice to UML algorithm evolves (see chapter 8).

The UML drawing tool to modify UML models like the Polygon model shown in Figure 5.4has not been developed in the context of this work. As discussed in chapter 4 an appropriatetool had to be found that integrates as well into the refactoring tools user interface as well assupporting a standardized and open data format.

4.3 From UML to RCF

To enable the Multi FCA algorithm in the Galicia tool the original UML model has to betransformed into the RCF (Relational Context Family) model format. As well the UML meta-model as the RCF metamodel are de�ned. The logic of mapping UML metamodel elements toRCF metamodel elements will be discussed in the beginning of this section. Than we will talkabout architectural approaches for a model transformation tool and the design of the modeltransformation language.

4.3.1 Transforming an UML model into a Relational Context Family

Figure 5.4 shows an possible input UML diagram. The metamodel of UML has been discussed inchapter 4. The Polygon model uses only three types of elements from the rich UML metamodelelement set, Classes, Properties and Generalizations. This UML model should now be presentedin the RCF data format.

44

FROM UML TO RCF 4

Figure 4.4: An Input UML Diagram

4.3.1.1 UML2 Metamodel

The UML2 metamodel is described in the UML2 Superstructure Speci�cation in detail. Toprogrammatically work with this metamodel an implementation of this standard should beused which provides methods to create, parse, modify and serialize the models.

4.3.1.2 The RCF Metamodel

The RCF metamodel is a very simple metamodel. Figure 5.5 shows an entity relationship dia-gram describing the most important entities. The metamodel contains two structured elementtypes, BinaryContexts and InterObjectContext. An Relational Context Family (RCF) is thecontainer for a set of these two types of BinaryContexts. A BinaryContext in general is acontainer for BinaryRelations, say a table with Columns and Rows. The di�erence betweenthe InterObjectContext and the BinaryContext is in the type the elements which are part ofthe relation (Columns and Rows in the table) have. If in the Columns are Attributes and theRows are Objects it is called a BinaryContext. If both participants of the relation are Objectsthe Context is called a InterObjectContext. Every InterObjectContext additionally needs toreference two RelationalContexts. These RelationalContext need to be the RelationalContextsthat describe the Objects the InterObjectContext connects.

Unfortunatly this metamodel was not subject to change. That's why the terms describing thedi�erent elements are not well chosen in the opinion of the author. In Figure 5.5 the author

45

4 ARCHITECTURE

BinaryRelation

Elements

Object Attribute

Row Column

InterObjectRelation

Row Column

Relational

Context Family

RCF

Context

InterObject

Context

BinaryContext

Container

contains

Container

contains

Container

contains 0..1

2Referencer

point to

Figure 4.5: Relational Context Family Metamodel - FMC ERD

tried to describe the metamodel in the clearest way, Figure 5.10 shows in the lower right howthe metamodel has been originally de�ned in an UML diagram.

4.3.1.3 An Example RCF Instance

How a UML model is expressed in an instance of the RCF metamodel (a RCF model) is shownin the three tables of Figure 5.6. The three tables correspond to two RelationalContexts andone InterObjectContext. The topmost table shows the relation between the object type Classand the attributes of the Classes. Every model element in the UML model that was an instanceof the UML type Class now is represented with its identi�er (here the quali�ed name) as anObject in the rows of the table. In the columns of the table some interesting attributes areexpressed. All attribute descriptions are key value pairs (e.g. isAbstract=false) allowing todescribe the relations to the Objects with a simple boolean value.

The second table (middle of Figure 5.6) shows as well a RelationalContext, this time containingall instances of the UML metamodel element Property the Polygon UML model contains.

The lower most table describes an InterObjectContext. It references the two RelationalContextsClass and Property and describes whether a speci�ed relationship in the UML model instanceexist between the Class and Property instances that exist in the Polygon model. In the caseshown in Figure 5.6 the relationship that is indicated by a marked �eld in the table is the factthat the Property instance in the column is an 'owned member' of the Class instance in therow.

46

FROM UML TO RCF 4

Figure 4.6: Relational Context Family - Tables shown in Galicia Tool

47

4 ARCHITECTURE

4.3.2 Transformation Con�guration Requirements

The content of the RCF is solely responsible for the quality/usability of the output of theGalicia Multi FCA algorithm. Which content of an RCF produces the best results is not knowat the moment, but the di�erent properties of the RCF which change the result are known.These properties are the answers of the following questions:

• How many Relational Contexts are in the RCF?

• Which UML metamodel elements do they describe?

• Which attributes are used to describe the Relational Context?

• How many InterObject Contexts are in the RCF?

• Which Relational Contexts do they connect?

To achieve that all these properties of the RCF are con�gurable the UML to RCF transformationwill be described by a set of rules. This enables the end user to develop step by step the mostsuccesful set of con�guration rules.

In this section �rst the model transformation language will be described and following a simpleexample the di�erent components of the transformation engine will be discussed. Finally we willtalk about how the architecture of such transformation engine processing of a transformationlanguage could be. Two ways are possible: code generation and invocation of generated codeor the use of re�ection.

4.3.3 UML to RCF Transformation Language

The design objective for the language was to �nd the most simple set of information whichis needed to describe a UML2 to RCF transformation. It should not serve as a full featuredmodel transformation language. This means supporting to transform every model type intoevery other model type is not the objective of this tool, only UML models to RCF models.

The input UML2 should be transformed to a result RCF. The easiest way towards a transfor-mation language is to identify which information should be found in the UML and into whichplace this should be trnasformed in the RCF.

What needs to be in a Rule:

• for each BinaryContext

� the type of the UML metamodel element for which the instances should be describedin the RCF

48

FROM UML TO RCF 4

Transformation

- Name

Rules

- Name

Transformation Document

contains contains

references

InterObject Rule

- Condition

- Column

- Row

RelationalRule

- matchType

AttributeColumns

- Description

- Attribute access

method

contains

Figure 4.7: Transformationlanguage Model

� all the attributes that will appear in the columns

• for an InterObjectContext

� the two metamodel elements they interconnect

� the condition that determines whether to interconnect to instances

The uml2rcf model describes these rules (see 5.7). It supports two types of rules - Interobjec-tRules and RelationalRules. Relational rules are described by a matchType and the methodthat is needed to access the attributes of this type which should appear in the result.

A valid transformation description has to be conform to the metamodel shown in Figure 5.7.The transformation description has to contain a root element which is called Transformation-Document which contains all the further elements of the transformation description. Onedocument normally contains a whole set of transformation descriptions which all use rules. Arule can be used by multiple transformations. This enables the user to write a whole set ofrules and than try out di�erent transformations which consist of di�erent subsets of rules.

This model is used to describe the language and to generate the source code to load, treatand store the model instances, say the transformation descriptions. The model de�nes thateach Transformation is part of a Transformation Document which contains multiple Transfor-mations. The Transformation Document also contains Rules. Each Transformation referencesan arbitrary set of rules with the constraint, that each InterObject Rule needs to reference twodistinct Relational Rules which have to participate in the Transformation as well. Each Rulecan be either an InterObject Rule or an Relational Rule. The Relational Rule consists of amatchType, the type of the UML Metamodel which will be extracted from the diagram by thisrule and a set of Attribute Columns. Each Attribute Column describes one Attribute of thematchType in the Metamodel and how the value of this attribute should be represented in thetarget RCF. InterObject Rules describe the relationship between two Metamodel elements. Forconsistency reasons in the RCF the two metamodel elements, for which the InterObject Ruledescribes the relationship, must be part of the transformation as well. The InterObject Ruledescribes the condition to be true and references the two Relational Rules.

49

4 ARCHITECTURE

Figure 4.8: Example of the Transformationlanguage

Figure 5.8 shows how a simple transformation document could look like. In this example wecan see that our 'Transformation Document' contains four 'RelationalRule' objects and two'InterobjectRule' objects as well as two 'Transformation' objects. Each Transformation coversa di�erent set of rules, which could be seen in the user interface by opening the 'PropertiesView' of the 'Transformation' object. The �rst rule is the 'RelationalRule' with the name'Class'. It has the 'matchType = Class' that describes the metamodel object 'Class'. Thefour 'AttributeColumn' objects the rule contains describe the interesting attributes of a 'Class'which are in this case name, visibility, isLeaf and isAbstract attributes.

This rule will produce one table in the output RCF that describes all the classes from the inputUML model and their attributes. The other Relational Rules can be understood similar as theydescribe the metamodel elements Property, Operation and Association.

The current version of the Multi FCA implementation in the Galicia tool exists the constraint,that for each InterObjectContext that connects one metamodel element with the another thereneeds to be a second one indicating the reverse direction. In this case this is done by the rulePropertyToClass which does point out for each Property which is the Class it belongs to.

4.3.4 UML to RCF Transformation Engine

The transformation engine is a processor for the transformation language. Similar to the ar-chitecture of transformation engines mentioned in chapter 4 the here presented transformationengine is split up into two main components. The �rst component is a code generator translat-

50

GALICIA 4

ing the rules language into source code, the second component is the transformation runtimeinvoking the source code and performing the transformations on the UML models.

4.3.4.1 Transformation Language Rules Generator

The Generator translates the rules language into source code. Due to the very restricted trans-formation language the generator complexity stays relatively low. Additionally no advancedcode generation technology concepts like (incremental building etc.) are supported.

For each rule object in the transformation a software component will be created. Dependingon the type of the rule this component will be an implementation of the InterobjectRule orRelationalRule. After the creation of the source code the compiler will be invoked to create anexecutable.

4.3.4.2 Transformation Engine Runtime

The runtime is responsible for parsing the input model, instantiating the rules and managingthe transformation process.

Depending on the transformation description the runtime loads the components implementingthe appropriate rules on an as needed basis. Each rule searches in the input model for the 'sourcepattern' (see section 3.3.4) speci�ed in the rules description by 'matchType' and 'condition'.The target pattern is dependent on the rule (InterObjectRule or BinaryRule) but always onemodel element of the RCF output model.

4.3.4.3 Alternative Approach - Re�ection

Alternatively to the two step idea of �rst generating source code which implements the compo-nents like de�ned in the transformation description the problem could be solved using re�ectionmechanisms. The methods which have been generated in the generator approach could also becreated by re�ection at runtime. This would enable the transformation engine to be one singletool instead of the tow separated parts described above.

4.4 Galicia

The Multi FCA algorithm is the heart of the transformation. It contains the mathematicaltheory how to �nd new concepts in data structures. This algorithm was given and not subjectto change. It is implemented in the Galicia tool. The task now is to understand how an interfaceto Galicia can look like.

51

4 ARCHITECTURE

UML to RCF

Generator

Transformation Engine Runtime

Input

UML2 Model

Rules Rule Parser/

Code Generator

Rules

Source Code

Compiler

Byte Code

Classloader

Model Parser/

Rules Activator

R

invoke

load

Rule 1

Rule 2

Rule nR

Invoke

Transformation

Speicified by Name

R

R

R

update

R

invoke

Transformation

Rule

Relational

Context Family

Figure 4.9: UML to RCF Transformation Engine

4.4.1 Interface

The input for the Multi FCA algorithm is a Relational Context Family and a small numberof parameters to con�gure the algorithm. The output of the algorithm is a set of ConceptLattices.

Unfortunately the Multi FCA algorithm is implemented in the Galicia tool and there wasno possibility to work with Galicia without a graphical interface at the moment. So whenperforming the Galicia transformation the user must use the Galicia interface. This would notallow a seamless integration of the tool chain.

To form a possibility to integrate the tools, a programmatical interface to invoke and con�gurethe Multi FCA algorithm in the tool needs to be created. Unfortunately this assumes thedeveloper to understand the Galicia implementation and more important to change the Galiciatools source code and recompile it. This was not the intension in the beginning of the workbecause this changes were not supported by the Galicia group and therefore lead to a proprietaryGalicia version.

4.4.2 Galicia Metamodel

The Galicia metamodel describes all the input and output formats which are important for theGalicia tool in one �le. A lot of di�erent data formats are de�ned this metamodel that arenot important for the Multi FCA algorithm. Only two distinct sections in this metamodel are

52

GALICIA 4

Figure 4.10: Galicia Metamodel - Lattice and RCF Part highlighted

53

4 ARCHITECTURE

Figure 4.11: Galicia Screenshot: Result Lattice - describes Properties

important for this work. The author proposes to create several metamodels, one for each inputand output format instead of specifying all di�erent concepts together in a big one.

Figure 5.10 shows the two important parts of the Galicia metamodel. The RCF part has beenalready described in section 5.3.1.2. The Lattice part of the metamodel describes the datastructure of a Lattice as known from mathematics.

4.4.3 Concept Lattices

The result of the Multi FCA algorithm are several concept lattices. Figure 5.11 and 5.12 showthe visualization of two of the result lattices by the Galicia tool. It is the result when the RCFshown in Figure 5.6 was the input. Even in this simple example the result lattices are big. Inthe next section will be described how an algorithmic interpretation of these lattices can be.

4.5 Concept Lattices to UML

In this section two possibilities how to translate concept lattices into refactored UML diagramswill be presented. The �rst possibility is to completely reconstruct the whole UML diagram

54

CONCEPT LATTICES TO UML 4

Figure 4.12: Galicia Screenshot: Result Lattice - describes Classes

only depending on the information the concept lattices contain. The second possibility is totranslate the concept lattice content into single refactorings which than will be performed onthe initial UML diagram.

Both solutions are based on an algorithm which interprets the concept lattices that have beenproduced as result by the FCA algorithm.

4.5.1 Interpreting Concept Lattices

Depending on the number of the UML metamodel elements that served as input for the refac-toring the number of the concept lattices varies. For each metamodel element one conceptlattice is created. The concept lattices are interconnected by references. Each concept latticemay contain new concepts that need to be considered by the interpretation.

The two concepts lattices showed in the example are the concept lattice describing the classes(Figure 5.12) and the concept lattice describing the properties (Figure 5.11).

The Classes Lattice: Some concepts in the classes lattice represent the old classes. In thisexample these are the concepts 0, 3 and 4. They already existed in the original UML diagram.The rest of the concepts now has to be judged whether it is interesting to produce a new concept

55

4 ARCHITECTURE

in the UML model or not.

When regarding the classes lattice it is possible to �nd patterns which indicate that introducinga new class in the UML model would make sense. The connections between two concepts canbe translated into inheritance relationships between the UML classes. How these Pattern looklike exactly will not be discussed here because this remains a research work and the algorithmsare subject to change.

The Properties Lattice: Interpreting the properties lattice is even more complicated, becausenew concepts in this lattice indicate that new properties should be introduced into the UMLdiagram. How to translate the relation between concepts in the lattice into relations betweenthe properties in the UML model is not obvious. A �rst possibility is to use the subsets

relationship between Property elements.

Generic Interpretation: The presented train of thoughts regarding the interpretation ofthe di�erent lattice types leads to the question if a generic interpretation of lattices is possi-ble. In the opinion of the author this is not possible but also the Concept Lattices to UMLtransformation step needs a lot of information about the transformation. This information canbe provided like in the UML to RCF transformation via con�guration language. A conceptfor a more generic or con�gurable interpretation is one of the important tasks for the furtherdevelopment of the Multi FCA refactoring idea.

4.5.2 Complete Reconstruction

A complete reconstruction algorithm will traverse each lattice a �rst time and create one meta-model element for each concept that describes an old metamodel element. For example travers-ing the classes lattice creates one class for each old concept, traversing the properties latticecreates one property for each old concept. Then the new concepts will be searched for thetwo lattices, they will be created also. When all model elements are created they need to beconnected by the apropriate relationships (e.g. Generalization for the Classes).

In a third step the attributes of the created model elements need to be set. This means alsothe references between the lattices have to be considered and the intent of the concepts has tobe translated into UML metamodel properties.

In the process of complete reconstruction depending on the patterns which lead to the creationof UML model elements sometimes uninteresting model elements will be created. It is ofteneasier to detect this when all model elements have been created than never creating theseuninteresting patterns. When everything is created these uninteresting patterns of elements(e.g. Classes with no name which have only Properties with no name) are deleted.

Figure 5.13 shows the static and dynamic structure of how this component will be embeddedin the transformation chain and how the algorithm works.

Figure 5.14 shows the refactored Polygon UML diagram (original diagram in Figure 5.4. Thisdiagram contains several generated classes and generated properties. I will not discuss the

56

CONCEPT LATTICES TO UML 4

Set of Lattices

Complete Reconstructor

Restructured

UML

Diagram

Algorithm Config

Parse/Load Lattices

For every

Lattice

Determine Lattice

Type (e.g Class)

Create Model

Elements (e.g

Classes)

Create Relationships

between this model

elements (e.g

Generelization)

Connect Model

Elements of different

Types (e.g Classes to

Properties –

setOwnedMember)

Delete Uninteresting

Model Elements

(e.g Classes with no

name which have only

Properties with no

Name)

For every

Lattice

Create new empty

UML Model

Save New Model

Read Algortihm

Configuration

Figure 4.13: Complete Reconstruction - Static and Dynamic Structure

57

4 ARCHITECTURE

Figure 4.14: Refactored UML Diagram

concrete elements of the new diagram nor talk about the sense of these refactoring because thiswork is done to show that the results of the Galicia algorithm can be used not to exactly showhow. This is considered to be future work as described in chapter 8.

4.5.3 Incremental Refactorings

The objective of this component is to obtain a list of incremental refactorings which shouldbe proposed to the user. The user can invoke one of the proposed refactorings on the originalUML diagram which then should be performed by the component.

To get this list of incremental refactorings the patterns which have to be found are resembling tothe patterns for the complete restructuring, but more complicated to �nd. For one refactoringperhaps several di�erent lattices have to be interpreted together, regarding references betweenthe lattices.

Example: For the Refactoring 'Extract Supertype' which in a �rst guess seems only be depen-dent on the Classes lattice perhaps also new Property objects have to be created. Not only thecreation of new Model elements is necessary but also changing the old ones and introducing

58

A TRANSFORMATION CHAIN WITH METAMODELS 4

Set of Lattices

Incremental Refactorer

input

UML

Diagram

Algorithm Configuration

Refactoring

Patterns

Search

EnginePossible

Refactoring

Descriptions

Refactorer

UIRefactoring

Proposition

R

Invoke Single Refactoring

Rinvoke

Figure 4.15: Incremental Refactoring - Static Structure

the inheritance relationships between them.

Figure 5.15 shows the static structure of this component. It consists of the 'Refactoring PatternsSearch Engine' which has already been described above, a user interface where the possiblerefactorings can be presented to the user and the 'Refactorer'. The 'Refactorer' can be invokedby the user via the user interface to perform the selected refactoring on the original UMLdiagram.

Figure 5.16 shows a Petri Net describing the dynamics of this component and the interactionwith the user. An important remark is that after one Refactoring has been performed from thelist of possible refactorings the other refactorings in this list are not valid any more. After onerefactoring the complete refactoring algorithms have to be invoked another time with the nowchanged UML diagram as input.

The incremental refactoring has advantages regarding the usability by modelers who like tohave an assistance tool proposing them refactorings. The complete reconstruction algorithmis less convenient to use at the moment because the results are more complicated to interpret.Nevertheless performing single refactorings and �nding the important patterns might be morecomplicated than the complete reconstruction.

4.6 A Transformation Chain with Metamodels

The GaliciaUML tool is build up on a set of metamodels. As described in chapter 4 whentalking about metamodeling and model transformations what GalicaUML does can be seen asa big model transformation consisting of three smaller model transformations. Each of the threesmaller model transformations can be performed in a lot of di�erent ways. Referring to chapter4 the elegant way of transforming models is using a model transformation engine and describingthe transformation in a model transformation language to de�ne the transformations on thesource and the target metamodel. This was the initial plan when designing the GaliciaUMLtool. It failed because none of the existing model transformation tools was mature enough.The solution presented in this chapter is summerized from this point of view in Figure 5.17.

Figure 5.17 shows that for all data formats explicit metamodels exist. The transformation com-

59

4 ARCHITECTURE

Load/Parse Lattices

Search for

Refactoring

Patterns

Create Refactoring

Description

Propose possible

Refactorings to User

Choose Refactoring

Invoke Single

Refactoring

Perform Single

Refactoring

Traverse

Lattices

Wait for

User Input

Incremental Refactorer User

Figure 4.16: Incremental Refactoring - Dynamic Structure

60

DECISIONS - TOWARDS AN IMPLEMENTATION 4

Relational

Context Family

Galicia

Multi FCA

Lattice

UML to RCFUML

Diagram

Transform.

Rules

Lattice to UML

Restructured

UML

Diagram

RCF

Metamodel

Lattice

Metamodel

Transformation

Metamodel

UML

Metamodel

UML

Metamodel

GeneratorModel

Metamodel

Model

Metamodel

Figure 4.17: GaliciaUML - A Transformation Chain of Metamodels

ponents work with these metamodels. The UML to RCF transformation component is alreadyclose to a transformation engine because the transformation is described in a transformationlanguage from which the actual 'UML to RCF' is generated. This perfectly implements theconcept of model transformation as presented in Figure 3.4 in chapter 3 because additionallyto the source and target metamodels also a transformation metamodel exists. As discussed insection 5.3 this is not a generic transformation engine because the transformation language isrestricted to the two metamodels.

In contrast to the UML to RCF transformation the two other transformation steps RCF toLattice and Lattice to UML don't implement these concepts. The transformation rules arehardcoded in the source code of these components. This leads to several restrictions whenworking with the tool. As discussed when talking about the Lattice to UML transformation inthis chapter the need for more con�gurability already appeared.

4.7 Decisions - towards an implementation

In this section we will discuss what basic decisions need to be made before thinking about thedesign of the software system. These decisions are the basis for continuing towards a runningsystem concerning tools, standards and technologies that will be used.

4.7.1 Decisions Overview

The system that should be build is described in Figure 5.1. On each of the components nowwe should be some more speci�c. When deciding it is important to have the requirements inmind. Let us sum up a last time the most important requirements

61

4 ARCHITECTURE

• future - further development by a large community

• standards - which are implemented by a lot of tools

• open - to share it in the academic community

• feasible - reuse existing work to keep development e�ort as low as possible

Respecting these requirements the decisions that had to be made were about the UML tools tosupport and about which standards should be used. What type of transformation engine to useto support the model transformation 'UML to RCF' and 'Lattice to UML' in Figure 5.1. Whichprogramming language to use for the implementation and what development environment touse with the UML tool to generate UML diagrams for software systems.

1. UML Tool -> Omondo Eclipse UML

2. IDE -> Eclipse Java Development Environment

3. UML Metamodel and Data Format -> EclipseUML

4. Support for Models/Metamodels -> Eclipse Modeling Framework

5. Integration Framework and GUI -> Eclipse Framework (Plug-in Concept)

6. Model Transformation Engine -> Hand written

These six decisions where not taken independently, but no �xed dependency hierarchy existsneither. In the next section the decisions will be presented more in detail.

4.7.2 Decision Details

UML Tool: The most important advantage of the Omondo1 UML Tool is that it works withthe EclipseUML data format. This makes it possible to replace the UML Tool with every otherUML Tool working on the same format if eventually another tool seams more appropriate. Asecond advantage is that the Omondo product has a free license which is o�ering all neededClass diagram drawing and generating capabilities.

IDE: The development environments which are used by most of the UML tools evaluated inthe last chapter are Microsoft Visual Studio .NET and Eclipse. Microsoft Visual Studio .NETis a commercial product and very expensive. It does not run on Linux machines. Eclipse is awidely distributed and accepted open source tool. The Omondo UML tool is based on Eclipse.The Eclipse IDE runs on a wide variety of operating systems and is the perfect match forGaliciaUML development.

1http://www.omondo.com

62

DECISIONS - TOWARDS AN IMPLEMENTATION 4

UML Metamodel and Data Format: The Eclipse UML2 metamodel and data format is anopen source implementation of the latest UML 2 speci�cation. The objectives of this project areto provide a usable implementation of the metamodel to support the development of modelingtools and a common XMI schema to facilitate interchange of semantic models.

It is the perfect match for the GaliciaUML development because the data format is not depen-dent on one tool or another but is supported by the Eclipse Community. It is just implementedfor the sake of having a reference implementation for the UML 2 standard. UML2 is based onthe Eclipse Modeling Framework.

Support for Models/Metamodels: To support the development of and work with mod-els/meatamodels the Eclipse Modeling Framework (EMF) provides a lot of features. EMF is amodeling framework and code generation facility for building tools and other applications basedon a structured data model. From a model speci�cation described in XMI, EMF provides toolsand runtime support to produce a set of Java classes for the model, a set of adapter classesthat enable viewing and command-based editing of the model, and a basic editor. Using thisFramework for the GaliciaUML development will simplify a lot of tasks especially parsing andserialization of model descriptions as well as the development of programming interfaces for thedi�erent models.

Integration Framework and GUI: The Eclipse Framework is an extensible tools platformo�ering a lot of build in support for common problems such as graphical user interfaces. It isbuild for the integration of di�erent tools what is the task with GaliciaUML as well. GaliciaUMLcan be developed as a Eclipse plug-in which can exploit the complete functionality o�ered by theEclipse Framework. The user interface can be seamlesly integrated into the Eclipse Workbench.

Model Transformation Engine: The model transformations will not be performed by specialmodel transformation engines at the moment (see section 5.3 and 5.5) because none of theevaluated model transformation engines were mature enough to be used for GaliciaUML. Thetwo components will be hand written in Eclipes plug-ins.

4.7.3 Eclipse

Most of the decisions talk about Eclipse and Eclipse related products and technologies. Theauthor decided to base this work on Eclipse because when monitoring the actual developmentconcerning standard speci�cations and UML tool vendors' behavior interestingly on both �eldsthe development brings the Eclipse platform into account.

Up to know most known UML tool vendors (see section 4.2) made their tools available asEclipse plug-ins. Most of them adopted their stand alone versions and now support althoughversions that can be used embedded into the Eclipse Platform and Java IDE. Although someUML tools rely completely on Eclipse and don't even build a standalone version but participatein the Eclipse Community open source development process.

The Eclipse Community is working on several modeling related projects which make the EclipsePlatform a powerful platform for the development of graphical modeling tools. The most

63

4 ARCHITECTURE

important projects in this context are EclipseUML and EMF. Eclipse will be discussed indepth in chapter 6.

The GaliciaUML tool will be developed as a plug-in for Eclipse. This means that the plug-in willrely on the standard implementations of UML 2.0 and XMI 2.0 provided by the Eclipse Platformand will use the capabilities of EMF. This will hopefully assure that GaliciaUML refactoringswill be available for a wide variety of UML modeling tools and be tightly integrated with themand the rest of the huge amount of functionality o�ered by Eclipse.

4.7.4 Advantages Summary

The decision to use Eclipse and Eclipse related products and technologies for the developmentof GaliciaUML refactoring tool leads to the following bene�ts.

• use Eclipse UML2 (standard compliant)

� UML2 Metamodel Implementation

• use Eclipse EMF and XMI

� XMI Implementation (standard compliant)

• use Eclipse plug-in development framework

� Mature Programming Patterns

� Extension Point Mechanism to tightly integrate with UML Modeling Tools

• use Eclipse Workbench

� Galicia Con�gurations embedded in development framework

• use Eclipse Java IDE

� CVS and Project Management

� Use Eclipse Refactoring

Eclipse is considered as a seminal technology. From this point of view besides all other technicalreasons Eclipse is interesting for the author and the working group at LIRMM. It is importantto understand its architecture and programming models in the context of this work. in thenext chapter Eclipse and its most important concepts and ideas will be presented.

64

Chapter 5

Eclipse

5

5.1 Introduction

The term Eclipse covers many di�erent things simultaneously. From di�erent points of viewEclipse can be described di�erently. It implements di�erent concepts and shows various possi-bilities to exploit it. As an appetizer lets have a look at how Erich Gamma, lead of the EclipseJava Development Tools project describes in [16] what Eclipse is:

Eclipse is a many-splendored thing. Eclipse is a technology, an extensible platform for toolintegration, and a wide range of tools built on that platform. Eclipse is an open source projectthat delivers this technology. And Eclipse is a community that contributes to the open sourceproject and also produces commercial Eclipse-based tools.

After all this possibilities one has the impression Eclipse is nothing and everything at all, thereis no concrete picture of what Eclipse is. The following chapter aims at explaining the conceptsof Eclipse and will help to understand how Eclipse can be so many di�erent things at the sametime.

Introduction Outline: Eclipse is a open-source product, but a huge amount of manpower isput in there. First of all we will try to get the Big Picture of Eclipse and than have an ideahow something like this is organized, who pays for it and why. After talking about what ourrelation to Eclipse is (or could be) the structure of this chapter will be presented.

5.1.1 Eclipse - Big Picture

Why exist all the di�erent statements what Eclipse is? Because Eclipse is a processor. Thisprocessor plays di�erent roles, depending on the programs it processes. Statements aboutEclipse di�er so much because in some cases they describe the processor and its concepts andin the other cases they describe one or more of the di�erent applications running on Eclipseand its features. When talking about the processor Eclipse throughout this work we will talkabout the 'Eclipse Runtime'.

Figure 6.1 describes this concept of a stack of processors, which is one of the basic concepts

65

5 ECLIPSE

Eclipse RuntimeInstance Net Simulating

Processor

Java Development ToolsInstance Net

Plug-in Development

EnvironmentInstance Net

Java Virtual MachineProcessor

Windows

Operating System

Additional Plug-insInstance Net

Plug-in DescriptionsInstance Net Descriptions

Processor Roles of the Processor

Eclipse Description (in Java Source Code)

JVM Description(in C/C++ Source Code)



Hardware ProcessorBits


Eclipse

Figure 5.1: Eclipse: A Processor on the top of a Stack of Processors

in computer science. The concept of a processor playing a role of another processor is appliedseveral times. Figure 6.1 shows the stack of processors on which the Eclipse Runtime is par-ticipating. The operating system runs on its hardware. This means the hardware is playingthe role of an operating system. On the next level, this operating system is playing the roleof a Java Virtual Machine (VM). This concept is applied another time, when the Java VirtualMachine is playing the role of the Eclipse runtime. This Eclipse runtime itself is an processorprocessing plug-in descriptions, which are descriptions of instance nets of complex softwarecomponents.

At each level in the processors stack new concepts are added, enabling di�erent types of softwaredevelopment (e.g. at the lowermost layer assembler development vs. object oriented program-ming in the Java VM). The main goal of the Eclipse processor is to manage the complexity ofcommunicating components which appear in di�erent con�gurations. These concepts will bediscussed in section 6.2. At every step from one level to a higher level in Figure 6.1 only oneexemplary role the processor can play is shown. In this particular case every role the processorsin the stack play is again the role of a processor. This is a special case, it exist many rolesthat serve as end user applications too, e.g. the role 'Microsoft O�ce' the 'Windows OperatingSystem' processor can play as well as the here described role of a Java VM.

At the top of the processor stack the Eclipse Runtime plays roles which are not processors butend user applications. The most famous application based on Eclipse, the Java DevelopmentTools (Java IDE) is shown a possible role the Eclipse Runtime can play.

66

INTRODUCTION 5

Figure 5.2: Eclipse Logo

The di�erent roles the Eclipse Runtime can play �t into two classes, end user applications andtechnologies. End user applications, like the Java IDE, o�er a functionality to the human user,in this case the support of the programming process. Technologies, like the EMF and UML2,do not have a sense on its own, but have been created to be used by other Eclipse applications.They serve mainly as libraries.

Eclipse is interesting for industry because of the high level it is situated in the stack of processors.The additional concepts that are added by Eclipse to the stack of existing processors are theintegration and communication concepts between big software components as well as the opensource organization.

5.1.2 The Eclipse Foundation

Eclipse is an organized open-source project with a solid funding. It is not only a community ofcomputer freaks working on open source projects in their free time but also full time employeesof big companies contribute. This organization describes itself at their homepage1 like this:

'The Eclipse Foundation is a non-pro�t corporation formed to advance the creation, evolution,promotion, and support of the Eclipse Platform and to cultivate both an open source communityand an ecosystem of complementary products, capabilities, and services.'

Industry leaders like Borland, IBM, Rational, Red Hat, Suse, Sybase, Fujitsu, SAP, FraunhoferInstitut and Open Management Group (OMG) form the Eclipse Board of Stewards, which is themain decision making body de�ning the strategic development directions. With the support ofover 50 member companies a full time Eclipse management organization has been establishedto manage a wide variety of projects. Due to the in�uence of its members Eclipse Foundationitself in�uences the development of current standards speci�cations.

Eclipse serves as a research and prototype development activity for new technologies, standard-ization projects and cooperation between di�erent companies.

1http://www.eclipse.org

67

5 ECLIPSE

5.1.3 The Eclipse Community

The Eclipse Community is more than only the Eclipse Foundation. Everybody who deals withEclipse in an arbitrary way is considered member of the Eclipse Community.

When working with Eclipse di�erent roles can be identi�ed [16]. They reach from 'Simple Users'over 'Con�gurers' and 'Extenders' up to 'Committer'. Depending on which role you play theevery day work with Eclipse will be di�erent. The roles mainly di�er in the commitment theygive into and the reward they get from the Eclipse community. 'Simple Users' are programmersusing the Eclipse Java IDE in their every day programming work. They normally do not needa lot of contact to the Eclipse Community and the documentation provided within Eclipseis su�cient for them to do their work properly. When starting to contribute to Eclipse byextending it more in depth knowledge about the Eclipse Runtime and the di�erent Eclipseprojects and technologies is necessary. This additional information is available on the Eclipsewebsite on the project pages, in the 'Eclipse Corner'[11] in di�erent 'Eclipse Corner Articles'and particularly in newsgroups. Real books on Eclipse are [26] for users of the Eclipse JavaIDE and [16] and [5] for plug-in developers. For special information on EMF [34] and [3].

Newsgroups: A lot of di�erent subjects concerning Eclipse (from internal algorithmic dis-cussions over website design to Eclipse related job o�ers) are discussed in newsgroups (63newsgroups at the time of writing). They can be understood as the most important way ofpublic knowledge interchange about Eclipse. Everybody has access to the newsgroups. Nor-mally the newsgroups are well organized, e.g. the newsgroups for EMF and UML22 have eacha full time newsgroup manager who provides average response times of about have an hourwith often high quality answers and in depth discussions. The average number of messagesper day is about thirty to forty. Even if these newsgroups are the best managed newsgroupsthe author knows, only very detailed questions will result in a satisfactory response. A 'BigPicture' of Eclipse which is important for every Eclipse beginner is hard to obtain by readingthe newsgroups.

5.1.4 Outline

Depending on whether the processor (Eclipse Runtime) or one of its roles is meant with theword 'Eclipse' the statements about Eclipse are di�erent. All these di�erent views on Eclipseare important for the undertaking to develop a Galicia Multi FCA based refactoring tool onEclipse. Therefore �rst of all we will learn about the 'Eclipse Runtime' and its plug-in concept(the processor, bottom of Figure 6.3) on which everything is based. This is the core of allEclipse related technologies and is the most important part of this chapter. After this we willtalk about Eclipse as a development environment for Java (for which Eclipse is very well known)and the development environment for plug-ins and their relation to the plug-in concept (twoimportant roles of the processor at the top of Figure 6.3). The most important technologies forour task built on Eclipse are the Eclipse Modeling Framework and Eclipse UML2 (also roles).At the end of this chapter we will talk about how we can integrate non Eclipse applicationswith Eclipse.

2used extensively throughout this work

68

ECLIPSE RUNTIME 5

Eclipse RuntimeInstance Net Simulating

Processor

Eclipse Applications

Java Development ToolsInstance Net

Plug-in Development

EnvironmentInstance Net

Plug-in DescriptionsInstance Net Descriptions


Eclipse Modeling

Framework (EMF)

UML2

Figure 5.3: Outline: di�erent parts of Eclipse in this chapter

Eclipse Platform

Eclipse

Runtime

Create

Plug-in

Instance

Hard Disk

Plug-in N

Description

Plug-in A

Description

Plug-in B

Description

Scan Hard Disk for

Plug-in Descriptions

Plug-in A

Plug-in N

Plug-in B

Plug-in Registry

(in-memory)register

Scan Hard Disk for

Plug-in Description

Plug in

Activation

Loop

Read Plug-in

Description

Register Plug-in

in Plug-in RegistryPlug-in Constructor

Startup Code

Invoke Autostart Plugins

Event Handling

Exit Code

Event

Loop

Eclipse Runtime

Event Dipatching

Shut Down

Event Loop

Plug-in A

Static Structure Dynamic Structure

extension

dependency

Figure 5.4: Eclipse Platform Runtime - static and dynamic structure

5.2 Eclipse Runtime

This section will focus on the Eclipse Runtime. The Eclipse Runtime is the kernel of the EclipsePlatform3. The Eclipse Platform is a program written in Java running on Windows, Linux andMac desktop computers in the Java Virtual Machine which can be started by the user. Whenstarting the Eclipse Platform, its small kernel called Eclipse Runtime is responsible for startingall registered plug-ins. Figure 6.4 describes this static structure on the left side. The maincomponents of the Eclipse Platform are the Eclipse Runtime and the plug-ins. The behaviorof the plug-ins (the source code) is described on the hard disk in so called plug-in descriptions.The plug-in registry manages the inter plug-in relationships which can be dependencies orextensions. Each of these terms will be explained in short now and then be discussed in detailin the following sections.

3The terms Eclipse Runtime and Eclipse Platform are often used synonymously, but when talking aboutinternal Eclipse concepts in these chapter it is important to understand the di�erence

69

5 ECLIPSE

1) Eclipse Runtime: The Eclipse Runtime is responsible for �nding, starting and stoppingplug-ins as well as organizing the plug-in relationships in the plug-in registry. The conceptsof building extensible platforms with plug-ins and inter plug-in communication is a huge andcomplicated �eld. Eclipse is based on the OSGi (Open Services Gateway initiative) standardwhich covers the problems of this approach. The Eclipse Runtime will be covered in section6.2.1.

2) Eclipse Plug-ins: Plug-ins are the main unit of re�ection in Eclipse. What is calledprogram when talking about other processors is a plug-in for Eclipse. The behavior of eachplug-in is in Java code, yet the dependencies and services of a plug-in are declared in a specialXML �le named plugin.xml. This structure facilitates lazy loading (see section 6.2.2.2) ofplug-in code on an as-needed basis, thus reducing both the startup time and the memoryfootprint of Eclipse. On startup, the plug-in loader scans the plugin.xml �le for each plug-inand builds a structure containing this information (see right side on Figure 6.4). Autostartplug-ins are activated immediately, the rest of the plug-ins on demand. The plug-in registrydoes take up some memory, but it allows the loader to �nd a required plug-in much morequickly. The Eclipse plug-ins will be covered in section 6.2.2.

3) Inter Plug-in Relationships: One of the most interesting concepts of Eclipse and a majorreason for its success are the di�erent inter plug-in relationships. In section 6.2.3 the basics ofthe two concepts, extension and dependency, will be explained focusing on the di�erent rolesplug-ins can play in the relationships.

5.2.1 Eclipse Runtime OSGi Implementation

The OSGi (Open Services Gateway initiative)[24] de�nes an application lifecycle model andservice registry in form of di�erent speci�cations which all Eclipse components implement.It is a standardized, component oriented computing environment for networked devices[23].Software components can be installed, updated, or removed on the �y without having to disruptthe operation of the device.

This section presents the general architectural levels the OSGi standard describes and thenoutlines how this is implemented in the Eclipse Platform.

5.2.1.1 OSGi Architecture

The OSGi architecture consists of four layers with dependency relations from the top to thebottom like shown in Figure 6.5. The lowest layer is the Execution Environment. It canbe any Java execution environment ful�lling the minimum requirements de�ned by OSGi tobe useful for OSGi Bundles4. The Modules Layer de�nes the class loading policies. It isbased on top of Java but adds modularization via private classes for a module as well ascontrolled linking between modules which overcomes the common problems of the Java importmechanism.[2] In object oriented technologies always the 'Class' or 'Object' was the unit of

4The terms bundle and plug-in are used equivalent in Eclipse and throughout this chapter.

70

ECLIPSE RUNTIME 5

Execution Environment (normal Java environment)

Modules

* class loading model

Life Cycle

Service Registry Security

Applications /

Bundles

Services

Figure 5.5: OSGi Layers (graphic from http://www.osgi.org)

re�ection and abstraction. OSGi adds bundles as a bigger component with the ability to de�neinterfaces. The Life Cycle layer adds concepts to bundles so they can be dynamically installed,started, stopped, updated and uninstalled. This layer introduces dynamics that are normallynot part of an application but are important when di�rent applications should run togetherin an instance net. The Service Registry provides a cooperation model for bundles thattakes the dynamics into account. The service registry provides a comprehensive model to shareobjects between bundles. A number of events are de�ned to handle the coming and going ofservices. Security is based on the Java 2 security model and OSGi extends this model byallowing private classes and dynamic management of permissions. [23]

5.2.1.2 Implementation in Eclipse

These OSGi layers are implemented in the Eclipse Runtime which is the core runtime engine thatstarts the platform base and dynamically discovers, starts and manages the plug-ins. Figure 6.6shows the inner structure of the Eclipse Runtime and the mapping between Eclipse componentsand the OSGi names for these components. Plug-ins are started, managed and stopped by thelifecycle manager. Discovering and registering the plug-ins on disk (called modules) is done bythe service registry manager. It manages the service registry.

In the current version of Eclipse the OSGi standard is not fully implemented. The most im-portant di�erence is that plug-ins can not be unloaded. This leads to a growing memoryconsumption of Eclipse until all plug-ins are loaded. The Equinox project5 works on the ques-tions of adopting the runtime to the OSGi standard and can be consulted for more informationon that. Major problems in standardizing the Eclipse Runtime core are compatibility issueswith versions prior to Eclipse 3.0.

5http://www.eclipse.org/equinox

71

5 ECLIPSE

Eclipse Platform

OSGi FrameworkEclipse Runtime

Create

Plug-in

Instance

Hard DiskModules

Plug-in Description

Scan Hard Disk for


Bundel APlug-in A

Bundle NPlug-in N

Bundle BPlug-in B

Service RegistryPlug-in Registry

register

Service

Registry

Manager

Lifecycle

Manager

Security

Manager

Check

dependencies

Rregister

R

Permission

Request

R

Permission

Request

Figure 5.6: Eclipse Runtime is OSGi Framework Implementation (big OSGi names, small Eclipsenames)

5.2.2 The Eclipse Plug-in Model

The concept of plug-in is the most important unit of re�ection in Eclipse. The Eclipse processorhas not been designed to process a single plug-in but a set of communicating plug-in instances.Theory on instance nets are described in [42] (chapter 3.2.4.5 Instanznetzsimulierende Abwick-ler). This is one of the main di�erences to other processors. Plug-ins should never be consideredto run alone, but always in the context of at least the Eclipse Workbench and the central in-stance Eclipse Runtime (see Figure 6.7). The Eclipse Workbench is building up a central userinterface in which all the other plug-ins can integrate.

A plug-in in Eclipse is a component that provides a certain type of service within the contextof the Eclipse. A component is something that may be con�gured into a system at systemdeployment time. The Eclipse Runtime provides an infrastructure to support the activationand operation of a set of plug-ins working together. Historically Eclipse was build to provide aseamless environment for development activities but at the moment this is changing to trans-form Eclipse to a platform for everything6). Within a running Eclipse instance, a plug-in isembodied in an instance of some plug-in runtime class, or plug-in class, for short. The plug-in class provides con�guration and management support for the plug-in instance. A plug-inclass in Eclipse must extend org.eclipse.core.runtime.Plugin, which is an abstract classthat provides generic facilities for managing plug-ins de�ned in the OSGi Lifecycle part. Mostimportant methods are start() and stop().

Up from now several examples will be presented when discussing the di�erent concepts ofthe plug-in mechanism. The declarative de�nition of plug-ins and their relations in Eclipse issituated in a �le called plug-in.xml which exists for each plug-in. When talking about plug-

6To allow Eclipse as the basis for arbitrary (also non development environment) applications is the objectiveof the Eclipse Rich Client Platform project (http://www.eclipse.org/rcp)

72

ECLIPSE RUNTIME 5

eclipse

folder

Eclipse Platform

Activated Plug-ins

Eclipse

Runtime

Create

Plug-in

Instance

eclipse\plugins

Workbench Plug-in

Plug-in Registry

register

User Interface/WorkbenchOrg.eclipse.ui.workbench

Plug-in code*.jar-files

Manifestplug-in.xml

Resources

Load Resources

Plug-in 2

Plug-in code

Manifest

Resources

Plug-in N

Plug-in code

Manifest

Resources

Plug-in Nactivated

Plug-in 2activated

Load Resources Load Resources

Install.ini

Plug-in Descriptor

Plug-in Descriptor

User Interface

ExtensionUser Interface

Extension

‘Platform API’

R

Plug-in Descriptor

Figure 5.7: Plug-in in the Eclipse Environment

in relationships often the example of the plug-in fr.lirmm.galiciauml and its relation to theorg.eclipse.ui.workbench plug-in have been chosen because this relatinship contains the majorcontext and is important in the regarding the GaliciaUML tool.

5.2.2.1 Plug-in Folder and Service Registry

Figure 6.7 shows the di�erent places where information about plug-ins resides in Eclipse. AnEclipse installation includes a plug-ins folder where individual plug-ins are deployed. Eachplug-in is installed in its own folder under the ECLIPSE-HOME/plugins folder. A plug-in isdescribed in an XML manifest �le, called plugin.xml, residing in the plug-in's folder. Themanifest �le tells the Eclipse runtime what it needs to know to activate the plug-in.

The parsed contents of plug-in manifest �les are stored in the plug-in registry. They are madeavailable programmatically through the Platform API or plug-in registry API. The Eclipseruntime instantiates an instance of each plug-in by using the plug-in registry API. The plug-inregistry API is also used by provider-supplied plug-in code to obtain information about plug-ins.

73

5 ECLIPSE

<?xml version="1.0" encoding="UTF-8"?>

<plugin

name="JUnit Testing Framework"

id="org.junit"

version="3.7"

provider-name="Eclipse.org">

<runtime>

<library name="junit.jar">

<export name="*"/>

</library>

</runtime>

</plugin>

Figure 5.8: Simple Manifest �le (plugin.xml)

Figure 6.7 shows among others the Workbench plug-in (orange colored). The plug-in code,resources and manifest are on the hard disk. The parsed contents of the manifest �le areavailable via the Platform API in the plug-in registry. If the plug-in is activated like in the caseof Figure 6.7 the plug-in instance is part of the Eclipse Platform.

Manifest: Figure 6.8 shows how a minimal plug-in manifest �le looks like. It is the manifestof the JUnit plug-in, a testing framework. The Eclipse Platform plug-in manifest speci�cationde�nes the XML elements and attributes used in de�ning plug-ins7.

I am not going to focus on the contents of the plug-in manifest �le at this time, except to notethat each plug-in has a unique identi�er (XML attribute id). The unique identi�er is used torefer to a plug-in within the manifest �les of other, related, plug-ins. The unique identi�er mayalso be used within provider-supplied plug-in code to access the plug-in's running instance.

5.2.2.2 Deployment and Activation

Deploying a plug-in in an Eclipse installation involves copying the resources that constitutethe plug-in (the manifest �le, jar �les, and other resources see Figure 6.7) into an individualfolder for the plug-in, under the installation's /plugins directory. Such a plug-in can then beactivated by the Eclipse runtime when it is required to perform some function. Activating aplug-in means loading its runtime class and instantiating and initializing its instance.

The main function of a plug-in class is to do special processing during plug-in activation anddeactivation, e.g., to allocate and release resources. For simple plug-ins, like the JUnit plug-inin Figure 6.8, no speci�c activation or deactivation processing is required, and therefore nospeci�c plug-in class needs to be provided by the plug-in designer. In that case, the Eclipseruntime automatically provides a default plug-in class for the plug-in instance.

When the plug-in needs to do something speci�c to activate or deactivate itself, the plug-in

7This speci�cation is also available in the Eclipse platform help documentation under Platform Plug-InDeveloper Guide/Other reference information/Plug-in manifest.

74

ECLIPSE RUNTIME 5

Extender Role / Extender Plug-in

Extension Provider Role / Host Plug-in

Dependent Role

Prerequesite Role

Plugin

Dependency Extension

Figure 5.9: Relationship ERD

designer subclasses org.eclipse.core.runtime.Plugin, provides overrides for the activationand deactivation methods of the class, respectively called startup and shutdown, and includesthe fully-quali�ed name of this speci�c plug-in subclass as the value of the attribute class8 inthe corresponding plug-in manifest �le.

Eclipse includes a plug-in management kernel, known as the Eclipse Runtime, and certain coreplug-ins that are present in every Eclipse installation. The identities of these core plug-ins arehard-coded into the Eclipse platform, and the platform knows how to activate these plug-ins ineach running instance of Eclipse (e.g. the Workbench plug-in). Non-core plug-ins, on the otherhand, are activated when required by other plug-ins, as described below.

In the Eclipse model, a plug-in may be related to another plug-in by one of two relationships(see Figure 6.9).

• Dependency: The roles in this relationship are dependent plug-in and prerequisite plug-in. A prerequisite plug-in supports the functions of a dependent plug-in.

• Extension: The roles in this relationship are host plug-in and extender plug-in. Anextender plug-in extends the functions of a host plug-in.

These relationships are speci�ed declaratively in plug-in manifest �les through the XML ele-ments requires and extension (the details of which appear in later sections).

A non-core plug-in that has been deployed in an Eclipse installation may be activated in arunning instance of Eclipse if it is transitively related to a core Eclipse plug-in by the dependencyand the extension relations. Such a plug-in will be activated when its functions are requiredto support and/or to extend the functions of another plug-in. A plug-in that is deployed butunreachable from any core plug-in via the dependency and extension relations will never be

8Attribute: class = 'org.junit.JUnitPlugin'

75

5 ECLIPSE


<plugin

id="fr.lirmm.galiciauml.ui"

name="GaliciaUML User Interface"

version="1.0.0">

<runtime>

<library name="fr.lirmm.galiciauml.ui.jar"/>

</runtime>

<requires>

<import plugin="org.eclipse.ui"/>

</requires>

</plugin>

Figure 5.10: Specifying Plug-in Dependencies (plugin.xml)

activated. Of course, even a reachable plug-in may remain unactivated in a running instancefor some time (or for the lifetime of the instance), if no user action or other triggering eventinvokes its use. If a plug-in has been activated it remains active until the shutdown of Eclipse.

5.2.2.3 Dependency

A plug-in is dependent on other plug-ins for its functions. The dependency is speci�ed viaa requires element in the plug-in manifest �le. This dependency is similar to the importstatement in normal Java code. It enables the possibility to use the API of the prerequisiteplug-in. The di�erence to the Java import is, that only API can be used, that has been explicitlyexported for use by other plug-ins. Figure 6.10 is an example of dependency speci�cation in amanifest �le. In this example, the sample plug-in fr.lirmm.galiciauml.ui is declared to bedependent on (i.e., to make use of) the base Eclipse UI plug-in org.eclipse.ui.

Dependency as de�ned in the plug-in manifest �le is both a runtime and a compile-time direc-tive. At runtime, Eclipse has to make sure that a prerequisite plug-in can be made available toa dependent plug-in when the dependent plug-in is activated. At compile time, Eclipse needsto load the .jar �les or the prerequisite plug-ins into the classpath.

5.2.2.4 Extension

The relationship of extension is a lot more complicated than the simple dependency. Here ashort introduction will be given before all details will be discussed in section 6.2.3.

When the functions of a plug-in are to be made directly available to the user, one or more userinterface elements have to be added to the base Eclipse workbench. For example, to make theGaliciaUML plug-in available to the user, menu items must be added to the workbench userinterface.

The process of adding some processing element or elements to a plug-in is known as an extension.This process is not restricted to UI elements. Any plug-in may allow other plug-ins to extend

76

ECLIPSE RUNTIME 5

it by adding processing elements. An extension is de�ned by an extender plug-in and causes ahost plug-in (see Figure 6.11) to modify its behavior. Typically, this modi�cation of behaviorincludes the addition of processing elements to the host plug-in (e.g., the addition of new menuitems to the Eclipse workbench), and the customization of the behavior of these additionalelements by services provided by the extender plug-in (e.g., the customization of new menuitems by speci�c menu event handlers).

In simple cases, a single act of extension adds a single callback object to the environment,through which the host and extender plug-ins communicate. The callback object is di�erentfrom the host and extender plug-in objects. Unlike the plug-in objects, which are componentsthat are automatically instantiated and managed by the Eclipse platform, a callback object isa plain old Java object that is instantiated and managed by the code supplied by the extensionprovider.

5.2.3 The Eclipse Extension Mechanism

The Eclipse Extension Mechanism allows di�erent plug-ins to cooperate in a service orientedway. Because this is one of the most important concepts the whole section is dedicated toexplain this extension mechanism and give a detailed example. Before talking about thesedetails the advantages of this Eclipse concept will be discussed.

5.2.3.1 Advantages of the Eclipse Extension Mechanism

Apart from Eclipse many Java application server models are available, such as J2EE, JMXand others. Except for the OSGi Service Platform implemented in Eclipse, all these modelsprovide a closed container in which the application runs in isolation. [23] Applications can uselibraries from the runtime environment but they are not able to provide functionality to otherapplications.

In contrast, the Eclipse concept allows plug-ins to contribute code as well as services to theenvironment. Contributing code is important because it allows libraries with shared function-ality to be downloaded and used. In the closed container model, each application must includeall its code, even if it is already present elsewhere in the environment. With the sharing oflibraries, applications can share common code via dependencies, making applications smaller.

The OSGi Service Platform also provides a lightweight publish, �nd, and bind service modelfor services inside the Java VM with the OSGi service registry [23]. This supports looselycoupled application designs with service-oriented architectures. In the OSGi speci�cations, theword service has a very precise meaning, indicating a mechanism that allows one bundle toprovide functionality to other bundles. An OSGi service is an object from one bundle thatis made available to other bundles. The service extension mechanism distinguishes betweenparameterization and callback extension.

77

5 ECLIPSE

5.2.3.2 Parameterization and Callback Extension

Normally both types of extensions will be used together, but it is important to understand thedi�erence between the two mechanisms Parametrization and Callback Extension. This conceptwill be discussed throughout the rest of this section and with all the details in the sections6.2.3.6 and 6.2.3.7.

Parameterization: The extension model is quite general, and does not necessarily require thatan extender plug-in provides custom callback objects. It is possible, for example, that the kindof behavior modi�cation required of a host plug-in can be provided entirely by objects whoseclasses are part of the host plug-in's implementation. These classes are known at compile-time,so that an extension declaration serves simply to parameterize instances of such built-in classes.

Callback Extension: Similarly, the extension model does not necessarily require that thehost plug-in directly exposes aspects of each of its extensions in its interface as it is necessaryin the Parametrization case. It may be su�cient to provide a slot for callback interfaces. Forexample, an extension may ask that an extender plug-in be noti�ed of certain events known tooccur in the host plug-in independently of the extender plug-in, without any changes visible inthe host plug-in's interface.

5.2.3.3 Extension Points

Extension points de�ne how a plug-in may be extended. A plug-in may allow itself to beaugmented by di�erent kinds of extensions. For example, the workbench UI allows both itsmenus and its editors to be extended. In each case, the extension must conform to a uniqueset of con�guration and behavioral requirements. Therefore, an extensible plug-in providesdi�erent types of slots that extensions can plug into. These slot types are called extensionpoints. An extension-point allows any number of extensions to be plugged into it.

Extension and extension-point are standard Eclipse plug-in terminology. Host plug-in, extenderplug-in, and callback object are terms used in this chapter to describe the di�erent roles ofobjects in an extension. (see Figure 6.11)

Figure 6.12 illustrates the relationships between the participants of a particular extension. TheEclipse Workbench is extended by the menu items of an arbitrary Eclipse plug-in. In thisextension, the host plug-in is the Eclipse Workbench user interface, org.eclipse.ui, whosemenus can be extended via an extension-point known as actionSets. The extender plug-in isan arbitrary Eclipse plug-in. In order to make its functions available to the user, the extenderplug-in uses the actionSets extension-point to extend the workbench UI plug-in by speci�cextender plug-in-related menu items. The extension is de�ned by the extender plug-in. And inthis case, the single extension augments the workbench UI by two menu items ('Menu 1' and'Button 1') which are added via parameterization. This means the 'Extension Processor' readsthe parameters and instantiates the two classes 'Menu' and 'Button' with these parameters.The action that should be performed in case of a pressed button can not be speci�ed byparameterization, but it needs to be implemented by the extender plug-in in a callback class.

78

ECLIPSE RUNTIME 5

single act of

Extension

Extension Point

Host plugin.xml

Extension

Extender plugin.xml

Generic

Callback

Interface

Callback Class

implements

references

references

has

has

Extension Point Schema

[extensionpoint].exsd

knows

defines

Extender Role

/ Extender Plug-in

Extension Provider

Role / Host Plug-in

Plugin

references

Figure 5.11: Extension Relationship ERD

The callback class is registered via its identi�er in the extension point.

Also shown in Figure 6.12 are the implementation of the extension's callback objects: thatis, the classes of the Extender plug-in's menu handlers (Action Implementation). As we willsee shortly, callback classes are typically identi�ed by name in the declarative speci�cation ofeach extension. This extension's menu speci�cation declares its custom callback class to be an'Action' via the 'Action' interface it references. (The references can not be seen in the staticstructure of Figure 6.12 but in the ERD in Figure 6.11.)

Participants of an Extension: The next section provides a detailed example of how extension-points and extensions are de�ned in the manifest �les. We look more closely at the various rolesplayed by the objects participating in an extension which have to be de�ned when implementingan extension. Figure 6.11 are two plug-in roles, host and extender. The host plug-in contains ageneric callback interfaces and parametrizable service classes de�ned by each extension-point.The host plug-in needs to de�ne the Extension Point Schema and the Extension Point. TheExtender plug-in contains the implementation of the generic callback interfaces (the speci�ccallback implementations). It de�nes and parametrizes the extension point it extends anddeclares its speci�c callback classes.

5.2.3.4 The Host Plug-in Role

The host role is the more complicated role in the extension. In the context of a particularextension, a plug-in that stands in the host role provides the extension-point and is extended.In addition to providing services, such a plug-in also acts as the coordinator and controller ofa number of extensions ('Extension Processor' and 'Callback Handler' in Figure 6.12).

Within the host plug-in's manifest �le, an extension-point is declared in an extension-point

XML element. Figure 6.13 is an example of such an element, taken from the base Eclipse

79

5 ECLIPSE

Eclipse Platform

Workbench UI (Host Plugin)

Extension PointactionSet

Parameter

Callback

Slots

ABC Plug-in

(Extender Plug-in)

Extension

Processor

Menu 1 Button 1

Parametrize Extension

Menu 1 with Button 1

RUse ABC Plug-in

invoke

Extension

Point

SchemaactionSets.exsd

Parametrizable

Service Classes

Menu Class

Button Class

Generic

Callback Interfaces

Action Interface

load

Callback

Handler

Rest of Plug-in

R

Declare specific

callback class

Specific

Callback

Implementation

Action

Implementation

R

Read for validation

of Extension

register

Callback

Figure 5.12: Extension Mechanism


<plugin

id="org.eclipse.ui"

name="Eclipse UI"

version="3.1.0"

provider-name="Eclipse.org"

class="org.eclipse.ui.internal.UIPlugin">

<extension-point id="actionSets" name="Action Sets" schema="schema/actionSets.exsd"/>



</plugin>

Figure 5.13: Declaring an Extension Point

80

ECLIPSE RUNTIME 5

Workbench UI plug-in, org.eclipse.ui9. The extension-point speci�cation de�nes a uniqueidenti�er for the extension-point within this host plug-in (id=actionSet). To identify anextension-point uniquely in global context, the extension-point identi�er is prepended with theunique identi�er of the host plug-in to form a fully-quali�ed identi�er for the extension-point.Thus, the fully-quali�ed identi�er of the actionSets extension-point of the Eclipse UI plug-inis org.eclipse.ui.actionSets. Plug-ins which extend an extension-point refer to it by itsfully-quali�ed identi�er.

The extension-point speci�cation also declares an XML schema for the extensions of thisextension-point (schema=schema/actionSets.exsd). It provides the syntax for declaring thecontents of the extension. In this case the contents are menus, menu items, and buttons to beadded to the workbench UI. We'll have more to say about the structure and contents of sucha schema when discussing Figure 6.15 in section 6.2.3.8.

5.2.3.5 The Extender Plug-in Role

In the context of a particular extension ('single act of extension' in Figure 6.11), a plug-inthat stands in the extender role de�nes the extension ('extension' in Figure 6.11), typicallymaking certain aspects of itself available to a host plug-in through the extension (callback). Inaddition it causes the host plug-in to add certain processing elements to its environment (para-meterization). An extension is declared by using an extension XML element in the extenderplug-in's manifest �le. Figure 6.14 shows an example of an extender plug-in, taken from thefr.lirmm.galiciauml.ui plug-in manifest �le, that extends the actionSets extension-pointof Figure 6.13, by adding menu items. It adds a button to the Galicia Menu labeled 'RefactorUML Model'.

5.2.3.6 The Callback Mechanism

In the context of a particular extension, an object that stands in a callback role is a plain oldJava object (not a plug-in) that is called by the host plug-in when certain events speci�ed inthe corresponding extension-point contract are recognized by the host plug-in (in our case thebutton is pressed). The interface for callback objects is provided by the host plug-in, and shouldbe documented in the documentation of the extension-point being extended. The implementa-tion of callback objects is a custom class speci�c to the particular extension, and is furnishedby the provider of the extender plug-in. Because the implementation of the callback objectin the extender references the callback interface, which is typically packaged with the host,an extender plug-in typically also depends on the host plug-in. This means in mostcases of an Extension relationship between two plug-ins there is additionally a Dependencyrelationship.

9The documentation for this extension-point is provided in a reference page (and is also available inthe Eclipse platform on-line help at Platform Plugin Developer Guide/Reference/Extension Points Refer-ence/Workbench/org.eclipse.ui.actionSets). The documentation indicates, among other things, that thisextension-point provides a plug-in slot for sets of menus, menu items, and buttons to be added to the baseEclipse workbench.

81

5 ECLIPSE

<plugin

id="fr.lirmm.galiciauml.ui"

name="GaliciaUML User Interface"

version="1.0.0"

provider-name="galiciauml.lirmm.fr"

class="fr.lirmm.galiciauml.ui.GaliciaUMLPlugin">





<extension

point="org.eclipse.ui.actionSets">

<actionSet

label="UML Refactoring"

visible="true"

id="org.eclipse.help.internal.ui.GaiciaUMLActionSet">

<action

label="&Refactor UML Model"

icon="icons/view.gif"

helpContextId="fr.lirmm.galiciauml.ui.RefactorContentsMenu"

tooltip="Refactor UML Model"

class="fr.lirmm.galiciauml.ui.actions.RefactorAction"

menubarPath="galiciaMenu/galiciaGroup"

id="fr.lirmm.galiciauml.ui.RefactorAction">

</action>



<action



</action>

</actionSet>

</extension>



</plugin>

Figure 5.14: Declaring an Extension

82

ECLIPSE RUNTIME 5

Each callback object �lls a certain speci�c role within an extension. I will refer to these speci�croles simply as callback roles. In the XML de�nition of an extension, callback roles are de�nedby child or descendent XML elements. The actionSets extension-point, for example, de�nesa descendent callback role known as action. Multiple callback objects may stand in this rolewithin an actionSets extension, each servicing a particular workbench menu item or button.

When a custom implementation of a callback object is required, the XML schema of the corre-sponding extension-point typically includes an attribute for specifying the fully-quali�ed nameof the custom callback implementation class. For the GaliciaUML UI plug-in, the name of theXML attribute designating an action class is 'class=fr.lirmm.galiciauml.RefactorAction'(see Figure 6.14).

But while the extender plug-in de�nes the required speci�c callback objects, and declares theircustom implementation classes, the callback objects only will be created as a result of spe-ci�c action by the host plug-in (and usually only when they are required for the �rst timeto perform some action on behalf of the extension). For example, in Figure 6.14 , the actioncallback class for the workbench 'UML Refactoring' menu is speci�ed by the extender plug-infr.lirmm.galiciauml.ui to be RefactorAction (package fr.lirmm.galiciauml.ui.actions).But the associated callback instance is created by the host plug-in org.eclipse.ui. In thiscase, the callback instance is created the �rst time the user clicks 'UML Refactoring->RefactorUML Model' menu item.

As extension designers for an extender plug-in, we need to know about the callback rolesof an extension, and supply concrete callback objects for these roles. The roles are de�nedas particular elements in the XML schema associated with the extension-point (see section6.2.3.8), and are described in the documentation of the XML schema, which must include theinterfaces expected of callback objects �lling each role.

For example, the actionSets reference page introduced earlier speci�es the callback interfacefor menu item actions to be org.eclipse.ui.IWorkbenchWindowActionDelegate. So themenu action handlers of the GaliciaUML system implement this interface. In this interface, themethod whose implementation actually performs the menu action is declared as:

public void run(org.eclipse.jface.action.IAction action);

Therefore, when a new service is to be made accessible through the main workbench menu, theservice's plug-in provides an implementation of IWorkbenchWindowActionDelegate in whichthe run method invokes the service. And the fully-quali�ed name of the implementation classis added to the service's plug-in manifest �le as the callback class of the service's menu.

5.2.3.7 Parameterization in form of Non-Speci�c Service Objects

Not all XML elements used in de�ning an extension correspond to custom callback roles. Someelements may be purely descriptive, supplying, for example, certain parameters to the host plug-in to shape corresponding UI elements. In our example (Figure 6.14, the actionSet element

83

5 ECLIPSE

itself (independently of its child elements) does not de�ne a custom callback object. But suchan element does cause an internal object to come into existence within the org.eclipse.ui

plug-in to represent the actionSet.

The actionSets extension-point allows the declaration of new top-level workbench menusthrough an actionSet menu element. But the action associated with a top-level menu isgeneric: 'expose the list of lower-level menu items'. Therefore, there is no need for an extender-speci�c callback object to be associated with a top-level workbench menu. And the workbenchtop-level menus are represented by internal workbench UI objects.

As users of extension-points, we need not be concerned with these non-speci�c internal objectssupplied by the host plug-in. But as designers of host plug-ins, we see that we have the�exibility to design complex extension structures. Parts of them may be exposed as callbacksto be provided by extensions, and other parts would be generic, built-in to the host plug-incode, and possibly parameterizable through corresponding XML attributes of extensions.

5.2.3.8 Extension-Point Schemas

The Extension Point Schema contains all the logic of the extension mechanism an serves asa single place were all information needed by extender plug-in runs together. We will shortlyresume which con�guration elements are used and point out the role of the Extension PointSchema.

A particular extension is de�ned by an XML con�guration element in an extender plug-in. Theelement provides the information required to instantiate and initialize the required callbackobjects for that extension, as well as the information required to customize the interface andbehavior of the host plug-in. When a host plug-in designer creates an extension-point, inaddition to declaring the extension-point in its manifest �le, the designer is also responsible forde�ning the con�guration syntax for extensions to that extension-point. This syntax is de�nedas an XML schema and stored in a �le with a .exsd extension, e.g., actionSets.exsd. Theschema de�nition then becomes part of the documentation of the host plug-in. (The EclipsePDE described in section 6.3.3 includes an XML schema editor and a corresponding formatterfor this purpose.) The extension-point schema lets extender plug-in designers know how toparameterize their extensions.10

Figure 6.15 shows an abbreviated version of actionSets.exsd. The schema de�nes an actionSetsextension as an element that includes some attributes and a sequence of actionSet's. AnactionSet is an element that includes some attributes and a sequence of menus and actions.In the full version of this �le, each attribute is annotated with a human-readable documentationelement. The documentation elements of extension-point schemas are used to generate HTMLreference pages for extension-points, similarly to the way in which Java API reference pages aregenerated via JavaDoc. Such a reference page is made available as part of the documentationof the host plug-in, and is integrated with the workbench's help system.

10Eclipse also provides an extension con�guration editor that is driven by the XML schema of an extension-point being extended.

84

ECLIPSE RUNTIME 5

<schema targetNamespace="org.eclipse.ui">

<element name="extension">

<complexType>

<sequence>

<element ref="actionSet" minOccurs="1" maxOccurs="unbounded"/>

</sequence>

<attribute name="point" type="string" use="required"> </attribute>

<attribute name="id" type="string"> </attribute>

<attribute name="name" type="string"> </attribute>

</complexType>

</element>

<element name="actionSet">

<complexType>

<sequence>

<element ref="menu" minOccurs="0" maxOccurs="unbounded"/>

<element ref="action" minOccurs="0" maxOccurs="unbounded"/>

</sequence>

<attribute name="id" type="string" use="required"> </attribute>

<attribute name="label" type="string" use="required"> </attribute>

<attribute name="visible" type="boolean"> </attribute>

<attribute name="description" type="string"> </attribute>

</complexType>

</element>

<element name="action">

<complexType>

<choice>

<element ref="selection" minOccurs="0" maxOccurs="unbounded"/>

<element ref="enablement" minOccurs="0" maxOccurs="1"/>

</choice>

<attribute name="id" type="string" use="required"> </attribute>

<attribute name="label" type="string" use="required"> </attribute>

<attribute name="toolbarPath" type="string">

<attribute name="icon" type="string"> </attribute>

<attribute name="tooltip" type="string"> </attribute>

<attribute name="class" type="string"> </attribute>

</complexType>

</element>

</schema>

Figure 5.15: Extension Point Schema De�nition (.exsd File)

85

5 ECLIPSE

The reference page supports the two tasks that must be performed to plug new functionalityinto an extension-point.

• Parametrization: Con�guration of an extension in the extender plug-in's manifest �le.The reference page speci�es the XML con�guration syntax required for the extension.

• Callback Extension: Provision of custom implementations for the extension-point'scallback objects.

The reference page includes an API section for documenting the callback interfaces expectedby the host plug-in for each callback role.

Extension Members: What goes into an extension-point schema de�nition is up to thedesigner of the host plug-in. The extension XML in the Eclipse Platform Plug-in ManifestSpeci�cation is de�ned as an XML ANY, meaning that it is arbitrary. In fact, an XMLextension speci�cation is always a sequence of elements. I will refer to an item within thissequence of elements as an extension member. An actionSets extension, for example, is asequence of actionSet members.

In XML, the number of elements of each type within a sequence may be bounded by using theminOccurs and the maxOccurs element de�nition attributes. This usage is illustrated in theactionSets schema (Figure 6.15, where an actionSets extension is speci�ed to contain at leastone, but an otherwise unrestricted number of actionSet elements.

5.2.3.9 Summary: Relationships between Plug-ins and Extension Objects

The act of extension is quite a general concept in Eclipse, and to understand its full generality,it is useful to summarize the types of relationships that may exist between plug-in objects,extension-points, and callback objects shown in Figure 6.11.

1. Multiple extension-points may exist in a host plug-in.

2. A plug-in may act both as a host plug-in, exposing some extension-points, and as anextender plug-in, extending some plug-ins.

3. Multiple plug-ins may extend a given extension-point.

4. A given plug-in may extend a given extension-point multiple times.

5. An extender plug-in may include di�erent extensions of di�erent host plug-ins.

6. A single act of extension of an extension-point by a particular extension of a particularplug-in may create multiple callback objects.

7. A plug-in can de�ne extensions of its own extension-points.

86

EXISTING ECLIPSE PLUG-INS 5

The idea of a plug-in extending itself may seem strange at �rst. A well-known example ofa self-extending plug-in is the workbench UI itself. This plug-in adds various facilities, e.g.,editors, to its own UI by extending its own extension-points.

5.3 Existing Eclipse Plug-ins

Following the concepts described in the last section a whole bunch of applications/plug-ins hasalready been developed. We will �rst talk about plug-ins that are used by every other plug-inrunning on Eclipse because they are implementing basic functionality. After that we will talkabout the most famous Eclipse plug-in, the Java Development Environment. At the end of thissection, the Eclipse plug-in development environment (PDE) will be presented, a tool whichallows to develop Eclipse plug-ins using an Eclipse plug-in.

5.3.1 Eclipse Core Plug-ins

The OSGi Speci�cations only describes how di�erent pieces of software could be plugged to-gether and what central instances are needed for such a system. A lot more than this technicalspeci�cation is needed for an application development platform. It can be compared to a spec-i�cation of a programming language but a lack of standard libraries. All components o�eringsuch additional (standard library) functionality are integrated as plug-ins into the basic Eclipsearchitecture. The base functionality o�ered to Eclipse plug-in developers is referred to whenusing the term Eclipse Platform.

The Eclipse Platform consists of a set of components nearly every application needs. The partsit consists of serve the developer to de�ne a graphical part (called Workbench), a resourcemanagement part (called Workspace), and additionally a help system, a cooperation facility(Team) and lots of others.

Workbench Plug-in: The Eclipse Workbench de�nes the graphical concepts and the techno-logical background using menus, editors and views to build user interfaces. Editors allow theuser to edit something in the workbench. Editors are "document-centric," much like a �le sys-tem editor. Like �le system editors, they follow an open-save-close lifecycle. Unlike �le systemeditors, they are tightly integrated into the workbench. Views provide information about someobject that the user is working with in the workbench. Views often change their content toprovide information when the user selects di�erent objects in the workbench. The Workbenchplug-in o�ers lots of extension points.

Workspace Plug-in: The Workspace plug-in acts as a resource manager. It de�nes everythingthat is related to the users data. It chooses the means of projects, project �les, folders, packagesand other elements in tree structures to organize the users data and hold it persistent for dif-ferent plug-ins. Via this plug-in every �le system access is managed for all plug-ins. Importantfeatures are resource change listeners as well as the management of concurrent access.

87

5 ECLIPSE

Hard disk

Eclipse Platform

Activated Plug-ins

Eclipse

Runtime

Create

Plug-in

Instance

eclipse\pluginsWorkspace Folder

Plug-in Registry

register

User Interface/Workbenchorg.eclipse.ui.workbench

Project 2

Project N

Project 1

Core Plug-ins

org.eclipse.core.*

Plug-in N

GaliciaUML

Plug-in Descriptor

UI

Extension

UI

Extension

‘Platform API’

R

Plug-in Descriptor

org.eclipse.ui

org.eclipse.resources

3rd Party Plug-ins

omondo

galiciaUML

Plug-in N

Workspace

Resource Manager

Manage Resources

Update

Manager

Help

UI

Extension

RResource

AccessRResource

Access

Provide Help

Content

(Extension)

Metadata

Figure 5.16: Eclipse Platform with Core and 3rd Party Plug-ins

Help Plug-in: The Help plug-in o�ers a framework to provide program documentation anusage help in a hyperlinked format organized in books and chapters integrated into the otherEclipse Help contents.

Team Plug-in: The Team plug-in is a tool to manage, share and synchronize resources. TheCVS standard is supported by default.

Update Manager Plug-in: The Update Manager is used to install and update new versionsof plug-ins. It connects to update servers which can be provided by plug-in developers tofacilitate their update process.

Figure 6.16 shows a running Eclipse instance with a mix of activated core and non core plug-ins.The core plug-ins provide basic functionality to the third party plug-ins. The most importantcore plug-ins are the Workbench user interface and the Workspace Resource Manager. TheResource Manager manages persistant user data in the Workspace folder on the hard disk.

88

EXISTING ECLIPSE PLUG-INS 5

Eclipse Platform

Eclipse

Runtime

Create

Plug-in

Instance

Hard Disk

Plug-in

DescriptionsWorkspace

Plug-in Registry

(in-memory)register

Java Developer

User Interface

Compiler

Source Code Byte Code

R

DebuggerSource Code

Editor

R R

Resource Manager

RR R

Projects

Java Developer

Development Environment

User Interface

Compiler

Source Code Byte Code

R

DebuggerSource Code

Editor

R R

Implement

Development

Environment in

Eclipse

Java Development Environment

Java Development Environment as Set of

Eclipse Plug-ins

Figure 5.17: Java IDE implementation in Eclipse Platform

5.3.2 Eclipse Java Development Environment (JDE)

The JDE is the most popular plug-in of Eclipse11. Most developers think of this plug-in whentalking of Eclipse. It is o�ering a comprehensive Java IDE. This is at the same time a journeyback into the history of Eclipse because it started as a Java Development Environment whichis still its most used application. The Java Development Environment is developed by the JDTproject12.

Figure 6.17 shows on the left side the simple static structure of a generic Java IDE. It consistsof a user interface that allows to write source code with a source code editor, to compile thissource code into byte code via a compiler and to debug the developed program. The datastructures a development environment normally deals with are projects consisting mainly ofthe source and byte code.

In the early days of Eclipse it was just a development environment like this, but the developerswanted to make the IDE extensible. A typical extension was that a user wanted to use anothereditor, another compiler or debugger, or perhaps wanted to integrate a code versioning systeminto the same user interface. The developers implemented what is shown on the right sideof Figure 6.17. A Java IDE that respects the concepts we learned about in the last section.Every component of the development environment is packaged in one plug-in using the plug-inconcepts like communication, registry and startup from the Eclipse Platform. For the normal

11Often what is called plug-in is correctly a set of communicating plug-ins. Each plug-in o�ers a small amountof functinality. The JDE is a set of eleven plug-ins.

12http://www.eclipse.org/jdt

89

5 ECLIPSE

Eclipse Platform

Eclipse

Runtime

Create

Plug-in

Instance

Hard Disk

Plug-in N

Description

Plug-in A

Description

Plug-in B

Description

Scan Hard Disk for


Plug-in A

Plug-in N

Plug-in B

Plug-in Registry

(in-memory)register

Eclipse Plug-in

Development Environment

(PDE)

Eclipse Plug-In Developer

Write Plug-In

code into

Eclipse folder

Develop Plug-In A Test Plug-In A

Launch Eclipse

for testing

Java IDE

Dependency

Viewer

Extension Point

Wizards

Manifest Builder

Manifest Editor

Debugger

Figure 5.18: Eclipse Plug-In Development Environment (PDE)

user this di�erent implementation of the development environment is not visible, but it o�ersthe possibility to contribute functionality for everybody intersted. This is one of the reasonsfor the still growing user group of the Eclipse Java IDE.

5.3.3 Eclipse Plug-In Development Environment

When talking about Eclipse plug-ins one can wonder how to develop these. Figure 6.18 shows allthe features needed by a Eclipse plug-in development environment. It needs a way to write theJava code of the plug-in (Java IDE) and an editor to write the Manifest �les. In the Manifest�les all the plug-in dependencies (import, export, classpath) are described and a builder tocheck and validate this �le is needed. Additionally a debugger to debug plug-ins is available.

A common confusion is, that what is shown on the left side of Figure 6.18, is also implementedin Eclipse as a set of eight plug-ins. This means an Eclipse plug-in developer is working withtwo Eclipse instances simultaneously. One for writing the plug-in code and the other is startedwhen he tests or debugs the running plug-ins. Eclipse is in this way a development environmentfor itself.

90

MODELING WITH ECLIPSE 5

5.4 Modeling with Eclipse

Several projects in the Eclipse community work on modeling issues and developed tools asEclipse plug-ins that support modeling tasks. This is one of the major reasons why Eclipse isused in the context of the development of a GaliciaUML refactoring tool. In this section theEMF and UML2 projects and tools will be presented.

5.4.1 Eclipse Modeling Framework (EMF)

The Eclipse Modeling Framework13 is an Eclipse application consisting of 36 cooperating plug-ins. The end user of EMF is normally a software developer, he can use the tool via the graphicaluser interface or programmatically by invoking code of these plug-ins from his own plug-ins.EMF is so famous that already two whole books ([3] [34]) have been dedicated to this Eclipseproject.

EMF is a modeling framework and source code generator for building applications based ona structured data model. It de�nes a metamodel and metamodeling language which is closeto MOF and resides also at level M3 of the OMGs metamodel hierarchy. This metamodel anlanguage is called ECore. Files which contain models described in this language have the �leextension .ecore. As well as MOF, ECore is self de�ning. The model description of ECore(ecore.ecore) comes along with each EMF installation. ECore claims to be the essential coreof the MOF and UML metamodel that fully describes class diagrams. It is simpler than theUML 2.0 metamodel and nearly the same as MOF 2.0 which shall be released in the near future.

Besides the theoretical de�nition of an additional metametamodel which is close to the Entity-Relationship metamodel EMF provides mature tool support for all modeling related tasks.A major part of EMF is the XMI implementation and Java code generation which enablesEMF to hold models in di�erent formats consistent. (see Figure 6.19) These formats areannotated Java source code, a graphical notation like UML or XML/XMI or XML Schema.EMF does not provide graphical user interfaces (editors) for all of these notations but canintegrate them tightly. EMF provides interfaces to programmatically work with the models.The code generation facility claims to be able to work with Java code which consists as well ofgenerated and not generated code.

A Model in the sense of EMF is the description of 'anything' with the ECore modeling language.This means in general the use of Entity-Relationship models to de�ne entity domains. EMFgives you the possibility to generate Java code to programmatically work with this model or tocreate a diagram to understand this model and graphically treat it and its instances.

EMF mappings: EMF itself contains a plug-in for model mappings in its latest version.This org.eclipse.emf.mapping package is only suitable for very simple mappings betweenresembling models. It is not yet serving as a generic model transformation engine. Only simplemappings can be de�ned, but no conditions on mappings or special actions can be implemented.

13http://www.eclipse.org/EMF

91

5 ECLIPSE

Eclip

se P

latform

External Model Representations

Model

[Instance of eCore Metamodel]

Graphic

Consistency Manager

(keeps Models

in all Formats

consistent)

eCore

Metamodel

Java Source Code

+ Model AnnotationsXML/XMI XMLSchema

Code GeneratorXMI 2.0

Generator

XSO Schema

Generator

hold Models consistent

EMF User - Modeler

Graphical Editor JAVA IDE XML Editor

Change

Model

edit edit edit

Change

Model

Draw

Model

Figure 5.19: Eclipse Modeling Framework

EMF has been used throughout the development of the GaliciaUML tool. All datamodels(Transformation Language, UML, RCF, Lattice) have been de�ned using the ECore lan-guage/metametamodel. These ECore models served as a basis for the Java code generatorwho generated an Java implementation to create, change, parse and serialize model instances.A detailed example how EMF has been used is given in section 7.3.4 on the example of thetransformation language implementation.

5.4.2 Eclipse UML2

The Eclipse UML2 project delivers 25 plug-ins. It is an EMF-based implementation of theUML 2.0 metamodel for the Eclipse platform. The objectives of this project are to provide auseable implementation of the metamodel to support the development of modeling tools and acommon XMI schema to facilitate interchange of models. Additionally test cases as a means ofvalidating the UML 2.0 speci�cation and validation rules as a means of de�ning and enforcinglevels of compliance are provided.

Figure 6.20 outlines the two di�erent ways the UML2 tool can be used. The heart of the tool isthe UML 2.0 metamodel and the application programming interface to work programmaticallywith UML2 models. Parsing and serialization of models is simple because UML2 is EMF-based.If the user of the UML2 tool is a modeler he can use a simple sample modeling user interfaceprovided with each installation of the tool. But the envisioned usage of the UML2 tool is tobuild an own custom UML2 modeling tool using the provided API14. The UML2 tools canbe model drawing tools, model transformation tools, code generation tools or like in our casemodel refactoring tools.

14The Omondo EclipseUML tool presented in chapter 4 is based on this API.

92

ECLIPSE INTEGRATION CONCEPTS 5

Simple

Modeling UI

Modeler

UML2 Modele.g. Class Diagram

Programmer

Custom

Modeling Tool

Programming

APIUML2 Metamodel

Uml2.ecore

develop

R

regard

RCreate UML

Model

RDraw UML

Model

R

Figure 5.20: The Eclipse UML2 Project

5.5 Eclipse Integration Concepts

Up to this point in this chapter we only talked about cooperation mechanisms between Eclipseplug-ins. Also integrating other non Eclipse tools with Eclipse is important. Two tools needto be integrated of which one tool (referred to Tool A in the following Figures 6.21) is al-ready running as a plug-in on the Eclipse Platform. Eclipse o�ers certain possibilities withadvantages/disadvantages concerning integration depth and integration e�ort.

Within Eclipse �ve Integration Conformance Levels describe the di�erent possibilities of inte-gration. Figure 6.21 illustrates them. Tool A can be seen as the UML Tool which should beconnected to an non Eclipse called Galicia.

No Integration: No integration at all is the trivial case of an integration conformance level.The two tools are separate and independent.

Invocation Integration: Invocation integration means integration through invocation of reg-istered applications on resource types. This means for a speci�ed resource in the EclipseWorkbench (*.abc) the Eclipse user can activate an Eclipse independent Tool B to process theresources contents.

Data Integration: Data integration is achieved through data sharing. The two tools Tool Aand Tool B can work simultaneously on the same data. Two achieve this data access conceptshave been de�ned.

API Integration: API integrated tools interact with other tools through Java APIs. This isa very tight coupling, which can be understood as if Tool B is serving as a library for Tool A).

UI Integration: UI integrated tools and their user interfaces are dynamically integrated atruntime including window panes, menus, toolbars, properties, preferences, etc. This type ofintegration comprises API integration. This integration is only possible when wrapping tool

93

5 ECLIPSE

Eclipse

Galicia

Ruse Eclipse

Model Data

Ruse Galicia

UML Tool

Eclipse

Galicia

Ruse Eclipse

Eclipse UI

UML Tool

UML Tool UI

R

Galicia UI

R

UI Integration

Data Integration

Eclipse

Galicia

Rinvoke

R

invokeUML Tool

Rmodel

Invocation Integration

Eclipse

Galicia

Ruse Eclipse

Eclipse UI

R

UML Tool

UML Tool UI

R

API Integration

Figure 5.21: Integration Levels

94

ECLIPSE INTEGRATION CONCEPTS 5

be in an Eclipse plug-in and using the Eclipse extension mechanism discussed throughout thischapter. This integration concept has been applied to the integration task of the Galicia toolas discussed in the next chapter.

95

5 ECLIPSE

96

Chapter 6

Design - Implementing GaliciaUML in

Eclipse

6

This chapter deals with the questions how the architecture presented in chapter 5 can beimplemented using Eclipse and Eclipse Concepts. The �rst question is how the Galicia tool inwhich the Multi FCA algorithm is implemented can be integrated with Eclipse. The di�erentarchitectural components of the system are mapped to Eclipse plug-ins and Eclipse technologyand concepts are used to implement the functionality in the most appropriate way. The di�erentdependencies between the plug-ins will be discussed and the internal structure of the mostimportant plug-ins will be presented.

Galicia Tool Integration: Which integration conformance level applies for the integrationof the existing Galicia tool into Eclipse to allow e�ective and convenient communication withthe other components? To answer this questions the prede�ned integration conformance Levelsdescribed in section 6.5 will help.

The �rst trivial integration type 'No integration' is no option and just mentioned for complete-ness. 'Invocation integration' is too simple because Galicia does not provide a interface to belaunched programmatically or via a command line. 'Data Integration' would be possible but isnot convenient for the user because he had to work with the two tools, Eclipse and Galicia inparallel, always loading and saving �les from Galicia. The chosen integration strategy is a mix-ture of the di�erent strategies API Integration an UI Integration. The Galicia tool is wrappedinto an Eclipse plug-in that is integrated with the plug-ins which implement the components1 and 2 (see Figure 5.1) via API integration. All the plug-ins are integrated into the EclipseWorkbench user interface. That means the two types of relations between plug-is that exist inEclipse are used - dependency and extension.

6.1 Plug-ins Overview

The GaliciaUML refactoring tool consists of eleven plug-ins. Figure 7.1 shows the GaliciaUMLsystem with a focus on its separation into plug-ins. It is possible to map each 'Actor' and'Storage' of the FMC Block Diagram (see Figure 5.1) from the architecture chapter to one plug-in. At the top of Figure 7.1 the interface to the user is, as always in Eclipse, the Workbenchuser interface. It is extended via the extension point mechanism by the GaliciaUML plug-ins.

97

6 DESIGN - IMPLEMENTING GALICIAUML IN ECLIPSE

6.1.1 The Storage Plug-Ins

The plug-ins which are denoted as storages in the diagram de�ne the data model of the data thestorage contains and provide parsing, serializing and basic editing code for these data structures.These plug-ins use the metamodels of the data to provide all these important support.

The storage plug-ins are all based on the Eclipse Modeling Framework. How this looks like indetail is described in section 7.3.4 later in this chapter.

fr.lirmm.galiciauml.uml2rcfmodel: This plug-in de�nes the data format of the �le in whichthe transformation language is stored. It is based on the Ecore �le (see Figure 5.7) and is anEMF plug-In. Everything but the .ecore �le and the .genmodel �le is generated.

fr.lirmm.galiciauml.galiciamodel: This plug-in de�nes the dataformat of the �les that areused to exchange the data with the Galicia tool, that means it comprises two di�erent dataformats. These two di�erent data formats belong to two separated components in the architec-ture diagram (see Figure 5.1). The plug-in is based on EMF parsing, serializing, editing anduser interface generated code as well. The di�erence is, that the ECore �le is generated as well,because the metamodel of this data format already existed in form of an XML Schema �le.EMF provides the possibility to translate metamodel description from XML Schema to ECore.

org.eclipse.uml2.*: This set of plug-ins is neither written by the author nor is it a result ofthe previous work. The plug-ins are developed and maintained by the Eclipse community andare mentioned here only because of the great importance. They are a basic implementationof the UML2 metamodel and provide all parsing, serializing, editing and simple UI that isnecessary to work with it.

fr.lirmm.galiciauml.persistancehelper: This plug-in does not appear in Figure 7.1 becauseit provide functionality that is used by all actor plug-ins and has no meaning in the architecuralsense. It provides convenience methods for working with the other plug-ins containing datamodels.

6.1.2 The Actor Plug-Ins

The actor plug-ins mostly contain algorithmic methods that change the data de�ned by the stor-age plug-Ins. The Actor plug-ins contain the implemented algorithmic functionality discussedin the architecture chapter mapped to Java Classes and Packages.

fr.lirmm.galiciauml.uml2rcf: This plug-in is the implementation of the 'UML to RCF' trans-formation step. It comprises the transformation engine as well as the code generator for therules. (see section 7.3.1)

fr.lirmm.galiciauml.lat2uml: This plug-in is the implementation of the 'Lattice to UML'transformation step. It parses the result �les from the Galicia algorithm and o�ers di�erentpossibilities how to translate these results to refactored UML diagrams. (see section 5.5)

98

PLUG-INS OVERVIEW 6

Eclipse Framework

Third Party Plug-Ins

org.eclipse.uml2.*

Eclipse Workbench UIorg.eclipse.ui.*

Omondo ExtensionsGaliciaUML

Omondo UML

Architectcom.omondo.architect.*

.uml2 File.uml2 File

UML 2 RCF

fr.lirmm.galiciaUML.uml2rcf

Lattice 2 UML

fr.lirmm.galiciauml.lat2uml

Transformation

Descriptionfr.lirmm.galiciauml.

uml2rcfmodel

Transformation

Transformation

Description Editorfr.lirmm.galiciauml.uml2rcfmodel.edit

fr.lirmm.galiciauml.uml2rcfmodel.editor

Modify UML ModelModify Transformation

Model

R

RExtension Point

fr.lirmm.galiciauml.galiciamodel

Galicia FCA

Algorithmfr.lirmm.galiciauml.galicia

RCF File Lattice File

GaliciaUML Plug-Insfr.lirmm.galiciaUML.*

Runtimeorg.eclipse.core.runtime

Resourcesorg.eclipse.core.resources

EMForg.eclipse.emf

Eclipse Standard Plug-Insorg.eclipse.*

RExtension Point

Figure 6.1: GaliciaUML - Plug-In View

Galica: This is the wrapped Galicia tool and some additional code that is used instead of thegraphical user interface to start Galicia programmatically with the UML speci�c options.

fr.lirmm.galiciauml.ui: This plug-in implements a speci�c user interface for all the otherplug-ins. The main components are the di�erent Actions and the Refactoring Dialog andWizard. At the moment this plug-in contains the knowledge about the sequence of which plug-in is launched after the other - the con�guration of the whole system. Even if this is not muchcode, perhaps it should be at another place.

6.1.3 Other Plug-ins

Additionally two other plug-ins come along with GaliciaUML, serving not directly as 'Actor'or 'Storage'. They provide functionality that is not directly related to the refactoring task.

fr.lirmm.galiciauml.help: The documentation, installation and user manual comes alongwith the tool packaged in a separate plug-in. It appears tightly integrated in the Eclipse Helpsystem.

99


fr.lirmm.galiciauml.test: Unit tests for the GaliciaUML plug-ins are implemented using theJUnit concept. They test with sample UML models whether the di�erent transformation stepswork properly or not. This plug-in is particularly useful when further development is planed.

6.2 Plug-in Relationships

The GaliciaUML plug-ins are related to each other, to Eclipse core and to third party plug-ins.Both types of relationships presented in chapter 6 are used. First the di�erent dependencyrelationships are discussed before talking about the use of extension points.

6.2.1 Dependencies between GalicaUML Plug-ins

The GaliciaUML plug-ins are interdependent using the Eclipse plug-in dependency mechanisms.That means that they even if the plug-in implementation seems to be at most normal Java sourcecode for the inter plug-in communication not the Java visibility of the classes is important. Ineach plug-ins Manifest the inter plug-in interfaces are described. The Java mechanism is onlyimportant for the plug-in internal dependencies.

Figure 7.2 shows a layer diagram of GaliciaUMLs plug-in layers. As de�ned by the Eclipse plug-in mechanism no recursive layering occurs. The topmost element is the fr.lirmm.galiciauml.uiplug-in that uses the three underlying plug-ins via API usage. This dependency is nec-essary because the user interface invokes the three subalgorithm (UML to RCF to Latticeto UML) sequentially. They build up the main transformation steps. The two underly-ing plug-ins fr.lirmm.galiciauml.uml2rcf and lat2uml have the same dependency to thefr.lirmm.galiciauml.galiciamodel plug-in also with an API usage. They need the galici-amodel plug-in to be able to parse, modify and serialize the RCF and Lattice data format. Theuml2rcf uses the uml2rcfmodel as well because this plug-in needs to work with the transforma-tion language data format. The uml2rcfmodel.editor plug-in depends on the uml2rcf.editplug-in which uses the uml2rcfmodel plug-in directly.

The dependencies graphic (Figure 7.2) has three layers of plug-ins with dependencies from thetop to the bottom. The user interface layer on the top depends on the algorithms layer in themiddle. The algorithms need the model plug-ins (for the data formats) from the lowermostlayer.

6.2.2 Depending on EMF and UML2 Plug-Ins

The task asked by GaliciaUML is dealing with a UML2 model, a RCF Model and a Latticemodel and their metamodels as discussed in section 5.6. The UML2 Model provided by theUML2 project perfectly �ts the requirements of the GaliciaUML idea. It provides all necessarypossibilities to work with UML models on a standard format. UML2 is implemented using the

100

PLUG-IN RELATIONSHIPS 6

ui

uml2rcf Galicia lattice2uml

persistance

helper

galiciamodel uml2rcfmodel

uml2rcf.editor

uml2rcf.edit

Figure 6.2: GaliciaUML - Plug-In Layer Diagram (Dependency Relationships)

EMF framework.

As well as the UML2 data format implementation also the implementations of the otherdata formats used in this tool are based on the Eclipse Modeling Framework. This is thereason for the dependency relationships between most of the GaliciaUML plug-ins and theorg.eclipse.emf.* plug-ins.

6.2.3 Depending on basic Eclipse Plug-Ins

Besides the here shown dependencies the additional dependencies to Eclipse core plug-ins exist.This is necessary to exploit the functionality which is o�ered by the Eclipse platform and toextend the user interface. The most important plug-ins the GaliciaUML plug-ins depend onare:

• org.eclipse.core.runtime

• org.eclipse.core.resources

• org.eclipse.ui

• org.eclipse.ui.ide

• org.eclipse.help

The functionality of most of these plug-ins has already been discussed in chapter 6. Dependingon these plug-ins can be compared to depending on standard libraries in other programminglanguages.

101


6.2.4 Extensions

Several of the plug-ins use Extension Points of Eclipse Core plug-ins to contribute functionality.No plug-in is yet de�ning its own extension point. How the Extension Point mechanism couldbe used also for the cooperation between the GaliciaUML plug-ins is a future task (see chapter8).

• org.eclipse.ui.actionSets - for menu items in the top level menu

• org.eclipse.ui.popupMenus - for menu items in the popup menu (right click)

• org.eclipse.ui.newWizard - for the contribution of the con�guration wizard to con�g-ure the refactoring

• org.eclipse.ui.editors - for the wizards input �elds

• org.eclipse.core.resources.markers - for the resource markers indicating the singlerefactorings as a result of the incremental refactoring algorithm

• org.elcipse.ui.ide.markeresolution - to bind an action to the marker, to performthe refactoring

• org.eclipse.ui.ide.markerimageprovider - to bind an image to the marker to distin-guis the GaliciaUML markers from other markers

• org.eclipse.help.toc - to de�ne at which place of the table of contents of the Eclipsehelp the GaliciaUML help should appear

• org.eclipse.emf.ecore.generated-package - to tell the generator that this is a gen-erated package

• org.eclipse.emf.ecore.extension-parser - to open the .galicia extension with thetransformation language editor.

6.3 Inner Plug-in Structures

In this section it is discussed how the architectural concepts of uml2rcf, lat2uml and Galicia

described in the Architecture chapter are mapped to object oriented concepts (packages, classes)and Eclipse concepts (plug-ins, extensions, ...) and how the algorithms in the di�erent partswork in detail. Also an Example of the implementation of the transformation language usingthe EMF concept is given.

102

INNER PLUG-IN STRUCTURES 6

Figure 6.3: Classes of fr.lirmm.galiciauml.uml2rcf generator Package - Class Diagram

6.3.1 fr.lirmm.galiciauml.uml2rcf

This plug-in implements the code generator and the transformation engine to translate .uml2�les to g2-rcf.xml �les. These two functionalities have to be considered as not on the samelevel because in di�erent steps �rst the classes for the generated rules need to be generatedbefore in a second step they can be used in the deployed plug-in.

6.3.1.1 Package Structure

This plug-in contains three packages and one important �le. The �le GaliciaUML.uml2rcf isin the root folder and contains all transformation descriptions.

• fr.lirmm.galiciauml.uml2rcf

• fr.lirmm.galiciauml.uml2rcf.generator

• fr.lirmm.galiciauml.uml2rcf.generated

• fr.lirmm.galiciauml.uml2rcf.transformationengine

The code generator resides in the generator package and the transformation engine in thetransformationengine package. The generated package contains the generated classes andis therefore used as well form the generator as from the transformation engine.

6.3.1.2 Rules Generator

Figure 7.4 describes the dynamic structures of the rules generation engine which are imple-mented in the four Java classes in the fr.lirmm.galiciauml.uml2rcf.generator package(see Figure 7.3).

The generation process starts with loading the rule descriptions from the GaliciaUML.uml2rcf�le. For every rule description the generic generation method of the RuleGenerator is invoked.

103


Load Rule

Descriptions

Recompile

Project

All rules

processed

Check RuleType

For every Rule

InterObjectRule

BinaryContextRule

Save gen.

source code in

.java file

gen. unique

Classname

Generate

specific code

imports

getRows

matchElement

getColumns

Generate

specific code

imports

getRows

matchElement

getColumns

setReferences

gen. Constructor

gen. Package

RuleGenerator

BinaryContext-

RuleGenerator

InterObject-

Context-

RuleGeneratorGeneratorEngine

Figure 6.4: Rules Generation Engine - Dynamic Structure

The RuleGenerator generates all methods that are equal for the both types of supported rules.For the code generation of rule type speci�c methods the appropriate of the two subclassesof RulesGenerator, BinaryContextRuleGenerator or InterObjectContextRuleGenerator,are called. Even if the method names are similar (matchElement, getRows, etc) becausethey �ll similar structures in the result RCF the implementation is di�erent. These di�er-ences will be discussed in the transformation engine section when presenting the transfor-mation process. When the complete code is generated it is saved in a .java �le in thefr.lirmm.galiciauml.uml2rcf.generated package. Recompilation of the code is done beforethe invocation of the transformation engine when starting the Eclipse runtime workbench.

104


Figure 6.5: Rules Package - Class Diagram

6.3.1.3 Transformation Engine

The transformation engine is implemented in four Java classes from two packages and in thegenerated rules classes.

• fr.lirmm.galiciauml.uml2rcf.transformationengine.TransformationEngine

• fr.lirmm.galiciauml.uml2rcf.rules.RCFRule

• fr.lirmm.galiciauml.uml2rcf.rules.BinaryContextRule

• fr.lirmm.galiciauml.uml2rcf.rules.InterObjectContextRule

• fr.lirmm.galiciauml.uml2rcf.generated.*

The Interface: This plug-in exports one package, the fr.lirmm.galicauml.uml2rcf package.This package contains three classes. The Uml2rcfPlugin Class exports the methods:

public static Uml2rcfPlugin getDefault()

public String[] getTransformationNamesArray()

public TransformationDocument getTransformationDocument()

Dynamics: The dynamic structures and the mapping to implementation classes is shown inFigure 7.6. The TransformationEngine implementation has the main entry point of this plug-ins functionality. The UML Model with the content to transform is loaded and a new emptyRCF model and �le are created. The classloader of this class is used to create instances ofthe generated rule classes in the generated package that participate on the particular chosentransformation. Every instantiated rule now is invoked one time on the input UML modeland will return a ContextType object. This object is either a InterObjectContext or aBinaryContext depending on the type of the rule that produced it. Each rule will �rst createits appropriate type of the context which than will be �lled by the methods of the generatedrules.

105


Load UML Model

Save Result RCF

Model File

All rules

processed

For every RuleBinaryContextRule

Create Binary

Context

TransformationEngine RCFRule + BinaryContextRule

GeneratedRule

Create File with

RCF Model

Use ClassLoader

to instanciate

Generated Rules

Add Binary

Context to RCF

Foreach UML model element

Match Element

getRows()

getColumns()

createRelations()

Element Matched

Create

InterObject

Context

Add InterObject

Context to RCF

Match Element

getRows()

getColumns()

createRelations()

Element Matched

InterObjectRule

Foreach UML model element

setReferences()

GeneratedRule

RCFRule + InterObjectContextRule

Figure 6.6: Transformation Engine - Dynamic Structure

106


6.3.2 Galicia

This is the wrapped Galicia tool and some additional code that is used instead of the graphicaluser interface to start Galicia programmatically with the UML speci�c options. Additionallysome changes on the Galicia tool needed to be made.

6.3.2.1 Java Code wrapped into a Plug-in

What does it mean to wrap a normal program into a plug-in? This is a very simple processwhich is o�ered by the Eclipse PDE. It creates a default plug-in Class and Manifest �les.Unfortunately the user-interface has to be integrated into Eclipse concepts if it should be used.This was not the problem in our case because for GaliciaUML the old Galicia interface was notinteresting.

6.3.2.2 Invoking Galicia Programmatically

The programmatical invocation of the Galicia Tool is implemented in the class lattice.GaliciaInterface.It exports the method

public Vector start(IFile rcfFile)

which is the complete interface of the Galicia tool.

int kindOfScaling = MultiFCA.WIDE_KIND;

6.3.2.3 Changes

At di�erent points the source code of the original Galicia tool had to be changed. The mostimportant ones are:

• Multi FCA Algorithm - The implementation of the algorithm was wrong.

• Resource Access - The resource access methods were operation system dependent andhad to be changed using the Eclipse Resource Manager.

• Saving of Lattices - The stored lattices had other numbers for the concepts than this wasthe case in the in memory version. Therefore references between the lattices did not workany more in the persisted version.

107


6.3.2.4 Metamodel

Even if the plug-ins developed in the context of this work and the Galicia tool are based on thesame metamodel for the interchange formats they use a di�erent technology. This work is basedon the EMF Framework which has generated a parser starting from a metamodel descriptionin XML Schema via a translation into an ECore model. This ECore model is the basis for agenerated parser and a generated user interface for this model. The Galicia tool is not basedon EMF and Eclipse even if it is now appearing as an Eclipse Plug-in. It uses an XMLReaderfrom Apache1 to parse the input �les with respect to the metamodel description in the XMLSchema.

The main di�erence between the two approaches is, that the EMF based solution also providesa programming environment and Class model to deal with the parsed �les as Java Objectsconform to the metamodel. The solution implemented in the Galicia tool uses the metamodelonly for the purpose of checking the input �les validity, the translation into Java Objects ishandwritten and independent. A second di�erence is that the EMF Framework parse andserialize their models using the XMI standard which is not the case for the Galicia tool. Thisleads to e�ects where Galicia refuses to open valid XML �les just because there is additionalmeta information included into the serialized model.

6.3.3 fr.lirmm.galiciauml.lattice2uml

This plug-in implements the algorithms presented in section 5.5 to perform incremental refac-torings or the complete reconstruction.

6.3.3.1 Package Structure

• fr.lirmm.galiciauml.lattice2uml

• fr.lirmm.galiciauml.lattice2uml.reconstruct

• fr.lirmm.galiciauml.lattice2uml.refactoring

• fr.lirmm.galiciauml.lattice2uml.util

The reconstruct package complete reconstruction algorithm implementation. The refactoringpackage contains the incremental refactoring implementation. The util package contains con-venience classes to work with Lattices, UML models and Galois Sub Hierarchies.

1http://www.apache.org

108


6.3.3.2 Complete Reconstruction

The reconstruction package contains several implementations of what is explained in Figure5.13 in the Architecture chapter. The implementations di�er in the number and types of classesthey can work with. The Class AbstractCompleteReconstructor should be extended by eachnew algorithm because it handles standard con�guration work and serves as an interface.

The mapping into an implementation is so simple because it is only an algorithm implementationwhich can be done easily programming Java.

6.3.3.3 Incremental Refactoring

The refactoring package contains one implementation of what is explained in Figure 5.15and Figure 5.16. The RefactoringMarkerCreator Class implements the 'Refactoring PatternsSearch Engine', the Refactorer Class implements the 'Refactorer'. The Refactoring Classimplements the data type used to store the 'Possible Refactoring Descriptions'. To integratethe tool with the Eclipse UI the RefactoringMarkerResolutionGenerator Class is used.

The Eclipse concepts for extension points have been used extensively by this tool to integratethe markers and marker resolution tightly into the Eclipse user interface. The extension pointswhich have been used are shown in section 7.2.4.

6.3.4 fr.lirmm.galiciauml.uml2rcfmodel, edit, editor

These three plug-ins are typical EMF plug-ins containing only an .ecore and a .genmodel �lefrom which all the plug-in code is generated. In this section the structure of EMF generatedplug-ins will be shortly presented.

The .ecore �le contains a discription of a datamodel. This datamodel has been alreadydescribed in the Architecture chapter. The .genmodel �le contains options concerning thegeneration process of the model form the .ecore �le. Figure 7.7 shows that the EMF Plug-In/Code Generator reads the two input �les and generates several plug-ins containing di�erenttypes of logic.

The fr.lirmm.galiciauml.uml2rcfmodel contains three packages. It is the main plug-in that isalways generated because all the other plug-ins are based on it.

• uml2rcf - contains the Java iterfaces for all model elements. One interface for eachmodel element (e.g. Rule, Transformation, RelationalRule) and additionally a factoryand a package class (here Uml2rcfFactory, Uml2rcfPackage).

• uml2rcf.impl - contains all implementation classes for the interfaces

109


Figure 6.7: EMF Plug-In/Code Generator

• uml2rcf.util - contains several helper classes. They appear only if the appropriateoptions have been set in the .genmodel �le

The edit and editor plug-in contain the code for the sample model editor. Even if EMF allowsincremental code generation and mixing of generated and hand written source code these threeplug-ins are one hundred percent generated. They contain no handwritten code.

110

Chapter 7

Outlook

7

The result of this work is a fully functional tool integrating refactoring algorithms into a maturedevelopment environment. It works, but at a lot of points more work can be done as well onthe development level as on theoretical research. The auther's major ideas on which furtherwork could be based are:

Usage of Model Transformation Engines: The three transformation steps (UML to RCFto Lattice to UML) can be implemented by transformation engines. The task is to monitorthe advancement of model transformation engines (see chapter 4) particularly when the QVTstandard is �nished. Especially the 'UML to RCF' transformation needs to be translated intoa generic transformation language. This seams to be possible because the actual logic of theimplementation is already in rules. The two other transformation steps will be more complicatedand success will depend on the development progress of model transformation engines.

Research on Refactoring Algorithms: With the GaliciaUML tool for a �rst time thepossibility to apply the Multi FCA algorithm to bigger projects has been created. Now largertests on real world software products have to be made to get a detailed picture on what MultiFCA can do in the current version, what possible changes can be implemented and what otherkinds of algorithms can be plugged in the GaliciaUML chain instead of Multi FCA.

Concept for Lattice Interpretation: The Lattice interpretation algorithm implemented inGaliciaUML is still simple. It works only for special numbers of lattices and depends on themetamodel elements which are expressed in the lattices. One concept for lattice interpretationcan be a generic algorithm working for all lattices. Another approach is to supply advancedcon�guration possibilities (e.g. in form of rules) that allows to treat the di�erent lattices asthey need it.

Interpretation/Semantics of Refactoring Results: What does a restructured UML modelmean? What are the implications for the underlying source code and the software system? Isit possible to let the Multi FCA algorithm work directly with Java models and not with UMLmodels?

Extract Multi FCA from the Galicia Tool: The Multi FCA algorithm is now implementedin the Galicia tool. The tool o�ers rich graphical and other features that are not necessarilyinteresting and complicate the source code basis. Galicia does not provide su�cient interfacesand development work from the side of Galicia working groups seams not to go in the direction

111

7 OUTLOOK

to support our refactoring approach. The mathematical algorithm should be purely integratedin a dedicated plug-in with a simple interface.

Declare Extension Points: The Eclipse Extension Point Mechanism o�ers possibilities toimprove the tools architecture even more. Algorithms can be contributed via extensions pointsto allow di�erent working groups to cooperate without changing any source code of the coretool.

The most important goal was to create a tool that can be understood by future developers. Thisshould be the case because of its clear and e�ective architecture together with the architecturalplans and explications provided in this document.

112

Appendix A

Installation Manual

ATo install Eclipse with the GaliciaUML plug-ins two possibilities are o�ered. Installation fromthe CD ROM where everything needed is bundled or manual installation of all the separate toolsand the development environment. If you don't want to install manually copy the completeEclipse folder from the CD into an arbitrary directory (I propose to use the directory structureshown in Figure A.1. Than continue with step 'Installing Java' A.3.

A.1 Download

This installation instructions work on the ATGC machine at LIRMM, but should work on everyLinux or Windows operating system when picking the appropriate packages. It is necessary todownload the following programs to prepare an appropriate Eclipse installation.

• Java Development Kit (JDK) 1.5

• Eclipse Platform

• Eclipse Modeling Framework

• Eclipse UML2

• GaliciaUML

• Omondo EclipseUML

A.1.1 Eclipse

Eclipse and related projects is everything that you can get from http://www.eclipse.org andwhich is developed and supported by the Eclipse community. These products are open sourceand it is important to install the right versions because of compatibility issues.

113

A INSTALLATION MANUAL

Figure A.1: Directory Structure of GaliciaUML installation

Downloading from www.eclipse.org: First of all the Eclipse environment and the relatedprojects need to be downloaded. Because Eclipse is an open source project not all downloadableversions are stable and versions change often to coordinate di�erent development teams. Allversions that are used here are 'Releases'. A 'Release' is normally in a very stable state, onlyversions are more 'important'. It is necessary to download exactly the versions speci�ed here,don't download nightly builds, stable builds, integration builds or release candidates.

• http://www.eclipse.org Eclipse SDK 3.1 Release, select the version for the desiredoperating system.

To install these downloads �rst of all the Eclipse SDK archive needs to be extracted into thefolder where the Eclipse Installation should be. After extracting the archive the basic Eclipseinstallation is �nished.

Launching Eclipse: To launch Eclipse on a Windows OS double-click the

eclipse.exe

�le in the ECLIPSE-HOME directory. On a Linux machine open a terminal window and type

114

GALICIAUML A

./eclipse

also from the ECLIPSE-HOME. When starting Eclipse the �rst time a Workspace locationneeds to be speci�ed, this is totally up to the users choice but I propose the structure in FigureA.1 to be able to follow this manual more easily.

A.1.2 EMF and UML2

Download the two projects from the Eclipse website into your install �les directory followingthe above given recommendations regarding versions.

• http://www.eclipse.org/emf Eclipse Modeling Framework, EMF Release 2.1.0, July 7,2005, SDK for sdo, xsd and emf.

• http://www.eclipse.org/uml2/ UML2 SDK Release Build 1.1.0

The EMF and UML2 archives both represent the same folder structure as the main Eclipseinstallation. They contain a folder named eclipse which contains the two folders plugins andfeatures with several �les in it. The �les have to be copied into the corresponding directoriesin the ECLIPSE-HOME installation directory.

If any problems appear please read the Eclipse installation documentation and the installationdocumentation of the projects from their websites. If errors remain it is helpful to contact theappropriate newsgroups.

A.1.3 Omondo EclipseUML

For the actual version of EclipseUML (here I recommend to always use the newest version)look at www.omondo.com for EclipseUML Architect or contact the Omondo development team([email protected]).

A.2 GaliciaUML

GaliciaUML is a set of plug-ins which are developed within the work on this Masters Thesisand are provided at http://www.lirmm.fr/GaliciaUML.

115


Figure A.2: Select Workspace

Figure A.3: Import Existing Projects into Workspace

A.2.1 Installing Plug-ins in the Eclipse workspace

Copy the workspace with the Galicia plug-ins for which further development should be doneinto a speci�c folder (see Figure A.1) which will than be used as your workspace. You can alsouse the workspace you normally use together with your other Eclipse development projects.

Start Eclipse. Select the Workspace where you recently installed the plug-ins. (see Figure A.2)

Select the Workbench view from the Eclipse Welcome screen. If it is the �rst time you use thisworkspace the projects view in the package explorer is empty. To import the projects into theworkspace select import (from File->import or right click in the empty package explorer andselect import option). Figure A.3 appears. Select the option 'Existing Projects into Workspace',than click 'Next'.

Figure A.4 appears. Select the Workspace directory as root directory. All projects in thisworkspace will appear and they are preselected. Choose the projects you are interested in and

116

INSTALLING JAVA 5 FOR ECLIPSE A

Figure A.4: Import Existing Projects into Workspace

click 'Finish'. This will invoke Eclipse to import and compile the projects. When compilingperhaps temporary errors may occur because the projects are interdependent. When a projectis importet and compiled before a prerequisite project is available the errors remain until theprerequisite project is compiled too. Just wait a view seconds until Eclipse has �nished hiswork.

If errors remain 'clean' the workspace via the Project menu's Clean option. If this does nothelp perhaps Java 5 is not yet installed - continue with next section.

A.3 Installing Java 5 for Eclipse

Download Java 5 from java.sun.com. Choose the version JDK 5.0 (Java Development Kit)for your Platform and follow the installation instructions. Don't try to install the JRE �rstbecause it's smaller, it is not su�cient. To tell Eclipse that a new Java Version is availableselect Window -> Preferences -> Java -> Installed JREs and Add the Java installation youjust �nished to install. Make sure your projects use the new Java version.

A.4 Launching Plug-ins in a Runtime Workbench

Select 'Run' from the menubar. Figure A.5 shows this dialog. The GaliciaUML plug-ins will runas an 'Eclipse Application'. Select 'Eclipse Application' and than 'New'. 'New Con�guration'appears. Change the name to e.g. GaliciaUML. The workspace of the new Eclipse runtime willbe in the directory speci�ed in the 'Workspace Data' region.

117


Figure A.5: Run Con�guration

Select the plug-ins tab to verify which plug-ins will be launched in the new workspace instance.Click 'Run'. A new Eclipse instance launches. This Eclipse instance is started with the plug-ins you speci�ed. If everything worked �ne you should �nd a 'UML Refactoring' menu in themenu bar (highlighted in Figure A.7). This step created the folder 'runtime workspace' in yourinstallation directory if you have chosen the directory structure shown in Figure A.1. How touse GaliciaUML Eclipse plug-ins please continue in the User Manual Chapter.

A.5 Installing Plug-ins permanently in Eclipse

This section describes how to install self-developed plug-ins permanently into Eclipse. This willbe explained on the example of the following the three interdependent plug-ins describing thetransformation language metamodel and the generated user interface. The same concept worksfor all plug-ins.

• fr.lirmm.galiciauml.uml2rcfmodel

• fr.lirmm.galiciauml.uml2rcfmodel.edit

• fr.lirmm.galiciauml.uml2rcfmodel.editor

To export plug-ins from the Plug-in Development Environement (PDE) the plug-in editoro�ers an Export Wizard. Double-click the plugin.xml or Manifest/Manifest.mf �le to open

118

INSTALLING PLUG-INS PERMANENTLY IN ECLIPSE A

Figure A.6: Run Con�guration

Figure A.7: Eclipse with GaliciaUML plug-ins installed

119


Figure A.8: Plug-n Export Wizard

the plug-in wizard of the plug-in that should be exported and press the export link. In thedialog shown in Figure A.8 the plug-ins that should be exported are preselected. As ExportDestination the eclipse root directory of the eclipse installation in which the plug-ins shouldrun permanently should be selected. Invoke the export process with pressing 'Finish'.

Verify that in the ECLIPSE-HOME/plugins folder of your Eclipse installation the three newarchive �les

• fr.lirmm.galiciauml.uml2rcfmodel_1.0.0.jar

• fr.lirmm.galiciauml.uml2rcfmodel.edit_1.0.0.jar

• fr.lirmm.galiciauml.uml2rcfmodel.editor_1.0.0.jar

exist with recent date and creation time. If this is the case everything worked �ne up to thispoint. To use the plug-ins Eclipse needs to be restarted. After the restart of Eclipse verifythat the plug-ins are properly installed via Help->About Eclipse SDK->Plug-in Details. Thisshows a dialog similar to the dialog shown in Figure A.9. It shows a list of all plug-ins that areloaded into the Eclipse plug-in registry and are ready for activation or already activated.

Another e�ect of the installation of especially these three plug-ins is that now the editor forthe transformation language is installed. It permits to easily de�ne new transformations andtransformation rules. This will be described more in detail in the next chapter.

120

INSTALLING PLUG-INS PERMANENTLY IN ECLIPSE A

Figure A.9: Dialog to verify which plug-ins are actually installed

121


122

Appendix B

User Manual

BThis user manual is organized in two parts. The �rst part describing how to perform prede�nedtransformations on di�erent user created UML2 models. The second part describes how tode�ne own transformations using the model transformation language and rule generator.

B.1 Performing Model Transformations

This section presents how to set up a model transformation environment from scratch. Creatinga project, an UML2 model and than performing the two types of transformations, completerefactoring or refactoring marker creation.

B.1.1 Creating a new Project

This section presumes that Eclipse with the GaliciaUML is properly installed (This can alsobe in a runtime-workbench). If this is not the case perform �rst the steps from the InstallationManual.

After the installation the workbench is empty. To get started it a new project needs to becreated. File -> New -> Project -> Java Project -> name='GaliciaUMLTest' with standardoptions creates a project named GaliciaUMLTest. It is not necessary to create a Java Project,it is possible to use any arbitrary project. (see Figure B.1).

B.1.2 Creating a UML2 Model

After that the UML2 that should be transformed needs to be created. How to work withUML2 is described in detail in the article 'Getting Started with UML2' from Ken Hussey whoanswers all related questions in the UML2 newsgroups on Eclipse. The article is available athttp://www.eclipse.org/uml2/. The very �rst simple steps will be nevertheless explainedhere too.

123

B USER MANUAL

Figure B.1: Create a new Project

Figure B.2: Create a new UML2 Model

124

PERFORMING MODEL TRANSFORMATIONS B

Figure B.3: Modifying UML2 Models with the default editor

File -> New -> other opens the dialog shown in Figure B.2. Select 'Example EMF ModelCreation Wizards' -> 'UML2 Model'. In the Wizard that appears select the model object'Model'. With the Model creation wizard every UML2 model can be created. It is also possibleto use the provided .uml2 models in from the fr.lirmm.galiciauml.test plug-in's uml2 folderor to create the UML2 model with the Omondo Tools 1

The created Model appears in the package explorer and can be opened by double clicking. Tomodify the model the provided editor (default option) in the editor �eld and the properties viewat the bottom need to be used (see Figure B.3). New model elements can be created by rightclicking on the model element and choosing the desired child element from the list. Propertiesof model elements will be speci�ed in the properties view on the bottom of the workbench. Furfurther details please refer to the 'Getting started with UML2' and the UML2 newsgroup.

B.1.3 Refactoring

When a model is created like shown in Figure B.4 the refactoring can be invoked by rightclicking on the model �le and choose 'Refactor UML Model'. The other way to do the same isto select this option from the menu bar's 'UML Refactoring' menu.

The 'UML Refactoring' dialog appears (see Figure B.5). At the top of the dialog the UML2model �le (*.uml2) should be speci�ed. When a *.uml2 �le was selected before invoking the

1see www.omondo.com or the provided EclipseUML section in the Eclipse Help.

125

B USER MANUAL

Figure B.4: Invoke Refactoring

'Refactor UML Model' action this �eld is already pre�lled. If this is not the case, the �le canbe opened via the open �le button. (only �les from within the workspace can be selected).

The option 'Transformation' is a list from which a 'Transformation' needs to be selected. Inthis list all the names of transformations appear which have to be de�ned and for which ruleshad been created generated before.

The next option 'Encoding' is an option for the Galicia algorithm itself. It is specifying howthe algorithm is working and for further details on this it should be referred to the Galiciadocumentation.

The third option 'Transformation Result' is the most important because there can be selectedhow the results of the galicia algorithm - the concepts lattices - will be retranslated to UMLdiagrams. The option 'Create Refactoring Markers' will create markers on the original UMLmodel that propose refactorings which can be invoked. The option 'Complete Diagram Recon-struction' will create a complete new UML Diagram with all the refactoring already performed.

B.1.3.1 Complete Diagram Restructuring

The 'Complete Diagram Restructuring' algorithm creates a complete new model in a new �le.The �lename of the new �le will be the �lename of the old �le completed with the stringrefactored. For example the refactored result of the �le My.uml2 will be stored under the

126

PERFORMING MODEL TRANSFORMATIONS B

Figure B.5: Refactoring Dialog

name My-refactored.uml2.

B.1.3.2 Creating Refactoring Marker

When this option is chosen after the clicking the 'Finish' button nothing changes on the diagrambut markers are added. These markers can be seen in the 'Problems View' of the Eclipse JavaDevelopment Tools. (already activated in every Eclipse default installation). Figure B.6 showsthe refactoring markers added by the standard transformation on our example model.

In the context menu of the refactoring marker (mouse right click) the option 'Quick Fix' nowis enabled. When selecting this option a dialog opens which o�ers one single option called'Perform Refactoring'. By selecting this option and pressing ok the selected refactoring isperformed on the original diagram. After this all refactoring markers should have disappearedfrom the problems view. When no changes can be seen on the original diagram it is possiblynecessary to refresh the view on the package explorer (by pressing F5 or context menu refreshor open close the diagram �le).

The result of a single refactoring using the 'Quick�x' of a 'Refactoring Marker' is shown inFigure B.12 (visualized with Omondo UML Architect)

B.1.4 Using Omondo to interpret Results

A intuitive way to visualize UML diagrams is provided by the Omondo EclipseUML Architect.It enables Eclipse to work with UML Diagrams stored in the Eclipse UML2 format (*.uml2).To open a UML2 �le in the UML Architect select File->New->Other. Than UML2 Architect->Architect Class Diagram. (see Figure B.7). To do this the selection in the package explorer

127

B USER MANUAL

Figure B.6: Refactoring Marker in the Eclipse Problems View

should be set on the project root (Omondo Bug).

The 'New Architect Class Diagram' dialog enables of selecting the name of the package thatshould be opened. When the package already exists the model �le which contains this packageis used as the model �le for the new diagram. (see Figure B.8).

If an existing package (not empty) has been selected the last step of the Omondo Wizard isto ask which model elements should be shown in the diagram. As default option all modelelements are selected, this is recommended. (see Figure B.9)

Figure B.10 and Figure B.11 show how the original diagram and the result diagram. Theyare visualized with the Omondo UML2 Architect. Unfortunately the in the result diagram theinheritance relationships are drawn so that one could not know which is model elements areconnected and which are not.

B.2 Generating New Transformation Rules

To generate new Transformation Rules the rules need to be described in the transformationlanguage and than the rules generator needs to be used to generate rules in Java Code fromthat.

B.2.1 Using the Transformation Rules Editor

When the three plug-ins including the model of the transformation language and the editor ofthe language are installed the transformation rules can be graphically modi�ed.

128

GENERATING NEW TRANSFORMATION RULES B

Figure B.7: Open UML2 Files with the Omondo UML2 Architect

Figure B.8: Opening a Class Diagram with Omondo UML2 Architect

129

B USER MANUAL

Figure B.9: Opening a Class Diagram with Omondo UML2 Architect

Figure B.10: Original UML Model visualized with Omondo UML2 Architect

Figure B.11: Result of the Complete Refactoring visualized with Omondo UML2 Architect

130


Figure B.12: Result of a Single Refactoring visualized with Omondo UML2 Architect

• fr.lirmm.galiciauml.uml2rcfmodel

• fr.lirmm.galiciauml.uml2rcfmodel.edit

• fr.lirmm.galiciauml.uml2rcfmodel.editor

If they are not installed or if you are not sure whether they are installed follow the instructionsfor the installation of permant plug-ins in the Installation Manual chapter. (see section A.5)

Figure B.13 shows how transformations and rules could be edited when the appropriate plug-insare installed. For further information about the transformation language please refer to theappropriate sections in the Architecture and Design chapters.

The document containing all the transformation descriptions and rules is called GaliciaUML.uml2rcfand is stored in the root of the fr.lirmm.galiciauml.uml2rcf plug-in. The content of this�le is used by the running refactoring engine to propose the name of the transformations. Inthis section we will add another transformation and see how we can invoke this transforma-tion. To specify a new transformation select New Child->Transformation from the contextmenu of the 'Transformation Document' model element in the uml2rcf editor (editor is shownin Figure B.13). Give a Name for the transformation (e.g. MyNewTransformation) and selectwhich rules from the already de�ned rules should belong to this transformation from the dialogthat appears when changing the rules property in the properties view (dialog with sample setof rules shown in Figure B.14). Do not forget to save the document with the transformationdescriptions when all changes are performed and invoke the rules generator as described in thenext section.

B.2.2 Invoking the Rules Generator

Every time the transformation document has changed the rules should be regenerated so thatthey contain the logic that has been speci�ed. To invoke the Rules Generator the Eclipse Runcon�guration should be used. In contrast to the invocation of the plug-ins the Rules Generator is

131

B USER MANUAL

Figure B.13: Graphical Editor for the Transformation Rules Language

Figure B.14: Select the Rules that should belong to the Transformation

132


Figure B.15: Run the Rules Generator as a Java Application

not an Eclipse plug-in but simple Java Code contained in the fr.lirmm.galiciauml.uml2rcfplug-in (for reasons on this see the Design chapter). The main method is situated in theClass fr.lirmm.galiciauml.uml2rcf.GeneratorEngine. Figure B.15 shows how the 'Run'con�guration should look like.

The result of the invocation of the Rules Generator should look similar to what is shown inFigure B.16. On the console output the names of the generated rules appear. The packagefr.lirmm.galiciauml.uml2rcf.generated now contains the Java �les for the rules. FigureB.16 shows a Java �le that implements the 'InterObjectRule ClassToOperation'.

When now invoking the GaliciaUML plug-ins as an Eclipse Application in an new Eclipseinstance (see section A.4) in the 'UML Refactoring' dialog (see Figure B.17) the new transfor-mation can be selected.

133

B USER MANUAL

Figure B.16: Result of a successful run of the Rules Generator

Figure B.17: The new Transformation is available in the List

134

BIBLIOGRAPHY

Bibliography

[1] Conceptual Structures at Work: 12th International Conference on Conceptual Structures,ICCS 2004, Huntsville, AL, USA, July 19-23, 2004. Proceedings, volume 3127 of LectureNotes in Computer Science. Springer, 2004.

[2] Manfred Broy. Objektorientierte programmierung und softwareentwicklung, eine kritischeeinschätzung. Informatik Spektrum, Feb 2002.

[3] Frank Budinsky. Eclipse Modeling Framework. Prentice Hall International, 2003.

[4] Joel Chechoua. Merlin generator homepage, 2005. http://merlin.sourceforge.net.

[5] Eric Clayberg. Eclipse: Building Commercial-Quality Plug-ins. Addison-Wesley, �rstedition, 2004.

[6] Michel Dao, Marianne Huchard, Mohamed Rouane Hacene, Cyril Roume, and PetkoValtchev. Improving Generalization Level in UML Models Iterative Cross Generalizationin Practice. In ICCS'04 [1], pages 346�360.

[7] DSTC. Mof query / views / transformations. OMG RFP, Jan 2004.

[8] Keith Duddy. Model transformation: A declarative, reusable patterns approach. CRC forEnterprise Distributed Systems (DSTC), 2004.

[9] Jean-Marie Favre. Towards a basic theory to model driven engineering. Université JosephFourier, Grenoble, France, Dec 2004.

[10] Jean-Marie Favre. Towards a megamodel to model software evolution through transfom-rations. University of Grenoble, France, Dec 2004.

[11] Eclipse Foundation. Eclipse corner articles, 2005. http://www.eclipse.org/articles.

[12] Eclipse Foundation. Eclipse modeling framework, 2005. http://www.eclipse.org/emf.

[13] Eclipse Foundation. Eclipse Platform, 2005. http://www.eclipse.org/.

[14] Eclipse Foundation. Uml 2, 2005. http://www.eclipse.org/uml.

[15] Martin Fowler. Refactoring, Improving the Design of Existing Code. Addison-Wesley, 2002.

[16] Erich Gamma. Contributing to Eclipse, Principles Patterns and Plug-ins. Addison-WesleyLongman, �rst edition, 2004.

135

http://merlin.sourceforge.net

http://www.eclipse.org/articles

http://www.eclipse.org/emf

http://www.eclipse.org/

http://www.eclipse.org/uml

BIBLIOGRAPHY

[17] Bernhard Ganter. Applied lattice theory: Formal concept analysis. On-line preprint:http://www.math.tu-dresden.de/ ganter/ns�les/concept.ps, 1998.

[18] Anna Gerber. Transformation, the missing link of mda. CRC for Enterprise DistributedSystems (DSTC), 2002.

[19] FMC Group. FMC homepage, 2005. http://www.fmc.hpi.uni-potsdam.de.

[20] Galicia Research Group. Galicia homepage, 2005. http://galicia.sourceforge.net/.

[21] Object Management Group. MOF Speci�cation, 2004. http://www.omg.org/mof.

[22] Object Management Group. UML 2 Speci�cation, 2004. http://www.omg.org/uml.

[23] OSGi Group. About the OSGi Service Platform, 2005. http://www.osgi.org/.

[24] OSGi Group. Open Services Gateway initiative, 2005. http://www.osgi.org/.

[25] QVT-Merge Group. Revised submission for MOF 2.0 Query/View/Transformation, 2005.ad/2005-03-02.

[26] Steve Holzner. Eclipse. OReilys, �rst edition, 2004.

[27] Marianne Huchard. Formal concept analysis for refactoring tasks. TODO, Feb 200.

[28] Marianne Huchard. Formal concept analysis for refactoring tasks. Feb 2000.

[29] Marianne Huchard, Mohamed Rouane Hacene, Cyril Roume, and Petko Valtchev. Re-lational concept discovery in structured datasets. submitted. Research report versionhttp://www.iro.umontreal.ca/�valtchev/Papiers/valtchev-et-al-DAM-JIM03.pdf.gz.

[30] IBM. IBM Model Transformation Framework Programmer's Guide, 2004. http://www.

omg.org/uml.

[31] Ivan Kurtev. Technological spaces: an initial appraisal. Software Engineering Group(TRESE), University of Twente, The Netherlands, 2004.

[32] Dominik Tornov Martin Fürstenau. Meta-object facility (mof). Seminar Model DrivenArchitecture, Hasso-Plattner-Institut Potsdam, 2005.

[33] Tom Mens. A taxonomy of model transformations. Dagstuhl Seminar on Language Engi-neering Proceedings, 2005.

[34] William Moore. Eclipse Development using the Graphical Editing Framework and theEclipse Modeling Framework. IBM Redbook, 2004.

[35] CWM Partners. Common Warehouse Metamodel Speci�cation, 2001. http://www.omg.

org/technology/cwm/.

[36] M Peltier. Mtrans: A general framework, based on xslt, for model transformations.WTUML01, April 2001.

[37] Cyril Roume. Analyse et restructuration de hiérarchies de classes. Université de Montpel-lier II, Nov 2004.

136

http://www.fmc.hpi.uni-potsdam.de

http://galicia.sourceforge.net/

http://www.omg.org/mof

http://www.omg.org/uml

http://www.osgi.org/

http://www.osgi.org/



http://www.omg.org/technology/cwm/

http://www.omg.org/technology/cwm/

BIBLIOGRAPHY

[38] Ed Seidewitz. What models mean. IEEE Computer Society, Oct 2003.

[39] Peter Tabeling. Softwaresysteme und ihre Modellierung. Springer, 2005.

[40] Peter Tabeling. Systeme und ihre Modellierung, 2005. http://wendtstud.hpi.

uni-potsdam.de.

[41] Markus Völter. openarchitectureware homepage, 2005. http://www.

openarchitectureware.org.

[42] Siegfried Wendt. Nichtphysikalische Grundlagen der Informationstechnik. Springer, 1991.

137

http://wendtstud.hpi.uni-potsdam.de

http://wendtstud.hpi.uni-potsdam.de

http://www.openarchitectureware.org

http://www.openarchitectureware.org

BIBLIOGRAPHY

138