1.  View仅涵盖了“用户界面”元素的抽象,而鲁棒图的边界对象全面涵盖了三种交互,即本系统和外部“人”的交互、本系统和外部“系统”的交互、本系统和外部“设备”的交互。

2.  数据访问逻辑是Controller吗?不是。控制对象广泛涵盖了应用逻辑、业务逻辑、数据访问逻辑的抽象,而MVC的Controller主要对应于应用逻辑。

3.  MVC的Model对应于经典的业务逻辑部分,而鲁棒图的实体对象更像“数据”的代名词——用实体对象建模的数据既可以是持久化的也可以仅存在于内存中，

    并不像有的实践者理解的那样直接就等同于持久化对象。

1.  有助于确保用例文本的正确性,且没有指定不合理或不可能的系统行为(基于要使用的一组对象),从而提供了健康性检查(Sanity Check)。这种改进使用例文本的特性从纯

    粹的用户手册角度变为对象模型上下文中的使用描述。

2.  有助于确保用例考虑到了所有必需的分支流程,从而提供了完整性和正确性检查。经验表明,为实现这种目标,并编写出遵循某些定义良好的指南的文本,而在绘制鲁棒图上

    花费的时间,将在绘制时序图时 3~4 倍地节省下来。

3.  有利于发现对象,这一点很重要,因为在域建模期间肯定会遗漏一些对象。您还可以发现对象命名冲突的情况,从而避免进一步造成严重的问题。另外,鲁棒分析有利于确保

    我们在绘制时序图之前确定大部分实体类和边界类。

1.  参与者只能与边界对象交谈。

2.  边界对象只能与控制对象和参与者交谈。

3.  实体对象也只能与控制对象交谈。

4.  控制对象既能与边界对象交谈,也能与控制对象交谈,但不能与参与者交谈。

    一方面,在实践中,有些系统须要在内存中创建数据的“暂存体”以保持中间状态,这当然可以被建模成实体对象。另一方面,有的系统没有持久化数据,

但基于鲁棒图的初步设计依然可用,此时难道鲁棒图不包含实体对象?显然不对。

基于“关键需求决定架构”的理念,功能需求作为需求的一种类型,在设计架构时不必针对每个功能都画出鲁棒图。

    既然是初步设计,鲁棒图建模时,针对关键功能的每个鲁棒图中的控制对象不必太多太细,5个是常见的上限值。相反,若实现某功能的鲁棒图中只含1个控制对象,

则是明显地“设计不足”——这个控制对象的名字必然和功能的名字相同,这意味着没有对职责进行真正的切分。

初步设计不应关注细节

1.  对每个对象只标识对象名,都未识别其属性和方法。

2.  “活期账户销户界面”,具体可能是对话框、Web页面、字符终端界面,但鲁棒图中没有关心这些细节问题。

3.  “客户资料”等实体对象须要持久化吗?不关心,更不关心用 Table 还是用File或其他方式持久化。

4.  没有标识控制流的严格顺序。

    过分关心UI,会陷入诸如有几个窗口,是不是有一个专门的结果显示页面等诸多细节之中,初步设计就没法做了。别忘了,初步设计的目标是发现职责。

初步设计无须展开架构设计细节,否则就背上了“包袱”,这是复杂系统架构设计起步时的大忌。