模型分区

可以在单个文件中开发一个模型,然后将该模型分成多个文件,这些文件就称为模型分区。当一个模型的大小或封装结构变得难以管理时,就可以考虑对该模型进行分区。

应当在极端情况下才对模型进行分区。因为如果没有正确执行模型分区,就会妨碍小组协作和开发。在考虑对模型进行分区之前,应确保模型具备有效体系结构并且为它指定了有效所有权,以便可以使分区最小化并减少成本较高的合并。

有效模型体系结构和所有权

有效模型体系结构严重依赖于分解。进行面向对象的开发、基于组件的设计和面向服务的体系结构应遵循下列分解原则:

如果经过分解的模型仍然包含大量的依赖关系,则可以选择执行以下两项操作:

建立有效体系结构之后,可以将结构组件的所有权指定给个人或小型小组。当只有一个人或者一个紧密联系的小型小组在使用模型中的逻辑包或分支时,无论将该模型存储在单个还是多个建模文件中,都会使与该模型的较高成本的合并操作减少到最低程度。

通过将模型分成多个建模文件并不能避免执行成本较高的合并,这是因为体系结构是在逻辑上而不是物理上互相依赖。如果将一个模型划分为多个建模文件,则将通过交叉文件引用而不是文件内引用来表示元素之间的互相依赖关系。

因交叉文件引用被破坏而发生的合并冲突是很难解决的。因为您在主机文件系统中给出文件,所以交叉文件引用表示潜在的破坏点。因此,如果移动、重命名或修改位于 Eclipse 环境外部的文件,则 Eclipse 将不能跟踪交叉文件引用。

何时对模型进行分区

在下列情况下应考虑将一个模型分成多个文件:

某些配置管理策略允许进行并行开发,也就是多个小组成员可以同时对模型执行操作。在并行开发期间,不协调的更改会影响文件以及该文件表示的逻辑模型或模型子集。必须合并任何更改才能将模型文件保存在配置管理系统中。当所作的更改不发生冲突时,将进行无关紧要的合并,因此,模型合并工具将自动对更改进行合并。当多个用户进行的更改发生冲突时,将进行成本较高的合并,并且用户必须确定要接受哪些更改。

抽象级别

只应在一个模型的抽象级别稳定之后才对该模型进行分区。当一个模型的抽象级别稳定时,分区就不太可能发生更改。还应该首先找出常用组件并使它们稳定,这是因为更改常用组件就会产生冲突,这些冲突又会影响所有其他分区。

一个模型的早期版本通常描述一个系统的顶级子系统。在定义了将来可能无须进行迭代的顶级子系统之后,才应分隔模型。在顶级子系统完善并且稳定之后,就可以分隔它们以进行并行开发和提高打开模型的速度。在单个子系统的内容稳定之后,就可以分割子系统了。

同步的工作空间

为了避免在使用模型分区时毁坏数据,始终应在包含所有处于相同修订级别的分区的同步工作空间中工作。

示例

以下示例说明了在不同步的工作空间中使用模型的各个分区时可能会发生的情况。

在配置管理系统中,一个模型有两个分区 - 模型 X 和模型 Y。这两个模型的版本都是 20。模型 X 包含一个称为 P1 的包。模型 Y 是空的。

两个用户加入了以下工作流程:

  1. 用户 A 检出版本都是 20 的两个模型。
  2. 用户 A 对 P1 进行了一些更改,然后将 P1 从模型 X 移至模型 Y。
  3. 用户 A 检入模型 X 和模型 Y。现在,两个文件的版本都是 21。
  4. 用户 B 的工作空间中具有版本为 20 的模型 X 并且对 P1 进行了更改。
  5. 当用户 B 试图保存这些更改时,配置管理系统提示用户 B 检出工作空间中的现有版本(模型 X,版本 20)或更高版本(模型 X,版本 21)。

如果用户 B 选择工作空间中的现有版本(模型 X,版本 20),则他可能必须重复执行提示检出的操作。

但是,如果用户 B 使用更高模型版本(模型 X,版本 20)来保存他所作的更改,则会覆盖用户 A 所作的更改。

相关任务
为小组开发组织模型
对模型分区

反馈