TROUBADOR PUBLISHING LTD 119 DaVinci – A Model-driven …€¦ · 120 J. WEB. INFOR. SYST. 2 (2), JUNE 2006. °c TROUBADOR PUBLISHING LTD software modeling can result in very bulky

J. WEB. INFOR. SYST. 2 (2), JUNE 2006.c©TROUBADOR PUBLISHING LTD 119

DaVinci – A Model-driven Web EngineeringFramework

A. LANGEGGER, J. PALKOSKA AND R. WAGNERInstitute for Applied Knowledge Processing (FAW), Johannes Kepler University Linz, Austria

Email: {alangegger,jpalkoska,rwagner}@faw.uni-linz.ac.at

Received: January 28 2006; revised: May 1 2006

Abstract— The World Wide Web has undergone a rapidtransition from the originally static hypertext to an ubiquitoushypermedia system. Today, the Web is not only used as a basis fordistributed applications (Web applications), moreover it serves asa generic architecture for autonomous applications and services.Many research work has been done regarding the modeling andengineering process of Web applications and various platforms,frameworks and development kits exist for the efficient imple-mentation of such systems. Concerning the modeling process,many of the published concepts try to merge traditional hyper-media modeling with techniques from the software engineeringdomain. Unfortunately, those concepts which capture all facets ofthe Web’s architecture become rather bulky and are eventuallynot applicable for a model-driven Web application development.Moreover, there is a need for frameworks which address both, themodeling process and the implementation task and allow a model-driven, semi-automatic engineering process using CASE tools.This paper outlines the DaVinci Web Engineering Frameworkwhich supports the modeling as well as the semi-automatedimplementation of Web applications. The DaVinci ArchitecturalLayer specifies a persistent, hierarchical GUI model and a genericinteraction scheme. This allows the elimination of the hypermediaparadigm, which turned out to be rather practical when buildingWeb applications.

Index Terms— web engineering, web application framework,model-driven web development, web application modeling

I. I NTRODUCTION

In 1989, when Tim Berners-Lee and his colleagues wereworking on the first drafts for a distributed hypertext system,they probably had no idea what the World Wide Web wouldlook like two decades later. While the number of registereddomain names and accessible resources on the Web wasincreasing rapidly, also the variety of programming languagesand technologies for Web page generation grew. Additionally,the latter one provoked an increase in the range of possibilitiesand applications on the Web. And as business models havearisen, making the Web a profitable market place, the dot-com era had been inaugurated. This was even more pushingthe evolution of the Web. Today the WWW is not merely anhuge information system hosting billions of documents, it canalso host distributed applications providing concurrent accessto users all around the world. Where browsers are acting asplatform-neutral containers for the applications’ graphical userinterfaces (GUI), the Hypertext Transfer Protocol provides asimple but effective communication layer. Moreover the Web

is becoming more and more ubiquitous. It is now accessiblefrom various kinds of mobile devices.

Ultimately, Web services do not even produce visible con-tent for human actors, instead they serve as communicationgateways between distributed, heterogeneous, and autonomousinformation systems. The current research activities in the fieldof semantic Web and semantic Web services [19] will continuethe evolution of the internet to a globally interconnected, partlyautonomous, functional network. This new era of the WorldWide Web is sometimes referred to as theWeb 2.0, a termintroduced by Dale Dougherty from O’Reilly, and Graig Clinein 2004.

With the growing importance of Web applications, therelevance of decent modeling techniques for such applicationsincreased. Most of the early websites and Web applicationswere built ad-hoc without any concept. This led to ratherbad code, bugs and poor re-usability of software components.By contrast to many other engineering disciplines, as forexample house building or car construction, the developmentof websites and Web applications really lacked of conceptualmodels and well-defined processes [29] resulting in the needfor an engineering approach. The development of a compre-hensive framework supporting the modeling process as well asthe implementation of Web applications is the matter of ourcontribution.

II. T ERMINOLOGY

Since there exist quite divergent interpretations for someimportant terms, a short definition will follow.

A. Website and Web application

The World Wide Web basically is a hypermedia system [4].So-calledresources(HTML documents, style sheets, images,movies, etc.) are dereferenced using global identifiers calledUniform Resource Locators(URLs). A websiteis a collectionof resources (e.g. Web pages) which are eventually hosted ana single server or directory belonging somehow together.

Compared to a website, aWeb applicationis not a linkedcollection of hypermedia resources in general. Actually, thepurpose of the original hypermedia paradigm is much lessimportant since thebehavioral aspect is dominating [24].Trying to intermingle hypermedia modeling with traditional

120 J. WEB. INFOR. SYST. 2 (2), JUNE 2006.c©TROUBADOR PUBLISHING LTD

software modeling can result in very bulky and often ineligiblyconcepts.

Where for some people interaction1 is the only differencebetween awebsiteand aWeb application[15], a more severelydefinition is probably given by Finkelstein et al. in [9]. Theirdefinition has also been adopted for this work. In DaVinci’scontext, a Web application is not just a set of Web pages,rather it is a piece of software withapplication logic andstate. "[...] this implies that it enforces the notion of a session,which differentiates it from the ordinary request-responseWeb paradigm" [9, Introduction]. Note that, according to thisdefinition a search engine’s front-end and even a Web serviceare not denoted to be Web applications. These are justWeb-based services, but no applications.

The fact, that a Web application has a specificbusinessstate is very important. And business state does not onlymean persistent objects (e.g. a registered user’s record, ora shopping cart containing items), furthermore the currentstate of the interaction – which can been seen analogous tothe navigational state within a website – is also part of theapplication state. The GUI of Microsoft Word, for instance,naturally has a state too which is stored in memory. The stateof a Web application normally is stored on the server insidea user-specific session context. However, rather often somepart of the application state is also stored at the client, forinstance when chaining information through hidden form fieldsor inside the query string of the URL.

B. Framework for Web applications and Web EngineeringFramework

A quite appropriate definition for a framework for Web appli-cations can be found in [27]:

"A Web-tier application framework [...] providingcommon application functionality such as dispatch-ing requests, invoking model methods, and selectingand assembling views. Framework classes and inter-faces are structural; they are like the load-bearingelements of a building, forming the application’sunderpinnings. Application developers extend, use,or implement framework classes and interfaces toperform application-specific functions."

Here, a framework is a set of software components. Thisframework at least must define a common scheme for userinteraction and the displaying of content and navigationalwidgets (the GUI). Having a generic interaction and viewscheme, the developer can concentrate on the actual applica-tion and does not need to model and implement fundamentalfunctionality. That is why a rather common pattern used inmany related projects is theModel View Controlerpattern[27, Ch. 11] (MVC, originally introduced in Smalltalk-80).The separation of themodel and theview component is ofgreat importance. It does not only bring order into the code,it allows to change the look-and-feel and application logicindependently. The MVC pattern is the basis for many Webdevelopment frameworks (e.g. Struts, Java Server Faces [1],Ruby on Rails [13], Microsoft’s ASP.NET, etc.). The patternwill be discussed in more detail in section V-B.

Fig. 1. evolution of Web engineering

However, the DaVinci approach is not just a set of softwarecomponents, it is more than a Web application framework.The DaVinci Web Engineering Frameworkconsists of threecomponents, theDaVinci Architectural Layer, the DaVinciModeling Framework, and theDaVinci Runtime Library. It is acomprehensive framework providing an architectural concept,modeling techniques and an API (the runtime library). Thethree components will be explained in detail in section VI.

