用例和用例图

1主要内容上讲回顾1用例模型2常见问题分析3补充规约4讨论---课程注册系统示例5小结2上讲回顾UML的全称？你对UML的理解？UML由什么构成？UML基本构造块中的关系有哪几种？UML的图有哪几种？31、用例模型1、用例模型用例模型的目的是各方达成共识，明确系统的基本功能，为后阶段的工作打下基础。确定系统应具备哪些功能；为系统的功能提供清晰一致的描述；为系统验证工作打下基础；用例模型由用例图和用例规约两部分组成52常见问题分析用例是有意义的目标价值结果由系统生成62常见问题分析用户的观点而非系统的观点不要把步骤当用例72常见问题分析用例的粒度——CRUD泛滥™用有色眼镜看，所有业务最终都会成为CRUD™多问：为什么要CRUD？光CRUD能为执行者提供价值吗？82常见问题分析用例的粒度——CRUD泛滥™如果CRUD不涉及复杂的交

互，一个用例“管理××”

即可™不管是C、R、U、D，都是

为了完成“管理”的目标™甚至很多种基本数据的管

理都可以用一个用例表示9用例的粒度——1个业务用例，多个系统用例2常见问题分析102常见问题分析11请举例说明包含、泛化、扩展的区别™扩展：分离扩展路径™包含：提取公共步骤，便于复用™泛化：同一业务目的的不同技术实现12很多软件系统在一开始都需要登录，若用户登录成功，则可进入系统。如下以一个研究生学籍管理系统为例，描述四种登录方法。为了简化起见，假设此处仅描述登录、选课和查看学分这3项功能。2常见问题分析13由于选课和查看学分都需要登录，故专门设立一个“登录”用例。若登录成功，则可以进行选课，也可以进行查看学分。方案一：14让所有的相关用例都包含登录用例。方案二：这个方法中的“登录”用例仅描述有关登录的信息，研究生执行系统的每项功能都要先登录。其缺点为，对研究生要进行多次验证。15使用扩展，设计系统登录。方案三：该方法与方法一相比，对“登录”用例的描述要清楚一些。在增加新用例时，仅在登录用例中添加扩展点即可16登录用例完全独立于其它用例。方案四：若使用该方法，必须要在“选课”用例和“查看学分”用例中指定前置条件：只有在登录成功后才能执行自己。17注意：必须是系统在用例开始前能检测到的业务代表已把保单交给录单员录单员已经登录2常见问题分析ATM用户的账户里有足够的金额ATM用户已登录ATM机器处于正常准备状态Usecase:WithdrawcashActor:customer主事件流：储户插入ATM卡,并输入密码储户按“取款”按钮,并输入取款数目储户取走现金/ATM卡/收据储户离开只描述了actor的行为2常见问题分析Usecase:WithdrawcashActor:customer主事件流：ATM系统获得ATM卡和密码，在SQL中查询到匹配的信息后，显示主界面如果信息不匹配，系统提示错误储户按“取款”按钮,并输入取款数目设置交易类型为“取款”ATM系统获得取款金额输出现金、收据和ATM卡现金/ATM卡/收据被储户取走系统复位2常见问题分析不要涉及界面细节购物查询用例会员从下拉框中选择要查询的商品类别后，又在在相应文本框中输入查询条件，然后点击“确定”按钮™系统以列表的显示查询结果2常见问题分析

用例编号:001

用例名:ATM取款用例描述:储户使用信用卡在ATM机上取款参与者角色：储户前置条件：ATM机器处于正常准备状态后置条件：若成功，则储户取出钱，帐户上扣除钱；若失败，储户没有取到钱，帐户上钱数不变。

基本路径

1,储户插卡；

2.ATM机提示输入用户口令；

3.储户输入口令；

4.ATM机口令验证通过，提示用户选择功能5.储户选择取款；6.ATM提示储户输入钱数； 例子---ATM取款用例描述 7.储户输入钱数；

8.ATM机进行钱数有效性检查，提示操作成功，吐

出钱和卡；

9.储户取走钱和卡；

10.ATM机屏幕恢复为初始状态。扩展路径

4a.ATM机验证用户口令不通过

4a1.ATM机给出提示信息，并吐出信用卡；

4a2.储户取出卡；

4a3.ATM机屏幕恢复为初始状态. 8a.ATM验证用户输入钱数超过3000 8a1.ATM机给出提示信息，并吐出信用卡；

8a2.储户取出卡；

8a3.ATM机屏幕恢复为初始状态.

