系统架构设计师-系统开发基础

1、系统架构设计师 - 系统开发基础（ 总分： 45.00 ，做题时间： 90 分钟 ）、单项选择题（ 总题数： 37，分数： 45.00）1. 需求工程活动产生软件运行特征的规约，指明软件和其他系统元素的接口并建立A. 数据流图和数据字典 B 程序流程图C.体系结构模型 D 软件必须满足的约束条件（分数： 1.00 ）A.B.C.D. V解析：需求工程活动产生软件运行特征的规约，指明软件和其他系统元素的接口并建立软件必须满足的约 束条件。数据流图和数据字典只是这些约束条件的表示方法，而程序流程图和体系结构模型是设计阶段的 工作。2. 有两种需求定义的方法严格定义和原型定义，在关于这两种方法的描述

2、中，不正确的是_A. 严格定义方法假定所有的需求都可以预先定义B 严格定义方法假定软件开发人员与用户之间的沟通存在障碍C. 原型定义方法认为需求分析中不可避免地要出现很多反复D. 原型定义方法强调用户在软件开发过程中的参与和决策（分数： 1.00 ）A.B. VC.D.解析：严格定义 （ 预先定义 ）是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方 法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、 严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。在传统的结构化开发中，需求的严格定义建立在以下的基本假设上： 所有需求都能

3、够被预先定义。假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通 过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂且较大的系统 显然是困难的。即使事先做了深入细致的调查和分析，当用户见到新系统的实际效果时，也往往会改变原 先的看法，会提出修改或更进一步增加系统功能的要求，所以再好的预先定义技术也会经常反复。这是因 为人们对新事物的认识与理解将随着直观、实践的过程进一步加深，这是与人类认识世界的客观规律相一 致的。所以，能够预先定义出所有需求的假设在许多场合是不能成立的。 开发人员与用户之间能够准确而清晰地交流。假设认为，用户与开发人员之间，虽然每人

4、都有自己的专 业、观点、行话，但在系统开发过程中可以使用图形 / 文档等通信工具进行交流，进行清晰、有效的沟通， 这种沟通是必不可少的。可是，在实际开发中，往往对一些共同的约定，每个人可能都会产生自己的理解 和解释。即使采用结构化语言、判定树、判定表等工具，仍然存在精确的、技术上的不严密感。这将导致 人们有意无意地带有个人的不同理解而各行其是，所以在多学科、多行业人员之间进行有效的通信交流是 有一定困难的。 采用图形 / 文字可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流、 通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们都是静止的

5、、 被动的，不能实际表演，很难在用户头脑中形成一个具体的形象。因此，要用静止的图形 / 文字描述来体现 一个动态的系统是比较困难的。除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷。 首先是文档量大，由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有助于 开发人员之间、用户与开发人员问的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力 和时间，导致系统开发周期增大。其次是开发过程可见性差，来自用户的反馈太迟。由于在需求定义、系 统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新 系统的实际操

6、作和体会来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的 工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会导致整个系统的失败。综上所述，需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的 障碍。为此，需要探求一种变通的方法。原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员 与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更 好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。 采用原型方法时需要注意以下几个问题：

7、 并非所有的需求都能在系统开发前被准确地说明。事实上，要想严密、准确地定义任何事情都是有一定难度的，更不用说是定义一个庞大系统的全部需求。用户虽然可以叙述他们所需最终系统的目标及大致功 能，但是对某些细节问题却往往不可能十分清楚。 一个系统的开发过程， 无论对于开发人员还是用户来说， 都是一个学习和实践的过程，为了帮助他们在这个过程中提出更完善的需求，最好的方法就是提供现实世 界的实例原型，对原型进行研究、实践，并进行评价。 项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。用户和开发人员通过屏 幕、键盘进行对话和讨论、 交流， 从他们自身的理解出发来测试原型， 一个具体的

8、原型系统， 由于直观性、 动态性而使得项目参加者之间的交流上的困难得到较好的克服。需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工具，但是，其最 大缺陷是缺乏直观的、感性的特征，因而不易理解对象的全部含义。交互式的系统原型能够提供生动的规 格说明，用户见到的是一个“活”的、实际运行着的系统。实际使用在计算机上运行的系统，显然比理解 纸面上的系统要深刻得多。 有合适的系统开发环境。随着计算机硬件、软件技术和软件工具的迅速发展，软件的设计与实现工作越来越方便， 对系统进行局部性修改甚至重新开发的代价大大降低。 所以，对大系统的原型化已经成为可能。 反复是完全需要和值得提

