学习笔记-鲁棒图

参考网址：https://blog.csdn.net/thebulesky/article/details/108402587

（1）鲁棒图包含 3 种元素：边界对象、控制对象、实体对象:

1.边界对象：对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入,处理内部内容的解释,并表达或传递相应的结果。
2.控制对象：对行为进行封装,描述用例中事件流的控制行为。（操作）
3.实体对象：对信息进行描述,它往往来自领域概念,和领域模型中的对象有良好的对应关系。（数据）

（2）鲁棒图和MVC的比较

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

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

3. MVC的Model对应于经典的业务逻辑部分,而鲁棒图的实体对象更像“数据”的代名词——用实体对象建模的数据，既可以是持久化的也可以仅存在于内存中，并不像有的实践者理解的那样直接就等同于持久化对象。

（3）鲁棒图的作用

4. 有助于确保用例文本的正确性,且没有指定不合理或不可能的系统行为(基于要使用的一组对象),从而提供了健康性检查(Sanity Check)。这种改进使用例文本的特性从纯粹的用户手册角度变为对象模型上下文中的使用描述。
5. 有助于确保用例考虑到了所有必需的分支流程,从而提供了完整性和正确性检查。经验表明,为实现这种目标,并编写出遵循某些定义良好的指南的文本,而在绘制鲁棒图上花费的时间,将在绘制时序图时
   3~4 倍地节省下来。
6. 有利于发现对象,这一点很重要,因为在域建模期间肯定会遗漏一些对象。您还可以发现对象命名冲突的情况,从而避免进一步造成严重的问题。另外,鲁棒分析有利于确保我们在绘制时序图之前确定大部分实体类和边界类。

（4）鲁棒图的10条经验

（一）建模规则

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

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

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

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

（二）鲁棒图语法

（三）鲁棒图思维方式

（四）增量建模

增量建模能解决鲁棒图建模卡壳的问题;从大处讲,这种方式适用于所有种类的UML图建模实践。

（五）实体对象≠持久化对象：

有些系统须要在内存中创建数据的“暂存体”以保持中间状态,这当然可以被建模成实体对象。有的系统没有持久化数据,但基于鲁棒图的初步设计依然可用,此时难道鲁棒图不包含实体对象?显然不对。

（六）针对关键功能画鲁棒图

（七）控制对象的数量

既然是初步设计,鲁棒图建模时,针对关键功能的每个鲁棒图中的控制对象不必太多太细,5个是常见的上限值。
相反,若实现某功能的鲁棒图中只含1个控制对象,则是明显地“设计不足”——这个控制对象的名字必然和功能的名字相同,这意味着没有对职责进行真正的切分。

（八）不需要关注细节

初步设计不应关注细节

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

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

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

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

（九）不要过分关注UI

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

（十）借助鲁棒图的初步设计

初步设计的目标是发现职责,为高层切分奠定基础。
初步设计不是必须的,但当待设计系统对架构师而言并无太多直接经验时,则强烈建议进行初步设计。
基于关键功能(而不是对所有功能),借助鲁棒图(而不是序列图)进行初步设计。