[语言类考试复习资料大全]中级软件设计师下午试题模拟55

1、书山有路勤为径，学海无涯苦作舟。祝愿天下莘莘学子：学业有成，金榜题名！语言类考试复习资料大全中级软件设计师下午试题模拟55中级软件设计师下午试题模拟55试题1阅读以下说明和数据流图，根据要求回答下列问题。 说明 现准备为某银行开发一个信用卡管理系统CCMS，该系统的基本功能如下。 1信用卡申请。非信用卡客户填写信用卡申请表，说明所要申请的信用卡类型及申请者的基本信息，提交CCMS。如果信用卡申请被银行接受，CCMS将记录该客户的基本信息，并发送确认函给该客户，告知客户信用卡的有效期及信贷限额；否则该客户将会收到一封拒绝函。非信用卡客户收到确认函后成为信用卡客户。 2信用卡激活。信用卡客户向CC

2、MS提交激活请求，用信用卡号和密码激活该信用卡。激活操作结束后，CCMS将激活通知发送给客户，告知客户其信用卡是否被成功激活。 3信用卡客户信息管理。信用卡客户的个人信息可以在CCMS中进行在线管理。每位信用卡客户可以在线查询和修改个人信息。 4交易信息查询。信用卡客户使用信用卡进行的每一笔交易都会记录在CCMS中。信用卡客户可以通过CCMS查询并核实其交易信息(包括信用卡交易记录及交易额)。 图8-15和图8-16分别给出了该系统的顶层数据流图和0层数据流图的初稿。 1. 问题1 根据说明，将图8-15中的E1E3填充完整。 答案:E1：非信用卡客户 E2：信用卡客户 E3：银行由题干关键信

3、息“1信用卡申请。非信用卡客户填写信用卡申请表CCMS将记录该客户的基本信息，并发送确认函给该客户否则该客户将会收到一封拒绝函”，以及图8-15中数据流“确认函”、“拒绝函”等信息可知，外部实体E1的名称是“非信用卡客户”。 由题干关键信息“2信用卡客户向CCMS提交激活请求CCMS将激活通知发送给客户”和图8-15中数据流“激活通知”，题干信息“3每位信用卡客户可以在线查询和修改个人信息”和图8-15中数据流“查询/修改个人信息”、“个人信息”，题干信息“4信用卡客户可以通过CCMS查询并核实其交易信息”和图8-15中数据流“交易记录查询请求”可知，外部实体E2的名称是“信用卡客户”。 由题

4、干说明中“1信用卡申请。如果信用卡申请被银行接受”、图8-15中数据流“信用卡申请信息”、“信用卡申请验证结果”和常识等关键信息可知，外部实体E3的名称是“银行”。 2. 问题2 图8-15中缺少3条数据流，根据说明，分别指出这3条数据流的起点和终点。(注：数据流的起点和终点均采用图中的符号和描述。) 答案:起点 终点 名称 E1 P0 信用卡申请表 E2 P0 激活请求 P0或信用卡管理系统CCMS E2 信用卡交易信息将问题1的分析结果填写到图8-15中，由题干关键信息“1非信用卡客户填写信用卡申请表提交CCMS”，图8-15中数据流“确认函”、“拒绝函”及其流向等综合信息可知，外部实体E

5、1“非信用卡客户”有一条输出数据流“信用卡申请表”，流向加工P0“信用卡管理系统CCMS”。换而言之，图8-15中缺少了1条名称为“信用卡申请表”的数据流，其起点是E1，终点为P0。 同理，由题干关键信息“2信用卡激活。信用卡客户向CCMS提交激活请求”和图8-15中数据流“激活通知”及其流向等综合信息可知，外部实体E2“信用卡客户”有一条输出数据流“激活请求”，流向加工P0“信用卡管理系统CCMS”。换而言之，图8-15中缺少了一条名称为“激活请求”的数据流，其起点是E2，终点为P0。 由题干关键信息“4交易信息查询信用卡客户可以通过CCMS查询并核实其交易信息”、图8-15中数据流“交易记

