PM的工作日常大概来说是三类：需求分析，产品设计，项目跟进。这三部分是统一的，依次进行的。单独的每项技能修炼皆需要一番功夫，但要知道，他们之前的转化，才是最关键，最困难的部分：

1如何将你提取出的需求转化为设计合理的产品原型；

2如何将你设计的产品原型高效的交付给技术，让技术完美实现。

想想便知，这三部分之间，有着巨大的鸿沟，而本书讲的UML,就是架在这些鸿沟上的桥梁。

好吧，卖了这么多关子，是时候讲解一下UML到底是什么鬼了：

UML，即Unified modeling Language(统一建模语言）。它定义了一些建模所需要的基本元素，也定义了这些元素互相之间关系的规则，以及如果运用元素和规则来绘制图形，以建立模型反映现实世界。

若上面这段定义比较抽象，可以作如下比喻：

建模就像写文章，UML的元素，规则就像我文章中的文字和语法。

————————什么是UML————————

关于建模

1.怎么建？

确定你建立这个模型的目的是什么，即选择抽象角度。打个比喻，城市是你面对的问题领域，而摄像机位就是抽象角度，你从不同角度看到的事物不同。

实例化一下：做需求时，我们不要刚开始就钻进细节，搞清业务如何一步步完成，我们首先要弄清楚有多少业务的参与者？每个参与者目标是什么？参与者的目标就是抽象角度。

2.模是什么？

模就是   “人”，“事”，“物”，“规则”。

静态的物+特定的条件（规则）+特定的动作（参与者驱动）=特定的场景（事件）。

人做事，做事产生物，规则限制人事物，人驱动系统，事体现过程，物记录结果，规则则是控制。

3.建模的相关：

3.1用例驱动：

整个软件生产过程就是用例驱动的。

简单来讲：软件生产的过程是“以人为本”的，一但用例被实现了，问题领域也就解决了。

3.2抽象层次：

抽象层次的不同决定着用例粒度的不同。

抽象层次越高，信息量越少（多数信息被封装or屏蔽），相对的越容易被理解。但过高又会产生信息量不足的问题，让人产生疑惑。所以，在合适的时候采用适当的抽象层次十分重要。

3.3视图

视图用于组织UML元素，表达模型的某一方面含义。

图形在表达精准信息方面远胜于文字。在建模工作中，会有各种各样的干系人，从他们视角出发的视图更容易被他们理解。不同的视图展现这不同的视角，这些视图从不同的方面描述着一个软件的结构和组成，所有视图的集合表达一个软件的完整含义。

UML的元素

参与者，用例，边界，关系，包，分析类，设计类。

1参与者（主角）

参与者在建模过程是处于核心地位，它一定处于边界之外。边界之类的被称为“业务工人”。         

参与者的实例就是“用户”。它一定是直接并主动的向系统发出动作并获得反馈。

2用例

一个用例=     <   参与者，前置条件，{场景}，后置条件（结果）    >

用例和功能的区别：功能是用事物角度出发的，而用例是从参与者角度出发的，功能是脱离使用者的愿望存在的。功能是孤立的，而用例是一个系统性的工作。

3.边界

边界和封装概念师出同源，在面向对象中，外界只能通过这个边界来认识对象，不能进入跨过边界，进入对象内部。边界决定着抽象的层次，也就是它决定着分析粒度的大小。

4.包

包是一种容器，它将信息分类，形成逻辑单元。好的分包可以让产品具有高内聚，低耦合的性质。

5.关系

关联关系，依赖关系，扩展关系，包含关系，实现关系，精化关系，聚合关系，组合关系，等等。这一部分是简单的定义，看书即可。

UML的视图

1.用例图

用例是系统中的一个可以描述参与者与系统直接交互作用的功能单元，用例图的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。

2类图

UML语言中的类是对应用领域或应用解决方案中概念的描述。类图以类为中心组织，类图中国的其他元素或属于某个类，或与类相关联。

3活动图

活动状态代表了一个活动，即一个工作流步骤或一个操作的执行。活动图由多个动作状态组成，当一个动作完成后，动作状态将会改变，转换为一个新的状态。

4状态图

UML语言中的状态图是对类描述的补充，它用于显示类的对象可能具备的所有状态，以及引起状态改变的事件。实际建模时，并不需要为所有的类都绘制状态图，仅对那些具有多个明确状态并且这些状态会影响和改变其行为的类才有绘制状态图的必要

5时序图

时序图显示多个对象间的动作协作，重点是显示对象之间发送的消息的时间顺序。

6协作图

UML语言中的协作图是对在一次交互中有意义的对象和对象间的链建模。除了显示消息的交互以外，协作图也显示对象以及它们之间的关系。时序图和协作图都可以表示各对象间的交互关系，但它们的侧重点不同

UML的模型

1用例模型

用例模型即为需求工作流程的结果，可当做分析设计工作流程以及测试工作流程的输入使用。

2领域模型

领域模型，是对问题领域中某个我们关心的问题来建立对象模型。它是“不完整”的，因为领域模型不包括使用者的信息和使用过程

3分析模型

分析模型是高层次的系统视图，它是转化为设计模型的必要前提。它是mvc模式（model,view,controller）的经典应用。在使用分析模型时要注意：减少依赖，分离职责，结构优化（控制耦合度）

4设计模型

设计模型，即详细设计，它需要考虑实现语言，架构，框架，规范等。

———————工作中如何应用UML——————

准备工作

了解问题领域

1将问题领域中的所有问题做初步了解，进行简单划分。

2.将所有参与者的业务期望做整理。

做好用户群分析

对软件的所有用户进行分类，每一类创造一个用户模型，对用户模型进行说明和整理其期望。

期望优先级划分

每一列代表一个用户群，每一行代表一个期望，构建优先级矩阵。

用户访谈技巧

1.站在对方角度去思考问题。

2.在双方达成默契之前，不要急于深入业务细节，先就一些大框框进行沟通，借此习惯和了解对方的沟通方式。

3.做到了解对方的专业背景，用相对专业的术语聊天，让对方感兴趣。

4.记录每次谈话结果，用自己的理解附属对方的话，形成文档让对方阅读。

获取需求

定义边界

定义边界是确定分析的起点。因为主角。边界。用例是相生相灭的。只要定义了边界，就能定义主角，自然就可以发现用例。

发现主角

直接与系统交互的涉众才能被称为主角。

获取用例

用户对系统有什么期望，用户打算在这个系统做什么事情，用户做这些事情目的是什么。用户做完这些事情想要个什么样的结果。即 需求-角色-场景-路径。

业务建模

用活动图描述业务用例场景。分析参与者的职责。

用时序图描述业务用例场景。强调业务的执行过程。

用协作图描述业务用例场景。分析参与者之间的交互。

提炼产品规则

产品的规则就相当于游戏的玩法，你需要定义清楚产品是什么，它是如何运作的，需要设计你希望用户应该如何去使用这个功能/产品，他们可以做什么，他们应该做什么，哪些不鼓励做，哪些不能做。在定义产品规则时，我们可以使用由主到次的方法来设计。

例如：产品的主线是让用户从A到B，为此设计出核心路径，为了满足这个过程中其他需求，再设计辅助路径，为了保证用户不走偏，再设计限制等。

另外，我们还需要定义产品原则。产品原则是指产品团队达成的一些共识，当我们开始具体的产品设计时都应该能够体现产品的原则。产品原则不局限于某一个范畴，它可以是跟产品有关的方方面面（例如：优先照顾买家体验，重点保证移动场景下的产品体验，产品应该是令人愉快的，尊重用户隐私，把发送广告的用户赶尽杀绝等）。

系统设计

设计模型

对于功能实现模式雷同的部分，我们设计好一个可扩展模式后便可以举一反三的应用到其他的类似功能点。

对于特殊的功能，我们要针对其进行详尽的设计。

接口设计

对类似对象设计接口：运用adapter模式

对软件各层次设计接口：运用facede模式。

设计模式有很多种，可以帮我们对软件进行解耦，提高软件的质量。

包设计

包设计遵循“自顶向下”，“职能集中”，“互不交叉”原则