OOAD和UML培训心得

今天在中创软件听了邵维忠老师关于OOAD和UML的培训，邵老师讲的太精彩了，预先一些在UML学习过程中困扰我好久的问题，都被邵老师一一点破，回来细细品味了一下确实收益非浅。

这四天培训原本的课程安排是：
1.OOAD的原理和历史
2.UML的原理和概念
3.OOA
4.OOD
先简单复述一下今天邵老师今天所讲课程：

上午的课程：

今天上午的课程讲述了OOAD的原理和历史，邵老师把类、对象、抽象、继承、基类、派生类、封装、消息、聚合、关联、多态的概念又细细讲了一遍，这些概念虽然都是些了熟于胸的内容，但因为邵老师讲的都很生动、并且重点也十分突出听起来还是有很大收获。其中老师重点提了一下对于封装不同的OO语言不相同的做法，对于Smalltalk这种纯OO的语言中强调外部对象不能访问内部数据，但这样同样带来的是编程麻烦、影响执行效率的问题，而现在一般的混合型OOPL语言（C++\Delphi\Java）大多采用不强调严格封装、实行可见性控制的方法，保证了灵活性，相当于把选择权又重新交还给程序员，即可以使用严格的封装有的时候也可以灵活的访问数据。讲的继承的时候我比较感兴趣，因为邵老师讲了一下使用单继承的Smalltalk和使用多继承的c++及多继承可能产生的问题，而没有讲多继承的另一种实现形式“接口”，现在流行的设计语言如Delphi\java\c#等都使用单继承+接口的实现方式，这样既避免了继承结构的混乱和命名冲突，又在原有基础上实现了模块间的契约调用。这样的设计方式在vcl、jdbc等类库中都体现了很好扩展性，并且在经典的设计模式中也有很多体现。对于这个问题我在课下还专门询问了一下老师，邵老师解答说接口不属于OOAD的基本范畴，属于是语言和UML扩展的概念。并且邵老师认为接口实现的意义很有限，并且在很多地方还会影响效率。但在我们实际开发中能否正确使用接口经常被认为是初学者和高手之间的差别，这可能也是因为学术大家和基层工作者所看问题角度不同引起的，当然这也是个仁者见仁，智者见智的问题了。

在上午的课程中老师还着重强调了一下“关联”关系，好像是因为最近在国内很多书籍中对“关联”的描述不是很准确，邵老师用集合学上的一个概念来描述“关联”关系：对于集合 A{A1,A2,A3......AN}和集合B{B1,B2,B3,......BM}的笛卡尔积A*B集合中，任意元素如果提供了被开发领域中使用的一组有意义的信息则定义为一个关联。虽然读起来绕口但理解起来也不困难。同时邵老师也提出了现在在UML使用过程中对关联关系认识上的误区：“认为任何2个类存在关联关系才会有消息”，其实即使2个类不存在关联关系也可能有消息传递。

下午的课程：

在下午的课程中老师讲了UML相关的课程，这部分课程中老师讲了很多书本上没有的观点和内容也是我收获最大的一部分。首先老师讲了一下UML的历史，需要说明的是前面UML的这段历史对于后面理解UML一些奇怪而错误的设定有很大帮助。

先来简单复述一下UML的历史（以下内容摘录自OMG UML修订任务组和OMG分析设计平台任务组联合主席Cris Kobryn于1999年10月在《COMMUNICATION OF THE ACM》上发表<UML 2001：标准化的《奥德赛》史诗>[蒋严冰老师 邵维忠老师 编译]）:
------------
早在1995年，Gray Booch和Janes Rumbaugh将他们的面向对象建模方法统一为Unified Method V0.8。一年之后Ivar Jacobson加入其中，共同将该方法统一为二义性较少的UML 0.9。同时，这三位杰出的方法学家被称为“三友(Three Amigos)”。

很快用户也认识到可对软件系统进行可视化、描述、构造和文档化的通用建模语言所带来的益处。他们充满激情地将这种语言的早期草案应用于不同的领域。受用户强烈需求的驱动，建模工具厂商也很快在它们的产品中加入了对UML的支持。

