Bachelor of Engineering, IT Thesisetd.dtu.dk/thesis/220257/dip08_05.pdf · Bachelor of Engineering,...

Technical University of Denmark

Bachelor of Engineering, IT

Thesis

Generation of Web applications from UWE models

Jakob Frydensberg

Study no.: s020629

May 2008

Internal Report Number: IMM-B.Eng-2008-5

Supervisor: Hubert Baumeister, IMM, DTU

In cooperation with IBM Rational Denmark

Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk

This thesis was prepared at Informatics Mathematical Modelling, the Technical University of Denmark in cooperation

with IBM Rational Denmark.

The thesis is about implementing UML based Web Engineering and related transformations, as plug-ins to Rational

Software Modeler.

Lyngby, May 2008

Jakob Frydensber

Bachelor of Engineering, IT Generation of Web applications from UWE

Thesis Jakob Frydensberg

1

1 ABSTRACT

The task of this project is to implement a tool to model Web applications using the UML based Web Engineering

Method (UWE), and to generate Web applications from these models.

UWE consists of a conceptual, navigational and presentational model and is represented as UML diagrams using the

UWE profile. UWE is a method based on ideas from Model Driven Development (MDD) and implies use of

transformations between each model.

The tool will be based on the Rational Software Modeler and generates a Web application based on PHP and MySQL.

A case study will be used to exemplify the steps in going from one model to another.

As Rational Software Modeler is perfectly capable of modeling with UML models, the task is to apply the required

transformations to Rational Software Modeler. A transformation in Rational Software Modeler is created as an Eclipse

plug-in. The plug-in will be dependent on resources provided by Rational Software Modeler.

The implemented solution is able to transform from the conceptual model to the navigational model, from the

navigational model to the presentational model, and to generate executable code based on the conceptual,

navigational and presentational models.



2

2 TABLE OF CONTENTS

1 Abstract ..................................................................................................................................................................... 1

3 Introduction .............................................................................................................................................................. 4

4 Problem ..................................................................................................................................................................... 5

4.1 UWE and Rational Software Modeler .................................................................................................................. 5

4.2 Project Scope ........................................................................................................................................................ 5

4.2.1 Scope of the UWE implementation .......................................................................................................... 5

4.3 Case study ............................................................................................................................................................ 6

4.3.1 Description of the case study ................................................................................................................... 6

4.3.2 Scope of the case study ............................................................................................................................ 7

5 Methodologies .......................................................................................................................................................... 9

5.1 Model Driven Architecture ................................................................................................................................... 9

5.1.1 Model types ............................................................................................................................................ 10

5.1.2 Transformations ..................................................................................................................................... 10

5.1.3 Marking of elements .............................................................................................................................. 12

5.1.4 MDA and Web engineering .................................................................................................................... 12

5.2 UWE .................................................................................................................................................................... 13

5.2.1 Separation of concerns ........................................................................................................................... 13

5.2.2 Process .................................................................................................................................................... 13

5.2.3 UWE Metamodel .................................................................................................................................... 13

5.2.4 UWE Profile ............................................................................................................................................ 14


5.3 UWE and MDA .................................................................................................................................................... 20

6 Solution ................................................................................................................................................................... 22

6.1 RSM plug-ins ....................................................................................................................................................... 22

6.1.1 Domain Specific Languages .................................................................................................................... 22



3


6.2 Architecture ........................................................................................................................................................ 23


6.2.2 Plug-in Dependencies ............................................................................................................................. 24

6.3 The Profile .......................................................................................................................................................... 27

6.4 Shared resources ................................................................................................................................................ 28

6.5 Content to Navigation Transformation .............................................................................................................. 29

6.6 Navigation to Presentation Transformation ....................................................................................................... 32

6.7 UWE_XML Ecore Model ..................................................................................................................................... 35

6.8 UWE models to PHP Code Transformation ........................................................................................................ 37

6.9 Exemplar ............................................................................................................................................................. 42

6.9.1 Model ..................................................................................................................................................... 43

6.9.2 View ........................................................................................................................................................ 43

6.9.3 Control .................................................................................................................................................... 44

6.9.4 DAO ........................................................................................................................................................ 45

6.9.5 Database ................................................................................................................................................. 45

6.10 Known issues and bugs .................................................................................................................................. 46

7 Future work ............................................................................................................................................................. 47

8 Conclusion ............................................................................................................................................................... 48

9 Abbreviations .......................................................................................................................................................... 49

10 References ............................................................................................................................................................... 51

11 A: UWE metamodel ................................................................................................................................................. 53

11.1 Navigation package........................................................................................................................................ 53

11.2 Presentation metamodel ............................................................................................................................... 54

12 A: CD ........................................................................................................................................................................ 56



4

3 INTRODUCTION

When developing software applications it is common to use UML as the notation when developing and designing the

application. This approach is well known to many architects and developers who also are involved in developing web

applications.

UML in itself is a “generic” language that can be used to model a wide variety of software application. This ability is

what makes is so widely used. In relation to developing Web application, UML in itself does not provide for modeling

of navigation and presentation of the application. Therefore an extension of UML is needed. UML has a build in

extension mechanism that makes this possible.

UML based Web Engineering (UWE) is an approach to develop Web applications using UML based on the ideas of

Model Driven Development. UWE provides an extension to UML that makes the modeling of navigation and

presentation easier. UWE also suggests use of automated transformations between each model.

The aim of applying automated transformations is to speed up the development process, and to avoid errors to occur

when transforming the model manually. By speeding up the development process, the cost of developing the Web

application will be reduced, thus the time to marked will be reduced, giving the organizations applying UWE a

competitive advantage over the other players in the marked.

Currently UWE is only implemented in one tool, ArgoUWE. Being represented in as many tools as possible will most

likely increase the chance for UWE to be accepted by the industry. The aim of this project is to Implement as much of

the transformations described by UWE as possible in Rational Software Modeler, within the timeframe given. Rational

Software Modeler is chosen based on its unprecedented capabilities within the scope of Model Driven Development.


Thesis - Problem - Jakob Frydensberg

5

4 PROBLEM

The UML based Web Engineering (UWE) methodology has, as far known, only been implemented in one tool, namely

ArgoUWE, which will most likely not promote wide industry acceptance. As the Eclipse Modeling Framework (EMF) is

becoming the defacto standard for software modeling, the UWE methodology should therefore be represented based

on this technology.

IBM Rational has experienced wide interest in their modeling tools, in Denmark especially from the banking and

insurance industry. Some enterprises that use .NET as their enterprise platform actually buys either Rational Software

Modeler (RSM) or Rational Software Architect (RSA), due to their unprecedented capabilities of modeling enterprise

scale applications and their outstanding capabilities within the scope of Model Driven Development (MDD). Both RSM

and RSA are primarily targeted at the Java platform.

4.1 UWE AND RATIONAL SOFTWARE MODELER

The Rational portfolio is Eclipse based, which implies that the tools in the portfolio are relatively easy to extend.

Simply, basic Eclipse plug-ins would be compatible with the tools in the Rational portfolio.

