From Goals to Aspects: Discovering Aspects from Requirements Goal Models

Abstract

Aspect-oriented programming (AOP) has been attracting much attention in the Software Engineering community by advocating that programs should be structured according to programmer concerns, such as "e#cient use of memory". However, like other programming paradigms in their early days, AOP hasnt addressed yet earlier phases of software development. In particular, it is still an open question how one identifies aspects early on in the software development process. This paper proposes an answer to this question. Specifically, we show that aspects can be discovered during goal-oriented requirements analysis. Our proposal includes a systematic process for discovering aspects from relationships between functional and nonfunctional goals. We illustrate the proposed process with a case study adapted from the literature.

Full text

From Goals to Aspects: Discovering Aspects
from Requirements Goal Models
Yijun Yu, Julio Cesar Sampaio do Prado Leite, John Mylopoulos
Department of Computer Science, University of Toronto
Abstract
Aspect-oriented programming (AOP) has been at-
tracting much attention in the Software Engineer-
ing community by advocating that programs should be
structured according to programmer concerns, such as
“efficient use of memory”. However, like other pro-
gramming paradigms in their early days, AOP hasn’t
addressed yet earlier phases of software development.
In particular, it is still an open question how one iden-
tifies aspects early on in the software development pro-
cess. This paper proposes an answer to this question.
Specifically, we show that aspects can be discovered
during goal-oriented requirements analysis. Our pro-
posal includes a systematic process for discovering as-
pects from relationships between functional and non-
functional goals. We illustrate the proposed process
with a case study adapted from the literature.
1. Introduction
Aspect-oriented programming (AOP) is founded on
the idea of aspect [4] as a cross-cutting concern dur-
ing software development. Asp e cts are usually “units
of system decomposition that are not functional” [12],
such as “no unauthorized access to data” or “efficient
use of memory”. Aspects cut across different com-
ponents of a software s ystem. The basic premise of
aspect-oriented programming is that software struc-
tured according to aspects is easier to develop, under-
stand and maintain.
In name and in practice, aspect-oriented program-
ming is a programming methodology. However, this
methodology does not deal with the origins of aspects.
Where do aspects come from? Is there a systematic
way of discovering aspects early on during the software
development process? T he main objective of this pa-
per is to propose an answer to these questions. Our
prop os al is based on the notion of goal and the analy-
sis techniques developed in goal-oriented requirements
engineering. These techniques are shown to be useful
in guiding the discovery of aspects.
Goal-oriented requirements engineering[15, 22] fo-
cuses on goals which are ”roughly speaking, precur-
sors of requirements” [7]. Goal-based models support
the description and analysis of intentions that under-
lie a new software system. Some goal models, such
as i* [25, 13], also model the actors who behold these
intentions. Most variations of goal models in the lit-
erature use AND/OR trees to represent goal decom-
position [14, 23] and define a space of alternative so-
lutions to the problem of satisfying a root-level goal.
There are several proposals in the literature for (for-
mal) goal analysis techniques. For example, obstacle
analysis [23] explores possible obstacles to the satisfac-
tion of a goal. Along a different dimension, qualitative
goal analysis [9] allows qualitative contributions from
one goal to another, and shows how to formalize and
reason with them. In whatever form, goal-oriented re-
quirements engineering has been attracting consider-
able attention within the community [1, 18, 11, 2].
The rest of the paper is structured as follows. Sec-
tion 2 presents a quick introduction to aspect-oriented
programming, while Section 3 defines a particular type
of goal model, called a V-graph. Section 4 describ es
a systematic process for discovering candidate aspects
while doing goal analysis; Section 5 illustrates the as-
pect discovery process using a case study of media shop
requirement analysis. Section 6 compares the candi-
date aspects with aspects found in an open-source im-
plementation of a media shop system, and proposes
goal aspects as a way of documenting candidate as-
pects for later phases. Section 7 concludes the paper
and sketches directions for future research.
2. Aspect Oriented Programming
An aspect, such as “efficient use of memory” is a
cross-cutting concern for a software system. Dealing
with code fragments that address a single aspec t in
different components of a software system has been a
great challenge for software engineers. Structured De-
sign [24] did recognize the importance of packing com-
monalities into modules. This is also known in pro-

