Handling unanticipated requirements change with ... - Semantic Scholar

Handling unanticipated requirements change with aspects Ana Moreira and João Araújo Departamento de Informática, Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa, Quinta da Torre, 2829-516 Caparica, PORTUGAL {amm, ja}@di.fct.unl.pt Abstract. Supporting software evolution and maintenance are two of the major issues of aspect-oriented software development. This paper adds to aspect-orientation by proposing (i) a classification of concerns, (ii) volatile concerns to be kept separately and handled as candidate aspects independently of the crosscutting property, (iii) the use of adaptable use cases and activity diagrams to cope with generic model elements that facilitate the composition of concerns, (iv) the extension of the use case model to support our ideas.

1. Introduction Aspect-oriented software development aims at handling crosscutting concerns by proposing means to their systematic identification, modularisation and composition. Crosscutting concerns are properties whose implementation is scattered among several implementation modules, producing tangled systems that are hard to understand, difficult to maintain and hard to evolve. Our work is at the requirements engineering level and uses facilities available in aspect-orientation to increase support for unanticipated changes in requirements. Use cases, proposed by Jacobson [4] and later adopted by the UML [9], are a simple technique to structure the requirements of a system and to facilitate the communication with the stakeholders. 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 properly, even if the and relationships are a good starting point [5]. This paper has two main goals: to extend the use case model so that concerns that were not modularised (e.g. non-functional requirements) can now be handled separately; to promote software evolution by externalising at this early stage volatile concerns that can be handled as candidate aspects. By externalising volatile concerns, such as business rules, that need to change on client’s or market demands, we can build a stepping stone for further

management of unanticipated requirements change. In order to accomplish this we classify each concern, we keep volatile concerns separated and handle them as candidate aspects, we use adaptable use cases and activity diagrams to address generic model elements that facilitate the composition of concerns and, finally we extend the use case model to support our approach. In the remaining of this paper section 2 introduces our approach, section 3 applies the approach to an example, section 4 discusses related work and section 5 draws some conclusions, pointing directions for further investigation.

2. Aspects to support requirements evolution Figure 1 proposes a simple model to improve modularisation of a use case driven approach with consequent increase of software reuse and evolution. Elicit concern-oriented requirements

Integrate concerns with use cases

Identify & compose candidate aspects

List of concerns Table of classified concerns Template of concern description Map of concerns into use case model Use case packages & projections UC model with pattern specifications List of candidate aspects Composition rules Composed model

Figure 1. A model to promote requirements evolution

Task 1: Elicit concern-oriented requirements. The goal here is to produce a requirements document organized in terms of the major concerns1 that define the problem domain. Each concern refers to a feature that the future system needs to address to satisfy the stakeholders’ needs. After identifying and defining concerns we classify them according to its type that depends on two factors: (i) longevity, that can be enduring or volatile and (ii) conceptual nature, that can be services or constraints. Enduring concerns are “relatively stable requirements which derive from the core activity of the organization and which relate 1

A concern may be defined as a set of related requirements.

directly to the domain of the system” [8]. Volatile concerns “are likely to change during the system development or after the system has been put into operation” [8]. Constraints are properties that the system must satisfy. Services reflect functionalities that the system must offer. This information is collected in a bidimensional table where each cell contains the list of concerns that satisfy a combination of those two factors. Concerns are then described in more detail in a template such as the one depicted in Table 1. Table 1. Template describing a concern Concern # Name Interrelationships List of pre-conditions Pre-condition # < What we expect is already done> List of responsibilities Responsibility #

