[Middlegen-user] db<->code<->uml?

[Aslak Hellesøy]

Hi!

Matthias Bohlen (author of UML2EJB - http://uml2ejb.sf.net/) wrote today:
http://sourceforge.net/mailarchive/forum.php?thread_id=1181378&forum_id=1015
4

And Ara Abrahamian followed up with this:
http://roller.anthonyeden.com/page?pageid=065218131008103306542336000026&use
rname=ara_e

I'm curious to hear what you Middlegen users out there think about this bus
thingy. I think it's a very good idea, and Middlegen/XDoclet/UML2EJB are all
dynamic projects that could nicely achieve the described goal if we agree on
a way to do this. Good and bad ideas are welcome!

Regards,
Aslak
http://www.freeroller.net/page/rinkrank

[Ludovic Claude]

Me me! I have an idea!

Its the following:
- this days, every metadata seems to have its XML representation (Database
schema with the Jakarta SQL project, XMI for UML, and only XJavadoc is
missing its XML representation but it's only a matter of time)
So XML is the model of choice for representing internally and storing the
metadata in this bus.
Then the db <--> code <--> uml becomes:

Db <--> XML for Db schema <--> XML for XJavadoc <---> XMI
|
|
Code
UML

Now things are simpler: we have already an open source project that manages
all those transformations: Cocoon and its pipeline model for managing the
transformations.
Some transformations, for example XML for Db schema <--> XML for XJavadoc
require some user intervention, so we need a GUI like Middlegen to let the
user customize the rules for those transformations, and store the user
choices into some kind of knowledge base (the existing preferences for
Middlegen will do the job).

That should work well for static generation, where you take for example an
existing database and generate all the code from it, but what about
incremental generation, where user writes some code for example and you
except the database schema to be updated?
Here, we need a repository for storing the previous versions for the
metadatas at all levels. Good news, it's easy, we just store the XML.
Then we run for example XJavadoc on the changed code, that produces a new
XML metadata represenatation, then we run a XML diff betwen the old and the
new metadatas (there is a XML diff project in alphaworks), then that's were
we need more thinking, because the idea is to propagate the XML diff to all
XML representations, but i don't think Cocoon supports things like that now.

My .2euros

Ludovic.

----- Original Message -----
From: "Aslak Hellesøy" <***@netcom.no>
To: <middlegen-***@lists.sourceforge.net>;
<middlegen-***@lists.sourceforge.net>
Cc: <***@mbohlen.de>; "Ara Abrahamian" <***@yahoo.com>
Sent: Tuesday, October 15, 2002 1:26 AM
Subject: [Middlegen-devel] db<->code<->uml?

Post by Aslak Hellesøy
Hi!

http://sourceforge.net/mailarchive/forum.php?thread_id=1181378&forum_id=1015

Post by Aslak Hellesøy
4

http://roller.anthonyeden.com/page?pageid=065218131008103306542336000026&use

Post by Aslak Hellesøy
rname=ara_e
I'm curious to hear what you Middlegen users out there think about this bus
thingy. I think it's a very good idea, and Middlegen/XDoclet/UML2EJB are all
dynamic projects that could nicely achieve the described goal if we agree on
a way to do this. Good and bad ideas are welcome!
Regards,
Aslak
http://www.freeroller.net/page/rinkrank
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
middlegen-devel mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-devel

[Ara Abrahamian]

It's cool idea and you know I've been advocating it for a long time.
That's Nirvana ;-)

Imho:
Code meta model: xjavadoc
Db meta model: commons-sql + some stuff from middlegen
Uml meta model: probably a simpler model over MAF (something more
diff-able with xjavadoc I mean)

There are other models we can throw in too: a soap-envelopeable mapping
of an object, or an xml mapping (like castorxml). What's important is
that you always map from source code + @tags to something external and
vice versa, not from db schema to uml for example, code sits there
always because it's the design in the code and you can always express it
in code and @tags. So what we need is defining ToCode and FromCode
interfaces and let it work on all elements of our meta model: A
DBTableToCode diff-er which aggregates DBColumnToCode diff-ers. Simple
command/composite objects. With command it can be undoable too: undo
new-attribute which resulted in creating a new column in db. Needless to
say we won't need a complete rerun of the synchronizer (ejbdoclet for
example) to get the intf/db/whatever, the fine grained Diff-er can work
on a mini unit of work. I'm starting to think that we need more fine
grained control over all elements of the generation process. I've
already talked about a method-overriding dilemma with Aslak. Raw
Velocity templates have no sense of outputted code, is it a method I'm
outputting? Is it an overridden one? I just output it and forget about
it. I really like the idea of moving many of the template stuff to
normal command-like java codes. Look at what Rickard does with the
command pattern, basically all his fireworks are: commands and
aspects/introspectors.

So as you can see I'm proposing something which is even more radical
than XDoclet2 itself. What do you think?

Ara.

-----Original Message-----
Sent: Tuesday, October 15, 2002 2:56 AM
Subject: db<->code<->uml?
Hi!

today:
http://sourceforge.net/mailarchive/forum.php?thread_id=1181378&forum_id=
10

15
4

http://roller.anthonyeden.com/page?pageid=065218131008103306542336000026
&u

se
rname=ara_e
I'm curious to hear what you Middlegen users out there think about

this

bus
thingy. I think it's a very good idea, and Middlegen/XDoclet/UML2EJB

are

all
dynamic projects that could nicely achieve the described goal if we

agree

on
a way to do this. Good and bad ideas are welcome!
Regards,
Aslak
http://www.freeroller.net/page/rinkrank

[Ampie Barnard]

My 2c:

Although I use XDoclet with great success for my EJB's (Session and MDB's) I
do not believe XDoclet is quite the tool for the management of O/R mapping.
I have found that not all O/R mapping concepts necessarily manifest in java
code (not even tagged code), for instance a one-directional compositional
relationships with a composite foreign key. Thus the code->db model is not
ideal.

I am currently use a highly customised Middlegen to generate abstract
classes representing my O/R layer for OJB. In my domain model I extend the
abstract classes, allowing me to focus on business logic alone. The plug in
also generates validation code, a deployment descriptor for OJB and data
transfer objects. All of these are relatively easy to predict from a
db-schema. So when my conceptual model changes I just update the db-schema
and regenerate my code. I have however found that not all O/R mapping
concepts manifest in database meta-data either, for instance lazy
initialisation, caching specifications etc. Thus the db->code model is also
not ideal.

I think that the only place where the metadata is extensible enough is in
UML. More specifically, UML has a much more elegant representation of
relationships than either java code or sql code. It is also highly
customisable through tagged values. So when it comes to conceptual class
diagrams, I think the UML diagram should be the point of reference for the
persistence layer classes, the db schema and the O/R mapping deployment
descriptor (be it EJB/OJB/Hibernate/JDO). As long as the UML diagram stays
the point of reference, the info bus can manage the bi-directional UML <->
code relationship (maybe using XDoclet) as well as the bi-directional
UML<->db relationship (maybe using Middlegen. But I believe there will
always be more in the UML diagram than in the db metadata and Java code put
together.

So we might want to add a field to the db or to the java code, and it then
reflects in the UML diagram. But neither the Java code nor the DB knows that
that field actually represents a one-directional compositional relationship
that should be loaded lazily except on Wednesdays, Fridays and Saturdays
between 2 and 5. This info should only be carried in UML.

In short I suggest: db<->UML<->code.

Regards

Ampie