A Comprehensive Aspect-Oriented Use Case ... - Drexel University

A Comprehensive Aspect-Oriented Use Case Method for Modeling Complex Business Requirements Caimei Lu and Il-Yeol Song College of Information Science and Technology, Drexel University Philadelphia, PA 19104, USA {Caimei.lu,song}@drexel.edu

Abstract. The aspect-oriented approach separates cross-cutting concerns and models them as aspects. In this paper, we present a comprehensive aspectoriented use case approach for modeling complex business requirements. We identify four categories of aspects: high level non-functional requirements, extending or optional requirements, included or subordinate requirements, and business rules. Our aspect-oriented use-case model comprises three different templates: base use cases, aspectual use cases, and nonfunctional aspects. The proposed method offers a systematic approach for identifying different potential aspects from complex business requirements. Moreover, our method provides a comprehensive model for documenting identified aspects and their composition to the core functionalities at an early stage of software development. The contributions of our paper include identifying and utilizing the four types of aspects and proposing the templates to document them. Keywords: Early Aspects, Aspect-oriented modeling, Aspect-oriented system development, aspect-oriented use case method, Aspect template.

1 Introduction The aspect-oriented paradigm has been proposed to address the cross-cutting concerns or requirements that cannot be cleanly encapsulated in a single class. The notion of “Aspect” was first proposed in the context of Aspect-Oriented Programming (AOP) [4], which refers to the “property for which the implementation cannot be cleanly encapsulated in a generalized procedure”. Recently, various aspect-oriented analysis and design approaches have been proposed to identifying, modeling, and representing “aspects” at earlier stages of software development. This paper focuses on how to identify and model aspects at the requirement engineering stage. We extend the use case approach with aspects to address both functional and non-functional requirements. Here, aspects are defined as the requirements cross-cutting multiple use cases. Addressing cross-cutting concerns at the use case level allows us to detect and resolve conflicts at an early stage. Thereby, the codelevel conflicts caused by cross-cutting concerns could be addressed much earlier before the implementation stage. In this paper, we propose four categories of aspects existing in complex business requirements: non-functional requirements (NFRs), extending or optional requirements, I.-Y. Song et al. (Eds.): ER Workshops 2008, LNCS 5232, pp. 133–143, 2008. © Springer-Verlag Berlin Heidelberg 2008

134

C. Lu and I.-Y. Song

included or subordinate requirements, and business rules. We first propose a comprehensive aspect-oriented use case method that models all these four categories of aspects from the core applications at the early stage of system development. We then present how to document our approach using three different types of templates. Many approaches have been proposed for modeling aspects and composing them with the base model at the requirements level. They include the scenario-based approach, the goal-oriented approach, the component-based approach, the multidimensional concern modeling approach, and the theme/doc approach. Our paper belongs to the approach that adapts use cases for modeling aspects. Araújo and Rashid et al. attempt to incorporate aspects into UML elements [1, 2, 5]. The authors propose a general model for aspect-oriented requirements engineering, which includes three main parts: identifying cross-cutting concerns, specifying functional concerns, and composing requirements. In [2], Araújo et al. refine the process model to combine viewpoints, use cases, and aspects. Here, the aspects are identified from two sources: (1) NFRs that cross-cut a number of use cases and (2) aspectual use cases—use cases that extend or are included by more than one use case. Jacobson and Ng [3] propose an approach called the aspect-oriented software development with use cases. This approach identifies and represents aspects with use cases. They view uses cases as cross-cutting concerns in that the realization of each use case cut across many classes. Accordingly, they point out that “when you identify use cases, you are indeed identifying aspects.” In our paper, however, we adopt the definition of aspects used by Araujo [1, 2, 5] in that a requirement is viewed as an aspect only when it cross-cuts more than one base use case. Another feature that differentiates the use case model proposed by Jacobson and Ng from the traditional use case model is that NFRs are separately represented with so-called infrastructure use cases. An infrastructure use case is a construct dealing with system activities needed to meet system-wide infrastructure concerns. Our model is based on Jacobson and Ng’s research [3] and Araujo et al.’s research [1, 2]. Following Jacobson and Ng, we introduce AOP concepts such as “join points” and “pointcuts” used to compose aspects into base use cases. Following Araujo et al.’s method, we specify that NFRs, extending requirements, or included requirements are viewed as aspects only when they cross-cut more than one base use case. However, the use case model proposed here is different from either of theirs. Our method is different from Jacobson and Ng’s method in the following three points: • Our use case model is based on a different definition of aspects at the requirements level. While Jacobson and Ng employ the three types of aspects: NFRs, peers, and extensions, we adopt the four types aspects: NFRs, extending requirements, included requirements, and business rules. A peer is an independent requirement that can be used separately with no reference to each other. Thus, we do not consider “peers” as aspects, because peer use cases are independent of each other at the requirements level. The entanglement between peers only appears until the design stage when the class diagram is used for realizing different peer use cases. • While Jacobson and Ng represent high level NFRs using low-level infrastructure use cases, we represent them with a special NFR template. We consider it is improper to identify these low-level infrastructure use cases at the requirement level, because behaviors described by these use cases are invisible to the user, and there

