用例图。
组成：系统边界。参与者。用例。关系。
参与者：Actor不是人，而是指参与用例时担当的角色。
如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。
怎样识别参与者呢？
系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度呢？
用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。对复杂系统可以划分为若干个子系统处理。
怎样获取用例呢？
参与者希望系统执行什么任务？
参与者在系统中访问哪些信息（创建、存储、修改、删除等）？
需要将外界的哪些信息提供给系统？
需要将系统的那个事件告诉参与者？
如何维护系统？
UML中的四种关系。
关联（association）
包含（include） 
扩展（extend）
泛化（generalization）
关联关系
描述参与者和用例之间的关系。
用单向箭头，表示谁启动用例。
每个用例都有角色启动，除了包含和扩展用例。
包含。
是指两个用例之间的关系。其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。
如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。
上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。且这三个用例和提取出的这个用例之间是包含的关系。
执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。
如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例
扩展。
也是指两个用例之间的关系。一个用例可以被定义为基础用例的增量的扩展，称作为扩展关系。扩展关系是把新的行为插入到已有的用例中方法。基础用例即使没有扩展用例的执行不会涉及扩展用例，只有在特定的条件发生，扩展用例才被执行。
泛化（继承）。
一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。
任何父用例出现的地方子用例也可出现。
1 对用例的描述。
2 用例描述的组成
用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。
事件流：就是用例执行时，由一序列活动组成的控制流。
基本事件流：对用例中常规、预期路径的描述。
扩展事件流：主要是对一些异常情况、选择分支进行描述。
前置条件：在用例启动时参与者（actor）与系统应置于什么状态。
后置条件：用例结束时系统应置于什么状态。
以上述的"新增书籍信息"为例，说明如何细化用例描述。
用例名称：新增书籍（UCO1）
简要说明：录入新购书籍信息，并自动存储建档。
事件流：基本事件流和扩展事件流。
非功能需求
前置条件：用户进入图书管理系统。
后置条件：完成新书信息的存储建档。
扩展点：无
优先级：高（满意度 5 ，不满意度5 ）
基本事件流
扩展事件流。
如下例所示建立用例模型。
有一个业务需求如下，要求我们为其构件一个用例图。
1）系统可以供教师使用来为学生记录成绩。
2）系统根据需要创建报告卡。
首先这里面要问到的是：11）中教师可以记录学生信息，这就是说教师可以录入、修改和删除学生信息了。22）中系统要创建报告卡，是谁来创建报告卡呢？这里就应该有权限的问题了，系统需要管理人员来来执行这项工作，另一个方面做系统的维护工作。报告卡创建后干什么？管理人员检查其准确性之后，由教师来分发报告卡。33） 系统允许用户浏览成绩，是谁可以浏览成绩呢？是学生和老师。
主要用例：录入成绩。更新成绩。生成报告卡。报告卡准确性。分发报告卡。浏览成绩。
要区分用例的优先级。
首先是 ：记录成绩，浏览成绩，更新成绩，生成报告，检查报告卡的准确性，分发报告卡。
细化每一个用例。
对"记录成绩"进行细化，下面是对该用例的主事件流。
从细分的用例中发现新的用例，并根据优先级重新排列。
机房收费系统的用例图。
1、首先是分析系统中的角色（Actor）。
谁向系统提供信息？-----学生
谁从系统获取信息？----学生、管理员、操作员、一般用户
谁操作这个系统呢？--一般用户、操作员、管理员。
谁维护这个系统呢？---管理员。
系统要使用的外部资源？---数据库。
系统是否和已经存在的系统交互？---好像没有。
从中找出这个系统的Actor---（学生、一般用户、管理员、数据库）
找出的参与者希望系统执行什么任务？
学生---去注册卡号，后充值，上机，下机，付钱，查看信息（查看自己的个人信息，上机信息，卡内的余额信息），不想用了就注销卡号。（学生的需求是要通过系统用户对系统的操作来完成的。所以学生和系统用户这两个角色之间是关联关系。）
一般用户—主要是用这个系统来管理学生上下机。可以登录到系统中去，后学生刷卡上机，显示上机的学生的记录，显示登录时间，查看学生上机状态，学生下机，显示下机时间和消费金额，可以修改自己的密码，查询余额。
操作员---主要是用这个系统为学生进行注册充值以及查询一些信息。登录到系统中去，可修改密码，根据学生的要求使用系统来，注册，充值，退卡，注册后充值可以查看收取金额，学生基本信息维护，学生上机统计信息，最后退卡时，查看金额退还信息来退还相应的钱数。最后可以查看老师和自己的工作记录。
管理员---登录到系统中去，可以修改密码以确保安全性。利用这个系统可以对学生的上下机情况查看。可以对一般用户和操作员的工作记录查看。
参与者在系统中访问哪些信息（创建、存储、修改、删除等）？
参与者在系统中需要访问
需要将外界哪些信息供给系统？
外界提供给本系统的信息是---学生信息、系统时间信息、系统用户信息。
需要将系统的哪个事件告诉参与者？
……无……
如何维护系统？
管理员负责对系统的维护-----基本数据的设定。
用例图如下所示：
学生和一般用户的用例图。
学生和操作员的用例图。
学生和管理员用例图所示：
原文地址：http://www.cnblogs.com/keyyang/p/3817885.html
