Technorati 标签: uml

这段时间在学 UML 建模，UML 10 中常见的域建模错误摘录如下：

1.立即关联指定多重度，确保每个关联都有明确的多重度

类图上有些关联度表示的是一对一的关系，而其他关联表示的是一对多的关系。这两种关系都被称为多重度。然而，不应在域建模期间就确定多重度 —— 这将占用大量的时间，是导致分析瘫痪的主要原因之一。

2.对名词和动词做过度的分析，而背离初衷

对名词尤其是动词作过度的分析，将很可能处于过低的抽象层次上，严重者还会有神经崩毁的危险（当然这是玩笑话）。

3.不对用例和时序图进行研究，就将操作分配给类

我们提倡在域建模过程中使用要求最低的的方式。事实上，我们是想告诉你，不应该在域建模期间将任何操作分配给类。因为，在项目的该阶段还没有足够的信息，无法做出正确的决策。进入交互模式后，你将拥有足够的信息（至少希望如此），

4.在确保已满足用户需求之前，对代码进行优化以提高重用性

对象和类的通用程度越高，在其他项目中重用他们的可能性就越大。一个完整地类在理论上是可以在任意数目的环境（context）中重用的，然而要实现完整性和重用性，必须考虑属性和操作，而前面已经指出了不应在域建模期间将操作分配给类的原因，因此在完成高级类图期间，将过多的精力用于提供类的可重用性是不明智的，应快速完成域建模的工作，以便有时间确保你构建的系统正是用户所需要的。

5.对于每个部分（part-of）关联，就使用聚集还是组合而争论不休

在 UML 中，有这么一种说法，“按引用拥有”关系是聚集，而“按值拥有”关系是一种被称为组合的“强”形式的聚集，在这种关系中，“部分”类归父类“所有”：父类被删除后，其所有的子对象示例将自动删除。在域建模期间视图区分聚集和组合无疑是费力不讨好的。在域建模期间，更倾向于使用简单的聚集。使用聚集还是组合是一个详细设计方面的问题。

6.未对问题空间进行建模之前，就假定一种具体的实现策略

改进域模型时，应删除所有明显陈述动作而不是依存性的内容以及同实现相关的内容。在高级类图中，不应引入涉及到具体技术的内容，如关系数据库或特定的服务器。将实现问题留待实现阶段解决，首先对问题域建模。

7.将类命名为难以理解的名称（如 cPortMgrIntf），二不是直观的名称（如 UserManager）

首先建立模型的一个重要原因，就是促使每个小组成员就关键抽象的名称达到一致。类名越简明，这项任务就越容易。应等到实现时再使用首字母缩写和各种缩略语（如果你一定要这样做的话）。

8.直接进入实现结构，如友元关系和参数化类

UML 提供了大量将我们称作“Booch 素材”的东西添加到类图中的机会。这包括直接来自C++的结构，如参数化类和友元关系。这些东西与解决方案空间相关，而与问题空间不相关，因此域建模绝对是属于问题空间的。

9.在域类和关系数据库表之间建立 1 对 1 的映射

对使用关系数据库的遗留系统进行重构时，数据库中的表可能是很多的域类名称的来源。然而，决不要将它们完全搬照搬到静态模型中。关系数据库中的很多属性不能找搬到对象模型环境中，应尽可能通过聚集，将属性组转换为“助手（helper）“类。这种类包含的属性和操作可被组合成更小的“部分”类。

10.过早地执行“模式化”，这将导致根据同用户问题毫无关系的模式创建解决方案。

模式通常在健壮性分析时才能发现。有两种策略可用于发现同用例相关的模式：“屏幕控制”和“用例控制器”。设计模式对时序图和设计级类图很有用，但域建模期间不应考虑模式的问题。