USING CLASSPECTS FOR INTEGRATING NON-FUNCTIONAL ANDFUNCTIONAL REQUIREMENTS

Tegegne Marew, Doo Hwan BaeDivision of Computer Science,

Korea Advanced Institute of Science and Technology, Daejon 305-701, Korea{tegegnem, bae}@se.kaist.ac.kr

ABSTRACT

Aspects are originally introduced to capture cross-cuttingconcerns among classes. Often this cross-cutting concernsends up being non-functional requirements. We can useSoftgoal Interdependency Graphs(SIG) to systematicallyanalyze and design non-functional requirements. In this pa-per, we propose a set of rules that could be used to capturethe information in SIGs as classpects. Then the classpectsthus generated are integrated with the classes that encapsu-late functional requirements. As a result, any further lifecycle of the software development not only captures thefunctional but also the non-functional requirements.KEY WORDS Non-Functional Requirments, Classpects, NFR FrameWork

1 Introduction

Requirements in software engineering are traditionallyclassified as functional requirements (FR) and Non-functional requirements (NFR). The analysis and design ofFRs has got a lot of attention from the early days of soft-ware engineering. On the other hand, NFRs like perfor-mance, security, usability and correctness often are incor-porated, if they are ever included, into the final system asafter thought (first build the FRs and then add the NFRs ifyou can). Still, complex and expensive systems has failedmiserably because of improper management of quality at-tributes (NFRs)[1, 2, 3].

A number of researches have been conducted on theanalysis of NFRs. Even though there are a number of dif-ferent approaches for dealing with NFRs, the Non Func-tionality Requirement Framework [4, 5, 6] has been therelatively successful approach as it has been the basis ofmany of the other approaches and has the most case studiesconducted to validate it. The NFR framework, discussedfurther in [7], is supposed to work in parallel with other FRanalysis methods like OOA even though the original de-velopers of NFR Framework didn’t provide much detail onhow to accomplish such objective.

518-075

Aspect-oriented software development has been orig-inally introduced to offer a higher separation of concernsthan provided by OOP by capturing cross-cutting concernsas aspects. Often this cross-cutting concerns turn out tobe NFRs. Therefore, aspects has been often used to cap-

ture non-functional requirements. In this paper, we suggestan approach on how to capture the NFRs identified by theNFR Framework as aspects so that NFRs can be integratedeasily with FRs during software development.

The rest of the paper is organized as follows. Sec-tion 2 introduces the two works our research is based upon.In Section 3, we discuss the the approach for integratingNFRs to FRs followed by Section 4 for discussion on theapproaches that are similar with ours. Finally, Section 5summarizes this paper and explains what we are going toexpand on this research.

2 Background

The concepts in this paper closely depend on ideas con-tained in two works which we discuss in this section. Thefirst is the NFR Framework to help us capture the NFRs ofa given system. The other work we discuss is classpects[8] which tries to combine the concept of class with the theconcept of aspect.

The NFR Framework is a qualitative approach foreliciting and analyzing NFRs. It treats NFRs as softgoalsthat need to be satisficed instead of satisfied. SIG, SoftgoalInterdependency Graph, plays a central role in viewing andanalyzing NFRs. In this paper, we utilize the fact that theNFR Framework decomposes NFR along both topic, whatkind of NFR it is, and parameter, the entity in the systemthe NFR is applied to as shown in Figure 1. The AND/ORdecomposition of NFRs suggested by the NFR Frameworkalso is used to capture NFRs as aspects.

One of the important features of the NFR Frameworkis the management of the interdependencies between dif-ferent NFRs. The dependencies can be one of make, hurt,break, help, and undetermined. The Framework also haveguidelines on how to combine these different contributions.

The other research work we use in our work is the no-tion of classpects [8]. Their motivation is to leverage theadvantages of both class and aspects. We employ their ap-proach because it significantly improves the compositional-ity of aspect modules, expanding the program design spacefrom the two-layered model of AspectJ-like languages toinclude hierarchical structures. By allowing the join pointsof aspects be named in the method-join point binds, aspectsnot only can advise base classes but other aspects. Fromthe example below, we can see the joinpoint, Exception-

142

Performance (Account)�

Space (Account)� Response Time (Account)�

Figure 1. Performance can be decomposed, along topic, tospace and time requirements

Handler, is named. Therefore, if another classpect wantto advice this joinpoint, there is no problem of identifyingExceptionHandler.