gramming as the DRY principle, that is, “Don’t Repeat
Yourself”. Accordingly, a good design should include
components with high fan-in. Figure 1 and Figure 2
show how structured design and asp ect- oriented pro-
gramming view the factoring out of common concerns
in complementary ways.
A typical asp ec t expressed in AspectJ
1
syntax is as
follows:
aspect DisplayUpdating {
pointcut move():
call(void FigureElement.moveBy(int, int)) ||
call(void Line.setP1(Point)) ||
call(void Line.setP2(Point)) ||
call(void Point.setX(int)) ||
call(void Point.setY(int));
after() returning: move() {
Display.update();
}
}
The aspect DisplayUpdating includes the advice Dis-
play.update() that will be weaved into the component
code after the move() pointcut. A pointcut is a vir-
tual address for the inclusion of the advice in a compo-
nent. This virtual address is resolved through match-
ing. For example, every time a Line.setP1(Point) ap-
pears in a component, the advice, Display.update() will
be weaved in that component.
Figure 1. Don’t repeat yourself (DRY) princi-
ple: increase fan-in.
The great benefit of software structured according
to aspects is the ability to separate issues, Figure 2,
and leave it to a pattern matching procedure to weave
the issues together at the correct time.
Although the original AOP paper [12] pointed out
that as pects are mainly non-functional concerns, there
has been no clear link with the notion of non-functional
requirements. [14, 5, 6] propose that non-functional
1
This example is taken from [10].
Aspect
C
Figure2. An aspect hides the high fan-in com-
mon part from a structured design.
Table 1. Contributions and correlations
link type and or make help hurt break
contrib. Y Y Y Y Y Y
correlat. N N Y Y Y Y
requirements are first class requirements, that is, re-
quirements that are elicited, modeled and analyzed as
the software is developed. We adopt their framework
and show in the rest of the paper how the analysis of
functional and non-functional requirements can lead to
the discovery of aspects.
3. The V-graph model
In order to reason about the interplay of functional
and non-functional requirements we focus on a partic-
ular type of a goal model called a V-graph.
The V-graph is a graph with an overall shape of
the letter V (Figure 3). The top two vertices of the
V represent respectively functional and non-functional
requirements in terms of goal models. Following [14]
we represent non-functional requirements in terms of
softgoals, i.e., goals with no clear-cut satisfaction. Both
models are AND/OR trees with lateral correlation links
(see Table 1
2
). The bottom vertice of the V represent
tasks that contribute to the satisfaction of both goals
and softgoals.
This model allows for the description of intentional
nodes (goals and softgoals), as well as operational ones
(tasks.) Following the NFR framework [5], we name
each goal and task with two descriptors: a type and a
topic. A topic captures contextual information for the
goal/task/softgoal. This contextual information is sim-
ilar to what Zave and Jackson call subject matter [26]
which will determine the designations used to identify
real world objects related to the goals. For instance, in
Figure 7, we have the softgoal Responsiveness (type)
of Transactions (topic). A type for a goal or a task
describes a generic function; while a type for a softgoal
2
In the NFR framework [5], Help/Hurt/Make/Break link
types are an extension to the And/Or trees to allow for the de-
scription of pa rtial orderings among goals.

SoftGoal
Task
Contribution
Goal
Correlation
Contribution
Figure 3. A V shape goal graph links a task
of the goal hierarchy to a softgoal as its op-
erationalization. In the paper, we represent
softgoals in Cloud shape, goals in Octagon
shape and tasks in Hexagon shape.
describes a generic non-functional requirement (quality
attribute), such as p erformance, safety, security, and
traceability. In the V-graph model, topics also confine
the pointcut links between functional goals/tasks and
non-functional softgoals.
Figures 4 depicts two generic decomposition
goal/softgoal hierarchies, with contribution and c orre-
lation links between them.
NFR Type
[system]
NFR SubType1
[system]
AND
NFR SubType2
[system]
AND
Function
[system]
Help
SubFunction1
[system]
AND
SubFunction2
[system]
AND
Sub-Function1
[sub-system1]
Break
Sub-Function1
[sub-system2]
Help Hurt
Sub-Function2
[system]
MakeOR OR Make
Figure 4. Decomposition of the goal and soft-
goals following type and topic taxonomy.
Of course, in order to produce a V-graph we need an
integrated process of elicitation, modeling and analysis.
The focus of this paper is on modeling and analysis,
with the help of a goal analysis tool [9].
4. Building V-graphs and discovering as-
pects
The (manual) process we are proposing constitutes
a systematic way for the refinement of a V-graph. The
process ends when all root goals are satisfied and all
softgoals are satisficed
3
. At this stage, we are able
to identify candidate aspects by identifying tasks that
have a high fan-in. The resulting graph can be further
refined if candidate aspects are grouped into what we
call goal aspects.
The process of building V-graphs is iterative. Dur-
ing each step, the goal analysis tool is used to detect
conflicts and deteriorations. A conflict occurs in a goal
model when a given labeling of leaf goals as satisfied or
denied leads to other goals being labeled both satisfied
and denied. A deterioration occurs when the labeling
of softgoals during one step of the iteration is weaker
(lower) than during the previous step of the iteration.
Below we present the proposed process us-
ing a programming language-like notation.
procedure AspectFinder
input r: node /* root goal */, s: {node} /* softgoals */
output a: {aspect} and g: graph<node, link>
pre-condition {r} ∪ s are named nodes,
a = φ and g =< φ, φ >
post-condtion IsSatisfied(g, r) and IsSatisficed(g, s),
a 6= φ and g 6=< φ, φ >
begin
g ⇐ Correlate(r, s, g)
while (not (IsSatisfied(g, r) and IsSatisficed(g, s))
or NodeToDecompose(g) 6= φ)
g, conflict ⇐ Decompose (g)
if conflict then
g ⇐ ResolveConflict(g)
end while
a ⇐ ListAspects(g)
end
AspectFinder is the root procedure. Some clarifica-
tions are need here:
1. node denotes a graph node, can be a goal, a task
or a softgoal;
2. {node } denotes a set of nodes;
3. { aspect } denotes a set of aspects;
3
Herbert Simon [20] used the term satisfice to denote the idea
of “good enough” solutions to an untractable problem. The NFR
framework [5] is founded on the premise that non-functional re-
quirements (softgoals) are “satisficed” when they admit a partial,
but good enough solution.

