第3章 用例图

案例分析--用例图
实例：“杂志流通”
在杂志的内容被一个雇员分析之前，每个杂志 首先由图书馆登记；分析员认为有意义的文章 被汇总输入到系统中；随后，杂志在雇员中传 阅。在此过程中，要求生成流通通知。该通知 被附到杂志上，并且包含现在正在阅读杂志的 雇员的名字。最后，在最后一名读者把杂志返 回到图书馆时，它由图书馆来存档。
3.1 参与者
从上面的问答得到系统中初步的类和对象：
GUI（图形用户界面）：识别用户的命令，接收 用户的输入，显示程序的结果。
Recorder（记录员）：记录中奖信息。 Chooser（抽奖者）：抽出中奖号码。 Printing（打印对象）：打印中奖信息。 Searching（查询对象）：为奖票持有者查询中
3.2 用例
问：抽奖主持人用这个系 抽奖程序初步的用例图
统做什么事情？兑奖人员
抽奖程序
如何用这个系统帮助兑奖
？
抽出中奖号码
答：抽奖主持人用这个系统 活动主持人 抽出中奖号码，兑奖人员用
活动主持人
这个系统打印本次活动所有
打印中奖记录
的中奖记录。再对照记录兑 兑奖者
兑奖者
奖。
查询中奖情况
奖票持有者
奖票持有者
用例图的构成4要素：
参与者 用例 系统边界 关联
用例图的基本概念
3.1 参与者
1. 参与者(Actor)的概念
参与者是指存在于被定义系统外部并与该系统发生 交互的人或其他系统，他们代表的是系统的使用者 或使用环境。
在确定系统的用例时，首要问题就是识别参与者 （是一个类！！！！！！不是对象）。
如何识别用例？
参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？
或者必须通知参与者关于系统中的发生的事件？ 这些事件代表了哪些功能？ 系统需要哪些输入/输出？ 这些输入输出来自哪里或者到哪里去？ 哪些用例支持或维护系统？ 是否所有功能需求都被用例使用了？ 系统当前实现的主要问题是什么？
答（3）：奖票持有者输入“奖票号”，程序就给出“是否 中奖和中奖等级”这个查询结果。
用例图的基本概念
在面向对象的分析设计方法中，用例模型主要用 于表述系统的功能性需求，系统的设计主要由对 象模型来记录表述。
用例定义了系统功能的使用环境与上下文（即描 述了如何处理业务事件时所处的上下文和结构）。 每一个用例描述的是一个完整的系统服务。
获取用户需求—从与用户交流开始需求分析
E：请问你在做XX事情时，需要事先准备什么吗？ F：请问你在做XX事情时需要别的数据吗？ G：请问你在做完XX事情后将结果放到哪里呢？有没有人在
等着用这个结果？ H：请问你在处理XX事情时，XX数据要精确到小数点几位？ I：请问你以前用过类似的系统吗？如果用过请谈谈那些系
非功能性需求
可靠性 可扩展性 安全性 常用事务处理 监控 兼容性 易用性 可维护性 性能
软件需求的内容
抛异常，存log文件，错误日志 浏览器、操作系统、第三方软件兼容 用户体验
需求开发中的信息收集技巧
demo
获取用户需求—从与用户交流开始需求分析
提问:
A：请问有哪几个岗位的工作人员要使用这个系统？ B：请问XX岗位的工作人员用这个系统来做什么事？ C：请问一般情况下XX岗位的人做XX事时，从哪里开始，经
奖情况。 Checking(公证人)：验证奖票的有效性。 Ticket（奖票） Records（中奖信息）
3.1 参与者
系统边界决定了参与者
参与者是由系统的边界所决定的，如果所要定义的系统边界仅限 于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象 为一个参与者。
3.1 参与者
问：奖票的持有者不用这个系统吗？如果他们想知道 手中的奖票是否中奖怎么办呢？
答：奖票持有者也应该能使用这个系统，如果想知道是否中奖， 可以查询中奖记录。
获取用户需求—从与用户交流开始需求分析
问：抽奖主持人用这个系统做什么事情？兑奖人员 如何用这个系统帮助兑奖？
答：抽奖主持人用这个系统抽出中奖号码，兑奖人员用这个 系统打印本次活动所有的中奖记录。再对照记录兑奖。
获取用户需求—从与用户交流开始需求分析
问（2）：“兑奖人期望怎样的操作能打印出中奖 结果，对中奖信息的格式有什么要求吗”？
答（2）：抽奖程序的界面期望能与一般的Windows程序类 似，兑奖人员只须点击一个按钮就能打印出中奖信息。 中奖信息打印成表格较好。
问（3）：“奖票持有者期望怎样进行中奖情况查 询，他想得到哪些查询结果？”
3.1 参与者
2. 参与者之间的关系
泛化关系：参与者之间可以有泛化(Generalization)关系 （或称为"继承"关系）。
3.1 参与者
3. 参与者与用例之间的关系
关联关系：一个参与者完成系统的一项功能。
案例--大学图书管理系统
可能的需求如下：
读者在大学图书管理系统中办理了借书证。读 者分学生和教师。读者借还书籍要通过图书管 理员之手来完成。系统管理员负责大学图书管 理系统的借书证维护和图书数据维护等操作。
3.1 参与者
问：抽奖主持人用这个系统做什么事情？兑奖人员 如何用这个系统帮助兑奖？
答：抽奖主持人用这个系统抽出中奖号码，兑奖人员用这个 系统打印本次活动所有的中奖记录。再对照记录兑奖。
问（1）：“工会以前进行抽奖活动时，要做哪些事 ？或者产生一个中奖号码的过程是怎样的？”
答（1）：工会以往进行抽奖活动的情况：活动前，制定抽奖 规则，准备奖票，准备奖品，发放奖票给所有的参与者， 一般一人一票。活动进行时由主持人自己或者邀请一位代 表抽出一个中奖号码。公证人进行公证，确认抽奖有效。 记录员记录中奖信息。如果中奖人数足够，抽奖完成，否 则，继续抽出下一个中奖号码。
获取用户需求—从与用户交流开始需求分析
如果分析人员不清楚“抽奖规则”的话，则: 问：“请详细解释抽奖规则有哪些内容？”
答：抽奖规则在活动进行之前就应该规划好。内容包括： 共设几个中奖等级，每个等级中奖人数，奖品。以今年 的安排为例：一般设五个等级：特等奖，一等奖，二等 奖，三等奖，鼓励奖。每个等级获奖人数：特等奖2名， 一等奖20名，二等奖50名，三等奖100名，剩下的都是 鼓励奖。
第3章 用例图
学习目标
理解用例模型的基本概念 掌握识别参与者、用例的方法 掌握用例模型中各种关系的分析 掌握用例描述（用例规约/用例约束）的分析与 编写 了解UML中用例建模的注意事项
补充：需求分析
关于项目涉众
我们称参与软件项目或受软件项目影响的人为项目干系 人，或称为项目涉众，主要包括：
例如：（1）客户建议和订单接收
（2）John希望从保险公司获取一份汽车保险 参与者是一个集合概念。一个具体的外部实体仅
代表同一类参与者的一个实例。
参与者分类（优先级）：
主要参与者和次要参与者
主动参与者和被动参与者
3.1 参与者
如何确定参与者？
使用系统主要功能的是谁？ 谁需要借助系统完成日常工作？ 系统从谁或哪些系统获得数据？ 系统会为谁或哪个系统提供数据？ 系统会与哪些其它系统交互 系统是由谁来日常维护和管理的？ 系统的控制硬件有哪些？ 谁对本系统产生的结果感兴趣？
3.1 参与者
3.1 参与者
实例：开发一个“抽奖程序” 标识参与者
问：“谁将会使用这个系统？”
答：抽奖活动的主持人(Director)在抽奖过程中、兑奖工作 人员(Dispense)在分发奖品时都需要使用这个系统。
问：奖票的持有者不用这个系统吗？如果他们想知道 手中的奖票是否中奖怎么办呢？
答：奖票持有者也应该能使用这个系统，如果想知道是否中奖， 可以查询中奖记录。
软件开发与运行环境、开发进度、产品成本、 培训需求等内容应该在项目需求中进行定义。
软件需求的内容
软件需求大致包含功能性Function需求与 非功能性Non-Function需求（诸如性能、 可靠性等）两类：
功能性需求的实质是目标系统与用户或外部系 统间的交互而体现出的一种外在行为；
非功能性需求则蕴含于这些外在行为中，体现 为行为的空间（执行的环境和数量，例如PDA 上的浏览器、并发用户数）和时间（性能，例 如执行的延迟时间）等附属特性。
3.2 用例
实例：开发一个“抽奖程序”
识别用例
问：“谁将会使用这个系统？”
答：抽奖活动的主持人(Director)在抽奖过程中、兑奖工作 人员(Dispense)在分发奖品时都需要使用这个系统。
问：奖票的持有者不用这个系统吗？如果他们想知道 手中的奖票是否中奖怎么办呢？
答：奖票持有者也应该能使用这个系统，如果想知道是否中奖， 可以查询中奖记录。
软件需求
软件需求的定义
1）定义
IEEE (美国电气和电子工程师协会) 软件标准词汇表定 义需求为：
① 用户解决问题或达到目标所需要的条件或权能。 ② 系统或系统部件要满足合同、标准、规范或正式规定文
档所需具有的条件或权能。 ③ 一种反映上面(1)或(2)所描述的条件或权能的文档说明。
客户：为达到业务目标而投资项目或购买产品 用户：直接或间接使用产品 需求分析员：负责获取和编写需求 开发人员：根据需求文档设计、实现、维护软件 测试人员：检测产品的分析、设计、实现与预计的一致 文档编制人员：负责编写用户手册、用户培训资料和帮助系统 法律人员：保证产品的合法性和知识产权 生产人员：制造包含该软件的产品 其他人员：市场策划、营销、技术支持以及其他辅助人员