第6章组织系统需求：用例描述和图.ppt

1、第6章 组织系统需求：用例描述和图,使用“用例”来表达系统的功能,需求的分类,功能性需求：系统应当具备的功能，即系统必须能够做什么、完成哪些工作。 非功能性需求：系统精确度、性能、效率、成本、可维护性、安全性等系统行为之外的系统质量需求。 用例建模：捕获系统的功能性需求，帮助人们理解系统需求，而无需关注系统如何实现,本章内容,分辨信息系统的边界 什么是用例 用例的概念、目的 识别参与者 识别用例 绘制用例图 如何描述用例 用例分解，确定用例关系,6.1.1 用例的概念,用例创始人雅各布森Ivar Jacobson认为： 用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定

2、的参与者（actor）产生可观测的、有价值的结果。 阿里斯代尔科克伯恩Alistair Cockburn： 强调用例是各种系统受益人（stakeholder）之间的一种行为契约（contract）。行为包括对象的活动、动作和对象之间的交互等。建立契约的目的是为了达成某种目标，因此每一个用例实际上都应代表一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。,Use Case的定义,在一个workshop(专题讨论会)上，14位主要的OO专家对Use Case有14个定义。 定义1：use case是对一个活动者(actor)使用系统的一项功能时所

3、进行的交互过程的一个文字描述序列 (见2)。 定义2：The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors. (见3) 2 邵维忠，杨芙清，面向对象的系统分析，p153 3 J. Rumbaugh, etc. The Unified Modeling Language Reference Manual,

4、p488,用例的意义,用例是对系统需求（主要是功能需求）的规范化的描述。 用例图及用例的事件流描述集中体现了系统责任， 通过用例建立交互图。交互图就是用例的具体实现，即系统中的对象以及对象间协作是如何完成一个用例的全部过程。 用例驱动的开发过程，从用例模型到分析模型和设计模型之间有一致性和可追踪性。,用例是代表系统中各个相关人员之间就系统的行为所达成的契约。 例：在线银行系统的一些可能的用例： 浏览帐户余额 列出交易内容 划拨资金 支付帐款 登录 退出系统 编辑配置文件 买进证券 卖出证券,Use Case 驱动,use case对软件开发的意义,use case说明： Use case从使用

5、系统的角度描述系统中的信息，即站在系统外部察看系统功能，并不考虑系统内部对该功能的具体实现方式。 使用use case可以促进与用户沟通，理解正确的需求，同时也可以用来划分系统与外部实体的界限，是OO系统设计的起点，是类、对象、操作的来源。,用例的一些特点： （1）用例描述了用户提出的一些可见的需求； （2）用例可大可小； （3）用例对应一个具体的用户目标。 理论上我们可以把一个软件系统的所有Use Case画出来，但实际运用时只需把重要的、交互过程复杂的那些画出来。 需求有两种基本形式：功能性和非功能性的。不是所有的需求都要用use case表示出来。 问题：一个系统的需求包括哪些内容？ 可

6、以参照需求大纲,用例建模的内容,基于用例的需求获取过程： 1. 获取原始需求 2. 开发一个可以理解的需求 识别参与者 识别用例 构建用例图 3 详细、完整地描述需求 书写用例规格说明 4 重构用例模型 识别用例间的关系 对用例进行组织和分包,1、识别参与者,参与者是系统之外与系统进行交互的任何事物。 使用系统的个人 谁负责提供、使用或删除信息？ 谁将使用某项功能？ 系统所连接的外部硬件。 例如，控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。 与该系统进行通信的其他信息系统。 例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。信用卡系统是销售系统中的一个

7、参与者,区分参与者和外部实体,只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者 新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。 如果学生直接通过Web方式提交个人信息，则认为学生是参与者。,区分主要参与者和次要参与者,主要参与者（primary actor）是从系统中直接获得可度量价值的用户。 次要参与者（secondary actor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用 用例分析的重点是要找到主要参与者。 比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作

8、者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。,通过事件表获得参与者：,参与者可以从“源”得到启发，但“源” 表示数据最初的提供者，不一定对应功能的执行者。,参与者举例,参与者的表示,在UML中，参与者使用小人符号：,图书馆 系统,读者,图书管理员,RSA中的 建模符号,参与者的泛化,在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。 比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。,2、识别用例,用例就是功能性需求。 每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供

9、的功能。,用例的UML图形表示,购买商品,Rose中的符号,购买商品,区分用例和用例完成的步骤,不能混淆用例和用例所包含的步骤。 比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤 在系统中这些步骤通常不作为单独的功能提供给参与者使用，它们只是一个用例所包含的事件流，或者是用例的子功能。 与结构化分析中提到的事件概念相同。,区分业务用例和系统用例,当针对整个业务领域建模时，需要使用业务用例 比如图书馆系统有一项重要工作就是“整理书架”，图书都要放回到固定的位置上 信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，即有信息处理的那部分功能。,客户

