|
在面向对象的需求分析方法中，UML的地位是不容动摇的。
在和很多做产品做需求的小伙伴聊过后发现大家对UML的了解非常的少，在之前组织的需求分析实战中也发现了这一点。
反而对程序员GG来说，UML的普及率会更高一些。
有的人会说，我不用UML，需求分析的也挺好的啊，产品做的也没什么问题啊。
如果你正面临着下面这些问题，我建议你看一下这篇文，并且学习并应用UML。
我对自己的产品功能了如指掌，但是却无法总结出所有的系统角色特征
测试写的用例我提不出意见，但是测试结束后我却经常发现之前没有想到过的用例
在做原型及需求文档时，有时候会遗漏某个功能或者场景
与程序猿经常无法沟通，我觉得自己写的文档、画的原型已经很清晰了，但是他们就是看不懂
我完全不知道产品中的业务主流程在执行的过程中会有哪些对象参与
什么是UML？
统一建模语言（UML，UnifiedModelingLanguage）是面向对象软件的标准化建模语言。UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。在软件无线电系统的开发过程中，统一建模语言可以在整个设计周期中使用，帮助设计者缩短设计时间，减少改进的成本，使软硬件分割最优。
简而言之就是一种语言，一种规范。
就好像音乐用五线谱、简谱表达，数学用公式表达，需求模型用UML来表达。
曾经有的人希望在需求阶段将UML做的很规范，并可以由此直接生成代码。就像现在的原型可以直接生成页面代码一样。
现在已经有很多工具可以做到这些了，虽然生成的代码不是那么的让人满意。
但是不排除未来掌握UML和业务的人员直接跳过程序员编写软件产品。
UML带给需求分析什么？
以小婧使用UML的经验来看，UML会给需求分析及需求相关人员提供更清晰、明确的目标。
我经常说，用UML重点是要充分应用它面向对象的分析方法。
也就是在做业务分析的时候，将信息抽象成对象进行分析，可以使得自己避开“干扰”信息，抓住“主线”。
你会对你的解决方案更加有信心，知道哪些地方存在改善的空间，会给用户带来什么价值。
如果发生需求变更，你也会很清晰的识别出影响点。
你设计出来的产品和业务流程会更加连贯、合理、有逻辑性，模块及功能之间的耦合关联也非常清晰。
就好像你看蜘蛛网仿佛毫无章法，但是仔细看来却是一件完美的艺术品。
UML适用于哪些阶段？
我们从UML的定义也可以看出，UML主要是服务于设计的。在需求分析阶段，我们如果能很好的使用UML，将会为代码设计提供很好的支持。
UMLChina在《软件方法》一书中提出了一个概念叫核心工作流。使用核心工作流可实现“低成本制造好卖的产品”。
1 业务建模——组织要解决什么问题
做产品需求的人都知道，我们需要去找甲方的痛点也就是问题，如果我们的产品可以很好的解决问题，那么人家就愿意付钱，我们就能盈利。
而你的产品能带给用户什么价值，这个价值到底是否足够大到吸引用户来付费。你可以通过业务建模来进行分析。要知道引进一个软件系统，和招聘一名新员工没有本质的区别。我以前经常会被challenge的问题是：我为什么要买你们的系统，我用Excel也管的挺好的。
业务建模阶段思考的焦点是：组织内系统之间
推荐UML元素：用例图、类图、序列图
2需求——为了解决组织的问题，待开发系统应该提供什么功能和性能
这里强迫我们从“卖”的角度思考哪些是干系人在意的，哪些不是。
需求阶段思考的焦点是：系统边界
推荐的UML元素：用例图、文本
3分析——为了提供功能，系统内部应该有什么样的核心机制
在用户的整个业务流程中，你的产品是在哪个部分起什么作用的。大部分的软件产品的作用就是取代人工，实现自动化。以前我们去餐馆点菜需要服务员拿个小单子来写你点了哪些菜，或者直接人脑记忆；付款的时候，老板要收集小单子或者记录在小本子上，以便休息的时候计算营业额。但是现在我们去吃饭，直接一个IPAD，菜单、点菜、消费记录全部自动化。装在IPAD里的系统是通过分析得到的。
在分解阶段思考的焦点是：系统内核心域
推荐的UML元素：类图、序列图、状态机图
4设计——试了提供性能，系统的核心机制如何选定技术实现
主要聚焦：系统内各域之间
UML：不画，代码即设计
从上面几个阶段我们可以看出，对于我们产品需求人员需要掌握的UML其实只有那么几种：用例图、序列图、类图、状态图。
有人会问，为什么没有活动图（流程图）？
我觉得如果你和用户或者业务人员沟通，可以使用活动图、但是如果你是为研发、设计服务，建议使用序列图。因为序列图会强迫你去思考所有的动作背后的目的。
怎么画UML？
关于各种图的具体画法我觉得大家去问度娘会得到比我这有限篇幅更详细的信息。
而针对用例图，我最近看到一种说法，觉得很有意思，在本文中做一个分享。
潘加宇老师在《软件方法》中提到了两种用例图：业务用例图和系统用例图。
之前有小伙伴说，测试和开发看不懂他画的用例图，很苦恼。我仔细看了下，确实是有些表述不清。因为他把业务用例图和系统用例图弄在一起了。
业务用例图
业务用例图主要是用在业务建模的阶段，目的是从甲方的角度来定位系统应该提供的价值。
所以业务用例图研究的对象是甲方组织。甲方的组织里面包括哪些角色，哪些软件系统，哪些部门？而我们的系统将承担这些对象中的哪些对象的大部分职责？
另外一方面，业务用例图的Actor执行者是业务执行者，即组织外与组织交互的人群或组织。
比如你的甲方是某商业银行，其Actor是储户、企业用户、人民银行。研究的是他们将会与商业银行产品什么用例。
系统用例图
系统用例图主要使用在需求阶段，我们其实最常用的是系统用例图。系统用例图的主要研究对象是系统，也就是我们待开发的软件系统。
系统用例图的执行者是在系统外与系统发生功能性交互的其他系统。所以重点在于这个执行者与系统发生功能性交互。
比如前些日子小婧的身份证过期了去办身份证（我又暴露年龄了）。身份证办理系统的执行者包括：办证人员、数码相机、指纹采集仪。这里要注意的是我并不是系统的执行者，至少在这个非自助的系统中，我不是。
写在最后
在实际的产品需求分析过程中使用UML，不论对你的产品还是你自己而言都会收益颇多。
但是和所有的方法一样，在学习和实践一种新的方法时会面临很多的挑战，也会有很多的问题。
单纯就从UML的角度来说，我觉得有这样几个方法可以来学习实践：
对自己产品进行梳理，尝试用UML的用例图、序列图（时序图）绘制现有系统业务，并与开发人员讨论。通常来说，开发对UML的了解会更深入，这可能是和现在常见的开发语言，比如C系列、Java等也是面向对象的语言有关。
|
