一、为什么画用例图
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
二、怎样画
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
1、参与者： 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。 在机房收费系统中的参与者有三个一般用户，操作员，管理员。
参与者的确定方法：
（1）谁将使用该系统的主要功能。
（2）谁将需要该系统的支持以完成其工作。
（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4）系统需要处理哪些硬件设备。
（5）与该系统那个交互的是什么系统。
（6）谁或什么系统对本系统产生的结果感兴趣。
通过以上方法可以确定参与者有：一般用户，操作员，管理员
对于学生在这个系统中我不认为他是一个参与者，因为我理解的是这个系统是学校的机房管理者使用的，而不是学生使用的，学生只是卡的持有者，机房管理员（一般用户，操作员，管理员）操作的学生卡进行注册，充值，退卡，上下机等操作。也就是说机房管理员是和学生的卡打交道的，而不是学生。
一般用户，操作员，管理员之间是泛化关系，即操作员继承一般用户，管理员继承操作员。
2、用例： 用例是外部可见的系统功能单元，这些系统功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。
在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1） 特定参与者希望系统提供什么功能。
（2） 系统是否存储和检索信息，如果是，由哪个参与者触发。
（3） 当系统改变状态时，是否通知参与者。
（4） 是否存在影响系统的外部事件。
（5） 哪个参与者通知系统这些事件。
在本机房收费系统中用例有：上下机，查看记录，修改密码等用例。
3、关联关系（Association）
关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。在UML中，关联关系用箭头来表示。
4、 包含关系（Include）
虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。这有点像通过继承父类并增加附加描述来定义一个类。一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。在UML中，包含关系表示为虚线箭头交<<include>>字样，箭头指向被包含的用例。
5、扩展关系（Extend）
一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。在UML中，扩展关系表示为虚线箭头加<<extend>>字样，箭头指向被扩展展的用例。
6、泛化关系（Generalization）
一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。
