鲁棒图的性质与用例驱动的正确输入范围

运用[[鲁棒图作为从功能需求到设计的桥梁]]和序列图配合建模时，有两个常见困惑值得澄清。困惑一：鲁棒图是协作图还是类图？答案是鲁棒图是类图，不是协作图——用建模工具画图时，”边界类”“控制类”“实体类”这些鲁棒图所需的元素，能在”类图”图元或”静态结构”图元中找到。这个定性带来一个重要推论：既然鲁棒图是类图，鲁棒图中的”连线”就不是严谨的对象间协作关系定义，这正是”鲁棒图+序列图”这套实践方式不会互相重复的原因——鲁棒图负责发现”应该有哪些类”，序列图负责精确定义”这些类之间具体怎么协作”，两者分工不同，不是同一件事画两遍。困惑二：对于用例非常多的大系统，是否要研究每一个用例的实现？答案是否定的，但理由需要拆开看。一方面，只设计一个用例的实现、得到一组相关的类，还不足以发现整个系统的架构切分规律——单个用例的视角太窄。但另一方面，对大系统而言，研究每一个用例实现之后再划分模块也不切实际，这样做至少有三个问题：不切实际（工作量过大）、有”先详细设计后架构设计”之嫌（本该在架构层面就定下来的划分，被拖到了逐个用例细化之后才做）、最大的问题是每个用例的实现设计没有受到架构的指导和制约，可扩展性、高性能这类整体质量属性根本无从保证。因此用例驱动设计的正确输入是一组用例，既不是一个用例，也不是全部用例——对于复杂系统，应该参照[[关键需求决定架构，其余需求验证架构]]的思路（第8章），从众多用例中先确定少数对架构设计关键的用例，再以这组关键用例为输入驱动模块划分。