Some types of plug-ins, for instance a model to model transformation requires resources provided by RSM. This

means that implementing UWE using tools like RSM or RSA would make the implementation of UWE dependent on

different parts of the Rational portfolio.

Only relying on free of charge Eclipse plug-ins would not provide for model to model transformations, or at least not

with the same flexibility and power as provided by RSM.

RSA in its current version supports UML 2.0, where RSM supports UML 2.1. The final implementation of UWE is

therefore based on RSM. By implementing UWE in RSM the implementation does not comply with the current release

of RSA, but it is expected that the next release of RSA supports UML 2.1. Thus the lifecycle of the implementation of

this project is expected to be longer, than it would have been if implemented in the current version of RSA.

4.2 PROJECT SCOPE

Implementing the entire UWE method would be a big task and not possible within the timeframe of this project.

The aim of this project is to demonstrate the basics of the transformations related to UWE by implementing the

transformations in RSM.

A case study will be used to exemplify the UWE method, as described in section 4.3.

4.2.1 SCOPE OF THE UWE IMPLEMENTATION

UWE implies transformations and UML modeling capabilities as part of the UWE approach. The modeling capabilities

are already supplied by RSM. Hence the scope of this project is to implement the transformations specified by UWE in

going from the content model to executable code.

The transformations implemented during this project are:



6

1. Content model to navigation model transformation.

2. Navigation model to presentation model transformation

3. UML models to executable code transformation.

Transformation no. 3 implies a model to text transformation, and in order to implement this, RSM requires an

exemplar representing a web application. An exemplar in this sense is a Web application capable of handling the use

cases specified by the case study. RSM uses the exemplar to generate templates for the transformation.

The exemplar of the Web application should be written in PHP and supplemented with a MySQL database, since the

person behind the case study knows these technologies. See section 4.3.

For the transformations to work properly marking of the models is needed, see section 5.1.3. Therefore the UML

profile defined by UWE will be implemented, but only including the stereotypes.

The consequence of this is that the implementation will not provide the ability to validate the models before and after

a transformation is executed, meaning that when trying to transform an invalid model the transformation might

produce unexpected output or crash. However modeling UWE models based on this implementation would require a

detailed understanding of the metamodel.

RSM provides a basic user interface for modeling with UML. When modeling UWE models it would be desirable to

have a similar user interface support of UWE specific classes and associations. However this has been put out of scope

in order to focus on implementing the transformations. Modeling with UWE in RSM based on this project will

therefore be slightly cumbersome.

The requirement modeling and transformations involving these models are also out of scope by advice from my

supervisor.

4.3 CASE STUDY

A case study will be used to exemplify the implementation of the UWE transformations. The case study will be

described in more detail during the report but the overall picture and selected use cases will be outlined here.

4.3.1 DESCRIPTION OF THE CASE STUDY

A close friend of mine, Henrik Bjørner, wants to build a Web portal targeting the jewelry industry as well as general

gold and silver industry like industrial design, watches etc. The users of the portal are expected to be both the

companies operating within the industry, and the consumers interested in products provided by the industry.

The basic idea of the portal is to provide an overview of what is going on in the industry. This idea is highly inspired by

the various dating sites on the Internet, where the user can chose between different account types that offers

different services. In this case the consumer can open a free off charge account providing services targeted to the

consumer segment. Companies within the market can chose between various accounts, in accordance to their specific

role in the industry.

The portal is also inspired by sites like www.aok.dk where the user for instance can gain general information regarding

a specific shop, a specific product or for instance special events that a company may offer, as well as activities

provided by the industry.

http://www.aok.dk/



7

4.3.2 SCOPE OF THE CASE STUDY

As mentioned not all parts of the case study will be addressed. Only the use cases where a user can browse and view

products and companies will be included. Different user rights are also out of scope. See Figure 1.

Figure 1 - Use case diagram of the case study

4.3.2.1 USE CASE DESCRIPTIONS

Brief use case descriptions are used to outline the use of the system.

4.3.2.1.1 BROWSE COMPANY PROFILE:

A user clicks on the company menu item in the main menu. The system generates a list of the companies in the

system. The list is displayed to the user.

4.3.2.1.2 VIEW COMPANY PROFILE:



8

A user clicks on a specific company from a list of companies. The system looks up information related to the specific

company and displays the information to the user.

Alternatively the user clicks on a company link within the view of a product. The system then looks up information

related to the specific company related to the product, and displays the information to the user.

4.3.2.1.3 BROWSE PRODUCTS:

A user clicks on the product menu item in the main menu. The system generates a list of the products in the system.

The list is displayed to the user.

Alternatively a user clicks on the products link within a view of a company profile. The system then generates a list of

all the products specifically related to the company. The list is displayed to the user.

4.3.2.1.4 VIEW PRODUCT:

A user clicks on a specific product form a list of products. The system looks up information related to the product, and

displays it to the user.


Thesis - Methodologies - Jakob Frydensberg

9

5 METHODOLOGIES

This chapter describes the main theories that are applied during this project.

This includes outlining of Model Driven Architecture (MDA) and UML based Web Engineering (UWE).

5.1 MODEL DRIVEN ARCHITECTURE

Within software development it is common to use the Unified Modeling Language (UML) during the development

process, to model different levels of abstraction as part of designing and documenting an application.

To set the record straight, instead of MDA some uses the term Model Driven Development (MDD), both are

trademarks of OMG and MDD is a acronym for MDA [2]. In this project the term MDA will be used.

MDA is an initiative of the Object Management Group (OMG) that relies on using models as part of the development

process, and implies a structured use of automated transformations (from now on referred to as transformations)

from model to model and from model to code.

The goal of MDA is to separate the business and application logic form the underlying execution platform technology

in a way that 1) changes in the underlying technologies will not affect the existing applications and 2) business logic

can evolve independently form the underlying technologies [2].

It is stated that four principles underlie OMG’s view of MDA, [1]:

Models expressed in a well-defined notation are a cornerstone in understanding systems for enterprise-

scale solutions.

The building of systems can be organized around a set of models by imposing a series of transformations

between models, organized into an architectural framework of layers and transformations.

A formal underpinning for describing models in a set of metamodels facilitates meaningful integration

and transformation among models, and is the basis for automation through tools.

Acceptance and broad adoption of this model-based approach requires industry standards to provide

openness to consumers and foster competition among vendors.

The 2 goals of MDA and the underling principles are perfectly aligned while the principles implies using of models

organized in layers, which in this project is interpreted as focusing on different levels of abstraction and concerns and

transformations between them. This opens the door for complete separation of the business domain and the actual

implementation and allowing those to evolve independently.

The MDA guide compares MDA to constructional engineering which clearly states the vision of MDA; to automate the

development process of software applications by means of transformations.

“Imagine if the construction worker could take his blueprint, crank it through a machine, and have the foundat ion of

the building simply appear. Not likely outside the Jetsons’ world, but an everyday occurrence in the software world.”

[3].



10

But the vision goes further. If we want to connect existing applications, generation of the infrastructure can be done