A Comprehensive Aspect-Oriented Use Case Method

135

is no action involved from the user’s side in these infrastructure use cases. Therefore, we use a high-level template to describe the nonfunctional aspects. • Jacobson and Ng treat all extensions as aspects, even if an extension is related with only one base use case. This view violates our definition of the aspect. In this paper, we treat an extending requirement as an aspect only when it cross-cuts more than one base use case. Our aspect-oriented use case method extends the method by Araujo et al. in the following three points: • They consider only three types of cross-cutting aspects: NFRs, extending requirements, and included requirements. We also consider cross-cutting business rules as the 4th kind of aspects. • We proposed new and specific templates for modeling aspectual use cases. • We define join points in the base use cases and pointcuts in aspectual use cases to facilitate the composition between base use cases and aspectual use cases. Thus, the contributions of our paper include classifying aspects into four categories, proposing the templates to model them, and proposing a method of composing aspects into base use cases. The rest of this paper is organized as follows: Section 2 introduces the integrated use case method for modeling the four types of aspects. Section 3 provides a case study to illustrate the proposed method. Finally, we conclude our work in Section 4.

2 The Framework of Aspect-Oriented Use Case Modeling In this section, we introduce the framework of our aspect-oriented use case modeling method. Fig. 1 shows the process model of the aspect-oriented use case method. Business Requirements Identify Non-functional Requirements

Crosscutting?

Specify Functional Requirements

Optional Functional Requirements

Yes

Subordinate Functional Requirements

Business Rules

Base Use cases

Crosscutting?

Template of Nonfunctional Aspects

Yes

Core Functionalities

Compose to

Aspectual Use Cases Compose to

Fig. 1. The Process Model of an Aspect-oriented Use Case Method

136

C. Lu and I.-Y. Song