III. W EB ENGINEERING

It is a noticeable fact, that over time on the one hand,static hypermedia resources where more and more asking forfunctional enrichment (application logic) and on the otherhand, traditional software approached the hypermedia domainto benefit from its features. Figure 1 shows the migration of theWeb authoring and software engineering domains, resultingto the Web engineeringdomain. Many of today’s businesssoftware products integrate Web-based front-ends to the mainapplication server (e.g. mySAP Enterprise Portal or OraclePeoplesoft’s Supply Chain Management software).

Today, there exist numerous scientific publications andjournals (e.g. theInternational Journal of Web InformationSystemspublished by Troubador, UK, theJournal of WebEngineering, etc.) and also some books (e.g. [17], [28], and[7]) about Web engineeringand modeling for Web applica-tions. Having sound models can also provide the possibilityto build CASE tools for (semi-)automatic generation of Webapplications [10], [20], [8].

The Web engineering process will not be covered in deepin this context. Instead, some related work will be presentedin the next section.

IV. RELATED WORK

Obviously many scientific approaches targeting Web engineer-ing try to combine already existing models for hypermediadesign (that is for example the Dexter model [12], HDM[11] or RMM [16]) with traditional software engineeringtechniques (where ER-models and UML are leading concepts).

LANGEGGER ET AL.: DAVINCI – A MODEL-DRIVEN WEB ENGINEERING FRAMEWORK 121

Target Zone

OOHDM [7]

Mo

dellin

g L

an

gu

ag

e S

up

po

rt

for

Fu

ncti

on

al A

rch

itectu

re

Modelling Language Support

for Information Architecture

WebML [6]

Conallen [11]

Koch [5]

HDM-lite [8]

W2000 [9]

Existing Modelling Approach Gap Analysis

HDM [3]

RMM [4]

UML [10]

Li [12]

Low High

Lo

wH

igh

Fig. 2. Concepts are missing the target domain (from [18]).

For instance OOHDM [26] or W2000 [3] try to combinehypermedia modeling with database and object-oriented soft-ware design methods. By contrast, the concept proposedby Jim Conallen [7] strongly originates from the softwareengineering domain and tries to cover the whole modelingprocess for Web applications with UML and a properWebApplication Extension. TheWeb Modeling Language(WebML[5]) rather descends from the hypermedia modeling domainand provides a quite extensive common set of patterns andmodels for database-driven websites. Some of the conceptsare also outlined in Figure 1.

However, the migration of hypermedia models and tra-ditional software models may be cumbersome as alreadydiscussed in [18]. Figure 2 (taken from [18]) shows variousmodeling concepts aligned in a two-dimensional diagram. Thehorizontal axis denotes support for theinformational aspect,while the vertical axis means support for thefunctionalaspect.A pure Web information system based on the hypermediaparadigm has very high informational but a rather low func-tional aspect. By contrast, a traditional application would havea high functional aspect and a low informational one. Andfinally, Web applications often require a high degree of both,functional as well as informational aspect.

Another related approach [25] has been introduced formodeling Web information systems(WIS), which require ahigh informationalaspect but often also need behavior. In thiswork, media objects which have similar content have beenintroduced. These objects can havelocal operationsbeingperformed by the user beside normal navigation. The objectsare linked forming a directed multi-graph (thestory space).With a formal story algebrathe navigational model can bedefined and checked.

Otherwise it may be argued that Web applications do not

really need much informational aspect. The point of viewis closely coupled to the interpretation of the termWebapplication. In the definition of section II-A the mentionedargument is true to some certain extent if a Web applicationis regarded as being more similar to a traditional applicationrunning in a browser than to a set of Web pages. In the contextof DaVinci this is true and therefore, theDaVinci ArchitecturalLayer eliminates the hypermedia paradigm.

Beyond the bottom line some existing concepts seem to berather complete and applicable to a wide range of differentscenarios (especially WebML and Jim Conallen’s UML-basedconcept). But unfortunately most concepts do not provideany development frameworks (common architecture and APIs)or even CASE tools which use the investigated concepts inpractice. The founders of WebML, Piero Fraternali and StefanoCeri, developed a tool called WebRatio [2] which seems to berather useful when building database-driven Web applications.They provide a CASE tool for building sites based on fun-damental components (entities, relationships, pages, layouts,etc.) at a very high abstraction layer.

A. State of the art technologies

Beside the modeling concepts, there are many popular tech-nologies used for the development of Web applications2. Onthe one hand there exist different interpreted programminglanguages (Perl, PHP, Phyton, Ruby, etc.) commonly usedfor the creation of dynamic web pages, but also for smaller-sized Web applications3 and on the other hand there arevarious compiled languages like Java for example or the .NETframework from Microsoft.

Since Java is one of the most frequently used environmentsfor building business software it is also very popular forbuilding Web applications. However it is normally required tobuild on-top of further APIs since the fundamental technology(Servlets and JSP) lacks on high-level concepts. This seams tobe a leeway to Miscrosoft’s ASP.NET to some certain extent.The DaVinci Architectural Layershould act as a missinglink between the Servlet API and the Web application andformalize the interaction process. This formalization is re-quired to enable CASE tools and semi-automatic development.Note that the architectural concept is open and not limited toJava implementations only. TheDaVinci Runtime Libraryisavailable for Java for the moment.

B. Motivation for DaVinci

On the one hand formal models should provide the possibilityto plan and design Web applications and on the other hand,tools and frameworks must be available to support the develop-ment process. Most frameworks do not combine modeling andimplementation. This is possibly proven by a missing adoptionof some scientific frameworks in industry.

The aim of the DaVinci project is to provide a comprehen-sive engineering framework for Web application developers.There is a fundamental difference between a hypermedia sys-tem and Web applications. As a result the complete applicationcan be modeled with software engineering techniques andbecause UML seams to be a very convenient concept, DaVinci


fully relies on UML. This assumption is of big importance.UML has already proven its strength for traditional object-oriented software development and should therefore be thebasis of theDaVinci Modeling Framework.

Although the future goal of DaVinci is to provide furtherCASE tools, it is assumed, that an application’s code is stillmanaged by the developers themselves. CASE tools shouldhelp where they are suitable. Adding reverse-engineeringcapabilities and the integration in well-established IDEs (e.g.Eclipse) are desirable steps for future enhancements.

V. COMMON CHALLENGES

Common challenges when building Web applications are theuser interaction and the composition of the response which isthe view in terms of a MVC-based GUI. User interaction andview composition are actually closely coupled.

A. User Interaction

The traditional way to integrate interaction in Web applicationsis using POST attachments or thequery string4 within an URLto tell the server what it needs to know. In our point of view,an URL does not need to refer to a resource like it is normallythe case in hypermedia systems. The URL can also representan interaction call instead, causing some change inside theapplication. That is why the termfunctional URLis stressed,which is an important concept in theDaVinci ArchitecturalLayer.

In most web applications, the application state is storedinside a session context and only a so-calledsession IDisstored on the client side. However, it is also possible topreserve all the information about the application state insidesub-sequent request URLs. Each new request will then re-post the required data5. As a result, there are two types ofinteraction using URLs:

1) interactions, which can be reproduced with a singlerequest URL because the URL includes all the requiredinformation that defines the application state

