This is the mail archive of the davenport@berkshire.net mailing list for the Davenport project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: DAVENPORT: UML


Joerg Wittenberger wrote:
| I'm using docbook and dsssl to prepare documentation for software.
| Naturally there is the question how to document UML diagrams.

Separately from the rest of my response, it would be useful to
describe what documentation UML diagrams need.  I think they
need legends, but what else?  Your post suggests your are really
talking about XML representations of UML diagrams, which is a little
different.

| So far I have found

[ most of list of UML DTDs omitted ]

I had a favorite in this derby, an SGML DTD written by Normand Rivard.
However, 

| III) XMI, which is XML and supported by some major players.  This one
| has line size tag names and many content models of ANY.  Hence it's
| probably more targeted as an exchange DTD (the name say so as well)
| only useful if the model is validated already.

This is the winner adopted by the UML industry.  So we can forget
the rest (whatever their merits) because XMI is the only format that's 
going to be supported by UML tool makers in the short run.

| Who has experiences with UML documentation, opinions etc?  Thanks

I've spent a fair amount of time on XMI and UML, particularly in
connection with ISO/IEC 11179 (which the OASIS Regrep TC intends
to use - the proposed X3.285 revision is fully illustrated with
UML diagrams).  XMI encodes the semantics of the UML model, rather than
the semantics of the system represented by the UML model.  Eliot
Kimber gave a very good paper on the difference between the two
views at XLM 99 Europe (Granada).

XMI is successful as a transfer syntax between UML tools (which is
a big win).  But in order to enable useful processing with XML tools
of the XML representation of a UML model, you're going to want to
derive markup from the semantics of the real content (in a genealogy,
<person>s have relatives to which they bear relationships such as
"father-of", "mother-of", "sibling-of") rather than the semantics of 
the XMI representation of the UML model (father, mother, sibling are 
all <node>s labelled appropriately), and the relations specified by UML 
(father-of is an <edge> with a label or something like that).

It would be really useful if someone would devise a method of
converting an XMI instance to a more concrete syntax, in which the
semantics of the system modelled were tokenized as element types,
attributes, etc.  I'd be interested in hearing from anyone working
along these lines.

regards, Terry


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]