6、录查询请求”及其流向和生活常识等综合信息可知，加工P0“信用卡管理系统CCMS”有一条输出数据流“信用卡交易信息”，流向外部实体E2“信用卡客户”。换而言之，图8-15中缺少了一条名称为“信用卡交易信息”的数据流，其起点是P0，终点为E2。 3. 问题3 图8-16中有两条数据流是错误的，请指出这两条数据流的名称，并改正。(注：数据流的起点和终点均采用图中的符号和描述。) 答案:错误的数据流名称：激活请求和信用卡申请表 改正后的数据流： 数据流名称 改正后数据流起点 改正后数据流终点 激活请求 E2 P3 信用卡申请表 E1 P4将问题1和问题2的分析结果填写到图8-15中。题干说明中“信用卡

7、申请”、“信用卡激活”、“信用卡客户信息管理”和“交易信息查询”是典型的加工名称。根据数据流图父图与子图数据平衡原则，对照图8-16和信息填充后的图8-15可以直观地发现，图8-16中存在的一条错误数据流是“信用卡申请表”。数据流“信用卡申请表”在图8-15中是从外部实体E1流向CCMS系统，而在图8-16中是从加工P4流向外部实体E1，应以予更正。 根据题干说明中“1信用卡申请”描述信息，结合图8-16中与加工P4相关的“信用卡申请表”、“信用卡申请信息”、“信用卡申请验证结果”等关键数据流信息可得，加工P4的名称是“信用卡申请”。图8-16中数据流“信用卡申请表”的起点应改正为E1，终点应

8、修改为P4。 同理，在图8-15中数据流“激活请求”从外部实体E2流向CCMS系统，而在图8-16中是从加工P4流向加工P3，应以予更正。根据题干说明中“2信用卡激活”描述信息，结合图8-16中加工P3的输出数据流“激活通知”等信息可得，加工P3的名称是“信用卡激活”。图8-16中数据流“激活请求”的起点应改正为E2，终点应修改为P3。 4. 问题4 根据说明，将图8-16中P1P4的处理名称填充完整。 答案:P1：交易信息查询 P2：(信用卡)客户信息管理 P3：信用卡激活 P4：信用卡申请根据题干说明中“3信用卡客户信息管理”描述信息，结合图8-16中与加工P2相关的“查询/修改个人信息”

9、、“个人信息”等关键数据流信息可得，加工P2的名称是“信用卡客户信息管理”。 根据题干说明中“4交易信息查询”描述信息，结合图8-16中与加工P1相关的“交易记录查询请求”、“交易信息”等关键数据流信息可得，加工P1的名称是“交易信息查询”。 根据问题3的分析结果可知，加工P3的名称是“信用卡激活”，加工P4的名称是“信用卡申请”。 试题2阅读下列说明，根据要求回答下列问题。 说明 某地区举行篮球比赛，需要开发一个比赛信息管理系统来记录比赛的相关信息。 需求分析结果 1登记参赛球队的信息。记录球队的名称、代表地区、成立时间等信息。系统记录球队的每个队员的姓名、年龄、身高、体重等信息。每个球队有

10、一个教练负责管理球队，一个教练仅负责一个球队。系统记录教练的姓名、年龄等信息。 2安排球队的训练信息。比赛组织者为球队提供了若干个场地，供球队进行适应性训练。系统记录现有的场地信息，包括场地名称、场地规模、位置等信息。系统可为每个球队安排不同的训练场地，如表8-6所示。系统记录训练场地安排的信息。 表8-6 训练安排表 球队名称 场地名称 训练时间 解放军 一号球场 2008-06-09 14:0018:00 解放军 一号球场 2008-06-12 09:0012:00 解放军 二号球场 2008-06-11 14:0018:00 山西 一号球场 2008-06-10 09:0012:00 3

11、安排比赛。该赛事聘请了专职裁判，每场比赛只安排一个裁判。系统记录裁判的姓名、年龄、级别等信息。系统按照一定的规则，首先分组，然后根据球队、场地和裁判情况，安排比赛(每场比赛的对阵双方分别称为甲队和乙队)。记录参赛球队、比赛时间、比分、场地名称等信息，如表8-7所示。 表8-7比赛安排表 A组： 甲队乙队 场地名称 比赛时间 裁判 比分 解放军北京 一号球场 2008-06-17 15:00 李大明 天津山西 一号球场 2008-06-17 19:00 胡学梅 B组： 甲队乙队 场地名称 比赛时间 裁判 比分 上海安徽 二号球场 2008-06-17 15:00 丁鸿平 山东辽宁 二号球场 20

