RE: [Andromda-devel] Prototyping Web Services Cartridge

[Matthias B. <inf...@mb...>]

Hi Tony,

I found this *very* interesting, thanks for sharing it with us.

One question: Do you really mean you modeled a PSM? I have the
impression that you modeled a UML profile for your PIM instead - which
is a very good thing, too! However, I did not look into your material,
yet.

What do you think?

Cheers...
Matthias

> -----Original Message-----
> From: and...@li... 
> [mailto:and...@li...] On Behalf 
> Of Anthony Mowers
> Sent: Monday, August 18, 2003 4:33 PM
> To: Users AndroMDA; Developers AndroMDA
> Subject: [Andromda-devel] Prototyping Web Services Cartridge
> 
> 
> Hi All,
> 
> I have started prototyping a web services cartridge for 
> AndroMDA.  This work is truly a prototype in the sense that I 
> am using it to explore some concepts.
> 
> My objectives for this prototype are to explore two areas:
> - modeling web service related concepts from an MDA perspective
> - general techniques for AndroMDA cartridge development
> 
> I have written this report to let you know what I discovered 
> from my first iteration of the prototype.  I plan to write 
> some other reports as I implement more iterations of the 
> prototype, and perhaps if they are useful I will put them on 
> a web page someplace.
> 
> The table of contents for this report is:
> 
>   Current Prototype Functionality
>   Instructions for Running Prototype
>   Prototype Learning Points
>    Cartridge Development Techniques
>    Modeling XML in UML (UML Profile for XML)
> 
> Current Prototype Functionality
> ===============================
> 
>   The prototype transforms a simple UML model into an XML 
> schema.  From the XML schema it generates an XML parser using 
> sun's JAXB (Java Architecture XML Binding) schema compiler.  
> It uses the generated XML parser to unmarshal a sample XML 
> document into memory and then output data from the document 
> to the console.
> 
> Instructions for Running Prototype ==================================
> 
> download andromda 2.x from sourceforge
> download jwsdp 2.x from sun
> grab the prototype from my CVS repository:
> 
>  cvs.sourceforge.net:/cvsroot/timetowork
>    + examples
>    + + xsd-cartridge
> 
> In the main directory for the prototype type:
>   ant
> 
> You should see:
> - prototype cartridge compiled
> - XML schema generated by AndroMDA from UML model
> - AndroMDA generated XSD compiled using Sun's JAXB
> - generated java based XML parser compiled
> - sample java program compiled
> - output generated from a trial run of the parser on a XML document
> 
> Prototyping Learning Points
> ===========================
>    There are two areas I wanted to explore with this iteration of
> prototyping: modeling XML comcepts in UML, and new cartridge 
> development techniques.
> 
> Cartridge Development Techniques
> --------------------------------
>   The prototype experiments with cartridge development 
> techniques different than the ones demonstrated in the 
> current AndroMDA distribution.
> 
>   I started with the assumptions, which might be incorrect, 
> that the current cartridge implementations have the following 
> problems:
> 
>   - the current template scripts are too coupled to the 
> UML1.4 meta-model
>   - text generation operations and model navigation 
> operations are badly coupled
>   - there exists no explicit model describing the cartrides output
> 
>   When I tried to solve these problems in my XML schema 
> prototype a strange thing happened.  I did not notice this 
> strange thing until after I had completed my first iteration 
> of my prototype.  My accidental solution turned out to be 
> that I created a PSM (Platform Specific Model) for XML schema 
> generation and layered it on top of the PIM (Platform 
> Independent Model) contained in the UML. I then restricted my 
> template scripts to accessing only the PSM.  There was a  
> particularly surprising solution to me given that before I 
> did this prototype I had hardly thought about PSMs at all.
> 
>   Here is my explanation of how this happened:
> 
>   I reasoned that the template scripts should have access to 
> at least two classes of objects when generating code.  One 
> set of objects should be model navigation related objects and 
> the other(s) should be output text generation related 
> objects.  Therefore I wrote a custom script helper for my 
> cartridge that was nothing more than a factory: it creates 
> model navigation objects, and code generation formatting objects.
> 
>   My next problem was to try to decide what the model 
> navigation objects should look like.  I didn't want to use 
> the UML1.4 objects directly, like in our EJB templates, 
> because I believed that would cause a porting problem if we 
> ever chose to move to UML2.0.  Therefore I decided I needed 
> to design an object model for model navigation that was 
> appropriate to the problem of XML schema generation and that 
> would isolate me from changes in the underlying UML meta-model.
> 
>   I wondered a bit about what that navigation model should 
> look like.  After some thought it seemed clear that since I 
> was going to be generating XML Elements, Attributes, 
> ComplexTypes, and SimpleTypes, that those would be as good a 
> set of navigation objects as any.  Therefore I ended up 
> creating a little mini-model of what it was I intended to 
> generate.  After looking back on what I did I realized I had 
> essentially created a PSM. It is a PSM because it is a 
> partial object model of the intended output.
> 
>   The last step was to design an output text generation 
> object for the cartridge.  All I did here was to move the 
> more cluttered bits of template scripts into Java based 
> convenience methods.  But I was careful to make as many of 
> the methods as possible public so that the templates could 
> reuse and reimplement any parts that they wanted to use.
> 
>   Now that I've done this exercise it strikes me that a PSM 
> is probably an important piece of a cartridge's 
> implementation and documentation.  The PSM for a cartridge 
> will always exist.  The only choice the cartridge implementor 
> has to make is what form that PSM will take.  It can be 
> explicitly documented, and explicitly used in the code 
> generation templates. Or it can exist implicitly as scraps of 
> logic in the code generation templates. I'd argue that it is 
> useful to create an explicit PSM in situations where the code 
> generation starts to get complicated.  That idea pretty much 
> matches up with the idea of when any model should be created; 
> when things start to get complicated.
> 
> Modeling XML in UML (UML Profile for XML)
> -----------------------------------------
>   Something that one is immediately struck by when modeling 
> XML via UML is that aggregation and composition are key 
> concepts in XML.  An XML document is essentially a 
> containment hierarchy of elements.  For every element in an 
> XML document it is essential to know the owner of that 
> element. In our EJB related models we have often been able to 
> ignore composition/aggregation/association concepts. This is 
> not so when modeling XML.
> 
>   The containment hierarchy concepts are dealt with by 
> creating XSD type definitions in the XSD only for those types 
> that can be reached from the documents top-level model 
> element via some sort of composition relation. There exist 
> two ways to model object composition: when one object is an 
> attribute of another object, when one object is associated to 
> another object via a composition relationship.
> 
>   There are some complexities that have to be dealt with when 
> deciding how to implement UML model elements in XML.  When 
> should an UML model element be implemented as a: attribute, 
> element, ComplexType, and/or SimpleTypes. A element in XML is 
> something like: <name>my name</name>. The same entity shown 
> as an attribute would be something like: <person name="my 
> name"/>. Generally a ComplexType is something that can 
> contain other xml elments.
> 
>   I have dealt with the type issue by creating some basic 
> modeling policies. In UML there exists the distinction 
> between datatypes and classes.  A datatype is typically a 
> fundamental type in the model such as: integer, string, date, 
> etc.  The policies I have implemented are:
> 
> - if an attribute on a UML class is modeled as a datatype 
> then the attribute is implemented in the XML as an XML 
> attribute otherwise it is implemented as an XML element
> 
> - If a UML class is modeled with attributes or relations then 
> it is implemented as an XML ComplexType otherwise it is 
> implemented as a XML SimpleType
> 
> - if a UML attribute has been modeled to have a multiplicity 
> then that element can appear within its parent element with 
> the restricted multiplicity
> 
> 
> I hope this was of some interest to people.
> Tony Mowers.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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