Duane Nickull wrote:
> My view on this is that UML diagrams should be viewed as an expression of a
>model/process etc. Many people used to get confused when they saw tools where
>they could model a UML CVD and have it write out java stub code. They
>interpreted this to be that some machine translated the UML into Java. The
>truth is that there is a model behind the UML that gets used. UML is only one
>of many ways to represent logic or models.
> (01)
As my late mentor Selden Stewart once said, "any language which can be
translated directly to executable code is a programming language". UML
models are made for many purposes. The most common purpose is still a
design for a program. The problem that OMG never addressed with its
"Model-Driven Architecture" is that there is no way to say what kind of
UML model a given model is. There is no "UML profile for problem-space
models" versus "platform-independent models" (solution models that
aren't tied to Java or WSDL/SOAP specifically), or "platform-specific
models" (solution models that have a 1-to-1 translation to Java or WSDL
or SQL or XML Schema). There isn't even any guidance on what UML
features are appropriate in each of these applications. UML classifiers
and associations have 50+ optional markups that are variously intended
for abstraction, Java implementation features, SQL implementation
features or XML implementation features, unsorted and sometimes
strangely named. (02)
As I have said before, the credo of the object modelers of the 1990s was
that the object model of the problem space _was_ the design for the
solution, which led to a confusion between the process of analysis and
the process of design. And that confusion is still present at OMG and
in most of the current UML literature. (This mis-insight was not new
with object modeling; many "information modeling" technologies of the
1980s treated the "model of the problem space" as the design for the
relational schemas. A language like IDEF1-X, for example, did not allow
multivalued attributes, because that would require a separate table in
SQL. The truth has always been that about 80% of a good problem space
model has some kind of direct translation to code elements, and the
other 20% is what we pay software engineers to do.) (03)
The problem with having tools that will generate XML Schema or Java from
a UML model is that the modeler will be tempted to make a UML model that
generates the code he wants, rather than making a UML model that is an
abstraction of the solution, or a model of the problem space. Or as
Selden put it, he makes a drawing of his program rather than a model.
There is nothing wrong with this; it is a useful software engineering
practice. The issue is not to confuse yourself or the reader as to what
the UML model is. (04)
> I am a big fan of MVC as an architectural pattern!
> (05)
I have no idea what "MVC" means. (06)
> Having said this, the approach of OMG’s XMI is something I found a bit
>cumbersome to work with.
> (07)
XMI is a different problem. The idea of having a well-defined XML
exchange form for UML models is good. The idea of having multiple
optional representations of every UML model element is not to
standardize a well-defined XML exchange form. (08)
Unfortunately, the purpose of XMI 2.0 was not to standardize UML
exchange. It was to support export forms of UML models that can be
easily converted to XML forms that are easier for "programmers" to
process. The problem that OMG faced was that software engineers of 2004
were educated to use and understand some features of XML Schema, and
they wouldn't readily accept a "clumsy" or "complex" XML schema that was
the implementation form of the UML model. (Once again, the problem was
the generated implementation.) So the solution was to allow the XMI
form of the UML model to be tailored so that a relatively simple
transform could produce a desirable XML Schema. And of course, each UML
tool vendor tailored his default XMI form to be something convenient to
his tools. (09)
[And because standardizing exchange of UML models was not really the
goal, it isn't the effect. 5 years later, I still can't move a UML
model from one tool to another. One of the rules for standard exchange
forms must be that every tool that claims conformance must be able to
read all of the standardized forms.] (010)
If you actually look at the OMG standards that have been produced using
the MDA approach, you will see UML models that describe the solution,
and standard XML schemas or Java APIs that are the actual basis for
software interoperability. And for the XML schemas, somewhere in there
there is a transform from some postulated XMI form to the standard XML
interchange form described using XMI v2.1 gibberish. It is the standard
XML or Java that creates "interoperability", not the UML model. But it
is the UML model that makes it comprehensible. (011)
Only those of us who are interested in converting the UML model to OWL
or CLIF (so that we can talk about "semantic interoperability" with
supporting technology) care about the XMI form. And then for us model
manipulators, we have the Eclipse Modeling Facility, with its very own
predilections for XMI forms -- its native form export form being
pseudo-XMI that is non-standard -- and a very interesting set of
dependency rules. (012)
In fairness, we are finally making some progress in educating the
average software engineer in making and reading some kind of abstract
model. Since it took 40 years to get the concept onto the software
engineering curriculum, it should not surprise us that it has taken us
15 years to understand what the flesh on that concept should really look
like and what the supporting technologies really need to do.
Socialization of an important concept always takes many strange turns.
But the net effect is that we have made a lot of real progress in the
right directions. (013)
-Ed (014)
P.S. One part of that real progress is bringing the different modeling
technologies and communities together, and I think Richard Soley of OMG
and Peter Yim have, in their own ways, contributed materially to that. (015)
-- (016)
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (017)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (018)
> Duane
>
>
> On 2/20/10 11:36 AM, "John F. Sowa" <sowa@xxxxxxxxxxx> wrote:
>
> I have often said that UML diagrams could be defined in Common Logic,
> and the OMG is actually doing that. Following is the beta version of
> Foundational UML (FUML) with definitions of the declarative parts of
> UML in Common Logic and translations of the procedural parts to Java:
>
> http://www.omg.org/spec/FUML/1.0/Beta2/PDF
>
> To see the CLIF translations, go to Chapter 10 Base Semantics, which
> starts on page 275.
>
> In various talks about Common Logic, I have said that UML diagrams could
> be translated to CL, and I'm happy to see that people are doing that.
>
> That is one more point in favor of using Common Logic as a lingua franca
> for translations among different formalisms, especially for mappings
> between the Semantic Web and other software technologies.
>
> John Sowa
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>
>
>
> ---
> Adobe LiveCycle Enterprise Architecture -
>http://www.adobe.com/products/livecycle/
> My TV Show - http://tv.adobe.com/show/duanes-world/
> My Blog – http://technoracle.blogspot.com/
> My Band – http://22ndcenturyofficial.com/
> Twitter – http://twitter.com/duanechaos
>
> (019)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (020)
|