Analysis and Application of Model Transformation Languages for

Technische Universitat Munchen

Fakultat fur Informatik

Bachelorarbeit in Wirtschaftsinformatik

Analysis and Application of ModelTransformation Languages for Generating

Software Maps

Jan Wiegelmann

Technische Universitat Munchen

Fakultat fur Informatik

Bachelorarbeit in Wirtschaftsinformatik

Analysis and Application of ModelTransformation Languages for Generating

Software Maps

Analyse und Anwendung vonModelltransformationssprachen zur

Generierung von Softwarekarten

Author: Jan Wiegelmann

Supervisor: Prof. Dr. Florian Matthes

Advisor: Christian M. Schweda

Submission Date: 12.03.2008

12.03.2008

I assure the single handed composition of this bachelor thesis,

only supported by declared resources.

Abstract

The research project Software Cartography establishes methods and modelsfor documentation, evaluation, and planning of application landscapes byusing Software Maps. These maps are graphical representations of data onthe enterprise architecture. Software maps can be created automatically,because both the documented data and the software maps can be seen asmodels.

This thesis explains, how software maps can be created utilizing a model-to-model transformation language, e.g. Atlas Transformation Language(ATL) or QVT-Relations Language from the Queries/Views/Transforma-tions (QVT) standard. At this stage, a prototype software exists supportingthe automatic generation of software maps based on model transformationsin Java. With this thesis it has been demonstrated, that instead of usingJava, ATL can be used for successfully transforming models according tothe sebis transformation approach [Er06].

The result of this work demonstrates several successfully tranformed soft-ware maps. We have also shown that additional information can be derivedfrom the documented data, e.g. interconnections can be created in thetransformation process. Moreover, the ATL features make it possible toreuse transformations by applying modularization mechanisms. Anothermajor finding of this work is that ATL helps to reduce the complexity ofthe transformation code, which also reduces the effort of developing andmaintaining transformations.

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Short overview on Model Transformations 42.1 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Definition of Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Model Transformation Approach for Generating Software Maps . . . . . . 10

3 Requirements for a Model Transformation Language for Software Car-tography 133.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Model Transformation Languages 214.1 Atlas Transformation Language (ATL) . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.2 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Queries/Views/Transformations (QVT) . . . . . . . . . . . . . . . . . . . . 274.2.1 QVT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.2 Relations Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Comparison of ATL and QVT . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.1 Conformance to functional requirements . . . . . . . . . . . . . . . 304.3.2 Conformance to non-functional requirements . . . . . . . . . . . . . 314.3.3 Performance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Generating Software Maps with ATL 345.1 Cluster Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1 Analyzing the required models . . . . . . . . . . . . . . . . . . . . . 375.1.2 Transforming Semantic Model to Symbolic Model . . . . . . . . . . 38

5.2 Process Support Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.1 Analyzing the required models . . . . . . . . . . . . . . . . . . . . . 415.2.2 Transforming Semantic Model to Symbolic Model . . . . . . . . . . 43

V

5.3 Annotating visualizations with certain aspects . . . . . . . . . . . . . . . . 465.3.1 Cluster Map with maintenance costs . . . . . . . . . . . . . . . . . 475.3.2 Cluster Map with conformance to architectural solutions . . . . . . 505.3.3 Aggregated Cluster Map with Interconnections . . . . . . . . . . . . 53

6 Conclusion and Outlook 586.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.2 Advantages and limitations of ATL . . . . . . . . . . . . . . . . . . . . . . 596.3 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A ATL Transformation Code 61A.1 Cluster Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.2 Process Support Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.3 Aggregated Cluster Map with Interconnections . . . . . . . . . . . . . . . . 68

B QVT Transformation Code 74B.1 Cluster Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

VI

Chapter 1

Introduction

1.1 Motivation

”Application landscapes are complex systems consisting of hundreds or even thousands ofbusiness application systems.” [Er06] They exist in modern enterprises and have devel-oped over time depending on business strategies and business goals. The research projectSoftware Cartography establishes methods and models for documenting, evaluating, andplanning these application landscapes. Furthermore, tools for supporting enterprises inthese tasks are put under research and are further developed.

Central to software cartography are visualizations of the application landscape, calledSoftware Maps, which are defined as follows: ”Software maps are graphical models of theapplication landscapes visualizing different aspects, which correspond to the concerns ofvarious stakeholders and are part of an Enterprise Architecture.” [Er06] These maps aregraphical representations of data about the enterprise architecture. Such data commonlyexists in many enterprises and is documented in tools like Microsoft Access. In additionto that, visualizations are widely used throughout companies, although many of thesediagrams are created manually, e.g. using Microsoft Visio. Such manual creation is bothtime consuming and error prone. Even, if more sophisticated tools for documenting theapplication landscape are used, e.g. the ARIS Toolset or the Corporate Modeler, thecreation of visualizations is only partially automated, retaining a lot of manual work stillto be done by the user. [se08]

Figure 1.1 shows an exemplary visualization of the application landscape, called a pro-cess support map. In detail, it illustrates the dependencies between deployed applicationsystems as rectangles, business processes (making up the x-axis), and organizational units(making up the y-axis), which can be seen as a ternary relationship. For example, thedeployed application system Online Shop supports the business process Distribution andis used at the organizational unit Headquarter. If deployed application system supported

1

more than on business process, as the Inventory Control System does, it would be pos-sible to stretch the corresponding rectangle in x-direction. Consequently, stretching iny-direction would be applicable, if a system was used of more than one organizationalunits (cf. the Monetary Transaction System (Germany)).

Acquisition

Headquarter

SubsidiaryMunich

Subsidiary Hamburg

Subsidiary London

Business Process A

Warehousing Distribution

Inventory Control System (200)

Monetary Transaction

System (Germany) (300)

Warehouse


System (Great Britain) (350)



Price Tag Printing System (Germany/

Munich) (1700)

Price Tag Printing System (Germany/Hamburg) (1720)

Price Tag Printing System (Great Britain) (1750)


Campaign Management

System (1500)

Product Shipment System (Germany)

(400)

Customer Relationship Management

System (2100)Online Shop (100)





Customer Complaint System

(1900)

POS System (Germany/Munich)

(1600)

POS System (Germany/

Hamburg) (1620)

POS System (Great Britain)

(1650)

A

Map Symbols

B Deployed Application System B

Organizational Unit C

Legend


















Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)


(1900)


(1900)



A

Visualization Rules

B

Horizontal Alignment

A B

Ordering

Business Process A is supported by Deployed Application System B and used at Organizational Unit C

Business Process A is a predecessor of B

C C

Figure 1.1: Exemplary process support map [Er06]

As a result of the research project software cartography, which started in 2003, an ap-proach was invented for creating software maps automatically as described in [Er06]. Thetechnology behind this creation process is based on model transformation, because boththe documented data as well as the software maps could be seen as models. The conceptof the model provides an abstract representation of a system omitting irrelevant details.According to the Model-Driven Architecture (MDA), the model transformation generatesa set of target models based on a set of source models. Nowadays, MDA has becomeindispensable in the field of software development, because it helps to improve the creationof software in productivity and quality. The approach for using model transformation ingenerating software maps, therefore tries to leverage the concepts, which have – in theMDA – proven to be useful in software engineering.

1.2 Problem statement

As alluded to above, model transformations can be employed in a tool supporting theautomatical generation of software maps. A prototypic implementation of such a tool has

2

been developed in the research project software cartography [Sc06]. Up to now, all modeltransformations used in the tool have been implemented in Java, because it was initiallyseen as language of choice for implementing the transformation rules due to its Turingcompleteness as well as the fact, that the remainder of the tool is realized in the sameprogramming language. Furthermore, as for the time of the prototypic implementation,no comprehensive set of requirements for a language for defining the transformation ruleswas known. When Java is used for implementing transformations, basic operations such aspattern matching, traversal and querying need to be implemented ”manually” [WV03]. Itis evident that the code is not self explanatory and likely to be complex. This is especiallytrue, when object-oriented metamodels should be accessed (information and visualizationmodels see Chapter 2), which is only possible with additional effort. In conclusion we cansay, that many lines of code have to be implemented. As an example, about 500 lines ofcode (LOC) are needed for the transformations for creating a standard cluster map, shownin Figure 2.5.

As outlined above, Java has shown up to have some drawbacks, especially concerning itsusability and its support for arbitrary object oriented models, which are inherent part ofdocumenting the application landscape. Therefore, Java cannot be considered the languageof choice for defining, which part of the application landscape a user wants to be visualizedand in which way. For this purpose designated model transformation languages, largelyrelying on the declarative programming principle, could perform considerably letter. Withtheir embedded support for accessing arbitrary models and multiple features, e.g. formatching parts of an object-oriented model, they are likely not only to reduce the effortfor defining a model transformation, but also to make the transformation code more easilyand intuitively understandable.

This work focuses on the automatic generation of software maps by using a specific modeltransformation language. Analyzing the required models and metamodels as well as se-lecting a suitable transformation language could be seen as preceding tasks. The mainpart of this work is the implementation and documation of transformations for exemplarysoftware maps such as shown in Figure 1.1. In concluding this work, upcoming problemsand missing concepts arising from the transformation of models with such a transformationlanguage will be shown.

This document is organized as follows. At the beginning, Chapter 2 presents the modelto model transformation approach for generating software maps [Er06], by giving basicinformation about important concepts. Chapter 3 provides the functional requirementsrelated to available approaches for developing model transformations, and non-functionalrequirements focused on properties and contraints of a specific model transformation sys-tem. Chapter 4 introduces the basic elements of the Atlas Transformation Language (ATL)and the Queries/Views/Transformations (QVT) standard, which proposes a set of trans-formation languages. Chapter 5 shows how we apply ATL for generating software maps.Chapter 6 concludes the document with some remarks on the practical applicability ofusing a model transformation languages like ATL.

3

Chapter 2

Short overview on ModelTransformations

In this Chapter, we elaborate on the approach of model transformation, which was firstintroduced by the Object Management Group (OMG) in their model-driven architecture(MDA) [OM03] initiative. After giving the definitions of the important concepts andconstituents of the approach, we relate them to the elements, which are employed in themodel transformation approach for generating software maps [Er06].

2.1 Basic concepts

In general we can define a transformation as follows: ”A [model] transformation is theautomatic generation of a target model from a source model, according to a transforma-tion definition. A transformation definition is a set of transformation rules that togetherdescribe how a model in the source language can be transformed into a model in the targetlanguage.” [KWB03]

Further detailed, the elements of the source model are transformed to target model ele-ments, according to specific transformation rules, which are defined as follows: ”A trans-formation rule is a description of how one or more constructs in the source language canbe transformed into one or more constructs in the target language.” [KWB03]

Figure 2.1 provides a complete overview on how model transformation bridges the gapbetween the source model Ma, which conforms to the source metamodel MMa, and thetarget model Mb, which conforms to the target metamodel MMb. The transformationrules are represented by a transformation model Mt, which is based on a transformationmetamodel MMt. The model MMt could be realize by the features of a programminglanguage like Java, or in our case a model transformation language. All metamodels (MMa,MMb, MMt) could be described conforming to the metametamodel MMM. It provides the

4

Figure 2.1: An overview of model transformation [LI06]

basic concepts for the whole transformation process.

The basic idea of MDA can be shorthanded to creating and using models at different levelsof abstraction, and relating them via a set of transformations. In detail, the MDA-standarddefines an architecture and a set of guidelines for structuring specifications expressed asmodels. According to the MDA approach, these models could be classified as independentof software platforms (= PIM), and as specific to particular platforms (= PSM). In detail,both models can be defined as follows: [OM03]

PIM A platform independent model describes the system, but does not show details ofits use of its platform. It is suited for a particular architectural style, or several ones.

PSM A platform specific model describes, how that system makes use of the chosenplatform. It may thus contain implementation specific information, e.g. programcode.

Figure 2.2 presents the MDA metamodel description. The main concept of MDA is thenotion of mappings. Thereby, it defines a set of rules and techniques used to modify onemodel in order to get another model as following described: [OM03]

PIM to PIM is used when models are enhanced, filtered, or specialized during the de-velopment lifecycle without needing any platform specific information.

PIM to PSM is needed when the PIM is sufficently refined to be projected to the exe-cution infrastructure, based on a specific platform.

PSM to PSM is required for component realization and deployment.

5

PSM to PIM is used for abstracting models of existing implementations in a particulartechnology into a platform independent model.

Figure 2.2: MDA metamodel description [OM03]

2.2 Definition of Model

Central constituent of a model transformation approach is the concept Model, for whichvarious definitions exist. A general one defines a model with three properties as fol-lows [St73]:

Mapping property A model is based on an original.

Reduction property A model only represente a (relevant) selection of the original’sproperties.

Pragmatic property A model needs to be usable in place of the original with respect tosome purpose.

An alternative definition of what a model is, could be: ”A model is a simplification of asystem built with an intended goal in mind. The model should be able to answer questionsin place of the actual system.” [BG01].

6

In the context of software development, a model is always written in a language like UMLor Java. The MDA approach and therefore model transformation systems can only handlemodels which are formalized in a well-defined languages that can be understood by acomputer. To sum this up, we subsequently rely on the following definition for the model:”A model is a description of (part of) a system written in a well-defined language. A well-defined language is a language with well-defined form (syntax), and meaning (semantics),which is suitable for automated interpretation by a computer.” [KWB03]

The MDA approach demands, that a model must be formally specified, for example: Adiagram with boxes, lines and arrows, that does not rely on a definition of the meaningof a box, a line and an arrow, is not a model, it is just an informal diagram. A diagram,that should be a model in the notion of the MDA, must be paired with a definition of themodeling language syntax and semantics. [OM03]

Figure 2.3: Model-Metamodel relationship [LI06]

In the context of model transformations, a model is generally described as conforming toa Metamodel, which itself can be seen as model on another level of abstraction, leadingto definition as follows: ”A metamodel is the explicit specification of an abstraction (asimplification).” [BG01] A metamodel describes the structure and semantics of a specificmodel. Figure 2.3 shows that any model conforms to a specific metamodel. Further, theadditional concept called Metametamodel describes the semantics that is required tospecify the metamodel. [LI06] As a consequence, the metametamodel would itself need anadditional metamodel, but according to several modeling facilities e.g. from the MDA orMOF it acts as its own metamodel. Hence, it is self-defined, describes his own semanticsand conforms to itself.

In summary, it can be said that such a metadata management is based on establishedstandards like the Meta Object Facility MOF [OM06a], an adopted OMG standard. Thestandard enables the development and interoperability of model and metadata processing

7

systems. Next we briefly look at the MOF 2.0 model. It is used to model itself as well asother models and other metamodels such as UML [OM05c]. The MOF 2.0 model consistsof two packages, Essential MOF (EMOF) and Complete MOF (CMOF).

EMOF is a subset of MOF, which can easily be mapped to frameworks in programminglanguages, as JMI [SU02] and XMI [OM05a].

CMOF is built from EMOF and the Core::Constructs of UML 2. It merges packagesadding further these extensions that together define more sophisticated metamodelingcapabilities.

At the time the implementation of the SoCaTool began, no java-based realization of EMOFwas commonly available. Therefore, an alternative metamodeling facility based on anothermetametamodel called Ecore was used. It is based on MOF and UML, and could beintegrated into Java implementations. The Eclipse Modeling Framework (EMF) [Bu04],which is part of the Eclipse platform, implements Ecore. ”Ecore defines the structure ofcore models, which in turn define the structure of the models we use to maintain applicationdata.” [Bu04]

Figure 2.4: The Ecore Kernel [IB08]

Figure 2.4 displayes a simplified Ecore model (cf. [Bu04]) in order to show the most im-portant elements as follows:

EClass models classes themselves. Classes are identified by their name and can containa number of attributes and references. To support inheritance, a class can refer to anumber of other classes as its supertypes.

EAttribute models attributes, the components of an object’s data. They are identifiedby their name and they have a type.

EDataType models the types of attributes, representing basic data types that are e.g.defined in Java, but not in EMF. Data types are also identified by their name.

8

EReference is used in modeling associations between classes; it models one end of suchan association. Like attributes, references are identified by their name and have atype.

The model needs to be taken as a single unit. Further, it is highly self-referential. Whenwe describe EClass, we detail its attributes, which are modeled using EAttribute, andits references, modeled with EReference, even referring indirectly to the attributes ofEReference. [Bu04]

The following section explains which models as well as metamodels are needed for thesebis approach [Er06] addressing the generation of software maps, by using the examplarycluster map, shown in Figure 2.5. This map illustrates, which Deployed Application

System is hosted at which OrganizationalUnit. For example the deployed applicationsystem ”Online Shop (100)” is hosted at the organizational unit ”Munich”. The followingmodels can be seen as representations of the above described definitions.

Headquarter Subsidiary Hamburg Subsidiary LondonSubsidiary Munich

Warehouse

Online Shop (100)

Inventory Control

System (200)

Monetary Transactions

System (Germany)

(300)


System (Great Britain)

