• Tidak ada hasil yang ditemukan

A Survey of Requirements Specification in Model-Driven Development of Web Applications

N/A
N/A
Protected

Academic year: 2023

Membagikan "A Survey of Requirements Specification in Model-Driven Development of Web Applications"

Copied!
51
0
0

Teks penuh

Then, a detailed study of the requirements specification techniques proposed by the nine MDWE methods is presented. This phase consists of describing the user interface in an abstract way.

Fig. 1. Chronological overview of MDWE methods.
Fig. 1. Chronological overview of MDWE methods.

WSDM: Web Site Design Method

Finally, on the lower left side of the figure we can find a task diagram that describes some of the requirements related to the customer target class. The requirements specification proposed by WSDM is based on the identification and classification of users and the description of the requirements associated with each user.

Fig. 4. Example of a requirements specification in WSDM.
Fig. 4. Example of a requirements specification in WSDM.

SOHDM: Scenario-Based Object-Oriented Hypermedia Design Methodology

One of the key strengths of WSDM is taking users into account in requirements development activities. To achieve this, we need to take users into account from the early stages of the development process. 2000b] it is argued that textual specifications are impractical when used in a validation process with users, mainly due to their lack of precision and conciseness.

This phase consists of creating a class diagram in which the static structure of the system is defined. In order to define the scope of the system, SOHDM proposes the system scope diagram based on the well-known data flow diagrams (DFD) [Demarco 1979], although context diagrams (eg zero-level DFD) are a good alternative. The top of this figure shows the scope of the web application in which three external entities are identified: Visitor, Client and Administrator.

Other criteria related to the specification of data requirements are not supported. As for information filtering mechanisms, they can be emulated by combining actions in which users enter data with actions in which the system searches for information using data entered by users (criterion NR3). Another important advantage is the consideration of the boundaries of the system with the help of its scope diagram.

Fig. 5. Example of a requirements specification in SOHDM.
Fig. 5. Example of a requirements specification in SOHDM.

UWE: UML-Based Web Engineering

In addition, additional descriptions may be associated with use cases to account for exceptional situations. The description of the effect of the parameters is not explicitly considered in this requirements model, therefore the FR4 criterion is considered not to be supported. In the same way, content elements can be associated with transactions that define the data that can be accessed by system operations (criterion DR3).

These two aspects allow us to consider that the criteria NR1 and NR2 are fully supported. Finally, the connection of nodes to transactions indicates the functionality that users can activate when navigating the published information; therefore, we consider criterion NR4 as fully supported. 2003], a plug-in of the ArgoUML open source modeling tool.5 However, development of this tool has been discontinued because it is not based on UML 2.0.

In the current version of the tool, only use case diagram construction is supported. Another important characteristic of UWE is that it is fully oriented to be used in MDD of web applications. However, the tools provided by UWE to specify web requirements and derive conceptual models from them need to be improved.

Fig. 6. Example of a requirements specification in UWE.
Fig. 6. Example of a requirements specification in UWE.

WebML: Web Modeling Language

This phase consists of translating the WebML-based conceptual schema into a specific implementation technology. Informal specification of page views that will allow users to accomplish the functions expressed by the identified use cases. A set of presentation guidelines that give indications of the look and feel of interfaces to be developed.

Below the use case diagram is the structured textual description of the Add CD to shopping cart use case and its description by means of an activity diagram. Furthermore, according to the description of Visitor (see the description of the user group at the bottom of the figure), visitors are those users who can only access the public part of the web application. They are defined by use case diagrams and associated descriptions.

Criterion FR3 (abnormal situations) is fully supported through the exception descriptions that can be associated with use cases. They are basically specified by means of the data dictionary templates and the user group descriptions. Some of the requirements specification techniques proposed by WebML provide a visual notation such as activity diagrams and use case diagrams and others are based on textual notations such as user group templates or site view specifications.

Fig. 8. Example of requirements specification in WebML.
Fig. 8. Example of requirements specification in WebML.

OO-H: Object-Oriented Hypermedia Method

This phase involves all the activities related to the analysis and design of the software product. If other mechanisms are used, they are only used as documentation and do not affect the rest of the phases of the OOH development process.” Although OO-H in an extension of the method [Cachero and Koch 2002] suggests supplementing use cases with activity diagrams, they are used during analysis activities. Figure 9(a) shows a partial view of the use case diagram proposed by initial version of OO-H to specify the requirements of the running example.

Figure 9(b) shows an example of a tree instantiation of the metamodel proposed in recent works for the current case. Therefore, we believe that criteria FR2 (sequence of operations) and FR3 (abnormal situations) are not supported. Therefore, we believe that all criteria related to the data requirements specification are not supported.

Thus, we consider criterion NR1 (published information) and criterion NR2 (navigation possibilities) to be partially supported. Thus, we consider criterion MR1 (metamodel) to be fully supported and criterion M4 (visual syntax) to be partially supported. These works present several PIM-to-PIM transformations implemented in the context of the WebSa tool [Meli ´a and Gomez 2006].

Fig. 9. Example of requirements model in OOH.
Fig. 9. Example of requirements model in OOH.

OOWS: Object Oriented Web Solutions

Below this taxonomy appears the description of the Add CD task (note that it is a leaf task). This last template specifies the data that the system should display for each CD in the list. The frequency with which the data is used is described using the frequency field defined in the task characterization template.

