WHAT IS AN ASPECT IN REQUIREMENTS ENGINEERING?

Hermann Kaindl

Institute of Computer Technology, Vienna University of Technology, Gusshausstr. 27-29, Vienna, Austria

Keywords: Crosscutting concerns, Aspects, Requirements.

Abstract: Addressing the issue of crosscutting concerns within a software system, the notion of an aspect has been

introduced, first for so-called Aspect-Oriented Programming (AOP) and then, more generally, for Aspect-

Oriented Software Development (AOSD). Unfortunately, this notion is used with two different meanings:

one as a synonym for “crosscutting concern”, and the other as a means to deal with a crosscutting concern

within the software. Later, this notion has been carried over to so-called Aspect-Oriented Requirements En-

gineering (AORE). This raises questions about the meaning(s) of an aspect in this context, and about the

relationship of this notion in AORE and the same notion in AOP. We try to answer these questions and ar-

gue to define an aspect as a means to deal with crosscutting concerns, and not as a synonym of “crosscutting

concern”. Most importantly, an aspect in AORE is not necessarily related to an aspect within the software.

1 INTRODUCTION

Decomposing a software system according to some

given approach leads to a modular decomposition,

where the resulting modules encapsulate certain

concerns. Other concerns, however, are usually not

encapsulated in such modules and they “end up

being scattered across many modules and tangled

with one another” (Elrad et al., 2001). Such concerns

are known as crosscutting concerns.

This was the motivation for developing Aspect-

Oriented Programming (AOP) first, and later

generalizing the approach to Aspect-Oriented

Software Development (AOSD). More recently,

Aspect-Oriented Requirements Engineering (AORE)

received some attention.

However, the term “aspect” as used in AOSD

does not always match well the intuitive and usual

meaning of “aspect” in natural language, and it is

not uniformly defined even in the context of

programming. And is it simply possible to carry the

concepts and techniques over to the realm of

requirements?

We try to pinpoint open issues and to clarify the

notion of an aspect. In particular, we investigate its

meaning in AORE and distinguish crosscutting

concerns in a requirements representation from

crosscutting concerns within the software.

The remainder of this paper is organized in the

following manner. First, we provide some necessary

background on AOSD for making this paper self-

contained. Then we present a critical view of AORE

approaches, focusing on how the notion of an aspect

is defined and used. We also highlight that cross-

cutting concerns in AORE are not necessarily the

same as crosscutting concerns within the software.

2 BACKGROUND ON AOSD

Since we try to answer the question what an aspect

is in AORE, we review first how this term is defined

in AOP and AOSD. As it turns out, there are two

different views, a problem view and a solution view.

In contrast, the term aspect means in natural

language a particular way in which something ap-

pears or may be regarded. So, it is synonymous to,

e.g., appearance, look, or facet.

2.1 Problem View

The first paper on AOP that we are aware of is

(Kiczales et al., 1997). It provides the following

definition (dots are inserted by us):

“With respect to a system and its implementation

using a GP-based language, a property that must

be implemented is:

…

An Aspect, if it can not be Cleanly

Encapsulated in a Generalized Procedure.

Aspects tend not to be units of the system’s

functional decomposition, but rather to be

353

Kaindl H. (2009).

WHAT IS AN ASPECT IN REQUIREMENTS ENGINEERING?.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 354-357

DOI: 10.5220/0002280603540357

 SciTePress

properties that affect the performance or

semantics of the components in systemic ways.

…”

We do not think that this text makes it really

clear what an aspect would be, but it seems as

though this term means here the problem of cross-

cutting concerns rather than a means to deal with it.

The following definition from the AOSD Wiki in

the Web pages of the Aspect-Oriented Software

Development community is much more explicit in

this regard:

http://www.aosd.net/wiki/index.php?title=Glossa

ry#aspect

“Aspects are one kind of concern in software

development. With respect to a primary or

dominant decomposition aspects are concerns that

crosscut that decomposition.”

While it is useful to explicitly take crosscutting

concerns into account, what is the point of calling

them “aspects”? In particular, this does not even

match the usual meaning of this notion in natural

language.

2.2 Solution View

Interestingly, the very same Web pages contain a

different definition of “aspect” in the context of the

definition of “concern”, which shows a different

view (dots are inserted by us):

http://www.aosd.net/wiki/index.php?title=Glossa

ry#concern

“… There are many formulations used to capture

concerns as well-identified separate units, aspects

are one such mechanism, that are tuned to

capturing crosscutting concerns.”

We consider this a solution view, since it is about a

“mechanism” to deal with crosscutting concerns,

rather than crosscutting concerns themselves.

Also in the literature of Aspect-Oriented Pro-

gramming (AOP) an aspect is defined, e.g., in (Elrad

et al., 2001) as

“… a mechanism beyond subroutines and

inheritance for localizing the expression of a

crosscutting concern.”

In AOSD, the term aspect is used, e.g., in

(Katara and Katz, 2003)

“for a module that is potentially able to

encapsulate software or design artifacts treating

an otherwise crosscutting concern”.

In the same spirit, we transferred this aspect ap-

