Identifying Aspectual Use Cases Using a Viewpoint-Oriented Requirements Method
João Araújo Departamento de Informática, FCT, Universidade Nova Lisboa 2829-516 Caparica, Portugal
[email protected]
Paulo Coutinho Departamento de Informática, FCT, Universidade Nova Lisboa 2829-516 Caparica, Portugal
[email protected]
tangled or duplicated representations of requirements. Therefore, it is essential that the crosscutting nature of stakeholders’ requirements be considered to avoid having the same requirements spread over the specification document, which turns to be more difficult to maintain.
Abstract The success of large-scale software systems depends on how accurate the huge amount of requirements is elicited and analysed by software engineers. Requirements engineering provides suitable approaches to define requirements of such systems in a systematic way. For example, viewpoint and object-oriented approaches have adequate mechanisms to reach these purposes. Nevertheless, the crosscutting nature of requirements is not addressed by these approaches, but this can be managed using aspect-oriented concepts. This work describes how aspects could be integrated to Vision, a viewpoint-oriented requirements method that integrates UML models.
The aspect-oriented paradigm can be used to answer this problem as crosscutting requirements can be seen as aspects. In our approach, functional requirements are abstracted in use cases (which are related to viewpoints) and the crosscutting ones will be called aspectual use cases. This paper is organised as follows. Section 2 summarises Vision extended to aspects, section 3 presents a case study applied to the approach, section 4 discusses some related work and section 5 presents some conclusions and future work.
1 Introduction Large-scale software development involves several participants. Each participant, or stakeholder, may have different roles, responsibilities and concerns, which can change at any time. This situation may generate some problems. For example, with several stakeholders, it is likely to appear inconsistencies and conflicts. So it is crucial identify and resolve them at early stages.
2 Vision and Aspects Vision [Coutinho, 2002] is a viewpoint-oriented requirements method based on VORD [Kotonya and Sommerville, 1992], and Preview [Sommerville et al., 1998]. What distinguishes Vision from them is that it incorporates UML models [OMG, 2002] and describes associations and aggregations among viewpoints. In this paper, we want to adapt Vision to include aspects.
At requirements level, viewpoint-oriented approaches appeared to address these problems through their structuring mechanisms. A viewpoint encapsulates information of a stakeholder, localizing the part of the specification relevant to his/her interests and responsibilities.
During the process, templates are created to describe each viewpoint, a viewpoint diagram (based on a class diagram) is used to show the relationships among viewpoint, and sequence diagrams illustrate the interaction among viewpoints. Figure 1 presents a process model for Vision.
However, there are situations that are not tackled properly by viewpoint-oriented approaches. For example, when a stakeholder provides system requirements that may crosscut other requirements of a different stakeholder. This circumstance can lead to
1
Vision
Elicit requirements
Identify & specify NFR
Identify & define VPs
Associate NFRs with VPs and UCs
Identify actors & UCs
Identify NF candidate aspects
Identify aspectual UCs
Define communication between VPs
Identify rel. between VPs
Define interaction between VP and system
Identify and solve conflicts
Specify requirements Figure 1 – Process model for Vision Each activity is described as follows. Table 1 – Template for a NFR
Elicit requirements Through interviews, questionnaires, manuals and other documents the essential requirements are obtained. Requirements elicitation involves careful capture and organization of all the system information, and this can be huge. In our approach, the organization is realised via templates and diagrams, used in the next activities. The aim of the elicitation process is to produce a document with all the requirements of the future system.
NFR Name
Description Represents the name of the NFR
Description
Gives a brief description of the NFR.
Influence
Contribution
Identify and specify non-functional requirements (NFRs)
Priority
This activity identifies NFRs of a system, like security and performance, through the analysis of the elicited requirements. Each NFR is described using a template as shown in table 1. This is based on the approaches described in [Chung et al., 2000] and [Moreira et al., 2002].
V P
List of viewpoints affected by the NFR .
U C
List of use cases affected by the NFR . List of positive (+) or negative (-) contributions (-) in relation to other NFR . Classified from 1 to 5. (1-very low; 2-low; 3-medium; 4-high; 5-very high)
Identify and define viewpoints By analysing the elicited requirements, we can identify the relevant viewpoints to the system and specify each one by means of its name, sources, actors, use cases, NFRs, relationships with other viewpoints and history. The resulting template imports elements from VORD and Preview and adds others to consider requirements analysis with UML. Table 2 shows the viewpoint template and a brief description of its attributes.
NFRs can conflict with each other. A conflict is represented by negative contributions between NFRs.
2
Table 2 – Template for viewpoint Viewpoint attribute
Attribute Description
Name
After the identification of NFRs, viewpoints and their use cases, it is necessary to check which viewpoints and use cases are influenced by a NFR and for each viewpoint/use case which NFRs affect it. This can be realised by using the templates of tables 1, 2 and 3. Here, we can use a similar approach as in [Rashid et al., 2002] where concerns that affect more than one viewpoint are called candidate aspects. However, we prefer to call them non-functional candidate aspects, to differentiate from the functional ones (aspectual use cases). Also, we extend that approach by saying that if a NFR crosscuts several use cases of one or various viewpoints they are also called non-functional candidate aspects.
This identifies the viewpoint.
Focus Sources Actors NFRs Use Cases
Aggregation
Association
Gen/ Spec
Associate NFR with viewpoints and use cases and identify non-functional candidate aspects
Sub VP Sup er VP
This shows the definition of the perspective taken by the viewpoint. This shows a list of sources of the viewpoint’s requirements. This shows a list of actors associated with the viewpoint. This shows a list of the NFRs applied to the viewpoint. This shows a list of functionalities relevant to the viewpoint. This shows a list of aggregations where the viewpoint is involved, illustrated in the viewpoint diagram and a specific template. This shows a list of associations where the viewpoint is involved, illustrated in the viewpoint diagram and a specific template.
Having identified and specified use cases, we are able to check whether there is a use case included by more than one use case of one or more viewpoints, or if there is a use case that extends more than one use case. If this is the case we have an aspectual use case, because it crosscuts several use cases. This use case may be designed and implemented as an aspect (using AspectJ, for example). Moreover, an aspectual use case would be the one that crosscuts several viewpoints. This is useful in the identification and resolution of conflicts, described later.
This shows a list of sub viewpoints, illustrated in the viewpoint diagram. This shows a list of super viewpoints, illustrated in the viewpoint diagram. This keeps the alterations of viewpoint information through time.
History
Identify aspectual use cases
the
A viewpoint can also be represented as a UML class with the stereotype «Viewpoint».
Identify relationships between viewpoints Relationships such as aggregation, association and generalisation/specialisation are powerful structural concepts that Vision applies to viewpoints. Generalisation/specialisation is defined similarly as in Preview and VORD. Viewpoints can be also part of other viewpoints, characterising viewpoint aggregation. An association between viewpoints implies the existence of interaction between the actors of different viewpoints, which is external to the system. This would be interesting to document in order to be used during the evolution of a system: some of these interactions would become part of the system. A viewpoint diagram (similar to a class diagram) is used to represent these relationships.
Identify and define actors and use cases for each viewpoint By analysing the requirements, we identify actors and use cases of the system’s viewpoints, and document this in the viewpoint template. Use cases express the functionality of a system available to their actors. Actors and use cases can be associated to more than one viewpoint. Table 3 shows a template that can be used to describe a use case in detail. Table 3 – Template for a use case Use case Name Description Actors Viewpoints
Description Represents the name of the use case. Gives a brief description of the use case. List of actors that use the use case. List of viewpoints associated with the use case.
Primary scenario Secondary scenarios Extends
List of use cases that this use case extends.
Includes
List of use cases that this use case includes.
NFRs
List of NFRs that affect this use case.
Define communication between viewpoints and interaction between viewpoint and system Communication is described through scenarios that represent a dialogue between the actors of viewpoints. Message exchange can be specified using sequence diagrams. Also, the interaction between viewpoint’s actors with the system can be illustrated using sequence diagrams. Here, the approach in [Moreira et al., 2002] can be used to represent some aspects (seen as crosscutting quality attributes), such as performance, in sequence diagrams.
Specification of the happy day scenario. Specification of the other scenarios.
3
Identify and solve conflicts
Identify and define viewpoints
To identify and resolve conflicts, we adapted the AORE approach [Rashid et al, 2003]. They use a table to check the contribution between candidate aspects. Negative contributions imply conflict if the candidate aspects have the same priority. We do exactly the same for our nonfunctional candidate aspects. We also suggest a similar table to check conflicts between aspectual use cases, shown in table 4.
By analysing the requirements, we identify accounting department as a viewpoint, described in table 6. Table 6 – Template for the accounting department viewpoint Viewpoint attribute
Table 4 - Contributions between aspectual use cases Note: AUC stands for Aspectual Use Case AUC AUC AUC1 AUC2 … AUCn
AUC1
AUC2 −
…
AUCn + −
The AORE approach uses a table to relate viewpoints and candidate aspects (which can be also used to relate use cases to non-functional candidate aspects). For candidate aspects in conflict with the same viewpoints (and, in our approach, also use cases), weights are attributed to them.
Attribute Description
Name
Accounting department.
Focus
It manages payments of salaries, services, etc.
Sources
Accounting manuals, etc.
Actors
Head of accounting accounting assistants.
NFRs
Security, performance.
Use Cases
Payment of salaries, payment of services, cheque printing, etc.
department,
Identify and specify non-functional requirements (NFRs) The NFRs that we identify in our example are security and performance, through the analysis of the elicited requirements. They are described in tables 7 and 8.
We also suggest creating two other similar tables: one to relate aspectual use cases to viewpoints and another one to relate aspectual use cases to use cases. Table 5 summarises these tables.
Security contributes negatively to performance, because more tests are needed to access the system making it slower. On the other hand, performance contributes negatively to security as, to be faster, the system may become more vulnerable.
Table 5 - Relating aspectual use cases to viewpoints/use cases Note: VP stands for ViewPoint and UC to Use Case VP/UC AUC AUC1 AUC2 … AUCn
VP1/UC1
VP2/UC2
Table 7 – Template for security
… VPn/UCn
NFR Name
0.5
Description Security. Only authorised people should access information.
Description 0.5
V P U C
Influence
Stakeholders should use the tables during the negotiation process to help solving conflicts.
Specify requirements
Contribution Priority
In this activity the elaboration of specification document is carried on considering all the aspects identified and described. This activity is out of the scope of Vision.
NFR Name
Accounting dept. Payment of salaries, payment services. Negative (-) to performance. 5-very high.
of
Table 8 – Template for performance Description Performance. Information should be accessed in a short amount of time.
Description
3 Case study
Influence
The case study we have chosen is a simplified version of an accounting system of a public institution. In this organisation, the accounting department is responsible for payment of salaries and services (e.g., cleaning), acquisition of office materials, balance sheets, etc. The head of the accounting department is helped by accounting assistants.
Contribution Priority
4
V P U C
Accounting dept. Payment of salaries, services. Negative (-) to security. 5-very high.
payment
of
Table 10 - Relating NFR aspects and use cases
Identify and define actors and use cases for each viewpoint
UC
Table 9 – Template for the use case payment of salary Use case
Description
Name
Payment of salary.
Description
It calculates the salaries for all the employees of the institution.
Actors Viewpoints
1. Get info about employees; 2. Calculate salaries; 3. Print cheque.
Includes
Cheque printing.
NFRs
Security, performance.
Payment of services
…
Security Performance
1 1
1 1
… …
…
…
…
…
For space reasons we do not illustrate the identification of relationships between viewpoints, the definition of communication between viewpoints and the interaction between viewpoints and the system.
Head of accounting dept., accounting assistant. Accounting department.
Primary scenario
Payment of salaries
NFR
Table 6 lists the actors and use cases of the accounting department viewpoint. Table 9 describes the use case payment of salary.
4 Related work There are several viewpoint-oriented approaches for requirements. VORD (Viewpoint-Oriented Requirements Definition) [Kotonya and Sommerville, 1996] has a process that includes viewpoint identification, description of services (which could be our use cases), and conflict identification and resolution. Also, it has the concept of indirect viewpoint (i.e. viewpoints that are not directly related to the system, but influence it), which is used in Vision. In Preview [Sommerville et al., 1998] a viewpoint encapsulates information about the system obtained from the stakeholders. Preview includes viewpoint focus, concerns and history, which are adopted by Vision. Moreover, Preview has an elaborated mechanism to deal with conflict resolution, which could be considered in later versions of Vision.
Note that cheque printing is included by payment of salary and also to payment of service, obviously.
Associate NFR with viewpoints and use cases and identify non-functional candidate aspects The NFRs security and performance can be associated with the accounting department viewpoint and the use cases payment of salary and payment of service. Since they crosscut several use cases they are called nonfunctional candidate aspects.
Leite and Freeman [Leite and Freeman, 1991] describe a viewpoint-oriented approach where a viewpoint is a mental state. One characteristic of this approach is the automatic verification and error detection provided during elicitation, not contemplated by Vision.
Identify aspectual use cases Cheque printing is used by both payment of salary and payment of service. Therefore, since it crosscuts several use cases, it is classified as an aspectual use case.
Nuseibeh et al. [Nuseibeh et al., 1994] propose a flexible approach, allowing the specification of multiple viewpoints using no predefined notations. Nuseibeh and Finkelstein define a viewpoint as a way to encapsulate representation, development and specification of knowledge, in a particular problem domain [Nuseibeh and Finkelstein, 1992].
Identify and solve conflicts As we can observe from tables 8 and 9, there is conflict between the non-functional candidate aspects security and performance, as both contribute negatively to each other, have very high priority and affect the same use cases. Table 10 shows possible weights attributed to the NFRs in relation the use cases.
The approaches above are limited, as they do not address the crosscutting nature of requirements at early stages. Nevertheless, there are some aspect-oriented requirements approaches related to ours. For example, the approach by Grundy [Grundy, 1999] is committed to component based software development, where there is a categorization of various aspects of a system that each component provides to end users or other components. This approach is too particular for component development, not presenting proof of its use in software development in general.
The stakeholders involved must negotiate the conflicts. It is out of the scope of this paper to define a mechanism to deal with negotiation, but the tables provide the necessary information. A possible solution for this is to reduce the weights of performance for the two use cases to have a slower, but a more reliable system. Similarly, we can be apply the same strategy to solve conflicts involving aspectual use cases.
The aspect-oriented requirements engineering (AORE) approach, described in [Rashid et al., 2002], proposes a
5
[Chung et al., 2000] L. Chung, B. Nixon, E. Yu, J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000.
model for aspect-oriented requirements engineering (from which we adopted some elements). The model supports separation of crosscutting properties from early stages of the development and identification of their mapping and influence on later development stages. A refinement of this approach, using Preview and XML, is found in [Rashid et al., 2003], where composition rules for aspectual requirement are defined and a detailed conflict resolution strategy is presented. Nevertheless, the approach has not been instantiated to use cases - a broadly used requirements technique.
[Coutinho, 2002] P. Coutinho, “Vision: um método de elicitação e análise de requisitos orientado a viewpoints”, Master’s thesis (in Portuguese), submitted in December 2002. [Grundy, 1999] J. Grundy, “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.
In [Moreira et al., 2002], functional requirements are specified using a use case based approach, and quality attributes (NFRs) are also described with templates, identifying those that crosscut functional requirements. They propose a set of models (use cases and sequence diagrams) to represent the integration of crosscutting quality attributes with functional requirements. A similar approach is found in [Araújo, 2002].
[Kotonya and Sommerville, 1992] G. Kotonya, I. Sommerville, "Viewpoints for Requirements Definition", Software Engineering Journal, 7 (6), 1992, pp. 375-387. [Kotonya and Sommerville, 1996] G. Kotonya, I. Sommerville, "Requirements Engineering With Viewpoints", BCS/IEE Software Engineering Journal, 11(1), 1996, pp. 5-18.
5 Conclusions and future work
[Leite and Freeman, 1991] J.C.P. Leite, P.A. Freeman, “Requirements Validation through Viewpoint Resolution”, IEEE Transactions on Software Engineering, 17(12), 1991, pp. 1253-1269.
This paper presented a viewpoint-oriented requirements approach with UML, which was extended to include aspect-oriented concepts. This is observed during the definition of both non-functional requirements and use cases. NFRs that crosscut a number of viewpoints or use cases are non-functional candidate aspects. Use cases that are included by or extend more than one use case are called aspectual use cases. Also, uses cases that crosscut several viewpoints are also called aspectual use cases.
[Moreira et al., 2002] A. Moreira, J. Araújo, I. Brito, “Crosscutting Quality Attributes for Requirements Engineering”, 14th International Conference on Software Engineering and Knowledge Engineering (SEKE 2002), ACM Press, Italy, July 2002. [Nuseibeh and Finkelstein, 1992] B. Nuseibeh, A. Finkelstein, “Viewpoints: a Vehicle for Method and Tool Integration”, International Workshop on CASE (CASE 92), Montreal, Canada, 6-10 July 1992, pp.50-60.
A process model was presented whose original activities were adapted to contemplate aspects. The advantages that we can highlight from the combination of viewpoints, uses cases and aspects are a better modularisation, traceability and evolution of system models at early stages, facilitating the detection and resolution of conflicts. Moreover, aspectual artefacts, such as aspectual use cases, promote a homogeneous software development based on aspects. Furthermore, the approach integrates UML models in a very simple and efficient way, making it more attractive to the huge amount of developers that use UML.
[Nuseibeh et al., 1994] B. Nuseibeh, J. Kramer, A. Finkelstein, “A Framework for Expressing the Relationships between Multiple Views in Requirements Specifications, IEEE Transactions on Software Engineering, 20(10), 1994, pp. 760-773. [OMG, 2002] Object Management Group, Unified Modeling Language version 1.4, http://www.omg.org. [Rashid et al., 2002] A. Rashid, P. Sawyer, A. Moreira, J. Araújo, "Early Aspects: a Model for Aspect-Oriented Requirements Engineering", Requirements Engineering 2002 (RE'02), Essen, Germany, 9-13 September 2002.
For future work we want to apply the approach to more case studies and real systems. Also, we intend to develop a tool to support the approach. Finally, we would like to represent aspects in other UML models, to have a more complete approach.
[Rashid et al., 2003] A. Rashid, A. Moreira, J. Araújo, "Modularisation and Composition of Aspectual Requirements", AOSD 2003, Boston, USA, March 2003. [Sommerville et al., 1998] I. Sommerville, P. Sawyer, S. Viller, “Viewpoints for requirements elicitation: a practical approach”, International Conference on Requirements Engineering, 1998.
References [Araújo, 2002] J. Araújo, A. Moreira, I. Brito, A. Rashid, "Aspect-Oriented Requirements with UML", Workshop: Aspect-oriented Modelling with UML, UML 2002, Dresden, Germany, October 2002.
6
