Assessing a Web Engineering Method in Practice: a Preliminary ...

Assessing a Web Engineering Method in Practice: a Preliminary Analysis for Personal Genomics Portals Ana Rosa Guzman1, Victoria López1, Francisco Valverde1, Sven Casteleyn1, Oscar Pastor 1 1

Centro de Investigación en Métodos de Producción de Software, Universitat Politècnica de València Camino de Vera S/N, 46022 Valencia, Spain {arguzman, vlopez, fvalverde, sven.casteleyn, opastor}@pros.upv.es

Abstract. Over fifteen years of academic research in Web Engineering resulted in sound engineering principles and full-fledged design methods for Web applications. Nevertheless, the community suffers a lack of industrial adoption and a lack of validation of the methods in realistically sized modern Web applications. This paper addresses this hiatus and presents an experience report on the application of OOWS 2.0, a state-of-the-art Web engineering method, on two real-life complex Web applications in the Personal Genomics field. Based on this analysis, we verify the technical completeness of the method, gather information about its use, identify shortcomings and present some improvements. Keywords: Web Engineering, Model-driven Engineering, Personal Genomics

1

Introduction

Over the past fifteen years, research in Web Engineering explored methods and techniques to develop Web applications in a sound and systematic way. Several so called Web Engineering methods have been established, and hundreds of scientific publications have been dedicated to them. These methods generally follow the model-driven development paradigm, and discern similar models and modeling abstractions tackling data, navigation and interaction and presentation concerns. Some of the bestknown methods include WebML [1], OOHDM [2], OOH [3], WSDM [4] and OOWS [5]. Despite these efforts, there is a lack of validation and evaluation research. Few experience reports are available [6] and industrial adoption is minimal or totally missing. An extensive empirical study carried out by Garzotto et al. [7] reveals that many factors contribute to the lack of adoption, among which are the lack of awareness of web engineering methods, lack of consideration of non-functional requirements and lack of tool support. As a result, it is unclear how the Web engineering methods would perform in a real-world industrial setting, where the requirements, size and complexity of Web systems are of a different order of magnitude than the academic proof-of-concepts that are usually reported © Springer-Verlag Berlin Heidelberg 2012

The purpose of this paper is two-fold. First, we contribute an experience report of the use of an academic model-driven Web Engineering method on a real-life case. More specifically, two practitioners systematically analyzed two existing large-scale Personal Genomics web portals, and then they modeled in detail the user-system interaction of the portals using the academic model-driven Web Engineering method OOWS 2.0. This process was supervised by two skilled OOWS 2.0 Web engineers. Both portals have been selected because of their complexity in functionality, navigation, interaction and presentation, and thus they form ideal examples to analyze the functional completeness of Web Engineering modeling constructs beyond the academic world. Second, based on the problems and lacks we detected in this real-word scenario, we isolate two important problems regarding OOWS 2.0 models and present solutions for them. The rest of this paper is structured as follows. Section 2 summarizes OOWS 2.0, the Web Engineering method used in this research work. Section 3 briefly describes Personal Genomics, the field of study, and details the setup of the analysis. Section 4 introduces two Personal Genomics web portals used as lab demos and describes the reverse engineering of the modeling process. Section 5 summarizes the results of the analysis that was performed. In Section 6, two extensions to the OOWS 2.0 metamodel that solve some identified shortcomings are proposed. Section 7 presents related work. Finally, section 8 presents concluding remarks and future work.

2

OOWS 2.0 in a Nutshell