2.1 Specify Functional Requirements Most expressed business requirements are functional requirements which define what the system should do. From the functional requirements we can further identify the core functionalities which define the primary flow of the system process. Besides the core functionality, we can identify other three categories of functional requirements which are the sources of aspects. The first category is optional requirements, which describe the alternative or extending flows of the primary flow under a special condition. An example is to create a back order when the ordered item is not available. The second category is subordinate functional requirements. Subordinate functional requirements are usually represented with inclusion use cases. For example, process credit card may be an included use case of a base use case called place order. The third category is business rules. Business rules are very changeable, so it is beneficial to model them separately without invasively influencing the core applications. Business rules are usually domain-specific. There are some common models of business rules across different applications, such as price personalization. If these common models can be represented with aspects, they could be plugged in and out of the application and reused across different applications. 2.2 Identify Non-functional Requirements Complex business requirements include not only requirements directly related to the functionality of the system, but also some NFRs which constrain the functionality of the system. NFRs are usually system-wide quality concerns described as declarative statement such as performance, security, response time, reliability, etc. NFRs are widely-accepted aspects. 2.3 Build Base Use Cases Base use cases model the core functionalities of the system. The template of our base use cases is shown in Fig. 1. It is different from typical UML use case template in three respects. First, the proposed template incorporates an additional component called “Join points” to identify the points where aspectual use cases are composed to the base use case (see Table 1). The concept of the join point is from AspectJ, in which it indicates an execution point where additional behaviors will run [1]. Each join point has a unique label which will be refereed by aspectual use cases. The “Position” states before or after or within which specific step of the primary flow the join point is located. Second, the proposed template of a base use case defines a component called “Nonfunctional Aspects”, which list all the cross-cutting NFRs that affect the current base use case. Third, the “Special Requirements” component defined in the proposed template merely includes NFRs or business rules which are not cross-cutting and only affect current base use case. The proposed template of base use case also include “Extension Use Cases” and “Inclusion Use Cases” components, which list use cases modeling non-cross-cutting optional requirements and subordinate requirements associated

A Comprehensive Aspect-Oriented Use Case Method

137

Table 1. The Template for the Base Use Case USE CASE Name ACTOR Goal Level Trigger The Primary Flow in numbered sequence Extension Use Cases Inclusion Use Cases Special Requirements Nonfunctional Aspects Join Points

Base > Actor Action System Action

Label Position JP1 JP2 …

with current base use case. Note that when a base use cases are initially built, the components of “Nonfunctional Aspects” and “Join Points” are left unfilled, because we can not tell what NFRs, or functional aspects are connected to the base use case until the nonfunctional aspect template and aspectual use cases are built. So these two important components are filled while the nonfunctional aspect templates and aspectual use cases are developed. 2.4 Identify and Create Functional Aspectual Use Cases After all optional functional requirements, subordinate functional requirements, and business rules are analyzed from the business requirements, their relationships to the base use cases are examined. Those requirements conforming to any of the following three conditions are modeled as aspectual use cases: • Optional requirements which extend more than one base use case • Subordinate requirements which are included by more than one use case • Business rules which affect more than one use case Those requirements that do not conform to the above three conditions are modeled in the traditional way: optional requirements are modeled with the extension use cases; subordinate requirements are modeled with inclusion use cases; business rules are modeled as special requirements of the corresponding base use case. Table 2 shows the template of an aspectual use case. The level of the use case is Aspect, and the type of the use case is either extension, inclusion, or business rule. In correspondence to the join points defined in base use cases, we define “Pointcut” and “Advice” in aspectual use cases. Each pointcut corresponds to a set of join points (at least two since each aspectual use case is composed to more than one base use case). Each pointcut has a label as its unique identifier. Each corresponding join point is referred through the combination of the name of the base use case, in which the join point is defined, and the label of the join point. Advice describes the additional flow composed to the base use case at each join point of the pointcut.

138

C. Lu and I.-Y. Song

2.5 Identify and Model Non-functional Aspects NFRs always deal with system-wide quality concerns such as performance and reliability and always work in the background of the system. Therefore, they cannot be modeled directly with use cases. Following the method of [1, 2, 6], we use a special template to describe the nonfunctional aspects, as shown in Table 3. However, not all NFRs are modeled with the nonfunctional aspect template. After identifying all the NFRs, we first check their associations with the base use cases. If a nonfunctional requirement affects more than one use case, it is modeled with the non-functional aspect template; otherwise, it is only listed as a special requirement in the base use case it affects. In Table 3, the “Influence” line lists all the base use cases affected or cross-cut by the current non-functional aspect. The relations of the current nonfunctional aspect to other non-functional aspects are also specified to help designers understand the constraints and trade-off among different cross-cutting NFRs. Table 2. Template for Aspectual Use Case USE CASE Name

