Towards Scalable Model Indexing (Konstantinos Barmpis 2016) 中文-第2章-背景（2）

2.1.2 大模型MDE

可伸缩性（scalability）问题是MDE在工业界的一个瓶颈，“加载和存储大模型是一项耗费资源和时间的活动”。

2.1.2.1 可伸缩性Scalability

模型保存（model persistence）是MDE的性能瓶颈；
模型查询和转换（model querying and transformation），主要是全局检索问题；
协同工作（collaborative work）；
大模型创建/探索/可视化（creation/exploration/visualization of large models）。

2.1.3 运行案例

一个简化的BPMN将作为示例，BPMN是一个定义商业流程的标准建模语言。
元模型的设计有如下考虑：
避免不同概念之间的名称冲突；
BPMN提供了一组高级概念（Event, Task, Flow等）用以建模；
这个元模型有一定的普适性和代表性；

这个元模型包含以下元素：
Tasks：每个task都是一个必须执行的时间可计的任务，而task之间跳转不耗时；
StartEvents：进程的起点，例如启动进程的管理员或未注册的账户；
EndEvents：进程的终止点，包括正常终止和异常终止；
SequenceFlows：任何两个状态的连接，有一个属性用来表示是否能传输数据，还可以附加条件属性；
Gateways：网关将SequenceFlow分隔开；
ParallelGateways：将过程分解为所有可能的结果而不管状态如何，如果它的diverging是False，则它应该将多个并行流收束到一个流中。
图2.7给出了一个“贷款申请”的例子，图2.8是它的BPMN model。

2.2 模型保存与版本控制 Model Persistence and Versioning

回顾已有的经典工具与技术，包括基于XMI的或自定义的。

2.2.1 模型保存格式 Model Persistence Formats

一些广泛使用的建模框架（例如 EMF）以 XML 格式序列化它们的模型，通常使用 XMI 标准，这也是对比其他标准的基线。

2.2.1.1 XML 元数据交换 (XMI)

XMI是基于XML的文档的扩展，其中的每个元素都映射到一个XML元素并具有唯一的标识符。因为全局加载的原因，加载基于XMI的模型需要使用SAX解析器读取，并将其转换为内存中符合元模型的对象。综上，XMI对大模型可伸缩性很差。
由于XML是一种基于文本的文件件个事，非常适合经典的基于文件的VCS，许多这样的系统每次更新只需要存储文件中更改的部分。

尝试改进处理大模型存储的方法是创建高性能的分类器，此类技术使用各种后端存储机制实现：

2.2.1.2 关系型数据库存储——Teneo/Hibernate

Teneo-Hibernate是将EMF存储在关系型数据库中，支持MySQL和HSQLDB。

如图2.10，开发人员能使用Hibernat查询可交互的API，而Ecore被隐藏。这个过程通过Java Persistence API自动化实现，并且可以自定义。

模型关系映射如图2.11的例子。这样列表在大模型情况下数据会很稀疏，增加检索的开销。关系型数据库以二进制文件保存，不利于版本控制。

2.2.1.3 基于文档的存储 Document-based Persistence – Morsa

Morsa是一种用NoSQL数据库将EMF存储为文档集合的存储方法。
NoSQL基于文档存储。图2.12是一个文档数据库，每个文档都有一个标准格式，类似的例子有MongoDB、CouchDB和OrientDB。

Model-MongoDB Mapping。如图2.13，Morsa为每一个文档存储一个模型元素，它们的属性以键值对的形式存储。索引文档存储了每个模型或元模型的URI。

Morsa使用按需加载机制，缓存满了就替换一些对象。这个方法也存在二进制文件对比的问题。

2.2.1.4 基于文档的存储Document-based Persistence – MongoEMF