9、倡的，需求一旦确定，就应遵从严格的方法。对系统改进的建议来自经验的发 展，应该鼓励用户改进他们的系统，只有做必要的改变后，才能使用户和系统问获得更加良好的匹配，所 以，从某种意义上说，严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求，这对提高最 终系统的质量是有害的。另一方面，原型方法的使用并不排除严格定义方法的运用，当通过原型并在演示 中得到明确的需求定义后，应采用行之有效的结构化方法来完成最终系统的开发。3. 软件需求分析产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约 束。下面对于软件需求分析的描述，不正确的是 。A. 分析员研究系统规约和软件项

10、目计划，并在系统语境内理解软件和复审， 从而生成计划软件范围的估算B. 需求分析使得系统工程师能够刻画出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件 必须满足的约束C. 经过仔细的需求分析活动，分析员能够得到详细的系统规约D. 需求分析能够为软件设计者提供可被翻译成数据、体系结构、界面和过程设计的模型分数： 1.00 )A.B.C. VD.解析：需求分析使得系统工程师能够刻画出软件的功能和性能、指明软件和其他系统元素的接口、并建立 软件必须满足的约束。需求分析能够为软件设计者提供可被翻译成数据、体系结构、界面和过程设计的模 型。分析员研究系统规约和软件项目计划，并在系统语境内理解

11、软件和复审，从而生成计划软件范围的估 算。4. 质量功能部署（QFD）是一种将客户要求转化成软件需求的技术。OFD的目的是最大限度地提升软件工程过程中客户的满意度。为了这个目标，OFD确认了 3类需求，常规需求、 和意外需求。A. 期望需求B .基础需求C .显式需求D .功能需求（分数： 1.00 ）A. VB.C.D.解析：OFD确认了 3类需求，分别是基本需求（常规需求）、期望需求和意外需求（兴奋需求）。其中期望需 求指的是那些隐含在产品或系统中，可能由于非常基础以至于用户没有显式说明的需求。5. 需求分析的任务是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统“做什么”的问

12、 题。 并不是需求分析的实现步骤之一。A. 获得当前系统的物理模型 B 抽象出当前系统的逻辑模型C. 建立目标系统的逻辑模型 D 确定目标实现的具体技术路线（分数： 1.00 ）A.B.C.D. V解析： 2 典型试题分析”中试题 21的分析。6. 希赛网软件开发团队欲开发一套管理信息系统，在项目初期，用户提出了软件的一些基本功能，但是没 有详细定义输入、处理和输出需求。在这种情况下，该团队在开发过程应采用。A. 瀑布模型B .增量模型C.原型开发模型 D 快速应用程序开发（RAD）（分数： 1.00 ）A.B.C. VD.解析：瀑布模型也称为生命周期法，是生命周期法中最常用的开发模型，它把软

13、件开发的过程分为软件计 划、需求分析、软件设计、程序编码、软件测试和运行维护 6 个阶段，规定了它们自上而下、相互衔接的 固定次序，如同瀑布流水，逐级下落。瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地 位，它提供了软件开发的基本框架。瀑布模型主要用于需求明确或很少变更的项目。原型法适合于用户没有肯定其需求的明确内容的时候。它是先根据已给的和分析的需求，建立一个原始模 型，这是一个可以修改的模型 （在生命周期法中，需求分析成文档后一般不再进行修改 ）。在软件开发的各 个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加 强了，最终的结果是更适

14、合用户的要求。这种原型法成败的关键及效率的高低，关键在于模型的建立及建 模的速度。增量模型融合了瀑布模型的基本成分（重复地应用）和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核 心的产品，即实现了基本的需求，但很多补充的特性还没有发布。核心产品交用户使用，使用和/或评估的结果是下一个增量的开发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布一 些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。RAD是一个线性顺序的软件开发模型，强调极短的开发周期和可复用

