extending the oows method to support semantic rich...

Bert Weyne

Internet ApplicationsExtending the OOWS method to support semantic Rich

Academiejaar 2011-2012Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie

Master in de ingenieurswetenschappen: computerwetenschappen Masterproef ingediend tot het behalen van de academische graad van

Begeleiders: Bruno Volckaert, Sven CasteleynPromotoren: prof. dr. ir. Filip De Turck, Oscar Pastor

Faculty of Engineering and Architecture

Department of Information Technology

Director: Prof. Dr. Ir. D. De Zutter

Extending the OOWS method to support semantic

Rich Internet Applications

by

Bert Weyne

Promoters: Prof. Dr. Ir. O. Pastor Lopez, Prof. Dr. Ir. F. De Turck,

Dr. Ir. S. Casteleyn

Supervisors: Dr. Ir. F. Valverde Girome

Dissertation submitted to obtain the academic degree of

Civil Engineer in Computer Sciences:

Software Engineering

Academic year 2011–2012

Faculty of Computer Science

Department of Information System and Computation

Director: Prof. Dr. Ir. J. C. Casamayor Rodenas

Extending the OOWS method to support semantic

Rich Internet Applications

by

Bert Weyne

Promoters: Prof. Dr. Ir. O. Pastor Lopez, Prof. Dr. Ir. F. De Turck,

Dr. Ir. S. Casteleyn



Official Master’s Degree in Software Engineering, Formal Methods and

Information Systems, specialty: Information Systems


FOREWORD i

Foreword

After ten moths of hard work and devotion, I am glad to finally present my dissertation.

This dissertation elaborates a model driven software development method for the produc-

tion of semantic rich internet applications, which I hope you will enjoy reading during the

following chapters.

This work is not only the fruit of one person, but also of many other persons to whom I

would like to express my gratitude for the time and energy they devoted to me and this

work.

I would like to start mentioning Dr. Ir. Sven Casteleyn, he achieved in a few weeks to

make me proficient in the world of model driven development, rich internet applications

and semantic web, all fields I knew very little about when starting this thesis. He furter

guided me along this thesis providing me each week his valuable feedback and at occasions

when I got stuck excogitated viable alternative solutions.

Next are Prof. Dr. Ir. Oscar Pastor Lopez and Dr. Ir. Francisco. Valverde Girome who with

regular intervals helped me bring this work to a success by providing essential information

from their experience about some of the challenges of the work.

Further I want to express my appreciation towards my family, especially my girlfriend

Beatriz Sisternes Rojas for providing large amounts of mental support and to keep me

focused on this thesis instead of news articles, wikipedia, etc.

Thanks to the University of Ghent and the Polytechnic University of Valencia, especially

for Prof. Dr. Ir. Filip De Turck, Ann Vanoutryve and Francisco Javier Martınez Sanchez

who were the key persons providing me the Erasmus exchange opportunity to carry out

this academic year and this thesis in Valencia.

Also I would like to thank my UPV classmates and especially Pablo Viciano Negre whom

from the first day on helped me, integrated me and made me feel common in their group.

As ultimate, for all the other persons who I have not mentioned by name here, but that

in one or another way are involved with this dissertation and support me along the way,

Thank you.

Bert Weyne, June 2012

PERMISSION FOR USAGE iii

Permission for usage

“The author gives permission to make this master dissertation available for consultation

and to copy parts of this master dissertation for personal use.

In the case of any other use, the limitations of the copyright have to be respected, in

particular with regard to the obligation to state expressly the source when quoting results

from this master dissertation.”

Bert Weyne, June 2012

Extending the OOWS method

to support semantic Rich Internet

Applicationsby

Bert Weyne


Civil Engineer in Computer Sciences:

Software Engineering


Promoters: Prof. Dr. Ir. O. Pastor Lopez, Prof. Dr. Ir. F. De Turck, Dr. S. Casteleyn


Faculty of Engineering and Architecture

University of Ghent

Department of Information Technology

Director: Prof. Dr. Ir. D. De Zutter

SummaryThis dissertation is situated on the crossline of Web Engineering and the Semantic Web.It addresses the challenge of engineering modern Rich Internet Applications that explicitlyexpose their content semantics using semantic annotations.

The work is performed in the context of OOWS 2.0, [Girome, 2010] an existing model-driven web engineering method that focuses on the development of Web 2.0 and RichInternet Applications. It provides the basic models to deal with data, functionality, in-teraction and presentation concerns, and formalizes these using metamodels. Adobe Flexwas foreseen as an implementation platform, but actual code generation was without thescope of the existing work.

This dissertation took the existing OOWS 2.0 metamodels as a starting point, and re-fined and extended them in four fundamental ways: 1/ the existing models, in particularthe interaction model, were refined and extended to allow for more advanced RIA fea-tures (e.g., support for event-driven data communication and widget coordination), 2/the necessary metamodels were added to support HTML5 and jQuery as a target imple-mentation platform, 3/ new metamodels were added to support automatic generation ofsemantic annotations describing the content, 4/ a model compiler was implemented thatrealizes the model transformations to generate J2EE combined with HTML5 and jQueryout of OOWS 2.0 metamodel instances, including the newly added semantic annotationsin multiple formats (RDFa and microdata).

KeywordsModel Driven Development, Web 2.0, Web 3.0, Rich Internet Applications, Semantic Web

Extending the OOWS method

to support semantic Rich Internet

Applicationsby

Bert Weyne


Official Master’s Degree in Software Engineering, Formal Methods and

Information Systems, specialty: Information Systems


Promoters: Prof. Dr. Ir. O. Pastor Lopez, Prof. Dr. Ir. F. De Turck, Dr. Ir. S. Casteleyn


Faculty of Computer Science

Polytechnic University Valencia

Department of Information System and Computation

Director: Prof. Dr. Ir. J. C. Casamayor Rodenas

ResumenEsta tesis se situa en la lınea transversal de la Ingenierıa Web y la Web Semantica. La tesis tienecomo reto la ingenierıa de modernas Aplicaciones de Internet Ricas y dinamicas que de formaexplıcita expongan la semantica de sus contenidos utilizando anotaciones semanticas.

El trabajo se marca en el contexto de OOWS 2.0, [Girome, 2010] un metodo Web dirigido pormodelos que se centra en el desarrollo de la Web 2.0 y Aplicaciones de Internet Ricas. Proporcionamodelos basicos para hacer frente a los datos, la funcionalidad, la interaccion y la presentacion,y formaliza estos mediante metamodelos. Se habıa previsto Adobe Flex como una plataforma deimplementacion, pero la generacion de codigo real no fue objetivo del trabajo.

Esta tesis cogio los existentes metamodelos OOWS 2.0 como punto de partida, los cuales matizoy amplio en cuatro aspectos fundamentales: 1/ los modelos existentes, en particular el modelo deinteraccion, fueron perfeccionados y ampliados para permitir componentes RIA mas avanzados(por ejemplo, apoyo para la comunicacion de datos impulsado por eventos y la coordinacion dewidgets), 2/ se han anadido los metamodelos necesarios para proporcionar soporte a plataformasde implementacion como HTML5 y jQuery, 3/ se han anadido nuevas metamodelos para soportarla generacion automatica de anotaciones semanticas que describen contenido, 4/ se llevo a caboun compilador de modelos que permite transformaciones de modelos para generar J2EE junto conHTML5 y jQuery de las instancias del metamodelo 2.0 OOWS, incluyendo las nuevas agregadasanotaciones semanticas en multiples formatos (RDFa y microdatos).

Palabras claveDesarollo Dirigido por Modelos, Web 2.0, Web 3.0, RIA, Web semantica, Aplicaciones de Internet

Ricas

Extending the OOWS method to support semanticRich Internet Applications

Bert Weyne

Supervisor(s): Oscar Pastor Lopez, Filip De Turck, Sven Casteleyn, Francisco Valverde Girome

Abstract—This document gives an overview about how the model drivenweb development method OOWS 2.0 [1] was extended to provide presen-tation modeling support for HTML5 and JavaScript-jQuery technologies,how it was extended to support semantic web modeling, and how a proof ofconcept model to code transformation was defined allowing to obtain auto-matically generated code from the models.

Keywords—Model Driven Development, Web 2.0, Web 3.0, Rich InternetApplications, Semantic Web

I. INTRODUCTION

THIS work is situated on the crossline of Web Engineeringand the Semantic Web. Living todays difficult transition

from WEB 2.0 towards WEB 3.0, it aims to address the chal-lenge of engineering modern Rich Internet Applications that ex-plicitly expose their content semantics using semantic annota-tions. The goal is to come up with a Model Driven Architec-ture (MDA) web engineering method that provides autonomousmodeling and code generation support to develop SemanticallyAnnotated Rich Internet Applications. Hereby exploiting thefaster, cheaper software development and easiness to maintainadvantages MDA advantages.

The work starts from OOWS 2.0 [1], an existing model drivenweb engineering method that focuses on the development ofWeb 2.0 Rich Internet Applications. It provides the basic mod-els to deal with data, functionality, interaction and presentationconcerns of a WEB 2.0 application, and formalizes these usingmetamodels. Adobe Flex was foreseen as an implementationplatform, but actual code generation was without the scope ofthe existing work.

This work is going to refine and extend the modeling part ofthe existing OOWS 2.0 method to 1/ support presentation speci-fication for different implementation platforms, in particular thelatest currently actively used HTML5 with jQuery-JavaScriptWEB 2.0 implementation technologies, 2/ support the specifica-tion of different types of WEB 3.0 semantic annotations such asRDFa, Microdata and Microformats. Further is this work goingto provide the first proof of concept model to code transforma-tion for the models of the existing OOWS 2.0 method extendedwith the new modeling support mentioned earlier.

II. EXTENDING OOWS 2.0

This work is integrally based on the preceding OOWS 2.0method, and in fact mainly affects on top layer presentationand semantics issues in the original method. Fig. 1 shows anoverview of the extended OOWS 2.0 web development work-flow proposed in this work. The four different background col-ors in the figure identify the different modeling phases in themethod. Subsequently, each of them are discussed briefly andthe adjustments (if any) that were applied on them are clarified.

Fig. 1. Proposed extended OOWS 2.0 solution

A. Requirements modeling

Requirements modeling has been integrally adopted from theoriginal OOWS 2.0 method. It is an essential phase for everysoftware development project and thus also applies on OOWS.It typically offers a high level abstract view of the desired endproduct that basically allows developers to specify the differ-ent goals and objectives of the end product together with somerestrictions and specifications about how these goals and objec-tives should be reached.

B. Conceptual modeling

The Conceptual modeling phase allows to define the structureof the end application, it consists out of two independent mod-eling steps; Object modeling and Interaction modeling. Each ofthem have been integrally adopted from the original OOWS 2.0method and below are further discussed separately.

B.1 Object modeling

OOWS Object modeling is similar to UML class modeling,it defines entities, attributes, relationships and operations on theentities. It forms the data structure base for the end web appli-cation and for the rest of the following models of the method.

The extended OOWS 2.0 method integrally adopted the Ob-ject model and introduced some top layer non functionality af-fecting changes in order to allow weaving mechanisms towardsother models. This was achieved by making all metamodel ele-ments inherit a top parent class that incorporates this function-ality.

B.2 Interaction modeling

Supported by the Object model, the Interaction model de-fines the different system end users with their particular interac-tion map and the navigational accesses between the InteractionContexts of the map. Each Interaction Context is build out ofAbstract Interaction Units (AIU) which allow the developer tospecify what information or operations from the Object modelwill be available in the contexts. On top of the AIU’ AbstractInteraction Patterns can be applied, specifying enhanced dataretrieval/operations mechanisms.

Interaction modeling has been integrally adopted by the ex-tended OOWS 2.0 method, but some alterations were appliedin order to provide better support for data handling on eventsproduced in the presentation layer. Also was the Interactionmetamodel prepared to allow presentation and semantics weav-ing mechanisms.

C. Presentation modeling

Presentation modeling allows to specify presentation ele-ments on Interaction model elements. For instance, it allowsto specify that a particular Service AIU input argument will berepresented as an input field, option box or etc.

OOWS 2.0 Presentation modeling was only focused on theAdobe Flex implementation technology. It proposes hard codedInteraction model element-Presentation model links with on topa presentation weaving mechanism that allows to overrule thehard coded links.

This work provides multi implementation support by in-troducing next to Adobe Flex, support for HTML5, jQuery-JavaScript, achieved by creating a new Presentation metamodelfor these technologies. Also was ensured that the Adobe Flexand HTML5, jQuery-JavaScript metamodel elements inheritfrom a top parent class that incorporates support for weavingmechanisms.

To avoid the single technology bound hard coded links, a de-fault weaving mechanism between Interaction metamodel ele-ments and Presentation model elements with on top of it a over-riding weaving mechanism between Interaction model elementsand Presentation model elements has been introduced. This pro-posal allows for instance that by default presentation weaving aService AIU is linked to a HTML5 text input field, and if neces-sary, a particular Service Input Arguments could by overridingpresentation weaving be linked to a HTML5 textarea, combo,etc. input field.

D. Semantic modeling

Semantic modeling is a whole new part that has been intro-duced to the OOWS 2.0 method. Its goal is to provide supportfor the development of semantically annotated web applications.The targeted elements of the application for annotation includeboth the data elements and the presentation elements, this lastone, to provide support for possible applications in for disabledusers. The Semantic modeling consists out of a Semantic modeland a weaving model.

The Semantic model allows developers to introduce the on-tologies they want to use to semantically annotate elements ofthe application. This support was achieved by defining a new

Semantic metamodel that provides ontology modeling supportfor the RDFa, Microdata and Microformats technologies. Againwas ensured that the metamodel elements inherit a top parentclass which incorporates support for weaving mechanisms.

The Semantic weaving mechanism is similar to the Presenta-tion weaving mechanism, but has been extended as multiple se-mantic annotations can be applied simultaneously on a Concep-tual/Presentation model element. The default semantics weav-ing mechanism allows to link multiple Semantic model elementsto a Conceptual/Presentation metamodel element. The overrid-ing semantics weaving mechanism allows to fully/partly over-ride the default semantics weaving, or to apply apply the defaultand overriding semantics weaving links in parallel on a Concep-tual/Presentation model element.

E. Model to code generation

The Model to Code (M2C) generation phase allows develop-ers once they have formally modeled their web application withthe method, to obtain automatically generated code accordingto the models. One of the biggest advantages of automated codegeneration is that developers can not create buggy code due tohuman carelessness during manual implementation, if the M2Ctransformations have been well defined the only problems thatmay arise are conceptual mistakes the developer introduced dur-ing the modeling step.

The proof of concept M2C generation for the OOWS 2.0method was implemented using Xpand-Xtext from the EclipseModel to Text project. The output technologies targeted bythe M2C generation implementation are the J2EE framework,including the Hibernate framework for the persistence layer,Java for the business layer and JSP, HTML5, jQuery-Javascript,RDFa, etc. for the presentation-semantics layer.

III. CONCLUSIONS

A. Achievements

This work successfully extended and completed the OOWS2.0 [1] model driven web development method, adding supportfor: 1/ multiple implementation platforms, with the support ofHTML5 and jQuery-JavaScript presentation technologies in ad-dition to Adobe Flex, 2/ semantic annotations, allowing multiplesemantic annotations and annotation technologies to be appliedsimultaneously, 3/ model compilation allowing ready for deployweb applications to be generated from model instantiations.

B. Limitations-future work

Although the objectives of this work have been accomplished,the work also has its limitations and can be further completed: 1/The HTML5, jQuery-JavaScript presentation metamodel shouldbe further completed, and the support for enhanced eventsshould be further extended. 2/ Code to Model transformationsthat automatically generates Semantic models from ontologies.3/ Presentation layer code beautifiers could be created to refor-mat the generated code in the standard aligned format.

REFERENCES

[1] Francisco Valverde Girome, OOWS 2.0, Un Metodo de Ingenierıa WebPara la Produccion de Applicaciiones Web 2.0, Universidad Politecnica deValencia, 2010.

CONTENTS viii

Contents

Foreword i

Permission for usage iii

Overview iv

Overview v

Extended abstract vi

Contents viii

Used abbreviations xii

1 Introduction 1

1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Dissertation structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 9

2.1 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 OMG’s MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Elipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . 12

2.1.3 Eclipse M2T project . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Object Oriented Web Solution (OOWS) . . . . . . . . . . . . . . . . . . . 14

2.2.1 OOWS 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 OOWS 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 OOWS 2.0 conceptual modeling illustration . . . . . . . . . . . . . 16

2.3 Used web technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.1 Java 2 Platform, Enterprise Edition (J2EE) . . . . . . . . . . . . . 25

CONTENTS ix

2.3.2 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.3 jQuery - JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.1 Resource Description Framework (RDF) - RDFa . . . . . . . . . . . 28

2.4.2 Microformats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.3 Microdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 State of the Art 32

3.1 WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1.1 Method overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1.2 Support for RIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.3 Support for Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 OOH4RIA - SM4RIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Support for RIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


3.3 WSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39


3.4 Rux method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.5 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5.1 UWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5.2 SHDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5.3 HERA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6.1 RIA’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.6.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 WEB 2.0 case study 48

4.1 OO-Method Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Interaction Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 RIA interface modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.5.1 OOWS 2.0 available support . . . . . . . . . . . . . . . . . . . . . . 57

4.5.2 Missing support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 The solution in a nutshell 58

5.1 Requirements modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 Conceptual modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1 Object modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.2 Interaction modeling . . . . . . . . . . . . . . . . . . . . . . . . . . 61

CONTENTS x

5.3 Presentation modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4 Semantic modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.5 Model to Code (M2C) generation . . . . . . . . . . . . . . . . . . . . . . . 66

5.6 ToDo after generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Extending OOWS 2.0 presentation modeling 68

6.1 New presentation metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.1.1 HTML5 metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.1.2 jQuery metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 Extending presentation weaving . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.1 Default presentation weaving . . . . . . . . . . . . . . . . . . . . . 74

6.2.2 Overriding presentation weaving . . . . . . . . . . . . . . . . . . . . 75

6.3 Adding support for events at conceptual level . . . . . . . . . . . . . . . . 77

6.4 Overview available RIA functionality . . . . . . . . . . . . . . . . . . . . . 79

7 Adding semantics modeling to OOWS 2.0 81

7.1 Ontology modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.1.1 RDFa metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.1.2 Microdata metamodel . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.2 Semantics weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.2.1 Default semantics weaving . . . . . . . . . . . . . . . . . . . . . . . 86

7.2.2 overriding semantics weaving . . . . . . . . . . . . . . . . . . . . . . 87

8 Generating code out of the models 89

8.1 General generation overview . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.2 Defining M2C transformations . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.2.1 Xpand - Xtext motivation, introduction . . . . . . . . . . . . . . . 91

8.2.2 Starting Xpand M2C transformation . . . . . . . . . . . . . . . . . 92

8.3 Transformations for the persistence layer . . . . . . . . . . . . . . . . . . . 93

8.3.1 Object model M2C transformation . . . . . . . . . . . . . . . . . . 94

8.4 Transformations for the business layer . . . . . . . . . . . . . . . . . . . . . 97

8.4.1 Object model M2C transformation . . . . . . . . . . . . . . . . . . 97

8.4.2 Interaction model M2C transformations . . . . . . . . . . . . . . . . 99

8.5 Transformations for the presentation layer . . . . . . . . . . . . . . . . . . 100

8.5.1 Preparation for interaction model generation . . . . . . . . . . . . . 100

8.5.2 Interaction model M2C transformations . . . . . . . . . . . . . . . . 101

8.5.3 Interaction model, object model, default variables and overriding

models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.6 Generating code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.6.1 Generation workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 106

CONTENTS xi

8.7 Deploying the application . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

8.7.1 Filling in the skeleton EJB . . . . . . . . . . . . . . . . . . . . . . . 108

8.7.2 Using Hibernate for the persistence layer . . . . . . . . . . . . . . . 108

8.7.3 Deploying on GlassFish server . . . . . . . . . . . . . . . . . . . . . 108

8.8 Generated 23AndMe application . . . . . . . . . . . . . . . . . . . . . . . . 109

8.8.1 RIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8.8.2 Semantic annotations . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9 Conclusions 112

9.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

9.2 Limitations - future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Bibliography 116

USED ABBREVIATIONS xii

Used abbreviations

CRUD Create Update Delete

HTML HyperText Markup Language

DOM Document Object Model

RIA Rich Internet Application

AJAX Asynchronous JavaScript and XML

MDA Model Driven Architecture

OOWS Object Oriented Web Solution

M2C Model to Code

M2M Model to Model

PHP Hypertext Preprocessor

CSS Cascading Style Sheets

OMG Object Management Group

CIM Computational Independent Model

PIM Platform Independent Model

PSM Platform Specific Model

fig. figure

CMW Common Warehouse Metamodel

MOF Meta Object Facility

UML Unified Modeling Language

XMI XML Metadata Interchange

OCL Object Constraint Language

QVT Query View Transformation

USED ABBREVIATIONS xiii

EMF Eclipse Modeling Framework

EMOF Essential MOF

CMOF Complete MOF

M2T Model to Text

OO Object Oriented

OO-Method Object Oriented software production Method

J2EE Java 2 Platform, Enterprise Edition

IC Interaction Context

AIU Abstract Interaction Unit

SIU Service Interaction Unit

AIP Abstract Interaction Pattern

W3C World Wide Web Consortium

RDF Resource Description Framework

URI Uniform Resource Identifier

DC Dublin Core

FOAF Friend Of A Friend

SIOC Semantically Interlinked Online Communities

WebML Web Modeling Language

ER Entity Relationship

OOH Object-Oriented Hypermedia

SM4RIA Semantic Models for RIA

GUI Graphical User Interface

GWT Google Widget Toolkit

CTT Concurrent Task Tree

XSLT EXtensible Stylesheet Language

UI User Interface

UWE UML based Web Engineering

