D

B

[解析]
   根据系统说明书中规定的功能要求，具体设计实现逻辑模型的技术方案，是系统设计阶段的任务。系统设计阶段形成的主要技术文档是系统设计说明书。

A

D

[解析]
   瀑布模型严格遵循软件生命周期各阶段的固定顺序：计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段，整个模型就像一个飞流直下的瀑布。瀑布模型有许多优点：可强迫开发人员采用规范的方法；严格规定了各阶段必须提交的文档；要求每个阶段结束后，都要进行严格的评审。但瀑布模型过于理想化，而且缺乏灵活性，无法在开发过程中逐渐明确用户难以确切表达或一时难以想到的需求，直到软件开发完成之后才发现与用户需求有很大距离，此时必须付出高额的代价才能纠正这一偏差。
   演化模型是一种原型化开发方法，其开发过程是从初始模型逐步演化为最终软件产品的渐进过程。
   螺旋模型综合了瀑布模型和演化模型的优点，还增加了风险分析。螺旋模型包含四个方面的活动：制订计划、风险分析、实施工程、客户评估。这四项活动恰好可以放在一个直角坐标系的四个象限，而开发过程恰好像一条螺旋线。采用螺旋模型时，软件开发沿着螺旋线自内向外旋转，每转一圈都要对风险进行识别和分析，并采取相应的对策。螺旋线第一圈的开始点可能是一个概念项目。从第二圈开始，一个新产品开发项目开始了，新产品的演化沿着螺旋线进行若干次迭代，一直运转到软件生命期结束。
   喷泉模型主要用于描述面向对象的开发过程。喷泉一词体现了面向对象开发过程的迭代和无间隙特征。迭代意味着模型中的开发活动常常需要多次重复，每次重复都会增加或明确一些目标系统的性质，但却不是对先前工作结果的本质性改动。无间隙是指在开发活动(如分析、设计、编程)之间不存在明显的边界，而是允许各开发活动交叉、迭代地进行。

C

B

A

[解析]
   OMT方法的OOA模型包括对象模型、动态模型和功能模型。
   对象模型表示静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象及对象彼此间’的关系的映射，描述了系统的静态结构，通常用类图表示。
   动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中对象的合法变化序列，通常用状态图表示。
   功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映了用户对目标系统的需求，通常用数据流图表示。
   对象模型为动态模型和功能模型提供了基本的框架。

C

B

[解析]
   螺旋模型是在瀑布模型和演化模型的基础上，加上两者所忽略的风险分析所建立的一种开发模型。螺旋线第一圈的开始点可能是一个概念项目。

B

C

[解析]
   模块的扇入应尽量大，扇出不宜过大。一个模块的扇入是指直接调用该模块的上级模块的个数。一个模块的扇出是指该模块直接调用的下级模块的个数。扇入大表示模块的复用程度高，扇出大表示模块的复杂度高。
   如果两个以上的模块都需要某一数据结构时，不使用全局变量的方式而是借助于模块接口被传递，这种耦合称为标记耦合。

C

D

[解析]
   软件设计包括体系结构设计、接口设计、数据设计和过程设计。  

A

D

B

[解析]
   UML是一种语言，是一种可视化的语言，是一组图形符号，是面向对象建模的重要工具。学习用UML建模的需要掌握三个要素：UML的基本构造块、这些构造块放在一起的规则、一些运用于整个UML的公共机制。UML中有四种贯穿整个语言且一致应用的公共机制，因此使得UML变得较为简单：这四种公共机制分别是详述、修饰、通用划分和扩展机制。
   1．详述：在建模的过程中，我们利用UML的图形表示对BPEL4WS系统进行可视化，利用UML的详述来描述BPEL4WS系统的细节问题。在文章前面提到的注释的问题实际上就是详述机制的问题，一个完备的BPEL4WS系统不仅要包括完整的系统模型元素，还要有详细的详述才能称得上是一个健壮的系统。
   2．修饰：UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上以扩展其含义。在BPEL4WS系统中，我们可以较自由地对系统中的各个元素进行修饰以扩充其含义，但注意要保证这种扩充是在受控制的范围中。
   3．通用划分；在对BPEL4WS系统建模时，我们可以采用两种通用划分的手段，一种是对类和对象的划分(类是一个抽象，而对象是这种抽象的一个具体形式)；第二种是对接口和实现的分离(接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实地实现接口的完整语义)。
   4．扩展机制：扩展机制是对已有的UML语义按不同系统的特点合理地进行扩展。UML扩展机制又包括如下三种。
   (1)构造型(Stereo type)：我们在对BPEL4WS系统建模的时候，会发现现有的UML构造块不能完整无歧义地表示出BPEL4WS系统中的每一元素，因此我们可以利用构造型来扩展UML的词汇，我们可以 利用它来创造新的构造块，这个新创造的构造块既可以从现有的构造块派生，又专门针对我们要解决的问题。
   (2)标记值(Tagged value)：利用标记值，我们可以扩展UML构造块的特性，我们可以根据我们的需要来创建详述元素的新元素。
   (3)约束(Constraint)：如果我们需要对UML构造块的语义进行扩展，我们就可以使用约束机制，这种机制使我们可以增加新的规则和修改现有的规则。

