产品经理从0-1 ：UML建模 之 用例 02

Posted 2021-04-02 圆珠笔 LenLee

   

     在写这篇文章之前，让我说一句晚到的"新年快乐"，最近在忙着玩自己创业的事情，加上很多原因需要重新找工作，再加上过牛年，勤劳的牛说让我逆时转一圈，于是也就偷了懒，这是我需要改的地方。

1、 建模 ---  用例

    我们还是接着UML建模来说事儿，既然我们要做一款实用且能用的产品，不管产品的形态是PC、APP还是系统，总之，’道可道、非常道‘这个观点永远不会错，作为道家的信仰者，我始终坚信：虽然这个事件很复杂，但是殊途同归，回归到本质上还是以人为中心，不管他的业务逻辑有多复杂，不论哪个行业不论什么业务，其本质无非是由人、事、物构成的，人是一切构成的中心，同时遵守一定的规则。那么建模的过程关键就是弄明白：有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，这就是抽象的过程。

创建用户用例，描述人物画像，是我们解决现实世界问题的一种常用手段，用计算机话来说就是建模，，找出解决问题的最佳方案，是指通过客观事物建立的一种抽象的方法。为了转化需求，理解需求，得到能落地的产物，我们有方式方法来做这些事儿；

2、 用例概念

在建模采用了用例 userCase 表示业务目标，要完成一个什么参与者做什么得到什么。这就是需求的转化，将所需要的现实信息转化成业务模型。

个人解释：就是一件事情，如果要完成这件事情，需要做一系列的活动，而这件事情可以有很多不同的办法和步骤，可能会遇到各种各样的情况，那么这件事情就有很多个情况构成，一个场景就是一个用例的实例。

比如：你要吃饭，那么这就需要蒸米饭和炒菜，那么这就是两个用例，而蒸米饭你需要电饭煲或者电饭锅，这就是一个大场景下的小场景，在整个过程中会有很多的情况，比如洗米、倒水、水倒多了等等，但是这些都是需要前置条件的，比如要蒸米饭就得有米和电饭煲，也就是说一个用例会有：参与者、前置条件、场景、结果构成。

用例的作用：

一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达到了参与者的一个愿望，当所有的愿望都能用用例来表达，那么这个系统就被确定下来了，捕捉功能性需求，这就是用例的作用；

     每个用例是相对独立的，也就是说：用例从功能上来说是完备的，完成了参与者的目的,也就是用例总会有一个发起者，必须有一个动作，有一个受体，比如人喝水，而不是人水或者人喝；一个用例就是一个需求单元、分析单元、一旦确定了用例，那么就有了系统的框架。可以围绕这个框架展开发；

用例的例子：

    举个例子，李老师去超市买打火机，那么挑选物品是一个场景，此场景下李老师关注的是打火机的价格？样式？还是品牌，那么对于超市而言就需要做好调研，将不同的打火机归类，按照产品定位的策略，让李老师第一眼就选到该品牌符合李老师的打火机。

     买完打火机了，李老师不可能拿着打火机就跑，会给他腿打折，得需要去结账，那这就是第二个场景，在此场景下，是什么流程？参与者都有谁，达成一个什么样的愿望，这个愿望使得参与者都满意。

就算李老师买完打火机了，但同样的这是现实中的购物，但在电商平台中是应该怎么去实现，这样的用例颗度有多大呢？

用例的颗粒度：

     我们用什么来确定这个用例的大小呢，比如购买商品，一个购买的动作就是一个用例呢？还是精确到如何选择不同型号的商品是一个用例呢？到低是一个大的用例合适还是分解成小用例合适呢？这个问题并没有准确的答案，

我认为是在每个阶段有不一样的粒度，在需求阶段应该是越大越好，能完整一整件事情为宜。即：一个用例可以完成一个完整的业务，可理解为一个用例描述一项完整的事件流为主，需要归纳和抽象出业务用力中的关键概念和模型。

而在设计阶段当然是越具体越好，查找商品、选择商品等等；这个阶段主要是为了能设计更好的系统或者产品，那么就应该很细致到一个界面或者一个界面流。比如：某人去图书馆，查询了书目，出示了借书证、管理员查看了他的借书记录、还书、到借书，这个过程中有很多用例，但是我们要以借书为目的的设计，而还书只是借书过程中的一个步骤。

用例的获取：

对于如何获取用例，这就得从需求说起，也就是参与者说起，要对自己的产品有一个大概的人物画像，有了特定的这一群人，我们可以对这个参者者(人物画像)需要做什么，也就是用户的痛点在哪里;了解他的痛点，那么这些需求从哪里来呢？这就是需求的收集：可以用用户访谈、问卷调查等等方式获得。(对于如何获取需求这里不再多说，请查看已有文章)

用例和功能的区别：

很多人认为一个用例就是一个功能，而这个仅仅是需求分析中的功能框图的翻版，很多人用用例来划分子系统、功能模块和功能点，而用例是从用户的角度出发的分析的过程；而功能是针对计算机说的，也就是：输入 -> 计算 –> 输出；

来看例子：

我们描述事物：这个事物是什么？ 这个事物能做什么？ 用户希望能用这个事物做什么？

大家都知道自行车：

1、 交通工具

2、 可以载人、轻便、快捷

3、 双脚蹬向前走，刹车、停

这是我们已知的事物，但是对未知的呢？比如：Viagra，刚开始是辉瑞公司研制的治疗心绞痛的药，但是现在是人尽皆知的伟哥，用来治疗ED，对于创造这种不存在的事物，最好的方式就是从用户的角度出发，描述希望这个事物用户能用他做什么，能获得什么。而软件产品恰恰就是我们不知道的事物，我们不能从结构观点去描述他，也不能用功能观点描述它，最好的观点就是从用户的观点描述。

很多软件产品在开发完成后客户并不满意，认为这不是他所要的东西，与其说是需求不清楚，还不如说是方法不对路，因为在一开始，收集需求人员就没有从使用者的观点出发描述系统，那么功能就肯定面目全非，虽然能做完，但是结果却是不尽人意。

我们要从用户的角度出发，描述这个事物使用者用它做什么？能获得什么？

因此：功能是脱离使用者的愿望而存在的，是鼓励存在的，给他一个输入，它给我一个输出。但使用者并不都是计算机高手，他们所说的功能仅仅是为了完成这个需求而做的一些工作。

说他们不一样的例子，你品、你细品

从功能角度出发：对电视的描述：能开关、可以调频道、可以调声音、可以显示画面，以上四者是独立的；从用例的角度出发：李坏要看电视节目的一个用例，完成这个用例，第一步打开开关、调到自己习惯的频道，如果音量不合适，可以调节音量；你给我品，品二者的区别，哪一个更为符合软件产品的设计；

好吧，你们暂且先品一下、细细品一下；可能品累了就休息一下吧，03 将说业务用例和怎么用UML用例。

每日鸡汤

       列子：“觉有八征，梦有六候”

                           

            

Hello！产品小伙伴们

(添加时请备注 地区+职业+姓名)