12、08-06-17 19:00 郭爱琪 4所有球员、教练和裁判可能出现重名情况。 概念模型设计 根据需求阶段收集的信息，设计的实体联系图和关系模式(不完整)如下。 1实体联系图(如图8-17所示) 2关系模式 教练(教练编号，姓名，年龄) 队员(队员编号，姓名，年龄，身高，体重， (a) ) 球队(球队名称，代表地区，成立时间， (b) ) 场地(场地名称，场地规模，位置) 训练记录( (c) ) 裁判(裁判编号，姓名，年龄，级别) 比赛记录( (d) ) 1. 问题1 根据问题描述，补充4个联系，完善图8-17的实体联系图。 答案:参见图8-25 本题考查读者对数据库概念结构设计及向逻辑结构转

13、换的掌握情况。此类题目要求认真阅读题目对现实问题的描述，经过分类、聚集、概括等方法，从中确定实体及其联系。题目已经给出了4个实体，需要根据需求描述，给出实体间的联系。 由“每个球队有一个教练负责管理球队，一个教练仅负责一个球队。”知球队与教练间为1:1联系；球队与队员之间应为1:N联系；多个球队使用多个训练场地，球队与场地之间为M:M联系；比赛是球队、场地与裁判之间的联系，一个球队会与同组的其他多个队之间比赛，有多个场地和裁判，一位裁判会对多场比赛判罚，一个场地会有多场比赛，涉及多个球队和裁判，因此球队、场地与裁判之间的比赛关系为M:N:P联系。补充完整的实体联系图如图8-25所示。 2. 问

14、题2 根据你的实体联系图，完成关系模式，并给出训练记录和比赛记录关系模式的主键和外键。 答案:填空： (a)球队名称 (b)教练编号 (c)球队名称，场地名称，开始时间，结束时间 (d)甲队，乙队，比赛时间，场地名称，比分，裁判，分组 主键： 训练记录(球队，开始时间)或训练记录(场地名称，开始时间) 或训练记录(球队，结束时间)或训练记录(场地名称，结束时间) 比赛记录(场地名称，比赛时间)或比赛记录(裁判，比赛时间) 或比赛记录(甲队，比赛时间)或比赛记录(乙队，比赛时间) 外键： 训练记录的外键：球队名称，场地名称 比赛记录的外键：甲队，乙队，场地名称，裁判根据补充后的E-R图，球队与球

15、员之间的1:N联系应通过将1端实体(球员)的主码(球队名称)加入到N端实体(球员)对应的关系中来表达。这类联系也可通过一个独立的关系来表达，如球队一球员(球队名称，队员编号)，这样会对查询增加多余的连接操作，因此一般不采用这种方法。 同样，球队与教练之间的1:1联系也应通过将一方的主码增加到另一方实体对应的关系中，来表达联系。 训练和比赛为多对多联系，只能独立成一个关系模式，由该联系相关连的各实体的码及联系自有的属性构成。如比分和分组应该是比赛的属性，再加上球队、裁判、场地的码，即构成“比赛记录”的关系模式。比赛记录关系模式的主键可以是“场地名称，比赛时间”，也可以是“裁判，比赛时间”，或者是

16、“甲队，比赛时间”，再或者是“乙队，比赛时间”。其外键是“甲队，乙队，场地名称，裁判”。 同理，训练是球队和场地的多对多联系，训练开始时间和结束时间为训练的属性，加上球队的码和场地的码，构成“训练记录”关系模式。训练记录关系模式的主键可以是“球队，开始时间”，也可以是“场地名称，开始时间”，或者是“球队，结束时间”，再或者是“场地名称，结束时间”。其外键是“球队名称，场地名称”。 3. 问题3 如果考虑记录一些特别资深的热心球迷的情况，每个热心球迷可能支持多个球队。热心球迷的基本信息包括姓名、住址和喜欢的俱乐部等。根据这一要求修改图8-17的实体联系图，给出修改后的关系模式。 答案:修改后的E