15、程序构件的开发。RAD莫型是瀑布模型的一个高速变种，通过使用基于构件的建造方法获得了快速开发。如果需求理解得很好，且约束了项目范 围，RAD莫型使得一个开发组能够在很短时间内创建岀功能完善的系统。RAD方法主要用于信息系统应用软件的开发，它包含业务建模、数据建模、处理建模、应用生成、测试及反复5个阶段。7. 基于构件的开发（CBD）模型，融合了 模型的许多特征。该模型本质是演化的，采用迭代方法开发软件。A. 瀑布B .快速应用开发（RAD）C. 螺旋D 形式化方法（分数：1.00 ）A.B.C. VD.解析：基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中

16、 的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开 发模型由软件的需求分析和定义、架构设计、构件库建立、应用软件构建及测试和发布5个阶段组成。统一软件开发过程是一种基于面向对象技术的软件开发过程，其特点是“用例驱动，以架构为核心，迭代 并增量”。统一软件开发过程定义了4种通用的开发阶段，它们按照过程顺序分别是：起始阶段、（8）构建阶段和（9），其中在构建阶段主要产生的文档有（10）。（分数：3.00 ）（1）.A 分析阶段B 细化阶段C 设计阶段D 交付阶段（分数：1.00 ）

17、A.B. VC.D.解析：.A 分析阶段B 细化阶段C 设计阶段D 交付阶段（分数：1.00 ）A.B.C.D. V解析：.A .初始用户手册B.用例模型C .项目计划D .设计模型（分数：1.00 ）A.B.C.D. V解析：统一过程适合于大、中型项目的开发，可以分为4个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和移交阶段。初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部 实体，定义系统与外部实体交互的特性。 在这个阶段中所关注的是整个项目的业务和需求方面的主要风险。 对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。细化阶段的任务是分

18、析问题领域，建立健全的架构基础，淘汰项目中最高风险的元素。在细化阶段，必须 在理解整个系统的基础上，对架构做岀决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项 目建立支持环境。在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。从某种 意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。构建 阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的 分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件做好准备。在构建 阶段，开发团队的工作可以实现某种程度的

19、并行。即使是较小的项目，也通常包括可以相互独立开发的构 件，从而使各团队之间实现并行开发。当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。交付阶段的主要任务是进行 B测试，制作产品发布版本；对最终用户支持文档定稿; 按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，如进 行调试、性能或可用性的增强等。根据产品的种类，交付阶段可能非常简单，也可能非常复杂。例如，发 布现有桌面产品的新发布版本可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。交付 阶段结束时也要进行技术评审，评审目标是

20、否实现，是否应该开始演化过程，用户对交付的产品是否满意 等。8. 敏捷软件过程强调：让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小 化软件工程工作产品，以及整体精简开发。 不是采用这种软件开发过程的原因。A. 难以提前预测哪些需求是稳定的和哪些需求会变化B. 对于软件项目开发来说，设计和实现可以做到基本分离C. 从制订计划的角度来看，分析、设计、实现和测试并不容易预测D. 可执行原型和部分实现的可运行系统是了解用户需求和反馈的有效媒介（分数：1.00 ）A.B. VC.D.解析：敏捷软件过程主要有四大价值观：个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文 档

21、；客户合作胜过合同谈判；响应变化胜过遵循计划。这种价值观的前提是软件需求是难以提前确定的， 而是会不断地发生变化，可以采用可执行原型和部分实现的可运行系统来了解用户需求，通过用户的反馈 来明确需求。从制订计划的角度来看，分析、设计、实现和测试并不容易预测。逆向工程过程的抽象层次是指可从源代码中抽取出来的设计信息的精制程度。抽象层次分为4层，其中,“最低层”抽象能够导岀过程的设计表示文档，“低层”抽象能够导岀程序和数据结构信息，“中层”能够导出（12），“高层”抽象能够导出 （13）。（分数：2.00 ）（1）.A 实体关系模型B 程序和文档结构信息C.全部文档信息 D .数据流和控制流模型（分

