用例
用例(use case)是Ivar Jacobson发明的. 其它的中 文译名有: 用况、用案等. 定义1: 用例是对一个活动者(actor)使用系统的一项 功能时所进行的交互过程的一个文字描述序列. 定义2: 用例是系统、子系统或类和外部参与者交互 的动作序列的说明, 包括可选的动作序列和会出现 异常的动作序列. 用例是代表系统中各个项目相关人员之间就系统的 行为所达成的契约, 软件开发过程是用例驱动的.
实例1：图书馆管理系统中的用例图
1.确定系统涉及的总体信息 图书馆管理系统是对书籍的借阅及读者信息进行统 一管理的系统，具体包括读者的借书、还书，书籍 预订；图书馆管理员的书籍借出处理、书籍归还处 理、预订信息处理；还有系统管理员的系统维护， 包括增加书目、删除或更新书目、增加书籍、减少 书籍、增加读者账户信息、删除或更新读者账户信 息、书籍信息查询、读者信息查询等。
用例图的作用
用例图展示了用例之间以及用例与参与者之间是怎样相互联 系的。用例图对系统、子系统或类的行为进行了可视化，使 用户能够理解如何使用这些元素，并使开发者能够实现这些 元素。 用例图主要用来描述用户的功能需求。UML侧重从最终用户 的角度来理解软件系统的需求，强调谁在使用系统、系统可 以完成哪些功能。用例分析技术已经是一种公认有效的用户 需求获取、分析和描述技术
情况二：假如机票购买者通过呼叫中心，由人工座席 操作订票系统购买机票，那么谁是参与者？
情况三：如果机票购买者通过呼叫中心的自动语音预 定机票而不是通过人工座席，那么谁是参与者？
情况四：如果扩大系统边界，让呼叫中心成为机票预 定系统的一个子系统，并且假设机票购买者将可以 自主选择是通过人工座席还是自动语音登录网站预 订机票，那么谁是参与者？
怎样确定用例的粒度？（用例规模的大小）
用例的粒度可大可小，一般一个系统控制在20个左右，但
没有严格规定 用例是系统级的、抽象的描述，不是细化的（考虑的是 “做什么what”，而不是“怎样做how”） 对复杂的系统可以划分为若干子系统处理
实际上，用例粒度的划分依据最标准的方法是一个 用例的粒度是否合适，是以该用例是否完成了参与 者的某个目的为依据的。
怎样识别用例
参与者希望系统执行什么任务？ 参与者在系统中访问哪些信息？（创建、存储、修改、删
除等） 需要将外界的哪些信息提供给系统？ 需要将系统的哪个事件告诉参与者？ 如何维护系统？
如何判断一个用例是否是一个优秀的用例呢？ ① 用例是否描述了应该做什么，而不是如何做？ ② 用例的描述是否采取了参与者的视点？ ③ 用例是否对参与者有价值？ ④ 用例描述的时间流是否是一个完整场景？ ⑤ 是否所有的参与者、用例都有相应的关联用例或关 联参与者？
几种关系的比较
关系类型 关联 泛化 包含 扩展 说明 actor与use case之间 actor之间或use case之 间 use case之间 表示符号
use case之间
思考：
需求建模—用例图 用例图
需求分析的第一步是确定系统能够做什么，谁来使用 这个系统。
用例图(use case diagram)是显示一组用例、参与者 以及它们之间的关系的图。 用户、项目管理员、分析人员、开发人员、质保人员 都可以通过用例图了解系统功能。
什么是用例？
用例是一种需求方法学 把用例解释为某个参与者(actor)要做的一件事，这样 的一件事有以下几个特征：
1、这件事是相对独立的； 2、这件事的执行结果对参与者来说是可观测的和有意义的； 3、这件事必须由一个参与者发起 ；不存在没有参与者的用 例，用例不应该自动启动，也不应该主动启动另一个用例。 用例总是由一个参与者发起，并且满足特征二； 4、这件事必然是以动宾短语形式出现的 。
在对参与者建模的过程中，注意以下几点： （1）参与者表示人和事物与系统发生交互时所扮演的 角色，而不是特定的人或特定的事物； （2）每个参与者需要一个具有业务一样的名字； （3）一个人或事物在与系统交互时，可以同时或不同 时扮演多个角色。
UML中的Actor实际上是一个版型化的类, 可以有三种 表示形式
例：在“订货”用例中包括几个相关脚本： • 订货顺利进行的脚本; • 相关货源不足时的脚本; • 购货者的信用卡被拒绝时的脚本; • ……
用例图中的关系
关联（accociation） 包含（include） 扩展（extend） 泛化（generalization）
关联（accociation）
一个用例功能过多，可分解成小用例，构成包含依赖
本例中，被包含用例不能单独执行，没有Actor直接指向
它们
扩展关系
扩展（extend） （是一种依赖关系，加了版型
<<extend>>） 一个用例（在某些扩展点extension point上）扩展另一个 用例的功能，构成新用例；箭头方向由扩展用例指向被扩 展用例（即基本用例）； 扩展用例依赖于被扩展用例（基本用例），只是部分片段 组成，不是完整的独立用例，无法单独执行； 扩展用例不一定每次都被执行和调用。（吃饭前也可以不 洗手），而被包含用例每次必须执行。 肯定没有参与者指向扩展用例，因为扩展用例依赖基本用 例。
每个用例都有参与者启动（每个用例必须和一个参与者关
联，有一个参与者来参与），除包含和扩展用例 用例和参与者之间是关联关系，有三种形式。
பைடு நூலகம்
泛化关系
泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中 的行为和含义.
Icon形式
Label形式
Decoration形式
由于Actor实际上是一个类, 因此它们之间可以存在 一定的关系,参与者之间的关系一般表现为特殊/一 般化关系，即，泛化关系。
思考： 1、这样一个需求：每天自动统计网页访问量，
生成统计报表，并发送至管理员信箱。这个
需求的参与者是谁？ 2、自动售货机的参与者是谁？
怎样识别参与者
谁向系统提供信息？ 谁从系统获取（使用）信息？
谁管理这个系统？
谁维护这个系统？ 系统要使用哪些外部资源？（系统启动打印机、扫描仪）
系统是否和已经存在的系统交互？（跨行转账的外部银行
系统、时间到了定时启动系统某功能）
查找参与者时请注意，参与者一定是直接并且主动的 向系统发出动作并获得反馈的，否则就不是参与者。 下面对机票预订系统进行分情况讨论： 情况一：机票购买者通过登录网站购买机票，那么谁 是参与者？
2.确定系统的参与者
根据图书馆管理系统的需求分析，可以确定如下几点： （1）作为一个图书馆管理系统，首先需要借阅者的参与，借阅 者可以登录系统查询所需要的书籍，查到所需书籍后可以考 虑预订，当然最重要的是借书、还书操作。 （2）对于系统来说，借阅者发起的借书、还书等操作最终还需 要图书馆管理员来处理，他们还可以负责图书的预订取消。 （3）对于图书馆管理系统来说，系统的维护操作也是相当重要 的，维护操作主要包括增加书目、删除或更新书目、增加书 籍、减少书籍等操作。 系统的参与者主要有：借阅者、图书馆管理员、图书馆管理 系统维护者。
UML中用例用椭圆表示, 使用动宾结构或主谓结构命 名.
例: 字处理程序中, “置正文为黑 体”和”创建索引”都可以是用 例.
使用用例进行需求分析的特点:
1. 用例从使用系统的角度描述系统中的信息. 2. 用例描述用户提出的一些可见需求, 对应一个具体的用户目标. 3. 用例是对系统行为的描述, 属于UML的动态建模部分.
UML的用例图示意
参与者有三大类：系统用户、与所建造的系统交互的 其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，命名这类参与者时，
应当按照业务命名； 第二类参与者是其它的系统，这类位于程序边界之外的系 统也是参与者。 第三类参与者是一些可以运行的进程，如时间。当经过一 定的时间触发系统中的某个事件时，时间就成了参与者。
3.确定系统用例 识别用例最好的方法就是从分析系统的参与者开始， 考虑每个参与者是如何使用系统的。
（1）借阅者请求服务的用例 ① 登录系统； ② 查询自己的借阅信息； ③ 查询书籍信息； ④ 预订书籍； ⑤ 借阅书籍； ⑥ 归还书籍。
（2）图书馆管理员处理借书、还书等的用例 ① 处理书籍借阅； ② 处理书籍归还； ③ 删除预订信息。
用例图的组成
用例图由如下元素组成： 参与者(Actor)：也称为参与者，它代表系统的用户。 系统边界(System Scope)：它确定系统的范围。 用例(Use Case)：它代表系统提供的服务。 关系(Association)：关联关系（Association）、
包含关系（Include）、扩展关系（Extend）以及
用例和用例图
用例建模是UML建模的一部分，它也是UML里最基 础的部分； 用例建模的最主要功能就是用来表达系统的功能性 需求或行为； 用例建模可分为用例图和用例描述； 用例图是由软件需求分析到最终实现的第一步，它 描述人们如何使用一个系统，是外部参与者所能观 察到的系统功能的模型图，该图呈现了一些参与者 和一些用例，以及它们之间的关系，主要用于对系 统、子系统或类的功能行为进行建模，用画图的方 法来完成； 用例描述用来详细描述用例图中每个用例，用文本 文档来完成。
使用用例时注意的问题:
1. 不要将所有的需求都以用例的形式表示出来. 2. 用例只描述系统功能性方面的需求, 它只是全部需求的一部分. 3. 本质上用例分析是功能分解技术, 但目前是OO开发的第一步. 4. 用例是与实现无关的关于系统功能的描述.
思考：
网上选课系统
脚本
其它译名: 情景、场景、情节、剧本. 脚本就是用例的一次完整的、具体的执行过程。用例 与脚本的关系，如同类与对象的关系。 每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.