Table 3. Template for Non-functional Aspect NFR Name Goal

ACTOR

Overview

Goal

Influence

Level

Aspect

Type

( Extension | Inclusion | Business Rule )

Condition Advice

Actor Action

System Action

Pointcut

Label

Corresponding Join Points

Relations to other Nonfunctional Aspects

Priority

> Positive Negative



>

3 A Case Study In this section, we use a case study of Subscription Automation System (SAS) to illustrate the Aspect-oriented use case method presented in Section 2. The requirements of SAS are stated as follows: The SAS is built for a monthly magazine called HOST (Hot Software Technologies) published by a company. HOST is sold on a subscription basis. The subscription process is Web-enabled. Most subscriptions are for a one year period. If individuals subscribe for multiple-years, they receive a 10% discount for each year up to three years. Subscriptions can come by mail, phone, or the Web. The Web subscription requires the use of a credit card for payment, while other subscription could be paid for by a check or a credit card. When subscribing through Web, one can also check the subscription status or renew. The termination of a subscription, however, cannot be done via Web. The termination must be initiated by the customer via a phone, fax, or a written request and must be processed by a staff member. For each subscription and cancellation, a confirmation notice is sent via email to the subscriber. Some

A Comprehensive Aspect-Oriented Use Case Method

139

subscribers live in foreign countries and issues need to be mailed to the foreign countries with a proper mailing charge. The current foreign postal charge is $25 per year. The company also offers free subscriptions. If the subscriber is the author of articles or the member of the editorial board, the subscription to the HOST is free. When the customer subscribes through the Web, the response time for all checking and displays should be within 5 seconds. 3.1 Specify Functional Requirements First, we identify the core functional requirements of the system. We then specify the optional requirements, subordinate requirements, and business rules contained in the functional requirements. The core functionality of the system is represented in the use case diagram of Fig. 2(a). Other functional requirements are listed as follows: • Optional requirements: − OR1: If the subscriber is the author of articles or the member of the editorial board, the subscription to the HOST is free. • Subordinate Requirements: − SR1: The web subscription requires the use of a credit card for payment, while other subscription could be paid for by a check or credit card. − SR2: For each subscription and cancellation, a confirmation notice is sent via email to the subscriber. • Business Rules: − BR1: If individuals subscribe for multiple-years, they receive a 10% discount for each year up to three years. − BR2: Subscribers in foreign countries are charged extra $25 for the postal fee. 3.2 Identify Non-functional Requirements The only NFR identified in this case is Response Time: response time for all checking and displays should be within 5 seconds. 3.3 Build Base Use Cases According to the use case diagram presented in Fig. 2(a), we have eight base use cases which represent the core functionality of the system. Here we only present the use case of “Add subscription” as an example (shown in Fig. 3(a)). Note that the five join points and nonfunctional aspects are added later after Step 3.4 and Step 3.5. 3.4 Identify and Create Functional Aspectual Use Cases After all the base use cases are built, we examine if each optional requirement, subordinate requirement, and business rule cross-cuts more than one base use case. If so, it is modeled with an aspectual use case. At the same time, all the corresponding join

140

C. Lu and I.-Y. Song

points of its pointcut are identified. The cross-cutting relationship can be examined based on the use case diagram. From the use case diagram presented in Fig. 2(b), we can see that: • OR1 cross-cuts two base use cases “Add Subscription” and “Renew/Change subscription”; • SR1 cross-cuts three use cases “Add Subscription”, “Renew/Change subscription,” and “Cancel Subscription”; • SR2 cross-cuts four use cases “Maintain Subscriber”, “Add Subscription”, “Renew/Change subscription,” and “Cancel Subscription”; • BR1 cross-cuts two use cases “Add Subscription” and “Renew/Change subscription”; • BR2 cross-cuts two use case “Add subscription” and “Renew/Change subscription”. Consequently, we build an aspectual use case for each of the above requirements. Here we only present the aspectual use cases for OR1 (shown in Fig. 3(b)), SR1 (Fig. 3(c)), and BR1 (Fig. 3(d)).