proach to architectures of general systems involving

mechanical, electronic and software parts

(Arnautovic and Kaindl, 2004). The key point is to

bundle the part of the architectural design that deals

with the crosscutting concern in an extra modular

unit, even though it may crosscut mechanical, elec-

tronic and software parts.

In all three cases, an aspect is clearly something

within the software system, more generally as a

mechanism or more specifically as a module. We

argue that it makes more sense to use the notion of

an aspect for such a means to deal with crosscutting

concerns rather than as a synonym of “crosscutting

concern”. While this use of the notion does also not

match its usual meaning in natural language, it

makes sense as a technical term for a technical solu-

tion.

2.3 “Early Aspects”

More recently, there was a trend to deal with aspects

“earlier” in the life cycle, see, e.g., (Baniassad et al.,

2006):

“Early aspects are concerns that crosscut an

artifact’s dominant decomposition, or base

modules derived from the dominant separation-

of-concerns criterion, in the early stages of the

software life cycle. “Early” signifies occurring

before implementation in any development

iteration.”

Here, requirements and software design are simply

treated together, as opposed to implementation in

AOP.

Also in (Baniassad et al., 2006), a straight-

forward distinction between requirements and ar-

chitecture can be found as follows:

“An aspect in requirements is a concern that

crosscuts requirements artifacts; an aspect in

architecture is a concern that crosscuts

architectural artifacts.”

Still, how do crosscutting concerns of require-

ments artifacts relate to those of architectural arti-

facts? Can the mechanisms to capture them be the

same? What is an aspect in the context of require-

ments?

3 A CRITICAL VIEW OF AORE

Let us have a closer look into the literature of

AORE, where aspects have been carried over to re-

quirements engineering. Also in AORE, some ap-

proaches use this notion as a synonym of “cross-

cutting concern”, while others propose mechanisms

for dealing with such concerns. Both do not make

clear, however, that crosscutting concerns in the

context of requirements are not necessarily the same

as crosscutting concerns inside the software. In this

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

354

spirit, we provide a critical view of AORE.

3.1 Claim of Usefulness for Design and

Implementation

Generally, AORE approaches claim that dealing

with aspects (in either meaning) is useful for soft-

ware development. See e.g., (Baniassad et al., 2006):

“Identifying and managing early aspects helps to

improve modularity in the requirements and

architecture design and to detect conflicting

concerns early, when trade-offs can be resolved

more economically.”

This is, in effect, mixing requirements and software

design, since modularity in the requirements and in

the architecture design are not necessarily the same.

In (Elrad et al., 2001), even a direct link is made

from certain requirements to the implementation

with respect to crosscutting concerns:

“Aspectual requirements are concerns that (for

common structural decompositions) introduce

crosscutting in the implementation.”

3.2 Hidden Assumption

The part of this quote “for common structural de-

compositions” may even indicate an otherwise well-

hidden assumption. Most AORE approaches seem to

tacitly assume that there is the same (or at least

similar) dominant decomposition of the require-

ments (from outside the software) and of the soft-

ware system itself!

Only under such an assumption, the same con-

cerns might crosscut the requirements and the soft-

ware design and implementation. So, is it usually

fulfilled?

The requirements are often decomposed into

functional and non-functional ones. The functional

requirements are often grouped according to a func-

tional decomposition of the overall functionality

needed. Use cases are related to each other in use

case diagrams. Such diagrams may be viewed as

representing a functional decomposition according

to use. With respect to such a dominant decomposi-

tion, at least some of the non-functional require-

ments usually crosscut the functional requirements

and/or use cases.

Is the software internally always decomposed ac-

cording to these same principles? This is not nec-

essarily the case, since certain architectural styles

such as layers, distributed architecture, repository

style etc. impose other decompositions, at least in

addition. Ironically, the non-functional requirements

are the ones that may indicate a certain software

architecture following a different decomposition,

e.g., security requirements may indicate a layered

architecture.

3.3 Mix of Requirements and Software

Design

So, there is a similar confusion of requirements and

software design in AOSD as previously in object-

oriented development methods (Kaindl, 1999).

Much as the wide-spread confusion of “analysis”

and “design” especially in the object-oriented com-

munity, this confusion may create issues both in

theory and in practical applications.

3.4 AORE Approaches based on this

Assumption

The following AORE approaches seem to be based

on the hidden assumption to have the same de-

compositions for requirements and within the soft-

ware:

 In (Rashid et al., 2002), a systematic way of

identifying crosscutting concerns using and with

respect to viewpoints is presented. It leads to

understanding crosscutting concerns in a

representation of requirements that is organized

according to viewpoints. We could not find there

any indication about consequences for possible

aspects within the software, however. Whether or

not the same crosscutting concerns will exist in-

side the software will largely depend on the

dominant decomposition of this software.

 In (Yu et al., 2004), a systematic way of identi-

fying crosscutting concerns from goal models is

presented (including “functional goals” and

“soft-goals”). The dominant decomposition

appears to be a functional decomposition. Also

here we could not find any indication about

consequences for possible aspects within the

software. Whether or not the same crosscutting