OOWS (Object-Oriented Web Solutions) [5] is a Web Engineering method that provides methodological support for Web application development. It has been developed as an extension of OO-Method [8], an automatic code generation method for software applications. Both OOWS and OO-Method are examples of Model-Driven Engineering methods because conceptual models are considered key elements in all development steps. Software products are generated from a conceptual specification of the system by means of four complementary OO-Method models and two OOWSspecific models, which capture the data, the business logic and the interface requirements of a given Web Information System. OOWS 2.0 [9] is made up of four phases whose activities are summarized in Table 1. It is an evolution of the original OOWS method to include support for features related to Rich Internet Applications and Web 2.0, such as richer interaction and presentation [10]. This article mainly focuses on the Interaction phase, hence the rest of phases are not elaborated here; we refer to [9] for a full description of OOWS 2.0. The purpose of the Interaction phase is to model the interaction between the users and the Information System in an abstract manner, i.e., without considering technological details. The key element of the Interaction phase is the Abstract Interaction Model, which is made up of several (sub-)models. First, users that directly interact with the system are represented in a User Diagram. Next, the abstract tasks that the users can carry out with the system, for instance adding a new customer to the system or browsing a product catalog, are represented as “interaction contexts”; which inter-

action contexts are accessible to a specific user is described using an Interaction Map. Interaction contexts are classified as “first level”, if they are always accessible to the user, or “sequence” if they only are accessible by means of a navigation from another context. The Interaction Map also supports grouping a set of contexts as a “subsystem”. Interaction Contexts are further decomposed in Abstract Interaction Units or AIUs, which specify an atomic interaction, e.g., the retrieval of a set of data objects. An AIU is defined as an interaction view over the state of the Information System objects, defined in the Object Model. There are two types of AIUs: (1) Population AIU, which retrieves a chunk of data to interact with, and (2) Service AIU, which represents an interaction for a service execution from a set of input arguments. Therefore AIUs represent two main interactions: data retrieval and functionality execution. To further refine these two main types of interaction, Auxiliary Interaction Patterns (AIPs) are introduced to constrain their behavior. Examples of such patterns are “Filter”, which is used to constrain the data to be retrieved, or “Validation Rule”, which defines a boolean rule that must be accomplished by the input data. Currently, the Abstract Interaction Model includes thirteen of these patterns providing a wide array of interaction expressivity. Further details about the Abstract Interaction Model are discussed in [11]. Table 1. OOWS 2.0 modeling activities Web Application OOWS 2.0 Modeling Phase Activity Requirements User Requirement analysis Data and Object Functionality Modeling Interaction

User Modeling

Abstract Interaction Modeling

Presentation

Interface Modeling

Description Obtain the user requirements (URs) of the portal using classical UR engineering techniques. Describe the Information System data entities and services, using OO-Method models, in the Object Model (OM) Obtain the user types of the portal and their hierarchical relationship described in a User Diagram. For each user type, create the associated Interaction Map to specify all the Interaction Contexts (IC) Identify the set of Abstract Interaction Units (AIUs) that composes each IC, indicating whether it is a Population or a Service AIU, as well the Auxiliary Interaction Patterns (AIPs) to apply. Identify the set of the RIA interface widgets that represent each IC and AIUs.

3

Personal Genomics Web Portals: Lab Demo Setup

Thanks to the evolution of the DNA sequencing technologies, nowadays it is feasible to compare two different sequences of the DNA in order to detect differences in the genotype that will result in different phenotypes, i.e., different physical conditions. Current sequencing technologies to perform a full genetic study are becoming cheaper. As a consequence, DNA analysis will be a common activity at the healthcare domain. This led to the rise of a new field, called Personal Genomics, which involved individual genome analysis and sequencing with the aim of detecting variations that may imply health conditions. The sequencing and analysis of the genome provides useful information regarding health: 1) the risk percentage of an individual to have a particular disease, 2) the probability of transferring health conditions to his offspring, 3) ancestry studies to search for late family members or to inform the ethnic origin of a person, 4) advisement about more effective habits, e.g. diets or recommended food for a specific organism, and 5) drugs that perform better or are less dangerous for the person’s health. From a computer science point of view, Personal Genomics offers many challenges. Problems include huge amounts of data to store and handle, algorithmic complexity when handling DNA sequences (e.g., for sequence analysis), lack of standard data formats, constant evolution of the field leading to new, more refined data or invalidation of previous data, ethical issues about data privacy, difficulty in data summary and visualization or difficulty to comprehensibly present analysis data to the user. Nevertheless, the first Personal Genomics web portals have appeared. These Web Portals provide services for people interested in their health or, for health professionals interested in providing better diagnosis thanks to the patient’s genetic data. Because they deal with large amounts of sensitive data and complex algorithmics, and the challenge to present the genome analysis results in an easily browsable and userfriendly way, these web portals form an ideal testbed for Web Engineering methods. We chose two of the most successful web portals on Personal Genomics, 23andMe and DeCODEme, to perform a systematic reverse modeling engineering using OOWS 2.0. The lab demo has two objectives: 1) to verify the functional completeness of the OOWS 2.0 method, its models and modeling primitives, 2) to investigate the use of the method in a real-world setting. To be able to assess the latter, and to accurately represent the real-world situation where the method is used by external web developers, we recruited two software engineers (SE) that are skilled in information systems programming and web development, with more than three and ten years of experience, respectively, but no prior experience using OOWS 2.0 or any other Web Engineering method. The second group of participants in the lab demo is Web Engineering experts (WEE), which are experts in the Web Engineering field in general, and involved in the creation and development of the OOWS 2.0 method in particular. Table 2 gives a schematic overview of the lab demo. For each phase, the different activities that were performed are described, and the actors participating in these activities are indicated. We note that the reverse engineering activities are performed iteratively; in our case, three iterations were performed before correct and complete models were obtained.