A

D

C

[解析]
   在面向对象技术中，对象在收到信息后要予以响应，不同的对象收到同一消息可产生完全不同的结果，这一现象称为多态。在使用多态技术时，用户可以发送一个通用的消息，而实现的细节则由接受对象自行决定，这样同一消息就可以调用不同的方法。多态有多种不同的形式，其中参数多态和包含多态称为通用多态，过载多态和强制多态称为特定多态。

A

A

D

[解析]
   原型化方法基于这样一种客观事实：并非所有的需求在系统开发之前都能准确地说明和定义。因此，它不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法。
   具有广泛技能高水平的原型化人员是原型实施的重要保证。原型化人员应该是具有经验与才干、训练有素的专业人员。衡量原型化人员能力的重要标准是他是否能够从用户的模糊描述中快速获取实际的需求。

C

A

D

C

B

[解析]
   演化模型是在快速开发一个原型的基础上，根据用户在试用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本。重复这一过程，直到演化成最终的软件产品。
   螺旋模型将瀑布模型和演化模型相结合，它综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程、客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的软件。
   喷泉模型主要用来描述面向对象的开发过程。它体现了面向对象开发过程的迭代和无间隙特征。迭代意味着模型中的开发活动常常需要多次重复；无间隙是指开发活动(如分析、设计)之间不存在明显的边界，各项开发活动往往交叉迭代地进行。

(1)起点：读者文件，终点：登记读者信息或3。
   (2)起点：处理查询请求或2，终点：读者文件。

[解析]
   (1)登记读者信息时，应该“写入”读者文件，而不应“读取”读者文件。因此，起点为读者文件、终点为3(登记读者信息)的数据流是错误的。
   (2)处理查询请求时，可能“读取”读者文件，而不能“写入”读者文件。因此，起点为2(处理查询请求)、终点为读者文件的数据流是错误的。

(1)起点：图书目录文件，终点：图书信息查询或2.2。
   (2)起点：借书文件，终点：读者信息查询或2.1。
   (3)起点：借书文件，终点：图书信息查询或2.2。

[解析]
   依照题意，读者信息查询可得到读者的基本信息以及读者借阅图书的情况，图书信息查询可得到图书基本信息和图书的借出情况。也就是说，读者信息查询时需“读取”读者文件与借书文件，图书信息查询时需要“读取”图书目录文件与借书文件。图7-20中还缺少：
   (1)起点为借书文件、终点为2.1(读者信息查询)的数据流；
   (2)起点为图书目录文件、终点为2.2(图书信息查询)的数据流；
   (3)起点为借书文件、终点为2.2(图书信息查询)的数据流。

系统的图书管理功能分为四个方面：购入新书、读者借书、读者还书以及图书注销。
   (2)入库单内容包括图书分类目录号、书名、作者、价格、数量和购书日期。

[解析]
   (1)[入库单|借书单|还书单|注销单]
   (2)分类目录号+书名+作者+价格+数量+购书日期

货物编码，货物名称，单价，仓库号，库存量。

[解析]
   货物关系模式的属性包括货物自身的属性-货物编码、货物名称、单价，以及货物的在仓库中的存放属性-仓库号和库存量。

补充后的图如图7-26所示。
   
   其中，联系名中的序号可任意排列。将联系3建立在出入库单和日汇总表之间也正确，或者同时建立两个联系也正确。

