Re: [xtm-wg] A challenge on "the graph"

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Lars Marius Garshol
|
| - it's not all that well known, though better than groves, and it's
|   not too easy to find introductions to it on the net

* W. Eliot Kimber
| 
| I'm not sure how you can claim that UML is not that well known--it's
| the closest thing to a standard in industry that I've seen.

You're right. Forget I said that. If we can accept groves we certainly
can accept UML (in terms of how many people know it).

* Lars Marius Garshol
|
| - it is very closely tied to implementation. In fact, UML is more
|   suitable as documentation of implementations and designs than as
|   anything else.
 
* W. Eliot Kimber
|
| This is not true--UML has been *used* primarily to document
| implementations, but there is nothing about UML that *requires* that
| use.

What I mean is that UML describes classes with methods, which is what
you have when you've finished your design. I don't think UML supports
you as well as it could when getting there, but that's a different
debate.

| We use UML almost exclusively to define high-level data models that
| are explicitly not implementation models.

OK, maybe there are UML features that I don't know about that would
make it suitable for this purpose. Can you make a quick-and-dirty
model of, say, a topic with its properties (just the topic) and post
it so that we can see what it looks like?

| I would suggest that a grove property set is necessarily much closer
| to implementation than a UML data model need be because it is
| documenting a particular data representation approach, not an
| abstract data model.

There's no need to drag the particular data representation approach
into this particular use of groves, so I don't think you are right
about this. The conformance section would say explicitly that you
don't need to use groves to implement the model.

Of course, you could say exactly the same about a UML-based model, but
as I saw it a UML model would have the disadvantage of looking
altogether too much like an implementation definition. But let's see
what you come up with. If that _doesn't_ look like an API I'll be
happy unless some new problem comes to light.

| Yes. For any multi-valued property you can further characterize that
| value as a set.

If so, I might be willing to accept UML as the chosen formalism.
Please post a simple example so that we can see what it would look
like. 
 
| The main problem with using EXPRESS in this domain is that it lacks
| the ability to express some essential types of relationships and
| properties.  For example, it has no defined way to represent
| aggregation or containment

Those features can easily be described in the prose, and in any case I
don't consider them to be very important for the abstract model. They
would be for an API, but not for the model, I think.

| EXPRESS, like groves and property sets, was designed to satisify a
| very specific, very narrow set of requirements, which it does well,
| but was not designed with an eye toward generic extensibility.

True. To say that it's useless for general modelling is overstating
it, however.
 
| I would agree that, graphically, EXPRESS and UML are essentially
| equivalent (modulo UML's inherent extensibility through
| stereotypes).
 
Does UML have a page-by-page representation that preserves references
across pages?

| Of course, one could use the EXPRESS constraint language with UML
| diagrams....

I'd be happier to use prose, I think. As long as the core parts of the
model are well-defined such things may be much more understandable as
prose than as code in a language unfamiliar to 99% of the readers and
that is also working on a data model different from the one it was
defined for.

--Lars M.


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your
Web Site for Business." Get it now!
http://us.click.yahoo.com/EVNB7A/c.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/