用例图。

组成：系统边界。参与者。用例。关系。

参与者：Actor不是人，而是指参与用例时担当的角色。

如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。

怎样识别参与者呢？

是谁向系统提供的信息呢.

谁向系统获取信息。

谁操作系统。

系统使用哪些外部资源

系统是否和已经存在的系统交互

系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。

用例分析可以认为是对系统功能的分解。

怎样确定用例的粒度呢？

用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。对复杂系统可以划分为若干个子系统处理。

怎样获取用例呢？

参与者希望系统执行什么任务？

参与者在系统中访问哪些信息（创建、存储、修改、删除等）？

需要将外界的哪些信息提供给系统？

需要将系统的那个事件告诉参与者？

如何维护系统？

UML中的四种关系。

关联（association）

包含（include） 

扩展（extend）

泛化（generalization）

关联关系

描述参与者和用例之间的关系。

用单向箭头，表示谁启动用例。

每个用例都有角色启动，除了包含和扩展用例。

包含。

是指两个用例之间的关系。其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。

如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。

上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。且这三个用例和提取出的这个用例之间是包含的关系。

执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。

如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例

扩展。

也是指两个用例之间的关系。一个用例可以被定义为基础用例的增量的扩展，称作为扩展关系。扩展关系是把新的行为插入到已有的用例中方法。基础用例即使没有扩展用例的执行不会涉及扩展用例，只有在特定的条件发生，扩展用例才被执行。

泛化（继承）。

一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。

任何父用例出现的地方子用例也可出现。

1 对用例的描述。

用例图：只能描述系统的大概功能，是一种视图。

用例描述：更详细地描述用例的功能。

2 用例描述的组成

    用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。

事件流：就是用例执行时，由一序列活动组成的控制流。

基本事件流：对用例中常规、预期路径的描述。

扩展事件流：主要是对一些异常情况、选择分支进行描述。

前置条件：在用例启动时参与者（actor）与系统应置于什么状态。

后置条件：用例结束时系统应置于什么状态。

以上述的"新增书籍信息"为例，说明如何细化用例描述。

用例的概要描述

用例名称：新增书籍（UCO1）

简要说明：录入新购书籍信息，并自动存储建档。

事件流：基本事件流和扩展事件流。

非功能需求

前置条件：用户进入图书管理系统。

后置条件：完成新书信息的存储建档。

扩展点：无

优先级：高（满意度 5 ，不满意度5 ）

详细描述

基本事件流

图书管理员向系统发出"新增书籍信息"请求。

系统要求图书管理员选择要增加的书籍是计算机类还是飞信计算接类

图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号。

图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本。页数、定价。是否有CD-ROM。

系统确认输入的信息中书名没有重名。

系统将所输入的信息存档建档。

扩展事件流。

A 如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入。

A（1）图书管理员选择取消输入，则结束用例，不做存储建档工作。

A（2）图书管理员选择修改书名后，转到A。

如下例所示建立用例模型。

有一个业务需求如下，要求我们为其构件一个用例图。

1）系统可以供教师使用来为学生记录成绩。

2）系统根据需要创建报告卡。

系统允许用户浏览记录的成绩。

首先这里面要问到的是：11）中教师可以记录学生信息，这就是说教师可以录入、修改和删除学生信息了。22）中系统要创建报告卡，是谁来创建报告卡呢？这里就应该有权限的问题了，系统需要管理人员来来执行这项工作，另一个方面做系统的维护工作。报告卡创建后干什么？管理人员检查其准确性之后，由教师来分发报告卡。33） 系统允许用户浏览成绩，是谁可以浏览成绩呢？是学生和老师。

从中得到这个系统的参与者是：教师，学生，管理员。

主要用例：录入成绩。更新成绩。生成报告卡。报告卡准确性。分发报告卡。浏览成绩。

要区分用例的优先级。

首先是 ：记录成绩，浏览成绩，更新成绩，生成报告，检查报告卡的准确性，分发报告卡。

细化每一个用例。

对"记录成绩"进行细化，下面是对该用例的主事件流。

首先是教师要确定录入哪些学的成绩。

系统中要确保学生在数据库中。

教师说明记录哪像作业的成绩。

系统开始数据库的一些事物。

系统为学生把作业加入到数据库中。

教师输入学生作业的成绩。

系统核对输入的成绩是否符合正确的范围和格式。

系统记录作业的成绩。

系统结束事物的处理。

系统提示教师成绩已经记录好。

从细分的用例中发现新的用例，并根据优先级重新排列。

机房收费系统的用例图。

1、首先是分析系统中的角色（Actor）。

谁向系统提供信息？-----学生

谁从系统获取信息？----学生、管理员、操作员、一般用户

谁操作这个系统呢？--一般用户、操作员、管理员。

谁维护这个系统呢？---管理员。

系统要使用的外部资源？---数据库。

系统是否和已经存在的系统交互？---好像没有。

从中找出这个系统的Actor---（学生、一般用户、管理员、数据库）

基本Use case。

找出的参与者希望系统执行什么任务？

学生---去注册卡号，后充值，上机，下机，付钱，查看信息（查看自己的个人信息，上机信息，卡内的余额信息），不想用了就注销卡号。（学生的需求是要通过系统用户对系统的操作来完成的。所以学生和系统用户这两个角色之间是关联关系。）

一般用户—主要是用这个系统来管理学生上下机。可以登录到系统中去，后学生刷卡上机，显示上机的学生的记录，显示登录时间，查看学生上机状态，学生下机，显示下机时间和消费金额，可以修改自己的密码，查询余额。

操作员---主要是用这个系统为学生进行注册充值以及查询一些信息。登录到系统中去，可修改密码，根据学生的要求使用系统来，注册，充值，退卡，注册后充值可以查看收取金额，学生基本信息维护，学生上机统计信息，最后退卡时，查看金额退还信息来退还相应的钱数。最后可以查看老师和自己的工作记录。

管理员---登录到系统中去，可以修改密码以确保安全性。利用这个系统可以对学生的上下机情况查看。可以对一般用户和操作员的工作记录查看。

参与者在系统中访问哪些信息（创建、存储、修改、删除等）？

        参与者在系统中需要访问

需要将外界哪些信息供给系统？

外界提供给本系统的信息是---学生信息、系统时间信息、系统用户信息。

需要将系统的哪个事件告诉参与者？

        ……无……

如何维护系统？

            管理员负责对系统的维护-----基本数据的设定。

        用例图如下所示：

学生和一般用户的用例图。

学生和操作员的用例图。

学生和管理员用例图所示：