2) interactions which can only be reproduced calling asequence of consecutive requests again, finally leadingback to a previous state6.

When viewing a Web page as a result of a type 1 interaction,it can be saved as a bookmark and processed by searchengines. Type 1 can be found at news sites and database-driven websites, but hardly at Web applications. Unfortunatelytype 2 interactions are usually the case within Web appli-cations. It can be argued that search engines should neverprocessviews of Web applications anyway. Concerning themissing bookmark-awareness, the application could providesome functionally to be able to recover a previous state of theuser’s session when coming back again later (assuming thatthe session ID still exists on the client).

Request-oriented approaches:It can be said, the defaultway to realize user interaction is by requests controlled by thedeveloper of the application. This means, that the developermust be aware of the correct composition offunctional URLs.This is also the case for DaVinci. Within DaVinci such an URLis called action. Any action has to be modeled as part of a

model class using UML. Upon execution an action is mappedto the appropriate model’s instance method using reflection.

Event-oriented approaches:An interesting approach hasbeen introduced by K. Nguyen and T. Dillon [21] as well asin ASP.NET. They both use events to control user interactions.When the request is received from the server’s API, it isdelegated to the appropriate piece of code where a previouslydefined callback handler will take over the request. Thisapproach seams to be very convenient for developers, sinceit is very similar to traditional GUI programming (e.g. JavaAWT/Swing).

B. Composition of views

In MVC-based graphical user interfaces theview is decoupledfrom the rest of the application. The pattern allows greatflexibility and is therefore very useful for building Webapplications too. Compared to traditional applications likeMicrosoft Word for example, a Web application’s view hasto be (re-)built using HTML (normally) after each request.The view is always generated by the HTML response. Thisrequires some concepts for cascading sub-views inside thewhole window. Any application has different dialogs andcontent panes. Java Server Faces do address this task andconcerning ASP.NET there is already some minor support forthis task.

In the context of a DaVinci application the traditionalapproach of windowing toolkits is followed and a dynamicGUI tree model is introduced. The state of the GUI modelcan be changed during runtime and after each request, theGUI tree is rendered and the response code is produced.

C. Client-side Code

Some modeling approaches even include modeling of client-side code (e.g. Jim Conallen). Unfortunately this task becomesvery complex. On the other hand, some sort of client-side codeis often needed because the set of widgets is very limitedwith HTML. With ASP.NET client-side code is capsuled inindependentWeb Controlswith well-defined input and outputproperties and behavior. For example a calender control hasas input an active date to start from, a pre-defined behavior(allows to browse and select different dates), and as outputit returns the selected date. The output can be sent back tothe server like a single string (date) value. If more interac-tion is required (e.g. DCOM, RMI), the client-side must bemodeled with techniques for distributed software components(concurrency may require locking mechanisms, etc.). This isa complex task but can be done with tools for traditionalsoftware engineering.

VI. T HE DAV INCI WEB ENGINEERING FRAMEWORK

DaVinci is a comprehensive framework for model-driven Webengineering. It is neither solely a modeling framework nor anarchitectural framework or library. It is designed as a completetoolkit which consists of three parts: theDaVinci ArchitectureLayer, the DaVinci Modeling Frameworkand the DaVinciRuntime Library(see Figure 3).


Fig. 3. DaVinci Web Engineering Framework

DaVinci Architectural Layer:This is an additional layer inthe application stack (Figure 4, section VI-B) which definesthe basic concept of the DaVinci approach (view trees and thegeneric interaction scheme) and adds extensions essential forWeb applications. It can be seen as a missing link between theWeb server API (respectively the Servlet Container in a Javacontext) and the Web application.

DaVinci Modeling Framework:This part specifies a com-prehensive, UML-based modeling framework for buildingDaVinci Web applications. It does not define a strict modelingprocess, since the development process will become very simi-lar to traditional software engineering. It actually shows how touse UML diagrams accordingly, especially when building theGUI (view trees and interaction spots, as explained in sectionVII-C). The DaVinci Modeling Frameworkwill provide arich set of CASE tools which will facilitate and automatethe modeling process. There is already a simpleView StubsGenerator for the Java implementation which generates allviews (JSP files for example) based on a GUI configurationand skeleton templates (see Figure 11).

DaVinci Runtime Library: The runtime library is a Javaimplementation of the architectural layer and is required forrunning DaVinci Web applications.

A. Characteristics

The basic idea of DaVinci was to eliminate the classicalhypermedia paradigm and to inject an additional layer betweenthe Servlet Container and the application (see Figure 4).The DaVinci Architectural Layerprovides concepts which aremissing in the Servlet API but essential for Web applications.While other projects (e.g. Java Server Faces or Struts) have nocentral GUI defined, DaVinci defines a dedicated GUI modelas well as an interaction process. Within DaVinci documents(or more accuratelyviews) are generated andtransientalways.

These four important aspects outline the main characteristicsof the DaVinci Web Engineering Framework:

• A Web application is not just a set of Web pages, itis rather a piece of software with application logic andbusiness state. Thus, the notion of a user session isfundamental.

• The view state is part of the session. It is based on ahierarchical view tree model with switchable sub-trees.This allows to change the GUI during the session, butalways keeps the GUI in a certain, deterministic state.

• Instead of referring to documents, URLs are referring toactions that can be invoked. When modeling an appli-cation with DaVinci, the GUI including all interactionspots (buttons, forms, etc.) is well defined allowing theincorporation of CASE tools.

• Application logic is modeled using traditional methodsand independently of the views.

B. DaVinci Architectural Layer

As described in section IV-A, there exist numerous differenttechnologies for building server-side dynamic web pages.Most of these technologies are designed for Web informationsystems in general and not especially for the kind ofWebapplications defined in section II. Thus, in most cases ageneral concept for the interaction, application logic andpresentation is missing. Many modeling concepts focus onthis task, formulating the conceptual, the navigational, and thepresentation layer [9].

To fill the gap between the Web server API (e.g. JavaServlets) and the Web application DaVinci adds an additionallayer to the application stack (Figure 4). HTTP is the basisprotocol which is used for communication between the Webserver and clients. Therefore the Web server implements HTTPand related protocols (SSL, etc.). The Servlet Container sitson-top of the Web server and provides a common server-sideprogramming interface (Java Servlet API and JSP in this case).The DaVinci Architectural Layerdefines theview tree model,the interaction process and adds further extensions. Finally,a DaVinci Web application is built on-top of the new layer.The MVC Model 2 pattern is the basis for the framework:viewtreesact as a sound GUI model which is statically pre-defined,but dynamic during runtime.

Figure 5 shows the interaction process of a DaVinci-basedWeb application. In general, a Web application consists ofa server-side application logic and a graphical user interface(GUI, can also be textual only). Although application logic canbe moved onto the client-side too (e.g. using Scripts, ActiveX,Applets, etc.), the server-side part will always be the coreof the application. Client-side code (see section V-C) mostlyaddresses minor and support functionality with defined inputand output parameters (e.g. advanced GUI widgets, DHTML,Web Controls in ASP.NET, etc.).

