extending the oows method to support semantic rich...
TRANSCRIPT
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
Supervisors: Dr. Ir. F. Valverde Girome
Dissertation submitted to obtain the academic degree of
Official Master’s Degree in Software Engineering, Formal Methods and
Information Systems, specialty: Information Systems
Academic year 2011–2012
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
Dissertation submitted to obtain the academic degree of
Civil Engineer in Computer Sciences:
Software Engineering
Academic year 2011–2012
Promoters: Prof. Dr. Ir. O. Pastor Lopez, Prof. Dr. Ir. F. De Turck, Dr. S. Casteleyn
Supervisors: Dr. Ir. F. Valverde Girome
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
Dissertation submitted to obtain the academic degree of
Official Master’s Degree in Software Engineering, Formal Methods and
Information Systems, specialty: Information Systems
Academic year 2011–2012
Promoters: Prof. Dr. Ir. O. Pastor Lopez, Prof. Dr. Ir. F. De Turck, Dr. Ir. S. Casteleyn
Supervisors: Dr. Ir. F. Valverde Girome
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.2.2 Support for Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 WSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.1 Support for Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 41
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
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/
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.
2.1 Model Driven Architecture 11
• 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])
2.1 Model Driven Architecture 12
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
2.1 Model Driven Architecture 13
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/
2.2 Object Oriented Web Solution (OOWS) 15
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.2 Object Oriented Web Solution (OOWS) 16
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.
2.2 Object Oriented Web Solution (OOWS) 17
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
2.2 Object Oriented Web Solution (OOWS) 18
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
2.2 Object Oriented Web Solution (OOWS) 19
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
2.2 Object Oriented Web Solution (OOWS) 20
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.
2.2 Object Oriented Web Solution (OOWS) 21
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
2.2 Object Oriented Web Solution (OOWS) 22
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
2.2 Object Oriented Web Solution (OOWS) 23
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
2.2 Object Oriented Web Solution (OOWS) 24
• 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/
2.3 Used web technologies 26
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/
2.3 Used web technologies 27
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/
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
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/
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
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
3.2 OOH4RIA - SM4RIA 37
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.
3.2 OOH4RIA - SM4RIA 38
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.
3.2.2 Support for Semantics
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
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.
3.3.1 Support for Semantics
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
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
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/
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
4.2 Interaction Modeling 50
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
4.2 Interaction Modeling 51
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
4.2 Interaction Modeling 52
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.
4.2 Interaction Modeling 53
• 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
Support provided by OOWS 2.0
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
Goals of the modeling step
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.
Support provided by OOWS 2.0
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
Goals of the modeling step
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.
Support provided by OOWS 2.0
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
Goals of the modeling step
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.
Support provided by OOWS 2.0
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.
Support provided by OOWS 2.0
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
6.1 New presentation metamodel 70
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.
6.1 New presentation metamodel 71
Figure 6.1: HTML5 Metamodel
6.1 New presentation metamodel 72
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.
6.1 New presentation metamodel 73
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
6.2 Extending presentation weaving 75
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.
6.2 Extending presentation weaving 76
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
7.2 Semantics weaving 85
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.
7.2 Semantics weaving 86
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
7.2 Semantics weaving 87
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,
7.2 Semantics weaving 88
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/
8.3 Transformations for the persistence layer 94
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,
8.3 Transformations for the persistence layer 95
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�;
8.3 Transformations for the persistence layer 96
�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
8.4 Transformations for the business layer 98
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.
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.
• 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.
The M2C transformation uses from the Object model the information about the class
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.
8.4 Transformations for the business layer 99
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.
8.5 Transformations for the presentation layer 101
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
8.5 Transformations for the presentation layer 102
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
8.5 Transformations for the presentation layer 103
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
8.5 Transformations for the presentation layer 104
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.
8.5 Transformations for the presentation layer 105
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" />
<!-- set up EMF for standalone execution -->
<bean class="org.eclipse.emf.mwe.utils.StandaloneSetup" >
<platformUri value=".."/>
</bean>
<!-- instantiate metamodel -->
<bean id="mm_emf" class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"/>
<!-- load model and store it in slot ’model’ -->
<component class="org.eclipse.emf.mwe.utils.Reader">
<uri value="platform:/resource/${model}" />
<modelSlot value="model" />
</component>
<!-- check model -->
<component class="org.eclipse.xtend.check.CheckComponent">
<metaModel idRef="mm_emf"/>
<checkFile value="metamodel::Checks" />
<emfAllChildrenSlot value="model" />
</component>
<!-- generate code -->
<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/
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 Generated 23AndMe application 110
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
8.8 Generated 23AndMe application 111
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
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.