c l a s s E x c e p t i o n {p o i n t c u t e x c e p t i o n ( ) :

e x e c u t i o n (∗ ∗ ( . . ) ) & &! w i t h i n ( E x c e p t i o n H a n d l e r ) ;

s t a t i c a f t e r e x c e p t i o n ( ) :E x c e p t i o n H a n d l e r ( ) ;

p u b l i c vo id E x c p e t i o n H a n d l e r ( ) {/∗ Handle t h e e x c e p t i o n ∗ /

}}

3 The Approach

The general approach we propose for integrating non-functional requirements and functional requirements isgiven in Figure 2. The first step, creating SIG, is alreadydiscussed elsewhere[4, 5, 6]; therefore, we are not going todiscuss it here. Instead, The ”synthesizing classpects fromSIG” phase is where we are going to concentrate. At thisstage, we use rules that are discussed in to transform theSIG to a set of classpects that can easily be integrated withthe classes that capture the FR. At this stage, the classpectsare very much skeletal in that the actual classes they ad-vise and the advises they make are not completely discov-ered. To accomplish that objective, we need to discover theclasses that the classpects are supposed to advise. We dothat at phase 3 of the the approach. Once we discover suchclasses we need to fill out the actual advises the classpectsgive to those classes along with filling out additional infor-mation required for integration.

3.1 From SIG to Aspects

Of the different information contained in SIGs, we will usethe followings to synthesis aspects from a SIG. They are:

• the topic: name of the non-functional requirement

Synthesising Classpects from SIG�

Descovering Classes for the Classpects�

Integrating the Classes and the Classapects�

Creating SIG�

Figure 2. An approach for integrating NFRs with FRs

• the parameter: the object or entity the non-functionalrequirement applies to

• the decomposition of a non-functional requirement ei-ther on its topic or its parameter

In this section, we will discuss the rules for creatingaspects from a SIG one by one. We use the textual form ofSIG as suggested by [6] to discuss the rules but the corre-sponding graphs can be seen in Figure 3 .

• A1(B) AND A2(B) SATISFICES A(B)

We create three classpects: A1, A2 and A. A ad-vises B while A1 and A2 advices A. At first glance,it may seem A1 and A2 should advice B. However,that would lose the information A is refined into A1and A2. We can preserve the information if we ensureA1 and A2 advise A instead of B. Note that even if Ais a NFR and B is an object which may be captured asclass, since we use classpects, both A and B are finallyimplemented as classpects.

• A(B1) AND A(B2) SATISFICES A(B)

Here an entity B in the system is decomposed into B1and B2. This situation occurs often as a result of

– When B1 and B2 are subclasses of B. For in-stance an account can be subclassed into goldac-count and regularaccount

– When B1 and B2 refer to (deals with) differentattributes of B. This is called decomposition viaattributes.

– When B1 and B2 are mutually exclusive sub-sets of B or in other words B is conceptuallycoarse grained entity in the system which later

143

is decomposed into independent classes. For in-stance, system refereing to the whole softwaresystem later decomposed into memory, cpu, etc.Here we don’t expect B to actually exist as aclass in the final software code and thus cannotbe advised.

Since we don’t have the class diagrams at the time weare analyzing the SIG, we cannot decide which caseactually applies except use our best judgement.

If we decide it is the first case, we only need oneclasspect A that advises B. Since B1 and B2 are sub-classes of B, the advise of A to B applies to them au-tomatically.

If it is the second case, we need three classpects A,A1 and A2. We have to remember B1 and B2 arepart of B as they deal with different attributes of B atcode level. We make classpect A1 to advise A, butthe advise is about the attributes of B dealt by B1. Inthe same manner, classpect A2 should advise A onthe attributes that are dealt by B2. Finally, classpectA should advise B. The example below will illustratethis particular case.

In the third case, since we don’t have B at thecode level (because it is represented by the indepen-dent (mutually exclusive) B1, and B2), we need theclasspect A to directly advise B1 and B2.

• A1(B) OR A2(B) SATISFICES A(B)

Here one of A1 or A2 is chosen to advise A whileA advises B. This seems redundant as A1 or A2 candirectly advise B but in that case the relation betweenA1 or A2 and A is lost in the code.

• A(B1) OR A(B2) SATISFICES A(B)

This is similar to case 2. Therefore, we have threecases (but the second case doesn’t make sense for“OR” decomposition and we haven’t come across iton the case study we have performed so far and thuswe don’t discuss it here). In the first case, classpect Aadvises B. We don’t need to know which of B1 or B2is chosen to refine B. In the third case we care since Bactually doesn’t exist at a code level. If it is B1, thenclasspect A will be made to advise B, otherwise A willadvise B2.

