[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Metadata as projections onto multidimensional space
|
Hi Gregor, Ramnivas,
I am really glad to see that the AspectJ community is moving towards the
combination of metadata and projections to achieve multidimensional
separation of concerns. I always believed that for AOP to become more
successful we need to somehow combine the AspectJ constructs with
MDSOC/HyperJ.
In my Ph.D. thesis I developed an architectural framework, called PCS
Framework, which aims at providing support for developing, documenting
and implementing concern-oriented software architectures. A significant
part of the PCS Framework is a particular implementation of MDSOC for
UML that is based on projections.
Interestingly, when comparing the PCS Framework with the idea of using
"metadata as projections onto multidimensional space" you can observe that:
1. The PCS Framework already has a multidimensional space, called
the UMLSpace (the thesis describes a UMLSpace for Aspect-Oriented
Modeling and gives an example of mapping to AspectJ constructs).
2. The PCS Framework supports the notion of projections as a
mechanism for "reifying concerns into software". What I mean by
projection is an architectural abstraction that defines the relationship
between a specific architectural viewpoint (i.e., a set of concerns) and
a set of models (including the units in those models).
3. The PCS Framework provides a new modeling element, called "model
slice" that is used to represent the reification of concerns into
software. A model slice can be described at code level as a metadata
attached to the units pertaining to a given concern. This allows us to
achieve what I refer to as "architectural design by concerns".
I believe that integrating XDoclet with AspectJ, we will get a more
powerful AOP language that allows one to achieve "programming by
concerns" -i.e., providing more flexibility than the current way of
programming by objects or by aspects.
For those who are interested, my thesis can be found at:
http://ahdoc.epfl.ch/EPFL/theses/2003/2796/EPFL_TH2796.pdf
I will be of course happy to receive any comments and suggestions that
help improve this work.
Mohamed
--
Dr Mohamed Mancona Kandé
Department of Management of Technology and Entrepreneurship
Swiss Federal Institute of Technology Lausanne
CH - 1015 Lausanne EPFL - Switzerland
Mohamed.Kande@xxxxxxx - +41 21 6930012
Gregor Kiczales wrote:
I think that's right. Here's how I look at it:
Tag names give you an explicit and localized way of saying that a single method[1] has a certain property.
Tag names give you an explicit and non-localized way of saying that a set of methods has a (potentially crosscutting[2]) property.
Pointcuts give you an explicit and localized way of saying that a set of methods has a (potentially crosscutting) property.
Notes:
[1] I say method for simplicity, but it can be anything you can put a tag on.
[2] As I said in my AOSD talk, crosscutting is a different way of saying multi-dimensional. As a term it tries to focus on the
particular relationship between organizations that makes them not "fit" together with standard hierarchical (de)compositions.
-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx
[mailto:aspectj-users-admin@xxxxxxxxxxx] On Behalf Of Ramnivas Laddad
Sent: Monday, August 18, 2003 11:51 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Metadata as projections onto
multidimensional space
Hello,
(Triggered by recent discussion on XDoclet/AspectJ integration)
Could method names and metadata be viewed as projections
for the same entity in different dimensions of a
multidimensional characteristics space? Each operation
is then a point in such a space.
With this way of viewing the metadata, the tags define the
dimensions (security, atomicity) with the "core" being the
implict tag associated with the operations name. An operation's
name is a then projection onto the core dimension, whereas,
each metadata is projection onto the corresponding dimension.
atomicity
^
|
| x
|
| ("debit", "required", "authorization")
|
|
+-------------> core
/
/
/
/
/
v
security
A nice thing about this view is each dimension is (by definition)
orthogonal, so it wouldn't be possible to deduce one characteristics
from another. There is no way to tell the security implication of
debit() and credit() method by examining just the (core) name.
-Ramnivas