INTRODUCTION 1

Chapter 1

Introduction

1.1 Context

The work described in this master dissertation is situated at the union of web development

and Model Driven Architecture (MDA) on one hand, and the Semantic Web on the other.

Over its 12 year’s existence, the web has evolved significantly. The first version of the

web, now identified as WEB 1.0, was mainly characterized by static hypertext documents

interconnected by hyperlinks. Content providers were responsible for publishing the web’s

information, which was consumed by passive end users. The interaction model was simple

and purely pull-based: the user requested desired information (http request), which was

subsequently delivered by the server (http response) in the form of a structured HyperText

Markup Language (HTML) file. The information flow was virtually one-way, from the

server to the client. Form-based interaction enabled the user to submit information to the

web server, but in the WEB 1.0 model, the separation between content provider and user

largely remained.

The successor of WEB 1.0 is todays massively used WEB 2.0 (read more details at 2.3).

The evolution to the WEB 2.0 was not sparked by technical advances, but rather by the

stronger user involvement: the clear separation between content providers and content

consumers is fading, and users now actively participate in the web by posting and sharing

content. It is therefore often also called social web as users use it intensively to interact

and collaborate with each other. Some of the most popular examples of Web 2.0 sites are

Facebook, Wikipedia, YouTube, etc.

1.1 Context 2

The above paradigm shift was also fueled by advances in usability and user experience, en-

abled by various technological advances such as asynchronous client-server communication

and intelligent (fat) clients enhanced with technologies such as Adobe flash, the Adobe

flex framework and/or Ajax/JavaScript frameworks such as jQuery, Prototype, etc. These

frameworks allow dynamic updates of the Document Object Model (DOM) on receipt of

new asynchronous data or other events without the need for reloading the complete page.

This allowed web user interfaces with enhanced representation and interaction possibilities,

which effectively made them resemble user interfaces of traditional desktop applications.

This kind of web applications are therefore often identified as Rich Internet Applications

(RIA) [Duhl, 2003] under the umbrella of WEB 2.0. Important building blocks for RIA

applications are widgets. Widgets are small reusable pieces of software typically created

in client-side technologies such as Adobe Flash or JavaScript, and are often targeted to

carry out a determined task. The Web has thus evolved into one of the most important

application development and deployment platforms, and the market share of Web software

is still rising. Rich web applications and software services are directly accessible by users

on the web through their web-browser without the need to install additional applications.

The last evolution in the web, often dubbed as WEB 3.0, is ongoing. WEB 3.0 aims to ex-

tend the existing WEB 2.0 by making published data machine readable and interpretable.

This goal is achieved by adding semantic annotations into the source code of webpages so

machines can interpret the content of the webpages. Some key technologies used to specify

annotations are RDFa, microdata and microformats (read more about them at 2.4). Unlike

the WEB 2.0, WEB 3.0 has little direct influence on the users web experiences. Rather, by

making content of webpages machine interpretable, the information on web pages can be

exploited by machines using logic and algorithms to provide new enhanced services for the

users. One of the envisioned services are for instance more intelligent search engines, that

provides more accurate and qualitative search results by exploiting the machine readable

data within webpages.

An ordinary software development process is often carried out in a set of phases: re-

quirements detection and system analysis, followed by system design, are typically the

first and crucial steps of the software development cycle that to a large extent determine

the quality aspects of the final product. Models use to be the output artifacts of these

development phases. Based on the produced artifacts, the final application is implemented

incrementally or in subsequent phases.

1.2 Problem statement 3

An alternative for manual implementation is automatic code generation based on artifact

instances. This alternative software development method is called Model Driven Archi-

tecture (MDA) (read more at 2.1). The goal of MDA is ambitious: it aims to eliminate

manual code implementation as manual implementation involves important disadvantages

such as elevated implementation cost, difficult reusability, human errors, etc. Instead,

MDA offers Model to Model transformation to (partly) derive one model (instance) from

another, and Model to Code (M2C) transformations to generate the final product accord-

ing to the specifications defined in the models and the transformations. MDA also makes

it possible that the same model can be provided to other M2C transformation specifica-

tions and generate code with equal functionality in different implementation languages or

for different deployment platforms. By deploying code generation, MDA aspires to make

software development faster, cheaper and easier to maintain.

This dissertation is situated at the union of web development, MDA and the Semantic

Web, bringing them together in order to exploit the advantages of MDA in web devel-

opment, while contributing to the creation of the Semantic Web. As mentioned earlier,

web development is an important branch in software development and most of the web

development methods originating from the Web Engineering community are MDA based,

e.g., WEBML, OOH, WSDM and OOWS. OOWS is the MDA framework within which

the work described in this dissertation is situation.

1.2 Problem statement

As mentioned before, bringing Web development and MDA together is not a new idea.

Several methods have already been published (some of them are discussed here 3). However,

most of these methods stem from the Web 1.0 era. Although most of them have proposed

some extensions to support Web 2.0 and modern Rich Internet Applications, most of

the methods do not fully support current capabilities of RIAs, nor do they support the

different implementation platforms that are currently available. In particular, to the best

of my knowledge, no method currently supports HTML5 combined with javascript, which

is a popular and promising implementation choice. Finally, to the best of my knowledge,

only one method (OOH4RIA) has some support to generate semantic annotations; no

method has support to generate different types of annotations that semantically describe

1.2 Problem statement 4

the content. The aim of this dissertation is to fill this hiatus, and extend an existing model-

driven web development method, OOWS 2.0, to support fully functional RIAs, included

support for different types of semantic annotations (for elaborated objectives, see 1.3).

The work done in this dissertation is founded on the work of [Pastor and Molina, 2007] and

especially on the work of [Girome, 2010]. The foundation created in both works is called

the Object Oriented Web Solution (OOWS) (more details here 2.2), which is a conceptual

modeling method for web applications. The original version of OOWS was dedicated to

WEB 1.0 applications. With this version it was possible to specify a WEB 1.0 application

through modeling and by executing M2C transformations on those models to generate Hy-

pertext Preprocessor (PHP) code for the final WEB 1.0 application. The generated code

artifacts of the OOWS 1.0 method could then be deployed instantly with the OOWS 1.0

default representation setting or enhanced with Cascading Style Sheets (CSS) to adapt the

representation to the user needs.

As web evolved towards the current WEB 2.0 version, OOWS had to be revised in or-

der to support the specification of the new development elements introduced by WEB 2.0

such as RIA’s and widgets. The result of this revision was OOWS 2.0, that allows de-

velopers to specify WEB 2.0 applications by modeling them. In contrast to OOWS 1.0,

for the 2.0 version next to modeling specifications no M2C transformation implementation

has been created yet. OOWS 2.0 just like many other MDA methods provide concep-

tual modeling possibilities, but only few of them report support for all required M2C

transformations. In order to make from OOWS 2.0 a real MDA compliant method, M2C

transformations have to be defined. These M2C transformations would take the OOWS

2.0 model specification of an WEB 2.0 application as input and generate the code for

the corresponding application. If this goal can be achieved, OOWS 2.0 would be one of

the few methods that as of today has full MDA support for WEB 2.0 and RIA applications.

Currently OOWS 2.0 is just a proposal, no real WEB 2.0 applications have been gen-

erated nor implemented manually guided by OOWS 2.0 models. It is therefore important

that the OOWS 2.0 method is reviewed in order to verify if all necessary requirements can

be modeled for subsequent code generation. If some concepts lack or errors arise in the

method, they first will have to be tackled before further investigation is to be dedicated to

the method.

Even if OOWS 2.0 gets fully MDA compliant to generate WEB 2.0 and RIA applica-

tions, with semantic web (WEB 3.0) upon us, the current OOWS 2.0 method proposal is

1.3 Objectives 5

to be outdated when industry starts massively adopting WEB 3.0. Therefore it is nec-

essary to extend the current OOWS 2.0 version with support for semantic annotations.

OOWS 2.0 already carries a lot of semantic information in its models such as classes with

their attributes and relationships between them representing the domain covered by the

intended web content. Also representation and structure elements of the modeled WEB

2.0 application are identified within the model. All these natively available knowledge,

which is currently not exploited, makes that OOWS 2.0 is perfectly suited to be extended

with support for semantic annotations.

1.3 Objectives

This dissertation aims to extend the existing OOWS 2.0 method to 1/ support different

implementation platforms, in particular HTML5 with javascript, 2/ support the generation

of different types of semantic annotations.

Presenting just another proposal about how the existing OOWS 2.0 method could sup-

port different target implementations and different types of semantic annotations is not

enough in this dissertation. This dissertation is more ambitious as it really aims to demon-

strate that the conceptual abstractions underlying OOWS 2.0 (which will be adapted if

necessary) effectively allow code generates for different platforms. The method has previ-

ously already been used for other representation technologies, in particular Adobe Flex.

It is important to demonstrate that OOWS 2.0 provides modeling support for the latest

currently actively used WEB 2.0 implementation technologies such as HTML5, jQuery, etc.

The adaptions to OOWS 2.0, and a proof of concept M2C transformation(s) to support

this, will therefore be focused on code generation for these latest implementation technolo-

gies. This M2C transformation should take as input our semantically extended OOWS 2.0

models and should generate as output the corresponding WEB 3.0 application.

Furthermore, I want to show that the semantically extended version of OOWS 2.0 is viable

alternative for ordinary WEB 3.0 software production, and is able to generate different

types of semantic annotations (i.e., in different formats). In other words, I aim to show

that, with my envisioned extensions, OOWS 2.0 provides the necessary requirements to

generate complete WEB 3.0 applications out of model specifications in different targeted

implementations, while avoiding the disadvantages of manual implementation.

1.4 Approach 6

1.4 Approach

The work dedicated to this dissertation can be divided in different tasks that have to be

carried out. First an immersion into OOWS, WEB in general is necessary in order to

understand both environments thoroughly, therefore an extended case study is carried out

on an existing WEB 2.0 website1. The website is first modeled using the existing OOWS

2.0 method. If inconsistencies occur or concepts are encountered on the website that can

not be modeled, the existing OOWS 2.0 method has to be adapted or extended.

Once the website has been modeled, a manual implementation guided by the previously

created OOWS 2.0 models is carried out. The goal of this manual implementation is to ob-

tain familiarity with the latest web development technologies and to test the completeness

of the models to guide manual implementation. The technologies used for the manual im-

plementation are the J2EE and Hibernate framework combined with HTML5, the jQuery

framework and JavaScript.

Next, M2C transformation concepts and technology knowledge has to be acquired. This

knowledge is subsequently to be applied by defining the M2C transformations that gener-

ate out of the previously defined OOWS 2.0 models from the case study 23AndMe website,

WEB 2.0 code for the J2EE and Hibernate framework combined with HTML5, jQuery and

JavaScript. Keeping in mind that OOWS 2.0 was originally targeting the Adobe Flex, the

OOWS 2.0 metamodels also need to be adapted/extended to support the aforementioned

technologies.

The next step in the dissertation is to get a grip on semantic annotations and the available

specification languages focused for web development. This in order to extend the existing

OOWS 2.0 method with support to model WEB 3.0 applications. Using this knowledge,

the OOWS 2.0 method is finally to be extended in order to support the new WEB 3.0

annotation requirements. Once OOWS 2.0 provides this support, the earlier created M2C

transformation can be further extended to allow M2C transformations for semantic an-

notations. In order to test the previous, relevant semantic information is added to the

1http://www.23andme.com

http://www.23andme.com

1.5 Dissertation structure 7

earlier defined model of the 23AndMe website case study, and subsequently the new M2C

transformations with support for semantic annotations are tested.

The result is an extended OOWS 2.0 method, that allows modeling of a Web 3.0 appli-

cation, including semantic annotations in different formats, and support proof-of-concept

code generation to provide a fully functional HTML5 and Javascript Web 3.0 website.

1.5 Dissertation structure

Ending this Introduction chapter, the content of the remaining chapters is described briefly:

• Chapter 2: Background presents the fundamentals about MDA, OOWS, Web

technologies and Semantics necessary to understand the rest of the work described

in this dissertation.

• Chapter 3: State of the Art gives an overview of parallel proposals to the work

presented in this dissertation. There are many model driven web development pro-

posals, but only the ones that really have similar solutions to the objectives of this

dissertation are discussed.

• Chapter 4: WEB 2.0 case study applies a case study on a typical Web 2.0

application. It gives at one hand an example of the original OOWS 2.0 method in

practice and on the other hand presents illustrative examples of what is aimed to be

possible with the extended OOWS 2.0 method.

• Chapter 5: The solution in a nutshell gives an overview of the solution pre-

sented by this dissertation. It provides the web development process proposed by

the extended OOWS 2.0 application and how this was achieved starting of from the

original OOWS 2.0 method.

• Chapter 6: Extending OOWS 2.0 presentation modeling describes in detail

how multi presentation implementation platform support was achieved, how support

for the specification of enhanced user events was added, and how a new presentation

metamodel was defined to provide support for HTML5 and jQuery - JavaScript.

It further describes how new weaving mechanisms were defined that allow to link

Interaction model elements with Presentation model elements without hard coded

links.

1.5 Dissertation structure 8

• Chapter 7: Adding semantics modeling to OOWS 2.0 describes how new

support for semantic web was added to the method. It describes the Semantic meta-

model created to allow ontology modeling, and the enhanced weaving mechanisms

that allows to bind Object/Presentation model element to multiple Semantic model

elements.

• Chapter 8: Generating code out of the models describes how a proof of concept

M2C transformation was implemented that allows to obtain automatically generated

code out of the extended OOWS 2.0 method models.

• Chapter 9: Conclusions gives an overview of the work carried out during this

dissertation, including an enumeration of the objectives that were tackled and the

limitations and future work of the extended OOWS 2.0 method.

BACKGROUND 9

Chapter 2

Background

2.1 Model Driven Architecture

2.1.1 OMG’s MDA

As already mentioned in the in the Introduction chapter 1, Model Driven Architecture

(MDA1) is an alternative for ordinary model guided development where models were only

used as artifacts that guide manual software implementation. MDA is a framework estab-

lished by the Object Management Group (OMG) for software development that is based

on a set of standardized technologies. The basic idea is to separate business functionality

from its specification on a determined technological platform. This separation automati-

cally ensures that the final product will be portable, interoperable and reusable because of

the “Model once, generate everywhere” philosophy. Standard MDA development is carried

out using four different artifacts:

• Computational Independent Model (CIM) is the place where business context,

business processes and business requirements are modeled, it also specifies whether

those are going to be implemented or not. Although its interesting characteristics,

this model is often abandoned due to the difficult mapping between CIM and PIM.

• The Platform Independent Model (PIM) or domain model is a high-level ab-

straction model independent from final implementation technologies. The nature of

PIM makes the model valid for multiple technological implementation platforms.

• The Platform Specific Model (PSM) is a model different for each technology.

1http://www.omg.org/mda/

http://www.omg.org/mda/

2.1 Model Driven Architecture 10

For example in a default three tier application (see fig. 2.1), a specific PSM is needed

for each tear (DB, EJB and JSP).

• Code is the final output of the MDA development cycle.

Figure 2.1: MDA development cycle for three tier applications (image taken and modified from

[van der Krogt, 2006])

The MDA framework is based on different standardized technologies, the most important

of them are listed and discussed briefly below:

• Meta Object Facility (MOF) is a conceptual framework for the formal defini-

tion of modeling languages. MOF metamodels are usually modeled as a UML class

diagram.

• Unified Modeling Language (UML) is a MOF compliant language that allows

to define the different models that are used during the development process.


• XML Metadata Interchange (XMI) is a standard interchange language for MDA

models. It allows models to be transported across networks, to be stored an retrieved

in repositories with version control and to be transformed into other formats.

• Object Constraint Language (OCL) is a textual declarative language that allows

to specify advanced constraints on MOF models. This language was created because

graphical modeling syntax was not always suitable to specify some advanced concepts.

• Query View Transformation (QVT) is a model transformation language. It

allows model to model (M2M) and model to code (M2C) transformations.

The basic components in the MDA code generation components are:

• Metamodel is a type of special model (defined using MOF) that specifies the ab-

stract syntax of a modeling language. It only defines structure, it does not contain

further semantic information.

• Specification is an instance of a metamodel which is also a model and that contains

the necessary functional information about a certain software product for subsequent

code generation.

• Code generator takes as input the specification model. It also needs to know the

metamodel of the specification model it takes as input in order to be able to exploit

the modeled concepts. According to the specification in the model and the specifica-

tion in the M2C transformation, the final output in the form of code is generated.

Figure 2.2: MDA code generation process (image taken from [Insfran, 2012a])


Just with the objective to clarify the MDA model hierarchy, the well known OMG UML

model hierarchy is illustrated in fig. 2.3. The figure shows that the MOF specification

is the highest level in the hierarchy (M3). Using MOF instances, a metamodel for any

desired type of model can be created. In the case of fig. 2.3 the metamodel of the UML

modeling language is defined as a MOF instance at the M2 level. Now having the UML

metamodel defined, UML model instances can be created at the M1 level. An example of

such an instance could be a class diagram for a simple application. The lowest M0 level

would then be the instances or objects of the earlier defined class model.

Figure 2.3: UML hierarchy (image taken from [Insfran, 2012b])

2.1.2 Elipse Modeling Framework (EMF)

EMF started as an Eclipse implementation of OMG MOF and has evolved from there. It

is a Java framework that contains a modeling framework and code generation facility for

building tools and other applications based on structured data models. The MOF-like core

metamodel from the EMF modeling framework is called Ecore (see fig. 2.4 for the Ecore

metamodel structure). It is similar to the subset of the current MOF 2.0 model, which is

called Essential MOF (EMOF). Starting with this Ecore metamodel, Ecore models can be

created that on their half can again serve as metamodels for other models (see the level

in the previous UML example 2.3). Also the OOWS 2.0 method 2.2.2, discussed further

in this chapter is structured this way. The top level is the Ecore metamodel, that is used

to define the second level OOWS 2.0 metamodel, that on its turn is used to define the

OOWS 2.0 models. Ecore models are stored in the interchangeable standard XMI format,

so OOWS 2.0 models could be handled in other environments to. For more information

on EMF, please see the EMF Developer Guide2.

2http://help.eclipse.org/ganymede/index.jsp?nav=/14

http://help.eclipse.org/ganymede/index.jsp?nav=/14


Figure 2.4: Ecore metamodel (image taken from [help.eclipse.org, ])

The code generation facility available in default EMF allows EMF data models to be trans-

formed into Java classes. For customized model transformations (not just java classes),

customized Ecore metamodels and instantiations of those metamodels can be defined and

handled by the technologies from the Model to Text (M2T) Eclipse project.

2.1.3 Eclipse M2T project

The Eclipse Model to Text (M2T) project is focused on generating textual artifacts from

models with three main purposes:

• Provide implementations of industry standard and defacto Eclipse standard model-

to-text engines.

• Provide exemplary development tools for these languages.

• Provide common infrastructure for this languages.

The three implementation languages currently supported by the M2T project are:

2.2 Object Oriented Web Solution (OOWS) 14

• Accelo

• Xpand

• Jet

Out of this three languages, Xpand is the one that has the broadest support and was

therefore chosen for implementing the M2C transformations needed in this dissertation. It

is a sequential imperative transformation language that also can be extended with Xtext3

and thereby make use of pure Java functionality. For more information about the Xpand

and the Eclipse M2T project, please visit the M2T project homepage4.

2.2 Object Oriented Web Solution (OOWS)

2.2.1 OOWS 1.0

OOWS 1.0 is an object oriented (OO) model driven software production method for au-

tomatic web application generation defined by [Pastor et al., 2008]. It extends the object

oriented software production method (OO-Method) [Pastor et al., 2001] by adding expres-

sivity to capture the navigational and presentation requirements necessary for web appli-

cations. The OOWS 1.0 software production method consists out of four main activities:

1. Requirements modeling is used to obtain the application specification.

2. Conceptual modeling is the crucial activity in the of the method that specifies

the conceptual models for web applications. This activity can be subdivided in four

sub-activities.

(a) OO-Method modeling is the first activity to be carried out that describes the

statical structure of the final product in a type of class diagram. The information

captured during this activity forms the base for the following models.

(b) User modeling constructs a user diagram that specifies the different users

types that are going to use the final product. This model is related to the

classes of the OO-Method model that have been defined as agents.

(c) Navigation modeling describes how the different user types have access to

the resources in the final product. Each user type has its own navigational

3http://www.eclipse.org/Xtext/4http://www.eclipse.org/modeling/m2t/

http://www.eclipse.org/Xtext/

http://www.eclipse.org/modeling/m2t/


map that defines the routes a particular user type can follow to access a certain

resource. The different resource in the navigational map are called Navigational

Contexts. These Navigational Contexts describe based on the first OO-Method

class diagram the information and functionality that is available in a certain

context.

(d) Presentation modeling defines a model to determine the presentation of the

available information in the different Navigation contexts. The representation

is described by means of representation patterns. This representation modeling

activity is very basic, it allows in certain cases to specify how information is

structured on a web page.

3. Model compilation automatically generates the final application after choosing

a specific architectural style often determined by the target technological platform.

Once the style and platform is determined, correspondences between abstraction

primitives and the technological elements available in the target platform are estab-

lished and the final application is generated.

4. Presentation design is an optional activity that is carried out if the developer is

not satisfied by the default representation generated by the OOWS 1.0 M2C trans-

formation.

The OOWS 1.0 method had all the necessary specifications for WEB 1.0 applications.

With the arrival of WEB 2.0 OOWS had to be brought to the next level, resulting in

OOWS 2.0.

2.2.2 OOWS 2.0

The 2.0 version of OOWS defined by [Girome, 2010] is an extension of the 1.0 version

described earlier. The fundamental modifications were introduced in the conceptual mod-

eling phase of ordinary OOWS development. In this phase, new models were added to

support the new features of WEB 2.0 applications. The new conceptual modeling phase

is again subdivided in a four sub-activities. The fist two activities are obligatory, they

