CPU响应DMA请求是在（1）结束时。

虚拟存储体系是由（2）两线存储器构成。

浮点数能够表示的数的范围是由其（3）的位数决定的。

在机器指令的地址段中，直接指出操作数本身的寻址方式称为（4）。

内存按字节编址从B3000H到DABFFH的区域其存储容量为（5）。

编译器和解释器是两种基本上的高级语言处理程序。编译器对高级语言源程序的处理过程可以划分为词法分析，语法分析，语义分析，中间代码生成，代码优化，目标代码生成等阶段，其中，（6）并不是每个编译器都必需的。

表达式采用逆波兰式表示时，利用（7）进行求值。

某企业的生产流水线上有2名工人P1和P2，1名检验员P3。P1将初步加工的半成品放入半成品箱B1，P2从半成口箱B1取出继续加工，加工好的产品放入成品箱B2，P3从成品箱B2取出产品检验。假设B1可存放N件半成品，B2可存放M件产品，并且设置6个信号量S1、S2、S3、S4、S5和S6，且S3和S6的初值都为0，采用PV操作实现P1、 P2和P3的同步模型如下图所示，则信号量S1和S5（8），S2 、S4的初值分别为（9）。

某企业的生产流水线上有2名工人P1和P2，1名检验员P3。P1将初步加工的半成品放入半成品箱B1，P2从半成口箱B1取出继续加工，加工好的产品放入成品箱B2，P3从成品箱B2取出产品检验。假设B1可存放N件半成品，B2可存放M件产品，并且设置6个信号量S1、S2、S3、S4、S5和S6，且S3和S6的初值都为0，采用PV操作实现P1、 P2和P3的同步模型如下图所示，则信号量S1和S5（8），S2 、S4的初值分别为（9）。

在支付多线程的操系统中，假设进程P创建了若干个线程，那么（10）是不能被这些线程共享的。

软件设计师王某在其公司的某一综合楼信息管理系统软件开发工作中承担了大部分程序设计工作，该系统交付用户后，投入试运行后，王某离职离开公司，并带走了该综合信息管理系统的源程序，拒不交还公司，王某认为，综合信息管理系统的源程序是他独立完成的，他是综合信息系统源程序的软件著作权人，王某的行为（11）。

颜色深度是表达单个像素的颜色或灰度所占的位数（bit），若每个像素具人有8位的颜色深度，则可表示（12）种不同的颜色。

视觉上的颜色可用亮度，色调和饱和度三个特征来描述，其中饱和度是指颜色的（13）。

（14）不属于主动攻击。

防火墙不具备（15）功能。

如下图所示，从输出的信息中可以确定的是信息是（16）。

数据库系统通常采用三级模式结构外模式，模式和内模式，这三级模式分别对应的数据库的（17）。

在数据库逻辑设计阶段，若实体中存在多值属性，那么将E-R图转为关系模式时（19）得到的关系模式属于4NF。

在分布式数据库中有分片透明，复制透明，位置透明和逻辑透明等基本概念，其中，（19）是指局部数据模型透明，即用户或应用程序无需知道局部使用是哪种数据模型，（20）是指用户或应用程序不需要知道逻辑上访问的表是怎么分块存储的。

在分布式数据库中有分片透明，复制透明，位置透明和逻辑透明等基本概念，其中，（19）是指局部数据模型透明，即用户或应用程序无需知道局部使用是哪种数据模型，（20）是指用户或应用程序不需要知道逻辑上访问的表是怎么分块存储的。

设有关系模式R（A₁，A₂，A₃，A₄，A₅，A₆），其中：函数依赖集F={A₁→A₂，A₁A₃→A₄，A₅A₆→A₁，A₂A₅→A₆，A₃A₅→A₆}，则（21）关系模式R的一个主键，R规范化程度最高达到（22）。

设有关系模式R（A₁，A₂，A₃，A₄，A₅，A₆），其中：函数依赖集F={A₁→A₂，A₁A₃→A₄，A₅A₆→A₁，A₂A₅→A₆，A₃A₅→A₆}，则（21）关系模式R的一个主键，R规范化程度最高达到（22）。

POP3协议采用（23）模式，客户端代理与POP3服务器通过建立（24）连接来传送据。