Table 2. Combinations of goal labels.
label name satisfice (s), denial(d)
S satisfied s = 1 and d = 0
D denied s = 0 and d = 1
U undetermined s = 0 and d = 0
FS fully satisfice s = 1 and d = 0
PS partially satisfice 0.5 < s < 1 and s + d = 1
UN undetermined s + d < 1
PD partially denial 0 < s < 0.5 and s + d = 1
FD fully denial s = 0 and d = 1
CF conflicting s + d > 1
4. and graph<node, link> is a graph template type
in C++ terminology instantiated with node and
link.
The stop condition for the iteration is defined in
terms of the following predicates:
• IsSatisfied(g, r) tests if a goal r is satisfied in goal
graph g, i.e., returns one of the following labels [9]:
{S, D, U } and IsSatisficed(g, s) tests if softgoal s
is satisficed in the goal graph g, i.e., returns one
of {FS, PS, UN, PD, FD, CF } as explained in
Table 2.
• NodeToDecompose(g) finds out the subset of
nodes of g that are either undetermined or un-
satisfied goals/tasks, or unsatisficed softgoals.
The Correlate procedure is defined as follows.
procedure Correlate
input r: node, s: {node}, g: graph<node, link>
output g: graph<node, link>)
pre-condition g =< φ, φ >
post-condition g =< {r} ∪ s, L > where
L: {link} 6= φ and ∀t ∈ s such that < r, t >∈ L.
begin
for each t in s
g ⇐ AddLink(g, < r, t >) /*correlation link */
end
g ⇐ MarkSatisfied(g, RootGoal(g))
g ⇐ LabelPropagation(g)
end Correlate
Correlate establishes an initial relationship between
root functional goals and softgoals. This relationship is
represented by one or more correlation links. Correlate
uses procedures that are defined below:
• AddLink(g, < n
1
, n
2
>) will place a link between
nodes n
1
, n
2
in g;
• MarkSatisfied(g, RootGoal(g)) w ill mark a ro ot
goal of g satisfied;
• LabelPropagation(g) is an algorithm described
in [9] that propagates the truth labels of the leaf
nodes upward to the top-level nodes according to
the types of goal dependency links.
procedure Decompose
input g: graph<node, link>
output g: graph<node, link>, conflict: boolean
pre-condition g is consistent
post-condition g is consistent, g has more nodes
begin
g
pre
⇐ g
for each t: node in NodeToDecompose(g)
subnodes ⇐ CreateNodes(g, t)
for each s in subnodes
g ⇐ AddNode(g, s)
if not s ∈ NodeToDecompose(g) then
g ⇐ MarkAsTask(s, g)
g ⇐ AddLink(g, < s, t >) /*contribution link*/
end
g, conflict ⇐ CorrelationDecompose(g
pre
, g)
end
end
Decompose refines the V-graph, using the following
procedures:
• CreateNodes creates a set of new nodes in the
graph by the human;
• AddNode(g, s) inserts a s into graph g;
• NodeToDecompose(g) gathers the goals and sub-
goals that have not been decomposed, or dealt
with in terms of a task.
procedure ResolveConflict
input g: graph<node, link>
output g
0
: graph<node, link>
pre-condition g is consistent, g has conflicts
post-condition g
0
is consistent, g has no conflict
begin
g
pre
⇐ g
g ⇐ RemoveConflictingLinks(g)
conflict ⇐ True
repeat
g, conflict ⇐ CorrelationDecompose(g
pre
, g)
until ! conflict
g
0
⇐ g
end

