《2009上半年软件设计师下午试题及答案》由会员分享，可在线阅读，更多相关《2009上半年软件设计师下午试题及答案（38页珍藏版）》请在金锄头文库上搜索。
1、全国计算机技术与软件专业技术资格全国计算机技术与软件专业技术资格( (水平水平) )考试考试20092009 年上半年年上半年 软件设计师软件设计师 下午试卷下午试卷试题一试题一阅读下列说明,回答问题 1 与问题 2,将解答填入答题纸的对应栏内。 说明说明 假设某大型商业企业由商品配送中心与连锁超市组成,其中商品配送中心包括采购、财务、配送等部门。为实现高效管理,设计了商品配送中心信息管理系统,其主要功能描述如下:1.系统接收由连锁超市提出的供货请求 ,并将其记录到供货请求记录文件。2.在接到供货请求后 ,从商品库存记录文件中进行商品库存信息查询。如果库存满足供货请求 ,则给配送处理发送配送通
2、知:否则,向采购部门发出缺货通知。3.配送处理接到配送通知后 ,查询供货请求记录文件,更新商品库存记录文件 ,并向配送部门发送配送单 ,在配送货品的同时记录配送信息至商品配送记录文件。4.采购部门接到缺货通知后 ,与供货商洽谈,进行商品采购处理,合格商品入库,并记录采购清单至采购清单记录文件、向配送处理发出配送通知 ,同时通知财务部门给供货商支付货款。该系统采用结构化方法进行开发 ,得到待修改的数据流图如下图所示。问题 1使用说明中的词语,给出上图中外部实体E1至E4的名称与数据存储 D1 至 D4 的名称。答:E1:财务部门E2:采购部门E3:连锁超市E4:配送部门D1:采购清单记录文件D2
3、:商品库存记录文件D3:商品配送记录文件D4:供货请求记录文件问题 2以上数据流图中存在四处错误数据流 ,请指出各自的起点与终点;若将上述四条错误数据流删除,为保证数据流图的正确性,应补充三条数据流,请给出所补充数据流的起点与终点。(起点与终点请采用上述数据流图中的符号或名称)答:错误数据流补充的数据流试题一分析试题一分析本题考查DFD的分析与设计,问题一主要考查DFD中的外部实体与数据存储 ,由于在题干中已经提到“系统接收由连锁超市提出的供货请求 ,并将其记录到供货请求记录文件”,因此可以明确出“连锁超市”外部实体与“供货请求记录文件”数据存储:对应到 DFD 图中为 E3 与 D4。描述中
4、的第二项提出“从商品库存记录文件中进行商品库存信息查询。如果库存满足供货请求 ,则给配送处发送配送通知;否则,向采购部门发出缺货通知”,因为配送通知需要发送到采购部门,因此采购部门将成为系统的外部实体;同时,商品库存记录文件能够提供库存信息,所以DFD图中E2与D2分别为采购部门与商品配送记录文件。第三项需求“配送处理接到配送通知后,查询供货请求记录文件 ,更新商品库存记录文件 ,并向配送部门发送配送单 ,在配送货品的同时记录配送信息至商品配送记录文件” ,所以配送处理需要查询供货请求记录文件,更新商品库存记录文件与商品配送记录文件,因此 D3 为商品配送记录文件;采购处理需要记录采购清单同时
5、通知财务部门,所以 E1 应该为财务部门,D1 为采购清单记录文件,剩下的 E4 则为配送部门。DFD 中出现的错误数据流为:E1 到 E2,E1 与 E2 的数据流不属于系统的范围;D3到E4,多余的数据流;D2到采购处理,数据流方向错误;D4 到供货请求处理,数据流方向错误。需要补充的数据流为:E2 到采购处理,因为 E2 就是采购部门,采购部门需要给采购处提供入库商品信息;采购处到D2需要一条数据流,因为采购处理需要更改库存信息;供货请求处理到 D4 需要一条数据流,因为供货请求处理需要记录供货请求信息。试题二试题二阅读下列说明,回答问题 1 至问题 3,将解答填入答题纸的对应栏内。 说
6、明说明 某集团公司拥有多个大型连锁商场 ,公司需要构建一个数据库系统以方便管理其业务运作活动。 需求分析结果需求分析结果 1.商场需要记录的信息包括商场编号(编号唯一),商场名称,地址与联系电话。某商场信息如下表所示。商场信息表2.每个商场包含有不同的部门 ,部门需要记录的信息包括部门编号(集团公司分配),部门名称,位置分布与联系电话。某商场的部门信息如下表所示。部门信息表3.每个部门雇用多名员工处理日常事务 ,每名员工只能隶属于一个部门(新进员工在培训期不隶属于任何部门)。员工需要记录的信息包括员工编号(集团公司分配),姓名,岗位,电话号码与工资。员工信息如下表所示。员工信息表4.每个部门的
7、员工中有一名就是经理 ,每个经理只能管理一个部门,系统需要记录每个经理的任职时间。 概念模型设计概念模型设计 根据需求阶段收集的信息 ,设计的实体联系图与关系模式(不完整)如下:实体联系图 关系模式设计关系模式设计 商场(商场编号,商场名称,地址,联系电话)部门 (部门编号 ,部门名称 ,位置分布 ,联系电话 ,(a)/ a: 商场编号员工(员工编号 ,员工姓名 ,岗位,电话号码 ,工资,(b) /b:部门编号经理(c),任职时间)/c:员工编号问题 1根据问题描述,补充四个联系,完善图 21 的实体联系图。联系名可用联系 1、联系 2、联系 3 与联系 4代替,联系的类型分为 1:1、1:n
8、 与 m:n。答:问题 2根据实体联系图,将关系模式中的空(a)(c)补充完整,并分别给出部门、员工与经理关系模式的主键与外键。问题 3为了使商场有紧急事务时能联系到轮休的员工 ,要求每位员工必须且只能登记一位紧急联系人的姓名与联系电话,不同的员工可以登记相同的紧急联系人。则在图 21 中还需添加的实体就是(1),该实体与图2-1 中的员工存在(2/登记)联系(填写联系类型)。 给出该实体的关系模式。答:紧急联系人(员工编号,姓名,联系电话)试题二分析试题二分析本题考查数据库概念结构设计及概念结构向逻辑结构转换的过程。此类题目要求考生认真阅读题目对现实问题的描述,经过分类、聚集与概括等方法从中
9、确定实体及其联系。题目已经给出了 4 个实体,需要根据需求描述给出实体间的联系。问题 1由“每个商场包含有不同的部门”可知商场与部门间为 1:m 联系;由“每个部门雇用了多名员工处理日常事务”可知部门与员工间为 1:p 联系;由“每个部门的员工中有一个经理每个经理只能管理一个部门” 可知部门与经理间为 1:1 联系,并且员工就是经理的超类型,经理就是员工的子类型。问题 2商场的属性信息中,商场编号由集团公司分配,不会重复,可作为商场的主键属性 ;部门的属性信息中 ,部门编号由集团公司分配,不会重复,可作为部门的主键属性,商场与部门的联系需要通过将商场的主键(商场编号)加入到部门中来表达;员工的
10、属性信息中,员工编号由集团公司分配,不会重复,可作为员工的主键属性 ,部门与员工的联系需要通过将部门的主键(部门编号)加入到员工中来表达;经理除了包含员工的属性信息外,还需要任职时间属性。完整的关系模式如下:商场(商场编号,商场名称,地址,联系电话)部门(部门编号,部门名称,位置分布,联系电话,商场编号)员工(员工编号,姓名,岗位,电话号码,工资,部门编号)经理(员工编号,任职时间)问题 3员工的紧急联系人信息通过添加紧急联系人关系来实现,由“每位员工必须且只能登记一位紧急联系人的姓名与联系电话”,但可能存在多位员工登记同一位家属,可知员工与家属间为 n:1 联系:由“不同员工可以登记相同的紧
11、急联系人”可知 ,员工编号可作为家属的主键属性。所以需要添加的关系模式如下:紧急联系人(员工编号,姓名,联系电话)参考答案参考答案问题 1(图中的 m、n 也可用*表示,对联系名称可不做要求,但不能出现重名)问题 2(a)商场编号(b)部门编号(c)员工编号部门关系模式的主键:部门编号外键:商场编号员工关系模式的主键:员工编号外键:部门编号经理关系模式的主键:员工编号外键:员工编号问题 3(d)紧急联系人(e)1:n关系模式:紧急联系人(员工编号,姓名,联系电话)试题三试题三阅读下列说明与图,回答问题 1 至问题 3,将解答填入答题纸的对应栏内。说明某银行计划开发一个自动存提款机模拟系统 (A
12、TMSystem)。系统通过读卡器 (CardReader)读取 ATM 卡;系 统 与 客 户 (Customer) 的 交 互 由 客 户 控 制 台(Customer-Console)实现;银行操作员(Operator)可控制系统的启动(System Startup)与停止(System Shutdown):系统通过网络与银行系统(Bank)实现通信。当读卡器判断用户已将 ATM 卡插入后,创建会话(Session)。 会话开始后,读卡器进行读卡,并要求客户输入个人验证码(PIN)。系统将卡号与个人验证码信息送到银行系统进行验证。验证通过后 ,客户可从菜单选择如下事务(Transacti
13、on):1.从 ATM卡账户取款(Withdraw);2.向 ATM卡账尸存款(Deposit);3.进行转账(Transfer):4.查询(Inquire)ATM卡账户信息。一次会话可以包含多个事务 ,每个事务处理也会将卡号与个人验证码信息送到银行系统进行验证。 若个人验证 码错误 ,则转 个人验证码 错误处理 (Invalid PINProcess)。每个事务完成后,客户可选择继续上述事务或退卡。选择退卡时,系统弹出 ATM卡,会话结束。系统采用面向对象方法开发,使用 UML 进行建模。系统的顶层用例图如图 3-1 所示,一次会话的序列图(不考虑验证)如图 3-2 所示。问题 1根据说明中
14、的描述,给出图3-1中A1与A2所对应的参与者,U1 至 U3 所对应的用例,以及该图中空(1)所对应的关系。(U1 至 U3 的可选用例包括:Session、Transaction、 Insert Card、 Invalid PIN Process 与 Transfer)答:A1:CustomerA2:BankU1:SessionU2:Invalid PIN ProcessU3:Transaction(1):extend问题 2根据说明中的描述,使用消息名称列表中的英文名称,给出图 3-2 中 69 对应的消息。答:6:readPIN()7:PIN8:creat(atm,this,card,
15、pin)9:preformTransaction()问题 3解释图 3-1 中用例 U3 与用例 Withdraw、Deposit等四个用例之间的关系及其内涵。答:Transaction 就是一个抽象泛化用例,具有其她事务类型共有的属性与行为,每个具体的事务类型继承它,并实现适合自己的特定的操作。试题三分析试题三分析本题涉及面向对象系统开发时的 UML 用例图、序列图以及用例之间的关系。问题 1构建用例图时,常用的方式就是先识别参与者,然后确定用例以及用例之间的关系。识别参与者时 ,考查与系统交互的人员与外部系统。本题中,与系统交互的人员包括客户(Customer)与银行操作员(Operato
16、r),与本模拟系统交互的外部系统包括银行。系统(Bank)。考查用例时,通过判断哪一个特定参与者发起或者触发了与系统的哪些交互 ,宋识别用例并建立与参与者之间的关联。考查用例之间的关系时 ,include(包含)定义了用例之间的包含关系 ,用于一个用例包含另一个用例的行为的建模;如果可以从一个用例的执行中,在需要时转向执行另一个用例,执行完返回之前的用例继续执行,用例间即存在extend关系。本题中,客户一旦插卡成功,系统就创建会话(Session),会话中可以执行用户从菜单选择的 Withdraw、Deposit、Transfer 与 Inquire 等事务(Transaction)。由图中 U3 与 Withdraw 之间的扩展关系,可知 U3 为Transaction;又由 U1 与 U3 之间的include关系,得知 U1 为 Session,进而判定图中 A1 为 Customer,A2为Bank。 每个事务处理也会将卡号与个人验证码信息送到银行系统进行验证,若个人验证码错误,则转个人验证码错误处理(1nvalid PIN Process,图中 U2),所以(1)处应填ex