POP3协议采用（23）模式，客户端代理与POP3服务器通过建立（24）连接来传送据。

如果在查找路由表时发现有多个选项匹配，那么应该根据（25）原则进行选择，假设路由表有4个表项如下所示，那么与地址139.17.179.92匹配的表项是（26）。

如果在查找路由表时发现有多个选项匹配，那么应该根据（25）原则进行选择，假设路由表有4个表项如下所示，那么与地址139.17.179.92匹配的表项是（26）。

在层次化局域网模型中，以下关于核心层的描述，正确的是（27）。

算术表达式a+b-c*d的后缀式是（28）（-、+、*表示算术的减、加、乘运算，运算符的优先级和结合性遵循惯例）。

函数f（）、g（）的定交如下所示，已知调用f时传递给其形参x的值是10，若以传值方式调用g，则函数f的返回值为（29）。

当用户需求不清晰，需求经常发生变化，系统规模不太大时，最适宜采用软件开发方法是（30）。

在结构化分析方法中，利用分层数据流图对系统功能建模，以下关于分层数据流图的叙述中，不正确的是（31）。采用数据字典为数据流图中的每个数据流、文件、加工以及组成数据流或文件的数据项进行说明，其条目不包括（32）。

在结构化分析方法中，利用分层数据流图对系统功能建模，以下关于分层数据流图的叙述中，不正确的是（31）。采用数据字典为数据流图中的每个数据流、文件、加工以及组成数据流或文件的数据项进行说明，其条目不包括（32）。

下图是一个软件项目的活动图，其中项点表示项目的里程碑，连接顶点的边表示包含的活动，则完成该项目的最少时间为（33）天，活动BD最多可以晚开始（34）天而不会影响整个项目的进度。

下图是一个软件项目的活动图，其中项点表示项目的里程碑，连接顶点的边表示包含的活动，则完成该项目的最少时间为（33）天，活动BD最多可以晚开始（34）天而不会影响整个项目的进度。

开发过程中以用户需求为动力，以对象作为驱动，（35）适合于面向对象的开发方法。

以下关于极限编程XP的叙述中，不正确的是（36）。

以下关于分层体系结构的叙述中不正确有的是（37）。

以下关于模块耦合关系的叙述中，耦合程度最低的是（38），其耦合类型为（39）耦合。

以下关于模块耦合关系的叙述中，耦合程度最低的是（38），其耦合类型为（39）耦合。

堆是一种数据结构，分为大顶堆和小顶堆两种类型，大（小）顶堆要求父元素大于等于（小于等于）其左右孩子元素。则（40）是一个大顶堆结构，该堆结构用二叉树表示，其高度（或层数）为（41）。

堆是一种数据结构，分为大顶堆和小顶堆两种类型，大（小）顶堆要求父元素大于等于（小于等于）其左右孩子元素。则（40）是一个大顶堆结构，该堆结构用二叉树表示，其高度（或层数）为（41）。

在ISO/IEC软件质量模型中，功能性是与一组功能及其指定的性质的存在有关的一组属性，其子特性不包括（42）。

程序质量评审通常是从开发者的角度进行评审，其内容不包括（43）。

在面向对象分析和设计中，用类图给出的静态设计视图，其应用场合不包括（44）。下图是一个UML类图，其中类University和类School之间是（45）关系，类Person和类PersonRecord之间是（46）关系，表示Person与PersonRecord（47）。

在面向对象分析和设计中，用类图给出的静态设计视图，其应用场合不包括（44）。下图是一个UML类图，其中类University和类School之间是（45）关系，类Person和类PersonRecord之间是（46）关系，表示Person与PersonRecord（47）。

在面向对象分析和设计中，用类图给出的静态设计视图，其应用场合不包括（44）。下图是一个UML类图，其中类University和类School之间是（45）关系，类Person和类PersonRecord之间是（46）关系，表示Person与PersonRecord（47）。

在面向对象分析和设计中，用类图给出的静态设计视图，其应用场合不包括（44）。下图是一个UML类图，其中类University和类School之间是（45）关系，类Person和类PersonRecord之间是（46）关系，表示Person与PersonRecord（47）。

软件复杂性是指理解和处理软件的难易程度。其度量参数不包括（48）。

