diff options
Diffstat (limited to 'plugins/doc/org.eclipse.papyrus.infra.viewpoints.doc/resources/viewpoints.html')
| -rw-r--r-- | plugins/doc/org.eclipse.papyrus.infra.viewpoints.doc/resources/viewpoints.html | 35 |
1 files changed, 1 insertions, 34 deletions
diff --git a/plugins/doc/org.eclipse.papyrus.infra.viewpoints.doc/resources/viewpoints.html b/plugins/doc/org.eclipse.papyrus.infra.viewpoints.doc/resources/viewpoints.html index dacce45f8f6..f097c3ec210 100644 --- a/plugins/doc/org.eclipse.papyrus.infra.viewpoints.doc/resources/viewpoints.html +++ b/plugins/doc/org.eclipse.papyrus.infra.viewpoints.doc/resources/viewpoints.html @@ -1,34 +1 @@ -<?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="Viewpoints_in_Papyrus">Viewpoints in Papyrus</h1><h2 id="Introduction">Introduction</h2><p>Viewpoints in Papyrus enables the specialization of the user experiences by constraining what can be seen and interacted with in models through views. -The most obvious ways to look at and interact with a model is through diagrams; and viewpoints enables the specification of constraints upon them as well as their specialization. -Papyrus also define additional views, including textual ones.</p><h2 id="Impacts_of_Viewpoints_in_the_Papyrus_Interface">Impacts of Viewpoints in the Papyrus Interface</h2><p>The enforcement of a particular viewpoint will have noticeable consequences on the user interface of Papyrus, i.e. what a user will be able to see and do. -Viewpoints also have impacts on the edition experience of the model themselves.</p><h3 id="Contextual_Menus">Contextual Menus</h3><p>The definition a viewpoints specify which views and diagrams can be applied to specified model elements. -A consequence is that the Papyrus tool bar as well as the contextual menus are aware of the currently enforced viewpoint and only make available actions that are in conformance with the viewpoint. -For example, in the two captures hereafter the content of the same menu for the creation of a new diagram depends on the enforced viewpoint.</p><table><tr><td><img border="0" src="captures/menu_normal.png"/></td><td><img border="0" src="captures/menu_filtered.png"/></td></tr></table><h3 id="Toolbar_Elements">Toolbar Elements</h3><p>The toolbar elements for the creation of new diagrams are also adapted in the same way as the contextual menus to reflect the currently enforced viewpoint. -The elements that appeat in the contextual menus should also appear in the toolbar.</p><h3 id="Diagram_Properties">Diagram Properties</h3><p>Papyrus views and diagrams have a set of properties related to the management of viewpoints. -They are visible in the <b>Properties</b> view of the diagrams.</p><p><img border="0" src="captures/properties.png"/></p><p>In the image above the selected diagram have two properties related to the management of viewpoints:</p><ul><li><b>View Type</b>: This property shows the diagram's type as defined in the viewpoints' configuration. In the example above, it is a <i>UML Activity Diagram</i>, part of the <i>Default Papyrus Viewpoint</i> configuration.</li><li><b>Owner</b>: This property shows the current owner of the diagram, i.e. the model element which the diagram is attached to. In the example above, the diagram is within the <i>Diagrams</i> package, meaning this package owns the diagram.</li><li><b>Root element</b>: This property shows the model element that is visualized through the diagram. In the example above, the top element visualized in the selected diagram is the UML activity named <i>Activity1</i>. It is possible to retarget a diagram, i.e. change its root element. The user will be prompted to select a model element that fits the constraints that apply for this type of diagram.</li></ul><h2 id="Changing_the_Applied_Viewpoint">Changing the Applied Viewpoint</h2><p>The Papyrus viewpoints can be configured in a preference panel accessible along the other Papyrus preferences under the name <b>Viewpoints Configuration</b>. -The panel looks like the following:</p><p><img border="0" src="captures/preferences.png"/></p><h3 id="Configuration_Kinds">Configuration Kinds</h3><p>The first preference element is the selection of the kind of configuration to apply to the user's environment. -In the above capture, the radio buttons are used to determine which kind of configuration to use. -Papyrus comes with two built-in configurations. -It is nevertheless possible to define new configurations and viewpoints, and select them in this position.</p><h4 id="Built-in_Configurations">Built-in Configurations</h4><p>The built-in configurations are provided for convenience and have the following properties:</p><ul><li><i>Any number of diagrams per model element</i> is a configuration with a viewpoint that allow any kind of view and diagram and does not restrain the number of diagrams that can be created for each model element.</li><li><i>At most one diagram per model element</i> is a configuration with a viewpoint that allow any kind of view and diagram but limit the number of diagrams that can be created for each model element at one.</li></ul><h4 id="Extension_Point-Defined_Configuration">Extension Point-Defined Configuration</h4><p>It is possible to deploy custom viewpoints configuration through an Eclipse plugin and its contribution to an extension point. -The identifier of the extension point to use is <i>org.eclipse.papyrus.infra.viewpoints.policy.custom</i> and is defined in the <i>org.eclipse.papyrus.infra.viewpoints.policy</i> plugin. -Each extension can contribute a viewpoints configuration and give it a priority (0 is lowest). -The setting of the contributed configuration is achieved by giving the path to the configuration file. -The path can be relative to the contributing plugin's root, or be an absolute URI in the form of <i>platform:/plugin/<pluginID>/<path></i>. -If no contribution is made and this option is selected, the builtin configuration named <i>Any number of diagrams per model element</i> will be used as a fallback.</p><h4 id="Custom_Configuration">Custom Configuration</h4><p>To select a custom configuration, choose the <i>Custom</i> option. -This will activate the corresponding preferences fields:</p><ul><li><i>Access scheme</i> lets the user select how the custom configuration should be looked for. The possible options are:<ul><li><i>Absolute path</i> means that the configuration will be looked for on the host's file system.</li><li><i>Workspace file</i> means that the configuration file will be looked for as a resource in the workspace.</li><li><i>Embedded in a plugin</i> means that the configuration file will be looked for as a resource in a loaded Eclipse plugin.</li></ul></li></ul><ul><li><i>Path</i> lets the user select the configuration file based on the selected scheme:<ul><li>Using the scheme <i>Absolute path</i> the file is selected using a simple file selection dialog.</li><li>Using the scheme <i>Workspace file</i> the file is selected using a workspace resource selection dialog.</li><li>Using the scheme <i>Embedded in a plugin</i> the file is selected using a plugin content selection dialog.</li></ul></li></ul><h3 id="Stakeholder_and_Viewpoint_Selection">Stakeholder and Viewpoint Selection</h3><p>Once a configuration is selected, the use can select one of the viewpoint defined within it. -This is achieved through the two dropdown boxes:</p><ul><li><i>Stakeholder</i> is used to select the user's archetype</li><li><i>Viewpoint</i> is used to select the viewpoint</li></ul><h2 id="Defining_New_Viewpoints">Defining New Viewpoints</h2><p>Papyrus supports the definition of new viewpoints that can subsequently used by selecting them in the Papyrus Viewpoints preferences panel. -A configuration file is simply an Ecore model that can be edited with the provided Viewpoints configuration editor in Papyrus.</p><h3 id="Available_Concepts">Available Concepts</h3><p>This subsection summarizes the different concepts that are leveraged for the definition of viewpoints in Papyrus. -It is important to note that these concepts rely on and extend the ISO 42010 standard for viewpoints.</p><ul><li>A <i>configuration</i> is a specification of a set of <i>viewpoints</i> and <i>stakeholders</i>. A <i>configuration</i> is typically stored in a .configuration file and has to be selected in the preference window (Window/Preferences/Papyrus/Viewpoints Configuration).</li><li>The concept of <i>stakeholder</i> (see ISO 42010) in Papyrus represents a user archetype that pertains in the construction and/or review of a model. A <i>stakeholder</i> is associated to a set of <i>viewpoints</i> defining how he/she can see a model.</li><li>The concept of <i>viewpoint</i> (see ISO 42010) in Papyrus represents a set of constrains about what can be seen in a model. A Papyrus <i>viewpoint</i> mainly defines what are the accessible <i>diagrams</i> and the particular constraints to be applied on each of them.</li><li>A Papyrus <i>diagram</i> is a specialized view on a model in the form of a visual language. It is supported by an implementation artifact, i.e. the actual code that implements the diagram. Moreover, it can be constrained using <i>rules</i>.</li><li>A <i>model rule</i> specifies if a model element can be represented through a <i>diagram</i>, i.e. whether it can be selected as the root element of a <i>diagram</i>.</li><li>An <i>owning rule</i> specifies whether a model element is allowed to own a <i>diagram</i>.</li><li><i>Child rules</i> specify whether a given model element can be added to the model through a <i>diagram</i>.</li><li><i>Palette rules</i> specify the palette elements that are visible for a <i>diagram</i>.</li></ul><h3 id="Building_a_Configuration">Building a Configuration</h3><p>The first step is to create the configuration file. -Papyrus comes with a wizard for this purpose:</p><ul><li>In the contextual menu of a project, or in the Eclipse <b>File'' menu, select '''New</b>, <b>Other ...</b>.</li><li>The wizard is called <b>Viewpoints configuration</b> and is located in the <b>Papyrus</b> category.</li></ul><h4 id="Configuration_element">Configuration element</h4><p>Once the configuration file is created, it should be automatically opened with the Papyrus viewpoints configuration editor. -The top element is the <i>configuration</i>. -It has two properties:</p><ul><li><i>Default Stakeholder</i>, which should be used to select the default stakeholder for this configuration (once one has been created).</li><li><i>Metamodel</i>, which should be used to select the metamodel on which the viewpoint will apply. The property field proposes a list of the loaded metamodels identified by their URI. Usually, the UML metamodel (<a href="http://www.eclipse.org/uml2/4.0.0/UML/">http://www.eclipse.org/uml2/4.0.0/UML/</a>) should be used.</li></ul><h4 id="Stakeholders_and_Viewpoints">Stakeholders and Viewpoints</h4><p>It is then possible to add new <i>Viewpoints</i> and <i>Stakeholders</i> to the configuration by the conxtual menu <b>New Child</b> on the configuration element. -A <i>stakeholder</i> has two properties, <i>name</i>' and <i>viewpoints</i>. The <i>viewpoints</i> properties must be filled with references to the appropriate viewpoints for the <i>stakeholder</i>. -A <i>viewpoint</i> also has two properties, <i>name</i> and <i>parent</i>. The <i>parent</i> property is used to specify that a <i>viewpoint</i> inherits from another one.</p><h4 id="Diagram_element">Diagram element</h4><p>Once a viewpoint has been created, it is possible to add to it <i>diagrams</i> using the <b>New Child</b> contextual menu. -A <i>diagram</i> will define a specialized view on a model, based on the implementation in Papyrus. -For this purpose, the <i>diagram</i> elements have the following properties:</p><ul><li><i>name</i>, which specifies a descriptor for the diagram</li><li><i>parent</i>, which enables the declaration of an inheritance relationship with another diagram</li><li><i>implementation ID</i>, which is the unique identifier of the software component in papyrus that will effectively implements the diagram</li><li><i>profiles</i>, which is the set of profiles that need to be applied for this diagram. The profiles can be selected through their metamodel identified by their URI. This implies that the profiles must be loaded at this point.</li></ul><p>The list of recognized implementation IDs is as follow:</p><table border="solid 1px grey"><tr><th>Implementation ID</th><th>Description</th></tr><tr><td><b>PapyrusUMLActivityDiagram</b></td><td>UML Activity Diagram</td></tr><tr><td><b>PapyrusUMLClassDiagram</b></td><td>UML Class Diagram</td></tr><tr><td><b>PapyrusUMLCommunicationDiagram</b></td><td>UML Communication Diagram</td></tr><tr><td><b>PapyrusUMLComponentDiagram</b></td><td>UML Component Diagram</td></tr><tr><td><b>CompositeStructure</b></td><td>UML Composite Diagram</td></tr><tr><td><b>PapyrusUMLDeploymentDiagram</b></td><td>UML Deployment Diagram</td></tr><tr><td><b>PapyrusUMLProfileDiagram</b></td><td>UML Profile Diagram</td></tr><tr><td><b>PapyrusUMLSequenceDiagram</b></td><td>UML Sequence Diagram</td></tr><tr><td><b>PapyrusUMLStateMachineDiagram</b></td><td>UML State Machine Diagram</td></tr><tr><td><b>PapyrusUMLTimingDiagram</b></td><td>UML Timing Diagram</td></tr><tr><td><b>UseCase</b></td><td>UML Use Case Diagram</td></tr><tr><td><b>PapyrusUMLInteractionOverviewDiagram</b></td><td>UML Interaction Overview Diagram</td></tr><tr><td><b>BlockDefinition</b></td><td>SysML Block Definition Diagram</td></tr><tr><td><b>InternalBlock</b></td><td>SysML Internal Block Diagram</td></tr><tr><td><b>Parametric</b></td><td>SysML Parametric Diagram</td></tr><tr><td><b>RequirementDiagram</b></td><td>SysML Requirements Diagram</td></tr></table><p>Once a diagram has been created it is possible to constraint it using rules. -There are four kinds of rules:</p><ul><li><i>Model rules</i> constrain the type of the (root) model elements that can be visualized through this view.</li><li><i>Owning rules</i> constrain the type of the model elements that can own the diagram itself.</li><li><i>Child rules</i> constrain the type of the model elements that can be dropped within this diagram.</li><li><i>Palette rules</i> constrain the display of the diagram's palette elements.</li></ul><p>Each rule has a <i>permit</i> property that specify whether the rule authorizes or forbids the action it represents. -Otherwise, the properties of the rules are as follow:</p><ul><li><i>Model rules</i><ul><li><i>element</i> represents the type of the model elements to apply the rule on.</li><li><i>multiplicity</i> represents the maximum number of this kind of diagram that can be created for the referenced model element. -1 represents an unbounded number.</li><li><i>stereotypes</i> represents the set of stereotypes that must be applied in the model element for the rule to match. The stereotypes can be picked from the classifiers of the <i>profiles</i> defined in the parent diagram.</li></ul></li><li><i>Owning rules</i><ul><li><i>element</i> represents the type of the model elements to apply the rule on.</li><li><i>multiplicity</i> represents the maximum number of this kind of diagram that can be created for the referenced model element. -1 represents an unbounded number.</li><li><i>stereotypes</i> represents the set of stereotypes that must be applied in the model element for the rule to match. The stereotypes can be picked from the classifiers of the <i>profiles</i> defined in the parent diagram.</li></ul></li><li><i>Child rules</i><ul><li><i>element</i> represents the type of the model elements begin dropped.</li><li><i>stereotypes</i> represents the set of stereotypes that must be applied in the model element for the rule to match. The stereotypes can be picked from the classifiers of the <i>profiles</i> defined in the parent diagram.</li><li><i>origin</i> represents the type of the model elements that are the target of the drop. It is usually one of the type defined in the <i>model rules</i>.</li><li>Additionally, <i>child rules</i> can be completed with children called <i>path elements</i> using the <b>New Child</b> contextual menu. <i>Path elements</i> defines a path of properties that must be used from the <i>origin</i> to insert the new <i>element</i> in the model.</li></ul></li><li><i>Palette rules</i><ul><li><i>element</i> represents a pattern to match for the identifier of a palette element.</li></ul></li></ul><p>As an example, it is possible to define a diagram of the inner classes of classes as follow:</p><p><img border="0" src="captures/config_sample.png"/></p><p>In this example, the sole <i>model rule</i> defines that this kind of diagram can only be applied on <b>Class</b>. -The <i>owning rules</i> define that the diagrams can be owned only by <b>Class</b> and <b>Package</b> elements. -Then two <i>child rules</i> are used to define that it is only possible to add new <b>Classifier</b> and <b>Comment</b> elements thorugh this diagram. -The first <i>child rule</i> specifies that the <b>Classifier</b> elements should be added to the model with the <b>nestedClassifier</b> property of the root <b>Class</b> element. -In the same way, the second one specifies that the <b>Comment</b> elements should be added to the model with the <b>ownedComment</b> property of the root <b>Class</b> element.</p><h4 id="Viewpoint_Enforcement_Principles">Viewpoint Enforcement Principles</h4><p>When enforcing a viewpoint, the following principles are used when authorizing, or denying user actions:</p><ul><li>If the selected viewpoint does not enable to decide for the action at hand (no mathcing diagram), the parent viewpoints are recursively considered.</li><li>If a diagram is matched, but the defined rules do not enable to decide for the action at hand, then the parent diagrams are recursively considered.</li><li>The rules are considered in the order of their definition in the viewpoints configuration editor.</li><li>The first rule to match the condition (e.g. type of the considered model element) is used to decide upon the user action. Subsequent rules are not considered. Parent diagrams/viewpoints are also not considered.</li></ul></body></html>
\ No newline at end of file +<?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="Viewpoints_in_Papyrus">Viewpoints in Papyrus</h1><h2 id="Introduction">Introduction</h2><p>Viewpoints in Papyrus enable the specialization and customization of the user experience by constraining what can be seen and interacted with in Papyrus diagrams and tables. Viewpoints can be used for the following purposes in Papyrus:</p><ul><li>Constrain the set of diagrams and tables that are available to a particular class of users</li><li>Define new kinds of diagrams with custom names, icons, figures and palette in order to implement domain-specific views in Papyrus, based on the classical UML and SysML diagrams.</li></ul><h2 id="Configuration_Options_for_Viewpoints">Configuration Options for Viewpoints</h2><p>At any given time, there can only be one viewpoint that is currently applied to an Eclipse instance. Users are free to select any viewpoint that is provided to them. Papyrus itself comes with a default viewpoint that is automatically selected when to other viewpoint is specified.</p><p>All the viewpoints-related configuration options available to the users are provided in the <i>Papyrus > Viewpoints Configuration</i> preference page of Eclipse:</p><p><img border="0" src="captures/preferences.png"/></p><p>The first available option is the <i>Configuration selection</i>. It determines how the current viewpoint is selected. The possible options are:</p><ul><li><b>Default (Papyrus built-in configuration)</b>. This option forces the selection of the default viewpoint provided by Papyrus. This default viewpoint exposes all the UML and SysML diagrams and tables implemented in Papyrus and does not restrict their use.</li><li><b>Deployed through the extension point</b>. This option allows Papyrus to choose the viewpoint with the highest priority provided through the appropriate extension point. This option is typically chosen when 3rd party viewpoints are provided through the extension point. In this way they are automatically applied. When no custom viewpoint is provide through the extension point the default Papyrus viewpoint is applied instead.</li><li><b>Manual configuration selection</b>. This option allows the user to force the application of a specific viewpoint that is manually selected. When this option is chosen the second part of the preference page becomes available. The appropriate configuration file containing the viewpoint can be selected through 3 possible schemes:<ul><li><b>Absolute path</b>: The absolute path a file in the local file system.</li><li><b>Workspace file</b>: The selection of a file in the current Eclipse workspace</li><li><b>Embedded in a plugin</b>: The selection of a file contained within a plugin that has been loaded by the current Eclipse instance.</li></ul></li></ul><p>In the case where multiple viewpoints are available through the current configuration options as explained above the specific viewpoint to be applied can be chosen through the two drop-down lists:</p><ul><li><b>Stakeholder</b>. The class of user that is associated to a list of possible viewpoints.</li><li><b>Viewpoint</b>. The viewpoint will be applied. The list is populated based on the Stakeholder field.</li></ul><p>In addition, the checkbox <b>Multiplicity</b> can be activated so that at most one diagram or table of the each kind defined in the applied viewpoint can be created for each model element. For example, at most one class diagram per package, etc.</p><p>It is possible at any time to see the details of the diagrams and tables offered by the currently used viewpoint in the <i>Viewpoint Explorer</i> view in Eclipse. This view is available in <i>Window > Show View > Other</i>, and then selecting <i>Papyrus > Viewpoint Explorer</i>.</p><p><img border="0" src="captures/explorer.png"/></p><p>This view summarizes the currently available diagrams and tables, as well as the conditions for their availability.</p><h2 id="Viewpoints-Related_UI_Elements">Viewpoints-Related UI Elements</h2><p>The application of a viewpoint has some impacts on the following UI elements in Papyrus:</p><ul><li>The diagram selection window in the <b>New Model</b> wizard is populated with only the diagrams and tables that are available in the current viewpoint.</li><li>The <b>New Diagram</b> and <b>New Table</b> contextual menus for the model elements provides only the diagrams and tables that are available in the current viewpoint and are applicable to the currently selected model element. For example, when a UML Activity is selected, the <b>New Diagram</b> context menu will not offer to create a Package diagram, or a class diagram.</li><li>The same holds for the toolbar elements for the creation of diagrams and tables.</li><li>The diagrams properties show the following information:</li></ul><p><img border="0" src="captures/properties.png"/></p><ul><li><b>View Type</b> is the qualified name of the diagram’s type. It gives an indication of which viewpoint is providing it.</li><li>The <b>Owner</b> attribute is the model element that syntactically contains the diagram in the model explorer. It can be different from the root element.</li><li>The <b>Root</b> element attribute is the model element that is the diagram’s root semantic element.</li></ul><h2 id="Definition_of_New_Viewpoints">Definition of New Viewpoints</h2><p>Papyrus supports the definition of new viewpoints that can subsequently be used by selecting them in the Papyrus Viewpoints preference panel, as presented above. Papyrus viewpoints are defined in configuration files with the ‘.configuration’ extension. They are really just an ECore model that can be edited with the specialized viewpoint configuration editor provided by Papyrus.</p><h3 id="Basic_Concepts">Basic Concepts</h3><p>Viewpoints in Papyrus are implemented as an extension to the ISO 42010 standard for architecture description framework. Hence many concepts presented here are derived from those presented in the ISO 42010 standard. However, the standard has been extended with Papyrus-specific concepts and properties.</p><ul><li>A <i>configuration</i> is a top element of a configuration file. It contains can contains <i>viewpoints</i> specifications, <i>stakeholders</i>, as well as <i>view categories</i>.</li><li>A <i>stakeholder</i> (from ISO 42010) represents in Papyrus an archetype of users. They can be attributed <i>viewpoints</i>, thus defining what users of this kind can see.</li><li>A <i>viewpoint</i> (from ISO 42010) in Papyrus is simply set of <i>views</i>, which can be <i>diagrams</i> or <i>tables</i>.</li><li>A <i>diagram</i> in this context does not represent a single instance (for example the diagram named X in model Y), but the specification (or prototype) of future diagrams of this kind. For example the <i>UML Class Diagram</i>.</li><li>A <i>table</i> is another kind of view in Papyrus that enables the presentation of models in a tabular format.</li></ul><h3 id="Walkthrough">Walkthrough</h3><p>The definition of a new viewpoint in Papyrus starts with the creation of a new configuration file: <i>Viewpoint s configuration</i> in the Papyrus folder of the Eclipse new element creation dialog. The top element of the file should be a <i>Papyrus Configuration</i> element.</p><p><u>Step 1</u>: Select the metamodel that is applicable to this configuration. Generally, this should be UML. The metamodel is selected as the <i>metamodel</i> property of the <i>Papyrus Configuration</i> root element. The drop-down value selection is automatically filled with the currently metamodel currently loaded in Eclipse. For UML select, "<a href="http://www.eclipse.org/uml2/5.0.0/UML">http://www.eclipse.org/uml2/5.0.0/UML</a>".</p><p><u>Step 2</u>: Add the basic elements. The setting of the elements below is required for the configuration to work correctly.</p><ul><li>Right click on the <i>Papyrus Configuration</i> root element to a new <i>Stakeholder</i> child.</li><li>Give it an appropriate name</li><li>Right click on the <i>Papyrus Configuration</i> root element to a new <i>Viewpoint</i> child.</li><li>Give it an appropriate name</li><li>In the properties of the new stakeholder, add the new viewpoint to the <i>viewpoints</i> property to specify that this stakeholder will have to the specified viewpoint.</li><li>In the properties of the <i>Papyrus Configuration</i> root element, select the new stakeholder in the <i>Default Stakeholder</i> property.</li></ul><p>Notes:</p><ul><li>Stakeholder attributes other than <i>viewpoints</i> and <i>name</i> are inherited from the ISO 42010 implementation and are currently not used in Papyrus.</li><li>Viewpoint attributes other than <i>parent</i> and <i>name</i> are inherited from the ISO 42010 implementation and are currently not used in Papyrus.</li></ul><p><u>Step 3</u>: Complete the viewpoint with new diagrams and tables. Those elements can be added by right clicking on the viewpoint element, in the <i>New child</i> menu. Refer to the sections below for more information on the specification of diagrams and tables.</p><p><u>Step 4</u>: Deploy the configuration. The new configuration file can be deployed in an Eclipse plugin and registered through an extension point. The extension point to use is <code>org.eclipse.papyrus.infra.viewpoints.policy.custom</code>. It comes in two flavors that are the possible child elements for it:</p><ul><li>The <i>configuration</i> element lets you register a configuration file and give it a priority. The configuration file is selected with the <i>file</i> property. Giving an URI of the form <code>platform:/plugin/my.plugin.name/path/myconfig.configuration</code> is a good practice. The <i>priority</i> is a value between 0 and 100, 100 is the highest priority. This value will be used to select the configuration with the highest priority when the user selects the <i>Deployed through the extension point</i> option in the configuration page as explained above. In this mode, the deployed configuration replaces the default Papyrus configuration and its viewpoint. This means that unless the provided viewpoint extends the default one or replicate it, the UML and SysML diagrams and tables will not be available.</li><li>The <i>contribution</i> elements lets you specifies a configuration file as an extension of another one. The custom configuration file is selected with the <i>file</i> property. The <i>original</i> property is used to select the configuration file that is extended. To extend the default Papyrus configuration, this value must be <code>platform:/plugin/org.eclipse.papyrus.infra.viewpoints.policy/builtin/default.configuration</code>. In this mode the custom viewpoints must have the same name as the extended on in the original configuration file. In essence, the diagrams and tables defined in the new custom viewpoint will be available along the one in the original viewpoints, instead of replacing them. This mode is used by RobotML to add the RobotML diagrams to the default Papyrus viewpoint.</li></ul><h3 id="Diagram_Specification">Diagram Specification</h3><p>A diagram has the following attributes:</p><ul><li>A <i>name</i> (required) that is the user-visible name of the diagram. It will appear in the creation menus and property panel.</li><li>An <i>icon</i> (required), as an URI of the form <code>platform:/plugin/...</code>.</li><li>An <i>implementation ID</i> (required) which selects the physical (hard-coded) diagram in Papyrus that will be used as a base. The possible values for this property are summarized in the following table.</li><li>An optional <i>parent</i> that specifies a parent viewpoint-defined diagram to inherit from. Essentially, the inheriting diagram will defer to its parent’s rules (see below) when its own are not sufficient to take a decision.</li><li>An optional list of <i>profiles</i> that must be applied on the model for this diagram to be available. The possible values are automatically populated from the loaded EPackages.</li><li>An optional <i>custom style</i> as an URI of the form <code>platform:/plugin/...</code>. It must point to a CSS file that will then be automatically applied to the diagram.</li><li>An optional <i>custom palette</i> as an URI of the form <code>platform:/plugin/...</code>. It must point a palette definition in XML that will be automatically applied to the diagram.</li><li>Other attributes are inherited from the ISO 42010 implementation and are currently not used in Papyrus.</li></ul><table border="solid 1px grey"><tr><th>Implementation ID</th><th>Description</th></tr><tr><td><b>PapyrusUMLActivityDiagram</b></td><td>UML Activity Diagram</td></tr><tr><td><b>PapyrusUMLClassDiagram</b></td><td>UML Class Diagram</td></tr><tr><td><b>PapyrusUMLCommunicationDiagram</b></td><td>UML Communication Diagram</td></tr><tr><td><b>PapyrusUMLComponentDiagram</b></td><td>UML Component Diagram</td></tr><tr><td><b>CompositeStructure</b></td><td>UML Composite Diagram</td></tr><tr><td><b>PapyrusUMLDeploymentDiagram</b></td><td>UML Deployment Diagram</td></tr><tr><td><b>PapyrusUMLProfileDiagram</b></td><td>UML Profile Diagram</td></tr><tr><td><b>PapyrusUMLSequenceDiagram</b></td><td>UML Sequence Diagram</td></tr><tr><td><b>PapyrusUMLStateMachineDiagram</b></td><td>UML State Machine Diagram</td></tr><tr><td><b>PapyrusUMLTimingDiagram</b></td><td>UML Timing Diagram</td></tr><tr><td><b>UseCase</b></td><td>UML Use Case Diagram</td></tr><tr><td><b>PapyrusUMLInteractionOverviewDiagram</b></td><td>UML Interaction Overview Diagram</td></tr><tr><td><b>BlockDefinition</b></td><td>SysML Block Definition Diagram</td></tr><tr><td><b>InternalBlock</b></td><td>SysML Internal Block Diagram</td></tr><tr><td><b>Parametric</b></td><td>SysML Parametric Diagram</td></tr><tr><td><b>RequirementDiagram</b></td><td>SysML Requirements Diagram</td></tr></table><p>Once a diagram has been created it is possible to constraint it using rules. There are four kinds of rules:</p><ul><li>Model rules constrain the type of the (root) model elements that can be visualized through this view. Hence model rules control what model elements can be selected for the <i>Root element</i> property of the diagrams, as shown in the capture below.</li><li>Owning rules constrain the type of the model elements that can own the diagram itself. In practice this materializes as the type of model elements under which the diagrams can appear in the model explorer. Owning rules control what model elements can be selected for the <i>Owner</i> property of the diagrams, as shown in the capture below.</li><li>Child rules constrain the type of the model elements that can be dropped within this diagram.</li><li>Palette rules constrain the display of the diagram's palette elements.</li></ul><p><img border="0" src="captures/properties.png"/></p><p>Each rule has a <i>permit</i> property that specify whether the rule authorizes or forbids the action it represents. Otherwise, the properties of the rules are as follow:</p><ul><li><i>Model rules</i><ul><li><i>element</i> (required) represents the type of the model elements to apply the rule on.</li><li><i>multiplicity</i> (required, default is -1) represents the maximum number of this kind of diagram that can be created for the referenced model element. -1 represents an unbounded number.</li><li><i>stereotypes</i> represents the set of stereotypes that must be applied in the model element for the rule to match. The stereotypes can be picked from the classifiers of the <i>profiles</i> defined in the parent diagram.</li></ul></li><li><i>Owning rules</i><ul><li><i>element</i> (required) represents the type of the model elements to apply the rule on.</li><li><i>multiplicity</i> (required, default is -1) represents the maximum number of this kind of diagram that can be created for the referenced model element. -1 represents an unbounded number.</li><li><i>stereotypes</i> represents the set of stereotypes that must be applied in the model element for the rule to match. The stereotypes can be picked from the classifiers of the <i>profiles</i> defined in the parent diagram.</li></ul></li><li><i>Child rules</i><ul><li><i>element</i> (required) represents the type of the model elements begin dropped.</li><li><i>stereotypes</i> represents the set of stereotypes that must be applied in the model element for the rule to match. The stereotypes can be picked from the classifiers of the <i>profiles</i> defined in the parent diagram.</li><li><i>origin</i> (required) represents the type of the model elements that are the target of the drop. It is usually one of the type defined in the <i>model rules</i>.</li><li>Additionally, <i>child rules</i> can be completed with children called <i>path elements</i> using the <b>New Child</b> contextual menu. <i>Path elements</i> defines a path of properties that must be used from the <i>origin</i> to insert the new <i>element</i> in the model.</li></ul></li><li><i>Palette rules</i><ul><li><i>element</i> (required) represents a pattern to match for the identifier of a palette element.<ul><li>If the value ends with '*', it will match any palette element with the prefix specified before the '*'.</li><li>If the value is '*', it will match any palette element.</li></ul></li></ul></li></ul><p>The minimal required rules for a diagram specification to work are:</p><ul><li>A model rule that allows the diagram to be created for a model element. For example, a model rule with <i>element</i> set to UML Package, <i>multiplicity</i> to -1 and <i>permit</i> to true; meaning this diagram can be created for UML Packages and an unlimited number of diagrams can be created for each UML Package.</li><li>An owning rule that allows the diagram to be owned by a model element (appear under an element in the model explorer). For example, an owning rule with <i>element</i> set to UML Package, <i>multiplicity</i> set to -1 and <i>permit</i> to true; meaning an unlimited number of diagrams of this kind can be placed under each UML Package element in the model explorer.</li><li>A child rule that allows the dropping of any element in the diagram, expressed with the <i>permit</i> attribute set to true and other attributes left empty.</li></ul></body></html>
\ No newline at end of file |