[架构之路-104]：《软件架构设计：程序员向架构师转型必备》-14-根据需求用例驱动进行软件架构的模块划分过程

14 用例驱动的模块划分过程

描述用例的两种方式：

• 图形描述：用例序列图，直观，但修改不方便，版本控制不方便。

• 文本描述：用例规约描述，不直观，但修改方便，版本控制方便。

14.1 描述需求的序列图 vs. 描述设计的序列图

说明：时序图是软件系统动态交互最好的方式。

备注：描述需求的序列图，是站在用户的角度描述的系统与外部的交互，是需求，也是设计。

14.1.1 描述“内外对话” vs. 描述“内部协作”

序列图既可以描述需求：外部用户对系统的需求 =》 来自用例图

序列图也可以描述设计：内部模块与模块之间的交互 =》对用例的细化

用用例中使用到的不同的“名词”划分为不同的“类”，根据相似性对“类”进行汇总，就得到了“功能模块”。这种方法，并非得到功能模块，然后再在功能模块中切分“类”。

因此，用例划分模块的过程是先分后总的过程！！！

14.1.2 《用例规约》这样描述“内外对话”

通过用例规约，可以详细描述用户与系统交互的行为。

14.2 用例驱动的模块划分过程（非常重要！！！）

14.2.1 核心原理：从用例到类，再到模块

备注：

用例是是需求，是软件的功能需求。协作图是功能设计，是架构设计，描述如何划分功能模块和模块之间的关系实现用例的功能！！！

备注：对象图=》类图 =》包图（模块）

备注：

本节阐述了一个关键的方法：如何从用例获得内部的模块设计！！！

（1）方法1：鲁棒图，能够获得内部模块。

（2）方法2：序列图，能够获得内部模块之间的交互。

14.2.2 第1步：实现用例需要哪些类

14.2.3 第2步：这些类应该划归哪些模块

备注：

很显然，分层和画模块并非一会事，并非同一个层的所有对象，就在同一个模块中。

界面交互模块：包含了界面层、业务逻辑处理层。

压缩控制模块：包含了解压和压缩的业务逻辑。

源文件读写模块：包含了业务逻辑层和源文件数据层。

压缩读写模块：包括了业务逻辑处理层和压缩后数据的数据层。

14.3 实际应用（12）——对比MailProxy案例的 4种模块划分设计

14.3.1 设计

14.3.2 设计的优点、缺点