22、数：1.00 ）A.B.C.D. V解析：.A .实体关系模型B .模块结构图C.完全的数据流图 D 全部文档信息（分数：1.00 ）B.C.D.解析：逆向工程过程能够导出过程的设计模型 （实现级，一种低层的抽象 ） 、程序和数据结构信息 （结构级， 稍高层次的抽象）、对象模型、数据和控制流模型 （功能级，相对高层的抽象）和uML状态图和部署图（领域 级，高层抽象 ） 。随着抽象层次增高，完备性就会降低。抽象层次越高，它与代码的距离就越远，通过逆向 工程恢复的难度就越大，而自动工具支持的可能性相对变小，要求人参与判断和推理的工作增多。所以本题选D、A。关于逆向工程的详细说明，请参看“ 软件开发

23、方法”中的逆向工程。9. 详细的项目范围说明书是项目成功的关键。 不应该属于范围定义的输入。A. 项目章程B 项目范围管理计划C.批准的变更申请 D 项目文档管理方案（分数： 1.00 ）A.B.C.D. V解析：在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范 围说明书，是项目成功的关键。范围定义的输入包括以下内容： 项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集 和开发，以产生详细的项目范围说明书。 项目范围管理计划。 组织过程资产。 批准的变更申请。所以项目文档管理方案不属于范围定义的输入。10. 项目时间

24、管理包括使项目按时完成所必需的管理过程， 活动定义是其中的一个重要过程。 通常可以使用 来进行活动定义。A. 鱼骨图B .工作分解结构（WBS）C.层次分解结构D .功能分解图（分数： 1.00 ）A.B. VC.D.解析：项目时间管理包括使项目按时完成所必需的管理过程。项目时间管理中的过程包括：活动定义、活 动排序、活动的资源估算、活动历时估算、制定进度计划及进度控制。为了得到工作分解结构（Work Breakdown Structure , WBS中最底层的交付物，必须执行一系列的活动。对 这些活动的识别及归档的过程就是活动定义。鱼骨图 （ 又称为 Ishikawa 图 ） 是一种发现问题

25、“根本原因”的方法，通常用来进行因果分析。11. 软件的逆向工程是一个恢复设计的过程，从现有的程序中抽取数据、体系结构和过程的设计信息。 逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述，在大多数情况下，抽象层次越高， 完备性就越低。下列可以通过逆向工程恢复的制品中，完备性最低的是。A.过程的设计模型 B .程序和数据结构C.对象模型、数据和控制流 D . uML状态图和部署图（分数:1.00）A.B.C.D. V解析：逆向工程过程及用于实现该过程的工具的抽象层次是指可从源代码中抽取出来的设计信息的精密程度。理想地，抽象层次应该尽可能高，即逆向工程过程应该能够导岀过程的设计表示

26、（一种低层的抽象）；程序和数据结构信息（稍高一点层次的抽象）；数据和控制流模型（一种相对高层的抽象）；以及实体关系模 型（一种高层抽象）。随着抽象层次增高，软件工程师获得更有助于理解程序的信息。在试题给出的4个选项中，UMLL犬态图和部署图可以用来描述实体之间的关系，因此，其层次最高，完备 性最低。12. 把整个软件开发流程分成多个阶段，每一个阶段都由目标设定、风险分析、开发和有效性验证及评审构成。A. 原型模型B .瀑布模型C .螺旋模型D . V模型（分数：1.00 ）A.B.C. VD.解析：本题考查开发模型基础知识，解这类题，需要对常见模型的核心特点有所了解。下面对选项中岀现的模型做一

27、个简单的总结。原型模型：针对需求不明确、原型可抛弃。瀑布模型：阶段明晰、无法应对需求不明确的情况。螺旋模型：瀑布模型+演化模型、循环、里程碑、风险分析。V模型：测试模型、测试全程介入、测试计划提前。把以上特点与题目描述进行对比，可以发现本题所描述的是螺旋模型。在RUP中采用“4+1”视图模型来描述软件系统的体系结构。在该模型中，最终用户侧重于（18），系统工程师侧重于（19）。（分数：2.00 ）(1).A.实现视图B.进程视图C .逻辑视图D .部署视图（分数：1.00 )A.B.C.VD.解析:(2).A.实现视图B.进程视图C .逻辑视图D .部署视图（分数：1.00 )A.B.C.D.

