The treatment of navigation in web engineering

The treatment of navigation in web engineering M.J. Escalona * , J. Torres, M. Mejı ´as, J.J. Gutie ´rrez, D. Villadiego Department of Computer Languages and Systems, University of Seville, Seville, Spain Abstract This paper aims at giving a global vision of the most popular web engineering approach. Web systems have woken up a high interest in companies and in the research community in the last years. Thus, techniques and methods are being proposed in order to offer a suitable framework to deal with the special characteristics of the web. For these reasons, some years ago a new line in the software engineering appeared. This line, then named web engineering, has grown in the last years, proving that web systems have special characteristics that require a special treatment. One of the most treated characteristic is the navigation. Navigation is a critical aspect in web systems and its suitable development in the life cycle is a basic need to guarantee the project quality. This survey shows how navigation is treated in 15 web proposals, which are the most referenced ones, and it analyses the available techniques, models and the possible gaps in the treatment. Keywords: Software engineering; Web engineering; Navigation treatment; Tools 1. Introduction Since the Net of Nets was born in the 1970s, as a net to spread research material, an amazing change in the use of Internet has taken place [1]. In the last years, Internet has become a popular tool and the number of users who work every day with it has grown crazily. Companies and organizations find in Internet a suitable way to present their businesses, and, also, a powerful way to contact with their clients and employees all over the world. This evolution, the high advance of communications and the increase in the benefits of the equipment, networks and routes of transmission have led to the fact that most of the actual systems are developed or adapted to Internet. Since the development of software systems in Internet appeared, the research community has detected the necessity of proposing new methodologies, techniques and models to offer a suitable reference environment for the new and special characteristics of Internet. For this aim, a new research line in the software engineering has been developed in the last years: web engineering [2]. Web engineering is the systematic,structured and quantifiable application of methodological proposals to the development, evaluation and maintenance of web applications [2]. At first, the development of web systems was an ad-hoc process. Applications were developed without following any structured process which guaranteed the quality of the results. When the web engineering appeared as a new research line, several new methodological approaches were proposed and some surveys and comparative studies agreed that it was necessary to offer new methodological environments to deal with the special characteristics of the web [3–9]. Nowadays, the research community accepts all over the world the idea that web projects have special characteristics (critical navigation, hypermedia, customization, etc.) that must be dealt carefully in the life cycle and that need their own models and techniques [10,11]. One of the most critical and special characteristic of the web environment is the navigation. The treatment of navigation is an aim which has led several research groups to propose and develop special models to deal with it in * Corresponding author. Tel.: +34 954 553 867; fax: +34 954 557 139. E-mail addresses: [email protected] (M.J. Escalona), [email protected] (J. Torres), [email protected] (M. Mejı ´as), [email protected] (J.J. Gutie ´rrez), [email protected] (D. Villadiego). the life cycle. This paper is focused on the analysis of the actual situation of web engineering in the treatment of navigation. It also shows how some of the most popular web proposals deal with navigation and compares the different approaches. The main aim is to show that navigation is a critical aspect deeply studied by a high number of research groups, like it was concluded in several comparative studies [3,6], but the paper also tries to show the gaps and the main problems found in these approaches. In this sense, this paper follows the idea of previous surveys that compare web methodologies in order to find their advantages and disadvantages. Comparative studies like [3–7] analyse web proposals from a general point of view. This paper is a survey focused on the navigation treatment. However, before starting to describe the proposals, it is necessary to outline some important aspects. First of all, the research community does not accept any standard approach. The paper analyses deeply 15 methodologies. Although there are more approaches, these ones are a very representative group. The other ones were not selected in the study for several reasons. Some of them have only been proposed [12] and there are not too much references of them. Other works are mainly focused on the last phases of the life cycle and they do not offer special information for the environment of this work [13–17]. It is also necessary to stick out that the web engineering is a very recent research line. Most of proposals are continually being revised and they are very often extended or corrected. New models, techniques or phases of the life cycle are continually added. The offered study is based on the last information found or even asked to the own authors. Finally, it is necessary to indicate that one of the main problems found when a comparative study is presented in the web engineering environment, is the variability of the terminology and the lack of standards. However, as it will be described, we can observe a recent eagerness to try to offer some standard aspects. This study has been divided on two main blocks. In Section 2, the first one presents each studied proposal. For each one, the life cycle is presented with an activity diagram [18] and the treatment of the navigation in the life cycle is outlined. The second block, in Section 3, offers a comparative study and an analysis of situation. Relations and common points in the proposals are analysed in Section 3.1. In Section 3.2, the concept of navigation and its different meanings in each methodology is presented. In Section 3.3, the treatment of the navigation in the life cycle in each proposal is analysed. And, in Section 3.4, techniques proposed by each methodology to deal with navigation in each phase of the life cycle is presented and compared. Finally, in Section 4, the paper details the conclusions and the final analysis. 2. Web engineering proposals This section presents a short vision of each analysed proposal. In order to present a graphical vision of its life cycle, each proposal description has an associated activity diagram, excepted HDM (hypermedia design model) [19] which has a class diagram. This short vision is the base for the comparative study in the following section. 2.1. HDM – Hypermedia Design Model HDM [19] had been the first approach to support the hypermedia information. HDM is not really a development methodology. In fact, HDM is an extension of ERDs (entity–relation diagram) [20,21] to which some new aspects to model hypermedia systems were added. HDM proposes a set of elements that allow the designer to specify an hypermedia application. These elements are entities, components,perspectives,units and links. All of them can be included in the classical semantic of ERDs. However, although classical elements like entities of ERDs are present in HDM, they had been extended in order to model complex navigational structures with links and internal navigation semantics. In conclusion, a specified application with HDM is a general structure composed by basic units, named entities. An entity represents a physical or conceptual object in the system. Entities are grouped in kinds of entities which are each one defined with a name, a group of perspectives that presents how the information of the entity can be showed and a set of application links to navigate through the information. Entity is the minimal autonomic unit in each HDM model, although there are other concepts. Each entity is composed by hierarchical components which inherit the properties of the entity. Those components cannot exist without their entity. They are the elements that design groups of units and nodes to present the same set of information of the entity. A unit is a repository of information managed by the application. It represents a fragment of the content of an entity shown in a concrete perspective. In this sense, each perspective lets represent multitude of presentations of the same piece of information (for instance, the presentation of a document in multiple languages). In Fig. 1, a class model shows the relations between these elements. Nowadays, HDM is not used. Mainly for two reasons: the first one is because the structured paradigm had been Entity Component 1..n1..n Unit 0..n Perspective 0..n 1..n +repository 0..n 0..n 1..n Fig. 1. Relations between HDM elements. substituted by the object-oriented paradigm. Thus, developers prefer object-oriented methods. Besides, although HDM proposes ideas to develop hypermedia systems, it is not a methodology. It is just a model. However, although it is not used, HDM has been the base for other approaches. Some methodologies like RMM (relation management method) [22], OOHDM (object-oriented hypermedia design method) [23] and W2000 [24], accepted and adapted HDM ideas in their life cycles. 2.2. RMM – Relationship Management Method RMM [22], unlike its predecessor HDM, can be considered as a methodology because it covers the complete life cycle. Its process is composed by seven phases that allow to model the structure of the application and its possibilities of navigation. The proposal is based on the ERD and HDM models, from which RMM defines a new model, named RMDM. It offers a special graphical language to describe domain objects, their inter-relations and the ways to get the hypermedia navigation of the application. Fig. 2 shows the life cycle of RMM. The process starts with the development of the E–R model, without taking navigation or presentation details into account. In this sense, the model is developed as in a non-hypermedia system. Next, the design of slices must be done. A slice is a subset of entities attributes which are going to be present together to the user. It will be a view of the system. The slice design is enriched with the navigation design. Both make the RMDM model. In base of this model, the process continues with the fourth phase called defining the protocol of conversion that allows to go from the RMDM model to the concrete development platform. After that, the next step is the design of the interface that is to say the development of screen for the users. Then, we have the implementation of the application in the selected computer language, and, finally, the process ends with the testing of the results. 2.3. EORM – Enhanced Object Relationship Methodology With OOHDM, EORM [25], in one of the first web proposals, focuses on the object-oriented paradigm. It gets many ideas from HDM, but translates them in the object-oriented paradigm. Its life cycle is a classical one, as shown in Fig. 3. EORM structures the development process in three phases: analysis,design and construction. The analysis phase does not have exactly the same aims as in other proposals. Analysis phase in EORM is the object design using the OMT model [26]. In this phase, aspects like navigation or interface are not modelled [27]. Then, the design phase modifies the class model obtained previously adding new semantic to model links and navigation. This object model with the navigation aspects is named EORM and it presents the structure of the system and the navigation possibilities. Finally, in the construction phase, all these aspects are implemented in the concrete computer language. 2.4. OOHDM – Object-Oriented Hypermedia Design Method Perhaps, OOHDM [23,28] has been the most referenced and studied web methodology in the last years. At the beginning, it was based on HDM but then it has been focused on the object-oriented paradigm. Its main contribution is the high acceptance of its life cycle presented in Fig. 4. The process starts with the design of conceptual classes. The static structure of the system is designed at this stage of the class diagram. The next phase is the navigation design which develops a navigational model. The latest offers a view of the Develop the ER Model Develop slices Design the navigation Design the protocol of conversion Design the interface Implement Test the application Fig. 2. Development process of RMM. Implement Analyse Design Fig. 3. Development process of EORM. conceptual model that expresses how the user can navigate through the information modelled in the first stage. In the third phase, the abstract interface design, a third model, named abstract interface model, is designed. This model describes how the information will be presented to the user. Thus, the navigation model is a view of the conceptual model and the abstract interface model is a view of the navigational model. In the last phase, the implementation of the three models is programmed. In each above mentioned phases, OODHM offers specific models languages to represent these models. Some of them, like the navigation context or the abstract data views are not used nowadays. However, the research community widely accepts other ideas of OOHDM, like representing navigation model with a special class diagram named navigational class diagram. Separating the modelling of different aspects in hypermedia systems is another very accepted idea of OOHDM. Most of proposals defined before OOHDM widely accepted and assumed the idea of modelling conceptual, navigation and abstract interface aspects in a separate way. Finally, it is necessary to stick out that OOHDM is not a static proposal [29]. Nowadays, it is being improved and enriched. For instance, it has been extended with a requirements phase using an own technique named UIDs (user interation diagrams) [30–33]. 2.5. WSDM – Web Site Design Method The method of designing web sites (WSDM) [34] is a proposal that defines the system according to the users groups. Its life cycle is divided into four phases: user’s model,conceptual design,implementation design and implementation. As well, the user’s model is divided into two subphases: classification and description and the conceptual design into two phases: object modelling and navigational design. WSDM life cycle is presented in Fig. 5. The development of the user’s model studies possible roles of users who are going to interact with the system and also their relations. In the next phase, and according to the previous users’ classification, the conceptual model of the system is developed. However, the conceptual model does not have the same meaning as in OOHDM. During the conceptual modelling two tasks are applied together; the object modelling, that is the same as the conceptual modelling in OOHDM, and the navigation modelling, that is the same as the navigational modelling in OOHDM. Besides, in WSDM, more than one navigational model exists. Each role detected in the first phase has its own model. Then, the implementation design phase models the specific interface for each role. Finally, in the implementation phase all these aspects are codified in the selected language. WSDM is also a live methodology. It is being changed and adapted to new requirements. Nowadays, one of the most interesting works of this research group is the development of a CASE tool that lets apply the WSDM life cycle [35,36]. 2.6. SOHDM – Scenario-based Object-Oriented Hypermedia Design Methodology SOHDM [37,38] is one of the first web proposals that deals with requirements. Its main contribution is its life cycle because it starts with the application of scenarios like a technique to elicit and define requirements [39]. Its development process is divided into six phases presented in Fig. 6. Design the conceptual model Design the navigational model Design the abstract interface model Implement the system Fig. 4. Development process of OOHDM. Develop the user's model Classify users Describe users Develop the conceptual design Design the object model Design the navigational model Design the implementation Implement Fig. 5. Development process of WSDM. The process starts with the analysis phase in which a study about the necessities, the environment and actors must be done. The main objective of this phase is to design scenarios that describe activities in the system. Then, the phase ‘‘object model’’ develops a class diagram to describe conceptual information. In the next phase, the development of views, objects are reorganized in navigational units that represent a view of the system objects. In the design of the navigational model, these views are enriched with links and hyperlinks. After that, web pages, interface and the database are designed, in the implementation design phase. Finally, the construction phase builds the application. 2.7. RNA – Relationship-navigational analysis Contrary to other proposals, RNA [40] does not cover several life cycle phases. Its development process is focused on the analysis phase. However, in this approach, the concept of analysis is not exactly the same as in other proposals. In fact, this approach includes activities in the analysis while other approaches include its in phases like the requirements or the design ones. Fig. 7 shows a diagram with its life cycle. It starts with an environment analysis, in which the audience characteristics are studied and classified and the different roles of the system are analysed. After that, interest elements like screens, documents, etc. which are going to be required during the development process, are defined. The process continues with the knowledge analysis, which develops a scheme to represent the system. In the latest, objects, processes and methods that have to be offered are identified. Then, an analysis of the navigation describes how the user will be able to navigate through the system. And to finish, the analysis has to be implemented. 2.8. HFPM – Hypermedia Flexible Process Modelling Strategy HFPM [41] is one of the most complete proposal because it covers a deep life cycle. In fact, it does not offer new models or techniques and assumes many OOHDM’s ideas. However, it covers a complete development process, and even generates documents. In Fig. 8, its life cycle scheme is presented. In this process, each phase is divided into tasks and subtask, offering a very detailed development guide. The process starts with the development of a requirements model and a planning and continues with the phase of conceptual modelling,navigational modelling and abstract Analyse Develop the object model Develop views Design the navigational model Design the implementation pages interfaces database Design Design Design the Build the system Fig. 6. Development process of SOHDM. Analyse the environment Define interest elements Analyse the knowledge Analyse the navigation Implement the analysis Fig. 7. RNA development process. interface modelling, which are similar to the OOHDM ones. The next step is the environment design and the capture and edition of the multimedia elements, with the description of the multiple media that appear in the system and also storage systems which will be used. Thanks to that knowledge, the system is implemented. The validation and the verification are then applied like some metrics to measure the quality of the system. Finally, the process ends with the maintenance and documentation generation phases. 2.9. Building web applications with UML The Conallen’s proposal [42] is a suggestion which has gotten a good acceptance in the last years. It is completely based on UML and on the unified process in its life cycle. It defines a high number of its own UML extensions and specific stereotypes for the web. Its life cycle starts with a previous phase of planning. Then, a cyclic process covering requirements treatment, analysis,design,implementation,test and evaluation phases starts. When the system is accepted, the phase of maintenance starts. This process is shown in Fig. 9. Basically, the models and techniques offered by Conallen are inherited from UML. However, they enrich and define several new specific model elements for web environment like the possibility of representing java beans, frames, bottoms, etc. These new stereotypes can be included in rational rose and used easily during the modelling. 2.10. WebML – Web Modelling Language As it is defined by its authors [43,44], WebML is a notation to specify complex web sites in the conceptual environment [45]. It gives a description of the web from different points of views: conceptual, navigational, presentational, etc. Its life cycle is presented in Fig. 10. The development process starts with the conceptual modelling of the system. In this phase, in which using a model language like UML, WebML does not specify any concrete, the static structure of the system is presented. After that, we deal with the development of an hypertext model in which hypertexts that can be published on the web are described. Each hypertext defines a view of the web site. The description of hypertexts is made using two models: the composition model, that defines the pages in the system, and the navigation model, that describes the navigation through them. In the next step, the presentation model, which defines the physic appearance of the web pages, is developed. And, finally, the personalization model underlines how the system has to be adapted to each role of user. In order to conclude, we have to stick out that one of the most interesting contribution of WebML is that it offers a tool CASE named WebRatio that lets apply the proposed techniques and get the results systematically [46]. Model requirements Make planning Design the conceptual model Design the navigational model Design the abstract interface model Design the environment Capture and edit multimedia elements Implement the system Verify and Validate Value quality Develop the maintenance Generate documentation Fig. 8. Development process of HFPM. Make planning Define requirements Analyse Design Implement Test the application Value non final version Develop the maintenance final version Fig. 9. Conallen’s development process. 2.11. UWE – UML-Based Web Engineering UWE [47] is a methodological proposal based on the unified process [48] and on the UML to develop web applications. UWE covers the complete life cycle of web applications and focuses its work on customized and adaptive systems. Its development process is divided into three main phases: the requirements capture, the analysis and design phase and the implementation phase. The development process of UWE is mainly focused on the analysis and design phase. This development process is completely detailed and defined, also the structure of these models. A scheme with its general phases is presented in Fig. 11. UWE makes a very detailed description of its phases. Thus, although it was not presented in the figure in order to avoid making it too much complex, UWE proposes the next phases: 1. In the requirements phases, UWE proposes to start with the users’ identification and the elicitation of requirements. It deals with requirements depending on if they are information requirements, navigation requirements, adaptation requirements or user interface requirements, and also some related additional requirements, like hardware or security constraints. Then, it focuses the work on the development of use cases, the generation of glossaries and the development of prototypes of the user interface. 2. The analysis and design phase is quite similar to the OOHDM one. However, UWE covers more aspects than OOHDM. In fact, UWE separates conceptual design,user model,navigation design,presentation design, adaptation design,design of the architecture and the detail design of classes, subsystems and interfaces. 3. Finally, in the implementation phase, UWE includes tasks that let the implementation of all the previous models: architecture implementation,hyperspace structure implementation,model user implementation,adaptive model implementation and all the tasks that deal with the integration of these implementations. Focusing UWE’s study on the treatment of navigation, UWE proposes in its requirements phase an elicitation of navigation requirements. UWE considers navigation requirements like functional requirements and, although it does not propose specific techniques for its treatment, the navigation requirements treatment is mainly made using use cases. UWE separates the navigational requirements in order to identify better relevant aspects for the navigational model in the analysis and design phases. This navigational model is built in two steps. In the first one, a navigation space model, built like a view of the conceptual model, is developed. This model shows that classes and models are accessible using a special class diagram with special classes named navigational classes. These are UML classes stereotyped with special tags. This model is enriched in the second step with the model of the navigation structure which presents the way to visit the accessible elements. The final navigation model includes both submodels and using then, it details the accessible elements and the way to navigate between them. In the last years, UWE proposal has getting a big acceptance in the research forums. Its models are completely based on UML, so they are being very good valued. Besides, UWE is an alive proposal. Nowadays, they are working on a tool to support its life cycle, named ArgoUWE [49]. 2.12. W2000 The W2000 proposal [22] has been the evolution of the object-oriented paradigm of HDM. W2000 is different to HDM in two basic ideas. The first one is that HDM was only an enriched model of ERD, but not a methodological proposal. W2000 proposes a life cycle to develop web systems. The other big difference is that W2000 is focused on the object-oriented paradigm. However, despite of these differences, HDM assertions are been accepted in W2000 and adapted to the object-oriented paradigm. The W2000 life cycle is shown in Fig. 12. The process starts with a requirements analysis phase mainly based on Develop the structural model Develop the hypertext model Design the composition model Design the navigational model Model the presentation Model the customization Fig. 10. WebML’s development process. Capture requirements Analyse and Design Implement Fig. 11. Development process of UWE. use cases. Thanks to the knowledge of this requirements phase, the process continues with the hypermedia design phase. In this phase two models are developed: the conceptual and the navigational model. For that, W2000 modifies and extends some UML models like the class diagram and the state diagram. The last phase is the functional design phase, in which the sequence diagram is used to express the functionality of the system. An important characteristic of W2000, which is outlined in the next section, is the separation of the navigation aspect and the information structure since the very firsts phases of the life cycle. As it is shown in Fig. 12, W2000 proposes a functional and a navigational requirements analysis. However, the used technique in both kinds of analysis is the use cases one, without specifying how both kinds of requirements can be separated, dealt, identified or elicited. 2.13. UWA project – Ubiquitous Web Applications The UWA project [50] is a European project in which several research groups worked together several years ago. In fact, the most of approaches, techniques or models presented in its life cycle is an heritage of other approach like W2000. The UWA development process is divided into four big phases, as it is shown in Fig. 13. 1. The elicitation of requirements is the phase that defines the functional requirements. It is a requirements elicitation based on objectives. The process starts defining the high level requirements and, from them, the necessities of the systems are systematically concreted. 2. The hypermedia design, is the phase in which data, navigation, data presentation and users’ services are modelled. This phase comes from W2000. In fact, UWA proposes three models to represent the hypermedia: the information model, the navigation model and the presentation model. 3. The transaction design models, the behaviour of the interaction transactions and their effects in the system. Transactions are modelled according to two point of views: the static point of view, which studies what transactions can appear, and the dynamic point of view, which analyses the effects of these transactions. 4. The customized design analyses how the application has to be adapted to the context in which it is executed. This phase is an heritage of WUML [16]. This web proposal is not included in this study because it is only focused on the last phases of the life cycle. It uses components like implementation technique. UWA, in fact, proposes to design the customization with components. 2.14. OOH – Object-Oriented Hypermedia Method OOH has got as main objective, the application of the object-oriented paradigm to capture the semantic to the efficient modelled of user interfaces and its implementation on the web environment [51]. The idea of OOH is to offer a methodological environment to let the systematic model of adaptive interfaces being suitable for the group of users. Its life cycle, as shown in Fig. 14, starts with a requirements analysis and is followed by an engineering phase. In the latest, the analysis and the domain and navigation design, and also the presentation design are developed. Then, there is a construction and adaptation phase in which the final system is obtained with a set of templates. The last stage includes the interface evaluation by the user. All these phases are very focused on the user’s roles. A very important characteristic of OOH is that it designs its interfaces and its navigation aspects adapting its to each user’s role and his/her specific necessities. Elicit requirements Design the hypermedia Design the information Design the navigation Develop the transactional design Design the customization model Fig. 13. Development process of UWA. Analyse requirements Analyse functional requirements Analyse navigational requirements Design the hypermedia Design the information Design the navigation Design the functionality Fig. 12. Development process of W2000. But, perhaps one of the most interesting aspect of OOH is its tool, named Visual WADE [52], that covers the complete life cycle of OOH. 2.15. NDT – Navigation Development Techniques NDT is a very recent proposal [53–55] based on some previous comparatives studies. NDT is a proposal that only works in the requirements and analysis phases. It offers specific methods and techniques to deal with web requirements and to get from them the analysed models applying some systematic process. The life cycle of NDT is presented in Fig. 15. In the first phase, the requirements phase, each kind of requirements is treated depending on its kinds. NDT supports storage information, actors’, functional, interaction and non-functional requirements. For each of them, NDT proposes a specific pattern, that is to say a structured template which defines specific and necessary information that describe a kind of requirements. Patterns are the base of NDT. Patterns give a very structured definition of very useful requirements to propose systematic processes that allow to derive analysis models from the requirements patterns. In the analysis phase, NDT propose to develop three models: the conceptual model, the navigation model and the abstract interface model. In this sense, a strong influence by OOHDM can be detected in NDT. However, the biggest influence on NDT is UWE. NDT assumes UWE notations as models. In this sense, NDT proposes a new phase of requirements but, after that, it is possible to complete the rest of the process using another web proposal, mainly UWE’s one. That is because NDT assumes that posterior phases of the life cycle have been being treated enough in the web engineering and tries to give support in the less treated phase, the requirements one. The systematic generation of analysis models has actually two phases. In the first one, analysis models are systematically generated from the requirements models, these are the basic analysis models. After that, analysts can make some changes to these basic models in order to adapt them better to the reality of the system. However, NDT manages the possible changes in order to check that there are not inconsistencies between the final models and the requirements. Lastly, two important points about NDT have to be stuck out. The first one is that NDT has a tool, named NDT-Tool [56], that allows to apply all the NDT techniques, to get final results and to apply automatically generation processes. This tool is compatible with rational rose and generates models and results automatically. The second point is that NDT is a very practical methodology. It has been applied in several real projects in the last years, getting very good results [57,58]. 2.16. Other studied approaches In this survey, we have presented a short vision of fourteen proposals. However, this sample is only a subset of the high number of web engineering proposals that have been presented in the last years. This survey only gives the closest proposals to the treatment of navigation or the most Analyse requirements Engineering Construction and adaptation Client evaluation Fig. 14. Development process of OOH. Deal with requirements Capture Define Validate correct? no yes Analyse Generate basic models Generate final models inconsistent? yes no Fig. 15. Development process of NDT. [52] VisualWADE Tool. University of Alicante. http://gplsi.dlsi.ua.es/ iwad/ooh_project/index.htm. [53] Escalona MJ. Modelos y te ´cnicas para la especificacio ´n y el ana ´lisis de la navegacio ´n en sistemas software. PhD Thesis, University of Seville, Seville, Spain, 2004. [54] Escalona MJ, Mejı ´as M, Torres J, Reina AM. The NDT development process. In: Proceedings of IV international conferences on web engineering. LNCS, vol. 2722. Springer-Verlag; 2003. p. 463–7. [55] Escalona MJ, Mejı ´as M, Torres J. Developing systems with NDT & NDT-Tool. In: 13th International conference on information systems development: methods and tools, theory and practice, Vilna, Lithuania, 2004. p. 149–59. [56] Escalona MJ, Mejı ´as M, Torres J, Reina AM. NDT-Tool: a tool case to deal with requirements in web information systems. In: Proceedings of IV International Conferences on Web Engineering. LNCS, vol. 2722. Springer-Verlag; 2003. p. 212–3. [57] Escalona MJ, Leo ´n A, Martı ´n A, Mejı ´as M, Torres J, El Tesauro de Patrimonio Histo ´rico de Andalucı ´a. In: IV Jornadas de Bibliotecas Digitales, Alicante, Espan ˜a, 2003. p. 105–14. [58] Villadiego D, Escalona MJ, Torres J, Mejı ´as M. Aplicacio ´n de NDT al sistema para el reconocimiento, declaracio ´n y calificacio ´n del grado de minusvalı ´a. Internal Report LSI-2004-02, University of Seville, 2004. [59] Mecca G, Atzeni P, Crescenzi V. The ARANEUS guide to web-site development. Technical Report, Universidad de Roma, 03 1999, Roma, Italia, 1999. [60] Nanard J, Nanard J. Hypertext design environments and the hypertext design process. Commun ACM 1995;38(8):49–56. [61] Thomson J, Greer J, Cooke J. Algorithmically detectable design patterns for hypermedia collections. In: Workshop on hypermedia development process, methods and models. Hypermedia, 1998. [62] Liddle SW, Embley DW, Woodfiel SN. A seamless model for objectoriented systems development. In: First international workshop on web-oriented software technology, Valencia, 2001. [63] Liddle SW, Embley DW, Woodfiel SN. An active, object-oriented, model-equivalent programming language. In: First international workshop on web-oriented software technology, Valencia, 2001. [64] Eklund J, Lowe D. Using partial design to elicit requirements in web development – a survey of commercial practice, 2001. [65] Lowe D, Eklund J. Client needs and the design process in web projects. In: Web engineering track of the WWW2002 conference, 2002. [66] Garzotto F, Mainetti L, Paolini P. Hypermedia design analysis, and evaluation issues. Commun ACM 1995;38(8):74–86. [67] Escalona MJ, Koch N. Requirements engineering for web applications: a comparative study. J Web Eng 2004;2(3):193–212. [68] Cachero C, Koch N. Navigation analysis vs. navigation design. An example for discussion. Internal Report, University of Alicante, TRAp02b, Alicante, Spain, 2002. [69] Cachero C, Koch N. Conceptual navigation analysis: a device and platform independent navigation specification. In: 2nd International workshop on web-oriented software technology, Ma ´laga, Spain, 2002. [70] Jacobson I, Booch G, Rumbaugh J. The unified software development process. Addison-Wesley; 1999.