The published information is defined using the entity associated with each output IP. In addition, this information is detailed using the templates associated with these IPs. Another interesting feature of this approach is that navigational capabilities are described globally using a taxonomy of tasks.

This phase consists of studying the requirements of the web application using UML use cases. In this phase, different perspectives of the web application are defined for each type of user. As with other approaches, use cases fully support the FR1 (input validation) and FR5 (output-input ratio) criteria through pre- and post-conditions that can be associated with the use cases.

Fig. 10. Example of requirements model in OOWS.
Fig. 10. Example of requirements model in OOWS.

NDT: Navigational Development Techniques

They are specified using the functional use case diagram and the formatted templates for requirements of this type. The template associated with use cases allows analysts to describe the sequences of actions performed by the user and the system, therefore we consider criterion FR2 to be fully supported. In addition, exception situations can be defined in these templates, so that criterion FR3 is also considered to be fully supported.

Therefore, we consider criteria DR1 (data types) and DR4 (entities and relationships) to be fully supported. Therefore, we consider criteria DR5 (integrity restrictions) and DR6 (data retention) to be fully supported. Therefore, we consider criteria NR1 (published information) and NR2 (navigation options) to be fully supported.

NDT suite is a profile for the commercial modeling tool Enterprise Architect.14 This suite incorporates different extensions that enable the creation of the complete NDT requirements model, so we consider criterion MR5 to be fully supported. This model matches the WebRE metamodel [Escalona and Koch 2007], so we consider criterion MR1 to be fully supported. In the same way, the use of text templates instead of other diagrammatic tools such as the UIDs of OOHDM or the activity diagrams of UWE makes it difficult to obtain a vision of the navigation aspect of a web application from the requirements model.

Fig. 13. Example of requirements specification in NDT.
Fig. 13. Example of requirements specification in NDT.

SUMMARY AND LESSONS LEARNED

The construction of the UWE requirements model is partially supported by the ArgoUWE and MagicUWE tools. However, the construction of the stereotypical activity diagrams is not supported (although authors are currently working on it). The creation of the OOWS requirements model is fully supported by a RE tool based on the eclipse platform.

This tool provides graphical support for creating the various elements of the NDT requirements model. Finally, in most of the analyzed methods, the way in which requirements are translated into a conceptual model (CIM-to-PIM transformation) depends on the analyst's experience and skills. These transformations take a description based on this metamodel as a source and obtain conceptual models of web applications.

NDT has developed an implementation of QVT transformations using Enterprise Architect tool templates that are automatically used to transform the NDT requirements model into a conceptual model. UWE is currently working on the implementation of CIM to PIM transformations in ATL. This allows OOWS to provide a tool-supported strategy based on the AGG tool to automatically apply model-to-model transformations to obtain OOWS conceptual models from the requirements model.

Table XIX. A Summary of the Requirements Specification Perspective Analysis
Table XIX. A Summary of the Requirements Specification Perspective Analysis

RELATED SURVEYS

Moreover, the newly created techniques can still be considered as young techniques and a lot of research work needs to be done to improve them. In particular, we should direct our efforts to improve the specification of data and navigation requirements and the integration of these specifications with functional requirements. there are few tools that support the construction of the proposed requirements for web application models. Thus, almost all the models proposed by the various methods must be created manually. once requirements are specified, there is little support to allow systematic or automatic derivation of the conceptual model that correctly satisfies the requirements model.

It makes sense that there are some tools available to support this aspect. they also list its main strengths and weaknesses.

CONCLUSIONS

Computernetwerken en ISDN-systemen, InProceedings of the 7th International World Wide Web Conference, Elsevier, 85–94. InProceedings of the 22th International Conference on Conceptual Modeling (ER'03).Lecture Notes in Computer Science, v.

Gambar

Fig. 1. Chronological overview of MDWE methods.
Fig. 2. Running example.
Fig. 3. Example of the requirements model in OOHDM.
Table I. A Summary of the Requirements Specification Evaluation of OOHDM OOHDM Requirements Specification Evaluation
+7

Referensi

Dokumen terkait

If I need to quickly access the progressive web app, this progressive web app is very useful because we can add it to the home screen.” In terms of performance expectancy, average

The 2nd Conference on Management, Business, Innovation, Education, and Social Science CoMBInES Taichung, Taiwan 3-6 March, 2022 469 DESIGN AND DEVELOPMENT OF WEB SCHEDULING

The majority of respondents, according to the study, “strongly agree” that one of the most significant benefits of Web 2.0 technologies is “rapid and easy communication.” Web 2.0

Chapter 1 Introduction Research Topic Area TABLE OF CONrEN'J'S Kates Natural Hazards Model Structural Components of the Decision Ma.king System Tho Human Use System The Natural

The reason to use the quantitative research in the next stage of this research is to have better understanding about factors affecting trustworthy of e-commerce websites depending on

Yet, recent reports on the same system propose the use of a much lower PtOEP content.22 It remains unclear whether the use of a nominal wt% content alone can exclude the possibility of

Based on the conducted works and studies of the mobile applications, security and privacy methods can be classified into three layers: Mobile services layer: the mobile services and

This journal discusses the application of text mining in the field of education, using a bibliometric approach to analyze the metadata of publications that use text mining or natural language processing (NLP) in educational