automatically, and if a new and better technology emerges it can be applied to an existing application or system with

relative ease.

“Even better, when we need to connect these “buildings” to each other we can automate the generation of bridges and

translators based on the defining models; and when a new, more fire-resistant type of steel is invented, we can

regenerate for the new infrastructure.” [3].

By applying MDA as a software development process, the organization applying it is aiming at reducing time to market

while the developers don’t have to spend a lot of time transforming models to other models. The great advantage is

to avoid spending, in some cases thousands of man hours, implementing the solution in some high-level programming

language like J2EE or .NET, and consequently a significant cost reduction of the development process. Another aim is

that the generated code is based on templates created by highly skilled programmers, leading to a higher quality of

the generated code. This approach is considered less error prone than to implement the application by hand.

5.1.1 MODEL TYPES

The principles behind MDA are supported by the definition of a set of model types, which are given in the MDA Guide

[3]. The model types are described in terms of other definitions within the MDA guide. The interested reader is

referred to the MDA guide for further readings.

5.1.1.1 COMPUTATION INDEPENDENT MODEL (CIM)

A computation independent model is a view of a system from the computation independent

viewpoint. A CIM does not show details of the structure of systems. A

CIM is sometimes called a domain model and a vocabulary that is familiar to the practitioners of the

domain in question is used in its specification.

5.1.1.2 PLATFORM INDEPENDENT MODEL (PIM)

A platform independent model is a view of a system from the platform independent viewpoint. A PIM

exhibits a specified degree of platform independence so as to be suitable for use with a number of

different platforms of similar type.

5.1.1.3 PLATFORM SPECIFIC MODEL (PSM)

A platform specific model is a view of a system from the platform specific viewpoint.

A PSM combines the specifications in the PIM with the details that specify how that system uses a

particular type of platform.

5.1.2 TRANSFORMATIONS

CIM are typically used to describe the requirements of the application being developed.



11

The PIM and PSM are used to describe models at different levels of abstraction. For instance a PSM could be referring

to the operating system, a Java, .NET or PHP implementation or a model of a specific level of abstraction that includes

information about the platform.

PIM and PSM change in relation to the system under development. For instance from the view of a developer,

developing the Java Virtual Machine used to execute Java applications. The compiled java application is the PIM and

the operating system in this case is the PSM. But with the view of a developer developing a java application, some of

the UML models used would represent the PIM and Java represents the PSM.

Transformations can be applied within the same level of abstraction, for instance from a PIM addressing one concern

to another PIM addressing another concern, see Figure 2.

Figure 2 - PIM to PIM transformation

Transformations can also be applied in going from one level of abstraction to another, for instance from a PIM to a

PSM, see Figure 3.

Figure 3 - PIM to PSM transformation

The relation between the PIM and the PSM is that from the view of the PIM the PSM represents a more detailed

description of the platform. From the view of the PSM the PIM is not dealing with concerns specific for the PSMs level

of abstraction [3].

Often multiple models are used when developing an application. In such cases many transformations can follow each

other, see Figure 4.

PIM

PSM

PIM PIM



12

Figure 4 - Many transformations following each other

In order for a transformation to produce the output model in a structured manner, a metamodel of the PIM and PSM

is required, as mentioned in section 5.1. OMG suggests using metamodels based on Meta Object Facility (MOF) [3]. An

example of this is UML that is defined using MOF as it’s metamodel, but it could also be a Domain Specific Language

(DSL) that uses MOF as metamodel. Yet another example is a DSL that is defined using UML, hence the meta-

metamodel of the DSL would be MOF.

5.1.3 MARKING OF ELEMENTS

For the transformation to be able to perform the mapping between elements in the PIM model to elements in the

PSM model, some form of marking the elements is needed. For example using a UML model PIM and transforming it

to another UML model as the PSM, any class in the PIM could be mapped to any class in the PSM. This would in many

cases not assist in moving from one level of abstraction to another. If instead the PIM UML model is marked, for

instance using stereotypes from a UML profile, a particular “type” of class in the PIM could be transformed into a

pattern in the PSM UML model. This would significantly help in moving from one level of abstraction to another.

5.1.4 MDA AND WEB ENGINEERING

Basically there are 3 reasons that MDA is well suited for Web engineering [2].

1) There is a precise set of concerns to address, for instance, navigation, presentation and business processes.

2) The basic types of Web applications are well known. A few examples could be: document-centric, transactional,

workflow-based, collaborative, etc.

PIM

PSM



13

3) The set of architectural patterns and structural features used in Web systems is reduced and precisely defined. For

example the Composite pattern [7] is often used for composing the presentation of the Web application. The book

“Core J2EE Patterns – Best Practice and Design Strategies” [8] provides a good overview of patterns frequently used in

the field of enterprise scale applications which includes Web engineering.

Applying the MDA model types when developing Web applications, the requirements and domain modeling belongs

to the CIM, the set of concerns content, navigation, presentation etc. belongs to the PIM, and implementation specific

models belongs to the PSM.

5.2 UWE

UML based Web Engineering (UWE) is an approach to develop Web applications that recommends the use of UML

models to address the different concerns. UWE suggests using transformations in all phases of the development

process. This provides a framework for automated generation of Web applications [4], where a person such as a

business domain expert, IT architect, developer, etc. enriches each model as the development process progresses.

5.2.1 SEPARATION OF CONCERNS

The concerns addressed by UWE are the requirements, content, navigation structure, presentation, and business

processes. UWE recommends use of at least one type of model for each type of concern [4].

Regarding tracking of user behavior, UWE suggest use of Aspect-Oriented Modeling but the implementation of this is

still subject of research [4][6].

The concern regarding architecture of the Web application is also addressed by UWE, and this is also subject of further

research [4][6].

5.2.2 PROCESS

In the process of developing Web applications, the “UWE way” is somewhat similar to other well known development

processes like Unified Process (UP) or others alike. These development processes are often divided into phases with

different focus such as requirements, design and implementation. However UWE differentiates by focusing on phases

related to the concerns of Web application development. Focus lies first on the requirements, then the content, the

navigation structure, the presentation and finally the implementation. The business processes is initially modeled as

part of the requirements, and refined in the navigation structure.

UWE suggests modeling the functional requirements with use cases and the business processes related to a specific

use case with activity diagrams. The content is modeled using a standard UML class diagram without extension.

Modeling the navigation structure is also done in a UML class diagram, but the metamodel of the navigation structure

is reflected by the UWE profile. Likewise the presentation model is modeled in a UML class diagram with its own

metamodel reflected by the UWE profile.

5.2.3 UWE METAMODEL

As mentioned, UML is used as the basic language for the models in UWE. The UWE metamodel is therefore an

extension of UML. More precisely, the metamodel is modeled as a light weight extension of UML, which means that it

is based on inheritance of elements of the UML metamodel. As the UML metamodel is profileable the UWE



14

metamodel will be profilabe [4][5]. The actual implementation of the metamodel is therefore done as a UML profile

reflecting the semantics of the UWE metamodel.

An advantage of the light weight extension is that the extension can be implemented in any UML tool that supports

