UML建模在产品经理工作中的应用.docVIP

UML建模在产品经理工作中的应用 / UML为什么能在产品工作中应用？能解决产品经理工作上的哪些痛点？ 一、先看图例 是否在工作中见过这些图呢？ 是否在偏技术型的文档中见过这些图？ 1）这是一张“用户——角色——权限”关联关系图，表达了“表”与“表”之间的关系；属于类图。 2）这是一张拼团产品中“用户——团——权益”的对应关系图，以及每个业务概念的属性字段与操作；同样属于类图。 3）这是一张表达相对独立的功能间的关系图，表达了一个功能模块的输入与输出，及与另一个功能模块间的供需关系；属于构件图。 4）这是一张表达服务器、数据库、使用网络地域范围的部署图。 5）这是一张以“员工申请立项，三个领导审批”事件为主的流程图。 6）这是上图中“审批单”的状态变化图，学名：状态机图。表达了审批单在不同用户的操作下的触发的状态变化。 7）这是一张用户在注册账户过程中“用户——前端界面——后端系统——数据库”之间的交互及信息传递图，学名顺序图，主要用来表达复杂的交互、系统与系统之间的交互。 8）这是一张表达了某系统范围内三种角色各自可操作的用例，以及角色与角色之间的继承关系，属于用例图。 看完上面7种图，感觉流程图最熟悉了，其他的几种图似曾相识。那么，其他的图有什么作用呢？先看看我们工作中的痛点。 二、产品经理工作中的痛点 业务分析时，范围不清晰、逻辑不严谨，或自己的方案超出技术边界。 刚接手一个产品时，弄不清一个概念与另一个概念的对应关系、关联关系，同事也不能系统地给你讲述全面。 需求文档中，文字描述很清楚，但程序员搞不清楚也不爱看文字。 经常听到程序员说：我们没有这张表、没有这个字段，这个表不能再加字段了。 和程序员讨论最多的也是：如果用户这样操作了该显示什么状态？该怎么提示？ 怎么才能在避免这些问题呢—— 利用UML作为沟通语言、利用UML图作为思考工具。 三、UML是什么 1. What：是什么？ UML，Unified Modeling Language，统一建模语言。 建模的输出主要是图的形式，分为两类，一种是结构型图、一种是行为型图。 我们常画的流程图就是一种行为型的UML。 2. Who：谁来用？ 产品经理（需求分析时可画出简易版的UML图）； 程序员（学技术的都能看懂ULM，甚至可以和程序员一起完善UML）。 3. When：产品经理什么时候用到UML？ 业务分析提炼需求、挖掘需求时； 与技术人员交流时。 4. Where：用在什么地方？ 需求文档。 5. Why：为什么要用？ 作为一种工具可以帮助产品经理完整无遗漏地梳理需求。 作为一种语言，可以清晰易懂，与技术人员顺畅沟通。 作为以图形为主的语言，更形象易懂。 四、产品工作中常用的UML有哪些？ 最常用的是：流程图、状态机图、顺序图、用例图、类图。 五、各类UML图的语法 学习网站：/oobject/OObject.asp 学习书籍：《UML大战需求分析》，作者：火球 1. 类图 1）什么是类 类是面向对象的，里面有属性、有操作。通俗讲一个类就是一个业务概念、就是一张表。 在表达类与类之间关系时，一般隐藏属性和操作，只用类名代表一个类。 2）语法 在类图的表达中，一定要注意箭头的区别。 ① 关联关系 a）用直线相连接，代表两个类之间有关联关系，当不确定具体关系时，均先用直线链接；直线两端的数字代表对应的数量关系，如下： 代表1个G可以0～3个M，如一个拼团除了团长可以有0～3个团员。 b）导航关系 代表由A可以导航到B，通俗讲是由A可以找到B，如：在拼团名单中可以找到参与用户。 ② 聚合关系，即弱包含关系 代表一个部门可以由多个员工组成，如果部门没了，员工可继续存在。 ③ 组合关系，即强包含关系 代表一个部门可以由多个员工组成，如果部门没了，员工也就没了。 ④ 泛化关系 代表A泛化为B，A具备B的特点，也有自己的特有特点，如香蕉泛化为水果。 ⑤ 依赖关系 代表A依赖于B，对于某件事，A需要B的协助才能完成。 3）类图建模的步骤 识别类，先记下类的名称； 识别出类的主要属性、操作； 描绘出类之间的关系； 对各类进行分析、抽象、整理。 这个图是网上找的，箭头使用不是很规范。切记要使用类图语法中的箭头。 2. 构件图 1）什么是构件？ 2）语法 ① 一个构件符号如下。服务接口像一个手一个拳头，可联系记忆为：伸手要服务，出拳打人服务。 ② 两个构件之间的对接如下： ③ 示例如下： 3. 部署图 产品经理一般需要搞清楚： 服务器部署在哪里？数据库放在哪里？ 是互联网还是局域网？ 4. 活动图（流程图） 活动图比较常用，不做太多讲述，但在画图时一定要规范，如每个活动用“主动宾”的表达方式，当采用泳道图，有角色泳道时，可以省略“主语”。 1）语法 2）绘制步骤 明确该流程要表达怎么样的