Viewpoints in Papyrus

Introduction

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.

Impacts of Viewpoints in the Papyrus Interface

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.

Contextual Menus

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.

Toolbar Elements

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.

Diagram Properties

Papyrus views and diagrams have a set of properties related to the management of viewpoints. They are visible in the Properties view of the diagrams.

In the image above the selected diagram have two properties related to the management of viewpoints:

Changing the Applied Viewpoint

The Papyrus viewpoints can be configured in a preference panel accessible along the other Papyrus preferences under the name Viewpoints Configuration. The panel looks like the following:

Configuration Kinds

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.

Built-in Configurations

The built-in configurations are provided for convenience and have the following properties:

Extension Point-Defined Configuration

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 org.eclipse.papyrus.infra.viewpoints.policy.custom and is defined in the org.eclipse.papyrus.infra.viewpoints.policy 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 platform:/plugin/<pluginID>/<path>. If no contribution is made and this option is selected, the builtin configuration named Any number of diagrams per model element will be used as a fallback.

Custom Configuration

To select a custom configuration, choose the Custom option. This will activate the corresponding preferences fields:

Stakeholder and Viewpoint Selection

Once a configuration is selected, the use can select one of the viewpoint defined within it. This is achieved through the two dropdown boxes:

Defining New Viewpoints

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.

Available Concepts

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.

Building a Configuration

The first step is to create the configuration file. Papyrus comes with a wizard for this purpose:

Configuration element

Once the configuration file is created, it should be automatically opened with the Papyrus viewpoints configuration editor. The top element is the configuration. It has two properties:

Stakeholders and Viewpoints

It is then possible to add new Viewpoints and Stakeholders to the configuration by the conxtual menu New Child on the configuration element. A stakeholder has two properties, name' and viewpoints. The viewpoints properties must be filled with references to the appropriate viewpoints for the stakeholder. A viewpoint also has two properties, name and parent. The parent property is used to specify that a viewpoint inherits from another one.

Diagram element

Once a viewpoint has been created, it is possible to add to it diagrams using the New Child contextual menu. A diagram will define a specialized view on a model, based on the implementation in Papyrus. For this purpose, the diagram elements have the following properties:

The list of recognized implementation IDs is as follow:

Implementation IDDescription
PapyrusUMLActivityDiagramUML Activity Diagram
PapyrusUMLClassDiagramUML Class Diagram
PapyrusUMLCommunicationDiagramUML Communication Diagram
PapyrusUMLComponentDiagramUML Component Diagram
CompositeStructureUML Composite Diagram
PapyrusUMLDeploymentDiagramUML Deployment Diagram
PapyrusUMLProfileDiagramUML Profile Diagram
PapyrusUMLSequenceDiagramUML Sequence Diagram
PapyrusUMLStateMachineDiagramUML State Machine Diagram
PapyrusUMLTimingDiagramUML Timing Diagram
UseCaseUML Use Case Diagram
PapyrusUMLInteractionOverviewDiagramUML Interaction Overview Diagram
BlockDefinitionSysML Block Definition Diagram
InternalBlockSysML Internal Block Diagram
ParametricSysML Parametric Diagram
RequirementDiagramSysML Requirements Diagram

Once a diagram has been created it is possible to constraint it using rules. There are four kinds of rules:

Each rule has a permit property that specify whether the rule authorizes or forbids the action it represents. Otherwise, the properties of the rules are as follow:

As an example, it is possible to define a diagram of the inner classes of classes as follow:

In this example, the sole model rule defines that this kind of diagram can only be applied on Class. The owning rules define that the diagrams can be owned only by Class and Package elements. Then two child rules are used to define that it is only possible to add new Classifier and Comment elements thorugh this diagram. The first child rule specifies that the Classifier elements should be added to the model with the nestedClassifier property of the root Class element. In the same way, the second one specifies that the Comment elements should be added to the model with the ownedComment property of the root Class element.

Viewpoint Enforcement Principles

When enforcing a viewpoint, the following principles are used when authorizing, or denying user actions: