用例和用例图.

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