Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] general UML 2.5 questions

Hi

<xmi:XMI ...>
    <uml:Package xmi:type="uml:Package" ...>
        ...
        <umldi:Diagram xmi:type="umldi:UMLClassDiagram" ...>
            ....
        </umldi:Diagram>
    </uml:Package>
</xmi:XMI>

and uml:Package is nested in xmi:XMI. Does that make XMI inherently dependent on UML?

No a more specialized specification may use elements from a less specialized specification.

	Regards

		Ed Willink

On 15/10/2014 11:59, Robert Lemmen wrote:
hi ed,

On Wed, Oct 15, 2014 at 09:43:31AM +0100, Ed Willink wrote:
UML models are conceptaually self-contained and so complete. Look at the
Eclipse UML project; UML without diagrams. Diagrams add value and so Diagram
models may reference UML models. There is no need for the reverse
references. What is the problem?
that is exactly how I read the UML spec as well!

As of today UML diagram interchange is not achieved between UML tools, since
UMLDI only became available with UML 2.5. I understand that Papyrus is
committed to supporting UMLDI which may encourage other vendors to follow
suit. More practically the DOD are prime movers in the OMG Model Interchange
Working Group, so once the DOD says UMLDI shall be available ....
exactly, the question I have only becomes relevant in the context of
UMLDI, although basically it also applies to eralier version of UML.

My understanding is that the semantics of PackageMerge have never been
entirely clear and that the Eclipse UML is the best/reference
implementation. I think this was another reason to eliminate the
PackageMerge from UML 2.5. PackageMerge is still modelable with UML 2.5 but
is no longer used by UML so the inadequate semantics are not a problem for
UML. Use of PackageMerge by users is discouraged.
point taken, but I don't really care about packageMerge here, this is
just what happened to be the next element in the OMB sample. The same
would apply to a <packagedElement xmi:type="uml:Class" ...>.

basically my problem boils down to the OMG UMLDI sample [0]:

<xmi:XMI ...>
    <uml:Package xmi:type="uml:Package" ...>
        ...
        <umldi:Diagram xmi:type="umldi:UMLClassDiagram" ...>
            ....
        </umldi:Diagram>
    </uml:Package>
</xmi:XMI>

as you can see there is an umldi:Diagram element nested in a
uml:Package. what does that nesting signify? how would it be represented
in the abstract model given that the class representing the "Package"
is unable to reference a "Diagram"? 

One logical conclusion is that there is no relationship between the two,
and that the above is equivalent to:

<xmi:XMI ...>
    <umldi:Diagram xmi:type="umldi:UMLClassDiagram" ...>
        ....
    </umldi:Diagram>
    <uml:Package xmi:type="uml:Package" ...>
        ...
    </uml:Package>
</xmi:XMI>

Would you take that position? If that's the case, then I am confused by
the fact that the OMG chose to put that umldi:Diagram element inside the
package, or even have that package in the first place in the file. Also
note that the common and useful practice of 2.4 UML editors (which of 
course do not use UMLDI but something homegrown) of associating a 
diagram with a package in the UI becomes difficult. That would be
surprising too.

Reading the example, I think it is far more likely that this is meant to
say that the diagram is part of the enclosing package. But there is no
way to represent that in the abstract model: the package does not have
any property that could hold a reference to a diagram, and the diagram
does not reference the package either...

regards  robert

[0] http://www.omg.org/spec/UML/20131001/PrimitiveTypes.umldi.xmi



_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4040/8392 - Release Date: 10/15/14


Back to the top