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

Posted 文火冰糖的硅基工坊

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[架构之路-104]:《软件架构设计:程序员向架构师转型必备》-14-根据需求用例驱动进行软件架构的模块划分过程相关的知识,希望对你有一定的参考价值。

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 设计的优点、缺点

以上是关于[架构之路-104]:《软件架构设计:程序员向架构师转型必备》-14-根据需求用例驱动进行软件架构的模块划分过程的主要内容,如果未能解决你的问题,请参考以下文章

[架构之路-94]:《软件架构设计:程序员向架构师转型必备》-4-软件架构设计的通用过程

[架构之路-100]:《软件架构设计:程序员向架构师转型必备》-10-细化架构设计

[架构之路-92]:《软件架构设计:程序员向架构师转型必备》-2-解析软件架构的概念

[架构之路-92]:《软件架构设计:程序员向架构师转型必备》-2-解析软件架构的概念

[架构之路-101]:《软件架构设计:程序员向架构师转型必备》-11-原型设计与架构评估与提前验证

[架构之路-103]:《软件架构设计:程序员向架构师转型必备》-13-软件架构如何分层(四层架构)