Menu
▾
▴
RE: [Andromda-devel] Refactoring AndroMDA 3.0
|
From: Anthony M. <to...@am...> - 2003-07-31 01:45:49
|
No critcism was intended on how the UML2EJB script helper was implemented. I think these things are natural evolutionary steps for the project. I wish I could just design things right the first time, but I seem to learn a lot more refactoring code than doing anything else. I'm headed off to Switerland tomorrow, but I'll still be in touch. Tony -----Original Message----- From: and...@li... [mailto:and...@li...]On Behalf Of Matthias Bohlen Sent: Wednesday, July 30, 2003 2:47 PM To: 'Tony Mowers'; and...@li... Subject: RE: [Andromda-devel] Refactoring AndroMDA 3.0 Hi Tony, thanks for this very detailed and interesting description - now I know a little more about the design ideas. I agree with you that the ScriptHelper is a bundle of different things merged into one class. It has too much heritage from UML2EJB (my fault) and urgently needs refactoring. Similar things are true for the proxies - I'll write a proposal for metamodel decorators or wrappers as soon as I find the time. I'll checkin the code as it is now although DefaultAndroMDACartridge.java looks a little ugly, now. :-) In spite of that I do the checkin just to save the currently running software before I continue to refactor. So, please don't pile criticism on me ... be patient, it is not the final state of the code - promised! Cheers... Matthias > -----Original Message----- > From: and...@li... > [mailto:and...@li...] On Behalf > Of Tony Mowers > Sent: Wednesday, July 30, 2003 6:48 PM > To: Matthias Bohlen; and...@li... > Subject: RE: [Andromda-devel] Refactoring AndroMDA 3.0 > > > Hi Matthias and others, > > I will try to answer your questions and how I see the roles > of the Proxy's > and the ScriptHelper's within the context of AndroMDA 2.x. > That way you can > get an idea what I was thinking when I wrote certain code and > you can decide > whether or not to factor that into your refactoring for > AndroMDA 3.x :-) > > Question 1: Why does the script helper have access to the whole model? > > The name "script helper" is really too vague. It does help > the scripts, but > there are several ways that the scripts need help. The help > that the script > needs falls into at least two very different catagories and > so the script > helper has too much functionality in it and needs to be refactored. > > These two catagories are: > > - MODEL FACADE: provides a facade over the meta-model which > isolates the > scripts from changes in the meta-model > - MODEL VIEW: provides help to the script for language specific code > generation > > I believe it is a defect in the current script helper that both these > concerns have been melded into one class. I will elaborate a > bit on each of > these two areas. > > Facade > ------ > In my mind the real test of whether the facade is properly > implemented would > be the following: > > Does the facade make it possible to rev the underlying meta-model from > UML1.4 to UML1.5, SimpleOO or UML2.0 without necessitating > major changes to > the template scripts? If the answer is yes then the facade > has done its > main job of isolating the scripts from changes in the > meta-model. If no > then it has failed it's job. > > I would fully expect there would be different facades for > different problem > domains. For example: all of our current scripts deal almost > entirely with > static model related issues, so it is reasonable that they > all use the same > facade, or at least very similiar facades. But if somebody > were to write a > cartridge that does business process generation, or activity flow code > generation, or state machine code generation then they would > certainly need > to write another facade that provides services specific to > that domain. To > not do so, and to try to adapt one facade to all domains, > would be to my > mind a gigantic architectural mistake. > > View > ---- > The name 'view' is probably not a very good name for it. The > reason I am > using the term 'view' is because I think of a cartridge as > constructing a > view of a model that is implementation specific. For example: > if one uses > the EJB cartridge to 'view' the model then the model > suddenly looks like > it is an EJB implementation. > > Just to hammer the point home; a facade should contain no > knowledge of the > implementation language specifics (it should not care if C++ > code or Java > code is being generated). But, above the facade sits a layer > I am calling > the view. It is in this layer that the implementation > specifics start to > come into existance. > > I am going to stretch an analogy here and compare the view > layer to a GUI. > If the facade exposes a model then shouldn't we ask ourselves > what pieces in > AndroMDA represent the GUI widgets and the GUI Window > instances? In my mind > the code templates are somewhat analogous to the Window > instances. So now > we should ask ourselves where in the AndroMDA framework are > the language > specific widgets that the templates use to help generate > language specific > code? At the moment these 'code generating widgets' are > merged horribly in > with the facade. They appear as an oddball set of methods > tacked onto the > scripthelper. > > The view and the facade concerns really need to be seperated > in AndroMDA > 3.0. > > Question #2: Why do the proxies have a reference to the script helper? > > In my opinion the proxies are a horrible, horrible (one more > time), horrible > idea. Since it was I who created them I think it is ok for > me to be so > critical of them. The only reason the simpleuml package > exists at all, with > proxy objects, is to make AndroMDA backward compatable with UML2EJB. > > The reason I think the Proxies are a bad idea is because it > lets too much of > the underlying meta-model bubble up through the facade. They allow the > templates to become too coupled to the UML1.4 meta-model and > it will make it > a nightmare for us to port the templates from UML1.4 to > anything else. The > problem will be made even worse by the fact that the velocity > scripts are > not compilable and therefore we will only be able to find API > incompatabilities via trial and error. > > Here I would use the following analogy. It is a bad idea to > expose too much > about entity beans to the application layer and so one of the > reasons for > using a session object is to hide the details of the entities from the > application layer. Similarily it is a bad idea to expose too > much about the > objects in the meta-data repository to the template scripts. > > So what does this all have to do with putting references in > the proxies to > the script helper? If you happen to agree with the idea that > the proxies > are horrible idea then it follows that these proxies should > have as little > code as possible inside them. That code actually belongs in > the facade's > implementation. Therefore I put the code in the facade and > had the proxy > objects call back to the facade to perform the functionality. > The idea > being that the facade is the important artifact and the proxies are > something we should be planning to throw away. > > > Hope that sheds some light on why things are the way they are. > > Tony > > > -----Original Message----- > > From: and...@li... > > [mailto:and...@li...]On > Behalf Of Matthias > > Bohlen > > Sent: Wednesday, July 30, 2003 4:32 AM > > To: and...@li... > > Subject: [Andromda-devel] Refactoring AndroMDA 3.0 > > > > > > Hi, Tony and the others, > > > > yesterday night, I spent a little time refactoring the AndroMDA > > core to prepare the ground for the new feature "refactoring at > > model level". (Funny: you need refactoring at AndroMDA level to > > make refactoring at model level possible!). :-) > > > > One thing I did was to move the template processing (all the > > methods "processModelElement*" and below) from the > > AndroMDAGenTask class to the DefaultAndroMDACartridge class. That > > way, the cartridges are now truly responsible for code > > generation, not the core ant task any more. The ant task is now > > responsible to collect all necessary parameters which control > > code generation and pass them to the cartridges. > > > > I did that to enable a cartridge to remember what it generated > > before. It should be entirely up to the cartridge to decide what > > to do when it notices that code for a UML model element is being > > re-generated. > > > > After this refactoring, the cartridge suddenly needed much > > context information (about type mapping, the default script > > helper, the user properties, the switch for lastModifiedCheck, > > etc.). So I had to put all this into a new class that I called > > CodeGenerationContext - I passed an instance of this to the > > cartridge as a parameter to processModelElement(). > > > > After this refactoring, I noticed many complicated calls in the > > cartridge code, like these: > > > context.getScriptHelper().setModel(context.getRepository().getModel()) > > > context.getScriptHelper().setTypeMappings(context.getTypeMappings()) > > > > And I thought: Why does ScriptHelper bother about the model? > > ScriptHelper was designed to adapt the scripts to the UML > > metamodel, in some way. Why should it know the entire model? > > And: Why should it know permanently about the type mappings? > > ScriptHelper was meant to be stateless. > > > > Do you know why? And: could I remove this knowledge from > > ScriptHelper to make it more lightweight? > > > > Similarly, I think the proxies in the simpleuml package know too > > much: they have a permanent reference to ScriptHelper. Why this? > > The proxies should adapt the JMI interfaces to the script - they > > should not need ScriptHelper for this. > > > > Wondering... > > Matthias > > > > __________________________________________________________________ > > ____________ > > ComputerBild 15-03 bestaetigt: Den besten Spam-Schutz gibt es bei > > WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021121 > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 303_01/01 _______________________________________________ Andromda-devel mailing list And...@li... https://lists.sourceforge.net/lists/listinfo/andromda-devel ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Andromda-devel mailing list And...@li... https://lists.sourceforge.net/lists/listinfo/andromda-devel ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Andromda-devel mailing list And...@li... https://lists.sourceforge.net/lists/listinfo/andromda-devel |