Web application modelling has been extensively researched, and many reviews and surveys of ex- isting approaches exist. Selmi et al. [307] provides an excellent survey of some of the fundamental problems with existing approaches. Other reviews concern themselves with evaluating the functional requirements of languages [11,140], and consistently find that existing languages are inadequate due to deficiencies in expressibility, usability or implementation support. A discussion on the suitability of model-driven approaches is discussed later in Section3.1.
In this section, a range of existing RIA modelling approaches will be briefly discussed. This eval- uation had been performed earlier by Wright and Dietrich [368], which identified that these existing languages tend to either be abandoned or poorly implemented. This section will focus on new web application modelling language research that has emerged since this evaluation was published, rather than revisiting these older languages.
2.4.1 WebML
WebML is a well-researched and commercialised approach to modelling data-intensive web appli- cations [51]. Web applications are described using five models, of which the hypertext model (the combination of thecompositionandnavigationmodels) is the most important. In Figure2.2, a simple web application for publishing CD reviews is illustrated. These models are combined together using code generators and custom XSLT templates [341] to generate the final Java-based application, which can then be published onto a web server.
The language is well-supported with a CASE tool named WebRatio, which is still actively de- veloped but at the time of writing, has not been extended to implement new modelling approaches, such as recent client/server extensions to the model [105]. This CASE tool is commercialised and closed-source which hinders extensibility, although there is some support for plugins. With regards to supporting RIAs, it appears that WebML is focused on supporting conventional data-driven web applications, and instead attempts to “bolt on” RIA support to the WebML model, instead of using RIA concepts fundamentally.
Wright and Dietrich [368] found that WebML was the most complete modelling language for web applications, yet lacked support for many of the fundamental concepts of RIAs, such as object lifecycles, user interface modelling, and controlling the browser. Following the publication of this review, the WebML authors agreed that the language lacked these important features [105].
9As discussed later in Section5.1.1, these requirements have been separated into two profiles –Basic RIAsandFull RIAs – to simplify the implementation of a modelling language for RIAs against these requirements.
2.4 Existing Web Application Modelling Languages 21
Figure 2.2: A sample WebMLhypertext model
2.4.2 UML
UML is a general-purpose modelling language for the analysis, design and implementation of software systems and other similar processes [254], which can include web applications and RIAs. However, this flexibility impacts on its suitability as a RIA modelling language. UML model instances are often verbose and extremely informal, with a lot of domain knowledge assumed. Common web concepts such as sessions, timed events and e-mails are difficult to describe with standard UML, and extensions are usually required.
As UML does not have a complete set of defined formal semantics and implementation rules [113], it is not possible to take an arbitrary UML model instance and translate it into a functional piece of software. This reduces the suitability of using UML for modelling RIAs, as the semantics of UML would need to be extended – which is likely to spawn platform-dependent UML model instances that cannot integrate with other UML model instances. Some authors argue that UML should not capture code-level semantics, such as Fu et al. [113]; however, this viewpoint suggests UML is therefore strictly for documentation-purposes only, negating many of the benefits of model-driven approaches.
The OMG recommends extending UML through the use of three key extension mechanisms; stereotypes, tagged values, and constraints [44]. In particular, a stereotype is defined as “a kind of Class that extends Classes through Extensions” which are applied to an existing metaclass10 [254, pg. 670], allowing domain-specific terminology to be provided against a base UML model. The for- mal combination of a particular set of extensions can be published as a single UML Profile [114].
10In this thesis, the UML termmetaclass[254, pg. 23] will be defined as thedefining metamodel class for a given instance of a metamodel element.
Figure 2.3: A sample UWEnavigation structure model, adapted from Koch [190]
In practice, only the stereotypes of a UML Profile are supported by existing CASE tools [298], and constraints defined by UML Profiles are poorly supported.
UML’s extensibility is entirely additive; you cannot remove existing UML notations or create new operations, without creating an entirely new UML derivative language [44]. Bruck and Hussey argue that DSLs provide more precision and less complexity, and recommend extending UML only if the majority of your concepts easily map onto existing UML concepts [44].
Nevertheless, one UML extension, UWE – discussed in the next section – has emerged as a promis- ing candidate for modelling web applications. Another extension of UML by Conallen [59] also at- tempts to extend UML to describe web applications, and can translate the model into a functional web application, but lacks significant functionality. A third extension, WUML [176], attempts to add models to describe web concepts, such as events and user profiles; WUML’s intent appears to focus on documentation and extension purposes, rather than systems development.
2.4.3 UWE
UML-based Web Engineering [192] is a web application modelling language extension to UML, fol- lowing the UML extensibility requirements [44], which has a heavy focus on using modelling stan- dards. UWE uses more types of models than WebML11, but advocates using automatic and semi- automatic tools to assist the developer in constructing these models12.
11At the time of writing, UWE uses at least eight models [190]: requirements, content, architecture, navigation, process, business logic, architecture and integration models; whereas WebML uses at least three models [51,50]: data, hypertext, and presentation models.
2.4 Existing Web Application Modelling Languages 23
define page editUser (u : User) {
title { "Edit User: " output(u.name) }
section {
header { "Edit User: " output(u.name) }
form {
par { "Name: " input(u.name) }
par { "Password: " input(u.password) }
par { action("Save Changes", saveUser()) } }
action saveUser() {
u.persist(); return viewUser(u); }
navigate(home()) { "return to home page" } }
}
Listing 1: Part of a web application implemented in WebDSL, adapted from Groenewegen et al. [134]
Compared to WebML, the model instances are often more verbose but the individual model ele- ments are simpler; this means the models are easier to understand, but less efficient to develop large applications. One of these models is anavigation structure modelto model the navigational aspect of web applications [191], and the navigation of the same CD reviewing application is illustrated in Figure2.3. Recent extensions to UWE have introduced RIA concepts, such as autocomplete and input validation, to the UWE metamodel [193]; however these extensions are simply functionality exten- sions for conventional web applications, and do not support fundamental RIA concepts such as events and browser control.
Wright and Dietrich [368] found that UWE had no support for common web concepts such as e-mails and browser identification. A significant extension to UWE is therefore necessary to support basic web concepts, which would then need to be extended again to support RIA concepts; but these extension would be vastly simplified due to its adherence to model-driven standards. The language’s openness, automatic developer processes, clean models, and standards-based approach is promising for future extensibility.
2.4.4 WebDSL
WebDSL is a textual domain-specific language for implementing data-driven web applications with a rich data model, and has limited support for user interface modelling [134]. It can support a wide range of access control models – including most of the access control models discussed later in Section4.8– although these policies have to be individually implemented [135]. A short excerpt of a WebDSL model instance is illustrated in Listing 1; as discussed later in Section 3.4, a modelling language does not require a graphical syntax in order to be effective.
Web applications defined in WebDSL may then be generated into source code through the model transformation languageStratego/XT. Language extensions also extend the code generator by provid- ing plugins upon the base language. At the time of writing, WebDSL is still fairly recent and lacks supports for RIA concepts such as client-side scripts and browser control, making it unsuitable in modelling RIAs.
2.4.5 Web Information Systems
Rather than providing a visual model, work has been done on describing web applications from a more formal perspective, with roots in algebra and graph theory. Schewe [297] describes Web Information Systems(WIS) as a triplet of issues: content, navigation and presentation, with each issue described using strict notation. Like most existing approaches, WIS lacks modelling support for most web concepts, and cannot handle the interactivity of RIAs.
The argued benefit for using formal models is that it simplifies formal verification of the model; but the line between formal and informal models continues to blur, as modelling languages (and instances) are increasingly using formal syntax and semantics in their own definition [188]. By themselves, formal models are difficult for developers to understand or utilise, so any formal modelling approach requires tool support in order to make any impact [49].
2.4.6 Older Languages
There is a vast selection of other modelling approaches to web applications, and each of these have been similarly investigated as to the feature requirements of modelling RIAs. Wright and Dietrich [368] investigates the languages W2000 [17], OOWS [271], OOHDM [288] and Araneus [225] and finds that these languages are particularly unsuitable for modelling RIAs. All of these older languages have been found to lack support for many of the fundamental concepts in web applications [276,307], and many are currently out-of-date or poorly maintained. These approaches will therefore not be considered in any further detail in this thesis.
2.4.7 Evaluation
Wright and Dietrich [368] critically evaluated the most recent versions of existing web application modelling languages against the general feature categories of RIAs introduced earlier in Section2.3.1, with respect to a subjective ranking. The evaluation results published in this paper are included here in Table2.3. This review found that the majority of approaches have limited existing support for standard web application concepts that should be supported already, such as sessions, events, messaging and access control.
These languages are therefore unsuitable as candidates for an extension to support RIAs, as signif- icant effort must first be expended to addressconventional web applications. Existing approaches do not directly support events or interactive functionality, but instead provide this functionality through the use of user interface libraries. Fundamental web concepts such as users and access control were often ignored, and very few approaches directly investigated the use of verification techniques.
Along with the existing reviews discussed earlier at the beginning of this section, these evaluation results strongly suggest that no existing modelling language satisfies the requirements defined by Wright and Dietrich for a RIA modelling language [368]. In particular, there is a significant conceptual gap between the high-level web system concepts and the low-level technologies required to support its implementation, and this size of this gap is increased by the arrival of new RIA technologies.