与此同时，UML成了实际上的工业标准。1996年，一个由建模专家组成的国际性队伍“UML伙伴组织”开始同“三友”一起工作，计划将UML提议作为OMG的标准建模语言。

1997年1月，伙伴组织向OMG提交了最初的提案UML 1.0。经过了九个月的紧张修订，于1997年9月提出了最终提案UML 1.1，这个提案在1997年11月被OMG正式采纳为对象建模标准。

有必要指出的是，由于比较仓促地通过了OMG的提交过程，尽管语言的基层结构和大部分上层结构是合理的，UML还是容忍了一些不尽如人意的负面因素：活动图的语义及表示法不完整；标准元素臃肿，其中有些元素是为了满足不同的、相互竞争的方法门派的需求而草率加入的，许多标准元素语义贫乏，而且命名和组织也不一致;结构混乱，所提交的规范并没有达到提交者预期的目标——用一种严格的元模型方法实现4层元模型结构，相反使用了一种实用但不精确的、松散的元模型方法，不利于UML同其他OMG规范的结合，比如与MOF（Meta Object Facility）的结合。

-------------
由上面可以看出UML虽然吸收了百家之长但并没有完全的进行取舍进行融会贯通,我觉得这也是自己在UML学习中经常走向歧途的原因之一。同时老师还强调UML虽然是现在软件建模中实际的标准但严格意义上来讲只是通过OMG批准的规范（specification）还不是严格意义上的标准（standard）。

讲完UML的历史后老师以UML1.4为参考从整体上讲述了UML规范的内容。UML1.4的规范分为6个部分:
1.概要
2.语义
3.表示法指南
4.外扩范例：（指针对不同领域的扩展--注：这部分笔记记的不是太清楚）
5.模型交换 a, CORBA的设施接口IDL b, XMI DTD规范
6.对象约束语言规范(OCL)

接下来老师讲了UML的语言体系结构，这部分应该是今天课程中最绕口最不好理解的部分了，这个元-元模型图我以前在书上看过好几次解释也看了不少，都是囫囵吞枣过去的，这次经过邵老师悉心讲解才知道其真正的作用。四级元模型是OMG为面向对象方法所规定的一个体系结构，UML符合这个规范。对于四级元模型：

M3级别为元-元模型：它是定义建模语言的语言，相当于MOF
M2级别为元模型：它就是我们所说的建模语言也就是UML
M1级别为模型：这部分是由我们开发者使用的也就是UML所建立的模型
M0级别为用户对象：这部分属于是系统用户层次，属于是模型所描述的实体。


讲完这个让大家头大的问题，下面的关于“元模型构造物”的内容理解起来依然不轻松，元模型构造物分为抽象构造物和具体构造物，具体构造物是指我们开发者在实际建模过程中使用到的元素，抽象构造物是为了更进一步描述UML描述具体构造物而抽象出来的构造物。
数据类型、类、接口、构件、节点这几个可以被分类实体化元素继承自抽象元模型构造物Classifier（类目）；关联、泛化、依赖继承自“关系”；关系和Classifier同时又继承自可泛化元素。

完成这部分内容后，剩余的内容就轻松了很多，接下来老师讲了UML表示法和UML图中常用到的元素和UML的扩充机制：
UML图中的元素：String(字符串)、name(名字)、label（标签）、keyword（关键字）、Expression(表达式)、note（注释）、package（包）
UML的扩展机制是UML的一个亮点，也是因为它扩展机制保证了它的流行和可用性：
1. 约束{OCL}
2. 注释：文字说明
3. 元素特征：属性 {关键词=值}
4. Stereotypes（衍型）：这部分的扩展是UML扩展功能中最有用的一部分， 它可以看作是原有类的一个子类，它在属性、关系等方面与原有元素相同，但用途更加具体。（上次pinxue老师的培训中也很强调了这个特性）
在UML的2.0中扩展将更加广泛，可以使用元-元模型定义元模型构造器。

