下半年试题及答案下午资料.docx

下半年试题及答案下午资料.docx

《下半年试题及答案下午资料.docx》由会员分享，可在线阅读，更多相关《下半年试题及答案下午资料.docx（30页珍藏版）》请在冰豆网上搜索。

下半年试题及答案下午资料

第8章软件设计师下午试题分析与解答

试题一

阅读下列说明和图，回答问题1至问题4，将解答填入答题纸的对应栏内。

[说明]

某公司欲开发招聘系统以提高招聘效率，其主要功能如下：

（1）接受申请

验证应聘者所提供的自身信息是否完整，是否说明了应聘职位，受理验证合格的申请，给应聘者发送致谢信息。

（2）评估应聘者

根据部门经理设置的职位要求，审查已经受理的申请；对未被录用的应聘者进行谢绝处理，将未被录用的应聘者信息存入未录用的应聘者表，并给其发送谢绝决策；对录用的应聘者进行职位安排评价，将评价结果存入评价结果表，并给其发送录用决策，发送录用职位和录用者信息给工资系统。

现采用结构化方法对招聘系统进行分析与设计，获得如图1-1所示的顶层数据流图、图1-2所示0层数据流图和图1-3所示1层数据流图。

[问题1]

使用说明中的术语，给出图中E1～E3所对应的实体名称。

答：

E1:

应聘者E2:

部门经理E3:

工资系统

[问题2]

使用说明中的术语，给出图中D1～D2所对应的数据存储

答：

D1:

未录用的应聘者表D2:

评价结果表

[问题3]

使用说明和图中的术语，给出图1-3中加工P1～P3的名称。

答：

P1:

验证申请P2:

审查申请P3:

职位安排评价

[问题4]

解释说明图1-2和图1-3是否保持平衡，若不平衡请按如下格式补充图1-3中数据流的名称以及数据流的起点或终点，使其平衡（使用说明中的术语或图中符号）。

答：

数据流名称

起点

录用职位

P3或2.3职位安排评价

已受理的申请

1.2受理申请

谢绝决策

2.2谢绝应聘者

试题二

阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。

[说明]

某物流公司为了整合上游供应商与下游客户，缩短物流过程，降低产品库存，需要构建一个信息系统以方便管理其业务运作活动。

[需求分析结果]

（1）物流公司包含若干部门，部门信息包括部门号、部门名称、经理、电话和邮箱。

一个部门可以有多名员工处理部门的日常事务，每名员工只能在一个部门工作。

每个部门有一名经理，只需负责管理本部门的事务和人员。

（2）员工信息包括员工号、姓名、职位、电话号码和工资；其中，职位包括：

经理、业务员等。

业务员根据托运申请负责安排承运货物事宜，例如：

装货时间、到达时间等。

一个业务员可以安排多个托运申请，但一个托运申请只由一个业务员处理。

（3）客户信息包括客户号、单位名称、通信地址、所属省份、联系人、联系电话、银行账号，其中，客户号唯一标识客户信息的每一个元组。

每当客户要进行货物托运时，先要提出货物托运申请。

托运申请信息包括申请号、客户号、货物名称、数量、运费、出发地、目的地。

其中，一个申请号对应唯一的一个托运申请；一个客户可以有多个货物托运申请，但一个托运申请对应唯一的一个客户号。

[概念模型设计]

根据需求阶段收集的信息，设计的实体联系图和关系模式（不完整）如图2-1所示。

[关系模式设计]

部门（部门号，部门名称，经理，电话，邮箱）

员工（员工号，姓名，职位，电话号码，工资，（a）部门号）

客户（（b），单位名称，通信地址，所属省份，联系人，联系电话，银行账号）

托运申请（（c），货物名称，数量，运费，出发地，目的地）申请号、客户号、货物名称、数量、运费、出发地、目的地

安排承运（（d），装货时间，到达时间，业务员）

[问题1]

根据问题描述，补充四个联系、联系的类型，以及实体与子实体的联系，完善图2-1所示的实体联系图。

答：

nn11

n

111

[问题2]

根据实体联系图，将关系模式中的空（a）～（d）补充完整。

分别指出部门、员工和安排承运关系模式的主键和外键。

答：

（1）

a:

部门号

b:

客户号

c:

申请号、客户号

d:

申请号

（2）

部门：

主键：

部门号外键：

无

员工：

主键：

员工号外键：

部门号

安排承运：

主键：

申请号外键：

无

[问题3]

若系统新增需求描述如下：

