see response below > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, September 06, 2003 4:48 PM > To: [EMAIL PROTECTED] > Subject: [Andromda-devel] RE: [Andromda-user] Looking for docs on > MDR/AndroMDA > > > >The cartridge mechanism provides a way for a user to package up a set of > >AndroMDA customizations into a single jar file. The jar can then be > >easily distributed and shared with other AndroMDA users. The cartridge > >is plugged into AndroMDA simply by adding the jar file to the classpath > >of AndroMDA. A typical cartridge will contain a set of custom code > >generation templates, supporting java classes, and an XML file that > >instructs AndroMDA how to plug these custom pieces into its kernel. > > > > these supporting Java classes, may they depend on uml14.jar ? or > is this reserved for the kernel only ? >
Yes they can depend on UML14.jar. > I was thinking of having some cartridge specific functionality > that would not really fit well in the kernel, and alternative > would be to put this logic in the templates (what I am doing now) > The web services cartridge that I am prototyping has a fair amount of it's own java code in it. It provides it's own scriptHelper class and a collection of supporting classes to help with the code generation. It does not use any of the SimpleUML package and the proxy objects. My code generation templates do not directly use the UML1.4 model elements. I use my java code to generate an intermediate simpler model, which is based upon the UML profile of the cartridge, and then I use that simplified model from my code generation templates. I also make a point of not putting any elaborate code formatting routines into my templates. I put the complicated routines on what I call a 'decorator', but I make a point of making the decorator methods out of sets of small helper routines so that that anything I implement in the decorator could also be easily modified and implemented in the templates too. Here is what my code template looks like for generating an XML schema description: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";> #set ($schema = $transform.createSchema($class)) #set ($xsd = $transform.createXSDDecorator("xsd")) <xsd:element name="$schema.name" type="${schema.name}Type"/> #foreach ( $complexType in $schema.complexTypes ) $xsd.begin($complexType) $xsd.begin($complexType.extension) <xsd:sequence> #foreach ( $element in $complexType.elements ) $xsd.format($element) #end </xsd:sequence> #foreach ( $attribute in $complexType.attributes ) $xsd.format($attribute) #end $xsd.end($complexType.extension) $xsd.end($complexType) #end #foreach ( $simpleType in $schema.simpleTypes ) $xsd.begin($simpleType) <xsd:restriction base="$xsd.basename($simpleType)"> </xsd:restriction> $xsd.end($simpleType) #end </xsd:schema> > I guess the consequences of doing this might be not easy to spot > rightaway ? > I agree with you. I am not sure what the consequences will be yet. So far I like how clean looking my XSD generating template looks. I also like the fact that the code generation template has no dependency upon UML1.4 therefore I will be able to easily port it to UML2.0 if at some point I need to do that. > please note that none of the cartridges depend on andromda-core > dependencies (check the cartridge build.xml), I guess there are > good reasons... > I do not think that it is on purpose that there are no dependencies. I think there are no dependencies yet because nobody has really experimented much with any of the advanced AndroMDA extension features. I think people haven't done it yet because we have yet to provide a good set of examples of what is possible. Based upon my experiences I have an approach that I am starting to warm to for cartridge writing. The steps are: repeat until happy { - design a UML profile, with its stereotypes and corresponding tags, for the problem domain for which you want to do code generation - design an object model that describes the problem domain for which you are doing code generation - transform your model from UML objects to your problem domain specific objects - write your templates so that they use the problem domain model objects instead of the UML objects - allow some sort of backdoor for navigating from the domain model objects back to the UML ones in case of an unanticipated gap in your domain model - write a script helper that helps with generating output from these problem domain model objects } Now let's get a little crazy and see if people can follow what I am trying to say ... If you use this approach formally there is an interesting result. Your problem domain model that you've created turns out to be a sort specification for a new modelling language. A modelling language that is problem domain specific, simpler than UML and describes the domain at a higher level than UML. If you wanted to take this one step more than you could use the MDR repository to generate a JAVA API for your problem domain in exactly the same way the MDR is used to generate the JAVA API for UML1.4. If you did that then you could write your code generation templates for your cartridge using only the generated JAVA API. You'd also automatically have an XML representation for your simplified modelling lanaguage in exactly the same way that UML1.4 has its XMI representation. Did that make any sense to anybody ? Tony ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
