Class and Package Diagram Consistency

[cdamus]

The discussion of Pull #22 reveals some apparent inconsistency in the requirements for Class Diagram and Package Diagram, both internally within the UML Light product and also in comparison with Papyrus UML.

In particular, there are two questions that need answering:

• what is the purpose of supporting the visualization of packages in a UML Light class diagram? Is it only for the relation of packages to the classifiers presented in the diagram (usually namespace/containment), or is it also to present relationships between packages? In the latter case, should the UML Light class diagram then allow the creation/visualization of PackageImport relationships?
• in the Papyrus UML product, the Package Diagram is defined as a strict subset of the Class Diagram. This implies that, deliberately or not, the Class Diagram in Papyrus UML is a superset of the Package Diagram. As such, it allows creation/visualization of PackageImport relationships and the "containment link" connector that the UML Light variant of the Package Diagram supports but not its Class Diagram. Do we want the same subset relationship between these diagrams in UML Light as in Papyrus UML?

[CharlesAtZelig]

I hope this wont be too convoluted... For what it's worth, here is what I think about this, from a user/practitioner's point of view, and not that of a toolsmith or standard writer!

And, as is the case in many standards (esp. those written by committee ;-), there will be many dissenting voices from people closer to the spec than I am.

UML has both good and bad sides: on the good side, you can do a lot of things that will help people understand what you are trying to do, on the bad side, you can do a lot of things and some people will complain about the way you are using the tool. ... and sometimes they're the same people.

This leads to the question of essense (borrowing from Ivar Jacobson). UML seems to have been designed to accommodate many approaches (methods, rules, etc.) So what follows is my approach when I model and, as such, should be taken with a pinch of salt (as too much salt is not good for you...). So the following is just my view on this topic.

I would say that, although is it possible, I would refrain from droping a package onto a class diagram. A class diagram is there to represent classes and how they interact. Classes typically interact with other classes and class-like elements, e.g., primitives. IMHO, classes should interact with other classes, not collections (in its generic meaning here). having a <> relation to a another class is meaningful, having the same relation to a package can be meaningless at that level...

However, the ability to see classes in a package diagram is meaningful information as to the packaging of the elements to express, e.g., layers or groups of classes that can then be places in components.

I am also not a big fan of the <<use/import/merge>> relationships. I recognize their use, but they can lead to confusion with some users. I usually prefer the notation of showing these are compartments in packages (and classes, for owned classes), when supported.

As for the last question, "Do we want the same subset relationship between these diagrams in UML Light as in Papyrus UML?"

This is, from my point of view, more of a compatibility issue. What happens if a user of Papyrus UML Light "graduates to Papyrus and observes different behaviour for the same action? That would likely be an issue. This is no longer a question of essense but one of functional compatibility, and I don't think it would be a good thing.

To paraphrase Mark Twain (I hope...): I am sorry I did not have the time to write a short answer...