provide all the necessary support for in case the the developers want to develop a WEB

1.0 application. If instead a WEB 2.0 application is desired, two extra activities have to

be carried out.

1. Object modeling is adopted from the OOWS 1.0 method and remained untouched

in OOWS 2.0.


2. Interaction modeling combines the previous User modeling and the Navigational

modeling. The Abstract Interaction model represents the interaction between the

user and the application. It is basically a more expressive model than previous

models as it provides support to specify enhanced user interaction.

3. Web 2.0 pattern modeling is an optional activity that enables developers to apply

WEB 2.0 patterns on previously modeled Abstract Interaction concepts. WEB 2.0

patterns are conceptual representations of common situations that occur during WEB

2.0 development.

4. RIA interface modeling is also an optional activity that provides developers the

possibility to create a model for the user interface of the final application. This

model is totally new compared to classic OOWS, where a only slightly modifiable

defect user interface was generated. The artifacts produced during this RIA interface

modeling step are:

• RIA interface model describes different widgets and other presentation ele-

ments together their behavior on user actions.

• Weaving model relates the widgets and other presentation elements defined

earlier in the RIA interface model with conceptual elements from the Abstract

Interaction model.

A general overview of artifacts produced during OOWS 2.0 development and their inter-

relations are showed in fig. 2.5

2.2.3 OOWS 2.0 conceptual modeling illustration

The work flow during the conceptual modeling activity of OOWS 2.0 is illustrated in fig.

2.6. Further the details of each model model are described.

Object model

As illustrated in fig. 2.6 the first step in the work flow is to define OO-Method models. In

OOWS 2.0, Object models are similar to UML class diagrams. The Object model allows

developers to specify the different information entities (classes) with their corresponding

interrelations and services that are going to be available in the end product. Because UML

class diagrams are very common and very well known, no further explanation is dedicated

to this model.


Figure 2.5: OOWS 2.0 artifcats (image taken from [Girome, 2010])

Abstract interaction model

The next step in the work flow is interaction modeling. To start of, in OOWS 2.0 there

are already 2 different types of users: the Anonymous user and the Registered user. As

the names of the user types indicate, the Anonymous user accesses the web application

without identification. The Registered user on the other hand has to authenticate himself

before he can access his resources. For the registered user type, different sub users (agents)

can be instantiated with their own closed user environment.

• First the different users and their properties have to be modeled. As an example, fig.

2.7 shows an instantiation of a User class for a Researcher agent. This User class

defines based on a previously defined OO-Method object model class diagram the

attributes that are always available for the application while handling this agent.

• Second, the Interaction map of the agents can be defined. The interaction map

defines the different resources (Interaction Contexts (IC)) the agent has access to,

and how these Interaction contexts are accessed. The principal Interaction context

access types are 1st level and Sequence. 1st level means that this interaction context

can be accessed always, no matter where the user is on the application. Sequence from

its part, means that the user has to follow a defined rout to get to this Interaction

context. An illustration of an Interaction map for the previously defined Researcher

agent can be seen in fig. 2.8.

• As ultimate, each interaction context of the Interaction map has one or multiple


Figure 2.6: work flow of the OOWS 2.0 conceptual modeling process (image taken from

[Girome, 2010])

Abstract Interaction Units (AIU) defined within it, and possible Abstract Interaction

Patterns (AIP) applied on the content of the AIU’s. There are 2 types of AIU

available in OOWS 2.0:

– An Population AIU represents a delineated view over the data objects from

the Object Model. The Population AIU is compound out of a collection of

classes that refer to the classes of the Object Model. From each class that is

represented in the Population AIU, its attributes may be selected so that these

will be visible to the end user. Each Population AIU has a manager class spec-

ified from which other complementary classes can be represented following the

relationships specified in the Object Model. Also provides the Population AIU

the possibility to define navigation links that provide access to the sequentially

accessible IC’s. This navigation links can be defined on class attributes and

inner class relationships. Using this navigation links, the users is transfered to

the requested IC where the manager Object of the target AIU is obtained by an

identifier parameter in the navigation link. An example of such an Population


Figure 2.7: OOWS 2.0 user class for Researcher agent (image taken from [Girome, 2010])

Figure 2.8: OOWS 2.0 Researcher agent Interaction map (image taken from [Girome, 2010])

AIU is demonstrated in fig.2.9.

– A Service AIU represents an operation from the Object Model that can be

executed. Each Service AIU has a series of input arguments that correspondent

to the arguments of the operation from the Object Model. On each input

argument a data type, default value and constant parameter can be defined.

An example of an basic Service AIU is illustrated in fig.2.10

– In order to provide enhanced interaction in AIU’s, Abstract Interaction Pat-

terns (AIP) can be applied on them. In fig.2.11 a general overview where the

different AIP’s can be applied is showed. The different AIP’s defined in OOWS

2.0 are described briefly:

∗ Applying the Filter AIP on an Population AIU the developer specifies

that a certain constraint on the data shown in the context can be issued

by the end users in order to achieve a better overview of the available data.

Basically two types of filters are available, a Static filter and a Dynamic

filter. In the first case the user can’t modify the filter constraint, where in


Figure 2.9: OOWS 2.0 Population Abstract Interaction Unit example (image taken from

[Girome, 2010])

Figure 2.10: OOWS 2.0 Service Abstract Interaction Unit example (image taken from

[Girome, 2010])

the second case the user can form its own constraints.

∗ The Index AIP can be interpreted as an variant to the static filter, with

the difference that the user has the possibility to to select one out of many

predefined constraints on the available data in the Population AIU.

∗ Summary View allows the developer to apply a summarization view on

data. A collection of data could thus be summarized in one keyword and

when the end users click that keyword, the whole collection becomes visible.

∗ Order Criteria allows data to be represented in another order than when

the data was retrieved from the datasource.

∗ The Pagination AIP can be defined to avoid endless scrolling through data

on a webpage.


Figure 2.11: OOWS 2.0 Interaction Model structure (image taken from [Girome, 2010])

∗ Defined List is a AIP that is applied on Service AIU’s that enables users to

fill in an input field by selecting an item out of a predefined set of elements.

The elements of the predefined list can be static enumerations or they can

be retrieved dynamically from objects out of the Object Model

∗ A Validation Rule can be applied to an input field of an Service AIU to

check whether the data the user introduced corresponds with the required

data type/format.

∗ Argument Setting enables the developer to set default values for input

fields.

∗ The Object Navigation AIP defines a navigation link from the current

Population AIU to another Population AIU in another Interaction Context.

The Object Navigation is defined on an attribute of a class from the current

population towards another Population AIU where the same class is the


Manager class so an instance identifier can be transmitted. Fig.2.12 gives

an illustration of an Object Navigation.

Figure 2.12: OOWS 2.0 Object Navigation (image taken from [Girome, 2010])

∗ The Relationship Navigation AIP defines a navigation to an Population

AIU of another Interaction Context based on a relation to a class. This

pattern can be used if the developer wants to specify a navigation to Popu-

lation AIU but he doesn’t want to use an attribute of that class as clickable

element to redirect to the other Population AIU. In stead a simple button

can be used to initiate the redirection. An example can be seen in fig.2.13.

Figure 2.13: OOWS 2.0 Relation Navigation (image taken from [Girome, 2010])

∗ Service Navigation AIP’s allow developers to define the AIU to be shown

after a Service AIU has been executed. Developers are allowed to specify a

condition such as “if success, if fail” to obtain conditional redirection.

∗ A Navigational Filter basically applies the functionality of the Filter

AIP, but applied to navigations. This way for some object instances of one

particular class, navigations can be allowed when for other object instances

not.

∗ The last Instance Edition AIP allows to carry out basic operation such

as create, update or delete on an object instance / object attribute without

the need to specify a Service AIU for that particular operation.

RIA model

OOWS 2.0 does not provide a direct modeling environment for RIA elements because of

the large quantity of technologies. In stead OOWS 2.0 proposes a general RIA metamodel


that can be used as a parent model to instantiate a customized metamodel for a certain

technology. A basic example of an Adobe Flex technology metamodel instantiation based

on the parent RIA metamodel is illustrated in fig.2.14. Next to Adobe Flex, many other

Figure 2.14: Adobe Flex metamodel with the OOWS 2.0 parent RIA metamodel (image taken

from [Girome, 2010])

WEB 2.0 technology metamodels can be instantiated. For instance, during this disserta-

tion an instance will be created for the HTML5 and jQuery technologies. Once the RIA

metamodel for the desired technologies has been defined, a RIA model can be instantiated

for the different elements the developer wants to use for the web application.

Next to WEB 2.0 RIA representation elements, interaction between different elements

and/or server logic is a very important characteristic of WEB 2.0. To support enhanced

interaction between RIA elements, the OOWS 2.0 method allows to specify event rules

to manage event generated by the different elements. The different reactions currently

supported by OOWS 2.0 method that RIA elements can carry out on event occurrence

are:

• Property change

• Data Request

• Invocation


• Validation

• UI Transition

Weaving model

Once the Abstract Interaction Model and the RIA model of the WEB 2.0 application have

been instantiated, the concepts from the Abstract Interaction Model and the concepts

from the RIA model can be linked. In fact, the weaving model does nothing more than

establishing a one to one link between a certain Abstract Interaction element and a RIA

element. An illustration is available at 2.15.

Figure 2.15: Weaving model example (image taken from [Girome, 2010])

2.3 Used web technologies 25

2.3 Used web technologies

The work in this dissertation is aims to target the latest WEB development technologies.

Web applications are usually developed with a three-tier architecture. This architecture is

very interesting for web applications as it enables easy modifications in one tier without

having to touch the other tiers. Also due to the tier architecture each tier can be optimized

for its own tasks. The different tiers identified in web applications are:

• Data tier is the place where information is stored and retrieved. Usually this tier

is implemented as a database with ODBC functionality.

• Business tier provides big part of the logic and processing required by the applica-

tion.

• Presentation tier uses the functionality provided by the previous business tier to

present the information in a desired structure to the end users. With todays WEB 2.0,

the presentation tier does not only simply presents the information to the end users

anymore. In order to provide enhanced user interfaces for improved user experiences,

more and more logic is added into this layer by means of RIA technologies.

2.3.1 Java 2 Platform, Enterprise Edition (J2EE)

J2EE5 is a popular Java platform for enterprise applications that provides within others

support for multi-tier applications. The platform is largely designed as modular concepts

tat can be deployed on an application server such as GlassFish6, JBoss7, etc. J2EE provides

complete/partial support for each of the three earlier discussed tiers. Also can the J2EE

support for certain tiers be extended with other not J2EE technologies. Following, just an

illustration of a possible WEB 2.0 architecture based on the J2EE framework.

• A typical J2EE web application could implement the Data tier in a MySQL database

with Hibernate8 relational persistence interfaces.

• The Business tier could on one hand build facades on the Hibernate relational per-

sistence interfaces with if necessary additional complex persistence logic. And on

the other hand provide functional business logic in Enterprise Java Beans (EJB) to

5http://www.oracle.com/technetwork/java/javaee/overview/index.html6http://glassfish.java.net/7http://www.redhat.com/products/jbossenterprisemiddleware/application-platform/8http://www.hibernate.org/

http://www.oracle.com/technetwork/java/javaee/overview/index.html

http://glassfish.java.net/

http://www.redhat.com/products/jbossenterprisemiddleware/application-platform/

http://www.hibernate.org/


prepare data from the facades for the upper Presentation tier, and process the data

received from the presentation tier to store it in the underlaying Data tier.

• The presentation tier from its part would use the underlaying Business tier to present

information to the end users. Many technologies are available to represent the data.

A possible proposal could be to represent the dynamic data in Java Server Pages

(JSP) and weave it within static HTML5 code. If more enhanced presentation log-

ic/functionality typical for WEB 2.0 applications is required, the Representation tier

can be extended with JavaScript code.

An overview of a possible J2EE web architecture is showed in fig. 2.16.

Figure 2.16: J2EE web architecture (image taken from [java.sun.com, ])

2.3.2 HTML5

HTML59 is the last and still in development version of the HyperText Markup Language

(HTML). HTML5 just like its predecessors is a markup language used to structure and

represent information in web applications. This last version of HTML aims to offer support

for the latest Mobile, WEB 2.0 and WEB 3.0 tendencies. The support it provides for mobile

web is to make it as lightweight as possible, so it can easily be executed on low resource

devices. For WEB 2.0, it includes new features such as the <canvas>, <video>, <audio>,

9http://www.w3.org/TR/html5/

http://www.w3.org/TR/html5/


etc. elements, and support for scalable vector graphics. Also new input types have been

added to the standard. In HTML5 it is possible to specify number, data, email, etc types

and even to set required, max, min restriction on the input fields. Towards WEB 3.0,

HTML5 offers some semantic additional annotation elements such as <nav>, <header>,

<atricle>, etc to indicate certain fields in a webpage. For more information about the

new features in HTML5, please visit the W3C HTML4-5 differences webpage10.

2.3.3 jQuery - JavaScript

Because HTML5 doesn’t always provide the most enhanced WEB 2.0 RIA support, frame-

works like jQuery11 can be added to become a more interactive application. In fact, jQuery

is a open source JavaScript library for client side functionality scripting. The most impor-

tant features the library provides are:

• Selecting element out of the Document Object Model (DOM) for all of the recent

popular web-browsers.

• Traverse the DOM and manipulate it.

• Capture and handle events from the DOM elements.

• Support for Asynchronous JavaScript and XML (AJAX) communication with server-

side.

• Support for graphical animations and effects.

• Extensible by means of plug-ins.

As mentioned before, jQuery is a JavaScript library that can be added to a web application.

This way a lot of prepared functionality is offered to the developers so they can apply it

instantly to their applications. If the functionality offered by the jQuery framework does

not suite the developers expectations, the developer can add additional JavaScript to make

it meet the expectations.

Because jQuery has as of today wider support on the recent popular web-browsers than

some of the new elements of the earlier discussed HTML5 standard, and because HTML5

sometimes offers less and even conflictive support for WEB 2.0 elements, this dissertation

opted to mainly use the jQuery framework for WEB 2.0 functionality development.

10http://www.w3.org/TR/html5-diff/11http://jquery.com/

http://www.w3.org/TR/html5-diff/

http://jquery.com/

2.4 Semantics 28

2.4 Semantics

Semantic annotations is the latest trend in web application development. The main goal of

the semantic web is to make the enormous amount of published data machine interpretable.

Adding semantic annotations to web applications permits machines to interpret and reason

on the available data, resulting in new web opportunities and new services to be offered

to the end users. Machine interpretable annotations is not a new idea, there are already

technologies available that permit to add semantic information to data collections. The

new thing is that this semantic annotations would be added to web applications and thus

could be used by all kind of machines from all over the world. Therefore it is necessary that

standard annotation formats are established. The most important semantic web annotation

languages are discussed below.

2.4.1 Resource Description Framework (RDF) - RDFa

RDFa12 is a standard from the W3C that is actually an extension of the existing RDF13

standard to support semantic annotations in web applications.

RDF

The RDF approach provide support for semantic annotations just like in a class model or

entity relation model. RDF specifies resources with subject - predicate - object expressions,

also know as RDF triples. The subject defines a certain resource, the predicate defines a re-

lationship between subject and object, and the object defines another resource. Resources

can be real values or can be objects defined by a Uniform Resource Identifier (URI). Also

blank nodes can be inserted that serves as a kind of virtual resource for more complex

semantics structures to be defined. This simple mechanism provides a very powerful tool

for semantic annotation.

RDF annotations are always based on public RDF ontologies, some very well known on-

tologies are the Dublin Core (DC14) ontology, the Friend Of A Friend (FOAF15) ontology

and the Semantically Interlinked Online Communities (SIOC16) ontology. It is a good

practice to use as much as possible the public standardized ontologies, but developers are

free to define their own ontology or reuse and rework existing ontologies. By having these

12http://www.w3.org/TR/xhtml-rdfa-primer/13http://www.w3.org/TR/rdf-primer/14http://purl.org/dc/elements/1.1/15http://xmlns.com/foaf/0.116http://rdfs.org/sioc/ns

http://www.w3.org/TR/xhtml-rdfa-primer/

http://www.w3.org/TR/rdf-primer/

http://purl.org/dc/elements/1.1/

http://xmlns.com/foaf/0.1

http://rdfs.org/sioc/ns

2.4 Semantics 29

ontologies publicly accessible, everything semantically annotated with RDF is interpretable

by machines.

Fig.2.17 illustrates an RDF example with URI resources, blank nodes and real value ob-

jects.

Figure 2.17: RDF example

The example represents a subject resource “http://www.mypage.com/Extending OOWS

for Semantic RIA.pdf” that has a DC “title” predicate identifying the “Extending the

OOWS method to support semantic Rich Internet Applications” value object. On the other

hand, the “http://www.mypage.com/Extending OOWS for Semantic RIA.pdf” resource

has an DC “creator” predicate identifying blank object, but that object on his hand is com-

posed out of a FOAF “name” predicate with the “Bert Weyne” value object, and composed

out of a FOAF “hompage” predicate with the “http://www/mypage.com/BertWeyne” ob-

ject resource.

RDFa

RDFa is an extension of ordinary RDF that enables to embed semantic metadata within

HTML code. RDFa has specified the following set of attributes that allows to define the

different subjects, predicates and objects in the visual data of a webpage. These attributes

can be added to (additional) <span>, <div> or other HTML tags within the code of the

webpage.

• about & src defines the subject resource

2.4 Semantics 30

• rel & rev defines a (reverse) relationship between resources

• href & resource specifies a partner resource

• property defines a property for the content of an resource

• content overrides the content of a resource when using the property attribute

• datatype specifies the datatype of object values when using the property attribute

• typeof specifies the RDF type(s) for a subject resource

Below the previous RDF triple example from fig.2.17 with an extra “created” predicate is

worked out in RDFa nested within HTML code.

<div xmlns:dc="http://purl.org/dc/elements/1.1/"

about="http://www.mypage.com/Extending_OOWS_for_Semantic_RIA.pdf">

<span property="dc:title">Extending the OOWS method to support semantic

Rich Internet Applications</span>

<span property="dc:creator">

<span property="dc:name">Bert Weyne</span>

<span property="dc:homepage">http://www.mypage.com/BertWeyne</span>

</span>

<span property="dc:created">15-06-2012/span>

</div>

In stead of just being published data on a website that only can be interpreted by humans,

the content of the webpage can now be interpreted by a machine and thereby provide new

services to the end user such as “find me the name of creator from the dissertation with the

title Extending the OOWS method to support semantic Rich Internet Applications. Just to

show how powerful semantic annotations are and the perspective they offer.

2.4.2 Microformats

The goal of Microformats is just like RDFa to provide an annotation mechanism for web-

page data. In stead of adding new attributes to the HTML tags, it uses the existing class,

rel and rev conventional HTML attributes. This implies that Microformats does not has

the expression capabilities that RDFa offers. Also does Microformats not use published

standardized ontologies as a vocabulary to define the different elements on a webpage. In

2.4 Semantics 31

stead each developer has to specify its own kind of vocabulary that can be made public.

More information about how to define semantic annotations in web applications is available

on the Microformats webpage17.

2.4.3 Microdata

Microdata18 could be seen as a kind of consensus between RDFa and Microformats. It

overall provides a simpler but thereby also less expressive semantic annotation mechanism

than RDFa. In Microdata, five three new HTML tags attributes have been introduced to

indicate semantic structure of a webpage.

• itemscope creates a new element.

• itemtype specifies by means an URI the type of an element.

• itemprop indicates another element that has a relation to the previous element.

The type of relationship is defined by a URI.

• itemid specifies the unique identifier or an element.

• itemref defines that the current element is related to a certain other element on the

page.

Just like with RDF, Microdata annotations are based on ontologies. In contrast to RDF

ontologies, Microdata ontologies are not structured in a standard way. For Microdata it

is enough to identify the ontology elements in a simple table an put a human understand-

able description next to it. This makes Microdata a lot simpler, but puts limits on the

machine interpretability because the machines first have to indicated by humans what the

different elements are and how they can and should treat them. Some example Micordata

vocabularies are available at the data-vocabulary19 website.

17http://microformats.org/about18http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html19http://data-vocabulary.org/

http://microformats.org/about

http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html

http://data-vocabulary.org/

STATE OF THE ART 32

Chapter 3

State of the Art

As mentioned earlier, model driven web development is not a new idea. However some of

the concepts introduced in this dissertation are. To situate the work carried out in this

dissertation between other proposals this chapter is going to give an overview of the closest

methodologies to the goal of this dissertation.

3.1 WebML

3.1.1 Method overview

The Web Modeling Language (WebML1) is one of the most mature and popular web

modeling techniques available as of today. The methodology is implemented into the

commercial product WebRatio2. Just like other methods it uses conceptual models to

capture the specifications of the web applications. The used models are:

• The Data model is in fact very similar to the UML like OO-Method Object Model

used in OOWS. It is a simple Entity - Relationship (ER) model that allows the

developers to specify the static data structure of the web application.

• The Hypertext model defines the composition of a webpage and the different

navigation possibilities the end users have to access other webpages.

• The Operation model specifies the execution of predefined CRUD operations that

can be carried out on the elements of the application.

1http://www.webml.org/2http://www.webratio.com

http://www.webml.org/

http://www.webratio.com

3.1 WebML 33

• The Presentation model is not really a model. WebML rather offers a set of

standard approaches that facilitate the work of graphic and communication experts

by offering the possibility to add XSL style sheets to site views, pages, units and

unit subelements. So predefined templates can be used and if necessary modified to

satisfy the presentation and communication requirements.

A general overview of WebML web application development process is illustrated in fig.3.1

Figure 3.1: WebML development process (image taken from [www.webml.org, ])

To what is important for this dissertation, the support for RIA and semantic web. There

have been proposals to extend the basic WebML and provide support for both RIA

