Papyrus/Oxygen Work Description/NewFeature/DeclarativeRepresentations

Declarative Representations

The main objective of this project is to complement the Papyrus’s viewpoint architecture framework (VAF) by making the representation kinds for UML diagrams more declarative and reusable. This is important to reduce the development complexity of the UML diagram kinds and make them easier to extend for profile-based DSLs.

The enhancements proposed here assume three kinds of users of Papyrus:

1. End users: create architectural views consisting of representations (diagrams) in UML/DSL models.
2. Toolsmiths: create architectural viewpoints consisting of representation kinds (e.g., diagram kinds) for UML or DSL domains.
3. Developers: create implementations for different model-based representation kinds.

The artifacts developed by those users are defined as follows:

1. Representations: are instances of representation kinds created in UML or DSL models by end users. Each representation has a given kind that cannot be changed (although a representation kind’s definition can evolve between Papyrus versions triggering migration). A representation is visible in a project’s view (the set of project’s active representations) if its representation kind is defined by one of the active viewpoints for the project.
2. Representation Kinds: are declarative rule-based definitions of viewers and editors in viewpoint models. Each representation kind specifies mappings from semantic elements to visualizations and/or editing tools for a particular UML or DSL notation. When mappings are defined only, the representation kind represents a viewer. When editing tools are also defined, the representation kind represents an editor. Editing tools are triggered by user interactions and cause the state of the visualizations (and semantic model) to change.
3. Representation Implementations: are implementations (in code) to support unique types of representation kinds based on some framework (e.g., GMF for diagrams). Each representation implementation defines a representation kind metamodel consisting of a set of visualization patterns, layouts and/or styles. It also defines a set of mappings between those visualization patterns and elements from a semantic model. Furthermore, it defines a set of editing requests and commands that can be triggered by tools to edit the visualizations (and their underlying semantic model elements). A representation implementation is mostly customized by a representation kind model. However, it can also introduce extension points to allow programmatic customizations.

A toolsmith will be able to use a tree-based editors for a VAF model to define an architecture consisting of one or more viewpoints. Each viewpoint specifies new representation kinds or extensions of existing kinds. Such specifications get interpreted dynamically at runtime by a representation implementation that creates/edits the representations. The toolsmith may occasionally need to write extensions (in code) to support custom behavior for a representation kind. Doing so extensively might be an indication of the need for a new representation implementation.

A representation kind (e.g., diagram kind) defines mappings (controllers) from element types in the UML metamodel or DSL profiles (models), to visuals (views). The types of mappings are specific to the representation kinds and defined by the representation implementation. For example, a diagram kind can have node mappings (for diagrams, shapes, compartments, and labels), and edge mappings (for edges). A representation kind belongs to a specific architecture description language (either UML or a DSL defined with a UML profile). The mapping details will be specified with queries that read values from the model. Those values get assigned to details of the visuals. Such queries can be specified in formalism like OCL. Container mappings can specify nested mappings by cross referencing them. Mappings can also specialize other mappings (the specialization semantics to be defined). They will also have common attributes like id, label, and documentation. Predefined visualizations and styles libraries will be provided out of the box, but others can be custom defined and used. A representation kind can also support the specification of editing tools for mappings. When specified, such tools makes a representation kind specify an editor rather than a viewer. Those tools will support specific UI interactions (e.g., drag and drop, double click, palettes, menus, modeling assistants, etc.). Each tool specifies a command to execute to change the state of the model. The framework will provide a library of command types that can be instantiated and composed into a hierarchy. The parameters (e.g., semantic element, diagram element, etc.) available to those commands will be tool specific. Since most semantic editing in Papyrus has been centralized in the definition of architecture description languages (ADLs), there will be special commands that delegate to ADL for the actual change logic. Tools can also cause notational changes but such changes will be managed by the representation implementation.