RE: Announcement from Technical Architecture

["David S. Frankel" <dfrankel@gendev.com>]

 Message text written by INTERNET:dfrankel@gendev.com
> >Deriving an XML syntax from a UML model in a consistent manner
> means you *don't* repeat the modeling process; rather, you use
> the superior
> modeling medium to model the domain and then generate the XML syntax
> according to a well-defined pattern.
>
> David S. Frankel<
>
> >>>>>>>>>>>>
>
> Once upon a time we talked about reversable process.
>
> I'd still like to be able to do that - i.e. import my DTD (aka schema)
> into a UML tool and have it then make those components available.
> Then I can do interesting UML things on top to enhance the documentation.
>
> I've used Visio Professional like this against SQL tables, and this just
> seems such a natural win-win.
>
> Never under estimate the power of simple!   Not everyone wants to
> start the process in a UML tool - nor should they need too.
>
> DW.

Your point about reverse-engineering is reasonable.  Note that the OMG
issued an RFP a few months back for, among other things, reverse-engineering
for mapping non-XMI DTDs and Schemas back to UML/MOF models.  What scares
me, though, is that there will be a temptation  to try to source way too
much on the XML side.  Reverse engineering is nice, but the semantic power
of UML often leads to streamlining of the reverse-engineered model such
that, if you then apply the consistent mapping back to XML, you end up with
a situation in which streams that validated against the original DTD don't
against the new one.  If standards are issued based on XML that's been
"hand-coded" on the XML side, this becomes quite a headache.

It all depends on what you see as the role of the UML model.  If you see it
as just a way to enhance the documentation, or add some invariants expressed
in OCL, then this isn't a problem, but then you have to realize that what
you have is a UML model that is really XML-biased.  You probably could not
use it to generate other kinds of representation, i.e. other than XML
DTD/schema.  I see the role of the UML model as being the means to express
the information model in a way that is independent of XML, LDAP, CORBA,
Java, etc., so that it can be used to generate stuff for any of these
environments.  If you see the model that way, then you will probably alter
the UML model that you obtained via reverse-engineering.  You'll alter it to
make it really technology-neutral.  Note that the OMG's RFP is really
calling for reverse engineering to a technology-neutral kind of UML/MOF
model.

I experienced first-hand a striking example of this.  I was part of the team
that worked on the CORBA Component Model's packaging and deployment
descriptors.  I joined the team when things had already progressed quite
far, and an extensive set of DTDs had been defined, and they were
"hand-coded."  The people who were doing them were quite knowledgeable about
XML and very smart and experienced software people.  When I came into the
team my job was to create a MOF/XMI compliant version of the DTDs.  As I
reverse engineered the DTDs (entirely a mental process--no tools used) I
noticed all kinds of efficiencies that could be obtained just from OO
inheritance alone, not to mention other factors.  It's not that I'm smarter
than the other guys--it's that UML and the UML tools innately promote
thinking in these streamlined terms.

Sometimes we have no choice but to reverse engineer, i.e. when the work has
already been sourced on the XML side. But I'd like to minimize the number of
cases in which we have to do this.

--David Frankel