WinZip案例：鲁棒图发现实现用例需要的类

[[用例驱动模块划分的两环节四步骤]]第一步”实现用例需要哪些类”，如果系统复杂或对领域不熟悉，可以借助鲁棒图配合增量建模逐步发现——书中以WinZip、WinRAR这类压缩工具的”压缩”功能为例完整演示了这个过程。第一步，识别最”明显”的职责：压缩就是把”原文件”变成”压缩包”的处理过程，于是先识别出原文件、压缩包、压缩器（负责压缩处理）三个职责，不必纠结这是不是”标准答案”。第二步，考虑职责间的关系、发现新职责：”压缩器”读”原文件”、最终生成”压缩包”，进一步发现可以把”打包器”独立出来（受压缩器委托工作），还发现需要”字典”这类支撑角色。第三步，继续同样的思维方式，此时《用例规约》定义的各种场景是最重要的输入（哪怕没有文档化，头脑中要有）——又引入了”压缩配置”这个职责，它影响着压缩器的具体工作方式（比如加密压缩、分卷压缩）。最终，因为压缩功能还要支持显示压缩进度、以及随时取消进行了一半的压缩工作，又识别出了”压缩行进界面”和”监听器”等职责，鲁棒图逐步完善成型。这个案例和[[鲁棒图的增量建模技巧]]（第9章网上书店搜索案例）演示的是同一套增量建模方法论，但换了一个不同领域（压缩工具而非搜索功能）来印证：无论系统类型如何变化，”先识别最明显职责→考虑职责关系发现新职责→不断迭代完善”这套思维流程本身是通用的，可以迁移到任何一个需要从功能需求过渡到设计元素的场景。