为了数据库信息的安全性，公司要求对数据库操作设置权限管理功能，当员工登录系统时，系统需要检查员工的权限。

权限的设置人是部门经理。

为满足上述需要，应如何修改（或补充）图2-1所示的实体联系图，请给出修改后的实体联系图和关系模式。

答：

1

nnn1

111

1n

试题二分析

本题考查数据库系统中实体联系模型（E-R模型）和关系模式设计方面的应用知识。

[问题1]

两个实体集之间的联系类型分为三类：

一对一（1:

1）联系、一对多（1:

n）联系和多对多（m:

n）联系。

根据题意，每名员工只能在一个部门工作，所以部门和员工之间有一个1:

n的“所属”联系；由于每个部门有一名经理，只需负责管理本部门的事务和人员，因此部门和经理之间有一个1:

1的“管理”联系；由于一个业务员可以安排多个托运申请，但一个托运申请只由一个业务员处理，故业务员和托运申请之间有一个1:

n的“托运”联系；又由于一个客户可以有多个货物托运申请，但一个托运申请对应唯一的一个客户号，故客户和托运申请之间有一个1:

n的“申请”联系。

根据上述分析，完善图2-1所示的实体联系图可参见参考答案。

[问题2]

根据题意，部门和员工之间有一个1:

n的“所属”联系需要将一端的码并入多端，故员工关系模式中的空（a）应填写部门号；在客户关系模式中，客户号为主键，故空（b）应填写客户号；在托运申请关系模式中，申请号、客户号为主键，故空（c）应填写申请号、客户号；又由于一个业务员可以安排多个托运申请，但一个托运申请只由一个业务员处理，因此在安排承运关系模式中，申请号为主键，故空（d）应填写申请号。

部门关系模式中的部门号为主键，经理为外键；因为经理来自员工关系。

员工关系模式中的员工号为主键，部门号为外键，因为部门号来自部门关系。

安排承运关系模式中的申请号为主键，业务员为外键，因为业务员来自员工关系。

[问题3]

根据题意，权限的设置人是部门经理，因此，需要建立一个权限关系模式，以及经理到权限之间的1:

n的“设置”联系。

修改后的实体联系图和关系模式参见参考答案。

参考答案

[问题1]

[问题2]

（a）

部门号

（b）

客户号

（c）

申请号，客户号

（d）

申请号

部门

主键：

部门号

外键：

经理

员工

主键：

员工号

外键：

部门号

安排承运

主键：

申请号

外键：

业务员

[问题3]

关系模式：

权限（员工号，权限，设置人）

或权限（员工号，权限，部门经理）

试题三

阅读下列说明和图，回答问题1至问题3，将解答填入答题纸的对应栏内。

[说明]

Pay&Drive系统（开多少付多少）能够根据驾驶里程自动计算应付的费用。

系统中存储了特定区域的道路交通网的信息。

道路交通网由若干个路段（RoadSegment）构成，每个路段由两个地理坐标点（Node）标定，其里程数（Distance）是已知的。

在某些地理坐标点上安装了访问控制（AccessControl）设备，可以自动扫描行驶卡（Card）。

行程（Trajectory）由一组连续的路段构成。

行程的起点（Entry）和终点（Exit）都装有访问控制设备。

系统提供了3种行驶卡。

常规卡（RegularCard）有效期（ValidPeriod）为一年，可以在整个道路交通网内使用。

季卡（SeasonCard）有效期为三个月，可以在整个道路交通网内使用。

单次卡（MinitripCard）在指定的行程内使用，且只能使用一次。

其中，季卡和单次卡都是预付卡（PrepaidCard），需要客户（Customer）预存一定的费用。

系统的主要功能有：

客户注册、申请行驶卡、使用行驶卡行驶等。

使用常规卡行驶，在进入行程起点时，系统记录行程起点、进入时间（DateOfEntry）等信息。

在到达行程终点时，系统根据行驶的里程数和所持卡的里程单价（UnitPrice）计算应付费用，并打印费用单（Invoice）。

季卡的使用流程与常规卡类似，但是不需要打印费用单，系统自动从卡中扣除应付费用。

单次卡的使用流程与季卡类似，但还需要在行程的起点和终点上检查行驶路线是否符合该卡所规定的行驶路线。

现采用面向对象方法开发该系统，使用UML进行建模。

构建出的用例图和类图分别如图3-1和图3-2所示。

[问题1]

根据说明中的描述，给出图3-1中U1和U2所对应的用例，以及

（1）所对应的关系。

答：

U1:

使用常规卡行驶U2：