Table 2. Phases and activities performed for the lab demo Phase Training

Activity Master courses

Tutorial

Reverse Modeling Engineering

Documentation Modeling

Model verification

Analysis

Model expressivity analysis Feedback form Interview

4

Description Actors SEs follow classes worth 6 ECTS-credits about SEs Model-driven engineering, modeling with and industrial tool based on OO-Method and Web Engineering methods (introducing OOWS). WEEs give a tutorial to the SEs explaining the WEEs, OOWS 2.0 method. The tutorial consisted of five SEs slide-based presentations, each of 2 hours. The SEs are given the available Phd thesis describSEs ing OOWS 2.0 and its metamodel. Each SE specifies one web portal (23andMe or SEs DeCODE) using OOWS 2.0 models. These modeling steps are detailed in Table 1. Specific parts that the SEs cannot model are indicated. Results of the modeling phase are verified by WEEs WEEs. Incorrect use of modeling elements is indicated. Incorrectly assessed parts that could not be modeled are marked, and the required modeling elements are indicated. The final models are quantitatively (amount of WEEs, models of each model types required) and qualitaSEs tively (amount of models able to correctly reflect the modeled page) analyzed. SEs are asked to give feedback (advantages, disSEs advantages, problems) concerning the use of the method in a free text form. WEEs take an interview from the SEs, based on WEEs, the feedback forms, to obtain further information SEs

Reverse Modeling Engineering Process

The modeling consisted of a systematic reverse engineering according to the OOWS 2.0 method. In this work, we focused on Interaction modeling, only by performing the activities of the Interaction phase in detail. We motivate this choice by indicating that requirements analysis is not relevant here, as the requirements are given by the existing Web portals. The Object Model of OOWS 2.0, which is taken from OO-Method, is equivalent to an UML profile of the Class Diagram. This Object Model has been extensively validated in industry and was shown to be functionally complete; therefore it is only used for defining the Abstract Interaction Units and we do not analyze it in more detail. Finally, Presentation modeling –where Web 2.0 support is included- is outside the scope of this article and subject of future work. Consequently, according

to Table 1, the performed activities were user and interaction modeling, and object modeling was only used to the extent needed for interaction modeling. The analysis of 23andMe & DeCODEme portals was conducted in July of 2011with a global effort of roughly 400 man-hours. 4.1

23andMe characterization

