Jonathan Sillito wrote:
Dear Jonathan!
> Albertina,
>
> I didn't follow all of the points raised in your message; however I'll try
> to answer the question:
> Indeed I congratulate you and your colleagues for having
produced what might be called a "pearl of immanent knowledge".
Sure the beauty of Vancouver enables you to contact the
joyness of the world of ideas and the outcome is knowledge
that flows like water or a dialogue. This can be likened to
the influence Rio de Janeiro had on my cognitive processes.
I am amazed with the list of related work. I have also been
reading them. Of course what causes us to select papers
to unfold further the same topic is not addressed in your paper.
However
I believe Agile software developers are mainly concerned with
transcendent knowledge. Hence they highlight humans as
first order components in software developers.
>
> > Of course my aim is to understand why sequence-diagram
> > model is a bridge between aspects in use case and aspects
> > in aspectJ in [Sillito's] research. Why not to skip this
> > transition?
>
> Our reasons for introducing a join point model targeting the
> sequence-diagram model are practical in nature. We wanted to explore the
> possibility of translating an AspectU aspect into an AspectJ aspect. Using
> AspectSD as an intermediate step seemed to make this translation easier to
> formalize and explain.
>
I have just finished overhauling your paper. Of course you have
not explained what I had asked here. Fortunately it is very well explained
in your paper.Obviously it cannot be skipped.
>
> More generally I think it is interesting to think about applying aspects to
> lots of different behavioural models, which means defining a join point
> model targeting each. In our ecoop'04 paper we present a sketch of how this
> might look in the case of the sequence-diagram model.
And I believe you were tremendously well successful. It is the first
time I have a true glimpse of how to implement my ecodesign model.
> Given the number and
> complexity of the behavioural models that exist for software systems, we
> have just scratched the surface.
> You are being too humble. When one discovers a true germ all we
need is time and patience and luck to unfold it further. Of course
the trailblazers who are opening the gate to AOSD have had the
first glimpse. Now if we wish to implement whole domain models
especially those concerned with art as is my case obvioulsy we
need to introduce aspects in dynamic languages such as AspectS
(aspectSqueak). Better to promote delegation that is also a weaver
like in Self (a simplification of Smalltalk).
Christopher Alexander who inspired the design patterns community through
his A pattern language
is now trying to implement his ideas on The Nature of Order (geometric
concerns) in Squeak.
I am glad to know this especially when one reads about his viewpoint
on computer science in his famous OOPSLA'97 lecture invited by
Jim COplien.
In this quotation it seems again you are responding the first question:
A different approach, that may not suffer these limitations
could involve applying aspect languages similar to AspectU
in the context of a model-driven approach. Using such an approach
higher level models are used to drive the generation of the source model.
In this context, aspect languages based on the appropriate models could be used
to influence
the source code generation. This approach might give the ASpectU aspects
more control of the flow of the system, avoid the cost associated with
maintaining
a mapping between models, and overcome key limitations with our current
approach.[Sullito's ECOOP2004 paper]
Perhaps you could expand this further. It seems this creates a link to Racoon's
fractal
model where he uses fractal phase definitions to show that the phases resemble
each other.
I show that we can view the whole life cycle in terms of each phase and view
each phase
in terms of the whole life cycle. By transitivity, the phases are essentially
identical.
So our assessment of where a project is shows our perspective about the project
rather
than any essential truth about the project.
Developers use all skills throught a project. Developers often get caught up
insmall
problems and forget how they relate to other problems that come before and
after, or
above and below the focus of attention. Developers need to keep the whole flow
of
software development in mind [Software engineering notes vol 20 n01 january1995,
page 61-62].
>
>
> --
> Jonathan Sillito
>
> -----Original Message-----
> From: Albertina Lourenci [mailto:lourenci@lsi.usp.br]
> Sent: April 8, 2004 7:25 AM
> To: discuss(a)aosd.ne; sillito(a)cs.ubc.ca; craig(a)craiglarman.com;
> pawlakr(a)rh.edu; houman(a)rh.edu; ducasse(a)iam.unibe.ch; ivar(a)jaczone.com;
> acockburn(a)aol.com; lourenci(a)lsi.usp.br; JOCoplien(a)cs.com
> Subject: pointcuts vs sequence diagrams model
>
>
> Hello!
> First of all I am aware most of us are not used to
> association of thoughts among different areas of
> research. Sorry if the text has not enough isotopy
> (sense) for most due to my inter-, multi and transdisciplinary
> concerns.
> It seems finally AOSD community has been producing
> knowledge that may be likened to natural language and
> hence to start treating software as a living organism indeed
> (see my paper from ROOTS'02 in Bergen Norway in my homepage).
> This can be seen in Use case level pointcuts from Sillito, Dutchyn,
> Eisenberg
> and De Volder
> to be presented
> at ECOOP'04 in Oslo-Norway. I mean one can trace isomorphic
> structures in all levels of software. However the levels per se have
> a different nature in natural language.
> Since I deal with essentially qualitative concepts to design and plan
> sustainable cities, would you please tell me if we can liken
> pointcuts to sequence diagrams model?
> Of course my aim is to understand why sequence-diagram model is a bridge
> between aspects in use case and aspects in aspectJ in sullito's research.Why
> not
> to skip this transition?
> Positional informational is the linchpin in a living organism. If you have a
> mechanism
> that chaotically you can match the foot or the head is different from
> devising
> a mechanism that cause the emergence of things at their right places as it
> happens
> in embryological development. I mean according to
> Craig Larman Applying UML and patterns, a system sequence diagram
> is a picture that shows for a particular scenario of a use case, the events
> that external actors generate, their order, and intersystem events
> (1998:137)
> While Kiczales et al ECOOP'01 says A pointcut is a set of join points, plus
> optionally, some of the values in the execution context of those join points
>
> does not imply clearly an order notion. I mean the semantic is not clearly
> well defined and this may cause errors.
> This is why James Odell (JOT nov-dec 2003) proposes:
> Complex systems should be built simply at first, initially (and gradually)
> placing any edge-of-chaos processing with human agents rather than
> automated agents.
> This is why I see untyped languages and languages with exploratory
> programming (like AspectS = AspectSqueak) as a must to build
> complex systems. Obviously
> Java and AspectJ do not match this need.
> Sullito et al's definition for pointcuts in use case level seems to start
> devising
> a morphodynamic level typical of qualitative complex systems
> (but it is still attached to tree reasoning and
> Christopher Alexander wrote A city is not a tree making clear this
> is not exactly morphodynamic level - then he wrote A pattern language
> that obviously tries to elicit a morphodynamic level) where the notion
> of order is implied. However the notion of order here is not sequential,
> it is generative or even implicate order as introduced by postquantum
> 'physicists like David Bohm, Jack Sarfatti and so on.
> I mean in music which displays the highest known morphodynamic level
> (see my Third PostDoctorate Scientific Report and also Second) the
> relational
> order of chords matters - if this is violated one can compose harsh sounds)
> relational order matters. Likewise in "visual music" like my project.
>
>
>
