第五部分 细化迭代3—中级主题(33-35章).pptVIP

PRJ270: Essentials of Rational Unified Process Module 1 Best Practices of Software Engineering 第五部分 细化迭代3 —— 中级主题(2) 主要内容 架构分析 逻辑架构的精化 包的设计 第三十三章 架构分析 什么是软件架构 架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。[IEEE 1471] 架构是对软件系统组织，结构部分和系统包含接口的选择，集合部分的特定行为，较大子系统部分的构成和架构风格的重大决定的设置。[Kruchten] 系统或计算系统的软件架构是包含软件部分，外部可见特性部分，和他们之间的关系的系统的结构。[Bass et al.] [架构]是系统的组织结构和相关行为。架构可被重复分解为通过接口，互联部分的关系和结合不相互作用的部分。通过接口相互作用的部分包括类，组件和子系统。[UML 1.5] 软件架构或系统由组成系统的结构的相互作用和软件结构的重要设计决定组成。设计决定应成功实现所期望支持的质量。设计决定为系统开发，支持和维护提供概念上的基础。 [McGovern] 共同点：大部分定义都指出一个架构关注于结构和行为，仅关注于重要决定，可以与架构风格一致，受涉众和环境的影响，体现基于原因的决定。 33.1 架构分析 架构分析的意义 降低在系统设计中丢失某些重要因素的风险 避免在低优先级的问题上花费过多的精力 有助于产品与业务目标的一致 何时开始架构分析 早期工作中就要识别和解决架构问题 架构分析和早期开发活动并行 变化点和进化点 变化点：当前现有系统或需求中的变化之处 进化点：现有需求中不存在，但可能在将来发生，推测性的变化点 什么是架构分析？ 架构分析是在功能性需求（例如销售处理）的语境中，识别和处理系统的非功能性需求（例如安全需求等）的活动。 架构分析的本质是要识别影响架构的因素，理解这些因素的可变性和优先级，并且解决这些问题。 架构分析——问题示例 可靠性和容错需求如何影响设计 采购子构件的许可费用如何影响收益率 可适应性和可配置性需求如何影响设计 商标名称的选择如何影响架构 架构分析——常用步骤 识别和分析对架构有影响的非功能性需求 可看作常规需求分析，初始阶段需粗略记录，细化阶段仔细地对这些需求调查 对于这些在架构方面具有重要影响的需求，需要分析可供选择的办法并创建解决这些影响的解决方案—架构决策 决策的范围包括：“删除需求”，定制解决方案，“终止该项目”或者“雇用一个信息专家”等。 架构因素的识别和分析 所有的FURPS+需求对系统的架构都有重要影响，其中涉及可靠性，进度安排，技巧和成本约束等 具有架构意义的因素称为关键架构因素 质量场景 形如刺激可度量响应 当销售完成，调用远程税金计算器服务计算税金时，在平均负载条件的生产环境下，大部分会在2秒之内返回 当NextGen Beta测试的志愿者报告一个bug时，应在一个工作日内电话回复。 架构因素的描述方法 架构因素表 因素表与其它文档的关系 创建因素表时，用例、愿景和补充性规格说明是重要的灵感来源。 应该检查用例中的特殊需求、技术变动和未决问题等部分，并且将其中所包含的明显和隐含的框架因素合并于补充性规格说明之中。 NextGen架构分析的部分因素 收集和组织有关的架构性因素，称为架构的科学 依据相互依赖情况，优先级，权衡考虑等，做出解决这些因素的决定，称为架构的艺术 技术备忘录 建议使用技术备忘录、问题卡、架构途径文档等记录架构选择，决策以及动机 优先级 引导架构决策的目标：强制性约束，业务目标，所有其它目标 因素表中的优先级应该反应这些目标的优先级 架构决策的另一个重要特征是按进化点可能发生的频率区分优先级 基本的架构设计原则 我们已经介绍的原则都适用：低耦合，高内聚，防止变异 构件的粒度更大 不是对象之间的，而是应用程序、子系统或进程之间的。 关注分离 UP制品中的架构信息 架构性因素（例如在因素表中的因素）被记录在补充性规格说明中 架构性策略被记录在软件架构文档（SAD）中。 包含技术备忘录和架构视图的描述 UP各阶段中的架构 初始阶段： 如果不确定技术上是否可以满足架构性需求，开发团队可以实现一个架构概念验证原型来确定其可行性 细化阶段： 主要目标是实现核心的风险架构元素，因而，大部分的架构分析都在细化阶段完成。 移交阶段： 可能需要修订SAD以便确保与最终部署的系统一致。 后续进化循环 设计新版本之前，通常会重温架构性因素和决策。 第三十四章 逻辑架构的精化 34.1 示例：NextGen的逻辑架构 层之间和包之间的耦合 如果不关心确切的依赖方式（属性可见性、子类型等），仅仅想突出普通的依赖