10、提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。银行收到申请后，置于“申请档案”中，以申请号标识。 某公司内部工作岗位的提供：不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其他地区的HR领导发送消息，邀请员工们提出申请。然后，其他地区HR领导将招聘信息贴在公告板上。所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。,用例举例1,用例举例2,在门诊挂号处只能挂当天的号，挂出的号可以退。 病人拿到挂号单后，到相应的科室进行就诊。医生根据挂号的顺序号，依次给病人看病开处方。 病人拿处方去收款处交费，并拿到发票。 病人拿已经收费的处方去药房

11、拿药。 该系统潜在的参与者和用例有哪些？,图书馆系统的用例图,进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。 扩展和包含关系就是用例模型中消除冗余的一种手段。 基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。,6.2 用例关系,用例关系,包含关系：经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。 扩展关系：表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例。 泛化关系：如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例

12、继承父用例并特殊化。,基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。 包含用例是基本用例存在的必要条件 一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。,包含关系,扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。 扩展用例的缺失不影响对基本用例的理解。,扩展关系,用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。 父用例通常是抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完

13、整的，这一点与包含关系扩展关系不同。,泛化关系（不推荐）,小结： actor，use case的关系(relationship)类型,说明：可在use case间建立关联，但意义不是很明确。,用例的粒度,通常用例图粒度较大 通过分解和细化，可以使粒度更小 通过事件流描述： 寻找用例的共同点 寻找用例的扩展点 切忌“画蛇添足”！,常见问题分析,1. Use case的粒度问题，即对于一个系统的Use Case图，所包含的用例数目问题。 这是很多人争论的重点。例如，Ivar Jacobson说，对一个十人年的项目，他需要二十个用例。而在一个相同规模的项目中，Martin Fowler*则用了一百多

14、个用例。,*UML distilled一书的作者,2. 许多应用中需要对系统访问进行控制，应该如何处理登录问题比较好？ 有四种处理登录用例的方式: (1) 其它用例包含登录; (2) 其它用例扩展登录; (3) 登录独立于其它用例; (4) 登录包含其它用例。,(1) 其它用例包含登录 用例说明: 这种处理方式的特点:,(2) 其它用例扩展登录 用例说明: 这种处理方式的特点:,(3) 登录独立于其它用例。 用例说明: 这种处理方式的特点:,登录用例说明: 1. 当超级用户启动应用时用例开始 2. 系统提示超级用户输入用户名和密码 3. 超级用户输入用户名和密码 4. 系统验证其是否为有效超级

15、用户 5. 用例结束 调入员工用例说明: 前置条件: 一个有效超级用户登录了系统,(4) 登录包含其它用例 用例说明: 存在的问题:,3. 假设有这样需求：学生档案管理中，用户经常需要做三件事：增加一条学生记录、修改一条学生记录，删除一条学生记录。如果要画出use case图，以下2种方法哪种更合适？,方法1：再分成3个脚本，分别画3个交互图。脚本1 增加学生记录； 脚本2 修改学生记录；脚本3 删除学生记录。,方法2：每个use case画一个交互图。,8.4.4 合理组织用例,对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和

16、系统的最终表现形式 常见的分包方式 按参与者分包，如读者包、图书管理员包 按主题分包，如毕设的题目管理包、成绩管理包 按开发团队分包，A小组、B小组 按发布情况分包，第1次迭代包,错误的用例图举例,把步骤当用例 把系统活动当用例,错误的用例图举例,Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件,用例是一个完整的交互 用例之间没有顺序的关系,课堂练习：用例建模,完成“旅店预定系统”的系统用例图，注意用例的命名和用例间的关系的使用。 选择一个体现系统核心业务功能的用例，完成用例规格说明。,“旅店预定系统”初步用户需求,某公司要开

17、发一个旅店预定系统，该旅店可对外开放豪华双人间、双人间、三人间和单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。,问题用例图1,问题用例图2,问题用例图3,1. 不恰当的“时间”参与者,时间：参与者，一种习惯用法，用于激活那些系统定期的、自动

18、执行的用例 “检查是否可以退定金”的时候，时间仅仅是一个系统内部的判断条件，而不是参与者,2. 无效的参与者泛化,参与者泛化：特殊参与者会继承泛化参与者所有的要素！ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则这样的方法没有任何意义 在系统中如果两个参与者涉及相同的用例，则合并,3. 错误的用例关系,依赖关系：include, extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示 扩展关系：“extend”关系的方向，子用例对主用例的扩展,3. 错误的用例关系,用例的顺序在活动图中表现,3. 错误的用例关系,4. “其他”用例？,“其他

