Community
Participate
Working Groups
Hi, the palette entry 'Interface Realization' creates instances of Realization. Although this is not incorrect with respect to the UML spec, however, it should create InterfaceRealization nonetheless. There is a big ambiguity in the spec about what relationship should be used for realizing an Interface. Although UML 2.4.1 Component.realizedInterfaces() is based on a Realization relationship, this may lead to weird results, since every subclass of Realization (i.e., InterfaceRealization, Substitution, ComponentRealization) would be incorporated in this calculation, so that a Substitution dependency with source element Component and target element Interface would also deliver to the realized Interfaces of the supplier Component. This is just wrong. I've already submitted an issue (not recorded yet, will add a comment as soon as there is an official link at OMG for this) to the UML 2.5 team. So, I recommend using solely InterfaceRealization for Components. Since InterfaceRealization is a subclass of Realization, there is actually no visible change for the user (the model is still valid), but it's clearer this way. Consider a situation where a user solely uses Realization for Components and then asks for Component.interfaceRealiaztion. The list would be empty, the query realizedInterfaces() would deliver the Interfaces which are connected to the Component via Realization.
I used Kepler M5 and Papyrus nightly build 20102201526