[解析]
   依照题意，存在以下五组实体联系。
   (1)出入库单与出入库记录，一对多联系(一张出入库单可以包含多个出入库记录，但一个出入库记录只能出现在一张出入库单上)。
   (2)货物与出入库记录，一对多联系(一种货物可以有多个出入库记录，但一个出入库记录上只能有一种货物)。
   (3)日汇总表与出入库记录，一对多联系(一张日汇总表可以包含多个出入库记录，但一个出入库记录只能出现在一张日汇总表上)。
   (4)仓库与货物，一对多联系(一个仓库可以存放多种货物，但一种货物只能存放在一个仓库)。
   (5)仓库与货物，一对多联系(一个仓库可以有多个管理员，但一个管理员只能在一个仓库)。

出入库单的主键：流水号
   出入库记录的主键：流水号，货物编码
   日汇总表的主键：日期，货物编码，出入库标志
   仓库的主键：仓库号
   管理员的主键：管理员号
   货物的主键：货物编码

[解析]
   流水号属性能够唯一标识出入库单关系模式的元组，可以作为出入库单关系模式的主键。
   流水号与货物编码属性集能够唯一标识出入库记录关系模式的元组，可以作为出入库记录关系模式的主键。
   日期、货物编码与出入库标志属性集能够唯一标识日汇总表关系模式的元组，可以作为日汇总表关系模式的主键。
   仓库号属性能够唯一标识仓库关系模式的元组，可以作为仓库关系模式的主键。
   管理员号属性能够唯一标识管理员关系模式的元组，可以作为管理员关系模式的主键。
   货物编码属性能够唯一标识货物关系模式的元组，可以作为货物关系模式的主键。

初录数据与复录数据。

[解析]
   依据题意，数据确认就是当初录数据与复录数据完全一致后，将其中的任一套作为最终进入系统A的原始数据。因此，数据确认处理所需的数据流在第1层图中的全部可选起点只能是初录数据与复录数据。

在0层图中，数据清除处理(加工6)没有输入数据流。

[解析]
   每个加工必须既有输入数据流，又有输出数据流。但在0层图中，数据清除处理(加工6)没有输入数据流。

①

[解析]
   根据表7-3可知，分户账清单是按照储蓄所排列的。

①、②、④

[解析]
   加工1(录入比对处理)只能检测出录入中的原始错误，如“输入的无效字符”、“输入的半个汉字”及“初录员重复录入同一账户”等。至于“汇总数据与会计账目不符”的错误，可能是系统A的汇总核对功能不正确，也可能是原来手工汇总的会计账目本身就不对。还有一种非常小的可能，初录员与复录员在录入数据时犯了完全相同的错误，但录入比对处理无法检测出这种错误。关于显示器与打印机的错误，录入比对处理当然更无法检测。

手工分户账=初录分户账+复录分户账。

[解析]
   对比第0层DFD中加工1(录入比对)的输入数据流与第1层DFD中加工1.1(初录)、加工1.2(复录)的输入数据流即知，于工分户账=初录分户账+复录分户账。

房间号，身份证号。

[解析]
   由题意可知，住宿关系尚缺房问号和身份证号属性。

住宿关系主键：房问号，身份证号，入住日期
   住宿关系外键：房间号，身份证号

[解析]
   住宿关系中的房间号、身份证号与入住日期属性集能够唯一标识该关系的元组，可以作为住宿关系的主键。
   住宿关系中的房间号属性，在房间关系中能够唯一标识该关系的元组。住宿关系中的身份证号属性，在客人关系中能够唯一标识该关系的元组。对于住宿关系，房问号与身份证号属性是外键。

(2)住宿，身份证号
   (3)HAVING
   (4)ORDER BY 2 DESC(或DSC)

[解析]
   SELECT语句由六个子句组成，完整的句法如下：
   SELECT       目标表的列名或列表达式序列
   FROM         基本表或(和)视图序列
   [WHERE       条件表达式]
   [GROUP BY    列名序列
   [HAVING      组条件表达式]]
   [ORDER BY    列名[序]……]
   整个SELECT语句语义如下：从FROM子句中列出的表中，选取满足WHERE子句中给出的条件表达式的元组，然后按GROUP BY子句中给定列的值分组，再提取满足HAVING子句中组条件表达式的那些组，按SELECT子句给出的列名或列表达式求值输出。ORDER BY子句是对输出的目标表进行排序，可附加ASC(升序)或DESC(降序)。

表：住宿
   属性：入住日期
   类型：聚簇索引(或聚集索引，或CLUSER)
   原因：表中记录的物理顺序与索引项的顺序一致，根据索引访问数据时，一次读取操作可以获取多条记录数据，因而可减少查询时间。

