机房重构系统的UML图总结

概述

         终于把机房收费系统的重构版UML图画完了,在这个过程中包括技术和思想方面,自己体会到很多。

 

技术

         对于3层,我们其实可以把它看成是5层,这个层数是根据具体的开发项目时的运用而出来的。我们知道,一个解决方案可以由多个工程组成,而一个工程就相当于一个组件,在开发项目的时候,我们建立5个工程,分别为U层,B层,D层,Model层和Common层,这样每个小组可以同时开发不同的工程,最后统一组装在一起就行了。

         Model内存放的类主要是作为参数或属性来用的,这样层与层之间的传递由单一的数据类型变成对象的传递,这样对于日后的修改等方面非常的有好处,因为他们的模板只有一个,而且是你可以控制的Model里面的类内只有属性,没有方法,一个类里的属性主要是数据库中表里记录类型的集合,当然,有不是和数据库中表的记录一模一样,视情况而定,这时Model里的类名就需要好好的定义了。

         U层里面主要是界面类,美化界面,然后就是利用D层类里的方法,完成某一功能。

         D层类里面的方法就是和数据库直接打交道的,一般一个表就会对应一个D层的类,这种情况一次只能和一个表进行交流,如果需要一次和多个表打交道,可以在D层建一个类,这个类用来执行存储过程,这样就可以一次返回多个表里的字段了。

         Common层是用来存放D层需要的字符串,为常量,该字符串是单独的一条SQL语句,或者是存储过程,或者是表名,或者是连接数据库的字符串,有了Common层后,D层就见不了SQL语句或者存储过程了,其实这个的功能和Model层有相同的功能,就是便于数据库结构变化时容易修改程序,因为只要修改一次Common层的SQL语句就行了,如果不用Common层,并且相同的SQL语句又用的很多时,修改时就需要每一条都要修改了,那是容易出错。

         B层就是逻辑的组合D层类中的方法,使其完成某一功能,可以说一个具体的用例就需要一个B层的类或方法,当然,有时B层也可以不需要D层。

    时序图是对用例图中类和类之间方法调用顺序的说明。

 

思想

        刚开始画UML图的时候,很困难,脑子里一直想,应该有哪些类,类里面应该都有什么方法,这个想对我来说是混乱的,因为当我想了一些类的时候,并且还没有想完所有的类,我就开始想那些想到的类里应该有什么方法,然后这两条线在我脑子里就互相的绕,使我最后那个都没有想通,并且搞得自己心情很压抑。

    郁闷了一段时间后,自己就开始慢慢的写了,先写出自己脑子里的那些类和方法,然后,通过时序图再慢慢的找类和方法,这个过程使我对自己的类和方法不断的修改和完善才使我完成了该学习阶段。这个阶段完成后,回想整个过程,上述经历的反思使我受益很深。

    如果你想问题时有很多个头绪,但是没有一条主线的话,我建议你把所有的头绪写下来,因为你的头绪可能是不同角度、不同层次之间的关系,一会儿想这个,一会儿想那个,想着这个的时候,惦记着那个,想着那个的时候,放不下这个,这样的话,它们就会越绕越紧,越绕越复杂,然后你就想不通了,然后,你就再也不愿意想他们了。这个想对于我们来说是不自觉的,我们一下子很难避免它们,所以,我们遇到这种问题的时候,还是写下来吧,写下来再看看,写下来再思考思考。

 

总结

        机房收费系统个人重构版的UML图虽然画完了,但是,画的不怎么好,后续会再修改。

你可能感兴趣的:(UML,三层,写下来)