NDT. A Model-Driven Approach for Web Requirements

NDT. A Model-Driven Approach for Web Requirements Marı´aJos´eEscalona and Gustavo Arago´ n Abstract—Web engineering is a new research line in software engineering that covers the definition of processes, techniques, and models suitable for Web environments in order to guarantee the quality of results. The research community is working in this area and, as a very recent line, they are assuming the Model-Driven paradigm to support and solve some classic problems detected in Web developments. However, there is a lack in Web requirements treatment. This paper presents a general vision of Navigational Development Techniques (NDT), which is an approach to deal with requirements in Web systems. It is based on conclusions obtained in several comparative studies and it tries to fill some gaps detected by the research community. This paper presents its scope, its most important contributions, and offers a global vision of its associated tool: NDT-Tool. Furthermore, it analyzes how Web Engineering can be applied in the enterprise environment. NDT is being applied in real projects and has been adopted by several companies as a requirements methodology. The approach offers a Web requirements solution based on a Model-Driven paradigm that follows the most accepted tendencies by Web engineering. Index Terms—Software Engineering for internet project, surveys of historical development of one particular area, requirements/specification. 1INTRODUCTION SOME years ago [22], a few research groups, started to analyze the characteristics of new types of software systems known as hypermedia systems which have since evolved into Web systems. It was the birth of a new line in software engineering that is currently called Web engineering. Web engineering is the systematic, structured, and quantifiable application of methodological proposals to the development, evaluation, and maintenance of Web applications [12]. Web Engineering is a young line that is being widely studied. However, the research study in this field is mainly oriented to the analysis and design phases. Surveys and comparative studies conclude that there are important gaps in this line [3], [49], [15], [18]. The requirements treatment is one of them. The correct treatment of requirements assures the quality of results in a Web project and this phase is now considered in the most recent approaches. The high number of approaches without standard consensus, the lack of the use of standards, and the scarcity of both practical experience and tool support are other aspects that should be developed in more depth in this line. In Section 2, a global analysis of the situation is presented. This paper analyzes the present situation of Web engineering in Section 2.1 and it presents how some . M.J. Escalona is with the Departamento de Lenguajes y Sistemas Informa ´ticos, ETS de Ingeneria Informa ´tica, University of Seville, Avenida Reina Mercedes S/N, 41012 Seville, Spain. E-mail: [email protected]. . G. Arago ´n is with Everis Spain, C/Gregor J. Mendel, Edificio DaVinci, 41092 Seville, Spain. E-mail: [email protected]. gaps are being solved with the use of Model-Driven Engineering (MDE). A Model-Driven paradigm is a suitable solution for Web development and Web engineering is a specific domain in which MDE can be usefully applied [54]. The application of MDE in Web engineering is called Model-Driven Web Engineering (MDWE) and, as stated in Section 2.2, is offering very good results. In Section 3, a combination of MDWE and classic Web engineering is presented in a Web requirements approach named Navigational Development Techniques (NDT) [14]. NDT is a methodology that covers the requirements and the analysis phases in Web developments. Thus, it tries to fulfill the lack of requirements treatment in Web engineering. Section 3 starts with a global vision of this approach and it present its life cycle and its scope. This approach is completely based on MDWE and, in Sections 3.2 and 3.3, NDT metamodels and transformations are introduced. In order to offer a suitable support for the NDT application, a tool case, named NDT-Tool [13], is offered with the methodology. The presentation of NDT in Section 3 finishes with the introduction of this tool in Section 3.4. NDT is also interesting because it has been widely applied in the business environment. In Section 4, this paper presents the most relevant applications of NDT and how they influence the theoretical research results. This paper ends by drawing conclusions from these studies and future work along these lines is proposed. 2RELATED WORK NDT is an approach based on two important research lines. The first one is Web engineering approaches. NDT is not only a methodology focused on requirements and analysis, but it is also related with several other approaches. The second one is the MDWE environment since its development process is based on this paradigm. In this section, a survey along the two lines is presented. Both lines are very popular today and there is quite recent work in this area; for this reason, the section only analyzes approaches similar to or connected to NDT. 2.1 Web Engineering Approaches In recent years, the growing interest in the Internet has led to the generation of a high number of proposals which offer a frame of reference for the Web environment. Fig. 1 shows the most representative ones in chronological order. In the diagram, continuous lines indicate that the latest methodologies are based on, or receive the ideas from, the previous ones. The dashed lines link the methodologies which have the same author. In the beginning, the overall tendency was oriented toward the structured paradigm. Thus, the shadowed approaches, Hypermedia Design Model (HDM) [22] and Relation Management Method (RMM) [27], were structured. However, with the introduction of Enhanced Object Relationship Methodology (EORM) [34] and Object-Or- iented Hypermedia Design Method (OOHDM) [50], this tendency moved to the object-oriented paradigm. As can be deduced from some surveys and comparative studies [3], [49], [15], [18], the initial interest of groups was focused on offering new models and suitable techniques to deal with hypermedia system aspects. Thus, HDM was an extension of Entity-Relation Diagrams (ERDs) [8], [9] in the representation of hypermedia concepts. However, research work has since improved and approaches have started to offer a complete life cycle oriented to the new Internet systems. Some of the approaches presented in Fig. 1 have not been developed over recent years, although others, such as UML- Based Web Engineering (UWE) [29], OOHDM, and Web Modeling Language (WebML) [7], are being reviewed in order to adapt and improve their approaches. Another important fact is the analysis of the phases treated by each approach. Table 1 shows the route of the different phases of the life cycle treated by each methodology. In Table 1, phases of requirements treatment, analysis, Fig. 1. Web methodologies. TABLE 1 Web Phases Treated by Each Approach 1www.uwaproject.org. 2www.fusebox.org. design, implementation, and tests are presented in the columns and approaches are given in the rows. It is necessary to add that the separation between phases is based on the comparative study presented in [18]. In Web engineering, there is no consensus and a clear separation between phases. In this table, ideas presented in this survey were followed. A cell without color indicates that this approach does not consider this phase in its life cycle. The shadowed color points out that the proposal includes a phase based on classic proposals, but that it does not include special proposals for the Web. The dark color means that the proposal covers the whole phase, including specific methods and models for the Web environment. By analyzing comparative studies, we can conclude that Web methodologies still present a relative lack of maturity and high ambiguity in some aspect such as in the definition of the covering of a life cycle, the performance of activities and tasks, the use of models and techniques, and handling of other aspects [5]. As can be observed in the table, most works have been focused on the design phase. However, this trend is changing. In recent years, research groups have detected the need to enrich their proposals with specific models for requirements processing on the Web. Thus, approaches like OOHDM, which did not consider the requirements phase in its first versions, now include a specific phase which proposes taking into account the use cases and its own technique named User Interaction Diagrams (UIDs) [56] to represent requirements suitable for Web systems. Empirical experience [13] shows that, due to the growing complexity of Web systems, it is becoming more and more important to capture the requirements needed to model navigation and other important aspects for the Web. In this respect, some issues have arisen: 1. Should the Web requirements be captured and treated in a specific way? Empirical results show that requirements should be treated carefully. Web systems are becoming more and more complex and it is necessary to know the requirements needed as soon as possible or to at least control their growth to guarantee the quality of the system. Moreover, the special characteristics of Web systems require special necessities. 2. Assuming the treatment of Web-specific characteristics is improved in the first phases of the life cycle, which specific techniques must be considered? According to the survey [5], the use of techniques, such as use cases, which capture those requirements should suffice. However, as some groups and research works have shown [26], [56], in many cases, use cases are inadequate and too ambiguous to capture all of the required details for the definition of navigation. 3. Is it necessary to include the user or client in the treatment of Web requirements? Empirical experience shows that, when it is possible and final users or, at least a group of expert users are known, it could be very useful. Web systems, and also the navigational systems on which they are based, are becoming more and more complex. Users or clients, experts in the business environment, can offer important knowledge for the development team. That is why the techniques proposed for Web requirements have to be detailed enough to be useful to the development team and to offer a flexible validation system of the results for the user and client. Another important issue is the need to use standard aspects [17]. As already mentioned, there are too many methods, techniques, and terminologies defining the same aspect. Work has to be oriented to assume accepted points and to propose new ideas only for those aspects which are really necessary. Last, an important aspect which has not yet been mentioned should be emphasized here. Web systems change very quickly. They have to be updated and they are characterized by different types of users, who are, in many cases, undefined. That is why, from the modeling and methodological environment points of view, it is necessary to ease the maintenance and development of those systems with suitable tool support. Most Web proposals lack the support of CASE tools, which support the technique application and the generation of results, as well as the process of maintenance and validation of models and final results. Some approaches, such as WebML, which offers WebRatio, 1 UWE, which offers ArgoUWE, 2 or FLiP Methodology, which is supported by a framework, Fusebox, are working along these lines. Obviously, the need to offer systematic or even automated definition, generation, or result validation is imminent in this type of environment and these tools provide the appropriate support. 2.2 Model-Driven Web Engineering As introduced in the previous section, empirical experience shows that, due to the growing complexity of Web systems, it is becoming more and more important to capture the requirements needed to model specific characteristics of Web environments. However, empirical studies also conclude that it is sometimes very difficult to translate users’ necessities into Web analysis models [13]. Maintaining consistency between models in different phases of the life cycle is of prime importance to assure the quality of results. This aspect becomes critical in the requirements phase. Requirements are frequently defined using nonformal models and the translation into analysis models depends on the analyst’s experience. Current research whose aim is to maintain consistency is in the use of Model-Driven approaches [51]. This tendency, named MDWE, is the application of MDE to the domain of Web system development. As introduced in [41], Web engineering is a specific domain in which MDE can be usefully applied. In MDE, concepts have the greatest importance, independent of their represented action. MDWE proposes representing concepts using metamodels. The development process is supported by a set of transformations and 1. http://www.webratio.com. 2. http://www.pst.informatik.uni-muenchen.de/projekte/argouwe. relations between concepts that leads to agile developments and assures consistency between models. The power of MDWE is provoking classic approaches into evolving into this new paradigm. Thus, in [40] and [51], metamodels for WebML are presented. In [1], a metamodel for W2000 is offered. Even some initial Model- Driven approaches, such as UWE, are evolving into the new standard defined by the Object Management Group (OMG), for example, the use of QVT [48] for defining transformations [31]. The application of MD systems within the Web environment is increasing daily. As mentioned earlier, it offers important benefits in development and consistency in addition to the definition of concepts. This trend is also followed for the requirements phase. One of the most recent pieces of research is [53]. This paper presents an approach for the transformation of a Web requirements model into a set of prototypes whereby requirements treatment is based on the task metaphor. Valderas et al. offer an extension of this approach to deal with the specific characteristics of Web requirements and then present a way to derive the navigational model of OOWS. First, they propose defining requirements as tasks and these tasks are translated into an AGG Graph. Using Graph transformations, analysis models are obtained. This approach is supported by a tool which enables the application of the complete cycle. This work is very interesting since it offers a suitable solution for transformation supported by a tool. However, its transformations are not based on OMG tendencies. This provokes incompatibility with other similar approaches. In [17], the power of metamodels is presented. In comparative studies on Web approaches, a general conclusion is that similar concepts are used or represented with a different number of models, techniques, or artifacts. Thus, for instance, navigational classes are presented with different elements in UWE, OOHDM, NDT, and W2000. Escalona and Koch show how a metamodel can represent a concept independently of its representation or notation; only concepts are important. A metamodel for Web requirements, named WebRe, which represents requirements models of W2000, NDT, OOHDM, and UWE, is presented. In [30], their work is continued using QVT to obtain analysis models from this metamodel. These papers are interesting since they are based completely on UML [45] and on QVT, standards defined by OMG. However, these papers can be considered to be excessively theoretical. This tendency to use metamodels and transformations to make different approaches compatible is applied in recent work under the name of MDWEnet [54]. MDWEnet is an initiative started by a representative group of MDWE researchers in an effort to find a common approach which allows different approaches to be represented and handled. This group is currently analyzing OO-H, UWE, and WebML with special focus on design models and, although this work is very recent, they are working toward the attainment of a common language in Web engineering. Ferna ´ndez and Mozo ´n [20] present the possibilities of working with metamodels and tools. Thus, they present how a requirements metamodel can be easily defined in Integral Requisite Analyzer (IRqA). 3 IRqA is a commercial tool that helps in the definition of metamodels for requirements. In this way, this paper presents the power of tools that support metamodels because they are suitable for any approach defined using metamodels. This work is very practical in fact, although it is not an approach for the Web. Metamodels do not offer specific artifacts to deal with the Web environment since only an approach for classic requirements treatment is offered. However, although these studies are specifically for requirements, other classic approaches are being used in the MDE environment. For instance, in [40] and [51], some metamodels for WebML can be found whereby metamodels can represent classic concepts independent of the artifact used in their representation. In [38], Melia ´and Go ´mez present an approach called Web Software Architecture (WebSA). WebSA provides the designer with a set of architectural models and transformation models which can be used to specify a Web application. Although these models work in the design phase, this approach is very interesting since Model-Driven Architecture (MDA) [44] and QVT are employed in a very exhaustive way. To conclude MDA and MDWE in a more general way, the use of metamodels and MDE are areas of software engineering that are becoming widely accepted by the Web engineering community as a solution for classic problems. 3NAVIGATIONAL DEVELOPMENT TECHNIQUES As mentioned in the previous section, several comparative studies have proven that one of the least studied phases in Web engineering is the requirements phase [1], [49], [15], [18]. Most approaches in Web engineering are focused on analysis and design phases. They usually propose using classic requirements techniques, such as use cases, in order to capture and define requirements on the Web. Although use cases are a suitable technique for dealing with requirements and are very easily understood by the user, they are frequently very ambiguous [56], [26]. For this reason, several research groups have been working on specific requirements treatment for the Web environment. Another conclusion drawn from comparative studies is that, in Web engineering, different aspects of software are treated in separate ways. This idea is followed in the analysis and design phases by several approaches. OOHDM, WSDM, WebML, and OOH, where content, navigation, interaction, etc., are modeled differently, are only a few examples. This idea of concept separation can be moved to the requirements phase in order to obtain these advantages. Thus, UWE deals separately with information requirements, functional requirements, etc., and W2000 defines different use cases for functional and navigational requirements. Finally, another important fact detected by the comparative studies is that requirements are sometimes defined in a very ambiguous way and it is very difficult for analysts to translate the knowledge from the requirements definition to the analysis models. 3. http://www.irqaonline.com/. With these ideas, NDT was proposed [14]. NDT is a methodological approach which deals with requirements in Web environments. NDT was proposed in order to support the requirements engineering and the analysis phase of Web systems and is based on the MDE paradigm. Thus, it proposes an MDE approach in order to offer a suitable environment for the capture, definition, analysis, and validation of Web requirements. In this section, NDT will be presented. In Section 3.1, a brief view of its life cycle and its structure is shown. In Section 3.2, metamodels for NDT are introduced. In Section 3.3, transformation of its Model-Driven approach is presented. NDT also has its own tool support. In Section 3.4, NDT- Tool, its associated tool, is presented. This section is completely focused on the theoretical presentation of NDT. However, NDT is not only a theoretical approach. It is being applied in several real projects by companies in Andalusia, Spain. Thus, in Section 4, the introduction of NDT ends with the analysis of its practical experience and evolution. 3.1 NDT Life Cycle NDT was born from exhaustive comparative studies between Web proposals. NDT proposes a complete and detailed requirements phase which systematically obtains the analysis models of Web systems. It is an approach for the specification and analysis of Web information systems. The NDT development process can be defined as a bottom-up process. The development process is focused on a very detailed requirements definition, guided by objectives, which covers three subphases: requirements capture, requirements definition, and requirements validation. NDT only covers the first phases in the life cycle. It is also necessary to emphasize that workflows in NDT, which go from requirements to analysis, are systematic. These workflows are defined using the MDE paradigm, as will be presented later in this paper. The necessity of offering a systematic process in order to develop Web design models has been detected by several research groups. These workflows may even be automatic if the development team uses its associated tool of NDT, the NDT-Tool. The process starts by defining objectives. Using the procedure described below, requirements are captured and defined. Requirements are classified according to their nature: information storage requirements,actors’ requirements,functional requirements,interaction requirements,or nonfunctional requirements. In this way, NDT follows the idea of concept separation used by other approaches in the design phase. These requirements are described in NDT using some especially defined patterns. A pattern is a template with specific fields which must be completed by the developer. In Section 3.2, an example of a pattern and its connection to the metamodel is introduced. When requirements are validated, the NDT process continues by defining three models: .The content model, which is a class diagram. It expresses the static view of the system. .The navigational model, which shows how users can navigate through the system. .The abstract interface model, which shows the abstract interface of the system. One of the main contributions of the NDT process is that it offers a systematic way of obtaining analysis models from requirements, thereby making each model independent. It is systematic because NDT offers transformations which indicate how each model must be obtained from the requirements definition. In NDT, different models are related to one another since each of them represents a different aspect of the same system. However, they are independent because each one can be obtained independently from the requirements. When the development team applies these transformations, they obtain the basic models: the basic content model, the basic navigational model, and the basic abstract interface model. These basic models can be modified in order to obtain models more suitable to the system. In this way, they obtain the final content model, the final navigational model, and the final abstract interface model. The step from basic models to final models is not automatic because it requires the analysts’ experience to be applied. However, NDT offers some guidelines and heuristics for their generation. Thenavigationandthecontentmodelsareclass diagrams. However, the abstract interface model is a set of evaluated prototypes. Users and customers can evaluate these prototypes. This is the last phase in the NDT life cycle. Starting with developed models and assuring that they are correct, the development team can apply other Web methodologies, such as UWE and OOHDM, to deal with other later phases, such as design and implementation. ThemainobjectiveofNDTistooffersystematic processes to build models which other Web methodologies can use as the starting point of their development process and to guarantee the quality of these models. Thus, we can conclude that NDT is not a complete methodological Web approach. It is a methodological procedure to obtain content, a navigational and an abstract interface model from the users’ requirements. This methodological procedure is based on the MDE paradigm. It allows consistency between requirements and concepts in the analysis phase to be assured. To conclude this short presentation, in Fig. 2, an activity diagram describes the NDT development process. In this diagram, two special stereotypes are included. The first, QVTTransformations, presents the QVT Transformations defined by NDT in order to attain basic analysis models from requirements. The second, NDTSupport, shows that these activities are supported by guidelines and heuristics offered by NDT for the development of the final models while maintaining consistency with requirements. 3.2 NDT Metamodel As presented in the previous section, NDT offers systematic ways to advance from the requirements model to the analysis models. These systematic ways are possible with the use of the Model-Driven paradigm. Following the architecture defined by MDA, the requirements artifacts of NDT are defined using a Computational Independent Model (CIM). In the analysis phase, a group of Platform Independent Model (PIM) is also defined. With a group of formal transformations, the group of metamodels in the PIM level can be systematically derived from the metamodel in the CIM level. In classic Web engineering, ideas detected in the requirements phase must be translated into concepts by analysts in the analysis models. An analyst’s experience is essential and critical in this step. In the MDWE paradigm, the definition of the process is different. In each phase of the life cycle, concepts are studied, detected, and defined using a metamodel. Concepts in each metamodel are studied and related to other concepts in other metamodels. Thus, for instance, in the requirements phase of NDT, the concept storage information requirement is defined and, in the analysis phase, the concept content class is detected. Storage information requirements defined by the user are translated in a conceptual class in the analysis content model. These rules and relations allow the definition of the set of systematic transformations. Transformations not only ease the translation of concepts but also assure the consistency between phases in the life cycle. Thus, using the same example, each storage information requirement has to be translated into a class in the analysis. If a storage information requirement is not represented by a class in the analysis content model, a requirement is lost in the development process. In the first version, NDT metamodels were not MOF metamodels and transformations were not based on any formal language for transformations. However, NDT metamodels are currently defined using a UML profile and transformations are being defined using QVT. The proposed metamodel for NDT in the requirements phase is presented in Fig. 3. This requirements metamodel follows the structure of WebRe [16]. As shown in Section 2.2, Fig. 2. NDT development process. Fig. 3. NDT requirements metamodel. WebRe is an approach for metamodels for requirements in Web engineering which groups concepts of different approaches: NDT, W2000, UWE, and UIDs of OOHDM. However, in this case, this metamodel has been extended in order to support all of the aspects of the NDT requirements phase. The metamodel is divided into two packages: the Behavior and the Structure. In the first package, concepts related to the behavior of the system are presented and classes represent conduct aspects. Thus, the WebActor class represents any actor in the system. As stated earlier, the study of actor requirements is a phase of NDT. In NDT, the study of actors is very complex. It not only detects different users in the system but also studies their relations. For this reason, in the metamodel, the relation of incompatibility is included. Two actors are incompatible when their roles cannot be played at the same time for the same person. Another class in the behavior package is the WebUseCase Class. This class represents the group of functional requirements of the system. When a functional requirement includes any transactional activity, this functional requirement is an instance of WebTransactionalUseCase. Finally, in the behavior package, a group of classes that represent activities is included. These are Browse,Phrase, and Transaction. Browse represents navigation activities in the system without any transaction activity. Phrase is a kind of activity that defines queries and search activities. Finally, the Transaction class represents activities where transactions are executed. In the structure package, Concept class represents any information storage by the system. Each Concept is composed of a group of SpecificFields. Each SpecificField defines each piece of information stored by the Concept. NDT defines a special concept named NewNature. New- Nature is a kind of Concept that represents global data structures in the company, not for the system. For instance, the definition of personal data of users must be stored in the same way in each system in the company. Thus, the structure of this information is of a new nature. The last concept, VisualizationPrototype, represents any point of interaction between the user and the system. This metamodel is based on UML artifacts. For this reason, its profile can be defined. In Fig. 4, this profile is presented. Although these concepts could be represented with UML artifacts, the selected technique in NDT for the definition of requirements is patterns. Patterns are tables with specific fields for the collection of any piece of information specific for each concept. In NDT, the structured way to define requirements offered by the patterns is important. In Table 2, an instance of an NDT pattern is presented. This pattern represents the definition of a storage information requirement taken from a real project defined completely in [57]. It represents the necessity of storing information about patients in a medical system. In this pattern, special fields which are necessary for the definition of storage requirements are found. The first is the identifier of the requirements, RA-01, and its name. The associated objectives field stores the objectives of the system that are later obtained (or partially obtained) by the implementation of the requirement. Finally, in the field of specific fields, the specific piece of data storage for each patient is presented. Similar patterns are defined for each kind of requirement in the project. Patterns are essential throughout the life cycle of NDT. They offer a structured definition of requirements, very useful for analysts during the analysis phase. Moreover, they also offer a suitable definition for users. Patterns are completely defined using the user’s language and, therefore, can be easily evaluated. Furthermore, patterns offer a suitable way to represent each concept and relation in the metamodel. Thus, storage information requirements are instances of the Concept class. With the field Specific Field, the relation between each Concept and Specific Field is represented. In fact, in NDT, patterns are defined in a more generic way. In Table 3, the pattern followed to define the previous example is presented. In the pattern, some fields are obligatory and others are optional (they are presented by *). In addition, some sentences are fixed and others (sentences Fig. 4. NDT requirements profile. between <> ) have to be completed by the development team. In the next phase of NDT, the analysis phase, more metamodels are used. However, most approaches of Web engineering offer models and techniques for the analysis phase. For this reason, NDT does not offer new models and uses previous experiences based on standards. For the content model, NDT proposes the development of a class diagram following UML. For this reason, the one content metamodel of NDT is the UML class metamodel. For the navigational model and abstract interface model, NDT also looked for previous suitable metamodels. After some comparative studies [15], [18], NDT assumes the UWE metamodel for the analysis phase. The selection of UWE is based on the use of UML. UWE metamodels are completely based on UML and they have a suitably defined profile. In [32], these metamodels are presented and defined. 3.3 NDT Model-Driven Transformation Continuing on from the previous section, requirements are located in the CIM level and the analysis artifact in a PIM level. Between them, transformations defined with QVT are defined in order to derive analysis models from the requirements models. According to the taxonomy of transformation approaches proposed by Czaenecki and Helsen [6], NDT defines a set of transformations model-to-model. Since NDT only works with the requirements and the analysis phases, NDT does not cover the other kind of transformations defined in this taxonomy: model-to-code. QVT Transformations offered by NDT are grouped into three transformations: .Requirements2Content: This transformation allows the generation of the basic content model from the requirements model. .Requirements2Navigational: This transformation allows the generation of the basic navigational model from the requirements model. .Requirements2Prototypes: This transformation allows the generation of the basic abstract interface model from the requirements definition. Presenting all of these transformations in this paper is very complex. For this reason, only the first one is presented, see Table 4. 4 It expresses how each storage information requirement is to be translated into a content class in the analysis phase. Each storage information system generates a class and each specific field generates an attribute. In relation R1, each Concept and each NewNature in the requirements is translated into a Class in the Content TABLE 3 A Storage Requirements Pattern 4. Complete information about NDT and its transformations can be found at www.lsi.us.es/ndt. TABLE 2 An Instance of the Storage Requirements Pattern Model. In relations R2 and R3, SpecificFields are treated. If a SpecificField has a basic Nature, that is, when its relation with Content has cardinality 0, they are translated into Attributes with relation R2. If its nature is Content, it is translated into Association with relation R3. Similar structures can be defined for navigational and abstract interface models. These transformations can be implemented by suitable tools such as SmartQVT 5 or Moment [47], as shown later in Section 5. These transformations were presented in Fig. 2 as QVTTransformation activities, although NDT includes another support also represented in Fig. 2: NDTSupport. These transformations could be applied automatically. However, the analysts’ experience could add some ideas to basic models in order to make them more suitable. For this reason, in NDT, analysts can change basic models, but these changes must be controlled. For instance, if, in the basic model, the analyst introduces a heritage, it must not contradict the transformation. However, if a new class is added, the analyst must consider if it is a lost storage requirement. Thus, NDT offers a set of rules that must be considered by the development team to control the consistency between final models and requirements. In [14], the complete list of these rules is defined. In conclusion, NDT is a Web approach focused on the first phases of the life cycle. It tries to offer a Model-Driven development process in order to assure the consistency of the model and to ease the development of each model in each phase. It is completely oriented to the interaction between the development team and the user with the use of patterns and its development process is supported by a tool named NDT-Tool. In this sense, NDT attempts to cover a gap in Web engineering by offering a detailed requirements approach that is compatible with other accepted approaches, mainly UWE. 3.4 NDT-Tool Another important gap detected in Web engineering is the lack of tools to support its development. NDT and its definition based on metamodels and transformations can be translated into a tool, named NDT-Tool. One of the most important advantages of NDT is that its tool not only support the definition of models or results, like other tools in Web engineering, it supports the complete life cycle of NDT, it lets patterns and model be defined, and it guarantees the traceability using model-driven support. It has been shown that NDT is being used profusely in practice, as is presented in Section 4. This tool is developed with J2EE using the Model-View- Controller pattern. Its architecture is presented in Fig. 5. The application interface, NDT-Tool, receives requests from the user and translates them to the controller. It interacts with the model, developed using JavaBeans and EJBs. Furthermore, the controller sends requests to the View, modeled using JSP and TagLibs. The view makes some queries to the model and presents the results to the user using the interface. Nowadays, there is a special collaboration between two companies, Telvent and everis, to finish the new tool that was presented at the end of September 2007. NDT-Tool is very suitable for applying NDT because it supports its complete life cycle. It allows the attainment of all NDT results automatically: requirements and analysis documents and, also, system prototypes. Not only are transformations between requirements and analysis models completely implemented in NDT-Tool, but the heuristics and controls of NDT also support the development of final models in the analysis phase. NDT-Tool is a free tool. 6 However, it is not the only option for NDT. It is an ad hoc tool. For large projects or special adaptations of NDT, this tool can be considered to be too closed. For instance, in a real project developed with NDT named Diraya [19], NDT-Tool was not useful because this project was very large and it needed a special identification of requirements and modularization of the system that was impossible to achieve using only NDT- Tool. The definition of NDT using metamodels and profiles as a formal extension of UML allows the adaptation of any commercial tool that supports the definition of profiles into the NDT approach. Thus, in the Diraya Project, Enterprise Architecture was the solution selected, as seen below. 3.5 NDT in the Web Engineering Community To conclude with the NDT presentation, it is necessary to present how NDT covers most of gaps presented in Section 2: .About the life cycle, NDT is focused on requirements and analysis. Thus, it covers the gap in the life cycle presented in Web engineering. .About the compatibility and standards, NDT is compatible with other approaches, mainly UWE and approaches based on standards like UML. .About the tool support, NDT offers NDT-Tool, a case tool that supports not only the generation of results but also the complete life cycle and the traceability using model-driven paradigm. 5. http://sourceforge.net/projects/smartqvt. 6. Available at www.lsi.us.es/ndt. TABLE 4 Requirements2Content Transformation