UML基础、案例与应用
2002-6-1
人民邮电出版社
Joseph Schmuller
294
463000
李虎
无
本书教读者循序渐进地、系统地学习UML基础知识和应用技术。全书分为三部分24章。第一部分“基础知识”包括第1章到第15章，主要是介绍UML语言的基础知识以及面向对象的概念和思想，还简单介绍了UML在开发过程的应用方法。第二部分“学习案例”包括第16章到第22章，结合实例详细分析了UML的应用方法与技巧，还介绍了UML在热点领域设计模式中的应用。第三部分“高级应用”包括最后两章，先是运用UML来描述设计模式和嵌入式系统，然后讨论UML在其他领域的应用前景。附录给出了每章的小测验答案，简单介绍了几种UML建模工具，还对常用UML图进行了总结。 本书适用于从事面向对象软件开发的软件工程人员，也特别适合UML的初中级学习者。
第一部分 基础知识 第1章 UML简介 第2章 理解面向对象 第3章 运用面向对象思想 第4章 关系 第5章 聚集、组成、接口和实现 第6章 介绍用例 第7章 用例图 第8章 状态图 第9章 顺序图 第10章 协作图 第11章 活动图 第12章 构件图 第13章 部署图 第14章 理解UML语言基础 第15章 在开发过程中运用UML第二部分 学习案例 第16章 学习案例介绍 第17章 领域分析 第18章 收集系统需求 第19章 开发用例 第20章 交互和状态变化 第21章 设计外观、感觉和部署 第22章 理解设计模式第三部分 高级应用 第23章 嵌入式系统建模 第24章 描绘UML的未来 附 录
无
贴不了图，原文在 http://iamsujie.com/7000/7011/，欢迎大家来探讨相关话题
人治–>法治–>德治（无为而治），大公司多为第二种：法治。1和3外表很像，区别在于1无法，而3的法在每个人的心中而非纸上。这是产品和团队发展的必经阶段，我们的现状就是“1–>2”，开始规范化，正好有同学原来熟悉UML，所以大家也都开始学习一下。
UML就是统一建模语言，它试图将软件工程的过程给规范化，从产品设计的角度，我对它的简单理解就是用一系列的标准图把需求分析的过程串起来，充分体现了“字不如表，表不如图”的原则，我以单个用例的粒度为界，把相关的图为两个层面。
上层的图中，用例是最小单位，不涉及用例内部，主要有：
Ø 类图：感觉有点像实体关系图（ERD，更接近现实世界的对象，类图更接近技术实现的对象），描述系统中出现的各个对象之间的关系，以及和外部系统的关系。这是对业务领域的描述，一个外行看了以后就应该了解系统是做哪方面事情的。还是用我最喜欢的“小明去饭店”为例，画个图练练。
Ø 用例图：各个用例之间的关系（include/extend）、用例包、用例和actor之间的关系（将一组相关用例打包成一个模块，画成“用例包”）。描述这个系统具体可以做哪些事情。
Ø 状态图：表达系统里实体的状态转换，这也是贯穿多个用例的。例图里描述的就是“小明”的状态转换。
上层的图包装一下就可以生成整个产品最顶级的业务逻辑图，描述整个系统的业务层面的事情，用于商业演示。业务逻辑图的画法现在团队内也没有统一的意见，比较随意，表达清楚就行，这也意味着最难画。
现在说说下层的图，描述的是一个用例内部的事务（用例内部不一定是“单个用例”内部，也可能有用例之间的关系），主要有：
Ø 时序图（顺序图）：描述事情变化在时间维度上的先后顺序，善于表达对象（比如多个页面之间）的交互。玩的好可以完全替代UC中对流程的文字表述。
Ø 活动图（比较接近传统意义上的流程图）：描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况。
Ø 协作图：表达不同对象之间是怎么互相影响的，这个图团队里用到的不多，就不画了，理论上他和时序图是可以等价转换的，时序图关注交互在时间上的步骤，协作图关注交互过程中各个对象间的关系。
这些图我们都是用Rational Rose画的，它最好的一个点是可以在不同层次间的图穿透，比如从用例包穿透看到用例图，再穿透进某个用例看活动图，再穿透进活动图的某一步看具体的时序图。
很多时候多种图都可以描述同一件事情，只是从不同的视角去表达一个系统，选用哪个关键是看针对特定的系统，从哪个角度来描述更容易让受众理解。另外还有表述软件实施的构件图、描述硬件结构的部署图，暂时用处不大，遵循性价比的原则直接跳过了。
融入了UML标准图元素以后，一个功能模块的PRD大约就是这样的：文档说明、类图+用例图；一个个的UC，UC里包含时序图、活动图等等。
感慨一下Rational Rose真的太强大（建立了整个软件工程的RUP，Rational Unified Process，包括分析、设计、编码、测试、部署等等一切），我想绝大多数公司应该找一个轻一点的工具，谁好的方案？
最后，再强调，工具是给人用的，如果团队里其他成员都看不懂了，学习成本太高，那一定不要强推UML，寻找合适自己的工具吧，原则很简单：把事情说清楚！