ResolveConflict uses the procedure,
RemoveConflictingLinks(g), that removes links
from a source node that has been labelled ”denied” by
the label propagation algorithm
procedure CorrelationDecompose
input g
pre
, g: graph<node, link>
output g: graph<node, link>, conflict: boolean
pre-condition g
pre
is consistent
post-condition g is consistent
begin
g ⇐ MarkGoalGraph(g,{U, S, D })
while (CorrelationLinkToDecompose(g
pre
) 6= φ
or Deteriorating(g
pre
, g))
l ⇐ GetACorrelationLink(g
pre
, l)
g ⇐ RemoveLink(g, l)
g ⇐ AddLinks(g, CreateLinks(l))
g ⇐ LabelPropagation(g)
end
g, conflict ⇐ LabelPropagation(g)
end
CorrelationDecomposition uses the procedures that
are, briefly, described below:
• MarkGoalGraph(g, ... ) initializes task nodes (as-
sociated to leaf goal nodes) with a satisfied/denied
label specified by the user, and all other goal nodes
as undetermined to facilitate the label propagation
algorithm.
• CreateLinks(l) where l =< r, s > creates new links
between subgoals of r and subsoftgoals of s speci-
fied by the user;
• CorrelationLinkToDecompose looks for all the cor-
relation links except for those from tasks to leaf
softgoals.
procedure Deteriorating
input g
pre
, g: graph<node, link>
output deteriorate: boolean
begin
r
0
, s
0
⇐ RootGoal(g
pre
), Softgoals(g
pre
)
r, s ⇐ RootGoal(g), Softgoals(g)
consistency ⇐ IsSatisfied(g
pre
, r
0
)
and IsSatisfied(g, r) and ∀n ∈ s
0
∩ s:
LessThan(IsSatisficed(g
pre
, n), Is Satisficed(g, n))
deteriorate ⇐ not consistency
end
Within the Deteriorating procedure,
LessThan(label
1
, label
2
) compares two labels ac-
cording to the label order (FD < PD < UN < PS <
FS).
procedure ListAspects(g)
input g: graph<node, link>
output as: {aspect}
pre-condition In the goal graph g, all goals are
satisfied and all softgoals are satisficed.
There is no conflict and all correlation links
are consistently decompose d into contribution
links from tasks to softgoals.
post-condition as 6= φ and
∀a ∈ as ∀f ∈ Pointcuts(a):
((∀t
f
∈ SubGoals(g, f ) ∀t
a
∈ Advices(a):
IsSatisfied(g, t
f
) and IsSatisfied(g, t
a
))
⇒ (IsSatisficed(g, SoftGoal(a)) and IsSatisfied(g, f )))
begin
as ⇐ φ
for each n in Softgoals(g) s uch that
n is the direct parent of a task
a: as pect ⇐ CreateAspect(n)
for each < t, n >∈ Links(g) where t ∈ Tasks(g)
a ⇐ AddAdvice(t, a)
for each f ∈ CrosscuttingGoals(t, g)
a ⇐ AddToPointcuts(f, a)
end
end
as ⇐ as ∪{a}
end
end
ListAspects(g) gathers a set of tasks that contribute
to a softgoal, that is, there is a contribution link <
t, s > and more than one chain of contribution links
{t →, · · · , → f} where t is a task, s is a softgoal, f is
the functional goal crosscutted by t. The semantics of
these goal aspects are specified in the post-condition:
if all the advice tasks t
a
of all the aspects are satisfied
and all the functional tasks t
f
of the pointcut goals
are satisfied, then the softgoal of the aspects are also
satisficed.
Figure 5 shows a pictorial view of the process of
modeling V-graphs. Initially, a set of objectives in-
cluding one or more functional goals and several non-
functional softgoals are listed. Then requirements engi-
neers and domain experts decompose goals (softgoals)
into subgoals (subsoftgoals) or tasks, and correlate the
goals/tasks from the functional p ers pective to the soft-
goals/operationalizations from the non-functional one.
The refinement process must be monotonic (no dete-

riorations) and resolve conflicts through a formal goal
analysis until goals are satisfied and softgoals are sat-
isficed.
Figure 5. Discover aspects during the goal
oriented requirement engineering
5. Analyzing V-graphs to discover as-
pects: An Example
We use the Media Shop example to illustrate the ap-
plication of our procedure. The Media Shop example
has been used in the context of intentional modeling [3]
and is a good e xample to show the interplay of func-
tional and non-functional goals. Through Figures 6 to
11 we show several steps of the AspectFinder process.
Figure 14 presents the final goal model annotated with
labels computed by the goal analysis tool. Finally, the
candidate aspects can be seen in the center-right part
of the final graph
4
, that is, they are the operational-
izations of the softgoals and the relations to functional
goals.
Once we have the elicited information regarding the
goals we can start the process. We start by listing root
goals and softgoals. Later we apply the Correlate pro-
cedure (see Section 3) to add correlation links. Figure 6
shows this for the Media Shop example.
Given this graph, we invoke the LabelPropagation
procedure, which return FS (s=1, d=0) values for all
the nodes. This means that the graph is not deterio-
rating and has no conflicts, as shown in the right part
of Figure 7. Here we export the goal analysis result to
the graphviz tool [8] for the layout.
However, if we decompose the goal above using De-
compose, which propagates correlations through Corre-
4
In Figure 14, they are clearly marked as hexagons with three
peripherie s.
Front
[shop]
Security
[system]
Usability
[ui]
Integrity
[data]
Responsiveness
[transaction]
⇒
Front
[shop]
Security
[system]
Make
Usability
[ui]
Make
Integrity
[data]
Make
Responsiveness
[transaction]
Make
Figure 6. Correlate
Front
[shop]
Security
[system]
Make
Usability
[ui]
Make
Integrity
[data]
Make
Responsiveness
[transaction]
Make
⇒
Front
[shop]
S:1.000,D:0.000
Security
[system]
S:1.000,D:0.000
Make
1.000000+
Usability
[ui]
S:1.000,D:0.000
Make
1.000000+
Integrity
[data]
S:1.000,D:0.000
Make
1.000000+
Responsiveness
[transaction]
S:1.000,D:0.000
Make
1.000000+
Figure 7. Consistent Graph
lationDecompose, as shown in the left part of Figure 8,
this results in a deterioration, since the softgoal Re-
sponsiveness[transaction] becomes partially satisficed
(PS) after decomposition and was previously, in Fig-
ure 7, fully satisficed (FS).
With the feedback provided by the goal analysis
tool, (see Figure 5), the requirements engineer proposes
a different decomposition (Figure 9) which removes the
deterioration.
At the left part of Figure 10 we show a part of the
Media Shop graph where the transaction goals are be-
ing decomposed into two tasks that by the contribution
links are related by “make” and “hurt” to the same
softgoal. The right part of the figure will show the re-
sult of the LabelPropagation procedure. Here we can
see a conflicting label for the softgoal “Responsiveness
[Transaction]”: S=1 and D=0.5.
With this feedback, the requirements engineer is
able to change the graph into a well formed graph, by
removing the links that caused the conflict.
As indicated earlier, Figure 14 is the V- graph for the
Media Shop example
5
. We can now apply the proce-
dure ListAspect presented in Section 3. Table 3 shows
the aspects (the operationalized softgoals, related func-
tional goals, as well as related functional tasks). These
aspects are named after the operationalized softgoal.
5
For space reasons, we only show part of the example.

