揭开UML美丽的面纱--实话实说《UML:Java程序员指南》（转）

http://www.dearbook.com.cn/Guide/ViewGuide.aspx?GuideID=207

《敏捷软件开发》的译者邓辉畅谈Bob大叔的这本经典之作。
[ 查看本指南所提及的书籍 ]
      Bob 大叔(Robert C. Martin)是一位享誉全球的面向对象设计大师，同时也是一位善于思考、敢于直言的实践家。他是我最为尊敬的软件开发者和最为喜爱的技术作家之一。他所写的东西（包括论文、书籍和代码）总是言简意赅而又直指问题核心，我每次看时总感到“于我心有戚戚焉”。是的，他的文字不仅犹如夏日里一阵阵清爽的凉风扫去我心中的疑惑，还能使我产生强烈的共鸣。

      关于软件开发方面的书很多，有过程方法的、有最佳实践的、还有设计原则的。但是当你真正进行软件开发实践时，却会发现这些书中告诉你的知识在实际运用的时候总是和期望的效果有一定的差距。应该还有某个存在于过程方法、最佳实践以及设计原则之外的东西来有机地把它们结合起来，才能真正地发挥它们的最大效用。这种东西不是可以形式化的条条框框，而是活跃于人的大脑中的某种思维方法。Bob 大叔花了七年时间才完成的《敏捷软件开发：原则、模式与实践》，向读者介绍了敏捷方法、面向对象设计原则、设计模式和UML，使读者有一种豁然开朗的感觉，清晰地阐述了这种思维方法。

    《敏捷软件开发：原则、模式与实践》被众多读者所赏识并理所当然地获得了计算机图书的最高奖项- ---Jolt大奖的时候，Bob大叔又推出了新作UML for Java Programmers（即《UML：Java程序员指南》，清华大学出版社推出了本书的中英双语版）。书名中UML赫然在目，但Bob大叔并没有像其他 UML书一样，详尽地描述UML语言。他的重点其实是如何去构建软件，以及在软件的构建中如何正确、有效地使用UML。有人称这是一本“颠覆UML的书”，其实不然，这是作者的又一本注重实效且能立即提高程序员技能的好书。

      我在软件开发方面有不少实践和研究，也参与过不少项目的开发。在合作过的许多程序员当中，我发现其中大部分人存在着这样一种情况：他们不是努力去提高自己开发高质量程序的能力，而是把大量的精力都投入到研究一些CASE工具的操作使用和UML的语言细节上。他们认为只要使用CASE工具绘制出一些漂亮、规范的UML图，就是在进行面向对象设计，就是一种高级的软件设计行为。这种错误的想法非但不可能帮助这些程序员产生出高质量的软件，还会成为他们职业生涯发展的绊脚石。糟糕的是，目前的一些教育培训并没有对这个问题给予足够的关注，而且一些市场炒作使问题变得更加严重。

      UML自“出道”以来，一直被美丽的面纱笼罩着，“走到哪里，亮到哪里”。喜欢尝鲜的软件精英们为之着迷，为之疯狂，甚至于迷失了方向。国内很多软件企业也纷纷聘请UML培训机构进行企业内训，期望UML能立即带来丰厚的回报。有的企业则惟UML为尊，要求我们的开发人员无论项目大小，一律用UML，大有“杀鸡用牛刀之嫌”。但后果呢，不分青红皂白滥用 UML，带给他们的只有失望。遗憾的是，很少有人注意到问题的根源在哪里。

    《UML：Java程序员指南》正是在这种形势下产生的，Bob大叔试图用他清醒的声音，唤起人们对UML的正确认识，这无疑具有很大的意义。
     下面我要结合自己在软件开发方面的实践和认识，谈谈对这本书的理解。
     这本书以UML的语法作为铺垫，以UML在软件开发中的使用为线索，慢慢地向你灌输着作者对软件开发和程序员的价值取向的看法。在《敏捷软件开发：原则、实践与模式》一书的序中，Bob大叔曾这样说道：“美的系统是灵活、易于理解的，构建、维护它们就是一种快乐。”他告诉我们，作为一个程序员，我们的职业是开发出美的软件，不是去绘制那些“中看不中用”（表面漂亮实际却蕴涵着糟糕设计理念）的UML图。而要创造出美的软件需要长期、不断地学习和实践。这一点是全书的中心，也是Bob大叔一直强调的观点（有作者的大量文章和演讲为证）。我觉得这一点对于在校的学生和刚刚走上工作岗位的程序员尤为重要，因为正确的观念重于一切。

      书中讲述了大量从实践中总结出来的优秀的面向对象设计原则。在描述这些具有指导和启发意义的设计原则时，采用了作者的一贯风格：附以实例、循循善诱、娓娓道来，总是能够以简明扼要的话语揭示出深刻的内涵。这种风格能够为我们带来愉快的阅读体验，作者就像是坐在你的身边，不时地给你以智慧的启迪。这些原则可以帮助你辨别一些常见的设计错误，并在创建美的程序的道路上迈出第一步。

      此外，作者在本书中向我们传授了许多软件开发工作中的权衡之道。这些权衡之道在我们实际的软件开发工作中具有非常重要的作用，可以使我们把精力集中于要解决的问题。当你在思考一个问题时，如果觉得一幅图能够帮助你理清思路，那么就去画图。当你在和其他人就一个设计问题进行交流时，如果双方觉得一幅图能够使交流的意图更加明确，那么就去画图。但始终都不要偏离你要解决的问题，不要在图的外观上花费太多的精力，因为一旦达到目的后，图示就完成了它的使命，花费在它的外观上面的精力就浪费了。这是一种典型的敏捷思维：“UML只是一种工具，不是最终产品，它可以帮助你思考、帮助你交流。但是不要过度使用它，否则会造成很大的浪费。”这种思维可以延伸到软件开发工作的方方面面，极大地提高我们的开发生产力。本书中所关注的也仅仅是那些我们在软件开发中经常用到的 UML元素。正如Bob大叔在书中所说：“掌握了这本书中的UML图，足以让每一个程序员安身立命”。

     最后，我想谈一下本书中另一个非常重要的观点，那就是对于软件设计的看法。传统的观点认为，软件设计是一些系统核心组件以及这些组件之间关系的图形化表示（目前比较常见的就是UML图），而Bob大叔的观点则与此相背离。他认为这些图示只不过描述了系统的一些高层结构，它们只是设计的附属物。真正的设计应该以代码的形式表现，它是可运行的、可验证的，并且是不断演化的，一个不能验证的设计是没有价值的。因此，我们在使用UML对系统进行描绘时，应该仅仅对系统的高层抽象进行粗略地描述，其作用也只是帮助开发人员大致了解系统。这样可以避免以后的变化所导致的大量UML图的修改工作。把那些关键的细节交给代码去描述，通过测试用例去表明这些代码是正确的（这方面的更多详细内容，请参阅Bob大叔的另一本书《 敏捷软件开发：原则、模式与实践 》）。就我个人而言，我是非常赞同他的这个观点的。

       我们这个行业在遭遇软件危机之后，一直在探索有效的解决之道。期间，既从其他行业借鉴很多经验而提出了软件工程的概念，又创造出了许多提高生产力的新技术，比如：面向对象、UML等。但由于许多从业者的经验和能力有限，这些过程方法、技术非但没有为他们带来好处，反而使他们陷入官僚主义和僵化的境地。幸好，有一批具有丰富软件开发经验的敏捷人士（Bob大叔就是其中的杰出代表）“挺身而出”，对新的软件开发技术进行实话实说。被评为软件十大先锋人物的 Barry Boehm在其最新著作Balancing Agility and Discipline（中译本《平衡敏捷与规范》即将由清华大学出版社出版）中指出“我们要感谢那些敏捷人士，是他们使以一种更好的方式澄清了软件开发的必要性。”本书所讲述的内容正是“这种更好的软件开发方式”中的一部分。

      从书名上看，这本书似乎是专门写给Java程序员看的。实际上，任何软件开发者都可以从本书受益。书名中之所以有Java程序员，是因为其中的代码是用Java来写的。如果你是C++程序员，肯定能看懂其中的代码，关键在于体会作者的思想。一旦掌握之后，就很容易融汇贯通了。

     值得高兴的是，《 UML:Java程序员指南（双语版） 》采用了不多见的中英文双语版，这满足了我们大多数人的需要。想迅速接收新思想，那就看中译文；要想慢慢玩味Bob大叔的写作风格，与他进行思想交流，那就悠着点，看英文。读这本书，是一种视觉和精神上的享受，相信你也会有我这样的感受。

