Advanced Separation of Concerns for Requirements Engineering Isabel Sofia Brito1 and Ana Moreira2 1
Escola Superior de Tecnologia e Gestão, Instituto Politécnico de Beja, Beja, Portugal
[email protected] 2 Departamento de Informática, Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa, Portugal
[email protected]
Abstract. Separation of concerns is a fundamental software engineering principle that proposes the encapsulation of each matter of interest in a separate module. Software engineering development methods have been created with this principle in mind. However, concerns such as security, fault tolerance and usability are not handled effectively. These concerns may cut across many other concerns and therefore cannot be kept separated in different modules. They are responsible for producing tangled representations that are difficult to understand, maintain and evolve. An effective requirements engineering approach should reconcile the need to handle crosscutting concerns with the need to integrate existing technologies. Our goal is to propose a generic model to handle advanced separation of concerns at the requirements level.
1 Introduction Separation of concerns aims at identifying and modularizing those parts of software that are relevant to a particular concept, goal or purpose. Traditional approaches to software development, such as object-oriented and structured methods, have been created with this principle in mind. However, they are unable to handle broadly scoped requirements and constraints, also known as non-functional requirements. Nonfunctional requirements are global properties of a system and usually refer to quality of service (e.g. accuracy and compatibility). Recent approaches [6, 16] achieve separation of concerns by integrating functional and non-functional requirements. Nevertheless, they do not consider the crosscutting nature of some of those concerns. The result is that the implementation of these crosscutting concerns are spread among several modules, producing tangled representations that are invasive to implement, and therefore difficult to understand, maintain and evolve. An effective requirements engineering (RE) approach should reconcile the need to integrate those two kinds of concerns with the need to modularize those that are crosscutting. Recent advanced separation of concerns techniques focus on crosscutting concerns [12, 17]. Our goal is to provide new abstractions and composition mechanisms to identify, modularise and compose such concerns during requirements engineering.
This paper extends the work already presented in [11, 13] by proposing a novel process for composition that introduces the new notions of match point, dominant concern and LOTOS operators to define composition rules. In addition, we recommend the use of existing catalogues to alleviate both the identification and the specification tasks. This paper is organized as follows. Section 2 introduces a generic model for advanced separation of concerns for requirements engineering. Section 3 applies it to a case study. Section 4 presents a brief background and the related work. Finally, Section 5 draws some conclusions and identifies a few tasks we need to develop in the near future.
2 Advanced Separation of Concerns for RE A generic model to handle advanced separation of concerns during requirements engineering is depicted in Figure 1. It is composed of four main tasks: identify concerns, specify concerns, identify crosscutting concerns, and compose concerns. INPUT
bc Task 1: Identify
#Task 2: Specify
concerns
concerns
/
Task 3: Identify crosscutting concerns
2.1: Using best approach CATALOGUES
2.2: Identify contributions
2.3: Identify priorities and interrelationship
Task 4: Compose concerns 4.1: Identify match points 4.2: Identify conflicts 4.3: Identify dominant 4.4: Define composition rules OUTCOME
Templates Rules
Visual models
Figure 1: A model for advanced concerns at RE
Despite the direction of the thick black arrows, indicating forward development, an iterative and incremental process should guide the model. Task1: Identify concerns. A concern is any matter of interest in a system, i.e., it is a goal or a set of properties that the system must satisfy. The identification of concerns is accomplished by undertaking a complete and exhaustive analysis of the documentation and any other information provided by the system’ stakeholders. (Stakeholders are all
the people that have a direct or indirect influence in the project. They may be users, clients, managers, developers, etc.) We may use any of the existing techniques for requirements elicitation. While some techniques emphasize the main functions that the future system should implement (e.g. use cases [14]), others emphasize constraints and certain properties that affect the whole system (e.g. the NFR framework [3]). Traditional techniques concentrate on the functional behavior of a system and they are part of the common knowledge of any software engineer. However, experts in NFRs, for example, are a lot harder to find. This is also true for techniques integrating both types of concerns, such as [6]. To alleviate the onus of the identification of the broadly scoped requirements we propose the use of existing catalogues, such as [3]. Each concern should be registered in a template as depicted in Table 1. Table 1: A template to describe concerns
Stakeholders
The name of the concern. Source of information, e.g. stakeholders, documents, domain, catalogues and business process. Users that need the concern in order to accomplish their job.
Description
Short description of the intended behaviour of the concern.
Classification
Helps the selection of the most appropriate approach to specify the concern. For example: functional, non-functional, goals. Represents how a concern can be affected by other concern. This contribution can be positive (+) or negative (-) Expresses the importance of the concern for the stakeholders. It can take the values: Very Important, Important, Medium, Low and Very Low. List of concerns needed by this concern.
Name Source
Contribution Priority Interrelationships
The outcome of this task is the completion of the rows Name, Source, Stakeholder and Description. The remaining rows will be filled during Task 2. Task 2: Specify concerns. This task is divided into three subtasks: apply the approach that better specifies each concern; identify contributions between concerns so that conflicts can be detected; identify priorities and interrelationships. Besides completing the remaining unfilled rows in each template, these subtasks will produce auxiliary documentation generated by the chosen specification technique (e.g. use cases, viewpoints, interdependency graphs, etc). Task 2.1: Specify concerns using the best approach. We may use any of the existing techniques for requirements specification. In certain cases a choice may have been done during Task 1, especially if particular techniques have been used to help the elicitation process. If so, we should build any models or other documentation proposed by those techniques. Based on this we can fill the Classification row in Table 1. Task 2.2: Identify contributions between concerns. A contribution relationship between two concerns defines the way in which one concern affects the other. This contribution can be collaborative (or positive, helping the affected concern) and is represented by “+”, or damage (or negative, obstructing the affected concern) and is
represented by “-“. This information is added to the Contribution row in Table 1. It is based on this information that we will be able to detect conflicts between concerns. Task 2.3: Identify priorities and interrelationships. A priority gives the degree of importance of a concern in the system. The priority of a concern is context dependent, i.e., the same concern can be classified differently by the stakeholder depending on the business domain. This information is added to row Priority in Table 1. Interrelationships provide the list of concerns that a given concern needs. This information is added to row Interrelationships in Table 1. If the list is empty, i.e. the concern under study needs no other concern we add to the row the keyword none. Task 3: Identify crosscutting concerns. A concern is crosscutting if it is needed by more than one other concern. This task is accomplished by taking into account the information in rows Interrelationships and Descriptions in Table 1. Task 4: Compose concerns. The goal of this task is to compose all the concerns to form the whole system. In this paper we will focus our attention to the composition of those concerns that are crosscutting, as the non-crosscutting ones bring no new problems. To guide the composition, we propose four subtasks: identify match points, identify conflicts, identify the dominant concern, and define the composition rules. Task 4.1: Identify match points. Based on row Interrelationships in Table 1 we identify the points where the composition will take place, i.e. the match points. A match point tells us which crosscutting concerns should be composed with a given concern. This can be better illustrated with a bi-dimensional table of Non-Crosscutting Concerns X Users (see Table 2). Each cell is filled with the list of crosscutting concerns (denoted CCi) that affect a given concern and represents a match point (denoted MPi). One composition rule must be defined for each match point. Table 2: Match points identification Concerns Users User1 User 2 … User n
Concern1 CC1, CC2 (MPA) CC1, CC3 (MPB) …
Concern2
…
Concernm CC2, CC5 (MPJ)
… CC1, CCk (MPI)
CC3,C C5 (MPZ)
Task 4.2: Identify conflicts. This subtask supports the identification of conflicting situations between concerns. For a given match point we need to analyse if any of the involved crosscutting concerns contribute negatively to any other (based on the Contribution row in Table 1). Concerns contributing positively to other concerns raise no problems. Task 4.3: Identify dominant concern. This subtask helps solving the conflicts identified in the previous subtask and is based on Priority row in Table 1. If the priority attributed to each concern is different, the problem is not too difficult to solve, and the dominant concern is that with higher priority. However, if at least two crosscutting concerns have the same priority, a trade-off must be negotiated with the user. To guide the negotiation among users we propose the identification of the dominant crosscutting concern for a given match point. Therefore, if more than two crosscutting concerns
exist in a given match point, with negative contribution and the same priority, we start by analysing two concerns first to identify the dominant, then take the dominant and analyse it with a third concern and so forth until we have taken into consideration all the crosscutting concerns. The result is the concern with higher priority between them all. Next we need to identify the second dominant crosscutting concern among the remaining concerns, and so forth until we have a dependency hierarchy between all the concerns. The identification of the dominant concern is important to guide the composition rule. Task 4.4: Define composition rules. The composition rule defines the order in which the concerns will be applied in a particular match point. It takes the form: . The operators we propose are taken from the LOTOS language [2]. In the descriptions below Ci denotes Concerni: −
Enabling (denoted by C1>>C2): This is a sequential composition and means that the behaviour of C2 begins if and only if C1 terminates successfully.
−
Disabling (denoted by C1[>C2): This is the disabling composition and means that C2 interrupts the behaviour of C1 when it starts its own behaviour. This allows the representation of interruptions.
−
Pure interleaving (denoted by C1|||C2): This is a parallel operator and means that C1 evolves separately from C2. It represents concurrent composition without interaction.
Full synchronization (denoted by C1||C2): This is another parallel operator and means that the behaviour of C1 must be synchronized with the behaviour of C2. It represents concurrent composition with interaction. A composition rule can be defined based on simpler composition rules, separated by one of the above operators. We will use brackets (“(“ and “)”) to attribute priorities to the operators.
−
3 Applying the Approach to a Case Study The case study we have chosen is a simplified version of the real system implemented in the Portuguese motorways network [4]: “In a road traffic pricing system, drivers of authorized vehicles are charged at toll gates automatically. The gates are placed at special lanes called green lanes. A driver has to install a device (a gizmo) in his/her vehicle. The registration of authorised vehicles includes the owner’s personal data, bank account number and vehicle details. The gizmo is sent to the client to be activated using an ATM that informs the system upon gizmo activation. The toll gate sensors read a gizmo. The information read is stored by the system and used to debit the respective account. When an authorized vehicle passes through a green lane, a green light is turned on, and the amount being debited is displayed. If an unauthorised vehicle passes through it, a yellow light is turned on and a camera takes a photo of the plate (used to fine the owner of the vehicle). There are three types of toll
gates: single toll, where the same type of vehicles pay a fixed amount, entry toll to enter a motorway and exit toll to leave it. The amount paid on motorways depends on the type of the vehicle and the distance travelled.” Task 1: Identify concerns. Based on the requirements given above, we can identify the following concerns: Register Vehicle, Pass Single Toll, Enter Motorway, Exit Motorway, Pay Bill, Compatibility and Response Time. The first five concerns are not too difficult to identify, if we think in terms of uses cases, for example. Compatibility is needed because the system needs to interact with the external system ATM. On the other hand, Response Time is an issue when a customer activates his/her own gizmo in an ATM, or when a vehicle passes a toll gate (the toll gate components have to react in time so that the driver can see the light and the amount being displayed). Other concerns can be identified based on the NFR catalogue [3]. For each entry in the catalogue, we must decide whether it would be useful in our system or not. For example, if the owner of a vehicle has to indicate, during registration, his/her bank account details, so that automatic transfers can be performed automatically, then Security is an issue that the system needs to address. Other concerns identified based on this catalogue are Legal Issues and Correctness. For each of these concerns we start filling in a template. Here we show only the templates that will help us illustrating concerns that are crosscutting and a situation of possible conflict. The concerns chosen are Register Vehicle (Table 3), Response Time (Table 4) and Security (Table 5). Task2: Specify concerns. Concerns are specified using the following three subtasks. Task 2.1: Specify concerns using the best approach. Apply the techniques that best suite the specification of the concerns encountered. In Task 1 we have already made a choice when identifying concerns. Therefore, we should specify the first five concerns using use cases (through scenarios, for example) and the rest of the concerns using Softgoal Interdependency Graphs (SIG). The nodes of a SIG are (non-functional) concerns, and are represented by clouds, and the lines represent decompositions (of a given concern into its sub-concerns). When all sub-concerns of a given concern are needed to achieve that concern, an AND relationship is defined with an arc connecting the lines (see Figure 2). If, on the contrary, not all the sub-concerns are necessary to achieve the concern, we have an OR relationship is defined with two arcs linking the decomposition lines. S ecu r ity R eg ister V eh icle
In teg r ity [V eh icle O w n er D a ta ]
C on fid en tia lity [V eh icle O w n er D a ta ]
Figure 2: Security specification for Register Vehicle
In this case Integrity and Confidentiality are both needed to achieve Security, so an AND relationship is required. Notice that a subject matter is added under the concern
name. A subject matter is the topic addressed by the non-functional concern. In Figure 2 Security influences Register Vehicle while Integrity and Confidentiality influence Vehicle Owner Data. Task 2.2: Identify contributions between concerns. For each concern we must identify its contribution to others concerns and fill the Contribution row in the template. Based on the NFR catalogue, we could, for example, say that Security has a collaborative (+) contribution with Correctness and a damage (-) contribution with Response Time. Also, response time has a damage contribution with Security and Correctness (see Tables 4 and 5). Task 2.3: Identify priorities and interrelationships. In this task we identify the importance of each concern to the system (and fill in the Priority row) and express if one concern needs other(s) concern(s) to accomplish its behaviour (and fill in the Interrelationships row). At the end of this task, the template of each concern will be complete. Table 3: Register Vehicle template Name Source Stakeholders Description Classification Contribution Priority Interrelationships
Register Vehicle Stakeholders, requirements, knowledge of the system Vehicle Owner, Bank Is responsible for registering a vehicle and its owner, and communicating with the bank to guarantee a good account Functional Very Important Response time, Correctness, Security
Table 4: Response time template Name Source Stakeholders Description Classification Contribution Priority Interrelationships
Response Time Stakeholders, requirements, NFR catalogue, knowledge of the system Vehicle Driver, Vehicle Owner The system has to react in time in specific situations, for instance, when a vehicle uses a tollgate or when a bank is need to reactivate the gizmo. Non-functional (-) Correctness, (-) Security Very Important
Table 5: Security template. Name Source Stakeholders Description
Security Stakeholders, requirements, NFR catalogue Bank, Vehicle Owner The system must guarantee the security/protection of the data on the system. For instance, guarantee the protection of the owner data and the bank data.
Classification Contribution Priority Interrelationships
Non-functional (+) Correctness, (-) Response Time Very Important
Task 3: Identify crosscutting concerns. Looking at rows Interrelationships and Description we can identify crosscutting concerns. For example, Response Time is crosscutting because it is needed in Pass Single Toll and Register Vehicle. Security, on the other hand, is also crosscutting, as it is needed in Pay Bill and Register Vehicle. Other crosscutting concerns are: Compatibility and Correctness. Task 4: Compose concerns. The goal here is to compose all concerns to obtain the whole system. During this process conflicts may be identified. Task 4.1: Identify match points. This is accomplished by building the match points table (see Table 6). Table 6. Identification of match points (CR: Correctness; CM: Compatibility; RT: Response Time; S: Security; LI: Legal Issues) Concern User Bank Vehicle Owner Vehicle Driver
Register Vehicle RT, S, CR (MPA) RT, S, CR (MPB)
Pay Bill
Pass Single Toll
…
CM, RT, CR (MPG)
…
CM, S (MPC) LI, S (MPD)
Task 4.2: Identify conflicts. When the same cell lists more than one crosscutting concern we must verify the contribution between them. For example, in our case study the MPA match point has three concerns. As we identified in Task 2.2, Security and Response Time, for example, contribute negatively to each other and they may generate a conflict. Another possible conflict may be found between Correctness and Response Time as they also contribute negatively to each other. Task 4.3: Identify dominant concern. To solve the possible conflicts identified above, we need to verify the priority of each concern involved. Let us only deal with Security and Response Time. As both have the same priority (Very Important) we need to negotiate a trade-off with the system’s stakeholders. Supposing that the priority of Response Time is decreased, Security becomes the dominant concern in MPA. However, as Security is composed of two sub-concerns, we need to make clear if both need to be dominant with respect to Response Time. What makes sense in this situation is to guarantee Confidentiality first and only at the end guarantee Integrity. Therefore the hierarchy would be Confidentiality, Response Time and Integrity (in decreasing order of importance). Task 4.4: Define composition rules. A composition rule for MPA could be defined using LOTOS operators as follows: Security.Confidentiality >> (RegisterVehicle || ResponseTime)>> Security.Integrity
This composition rule expresses the order in which each concern must be satisfied. After the successfully satisfaction of Confidentiality, ResponseTime and RegisterVehicle must synchronize so that both concerns are satisfied in parallel, and only after their successful satisfaction will Integrity be satisfied. Notice that we are using the “.” notation to access a sub-concern of a given concern (e.g. Security.Confidentiality).
4 Related Work Crosscutting concerns, in general, are responsible for producing spread and tangled representations (e.g. specifications, code) that are invasive to implement, and therefore difficult to understand, and hard to evolve. Aspect-oriented software development (AOSD) aims at providing means for their systematic identification, separation, representation and composition, throughout the software life cycle. Several aspectoriented programming approaches that implement crosscutting concerns are available. Examples are AspectJ [17], composition filters [1], adaptive programming [10] and Hyper/J [12]. Recently, a number of researchers have been proposing the use of aspectoriented concepts in the earlier phases of the software development, such as design [5, 8, 9, 15] and requirements analysis [8, 11, 13]. Grundy proposes an aspect-oriented component requirement engineering (AOCRE) method targeted at component based software development [7]. For the last two years we have been investigating how crosscutting requirements can be effectively managed during requirements engineering. As a result of this work we have proposed a general model [13] that uses XML to define the composition rules and a tool to validate them, and another to handle quality attributes [11] with the UML. In the present paper the focus is on the composition task, introducing the new notions of match point and dominant concern. A match point is an abstraction of the join point concept in AspectJ [17]. Clark [5] also mentions this idea in her work on aspect design and composition, but here we are at a different level of abstraction. Other novel ideas, and therefore different from our previous work, are the use of existing catalogues to help identify and specify concerns and LOTOS operators to build composition rules.
5 Conclusions and Future Work This work provides support to deal with crosscutting concerns during requirements engineering. It extends the work developed in [11, 13], providing new ideas for the identification, specification and composition of crosscutting concerns. The novelty introduced here is, on the one hand, the use of existing catalogues to help identify and specify concerns and, on the other hand, a new composition process with the introduction of match points, dominant aspects and composition rules using LOTOS operators. This work is only in its infancy and therefore we still have several parts to refine, extend and test. However, writing this paper showed us the following tasks to be done in a very close future: define composition rules at a finer level of granularity, i.e. compose crosscutting actions or behaviour with the requirements it cuts across; study
the level of granularity at which a conflicting situation can be handled; define a visual integrated notation, probably based on UML. Finally, we need to define a composition language to help us express, at this high level of abstraction, the way a crosscutting concern influences the behaviour of other concerns. In this paper we have inspired ourselves in the LOTOS formal description language. Since LOTOS is also an executable language, we plan to investigate how to take advantage of this feature and produce animated concern-oriented requirements specifications.
References 1. Bergmans, L. M. J. and Aksit, M.: Composing Crosscutting Concerns using Composition Filters, Communications of ACM. Vol. 44, No. 10, pp. 51-57 2001. 2. Brinksma E. (ed): Information Processing Systems -- Open Systems Interconnection-LOTOS -- A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour, ISO 8807, 1988 3. Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000. 4. Clark, R., Moreira, A.: Constructing Formal Specifications from Informal Requirements, Software Technology and Engineering Practice, pp. 68-75, IEEE Computer Society, Los Alamitos, California, July 1997. 5. Clarke, S., Walker, R.J.: Composition Patterns: An Approach to Designing Reusable Aspects, Proceedings of International Conference on Software Engineering, ICSE 2001, Toronto, Canada, 2001. 6. Dardenne, A., Lamsweerde, A., Fickas S.: Goal-directed Requirements Acquisition, Science of Computer Programming, Vol. 20, nº 1, pp. 3-50, 1993. 7. Grundy, J.: Aspect-oriented Requirements Engineering for Component-based Software Systems, 4th IEEE International Symposium on Requirements Engineering, IEEE Computer Society, Limerick, Ireland, 1999, pp. 84-91. 8. Herrero. J., Sánchez F., Lucio F., Toro M.: Introducing Separation Of Aspects At Design Time, ECOOP Workshop on Aspects and Dimensions of Concerns, 2000. 9. Ho, W.-M., Pennaneac’h F., Plouzeau, N.: UMLAUT: A Framework for Weaving UMLBased Aspect-Oriented Designs, http://www.irisa.fr/pampa/UMLAUT/download.htm. 10. Lieberherr, K. J.; Orleans, D., Ovlinger, J.: Aspect-Oriented Programming with Adaptive Methods, Communications of ACM, Vol. 44, No. 10, pp. 39-41, 2001. 11. Moreira, A., Araújo, J., Brito, I.: Crosscutting Quality Attributes for Requirements Engineering, 14th International Conference on Software Engineering and Knowledge Engineering (SEKE 2002), ACM Press, Italy, July 2002. 12. Ossher, H., Tarr P. L.,: Hyper/J: multi-dimensional separation of concerns for Java, International Conference on Software Engineering, ACM, pp. 734-737, 2001. 13. Rashid, A., Moreira, A., Araujo, J.: "Modularisation and Composition of Aspectual Requirements", 2nd International Conference on Aspect-Oriented Software Development, ACM Press, 2003, pp. 11-20 14. Schneider, G. and Winters, J.: Applying Use Cases – A Practical Guide, Addison-Wesley, 1998. 15. Suzuki, J. and Yamamoto, Y.: Extending UML with Aspects: Aspect Support in the Design Phase, AOP Workshop at ECOOP’99, Lisbon, Portugal, 1999. 16. Yu E.: Modeling Strategic Relationships for Process Reengineering, PhD Thesis, University of Toronto, 1995. 17. Xerox Parc, AspectJ home page, Technical report, http://www.aspectj.org/, 2001.