[解析]  
   由于住宿表中的记录是按照入住日期排列的，如果在住宿表的入住日期属性上创建聚簇索引，由于表中记录的物理顺序与索引项的顺序一致，根据索引访问数据时，一次读取操作可以获取多条记录数据，因而可减少查询时问。

(1)项目经理
   (2)程序员
   (3)系统分析师
   (4)测试员

[解析]
   项目经理一般参加项目的全过程，但在某些软件组织，项目经理并不参加早期的需求分析工作，而是在需求大致明确之后再任命项目经理。表7-4中的角色1从需求分析的后半段开始介入，一直到测试结束，在给定的4种角色之中，只有项目经理可以承担这一责任(无论其是否参与了需求分析的全过程)。
   系统分析师的主要职责是：(1)需求分析(在某些软件组织中，最早期的需求调查由商务人员进行，形成初步意向后，系统分析师才开始介入)。(2)系统分析(需求分析与系统分析可以合为一个过程，也可以分为两个过程。合为一个过程时，称系统分析、需求分析或系统需求分析均可，一般不区分这几种叫法的差异。分为两个过程时，需求分析的目标是为了与客户对系统需求达成一致意见，需求分析文档通常采用某种便于客户理解的形式(如用例图等)。而系统分析则是从技术角度(例如，数据、流程或类、对象等)对系统进行分析，系统分析文档通常采用某种便于开发人员理解的形式(例如，结构化方法的数据流图与数据字典，面向对象方法的类图、协作图等)。(3)在缺少系统架构设计师的情况下，系统分析师有时也会负责系统架构(或程序结构)的设计，但系统分析师一般不会从事系统的详细设计。表7-4中的角色3从需求分析的大约前半段开始介入，一直到系统分析的中期，在给定的4种角色之中，只有系统分析师符合这一角色。
   程序员主要负责编码和单元测试，与表7-4中的角色2恰好符合。
   测试员介入测试的仝过程，与表7-4中的角色4恰好符合。

(5)建立初始原型
   (6)运行原型
   (7)修改原型

[解析]
   原型化方法是一种逐步地、迭代地完成需求分析的策略，是一种动态定义系统需求的技术。
   原型是指快速建立起来的可以在计算机上运行的程序，它所完成的功能往往是最终软件产品功能的一个子集。原型化方法的第一步是收集用户的主要需求，并据此快速建立一个初始的软件原型(建立初始原型)，让用户在计算机上使用它(运行原型)，通过实际操作了解目标系统的概貌。开发人员按照用户提出的意见快速地修改原型系统(修改原型)，然后再次请用户试用……一旦用户认为这个原型系统确实能够满足他们的需求，开发人员便可据此书写软件需求说明，并根据这份文档开发出可以满足用户真实需求的软件产品。

(1)常用的三种网上电子支付方式是银行卡、电子现金、电子支票。
   (2)该网站提供的会员币属于电子现金支付方式。

[解析]
   网上支付是以互联网为基础，利用银行所支持的某种数字金融工具，发生在购买者和销售者之间的资金流转。常用的网上支付方式包括：
   ·银行卡支付方式-用户可以通过自己所拥有的借记卡、信用卡的银行，申请网上支付，通过网上银行直接转账；
   ·电子现金支付方式-电子现金是指用户可以购买、特定销售方可接受、以数字形式存在的货币，通常用于完成小额的网上支付。本题中该网站提供的会员币就是电子现金的一种形式；
   ·电子支票支付方式-将支票改变为带有数字签名的电子报文、或利用其他数字电文代替传统支票的全部信息，就是电子支票。利用电子支票，可以使支票的支付业务和支付过程电子化。

三种通用的异构数据库查询技术是公共数据库网关技术、公共协议技术、公共编程接口技术。

[解析]
   异构数据库系统是相关的多个数据库系统的集合，可以实现数据的共享和透明访问，每个数据库系统在加入异构数据库系统之前本身就已经存在，拥有自己的DMBS。异构数据库的各个组成部分具有自身的自治性，实现数据共享的同时，每个数据库系统仍保持有自己的应用特性、完整性控制和安全性控制。异构数据库系统的目标在于实现不同数据库之间的数据信息资源、硬件设备资源和人力资源的合并和共享。其中关键的一点就是以局部数据库模式为基础，建立全局的数据模式或全局外视图。通用的异构数据库查询技术主要包括公共数据库网关技术、公共协议技术、公共编程接口技术。