WebHome
- Education Page
- Literature
- Presentations
- Discussion questions
- News

Center
Master Program
Course Assignments

Aop
---+ Discussion questions
%TOC%
<noautolink>

---++ Session 2 (Mon 10 Sep)

*Mark:* Information questions:

- Are there any example of aspects applied to functional programming
languages?

- Have other people done any large experimental studies?

- Are there other, non-aspects, solutions to the problem sketched in the
paper?

Discussion questions:

- As said in the paper, aspects take over most of the optimalisation work,
normally done by the compiler. In what sense is this a good thing? Is it
not extremely hard to write aspects by hand and also, don't you need a lot
of them to make it efficient in larger, more complex, systems?

- The paper talks about functionality which cross-cuts the basic system
functionality. They say aspects help you capture these requirements in
actual code. Do you think aspects capture all the cross-cutting
functionality?

*Robin:* I see someone posted a question about optimising earlier today. To be
honest, I had similiar questions about it after reading the paper:

- Is AOP really a new programming paradigm or is it just another
optimisation technique based on existing languages (the paper talks mostly
about optimisations anyway)?

- How does it resolve the complexity of existing languages? It seems that
adding code seperation between an aspect and a compenet will increase the
overall complexity of the system.

And really a genereal question about the relation of the components and
aspects to the weaver. I understood that the aspects are some sort of
rules which control the overall output of the weaver. So I assumed aspects
are somewhat the rule base by which the weaver will work. The weaver will
have to work with components and aspects to generate the output itself.
Correct me if I'm wrong though. So, my question is: How do aspects control
the weaver? I think I understood the main idea but I think the paper says
little about the actual details of the aspect language. It's really a grey
area at this moment.

*Christiaan:* - At the top of page 221 they say that the current state of AOP is
analogous to that of OOP 20 years ago. I hardly ever hear anything about
AOP nowadays and since this paper was written about 10 years ago, does
that mean that the development of AOP is just going slow or that it's just
not as revolutionary and great as they hoped it to be?

- It might be me, but the "tangled" code at the top of page 224 seems to
be easier to understand than the aspect code on page 229. So my question
is: could you explain the code on page 229? And also, does this really
make it easier to program?

