UML 2.6 RTF Avatar
  1. OMG Issue

UMLR — What is a UML diagram? is it restricted to showing elements that are instances of the M2 UML metamodel and nothing else?

  • Key: UMLR-433
  • Legacy Issue Number: 18854
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Figure B.3 in UML 2.5 effectively prevents any possibility of using UMLDI
    for anything but pure UML models.
    By pure UML models, I mean a UML model where all of the model elements are
    CMOF::Elements classified by an M2 UML classifier from the M2 UML
    This excludes the possibility of using UMLDI for mixed UML models, that
    is, UML models that can include instances of classifiers from other
    metamodels or classifiers defined in a UML Profile applied to such model.

    These restrictions come from the redefinition approach taken for defining
    UMLDI as a closed, non-reusable extension of the DI metamodel:

    1) UMLDI::UMLDiagramElement::modelElement : UML::CommmonStructure::Element

    { redefines DI::DiagramElement::modelElement }

    2) UMLDI::UMLDiagramElement::ownedElement : UMLDI::UMLDiagramelement

    { redefines DI::DiagramElement::ownedElement }

    3) UMLDI::UMLDiagramElement::owningElement : UMLDI::UMLDiagramElement

    { redefines DI::DiagramElement::owningElement }

    4) UMLDI::UMLEdge::source : UMLDI::UMLDiagramElement

    { redefines DI::Edge::source }

    5) UMLDI::UMLEdge::target : UMLDI::UMLDiagramElement

    { redefines DI::Edge::target }

    These redefinitions have significant consequences:

    • One cannot reuse UMLDI as part of a new DI-based metamodel because UMLDI
      excludes any possibility of UMLDiagramElements to be owned by anything but
      a UMLDiagramElement.
    • One cannot reuse UMLDI as part of a mixed UML+BPMN DI metamodel because
      the only kinds of DI::Edges that a UMLDI::UMLDiagramElement can be the
      source or target of is a UMLDI::UMLDiagramElement
    • One cannot extend UMLDI because (1) restarts the use of the DI framework
      within UMLDI for pure UML content – that is, M1 models where everything
      is an instance of an M2 UML classifier.

    These restrictions pose a problem for UML tools that currently allow
    diagrams to show notation for mixed content – e.g., UML + images + tables
    + notes + powerpoint/visio like shapes/lines or diagrams showing content
    from multiple metamodels.
    Since UMLDI is too restrictive to support such diagrams, tool vendors will
    be faced with undesirable, expensive tradeoffs:

    • Keep the current diagram support, add support for UMLDI
    • Delay adding support for UMLDI until the OMG loosens the restrictions
    • Use UMLDI as a notional metamodel and implement one that has the
      capability to support existing diagram capabilities so that the tool can
      use DI-based diagram interchange (for the subset of pure UML models).
    • Ignore UMLDI

    For tool vendors, these tradeoffs mean expensive business decisions about
    supporting UMLDI.

    The advantage of this restrictive approach is that it certainly clarifies
    what a UML diagram is and what it can show – I.e., instances of the M2
    UML metamodel and nothing else.
    The disadvantage of this restrictive approach is that any diagram that
    shows anything that is not an instance of the M2 UML metamodel is, by
    definition, not a UML diagram.
    (in practice, that means a lot of diagrams would not be UML2.5 UMLDI
    diagrams anymore)

    This approach seems very inflexible.

    A more flexible approach would be to define UMLDI by subsetting the DI
    associations instead of redefining them.

    The advantage of this subsetting approach is that it allows extending and
    reusing UMLDI by adding additional associations that subset the DI
    associations as necessary.
    The disadvantage of this approach is that the scope of a UML diagram
    becomes open – that is, a UML diagram could also include instances of
    something other than the M2 UML metamodel and no instances of the M2 UML
    metamodel and still be called a UML diagram.

    This could be easily addressed with queries:

    UMLDI::UMLDiagramElement::showsUMLContentOnly() : Boolean

    modelElement->forAll(oclIsKindOf(UML::CommonStructure::Element)) and
    ownedElement->select(not oclIsKindOf(UMLDI::UMLDiagramElement)->isEmpty()

    Then, diagram interchange tests could be conducted for UML models where
    the UML diagrams satisfy UMLDI::UMLDiagram::showsUMLContentOnly()

    Do you agree that loosening the UMLDI metamodel as described above makes
    sense and is important enough to do urgently for UML 2.5?

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:28 GMT