(350)

Product Shipment System

(Germany) (400)

Accounting System (500)

Costing System (600)

Human Resources

System (700)

Data Warehouse

(800)

Fleet Management System (900)

Business Traveling

System (1000)

Document Management

System (1100)

Supplier Relationship Management

System (1200)

MIS (1300)

Financial Planning

System (1400)


Munich) (1600)

Campaign Management

System (1500)

POS System (Germany/Hamburg)

(1620)


(1650)

Price Tag Printing System

(Germany/Munich) (1700)


(Germany/Hamburg)

(1720)

Price Tag Printing System (Great Britain)

(1750)

Worktime Management


Worktime Management

(Germany/Hamburg)

(1820)

Worktime Management (Great Britain)

(1850)


System (2100)

Customer Complaint

System (1900)

Customer Satisfaction

Analysis System (2000)

Map Symbols

A

B

C Nesting: Organizational Unit A hosts Deployed Application System B and C

Visualization Rules

Legend

A

B

Organizational Unit A

Deployed Application System B

Figure 2.5: Exemplary cluster map showing which deployed application system is hostedat which organizational unit [Er06]

9

2.3 Model Transformation Approach for Generating

Software Maps

In this section we describe the model transformation approach for generating softwaremaps [Er06]. As before, we start by defining the needed models.

Semantic Model contains the information describing the enterprise architecture, for ex-ample: [Er06] Deployed Application Systems, Organizational Units, Business Pro-cesses, Services, Projects, and relationships between objects (e.g. organizational unithosts deployed application systems).

It could be available as file in different formats like a Microsoft Excel Sheet or a XML file.The semantic model acts as source model (= Ma as from Figure 2.1) for the transformationprocess, which we explain in Section 2.3. It contains all or some above described data,in most cases documented by a responsible person (e.g. a process owner or a systemadministrator) in a company. Figure 2.6 shows parts of an exemplary semantic model asan object diagram. For a better understanding, we shall briefly introduce the respectivemetamodel.

Information Model acts as metamodel for the semantic model. Our examplary infor-mation model in Figure 2.7 represented by a class diagram, consists of:

• the two classes OrganizationalUnit and DeployedApplicationSystem,

• the attribute name for both classes, and

• an association deployedAt.

The information model in Figure 2.7 defines the structure of the respective semantic model,shown in Figure 2.6, or in other words, the semantic model conforms to the informationmodel. Hence, the information model acts as source metamodel (= MMa as from Fig-ure 2.10) for the transformation process. For example, the deployed application system”Online Shop” hosted at the organizational unit ”Munich” can be seen as an instance ofthe respective information model. It describes that a deployed application system belongsto one organizational unit. Furthermore, a organizational unit can host more than onedeployed application system.

Complementing the information centric source models as outlined above, we subsequentlypresent the needed target models.

Symbolic Model contains the information about symbols and their positioning, for ex-ample Map Symbols, e.g. rectangle, ellipse, or chevron, Visual Variables, e.g. back-ground color, border color, or line size, and Visualization Rules, e.g. rectangle A isnested in rectangle B [Er06].

10

Munich : OrganizationalUnitOnline Shop : DeployedApplicationSystem

Monetary Transaction System (Germany) : DeployedApplicationSystem

Accounting System : DeployApplicationSystem

Costing System : DeployApplicationSystem

Hamburg : OrganizationalUnitProduct Shipment System (Germany) : DeployApplicationSystem

Fleet Management System : DeployApplicationSystem

: deployedAt

: deployedAt

: deployedAt

: deployedAt

: deployedAt

: deployedAt

Figure 2.6: Semantic model of the mapin Figure 2.5 [Er06]

DeployableElement

DeployedApplicationSystem

name : String

InfrastructureService

OrganizationalUnit

name : StringdeployedAt

1

- organizationalunit

*

- deployment

Figure 2.7: Information model of themap in Figure 2.5 [Er06]

It could be available as files in formats specifically designed for exchanging data like XMLor XMI. The symbolic model is the target model (= Mb as from Figure 2.1) for the trans-formation process, which we explain in Section 2.3. Depending on the semantic model (assource model) which we discussed above, it represents all or some above described data.Figure 2.8 shows an examplary symbolic model with map symbols like Rectangles as wellas visualization rules like Nesting. For a better understanding, we shall briefly introducethe respective visualization model.

Visualization Model acts as metamodel for the symbolic model. Our examplary visu-alization model in Figure 2.9 represented by a class diagram, consists of:

• the two classes Rectangle and Nesting,

• the attributes x, y, width, height, backgroundColor, borderColor, text

for the class Rectangle, and

• the two associations inner and outer.

Online Shop : Rectangle

Monetary Transaction System (Germany) : Rectangle

Accounting System : Rectangle

Costing System : Rectangle

Product Shipment System (Germany) : Rectangle

Fleet Management System : Rectangle

Munich : Rectangle

Hamburg : Rectangle

: Nesting

: Nesting

: Nesting

: Nesting

: Nesting

: Nesting

: intersecting

: intersecting

: intersecting

: intersecting

: intersecting

: intersecting

: intersected

: intersected

: intersected

: intersected

: intersected

: intersected

Figure 2.8: Symbolic model of the clustermap in Figure 2.5 [Er06]

Rectangle

x : Real

y : Real

width : Real

height : Real

backgorundColor : Color

borderColor : Color

text : String

Nesting

inner

1 *

outer

*1

Figure 2.9: Visualization model of thecluster map in Figure 2.5 [Er06]

The visualization model in Figure 2.9 defines the structure of the respective symbolic model,shown in Figure 2.8, or in other words, the symbolic model conforms to the visualizationmodel. Therefore, the visualization model acts as target metamodel (= MMb as fromFigure 2.1). For example, the rectangle ”Online Shop” is nested in the rectangle called”Munich”.

11

In concluding this, we explain the model transformation approach [Er06]. For generatingsoftware maps, a Semantic Model (= Ma), which conforms to the Information Model (=MMa), is transformed to a Symbolic Model (= Mb), which conforms to the VisualizationModel (= MMb). The Figure 2.10 shows overall transformation process including the com-mon metametamodel Ecore (= MMM) which we introduced above. This is complementedby an informal description (cf. Figure 2.11) of sebis approach for generating softwaremaps [Er06].

The mapping is described in the transformation model Semantic to Symbolic (= Mt)based on the model transformation languages ATL (= MMt), which we introduce in thenext chapter. The aim of this transformation is to generate software maps based on the datadescribing a semantic model for visualizing application landscapes like shown in Figure 2.5.

Figure 2.10: Semantic to symbolic model transformation

Models and Transformations

T f tiSymbolic ModelSemantic Model

Transformation

is instance ofbased on

Information ModelBusinessApplicationVersion

id : IntegerversionId : Integerstatus : StringplannedFrom : Date

Busine ssApplicationid : Integer h i

OrganizationalUnitid : IntegernameEnglish : StringnameGerman String hosted at

Visualization Model

based onis instance of

is instance of

0..*1

BusinessProcessid : IntegernameEnglisch : StringnameGerman : Stringdescription : StringisPrimary : Booleanlev el : Integer

0..1

0..*

paren t0..1superprocess

child

0..*

0..10..1

previous

0..1

predecessornext0..1

Projectid : IntegernameEnglish : StringnameGerman : StringstartDate : DateendDate : Dateselected : Boolean

pplannedTo : DateinDevelopmentFrom : DateinDevelopmentTo : DateinProductionFrom : DateinProductionTo : DateinRetirementFrom : DateinRetirementTo : Date

id : IntegernameEnglish : StringnameGerman : Stringstatus : Enumeration

0..*

0..*

0..*

0..*

supports

0..*

0..*

0..*

0..*

modifies

1 0..*1 0..*has version

SupportRelationship

nameGerman : StringplzPoBoX : Stringcity : Stringcountry : Stringaddress : String

0..*1

hosted at

0..*

1..*

0..*

1..*

used at

is instance of

based on

ABC

based on

Metamodel

based on

e.g. Meta Object Facility (MOF) 2.0

© sebis 1##

Figure 2.11: Approach to Software Map Generation [Er06]

12

Chapter 3

Requirements for a ModelTransformation Language forSoftware Cartography

In this Chapter we elicit functional and non-functional requirements [So04] for a modeltransformation language, which arise in the context of the sebis approach [Er06] for gen-erating software maps as presented in Section 2.1.

3.1 Functional requirements

At first we take a brief look on how the model transformation system should react to par-ticular inputs and how it should behave in particular situations. The following functionalrequirements [So04] relate to available approaches for developing model transformations.

Figure 3.1: Feature diagram representing the top-level areas of variation [Ka90, Cz98]

Figure 3.1 shows a possible taxonomy of features for existing model transformation ap-

13

proaches (cf. [Ka90, Cz98]), we will adhere to in further specifying the functional require-ments specific to our approach. The used terminology is in development, because thenew area of model transformation has many overloaded terms. For detailing the features,we subsequently provide definitions and fine grained feature diagrams [CH06], using thenotational elements as explained in Figure 3.2.

Figure 3.2: Symbols for feature diagrams [CH06]

Specification A dedicated specification mechanism (e.g. precondition, postcondition) isprovided by some model transformation languages. This could best be expressedby the Object Constraint Language (OCL) [OM06b]. Hence, specifications are notexecutable, because they describe relations such as a mapping between source andtarget models.

A dedicated specification mechanism such as OCL is helpful to define [OM06b]:

• invariants on classes and types in the class model,

• type invariants for stereotypes,

• pre- and postconditions on operations and methods,

• constraints on operations, and

• derivation rules for attributes.

Transformation Rules In the most cases, rules have one source and one target do-main. Sometimes they are involved in n domains, also called n-way transforma-tions (e.g. model merging, model weaving). With a domain, the rule has access tothe responsible model, because it has an associated domain language specification(metamodel) including the structures of the model. The specification itself could

14

Figure 3.3: Transformation rules [CH06]

rely on a metametamodel such as the one provided in the Meta Object Facility(MOF) [OM06a].

Computations and constraints on model elements are expressed by executable logic.In detail, these concepts could be described declaratively (e.g. by OCL-queries im-plicitly creating target model elements from the source model) or imperatively (e.g.by Java code directly manipulating the models).

In the context of our approach, we prefer a transformation language including declar-ative features, because declarative programming eases the formulation of mappingsbetween the models. Just in case, if the declarative features are not fully sufficient,we would use imperative programming as a ”fallback”, because it can help to simplifythe specification of mappings.

According to Figure 3.3, transformation rules include more subcategories like syn-tactic separation, multidirectionality, application conditions, intermediate structures,parameterization, reflection, and aspects. These subcategories are not detailed hereas are do not regard them relevant in the conext of the sebis approach [Er06].

Figure 3.4: Location determination [CH06]

Rule Application Strategy A rule application strategy is needed, when there is morethan one match within a given source scope, where the rule could be applied. Thepossible strategies (cf. Figure 3.4) are deterministic (e.g. using a traversal strategylike depth-first search on model elements), non-deterministic (e.g. using a selectedmodel element or all model elements), or interactive. The target point for a ruleis in most cases deterministic. If the source model differs from the target model,traceability links can help to determine the target (Figure 3.10).

The tranformation language should provide deterministic as well as non-deterministicrule application strategies. In most cases, there is more than one match within a given

15

source scope as enterprise architectures are quite complex and varied. The semanticmodel differs from the symbolic model (as introduced in Section 2.3). Consequently,the transformation system should also provide tracing mechanisms.

Figure 3.5: Rule scheduling [CH06]

Rule Scheduling For determining the order, in which rules are applied, the transforma-tion language can provide rule iteration (e.g. recursion, looping, fixpoint iteration)and phasing (e.g. organizing the transformation process in several phases). The formof determining the schedule can be defined implicitly i.e. the scheduling algorithmcannot be controlled by the user, or explicitly i.e. with dedicated constructs to con-trol the execution order. Rule selection can be used by an explicit condition or bya non-deterministic choice. In some cases, a conflict resolution mechanism could beexecuted. Figure 3.5 gives an overview on these features.

For our purpose, rule iteration is useful for developing model transformations, becauseour source model contains self-referential objects like business processes and one-to-many relationships between objects like an organizational unit hosts many applicationsystems. Hence, it should be a basic function of any transformation language usedfor that approach.

Figure 3.6: Rule organization [CH06]

Rule Organization For composing and structuring rules, different mechanisms (cf. Fig-ure 3.6) exist, like modularity mechanisms (e.g. packaging rules into modules, im-porting modules), reuse mechanisms (e.g. inheritance between rules, derivation in,

16

extension in, specialization in, inheritance between modules, and logical composi-tion), and organizational structure (e.g. according to the structure of the sourcelanguage, target language, or independent).

For our purpose, the transformation language should have modularity mechanismsas well as reuse mechanisms. This is convenient because we want to define rules forcalculating metrics (e.g. maintenance cost for applications) and reuse these rulesacross different software maps. The exact type of reuse or modularity mechanism isnevertheless not specifically demanded.

Figure 3.7: Source-Target Relationship [CH06]

Source-Target Relationship The model transformation specifies the way to produce atarget model from a source model. If both models are the same, the in-place updatemechanism will help to update the existing target, seldomly generating a new targetmodel, shown in Figure 3.7. Some transformation systems using nondeterministic se-lection and fixpoint iteration scheduling (cf. Figure 3.5) may restrict in-place updateto pure extension in order to ensure termination.

In-place transformation is not required for our approach, because the semantic modeland the symbolic model are strictly seperated. Hence, we generate a new target (asymbolic model) on the existing source (a semantic model).

Figure 3.8: Incrementality [CH06]

Incrementality The source model is often very large (i.e. application landscapes contain-ing thousands of application systems) and could be affected by changes over time.

17

On the one hand, source incrementality is useful for such large source models, be-cause less source elements need to be repeatedly checked by a model transformation,when the source is modified. On the other hand, target incrementality propagateschanged source elements by updating the existing target elements. The preserva-tion of user edits in the target model is a possible scenario in the context of modelsynchronization, as described in the next Figure 3.8.

For our purpose, both source incrementality as well as target incrementality canbe considered to be useful features, because application landscapes are affected bychanges over time, e.g. the application landscape could exist in a current, planned,and target version.

Figure 3.9: Directionality [CH06]

Directionality Unidirectional transformations (cf. Figure 3.9) generate a target modelbased on a source model in one direction only. If you write two unidirectional trans-formations and execute them in both directions, you will have a bidirectional (mul-tidirectional) transformation. The latter is useful in the context of model synchro-nization. It would only work in a declarative scenario, because it can only be definedmeaningfully when it describes an isomorphic relationship.

At the moment, we focus on transforming models in one direction only, becauseit is sufficient for the model transformation approach as introduced in Section 2.3.The related source and target metamodels describe aspects at different levels of ab-straction. Hence, the metamodels used here are likely to have a non-isomorphicrelationship [VS06].

Tracing Traceability links (cf. Figure 3.10) connect source and target elements as a com-mon form of trace information. They can be described as a runtime footprint of atransformation execution. It is important to retrace the outcome of other transfor-mation rules have computed, because each rule usually addresses only a part of thecomplete transformation process.

The mapping can be achieved by dedicated support from the transformation languageor similarly by using created target elements. Recorded links between the source andtarget elements are useful for performing impact analysis, synchronization betweenmodels, model-based debugging, and determining the target model of a transforma-tion [VS06]. For model transformation languages that have dedicated support forcreating traceability links automatically, it is possible to control [CH06]:

18

Figure 3.10: Tracing [CH06]

• the kind of information recorded,

• the abstraction level of the recorded information,

• the scope for which the information is recorded, and

• the location where the links are stored.

For our purpose, model-based debugging might be very useful in writing transforma-tion code. For example, if the target model shows unexpected results, it is helpful tofollow the execution trace and discover, which rules made the wrong decisions.

3.2 Non-functional requirements

We also identified non-functional requirements to be taken into consideration. More pre-cisely, these requirements define properties and constraints of a specific model transforma-tion system. In some situations process requirements may also be specified. We primarilyfocused on product requirements, which define that the choosen model transformation sys-tem must conform to certain environmental conditions [So04]. The following categories ofnon-functional requirements are relevant:

Implemenation The SoCaTool [Sc06] is based on Eclipse, an open platform for toolintegration. Hence, the model transformation system must be usable from Java,preferably as a plugin for Eclipse. The meta-modeling should be performed by Ecore(cf. Moore, B. et al in [Mo04], Figure 2.4) which supports some high-level conceptsthat are not directly included in Java.

19

Performance The model transformation system should be able to import as well as trans-form huge data sets without taking much time and resources. This is required asaccording to [Er06]: ”Large scale application landscapes contain thousands of appli-cation systems and interconnections between them.” Creating cluster maps containingup to 1000 system should take less than a minute.

Usability The ease of use of the transformation plugin can be supported by syntax high-lightings, and debugging. An online help (e.g. active community) and other docu-mentation should be available.

20

Chapter 4