- In the table on page 227 they give a couple of examples but they fail to
explain for a lot of them why exactly they are aspects (or why other
things aren't). Is there a better way to define when something in a
program can be seen as an aspect?

- Figure 2 on page 230 shows 3 steps for a program from source to a C
program. Now if you compile that C program that adds another step. What
happens when the end result crashes? Will it be traceable at all what part
of the original code caused the error? I.E. is it possible at all to do
decent debugging?

- At the bottom of page 230 they mention that their weaver is not a
"smart" compiler and that the programmer has to do everything himself. In
the footnote they say that's not so bad, but could it be done better?
Would it be possible to make such a "smart" compiler? And would that be
useful or would that actually completely contradict the whole point of
AOP?

- On page 235 they mention a 'join point representation', but it's not
really clear to me what that would be. Could you shed some more light on
this?

*Peter:* What kind of 'join points' are possible? 
Is it limited to matching on (nested) functions calls? 
Or is it also be possible to hook into things like an assignment?
Or when an object is passed around?

On Sun, Sep 09, 2007 at 02:07:12AM +0200, Christiaan Hees wrote:
 - Figure 2 on page 230 shows 3 steps for a program from source to a C
 program. Now if you compile that C program that adds another step. What
 happens when the end result crashes? Will it be traceable at all what part
 of the original code caused the error? I.E. is it possible at all to do
 decent debugging?

related to this: what if the programmer isn't satisfied with the result
of its aspect programs, of example the end program is still using to
much memory.  Would there be any way to find out which aspect program
needs to be improved, or where another one might be needed? (Or conclude
that this is as good as it gets...)

At the bottom of page 228 they show that the program is slightly adapted
to make the use of aspects possible (/easier).  Does the programmer need
to know the kind of aspect programs that are going to be applied before
starting to code?

*Martijn:* How does one recognize a problem can be easily solved using AOP? Or, how
does one recognize whether an existing solution can be simplified using AOP? 

---++ Session 3 (Thu 13 Sep)

*Peter:* Is it possible for an aspect to extend another aspect (maybe that would
be another way of doing the MoveTracking and Mobile examples?).  Or
would that just come down to re-using the pointcut's ?

AspectJ and IDE integration: are there tools that allow for easy
integration, like some tool that tells given some pointcut where it will
be will crosscut the program (/source code) ?  Or should every IDE
extension implement this logic itself?

*Robin:* - At chapter 3.3 in the paper, they state that upon arrival at a join
point, all advice in the system is examined to se whether any apply at the
join point. It collects all advices and try to match those with the
current evaluated method/function. Can this have some sort of influence on
the system performance (especially on more advice given ;-)?

As follow up question:
- At chapter 4 they say that the AspectJ language uses a compiler. At
chapter 3.3 they talk about runtime (if I'm correct though). What's the
implementation? Is it both a compiler and runtime library or just the
compiler?

*Alesya:* 1.  The paper and tutorials on AspectJ say that the three types of advice
that are available - before, after and around - allow applying advice to
methods. But what if I want to insert a logging statement somewhere in the
middle in the method code? Or when I do debugging and I want to see the
intermediate results, I would have a log.debug statement inside a method.
Is it possible to somehow accomplish that with AspectJ? I could think of
writing a pointcut for every logging (debugging) statement that's in the
middle of the method. But I was wondering if there is another way of doing
this?

2. Another question that I have is about precedence. Imagine defining
before, after and around advices for the same pointcut, I wonder what the
execution order of the advices will be? Will the order be before, around
and then after or the other way around?

*Martijn:* Can you please discuss the primitive pointcut cflow in detail? I am
particularly interested in the semantics of the composition of those
pointcuts: cflow(P) && cflow(Q) and cflow(P && Q). This is explained
briefly in the Programming Guide, but I find it very difficult to
understand. Perhaps you can give a clear, concrete example?

Also, what is the difference between cflow and cflowbelow, and cflow and
within? Is within just a more specific version of cflow?

*Christiaan:* When you have something like:
receptions(void FigureElement.incrXY(int, int))
and the example from fig. 1. in the 2001-ecoop paper...
If you call Line.incrXY(int,int) it will match... but what if that method
forwards the call to Point.incrXY(int,int)? Will it match again? And if so,
is there a way to prevent this bubbling up effect? Or don't you need this in
practice anyway?

But at the top of page 17 they seem to say that you can do that with cflow,
but it's still a bit unclear. Is this indeed the way to do it?

---++ Session 4 (Mon 17 Sep)

*Mark:* 
   * How is the tool support for using aspect-oriented implementations of design patterns?

   * The papers both discuss the implementation of design patterns using aspect-oriented implementations. Especially the HK paper describes there general aspect solution using a special protocol aspect. I was wondering whether there are more of these "aspect patterns".

   * The papers concentrate on the implementation advantages of aspect-oriented and object-oriented implementations of the design pattern. However, it is still a lot of work to go through all the code to understand the program. UML makes our life easier by giving us a picture of the system. Of course, this is all in favour of object-oriented programs where an UML entity more or less equals an object in the system. What are the plans for aspect-oriented models in this sense? Are there plans for the UML standard to support aspects?

   * Both papers agree on some design patterns that aspect-oriented implementations improve the modularity. So it seems like if this is the case, then we can only gain by using the aspect-oriented approach. Or are there also disadvantages by using aspects in design patterns?

*Robin:*
   * In The Java Programming language (3rd edition) they state that multiple inheritance complicated the design and use of class hierarchies (and so they ditched it). However, AspectJ provides a way to attach interfaces and implementations to existing classes. Will this AspectJ-feature make the designs of your AoP programs more complicated?

   * In the first paper, on page 167, they state that they can generalize pattern code. I'm not following that actually. How is this possible?

   * In the second paper they have an example with an UML diagram shown. Is there a standard UML extension (UML2.0 is extendible; a great example of this is Realtime-UML) for AoP?

*Alesya:* 1. By reading the papers I think the authors failed to address a point of
composing several patterns together since patterns seldom exist in
isolation. Is it possible to compose aspects that allow patterns
interacting together?

2. I wonder if any new design patterns emerged with the AOP introduction.

*Martijn:* The implementation of the Singleton aspect as provided by the authors of
the first paper (available at [1]) is based on intercepting constructor
calls, which allows weird stuff like this:

<verbatim>
import junit.framework.Assert;

import org.junit.Test;

public class Universe implements Singleton {
       
        @Test
        public void test() {
                Assert.assertTrue(new Universe() == new Universe());
        }

}
</verbatim>

It is every programmer's intuition that this test should fail, yet it
succeeds. Can you write a different generic implementation of the
Singleton pattern that does not abuse constructor calls like this?

When you have your different implementation: do you really need AOP for
this, or would the standard Java language suffice?

---++ Session 5 (Thu 20 Sep)

*Alesya:* 1. In the Advice Weaving paper on page 27 they show a woven code fragment
for the before advice. Could you please explain why do they create
temporary variables to operate the before advice (although maybe for the
after advice that would be sufficient). Seems like they create redundant
variables.

2. How is it determined that the optimization of replacing thisJoinPoint
with thisJoinPointStaticPart can be made?

3. In the paper about semantic-based weaving, they say that it is a
powerful mechanism. Maybe you could give the examples when semantic-based
weaving might be beneficial.

*Robin:* The following questions are related to the performance of the AspectJ
weaver, as stated in chapter 6 of the "Advice Weaving in AspectJ" paper:
- In Chapter 6 the authors state that the final approach to improving
performance is to support incremental recompilation. Is this issua
already resolved in newer version of AspectJ and how does it affect
performance?

- As a more global question: the paper describes some performance issues
for an AspectJ version prior to 1.1. The current version is 1.5.3. What
are the performance improvements of the newer versions in comparison to
the older versions?

To be honest with you: I tried reading the second paper and it took me a
long time to finish it. I thought the paper was quite difficult (for me)
to read. I think I don't understand it at this moment. So for I've only
come up with one question:

- The introduction talks about using Aspect Oriented Programming at
design time or at the requirements analyses instead at implementation
time itself. The paper then talks about several algorithms to make this
possible. Is it already used in the real world? Or is it still onlye
theory?

*Mark:* In the paper "An Overview of AspectJ", session 2, page 17, section 4.1
"compilation of advice bodies". They say, that an 'around' advice is
compiled into multiple methods. Could you explain to me why, since I do
not understand the way they explain it and the other paper doesn't
specifically mention it.

In the second paper, they start by saying that semantic-based weaving is
"far more appealing and powerful mechanism". Could you point out some of
the advantages and disadvantages of this? Also, is it useful to be able to
do semantic-weaving?

Later on they are rewriting HMSC to other HMSC, because of breaking some
infinite cycles (I think). Could you shed some more light on this specific
part? What are they trying to accomplish? How do they try to do this? An
why is this valid, since it seems to me like they are changing the flow
(see figure 11).

The whole second paper is pretty theoretically, but they actually say they
are still implementing this in a framework called UMLAUT. So, could you
show a more concrete example of this weaving? What would I have to type
into this framework to get something, for example.

*Peter:* 
In the paper 'Advice Weaving in AspectJ', section 7, show that
there's quite a difference in performance depending on how you
write the aspect.  Are there easy ways (besides benchmarking)
for a programmer to find out if his aspected can be improved.

I was also wondering if they have made (some of) the optimisations
mentioned in the paper, like more/beter fastmatch or the 'basic
engineering' for reducing the overheads.

*Christiaan:* In the Hilsdale paper on page 33 at the top left they mention that some tests
were found to fail. Do you have any idea why they failed? It seems to me like
an important issue when you add a simple logging Aspect that some bechmarks
actually fail, but they don't seem to mention it anywhere else. Could it be
that the aspects changed the code in a destructive way? i.e. are there
situations where it's not trivial to add logging with aspects?

---++ Session 6 (Mon 24 Sep)

*Mark:* - Why won't they simplify the language to make it easier to parse? Would
that result in a loss of expresiveness? Or is it actually possible to
change the syntax in such a way that it is easier to parse, while
maintaining it's strength?

- Could you tell something more about SDF? Are there applications which
use SDF? What are the advantages and disadvantages of SDF, in general?
Maybe you can also give a small sketch on how SDF is implemented.

*Christiaan:* On page 213 at the bottom right they say that the Pattern Parser is 
handwritten which is a bad thing. Is there a good reason to do this part by 
hand? Would it be possible to also use a parser generator here? Some sort of 
subparser? Or would that be a waste since you can't reuse the (although 
perhaps incorrect) tokens anymore?

Is the aproach of the abc parser inherently better than the one used for ajc?

Is there such a thing as Parser Aspects?
They talk about Mixins, but can't you consider them also as some sort of
Aspects?
On page 221 at the bottom right: "AspectJ imports the grammar mixin
JavaMix four times, once for every context." This sounds to me like the
JavaMix could be an aspect of those contexts (crosscutting them).

On page 224 on the bottom right they mention: "the cost of scannerless
parsing is linear in the length of the input, although with an important
constant factor."
I can't see the constant factor in the graphs. They all seem to originate
from 0,0. If there was a constant factor wouldn't they originate from 0,50
or something like that?

*Alesya:* I can imagine that lexical analysis of AspectJ is supposed to be difficult as
there are several different languages that have to be parsed: regular
Java code, aspect and pointcut definitions. The paper says that the lexer
is stateful which means it recognises different tokens in different
contexts. I was wondering if  the actions taken by the lexer when
encountering one of the keywords are customisable.

*Martijn:* - SDF is a parser generator. For which language(s) does it generate parsers?
- Is it possible to mix normal code with SDF grammars, like it is with other parser generators such as JavaCC or ANTLR?
- Can you please give a small example that shows the power of mixins (section 5.4), and their difference from normal imports?

*Peter:* The abc compiler is intended for easy extending, but ajc is the official
compiler.  Seeing the difference in the way both compilers work, are there
any extensions that have been developed on abc been ported to ajc?

---++ Session 7 (Mon 1 Oct)

*Mark:* - Are there other approaches to using aspects at design level? How do they
work?

- Is this Theme-approach commonly used in practice?

*Martijn:* Can you explain figure 5 to us tomorrow, please?

And can you tell us what the consequences of the determination of the crosscutting themes are? How do they affect the implementation of the system? For example, if the system is implemented in AspectJ, does every Theme aspect correspond to an AspectJ aspect?

*Robin:* Are there any tools that can be used for this approach?

*Alesya:* 1. From the diagrams in the paper it seems that Theme/UML makes use of both
class diagram notation and also sequence diagram notation. I wonder what
additional information does those diagrams have to capture that allows to
depict how cross-cutting concerns relate to each other?

2. Discussion question: There may be situations when requirements
frequently change in the software development process. Do you think that
decomposing requirements into aspects helps dealing with any changes when
requirements evolve?

*Christiaan:* They talk about lexical analysis being done by Theme/Doc a couple of times, 
but isn't that terribly inaccurate and error prone? They actually mention in 
4.1 that they had problems with synonyms and I imagine there will be other 
problems like that. So wouldn't it be easier to model it by hand instead of 
letting a tool try to guess it and then fix the mistakes of the tool?

---++ Session 8 (Thu 4 Oct)

*Martijn:* In section 2.1, they write: "Note that the scope of the advice does not include access to any of the fields of the Iterator object"

Is their analysis of only locally used objects always correct? Or are there ways to "fool" their analysis? With what effects? 

*Robin:* 3.2 Pointer Analysis:
   * The pape talks about an existing interprocedural, flow sensitive, context-sensitive, bottum-up combined pointer and escape analysis. Besides the very long sentence ( :-) ) I never heard of such thing. Could you explain it a bit? Or talk about it a bit? What is it? How does it work?