UML profiles [5] by applying the already implemented UML profile. On the other hand, when editing the UML

metamodel, the UML metamodel implemented by modeling tools would have to be edited as well, which would most

likely lead to challenges implementing UWE in a broad variety of tools.

The extension consists of adding 2 packages, one called Core and another one called Adaptivity. See Figure 5. The Core

package consists of 5 packages, one for each concern of Web engineering. The crosscutting of adaptation is depicted

by the dependency of Adaptivity on Core [5].

Figure 5 - Overview of the UWE metamodel, [5]

As stated earlier, content modeling is done in standard UML.

An overview of the navigation and presentation packages is to be found in Appendix A. The interested reader is

referred to [5].

5.2.4 UWE PROFILE

UWE provides a UML profile, to which the UWE metamodel is mapped. The semantics of each stereotype in the

profile corresponds to the element of the same name in the UWE metamodel [5].

All the stereotypes are listed in Table 1 - UWE stereotypes.

UWE stereotype UML base class Used in Icon



15

«anchor» class presentation model

«anchored collection» class presentation model

«button» class presentation model

«choice» class presentation model

«form» class presentation model

«guided tour» class navigation model

«image» class presentation model

«index» class navigation model

«menu» class navigation model

«navigation class» class navigation model

«navigation link» association navigation model

«navigation property» property navigation model

«page» class presentation model



16

«presentation class» class presentation model

«presentation group» class presentation model

«presentation property» property presentation model

«process class» class navigation/presentation model

«process link» association navigation model

«process property» property navigation/presentation model

«query» class navigation model

«text input» class presentation model

«text» class presentation model

«user action» action process model

Table 1 - UWE stereotypes


As already mentioned UWE suggest use of transformations between the models of each concern. UWE defines

transformation rules for each step from requirement to presentation [4].

Based on the use cases of the case study in section 4.3.2.1, a content model is created. See Figure 6. As the scope of

the project is to deal with the transformations and not the modeling, how the content model is created will not be

described. The interested reader is referred to [4] for detailed descriptions of how to model with UWE.



17

Figure 6 - Content model of the case study

The transformations relevant within the scope of this project are described here.

MDA suggest use of MOF-QVT as the standard language to describe transformations [2], but due to limited knowledge

of this language pain text is used instead, often exemplified with diagrams.

5.2.5.1 CONTENT TO NAVIGATION TRANSFORMATION

The content model of the use case will be used to exemplify the transformation rules.

Transformation Rule 1.

Each class in the content model is mapped to a navigation class in the navigation model [4].

In order to maintain traceability between the content class and the navigation class, the navigation class will have

the same name as the content class [4], and the navigation class will have a property of the content class [5].

See Figure 7. Here the class Company in a) represents the class being transformed and b) is the outcome of the

transformation. The arrows illustrate what is mapped to what.

Figure 7 - Content to Navigation rule 1

a) b)



18


Each association with multiplicity one-to-one in the content model is mapped to 2 navigation links in the

navigation model, one pointing opposite of the other, and both connecting the navigation classes corresponding

to the classes connected by the association in the Content model [4].

The properties in the content class that represents an association are mapped to navigation properties in the

navigation class [5].

An Access Primitive should be added between the navigation classes where the multiplicity of the association is

greater than 1 [4]. The naming of the Access Primitive is composed from the name of the target class and the type

of Access Primitive.

Figure 8 illustrates a one-to-many relation between the class Company and the class Product in the content

model, shown in part a). In part b) the output of the transformation becomes a navigation link connecting Product

to Company, and an Access Primitive in this case an Index, has been added between the Company and the

Product navigation classes in the navigation model. Also the one-to-many relation is represented by the

navigation link between the index class and the Product navigation class. Part c) illustrates that the property

connected to a navigation link is a navigation property.

Normally when modeling the navigation structure, the stereotypes and multiplicity of navigation links would not

be shown. In this case they are shown to provide for a more detailed understanding.



19



If a class in the content model is connected to other classes with more than one outgoing association, a menu in

the navigation model should be added between the navigation classes [4].

The name of the menu class is composed from the name of the source class followed by “Menu” to indicate that

it is the menu related to the source class.

As shown in Figure 6 on page 17, the Product has more than one association connecting it to other classes. The

transformation rule result in a menu being added along with the associated navigation links. See Figure 9.

a) b)

c)



20


5.2.5.2 NAVIGATION TO PRESENTATION TRANSFORMATION


Each navigation node in the navigation model is mapped to a presentation class in the presentation model [4].

By default the presentation class uses the same name as the navigation node [4].

Each attribute of a navigation class is presented with an appropriate UI element [4].

An association to the navigation node is created in order to maintain traceability [5].

5.2.5.3 UML MODELS TO EXECUTABLE CODE TRANSFORMATION

It has only been possible to fine sparse documentation on how UWE addresses the generation of code based on the

UWE models. Therefore the rules will be specified as part of the implementation section.

5.3 UWE AND MDA

As mentioned in section 5.2.3 – UWE metamodel. The metamodel of each concern in UWE is based on UML. UML is

defined in terms of MOF, therefore the meta-metamodel of UWE is MOF and hence compliant with MDA.

UWE addresses the different concerns of the development process using separate models, in order to reach the goal

of being able to separate the business processes and the technological platforms apart, just as MDA aims.



21

Another similarity between UWE and MDA is the recommendation to use transformations at each step in the

development process.

This illustrates that UWE is perfectly aligned with the ideas of MDA [2].


Thesis - Solution - Jakob Frydensberg

22

6 SOLUTION

This chapter describes the implementation of UWE in RSM.

At first, a general description of how transformations and DSL’s are treated by RSM is given. Then the architecture of

the solution will be described, including how the transformations are connected. Finally the plug-in dependencies in

this project, and the implementation of each plug-in will be described.

6.1 RSM PLUG-INS

RSM out of the box provides the ability to create models using UML and UML profiles, consequently lightweight

extensions of UML are possible.

As already mentioned in section 4.1, RSM is based on Eclipse. Everything in Eclipse is essentially a plug-in, except from

a small run-time kernel. This means that RSM is an Eclipse plug-in. The way transformations and DSL’s are created in

RSM is by creating an Eclipse plug-in [9].

6.1.1 DOMAIN SPECIFIC LANGUAGES

As mentioned in section 5.1.2 a Domain Specific Language (DSL) is a language designed to address a specific domain in

order to raise the level of abstraction. MDA suggests using DSL’s based on MOF. The Eclipse Modeling Framework

(EMF) provides the ability to create models. EMF defines ecore models, which are the EMF implementation of MOF.

For instance UML is implemented as an ecore model.

This means that for instance DSL’s can be created as an ecore, hence based on MOF. Alternatively the extensibility

mechanism of UML can be used, e.g. a UML Profile to create a DSL that in the end would be defined using the UML

ecore, hence MOF.

If the DSL is created as an ecore model, it is necessary to create a new editor specific to this ecore model, in order to

use it. RSM provides tooling support to auto generate such editors. The editor for an ecore model is a plug-in to

