RE: [aspectj-users] UML for AspectJ

[Russell Miles <russellmiles@xxxxxxx>]

I like this approach, it would be great if we had some tools support for this beyond the diagrammatic hacks that I can get away with at the moment. True Modelling support still seems to be a way off at the moment, maybe this will come along as the adoption of AO and understanding of the approach increases.

In terms of capturing the cross cutting concerns (system wide ones really) then I can also see how Use Cases would finish the picture off. I don't completely agree that logging is a low level "implementation" concern, I see it in the same ball park as most passive aspects and therefore should be modelled in much the same way. 

However, I have definitely used stereotypes in class diagrams for the static structure of the classes and aspects but the trickiest part seems to be tying this together in the dynamic modelling, such as the different forms of interaction diagrams. I have yet to come up with a satisfactory representation of crosscutting structure being interacted with in sequence diagrams for example. But once again, with a bit of hacking a means of exhibiting this information can be found but this is still a long way off from being a 'preferred' or even 'agreed' way of doing this.

Russ

On Tuesday, February 03, 2004, at 03:52PM, Kenworthy, Edward (EDS) <Edward.Kenworthy@xxxxxxxxxxx> wrote:

>I think there are three ways you could deal with this: One is to say that
>you are going to use Aspects for low-level "implementation" eg logging. Two
>you could implicitly model it by including as part of one or more design
>patterns and modelling those design patterns using UML (stereotypes for eg)
>or thirdly you could try and model them explicitly. Personally I would go
>with one or both of the first two options - and forget the third one.
>
>Edward
>
>-----Original Message-----
>From: Russell Miles [mailto:russellmiles@xxxxxxx]
>Sent: 29 January 2004 22:17
>To: aspectj-dev@xxxxxxxxxxx
>Cc: aspectj-users@xxxxxxxxxxx
>Subject: [aspectj-users] UML for AspectJ
>
>
>Hi everyone,
>
>I've talked to a couple of people about this because this is one area 
>where my company is keen to see proof that aspects can indeed be 
>modeled.
>
>One of the suggested mechanisms is to look carefully at Use Cases, in 
>particular towards their realizations. Admittedly the logical model 
>calls for some new stereotypes and a perspective change on the 
>developers part but in effect aspects can be modeled as forms of 
>classes within this context. It's at the Use Case realization level 
>that the distinction can be made between a cross-cutting approach or a 
>more traditional OO solution. Admittedly I haven't found anything 
>formal to this effect but this is what has seemed to work reasonably 
>well for me.
>
>Does anyone else out there have anything more formal? I do use the AJDT 
>browser too but that is not much use when you are in the early days of 
>design development and no actual code is in existence so UML still 
>seems to fit the bill at that point.
>
>Just my two pence :)
>
>Russ Miles
>
>On 29 Jan 2004, at 21:54, Eric Bodden wrote:
>
>> aspectj-dev-admin@xxxxxxxxxxx <> wrote:
>>
>>> Hello, I am very new to AspectJ and AOP in general.  I am
>>> wondering if there is any sort of UML specification for AOP.
>>> Specifically, can an AO design fit with a normal OO class
>>> design?  My understanding of AOP is that an aspect is
>>> actually a class(or maybe that a class can hold multiple aspects).
>>> Any ideas?
>> Usually UML does not fit quite well because aspects are designed to
>> _crosscut_ thorugh classes. You could see them as some kind of filter 
>> lying
>> over your whole class hierarchy. Thus UML does not fit very well I'd 
>> say.
>> The only useful visualization I know is the one provided by the Aspect
>> Browser or AJDT tools respectively.
>>
>> HTH,
>> Eric
>>
>> -- 
>> Eric Bodden
>> RWTH Aachen University
>> ICQ UIN: 12656220
>> Website: http://www.bodden.de
>> PGP key: http://www.bodden.de/pub_key.asc
>>
>>
>>
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/aspectj-users
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>