17、-R图见图8-26， 新增的关系模式如下： 热心球迷(球迷编号，姓名，住址，俱乐部) 支持球队(球迷编号，球队)球迷与球队之间为多对多联系，需新增球迷实体和球迷与球队之间的支持联系，如图8-26所示。 新增的关系模式如下。 热心球迷(球迷编号，姓名，住址，俱乐部) 支持球队(球迷编号，球队) 试题3阅读以下技术说明，根据要求回答下列问题。 说明 某汽车停车场欲建立一个信息系统，已经调查到的需求如下。 1在停车场的入口和出口分别安装一个自动栏杆、一台停车卡打印机、一台读卡器和一个车辆通过传感器等，其示意图见图8-18。 2当汽车到达入口时，驾驶员按下停车卡打印机的按钮获取停车卡。当驾驶员拿走停车

18、卡后，系统命令栏杆自动抬起；汽车通过入口后，入口处的传感器通知系统发出命令，栏杆自动放下。 3在停车场内分布着若干个付款机器。驾驶员将在入口处获取的停车卡插入付款机器，并缴纳停车费。付清停车费之后，将获得一张出场卡，用于离开停车场。 4当汽车到达出口时，驾驶员将出场卡插入出口处的读卡器。如果这张卡是有效的，系统命令栏杆自动抬起；汽车通过出口后，出口传感器通知系统发出命令，栏杆自动放下。若这张卡是无效的，系统不发出栏杆抬起命令而发出告警信号。 5系统自动记录停车场内空闲的停车位的数量。若停车场当前没有车位，系统将在入口处显示“车位已满”信息。这时，停车卡打印机将不再出卡，只允许场内汽车出场。 根

19、据上述描述，采用面向对象方法对其进行分析与设计，得到如表8-8所示的类/用例/状态列表，如图8-19所示的用例图，如图8-20所示的初始类图以及如图8-21所示的描述入口自动栏杆行为的UML状态图。 表8-8 类/用例/状态列表 用户名 说明 类名 说明 状态名 说明 Car entry 汽车进入停车场 CentralComputer 停车场信息系统 Idle 空闲状态，汽车可以进入停车场 Car exit 汽车离开停车场 PaymentMachine 付款机器 Disable 没有车位 ReportStatistics 记录停车场的相关信息 CarPark 停车场，保存车位信息 Await

20、Entry 等待汽车进入 Barrier 自动护栏 AwaitTicket Take 等待打印停车卡 Car entrywhen full 没有车位时，汽车请求进入停车场 EntryBarrier 入口的护栏 Await Enable 等待停车场内有空闲车位 ExitBarrier 出口的护栏 1. 问题1 根据说明中的描述，使用表8-8给出的用例名称，给出图8-19中U1、U2和U3所对应的用例。 答案:U1：Car entry U2：Car exit U3：Car entry when full表8-8中给出了Car entry、Car exit、Report Statistics、Car

21、 entry when full 4个用例。在这4个用例中，两个用例表示汽车进入停车场，一个用例表示汽车退出停车场，另一个用例表示记录停车场相关信息。经分析得出，前3个用例的参与者都是驾驶员，因此U1、U2和U3对应进入和退出停车场。U1和U3之间存在扩展关系，而用例之间的延伸关系用于对被用户看作是可选系统行为的用例的一部分建模。通过这种方式，可以把可选行为从必需的行为中分离出来。Car entrv when full和car entry之间就可以使用extend关系进行建模。 2. 问题2 根据说明中的描述，使用表8-8给出的类的名称，给出图8-20中的AD所对应的类。 答案:A：CarPa

22、rk B：Barrier C：EntryBarrier D：ExitBarrier在UML类图中，类与类之间的5种关系从弱到强依次为：依赖(Dependency)，关联(Association)，聚合(Aggregation)，组合(Composition)和继承(Inheritance)。因此依赖关系最弱，继承表示类与类之间关系最强。依赖(Dependency)关系是类与类之间的连接，并且依赖总是单向的，其标准UML图形表示为“”。“”表示其相联的两个类之间存在关联关系，用于描述两个概念上位于相同级别的类的实例之间存在的某种语义上的联系。聚合关系是关联关系的一种特例，代表两个类之间的整体/局

