《UML精粹》·书评

本来说3天看完这本书，毕竟只有200页，而且也是入门级别的读物。但是计划总赶不上变化，前前后后花了5天才看完，而且有些地方还不是很明白，因为欠缺实战经验（至今我还没画过UML，只玩过结构化设计的一些图）。

本书的确是UML初学者入门的经典书，凡入门读物，重点是将其精华，略去细枝末节，这本书做到了。作者大篇幅介绍结构图中的类图和行为图中的顺序图、状态机图和活动图。因为这是我们实际应用中大部分所用到的，有些图作者只花了2页去介绍。我觉得本书只所以简洁，这跟作者的写作风格有很大关系。每介绍一个图，作者首先抛出这个图的一个范例。然后再用文字陈述使你很快的了解这个范例图的含义。最大的亮点就是在每张最末他告诉了这种图何时用才会更佳。这是他自己的经验总结，虽然你可以完全不认同，但是我认为带着他的经验在实践中检验并积累你自己的经验才是最佳！

还有一点我不得不说，此书翻译得实在不咋样。在“第三版译序”中有一处：“余自今岁五月阅读此书，六月启译，虽数易其稿，然限于水平，错讹欠妥之处，恳请业界贤达，不吝赐正”。又不是写言情小说，不需要那么高的意境，尽量达到简单易懂就好了啊。其实本来就一本简明教程，被你这么一搞，变得难读了。用文言文翻译技术书籍我还是第一次见到。

写序用古文也就好了，毕竟跟内容没多大关系。但有些地方的措词也令人追摸不透。比如：“对一个特定的图来说，任何信息均可被隐抑”、“因此，在一张图中，你一定不能在信息阙如时进行任何判断”、“...并未过多的谈到在UML元模型的精良天地之外UML含义”。其中“隐抑”、“信息阙如”、“天地精良之外”这些词实在是让人丈二和尚摸不着头脑，难道是我语文水平太低了？为什么不用“隐蔽”、“信息缺乏”？没说“精良天地之外”的对应词是因为我确实不懂它在句子中是什么意思。= =！

好了，还是看看写的什么吧

=========================================================================

第一章 引言

UML三种使用分类法：用作草图绘制语言、用作蓝图绘制语言、以及用作程序编制语言。草图是研究性的，蓝图是定义性的。通常的途径是，设计人员开发蓝图级的模型直到子系统的接口，然后，让开发人员产生出实现那些细节的细节。

大多数的时候，UML草图是其精髓，然而，UML创建者却认为元模型才是。UML草图对正向工程和逆向工程都是有用的，并且在概念视面和软件视面中也都有用。

元模型是一种用以定义语言概念的图（通常是类图）。元模型对于UML的用法以及编程语言都很重要。图示法的问题往往居于第二位，如果你打算熟悉标准文档本身，那么，图示法就很重要了。

UML一共有13中正式图形，他们分别是（括号中是图的目的）：

结构图：类图（类、特征与关系）、构件图（构建的结构与连接）、复合结构图（类的运行时刻分解）、部署图（制品在结点上的部署）、对象图（实例的样形）、包图（编译时刻层次结构）。

行为图：活动图（过程行为与并行行为）、用案图（用户在系统中如何交互）、状态机图（事件如何改变生命周期中对象）、顺序图（对象间交互，着重顺序）、通信图（对象间交互，着重连接）、交互概观图（顺序图与活动图的混合）、定时图（对象间交互，着重定时）。

UML更多的是具有描述性规则，看UML不是用来精确定义源代码的，而是对这种代码能有一个粗略的印象。

第二章 开发过程

极力推荐项目不要采用纯瀑布风格。如果不用更纯粹的迭代风格，也应该采用阶段提交风格。

预见性计划制定更多地致力于需求过程本身。这样，你就可以得到一组更为精确的需求，从而会使折腾减少。而适应性计划制定则认为需求折腾是很正常的事情，因此把预见性看成一种假象。不用虚幻的预见性来愚弄自己，而应该面对不断改变的现实。在具有准确而精确的需求且确信不会大动以前，不要制订预见性计划；如果不能得到准确、精确、稳定的需求，就使用适应性计划制定方式。适应性计划绝对要求迭代过程，预见性计划制订两种风格（瀑布和迭代）都可以做。

UML适配过程

需求分析：

用案    表述人们如何与系统交互。

从概念视面绘制的类图   这种图可能是一种构作领域精确词汇表的好方法。