23andMe was founded in 2006 by Google, New Enterprise Associates and Genentech for research and educational use, as they state in their terms of service. At the time of writing, 23andMe contains over 100.000 analyzed DNA sequences. They offer a personal genomic service from a user-provided DNA sample, analyzing 966.983 SNPs of all the human chromosomes. From the results of this analysis, they offer information about ancestry and health conditions. 23andMe also performs research on correlation between SNP and conditions by means of surveys that users freely fill in. The main functionality provided by 23andMe is available using the demo profile The User Modeling phase revealed three user types: 1) anonymous, with access to the public site, 2) demo-registered, with access to the demo site of the personal genomic service and 3) genotyped-registered, with access to the actual personal genomic service to browse his/her DNA results after buying a DNA analysis kit and sending a DNA sample. The “genotyped” access of the web portal was not analyzed as we did not pay to gain access and the demo user offers an equivalent view of the interaction contexts of the personal genomic service. The Object Modeling phase required a significant amount of classes, which is explainable by the complexity of the domain. The portal offers a wide portfolio of personal genomic services and provides a huge amount of domain-specific knowledge. The Object Model can be structured in five main groups: 1) data about user information, including his DNA results, 2) classes for building knowledge reports, 3) classes to structure the user communities, 4) classes for developing ancestry information and 5) classes for storing and operating surveys. The modeled AUIs have used views on the Object Model with an average of 7 classes (highest 15; lowest 2) and 8 relationships (highest 22; lowest 2). The PAIUs with more classes are those related with reporting conditions that derivate from the DNA analysis. The Interaction Modeling phase revealed an inconsistent and confusing interaction map for anonymous users, with similar contexts with different structure, menus and navigational design, as well as excessive number of sequence interaction contexts (contexts only attainable from other contexts) and direct links. For demo-registered users, the interaction map is better structured and its navigation is more rational. Table 3 reflects the complexity of the application modeled. This table shows the total number of interaction contexts (IC) identified, classified according their type, and the total number of population abstract interaction units (PAIU) and service abstract interaction units (SAIU) identified to model all the ICs. The total number of ICs is the sum of the number of IC by type plus the “Home” interaction context. In order to distinguish between first level interaction contexts of the site and first level interaction contexts of a subsystem, the latter are labeled as “second level”. Subsystems and

1st level ICs are accessible from any location of the site, but there are some ICs that cannot be accessed from the 23andMe anonymous sitemap: 7 sequence ICs without access to the subsystems, 1 sequence IC inside a subsystem without access to second level contexts and 1 sequence IC without access to any subsystem or 1st level context. Table 3. 23andMe Interaction Modeling summary Illustrative Example 23andMe anonymous 23andMe demo

4.2

Total IC 1st Level 53 14 48 22

Subsys 3 0

2nd Level 16 0

Sequence PAIU SAIU 19 50 11 26 121 10

DeCODEme characterization

DeCODE Genetics is a biopharmaceutical company founded in 1996 and based in Reykjavík. At the time of the analysis DeCODE Genetics can analyze 1.072.820 SNPs along all the human chromosomes. They offer information about health conditions from user-provided DNA samples. The User Modeling phase revealed two user types: anonymous and registered. We only analyze the anonymous user type, as the registered user type requires payment and the anonymous user has access to a demo site which shows the functionality offered to registered users. The Object Modeling was less complex than for 23andMe, because DeCODEme offers less knowledge from the DNA samples than 23andMe, as far as we have been able to analyze. The domain model is made up of four main groups: 1) classes about users and their DNA analysis, 2) classes in order to structure the discussion forum, 3) classes related with health conditions and, 4) classes for structuring the news and the company events. The AUIs used an average of 4 classes (highest 7; lowest 1) and 4 relations (highest 8; lowest 1) from the Object Model. The Interaction Modeling phase revealed a well-structured consistent interaction map. The purpose of the public part of DeCODEme is to show which services are offered and how they work, in order to attract new customers. Anonymous user interaction is split up into two websites, one public and one for demonstration purposes. For that reason, the modeling task has been divided into two interaction maps. Similar as for 23andme, table 4 shows the total number of interaction contexts (IC) identified for deCODEme, classified according to their type, and the total of population (PAIU) and service abstract interaction units (SAIU). The deCODEme portal follows a hierarchical structure, hence sequence contexts are accessible through first level or second level interaction contexts. However, one interaction context of the deCODEme anonymous site map is, probably erroneously, only accessible through the sitemap. Table 4. deCODEme Interaction Modeling summary Illustrative Example Total IC 1st Level deCODEme anonymous 34 11 deCODEme demo 42 8

