人治–>法治–>德治（无为而治），大公司多为第二种：法治。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，寻找合适自己的工具吧，原则很简单：把事情说清楚！