Model Transformation Languages

This Chapter contains information about the Atlas Transformation Language (ATL) [LI06]and the Queries/Views/Transformations (QVT) [OM05b] standard, which provides a pro-posal for a set of transformation languages. Subsequently, two languages, the ATL and animplementation of the QVT relations package, will be introduced with the focus on modelto model transformations. According to the requirements on those languages in the lastsection, we explain why we decided us to use ATL for the generation of software maps.

4.1 Atlas Transformation Language (ATL)

ATL is developed by ATLAS INRIA & LINA research group as an implementation ofthe OMG QVT [OM05b] standard. It is a hybrid language, combining declarative andimperative programming elements, providing means for defining model to model transfor-mations. Within ATL the components of a transformation program are rules that definehow elements from the source model are matched and later used to create the target modelelements. Beside the rules, all data types and declarative expressions in ATL are basedon the Object Contraint Language (OCL) [OM06b]. The following subsections explaincore concepts of ATL and lay the basics for the implementation of model tranformationsshown in Chapter 5. The core concepts of the ATL Modules and Rules are subsequentlyintroduced and explained.

4.1.1 Module

An ATL module represents the transformation model, consisting of the rules which areneeded to get a target model from a source model. A module can handle more than onesource and target model, but this is not required for our transformation approach. Amodule consists of the following elements:

21

Header The header defines the name of the transformation module. It must be similarto the corresponding file name, e.g. the SourceModel2TargetModel module hasto be defined in the SourceModel2TargetModel.atl file. Furthermore, the headerdeclares symbolic names for the source and target models as well as their respectivemetamodels. An ATL transformation header could look as follows:

module SourceModel2TargetModel;create OUT : TargetMetaModel from IN : SourceMetaModel;

The keyword from defines the normal execution mode (the new target mode as in-troduced in Section 3.1) for different source and target models, which is applicable inmost cases. Alternatively, if the target model and the source model are the same (thein-place update mode as introduced in Section 3.1), the refining execution mode isneeded. This mode is applied, if the keyword refines is used instead of the keywordfrom. In detail, special kind of transformation code is dedicated to the generation ofmodified target elements. Unchanged elements are implicitly copied from the sourceto the target model. For our purpose, the normal execution mode is sufficient, as thesemantic model differs from the symbolic model in various ways e.g. the underlyingmetamodels.

Figure 4.1 shows an exemplary ATL configuration within the Eclipse IDE. In thisconfiguration, the user can choose which actual models (represented as xmi files)or metamodels (represented as ecore files) are mapped to the symbolic names asintroduced in the module definition.

Figure 4.1: Exemplary configuration of a model transformation within ATL

22

Import declaration These declarations allow to import functionalities from other ATLmodules; a typical import should look as follows:

uses library_file_name;

An ATL library contains a set of several helpers that can be triggered from differentmodules. All helpers within a library must be explicitly associated with a givencontext, which specifies the execution environment in which this functionality isdefined. Contrary of a module, the library cannot be executed independently. Hence,it is not associated with any initialization at execution time, which means attributehelpers (see below) cannot be defined within an ATL library. Next, we will introducethe concept of a helper.

Helpers can be seen as independent methods that define a function or an attribute. Theycan be called from different points within an arbitrary transformation module. Forexample, the following functional helper without parameters multiplies an integervalue by two:

helper context Integer def : double() : Integer = self * 2;

For defining a helper, a name and a context type setting the context in which thisattribute is defined have to be specified. Furthermore, a return value type, an ex-pression that represents the computation rule of the helper, and an optional set ofparameters have to be provided.

The following helper looks similar to the one above, but in ATL this represents anattribute helper, which is a special kind of helper. The functional helper calculatesthe expression each time when it is called, the return value of an attribute helper iscomputed only once, when the value is required for the first time [LI06].

helper context Integer def : double : Integer = self * 2;

Rules can define the way how a target model will be created based on a source model. Indetail, we introduce ATL rules in Section 4.1.2.

4.1.2 Rules

ATL provides two different programming modes. Firstly, the declarative programmingmode, which is represented by matched rules. And secondly, the imperative one, whichutilizes called rules. Instead of a matched rule, which executes only if a pattern matchessuccessfully, the called rule is not triggered via a match found, but can be called fromanother rule.

23

Matched rules These rules help to specify for which kind of source elements specific tar-get elements must be created, and how these target elements have to be initialized.The matched rule is identified by the keyword rule and a unique name. It containstwo mandatory patterns (source and target), and two optional sections (local vari-ables and imperative). The local variables will only be available during the localexecution of the current rule.

We will have a closer look at the source pattern, which is preceded by the keywordfrom. It is possible to specify a model element variable, that conforms to the typeof source elements, the rule has to match, as this type corresponds to a class of therespective source metamodel. For each source model element, that conforms to thismatching type, the rule generates a target model element. By using an optionalcondition, it is possible to filter out certain elements from the source model.

The target pattern is defined after the keyword to. It generates a distinct target modelelement for each source element when the source pattern of the rule is matched. Eachtarget element has to correspond to a class from the target metamodel.

In closing, we can say that the optional imperative section, which is introduced by thekeyword do, enables us write imperative code that will be executed after the initialstep of the target element generation by the rule. The following example illustratesa simplified matched rule.

rule Author {froma : MMAuthor!Author

top : MMPerson!Person (

name <- a.name,surname <- a.surname

)}

It contains one source pattern called a:MMAuthor!Author and one target patterncalled p:MMPerson!Person. For each Author instance within the source model thatconforms to the class Author source metamodel MMAuthor the rule will create aPerson instance in the target model that conforms to the corresponding class fromthe target metamodel called MMPerson.

Until now we have seen the usage of declarative standard rules in ATL. There aretwo more kinds of declarative rules, which are called [JK05]:

• Lazy rules, which are triggered by other rules. Each time when a match issuccessfully performed, the lazy rule will be applied. It could be applied multipletimes on a single match, each time e.g. creating a new set of target elements.

• Unique lazy rules, which are also triggered by other rules, but they are appliedonly once for a given match. If the unique lazy rule triggers more than one

24

time on the same match, it will only refer to an existing target element by notcreating a new target element.

Next, we will see how the called rule differs from the matched rule.

Called rules provide facilities for imperative programming and can be seen as specialkind of helpers with parameters. Called rules can only be called from imperativecode, a matched rule or another called rule. The called rule is identified by thekeyword rule and its unique name. It does not have a source pattern, but it canhave an optional local variables section.

The target pattern of called rules is defined similar to the one of matched rules,including the same keyword to. The target model elements have to be based on acombination of local variables, parameters, and module attributes. The followingexample illustrates the structure of a simple called rule:

rule NewPerson (na: String, s_na: String) {top : MMPerson!Person (

name <- na)

do {p.surname <- s_na

}}

This rule creates target model elements based on the given parameters na:String

and s na:String. The rule has one target pattern called p:MMPerson!Person andone imperative code section, defined by the keyword do. Each time the rule is called,a Person instance will be created, which conforms to the corresponding class fromthe target metamodel called MMPerson. Furthermore, the name attribute will beinitialized by the target pattern. The imperative code section is executed after theinitialization of the target pattern, and sets the surname attribute of the generatedPerson model element to the value s na.

Rule inheritance ATL provides specific language features like rule inheritence, whichare useful when several rules share a common part. Furthermore, the reuse of codefor a rule is applicable in the context of polymorphic rules. Rule inheritance is acompiler-feature of ATL 2006, not one of the corresponding virtual machine, whichmeans that only ”implementation” inheritance is supported. As a consequence, partsof the rule definiton code are reused in the inheriting rule, although both rules, whichmight be considered objects in terms of the transformation model, do not supportexchangeability, as ”full-scale” inheritance would demand. For activating rule inher-itance in ATL, the transformation code requires the --@atlcompiler statement atthe beginning.

25

rule A {from [fromA]to [toA]

}

rule B extends A {from [fromB]to [toB]

}

The rule B inherits from rule A, by using the keyword extends. It means that, ruleA is the parent rule and B is the child rule, or also called subrule. Thereof, we cansay that rule B matches a subset of what rule A matches, by imposing followingcontraints:

• Both rules must have the same number of elements.

• Each child source element must correspond to a unique parent source element.

• Each child element type must conform to a type of corresponding parent element.

Otherwise rule B specializes target elements of rule A, by the following possibilities:

• Target elements can be added in child rule.

• Child target elements with corresponding parent elements can have a differenttype, more bindings, and redefine bindings.

The parent rule may be abstract, by using as prefix the keyword abstract. In thiscase the parent rule A cannot be applied directly, only the subrules B and C.

abstract rule A {from [fromA]to [toA]

}

rule B extends A {from [fromB]to [toB]

}

rule C extends A {from [fromC]to [toC]

}

26

4.2 Queries/Views/Transformations (QVT)

The Queries/Views/Transformations (QVT) [OM05b] specification is developed by theObject Management Group (OMG) as a standard for model transformations in an object-oriented environment. According to OMG, the standard contains a language dimension,which consists of the three named language levels: Core, Relations, and Operational. In-stead of ATL, which combines declarative and imperative programming features into onehybrid language, the QVT standard and its languages can be separated into a declarativeand imperative part. The following sections give an overview on the architecture of QVT.According to the requirements in Chapter 3, we take a detailed look at one declarativepart called Relations Language.

4.2.1 QVT Architecture

Figure 4.2 shows the QVT architecture. The declarative part is divided into two layers:

• The Relations metamodel and language is user friendly and supports object patternmatching, template creation, and traces between model elements implicitly.

• The Core language is equally powerful to the relations language. It is specified usingextensions to EMOF and OCL. Further, traces between model elements are explicitlydefined models according to MOF [OM06a].

Figure 4.2: QVT architecture according to [OM05b]

Furthermore, the following two mechanisms are responsible for invoking imperative imple-mentations from relations or core language. MOF operations make it possible to plug-inany implementation of a MOF operation with the same signature. It allows to use complexalgorithms in any programming language with MOF bindings, the use of domain specificlibraries, and thereby hide some implementations of the transformation.

• Operational Mappings, which provide imperative implementations and use the sametrace models as the relations language. They are useful to implement relations when

27

it is difficult to provide a purely declarative specification of how a relation is to bepopulated.

• The Black Box implementation needs to realize an explicit relation, which not de-pends on the relation language. Further, traces between model elements will behandled by the operation implementation.

For a better understanding, an analogy to the Java is useful. In this case, the Core languageplaying the role of Java Byte Code. Thereof, the semantics of the core language matchesthe behavior of the Java Virtual Machine. The RelationsToCore Transformation can beseen as the the Java Compiler. Furthermore, the Relations language represents the Javalanguage. Finally, an invocation of Operational mappings or Black Box implementationscan be seen as making a Java Native Interface (JNI) call.

According to the OMG specification [OM05b], both the relations as well as core languagesupport the following execution scenarios:

• Check-only transformations to verify that models are related in a specified way.

• Single direction and bi-directional transformations are supported.

• The ability to establish relationships between existing models, whether developedmanually, or by some other tool or mechanism.

• Incremental updates (in any direction) when one related model is changed after aninitial execution.

• The ability to create as well as delete objects and values, while also being able tospecify which objects and values must not be modified.

4.2.2 Relations Language

In this Section, we introduce the Relations Language of QVT, which specifies the rela-tionship between models. Thereby, the following examples are parts of the transformationcode for generating a cluster map, as it is shown in Appendix B.1. The source and targetmodels are named, and the types of elements, they can contain, are restricted to thosefrom respective metamodels. The following example shows a QVT declaration, which isnamed ClusterMap.

transformation ClusterMap(semantic:SoCaStore2008, symbolic:SoCaVisualizationModel)

The semantic identifier represents a model, which is based on the respective metamodelcalled SoCaStore2008. Similarly, the symbolic identifier represents the second model, which

28

