Overview of the Sirius Meta-Models

Introduction

Sirius uses EMF models to store both Viewpoint Specification Models (the *.odesign files) and representation data (the *.aird files). If you need to extend the Sirius platform in Java, sooner or later you will have to deal with elements from these meta-models, so this document gives a very brief overview of which meta-models are used, where they are defined and how they are organized.

Viewpoint Specification Meta-Models

The structure of the VSMs is defined by several meta-models. The org.eclipse.sirius plug-in contains the http://www.eclipse.org/sirius/1.1.0 Ecore package and its sub-packages, which defines the general structure of a VSM:

The other dialects define their own extensions to these packages, in their own plug-ins. They follow the same structure:

Representation Meta-Models

The meta-models described above correspond to the elements which are found inside the *.odesign files. The representation files ( *.aird) are also stored as models. A representation can be thought of as a serialized version of a session. It includes references to the semantic models represented in the session, and the model for each actual representation (diagram, table or tree). These representation models are organized into groups corresponding to which viewpoint defines them, and the representation file also stores the set of currently enabled viewpoints in the session.

This means the representation file contains the representation and session data, references the semantic models, and also references the VSMs which define the representations it contains.

The meta-model for representation files is defined in the http://www.eclipse.org/sirius/1.1.0 package, from the main org.eclipse.sirius plug-in. Diagrams, sequence diagrams, tables and trees define their own meta-models to describe their representations' data:

The concrete structure of an aird file is the following: An aird resource contains a single DAnalysis. The analysis references the semantic resources in the session, via its semanticResources reference, and may reference other “sub-aird” through its referencedAnalysis reference. It also contains through ownedViews a DView for every Viewpoint which was ever enabled in the session. The sub-set of ownedViews in selectedViews corresponds to the Viewpoints currently enabled in the session. Each DView references (through viewpoint) the viewpoint definition it is an “instance” of, and contains actual representations (from that viewpoint) in ownedRepresentations.

The structure of the representations themselves depend on each dialect, which defines its own meta-model as mentioned above. However, they all use the org.eclipse.sirius.viewpoint.DSemanticDecorator interface for representation elements which stand for semantic elements. The getTarget() method of DSemanticDecorator can be used to obtain the actual semantic target element being represented. This means that both a node on a diagram (which is a DNode) and a cell in a table (a DCell), and any other representation element in Sirius, share the same API to retrieve the element in the user’s semantic model that it represents.