软件需求实验报告二.docx
《软件需求实验报告二.docx》由会员分享，可在线阅读，更多相关《软件需求实验报告二.docx（12页珍藏版）》请在冰点文库上搜索。
软件需求实验报告二
深圳大学实验报告
课程名称：
软件工程
实验项目名称：
实验二用例开发
学院：
计算机与软件学院
专业：
软件工程
指导教师：
尹剑飞
报告人：
文成学号：
2011150259班级：
2
实验时间：
2013-11-12
实验报告提交时间：
2013-11-15
教务部制
一、实验目的
1.理解用例结构
用例分为业务用例和系统用例，业务用例是业务主角与多个业务工人或外部系统的交互过程。
而系统用例是对业务用例的切分，是业务主角与系统的交互。
而系统则称为边界。
各种用例之间有多种关系，如：
include,extend,refine,realize等，通过关系，需求分析员来处理用例需求的层次性。
2.用例案例分析
通过阅读各类用例图，对用例进行性质分析。
二、实验环境
Word
三、实验内容与过程
1.判定业务用例
先给出一张典型业务用例的活动图场景描述：
图1.业务员->低压用电申请
其中业务员称为业务主角，业务主角起动“低压用电申请”业务用例。
业务班长、勘察员、配电专员、业务收费员、施工班、装表员在这个业务用例中称为业务工人，他们所从事的活动（如：
业务班长的分配勘察、配电专员的配电审批等）是服务于“低压用电申请”这一业务目标的。
“低压用电申请”这一业务目标是业务员代理真正的用户完成的事。
从图1，我们可以得出绝大多数业务用例满足下述条件：
1.1不涉及计算机概念
因为在业务用例中引入计算机概念将限制可能的实现方式：
你能预计未来通过克隆人来实现系统吗？
现实的业务活动并不需要通过计算机才能完成：
想想我国在解放初期的用电申请。
1.21个业务边界
业务主角一定位于业务边界之外，一个业务用例位于1个业务边界内。
业务边界常用一个方框表示，如：
图2用户客户服务业务边界示例
业务边界定义了一个业务上下文，也即讨论的主题，也即一个业务目标。
图2表示参与用户客户服务这一业务边界的业务主角有用户客户和银行。
1.31个业务主角
业务主角的作用就是“启动”业务用例。
多于1个业务主角的情况也是有的，但是它们一般是业务工人，只是因为它们位于对应的边界之外，所以被称为“业务主角（被动）”。
如图2中的“银行”，它在用户客户服务这一业务主题中，并不是启动业务的，而只是被动执行扣费的，这一点可从下图知：
图31个业务主角（业务员）+N个业务主角（被动：
营业出纳）
图3中关于营业出纳的脚注是：
“交纳业务费用本来是用电客户事情。
但这里假设的业务是用电客户去银行交费，银行提供交费记录，营营业出纳则将记录取回并录入系统。
”，从中可见“被动”之含义。
1.4至少1个以上的业务工人
业务用例是复杂的，涉及到多个现实中的业务工人的交互，他们之间的消息传递是通过各种单据达到的，如业务员与业务班长从“申请登记”到“分配勘察”之间的活动跳跃是通过申请单达到的，这一点可以从下图知：
图4业务主角、业务工人之间的单据传递
若一个业务用例是简单的，也即除了业务主角外，没有与其它人交互，那么这个业务用例不应挂上“业务”两字，而很可能是“系统用例”。
特别需要注意的是，若你描述一个业务用例形如：
增加/删除/修改/查询xxx，这样的用例并不是业务用例，因为不满足第1.1）和1.4）条件。
事实上，这样的用例已经隐含了“计算机”的概念，所以这样的用例应称为“系统用例”。
为什么需要1.4）这样的必要条件？
，原因是
1.4.1控制系统复杂度
试想一下一个系统有多少增加/删除/修改/查询xxx这样的系统用例？
1.4.2在将来的系统实现之后，为设计和编码提供业务上下文
业务用例可以回答像这样的问题：
为什么在创建申请单后，系统向业务班长发一条短信通知，或是在数据设计时，要在申请单上增加一个“申请状态”字段，其值=“待勘察”？
2.判定业务用例练习
Q1.对书本P89图8.1进行分析，找出哪些是业务用例，哪些不是。
请给出你的判定依据。
答：
（1）申请人请求一种化学品
（2）健康保险部门处理化学品
（3）购买人检查订单状态
判定依据：
不涉及计算机概念，业务主角一定位于业务边界之外，一个业务用例位于1个业务边界内。
1个业务主角（主动）+1个业务主角（被动）。
例如一申请人收到化学品这个业务用例是简单的，也即除了业务主角外，没有与其它人交互，它就不算业务用例。
例如化学品仓库管理人员查看厂商的产品目录，其增加/删除/修改/查询涉及到计算机的概念，它就不是一个业务用例。
Q2.请给出的一个业务用例，包括业务主角、业务主角（被动）、业务工人、业务用例名称。
并画出像图4那样的图。
下图为顾客购物的一个用例：
3.判定系统用例
简而言之，系统用例就是在引入计算机之后，对业务用例的切分。
这种切分反映了引入计算机之后的业务解决方案。
系统用例具有下述条件：
3.11业务主角异或1个业务工人只与计算机交互
其中计算机代表系统，业务主角或业务工人代表使用系统的人。
例子有：
书本P95的UC-1申领化学品。
或者下面的图形描述：
图5系统用例的活动图场景示例
3.2反映业务主角和业务工人、业务工人和业务工人之间的通信
1个系统用例必然存在这种通信，原因已在1.4节描述。
4.系统用例练习
Q3.除了出现业务主角，为什么在系统用例的边界外还可以出现业务工人？
答：
因为系统用例的主动发起者也可以是计算机，在系统用例的边界外是可以出现业务工人的。
Q4.为什么1个系统用例只有1个业务主角或1个业务工人参与？
答：
若一个业务用例是简单的，也即除了业务主角外，没有与其它人交互，或者只有计算机与1个业务工人参与，那么这个业务用例不应挂上“业务”两字，而很可能是“系统用例”。
Q5.请在图5中找出系统用例之间的通信。
答：
计算机“展现新申请录入界面”与“循环校验用户信息”通过业务员录入申请人资料来通信
Q6.如果在一个系统用例的描述中，找不出业务主角和业务工人、业务工人和业务工人之间的显式通信的证据，那么是否意思着这种通信不存在呢？
答：
否，1个系统用例必然存在反映业务主角和业务工人、业务工人和业务工人之间的通信。
业务用例是复杂的，涉及到多个现实中的业务工人的交互，他们之间的消息传递是通过各种单据达到的。
大的业务用例拆成小的系统用例，要互联，软件设计要有系统的连接。
Q7.请用UML的活动图，对附件UseCase_Guide.pdf中的UC4ShopForCD加以描述，以可视化地显示出FlowofEvents、AlternativeFlows中的UC4.2~UC4.9之间的活动转换条件。
下图：
开始
Q8.附件UseCase_Guide.pdf中的UC4ShopForCD满足3.1）和3.2）条件吗？
为什么？
答：
满足
3.1一个业务主角只与计算机交互。
UC4ShopForCD是顾客与计算机的交互。
3.2反映业务主角和业务工人之间的通信。
存在买方与卖方之间的通信。
卖方作为业务工人通过系统与买方通信。
Q9.相应于Q2，请给出2个系统用例的描述。
要求：
1）这2个系统用例必须满足3.1）和3.2）条件，并在描述中指出在何处满足这两个条件；2）必须提供两种描述方式，其一是像UseCase_Guide.pdf中的UC4ShopForCD那样的文字描述；其二是使用UML的活动图或序列图或状态图。
答：
系统用例1：
顾客将商品加入购物车（顾客是主角与计算机交互）
基本流程
1.开始
用例开始顾客选择商品。
2、该系统将提供输入框（通信）
•顾客选择商品件数
3、选项
该系统将提供以下选项:
（通信）
•返回继续浏览商品
•查看购物车
4.系统保存信息。
系统用例2：
顾客查询商品（顾客是主角与计算机交互）
基本流程
1.开始
用例开始顾客输入商品名。
（通信）
2、该系统查询商品
3、显示找出的商品列表
Q10.请在阅读附件11-08-06.pdf中16.3.5Include和16.3.3Extend和16.3.4ExtensionPoint的基础上，分析书本P89图8.1中<<扩展>>、书本P91图8.3中的<<包括>>的含义，试问答：
它们可以互换吗？
为什么？
答：
不可以，由11-08-06.pdf中16.3.5Include和16.3.3Extend定义可以知道，Include是指一个用例包括了另一个用例的行为，而Extend则是指一个扩展用例可以在自己的行为中定义另一个扩展用例的行为。
四、实验结论
刚开始看前面的指导时，还不知道怎么找业务主角，觉得业务主角很多，后来总结出要找主动的一方。
开始发现很难区分一个用例是业务用例还是系统用例，后面找出了诀窍。
原来若一个业务用例是简单的，也即除了业务主角外，没有与其它人交互，那么这个业务用例不应挂上“业务”两字，而很可能是“系统用例”。
另外，实验中发现要画一个活动图是挺困难的，在画好之后总发现又漏了很多没考虑到的。
后来我感觉前面画的图有很多不足，但后来修改起来又很不方便。
指导教师批阅意见：
成绩评定：
指导教师签字：
年月日
备注：
注：
1、报告内的项目或内容设置，可根据实际情况加以调整和补充。
2、教师批改学生实验报告时间应在学生提交实验报告时间后10日内。
升级会员 