Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Papyrus/Oxygen Work Description/NewFeature/PapyrusAFViewpointSwitch

Introduction

This is a proposal for the realization of the ISO42010 standard for architecture in the context of the Papyrus tool. The proposal suggests how the standard can be used to specify UML-based domain specific architectures.

Background

The ISO42010 standard specifies the requirements for producing an Architecture Description (AD), shown in Figure 1, as a work product of systems and software architecting.

ISO42010 definition Architecture Description.png

Figure 1. ISO42010 definition Architecture Description (AD)

In a nutshell, an AD is a specification of the architecture of a system. It identifies the relevant stakeholders of the system, their addressed concerns, and the architecture viewpoints that depicts those concerns. An AD has a set of architecture views, each of which is defined by a viewpoint and consists of a set of architecture models (representations of some sort) that conform to model kinds that are defined by that viewpoint. Furthermore, the ISO42010 standard specifies that an AD conforms to a meta (higher level) description. This meta description can be an Architecture Framework (AF) or an Architecture Description Language (ADL), which are two widely used mechanisms for architecting. Each mechanism establishes common practices for creating, interpreting, analyzing and using ADs within a particular domain of application or stakeholder community. The main difference between an AF and a ADL is in how they define viewpoints and model kinds. An AF, shown in Figure 2, defines viewpoints that frame the stakeholder’s concerns by defining model kinds, while an ADL, shown in Figure 3, defines model kinds that frame the stakeholder’s concerns and can be grouped by different viewpoints.

ISO42010 definition of an Architectural Framework.png

Figure 2. ISO42010 definition of an Architectural Framework

ISO42010 definition of Architecture Description Language.png

Figure 3. ISO42010 definition of Architecture Description Language.

Proposal

The goal of the proposal is to enable Papyrus toolsmiths to define architecture domains, that consists of stakeholders, concerns, AFs, and ADLs, and to enable Papyrus users to define ADs that use them.

Architecture Domain Model

The proposal defines an Ecore-based metamodel, called Architecture.ecore, shown in Figure 4, that realizes the ISO42010 standard but also makes some changes. All types in the metamodel that make up an architecture domain are subtypes of ADElement which has a name and a description attributes. We define the type ArchitectureDomain to represent an application domain and become the root of containment in an architecture domain model (*.domain). An architecture domain can contain a set of stakeholders (of type Stakeholder), concerns (of type Concern), and contexts (of abstract type ArchitectureContext). A stakeholder references its concerns. An architecture context has an id (used as a GMF client context id), references a set of element types (of type ElementTypeSetConfiguration), and contains a set of viewpoints (of type ArchitectureViewpoint). The concrete type ArchitectureFramework specializes ArchitectureContext. Similarly, the concrete type ArchitectureDescriptionLanguage specializes ArchitectureContext and adds the ability to contain representation kinds (of type RepresentationKind). A viewpoint references a set of representation kinds. Both a viewpoint and a representation kind can reference a set of concerns. This metamodel suggests that an ADL can define representation kinds, in addition to viewpoints, while a regular AF can only define viewpoints. The set of element types that are bound to a given context (AF or ADL) through direct reference may be augmented by ones that are bound to it through org.eclipse.papyrus.infra.types.core.elementTypeSetConfiguration extensions.

The Architecture.ecore metamodel.png

Figure 4. The Architecture.ecore metamodel

Notice that the type RepresentstionKind is abstract. Concrete subtypes are defined in another Ecore-based metamodeld, called Representation.ecore, and shown in Figure 5. The metamodel is an adaptation of the Configuration.ecore metamodel that is available in Papyrus today. Type PapyrusRepresentationKind specializes the abstract type RepresentationKind. Other than that, all details of the configuration.ecore metamodel, especially the details of the specialized representation kinds (PapyrusDiagramKind, PapyrusTableKind, PapyrusSyncTableKind), are preserved in Representation.ecore for now.

The Representation.ecore metamodel.png

Figure 5. The Representation.ecore metamodel

Examples

Architecture Domain (name=Software Engineering)
	Stakeholder (name=Software Engineer, Concerns=Function, Structure, Behavior)
	Concern (name=Function)
	Concern (name=Structure)
	Concern (name=Behavior)
	Architecture Description Language (name=UML)
		Element Type Set Configuration* (identifier=*.uml.*)
		Diagram Kind (name=Use Case Diagram, Concerns=Function)
		Diagram Kind (name=Class Diagram, Concerns=Structure)
		Diagram Kind (name=Statechart Diagram, Concerns=Behavior)
		Architecture Viewpoint (name=Software Analysis, representationKinds= Use Case Diagram, Class Diagram)
		Architecture Viewpoint (name=Software Design, representationKinds= Class Diagram, Statechart Diagram)

