Community
Participate
Working Groups
The "ContainmentLink" is a graphical information that represent the ownership relation between two element (SysML spec. 7.2). It can currently be used between Packages or between a Class and its nested Classifier(s). The ContainmentLink appears as a link with a round anchor (containing "+" sign) on the owner side. The expected behavior is the following: Creation with the palette tool 1. Prevent containment cycles: - forbid creation of the link from an element to itself - forbid the creation from an element to any element from its owning hierarchy 2. Change the model to reflect the ContainmentLink information - creation from A to B results in A moved into B in the model - creation from A to B results in simply showing the link in the diagram if B is already contained in A 3. Several ContainmentLink anchors can be shown - creation from an existing ContainmentLink anchor result in reusing the anchor and adding a link - creation from the owner Package result in showing a new ContainmentLink "anchor + link" Drop from the Explorer in the Explorer - The expected behavior here is to move the element into a new owner (moving a Package into another Package) - Deprecated ContainmentLink shown in diagrams should be removed Drop from the Explorer in the Diagram -> two alternate behaviors - Show the dropped element in the Diagram -> Do not try to show any containment link in the diagram here Drop from the Diagram in the Diagram -> two alternate behaviors 1. (drop) - Modify Package ownership when dropped in another Package -> Deprecated ContainmentLink shown in diagrams should be removed 2. (alt+drop) - Do not modify Package ownership
*** Bug 317997 has been marked as a duplicate of this bug. ***
*** Bug 316433 has been marked as a duplicate of this bug. ***
*** Bug 314255 has been marked as a duplicate of this bug. ***
*** Bug 310596 has been marked as a duplicate of this bug. ***
*** Bug 300666 has been marked as a duplicate of this bug. ***
*** Bug 297418 has been marked as a duplicate of this bug. ***
Created attachment 173089 [details] Initial refactoring of ContainmentLinkReorientCommand The factoring not also makes the code more readable and easy to maintain, but allows to reorient target of the link properly even if the target is contained by other elements.
(In reply to comment #0) > ...Creation with the palette tool > 1. Prevent containment cycles: > - forbid creation of the link from an element to itself > - forbid the creation from an element to any element from its owning > hierarchy > 2. Change the model to reflect the ContainmentLink information > - creation from A to B results in A moved into B in the model > - creation from A to B results in simply showing the link in the diagram if I've rewritten corresponding CreateLink and ReorientTarget commands in order to support this functionality. Circular and self dependencies are prohibited now. While Containment Link Package->Package, Package->Class, Class->Class for fine now, including inner elements, what was not supported before. Reorient target also works fine now. Several additional bugs were fixed, e.g. Model to Model containment link doesn't change structure in a domain model or Trying to reorient link target to another link or ContainmentCircle caused an exception - fixed now.
4. Delete Command: When the user deletes the source of the containing link from the model its target ia actually also deleted. But current implementation only deletes the link itself, link targte is still displayed even though it no longer exists. It causes multiple NPEs from different places - diagram editor, properties view and so on. The expected behaviour is to delete target view after source delete as target element doesn't exist.
(In reply to comment #9) > 4. Delete Command: > When the user deletes the source of the containing link from the model its > target ia actually also deleted. But current implementation only deletes the > link itself, link targte is still displayed even though it no longer exists. It > causes multiple NPEs from different places - diagram editor, properties view > and so on. > The expected behaviour is to delete target view after source delete as target > element doesn't exist. Delete is implemented if source Package/Class is deleted. Or when the containment circle is deleted. In that case views for contained elements are deleted recursively. The user is asked with the dialog if he really wants to delete these elements (now implemented for Containment Circle only), this operation is undoaable.
Created attachment 174143 [details] mylyn/context/zip impacted classes
add a modification for the drop from the model explorer, now it is impossible to drop a element if the target is not a diagram or not the semantic owner
Fixed in Helios
