Collaborative Aspect-oriented Requirement Tool (CAORT)

Transcription

1 Collaborative Aspect-oriented Requirement Tool (CAORT) Aws A. Magableh, Zarinah Mohd Kasirun Department of Software Engineering, Faculty of Computer Science and Information Technology, University of Malaya, Kuala Lumpur, Malaysia Abstract Many requirement engineering techniques lacked of supporting concerns identifications from the earlier stage of software life cycle. For that reason, this research investigating Aspect-oriented Requirement Engineering Approach using Concern Space Modeling Schema (COSMOS) to avoid these problems. Our objective of this study is to find out concerns from the earlier stage of software life cycles by using Concern Space Modeling Schema approach as one of multidimensional separation of concern approaches. Our scope in this research is to convert Concern Space Modeling form manually documentation and stand alone system to a collaborative system by sustaining the ability of making decision based on opinions and views of other stakeholders who are geographically distributed in different areas. The system shall also enhance new features such as priority value for each concern, relationships and consistency checking constraint. Hence, by applying the concern space modeling we come up with more accurate way of avoiding for crosscutting concerns as long as there is a flexibility of adding, deleting and updating concerns, relationships and even predicates derived from stakeholders point of views. Advanced separation of concerns is a long conventional principle in software engineering. It includes subject-oriented programming, aspect-oriented programming and multi-dimensional separation of concerns [1]. This article is concentrating on the initial stage of software life cycle i.e. the requirement engineering stage. It highlights Space Modeling Schema (COSMOS) as one of multidimensional separation of concerns approaches. The following sections describe the literature review done as well as COSMOS in details. It is followed by design of the Collaborative Aspect-Oriented Tool (CAORT). After that, we will discuss the implementation and testing. Finally, contributions, results, discussions, strengths and weaknesses of CAORT will be explained. 2. Literature Review Many researches have been carried out in Requirement Engineering (RE). Among others, the researches are focusing on the techniques of identification and avoiding crosscutting concerns. Two main categories are aspect-oriented (AO) and non aspect (non-ao) requirement engineering approaches. Requirement engineering (RE) is the process of discovering, identifying stakeholders and their needs, and documenting these in a form that can be analyzed, communicated, and subsequently implemented [2]. RE consists of entire processes as in figure 2.1. Keywords: Aspect-oriented requirement engineering, AORE, concern space modeling schema, multi-dimensional separation of concerns, MDSOC, COSMOS, and RE. 1. Introduction Figure 2.1: RE processes [3] 2.1. Non-aspects approaches Contemporary or non aspect-oriented approaches are divided into three categories; viewpoint approach, the goal-oriented approach and use case and scenario based approach.

2 Under the first approach, there are two methods; PREview and VIM, where both of them are used to produce a viewpoint template or pamphlet in the earlier requirement analysis stage and consistency management, respectively. Both of them are complement to each other, PREview is used to identify viewpoints and VIM is used for consistency management. However, both of them lacked of support in defining concerns in the earlier stages of software life cycle [4]. Under the second approach, there are three methods. Firstly, Knowledge Acquisition in Automated Specification (KAOS) is dealing with formalization and knowledge acquisition. Secondly, I* provide an agent related knowledge. Finally, non-functional requirement (NFR) suggests knowledge structure about nonfunctional requirement. These approaches lacked of support in defining concerns in the earlier stage of life cycle [5]. Use case and scenarios based include collection of stories related to each other. A collection of scenarios are called use cases which representing the entire processes of the system and the interactions with different domain of users. As a result, normal use cases are supporting for crosscutting functional requirement because it separates each group of related processes into one use case. Consequently, use cases are not supporting for separation of concerns for non-functional requirement [6] Aspect-oriented approaches Aspect-oriented approaches are divided into four categories. The first one is AORE with Arcade, it falls under viewpoint aspect-oriented approach. It consists of some entire processes to capture the method itself. As a result, the most important process of its processes is mapping the concerns to functions. The main output of this method is viewpoints of the requirement in XML format [7]. The second method is requirements goal model (ARGM). This method depends on decomposing the goals into sub-goals using V-graph as in figure 2.2. The main output is to find out the interdependency graph among goals and softgoals. [8] Figure 2.2: V-graph [8] The third is use case and scenario based approach. This approach provides templates to find out the crosscutting concerns. Consequently, this approach is focusing on identification of functional concern only [7]. The fourth method is concern-oriented requirement engineering (CORE). CORE deals with all concerns uniformly. On the other hand, it decomposes the requirement into unified fashion without regarding to functional or non-functional requirement. In the next figure 2.3 represents CORE concerns spaces as hypercube. All faces are treated equally and any sets of concerns can be chosen to be the base of the project since it gives us the ability to determine the bases and the crosscutting of the project without regarding to crosscutting concerns [9]. Figure 2.3: Concern spaces as hypercube [9]. The fifth method is concern modeling using Space Modeling Schema (COSMOS) as in the following section Concern Space Modeling Schema (COSMOS) COSMOS modeling the space of concern s in term of concerns, relations and predicates. With regard to concerns, it is divided into two types namely concerns which related to the hardware and software components and concerns which means "Matter of Interests which consists of topics, classes, classifications, instance and Properties. With regards to relation; it represents the relation among concerns, the first type of relation is Categorical which is divided into Classification, Generalization, Instantiation, Characterization, Topicality, Membership and Attribution relationships. The second type is interpretive relationship which relates logical concerns semantically with each other, usually there are no pre-defined subcategory for interpretive relationships. The third type is mapping relations; it represents the association among logical and physical concerns. The third part of concern space modeling is predicates; predicates represent the conditions and constraint over the relationship [1].

