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

描述用例的两种方式：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

备注：

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

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

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

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

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

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

14.3.1 设计

14.3.2 设计的优点、缺点