23、部关系，其标准UML图形表示为“”。“”表示其相联的两个类之间存在继承关系。子类继承父类的行为与含义，子类还可以增加或者覆盖父类的行为。子类可以出现在父类出现的任何位置。 依题意可以判断Barlrier、EntryBarrier和ExitBarrer之间存在继承关系，而在图8-20类图中“”所表示的继承关系的部分只有一处，因此这3个类分别对应于图8-20中的类B、类C和类D，而剩下的类A只有选择类CarPark了。 3. 问题3 根据说明中的描述，使用表8-8给出的状态名称，给出图8-21中S1S4所对应的状态。 答案:S1：Idle S2：Await Ticket Take S3：Await

24、 Enable S4：Await Entry在图8-21中，Idle表示有空闲车位，Disable表示没有空闲车位，因此在其之间存在双向的状态迁移，即状态图上的状态S1为Idle状态。当停车场存在空闲车位时，汽车请求进入停车场，根据说明描述“当汽车到达入口时，驾驶员按下停车卡打印机的按钮获取停车卡”，可知该动作正对应于状态图上的S1和状态S2之间的迁移，因此，状态S2表示的含义应该是按下按钮后的状态，此时，驾驶员等待打印停车卡，所以状态S2为Await Ticket Take。同理可分析出状态S3和状态S4。 4. 问题4 简要解释图8-19中用例U1和U3之间的extend关系的内涵。 答案

25、:用例之间的延伸关系用于对被用户看作是可选系统行为的用例的一部分建模。通过这种方式，可以把可选行为从必需的行为中分离出来在用例的执行过程中，可能会在不同的流程分支中选择执行，也可能会出现异常行为。此时，可以将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成“扩展(extend)”关系。试题4阅读下列算法说明和流程图，根据回答下列问题。 说明 某机器上需要处理n个作业job1，job2，jobn，其中： (1)每个作业jobi(1in)的编号为i，jobi有一个收益值pi和最后期限值di； (2)机器在一个时刻只能处理一个作业，而且每个作业需要一个单位时间进行处理，一旦作业开始就不

26、可中断，每个作业的最后期限值为单位时间的正整数倍； (3) job1jobn的收益值呈非递增顺序排列，即p1p2.pn； (4)如果作业jobi在其期限之内完成，则获得收益pi；如果在其期限之后完成，则没有收益。 为获得较高的收益，采用贪心策略求解在期限之内完成的作业序列。图8-22是基于贪心策略求解该问题的流程图。 (1)整型数组J有n个存储单元，变量k表示在期限之内完成的作业数，J1.k存储所有能够在期限内完成的作业编号，数组J1.k里的作业按其最后期限非递减排序，即dJ1.dJk。 (2)为了便于在数组J中加入作业，增加一个虚拟作业job0，并令d0=0，J0=0。 (3)算法大致思想是

27、：先将作业job1的编号1放入J1，然后，依次对每个作业jobi(2in)进行判定，看其能否插入到数组J中。若能，则将其编号插入到数组J的适当位置，并保证J中作业按其最后期限非递减排列；否则不插入。 jobi能插入数组J的充要条件是：jobi和数组J中已有作业均能在其期限之内完成。 (4)流程图中的主要变量说明如下。 i：循环控制变量，表示作业的编号。 k：表示在期限内完成的作业数。 r：若jobi能插入数组J，则其在数组J中的位置为r+1。 q：循环控制变量，用于移动数组J中的元素。 1. 问题1 请将图8-22中的空缺处的内容填写完整。 答案:i=n dJrdi Jr+1=i，或Jq+1=

28、i 2. 问题2 假设有6个作业job1，job2，job6；完成作业的收益数组p=(p1,p2,p3,p4,p5,p6)=(90,80,50,30,20,10)；每个作业的处理期限数组d=(d1,d2,d3,d4,d5,d6)=(1,2,1,3,4,3)。 请应用试题中描述的贪心策略算法，给出在期限之内处理的作业编号序列_(按作业处理的顺序给出)，得到的总收益为_。 答案:1,2,4,5或job1、job2、job4、job5及其等价描述形式 220这是一道考查贪心算法实例应用的分析题。6个作业、job1、job2、.、job6的收益已经按降序排列，根据图8-22的算法流程，将作业1、2、4