Table 3. Candidate aspects discovered for Media Shop requirements.
Aspect softgoal Advising task Crossing-cutting functional goals
Responsiveness
[transaction]
SessionCookie
[transaction]
Preparing [cart, product], Checking Out [cart, product, account, stock]
Integrity [data]
DatabaseTable
[transaction]
Checking Out [cart, product, account, stock], Managing [shop], Searching
[shop], Reporting [shop]
Confidentiality
[system]
Password Pro-
tection [account]
Checking Out [cart, product, account, stock]
Info. Flow Secu-
rity [system]
SSL [protocol] Checking Out [cart, product, account, stock], Managing[shop]
Usability [lan-
guage]
Customizing
[English]
Preparing [cart, product], Checking Out [cart, product, account, stock],
Managing [shop], Searching [shop], Reporting [shop]
Usability [font] Infob ox [font]
Preparing [cart, product], Checking Out [cart, product, account, stock],
Managing [shop], Searching [shop], Reporting [shop]
Usability [layout]
Page Layout
[gui]
Preparing [cart, product], Checking Out [cart, product, account, stock],
Managing [shop], Searching [shop], Reporting [shop]
Front
[shop]
S:1.000,D:0.000
Informing
[shop]
S:1.000,D:0.000
AND
Managing
[shop]
S:1.000,D:0.000
AND
Shopping
[shop]
S:1.000,D:0.000
AND
Integrity
[data]
S:1.000,D:0.000
Make
1.000000+
Usability
[ui]
S:1.000,D:0.000
Make
1.000000+
Make
1.000000+
Responsiveness
[transaction]
S:0.500,D:0.000
Help
0.500000+
Security
[system]
S:1.000,D:0.000
Make
1.000000+
Make
1.000000+
Help
0.500000+
Figure 8. Detection of Inconsistent Decompo-
sition of Correlations
6. Discussion
As shown from Table 3, the proposed process was
able to identify candidate aspects. However, how can
we be sure that these candidate aspects that we have
listed are reasonable?
Apart from appealing to common sense, we have
also attempted an evaluation by matching these as-
pects against an open source implementation of the
Media Shop example. The source code is available
at OSCommerce [16], and its core contains about 65
KLOC in PHP.
After running Semantic Designs’ clone detector
Table 4. Cloned aspects in osCommerce
name # of contributing
clone to NFR
messageStack->add($error) 67 InfoBox
require(’application top.php’) 10 SSL
HTMLHead(CHARSET) 64 LangCustom
tep set language 76 LangCustom
get browser language 75 LangCustom
tep draw separator 71 PageLayout
tep image 69 Infobox
tep image button 56 InfoBox
tep session name 80 SessionCookie
tep db query 127 DatabaseTable
tep session register 56 PasswordProtect
(CloneDR) on osCommerce, 463 clone tuples were found
in the source code. Since clone detection can be seen
as a way of pointing out scattered and repeated code,
we looked at these tuples and found out that among
them there were candidate aspects; that is, code that
could have been grouped together and that was scat-
tered through the system. Out of the 52036 LOC un-
der clone detection analysis, 16833 LOC or 19,1% of
the total code are scattered clones [19].
Taking a closer look, we have found that many of the
clones were of non-functional nature and contributing
to the Usability, Security, Integraty and Responsive-
ness softgoals. Table 4 lists 10 of these clones that
could have been implemented as aspects, if we were
using an aspect oriented platform. In the same table
we list the NFR that these aspects would be contribut-
ing to. Here is the demonstration that our proposal,
of finding out aspects early on, does contribute to the
identification of aspects, even if an aspect oriented lan-
guage is not used in the implementation.
It is interesting to note that the goal graphs ob-
tained from the proposed process can be simplified by