28、V解析:在RUP中采用“4+1”视图模型来描述软件系统的体系结构。“4+1 ”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；最终用户关心的是系统的功能，因此 会侧重于逻辑视图；程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图；系统集成人员关 心的是系统的性能、 可伸缩性、 吞吐率等问题， 因此会侧重于进程视图； 系统工程师关心的是系统的发布、 安装、拓扑结构等问题，因此会侧重于部署视图。13. 软件的横向重用是指重用不同应用领域中的软件元素。 是一种典型的、原始的横向重用机制。A. 对象B .构件C .标准函数库

29、D .设计模式（分数： 1.00 ）A.B.C. VD.解析：软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。按照重用 活动是否跨越相似性较少的多个应用领域，软件重用可以区别为横向重用和纵向重用。横向重用是指重用 不同应用领域中的软件元素，例如数据结构、分类算法和人机界面构建等。标准函数是一种典型的、原始 的横向重用机制。纵向重用是指在一类具有较多公共性的应用领域之间进行软部件重用。纵向重用活动的 主要关键点是域分析：根据应用领域的特征及相似性预测软部件的可重用性。14. 下列关于不同软件开发方法所使用的模型的描述中，正确的是 。A. 在进行结构化分析时，必须使用

30、数据流图和软件结构图这两种模型B. 采用面向对象开发方法时，可以使用状态图和活动图对系统的动态行为进行建模C. 实体联系图（E-R图）是在数据库逻辑结构设计时才开始创建的模型D. UML的活动图与程序流程图的表达能力等价（分数： 1.00 ）A.B. VC.D.解析：结构化分析方法是一种面向数据流的需求分析方法，其基本思想是自顶向下逐层分解。数据流图是 进行结构化分析时所使用的模型，其基本成分包括数据流、加工、数据存储和外部实体。在进行结构化设 计时，通过对数据流图进行变换分析和事务分析可以导出程序结构图。数据库设计可以分为4个主要阶段：用户需求分析。数据库设计人员采用一定的辅助工具对应用对象

31、的 功能、性能、限制等要求所进行的科学分析。概念设计。概念结构设计是对信息分析和定义，如视图模 型化、视图分析和汇总。对应用对象精确地抽象、概括而形成的独立于计算机系统的企业信息模型。描述 概念模型的较理想的工具是 ER图。逻辑设计。将抽象的概念模型转化为与选用的DBM沪品所支持的数据模型相符合的逻辑模型，它是物理设计的基础。包括模式初始设计、子模式设计、应用程序设计、模 式评价及模式求精。物理设计。逻辑模型在计算机中的具体实现方案。UML是面向对象软件的标准化建模语言，其中状态图、活动图、顺序图和通信图可以用来对系统的动态行 为进行建模。活动图展现了在系统内从一个活动到另一个活动的流程。活动

32、图强调对象之间的控制流程。 在活动图上可以表示分支和汇合。活动图与传统的程序流程图是不等价的。15. 在实际的项目开发中， 人们总是希望使用自动工具来执行需求变更控制过程。 下列描述中， 不是这类工具所具有的功能。A. 可以定义变更请求的数据项及变更请求生存期的状态转换图B. 记录每一种状态变更的数据，确认做出变更的人员C. 可以加强状态转换图使经授权的用户仅能做出所允许的状态变更D. 定义变更控制计划，并指导设计人员按照所制定的计划实施变更分数： 1.00 ）A.B.C.D. V解析：对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避免，要使得软件 需求完全不变更，也许

33、是不可能的，但毫无控制的变更是项目陷入混乱、不能按进度完成或者软件质量无 法保证的主要原因之一。一个好的变更控制过程，给项目风险承担者提供了正式的建议需求变更机制。可以通过需求变更控制过程 来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。在实际中，人们总是希望使用自动工具 来执行变更控制过程。有许多人使用商业问题跟踪工具来收集、存储、管理需求变更；可以使用工具对一 系列最近提交的变更建议产生一个列表给变更控制委员会开会时做议程用。问题跟踪工具也可以随时按变 更状态分类包裹变更请求的数目。挑选工具时可以考虑以下几个方面： 可以定义变更请求的数据项。 可以定义变更请求生存期的状态转换图。

