Sirius的架构
下图为Sirius文档中展示的Sirius架构图。
由图可知，Sirius基于Eclipse Platform、EMF实现，总共包括了两部分功能——分别是Sirius Runtime和Sirius Tooling。
Sirius面向的用户也可以分为两种：
- Architects，暂且称为开发者
- End Users， 暂且称为终端用户
Sirius Tooling供开发者使用，提供了自定义建模工具的环境，该部分的产出核心为*.odesign文件。这个文件存储了开发者对于目标建模工具的配置数据，同样也对应了图中的Descriptoin Metamodel，暂且称为描述（元）模型。
Sirius Runtime，即Sirius的运行时，在运行过程中需要描述模型的支持，也是根据该描述模型才能够向终端用户提供目标建模工具的使用。此外，图中Sirius Runtime还包含了另一部分——Representation MetaModel，暂且称为展示（元）模型。Sirius Runtime使用展示模型存储终端用户在建模过程中所产生的数据，包括视图展示数据等。
Sirius Runtime管理这几个模型的过程如下图所示：
该过程涉及三类模型：
- Business Model，即开发者定义的建模工具的需要产出的语义模型
- Description Model，即Sirius Tooling产出的描述模型，Sirius称为Viewpoint Specification Model
- Representation Model，即Sirius Runtime运行时持有的展示模型，该模型对应的持久化文件为
*.aird文件
三个模型之间通过Sirius的刷新算法来同步。具体来说，刷新算法会根据开发者在描述模型中定义的规范，将语义模型的模型数据映射至展示模型中，接着建模工具则会根据展示模型的数据渲染出供终端用户编辑的展示视图（Representation）。
当用户在建模工具中根据开发者所提供的工具修改语义模型数据时，Sirius Runtime将会重复上述步骤，将语义模型的更新同步到展示模型中，从而将终端用户所做的修改展现在建模工具上。
Sirius的几个概念
Session
Sirius采用了EMF模型的方式存储所有数据（前文提到的描述模型、展示模型均如此，当然Sirius定义了各自对应的EMF元模型文件）。
而每一个Session对象是对Sirius同一个建模项目中的运行事务即其资源集合的包装，其中所有操作均需要通过Session提供的接口进行。Sirius由此能够确保建模项目中模型一致性。
每一个建模项目均绑定一个Session对象，不同Session之间彼此独立。同时，*.aird文件可以看做Session对象的持久化表示形式，亦即Session对象持有着展示模型数据。
Dialect
Sirius默认为开发者提供了几种不同的展示语义模型的展示方式，包括diagram、tree、table等。Sirius将不同的展示方式称为为dialect。
为了提高Sirius代码的可重用性，Sirius的代码组成主要由核心功能代码与不同dialect的扩展代码组成。如果想要为Sirius额外增加一种dialect，所需要的工作包括以下4个步骤：
- 扩展展示元模型，使其能够支持新增dialect的展示数据
- 扩展描述元模型，使其能够支持开发者根据dialect的规范自定义模型展示方式
- 增加支持该dialect的刷新算法代码
- 增加支持该dialect展示和用户交互的编辑器相关代码。其中Sirius对于diagram的编辑器支持是通过GMF代码实现的。
上述四个步骤是Sirius新增dialect所需工作，同时也反映出了Sirius的几个工作层次。
