架构权衡分析方法（Architecture Tradeoff Analysis MethodATAM)是一种系统架构评估方..

免费智能真题库 > 历年试卷 > 系统架构设计师 > 2013年下半年系统架构设计师上午试卷综合知识

第57题

知识点： ATAM评估方法软件架构安全性调试架构设计排序评估系统架构

关键词： Windows 安全接口开发可修改性排序权衡分析软件架构系统架构需求章/节：软件架构评估

架构权衡分析方法（Architecture Tradeoff Analysis Method,ATAM)是一种系统架构评估方法，主要在系统开发之前，针对性能、(57)、安全性和可修改性等质量属性进行评价和折中。ATAM可以分为4个主要的活动阶段，包括需求收集、(58)描述、属性模型构造和分析、架构决策与折中，整个评估过程强调以（59)作为架构评估的核心概念。
某软件公司采用ATAM进行软件架构评估，在评估过程中识别出了多个关于质量属性的描述。其中，“系统在进行文件保存操作时，应该与Windows系统的操作方式保持一致”主要与（60)质量属性相关;“系统应该提供一个开放的API接口，支持远程对系统的行为进行控制与调试”主要与(61)质量属性相关。在识别出上述描述后，通常采用（62)对质量属性的描述进行刻画与排序。在评估过程中，(63)是一个会影响多个质量属性的架构设计决策。

A. 可测试性

B. 可移植性

C. 可用性

D. 易用性

相关试题：软件架构评估

更多>

第60题 2014年下半年

63%

识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。“改变业务数据编码方式会对系统的性能和安全性产生影响&..

第63题 2012年下半年

57%

基于场景的架构分析方法（Scenarios-based Architecture Analysis Method，SAAM)是卡耐基梅隆大学软件工程研究所的Kazman等人于1..

第59题 2013年下半年

58%

架构权衡分析方法（Architecture Tradeoff Analysis Method,ATAM)是一种系统架构评估方法，主要在系统开发之前，针对性能、(57)、..


知识点讲解
· ATAM评估方法 · 软件架构 · 安全性 · 调试 · 架构设计 · 排序 · 评估 · 系统架构

ATAM评估方法

使用ATAM方法对软件架构进行评估的目标，是理解架构关于软件的质量属性需求决策的结果。ATAM方法不但揭示了架构如何满足特定的质量目标（如性能和可修改性），而且还提供了这些质量目标是如何交互的，即它们之间是如何权衡的。这些设计决策很重要，一直会影响到整个软件生命周期，并且在软件实现后很难以修改这些决策。

ATAM评估的步骤

整个ATAM评估过程包括9个步骤：

（1）描述ATAM方法。评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。在这一步，要解释每个人将要参与的过程，并预留出解答疑问的时间，设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息，如何描述这些信息，将要向谁报告等。

（2）描述业务动机。参加评估的所有人员必须理解待评估的系统，在这一步，项目经理要从业务角度介绍系统的概况。

（3）描述架构。首席架构设计师或设计小组要对架构进行详略适当的介绍。这一步很重要，将直接影响到可能要做的分析及分析的质量。在进行更详细的分析之前，评估小组通常需要收集和记录一些额外的架构信息。

（4）确定架构方法。ATAM评估方法主要通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法，由分析小组捕获，但不进行分析。

（5）生成质量属性效用树。评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。这一步很关键，它对以后的分析工作起指导作用。

（6）分析架构方法。一旦有了效用树的结果，评估小组可以对实现重要质量属性的架构方法进行考察。这是通过文档化这些架构决策和确定它们的风险、敏感点和权衡点等来实现的。在这一步中，评估小组要对每一种架构方法都考察足够的信息，完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及架构设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。

（7）讨论和对场景分级。场景在驱动ATAM测试阶段起主导作用，实践证明，当有很多项目干系人参与ATAM评估时，生成一组场景可为讨论提供极大的方便。

（8）分析架构方法。在收集并分析了场景之后，架构设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第（6）步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第（7）步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则进入第（8）步，就是测试步骤。

（9）描述评估结果。最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。这种描述一般要采用辅以幻灯片的形式，但也可以在ATAM评估结束之后，提交更完整的书面报告。在描述过程中，评估负责人要介绍ATAM评估的各个步骤，以及各步骤中得到的各种信息，包括业务环境、驱动需求、约束条件和架构等。最重要的是要介绍ATAM评估的结果。

：我们可以修改这9个步骤的顺序，以满足架构信息的特殊需求。也就是说，虽然这9个步骤按编号排列，但并不总是一个瀑布过程，评估人员可在这9个步骤中跳转或进行迭代。

ATAM评估的阶段

ATAM方法的各个步骤是随着时间的推移而展开的，可大致分为两个阶段。第一个阶段以架构为中心，重点是获取架构信息并进行分析；第二个阶段以项目干系人为中心，重点是获取项目干系人的观点，验证第一个阶段的结果。

之所以要分为两个阶段，是因为评估人员要在第一个阶段收集信息。在整个ATAM评估过程中，评估小组中的部分人（通常是1~3人）要与架构设计师、1或2个其他关键的项目干系人（例如，项目经理、客户经理、市场代表）一起工作，收集信息。对支持分析而言，在大多数情况下，这种信息是不完整的或不适当的，所以，评估小组必须与架构设计师一起协作引导出必须的信息，这种协作通常要花几周的时间。当评估人员觉得已经收集了足够的信息，并已把这些信息记录成文档，则就可以进入第二个阶段了。

软件架构