Architecture Domain (name=Systems Engineering)
	Stakeholder (name=Systems Engineer, Concerns=Requirements, Function, Structure, Behavior, Parametrics)
	Concern (name=Requirements)
	Concern (name=Parametrics)
	Architecture Description Language (name=SysML)
		Element Type Set Configuration* (identifier=*.sysml.*)
		Table Kind (name=Requirements Table, Concerns=Functions)
		Diagram Kind (name=Requirements Diagram, Concerns=Functions)
		Diagram Kind (name=Block Definition Diagram, Concerns=Structure)
		Diagram Kind (name=Parametrics Diagram, Concerns=Structure)
		Architecture Viewpoint (name=Systems Analysis, representationKinds= Requirements Table, Requirements Diagram, Use Case Diagram, Block Definition Diagram)
		Architecture Viewpoint (name=Systems Design, representationKinds= Block Definition Diagram, Parametrics Diagram, Statechart Diagram)

Architecture Domain (name=Papyrus for Education)
	Architecture Description Language (name=Simple UML)
		Diagram Kind (name=Simple Class Diagram, Concerns=Structure)
		Diagram Kind (name=Simple Statechart Diagram, Concerns=Behavior)
		Architecture Viewpoint (name=Software Analysis, representationKinds= Use Case Diagram, Simple Class Diagram)
		Architecture Viewpoint (name=Software Design, representationKinds= Simple Class Diagram, Simple Statechart Diagram)

Architecture Domain (name=Systems Engineering)
	Stakeholder (name=Safety Analyst, Concerns=Safety)
	Concern (name=Safety)
	Architecture Description Language (name=Safety Profile))
		Element Type Set Configuration* (identifier=*.safety.*)
		Diagram Kind (name=FEMCA Diagram, Concerns=Safety)

Architecture Domain (name=Systems Engineering)
	Architecture Framework (name=DODAF))
		Element Type Set Configuration* (identifier=*.dodaf.*)
	Architecture Viewpoint (name=Requirements, representationKinds= Requirements Table, Requirements Diagram)
	Architecture Viewpoint (name=Analysis, representationKinds= Use Case Diagram, Block Definition Diagram, State Machine Diagram)
	Architecture Viewpoint (name=Design, representationKinds= Block Definition Diagram, State Machine Diagram, FEMCA Diagram)

Architecture Domain (name=Systems Engineering)
	Architecture Description Language (name=AUTOSAR))
		Element Type Set Configuration* (identifier=*.autosar.*)
		Diagram Kind (name=AUTOSAR Diagram, Concerns=Structure)
	Architecture Viewpoint (name=AUTOSAR Analysis, representationKinds= Requirements Diagram, Use Case Diagram, AUTOSAR Diagram)
	Architecture Viewpoint (name=AUTOSAR Design, representationKinds= AUTOSAR Diagram, State Machine Diagram)

Operations

  1. ArchitectureContext::GetAllRepresentationKinds()
    • For each viewpoint owned by the context
      • Collect representation kinds referenced by the viewpoint
  2. ArchitectureViewpoint::GetConcerns()
    • For each representation kind in the viewpoint
      • Collect the representation kind
      • Recursively collect the parent of each representation kind
    • For each collected representation kind
      • Collect the representation kind’s concerns
    • Union the result with the concerns of the viewpoint
  3. ArchitectureViewpoint::GetStakeholders()
    • For each concern in self.GetConcerns()
      • Collect the stakeholder that has this concern

Extension Points

There will be a new extension point (org.eclipse.papyrus.infra.architecture.domain) allowing contribution of architecture domain models. Each contribution specifies the path to a (*.domain) model.

There will be a new extension point (org.eclipse.papyrus.infra.architecture.applicator) allowing contribution of an implementation of an interface that allows applying and un-applying architecture contexts to/from models. The interface will be invoked when an architecture context is applied or unapplied to a model.

interface ArchitectureContextApplicator {
	void apply(org.eclipse.uml2.uml.Model model);
}

Each architecture context with a unique id corresponds to a GMF client context with the same id. This is why contributions to the element type set configurations for a given architecture framework can also be made by extending the extension point (org.eclipse.papyrus.infra.types.core.elementTypeSetConfiguration) with the same id.

Extensibility

An architecture domain can be defined by several models that get merged into the primary model at runtime. The semantics of the merge are as follows:

  • Architecture domains with the same name will be merged
    • Stakeholders with the same name will be merged
      • Concern references will be merged
    • Concerns with the same name will be merged
    • Architecture framework with the same name will be merged
      • Architecture viewpoint with the same name will be merged
        • Representation kind references will be merged
        • Concern references will be merged
      • Element type set configurations references will be merged
    • Architecture description language with the same name will be merged
      • Architecture viewpoint with the same name will be merged
        • Representation kind references will be merged
        • Concern references will be merged
      • Element type set configurations references will be merged
      • Representation kind references will be merged

Note: It is expected that only one of the merge increments for each element to have a value for the description attribute. In the event more than one increment has a description value, one of them will be randomly picked.

Note: It is expected that all merge increments of an architecture context to have the same value for the id attribute. In the event more than one increment has a different id, an error will be logged.

Architecture Description

