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 设计的优点、缺点
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
