<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
 
<p>Jonathan Sillito wrote:
<br>Dear Jonathan!
<br> 
<blockquote TYPE=CITE>Albertina,
<p>I didn't follow all of the points raised in your message; however I'll
try
<br>to answer the question:
<br><font color="#993366"><font size=+1>Indeed I congratulate you and your
colleagues for having</font></font></blockquote>
<font color="#993366"><font size=+1>produced what might be called a "pearl
of immanent knowledge".</font></font>
<br><font color="#993366"><font size=+1>Sure the beauty of Vancouver enables
you to contact the</font></font>
<br><font color="#993366"><font size=+1>joyness of the world of ideas and
the outcome is knowledge</font></font>
<br><font color="#993366"><font size=+1>that flows like water or a dialogue.
This can be likened to</font></font>
<br><font color="#993366"><font size=+1>the influence Rio de Janeiro had
on my cognitive processes.</font></font>
<br><font color="#993366"><font size=+1>I am amazed with the list of related
work. I have also been</font></font>
<br><font color="#993366"><font size=+1>reading them. Of course what causes
us to select papers</font></font>
<br><font color="#993366"><font size=+1>to unfold further the same topic
is not addressed in your paper.</font></font>
<br><font color="#993366"><font size=+1>However</font></font>
<br><font color="#993366"><font size=+1>I believe Agile software developers
are mainly concerned with</font></font>
<br><font color="#993366"><font size=+1>transcendent knowledge. Hence they
highlight humans as</font></font>
<br><font color="#993366"><font size=+1>first order components in software
developers.</font></font>
<br> 
<blockquote TYPE=CITE> 
<br>> Of course my aim is to understand why sequence-diagram
<br>> model is a bridge between aspects in use case and aspects
<br>> in aspectJ in [Sillito's] research. Why not to skip this
<br>> transition?
<p>Our reasons for introducing a join point model targeting the
<br>sequence-diagram model are practical in nature. We wanted to explore
the
<br>possibility of translating an AspectU aspect into an AspectJ aspect.
Using
<br>AspectSD as an intermediate step seemed to make this translation easier
to
<br>formalize and explain.
<br> </blockquote>
<font color="#CC33CC"><font size=+1>I have just finished overhauling your
paper. Of course you have</font></font>
<br><font color="#CC33CC"><font size=+1>not explained what I had asked
here. Fortunately it is very well explained</font></font>
<br><font color="#CC33CC"><font size=+1>in your paper.Obviously it cannot
be skipped.</font></font>
<blockquote TYPE=CITE> 
<br>More generally I think it is interesting to think about applying aspects
to
<br>lots of different behavioural models, which means defining a join point
<br>model targeting each. In our ecoop'04 paper we present a sketch of
how this
<br>might look in the case of the sequence-diagram model.</blockquote>
<font color="#CC33CC"><font size=+1>And I believe you were tremendously
well successful. It is the first</font></font>
<br><font color="#CC33CC"><font size=+1>time I have a true glimpse of how
to implement my ecodesign model.</font></font>
<blockquote TYPE=CITE>Given the number and
<br>complexity of the behavioural models that exist for software systems,
we
<br>have just scratched the surface.
<br><font color="#CC33CC"><font size=+1>You are being too humble. When
one discovers a true germ all we</font></font></blockquote>
<font color="#CC33CC"><font size=+1>need is time and patience  and
luck to unfold it further. Of course</font></font>
<br><font color="#CC33CC"><font size=+1>the trailblazers who are opening
the gate to AOSD have had the</font></font>
<br><font color="#CC33CC"><font size=+1>first glimpse. Now if we wish to
implement whole domain models</font></font>
<br><font color="#CC33CC"><font size=+1>especially those concerned with
art as is my case obvioulsy we</font></font>
<br><font color="#CC33CC"><font size=+1>need to introduce aspects in dynamic
languages such as AspectS</font></font>
<br><font color="#CC33CC"><font size=+1>(aspectSqueak). Better to promote
delegation that is also a weaver</font></font>
<br><font color="#CC33CC"><font size=+1>like in Self (a simplification
of Smalltalk).</font></font>
<br><font color="#CC33CC"><font size=+1>Christopher Alexander who inspired
the design patterns community through</font></font>
<br><font color="#CC33CC"><font size=+1>his A pattern language</font></font>
<br><font color="#CC33CC"><font size=+1>is now trying to implement his
ideas on The Nature of Order (geometric</font></font>
<br><font color="#CC33CC"><font size=+1>concerns) in Squeak.</font></font>
<br><font color="#CC33CC"><font size=+1>I am glad to know this especially
when one reads about his viewpoint</font></font>
<br><font color="#CC33CC"><font size=+1>on computer science in his famous
OOPSLA'97 lecture invited by</font></font>
<br><font color="#CC33CC"><font size=+1>Jim COplien.</font></font>
<br><font color="#CC33CC"><font size=+1>In this quotation it seems again
you are responding the first question:</font></font>
<br><i><font color="#999900"><font size=+1>A different approach, that may
not suffer these limitations</font></font></i>
<br><i><font color="#999900"><font size=+1> could involve applying
aspect languages similar to AspectU</font></font></i>
<br><i><font color="#999900"><font size=+1>in the context of a model-driven
approach. Using such an approach</font></font></i>
<br><i><font color="#999900"><font size=+1>higher level models are used
to drive the generation of the source model.</font></font></i>
<br><i><font color="#999900"><font size=+1>In this context, aspect languages
based on the appropriate models could be used to influence</font></font></i>
<br><i><font color="#999900"><font size=+1>the source code generation.
This approach might give the ASpectU aspects</font></font></i>
<br><i><font color="#999900"><font size=+1>more control of the flow of
the system, avoid the cost associated with maintaining</font></font></i>
<br><i><font color="#999900"><font size=+1>a mapping between models, and
overcome key limitations with our current</font></font></i>
<br><i><font color="#999900"><font size=+1>approach.[Sullito's ECOOP2004
paper]</font></font></i>
<br><font color="#999900"><font size=+1>Perhaps you could expand this further.
It seems this creates a link to Racoon's fractal</font></font>
<br><font size=+1><font color="#999900">model where h<i>e </i></font><i><font color="#FF6600">uses
fractal phase definitions to show that the phases resemble each other.</font></i></font>
<br><i><font color="#FF6600"><font size=+1>I show that we can view the
whole life cycle in terms of each phase and view each phase</font></font></i>
<br><i><font color="#FF6600"><font size=+1>in terms of the whole life cycle.
By transitivity, the phases are essentially identical.</font></font></i>
<br><i><font color="#FF6600"><font size=+1>So our assessment of where a
project is shows our perspective about the project rather</font></font></i>
<br><i><font color="#FF6600"><font size=+1>than any essential truth about
the project.</font></font></i>
<br><i><font color="#FF6600"><font size=+1>Developers use all skills throught
a project. Developers often get caught up insmall</font></font></i>
<br><i><font color="#FF6600"><font size=+1>problems and forget how they
relate to other problems that come before and after, or</font></font></i>
<br><i><font color="#FF6600"><font size=+1>above and below the focus of
attention. Developers need to keep the whole flow of</font></font></i>
<br><i><font color="#FF6600"><font size=+1>software development in mind
[Software engineering notes vol 20 n01 january1995, page 61-62].</font></font></i>
<br><i><font color="#999900"><font size=+1></font></font></i> 
<br><i><font color="#999900"><font size=+1></font></font></i> 
<br><font color="#CC33CC"><font size=+1></font></font> 
<br> 
<blockquote TYPE=CITE><font color="#CC33CC"><font size=+1></font></font> </blockquote>

<blockquote TYPE=CITE><font color="#CC33CC"><font size=+1></font></font> 
<br>--
<br>Jonathan Sillito
<p>-----Original Message-----
<br>From: Albertina Lourenci [<a href="mailto:lourenci@lsi.usp.br">mailto:lourenci@lsi.usp.br</a>]
<br>Sent: April 8, 2004 7:25 AM
<br>To: discuss@aosd.ne; sillito@cs.ubc.ca; craig@craiglarman.com;
<br>pawlakr@rh.edu; houman@rh.edu; ducasse@iam.unibe.ch; ivar@jaczone.com;
<br>acockburn@aol.com; lourenci@lsi.usp.br; JOCoplien@cs.com
<br>Subject: pointcuts vs sequence diagrams model
<br> 
<p>Hello!
<br>First of all I am aware most of us are not used to
<br>association of thoughts among different areas of
<br>research. Sorry if the text has not enough isotopy
<br>(sense) for most due to my inter-, multi and transdisciplinary
<br>concerns.
<br>It seems finally AOSD community has been producing
<br>knowledge that may be likened to natural language and
<br>hence to start treating software as a living organism indeed
<br>(see my paper from ROOTS'02  in Bergen Norway in my homepage).
<br>This can be seen in Use case level pointcuts  from Sillito, Dutchyn,
<br>Eisenberg
<br>and De Volder
<br>to be presented
<br>at ECOOP'04 in Oslo-Norway. I mean one can trace isomorphic
<br>structures in all levels of software. However the levels per se have
<br>a different nature in natural language.
<br>Since I deal with essentially qualitative concepts to design and plan
<br>sustainable cities, would you please tell me if we can liken
<br>pointcuts to sequence diagrams model?
<br>Of course my aim is to understand why sequence-diagram model is a bridge
<br>between aspects in use case and aspects in aspectJ in sullito's research.Why
<br>not
<br>to skip this transition?
<br>Positional informational is the linchpin in a living organism. If you
have a
<br>mechanism
<br>that chaotically you can match the foot or the head is different from
<br>devising
<br>a mechanism that cause the emergence of things at their right places
as it
<br>happens
<br>in embryological development. I mean according to
<br>Craig Larman Applying UML and patterns, a system sequence diagram
<br>is a picture that shows for a particular scenario of a use case, the
events
<br>that external actors generate, their order, and intersystem events
<br>(1998:137)
<br>While Kiczales et al ECOOP'01 says A pointcut is a set of join points,
plus
<br>optionally, some of the values in the execution context of those join
points
<p>does not imply clearly an order notion. I mean the semantic is not clearly
<br>well defined and this may cause errors.
<br>This is why James Odell (JOT nov-dec 2003)  proposes:
<br>Complex systems should be built simply at first, initially (and gradually)
<br>placing any edge-of-chaos processing with human agents rather than
<br>automated agents.
<br>This is why I see untyped languages and languages with exploratory
<br>programming (like AspectS = AspectSqueak)   as a must to
build
<br>complex systems. Obviously
<br>Java and AspectJ do not match this need.
<br>Sullito et al's  definition for pointcuts in use case level seems
to start
<br>devising
<br>a morphodynamic level  typical of qualitative complex systems
<br>(but it is still attached to tree reasoning and
<br>Christopher Alexander wrote A city is  not a tree making clear
this
<br>is not exactly morphodynamic level - then he wrote A pattern language
<br>that obviously tries to elicit a morphodynamic level) where the notion
<br>of order is implied. However the notion of order here is not sequential,
<br>it is generative or even implicate order as introduced by postquantum
<br>'physicists like David Bohm, Jack Sarfatti and so on.
<br>I mean in music which displays the highest known morphodynamic level
<br>(see my Third  PostDoctorate Scientific Report and also Second)
the
<br>relational
<br>order of chords matters - if this is violated one can compose harsh
sounds)
<br> relational order matters. Likewise in "visual music"  like
my project.
<br> 
<br> 
<br> </blockquote>
</html>