The GUI provides various interaction spots like links andHTML forms which can invoke further HTTP requests. Arequest can change the application logic and also the stateof the GUI, which is part of the application state. At theend of a request the GUI is rendered again and sent back asresponse to the client. If the user did not invoke any action (e.g.the framework can detect a simple page reload), nothing willhappen but the GUI will be rendered again. While a changein the application logic can simply meanselect a differentdocumentand the GUI can be seen as adocument renderedas HTML output, a change in the application logic can alsobe the invocation of a Web service while the GUI simplyshows the SOAP response. The first example would be similarto a traditional HTTP request which serves static documentresources. Thus, if some kind of hypermedia model is required


Fig. 4. DaVinci application stack Web Applicationuser’s view system viewdatabasesand legacysystemsapplication logicpersistentobjects rightsmanagementUI controlerexecuteactionsGUIrender GUI(content + interaction spots)interactuser

Fig. 5. interaction scheme of a Web application

within a DaVinci Web application it can be modeled inside theapplication logic again.

Hierarchical GUI tree: A significant feature is the prede-fined hierarchical GUI-tree, which defines the complete set ofviews and even the possible interaction spots on each view inthe application at once. A single Web page is composed whenrendering the current state of the view tree. This concept willbe outlined in more detail in section VII-C.

Functional URLs: The DaVinci Architectural Layerspec-ifies a specific URL scheme (Listing 1) which maps URLsto actions. Any incoming request is processed by the frontcontroller (MVC Model 2), which executes the correspondingmethod using reflection. Instead of using the query string, thepath info7 of an URL is used to refer to a specific action tobe executed on the server. Various parameters required by anaction can follow in the URL separated by slashes. This canbe compared to a traditional function call in programminglanguages, with the difference that it is executed over theWeb (Note that a Web service call is similar to this schema).The function call returns the response of the HTTP request,which is an HTML document, an image, or various data ofany other MIME type (by contrast to the SOAP response ofWeb services). In case of HTML, the GUI tree is renderedresulting in the current state of the application’s GUI.

Interaction process:Any request received by the DaVincifront controller servlet will lead to an action call on the

URL = " h t t p : / / " h o s t " : " p o r t " / d a v i n c i " [ " / " Ac t ion ]Ac t ion = package " . " c l a s s " . " method [ " / " Pa rame te r ]Pa rame te r = paramValue [ " / " Pa rame te r ]

Listing 1. DaVinci URL scheme syntax

appropriate model instance. As described in section VI-Binside DaVinci different model instances reside forming theapplication state as well as providing business logic. In afurther step, these models can link to other libraries or to anadditional application server to enable multi-tier architectures.

A common issue when developing dynamic Web pages is,that parameters which are transmitted to the server (eitherwith GET or POST) always come as string values (e.g. theselections of multi-list boxes have to be deserialized first,etc.). To automate this process, reflection is used to parse andconvert data specified inside the path info or sent using HTTPPOST. Basically a DaVinci action can define two kinds ofparameters: path info parameters and POST parameters (usedfor submitting form data and MIME-encoded binary files).

For example a request tohttp://somehost/davinci/

demoapp.Navigation.navigateTo/homepage

will execute the methodnavigateTo of a session-specificinstance of the modeldemoapp.Navigation . Because themethod signature ofnavigateTo defines the incoming pathparameterstate of type String , the framework will declarea String variablestate and assign the value"homepage"toit. This process is done using the Java reflection mechanism.

The DaVinci Architectural Layerspecifies a common frontcontroller interface to the DaVinci kernel, which can beimplemented in different ways to support different protocolsin addition to HTTP.

Models – the building blocks of the application logic:The main building blocks of the application logic aremodels.Models are just classes which implement all the actionsdefined by the view’s interaction spots (section VII-D). Eachinteraction spot (which is afunctional URL) refers to a specificmodel’s method. Reflection is used to map a functional URL tothe corresponding method signature. All interaction spots arealso defined in the view tree descriptor file (see section VII-Cand Listing 2). Like any other classes, models can aggregatedata structures, bind data sources, use additional libraries, andmodify the GUI tree.

The second major task of a model is to provide data for


at.davinci

ui

http

text

control

accesshttp

socket

model

taglibs.standard casetoolsutil

Fig. 6. DaVinci implementation for Java

views. Therefore, theDaVinci Runtime Librarydefines an ab-stract model class which defines the abstract methodgetView-Data(String view, String name, Class type). This method issupposed to return the appropriate data for the requesting viewnode.

Implicit access control:When using the MVC Model 2 pat-tern, the integration of an inherent rights management systemis very easy. Access control is possible down to the action levelin DaVinci. For each single action it is possible to define whomay execute the action and who does not. DaVinci uses thealready existing HTTP Authentication schema supported bymost of the web browser’s used today. When a user wants toexecute an action requiring additional rights, the login dialogwill automatically appear. After specifying correct credentialsthe action is executed at once and the user can continueworking. Otherwise, he will be informed about missing accessrights or wrong credentials.

C. DaVinci Modeling Framework

The modeling framework specifies the UML diagrams to beused for which task and process. The models are not coveredin detail now, instead in section VII an application scenariowill be demonstrated also showing how to model applyingthe DaVinci Modeling Framework. Generally spoken, apartfrom the GUI model, software engineering patterns and UMLdiagrams will be applied which also opens the possibility tomodel the application with already existing CASE tools builtfor software engineering [23].

D. DaVinci Runtime Library

The DaVinci Runtime Libraryis outlined in Figure 6. TheFigure shows the main packages of the API built on top of theServlet API. The main classes involved are show in Figure 7.The classDaVinciKernel is the core of the implementationpulling together all the components. DaVinci can either beintegrated in an existing Webserver (e.g. Apache Tomcat) orrun as an independent server daemon.

E. Controllers

Since the interaction process shown in Figure 5 needs notnecessarily be based on HTTP and can be based on otherprotocols, the framework’s core was implemented in an openmanner. The framework can have different controllers thatdock to the core (currently there is aHttpController and asimple SocketController used for connecting via telnet).Adding some kind of aPOP3_Controller would make itpossible to execute DaVinci actions upon incoming E-Mailsfor example. DaVinci can therefore also be used for a commonframework for client-server applications, although initially ithas been developed for Web applications.

When aController as for example theHttpController

receives an incoming interaction (a request to afunctionalURL), it parses the URL to find out, which model instanceand method to call. EachDaVinciSession contains itsown instances of all models8. All models of the application(e.g. aShoppingCart ) must extendAbstractModel and beregistered at theModelManager . Thus, the DaVinci kernel cancreate and initialize new sets of models when new sessions arestarted.

The Controller uses an instance of theAction classto handle requests. According to the signature of the methodto call, the incoming path info and HTTP POST parametersare converted. This is done by theSimpleTypeCaster , butcustom type casters can be implemented for custom types.For instance, the already implementedHttpTypeCaster canparse form fields and instantiate appropriate Java objectsfor text areas, list boxes, and also file uploads (similar toASP.NET’s Web Controls).

Finally the method invocation takes place and theController calls aViewTreeRenderer which generates theresponse.

F. View tree rendering

Concerning the generation of views in the MVC context,there can be multiple implementations for the commonViewTreeRenderer interface. Normally, the view is gen-erated as an HTML page. But different output formatswould be possible using different renderers. For exam-ple, in conjunction with theSocketController , a simpleConsoleRenderer is also available. For an output in HTMLthe JSPViewTreeRenderer is used normally.

Instead of describing each one of the classes and artifactsin Figure 7, the interaction process will be explained whilereferring to the most important artifacts.