[Bozzon et al., 2006a, Bozzon et al., 2006b, Comai and Carughi, 2007, Carughi et al., 2007,

Fraternali et al., 2008] and semantic web [Facca and Brambilla, 2007, Brambilla and Facca, 2007,

Ceri, 2007, Casteleyn et al., 2009].

3.1.2 Support for RIA

WebML was extended to support RIA functionality by letting the developers specify if data

composition or operations are to be carried out server-side or client-side. Also mechanisms

have been defined [Carughi et al., 2007] that allow to specify how and when certain client

side events may be thrown an how they may be caught and handled in other parts of the

web application (client side or server side). See fig. 3.2 for an illustrative example.

3.1 WebML 34

Figure 3.2: WebML event definition example (image taken from [Carughi et al., 2007])

[Fraternali et al., 2008] from its part defines different patters that easily could be applied on

Hypertext models that provide interactive operations at the client side of the application.

An example is the rating pattern that is illustrated in fig. 3.3.

The conceptual solutions for RIA available in WebML evolve during the code transforma-

tions phase in Flash and AJAX technology elements.

Also is there a cooperation between WebML and the RUX method (discussed later in 3.4)

[Preciado et al., 2007a, Preciado et al., 2007b] that can be applied on WebML to create

WEB 2.0 applications based on WebML models. The RUX model basically provides im-

proved Business Logic and Representation expressiveness on top of WebML. A general

overview of this approach is illustrated in fig. 3.4.

3.1 WebML 35

Figure 3.3: WebML rating pattern example (image taken from [Fraternali et al., 2008])

3.1.3 Support for Semantics

Also was WebML extended to provide support for semantic web, it basically permits de-

velopers to define semantic information into all (Data, Hypertext, Operation and Pre-

sentation) models. The defined semantic information is then used by additional M2C

transformations that creates external files with RDF descriptions of the generated web-

pages. The extended elements to the original development process are indicated in gray in

fig. 3.6 and are responsible for:

• Ontology Import addresses the selection and the importing of existing domain

ontologies for later user during development.

• Hypertext Design step was extended to specify how to query ontologies by means

of proper primitives. The new ontological query units that allow to specify semantic

information in the Hypertext model are illustrated in fig. 3.5.

• Design Annotation allows developers to specify how the hypertext pages will be

annotated using existing ontological knowledge.

3.2 OOH4RIA - SM4RIA 36

Figure 3.4: RUX on top of WebML (image taken from [Preciado et al., 2007b])

Figure 3.5: WebML ontological query units (image taken from [Ceri, 2007])

3.2 OOH4RIA - SM4RIA

The Object-Oriented Hypermedia (OOH3) method provides is just like OOWS and WebML

a modeling environment for web applications. Also because of the advancements on the

web, the method was extended to provide support for RIA (OOH4RIA4) [Melia et al., 2008,

Garrigos et al., 2009] and later for semantic [Hermida et al., 2010] web. Semantic Models

for RIA (SM4RIA5) is the latest version of the OOH method.

3.2.1 Support for RIA

The development of web applications using the OOH4RIA method is carried out following

five stages:

1. The first step is define the Domain model, it is just like in the OOWS OO-Method

Object Model to define the different entities, relationships and operations available

3http://gplsi.dlsi.ua.es/iwad/ooh project/oohmethod.htm4http://suma2.dlsi.ua.es/ooh4ria/5http://suma2.dlsi.ua.es/ooh4ria/sm4ria.html

http://gplsi.dlsi.ua.es/iwad/ooh_project/oohmethod.htm

http://suma2.dlsi.ua.es/ooh4ria/

http://suma2.dlsi.ua.es/ooh4ria/sm4ria.html


Figure 3.6: Extended WebML development process for Semantic Web (image taken from

[Brambilla and Facca, 2007])

on the entities.

2. Subsequently a Navigation Model is created that defines the navigation between

the domain concepts using OCL. Out of the model, the required presentation logic

can be extracted that provides the dynamic information for GUI components.

3. Next, the platform dependent Presentation Model is introduced (for now only sup-

port for the Google Widget Toolkit (GWT) platform). This model allows developers

to define a RIA schematic interface by defining the style and spatial representation of

RIA widgets. Fig.3.7 shows a part of the RIA metamodel used to make presentation

model instantiations. This metamodel is similar to the OOWS 2.0 RIA metamodel

but with the significant difference that OOWS 2.0 RIA metamodel (fig.2.14) is generic

for multiple RIA development technologies where the OOH4RIA RIA metamodel is

only dedicated to GWT.

4. Further, to support dynamic RIA behavior, the developer can define an Orchestra-

tion model by setting Event-Condition-Action (ECA) rules for each widget. The

developer first choses the GWT-specific events from the widgets. Next using Object

Constraint Language (OCL), the developer specifies the conditions the events must

comply. And finally the developers defines the actions that can be carried out on

GWT widgets or at server-side.


Figure 3.7: OOH - SM4RIA RIA metamodel (image taken from [Melia et al., 2008])

5. Finally, using the previous artifacts, the Xpand Model-to-Text Transformation

Rules can be executed to obtain the final application ready to be deployed on a

webserver.


Fig.3.8 shows the development process for semantic web development with the SM4RIA

method. The orange colored development steps, are elements that have been extended to

the OOH4RIA process described earlier in the five stages to provide semantic web develop-

ment. These new development steps have been enabled by extending the OOH4RIA MOF

metamodel with new metaclasses that relate OOH4RIA concepts to semantic sources, and

by defining new M2M transformations to automatically obtain new ontology models from

the functional RIA models. Next to specifying semantic information for the domain model,

the method also allows to define additional semantic concepts within the Presentation and

Orchestration model. All of this conceptual semantic information is then in the last M2C

transformation development step used to create separate RDF structured information that

semantically describes the generated application.

3.3 WSDM 39

Figure 3.8: SM4RIA development process (image taken from [Hermida et al., 2010])

3.3 WSDM

Web Semantic Design Method [Troyer et al., 2005, Troyer et al., 2008] (WSDM6) is an

audience driven development method for web applications. The WSDM method provides a

systematic web application development process based on modeling primitives to describe

web applications from different perspectives and on multiple levels of abstraction. The

development process illustrated in fig.3.9 shows five development stages with the artifacts

created during each stage.

1. The Mission Statement Specification stage allows developers to specify using

natural language the purpose, subject and end users of the desired web application,

thereby defining the borders of the design process. Further does it also allow to

define which information and functionality to include, how to structure and present

the information.

2. Now the Mission Statement is described, the next phase is to do the Audience

Modeling. Because WSDM is audience-driven, the first goal is to define the end

6http://wise.vub.ac.be/content/wsdm-web-semantic-design-method

http://wise.vub.ac.be/content/wsdm-web-semantic-design-method

3.3 WSDM 40

Figure 3.9: WSDM development process (image taken from [Troyer et al., 2008])

users. Different users have different requirements and needs, and therefore require

different support. The users described in the Mission Statement are refined into

audience classes in two sub phases: Audience Classification and Audience Charac-

terization. During these phases the user classes can be structured in an audience

hierarchy. Each class is assigned its own usability and navigations requirements as

well.

3. Next, the Conceptual Design phase turns the previous identified informal require-

ments into high level formal descriptions that later can be used to carry out M2T

transformations. Also this phase is subdivided in sub phases:

• The Task & Information Modeling sub phase that models in detail the tasks

the members of an audience class are able to carry out, together with formally

describing the functionality an data necessary for those tasks. Each task is mod-

eled into more details using a Concurrent Task Tree (CTT) technique, resulting

in elementary tasks. All the elementary tasks are then modeled by an OWL

object chunk that formally describes the information and functionality needed

3.3 WSDM 41

to carry out the task. OWL has the advantages that existing ontologies can be

(re)used and that it provides support for automatic semantic web application

generation.

• The Navigational Design sub phase specifies the conceptual structure of

the web applications together with the navigation paths the different audience

classes can follow through the system to perform their tasks. Each audience

class has its own navigation path that only contains the functionality required

by that specific user. The navigation model is build up out of conceptual nav-

igation entities and links that are connections between those entities. These

connections can structural, semantic, navigational-aid and process-logic links.

4. The following Implementation Design stage complements the Conceptual Design

with the necessary details for implementation. The phase allows developers to struc-

ture components from the navigational model into groups for webpages, to define the

look, feel and layout of the pages by using templates, and logical data design to be

established for the storage of the data that is going to be used in the application.

5. The final Implementation stage would allow to generate the web application imple-

mentation automatically using EXtensible Stylesheet Language (XSLT) M2T trans-

formations.


Because big part of the conceptual models defined by the WSDM method are already

defined in the OWL semantic description language, WSDM is a very suitable method to

generated semantic web applications. The semantic annotation generation process was

defined by [Plessers et al., 2005, Casteleyn et al., 2006, Casteleyn et al., 2009] and is illus-

trated in 3.10. As can be seen, all of the artifacts contain valuable semantic information

that is used through transformations to generate the semantic information.

• T1: Model Integration combines the different input models into one single model.

• T2: Implementation Mapping chosen the implementation platform (e.g., HTML,

XHTML, WML), the integrated model derived in T1 is transformed towards the

chosen platform.

• T3: Query Construction resolves and maps fully automatically the references to

instance values in the object chunks onto queries on the data source.

3.4 Rux method 42

• T4: Query Execution processes the queries derived in T3, and the actual pages are

generated by inserting the data at the proper places. When the query execution phase

is performed offline, a static website is created. If in the other case it is performed

at runtime, the result is a dynamic website.

• T5: Is an optional transformation that can be added to the pipeline to generate

structural annotations.

Figure 3.10: WSDM semantic annotation generation process (image taken from

[Casteleyn et al., 2006])

3.4 Rux method

The RUX7 method [Trigueros et al., 2007, Rossi et al., 2008] is a method that is totally fo-

cused on generating RIA interfaces. The method basically takes profit of the fact that at the

switch from WEB 1.0 to WEB 2.0, there were lots of WEB 1.0 modeling techniques avail-

able that did not provide support for WEB 2.0. RUX created a solution that, based on mod-

els from the older WEB 1.0 techniques such as WebML and UWE, allowed to specify WEB

2.0 behavior. See the WebML example earlier mentioned at 3.1.2 [Preciado et al., 2007a,

Preciado et al., 2007b]), or the UWE example [Preciado et al., 2008]. The RUX develop-

ment process is carried in three phases (illustrative example in fig. 3.11):

7http://www.ruxproject.org

http://www.ruxproject.org

3.4 Rux method 43

Figure 3.11: RUX development process with output example (image taken from

[Trigueros et al., 2007])

• The Abstract Interface phase defines an platform independent abstract user in-

terface (UI) model that thus is general for later RIA development technologies. The

model is constructed out of Connectors that define relationships between the data

model and the UI element that is going to represent certain data elements. Further

does it contain Media elements that are used to represent specific atomic informa-

tion elements such as text, image, video, etc. The last View element groups multiple

information elements that are showed together to the end users.

• The Concrete Interface phase is composed out of three models that allow to define

the concrete presentation information and the behavior of the UI.

– The Spatial Presentation model allows to define the place, size, etc. charac-

3.5 Other methods 44

teristics of the elements that compose the UI.

– The Temporal Presentation model defines the behavior of the UI independent

from the user interaction.

– The Interaction Presentation model defines the behavior of the UI during

interaction with the end user.

• The Final Interface phase transforms the previous models into the final UI depend-

ing on the selected technological platform.

3.5 Other methods

There are still many other methods that allow to at least define web applications, but most

of them have similar approaches to the ones discussed earlier. Beneath a quick overview is

given of some methods that have interesting characteristics.

3.5.1 UWE

The UML based Web Engineering (UWE) method [Koch et al., 2009], is mainly charac-

terized by the fact that it only uses UML standard compliant models to conceptually

define web applications. At the base, UWE is similar to previous methods as it also uses

models to specify conceptual concepts. One particularity for UWE is that for RIA speci-

fications it makes use of the very expressive UML State Diagram models. Some examples

worked out as State Diagrams in the [Koch et al., 2009] work are Periodic refresh and Auto

completion. About how these models are transformed into code, no information is included.

As mentioned earlier at 3.4, RUX extension have been defined on top of UWE to provide

enhanced support for RIA interfaces [Preciado et al., 2008].

3.5.2 SHDM

the Semantic Hypermedia Design Method (SHDM8) is just like OOH4RIA and SM4RIA an

extension on the early OOH method that was intentioned to provide semantic information

at generation time, but next to theoretic specifications there has been little activity on the

work since 2010.

8http://www.w3.org/2005/Incubator/model-based-ui/wiki/SHDM - Semantic Hypermedia Design Method

http://www.w3.org/2005/Incubator/model-based-ui/wiki/SHDM_-_Semantic_Hypermedia_Design_Method

3.6 Conclusions 45

3.5.3 HERA

The HERA [Gustavo Rossi, 2007] method, just like other methods provides support to

conceptual modeling of web applications. It has the particularity that its conceptual models

are based on semantic data build in RDF files and repositories, but it doesn’t generate no

semantic annotations, neither does it provides support for RIA applications.

3.6 Conclusions

This section gives an overview of the previously discussed methods according to their

support for RIA web applications and semantics web. In both the RIA compare table 3.2

and the semantic web compare table 3.3, we see that their is no method that provides full

support for RIA and semantics. The closest methods would be WebML 3.1 and SM4RIA

3.2, but their semantics part lack integrated semantic annotations. WSDM 3.3 on the other

hand provides integrated semantic annotations, but has no support for RIA environments.

3.6.1 RIA’s

To start of this comparison, a legend table 3.1 has been created to not overload the following

method comparison table 3.2. It contains the five elements that are of particular interest

when dealing RIA applications. The first three elements have basically been obtained

and refactored from the RIA characteristics defined at the RIA State of the Art paper

[Busch and Koch, 2009]. The two ultimate points were after having carried out a literature

study in the area of model driven web development, found to be two important points that

provide significant support at the modeling stage for the developer.

• Client/Server distribution allows developers at one hand to define where data is

going to reside during the execution of a web application. And at the other hand

where operations are going to be carried out. Often, in order to raise the performance

of a web application, data is held and operations are carried out at the client side

and later on in one moment or even asynchronously communicated to the server.

• Asynchronous communication allows web applications to keep responsive to user

requests while obtaining or transmitting information from or to the server. This way

the end user does not have to wait until the communication has completed before he

can carry out other tasks.

3.6 Conclusions 46

• Events are very important for RIA interaction. It is strongly desirable that web

application developers can specify which events are expected to be thrown and why

by a certain element of the web application. Just as they can specify which elements

are interested in a certain event been thrown, and what will be their behavior on

that particular event.

• Advanced Presentation allows developers to basically draw the final user interface

by specifying exactly where presentation elements will be located on a web page and

how exactly their look and feel will be.

• Patters are basically modeling concepts that allows the developers to rapidly design

web applications without having to specify the full behavior of those concepts. For

instance, the Rating pattern of the WebML method allows developers to quickly

define the rating functionality on a certain web application element without the need

to specify that an event is throw when the user clicks on the rating stars, that that

event is caught and handled by coloring the blank stars on the web page and by

sending the rate value to the server asynchronously.

Primitive Abbreviation

Client/Server distribution C/S

Asynchronous communication AC

Events E

Advanced presentation AP

Patterns P

Table 3.1: Legend

Next, the five elements from the legend are used int the WEB 2.0 support comparison

table 3.2 between the different methods. The table shows for each method the support

it provides when modeling a web application. Next it shows the support available in the

implementation once the models have gone through the M2C transformations. And at

the last column it shows the platforms that are used by a certain method to provide the

implementation support.

3.6 Conclusions 47

Method Modeling support Implementation support Supported platforms

WEBML E, C/S, AC, P E, C/S, AC, P Flash, AJAX

OOH4RIA E, C/S, P E, C/S, P GWT

WSDM None None None

RUX E, AC, AP Not specified Not specified

UWE E, P Not specified Not specified

SHDM None None None

HERA None None None

Table 3.2: Method overview for WEB 2.0 (see legend

table 3.1)

3.6.2 Semantics

The semantics table below, illustrates the different methods discussed earlier in this chapter

with their implementation support for semantic information, together with the implemen-

tation type that defines how semantic information is made available.

Method Implementation support Implementation type

WEBML RDF External description

SM4RIA RDF External description

WSDM RDF Integrated

RUX None None

UWE None None

SHDM Not specified Not specified

HERA RDF/Repositories External base models

Table 3.3: Method overview for Semantic Web

WEB 2.0 CASE STUDY 48

Chapter 4

WEB 2.0 case study

As mentioned earlier, the case study carried out during this master dissertation is based

on the http://www.23AndMe.com website. The 23AndMe website is a typical WEB 2.0

application as it offers a rich user interface and because it contains a social part that allows

users to interact with each other. As the 23AndMe website is quite extended, only some

of the interesting parts have been taken into account for this case study. This chapter will

basically follow the OOWS 2.0 method to demonstrate the case study application. Keep in

mind that the OOWS 2.0 method does not provide a graphic modeling environment besides

the Ecore EMF model specification, in order to keep the case study illustrative, some

models (Object model, Interaction map, Interaction Context (IC), Abstract Interaction

Units (AIU), Abstract Interaction Patterns(AIP)) have been artificially represented in the

Visual Paradigm1 graphical modeling environment. This graphical representations don’t

have OOWS 2.0 semantic information included for MDD generation. In order to produce

semantic containing OOWS 2.0 models for MDD generation, the EMF modeling framework

is to be used, where models are instantiated according to their corresponding metamodel

(see 2.1.2 for more information).

4.1 OO-Method Modeling

According to the OOWS 2.0 workflow illustrated in 2.6, OO-Method modeling is the first

step to be carried out. As mentioned before, the goal of the case study is not to capture the

whole 23AndMe website, but just some relevant elements. The OO-Method Object Model

specified for the 23AndMe case study is show in fig. 4.1. Because the OO-Method object

model is similar to the well known UML class diagram model, no further description of th

1http://www.visual-paradigm.com/

http://www.23AndMe

http://www.visual-paradigm.com/

4.2 Interaction Modeling 49

model is provided as UML is very intuitive.

Figure 4.1: 23AndMe case study OO-Method Object Model

Just to illustrate how in fact the models have to be introduced in EMF without graphical

representation, a screenshot of the Ecore tool with the modeled 23AndMe case study OO-

Method Object Model is illustrated in fig. 4.2.

4.2 Interaction Modeling

During the Interaction Modeling step, OOWS web modeling really starts. Once the Person

class from the previously defined Object Model has been identified as the Agent class, the

different system users for the 23AndMe Case study; Anonymous and Registerd are defined

and assigned the corresponding Anonymous and Registered OOWS 2.0 user type. For

each user a Interaction Map is defined with the different Interaction Contexts (IC) and the

corresponding access type (exploration or sequence) for each IC is specified. A graphical

representation of The Interaction Map model with the system users for the 23AndMe case

study is available in fig. 4.3. The Interaction Map of the the Anonymous system user

represents two always accessible IC’s by exploration; the General IC which has also been

defined as the homepage for this system user, and the Register IC that will enable new

users to subscribe. The Registered system user of its part has always access by exploration


Figure 4.2: EMF 23AndMe case study OO-Method Object Model

to three IC’s; the MyProfile IC which also has been defined as the homepage for this user,

the CompareGenes IC and the Forum IC. Out of the Forum IC, links have been defined

that allows the system user to access the other Discussion, TopicDiscussion and Person-

Profile IC’s by sequential navigation. Out of the TopicDiscussion IC, the system user has

sequential access to the Discussion and PersonProfile IC’s, and out of the TopicDiscussion

IC, the system user has again sequential access to the PersonProfile IC.

A brief description of what each IC provides is given below:

• As mentioned earlier, the General IC, is the home page of the application. It offers an

image slider with some propaganda images, and further does it offer a listing of some

of the newest scientific research findings that have been discovered by the enterprise,

and it does also provides a listing of the most popular discussion topics of forum part


Figure 4.3: 23AndMe case study Interaction Map

from the web application.

• The register IC offers Anonymous system users the possibility to subscribe to the

system and by doing so becomes Registered system users. Thereafter, they get access

to the content of the Registered system users.

• The MyProfile IC is the homepage for the Registered system users after login. On

this IC, they can view and modify their personal information (Person, Address and

Profile class attributes).

• The CompareGenes IC allows users to compare their genetic data with average values,

and find out their genetic tendency probability for the available traits (phenotypes).

• The Forum IC gives an overview of the different discussion topics available on the

web application. Further does it gives an overview of the newest discussions with

their corresponding creator and associated topic.

• If a user has selected a topic on the Forum IC, the system user is redirected through

sequential navigation to the TopicDiscussion IC where he has an overview over the

different discussions from the previously selected topic. Also In that IC, the system

user the possibility to start a new discussion within the current topic.

• When a user selects a discussion on the Forum IC or TopicDiscussion IC, the user

is redirected through sequential navigation to the Discussion IC where he can view


the discussion posts that have been published, and where he can create his own post

responding to the previously published posts of the discussion.

• On the Forum, the TopicDiscussion and the Discussion IC’s, the user has the pos-

sibility to navigate through sequential navigation to the PersonProfile IC where the

system user can view person details of a certain post publisher or discussion creator.

Now the Interaction Map has been defined, specifying the different IC’s it contains, the IC’s

themselves have to be modeled. In order not to fall in redundant conceptual information,

only one of the most interesting IC’s (as it incorporates multiple OOWS 2.0 concepts),

namely the Discussion IC which is represented in fig. 4.4 is discussed with further details.

Figure 4.4: EMF 23AndMe case study Discussion IC

The detailed view of the Discussion IC is illustrated in fig. 4.4. It is accessible for the

Registered system users by sequence navigation from the Forum or TopicDiscussion IC,

and consists internally out of two AIU, more specifically a Population AIU and a Service

AIU.


• The Discussion <AIU> Population AIU shows a view of the Discussion class which

has been identified as Manager class. This means that all other data in the Population