在UML1.4中提供了9种不同的图，这些图从不同的视角对系统进行建模。
1. 类图：（在UML中最常用到图），仅用来表示静态类属性（此部分需要细化）
2. 对象图：（用处十分有限），对象图和类图有所重复，使用它会使得抽象的层次不明显，模型和程序对应得好才是好的建模语言。在UML修订过程中层考虑去掉对象图，但UML2.0版本还在保留，在GB-OOAD规范中将不使用该对象图。
3. 用况图（非常有用的图，特别是用在收集需求方面）可以规范描述需求，对于Include关系和Extend关系，Include表示一定会触发，Extend表示可能会触发。而在实际开发过程中，对于Include和Extend的处理方法都是一样的，可以更进一步抽象。对于用况的泛化关系，这个关系本身作用并不明显不严格不建议使用。用况图不仅仅是图形更重要的是文字描述。
4. 顺序图：（比较有用）表示的很清楚但只能表述很小的局部内容，[消息和激发]可以直接理解为消息
5. 协作图（最没用的图之一），因为类于类之间关系在类图中已经表示了，所以这个图得意义更加有限。
6. 状态图：意义有限，不过在某些特殊领域可能会用到
7. 活动图（比较有用）在结构化程序中可以代替流程图使用
8. 构件图：在1.4中相当于模型图，在2.0中有进一步改进
9. 部署图：

邵老师对UML的几个图和图形元素作了很详细的点评，这部分结合我们原先实际工作的情况做了下对比确实收获不小。



心得：
1. 原先我们在工作中一般使用类图、use case图、顺序图比较多，在有些判断流程很多的地方也会用活动图，当时看到UML提供了这么多的图和元素我们在实际项目中却用不上，都认为是自己对UML认识还不够，还不能领会真正用途，现在才知道其他的几个图对于我们普通开发者好像的确是没有什么用。
2. 对UML的历史有了进一步了解，原来称呼UML是一种OOAD的方法也是有一定道理的
3. 对于初学者UML难于学习一部分原因是因为其中涵盖的范围广泛，不同方法门派观点的杂糅以及结构混乱也是原因之一，UML有很多地方难于理解应该也是缘由此。
4. 原先和同事们为分辨一个use case是Extend还是Include经常会讨论半天，现在才知道究竟是那个关系并不重要，因为从更高的抽象角度看它们都是一样的，
5. 因为UML抽象化程度非常高，对于很多新名词的翻译上确实有很大难度，初学者看些原版书或是由国内学者消化吸收后自己写出来的书已经对学习有帮助。
6. 原先在学习UML总是觉得UML是十分高深和天书有的一比，经过老师点播后发现使用UML对于我们开发人员并不算困难，对于UML图只要学会适当裁剪取舍即可。
7. 对于临近下课一位同学问的在需求分析中是使用USE CASE图还是使用自然语言的描述，老师的解答是2者都要。事实上在Rational SUIT中已经提供了类似的解决方案，使用Requisite Pro需求管理工具，可以将rose中画的use case转换成自然语言描述的需求，并对需求的实现进行跟踪，看这个需求在设计阶段是不是被设计，同样实现阶段是否被实现，不过由于其关联性太强，在一般公司需求跟踪工作很难完成，不过use case转换成自然语言的工作是很简单的。
8. 我在学习UML过程中，在思考能否依靠工具来辅助软件开发，我的想法是在需求阶段，case软件可以帮助分析收集需求（由开发人员识别use case、actor），相应得可以生成需求文档，开发人员根据需求做出相应的设计文档，设计文档中要保证需求里面要求的功能都被设计到，并且可以根据设计中的类图生成编码中的类编码框架，并且保证设计中的内容都能被实现，同时这个CASE 软件可以对软件开发过程的变更进行跟踪，比如需求做出了变更则CASE软件同样提醒开发人员那些设计需要变更，同样设计改变后也会降实现部分的代码自动修改，实现一个完整的需求跟踪矩阵。同时这个CASE软件还能对变更、版本和工程进度作管理。上面说的这个软件的很多功能在Rational SUIT已经实现，但真正使用的意义并不是太大，主要是因为使用起来过于繁琐，且ROSE对我们当时使用的开发语言DELPHI支持不好。
9. 我尝试过很多的建模工具，发现最好用的是www.sparxsystems.com.au出品的Enterprise Architect ，价格和大小只有ROSE的1/10, 功能比rose更加完善，带有需求管理、估算等几个有特色的功能，并且能够支持UML2.0。