VII. D AV INCI IN PRACTICE

To demonstrate the framework by example, the followingscenario is defined. A simple Web application will be createdwhich could be configured as the personal starting page inone’s favorite Web browser. The application should allowto store a list of personal links (bookmarks) and addresses.Furthermore the application should start with a configurablehomepage whose URL is stored among the other links. Theapplication should provide some navigation so that the user


+renderGUI( s : DaVinciSession, r : JSPViewTreeRenderer )

+getAccessControlManager() : AccessControlManager

+getConfigurationLoader() : ConfigurationLoader+getApplicationContext() : ApplicationContext

+getSessionManager() : SessionManager

+getModelManager() : ModelManager+registerController( c : Controller )

+executeAction( a : Action )

+boot( baseDir : String )+shutdown()

DaVinciKernel

HttpController

+doPost( q : HttpServletRequest, r : HttpServletResponse )+doGet( q : HttpServletRequest, r : HttpServletResponse )

AbstractModel

+getViewData( view : String, name : String, type : Class )+cleanup()+init()

Controller

+setKernelReference( k : DaVinciKernel )+shutdown()

javax.servlet.http

HttpServletResponse

HttpServletRequest

HttpServlet

: Java Webserver

: HttpController

AccessControlManager

JSPViewTreeRenderer

ConfigurationLoader

ParameterSignature

ViewTreeRenderer

ApplicationContext

MethodSignature

SocketController

SessionManager

ShoppingCart

DaVinciSession

Action

-reqParameters

ModelManager

ViewTreeNode

application models (e.g. shopping cart)

create action upon incoming request

<<use>>

<<use>>

<<use>>

0..*1

1..*

1

1..*

<<register>>

1..*

0..*

Fig. 7. Class diagram of the DaVinci core

can switch betweenhomepage, links andaddressbook(whichwill further be calledmodules).

This sample application has been released at Source-Forge.net under the GNU General Public License combinedwith Version 1.0 of theDaVinci Runtime Libraryand can bedownloaded from the project homepage at http://davinci4j.sf.net.

The completeWeb engineeringprocess, including planning,workflow and team management, testing, deployment, etc. willnot be covered here. Many concepts mentioned in sectionIV have drawn particular attention to this. Instead the mostimportant steps involved when modeling a DaVinci Webapplication will be shown (defining the appropriate models,the view tree, and interaction spots).

As part of theDaVinci Modeling Framework, the followingworkflow is suggested (with appropriate UML concepts inbrackets). Note again, that modeling is done using traditionalsoftware engineering tools rather than hypermedia concepts.

1) requirements analysis* (use cases, [22])2) find required entities and components (implementation,

class diagrams)3) model the application logic (class, sequence, activity

diagrams, state charts)4) design the views and model the GUI tree (2D layout

sketches, class diagram)5) add required interaction spots (add to GUI tree class

diagram)6) generate code stubs and facets with CASE tools (more


tools will be required)7) build and deploy all components8) test and improve* (using eXtreme programming tools

[14])

Steps marked with an asterisk (*) will not be covered here.Since the scenario is already given and quite simple step 1 isstraight forward. Regarding step 8, there exist lots of literatureabout software engineering processes (waterfall model, Blum’sEssential Model, etc. [30]) and extreme programming.

A. Finding required entities and components

This step is straight forward too. There will be two entitieswithout references in-between,link andaddress. For the demoapplication no database will be connected, instead all linksand addresses are stored using hashtables as members of theaccording models.

Usually, Entity Relationship diagrams [6] would be used tomodel the required data entities. Optionally some middlewarefor an object-relational mapping (e.g. Hibernate or JDO)could be applied and of course it is possible to use a multi-tier architecture and separate the database layer from theapplication.

Software components are the large building blocks. Theyare used to model a coarse-grained view of the overall system.Regarding software components, for this simple demonstrationjust one component is sufficient, which is implemented ina Java package calledhomebase. Normally an applicationconsists of different components statically or dynamicallylinked together. Some applications will use multiple concurrentprocesses and messaging APIs. The DaVinci framework doesnot restrict the developer in any way.

B. Modeling the application logic

The DaVinci Architectural Modeldefines a special kind ofobjects which are calledmodels (section VI-B). Modelsrepresent the major building blocks of the application andare used to model the fine-grained application logic. Eachmodel has its own methods and properties, must extend theAbstractModel class and implement thegetViewData -method. While other public methods correspond to the interac-tion spots of views, properties can refer to data in views. Doingso, models also represent the current state of the application(or more precisely spoken, of a certain user session).

In this example there are three models:Navigation ,Addressbook , and Links (shown in Figure 8). The Nav-igation model is only used for the navigation between thethree modules and would be extensible. The currently selectednavigation item is stored within this model. The methodnavigateTo(Stringstate) is called when the user se-lects another module. The two other models provide variousmethods for creating, editing and deleting links respectivelyaddresses. Both models store the corresponding entity recordsas beans inside aLinkedHashMap . Note that the records willbe lost, when the session is closed because no database is usedto persistently store them.

<<view>> mainframe

<<view>> header (html head, not visible)

<<view>> navigation_bar

<<switch>> body

<<view>> footer

<<view>>homepage

<<view>> addressbook

<<view>>links

Fig. 9. draft of the GUI, flat

C. Designing views and modeling the GUI tree

Traditionally GUI widgets have been regarded separately fromthe display of content. But regarding Web applications, theGUI merges with the display of content. Hyperlinks areactually part of the content. Thus, the graphical user interfacedoes both, present content and provide interaction spots insideparts of the content. Hyperlinks are interaction spots insidedocuments on the Web. For example, as part of a GUI shownin a window frame or on the full screen, there are areas withinformation only and areas which act asinteraction spots(anavigation, menu or as already explained, concerning Webapplications: hyperlinks and HTML forms).

We suppose to start the GUI model with simple sketches(Figure 9) of single views. This is rather helpful becausethe user should be the focus first, and the integration offeatures that are technically possible but practically uselesscan be better avoided this way. All views are structured in thehierarchical view tree model in a second step (Figure 10). JimConallen calls thisUser Experience Model(UX-Model) in [7,Ch. 9].

It is useful to draw abstract sketches first omitting detailsand then drawing fine-grained sketches each sub-views. Thecomplete view hierarchy of large GUIs would be to complexto show in one sketch. Therefore Figure 9 does not show thesub-trees of the three modules. The flat view also shows theposition of the view elements in the window. In the middle ofthe window there is the page’s body. The content of the bodycan either be the homepage, the address book or the linksrepository. The interaction spots provided by the navigationon the top will invoke a change in the GUI tree and switchthe page body accordingly. These sketches are the only modelsnot being part of UML because there is no appropriate diagramto do that. Moreover it is a graphical design task that shouldbe done by the GUI designer.

The corresponding hierarchical GUI tree is modeled usingUML class diagrams in Figure 10. The specification of theview tree is stored in an XML file (view tree descriptor) asshown in Listing 2. First, anymodel must be declared to


<<Model>>

Addressbook

-currentRecord : AddressBean

+saveRecord( firstName : TextField, lastName : TextField, email : TextField )

+sendEmail( id : int, sbj : String, msg : String )+composeEmail( id : int )

+deleteRecord( id : int )

+showRecord( id : int )+editRecord( id : int )

+createRecord()

+cancelEdit()

AbstractModel