对现有软件系统中一些数据处理的算法进行改进，以提高效率，从而更快地响应用户服务要求。这种行为属于（49）维护。

软件测试的对象包括（50）。
①需求规格说明
②概要设计文档
③软件测试报告
④软件代码
⑤用户手册
⑥软件开发人员

以下不属于系统测试的是（51）。
①单元测试
②集成测试
③安全性测试
④可靠性测试
⑤确认测试
⑥验证测试

以下关于软件测试原则叙述中，不正确是的（52）。

一条BUG记录应该包括（53）。
①编号
②bug描述
③bug级别
④bug所属模块
⑤发现人

（54）不属于使用软件测试工具的目的。

以下关于验收测试的叙述中，不正确的是（55）。

以下关于黑盒测试的测试方法选择的叙述中，不正确的是（56）。

以下关于等价划分法的叙述中不正确的是（57）。

以下关于白盒测试的叙述中，不正确的是（58）。

对于逻辑表达式((a||(b&c))||(c&&d))，需要（59）个测试用例才能完成条件组合覆盖。

为了解系统在何种服务级别下会崩溃，应进行（60）。

兼容性测试的测试范围包括（61）。
①硬件兼容性测试
②软件兼容性测试
③数据兼容性测试
④平台兼容性测试

以下不能作为测试结束标准的是（62）。

以下属于静态测试方法的是（63）。

单元测试的测试内容包括（64）。
①模块接口
②局部数据库结构
③模块内路径
④边界条件
⑤错误处理
⑥系统性能

一个Web信息系统所需要的进行的测试包括（65）。
①功能测试
②性能测试
③可用性测试
④客户端兼容性测试
⑤ 安全性测试

以下不属于网络测试的测试指标的是（66）。

对于其于用户口令的用户认证机制来说，（67）不属于增强系统安全性应使用的防范措施。

对于防病毒系统的测试是系统安全测试的重要内容，下列不属于防病毒系统安全测试基本测试点的是（68）。

1976年Diffie与Hellman首次公开提出（69）的概念与结构，采用两个从此独立的密钥对数据分别行行加密或解密，且加密过程基于数学函数，从而带来了加密领域的革命性进步。

集线器与网桥的区别是（70）。

In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.
But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describle steps and sequences of events.
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requiements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do.In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement. Use cases are particularly well suited to capture approaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.
But, like anything, use cases come with their own problems, and as useful as they are, they can be （75）. The result is something that is as bad, if not worse, that the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.

In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.
But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describle steps and sequences of events.
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requiements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do.In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement. Use cases are particularly well suited to capture approaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.
But, like anything, use cases come with their own problems, and as useful as they are, they can be （75）. The result is something that is as bad, if not worse, that the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.

In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.
But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describle steps and sequences of events.
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requiements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do.In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement. Use cases are particularly well suited to capture approaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.
But, like anything, use cases come with their own problems, and as useful as they are, they can be （75）. The result is something that is as bad, if not worse, that the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.

In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.
But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describle steps and sequences of events.
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requiements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do.In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement. Use cases are particularly well suited to capture approaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.
But, like anything, use cases come with their own problems, and as useful as they are, they can be （75）. The result is something that is as bad, if not worse, that the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.

In a world where it seems we already have too much to do, and too many things to think about, it seems the last thing we need is something new that we have to learn.
But use cases do solve a problem with requirements: with （71） declarative requirements it's hard to describle steps and sequences of events.
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful. As simple as this sounds, this is important. When confronted only with a pile of requiements, it's often （72） to make sense of what the authors of the requirements really wanted the system to do.In the preceding example, use cases reduce the ambiguity of the requirements by specifying exactly when and under what conditions certain behavior occurs; as such, the sequence of the behaviors can be regarded as a requirement. Use cases are particularly well suited to capture approaches. Although this may sound simple, the fact is that （73） requirement capture approaches, with their emphasis on declarative requirements and "shall" statements, completely fail to capture fail to capture the （74） of the system's behavior. Use cases are a simple yet powerful way to express the behavior of the system in way that all stakeholders can easily understand.
But, like anything, use cases come with their own problems, and as useful as they are, they can be （75）. The result is something that is as bad, if not worse, that the original problem. Therein it's important to utilize use cases effectively without creating a greater problem than the one you started with.