4 Report Generation:
   * The paper talks a bit about Report Generation. They tried to explain with an example earlier in the paper, but how do you interpret/read these reports? It seemed a bit vague for me.

5 Experience
   * They talk about a report generator they wrote. Where can you find it and how does it work? Can you show an example of the working (a website would also qualify :-) ?

*Mark:* - The combination classification contains all those which couldn't be
classified. Do you, or other people, have any ideas for other
classifications?

- Wouldn't it be useful to make the distinction between before and after
advice in the classification system (both aspect and scope)?

- Is this tool integrated into any IDE? If not, would it be a good idea to
do?

---++ Session 9 (Mon 8 Oct)

*Robin:* - The paper talks about the Hob program specification, analysis and verification system and how it is implemented. But can you tell some more about it (about the users, usage, maybe a small example about it)?

- Are there any other methods/techniques for program specification, analysis and verification for Aspect Oriented Programming/AspectJ ? 

*Alesya:* In paper they state that formats can be viewed as a case of intertype
declarations in AspectJ. Could you indicate what they have in common?

*Martijn:* The paper mentions "call sites". What are they?

Does HOB support the OO concept of inheritance? 

*Christiaan:* - In figure 3 in format Cell they have init:bool twice. Do you have any
idea why that is? Could this somehow be related to Scopes or something?

