重构机房收费系统之UML图

 

写完文档大概有半个多月的时间了，然而我的UML图还没有完成，虽然之前也画过图，但是这次有点儿无从下手的感觉。在画图过程中遇到各种让我无法再画下去的问题：

由于这是学三层后的第一次运用，总感觉画图不比代码，总觉得代码才是最真实的，画图就有种虚无缥缈的感觉。开始是从用例图着手的，这样困难就来了：

步骤一：

用例图主要是将系统的整个功能进行管理，然而在画图的时候，却不知道我是该从功能模块来划分，还是从角色的角度进行划分，若是从功能模块来分的话，那样相似的功能就会一目了然，但却是角色的权限就无从体现；若是从角色来划分那就感觉系统的功能看上去特别复杂，但是实际上功能基本都是增删改查。。。通过权衡最终还是选择了之前的方式，从角色来分，下面是我的用例图，还有很多不足的地方：

 

步骤二：

用例图完成之后，进行的是包图，其实如果说只是简单地按照三层来画包图也没有什么难度，但是当时我想的是加上设计模式，觉得如果第一遍不加模式再回来加会有些困难，虽然系统很小，但是毕竟学习设计模式就是为了运用，由于系统设计到数据库问题，最开始想到的就是抽象工厂模式，这样可以方便数据库的修改；之前也听过很多人用到外观模式，所以就加上了，但是抽象类的时候觉得似乎在外观层里不知道该如何使用。。所以就暂时放弃了外观。。。。对于数据库方面D层分出了一个SqlHelper层，这样看上去是不错，但是实际的操作还是有些困难，暂时先把不完整的包图放上来，欢迎指正：

 

 

步骤三：

包图完成之后开始的是类图，把类抽象出来的过程其实还是挺艰难的，所以就从最简单的包开始，第一是U层，因为U层只涉及界面问题，所以将画好的界面化成类就构成了U层

 

当然只是界面表面上具有的方法和变量，在实际需要的方法还需要在时序图时进行完善；

完成U层，我觉得最简单的就是Entity实体层，因为实体是跟表关联的，所以只要设计好数据库，完成实体层的类是没有什么问题的，但是总觉得数据库设计的有问题，但是又不知道该如何改，利用以前敲三层的实例生成的实体层的类图，发现所谓类的属性，也是一种方法，供其它层调用。所以就这样了：

由于使用抽象工厂模式，D层用来实现接口IDAL,并由工厂来创建相应的类，所以工厂类大概是：

自我感觉B层是最难实现的，因为总感觉如果没有代码，不知道系统需要什么业务逻辑，自然也不知道该抽象出怎样的类才算是合适的粒度，但是我觉得如果使系统有足够的可扩展性，按每个功能来抽象是不切实际的，因为若是这样当需要添加功能或者修改功能的时候，整个B层都要做出调整，这样三层就没有意义了，所以考虑了根据数据库来抽象类，再加上一些跟数据库无关的算法和调用其他程序，就构成了B层：

B层有用到策略模式，因为考虑结账的时候可能根据不同的情况做出不同的调整，其他的设计模式暂时还没有想到。。。

 

大概有半个月了都一直在画图，只进行的这个地步了。。感觉有点儿慢。。。不过先这样吧。。在整个画图的过程中感觉对自己还是挺有考验的，从而更加了解系统的整个流程，使自己的思路也更加清晰了，也加深了自己对UML和三层的理解。。。继续出发开始时序图！