RE: revised UML profile for DAML

From: Hart, Lewis (lhart@grci.com)
Date: 01/26/01


I believe we are generally in agreement. Just to clarify a bit, let me say
that the ultimately the transformations between UML and DAML should be
constrained sufficiently so that they are bounded for a limited subset of
UML and DAML. That is, the middle part in the "figure" below. 

[Full UML] -- U2D --> [sub DAML] < -- U2D/D2U --> [sub UML] <-- D2U -- [Full
DAML]
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The tricky bit is to make the set of transformations as large as possible
and the limitations as small as possible in order to maximize utility of the
process. 

- Lewis.
_____________________________________________________
Lewis L Hart
GRC International                      lhart@grci.com
1900 Gallows Rd.                  Voice (703)506-5938
Vienna, Va 22182                    Fax (703)556-4261

-----Original Message-----
From: Ken Baclawski [mailto:kenb@ccs.neu.edu]
Sent: Friday, January 26, 2001 12:49 AM
To: Hart, Lewis
Cc: daml-graphical@mail.daml.org
Subject: RE: revised UML profile for DAML

On Wed, 24 Jan 2001, Hart, Lewis wrote:

> The mapping which I have posted is primarily for UML to DAML. This
mappings
> is many to one, that is there are several UML situations which are mapped
> into the single DAML Property. Typical of a many to one mapping, the
inverse
> mapping looses some information. For a given DAML property, it is not
> apparent from the DAML alone what UML elements resulted in that property.
> Clearly, the reverse mapping is free to pick any one of the UML
> representations that are semantically equivalent. The I believe this
> prevents the unbounded situation, though the UML representation will not
be
> identical. 

Yes, this is the usual situation.  Both the UML -> DAML mapping and the
DAML -> UML mapping will be many to one.  However, even if they preserve
semantics, the pair of mappings can still be unbounded.  The example of ER
-> Relational and Relational -> ER that I mentioned in an earlier posting
preserves semantics, but it is still unbounded.

> Consider the "child" and "mother" roles of the "Parent" association found
at
> link [1], and shown crudely below.  Starting from one UML binary
association
> with two roles:
> 
>          child                   mother
> [Person] -------- Parent> -------------[Woman]
> 
> it is mapped/transformed into three DAML properties(ignoring cardinality,
> domain and range):
> 
> <Property id="child"/>
> <Property id="mother">
>   <subPropertyOf resource = "Parent"/>
> </Property>
> <Property id="Parent"/>
> 
> The inverse transformation could result in three associations without
roles
> and a generalization between stereotyped classes:
> 
> [      ] -----------mother> ---------- [     ]
> [person] ---------- Parent> ---------- [Woman]
> [      ] --------- <child ------------ [     ]
> 
> [<<Property>>]                            [<<Property>>]
> [   mother   ] ---- generalization > ---- [   Parent   ]
> 
> I do not see how this results in an unbounded situation, since both of
these
> UML representations result in identical DAML when transformed. 
> 
> Furthermore, I think it is unreasonable for UML<->DAML transformations to
be
> totally reversible. That is, if UML1 is transformed into DAML1 and then
back
> to UML2, then UML1 will be not identical to UML2. What I believe should
> be true is that if the transform is applied again to UML2 to produce
> DAML2, then DAML1 and DAML2 should be identical. This defines semantic
> equivalence for UML models with respect to DAML.

My formulation of the problem did not presume that the transformations
were invertible, and I agree that it is unreasonable to expect
transformations to have this property.  However, one must expect that both
transformations (UML -> DAML and DAML -> UML) will "lose information", not
just UML -> DAML.  So it may be difficult to achieve convergence as
quickly as you propose.  Nevertheless, it is certainly reasonable to
propose that this be one of the goals of the UML -> DAML transformation
effort. 

  -- Ken Baclawski


This archive was generated by hypermail 2.1.4 : 03/26/02 EST