eclipsesource / papyrus-umllight

Eclipse Public License 2.0
4 stars 2 forks source link

Fix #9 Use case diagram #27

Closed cdamus closed 6 years ago

cdamus commented 6 years ago

Define the UML Light flavour of the Use Case Diagram, including

This also includes a couple of new elements of a more cross-diagram concern that should be called out, as described below. These are introduced to support the narrowing of the subject concept of the UML use case diagram to classes specifically, whereas the concept that could be reused from Papyrus UML is generically "classifier as subject" which brings in unwanted complexity.

Element Types

This PR adds an element-types configuration model for UML Light, in particular for "DI types" (visual specializations of element-types for the diagrams). This introduces the Class as Subject type that is not defined by Papyrus UML, which is needed for the specification of palette tools and modeling assistants in the UML Light use case diagram. The "Classifier as Subject" type from Papyrus UML is too broad and requires users to choose from amongst several inappropriate (in the light domain) classifier metaclasses to instantiate.

In the (hopefully rare) case that we should need any more specialized types for UML Light, we can add them to this resource.

Modeling Assistants

With the diagrams defined so far for UML Light, we have been able to re-use the model assistants provided by Papyrus UML via inclusion/exclusion rules in the Architecture Model. However, that is not sufficient for support of the subject concept in the use case diagram because that needs to instantiate the new "Class as Subject" type discussed above.

In Papyrus, we generally keep each diagram's assistant definitions in a resource of its own, so that's what I've done here. If we need to define new assistants for other UML Light diagrams, I would suggest that they should be in new resources specific to those diagrams.