Bachelor of Engineering, IT Thesis

Technical University of Denmark Bachelor of Engineering, IT Thesis 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 reception@imm.dtu.dk 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

Thesis Jakob Frydensberg 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. 1

Thesis Jakob Frydensberg 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.2.5 Transformations... 16 5.3 UWE and MDA... 20 6 Solution... 22 6.1 RSM plug-ins... 22 6.1.1 Domain Specific Languages... 22 2

Thesis Jakob Frydensberg 6.1.2 Transformations... 22 6.2 Architecture... 23 6.2.1 Transformations... 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 3

Thesis Jakob Frydensberg 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. 4

Thesis - Problem - Jakob Frydensberg 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: 5

Thesis - Problem - Jakob Frydensberg 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. 6

Thesis - Problem - Jakob Frydensberg 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: 7

Thesis - Problem - Jakob Frydensberg 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. 8

Thesis - Methodologies - Jakob Frydensberg 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 enterprisescale 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 foundation of the building simply appear. Not likely outside the Jetsons world, but an everyday occurrence in the software world. [3]. 9

Thesis - Methodologies - Jakob Frydensberg 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. 10

Thesis - Methodologies - Jakob Frydensberg 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. PIM PIM 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. PIM PSM 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. 11

Thesis - Methodologies - Jakob Frydensberg PIM PSM 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 metametamodel 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. 12

Thesis - Methodologies - Jakob Frydensberg 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 13

Thesis - Methodologies - Jakob Frydensberg 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 14

Thesis - Methodologies - Jakob Frydensberg «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 15

Thesis - Methodologies - Jakob Frydensberg «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 5.2.5 TRANSFORMATIONS 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. 16

Thesis - Methodologies - Jakob Frydensberg 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 17

Thesis - Methodologies - Jakob Frydensberg Transformation Rule 2. 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. 18

Thesis - Methodologies - Jakob Frydensberg a) b) Transformation Rule 3. Figure 8 - Content to Navigation rule 2 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. 19

Thesis - Methodologies - Jakob Frydensberg Figure 9 - Content to Navigation rule 3 5.2.5.2 NAVIGATION TO PRESENTATION TRANSFORMATION Transformation Rule 4. 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. 20

Thesis - Methodologies - Jakob Frydensberg 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]. 21

Thesis - Solution - Jakob Frydensberg 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. 6.1.2 TRANSFORMATIONS There are 2 types of transformations, Model to Text (M2T) transformations and Model to Model (M2M) transformations. 22

Thesis - Solution - Jakob Frydensberg 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. 6.2.1 TRANSFORMATIONS 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 23

Thesis - Solution - Jakob Frydensberg 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. PIM PSM Platform 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 plugins. 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. 24

Thesis - Solution - Jakob Frydensberg Figure 11 - Plug-in dependencies 6.2.2.1 MANAGING PLUG-IN DEPENDENCIES 25

Thesis - Solution - Jakob Frydensberg 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. 26

Thesis - Solution - Jakob Frydensberg 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 27

Thesis - Solution - Jakob Frydensberg 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 Plug-in Dependencies: Description: 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)" 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 28

Thesis - Solution - Jakob Frydensberg Plug-in Dependencies: Description: org.eclipse.ui, org.eclipse.core.runtime, org.eclipse.uml2.uml, uwe.profile.tooling 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 Plug-in Dependencies: Description: org.eclipse.ui, org.eclipse.core.runtime, org.eclipse.emf.ecore, org.eclipse.gmf.runtime.common.core, org.eclipse.uml2.uml, com.ibm.xtools.transform.authoring.uml2, com.ibm.xtools.modeler.ui, org.eclipse.uml2.uml.resources, uwe.shared, uwe.profile.tooling 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 29

Thesis - Solution - Jakob Frydensberg 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. 30

Thesis - Solution - Jakob Frydensberg Handles associations Handles associations Handles attributes Handles ownedattribues 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. 31

Thesis - Solution - Jakob Frydensberg 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 oneto-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 Plug-in Dependencies: org.eclipse.ui, org.eclipse.core.runtime, org.eclipse.emf.ecore, org.eclipse.gmf.runtime.common.core, org.eclipse.uml2.uml, com.ibm.xtools.transform.authoring.uml2, com.ibm.xtools.modeler, uwe.shared, uwe.profile.tooling 32

Thesis - Solution - Jakob Frydensberg 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. 33

Thesis - Solution - Jakob Frydensberg 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. 34

Thesis - Solution - Jakob Frydensberg 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 Plug-in Dependencies: Description: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport, org.eclipse.emf.ecore.xmi;visibility:=reexport, org.eclipse.uml2.uml;visibility:=reexport, uwe.profile.tooling 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. 35

Thesis - Solution - Jakob Frydensberg Figure 17 - UWE_XML Ecore Model Project name: uwe.xml.editor Plug-in Dependencies: org.eclipse.core.runtime, 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. 36

Thesis - Solution - Jakob Frydensberg 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 Plug-in Dependencies: Description: org.eclipse.jet 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. 37

Thesis - Solution - Jakob Frydensberg 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. 38

Thesis - Solution - Jakob Frydensberg 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. 39

Thesis - Solution - Jakob Frydensberg Project name: uwe.php.transform.model Plug-in Dependencies: Description: org.eclipse.core.runtime, org.eclipse.emf.ecore;visibility:=reexport 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. 40

Thesis - Solution - Jakob Frydensberg 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 Plug-in Dependencies: org.eclipse.ui, org.eclipse.core.runtime, 41

Thesis - Solution - Jakob Frydensberg Description: org.eclipse.emf.ecore, org.eclipse.gmf.runtime.common.core, org.eclipse.uml2.uml, uwe.xml, uwe.php.transform.model, com.ibm.xtools.transform.authoring.uml2 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. 42

Thesis - Solution - Jakob Frydensberg Presentation Tier Business Tier Integration Tier 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. 43

Thesis - Solution - Jakob Frydensberg 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 44

Thesis - Solution - Jakob Frydensberg 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 45

Thesis - Solution - Jakob Frydensberg 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 46