文档介绍：郝源春
2012年8月29日
软件架构设计(五) ——软件架构要设计到什么程度
无法理解某些“高人”的软件架构设计方案,或者至少是不同人有不同的理解?
无法从软件架构设计方案中得到足够的指导,对一些关键部分的实现方法依然一头雾水?
投标或市场演讲归来,直接从演示的PPT上拷贝些东西,作为架构设计方案的全部,直接让开发人员去开发?
设计很玄妙,但在大规模并行开发时才暴露出一些影响全局的设计决策问题,于是出现程序员碰头临时决定的情况?
作为软件开发人员,你是否遇到过以下问题?
“架构被用作销售手段,而不是技术蓝图,这屡见不鲜。”
——Thomas J Mowbray, 《What is Architecture》
“我不会认为Coding和Designing是对立的。……而问题在于,那些设计人员的设计又往往是高来高去的扯淡,脱离实际情况,二者的矛盾就必然存在。”
——猛禽,《设计不是一件玄事》
症状一:缺失重要架构视图
由于角色与分工不同,关注点不同;
由于项目不同,侧重点不同;
片面强调用户描述的功能需求,对非功能需求关注不够;
症状二:浅尝辄止,不够深入
停留在概念性架构的层面,没有提供明确的技术蓝图
遗漏了全局性的设计决策,到大规模开发阶段,由具体开发人员从局部视角考虑并确定下来
症状三:名不副实的分层架构
仅用分层进行指责划分,没有规划层次之间的交互接口和交互机制
“层”已退化成笼统意义上的“职责模块”了
高来高去式架构设计的症状
高来高去症的对策
症结
问题
对策
缺失重要架构视图
遗漏了对团队某些角色的指导
针对遗漏的架构视图进行设计
浅尝辄止,不够深入
将重大技术风险遗留到后续开发中
设计决策须细化到和技术相关的层面
名不副实的分层架构
只用分层概念进行指责划分,没有明确层次之间的交互接口和交互机制
步步深入,明确各层之间的交互接口和交互机制
“分而治之”的两种方式
按问题深度分而治之
例如,接口和实现分离
按问题广度分而治之
例如,展现层、业务层和数据层的分层开发
架构设计与详细设计
先架构设计规划全局,再详细设计明确局部,实现按问题深度分而治之
对不同局部分工进行详细设计,实现按问题广度分而治之
该方法利于控制复杂性,提高开发效率,常被称为“以架构为中心的开发方法”
软件架构要设计到什么程度
架构设计
详细设计
详细设计
详细设计
详细设计
问题的广度
问题的深度
架构设计要进行到什么程度
软件项目不同,架构设计的程度不同
开发团队情况不同,架构设计的程度不同
一些公共模块会设计得比较深入,具体的业务功能模块往往设计程度不深
软件架构要设计到什么程度
架构设计
详细设计
详细设计
详细设计
详细设计
问题的广度
问题的深度
架构设计
详细设计
详细设计
详细设计
详细设计
问题的广度
问题的深度
总结为两句话:
由于项目的不同、开发团队情况的不同,软件架构设计的程度会有所不同;
软件架构应当为开发人员提供足够的指导和限制。
软件架构要设计到什么程度
概念性架构设计
已在上一章中介绍
案例分析:网络管理系统
名称
职责
网络拓扑模块
接收状态轮询模块的汇报
接收设备发现模块的汇报
向设备发现模块发送发现命令
状态轮询模块
向网络拓扑模块发送设备状态信息
设备发现模块
向网络拓扑模块发送所发现设备的信息
接受网络拓扑模块的发现命令
实际架构设计
识别各层功能模块
实际架构设计
明确各层之间的交互接口
案例分析:网络管理系统