The row “Interrelationships” lists the concerns that a given concern relates to. A responsibility is an obligation to perform a task, or know certain information [11]. A required concern is a subset of the interrelationships’ list. Task 2: Integrate concerns with use cases. This task starts by mapping concerns into use cases (one to one), stakeholders into actors (stakeholders that directly use systems’ services are mapped into actors) and interrelationships (listed in each template) into relationships between use cases. A one-to-one mapping between concerns and use cases promotes, as we will show in Section 3, the early externalization of constraints and volatile business rules that would, otherwise, be spread throughout the original use cases, making the evolution harder. There are six kinds of relationships between concerns. Three of them are those used by the use case model [4]: , and . The remaining three are new ones: , and . While reflects a positive contribution of one concern to another, reflects a negative contribution. These two relationships are specific for global properties, i.e. nonfunctional concerns, and can be validated using the NFR catalogue [1]. Finally, says that a global property restricts another concern. The second step of this task, is concerned with handling complexity. As one concern is mapped into one use case, the resulting use case diagram is a too large diagram, even for a not so big system. One way of managing this problem is to project each global property on a use case diagram. The result of such a projection is a use case diagram with the global property connected with a

relationship with all the use cases that must satisfy it. The last step has two main goals: (1) promote concrete use cases to generic use cases; (2) describe each use case using an activity diagram with generic elements. Generic use cases can be defined in an abstract way and later be instantiated to a particular situation. A generic use case will be represented by a Use Case Pattern Specification (UCPS). Each element in a pattern specification is a role that is a UML meta-class specialized by additional properties that any element fulfilling the role must possess. Role names are preceded by “|”. (An UCPS is based on the idea of Pattern Specification [3].) Use case roles are concerns that are more likely to change over time, such as constraints and volatile services. The idea is that such concerns, in the end, will be instantiated differently for particular configurations of a system. We can apply the same idea to relationships and have relationship roles that can be later instantiated. The instantiation is given by a rule of the form: Replace | with

Use cases can be described in more detail using activity diagrams. We propose a generalization of the activity diagrams to include element roles. We call these Activity Pattern Specifications (APSs). Use case roles, therefore, should be described using APSs. Task 3: Identify and compose candidate aspects. Candidate aspects2 handle crosscutting concerns and promote software evolution by externalising volatile concerns that are typically conditions, business rules and constraints. A crosscutting concern is one that is required by several concerns. (Or, it is a use case that is related to more than one use case.) However, we propose that all constraints and volatile services should be considered as good candidate aspects, independently of being crosscutting or not. Composing use cases with candidate aspects gives the developer a possibility to understand the full picture. Composition rules are defined to weave service use cases with both constraint and volatile use cases specified with activity diagrams or APSs. A composition rule consists of a set of instantiation steps, where APS elements are replaced with concrete elements or other APS elements. It takes the form: Compose with { Replace | with [] | } 2

The term “candidate aspect” was defined in [7].

Where “[]” represents the choice operator and “|” denotes that the model element is a role.

3. A subway system example This section illustrates the approach described in the previous section by means of an example based on the Washington subway system, described below: “To use the subway, a client uses a card that must have been credited with some amount of money. A card is bought and credited in buying machines available in subway stations. The card is used in an entering machine to initiate a trip. When the destination is reached, the card is used in an exit machine that debits it with an amount that depends on the zones travelled. If the card has not enough credit the gate will not open. During periods of low usage (e.g., weekends), special package promotions are offered.”

3.1 Elicit concern-oriented requirements List concerns. By analysing the requirements described above, we discovered concerns C1-C7 listed in Table 2. Additionally response-time, availability and multi-access are intrinsic properties in this type of systems. In particular, response time is needed as the system needs to react in a short amount of time to avoid delaying passengers; availability is needed as the system must be available when the subway is open; multi-access is needed so that several passengers can use the system concurrently; Concerns C8-C10 express these properties as concerns. Table 2. List of concerns for the subway system Concern # Concern description C1 A client buys a card in a buying machine C2 A client must own a valid card C3 Clients credit cards with minimum amounts of money in buying machines C4 A client enters a subway station using a card in an entry machine C5 A client leaves the subway station using his card in an exit machine that debits it according to the zones travelled C6 An exit machine will not open its gate for cards without enough balance to pay the trip C7 Special package promotions are offered during periods of low usage C8 The system is used for several passengers simultaneously C9 The system needs to react in time to avoid delaying passengers while they are entering or leaving the subway, or crediting their cards C10 The system must be available for use

