免费智能真题库 > 历年试卷 > 系统架构设计师 > 2020年下半年 系统架构设计师 上午试卷 综合知识
  第48题      
  知识点:   软件架构   软件架构评估   安全性   加密   评估   系统性能   消息
  章/节:   软件架构评估       

 
软件架构评估中,(48)是影响多个质量属性的特性,是多个质量属性的(49) 。例如,提高加密级别可以提高安全性,但可能要耗费更多的处理时间,影响系统性能。如果某个机密消息的处理有严格的时间延迟要求,则加密级别可能就会成为一个(50)。
 
 
  A.  敏感点
 
  B.  权衡点
 
  C.  风险决策
 
  D.  无风险决策
 
 
 

 
  第50题    2020年下半年  
   47%
在软件架构评估中,(48)是影响多个质量属性的特性,是多个质量属性的(49) 。例如,提高加密级别可以提高安全性,但可能要耗费更..
  第49题    2020年下半年  
   27%
在软件架构评估中,(48)是影响多个质量属性的特性,是多个质量属性的(49) 。例如,提高加密级别可以提高安全性,但可能要耗费更..
  第60题    2014年下半年  
   62%
识别风险、非风险、敏感点和权衡点是进行软件架构评估的重要过程。“改变业务数据编码方式会对系统的性能和安全性产生影响&..
   知识点讲解    
   · 软件架构    · 软件架构评估    · 安全性    · 加密    · 评估    · 系统性能    · 消息
 
       软件架构
        随着嵌入式技术的发展,特别是在后PC时代,嵌入式软件系统得到了极大的丰富和发展,形成了一个完整的软件体系,如下图所示。这个体系自底向上由3部分组成,分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统(Embedded Operating System,EOS)由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务,其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲,软件的开发环境大部分在通用台式计算机和工作站上运行,但从逻辑上讲,它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中,如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       软件架构评估
        架构评估可以只针对一个架构,也可以针对一组架构。在架构评估过程中,评估人员所关注的是系统的质量属性。有关质量属性,请参考11.6.3节。
        为了后面讨论的需要,我们先介绍两个概念:敏感点(sensitivity point)和权衡点(tradeoff point)。敏感点和权衡点是关键的架构决策。敏感点是一个或多个构件(和/或构件之间的关系)的特性。研究敏感点可使架构设计师或系统分析师明确在搞清楚如何实现质量目标时应注意什么。权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。例如,改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性,但可能要耗费更多的处理时间,影响系统性能。如果某个机密消息的处理有严格的时间延迟要求,则加密级别可能就会成为一个权衡点。
                      主要的评估方式
                      从目前已有的软件架构评估技术来看,基本可以归纳为3类主要的评估方式:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
                             基于调查问卷或检查表的评估方式
                             CMU/SEI(Carnegie Mellon University/Software Engineering Institute,卡耐基梅隆大学的软件工程研究所)的软件风险评估过程采用了这一方式。调查问卷是一系列可以应用到各种架构评估的相关问题,其中有些问题可能涉及到架构的设计决策;有些问题涉及架构的文档,例如架构的表示用的是何种ADL(Architecture Description Language,架构描述语言);有的问题针对架构描述本身的细节问题,如系统的核心功能是否与界面分开。检查表中也包含一系列比调查问卷更细节和具体的问题,它们更趋向于考察某些关心的质量属性。例如,对实时信息系统的性能进行考察时,很可能问到系统是否反复多次地将同样的数据写入磁盘等。
                             这一评估方式比较自由灵活,可评估多种质量属性,也可以在软件架构设计的多个阶段进行。但是由于评估的结果很大程度上来自评估人员的主观推断,因此不同的评估人员可能会产生不同甚至截然相反的结果,而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。尽管基于调查问卷与检查表的评估方式相对比较主观,但由于系统相关的人员的经验和知识是评估软件架构的重要信息来源,因而它仍然是进行软件架构评估的重要途径之一。
                             基于场景的评估方式
                             场景是一系列有序的使用或修改系统的步骤。基于场景的方式主要应用在架构权衡分析方法(Architecture Tradeoff Analysis Method,ATAM)和软件架构分析方法(Software Architecture Analysis Method,SAAM)中。在架构评估中,一般采用刺激(stimulus)、环境(environment)和响应(response)3方面来对场景进行描述。刺激是场景中解释或描述项目干系人怎样引发与系统的交互部分,环境描述的是刺激发生时的情况,响应是指系统是如何通过架构对刺激作出反应的。
                             基于场景的方式分析软件架构对场景的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。例如,用一系列对软件的修改来反映易修改性方面的需求,用一系列攻击性操作来代表安全性方面的需求等。这一评估方式考虑到了所有与系统相关的人员对质量的要求,涉及到的基本活动包括:确定应用领域的功能和软件架构的结构之间的映射,设计用于体现待评估质量属性的场景,以及分析软件架构对场景的支持程度。
                             不同的系统对同一质量属性的理解可能不同,例如,对操作系统来说,可移植性被理解为系统可在不同的硬件平台上运行,而对于普通的应用系统而言,可移植性往往是指该系统可在不同的操作系统上运行。由于存在这种不一致性,对一个领域适合的场景设计在另一个领域内未必合适,因此基于场景的评估方式是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识,以对某一质量需求设计出合理的场景;另一方面,必须对待评估的软件架构有一定的了解,以准确判断它是否支持场景描述的一系列活动。
                             基于度量的评估方式
                             度量是指为软件产品的某一属性所赋予的数值,如代码行数、方法调用层数、构件个数等。传统的度量研究主要针对代码,但近年来也出现了一些针对高层设计的度量,软件架构度量即是其中之一。基于度量的评估技术都涉及3个基本活动:首先,需要建立质量属性和度量之间的映射原则,即确定怎样从度量结果推出系统具有什么样的质量属性;然后,从软件架构文档中获取度量信息;最后,根据映射原则分析推导出系统的某些质量属性。
                             基于度量的评估方式提供更为客观和量化的质量评估,需要在软件架构的设计基本完成以后才能进行,而且需要评估人员对评估的架构十分了解,否则不能获取准确的度量。
                             比较
                             经过对3类主要的软件架构评估方式的分析,我们用下表从通用性、评估者对架构的了解程度、评估实施阶段、评估方式的客观程度等方面对这3种方式进行简单的比较。
                             
                             3类评估方式比较表
                      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个其他关键的项目干系人(例如,项目经理、客户经理、市场代表)一起工作,收集信息。对支持分析而言,在大多数情况下,这种信息是不完整的或不适当的,所以,评估小组必须与架构设计师一起协作引导出必须的信息,这种协作通常要花几周的时间。当评估人员觉得已经收集了足够的信息,并已把这些信息记录成文档,则就可以进入第二个阶段了。
                      SAAM评估方法
                      SAAM方法是最早形成文档并得到广泛使用的软件架构分析方法,最初是用来分析架构的可修改性的,但实践证明,SAAM方法也可用于对许多其他质量属性及系统功能进行快速评估。
                      与ATAM方法相比,SAAM比较简单,这种方法易学易用,进行培训和准备的工作量都比较少。SAAM评估可以分6个步骤进行,在这些步骤进行之前,通常有必要对系统做简要的介绍,包括对架构的业务目标的说明等。
                      (1)形成场景。在形成场景的过程中,要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。只有这样,形成的场景才能代表与各种项目干系人相关的任务。
                      (2)描述架构。在这一步,架构设计师应该采用参加评估的所有人员都能够充分理解的形式,对待评估的架构进行适当的描述。这种描述必须要说明系统中的运算和数据构件,也要讲清它们之间的联系。除了要描述这些静态特性外,还要对系统在某段时间内的动态特征做出说明。描述既可采用自然语言,也可采用形式化的手段。
                      (3)对场景进行分类和确定优先级。在SAAM评估中,场景就是对所期望的系统中某个使用情况的简短描述。架构可能直接支持该场景,即这一预计的使用情况不需要对架构做任何修改即可实现,一般可以通过演示现有的架构在执行此场景时的表示来确定。在SAAM评估方法中称这样的场景为直接场景。也就是说,直接场景就是按照现有架构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景并不会让项目干系人们感到意外,但将增进对架构的理解,促进对诸如性能和可靠性等其他质量属性的研究。
                      (4)对间接场景的单个评估。一旦确定了要考虑的一组场景,就要把这些场景与架构的描述对应起来。对于直接场景而言,架构设计师需要讲清所评估的架构将如何执行这些场景;对于间接场景而言,架构设计师应说明需要对架构做哪些修改才能适应间接场景的要求。
                      (5)评估场景的相互作用。当两个或多个间接场景要求更改架构的同一个构件时,我们就称这些场景在这一组构件上相互作用。
                      (6)形成总体评估。最后,评估人员要对场景和场景之间的交互作一个总体的权衡和评价,这一权衡反映该组织对表现在不同场景中的目标的考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值,权值的确定通常要与每个场景所支持的业务目标联系起来。如果是要比较多个架构,或者针对同一架构提出了多个不同的方案,则可通过权值的确定来得出总体评价。权值的设置具有很强的主观性,所以,应该让所有项目干系人共同参与,但也应合理组织,要允许对权值及其基本思想进行公开讨论。
                      上述6个步骤是关于SAAM评估中技术方面的问题,与ATAM评估方法类似,在进行SAAM评估时,也要考虑合作关系、准备工作等问题。需要对评估会议的时间做出安排、确定评估小组的人员组成、确定会议室、邀请各类项目干系人、编制会议日程等,这些工作都是必需的。
 
       安全性
        (1)可用性。可用性评价指标及测量,如下表所示。
        
        可用性评价指标及测量
        
        (2)完整性。完整性评价指标及测量,如下表所示。
        
        完整性评价指标及测量
        (3)保密性。保密性评价指标及测量,如下表所示。
        
        保密性评价指标及测量
        
 
       加密
               保密与加密
               保密就是保证敏感信息不被非授权的人知道。加密是指通过将信息进行编码而使得侵入者不能够阅读或理解的方法,目的是保护数据和信息。解密是将加密的过程反过来,即将编码信息转化为原来的形式。古时候的人就已经发明了密码技术,而现今的密码技术已经从外交和军事领域走向了公开,并结合了数学、计算机科学、电子与通信等诸多学科而成为了一门交叉学科。现今的密码技术不仅具有保证信息机密性的信息加密功能,而且还具有数字签名、身份验证、秘密分存、系统安全等功能,来鉴别信息的来源以防止信息被篡改、伪造和假冒,保证信息的完整性和确定性。
               加密与解密机制
               加密的基本过程包括对原来的可读信息(称为明文或平文)进行翻译,译成的代码称为密码或密文,加密算法中使用的参数称为加密密钥。密文经解密算法作用后形成明文,解密算法也有一个密钥,这两个密钥可以相同也可以不相同。信息编码的和解码方法可以很简单也可以很复杂,需要一些加密算法和解密算法来完成。
               从破译者的角度来看,密码分析所面对的问题有三种主要的变型:①“只有密文”问题(仅有密文而无明文);②“已知明文”问题(已有了一批相匹配的明文与密文);③“选择明文”(能够加密自己所选的明文)。如果密码系统仅能经得起第一种类型的攻击,那么它还不能算是真正的安全,因为破译者完全可能从统计学的角度与一般的通信规律中猜测出一部分的明文,而得到一些相匹配的明文与密文,进而全部解密。因此,真正安全的密码机制应使破译者即使拥有了一些匹配的明文与密文也无法破译其他的密文。
               如果加密算法是可能公开的,那么真正的秘密就在于密钥了,密钥长度越长,密钥空间就越大,破译密钥所花的时间就越长,破译的可能性就越小。所以应该采用尽量长的密钥,并对密钥进行保密和实施密钥管理。
               国家明确规定严格禁止直接使用国外的密码算法和安全产品,原因主要有两点:①国外禁止出口密码算法和产品,目前所出口的密码算法都有破译手段,②国外的算法和产品中可能存在“后门”,要防止其在关键时刻危害我国安全。
               密码算法
               密码技术用来进行鉴别和保密,选择一个强壮的加密算法是至关重要的。密码算法一般分为传统密码算法(又称为对称密码算法)和公开密钥密码算法(又称为非对称密码算法)两类,对称密钥密码技术要求加密解密双方拥有相同的密钥。而非对称密钥密码技术是加密解密双方拥有不相同的密钥。
               对称密钥密码体制从加密模式上可分为序列密码和分组密码两大类(这两种体制之间还有许多中间类型)。
               序列密码是军事和外交场合中主要使用的一种密码技术。其主要原理是:通过有限状态机产生性能优良的伪随机序列,使用该序列将信息流逐比特加密从而得到密文序列。可以看出,序列密码算法的安全强度由它产生的伪随机序列的好坏而决定。分组密码的工作方式是将明文分成固定长度的组(如64比特一组),对每一组明文用同一个密钥和同一种算法来加密,输出的密文也是固定长度的。在序列密码体制中,密文不仅与最初给定的密码算法和密钥有关,同时也是被处理的数据段在明文中所处的位置的函数;而在分组密码体制中,经过加密所得到的密文仅与给定的密码算法和密钥有关,而与被处理的明数据段在整个明文中所处的位置无关。
               不同于传统的对称密钥密码体制,非对称密码算法要求密钥成对出现,一个为加密密钥(可以公开),另一个为解密密钥(用户要保护好),并且不可能从其中一个推导出另一个。公共密钥与专用密钥是有紧密关系的,用公共密钥加密的信息只能用专用密钥解密,反之亦然。另外,公钥加密也用来对专用密钥进行加密。
               公钥算法不需要联机密钥服务器,只在通信双方之间传送专用密钥,而用专用密钥来对实际传输的数据加密解密。密钥分配协议简单,所以极大简化了密钥管理,但公共密钥方案较保密密钥方案处理速度慢,因此,通常把公共密钥与专用密钥技术结合起来实现最佳性能。
               密钥及密钥管理
               密钥是密码算法中的可变参数。有时候密码算法是公开的,而密钥是保密的,而密码分析者通常通过获得密钥来破译密码体制。也就是说,密码体制的安全性建立在对密钥的依赖上。所以,保守密钥秘密是非常重要的。
               密钥管理一般包括以下8个内容。
               (1)产生密钥:密钥由随机数生成器产生,并且应该有专门的密钥管理部门或授权人员负责密钥的产生和检验。
               (2)分发密钥:密钥的分发可以采取人工、自动或者人工与自动相结合的方式。加密设备应当使用经过认证的密钥分发技术。
               (3)输入和输出密钥:密钥的输入和输出应当经由合法的密钥管理设备进行。人工分发的密钥可以用明文形式输入和输出,并将密钥分段处理;电子形式分发的密钥应以加密的形式输入和输出。输入密钥时不应显示明文密钥。
               (4)更换密钥:密钥的更换可以由人工或自动方式按照密钥输入和密钥输出的要求来实现。
               (5)存储密钥:密钥在加密设备内采用明文形式存储,但是不能被任何外部设备访问。
               (6)保存和备份密钥:密钥应当尽量分段保存,可以分成两部分并且保存在不同的地方,例如一部分存储在保密设备中,另一部分存储在IC卡上。密钥的备份也应当注意安全并且要加密保存。
               (7)密钥的寿命:密钥不可以无限期使用,密钥使用得越久风险也就越大。密钥应当定期更换。
               (8)销毁密钥:加密设备应能对设备内的所有明文密钥和其他没受到保护的重要保护参数清零。
 
       评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。
 
       系统性能
               系统性能定义和指标
               计算机系统性能指标以系统响应时间和作业吞吐量为代表。响应时间(Elapsed Time)是指用户从输入信息到服务器完成任务给出响应的时间,即计算机系统完成某一任务(程序)所花费的时间,比如存储器访问、输入/输出等待、操作系统开销等。作业吞吐量是整个服务器在单位时间内完成的任务量。假定用户不间断地输入请求,则在系统资源充裕的情况下,单个用户的吞吐量与响应时间成反比,即响应时间越短,吞吐量越大。为了缩短某一用户或服务的响应时间,可以分配给它更多的资源。性能调整就是根据应用要求和服务器具体运行环境和状态,改变各个用户和服务程序所分配的系统资源,充分发挥系统能力,用尽量少的资源满足用户要求,达到为更多用户服务的目的。
               计算机性能的其他常用指标还包括MIPS (Million Instruction Per Second)和MFLOPS(Million Floating-point Instruction Per Second)。
               (1) MIPS=指令数/(执行时间×1000000)。
               其主要特点如下:
               ① MIPS大小和指令集有关,不同指令集的计算机间的MIPS不能比较。
               ②在同一台计算机上MIPS是变化的,因程序不同而变化。
               ③有时MIPS指标会出现矛盾。
               ④主要适用于带有硬件浮点处理器的计算机。
               ⑤MIPS中,除包含运算指令外,还包含取数、存数、转移等指令在内。
               ⑥MIPS只适宜于评估标量机。
               ⑦相对MIPS指相对参照机而言的MIPS,通常用VAX-11/780机处理能力为1MIPS。
               (2)MFLOPS=浮点指令数/(执行时间×1000000)。
               ①与机器和程序有关。
               ②测量浮点运算时,比MIPS准确。
               ③MFLOPS比较适宜于评估向量计算机。
               ④MFLOPS与MIPS关系:1MFLOPS≈3MIPS。
               ⑤MFLOPS仅仅只能用来衡量计算机浮点操作的性能,而不能体现计算机的整体性能。例如编译程序,不管计算机的性能有多好,它的MFLOPS不会太高。
               ⑥MFLOPS是基于操作而非指令的,所以它可以用来比较两种不同的计算机。
               ⑦MFLOPS依赖于操作类型。例如100%的浮点加要远快于100%的浮点除。
               ⑧单个程序的MFLOPS值并不能反映计算机的性能。
               系统性能评估
               计算机性能评价技术可用于开发中和开发后的系统评价。主要包括三种技术:分析技术、模拟技术、测量技术。
                      分析技术
                      分析技术是在一定假设条件下,计算机系统参数与性能指标参数之间存在着某种函数关系,按其工作负载的驱动条件列出方程,用数学方法求解。其特点是具有理论的严密性,节约人力和物力,可应用于设计中的系统。它的数学工具主要是利用排队论模型进行分析。
                      模拟技术
                      模拟技术首先是对于被评价系统的运行特性建立系统模型,按系统可能有的工作负载特性建立工作负载模型;随后编写模拟程序,模仿被评价系统的运行;设计模拟实验,依照评价目标,选择与目标有关因素,得出实验值,再进行统计、分析。其特点在于可应用于设计中或实际应用中的系统,可与分析技术相结合,构成一个混合系统。分析和模拟技术最后均需要通过测量技术验证。
                      测量技术
                      测量技术则是对于已投入使用的系统进行测量,通常采用不同层次的基准测试程序评估。其评估层次包括实际应用程序、核心程序、合成测试程序三个层次,但必须均为国际性组织认可的程序,同时需要对评估结果进行分析和统计以保证其准确性。
                      常用的国际认可的用来测试机器性能的测试基准测试程序(按评价准确性递减的顺序):
                      (1)实际的应用程序方法。
                      运行例如C编译程序、Tex、字处理软件、CAD工具等。
                      (2)核心基准程序方法。
                      从实际的程序中抽取少量关键循环程序段,并用它们来评价计算机的性能。
                      (3)简单基准测试程序。
                      简单基准测试程序通常只有10~100行而且运行结果是可以预知的。
                      (4)综合基准测试程序。
                      为了体现平均执行而人为编制的,类似于核心程序,没有任何用户真正运行综合基准测试程序。
 
       消息
        消息是对象间通信的手段、一个对象通过向另一个对象发送消息来请求其服务。一个消息通常包括接收对象名、调用的操作名和适当的参数(如有必要)。消息只告诉接收对象需要完成什么操作,并不能指示接收者怎样完成操作。消息完全由接收者解释,接收者独立决定采用什么方法来完成所需的操作。
   题号导航      2020年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第48题    在手机中做本题