浅谈UML中常用的几种图——鲁棒图

什么是鲁棒图

• 鲁棒图包含 3 种元素(如图 8-2 所示),它们分别是边界对象、控制对象、实体对象:
  • 边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入,处理内部内容的解释,并表达或传递相应的结果。
  • 控制对象对行为进行封装,描述用例中事件流的控制行为。
  • 实体对象对信息进行描述,它往往来自领域概念,和领域模型中的对象有良好的对应关系。

鲁棒图和MVC的比较

?

1.  View仅涵盖了“用户界面”元素的抽象,而鲁棒图的边界对象全面涵盖了三种交互,即本系统和外部“人”的交互、本系统和外部“系统”的交互、本系统和外部“设备”的交互。 2.  数据访问逻辑是Controller吗?不是。控制对象广泛涵盖了应用逻辑、业务逻辑、数据访问逻辑的抽象,而MVC的Controller主要对应于应用逻辑。 3.  MVC的Model对应于经典的业务逻辑部分,而鲁棒图的实体对象更像“数据”的代名词——用实体对象建模的数据既可以是持久化的也可以仅存在于内存中，     并不像有的实践者理解的那样直接就等同于持久化对象。

 

棒图范例

• 银行储蓄系统的“销户”功能的鲁棒图

鲁棒图的作用

?

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

鲁棒图的10条经验

 

建模规则

?

1.  参与者只能与边界对象交谈。 2.  边界对象只能与控制对象和参与者交谈。 3.  实体对象也只能与控制对象交谈。 4.  控制对象既能与边界对象交谈,也能与控制对象交谈,但不能与参与者交谈。

鲁棒图语法

鲁棒图思维方式

增量建模

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

实体对象≠持久化对象

?

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

针对关键功能画鲁棒图

?

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

控制对象的数量

?

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

不需要关注细节

?

初步设计不应关注细节 1.  对每个对象只标识对象名,都未识别其属性和方法。 2.  “活期账户销户界面”,具体可能是对话框、Web页面、字符终端界面,但鲁棒图中没有关心这些细节问题。 3.  “客户资料”等实体对象须要持久化吗?不关心,更不关心用 Table 还是用File或其他方式持久化。 4.  没有标识控制流的严格顺序。

不要过分关注UI

?

过分关心UI,会陷入诸如有几个窗口,是不是有一个专门的结果显示页面等诸多细节之中,初步设计就没法做了。别忘了,初步设计的目标是发现职责。 初步设计无须展开架构设计细节,否则就背上了“包袱”,这是复杂系统架构设计起步时的大忌。

借助鲁棒图的初步设计

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