MongoEMF允许EMF存储在MongoDB中，可以调用EMF的API，通过将模型存储在NoSQL中，实现可伸缩性。它通过使用自定义的URI识别扩展EMF接口，即“mongodb://host[:port]/database/collection/{id}”。可以本地MongoDB查询，也可以用MongoEMF专用格式查询
Model-MongoDB Mapping。Mon个OEMF提供了两种使用MOngoDB对象集合的选项，即可以存储在父类中也可以作为集合的顶级文档，前者修改父类则子类也会变，而对于后者客户端则无法修改。【原文56页有两段没看懂，暂跳过】。下文列举了可以加载MongoEMF资源的选项：
OPTION_PROXY_ATTRIBUTES（选择代理属性）：如果true，则允许跨文档代理引用以自动填充属性；
OPTION_QUERY_CURSOR（选项查询游标）：如果true，则允许查询返回MongoCursor而不是默认的结果；
OPTION_SERIALIZE_DEFAULT_ATTRIBUTE_VALUES（选择序列化默认属性值）：如果true，则允许保留属性的默认值（默认不存储），这用在按照属性查询；
OPTION_SERIALIZE_DEFAULT_ATTRIBUTE_VALUES（选项使用 ID 属性作为主键）：如果true，则允许自动使用ID属性作为对象的MongoDB ID，这样做是对在URI中没有ID和有ID属性的对象的集成方法。
如图2.14，在 BPMN 贷款示例中，当对其资源调用“save”方法时，贷款模型将被插入到 MongoDB 存储中，并且如果存储中不存在该资源使用的任何相关元模型，则它们将被插入（因为这些元模型已经由 EMF 加载以便加载资源）。虽然最终存储的确切结构尚未公布，但它与图 2.14 中所示的结构类似。

2.2.1.5 基于图的存储Graph-based Persistence – NeoEMF (Graph)

NeoEMF14（以前称为 Neo4EMF 和 Kyanos）包含两个由 Inria 开发的工具，它使用图形数据库作为后端。
NoSQL Graph-based stores。图数据库（如图 2.15 所示）由一组通过边连接在一起的图节点组成（因此提供节点的无索引邻接）。每个节点都包含数据字段，查询存储通常使用高效的图形遍历算法来实现性能。因此，这些数据库针对高度互连的数据的遍历进行了优化。此类存储的示例有Neo4J、InfiniteGraph和OrientDB的图形层。

NeoEMF/Graph 提供“一种后端不可知的持久化解决方案，适用于大型、复杂和高度互连的 EMF 模型”。它使用 Blueprints API连接到各种 NoSQL 图形数据库，从而利用延迟加载和数据库缓存。然而与原始数据库的API相比，也会出现性能损失。NeoEMF 还允许根据装饰器模式中定义的特定策略添加自定义缓存，还提供“脏保存”机制来处理将大事务安全拆分为小事务（同时保留恢复到一致状态的能力）。
Model-Neo4J Mapping。它具有下列特点：
模型元素存储为 Neo4J 节点，其中一个特殊节点表示引用模型中所有其他元素的“根”元素；
元素属性作为节点属性存储在相应的模型元素节点中；
元模型元素存储为节点。这样的节点只包含两个属性，一个是它们的名称，一个是它们的元模型的唯一标识符（nsURI）；
一致性关系存储为传出 Neo4J 关系，类型为 INSTANCE_OF，指向表示模型元素的相关元模型类型的节点；
模型元素之间的引用存储为元素之间的关系，使用特定的命名约定来避免与其他关系（例如上述的一致性关系）可能发生的冲突。
如图2.16的例子：

在 BPMN Loan 示例中，当在其资源上调用“save”方法时，Loan 模型将被插入到 Neo4J 存储中，并且如果存储中不存在该资源使用的任何相关元模型，则它们将被插入（因为这些元模型已经由 EMF 加载以便加载资源）。生成的数据库如图 2.17 所示。

NoSQL Key-value Stores。键值存储（如图 2.18 所示）由键及其相应的值组成，这允许以无模式的方式存储数据。这些存储声称这允许在传统存储所需时间的一小部分内搜索数百万个值。受亚马逊 Dynamo等数据库的启发，它们专为处理数兆字节的分布式键值数据而量身定制。

