Applying Transformations to Model Driven Development of Web ...

Applying Transformations to Model Driven Development of Web applications* Santiago Meliá and Jaime Gómez Universidad de Alicante, Spain {santi, jgomez}@dlsi.ua.es

Abstract. Nowadays, the maturity reached by the Web engineering research community can be assessed by the myriad of web design methods that have proven successful for the specification of the functional and navigational requirements posed by Web information systems. However, these proposals often fail to address architectural features, which results in Web specifications with rigid architectures, with no regard for their actual circumstances of use. To overcome this limitation, we propose a generic approach called WebSA. WebSA is based on the MDA (Model-driven Architecture) paradigm. It proposes a Model Driven Development made up of a set of UML architectural models and QVT transformations as mechanisms to integrate the functional aspects of the current methodologies with the architectural aspects. In order to illustrate our approach, in this paper we combine WebSA with the OO-H method to tackle the design of the well known J2EE Petstore specification.

1 Introduction The rapid evolution of Internet has promoted in recent years intensive research in the field of functional modeling of Web applications. This fact has induced a new research trend within Software Engineering known as Web Engineering. In this context, different methods, languages, tools and design patterns for Web modeling have been proposed. These methods are centered mainly in the definition of functional aspects relative to the semantic of models to capture relevant properties of Web applications. However, few are the proposals that have tried to integrate in their methods the explicit consideration of architectural modeling features. Some authors have proposed the use of well known techniques in the Software Architecture discipline [1] in order to identify and formalize which subsystems, components and connectors (software or hardware) should make up the Web application. These architectural features are especially important in methodologies that provide a code generation environment, such as WebML [5], OO-H [9], UWE [12], etc. The addition of an architectural view would cover the gap that nowadays exists between the Web design models and the code architecture. For this purpose, we propose the WebSA (Web Software Architecture) approach [13, 14], based on the standard MDA (Model Driven Architecture) [15]. Basically, WebSA provides the designer with a set of architectural models and transformation models to specify a Web application. *

This research has been partially sponsored by t the Spanish METASIGN (TIN2004-00779).

J. Akoka et al. (Eds.): ER Workshops 2005, LNCS 3770, pp. 63 – 73, 2005. © Springer-Verlag Berlin Heidelberg 2005

64

S. Meliá and J. Gómez

Starting from these models the designer can integrate the Web functional models (domain, navigation and presentation) applying a set of model transformations following the Request for Proposals Query/View/Transformations (QVT) [16]. The result is an Integration model that captures the functional and architectural aspects of a Web application. Applying successive QVT transformations over the Integration model the Web specification can be converted to different implementation environments like J2EE or .NET. This paper describes the first step, that is, how to achieve to the Integration model. We introduce the relevant concepts that are needed to understand our approach using the well-known Petstore running example [18]. The paper is organized as follows: Sect. 2 gives an overview of the WebSA development process and the modeling notation. Sect. 3 describes the functional viewpoint of by means of the Domain model of the Petstore blueprint. Next, the architecture of Petstore is specified by means of the WebSA Configuration model in sect. 4. Sect. 5 explains the QVT transformations showing how traditional Web functional models and the Configuration model can be merged into an Integration model. Sect. 6 gives an overview of the Integration model. Finally, sect. 7 and 8 outline the related work, conclusions and further lines of research.

