ACHIEVING SUPPLEMENTARY REQUIREMENTS USING

ASPECT-ORIENTED DEVELOPMENT

Julie Vachon and Farida Mostefaoui

DIRO, University of Montreal

Montreal (Quebec), Canada

Keywords:

Aspect-oriented development, supplementary speciﬁcations, design pattern, requirement modeling.

Abstract:

The problem of attempting to work supplementary requirements (software quality attributes and constraints)

only around the end of the development phase is frequent and quite risky for there is little chance the ﬁnal

architecture will be able to meet these quality requirements without important modiﬁcations. Supplementary

speciﬁcations capture the requirements which are not deﬁned using the use case model. They are some kind

of crosscutting concerns which one would like to plug in at some later stage of the design process (e.g. after

prototyping use cases). The connection with the aspect notion suggests that aspect-oriented techniques may

here be called upon advantageously. This article presents an aspect-oriented methodology to support the devel-

opment of supplementary speciﬁcations in UML. The use-case analysis is adapted to take care of crosscutting

requirements and a pattern is proposed for the elaboration of aspect-oriented designs.

1 INTRODUCTION

Business software speciﬁcation documents often con-

tain numerous satellite requirements which complete,

surround or constrain the realization of the software

uses cases. These requirements may concern software

qualities such as performance or reliability. They

may also describe the various business rules which

the application must obey. Current incremental and

iterative development approaches generally focus on

analysis, design and implementation of use cases i.e.

main system services. It is often only by the end

of the development process, indeed sometimes just a

few hours before the delivery day, that developers re-

ally start worrying about those other requirements, yet

recorded in a special document called Supplementary

Speciﬁcations. This document intends to describe

(1) quality goals, (2) design constrains and (3) var-

ious crosscutting functionalities. At this stage, it is

really a matter of chance if these speciﬁcations can

still be satisﬁed. But if the whims of fate are bad,

it might become a feat to modify the system archi-

tecture and detailed design to satisfy these additional

requirements unfortunately relegated to a position of

secondary importance.

To overcome this problem, this paper introduces

a new development approach based on the aspect-

oriented paradigm and using the UML for modeling.

Affording the same advantages as object-oriented dis-

ciplines, the aspect-oriented paradigm allows bring-

ing to the highest rank all these “non use-case” con-

cerns which crosscut the various system modules im-

plementing main functional requirements.

By their global nature, supplementary requirements

can relevantly be considered as crosscutting concerns.

On one hand, they should be documented early in the

analysis phase and never be neglected during develop-

ment. On the other hand, since they affect many use

cases, it is not a good idea to start their design ﬁrst!

Moreover, technical and algorithmic solutions needed

to realize these requirements are often not clearly

identiﬁed at the beginning of the project. However,

once use cases design have mainly been taken care

of, one should ideally be able to readily plug in a

component implementing some given supplementary

requirement without needing to modify the architec-

ture. With the same ease, one should be able to retract

or replace these components.

A software system may consist of several kinds

of additional concerns: business logic, performance,

data persistence, logging and debugging, authenti-

cation, security, etc. Aspect-oriented programming

(AOP), as introduced in (Kiczales et al., 1997), pro-

vides explicit support for dealing with these crosscut-

584

Vachon J. and Mostefaoui DIRO F. (2004).

ACHIEVING SUPPLEMENTARY REQUIREMENTS USING ASPECT-ORIENTED DEVELOPMENT.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 584-587

DOI: 10.5220/0002657005840587

 SciTePress

ting concerns scattered throughout the software sys-

tem and which often result in code tangling problems.

Hence, our development approach is taking advantage

of aspect-oriented principles and constructs to facili-

tate the “in-time” ﬂexible realization of supplemen-

tary requirements, not only at the programming level,

but as soon as the analysis begins.

This work-in-progress paper shows the relevance of

aspect-oriented development for these “non use-case

requirements”. Motivations, strategies and aspect-

oriented design solutions are presented. We propose

a design pattern for aspect weaving and explain our

methodology on a small case study.

Former Work

Various approaches have been proposed to intro-

duce aspect-oriented concepts into UML. Some of

them suggest adding aspect-oriented concepts di-

rectly in the meta-model (Suzuki and Yamamoto,

1999). Other achieve aspect-oriented modeling by

introducing a new proﬁle in UML (Aldawud et al.,

2001). In (Clarke and Walker, 2001), elements are

decomposed into special packages to be later weaved

with others using composition relationships. Authors

in (Stein et al., 2002) propose a UML based design

language dedicated to the representation of AspectJ’s

speciﬁc constructs.

Closer to our view of modeling, Jacobson explains

in (Jacobson, 2003) how aspects can be modeled as

extension use cases and how the base concepts of

AOP have their equivalents in use case related ele-

ments. Our goal is to go further in this direction and to

show how UML can be put to work to guide and docu-

ment the development of aspect-oriented systems, es-

pecially those ones having to deal with supplemen-

tary requirements. We propose a modeling approach

based, on the current UML notation. Contrarily to

