AW: [aosd-discuss] Non academic ideas on AOSD

Mon Oct 21 06:45:27 EDT 2002

Hi Dennis,
some comments below,
kind regards
   Arno Schmidmeier

********************************************

Arno Schmidmeier
Sirius Software GmbH
- simplicity out of complexity -

Fon 	+49 (0)9151 /90 50 30
Fax 	+49 (0)89 613 676-33
Arno.Schmidmeier at sirius-eos.com

Yes, we have realized large scale projects with aspectJ
Yes, we do provide consulting for aspectJ based on our experience

> -----Ursprüngliche Nachricht-----
> Von: Juri Memmert [mailto:memmert at jpmdesign.de]
> Gesendet: Samstag, 19. Oktober 2002 00:44
> An: denisbilas at yandex.ru
> Cc: AOSD
> Betreff: RE: [aosd-discuss] Non academic ideas on AOSD
> 
> 
> Am Fre, 2002-10-18 um 15.47 schrieb Denis Bilas:
> 
> Hi Denis,
> 
> 
> > > Especially in serious projects, you normally could apply 
> > > aspects very well. 
> > > Serious projects have normally all what helps applying aspects: 
> > > *good understanding of the architecture, 
> > > *good QA 
> > > *emphasis on good design 
> > > *emphasis on quality 
> > > *have very skilled developers on board 
> > > *And NO "HACK NOW DESPARATE LATER" mentality 
> > 
> > I have been involved into several mid-large projects (about 500
> > human-made classes). And none of them featured the entire collection
> > of that bullet topics! Moreover, I think that having in 
> place all that
> > good stuff the project will do quite well even without 
> aspects (but I
> > concur it could be somewhat better with them).
> 
> Of course, the criteria listed above would be beneficial to 
> any project,
> not only AOSD projects.
> But within the context of an AOSD approach, it is necessary that your
> approach is well-based.
> And, of course, many projects are lacking in these criteria, which is,
> of course, no excuse for not striving for them.
> 

I didn´t intent to claim, that you should have all these 
bullet points in place in a formal way, 
before you can apply AOSD. 
The only prerequisite IMHO is that there is no "HACK NOW DESPARATE LATER"
mentality.
(XP-projects fullfill this requirement)

Based on my experience, following rule apply:
Projects which fullfills more of these critierias 
will benefit more from adopting AOSD then other projects.

> 
> > The point: maybe the limits imposed by your requirements 
> are too strict?
> > Do not they filter out 99% of the real life projects?
> 
> Many projects are bad. Adding another technology to a bad project will
> not make it better.
> But if you want to reap the benefits of AOP, you need to be willing to
> invest time and money into making the project better. In the end, the
> application of AOP will give you tremendous benefits, as far as I am
> concerned.

I agree.

> 
> I have spend many months in projects that were completely messed up.
> Employing AOSD approaches, I was able to better organize, 
> understand and
> improve the projects to the point needed to achieve the goal 
> set before
> me.
> In many of these projects, the developers and designers tried to focus
> on all the good qualities in software engineering and they 
> really did a
> good job. Unfortunately, the complexity of the application 
> was more than
> their conventional approach could handle. There, the 
> extension of a good
> approach with AOSD approaches gives the development team the direly
> needed handle on things.
> 

I had similar experiences. AOSD can help to organize a project/product, 
if the project was totally messed up with tangling concerns/ tangling code,
etc.
However the will to do better is a prerequisite. 

> 
> > Or maybe most big projects are not "serious" :)
> 
> ;-)
> 
> 
> > > Appling aspects is a design decision. It should be treated as 
> > > any design decision and not as a hack. If you fear to apply 
> > > AOP in serious projects, I strongly recommend to get a good
> > > coach on board. 
> > 
> > I could mentor my team on the good usage of AOP -- if I knew it for
> > myself.

<shameless advertise>
That is what we have done in the past internal to Sirius and we offer now
the same services to the public.
</shameless advertise>

> > So what I need (to start applying AOP in real projects) is to get
> > myself confident that AOP is safe to use. And I'm pretty sure that
> 
<snip>

What do you need to convince yourself, that it is safe to use?
How do you define safe?

