2011(下半年)试题及答案(下午)

第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所示的实体联系图。答：nn11n111[问题2]根据实体联系图，将关系模式中的空(a)～(d)补充完整。分别指出部门、员工和安排承运关系模式的主键和外键。答：（1）a:部门号b:客户号c:申请号、客户号托运申请客户员工部门处理申请安排管理业务员经理d:申请号（2）部门：主键：部门号外键：无员工：主键：员工号外键：部门号安排承运：主键：申请号外键：无[问题3]若系统新增需求描述如下：为了数据库信息的安全性，公司要求对数据库操作设置权限管理功能，当员工登录系统时，系统需要检查员工的权限。权限的设置人是部门经理。为满足上述需要，应如何修改(或补充)图2-1所示的实体联系图，请给出修改后的实体联系图和关系模式。答：1nnn11111n权限客户员工部门处理申请安排管理业务员经理设置托运申请试题二分析本题考查数据库系统中实体联系模型(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][问题3](a)部门号(b)客户号(c)申请号，客户号(d)申请号部门主键：部门号外键：经理员工主键：员工号外键：部门号安排承运主键：申请号外键：业务员关系模式：权限(员工号，权限，设置人)或权限(员工号，权限，部门经理)试题三阅读下列说明和图，回答问题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）：extend[问题2]根据说明中的描述，给出图3-2中缺少的C1～C6所对应的类名以及(2)～(3)处所对应的多重度(类名使用说明中给出的英文词汇)。答：C1:RoadSegmentC2:TrajectoryC3:CardC4:RegularCardC5:PrepaidCardC6:MinitripCard(2):1(3):1…3[问题3]根据说明中的描述，给出RoadSegment、Trajectory和Card所对应的类的关键属性(属性名使用说明中给出的英文词汇)。答：RoadSegment的属性：DistanceTrajectory的属性：Entry、Exit、DateOfEntryCard的属性：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”关系，这是继承结构的典型标