+getViewData( view : String, name : String, type : Class ) : Object+cleanUp()+init()

<<Model>>

Links

-currentRecord : LinkBean-homepage : LinkBean

+saveRecord( url : TextField, isHomepage : CheckBox )

+deleteRecord( id : int )+editRecord( id : int )

+createRecord()

+cancelEdit()

NavigationBean

-currentItem : NaivgationItemBean

+getCurrentItem() : NaivgationItemBean+setCurrentItem( currentItem : String )

<<Model>>

Navigation

+navigateTo( state : String )

NaivgationItemBean

-name-key

-url

AddressBean LinkBean

0..* 0..*

1

0..*

Fig. 8. models and other classes for the demo application

be able to reference to it later when specifying a view node(attributemodel). The reference is required for acquiring datafrom models.

The dynamical aspect of a view tree can be achieved byspecial switch nodes. A switch node can switch betweenvarious underlying sub-trees in the GUI model and perform achange in the GUI when the tree is rendered at the end of eachrequest. In fact, this GUI tree model has been derived fromthe scene-graph model, which is used in computer graphics(e.g. AutoCAD, Java3D API).

Each session of the Web application starts with an initialconfiguration of the complete GUI tree9. All switch nodes areset to an initial underlying sub-tree (private attributedefault ,see Figure 10). During the session the GUI tree can be alteredthrough changingswitch nodes. A very important advantageis, that from the user’s point of view, navigational paths (clickpaths) in the application are kept very short. That is becausedeeper switch nodes are not changed when a node at a higherlevel in the tree is changed. Changing back the higher switchnode will exactly bring up the previous view state again.

When using aJspViewTreeRenderer , each view node inFigure 10 can have an associated JSP file (private attributejsp ) which will be parsed and included into the response’soutput if it is visible in the current tree state. Some viewnodes also have public parameters. Any public parameter

refers to data provided by a model instance. For exam-ple the view nodemainframe.body.addressbook.right_

canvas.edit_record 10 has a public attributeaddress andbecause the modelAddressbookis associated with this view,the framework will fetch the data fromAddressbook be-fore rendering the JSP. To be more precisely, the functiongetViewData of the Addressbook model will be invokedbefore rendering the view. This is sort of apull strategyforsupplying data to view nodes. It is possible to change all theview files and provide different output channels for variousdevices (e.g. PDAs or cell phones) without changing any otherparty of the Web application.

D. Adding interaction spots

To complete the GUI model interaction spots are insertedinto the GUI tree. This is done by adding methods to allview nodes that provide interaction spots. A method in theview tree model stands for an interaction spot and furtherrefers to a model method. For example the viewmainframe.

navigation_bar provides some buttons for selecting themodule. In fact, the method will call the API methodswitchNode("mainframe.body",findItem(state)) onthe instance of the viewTree to change the switchmainframe.

body . Therefore it has a methodnavigateTo which willchange the currently selected module. All interaction spots


Addressbook

-currentRecord : AddressBean

+saveRecord( firstName : TextField, lastName : TextField, email : TextField )

+sendEmail( id : int, sbj : String, msg : String )+composeEmail( id : int )

+deleteRecord( id : int )

+showRecord( id : int )+editRecord( id : int )

+createRecord()

+cancelEdit()

<<view>>

edit_record

-jsp : String = /addressbook/edit_record.jsp+address : AddressBean

+saveRecord()+cancelEdit()

<<view>>

mailform

-jsp : String = /addressbook/mailform.jsp+address : AddressBean

+cancelEdit()+sendEmail()

<<view>>

addressbook

-jsp : String = /addressbook/canvas.jsp

<<view>>

record

-jsp : String = /addressbook/record.jsp+address : AddressBean

<<view>>

list

-jsp : String = /addressbook/list.jsp

+selectedAddress : AddressBean+addressList : Map

+composeEmail()

+createRecord()

+deleteRecord()

+showRecord()

+editRecord()

<<view>>

links

-jsp : String = /links/canvas.jsp

<<view>>

navigation_bar

+navigation : NavigationBean-jsp : String = /navigation.jsp

+navigateTo()

<<view>>

homepage

-jsp : String = /homepage.jsp+homepage : String

<<view>>

mainframe

-jsp : String = /mainframe.jsp

<<switch>>

body

-default : String = homepage

<<view>>

header

-jsp : String = /header.jsp+title : String

<<viewtree>>

main_window

-default : boolean = true

<<switch>>

right_canvas

-default : String = record

<<view>>

footer

-jsp : String = /footer.jsp

<<use>>

<<use>>

<<use>>

Fig. 10. GUI tree including view data and interaction spots

point to functional URLsusing the DaVinci URL schemeexplained in section VI-B In Listing 2 the models, theiractions (public Java methods) and interaction spots of views(references to defined actions) have been already added.

Where – or more precisely – on which x/y position theseinteraction spots are actually placed in the views is not definedhere. This is part of the layout process which will not be

covered now.

E. Generate code stubs and facets with CASE tools

At the moment, support for CASE tools is still weak.There is a simple tool which allows the generation of viewstub files from an XML view tree descriptor file. But, after


<viewTree name=" main_window "d e f a u l t =" t r u e ">< a l l o w D e f a u l t r o l e s =" g u e s t " / >

<model c l a s s =" demoapp . N a v i g a t i o n ">< a c t i o n name=" nav iga teTo " / >

</ model ><model c l a s s =" demoapp . Addressbook ">

< a c t i o n name=" showRecord " / >< a c t i o n name=" e d i t R e c o r d " a l l ow =" admin " / >< a c t i o n name=" d e l e t e R e c o r d " a l l ow =" admin " / >< a c t i o n name=" c r e a t e R e c o r d " a l l ow =" admin " / >< a c t i o n name=" saveRecord " a l l ow =" admin " / >< a c t i o n name=" c a n c e l E d i t " / >< a c t i o n name=" composeEmail " a l l ow =" e d i t o r " / >< a c t i o n name=" sendEmai l " a l l ow =" e d i t o r " / >

</ model ><model c l a s s =" demoapp . L inks ">

< a c t i o n name=" e d i t R e c o r d " a l l ow =" admin " / >< a c t i o n name=" d e l e t e R e c o r d " a l l ow =" admin " / >< a c t i o n name=" c r e a t e R e c o r d " a l l ow =" admin " / >< a c t i o n name=" saveRecord " a l l ow =" admin " / >< a c t i o n name=" c a n c e l E d i t " / >

</ model >

<view name=" mainframe " f i l e =" / mainframe . j s p "><view name=" heade r " f i l e =" / heade r . j s p ">

< d a t a name=" t i t l e " model=" demoapp .N a v i g a t i o n " t ype =" j a v a . l ang . S t r i n g " / >

</ view ><view name=" n a v i g a t i o n _ b a r " f i l e =" / n a v i g a t i o n .

j s p ">< d a t a name=" n a v i g a t i o n " model=" demoapp .

N a v i g a t i o n " t ype =" demoapp . beans .Nav iga t ionBean " / >

< a c t i o n r e f =" demoapp . N a v i g a t i o n . nav iga teTo "/ >

</ view >< s w i t c h name=" body " d e f a u l t =" homepage ">

<view name=" homepage " f i l e =" / homepage . j s p "model=" demoapp . L inks ">

< d a t a name=" homepage " model=" demoapp .L inks " t ype =" j a v a . l ang . S t r i n g " / >

