Use Case Level Pointcuts
ECOOP 2004
Jonathan Sillito, Christopher Dutchyn,
Andrew David Eisenberg and Kris De Volder
Software Practices Lab
THE UNIVERSITY OF BRITISH COLUMBIA
I am going to present some work a group of us at the University of British Columbia did
under the title “Use Case Level Pointcuts”.
1
Behavioral Models
Use Cases
Sequence Diagram
Source Code
Software developers create a variety of artifacts that model the behavior of applications at
different levels of abstraction; e.g. use cases, sequence diagrams, and source code.
2
Behavioral Models
Use Cases
Sequence Diagram
Source Code
AspectJ
Aspect-oriented programming languages, such as AspectJ, support the modularization of
crosscutting concerns at the source code level. However, I believe crosscutting concerns also
arise in other behavioral models of software systems.
3
The Problem
1. Lack of support for modularizing crosscutting in
other behavioral models, and in particular the
use-case model
2. Scattering across models
The problem we are trying to address has two parts. First, currently, there is a lack of
support for modularizing crosscutting concerns in other behavioral models. To this end, we
introduce a new aspect language, AspectU, which supports the formal modularization of
crosscutting concerns in the use-case model. This support makes it possible to define additional
behavior at certain points in the model. Talking about AspectU will take the majority of talk.
A second problem that I'll talk somewhat about towards the end of the talk has to do
with cross-model scattering and tangling. More on that later.
Now to talk about AspectU I want to describe what I think of as the use-case behavioral
model.
4
Use Case: Server handles presence stanza (handle presence)
Trigger: Entity sends presence (send)
Main Success Scenario
1. server processes and verifies presence (verify)
2. server obtains entity’s subscription information (subscription)
3. server determines recipients based on subscription
information (determine recipients)
4. sever delivers stanza to each recipient (deliver presence)
Extensions:
1a. Presence probe
1a1. server determines target of probe (determine target)
1a2. server obtains target’s last presence (obtain presence)
1a3. server replies to probe with this presence (reply)
4a. Non-local recipient
4a1. route presence (route)
This discussion will be based on some use cases for on a standardized messaging protocol
called XMPP (you may have heard it called jabber). The XMPP specification enables connected
entities to exchange various types of information. In XMPP terminology, a stanza is a chunk of
information. This use case describes how one type of stanza, a presence stanza, should be
handled.
While handling presence stanzas, the server follows a publish-subscribe scheme in which
the information is sent to all subscribed entities. This is shown as the main success scenario of
this use case, that is steps 1 through 4.
An exception to this is a so called presence probe, which is a particular kind of presence
stanza. The handling for this is described in extension 1a.
Along with the use case, we provide an identifying name next to each step, each use case,
and some extensions.
Use cases are a behavioral model of a system, and can be thought of as something that can
be executed. Elements in the model are nested: a use case is made up of extensions and steps; an
extension is made up of steps. This can be taken further in that steps may be further elaborated as
other use cases. Because of this nesting property of the model, each execution of a use case can
be thought of as forming a tree. Execution order is represented in left-to-right, depth-first
traversal of this tree.
5
Handle Presence: Main Scenario
use case:
handle
presence
step:
verify
step:
subscription
step:
determine
recipients
step:
deliver
presence
This tree, for example, represents one possible execution of the handle presence use case.
In particular this represents the main success scenario of the use case. The system behavior
captured by this particular execution of the use case is broken down as four steps.
6
Handle Presence: Presence Probe
use case:
handle
presence
step:
verify
step:
determine
recipients
extension:
presence
probe
step:
determine
recipients
step:
deliver
presence
This tree represents another possible execution of the handle presence use case. This
particular tree represents a scenario in which a presence probe is received. The system behavior
captured by this execution of the use case is broken down as one step followed by one extension,
which is further broken down as three additional steps.
That, in a nutshell is the use-case model as we see it. AspectU extends this model with
crosscutting implementation. Crosscutting in AspectU is based on join points, which are points in
the use-case model, pointcuts, which are a means to identify join points, and advice, which is a
means of affecting the behavior at the join points. I’ll talk about each of these in a bit of detail,
starting with join points.
Join points in AspectU are elements in the execution of the use-case model. These points
can be considered as subtrees in the execution of that model. In particular there are three types of
join points: use-case, extension, and step join points.
7
AspectU Join Points
use case:
handle
presence
step:
verify
step:
determine
recipients
extension:
presence
probe
step:
determine
recipients
step:
deliver
presence
For example, this subtree corresponds to a join point of type use case;
8
AspectU Join Points
use case:
handle
presence
step:
verify
step:
determine
recipients
extension:
presence
probe
step:
determine
recipients
step:
deliver
presence
this subtree corresponds to a join point of type extension;
9
AspectU Join Points
use case:
handle
presence
step:
verify
step:
determine
recipients
extension:
presence
probe
step:
determine
recipients
step:
deliver
presence
and this subtree corresponds to a join point of type step.
10
Pointcuts in AspectU
Pointcuts identify a set of join points (subtrees).
Three primitive pointcuts are defined:
1. usecase(id) – matches the join point for any
use-case subtree with name matching id
2. extension(id) – matches the join point for
any extension subtree with name matching id
3. step(id) – matches the join point for any
step subtree with name matching id
An AspectU pointcut identifies a set of join points. Pointcuts can be thought of in terms of
matching certain subtrees in the execution. Three primitive pointcuts, which can be composed
to form more sophisticated pointcuts, are defined:
usecase(id) -- matches the join point for any use-case subtree with name matching id
extension(id) -- matches the join point for any extension subtree with name matching id
step(id) -- matches the join point for any step subtree with name matching id
11
Pointcuts in AspectU
• The identifiers used as arguments in primitive
pointcuts can contain the wild-card character *
step(handle*)
• Primitive pointcuts can be combined using and
(&&) and or (||) operators
• Pointcuts can also bind values in the execution
context:
usecase(handle message) &&
bind(m, message)
Here are a few more details about AspectU pointcuts.
The identifiers used as arguments in these primitive pointcuts, are the name of an entity,
possibly including wild cards. So step(handle*) matches an execution subtree corresponding to a
step with name beginning with handle.
Pointcuts can be combined, to form more sophisticated pointcuts, using and and or
operators. In either case the result is a new pointcut. In this talk you’ll see some examples of
these combinations and, of course, it is made more formal in the paper.
In addition to identifying join points, a pointcut can also provide access to values in the
execution context of those join points. This is done using the bind() pointcut, which allows
values associated with the matching join point to be available within the advice body. For
example:
usecase(handle message) && bind(m, message)
Provides a name, m, for the message entity within the handle message use case.
12
Use Case Execution Trees
use case:
handle presence main scenario
step:
deliver presence
use case:
handle presence –
non-local recipient
scenario
use case:
handle message main scenario
step:
deliver message
Now let's run through some very simple example pointcuts. I am going to try to illustrate
these examples using these triangles that represent execution trees in the use-case model. The
first two correspond to different scenarios of the handle presence use case. The third triangle
corresponds to the main success scenario of a different use case called handle message.
Two subtrees corresponding to steps in the use case are shown as smaller triangles: one
corresponding to a step named deliver presence, and one corresponding to a step named deliver
message.
13
Example AspectU Pointcut
step(deliver*)
use case:
handle presence main scenario
step:
deliver presence
use case:
handle presence –
non-local recipient
scenario
use case:
handle message main scenario
step:
deliver message
The pointcut
step(deliver*)
matches the execution subtree of steps with names beginning with deliver. So on this
diagram there are two of these, shown on this slide as smaller, colored triangles .
14
Example AspectU Pointcut
usecase(handle presence)
use case:
handle presence main scenario
step:
deliver presence
use case:
handle presence –
non-local recipient
scenario
use case:
handle message main scenario
step:
deliver message
The poincut
usecase(handle presence)
matches the execution subtree of use cases with the name handle presence. So on this
diagram there are two of these, shown here as large colored triangles.
15
Example AspectU Pointcut
usecase(handle presence) &&
step(deliver*)
use case:
handle presence main scenario
step:
deliver presence
use case:
handle presence –
non-local recipient
scenario
use case:
handle message main scenario
step:
deliver message
In this example the two pointcuts we just looked at are combined using an and operator
usecase(handle presence) && step(deliver*)
In this case we will match only the execution subtree of steps with names beginning with
deliver and that are in one of the execution trees of the handle presence use case. In this diagram,
this would match just one subtree, shown as the smaller colored triangle here.
16
AspectU Advice Parts
1. a pointcut indicating where the additional
behavior should be performed
after() : step(handle*) {
steps:
- server logs delivery
}
Now, advice is a mechanism used to declare that certain additional behaviour should
execute at each of the join points in a pointcut. A piece of advice has three parts:
a pointcut indicating where the additional behavior should be performed,
17
AspectU Advice Parts
2. an advice body describing what the additional
behavior is
after() : step(handle*) {
steps:
- server logs delivery
}
an advice body describing what the additional behavior is, expressed in terms of steps and
extensions, and
18
AspectU Advice Parts
3. a qualifier indicating how the additional
behavior combines with the behavior at the join
point
after() : step(handle*) {
steps:
- server logs delivery
}
a qualifier indicating how the additional behavior combines with the behavior at the join
point.
So this advice says that after the execution of a subtree corresponding to any use-case step,
with a name beginning with handle, an additional logging step should be performed.
19
AspectU Qualifiers
1. before(…) – denotes advice to apply
immediately before the execution of the
matched subtrees
2. around(…) – denotes advice to apply around,
and possibly instead of the matched subtrees
3. after(…) – denotes advice to apply
immediately after the execution of the matched
subtrees
AspectU supports three types of qualifiers, with meanings analogous to the corresponding
AspectJ qualifiers.
• before(binding-list) -- denotes advice to apply immediately before the execution of the
matched subtrees,
• around(binding-list) -- denotes advice to apply around, and possibly instead of, the
matched subtrees (more on this below), and
• after(binding-list) -- denotes advice to apply immediately after the execution of the
matched subtrees.
20
Effecting Behavior with Advice
1. Advice an be strictly additive
2. Around advice can replace a subtree with some
new behavior
3. Advice can introduce extensions, specifying a
new possible flow for the system
Here I want to characterize the ways that AspectU advice can affect the behavior of the
system. There are three distinct ways to do this. First, it can be strictly additive, for example
specifying that before some point in the execution, an additional step should be performed. The
simple logging aspect we just looked at is an example of this.
Second, around advice can replace a subtree with some new behavior.
Third, advice can introduce extensions, specifying a new possible flow for the system.
Now lets look at a more realistic example.
21
Privacy Example
• Affects handle presence and handle message
use cases
• Requires consulting a client’s privacy settings,
before delivering presence and message
stanzas
• Depending on the privacy settings, some
stanzas will be dropped rather than delivered
The example is based on a feature to be added to an XMPP system. The feature is privacy.
Recall that the use case we looked at previously was based on the XMPP specification and it
described how one type of information, a presence stanzas, is to be handled. On the next slide we
look at a use case describing how message stanzas are to be handled.
Adding the privacy feature to the system, requires adding behavior to both of these use
cases.
The added behavior is that before delivering the stanza, a client’s privacy settings should
be consulted. If this privacy check fails (that is, delivering the message would violate the client’s
privacy settings) the stanza should not be delivered.
22
Use Case: Server handles message stanza (handle message)
Trigger: Entity sends message (send)
Main Success Scenario
1. server processes and verifies message (verify)
2. server determines recipient of message (determine recipient)
3. sever delivers message to recipient (deliver message)
Extensions:
2a. Non-local recipient
2a1. route message (route)
2b. No such client
2b1. reply with ‘recipient unavailable’ (error)
3a. Delivery failed (delivery failed)
3a1. reply with ‘recipient unavailable’ (error)
This use case describes how another type of information, messages, is to be handled. The
handle message use case comprises three steps: verification, addressing, and delivery of message
stanzas. Various exceptional situations are described in extensions 2a, 2b and 3a. Adding the
privacy feature here would mean adding a step to do the privacy check and adding an extension
to handle the privacy check failure.
Now it would certainly be possible to add the privacy feature directly to this use case and
to the handle presence use case, however I am going to show how AspectU can be used to
modularize this concern.
23
before(user, stanza) :
(step(deliver message) && bind(user, recipient) &&
bind(stanza, message)) ||
(step(deliver presence) && bind(user, entity) &&
bind(stanza, presence))
{
steps:
- server verifies stanza against user’s
privacy settings (check privacy)
extensions:
- name: privacy check failed
source: check privacy
steps:
- silently drop stanza (drop)
}
Here is an AspectU aspect that captures this behavior. So that I can describe a few parts of
this, I want to simplify it a bit.
24
before() :
step(deliver message) || step(deliver presence)
{
steps:
- server verifies stanza against user’s
privacy settings (check privacy)
extensions:
- name: privacy check failed
source: check privacy
steps:
- silently drop stanza (drop)
}
The first part of it is the qualifier and the pointcut, shown here in bold. Together these state
that the additional behavior should be applied before the execution of any subtree corresponding
to the deliver message step and before the execution of any subtree corresponding to the deliver
presence step.
25
before() :
step(deliver message) || step(deliver presence)
{
steps:
- server verifies stanza against user’s
privacy settings (check privacy)
extensions:
- name: privacy check failed
source: check privacy
steps:
- silently drop stanza (drop)
}
The body of the advice, describes the additional behavior. First there is an additional step,
the actual check of the privacy settings.
26
before() :
step(deliver message) || step(deliver presence)
{
steps:
- server verifies stanza against user’s
privacy settings (check privacy)
extensions:
- name: privacy check failed
source: check privacy
steps:
- silently drop stanza (drop)
}
Then if this check fails, the added extension describes how the system should respond.
Specifically that the stanza should be dropped and the delivery step skipped.
So we have a modular representation of this crosscutting behavior.
27
The Problem
1. Lack of support for modularizing crosscutting in
other behavioral models, and in particular the
use-case model
2. Scattering across models
Here is the two part problem that our work addresses. AspectU is a start on addressing the
first part. With AspectU we can keep some crosscutting concerns in the use-case model
modularized. However there is another kind of scattering going on, that is cross-model scattering.
The discussion about scattering across models will be quick, my goal is to give you some idea
about this problem and tell you at a high level what we did towards addressing this problem. The
details of course are in the paper.
28
Behavioral Models
Use Cases
AspectU
Source Code
AspectJ
To understand this cross model problem, consider this situation. A developer can use
AspectU to modularize concerns at the use-case level, and AspectJ to modularize concerns at the
implementation level.
The cross-model scattering problem, then, is simply that the same concerns will exist in
multiple models. The privacy concern (for example) affects both the use cases and the
implementation. An AspectJ implementation of that concern, can not be easily understood in the
context of the use case model. An AspectU implementation can not impact the running system.
I think this is an interesting problem and we certainly haven’t solved it. What we have
done is explored these issues in the context of a translation tool that was designed to translate an
AspectU aspect into an AspectJ aspect.
29
Behavioral Models
Use Cases
AspectU
Sequence Diagram
AspectSD
Source Code
AspectJ
To facilitate this translation we introduced a third aspect language, AspectSD, which
targets the sequence-diagram model. So our translation tool the follows a two stage process,
AspectU to ApsectSD and AspectSD to AspectJ.
30
Pointcut Comparison
AspectU pointcuts identify subtrees corresponding
to use case, step and extension execution
subtrees
AspectSD pointcuts identify sequences of
messages
AspectJ pointcuts identify points in the execution
of the program (method calls, method returns, etc)
I haven’t talked about AspectSD, but here is a summary of the pointcuts in each of the
three languages.
AspectU pointcuts identify subtrees corresponding to use case, step and extension
execution subtrees.
AspectSD pointcuts identify sequences of messages.
AspectJ pointcuts identify points in the execution of the program.
31
Our Translation Tool
• Depends on a mapping between the use-case
model and the sequence-diagram model
• Similarly, depends on a correspondence
between the sequence-diagram model and the
source code
Our tool depends on a mapping between a system's use cases and its sequence diagrams.
And similarly it depends on a correspondence between the sequence diagrams and the source
code.
I need to be clear here, our translation focuses on translating the AspectU poincut,
including the value bindings and information about the control flow. This can be thought of as a
translation of the information about where in the model the additional behavior applies and how
the flow of the application is affected. As you may guess, we do not magically translate the
additional behavior (i.e. steps aren’t automatically translated into java code, instead the user
supplies the Java implementation as input to the translation tool).
32
Our Translation Tool
• We implemented a prototype of this translation
tool and used on OpenIM system
• Details (including the limitations) are discussed
in the paper
We tested used our tool on OpenIM, a server implementation of the XMPP specification.
I am not going to say more about this now, but the details (including the limitations) are
discussed in the paper.
33
Related Work
• Aspect languages such as AspectJ, Hyper/J,
and Caesar
• Concerns spanning multiple document types
[Batory et al. 2002, Batory et al. 2003]
• Early aspects, Cosmos [Sutton et al. 2002]
Our work is related to a some previous work, including: work on aspect languages such as
AspectJ and Hyper/J, work by Batory and others to do with crosscutting concerns that span
multiple document types, and generally, work in the area of early aspects, or aspects in the area
of requirements and architecture just to mention a couple.
34
Summary
• Crosscutting exists in other behavioral models
• AspectU is a way to modularize these concerns
in the use-case model
• AspectU, together with our translation tool,
allows developers to express advice using use
case level concepts while still affecting the
runtime behavior of a system
In summary, we believe that crosscutting exists in other behavioral models. AspectU is a
way to modularize crosscutting concerns in the use-case model.
AspectU, together with our translation tool, allows developers to express advice using use
case level concepts while still affecting the runtime behavior of a system, yielding a natural
expression of some concerns.
35
Questions?
Questions?
Just speculating here but, if there was a unified model of a system’s behavior, where things
like the source code, the sequence diagrams and the use cases are views on this underlying
model. Then it would be possible to develop a unified representation of crosscutting
implementation.
36