Listing 4.1: Top relation ApplicationSeparationLayer1 top relation ApplicationSeparationLayer {2 app : String;3 org : String;4 checkonly domain semantic source : SoCaStore2008 :: SemanticModel {5 informationObject = application : SoCaStore2008 ::

DeployedApplicationSystem {6 name = app ,7 deploymentUnit = orgunit : SoCaStore2008 :: OrganizationalUnit {8 name = org}9 }

10 };11 enforce domain symbolic separationApp : ConstraintVisualizationRules

:: Separation {12 separated = rectangleApp : MapSymbols :: Rectangle {13 nestedRule = nesting : ConstraintVisualizationRules :: Nesting {},14 text = ftApp : Types :: FormattedText {15 value = app16 },17 fillColor = fcApp : Types ::Color {18 blue = 255, green = 255, red = 25519 },20 borderColor = bc : Types ::Color {21 blue = 1, green = 1, red = 122 }23 }24 };

Listing 4.1: Top relation ApplicationSeparationLayer

is based on the metamodel called SoCaVisualizationModel. The transformation will beinvoked in a particular direction by selecting one identifier as the target. As such, weenforce an unidirectional transformation, whereat the identifier named symbolic acts astarget. Alongside this examplary transformation, we subsequently introduce the basicconcepts of the relations language.

According to Listing 4.1, the relation is required for the declaration of constraints thatmust be satisfied by elements of the related models. A relation contains two or moredomains, indicated by using the keyword domain. A domain represents a typed variablethat can be matched in a model of a given model type. The domain can have the prefixcheckonly, which tests to see, if there exists a valid match in the relevant model thatsatisfies the relationship. By using the prefix enforce, the relation modifies the targetmodel by creating, updating, or deleting elements within the target model. If the relationhas the prefix keyword top, it will execute automatically, in the absence of this keyword,the respective relation is only invoked directly or transitively from another relation.

29

4.3 Comparison of ATL and QVT

This Section compares both ATL as well as the QVT relations language based on functionaland non-functional requirements, as introduced in Chapter 3. Finally, we explain how thedecision to use ATL instead of a QVT implementation was made, and for what reasons.

4.3.1 Conformance to functional requirements

According to Section 3.1 the following table compares ATL and QVT in order to thefulfillment of functional requirements.

Functional Requirements ATL QVT

Specification Yes Yes

Transformation Rules Hybrid Declarative/Imperative Language

Rule Application Strategy Deterministic Deterministic

Rule Scheduling Implicit Implicit

Rule Organization Library Library

Source-Target Relationship No No

Incrementality Explicit Implicit

Directionality Unidirectional Bidirectional

Tracing Internal External

Both languages fulfill the functional requirements to varying degrees. Nevertheless, thelanguages are obviously of similar functionality, maybe a consequence of ATL having beendeveloped in response to the first QVT standard. Nevertheless, the hybrid character ofATL makes it more comfortable to combine declarative and imperative features. In contrastto ATL, the Request for Proposal (RFP) of the QVT language separates declarative andimperative features in two languages. On the other side, the QVT language provides bidi-rectional transformations, which could be useful in the context of model synchronization.In respect to the tracing mechanism, the QVT language creates a dedicated transforma-tion model and metamodel. Figure 4.3 illustrates the transformation metamodel, whichpresents the relation statements. Moreover, the attributes within the relations show theconcepts, which are used from the source and target metamodels.

30

Figure 4.3: Transformation Metamodel of the Cluster Map with QVT

4.3.2 Conformance to non-functional requirements

According to Section 3.2, we compared ATL and a publicly available implementation ofQVT in respect to the fulfillment of non-functional requirements.

ATL within the Eclipse Modeling Project

Implementation An existing Integrated Development Environment (IDE) has been de-veloped as extension to the Eclipse Modeling Project (M2M) [Fo08]. It is releasedunder the Eclipse Public License v1.0, which is an open source license. This IDEprovides some support for developing transformations like syntax highlighting anddebugging [LI06].

Usability There exists an active ATL community in the Eclipse Modeling Project. More-over, the website provides approx. 100 model transformation scenarios, which arevery helpful for beginners. The documentation explains the language in respect of

31

its syntax and semantic.

QVT implemented as rich client platform named mediniQVT

Implementation At the moment, there is still no open source implementation of theQVT-Relations language. The company ikv++ technologies AG (from Germany)developed a QVT-Relations implementation representing the product named me-diniQVT. It is free for non-commercial use. It is an eclipse based rich client platformapplication including an editor with code assistant and a debugger.

Usability There is currently no active community of QVT users. Further, only a fewexamples are available. The QVT standard explains the relations language in respectof his syntax and semantic, but a dedicated documentation is not available.

4.3.3 Performance tests

This section shows the execution of a non-regression performance tests on the ATL (withinthe Eclipse Modeling Project) and QVT (implemented as rich client platform named me-diniQVT) implementation.

Number of applications ATL time QVT time

100 2s 2s

200 4s 2s

500 10s 11s

1000 37s 40s

2000 2m 21s 2m 30s

5000 14m 26s -

10000 1h 18m -

Test Design We tested both implementations in respect to the performance of generatinga cluster map based on different data sets containing 100 up to 10000 elements ofdeployed application systems. Moreover, the source model includes 10 elements oforganizational units. The used transformation code for ATL is listed in Appendix A.1,for QVT in Appendix B.1.

Results The ATL implementation takes virtualy the same time as the QVT implementa-tion. According to Table 4.3.3, we can say that both languages run the test till 1000elments within the source model in an adequate time. We stopped the QVT test at

32

2000 elements, because the transformation process raises errors. This is known byikv++ technologies AG, according to the email correspondence with developers fromikv++ [Ei08].

Configuration Notes The non-regression tests realized on 19/02/2008 with the followingconfiguration: Intel Pentium M 1.5 GHz, 1 GB RAM, Windows 2000 SP4, JRE 1.6.0.

33

Chapter 5

Generating Software Maps with ATL

This Chapter presents exemplary transformations for generating software maps with ATL.The used software maps are taken from the Enterprise Architecture Management ToolSurvey 2008 (EAMTS2008) [se08], which evaluates the products of major players in themarket of enterprise architecture management tools. The information models presentedwith the different visualizations are excerpts of the information model of EAMTS2008reduced to only the necessary concepts. The different kinds of software maps in this chapterare presented in different sections, each section structured as follows. First, the requiredmodels and metamodels of the transformation are introduced. Secondly, important stepswithin the transformation process are explained in detail alongside the transformationcode.

Prior to the detailed decription of the transformation, we take a look on recurring elementsin the transformation process such as follows.

Primitive Type Short Description

Color Primitive type containing the RGB values

FormattedText Primitive type containing text as string

According to Section 2.3, the visualization model (as target metamodel) contains elemen-tary types like Color and FormattedText. These can be seen as primitive types, althoughthey are represented in the metamodel as classes. At instance level, both may belong tomore than one map symbol instance.

Attribute Helper Short Description

setColorTuple Saving RGB color values summarized in one tuple

The attribute helper setColorTuple shown in Listing 5.1 is reused throughout several trans-formations. It helps to save RGB color values summarized in one tuple, e.g. (255,255,255)for white.

34

Listing 5.1: Attribute helper setColorTuple1 helper def : setColorTuple(b : Integer , g : Integer , r : Integer) :

TupleType(blue : Integer , green : Integer , red : Integer) = Tuple{blue = b, green = g, red = r};

Listing 5.1: Attribute helper setColorTuple

Listing 5.2: Unique lazy rule setColor1 unique lazy rule setColor {2 from source : TupleType(blue : Integer , green : Integer , red : Integer

)3 to bcolor : SoCaVisualizationModel!Color (4 blue <- source.blue ,5 green <- source.green ,6 red <- source.red)7 }

Listing 5.2: Unique lazy rule setColor

Transformation Rule Short Description

setColor Creating only one Color instance, if the rule will be trig-gered several times

The rule setColor, shown in Listing 5.2, uses the above described attribute helper setCol-orTuple for creating color elements in the target model. If it is triggered several times withthe same RGB values, the unique lazy rule will create only one Color instance.

Additional Concept Short Description

VisibilityLayer Containing the base map and additional layers of filters

LegendElement Concept for describing the the respective legend of the map

Several aspects concerning the application landscape can be filtered by using the layeringprinciple, as shown in Figure 5.1. The visualization model represents this concept by usingVisibilityLayer instances. Figure 5.2 shows a cluster map containing the Base Map layer.Furthermore, the cluster map has an Application layer having a reference to all instances ofsymbols representing application systems. The Interconnection layer contains connectionsbetween deployed application systems, which can be displayed or hidden. At the top, aMeasures layer can visualize metrics for application systems like maintenance costs.

The SoCaTool, which generates and visualizes such software maps, needs additional infor-mation about the legend, which is contained in the LegendElement instances. For example,the legend at the bottom of Figure 5.2 shows the used map symbols.

Below, recurring concepts used throughout the different transformation modules are in-

35

Base Map

Applications

Interconnections

Measures

Figure 5.1: Exemplary cluster map

troduced, further detailing their ATL specific syntax and semantics. In ATL the reservedkeyword self is used to refer to the contextual instance. An operation can be called by thesyntax following the classical dot notation, e.g. self.operationName(parameters). Accord-ing to the ATL manual [LI06], we need some recurring operations that are common to allexisting data types as follows:

ATL Operation Short Description

oclType() Returning the oclType of self

oclIsKindOf(t:oclType) Returning a boolean value stating whether self is an eitheran instance of t or of one of its subtypes

oclIsTypeOf(t:oclType) Returning a boolean value stating whether self is an in-stance of t

oclIsUndefined() Returning a boolean value stating whether self is undefined

allInstances() Returning a set containing all the currently existing in-stances of the type self

5.1 Cluster Map

The first examplary software map is called Cluster Map, as it is shown in Figure 5.2.The usage of this map is that it illustrates, which DeployedApplicationSystem is hosted atwhich OrganizationalUnit by using the concept of Nesting, which is a visualization rule.For example, the rectangle labeled Online Shop(100) is nested into the rectangle labeledMunich expressing that the DeployedApplicationSystem ”Online Shop” is hosted at theOrganizationalUnit ”Munich”.

36


Warehouse

Online Shop (100)

Inventory Control

System (200)


System (Germany)

(300)



(350)


(Germany) (400)



Human Resources

System (700)

Data Warehouse

(800)


Business Traveling

System (1000)

Document Management

System (1100)


System (1200)

MIS (1300)

Financial Planning

System (1400)


Munich) (1600)

Campaign Management

System (1500)


(1620)


(1650)




(Germany/Hamburg)

(1720)


(1750)

Worktime Management


Worktime Management

(Germany/Hamburg)

(1820)


(1850)


System (2100)

Customer Complaint

System (1900)



Map Symbols

A

B


Visualization Rules

Legend

A

B



Figure 5.2: Exemplary cluster map

5.1.1 Analyzing the required models

The required source and target metamodels according to Chapter 2 are described as follows.

Information Model The information model acts as source metamodel, as shown in Fig-ure 5.31. Both the OrganizationalUnit as well as the DeployableElement are theessential classes for creating the cluster map. The transformation code needs to con-sider that both DeployedApplicationSystem as well as InfrastructureService inheritfrom DeployableElement. According to the association ends, the OrganizationalUnitcan host more than one DeployedApplicationSystem.

Visualization Model The visualization model acts as target metamodel. The graphicalconcepts behind the cluster map are represented by classes of Rectangle, Nesting, andSeparation, as it shown in Figure 5.42.

1Therein, some attributes, e.g. the id attributes of the classes, are omitted for reasons of clarity.2Again, the id attribute has been omitted.

37

DeployableElement


name : String

InfrastructureService

OrganizationalUnit

name : StringdeployedAt

1


*

- deployment

Figure 5.3: Information model for the cluster map

Rectangle

text : FormattedTextborderColor : ColorfillColor : Color

Nesting

Separation separating 2..*

- separated

*

- separationRule

nesting

*- nestingRule

1- nestingSymbol

nested

*- nestedRule

1- nestedSymbol

Figure 5.4: Extract of the visualization model for the cluster map

According to the legend in Figure 5.2, a Rectangle can appear in different kinds of styles, i.e.the DeployedApplicationSystem has a white background color and the OrganizationalUnithas a gray background color. The rectangle represents a map symbol, which contains alabel acting as string text (or called FormattedText).

The visual concept of Nesting makes it possible that the rectangle represented a De-ployedApplicationSystem is nested into another rectangle represented an OrganizationalU-nit. For example, the rectangle labeled Online Shop(100) is nested into the rectangle la-beled Munich. Map symbols which are referenced by a Separation instance are demandednot to overlap at all.

5.1.2 Transforming Semantic Model to Symbolic Model

This Section explains important steps within the transformation process. Both followingrules present a subset of the complete ATL code (cf. Appendix A.1) for generating a clustermap like in Figure 5.2.

38

Map Symbol Short Description Symbol

Rectangle Symbol representing a rectangular shape

Visualization Rule Short Description Symbol

Nesting Rectangle A is nested into rectangle B

A B

A

BA

BA

B

A

A B

B

Separation Rectangle A does not overlap with rectangle B

A B

A

BA

BA

B

A

A B

B

According to Listing 5.3 at line 1, the ATL module ClusterMapTransformer is similar to thefilename named ClusterMapTransformer.atl. Furthermore at line 2, the target metamodelis called SoCaVisualizationModel, and the source metamodel is called SoCaStore2008.

The first part of the Listing 5.3 shows the source pattern (at lines 5-6). Each Organiza-tionalUnit instance, which has at least one DeployedApplicationSystem instance associatedvia the deployment association, is matched. The target pattern (at lines 7-19) generatesfor each source pattern element a Rectangle instance with some attributes set, e.g. thetext attribute (at line 8) is set to the respective FormattedText instance (at lines 14-15). The nestingRule reference (at line 9) matches each deployment element, which is aDeployedApplicationSystem and creates a nesting instance, which references both the Or-ganizationalUnit as well as the DeployedApplicationSystem (at lines 16-19). The fillColorattribute (at line 10) is set to the fill color with the setColorTuple attribute helper throughthe unique lazy rule called setColor, shown in Listing 5.2. The last attribute borderColor(at line 11) is set to the border color.

The separationRule reference (at line 12) is set to the Separation instance including asequence of organizational units, which triggers the unique lazy rule named separationOr-ganizationalUnit. The map symbols, which are referenced by a Separation instance do notoverlap at all. Further, the rulingLayer reference (at line 13) is set to the VisibilityLayerinstance, which triggers the unique lazy rule named layerOrganizationalUnit. A sequence oforganizational units is given as parameter, which means that all included instances shouldbe contained in one layer.

Listing 5.3: Rule OrganizationalUnit2Rectangle1 module ClusterMapTransformer;2 create OUT : SoCaVisualizationModel from IN : SoCaStore2008;3

4 rule OrganizationalUnit2Rectangle {5 from source : SoCaStore2008!OrganizationalUnit (6 source.deployment -> select(e | e.oclIsKindOf(SoCaStore2008!

DeployedApplicationSystem)).size() > 0 )7 to target : SoCaVisualizationModel!Rectangle (8 text <- ftext ,9 nestingRule <- nesting ,

39

10 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,255, 255)),

11 borderColor <- thisModule.setColor(thisModule.setColorTuple (1,1, 1)),

12 separationRule <- thisModule.separationOrganizationalUnit(source.listOrganizationalUnit ()),

13 rulingLayer <- thisModule.layerOrganizationalUnit(source.listOrganizationalUnit ())),

14 ftext : SoCaVisualizationModel!FormattedText (15 value <- source.name),16 nesting : distinct SoCaVisualizationModel!Nesting foreach(obj in

source.deployment -> select(e | e.oclIsKindOf(SoCaStore2008!DeployedApplicationSystem))) (

17 nestingSymbol <- source ,18 nestedSymbol <- obj)19 }20

21 unique lazy rule separationOrganizationalUnit {22 from source : SoCaStore2008!OrganizationalUnit23 to separation : SoCaVisualizationModel!Separation (24 separated <- source)25 }26

27 unique lazy rule layerOrganizationalUnit {28 from source : SoCaStore2008!OrganizationalUnit29 to layer : SoCaVisualizationModel!VisibilityLayer (30 name <- ’Organizational Units ’,31 visible <- true ,32 layeredSymbol <- source)33 }

Listing 5.3: Rule OrganizationalUnit2Rectangle

5.2 Process Support Map

This Section describes the generation of the Process Support Map, as shown in Figure 5.5.It visualizes, which DeployedApplicationSystem is hosted at which OrganizationalUnit andsupports there at least one BusinessProcess. This ternary relationship is represented by us-ing the visual concept of alignment between different map symbols, in respect to their x andy-coordinates. For example, the rectangles labeled Inventory Control System (represent-ing an application system) are aligned with the chevron labeled Acquisition (representing abusiness process) in respect to the x-coordinate, which means that the respective applica-tion system supports the respective business process. Furthermore, the multiple rectanglesrepresenting the Inventory Control System are each aligned with one of the five organi-zational units in respect to the y-coordinate, which means that the application system isused at all these organizational units.

40

Acquisition

Headquarter

SubsidiaryMunich

Subsidiary Hamburg

Subsidiary London

Business Process A

Warehousing Distribution




Warehouse






Munich) (1700)




Campaign Management

System (1500)


(400)


System (2100)Online Shop (100)






(1900)


(1600)


Hamburg) (1620)


(1650)

A

Map Symbols

B Deployed Application System B

Organizational Unit C

Legend


















Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)


(1900)


(1900)



A

Visualization Rules

B

Horizontal Alignment

A B

Ordering

Business Process A is supported by Deployed Application System B and used at Organizational Unit C

Business Process A is a predecessor of B

C C

Figure 5.5: Exemplary process support map

5.2.1 Analyzing the required models


Information Model Figure 5.63 illustrates the information model acting as source meta-model. The central class of the metamodel is called SupportRelationship connectingas a ternary relationship the classes SupportProvider, OrganizationalUnit, and Busi-nessProcess. Hence, the support relationship means that a business process is sup-ported by a support provider and used at an organizational unit. The transformationcode for the process support map needs to consider that both DeployedApplication-System as well as Service are inherited from the SupportProvider, as only applicationsytems should be depicted in the visualization. The self-referential association namedordering has both association ends pre as well as post at the BusinessProcess class.This can be used to order the business process instances into a sequence which issubsequently graphically represented using the visualization rule XSequence, whichwe will explain next.

Visualization Model The visualization model acts as target metamodel. The graphicalconcepts behind the process support map are represented by appropriate subclassesof Map Symbol, Visualization Rule, and Visualization Variable.

41

OrganizationalUnit

name : String

BusinessProcess

name : String


name : String

SupportRelationship SupportProvider

Service

supportAt

* - supports

1 - organizationalunit

ordering0..1 - pre

0..1

- post

supportOf

1 - businessprocess

* - supports

supportBy*

- supports

1

- provider

Figure 5.6: Information model for the process support map

Map Symbol Short Description Symbol

Rectangle Symbol representing a rectangular shape

Chevron Symbol representing a special kind of polygon

Within the process support map, a Rectangle represents a deployed application systemhaving a white background color with a black frame. A rectangle represents a organiza-tional unit having a grey background color with a black frame. The rectangle is labeledwith the name attribute of the application system. Moreover, the Chevron stands for abusiness process which has a gray background color.

Figure 5.74 shows the visualization model containing the visualization rule, named Ful-lXSpecificIntersection, which demands that both referenced map symbols intersect verti-cally. Applying on the process support map, this is used by the Organizational Unit andthe DeployedApplicationSystem, which share the same x-coordinates. FullYSpecificInter-section similarly requires that both referenced map symbols intersect horizontally. Hence,the map symbol instance representing a BusinessProcess shares its y-coordinates with the

3The id attribute has been omitted.4The id attribute has been omitted.

42

Visualization Rule Short Description Symbol

XSequence Chevron A is to the left of chevron B

FullXSpecificIntersection Chevron A and B align to the same x coordinate A B

A

BA

BA

B

A

A B

BYSequence Rectangle A is positioned under the chevron B

FullYSpecificIntersection Rectangles A and Chevron B align to the same ycoordinate

A B

A

BA

BA

B

A

A B

B

Separation Rectangle A does not overlap with rectangle B

A B

A

BA

BA

B

A

A B

B

DeployedApplicationSystem. Another visualization rule, called XSequence, holds a set ofreferenced map symbols supplied by the ruledXSequence association, which are positionedfrom left to right within the sequence. Similarly, the YSequence contains all referenced mapsymbols, which are supplied by the ruledYSequence association. These symbols are po-sitioned from top to bottom within the sequence. The last visualization rule means thatmap symbols, which are referenced by a Separation instance, do not overlap at all.

5.2.2 Transforming Semantic Model to Symbolic Model

This Section shows important steps within the transformation for generating a processsupport map. Both following helpers and rules present a subset of the complete ATLcode for generating a process support map like in Figure 5.5, which is included in theAppendix A.2.

At the top of the process support map, business processes are aligned in an ordered se-quence. For creating this sequence, we need the recursive helper called allBusinessPro-cessesRec, which is triggered by the functional helper allBusinessProcesses(). It uses twoparameters, a business process instance as well as an empty sequence. For the given busi-ness process instance, the recursive helper takes the post reference, which also provide abusiness process instance, and appends it to the given sequence. The parameters for thenext recursive call are the post reference instance of the given business process and the newordered sequence. This call is only executed, if the post reference of the current processhas a value assigned. Otherwise, the recursion terminates.

The functional helper is called by an imperative code section, as it shown in Listing 5.5at lines 16-19, if the respective rule matches a business process instance, which has anundefined pre reference, or in other words, it takes the first business process. In casemultiple ”first” processes exist, e.g. due to a model inconsistency, the rule is also likely toproduce a non-consistent symbolic model. Resulting business processes are appended to thesequence called listBusinessProcess, which is defined by the helper in line 1 at Listing 5.4.

43

MapSymbol


FullYSpecificIntersectionFullXSpecificIntersectionXSequence YSequence

