与机房收费系统图的初步情结

 从六月一号开始着手画的UML图，过去了半个月，这半个月当中，对图进行了四次修改！下面说说这半个月来我与UML图的情结吧：

第一阶段： 6月1号—6月5号 

1.第一步用例图

  用例图主要是系统的功能模型图，有第一次机房收费系统的画图经验，所以这个用例图是最简单不过了，并不纠结！

2.第二步 包图

    主要是根据经典的三层架构来画，主要分为实体层，界面层，业务逻辑层和数据访问层。前面已经学习了三层的理论和实践，所以经典三层架构并不感觉到困难。

    界面层：毫无疑问就是用户能直观看到的窗体；下面是业务逻辑层，这个就难办多了，这时候稍微有点困惑了，这个业务逻辑到底应该根据什么来划分比较好呢？分析了一下系统，发现整个系统都是围绕着增、删、改、查这四个功能来进行实体层与数据库进行一一对应；从实体层可以得出数据访问层，数据访问层：主要是进行对数据库的操作，也就是对表进行增、删、改、查的操作。

3.第三步 时序图

   再画时序图的时候，想起了师父说过要加设计模式，最基本的要了解抽象工程模式+反射+配置文件的用法。所以进行了下一阶段。所以先把设计模式添加到包图中，再进行时序图！

第二阶段：6月6号—6月15号 

      经典的三层架构完成之后，就想往上面加设计模式！最基本的就是抽象工厂模式+反射+配置文件了。

       这个阶段挺纠结的，主要是对抽象工厂模式+反射+配置文件很不理解。学设计模式的时候，反射那一块就看不懂！上次看不懂还可以忽略它，因为我们并没有用到它，但是这次不行了，所以抱着一定要弄懂的心情去学习！先是回头看大话设计模式关于抽象工厂模式那点知识，然后是上网找资料和找一个抽象工程模式模式在三层中的应用的一个实例来学习。最后是拿机房收费系统的登录窗体进行开刀。这次对抽象工厂模式+反射+配置文件的用法总算是有了进一步的认识。这也验证了那一句话：学习是一个过程。刚开始的时候，我们对这一块并不懂，但是当你用到的时候，你再回过头来学习，就相对于来说容易多了。就拿这次的模式来说，我们之前学习设计模式的时候，我们要学的是23个模式，现在想起来脑子还是一片混浊。但是，我们现在由于系统的需要，我们需要知道抽象工厂模式，这时候我们就有目的的去学习具体的某一个模式，大大的减少新知识的量。所以也就轻松多了，而如果我们一开始，就非要把这23个模式一个个的都弄懂的话，那不累死才怪呢？

       之后就是重新在第一阶段的基础上对包图进行修改，这次加上了抽象工厂模式。

   紧接着是画时序图，这里停留了两天都没进展，不知道该怎么办？感觉应该是自己前面画的包图（B层)有出问题了吧。所以找导师检查了自己前面的图：

     经过导师检查，自己再画图的时候暴露的问题和需要完善的：

      1.用例图：应该画在Use Case View下面，而我是把所有的图都堆积到一起了

      2.时序图：

           a.因为时序图主要是根据功能来进行的，所以一个时序图应该对应一个用例，而且应该画在用例图下面。

           b. 时序图调用的方法没有参数与返回值

           c.工厂的主要作用是为了创建对象，并且通过反射实例化出接口，所以工厂层与数据访问层之间不应该存在调用关系，而应该是由工厂创建好对象之后，返回给业务逻辑层，业务逻辑层再通过方法进行调用。

      3.包图：

          a.B层的划分应该是按照业务逻辑来进行划分，B层的主要作用就是为了解耦，即隔离对数据库的直接操作，而我根据增、删、改、查功能来进行划分，很明显的又跟数据库挂钩上 了！

          b.D层命名参考规范，方法考虑不周全，需要有参数和返回值。

          c.建议使用策略模式和单例模式。

     总而言之，在学习的过程当中，应该是让自己保持轻松，愉快！

     始终相信学习本身就是一件快乐的事情就可以了！