Front
[shop]
S:1.000,D:0.000
Informing
[shop]
S:1.000,D:0.000
AND
Managing
[shop]
S:1.000,D:0.000
AND
Shopping
[shop]
S:1.000,D:0.000
AND
Usability
[ui]
S:1.000,D:0.000
Make
1.000000+
Integrity
[data]
S:1.000,D:0.000
Make
1.000000+
Security
[system]
S:1.000,D:0.000
Make
1.000000+
Make
1.000000+
Make
1.000000+
Make
1.000000+
Make
1.000000+
Make
1.000000+
Responsiveness
[transaction]
S:1.000,D:0.000
Make
1.000000+
Figure 9. Decomposition without deteriora-
tion
factoring out candidate aspects, as per Figure 12.
In that sense, we are proposing goal aspects as an
abstraction of aspects, intended to help requirements
engineers with respect to the scalability of their models.
Goal aspects may defined in terms of a syntax such as
that shown below.
goal aspect Responsiveness[transaction] {
pointcut frequentTransaction():
and(Preparing[cart,product]) ||
and(CheckingOut[cart, product, account, stock]);
required () by: frequentTransaction( ) {
SessionCookie[transaction]();
}
}
Here the goal aspect Responsiveness[transaction]
has the advice task SessionCookie[transaction] that
is required by the frequentTransaction() point-
cut. In the description of this pointcut, we will
look for addresses that match the two match-
ing conditions and(Preparing[cart,product]),
and(CheckingOut[cart, product, account,
stock]) . Note that Figure 14 is already a weaved
graph. As such, the description above can be traced.
However, Figure 13 shows the goal graph as if the
above goal aspect was applied. The syntax of goal
aspects clearly needs further research.
Transaction
[cart]
S:1.000,D:0.000
Session
Cookie
[transaction]
S:1.000,D:0.000
OR
Database
Table
[transaction]
S:1.000,D:0.000
OR
Transaction
[account]
S:1.000,D:0.000
OR
OR
Transaction
[product]
S:1.000,D:0.000
OR
OR
Transaction
[stock]
S:1.000,D:0.000
OR
OR
Responsiveness
[transaction]
S:1.000,D:0.500
Make
1.000000+
Hurt
0.500000-
Figure 10. Conflict detection for the softgoal
“Responsiveness [transaction]"
Responsiveness
[transaction]
S:1.000,D:0.000
Transaction
[cart]
S:1.000,D:0.000
Session
Cookie
[transaction]
S:1.000,D:0.000
OR
Database
Table
[transaction]
S:1.000,D:0.000
Transaction
[account]
S:1.000,D:0.000
OR
Transaction
[product]
S:1.000,D:0.000
OR
Transaction
[stock]
S:1.000,D:0.000
OR
Make
1.000000+
Figure 11. Resolving conflicts
7. Conclusions
We have proposed a systematic process whereby as-
pects can be discovered by conducting goal analysis
for a system-to-be. We have demonstrated the pro ce ss
with a case study adopted from the literature, and we
have compared the resulting aspects with those found
in an independently-developed open source solution.
Compared to [21], we are providing a well-defined,
tool-supported process that they assume must be done
by an experienced software engineer. Compared to [17],
we are treating aspects at a higher level of abstraction,
in terms of goals, and doing so in a systematic way
based on formal analysis.
For future research, we plan to investigate further
the notion of goal aspects, especially so in the context
of software reusability, also in reengineering legacy code
to make it aspect-oriented.
Acknowledgement
We thank Dr. Ira Baxter (Semantics Designs) for
the results reported on section 6 regarding the analy-
sis of osCommerce source code. Dr Leite thanks the
Brazilian agency Capes for the support given during
his sabbatical leave at University of Toronto. The au-

