UML中类图的理解
按照UML中图的出现顺序。当做完包图以后，我们下一步要做的当然是类图,类图也是UML中的三大核心图(用例图、包图、类图)之一。
类图是UML中的一种静态图，他是体现面向对象编程的基础，类图就像是软件设计的细胞，是基本元素，没有了类图，也就没有了接下来的设计，但是类不可能是凭空产生的，类是我们凭借自己的经验和智慧去抽象,提取出来的。
所以说对于一个良好的系统，如何去提取出类来才是最关键的。下面我介绍一下面向对象开发过程中，利用三层架构的方式。分析典型MIS系统的类图从提出类到类图的生成过程。
一、根据用例确定数据库、确定表、创建实体类
我们要做的第一步就是要根据用户对数据的要求,去确定数据库中的表，去设计数据库。因为我们在信息管理系统中，所有的操作可以说都是对数据的操作。你首先要确定的是数据，确定了数据,你才知道怎么操作。然后根据设计好的数据库,一一对应的方式设计成实体类，实体类可以说就是数据库的映射，把数据库的每一个表影射成一个类,每一个字段设计成一个属性，这样保证你的操作是面向对象的。对于一条记录,你可以整体去操作它。
很多人不理解实体类是干什么的，不知道该把它放在三层架构的那一层？其实实体类不属于三层的任何一层。其实它就是一个自定义的变量。就像是你的string、int型变量一样，你用它来存放数据就对了，不同地方就是它可以放多个不同类型的变量而已。
二、将实体类对应成数据库操作类 (注意为什么不是增删改查类)
创建完实体类以后，然后要创建对数据库的操作类。这个也是每一个数据表对应一个操作类，即DAL层的类。注意为什么是一个数据库表对应一个操作类，但是不是一个一个操作类对应一个数据库表。最好是为每一个操作类都设计一个接口类，这样方便以后换数据库。
建立好这些类以后，就要为这些类添加方法,方法对于每一个数据库是不同的，但是大体的方法用途还是基本一样的。都是增删改查的一些方法，无非是变了一些参数和返回值。
三、根据用例封装业务逻辑形成BLL层类
当实现完数据库的操作类以后,其实整个系统的基石就有了。下面就是研究系统的功能了。
对于BLL层的类，其实就是根据用例然后封装一下单个用例需要用到的数据库操作类，然后把他们的功能封装到一起。
比如想添加一个用户:
首先到用户类里查询是否已经添加。
接着添加到用户信息表中信息。
然后添加到用户工作记录表信息。
也就是说你这个用例要用到哪些个表的操作，我都要封装到一起，为UI层提供统一的接口。
为BLL层设计类的时候，尽量符合单例模式。即一个类只完成一个功能，这样减少了类之间的耦合性。
四、界面层就是窗体类
至于界面层,好的界面无非是用一些好的控件等，让大家看起来舒服。在UML中,只要把界面对应的窗体(.cs)名称写出来就可以了，里面的方法我认为是不必要写的，你在做界面的时候就已经都做好了。.
备注:
1、在DAL层可以考虑用抽象+反射的方法来实例化类，这样再换数据库的时候就方便多了。
2、DAL层不一定完全和数据库对应。这个就是我在上边提出的问题。在操作中难免要遇到一些全局使用的数据，我们把这些数据放到一个实体类中，把它虚拟出一个类，把数据设置成这个类的属性，然后操作类的属性，最好不要把它单独定义到模块中，这样就不太复合面向对象的精神。
3、同层之间尽量不要相互调用
虽然类图中允许同层之间的相互调用，但是个人认为同层直接尽量避免相互调用，已较少之间的耦合(关于这篇我将在后面的文章接着讲述为什么是这样)。
4、类图之间的关系
(一)、DAL层为什么不把它直接分成增删改查四个类
其实很多人开始的时候都是这样想的，把它设置成这四个类不是很好吗。简单，不用在那么多类中找来找去，最让人感觉不错的地方就是在画UML时序图的时候。很是简单，基本上所有的图都是一样。
首先说，这样的分类对于系统来说是可以实现的。只是每个类中有很多的方法，比如查找这个类，里面对于每一个表的查找都要出现几个方法，但是这样做违反了一个很重要的软件设计原则:开闭原则。开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改。
当把DAL层设计成四个类的时候，比如我们要增加一张表, 或者一个功能，我们只有去修改原来的类，这样显然违反了开闭原则，如果我们把每一张表都对应一个类，这样我们再增加一个表的时候，只需要增加一个类就可以了。面向对象的核心就是封装，装起来以后就把它看作一个整体，不要轻易去改动它，只能来复用它，这样才是可复用的软件设计。
(二)、同层之间尽量不要相互调用，模块与模块直接也尽量不要交叉调用
我们分层的目的就是为了减少模块与模块之间的耦合。在层与层之间，尤其是BLL层和DAL层之间，一般是不相互调用的，也不去交叉调用。这个就像是政府部门，你公安部的人不能随便调用我财政部的人，你只要做好的你地任务就好了，但是如果一个部门需要另一个部门的功能怎么办?比如我公安部需要一个管理财政的?很简单，你公安部也设立一个下属的财务部门就解决了，这样看起来比较重复，其实分层设计很多代码都是重复的，但是大量的重复换来了以后的方便。这个就像是我们设计类一样，如果一个模块需要另一个模块的功能，比如我结账要查询,充值也要查询，你可以在bll中设立两个查询去解决，坚决不要调用bll的一个查询。任何事情都有特殊，如果一个部门实在是解决不了怎么办?那么只能麻烦我们的老大，也就是顶层UI来，让他来调用另一个窗体，或者页面去解决，这个就可以交叉调用。
类图是UML中的一种静态图，他是体现面向对象编程的基础，类图就像是软件设计的细胞，是基本元素，没有了类图，也就没有了接下来的设计，但是类不可能是凭空产生的，类是我们凭借自己的经验和智慧去抽象,提取出来的。
所以说对于一个良好的系统，如何去提取出类来才是最关键的。下面我介绍一下面向对象开发过程中，利用三层架构的方式。分析典型MIS系统的类图从提出类到类图的生成过程。
一、根据用例确定数据库、确定表、创建实体类
我们要做的第一步就是要根据用户对数据的要求,去确定数据库中的表，去设计数据库。因为我们在信息管理系统中，所有的操作可以说都是对数据的操作。你首先要确定的是数据，确定了数据,你才知道怎么操作。然后根据设计好的数据库,一一对应的方式设计成实体类，实体类可以说就是数据库的映射，把数据库的每一个表影射成一个类,每一个字段设计成一个属性，这样保证你的操作是面向对象的。对于一条记录,你可以整体去操作它。
很多人不理解实体类是干什么的，不知道该把它放在三层架构的那一层？其实实体类不属于三层的任何一层。其实它就是一个自定义的变量。就像是你的string、int型变量一样，你用它来存放数据就对了，不同地方就是它可以放多个不同类型的变量而已。
二、将实体类对应成数据库操作类 (注意为什么不是增删改查类)
创建完实体类以后，然后要创建对数据库的操作类。这个也是每一个数据表对应一个操作类，即DAL层的类。注意为什么是一个数据库表对应一个操作类，但是不是一个一个操作类对应一个数据库表。最好是为每一个操作类都设计一个接口类，这样方便以后换数据库。
建立好这些类以后，就要为这些类添加方法,方法对于每一个数据库是不同的，但是大体的方法用途还是基本一样的。都是增删改查的一些方法，无非是变了一些参数和返回值。
三、根据用例封装业务逻辑形成BLL层类
当实现完数据库的操作类以后,其实整个系统的基石就有了。下面就是研究系统的功能了。
对于BLL层的类，其实就是根据用例然后封装一下单个用例需要用到的数据库操作类，然后把他们的功能封装到一起。
比如想添加一个用户:
首先到用户类里查询是否已经添加。
接着添加到用户信息表中信息。
然后添加到用户工作记录表信息。
也就是说你这个用例要用到哪些个表的操作，我都要封装到一起，为UI层提供统一的接口。
为BLL层设计类的时候，尽量符合单例模式。即一个类只完成一个功能，这样减少了类之间的耦合性。
四、界面层就是窗体类
至于界面层,好的界面无非是用一些好的控件等，让大家看起来舒服。在UML中,只要把界面对应的窗体(.cs)名称写出来就可以了，里面的方法我认为是不必要写的，你在做界面的时候就已经都做好了。.
备注:
1、在DAL层可以考虑用抽象+反射的方法来实例化类，这样再换数据库的时候就方便多了。
2、DAL层不一定完全和数据库对应。这个就是我在上边提出的问题。在操作中难免要遇到一些全局使用的数据，我们把这些数据放到一个实体类中，把它虚拟出一个类，把数据设置成这个类的属性，然后操作类的属性，最好不要把它单独定义到模块中，这样就不太复合面向对象的精神。
3、同层之间尽量不要相互调用
虽然类图中允许同层之间的相互调用，但是个人认为同层直接尽量避免相互调用，已较少之间的耦合(关于这篇我将在后面的文章接着讲述为什么是这样)。
4、类图之间的关系
(一)、DAL层为什么不把它直接分成增删改查四个类
其实很多人开始的时候都是这样想的，把它设置成这四个类不是很好吗。简单，不用在那么多类中找来找去，最让人感觉不错的地方就是在画UML时序图的时候。很是简单，基本上所有的图都是一样。
首先说，这样的分类对于系统来说是可以实现的。只是每个类中有很多的方法，比如查找这个类，里面对于每一个表的查找都要出现几个方法，但是这样做违反了一个很重要的软件设计原则:开闭原则。开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改。
当把DAL层设计成四个类的时候，比如我们要增加一张表, 或者一个功能，我们只有去修改原来的类，这样显然违反了开闭原则，如果我们把每一张表都对应一个类，这样我们再增加一个表的时候，只需要增加一个类就可以了。面向对象的核心就是封装，装起来以后就把它看作一个整体，不要轻易去改动它，只能来复用它，这样才是可复用的软件设计。
(二)、同层之间尽量不要相互调用，模块与模块直接也尽量不要交叉调用
我们分层的目的就是为了减少模块与模块之间的耦合。在层与层之间，尤其是BLL层和DAL层之间，一般是不相互调用的，也不去交叉调用。这个就像是政府部门，你公安部的人不能随便调用我财政部的人，你只要做好的你地任务就好了，但是如果一个部门需要另一个部门的功能怎么办?比如我公安部需要一个管理财政的?很简单，你公安部也设立一个下属的财务部门就解决了，这样看起来比较重复，其实分层设计很多代码都是重复的，但是大量的重复换来了以后的方便。这个就像是我们设计类一样，如果一个模块需要另一个模块的功能，比如我结账要查询,充值也要查询，你可以在bll中设立两个查询去解决，坚决不要调用bll的一个查询。任何事情都有特殊，如果一个部门实在是解决不了怎么办?那么只能麻烦我们的老大，也就是顶层UI来，让他来调用另一个窗体，或者页面去解决，这个就可以交叉调用。