用例驱动模块划分的两环节四步骤

[[粗粒度功能模块划分的两个维度]]虽然会把功能相近的一组用例划到同一个功能模块，但这还算不上真正的”用例驱动”设计思想。用例驱动的核心原理是：从用例到模块划分结构，关键过渡是一组对象的相互协作——协作是一组对象为了实现某个目的而进行的交互，这里”某个目的”就是用例定义的功能，”一组对象”就是用例实现所需要的程序元素，最熟悉的序列图正是围绕一个功能的一组对象的协作。从用例出发，经过序列图建模识别出一系列对象，这些对象的合理分组就能促进定义出系统的模块结构。完整的思维路径可以概括成”两环节、四步骤”：需求分析环节——先用用例图定义系统能提供给外部Actor的哪些功能，再用用例规约把笼统的”功能”进一步明确定义为”能够为用户带来价值的交互序列”（但此时系统仍保持黑盒）；架构设计环节——先打破黑盒，识别一个用例背后有哪些类、设计类之间的交互，再梳理通过多个用例识别出的这些类，把它们划分到不同模块。聚焦到架构设计环节，用例驱动的模块划分过程进一步拆成两步：第一步回答”实现用例需要哪些类”，运用鲁棒图、序列图；第二步回答”这些类应划归哪些模块”，运用包图等工具。这个”两环节四步骤”框架的价值在于把”用例驱动设计”这个听起来抽象的方法论，拆解成了一条从需求到设计层层递进、每一步都有明确输入输出和对应UML工具的具体流程，而不是一个模糊的口号。

结构图：

flowchart TD
    subgraph 需求分析环节
        A["用例图\n定义系统对外提供的功能"] --> B["用例规约\n交互序列（黑盒）"]
    end
    subgraph 架构设计环节
        C["第1步：实现用例需要哪些类\n运用鲁棒图、序列图"] --> D["第2步：这些类划归哪些模块\n运用包图等"]
    end
    B -->|"打破黑盒"| C