- If you have a lot of defaults specified, doesn't that make it easy to
make mistakes (especially in bigger systems)? Either because you think
something already has a default or by not realizing that something has a
default. In the paper in section 4 they claim the opposite, but I think it
all just depends on how clear it is to the programmer... perhaps by tool
support. Any thoughts on this?

- In the paper they mention Hyperslices a couple of times. I don't really
know what they are but if you have extra time perhaps you can give a short
intro to them to put it in perspective.

---++ Session 10 (Thu 11 Oct)

*Robin:* - In the introduction the authors talk about precedence. When there  
are two shared join points the weaver will chose which aspect is  
chosen. How will the weaver pick the order? Is it just random or does  
it follow some rule for it? [Introduction section]

- The authors explain the syntax of the composition filters, e.g. a  
name, a type etc. The type is the type of the filter. They give three  
examples for this: Dispatch, Meta or user-defined. Can you explain  
these types (although the Dispatch type is explained in the paper)?  
Are there more filter types available? [3. Composition Filters]

- The paper talks a bit about the Berstein read-write sets for  
detecting possible deadlocks. Can you tell more about this? [4.1  
Resource Model]

- The paper talks about Compose*, a tool for the Microsoft .NET  
platform. This tool can only be used for the .NET platform or are  
there any Java tools available (for AspectJ / ABC) which do the same  
thing (conflict detection)? [5. Conflict Detection & Compose*]