Model-MapDB Mapping。首先，为每个模型元素分配一个唯一标识符，以便随后将整个模型分解为键值对集合。 NeoEMF/Map 使用三个映射来存储此信息：
Property map：
$$<(id,name),v>$$
其中键由包含模型元素的唯一标识符和特征名称的对组成，值由包含特征值的文字（用于引用的另一个元素的标识符或属性的原始值）用于单值或多值特征的此类文字数组。
Type map：
$$<id,(nsURI,name)>$$
这是一个包含有关元模型类型信息的映射。其中键是存储中模型元素的唯一标识符，值由命名元组组成，其中包含有关其类型的各种元信息，例如它们的名称和它们所在包的 nsURI。
Containment map：
$$<id,(contid,name)>$$
这是一张包含有关包含措施信息的map。其中键是存储中模型元素的唯一标识符，值由命名元组组成，其中包含容器对象的唯一标识符和将容器对象与子对象相关联的特征（引用）的名称。
图2.19展示了这三种形式：

在 BPMN Loan 示例中，当在其资源上调用“save”方法时，Loan 模型将被插入到 MapDB 存储中，并且如果存储中不存在该资源使用的任何相关元模型，则它们将被插入（因为这些元模型已经由 EMF 加载以便加载资源）。生成的数据库如图 2.20 所示。

2.2.2 模型版本控制Model Versioning

模型需要以系统和规范的方式进行版本控制。本节介绍两种流行的 MDE 版本控制方法：使用基于文件的版本控制工具，以及使用特定于模型的版本控制工具。

2.2.2.1 基于文件的版本控制 File-based Versioning

版本控制（Version Control/Revision Control）是对一组文件所做更改的管理。这些文件本质上可以是文本文件或二进制文件，并组织为一组有序（通常编号）的修订版。这样的系统对文件进行逐行比较以发现版本之间的差异（deltas）；因此，基于文本的文件非常适合 VCS 理解小的变化并相应地传播（只存储小的增量）；另一方面，二进制文件很可能会在整个结构中发生变化，即使是很小的变化，因此每次都必须进行全面比较和存储，如果可能的话，应该避免这种耗时耗资源的操作（人们普遍认为不鼓励将二进制文件存储在基于文件的 VCS 中）。提供此服务的应用程序可以是独立的（例如 Subversion），也可以嵌入到程序中，例如文字处理器（例如 Microsoft Word）和 wiki 软件包（例如 TWiki）。
中心式系统Centralized Systems。集中式版本控制系统使用包含所有文件版本的单个服务器，客户端连接到该服务器并检索或更新修订。更新策略：悲观锁、乐观锁。
分布式系统Distributed Systems。用户拥有整个存储库（文件和历史记录）的本地副本。这最显着地允许文件的离线版本控制（更新、检查点等）。更新策略：开放系统、复制系统。
基于文件的模型版本控制。系统在文件级别上运行，而无法在合适的抽象层级上运行，这限制了模型层级的修改。
模型碎片化Model Fragmentation。为了避免对大型整体模型文件进行版本控制，模型在物理上被分成几个较小的互连片段，以避免通过网络传输大型文件。与以模型为中心的存储相比，它的缺点是：每个开发者的可见性仅限于本地空间的片段，开发者无法远程全局查询，而全局加载又会增加开销。当提供单个整体模型文件时，需要一种将其有意义地拆分成片段的方法。 EMFFragments等工具可用于自动执行此任务。
在 BPMN 贷款示例中，包含贷款模型和元模型的文件（无论它们是独立 XMI 文件的形式还是数据库结构）将在版本控制系统 (VCS) 中进行版本控制。每次需要访问模型时，VCS 中的 HEAD 修订版将被使用的相关建模工具检索和加载。

2.2.2.2 基于模型的版本控制

