实战机房收费系统之-----UML用例图

   用例图，在软件开发的需求阶段构思绘制，掌握好用例图的定义、作用、构成、绘图顺序步骤，基本上就OK了。

   下面就从画机房收费的用例图来进行分析：

一、机房收费系统需求介绍：

   功能：（用途的多与少）

   上下机：实现学生上机、下机的计时（从登陆系统到离开机房），自己卡内时间的流逝，减化了值班人员的记录工作量。

   计费：根据学生用户类型的不同，实现自动根据上机时间进行计费。同时实现值班人员的充值、退卡、结账的功能。

   查询：对于卡内余额、用户使用记录、值班记录、上下机记录、账单等进行查询。

   考勤：对于图书馆值班人员定时上下班起到了监督。

   故障处理：当出现系统故障或硬件设施故障时，强制所有用户下线。

二、分析

   根据需求，便可以初步定义出系统的参与者为：学生、一般用户、操作员、管理员，如果再深究一下，系统数据不是保存在程序中，So把数据库也算作参与者之一。

   然后去思考系统可以实现的功能，无非就是对学生操作的管理，对工作人员具体管理，以及对金钱的管理及流通，所以可以把系统分为3个模块，1、学生上机操作管理及信息维护；2、账目管理；3、工作人员操作及考勤管理。

三、画图

    于是可以将系统的需求按模块用如下几幅用例图来表示：

   （1）整体把控图

               


    把对机房收费系统的所有操作看做是一个用例，主要是表示出系统的参与者、参与着之间的关系。

   

   （2）上机操作管理及信息学生维护图

           


   该模块从两条线出发：1、学生信息管理，2、学生基本操作进行

   针对学生信息可以实现：查询、修改、维护；对于学生基本操作的进行：上下机、强制学生下线以及充值和退卡。

 

   （3）工作人员管理图

                   


    该模块涉及系统登录、修改密码、基本数据的设定这些基本操作，再者就是对工作记录的查询，需要注意操作执行者的权限。

 

   （4） 账目管理图

        


    各个权限级别的工作人员涉及到账目的操作，涉及到余额的查询、收取返还金额的查询，结账以及账单查询。

 

总结：

   1、对需求进行抽象把系统分成3个小部分，对每个小系统进行画图，这样系统用例粒度的把握更容易控制。

   2、注意参与者与参与者之间的关系主要是泛化关系，用例与用例之间的关系主要为include、extend、泛化。参与者和用例之间大多为单向关联。

   3、UML是通过9个方面去描述一个系统，所以没有说那个图重要或者不重要，都很重要，只是我们现阶段对后面的图用的较少，现在学不好以后得还。