Community
Participate
Working Groups
The Papyrus UML tooling would like to give users flexibility in the storage and loading of stereotype applications (bug 399859, bug 438966). In particular, the plan is that users be able to determine for any particular profile application whether applications of its stereotypes are stored in the same resource as the base elements (default UML2 behaviour), in some separate resource by themselves, or in multiple separate resources (enabling alternative disjoint sets of stereotype applications). The idea is that, in the case of separate stereotype application storage, Papyrus would load at most one stereotype resource at any time for a given profile application; users can load or not the stereotype applications according to their current viewpoint on the model. Anyways, this needs the flexibility in the UML API of allowing an application to install a StereotypeApplicationHelper that doesn't interfere with what other UML-based applications in the same Eclipse workbench are doing. Reliance on system properties doesn't work in the Eclipse context because although Papyrus could ensure that its custom behaviour is only applied to its own resource sets (delegating to the default helper otherwise), Papyrus can do nothing if some other application registers a helper of its own on the system property.
Created attachment 247240 [details] Proposed implementation of per-resource-set helpers Attached is a git e-mail patch proposing an implementation of per-resource-set stereotype application helpers. The StereotypeApplicationHelper adds API to associate a specific helper instance with a resource set and the UML APIs that need a helper look for one in the resource set (if there is a resource set). The shared instance remains as a default in case there is no resource set instance. Looking up the helper associated with a resource set should not have adverse performance impact because the helper is only used when applying and unapplying stereotypes, which is an editing operation. Merely computing applied/applicable stereotypes doesn't need to look for the helper, so performance of loading and reading models is not affected. Feed-back is welcome.
I can provide input wrt Bug 438966 when needed. :) /Toni
Presumably the OCL support will need to be aware of which stereotypes are actually in use.
(In reply to Ed Willink from comment #3) > Presumably the OCL support will need to be aware of which stereotypes are > actually in use. There is no change to how the UML implementation finds stereotype applications. The behaviour of the Element operations querying applied/applicable stereotypes is unchanged. And, indeed, UML has long since provided this helper mechanism to let applications customize the storage of stereotype applications. All that this enhancement requests is a better integration of that mechanism.
Ciao guys. Primary importance is defined by Bug 438966. Needed to work for deployment profiles having no OCL restrictions. (right now) Enabling product variant handling is of primary importance at this point. Those profiles (profile applications) are related to M2M and M2T transforms. Not sure if DSL-profiles having model-entry-time restrictions defined in OCL ever will have its "profile applications" stored in separate files. Not sure what tooling a user like to migrate to requesting such capability. Maybe during 2015-16 there will be such requests, while trying to support transformation of Executable UML and Action Language in Open Source tooling. This one is related to the old bugzillas Bug 396537, Bug 401899 and Bug 396543. Any progress reports and responses on those are appreciated. :) Regards/Toni
Created attachment 247397 [details] Revised patch with similar support for ProfileApplicationHelpers On further discussion of the Papyrus requirements for separation of stereotype applications, which includes also separation of profile applications from the user model, it is evident that a per-resource-set ProfileApplicationHelper is also needed. This revised patch implements the same per-resource-set affiliation of the ProfileApplicationHelper as for StereotypeApplicationHelpers. Also included are JUnit tests demonstrating the kind of profile application handling that Papyrus needs.
Christian, could you please provide a rebased patch?
Created attachment 248287 [details] Same patch rebased onto 0b1b083 I've attached a patch rebased onto master 0b1b0837654ad4c26accb11ebd3fed737802d90d
Thanks, Christian. The changes have been committed/pushed to the ‘master’ branch in git.
The changes are available in an integration build for UML2 5.1.
