An architecture context is a method for customizing Papyrus for a given domain. It defines a regime for editing a Papyrus model semantically and notationally. The semantic editing is defined by a set of element type set configurations (from some domain), while the notational side is defined by a set of viewpoints consisting of a set of representation kinds (e.g., diagram kinds and table kinds) and other notational configurations.
An architecture context is composed within an architecture domain (a namespace) and satisfies a set of concerns that belong to a set of stakeholders, both of which are composed in (the same or another) architecture domain. An architecture domain can be specified by one or more architecture models. In the latter case, all of these models are dynamically merged at runtime.
An architecture context can either be an architecture description language or an architecture framework. In the former case, it can own its own set of representation kinds, while in the latter, it cannot. However, in both cases, a context can own a set of viewpoints that reference representation kinds owned by any description language.
Each model in Papyrus is created using a specific architecture context, although this context may later be switched, possibly resulting in the model details being changed. A model also specifies a subset of its context's viewpoints as enabled at creation time, although this set may later be switched as well. When a viewpoint is enabled on a model, a user can create representations, based on this viewpoint's referenced representation kinds, and see them in model explorer. When a viewpoint is disabled, its representations become invisible, unless another enabled viewpoint references their representation kinds.
Papyrus is typically deployed with one or more architecture models that are registered through platform extensions. The architecture contexts contributed by these models can be seen in the Architecture Context Preference Page:
A user can choose to enable or disable those architecture contexts in the workbench by toggling their checkboxes, set one of them as a default context (using the Make Default button), or extend existing contexts or add to them at runtime by specifying other architecture models from the file system or the workspace (using the Other Architecture Models button):
The enabling of architecture contexts in a workbench has some impacts on the following UI elements in Papyrus:
The Select Architecture Context page of the New Papyrus Model wizard allows for selecting one of the enabled architecture contexts to create the model in. It also allows for enabling/disabling on the model the set of viewpoints that are provided by the context.
The Initialization Information in the New Papyrus Model wizard has a Select a Representation Kind section that is populated with only the diagrams and tables that are available in the enabled viewpoints.
The Switch Architecture Context... context menu action in the Model Explorer view allows for switching the model's architecture context and/or viewpoints. Similarly, the Switch Architecture Viewpoints context menu allows for quickly enabling/disabling a viewpoint.
When the Switch Architecture Viewpoints is disabling viewpoint(s), there are these behaviors:
On the contrary, when the Switch Architecture Viewpoints is enabling viewpoint(s):
The Unsupported Diagrams/Tables filter in the Model Explorer view hides diagrams/tables whose kinds are not supported by the viewpoints currently enabled on the model.
The New Diagram and New Table contextual menus for the model elements in the Model Explorer view provides only the diagrams and tables that are available in the enabled viewpoints and are applicable to the currently selected model element. For example, when a UML Activity is selected, the New Diagram context menu will not offer to create a Package diagram, or a class diagram. The same holds for the toolbar elements for the creation of diagrams and tables.
The diagrams properties show the following information:
Papyrus supports the definition of new architecture models that can subsequently be used by selecting them as other models in the Papyrus Architecture Context preference page, as presented above. Papyrus architecture models are defined in files with the *.architecture extension. They are really just EMF models that can be edited with the specialized architecture model editor provided by Papyrus.
The architecture metamodel in Papyrus is implemented as a realization and an extension to the ISO 42010 standard for architecture of systems. Hence many concepts present in the metamodel are derived from those presented in the ISO 42010 standard. However, the standard has been extended with Papyrus-specific concepts and properties.
Papyrus adds to the ISO 42010 standard two mechanisms that enable reuse of and additions to architecture contexts provided by other bundles. These are extension and inheritance. Extension allows an architecture context to add definitions to other contexts; these added definitions are merged as appropriate (see below) with definitions already in the receiving context and contributed to it by other extensions. Inheritance allows an architecture context to reuse definitions from another context, integrating them into itself in accordance with the same merge semantics as extension: inherited definitions are merged into the inheriting context's local definitions and also any definitions that may be added to it by extensions.
A common use case for context extension is the addition of custom viewpoints and representation kinds to some context. For example, consider a plug-in that defines a new kind of diagram or table for some peculiar visualization of elements in UML models. Papyrus provides an ''architecture description language'' covering the standard UML diagrams. An custom architecture description language can have an extension relationship to UML by adding the UML language to its extended contexts list. Its custom viewpoint with its custom representation kinds are then added to the viewpoints and representation kinds defined in the UML context.
An architecture context that extends other contexts via this mechanism is an extension context and is not instantiable in its own right in Papyrus models. Its only purpose is to contribute definitions to the contexts that it extends. In Papyrus, its definitions are merged into the contexts that it extends and then it is elided from the set of contexts available in the UI.
Another use case involves specialization of another architecture context for domain-specific semantics. For example, UML is engineered to enable refinement of the language in various ways for the description of domain-specific modeling languages (DSMLs) such as UML-RT or SysML. For these purposes, Papyrus makes it possible to define an architecture context that inherits another context. A domain-specific architecture description language can, for example, set the UML architecture description language as its general context. This defines a new language that has all of the definitions provided by its general context (here, UML) and adds further definitions of its own. Unlike the extension scenario, a specialization context that inherits some other context is a first-class context that is available in Papyrus for creation of models in that language (or framework).
In cases of extension and inheritance of contexts, definitions from one context are added to another context, albeit in different directions. This contribution of definitions from one context to another is not strictly additive: definitions that would have the same name in the same scope (thus would have equal qualified names) are merged. When Papyrus initializes its architecture definition subsystem, it loads all of the source architecture models and merges their contexts according to the semantics described below. The contexts resulting from this merge operation are what are presented in the New Model Wizard and other UI.
Architecture Contexts
Viewpoints
Representation Kinds
An architecture context may participate in both inheritance and extension relationships. In this case, the context is an extension context and as such is elided by the merge algorithm.
Conceptually, the merge algorithm proceeds in two stages: first a top-down merge of contexts in inheritance relationships and second a bottom-up merge of contexts in extension relationships. This has several consequences:
As inheritance is transitive, so is extension: a context that merges its definitions into some extended contexts will include in that merge any definitions that are merged into it by other contexts that extend it.
There are configurations of inheritance and extension that are not permitted and are flagged as errors by validation of architecture models:
The architecture contexts that result from this merge algorithm do not have any references to inherited and/or extended contexts. This reflects semantics of merge as copying definitions from merged to contexts to receiving contexts, so that these relationships are not needed in the merge result. But also, more practically, extension contexts are not included in the merge result (as they only exist to donate definitions to other contexts) and so do not exist to reference as general or extended contexts.
For advanced tools that need it, Papyrus does provide a mechanism by which contexts and other elements in the merge result can be traced to the elements in the source architecture models from which they are derived. Those source models retain the original inheritance and extension relationships.
In case the Papyrus workbench shows an unexpected configuration of architecture contexts, Eclipse tracing options are available to assist in the analysis of how the source architecture models were merged to produce that outcome. These are:
The definition of an architecture model in Papyrus starts with the selection of the Architecture Model option in the Eclipse New creation wizard under the Papyrus category and clicking Finish. At each following step, it is strongly recommended to validate the Architecture Model by selecting the 'Papyrus Developer'> 'Validate architecture' menu.
Step 0 (optional): If a profile is used to define the Architecture description language, prepare the profile plugin. The profile plugin shall have org.eclipse.papyrus.infra.architecture as dependencies. The profile shall extend org.eclipse.papyrus.infra.architecture.models with the path to the architecture model file as shown below.
Do not forget to include the profile and architecture resource directories in the Binary build.
Step 1: Specify the Name, Id and Description of the Architecture Domain (the root element).
Step 2: Right click on the domain to add one or more Concerns. In the properties view, specify the following for each concern: a Name, an Id and a Description.
Step 3: Right click on the domain to add one or more Stakeholders. In the properties view, specify the following for each stakeholder: a Name, an Id', a Description'', and one or more references to Concerns.
Step 4: Right click on the domain to add one or more Architecture Description Languages. In the properties view, specify for each language: a Name, a Description, a unique Id (e.g., org.eclipse.uml2.UML), an Extension Prefix if desired (e.g., profile), an Icon using a platform plugin URI (e.g., platform:/plugin/project/icons/xxx.png), a Metamodel as a reference to an EPackage (load the Ecore model first), one or more Profiles as references to EPackages (load the Ecore models first), one or more Element Types as references to ElementTypeSetConfigurations (load the *.elementtypesetconfiguration models first), a creation command using a fully qualified of a Java class implementing the IModelCreationCommand interface, and an optional conversion command using a fully qualified of a Java class implementing the IModelConversionCommand interface.
More precisely, as far as one or several profiles are concerned, launch Papyrus in a runtime and edit the plugin to add the related profile(s) to the description language as shown below.
Add, in the CreateMyProfileTestModelCommand.java source file, one Java Class named CreateMyProfileTestModelCommand that extends ModelCreationCommandBase as shown below.
The following code shall then be entered, provided the profile project name (here my_profile_test) and the profile's pathmap (here "pathmap://toy/my_profile_test.profile.uml") that is the one filled in the profile plugin (
org.eclipse.papyrus.uml.extensionpoints.UMLprofile extension point).
package my_profile_test;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.papyrus.infra.architecture.commands.IModelCreationCommand;
import org.eclipse.papyrus.uml.diagram.common.commands.ModelCreationCommandBase;
import org.eclipse.papyrus.uml.tools.utils.PackageUtil;
import org.eclipse.uml2.uml.Package;
import org.eclipse.uml2.uml.Profile;
import org.eclipse.uml2.uml.UMLFactory;
public class CreateMyProfileTestModelCommand extends ModelCreationCommandBase implements IModelCreationCommand {
@Override
protected EObject createRootElement() {
return UMLFactory.eINSTANCE.createModel();
}
@Override
protected void initializeModel(EObject owner) {
super.initializeModel(owner);
Profile myProfileTest = (Profile) PackageUtil.loadPackage(URI.createURI("pathmap://toy/my_profile_test.profile.uml"), owner.eResource().getResourceSet());
if (myProfileTest != null) {
PackageUtil.applyProfile((Package) owner, myProfileTest, true);
}
}
}
Last but not least, the Creation Command Class shall be entered in the Architecture Model properties as shown below.
Step 4A: Right click on the description language to add one or more representation kinds, i.e., Papyrus Diagram, Papyrus Table or Papyrus Sync Table (see details below).
Step 5: Right click on the domain to add one or more Architecture Framework. In the properties view, specify for each framework: a Name, a Description, a unique Id (e.g., org.eclipse.dodaf), an Extension Prefix if desired (e.g., profile), an Icon using a platform plugin URI (e.g., platform:/plugin/project/icons/xxx.png), and one or more Element Types as references to ElementTypeSetConfigurations (load the *.elementtypesetconfiguration models first).
Step 6: Right click on the description language (step 4) or framework (step 5) to add one or more Architecture Viewpoints. In the properties view, specify for each viewpoint: a Name, a Description, a unique Id (e.g., org.eclipse.uml.design), one ore more references to Concerns, and one or more references to Representation Kinds.
Step 7: Right click on the description language (step 4), to add one or more EMFFacetTreeViewerConfiguration. In the properties view, specify : a Description and the extended EMFFacetTreeViewerConfiguration or keep the value to null.
Step 7A: Right click on the EMFFacetTreeViewerConfiguration and create one or more CustomizatioReference. In the properties view, specify the Referenced Customization. You need to get the project providing the Customization in your workspace. To be able to reference the Customization, you need to load in from the workspace in your architecture file'' ( Right click -> Load Resource -> From Workspace)
Step 7B: Right click on the CustomizatioReference and create an application rule ( Absolute Order or Relative Order or Redefinition). Absolute Order allows to give the order of application (the smallest order is the first applied). Relative Order allows to define if your CustomizationReference must be applied Before or After another one. Redefinition allows to replace the a CustomizationReference with a new one.
Step 8: Deploy the model. The new architecture file can be deployed in an Eclipse plugin and registered through an extension point. The extension point to use is org.eclipse.papyrus.infra.architecture.models. Alternatively, the model can be deployed using the
Other Architecture Model button in the
Architecture Contexts preference page.
Note: If the Architecture Model you are developing is considered an extension of another model that is available in the target platform, and you want to reference some of its dependencies (like elementtypeconfigurations and palleteconfiguration, etc.) you first need to load the plugin that contains the model in your workspace. Then, using the Architecture Model editor, load the other Architecture Model using the Load Resource->Browse Workspace context menu action). This will import it using its "platform:/resource" URI. On the other hand, if the extended architecture model is rather deployed in the current platform, then use the Loaded Resource->Browse Registered Architectures context menu action. This will load the model using its "platform:/plugin" URI. Once the extended model is loaded in the editor, you can invoke the context menu action Resolve All to load all its related resources.
Once a Papyrus Diagram is created, in the properties view, specify for it:
platform:/plugin/....
platform:/plugin/.... It must point to a CSS file that will then be automatically applied to the diagram.
| Implementation ID | Description |
|---|---|
| PapyrusUMLActivityDiagram | UML Activity Diagram |
| PapyrusUMLClassDiagram | UML Class Diagram |
| PapyrusUMLCommunicationDiagram | UML Communication Diagram |
| PapyrusUMLComponentDiagram | UML Component Diagram |
| CompositeStructure | UML Composite Diagram |
| PapyrusUMLDeploymentDiagram | UML Deployment Diagram |
| PapyrusUMLProfileDiagram | UML Profile Diagram |
| PapyrusUMLSequenceDiagram | UML Sequence Diagram |
| PapyrusUMLStateMachineDiagram | UML State Machine Diagram |
| PapyrusUMLTimingDiagram | UML Timing Diagram |
| UseCase | UML Use Case Diagram |
| PapyrusUMLInteractionOverviewDiagram | UML Interaction Overview Diagram |
| BlockDefinition | SysML Block Definition Diagram |
| InternalBlock | SysML Internal Block Diagram |
| Parametric | SysML Parametric Diagram |
| RequirementDiagram | SysML Requirements Diagram |
Once a diagram has been created it can be constrained using rules (some of them are required, others are optional). 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:
The minimal required rules for a diagram specification to work are:
The merge is done by the class org.eclipse.papyrus.emf.facet.architecture.customizationconfiguration.comparators.CustomizationReferenceMerger. Here, the description of the process:
If an error occurred during this process, the error is logged and Papyrus will use the produced intermediate result list which is just a partial merge of the Customization to apply.