former solutions, few extensions are here required to

adapt UML to aspect-oriented analysis and design,

and those introduced are very natural.

2 ASPECT-ORIENTED

DEVELOPMENT OF

SUPPLEMENTARY

REQUIREMENTS

Use Case View

To illustrate our approach, we refer the reader to the

well-known ATM (Automated Teller Machine) exam-

ple. The ATM requires functionalities (logging, se-

curity, etc.) which can’t be formulated as standard

use cases for they are not main services but rather

common sub-fonctionalities required by them. Fig-

ure 1 gives an overview of these supplementary re-

quirements.

Table 1: Supplementary spec. for the ATM

Functionality :

- Logging : Log all deposit and withdraw trans-

actions to persistent storage on the central server.

- Security : Each access to an account requires

client authentication.

Reliability:

- Recoverability : If there is a failure, store and

forward operations in order to complete the trans-

action anyway and recover later on.

Performance : ...

As commonly agreed, use cases are not appropri-

ate to capture these quality goals, design constraints

or global requirements applicable to the whole sys-

tem application. The Supplementary Speciﬁcations

documents those requirements apart, for they would

otherwise be sparsely described in uses cases.

A better idea, however, consists in turning these

supplementary requirements into special use cases.

As mentioned in (Malan and Bredemeyer, 2001), non-

functional requirements are often “not speciﬁed in

time”, “compromised without attention to the trade-

offs involved”, and/or “speciﬁed in loose, fuzzy terms

that are open to wide ranging and subjective interpre-

tation”. Transforming supplementary requirements

into use cases, (thus describing the functionalities re-

alizing them), allows bringing them back to the high-

est ranking (i.e. use case level) and entails developers

to handle them in a more disciplined way.

extension point

logPointCut

extension point

logPointCut

<<aspect>>

Logging

Deposit

Transfer funds

Withdraw

<<extend>>(logPointCut)

Client

Figure 1: ATM logging expressed as a use case.

In the ATM example, the Logging supplementary

requirement can be turned into a use case, as shown

by Figure 1. To model the crosscutting behavior of

the Logging functionality and to show its insertion

into both use cases Deposit and Withdraw, the UML

« extend » relationship is used. Hence these base

use cases are implicitly modiﬁed, in a modular way, at

indicated extension points, and this, without them be-

ACHIEVING SUPPLEMENTARY REQUIREMENTS USING ASPECT-ORIENTED DEVELOPMENT

585

ing aware of the extension. The following correspon-

dence therefore becomes obvious for those familiar

with AOP: extended use cases can be implemented as

aspects while extension points can be assimilated to

pointcuts.

This way, the Logging requirement can be mod-

eled as an independent aspect weaving into the rest

of the design. A design pattern, called “Aspect-

Weaving” (AW), is proposed for this modeling. It per-

tains to how aspects are structured and how they be-

have (weaving). The ATM example and its Logging

requirement are modeled to illustrate aspect-oriented

analysis and design based on the AW pattern.

Static View

Consider the Logging use case of the ATM ex-

ample. Figure 2 shows how the Logging requirement

can be integrated into the UML class structure of the

ATM, following aspect-oriented principles.

ApplicationInterface

+withdraw(m:Integer)

+deposit(m:Integer)

+getBalance():Integer()

+balance : Integer

+no: String

Account

AspectLogging

<<aspect>>

<<crosscut>>

<<before>>

+ writeOp(op:String, a:Account, m:Integer, d:Date)

+ deleteOp(op:String, a:Account, m:Integer, d:Date)

+ displayOp(d:Date)

LogFile

+ logPointCut(op:String, a:Account, m:Integer)

+ <<call>> Account.withdraw()

+ <<call>> Account.deposit()

<<pointcut>>

LogPointCut

Figure 2: Class diagram for the ATM.

In this model, (1) the behavior of the Logging use

case is captured by a class named AspectLogging

with stereotype «aspect » while (2) the exten-

sion point logPointCut is modeled by a class

interface named LogPointCut with stereotype

«pointcut ». According to the use case view

(Figure 1), the extension point logPointCut ref-

erences a set of locations within the behavioral se-

quence of use cases Withdraw and Deposit. A

location is usually related to an event (e.g. method

call) in a scenario. These locations are called joint

points and are here listed in the middle compart-

ment of the LogPointCut interface. A depen-

dency relationship, labeled « crosscuts », relates

The orientation of the « crosscuts » dependency is

signiﬁcant, for it illustrates the fact that an aspect can be

plugged “in or out” without modifying the speciﬁcation of

the crosscut classes.

the « pointcut » interface to each of the classes

which may activate one of its joint points. In the

ATM use case model, the logPointCut exten-

sion point references locations where withdraw and

deposit operations are executed on accounts. To

mark this dependency, the LogPointCut interface

has a « crosscuts » relationship to the Account

class implementing these operations.

The LogPointCut interface also contains an op-

eration named logPointCut whose implementa-

tion must describe the behavior to be inserted at joint

points i.e. at special locations, within the Withdraw

