UML based modeling outside of Modeler (was: RE: Modeler vs. consistency of DataMap/Entity/Attribute/Relationship)

From: Holger Hoffstätte (
Date: Fri Mar 21 2003 - 13:55:45 EST

  • Next message: Holger Hoffstätte: "Re: UML based modeling outside of Modeler (was: RE: Modeler vs. consistency of DataMap/Entity/Attribute/Relationship)"

    The following was sent to me by Michael; I forward with his permission.
    Good food for thought.


    -------- Original Message --------
    From: "Michael Henderson" <>
    Subject: RE: Modeler vs. consistency of
    To: Holger Hoffstatte <>


    I have been lurking on the mailing lists for cayenne for quite a while and
    looked back through
    my mailbox to find the attached posting.

    I have been looking at ArgoUML ( as a platform for writing
    UI for an open-source O/R mapping tool
    (hibernate, OJB, Cayenne).

    Here are my resaons:

    1. Integration with UML class diagrams - manipulation of diagrams
    2. Class model is XML (XMI format) (embedded in a zip archive)
    3. Output to image, eps, or SVG
    4. Extensible class, attribute information via 'tagged values'
    5. Plugin architecture
    6. ArgoUML supports UML class diagram generation from source code
       and source code generation from UML models

    This seems ideal since the O-R modelling can become another stage in the
    system modelling process
    with representation in an industry standard form. XSLT or Velocity DVSL
    be used to convert XMI
    to the O-R XML file format (all the O-R frameworks I have looked at use an
    XML file format).

    I have so far created a class diagram in ArgoUML to represent the
    Artist/Painting/Gallery entities
    in the cayenne tapestry tutorial. with tagged values added to the diagram
    elements to represent
    items such as table name, primary key, manadatory, column name, column

    It is my goal to create a XSLT stylesheet to convert this model's XMI file
    to the file
    shipped with the example and have it opened in CayenneModeler.

    If this works out then a ArgoUML plugin should be possible to make the
    editing of the tagged values
    less cumbersome.

    Would this effort be welcome.? I realize that a great deal of effort has
    been expended on the cayenne modeler
    application, but if a redesign is being contemplated the above approach
    offer a viable solution.

        Mike Henderson

    -----Original Message-----
    From: Holger Hoffstatte []
    Sent: Sunday, March 02, 2003 12:30 PM
    To: cayenne-devel
    Subject: Re: Modeler vs. consistency of

    Andrus Adamchik wrote:
    > I totally agree that Modeler is confusing and hard to modify. I said it
    > all along, since I was the first one to feel the pain of the original
    > "hit-and-run" Modeler design. A few months ago I grew so desperate with

    No hard feelings ;-)
    I was just as disappointed to see how useless Swing as an application
    framework really is.

    > I think we should do a full conversion to Scope (maybe in 1.1 or 1.2). I
    > (..snip..)

    fully agree, scope seems very helpful. Lots of useful things in there.

    > Hopefully using Scope will allow us to get rid of *all* map modification
    > events. Scope uses hierarchies of MVC triades and allows event, please? What I tried to say in my mail was that I liked the
    non-display events like AttributeEvent etc., but that they are simply in
    the wrong place (package-wise) where the DataMap itself cannot benefit
    from it right now. That's all! It would be so great to have Entity as
    AttributeEvent listener, for example. It seems Craig understood what I
    meant; messing with the model at runtime has always been a problem with
    EOF since there was no way to invalidate the internally cached structures.

    > I haven't done the full switch yet (only a few recent panels are
    > implemented using Scope), since I feel like Modeler in its current form
    > has an acceptable level of quality for the end users and is ready for
    > 1.0. I did not want to break it apart and face the task of rebuilding it
    > from scratch, thus delaying the 1.0 date further.

    I understand that: one of our customers is playing with it and likes it,
    even though they will use TopLink 'for real'. But generally reception so
    far has been positive already and is probably going to get better for 1.0
    (L&F, prefs saving). On the other hand I now spent almost three days
    trying to get the rename-entity functionality working and have so far not
    yet been able to get it right. Even rebuilding the tree view is really
    obscure and doesn't work as expected..maybe I'm just too dumb. :(

    > As a downside, I stopped any attempts to optimize events and other
    > things till the switch is done. 1.0 is the most important thing now!



    This archive was generated by hypermail 2.0.0 : Fri Mar 21 2003 - 13:59:55 EST