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