使用单次卡行驶

（1）：

<>

[问题2]

根据说明中的描述，给出图3-2中缺少的C1～C6所对应的类名以及

（2）～（3）处所对应的多重度（类名使用说明中给出的英文词汇）。

答：

C1:

RoadSegmentC2:

Trajectory

C3:

CardC4:

RegularCard

C5:

PrepaidCardC6:

MinitripCard

（2）:

1

（3）:

1…3

[问题3]

根据说明中的描述，给出RoadSegment、Trajectory和Card所对应的类的关键属性（属性名使用说明中给出的英文词汇）。

答：

RoadSegment的属性：

Distance

Trajectory的属性：

Entry、Exit、DateOfEntry

Card的属性：

UnitPrice、ValidPeriod

试题三分析

本题属于经典的考题，主要考查面向对象分析方法以及UML的用例图和类图的相关知识。

[问题1]

本问题要求将图3-1所给出的用例图补充完整。

用例图的构成要素有：

参与者、用例以及用例之间的关系。

图中缺少了两个用例，以及一个用例关系。

解答此题时，首先应从说明中找到所有的用例。

用例表示系统的一个单一业务功能。

从题目的描述中可以看出，系统的主要功能就是申请行驶卡，以及使用行驶卡行驶。

由于行驶卡分为三种，所以在说明中详细描述了三种行驶卡的使用方法。

再结合用例图来看，缺少的两个用例与用例“使用季卡行驶”有关联关系，由此可以推断出，需要补充的这两个用例必定与另外两种行驶卡相关，分别为“使用常规卡行驶”和“使用单次卡行驶”。

下面需要解决的问题是这两个用例与U1和U2的对应关系。

这就需要仔细考查一下用例图所给出的用例关系。

由图3-1可知，U1和“使用季卡行驶”之间是泛化（generalization）关系。

当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象为父用例，其他的用例作为泛化关系中的子用例。

在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

根据说明中的“季卡的使用流程与常规卡类似，但是不需要打印费用单，系统自动从卡中扣除应付费用”可知，U1应该对应着用例“使用常规卡行驶”。

由此不难得出U2对应着用例“用单次卡行驶”。

现在图中只剩下

（1）处的用例关系没有确定。

用例之间的关系在用例图上只有三种：

包含（include）、扩展（extend）和泛化（generalization）。

包含关系是指当多个用例中存在相同事件流时，可以把这些公共事件流抽象成为公共用例，这个公共用例称为抽象用例，而原始用例称为基础用例。

基础用例和抽象用例之间是包含关系。

如果一个用例明显地混合了两种或两种以上的不同场景，则可以将这个用例分为一个基本用例和多个扩展用例。

扩展关系用“《extend》”表示，箭头指向基本用例。

包含关系和扩展关系的区别在于，抽象用例中的事件流一定要插入到基本用例中去，并且插入点只有一个，通常抽象用例不能脱离基本用例而独立存在。

扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的事件流中，并且插入点可以有多个。

根据以上分析可知，

（1）处的用例关系选择“《extend》”最为合适。

[问题2]

本问题考查的是类图建模。

解题的重点在于根据类图中提供的类及类之间的关联关系，推断出剩余的类。

可以先观察一下类图。

可以看到，需要补充的类基本上集中在两个结构上：

聚集结构（类C1和C2）以及继承结构（类C3～C6）。

继承结构是比较容易辨识的类之间的关联关系，图上给出了其中的一个子类SeasonCard。

以这个类为线索，回到说明中寻找与类SeasonCard相关的其他类。

从说明中可知，“系统提供了3种卡”，常规卡、季卡、单次卡，而“季卡和单次卡都是预付卡”。

这些描述暗示，“季卡”、“单次卡”与“预付卡”之间存在着特殊/一般关系，即“is-a”关系，这是继承结构的典型标志。

由此可以得出类C5和C6应该分别对应PrepaidCard（预付卡）和MinitripCard（单次卡）。

根据C5和C6所对应的类，可以推断出，C4和C3必定也是与行驶卡相关的类。

三种卡中，已经有两种卡有了对应的类，还剩下一种卡即“常规卡”。

而“常规卡”只能是与“预付卡”同层次的概念，所以只能对应于C4，C3表示的是能代表所有这几种卡的公共概念。

所以C3和C4应分别对应于Card和RegularCard。

确定了C3之后，就可以识别出

（2）和（3）处的多重度。

Customer和Card之间是持有和被持有的关系，由于系统中只有3种卡，所以一个客户最多只能有3种卡，所以（3）处应填1..3。