无论模型本身是在基于文件的经典 VCS 中还是在使用专有存储技术的自定义服务器上进行版本控制，这种方法都允许在模型级别进行协作和解决冲突，而不是将其完全委托给客户端。
ModelCVS。异构建模工具。 EMF 和 SVN 验证了这种概念。模型（和元模型）存储在一个存储库中，该存储库允许不同的工具（使用不同的建模语言）检查模型的版本，编辑它并提交。它旨在处理模型元素级别的冲突，而不是版本控制软件通常处理的通常文件级别（称为语义版本控制）。
语义版本控制。每次进行新提交时，如果存储库中的最后修订是传入工作副本的直接祖先，则可以直接接受提交，因为提交与模型的先前版本之间没有更改。在所有其他情况下，通过使用累积计算的更改摘要文件执行语义比较，并且通过将当前提交模型与其在工作副本中的祖先进行比较而创建的计算更改摘要文件。当所有冲突都解决后（自动或由提交者手动），该工具现在允许提交版本。由于该工具似乎没有将可扩展性作为主要关注点，因此处理大型模型是通过每种语言的持久性默认机制（例如用于 EMF 模型的 XMI）完成的，因此随后会遇到与 2.2 .1中描述的问题相同的问题。尽管如此，该项目的体系结构可能适合深入了解集成用于该研究项目的版本控制系统，因为它确实使用了可靠的版本控制系统并将其与模型存储库集成。
在 BPMN 贷款示例中，包含贷款模型和元模型的文件将在 SVN 存储库中进行版本控制。每次需要访问模型时，HEAD 修订将被使用的相关建模工具检索和加载。
连接的数据对象存储库The Connected Data Objects Repository (CDO)。另一种方法是将模型存储在专用的远程模型存储库中。 CDO 允许用户访问存储在各种可能的后端存储中的模型，它可以使用这些模型来保存其存储库。它的 API 是 EMF 的扩展，并允许无缝使用远程存储来访问和操作模型。 CDO 支持多种不同的后端，例如关系数据库（例如，它可以使用第 2.2.1.2 节中描述的 teneo-hibernate 将模型存储到 MySQL 中）和非关系存储，例如 MongoDB NoSQL 存储。
Object-Relational Mapping。==【这段是CDO和EMF的映射介绍，暂略】==从客户端来看，常规 EMF API 可以在建立连接（会话）后直接使用，但要使用高级 CDO 特定功能（例如允许直接查询 CDO 存储的 CDOView，或允许查询的 CDOTransaction保存点和回滚），必须包括对 CDO 的额外依赖。

此外，还提供了一个内置的 CDO 用户界面 (UI)，用于访问、操作和查询存储在存储库中的模型。该客户端架构如图 2.21 所示。在服务器端，此存储库允许轻松插入任何形式的存储，并且与所选后端一样可扩展，但仍有一些限制，例如与版本控制有关的限制。
协同开发Collaborative Development。由于 CDO 是模型的远程（在线）存储，因此它支持多用户访问和更新模型。用户可以使用 CDOSession(s)。这些可以自动或手动刷新，并允许与模型的最新版本保持一致。可以明确锁定元素以进行更新，也可以将流程自动化并委托给 CDO 框架。在客户端检测到冲突时（例如，使用被动更新或刷新后），提交能力失败，但 CDOConflictResolver 接口允许用户手动解决特定冲突的能力。在服务器端，如果发现冲突，整个事务将被拒绝（这主要是为了处理网络竞争情况）。
版本控制Version control。CDO 使用审计视图来处理访问历史数据的能力。此功能允许应用程序在过去的特定时间拥有模型存储库状态的只读视图。因此，CDO 没有办法允许存储并行版本（分支），如果需要的话，也没有有效的方法来处理主要冲突（例如，在模型的离线副本试图与存储库中发生了很大变化的模型）。尽管版本控制是特定于模型的并且可以检测模型级别的冲突，但它受到以下事实的限制：过去的版本不能作为最新版本检出。
CDO 的示例后端存储：后端存储的一个示例是 Teneo/Hibernate 后端。如图 2.2222 所示，这允许 CDO 无缝地利用该技术来执行模型存储、更新和查询。在 BPMN 贷款示例中，CDO 后端将包含贷款模型和元模型。有关更多详细信息，请参阅第 2.2.1.2 节中的 Teneo/Hibernate 示例，因为 CDO 环绕此技术。

EMFStore。这是一种使用基于 MongoEMF 的后端（在第 2.2.1.4 节中描述）为版本化模型创建模型存储库的工具。它提供模型元素级别的版本控制，因此多个开发人员可以在模型元素级别处理和解决 EMF 模型上的冲突。
版本控制。EMFStore 提供的版本控制系统允许模型元素级别的版本历史和版本差异、分支和标记。因此，服务器中的任何版本都可以按需检索并在历史浏览器中可视化。 EMFStore 使用基于更改的版本控制策略，其中历史信息被保存为从初始版本到当前版本所做的更改的集合；变化类型见图 2.23。如果提交有合并冲突，合并编辑器允许一次手动解决它们。