Eclipse.

When creating the DSL’s based on UML as a UML profile, it is not necessary to create a new editor, as the UML editor

in RSM is already capable of handling UML profiles. However other issues arise. In this project some of the

transformations use the UWE profile and since the UWE profile is created in the same workbench as the

transformations, it is necessary to deploy the profile along with the transformations in order to use the UWE profile in

the run-time workbench. This can be done in 2 ways, by deploying the profile using the file system or by making the

profile in a plug-in [10]. In this project the profiles are deployed using a plug-in, as this eases the installation process of

the UWE implementation, thus when editing the profile, the changes will be immediately reflected in the depending

projects.


There are 2 types of transformations, Model to Text (M2T) transformations and Model to Model (M2M)

transformations.



23

JET transformations are used to handle M2T transformations. JET used to be part of the Eclipse Modeling Framework

Technology (EMFT) project, but has recently been moved to the Model 2 Text project. In the current version of RSM,

JET still belongs to EMFT.

JET was formerly known as Java Enabler Templates; however, the nomenclature has changed to simply JET because it

is no longer limited to Java expressions. XML-based templates can now be used which makes building tools with JET

programming language agnostic [11].

M2M transformations are apparently not addressed by any free Eclipse projects, but RSM provides the technology

needed to create these transformations.

A M2M transformation is made by creating a plug-in project with the special capability transformation mapping

provided by RSM. The M2M transformation rules are written in Java.

The mapping rules are applied in the plug-in project by creating a map in a UI based mapping editor.

Basically there are 3 mapping types available.

One called Move, which copies the content of a property from the source model to the target model, but this only

works when moving primitive types like string, integer etc.

Another type is a submap, which as implied in the name allows for making a sub map. For instance if the owned

attributes of a UML class should be moved, a simple move rule cannot move this because it is a collection. However

with a submap each element in the UML Property can be moved one at a time using the move mapping.

When dealing with more complex mappings, for instance where an association from the UWE content model is

transformed into a set of navigation links and indexes, a custom rule can be created. This can be done by creating a

Java method or a Java class depending on the complexity of the mapping, but which one to choose is up to the

developer implementing the transformation.

Executing a transformation will not make the mapping from the source model to the target model directly. An

intermediate temporary model will automatically be created, and the transformation will map the source model to

this temporary model. The user is then asked to select which parts of the temporary model should be added to the

target model.

6.2 ARCHITECTURE

The description of the architecture of the UWE implementation is divided into two sections. One section describes the

different models and the transformations between them. The other section describes the dependencies between the

different plug-in projects.


Implementing the project requires some considerations on how to structure all the transformations.

The presentation model contains all information in the navigation model, and the content model. Therefore intuitively

the code should be generated based on this model, or perhaps a PSM specific for a web application, where the

transformations are connected in a “straight line”. At the time of developing the solution, the “UWE Metamodel and

Profile” [5] reference was unavailable, resulting in lack of knowledge of how to manage the traceability between the



24

models as described in section 5.2.5.1 and section 5.2.5.2. The solution is based on an ecore model referring to the

presentation model, the navigation model and the content model. Then transforming this to a PSM specific to the

Web application. Finally a transformation from that PSM to source code is created. Execution of the Web application

specific model will automatically trigger the transformation that generates the source code. Figure 10 illustrates the

different models and the transformations between them. A model is represented as a UML package with a stereotype

defining the type of model. To illustrate the transformations, UML Dependencies are applied using text to describe the

type of transformation.

Figure 10 – Models and Transformation structure

6.2.2 PLUG-IN DEPENDENCIES

The different transformations and Ecore models are all plug-in projects and all of them are dependent on other plug-

ins. Figure 11 shows the dependencies between the plug-ins created during this project. To simplify the illustration,

the plug-ins containing editors for different models are excluded, except for the profile. Thus only the plug-ins

containing the model are shown. A plug-in is shown as a UML class marked with the stereotype <<Plug_in_Project>>.

The dependencies are illustrated with normal UML dependency relation. Comments have been added to each plug-in

project to inform of its purpose in the system.

PIM

PSM

Platform



25

Figure 11 - Plug-in dependencies

6.2.2.1 MANAGING PLUG-IN DEPENDENCIES



26

The transformation between the UWE models, content to navigation and navigation to presentation both need to

apply stereotypes to the target model, and make different checks. Since these methods are more or less identical,

another plug-in project is created to manage shared operations and constants. When creating and setting up the

shared plug-in, the transformation plug-ins have to be made dependent on the shared plug-in. This is done by adding

a dependency in the Dependencies tab in the MANIFEST.MF file in the transformation project. See Figure 12.

Figure 12 - Dependencies of a Plug-in Project

In order for the transformation plug-ins to use the shared plug-in, the shared plug-in should be activated when other

resources tries to load classes within it. This is done by selecting the “Activate this plug-in when one of its classes is

loaded” option in the Overview tab of the MANIFEST.MF file in the shared plug-in. See Figure 13. In this project, all

projects where other projects depend on them, are activated when classes is loaded from them.



27

Figure 13 - Activating a plug-in project

6.3 THE PROFILE

The profile is managed in two projects, one called uwe.profile and one called uwe.profile.tooling.

When applying a change to the profile, the change should be added in the uwe.profile project. This way the

uwe.profile.tooling project can be automatically updated to reflect the change. If changes were made in the profile in

uwe.profile.tooling project, the changes would have to be applied manually.

Project name: uwe.profile

Plug-in Dependencies:

n/a



28

Description:

The uwe.profile project is a UML Profile Project, only containing the profile and it is not a plug-in project. Based on

that project the uwe.profile.tooling project is auto generated. The uwe.profile.tooling project is a plug-in project

containing a copy of the profile in the uwe.profile project.

Generating the uwe.profile.tooling project is done by right clicking the profile in the Project Expore and select

“Generate Profile Tooling…”. A wizard will assist in creating the project.

During the development process, the implementation of the profile was initially based on information from [4] since

[5] was unavailable at the time. In the final hours the profile is refactored based on information from [5]. The

refactored edition of the profile is aware of the generalization relationship between the stereotypes, but the

constraints specified in the UWE metamodel [5] are not implemented.

The transformations have not been adapted to the new profile in the sense that they are not implementing the

traceability suggested in [5].

Project name: uwe.profile.tooling


com.ibm.xtools.uml.ui.diagram;bundle-version="[7.0.0,8.0.0)",

org.eclipse.ocl.uml;bundle-version="[1.1.0,2.0.0)",

org.eclipse.gmf.runtime.emf.ui.properties;bundle-version="[1.0.2,2.0.0)",

org.eclipse.gmf.runtime.diagram.ui;bundle-version="[1.0.1,2.0.0)",

org.eclipse.uml2.uml.edit;bundle-version="[2.1.0,3.0.0)";visibility:=reexport,

org.eclipse.emf.query.ocl;bundle-version="[1.1.0,2.0.0)";visibility:=reexport,

com.ibm.xtools.uml.msl;bundle-version="[7.0.0,8.0.0)",