> 
> 
> > using current AOP tools will have a negative impact on design/code
> > manageability of real projects. (One exception is the AOP framework
> > created by Rickard Oberg -- I think it is safe to use, but 
> it does not
> > go far enough from OOP, e.g. can be implemented using Role Playing
> > Pattern -- hence I don't consider it here).
> 

Which kind of tools do you have in mind? If you think about Aspect Oriented
UML drawing monster (like Rational Rose, TogetherJ, etc.), I expect that you
have to wait.

> Sorry, I can't say that this is true.
> AOSD shrinks the size of the modules while increasing the number of
> modules. Complexity doesn't go away, but it becomes more manageable as
> it is in smaller chunks.
> If you're not able to manage a large number of modules, you'll not be
> able to manage any application, so I don't see any problem in any
> OO-savvy project.

I agree here.

> The only important difference between an OO and an AOSD 
> project is that
> the analysis and design documents can not remain one word document of
> 150 pages.
> It will rather be 30 documents of 5 pages. This requires a 
> greater deal
> of abstraction from the developers and the ability to 
> constrain oneself
> to one topic at a time.
> 

I do not agree here. In the worst case, you could concat all 30 documents
and generate one big out of them. ;-)
However the way how and what you document and what your document will look
like should change.
If you want to place the documentation under version control, (What I
strongly suggest)
you should split the 150 document up into smaller parts anyway.

> 
> > Maybe I'm wrong with my estimate. Then I'd like to see some proven
> > methodology (similar to those we have for OOP) that can 
> convince that
> > current AOP is solid. Numerous what-ifs must be closed before I let
> > guys do AOP. 100-line examples do not suffice -- they are 
> only good as
> > demos of basic principles.
>

Note AOP is a superset of old OOP. So you can apply all of the old OO-stuff,
all what you risk is, that you do not get all the benefits out of AOP,
compared to an optimal AOSD adoption.

If you are behind a AOSD methodology, like Jourdan, Coad, Booch, etc. you
will have to wait.

> Proven approaches are difficult to get by at the moment.
> Arno and I are probably the most advanced industrial users (please
> correct me if I'm wrong) and our methodologies are, as of yet, pretty
> much undocumented, beyond some short papers. In the research 
> community,
> there is a lot of work going on, but until this research can be called
> "proven methodology", some time will go by.
> If I may, I'd like to point you toward the paper I wrote for AOSD 2002
> (you can find it at
> http://swt.cs.tu-berlin.de/lehre/seminar/ss02/Papers/Mem02%20-
> %20Designing%20with%20Cosmos.pdf )
> 
> It is probably somewhere else, too, but Google gave me that url. ;-)
> 

Also a proven approach from project A is quite likely to fail in project B,
because 
the constraints of project B wouldn´t work with the approach A.
If you want to have an approach will will work very reliable, you would have
to live with a high overhead. I doubt that you would accept that. 
So I suggest to tailor a given appoach to your special needs, or even
better: 
let some experienced people tailor you a working approach.

> 
> As for the 100-line examples... I never deal with 100-line 
> examples. The
> applications I am working on are up in the "2000+ classes and 10000+
> methods"-range.
> The smallest applications I'm dealing with is somewhere in the "500
> classes, 2500 method" range.
> 

The projects I normally deal with are all based in the 2500+ class range.
I normally use these 100 lines samples only in samples and short tests. 

> 
> > All in all, I currently cannot take the risk of applying 
> > AOP in real projects.

I understand that there must be a clean business case before adopting 
AOP in a real project. I stringly recommend to define a midterm 
adoption strategy.
You may want to start with the adoption in low risk components, 
in a low risk phase. Or if you a fucked up beyond any recovery, 
that may be also a good place to start. 

However I would start with the most rewarding businesscase:
e.g. A places in code or tasks, where you could gain great advantages 
with very little efford.
It is a good idea to consult an experienced AOSD practioneer for this task.

If possible place your best persons on this tasks. Get good coaches on board
or train them. Lerning how to effiecently code and structure AOP-code may
take a while, if it is leaned by trail and error. Also IMHO most of the
current published books and articles are also no help.

<shameless advertising>
We can help you out with individual coaching/mentoring educational
programms.
</shameless advertising>

> 
> This is a pity. I would like to suggest that you look at all the
> different approaches once more and let us know about the problems and
> questions you're facing. Maybe we can solve some of the problems and
> definitely your problems will help us along the way to a better AOSD.
> 
> Regards,
> 
> 	Juri
> 
> _________________________________________________
> AOSD discuss mailing list    -   discuss at aosd.net
> To be removed send mail to discuss-admin at aosd.net
> or visit http://aosd.net
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://server2.hostvalu.com/pipermail/discuss_aosd.net/attachments/20021021/58ab4146/attachment.htm