最后，一个可扩展的用户界面作为 Eclipse 视图的集合提供…
在 BPMN 贷款示例中，MongoEMF MongoDB 后端将包含贷款模型和元模型。读者可以参考第 2.2.1.4 节中的 MongoEMF 示例了解更多详细信息。
Commercial Tools。各种商业工具为各种建模技术提供模型存储库：
Modelio——UML 建模环境 Modelio 是一个用于开发 UML 模型的开源建模平台。已经为这个工具开发了各种模块，一些是免费的，一些是商业的。其中一个商业模块称为 Modelio Teamwork Manager Module（这是（商业许可）Modeliosoft Modelio 发行版第 3 版的一部分）。该模块通过将基于 SVN 的模型级版本控制和比较工具集成到 Modelio 中来实现 Modelio 模型的协作开发。它提供了用于提交和更新的常用 SVN 选项，同时还提供了两个版本之间的模型元素级别差异（并在需要时合并它们）。此外，它使用 SVN 锁定/解锁功能对原子单元进行模型感知锁定，这些单元是：UML 图的实例，例如活动图或类图；UML 类型的实例，例如类、接口或构造型。图表或类型的每个实例都存储在 SVN 的 Modelio 项目结构中其自己单独的 .exml 文件中。因此，开发人员可以选择锁定任意数量的模型元素或图表，以确保只有他们才能对它们进行更改，直到锁定被释放。
基于SVN的存储库中的Modelio项目结构如下：
包含 Modelio 项目的顶级文件夹，以项目命名（下面提到的所有其他元素都在此文件夹中）；
包含各种元数据项的“admin”文件夹，例如本项目中使用的 Modelio 元模型版本；
“模型”文件夹包含：一组文件夹，一个用于当前使用的 UML 版本中定义的每个 UML 类型和 UML 图，每个文件夹包含： 一组文件，一个用于项目中相关类/图的每个实例。例如，在名为“Actor”的文件夹中将有一组文件，一个对应于项目中找到的每个 Actor 实例；没有实例的文件夹将存在但为空。
此结构如图 2.24 所示，无论 Modelio 项目是存储在本地还是在存储库中进行版本控制都是相同的。
此外，它还提供了一个详细的信息窗口，描述了存储库的当前状态：
锁定的元素（由当前用户）、锁定元素（由其他用户）、修改的元素（由当前用户 - 相对于当前存储库版本）、未版本化的元素、添加的元素（已添加到版本但尚未在存储库中提交的元素）、过时元素（已被其他用户修改的元素 - 尚未在本地更新）。
这种架构提供了模型元素级锁定以及图表级锁定操作的优点，但是当使用包含数百万个片段（即数百万个模型元素）的大型模型时，性能和资源使用会受到影响，因为它们都必须被加载到内存中。

在 BPMN Loan 示例中，BPMN 元模型将在工具内部存储，模型将作为 .exml 文件的集合存储在它们各自的文件夹中，如上所述，模型中包含的每个模型元素和图表都有一个。

MagicDraw——UML modeling tool。MagicDraw 是一种提供协作模块的商业 UML 工具。此功能允许通过提供的 Teamwork Server 版本控制系统进行模型级版本控制和协作。 Teamwork Server 提供了三种可用的版本控制系统替代方案：Native、SVN 和 ClearCase。
使用本机版本控制系统的存储库使用专有格式来存储版本化模型以及用户凭据和访问权限。另一方面，使用 SVN 或 ClearCase VCS 的存储库仅存储用户登录名，并且在用户登录系统时直接使用所使用的相应 VCS 执行实际身份验证。
【未完待续……后面有点乱了，需要再梳理一下】

原文链接：https://etheses.whiterose.ac.uk/14376/7/Konstantinos%20Barmpis%20-%20EngD%20Thesis.pdf
官网链接：https://www.eclipse.org/hawk/