Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-papyrus.dev] general UML 2.5 questions 
hi everyone,

this is somewhat offtopic to papyrus, because it is more a general UML
point, but it is very hard to find knowledgable UML folks on the public
web, and you might find it interesting even if it is not directly
related to papyrus...

I am trying to understand UML/MOF/MDA a little bit better, from the
ground up. To do that I am looking at the XMI files and the specs from
OMG directly. it's a rough ride, but so far I am getting along ok. there
are two puzzling points however:

a) in UML 2.4, we have the L0, L1 etc compliance levels. Each of them
comes as a XMI that creates a package and then merges all the relevant
packages into that, e.g. (heavily abbreviated, full file at [1]):

<xmi:XMI ...>
  <uml:Package xmi:type="uml:Package" name="L1" ...>
    <packageMerge xmi:type="uml:PackageMerge" ...>
      <mergedPackage href="http://www.omg.org/spec/UML/20110701/Superstructure.xmi#Actions-BasicActions"/>
    </packageMerge>
    <packageMerge xmi:type="uml:PackageMerge" xmi:id="_packageMerge.1">
      <mergedPackage href="http://www.omg.org/spec/UML/20110701/Superstructure.xmi#Activities-BasicActivities"/>
    </packageMerge>
    ....

This way a single package "L1" gets created that contains all the
relevant classes for the UML. This is convenient from a meta-modelling
perspective, because a UML tool can now use that package to e.g. read
another UML XMI: whenever an object needs to be created while reading
the XMI, the xmi:type can be used to look up the class in that package.

in UML 2.5 however that compliance level XMI does not seem to exist.
Initially I thought it's just an omission because the standard is not
finished yet, but I saw a slide deck on the web [0] which suggested that
the removal of the compliance levels is deliberate, even a core design
aspect of 2.5. So I am wondering: what is used instead? how would a UML
2.5 tool that reads an XMI know in which package to look for a given
type that it needs to instantiate when reading a XMI?


b) I am also wondering about the relationship between objects in an XMI
file that come form different namespaces. In the example above, the
"uml:Package" element is a bit special, because it is the top-level
element in the XMI, but below that it generally becomes quite simple:
for example the next line would lead to the instantiation of a
"PackageMerge" object, and the name of the tag tells us which property
of the parent object (the Package) is used to hold it, namely
"mergedPackage". This is great and works as long as you are in the same
namespace. towards the bottom of the same file however:

  </uml:Package>
  <mofext:Tag xmi:type="mofext:Tag" xmi:id="_2" name="org.omg.xmi.nsPrefix" value="uml" element="_0"/>

here we have an elemt from a different namespace "mofext". In this
particular case it's not that bad because this is also a top-level
element in the XMI, so there isn't really a relationship between this
and any element of the "uml" namespace apart from the "element"
reference. In the examples for UML 2.5 Diagram Interchange [2] however:

<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" ...>

notice that there is a "Package" element from the "uml" namespace and
a *nested" "Diagram" element from the "umldi" namespace. Clearly there
is an intended relationship between the package and the diagram, but I
can't see how that could be represented in the abstract model! which
property of the package would hold the diagram? also note that "Diagram"
does not derive from any "uml" type, so the Package can't even hold the
diagram if it had a property simply because there is no base type of
Diagram that "Package" would know about. If you look at figure 7.1 in
[3], you can see the link from diagram elements to model elements, which
of course is possible through the UMLDI specialization, e.g. the
UMLDiagramElement type in UMLDI 2.5 adds a "modellElement" property of
type "Element" from the uml namespace. To me it looks however that there
needs to be some way to do the opposite: refer to a UMLDI elemnt such as
a Diagram from a UML package, but I do not understand how that would be
possible.

any pointers appreciated! I'll also post these questions on other UML
forums if I can find any, appologies for the noise to people who are
subscribed to both. I'll report back any findings I get from other
sources for those interested.

thanks  robert

[0] http://www.slideshare.net/seidewitz/uml-25-specification-simplification
[1] http://www.omg.org/spec/UML/20110701/L1.xmi
[2] http://www.omg.org/spec/UML/20131001/PrimitiveTypes.umldi.xmi
[3] http://www.omg.org/cgi-bin/doc?ptc/14-03-02.pdf

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

Attachment: signature.asc
Description: Digital signature

Back to the top