软件构架考试复习提纲及答案

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

(3)、性能(Performance) 性能与事件发生时,将要耗费系统多长时间做出响应有关。影响性能的因素包括:事件 源的数量和达到模式,到达系统的事件包括:周期性事件、随机事件或偶然事件。 性能的一般性场景: 场景部分 刺激源 刺激 制品 环境 响应 相应度量 正常模式;超载模式 处理刺激;改变服务级别 等待时间、时间期限、吞吐量、抖动、缺失率、数据丢失 可用的值 大量独立源中的一个,可能来自系统内部 定期、随机或偶然事件到达




ISSS 系统的质量属性要求: (1)极高的可用性:保证系统不能正常工作的状态只延续极短的时间(全年 5 分钟) (2)高性能:系统必须在不“丢失”任何数据的情况下对大量数据(2440 架飞机)进行处 理 其他需求:1、开放性:系统必须能够与按商业运作开发出来的其它软件进行集成,比 如航图显示系统,2、可提交的子系统,3、能够更改功能和处理软硬件的升级,4、能 够与众多的外部系统相接并协同工作 为了实现 A TC 系统极高的可用性,在构架中大量的采样了冗余战术,包括硬件冗余和 软件冗余。 为了实现高性能,采用了并发和资源调度等战术。
授权或非授权用户;访问了有限的资源/大量资源 试图修改数据,访问系统服务 系统服务、系统中的数据 在线或离线、直接或通过防火墙入网 对用户验证,阻止或允许访问数据或服务 避开安全措施所需要的时间或资源;恢复数据/服务
(5)、可测试性(Testability)——可测试性是指通过测试揭示软件缺陷的容易程度。 如果要对系统进行正确的测试,那么必须能够“控制”每个组件的内部状态及其输入,然 后“观察”其输出, 测试可以由开发人员、 测试人员、 验证人员或用户进行; 可以对代码、 设计以及整个系统进行测试。 可测试性的一般性场景 场景部分 刺激源 刺激 制品 环境 响应 相应度量 可用的值 单元开发人员、系统集成人员、系统验证人员、测试人员、用户 已完成的一个阶段,如分析、构架、类和子系统的集成,所交付 的系统 设计、代码段、完整的应用 设计时、开发时、编译时、部署时 可以控制系统执行所期望的测试 已执行的可执行语句的百分比;最长测试链的长度,执行测试的 时间,准备测试环境的时间

