UML从需求到实现(三)----类图.docx

UML从需求到实现（三）----类图作者:?李守宏?发布时间: 2011-04-02 09:51按照UML中图的出现顺序.当做完包图以后.我们下一步要做的当然是类图,类图也是UML中的三大核心图之一.看到很多文章在描述类图的时候.总是大部分在叙述类之间的关系:关联,依赖,继承,组合,聚合呀这些.很少有人说明类是怎么来的.没有了类,你拿什么来画类图.那些关系其实没有多大意义.就像是象棋的马走日,象飞天一样.只是一个规定.你知道了这些就是一个象棋高手吗?类图是UML中的一种静态图.他是体现面向对象编程的基础.类图就像是软件设计的细胞.是基本元素.没有了类图.也就没有了接下来的设计.但是类不可能是凭空产生的.类是我们凭借自己的经验和智慧去抽象,提取出来的.所以说,对于一个良好的系统.如何去提取出类来.才是最关键的.下面我介绍一下面向对象开发过程中.利用三层架构的方式.分析典型MIS系统的类图从提出类.到类图的生成的过程.一:根据用例确定数据库,确定表,创建实体类第一个也是最关键的一个.我们要做的第一步就是要根据用户对数据的要求,去确定数据库中的表.去设计数据库(如何去设计数据库中的表,这里不在叙述).因为我们在信息管理系统中.所有的操作可以说都是对数据的操作.你首先要确定的是数据.确定了数据,你才知道怎么操作(这个仅仅是我的个人体会).就像是你要谈恋爱.你首先要确定你要追求的目标.才能制定追求的方法.如果你连个目标也没有.整天和别人说你要谈恋爱.别人会怎么想你?然后根据设计好的数据库,一一对应的方式设计成实体类.实体类可以说就是数据库的映射.把数据库的每一个表影射成一个类,每一个字段设计成一个属性.这样保证你的操作是面向对象的.对于一条记录,你可以整体去操作它.如下图:PS:这里我要补充一点.很多人不理解实体类是干什么的.不知道该把它放在三层架构的那一层.其实实体类不属于三层的任何一层.其实它就是一个自定义的变量.你这么理解他就行了.就像是你的string,int型变量一样.你用它来存放数据就对了.不同地方就是它可以放多个不同类型的变量而已.二:将实体类对应成数据库操作类 (注意为什么不是增删改查类)创建完实体类以后.然后要创建对数据库的操作类.这个也是每一个数据表对应一个操作类即:DAL层的类.注意我为什么是一个数据库表对应一个操作类.但是不是一个一个操作类对应一个数据库表.这个原因在后面将讲到.我们最好是为每一个操作类都设计一个接口类.这样方便以后换数据库.建立好这些类以后.就要为这些类添加方法,方法对于每一个数据库是不同的.但是大体的方法用途还是基本一样的.都是增,删,改,查的一些方法.无非是变了一些参数和返回值.如图:三:根据用例封装业务逻辑.形成bll层类当实现完数据库的操作类以后,其实整个系统的基石就有了.下面就是研究系统的功能了.对于BLL层的类.其实就是根据用例.然后封装一下单个用例需要用到的数据库操作类.然后把他们的功能封装到一起.比如想添加一个用户:首先到用户类里查询是否已经添加.接着添加到用户信息表中信息然后添加到用户工作记录表信息.也就是说你这个用例要用到那些个表的操作.我都要封装到一起.为UI层提供统一的接口.如图:PS:再为BLL层设计类的时候.尽量符合单例模式.即一个类只完成一个功能.这样减少了类之间的耦合性.如何设计类请看我的另一篇文章:/lsh6688/archive/2010/12/02/6050463.aspx设计模式原则四:界面层就是窗体类至于界面层,好的界面无非是用一些好的控件等.让大家看起来舒服.在UML中,只要把界面对应的窗体(c/s)名称写出来就可以了.里面的方法我认为是不必要写的.你在做界面的时候就已经都做好了.备注:1:在DAL层可以考虑用抽象工+反射的方法来实例化类.这样再换数据库的时候就方便多了.如图:2:DAL层不一定完全和数据库对应.这个就是我在上边提出的问题.在操作中难免要遇到一些全局使用的数据.我们把这些数据放到一个实体类中.把它虚拟出一个类.把数据设置成这个类的属性.然后操作类的属性.最好不要把它单独定义到模块中.这样就不太复合面向对象的精神. DAL层为什么不把它直接分成增,删,改,查四个类其实很多人开始的时候都是这样想的.把它设置成这四个类不是很好吗.简单.不用在那么多类中找来找去.最让人感觉不错的地方就是在画UML时序图的时候.很是简单.基本上所有的图都是一样.首先说.这样的分类对于系统来说是可以实现的.只是每个类中有很多的方法.比如查找这个类.里面对于每一个表的查找都要出现几个方法.但是这样做违反了一个很重要的软件设计原则:开闭原则开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改?当把DAL层设计成四个类的时候.比如我们要增加一张表, 或者