2 The WebSA Approach: An Overview WebSA is a proposal whose main objective is to cover all phases of Web application development focusing on software architecture. It contributes to fill the gap currently existing between traditional Web design models and the final implementation. In order to achieve this, WebSA defines a set of architectural models to specify the architectural viewpoint which complements current Web engineering methodologies [9, 12]. Furthermore, WebSA also establishes an instance of the MDA development process [11], which allows for the integration of the different viewpoints of a Web application by means of transformations between models. The WebSA development process is based on the MDA development process in which the output artefacts of each phase must be models, which represent the different abstraction levels in the system specification. In the analysis phase the Web application specification is vertically divided into two viewpoints, as shown in the diagram flow of Fig. 1. On the one side, the functional-perspective is given by the Web functional models provided by Web methods like OO-H [9], UWE [12], etc. On the other side, the Subsystem Model (SM) and the Configuration Model (CM) define the software architecture of the Web Application. The SM and CM architectural models, defined by WebSA, use two different architectural styles to specify a Web application, namely, a subsystem (or layer style) and a component style respectively. The first PIM-to-PIM transformation (from now on T1, see Fig. 1) turns the analysis models into platform independent design models. It integrates the information about functionality and architecture (see sect. 4) in a single Integration Model (IM). In the same way, the Integration Model, is the basis on which several PIM-to-PSM transformations, one for each target platform (from now on T2, see e.g. T2, T2’ and T2’’ in Fig. 1), can be defined. The output of these transformations is the specification of the Web application for a given platform (e.g. J2EE, .NET, etc).

Applying Transformations to Model Driven Development of Web Applications

65

In order to show the usefulness of the WebSA approach, we have chosen the J2EE Petstore example. This application constitutes a blueprint that uses best practices and design guidelines for a distributed component e-commerce Web application. Next section illustrates the design the Web Functional Viewpoint in the WebSA approach by means of the Domain model. The definition of this viewpoint with other notations would also be possible. Web Functional Viewpoint

Web Architectural Viewpoint

Functional Models (OO-H,UWE)

Subsystem Model

Analysis Merge

Platform Independent Design

T1

Configuration Model

Models to Model Transformation

Integration Model

T2

T2'

T2'’

Implementation

J2EE models

.NET models

Other models

Fig. 1. WebSA Development Process

3 The Web Functional Viewpoint: Domain Model The Web functional viewpoint of WebSA is made up by the Domain, Navigational and Process models defined by the traditional Web methodologies. However, for lack of space, in this paper we only focus on the Domain model in order to show how its information is merged with the architectural models. The Domain model represents the domain entities of the Web application and it is free from any technical or implementation details and represents an ideal class model. Like a typical e-commerce site, the Petstore presents the customer with a catalog of products. The customer selects products of interest and places them in a shopping cart. Fig. 2 depicts a class diagram which contains the most important domain entities of the Petstore. The customer class contains a set of different attributes that represent the personal data (userid, email, name, address, phone, etc.). Also, the application contains the customer preferences in the Profile class like favorite category, language, etc. In order to ease the accessibility to the different products, each product is classified in a Category (p.e a parrot corresponds to the bird category). Thus, the customer selects a particular product in the category list. At this moment, the application displays detailed information about the selected product. The product

66

S. Meliá and J. Gómez

class contains the description and image. When there are several variants of the same product, each variant is shown as a separate item. For example, when showing details about an African parakeet, the items could be large male African parakeet or a small female African parakeet which has a different unit cost, supplier, stock, etc. When the customer decides to purchase a particular item and clicks a button to addToCart the item to the shopping cart. The customer may continue shopping, adding more items to the cart while there are items in stock. Finally, the customer can choose to order the items in the shopping cart at any time. The operation checkout from the Cart class is invoked.

1..1 Cart ID total

Customer userid email firstname lastname status addr city state zip country phone

1..1

1..1

Profile userid langpref favcategory mylistopt banneropt *

*

addItem 1..1 updateToCart checkout

1..*

CartItem quantity *

Category catid name descn

0..1

1..1 1..1 Item itemid listprice unitcost supplier attr1 attr2 status instock

* Product productid name descn *

1..1

search

addToCart

Fig. 2. Domain Model of Petstore

The next step in the WebSA analysis phase is to specify the Web architectural viewpoint. For the purposes of this paper, only the configuration model needs to be specified.