3 Actually, there are no such defined processes for COSMOS but, the most artifacts coming out are the templates that defined concerns, relationships and predicate as in figure 2.4. Figure 2.4:, relation and predicated identification [1]. Currently, COSMOS is used by the system analysts to analyze the requirements as well as to manually identify concerns, so there are still possibilities for human mistakes Aspect-oriented tool supports With regards to support tools, there are various tools that have been developed to help the system analyst in concern analyzing and identification. Table 2.5 illustrates a tabulation of comparison among the existing tools used in concerns identifications. environment. Furthermore, most of these tools depend on the system analyst s views in making decisions, which lead to high percentage of human mistakes and highly risk problems in the next stages of software life cycle. All of these tools do not suggest sub-category to avoid crosscutting concerns from the earlier stage of software life cycle. Finally, no one of the existing tools give a priority value for each founded concern to avoid confuse when there are two or more concerns under implementation phase of software life cycle. Hence, this study uses COSMOS in concern identification from the earlier stage of software life cycle, as theoretically, the technique support all the criteria except for the NLP support. On top of that, the system which is called Collaborative Aspect-Oriented Requirements Tool (CAORT) emphasizes on collaborative environment and improves the existing features in the current tools. 3. CAORT design and architecture CAORT is designed for system analysts who are geographically distributed areas to enhance the communication among them. As a result, CAORT increases the percentage of concern identification accuracy from the earlier stage of software life cycle. Figure 2.6 illustrates the component diagram for the CAORT. This tool consists of five components; concerns component to captures all concerns details, relationship components, predicates, users components and database component. Relationships Catigorical Users Admin System Analyst Mapping Database Predicates Constraints Recording Table 2.5: Comparison among existing tools. As shown in the table, no tool support all the criteria compared except for aspect identifications. All of these tools are stand alone systems and manually use. In other word, the existing tools do not support collaborative Figure 2.6: Component diagram for CAORT Figure 2.7 shows the class diagram for CAORT system to capture the static structure of the system in term of classes name, attributes and operations.

4 Profile ProfileID ProfileName ProfileDescription Users UserID UserProfile Announcement AnnouncenetID AnnSender AnnTo AnnText ConcernID ConcernType ConcernName Priority ConcernDescription attribute as this tool is using the internet as a basic connection. Therefore, layered architecture as in figure 2.9 is employed to support security sessions and objects to achieve security non-functional requirement. CAORT GUI Admin UserName Password Authorization Recording RecordingID RecorgingName RecordinhTime RecordingDate System Analyst UserName Password Constraint ConstraintID ConstraintName Connection ConstraintText Description RelationID Name RelationID Name Relationship RelationshipID RelationName RelationPriority Description RelationID Name RelationID Name Mapping MappingID MappingName Figure 2.7: Class diagram for CAORT. Figure 2.8 illustrates the sequence diagram to show the ordered sequence of actions that occurs among the classes itself to capture the dynamic view of the system. : SysAnalyst Recording Figure 2.9: Layered architecture for CAORT The second important quality attributes are availability and performance. In conjunction to this, client server architecture as shown in figure 2.10 provides good support. As a result of this architecture, Figure 2.11 gives the design on the database using Entity Relationship Diagram (ERD). 1: Add() 2: Add( ) 3: Add( ) 4: Done 5: Record( ) 6: Done 7: Done 8: Add () 9: Add () 10: Add( ) 11: Done 12: Done Figure 2.10: Client-server architecture. Figure 2.8: Sequence diagram for CAORT. CAORT uses two architectural structures to work properly. The first one is three tier client-server architecture and the second one is layered architecture. This tool suggests these two architectural styles to achieve some important non-functional requirements. For instance, the security is very important quality ERD is used here to design the databases needed for such application, it illustrates the entities, their attributes and relationships.

