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@aosd.ne; sillito@cs.ubc.ca; craig@craiglarman.com; pawlakr@rh.edu; houman@rh.edu; ducasse@iam.unibe.ch; ivar@jaczone.com; acockburn@aol.com; lourenci@lsi.usp.br; JOCoplien@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.