4 The Web Architectural Viewpoint: Configuration Model The CM defines a component architectural style based on the structural view of the Web application. It defines a set of Web components and their connectors, where each component represents the role or the task performed by one or more common components identified in the family of Web applications. In this way, CM uses a topology of components defined in the Web application domain, and this allows us to specify the architectural configuration without knowing anything about the problem domain. At this level, we can also define architectural patterns for the Web application as a reuse mechanism. A Configuration model is built by means of a UML 2.0 Profile of the new composite structure model, which is well-suited to specify the

Applying Transformations to Model Driven Development of Web Applications

67

software architecture of applications. The main modeling elements of the CM are WebComponent, WebConnector, WebPart and WebPattern. A description of their notation and semantics can be found in [14]. «ClientPage» Client Page1

«UserAgent» UA1

«ServerPage» TemplatePage

builds

1..*

1..*

ClientRequest

1..*

«ServerPage»

«ServerPage»

:TopIndex [1]

:Banner [1]

«ServerPage»

«ServerPage»

1

:Body [1..*] ExtServicesSupplied

:Foot [1]

1..* 1 ScreenData 1

«LegacyView» LW1 -

ClientHandler

«WebComponent» MVC2

ViewData

isSynchronous = false

LegacyServicesRequired

«WebPattern» :Model View Controller 2

«represents» 1

Model

1..*

Process Component

1

1..* EntityExtAccess

«WebComponent» Facade

«WebPattern» :Facade

«represents»

1 NonTransQueries 1 TransQueries

1..* 1 «DAC» DAC1

«Store» DB

«DataSource» DS1 1..*

1..*

-

isRemote = true isTransactional = true

1..*

1

-

access = R/W data = Conceptual Organization = Relational

Fig. 3. Configuration Model of the Petstore

In order to represent its architectural style, the CM has been defined as an extension of the UML Composite Structure model, and includes Web components and properties of the Web application domain. The CM model also provides the necessary information for the T1 transformation defined in the WebSA development process (see Fig. 1) for integrating the functionality with the architecture in the IM model. Fig. 3 shows a general view of the CM representing the Petstore architecture. In the front-end part of the model we find the component UserAgent (e.g. a browser) which receives the user’s requests and renders the ClientPage set. Each ClientPage component contains the interface and functionality information and is responsible for sending messages to the MVC2 WebPattern component (MVC2 is detailed in [14]). The MVC2 Webpattern receives the requests through the WebPort ClientHandler and establishes the interface reaction through the WebPort ScreenData, which defines the ServerPage components. In Petstore the ServerPages are specified following the pattern Master Template defined by Conallen [6]. Following this pattern, in Fig. 3 we have defined a TemplatePage that builds the client pages by instantiation of the WebParts TopIndex, Banner, Foot and Body.

68

S. Meliá and J. Gómez

Each instance of a Body ServerPage needs an interface to access the required data objects. Such interface is provided by the WebPort ViewData of the MVC2 Web Pattern. Looking at the MVC2, we can observe that this component needs information from the components that implement the business logic, which is obtained through the BLogic interface offered by the Façade WebPattern defined by [8]. This Façade component invokes the DAC component (Data Access Component), which contains the data access methods and decouples the business logic from the data. In our example DAC offers two interfaces, one for the non transactional queries, i.e. the data retrieval queries which can be accessed through the WebPort process component of Façade, and one for the transactional queries (insert, update and delete) which can be accessed through the Entity port of Façade. The WebComponent Façade is in turn related to the component LegacyView, which offers a series of services coming from the EntityExtAccess port to other applications and converts the received asynchronous calls into requests to the business logic. Finally, the specified remote and transactional data sources allow for the connection to a Store component that contains the information modelled in the domain model of the functional view of the Web application Petstore, and specifies a read/write access, as well as a relational organization. Fig. 4 depicts the components of the Façade WebPattern which includes a set of stateless ProcessComponents (e.g., a Session Stateless EJB), which receives the requests through the BLogic WebInterface from the MVC2, and resends them to the Entity through the interfaces createEntity and invokeServices. This pattern requires an interface to DAC through the nonTransactionalQueries interface. Also, it has a set of EntityWeb components that represent the elements of the domain in the business logic. These have the tagged value isShare=true indicating that they can be shared by multiple transactions and users (e.g., it could be implemented by an EJB Entity). Note how this entity provides the ExtEntityServices interface for the View Legacy and sends the requests to the data layer through the TransactionalQueries WebInterface. Once the WebSA analysis has been completely specified, the next step is to describe the transformation process to obtain the integration model.

