软件需求讲义-第三部分.ppt

图书馆系统的用例图（具有包含和扩展关系） 图书馆系统 用例的粒度 通常用例图粒度较大 通过分解和细化，可以使粒度更小 通过事件流描述： 寻找用例的共同点 寻找用例的扩展点 切忌“画蛇添足”！ 合理组织用例 对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按参与者分包，如读者包、图书管理员包 按主题分包，如毕设的题目管理包、成绩管理包 按开发团队分包，A小组、B小组 按发布情况分包，第1次迭代包… 错误的用例图举例 把步骤当用例 把系统活动当用例 错误的用例图举例 Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件 用例是一个完整的交互 用例之间没有顺序的关系 课堂练习1：用例建模 完成“旅店预定系统”的系统用例图，注意用例的命名和用例间的关系的使用。 选择一个体现系统核心业务功能的用例，完成用例规格说明。 “旅店预定系统”初步用户需求 某公司要开发一个旅店预定系统，该旅店可对外开放豪华双人间、双人间、三人间和单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。假定这些功能旅客均需通过旅店前台与系统交互实现。并且每周一系统会自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。 问题用例图1 问题用例图2 问题用例图3 不恰当的“时间”参与者 时间：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例 “检查是否可以退定金”的时候，时间仅仅是一个系统内部的判断条件，而不是参与者 无效的参与者泛化 参与者泛化：特殊参与者会继承泛化参与者所有的要素！ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则这样的方法没有任何意义 在系统中如果两个参与者涉及相同的用例，则合并 错误的用例关系 依赖关系：include, extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示 扩展关系：“extend”关系的方向，子用例对主用例的扩展 错误的用例关系 用例的顺序在活动图中表现 错误的用例关系 “其他”用例？ “其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？ “其他”用例又代表什么呢？想说明什么样的功能需求？ 参与者和用例间的关系 “打印报表”和“酒店管理员”之间的关联是有意义的交互吗？ 用例粒度太小 较为合理的用例图 较为合理的用例规格说明1 用例名称：预定房间 涉及的参与者：酒店前台 描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。 前置条件：前台工作人员必须已经登录到这个系统 后置条件：预定信息正确的记录到系统中 正常事件流： 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。 3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定，工作完成。 备选事件流： 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束 5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。 较为合理的用例规格说明2 n用例名称：取消预订 n主要参与者：酒店前台 n描述：酒店前台利用该用例来取消顾客的预定，如果在指定时间内，则取消时需要返还顾客定金 n前置条件：用户必须已经预订了某个房间 n后置条件：系统将取消预定的房间恢复为空闲，并且定金已返还给顾客 n正常事件流： 前台人员提供给系统顾客信息，比如顾客姓名或证件号码； 系统进行检查并返回该顾客的预订信息，包括顾客姓名、证件号码、联系电话、房间类型、预订时间、预订天数和总费用； 前台人员确认取消该预定； 系统取消该房间预订。 n备选事件流： 2a.系统提示没有该顾客的预定信息 4a.当取消预订在6小时之内，系统提示需要退还顾客定金 4a1. 系统提示返回金额； 4a2.前台人员确认已退还定金； 4a3.系统记录定金已退还。 课堂练习2：用例建模 某电话公司决定开发一个管理所有客户信息的交互式网络系统。系统的功能如下，请根据下述描述，画出系统的用例