正确认识使用UML类图前言在OOA与OOD大行其道的今天，UML在系统分析与设计中得到了广泛的采用。而在UML的9种图中，UML类图是最重要也是使用最普遍的图之一。但是，在与一些朋友，特别是初学者的聊天当中，我发现很多朋友对UML类图的作用及使用方法存在一定的误解和困惑。于是我写下这篇文章，希望本文能在一定程度上帮助这些朋友更好的认识和使用UML类图。当然，由于我对UML的认识并不很深刻，所以在文章中有错误和疏漏之处，恳请大家批评指正。AvsD要想正确认识与使用UML类图，我们首先要正确认识两个概念——“A”和“D”。A是Analyse的缩写，即我们所说的“分析”；而D是Design的缩写，即“设计”。一般来说，一个系统在编码前，都要经过分析与设计两个步骤。而对这两个概念认识的模糊不清，正是导致很多朋友无法正确使用UML类图的原因。分析，我对其的解释是：根据用户的需求，做出一系列与业务领域相关而和计算机技术无关的整理与识别。很多朋友有个错误的认识，认为软件开发工作一定要由懂计算机的人完成，不懂计算机的人怎么能进行软件开发呢？当然，对于设计和编码等工作，当然是这样，但是唯有“分析”这一工作，可以由完全不懂计算机的人来进行，甚至从某种程度上说，不懂计算机的人更适合做软件分析师的工作。因为想要把分析做好，一定要仅与业务相关，而抛开具体技术。一个满脑子计算机技术的程序员去做分析时，很容易想到编码、实现、平台、数据库设计等具体细节，这种思维形式恰恰成为做好分析的最大障碍。此为误解一：只有懂计算机技术的人才能做系统分析师。我现在所在的研究所（北京航空航天大学计算机学院软件工程研究所）曾经接过一个日本项目，当时日方那边派来一个系统分析师对计算机就完全是外行，而是一个领域专家，但是他很好的完成了系统分析的工作。另外一个误解就是UML图，特别是UML类图，就是给开发人员用的。很多人觉得UML是计算机业内专业语言，不懂计算机的怎么能用它呢？用了做什么呢？但是很多不懂计算机的系统分析师在进行分析工作时，也在使用UML图，而UML类图就是其中一种。一般情况下，分析师在进行分析时，确实会绘制一套UML类图。但是，它所画的UML类图不管是从视角还是作用，与设计师所做的UML类图是不同的，具体将在下面介绍。此为误解二：只有计算机人士才使用UML图。分析说完了，下面说设计。与分析不同，我对设计的解释是：根据分析材料与技术平台，确定软件系统的架构结构、编码方式及一切与具体技术有关的宏观问题。这里可以看到，设计与分析不同，它必须由计算机方面的人来完成，因为它和具体技术是息息相关的。而且，设计师在进行设计时，也会绘制一套UML类图。到这里，我们明确了，原来软件在分析与设计两个阶段各自会绘制一套UML类图，而且是由分析师和设计师两个不同的角色绘制的。那么这两套UML类图有什么异同呢？下面将解释这个问题。
领域UML类图vs实现UML类图上文提到，在软件分析与设计过程中，会由两种角色产生两套UML类图。一般情况下，分析师绘制的UML类图叫做“领域UML类图”，而设计师绘制的UML类图叫做“实现UML类图”。这里要声明，这两个名词是我的习惯性叫法，并不是大家都认同的通用叫法。下面，我对这两种UML类图给出我的定义：领域UML类图：产生于分析阶段，由系统分析师绘制，主要作用是描述业务实体的静态结构，包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。虽然这个UML类图也叫“UML类图”，但是说实话，它和编程中的“类”实在是没啥关系，因为最后的系统中可能根本没有类和它们对应，而且很多最后系统中的类如控制类和界面类这套UML类图中也没有。也就是说这套图和具体技术无关，也不是画给程序员看的，它只是表达业务领域中的一个静态结构。下面给个例子：
这是一个选课系统的简单领域分析UML类图。可以看到，主要实体有教师、学生、课程和开课安排。每个实体标注了其在业务上具有的属性和方法。而且图中还标明了实体间的关系。但是，最终系统中可能没有一个学生类和其对应。因为最终系统中有哪些类、各个类有什么属性、方法依赖于所选择的平台和架构。例如，如果使用了Struts2，则会存在很多Action类，而使用了ASP.NETMVC，则会有很多Controller类等，所以，领域UML类图只于业务有关，和具体实现及编码等计算机技术无关。实现UML类图：实现UML类图：产生于设计阶段，由系统设计师绘制，其作用是描述系统的架构结构、指导程序员编码。它包括系统中所有有必要指明的实体类、控制类、界面类及与具体平台有关的所有技术性信息。就像上面的领域UML类图，如果你把它交给程序员编码，我想程序员会疯掉，因为它没有提供任何编码的依据。假如我们使用的是.NET平台分层架构，并使用ASP.NETMVC，则设计师应该在实现UML类图中绘制出所有的实体类、数据访问类、业务逻辑类和界面类，界面类又分为视图类、控制器类等等，还要表示出IoC和Aop等信息，并明确指出各个类的属性、方法，不能有遗漏，因为最终程序员实现程序的依据就是实现UML类图。总结最后，我们总结一下本文的要点：1.软件分析与设计是编码前的两个阶段，其中分析仅与业务有关，而与技术无关。设计以分析为基础，主要与具体技术有关。2.分析阶段由分析师绘制领域UML类图，设计阶段由设计师绘制实现UML类图。3.领域UML类图表示系统的静态领域结构，其中的类不与最终程序中的类对应；设计UML类图表示系统的技术架构，是程序员的编码依据，其中的类与系统中的类对应。4.领域UML类图中类的属性与操作仅关注与业务相关的部分，实现UML类图中的属性与操作要包括最终需要实现的全部方法与操作。
领域UML类图vs实现UML类图上文提到，在软件分析与设计过程中，会由两种角色产生两套UML类图。一般情况下，分析师绘制的UML类图叫做“领域UML类图”，而设计师绘制的UML类图叫做“实现UML类图”。这里要声明，这两个名词是我的习惯性叫法，并不是大家都认同的通用叫法。下面，我对这两种UML类图给出我的定义：领域UML类图：产生于分析阶段，由系统分析师绘制，主要作用是描述业务实体的静态结构，包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。虽然这个UML类图也叫“UML类图”，但是说实话，它和编程中的“类”实在是没啥关系，因为最后的系统中可能根本没有类和它们对应，而且很多最后系统中的类如控制类和界面类这套UML类图中也没有。也就是说这套图和具体技术无关，也不是画给程序员看的，它只是表达业务领域中的一个静态结构。下面给个例子：
这是一个选课系统的简单领域分析UML类图。可以看到，主要实体有教师、学生、课程和开课安排。每个实体标注了其在业务上具有的属性和方法。而且图中还标明了实体间的关系。但是，最终系统中可能没有一个学生类和其对应。因为最终系统中有哪些类、各个类有什么属性、方法依赖于所选择的平台和架构。例如，如果使用了Struts2，则会存在很多Action类，而使用了ASP.NETMVC，则会有很多Controller类等，所以，领域UML类图只于业务有关，和具体实现及编码等计算机技术无关。实现UML类图：实现UML类图：产生于设计阶段，由系统设计师绘制，其作用是描述系统的架构结构、指导程序员编码。它包括系统中所有有必要指明的实体类、控制类、界面类及与具体平台有关的所有技术性信息。就像上面的领域UML类图，如果你把它交给程序员编码，我想程序员会疯掉，因为它没有提供任何编码的依据。假如我们使用的是.NET平台分层架构，并使用ASP.NETMVC，则设计师应该在实现UML类图中绘制出所有的实体类、数据访问类、业务逻辑类和界面类，界面类又分为视图类、控制器类等等，还要表示出IoC和Aop等信息，并明确指出各个类的属性、方法，不能有遗漏，因为最终程序员实现程序的依据就是实现UML类图。总结最后，我们总结一下本文的要点：1.软件分析与设计是编码前的两个阶段，其中分析仅与业务有关，而与技术无关。设计以分析为基础，主要与具体技术有关。2.分析阶段由分析师绘制领域UML类图，设计阶段由设计师绘制实现UML类图。3.领域UML类图表示系统的静态领域结构，其中的类不与最终程序中的类对应；设计UML类图表示系统的技术架构，是程序员的编码依据，其中的类与系统中的类对应。4.领域UML类图中类的属性与操作仅关注与业务相关的部分，实现UML类图中的属性与操作要包括最终需要实现的全部方法与操作。
2、协作图可以分析业务中各个对象之间的交互、职责的分配，分析完了可以让你的思路更加清晰明了，对于复杂的业务很管用；
3、类图是在设计各个实体以及相关控制类，根据协作图的分析以及UI原型设计你的实体应该具有哪些属性，完成当前业务需要提供哪些方法的支持，同时表明各个类的继承、依赖、引用关系，看类图比看API直观得多，具有把控整体‘一目了然之功效。而且类图还可以反向生成源代码哦
4、有用例图配合在需求文档上面那就更完美了，不过小公司一般就是只有需求文档的，不会在相关模块贴上用例图，大公司的详细文档应该有。文字描述需要啰嗦几句，有用例场景图可以直观的反应什么角色的人来处理什么样的业务、具备哪些操作权限。个人感觉跟viso里面画的流程图片段有些相似
养成UML建模的开发习惯还是比较好的，对于对面向对象编程、领域建模、把控整体框架会有更深的理解跟体会，当然啦，要是小系统也用UML建模 我觉得没必要，有点杀鸡用牛刀的感觉