Maintain Subscriber

Maintain Subscriber

Subscriber

Send confirmation Subscriber email (SR2)

Add subscription Check status

Add paid subscription Get Free Subscription (OR1)

Subscriber Check status

Renew/Change subscription

Apply Discount (BR1) Renew/Change subscription

Cancel subscription Staff

Send renewal notice

Charge Foreign Postal Fee (BR2)

Cancel subscription

Process issue mailings Staff

Process issue mailings Process Credit Cards (SR1)

Send renewal notice Terminate subscription

Scheduling System

Terminate subscription

(a)

(b)

CCAS

Scheduling System

Fig. 2. The use case diagrams of SAS. The use case diagram in (a) represents the core functionalities of SAS. The use case diagram in (b) shows the cross-cutting relationships among base use cases and aspectual use cases.

3.5 Identify and Model Non-functional Aspects The only NFR identified from the problem specification is Response time. It is easy to see that this NFR affects almost all the base use cases shown in Fig. 2(b). So it is modeled with the Nonfunctional Aspect Template (as shown in Fig. 3(e)). 3.6 The Composition of Aspects to the Base Use Case Fig. 3 illustrates the composition of the aspectual use cases to the base use case Add paid subscription. The composition is based on the definition of join points in the

A Comprehensive Aspect-Oriented Use Case Method

USE CASE Name Actor Goal Level Type Condition

Advice

Pointcut

Get Free Subscription Subscriber To Obtain free subscription

Aspect Extension The subscriber is the author of the articles or the member of the editorial board Actor Action System Action 1. Displays the subscription data to confirm 2. Accepts 3. Determines the ending date and clicks to and renew warning date proceed … … Label Corresponding Join Points Add Paid Subscription.Check Eligibility for Free Subscription Renew/Change Subscription. Checking Check Eligibility for Free Eligibility Subscription

USE CASE Name Actor Goal Overview Level Trigger

Link 1 Nonfunctional Aspects

Join Points

USE CASE Name Actor Goal Level Type Condition

Pointcut

(c)

Process Credit Card

Goal

To process charges and refunds as related to subscriptions

Level Type

Aspect Inclusion

Condition

Advice

Pointcut

The subscriber submits credit card information Actor Action System Action 1. Send the credit information to CCAS 2. Return the successful status flag 3. Returns to the primary flow of the base use case Label Corresponding Join Points Add Paid Subscription. Submit Credit Information Submitting Renew/ChangeSubscription Credit .submit Credit Information Information Cancel Subscription. Submit Credit Information

(a)

Add Paid Subscription Subscriber, Staff To obtain a paid subscription of the HOST …

Base

Primary Flow

Advice

USE CASE Name

(b)

141

The subscriber has chosen “Paid Subscription” option Actor Action System Action … … … 5. Calculates the total subscription fee … … 9. Enters the name on the Credit Card, Credit Card type, Credit Card No., and expiration … date. Then, submit the payment data. ... 11. Assigns a subscription ID … … Response time Link 3 Label Position JP1. Check eligibility for free subscription Before Step 5 JP2. Submit Credit Information Within Step 9 JP3. Confirm successful subscription After Step 11 JP4. Check subscription period Within Step 5 JP5. Check subscriber’s address Before Step 5

(d)

Apply Discount

Staff To apply 10% discount of subscription fee

Aspect Business rule

Link 2

The number of subscription year is greater than one. Actor Action System Action 1. Discount the subscription fee by 10% for the first 3 subscription years 2. Shows the subscription period and discounted subscription fee to confirm 3. Accepts and 4. Returns to the primary flow of clicks to proceed the base use case Label Corresponding Join Points Checking Subscription Period

