UML从需求到实现---类图(1)

上次写到了UML的包图,用例等:接上:UML从需求到实现---包图

按照UML中图的出现顺序.当做完包图以后.我们下一步要做的当然是类图,类图也是UML中的三大核心图之一.

看到很多文章在描述类图的时候.总是大部分在叙述类之间的关系:关联,依赖,继承,组合,聚合呀这些.很少有人说明类是怎么来的.没有了类,你拿什么来画类图.那些关系其实没有多大意义.就像是象棋的马走日,象飞天一样.只是一个规定.你知道了这些就是一个象棋高手吗?

类图是UML中的一种静态图.他是体现面向对象编程的基础.类图就像是软件设计的细胞.是基本元素.没有了类图.也就没有了接下来的设计.但是类不可能是凭空产生的.类是我们凭借自己的经验和智慧去抽象,提取出来的.

所以说,对于一个良好的系统.如何去提取出类来.才是最关键的.下面我介绍一下面向对象开发过程中.利用三层架构的方式.分析典型MIS系统的类图从提出类.到类图的生成的过程.

一:根据用例确定数据库,确定表,创建实体类

第一个也是最关键的一个.我们要做的第一步就是要根据用户对数据的要求,去确定数据库中的表.去设计数据库(如何去设计数据库中的表,这里不在叙述).

因为我们在信息管理系统中.所有的操作可以说都是对数据的操作.你首先要确定的是数据.确定了数据,你才知道怎么操作(这个仅仅是我的个人体会).就像是你要谈恋爱.你首先要确定你要追求的目标.才能制定追求的方法.如果你连个目标也没有.整天和别人说你要谈恋爱.别人会怎么想你?

然后根据设计好的数据库,一一对应的方式设计成实体类.实体类可以说就是数据库的映射.把数据库的每一个表影射成一个类,每一个字段设计成一个属性.这样保证你的操作是面向对象的.对于一条记录,你可以整体去操作它.

 

PS:这里我要补充一点.很多人不理解实体类是干什么的.不知道该把它放在三层架构的那一层.其实实体类不属于三层的任何一层.其实它就是一个自定义的变量.你这么理解他就行了.

就像是你的string,int型变量一样.你用它来存放数据就对了.不同地方就是它可以放多个不同类型的变量而已.

二:将实体类对应成数据库操作类 (注意为什么不是增删改查类)

创建完实体类以后.然后要创建对数据库的操作类.这个也是每一个数据表对应一个操作类即:DAL层的类.注意我为什么是一个数据库表对应一个操作类.但是不是一个一个操作类对应一个数据库表.这个原因在后面将讲到.

我们最好是为每一个操作类都设计一个接口类.这样方便以后换数据库.

建立好这些类以后.就要为这些类添加方法,方法对于每一个数据库是不同的.但是大体的方法用途还是基本一样的.都是增,删,改,查的一些方法.无非是变了一些参数和返回值.

 

 

三:根据用例封装业务逻辑.形成bll层类

当实现完数据库的操作类以后,其实整个系统的基石就有了.下面就是研究系统的功能了.

对于BLL层的类.其实就是根据用例.然后封装一下单个用例需要用到的数据库操作类.然后把他们的功能封装到一起.

比如想添加一个用户:

首先到用户类里查询是否已经添加.

接着添加到用户信息表中信息

然后添加到用户工作记录表信息.

也就是说你这个用例要用到那些个表的操作.我都要封装到一起.为UI层提供统一的接口.

 

 

PS:再为BLL层设计类的时候.尽量符合单例模式.即一个类只完成一个功能.这样减少了类之间的耦合性.

如何设计类请看我的另一篇文章:设计模式原则

四:界面层就是窗体类

至于界面层,好的界面无非是用一些好的控件等.让大家看起来舒服.在UML中,只要把界面对应的窗体(c/s)名称写出来就可以了.里面的方法我认为是不必要写的.你在做界面的时候就已经都做好了.

备注:

1:在DAL层可以考虑用抽象工+反射的方法来实例化类.这样再换数据库的时候就方便多了.

 

2:DAL层不一定完全和数据库对应.这个就是我在上边提出的问题.在操作中难免要遇到一些全局使用的数据.我们把这些数据放到一个实体类中.把它虚拟出一个类.把数据设置成这个类的属性.然后操作类的属性.

最好不要把它单独定义到模块中.这样就不太复合面向对象的精神.

3:同层之间尽量不要相互调用

虽然类图中允许同层之间的相互调用.但是个人认为同层直接尽量避免相互调用.已较少之间的耦合(关于这篇我将在后面的文章接着讲述为什么是这样).

4:类图之间的关系.

关于类之间的关系.这里就不在叙述,请看我的其他文章.UML文章集合