- The authors state that there still are a number of false positives.  
Their tool provides an auto-correct facility, which picks a conflict  
free path if any are available. I can imagine that it is still  
possible to encounter a conflict in some situations. Can the auto- 
correcting facility be turned off? How reliable is the tool at the  
current state? [6. Discussion]

Bonus question:
- In the Jukebox example they state that one requirement couldn't be  
expressed and ensured with the basic filter know-how. They require  
extra knowledge from the Jukebox domain which currently (at time of  
writing) isn't implemented. Is it already possible? Will it be in the  
future.

And on a general note (this is not meant for the presentation): I  
think that the example they're giving in the paper isn't entirely  
correct. They say that when the player is idle then it will start a  
thread and start playing songs. For this example I think it would be  
more usefull when the player starts playing IF there is 1 or more  
elements available in the queue. If someone keeps using the player  
(by keeping a button pressed) the music won't play :-). Or maybe I  
misunderstood that bit ;-).

*Mark:* - How does the paper from session 8 compare to this paper? What are the
differences, advantages/disadvantages, etc. ?

- Related to Robin's question: could you explain some more about the
Resource-operation model?

- What determines the order of the filters (enqueues, check, withdraw) in
the tree? (Figure 3)

*Christiaan:* Could you explain Listing 3 and 4 a little better or perhaps give another 
example to make it more clear cause I don't think I understand everything 
they say about those concerns.