concerns will exist inside the software, will also

here largely depend on the dominant

decomposition of this software.

 In (Baniassad and Clarke, 2004), a systematic

way of identifying crosscutting concerns is

presented, and modeling them in a software

design language using their Theme approach.

This seems to bridge requirements and design

explicitly regarding crosscutting concerns.

3.5 AORE Approaches using Aspects

as a Solution Concept

The following AORE approaches use the aspect no

WHAT IS AN ASPECT IN REQUIREMENTS ENGINEERING?

355

tion as a solution concept for dealing with cross-

cutting concerns:

 In (Katz and Rashid, 2004), aspects are basic

“modules” of requirements specifications, repre-

sented using XML tagging. Such an aspect

groups crosscutting requirements. This is in the

spirit of the aspect definition of (Katara and

Katz, 2003), but the hidden assumption of the

same dominant decomposition of the re-

quirements and of the software system itself

seems to be behind this approach as well.

 In (Xu et al., 2006), a very appealing application

of the aspects idea from programming in use

cases is proposed. The program code of the

former corresponds to the action sequences of

the latter, both being behavior specifications.

The former behavior is inside the software,

while the latter is behavior in the composite

system (including the software system and the

user). While this approach leads to untangling

of the scenarios of these use cases, it is not clear

what the consequences are for untangling of

code in the implementation.

4 CONCLUSIONS

The very notion of an aspect in software develop-

ment is a misnomer somehow, since it barely

matches the intuitive and usual meaning of “aspect”

in natural language. Even worse, it is ambiguously

defined in AOP.

Therefore, we tried to clarify the different

meanings of “aspect”, with a focus on AORE. We

argue to define it as a means to deal with cross-

cutting concerns, and not as a synonym of “cross-

cutting concern”.

From a research point of view, it is important to

have a conceptually clean view of these issues and

concepts. Otherwise, there may be confusion in

practical applications. In particular, the hidden as-

sumption of the same dominant decomposition of

the requirements and the software itself is danger-

ous. Whenever it is not fulfilled, a crosscutting con-

cern identified in a requirements representation is

not necessarily a crosscutting concern inside the

software, i.e., in design and implementation.

Still, AORE is useful in its spirit of dealing with

crosscutting concerns “early” and also in the context

of requirements. This may lead to a better under-

standing of the requirements and of some of the is-

sues involved in developing the system. However, it

is necessary to consider the decompositions used in

the requirements representation and in the software

itself. An aspect identified in aspect-oriented re-

quirements engineering is not necessarily related to

an aspect within the software.

ACKNOWLEDGEMENTS

Edin Arnautovic provided useful comments to an

earlier version of this paper.

REFERENCES

Arnautovic, E., Kaindl, H., 2004. Aspects for crosscutting

concerns in systems architectures?, In Proc. of the

Second Annual Conference on Systems Engineering

Research (CSER-04), pp. 1–10.

Baniassad, E., Clarke, S., 2004. Theme: An Approach for

Aspect-Oriented Analysis and Design. In Proc. of the

26th International Conference on Software Engineer-

ing (ICSE’04), pp. 158–167.

Baniassad; E., Clements, P.C., Araujo, J., Moreira, A.,

Rashid, A., Tekinerdogan, B., 2006. Discovering early

aspects, IEEE Software, 23(1): 61–70.

Elrad, T., Filman, E.R., Bader, A., 2001. Aspect-oriented

programming: Introduction. Communications of the

ACM, 44(10):29–32.

Kaindl, H., 1999. Difficulties in the Transition from OO

Analysis to Design, IEEE Software, 16(5):94–102.

Katara, M., Katz, S., 2003. Architectural Views of

Aspects. In Proc. of the Second International Confer-

ence on Aspect-Oriented Software Development

(AOSD 2003), ACM Press, pp. 1–10.

Katz, S., Rashid, A., 2004. From aspectual requirements to

proof obligations for aspect-oriented systems. In Proc.

of the 12th IEEE International Requirements Engi-

neering Conference (RE’04), pp. 48–57.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C.,

Lopes, C., Loingtier, J.-M., Irwin, J., 1997. Aspect-

Oriented Programming. In Proc. ECOOP '97, LNCS

1241, Springer-Verlag, pp. 220–242.

Rashid, A., Sawyer, P., Moreira, A., Araujo, J., 2002.

Early aspects: a model for aspect-oriented require-

ments engineering. In Proc. of the IEEE Joint Inter-

national Conference on Requirements Engineering

(RE’02), pp. 199–202.

Xu, D., Vivek G., Nygard, K., 2006. An Aspect-Oriented

Approach to Security Requirements Analysis. In Proc.

of the 30th Annual International Computer Software

and Applications Conference (COMPSAC'06), pp. 79–

82.

Yu, Y., Leite, J.C.S.P., Mylopoulos, J., 2004. From goals

to aspects: discovering aspects from requirements goal

models. In Proc. of the 12th IEEE International

Requirements Engineering Conference (RE’04), pp.

38–47.

ICSOFT 2009 - 4th International Conference on Software and Data Technologies

356