5 Figure 2.12 shows some screen shots from the output of this test case. Figure 2.11: ERD for CAORT 4. CAORT implementation and testing This tool is a web-based application. Web applications have many advantages such as, allowing direct access to the application via multi-users, eliminate software distribution in more than one PC since the application need to be easy to maintain, application reuses and such application supports for many platforms. From the CAORT functionalities, the web-based application provides a platform for collaborative environment CAORT server side and client side implementation Various applications are used in server side; windows NT server handles the operation of server configurations as well as server maintenance with all synchronization control over different processes and recovery ability in case of failure, Internet Information System (IIS) monitors the database and the usage of it, Active Server Pages (ASP) is used to call when the application is running, Microsoft Standard Query language (MS SQL) to enable scalability, installation and data warehouse. In the client side, Hyper Text Markup Language (HTML) is used to design the controls of the ASP while java script is needed to enhance the design and for security sessions CAORT testing To evaluate the tool in term of usability and functionally, this research will be applying Clinic Information Management System/ Electronic Medical Record Requirement (CIMS/EMRR) as a case study. Figure 2.12: Screen Snapshot 5. CAORT contribution This section highlights the significance and contributions of this research. In addition, it explains the observation on weaknesses and strengths of this research as well as propositions for improvement and future works Significance and Contributions of CAORT a. The tool applies Concern Space Modeling Schema (COSMOS) b. The tool enhances the existing requirement engineering tools by providing the ability of more than system analyst to participate with each other to classifying concerns from the earlier stage of software life cycle. c. The tool uses the concept of collaborative and combines it with Space Modeling Schema (COSMOS) as on of aspect-oriented requirement engineering approaches. d. The research enhances COSMOS by adding new feature while classifying concerns and their relations which is named as priority. e. A research thesis study about the literature review, CAORT techniques and algorithms, CAORT methodology, CAORT analysis, design, implementation, testing and future work and recommendations.

6 5.2 Observation on Weaknesses and Strengths It is very normal that systems have strengths and weaknesses. Different observers have different opinions and ways for looking at and evaluating systems. However, there are certain strengths and weaknesses that could be mentioned in this part Strengths In this technological era, system analyst prefer to complete their work in fastest and easiest way as possible as they can, so this tool give the system analyst not only to complete their work but in an efficient way also. This CAORT is available to be used by any authorized system analyst by providing a security over the tool. The tool provides the ability to send online message through internet and intranet also to other online system analysts. This project will open rooms for more researchers and projects done by the UM students, since students will be able to refer to this project and its report for their own benefits in developing systems. The tool provides the ability to open simple chatting rooms among system analyst to share their opinions before decision is made. The tool combines two different areas together, the first one is Computer-Supported Collaborative Working (CSCW) and the second one is Aspect-Oriented Requirement Engineering Weaknesses It is not easy to handle this type of application since it uses new concepts in research which is Multi-dimensional separation of concerns using Concern Space Modeling Schema (COSMOS). Currently the system supports English language only. It is not supporting for all processes in requirement engineering such as feasibility study and elicitations. It is still under the risk of human mistakes since that the system analyst analyzing the requirement that already elicited Future Research Theoretically, this system is very effective and efficient, but there are still propositions for improvement in this system in order to make it more useful. The Aspect-Oriented Requirement Engineering has a very wide scope, and there will always be new developments in this technology and new rooms for researchers and creativity in developing such systems. Many things need to be considered in improving this system further. The followings will briefly explain about such propositions for improvement: The tools shall be able to accept the participations of other stakeholders in the processes of separation for concerns. The system shall provide multi-language user interfaces such as Arabic languages and even Bahasa Melayu language to encourage and increase the number of users from different geographical areas. 6. Conclusion This research has covered a Collaborative Aspectoriented Requirement tool using Concern Space Modeling Schema (COSMOS). In addition, this research has achieved and met the objectives of developing it, and it is hoped that this research will benefit the system analyst as it is designated for that purpose. However, this CAORT had shown the strengths and weaknesses of developing it. Thus, the achievements of this system are very valuable and definitely have benefited researchers and developers of such a system. In conclusion, this system needs to be improved in the coming future to adapt to the various and different aspect orientation approaches with multi-user interfaces. 7. References [1] Stanley M. Sutton, Jr., lsabelle R. (2002). Modeling of software concerns in Cosmos, in, Proceedings of the 1st international conference on Aspect-oriented software development Enschede, The Netherlands. Pages: ISBN: X

7 [2] Nuseibeh B. & Easterbrook S. (2000). Requirements Engineering: A Roadmap. Proceedings of International Conference on Software Engineering (ICSE-2000), 4-11 June 2000, Limerick, Ireland. [3] Kotonya G., Sommerville I. (1998). Requirement engineering processes. [4] Sommerville I. and Sawyer P. (1996). PREview Viewpoints for Process and Requirements Analysis. Lancaster University, Lancaster REAIMS/WP5.1/LU060. [5] Ruzanna C., Américo S., Awais R., Paul R. (2005). A Tool Suite for Aspect-Oriented Requirements Engineering. Lancaster University. Lancaster LA1,4WA,UK. [6] Chitchyan R., Awais R., Pete S., Alessandro, Garcia, Mónica P. Alarcon, Jethro B., Bedir T., Siobhán C., Andrew J. (2005). Survey of Analysis and Design Approaches [7] Rashid A., A. Moreira, and J. Araujo. (2003). Modularization and Composition of Aspectual Requirements, presented at 2nd International Conference on Aspect-oriented Software Development (AOSD), Boston, USA. [8] Yijun Yu, Leite P., and J. Mylopoulos. (2004). From Goals to Aspects: Discovering Aspects from Requirements Goal Models, presented at International Conference on Requirements Engineering, Kyoto, Japan. [9] Moreira A., J. Araujo, and A. Rashid. (2005). Multi- Dimensional Separation of in Requirements Engineering, in, presented at Requirements Engineering Conference.