免费智能真题库 > 历年试卷 > 系统架构设计师 > 2012年下半年 系统架构设计师 上午试卷 综合知识
  第62题      
  知识点:   SAAM评估方法   软件架构   评估   软件工程
  关键词:   SA   开发   软件工程   软件架构   文档        章/节:   软件架构评估       

 
基于场景的架构分析方法(Scenarios-based Architecture Analysis Method,SAAM)是卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法,是最早形成文档并得到广泛应用的软件架构分析方法。SAAM的主要输入是问题描述、(62)和架构描述文档,其分析过程主要包括场景开发、(63)、单个场景评估、场景交互和总体评估
 
 
  A.  问题说明
 
  B.  问题建模
 
  C.  需求说明
 
  D.  需求建模
 
 
 

 
  第63题    2011年下半年  
   48%
识别风险点、非风险点、敏感点和权衡点是软件架构评估过程中的关键步骤。针对某系统所作的架构设计中,“系统需要支持的最大..
  第50题    2020年下半年  
   51%
在软件架构评估中,(48)是影响多个质量属性的特性,是多个质量属性的(49) 。例如,提高加密级别可以提高安全性,但可能要耗费更..
  第57题    2013年下半年  
   30%
架构权衡分析方法(Architecture Tradeoff Analysis Method,ATAM)是一种系统架构评估方法,主要在系统开发之前,针对性能、(57)、..
   知识点讲解    
   · SAAM评估方法    · 软件架构    · 评估    · 软件工程
 
       SAAM评估方法
        SAAM方法是最早形成文档并得到广泛使用的软件架构分析方法,最初是用来分析架构的可修改性的,但实践证明,SAAM方法也可用于对许多其他质量属性及系统功能进行快速评估。
        与ATAM方法相比,SAAM比较简单,这种方法易学易用,进行培训和准备的工作量都比较少。SAAM评估可以分6个步骤进行,在这些步骤进行之前,通常有必要对系统做简要的介绍,包括对架构的业务目标的说明等。
        (1)形成场景。在形成场景的过程中,要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。只有这样,形成的场景才能代表与各种项目干系人相关的任务。
        (2)描述架构。在这一步,架构设计师应该采用参加评估的所有人员都能够充分理解的形式,对待评估的架构进行适当的描述。这种描述必须要说明系统中的运算和数据构件,也要讲清它们之间的联系。除了要描述这些静态特性外,还要对系统在某段时间内的动态特征做出说明。描述既可采用自然语言,也可采用形式化的手段。
        (3)对场景进行分类和确定优先级。在SAAM评估中,场景就是对所期望的系统中某个使用情况的简短描述。架构可能直接支持该场景,即这一预计的使用情况不需要对架构做任何修改即可实现,一般可以通过演示现有的架构在执行此场景时的表示来确定。在SAAM评估方法中称这样的场景为直接场景。也就是说,直接场景就是按照现有架构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景并不会让项目干系人们感到意外,但将增进对架构的理解,促进对诸如性能和可靠性等其他质量属性的研究。
        (4)对间接场景的单个评估。一旦确定了要考虑的一组场景,就要把这些场景与架构的描述对应起来。对于直接场景而言,架构设计师需要讲清所评估的架构将如何执行这些场景;对于间接场景而言,架构设计师应说明需要对架构做哪些修改才能适应间接场景的要求。
        (5)评估场景的相互作用。当两个或多个间接场景要求更改架构的同一个构件时,我们就称这些场景在这一组构件上相互作用。
        (6)形成总体评估。最后,评估人员要对场景和场景之间的交互作一个总体的权衡和评价,这一权衡反映该组织对表现在不同场景中的目标的考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值,权值的确定通常要与每个场景所支持的业务目标联系起来。如果是要比较多个架构,或者针对同一架构提出了多个不同的方案,则可通过权值的确定来得出总体评价。权值的设置具有很强的主观性,所以,应该让所有项目干系人共同参与,但也应合理组织,要允许对权值及其基本思想进行公开讨论。
        上述6个步骤是关于SAAM评估中技术方面的问题,与ATAM评估方法类似,在进行SAAM评估时,也要考虑合作关系、准备工作等问题。需要对评估会议的时间做出安排、确定评估小组的人员组成、确定会议室、邀请各类项目干系人、编制会议日程等,这些工作都是必需的。
 
       软件架构
        随着嵌入式技术的发展,特别是在后PC时代,嵌入式软件系统得到了极大的丰富和发展,形成了一个完整的软件体系,如下图所示。这个体系自底向上由3部分组成,分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统(Embedded Operating System,EOS)由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务,其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲,软件的开发环境大部分在通用台式计算机和工作站上运行,但从逻辑上讲,它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中,如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。
 
       软件工程
        1)软件工程的概念
        为了消除软件危机,通过认真研究解决软件危机的方法,人们认识到软件工程是使计算机软件走向科学的途径,逐渐形成了软件工程的概念,并开辟工程学的新兴领域,即软件工程学。
        2)软件工程的要素
        软件工程具有以下3个要素。
        (1)方法。完成软件工程项目的技术手段。
        (2)工具。支持软件的开发、管理、文档生成。
        (3)过程。将方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
        3)软件生命周期
        软件生命周期是指软件产品从考虑其概念开始到该软件产品交付使用,直至最终退役为止的整个过程,包括计划阶段、分析阶段、设计阶段、实现阶段、测试阶段和运行维护阶段。
        4)软件开发模型
        比较经典的软件开发模型有瀑布模型、快速原型模型、演化模型、增量模型、螺旋模型、喷泉模型等。
        5)软件开发方法
        软件开发方法有以下几种。
        (1)结构化软件开发(SASD)方法:采用结构化技术来完成软件开发的各项任务。它把软件生命周期划分成若干个阶段,依次完成每个阶段的任务。它与瀑布模型有很好的结合度,是与其最相适应的软件开发方法。
        (2)面向数据结构的软件开发方法:从目标系统的输入、输出数据结构入手,导出程序框架结构,再补充其他细节,从而可得到完整的程序结构图。有Jackson方法和Warnier方法。
        (3)面向对象的软件开发方法:随着OOP(面向对象编程)向OOD(面向对象设计)和OOA(面向对象分析)的发展,最终形成面向对象的软件开发方法OMT(Object Modelling Technique)。这是一种自底向上和自顶向下相结合的方法,而且它以对象建模为基础,从而不仅考虑了输入、输出数据结构,实际上也包含了所有对象的数据结构。
        (4)基于构件化的开发方法:用预先建立的构件和模板,像"搭积木"一样进行建造。
   题号导航      2012年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第62题    在手机中做本题