Modelling the Requirements of Rich Internet Applications in WebRe

. In the last years, several Web methodological approaches were defined in order to support the systematic building of Web software. Together with the constant technological advances, these methods must be constantly improved to deal with a myriad of new feasible application features, such as those involving rich interaction features. Rich Internet Applications (RIA) are Web applications exhibiting interaction and interface features that are typical in desktop software. Some specific methodological resources are required to deal with these characteristics. This paper presents a solution for the treatment of Web Requirements in RIA development. For this aim we present WebRE+, a requirement metamodel that incorporates RIA features into the modelling repertoire. We illustrate our ideas with a meaningful example of a business intelligence application.


Introduction
It is widely known that the Web is constantly evolving.In this evolution, Rich Internet Applications (RIA) [1] represents a major breakthrough, as they allow combining the typical navigation flavour of the Web with the interface features of desktop applications.These applications allow reducing the communication between clients and servers since pages (differently from the "navigational" Web) do not need to be fully reloaded with each user interaction.The emergence of a well-known set of RIA patterns [2] has additionally defined a small, though complete, vocabulary for expressing desired interaction functionalities in a software system.It is now common saying: "this should be an auto-complete field" or, "we can use hover details for showing this information".Not surprisingly applications stakeholders also use this vocabulary as part of their requirements for a new application.However, though most Web design methods have been already extended to cover the scope of RIA [3][4] [5], there is still an important gap in requirement specification of RIA functionality, since requirement specification and modelling languages do not include suitable primitives for expressing this kind of requirements.In this way, checking whether a requirement has been fully implemented becomes a subjective matter, and it is not possible to automate this process (e.g. by automatically generating tests from requirement specifications).
In this paper we analyze the new kind of requirements that occur in RIA, and how we can extend an existing approach to specify the behaviour of this kind of applications in a MDWE (Model-Driven Web Engineering style) [6].Specifically, we use an enhanced version of the WebRE metamodel [7] to specify RIA requirements.
The paper has two aims.Firstly, we show how our modelling approach for specifying Rich web requirements is integrated in the NDT approach.In addition we show the integration between mockups and our metamodel to improve requirements elicitation with customer.Finally, we show how to derive a set of interaction tests from WebRE+ models to validate the RIA functionality.
The paper is structured as follows: Section 2 presents the background for this work; we present the NDT approach and the WebRe metamodel.In Section 3, we show the extension of WebRE for RIA, its UML profile and how our metamodel is used with Mockups.Section 4 presents how tests are derived from WebRE+ models and section 5 shows a case of study with an example in the Business Intelligence area.In section 6 we present the implementation of our metamodel and in section 7 the related works in Web requirements, Model-Driven Web Engineering and RIA.Finally we present the conclusions and future research work in this project.

Background
In this section we introduce the NDT approach that gives a good context for our metamodel and the original version of our metamodel called WeRe which does not support rich requirements.

NDT
NDT [14] is the acronym for Navigational Development Techniques, is a member of the growing family of MDWE approaches.Initially, NDT dealt with the definition of a set of formal metamodels for requirements, based on the WebRE metamodel.In addition, NDT defined a set of derivation rules, expressed with the standard QVT, which generate analysis models from requirements models.Nowadays, NDT defines a set of metamodels for every phase of the life cycle of software development: the feasibility study phase, the requirements phase, the analysis phase, the design phase, the implementation phase, the testing phase, and finally, the maintenance phase.Besides, it includes new transformation rules to systematically generate models.Fig. 1 shows the first part of the NDT lifecycle 1 .
The main goal of the Requirements phase is to build the catalogue of requirements which contains the needs of the system to be developed.It is divided into a series of activities: capture, definition and validation of requirements.
NDT classifies system requirements according to their nature: information storage requirements, functional requirements, actor requirements, interaction requirements, and non-functional require patterns and UML complia specification.

