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,

Since the UMLDI specification has never been implemented, it is also possible that the specification itself is invalid (IIRC, the UML 2.5 XMI contains invalid IDs for example)

Camille

-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Robert Lemmen
Envoyé : mercredi 15 octobre 2014 13:00
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] general UML 2.5 questions

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

-- 
Robert Lemmen                               http://www.semistable.com 


Back to the top