AIU is obtained following relationships defined in the OO-Method Object Model

out of that manager class to other complementary classes. As the Discussion IC

is accessed by sequence navigation, the desired Discussion object that will be the

manager for the Population AIU is identified by an object identifier passed through

the navigation link from the preceding IC. If in the other case, the IC would have been

accessed by exploration navigation, all the objects of the discussion class would have

been manager objects and all of them would be represented with their corresponding

data and complementary classes.

Particularly for this Discussion Population AIU, what is aimed to be represented,

is the discussion that has been identified through a identifier from the navigation

link with its posts and corresponding post creators. From the identified discussion

manager object, its discussionName attribute will be represented. Following the rela-

tionships out of the manager class towards the complementary classes, the topicName

attribute of the related Topic object would be show, the postComment and Postdate

attributes of the Post object identified through the StartPost relationship and the

the postComment and Postdate attributes of the Post objects identified through the

FollowPosts relationship. Also relationships towards further complementary classes

are defined that would obtain the username and picture of the users that created a

certain post in related to the manager discussion object.

Also has the Discussion Population AIU some Abstract Interaction Patterns defined.

The Order Criteria pattern that is applied on the complementary Post class specifies

that the posts of the discussion will be presented from oldest to newest (based on the

postDate attribute). The Pagination pattern specifies that there will be a maximum

of 20 posts presented at once and that the user can access the other posts by sequence

(usually by < > symbol links at the bottom of the page).

• The Discussion <Service AIU> Service AIU shows an operation the users can carry

out to create their own response post on the discussion that was object identified

through the navigation link. The Service AIU specifies the arguments that will be

passed to the Post.contructor service. As can be seen, the only modifiable argument

by the user is the postComment, the other arguments are set constant (unmanip-

ulatable) and have been set default values. On the Service AIU a Validation Rule

defined that will check whether the by the user introduced postComment value isn’t

empty before the operation is submitted.

4.3 RIA interface modeling 54

4.3 RIA interface modeling

Rich Internet Application interface modeling as it is defined in the OOWS 2.0 workflow

at 2.6, consists in fact out of two steps, RIA interface modeling that describes different

widgets and other presentation elements together their behavior on user actions, and RIA

weaving modeling which relates presentation elements from the RIA interface model with

conceptual elements from the Abstract Interaction model.

The first RIA modeling step is fairly well defined by OOWS 2.0 using the representa-

tion meta-metamodel to create a Adobe Flex environment metamodel that can be used

to define the RIA interface model. Although, for the 23AndMe case study the goal is to

provide interface modeling support for the latest development technologies such as HTML5

and JavaScript frameworks such as JQuery. As no metamodel for these presentation de-

velopment environments is available, it has to be designed first using the representation

meta-metamodel.

The second RIA weaving modeling step for RIA interface modeling described in the OOWS

2.0 work of [Girome, 2010] is absent in the current OOWS 2.0 EMF modeling environment.

It will be extended and created during this dissertation (more details at 6.2).

Because of the previous reasons, it is impossible to model the RIA part of the 23AndMe

case study with the current OOWS 2.0 support. Nevertheless it is interesting to go over

some of the RIA examples from the case study that are going to be possible with the

extensions to OOWS 2.0 that are going to be introduced during this dissertation.

The first RIA example would be a image slider on the 23AndMe case study home page that

contains some propaganda. Technically is it basically some JavaScript functions that are

applied on HTML5 images that allows users to go through the images with enhanced user

interaction possibilities. A screenshot of this element on the 23AndMe case study home

page is illustrated in fig. 4.5.

Another enhanced interaction RIA element that has been encountered in the 23AndMe

case study web application and that this dissertation will provide modeling and generation

support for, are tab interaction mechanisms build out of HTML5 and JQuery functions.

A screenshot such an element from the 23AndMe case study web page is illustrated in fig.

4.6.

A very interesting web page of the 23AndMe case study, is the CompareGenes page. A

4.3 RIA interface modeling 55

Figure 4.5: 23AndMe case study image slider (screenshot taken from www.23andme.com)

Figure 4.6: 23AndMe case study tabular (screenshot taken from www.23andme.com)

screenshot with the important elements of this page is illustrated in fig. 4.7. At the right

side the figure shows a list with different “trait” values. Each of these traits has some kind

of accordion representation element applied on it that allows the system users to obtain

more detailed information about a certain trait when opening the accordion. On the left

side of the figure another list is showed that contains different “similarity” values for traits.

What is done is that each time a “trait” from the right list is selected, automatically a new

element is added in the left list showing the “similarity” value between different system

users for the trait that just has been selected. When trying to analyze the actions that occur

when a user selects a trait from right list, next to the accordion functionality applied on the

“trait” values, also some kind of events are thrown from the right list “trait” values which

on their turn are received by the left “similarity” value containing list, eventually resulting

in the presentation of new “similarity” values into the list. Al of this RIA functionality

could be modeled and generated by HTML5 and JQuery, but it is quite more complicated

as net to presentation, certain user events from one element will have to be generated and

send, and on their turn received and handled by other presentation elements. It is clear

that in the OOWS 2.0 way of modeling, both lists would be two independent Population

AIU’s, each with a different manager class (Trait and TraiType from the Object model in

4.4 Semantics 56

fig. 4.1). Events in the current OOWS 2.0 metamodel are not fully supported, thus it will

have to be added to the method (see how at 6.1.2 and 6.3).

Figure 4.7: 23AndMe case study compare genes (screenshot taken from www.23andme.com)

4.4 Semantics

For semantics, OOWS 2.0 does not provide any modeling nor generation support. This

support will be added to the method during this dissertation in chapter 7. Also does the

23AndMe case study web application not incorporate semantic information in its current

web application. Nevertheless some interesting ideas can be given of what could be possible

modeled and generated with the semantically extended OOWS 2.0 method. To start of,

as described at 2.4, there are multiple technologies (RDFa, Microdata, Microformats and

maybe others) available to create semantic applications. The goal is to show that the

extended OOWS 2.0 method will be able to provide modeling and generation support for

all of them and that they even could be used in parallel on the same web application. As

a good part of the 23AndMe case study web application consists out of a forum, some

of popular existent social network ontologies for RDFa such as FOAF, SIOC and DC

could provide annotations for the 23AndMe case study web application. For Microdata

annotation, the well known data-vocabulary ontology provides person related concepts that

could be used in the 23AndMe case study.

4.5 Results 57

4.5 Results

This section will give a small overview of what support the original OOWS 2.0 method offers

and what is missing. In the following chapters, this dissertation will work out solutions in

order to fill up the gap.

4.5.1 OOWS 2.0 available support

• OO-Method modeling allowed to specify the conceptual data elements that will

form the information base for the web application. No shortcomings have been

encountered in this part of the method.

• Interaction modeling allowed to specify the global structure of the web application,

including system users, their Interaction map with the Interaction Contexts and the

access types to the Contexts. The content of each Context be defined with Population

AIU’s, Service AIU’s and Abstract Interaction Patterns (AIP). On their turn the AIU

and AIP Interaction Context building blocks provide the required functionality to

model the majority of the functionality/information available in the end application.

• Presentation modeling would in fact provide support to model the presentation

of the end application for the Adobe Flex implementation platform, but not for the

targeted HTML5 and jQuery-JavaScript technologies of the case study.

4.5.2 Missing support

• HTML5 and jQuery-JavaScript implementation technologies are not supported.

• Multiple implementation platforms support is not available in the current OOWS

2.0 mehtod, it is totally focused on Adobe Flex.

• Events are supported, but the expressivity of the current models does not allow to

use data information out of the Interaction model to specify the event handling.

• Semantic annotation support is totally absent.

• Code generation support is totally absent.

THE SOLUTION IN A NUTSHELL 58

Chapter 5

The solution in a nutshell

This chapter will give an overview of the extended OOWS 2.0 method solution for RIA and

semantic Web development presented in this dissertation. Detailed descriptions about the

extensions will be given in the following chapters 6, 7 and 8. As this dissertation extends

the existing OOWS 2.0 method, there remain many similarities to the original method

which are very well defined in the work of [Girome, 2010] and [Pastor et al., 2008] handled

earlier at 2.2 and will therefore not be rediscussed detailedly, trying to focus this chap-

ter on the extensions. To keep this overview easy to follow, a workflow has been created

illustrated in fig. 5.1, it is divided in several mayor blocks each of which has a different

background color. These blocks represent the different modeling phases that are carried

out during the extended OOWS 2.0 method for developing web applications. For each

block a different section is available in this chapter that describes how and what has been

extended from the original OOWS 2.0 method.

In fig. 5.1 the internal modeling steps within the modeling phases are illustrated with their

corresponding output artifacts and an example illustration of these at the right. Some of

the modeling steps and output artifacts in fig. 5.1 are indicated with a red surrounding.

This is not indicated in the legend of the illustration, but these red surroundings has been

added to clearly indicate the new modeling elements that have been added during this

dissertation with respect to the original work of the OOWS 2.0 method.

THE SOLUTION IN A NUTSHELL 59

Figure 5.1: Proposed extended OOWS 2.0 solution

5.1 Requirements modeling 60

5.1 Requirements modeling

Goals of the modeling phase

The Requirements stage is essential for every software development project. For the ex-

tended OOWS 2.0 method this is not different and therefore it is the starting point for

model driven web application development. This Requirements modeling phase typically

offers a high level abstract view of the desired end product. It basically allows developers to

specify the different goals and objectives of the end product together with some restrictions

and specifications about how these goals and objectives should be reached.

Support provided by OOWS 2.0

OOWS 2.0 does currently not provide any modeling support for this phase.

Proposed solution

The objectives of this dissertation do not address this part of the method. There are many

tools and methods available to model requirements, some typical output artifacts are Use

Case models and Task models (see examples in fig. 5.1).

5.2 Conceptual modeling

This modeling phase has been subdivided in two independent modeling steps; Object

modeling and Interaction modeling. Each of them have been adopted from the original

OOWS 2.0 method and are briefly discussed below.

5.2.1 Object modeling

Goals of the modeling step

As mentioned earlier in this dissertation, the Object model is similar to the UML class

model. It allows the developer to specify the different information entities (classes) that

are going to be available in the end product. It is essential that Requirements modeling has

been carried out before Object modeling as it predefines, to a large extent, the conceptual

elements required for the end product.

5.2 Conceptual modeling 61


Just like in UML models, OOWS 2.0 provides with the Object model developers the pos-

sibility to defines entities (classes), assign attributes to these entities, define relationships

between entities and define services on entities.

Proposed solution

The Object model has been integrally taken over from the the OOWS 2.0 method. Some

changes were added to the metamodel by making all the Object metamodel elements

inherit from a top parent ObjectNamedElement class that on its turn inherits from the

OOWSNamedElement, but these changes do not change anything in the expressivity and

functioning of the model. The changes have been added to allow subsequent weaving

mechanisms mentioned later in this chapter.

5.2.2 Interaction modeling


Once the Object modeling step is finished, developers can based on the Object model

start with the Interaction modeling step. The interaction model defines conceptually what

functionality and information will be available in the web application and how this one

will be structured.


OOWS 2.0 provides there are three output artifacts, all of them are interconnected and

form together the global interaction model. Each of them is briefly discussed below:

• Interaction map is the top level and consists out of Users and Interaction Contexts

(IC). The Users can be seen as agents, these agents must be related to an entity

from the beforehand defined Object model (typically they are related to some kind

of Person class). These Users have to be assigned a name together with a user type

(Anonymous or Registered).

Once the Users have been defined, the developer starts defining the IC’s for the

different Users. The developer can assign access by Exploration or access by Sequence

to the IC’s.

5.2 Conceptual modeling 62

• Interaction contexts themselves are what actually are going to become the web-

pages of the web application. IC’s are used as some kind of containers that contain

one or multiple Abstract Interaction Units (AIU). These units will provide the web

application users with data information and/or data operations.

• Abstract interaction element can be subdivided into the more specific:

– Population AIU can be seen as data providing containers in a web application.

With Population AIU’s developers are allowed to define which information from

the Object model is visible to the web application in that particular IC. They

have two important concepts; Manager class and Complementary classes. The

one and only Manager class of a Population AIU fixes the starting point in the

Object model for data information retrieval (usually class attribute values) for

representation to the end users. Out of the manager class, following the defined

relationships in the Object model, Complementary classes can be identified.

– Service AIU allows developers to define operations that users can carry out

within a certain IC. These operations are always linked to an service that has

been defined in the Object model. The developer can define which of the service

input arguments are going to manipulatable, visible or set by default values.

Also is the developer allowed to define output arguments, error messages and

operation finish navigation depending on the output of the navigation.

– Abstract Interaction Patterns (AIP) provide enhanced data information

retrieval and data operation mechanisms that can be applied on top of both

previous Population and Service AIU’s the developer can define various AIP

patterns with enhanced functionality which have been detailedly described ear-

lier in this dissertation at 2.2.3.

Proposed solution

Interaction modeling as it defined in OOWS 2.0 has integrally been taken over. Although

some adoptions have been added to provide support for data handling on user events, and

to provide support for presentation and semantics weaving on the Interaction model ele-

ments. These changes did not change anything to the original expressivity and functioning

of the modeling step.

Because OOWS 2.0 only incorporates event support in its Presentation model, only general

event handling between Presentation model elements can be specified. Events often not

5.3 Presentation modeling 63

only relate to the presentation element that generates of receives these events, but also to

the data thats available within the presentation elements. Therefore event specification

support has been added to the elements of the Interaction model, that will allow to let

events be generated or have effect on well defined parts of the data represented by a pre-

sentation element. More details in the following chapter at 6.3.

In order to provide presentation and semantics weaving mechanisms later on, the Interac-

tion metamodel elements were made to inherit from a top parent AimNamedElement class

that on its turn inherits from the OOWSNamedElement,

5.3 Presentation modeling


Presentation modeling allows the developer to specify enhanced presentation possibilities.

This means that developers already can generate their Web application with their own

customized presentation.


Presentation modeling is present in the OOWS 2.0 method, but no metamodel available is

yet that allows to model the in this dissertation targeted HTML5, jQuery - JavaScript pre-

sentation technologies. Nevertheless, this metamodel can be instantiated using the OOWS

2.0 Presentation metametamodel.

In order to apply presentation on the web application, the OOWS 2.0 method proposes to

interrelate Abstract Interaction model elements with the instances of the Representation

model. OOWS 2.0 does not require that every Interaction model element is interrelated

with at Presentation model element, for these Interaction model elements it proposes hard

coded relations that bind them to a specific presentation.

Proposed solution

The OOWS 2.0 interrelation proposal between Interaction model elements and Presentation

model elements is a good idea, but this dissertation goes a step further because some

difficulties were encountered with the simple solution. First of all, the original OOWS 2.0

idea requires that many redundant links would have to be laid between Interaction and

5.3 Presentation modeling 64

Presentation model elements. For instance, a input argument from a Service AIU has to

be linked on a simple HTML5 input field from the Representation model. Secondly, what

happens with Interaction model elements that have not been assigned a Representation

model element? OOWS 2.0 proposes that Interaction model elements that do not have a

Representation element assigned, get a default representation during the M2C generation

phase. This isn’t the best practice when OOWS 2.0 claims to provide representation

modeling solutions for multiple representation implementation technologies. So if the M2C

transformations for Service AIU input arguments with no representation element associated

are hard coded to result in HTML5 input fields what if some developer wants to develop

for Adobe Flex? In this case with the current OOWS 2.0 proposal, the developer will have

to lay links will for every Interaction model element to its corresponding Adobe Flex input

presentation element.

This dissertation proposes to create a Default Presentation Weaving model that lays links

between elements from the Interaction model metamodel and the Presentation model.

This allows developers to define a default link between a Interaction metamodel concept

such as may be a Service AIU input argument and a Presentation model element which

may be a Adobe Flex, HTML5, etc. input field. It is recommended that the Presentation

model element that is selected for the default link is the element that would occur the

most for the particularly linked Interaction metamodel element, thereby avoiding as much

as possible redundant work. For the Service AIU input argument (taking HTML5 as the

target presentation technology) typically the best default link would be laid with a simple

HTML5 text input field. A detailed description about how this is achieved is explained in

the following chapter at 6.2.

On top of the previous Default Presentation Weaving model, this dissertation provides

the developers the possibility to define a Overriding Presentation Weaving model. As the

name of the model indicates, this model overrides the Default Presentation Weaving model.

The overriding model allows developers to link particular Interaction model elements (in

contrast to Interaction metamodel elements) with Presentation model instances. As an

illustrative example, suppose a developer defined in the Default Presentation Weaving

model that Service AIU input argument elements are by default mapped onto HTML5

text input fields. Now for one particular Service AIU input argument, no HTML5 text

input field is required, but a HTML5 textarea input field. The only action the developer

has to carry out is to define a overriding presentation link between that particular Service

AIU input argument and a HTML5 textarea input field element from the Presentation

model. All the other Service AIU input argument elements will remain untouched and are

5.4 Semantic modeling 65

still going to be mapped onto HTML5 text input fields.

5.4 Semantic modeling


Semantic modeling allows to import semantic information in the models to obtain semantic

web end applications. Doing so, creating semantic web applications that not only can be

interpreted by human beings, but that machines can also interpret and reason on. Usually

semantic annotations are used to annotate data elements present in web applications. In

this solution semantic annotations can not only be applied on data elements, but also on

presentation elements, this in the perspective of possible applications for disabled users.


No support for semantic web is available in the OOWS 2.0 metod.

Proposed solution

Semantic modeling is a whole new phase that has been introduced to the OOWS 2.0

method and consists out of two independent modeling steps:

• Ontology modeling allows developers to model their ontologies. The extended

OOW 2.0 method provides modeling support for RDFa, Microdata and Microformat

semantic annotation technologies. This has been achieved creating a new metamodel

that allows to host semantic information for each of the three semantic implemen-

tation RDFa, Microdata and Microformat technologies. In order to allow weaving

between semantic model elements and other elements, the semantic metamodel ele-

ments inherit form a top SemanticsNamedElement parent class.

• Semantics weaving is based on the same idea as the earlier discussed Presentation

weaving and allows developers to establish links between Ontology model elements

with Conceptual model elements and Ontology model elements with Presentation

model elements. The extended OOWS 2.0 method thus allows to semantically an-

notate Conceptual model elements such as classes, attributes, etc. and it also allows

to semantically annotate Presentation model elements such as input fields, JQuery

tabs, etc (which can be very useful for disabled user web browsers, etc.).

Just as with Presentation weaving, there is a Default Semantic Weaving model that

5.5 Model to Code (M2C) generation 66

allows to link Semantic model elements with Conceptual or Presentation metamodel

elements. For instance each object from the Object model can be by default linked

to OWL:Thing.

Where with Presentation weaving only one Presentation model element could be

linked to a Conceptual (meta)model element, Semantics weaving allows multiple

Semantic model elements to be simultaneously linked to Conceptual and Presen-

tation (meta)model elements (this besides the fact that also the three annotation

technologies (RDFa, Microdata, Microformat) currently supported also can applied

simultaneously on Conceptual and Presentation (meta)model elements).

On top of the Default Semantic Weaving model also a Overriding Semantic Weaving

model can be applied. In contrast to Presentation weaving, Semantic weaving does

not necessarily overrides the default weaving. In stead the developer is offered the

possibility whether he wants to override the Default Semantic Weaving (which may

be multiple elements) for a particular Conceptual - Presentation model element, or

even to define specifically which of the Default Semantic Weaving elements have to

be overridden (By not specifying any Overriding Semantic elements it would just re-

move the specified Default Semantic elements). For instance for a Person class from

the Object model, next to the Default Semantic Weaving that applies OWL:Thing

on each class, the developer can use Overriding Semantic Weaving that also links,

or only links FOAF:Person to that particular class.

5.5 Model to Code (M2C) generation

Goals of the M2C generation phase

The Model to Code generation phase allows developers once they have formally modeled

their desired web application with the method, to obtain automatically generated code

according to the models. One of the biggest advantages of automated code generation

is that developers can not create buggy code due to human carelessness during manual

implementation, if the M2C transformations have been well defined the only problems

that may arise are conceptual mistakes the developer introduced during the modeling step.


The OOWS 2.0 method did not provide any transformation to obtain code out of the

models.

5.6 ToDo after generation 67

Proposed solution

The M2C generation illustrated inf fig. 5.1 can be carried out on two occasions in the

workflow, depending on how much is modeled, the M2C transformation will generate the

web application accordingly. The M2C transformation mas been implemented using the

Xpand - Xtext languages from the Eclipse Model to Text (M2T, see 2.1.3) project. Later

in this dissertation at 8 a whole chapter has been dedicated to this process. The output

technologies targeted by the proof of concept implementation of the M2C generation are

the J2EE framework, including the Hibernate framework for the persistence layer, Java for

the business layer and JSP, HTML5, jQuery - Javascript, RDFa, Microdata, Microformat

for the presentation - semantics layer.

5.6 ToDo after generation

Once the generation has finished, using the hibernate framework the persistence layer

database can be generated automatically out of the generated Entity classes. In the busi-

ness layer, the skeleton ToCreateServiceBean.java EJB has to be completed with the func-

tionality the developers want to assign to the services they defined in the Object model,

because many times a high expressivity modeling environment would be required to spec-

ify the sometimes complex functionality of these services. This modeling environment is

currently not available in OOWS 2.0 and fell out of the scope of this dissertation. For

the presentation layer, the application server has to be configured (JDBC connections and

security realms) and the application can be deployed and run.

EXTENDING OOWS 2.0 PRESENTATION MODELING 68

Chapter 6

Extending OOWS 2.0 presentation

modeling

This chapter as its name indicates is going to extend the original OOWS 2.0 Presentation

Modeling discussed earlier at 2.2.3 and 2.2.3. To quickly recapitulate:

• OOWS 2.0 proposes a top layer and technology independent Presentation metametaModel