Subsys 3 7

2nd Level 16 17

Sequence PAIU SAIU 3 97 4 9 63 25

5

Analysis

By modeling the 23andMe and DeCODEme portals using OOWS 2.0, we obtained important information about the expressivity of the OOWS 2.0 models and the use of OOWS 2.0 itself. 5.1

Model Expressivity Analysis

The modeling of 23andMe and DeCODEme portals, using OOWS 2.0 Abstract Interaction Model, provided interesting data about its expressivity through analysis of the non-supported interaction contexts. Table 5 shows the percentage of ICs fully supported by the OOWS 2.0 Abstract Interaction Model. Every context of the 23andMe anonymous site is supported because all of them are static contexts with no data retrieval. However, only 27% of the contexts of the 23andMe demo site are fully supported. The main issue detected was that OOWS 2.0 filter AIP cannot specify a selected value by default (41.6% of the unsupported interaction contexts) and cannot be automatically activated (16.6%). There are also other issues that are summarized at the end of the section. DeCODEme is also not fully supported, with 31% of demo site ICs and 9% of anonymous site ICs not supported. As for 23andme, the main issue is the lack of semantics for filters specification (33.3% of anonymous portal and 38% of demo portal). Another detected issue is that surveys, which have to be automatically generated according to the user profile, cannot be precisely modeled (33% of anonymous and 15.4% of demo). Moreover, the need for conditional navigation, which is not supported by OOWS 2.0, was detected (23.07% of demo site). Table 5. OOWS 2.0 Expressivity Analysis Illustrative Example 23andMe anonymous 23andMe demo deCODEme anonymous deCODEme demo

Nº of IC 53 48 34 42

% fully supported 100% 27% 91% 69%

Table 5 shows that for both Web portals, the demo sites are less supported by OOWS 2.0 models, as these are more complex and heavily rely on underlying data and functionality. The main issues that were detected are 1) Filters always require the input of a value by the user and cannot be automatically executed, 2) Interaction Contexts access (first level or sequence) is statically specified, hence it is not possible to establish different access criteria for a context to different users or inside a subsystem, 3) Survey questions and answers cannot be automatically generated due to limitations in service arguments specification, 4) the absence of conditional navigations, 5) Advanced file data types, as multimedia content or binary, cannot be expressed and 6) List boxes with null values are not supported.

In conclusion, the expressivity analysis reveals several lacks in OOWS 2.0. The lacks do not consist of fundamental problems, but rather smaller issues that were overlooked during the academic work. Nevertheless, they do prevent OOWS 2.0 in its current state to be used for real-life Web applications. In section 6, we present solutions for two commonly encountered problems, namely filtering problems and advance navigation. 5.2

Feedback on the use of a model-driven Web Engineering method

Through a free-text feedback form and an interview with the software engineers that performed the lab study, we obtained valuable feedback on the use of OOWS 2.0 for a real-life complex Web application. The software engineers perceived several problems concerning the use of OOWS 2.0, most of which can be generalized to other academic Web Engineering method. First of all, the lack of industrial-style tool support with accompanying usability features was indicated. In particular, the software engineers complained about the lack of a modeling tool to draw the diagrams. Instead, the software engineers had to rely on UML or diagramming tools (Visual Paradigm and Visio) for creating the users maps and the interaction maps. The lack of tool support was perceived as frustrating, causing a significant reduction of the productivity of the modeling process. Second, the lack of complete code generation to provide a prototype product was criticized. Code generation was perceived as one of the main reasons for going through the modeling process, so the lack of possibility to generate a complete prototype was considered problematic. It also prevents quick prototyping and agile development, which in a Web context is considered important to react on customer comments and/or changing requirements. Third, some problems were indicated that relate to the size of the Web portals, which is significantly larger than usual proof-of-concept examples. For example, the lack of support for splitting larger models in smaller chunks was indicated. Also, easier duplication or re-use of similar parts of the model was indicated as problematic and time-wasting. Finally, some issues related to the learnability and documentation were mentioned. The software engineers found it difficult to understand OOWS 2.0 only from the documentation that was provided. They indicate that clear tutorials, with good and intuitive examples of use of each modeling constructs, as well as examples of when not to use certain modeling constructs, is required. Due to the lack of good documentation, the training, which overall was time-consuming, was essential for them to be able to use OOWS 2.0. On the other hand, the software engineers saw some clear advantages of using OOWS 2.0. Using the interaction modeling, and interaction map in particular, the software engineers detected several issues and inconsistencies in the structure of the existing Web portal. It was expected that using OOWS 2.0 to create a new Web portal, such inconsistencies would be avoided. Similarly, the software engineers expect that content would be better structured and more consistent throughout the Web portal using a Web Engineering method.