Fig. 1. Transformations from
Once the requirements of system requirements has to generate the system test these transformations throu NDT conceives the Te and proposes to carry it ou models in this phase: i acceptance tests model.T generated systematically.model of system tests from phase.The team of analy complete this basic model stereotype «NDTSupport».
The Analysis phase inc and organization of require four models: the conceptual the process model, which navigation model, which sh abstract interface model, a s The transition between and automated, and it is ba of requirements metamodel are known in NDT as basi model of analysis is obta requirements phase.
he Requirements of Rich Internet Applications in WebRe ements.In order to define them, NDT provides spe ant artefacts, such as use cases for functional requireme m Requirements to Analysis and from Requirements to Testin specification phase has been completed and the catalo s been drafted and validated, NDT defines derivation ru t model and the analysis phase models.Fig. 1 shows gh the stereotype «QVTTransformation». esting phase, as an early phase of the software life cy ut together with the remaining phases.NDT defines th mplementation tests model, system tests model The system tests model is the only one that can NDT comprises derivation rules to generate the ba m the functional requirements defined in the requireme ysts can perform transformations in order to enrich l.Transformations are represented in Fig. 1 through cludes the resulting products from the analysis, definit ements in the previous phase.At this phase, NDT invol l model, which represents the static structure of the syste h represents the functional structure of the system; hows how users can navigate through the system and set of prototypes of the system.the requirements and the analysis model is standardi ased on QVT transformations, which translate the conce ls to the first versions of the analysis models.These mod ic models of analysis.For example, the basic concept ained from the storage requirements defined during Thereafter, the team of analysts can transform these basic models to enrich and complete the final model of analysis.Since this process is not completely automatic, the expertise of an analyst is required.To ensure consistency between requirements and analysis models, NDT controls these transformations by means of a set of defined rules and heuristics.
To sum up, NDT offers an environment suitable to the development of Web systems, completely covering life cycle of software development.This environment is named NDT-Suite.
The application of MDE and, particularly, the application of transformations among models may become monotonous and very expensive if there are no software tools that automate the process.To meet this need, NDT has defined a set of supporting tools called NDT-Suite.Currently, the suite of NDT comprises the following free tools:  NDT-Profile is a specific profile for NDT, developed using Enterprise Architect [8].NDT-Profile offers the chance of having all the artefacts that define NDT easily and quickly as they are integrated within the tool Enterprise Architect. NDT-Quality is a tool that automates most of the methodological review of a project developed with NDT-Profile.It checks both, the quality of using NDT methodology in each phase of software life cycle and the quality of traceability of MDE rules of NDT. NDT-Driver implements a set of automated procedures that enables to perform all transformations MDE among the different models of NDT that were described in the previous section. NDT-Prototype is a tool designed to automatically generate a set of XHTML prototypes from the navigation models, described in the analysis phase, of a project developed with NDT-Profile. NDT-Glossary implements an automated procedure that generates the first instance of the glossary of terms of a project developed by means of NDT-Profile tool.
 NDT-Checker is the only tool in NDT-Suite that it is not based on the MDE paradigm.This tool includes a set of sheets, different for each product of NDT.These sheets give a set of check lists that should be reviewed manually with users in requirements reviews.
To conclude, one of the most important characteristics of NDT is that has been applied in many practical environments; it has succeeded mainly due to the application of transformations among models, which has significantly reduced development time.

WebRE
WebRE is a metamodel that includes modelling artefacts to deal with requirements in Web applications; it uses the power of metamodelling to fuse different approaches.WebRE was born from the exhaustive analysis of different Web engineering proposals that deal with requirements.It unifies the criteria of these proposals and defines a unified metamodel for the CIM (Computer Independent Model) level.It provides a base to decide which concepts or elements must be captured and defined in the requirements phase of Web applications.The metamodel defines each of these concepts and the relationships between them.With this unification, WebRE overcomes an important gap: with the use of a common metamodel, it abstracts from the multiple notations used in each approach.Each artefact defined in WebRE can be mapped to an artefact in each of the different requirement engineering approaches.Besides, WebRE also comprises an UML Profile with a concrete syntax to represent each concept.Thus, a development team can specify an application's requirements using the WebRE profile, and later (when necessary) map them to concrete model elements to continue with the selected methodology (NDT, UWE, W2000 or OOHDM).Additionally, it would be possible to systematically derive the corresponding navigation models from requirements expressed in WebRE using suitable transformations.
However, WebRE was originally conceived for Web 1.0 applications and therefore it does not support specification of RIA behaviours.The extension proposed in this paper allows the systematic generation of models for Web 2.0 applications and the generation of tests to validate the RIA functionality (Section 4).In the following sections we show how we enriched the WebRE metamodel with new metaclasses and metaassociations in order to provide an approach that covers both: Web 1.0 and Web 2.0 requirements.