that is used to define the underlaying technology dependent Presentation metamodel.

The thesis of [Girome, 2010] gives an example (illustrated in this dissertation at 2.14)

of how this is done for the Adobe Flex technology. Using this Flex metamodel, the

Presentation model can be defined.

• Once the Presentation Model has been defined, OOWS 2.0 proposes a Weaving model

to bind Abstract Interaction model elements with Presentation model elements. The

proposed Weaving model would just lay one to one relations between those elements

(an illustration is available at 2.15).

During this chapter the following goals will be addressed for extending the original OOWS

2.0 method:

• Support for multiple presentation implementation platforms to be used in the method.

• New presentation modeling support specifically for the currently actively used HTML5

jQuery-JavaScript technologies.

• Enhanced Weaving support to bind Presentation model elements to Abstract Inter-

action model elements.

6.1 New presentation metamodel 69

• Support for enhanced event handling, allowing Abstract Interaction model element

information to be used for event handling.

In order to reduce complexity and overhead, the metamodel illustrations included in this

chapter are in fact simplified graphical presentations of the real extended Ecore EMF

metamodels used for OOWS 2.0 modeling and M2C generation.

6.1 New presentation metamodel

The first extension introduced in this chapter considering Presentation Modeling, is by

making the OOWS 2.0 method provide modeling support for new presentation develop-

ment technologies such as HTML5 and jQuery. To do so, a HTML5 and jQuery Metamodel

have to be defined. Just like OOWS 2.0 proposes, the HTML5 - jQuery metamodel has

been defined using the Presentation metametamodel. As the goal of this dissertation

is to provide a proof of concept extended OOWS 2.0 implementation. The Presentation

metamodel defined in this dissertation has primarily been build with the goal to provide

modeling support for the 23AndMe case study web application 4. Therefore only the rele-

vant HTML5 and jQuery concepts for the 23AndMe case study web application have been

modeled, nevertheless this can be extended easily.

In fact, the HTML5 - jQuery metamodel is one big Presentation metamodel, but because

it was impossible to make a graphical illustration of it that would fit on A4 and include in

this dissertation, it has been separated in 2 parts. One containing the HTML5 metamodel

and another with the jQuery metamodel. In the two sub sections below each of them is

discussed in more detail.

6.1.1 HTML5 metamodel

A graphical representation of the HTML5 presentation metamodel defined in this disser-

tation is illustrated at fig. 6.1. As can be seen, there have been different fields identified

in the figure. The top part of the figure that has no surrounding and is indicated with

Presentation Metametamodel, is the exact Presentation metametamodel taken over from

the original OOWS 2.0 specification. Below it, two parts can be identified; one with the

green dashed line surrounding, and one with the red dashed line surrounding.

The red dashed surrounded part is in fact the HTML5 metamodel that has been defined


in this dissertation. It contains all the HTML5 metamodel elements that were required

to define the Presentation model for the 23AndMe case study web application. As can be

seen, all the HTML5 metamodel elements in the red dashed part inherit from the original

Presentation metametamodel. This means that for the 23AndMe case study, the original

OOWS 2.0 Presentation metametamodel defined by [Girome, 2010] is expressive enough

as it was not necessary to add new metametamodel elements.

The green dashed part in the figure has been added for two purposes;

• First, to define the HTML5 - jQuery metamodel top layer structure. It specifies

that all the HTML5 elements can have many internal HTML5 elements. This is for

example the case with a HTML5 table that usually has internally many HTML5

rows that on there turn can have many HTML5 columns. Also does it specify that

a jQuery element can be applied on a group of HTML5 elements and that a HTML5

element can have many jQuery elements applied on it. For example, this can be the

case with jQuery tabs applied on multiple HTML5 divisions.

• Second, to facilitate the Presentation weaving explained further in this chapter.

The CommonHTML5-JqueryElement is the parent class for all further Presentation

metamodel elements (HTML5 and jQuery). This will make it possible to lay weaving

references to every Presentation metamodel element in subsequent weaving model

steps.


Figure 6.1: HTML5 Metamodel


6.1.2 jQuery metamodel

A graphical representation of the jQuery presentation metamodel is illustrated in fig. 6.2.

Just like with the HTML5 presentation metamodel, it has been subdivided in three parts.

The original OOWS 2.0 Presentation metametamodel remained also untouched to define

the jQuery metamodel. The green dashed surrounded part is again present in the meta-

model level of the figure, but now as of defining the metamodel for jQuery, all the presen-

tation metamodel elements inherit from the CommonJqueryElement parent class that on

its turn inherits from the CommonHTML5-JqueryElement parent class. The red dashed

surrounded part presents the jQuery metamodel defined for the presentation elements re-

quired in the 23AndMe case study web application.

Most of the Jquery Presentation metamodel elements are trivial, but the JqueryThrow-

EventElement and JqueryReceiveEventElement may need some more detail. As their name

indicates, these elements have been defined to allow event handling by the jQuery frame-

work. The JqueryThrowEventElement presentation element will allow to throw events on

certain user actions. For the 23AndMe case study the click, hover and change user actions

have been predefined as possibilities to throw events (this can easily be extended with more

actions). The JqueryReceiveEventElement presentation element will on its turn allow to

receive events. For the 23AndMe case study the hide, show and append presentation ac-

tions on event receive have been predefined (also this can easily be extended). Both these

event handling presentation elements will usually be linked (using the weaving model) to

a certain Abstract Interaction model element and a EventSpecification element from the

Abstract Interaction model that specifies the underlaying data handling when a event is

thrown or received (more details at 6.3). Using these jQuery event specification elements,

the compare genes jQuery functionality (discussed earlier and illustrated in fig. 4.7) of the

23AndMe case study web application was able to be modeled and subsequently generated.


Figure 6.2: jQuery Metamodel

6.2 Extending presentation weaving 74

6.2 Extending presentation weaving

The other extension introduced in this chapter is due to the lacks (discussed earlier at

5.3) encountered in the original OOWS 2.0 weaving proposal. This dissertation extends

the original weaving proposal and addresses the lacks proposing new Default and Overrid-

ing Weaving mechanisms described in more detail in the sub sections below. A graphical

representation of the metamodel that provides this new presentation weaving support is

illustrated in fig. 6.3.

The top level of the figure is the RIAWeaving element that will hold all the weaving ref-

erences between Abstract Interaction model elements and Presentation model elements.

This RIAWeaving element has defaultPresWeaving and overridingPresWeaving references

to the corresponding Default presentation weaving model (metamodel surrounded with the

blue dashed line) and the Overriding presentation weaving model (metamodel surrounded

with the purple dashed line).

The purpose of the Default presentation weaving model is to define default presentation

specifications. For instance, to specify that every service input argument is automatically

represented as a HTML5 text input field. If for some particular service input arguments

another representation is required, then the Overriding presentation weaving model that

overrides the Default presentation weaving model can be used to specify this other repre-

sentation (thereby discarding the default presentation for service input argument element).

One of the main advantages that incorporates the default - overriding presentation weaving

mechanism, is that a one time defined, the default presentation weaving model can be

reused for any web application development project without having to apply any changes.

This also allows rapid prototyping, defining a Object and Abstract Interaction model

without having to define a specific presentation weaving. Then, on top of the default

presentation weaving, overriding presentation weaving can be applied to further customize

the presentation.

6.2.1 Default presentation weaving

The DefaultRepresentationWeaving element in the blue dashed part of fig. 6.3 is the el-

ement that will hold the Default presentation weaving model through containing many

DefaultWeavingElement instances. It are these DefaultWeavingElement instances that


will lay links between Abstract Interaction (meta)model elements and Presentation model

elements.

Out of a DefaultWeavingElement a link can be laid to any Presentation model instance

using the hTML5-JqueryElement reference, as all of the Presentation metamodel ele-

ments inherit from the CommonHTML5-JqueryElement class (see fig. 6.1 and 6.2). The

hTML5-JqueryElement reference is indicated as contained (see diamond symbol at begin

of the reference) which means that every reference instantiates a new CommonHTML5-

JqueryElement and thereby the Presentation model is actually instantiated while carrying

out presentation weaving.

The other reference out the DefaultWeavingElement class is the aimElement reference to-

wards the AimNamedElement class. This AimNamedElement class is (applying the same

principle as the CommonHTML5-JqueryElement class) the parent class for all Abstract

Interaction metamodel elements. Doing so, presentation weaving links can be laid to every

element from the Abstract Interaction model. Because this is the Default presentation

model, aimElement links should in fact be laid to Abstract Interaction metamodel ele-

ments. As it is impossible to reference metamodel elements with EMF when modeling

based on that earlier defined metamodel (this is very reasonable to not mess up things),

in stead special instances of Abstract Interaction metamodel elements are used to lay the

links. The red with index 1 indicated dashed circle on fig. 6.3 around the diamond symbol

at the start of the aimElement reference, indicates that the reference is containing and

thus new (special) AimNamedElement instances will be created when laying the reference.

During presentation weaving, these new special instances of Abstract Interaction meta-

model elements will in there name be identified as default in their name to avoid confusion

between the normal Abstract Interaction metamodel instances (the real Abstract Interac-

tion model) of the modeled web application, and special Abstract Interaction metamodel

instances used for default presentation weaving.

6.2.2 Overriding presentation weaving

The OverridingRepresentationWeaving element in the purple dashed part of fig. 6.3 is

(similar to default weaving) the element that will hold the Overriding presentation weav-

ing model. It consists out of many OverridingWeavingElement elements that link Abstract

Interaction metamodel instances with Presentation metamodel instances using the aimEle-

ment and hTML5-jQueryElement references.


The red with index 2 indicated dashed circle on fig. 6.3 illustrates that in contrast to

the Default weaving, the aimElement references are laid to existing AimNamedElement

instances and does not allow to create new instances. Doing so, each Abstract Interaction

model element out the conceptual modeled application can be referenced (also the Abstract

Interaction metamodel instances of Default weaving, so caution is required) and linked to

new instance in the Presentation model.

Figure 6.3: Presentation weaving Metamodel

6.3 Adding support for events at conceptual level 77

6.3 Adding support for events at conceptual level

Events have already been mentioned earlier in this chapter when discussing the jQuery

presentation metamodel at 6.1.2. This because events are at usually generated by user

actions on the user interface, and on because they often result in a visible effect on the

user interface. Especially in the 23AndMe case study this behavior was encountered at

the Compare Genes functionality (discussed earlier and illustrated in fig. 4.7). To detect

and represent certain user produced events, the JqueryThrowEventElement and JqueryRe-

ceiveEventElement were defined in the jQuery metamodel.

As said, events are usually generated and produce effects at the presentation layer, but

events often also carry within them data from the conceptual model. For instance in the

Compare Genes functionality, events are detected by a click on a trait instance from the

righter table of fig. 4.7) and result in a extra row with the corresponding trait value in the

lefter table. In order to do this correctly, certain information out of the conceptual model

has to be available for the event handling functionality, as presentation model elements do

not have knowledge about this information. Combining conceptual information to event

handling it is be possible to carry out more complex event functionality. Specifically for

the Compare Genes, it will that the corresponding Trait value instance is added to the

lefter table after having clicked on a certain TraitType instance in the righter table.

In order to support this behavior, next to event specification Presentation metamodel el-

ements, the conceptual model has been altered with event support. Fig. 6.4 illustrates

how using the AimNamedElement which is the parent class for all the elements from the

Abstract Interaction metamodel, the Abstract Interaction metamodel elements can be as-

signed EventSpecification’s through the eventsOnthisElement reference. As the EventSpec-

ification also inherits from the AimNamedElement, it could even be applied on itself, but

in the subsequent M2C generation this case has not been treated for now.

The AimNamedElement contains four attributes and one reference:

• description is an optional value for clarity reasons that allows the developers to give

their own description about why they defined the EventSpecification.

• eventGroup is a EString value that will allow to group multiple EventSpecifica-

tion’s. This eventGroup value will be used in the subsequent M2C generation to

associate events in a event channel. For a throwing EventSpecification, its assigned

6.3 Adding support for events at conceptual level 78

eventGroup value will be passed to the event channel that on its turn will notify

the receiving EventSpecification’s with this same eventGroup value. Note that it

is possible that multiple throwing and receiving EventSpecification’s have the same

eventGroup value. They will act accordingly.

• dataString s an optional value for clarity reasons that allows developers to specify

information about the OowsNamedElement elements they have referenced through

the oowsDataElements reference.

• oowsDataElements is a reference to OowsNamedElement data containing elements

form the Object model the developer can associate to the EventSpecification. This

reference is meant to associate only the Object model data elements that are also

available in the Abstract Interaction model element on which the current EventSpec-

ification is applied. For this proof of concept OOWS 2.0 implementation and for the

23AndMe case study, the first associated Object model has in the subsequent M2C

generation been used as the identification data element for event throwing-receiving

functionality on the Abstract Interaction model element. The possible following con-

ceptual model data elements that can be assigned, are meant to be used as parameters

by the receiving functionality. For instance, for the Compare Genes event functional-

ity, at the event throw specification the traitTypeId attribute of the TraitType Class

was indicated to be the the first data element to be passed and thereby to identify

the functionality at receiver side. At the receiver side, using the passed traitTypeId

value, the associated Trait class instance within the receiving Abstract Interaction

model element can be identified and the according jQuery event receipt action (show,

hide and change for now) could be undertaken on this Abstract Interaction model

element.

• eventType allows the developers to specify whether this EventSpecification will be

used to throw or receive events.

6.4 Overview available RIA functionality 79

Figure 6.4: Adding support for Events

6.4 Overview available RIA functionality

To end this chapter, this section will provide an overview of the RIA functionality that

is now available in the extended OOWS 2.0 method after having extended it during this

chapter. To give this overview, the RIA characteristics described earlier at 3.6.1 in this

dissertation are used as reference.

• Client/Server distribution The server side data/functionality is indicated in the

Object model and the Abstract Interaction model. The data/functionality available

at client side is indicated in the Presentation model, including the specification of

where and how the user event functionality originates/applies in the Presentation

model.

• Asynchronous communication has not been implemented because the 23AndMe

case study does not require them, but is can be easily supported by presentation

layer user events, bound to EventSpecifications from the Abstract Interaction model.

• Events events are both specified in the Presentation model defining where and how

user event functionality originates/applies in the Presentation model, and in the

Interaction model defining which data elements will be used for the event functionality

defined Presentation model.

6.4 Overview available RIA functionality 80

• Advanced Presentation is provided by the Presentation metamodel (the existing

Adobe Flex or the new HTML5 with jQuery-JavaScript). Many instances of these

metamodel elements can be instantiated and can even be nested within each other.

• Patters were already fully supported by the original OOWS 2.0 method by the

Abstract Interaction Patterns model that could be applied on the elements of the

Abstract Interaction model.

ADDING SEMANTICS MODELING TO OOWS 2.0 81

Chapter 7

Adding semantics modeling to

OOWS 2.0

This chapter introduces a whole new modeling part to the OOWS 2.0 method. This mod-

eling part will allow developers to model ontologies and associate them to OOWS 2.0

elements using a weaving mechanism. Doing so, during the subsequent M2C generation

phase, these associations can be exploited to incorporate the semantic information into the

web application code by means of semantic annotations.

7.1 Ontology modeling

The first step in adding semantic information to the web application, is to model the se-

mantic information to be associated to the web application, so through subsequent weaving

steps it can be linked to OOWS 2.0 elements. Therefore a Ontology Metamodel has been

defined that allows developers to model their ontologies. The illustration in fig.7.1 show

a graphical representation of the Ontology metamodel that will allow to model seman-

tic information. The semantic information model is hold in the SemanticsModel class of

the metamodel. Out of SemanticsModel class, semantics models for the RDFa technol-

ogy (RdfaSemantics class), Microformats Technology (MicroformatsSemantics class) and

Microdata technology (MicrodataSemantics class) can be created. Each technology can

have multiple vocabularies assigned. Vocabularies have been added to allow developers

to maintain structure in their semantic models. For instance, the RDFa technology could

have a vocabulary containing the DC ontology, another containing the FOAF ontology, etc.

The vocabularies have a uri String attribute where developers can specify the location of

7.1 Ontology modeling 82

the ontology, this will in the subsequent M2C generation phase allow to create namespaces

and thereby achieve shorter, cleaner code. Out of the Vocabularies there is a semantics

reference to a RDFa, Microdata or Microformats parent class that will allow the vocabu-

lary to contain the semantic information elements.

On the top of the figure the SemanticsNamedElement is illustrated. This element is the

parent element for all semantic information elements. Below it, there are three child el-

ements; RdfaNamedElement, MicroformatNamedsElement and MicrodataNamedElement.

Each of these elements will on their turn be the parent element for all semantic informa-

tion for one of these defined technologies. With these parent classes, in subsequent steps

it will be possible to lay weaving references on technology specific semantic elements and

link them to OOWS 2.0 elements.

In fig.7.1 there is a red dashed line surrounded part at the left that contains the RDF

metamodel for the RDFa semantic annotation technology. Another green dashed line sur-

rounded part in the right of the figure contains the metamodel for the Microdata semantic

annotation technology. Both of them are discussed with more detail in following subsec-

tions. The metamodel for the Microformats technology is not present in the figure, but it

has been created similar to the Microdata metamodel.

As ontologies are usually defined in machine interpretable languages (RDF, XML, etc.), it

would even be possible to generate OOWS 2.0 Semantic models from existing ontologies

automatically, avoiding that these Semantic models have to be defined by hand.

7.1 Ontology modeling 83

Figure 7.1: Semantics Metamodel

7.2 Semantics weaving 84

7.1.1 RDFa metamodel

The RDFa technology is based on RDF. The ontologies used by RDFa are usually defined

in RDF and therefore the RDFa ontology definition metamodel is actually the RDF meta-

model. This metamodel has been taken over from the [Chang and Kendall, 2004] paper.

The RDFa metamodel central element is the RdfsResource. Children of the RdfsResource

are the RdfsClass and the RdfsProperty elements. Every RdfsResource can have multiple

types assigned, defined as RdfsClasses. RdfsProperties are assigned range and domain Rdf-

sClasses. RdfsClasses and the RdfsProperties can have their own inheritance hierarchies.

The RdfsDatatype is a special type of RdfsClass and the RdfsLiteral is a special type of

RdfsResource that will contain text basically.

7.1.2 Microdata metamodel

For the Microdata ontologies, no formal definition for the metamodel has been encountered

during the literature study. Therefore a simple metamodel has been created that allows

the developer to specify the Microdata concepts. It consist out of a ItemscopeItemType

element that can be seen as a UML class from the RDFa metamodel, and the ItemProp

element that can be seen as UML attribute or relationship. This simple form of metamodel

has also been used for Microformats and has been found expressive enough to add semantic

annotations into web applications.

7.2 Semantics weaving

The semantic weaving uses the similar principle as presentation weaving, but it provides

some more enhanced weaving mechanisms. The semantics weaving metamodel is illus-

trated in fig. 7.2. The top SemanticsWeaving element contains both a weaving model

for annotating OOWS 2.0 conceptual model elements (OowsSemWeaving), and a weaving

model for annotating OOWS 2.0 presentation model elements (PresentationSemWeaving).

Both these weaving models provide the same underlaying weaving functionality, just that

they are focused on their corresponding OOWS 2.0 elements. As both metamodels are

equal in functionality, Fig. 7.2 only illustrates the details of the metamodel to annotate

OOWS 2.0 conceptual model elements (OowsSemWeaving) in order to save space and avoid

redundant information.

The OowsSemWeaving and PresentationSemWeaving elements themselves can contain a


Microdata (MicrodataWeaving), RDFa (RdfaWeaving) and Microformats (MicroformatsWeav-

ing) weaving model. Again, because the weaving mechanisms in these three technology

dependent weaving metamodels are equal and to avoid redundant information, only one of

them, the RDFa weaving metamodel is shown in more detail in fig. 7.2.

As mentioned earlier, the weaving principle applied for semantic annotation, is more en-

hanced but similar similar to the presentation weaving principle mentioned earlier. The Mi-

crodataWeaving, RdfaWeaving and MicroformatsWeaving elements themselves can contain

just liken in presentation weaving both a default weaving model (DefaultRdfaSemWeav-

ing) and a overriding weaving model (OverridingRdfaSemWeaving). The default semantics

weaving metamodel is surrounded in fig. 7.2 with the blue dashed line, and the overriding

semantics weaving metamodel with the purple dashed line. Both of them are discussed

with more detail in the following subsections.

One of the main advantages that incorporates the default - overriding semantic weaving

mechanism, is that a one time defined, the default semantic weaving model can be reused

for any web application development project without having to apply any changes. On

top of the default semantic weaving, overriding semantic weaving can be applied to further

customize the semantic bindings.


Figure 7.2: Semantics weving Metamodel

7.2.1 Default semantics weaving

The default semantics weaving model, also similar to default presentation weaving, con-

sists out of many default weaving elements (DefaultRdfaSemWeaElement) that will allow

to link OOWS 2.0 conceptual (meta)model elements with semantic model elements.

To make it possible to lay references to OOWS 2.0 conceptual metamodel elements, the


same trick as used in default presentation weaving is applied. The red dashed circle with

index 1 if fig. 7.2 indicates the diamond symbol at begin of the reference that defines it

as contained. So when defining default weaving links, the developer in fact creates new

special conceptual or presentation elements and links them to elements of the semantic

model. In order to avoid confusion with the real conceptual elements from the web ap-

plication model, it is again important that these special conceptual elements are in their

name identified as default and thereby indicated to form no part of the conceptual model

of the web application.

In difference to the default presentation weaving model where one conceptual (meta)model

element is linked to one presentation model element, the default semantics weaving model

allows one conceptual (meta)model element to be linked to multiple semantic weaving

elements. This has been achieved by defining the references reference as a multi reference.

Doing so it allows to link many DefaultRdfaSemWeaReference elements to one Default-

RdfaSemWeaElement. Out of the DefaultRdfaSemWeaReference element, developers can

