Community
Participate
Working Groups
Created attachment 253702 [details] Result of attempting to create Realization branches Papyrus Mars RC1 Realizations, like some other dependencies, can have multiple suppliers and multiple clients. So, any diagram that provides a Realization tool should also provide a Realization Branch tool. In an attempt to specify a realization with multiple clients, I used the Dependency Branch tool to connect a second client to an existing realization. The result is attached. Particularly odd is that now the connections have nonsensical 'import' decorations applied to them. Likewise the Abstraction (superclass of Realization) and ComponentRealization (subclass of Realization) metaclasses should also have branch tools. The latter is slightly more complicated because the ComponentRealization can have multiple client Classifiers but only (and exactly) one supplier Component, so only client branches make sense. Also, I would expect other class-like diagrams to support the Realization relationship, in particular Component and Package, but they don't.
So, it seems that the 'import' decorations appear because the realization is created (in this case) as an owned element of the first client package, but once its visualization has been (incorrectly) changed to dependency-like, dependencies are expected to be owned by the package that is the context of the class diagram. When I move the realization (it does correctly have two clients now) to be a packaged-element of the class diagram's context package, the import decorator disappears. But, the connector still looks like a dependency, not a realization.