类图之我所见


 

 

   紧接着上一篇的用例图,接着来谈一下类图。


   说到类图,我们首先来了解一句话:对象是类的实例,而类是对象的抽象。这就需要


我们来发挥我们的想象力,来抽象一些东西。下面进入正题。


重温需求

   因为有那句话的存在,所以我们要在用户的需求中来抽象出系统的静态结构。


    学生:我想能够像网吧那样,先刷卡然后再系统中输入自己的用户名和账号就可以


上机。并且我也能够在系统中修改自己的用户信息和用户密码,查看自己的账号余额。


    教师:学生通过来我这里刷卡上机,当然没有卡的需要先来我这里注册,最好在注


册过程中输入的信息越少越好。我也可以帮助学生充值,也可以退卡。也能够查看正在


上机的人数,如果学生离开的时候忘了退出自己的账号,我也能够帮他们退出。我也能


够修改学生信息。当然我也想看看所有教师的工作记录,跟月底的出勤率也有个依据。


    管理员:我是这个系统的最高权限者,我能够管理老师,比如注册,信息的修改


等,对于学生上机的花费情况,我希望能够做到每日一结,每月汇总,并能够帮我打印


出来。


    学校某领导:我的要求不高,希望这个系统能够方便机房的管理,减少教师的工作


情况,节省开支,并且对于系统财务方面的管理,我希望不要出差错。

 

   提取实体

从用户的需求中,我们注意到用户用来描述业务视图的名词或者用户反复提到的名词。

这些名词都可以成为备选类。


    因此从前面的分析中可以得出的概念类有:


    学生、值班教师、管理员、充值记录、上机记录、消费记录、日结账单、周结账

单、值班记录、基本数据设定

 

  获取实体类的属性

方法一:


从类的概念中找出类的一些基本的属性。


  例如:学生、教师、管理员三个类都有相同的部分属性:姓名、工号、性别、年龄。


因此我们发挥我们的想象力来进一步的抽象出一个People类。


再如上机记录,充值记录,消费记录类中可以抽象出一个Record的类来。


这样与其他几个类的关系就为聚合关系,这样表达起来更直观,也方便以后的修改和管

理。

 

方法二:


从问题分析和描述中找到的名词和术语。


 例如:从学生的描述中就可以得出:


  系别、专业、年级、班级等

 

获取实体类的方法

  获取实体类的方法可以通过查看用户描述的动词。(可以参看用例的事件流分析)


1.基本流

1.学生登录系统

2.系统进行验证

3.学生查看信息

2.备选流

  2.a 如果学生信息不正确

      1.给出提示,重新输入

      2.结束

  2.b  如果学生余额不足

      1.给出提示,及时充值

      2.结束

  3.a 系统进行验证

      1.如果不符合规范,给出提示

      2.结束操作,返回

 

 

通过以上分析得出:


  ·学生类的主要方法


       登录系统、退出系统、核对信息


  ·教师类的主要方法


        注册账号、充值、退卡、查看上机记录等


  ·管理员类的主要方法


        管理教师、设置参数、核对账单

     …………………..

 

 

分析类之间的联系


   找出所有的类后,就开始分析类与类之间联系与交互。类之间的关系也已经在上篇博

客中讲解过一下就不再详谈。

 

 

下面就是我的类图,请多多指教。

类图之我所见

其实在此有个疑问,关于学生是通过刷卡上机学习的,我们要不要在单独分开一个上机


卡的类来呢?还是直接把这个类归位学生的一个属性呢?这些疑问还有待于接下来的学


习,看到底哪一种设计方法对于后面的代码实现更简单些。

类图之我所见

上一篇:HDU 2047 阿牛的EOF牛肉串.


下一篇:UML-顺序图和协作图