Conference PaperPDF Available

Domain-Driven Discovery of Stable Abstractions for Pointcut Interfaces


Abstract and Figures

The benefits of defining explicit pointcut interfaces in aspect-oriented applications have been advocated by many. A pointcut interface exposes a set of crosscutting abstract behaviors that multiple aspects of an application can leverage and use. In order to maximally promote pointcut reuse across applications from a certain problem domain, a pointcut interface should preferably expose stable abstractions in that problem domain. In this paper, we propose a top-down method for designing such stable pointcut interfaces. The method builds upon state-of-the-art domain analysis techniques and employs systematic re-engineering of use case models to discover stable abstractions that are anchored in the domain model of the application. At architecture creation time, these stable domain abstractions are mapped onto pointcut interfaces. We provide algorithmic procedures for use case re-engineering and guidelines for architecture creation. This enables further experimentation with the proposed method and its automation, which in turn improves the ease of adoption. The paper enhances the detailed description of the method by applying it in a running example. We have applied our method in two case studies, where we observe that the resulting pointcut interfaces can be reused for implementing the composition logic of different aspects without requiring modification to their pointcut signatures. In summary, both case studies provide compelling examples that illustrate non-trivial reuse of the pointcut interfaces that have been created using our method.
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
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
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.
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
3. Reuse within pointcut
interface hierarchies
gray reuse
1. Reuse of existing pointcut
Aspect New Aspect K
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
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-
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-
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
2. Identify & Separate
crosscutting concerns
in use cases
3. Generalize
crosscutting use case
4. Dene discovered
domain abstractions
1. Dene Domain
Model and Use Cases
5. Architectural design
using domain
6. Specify Pointcut
Interfaces based on
domain abstractions
7. Compose aspects
through pointcut
(constrain architecture)
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
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.
Act. Input Output
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
use cases; domain mod-
els; domain abstractions;
existing component-based
architecture (optional)
(constrained) component-
based architecture
component-based ar-
chitecture; domain
component-based ar-
chitecture with pointcut
component-based ar-
chitecture with pointcut
component-based ar-
chitecture with pointcut
interfaces and aspectual
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).
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
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
block customer account
close a savings account
open a savings account
open a current account
close a current account
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-
11b If the provided signature is invalid, the transaction is can-
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-
Bank Clerk Customer
account number
Bank Account
associated with
0..* 1
Transfer Withdrawal Deposit
Figure 4: Subset of the E-Finance domain models.
4.2 Identify and separate crosscutting con-
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
UseCase3 Sign an agreement
Primary actor: Bank clerk or Customer
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
open a savings account
Extension Points
open a current account
Extension Points
close a current account
Extension Points
<< extend>>
<< extend>>
<< extend>>
<< extend>>
<< extend>>
<< extend>>
Extension Points
<< extend>>
<< extend>>
block customer account
Extension Points
<< extend>>
Extension Points
<< extend>>
<< extend>>
Extension Points
<< 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-
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
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-
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-
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,
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
block customer account
close a savings
open a savings
open a current
close a current
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-
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-
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-
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
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
context info
pointcut signature
pointcut signature
Figure 9: The transition from requirements to architecture.
4.8 Transition from requirements to architec-
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
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-
The resulting pointcut interface is presented at the bottom of
Figure 9.
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
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.
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.
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
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
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
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.
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).
[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,
[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,
[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,
[8] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and
Design: the Theme Approach. Addison-Wesley Reading,
[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,
[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;
[23] Dimitri Van Landuyt, Steven Op de beeck, Eddy Truyen, and
Wouter Joosen. An aspect-oriented architecture for the
e-finance case study;
[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,
[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.
... This document presents the application of the method to discover stable domain abstractions for designing reusable pointcut interfaces [4] in the common case study for aspect-oriented design [2]. It serves to document how we applied this method in this concrete case study and provides all details of this. ...
... In opposition, the subsequent two activities (3,4) are essential and specific to our method. They comprise the key contribution of our work. ...
... 3. The CMS Employee indicates his current Availability Status. 4. The System stores this information. ...
... By letting aspect composition specifications depend on such stable domain abstractions, this Domain-Driven Design approach offers an interesting base for dealing with fragility issues in the context of AOSD [5]. Additionally, the use of stable domain abstractions has been linked to effective reuse in literature [11,7,14]; i.e. pointcuts exposing stable domain abstraction are more likely to be reusable, and therefore are important assets in the definition of aspectoriented product lines architecture [6]. ...
... In earlier work [14], we have introduced such a domaindriven aspect design approach mainly as a manual method. In this paper, we examine the feasibility of automating this method to discover stable domain abstractions from domain models and use cases. ...
... For a more detailed description of the method, please refer to [14]. ...
Full-text available
Domain-driven aspect design aims to support effective reuse of aspects within a product-line or family of software systems. In this paper, we explore the feasibility of automat-ing our approach to discover stable domain abstractions in requirements for the purpose of defining reusable pointcuts. This approach was introduced in earlier work mainly as a manual method. This paper defines an algorithmic proce-dure for each activity, and discusses to which degree each activity can be automated. The generalization activity (ac-tivity 3) is given specific attention, as it is the most com-plex activity at the heart of the approach. The end result is an algorithmic procedure for (semi-)automatically discover-ing stable domain abstractions to design effectively reusable pointcuts.
... It is an important concern during the development of service lines to ensure the composability of features and their corresponding software variants; i.e. to make sure that separately developed feature implementations remain compatible (syntactically and semantically), so that they can later be composed to a working system. To support this concern, the base architecture has to be built around stable interfaces [208], and components should be self-contained (modular) and preferably be stateless. The latter is especially relevant in a multi-tenant context because it simplifies dynamic customization (no need for quiescence) and thus limits the performance overhead. ...
Full-text available
Software as a Service (SaaS) has been increasingly adopted by software vendors as their main software delivery model, as it provides the opportunity to offer their software applications to a larger market and to benefit from the economies of scale. One of the key enablers to leverage economies of scale is multi-tenancy: resources are shared among multiple customer organizations (the so-called tenants), which leads to higher resource utilization and scalability. The highest degree of resource sharing is achieved with application-level multi-tenancy. However, this focus on increased resource sharing typically results in a one-size-fits-all approach. As a consequence, multi-tenant SaaS applications are inherently limited in terms of flexibility and variability, and cannot be customized to the different and varying requirements of the different tenants. This dissertation presents both a middleware framework and a software engineering method to facilitate the development, operation and management of customizable, multi-tenant SaaS applications. More specifically, the middleware framework improves the flexibility of multi-tenant SaaS applications by enabling tenant-specific customizations, while preserving the economies of scale and limiting the application engineering complexity. The focus is on dynamically composing software variants on a per tenant basis as well as on enforcing tenant-specific performance SLAs throughout the SaaS application. The service line engineering (SLE) method aims to reduce the management complexity of many co-existing tenant-specific configurations as well as the effort to provision tenants and to update and maintain the customizable SaaS application. This work has been validated and evaluated in the context of two types of industry-relevant SaaS applications, i.e. a request-driven online hotel booking application and a batch-driven document processing application. We have implemented different prototypes on top of existing cloud platforms and the evaluation shows the effectiveness of our solution while introducing only a very limited performance overhead.
... It is an important concern during the development of service lines to ensure the composability of features and their corresponding software variants; i.e. to make sure that separately developed feature implementations remain compatible (syntactically and semantically), so that they can later be composed to a working system. To support this concern, the base architecture has to be built around stable interfaces (Van Landuyt et al., 2009), and components should be self-contained (modular) and preferably be stateless. The latter is especially relevant in a multi-tenant context because it simplifies dynamic customization (no need for quiescence) and thus limits the performance overhead. ...
Full-text available
Application-level multi-tenancy is an architectural approach for Software-as-a-Service (SaaS) applications which enables high operational cost efficiency by sharing one application instance among multiple customer organizations (the so-called tenants). However, the focus on increased resource sharing typically results in a one-size-fits-all approach. In principle, the shared application instance satisfies only the requirements common to all tenants, without supporting potentially different and varying requirements of these tenants. As a consequence, multi-tenant SaaS applications are inherently limited in terms of flexibility and variability. This paper presents an integrated service engineering method, called service line engineering, that supports co-existing tenant-specific configurations and that facilitates the development and management of customizable, multi-tenant SaaS applications, without compromising scalability. Specifically, the method spans the design, implementation, configuration, composition, operations and maintenance of a SaaS application that bundles all variations that are based on a common core. We validate this work by illustrating the benefits of our method in the development of a real-world SaaS offering for document processing. We explicitly show that the effort to configure and compose an application variant for each individual tenant is significantly reduced, though at the expense of a higher initial development effort.
... Example usage of pointcut interface can be found in the DigiNews applica- tion [77, 63]. A domain-driven methodology was used to find stable abstractions for the design with pointcut interfaces [78]. The same methodology was applied to a common case study for AO modeling [79]. ...
Full-text available
A key direction for achieving mainstream adoption of aspect-oriented (AO) programming is the availability of reusable aspect libraries that can be easily applied across a wide range of applications. This paper presents a pattern system for AO design that provides solutions for recurring problems in the design of such reusable aspect libraries. We have focused on libraries using AspectJ. The requirements for setting up reusable aspect libraries are first sketched. Subsequently, an architectural pattern and four design patterns addressing key design problems are identified: managing aspect-awareness, enabling join point abstraction and adaptation, decomposition, and mediation. Each design pattern leads to a set of programming idioms to address the related design problem. The pattern system aggregates the four sets of idioms that include a specific section to guide selection of a specific idiom. The implementation of an aspect library for access control is discussed to illustrate how the system of patterns can be used and how the different patterns and idioms can be combined. The format of the pattern catalogs is based on pattern writing advice provided by the Hillside group. We have analyzed and integrated related work in design patterns for aspects. Furthermore, we present an initial validation of the patterns with respect to their stability, versatility, and ease-of-use. To the best of our knowledge, this is the first comprehensive system of AOP patterns that supports the construction of aspect libraries.
Full-text available
With the increasing dependence on software systems, their longevity is becoming a pressing need. Stability is envisioned as a primary property to achieve longevity. Stability has been defined and treated in many different ways in the literature. We conduct a systematic literature review to analyse the state-of-the-art related to stability as a software property. We formulate a taxonomy for characterising the notion, analyse the definitions found in the literature, and present research studies dealing with stability. Also, as architecture is one of the software artefacts with profound effects throughout the software lifecycle, we focus on software engineering practices for realising architectural stability. The analysis results show a wide variation in dimensions when dealing with stability. The state-of-the-art indicates the need for a shift towards a multi-dimensional concept that could cope with runtime dynamics and emerging software paradigms. More research efforts should be directed toward the identified gaps. The presented taxonomy and analysis of the literature aim to help the research community in consolidating the existing research efforts and deriving future developments.
Aspect-oriented programming is known as a technique for modularizing crosscutting concerns. However, constructs aimed to support crosscutting modularity might actually break class modularity. As a consequence, class developers face changeability, parallel development and comprehensibility problems, because they must be aware of aspects whenever they develop or maintain a class. At the same time, aspects are vulnerable to changes in classes, since there is no contract specifying the points of interaction amongst these elements. These problems can be mitigated by using adequate design rules between classes and aspects. We present a design rule specification language and explore its benefits since the initial phases of the development process, specially with the aim of supporting modular development of classes and aspects. We discuss how our language improves crosscutting modularity without breaking class modularity. We evaluate it using a real case study and compare it with other approaches.
Conference Paper
Originally, the introduction of aspects to address crosscutting concerns was proposed for implementation activities. Aspects have also been considered in the software architecture community in order to solve the problems of modularization of crosscutting concerns. The real benefits of introducing aspects into software architecture design are still debated. In this article, a systematic review on aspect-oriented software architectures is proposed. The chosen articles were evaluated based on criteria such as which non-functional requirements were improved and which architecture views were considered in each study. In addition, specific qualities related to software maintenance, such as understandability and modifiability, were evaluated for each article. The purposes are to evaluate what are the most common concerns considered when designing a software architecture using aspects, and whether the introduction of aspects is useful in software maintenance.
In software architecture design, the end product is the combined result of a wide variety of inputs, most of which are provided by the non-technical stakeholders. These include the analysis of the problem domain, the functional and non-functional requirements, the architectural or technical constraints. However, a software architecture is typically also influenced by different, less visible factors such as the architect's prior experience and his creativity. In this paper, we focus on so-called architectural assumptions, which are key premises made by technical stakeholders in the early phases of the software development life-cycle. Often these assumptions are made silently and not documented explicitly in the description of the architecture. As a result, they introduce a certain degree of rigor in the software product that hinders the evolvability, variability, and reusability of the architectural solution as a whole and its individual building blocks. Additionally, architectural assumptions in many cases exert a crosscutting influence on the software architecture and its description. This makes it hard to discover them, assess their individual architectural impact, and treat them as first-class architectural elements. In this position paper, we explore and discuss these modularity problems in specific examples from a patient monitoring system (e-health). Furthermore, we introduce the distinction between problem-space and solution-space architectural assumptions, and we discuss their intrinsic differences.
The quality attributes of a software system are, to a large extent, determined by the decisions taken early in the development process. Best practices in software engineering recommend the identification of important quality attributes during the requirements elicitation process, and the specification of software architectures to satisfy these requirements. Over the years the software engineering community has studied the relationship between quality attributes and the use of particular architectural styles and patterns. In this paper we study the relationship between quality attributes and Aspect-Oriented Software Architectures - which apply the principles of Aspect-Oriented Software Development (AOSD) at the architectural level. AOSD focuses on identifying, modeling and composing crosscutting concerns - i.e. concerns that are tangled and/or scattered with other concerns of the application. In this paper we propose to use AO-ADL, an aspect-oriented architectural description language, to specify quality attributes by means of parameterizable, and thus reusable, architectural patterns. We particularly focus on quality attributes that: (1) have major implications on software functionality, requiring the incorporation of explicit functionality at the architectural level; (2) are complex enough as to be modeled by a set of related concerns and the compositions among them, and (3) crosscut domain specific functionality and are related to more than one component in the architecture. We illustrate our approach for usability, a critical quality attribute that satisfies the previous constraints and that requires special attention at the requirements and the architecture design stages.
Full-text available
In this article we present our industrial demonstrator about building a digital publishing system using Aspect-Oriented Software Development (AOSD). We have applied AOSD methods and tools during the full software development process from requirements to deployment. The goal of the demonstrator is to show that (i) AOSD integrates well with existing standard paradigms such as component-based software engineering, (ii) the resulting software exhibits a good evolvability and variability, and (iii) AOSD increases the overall business value of digital publishing services by supporting characteristics of an ideal news product that allows direct marketing to targeted groups of customers.
Full-text available
Crosscutting concerns are responsible for producing spread and tangled representations throughout the software life cycle. Effective separation of such concerns is essential to improve understandability and maintainability of artefacts at the various software development stages. Aspect-oriented software development holds promise for the purpose. However, to date, most of the work in this area has concentrated on the implementation level. While the focus is shifting to earlier development stages such as design, very less work exists on separation of crosscutting concerns during requirements engineering. The goal of this paper is to handle the separation of crosscutting concerns at requirements level using UML. To accomplish this we identify and specify crosscutting concerns in separate modules, so that localization and hence, reusability and maintainability can be promoted. The UML- based aspect-oriented requirements engineering mechanism has a two-fold impact. It makes it possible to identify trade- offs among broadly scoped properties early on in the development cycle hence providing decision support for the stakeholders involved. At the same time, being based on UML, the approach adheres to a de-facto industry standard hence making it suitable for incorporation in existing requirements engineering practices.
Full-text available
Everything changes in our everyday lives: New discoveries, paradigms, styles, and technologies. Frequently, software systems success depends on how they can quickly adapt to requirement or environment evolution. Software architectures are abstract models at the highest level. As such, they should assume conceptual guidance on what parts of the system changed. However, many software architectures often evolve from an uncoordinated build-and-fix attitude. The result is opaque and not analyzable. We present in this paper a practical experience of using as-pect oriented programming principles for managing software architecture specification evolution. Our approach aims at clarifying software archi-tecture evolution steps. It extends software architecture abstract models for the specification and the analysis of new concern integration.
Full-text available
Aspect-Oriented Software Development aims at supporting separation of crosscutting concerns throughout the full soft-ware lifecycle. In this contribution we focus on lifecycle sup-port for crosscutting concerns with internal structure and complex behaviour. In order to make transitions between phases more seamless, support for such concerns is needed in all phases. In the past the programming language Ob-jectTeams/Java has been developed which supports encap-sulation of role-based collaborations and therefore is a suit-able target platform for complex crosscutting concerns. We demonstrate how to develop requirements, analysis, and de-sign models for this target language.
From the Book:Leading software designers have recognized domain modeling and design as critical topics for at least twenty years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been clearly formulated, a philosophy has developed as an undercurrent in the object community, which I call "domain-driven design".I have spent the past decade focused on developing complex systems in several business and technical domains. I've tried best practices in design and development process as they have emerged from the leaders in the object-oriented development community. Some of my projects were very successful; a few failed. A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project.This book provides a framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with my own insights and experiences. Projects facing complex domains can use this framework to approach domain-driven design systematically.Contrasting Three ProjectsThree projects stand out in my memory as vivid examples of the dramatic effect domain design practice has on development results. Although all three delivered useful software, only one achieved its ambitious objectives and delivered complex software that continued to evolve to meet ongoing needs of the organization.I watched one project get out of the gate fast with a useful, simple web-based trading system. Developers were flying by the seat of their pants, but simplesoftware can be written with little attention to design. As a result of this initial success, expectations for future development were sky-high. It was at this point that I was approached to work on the second version. When I took a close look, I saw that they lacked a domain model, or even a common language on the project, and were saddled with an unstructured design. So when the project leaders did not agree with my assessment, I declined the job. A year later, they found themselves bogged down and unable to deliver a second version. Although their use of technology was not exemplary, it was the business logic that overcame them. Their first release had ossified prematurely into a high-maintenance legacy.Lifting this ceiling on complexity calls for a more serious approach to the design of domain logic. Early in my career, I was fortunate to end up on a project that did emphasize domain design. This project, in a domain at least as complex as the one above, also started with a modest initial success, delivering a simple application for institutional traders. But this delivery was followed up with successive accelerations of development. Each successive iteration opened exciting new options for integration and elaboration of functionality. The team way able to respond to the needs of the traders with flexibility and expanding capability. This upward trajectory was directly attributable to an incisive domain model, repeatedly refined and expressed in code. As the team gained new insight into the domain, the model deepened. The quality of communication improved among developers and between developers and domain experts, and the design, far from imposing an ever-heavier maintenance burden, became easier to modify and extend.Unfortunately, not all projects that start with this intention manage to arrive at this virtuous cycle. One project I joined started with lofty aspirations to build a global enterprise system based on a domain model, but finally had a disappointing result. The team had good tools, a good understanding of the business and gave serious attention to modeling. But a separation of developer roles led to a disconnect between the model and implementation, so the design did not reflect the deep analysis that was going on. In any case, the design of detailed business objects was not rigorous enough to support combining them in elaborate applications. Repeated iteration produced no improvement in the code, due to uneven skill-level among developers with no clear understanding of the particular kind of rigor needed. As months rolled by, development work became mired in complexity and the team lost its cohesive vision of the system. After years of effort, the project did produce modest, useful software, but had given up the early ambitions along with the model focus.Of course many things can put a project off course, bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features.Some of these design factors are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills.Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won't matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software.The premise of this book is that For most software projects, the primary focus should be on the domain and domain logic. Complex domain designs should be based on a model. Domain-driven design is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book presents an extensive set of design practices, techniques and principles.Design vs. Development ProcessDesign books. Process books. They seldom even reference each other. Each is a complex topic in its own right. This is a design book. But I believe that these two issues are inextricable if design concepts are to be put into successful practice and not dry up into academic discussion. When people learn design techniques, they feel excited by the possibilities, but then the messy realities of a real project descend on them. They don't see how to fit the new design ideas with the technology they must use. Or they don't know when to worry about a particular design aspect and when to let go in the interest of time. While it is possible to talk with other team members about the applica design principle in the abstract, it is more natural to talk about the things we do together. So, while this is a design book, I'm going to barge right across that artificial boundary when I need to. This will place design in the context of a development process. This book is not specific to a particular methodology, but it is oriented toward the new family of "Agile Development Processes". Specifically, it assumes a couple of process practices are in place on the project. These two practices are prerequisites for applying the approach in this book. Iterative development. The practice of iterative development has been advocated and practiced for decades, and is a corner stone of the Agile development methods. There are many good discussions in the literature of Agile development and Extreme Programming, among them, Cockburn1998 and Beck 1999. A close relationship between developers and domain experts. Domain-driven design crunches a huge amount of knowledge into a model that reflects deep insight into the domain and a focus on the key concepts. This is a collaboration between those who know the domain and those who know how to build software. Because it is iterative, this collaboration must continue throughout the project's life.Extreme Programming (XP), conceived by Kent Beck, Ward Cunningham and others Beck2000, is the most prominent of the agile processes and the one I have worked with most. To make the discussion concrete, I will use XP throughout the book as the basis for discussion of the interaction of design and process. The principles illustrated are easily adapted to other Agile Processes. In recent years there has been a rebellion against elaborate development methodologies that burden projects with useless, static documents and obsessive upfront planning and design. Instead, the Agile Processes, such as XP, emphasize the ability to cope with change and uncertainty. XP recognizes the importance of design decisions, but strongly resists upfront design. Instead, it puts an admirable effort into increasing communication, and increasing the project's ability to change course rapidly. With that ability to react, developers can use the "simplest thing that could work" at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer's true needs.This has been a much-needed antidote to some of the excesses of design enthusiasts. Projects have bogged down in cumbersome documents that provided little value. They have suffered "analysis paralysis", so afraid of an imperfect design that they made no progress at all. Something had to change.Unfortunately, some of these new process ideas can be easily misinterpreted. Each person has a different definition of "simplest". Continuous refactoring without design principles to guide these small redesigns developers can produce a code base hard to understand or change - the opposite of agility. And, while fear of unanticipated requirements often leads to over-engineering, the attempt to avoid over-engineering can develop into another fear: The fear of any deep design thinking at all. In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But design choices make refactoring itself easier or harder. The XP process attempts to increase team communication. But model and design choices clarify or confuse communication. What is needed is an approach to domain modeling and design that pulls its weight.This book intertwines design and development practice and illustrates how domain-driven design and agile development reinforce each other. A sophisticated approach to domain modeling within the context of an agile development process will accelerate development. The interrelationship of process with domain development makes this approach more practical than any treatment of "pure" design in a vacuum.The Structure of This BookThe book is divided into four major sections:Part I: Putting the Domain Model to Work presents the basic goals of domain-driven development that motivate the practices in later sections. Since there are so many approaches to software development, Part I defines terms, and gives an overview of the implications of placing the domain model in the role of driving communication and design. Part II: The Building Blocks of Model-driven Design condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. The focus of this section is on bridging the gap between models and practical, running software. Sharing these standard patterns brings order to the design and makes it easy for team members to understand each other's work. Using standard patterns also establishes a common language, which all team members can use to discuss model and design decisions.But the main point of this section is on the kind of decisions that keep the model and implementation aligned with each other, reinforcing each other's effectiveness. This alignment requires attention to the detail of individual elements. Careful crafting at this small scale gives developers a steady platform to apply the modeling approaches of Parts III and IV.Part III: Refactoring Toward Deeper Insight goes beyond the building blocks to the challenge of assembling them into practical models that provide the payoff. Rather than jumping directly into esoteric design principles, this section emphasizes the discovery process. Valuable models do not emerge immediately. They require a deep understanding of the domain. That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make it's potential available to the application. Then, once in a while, this onion pealing leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes.Exploration is inherently open-ended, but it does not have to be random. Part III delves into modeling principles that can guide choices along the way, and techniques that help direct the search.Part IV: Strategic Design deals with situations that arise in complex systems, larger organizations, interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: Bounded Context, Distillation, and Large-Scale Structure. Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of Part I to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network.Throughout the book, discussions are illustrated with realistic examples, drawn from actual projects, rather than oversimplified "toy" problems.Much of the book is written as a set of "patterns." The reader should be able to fully understand the material without concern about this device, but those who are interested in the style and format of the patterns can read Appendix A.Who This Book Is Written ForThis book is primarily written for developers of object-oriented software. Most members of a software project team can benefit from some parts of it. It will make most sense to people who are on a project, trying to do some of these things as they go through, or who have deep experience already to relate it to.Some knowledge of object-oriented modeling is necessary to benefit from this book. The examples include UML diagrams and Java code, so the ability to read those languages at a basic level is important, but it is unnecessary to have mastered the details of either UML or Java. Knowledge of Extreme Programming will add perspective to the discussions of development process, but the discussion should be understandable without background knowledge.For an intermediate software developer, a reader who already knows something of object-oriented design and may have read one or two software design books, this book will fill in gaps and provide perspective on how object modeling fits into real life on a software project. It will help an intermediate developer make the jump to applying sophisticated modeling and design skills to practical problems.An advanced or expert software developer should be interested in the comprehensive framework for dealing with the domain. The systematic approach to design will help them in leading teams down this path. The coherent terminology will help them communicate with peers.Readers of various backgrounds may wish to take different paths through the book, shifting emphasis to different points. I recommend all readers to start with the introduction to Part I, and Chapter 1. This book is a narrative, and can be read beginning to end, or from the beginning of any chapter. A skimmer who already has some grasp of a topic should be able to pick up the main points by reading headings and bolded text. A very advanced reader may want to skim Parts I and II, and will probably be most interested in Parts III and IV.In addition to this core readership, the book will be of interest to analysts and to relatively technical project managers. Analysts can draw on the connection between model and design to make more effective contributions in the context of an "Agile" project. Analysts may also use some of the principles of strategic design to better focus and organize their work. Project managers should be interested in the emphasis on making a team more effective and more focused on designing software meaningful to business experts and users. And, since, strategic design decisions are interrelated with team organization and work styles, these design decisions necessarily involve the leadership of the project, and have a major impact on the project's trajectory.While an individual developer who understands domain-driven design will gain valuable design techniques and perspective, the biggest gains come when a team joins to apply a domain-driven design approach and move the domain model to the center of discourse of the project. The team members will share a language that enriches their communication and keeps it connected to the software. They will produce an implementation in step with the model, giving leverage to application development. They will share a map of how design work of different teams relates, and will systematically focus attention on the most features most distinctive and valuable to the organization.A domain-driven design is a difficult technical challenge that can pay off big, opening opportunities just at the stage when most software projects begin to ossify into legacy. Eric Evans, San Francisco, California, March 2003
For aspect-oriented design (AOD) to become mainstream, appropriate design principles are needed to guide its proper use in real, evolving systems. Design principles should tell us what types of coupling are appropriate between aspects and the software entities they advise, what if any restrictions should exist on non-invasiveness, how can aspects be used in ways that preserve correct behavior in the advised entities, and how do aspects complement other design constructs? I examine these questions using several object-oriented design (OOD) principles, considered from an AOD perspective. I demonstrate how AOD contributes design solutions to satisfy these principles, while it introduces nuances in their interpretations. Conversely, the OOD principles suggest good AOD-specific principles. In particular, they have implications for noninvasiveness, which is aspect weaving without module modification, but with appropriate controls.
Aspect oriented programming has been proposed as a way to improve modularity of software systems by allowing encapsulation of cross-cutting concerns. To do so, aspects specify where new functionality should apply using point-cuts. Unfortunately todays mainstream aspect oriented lan-guages suffer from pointcut languages where pointcut declarations result in a high coupling between aspect and base system. Additionally, these pointcuts are fragile, as non-local changes easily may break pointcut semantics. These properties are a major obstacle for program evolu-tion of aspect oriented software. This paper introduces a pointcut delta analysis to deal with this problem.