</ view ><view name=" add ressbook " f i l e =" / add ressbook

/ canvas . j s p " model=" demoapp . Addressbook">

<view name=" l i s t " f i l e =" / add ressbook /l i s t . j s p ">

< d a t a name=" a d d r e s s L i s t " model="demoapp . Addressbook " t ype =" j a v a .u t i l . Map" / >

< d a t a name=" s e l e c t e d A d d r e s s " model="demoapp . Addressbook " t ype ="demoapp . beans . AddressBean " / >

< a c t i o n r e f =" demoapp . Addressbook .showRecord " / >

< a c t i o n r e f =" demoapp . Addressbook .c r e a t e R e c o r d " / >

< a c t i o n r e f =" demoapp . Addressbook .e d i t R e c o r d " / >

< a c t i o n r e f =" demoapp . Addressbook .d e l e t e R e c o r d " / >

< a c t i o n r e f =" demoapp . Addressbook .composeEmail " / >

</ view >< s w i t c h name=" r i g h t _ c a n v a s "d e f a u l t ="

r e c o r d ">[ . . . ]

Listing 2. GUI descriptor file (XML)

<%@ page con ten tType =" t e x t / h tml " %><%@ t a g l i b u r i =" h t t p : / / p h p d a v i n c i . s f . n e t " p r e f i x =" d "

%><html >

<head><d : i nc lude > heade r </ d :i nc lude >

</head><body>

< t a b l e he igh t="100%" width ="100%" border =" 0 "c e l l s p a c i n g=" 0 " ce l l padd ing=" 0 ">

< t r >< t d he igh t=" 60 " v a l i g n =" midd le " a l i g n =" l e f t ">

<d : i nc lude > n a v i g a t i o n _ b a r </ d :i nc lude ></ td >

</ t r >< t r >

< t d v a l i g n =" top "><d : i nc lude >body </ d :i nc lude > </td >

</ t r >< t r >

< t d he igh t=" 30 " v a l i g n =" midd le " a l i g n =" r i g h t "><d : i nc lude > f o o t e r </ d :i nc lude >&nbsp ;& nbsp ;&

nbsp ;& nbsp ;& nbsp ;</ td >

</ t r ></ t ab le >

</body></html >

Listing 3. The generated mainframe.jsp view stub.

the fundamentals of a framework have been specified, thedevelopment of further CASE tools is just a matter of timeand effort.

The ViewStubGenerator will parse the descriptor file,build up a DOM-like object model and finally generate allrequired view stubs based on customized template files. Thegenerated view files (which are JSP files) already containcorrect tags for view tree inclusion. TheDaVinci RuntimeLibrary already provides a tag-library for DaVinci-specifictags like view inclusion. Figure 11 shows the GUI of theViewStubGenerator and Listing 3 shows the generatedmainframe.jsp file.

The JSP code of the generated view file also demonstrateshow all the hierarchical views are composed to a completeHTTP response. There is a convention, that for HTML outputthe top-most view (root view) must open and close the HTMLroot-tag. All other views are part of the HTML document andtherefore each of them should produce clean and valid code.

F. Build and deploy

Building is done best with a well-suited Java IDE like Eclipsefor instance. After deploying the application to a servletcontainer, the result will look like in Figure 12. A ratherspecific behavior of a DaVinci application is, that navigationis state-ful. This means that views preserve their states whenswitched between them. The deeper a view tree will be, themore users will benefit of this behavior, because they do nothave to click through long navigation paths, instead if theyswitch back to a certain view, all sub-views of this view willhave kept their state.


Fig. 11. The ViewStubGenerator CASE tool.

Fig. 12. A screenshot of the demo application.

VIII. C ONCLUSION AND FUTURE WORK

The concept offunctional URLscombined with an hierarchicalGUI model seems to be a very promising approach to escapefrom complex task of providing maximum support for both, in-formational and functional aspect of a Web application. Whenbuilding Web applications the focus should be the applicationlogic and not reinventing the wheel of user interaction overHTTP. When using DaVinci all views must be predefinedas nodes of the GUI tree. This heavily differs from thehypermedia paradigm where an arbitrary number of additionalpages could be linked into the document structure. But sincethe GUI of anapplicationshould be well-formed anyway, anyview elements must be properly defined in the GUI tree.

The MVC model is a proven concept for Web applications.Because of the strict definition of views and interaction spots,

it is rather easy to find back into source code after months,when extensions to the Web application are requested. Theseparation of application logic and views is a great improve-ment.

There are of course some problems to cope with in future asfor example memory optimizations. Another drawback of theDaVinci concept is, that the URL cannot store an application’sstate. Thus, it is not possible to copy the current URL of aDaVinci session and e-mail it to someone else. Like describedin section V-A, the complete sequence of invoked DaVinciactions would have to be executed again in order to reconstructa previous application state. And often actions are irreversibleat all, so there is no chance to reconstruct a specific state.On the other hand, this limitation should not be an issue inthe context of this definition of Web applications. Again, forDaVinci pages are transient and normally not relevant to bereconstructed.

Concerning the initial demand for a combined modeling andimplementation framework, DaVinci is well suited and cantherefore be called a Web engineering framework. In futurethe integration of DaVinci in Eclipse will be a favorable task.A first CASE tool for the automatic generation of view stubsout of an view tree configration has been created. In future, theintegration of DaVinci into the Eclipse framework and furtherCASE tool support will be a task with priority.

The DaVinci Runtime Library and the presented sampleapplication have been released at SourceForge.net and can bedownloaded at the project’s homepage: http://davinci4j.sf.net.

NOTES1meaning interaction concerning the content of a single resource (dynamic

pages); not the navigation inside the hypermedia system


2The termWeb applicationis used as described in the terminology section(II-A) throughout this work.

3A popular PHP-based project in this category is the Horde applicationframework including an E-Mail application, a calendar, a CVS browser, etc.– see http://www.horde.org for more information.

4Thequery stringis an optional part of an URL following after a questionmark, e.g. http:\\www.guestbook.com?cmd=newentry.

5However, there are some limitations: in this case data has to be serializedand complex data-structures with pointers in memory cannot be preserved.

6Note that in both cases it is assumed that the state of the application isnot strictly equal, since another user could have changed some data; but forexample, the last personalized GUI could be restored.

7The path info is an additional string inside an URL following after thepath to the actual resource file, e.g. assuming thatdavinci maps to the frontcontroller servlet, the path info of the URL http://anyhost/davinci/path-info/foo/4 is /path-info/foo/4. Most Web servers can pre-parse such URLs andextract thepath infostring before serving the request.

8This concept can lead to memory problems when many concurrentsessions are active. This issue will not be further discussed for now. Furtherresearch will address this issue.

9Combined with user profiles a user could therefore recall a previouslysaved state of the GUI tree or personalize his GUI of the Web application.

10A view node’s name is composed of all its parent’s nodes using a Javapackage-similar notation.

REFERENCES

[1] Java Server Faces. URL, http://java.sun.com/javaee/javaserverfaces. Lasttime visited: 29th of March 2006.

[2] Webratio. URL, http://www.webratio.com. Last time visited: 29th ofMarch 2006.