。。。。23™用例编号：用例名™执行者™前置条件™后置条件™涉众利益™基本路径™1…..×××י2……×××י3…..×××י扩展™2a.××××：™a1….×י字段列表™业务规则™非功能需求™设计约束™待解决问题用例文档+补充约束=

需求规格说明243补充约束3补充约束：字段列表™+数据序列™[]可选项™｛｝*

多个™{|||}可能取值可以用自然语言，也可以用表达式™注册信息=公司名+联系人+电话+{联系地址}*™客房状态={空闲|已预定|占用|维修中}3补充约束：字段列表™不同于业务模型－－只是一部分™可以用E/R图或业务对象图作为辅助说明，但不宜直接作为需求™不等于数据字典－－容易过早把时间花在细节上™一开始好像做了很多事情，其实却回避了困难的业务问题用表达式表示3补充约束：业务规则™事实设备是资产的一种™推理™如果过了计划中的交付日期，货物还没有送到，即为“未按时送货”™约束™合同的总金额不能超出买方的信用额度™….各种业务规则3补充约束：业务规则™文字说明™决策表OCL™行业上适用的任何方式™….业务规则的各种表示方法2.2

用例描述——补充约束：业务规则决策表可能方案3补充约束：业务规则OCL3补充约束：业务规则™系统将语音输入翻译为文字™采用××识别算法™背景噪音强度为××的情况下，识别率应在××以上业务规则！＝实现算法警惕误把设计当成规则3补充约束——非功能需求：可用性™系统没有按程序员的意图工作™系统无法执行一项任务™系统能按照程序员意图工作，并且支持任务，但用户仍然不知道如何使用系统执行任务或者不喜欢使用系统执行任务程序错误功能需求遗漏可用性问题3补充约束——非功能需求：可用性™系统应易于使用™人事专员第一次使用时30分钟内能学会添加新员工（任务时间）™前台5次击键能完成客人入住服务，不需要使用鼠标（操作次数）80%的用户认为系统易学，并且使用效率高（用户调查）™系统界面应如××附件所示的屏幕图像（小心！）可用性需求的表达3补充约束——非功能需求：可靠性™™系统应能防范磁盘故障（安全）™™系统应保证收到的数据和发送的数据一致（完整）™MTBF（MeanTimeBetweenFailures）平均故障间隔时间（稳定）™MTTR（MeanTimeToRepair）平均修复时间（稳定）各种可靠性需求3补充约束——非功能需求：性能™™系统应在0.5秒之内拍摄超速车的照片（速度）™系统应允许1000个用户同时使用（容量）™在标准工作负荷下，系统的CPU占用率应少于50%

（能力）各种性能需求3补充约束——非功能需求：可支持性™™™95%的紧急错误应能在30工作时内修复™在修复故障时，未修复的相关缺陷平均数应小于0.5™在两年内，以每功能点××的价格升级系统™升级新版本时，应保存所有系统设置和个人设置各种可支持性需求3补充约束：设计约束™界面样式™报表™平台™语言™外系统接口™行业规定™…..38以下情况的用例优先级别最高a)对类图有重要影响b)包含丰富的业务过程信息和线索c)有开发风险、时间紧迫或功能复杂d)涉及到重要核心技术或新技术e)能直接产生经济效益或降低成本f)代表本系统的核心流程对用例进行优先级排序排序原则39对用例进行优先级排序排序方法：1、用例分级和评估矩阵40对用例进行优先级排序排序方法：2、用例依赖关系图3例子：学生注册课程系统当前的任务是开发一个新的学生注册系统。学校希望用新的客户—服务器系统代替原有的系统。这个系统允许学生通过连接到校园局域网的个人计算机进行课程的注册和查看成绩单。教授通过访问此系统选择其所教的课和记录学生的成绩。学校保留原有的课程目录数据库系统来维护所有的课程信息。学校已经购买了允许从学校的Unix服务器访问这个数据库的开放SQL接口。遗留系统的性能是很差的。所以新系统必须确保能及时访问这个系统上的数据。新系统读取遗留系统上的课程的信息，但不更新。每学期的开始，学生请求查看本学期的所开设的课程目录。有关课程的信息，如教授，所开设的系等会提供给学生帮助他们做出决定。系统允许学生为本学期选择四门课。另外，如果学生没有被分配到主要的选择课程，他还有两门备选的课程。每门课的学生人数是3到10人。3人以下的课程会被取消。每个学期会有一段时间让学生更改课程表。这段时间学生必须能访问系统并能添加或删