Figure 12. Separating aspects advised tasks
from the functional tasks.
Preparing
[cart,product]
S:1.000,D:0.000
Selecting
[item,cart]
S:1.000,D:0.000
AND
Adding[item,cart]
S:1.000,D:0.000
AND
CheckingOut[cart,
product,account,stock]
S:1.000,D:0.000
Clearing
[cart]
S:1.000,D:0.000
AND
Updating
[account,product]
S:1.000,D:0.000
AND
Updating
[product,stock]
S:1.000,D:0.000
AND
Login/Logout
[account]
S:1.000,D:0.000
AND
SessionCookie
[transaction]
S:1.000,D:0.000
Responsiveness
[transaction]
S:1.000,D:0.000
Make
1.000000+
Figure 13. Separating the advicing task of the
goal aspect Responsiveness[transaction] from
the functional goals in its pointcut.
thors wish to thank the referees for their comments.
They have helped to improve the paper.
References
[1] A. I. Anton, R. A. Carter, A. Dagnino, J. H. Dempster, and
D. F. Siege. Deriving goals from a use-case based require-
ments specificatio n. Requirement Engineering, 6(1):63–73,
2001.
[2] D. Bolchini, P. Paolini, and G. Randazzo. Adding hyper-
media requirements to goal-driven analysis. In RE 2003,
pages 127–137, 2003.
[3] J. Castro, M. Kolp, and J. Mylopoulos. Towards
requirements-driven information systems engineering: the
tropos project. Information Systems, 27(6):365–389, 2002.
[4] v. F. C. Chavez, F. A. Garcia, and C. J. P. Lucena.
Tutorial: Desenvolvimento de Software Orientado
a Aspectos” (in Portuguese). In The 17th Brazil-
ian Symposium on Software Engineering SBES,
(http://www.sbbd.fua.br/inenglish/paginaseng/sbes-
tutorials.htm), 2003.
[5] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. Non-
Functional Requirements in Software Engineering. Kluwer
Academic Publishing, 1999.
[6] L. M. Cysneiros, J. C. S. do Prado Leite, and J. de Melo
Sabat Neto. A framework for integrating non-functional
requirements into conceptual models. Requirement Engi-
neering, 6(2):97–115, 2001.
[7] M. S. Feather, T . Menzies, and J. R. Connelly. Relating
practitioner needs to research activities. In RE 2003, pages
352–, 2003.
[8] E. R. Gansner, E. Koutsofios, S. C. North, and K.-P. Vo.
A technique for drawing directed graphs. IEEE TRANS.
SOFTW. ENG., 19(3):214–230, May 1993.
[9] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, and R. Sebas-
tiani. Reasoning with goal models. LNCS, 2503:167–181,
2002.
[10] E. Hilsdale and G. Kiczales. Aspect oriented programming
with AspectJ, xerox parc, http://www.aspectj.org.
[11] H. Kaiya, H. Horai, and M. Saeki. Agora: Attributed goal-
oriented requirements analysis method. In RE 2002, pages
13–22, 2002.
[12] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda,
C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect oriented
programming. LNCS, 1241:220–242, Oct. 1997.
[13] L. Liu, E. Yu, and J. Mylopoulos. Security and privacy
requirements analysis within a so ci al setting. In RE 2003,
pages 151–161, 2003.
[14] J. Mylopoulos, L. Chung, and B. Nixon. Representing
and using nonfunctional requirements: A process- oriented
approach. IEEE Transactions on Software Engineering,
18(6):483–497, June 1992.
[15] J. Mylopoulos, L. Chung, and E. Yu. From object-oriented
to goal-oriented requirements analysis. Communications of
the ACM, 42(1) :31–3 7, Jan. 1999.
[16] pair Networks. oscommerce: Open Source E-Commerce
Solutions, http://www.oscomm erce.c om.
[17] A. Rashid, P. Sawyer, A. M. D. Moreira , and J. Arajo.
Early aspects: A model for aspect-oriented requirements
engineering. In RE 2002, pages 199–202, 2002.
[18] C. Rolland and N. Prakash. From conceptual modelling to
requirements engineering. Annals of S oftware Engineering,
10:151–176, 2000.
[19] Semantics Designs. CloneDR,
http://www.semdesigns.com/products/DMS.
[20] H. A. Simon. The Science of the Artificial, 3rd Edition.
MIT Press, 1996.
[21] G. Sousa, I., and J. Castro. Adapting the NFR framework
to aspect-oriented requirement engineering. In The XVII
Brazilian Symposium on Software Engineering, Manaus,
Brazil, October, 2003, 2003.
[22] A. van Lamsweerde. Goal-oriented requirements engineer-
ing: From system objectives to UML models to precise soft-
ware specifications. In ICSE 2003, pages 744–745, 2003.
[23] A. van Lamsweerde and E. Letier. Handling obstacles in
goal-oriented requirements engineering. IEEE Trans. Soft-
ware Eng., 26(10):978–1005, 2000.
[24] E. Yourdon and L. L. Constantine. Structured Design:
Fundamentals of a Discipline of Computer Program and
Systems Design, 1st ed. Prentice-Hall, 1979.
[25] E. S. K. Yu and J. Mylopoulos. From E-R to A-R –
modelling strategic actor relationships for business process
reengineering. Int. Journal of Intelligent and Cooperative
Information Systems, 4(2–3):125–144, 1995.
[26] P. Zave and M. Jackson. Four dark corners of requirements
engineering. ACM Trans. Softw. Eng. Methodol., 6(1):1–
30, 1997.