消息到达、定时器到时,系统状态的变化。性能战术包括 3 个分类:
试的目标是发现错误
一些重要的概念:连锁反应,接口等
连锁反应(ripple effects)——修改某个模块却影响到其他并没有被修改的模块, 我们必须修改所有相关模块(直接影响和间接影响)才能够实现我们的变更目标 接口是两个独立的实体相遇并进行交互或通信的边界 第六章 空中交通管制 1. 本节讨论的构架为初始区段组系统(Initial Sector Suite System, ISSS ) ,它是对美国 22 个中途中心的软硬件升级系统。
(2)、可修改性(Modifiability)关于变更的成本问题,可修改性包括两个关注点: a、可以修改什么?如修改系统功能、系统运行的平台和环境、系统容量、质量属性等 b、何时进行变更以及由谁进行变更?修改时间包括设计时修改(源代码) 、编译时修改(编 译条件) ,部署时修改(系统配置)等。 刺激源 刺激 制品 环境 响应 响应度量 用户,开发人员,管理员 希望增加/删除/改变功能 用户界面,平台,环境 运行时;编译时;构建时;设计时 查找修改位置,进行修改不影响其他功能,对修改进行测试 时间成本
分为 3 组:
限制暴露的信息、限制访问。 检测攻击:入侵检测。 从攻击中恢复:恢复→查看可用性,识别→审计追踪。 5. 实现性能的战术?性能(Performance) 性能战术的目标是对一定的时间限制内到达系统的事件生成一个响应,这些事件可以使 1、资源需求——分析影响性能的资源因素 战术:提高计算效率、减少计算开销、管理事件率、控制采样频率。 2、资源管理——提高资源的应用效率 战术:引入并发、维持数据或计算的多个副本、增加可用资源。 3、资源仲裁——解决资源的争用 战术:调度策略:先进先出、固定优先级调度、动态优先级调度、静态调度。 6. 实现可测试的战术?可测试性(Testability) 可测试性战术的目标是允许在完成软件开发的一个增量后,轻松地对软件进行测试。测 输入/输出:记录/回放、将接口与实现分离、特化访问路线/接口。 内部监视:内置监视器。 7. 实现易用性的战术? 易用性与用户完成期望任务的难易程度以及系统为用户提供的支持种类有关 分离用户接口: 。 支持用户主动:取消、撤销、聚合 用户模型:用户模型、系统模型、任务模型。 8.
第七章 设计构架
1.
什么是属性驱动因素?
功能、质量和商业需求的某个集合塑造了构架。我们把这些塑造需求称为构架驱动因素 2. ADD 构架设计方法(属性驱动的设计方法(Attribute Driven Design, ADD)) 该方法可以用于设计一个满足一定质量需求和功能需求的构架 ADD 把一组质量属性场景作为输入,并使用对质量属性实现和构架之间的关系的了解, 对构架进行设计。ADD 设计的结果是构架的模块分解视图和其他视图的最初几个层次。 第九章 构架编档 我们需要对软件构架中的每一个视图进行编档,每个编档视图通常包含 7 部分的内容: 1、展示视图中的元素和元素间关系的主要表示 2、使用元素目录描述在主要表示中所描述的元素和他们之间的关系及其他。在这一部 分内容中我们将对元素的行为和元素接口进行描述 3、展示在视图中描述的系统的环境相关上下文 4、可变性指南展示了如何应用该视图中所展示的构架的一部分的任何变化点,应该包 含每个变化点的文档 5、解释视图中所反映的设计合理性的构架背景,包括:基本原理,分析结果,设计中 所反映的假定 6、视图中所使用的术语表 7、其他信息,如管理信息等 第十一章 ATAM 1. ATAM 的参与人员(评估小组组成,项目决策人和涉众) ATAM 要求以下 3 个小组的参与和合作: (1) 评估小组:该小组是所评估构架项目外部的小组,通常由 3~5 人组成。该小组的每 个成员都要扮演大量的特定角色。 他们可能是开发组织内部的, 也可能是外部的。 任何时候, 他们都应该是有能力、没有偏见而且私下没有其他工作要做的人员 评估小组包括如下角色的人员:评估小组负责人,评估负责人,场景书记员,进展书 记员,计时员,过程观察员,过程监督者,提问者等 (2) 项目决策者对开发项目具有发言权,并有权要求进行某些改变,他们包括项目管理 人员,重要的客户代表,构架设计师等。 构架评估的一个基本准则就是构架设计师必须愿意参与评估 (3)构架涉众完成工作的能力与支持可修改性、安全性、高可靠性等特性的构架密切相 关。包括:开发人员、测试人员、集成人员、用户等 ATAM 的评估过程可以分为 4 个阶段: 1.评估准备阶段 2.部分评估阶段 3.全体评估阶段 4.评估后续阶段 2.ATAM 评估的具体步骤包括以下八步: 1) 、由评估负责人向参加会议的项目代表介绍 ATAM 评估方法,在这一步,要说明每 个人将参与的过程,回答提出的问题,并为其他活动确定上下文和期望 2) 、项目决策者从商业的角度介绍系统的概况,包括:系统最重要的功能;任何相关 的技术、 管理、 经济和政治限制; 与项目相关的商业目标和上下文; 主要的涉众; 构架的驱动因素(主要质量属性目标)等 3) 、设计师使用各种视图来介绍构架 的本质,促使形成构架的需求,构架受到的技术约束条件,以及系统与之交互的 系统,构架方法、模式,采用的战术等 4) 、ATAM 评估主要通过理解其构架方法来分析构架 5) 、 使用质量属性效用树对质量目标进行详细清晰地阐述。 效用树的作用是使质量属
第四章 理解质量属性 我们开发一个系统是为了给用户使用,因此系统的质量好坏最终要由用户来评判。评判 的依据: (1)、系统是否能够满足客户的功能需求(直接) (2)、系统是否能够满足一定的质量需求(间接,长期的影响) 功能性(functionality)是指系统能够完成所期望的工作的能力 质量属性(quality attributes )是高于系统功能基本要求的,它是对多种更高层次需求的 抽象描述,如安全、可靠、易用及易于修改等,显然它适用于多个特定系统而非一个。 1. 2. 什么是质量属性场景(比如可用性的一般场景表示) 质量属性场景由以下 6 个部分组成: (1) 刺激源(Source of stimulus) :生成刺激的实体(人、计算机或其他) (2) 刺激(Stimulus) :当刺激源产生的刺激达到系统后需要考虑的条件,或指可能对系 统的影响 (3) 环境(Environment) :刺激到达时系统的状态,或指刺激在系统的某些条件内发生 (4) 制品(Artifact) :被刺激的部分,可能是整个系统,也可能是其中的一部分 (5) 响应(Response) :刺激到达后系统所采取的措施 (6) 响应度量(Response measure) :当响应发生时,我们以某种方式对其进行度量,便 于我们对需求进行测试 (1)、可用性(Availability) 可用性与系统故障及其相关后果有关。当系统不再提供其规范中所说明的服务时,就出 现了系统故障。可用性关注的问题:如何检测故障,发生故障的频度,出现故障时的现象, 系统故障排除的时限,如何防止故障的发生以及发生故障时的处理 可用性的表示 场景部分 刺激源 刺激 制品 环境 响应 响应度量 可能的值 系统内部、外部 错误:疏忽、崩溃、时间、响应 系统的处理器、通信通道、持久性存储器、进程 正常、降级模式 系统检测到事件,进行以下活动之一记录故障,通知用户或系统;根据已 定义的规则禁止故障源等 系统修复时间,系统可以在降级模式下运行的时间间隔等 质量属性场景(scenarios 是描述质量属性的手段,是一种面向特定的质量属性的需求
(4)、安全性(Security) 安全性是衡量系统在向合法用户提供服务的同时,阻止非授权使用的能力 安全性被刻画为一个提供认可(交易不能被交易的任何一方拒绝) 、机密性(未经授权 不能访问数据或服务) 、完整性(根据计划来提交数据或服务) 、保证(交易各方是所声 称的人) 、可用性(系统可用于合法用途)和审核(在系统内部跟踪系统活动)的系统 安全性的一般性场景: 场景部分 刺激源 刺激 制品 环境 响应 相应度量 可用的值
第1章 1.1 构架的产生 答:构架是若干商业和技术决策的结果 构架开发的影响因素 答:系统涉众、开发组织、设计师的素质和经验、技术环境 软件构架是技术、 商业和社会诸多因素作用的结果, 而软件构架的存在反过来又会影响技术、 商业和社会环境, 从而影响到未来的构架。 我们把这种相互影响的周期——从环境到构架又 返回环境称为构架商业周期 构架活动包括 答:为系统创建构架商业案例; 理解需求; 创建或选择构架; 构架的交流; 构架的分析和评价; 实现基于该构架的系统; 使构架符合原来的表述; 第二章 1. 理解软件构架,构架模式的定义 构架模式——以一种方式对战术打包; 是对元素、关系类型、一组对其使用方法的限制的描述; 看作是对构架的一组制约条件——即对各元素类型及其交互模式的限制条件; 参考模型——是一种考虑数据流的功能划分,它对已知问题进行分解,分解得到的各个 部分相互协作,构成问题的解决方案 参考构架——是映射到软件元素及元素之间数据流上的参考模型 2. 软件构架重要性的原因 软件构架对于一个系统而言,具有极其重要的意义,包括: (1)、软件构架是涉众之间交流的手段 (2)、软件构架是系统的早期设计决策 (3)、软件构架是可传递的系统抽象 3. 三种构架结构及其详细分类 我们使用视图和结构来表示系统的构架,构架结构根据元素的主要特性可以分为三类: 模块结构:元素是模块,它们是实现单元,模块表示一种考虑系统的基于代码的方法; 组件连接器结构:元素是运行时组件和连接器; 分配结构:展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间 的关系; 模块包括:分解、使用、分层、类或泛化。 组件连接器结构包括:进程或通信进程、并发、共享数据或存储库、客户机/服务器。 分配结构包括如下内容:部署、实现、工作分配。 第三章 A-7E 航空电子系统 1.A-7E 软件所满足的质量目标包括: (1)实时性能,软件系统每秒钟显示内容的更新次数和武器投放的计算速度 (2)针对期望更改的可修改性,对武器、平台、显示屏上符号的变更,以及通过键盘数据新 的内容容易更改
(6)、易用性(Usability) 易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持种 类。包括如下几个方面:1、学习系统的特性,2、有效地使用系统,提高用户操作效率,
3、将错误的影响降到最低,4、使系统适应用户的需要,5、提高自信和满意度。 易用性的一般性场景 场景部分 刺激源 刺激 制品 环境 响应 相应度量 最终用户 想要学习系统特性、有效使用系统、使错误的影响最低,适配系 统等 系统 在运行时或配置时 上下文相关的帮助系统,导航,撤销、取消操作,从系统故障中 恢复,国际化,Βιβλιοθήκη Baidu制能力 任务时间,错误数量,用户满意度等 可用的值
第五章 实现质量属性 1.

什么是战术? 战术(tactics )——影响质量属性响应的设计决策 构架策略(architectural strategy)——战术的集合 构架模式(architectural pattern)——以某种方式将战术打包在一起 实现可用性的战术? 可用性(Availability)
2.
可用性战术将会阻止错误发展为故障,或者至少能够把错误的影响限制在一定范围内, 从而使修改成为可能。维持可用性的战术包括: (1)、错误检测——命令/响应、心跳、异常。 (2)、错误恢复——准备恢复:表决、主动冗余(热启动) 、被动冗余(暖重启/ 双冗余/ 三冗余) 、备件。重新引入:shadow 操作、状态再同步、检查点/回滚。 (3)、错误预防——从服务中删除、事务、进程监视器。 3. 实现可修改性的战术?可修改性(Modifiability) 可修改性战术的目标是控制实现、测试和部署变更的时间和成本。根据其实现目标可以 1、局部化修改——目标是减少由某个变更直接影响的模块的数量 战术:维持语义的一致性、预期期望的变更、泛化该模块、限制可能的选择、抽象通用 服务。 2、防止连锁反应——目标是限制对局部化的模块的修改,以防止对某个模块的修改间 接地影响到其他模块 战术:隐藏信息、维持现有接口、限制通信路径、使用仲裁者。 3、延迟绑定时间——目标是控制部署时间并允许非开发人员进行修改 战术:运行时注册、配置文件、多态、组件更换、遵守已定义的协议。 4. 实现安全性的战术?安全性(Security) 安全性战术包括抵抗攻击的战术、检测攻击的战术和从攻击从恢复的战术 抵抗攻击:对用户进行身份验证、对用户进行授权、维护数据的机密性、维护完整性、
相关文档
最新文档