Add Part and Shared Association to Tool Palette #352
Conversation
Signed-off-by: Dan Yeaw <dan@yeaw.me>
|
I think in the icon, the diamond on the association end may be a little smaller. Also I'd like this in the UML palette too. |
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
|
@amolenaar Thanks again for the feedback.:clap: I made those two updates. What do you think of the updated icons? |
Those look really nice 👍 |
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
| """ | ||
| opposite = self.line.opposite(handle) | ||
| c1 = self.get_connected(handle) | ||
| c2 = self.get_connected(opposite) | ||
| if c1 and c2: | ||
| old: UML.Association = self.line.subject | ||
| del self.line.subject |
There was a problem hiding this comment.
@amolenaar In order to keep the UML.Association including the navigability and aggregation, does this seem reasonable to you to not delete these on disconnect?
There was a problem hiding this comment.
This will, however, disconnect the member end from everything. Including the model. So these memberEnd properties can not be reused... Same goes for self.line.subject.unlink(): the Association instance will be completely removed from the model. This causes errors when saving and loading the model.
Since the Association and its memberEnds are created when the item is placed on the diagram, they should remain part of the model after disconnecting. Alternatively, we can just create the Association and add the memberEnds only when an association is connected. It will violate the multiplicity constraint, though ([2..*]).
I think this approach makes sense. An Association is also a Classifier, so it has a different role than, say, Generalization. Also, this will allow us to create Association Classes (or 3/4/5-way associations for that matter).
The trade-off is we give up the possibility to present an association in different diagrams. We can always work around this by offering such an option though the element editor, which may be fine, since I generally to not tend to use associations in multiple diagrams anyway.
There was a problem hiding this comment.
@amolenaar Thanks for the clarification on the unlink!
Ideally I think the associations should be reusable in many diagrams. A user should be able to grab a few elements in a model and then ask the model to display the relationships that already exist.
I thought we had to create the Association and memberEnds to display the navigability and aggregation. This is how it was a few commits ago, the association goes back to being a plain one as soon as you disconnect it.
There was a problem hiding this comment.
Ideally I think the associations should be reusable in many diagrams. A user should be able to grab a few elements in a model and then ask the model to display the relationships that already exist.
That would be a nice feature. But it's different from:
- create a diagram with 2 classes and draw an association between them (name it "foo")
- create a new diagram, add the same 2 classes and draw another association
- Will the association be:
a. a new association
b. be the already existing association named "foo"?
Currently we do option 3a. Which is fine IMHO.
I thought we had to create the Association and memberEnds to display the navigability and aggregation. This is how it was a few commits ago, the association goes back to being a plain one as soon as you disconnect it.
Indeed you'll need both Association and the Properties at the memberEnds. Since the logic on navigability lies at the model. Not in the diagram items. It should, however, still disconnect the "type"s at the end. In the connect() method, the association ends are paired with the classes they connect to. On disconnect, this relation should be removed I think. Otherwise the model and the diagrams are no longer in sync.
There was a problem hiding this comment.
Thanks good catch. I don't think I was properly connecting the the type to the element either. How does this look?
|
@amolenaar I think this is ready, would you mind giving me your feedback on the two items above?
Thanks! |
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Sourcery Code Quality Report (beta)✅ Merging this PR will increase code quality in the affected files by 0.01 out of 10.
Here are some functions in these files that still need a tune-up:
Please see our documentation here for details on how these metrics are calculated. We are actively working on this report - lots more documentation and extra metrics to come! |
|
@amolenaar Anything left to do before I merge this? |
Signed-off-by: Dan Yeaw dan@yeaw.me
This PR adds buttons to the tool palette for creating a Part (Direct Composition) and Shared Associations. This save a few step when create a Block Definition Diagram, so that you don't have to create an association and change the navigability and aggregation each time.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: Partial #138
What is the new behavior?
Does this PR introduce a breaking change?
TODO