Diffstat (limited to 'plugins/doc/org.eclipse.papyrus.uml.decoratormodel.doc/resource/profileapplications.html')
1 files changed, 0 insertions, 3 deletions
diff --git a/plugins/doc/org.eclipse.papyrus.uml.decoratormodel.doc/resource/profileapplications.html b/plugins/doc/org.eclipse.papyrus.uml.decoratormodel.doc/resource/profileapplications.html
deleted file mode 100644
@@ -1,3 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/></head><body><h1 id="About_Externalized_Profile_Applications">About Externalized Profile Applications</h1><p>Ordinarily, profile applications in UML models are owned by the packages to which they apply profiles. However, Papyrus provides an extended
-semantics that externalizes the application of profiles, letting profile applications be defined separately from the packages that apply them.
-This has a few advantages:</p><ul><li>profile applications may be loaded and unloaded as required, to present extended attributes of model elements (as defined by stereotypes) when and if they are needed by the modeling user</li><li>multiple applications of the same profile to a package can provide alternative values for stereotype extensions of model elements</li></ul><h1 id="Externalizing_a_Profile_Application">Externalizing a Profile Application</h1><p>Consider the following small example of a model that has the Ecore profile applied: </p><p><img border="0" src="images/profile.png"/> </p><p>This model has two classes, both stereotyped as <tt>«eClass»</tt>. A CSS stylesheet paints EClasses yellow that specify the <tt>xmlName</tt> attribute and red that do not. Initially, this profile application is owned by the model. To separate it out into its own resource, invoke the <b>Refactor → Externalize Profile Applications...</b> context menu action on the applying package:</p><p><img border="0" src="images/refactor_externalize_menu.png"/></p><p>or select the profile application in the applying package's properties and press the externalize action button:</p><p><img border="0" src="images/externalize_button.png"/></p><p>Either way brings up the <b>Externalize Profile Applications</b> dialog:</p><p><img border="0" src="images/externalize_dlg.png"/></p><p>In this dialog, you must:</p><ul><li>select which profile applications to externalize (there may be more than one)</li><li>enter or browse to a model resource in which to put the profile application. It may be a new resource, or it may be an existing resource<ul><li><b><i>Note</i></b> that in the case of an existing resource, it must be a "profile application model". Profile applications may not be added to regular UML models</li></ul></li><li>enter a name for the profile application model (if it is new)<ul><li>if an existing profile application model is chosen to add the profile application to, then the name field is not editable as the model already has a name</li></ul></li></ul><p>After completing this dialog, it is recommended to save to create the new profile application model. This is similar to sub-model units, which are created when saving the parent model. The result is something like this:</p><p><img border="0" src="images/externalized.png"/></p><p>Note the new elements in the user interface, indicated by the arrows in the graphic above:</p><ul><li>a new UML resource is created containing the profile application. It shows a decoration indicating that it is a special kind of model, a <i>profile application model</i></li><li>the Model Explorer decorates the applying package (in this case, the root package) with the names of all of its externalized profile applications that are currently loaded</li><li>the properties of the applying package decorate the names of externalized profile applications to show which profile application model they are loaded from</li></ul><p>Moreover, the applying package has a new tab in its property sheet listing available and loaded profile applications. This is discussed further in the next section.</p><p>Note that in this example, the profile application model was created in the same project as the model to which it applies profiles. Profile application models may be created in any project in the workspace; they do not have to be in the same project as the models that they extend. Also, a profile application model may contain applications of any number of profiles on any number of packages in any number of models. The only restriction is that a single profile application model may not apply the same profile more than once to the same package. Two or more different profile application models may apply the profile to the same package in a user model, but then only one of them may be loaded at any one time in the context of that package.</p><h1 id="Loading_and_Unloading_Profile_Applications">Loading and Unloading Profile Applications</h1><p>Once a profile application has been externalized (see the preceding section), it may be unloaded and loaded again as needed. There are two ways to unload profile applications.</p><h2 id="Unload_In_Model_Explorer_View">Unload In Model Explorer View</h2><p>In the Model Explorer, select a package that has profile applications loaded and choose the <b>Unload Profile Applications...</b> action in the context menu:</p><p><img border="0" src="images/unload_menu.png"/></p><p>This brings up a dialog that lets you choose which profile application models to unload:</p><p><img border="0" src="images/unload_dlg.png"/></p><p>Finish the dialog to unload the selected models.</p><h2 id="Unload_in_Properties_View">Unload in Properties View</h2><p>Alternatively, in the <b>Applications</b> tab of the property sheet for a package that has externalized profile applications, select one or more loaded profile applications and press the unload button to quickly unload them:</p><p><img border="0" src="images/unload_button.png"/></p><p>The result on our example Ecore-profiled model is this:</p><p><img border="0" src="images/unloaded.png"/></p><p>The default styling in the diagram suggests that the <tt>«eClass»</tt> stereotype applications are now unloaded and the profile application's state in the property sheet is changed to <b>Unloaded</b>. Also, the root package no longer shows the decoration indicating loaded profile applications.</p><h2 id="Load_in_Model_Explorer_View">Load in Model Explorer View</h2><p>For packages that have available unloaded profile applications, the Model Explorer provides a <b>Load Profile Applications...</b> context menu action:</p><p><img border="0" src="images/load_menu.png"/></p><p>This brings up the <b>Load Profile Applications</b> dialog in which you may select the profile applications to load:</p><p><img border="0" src="images/load_dlg.png"/></p><p>Select the profile applications to load and finish the dialog to load them.</p><h2 id="Load_in_Properties_View">Load in Properties View</h2><p>In addition to any profile applications that are already loaded, the <b>Applications</b> tab in the property sheet shows those that are currently available to load:</p><p><img border="0" src="images/load_button.png"/></p><p>Select one or more unloaded profile applications and press the load action button to load them:</p><p><img border="0" src="images/loaded.png"/></p><p>As a quick alternative, you can double-click on an unloaded profile application to load it.</p><h2 id="Profile_Application_Resources">Profile Application Resources</h2><p>An externalized profile application is defined in a UML package in its own, separate, resource. As such, when it is loaded into the Papyrus editor, it appears in many respects like any other UML package. For convenience, the packages containing profile applications are hidden in the Model Explorer. However, they can be revealed if necessary by disabling the filter in the <b>Customize View...</b> view menu action:</p><p><img border="0" src="images/customize_view.png"/></p><p>Uncheck the <b>Profile Applications</b> filter and complete the dialog to see the loaded profile application models in the explorer:</p><p><img border="0" src="images/show_in_explorer.png"/></p><h1 id="Duplicating_Profile_Applications">Duplicating Profile Applications</h1><p>Using externalized profile applications, not only is it possible to apply multiple profiles externally to a package, but the same profile may be applied multiple times to the same package. This facilitates development of alternative extensions of the same model elements, such as for "what if" analysis or other comparisons.</p><p>The simplest way to create another application of the same profile is to duplicate an existing one. Simply select a profile application in the property sheet (it may be either loaded or unloaded) and press the duplicate action button:</p><p><img border="0" src="images/duplicate_button.png"/></p><p>This opens the <b>Duplicate Profile Application</b> dialog in which you select which of the profile applications in the model that you are duplicating you want to copy (you don't have to duplicate all of them) and then specify a new file name and profile-application model name:</p><p><img border="0" src="images/duplicate_dlg.png"/></p><p>The result looks something like this:</p><p><img border="0" src="images/duplicated.png"/></p><p>If the original profile application was loaded, then the new duplicate is loaded in its place (because the new profile application applies at least one of the same profiles as the original to the same package, only one can be loaded at a time). Otherwise, you can proceed by opening the new profile application and configuring its stereotype applications differently than in the original:</p><p><img border="0" src="images/variant2.png"/></p><h2 id="Restrictions">Restrictions</h2><p>There are certain restrictions in working with multiple profile applications, especially when they concern the same combinations of profiles and applying packages:</p><ul><li>a profile application model cannot be loaded if it applies a profile to a package that already has that profile applied<ul><li>this is concerned only with the actual package that the profile is applied to. A package may apply a profile that is also applied to some package containing it</li><li>this applies equally to the case where the package already owns an application of the profile and also the case where an externalized application of the profile is already loaded. However, in the latter case, there is a remedy available: the current profile application model may be unloaded. Papyrus will prompt to unload the conflicting profile application, with the option to just automatically unload it in the future, which is convenient for quickly switching between alternative configurations of stereotypes</li></ul></li><li>a profile application may not be externalized into a model that already has an application of the same profile for the same package. A different model must be selected or created</li></ul><h1 id="Opening_Profile_Application_Models">Opening Profile Application Models</h1><p>Profile application models may be opened in their own editors to provide convenient access to the perspective that they offer on the models that they extend. Ordinarily, they contain only stereotype applications extending elements in the user model, but it may be useful in some circumstances to create diagrams in a profile application model that are specific to the profile applications that it contains. It is <b>highly recommended</b> never to add UML content to a profile application model; only stereotype applications extending UML content. </p><p>The <b>New → Papyrus Model</b> wizard may be used to initialize a complete Papyrus model from the UML resource of a profile application:</p><p><img border="0" src="images/init_model_menu.png"/></p><p>Complete the wizard, creating for example a class diagram, and you can drag and drop elements from the profiled model onto the diagram to visualize them in some way specific to the profile application:</p><p><img border="0" src="images/decorator_model.png"/></p><p>Note that the Model Explorer shows the profile model, not the profile application model itself, simply by virtue of the latter being filtered out of the view by default (see above for details). In this way, various different perspectives on the same user model may be revealed in separate editors through the profile applications. Of course, the same caveats apply for making changes to the same UML content in multiple such editors as would normally apply to editing shared "library" models.</p><h1 id="Reintegrating_Profile_Applications">Reintegrating Profile Applications</h1><p>The opposite process to externalizing a profile application is reintegrating it into the model proper. There are two ways to reintegrate a loaded profile application: using the <b>Refactor → Internalize Profile Applications...</b> action in the context menu:</p><p><img border="0" src="images/internalize_menu.png"/></p><p>or by selecting one or more profile applications in the property sheet and pressing the internalize action button:</p><p><img border="0" src="images/internalize_button.png"/></p><p>The context menu action opens a dialog in which you may choose which profile applications, for the selected package, that are currently loaded should be reintegrated. Upon saving the model, then, these profile applications and the stereotype applications that they define are stored once more in the same resources as the UML elements that they extend.</p><h1 id="Preferences">Preferences</h1><p>A few preference options are available to control how Papyrus behaves in working with externalized profile applications. These are:</p><p><img border="0" src="images/preferences.png"/></p><ol><li>Whether Papyrus should automatically prompt you to select one or more profile applications to load when opening a model that has externalized profile applications available for one or more packages within the model.</li><li>When loading a profile application model, whether Papyrus should prompt to confirm that applications of the same profile(s) to the same package(s) that are already loaded should first be unloaded, or else cancel loading the new profile application. Disabling this prompt makes for quick switching of profile applications by double-clicking in the property sheet to load alternatives.</li><li>What to do when a profile application model is emptied of all profile applications by reintegration. Ordinarily, no useful data besides stereotype applications is stored in a profile application model, and these are simply moved into the main model resource by reintegration, so it is safe and practical to delete the profile application model when it is no longer needed. However, in the case that it has specialized diagrams or (though not recommended) other UML content, it may be important to retain that model.</li></ol></body></html> \ No newline at end of file