Metamodelling Rich Requirements with WeRe+ in NDT
Expressing RIA behaviour and specifically supporting the use of RIA patterns in requirements using a metamodel have many benefits such as: • Making possible to develop the application easier by automatically deriving concrete software artefacts, • Allowing the generation of tests to automatically validate the requirements • Supporting requirements evolution and • Improving traceability between requirements and the implementation.
In the following subsections we show its RIA extension and the corresponding UML profile.Also, we present in which activities of the NDT approach the WeRe+ modelling is used with mockups.

WebRE+
RIA have particular features like sophisticated interactive behaviour, client-side feedback of "slow" operations and different kinds of client-side behaviour depending on the occurrence of events, among others.An example of the last feature is shown in Figure 2.
The line graph shows information about the progress of a business across time.As a consequence of how progress is measured (it requires certain calculations) we only show the final computed value in the graph.The details of how those values were computed are shown only when the user shows interested in it (e.g. when the user puts its mouse over an item).This solution is well known as a hover detail pattern in the Yahoo Patterns catalogue.This kind of RIA the user interface with lots o provide a precisely specific concepts such as events, U extended the WebRE metam Fig.

In WebRE+ the original the mapping between the co
The structure package in Web requirements.Since R add the UIElement metacl images, checkboxes, etc. T metaclasses: RIASpecificati a RIA behaviour must sat RIASpecification in a conc RIASpecification instanc (RIAScenarioSpecification puts the mouse over an ite UIElement must contain disappears: When the user the details of the item must The behaviour package navigation.We extended th specify different situations; when the user types somethi different subclasses: those KeyboardEvent) and those w Also, we include a new met perform over an element in t UIElement).Instances of UI actions may produce many three events are fired, namel .Escalona, and G. Rossi A behaviour improves applications usability without pollut of information, which could be unnecessary at first sight.cation of this kind of requirement we need to deal w UI elements like buttons, textfields, etc.For this reason model with these concepts as shown in figure 3.
. 2. Hover detail pattern on a line graph l packages, structure and behaviour, were kept to prese oncepts present in WebRE+ and its ancestors.ncludes each concept to deal with the conceptual aspec RIA applications mainly deal with client side behaviour, lass.Instances of this metaclass are: buttons, textfie o support RIA we extended the metamodel with two n ion, which represents a definition of a set of scenarios t tisfy and RIAScenarioSpecification, which describes crete scenario.For example, in the hover detail feature e), we must specify two different scenar instances), namely Hover detail appears: When the u em then a UIElement must appear after 2 seconds.T a name and a description of the item; Hover de moves the mouse out of the item, then the UIElement w not be shown.e includes metaclasses to represent user's interaction he package with the Event metaclass which is importan for example, when the user puts the mouse over an it ing on a field, etc.In this case, we differentiate between events which are originated with the keyboard (subc which are originated with the mouse (subclass MouseEve taclass UIAction which captures the actions that the user the UI of the application (relationship between UIAction IAction are "click", "type keys", and execution of one of events, e.g. when typing a key on a user interface elem ly onpressdown, onpresskey and onpressup.In the following subsection we describe our implementation of the UML profile.

A UML Profile for WebRE+
In order to provide editing support for our approach, we developed an UML profile for WebRE+, and implemented it using the Enterprise Architect tool.The use of UML profiles to provide tool supports is being used as a solution in some Web design approaches like UWE with MagicUWE [23] and specifically in NDT with NDT-Profile [24].
In Figure 4 we present the profile for WebRE+.As WebRE has its own profile, we only our extension; that is, the metaclasses we have added create WebRE+.
Each metaclass of WebRE extends an UML metaclass.Thus, we map our artefacts onto UML ones and define for them a set of characteristic that we could, even, improve with specific tag values or constraints.

