用例有什么用？如何正确使用它？让我们通过这篇文章来进一步了解它。
用例作为UML的重要组成部分，经常和类图、序列图、状态图、活动图等一起出现在各种产品设计开发文档中。然而用例图在实际使用UML图形化表达时显得有些别扭。不知道大家有没有这样的感觉，我们的设计文档中对于用例的要求往往只是走个过场，要么草草地画几张，要么根本就没画。那么用例真的一无是处了吗？
谁将使用用例？
相比于Use case，产品经理更喜欢用界面原型来表达用户与产品的交互，这也不足为奇。想想看，最早的Use case概念是Ivar Jacobson在1967年定义爱立信AXE系统架构时提出的，毕竟那时候人机交互还是非常难懂的，半个世纪过去了，现在的设计理念崇尚简洁、直观、所见即所得的模式。
架构师和开发工程师喜欢使用用例吗？答案是否定的，他们更喜欢使用序列图、活动图、状态图等更加详细、系统化、参数化的设计方法来表达系统状态、数据变化和行为，用类图来表达信息的静态结构。
测试工程师会用吗？不会，会直接根据功能设计和接口原型写测试用例。测试用例和用例不一样，测试用例更系统化，更强调严谨的输入输出定义。
谁会用Use case呢？哈哈，看完上面的分析你肯定觉得Use case没什么用，可以彻底抛弃了。别着急，我还没说完呢。这不是上面几个角色的错，也不是说Use case完全没用，只是我们经常把Use case用在错误的地方。其实Use case是一个业务分析的过程，而不是设计的过程，准确的说，Use case是一个衔接业务分析和系统设计的过程。
那么用例有什么用呢？
在软件工程中，我们通常将软件开发过程分为分析、设计、开发、测试四个阶段。但在当前以电商经济为主导的互联网产品开发体系中，我们确实很容易忽视软件分析过程。这并不是说电商系统不需要分析，而是因为这个行业同质化产品太多，借鉴、抄袭效率更高。那谁还愿意认真分析商业的本质呢？
用例被忽视的另一个原因是对敏捷开发的一些误解。敏捷开发提倡快速交付，用客户来测试设计，用市场来检验产品的成败。这很容易让我们误以为软件或者它所服务的行业的业务分析已经不再必要。其实，分析-设计-开发-测试的过程就像语言中的主谓宾结构。无论你说话的速度有多快，使用什么花哨的修辞手法，基本的结构是不会变的。
敏捷研发体系其实就是改变了传统的整个系统分析完成后才进入设计开发阶段的方式：单一业务流程场景分析到设计到开发到测试。至于单一业务流程场景的粒度，可以参考我之前的文章：《电商初期建设的7个优先流程（上）》。
如果你认同以上的观点，那我们继续聊聊Use case有什么用，怎么用？本文就不讲解如何画UML Use case图了，因为网上有太多免费的介绍，甚至不用买书就能看懂。我们的重点是讲解如何使用Use case，让它的功能发挥出来。
前面我提到过，Use case 是衔接业务分析和系统设计的一个过程。在软件工程中，Use case 的常用定义是：Use case 是在开发新系统或软件修改时，用于捕获潜在需求的一种技术。其实，如果仔细理解定义，就会明白“捕获潜在需求”其实是一个系统的分析过程。Use case 最适合对抽象的业务流程活动进行进一步分解。
接下来我们将通过讨论Use case与业务流程、界面原型、系统设计的关系，明确Use case的定位和作用。
1.用例与业务流程分析的关系
要讲用例，首先要讲什么是业务流程，因为它们是相辅相成的。维基百科对业务流程的定义是：为特定客户或客户群提供特定服务或产品（服务于特定目标）的一组相关的、结构化的活动或任务。
这里用Business process来代替Business Flowing，以区别于workFlow。WorkFlow是一种更加系统、严谨、技术性的活动描述。Business process与系统、技术无关，有时纯粹描述手工的业务流程，是真正描述业务需求的方式。Business process分析和Use case分析的侧重点不同，Business process采用基于流程的方式来表达业务发展的连续性和方向性；而Use case则侧重于单个业务活动，进行面向对象的解构分析。
比如我在《初次电商的7个优先流程（上）》中提到过：请求到答复的流程画出来是：
请求答复
请求到答复流程是一个业务流程，是企业运营体系中几个业务流程之一，由于它符合从客户发起到客户满意的端到端原则，所以我们可以单独分析这个流程，这也符合敏捷理论的快速响应、闭环分析、最小值开发理念。
用例的作用是通过人机交互、以用户为中心的方式，分析业务流程中业务活动的物理场景（如上图中的咨询、判断销售前景、匹配产品、提供销售建议等），从而获得该活动的详细功能需求。没错，用例是形成功能需求的关键，因此是需求分析/系统分析的工具。所以如果你已经有了系统功能，再做用例分析就会发现用例完全是多余的。这里我重申一下，用例不是设计工具，而是业务分析工具。
为了证明这一点，我们可以看一下UML图的主要结构：
用例主要结构
从上图中我们可以看到Use case是由Actor、case、relation、system/module组成，而他们之间的关系主要分为：包含、泛化、使用、扩展。怎么样？看到这些图示之后，你有没有想：这不是在用面向对象的系统思维去分析和解释业务活动吗？没错，当我们在处理不熟悉的需求或者业务活动的时候，我们需要把单纯的业务需求和流程转化为面向对象思维的系统需求，就需要做Use case分析了。这时候还没有具体的功能，没有类模型，也没有数据模型，最多只是一个泛化的系统或者模块。
2.用例与接口原型的关系
在做Use case分析的时候，可能已经有了接口原型（因为现在的设计潮流提倡接口原型和需求分析同步，接口原型也是确认客户需求的工具），但一定不要把接口需求表达在Use case里或者从接口需求反向推导出Use case，因为Use case的分析重点是分析业务流程的本质（用5W1H分析法），有的可能有接口，有的可能没有，有的是抽象实体，有的则是实例实体。而接口原型的重点是用显性、可视化的表达手段来表达业务流程分析的结果。
比如上图：用户登录，泛化了两种案例（实体）：昵称登录、手机号登录。在界面设计中，可能是一个界面（通用登录界面），也可能是两个界面（交互设计师会有很多理由告诉你哪种设计更好，但一般都不是由用户业务可能性分析驱动的，因为交互设计师不喜欢研究业务流程，哈哈！交互设计师别打我！）。如果我们用界面设计来逆向推导Use case，就很容易限制我们业务拓展的可能性。在上面的例子中，根据业务流程抽象、泛化的分析结果，还可以得到扫码登录的案例。所以，Use case和界面原型是互相验证的，而不是互相替代的。Use case的另一个作用就是分析业务可能性。
3.用例与系统设计的关系
这里讨论的系统设计涵盖了领域驱动设计中的模块设计、类设计、时序设计、系统活动设计、信息模型设计等常见的UML过程。用例分析除了可以生成功能需求、提供业务可能性分析外，还可以为后续的系统设计提供结构化设计和行为设计的第一手资料，因为整个分析过程采用了系统的面向对象分析方法。
因此，用例提供了将客户需求用系统语言翻译出来的能力，编写或绘制用例的人必须是业务分析能力和系统思维能力的结合体，用例是业务流程分析与系统设计的关键环节，用例的好坏直接关系到业务实现的可能性以及能否在系统功能中体现出来。
要做出好的用例，产品经理要有足够的系统性思维，架构师要有足够的业务流程分析思维，但这是目前互联网研发体系中比较薄弱的环节。在一些大型IT公司，产品经理和架构师之间其实还有一个角色：系统分析师或者业务架构师。只是因为产品经理这个角色在行业中正在崛起，有逐渐取代的趋势，但是其实际工作内容很容易被遗忘。所以如果你的公司看重业务分析能力，要么要求产品经理有系统性分析思维，架构师有业务流程分析思维，要么设置系统分析师和业务架构师的角色。这样才能真正把行业中的业务需求挖掘出来，转化并延伸成优质的产品。
我们应该怎么做用例？
确定用例的分析粒度其实是整个分析过程中最麻烦的部分，也是最容易被忽略的部分。被忽略的结果就是我们选择的用例既不具有代表性，也不连贯（承担业务流程分析），更不全面。一旦用例不能提供详细完整的功能需求和系统设计所需的结构和行为分析，用例就变成了无用的正式文档。
1.首先需要确定用例表达的粒度
用例是衔接业务分析与系统设计的一个过程，因此，用例的定义一定不能基于经验、孤立的设定、或者直接凭空而来，必须遵循业务分析的连续性。从业务流程到用例的分析就是这种连续性，用例的粒度定义可以设置在业务流程中的业务活动上。注意：用例的设置依据一定是业务流程中的活动，而不是接口结构。
订单确认
以《电商初期搭建七大优先流程（上）》中的订单到确认为例，我们需要从业务流程中的业务活动来建立Use case的分析粒度，即需要对下订单、计算费用、分解订单、发货、评估跟踪、确认完成这几个活动建立Use case描述。
这里需要指出的是，订单到确认只是一个抽象的业务流程，由于行业的差异性和复杂性，一个业务活动可能进一步分解成更多的业务活动。比如“分解一个订单”会分解成“分解一个产品订单、分解一个服务订单、分解一个资源订单”。请注意，这里的业务活动不是指系统具体的操作步骤，所以不要将业务活动分解成增删改插查询等具体的系统操作，因为这些操作是基于系统实现的，而不是业务分析的。
之所以把Use case构建在业务活动之上，是因为我们看重业务活动不受系统限制、技术约束的特点，业务活动要展现的是业务发展的可能性而不是具体的系统实现，Use case的粒度也是一样的。
2. 其次，有了Use case这个粒度，我们该如何生成Use case呢？下面我来介绍一下生成Use case的方法
我们需要对每一个Use case提供一份脚本描述。描述应该简明扼要，基本句型符合5W1H模型：时间、地点、谁、什么、如何、为什么。最终影响Use case的变量需要由系统分析师、业务架构师或产品经理根据业务特点来决定。
以订单确认流程中“发布订单”业务活动为例，我们建立如下用例分析模型：
用例分析模型
这是最简单有效的用例生成工具。首先业务架构师定义并选择能够影响业务活动发生可能性的维度，可以参考5W1H方法，图中提到的“时间间隔”、“客户类型”、“渠道类型”、“订购方式”、“产品类型”、“触发条件”只是我举例的维度，大家可以根据自己行业的业务特点定义自己的维度。定义维度的重点在于找到案例的差异性，如果维度没有差异，可以直接丢弃结构化系统分析工具，比如上午和下午发订单的活动没有差异，就可以忽略。其次需要填写相关的维度参数，可能是某个类型，也可能是某个具体的实例。最后对这些维度参数进行笛卡尔积运算，就可以得到最直接的案例。
我们大多数人在生成用例时都缺乏方法，无论是凭经验还是看界面原型，都很难保证不遗漏我们分析的业务可能性。所以我建议大家试试上面的方法。当然，看到432个案例你会抓狂的。什么，这么多？其实这432个案例只是业务可能性案例。你可以根据自己行业的业务特点，用排除法轻松排除不可能、无效、无所谓的用例。实际用例可以控制在两位数以内。
可能剩下的就是：“晚上，一位新客户接受了平台推荐的商品，通过对比分析商品，在网上自营渠道订购了家电。”这就是Use case的脚本。基于这个脚本，接下来就可以画出Use case图，分析业务的功能需求，结构模型和行为模型的草稿，以及业务可能性。这里就不描述画Use case UML图的过程了，大家可以参考UML Use case文档。
3.最后我想澄清一个业界有争议的关于用例的概念。
业界对Use Case有两种不同的观点，一种观点认为Use Case是抽象视图，往往不需要携带具体的业务参数；另一种观点认为Use Case是实例，是参数化的视图。这两种观点都有各自的道理，前提是，在与Use Case的关联分析中包含业务流程分析。我们知道，业务流程分析本身是一种抽象分析，而业务流程本身也分为抽象过程和实例化过程，抽象过程用于系统分析，实例化过程用于系统工作流设计。Use Case承担了抽象过程，因此需要对抽象的业务活动进行实例化分析。这种实例化其实并不是最终的系统实例化，因为在创建Use Case的过程中，需要选取有差异化的Case进行业务差异化分析，所以我们可以认为Use Case的Case实例化是有限实例化。
最后，我们来总结一下
本文不重点讨论具体的UML Use case绘制方法，因为如果你去百度一下结构化系统分析工具，就能得到很多相关的方法。我着重讨论Use case到底有没有用，以及如何生成Use case。我14年的系统设计开发经验告诉我，如果很多工具和方法没有配合使用，如果不理解它的含义和实际的业务目的，那么我们往往会产生形式化的设计，而这些设计对产品和系统不会有太大的帮助。
Use case 有这样的问题，首先要明确它是一个分析过程，而不是设计过程，它是一个从业务流程分析到系统设计的衔接过程，如果这个问题没有搞清楚，Use case 对于产品开发中所有角色来说可能都是无用的。
其次我们要知道Use case能给我们提供什么，它可以帮助我们分析功能需求和业务可能性，我觉得这是最重要的部分。换句话说，如果我们已经有了功能需求或者限制了业务可能性的分析，那么你会觉得做Use case完全是多余的。
进一步我强调了用例的粒度选择一定要放在业务流程分析的业务活动中，只有这样分析过程才能兼具设计的一致性和最小代价的完整性，这也符合敏捷设计的理念。
最后我提供了一套生成用例的方法，可以帮助大家快速生成有限实例化案例，通过差异化的案例分析，生成功能需求和业务可能性，为后续的系统结构化设计和行为设计提供必要的设计参考。
好了，今天就到这里，希望在新年之前再写一篇文章，题目还没定，祝大家新年快乐！
暂无评论内容