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,


Just a quick reply on this part:

> I would think that the general expectation is that these are *not* equivalent, and that the first one encodes an implied relationship between the package and the diagram, namely that the diagram is "contained" in some way in the package. That also lines up with pretty much every UML diagram editor implementation, which nests diagrams into packages. However, as you said, there isn't really any relationship of that type in the XMI. And that's what I am trying to understand...

In Papyrus, Diagrams are separated from the model, and the Packages (And other UML elements) know nothing about their diagrams (At least not from an XMI point of view). Only the diagram contains a reference to the model. However, the UI presents the Diagram as being "contained" in the model (But that's really just a graphical representation).

In other tools, Diagrams are either separated as well, or contained in the UML Model via implementation tweaks (Which are usually not compliant with the OMG specification). For example, in Eclipse/UML2, all UML Elements can contain "annotations", which don't exist in the OMG/UML specification. These annotations can contain other non-UML objects, such as Diagrams.

So, in my understanding, this is valid:

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

And this is not:

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


HTH,
Camille
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Robert Lemmen
Envoyé : mardi 14 octobre 2014 12:38
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] general UML 2.5 questions

hi ed,

thanks for the reply! You do primarily support my concerns/questions
however:

On Tue, Oct 14, 2014 at 11:11:21AM +0100, Ed Willink wrote:
> UML 2.0 had the vision that it would be helpful if UML was built from 
> reuseable parts. Hence the many levels and general difficulty with 
> finding anything definitive in the specifications.
> 
> No one was aware of any actual reuse and so the UML simplification 
> that led to UML 2.5 abandoned this heavy use of Package Merge in favor 
> of single points of definition.

understood, but that means that a UML tool that reads a XMI file must "know" somehow in which package to go looking for a given element from teh XMI. In other words, a lot of knowledge about UML must be built into the tool that manages the model, rather than being incoded into the model itself. That is very unfortunate from a meta-modelling perspective, if you for example were to create another model, you need to update your tools to read the matching XMI into an abstract representation, in the 2.4 system a XMI reader could populate the abstract model with very little knowledge about the model being read.

Of course no one is stopping the createor of a toolset to use the same mechanism that is used in 2.4 to create a package that contains all used classes, solving this problem. But I find it very surprising and was assuming that I am missing something important, e.g. that the same can be achieved with profiles or so (though I don't see how).

> A UML model does not and cannot refer to a diagram. UML 2.5 introduces 
> UMLDI allowing a diagram to refer to a model.

exactly how I read the specs and XMI! but look at the example from the original email:

<xmi:XMI ...>
    <uml:Package xmi:type="uml:Package" name="PrimitiveTypes" ...>
        <packageMerge xmi:type="uml:PackageMerge" ...>
            <mergedPackage xmi:type="uml:Package" href=...>
        </packageMerge>
        <umldi:Diagram xmi:type="umldi:UMLClassDiagram" ...>

Would you expect the Diagram to be independent from the package? in other words? is the above equivalent to e.g.:

<xmi:XMI ...>
    <umldi:Diagram xmi:type="umldi:UMLClassDiagram" ...>
    <uml:Package xmi:type="uml:Package" name="PrimitiveTypes" ...>
        <packageMerge xmi:type="uml:PackageMerge" ...>
            <mergedPackage xmi:type="uml:Package" href=...>
        </packageMerge>

I would think that the general expectation is that these are *not* equivalent, and that the first one encodes an implied relationship between the package and the diagram, namely that the diagram is "contained" in some way in the package. That also lines up with pretty much every UML diagram editor implementation, which nests diagrams into packages. However, as you said, there isn't really any relationship of that type in the XMI. And that's what I am trying to understand...

> The top level of any XMI document is 'irregular' because it must 
> specify the namespace.

understood, and not a serious problem. I just added that because the case where an element comes from a different namespace than another one in the same XMI is different for the top-level case than for a nested one...

regards  robert

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


Back to the top