Rectangle Chevron

VisualizationRuleVisualizationElement

xsequencing

* - xsequenceRule

2..*

- ruledXSequence

ysequencing

* - ysequenceRule

2..*

- ruledYSequencexintersected

*- xIntersectedRule

1

- xIntersectedSymbol

xintersecting

*- xIntersectingRule

1

- xIntersectingSymbol

yintersecting

*- yIntersectingRule

1

- yIntersectingSymbol

yintersected

*- yIntersectedRule

1

- yIntersectedSymbol

ruling

*

- ruled

*

- rules

Figure 5.7: Exemplary visualization model of the process support map

Listing 5.4: Helpers ordering business processes in a sequence1 helper def : listBusinessProcess : Sequence(SoCaStore2008!

BusinessProcess) = Sequence {};2

3 helper context SoCaStore2008!BusinessProcess4 def: allBusinessProcesses () : Sequence(SoCaStore2008!BusinessProcess)

= self.allBusinessProcessesRec(self , Sequence {});5

6 helper context SoCaStore2008!BusinessProcess7 def: allBusinessProcessesRec(s : SoCaStore2008!BusinessProcess , res :

Sequence(SoCaStore2008!BusinessProcess)) :8 Sequence(SoCaStore2008!BusinessProcess) =9 if s.post.oclIsUndefined () then

10 res ->append(s)11 else12 self.allBusinessProcessesRec(s.post , res ->append(s))13 endif;

Listing 5.4: Helpers ordering business processes in a sequence

According to Listing 5.5, the SupportRelationship rule is matched by the source patternfrom lines 3-8 and target pattern is lines 9-15, including an imperative code section fromlines 16-19. The source pattern matches relevant SupportRelationship instances from thesource model fulfilling the conditions at lines 4-8. Hence, the SupportRelationship instancerequires valid references to an Organizational Unit, a Business Process, and a Support-Provider. At line 8, the rule matches only DeployedApplicationSystem instances inheritedfrom the SupportProvider.

44

The target pattern creates for each valid SupportRelationship instance within the sourcemodel both FullXSpecificIntersection and FullYSpecificIntersection elements. The mapsymbol instance referenced by intersectingSymbol in line 12 is thus demanded to share itsx-coordinates with the intersectedSymbol in line 11. Similarly, the map symbol instancereferenced by intersectingSymbol in line 15 is demanded to share its y-coordinates withthe intersectedSymbol in line 14. At line 11, the attribute xIntersectedSymbol matchesthe result instance of the triggered rule named createApplication, as shown in Listing 5.6.

Listing 5.5: Rule SupportRelationship1 rule SupportRelationship {2 from3 source : SoCaStore2008!SupportRelationship (4 not source.organizationalunit.oclIsUndefined () and5 not source.businessprocess.oclIsUndefined () and6 not source.businessprocess.super.oclIsUndefined () and7 not source.provider.oclIsUndefined () and8 source.provider.oclIsTypeOf(SoCaStore2008!

DeployedApplicationSystem))9 to

10 xintersection : SoCaVisualizationModel!FullXSpecificIntersection (11 xIntersectedSymbol <- thisModule.createApplication(source.

provider),12 xIntersectingSymbol <- thisModule.createOrganizationalUnit(

source.organizationalunit)),13 yintersection : SoCaVisualizationModel!FullYSpecificIntersection (14 yintersectedSymbol <- xintersection.xIntersectedSymbol ,15 yintersectingSymbol <- thisModule.createBusinessProcess(source.

businessprocess))16 do {17 if (source.businessprocess.pre.oclIsUndefined ()) {18 thisModule.listBusinessProcess <- source.businessprocess.

allBusinessProcesses ();19 }20 }21 }

Listing 5.5: Rule SupportRelationship

The next three unique lazy rules in Listing 5.6 are triggered by the SupportRelationshiprule in Listing 5.5 at lines 11-15. According to the prefix unique lazy, these rules createunique instances, even, if the rules are called several times with the same attribute val-ues. The createApplication rule (at lines 1-9) creates a rectangle representing a deployedapplication system by using the name attribute from the source element as a label. Further-more, the createOrganizationalUnit rule (at lines 11-19) creates a rectangle representing aorganizational unit. The last rule named createBusinessProcess (at lines 21-29) creates arectangle representing a business process.

Listing 5.6: Unique lazy rules are triggered from the SupportRelationship rule1 unique lazy rule createApplication {

45

2 from source : SoCaStore2008!SupportRelationship3 to target : SoCaVisualizationModel!Rectangle (4 text <- ftext ,5 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,

255, 255)),6 borderColor <- thisModule.setColor(thisModule.setColorTuple (1,

1, 1))),7 ftext : SoCaVisualizationModel!FormattedText (8 value <- source.provider.name)9 }

10

11 unique lazy rule createOrganizationalUnit {12 from source : SoCaStore2008!OrganizationalUnit13 to target : SoCaVisualizationModel!Rectangle (14 text <- ftext ,15 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,


1, 1))),17 ftext : SoCaVisualizationModel!FormattedText (18 value <- source.name)19 }20

21 unique lazy rule createBusinessProcess {22 from source : SoCaStore2008!BusinessProcess23 to target : SoCaVisualizationModel!Chevron (24 text <- ftext ,25 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,


1, 1))),27 ftext : SoCaVisualizationModel!FormattedText (28 value <- source.name)29 }

Listing 5.6: Unique lazy rules are triggered from the SupportRelationship rule

5.3 Annotating visualizations with certain aspects

The main idea of this section is to present software maps annotated with certain aspects.For this purpose we will reuse existing transformations for generating software maps, asdescribed in the sections above. The transformation language ATL provides programmingfeatures like rule inheritance, which are useful in this case. Moreover, one can separate thetransformation code for the annotation from the one for the base map, by using libraries.

46

5.3.1 Cluster Map with maintenance costs

This Section explains the generation of the Cluster Map with maintenance costs, as it isshown in Figure 5.8. It helps to get an overview of the application systems that rise highmaintenance costs. According to Section 5.1, which describes the usage of a cluster map indetail, this section focuses on information, which should be visualized additionally, i.e. asan annotation to an already defined software map. Hence, the transformation code fromSection 5.1 is reused and further extended with additional functionalities. It enables tovisualize the maintenance costs for each rectangle representing a DeployedApplicationSys-tem, by using different colors. The color-coding represents the amount of maintenancecosts per application system, with green color indicating lower costs, and the red colorindicating higher costs.


Warehouse

Online Shop (100)

Inventory Control

System (200)


System (Germany)

(300)



(350)


(Germany) (400)



Human Resources

System (700)

Data Warehouse

(800)


Business Traveling

System (1000)

Document Management

System (1100)


System (1200)

MIS (1300)

Financial Planning

System (1400)


Munich) (1600)

Campaign Management

System (1500)


(1620)


(1650)




(Germany/Hamburg)

(1720)


(1750)

Worktime Management


Worktime Management

(Germany/Hamburg)

(1820)


(1850)


System (2100)

Customer Complaint

System (1900)



Map Symbols

Online Shop (100)

Inventory Control

System (200)


System (Germany)

(300)



(350)


(Germany) (400)



Human Resources

System (700)

Data Warehouse

(800)


Business Traveling

System (1000)

Document Management

System (1100)


System (1200)

MIS (1300)

Financial Planning

System (1400)


Munich) (1600)

Campaign Management

System (1500)


(1620)


(1650)




(Germany/Hamburg)

(1720)


(1750)

Worktime Management


Worktime Management

(Germany/Hamburg)

(1820)


(1850)


System (2100)

Customer Complaint

System (1900)



Maintenance Costs in Q1 2007

0 50.000 €

A

B


Visualization Rules

Legend

A

B



Figure 5.8: Cluster Map with maintenance costs

The information model acting as source metamodel is similar to the one Figure 5.3 exceptthat the DeployedApplicationSystem class supplies an additional attribute, called mainte-nanceCosts. The visualization model acts as target metamodel, which is similar to the onein Figure 5.4.

In order to realize the color-coding on an existing cluster map, we use an ATL library, asintroduced in Section 4.1. The library is called libMaintenanceCosts and is imported into

47

Listing 5.7: Import of the library libMaintenanceCosts1 module ClusterMapTransformer;2 create OUT : SoCaVisualizationModel from IN : SoCaStore2008;3 uses libMaintenanceCosts;

Listing 5.7: Import of the library libMaintenanceCosts

the existing ClusterMapTransformer shown in Listing 5.7 at line 3. Listing 5.9 shows thelibrary libMaintenanceCosts which has the filename libMaintenanceCosts.atl.

Furthermore, we need to edit the existing transformation code for generating a clustermap with maintenance costs, as it is shown in Appendix A.1. According to Section 4.1,we use rule inheritance by adding a new child rule named ApplicationSystem2Costs, whichinherits from the existing parent rule named ApplicationSystem2Rectangle. The child rulewill only apply, if the attribute maintenanceCosts from a deployed application system isgreater than zero. Otherwise, the parent rule matches successfully. In detail, the librarylibMaintenanceCosts is called from the target pattern within the ApplicationSystem2Costschild rule shown in Listing 5.8 at line 18, by using the source name holding the instanceof a DeployedApplicationSystem.

According to Listing 5.9, the libMaintenanceCosts library contains a set of helpers. Themain functional helper at line 10 is called with a DeployedApplicationSystem instance as agiven parameter and returns a TupleType(red,green,blue) representing the color-codingbased on RGB colors. This helper needs some precalculated values, shown as follows.

At line 3, the functional helper orderedCosts() iterates over all DeployedApplicationSys-tem instances and saves the respective maintenanceCosts values into an OrderedSet inascending order. Next, the helper middle() at line 4 takes the upper bound, which is thelast element in the ordered set (ω) and calculates the middle (λ) for the coloring interval,as follows5:

λ = ω / 2

If the given paramenter representing the maintenance costs (ε) of an application system isgreater then the middle value (λ), then the helper setRedColorTuple at line 7 will be called,including the maintenance costs (ε) and the middle value (λ) as arguments. It calculatesthe green value of the RGB color while the red value is fixed to 255, as defined as follows:

green = (1 - (ε - λ) / λ) · 255

If the maintenance costs (ε) of an application system is lower then the middle value (λ),then the helper setGreenColorTuple at line 8 will be called, including the maintenance

5The lower bound is set to zero, because a green rectangle represented zero costs.

48

Listing 5.8: Child rule ApplicationSystem2Costs triggers the coloringMaintenanceCostshelper

1 rule ApplicationSystem2Rectangle {2 from source : SoCaStore2008!DeployedApplicationSystem (3 not source.deploymentUnit.oclIsUndefined ())4 to target : SoCaVisualizationModel!Rectangle (5 text <- ftext ,6 fillColor <- thisModule.setColor(source.coloringMaintenanceCosts

()),7 borderColor <- thisModule.setColor(thisModule.setColorTuple (1,

1, 1)),8 separationRule <- thisModule.separationOrganizationalUnit(source

.listDeployedApplicationSystem ()),9 rulingLayer <- thisModule.layerDeployedApplicationSystem(source.

listDeployedApplicationSystem ())),10 ftext : SoCaVisualizationModel!FormattedText (11 value <- source.name)12 }13 rule ApplicationSystem2Costs extends ApplicationSystem2Rectangle {14 from source : SoCaStore2008!DeployedApplicationSystem (15 source.maintenanceCosts > 0)16 to target : SoCaVisualizationModel!Rectangle (17 fillColor <- thisModule.setColor(source.coloringMaintenanceCosts

())18 )19 }

Listing 5.8: Child rule ApplicationSystem2Costs triggers the coloringMaintenanceCostshelper

costs (ε) and the middle value (λ) as arguments. The helper calculates the red value ofthe RGB color while the green value is fixed to 255, as defined as follows:

red = (ε / λ) · 255

The resulting TupleType(red,green,blue) of both helpers represents the final colors,which depends on the maintenance costs of a given application system.

Listing 5.9: Library libMaintenanceCosts1 library libMaintenanceCosts;2

3 helper def : orderedSetValues () : OrderedSet(Real) = SoCaStore2008!DeployedApplicationSystem.allInstances () -> sortedBy(e | e.maintenanceCosts) -> collect(e | e.maintenanceCosts);

4 helper def : middle () : Real = 0.5* thisModule.orderedSetValues ().last();5

49

6 helper def : setRedColorTuple(costs : Integer , mid : Real) : TupleType(red : Integer , green : Integer , blue : Integer) = Tuple{red = 255,green = ((1-(costs -mid)/mid)*255).round (), blue = 0};

7 helper def : setGreenColorTuple(costs : Integer , mid : Real) : TupleType(red : Integer , green : Integer , blue : Integer) = Tuple{red = (( costs/mid)*255).round (), green = 255, blue = 0};

8

9 helper context SoCaStore2008!DeployedApplicationSystem def :coloringMaintenanceCosts () : TupleType(red : Integer , green : Integer, blue : Integer) =

10 if self.maintenanceCosts > thisModule.middle ()11 then thisModule.setRedColorTuple(self.maintenanceCosts , thisModule.

middle ())12 else thisModule.setGreenColorTuple(self.maintenanceCosts , thisModule.

middle ())13 endif;

Listing 5.9: Library libMaintenanceCosts

5.3.2 Cluster Map with conformance to architectural solutions

This Section explains the generation of the Cluster Map showing application systems andtheir conformance to architectural solutions, as it is shown in Figure 5.9. It helps to doc-ument the heterogeneity of an application landscape, because the software map highlightsdeployed application systems, which are not conforming to their intended architecturalsolution. The examplary cluster map indicates the rectangle representing an applicationsystem that conforms to an architectural solution by using a green background color. Al-ternatively, red colored rectancles represent application systems that do not conform toan appropriate architectural solution. For this purpose, we reuse the transformation codefrom Section 5.1. According to Section 5.3.1, an ATL library is used to add additionalfunctionalies to the transformation code.

According to Section 4.1, we use rule inheritance by adding a new child rule named Appli-cationSystem2ArchSol, which inherits from the existing parent rule named ApplicationSys-tem2Rectangle. The parent rule will be annotated with the prefix abstract, because only thethe child rule is applied. In detail, the coloringArchitecturalSolution() helper is called fromthe target pattern within the ApplicationSystem2ArchSol child rule shown in Listing 5.10at line 18, by using the source name holding the instance of a DeployedApplicationSystem.

Listing 5.10: Child rule ApplicationSystem2ArchSol triggers the coloringArchitecturalSo-lution helper

1 abstract rule ApplicationSystem2Rectangle {2 from source : SoCaStore2008!DeployedApplicationSystem (3 not source.deploymentUnit.oclIsUndefined () )4 to target : SoCaVisualizationModel!Rectangle (5 nestedRule <- thisModule.setNesting(source),

50

Munich Hamburg LondonGarching

Online Shop (100) Inventory Control System (200)






(400)



Human Resources System (700)

Data Warehouse (800)


Business Traveling System (1000)

Document Management

System (1100)


System (1200)MIS (1300)

Financial Planning System

(1400)


(1600)

Campaign Management

System (1500)


Hamburg) (1620)


(1650)


Munich) (1700)



Worktime Management


Worktime Management

(Germany/Hamburg) (1820)


(1850)


System (2100)


(1900)



Map Symbols

Legend

A Organizational Unit

B

Yes

No

Deployed Application System conforms to the respective architecutal standard

A

B (1)

C (2) Organizational Unit A hosting Deployed Application System C

Visualization Rules

Deployed Application System B does not need to conform to the respective architectural standard

Figure 5.9: Cluster Map showing application systems and their conformance of architec-tural solutions

6 text <- ftext ,7 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,




listDeployedApplicationSystem ())),11 ftext : SoCaVisualizationModel!FormattedText (12 value <- source.name)13 }14

15 rule ApplicationSystem2ArchSol extends ApplicationSystem2Rectangle {16 from source : SoCaStore2008!DeployedApplicationSystem17 to target : SoCaVisualizationModel!Rectangle (18 fillColor <- thisModule.setColor(source.

coloringArchitecturalSolution ())19 )20 }

Listing 5.10: Child rule ApplicationSystem2ArchSol triggers thecoloringArchitecturalSolution helper

Figure 5.10 shows the information model used in generating this cluster map. Each de-ployed application system uses one or more instances of the InfrastructureService, for ex-

51

ample an Oracle 9i database management system at the headquarter. The infrastructureservice is based on one SolutionElement representing the used technology, for example anOracle 9i. Additionally, a deployed application system should conform to an Architectural-Solution that employs at least one SolutionElement.

InfrastructureServiceDeployedApplicationSystem

SolutionElementArchitecturalSolution

uses

*

- deployedApplications

*

- infrastructureServices

basedOn

1- solutionelement

*- deployedElement

shouldConformTo

* - deployedApplications

0..1 - solution

employs

*

- solution

1..*

- element

Figure 5.10: Information model of the DeployedApplicationSystem and their conformanceof architectural solutions