«WebPattern» Facade

EA 4.10 Unregistered TransactionalQueries Trial Version LogicServices invokeServices remoteInterface EA 4.10 Unregistered Trial Version «ProcessComponent» FacadeComponent: - hasState: = false

«EntityWeb» EntityComp:

EA 4.10 Unregistered Trial Version - isShared: = true createEntity homeInterface EA 4.10 Unregistered Trial Version

nonTransQueries

EntityExtAccess

Fig. 4. Façade WebPattern

Applying Transformations to Model Driven Development of Web Applications

69

5 The WebSA Transformation Process The WebSA transformation policy is driven by the architectural viewpoint, i.e. it is defined by a set of transformations in which first class citizens are the classes of the architectural view. The WebSA development process consists of two types of transformations: T1 and T2. T1 merges the elements of the architectural models of WebSA with those of the functional models, and translates them into a platform independent design model called Integration Model. T2 turns the Integration Model into a platform specific implementation model (e.g. J2EE or .NET). Both transformations are complex, i.e. they are made up of a set of smaller transformations, which are executed in a deterministic way in order to complete the transformation. In MDA there are different alternatives for getting the information necessary for transforming one model into another (e.g. using a profile, using metamodels, patterns and markings, etc). WebSA has opted for a metamodel mapping approach to specify the transformations, because in this way it is possible to obtain the information of the different Web approaches just knowing their MOF metamodel. As an example, let’s take a closer look at the merging process of WebSA with the OO-H models (T1 in Fig. 1). In order to perform this merging, WebSA extends the MDA model transformation pattern of Bezivin [2]. In this pattern, MOF-based metamodels are the source of the transformation models that carry out the transformation to the target metamodel elements. The transformation models are defined in the QVT 2.0 language [16] which, as the reader might know, is an MDA standard also based on the MOF language. The QVT specification has a hybrid declarative/imperative nature. The declarative part is split into a user-friendly part based on transformations which comprises a rich graphical and textual notation, and a core part which provides a more verbose and formal definition of the transformations. The declarative notation is used to define the transformations that indicate the relationships between the source and target models, but without specifying how a transformation is actually executed. QVT also defines operational mappings that extend the metamodel of the declarative approach with additional concepts. This allows for a definition of transformations that use a complete imperative approach. Next, we present an example of a T1 transformation using the graphical notation of QVT. Fig. 5 uses the QVT graphical notation to define the FacadeDomain2Integration transformation. This transformation checks (‘c’ arrow) whether there is a class in the Domain model that contains a set of operations (see NOperation o1set in Fig. 5). Also, it checks in the Configuration model whether there is a WebPattern called Façade that contains both a ProcessComponent and an EntityWeb instances. If both patterns are found, the transformation enforces (‘e’ arrow) that both one stateless Process Component (that is, with its WebAttribute hasState=false) and an EntityWeb are created in the Integration model. In addition, the o1set from the class c1 is transformed into a set of WebServices associated to the Process component (s1set) and a set of WebServices associated to the EntityWeb component (s2set). Also, the NAttributes from the Domain model (a1set) are converted into a set of WebAttributes in the Integration model (a2set). The links among the n-ary elements (depicted by two superimposed rectangles) in the T1 transformation are defined in the Operations2WebServices and Attributes2WebAttributes subtransformations included

70

S. Meliá and J. Gómez

in its Where clause. On one hand, Operations2WebServices generates for all NOperations of each Class element a WebService in a Component. On the other hand, Attributes2WebAttributes generates for all NAttributes of each Class element a WebAttribute in an EntityWeb.