随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系，如下图所示。这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。

嵌入式系统的软件架构

嵌入式操作系统（Embedded Operating System，EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。

嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。

嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。

安全性

（1）可用性。可用性评价指标及测量，如下表所示。

可用性评价指标及测量

（2）完整性。完整性评价指标及测量，如下表所示。

完整性评价指标及测量

（3）保密性。保密性评价指标及测量，如下表所示。

保密性评价指标及测量

调试

调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。调试主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。常用的调试方法有试探法、回溯法、对分查找法、归纳法和演绎法。

架构设计

WebApp描述了使WebApp达到其业务目标的基础结构，典型使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含WebApp的业务规则的内容层或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器（Model-View-Controller，MVC）结构是WebApp基础结构模型之一，它将WebApp功能及信息内容分离。

排序

假设含n个记录的文件内容为｛R₁，R₂，…，R_n｝，其相应的关键字为｛k₁，k₂，…，k_n｝。经过排序确定一种排列｛R_j₁，R_j₂，…，R_jn｝，使得它们的关键字满足如下递增（或递减）关系：k_j₁≤k_j₂≤…≤k_jn（或k_j₁≥k_j₂≥…≥k_jn）。

评估

评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。

很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。

在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。

评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。

评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。

评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。

用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。

工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。

所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。

在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。

进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。

网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。

需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。

制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。

最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。

系统架构

客户机／服务器系统

C/S（Client/Server）结构，即大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到客户机端和服务器端来实现，降低了系统的通信开销。目前大多数应用软件系统都是客户机／服务器形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和客户机／服务器应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。

浏览器／服务器系统

B/S （Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（浏览器）实现，但是主要事务逻辑在服务器端（服务器）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握，成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（如LAN，WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全。

多层分布式系统（Multi-tier System）

（1）概念。

随着中间件与Web技术的发展，三层或多层分布式应用体系越来越流行。在多层体系中，各层次按照以下方式进行划分，实现明确分工：

①瘦客户：提供简洁的人机交互界面，完成数据的输入／输出。

②业务服务：完成业务逻辑，实现客户与数据库对话的桥梁。同时，在这一层中，还应实现分布式管理、负载均衡、Fail/Recover、安全隔离等。

③数据服务：提供数据的存储服务。一般就是数据库系统。

（2）多层系统主要特点。

多层系统主要特点是：

.安全性。中间层隔离了客户直接对数据服务器的访问，保护了数据库的安全。

.稳定性。对于要求24×7工作的业务系统，多层分布式体系提供了更可靠的稳定性。一是中间层缓冲Client与数据库的实际连接，使数据库的实际连接数量远小于Client应用数量。当然，连接数越少，数据库系统就越稳定。二是Fail/Recover机制能够在一台服务器宕机的情况下，透明地把客户端工作转移到其他具有同样业务功能的服务上。

.易维护。由于业务逻辑在中间服务器，当业务规则变化后，客户端程序基本不做改动。

.快速响应。通过负载均衡以及中间层缓存数据能力，可以提高对客户端的响应速度。

.系统扩展灵活。基于多层分布体系，当业务增大时，可以在中间层部署更多的应用服务器，提高对客户端的响应，而所有变化对客户端透明。

（3）多层系统举例。

目前最为流行的两类多层应用架构为Sun的J2EE和Microsoft.Net，下面简单介绍J2EE的多层架构。

J2EE多层应用架构

（4）客户层。

客户层用于与企业信息系统的用户进行交互以及显示根据特定商务规则进行计算后的结果。基于J2EE规范的客户端可以是基于Web的，也可以是不基于Web的独立（Stand Alone）应用程序。

在基于Web的J2EE客户端应用中，用户在客户端启动浏览器后，从Web服务器中下载Web层中的静态HTML页面或由JSP或Servlets动态生成的HTML页面。

在不基于Web的J2EE客户端应用中，独立的客户端应用程序可以运行在一些基于网络的系统中，例如手持设备或汽车电话等。同样，这些独立的应用也可以运行在客户端的Java Applet中。这种类型的客户端应用程序可以在不经过Web层的情况下直接访问部署在EJB容器（EJB Container）中的EJB组件。

（5） Web层。

J2EE规范定义的Web层由JSP页面、基于Web的Java Applets以及用于动态生成HTML页面的Servlets构成。这些基本元素在组装过程中通过打包来创建Web组件。运行在Web层中的Web组件依赖Web容器来支持诸如响应客户请求以及查询EJB组件等功能。

（6）业务层。

在基于J2EE规范构建的企业信息系统中，将解决或满足特定业务领域商务规则的代码构建成为业务层中的Enterprise JavaBean （EJB）组件。EJB组件可以完成从客户端应用程序中接收数据、按照商务规则对数据进行处理、将处理结果发送到企业信息系统层进行存储、从存储系统中检索数据以及将数据发送回客户端等功能。

部署和运行在业务层中的EJB组件依赖于EJB容器来管理诸如事务、生命期、状态转换、多线程及资源存储等。这样由业务层和Web层构成了多层分布式应用体系中的中间层。

（7）企业信息系统层。

在企业应用系统的逻辑层划分中，企业信息系统层通常包括企业资源规划（ERP）系统、大型机事务处理（Mainframe Transaction Processing）系统、关系数据库系统（RDMS）及其他在构建J2EE分布式应用系统时已有的企业信息管理软件。

题号导航 2013年下半年系统架构设计师上午试卷综合知识

本试卷我的完整做题情况



	第57题在手机中做本题