Closed planger closed 6 years ago
Should the UML Light Class concept also support nested classifiers for Primitive Types, Enumeration, Interfaces etc. ?
@planger I think there are some concepts missing from the list in this requirement:
Also, I think there are items on the list that should not be:
And I wonder whether it can be argued that these don't belong in a UML Light dialect
I think there are some concepts missing from the list in this requirement:
- Constraint — sure, these can be complex, but even the most basic model needs to be able to specify constraints on the system that it describes
Yes, please add constraint. It is also listed in https://www.omg.org/ocup-2/coveragemap-found.htm which we used as a reference.
- Usage (or maybe this was implicit as a kind of Dependency, which is on the list)?
Hm, this is also not listed in the OCUP2 list, but Dependency
is listed. Isn't dependency enough?
Also, I think there are items on the list that should not be:
- Link: this part of instance modeling, and we don't have instance specification or slot (which I agree should be excluded)
Yes, please remove Link
for now. It is also not included in the OCUP2. Not sure why we added it.
And I wonder whether it can be argued that these don't belong in a UML Light dialect
- Realization — the semantics of refinement across design layers is fairly esoteric? Besides, we don't have its superclass Abstraction on the list, which I agree should be excluded
Realization
(only InterfaceRealization
is) is also not part of the OCUP2, so I guess we can remove it too.
- Interface and Interface Realization — these are weird in UML and very much geared towards component modeling. It appears that we don't even have Composite Structure and Component diagrams in the UML Light requirements, at all?
No, we don't have Composite Structure and Component diagrams included, only as far as similar concepts can be expressed in a class diagram. I think we left them in, because they could be part of Class Diagrams as well, right?
Thanks for the responses, @planger.
No, we don't have Composite Structure and Component diagrams included, only as far as similar concepts can be expressed in a class diagram. I think we left them in, because they could be part of Class Diagrams as well, right?
Yes, because classes are used to define the types of ports and attributes and things in components, and port types of course need the interfaces. 😀 I don't have a good picture of what the target audience is for the UML Light and so can't really say that interfaces won't be of use to them, so I'm happy to leave them in.
Addressed in #24
Yes, please remove Link for now. It is also not included in the OCUP2. Not sure why we added it.
I think we still need the Link concept for modeling the relation between comments and diagram elements.
Yes, please remove Link for now. It is also not included in the OCUP2. Not sure why we added it.
I think we still need the Link concept for modeling the relation between comments and diagram elements.
Right, that's the Comment_AnnotatedElementEdge
element-type in Papyrus. The Link concept from UML, being an instance-specification of an association, is what we need to exclude.
The UML Class diagram shall include the UML concepts listed below. This includes adapting the palette.