According to Listing 5.11, the helper usedSolutionElements() collects for a given deployedapplication system all used solution elments, and stores the result in a result set. Otherwise,the helper conformedSolutionElements() collects for a given deployed application system allsolution elements that are employed in the intended architectural solution, and also storesthe result in another result set. Finally, the helper coloringArchitecturalSolution() evaluatesthe tuple representing the result color for a given deployed application system, by using thefollowing condition: If the result set of the conformedSolutionElements() helper is empty,then return a tuple representing a white color. Otherwise, if the usedSolutionElements()result set includes all elements from the conformedSolutionElements() result set, then itreturns a tuple representing green, because the deployed application system conforms tothe architectural solution, else return a tuple representing red is returned. Thereby, a notso strict interpretation of architectural conformance is applied. A more strict one couldalso be evaluated and visualized, relying on equality of sets instead of a subset relationship.

Listing 5.11: Library libArchitecturalSolution1 library libArchitecturalSolution;2

3 helper context SoCaStore2008!DeployedApplicationSystem def :usedSolutionElements () : Set(SoCaStore2008!SolutionElement) =

4 if not self.infrastructureServices.oclIsUndefined ()5 then self.infrastructureServices -> collect(e | e.solutionelement)6 else Set{}7 endif;8 helper context SoCaStore2008!DeployedApplicationSystem def :

conformedSolutionElements () : Set(SoCaStore2008!SolutionElement) =

52

9 if not self.solution.oclIsUndefined () and self.solution.oclIsKindOf(SoCaStore2008!ArchitecturalSolution)

10 then self.solution.element -> select(e | e.oclIsKindOf(SoCaStore2008!SolutionElement))

11 else Set{}12 endif;13

14 helper context SoCaStore2008!DeployedApplicationSystem def :coloringArchitecturalSolution () : TupleType(red : Integer , green :Integer , blue : Integer) =

15 if self.conformedSolutionElements ().isEmpty ()16 then Tuple{red = 255, green = 255, blue = 255}17 else18 if self.usedSolutionElements () -> includesAll(self.

conformedSolutionElements ())19 then Tuple{red = 0, green = 255, blue = 0}20 else Tuple{red = 255, green = 0, blue = 0}21 endif22 endif;

Listing 5.11: Library libArchitecturalSolution

5.3.3 Aggregated Cluster Map with Interconnections

The last examplary software map in this Chapter is called Aggregated Cluster Map withInterconnections, as it is shown in Figure 5.11. This software map uses the base mapaccording to Section 5.1, extended by visualizing additional information objects from thesource model. Thereof, the OrganizationalUnit is located at the Location, represented usingthe concept of Nesting. For example, the rectangle labeled Headquarter is nested into therectangle labeled Munich expressing that the OrganizationalUnit ”Headquarter” is locatedat the Location ”Munich”. Moreover, this aggregated cluster map shows interconnectionsbetween DeployedApplicationSystems by using the visualization concept of Polyline repre-senting the black line, which is stored within the target model. The interconnections areaggregated to the organizational units, i.e. a red line connecting two rectangle represent-ing Organizational Units is shown, when at least one DeployedApplicationSystems fromthe one unit is interconnected to one DeployedApplicationSystems from the other unit.This information is not directly part of the source model, but can be derived during theexecution of the transformation code, which will subsequently be explained.


Information Model The information model acts as source metamodel, as shown in Fig-ure 5.126. According to Section 5.1, this information model shows additional classeslike the Location as well as the Interconnection. The latter means that two instances

6Therein, some attributes, e.g. the id attributes of the classes, are omitted for reasons of clarity.

53

LondonHamburgMunichHeadquarter Subsidiary SubsidiarySubsidiary Warehouse

Inventory Control

System (200)



(350)


(Germany) (400)

Human Resources

System (700)

Data Warehouse

(800)


Business Traveling

System (1000)

Document Management

System (1100)


System (1200)

MIS (1300)

Financial Planning

System (1400)


Munich) (1600)

Campaign Management

System (1500)


(1620)


(1650)




(Germany/Hamburg)

(1720)


(1750)

Worktime Management


Worktime Management

(Germany/Hamburg)

(1820)


(1850)


System (2100)

Customer Complaint

System (1900)



Map Symbols

A

B

Nesting: „B“ located at „A“

Visualization RulesLegend

A Location A

Deployed Application System BB

C Organizational Unit C

A

B

CNesting: „A“ hosts „B“ and „C“

A B

C D

Polyline: „A“ uses „B“

Polyline: „C“ connects „D“

Figure 5.11: Aggregated Cluster Map with Interconnections

(client, server) of the DeployedApplicationSystem are connected through one instanceof the Interconnection.

Visualization Model Figure 5.137 shows the visualization model acting as target meta-model. Instead of the one used for standard cluster map in Section 5.1, this vi-sualization model contains additional classes like the Attachment and the Polyline.The latter connects two instances of the Rectangle class by a polyline using for eachpolyline two instances of the Attachment class.

According to Listing 5.12, the parent rule named Interconnection2Polyline selects all in-stances of the Interconnection class from the source model at lines 3-6, which have validclient and server references assigned at the associations ends. If the client and server de-ployed application systems are hosted at the same organizational unit (cf. line 13), thenthe derived rule named App2Polyline will trigger for each interconnection the unique lazyrule called createApplicationPolyline at line 15, which creates the respective instance ofthe Polyline class as well as two instances of the Attachment class. Otherwise (cf. line23), the derived rule named OrgUnit2Polyline will trigger the unique lazy rules named

7Again, the id attribute has been omitted.

54


name : String

OrganizationalUnit

name : String

Location

address : Stringcounty : Stringcity : StringzipCode : String

Interconnection

isServer1

- server

*

- serversides

deployedAt

1- organizationalunit

*- deployment

isClient *

- clientsides

1

- client

isLocatedAt *


1

- location

Figure 5.12: Information model for the aggregated cluster map

Rectangle


Nesting

Separation Attachment

MapSymbol

Polyline

PlanarMapSymbol LinearMapSymbol

separating 2..*

- separated

*

- separationRule

nesting

*- nestingRule

1- nestingSymbol

nested

*- nestedRule

1- nestedSymbol

attaching1

- attached

*- attachmentRule

attaching 1

- attached

2 - attachmentRule

Figure 5.13: Extract of the visualization model for the aggregated cluster map

createApplicationPolyline and createOrgUnitPolyline. This rule contains an if clause in itsimperative code, because the target model should only contain one instance of the Polylineclass between two instances of the OrganizationalUnit class.

Listing 5.12: Child rules create polylines between rectangles1 abstract rule Interconnection2Polyline {2 from source : SoCaStore2008!Interconnection (3 not source.client.oclIsUndefined () and4 not source.server.oclIsUndefined () and5 source.client.oclIsKindOf(SoCaStore2008!

DeployedApplicationSystem) and6 source.server.oclIsKindOf(SoCaStore2008!

DeployedApplicationSystem) )

55

7 }8

9 rule App2Polyline extends Interconnection2Polyline {10 from source : SoCaStore2008!Interconnection (11 not source.client.deploymentUnit.oclIsUndefined () and12 not source.server.deploymentUnit.oclIsUndefined () and13 source.client.deploymentUnit = source.server.deploymentUnit )14 do {15 thisModule.createApplicationPolyline(source);16 }17 }18

19 rule OrgUnit2Polyline extends Interconnection2Polyline {20 from source : SoCaStore2008!Interconnection (21 not source.client.deploymentUnit.oclIsUndefined () and22 not source.server.deploymentUnit.oclIsUndefined () and23 source.client.deploymentUnit <> source.server.deploymentUnit )24 do {25 if (thisModule.listInterconnections -> excludes(Tuple{client =

source.client.deploymentUnit , server = source.server.deploymentUnit }) or thisModule.listInterconnections -> excludes(Tuple{server = source.client.deploymentUnit , client = source.server.deploymentUnit })) {

26 thisModule.createOrgUnitPolyline(source);27 thisModule.listInterconnections <- thisModule.

listInterconnections.append(Tuple{client = source.client.deploymentUnit , server = source.server.deploymentUnit });

28 thisModule.listInterconnections <- thisModule.listInterconnections.append(Tuple{server = source.client.deploymentUnit , client = source.server.deploymentUnit });

29 }30 thisModule.createApplicationPolyline(source);31 }32 }33

34 unique lazy rule createApplicationPolyline {35 from source : SoCaStore2008!Interconnection36 to polyline : SoCaVisualizationModel!Polyline (37 attachmentRule <- thisModule.createClientAttachment(source) ->

asSequence ().append(thisModule.createServerAttachment(source)))38 do {39 thisModule.legendAppInterconnections <- thisModule.

legendAppInterconnections.append(polyline);40 }41 }42

43 unique lazy rule createClientAttachment {44 from source : SoCaStore2008!Interconnection45 to client : SoCaVisualizationModel!Attachment (46 attached <- source.client)47 }

56

48

49 unique lazy rule createServerAttachment {50 from source : SoCaStore2008!Interconnection51 to server : SoCaVisualizationModel!Attachment (52 attached <- source.server)53 }

Listing 5.12: Child rules create polylines between rectangles

57

Chapter 6

Conclusion and Outlook

This Chapter summarizes the conclusions of this thesis focusing on the advantages andlimitations found out by using ATL for several model-to-model transformations in thecontext of generating software map. Finally, an outlook for future work will be given.

6.1 Summary

The aim of this work was to analyze and apply model transformation languages for gen-erating software maps. Within this field of application the research project Software Car-tography provided a prototype [Sc06], which is currently in use for transforming modelswith Java. The used transformation approach [Er06] was described in Chapter 2, by givingthe definitions of important concepts and constituents. The work was motivated by thefact that transforming models with Java comes along with additional effort. Therefore,languages providing dedicated support for model-to-model transformation were subject toresearch, in order to evaluate, if they can help to focus on the essentials of the transforma-tion code.

Based on functional and non-functional requirements elicited in Chapter 3, we provided adetailed look at the Atlas Transformation Language (ATL) as well as the Queries/Views/-Transformations (QVT) standard and its QVT-Relations Language in Chapter 4. In de-tail, we found out that both languages perform similarly in respect to the fulfillment ofthe functional requirements. In contrast, the non-functional requirements, which dependon the implementations with different features and environments, were fulfilled to differ-ent levels. The reason why we prefered ATL for transforming models was based on theconformance to non-functional requirements, e.g. the active ATL community as well asexemplary applications and documentations.

Chapter 5 shows the application of ATL for successfully generating several different kindsof software maps like the cluster map and the process support map. Moreover, we showed

58

how to reuse the base maps for annotating visualizations with certain aspects. For example,the calculation of colors representing e.g. different maintenance costs, has been developed.This is possible, because ATL provides useful language features like libraries and ruleinheritance. With the example of the aggregated cluster map with interconnections, wehave seen that the transformation code can be used to derive additional information likethe interconnections between organizational units, which is not directly part of the sourcemodel. The results have been displayed that ATL is powerful to transforming differentkinds of models in one direction.

6.2 Advantages and limitations of ATL

First, there are a few drawbacks, which might come up by using ATL for transformingsource to target models. Rule inheritance within ATL is useful when several rules share acommon part. The introduced Eclipse implementation in Section 4.3 supports rule inheri-tance only for matched rules, but not for called rules. This means, similar called rules withonly minor differences need to be implemented over again. For example, the ClusterMap-Transformer as shown in Appendix A.1 contains similar unique lazy rules for generatinga Separation element at lines 74-84, and also a VisibilityLayer element at lines 86-100.

Furthermore, ATL is based on the OMG OCL [OM06b] standard in respect to its datatypes and its declarative expressions, which causes limitations concerning the supporteddata types. The developer can use the primitive data types like string, boolean, integer,and real, but it is not possible to introduce new primitive data types.

According to Section 3.1 transformation rules can be defined in an imperative as well asa declarative form. The latter is preferred in the context of our approach. According toAppendix A, we can say that complex transformations like the ProcessSupportMapTrans-former need approx. 90 percent declarative and approx. 10 percent imperative features.Otherwise, the ClusterMapTransformer can be 100 percent declaratively implemented.

Next, we focus on the advantages of using ATL for transforming models. As describedabove, ATL provides OCL expressions including operations associated with different kindsof data types. The OCL expressions are common to all data types, which is helpful in thecontext of filtering. For example, OCL can be used within a source pattern, to select onlyspecific elements from the source model. Moreover, facilities for performing calculationson several data types via OCL are very powerful.

Hence selecting and traversing through instances of model elements are quite simple. Ele-ments can simly be selected using the name of the reference.

If more than one element in the source model could trigger the creation of the same specifictarget element, the rule for the target element will be called more then one time. In thiscase, the unique lazy rule may be helpful, because it creates only one element in the target

59

model. This is possible, because the ATL engine generates and maintains implicit tracinglinks.

The most important advantage of using ATL is the pattern matching, which matches thespecific elements from the source model and creates the right elements within the targetmodel. In combination with OCL expressions, the pattern matching saves plenty a numberof lines of code instead of using a programming language like Java for transfoming models.Furthermore, the transformation code is easier to read, which is important for reengineeringas well as for maintaining transformation models.

Therefore, ATL can be considered a valuable model transformation language, with a num-ber of advantages, which especially in the context of generating software maps are likly tooutweight its limitations.

6.3 Outlook

One objective for future work could be to develop bidirectional transformations. Accord-ing to Chapter 3, ATL supports unidirectional transformations, which is sufficient forcreating the symbolic model based on the semantic model. If we wanted to use ATL forbidirectional transformations, we would need to create an additional unidirectional trans-formation, which updates the semantic model according to changes from the symbolicmodel. For example, if the user made changes in the graphical software map editor likedeleting a rectangle representing an application, then the transformation should updatethe respective source model. Alternatively, the QVT relations language could be seen asa possible technology for this purpose, because it supports bidirectional transformations.Upcoming side effect needs to be considered, because both metamodels describe aspectsat different levels of abstraction.

Another area for future work is the usage of openArchitectureWare (oAW) [Ec08b], whichwe could not evaluate in the context of this thesis due to reasons of brevity. In detail,oAW is a modular MDA framework implemented in Java and hosted inside the EclipseGenerative Modeling Technologies (GMT) [Ec08a] project. One part of the framework canperform model-to-model transformations by using the Xtend language, which is a textual,functional transformation language. It can be used to transform between the variousmetametamodels. Instead of using the Xtend language, the oAW framework provides anadapter for third party transformation languages such as ATL. Therefore, it might bepossible to leverage some of the findings from this thesis in the oAW environment, too.

60

Appendix A

ATL Transformation Code

This Chapter lists the transformation code for generating several software maps with ATL.The sections are separated by the different kinds of software maps.

A.1 Cluster Map

Listing A.1: Cluster Map Transformer in ATL1 module ClusterMapTransformer;2 create OUT : SoCaVisualizationModel from IN : SoCaStore2008;3

4 helper def : setColorTuple(r : Integer , g : Integer , b : Integer) :TupleType(red : Integer , green : Integer , blue : Integer) = Tuple{blue = b, green = g, red = r};

5

6 helper context SoCaStore2008!OrganizationalUnit7 def: listOrganizationalUnit () : Sequence(SoCaStore2008!

OrganizationalUnit) =8 SoCaStore2008!OrganizationalUnit.allInstances () -> select(e | e.

oclIsKindOf(SoCaStore2008!DeployedApplicationSystem));9

10 helper context SoCaStore2008!DeployedApplicationSystem11 def: listDeployedApplicationSystem () : Sequence(SoCaStore2008!

DeployedApplicationSystem) =12 SoCaStore2008!DeployedApplicationSystem.allInstances ();13

14 rule SoftwareMap {15 from source : SoCaStore2008!SemanticModel16 to target : SoCaVisualizationModel!SoftwareMap (17 title <- ’Cluster Map ’),18 legendOrgUnit : SoCaVisualizationModel!LegendElement (19 text <- ’Org. Unit.’),20 legendRectangleOrgUnit : SoCaVisualizationModel!Rectangle (

61

21 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,255, 255)),

22 borderColor <- thisModule.setColor(thisModule.setColorTuple (1,1, 1)),

23 legendelement <- legendOrgUnit),24 legendDeployedApp : SoCaVisualizationModel!LegendElement (25 text <- ’Deployed App.’),26 legendRectangleDeployedApp : SoCaVisualizationModel!Rectangle (27 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,


1, 1)),29 legendelement <- legendDeployedApp)30 }31


DeployedApplicationSystem)).size() > 0)35 to target : SoCaVisualizationModel!Rectangle (36 text <- ftext ,37 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,



.listOrganizationalUnit ()) ,),40 rulingLayer <- thisModule.layerOrganizationalUnit(source.

listOrganizationalUnit ())),41 ftext : SoCaVisualizationModel!FormattedText (42 value <- source.name)43 }44

