资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,设计构架(1),1/25,简短回顾,在前几节课我们学习了,构架商业性方面,构架视图和结构,质量属性,实现质量属性构架战术和模式,这些组成了我们进行构架设计背景知识,生命周期中构架,设计构架,形成团体结构,创建骨架系统,2/25,软件生命周期,常见软件生命周期模型,瀑布模型,瀑布模型将软件生命周期各项活动要求为依固定次序联接若干阶段工作，形如瀑布流水，最终得到软件产品,演化模型,用户能够给出待开发系统关键需求，而且当看到关键需求实现后，能够有效地提出反馈，以支持系统最终设计和实现。,螺旋模型,瀑布模型与演化模型相结合，并加入二者所忽略风险分析所建立一个软件开发模型。,构架在软件生命周期中处于一个什么位置？,3/25,演化模型生命周期,软件概念,初步,需求分析,构架和,系统关键,设计,交付最,终版本,获取客,户反馈,开发一,个版本,汇总客,户反馈,交付,该版本,4/25,何时能够开始构架设计,首先要有需求,但我们并不需要太多需求来开始构架设计,形成构架原因包含,功效需求,质量需求,商业需求,这些需求我们成为构架驱动原因,比如：第三章案例中介绍A-7E航空电子系统可修改性和性能需求,第六章案例中空中交通管制系统可用性需求,5/25,决定构架驱动原因,识别构架驱动原因,识别最高优先级商业目标,应该只有几个,将这些商业目标转化为质量属性场景或,使用案例,从中选择对构架产生最大影响部分,这些就是构架驱动原因,应该不多于10个,使用案例是对一个系统所执行一系列动作描述，通常功效属性需求都能够由用户案例表示,6/25,属性驱动设计(ADD),ADD是一个设计软件构架方法，该方法依据软件质量属性需求对系统进行分解,一个递归分解过程,系统分解基于系统必须满足质量属性,每个阶段都选择战术和构架模式来满足一组质量属性场景，然后对功效进行分配，以实例化由该模块所提供模块类型,ADD结果：得到一个粗粒度划分，即模块分解视图和其它视图最初几个层次,系统被描述为功效和功效之间交互一组容器,7/25,案例分析车库门开关器(1),目标：为家庭信息系统(HIS)中车库门开关器设计一个产品线构架,开关器负责经过开关、远程控制或家庭信息系统来实现车门升起或下降,ADD输入：一组需求,使用用户案例表示功效需求,限制,使用质量属性场景表示质量需求,8/25,案例分析车库门开关器(2),车库门系统质量属性场景,对于产品线中各种产品而言，用于开门和关门设备和控制装置是不一样,不一样产品中使用处理器不一样,假如车库门在下降过程中检测到一个障碍物，它必须在0.1秒内停顿,能够在家庭信息系统内使用产品相关诊疗协议来诊疗和管理车库门开关器。因改能够直接产生一个反应该协议构架,9/25,ADD步骤,1.选择要分解模块,从整个系统开始,进行分解时，要求全部输入都是可取得,限制条件、功效需求、质量需求,2.依据这些步骤对模块进行求精,从详细质量场景和功效需求集合中选择构架驱动原因,选择或创建满足构架驱动原因构架模式，确定所用战术需要子模块,实例化模块并依据使用案例分配功效，使用多个视图进行表示,定义子模块接口,验证使用案例和质量场景并对其进行求精，使它们成为子模块限制,3.对需要深入分解每个模块重复上述步骤,10/25,选择要分解模块,系统分解步骤：系统子系统子模块,示例中，系统指是车库门开关器,在这个级别一个限制是：开关器必须能与家庭信息系统进行交互,11/25,2.a 选择构架驱动原因,进行分解时，需要从质量属性场景和功效需求中选择对应构架驱动原因,构架驱动原因在模块高优先级需求中,在车库门系统中，已给出,4,个场景就是构架驱动原因，它们给出了以下需求,可修改性,实时性能需求,ADD,特点在于，对于模块全部需求并非同等对待,经过选择构架驱动原因，我们将问题简化为满足最主要需求,在满足最主要需求条件下，才满足不太主要需求,12/25,选择构架模式(1),对于每个质量属性需求，在构架设计中，我们都有对应战术来实现它,每个战术都有对应成本,每个战术都能够实现一个或多个质量属性，不过也可能对一些质量属性产生负面影响,通常我们会在构架设计中选择战术组合来实现多个质量属性平衡,13/25,选择构架模式(2),该步骤目标是建立一个由模块类型组成总体构架模式,该模式经过组合选定战术，满足构架驱动原因,影响战术选择两个原因,驱动原因本身,实现战术模式对其它质量属性产生副作用,14/25,选择构架模式(3)-示例,比如：,为了达成系统可修改性，一个经典战术就是使用“解释器”模式,不过使用解释器模式会对性能产生较大负面影响,是否使用“解释器”模式依赖于可修改性与性能主要性对比,一个可行决议为：对总体模式部分使用“解释器”，其它部分则使用其它战术,15/25,选择构架模式(4),按照案例分析中所提到两个关键需求：性能和可修改性，我们能够使用学过响应战术来满足,可修改性战术回顾,局部化变更,预防连锁反应,推迟绑定时间,我们案例中，可修改性场景主要与系统设计时出现变更相关，所以我们能够使用“局部化变更”战术,所采取详细战术为：“语义一致性”和信息隐藏,16/25,选择构架模式(5),性能战术回顾,资源需求,提升计算效率,资源仲裁,优化调度算法,资源管理,不论是引入并发，还是维持数据或计算备份，还是增加可用资源，都无助于提升车库门响应速度,17/25,选择构架模式(6),最终选定和应用详细战术,语义一致性,将处理用户接口、通讯和传感器部分都放入各自单独模块,信息隐藏,为通讯和传感器模块使用“虚拟机”技术，隐藏内部实现,提升计算效率,提升关键部分（瓶颈）计算效率,精心调度,对关键性能计算进行调度，确保实时响应需求,18/25,应用了战术后导出模式,这并非唯一可导出模式,这是一个满足了需求模式,非关键性,能计算,虚拟机,关键性,能计算,用户界面,确保时限时间,调度程序,选择构架模式(7),19/25,实例化模块(1),前面步骤确定了模块分解结构，接下来要确定怎样实例化这些模块类型,在ADD方法中，功效分配标准类似于其它设计方法,实际系统中往往有多个模块，每组功效都会有一个模块,模块功效实例化,升/降门（没有时限，非关键性能计算）,诊疗（非关键性能计算）,障碍物检测（有时限，关键性能计算）,通信、传感等（有可修改性需求，使用“虚拟机”技术）,20/25,实例化模块(2),诊疗,通讯虚拟机,障碍物检测,用户接口,确保时限时间,调度程序,升/降门,传感器/启发器,虚拟机,21/25,分配功效,(1),该步骤目标是验证现有分解时限所要求功效,预防功效遗漏,应用与父模块相关用例能够让构架师更详细了解功效分布情况,可能造成增加或删除子模块,父模块每个用例都可用子模块一系列责任来表示,22/25,分配功效,(2),为分解模块中子模块分配责任还会帮助发觉必要信息交换,这必须作为生产者/消费者关系统计下来,信息交互细节在这一步并不主要,一些交互将引入模块间交互特定模式,比如：公布/订阅模式,必须统计这些模式，对于受影响模块而言，它们将转化为责任,23/25,用多个视图表示构架(1),通常使用三种主要视图类型中，每种选择一个视图来表示构架（假如这些视图表示还不足够怎么办？）,模块分解视图,为责任提供容器；确定模块间主要数据流关系,并发视图,确定资源竞争、可能出现死锁和数据一致性问题,可能会发觉模块新责任,比如对临界资源并发访问,必须在模块视图中对这个新责任进行统计,可能造成新模块产生,比如：一个资源管理器,24/25,用多个视图表示构架(2),了解车库门系统中并发，要考虑以下用例,两个用户同时做类似事情（用HIS关门，用开关关门）,识别资源竞争或数据完整性问题,一个用户同时执行多个活动,揭示数据交换和活动控制问题,开启系统,提供系统初始化策略和概述,关闭系统,揭示系统去除（关机）问题,布署视图,确定布署到特定硬件上出现特殊责任,确定是否需要一些模块多个实例,25/25,
展开阅读全文
浙ICP备2021020529号-1 | 浙B2-20240490 