com.ibm.xtools.common.ui.reduction;bundle-version="[7.0.200,8.0.0)",

com.ibm.xtools.common.ui.wizards;bundle-version="[7.0.200,8.0.0)",

com.ibm.xtools.modeler.ui;bundle-version="[7.0.0,8.0.0)"

Description:

This plug-in is primarily used to deploy the profile, but it also contains other things such as a palette containing all the

profiles. This palette can be used when modeling with the profile.

6.4 SHARED RESOURCES

Project name: uwe.shared



29


org.eclipse.ui,

org.eclipse.core.runtime,

org.eclipse.uml2.uml,

uwe.profile.tooling

Description:

This Plug-in basically contains two classes. One called Constants, which manages constants used in the

transformations between the UWE models. This could for instance be names of stereotypes.

The other project is called ModelHelper. This class contains different supporting classes used when dealing with UML

models, such as a method to apply stereotypes to elements in the model, or a method to locate a named element in

the model.

6.5 CONTENT TO NAVIGATION TRANSFORMATION

Project name: uwe.transform.content2navigation


org.eclipse.ui,


org.eclipse.emf.ecore,

org.eclipse.gmf.runtime.common.core,


com.ibm.xtools.transform.authoring.uml2,

com.ibm.xtools.modeler.ui,

org.eclipse.uml2.uml.resources,

uwe.shared,

uwe.profile.tooling

Description:

This plug-in project is the implementation of the transformation from the UWE content model to the UWE navigation

model described in section 5.2.5.1.

First a mapping between the source model and the target model is created. A submap between the packaged

elements collection is created, which connects the source and the target model. The purpose of the submap is to



30

create a mapping between each class in the source model to the classes in the target model. Figure 14 shows the

submapping. Note also that the name of the submap is shown at the button of Figure 14.

Figure 14 - Model 2 Model mapping

The Class2NavigationClass mapping is composed from three mappings. One moves the name of the source class to the

navigation class. Two custom mappings are also created, one of them mapping the owned attribute collection

between the source and the target classes, and the other handling the associations connected to the source class. See

Figure 15.



31

Figure 15 - Class 2 Navigation Class Mapping

The custom mapping handling the owned attribute collection is simply a method that checks if the property is part of

an association. If it is part of an association it is ignored, and if not the property is mapped to the target class. The

method is called executeOwnedAttributeToOwnedAttribute_Rule and is located in the class

Class2NavigationClassTransform that is auto generated. The class handles the Class2NavigationClass rule that are

shown in Figure 15.

Handles associations

Handles ownedAttribues

Handles associations

Handles attributes



32

The custom mapping handling the associations connected to the source class is handled in its own class. The reason

for this is that the mapping of an association results in a structure, and therefore is relative complex. This class is

named ContentAssociation2navigation and extends RuleExtension. The empty class with the proper extension is auto

generated.

The handling of an association will always be executed twice, since the association is connected to two classes, and

the handling of the association will be triggered for each class. Therefore first it should be checked if both the classes

already exist in the target model. If so, the navigation structure is created, if not the execution of the rule will

terminate.

The creation of the navigation structure is done based on the association in the source model. For each property in

the association, the class associated with it is located within the target model. Based on the multiplicity of the

property, a navigation link or an index connected with navigation links will be created connecting the two classes. As

the properties of the association are handled one at a time, the navigation structure will be able to handle both one-

to-one, one-to-many, and many-to-many associations, as well as creating the proper navigation structure.

This implementation satisfies most of the transformation rules specified in section 5.2.5.1 by:

mapping each class in the content model to a navigation class in the navigation model

Creating the proper navigation indexes and navigation links connecting the classes in the

navigation model.

Creation of menus when multiple associations are connected to a class in the source model is not implemented due to

time constraints. Also the association to the content class has not been implemented as [5] was unavailable during the

development process.

6.6 NAVIGATION TO PRESENTATION TRANSFORMATION

Project name: uwe.transform.navigation2presentation


org.eclipse.ui,





com.ibm.xtools.transform.authoring.uml2,

com.ibm.xtools.modeler,

uwe.shared,

uwe.profile.tooling



33

Description:

This plug-in project is the implementation of the transformation from the UWE navigation model to the UWE

presentation model described in section 5.2.5.2.

First a model to model mapping is created as in the implementation of the content to navigation transformation

described in section 6.5.

Each navigation node in the navigation model is to be transformed into presentation classes. When creating the

mapping, the generalization relationship between stereotypes is not taken into account, for instance, a navigation

class is not recognized as a navigation node even though it extends the navigation node. This means, that a submap

for each stereotype that extends the navigation node should be created as part of the transformation. In order to

simplify the implementation, it is assumed that only classes applied with a stereotype extending the navigation node

is represented in the navigation model. This way one map taking a class as input and producing a corresponding

presentation class would be enough.

The name of the source class is moved to the name of the target presentation class. The owned attribute collection is

handled with a custom transformation, created as a separate class named Property2UIelement. See Figure 16.



34

Figure 16 - Class to Presentation Class Mapping

When handling properties, the name of the property will be used as the name of the UI element. The UIElement will

be created as a class in the presentation model, unless a class with the same name exists. Logic has been applied in

order to select an appropriate UIElement type, for instance if an attribute with the name “name” of the type String

exists in the navigation model, a UIElement will be created called “Name” and marked with the stereotype <<Text>>.

A directed composite association will be used to connect the presentation class with the UIElement, and thereby

create a property of the UIElement on the presentation class.



35

As an attribute represented by an association are of the type of a class in the source model, it is necessary to check if

the corresponding class has already been created in the target model. Therefore the handling of associations is done

separately.

If both the classes connected by the association exist in the target model, then they are connected with a directed

composite association. Also here the handling of an association will be performed twice, as argued in section 6.5.

Thereby all attributes of a class in the source model will always be reflected in the target model.

This implementation satisfies the transformation rule specified in section 5.2.5.2 by:

Creating a presentation class in the presentation model, representing the navigation node in the

navigation model, with the same name as the navigation node.

Mapping each attribute in the navigation node, to UIElements in the presentation model, and

connecting them to the appropriate presentation class.

The association to the navigation node is not implemented as [5] was unavailable during the development process.

6.7 UWE_XML ECORE MODEL

Project name: uwe.xml



org.eclipse.emf.ecore;visibility:=reexport,

org.eclipse.emf.ecore.xmi;visibility:=reexport,

org.eclipse.uml2.uml;visibility:=reexport,

uwe.profile.tooling

Description:

The uwe_xml.ecore in this project is the Ecore model that defines the “big picture” model that has references to the

content model, the navigation model and the presentation mode. Also an attribute defining the name of the site is

created. See Figure 17.

The file uwe_xml.genmodel is an EMF model reflecting the uwe.xml.ecore model. The uwe_xml.genmodel is used to

create model code that enables the use of the model. It is also used to generate an editor that is used in the run-time

workbench.



36

Figure 17 - UWE_XML Ecore Model

Project name: uwe.xml.editor



org.eclipse.core.resources;visibility:=reexport,

