h1. Conception of the external profile application management module
Currently, profile applications are serialized within the same file as the model itself. This feature will enable to serialize profile applications within a dedicated file. This feature will be an option that the user may configure within the Papyrus preferences. If one applies several profiles on a model, each profile application is serialized within its own resource. It has to be possible to switch from one configuration to the other, i.e. either to externalize profile applications or to internalize them.
Control mode shall be taken into consideration here and should continue to work correctly.
h3. Enable external profile application
The purpose of this task will consist in patching the UML2 component in order this latter can fully support the possibility to apply profiles on UML models by serializing this profile application in a separate file and vice-versa. Papyrus UI has also to be enriched in order to enable the user to configure Papyrus in order to enable or disable this option. The process will be reversible, i.e. profiles would be serializable individually in or out the model resources. In addition, the tool will also support the ability to apply several times the same profile. In case of a profile has been applied several time (values of the stereotype properties would be possibly different in that case), only one profile application is defined as part of the current configuration.
h3. Control mode extension
This task will consist in analyzing the impact of the externalization of profile serialization and update its design in order the control mode can still run correctly in that case. The test set of the control mode will also be extended to cover this new use case.
# currently, the profile application themselves are part of the model (this is a real element in the UML metamodel). the stereotype applications are located in the same resource as the model, at the same level as the model itself. The goal of this module is to separate the stereotype applications from the model resource and to put them in one or several external resources.
# Several strategies are possible to manage profile applications in external resources. Each profile application can be saved in a separated resource, or all profile applications can have their own resource. This would ease the management of view points on the model (loading or not a given profile would be easy, and so specific domain concepts would be present or not. The sub profiles should also be taken into account: do each sub-profile need its own resource, or the resource is managed by the main profile (example of SysML)
# The naming of the resource: name of the profile should be present. the name of the UML element on which the profile is applied should be used, in order to be able to have several external resources for the same profile in case of control mode. Should the version of the profile be present also ?
# integration with the control mode: should one/several new resource be created when splitting the model?
# integration with rename/copy files
# integration with copy paste: does the current extension of the copy/paste work with this module?
# profile migration: when Papyrus detects that a new definition of a profile is available, the migration needs to account for externalized stereotype applications. These must be loaded, converted, and unloaded again if not currently loaded; this is very like the stereotype repair functionality
# do we really need to be able to store profile applications independently of their applying packages? And multiple applications of the same profile? It should be sufficient to store stereotype applications separately, and perhaps multiple disjoint sets of applications of the same stereotypes from the same profile on the same model elements. What really matters in UML terms is the discovery and loading of a particular set of stereotype applications; the profile application has no value except in determining which stereotypes are applicable in a given scope
h2. Current external mechanism limitations
h3. Stereotype application helper
UML2 module provides a framework for externalization of the stereotype applications, but this mechanism is rather basic. It relies with a singleton helper, referenced in the java system properties. If the externalization is done, it will be done for all components in the installation relying on UML2 metamodel, not only Papyrus models. Moreover, only one Eclipse component can provide a customization. If another component that Papyrus relies on that extension mechanism, only one will work at the same time.
* should be simple to let stereotype application helpers be attached to a resource set
h3. Required extensions
Stereotypes may define required metaclass extensions, which imply that every instance of the extended metaclass in the scope of the profile application must have an application of the stereotype. This is actually enforced by the UML API at run-time; when a profile is applied that has required extensions, the stereotypes are applied to all elements that require them. Also, when an element is attached to the model, all required stereotypes are applied that are not already applied
* the enforcement of required stereotypes is suppressed when loading a model, which means that required stereotype applications can be stored in separate resources and loaded separately
* a resource containing required stereotype applications may be unloaded. The UML API tolerates required stereotype applications being unapplied in this way
* for profiles that do not have any required extensions, it is feasible to edit the model without having any stereotype resource loaded. Not so if it has required metaclass extensions, because any attachment/move/reattachment of an element will cause it and all of its contents to have required stereotypes applied. If a stereotype resource is not loaded at the time, then the UML API will think the required stereotypes are unapplied and will try to apply them