软件体系结构9、设计软件体系结构1.pptVIP

选择的战术 语义一致性和信息隐藏 用单独的模块来处理用户接口、通信和传感器，使用虚拟机战术 将与诊断相关的责任分离开 提高计算效率 应该使关键性能计算尽可能的高效 精心调度 应该对关键性能计算进行调度， 以确保时间紧迫的任务的实现 利用选择的Tactics形成的架构模式 这不是唯一可以导出的模式，但看上去是个似乎合理的模式 (2.C)实例化模块并使用多个视图分配功能 (2.c). 实例化模块并根据用例分配功能，使用多个视图进行表示。 关键性能计算 障碍物检测 非关键性能计算部分 升降门管理 诊断 虚拟机部分 传感器/激励器 通信 系统的第一次分解 验证该分解实现所要求的功能情况 主要使用分解视图 父模块的每个用例都必须可以用一个或多个子模块的责任以及相关子模块间的一系列交互来表示 使用与父模块相关的用例来进行分析和验证，有助于设计师更详细地了解功能的分布情况 有可能导致增加或删除子模块，以实现所要求的功能 用例举例：用户通过开关开门 用户接口 升降门 传激器 按开关 用户 开门请求 开门请求 模块之间的接口 子模块之间的交互意味着子模块间必要的信息交换，这在子模块之间产生了一个生产者和消费者关系 这里只对信息本身、其生产者消费者角色以及生产者、消费者之间的交互模式（如使用发布－订阅）感兴趣 对交互方式不感兴趣（设计后期需要解决的问题） 是否对信息进行推或拉？是否将其作为消息或者调用参数传递？ 验证该分解对质量属性的支持情况 为了检查是否满足了期望的质量属性，还需要动态的和运行时的部署信息对质量属性的实现进行分析 并发视图 部署视图 并发视图概述 并发视图是CC视图中的一种风格，其组件是模块分解视图中的模块的实例，连接器是“虚拟线程”的载体 虚拟线程描述了系统的一部分的执行路径 虚拟线程间的同步点位于一个特定的模块中，以便在该模块的适当部分分配该责任 在详细设计期间，需要将虚拟线程映射到操作系统线程 一种并发视图例 并发视图的作用 并发视图能为系统的动态方面（如并行活动和同步）建模，以助于确定资源争用问题、可能出现的死锁情况、数据一致性问题等 对系统中的并发性建模很可能会发现模块的新责任，这记录在模块视图中，它还可能导致新模块的产生，如资源管理器，以解决对稀少资源的并发访问 分析并发性而选择的用例 本例通过下面几个用例对系统的并发性进行分析： 两个用户同时做类似的事情 一个用户同时执行多个活动 启动系统 关闭系统 两个用户同时做类似的事情 有助于识别资源争用或数据完整性问题 在车库门例中，一个用户可能在远程关门，另一个用户在用开关开门 并发视图 用户接口 升降门 传激器 通信 按开关 用户 开门请求 开门请求 家庭信息 系统 关门请求 关门请求 关门请求 线程2的 踪迹 线程1的 踪迹 可能的 同步点 可能的 同步点 一个用户同时执行多个活动 有助于揭示数据交换和活动控制问题 在车库门系统中， 一个用户可以在执行诊断的同时开门 并发视图 通信 升降门 传激器 诊断 按开关 开门请求 开门请求 家庭信息 系统 诊断请求 诊断请求 线程2的 踪迹 线程1的 踪迹 可能的 同步点 可能的 同步点 诊断请求 可能的 同步点 启动系统 为系统中永久运行的活动以及如何初始化它们提供了一个良好的概述 还有助于确定初始化策略，如所有一切都并行，所有的一切都串行或其它的模型 车库门系统的启动问题1 问题1：车库门系统总是处于工作状态，还是在请求到来的时候启动，处理完相应的请求后停止？ 如果系统在请求到来的时候启动，那么有哪些可能需要启动系统的请求呢？ 用户按开、关控制按钮； 用户远程开、关门 用户远程通过家庭信息系统对车库门系统进行诊断 上述三类请求到来时是否适于启动系统？考虑： 实现的难度：处于停止状态的系统怎么捕捉请求？ 响应速度 比较合理的选择可能是：车库门系统总是处于工作状态 但是，如果这个软件系统坏了，难道车库门就没有办法开关了？ 这两个是绑定的 车库门系统的启动问题2 问题2：系统中有哪些永久的活动？ 永久的活动类似于守护进程(daemon)的概念，它能一直运行，以监听某个事件的到来并进行相应的处理。 可以一个进程为单位进行活动 可以一个线程为单位进行活动，这时，一个进程空间内可以有多个并行的永久活动，监听不同的端口或事件 一个系统的启动实际上主要就是为了启动这些永久活动，使其处于活动状态，以便监听相应的事件。 车库门系统需要的永久活动 监听通信信道的活动 监听用户按开、关按钮的事件的活动 车库门系统的启动问题3 问题3：车库门系统的启动是否依赖于家庭信息系统的可用性？ 车库门开关系统是家庭信息系统的一个部分 应该依赖？ 家庭信息系统不可用的时候，门就不能开关了？ 是两个相对独立的系统，因此不应该相互依赖 车库门系