Add Paid Subscription.Check Subscription Period Renew/Change Subscription. Check Subscription Period

Nonfunctional Aspect Name

Response Time

Link 4

(e)

Goal

To Improve the Performance of the system

Description

Information should be accessed and displayed within 5 seconds

Maintain Subscribe; Add Paid Subscription; Affected Use Cases Check Status; Renew/Change Subscription; Cancel Subscription Positive Relations to other Non-functional Aspects …. Priority

Negative …

Second

Fig. 3. The composition of aspectual use cases and non-functional aspects to the base use case

142

C. Lu and I.-Y. Song

base use case and the definition of pointcuts in the aspectual use cases (Get Free Subscription, Process Credit Card, and Apply Discount). For instance, in the aspectual use case “Apply Discount”, a pointcut called “Checking Subscription Period” is defined. This pointcut corresponds to two join points. The identification of each corresponding join point comprises two parts. The first part refers to the base use case to which the aspectual use case is to be composed (e.g., Add Paid Subscription, see Link 1). The second part refers to the specific join point defined within that base use case (e.g., Check Subscription Period, see Link 2). Then the position of the join point specified in the base use case tells at which specific step within the primary flow the join point is defined (see Link 3). In this instance,the join point “JP4 Check Subscription Period” of the base use case “Add paid subscription” occurs “within Step 5” of the primary flow. It means that the “Advice” of the aspectual use case “Apply Discount” is composed to the primary flow of the base use case “Add Paid Subscription” at a point within Step 5 in condition “The number of subscription year is greater than one”. The base use cases to which a non-functional aspect is composed are referred to through the component of “Affected Use Cases” defined in the non-functional aspect template (see Link 4).

4 Conclusions This paper proposed a comprehensive aspect-oriented use case method to model complex business requirements. We defined aspects as the requirements cross-cutting multiple use cases. The three-fold contributions of our paper are: First, we extended the types of aspects into four types: NFRs, extending requirements, included requirements, and business rules. Existing approaches have not treated business rules as an aspect. In this paper, we view business rules as an important source of aspects when it cross-cuts more than one use case, since a business rule is usually tangled in many major concerns of a system. Furthermore, it is more changeable than the core functionality. If business rules are represented as aspects, the base model of a system would be disentangled from business rules, so that the base model can evolve independently without invasively affecting each other. This would further improve the reusability of both the base model and the representation of business rules. Second, we proposed three different types of templates for documenting aspect-oriented use case models. With these four types of aspects and three templates, we provided a comprehensive aspect-oriented use-case method to model both functional aspects and nonfunctional aspects. Third, we have shown that the proposed model successfully realizes the composition of aspects to the core functionalities at the requirement level.

References 1. Araújo, J., Moreira, A., Brito, I., Rashid, A.: Aspect-Oriented Requirements with UML. In: Workshop on Aspect-Oriented Modelling with UML, Dresden, Germany, pp. 1–6 (2002) 2. Araújo, J., Coutinho, P.: Identifying aspectual use cases using a viewpoint-oriented requirements method. In: Early Aspects: Aspect Oriented Requirements Engineering and Architecture Design, Boston (2003)

A Comprehensive Aspect-Oriented Use Case Method

143

3. Jacobson, I., Ng, P.-W.: Aspect-oriented Software Development with Use Cases. Addison Wesley, Boston (2005) 4. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 220–242. Springer, Heidelberg (1997) 5. Rashid, A., Moreira, A., Araujo, J.: Modularisation and Composition of Aspectual Requirements. In: 2nd International Conference on Aspect-Oriented Software Development (AOSD), pp. 11–20. ACM, New York (2003) 6. Whittle, J., Araujo, J.: Scenario modelling with aspects. IEE Proceedings 151, 157–171 (2004)