45 rule ApplicationSystem2Rectangle {46 from source : SoCaStore2008!DeployedApplicationSystem (47 not source.deploymentUnit.oclIsUndefined () )48 to target : SoCaVisualizationModel!Rectangle (49 nestedRule <- thisModule.setNesting(source),50 text <- ftext ,51 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,





62

59 unique lazy rule setNesting {60 from source : SoCaStore2008!DeployedApplicationSystem61 to nesting : SoCaVisualizationModel!Nesting (62 nestedSymbol <- source ,63 nestingSymbol <- source.deploymentUnit)64 }65

66 unique lazy rule setColor {67 from source : TupleType(red : Integer , green : Integer , blue : Integer

)68 to bcolor : SoCaVisualizationModel!Color (69 blue <- source.blue ,70 green <- source.green ,71 red <- source.red)72 }73

74 unique lazy rule separationDeployedApplicationSystem {75 from source : SoCaStore2008!DeployedApplicationSystem76 to separation : SoCaVisualizationModel!Separation (77 separated <- source)78 }79


86 unique lazy rule layerOrganizationalUnit {87 from source : SoCaStore2008!OrganizationalUnit88 to layer : SoCaVisualizationModel!VisibilityLayer (89 name <- ’Organizational Units ’,90 visible <- true ,91 layeredSymbol <- source)92 }93

94 unique lazy rule layerDeployedApplicationSystem {95 from source : SoCaStore2008!DeployedApplicationSystem96 to layer : SoCaVisualizationModel!VisibilityLayer (97 name <- ’Deployed Application Systems ’,98 visible <- true ,99 layeredSymbol <- source)

100 }

Listing A.1: Cluster Map Transformer in ATL

63

A.2 Process Support Map

Listing A.2: Process Support Map Transformer1 module ProcessSupportMapTransformer;2 create OUT : SoCaVisualizationModel from IN : SoCaStore2008 ;3

4 helper def : setColorTuple(b : Integer , g : Integer , r : Integer) :TupleType(blue : Integer , green : Integer , red : Integer) = Tuple{blue = b, green = g, red = r};

5 helper def : listOrganizationalUnit : Sequence(SoCaStore2008!OrganizationalUnit) = Sequence {};

6 helper def : listBusinessProcess : Sequence(SoCaStore2008!BusinessProcess) = Sequence {};

7 helper def : listSupportRelationship : Sequence(SoCaStore2008!SupportRelationship) = Sequence {};

8 helper def : listSupportRelationshipDone : Sequence(SoCaStore2008!SupportRelationship) = Sequence {};

9 helper def : organizationalUnitCounter : Integer = 0;10 helper def : businessProcessReady : Boolean = false;11 helper def : organizationalUnitReady : Boolean = false;12 helper def : sequenceReady : Boolean = false;13 helper def : organizationalUnitMax : Integer = SoCaStore2008!

OrganizationalUnit.allInstances () -> select(e|not e.supports.oclIsUndefined ()).size();

14 helper def : counter : Integer = 1;15

16 helper context SoCaStore2008!BusinessProcess17 def: allBusinessProcessesRec(s : SoCaStore2008!BusinessProcess , res :

Sequence(SoCaStore2008!BusinessProcess)) :18 Sequence(SoCaStore2008!BusinessProcess) =19 if s.post.oclIsUndefined () then20 res ->append(s)21 else22 self.allBusinessProcessesRec(s.post , res ->append(s))23 endif;24

25 helper context SoCaStore2008!BusinessProcess26 def: allBusinessProcesses () : Sequence(SoCaStore2008!BusinessProcess)

=27 self.allBusinessProcessesRec(self , Sequence {});28

29 helper context SoCaStore2008!SupportRelationship30 def: supportRelationshipSeparation(s : SoCaStore2008!

SupportRelationship) :31 Sequence(SoCaStore2008!SupportRelationship) =32 SoCaStore2008!SupportRelationship.allInstances ()33 -> select(e | not e.organizationalunit.oclIsUndefined () and34 not e.businessprocess.oclIsUndefined () and35 not e.provider.oclIsUndefined () and

64

36 e.provider.oclIsTypeOf(SoCaStore2008!DeployedApplicationSystem)and

37 not e.businessprocess.super.oclIsUndefined ()38 and e <> s39 )40 ->iterate(e; res : Sequence(SoCaStore2008!SupportRelationship) =

Sequence {} |41 if e.organizationalunit = s.organizationalunit and e.

businessprocess = s.businessprocess42 then43 res ->append(e)44 else45 res46 endif);47

48 rule SupportRelationship {49 from50 source : SoCaStore2008!SupportRelationship (51 not source.organizationalunit.oclIsUndefined () and52 not source.businessprocess.oclIsUndefined () and53 not source.provider.oclIsUndefined () and54 source.provider.oclIsTypeOf(SoCaStore2008!

DeployedApplicationSystem) and55 not source.businessprocess.super.oclIsUndefined ())56 to57 xintersection : SoCaVisualizationModel!FullXSpecificIntersection (58 xIntersectedSymbol <- thisModule.createApplication(source),59 xIntersectingSymbol <- thisModule.createOrganizationalUnit(

source.organizationalunit)),60 yintersection : SoCaVisualizationModel!FullYSpecificIntersection (61 yintersectedSymbol <- xintersection.xIntersectedSymbol ,62 yintersectingSymbol <- thisModule.createBusinessProcess(source.

businessprocess))63 do {64 if (not thisModule.listOrganizationalUnit ->includes(source.

organizationalunit)) {65 thisModule.listOrganizationalUnit <- thisModule.

listOrganizationalUnit ->union(Sequence{source.organizationalunit });}

66 if (thisModule.organizationalUnitCounter = thisModule.organizationalUnitMax) {

67 thisModule.organizationalUnitReady <- true;}68 if (source.businessprocess.pre.oclIsUndefined () and not thisModule.

businessProcessReady) {69 thisModule.listBusinessProcess <- source.businessprocess.

allBusinessProcesses ();70 thisModule.businessProcessReady <- true;}71 if (thisModule.organizationalUnitReady and thisModule.

businessProcessReady and not thisModule.sequenceReady) {72 thisModule.createXSequence(thisModule.listBusinessProcess ->prepend(

thisModule.listOrganizationalUnit.first ()));

65

73 thisModule.createYSequence(thisModule.listOrganizationalUnit ->prepend(thisModule.listBusinessProcess.first()));

74 thisModule.sequenceReady <- true;}75 }76 }77

78 unique lazy rule createApplication {79 from source : SoCaStore2008!SupportRelationship80 to target : SoCaVisualizationModel!Rectangle (81 text <- ftext ,82 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,


1, 1))),84 ftext : SoCaVisualizationModel!FormattedText (85 value <- source.provider.name)86 do {87

88 thisModule.listSupportRelationship <- source.supportRelationshipSeparation(source);

89

90 thisModule.listSupportRelationshipDone <- thisModule.listSupportRelationshipDone ->union(thisModule.listSupportRelationship);

91

92 if (not thisModule.listSupportRelationship ->isEmpty () and notthisModule.listSupportRelationshipDone ->includes(source)) {

93 thisModule.createSeparation(thisModule.listSupportRelationship ->append(source));

94 thisModule.listSupportRelationshipDone <- thisModule.listSupportRelationshipDone ->union(thisModule.listSupportRelationship);

95 }96 }97 }98

99 unique lazy rule createOrganizationalUnit {100 from source : SoCaStore2008!OrganizationalUnit101 to target : SoCaVisualizationModel!Rectangle (102 text <- ftext ,103 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,


1, 1))),105 ftext : SoCaVisualizationModel!FormattedText (106 value <- source.name)107 do{thisModule.organizationalUnitCounter <- thisModule.

organizationalUnitCounter + 1;}108 }109

110 unique lazy rule createBusinessProcess {

66

111 from source : SoCaStore2008!DeployedApplicationSystem112 to target : SoCaVisualizationModel!Chevron (113 text <- ftext ,114 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,


1, 1))),116 ftext : SoCaVisualizationModel!FormattedText (117 value <- source.name)118 }119

120 unique lazy rule createYSequence {121 from source : Sequence(SoCaStore2008!OrganizationalUnit)122 to target : SoCaVisualizationModel!YSequence (123 ruledYSequence <- source ->collect(e |124 if e = source.first() then125 thisModule.createBusinessProcess(e)126 else127 thisModule.createOrganizationalUnit(e)128 endif))129 }130

131 unique lazy rule createXSequence {132 from source : Sequence(SoCaStore2008!BusinessProcess)133 to target : SoCaVisualizationModel!XSequence (134 ruledXSequence <- source ->collect(e |135 if e = source.first() then136 thisModule.createOrganizationalUnit(e)137 else138 thisModule.createBusinessProcess(e)139 endif))140 }141

142 lazy rule createSeparation {143 from source : Sequence(SoCaStore2008!SupportRelationship)144 to target : SoCaVisualizationModel!Separation (145 separated <- source -> collect(e | thisModule.createApplication(

e)))146 }147

148 unique lazy rule setColor {149 from source : TupleType(blue : Integer , green : Integer , red : Integer

)150 to bcolor : SoCaVisualizationModel!Color (151 blue <- source.blue ,152 green <- source.green ,153 red <- source.red)154 }

Listing A.2: Process Support Map Transformer

67

A.3 Aggregated Cluster Map with Interconnections

Listing A.3: Aggregated Cluster Map with Interconnections Transformer1 -- @atlcompiler atl20062 module AggregatedClusterMapTransformer;3 create OUT : SoCaVisualizationModel from IN : SoCaStore2008;4

5 helper def : setColorTuple(r : Integer , g : Integer , b : Integer) :TupleType(red : Integer , green : Integer , blue : Integer) = Tuple{blue = b, green = g, red = r};

6 helper def : listInterconnections : Sequence(TupleType(client :SoCaStore2008!OrganizationalUnit , server : SoCaStore2008!OrganizationalUnit)) = Sequence {};

7 helper def : legendAppInterconnections : Sequence(SoCaVisualizationModel!Polyline) = Sequence {};

8 helper def : legendOrgUnitInterconnections : Sequence(SoCaVisualizationModel!Polyline) = Sequence {};

9

10 helper context SoCaStore2008!Location11 def: listLocation () : Sequence(SoCaStore2008!Location) =12 SoCaStore2008!Location.allInstances ();13

14 helper context SoCaStore2008!OrganizationalUnit15 def: listOrganizationalUnit () : Sequence(SoCaStore2008!

OrganizationalUnit) =16 SoCaStore2008!OrganizationalUnit.allInstances () -> select(e | e.

oclIsKindOf(SoCaStore2008!DeployedApplicationSystem));17

18 helper context SoCaStore2008!DeployedApplicationSystem19 def: listDeployedApplicationSystem () : Sequence(SoCaStore2008!

DeployedApplicationSystem) =20 SoCaStore2008!DeployedApplicationSystem.allInstances ();21


DeployedApplicationSystem)).size() > 0 and25 not source.location.oclIsUndefined () )26 to target : SoCaVisualizationModel!Rectangle (27 text <- ftext ,28 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,


1, 1)),30 nestedRule <- thisModule.setOrganizationalUnitNesting(source),31 separationRule <- thisModule.separationOrganizationalUnit(source

.listOrganizationalUnit ()),32 rulingLayer <- thisModule.layerOrganizationalUnit(source.

listOrganizationalUnit ())),33 ftext : SoCaVisualizationModel!FormattedText (

68

34 value <- source.name)35 }36

37 rule ApplicationSystem2Rectangle {38 from source : SoCaStore2008!DeployedApplicationSystem (39 not source.deploymentUnit.oclIsUndefined () )40 to target : SoCaVisualizationModel!Rectangle (41 text <- ftext ,42 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,


1, 1)),44 nestedRule <- thisModule.setApplicationNesting(source),45 separationRule <- thisModule.separationDeployedApplicationSystem

