鲁棒图：从功能需求到设计的桥梁

需求和设计之间存在一道无形的鸿沟：用例规约用自然语言、面向问题域描述功能，设计需要用类、包、组件等面向对象、形式化的方式描述系统内部结构——两者的思维方式、描述手段完全不同，很多人在需求分析之后就此卡壳。越过这道鸿沟需要搭桥，这座桥就是鲁棒图（Robustness Diagram，1991年由Ivar Jacobson发明）。鲁棒图和”鲁棒性”这个词看似相关，实则含义不同——鲁棒性（健壮性/容错性）指系统在非法输入、软硬件故障、未预料情况下仍能正确运行的能力；而鲁棒图的作用除了初步设计之外，就是检查用例规约是否正确和完善，它是因为承担”检查”这个功能而得名，严格讲和”鲁棒性”不是一回事。鲁棒图包含三种元素：边界对象，为系统与外部环境之间的交互建模，负责接收外部输入、解释内部内容、传递结果；控制对象，封装用例中事件流的行为，描述控制逻辑；实体对象，描述信息，通常来自领域概念、和领域模型中的对象有良好对应关系。每个用例由若干场景（正常或意外）组成，每个场景的实现是一串职责协作，从用例规约出发运用鲁棒图建模，本质上是研究功能如何和外部Actor交互（发现边界对象）、研究功能实现需要的行为（发现控制对象）、研究实现功能所需的信息（发现实体对象），这个从功能需求到”交互/行为/信息”三种基本设计元素的思维过程直观地抹平了需求到设计的鸿沟。特别需要注意鲁棒图三元素和MVC看似相似、实则有明显差异，不能简单等同：View仅涵盖用户界面元素，而边界对象全面涵盖本系统与外部”人”、外部”系统”、外部”设备”三种交互；数据访问逻辑不是Controller，控制对象广泛涵盖应用逻辑、业务逻辑、数据访问逻辑，而MVC的Controller主要对应应用逻辑；MVC的Model对应经典业务逻辑，而实体对象更像”数据”的代名词，既可以是持久化数据也可以只存在于内存中，并不等同于持久化对象。

结构图：

flowchart LR
    A["用例规约\n（面向问题域，自然语言）"] --> B["鲁棒图建模\n研究交互/行为/信息"]
    B --> C["边界对象\n（交互：人/系统/设备）"]
    B --> D["控制对象\n（行为：应用/业务/数据访问逻辑）"]
    B --> E["实体对象\n（信息：可持久化或仅存于内存）"]
    C --> F["设计\n（面向对象，形式化模型）"]
    D --> F
    E --> F