05_架构分析.ppt

Mastering OOAD - Instructor Notes Module 5 - Architectural Analysis 目标：架构分析 解释架构分析的目的以及在生命周期的那个阶段执行 描述典型的架构模式和分析机制集合，以及他们如何影响架构 描述支持架构决策的原理和考虑 展示如何阅读并解释架构分析的结果： 架构层和他们的关系 关键抽象 分析机制 架构分析上下文场景 架构分析概览 架构分析步骤 关键概念 定义高层模型结构 识别分析机制 识别关键抽象 创建用例实现 检查点 复习：什么是架构？模型的“4+1”视图 复习：什么是包？ 包是将元素组织到一组的一种多用途机制 他是能包含其他模型元素的模型元素 包可用于 为开发组织模型 作为一个配置管理单元来管理 包关系：依赖 包能通过依赖关系相互关联 依赖隐含着： 改变供应商包可能影响客户包 客户包不能被独立重用因为它依赖供应商包 避免循环依赖 架构分析步骤 关键概念 定义高层模型结构 识别分析机制 识别关键抽象 创建用例实现 检查点 模式和框架 模式 就一个具备上下文场景的通用问题提供一个通用的解决方案 分析/设计模式 提供一个方案来缩小技术问题的范围 是方案或问题的局部或片段 框架 定义了解决问题的通用方法 提供一个框架性方案，该方案细化下来可能就是分析/设计模式 什么是设计模式？ 设计模式是针对普遍的设计问题的一种解 描述了一个常见的设计问题　 给出了该问题的解决方案　 讨论了运用模式后的结果 设计模式提供了重用成功设计的能力 什么是架构模式？ 架构模式表达了一个基础性的软件系统的组织结构。提供一组预定义子系统，并详述他们的职责、规则及他们之间关系的指南 　– Buschman et al, “面向软件架构的模式 — 系统模式” 分层 M-V-C 管道和过滤器　 黑板 典型的分层方法 举例：层 分层考虑 抽象层次 在同一个抽象层次的元素组 关注点分离 相似事物分组到一起 分离完全不同的事物 应用 vs. 领域模型元素 灵活性 松散耦合　 关注对变化的封装 用户接口，业务规则和保留的数据很可能有潜在的变更 架构层建模 架构层用包的构造型来表述 层 构造型 什么是构造型 构造型是指根据一个模型元素来定义一个新的模型元素 有时候，你需要在当前领域中引入一个新的事物，看起来非常像已有的某个主要构建块 举例：模型高层组织 架构分析步骤 关键概念 定义高层模型结构 识别分析机制 识别关键抽象 创建用例实现 检查点 什么是架构机制？ 架构机制：三类 架构机制分类 分析机制 (概念) 设计机制(具体) 实现机制 (实际) 为什么用分析机制？ 分析机制举例 持久化 通信 (IPC and RPC) 消息路由 分布式 交易管理 流程控制和同步(资源争用) 信息交换, 格式转换 安全 错误的检测 / 处理 / 报告 冗余 遗留系统接口 分析机制特性举例 持久化机制 粒度 数据量 持续时间 访问机制 访问频率 (增 \ 删 \ 改 \ 读) 可靠性 进程间通信机制 等待时间 同步性 消息大小 协议 分析机制特性举例 遗留系统接口机制 等待时间 持续时间 访问机制 访问频度 安全机制 数据粒度 用户粒度 安全规则 授权类型 其他 分析机制描述 收集所有分析机制列成一个列表 画出类到机制的映射 识别分析机制的特性 用协作机制来对其建模 举例：课程注册分析机制 架构分析步骤 关键概念 定义高层模型结构 识别分析机制 识别关键抽象 创建用例实现 检查点 什么是关键抽象？ 关键抽象是一个概念，通常并不被需求覆盖，但系统必须要能处理它 关键抽象的来源 定义关键抽象 定义分析类 在类图中对分析类和关系建模 包括对分析类的一个概要描述 将分析类映射到必须的分析机制上 举例：关键抽象 复习：什么用例实现? 用例实现的价值 提供从分析涉及到需求的跟踪 架构师创建用例实现 检查点 通常 包是否已经在一个逻辑一致的方式下被再组织和分层？ 是否已经有一些必须的分析机制被识别出来了？ 包 我们是否提供了在高层次上的一个完整的包相互服务的大图? 检查点 (继续) 类 是否已经将关键的类及其关系识别出来并精确的模型化了？ 是否每个类的名字都能清晰反映其责任？ 关键抽象及其关系是否和业务模型、领域模型、需求、术语表等一致？ 复习: 架构分析 什么是架构分析的目的？ 什么是包？ 什么是分层的架构？给出一个典型的分层例子 什么是分析机制？给出例子. 什么是在架构分析期间识别的关键抽象？为什么要在这里识别它们？ 练习: 架构分析 已给定如下内容: 需求规程的的一些产出: (练习本: Payroll 需求) 问题描述 用例模型图 术语表 一些架构决策: (