52浙江大学王灿《软件体系结构》视频课程PPT7_构架设计案例(1).ppt

1、设计构架 (1),简短回顾,在前几节课我们学习了 构架的商业性方面 构架视图和结构 质量属性 实现质量属性的构架战术和模式 这些构成了我们进行构架设计的背景知识 生命周期中的构架 设计构架 形成团队结构 创建骨架系统,软件生命周期,常见的软件生命周期模型 瀑布模型 瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作，形如瀑布流水，最终得到软件产品 演化模型 用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。 螺旋模型 瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。 构架在软件生命周期中处于

2、一个什么位置？,演化模型生命周期,软件概念,初步的 需求分析,构架和 系统核心 的设计,交付最 终版本,获取客 户反馈,开发一 个版本,汇总客 户反馈,交付 该版本,何时可以开始构架设计,首先要有需求 但我们并不需要太多的需求来开始构架设计 形成构架的因素包括 功能需求 质量需求 商业需求 这些需求我们成为构架驱动因素 例如：第三章案例中介绍的A-7E航空电子系统的可修改性和性能需求 第六章案例中的空中交通管制系统的可用性需求,决定构架驱动因素,识别构架驱动因素 识别最高优先级的商业目标 应该只有几个 将这些商业目标转化为质量属性场景或使用案例 从中选择对构架产生最大影响的部分 这些就是构架驱

3、动因素 应该不多于10个,使用案例是对一个系统所执行的一系列动作的描述，通常功能属性的需求都可以由用户案例表达,属性驱动的设计 (ADD),ADD是一种设计软件构架的方法，该方法根据软件的质量属性需求对系统进行分解 一个递归的分解过程 系统分解基于系统必须满足的质量属性 每个阶段都选择战术和构架模式来满足一组质量属性的场景，然后对功能进行分配，以实例化由该模块所提供的模块类型 ADD结果：得到一种粗粒度的划分，即模块分解视图和其他视图的最初的几个层次 系统被描述为功能和功能之间交互的一组容器,案例分析车库门开关器 (1),目标：为家庭信息系统(HIS)中的车库门开关器设计一个产品线构架 开关器

4、负责通过开关、远程控制或家庭信息系统来实现车门的升起或下降 ADD的输入：一组需求 使用用户案例表达的功能需求 限制 使用质量属性场景表达的质量需求,案例分析车库门开关器 (2),车库门系统的质量属性场景 对于产品线中的各种产品而言，用于开门和关门的设备和控制装置是不同的 不同的产品中使用的处理器不同 如果车库门在下降的过程中检测到一个障碍物，它必须在0.1秒内停止 可以在家庭信息系统内使用产品相关的诊断协议来诊断和管理车库门开关器。因改可以直接产生一个反应该协议的构架,ADD步骤,1. 选择要分解的模块 从整个系统开始 进行分解时，要求所有输入都是可获得的 限制条件、功能需求、质量需求 2.

5、 根据这些步骤对模块进行求精 从具体的质量场景和功能需求集合中选择构架驱动因素 选择或创建满足构架驱动因素的构架模式，确定所用战术需要的子模块 实例化模块并根据使用案例分配功能，使用多个视图进行表示 定义子模块的接口 验证使用案例和质量场景并对其进行求精，使它们成为子模块的限制 3. 对需要进一步分解的每个模块重复上述步骤,选择要分解的模块,系统分解的步骤：系统子系统子模块 示例中，系统指的是车库门开关器 在这个级别的一个限制是：开关器必须能与家庭信息系统进行交互,2.a 选择构架驱动因素,进行分解时，需要从质量属性场景和功能需求中选择相应的构架驱动因素 构架驱动因素在模块的高优先级需求中 在

