The case study we chose is based on the Washington subway sys- tem: âTo use the subway, a client has to own a card that must have been credited with.
An Aspectual Use-Case Driven Approach João Araújo and Ana Moreira Departamento de Informática, Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa, Quinta da Torre, 2829-516 Caparica, PORTUGAL {ja,amm}@di.fct.unl.pt Abstract. Existing approaches to software development do not handle properly the crosscutting nature of some requirements, be functional or non-functional. Aspect-oriented approaches aim at handling effectively separation of crosscutting requirements. We have been investigating how to achieve separation of concerns, not only through functional and non-functional requirements, but also by providing mechanisms to identify, modularize, specify and compose crosscutting requirements. In this paper we envisage an aspectual use-case driven approach by extending the use case model to integrate non-functional requirements and identifying those use cases that are crosscutting. The examples of crosscutting concerns usually found in the literature are always non-functional. In this work we will explore the idea of crosscutting use cases and, therefore, functional concerns.
1 Introduction Use cases were first proposed by Jacobson [4] and later embraced by most of the object-oriented methods. Developers find it an easy technique to structure the requirements of a system and to facilitate the communication with the stakeholders. (A stakeholder is any person that has some direct or indirect influence on the system [8].) However, use cases are only used to define functional requirements, leaving out global properties (such as response time, availability and compatibility) that affect the whole or part of the system. Furthermore, the crosscutting nature of some requirements (functional and non-functional) is not handled. This limitation can lead to tangled representations in requirements documents that are difficult to maintain and keep consistent. The NFR framework focus is on non-functional requirements [1]. It does not explicitly deal with functional concerns, but establishes a link to them. Nevertheless, it ignores the crosscutting nature of those requirements. There are approaches that integrate functional and non-functional concerns [2, 9], but, again, the crosscutting nature of those concerns is not addressed. Aspect-oriented software development aims at handling crosscutting concerns by proposing means to their systematic identification, specification and implementation. There are not many aspect-oriented requirements approaches. Grundy [3] proposes an aspect-oriented requirements approach targeted to component-based development. 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 [7] based on viewpoints that was extended with com-
position rules specified in XML and a tool to validate them [6]. Also, we have attempted to bring into the UML some of the aspect-oriented main concepts. In [5], separation of crosscutting concerns at the requirements level is achieved by identifying and specifying quality attributes and functional requirements. In the present paper, we envisage an aspectual use-case driven approach by extending the use case model to integrate non-functional requirements and identifying those use cases and NFRs that are crosscutting. Also, we discuss the need to handle the complexity of resulting compositions of crosscutting concerns, be NFRs or use cases, with non-crosscutting use cases. The standard examples of crosscutting concerns found in the literature are always non-functional. In this work we will explore the idea of functional crosscutting concerns. This work is organized as follows. Section 2 presents the approach. Section 3 illustrates our ideas by means of a case study. Section 4 draws some conclusions and points to directions of future work.
2 Extending the Use Case Model with Aspects An iterative and incremental set of steps to identify aspectual use cases is depicted in Figure 1. Our goal is to extend the use case model so that non-functional requirements are addressed and to refine some use cases to externalize functionalities that crosscut several other use cases. Actors Use cases UC model Relationship Relationship
Identify & define Functional Req. Refine the UC model
NFR templates
Identify & define NFRs
UC Relationship
Integrate NFRs in UC model
Refined UC model Candidate aspects Identify candidate aspects
Fig. 1. Aspectual use case-driven approach
We start by inspecting the requirements to identify and define actors and use cases and build an initial use case model. Actors are defined by an executive summary of their roles. Use cases are commonly defined using primary and alternative scenarios. The second step refines use cases to promote the externalization of functionalities that are spread throughout the original use cases. This will be realized by using the existing and relationships between use cases. The third step
identifies and defines NFRs by analyzing the elicited requirements and any other information obtained from enquiring the system’s stakeholders. Each non-functional requirement is described in a template, with a name, a short description, and a list of requirements. The fourth step handles the integration of NFRs. This is achieved by extending the use case model with the new stereotyped relationship that links functional use cases to a new stereotyped use case for each nonfunctional requirement identified. Finally, the fifth step identifies candidate aspects1. In situations where a use case is related to more than one use case then that use case is good candidate aspect. A use case is crosscutting if it constrains, extends or is included by more than one use case. A well-known problem when using a use case approach is the explosion of the number of use cases identified, even in small projects. Adding a new use case for each NFR to the diagram, as we propose in step 4, augments this problem. One possible solution is to build different use case diagrams, each one showing the result of projecting a NFR to the use cases that it affects. Each of these diagrams will show only the use cases directly involved in the projection together with the ones related to them.
3 Aspectual Use Cases: a Case Study This section illustrates how aspectual use cases can be identified from a set of informal requirements. The case study we chose is based on the Washington subway system: “To use the subway, a client has to own a card that must have been credited with some amount of money. A card is bought and credited in special buying machines available in any subway station. This card is then used by its owner in an entering machine to initiate her/his trip. When s/he reaches the destination, the card is used in an exit machine that debits it with an amount that depends on the distance traveled. If the card has not enough credit the gates will not open unless the client credits its card. To encourage the use of the system during periods of low traffic (e.g., weekends), special package promotions are offered to allow cheaper trips.” Identify and define actors and use cases. The actors identified are Client and ClientCard. Client triggers the use cases BuyCard and CreditCard, while ClientCard triggers EnterSubway and ExitSubway. Refine the use case model. The use case model is refined by identifying generalizations, extensions and inclusions of the use cases. In our case, we can externalize the two functionalities ValidateCard and DebitCard to be associated, using the relationship, to the original use cases CreditCard, EnterSubway and ExitSubway. The functionality WeekendPromotion can be externalized as well 1 The term candidate aspect was coined in [7], to name those requirements that are crosscutting. They are candidate because they will not necessarily be mapped into an aspect in later stages of the software development.
and then associated using the relationship to the original use cases DebitCard and BuyCard (see Figure 2).
BuyCard
Debit Card
WeekendPromotion
ExitSubway
Client ValidateCard CreditCard
EnterSubway
ClientCard
Fig. 2. Refined use case diagram for the subway system
Identify NFRs. We have identified five NFRs: (i) response time, as the system needs to react in a short amount of time to avoid delaying passengers; (ii) accuracy, only right amounts should be debited from, or credited to a card; (iii) multi-access, so that several passengers can use the system concurrently; (iv) availability, as the system must be available when the subway is open; (v) legal issues, what legal actions should be taken to unauthorized clients. Each NFR should be described using the template introduced in Section 2. Integrate NFRs in the use case model. The integration of NFRs with the use cases is achieved by projecting each NFR on the use case diagram depicted in figure 2. In this context, the result of the projection is a use case diagram with the NFR connected with a relationship with all the use cases it constrains. Figure 3 shows this for ResponseTime. WeekendPromotion
BuyCard
DebitCard
ExitSubway
Client
Resp onseTi me
CreditCard
ClientCard
ValidateCard
EnterSubway
Fig. 3. Projecting response time on the use case diagram
Identify candidate aspects. The use cases ResponseTime, WeekendPromotion, and ValidateCard are crosscutting and, therefore, are candidate aspects. Observe that, while ResponseTime is a non-functional use case, WeekendPromotion and ValidateCard are functional use cases. Therefore, we have identified two func-
tional use cases that are good candidate aspects. Notice that DebitCard is not crosscutting, as it is only used by ExitSubway.
4 Conclusions and Future Work This paper presented an aspectual use-case driven approach that extends the use case model to include non-functional requirements and to handle crosscutting use cases. The advantages are (i) a better modularization of requirements, which facilitates system’s evolution, by increasing understandability and maintainability, and (ii) an encouragement of homogenous development using aspectual concepts from requirements to implementation. Standard examples of crosscutting concerns found in the literature are always non-functional. In this paper we have explored the idea of functional crosscutting concerns. There are a few problems in the proposed approach that we plan to tackle in the near future. Building diagrams for projections of NFRs will help managing complexity. However, we need to extend this idea to the situation where a NFR is related to other NFRs by a composition relationship, or by positive and negative contributions. This may not be enough as it may well be that a NFR can crosscut others. Additionally, we want to extend these ideas to consider the externalization of volatile business rules. An interesting task we are now planning to do is the definition of a language to formally express the composition of crosscutting concerns with non-crosscutting ones. The projections used here to handle complexity will have their semantics defined by means of a composition rule.
References 1. Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000 2. Dardenne, A., Lamsweerde, A., Fickas, S.: “Goal-directed Requirements Acquisition”, Science of Computer Programming, Vol. 20, No., 1993, pp. 3-50 3. Grundy, J.: “Aspect-Oriented Requirements Engineering for Component-based Software Systems”, 4th IEEE International Symposium on RE, 1999, IEEE Computer Society Press, pp. 84-91 4. Jacobson, I.: Object-Oriented Software Engineering – a Use Case Driven Approach, Addison-Wesley, Reading Massachusetts, 1992 5. 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, 2002 6. Rashid, A., Moreira, A., Araújo, J.: “Modularisation and Composition of Aspectual Requirements”, 2nd International Conference on Aspect-Oriented Software Development, ACM Press, 2003, pp. 11-20 7. Rashid, A., Sawyer, P., Moreira, A., Araújo, J.: “Early Aspects: A Model for AspectOriented Requirements Engineering”, IEEE Joint International Conference on Requirements Engineering, IEEE CS Press, 2002, pp. 199-202 8. Sommerville, I.: Software Engineering, Addison-Wesley, 6th edition, 2001 9. Yu, E.: “Modelling Strategic Relationships for Process Reengineering”: PhD Thesis, University of Toronto, 1995
