This document provides definitions for the technical terms and concepts used in Sirius, and in particular in the rest of this documentation.

For concepts which concern end-users, it assumes some basic knowledge of Eclipse terminology. If you are not familiar with it, please refer to the Eclipse documentation itself. For concepts targeted to specifier (and developers), it also assumes knowledge of EMF and relegated technologies (including Java for developers). Again, refer to the documentation of these frameworks or tools as needed.

A kind of representation supported by Sirius. Out of the box, Sirius supports three dialects: diagrams, tables, and trees. Sequence diagrams and cross-tables, which are special kinds of diagrams (resp. tables) can also be though of as dialects, although technically they are not.
Modeling Project
A special kind of project in your workspace which makes it easy to manipulate representation files and semantic models in a consistent way.
A particular diagram, table, or tree which you created on your semantic model. It is simply a more general term than «diagram» which is also usable for other dialects.
Representation File
A file in which Sirius stores all informations related to which representations you created, what appears on them, the positions and colors of the elements, etc. This files have a .aird extension (typically representations.aird). Representation files reference the semantic model(s) they contain representations for, but you semantic models are kept unaware (and unpolluted) of any Sirius-specific data.
A generic term for a file (in your workspace or inside a plug-in) which contains a model. The file extension (e.g. .uml) indicates what kind of semantic model it contains.
Semantic Model
The model (or models) which contains your business data. It can be stored in one of several resources (files) which can reference each other. The type of semantic model can be different for each user. It can be based on a standard (for example .uml files for UML models) or based on a Domain Specific Model (sometimes called Domain Specific Language) which was specially created for your needs.
A set of consistent representation descriptions which provide a specific point of view on some kind of semantic model. For example we could have a UML Structural viewpoint, which describes the sub-set of all the standard UML diagrams which deal only with structural aspects of UML models (as opposed to behavioral or requirements aspects). Viewpoints are defined in Viewpoint Specification Models and packaged as Eclipse plug-ins. Once you install such a plug-in, the viewpoints it defines will be available to you (with all the representations they define) on all compatible semantic models.
See Viewpoint Specification Model.
Viewpoint Specification Model
The model, stored in resources with the .odesign extension, in which an architect defines and configures viewpoints and their associated representations.
See Viewpoint Specification Project.
Viewpoint Specification Project
An Eclipse plug-in project which contains a VSM and registers it using the proper extension point so that it can be deployed correctly.