而对于任何一张卡来说，只能有唯一地一个所属人，因此

（2）处应填1。

现在还剩下类C1和C2没有确定。

由于这两个类之间是聚集关系，所以需要在说明中寻找具有“部分一整体”关系的概念。

由说明中的“行程（Trajectory）由一组连续的路段构成”可知，C1和C2应分别对应于RoadSegment和Trajectory。

[问题3]

本问题考查类的关键属性的识别。

由说明中给出的描述可知，类RoadSegment的属性至少应包括Distance；类Trajectory的属性至少应包括Entry、Exit和DateOfEntry;类Card的属性至少应包括UnitPrice、ValidPeriod。

参考答案

[问题1]

U1：

使用常规卡行驶U2：

使用单次卡行驶

（1）：

extend

[问题2]

C1：

RoadSegmentC2：

TrajectoryC3：

Card

C4：

RegularCardC5：

PrepaidCardC6：

MinitripCard

（2）1（3）1..3

[问题3]

RoadSegment的属性：

Distance

Trajectory的属性：

Entry、Exit、DateOfEntry

Card的属性：

UnitPrice、ValidPeriod

试题四

阅读下列说明和C代码，将应填入（n）处的字句写在答题纸的对应栏内。

[说明]

设某一机器由n个部件组成，每一个部件都可以从m个不同的供应商处购得。

供应商j供应的部件i具有重量wij和价格cij。

设计一个算法，求解总价格不超过上限cc的最小重量的机器组成。

采用回溯法来求解该问题：

首先定义解空间。