In conclusion, the software engineers indicated that currently, the advantages do not outweigh the disadvantages. They left with the idea that, using existing tools and web development frameworks, they would be more productive and more efficiently create a Web portal than with OOWS 2.0. The main problems preventing industrial adoption of OOWS 2.0 are 1) the lack of tool support, 2) the lack of complete code generation and rapid prototyping possibilities, and 3) the lack of practitioners-oriented documentation causing a steep learning curve. Any Web Engineering methods that aim to commercialize their approach should take these three issues in mind.

6

Method Extension

In this section, we propose two extensions to the Abstract Interaction Model in order to improve the modeling of the analyzed personal genomic portals. These extensions have been performed over the Abstract Interaction Model represented as an EMF metamodel [12]. 6.1

Advanced Navigation Structuring

One of the main issues detected is that modeling the complex structure of the Web Portals is not feasible. The reason is that the access criteria to an Interaction Context in OOWS 2.0 cannot be redefined for each user or subsystem. In the analyzed Web Portal, the global site map is grouped in several areas according to two main reasons: 1) in order to group a specific set of Web Pages with a related meaning (information about the company, tools for diagnosis, user profile utilities, etc.), and 2) to hide a specific sub-sitemaps that are not accessible until a previous navigation is followed. One example of the first scenario can be found in the webpage (https://www.23andme.com/you/) from 23andMe portal. In this case, the different links are grouped according to information about the user account, about the health, about the user ancestry, about the community of the website and about research experiments. The grouping is only to structure the information to the user and facilitate the navigation. Another example regarding the second scenario is the demo context from the DeCODEme website (http://demo.decodeme.com). When users navigate to this context, top menu changes completely showing a different set of links more related with the site functionality (diagnosis, gene comparisons, threats). At the home webpage, top menu links are related to information about the company. Both scenarios are a consequence of usability requirements, because a huge amount of navigational links, without some structure or specific meaning, compromises the user experience. For that reason, models from Web Engineering methods must provide mechanisms to create advanced navigation structures. The OOWS 2.0 models lack of a proper mechanism to model these scenarios. Though it provides the subsystem concept, this has been used as a simple aggrupation of contexts without additional semantics. Hence, the second scenario is not properly supported. Additionally, subsystems are represented as a webpage that only show the

links from the group. As a consequence, the first scenario from 23andMe also cannot be precisely modeled. Fig. 1. shows a metamodel extension to the Abstract Interaction Model (depicted in bold) for supporting both scenarios. First, a new abstract entity InteractionNode has been defined in order to classify the three entities that made up an Interaction Map: Subsystems, ContextAccess and ContexGroup. The new ContextAccess entity defines the accessibility to a specific Interaction Context for each user. This new entity avoids that different users must share the same accessibility for an Interaction context. Subsystems have also been redefined with the semantics of the second scenario and now can be considered as interaction sub-maps, with an optional home context and additional InteractionNodes. Because of the new subsystem semantics a new entity, ContextGroup, has been defined to support the simple grouping of Interaction Contexts.

Fig. 1. Metamodel extension for Hierarchical Maps

6.2

Filtering mechanisms

Web engineering methods provide conceptual primitives in order to represent chunks of information modeled as a specific query. In order to constraint the set of retrieved instances, is common to provide some filtering mechanisms. Filtering expressivity is a common mechanism in several methods and, usually, is based on some sort of logic formula that the retrieved data must fulfill. However, we have detected the requirement of some complex filtering features as whether the filtering is activated by the user or not, or to show only the data related to the user. For instance, in the 23andMe demo Interaction Contexts, all the genomic data shown is always constraint to the connected user. This filter is completely transparent because is automatically executed. The Abstract Interaction Model provides the Filter AIP to model these semantics. However, two main issues have been detected from the analysis performed: 1) Filter AIPs must be always activated as a consequence of a user interaction, though in most scenarios the activation is performed automatically; and 2) It is not possible to easily