34、 可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。 记录每一种状态变更的数据，确认做出变更的人员。 可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。 可以根据需要生成标准的或定制的报告和图表。16. 黑盒测试法是根据软件产品的功能设计规格说明书，通过运行程序进行测试，证实每个已经实现的功能是否符合设计要求。如果某产品的文本编辑框允许输入1255个字符，采用测试方法，其测试数据为：0个字符、1个字符、255个字符和 256个字符。A.等价类划分B .边界值分析C. 比较测试D .正交数组测试（分数：1.00 ）A.B. VC.D.解析：本题考查黑盒测试，常用的黑盒测试技术

35、包括等价类划分、边值分析、错误推测和因果图等。关于 这些技术的详细介绍，请参看“ 测试与评审”。软件开发环境是支持软件产品开发的软件系统，它由软件工具集和环境集成机制构成。环境集成机制包括：提供统一的数据模式和数据接口规范的数据集成机制；支持各开发活动之间通信、切换、调度和协同的_（24）_ ;为统一操作方式提供支持的(25)。（分数:2.00 )(1).A .操作集成机制B .控制集成机制C.平台集成机制D .界面集成机制（分数：1.00 )A.B.VC.D.解析：.A .操作集成机制B .控制集成机制C.平台集成机制D .界面集成机制（分数：1.00 )A.B.C.B. V解析：软件开发环

36、境(Software Development EnvironrrLent)是支持软件产品开发的软件系统。它由软件工具集和环境集成机制构成，前者用来支持软件开发的相关过程、活动和任务；后者为工具集成和软件开 发、维护和管理提供统一的支持，它通常包括数据集成、控制集成和界面集成。数据集成机制提供了存储 或访问环境信息库的统一的数据接口规范；界面集成机制采用统一的界面形式，提供统一的操作方式；控 制集成机制支持各开发活动之间的通信、切换、调度和协同工作。17. 是一个独立可交付的功能单元，外界通过接口访问其提供的服务。A. 面向对象系统中的对象(Object)B. 模块化程序设计中的子程序 (Sub

37、routine)C. 基于构件开发中的构件 (Component)D. 系统模型中的包(Package)(分数：1.00 )A.B.C. VD.解析：在基于构件的开发中，构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系 统模型中包的思想，它是系统设计、实现和维护的基础。构件定义为通过接口访问服务的一个独立可交付 的功能单元。平时我们所看到的 DLL文件就是封装好的构件。在基于构件的软件开发中，(27)描述系统设计蓝图以保证系统提供适当的功能;(28)用来了解系统的性能、吞吐率等非功能性属性。(分数：2.00 )(1) .A .逻辑构件模型 B .物理构件模型C. 组件接口模型

38、 D .系统交互模型(分数：1.00 )A. VB.C.D.解析：(2) .A .逻辑构件模型 B .物理构件模型C.组件接口模型 D .系统交互模型(分数：1.00 )A.B. VC.D.解析：在基于构件的软件开发中，逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模 型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架 构用于了解系统的性能、吞吐率等许多非功能性属性。18. 对象管理组织()MG)基于CORBAS础设施定义了 4种构件标准。其中，