解空间由长度为n的向量组成，其中每个分量取值来自集合{1，2，…，m），将解空间用树形结构表示。

接着从根结点开始，以深度优先的方式搜索整个解空间。

从根结点开始，根结点成为活结点，同时也成为当前的扩展结点。

向纵深方向考虑第一个部件从第一个供应商处购买，得到一个新结点。

判断当前的机器价格（c11）是否超过上限（cc），重量（w11）是否比当前已知的解（最小重量）大，若是，应回溯至最近的一个活结点；若否，则该新结点成为活结点，同时也成为当前的扩展结点，根结点不再是扩展结点。

继续向纵深方向考虑第二个部件从第一个供应商处购买，得到一个新结点。

同样判断当前的机器价格（c11+c21）是否超过上限（cc），重量（w11+w21）是否比当前已知的解（最小重量）大。

若是，应回溯至最近的一个活结点；若否，则该新结点成为活结点，同时也成为当前的扩展结点，原来的结点不再是扩展结点。

以这种方式递归地在解空间中搜索，直到找到所要求的解或者解空间中已无活结点为止。

[C代码]

下面是该算法的C语言实现。

（1）变量说明

n：

机器的部件数

m：

供应商数

cc：

价格上限

w[][]：

二维数组，w[i][j]表示第j个供应商供应的第i个部件的重量

c[][]：

二维数组，c[i][j]表示第j个供应商供应的第i个部件的价格

bestW：

满足价格上限约束条件的最小机器重量

bestC：

最小重量机器的价格

bestX[]：

最优解，一维数组，bestX[i]表示第i个部件来自哪个供应商

cw：

搜索过程中机器的重量

cp：

搜索过程中机器的价格

x[]：

搜索过程中产生的解，x[i]表示第i个部件来自哪个供应商

i：

当前考虑的部件，从0到n-1

j：

循环变量

（2）函数backtrack

intn=3;

intm=3;

intcc=4;

intw[3][3]={{1,2,3},{3,2,1},{2,2,2}};

intc[3][3]={{1,2,3},{3,2,1},{2,2,2}};

intbestW=8;

intbestC=0;

intbestX[3]={0，0，0};

intcw=0;

intcp=0;

intx[3]={0，0，0};

intbacktrack（inti）{

intj=0;

intfound=0;

if（i＞n-1）{/*得到问题解*/

bestW=cw;

bestC=cp;

for（j=0;j＜n;j++）{

（1）;//bestX[j]=x[j]

}

return1;

}

if（cp＜=cc）（/*有解*/

found=1;

}

for（j=0;

（2）;j++）{//j

/*第i个部件从第j个供应商购买*/

（3）;//x[i]=j

cw=cw+w[i][j];

cp=cp+c[i][j];

if（cp＜=cc&&（4））{/*深度搜索，扩展当前结点*/

//cw<=bestW

if（backtrack（i+1））{found-1;）

}

/*回溯*/

cw=cw-w[i][j];

（5）;//cp=cp-c[i][j]

}

returnfound;

}

试题四分析

本题考查算法的设计和分析技术中的回溯法。

回溯法是一种系统搜索问题解的方法，在包含问题所有解的解空间树中，按照深度优先的策略，从根结点出发搜索解空间树。

算法在到达解空间树的任一结点时，总是先判断该结点是否肯定不包含问题的解。

若肯定不包含，则跳过对以该结点为根的子树的系统搜索，逐层向其祖先结点回溯；否则进入该子树，继续按深度优先的策略进行搜索。

回溯法在求问题的最优解时，要回溯到根，且根结点的所有子树都已经被搜索遍才结束。

根据上述思想和题干说明，对实例：

部件数n=3，厂商数m=3，具体的重量和价格如表4-1所示。

构造该实例的解空间树如图4-1所示。

图4-1中结点编号表示生成该结点的顺序。

边上的编号表示哪个部件选择哪个厂商，如x

（2）=1，表示第2个部件来自厂商1。

结点旁边的两个数字表示当前解或部分解对应的重量和价格，如2:

2表示重量为2，价格为2。

从图4-1可以看出，最优解是结点20表示的解，即x

（1）=1，x

（2）=3，x（3）=1，即第1个部件来自厂商1，第2个部件来自厂商3，第3个部件来自厂商1，总的价格和重量分别为4和4。

当然，本实例的最优解还可以是x

（1）=1，x

（2）=3，x（3）=2和x

（1）=1，x

（2）=3，x（3）=3，分别对应解空间树上的21号和22号结点。

代码中的空

（1）处是得到问题解之后，将搜索过程中产生的重量cw、价格cp和解x放到最终重量bestW、价格bestC和解bestX中，因此空格

（1）处填写bestX[j]=x[j]。

空

（2）处的for循环是考虑第i个部件选择哪个厂商，因此j从0到m-1依次检查，此处应填j＜m。

对搜索过程中产生的重量cw、价格cp和解x的值进行设置，因此空（3）处应填x[i]=j，表示第i个部件选择厂商j。

空（4）是判断当前结点是否要扩展，若当前获得的价格比目前最优解更优，且重量没有超过当前得到的最优重量，即cp＜=cc且cw＜bestW，则扩展当前结点，否则回溯。

在回溯过程中，需要把原来选择的部件的价格和重量从搜索过程中产生的重量cw和价格cp中去掉，因此空（5）应填cp=cp=c[i][j]。

参考答案

（1）bestX[j]=x[j]

（2）j＜m（3）x[i]=j

（4）cw＜bestW（5）cp=cp-c[i][j]

试题五

阅读下列说明和C++代码，将应填入（n）处的字句写在答题纸的对应栏内。

[说明]

某大型商场内安装了多个简易的纸巾售卖机，自动出售2元钱一包的纸巾，且每次仅售出一包纸巾。

纸巾售卖机的状态图如图5-1所示。

图5-1纸巾售卖机的状态图

采用状态（State）模式来实现该纸巾售卖机，得到如图5-2所示的类图。

其中类State为抽象类，定义了投币、退币、出纸巾等方法接口。

类SoldState、SoldOutState、NoQuarterState和HasQuarterState分别对应图5-1中纸巾售卖机的4种状态：

售出纸巾、纸巾售完、没有投币、有2元钱。

[C++代码]

#include＜iostream＞

usingnamespacestd;

//以下为类的定义部分

classTissueMachine;//类的提前引用

classState{

public：

virtualvoidinsertQuarter（）=0;//投币

virtualvoidejectQuarter（）=0;//退币

virtualvoidturnCrank（）=0;//按下“出纸巾”按钮

virtualvoiddispense（）=0;//出纸巾

};

/*类SoldOutState、NoQuarterState、HasQuarterState、SoldState的定义省略，每个类中均定义了私有数据成员TissueMachine*tissueMachine;*/

classTissueMachine{

private：

（1）*soldOutState,*noQuarterState,*hasQuarterState,*soldState，*state;//

（1）State

intcount;//纸巾数

public：

TissueMachine（intnumbers）;

voidsetState（State*state）;

State*getHasQuarterState（）;

State*getNoQuarterState（）;

State*getSoldState（）;

State*getSoldOutState（）;

intgetCount（）;

//其余代码省略

};

//以下为类的实现部分

voidNoQuarterState:

:

insertQuarter（）{

tissueMachine->setState（

（2））;//

（2）tissueMachine-＞getHasQuarterState（）

）