任何东西都不能取代编程实践，编程能力是任何从事软件开发的人（程序员、设计师、测试人员）的立身之本。 Stallman 据说是这个星球上写代码最多的人。他可能并不精通 UML（难道掌握 UML 对于他是很困难的事情吗？），但是毫不妨碍他成为一代宗师。尽管面向对象已经成为当今开发的主流，占据了所有论坛的话语权，但是我仍然很欣赏 Emacs 的设计思想。Emacs 不是 OO 的，所以设计得很烂，根本不值一提，我们可以理所当然地这样想吗？

再来看看这个：
http://www.dearbook.com.cn/Guide/ViewGuide.aspx?GuideID=178

全程建模

     本文的标题就提到了全程建模，那，到底什么是全程建模？为什么要采用全程建模？她有什么好处？如果要用，又如何应用？如何开始？
2.1什么是全程建模
     在软件工程的全部实施过程中都采用模型的方式/手段而非文字的表达方式来进行描述/展现，这样的实现过程就称之为全程建模。
     特点：这些模型相互之间是有关联的，模型成为软件工程过程各阶段展现的主体而不是文字描述作为主体存在。

2.2全程建模的好处
     通过建模的方式将原来纯文字加图形描述的各种文档模型化，使得从需求到代码能够统一起来，实现需求的变动直接影响到代码的变化。
     提高代码对需求的有效性联系，同时，降低过去经常出现的：编码一启动，文档就失效的“怪圈”。