specify their desired element out of the earlier defined semantics model and thereby weave

it.

7.2.2 overriding semantics weaving

The overriding semantics weaving model is as it name indicates should override the default

semantics weaving model. Although overriding is in this case not the best term, as in

fact its metamodel does not only allow to override the default semantics weaving model,

but it also allows to add or remove overriding semantic information on top of the default

semantics weaving model.

The red dashed circle with index 2 if fig. 7.2 towards the OowsNamedElement indicates

that the semantic overriding links are in contrast to default semantic weaving, laid to ex-

isting conceptual model elements (it is in theory also possible to lay them to the special

conceptual elements of the default weaving, but this has not been supported, so caution is

required).

If a developer would like to override all the default weaving semantic links and only add new

semantic links, he can set the overrideAll attribute true in the OverrideRdfaSemWeaEle-

ment class and it will act accordingly. Subsequently the reference reference can be used to

link the new required semantic model elements. If the overrideAll attribute is left false,


the new assigned semantic model elements will just be added in parallel with the ones

defined in the default semantics weaving model.

The green dashed circle with index 3 if fig. 7.2 on the toBeOverriden reference provides

developers the possibility to override only some of the default semantic weaving references.

All of the DefaultRdfaSemReference elements of the default weaving referenced through the

toBeOverriden reference will not be used added as annotations on the current conceptual

element in the M2C generation phase.

GENERATING CODE OUT OF THE MODELS 89

Chapter 8

Generating code out of the models

Now all the metamodels of the extended OOWS 2.0 modeling environment have been de-

fined formally, it is time to create M2C transformations that will allow to automatically

generate code out of the models. During this chapter the code generation process imple-

mented for this dissertation will be discussed. In order to generate code out of EMF models,

there are two important components; The M2C transformation definition with knowledge

about the metamodel of the input model, and the transformation execution engine. The

M2C transformation will be defined using the Xpand technology, and is discussed during

section two, three, four and five of this chapter. The transformation execution engine is

implemented using the EMF code generator, and is discussed in the sixth section of this

chapter. Because nothing is perfect, after generation still some tasks have to be carried

out in before deploying the generated code. These tasks are discussed in the penultimate

section of this chapter. The final section provides some screen shots of the generated case

study 23AndMe application.

8.1 General generation overview

In order to give an general overview about how actually the final code is obtained out the

models an illustration has been included at fig. 8.1. It shows from top to bottom a more

or less chronological transformation overview of how from different input models and its

internal elements, the output artifacts are generated. It also illustrates how sometimes

additional non in the models included information is required by the generation process

and how sometimes intermediate elements are generated (especially to prepare the default

presentation and semantics) to facilitate subsequent generation.

8.1 General generation overview 90

Figure 8.1: Overview of the extended OOWS 2.0 M2C transformation

8.2 Defining M2C transformations 91

8.2 Defining M2C transformations

8.2.1 Xpand - Xtext motivation, introduction

As the metamodels for the extended OOWS 2.0 method modeling environment have been

defined using the Eclipse Modeling Framework (EMF, see 2.1.2), it is recommended to

define the transformations using Eclipse based technologies offered by the Eclipse Model

to Text (M2T, see 2.1.3) project. From the M2C transformation technologies the Eclipse

M2T project offers, Xpand together with Xtext java extensions are some of the most ma-

ture technologies and have the widest developer support. They therefore have been chosen

as the transformation technologies for the M2C transformations introduced during this

chapter.

As mentioned when discussing Xpand in the Background chapter 2.1.3, Xpand is a se-

quential imperative language that allows to traverse through the input model based on the

specification of the metamodel and that generates output code according to the specifica-

tions in the transformation. Its major model traverse operations are definitions (DEFINE)

and expand rules (EXPAND). Definitions can be seen as a kind of methods without name

that are identified through the type of metamodel element they handle. Within definitions

many operations can be executed, and one of them is the expanding operation that allows

one or multiple elements of the model to be expanded to other definitions in the transfor-

mation that on their turn will handle these elements they were passed.

The operations Xpand provides to generate code are:

• FILE which creates a new file on a determined place within the output location.

Once a file has been created, Xpand only allows to sequentially introduce the code

within it. In other words, Xpand requires that all the information to generate code

is ready when creating a file, it does not allow to first create some kind of skeleton

code to be later filled in from other points in the transformation when more details

are known about the models.

• FOREACH is a well know simple clause that allows to carry out one or many

certain tasks for all of the elements within the set.

• IF - ELSE are the well known operators that allow to carry out different tasks

depending on a certain condition.

8.2 Defining M2C transformations 92

• LET AS allows to create local variables and store information out of the model or

simple text within them.

• REM allows to put comment for clarification reasons in the Xpand code.

Because these operations are very limited, Xpand allows to use create your own Xtext

extensions that allow to create Java programing language methods and carry them out

while generating code. For instance, one of the most simple Xtext extension that has

been created for this dissertation, is a Java method that capitalizes the first character of a

string. This extension allowed that class names were created according to the programing

standards of the output technologies.

As mentioned earlier during this dissertation, the target technologies for the proof of con-

cept M2C transformation implementation of this dissertation is the J2EE framework with

on top of it the HTML5, jQuery-JavaScript presentation technologies, and the RDFa, Mi-

crodata, Microformats semantic annotation technologies. It is a good practice to keep

these technologies separated so that they easily could be replaced by alternatives or new

emergents. This has succeeded for the two lower Persistence and Business layers, but due

to the nature of the Xpand M2C transformation technology and the heavy interaction be-

tween the RDFa, Microdata, Microformats, HTML5, jQuery and JSP Presentation layer

technologies it resulted difficult to keep them separated.

8.2.2 Starting Xpand M2C transformation

Below, the Xpand code is illustrated that initiates the transformation from the model into

code. Beause Xpand M2C transformations can be based on multiple metamodels, the first

thing done is thus importing the metamodels that will be used during the M2C transfor-

mation. For this extended OOWS 2.0 method, the driving metamodel will be the extended

OOWS 2.0 method metamodel discussed in previous chapters. Next to extended OOWS 2.0

method metamodel, it is also necessary to import the top Ecore metametamodel discussed

earlier in this dissertation at 2.1.2 so that during Xpand M2C transformation, reasoning

can be performed on the metametamodel basic concepts such as inheritance, relationships

and etc.

�IMPORT ecore��IMPORT metamodel�

8.3 Transformations for the persistence layer 93

�DEFINE main FOR Model��EXPAND oows(this) FOR oowsSpecification�

�ENDDEFINE�

�DEFINE oows(metamodel::Model main) FOR metamodel::OOWS::OOWSSpecification��EXPAND ObjectmodelTemplate::objectmodel(main) FOR oomModel��EXPAND AiModelTemplate::aim(main) FOR aiModel�

�ENDDEFINE�

Now the metamodels have been imported, the M2C transformation can be stared by calling

the main definition in the above code. What it does is passing the OOWSSpecification

model to a subsequent definition where the model is split in the oomModel part and the

aiModel. Each of them will be handled independently. The first oomModel will mainly

create the persistence and business layer of the final web application, while the second

aiModel will create mainly the presentation layer.

Note that when expanding parts of the model to independent transformation definitions,

each time a reference to the main model is passed as parameter. Because of the high grade

of interrelationship in the model, this has crucial for the transformation because it allows

within a certain definition, to search for often indirectly related information on a whole

other place than the current definition in the model and act accordingly.

8.3 Transformations for the persistence layer

The persistence layer in a J2EE application is the base layer that handles the persistence

of data, usually in persistence specific databases like MySQL, etc. For this M2C transfor-

mation, the persistence layer is targeted on the Hibernate1 framework. This framework

allows to persist data to a big variety of database technologies, just by having entity class

instances annotated with Hibernate platform specific persistence information. It primarily

requires a xml specification file that next to other persistence specific specifications, mainly

indicates which entity classes have to persisted and on which database source. Secondarily,

it requires the with persistence properties annotated entity classes, these define which and

how data from the persistence classes has to be persisted and defines the relationships

between the different data objects when persisting it.

1http://www.hibernate.org/

http://www.hibernate.org/


8.3.1 Object model M2C transformation

All the previously mentioned information required for the persistence layer is available in

the OOWS 2.0 Object model.

Persistence specification file

The Xpand oomModel definition therefore starts of creating the Hibernate persistence

specification xml file illustrated below:

�FILE "src/META-INF/persistence.xml"�<?xml version="1.0" encoding="UTF-8"?>

<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">

<persistence-unit name="�this.persistenceUnit�">

<jta-data-source>�this.jtaDataSource�</jta-data-source>

�FOREACH main.oowsSpecification.oomModel.classes AS class�<class>entity.�class.name�</class>

�ENDFOREACH�<shared-cache-mode>NONE</shared-cache-mode>

<validation-mode>NONE</validation-mode>

</persistence-unit>

</persistence>

�ENDFILE�

As can be seen in the code, the transformation creates a new file named persistence.xml that

contains information about the persistence unit. It gives the persistence unit a name and

a jta datasource (for this proof of concept, these values have been included in the model,

but in order to keep the model platform independent they should better be obtained out

of a transformation properties file.). And further does it cite the location of all the entity

classes that are desired to be persisted. This is just a enumeration of all the classes from

the OOWS 2.0 Object model.

Persistence entity classes

The next step in creating the persistence layer is to create the Hibernate entity classes.

The transformation therefore traverses through the OOWS 2.0 object model and creates

a entity class for each class within the Object model. Each of these entity classes is by

default given an id attribute, further attributes, associations and constructors are added,


depending on the attribute and association specifications of the particular class in the

Object model. For the id and the rest of attributes, associations to other classes (carefully

handling the cardinalities and containment properties), set and get methods are added. A

part of the Xpand code that creates these classes out of the Object model is illustrated

below. Earlier in the code a new entity class file has been created in the entity folder and

is now filled in with the required entity class code.

@Entity

public class �this.name� implements Serializable {private static final long serialVersionUID = 1L;

@Id

@GeneratedValue(strategy = GenerationType.AUTO)

private int id;

�FOREACH this.attributes AS attr�private �attr.type� �attr.name�;

�ENDFOREACH�

public �this.name�() {super();

}

public �this.name�(�FOREACH main.oowsSpecification.oomModel.associations

AS asso��IF asso.from.associatedWith.name == this.name��asso.to

.associatedWith.name� �asso.name.toFirstLower()��asso.to.associatedWith

.name.toFirstUpper()�, �ENDIF��ENDFOREACH��FOREACH this

.attributes AS attr� �attr.type� �attr.name��IF this

.attributes.last() != attr�, �ENDIF��ENDFOREACH�) {super();

�FOREACH main.oowsSpecification.oomModel.associations AS asso��IF asso.from.associatedWith.name == this.name�this.�asso.name.toFirstLower()��asso.to.associatedWith.name.toFirstUpper()�= �asso.name.toFirstLower()��asso.to.associatedWith.name.toFirstUpper()�;

�ENDIF��ENDFOREACH��FOREACH this.attributes AS attr� this.�attr.name� = �attr.name�;


�ENDFOREACH�}

public int getId() {return this.id;

}

public void setId(int id) {this.id = id;

}

�FOREACH this.attributes AS attr�public �attr.type� get�attr.name.toFirstUpper()�(){return this.�attr.name�;

}

public void set�attr.name.toFirstUpper()�(�attr.type� value){this.�attr.name� = value;

}�ENDFOREACH�

�FOREACH main.oowsSpecification.oomModel.associations AS asso��IF asso.from.associatedWith.name == this.name��IF asso.to.maxCardinality == 1 && asso.from.maxCardinality == 1�//bi-directional one-to-one association to �asso.to.associatedWith.name�@OneToOne(fetch=FetchType.EAGER)

@JoinColumn(name="�asso.to.associatedWith.name.toUpperCase()�ID")

...

As can be seen, Xpand is a though language and this is only a part of the code used to

create entity classes. Especially the part concerning the associations between classes has

not been shown as it is full of checks and loops to make it work. Through the rest of this

chapter showing Xpand code will as much as possible be avoided as it would overload this

chapter with often hard to follow Xpand code.

8.4 Transformations for the business layer 97

8.4 Transformations for the business layer

The business layer for J2EE applications exists basically out of entity facades with their

interfaces that handle the functionality for retrieval and storage of data in the underlaying

persistence layer, and Enterprise Java Beans (EJB) with their remote interfaces that will

provide the data managing functionality required by the upper presentation layer.

The first element created is a abstract facade that contains some default facade functions

such as “create”, “edit”, “remove”, “find”, “findall” for storing and retrieving entity ele-

ments through the hibernate framework. For this abstract facade, no information out of

the object model is required as the abstract facade is general for all further entity specific

faces.

8.4.1 Object model M2C transformation

Out of the Object model, the M2C transformation can obtain all the required information

to create the entity facades, the default services EJB and the skelenton services EJB. For

each of these transformation output artifacts, the transformation process is discussed below

in more detail.

Entity facades

The entity specific facades extend the earlier mentioned abstract facade. They provide

several entity specific methods:

• create is a method that creates a new object of a particular entity class, internally it

calls the entity class constructor to create a new entity and then persists it through

Hibernate framework. It therefore has the same attribute and association parameters

in its method call as the constructor of the particular entity class has. When the

method finishes, it returns the entity object is just created to the function that

originally called method.

The M2C transformation uses from the Object model the information about the class

name, attribute names, attribute types, relationship names, relationship cardinalities

and relationship containment properties to create this methods.

• edit is a method that has the same parameters in its method call as the constructor

of the particular entity class has together with an extra id parameter. Internally it

calls first searches the entity object that is identified through the id parameter and


the applies all the set methods of the particular entity with the new values out of

the method parameters. On finishing, it persists the new version of the entity object

and also returns it the function that originally called the method.


name, attribute names, attribute types, relationship names, relationship cardinalities

and relationship containment properties to create this methods.

• remove is a method that will remove a particular entity object and will make sure

that all the associations are handled according to the specifications in the Object

model.


name, relationship names, relationship cardinalities and relationship containment

properties to create this methods.

• findById is a method that returns the entity object with the particular id that was

passed as parameter.

The M2C transformation only requires the class name.

• getAll is a method that allows to retrieve all the objects of a certain entity class.

The M2C transformation only requires the class name.

Now the entity facades have been created, the M2C transformation creates their interfaces

who just contain the method calls of the default methods available in the abstract facade

and those of the methods available in the entity specific facades. These interfaces will

be consumed by the subsequent Enterprise Java Beans (EJB) to provide the functionality

required by the presentation layer.

Default services EJB

The default services EJB combines all the functionality of provided in the entity facades

in one big EJB. On this EJB a remote interface will be created so that the functionality

can be consumed from the presentations layer.

Some of the crucial functions that will be consumed by the presentation layer are without

doubt; the “getAll”) function to populate Population AIU’s of contexts that are accessed

through exploration navigation, the “findById” function that will allow to populate Pop-

ulation AIU’s when the context their in is accessed though sequential navigation, the

“create” and “edit” functionality that can serve for the service AIU’s in the application.

All the required information the M2C transformation needs to create these default methods

is again found in the Object model.


Skeleton services EJB

As the OOWS 2.0 Object model does not provide support to express the semantics of the

operations and it is thus impossible to create the functionality of these operations, the

M2C transformation creates them in the skeleton services EJB. The skeleton services EJB

will contain all the operations defined in the Object model, with the parameters and return

values as they have been specified by the developer. Also for this skeleton services EJB,

a remote EJB interface will be created so that the EJB can be used by the subsequent

presentation layer.

All of the information required to create the skeleton services EJB and its remote interface

can be obtained from the Object model, the only task the developer still has to do is to

fill in the skeleton code with the desired functionality.

8.4.2 Interaction model M2C transformations

The majority of the business functionality is obtained from the Object model, but also

an important part concerning the user agents business functionality is specified in the

Interaction model.

User agents EJB

The user agents EJB with its remote interface will provide identification and authorization

functionality required by presentation layer of the end application. Especially for the reg-

istered user types, it is desirable that only the traits of that the connected user can only

access and manipulate his own data without interfering the data of other users.

The M2C transformation will according to the user agents defined in the Interaction model,

create the user agents EJB with methods that will allow to obtain a particular user agent

entity object by providing identification specific information such as its id and user name.

This obtained entity object contains all the user agent specific information, together with

information about the associations it has to other instances of the classes of the Object

model. Using this information, the M2C generation can assure that the users only can

access their personal data.

8.5 Transformations for the presentation layer 100

8.5 Transformations for the presentation layer

The presentations layer is the layer that provides the user interface of the system. For this

proof of concept implementation it is build on the following presentation technologies:

• Java Server Pages (JSP) takes care of retrieving data from and transferring data

to the underlaying business layer EJB’s. It basically build the web pages dynami-

cally depending on the the functionality incorporated in the JSP code and the data

retrieved from the business layer.

• HTML5 takes care of structuring and presenting on the web page the data obtained

from and to be transfered to the JSP technology. In its latest HTML5 version, it

also provides some basic user interaction and enhanced presentation functionality.

• jQuery - Javascript takes both care of user interaction functionality and enhanced

information presentation.

The principal sources the M2C transformation will use to obtain the required informa-

tion for creating the presentation layer are the interaction model and the presentation

model. Each of these models that internally contain multiple elements information pro-

viding elements will be thoroughly solicited by the transformation. In the two subsequent

subsections more details is given about how the M2C transformation uses the models.

Next to enhanced presentation, this proof of concept M2C transformation also wants to

provide support for semantic annotations in the final application. This annotations are

included into the presentation layer. The information the M2C transformation therefore

uses is available in the semantics model. More detail is provided in the third subsection

below.

8.5.1 Preparation for interaction model generation

Before flying into the Interaction model, the M2C transformation first goes through the

default presentation and semantics model to prepare references with these default settings

and so can avoid having to over search the default models for these values each time when

it encounters a Interaction or Object model element that has to included in the web pages.


Default presentation model M2C transformations

In order to avoid having to let the M2C transformation search each time through the default

presentation model for the presentation model element linked to a Interaction metamodel

element, the M2C transformation creates for each Interaction metamodel element a variable

that contains the default presentation model element in it. Each time an instance of

this metamodel element is later encountered in the Interaction model during the M2C

transformation , this variable can be used to instantly apply the specified presentation.

Default semantics model M2C transformations

With the same objective as before, to avoid a high number of searches through the de-

fault semantics model, also for the default semantic annotations, variables are created that

contain the semantic model element so it can be applied instantly when transforming In-

teraction and Object model elements for the presentation layer. Because multiple semantic

model elements can be linked to Interaction and Object model elements, it is achieved a

bit different, but the principle remains the same.

8.5.2 Interaction model M2C transformations

The interaction model starts with information about the interaction map and the different

user agents. When the M2C transformation traverses through this part of the model, it is

the perfect time to create the sun-web.xml, the web.xml, the web folder structure and the

log in and out pages for the registered users.

sun-web.xml

The sun-web.xml file allows the M2C transformation to specify the name of the web project

and specify different user roles in it. Each of user agents defined in the interaction map

will have its own user role. This roles are used later in the web.xml file.

web.xml

In the web.xml file, the M2C transformation guided by the interaction map specifies the

root context of the web application. It also allows to create access types (denying or

allowing access or operations on certain parts of the web folder) which subsequently can

be assigned to one of the user roles defined earlier in the sun-web.xml. Further does is also


specify through which login pages with a connected security realm a system user should

pass before it can take the access rights of a certain role.

Login - out pages

As earlier mentioned when handling the web.xml file, each Registered type of user must

have a login page where they can introduce their login and password to identify themselves

so they gain access rights to their corresponding restricted part of the application and a

logout page to leave that restricted part of the application.

The login and logout are not explicitly modeled in the interaction map, but these pages

contain interaction elements such as elements where the username and password can be

introduced together with the submit button to send the information to the server, these

elements are in fact non explicitly modeled Service AIU’s, input arguments, etc. The M2C

transformation therefore uses during the generation the according information from the

default presentation and semantics model defined by the developer and applies these on

the earlier mentioned interaction elements in the pages.

Also because login - out pages are not specifically modeled, but generated automatically

for “Registered” users, they are not represented in the interaction map. Instead, through

the M2C transformation they are expected to be by exploration navigation accessible con-

texts in the map of the “Anonumous” user. The login pages for the “Registered” users

are therefore automatically incorporated with the rest of exploration navigations from the

“Anonymous” user. In order to maintain uniformity, the “Anonymous” user exploration

navigations are also shown on the login - out pages.

The login credentials that have been provided through the users will as defined in the

web.xml be transfered to a security realm on that has to be specified on the the application

server that will take care about authorization. More information about the security realm

at 8.7.3.

8.5.3 Interaction model, object model, default variables and over-

riding models

Now all the preliminary work has been finished, it is time for the M2C transformation to

start creating the real user environment of the presentation layer. The M2C transformation


goes over all the over all the users, starting with the “Anonymous” user and following with

the “Registered” users, creating new JSP files in the right user folder for each interaction

context in the users interaction map.

The interaction contexts all contain different and diverse elements depending on the func-

tionality the developer gave them when modeling them. The two important top layer

building blocks of interaction contexts are Population AIU’s and Service AIU’s. Multiple

of them can be available in one context, the transformation process for each of them is

discussed below in more detail.

Keep in mind that each time the code for an element from the interaction model of the

object model is written in the JSP file, its default or overriding presentation, and its default

and/or overriding semantics are applied on the code of the element. Specifically for the

presentation of a interaction model, before

Preamble

Each context starts with a a JSP preamble that will allow to lay connections to the un-

derlaying business layer EJB’s. It is through these EJB’s that the JSP code will be able

to retrieve, manipulate and create data from the persistence layer. It also contains has all

the required imports of classes it may need, examples are; the entity classes, dataformats,

etc.

Also in the JSP preamble of contexts from the interaction map of “Registered” users, a

variable is created that contains the entity object of that particular user. This is entity

will be used through the rest of the JSP page if defined so in the models to only obtain