The proposal addresses the definition of ADs with type ArchitectureDescription (Figure 4). An object of this type may get added to the root of the Papyrus DI model, with its contextId attribute having a value that is the qualified name of an architecture context (in the format <domain>::<context>) that is applied to the model. A model is expected to have representations (in the DI models) that are instances of the representation kinds referenced by the chosen architecture context’s viewpoints. A representation references its representation kind (e.g., the type of a Diagram) using its implementationID value (e.g., “PapyrusUMLClassDiagram”).

User Interface

Preference Page

An Architecture Contexts preference page (Figure 6) will be added to select the architecture contexts that can be applied to Papyrus models in the workspace. Those contexts are selected by default, but can be unselected. One of the domains (in bold) is set as the default. This can be changed by selecting another and pressing the Set to Default button.

Architecture Contexts Preference Page.png

Figure 6. Architecture Contexts Preference Page

By default, the contexts shown are those whose domain models are contributed via the org.eclipse.papyrus.infra.architecture.domain extension point. However, one can also add domain models from in the workspace using the Add button and choosing those models. This brings up a dialog box (Figure 7) to select/unselect the model files. Notice that those domain models may contribute new domains or merge increments to existing domains. In the latter case, the new domain and its contexts will be listed.

Add Domain Models dialog.png

Figure 7. Add Domain Models dialog

New Model Wizard Page

The New Papyrus Model Wizard will replace the Language Selection page by Architecture Framework Selection page (Figure 8) that allows choosing one architecture context (from the selected ones in the preferences) to apply to the model . Setting the focus on a context shows its description. At the end of the wizard, after the model is created, the chosen context is applied to it by adding an object of type ArchitectureDescription to the root of the DI model. Also, the wizard will invoke the apply method on all ArchitectureContextApplicator(s) registered for the framework through the org.eclipse.papyrus.infra.architecture.applicator extension point.

Switch Architecture Context Dialog

A dialog (Figure 9) will be added to allow switching the architecture context applied to a given model. If a new architecture context is selected, the apply function on any ArchitectureContextApplicator registered for it will be invoked by the dialog. The user receives a warning message box (Figure 10) If the element type set configurations of the old context is not a subset of that of the new context.


After the switch, and the invokations of applicators, the representations that remain in the model and whose kinds are supported by the new context’s viewpoints will not be affected. Those representations whose kinds are not supported by the new context will remain in the model but will be marked as stale so that the user may chose to delete them manually.


The switch dialog can be invoked by a “Switch Architecture Context…” action under a “Refactor” submenu in the context menu (Figure 11).

The Architecture Context Selection Page in the New Model Wizard.png

Figure 8. The Architecture Context Selection Page in the New Model Wizard

The Architecture Framework Switch dialog box.png

Figure 9. The Architecture Framework Switch dialog box

A warning message when the architecture context switch is not compatible.png

Figure 10. A warning message when the architecture context switch is not compatible

The context menu for Switch Architecture Context action.png

Figure 11. The context menu for Switch Architecture Context action

Select Viewpoints Dialog

When a model has a given architecture context applied, the viewpoints of this context become visible by default in the workspace. However, a user can control which viewpoints are visible on a model, out of those supported by the model’s architecture context, using the Select Viewpoints dialog box (Figure 12). The selected viewpoints are identified by qualified name and persisted either in the DI model (in the viewpoints attributes of the ArchitectureDescription object that is in the root of the DI model) or in the user’s workspace, based on a flag that is available in the model’s welcome page (Figure 13).

Impact on Model Explorer

For the visible viewpoints on a model, the model explorer (Figure 14) shows the representation kinds referenced by those viewpoints only in the New <Representation Kind> (e.g., New Diagram, New Table) menus. Also, created representations supported by the visible viewpoints are shown in the model explorer (under their context elements), while unsupported ones are hidden.

The Select Viewpoints dialog box.png

Figure 12. The Select Viewpoints dialog box

The welcome page of a Papyrus model showing the “Private visible viewpoints” flag.png

Figure 13. The welcome page of a Papyrus model showing the “Private visible viewpoints” flag


Furthermore, the model explorer shows under the root a special node called ‘Views’ (Figure 14) that expands to show a set of views named after the visible viewpoints and another special view called ‘Other’ that is dimmed. The first set shows all the representations that are supported by each respective viewpoint, while the second set shows all the representations that are not supported by any visible viewpoint.

Model Explorer showing the special Views node.png

Figure 14. Model Explorer showing the special Views node

Impact on Property Sheet

Papyrus provides a model-based definition of the properties view that can be activated depending on a specific context. This framework notably enables the contribution of properties pages for a specific viewpoint using the extension point org.eclipse.papyrus.views.properties*.

Semantic Editing

The architecture framework applied to a model affects the semantic editing of the model since it affects the element type set configurations that are active when editing the model. Since all semantic editing is contextual to a given model, the editing requests will be handled by a GMF client context (along with all its registered element type set configurations) that corresponds to the id of the architecture framework that is applied on the model.

Back to the top