29、和5放入数组J中，并得到总收益为220，具体分析过程见表8-9。 表8-9 贪心算法实例执行过程 J数组 收益 考虑的作业 期限 操作 0 job1 1 放入J中 1 90 job2 2 放入J中 1,2 170 job3 1 不放入J中 1,2 170 job4 3 放入J中 1,2,4 200 job5 4 放入J中 1,2,4,5 220 job6 3 不放入J中 1,2,4,5 220 3. 问题3 对于本试题的作业处理问题，用图8-22的贪心算法能否求得最高收益?_(能或不能)。用贪心算法求解任意给定问题时，是否一定能得到最优解?_(能或不能)。 答案:能，或可以、行及其他含义相同的

30、词语 不能，或不可以、不行及其他含义相同的词语这是一道判断贪心算法是否能求得最优解的应用分析题。对于本试题的作业处理问题，用图8-22的贪心算法策略，能求得最优解(即能求得最高收益)。但不是所有的问题都能通过贪心策略来求得最优解，一个典型的例子是0-1背包问题。例如，有3件物品，背包可容纳50磅重的东西，每件物品的详细信息如表8-10所示，问如何装包使得其价值最大? 表8-10贪心算法实例执行过程 物品编号 重量(磅) 价值(美元) 单位价值 R 10 60 6 S 20 100 5 T 30 120 4 如果按贪心策略求解该问题，优先选择单位价值最大的物品，则先选择物品R，然后选择物品S。由

31、于此时背包容量还剩下50-10-20=20，不足以容纳物品T，故总价值为60+100=160美元。但若选择物品S和物品T，容量总和为20+30，小于等于总容量50，得到总价值为100+120=220美元，会得到更优解。此时用贪心策略不能得到最优解。 试题5问题:1. 请阅读以下技术说明、类图及C+代码，回答下列问题。 说明 已知某企业的采购审批是分级进行的，即根据采购金额的不同由不同层次的主管人员来审批。主任可以审批5万元以下(不包括5万元)的采购单，副董事长可以审批5万元至10万元(不包括10万元)的采购单，董事长可以审批10万元至50万元(不包括50万元)的采购单，50万元及以上的采购单就

32、需要开会讨论决定。 采用责任链设计模式(Chain of Responsibility)对上述过程进行设计后得到的类图如图8-23所示。 C+代码 #include String #include iostream using namespace std; class PurchaseRequest public: double Amount; /采购的金额 int Number; /采购的单号 string Purpose; /采购的目的 ; class Approver / 审批者类 public: Approver() successor=NULL; virtual void Proce

33、ssRequest (PurchaseRequest aRequest) if successor !=NULL) successor- _; void SetSuccessor (Approver *aSuccesssor) successor=aSuccesssor; private: _ successor; ; class Congress:public Approver public: void ProcessRequest (PurohaseRequest aRequest) if (aRequest.Amount:500000) /*决定是否审批的代码省略*/ else _ Pr

34、ocessRequest(aRequest); ; class Director:public Approver public: void ProcessRequest(PurchaseRequest aRequest) /*此处代码省略*/ ; class President:public Approver public: void ProcessRequest(PurchaseRequest aRequest) /*此处代码省略*/ ; class VicePresident:public Approver public: void ProcessRequest(PurchaseReque

35、st aRequest /*此处代码省略*/ ; void main() Congress Meeting; VicePresident Sam; Director Larry; President Tammy; /构造责任链 Meeting.SetSuccessor(NULL); Sam.SetSuccessor(_); Tammy.SetSuccessor(_); Larry.SetSuccessor(_); PurchaseRequest aRequest; /构造一采购审批请求 cin aRequest.Amount; /输入采购请求的金额 _.ProcessRequest(aRequest); /开始审批 return; 答案:ProcessRequest(aRequest) Approver* Approver: /采购金额 public int Number; /采购单编号 public String Purpose; /采购目的 ; class Approver /审批者类 public Approver() successor=null; public void ProcessRequest PurchaseRequest aRequest) if (succes