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

合集下载
相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

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

作者: 李守宏发布时间: 2011-04-02 09:51

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

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

天一样.只是一个规定.你知道了这些就是一个象棋高手吗?

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

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

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

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

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

求的方法.如果你连个目标也没有.整天和别人说你要谈恋爱.别人会怎么想你?

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

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

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

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

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

我们最好是为每一个操作类都设计一个接口类.这样方便以后换数据库.建立好这些类以后.就要为这些类添加方法,方法对于每一个数据库是不同的.但是大体的方法用途还是基本一样的.都是增,删,改,查的一些方法.无非是变了一些参数和返回值.如图:

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

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

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

比如想添加一个用户:

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

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

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

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

如图:

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

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

四:界面层就是窗体类

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

备注:

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

2:DAL层不一定完全和数据库对应.这个就是我在上边提出的问题.在操作中难免要遇到一些全局使用的数据.我们把这些数据放到一个实体类中.把它虚拟出一个类.把数据设置成这个类的属性.然后操作类的属性.最好不要把它单独定义到模块中.这样就不太复合面向对象的精神. DAL 层为什么不把它直接分成增,删,改,查四个类

其实很多人开始的时候都是这样想的.把它设置成这四个类不是很好吗.简单.不用在那么多类中找来找去.最让人感觉不错的地方就是在画UML时序图的时候.很是简单.基本上所有的图都是一样.

首先说.这样的分类对于系统来说是可以实现的.只是每个类中有很多的方法.比如查找这个类.里面对于每一个表的查找都要出现几个方法.

但是这样做违反了一个很重要的软件设计原则:开闭原则

开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改当把DAL层设计成四个类的时候.比如我们要增加一张表, 或者一个功

能.我们只有去修改原来的类.这样显然违反了开闭原则.如果我们把每一张表都对应一个类.这样我们再增加一个表的时候.只需要增加一个类就可以了.

面向对象的核心就是封装.装起来以后就把它看作一个整体.不要轻易去改动它.只能来复用它.这样才是可复用的软件设计.

3:同层之间尽量不要相互调用.模块与模块直接也尽量不要交叉调用

我们分层的目的就是为了减少模块与模块之间的耦合.在层与层之间.尤其是bll层和dal层之间.一般是不相互调用的.也不去交叉调用.

这个就像是政府的部门.你公安部的人不能随便调用我财政部的人.你只要做好的你地任务就好了.但是如果一个部门需要另一个部门的功能怎么办?比如我公安部需要一个管理财政的?

很简单.你公安部也设立一个下属的财务部门就解决了.这样看起来比较重复.其实分层设计很多代码都是重复的.但是大量的重复换来了以后的方便.

这个就像是我们设计类一样.如果一个模块需要另一个模块的功能.比如我结账要查询,充值也要查询.你可以在bll中设立两个查询去解决.坚决不要调用bll的一个查询.

任何事情都有特殊.如果一个部门实在是解决不了怎么办?那么只能麻烦我们的老大.也就是顶层UI来.让他来调用另一个窗体.或者页面去解决.这个就可以交叉调用.

4:类图之间的关系.

相关文档
最新文档