[3] L. Baresi, F. Garzotto, and P. Paolini. Extending UML for Modeling WebApplications. InHICSS ’01: Proceedings of the 34th Annual HawaiiInternational Conference on System Sciences ( HICSS-34)-Volume 3,page 3055, Washington DC, 2001. IEEE Computer Society.

[4] Tim Berners-Lee, Tim Bray, Dan Connolly, Paul Cotton, Roy Fielding,Mario Jeckle, Chris Lilley, Noah Mendelsohn, David Orchard, NormanWalsh, and Stuart Williams. Architecture of the World Wide Web,Volume One. URL, http://www.w3.org/TR/webarch, December 2004.

[5] Stefano Ceri, Piero Fraternali, and Aldo Bongio. Web ModelingLanguage (WebML): a modeling language for designing Web sites. InProceedings of the 9th international World Wide Web conference onComputer networks: the international journal of computer and telecom-munications networking, pages 137–157, Amsterdam, 2000. North-Holland Publishing Co.

[6] P. Chen. The Entity-Relationship Model – Toward a Unified View ofData.ACM Transactions on Database Systems, 1(1):9–36, March 1976.

[7] Jim Conallen, editor.Building Web Applications with UML. Addison-Wesley, Boston, MA, 2003.

[8] Mary Fernández, Daniela Florescu, Jaewoo Kang, Alon Levy, and DanSuciu. Catching the boat with Strudel: experiences with a Web-sitemanagement system. InSIGMOD ’98: Proceedings of the 1998 ACMSIGMOD international conference on Management of data, pages 414–425, New York, 1998. ACM Press.

[9] Anthony Finkelstein, Andrea Savigni, Gerti Kappel, Werner Retschitzeg-ger, Brirgit Pröll, Wieland Schwinger, Thomas Hofer, and ChristianFeichtner. Ubiquitous Web Application Development – A Framework forUnderstanding. InThe 6th Multiconference on Systemics, Cyberneticsand Informatics (SCI2002), Web-Engineering Track, July 2002.

[10] Piero Fraternali and Paolo Paolini. Model-driven development of Webapplications: the AutoWeb system.ACM Transactions on InformationSystems, 18(4):323–382, 2000.

[11] Franca Garzotto, Paolo Paolini, and Daniel Schwabe. HDM – a model-based approach to hypertext application design.ACM Transactions onInformation Systems, 11(1):1–26, 1993.

[12] Lynda Hardman, Dick C. A. Bulterman, and Guido van Rossum. TheAmsterdam hypermedia model: adding time and context to the Dextermodel. Communications of the ACM, 37(2):50–62, 1994.

[13] David Heinemeier Hansson. Ruby on Rails. URL, http://www.rubyonrails.org. Last time visited: 29th of March 2006.

[14] Richard Hightower and Nicholas Lesiecki.Java Tools for ExtremeProgramming. John Wiley and Sons, Inc., New York, 2002.

[15] Jason Hunter and William Crawford. Java Servlet Programming.O’Reilly, Sebastopol, CA, 1998.

[16] Tomás Isakowitz, Edward A. Stohr, and P. Balasubramanian. RMM: amethodology for structured hypermedia design.Communications of theACM, 38(8):34–44, 1995.

[17] Gerti Kappel, Birgit Pröll, Siegfried Reich, and Werner Retschitzegger,editors. Web Engineering. dpunkt Verlag, Oct. 2003.

[18] David Lowe, Brian Henderson-Sellers, and Alice Gu. Web modellinglanguages: the gap between requirements and current exemplars. InAustralien Web Conference (AUSWEB02), July 2002.

[19] Sheila A. McIlraith, Tran Cao Son, and Honglei Zeng. Semantic WebServices. InIEEE Intelligent Systems, pages 46–53. IEEE ComputerSociety, Los Alamitos, CA, March/April 2001.

[20] Paolo Merialdo, Paolo Atzeni, and Giansalvatore Mecca. Design anddevelopment of data-intensive web sites: The Araneus approach.ACMTransactions on Internet Technology, 3(1):49–92, 2003.

[21] K. Nguyen and T. S. Dillon. Towards a practical model-driven approachto web information system development. InThe Seventh InternationalConference on Information Integration and Web-based Applications &Services, Kuala Lumpur (iiWAS 2005), pages 629–641, Vienna, 2005.OCG.

[22] B. A. Nuseibeh and S. M. Easterbrook. Requirements engineering:A roadmap. In A. C. W. Finkelstein, editor,The Future of SoftwareEngineering, pages 35–46. IEEE Computer Society Press, Los Alamitos,CA, 2000.

[23] Object Management Group (OMG). MDA Guide Version 1.0.1. URL,http://www.omg.org/docs/omg/03-06-01.pdf, June 2003. Last time vis-ited: 29th of March 2006.

[24] Werner Retschitzegger and Wieland Schwinger. Towards modeling ofdata web applications – a requirements’ perspective. InProceedingsof the Americas Conference on Information Systems (AMCIS 2000),volume 1, pages 149–155, Atlanta, Georgia, August 2000. Associationfor Information Systems.

[25] Klaus-Dieter Schewe and Bernhard Thalheim. The Co-Design Approachto Web Information Systems Development.Journal of Web InformationSystems, 1(1):5–14, 2005.

[26] Daniel Schwabe and Gustavo Rossi. The object-oriented hypermediadesign model.Communications of the ACM, 38(8):45–46, 1995.

[27] Inderjeet Singh, Beth Stearns, and Mark Johnson.Designing EnterpriseApplications with the J2EE Platform. Addison-Wesley, Boston, MA,2002.

[28] Woojong Suh, editor.Web Engineering: Principles and Techniques. IdeaGroup Publishing, April 2005.

[29] Lorna Uden. Design process for web applications. InIEEE MultiMedia,pages 47–55. IEEE Computer Society, Los Alamitos, CA, Oct-Dec 2002.

[30] H. Van Vliet. Software Engineering: Principles and Practice (2ndEdition). John Wiley and Sons, Inc., New York, 1999.

Andreas Langeggeris scientific assistant at the Institute for Applied Knowl-edge Processing, Johannes Kepler University Linz, Austria. He studied "Mediatechnology and -design" at the Upper Austrian University of Applied Sciences,where he is also holding lessons. Currently he is doing research in the fields ofGrid computing, Semantic Web and Web engineering. In 2005 he has startedworking for his PhD at the Johannes Kepler University Linz.

Jürgen Palkoska is assistant at the Johannes Kepler University of Linz,Austria. He finished his PhD in the area of semantic based similarity searchconcepts for database systems. Currently, he intensively researches and teachesin the area of semantic based information retrieval, fuzzy search methods, WebEngineering and information systems. Furthermore he is area manager for WebEngineering and responsible for the project management in this domain.

Roland Wagner is a Professor for Information Systems at the JohannesKepler University of Linz. He is director of the Research Institute ofApplied Knowledge Processing (FAW) and director of the Institute IntegratedStudies ("integriert studieren"). He is managing various industrial and researchprojects in the areas of information systems, knowledge-based systems, elec-tronic commerce and eAccessibility. He is teaching in the area of InformationSystems and his current research interests are new database developments,object oriented database environment, data mining, data warehouses andeAccessibilty.

Documents

TROUBADOR PUBLISHING LTD 119 DaVinci – A Model-driven …€¦ · 120 J. WEB. INFOR. SYST. 2 (2), JUNE 2006. °c TROUBADOR PUBLISHING LTD software modeling can result in very bulky