Jan,
I found this (tweaking the template x inheritance) strategy useful not only when
the interface comes from the framework, but, generally speaking, when the
interface represents a crosscut (as used in AOP parlance) concept.
The classical AOP examples apply here: audit logging, security, etc
That raises (for me, at least) an interesting question: how one should properly model
aspects in a UML model ?
As for ending up with a application-specific andromda, as you said, it may or not
be the best solution. I have only one year and two real projects that used andromda, and,
in practice, two similar but distinct versions for the cartridges...
Philippe.
Jan Heise wrote:
Philippe,
thanks for your reply. Sounds reasonable as long as the interface comes from the framework (like net.sf.hibernate.Lifecycle) but in my case I want to have more behaviour into my baseclass besides the inclusion of the interface. So I think I'd definitely want to model this in my UML also, as it's part of the application. Also the result I have in mind worked nicely with the last projects I did.
Regarding new Stereotypes: I could tweak the cartridge but would end up with an application- specific andromda-version as I would generate classes that would inherit from a class that's in the project but not anywhere else. Possibly not the best solution.
Jan
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-user
