第十讲软件架构设计 - Read.PPT

需求分析 领域建模 为交流提供公共的领域词汇 提供探索问题领域的语境 项目启动 领域建模 需求分析 架构设计 详细设计 详细设计 详细设计 需求捕获 重新认识 需求详述 设计 引起变更 促成设计决策 变更冲击设计 需求捕获 重新认识 关键需求 其余需求 设计 变更性小 变更性大 决定架构 验证架构 P200 表14-2 概念性架构 实际架构 开发实现 关键设计元素 关键交互机制 逻辑架构　数据架构开发架构　运行架构 物理架构 详细设计 编码实现 基于５视力方法 进行架构细化 关键需求 概念架构 约束 架构方案 经验 分析模型 问题空间 解空间 设计模型 系统分析员 系统设计师 《描述》 《描述》 《描述》 《描述》 方法缺少针对性 设计层次论 架构设计方法 在OO过程中的位置 什么是对架构关键的需求 包括功能需求、质量（属性）需求、商业需求三类 任何功能需求，都是由一条特定的“模块协作链”完成的。对软件架构关键的功能需求，就是它涉及（或串起）的模块最多、最典型的功能需求。 对架构至关重要的质量属性需求是那些经过权衡取舍、最终决定重点支持的质量属性需求。 商业需求又称业务需求（其实对应的英文都为Business Requirement）。它关注： 客户群、企业现状、未来发展 预算、立项 包括开发、运营、维护在内的整个软件生命周期因素 商业层面的目标、期望和限制等 什么是对架构关键的需求 具体步骤 第一步：全面整理需求 研究《愿景和范围文档》 研究《软件需求规格说明书》 参加需求讨论会 询问客户、用户、领域专家、系统分析员 突破字面意思 分析遗漏需求 第二步：分析约束性需求 商业需求因素（第二步） 商业需求因素（第二步） 案例：银行系统（第二步） 第三步：确定关键功能需求 核心功能 –标志：业务层的接口要反映这些功能 必须实现的功能 –往往来自甲方的要求。 覆盖了系统架构的一些方面，而其他功能没有 例如…… 实现风险高的功能 例如…… 第四步：确定关键质量属性需求 考虑为了提高要开发的软件系统受认可的程度，应着重提高哪些方面的质量属性要求； 接下来，充分考虑这些质量属性之间的相互制约、或相互促进关系，以调整不同质量属性的要求标准——例如，你可能会决定高性能要求最最重要，而可扩展性也比较重要； 同时，必须满足各种约束性需求。 不再拍脑袋：从场景到决策 “属性-场景-决策表”方法 整体质量观：如何权衡决策 案例 案例 总结回顾 包含非功能需求在内的一组关键需求，驱动了架构设计 “属性-场景-决策表”是有效的非功能需求设计方法 谢谢大家！ 第十讲 软件架构设计 目标 管窥架构设计现状 架构设计方法 如何确定架构驱动因素 非功能需求设计方法论 通用过程太笼统 架构分析 架构分析可以被视为需求分析的规格化，其关注强烈影响”架构“的需求。例如，为系统识别高度安全方面的需求。 架构分析的本质是要识别影响架构的因素，理解这些因素的可变性和优先级，并且解决这些问题 为什么架构分析如此重要？因为它有助于： 降低在系统设计中丢失某些重要因素的风险。 避免在低优先级的问题上花费过多的精力 有助于产品与业务目标的一致 架构分析 架构分析（architecture analysis）是在功能性需求（例如处理销售等）的语境中，识别和处理系统非功能性需求（例如安全需求等）的活动。其包括识别变化点和最具有可能性的进化点。 例： 可靠性和容错需求如何影响设计？ 采购子构建的许可费用如何影响收益率？ 可适应性和可配置性需求如何影响设计？ 商标名称的选择如何影响架构？ 架构分析 识别和分析对架构有影响的非功能性需求。虽然与功能性需求也有关系（特别是可变性方面），但是应该对非功能性需求给予非常彻底的关注。通常，这些都被称为架构因素（或者称为架构驱动者） 对于这些在架构方面具有重要影响的因素，需求分析可供选择的办法并创建解决这些影响的解决方案。这就是架构决策。 架构分析 软件系统的架构将系统描述为计算组件及组件之间的交互 ”组件“可以指子系统、框架（Framework）、模块、类等不同程度的软件单元，它们可以担负不同的计算职责。 软件架构的要素：组件及组件之间的交互 组件 交互 MVC架构作为”组件+交互“的例子 View Controller Model 创建 读取 通知 调用服务 关注点分离之道 好的架构设计必须把变化点错落有致地封装到软件系统的不同部分，为此，必须进行关注点分离 好的架构必须使每个关注点相互分离，也就是说系统中的一部分发生了改变，不会影响其他部分。即使需要改变，也能够清晰地识别出哪些部分需要改变。如果需要扩展架构，影响将会最小化。已经可以工作的每个部分都将继