Aspect-Oriented Requirements Engineering: A Use Case Based Approach

Hammad Sharif, Saqib Rehan and Ghulam Ahmad FarrukhNational University ofComputers and Emerging Sciences

tforhammad@hotmail. com, saqibrehan@gmail. com and gafarrukh@yahoo. com]

Abstract

Aspect oriented software development has shown anew level of modularization at design andimplementation level. A technique is presented in thispaper for aspect oriented modeling of requirements.An extension is proposed for UML use caserelationships that enable the requirements model tocapture the crosscutting nature of different softwareconcerns. Using aspect oriented modeling ofrequirements can lead to better system design.System's understandability and traceability isimproved that leads to better design and easiermaintenance

1. Introduction

The age-old principal of "Separation of Concerns"[6] has not been implemented fully in the currentsoftware development methodology using objects; theemergence of aspect oriented software development(AOSD) has put even more emphasis on this issue.Aspects complement the object oriented (00)techniques and aid in handling the complexity of thesystem. With processor clock speed rising to the upperbounds and proliferation of modern wirelesscommunication gadgets, software development isbecoming more complex. The number of concerns thata software engineer has to navigate along with is alsoincreasing. In this scenario, the existing techniques forsoftware development are falling behind. AOSD hasintroduced new notions at the implementation level.But the processes working at higher phases of thedevelopment life cycle do not cater for aspect orientedsoftware development. To render the whole life cycleseamless, we need to promote the notion of aspect, upthe life cycle. This should bring uniformity to thedevelopment process and help in handling the

horizontal complexity of a system. The idea is toincorporate aspects into the software developmentprocess, from needs analysis to implementation. Aconsiderable research volume contributes to proposalsfor modifications to UML to cater for AOSD.

At the level of requirements analysis, almost allprocesses for requirements modeling and specificationprescribe that requirements should be packagedtogether so that they appear as different concerns ofthe system. This allows a software designer to comeup with a better architecture. Two broad categories forsystem level concerns are functional requirements(FR) and non-functional requirements (NFR) [10]. Butusually at the requirements modeling stage (use casesin OOSD), we mix up such requirements. The use casemodel shows functional requirements as actionbubbles, interacting with an actor. The proposals thathave been given for incorporating aspects into therequirements engineering phase mostly look for NFRsthat overlap with FRs. In this paper, we show ourresults from case studies that concerns of the systemthat are functional can also overlap over differentactions required of the system. Secondly, a simpleextension is proposed that allows the analyst to conveythe system functionality in an aspect oriented manner.The proposed scheme requires least changes to thecurrent use case syntax and should be introduced withease in the existing computer aided softwareengineering (CASE) tools.

The next section gives an introduction to theAOSD. Section 3 introduces the notion of an aspectand how it appears at the different phases of REprocess. Section 4 introduces a mechanism to extendthe use case model to allow for aspect orientedsoftware engineering. In section 5, we discuss howthis mechanism helps to improve thecomprehensibility and traceability of the softwaresystem. Section 6 contains the concluding remarks.

Figure 1. Code Tangling

2. AspectDevelopment

Oriented

Something of interest in a software sy:

defined as a concern [1]. In functionalprocesses taking place in a system are tiWhen object technology was introducedshifted from processes to objects. Thisdevelopment of software methodologiesmore importance to the design of entitiesinstead of the process. Object technologaround for almost two decades. Separationis achieved by separating the softwareclasses, the modules. There is now a stancavailable for software development u

technology. We start with requirementsmodel those requirements as use cases,

design the software artifacts andimplementation. For software to achievdifferent components work together an(

messages. We usually come across cprovide certain services to other objects a]are called by other objects. The originaticalls is distributed among a number of o

leads to tangled or spaghetti code. A go]object oriented paradigm is, "Program to ito implementation". But what if, at som

need to change interface. We shall need tothe entire code base to make the appropri;at different points.