At first they say that the problem is that if multiple developers make 
different but overlapping aspects that they are not fully aware of eachothers 
code and therefore you might get problems with composition.
Then in their solution they use these composition filters and concerns, but it 
seems to me that to be able to write those concerns you need to be aware if 
all overlapping aspects already. And if you have that knowledge anyway, then 
you could just solve those problems of composition using declare precedence 
like they said in section 2, so what's the point?
I feel like I'm missing something here or perhaps not fullly understanding it, 
but it seems a bit weird...

*Alesya:* From the explanation in the paper it seems that they analyze conflicts
statically. But is it always possible to analyze conflicts statically, I
can imagine some conflicts may occur at run-time and in this situation
dynamic verification might be useful. I wonder if they have built some
tools that allow dynamic verification or you just have to rely on the
messages at compile time.

*Martijn:* In the paper the distinction between application-specific information and filter-specific information is mentioned several times. What is meant exactly by these two terms? 

---++ Session 11 (Mon 15 Oct)

*Mark:* - I can imagine there are other ways to model these relationships, for
example, by extending the Java language itself, introducing new keywords.
Are there any projects which actually do this?

- The paper mentions a couple of times that they don't use most of the
AspectJ functionality, like join points and pointcuts. They do use the
inter-type declarations. Do you think using aspects is an overkill for
modelling relationships?

- Section 3.2 states that they have several classes for StaticRel, namely
StaticRelX for X >= 1. This is because of the name collision on the
fields. Are there any solutions to this problem, or any ideas on how to
solve this in the AspectJ developement pipeline?

*Peter:* UML also allows for grouping of object/classes (packages, systems with
subsystems, etc..) and defining relations between these groupings.
Can this also be captured using relation aspects?

*Robin:* - The Relationship Aspects are implemented using Java Generics. Generics are based on C++ Templates (or on some other language constructions). So, would it be possible (or is it already done?) to port this over to AspectC++?

- In section 3.3 the authors state that a dynamic relationship can be created and discarded when needed. Can you give an example of this?

- In section 5.4 the authors talk a bit about patterns. We discussed patterns earlier in the course. Will the patterns benefit more from using this technique?

*Martijn:* The paper makes heavy use of generics. What would their solution look 
like without generics?

*Alesya:* 1. How can you store additional information together with a relationship?

2. I've read that there exist patterns for relationships (Relationship as
Attribute and Relationship as Object). I wonder what the difference is
between their implementation and which pattern is more preferable?

---++ Session 12 (Thu 18 Oct)

*Mark:* For Martijn:
- Do you think it's worthwhile to refactor old OO code to AO code, or
would it be better to re-design the whole system (or just leave it as it
is)?

- Is refactoring of concerns important for new systems which already use
aspects from the start? Or would it for those systems be more useful to
use the practical refactoring methods proposed in paper 2?

For Robin:
- Any tool support for aspect refactoring?

- Can the refactoring of concerns from paper 1 be translated to a
composition of refactorings proposed in paper 2?

*Alesya:* (Paper "Catalogue of Refactorings and Code Smells in AspectJ"):