uwe.xml.edit;visibility:=reexport,

org.eclipse.emf.ecore.xmi;visibility:=reexport,

org.eclipse.emf.edit.ui;visibility:=reexport,

org.eclipse.ui.ide;visibility:=reexport,

org.eclipse.emf.ecore.edit;visibility:=reexport,

org.eclipse.uml2.uml.edit;visibility:=reexport

Description:

This plug-in is a domain specific editor for the uwe_xml.ecore model.



37

The generated editor reports an error when references are made to UML models in the run-time workbench. It seems

to be only a cosmetic error in the UI of the editor, since the references can be made and the transformations are

working even when this error occurs. It seems that the error is coursed by the editor being unable to locate UML

related recourses in other plug-ins, but this has not been confirmed.

6.8 UWE MODELS TO PHP CODE TRANSFORMATION

This transformation consists of two transformations, where the first transformation triggers the second

transformation.

The first transformation is a M2M transformation that takes the UWE_XML PIM model as input and produces a PSM

model which is directly used as input to the second transformation. The second transformation is a JET transformation

that produces PHP code based on this PSM model.

The PSM model is defined by the M2T transformation, and an EMF model is created in a separate plug-in project in

order to produce the necessary model code, and an editor allowing the user to track the intermediate result.

First the M2T transformation will be described, then the PSM model and finally the M2M transformation.

Project name: uwe.php.transform


org.eclipse.jet

Description:

This is the M2T transformation that produces the PHP code. It is implemented as a JET transformation.

The JET transformation uses an exemplar in order to specify which template to generate.

The task of developing a JET transformation is done using a graphical editor, on the left side is the exemplar and on

the right is a representation of an Ecore model, see Figure 18 . The Ecore model represented is the one used as the

PSM.

First a new entity is created in the Ecore, called webSite and an attribute called name is added to it.



38

Figure 18 - JET Graphical Editor

Now the project of the exemplar is dragged to the webSite entity. This allows the JET transformation to create a new

project to hold the Web application.

All the files that are created once are now dragged from the exemplar to the webSite entity.

It is now time to apply all the files that should be created more than once. In order to do so, first new entities are

created along with proper attributes. Now files from the exemplar can be dragged onto these entities.



39

When all the files are set to be created, templates are generated. Initially the generated templates are exact copies of

those files provided by the exemplar.

Especially the templates of the files created many times have to be edited, but also many of the other files have to be

edited.

As described in section 6.9, the exemplar is designed inspired by the Model-View-Control (MVC) pattern. All the model

classes therefore have to be created from the same template, likewise with Data Access Objects (DAO) and others.

Editing the templates is done using XPath [11].

Figure 19 illustrates the process of creating JET transformations.

Figure 19 - The process of creating Jet Transformation [11]

The article “Create powerful custom tools quickly with Rational Software Architect Version 7.0” [11] provides a

detailed description on how to create JET transformations.

The approach by creating an entire Web application in one JET transformation has a related issue. The size and

complexity of the Web application used as exemplar, results in a JET transformation that handles far too many files

making it wary hard to maintain an overview of the templates.

One solution to this issue could be to use a simpler architecture in the exemplar Web application, or another solution

could be to split the exemplar into smaller modules, this way a dedicated JET transformation could handle each

module. The later solution to the issue will probably also help addressing the architectural decisions at a higher level

of abstraction.

The consequence of the described issue is that the Web application being generated does not run. It seems that the

different parts of the generated web application are working independently of each other, but that the connection

between them is not generated correctly.



40

Project name: uwe.php.transform.model



org.eclipse.emf.ecore;visibility:=reexport

Description:

This is the web application specific EMF model that is used as PSM. The name of the Ecore model is input.ecore. The

name is defined by the JET transformation where it was created. The structure of the Ecore model is depicted in Figure

20.



41

Figure 20 - Structure of the input.ecore model

Also an EMF model exists in the project which has been used to generate model code and an editor. The editor will

not be described further, as it is analogue to the uwe.xml.editor described in section 6.7, except that it does not

produce any error messages.

Project name: uwe.php.transform.frontend


org.eclipse.ui,




42




uwe.xml,

uwe.php.transform.model,

com.ibm.xtools.transform.authoring.uml2

Description:

This is the M2M transformation that transforms the uwe_xml.ecore model to the input.ecore model.

It maps each class in the UWE content model referenced in the uwe_xml.ecore to a corresponding content entity in

the input.ecore by moving the name of the content class. Also the attributes of the content class is mapped to

properties in the content entity in the input.ecore.

Mapping of the UWE navigation model and the UWE presentation model from the uwe_xml.ecore is analogue to the

mapping of the content class. The mapping of UIElements in the UWE presentation model to a corresponding

UIElement entity is done by mapping the name of the stereotype of the UIElement in the UWE presentation class, to

the type of the UIElement in the input.ecore model.

6.9 EXEMPLAR

The Web application used as exemplar in the JET transformation is primarily inspired by 2 patterns. The Model-View-

Control (MVC) to manage the presentation tier of the web application, and the Data Access Object (DAO) pattern to

wrap the connection to the database in the integration tier. As the use case does not imply any business logic, the

business tier has been omitted. See Figure 21. In the diagram packages is used to illustrate different parts of the

system. The packages represent folders on the file system containing the related PHP files. They are not to be

mistaken with packages in the Java programming language, as PHP does not handles namespaces the same way as

Java.



43

Figure 21 - Architecture of the Exemplar Web Application

6.9.1 MODEL

The model package contains a PHP class for each content class in the UWE content model. The PHP class contains only

attributes, and getters and setters for those attributes.

6.9.2 VIEW

The view package is divided into two parts, one part dealing with the structure of a view called presentation model,

and one dealing with the presentation of a view called HTMLGenerator.

6.9.2.1 PRESENTATION MODEL

The presentation model representing the structure of a view, and is designed based on the Composite pattern (GoF)

[7]. This composite structure is highly inspired by the UWE Presentation metamodel.

Presentation Tier

Business Tier

Integration Tier



44

Figure 22 - Presentation Model

6.9.2.2 HTML GENERATOR

This is an implementation of the Visitor pattern that is easy to apply to a composite pattern.

It is implemented based on an abstract class called ViewVisitor, see Figure 23, where the implementation of the visitor

is done by different html visitors that inherits from the ViewVisitor class.

Figure 23 - The ViewVisitor Class

6.9.3 CONTROL



45

The control package contains an abstract class called control. This class is used from the index.php file that is the only

access point of the web application.

A helper class called controlHelper assists in performing various control related tasks.

The controller generates the structure of the view using another helper class called presentationModelHelper.

Figure 24 show an example of a controller.

Figure 24 - Controller

6.9.4 DAO

For each model classes in the model, a corresponding DAO class exists. An example of a DAO class is shown in Figure

25.

Figure 25 - Example of a DAO

6.9.5 DATABASE



46

The database package consists of 2 classes, one called Database handling the SQL statements, and one called

DBConnect handling the connection to the actual database.