Fig. 5. Example of T1: FacadeDomain2ToIntegration

6 The Integration Model IM defines a complete structural design of our application in a platform independent way. It integrates the SM and the CM with the functional viewpoint models. This model plays and outstanding role in WebSA, due to the fact that certain application characteristics are only identifiable when we consider together functional and architectural aspects. For instance, in order to determine the granularity of the business logic components, it is necessary to know both the architectural structure (e.g. whether this logic is likely to be distributed) and the business logic functionality itself (the tasks to be performed). As previously stated (see fig. 1), the IM can be obtained by means of a PIM-toPIM transformation applied on the SM and the CM together with the functional view, and reduces the modeling effort. Also, this automated mapping causes the IM to inherit the architecture patterns defined in the CM, which will be now reflected in the concrete application. The resulting model is the basis on which the designer may perform further refinements in order to fine-tune the architecture to the system needs. Fig. 6 shows a portion of the Petstore IM that represents a simplified WebModule BusinessLogic. This module contains a set of WebComponents and their relationships obtained by the T1 transformation. On the left, the module has the IBLogic interface

Applying Transformations to Model Driven Development of Web Applications

71

that gathers the requests from the client components. This interface grants access to the different ProcessComponents in charge of obtaining all the requests from the client and launching the transactions in the business logic. As stated in the T1 transformation, each ProcessComponent is obtained from one or more domain classes (Customer, Profile, Product, etc., see Fig. 2). When a ProcessComponent begins the transaction, it creates an EntityWeb by means of a Home Interface (e.g IHomeProduct), and subsequently invokes such EntityWeb to access their WebServices through the Remote interface. In our example, the EntityWeb stores the state of the class instances of the Domain model by means of a DAC component (which must be also generated by T1 for each domain class). The DAC component provides a mapping between the Object data and the relational store. In Fig. 6 we can observe how in our architecture all of DAC components require the IdataInterface in order to store the data in the persistent layer. It is also important to stress that this model still centers on design aspects (WebComponents, their WebPorts and WebParts, WebInterfaces, WebModules and WebConnectors), and does not say anything about implementation. In this way, the model is still independent from the target platform. From this model, it is possible to define different T2 transformations (see Fig. 1) to specific platforms such as J2EE, .NET, PHP, etc. «WebModule» BusinessLogic IHomeCustomer «ProcessComponent» PCCustomer

«EntityWeb» EntCustomer

IRemoteCustomer -

- hasState:bool = false

IRemoteCustomer

«ProcessComponent» PCProfile

IBLogic

-

- hasState:bool = false IHomeProfile

«ProcessComponent» PCProduct -

IHomeProduct

«EntityWeb» EntProduct

IRemoteProduct

-

IDACProfile

«DAC» DACProfile

IDACProduct

«DAC» DACProduct

userid: int favcategory: string banneropt: string

hasState: bool = false

+ getCategories() : set + addItems() : set + searchProducts() : void

«DAC» DACCustomer

userid: int email: string firstname: string lastName: string status: string addr: string

«EntityWeb» EntProfile

IRemoteProfile

IDACCustomer

productId: int name: string descn: int

IDataInterface

+ getCategories() : set + addItems() : void + searchProducts() : void

Fig. 6. Simplified BusinessLogic WebModule of the Petstore Integration Model

7 Related Work This section compares our work with related research in the area of Web Engineering where MDA is applied to the development of Web applications.

72

S. Meliá and J. Gómez

In Tai et al [17] different kinds of artifacts are provided in a consistent and cohesive way by means of a metamodel. Our approach improves this idea with (1) the integration of proven successful models from the Web engineering field and (2) the formalization of the code generation phase by means of transformation rules. Another model-driven methodology for Web Information System development is MIDAS [4]. This methodology uses XML and object-relational technologies for the specification of the PSMs. Unlike the WebSA approach, it does not establish the transformation mapping following the standard QVT, and it does not provide any Web application architectural aspect. In contrast, architectural aspects are present in other Web engineering proposals. OOHDM-Java2 [10] proposes a product line architecture in J2EE for simplifying the systematic construction of different families of applications, only useful for J2EE platforms. Similarly, WebML [5] proposes a static architecture based on the J2EE struts framework. The rigidity of these approaches in terms of architecture is a drawback that has been overcome in the WebSA approach with the definition of a set of flexible architectural models.

