软件架构---确定关键需求
确定关键需求,架构师具体要做什么呢?
· 一方面,不同质量属性之间往往具有相互制约性,于是我们自然应该权衡哪一部分质量属性是架构设计的重点目标。
· 另一方面,功能需求数量众多,应该控制架构设计时需要详细分析的功能(或用例)的个数。
1 确定关键质量
为了确定对架构设计关键的质量属性需求,需要做如下三方面的工作:
· 考虑为了提高要开发的软件系统受认可的程度,应着重提高哪些方面的质量属性要求;
· 接下来,充分考虑这些质量属性的相互制约或相互促进关系,以调整不同质量属性的要求标准——例如,你可能会决定高性能要求最最重要,而可扩展性也比较重要;
· 同时,必须满足各种约束性需求。
确定关键质量时考虑质量属性之间的矛盾关系,例如,“互操作性”需求往往给“安全性”需求造成威胁,而为了满足“高性能”需求,往往需要使用特定平台的非标准能力,这势必影响了系统的“可移植性”,……,不一而足。于是,我们自然应该权衡哪一部分质量属性是架构设计的重点目标。
2 确定关键功能
功能需求是大家最熟悉的一种需求。Karl E. Wiegers在《软件需求(第2版)》中这样描述它:
功能需求(Functional Requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求(Behavioral Requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。
而所谓对软件架构关键的功能需求,就是它涉及(或串起)的模块最多、协作方式最有代表性的功能需求。
任何功能需求,都是由一条特定的“模块协作链”完成的。控制权在模块协作链中来回传递,而功能需求就相当于串起不同模块的线索
如何确定关键功能需求呢?可通过如下4条启发规则,确定关键功能子集:
· 核心功能。
· 必做功能。
· 高风险功能。
· 独特功能(覆盖了上述3类功能没有涉及的职责)。
核心功能。识别“核心功能”,有个标志:业务层的接口要反映这些功能。例如,项目管理系统中,项目信息查看、添加项目任务等都是核心功能。
必做功能。识别“必须实现的功能”主要依据客户方的背景。架构师不应忽视系统的《愿景与范围文档》,这份文档描述了项目立项的真正源起,文档“项目愿景的解决方案”中“主要特征”往往应作为“必做功能”的备选项。另外,对于业务系统而言,一般支持“运营”的功能比支持“管理”的功能优先级要高。
高风险功能。基于务实考虑,还应该把“风险高的功能”选入关键功能子集。
例如,你在设计一个网上书店系统,书籍的全库搜索功能就需要特别关注:
· 从用户角度讲,极慢的搜索速度、甚至直接收到“系统忙,请稍后再试”的提示,都是令人不满的;
· 从架构设计角度讲,此功能对书籍数据库进行“面状、只读”式的使用,和增加书籍、修改书籍信息等功能“点状、写入”式的数据库使用特点完全不同……尽早将全库搜索功能选入“高风险功能”之列,利于有针对性地进行架构设计。
独特功能。最后,看看还是否覆盖了“上述3类功能没有涉及的职责”的功能。例如,如果你设计类似“搜狗拼音”这样的输入法软件,“词库在线更新”功能就必然是对架构关键的功能,因为忽略了它就很难发现架构中负责和服务器交互的“互操作模块”。显然,“特殊功能”是相对上述3类功能而言的。
另外,架构师在确定关键功能子集时,还必须注意两点。
第一,“关键功能子集”的确定并不存在“标准答案”。只要能较好地覆盖组成架构的不同职责模块,并体现职责模块之间协作关系的特点(有经验的架构师不会放过后者),那么“关键功能子集”的价值也就体现了。
第二,值得专门说明的还有“关键功能所占比例”的问题。有些专家认为比例大致是固定的,例如,Per Kroll和Philippe Kruchten在《Rational统一过程:实践者指南》中写道:
在初始阶段,应该确定出一些(大概占总数的20%至30%)对系统起关键作用的用例。这些用例通常对创建架构具有重要影响。
参考:温昱《软件架构设计》