模型融合
以下整理来自于文献：Merging and Consistency Checking of Distributed Models
模型融合的定义和标准
模型融合的目标是对一组模型重复的部分统一，即如果在源模型中有一个概念多次出现，则仅保留一个复本。这个属性被称作非冗余（non-redundancy）。重复可能包括：
- 名称等价(name equivalence)：如果模型具有共同的词汇
- 标识符等价(identifier equivalence)：如果模型具有共同的祖先
非冗余是模型融合最基本的功能，除此之外，模型融合还应该满足如下正确性标准（correctness criteria）:
- 完整性(Completeness):融合不能丢失信息，也就是说它能表示所有源模型的完整性。
- 最小化(Minimality):融合不能引入源模型中没有出现的或者隐含的信息。
- 语义保持(Semantic Preservation):模型支持语义属性的表达和保持。例如，如果模型是状态机，人们可能希望保留它们的时间行为以确保融合能恰当地捕获源模型的预期含义。
- 整体性(Totality)：对于任何一组模型而言，融合都应该是明确的，无论它们是否一致。 如果要容忍源模型之间的不一致性，此属性特别重要。
针对具体融合目标，上述标准是可选择的。
融合策略
源模型的数量可以是两个或者多个。被分为两类
- 二分策略（Binary strategies）:一次融合两个模型。如果融合多个模型，则先融合两个模型，得到的融合结果再与另外一个源模型融合。
- n-ary策略：一次融合n个模型（n>2）。
二分策略的性质：
幂等率（Idempotence）
$$Merge(M_1,M_1)=M_1$$: 两个同样的模型融合后仍然得到该模型
交换率(Commutativity)
$$Merge(M_1,M_2)=Merge(M_2,M_1)$$
结合结合性(Assoicativity)
merge(merge(m1,m2,r1,2),m3,r(1,2),3)=merge(m1,merge(m2,m3,r23),r1,(2,3)))
关于融合质量
一些定性分析，包括：
可理解力(understandability)：融合结果应该对分析者和最终用户容易理解。
支持追踪（support for traceability）:融合元素能够追踪到信息源，这对于支持团队之间的合作工作并确保所有利益相关者的贡献得到适当考虑是必要的。
支持探索替代方案(support for exploration of alternatives)：当模型由分布式团队开发时，人们无法确定不同模型应该如何相互关联。 合并框架应该能够描述用于关联一组模型的不同备选方案，并根据这些备选方案配置不同的合并。
模型融合案例
实体-关系模型融合（Merging Entity-Relationship Models）
参考文献：M. Sabetzadeh and S. Easterbrook. “An A：lgebraic Framework for Merging Incomplete and Inconsistent
Views”. In 13th IEEE International Requirements Engineering Conference, September 2005.
举例：A manifesto for model merging
场景：需求抽取实验，联合从不同人群中的需求模型。假设Rob和Sue从工资数据库采集需求。
输入：描述一个融合merge:model and embeddings
model: is simply a graphical representation of a set of related concepts.
embedding: expresses an admissible way to incorporate a model into another.表达了将模型并入另一个模型的可接受方式。
embedding preserve the graphical structure of models and are described by graph homomorphisms.(同构)
融合过程的输入是一个模型的集合和它们之间关系的集合。
融合过程：结构融合算法是基于分类理论(category-theoretic)的概念称为colimit.
第一步：Rob和Sue描述他们初步观察，对应于两个独立的模型。
第二步：分析人员Jack识别这两个模型之间的对应关系 (identification of correspondences between their models)
为了描述这些对应关系correspondences，jack创建了connector：包含两个模型中的共同部分。接下来，他将根据connector，并选择合适的名称为每个模型提供embedding，如C1-To-Rob和C2-To-Sue.
所有的对应关系在执行融合操作之前明确。connector表达了两个模型的交叉部分。
这个识别connector的过程（match operator）并不是自动化的，而是人工的
更多参考的论文：Merging Individual Conceptual Models of Requirements
状态机模型
输入：一组状态机模型（由状态state和转换transitions between states）,和一组变体（variables：从状态 到状态，可取三个值t,!（unknown）,f）
融合过程：
1：变量统一，统一状态机模型的状态变量集合。如有一个状态机与另一个状态机相比，缺少了某个状态变量，则将它加入进去，并标记为！
2：对齐：（确定关系）计算共同部分common refinement.根据状态之间的关系（relationships）:是一种二元关系集合（对齐点的组合），通过匹配(match)确定关系
3：检查属性(check-property)。状态机包含行为语义，融合过程保持行为语义。例如："whenever focus is achieved, we can take a picture"能被CTL形式化AG(Focusing->EXshutter_open).这个属性在两个模型中保持，因而在融合结果中仍然保持。
模型融合的应用
可追踪性(traceability)
Traceabi lity in viewpoint merging: A model management perspective.
一致性(consistence)
互补(complementarity)和冲突(contradiction)模型融合过程中根据语义来确定互补或冲突
完整与一致融合需求视角
viewpoint-based,view-based approach
参考文献来自merging requirements views with incompleteness and inconsistency
It is a viewpoint-based approach which separates the descriptions provided by different stakeholders, and concentrates on identifying and resolving conflicts between them.
融合方法分类：
基于代数逻辑(algebraic)。
基于学习的
基于形式化描述的(formal language)
文献：business process customization using process merging techniques(2015)
研究问题：新的业务流可以通过组合两个已经存在的过程流创建。文中提出使用形式化语言表达过程的行为属性来表示过程流的语义。
过程流可以是专家设计或从用户反馈中提炼或者从已有的数据中抽取。
方法：
- encode both processes (encode the behaviors of the processes in a temporal logic like formalism and perform the merging at the language level and go then back by generating a new process from the formal description which is a consistent merge of the initial processes)
- optional pre-processing (cure possible contradictions between the two process basing on some predefined strategy)
- merge the two sets (automatically)
- reconstruct the result process
关键问题：
过程表示:a process P是一个三元组<A,G,T>
A是活动集合
G是关系集合or,and
S是步骤集合，$$S=A \cup G$$
$$T=T_a \cup T_g$$ 表示每个活动的下一步
$$T_a$$是一个转换集合，对应于每个节点的下一步
$$T_g$$是一组转换集合，对就于每个关系（or,and）的下一步非空结点。
融合步骤：
- 使用TPL表示两个模型
- 合并集合得到它们的联合
- 基于联合构建融合结果
基于图的融合方法(graph based)
文献：merging event-driven process chains(2010)
研究意图：在不同行业之间存在一定的协同（如航空公司和银行），为了协同联合(cooperations join),减少协作(synergy effect)代价。这样，合并后的公司通过融合公司间的业务流减少部门之间或操作中的重复。
问题表示：
event-driven process chains (EPCs) 表示为一个图：
三种节点类型(three node types)：namely events, functions and logical connectors.这些节点通过有向边相连。
logical connectors: 定义了控制流行为
融合算法：
工业界需求模型融合
参考文献：Requirements for practical model merge - An Industrial perspective(2009)
工业界模型驱动开发不仅应用在大型和复杂的模型，更重要的还是有许多人参与同一个模型。成熟模型工具为开发者在以模型为中心的任务中提供辅助。工具大多包括模型编辑(model editor)、和模型编译(model compiler)，它可以创建和管理一个模型，也可以编译模型成一个可运行的代码。但无法扩展到工业级规模的用户参与。
从2007年初进行的非正式工具评估中可以看出，即使对于非常简单的示例，合并结果通常可能违反直觉或完全错误 - 在某些情况下，生成的合并结果甚至不会在模型编辑器中加载。
决定更仔细地调查三个目标模型合并的成熟度。 首先，找到可以由开发人员和项目立即实施的解决方案。 其次，发现可以集成在供应商提供的工具中的研究成果。 第三，区分和定义需要研究的问题，为模型合并提供更成熟的支持。
问题的提出：我们经常在大型项目中工作，最多有100人在同一个模型上工作。 在一些项目中，人们甚至分布在多个站点上，如果没有适当的工具支持，协作会变得更加困难。
质量检查的需要
背景条件：团队中的所有人都将使用相同的工具和流程
应用模型融合的场景：
2 查看版本历史：比较两个版本模型的差异
3 不需要融合的模型更新：两个模型是完全不同的，不需要merge,只需要把它们累积到一起
4 模型自动融合更新：工具可以自动发现变化并产生一个融合结果
5 具有冲突的模型更新：不能自动融合，产生冲突报告
6 模型融合结果的检查与验证：检查与验证准备性
讨论：
1。模型融合语义(semantics of model merge)
文本融合的语义非常简单，如果一行文本发生了变化，则语义变了，如果同一行文本，多于两个可选变化，则是冲突的。
模型的语义并不像文本那样简单。确实有可能利用模型的底层文本表示并使用文本合并工具。但是，即使模型布局的微小变化也会对事物的存储顺序产生重大影响，这将导致文本合并工具无法克服的问题。
使用模型语言隐含的结构语义将有不同的版本单元“类型”，而不仅仅是文本合并中的一种（文本行）。这些工作，最早见于代数属性（algebraic properties）和比较合并操作(union operators)。
工具在融合中将相同的两类合并，将不同的类保持。此过程中，工具提供商非常明确地表达这些语义是非常重要的，并且用户需要反复阅读手册，以达成共同的标准语义为止。
2。责任分工（division of responsibility）
融合工具仅是协同组件的一部分。在并行工作环境中，我们需要根据工作任务使用具体的工具，而不仅仅物理上合并两个制品。对于并行工作，主要有两项任务：并发检测（concurrency detection）和冲突检测及解决(conflict detection)。
并发检测是版本控制工具具备的功能冲突
冲突检测是发现融合中发现不成功的融合，冲突解决是成功融合。冲突检测与解决是融合工具应具备的功能
3。表示问题（presentational issues）
表示问题对于文本融合与模型融合同样重要。我们必须以能够理解冲突（或变化）性质的方式向用户展示合并（和差异），特别是冲突，并且忽略相关细节。我们还需要考虑模型本身应该如何表现合并冲突。
目前的模型融合工具工作在交互模式下，一旦发现冲突，要求用户手动去解除冲突。如果冲突被有效表达，这样具有冲突标记的模型就成为编辑的有效模型，被理解和处理。
模型融合的工具
参考文献：Model Merging Falls short of software engineering needs
工具IBM RSA的模型合并案例。比较模型之间的不同，并维护这些不同，当有冲突发生，由merger选择哪个contribution
工具Sparx Enterprise Architect（EA）model driven UML tools,EA是一个UML分析和设计工具。包括需求采集，模型设计测试与维护。仅针对two-way consolidation.同步规则:添加是累积的，删除优于修改（从一个模型中删除的元素，即使被修改，也会从两个模型中删除）。
融合(merging)与同步（synchronization）：
将两个或更多物理数据库（目录，工作空间，PDA等）或整个逻辑实体（程序，模型等）对齐的过程称为同步。 如果操作成功，则完成时正在同步的项目将完全相同。
协调在同步期间检测到的物理储存库或逻辑实体的相应工件之间的冲突的行为被称为合并。 合并两个冲突的项目导致第三个不同的项目。
理解融合（merge）：融合可以被认为是通过一系列变更操作产生的。可以产生两个问题：不一致(inconsistency)和冲突(conflict)
不一致：如果更改操作序列中的任何操作失败（例如，由于不存在元素）。
冲突：是一对矛盾的变体，即两个操作不相容（例如，给同一方法赋予不同的名称）
可以分为三类：raw merging, two-way merge, three-way merge
是一个分析、设计、开发的工具集，支持理解、设计、管理和企业解决方案的演化及服务。包括模型驱动的设计、分析及开发能力。
融合过程（merge section）：两个contributors复制同一个ancestor模型，然后分别对祖先模型演化（修改）。如果这两个演化版本存在冲突，则被解决。然后被合并成一个最终的结果模型(outcome model)。
some tools make merge decisions based on a default set of rules which may or may not be accessible and extensible.
大多数工具会将合并的冲突和含糊不清的解决方案留给合并者。合并的可用操作取决于工具。
工具：Rational Software Architect, version 7.0
可用规范two-way merge和three-way merge
过程：比较（有变化的部分被标记，有冲突的地方显示）解决冲突（接受、拒决变化或者忽略变化）保存验证
该工具支持n-way merge