UML用例图

前言

在面向对象的设计方法中，采用用例图来描述用户需求，从用户的角度对系统的需求来描述该系统的功能和动态行为，并指出各功能的执行者，系统为执行者完成哪些功能，描述了用例与用例，用例与角色，角色和角色之间的关系， 用于需求分析阶段 。用例图只描述外部用户对系统的看法，而不是系统内部功能的实现方式。简单地说用例图描述的就是有哪些事物或人完成了什么样的功能，用于需求分析阶段对系统的功能分析。

内容

下面是对我用例图的总结。

用例图元素：

角色：就是系统的参与者

用例：系统的功能

关系：关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系

关联关系：

参与者和用例之间通常用关联关系。表示某个参与者执行那个动作。

泛化关系：

一个用例可以被特别列举一个或多个子用例，子用例表示父用例的特殊形式。子用例继承父用例的行为和属性，还可以添加行为或覆盖，改变已继承的行为。

包含关系：

其中一个用例的行为包含了另外一个用例的行为。使一个用例的功能可以在另一个用例中使用，是整体与部分之间的关系。

通常用于这两种情况：（1）如果两个以上的用例有重复的功能，可以将重复的功能分解到另一个用例中，其他用例可以和这个用例建立包含关系。（2）一个用例的功能太多时，可以用包含关系创建多个子用例。

下面这个修改用户信息，查看详细信息，以及删除用户信息都需要查询用户操作，这样会很麻烦并且会重复操作，这时就需要使用包含关系，避免重复的操作。

扩展关系：

把新行为插入到已有的用例中。如果满足某一个条件将到扩展点执行用例，使得系统更容易理解。

下图中如果借阅图书超期，则不能执行归还图书正常操作，如果更改此用例会增加系统的复杂性，所以要在归还图书用例上加扩充点，如果超期归还，就会执行扩展用例缴纳罚款，这样系统更容易理解。

个人理解：扩展用例是可执行可不执行的部分，就像导出一个excel表格一样，基本用例是一定要执行的，扩展用例是满足条件或在有要求的条件下会执行，这也是为什么扩展用例是指向基本用例的。

对用例的描述：

对于复杂的用例需要写事件流来详细地描述这个系统，包括执行者和用例件的交互过程，用例执行的前提条件，用例执行后的状态。

我的机房收费系统用例图

思路：

首先要确定角色，即这个系统的参与者，然后确定用例即功能。

机房系统的角色有一般用户，操作员，管理员

分析每个角色的功能需求，即确定用例：

一般用户：学生查询余额，学生状态查看，学生充值记录查询，学生上级记录查询，

操作员：注册卡，充值卡，退卡，操作员工作记录查询，学生信息维护

管理员：结账，添加删除用户，基本数据设定，值班教师查询，日/周结账单

然后需要准确描述角色和角色之间，角色和用例之间，用例和用例之间的关系。

这是我第一次画的图，管理员权限最高，一般用户权限最低，所以可以用泛化关系来描述他们，即管理员可以理解成是操作员的子类，操作员是一般用户的子类。但是没有很好地考虑用例之间的关系，会出现很多重复的地方。

下面是第二次画的图，添加了用例之间的关系。

总结： 第一次画UML,对用户需求了解不是很深，这个都是根据自己现阶段的理解画的，所以感觉画的不太全面，在学习的过程中要很好地利用网络来帮助自己学习，查多个对比学习，但是还要有自己的思考，感觉在各个图种如何准确描述个元素之间的关系是很重要的，加油！！！