constrain the information to the connected user. For both reasons is mandatory to extend the semantics of the Filter AIP. Instead of applying adaptation models, as proposed by [13], which will add more complexity to the OOWS 2.0 models, a light extension is a more suitable solution. Fig. 2 illustrates the metamodel extension. A new AIP name ConstrainAIP has been defined. This pattern shares some of the semantics of the current Filter AIP, but with two additions: 1) Formulas for Constraint AIP must be fully defined, i.e, they cannot have parameters to be introduced by the user; and 2) the activation is automatic by default if the byUser attribute is set to false. The inclusion of this new AIP also modifies the semantics of the Filter AIP because it cannot have formulas without user parameters. Also it has been include the attribute defaultValues. This attribute defines an optional list of values in order to set the formula parameters. As a consequence, if the list is defined, the filter is also automatically applied.

Fig. 2. Metamodel extension for filtering mechanisms

7

Related Work

Some works have also analyzed how Web Engineering methods are applied in practice. Garzotto et al [7] present the results of an empirical study that highlights the features that prevent, or contribute to, the adoption of Web Engineering methods in a business environment. From the study, they extract some general lessons learnt. In the same reasoning line, a recent work carried out by Lam [14] investigates what methodologies, tools, and techniques are used by Web developers. The research work is based on interviews to Web developers from the United States. Both works also indicate that traditional Software Engineering methodologies and techniques are the most usually applied in Web development. However, the results of both works are mainly based on the feedback and experience of the interviewed developers, and are not obtained from practitioners using a Web Engineering method on a real-life Web system. In fact, both studies show that the awareness of Web Engineering methods in practice is very low. Mendes [6] presents the results of a systematic literature review

aimed at investigating the rigor of claims arising from Web engineering research. This work is based on a set of relevant Web Engineering research papers. For that reason, the work has a clear academic setting and it is mainly focus on the empirical concern. In the Web Engineering community have been several joint research works in order to compare different methods. Some examples are the Web Engineering research book edited by Rossi et al. [15] or the research works presented at the first IWWOST workshop (http://users.dsic.upv.es/~west/iwwost01/). Both research initiatives are based on a single case study, respectively the Internet Movie Database and a conference review system, that is modeled using the different methods with the aim of establishing a comparative scenario. The aim of these works is different from ours: the particular cases were not extensively modeled, and are used to illustrate the respective methods, neither to perform an expressivity analysis nor an analysis of the use of the method. Furthermore in those works, the method researchers perform the modeling, while our analysis has been carried out by external software engineers.

8

Concluding Remarks

This work presents a preliminary analysis to examine the use of a Web Engineering method, OOWS 2.0 in practice. A lab demo was set up using two personal genomics portals, 23andMe and DeCODEme, with as goal to assess the functional completeness of OOWS 2.0 and to gain insight in a real-world, complex scenario. The analysis revealed several problems and lacks faced by the software engineers using the OOWS 2.0 method. Examining these problems we noticed that most of them are not fundamental problems, yet caused by the academic nature of the method and the lack of extensive testing. For two of these problems, we provided a solution. Moreover, the learned lessons provide interesting feedback about the use of Web Engineering methods in practice. In particular, for Web Engineering methods aiming for industrial adoption, we can formulate the following recommendations based on our experience from this experiment: 1) rigid tool support should be provided, 2) code generation and rapid prototyping should be provided, and 3) practitioners-oriented documentation is essential. To obtain more support for these recommendations, more extensive experiments should be performed. In any case, we can conclude that performing an extensive experiment as we did in this paper may also be useful for other methods to detect problems and assess their use in a real-world scenario. Future works consists of completing the lab demo to also include presentation modeling. Furthermore, we will analyze how other Web Engineering methods have dealt with the detected issues, and based on this analysis will formulate solutions for all problems. Following this, we will apply the revised OOWS 2.0 models to develop a new personal genomics portal. Acknowledgement. This work has been developed with the support of GVA under the project ORCA (PROMETEO/2009/015), the project PROS-Req (TIN2010-19130C02-02), and co-financed with ERDF. Sven Casteleyn is supported by a European