and Deposit use cases, where operations must be

logged. In our example, the AspectLogging class

implements the LogPointCut interface and will

thus provide the code, called an advice, to be executed

at the given joint points. A realization relationship re-

lates the « aspect » class to the « pointcut »

interface. It has one of the following stereotypes,

« before », « after », or « around », accord-

ing to whether the advice must be executed before,

after or instead of a joint point when it is reached. As

speciﬁed on Figure 2, withdraw and deposit op-

erations on Account objects are recorded into the

LogFile just before being executed.

We generalize this modeling approach and sum-

marize it in a design pattern called “Aspect-

Weaving”(AW). Figure 3 shows the general structure

of the AW pattern which has been applied to the ATM

example. The next section explains how the pattern

behaves.

+ <<call>> CrosscutClass1.m1()

+ <<execute>> CrosscutClass2.m2()

PointCut_X

<<pointcut>>

+ pointCut_X()

Aspect_X

<<aspect>>

realization stereotypes:

<<after>>, <<before>>, <<around>>

+ m2()

CrosscutClass2

CrosscutClass1

+ m1()

<<after>>

<<crosscuts>><<crosscuts>>

Figure 3: Structure of the Aspect-Weaving pattern.

Dynamic View

The sequence diagram of Figure 4 illustrates

the weaving of the Logging use case into the

Withdraw use case of the ATM example. It pro-

poses a compiler-independent representation of this

weaving into a withdraw scenario. As shown, the sce-

nario starts when the ApplicationInterface

object sends a withdraw request (message 1) to the

Account object. This withdraw call ﬂags a

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

586

:ApplicationInterface :AspectLogging :LogFilea:Account

<<resume>>

1.1.1 writeOperation("withdraw", a, m, date)

1.1 logPointCut("withdraw", a, m)

1. withdraw(m) !

Figure 4: Sequence diagram describing a withdraw scenario of the ATM.

joint point declared in the LogPointCut inter-

face (c.f. Figure 2). The joint point is repre-

sented by an exclamation mark on the sequence di-

agram. We therefore know that some advice call

has been woven before, after and/or around the join

point. As speciﬁed in the static view, the ad-

vice logPointCut("withdraw", a, m) im-

plemented by AspectLogging is ﬁrst executed

(message 1.1): the withdraw operation is recorded

in the LogFile object (message 1.1.1). The

Account object can then resume its activities and

execute its withdraw method. Since there is no

more advice attached to the reached joint point,

the procedure call gives back control to its initiator

ApplicationInterface.

3 CONCLUSIONS

This project proposes a UML development methodol-

ogy based on the aspect-oriented paradigm. It takes

into account the importance of supplementary re-

quirements by considering them as special extension

use cases and by guiding their realization through

aspect-oriented design.

First attempts to integrate aspects into software

were made in programming languages (AspectJ, Hy-

perJ and so on). Then, researchers took interest in

ways to elaborate software designs which could eas-

ily map to aspect-oriented programs. Our belief is

that aspect should be available from the very begin-

ning, that is right from the analysis phase. Hence-

forth, supplementary requirements, which can often

be formulated as extension use cases comparable to

aspects, can be integrated into the rest of the system

and their implementation can naturally be realized

through aspect-oriented mechanisms. The Aspect-

Weaving pattern presented in this paper is part of

wider development process covering all phases from

analysis to implementation.

Further work will be concerned with the model-

ing of a complete case study. We plan to evaluate

and compare the utility and efﬁciency of our aspect-

oriented approach regarding the development of dif-

ferent kinds of supplementary requirements (e.g. re-

lated to concurrency, security, etc.). The relevance of

the aspect-oriented approach for software veriﬁcation

is also under study.

REFERENCES

Aldawud, O., Elrad, T., and Bader, A. (2001). A uml proﬁle

for aspect-oriented software development. In OOP-

SLA’01 (Workshop on AOP).

Clarke, S. and Walker, R. (2001). Composition patterns: an

approach to designing reusable aspects. In Proc. of the

23rd Int. Conf. on Software Engineering, pages 5–14.

Jacobson, I. (2003). Use cases and aspects – working seam-

lessly together. J. of Object Technology, 2(4):7–28.

Kiczales, G. et al. (1997). Aspect-oriented programming.

In Proc. of ECOOP’97), volume 1241 of LNCS, pages

220–242.

Malan, R. and Bredemeyer, M. (2001). Deﬁning non-

functional requirements. www.bredemeyer.com/-

pdf_ﬁles/NonFunctReq.pdf.

Stein, D., Hanenberg, S., and Unland, R. (2002). A uml-

based aspect-oriented design notation for aspectj. In

Proc. of the 1st Int. Conf. on AOSD, pages 106–112.

Suzuki, J. and Yamamoto, Y. (1999). Extending uml with

aspects: Aspect support in the design phase. In

ECOOP’99 (Workshop on AOP).

ACHIEVING SUPPLEMENTARY REQUIREMENTS USING ASPECT-ORIENTED DEVELOPMENT

587