(source.listDeployedApplicationSystem ()),46 rulingLayer <- thisModule.layerDeployedApplicationSystem(source.


51 rule Location2Rectangle {52 from source : SoCaStore2008!Location (53 not source.organizationalunit.oclIsUndefined () )54 to target : SoCaVisualizationModel!Rectangle (55 text <- ftext ,56 fillColor <- thisModule.setColor(thisModule.setColorTuple (64,


1, 1)),58 separationRule <- thisModule.separationLocation(source.

listLocation ()),59 rulingLayer <- thisModule.layerLocation(source.listLocation ())),60 ftext : SoCaVisualizationModel!FormattedText (61 value <- source.name)62 }63

64 abstract rule Interconnection2Polyline {65 from source : SoCaStore2008!Interconnection (66 not source.client.oclIsUndefined () and67 not source.server.oclIsUndefined () and68 source.client.oclIsKindOf(SoCaStore2008!

DeployedApplicationSystem) and69 source.server.oclIsKindOf(SoCaStore2008!

DeployedApplicationSystem) )70 }71

72 rule App2Polyline extends Interconnection2Polyline {73 from source : SoCaStore2008!Interconnection (74 not source.client.deploymentUnit.oclIsUndefined () and75 not source.server.deploymentUnit.oclIsUndefined () and

69

76 source.client.deploymentUnit = source.server.deploymentUnit )77 do {78 thisModule.createApplicationPolyline(source);79 }80 }81

82 rule OrgUnit2Polyline extends Interconnection2Polyline {83 from source : SoCaStore2008!Interconnection (84 not source.client.deploymentUnit.oclIsUndefined () and85 not source.server.deploymentUnit.oclIsUndefined () and86 source.client.deploymentUnit <> source.server.deploymentUnit )87 do {88 if (thisModule.listInterconnections -> excludes(Tuple{client =

source.client.deploymentUnit , server = source.server.deploymentUnit }) or thisModule.listInterconnections -> excludes(Tuple{server = source.client.deploymentUnit , client = source.server.deploymentUnit })) {

89 thisModule.createOrgUnitPolyline(source);90 thisModule.listInterconnections <- thisModule.

listInterconnections.append(Tuple{client = source.client.deploymentUnit , server = source.server.deploymentUnit });

91 thisModule.listInterconnections <- thisModule.listInterconnections.append(Tuple{server = source.client.deploymentUnit , client = source.server.deploymentUnit });

92 }93 thisModule.createApplicationPolyline(source);94 }95 }96

97 unique lazy rule createApplicationPolyline {98 from source : SoCaStore2008!Interconnection99 to polyline : SoCaVisualizationModel!Polyline (

100 attachmentRule <- thisModule.createClientAttachment(source) ->asSequence ().append(thisModule.createServerAttachment(source)))

101 do {102 thisModule.legendAppInterconnections <- thisModule.

legendAppInterconnections.append(polyline);103 }104 }105

106 unique lazy rule createOrgUnitPolyline {107 from source : SoCaStore2008!Interconnection108 to polyline : SoCaVisualizationModel!Polyline (109 attachmentRule <- thisModule.attachmentClientOrgUnit(source) ->

asSequence ().append(thisModule.attachmentServerOrgUnit(source)))

110 do {111 thisModule.legendOrgUnitInterconnections <- thisModule.

legendOrgUnitInterconnections.append(polyline);112 }113 }

70

114

115 unique lazy rule createClientAttachment {116 from source : SoCaStore2008!Interconnection117 to client : SoCaVisualizationModel!Attachment (118 attached <- source.client)119 }120

121 unique lazy rule createServerAttachment {122 from source : SoCaStore2008!Interconnection123 to server : SoCaVisualizationModel!Attachment (124 attached <- source.server)125 }126

127 unique lazy rule attachmentClientOrgUnit {128 from source : SoCaStore2008!Interconnection129 to client : SoCaVisualizationModel!Attachment (130 attached <- source.client.deploymentUnit)131 }132

133 unique lazy rule attachmentServerOrgUnit {134 from source : SoCaStore2008!Interconnection135 to server : SoCaVisualizationModel!Attachment (136 attached <- source.server.deploymentUnit)137 }138

139 unique lazy rule setOrganizationalUnitNesting {140 from source : SoCaStore2008!OrganizationalUnit141 to nesting : SoCaVisualizationModel!Nesting (142 nestedSymbol <- source ,143 nestingSymbol <- source.location)144 }145

146 unique lazy rule setApplicationNesting {147 from source : SoCaStore2008!DeployedApplicationSystem148 to nesting : SoCaVisualizationModel!Nesting (149 nestedSymbol <- source ,150 nestingSymbol <- source.deploymentUnit)151 }152

153 unique lazy rule setColor {154 from source : TupleType(red : Integer , green : Integer , blue : Integer

)155 to bcolor : SoCaVisualizationModel!Color (156 blue <- source.blue ,157 green <- source.green ,158 red <- source.red)159 }160

161 unique lazy rule separationLocation {162 from source : SoCaStore2008!Location163 to separation : SoCaVisualizationModel!Separation (

71

164 separated <- source)165 }166


173 unique lazy rule separationDeployedApplicationSystem {174 from source : SoCaStore2008!DeployedApplicationSystem175 to separation : SoCaVisualizationModel!Separation (176 separated <- source)177 }178

179 unique lazy rule layerLocation {180 from source : SoCaStore2008!Location181 to layer : SoCaVisualizationModel!VisibilityLayer (182 name <- ’Locations ’,183 visible <- true ,184 layeredSymbol <- source)185 }186

187 unique lazy rule layerOrganizationalUnit {188 from source : SoCaStore2008!OrganizationalUnit189 to layer : SoCaVisualizationModel!VisibilityLayer (190 name <- ’Organizational Units ’,191 visible <- true ,192 layeredSymbol <- source)193 }194

195 unique lazy rule layerDeployedApplicationSystem {196 from source : SoCaStore2008!DeployedApplicationSystem197 to layer : SoCaVisualizationModel!VisibilityLayer (198 name <- ’Deployed Application Systems ’,199 visible <- true ,200 layeredSymbol <- source)201 }202

203 unique lazy rule layerAppInterconnection {204 from source : SoCaStore2008!Interconnection205 to layer : SoCaVisualizationModel!VisibilityLayer (206 name <- ’Deployed. App. Interconnection ’,207 visible <- true ,208 layeredSymbol <- source)209 }210

211 unique lazy rule layerOrgUnitInterconnection {212 from source : SoCaStore2008!Interconnection213 to layer : SoCaVisualizationModel!VisibilityLayer (214 name <- ’Org. Unit. Interconnection ’,

72

215 visible <- true ,216 layeredSymbol <- source)217 }218

219 rule SoftwareMap {220 from source : SoCaStore2008!SemanticModel221 to target : SoCaVisualizationModel!SoftwareMap (222 title <- ’Aggregated Cluster Map ’),223 legendOrgUnit : SoCaVisualizationModel!LegendElement (224 text <- ’Org. Unit.’),225 legendRectangleOrgUnit : SoCaVisualizationModel!Rectangle (226 fillColor <- thisModule.setColor(thisModule.setColorTuple (255,


1, 1)),228 legendelement <- legendOrgUnit),229 legendDeployedApp : SoCaVisualizationModel!LegendElement (230 text <- ’Deployed App.’),231 legendRectangleDeployedApp : SoCaVisualizationModel!Rectangle (232 fillColor <- thisModule.setColor(thisModule.setColorTuple (128,


1, 1)),234 legendelement <- legendDeployedApp),235 legendLocation : SoCaVisualizationModel!LegendElement (236 text <- ’Location ’),237 legendRectangleLocation : SoCaVisualizationModel!Rectangle (238 fillColor <- thisModule.setColor(thisModule.setColorTuple (64,


1, 1)),240 legendelement <- legendLocation),241 legendAppInterconnection : SoCaVisualizationModel!LegendElement (242 text <- ’Deployed. App. Intercon.’),243 legendRectangleAppInterconnection : SoCaVisualizationModel!Polyline

(244 legendelement <- legendAppInterconnection),245 legendOrgUnitInterconnection : SoCaVisualizationModel!LegendElement

(246 text <- ’Org. Unit. Intercon.’),247 legendRectangleOrgUnitInterconnection : SoCaVisualizationModel!

Polyline (248 legendelement <- legendOrgUnitInterconnection)249 do {250 thisModule.layerAppInterconnection(thisModule.

legendAppInterconnections);251 thisModule.layerOrgUnitInterconnection(thisModule.

legendOrgUnitInterconnections);252 }253 }

Listing A.3: Aggregated Cluster Map with Interconnections Transformer

73

Appendix B

QVT Transformation Code

Finally, this Chapter shows the transformation code for generating a cluster map withQVT.

B.1 Cluster Map

Listing B.1: Cluster Map Transformer in QVT1 transformation ClusterMapTransformer(semantic:SoCaStore2008 , symbolic:

SoCaVisualizationModel) {2

3 key SoCaVisualizationModel :: Types:: Color { blue , green , red };4 key SoCaVisualizationModel :: Types:: FormattedText { value };5

6 top relation SemanticModelToSoftwareMap {7 checkonly domain semantic model : SoCaStore2008 :: SemanticModel {8 };9 enforce domain symbolic target : SoCaVisualizationModel ::

SoftwareMap {10 title = ’Cluster Map ’11 };12 enforce domain symbolic legendOrgUnit : SoCaVisualizationModel ::

LegendElement {13 text = ’Org. Unit.’14 };15 enforce domain symbolic rectangleOrgUnit : SoCaVisualizationModel ::

MapSymbols :: Rectangle {16 legendelement = legendOrgUnit17 };18 enforce domain symbolic legendDeployedApp : SoCaVisualizationModel

:: LegendElement {19 text = ’Deployed App.’20 };

74

21 enforce domain symbolic rectangleDeployedApp :SoCaVisualizationModel :: MapSymbols :: Rectangle {

22 legendelement = legendDeployedApp23 };24 enforce domain symbolic separationOrg : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Separation {25 };26 enforce domain symbolic layerOrg : SoCaVisualizationModel ::

VisibilityLayer {27 name = ’Organizational Units ’,28 visible = true29 };30 enforce domain symbolic separationApp : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Separation {31 };32 enforce domain symbolic layerApp : SoCaVisualizationModel ::

VisibilityLayer {33 name = ’Deployed Application Systems ’,34 visible = true35 };36 where {37 markerOrg(model , separationOrg , layerOrg);38 markerApp(model , separationApp , layerApp);39 }40 }41

42 relation markerOrg {43 checkonly domain semantic model : SoCaStore2008 :: SemanticModel {44 };45 checkonly domain symbolic separationOrg : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Separation {46 };47 checkonly domain symbolic layerOrg : SoCaVisualizationModel ::

VisibilityLayer {48 };49 }50

51 relation markerApp {52 checkonly domain semantic model : SoCaStore2008 :: SemanticModel {53 };54 checkonly domain symbolic separationOrg : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Separation {55 };56 checkonly domain symbolic layerApp : SoCaVisualizationModel ::

VisibilityLayer {57 };58 }59

60 top relation OrganizationalUnitSeparationLayer {61 org : String;

75

62 checkonly domain semantic orgUnit : SoCaStore2008 ::OrganizationalUnit {

63 name = org ,64 model = model : SoCaStore2008 :: SemanticModel {65 }66 };67 enforce domain symbolic rectangleOrg : SoCaVisualizationModel ::

MapSymbols :: Rectangle {68 text = ft : SoCaVisualizationModel :: Types:: FormattedText {69 value = org70 },71 fillColor = fc : SoCaVisualizationModel ::Types ::Color {72 blue = 128,73 green = 128,74 red = 12875 },76 borderColor = bc : SoCaVisualizationModel ::Types ::Color {77 blue = 1,78 green = 1,79 red = 180 },81 separationRule = separationOrg : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Separation {82 }83 };84 enforce domain symbolic rectangleOrg : SoCaVisualizationModel ::

MapSymbols :: Rectangle {85 rulingLayer = layerOrg : SoCaVisualizationModel :: VisibilityLayer

{86 }87 };88 when {89 markerOrg(model , separationOrg , layerOrg);90 }91 where {92 markerRectangle(orgUnit , rectangleOrg);93 }94 }95

96 relation markerRectangle {97 checkonly domain semantic orgUnit : SoCaStore2008 ::

OrganizationalUnit {98 };99 checkonly domain symbolic rectangleOrg : SoCaVisualizationModel ::

MapSymbols :: Rectangle {100 };101 }102

103 top relation ApplicationSeparationLayer {104 app : String;105 org : String;

76

106 checkonly domain semantic source : SoCaStore2008 ::DeployedApplicationSystem {

107 name = app ,108 deploymentUnit = orgunit : SoCaStore2008 :: OrganizationalUnit {109 name = org110 },111 model = model : SoCaStore2008 :: SemanticModel {112 }113 };114 enforce domain symbolic rectangleApp : SoCaVisualizationModel ::

MapSymbols :: Rectangle {115 nestedRule = nesting : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Nesting {116 },117 text = ftApp : SoCaVisualizationModel :: Types:: FormattedText {118 value = app119 },120 fillColor = fcApp : SoCaVisualizationModel ::Types ::Color {121 blue = 255,122 green = 255,123 red = 255124 },125 borderColor = bc : SoCaVisualizationModel ::Types ::Color {126 blue = 1,127 green = 1,128 red = 1129 },130 separationRule = separationApp : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Separation {131 },132 rulingLayer = layerApp : SoCaVisualizationModel :: VisibilityLayer

{133 }134 };135 enforce domain symbolic rectangleOrg : SoCaVisualizationModel ::

MapSymbols :: Rectangle {136 nestingRule = nesting : SoCaVisualizationModel ::

ConstraintVisualizationRules :: Nesting {137 }138 };139 when {140 markerRectangle(orgunit , rectangleOrg);141 markerApp(model , separationApp , layerApp);142 }143 }144 }

Listing B.1: Cluster Map Transformer in QVT

77

List of Figures

1.1 Exemplary process support map [Er06] . . . . . . . . . . . . . . . . . . . . 2

2.1 An overview of model transformation [LI06] . . . . . . . . . . . . . . . . . 5

2.2 MDA metamodel description [OM03] . . . . . . . . . . . . . . . . . . . . . 6

2.3 Model-Metamodel relationship [LI06] . . . . . . . . . . . . . . . . . . . . . 7

2.4 The Ecore Kernel [IB08] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Exemplary cluster map showing which deployed application system is hostedat which organizational unit [Er06] . . . . . . . . . . . . . . . . . . . . . . 9

2.6 Semantic model of the map in Figure 2.5 [Er06] . . . . . . . . . . . . . . . 11

2.7 Information model of the map in Figure 2.5 [Er06] . . . . . . . . . . . . . . 11

2.8 Symbolic model of the cluster map in Figure 2.5 [Er06] . . . . . . . . . . . 11

2.9 Visualization model of the cluster map in Figure 2.5 [Er06] . . . . . . . . . 11

2.10 Semantic to symbolic model transformation . . . . . . . . . . . . . . . . . 12

2.11 Approach to Software Map Generation [Er06] . . . . . . . . . . . . . . . . 12

3.1 Feature diagram representing the top-level areas of variation [Ka90, Cz98] . 13

3.2 Symbols for feature diagrams [CH06] . . . . . . . . . . . . . . . . . . . . . 14

3.3 Transformation rules [CH06] . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Location determination [CH06] . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5 Rule scheduling [CH06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.6 Rule organization [CH06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7 Source-Target Relationship [CH06] . . . . . . . . . . . . . . . . . . . . . . 17

3.8 Incrementality [CH06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

78

3.9 Directionality [CH06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.10 Tracing [CH06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Exemplary configuration of a model transformation within ATL . . . . . . 22

4.2 QVT architecture according to [OM05b] . . . . . . . . . . . . . . . . . . . 27

4.3 Transformation Metamodel of the Cluster Map with QVT . . . . . . . . . 31

5.1 Exemplary cluster map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Exemplary cluster map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 Information model for the cluster map . . . . . . . . . . . . . . . . . . . . 38

5.4 Extract of the visualization model for the cluster map . . . . . . . . . . . . 38

5.5 Exemplary process support map . . . . . . . . . . . . . . . . . . . . . . . . 41

5.6 Information model for the process support map . . . . . . . . . . . . . . . 42

5.7 Exemplary visualization model of the process support map . . . . . . . . . 44

5.8 Cluster Map with maintenance costs . . . . . . . . . . . . . . . . . . . . . 47

5.9 Cluster Map showing application systems and their conformance of archi-tectural solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.10 Information model of the DeployedApplicationSystem and their conformanceof architectural solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.11 Aggregated Cluster Map with Interconnections . . . . . . . . . . . . . . . . 54

5.12 Information model for the aggregated cluster map . . . . . . . . . . . . . . 55

5.13 Extract of the visualization model for the aggregated cluster map . . . . . 55

79

Listings

4.1 Top relation ApplicationSeparationLayer . . . . . . . . . . . . . . . . . . . 29

5.1 Attribute helper setColorTuple . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Unique lazy rule setColor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3 Rule OrganizationalUnit2Rectangle . . . . . . . . . . . . . . . . . . . . . . 39

5.4 Helpers ordering business processes in a sequence . . . . . . . . . . . . . . 43

5.5 Rule SupportRelationship . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.6 Unique lazy rules are triggered from the SupportRelationship rule . . . . . 45

5.7 Import of the library libMaintenanceCosts . . . . . . . . . . . . . . . . . . 48

5.8 Child rule ApplicationSystem2Costs triggers the coloringMaintenanceCostshelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.9 Library libMaintenanceCosts . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.10 Child rule ApplicationSystem2ArchSol triggers the coloringArchitecturalSo-lution helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.11 Library libArchitecturalSolution . . . . . . . . . . . . . . . . . . . . . . . . 52

5.12 Child rules create polylines between rectangles . . . . . . . . . . . . . . . . 55

A.1 Cluster Map Transformer in ATL . . . . . . . . . . . . . . . . . . . . . . . 61

A.2 Process Support Map Transformer . . . . . . . . . . . . . . . . . . . . . . . 64

A.3 Aggregated Cluster Map with Interconnections Transformer . . . . . . . . 68

B.1 Cluster Map Transformer in QVT . . . . . . . . . . . . . . . . . . . . . . . 74

80

Bibliography

[BG01] Bezivin, J.; Gerbe, O.: Towards a Precise Definition of the OMG/MDA Frame-work, 2001.

[Bu04] Budinsky, F. et al.: Eclipse Modeling Framework: a developer’s guide. Addison-Wesley, Boston, USA, 2004.

[CH06] Czarnecki, K.; Helsen, S.: Feature-based survey of model transformation ap-proaches. IBM Systems Journal, 2006.

[Cz98] Czarnecki, K.: Generative Programming: Principles and Techniques of SoftwareEngineering Based on Automated Configuration and Fragment-Based Compo-nent Models. Phd thesis, Computer Science Department, Technical Universityof Ilmenau, 1998.

[Ec08a] Eclipse: Generative Modeling Technologies (GMT) project, 2008.

[Ec08b] Eclipse: openArchitectureWare, 2008.

[Ei08] Eichler, H.: Email correspondence with Mr. Eichler from ikv++ technologiesAG, 2008.

[Er06] Ernst, A. et al.: Using Model Transformation for Generating Visualizations fromRepository Contents - An Application to Software Cartography. Technical report,Technische Universitat Munchen, Chair for Informatics 19 (sebis), Munich, 2006.

[Fo08] Foundation, T. E.: Eclipse Modeling Project, 2008.

[IB08] IBM: EMF Developer Guide, 2008.

[JK05] Jouault, F.; Kurtev, I.: Transforming Models with ATL, 2005.

[Ka90] Kang, K. C. et al.: Feature-Oriented Domain Analysis (FODA) Feasibility Study.Technical report, Carnegie-Mellon University Software Engineering Institute,1990.

[KWB03] Kleppe, A. G.; Warmer, J. B.; Bast, W.: MDA Explained: The Model DrivenArchitecture: Practice and Promise. Addison-Wesley, 2003.

81

[LI06] group at LINA & INRIA, A.: ATL: Atlas Transformation Language, 2006.

[Mo04] Moore, B. et al.: Eclipse Development using the Graphical Editing Frame-work and the Eclipse Modeling Framework. http://www.redbooks.ibm.com/redbooks/pdfs/sg246302.pdf (cited 2008-01-26), 2004.

[OM03] OMG: MDA Guide Version 1.0.1. Technical report, Object Management Group(OMG), 2003.

[OM05a] OMG: MOF 2.0/XMI Mapping Specification, v2.1 (formal/05-09-01), 2005.

[OM05b] OMG: Revised Submission for MOF 2.0 Query/View/Transformation (ptc/05-11-01), 2005.

[OM05c] OMG: Unified Modeling Language: Superstructure, version 2.0 (formal/05-07-04). 2005.

[OM06a] OMG: Meta Object Facility (MOF) Core Specification, version 2.0 (formal/06-01-01), 2006.

[OM06b] OMG: OCL 2.0 Specification, Version 2.0 (formal/2006-05-01). 2006.

[Sc06] Schweda, C.: Architektur eines Visualisierungswerkzeugs fur Anwendungs-landschaften - Anforderungsanalyse und Realisierung von Kernkomponenten.Diploma thesis, Fakultat fur Informatik, Technische Universitat Munchen, 2006.

[se08] sebis: Enterprise Architecture Management Tool Survey 2008, 2008.

[So04] Sommerville, I.: Software Engineering. Pearson, Munchen, 6. Auflage, 2004.

[St73] Stachowiak, H.: Allgemeine Modelltheorie. Springer-Verlag, Wien, 1973.

[SU02] SUN: Java Metadata Interface (JMI), 2002.

[VS06] Volter, M.; Stahl, T.: Model-Driven Software Development. Wiley, 2006.

[WV03] van Wijngaarden, J.; Visser, E.: Program Transformation Mechanics: A clas-sification of Mechanisms for Program Transformation with a Survey of ExistingTransformation Systems, 2003.

82

Documents

Analysis and Application of Model Transformation Languages for