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
metamodel.
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()
and
ownedElement->forAll(oclAsType(UMLDI::UMLDiagramElement).showsUMLContentOnl
y())
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?