识别用例和用例图

第3页
2015年5月14日星期四
4.1 识别用例图
建立一个系统的用例图通常是开发过程中一个 困难的部分。
建立一个用例图包括以下步骤：
定义系统。 确定参与者和用例。 描述用例。 定义用例和参与者之间的关系。 定义用例之间的关系。
第4页 2015年5月14日星期四
4.1 识别用例图
客户和开发者通过用例图达成共识，用例图包 括以下几个内容：
第9页 2015年5月14日星期四
4.2 用例图组件
二、用例(Use Case)
The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. A use case is a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system.
第19页
2015年5月14日星期四
4.3 用例关系
3. 泛化关系
用例的泛化关系指的是一个父用例可以被特 化为多个子用例，而父用例和子用例之间的 关系就是泛化关系。 A generalization from use case A to use case B indicates that A is a specialization of B.
第13页
2015年5月14日星期四
4.2 用例图组件
用例的文档化
一旦决定了每个用例将做什么和谁将调用它，就应 该写一个简短的文本来描述这一点。这段描述在开 发过程的初始阶段完成，它应该以一些句子说明用 例的目的，还应该说明用例提供的功能的高层次定 义。
第14页
2015年5月14日星期四
4.2 用例图组件
第17页
2015年5月14日星期四
4.3 用例关系
2. 扩展关系
在一定条件下，把新的行为加入到已有的用例中，获得的新 用例称为扩展用例，原有的用例称为基础用例，从扩展用例 到基础用例的关系就是扩展关系。
An extend relationship from use case A to use case B indicates that an instance of use case B may be extended by the behavior specified by A.
识别用例的方法
使用已经定义的参与者来识别用例。对于每个参与 者，都需要回答一系列问题：
参与者需要哪些功能？ 参与者需要什么支持？
参与者如何与系统信息交互？
用例必须一直与至少一个参与者相关联。
第15页
2015年5月14日星期四
4.3 用例关系
用例之间的关系
用例与用例之间有三种关系：
包含关系（include）：当一个用例一直使用 另一个用例时就确定为包含关系。
谁将与系统交互。（参与者）
系统将做什么。（用例） 需要什么接口。（关系）
第5页
2015年5月14日星期四
4.2 用例图组件
一、参与者(Actor) ：
参与者代表的是与系统交互的任何人或任何事物。 参与者是外部的，不是系统的组成部分，但如果要 使用或支持参与者，则需要一个接口。 An Actor defines a coherent set of roles that users of use cases play when interacting with use cases. An actor has one role for each use case with which it communicates.
2015年5月14日星期四
4.4 书写用例文档
前置后置条件 ATM自动取款机的取款用例的前置条件？
ATM用户的帐户里有足够的金额
第26页
2015年5月14日星期四
4.4 书写用例文档
基本路径描述 1.使用主动语言
2.句子必须以参与者或者系统做主语
3.每一句都要朝目标迈进 4.只书写“可观测的” 5.不要涉及界面细节
第8页
2015年5月14日星期四
4.2 用例图组件
参与者如何确定？可以通过以下一些问题来帮 助你确定参与者：
谁使用系统的主要功能? 谁从系统获取信息？ 谁支持和维护系统？ 谁需要系统的支持以履行他们的日常职责？ 在组织里这个系统被用到哪里？ 与系统交互的是哪些硬件设备？ 与这个系统交互的其他系统是哪些？
第27页
2015年5月14日星期四
4.4 书写用例文档
使用主动语言 1.欧文从贝克汉姆处得到传球，守门员...
2.贝克汉姆传球给欧文,欧文射门,守门员扑救...
3.用户名和密码被验证
4.系统验证用户名和密码
第28页
2015年5月14日星期四
4.4 书写用例文档
每一句都要朝目标ቤተ መጻሕፍቲ ባይዱ进 参与者填写姓名
订票
在UML中，用例的泛化关系是通过一个从 子用例指向父用例的三角箭头表示的，如右 图所示。
网上订票
电话订票
第20页
2015年5月14日星期四
例1 建立项目与资源管理系统的Use case图
系统的主要功能是：项目管理，资源管理和系 统管理。项目管理包括项目的增加、删除、更 新。资源管理包括对资源和技能的添加、删除 和更新。系统管理包括系统的启动和关闭，数 据的存储和备份等功能。
系统能够从帐户中扣除取款金额
系统允许选择“打印数据” 或者 “不打印数据”
系统能够显示交易结束信息
第2页 2015年5月14日星期四
4.1 识别用例图
用例图最重要的作用是使最终用户和开发者之 间进行交流。
在开发的初始阶段，通过确定系统的参与者和 主要用例来建立用例图。在细化阶段，把更多 的详细信息加入到已确定的用例中，用例模型 将越来越成熟。
第4章 用例和用例图
一个系统的初始阶段是从获得需求开始的。一 旦需求确定了，就可以在问题说明中确定用例。
本章说明了如何从问题说明中提取用例以及如 何建立用例图模型。
第1页
2015年5月14日星期四
用例：基于用户目标的需求组织形式
立足开发者视角（银行取款） 系统要求用户输入合法的密码
系统能够接受用户录入的取款金额
第6页
2015年5月14日星期四
4.2 用例图组件
一、参与者：
参与者用于表示使用系统的对象，参与者可以是 一个人或者一个系统。参与者由一个固定的图形表 示，并在图形下面列出参与者的名字。
管理员
第7页
2015年5月14日星期四
4.2 用例图组件
每个参与者的名称要反映参与者的角色，而不 是它的功能或它的实例，所以给参与者提供一个最 能描述其功能的合适名称是非常重要的。并且我们 要避免为代表人的参与者起一个实际人名。如：参 与者张三是个“教师”，是他所扮演的角色。如果 命名为 “张三”就不对了。
第23页
2015年5月14日星期四
4.4 书写用例文档
前置后置条件（起点与终点） 前置条件：开始用例前所必需的系统及其环境 条件。 注：前置条件必须是系统在用例开始前能检测 到的。 后置条件：用例成功后系统应该具备的状态。
第24页
2015年5月14日星期四
4.4 书写用例文档
前置后置条件
第25页
第10页
2015年5月14日星期四
4.2 用例图组件
用例简介
用例对参与者和系统之间的交互建立模型。它是通 过参与者调用功能来启动的，这将会产生一个可视 化的结果。一个用例产生的结果必须是一个给系统 用户的特定值。
用例的功能和结果必须是一个完整且有意义的事件 流。它阐明了系统提供给参与者的功能。
第11页
第22页
2015年5月14日星期四
4.4 书写用例文档
（10） ATM从客户帐户中减去所取金额。 （11） ATM向客户提供要取的钱。 （12） ATM打印清单。 ATM退出客户的卡，用例结束。 子事件流a： a1． 提示用户输入无效密码，请求再次输入； a2． 如果三次输入无效密码，系统自动关闭，退出客户银行卡。 子事件流b： b1． 提示用户余额不够。 b2． 返回（5），等待客户重新选择。 后置条件：结束取款事件。
第21页
2015年5月14日星期四
4.4 书写用例文档
用例描述： 用例名称：取款 前置条件： 基本路径： （1） 客户将卡插入ATM机，开始用例。 （2） ATM显示欢迎消息并提示客户输入密码。 （3） 客户输入密码。 （4）ATM确认密码有效。如果无效则执行子事件流a。 （5） ATM提供以下选项：存钱，取钱，查询。 （6） 用户选择取钱选项。 （7） ATM提示输入所取金额。 （8） 用户输入所取金额。 （9） ATM确定该帐户是否有足够的金额。如果余额不够，则执行子事件流b。
第31页
2015年5月14日星期四
4.4 书写用例文档
不要涉及界面细节 会员从下拉框中选择类别
会员在相应文本框中输入查询条件
会员点击”确定”按钮
第32页
2015年5月14日星期四
4.4 书写用例文档
用例名称：结账 用例描述：会员完成一次与商店的交易 参与者：会员 前置条件：会员已经完成选购 基本路径： 1. 会员请求结账 2. 系统检查账户是否处于打开状态 3. 系统检查库存是否满足 4. 系统检查会员提交的信息是否充分 5. 系统合计订单总价 6. 系统显示收费明细 7. 会员确认 8. 系统保存订单信息，通知供应商发货，减少相应库存数量。