6、车库门系统中，已给出的4个场景就是构架驱动因素，它们给出了以下需求 可修改性 实时性能需求 ADD的特点在于，对于模块的所有需求并非同等对待 通过选择构架驱动因素，我们将问题简化为满足最重要的需求 在满足最重要的需求的条件下，才满足不太重要的需求,选择构架模式 (1),对于每个质量属性的需求，在构架设计中，我们都有相应的战术来实现它 每个战术都有相应的成本 每个战术都可以实现一个或多个质量属性，但是也可能对一些质量属性产生负面的影响 通常我们会在构架设计中选择战术的组合来实现多个质量属性的平衡,选择构架模式 (2),该步骤的目标是建立一个由模块类型组成的总体构架模式 该模式通过组合选定的战术，

7、满足构架驱动因素 影响战术选择的两个因素 驱动因素本身 实现战术的模式对其他质量属性产生的副作用,选择构架模式 (3)-示例,比如： 为了达成系统的可修改性，一个经典的战术就是使用“解释器”模式 但是使用解释器模式会对性能产生较大的负面影响 是否使用“解释器”模式依赖于可修改性与性能的重要性对比 一个可行的决策为：对总体模式的部分使用“解释器”，其他部分则使用其他战术,选择构架模式 (4),按照案例分析中所提到的两个关键需求：性能和可修改性，我们可以使用学过的响应战术来满足 可修改性战术回顾 局部化变更 防止连锁反应 推迟绑定时间 我们的案例中，可修改性场景主要与系统设计时出现的变更相关，因此

8、我们可以使用“局部化变更”战术 所采用的具体战术为：“语义一致性”和信息隐藏,选择构架模式 (5),性能战术回顾 资源需求 提高计算效率 资源仲裁 优化调度算法 资源管理 无论是引入并发，还是维持数据或计算的备份，还是增加可用资源，都无助于提高车库门的响应速度,选择构架模式 (6),最后选定和应用的具体战术 语义一致性 将处理用户接口、通讯和传感器的部分都放入各自单独的模块 信息隐藏 为通讯和传感器模块使用“虚拟机”技术，隐藏内部实现 提高计算效率 提高关键部分（瓶颈）的计算效率 精心调度 对关键性能计算进行调度，确保实时响应需求,应用了战术后导出的模式 这并非唯一可导出模式 这是一个满足了需

9、求的模式,非关键性 能计算,虚拟机,关键性 能计算,用户界面,保证时限时间 的调度程序,选择构架模式 (7),实例化模块 (1),前面的步骤确定了模块的分解结构，接下来要确定如何实例化这些模块类型 在ADD方法中，功能的分配标准类似于其他设计方法 实际的系统中往往有多个模块，每组功能都会有一个模块 模块功能实例化 升/降门（没有时限，非关键性能计算） 诊断（非关键性能计算） 障碍物检测（有时限，关键性能计算） 通信、传感等（有可修改性需求，使用“虚拟机”技术）,实例化模块 (2),诊断,通讯虚拟机,障碍物检测,用户接口,保证时限时间 的调度程序,升/降门,传感器/启发器 虚拟机,分配功能 (1

10、),该步骤的目的是验证现有的分解时限所要求的功能 防止功能的遗漏 应用与父模块相关的用例可以让构架师更详细的了解功能的分布情况 可能导致增加或删除子模块 父模块的每个用例都可用子模块的一系列责任来表示,分配功能 (2),为分解模块中的子模块分配责任还会帮助发现必要的信息交换 这必须作为生产者/消费者关系记录下来 信息交互的细节在这一步并不重要 一些交互将引入模块间交互的特定模式 比如：发布/订阅模式 必须记录这些模式，对于受影响的模块而言，它们将转化为责任,用多个视图表示构架 (1),通常使用三种主要的视图类型中，每种选择一个视图来表示构架（如果这些视图的表示还不足够怎么办？） 模块分解视图 为责任提供容器；确定模块间的主要数据流关系 并发视图 确定资源竞争、可能出现的死锁和数据一致性问题 可能会发现模块的新责任 比如对临界资源的并发访问 必须在模块视图中对这个新责任进行记录 可能导致新模块的产生 比如：一个资源管理器,用多个视图表示构架 (2),理