We can see the application of such rules using Fig-ure 4. Here the white clouds represent softgoals and theshaded clouds represent operationalization. The decompo-sition of the root is via attributes. The skeletal classpectcode generated looks like

p u b l i c c l a s s SafeRoomMal{

1 Room rm ;2 p u b l i c SafeRoomMal (Room rm ){3 t h i s . rm = rm ;

A(B)�

A(B1)� A(B2)�

A(B)�

A1(B)� A2(B)�

(�1�)�

A(B)�

A(B1)� A(B2)�

A(B)�

A1(B)� A2(B)�

(�2�)�

(�3�)�

(�4�)�

Figure 3. The different cases of the rules

4 }5 p u b l i c vo id s a f t e y f u n ( ) {6 in fo rm f a c i l i t y manager7 }8 b e f o r e e x e c u t i o n { ( p u b l i c ∗Room . ∗ ( ∗ ) )9 && r e t u r n s ( r e t ) && a r g s ( ) :10 c a l l s a f e t y F u n ( ) ;}

p u b l i c c l a s s SafeRoomMalOI{SafeRoomMal srm ;p u b l i c SafeRoomMalOI ( SafeRoomMal srm ){

t h i s . srm = srm ;}p u b l i c vo id s a f t e y f u n ( ) {

a l l c e i l i n g l i g h t s onand in fo rm u s e r

}b e f o r e e x e c u t i o n ( p u b l i c ∗

safeRoomMal . ∗ ( ∗ ) )&& r e t u r n s ( r e t ) && a r g s ( ) :c a l l s a f e t y F u n ( ) ;

}

p u b l i c c l a s s SafeRoomMalMD{SafeRoomMal srm ;p u b l i c SafeRoomMalMD ( SafeRoomMal srm ){

t h i s . srm = srm ;}p u b l i c vo id s a f t e y f u n ( ) {

i n fo rm u s e rand s e t room as o c c u p i e d

}b e f o r e e x e c u t i o n ( p u b l i c ∗

safeRoomMal . ∗ ( ∗ ) )&& r e t u r n s ( r e t ) && a r g s ( ) :c a l l s a f e t y F u n ( ) ;

}

In the classpect SafeRoomMal, lines 2-4 describe theconstructor which designate a Room class (here we are notsure if there is a room class in the functional requirementbut we use it as first approximation) as one of its own at-tributes. This helps the classpects to access the attributes ofRoom if there is a need to do so. In lines 5-7, we have themethod that advices the class Room and in lines 8-10 wehave the crosscut specifications describing which methodsand when (before, after, around) the advice occurs. The

144

Safety�(Room.�

Malfunction)�

Safety�(Room.�

Malfunction.�Motion Detector)�

Safety�(Room.�

Malfunction.OI)� ����

inform facility manager�

��������

All ceiling lights on�inform user� set room as occupied�

Figure 4. An example used to show the application of therules

important characteristics of this code are:

• It is skeletal. The actual arguments of the methodsand their bodies is not yet filled. We just have in-serted text messages based on the operationalizationsin the methods of the classpects. Actually how thatis implemented, obviously, depends on the class thatis advised. Besides, we decided every method in theRoom class is advised by SafeRoomMal. This may bechanged after going through the methods of Room.

• It preserves the the hierarchical structure of the SIG.The first class, SafeRoomMal, corresponds to the rootof the SIG. It advises a class called Room which wehope is one of the classes in the design document forthe functional requirements. If that is not the case,we have to figure out which class this classpect advise(that is the topic of the next phase). If we look at thesecond and third classes which represent the childrenof the root, they all advice SafeRoomMal. This is ac-cording to rule 2. Since the two softgoals deal withdifferent attributes of room (one about lights and theother about motion detector).

3.2 Discovering Classes

Once we synthesized the classpects for the NFRs identi-fied in the SIG, we need to find which classes in the func-tional requirement the identified classpects apply to (ad-vise). There are a number of approaches to achieve thisobjective. These include

• For both NFR and FR requirement elicitation use thesame vocabulary. Used by [9], this method ensuresthe parameters of the NFRs in the SIG are also usedin the FR elicitation. Unfortunately, this approach re-quires both FR and NFR analysts to precisely know

the objects they have identified early on. The reasonbeing to use the same term used in FR, the NFR ana-lyst should understand what the FR analyst meant tosay by that term and see if that is exactly what he (theNFR analyst) also wants to model.

• Start with use cases and consider the classes that col-laborate to implement the use case. Often a specificNFR can be seen as if it applies to a particular usecase(s) since use cases are used for functional decom-position and the quality of each functionality is cap-tured by a specific NFR. For instance, if we have ause case withdrawal, an FR, in an ATM system, wecan easily see security, an NFR, is a required quality.Once we identify the use case, we can investigate theclasses in the sequence diagram that implements theuse case to see which class(es) the NFR should be ap-plied to.

• Using the requirement document. Usually, a specificNFR is usually mentioned along side with the entitiesit applies to. If those entities are later decided to berealized as classes, then the classpect that realizes theNFR can be applied to those classes.

In our example,Figure 2, the Room class actuallyexists in the class diagram and thus the skeletal code ofclasspect SafetyRoomMal doesn’t change.

3.3 Integrating Classpects with Classes

At the final stage, we have to integrate the classpects wesynthesized from the SIG in the second phase and theclasses we determined to be advised by these classpectsin the third phase. In the SIG, the leaves of the tree struc-ture are operationalizations. These are captured in the bodyof the methods of the classpects as we saw in phase two.But, the information required to realize these methods isnot completely available in the classpects. For instance,in the classpect SafeRoomMalOI the advice is all ceilinglights on. Clearly to realize such objective, we need to haveattributes/accessor methods that allow us to manage ceil-ing attributes. Such information (being functional require-ment related) is available in the Room class we identifiedin phase two. This is the time to utilize the design speci-fication of Room to find about its attributes and methods.The class diagram of Room is shown in Figure 5.

Now using the information from the class diagram wefill out the skeletal code. When we fill out the code wehave to realize one important difference between the infor-mation contained in the SIG and UML diagrams. In UMLdiagrams, we don’t have implementation details. Yet, inthe SIG, operationalization nodes capture implementationdetails. Since NFRs are quite general and there realizationis quite independent of the particular application we are de-veloping, it is possible to incorporate the information at theSIG (now in the classpects) to the functional design docu-ments. If that is not desirable, the implementor can fill out

145

the skeletal classpects himself/herself. Here we decided toill out the classpects at the design level. The result is

p u b l i c c l a s s SafeRoomMal{1 Room rm ;2 p u b l i c SafeRoomMal (Room rm ){3 t h i s . rm = rm ;4 }5 p u b l i c vo id s a f t e y f u n ( ) {6 p r i n t l n ( ‘ ‘ Th i s room ”+ rm . i d

+ ‘ ‘ has a m a l f u n c t i o n ” ) ;7 }8 b e f o r e e x e c u t i o n { p u b l i c ∗ Room . ∗ ( ∗ ) )9 && r e t u r n s ( r e t ) && a r g s ( ) :10 c a l l s a f e t y F u n ( ) ;}

p u b l i c c l a s s SafetyRoomMalOI {SafetyRoomMal srm ;p u b l i c SafeRoomMalOI ( SafeRoomMal srm ){

t h i s . srm = srm ;}

p u b l i c vo id s a f t e y f u n ( ) {f o r a l l i i n srm . rm . l i g h t s {

srm . rm . t u r n O n L i g h t s ( i ) ;}

p r i n t l n ( ‘ ‘ Th i s room ”+ srm . rm . i d+ ‘ ‘ has a m a l f u n c t i o n ” ) ;

}b e f o r e e x e c u t i o n { p u b l i c ∗

safeRoomMal . ∗ ( ∗ ) )&& r e t u r n s ( r e t ) && a r g s ( ) :c a l l s a f e t y F u n ( ) ;

}

p u b l i c c l a s s SafeRoomMalMD{SafeRoomMal srm ;p u b l i c SafeRoomMalMD ( SafeRoomMal srm ){

t h i s . srm = srm ;}p u b l i c vo id s a f t e y f u n ( ) {

p r i n t l n ( ‘ ‘ Th i s room ”+ srm . rm . i d +‘ ‘ has a m a l f u n c t i o n ” ) ;

srm . rm . s e t O c c u p i e d ( ) ;}b e f o r e e x e c u t i o n { p u b l i c ∗

safeRoomMal . ∗ ( ∗ ) )&& r e t u r n s ( r e t ) && a r g s ( ) :c a l l s a f e t y F u n ( ) ;

}In the classpect SafeRoomMal we don’t need to do

much to incorporate all the information required. We justneed to write a println (assuming java is used as implemen-tation code). In the case of SafeRooMalOI, we have to do alittle more (for turning on the lights) using the methods inthe room class.

4 Related Work

Systematic inclusion of non functional requirements to thefunctional requirement analysis has been a topic of a num-

+setLightIntensity()�+occupied() : boolean�+setOccupied()�+lightIntensity() : Byte�+turnLights(in light : Single)�

+id : Integer�+lights : sequence(idl)�+user : String�+occupied : Boolean�+fm : String�+lightintensity : Byte�

Room�

Figure 5. The class diagram of Room

ber of researches. The non-functional requirement frame-work (NFR-Framework), discussed in section 2, often isthe spring board for most of such researches including ours.

[9] discusses how non-functional requirementselicited by NFR-Framework can be incorporated intoUML diagrams specifically use case, class, sequence, andcollaboration diagrams. Their work needs a developerto use a common vocabulary for both functional andnon-functional requirement analysis. From the SIG,they use the common vocabulary feature to find whichclasses are related to which softgoals. Once they identifiedthe relation, they add appropriate methods on the classdiagrams to realize the softgoals. The first difference withour work is that they don’t use aspects to realize NFRs.This, in our opinion, is a serious draw back as NFRs arecross-cutting concerns. Moreover, the design documentthey produce doesn’t preserve the information conveyedby the SIG. We achieve such objective by using the ruleswe developed and the classpects that are used to realize theNFRs.

[10] describes how we can start from soft goalsand discover aspects. They use goal-oriented requirementanalysis for both functional and non-functional require-ment analysis. In our work, we don’t introduce new analy-sis technique for functional requirements as object orientedanalysis is a widely accepted analysis technique. It is notalways easy to use functional requirements discovered bygoal-oriented analysis for designing classes and their rela-tionship. Besides, even if we discover aspects from SIGsusing the approach, there are no guidelines on how to findthe classes these aspects advise. Moreover, the approachdoesn’t preserve the hierarchical information SIGs provide.

5 Conclusion

We have presented an approach for integrating NFR to FRanalysis. We used the widely accepted Non-Functional Re-

146

quirement Framework to capture the NFRs. Then, we syn-thesized classpects from the SIG using the rules we devel-oped and found the classes they advise in the design docu-ments particularly class diagrams. Once we identified theclasses, we filled out the remaining code for the classpects.Therefore, we included the classpects which represent theNFRs into the class diagrams which originally include onlythe functional requirements.

We plan to extend and fine tune our approach to fullyintegrate NFRs and FRs. First, we are carrying out casestudies to validate our approach. Second, we will investi-gate if we need to add additional rules or modify existingones. Third, we are going to compare and contrast the rel-ative merits of different approaches for finding the classesthe classpects refer to. Fourth, we will try to find the bestway to capture the operationalizations in the SIG as meth-ods or attributes in the classpects. Our ultimate goal will beto provide a framework with specific practical guidelinesfor incorporating NFRs into FRs.

Acknowledgments

This work was supported by the Ministry of Information &Communication, Korea, under the Information TechnologyResearch Center (ITRC) Support Program.

References

[1] K.K. Breitman, J.C.S.P. Leite, and A. Finkelstein, The World’sStage: A Survey on Requirements Engineering Using a Real-LifeCase Study, J. the Brazilian Computer Soc., 6(1), July 1999, 13-38.

[2] A. Finkelstein and J. Dowell, A Comedy of Errors: The LondonAmbulance Service Case Study, Proc. Eighth Int. Workshop Soft-ware Specification and Design,1996, 2-5.

[3] D.R. Lindstrom, Five Ways to Destroy a Development Project,IEEE Software, 1993, 55-58,.

[4] L. Chung, Representing and Using Nonfunctional Requirements:A Process Oriented Approach,PhD thesis, Dept. of ComputerScience, Univ. of Toronto, June 1993, also Technical ReportDKBSTR- 91-1

[5] L. Chung and B. Nixon, Dealing with Nonfunctional Require-ments: Three Experimental Studies of a Process-Oriented Ap-proach, Proc. 17th Int. Conf. Software Eng., 1995, 24-28, .

[6] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, Non-FunctionalRequirements in Software Engineering(Kluwer Academic, 2000).

[7] J. Mylopoulos, L. Chung, and E. Yu., From object-oriented togoal-oriented requirements analysis, Communications of the ACM,42(1), Jan. 1999, 31-37, .

[8] H. Rajan and K. J. Sullivan, Classpects: Unifing Aspect- andObject-Oriented language design, ICSE 05, 59-68.

[9] Cysneiros,L.M. and Leite, J.C.S.P., Non-Functional Requirements:From Elicitation to Conceptual Model, IEEE Transactions on Soft-ware Engineering, May 2004.

[10] Y. Yu, J.C.S.P. Leite, J. Mylopoulos. From goals to aspects: dis-covering aspects from requirements goal models., Proceedings ofthe 12th IEEE International Requirements Engineering Conference(RE’04). 2004, 38-47, .

147