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

1、 模拟 系统架构设计师系统开发基础单项选择题第 1 题：需求工程活动产生软件运行特征的规约，指明软件和其他系统元素的接口并建A. 数据流图和数据字典B. 程序流程图C. 体系结构模型D. 软件必须满足的约束条件参考答案： D需求工程活动产生软件运行特征的规约， 指明软件和其他系统元素的接口并建立 软件必须满足的约束条件。数据流图和数据字典只是这些约束条件的表示方法， 而程序流程图和体系结构模型是设计阶段的工作。第 2 题： 有两种需求定义的方法严格定义和原型定义，在关于这两种方法的描述 中，不正确的是 。A. 严格定义方法假定所有的需求都可以预先定义B. 严格定义方法假定软件开发人员与用户之间

2、的沟通存在障碍C. 原型定义方法认为需求分析中不可避免地要出现很多反复D. 原型定义方法强调用户在软件开发过程中的参与和决策参考答案： B严格定义 （预先定义 ）是目前采用较多的一种需求定义方法。 在采用严格定义的传 统的结构化开发方法中， 各个工作阶段排列成一个理想的线性开发序列， 在每一 工作阶段中， 都用上一阶段所提供的完整、 严格的文档作为指导文件， 因此它本 质上是一种顺序型的开发方法。 在传统的结构化开发中，需求的严格定义 建立在以下的基本假设上： 所有需求都能够被预先定义。假设意味着， 在没有实际系统运行经验的情况下， 全部的系统需求均可通过逻辑推断得到。 这 对某些规模较小、

3、功能简单的系统是可能的， 但对那些功能庞大、 复杂且较大的 系统显然是困难的。 即使事先做了深入细致的调查和分析， 当用户见到新系统的 实际效果时， 也往往会改变原先的看法， 会提出修改或更进一步增加系统功能的 要求，所以再好的预先定义技术也会经常反复。 这是因为人们对新事物的认识与 理解将随着直观、 实践的过程进一步加深， 这是与人类认识世界的客观规律相一 致的。所以，能够预先定义出所有需求的假设在许多场合是不能成立的。 开发人员与用户之间能够准确而清晰地交流。假设认为，用户与开发人员之间， 虽然每人都有自己的专业、观点、行话，但在系统开发过程中可以使用图形 / 文 档等通信工具进行交流，

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

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

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

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

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

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

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

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

12、统“做什么”的问题。 并不是需求分析的实现步骤之一。A. 获得当前系统的物理模型B. 抽象出当前系统的逻辑模型C. 建立目标系统的逻辑模型D. 确定目标实现的具体技术路线参考答案： D第 6 题： 希赛网软件开发团队欲开发一套管理信息系统，在项目初期，用户提出了软件 的一些基本功能，但是没有详细定义输入、处理和输出需求。在这种情况下， 该团队在开发过程应采用 。A. 瀑布模型B. 增量模型C. 原型开发模型D. 快速应用程序开发 (RAD)参考答案： C瀑布模型也称为生命周期法， 是生命周期法中最常用的开发模型， 它把软件开发 的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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