With the introduction of aspects, an effmade to further modularize the software,tangling can be avoided. Kiczales [7]-['PARC refactored the code to a nex

modularization for an existing imagesystem. With success stories on its boriented programming technique receivecacceptance by the software community, t

technique does not replace but builds on the principlesof object oriented software development methods.

3. Notion of an "Aspect"

The notion of aspect can be understood by the aidof an analogy. In English grammar, there is a conceptof active and passive voice. Similar to change in voice,the design of a software system changes from beingproactive to reactive. Let us consider an applicationthat has security as a major concern. A typicalexample is of an ATM system as shown in Figure 2.For any transaction to take place, the user has to beauthorized and validated first. And after a session hasbeen established, each time an action is requested fromthe system, the session has to be checked for validity.

Software This is a major concern of the system that should be

dealt with, as in the following illustration of a use

case, when we are using an object oriented softwaremethodology. A usual approach to design would be as

stem can be shown in Figure 3. The Validate( ) method of classapproaches, Session is called by every transaction object,ie concerns. proactively. Any change to this method signature1, the focus would trigger a major code changing exercise. There isled to the nothing wrong with the design. It has been designed as

which gave per the requirement specification given in the use case

(or objects) model and in accordance with the object oriented

ly has been principles. The call for validation of session isof concerns essential for the system to work. But this mechanismlogic into of message passing can lead to serious problems

lard process during the system maintenance phase. To evade thissing object situation, the code for call to a session object is placedstatements, in another module an "aspect". Moreover, this

analyze and aspect is given enough intelligence to execute thefinally the session validation code just before the execution of theie its goal, transaction code. So an aspect, in this case, realizes thed exchange concern of security in the ATM system. It is a

)bjects thatnd thereforeion of theseibjects. ThisIden rule ofinterface notie stage, we

go throughate changes,

ort has beenso that code)] at Xeroxct level ofprocessing

ack, aspectI immediatebecause this Fieure 2. Use Case for ATM

Figure 3. Class Diagram for ATM Svstemmechanism that intercepts a call made to the "execute()" method and transfers the control to the "IsValid( )"

method of the Session object.

4. Aspects at Requirements ModelingStage

A change at a lower stage of a software developmentprocess reaches upward to the very first phase of theprocess. It changes the thinking process. A change inprogramming, like object oriented programming,triggered research in the software analysis and designmethodology. Now we have a Unified SoftwareProcess Model that has a theme that revolves aroundobjects, during the whole process execution. So forbetter aspect-oriented design, the notion of aspects hasto be propagated to the requirements modeling stage.This movement of promoting the introduction ofaspects into the process has been named "EarlyAspects" [3]. The goal of this movement is to makeaspects, a part of the thinking process during thesoftware systems development. In what follows, we

shall develop an extension to the existing objectoriented way of requirements modeling the use case

model.

In case of use case model, requirements are givenas interaction between an actor and the softwaresystem. Actions required of the system are representedas bubbles. These actions are derived from therequirements. Let us look at a use case (Figure 4) for a

network application that runs on different hosts. Thesehosts exchange information. From a user'sperspective, the hosts should be enabled to exchangeinformation over the network. The different aspects ofnetwork communication like compatibility andsecurity have to be taken care of in the design of thesoftware. So every time, information has to beexchanged between hosts, it needs to go through a setof network related procedures before finally gettingtransmitted over the network and reaching thedestination host. First the information needs to be

encrypted for security. Then it is divided into chunksor packets (a process called packetization in networkjargon). Each packet is appended with some meta-information before it can be transmitted. From a user'sperspective, the questions like, "How the system doesthat? How many packets it should break up the datainto before transmission? How the encryption has beendone? What meta-data is appended to the packet as

header?", are not relevant. She/He just wants thesystem to transmit data over a secure channel. But theconcerns of transmission, network compatibility andsecurity are very close in system's architecture and itsworking. Transmission of data is the functionalconcern whilst the security of data transfer is a non-

functional requirement. Note this point that how twodissimilar concerns are tangled in one use case.

Figure 4. Use Case Model of a NetworkApplication

Figure 5. Use Case of Network Application

Let us consider the ATM software system as

discussed in section 3 and shown in Figure 2. One ofthe major concerns in the development of suchsystems is security. Another concern is the limit on theamount and number of transactions that a user may

make in a day (usually called cycle limit). When theuser carries out a transaction of certain amount fromhis/her account, the cycle limit of the user isdecreased. The user is informed about the new cyclelimit for that day. So before every transaction, thesystem shall validate the user. Also, before transaction,user's cycle limit shall be checked. Then after thetransaction, user's cycle limit shall be adjusted

Such situations where sequencing of actions of thesystem is to be realized, aspect oriented softwaredevelopment aids us with a concept called advice, atimplementation phase. Advices are used to inform an

aspect that before or after some code segment getsexecuted, which other code segment must execute.There are two common advices, before and after. Inthe following section, an approach is proposed tospecify such situations at the requirements modelingstage.

5. Extending the <<uses>> relationship