2.3全程建模的应用环境
2.3.1项目类型
    目前而言，我建议的项目应该具有以下特征：
    第一、在开发时间较为充足的项目中应用。
    第二、产品将来会不断地被要求提供升级服务。
    例如做产品开发时，一般时间和资金都较为充足，而且，公司方面也会要求将来对该产品做持续不断的升级，这时候，建议你采用全程建模的方法来实施你的项目。
2.3.2管理方式
    管理方式上建议尽可能的正规化，至少也应该提供如下管理措施：
    第一、项目开发计划和过程管理；
    第二、配置管理的应用；
    只要做了这两条，就基本上可以应用全程建模的方法来实施项目了。
2.4如何开始全程建模实践
    首先，开发人员必须有相应的基础知识；
    其次，公司在管理上应当适当的正规化；
    第三，初次应用的时候，开发过程中需要有经验的人来做指导和审核，以便于实施能够顺利进行。

这个所谓的“全程建模”除了 RUP 以外还说了些什么？贴上一个新的标签是不是书就会比较好卖？

看来 Bob 大叔显然比不上青润了，Bob 大叔写的书居然连我这种 UML 初学者都能读懂。如何把书写的让别人读不懂可是一门很高深的学问，而且还是财源滚滚的保障。Bob 大叔一定要在有生之年奋起直追啊。

听起来应该是本好书,赶紧买一本看看

听说有一半的内容和<<敏捷建模: 原则,模式与实践>>重复

果然是好书。我正嫌那本《敏捷建模》太厚没功夫看呢。

虽然我也对全程建模表示怀疑，不过因为没有用过，没有多大发言权，就当是一个门户流派，存在总有它的合理性。

市场是检验这些开发过程的标准，我们做好敏捷方法的宣传和推广就够了。

《敏捷建模》是哪本书啊？是不是就是《敏捷软件开发：原则、模式与实践》这本？

对呀，那本书我看了几个月才断断续续view了一遍，感觉需要些耐心、时间，这本很好，很随意的时间就可以翻一下，而且收获不小