the information from the persistence layer related to this user, and to execute services of

Service AIU’s only on data related to the identified user.

If the information in the interaction map indicates that the current context is accessed

through sequential navigation, the manager id transfered through the link is used to ob-

tain the manager object from the persistence layer so it can be used for the AIU’s that

compose the context to obtain/allow only information/operations on that particular object

and its environment.

When the context contains Service AIU’s, extra code code in to be included into the JSP


preamble to transmit the data that may have been introduced and submitted in the Service

AIU to the business layer. What the preamble code does is checking if ones of its particular

Service AIU’s has been submitted, if so then all the input arguments are obtained out of

the post message, transformed in to their corresponding mime types and transmitted to the

according service of the skeleton services EJB that the developer linked to the Service AIU.

Once the JSP preamble has been established, it is time to creating the HTML5 header.

The most important parts of the header are the stylesheet references, script references

so the jQuery framework with its functionality is available in the application, and the

namespaces of the semantic vocabularies for the semantic annotations used later through

the application.

Exploration references

The first element created by the M2C transformation in the body of the JSP page are the

links to the contexts of the interaction map of the current user that are accessed through

exploration navigation. On these links the according presentation and semantics as defined

in the weaving model are applied by the M2C transformation. The links will allow the

application users access to the other through exploration navigation accessible contexts in

the interaction map of the user.

Population AUI

When creating the Population AIU’s of a context, the M2C transformation starts with

the manager class of the AIU. Depending on whether the context is accessed through se-

quence navigation or exploration navigation, the indicated object through the link is taken

as manager object, or all the objects of the manager class are going to serve as manager

object (applying off course possible Abstract Interaction Patterns (AIP) such as order cri-

teria, filters, navigation etc. that could be applied on any of the classes and relationships

in the AIU). The M2C transformation writes code so that these manager object(s) are

obtained through JSP code from the business layer, who on his part obtains them from the

persistence layer. The M2C transformation also writes JSP code that allows the attributes

indicated in the model to be represented to the end users when consulting the web page.

Further does the M2C transformation traverse the Population AIU following the relation-

ships out of the manager object(s) to other objects and writes the required JSP code to

obtain this objects with its attributes, AIP’s applied and ect.


Service AIU

For the Service AIU’s of a context, the M2C transformation creates for each argument

in the Service AIU depending on its type; manipulable inputs, hidden constant inputs,

and depending on their presentation settings input fields. The M2C transformation also

applies the different AIP’s such as validation rule, argument setting, ect. that could be

defined on them. For each Service AIU is also by default a hidden id field included that

will allow to identify the right service handling when submitted by the according handling

code available in the JSP file preamble discussed earlier.

Presentation and semantics

Every time when the M2C transformation writes code in the JSP file and traverses through

elements in the model, depending on the default and overriding settings from the presen-

tation and semantics weaving, the according actions are taken. As the Object model and

Interaction model elements all inherit from a certain NamedElement that can be connected

through overriding weaving to a/multiple presentation and/or semantics model element,

the M2C generation checks these overriding links to see what presentation or semantics

elements are connected and applies them on the element by writing it in the JSP file. If

no presentation overriding link is defined then, the M2C transformation uses the current

elements type to obtain the default presentation element prepared earlier and applies it.

Depending on the specification (override all, etc.) in the overriding semantics link on a

model element, the M2C transformation obtains no, partly or fully the default semantics

elements and applies them by writing it in the JSP file.

Events

By default, every JSP file has JavaScript event channel functionality incorporated. This

event channel does by default nothing, the infrastructure is just available for in case events

may have been defined in the web page.

Every time an element of the Interaction model is handled, the M2C transformation checks

whether there is an EventSpecification associated with the element. If this is the case, then

extra jQuery - JavaScript code is included in the web page that allows depending on

the presentation event specification transmit/receive events to/from the event channel on

certain user interactions / resulting in certain presentation actions on the Interaction model

8.6 Generating code 106

element with the associated EventSpecification.

8.6 Generating code

8.6.1 Generation workflow

To recapitulate a bit, the general MDD code generation process is shown again in fig. 8.2.

It illustrates how a M2C transformation is based on a metamodel that defines what the

transformation will encounter in the models. The input for the transformation is a instance

model of the metamodel that will result in the output code.

Figure 8.2: MDA code generation process (image taken from [Insfran, 2012a])

EMF code generation, follows the MDD generation process and has to have its generation

workflow defined in a MWE file. The MWE file created for the transformation defined in

this dissertation is illustrated below. The MWE file first specifies where the input model

and can be found, and where the generated code should be stored. Now some preparations

of the generation environment such as loading the model and specifying generation have to

be carried out. Once this has been done, the workflow allows to perform model checking to

find possible inconsistencies in the model. Now the model has been checked, t he generation

can start by calling the Xpand transformations defined earlier that will generate the code in

the specified output folder. As the standard Xpand code output has quite messy aesthetics,

code beautifiers can be applied that reformat the code into the standard structure. EMF

has by default beautifiers for Java and XML code but not for JSP HTML5 and jQuery, so

this code remains with the messy aesthetics.

<workflow>

8.6 Generating code 107

<property name="model" value="test2.generator.project/src/Model.xmi" />

<property name="src-gen" value="src-gen" />



<bean class="org.eclipse.emf.mwe.utils.StandaloneSetup" >

<platformUri value=".."/>

</bean>



<bean id="mm_emf" class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"/>



<component class="org.eclipse.emf.mwe.utils.Reader">

<uri value="platform:/resource/${model}" />

<modelSlot value="model" />

</component>



<component class="org.eclipse.xtend.check.CheckComponent">

<metaModel idRef="mm_emf"/>

<checkFile value="metamodel::Checks" />

<emfAllChildrenSlot value="model" />

</component>



<component class="org.eclipse.xpand2.Generator">

<metaModel idRef="mm_emf"/>

<expand

value="template::Template::main FOR model" />

<outlet path="${src-gen}" >

<postprocessor class="org.eclipse.xpand2.output.JavaBeautifier" />

<postprocessor class="org.eclipse.xtend.typesystem.xsd.XMLBeautifier"/>

</outlet>

</component>

</workflow>

8.7 Deploying the application 108

8.7 Deploying the application

Although a lot of code has been generated by the M2C transformation, there are still some

tasks to be carried out before the application will be up and running.

8.7.1 Filling in the skeleton EJB

The first task is to code the desired functionality for the services defined in the Object

model. This functionality has to filled in the skeleton services EJB already prepared by

the M2C transformation. The developer can make use of the default services provided in

the “default services EJB” and the functionality offered by the entity facades to define the

desired functionality and off course add whatever other functionality the developer likes to

add.

8.7.2 Using Hibernate for the persistence layer

Before the application can run, it is fundamental that a persistence infrastructure is avail-

able to handle the data of the application. For this dissertation, the free MySQL2 database

server has been used to host the data of the application, but many alternative database

servers are available.

Once the database server is up and running and a database has been created, automatically

through the Hibernate framework the database structure for the web application can be

generated. Accordingly to the data structure and annotations in the entity classes, the

Hibernate framework will create the tables, relationships, primary and foreign keys.

8.7.3 Deploying on GlassFish server

For running the web application, the well known GlassFish3 application server has been

used. Before it can run the generated application, some specific settings have to configured,

they are discussed in more detail below. In stead of the GlassFish server, developers could

also run the generated code on other Java supporting servers as Tomcat, JBOSS, etc.

2http://www.mysql.com/3http://glassfish.java.net/

http://www.mysql.com/

http://glassfish.java.net/

8.8 Generated 23AndMe application 109

Data connection

As the application will require access to the earlier defined database server, a JDBC

database connection will have to be established. Therefore in GlassFish, first a new JDBC

connection pool instance will have to be created, pointing to web application database.

And subsequently this connection pool is used to create a new JDBC resource that will be

used by the web application and the subsequently created security realms.

Security realm

The security realm allows to specify the security features for the different user roles cre-

ated by the M2C transformation in the sun-web.xml file. It is important that the developer

creates this realm in the GlassFish admin console and assigns the right “database connec-

tion”, “user table”, “user name column”, “password column”, “group table”, “group name

column”, “assign groups” and the required encryption if applicable.

Additional

Additionally, there is the possibility to apply a CSS style sheet on the web pages to per-

sonalize the applications aesthetics.

Deploying

Having completed the previous GlassFish configuration tasks, the only thing left to do,

is to compile the generated code of the M2C transformation with the completed skeleton

services EJB to a war file, upload it to the server and deploy it.

8.8 Generated 23AndMe application

These screen shots only provide some by this dissertation targeted RIA and semantic

examples in the web page that has been generated out of the models with the extended

OOWS 2.0 method. Keep in mind, that in order to improve the aesthetics aspects of the

web application, CSS code file has been applied on the generated webpages, more or less

imitating the CSS of the original case study 23AndMe webpage. A more detailed view of

the whole generated web page will be provided on the public recitation of this thesis.


8.8.1 RIA

Tabs

Figure 8.3: Extended OOWS 2.0 method generated jQuery tabs

Compare genes - events - accordion

Figure 8.4: Extended OOWS 2.0 method generated compare genes - events - accordion


Fig. 8.4 illustrates how through user events (clicks), information incorporated in the trait

type holding top Population AIU with accordion presentation applied on it, is passed to

the lower Population AIU showing the particular trait values of the traits that have been

clicked.

8.8.2 Semantic annotations

Figure 8.5: Extended OOWS 2.0 method generated semantic annotations

In fig. 8.5 the Ubiquity RDFa parser4 has been applied on a discussion page from the Forum

part of the generated 23AndMe web application. It reveals the RDFa SIOC ontology

semantic annotations defined in the models that have been inserted into the the web

application during the code generation. As can be seen, the Ubiquity RDFa parser identifies

a SIOC - Thread called “Cancer” that has been created by “Bert” and that has received

several replies.

4http://ubiquity-rdfa.googlecode.com/svn/trunk/install-checker.html

http://ubiquity-rdfa.googlecode.com/svn/trunk/install-checker.html

CONCLUSIONS 112

Chapter 9

Conclusions

9.1 Achievements

This dissertation has successfully extended and completed the OOWS 2.0 [Girome, 2010]

model driven web development method to provide support for: 1/ multiple implementation

platforms, with the support of HTML5 and jQuery-JavaScript presentation technologies in

addition to Adobe Flex, 2/ semantic annotations, allowing multiple semantic annotations

and different annotation technologies to be applied simultaneously, 3/ model compilation

to allow web applications to be generated from model instantiations. I elaborate these

achievements below.

The OOWS 2.0 method has been extended by adding new presentation metamodels provid-

ing modeling support for the HTML5 and jQuery presentation technologies. The original

OOWS 2.0 method provided presentation modeling support for the Adobe Flex technology.

This dissertation has proven that the extended OOWS 2.0 provides support for multiple

presentation platforms, and thus could be further extended and used if new future pre-

sentation technologies break through, without having to introduce fundamental changes in

the metamodels. This has been achieved through a new weaving mechanism that avoids

hard presentation coding, replacing it with default and overriding presentation weaving

on Abstract Interaction model elements. Concretely, a new top parent CommonPresen-

tationNamedElement Presentation model class, and new top parent AbstractInteraction-

ModelNamedElement Abstract Interaction model class have been defined together with a

new weaving metamodel combining default and overriding presentation weaving. Default

presentation weaving allows to bind by default any element from the Presentation model

to any concept used during Abstract Interaction modeling. Overriding presentation weav-

9.1 Achievements 113

ing allows overriding the default presentation weaving by binding any element from the

Presentation model directly to any element from the Abstract Interaction model.

The OOWS 2.0 method has also been extended to add support for semantic web, allowing

Object model, Abstract Interaction model and Presentation model elements to explicitly

expose their semantic meaning. In the method this was achieved by creating a new Se-

mantics metamodel allowing to model ontologies (for now support is available for RDFa,

Microdata and Microformats), and a enhanced weaving mechanism allowing to bind se-

mantic model elements to Object model, Abstract Interaction model and Presentation

model elements. The semantics weaving mechanism is similar to the presentation weaving

mechanism, and is fundamentally based on top parent classes in the metamodels. One

fundamental difference however is the fact that multiple semantic model elements can by

linked to an element from the Object model, Abstract Interaction model or Presentation

model. This allows supporting different vocabularies and/or different annotation technolo-

gies to be used simultaneously.

To demonstrate the functional completeness of the modeling support provided by the ex-

tended OOWS 2.0 method, a proof of concept model to code (M2C) transformation has

been implemented using the Xpand - Xtext model transformation languages. This M2C

transformation demonstrates that out of the models from the extended OOWS 2.0 method,

it is possible to generate working code and that the extended OOWS 2.0 method indeed

is able to provide qualitative alternative solutions for Web 3.0 software development. To

show that the extended OOWS 2.0 method functions in a real-world setting, the 23AndMe

case study application has been modeled using the extended OOWS 2.0 method and af-

ter applying the M2C transformation, functioning code has been generated out of it. A

demonstration of how the extended OOWS 2.0 method is used to model the 23AndMe

web application and code is generated out of the models, showing the end web application

result, will be presented on the public recitation of this dissertation.

In conclusion, this dissertation successfully tackled its objectives described at 1.3 in the

introduction chapter by 1/ providing modeling support for; a/ different RIA presentation

implementation technologies, b/ multiple semantic annotations technologies, allowing them

to be applied simultaneously, 2/ providing Model to Code generation support, allowing to

obtain ready for deploy web applications, 3/ demonstrating that the elaborated extended

OOWS 2.0 method is viable alternative for ordinary WEB 2.0 - 3.0 software production

having incorporated the Model Driven Architecture software development advantages.

9.2 Limitations - future work 114

9.2 Limitations - future work

Although the objectives of this dissertation have mainly been accomplished, the work also

has its limitations and can be further completed.

Only for a part of the HTML5 and jQuery-JavaScript presentation technologies a meta-

model has been made. Only the concepts that were going to be used by the 23AndMe case

study have been metamodeled. In order to let the extended OOWS 2.0 method provide

full support for these technologies, the presentation metamodel should be further extended.

Support for events is available and is functioning well, but it remains very basic as only

support for the types of events encountered in the 23AndMe case study has been provided.

The event supporting part in the presentation - Abstract Interaction metamodel should

be further extended to provide support for additional user event generating interactions,

event output presentation actions and others.

A nice to have would be possible C2M transformations that could take existing ontologies

as input and generate the corresponding extended OOWS 2.0 Ontology model.

Specifically concerning the presentation layer generation in the M2C transformation, the

Xpand implementation code for generation of the logic-communication with business layer

(JSP), presentation (HTML5, etc.) and semantics(RDFa, etc.) is currently heavily nested.

This is due to the nature of the Xpand language and the high nesting between the logic,

presentation and semantics output languages in the presentation layer. Independent Xpand

code routines could be created for each of the three presentation layer output languages;

this would make the implementation clearer, and more importantly, easier to maintain.

The code obtained after M2C transformation for the persistence and business layer is

passed through Java and XML beautifiers that reformat the code to the standard aligned

Java/XML form. There are currently no code beautifiers available for the presentation

layer JSP, HTML5, jQuery, RDFa, Microdata, Microformats implementation languages.

Beautifiers are not indispensable because the generated code works, but still it would be

a nice to have if the presentation layer code could be delivered in the standard aligned form.

As ultimate, this dissertation presents a proof of concept code generation implementation,

which did not undergo rigorous testing procedures as commercial software typically under-

9.2 Limitations - future work 115

goes. To detect errors and to ensure a more functionally complete and qualitative code

generation, additional case studies should be performed.

BIBLIOGRAPHY 116

Bibliography

[Bozzon et al., 2006a] Bozzon, A., Comai, S., Fraternali, P., and Carughi, G. T. (2006a).

Capturing ria concepts in a web modeling language. pages 907–908.

[Bozzon et al., 2006b] Bozzon, A., Comai, S., Fraternali, P., and Carughi, G. T. (2006b).

Conceptual modeling and code generation for rich internet applications. pages 353–360.

[Brambilla and Facca, 2007] Brambilla, M. and Facca, F. M. (2007). Building semantic

web portals with webml. pages 312–327.

[Busch and Koch, 2009] Busch, M. and Koch, N. (2009). Rich internet applications state-

of-the-art. Technical Report 0902, Programming and Software Engineering Unit (PST),

Institute for Informatics, Ludwig-Maximilians-Universitat Munchen, Germany.

[Carughi et al., 2007] Carughi, G. T., Comai, S., Bozzon, A., and Fraternali, P. (2007).

Modeling distributed events in data-intensive rich internet applications. pages 593–602.

[Casteleyn et al., 2009] Casteleyn, S., Daniel, F., Dolog, P., and Matera, M. (2009). En-

gineering Web Applications. Springer.

[Casteleyn et al., 2006] Casteleyn, S., Plessers, P., and Troyer, O. D. (2006). On generating

content and structural annotated websites using conceptual modeling. 4215:267–280.

[Ceri, 2007] Ceri, S. (2007). Design abstractions for innovative web applications. pages

1–2.

[Chang and Kendall, 2004] Chang, D. T. and Kendall, E. (2004). Metamodels for rdf

schema and owl.

[Comai and Carughi, 2007] Comai, S. and Carughi, G. T. (2007). A behavioral model for

rich internet applications. pages 364–369.

[Duhl, 2003] Duhl, J. (2003). Rich internet applications - idc report.

BIBLIOGRAPHY 117

[Facca and Brambilla, 2007] Facca, F. M. and Brambilla, M. (2007). pages 1235–1236.

[Fraternali et al., 2008] Fraternali, P., Tisi, M., Silva, M., and Frattini, L. (2008). Building

community-based web applications with a model-driven approach. and design patterns.

[Garrigos et al., 2009] Garrigos, I., Melia, S., and Casteleyn, S. (2009). Adapting the

presentation layer in rich internet applications. pages 292–299.

[Girome, 2010] Girome, F. V. (2010). OOWS 2.0, Un Metodo de Ingenierıa Web Para la

Produccion de Applicaciiones Web 2.0. Universidad Politecnica de Valencia.

[Gustavo Rossi, 2007] Gustavo Rossi, Oscar Pastor, D. S. L. O. (2007). Web engineering:

Modelling and implementing web applications, human-computer interaction.

[help.eclipse.org, ] help.eclipse.org. The eclipse modeling framework (emf) overview.

[Hermida et al., 2010] Hermida, J. M., Melia, S., Montoyo, A., and Gomez, J. (2010).

Developing semantic rich internet applications using a model-driven approach. pages

198–211.

[Insfran, 2012a] Insfran, E. (2012a). Course: Introduccion a mda (imd), tecnicas de gen-

eracion de codigo. Programa de Master en Ingenierıa del Software, Metodos Formales y

Sistemas de Informacion, page 13.

[Insfran, 2012b] Insfran, E. (2012b). Course: Model-driven architecture (mda), estandares

de la omg. Programa de Master en Ingenierıa del Software, Metodos Formales y Sistemas

de Informacion, page 29.

[java.sun.com, ] java.sun.com. The j2ee tutorial.

[Koch et al., 2009] Koch, N., Pigerl, M., Zhang, G., and Morozova, T. (2009). Patterns

for the model-based development of rias. pages 283–291.

[Melia et al., 2008] Melia, S., Gomez, J., Perez, S., and Dıaz, O. (2008). A model-driven

development for gwt-based rich internet applications with ooh4ria. pages 13–23.

[Pastor et al., 2008] Pastor, O., Fons, J., and Pelechano, V. (2008). Oows: A method to

develop web applications from web-oriented conceptual models.

[Pastor et al., 2001] Pastor, O., Gomez, J., Insfran, E., and Pelechano, V. (2001). The

oo-method approach for information systems modeling: from object-oriented conceptual

modeling to automated programming. Inf. Syst., 26(7):507–534.

BIBLIOGRAPHY 118

[Pastor and Molina, 2007] Pastor, O. and Molina, J. C. (2007). Model-driven architecture

in practice - a software production environment based on conceptual modeling. Springer.

[Plessers et al., 2005] Plessers, P., Casteleyn, S., Yesilada, Y., Troyer, O. D., Stevens, R.,

Harper, S., and Goble, C. A. (2005). Accessibility: a Web engineering approach. ACM.

[Preciado et al., 2007a] Preciado, J. C., Linaje, M. L., Comai, S., and Sanchez-Figueroa,

F. (2007a). Designing rich internet applications with web engineering methodologies.

pages 23–30.

[Preciado et al., 2008] Preciado, J. C., Trigueros, M. L., Morales-Chaparro, R., Sanchez-

Figueroa, F., Zhang, G., Kroiss, C., and Koch, N. (2008). Designing rich internet

applications combining uwe and rux-method. pages 148–154.

[Preciado et al., 2007b] Preciado, J. C., Trigueros, M. L., and Sanchez-Figueroa, F.

(2007b). An approach to support the web user interfaces evolution.

[Rossi et al., 2008] Rossi, G., Urbieta, M., Ginzburg, J., Distante, D., and Garrido, A.

(2008). Refactoring to rich internet applications. a model-driven approach. pages 1–12.

[Trigueros et al., 2007] Trigueros, M. L., Preciado, J. C., and Sanchez-Figueroa, F. (2007).

Engineering rich internet application user interfaces over legacy web models. IEEE

Internet Computing, 11(6):53–59.

[Troyer, 2005] Troyer, O. D. (2005). Audience-driven web site design. pages 184–187.

[Troyer et al., 2005] Troyer, O. D., Casteleyn, S., and Plessers, P. (2005). Using ORM to

Model Web Systems.

[Troyer et al., 2008] Troyer, O. D., Casteleyn, S., and Plessers, P. (2008). Wsdm: Web

semantics design method. pages 303–351.

[van der Krogt, 2006] van der Krogt, R. (2006). Model driven architecture (mda).

[www.webml.org, ] www.webml.org. The webml process.

extending the oows method to support semantic rich...

Documents