[重点]UML精粹第一章-李译

[重点]UML精粹第一章-李译 UML精粹 第一章 引言 第一节-什么是UML 统一建模语言(Unified Modeling Language，UML)为单一元模型支持的图形符号族，这些图形符号有助于我们描述与 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 软件系统，特别是那些用面向对象(object-oriented，OO)方式构建的软件系统。这个定义似乎有点简单化了，事实上，UML 是因人而异的，究其原因，一半源自于它的历史，另一半是因为大家为了实现一个有效的软体工程开发 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 ，往往从不同的角度来使用它。因此，本章的主要任务是对大家看待和使用UML的不同方式予以解释与说明，为全书作出一个铺垫。 在软件业，图形化建模语言已出现多年。引发大家使用这些建模语言的基本原因是:原有程序设计语言的抽象程度不够高，无法满足对设计进行讨论与交流的需要。 虽然图形化建模语言(graphical modeling language)已出现多年，不过业界对它们所扮演的角色还是存在很大的争议，这些争议直接影响到人们如何看待UML 的作用。 UML是由对象管理组(Object Management Group，OMG)管理控制的一种开放标准。OMG是一个由多家公司所组成的开放性联合组织，成立的宗旨是建立互操作(interoperability)的相关标准，特别是面向对象系统间的互操作问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 。OMG 最广为人知的事迹或许是CORBA(Common Object Request Broker Architecture，CORBA)标准。 UML起源于多种图形建模语言的融合，这些建模语言在上世纪80年代末到上世纪90年代初非常繁荣。UML在1997年出现，使原本一片混乱的局面成为了历史，这使得包括我在内的广大开发人员深感欣慰。 第二节 UML的不同用法 UML 在软件开发中所起作用的实质是人们使用它不同方式，这些差异其实是从其他图形化建模语言延续而来的，也因此导致了一个长期难以解决的争论:我们该如何使用UML, 为了解决这一纷争，Steve Mellor和我分别针对人们使用UML的特点提出了三种使用模式，即分别把 UML当成草图绘制语言、蓝图绘制语言或编程语言来用。以我个人的观点，将UML视为草图绘制语言应该是到目前为止最常见的一种用法。在这一用法中，开发人员使用UML来帮他们实现系统某些层面的交流。和用作蓝图绘制语言一样，我们可以从正向工程(forward-engineering)或逆向工程(reversee engineering)两个不同方向来使用草图绘制语言。如果是采用正向工程的话，我们会在写程序之前先画出UML图，而逆向工程则是由现存代码产生UML图，以帮助我们理解代码。 绘制草图的实质是选择。以正向使用草图来看，先针对要编码的某些议题粗略画出草图，然后与项目组的同事进行讨论。使用草图的目的是帮助我们沟通想法，并且针对要做的事情探讨可供选择的方法。讨论不要涉及所有要编写的代码，只需针对那些打算先交给同事去做的重要议题，或者在开始写代码之前想以可视方式展现出来的部分展开。像这样的会议通常非常短，有可能开十分钟的会讨论未来几小时的编码工作，或者花费一天来讨论未来为期2个星期的迭代(iteration)工作。 对于逆向工程，通常利用草图说明系统的某个部分如何工作。因此，不必展示所有的类，仅需展示那些有意义或在深入研究代码之前值得一提的问题。 由于草图是非正式的，变动性也很大，需要快速、相互协作完成，所以白板是最为常用的一种工具。草图对于设计文档也有用，在这种情形下，重点在于沟通和交流，而不是苛求完备。用来画出草图的都是简易的画图工具，而且大家也不会刻意遵守UML中的每一条严谨 规则。多数书(例如我的其他书)中所给出来的UML图，大多是草图，其重点在于有选择地交流，而不是完整地说明。 与此相反，将UML视为蓝图绘制语言则强调完整性。在正向工程中，蓝图绘制由设计师完成，设计师的工作就是做出详细设计，供程序员依葫芦画瓢完成编码。设计结果必须足够完整，要做出所有的设计选择，程序员不需要太多思考，就可以按照它完成代码编写。当然，设计师和程序员有可能是同一个人，不过一般来说设计师通常是比较资深的开发人员，由他替整个程序员团队做出设计。这种做法得益于其他类型工程的启发，在那些工程中，往往先由专业工程师画出工程图，然后，再把这些图纸交给建筑公司去施工。 蓝图绘制可以用于所有细节性工作，即，设计师可以针对特定部份画出蓝图。对于设计师，通常的做法是建造出蓝图级的模型，直到子系统的接口，稍后再让开发人员给出实现的具体细节。 在逆向工程中，蓝图的目的是传递关于代码的详细信息，可以借助纸质文档，也可以通过交互式的图形浏览器。蓝图可用图形方式展示某个类的所有细节，让开发人员更容易理解。 与草图绘制相比，蓝图绘制需要更复杂的工具，以便处理工作任务所需要的细节。专用的CASE(计算机辅助软件工程)工具就属于这一类，不过现在 CASE 这个词已经被人用烂，厂商也在试图回避这个词。正向工程工具支持绘图，并利用储存库保存信息。反向工程工具则可以读取原代码，然后解读源代码到储存库，从而产生图。同时支持正反向工程的工具则称为双向工具(round-trip tool)。 有些工具直接把原始码作为储存库，把图当作代码的图形化视图。这些工具跟编码工作结合的更加紧密，而且通常会直接与代码编辑器整合在一起。我喜欢将其称为无往返工具(tripless tool)。 蓝图和草图之间的界线有时是比较模糊的，不过本人认为两者间的差异在于:我们会刻意使草图不完整，以突出重要的信息;而蓝图则意图变得无所不包，目的是让编码工作变成简单的、相当机械化的活动。简言之，我认为草图是探索性的，而蓝图则是确定性的。 随着在UML上花的功夫越来越多，编码工作变得越来越机械化，编程自动化是显而易见的。事实上，许多CASE工具都可以实现某种形式的代码自动生成，使系统的相当一部份的构建工作自动化。如此继续下去，最终可以用UML说明系统的所有部份，这时候UML就可以视为编程语言了。在这种情况下，开发人员绘制可直接编译成可执行码来的UML图，UML也就变成所谓的原代码了。很明显，这种UML用法需要很复杂的工具。(此外，从这种用法来看，正反向工程的概念也变得没有意义，因为这时候UML与原代码已经是同一回事了。) 模型驱动架构与可执行UML 当人们谈论UML时，往往会提到模型驱动架构(Model Driven Architecture，MDA)[Kleppe et al.]。实质上，MDA 是将UML作为编程语言来使用的一种标准方法;这个标准与UML一样，均由OMG负责掌控。厂商只要产生一个符合MDA的建模环境，那么它所建造的模型也可在其他MDA兼容环境中使用。 当人们谈论MDA时，通常也会提到UML，因为MDA把UML当作基本的建模语言。不过，使用UML时当然不一定要使用MDA。 MDA将开发工作分成两个主要方面。建模人员针对特定应用问题构建一个平台无关模型(Platform Independent Model，PIM)。PIM代表与任何特定技术无关的UML模型。然后使用工具将PIM转换成平台特定模型(Platform Specific Model，PSM)。PSM是面向某个 特定执行环境的系统模型。更深一层的工具处理PSM，生成该平台上使用的代码。PSM可以是UML，不过并非必须是UML。 所以如果想用MDA建立一个仓储系统的话，那么可以先建立一个仓储系统的PIM。接下来，如果希望这个仓储系统在J2EE与.NET上执行，就可以使用某些厂商所提供的工具来产生两个PSM:每个平台各一个。稍后，再用其他工具进一步产生两个平台使用的代码。 如果从PIM到PSM，再从PSM生成最终代码的过程完全自动化，就可以将UML视为编程语言。如果其中任一步骤要以手工方式完成，就将UML视为蓝图绘制工具。 Steve Mellor长期活跃在这一领域，最近又提出了一个术语可执行UML(Executable UML)[Mellor and Balcer]。可执行UML与MDA含义相似，只是叫法不同而已。类似地，开始先产生一个相当于MDA之PIM的平台无关模型，然而，下一步是使用模型编译器将UML模型直接转换为可部署的系统;因此，它不需要产生PSM。正如编译器这个词所暗示的，这一步骤是完全自动化的。 模型编译器是基于那些可复用的原型(archetype)。原型描述如何获取一个可执行UML模型，并将其转换到特定的程序设计平台。就仓储系统这个例子来说，可以购买一个模型编译器和两个原型(J2EE与.NET)。然后分别对于可执行UML 模型运行每个原型，得到仓储系统的两个版本。 可执行UML并没有使用完备(正式)UML标准;它认为UML中有许多构造并不是必须的，因而没使用它们。所以，可执行UML比完备(正式)UML还要简单。 所有这一切听起来不错，但其现实程度如何呢,就我个人的观点，至少存在两个问题。首先是工具问题:这些工具是否成熟到足以完成此项工作。当然，情况会随着时间发生变化;但确实，在我撰写本书时，这样的工具并未广泛使用，而且也没有发现一些工具在起作用。 另一个更为基本的问题是将UML视为程序设计语言的观念。依我看，只有在 UML较其他程序语言有更高编程效率的情况下，使用UML作为程序设计语言才是有价值的。不过，就我过去曾使用过的各种图形开发环境来看，我实在很相信这一点。纵然他真的更加富有成效，还是需要有大量的使用者，才能使其成为主流。这件事本身就是一大障碍。像许多Smalltalk爱好者一样，我认为Smalltalk比当前一些主流程序设计语言更富有效率。然而，Smalltalk只是作为一种摆设，到目前，并没有多少项目在使用它。要避免与Smalltalk一样的下场，纵然UML比较优秀，它还必须足够幸运。 如果将UML用作编程语言，一个很有意义的问题是如何构建行为逻辑的模型。UML第2版中提供了三种构建行为模型的方法:交互图(interaction diagram)、状态图(state diagram)与活动图(activity diagram)。对于每一种方法，都有人建议植入编程功能。如果UML真能成为一种流行的编程语言，很难预料究竟是哪一种技术会取得成功。 对于UML的使用方式，人们关注的另一个方面是究竟偏重概念建模还是偏重于软件建模。大部分人都习惯使用UML进行软件建模。从软件视面(software perspective)，UML中的各种元素都可直接对应到软件系统中的元素。可以预见，这种对应关系绝不是严格 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 的，不过当我们使用UML时，事实上是在讨论软件元素。 从概念视面(conceptual perspective)，UML就是我们对所研究领域的一种概念描述。这时候，我们不是在讨论和软件元素有关的东西，而是构建一个词库，用于讨论某个特定领域的问题。 对于视面，并没有严格的规则;如同大家所见到的，存在各种各样的用法。有些工具自动把原代码转成UML图，把UML视为是原代码的另一种视图。这种做法在很大程度上侧重软件视面。另一方面，如果试图用UML图和会计师探讨资产池(asset pool)这个术语的各种含意，实际上是更多地处于思维的概念框架之内。 在本书的前两版中，我将软件视面细分为规范(接口)与实现。但实际上，我发现很难对两者予以严格区分，所以，不值得这么小题大做。不过在图中，我还是倾向于强调接口而非实现。 UML的这些不同用法引起了很多争议，UML 图究竟代表什么，它们与外界事物之间是什么关系。特别，它影响到UML和原代码之间的关系。有些人持有这样的观点:UML 应当用来产生与用于实现的编程语言无关的设计，另一些人则认为:语言无关的设计是自相矛盾的说法，具有非常愚昧的印象。 对于UML，另一种观点上的分歧在于:UML 的要素是什么。就我个人来看，大部分的UML 使用者，特别是用于草图绘制的使用者，会认为 UML 的要素是图。然而，UML 的创造者却把图看作是第二位的;他们认为 UML 的要素是元模型，图仅仅是元模型的展现而已。这种观点对用于蓝图绘制和将UML用作编程语言的使用者来说，也是有意义的。 所以无论何时，当你阅读任何与 UML 有关的作品时，最重要的是设法了解原作者的观点。唯有这样，你才会明白UML 所引起的那些激烈争论究竟为何。 针对上述不同说法，我需要很清楚地表明自己的看法，几乎任何时候，我都将 UML 用于草图绘制。我发现UML 草图在正反向工程，以及概念视面和软件视面都是非常有用的。 我不是那种详细的正向工程师蓝图爱好者;我认为详细的正向工程师蓝图很难绘制，而且它也会延缓开发工作。对于子系统的接口层，将UML用于蓝图绘制是合理的，不过纵然如此，你还是应当预料到，当开发人员实现接口间的交互时，很可能会修改那些接口。至于由反向工程所得到的蓝图，其价值要看工具是如何运作的。如果当作代码的动态浏览器来使用，它可能非常有用;如果它只会产生一大堆文件，那么它就是在砍树。 本人认为将 UML 视为编程语言是一种很好的想法，不过却对它是否会被广泛使用有所怀疑。首先，我无法相信对于大多数编程任务，图形比文字更有生产效率。即使真的如此，要让一种编程语言被广泛接纳也是一件非常困难的事情。 因为上述这些偏见，所以本书更多地着重于将UML用于草图绘制。幸运地是，对于一本简明入门读物来说，这却是非常有意义的。在这样一本小篇幅的书中，我无法公平地介绍 UML的其他两种用法，不过本书却对那些介绍其他用法的书籍给出了有效导引。所以如果你对UML的其他用法有兴趣，那么请将本书当作一本入门书，需要时再去看其他书籍。如果你只对草图用法感兴趣，那么本书足以满足你的需要。 第三节 UML的发展历程 老实说，我是一位历史爱好者。当我想看轻松的书时，就会拿起一本好的历史书。不过我知道并不是每个人都对这样的书有兴趣。之所以在这里谈到UML 的历史，主要是因为我认为:如果不了解它是如何演变的话，那么我们将很难从多方面来了解 UML 的现况。 在上世纪80年代，对象刚走出实验室，迈向真实世界的第一步。某个平台上的 Smalltalk 程序语言已经很稳定、也能用了，而 C++才刚刚诞生而已。此时，大家开始思考面向对象的图形设计语言。 跟面向对象图形建模语言有关的重要书籍出现在1988 年到1992 年间。当时的领导人物包括 Grady Booch[Booch、OOAD];Peter Coad[Coad、OOA]、[Coad、OOD];Ivar Jacobson(Objectory)[Jacobson、OOSE] ;Jim Odell[Odell];Jim Rumbaugh(OMT)[Rumbaugh、insights]、[Rumbaugh、OMT];Sally Shlaer与Steve Mellor[Shlaer and Mellor 、data]、[Shlaer and Mellor、states];Rebecca Wirfs-Brock(Responsibility Driven Design) [Wirfs-Brock]。 前面所提到的这些作者都非正式领导一群喜欢他们想法的实践者。其实，这些方法论之间都非常相似。只是，彼此存在着一些烦人的小差异。同样的概念可能会有非常不同的表示法，这些差异让我的客户感到十分困惑。 在那段令人兴奋的时期里，有人谈到了标准化问题，也有人忽视这个问题。一个 OMG的工作组试图进行标准化的工作，可是他们却收到主要方法论学者的一封公开抗议信。(这让我想起了一个老掉牙的笑话:方法论者和恐怖主义者间有什么差 异吗,答案是你可以跟恐怖主义者谈判。) 促成 UML 诞生的第一个重大事件是 Jim Rumbaugh 离开通用电器加入Grady Booch 所在的 Rational 公司(现在它已属于 IBM 公司)。大家认为这时候的 Booch/Rumbaugh 联盟，他们所具有的市场占有率已超过临界值了。Grady 与 Jim 宣称方法论的战争结 束了，他们已经得到胜利。基本上，他们宣称将以微软占领市场的方式来促成标准。 一些其他的方法论者因而想成立反 Booch 联盟。 在 95 年的 OOPSLA 大会上，Grady 和 Jim 第一次提出结合两人想法的方法论:0.8 版 的统一方法论(Unified Method)。更重要地，他们宣布 Rational 公司已买下 Objectory 公司，从此以后Ivar Jacobson 也将加入统一团队。Rational公司还举办了一场庆功宴 来庆祝他们的0.8 版草案问世。(这场宴会的高潮是 Jim Rumbaugh第一次当众展现他的歌喉; 次年，我们看到比较开放的合并过程出现。OMG，这个不过大家都希望这也是最后一次。) 过去以来一直担任旁观者角 色的组织，终于开始扮演主导的角色。Rational 公司一方面必须将 Ivar 的想法融合起 来，同时也要花时间跟其他协力厂商沟通。更重要的是，OMG 决定担任主角。 我们必须了解 OMG 在这个时间点之所以介入的原因。方法论者，例如一些书的作者， 都希望他们受到重视。不过，我认为这些书籍作者的吶喊声并没有被 OMG 所听到。 OMG 之所以介入，其原因是因为他们听到工具厂商所发出的吶喊声，大家一致反对这项标准单独被Rational 公司所掌控，因为这么一来，Ratioanl 工具将取得不公平的竞争优势。因此，厂商们逼迫 OMG 在维护 CASE 工具互通性的旗帜下做些事情。 这面旗帜非常重要，因为 OMG 所代表的正是跟互通性有关的事。大家的想法是:创造出UML 来，让所有的 CASE 工具都可以自由自在地彼此交换模型。 Mary Loomis 与 Jim Odell 担任创始工作团队的共同主席。Odell 很清楚地宣示，为了标准，他准备放弃自己的方法论，不过他不希望产生一个由 Rational 公司强势推销得来的标准。在 1997 年1月，许多组织一起交出方法论标准用的很多提案，藉此达成交换模型的目的。Rational 公司联合了许多组织，并发行了 UML1.0 版的文件作为它们的提案，这是第一份叫做统一建模语言的文件。 接下来则是一连串的角力过程，同时很多的提案也被合并进来了。OMG采用最后所得到的 1.1 版作为 OMG 的官方标准。稍后它又做了一些修定版本。1.2 修定版整个都只是在修饰文字而已。1.3 修定版有比较显著的差异。1.4 修定版新增了许多跟组件(component)和特征描述有关的细节概念。1.5 修定版则新增了动作语意(action semantic)。 当人们在谈论 UML 时，大部分认为Grady Booch、Ivar Jacobson 与 Jim Rumbaugh 三位 是创始人。大家喜欢把他们称为 UML的三人帮(Three Amigos)，不过有些爱开玩笑的人会故意把Amigos的第一个音节漏掉(译注:这样子Amigos就被读作[mI`^Cd]，在口语里是天哪!哎呀! 的意思(=My God!))。虽然他们是UML的主要贡献者，不过个人认为把这么巨 大的荣誉归于他们，对其他人来说实在有失公允。没错，UML表示法的确是在 Booch/Rumbaugh 的统一方法论中成形的。不过自此以后，大部分的工作都是在OMG 委员会的领导下所完成的。在后面这些阶段，Jim Rumbaugh 是三人当 中唯一参与较多的人。个人认为 UML推动委员会中的这些成员才是 UML 实至名归 的有功人员。