Front [shop]
S:1.000,D:0.000
Informing[shop]
S:1.000,D:0.000
AND
Managing[shop]
S:1.000,D:0.000
AND
Shopping[shop]
S:1.000,D:0.000
AND
Reporting [shop]
S:1.000,D:0.000
Reporting[stock]
S:1.000,D:0.000
AND
Reporting[account]
S:1.000,D:0.000
AND
Reporting[product]
S:1.000,D:0.000
AND
Transaction[account]
S:1.000,D:0.000
AND
Transaction[product]
S:1.000,D:0.000
AND
Transaction[stock]
S:1.000,D:0.000
AND
Customization[language]
S:1.000,D:0.000
AND
Infooctagon[font]
S:1.000,D:0.000
AND
PageLayout[gui]
S:1.000,D:0.000
AND
Searching [shop]
S:1.000,D:0.000
Navigating[stock]
S:1.000,D:0.000
AND
Searching[stock]
S:1.000,D:0.000
AND
AND
AND
AND
AND
Managing [product]
S:1.000,D:0.000
Managing [account]
S:1.000,D:0.000
Managing [stock]
S:1.000,D:0.000
Preparing
[cart,product]
S:1.000,D:0.000
Selecting
[item,cart]
S:1.000,D:0.000
AND
Adding[item,cart]
S:1.000,D:0.000
AND
Transaction[cart]
S:1.000,D:0.000
AND
AND
AND
AND
Getting [account]
S:1.000,D:0.000
Customizing [English]
S:1.000,D:0.000
Usability[language]
S:1.000,D:0.000
Make
1.000000+
CheckingOut[cart,
product,account,stock]
S:1.000,D:0.000
Clearing
[cart]
S:1.000,D:0.000
AND
Updating
[account,product]
S:1.000,D:0.000
AND
Updating
[product,stock]
S:1.000,D:0.000
AND
Login/Logout
[account]
S:1.000,D:0.000
AND
AND
AND
AND
AND
AND
AND
AND
PasswordProtection
[account]
S:1.000,D:0.000
AND
SSL[protocol]
S:1.000,D:0.000
AND
SessionCookie
[transaction]
S:1.000,D:0.000
OR
DatabaseTable
[transaction]
S:1.000,D:0.000
OR
OR
OR
AND
AND
AND
AND
AND
AND
AND
AND
AND
AND
AND
AND
AND
AND
AND
OR
Usability[font]
S:1.000,D:0.000
Make
1.000000+
Usability[layout]
S:1.000,D:0.000
Make
1.000000+
Confidentiality[system]
S:1.000,D:0.000
Make
1.000000+
Responsiveness
[transaction]
S:1.000,D:0.000
Make
1.000000+
Integrity[data]
S:1.000,D:0.000
Make
1.000000+
Info.flow Security
[system]
S:1.000,D:0.000
Make
1.000000+
Security[system]
S:1.000,D:0.000
Usability[ui]
S:1.000,D:0.000
AND
AND
AND
Usability[gui]
S:1.000,D:0.000
AND
AND
AND
Figure 14. The evaluation result of the goal model. All goals/tasks are satisfied and all softgoals
and operationalizations are satisficed and there are no conflicts. The tasks hexagon with three
peripheries are identified advising tasks for candidate aspects.