Hi Aslak, thanks for your message! I'll answer the points one by one, below.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Aslak > Hellesoy > Sent: Friday, July 12, 2002 9:15 PM > To: Ara Abrahamian; 'Matthias Bohlen'; > [EMAIL PROTECTED] > Subject: RE: [Xdoclet-user] UML modeling frontend for XDoclet > Ara wrote in a previous email: > > PS: Ideally I would like to see convergence of UML2EJB and > Middlegen. > > Imho middlegen's architecture should be extended to treat UML as yet > > another input source. What do you think? Aslak? > > > You're reading my mind, Ara. There are pros and cons of course. > Both UML2EJB and Middlegen use Velocity as template lenguage to > spit out XDoclet @annotated Bean implementations. Middlegen has a > plugin architecture similar to XDoclet, and the EJB output is > part of the cmp20 plugin. Middlegen also has a JDO plugin, and > I'm currently working on a JSP/Struts plugin. -And there is WebWork/ > Velocity up the road (using Velocity to generate Velocity code!). As you already said, there are pros and cons. Let's have a look at what both tools do: > What Middlegen does is to build an object model out of the > database, based on information that is gathered reading database > metadata. It's merely transforming the iformation provided by a > java.sql.DatabaseMetaData object into objects that are easier to > deal with: Both from velocity templates, but also from the GUI > which is part of Middlegen. These objects are basically table, > column and relation. At first sight (I do not know Middlegen, yet!), this database metadata seems like a subset of the full set of UML metadata. Let's put this into a comparison table: Database item UML analogy ----------------------------- table class column attribute relation association OK, that works. But there is more: Database item UML analogy ----------------------------- ? package ? method ? dependency ? stereotype This brings us to the first problem: the dynamic aspect in the model. But wait a little, let's read the rest, first! > I have no knowledge of XMI whatsoever, and my UML knowledge is > limited to basic understanding (I can draw 4-5 of the diagram > types on a blackboard). If we were to see a synergy effect here, > It would be to do as you(Ara) say: Treat XMI as an input source > analogue to database metadata. That would require the invention > of a new abstraction layer between Velocity and the input sources, > so that the Velocity templates could be agnostic about the origin > of the data (whether it comes from a database, an XMI document, > or perhaps even other kinds of input sources). Well, this seems tempting at first, but it tackles the problem at the wrong level of detail. We'll come to that in a moment... > Matthias, do you think such an abstraction layer would be > feasible? -Or would this common denominator be too narrow to > capture the detail level provided by the two input sources we're > talking about here? I think, it would be possible to construct such a layer, but this layer would cover only the static aspects of the model (or if you want to put it bluntly, this would be a "data only" approach). > I think XMI and database metadata can provide much of the same > information, but still, each of them probably provide information > that the other doesn't. Yes, that's absolutely right. There is always a necessary transformation process. Example: Type mapping. If you read a DECIMAL field from the database metadata, how do you know it's a java.math.BigDecimal? Or maybe, a Double? Or a scaled Integer? > I don't know for example if XMI can > express whether a class field corresponds to a foreign key in a > database column (this knowledge is required if we want to > generate CMR EJBs for example). Right: UML would omit the entire attribute from the class because in UML you would model this as an association with a cardinality and role names on each side. Only some transformation with additional information about the implementation can do the job. > I don't know what kind of > information XMI provides that database metadata doesn't, but I'm > sure it's a lot. As you see above, UML (and so, XMI) provides a couple of more things: a) Packages UML2EJB translates them to Java packages, that's natural. b) Methods UML2EJB translates them to Java methods, that's natural, too. c) Dependencies UML2EJB translates them to Java "import" statements, if the depending class is in a different package than the class it depends on. UML2EJB translates them into an EJB-reference, if the stereotype tells it to do so. To me, it is the dynamic aspect that makes most of the difference. And, to give a constructive idea: It would be fantastic if Middlegen could convert the database schema to XMI, then the CASE tool could add all the dynamic things as well as the packages and the dependencies, then UML2EJB could re-translate this into enriched EJB's. Do you think, this is feasible? > I'm looking forward to reading your repsonse on this. > /Aslak I'm looking forward to reading YOUR response on this. Matthias. ---- Matthias Bohlen Consulting that helps project teams to succeed... Web: http://www.mbohlen.de/ Snail: Luise-Albertz-Str. 25 D-53340 Meckenheim Germany Phone: +49 (170) 772 8545 Fax: +49 (2225) / 945189 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