1. Is it possible to measure the value of aspect introduction in a system?

2. I wonder if there are any metrics to measure the effects of refactoring
and whether aspect-oriented systems need different metrics than regular
systems?

3. In the paper they talk about fragile pointcut problem. Could you please
explain this problem in a little more detail and are there ways to solve
it?

(Paper "An Approach to Aspect Refactoring.."):

4. Are there any tools that provide automatic refactoring?

5. Are there ways to detect if the original functionality is preserved
after refactoring?

*Peter:* Paper "Towards a Catalogue of Refactorings and Code Smells in AspectJ":
* Maybe I missed it but, why the 'Change abstract class to interface' and
also a 'Split abstract class into aspect and interface' ?
* The 'Introduce Aspect Protection' solution seems to me a bit hacky with
its declare warning/error.  If it's a common refactoring, perhaps it would
be beter to add a keyword for it (something like 'aspect-protected')?
* 'Tidy up internal aspect structure' is a bit odd compared as it's just a
case of try apply stuff, is it really a refactoring?

Paper "An Approach to Aspect Refactoring Based on Crosscutting Concern Types"
* What other crosscutting concern types are there besides the 'consistent
behavior', 'contract enforcement' and 'superimposed roles' ?

---++ Session 13 (Mon 22 Oct)

*Mark:* - Paper 1 -
Are inter-crosscut variables the same thing as inter-type variables? If
so, how would they cope with inter-type methods?

Do you think it's feasible to define aspect requirements as they proposed
in section 5.1?

- Paper 2 -
The composition of aspects can be implicit or explicit. In AspectJ
composition is implicit, ie. there is no order defined in which aspects
are composed. Wouldn't it be better to require explicit composition and
evade all these interaction analysis?

*Christiaan:* Douence paper:

How is this system supposed to be used? Does a programmer have to define his 
aspects in terms of this logical language and then you can reason about it or 
something? Or can this information be automatically extracted from a program 
with aspects by a tool? Or does a programmer define his aspects using this 
language first and then transforms it to actual code? Or it this whole system 
only theory?
Perhaps you can give some more information about the framework that they 
extend?


Mehner paper:

In 3.1 they mention that "the inheritance relationship was rendered by 
flattening all the associations of Travel to Flight and Rental". What exactly 
is that flattening and does it have any consequences?

I don't really understand how two things can be both a conflict and a 
dependency. Redeem_flight conflicts with Earn_flight according to Figure 7, 
but according to Figure 8 Redeem_flight depends on Earn_flight. And to make 
it more complicated Earn_flight also depends on Redeem_flight. Could you 
explain a little better how this works?

*Martijn:* Composition, Reuse and Interaction Analysis of Stateful Aspects:

Can you please explain how the recursive definition A ::= ma.A of the aspect works?


Interaction Analysis in Aspect-Oriented Models:

Can you please discuss and explain figure 5 and the relation between figure 5a and 5b in your presentation?

The paper mentions finding matches in graphs, but doesn't discuss how this works exactly. Without going into details, can you give us an idea of how complicated this part is?

---++ Session 14 (Thu 25 Oct)

*Robin:* What I didn't understood in the paper is how DisCo is implemented;  is it an extension for AspectJ? A seperate framework that targets  AspectJ or or something else?

*Mark:* - Could you explain symmetric and asymmetric structuring (Hyper/J vs. AspectJ)?

- Could you give a small summary of both implementations (Hyper/J and
AspectJ) and argue which you like more?

*Peter:* How does this paper relate to the 'Relationship aspects' paper?

---++ Session 15 (Mon 29 Oct)

*Mark:* - Could you explain some more about executing UML 2.0 actions?

- This paper addresses only the non-invasive join point model, ie. they
don't support dynamic join points. Could you say some more about UML and
aspects, especially howto model dynamic aspects?