活动图    活动图以示明组织机构的工作流，示明软件与人的活动如何交互。活动图还可以示明用案的环境以及复杂用案如何工作的细节。

状态图    如果一个概念具有有趣的生命周期、具有各种状态以及改变状态的事件，状态图则可能有用。

设计：

软件视面的类图    这些图示明软件中的类以及它们如何相互联系。

常用案况的顺序图    一种有用的方法是从用案中挑选出最为重要且有趣的案况，并利用CRC卡或顺序图以勾勒出软件中发生的事件。

包图    示明软件的大型组织。

具有复杂生命史的泪的状态图。

部署图    示明软件的物理布局。

文档：

包图，部署图，由少量交互图支持的类图，那些少量的交互图示明系统中最重要的交互。

如果一个类具有复杂的生命周期行为，我就绘制一个状态机图来描绘它。只是在该行为充分复杂时才画状态机图。

第三章 类图

一个类图表述系统中各个对象的类型以及其间存在的各种静态关系。类图也示明类中的特性和操作以及用于对象连接方式的约束。UML使用特征一词作为涵盖类之特性与操作的一般术语。

何时使用类图？

不要试图使用对你可用的所有图示法。仅当需要时才使用。

概念类图（即从概念视面绘制的类图）在探究业务语言时很有用。尽量使软件离开讨论并保持图示法很简单。

不要对每件事都绘制模型，而要集中考虑关键方面。少量使用至今的图要比很多被人遗忘而遭淘汰的模型更好。

第四章 顺序图

交互图表述各组对象如何依某种行为进行协作的模型。UML定义了若干形式的交互图，其中最常见的是顺序图。

典型的是，一个顺序图获取单个案况的行为。这种图示明一些样例对象以及在用案内部这些对象之间传递的信息。

何时使用顺序图？

当你要考察单个用案内部若干对象的行为时，就应使用顺序图。顺序图擅长于示明对象间的协作；但是它们却不擅长于示明行为的精确定义。如果要考察跨用案的单个对象的行为，就使用状态图。如果要考察跨用案或跨线程的行为，就要考虑活动图。如果要迅速探究多个供选交互，则使用CRC卡更好，原因是，那样可以避免不少绘制及擦去工作。举行一次CRC卡聚会探讨设计选择非常方便，而后再使用顺序图来获取往后要提到的任何交互。其他形式的有用交互图是用以示明连接的通信图以及用以示明时间约束的定时图。

第五章 类图高级概念

在用到的时候才用它们。

第六章 对象图

对象图是在一个时间点上系统中各个对象的一个快照。由于对象图示明的是实例而不是类，所以它有时亦称实例图。

何时使用对象图？

对象图对于示明连接在一起的对象的例子是有用的。在很多场合，可以使用类图精确定义一个结构，但这个结构仍然难以理解。在这些场合，几个对象图例就可以使全局改观。

第七章 包图

包是一种这样的聚组构造，使你能取UML中的任一构造，将其成分聚组在一起，以构成更高层的单位。其最通常的用法是聚组类，而这就是我在这里表述的方式，不过，你也可以将包用于UML的任何别的小块。

何时使用包图？

对大型系统要了解系统主要成分之间的依赖时，包图极为有用。这些图很好地对应于通常的编程结构。绘制包河依赖的图有助于你保持对应用依赖的控制。如果你想示明在运行时刻如何来组合各个对象，请使用复合结构图。

第八章 部署图

部署图通过揭示“哪些软件片段运行于哪些硬件片段上”来示明系统的一个物理布局。

何时使用部署图？

任何复杂的部署都可以很好地使用部署图。

第九章 用案

用案是获取系统功能需求的一种技术。用案通过表述系统的用户和系统本身之间特有的交互而工作，提供了如何使用系统的一种陈述。

何时使用用案图？

对用案，要全神贯注的是正文而不是图。纵然UML对用案正文未有任何论述，包含技术中全部价值的依然是正文。记住，用案千万不要做的太复杂。

第十章 状态机图

状态机图是表述系统行为的一种熟悉的技术，在面向对象方法中，对单一一类画一个状态机图以示明单个对象的生命周期行为。

何时使用状态机图？

