公司比较清闲，平时大部分时间都在学习，哦，不是大部分，是整天都在自己学习，最近一直对建模语言感兴趣，所以就自己各方找资料。开始是看视频，看了一个小时，感觉效果不大，然后开始反思效果不大的原因。这是我自己的一点建议。对于一个自己不知道的技术，如果能看书或找资料能解决的就不要看视频，视频是最后的手段，虽然视频能让自己很快的理解，但那毕竟是别人的想法，是被动的灌输，也许看完你就会忘记了。而自己主动的去网上找资料，这样是主动的获取知识，而且文字的东西可以反复的看，不理解的地方可以停下来深思一番。其中好处不言而喻，而且还有最最重要的一点，还可以听着歌，好了，闲话不说，说正题。
UML嘛，楼主在学习Java期间，就听过了，那个时候，楼主非常不解，UML那是什么，记得当初问了一个本专业的，他告诉我说，建房子知道怎么回事吗？UML就相当于图纸，然后楼主深感这个东西是个好家伙，等有时间一定要学。然后楼主有问了一句，这个东西你会吗？然后那个在我眼中是大神的家伙就呵呵。。。。你懂的。
UML，Unified Modeling Language (UML)又称统一建模语言或标准建模语言。架构师必备神器，像我一样要想成为架构师的菜鸟们必须努力了。我第一个接触的UML建模工具是powerdesigner，当初楼主非常兴奋的安装好，然后在心里兴奋的说，楼主将迈出架构师的第一步啦........然后打开软件，楼主傻眼了，这都是什么玩意，全是英文。楼主那个时候在网上找了一本powerdesigner书籍，才了解到，哦，原来这是个数据库建模工具，然后楼主开始了点击file然后new 了第一个model,然后楼主又点击了上面唯一个认识的图形PhysicalDataModel，这个都知道了吧，物理数据模型。楼主当初可不知道这个是什么........
好了，到此，你必须了解几个新词了（大神跳过）。
1、概念数据模型（Conceptual Data Model）：简称 概念模型 ，主要用来描述世界的概念化结构，它使数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的数据管理系统（Database Management System，简称DBMS）无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。
2、逻辑数据模型（Logical Data Model）:简称数据模型，这是用户从数据库所看到的模型，是具体的DBMS所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型 (Hierarchical Data Model)等等。 此模型既要面向用户，又要面向系统，主要用于 数据库管理系统 （DBMS）的实现。
3、物理数据模型（Physical Data Model）:简称 物理模型 ，是面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有起对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作又系统自动完成，而设计者只设计索引、聚集等特殊结构。
这是我在百度上找的他们的关系。看懂了吗？其实我们可以简化理解： 概念数据模型，是你心中所想的，还没有实现，而物理数据模型是进行数据库体系结构设计，真正实现数据在数据库中的存放，而要把心中的设计变成能存放在数据库中的对象或字段，则必须把概念数据模型上升为逻辑数据模型，而物理数据模型是在逻辑数据模型的基础上实现的。
等等，这怎么说到数据库建模了，不是说UML建模吗？哎，不好意思，楼主扯远了。
powerdesigner开始最主要的用途就是数据库建模，但是随着版本的提高，它在UML建模上也渐渐有了一席之地。
那么，UML建模到底怎么理解呢？这是个大问题，开始楼主就是因为概念不清，导致了走了很多弯路，楼主在学习的疑问中慢慢找到了答案。
要想正确理解UML,那么首先先区分什么是 分析（Analyse）和设计（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类图中的属性与操作要包括最终需要实现的全部方法与操作。（楼主不会厚颜无耻，这是在另一个博客上看的http://developer.51cto.com/art/201007/210700_all.htm）
那么既然UML用在不同的开发阶段有不同的类型？那么，作为开发人员，我们应该掌握那个呢？答案：都掌握。
到这里，我终于明白了软件建模，但由于目前的公司不用这个玩意，我还没见过设计建模，只见过分析建模。然后怎么办？自己慢慢的捣鼓呗。
今天就到这里，下次接着分析建模的后面学习情况，与君共勉。
扫一扫
984
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
