Community
Participate
Working Groups
The imported element decorator is shown when an element is visually attached to an element do which it does not belong with respect to the containment hierarchy. This is sometimes not useful. For instance in composite structure diagrams, ports of parts have the decorator, since the port does not belong to the part but the type of the part. While this is correct, the decorator is rather harmful, since it makes the diagram harder to read and might hide stereotype icons on the port. Another example are constraints: in the moment, the context element is set, the constraint will have the import icon.
The following elements are known to display an invalid "import" decorator: - Message in Sequence Diagram - Constraint/Comment in all Diagrams - Port on Part in Composite Diagram (And IBD, most likely) (This list is not exhaustive) Moreover, this decorator is displayed for inherited members in all diagrams. However, the UML 2.5 specification adds a new standard notation for inherited members (^): ^ myProperty : String ^ myOperation(p1, p2) : Integer We should use this notation instead of the decorator (See UML 2.5, Section 9.2.4)
Created attachment 240585 [details] Screenshot
I've attached a Screenshot of another scenario where I see the icon incorrectly. This occurs when you drag and drop on property from a class onto the diagram surface outside the class.
Well, this actually is a valid case for displaying the decorator. The property doesn't belong to the diagram (Because the diagram represents the root Model).
I don't agree. There is only one Model here and so the diagram should show everything in the model as local. The agreed use-case where there are multiple packages/diagrams (in one model) and an interface is used from a different (the other package in the model) package is totally different in my view.
The algorithm is more complex than I thought it would be. It's quite hard to define a generic algorithm with properly understands the specifics of UML (Even if we only care for external resources and external packages) There are many cases where an element is displayed in a different package, simply because it is reused (e.g. white box classifier reuse: we display the properties of the type, in the graphical context of the element referencing the component, which may be in a different package than the referenced component). I'm not able to provide a truly generic algorithm, so... it's better than before, but there may still be similar corner cases (To be identified, but from my experiments so far, it seems OK) Fixed in e3e5210, pushed to master. Please reopen if you find any new invalid case. The expected cases are: - Elements from an external package (Excluding Constraints and Comments which are really specific) - Inherited properties (When displayed in their Classifier only: for Parts with ports, white box references, ..., decorator should never be displayed) Note that, if you display an external/imported Package, with its contents (white box package), only the Package will be decorated. However, if you display its elements one by one on your diagram, they will properly be decorated (Not sure if that's clear)
The option to reopen this one is not available. When a component inherits from another component having ports, the ports when displayed on the subtype get these decorators.
> The expected cases are: > > - Elements from an external package (Excluding Constraints and Comments which are really specific) > - Inherited properties (When displayed in their Classifier only: for Parts with ports, white box references, ..., decorator should never be displayed) Ports are properties, so Inherited ports are inherited properties We might remove the decorator for all ports
Thanx Camille.
Created attachment 250452 [details] Screen shot of element imported This also seems to happen when diagrams and elements are moved in a package hierarchy. In this scenario, I creates a package named "Use Cases". In this package, I created a use case diagram named "Actors" that contains six actors in a hierarchy. The diagram did not show any ""This element is imported" decorators. I then created a package names "Actors" in (under) the "Use Cases" package and moved the "Actors" diagram and all the actors to this new package. Note that the diagram and the actors are still at the same package hierarchy level. However, all the actors have the "This element is imported" decorator. In "Advanced" properties, the actors are shown in the "<Package> Actors>" namespace whereas the diagram is still in the "<Model> Papyrus-RT" namespace (even though it was moved and is, visually, under the "Actors" package). See attached screen shot. If I create a new use case diagram in the "Actors" package, its "Advanced" properties show its namespace to be "<Package> Actors" and its qualified name to be "Papyrus-RT::Use Cases::Actors", as I would expect. Adding one of the actors to the diagram also does not display the ""This element is imported" decorator, again as expected.
> In this scenario, I creates a package named "Use Cases". In this package, I created a use case diagram named "Actors" that contains six actors in a hierarchy. The diagram did not show any ""This element is imported" decorators. > > I then created a package names "Actors" in (under) the "Use Cases" package and moved the "Actors" diagram and all the actors to this new package. Charles, The diagrams have two distinct containers: the graphical container (as shown in the Model Explorer and properties view: "Owner"), and the semantics container (Properties view: "Root Element") In this case, I suspect you only changed the graphical container. You can verify that by selecting the Diagram in the ModelExplorer, go to the "General" tab in the properties view, and check the "Owner" and "Root Element" properties. Changing the "Root Element" property should remove the decorators. IMO this works as expected, since it was a feature request to have the ability to use a different Graphical and Semantic container for Diagrams.
Unfortunately, that behaviour is counter-intuitive. I would expect, if I move an element in the model explorer (regardless of its type or purpose), for that element to now be part of that new namespace, as implied by the structure of the model explorer. However, what you are stating is that behaviour does not apply to diagrams. This means that the same action (moving a model explorer element) in the same context (the model explorer) produces different results. From a user's point of view, this is inconsistent and therefore unexpected behaviour. I would also contend that this would not be an expected outcome from a new Papyrus modeler who would not immediately think of looking at the "General" Properties tab, much less understand the difference between "Owner" and "Root Element" when it applies to semantic vs. graphical elements. What is also seemingly inconsistent here is that in the "Advanced" properties, the namespace for the diagram is set to the model ("<Model> SysMLmodel" in my case). Would you have a use case or user story for the feature to "have the ability to use a different Graphical and Semantic container for Diagrams"? I would like to understand the context for that feature. By the way, from a user's perspective, "as designed" is not the same as "works as expected". In this case, I would have used the former rather than the latter to describe the situation.
> Would you have a use case or user story for the feature to "have the ability to use a different Graphical and Semantic container for Diagrams"? I would like to understand the context for that feature. The first user story I have in mind for this feature is a neighborhood diagram for a class, that describes the relationship it has with other classes in the model (provided/required interfaces, associations, etc.). To find easily this diagram for a class (named Class1), user would like to add this diagram as a child of this class in the model explorer (graphical owner). However, the context of the diagram (root element) is not the class itself, but its container. In fact, if you create another 'neighbor' class and have an association with it, you would like to have this class not as a nestedClassifier, but contained by default by the same container as the class Class1
(In reply to Remi Schnekenburger from comment #13) > > Would you have a use case or user story for the feature to "have the ability to use a different Graphical and Semantic container for Diagrams"? I would like to understand the context for that feature. > > The first user story I have in mind for this feature is a neighborhood > diagram for a class, that describes the relationship it has with other > classes in the model (provided/required interfaces, associations, etc.). > To find easily this diagram for a class (named Class1), user would like to > add this diagram as a child of this class in the model explorer (graphical > owner). However, the context of the diagram (root element) is not the class > itself, but its container. In fact, if you create another 'neighbor' class > and have an association with it, you would like to have this class not as a > nestedClassifier, but contained by default by the same container as the > class Class1 Interesting user story (although not in the right form... ;-), thanks Rémi! However, Papyrus has both "Class Diagrams" and "Inner Class Diagrams" (the latter for classifier?) - what are the differences between the two? Papyrus will only let me create an "inner class diagram" under the class in the model explorer. I noticed that I can neither drag a (non-inner) class diagram into a class nor drag an inner class diagram into a package (or another class for that matter). So it appears that your user story uses diagram elements that will (by design?), not reproduce my scenario. Would you then have a user story that address the use of the (non-inner) class diagrams to "have the ability to use a different Graphical and Semantic container for Diagrams"?
(In reply to Camille Letavernier from comment #1) [...] > Moreover, this decorator is displayed for inherited members in all diagrams. > However, the UML 2.5 specification adds a new standard notation for > inherited members (^): > > ^ myProperty : String > ^ myOperation(p1, p2) : Integer > > We should use this notation instead of the decorator (See UML 2.5, Section > 9.2.4) Note that this is also a requirement for SysML 1.4!