WebRE+ and Mockups in the Context of NDT
Specifying rich requirements using the presented metamodel might be easy for developers but when used in a work session with a customer it may not be suitable, since customers do not understand the concepts behind a metamodel.To overcome this problem and in syntony with existing approaches in agile web application development [31] we can use WebRE+ with mockups to simplify the requirements elicitation phase.
A mockup is a sketch of a User Interface (UI) which shows an example state of the system to be.It is useful when interacting with customers, as it is clear of what would be the software's UI.An example of our business case example is shown in Fig. 5 where we show the 2 possible states of the UI according to the mouse events.
Using mockups and WebRE+ we can specify a variety of rich requirements and allow customers to be involved in the process.However, it is important to define the activities involved in this process.In Fig. 6 we show those activities when using mockups with WebRE+ models.We start creating mockups (Step 1) as it defines a good basis to start discussing with customers.Also, they can be created really fast (within few minutes) and the feedback obtained from customers is good.Afterwards, we can create/update our WebRe+ models (Step 2); during this activity the analyst may notice incomplete and even contradictory requirements while formally specifying the requirement, and therefore it is necessary to create extra mockups to discuss with customers.After a few iterations, we can conclude this process (Step 3).we work such us Watir [26].We have chosen Selenium because it is one of the most popular testing frameworks that simulate user input and it is widely used in industrial settings.Also, a Selenium test could be re-written in almost any programming language and run on a Selenium server whereas Watir on Ruby [30].

Fig. 7. Test model
In the following section we illustrate the use of the metamodel with a specific RIA requirement in the context of a Business Intelligence application showing how we specify it using WebRE+ and how tests are derived to Selenium.

A Case of Study
The business intelligence area is an example of how to use RIA to improve the user experience.For example, Pentaho BI suite [27] uses the Web environment to show data and allows users to execute queries to the data warehouse.A line graph that shows the progress of the business (Figure 2) could provide details about each value shown using the hover detail pattern.Let's suppose that we are developing a Business Intelligence Web application for a company whose core business is organizing campaigns for different customers and providing summary reports to them.To improve the usability of the summary report which contains the line graph of Figure 2, we would like to add hover details to the items to show how those values are computed.For example, on a particular day there have been 3245 clicks and 15687 impressions so the CPC (Cost per click) is 0.34.
As in every RIA pattern, there are some features that can be configured and should be specified during the requirement elicitation phase.A simplified instance model of the WebRE+ specification for this requirement is shown in figure 6.The model shows that when the item receives an onmouseover event, a detail of the item must be shown in the page in less than 2 seconds.This widget must contain a label with the money used in the campaign and the number of clicks.The test suite contains 2 tests, one for each scenario described in the WebRE+ model of figure 6.The first test opens the report (line 1), passes the mouse over the item (2) and waits till the item detail is shown (3), then the assertion verifies that the detail is present (4).The second test opens the report (1), passes the mouse over the item (2) and waits till the item detail is shown (3).Then the mouse is put out off the item and waits (4 and 5) and the assertion verifies that the detail is not present (6).

Implementation
The idea of using metamodels and UML profiles, allowed the incorporation of our approach in NDT and its tools easily.The metamodel for requirements of NDT is based on WebRE and WebRE+ is an extension of WebRE.The incorporation of the new classes presented in Figure 3 is easy and, proposing a way to represented them using a UML profile, as described in Figure 4, let us introduce it in the NDT-Profile.According to Figure 2, this extension enriches the possibilities of the Requirements Definition tasks.Thus, using WebRE+, a development team could include in the requirements a catalogue of RIA requirements.But, WebRE+ could be also added in the NDT-Profile.According to section 2.1, NDT offers a suite, NDT-Suite, which is based on a tool, NDT-Profile, which supports its UML profiles and let the definition of NDT artifacts and elements using the UML notation.With the definition of a UML profile for WebRE+, we can enrich the NDT-Profile and Enterprise Architect to support it.
The next step to let the inclusion of our approach in NDT is the definition of a set of transformations to be included in NDT-Driver.This paper covers a first set of transformations, the set of transformations from requirements to tests.The rest of transformations are part of our future work.
In Figure 7, we show an example work screen of WebRE+ in Enterprise Architect.On the left, we can see a special toolbox for creating instances of the metaclasses.The user can select each WebRE+ artefact to deal with it in his diagrams.In Figure 7, a WebUser instance (WebUserExample) and a RIASpecification instance (RIASpecification) example is presented.In our profile (Figure 4), the RIASpecification is defined as an extension of the UseCase metaclass, thus, it could be related with a User, like WebUserExample.Related Works The research of this paper is related with research in two different areas: the specification of Web Requirements in the context of Model Driven Engineering (MDE) and RIA.We analyze both areas in separate sub-sections.