Commission Marie Curie Intra-European Fellowship (IEF) for Career Development under the Seventh Framework Program (FP7), FP7-PEOPLE-2009-IEF, N° 254383.

References 1. Ceri, S., Fraternali, P., Bongio, A.: Web Modelling Language (WebML): a modeling language for designing Web sites. Computer Networks 33, 137-157 (2000) 2. Schwabe, D., Rossi, G., Barbosa, S.: Systematic Hypermedia Design with OOHDM. In: ACM Conference on Hypertext. ACM, vol. 17(1), pp. 116-128. ACM Press (1996) 3. Garrigós, I., Casteleyn, S., Gómez, J.: A Structured Approach to Personalize Websites Using the OO-H Personalization Framework. In: Web Technologies Research and Development APWeb 2005, pp. 695- 706. Springer-Verlag Berlin Heidelberg (2005) 4. Troyer, O., Casteleyn, S., Plessers, P.: WSDM: Web Semantics Design Method. Web Engineering: Modelling and Implementing Web Applications. In: Human-Computer Interaction Series, vol. 12, pp. 303-352. Springer (2007) 5. Fons, J., Pelechano, V., Albert, M., Pastor, O.: Development of Web Applications from Web Enhanced Conceptual Schemas. In: 22nd International Conference on Conceptual Modeling (ER 2003). LNCS, vol. 2813, pp. 232-245. Springer, Heidelberg (2003) 6. Mendes, E.: A systematic review of Web Engineering research. In: International Symposium on Empirical Software Engineering, pp. 498-507. Noosa Heads, Australia (2005) 7. Garzotto, F. Perrone, V.: Industrial Acceptability of Web Design Methods: an Empirical Study. Journal of Web Engineering. 6(1), 73-96 (2007) 8. Pastor, O., Molina, J.C.: Model-Driven Architecture in Practice. A Software Production Environment Based on Conceptual Modeling. Springer-Verlag, New York (2007) 9. Valverde, F.: OOWS 2.0: Un método de Ingeniería Web Dirigido por Modelos para la producción de aplicaciones WEB 2.0. Information Systems and Computation. PhD thesis. Universitat Politècnica de València, Valencia (2010) 10. Valverde, F., Pastor, O.: Facing the Technological Challenges of Web 2.0: A RIA ModelDriven Engineering Approach. In: Web Information Systems Engineering 2009. LNCS, vol. 5802, pp. 131-144. Springer, Heidelberg (2009) 11. Valverde, F., Panach, J.I., Pastor, Ó.: An Abstract Interaction Model for a MDA Software Production Method. In: 26th International Conference on Conceptual Modeling (ER 2007), pp. 109-114. Australian Computer Society Inc., Australia (2007) 12. Budinsky, F., Steinberg, D., Paternostro, M., Merks, E.: EMF: Eclipse Modeling Framework. Addison-Wesley Professional (2009) 13. Dolog, P., Bieliková, M.: Navigation Modelling in Adaptive Hypermedia. In: De Bra, P., Brusilovsky, P., Conejo, R. (eds.) Adaptive Hypermedia and Adaptive Web-Based Systems, pp. 586-591. Springer Berlin, Heidelberg (2006) 14. Lam, M.: Methodologies, tools, and techniques in practice for Web application development. Journal of Technology Research. 3 (2011) 15. Rossi, G., Pastor, O., Schwabe, D., Olsina, L.: Web Engineering: Modelling and Implementing Web Applications. In: Human-Computer Interaction Series, vol. 12, pp. 263–301. Springer, Heidelberg (2008)