状态机图擅长于表述跨用案的对象行为。状态图不太擅长于表述包含若干协作对象的行为。就其本身而言，把状态机图和其他技术进行组合是有用的。顺序图擅长于表述单个用案中若干对象之行为，而活动图擅长于示明若干对象和用案的活动的一般顺序。如果你真使用状态图，就不要打算对系统中每一个类都绘制状态图。很多人发现UI和控制对象具有值得用状态图刻画的行为。

第十一章 活动图

活动图是一种表述过程基理、业务过程以及工作流的技术。在很多方面，它们所起的作用与流程图类似，但是，与流程图表示法的主要区别是，活动图支持并行行为。

何时使用活动图？

活动图的最大优点是，它们支持并鼓励并行行为。这使它们成为工作流建模和过程建模的一项重要工具。活动图最好不要用于表述用案，因为往往领域专家不易领会活动图。

第十二章 通信图

通信图是一种着重阐述交互中各个参加者之间的数据连接的交互图。与顺序图依垂直方向对每一参加者画一条生命线并示明消息顺序不同，通信图允许自由放置参加者，允许画一些连线来示明各个参加者如何相连，并利用编号示明消息顺序。

何时使用通信图？

在强调调用顺序时，用顺序图更好；要强调连接时，通信图更好。

第十三章 复合结构图

复合结构图是层次的把一个类分解成一个内部结构的能力。这就使你能把一个复杂对象分成若干部分。

何时使用复合结构图？

包和复合结构图之间区别是，包是编译时刻的聚组而复合结构则示明运行时刻的聚组。就其本身而言，复合结构自然宜于示明构件以及如何把构件分解为部分，因此，这种图示法大部分适用于构件图。

第十四章 构件图

构件是涉及客户如何与软件相联系的一种构造。

何时使用构件图？

当你将系统分成若干构件，并希望借助接口或者把构件分解为一些更为底层的结构示明期间相互关系时，就要使用构件图。

第十五章 协作图

协作图表示角色由不同的类扮演。

何时使用协作图？

在角色由不同的类扮演时，协作的确提供了一种把交互行为聚组成块的方式。

第十六章 交互概观图

交互概观图时将活动图与顺序图嫁接在一起的图。

何时使用交互概观图？

取决于何者服务与你的目的更好，你或者画活动图，或者画顺序图。

第十七章 定时图

定时图是交互图的另一种形式，其中着重点是对约束定时：或者是对单个对象，或者更有用的是，对一群对象。

何时使用定时图？

定时图用以示明不同对象上状态改变之间的定时约束。

 

终于写完了，写了一下午，纯手工制作，希望大家支持下

这本书,那翻译,还是再去看一遍E文的吧!!再把术语纠正过来.万恶的徐X福......

参考http://www.iteye.com/topic/175638

这本书英文版，大概可以算作入门读物，而简体中文版则不是入门读物。同很多人所理解的不同，我认为简体中文版翻译的非常好，非常准确到位的反应了原作者的思想脉络，也非常反应出翻译者的高超学术水准。对于译者我们不需要去非议他的能力，如果这位老先生能力有问题，态度有问题，思想有问题，那么估计国内的计算机领域就没法找出好人了。
实际上我们看评论，最多的非议大大集中在用词比较怪异，跟我们平常使用的有所不同。其实类似问题，当初侯捷也遇到过。原因在于译者都觉得现在的词汇体系，特别是专业名称体系不能很好的表达，这些专业方面的内容。而这位老先生，恰好是国内的权威（是真权威，不是北大那些假权威），长期从事研究和教学活动，是实打实的人。所以他们免不了，会把自己的学术思想结合到翻译中去。而且即便不考虑自己的观点，这些学院派的老先生，也自然会有一种希望能够成系统，条理化的倾向。而且文章的风格，也更加类似学术论文，而不是考虑阅读的容易（即便他们考虑到这个问题，由于他们的背景，也很难跟我们这些人持一个用词体系）。
其实如果大家仔细研究当初最早进入国内的翻译版本，都是教授牵头，并且亲自动笔，但是可阅读性并不好，而且词汇系统用我们的观点看来，也比较怪异，大概的原因都在这里。对这种情况，我们只能说是我们这些读者跟翻译者不配套。而如果我们真的想去深入研究这些东西，理解这些前辈的思想，也是很有必要的。
但是就实际情况看，很多人仅仅是为了快速入门，快速应用，本就没有研究特别是深入研究的意图。这种书和这些译者，对他们就价值不大。

翻译的不好，不需要找原因。
面向的群体看不懂说明书翻译的确实差。

孤芳自赏型的译者。
对读者不够负责