逻辑组织
逻辑模型组织应当实现下列目标:
物理组织
物理模型组织具有两种方法:
虽然规划物理分区策略具有优势,但是使用更自然的方法也有效,有时候可以解决已计划的方法中忽视或者不期望发生的问题。例如,如果由于增加了新的需求或者设计复杂性超出预期而使包结构的整个模型大小或深度变得难以管理,那么您可以决定执行物理分区。
模型合并
当您规划模型的逻辑组织和物理组织时,模型合并是一个重要注意事项。
某些配置管理策略允许进行并行开发,也就是说多个团队成员可以同时处理同一模型。在并行开发期间,不协调的更改可能会影响模型。您必须合并更改,然后将模型文件保存在配置管理系统中。当所作的更改不发生冲突时,将进行无关紧要的合并,一个工具将自动对更改进行合并。当所作的更改发生冲突时,将进行重要的合并,并且您必须确定要接受哪些更改。
有效模型体系结构严重依赖于分解,分解就是能够将系统分成多个部分。进行面向对象的开发、基于组件的设计和面向服务的体系结构应遵循下列分解原则:
如果模型在分解之后仍然包含大量的依赖项,那么有两个选项供您选择:
建立有效体系结构之后,可以将结构组件的所有权指定给个人或小型团队。当一个人员或者一个紧密联系的小型团队在处理模型中的逻辑包或分支时,无论将该模型存储在单个还是多个建模文件中,都会使与该模型的较高成本的合并操作减少到最低程度。
有以下两种机制可用于将逻辑模型分区:创建单独的模型;分段。
当您创建单独的模型时,通常从组织在公共逻辑模型根下或者根包下的许多逻辑模型包开始。 这些逻辑包将占用同一物理建模文件。您在根下选择一个包,并根据该包来创建物理模型。然后,该包在“项目资源管理器”视图中将成为新的顶级逻辑模型。新模型在逻辑上不再归将其分区的模型所有。此外,该新模型包含的元素与该模型先前的父逻辑模型仍然包含的元素之间的关系将成为交叉文件关系。以前,这些关系在文件中,这会影响模型的比较与合并方案。
相比之下,通过将模型分段,您可以选择模型的任何类元类型的元素,并将其作为片段来管理。片段是一个独立的物理 Eclipse 资源文件,但是父逻辑模型拥有其内容。
应当在极端情况下才对模型进行分区。因为如果没有正确执行模型分区,就会妨碍团队协作和开发。
您通常对模型进行实际分区,以尝试减少模型比较与合并活动的数目和量级。但是,通过将模型分成多个建模文件并不能避免执行成本较高的合并,这是因为体系结构是在逻辑上而不是物理上互相依赖。如果将一个模型划分为多个建模文件,则将通过交叉文件引用而不是文件内引用来表示元素之间的互相依赖关系。涉及到交叉文件引用的合并冲突难以解决,因为您不知道模型在其他模型文件中的逻辑内容。当您必须执行合并时,物理分区会使合并会话更具挑战性。
物理模型分区适合于下列情况:
如果您不对模型进行物理分区,而是重点关注逻辑组织、强大的逻辑包所有权和实际的大型模型文件。如果您使用 Rational ClearCase,请使用私有的静态或动态视图以及 UCM 重定基底和交付以保持模型完整性,直到您完成整个集成为止。
此外,仅在逻辑内容开始变得稳定之后才对模型进行分区,以便分区决策不太可能需要更改。例如,模型的早期版本通常描述顶级子系统。定义了可能保留在将来的迭代中的顶级子系统之后,才应进行分区。在顶级子系统完善并且稳定之后,就可以物理方式分隔它们(如果这样做可以改善并行开发工作流程或者提高诸如打开或发布模型等任务的性能)。此外,首先重点关注从逻辑上稳定高度共享的常见组件,因为对这些组件所作的更改可能会导致冲突,这些冲突会影响所有其他分区。
为了避免在使用模型分区时毁坏数据,始终应在包含所有处于相同修订级别的分区的同步工作空间中工作。
示例
以下示例说明了在不同步的工作空间中使用模型的各个分区时可能会发生的情况。
在配置管理系统中,一个模型有两个分区 - 模型 X 和模型 Y。这两个模型的版本都是 20。模型 X 包含一个称为 P1 的包。模型 Y 是空的。
两个用户加入了以下工作流程:
如果用户 B 选择工作空间中的现有版本(模型 X,版本 20),则他可能必须重复执行提示检出的操作。
但是,如果用户 B 使用更高模型版本(模型 X,版本 20)来保存他所作的更改,则会覆盖用户 A 所作的更改。