The package is illustrated in Figure 26. For simplicity the Database class is only shown with the core operations, but it

contains many functions and static tokens used to generate the SQL statements at runtime.

Figure 26 - Database package

6.10 KNOWN ISSUES AND BUGS

All known bugs and issues are listed in Table 2.

Project Description

uwe.transform.navigation2presentation Some UML related methods is not moved to the uwe.shared

project.

uwe.xml.editor An error message is displayed when editing the model. It seems

to be a UI related issue possibly related to dependencies not

specified or unavailable for the plug-in at runtime.

uwe.php.transform The JET transformation is too big and complex. Resulting in, that

the generated Web application contains error.

uwe.profile.tooling The palette to create UWE elements is not shown at runtime.

Table 2 - Known issues and bugs


Thesis - Future Work - Jakob Frydensberg

47

7 FUTURE WORK

In order to provide validation of the UML models in accordance with the UWE metamodel, all the constraints specified

by the UWE metamodel should be implemented in the UWE profile.

In the transformation from the content model to the navigation model, handling of alternative navigation routes

should be implemented using menus.

In the transformation from the navigation model to the presentation model, each navigation node should be handled

in a separate submap.

The traceability between the models in the transformation from the content model to the navigation model, and the

transformation from the navigation model to the presentation model, should be implemented by creating an attribute

of the source element in the target element.

The exemplar project should be simplified by breaking it up into smaller pieces in order to provide for many, but

simpler JET transformations.

Just like the metamodel has a formal description provided by the UWE group, a formal description on the

transformations would be appreciated.


Thesis - Conclusion - Jakob Frydensberg

48

8 CONCLUSION

The UWE profile is implemented based on the UWE metamodel in order to provide for marking of the UML elements

that is to be transformed.

The transformations from the content model to the navigation model, and from the navigation model to the

presentation model, are implemented and are running as expected.

The transformation from the navigation model to the presentation model has been simplified by transforming all

classes from the navigation model instead of the navigation node. This is done based on the assumption that the

navigation model only contains classes that are navigation nodes.

In order to transform from the UWE models to PHP code, an ecore model is created to collect the UWE models into

one model. This model is then transformed into a Web application specific ecore model by a M2M transformation. A

M2T transformation is created to transform the Web application specific ecore model to a Web application written in

PHP and connected to a MySQL database.

The M2T transformation from the UWE models to a Web application is implemented but contains errors. The different

parts of the Web application, seems to be working independently, but they are not connected properly; resulting in an

application that does not run.

The overall picture is that all the transformations have been implemented and is producing proper output.

It is demonstrated that executable code is generated based on UWE models.


Thesis - Abbreviations - Jakob Frydensberg

49

9 ABBREVIATIONS

Abbreviations: Meaning:

DAO Data Access Object

DLS Domain Specific Language

EMF Eclipse Modeling Framework

EMFT Eclipse Modeling Framework Technology

M2M Model to Model Transformation

M2T Model to Text Transformation

MDA Model Driven Architecture

MDD Model Driven Development

MOF Meta Object Facility

MVC Model-View-Control

OMG Object Management Group

PIM Platform Independent Model

PSM Platform Specific Model

RSA Rational Software Architect


Thesis - Abbreviations - Jakob Frydensberg

50

RSM Rational Software Modeler

UML Unified Modeling Language

UP Unified Process

UWE UML based Web Engineering


Thesis - References - Jakob Frydensberg

51

10 REFERENCES

[1] An introduction to Model Driven Architecture, Part1: MDA in today’s systems, 2004,

Alan Brown

http://www.ibm.com/developerworks/rational/library/3100.html

[2] Web Engineering – Modelling and Implementing Web Applications, 2008,

Chapter 12, AN OVERVIEW OF MODEL-DRIVEN WEB ENGINERRING AND THE MDA,

Nathalie Moreno, José Raúl Romero, Antonio Vallecillo

[3] MDA Guide Version 1.0.1, 2003, OMG

[4] Web Engineering – Modelling and Implementing Web Applications, 2008,

Chapter 7, UML-BASED WEB ENGINEERING,

Nora Koch, Alexander Knapp, Gefei Zhang, Hubert Baumeister

[5] UWE Metamodel and Profile – User Guide and Reference, 2008

Christian Kroiß, Nora Koch

[6] Meetings with supervisor, Hubert Baumeister.

[7] Design Patterns – Elements of Reusable Object-Oriented Software, 1995

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

[8] Core J2EE Patterns – Best Practise and Design Strategies, 2nd

edition

Deepak Alur, John Crupi, Dan Malks

http://www.ibm.com/developerworks/rational/library/3100.html


Thesis - References - Jakob Frydensberg

52

[9] developerWorks – Developing Eclipse Plug-ins

http://www.ibm.com/developerworks/opensource/library/os-ecplug/?Open&ca=daw-ec-dr

[10] developerWorks - Authoring UML Profiles: Part 2. Using Rational Software Architect, Rational Systems

Developer, and Rational Software Modeler to manage change in UML Profiles

http://www.ibm.com/developerworks/rational/library/08/0429_misic2/index.html?S_TACT=105AGX15&S_CM

P=LP

[11] developerWorks - Create powerful custom tools quickly with Rational Software Architect Version 7.0

http://www.ibm.com/developerworks/rational/library/07/0109_peterson/

http://www.ibm.com/developerworks/opensource/library/os-ecplug/?Open&ca=daw-ec-dr

http://www.ibm.com/developerworks/rational/library/08/0429_misic2/index.html?S_TACT=105AGX15&S_CMP=LP

http://www.ibm.com/developerworks/rational/library/08/0429_misic2/index.html?S_TACT=105AGX15&S_CMP=LP

http://www.ibm.com/developerworks/rational/library/07/0109_peterson/


Thesis - Appendix: UWE Metamodel - Jakob Frydensberg

53

11 A: UWE METAMODEL

11.1 NAVIGATION PACKAGE

The navigation package is shown in 2 diagrams, one depicting the structure of the package and one depicting the

relationship to the UML metamodel. The diagrams are shown in Figure 27 and Figure 28.

Figure 27 - The navigation package, [5]



54

Figure 28 - Relationship between the navigation package and the UML metamodel, [5]

11.2 PRESENTATION METAMODEL

To avoid cognitive overload, the presentation metamodel is also shown in 2 diagrams, one depicting the backbone of

the presentation package, Figure 29, and one depicting the Presentation Elements, Figure 30.



55

Figure 29 - The backbone of the presentation package, [5]

Figure 30 - Presentation Elements, [5]


Thesis - Appendix: CD Contents - Jakob Frydensberg

56

12 A: CD

The CD contains:

The report as a pdf file.

The workbench

A feature making it easy to install the UWE implementation in RSM.

A guide describing how to install the feature.

Bachelor of Engineering, IT Thesisetd.dtu.dk/thesis/220257/dip08_05.pdf · Bachelor of Engineering,...

Documents

Transcript of Bachelor of Engineering, IT Thesisetd.dtu.dk/thesis/220257/dip08_05.pdf · Bachelor of Engineering,...