免费智能真题库 > 历年试卷 > 系统架构设计师 > 2011年下半年 系统架构设计师 上午试卷 综合知识
  第62题      
  知识点:   软件架构   软件架构评估   第二层   架构设计   评估   系统架构
  关键词:   并发用户数   传输   可修改性   软件架构   识别风险   数据   系统架构   协议   并发   风险        章/节:   软件架构评估       

 
识别风险点、非风险点、敏感点和权衡点是软件架构评估过程中的关键步骤。针对某系统所作的架构设计中,“系统需要支持的最大并发用户数量直接影响传输协议和数据格式”描述了系统架构设计中的一个(62):“由于系统的业务逻辑目前尚不清楚, 因此现有系统三层架构中的第二层可能会出现功能重复,这会影响系统的可修改性”描述了系统架构设计中的一个(63)。
 
 
  A.  敏感点
 
  B.  风险点
 
  C.  非风险点
 
  D.  权衡点
 
 
 

 
  第61题    2011年下半年  
   44%
架构权衡分析方法(ATAM)是一种常用的软件架构评估方法,下列关于该方法的叙述中,正确的是(61).
  第63题    2010年下半年  
   54%
正确识别风险点、非风险点、敏感点和权衡点是进行软件架构评价的关键步骤。其中(62)是实现一个特定质量属性的关键特征,该特征为..
  第62题    2012年下半年  
   54%
基于场景的架构分析方法(Scenarios-based Architecture Analysis Method,SAAM)是卡耐基梅隆大学软件工程研究所的Kazman等人于1..
   知识点讲解    
   · 软件架构    · 软件架构评估    · 第二层    · 架构设计    · 评估    · 系统架构
 
       软件架构
        随着嵌入式技术的发展,特别是在后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评估时,也要考虑合作关系、准备工作等问题。需要对评估会议的时间做出安排、确定评估小组的人员组成、确定会议室、邀请各类项目干系人、编制会议日程等,这些工作都是必需的。
 
       第二层
        第二层是应用服务器层,该层由Web服务器与应用服务器两部分组成。这两类服务器一般在同一层中,该层有时也称为应用服务器或Web服务器。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构,典型使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器,以及可以包含WebApp的业务规则的内容层或模型层,描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp基础结构模型之一,它将WebApp功能及信息内容分离。
 
       评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如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分布式应用系统时已有的企业信息管理软件。
   题号导航      2011年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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题    在手机中做本题