Web Requirements Engineering and MDE
Web engineering is nowadays an important field in software engineering [9].However there is an important gap in the treatment of requirements.In the first design approaches, OOHDM (Object-Oriented Hypermedia Design Model) [10], WebML (Web Modeling Language) [11] or UWE (UML Web Engineering) [12] the main focus was put on modelling and design issues, while the requirements phase was almost neglected as reported in [13].
The importance of a full-fledge requirements phase is nowadays common in Web methodologies like NDT (Navigational Development Techniques) [14] or OOWS [15].Additionally, some of the previous approaches started to include their own formalisms for requirement specification.For instance, OOHDM was enriched with UIDs (User Interface Diagrams) [16] or WebML with business models [17].
Other relevant problem in the requirements specification stage is the lack of standards and therefore the proliferation of proprietary notations; each approach tends to offer its own notation.To make matters worse similar formalisms are used in different approaches with slightly different semantics, or several names are used for the same concept.
In order to solve this problem, some authors have used the concepts in MDE [18].In this development approach, building models is the main activity, and software is built by a series of model transformations ending, eventually, in a running application.Models are built using instances of concepts and relationships which are formally described by metamodels.
In summary, MDE offers a suitable solution for Web requirements for several reasons: It mainly focuses on concepts; the way to represent them is a secondary aspect.It offers a systematic way to translate requirements knowledge into the next phases in the development life cycle.
Additionally, as some relations are defined between requirements and analysis concepts, it can control the traceability and the coverage of requirements.
Finally, if an UML profile is defined for the requirements metamodel (as it is in WebRE), software support tools for modelling activities can be built in a cheap way.

Rich Internet Applications
The Web as it was originally conceived has dramatically changed since 2003 when the concept of Rich Internet Applications (RIA) appeared.This new kind of Web applications mixes the old navigation style of Web Applications with the behaviour of traditional desktop applications: client side feedback, drag and drop features, etc.Since then, almost any desktop application has a Web counterpart, allowing users to take advantage of automatic updates since no instalment is necessary at the client side.Some examples of Web applications with RIA behaviour are Google Maps [20], GMail and Google calendar [21], Meebo [22], etc.As developers faced the same problems repeatedly and found good solutions using the concepts in RIA, some patterns arose.As in the design patterns field, different catalogues showing RIA solutions to abstract problems have been described; one of the most popular catalogues is the so called Yahoo Patterns catalogue [2].In contrast with software design patterns, RIA patterns are near to the stakeholder's perspective thus they use patterns' names when they describe specific RIA requirements.ADV-charts [5] were proposed as a modelling approach to design the structural and behavioural of user interface (UI) elements of RIA applications.However their level of abstraction (close to implementation) is inadequate to be used during requirements specification.

Conclusions and Future Works
In this paper we presented a metamodel for capturing RIA requirements.The metamodel allows us to express different well known RIA patterns such as those in the Yahoo patterns catalogue.The metamodel has been implemented as a UML profile and used within the EA environment to capture different RIA requirements in the context of a business intelligence application.Also, we have shown how to use the metamodel with mockups to improve the requirements gathering phase as it is hard for customers to understand the models and mockups give an intuitive way for expressing rich requirements.Some aspects of our research still need some further work.In this matter we are working on deriving part of the RIA functionality using well known Javascript libraries such us YUI [28] or ExtJS [29].Finally, since this kind of requirements not only affect the UI but also the software backend, we are trying to indicate which part of the functionality could not be implemented automatically and thus needs manual intervention from developers.
Besides, this approach opens new research lines for NDT.In the paper, we discussed how it enriches the requirements definition and presented a set of transformations (from RIA requirements to test); some others, such as for instance transformations from RIA requirements to analysis models, should be proposed.We are also working in these issues to complete our set of development tools.