8 Conclusions and Further Work WebSA is an approach that complements the currently existing methodologies for the design of Web applications with techniques for the development of Web architectures. WebSA comprises a set of UML architectural models and QVT transformations, a modeling language and a development process. The development process includes the description of the integration of these architectural models with the functional models of the different Web design approaches. In this paper we focus on the development process of WebSA and describe how models are integrated and generated based on model transformations. For the specification of the transformations we have chosen the promising QVT approach that allows for visual and textual description of the mapping rules. We are currently working on a tool to represent the set of QVT transformation models that support the WebSA refinement process. This work will allow to define the transformations while guaranteeing the traceability between those models and the final implementation.

References 1. L. Bass, M. Klein, F. Bachmann. Quality Attribute Design Primitives, CMU/SEI-2000TN-017, Carnegie Mellon, Pittsburgh, December 2000. 2. J. Bézivin. In Search of a Basic Principle for Model Driven Engineering, Novática nº1, June 2004, 21-24 3. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture – A System of Patterns, John Wiley & Sons Ltd. Chichester, England, 1996 4. P. Cáceres, E. Marcos, B. Vela. A MDA-Based Approach for Web Information System, Workshop in Software Model Engineering, WisME 2004. 5. S. Ceri, P. Fraternali, M. Matera. Conceptual Modeling of Data-Intensive Web Applications, IEEE Internet Computing 6, No. 4, 20–30, July/August 2002 6. J. Conallen. Building Web applications with UML Second Edition. Adisón Wesley

Applying Transformations to Model Driven Development of Web Applications

73

7. Longman. September 2002. 8. E. Gamma, R. Helm, R. Johnson & J. Vlissides. Design patterns: elements of reusable object-oriented software. Reading Mass: Addison-Wesley, 1995. 9. J. Gómez, C. Cachero, O. Pastor. Conceptual Modeling of Device-Independent Web Applications. IEEE Multimedia, 8(2), 26–39, 2001 10. M. D. Jacyntho, D. Schwabe, G. Rossi. A Software Architecture for Structuring Complex Web Applications. Journal of Web Engineering, 1(1): 37-60, 2002 11. A. Kleppe, J. Warmer, W. Bast. MDA Explained: The Model Driven Architecture, Practice and Promise, Addison-Wesley, 2003 12. N. Koch, A. Kraus. The Expressive Power of UML-based Web Engineering, In Proc. of the 2nd. Int. Workshop on Web-Oriented Software Technology, CYTED, Málaga, Spain, 105-119, June 2002 13. S. Meliá, C. Cachero. An MDA Approach for the Development of Web Applications, In Proc. of 4th International Conference on Web Engineering (ICWE’04), LNCS 3140, 300305, July 2004 14. S. Meliá, J. Gomez, N. Koch. Improving Web Design Methods with Architecture Modeling. 6th International Conference on Electronic Commerce and Web Technologies (EC-Web 2005), August 2005. 15. OMG. Model Driven Architecture, OMG doc. ormsc/2001-07-01 16. OMG. 2nd Revised submision: MOF 2.0 Query / Views /Transformations RFP, OMG doc. ad/05-03-02 17. H. Tai, K. Mitsui, T. Nerome, M. Abe, K. Ono. Model-Driven Development of Largescale Web Applications, IBM J. Res. & Dev. Vol. 48 No. 5/6, Sep/November 2004 18. TM J2EE Blueprint. Java Petstore 1.1.2, http://developer.java.sun.com/ developer/releases/ petstore/petstore1_1_2.html, November 2004