Fully agreed. Thank you for this really verbose explanation.
Cheers
Harald
Anthony Mowers wrote:
From: Harald Weyhing [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 22, 2003 11:22 AM
To: Anthony Mowers
Subject: Re: [Andromda-user] RE: [Andromda-devel] Prototyping Web Services Cartridge
Hi All,
As of my understanding the UML profile is your specific extension to the UML with stereotypes, tagged values and constraints to the UML model. You create a UML profile to be as exact as possible while modelling the PIM or the PSM. For example, if you create the <<Entity>> Stereotype you might want to say, that this is going to be persistent. While your transformation to PSM you will change this to <<EJBEntity>> to express that this is a J2EE platform specific UML model, <<HibernateEntity>> will say, that this is for Hibernate. Now, OMG does not say, that a PSM is UML, but for this example this is irrelevant. While doing the transformation to EJB or Hibernate you will take some mechanism that add platform specifc artifacts to your Model, the PIM.
So, if your Model describes all platform specific details you need for generating code to your platform this should be a PSM. Still, it will many times be possible to have a PSM that can be used to generate code for many other platforms too, but perhaps there are some missing Details to fit perfectly.
I would conclude to say that you have to decide which Details are platform specific and wich are not. After that you can try to describe a transformation from a PIM to the PSM. With this in mind I came to the conclusion that the car rental example is platform specific for EJB (CMP) and EJB (Hibernate) but platform independent for EJB.
Is there this much space for interpretation or am I missing something?
Cheers
Harald
Anthony Mowers wrote:
Matthias, I am not sure if what I modelled is the PSM or the UML profile and what the exactly differences would are. I think modeling the ;problem domain' of the cartridge has been educational and useful for me. I still don't know for sure if this is the right approach, but I will keep people updated.Perhaps you could write us an e-mail explaining what you see the main differenc being between the PSM and UML profile? Tony-----Original Message----- From: Matthias Bohlen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 19, 2003 12:57 PM To: 'Anthony Mowers'; 'Users AndroMDA'; 'Developers AndroMDA' Subject: RE: [Andromda-devel] Prototyping Web Services Cartridge 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