*Robin:* Questions for Christiaan:
 - More powerful and complex pointcuts than those shown in the paper (5.3 Pointcut modeling) can be specified using the AOEMProfile. Although the paper states that those are beyond the scope of the paper, can you show some more examples of these pointcuts using the AOEMProfile?
 - The AOEM Profile uses a non-invasive joinpoint model, similar to JAsCo, Lasagne or CAM/DAOP. What is meant with a non-invasive joinpoint model?
 - In 6. Weaving executable models the authors talk about precedence of joinpoints. Who will assign these integers? The designer, the UML tool or the weaver? 

Questions for Mark:
 - In order to explicitly reason about traceability of the concerns in architectural views it is necessary that the corresponding concerns are explicitly modeled as first class abstractions. Could you explain this? What do they mean? (3.1 Explicit Modeling of Concerns)
 -  The  paper talks about symmetric and asymmetric approaches. Could you give a small explanation of this? (3.1 Explicit Modeling of Concerns)
- I don't really understand the proposed Metamodel. Could you explain this?

*Christiaan:* In the paper they talk about how they do the modelling but only in the
conclusion they talk a little bit about how it's applied and what problems
they encountered there ("for some concerns it appeared that sufficient
domain knowledge was necessary to define the appropriate queries"). Are
there some more details published about that perhaps? Or could you imagine
some other problems you could run into? Perhaps this could be a discussion
question.

*Alesya:* Paper "Modeling Traceability of Concerns in Architectural Views"
1. In the paper  the authors mention that it is not always possible to
trace the concerns by providing specific names. They say that you need
domain specific knowledge to characterize the concerns. Could you describe
how domain specific knowledge can be applied?

Paper "Towards Executable Aspect-Oriented UML models"
2.Could you describe the difference between the suggested approach and the
approach that we've seen in the Theme/UML. What are their advantages and
disadvantages?

*Martijn:* For the paper on tracability of
concerns: What is meant by "artifacts" in section 3.1?

About the UML paper:

* Since the weaver uses XPath expressions to search for joinpoints,
would it be possible to implement the each specific weaver as an XSL
stylesheet? Why/why not?
* At the bottom of page 32, the authors write: "We would like to point
out that the translation of aspect-oriented actions ... involve many
special cases ..." Can you explain such a special case in detail?
* Would it be possible to combine the ideas in this paper with those in
"Semantic-based Weaving of Scenarios", which we discussed earlier? If
so, can you give us an intuition of what it would look like?

*Peter:* Towards Executable Aspect-Oriented UML models:
  In the conculsion the mention that the (auto) code generated from the
  UML is non aspect-oriented, but doesn't that make it more difficult
  for the implementors to understand what's designed?

---++ Session 16 (Thu 1 Nov)

*Mark:* This is a quite a nice paper! The JPM of an aspect-oriented language is often the key to succes or failure. If it's too complex, people won't understand it, but if it's too simple, it lacks expressiveness. Anyway, I listed a few questions below, although I think you could actually talk about this subject for at least 2 sessions.

- AspectJ uses a mostly syntax-based JPM. Could you elaborate on semantic-based JPMs?

- In the paper they insinuate a state-based JPM. Could you elaborate on state-based JPMs?

- Annotations are a powerful way to select join points. If Java would allow in-method annotations, we would be able to specify very precise where to apply an advice. However, the dynamic features of aspects are not that easily captured. How can we extend annotations to capture the dynamic part of aspects?

- As seen from the paper, AspectJ's JPM is quite powerful, but still lacks some important constructs. Do you think that revising their pointcut language would be a good idea?

*Martijn:* Which of the three models do you think is most useful, if you had to choose one?

*Christiaan:* With these models they can specify join point selections that some aspect languages don't even support. They talk about that like it's a good thing, but I'm not yet convinced of that. I guess it's nice to be able to model what you really want, but if you then can't implement it that way... wouldn't that just make it more confusing for the maintainers because you have to work around the limitations of your language?





</noautolink>