search

eclipsesource / papyrus-umllight

Eclipse Public License 2.0
4 stars 2 forks source link

Fix #7 Package Diagram #22

Closed cdamus closed 5 years ago

cdamus commented 5 years ago

Define a Package Diagram as a refinement of the Class Diagram, essentially just selecting a subset of what can be shown in the latter.

However, more importantly, add initial creation-menu models for the UML Light dialect:

It is expected that these creation menu models will likely need further refinement according to the various specific issues scheduled in this milestone.

I also include some Eclipse project metadata files to enable working on the upper layers of the Maven module structure in the workspace.

cdamus commented 5 years ago

The question of profile applications is one that I have pending in the comments on Issue #7, addressed to @planger. I can remove profile and application tools for now at least. I would expect that we still need UML Light users to be able to customize the language via profiles, but perhaps not.

I understood that the diagram assistants customization is tracked by separate issues, because it is a quite separate mechanism from everything else. But I don't actually see those issues on the list, so perhaps it does need to be handled in this PR.

The package diagram includes exactly a subset of what the standard class diagram presents, so in Papyrus it is implemented by re-use of the class diagram definitions using these palette rules. That seems to make sense, reusing where it's appropriate to do so and not just for convenience.

tortmayr commented 5 years ago

I would remove profile and application for now until the question in #7 is resolved.

The package diagram includes exactly a subset of what the standard class diagram presents, so in Papyrus it is implemented by re-use of the class diagram definitions using these palette rules. That seems to make sense, reusing where it's appropriate to do so and not just for convenience.

Ah I see. That seems to be reasonable. Thanks for the explanation.

cdamus commented 5 years ago

Thanks, @tortmayr for your review. I've rebased on the latest Class Diagram definitions and made changes as described in commit 0a998cc14d8781de46e37d30f9983a399a7c7833.

tortmayr commented 5 years ago

@cdamus The refinements look fine but there seems to be a problem with the palette. Not all allowed tools are available in the palette. (e.g. Model is missing). I guess the problem is that the palette rules are applied on top of the palette model for the Light Class Diagram instead of palette model for the default Papyrus Class Diagram image

cdamus commented 5 years ago

@cdamus The refinements look fine but there seems to be a problem with the palette. Not all allowed tools are available in the palette. (e.g. Model is missing). I guess the problem is that the palette rules are applied on top of the palette model for the Light Class Diagram instead of palette model for the default Papyrus Class Diagram

These tools were formerly defined in our UML Light Class Diagram palette, but now they've gone with the rebase. Likewise package merge in the Edges drawer. I think the Architecture Model should be able to target the Papyrus palette. Let me see ...

cdamus commented 5 years ago

This raises the question, though, why are there things that we want to support in the UML Light package diagram but not in the class diagram? The class diagram should support the same kinds of packages as the package diagram, and the same relationships such as package merge.

cdamus commented 5 years ago

Commit 4d8941ee477446e5f889542d7c1816b0f20fa964 should cover all of the package diagram's needs vis-a-vis the palette.

planger commented 5 years ago

Imho, the Model doesn't need to be in the palette. The root is always a Model, but after that, users can just create packages and that should be sufficient.

I agree that the Package Diagram shouldn't include things that aren't in the Class Diagram, except maybe PackageImport. Which are these that are only in Package Diagram, but not in the Class Diagram?

cdamus commented 5 years ago

Imho, the Model doesn't need to be in the palette. The root is always a Model, but after that, users can just create packages and that should be sufficient.

Okay, good. I'll be happy to remove that from the palette and from the assistants.

I agree that the Package Diagram shouldn't include things that aren't in the Class Diagram, except maybe PackageImport. Which are these that are only in Package Diagram, but not in the Class Diagram?

My suggestion was the reverse: the class diagram should include everything that's in the package diagram, plus all of the classifiers stuff. But maybe we don't want anything to do with packages in the class diagram? In any case, with commit 4d8941ee477446e5f889542d7c1816b0f20fa964 we have in the light package diagram these elements that aren't in the light class diagram:

It's odd to me that the class diagram would have package but not package import, but maybe the package is just for showing classifiers within its namespace, and not the relationships between packages?

planger commented 5 years ago

It's odd to me that the class diagram would have package but not package import, but maybe the package is just for showing classifiers within its namespace, and not the relationships between packages?

Right, let's maybe open a BR on that with the tag "question" so that we can collect things we'd like to discuss with the stakeholders. Thanks!

cdamus commented 5 years ago

Thanks, all! I've opened #26 to follow up these remaining questions.