39、的状态信息是由构件自身而不是由容器维护。A.实体构件B 加工构件C.服务构件D 会话构件(分数:1.00)A.B.C.D. V解析：对象管理组织(OMG基于CORB基础设施定义了 4种构件标准。实体(Entity)构件需要长期持久化并 主要用于事务性行为，由容器管理其持久化。加工(Process)构件同样需要容器管理其持久化，但没有客户 端可访问的主键。会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。服务 (Service)构件是无状态的。19. 分布式系统开发中，通常需要将任务分配到不同的逻辑计算层。业务数据的综合计算分析任务属于A.表示逻辑层B 应用逻辑层C

40、 数据处理层D 数据层(分数：1.00 )A.B. VC.D.解析：分布式系统开发分为 5个逻辑计算层：表示层实现用户界面；表示逻辑层为了生成数据表示而必须 进行的处理任务，如输入数据编辑等；应用逻辑层包括为支持实际业务应用和规则所需的应用逻辑和处理 过程，如信用检查、数据计算和分析等；数据处理层包括存储和访问数据库中的数据所需的应用逻辑和命 令，如查询语句和存储过程等；数据层是数据库中实际存储的业务数据。20. 系统输入设计中，采用内部控制方式以确保输入系统数据的有效性， 用于验证数据是否位于合法的取值范围。A.数据类型检查 B .自检位C .域检查D .格式检查(分数：1.00 )A.B.

41、C. VD.解析：系统输入设计中，通常通过内部控制的方式验证输入数据的有效性。数据类型检查确保输入了正确 的数据类型；白检位用于对主关键字进行基于校验位的检查；域检查用于验证数据是否位于合法的取值范 围：格式检查按照已知的数据格式对照检查输入数据的格式。系统测试由若干个不同的测试类型组成，其中(32)检查系统能力的最高实际限度，即软件在一些超负荷情况下的运行情况；(33)主要是检查系统的容错能力。(分数：2.00 )(1).A .强度测试B .性能测试C .恢复测试D .可靠性测试(分数：1.00 )A. VB.C.D.解析：.A .强度测试B .性能测试C .恢复测试D .可靠性测试(分数：

42、1.00 )A.B.B. VD.解析：本题考查测试的相关概念，我们只要了解每一种测试的主要工作，就能解答此题。恢复测试：恢复测试监测系统的容错能力。检测方法是采用各种方法让系统岀现故障，检验系统是否按照要求能从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。如果系统的恢 复是自动的（由系统自动完成），需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工 干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。强度测试：是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行时，性能下降的幅度 是否在允许的范围内。因此，强度测试要求系统在非正常数

43、量、频率或容量的情况下运行。强度测试主要 是为了发现在有效的输入数据中可能引起不稳定或不正确的数据组合。例如，运行使系统处理超过设计能 力的最大允许值的测试例子；使系统传输超过设计最大能力的数据，包括内存的写入和读岀等。性能测试：检查系统是否满足系统设计方案说明书对性能的要求。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分所有都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时 对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。可靠性测试：通常使用以下两个指标来衡量系统的可靠性： 平均失效间隔时间（Mean Time Between

44、Faihires MTBF是否超过了规定的时限，因故障而停机时间 （Mean Time To Repairs，MTTR在一年中不应超过多少时 间。21. 需求管理是CMM可重复级中的6个关键过程域之一，其主要目标是 。A. 对于软件需求，必须建立基线以进行控制，软件计划、产品和活动必须与软件需求保持一致B. 客观地验证需求管理活动符合规定的标准、程序和要求C. 策划软件需求管理的活动，识别和控制已获取的软件需求D. 跟踪软件需求管理的过程、实际结果和执行情况（分数：1.00 ）A. VB.C.D.解析：过程能力成熟度模型（Capability Maturity Model ，CMM在软件开发机

45、构中被广泛用来指导软件过 程改进。该模型描述了软件成立能力的5个成熟级别，每一级都包含若干关键过程域 （Key Process . Areas，KPA）。CMM勺第二级为可重复级，它包括6个关键过程域，分别是：需求管理、软件项目计划、软件项目跟踪和监督、软件分包合同管理、软件质量保证和软件配置管理。需求管理的目标是为软件需求建立一个基线，提供给软件工程和管理使用；软件计划、产品和活动与软件需求保持一致。UML的事物是对模型中最具有代表性的成分的抽象，（35）是模型的静态部分，描述概念或物理元素；（36）用来描述、说明和标注模型的任何元素。（分数：2.00 ）（1）.A .结构事物B .分组事物

46、C .行为事物D .注释事物（分数：1.00 ）A. VB.C.D.解析：.A .分组事物B .注释事物C .结构事物D .行为事物（分数：1.00 ）A.C.D.解析：UML有3种基本的构造块，分别是事物 （元素）、关系和图。事物是 UML中重要的组成部分。关系把 事物紧密联系在一起。图是很多有相互相关的事物的组。UML中的事物也称为建模元素，包括结构事物、动作事物、分组事物和注释事物。这些事物是UML模型中最基本的面向对象的构造块。 结构事物。 结构事物在模型中属于最静态的部分，代表概念上等或物理上的元素。 总共有 7 种结构事物：首先是类，类是描述具有相同属性、方法、关系和语义的对象的集

47、合。一个类实现一个或多个接口。第2 种是接口，接口是指类或组件提供特定服务的一组操作的集合。因此，一个接口描述了类或组件的对 外的可见的动作。一个接口可以实现类或组件的全部动作，也可以只实现一部分。第3 种是协作，协作定义了交互的操作，是一些角色和其他元素一起工作，提供一些合作的动作，这些动 作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成 部分。这些协作代表构成系统的模式的实现。第4 种是用例，用例是描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的 值。在模型中用例通常用来组织动作事物。用例是通过协作来实现的。第5 种是活动

48、类，活动类是这种类，它的对象有一个或多个进程或线程。活动类和类很相像，只是它的对 象代表的元素的行为和其他的元素是同时存在的。第6 种是构件，构件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，可能会遇到不同种类的构件，女口 DCOM EJB第7 种是节点，节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具 有处理能力。一个组件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。 动作事物：动作事物是 uML模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有 两种主要的动作事物。第1种是交互 （内部活动 ） ，交互是由一组对象

49、之间在特定上下文中，为达到特定的目的而进行的一系列消 息交换而组成的动作。 交互中组成动作的对象的每个操作都要详细列出， 包括消息、 动作次序 （消息产生的 动作 ） 、连接 （ 对象之间的连接 ） 。第2 种是状态机，状态机由一系列对象的状态组成。内部活动和状态机是 UML模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对 象连接在一起。 分组事物。分组事物是 UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。总 共只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。结构事物、动作事物甚至其他的分 组事物都有可能放在一个包中。与组件 （存在于运

50、行时 ）不同的是包纯粹是一种概念上的东西，只存在于开 发阶段。 注释事物。注释事物是 UML模型的解释部分。22. 希赛公司欲开发一个在线交易系统。 为了能够精确表达用户与系统的复杂交互过程， 应该采用 UIVlL 的 进行交互过程建模。A.类图B 顺序图C 部署图D 对象图（分数： 1.00 ）A.B. VC.D.解析：显然，为了能够精确表达用户与系统的复杂交互过程，应该使用交互图。在UML中，交互图包括顺序图、通信图、定时图和交互概览图。顺序图强调消息的时间次序，通信图强调消息流经的数据结构，定 时图强调消息跨越不同对象或角色的实际时间，交互概览图是顺序图和活动图的混合体。23. 雇员类含

51、有计算报酬的行为， 利用面向对象的 ，可以使得其派生类专职雇员类和兼职雇员类计算报酬的行为有相同的名称，但有不同的计算方法。A.多态性B .继承性C .封装性D .复用性（分数： 1.00 ）A. VB.C.D.解析：本题是一个纯概念题。在面向对象技术中，多态考虑的是类与类之间的层次关系，以及类自身内部 特定成员函数之间的关系问题，是解决功能和行为的再抽象问题。多态是指类中具有相似功能的不同函数 用同一个名称来实现，从而可以使用相同的调用方式来调用这些具有不同功能的同名函数。这也是人类思 维方式的一种直接模拟， 例如，一个对象中有很多求两个数最大值的行为， 虽然可以针对不同的数据类型， 写很多

52、不同名称的函数来实现，但事实上，它们的功能几乎完全相同。这时，就可以利用多态的特征，用 统一的标识来完成这些功能。这样，就可以达到类的行为的再抽象，进而统一标识，减少程序中标识符的 个数。24. 面向对象分析的一项重要任务是发现潜在对象并进行筛选，错误的做法是删除 。A.系统范围之外的名词 B .表示事件的名词C.不具有独特行为的名词 D 一个对象的同义词（分数： 1.00 ）A.B. VC.D.解析：在00A中，并不是所有的名词都表示了问题域内有用的业务对象，通过删除对象的同义词、系统范 围之外的名词、不具有独特行为的名词、不清楚的名词和另一个对象的行动或属性的名词来最终清理候选 对象列表。25. 面向对象分析的任务不包含 。A.建模系统功能B .发现并确定业务对象C.建模各对象的状态 D .组织对象并确定对象间的关系（分数： 1.00 ）A.B.C. VD.解析：00A基于用例模型，通过对象建模记录确定的对象、对象封装的数据和行为，以及对象之间的关系。00A包括3个活动，分别是建模系统功能、发现并确定业务对象、组织对象并确定对象问的关系。26. 系统测试将软件、硬件、网络等其他因素结合，对整个软件进行测试。不是系统测试的内容。A.路径测试B 可靠性测试C 安装测试D 安全测试分数： 1.00 )A. VB.C.B. 解析：系统测试是将已