The number of concerns identified depends on the level of granularity used to look at the system. For example, instead of C1-C7 we could have one concern to handle each machine (entry machine, exit machine and buying machine). Classify concerns. Each concern in Table 2 is classified according to characteristics defined in Table 3. Table 3. Concerns classification of the system Enduring Volatile C7 Services C1, C3, C4, C5 C3, C5, C6 Constraints C2, C8, C9, C10

Constraints impose conditions on services. For example, constraint C6 is a pre-condition on service C5; C2 is a pre-condition on services C3, C4 and C5. Constraint C9 is a global property that C1-C7 must satisfy. Note that C3 and C5 appear in two cells of the table, being classified both as enduring services and volatile constraints. This means that they should be divided into two separate concerns. From C3 we can derive: • C3A Clients credit cards in buying machines • C3B Cards are credited with a minimum amount Similarly, for C5 we have: • C5A A client leaves the subway station using his card in an exit machine that debits it • C5B Exit machines calculate amount to debit cards according to the zones travelled C3A and C5A are enduring services and C3B and C5B are volatile constraints. For example, C5B is volatile because we can change the way prices are calculated (e.g. fixed prices). Describe concerns. Each concern is described using the template presented in Section 2, Task 1 (see Table 4). Table 4. Template for “Exit subway” Concern # C5A Concern name Exit subway Interrelationships C2, C5B, C7, C8-C10 List of pre-conditions Pre-condition 1 Card is valid List of responsibilities R1 Calculate amount to be paid C5B, C7 R2 Check balance C6 R3 Debit card R4 Register end of trip R5 Let client leave

Notice that while some concerns from the interrelationships list are required by particular responsibilities, C8-C10 affect the whole concern. Also, precondition 1 is a C2 responsibility.

3.2 Integrate concerns with use cases Map concerns into a use case model. Figure 2 depicts the use case model. Each concern was mapped into one use case. The stakeholders Client and ClientCard were mapped onto actors. Some of the relationships between use cases were identified based on the interrelationship list of each concern. Examples of each type of relationship are: is used to relate ValidateCard with CreditCard, EnterSubway and ExitSubway; is used to extend the original use case CalculateAmount with Promotion. is defined between C8C10 and all the other use cases; C8-C10 are related between them with and relationships (this information was taken from the catalogue offered by the NFR framework [1]). We could, complement the template of the concern with this information by adding the name of the relationship between brackets after the name of the concern in the interrelationship row. Handling complexity. In complex situations where different global properties affect different subsets of use cases, we use the projections as described in Task 2 of Section 2. Figure 2 illustrates this for Availability. WeekendPromotion

MinimumAmount

CalculateAmount



Buy card

HasBalance

ExitSubway

Client

ClientCard

Availability





CreditCard

Ent erSubway ValidateCard

Figure 2. Projecting Availability on a set of use cases

Describe use cases with pattern specifications. A use case model is made generic by “marking” the use cases that are more likely to change as use case roles. For example, “Promotion” is a good example of a use case role, as special prices can be defined for weekends, bank holidays, seasonal periods, handicap users. It should then be preceded with “|” in the use case model. The resulting use case model is called UCPS. Later, during composition, “|Promotion” can be instantiated to “Weekend Promotion”, for example, through the rule: Replace |Promotion with WeekendPromotion

Figure 3 shows APSs for ExitSubway and ValidateCard. |ValidateCard

|CalculateAmount

|HasBalance

InsertCard

DebitCard

ReadCard

RegisterTrip

CheckCard [ Card NOK ]

OpenGate [ Card OK ]

EjectCard

|ContinueExit

|HandleError

|Terminate

TakeCard

a)

b)

Figure 3. a) Exit subway; b) Validate Card

3.3 Identify and compose candidate aspects List candidate aspects. The use cases ResponseTime, Multi-access, Availability, CalculateAmount and ValidateCard are crosscutting and so, are candidate aspects. One of the contributions of this paper is that candidate aspects do not have to be crosscutting. Examples are Promotion, HasBalance and MinimumAmount. Since these are volatile business rules that can change according to the market needs, modularise them and handle them as candidate aspects promotes software evolution, since aspects are more easily enabled and disabled from a system than a class, for example. Define composition rules. All concerns need to be composed so that the developer gets a full picture of the system. Composition will be accomplished by replacing role elements of one APS with concrete or role elements from another model. Below there is a simple composition rule for ExitSubway and ValidateCard: Compose ExitSubway with ValidateCard 1. Replace |ValidateCard with InsertCard 2. Replace |ContinueExit with |CalculateAmount 3. Replace |Terminate with EjectCard