19、”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？ “其他”用例又代表什么呢？想说明什么样的功能需求？,5.参与者和用例间的关系,“打印报表”和“酒店管理员”之间的关联是有意义的交互吗？,6. 用例粒度太小,用例规格描述常见错误,用例描述中只有参与者动作，没有系统动作。 用例描述中没有主参与者。 描述中过多的用户接口细节，如按钮等界面元素的具体实现。 描述过低的目标级别。,较为合理的用例图,8.4.2 用例的描述,用例图是对系统中的用例的高度概括和直观的表示，但没有细节。 一个用例就象一个故事，使用文字叙述对用例进行详细描述。 一个编写良好的用例应该具

20、有很好的可读性，没有可读性的用例则一点儿用也没有。 用例的描述可以有多种格式，从随意的语言描述到定义严格的用例模板，可根据实际情况选择。,1、用例规格说明（模板）Use Case Specification,用例名称 主要参与者/次要参与者 简要描述 前置条件 后置条件 主事件流（主要成功场景/基本路径） 备选事件流（扩展路径/替代流程/异常事件流） 特殊要求/非功能性需求 发生频率,2、用例与事件流（Flow of Activities）,用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。 事件流的描述包括： 用例何时开始和结束

21、用例何时与参与者交互 参与者与系统之间有什么对象或信息被交换 该行为的主事件流和备选事件流,3、用例与场景（Scenarios）,用例描述的是一组动作序列，在复杂的系统中，用例细节可能存在多种不同的情节，称为变体。 比如：购买商品的用例中收款可以是现金支付、信用卡支付或支票支付。针对每一种情况有不同的场景，一个场景就是一个具体的故事现场，重现一个参与者如何具体完成用例。 主成功场景：故事的主线，用例通常得到成功执行的典型场景。 扩展场景：失败场景，或因为一些特别条件而出现行为分支的步骤（包括失败和成功）,4、用例的前置条件和后置条件,前置条件（pre-condition）：表述在系统允许用例开

22、始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。 如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。 后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。 一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。 某些用例可能没有前置条件或后置条件，比如“查询书目” 。,用例的简要描述,用例名：购买商品 参与者：出纳员 简要描述：顾客带着所要购买的商品来到收款处。收款员记录下商品信息并

23、收款。付款完成后，顾客带着所购买的商品和收据离开。,购买商品,收款员,对“取款”用例的非正式描述,1）用户插入ATM卡并输入密码 2）用户选择取款并输入取款数量 3）系统吐出现金，并从账号余额中扣除取款数,对“取款”用例的完整描述,主参与者：信用卡用户 目标： 用户使用信用卡从ATM机获取现金 范围：银行ATM系统 前置条件： 用户将信用卡插入ATM 触发事件： 用户希望从ATM机上取现金 主事件流： 1）用户插入信用卡到ATM机 2）ATM系统识别卡的ID和账号，并用主银行系统验证其有效性 3）用户输入密码，ATM验证其有效性 4）用户选择取款，并输入提取金额，该数额必须在502000之间，

24、50的倍数 5）ATM系统通知账户所在的主银行系统，传递账号和取款金额，并接受返回的确认信息和账户余额 6）ATM系统发放现金、卡，并打印收据 7）ATM将事务记入日志,对“取款”用例的完整描述（续）,备选事件流： 2a：该卡不能在此ATM机上使用 3a：密码不正确 3b：用户没有及时输入密码 4a：金额不是50的倍数，或不在指定范围 5a：主机死机或网络瘫痪 5b：账户余额不足 发生频率： 一天1000次,“借出图书”的用例描述,5、用例描述的双列格式,每个用例可绘制系统级顺序图,纯文本的用例描述直观性较差 使用UML中的顺序图可以图形化地表现出参与者和系统之间的交互,较为合理的用例规格说明

25、1,用例名称：预定房间 涉及的参与者：酒店前台 描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。 前置条件：前台工作人员必须已经登录到这个系统 后置条件：预定信息正确的记录到系统中 正常事件流： 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。 3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定，工作完成。 备选事件流： 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束 5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。,较为合理的用例规格说明2,n用例名称：取消预订 n主要参与者：酒店前台 n描述：酒店前台利用该用例来取消顾客的预定，如果在指定时间内，则取消时需要返还顾客定金 n前置条件：用户必须已经预订了某个房间 n后置条件：系统将取消预定的房间恢复为空闲，并且定金已返还给顾客 n