-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Bohlen Sent: Sunday, January 02, 2005 3:19 PM To: [email protected] Subject: [Andromda-devel] Design documents for new features - where?
Hi all, "between the years" (as we say in Germany), I thought a lot about new features for AndroMDA 3.5 or 4.0: * detecting and reacting to model changes (I won't call this model based refactoring any more because it is not) and propagate those changes to generated *and* hand-written code * fast, incremental code generation, on parts of the model, not always loading the entire model * generating code from more than one repository at the same time (e.g. generate control flow from UML activity graphs but JSP pages from XMLish GUI descriptions, define GUI events in the XML code and reference them from a transition in an activity graph) * flexible configuration of AndroMDA (with Spring core?) [CB] I actually think we're almost there already with the flexible configuration part, the only thing we can't currently do is use more than one repository at the same time during generation, I don't see a need to try to refactor just to use Spring. AndroMDA is currently VERY flexible. I'm not saying we can't improve, but I don't think trying to incorporate Spring is the answer (especially since it has slow startup time). * integrating AndroMDA into a CASE tool (e.g. MagicDraw), allowing event based reaction, for example: OCL validation at design time, not at code generation time (using an abstraction layer for being able to integrate with several different CASE tools) [CB] It should be at code generation time AND design time, not just design time. * etc. etc. The tricky thing is that those features are so large that they require a certain amount of design up front (for example, separation of concerns among several AndroMDA components, e.g. an abstraction of the AndroMDA process as a kind of "code generation service", to be used from the Ant task, from the Maven plugin and from the CASE tool integration layer). [CB] AndroMDA already has this separation, it's the ModelProcessor in org.andromda.core (it's completely independent of ant, maven, etc), the AndroMDA Ant task just delegates to the ModelProcessor. The architecture of AndroMDA must evolve gracefully, in a consistent manner so that it remains able to "absorb the forces of change" (wow, didn't I coin a cool term?). :-) This design should be documented as a reference to keep us all "on track" one we will have started the implementation (I tend to forget my basic design ideas after six weeks or so). Question: All this shows the need for design docs. Have you got any ideas where we should manage these documents? CVS? Jira? In what format? MS Word? (Readers might use Open Office to read them). [CB] I think we should place them in CVS in the documentation section with everything else, do them in the consistent xdoc format. Of course new features should be added to JIRA as well. Ideas? Cheers... Matthias --- Matthias Bohlen "Consulting that helps project teams to succeed..." Internet: http://www.mbohlen.de/ [EMAIL PROTECTED] Phone: +49 (170) 772 8545 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