The APS resulting from this composition is illustrated in Figure 4.

5. Conclusions and Future Work InsertCard

ReadCard

CheckCard [ Card NOK ]

|HandleError

[ Card OK ]

|HasBalance

DebitCard

|CalculateAmount

RegisterTrip

OpenGate

EjectCard

TakeCard

Figure 4. Diagram resulting from (partial) composition

To obtain the full view of ExitSubway, we need to compose it with all the use cases that are in any way related to this. This information is in the interrelationships row of its template description.

4. Related work An aspect-oriented requirements model was proposed in [11]. Jacobson [5] agrees that use case extensions are a way to handle aspects during requirements and uses SDL to demonstrate that. However, his work is not on the aspect-oriented software development context and gives no systematic process to handle evolution through constraints and volatile services. Our pattern specifications are based on the work of [3, 10]. [3] defines an aspect through role models to be composed into UML diagrams. However, the approach only handles role models and does not allow concrete elements in those models, which decreases the amount of instantiations required. Concrete modeling elements are dicussed in [10] for sequence diagrams. Our only similarity with this work is the structure of the composition rules and the use of concrete elements in the APSs. Clarke and Walker [2] define aspects using UML templates, but at design level. Also, they are concerned with how to specify the aspects rather than composing aspects with non-aspectual models. In [6] an extension of use case modelling to handle evolution through coordination contracts is proposed. The work we present here differs not only on the level of abstraction and the use of aspects, but also the focus on concerns and composition rules.

This paper complements our previous results in the area of aspect-oriented requirements engineering with four main innovations: a classification of concerns into services and constraints, and each one into enduring and volatile; an extension of pattern specification for activity diagrams to define role elements in a model that can be later instantiated; the externalization, i.e. modularisation, of constraints and volatile services that reflect business rules that are important in the organization; the integration of the notions above with use cases, in the context of aspect-oriented requirements engineering. For future work we will investigate how (1) to handle possible conflicts resulting from composing APSs of concerns that have a relationship between them; (2) to address conflicting emergent behavior that may appear when two or more candidate aspects are allowed to co-exist; (3) to extend this approach to the modeling and design activities; (4) to develop a tool that supports the identification of concerns, their specification and composition.

References [1] L. Chung, B. Nixon, E. Yu, J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000. [2] S. Clarke and R. J. Walker, “Composition Patterns: An Approach to Designing Reusable Aspects”, 23rd International Conference on Software Engineering (ICSE), 2001. [3] G. Georg, I. Ray, R. France, “Using Aspects to Design a Secure System”, 8th IEEE International Conference on Engineering of Complex Computer Systems, Maryland, USA, December, 2002. [4] I. Jacobson, Object-Oriented Software Engineering – a Use Case Driven Approach, Addison-Wesley, Reading Massachusetts, 1992. [5] I. Jacobson, “Aspects: the Missing Link”, Software Development, November 2003. [6] A. Moreira, J. Fiadeiro, L. Andrade, “Evolving Requirements through Coordination Contracts”, 15th International Conference CAiSE’2003, Springer-Verlag, pp. 633-646. [7] A. Rashid, A. Moreira, J. Araújo, “Modularisation and Composition of Aspectual Requirements”, 2nd International Conference on Aspect-Oriented Software Development, ACM Press, 2003, pp. 11-20. [8] I. Sommerville, Software Engineering, Addison-Wesley, 6th edition, 2001. [9] Unified Modeling Language Specification, version 2.0, January 2004, in OMG, http://www.omg.org [10] J. Whittle, J. Araújo, “Scenario Modeling with Aspects”, IEE Proceedings Software. Under review. [11] R. Wirfs-Brock, B. Wilkerson, L. Wiener, Designing Object-Oriented Software, Prentice-Hall, 1999.