UML，类图

类图是所有面向对象建模方法的核心部分，描述了系统的静态结构。

一.类图概述

1.组成部分 ： 类、类间关系

【类】 具有相同属性和相同方法的对象的集合。

【类间关系】 表示了两个类之间的关系。

2.图符

3.关系

类间的关系，在前面的博客中有详细的梳理，这里也就不再赘述了。请看《UML，理理关系》

二.如何绘制类图

理论知识都清楚了，可要动手开始画的时候，怎不知道从何开始。于是，还是先定下个绘制类图的步骤吧，掌握全局很重要。

1.需求描述。

2.发现类。

3.筛选类，得到候选类。

4.关联分析，建模；多重分析，再建模。

5.限定与修改

三.机房收费系统画类图前的分析

【需求描述】

机房收费系统，我们用VB实现了第一遍了，对其整个系统也是了如指掌。下面就用文字来描述一遍：

系统中，可供三类用户使用，分别为一般用户、操作员和管理员。其中，这三类用户最大的区别就在于权限。权限不同，各类用户所能执行的操作也就不同。

先了解权限最低一级的用户即一般用户的各项工作，分别为：帮助学生查询余额、上机记录、充值记录、上机状态以及修改密码。在实现查询功能之时，很简单，都是将卡号输入，系统就会自动将结果按照不同方式显现。可能是卡号不存在，也可能是显示正常的查询结果。

再者是操作员，其需要做的是：注册、充值、退卡，查询收取金额、返还金额数、学生上机统计信息、工作记录，以及学生基本信息维护。通过填写一系列信息，完成某个同学的卡号注册；通过卡号，可以充值或是退卡；通过卡号、日期、金额等一些选项，系统实现组合查询功能。另外，其也继承了一般用户所有的各项工作权限。

最后是管理员这一类，他要做的工作很简单，包括最初的基本数据设定、添加或删除用户、结账、查看日/周结账单以及查看正在值班老师。为了方便上机收费的查询情况，管理员可以通过结账单对收费进行打印报表。除此之外，也同时继承了一般用户与操作员的各项工作权限。

【筛选类】

“系统”是指要开发的系统本身，无须对其建模。

“用户”是指系统所要面向的人的统称，其中他们都具有用户名、用户ID等基本信息，所以可对其进行建模。

“一般用户”、“操作员”、“管理员”，很明显，都是此系统重要的用户类的实例化对象。

“学生”，同样也是不可缺少的一类，其包含姓名、性别、学号等各种基本属性。

“卡”，这也算是一大类吧，一张卡，包含的信息还是很多的，卡号、余额、各种记录等。

“各项金额数”、“各项工作记录”都是查询的结果，可能是一个数字，也可能是一些信息集合，都无须对其建模。

【候选类或对象】

综上分析，机房收费系统中所得出的类或实例化后的对象共包括六个，分别为：用户、一般用户、操作员、管理员、学生和卡。

【分析与建模】

【职责分析，详细类图】

用户类：为此次系统中面向的终端人员，是对此系统进行操作的人员的统称。其属性包含：用户名称和用户ID。

管理员：此次系统权限最大的使用者，其主要的成员方法是：基本数据设定、编辑用户、结账、查看账单及正在值班人员。

操作员：主要是对卡进行各种操作的人员。其主要职责是注册、充值、办理退卡；其中也可执行各种查询功能，包含收取金额、金额返还、上机统计信息、学生基本信息的维护和操作员的工作记录。

一般用户：其主要是实现一些关于帮助学生查询或修改各项卡号信息，如查询余额、上机记录、充值记录、上机状态以及修改密码的操作。

卡类：一张基本的上机卡，包含的属性有办卡人用户名、用户号以及学生基本信息。

学生类：一个学生一张卡，包含各种基本的信息是：卡号、学号、学生姓名、性别、年级、专业、班级等。

第一次分析机房收费系统的类图，一定还有很多地方分析有错误或没有周全考虑的地方。不过通过这一次的学习，自己还是又对类图有了进一步更深的了解。学习是需要反复的，以后一定还需要回到这里，重新画出一张更好的UML类图的。