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