[架构之路-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-解析软件架构的概念