Content uploaded by Dimitri Van Landuyt
Author content
All content in this area was uploaded by Dimitri Van Landuyt on Feb 03, 2014
Content may be subject to copyright.
Domain-driven Discovery of Stable Abstractions
for Pointcut Interfaces
Dimitri Van Landuyt, Steven Op de beeck,
Eddy Truyen and Wouter Joosen
DistriNet, Katholieke Universiteit Leuven
Celestijnenlaan 200A
B-3001 Leuven, Belgium
{dimitri.vanlanduyt,steven.opdebeeck,
eddy.truyen,wouter.joosen}@cs.kuleuven.be
ABSTRACT
The benefits of defining explicit pointcut interfaces in aspect-
oriented applications have been advocated by many. A pointcut in-
terface exposes a set of crosscutting abstract behaviours (as named
pointcut signatures) that multiple aspects in the application can use.
In accordance with the dependency inversion and stable dependen-
cies principles, a pointcut interface should expose only stable ab-
stractions in order to maximally promote its reuse across a family
of applications.
In this paper, we propose a domain-driven architecture method
for designing such stable pointcut interfaces. The method employs
systematic reengineering of use case models to discover stable ab-
stractions that are anchored in the domain model of the applica-
tion. During architecture design, these stable domain abstractions
are mapped to pointcut interfaces. As part of this mapping activity,
the architecture is constrained to ensure that the pointcut interfaces
can be implemented correctly.
We have applied this method in two applications, where we val-
idate that pointcut interfaces can be reused for implementing the
composition logic of different aspects without requiring modifica-
tion to their pointcut signatures. Moreover, the method consistently
yields pointcut interface hierarchies.
Categories and Subject Descriptors
D.2.13 [Software Engineering]: Reusable Software—Domain en-
gineering; D.2.11 [Software Engineering]: Software architec-
tures—Data abstraction, Domain-driven architecture
General Terms
Design, Documentation
Keywords
Domain-driven Architecture, Reusable Pointcut Interfaces, Stable
Domain Abstractions
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
AOSD’09, March 2–6, 2009, Charlottesville, Virginia, USA.
Copyright 2009 ACM 978-1-60558-442-3/09/03 ...$5.00.
1. INTRODUCTION
Aspect-oriented programming enables the modularization and
composition of crosscutting concerns. However, in large-scale
applications the necessary composition logic remains often com-
plex and it would greatly pay off if the composition logic —
traditionally encoded in monolithic pointcut specifications— could
be reused within a single application or across a family of applica-
tions. Monolithic pointcuts are often written with a specific aspect
composition in mind and are highly dependent on low-level details
of the application. This causes any form of reuse to be problematic
at best.
The stable dependencies principle (SDP) and dependency inver-
sion principle (DIP) applied to aspects [37, 14] state that, in order
to maximally promote pointcut reuse, (a) a pointcut should only
depend on abstractions, and (b) the more pervasive a pointcut be-
comes, the more it should depend on abstractions.
Two mechanisms are essential for effective pointcut reuse: (i)
named pointcuts, that is, supplying a pointcut with a suitable name
that describes its intention or meaning; and (ii) abstraction,inthe
sense of key abstractions that reflect concepts in designers’ minds
and communication. Putting both together results in pointcuts that
carry the name of the key abstractions they represent. This en-
ables two-level pointcut design where named pointcuts are used
by a composition pointcut that binds an aspect to the application.
Figure 1 presents the structure of this two-level approach and illus-
trates the different types of pointcut reuse that should be supported.
This idea is not new, its essence has been covered by, for ex-
ample, the pointcut interface from the work of Gudmundson, et
al. [12] and as a part of the crosscutting programming interface
(XPI) from the work of Griswold, et al. [34]. To summarize Gud-
mundson [12]: a pointcut interface is an interface between the base
and the aspects that are applied to it. This interface contains a num-
ber of pointcut definitions that represent abstraction points in the
base. A pointcut interface is maintained together with the mod-
ule that it refers to. To support this idea at the architectural level,
Kulesza, et al. [19] introduce extension join points (EJPs) which
establish a contract between the base and aspectual modules.
Aspect-oriented programming languages provide us with a way
to capture abstractions as named pointcut signatures (a name and
a set of parameters), which are logically grouped into pointcut in-
terfaces. However, no guidelines are available on how to identify
the abstractions that lead to reusable pointcut signatures —Section
6 gives an elaborate account about this lack of guidance. Most
work on this topic is based on a bottom-up approach, where a
useful pointcut is defined in the scope of a specific aspect and is
given a name that best captures its meaning in that specific scope.
Moreover, the parameters of the pointcut signature are typically de-
signed with that single aspect in mind. The pointcut can often not
be reused for another aspect.
We therefore explore and study the value of a top-down approach
that is based on an architecture creation process, during which
all known and relevant crosscutting concerns are reasoned about.
Moreover, as a second guiding principle, we expect that the sta-
bility of the pointcut signatures will considerably improve if their
definition is based on stable domain abstractions. Stable domain
abstractions are fundamental concepts in the application domain
that change slowly [32].
The main contribution of this paper is twofold: (1) We introduce
a method for the discovery of domain abstractions by systemati-
cally reengineering use cases. (2) We define a method for the map-
ping of these domain abstractions to reusable pointcut interfaces at
the level of architecture. As part of this mapping activity, the archi-
tecture is constrained to ensure that the pointcut interfaces can be
implemented correctly.
2. Reuse of aspect
compositions
Base
pi
Aspect
3. Reuse within pointcut
interface hierarchies
Base
pipi
pi
existing
new
gray reuse
pointcut
interface
pi
1. Reuse of existing pointcut
interfaces
Base
pi
Aspect New Aspect K
E
Y
Figure 1: Types of pointcut reuse.
Additionally, we have applied the proposed method in two ap-
plications, where we validate that pointcut interfaces can indeed be
reused for implementing the composition logic of different aspects
without requiring modification to their pointcut signatures. To this
end, we distinguish between three types of pointcut interface reuse
(as illustrated in Figure 1):
1. Reuse of existing pointcut interfaces. This type of reuse occurs
when a new aspect is introduced that can be composed with
the application in terms of already-existing pointcut interfaces,
either fully or partially. Diagram 1 in Figure 1 illustrates this
type of reuse graphically.
2. Reuse of aspect compositions. This type of reuse occurs when a
new requirement is added that affects an already-existing cross-
cutting concern. Reuse is successful when the new require-
ment can be supported by re-implementing an existing point-
cut interface, without breaking the pointcut signatures. The re-
implementation typically involves expanding the pointcuts to a
larger join point set in the base application. This type of reuse is
illustrated in diagram 2 of Figure 1.
3. Reuse within pointcut interface hierarchies. This type of reuse
occurs when the pointcut interfaces themselves are structured
hierarchically; i.e. the implementation of high-level pointcut in-
terfaces is done in terms of lower-level ones. This structuring
avoids unnecessary duplication of pointcut interface specifica-
tions, and whenever the implementation of a lower-level point-
cut changes, the higher-level pointcut reuses this change at no
extra cost. Figure 1 illustrates this type of reuse in diagram 3.
Our domain-driven architecture method is situated at the tran-
sition between requirements elicitation and architecture creation.
This work is related to various Early Aspects [4] approaches that
map aspectual requirements to architecture. The most relevant ap-
proaches in this space include COMPASS [7], Goal-Driven Discov-
ery of Aspects [27], Theme [8], Jacobson’s AOSD with Use Cases
approach [15] and Aspect-Oriented Architecture Models (AAM)
[10]. The main and common goal of all the above Early Aspects ap-
proaches is achieving improved aspect traceability across the soft-
ware life cycle and supporting trade-off analysis [30, 27] for con-
flicting requirements. The proposed architecture method is comple-
mentary to these approaches as we focus on the discovery of stable
abstractions for aspect-oriented architecture and composition, start-
ing from the requirements.
The remainder of the paper is structured as follows. Section
2 introduces the starting points for this paper, whereas Section 3
presents a high-level overview of the proposed method. In Section
4, a detailed application of the method is illustrated by means of
an example from one of the case studies. Then, Section 5 sum-
marizes our findings with respect to the actual reusability of the
discovered pointcut interfaces, based on two case studies in which
the approach has been applied. Related work is presented in Sec-
tion 6. Finally, Section 7 concludes the paper and presents future
work.
2. STARTING POINTS
In this section, we introduce the methodological starting points
for our approach. Section 2.1 introduces stable domain abstractions
and discusses domain stability. Section 2.2 discusses how use cases
are engineered to improve separation of concerns. Finally, Section
2.3 introduces the Twin Peaks model, to which our approach ad-
heres.
2.1 Stable Domain Abstractions
Sommerville [32] defines stable domain abstractions as “funda-
mental concepts in the application domain that change slowly”. In a
realistic development setting, the problem domain is often the only
common ground between the different developers and therefore,
stable domain abstractions form an important means of communi-
cation between the different members of the development team. In
domain-driven design [9], the set of stable domain abstractions is
called a ubiquitous vocabulary.
Additionally, the use of stable domain abstractions has been
linked to effective reuse in literature [32, 24]; i.e. in a component-
based context, components implementing a stable domain abstrac-
tion are more likely to be reusable. Literature shows that for several
often-recurring concerns, the search for stable domain abstractions
has indeed converged. Such concerns are infrastructural in nature,
such as transaction handling, caching and security. For instance,
the EJB 3.0 standard introduces a set of annotations which are used
to bind aspects to an application, and are reusable across applica-
tions.
In this paper, we propose an approach to discover stable domain
abstractions, and leveraging their stability to build pointcut inter-
faces that are resilient to evolution. Therefore, the starting point
is absolute domain stability; i.e. the situation where the domain it-
self remains fully stable when requirements change. Obviously,
absolute domain stability is an unrealistic condition in real-world
REQUIREMENTS ENGINEERING
2. Identify & Separate
crosscutting concerns
in use cases
3. Generalize
crosscutting use case
extend-relationships
4. Define discovered
domain abstractions
1. Define Domain
Model and Use Cases
ARCHITECTURE DESIGN
5. Architectural design
using domain
abstractions
6. Specify Pointcut
Interfaces based on
domain abstractions
7. Compose aspects
through pointcut
interfaces
abstraction
mismatch
initial
final
[no]
[yes]
(constrain architecture)
KEY
transition
activity
PHASE
decision
Figure 2: Overview of the method.
problem domains, as it is impossible to take into account all pos-
sible future changes in a software system. Section 5 investigates
practical reuse in two realistic case studies, and their relation to do-
main stability. We show that reuse improves in any case, and that
reuse seems to be more optimal in the context of a stable problem
domain.
2.2 Use Cases and Aspects
We propose a use case-driven approach to find stable domain
abstractions by reengineering use case diagrams.
Part of the approach deals with the separation of base use cases
and extension use cases. Use case extension [15] is a use case rela-
tionship that is well-suited for this purpose. Introducing this rela-
tion requires explicitly naming extension points to be defined by the
base use cases. One common pitfall in specifying extension points
is naming them after the aspects that affect them. This approach in-
herently suffers from the problem of concern diffusion: the base is
affected in a crosscutting manner by the aspects. Instead, extension
points should be used to expose additional information specific to
the base concern, regardless of any specific aspect. This is exactly
what our architecture method advocates.
Our approach introduces a use case hierarchy, in which abstract
use cases represent commonalities between use cases. However,
the UML specification is not clear on the semantics of an exten-
sion point in an abstract use case. To avoid confusion, we attribute
the following semantics to extension point inheritance: the abstract
use case provides a common frame (segment of abstract steps) in
which all child use cases must be structured. In this frame, an ex-
tension point is defined. Child use cases implementing this frame
automatically inherit the extension point. This way, an extension
point denotes a step that is common to all child use cases.
2.3 Twin Peaks model
Our architecture creation approach adheres to the Twin Peaks
model to Software Engineering [28]. This model represents an
incremental software development process which spirals between
requirement analysis and architecture design. Developers alterna-
tively iterate over system requirements and architecture design in
quick succession, developing the application’s requirements and
architecture specifications concurrently. For reasons of simplicity,
Figure 2 outlining the approach does not depict this explicitly. At
any point in time, the software engineer might backtrack to one of
the requirement activities.
Table 1: Input and output artifacts per activity.
Artifacts
Act. Input Output
1
stakeholder requirements,
domain analysis, techni-
cal/legal constraints, . . .
use cases, domain models
2use cases separated use cases; exten-
sion points
3separated use cases; exten-
sion points
generalized use cases; ab-
stract extension points
4abstract extension points;
domain models domain abstractions
5
use cases; domain mod-
els; domain abstractions;
existing component-based
architecture (optional)
(constrained) component-
based architecture
6
component-based ar-
chitecture; domain
abstractions
component-based ar-
chitecture with pointcut
interfaces
7
component-based ar-
chitecture with pointcut
interfaces
component-based ar-
chitecture with pointcut
interfaces and aspectual
compositions
3. OVERVIEW OF THE METHOD
This section briefly introduces the proposed approach. Figure 2
presents an activity diagram showing the sequence of steps to be
performed. It depicts how the approach guides the software engi-
neer throughout seven activities to discover and design an architec-
ture that is centered around reusable pointcut interfaces. Addition-
ally, Table 1 presents the input and output artifacts for each activity.
The approach shows similarities to the “AOSD with Use Cases
Approach” by Jacobson [15]. In activity 1, the requirements are
gathered and modeled in a structured way, as use cases. Addition-
ally, as our approach is domain-driven, a domain model for the
application is defined in parallel.
In activity 2, the identification of crosscutting concerns takes
place starting from the use case models. A variety of approaches
have been proposed in literature [3, 13] that can be employed for
this activity. Once the identification of crosscutting concerns is
considered to be finished, the use cases are reengineered so that
each use case is affected by at most one concern. The Use Case
Approach allows to model this separation as an extension use case
that is connected by an extend-relationship to an extension point in
the extended (base) use case.
Activities 1and 2are comparable to existing proposals and prac-
tices. The subsequent activities (3,4) are essential and specific to
our approach. The reengineering effort, from activity 2, typically
results in highly coupled use case models, where the implicit rela-
tions between an extension use case and the multiple base use cases
it affects, are made explicit. This explicitation is done for each ex-
tension use case. The goal of activity 3is to generalize these use
case models in order to reduce coupling. It results in multiple use
case hierarchies of which the roots are abstract use cases with gen-
eralized extension points. These generalized extension points form
the first indication for finding stable domain abstractions for cross-
cutting concern composition. Selecting a name for a generalized
extension point involves paying ample attention to finding the do-
main abstraction that best describes the semantics of the extension
point in question. The guiding principle is that the domain abstrac-
tions should be anchored in the domain model.
Activity 4is the final requirements engineering activity in our
approach. During this activity, the generalized extension points are
used to define domain abstractions. This definition contains a name
and references to other domain concepts that are required for the
particular composition-context: the contextual information.
In activity 5, the first architectural design activity, the architec-
ture is created (in fact the component-and-connector view) with the
earlier-defined domain abstractions in mind. These domain ab-
stractions constrain the design of software components and their
interfaces to ensure that these artifacts remain compatible with the
domain abstractions. This contrasts with the AO Use Case ap-
proach of Jacobson, et al., where a base architecture is defined
without taking crosscutting concerns into account. In our approach,
the domain abstractions ensure that the architectural design takes
crosscutting concerns into account from its initial inception.
The previous activity, ensuring compatibility between domain
abstractions and architecture, is important for the next activity (ac-
tivity 6), where domain abstractions are mapped to pointcut inter-
faces. A pointcut interface has a scope that is limited to a module in
the architecture (typically component, or a set thereof). It captures
the artifacts in this module that match the specific domain abstrac-
tion; i.e. the named abstraction and the contextual information. In
case a mismatch between an abstraction and the initial architecture
prohibits the correct specification of this pointcut interface, the pre-
vious activity (activity 5) has to be repeated. Once the abstraction
mismatch is corrected, the pointcut interface specification can be
completed (repeat of activity 6).
In the final architecture design activity (activity 7), aspectual
compositions are specified in terms of the pointcut interfaces, lever-
aging upon state-of-the-art aspect-oriented architectural description
languages (ADL’s).
4. DETAILED DESCRIPTION AND ILLUS-
TRATION
This section presents a detailed explanation of the seven activ-
ities of the approach. At the same time, these different activities
are illustrated in a running example. The final paragraph presents
a closer look at the activities at the transition from requirements to
architecture.
4.1 Define Domain Model and Use Cases
Throughout this section, the E-Finance Banking System [21, 23]
serves as running example. Although somewhat pedagogical in na-
basic banking system
show account information
show customer information
create new customer
transfer
deposit
withdraw
block customer account
close a savings account
open a savings account
open a current account
close a current account
Customer
Bank Clerk
Figure 3: Use case diagram providing an overview of the basic
banking services.
UseCase1 Transfer between two accounts
•Primary actor: Bank clerk or Customer
•Basic flow:
1. The actor indicates he wants to transfer money.
2. The system asks for the source account.
3. The actor selects the source account.
4. The system asks for the destination account.
5. The actor enters the destination account.
6. The system asks for the amount to transfer.
7. The actor enters the amount.
8. The system verifies the balance of the source account.
9. The system asks to sign the transfer.
10. The actor signs the transfer.
11. The system checks the signature for validity.
12. The system processes the transfer.
•Alternative flow:
8b If the account balance is insufficient, the transaction is can-
celed.
11b If the provided signature is invalid, the transaction is can-
celed.
ture, it covers a sufficiently large requirements space to be repre-
sentative for a realistic application.
Activity 1consists of diverse requirements gathering and engi-
neering efforts such as interviewing the stakeholders, investigating
current state-of-the-art and -practice in the field, taking into account
several (legal, technical) constraints, detailed domain analysis with
domain experts, and so on.
For the E-Finance system, the result of activity 1consists of (i)
more than fifty coarse-grained use cases (functional requirements),
(ii) non-functional requirements such as security, performance and
availability, described in quality scenarios [6], and (iii) the domain
models resulting from domain analysis.
Figure 3 presents a subset of the basic banking use cases. In
these use cases two distinct actors interact with the system: the
bank clerk and the customer. As part of the basic banking services,
the bank clerk is given the ability to create customer accounts and
inspect customer information. The customer in turn is allowed to
open and close accounts via the bank clerk. Both actors are able to
perform financial transactions such as money transfer, withdrawal,
and deposit.
In Use Case 1, a trimmed version of the transfer between two
accounts use case is presented. This use case is used as running
example throughout the paper.
Figure 4 presents a subset of the domain model for the E-Finance
case study. A domain model represents a conceptual model which
describes the various entities involved in the system and their rela-
tionships.
name
Person
Bank Clerk Customer
adapts
owns
account number
balance
Bank Account
Current
Account
Savings
Account
associated with
creates
*
1..*
1
*
*
*
0..* 1
amount
Transaction
Transfer Withdrawal Deposit
performs
*
*
closes
Figure 4: Subset of the E-Finance domain models.
4.2 Identify and separate crosscutting con-
cerns
In the second activity, crosscutting concerns are identified in the
use cases from previous activity. Thereafter, these use cases are re-
organized, so that each use case is affected by at most one concern,
a process called separation.
Identification of crosscutting concerns.
This sub-activity involves the identification of crosscutting con-
cerns; i.e. concerns that affect several use cases. In use cases, cross-
cutting concerns can be identified by: (i) looking for recurring or
duplicated steps across use cases, or (ii) paying specific attention to
inclusion or extension relationships between use cases, as they rep-
resent interdependencies. As already stated in Section 3, existing
aspect-oriented use case approaches can be adopted for implement-
ing this identification process.
In the E-Finance use cases, the following crosscutting concerns
were identified:
Balance verification. This concern handles verification that the
balance of a bank account complies a certain constraint before ex-
ecuting a transaction. This business logic is triggered both at the
closure of current and savings accounts to check if the final balance
is zero, and at deposit, withdrawal and money transfer between ac-
counts to check if the current balance is sufficient. In the example
of Use Case 1, step 8 and its alternative step 8b, both belong to this
crosscutting concern.
Agreement signing. When executing certain actions, the main ac-
tor is asked to confirm by signing a legally binding agreement with
the bank. This happens when current and savings accounts are
opened and closed, when the bank clerk blocks an account and
when money is deposited, transferred, and withdrawn. In the ex-
ample of Use Case 1, steps 9 to 11, as well as step 11b are specific
to this concern.
Separation of crosscutting concerns.
Next, the use cases are reorganized so that each use case de-
scribes at most one concern. A new extension use case is intro-
duced for each set of recurring or duplicated use case steps. Next,
these extension use cases are related back to the base use cases by
means of the extend relation. In Use Case 2, the result of separat-
ing the crosscutting concerns in Use Case 1 is presented. During
this process, one extension point is introduced pointing to step 8, as
this is exactly the step at which the system must process the money
transfer. For that reason, it is named money transfer. At this exten-
sion point, the use case is extended by the extension use case sign
an agreement, which is presented in Use Case 3.
The full use case diagram after separating crosscutting concerns
is presented in Figure 5. This diagram depicts both the base use
cases and the extension use cases —sign an agreement (dark gray)
and verify account balance (light gray)— together with the exten-
sion relations between them.
UseCase2 Transfer between two accounts
•Primary actor: Bank clerk or Customer
•Basic flow:
1. The actor indicates he wants to transfer money.
2. The system asks for the source account.
3. The actor selects the source account.
4. The system asks for the destination account
5. The actor enters the destination account
6. The system asks for the amount to transfer.
7. The actor enters the amount.
8. Extension point: money transfer. The system processes the
transfer.
UseCase3 Sign an agreement
•Primary actor: Bank clerk or Customer
•Extends:
–open a current account at open current account.
–close a current account at close current account.
–open a savings account at open savings account.
–open a savings account at close savings account.
–block customer account at block account.
–withdraw at money withdrawal.
–deposit at money deposit.
–transfer at money transfer.
•Basic flow:
1. Thesystemaskstosignanagreement.
2. The main actor signs the agreement.
3. The system checks the provided signature for validity.
•Alternative flow:
3b If the provided signature is invalid, the use case has failed.
Bank Clerk
basic banking system
show account information
show customer information
create new customer
verify account balance
sign agreement
close a savings account
Extension Points
EP_4:close_savings_account
open a savings account
Extension Points
EP_3:open_savings_account
open a current account
Extension Points
EP_1:open_current_account
close a current account
Extension Points
EP_2:close_current_account
<< extend>>
<< extend>>
<< extend>>
<< extend>>
<< extend>>
<< extend>>
transfer
Extension Points
EP_8:money_transfer
<< extend>>
<< extend>>
block customer account
Extension Points
EP_5:block_account
<< extend>>
withdraw
Extension Points
EP_6:money_withdrawal
<< extend>>
<< extend>>
Customer
deposit
Extension Points
EP_7:money_deposit
<< extend>>
<< extend>>
Figure 5: Use case diagram providing an overview of the basic
banking services after separating the crosscutting concerns.
4.3 Generalize crosscutting use case extend-
relationships
After previous activity, the crosscutting concerns are represented
modularly (see Figure 5). However, the increased modularity
clearly comes at the cost of maintainability and reusability. More
specifically, a large set of extension points is introduced —one per
base use case— at which the extension use cases extend the base.
As a result, a high degree of coupling between base and extension
use cases is introduced.
This complexity originates from the requirements themselves: it
manifests itself differently depending on the particular modulariza-
tion that was chosen, yet it inherently is problem space complexity.
Therefore, removing this complexity is not the goal, managing it
more efficiently, however, is. More specifically, this approach en-
ables to better manage the complexity through the introduction of
reusable abstractions.
To discover abstractions suitable for this purpose, the base use
cases are placed in a generalization hierarchy. This leads to the
introduction of several abstract use cases. This process is driven
by the search for commonalities in the base use cases. For the use
cases extended by the sign an agreement extension use case, the
commonality is that they all adapt the customer’s bank accounts
(creation, closure, money transfer, etc). As a result, a specialization
hierarchy is introduced, with from top to bottom: the abstract adapt
an account use case (Use Case 4), the abstract perform a transac-
tion use case (Use Case 5) and the transfer between two accounts
use case (Use Case 6).
UseCase4 [abstract use case] Adapt an account
•Primary actor: Bank clerk or Customer
•Basic flow:
1. [abstract] The actor indicates he wants to adapt an account.
2. The system asks for the account to adapt.
3. The actor selects an account.
4. [abstract] The system asks for the additional information.
5. [abstract] The actor enters the additional information.
6. Extension point: account adaptation. [abstract] The sys-
tem performs the adaptation.
UseCase5 [abstract use case] Perform a transaction
•Specializes: Adapt an account (Use Case 4)
•Primary actor: Bank clerk or Customer
•Basic flow:
1. [abstract] refines parent step 1. The actor indicates he wants
to perform a transaction.
2. Specialize step 2 The system asks for the source account.
3. As parent step 3.
4. As parent step 4.
5. As parent step 5.
6. Extension point: balance change. [abstract] The system
processes the transaction.
In Use Case 7, the extension use case sign an agreement extends
the abstract use case adapt an account at the newly-introduced ex-
tension point account adaptation. Similarly for the balance veri-
UseCase6 Transfer between two accounts
•Specializes: Perform a transaction (Use Case 5)
•Primary actor: Bank clerk or Customer
•Basic flow:
1. Impl. step 1. The actor indicates he wants to transfer money.
2. As parent step 2.
3. As parent step 3.
4. Impl. step 4. The system asks for the destination account.
5. Impl. step 5. The actor enters the destination account
6. Impl. step 5. The system asks for the amount to transfer.
7. Impl. step 5. The actor enters the amount.
8. Impl. step 6. The system processes the money transfer.
UseCase7 Sign an agreement.
•Primary actor: Bank clerk or Customer
•Extends:
–adapt an account at account adaptation.
•Basic flow:
1. Thesystemaskstosignanagreement.
2. The actor signs the agreement.
3. The system checks the provided signature for validity.
•Alternative flow:
3b If the provided signature is invalid, the use case has failed.
fication concern, the use cases to perform a transaction, open and
close an account are grouped together, albeit deeper in the inheri-
tance hierarchy. Figure 6 presents the resulting use case diagram.
Comparing this diagram to Figure 5, it becomes clear that the
high coupling between base and extension use cases is represented
in a more maintainable manner. Furthermore, the extension use
cases are coupled to abstract concepts rooted in the problem do-
main.
4.4 Define domain abstractions
The main result of the previous activities is the identification of
commonalities in the base use cases, represented by abstract exten-
sion points. However, at this moment an extension point is merely
a label to a (set of) location(s) in a use case. In this activity, stable
domain abstractions are defined from these extension points. The
key characteristic of these definitions is that they are fundamentally
anchored in the domain model, i.e. they are presented in terms of
key concepts in the problem domain.
A domain abstraction is defined by name, textual description,
contextual information, and potential relations to other domain ab-
stractions.
Contextual information is additional information associated to a
domain abstraction, which is extracted from the domain model as
well. One way to discover it is by explicitly specifying the com-
position between base and extension use cases, using a use case
pointcut language such as AspectU [31]. This involves specify-
ing use case-level pointcuts and employing context passing mech-
anisms between the use cases to explicitize which type of infor-
mation must be accessible to the extension use case. Due to space
constraints, we do not elaborate on this further. In the case of the
running example, the contextual information associated to the ac-
count adaptation domain abstraction consists of the bank account,
Customer
basic banking system
show account information
perform transaction
Extension Points
EP_3:balance change
close account
Extension Points
EP_2:account closure
verify account balance
sign agreement
transfer
deposit
withdraw
block customer account
close a savings
account
open a savings
account
open a current
account
close a current
account
open account
Extension Points
EP_1:account creation
<< extend>>
<< extend>>
adapt account
Extension Points
EP_1:account adaptation
consult account
<< extend>>
Bank Clerk
Figure 6: Use case diagram providing an overview of the basic
banking services after the generalization step.
account adaptation
•Specialized by: account closure,account creation,bal-
ance change.
•Description: This domain abstraction is used to denote an
adaptation to a bank account.
•Contextual information: the person that performs the
adaptation (either the bank clerk or the customer), a
reference to the bank account that is closed, and the
bank account type.
Figure 7: The definition of the account adaptation domain
abstraction. Underlined words denote contextual information.
the bank account type, and the person performing the adaptation
(either a bank clerk or a customer), as presented in Figure 7.
All domain abstractions are placed into a domain abstraction in-
ventory which is considered an integral part of the requirements
documentation. In further activities (see Section 4.6), the domain
abstraction inventory is used to specify pointcut interfaces in a con-
crete software architecture.
4.5 Architectural design using domain ab-
stractions
This activity either starts with a pre-existing initial architecture,
or with the design of an architecture. For this, a state-of-the-art
software architecture methodology is employed, such as Attribute-
Driven Design [6]. The core activity in software architecture design
is the introduction of a decomposition; i.e. dividing the system in
software modules such as classes or software components. The
end result is a software architecture that fullfills all requirements
—functional and non-functional— and covers the problem domain.
Our approach extends this by constraining the software architect
during architectural design so that the domain abstractions can in
fact be implemented. In some cases, this implies that the architect
must explicitly expose additional context information through the
component interfaces.
Also, to ensure correctness of the compositions between aspect
and base modules, it is during this activity that design rules [34, 19]
would be defined by the software architect. However, these are out
of scope of this paper.
4.6 Specify pointcut interfaces
During this activity, the domain abstractions are mapped to
pointcut interfaces. To achieve this, the used architecture descrip-
tion language (ADL) must support aspect-oriented compositions.
Therefore, an aspect-oriented architecture approach is adopted. In
this paper, we employ the AO-ADL [29].
As an alternative to the classical component interface, the point-
cut interface is introduced. Indeed, not unlike the classical inter-
face, the pointcut interface exposes the component’s internals to the
outside world. The representation we adopted for this is the UML
lollipop stereotyped with pointcut interface (in short p.i.). This rep-
resentation is shown in Figure 8. Note that a pointcut interface can
be associatedtoany classifier (class, package, ...). However, due
to our choice for a component-based architecture methodology in
the running example, the pointcut interface will be associated with
software components.
The specification of a pointcut interface comprises a set of named
pointcuts. The pointcut parameters originate directly from the con-
textual information associated to the domain abstraction. For the
running example, we have adopted the AspectJ syntax to specify
the named pointcut in architecture. The pointcut interface is pre-
sented in Listing 1. The pointcut signature matches exactly the
contextual parameters of the account closure domain abstraction
that was presented in Figure 7.
public cla ss AccountAdaptation {
public poin tcut accountAdaptation ( User u ,
Account acct , AccountType at ) :
accountCreation (u , acct , at )
| | accountClosure (u , acct , at )
| | balanceChange (u , acct , at )
| | ca ll ( IBasicB anking . blockAccount
( User u , Account acct , AccountType at )
&& args ( u, acct , at ) )
}
Listing 1: Definition of the account adaptation pointcut inter-
face
During this activity, it might occur that the initial architecture
fails to expose sufficient information to specify the pointcut inter-
face correctly. This phenomenon is called abstraction mismatch.
As a result, it may be required to repeat the architectural design
phase, as part of activity 5(see Section 4.5).
4.7 Compose aspects through pointcut inter-
faces
Finally, the pointcut interfaces are used to define compositions.
In the E-Finance case study, we have used the AO-ADL [29] to
specify AO compositions. The idea is that there is no specialized
component element for representing aspectual behaviour, how-
ever, there is a specific aspect-oriented connector for representing
aspect-oriented composition logic as first-class entity. This is not a
mandatory choice, as other aspect-oriented architecture techniques
could be employed as well. This is elaborated further in Section 6.
Figure 8 presents an excerpt of the component-and-connector
view of the resulting AO architecture. It illustrates one AO connec-
tors, named sign agreement. It binds the pointcut interface account
adaptation to the User Agreement Manager, responsible for creat-
ing an agreement and requesting the user to provide a signature. An
AspectJ notation for this connector is presented in Listing 2.
pub lic as pect SignAgreement {
bef ore ( Us er u sr , Account acct , AccountType at ) :
accountAdaptation ( usr , acct , at ) {
lookUpAgreementManag er () .
requ estSig natur e (usr , acct );
}}
Listing 2: The Sign Agreement connector in AspectJ.
AO architecture
Basic
Banking <<p.i.>> Account Adaptation
pointcut accountAdaptation( User u, Account acct, AccountType at )
Account Adaptation (Person, Bank Account, Account Type)
domain abstractions
use cases domain models
Bank
Account
Savings
Account
Current
Account
*
*
Person
context info
pointcut signature
name
pointcut signature
Figure 9: The transition from requirements to architecture.
4.8 Transition from requirements to architec-
ture
This section provides a detailed zoom-in at the transition from
requirements to architecture. We present an operational view of
this transition process by giving a procedure of how to perform
the activities involved (activities 4to 6). Figure 9 illustrates the
main artifacts involved in these activities. At the top of this figure,
the use case diagram (left) represents the set of use cases that result
from activity 3, and the domain model (right) represents the domain
models that are created in activity 1.
Activity 4: for each abstract extension point in the base use
case hierarchy (as defined in activity 3):
•Specify and analyze the required data flow between the base
use case and the extension use cases at the extension point
(e.g. by using a use-case level pointcut language).
•Derive the required context information from the resulting
data flow requirements.
•Create a domain abstraction which is named after the ab-
stract extension point, and is related to the context informa-
tion derived in the previous step.
The resulting domain abstraction specification is presented in
the middle of Figure 9.
Figure 8: Subset of architecture for the E-Finance basic banking services.
Activity 5:either start from an existing architecture, or create an
initial architecture using a state-of-the-art architecture method.
During this activity, for each domain abstraction:
•Verify whether the current set of component interfaces ex-
poses the required contextual information.
•If not, extend or modify the existing component interfaces
to do so.
Activity 6: for each domain abstraction:
•Create a pointcut interface consisting of a poincut named
after the domain abstraction. Add pointcut parameters to
match the contextual information associated to the domain
abstraction.
•If the architecture does not expose sufficient information
(abstraction mismatch), go back to activity 5(see Figure 2).
•Add the resulting pointcut interface to the suitable compo-
nent(s).
The resulting pointcut interface is presented at the bottom of
Figure 9.
5. EXPERIENCE WITH THE METHOD
We have applied the approach in two distinct case studies in
which we evaluate how many pointcuts are effectively reusable
over the course of system evolution. In both cases, we start from
an existing development iteration in which the approach is applied
to discover domain-anchored pointcut interfaces. Then, a second
development iteration is adopted, introducing a substantial set of
additional requirements, and the approach is re-applied. Finally,
we assess effective reuse, clearly distinguishing between the three
types of reuse as introduced earlier in Section 1.
E-Finance. This case study has been introduced in Section 4.
A second development iteration has been performed, introducing
new use cases into the case study adding investment services to the
already-existing basic banking services.
Digital Publishing. Next to the E-Finance case study, we have
also applied the approach to develop a digital news publishing plat-
form [22]. Different from the E-Finance case, this case study starts
from an existing component-based object-oriented system, which
is re-factored using our approach to discover suitable pointcut in-
terfaces. Then, a second development iteration is adopted, in which
requirements are added. In this case, the evolution scenario repre-
sents a fundamental shift in the news publishing domain: starting
from a classical news broadcasting (one-to-many) scheme, the sys-
tem is adapted to support point-casting (a one-to-one scheme), by
personalizing news editions to the end user’s preferences.
Table 2 presents some facts and figures about both case studies.
The first part of the table presents some figures to indicate their
size and complexity. The second part of the table shows the relative
Table 2: Main facts and figures from case studies.
Case study E-Finance Dig. Publishing
Iteration IIIIII
# use cases 13 28 16 31
# crosscutting concerns 2437
# domain abstractions 46712
Total person months 34.5
Person hours applying
the approach
55 116
amount of time needed to apply the approach in these case studies1.
More information about both case studies can be found at [22, 23].
Summary of Observations.
1. Reuse of existing pointcut interfaces.
This type of reuse occurs when a new aspect is introduced that
can be composed with the application in terms of already-existing
pointcut interfaces, either fully or partially.
In the E-Finance case study, two crosscutting concerns were
added: age verification and fraud detection. Wewereabletocom-
pose all aspects to the base by uniquely relying on the earlier-
defined pointcut interfaces. One example is the age verification
concern, which dictates that whenever an account is opened, the
age of the legal holder has to be verified. In this example we were
able to effectively reuse the account creation pointcut interface,
exactly as it was defined in the first development iteration.
In the digital publishing case study, four system-level crosscut-
ting concerns were added. For two of these, we were able to en-
tirely specify the composition in terms of pointcut interfaces that
were defined in the first development iteration. Interestingly, in the
cases where we were forced to introduce new pointcut interfaces
for aspect composition, the newly introduced domain abstractions
were unrelated to the already-existing domain abstractions.
2. Reuse of aspect compositions.
This type of reuse occurs when a new requirement is added that
affects an already-existing crosscutting concern. Reuse is success-
ful when the new requirement can be supported by re-implementing
an existing pointcut interface, without breaking the pointcut sig-
natures. The re-implementation typically involves expanding the
pointcuts to a larger join point set in the base application.
This type of reuse was most prominent in the E-Finance case
study. For example, the new investment services introduced a
new account type: the custody account. Because of this, the ac-
tual implementation of the account closure pointcut interface was
adapted, without needing to break the pointcut signature.
1We estimate 30 minutes of work per versioning system commit.
In the digital publishing system, we experienced this type of
reuse as well, albeit to a lesser degree. For example, in the first
iteration, a pointcut interface named user-system interaction was
introduced. This pointcut interface matches to the set of operations
callable by an untrusted user. In the first iteration, is was used to
compose the authentication aspect to these operations. In the sec-
ond iteration, the number of methods callable by untrusted users
increased drastically. Triggered by this evolution, the implementa-
tion of this pointcut interface was adapted, but its signature was not
broken.
3. Reuse within pointcut interface hierarchies.
This type of reuse occurs when the pointcut interfaces them-
selves are structured hierarchically; i.e. the implementation of high-
level pointcut interfaces is done in terms of lower-level ones. This
structuring avoids unnecessary duplication of pointcut interface
specifications, and whenever the implementation of a lower-level
pointcut changes, the higher-level pointcut reuses this change at no
extra cost.
In the E-Finance case study, this type of reuse was encountered
in the account adaptation pointcut interface. As presented earlier
(cf. Listing 1), this pointcut interface is an aggregate of the account
closure,account creation,andbalance change pointcut interfaces,
as well as a concrete pointcut expression. Whenever the implemen-
tation of one of these lower-level pointcut interfaces changes, but
not its signature, that change does not ripple through to the higher-
level pointcut interface account adaptation.
In the digital publishing system, the approach did not deliver a
hierarchy of pointcut interfaces, and thus this type of reuse can not
be claimed.
Discussion.
In summary, we effectively reused some of the pointcut interfaces
discovered by our method in both case studies. More specifically,
in the E-Finance case study, we effectively reused all four pointcut
interfaces. In the digital publishing case study, we reused three out
of six discovered pointcut interfaces.
To understand why this reuse generally was less prominent in
the digital publishing case study, we have to consider the stability
of both domains. As explained in Section 2, this is an important
factor influencing the effectiveness of our approach. In both case
studies, we were forced to change the domain models in the second
iteration. However, a distinction has to be made between comple-
mentary changes, and invasive changes to the domain model. Ex-
amples of complementary changes are adding concepts as leaves of
existing generalization/specialization hierarchies, adding concepts
that have no intrinsic relation to earlier-defined concepts. Invasive
changes in the domain are for example restructuring existing rela-
tionships between concepts, invasively redefining concepts, or re-
moving concepts. In the E-Finance case study, the adaptations to
the domain model were mostly complementary in nature. To illus-
trate, we found that the newly-introduced custody account fit well
into the existing domain model, as it already contained the concept
of a bank account (see Figure 4). On the other hand, the digital
publishing evolution scenario brought more invasive changes to the
publishing domain models. This was mostly due to the fact that the
adopted evolution scenario represents a fundamental shift in digital
news publishing. From these considerations, it becomes clear that
the E-Finance domain was closer to the theoretical extreme of ab-
solute domain stability than the digital publishing domain. This in
turn provides an explanation why we indeed experienced a higher
degree of effective reuse in the E-Finance case study.
Concluding, we state that in both case studies, (i) we experi-
enced effective reuse of the pointcut interfaces introduced by our
approach, and (ii) we found that the effectiveness of the presented
approach to discover reusable pointcut interfaces is dependent on
the stability of the domain it acts upon.
Since we applied this validation in only two case studies, it has
no statistical relevance as such. A statistically relevant validation
would include the application of the approach in multiple case stud-
ies, and application domains. Moreover, a full-blown validation of
the approach would take into account other considerations such as
the scalability of the approach, and the maintainability of the re-
sulting software architectures. Providing such a strengthened vali-
dation of the approach is part of future work.
However, we clearly provide some compelling examples that il-
lustrate effective reuse of the pointcut interfaces in an AO architec-
ture as a result of applying the approach.
6. RELATED WORK
In this section we compare our domain-driven architec-
ture method against four bodies of work: Early Aspects ap-
proaches, aspect-oriented architecture approaches, aspect-oriented
approaches to use case modeling, and approaches that deal with the
fragile pointcut problem.
Early Aspects.
As our domain-driven architecture method is situated at the
transition between requirements and architecture, it is related to
various Early Aspects [4] approaches that map aspectual require-
ments to architecture. The most relevant approaches in this space
include COMPASS [7], Goal-Driven Discovery of Aspects [27],
Theme [8], Jacobson’s AOSD with Use Cases approach [15] and
Aspect-Oriented Architecture Models (AAM) [10]. We first dis-
cuss the general relationship between these approaches and our
domain-driven architecture method. Thereafter we more closely
compare against COMPASS and the Goal-Driven Discovery ap-
proach as these approaches derive pointcut-like compositions from
aspectual requirements.
The common goal of all the above Early Aspects approaches is
achieving improved aspect traceability across the software life cy-
cle and supporting trade-off analysis [30, 27] for conflicting re-
quirements. Our domain-driven architecture method is comple-
mentary to these approaches as we focus on discovering stable
architectural abstractions for aspect-oriented composition, starting
from the requirements level. As our method adheres to the Twin
Peaks model, the method should ideally be performed after a first
iteration of these Early Aspects approaches has been performed.
In COMPASS, aspectual compositions at the requirements level
are mapped to aspect-oriented compositions at the architecture
level. More specifically, COMPASS uses a one-to-one mapping
between requirements-level and architecture-level compositions.
In contrast, our method takes a many-to-one mapping approach,
where a single pointcut signature at the architectural level is de-
rived by generalizing multiple aspectual compositions at the re-
quirements level. This generalization step is the key factor that
enables a higher reusability of pointcuts across multiple aspects.
COMPASS also uses the AO-ADL architectural description lan-
guage [29] for expressing aspectual compositions at the architec-
ture level. AO connector templates are an interesting feature of
AO-ADL which enable parametrization reuse of pointcuts. This
kind of pointcut reuse is focused at reusing the binding of specific
aspectual components across multiple base applications. In con-
trast, our method is focused at reusing a pointcut across multiple
aspects.
The Goal-driven Discovery of Aspects approach offers detailed
procedures for discovering aspects from V-shaped goal graphs [38].
These goal aspects are represented as pairs of pointcut-advice con-
structs, where advice refers to softgoals, and a pointcut refers
to fine-grained functional goals.We believe our approach comple-
ments this by discovering stable domain abstractions in the goal as-
pects. Once these stable abstractions are identified, however, their
projection to the operationalizations of the functional goals poten-
tially leads to reusable pointcuts at the architecture level.
Aspect-oriented architecture approaches.
In the area of aspect-oriented product-line architectures [11, 36],
there are some works [16, 26, 5, 20] that focus on establishing sta-
ble aspectual interfaces, with the possibility of specifying various
types of contracts to govern interactions between features (aspects)
and the base architecture. As stated in section 4.5, specifying such
interaction contracts and other design rules is possible, yet out of
the scope of our method. Kulesza, et al. [20] also identified a
synergy between extension points in use cases and aspectual in-
terfaces, which they aim to exploit in future work to improve the
traceability between requirements and architecture. In opposition,
our approach exploits this synergy to discover stable abstractions
for reusable aspectual interfaces.
Aspect-oriented approaches to use case modeling.
Most existing aspectual use-case approaches [2, 31, 13, 33] pro-
pose an explicit crosscuts relationship so that the crosscutting re-
quirements can be completely modularized without having to pre-
pare the base use cases with extension points. Our goal is not to
achieve improved modularization of aspectual use cases. Instead
we want to generalize base use cases to reveal stable domain ab-
stractions for multiple aspectual use cases.
Fragile pointcut problem.
Most of the recent work on explicit pointcut interfaces at the im-
plementation level, a concept originally proposed by Gudmundson
and Kiczales [12], has to do with the fragile pointcut problem [18].
This problem refers to the situation when pointcuts suffer from un-
intended join point matches or accidental join point misses after
base code has evolved [35]. The XPI approach [34] deals with
this problem by attaching design rules to pointcut interfaces. These
design rules are contract-like invariants about the structure of the
base code, which can be automatically maintained over the course
of system evolution. Open modules [1] deals with the problem by
making the base code modules directly responsible for maintain-
ing the implementation of the pointcut interfaces. The main con-
tribution of these works thus lies in the fact that the correctness of
pointcut interface implementations can be maintained in the face of
changes in the base code. However, these works define very little
guidance on how to identify the right abstractions so that a point-
cut interface becomes useful for as many client aspects as possible.
Our domain-driven method aims to provide such guidance, thus
mostly making a complementary contribution at the client-side of
the pointcut interface.
The work on model-based pointcuts [17] tackles the fragile
pointcut problem by declaring pointcuts in terms of a conceptual
model of the base program. The definition of the conceptual model
is based on the Intentional Views approach [25]. Intentional views
describe concepts of interest to a programmer by grouping program
entities (classes, methods, ...) that share some structural prop-
erty. For example, in an object-oriented implementation of a Wiki
framework, the WikiAction view groups all methods implementing
an action on a Wiki page. The question arises however whether the
concept of a wiki action is a suitable abstraction for expressing the
required aspect compositions in the Wiki framework. Again, we
believe our method provides the missing guidance on identifying
what are the relevant properties to expose in such an Intentional
view.
7. CONCLUSION AND FUTURE WORK
This paper presents a method to discover stable domain abstrac-
tions from use cases and domain models. Furthermore, it guides the
software architect in mapping these domain abstractions to reusable
pointcut interfaces, and constraining the software architecture in or-
der to implement the pointcut interfaces. This approach builds on a
certain degree of domain stability; i.e. the problem domain remains
stable under system evolution. More specifically under this pre-
condition, the discovered domain abstractions can be considered
to be a ubiquitous vocabulary, as they represent a complete ter-
minology for the stakeholders to communicate about the software
solutions in terms of problem space concepts. Specifying pointcut
interfaces based on such stable domain abstractions improves the
effective reusability of these pointcut interfaces. We have applied
the approach in two realistic case studies, in which we adopted an
evolution scenario to assess how many pointcut interfaces could
effectively be reused. From this, we have shown that we were in-
deed able to reuse the pointcut interfaces discovered by applying
the approach. More importantly, we found that the effectiveness of
the approach indeed depends on the stability of the domain it acts
upon.
In future work, we will strengthen the validation of the approach
as outlined in Section 5. Also, investigating how closely our ap-
proach is tied to the specific choice of use cases as requirements
representation technique is part of future work. Possibly a similar
approach could be articulated for different requirement representa-
tion techniques, such as problem frames, viewpoints or goals.
Meanwhile, we have presented an architecture method that
leverages upon state-of-the-art research in AORE and on state-of-
practice in requirements specification (use cases). We believe that
this is essential to integrate and adopt AOSD in all stages of the
software life cycle.
Acknowledgements
This research is supported by European Commission FP6 Grant
AOSD-Europe: European Network of Excellence on AOSD (IST-
2-004349), the Interuniversity Attraction Poles Programme Belgian
State, Belgian Science Policy, by the Research Fund K.U.Leuven,
and by an SBO project grant from the Flemish Institute for the ad-
vancement of scientific-technological research in industry (IWT).
8. REFERENCES
[1] Jonathan Aldrich. Open modules: Modular reasoning about
advice. In ECOOP, pages 144–168, 2005.
[2] João Araújo, Ana Moreira, Isabel Brito, and Awais Rashid.
Aspect-oriented requirements with UML. In Mohamed
Kandé, Omar Aldawud, Grady Booch, and Bill Harrison,
editors, Workshop on Aspect-Oriented Modeling with UML,
2002.
[3] João Araújo and Ana M. D. Moreira. An aspectual use-case
driven approach. In Ernesto Pimentel, Nieves R. Brisaboa,
and Jaime Gómez, editors, JISBD, pages 463–468, 2003.
[4] Elisa L. A. Baniassad, Paul C. Clements, João Araújo, Ana
Moreira, Awais Rashid, and Bedir Tekinerdogan.
Discovering early aspects. IEEE Software, 23(1):61–70,
2006.
[5] Olivier Barais, Eric Cariou, Laurence Duchien, Nicolas
Pessemier, and Lionel Seinturier. Transat: A framework for
the specification of software architecture evolution. In
ECOOP First International Workshop on Coordination and
Adaptation Techniques for Software Entities (WCAT04),
Oslo, Norway, jun 2004.
[6] L. Bass, P. Clements, and R. Kazman. Software Architecture
in Practice. Addison-Wesley, second edition, 2003.
[7] Ruzanna Chitchyan, Mónica Pinto, Awais Rashid, and Lidia
Fuentes. Compass: Composition-centric mapping of
aspectual requirements to architecture. Transactions on
Aspect-Oriented Software Development IV, pages 3–53,
2007.
[8] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and
Design: the Theme Approach. Addison-Wesley Reading,
2005.
[9] Eric Evans. Domain-Driven Design: Tackling Complexity in
the Heart of Software. Addison-Wesley, 2004.
[10] Robert B. France, Indrakshi Ray, Geri Georg, and Sudipto
Ghosh. Aspect-oriented approach to early design modelling.
IEE Proceedings - Software, 151(4):173–186, 2004.
[11] Martin L. Griss. Implementing product-line features by
composing aspects. In Patrick Donohoe, editor, SPLC, pages
271–289. Kluwer, 2000.
[12] Stephan Gudmundson and Gregor Kiczales. Addressing
practical software development issues in aspectj with a
pointcut interface. In Advanced Separation of Concerns,
2001.
[13] Stephan Herrmann, Christine Hundt, and Katharina Mehner.
Mapping use case level aspects to object teams/java. In
OOPSLA Workshop on Early Aspects, 2004.
[14] Martin E. Nordberg III. Aspect-oriented dependency
inversion. In Workshop on Advanced Separation of Concerns
in Object-Oriented Systems at OOPSLA, 2001.
[15] Ivar Jacobson and Pan-Wei Ng. Aspect-Oriented Software
Development with Use Cases. Addison-Wesley, 1st edition,
December 2004.
[16] Mika Katara and Shmuel Katz. Architectural views of
aspects. In AOSD ’03: Proceedings of the 2nd international
conference on Aspect-oriented software development, pages
1–10, New York, NY, USA, 2003. ACM.
[17] Andy Kellens, Kim Mens, Johan Brichau, and Kris Gybels.
Managing the evolution of aspect-oriented software with
model-based pointcuts. In Dave Thomas, editor, ECOOP,
volume 4067 of Lecture Notes in Computer Science, pages
501–525. Springer, 2006.
[18] C. Koppen and M. Stoerzer. Pcdiff:attacking the fragile
pointcut problem. In First European Interactive Workshop on
Aspects in Software (EIWAS), 2004.
[19] Uirá Kulesza, Er Alves, Ro Garcia, Carlos J. P. De Lucena,
and Paulo Borba. Improving extensibility of object-oriented
frameworks with aspect-oriented programming. In Proc. of
the 9th Intl Conf. on Software Reuse (ICSR’06, pages
231–245, 2006.
[20] Uirá Kulesza, Er Alves, Ro Garcia, Alberto Costa Neto,
Elder Cirilo, Carlos J. P. De Lucena, and Paulo Borba.
Mapping features to aspects: A model-based generative
approach. In Early Aspects: Current Challenges and Future
Directions, volume 4765 of LNCS. Springer, 2007.
[21] Bert Lagaisse, Bart De Win, Wouter Joosen, and Johan Van
Oeyen. E-finance case study: analysis and requirements.
CW-Report 438, DistriNet, KULeuven, March 2006.
[22] Dimitri Van Landuyt, Steven Op de beeck, Bas Kemper,
Eddy Truyen, and Wouter Joosen. Building a next-generation
digital publishing platform using aosd;
http://distrinet.cs.kuleuven.be/projects/digitalpublishing/.
[23] Dimitri Van Landuyt, Steven Op de beeck, Eddy Truyen, and
Wouter Joosen. An aspect-oriented architecture for the
e-finance case study;
http://distrinet.cs.kuleuven.be/projects/aoarchitectureefinance/.
[24] Jacques Meekel, Thomas B. Horton, Robert B. France,
Charlie Mellone, and Sajid Dalvi. From domain models to
architecture frameworks. In SSR ’97: Proceedings of the
1997 symposium on Software reusability, pages 75–80, New
York, NY, USA, 1997. ACM.
[25] Kim Mens, Andy Kellens, Frédéric Pluquet, and Roel Wuyts.
Co-evolving code and design with intentional views: A case
study. Computer Languages, Systems & Structures,
32(2-3):140–156, 2006.
[26] Freddy Munoz, Benoit Baudry, and Olivier Barais.
Improving maintenance in aop through an interaction
specification framework. In ICSM, pages 77–86. IEEE, 2008.
[27] Nan Niu and Steve Easterbrook. Analysis of early aspects in
requirements goal models: A concept-driven approach.
Transactions on Aspect-Oriented Software Development III,
pages 40–72, 2007.
[28] Bashar Nuseibeh. Weaving together requirements and
architectures. IEEE Computer, 34(3):115–117, 2001.
[29] M. Pinto and L. Fuentes. AO-ADL: An ADL for describing
aspect-oriented architectures. In Early Aspects: Current
Challenges and Future Directions, volume 4765 of LNCS.
Springer, 2007.
[30] Awais Rashid, Ana M. D. Moreira, and João Araújo.
Modularisation and composition of aspectual requirements.
In AOSD, pages 11–20, 2003.
[31] Jonathan Sillito, Christopher Dutchyn, Andrew David
Eisenberg, and Kris De Volder. Use case level pointcuts. In
Martin Odersky, editor, ECOOP, volume 3086 of Lecture
Notes in Computer Science, pages 244–266. Springer, 2004.
[32] Ian Sommerville. Software Engineering. Pearson, 2008.
[33] Geórgia Sousa, Sérgio Soares, Paulo Borba, and Jaelson
Castro. Separation of crosscutting concerns from
requirements to design: Adapting the use case driven
approach. In In Proc. Early Aspects Workshop at AOSD,
2004.
[34] Kevin J. Sullivan, William G. Griswold, Yuanyuan Song,
Yuanfang Cai, Macneil Shonle, Nishit Tewari, and Hridesh
Rajan. Information hiding interfaces for aspect-oriented
design. In Michel Wermelinger and Harald Gall, editors,
ESEC/SIGSOFT FSE, pages 166–175. ACM, 2005.
[35] Tom Tourwé. On the existence of the aosd-evolution
paradox. In In AOSD Workshop on Software Engineering
Properties of Languages for Aspect Technologies, 2003.
[36] Markus Völter and Iris Groher. Product line implementation
using aspect-oriented and model-driven software
development. In SPLC, pages 233–242. IEEE Computer
Society, 2007.
[37] Dean Wampler. Aspect-oriented design principles: Lessons
from object-oriented design. In Proceedings of the 2007
AOSD conference. Object Mentor, Inc., Feb. 2007.
[38] Yijun Yu, Julio Cesar Sampaio do Prado Leite, and John
Mylopoulos. From goals to aspects: Discovering aspects
from requirements goal models. In RE, pages 38–47. IEEE
Computer Society, 2004.
