An Aspectual Use-Case Driven Approach

An Aspectual Use-Case Driven ApproachJoão Araújo and Ana MoreiraDepartamento 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.ptAbstract. Existing approaches to software development do not handle properlythe crosscutting nature of some requirements, be functional or non-functional.Aspect-oriented approaches aim at handling effectively separation of crosscut-ting requirements. We have been investigating how to achieve separation ofconcerns, not only through functional and non-functional requirements, but alsoby providing mechanisms to identify, modularize, specify and compose cross-cutting requirements. In this paper we envisage an aspectual use-case drivenapproach by extending the use case model to integrate non-functional require-ments and identifying those use cases that are crosscutting. The examples ofcrosscutting 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 IntroductionUse 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 re-quirements 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 require-ments (functional and non-functional) is not handled. This limitation can lead to tan-gled 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 ex-plicitly deal with functional concerns, but establishes a link to them. Nevertheless, it ignores the crosscutting nature of those requirements. There are approaches that inte-grate 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 at-tempted 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 identify-ing and specifying quality attributes and functional requirements.In the present paper, we envisage an aspectual use-case driven approach by ex-tending 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 con-cerns 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 illus-trates 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 AspectsAn 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 require-ments are addressed and to refine some use cases to externalize functionalities that crosscut several other use cases.Fig. 1.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 exist-ing <<include>> and <<extend>> relationships between use cases. The third stepidentifies 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 <<constrain>> that links functional use cases to a new stereotyped use case <<NFR>> for each non-functional 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 in-cluded 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 possi-ble 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 StudyThis section illustrates how aspectual use cases can be identified from a set of infor-mal requirements. 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 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 generaliza-tions, extensions and inclusions of the use cases. In our case, we can externalize the two functionalities ValidateCard and DebitCard to be associated, using the <<include>> 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 de-velopment.and then associated using the <<extend>> relationship to the original use cases DebitCard and BuyCard (see Figure 2).ClientCardEnterSubwayFig. 2. Refined use case diagram for the subway systemIdentify 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 <<constrain>> relationship with all the use cases it constrains. Figure 3 shows this for ResponseTime.ValidateCardFig. 3. Projecting response time on the use case diagramIdentify 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 cross-cutting, as it is only used by ExitSubway.4 Conclusions and Future WorkThis 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 sys-tem’s evolution, by increasing understandability and maintainability, and (ii) an en-couragement of homogenous development using aspectual concepts from require-ments to implementation. Standard examples of crosscutting concerns found in the literature are always non-functional. In this paper we have explored the idea of func-tional 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 complex-ity. 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. Addition-ally, 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 de-fined by means of a composition rule.References1. Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-Functional Requirements in SoftwareEngineering, Kluwer Academic Publishers, 20002. Dardenne, A., Lamsweerde, A., Fickas, S.: “Goal-directed Requirements Acquisition”,Science of Computer Programming, Vol. 20, No., 1993, pp. 3-503. Grundy, J.: “Aspect-Oriented Requirements Engineering for Component-based SoftwareSystems”, 4th IEEE International Symposium on RE, 1999, IEEE Computer Society Press, pp. 84-914. Jacobson, I.: Object-Oriented Software Engineering – a Use Case Driven Approach, Addi-son-Wesley, Reading Massachusetts, 19925. Moreira, A., Araújo, J., Brito, I.: “Crosscutting Quality Attributes for Requirements Engi-neering”, 14th International Conference on Software Engineering and Knowledge Engineering (SEKE 2002), ACM Press, Italy, 20026. Rashid, A., Moreira, A., Araújo, J.: “Modularisation and Composition of Aspectual Re-quirements”, 2nd International Conference on Aspect-Oriented Software Development, ACM Press, 2003, pp. 11-207. Rashid, A., Sawyer, P., Moreira, A., Araújo, J.: “Early Aspects: A Model for Aspect-Oriented Requirements Engineering”, IEEE Joint International Conference on Requirements Engineering, IEEE CS Press, 2002, pp. 199-2028. Sommerville, I.: Software Engineering, Addison-Wesley, 6th edition, 20019. Yu, E.: “Modelling Strategic Relationships for Process Reengineering”: PhD Thesis, Uni-versity of Toronto, 1995。