To handle situations as described in the previoussection, we propose an approach that extends theexisting <<uses>> relationship of UML's use case

model. This extension to the use case model willrender it more understandable and the transition to an

aspect oriented design phase will be seamless. In case

of the software applications involving the transmissionof information over a network, the <<uses>>relationship between "Send data" and "AssemblePackets" should be changed to <<uses.before>> as

shown in Figure 5. This association between the twouse cases clarifies the functional relationship thatexists between the two use cases. Moreover, thedesigner shall be able to think in terms of aspects inthe system.

In case of the internet banking system discussed inthe last section, the session validity check is to be usedbefore making any transaction. So the new associationbetween "Make withdrawal" and "check session

Fig. 6 Use case model for an Internetbanking system

validity" becomes <<uses.before>>. Similarly, therelationship between "Check cycle limit" and "Makewithdrawal" changes to <<uses.before>>. But in thiscase, cycle limit is to be changed if funds have beentransferred or withdrawn from the account. So thecycle limit is changed after committing the transaction,thus relationship becomes <<uses.after>> as shown inFigure 6.

These small changes proposed for the use case

model will render the system easier to understand andconsequently, design quality should improve as well.The designer will have a clearer view of the aspectoriented nature of the system and should be able tohandle the complexity of the system.

6. Traceability and understandability

From the examples shown in the previous section,in case of aspect-oriented design, we can see that use

case model has poor traceability when it comes tomapping use cases to the design. With the proposedapproach for modification to the <<uses>>relationship, traceability and understandability of theuse case model has been improved. A better designcan emerge from this use case model as it shows theaspect oriented nature of the system.

7. Conclusions

Aspects at early stage of the software developmentlife cycle can improve design of the software. Thisimprovement is realized because of separation ofconcerns. If aspects are introduced at the requirementsmodeling stage of the software process, system'sunderstandability is improved. This leads to better

<<uses.before>_ ~~~~~~~~~~I %K-Anaa)\Issemb e

nD

«uses. before>>

ake withdrw

<<uses.after»

User

design that has the necessary coupling. Moreover,software design artifacts appearing later at design andimplementation stages can be traced back to therequirements model, thus leading to easy maintenance.

8. References

[1] Sutton Jr., S. M. and Rouvellou, I. ModelingSoftware Concerns in Cosmos. First InternationalConference on Aspect-Oriented SoftwareDevelopment (AOSD 2002), Enschede, TheNetherlands, Apr. 2002, ACM Press, pp.127-133.

[2] L. Rosenhainer. Identifying Crosscutting Concernsin Requirements Specifications. In: Early Aspects2004: Aspect-Oriented Requirements Engineeringand Architecture Design Workshop, Vancouver,Canada, October 25, 2004. In conjunction withOOPSLA'04 (Position Paper).

[3] Rashid, A., Sawyer, P., Moreira, A. and Arauijo, J."Early Aspects: a Model for Aspect-OrientedRequirements Engineering", IEEE JointConference on Requirements Engineering, Essen,Germany, September 2002, pp 199-202.

[4] Arauijo, J., Moreira, A., Brito, I., Rashid, A.Aspect-oriented requirements with UML. SecondInternational Workshop on Aspect-OrientedModeling with UML. September 2002

[5] E. Baniassad and S. Clarke. Theme: An approachfor aspectoriented analysis and design. InInternational Conference on SoftwareEngineering, 2004.

[6] J. Grundy, "Aspect Oriented RequirementsEngineering fro Component Based SoftwareSystems", 4th IEEE International Symposium onRE, 1999, IEEE Computer Society Press, pp.84-91.

[9] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, MikKersten, Jeffrey Palm, William G. Griswold: "AnOverview of AspectJ", ECOOP 2001, 327-353

[10] Gerald Kotonya and Ian Sommerville,Requirements engineering processes andtechniques, John Wiley & Sons, 1998

[11] James Rumbaugh, Ivar Jacobson, Grady Booch,The Unified Modeling Language ReferenceManual, Addison Wesley, 1999

[7] John Irwin, Jean-Marc Loingtier, John R. Gilbert,Gregor Kiczales, John Lamping, AnuragMendhekar, Tatiana Shpeisman, "Aspect-Oriented Programming of Sparse Matrix Code",ISCOPE 1997: 249-256

[8] Gregor Kiczales, John Lamping, AnuragMendhekar, Chris Maeda, Cristina Videira Lopes,Jean-Marc Loingtier, John Irwin, "Aspect-Oriented Programming", ECOOP 1997, 220-242