Is your feature request related to a problem?

The UML model in Gaphor is not presently self consistent. These inconsistencies arise in the modeling of associations and fall into two categories:

1. Subsets having a multiplicity greater than their supersets
2. Associations having one end as a derived set and the other end a settable value.

As described below, resolving one of the subset inconsistencies would require changing the multiplicity of the core Relationship.target property, which is likely to have far-reaching impacts on the behavior of Gaphor when editing and displaying models.

The discussion below explores some of these inconsistencies in detail. It is likely that there are many others yet to be discovered.

BehavioralFeature.ownedParameterSet

The BehavioralFeature.ownedParameterSet property is modeled with a multiplicity of 0..*, but is declared to be a subset of Element.namespace which has a multiplicity of 0..1. Pull request #3525 changed the BehavioralFeature.ownedParameterSet multiplicity to 0..1. This change was straightforward and is consistent with the UML standard.

Property.classifier

The Property.classifier property is declared to be editable (i.e. not derived). Its opposite Classifier.attribute is declared to be a derived property and therefore is unsettable. This breaks the current logic of the Association.set() operation when Property.classifier is assigned a value.

In the UML standard, Property.classifier is declared to be a read-only derived union of Property.interface and Property.class. Since these subset declarations are already present in the Gaphor model, pull request #3525 changed Property.classifier to a derived union. This change was also straightforward and is consistent with the UML standard.

Deployment.deployedArtifact

This one is problematic with the present Gaphor Core structure. The Deployment.deployedArtifact property is modeled in Gaphor with an multiplicity of 0..*, but is declared to be a subset of Dependency.supplier which has a multiplicity of 0..1. The Dependency.supplier property is, in turn, declared to be a subset of Relationship.target, which also has a multiplicity of 0..1.

In the UML standard, Dependency.supplier has a multiplicity of 1..* and DirectedRelationship.target has a multiplicity of 1..*.

So the solution is to change the Gaphor Dependency.supplier and Relationship.target model dependencies to 1..*. However Relationship in Gaphor is presently a 1:1 mapping and this class is widely used. It is quite likely that the dynamic editing and display behavior of Gaphor makes assumptions about the multiplicity of Dependency.supplier and Relationship.target. Consequently, the scope of this change will be large and will, I suspect, require significant manual testing in addition to the automated testing already in place. This inconsistency has not yet been addressed.

Describe the solution you'd like

The Gaphor model should, at a minimum, be self-consistent and, ideally, conform to the UML model standard.

Describe alternatives you've considered

Additional context