第21章　用例设计

        经过需求工程到设计工程的5个阶段，以及综合设计（管理、价值）后，正式的设计工作已经完成，本章重点讲述如何对各阶段的工作成果进行推演和验证以保证设计成果可以达到预期效果，并在软件开发完成前就掌握完成后的效果，避免或减少开发完成后的返工作业。

        综合设计-用例设计，作为设计工程的提高部分，这个部分的学习除了需要读者已经基本上掌握了业务设计和应用设计部分的知识以外，还需要读者对企业中的某类业务有一定的实践经验，这样才能够从自己的实践经验中提取出用例场景。

21.1　基本概念

21.1.1　用例的概念

        在进行前述各个阶段的设计时，设计师需要判断设计完成的效果如何：分别进行的架构、功能到数据三个层面设计内容是否可以形成一个整体运行？业务数据是否会顺畅地流通？管控点是否会有效地发挥管理的效果？客户价值是否体现出来了？设计中是否还存在着缺陷、错误等？此时就需要有一套方法，来帮助设计师进行推演、确认。

        如果是建筑设计和机械设计的成果，它们可以通过图纸、建筑模型或是计算机制作的3D模型等直观地“看到”功能的效果。但是软件的设计是无法直接“看到”功能的效果的，它需要用流程、数据、规则、机制等将所有的设计成果串联起来进行检查。怎么做呢？打个比喻，导演为什么在电影拍摄完成前就预知拍完的效果呢？因为有脚本和剧本。拍电影时要先写个电影脚本，这个脚本给出了故事梗概、分镜头等粗粒度的设计。然后根据脚本，再编写出详细的电影剧本，剧本中要将全部的剧情串联起来，并描写到对话、动作、道具等细节，电影导演和演员就是根据这个剧本来拍电影的，就是因为有了剧本，电影导演才有可能在电影拍摄完成前就能把控和预知每个细节以及整体的效果。这里对比一下，如果“业务架构、业务功能”相当于“电影脚本”，是粗线条的，那么设计师也需要一套将“剧情”全部串联起来的“剧本”作为设计成果的验证工具，这个“电影剧本”就是“业务用例与应用用例”。业务与应用写的是“剧本、故事”，但是为了与技术的称呼习惯统一，所以将业务剧本和应用剧本统一写成“业务用例”和“应用用例”，这样与测试阶段使用的“测试用例”就统一起来了。

        1．用例的分类

        业务设计、应用设计和技术设计三个阶段的内容不同，所以对它们的验证目的和方法也有所不同，因此将验证的用例分为三类，即业务用例、应用用例以及测试用例。

        1）业务用例——验证业务设计成果编写业务处理的场景，将概要设计与详细设计的成果串联起来，用于推演业务设计的成果是否满足客户对业务方面的需求。

        2）应用用例——验证应用设计成果基于业务用例的场景，将业务设计与应用设计的成果串联起来，用以推演应用设计的成果是否满足客户对应用方面的需求。

        3）测试用例——测试开发成果参考业务与应用的用例，全面测试软件的开发成果是否满足业务设计、应用设计以及技术设计的要求。三个阶段使用了三种用例形式，从前到后继承叠加，最后验证出综合效果，这三者是包含关系：测试用例＞应用用例＞业务用例

        这里未标出管理设计和价值设计的位置，因为它们的内容分别融入到各个阶段的设计中了。

        2．测试与测试用例

        软件开发完成后在交给客户前，到底要测试到什么程度呢？关于这个“度”的问题有不同的说法，其中强调“软件不同于其他行业…”的说法也不在少数，但是有一个原则不论什么行业都是要遵守的，那就是交到客户手中的产品原则上是不能有质量问题的，不论这个质量问题是设计带来的（业务、应用和技术）还是开发带来的。“没有bug了，所以测试完成了”的说法是不正确的，测试完成的标准应该是：测试结果证明产品的开发完全符合设计要求。按照这个标准做测试，不但要有测试用例，还必须有业务用例和应用用例，一般来说，测试工程师是不可能写出来业务用例和应用用例的，因此这两个用例必须由业务／应用设计师或是业务专家来编写，编写这两个用例也是业务／应用设计师利用用例向他人说明自己的设计意图和效果的好方法。一定要记住：客户的满意度是针对整个软件的设计、开发和服务而言的，没有bug不是客户满意度的参考指标。

        另外，“测试结果”是不能直接用于验证“客户需求”的，而只能用于验证“设计结果”，因为客户需求都要经过多重的设计（业务、应用、技术）之后才能确定下来交付开发。因此，测试开发成果是对设计负责，而不是对需求负责，这就是工程化设计的原则。

        3．关于需求用例

        UML中使用“用例”的方法来获取需求（也称之为“需求用例”），它与上述三个用例定义、目的是不同的。由于本书采用的需求获取、分析方法与UML的方法不同，所以这里省略UML的用例说明。

21.1.2　用例的作用

        编写用例可以在进入正式编程前帮助消除“隐性的设计缺陷”，由于设计时每个功能都是独立设计彼此不关联，这些隐性缺陷不用业务场景进行验证暴露不出来，因此有问题也难以发现。如果把这些隐性缺陷带入到编码中，就相当于埋下了隐形“炸弹”，上线后就会爆炸。开发完成后再修改缺陷将会带来很大的开发成本，因此在设计／原型阶段修改的成本是最小的。

        1．用例的作用与区别

        1）业务用例（对业务设计成果的推演）以需求为依据，对业务的梳理、优化内容进行推演，重点在于对“业务逻辑、数据逻辑”的确认，是“内涵”。

        2）应用用例（对应用设计成果的推演）以业务用例的数据作为主线，加入系统功能（流程机制、高保真界面、按钮等），进行用户操作过程的合理性、友好性推演，重点在于“信息化环境”的确认，是“外表”。

        3）测试用例（对完成系统的测试）测试用例除去其自有的测试内容（如bug、性能、安全、集成等）以外，再加入前述两个推演用例的内容，以测试完成的系统是否可以准确地演出这个“剧本”。

21.2　业务用例

21.2.1　定义与作用

        1．定义

        业务用例，是针对业务设计阶段（概要设计、详细设计）成果的验证依据

        业务用例将专业知识、业务设计部分（业务与管理）的成果，通过业务场景（数据、规则）串联在一起，用以验证逻辑是否正确，功能是否可以满足设计的要求。

        （1）用例构成：业务用例是由三个部分构成的，即用例场景、用例导图、用例数据。

        （2）编写期间：业务用例是在业务设计期间编写的，在业务设计完成时进行验证。业务用例是用来验证业务设计阶段（概要、详细）的成果的，所以在业务场景不要涉及应用设计阶段或是技术设计阶段的内容。也就是说，业务用例只包含纯粹的“业务设计与相应的管理设计”内容。

        利用业务用例，可以精准自查设计是否正确

21.2.2　内容与能力

           一个完整的业务用例设计内容由三个部分构成：用例场景、用例导图和用例数据。

        （1）用例场景：用以确定需要验证的对象、目的。

        （2）用例导图：利用架构图来表达用例场景的数据流转过程。

        （3）用例数据：利用用例导图、详细数据、规则来推演验证用例场景描述的过程。

21.2.3　用例设计1——用例场景

        一个系统的业务设计完成后，需要对哪些部分进行验证是根据业务设计师的判断来决定的，通常判断是否需要验证的条件如下（仅作参考）。

        （1）业务场景、业务逻辑非常复杂的部分。

        （2）业务计算的逻辑复杂、数据来源复杂，且需要多重计算。

        （3）新产品、新业务。

        （4）多人协同、多系统协同等的场景。

        （5）客户非常关心、设计方把握不大的业务运行场景，等等。大型的复杂系统可能要编写几个甚至十几个业务用例。每个业务用例的对象、目的都不同，它们的验证结果合起来就可以判断该系统的业务设计成果是否满足要求。

        首先要确定验证什么场景，目的是什么。

        （1）题目：给出编写用例的方向。

        （2）目标：根据题目说明验证的目标，如客户关心、流程逻辑复杂、数据规则复杂等。

        （3）价值：达成目标后，可以为客户带来什么价值（效果）。

21.2.4　用例设计2——用例导图

        用例场景不但要用文字描述，还需要用一个可以表达场景的用例导图，这个图可以给出：场景开始的目标数据、场景结束的结果数据，以及表达从目标数据到结果数据的变化过程的结构图。

        用例导图，是以功能的结果数据为节点、以数据间的关系为连接形成的图形，给出了从目标数据到结果数据的变化过程

        1．数据结构

        数据结构中同时包含“业务逻辑”和“数据逻辑”。

        （1）形式：采用流程与分解两种模型的混合体，来源于流程图的流向和数据的分解结构。

        （2）来源：结构的内容来源为用例场景。

        （3）节点：节点标注的是“功能名称+数据”，这个“数据”是该功能的处理结果，节点不一定都来自于流程，也可以是“数据库名称+数据”。

        （4）关系：节点之间的关系是数据关系，前后之间是计算关系。

        3．业务流程与数据结构的区别

        1）从形态上看

        （1）业务流程：采用的是业务架构模型。

        （2）数据结构：采用的是流程模型与分解模型的混合型。

        2）从逻辑上看

        （1）业务流程：节点是功能，所以节点之间符合业务逻辑关系。

        （2）数据结构：节点是数据，节点间只要有数据引用关系即可，业务逻辑有无都可以。

        3）从数据上看

        （1）业务流程：节点是“功能”，因此内部数据是多样的，同时存在成本、组织、名称等数据。

        （2）数据结构：节点上只标一个可计算的数据，如成本、支出、经费等。

21.2.5　用例设计3——用例数据

        有了数据结构、目标和结果数据后，下面用一个数据推演表，将数据结构中的从“目标数据”到“结果数据”的数据变化过程完整、详细地列出来。用例数据涉及的主要内容可以分为以下三个部分。

21.3　应用用例

21.3.1　定义与作用

1．定义

        应用用例，是针对应用设计阶段成果的验证依据。

        应用用例将业务用例、应用设计成果（组件、机制），通过应用场景（操作）串联在一起，用以验证操作过程是否满足用户的需求。

        （1）用例构成：用例场景、用例导图和用例数据。

        （2）编写期间：是在应用设计期间编写的，在应用设计完成时进行验证。

        应用用例，是在业务用例之上，加入了应用设计的组件（界面）、按钮控件、菜单等构成了一个虚拟的操作环境，它可以模拟系统完成后的实际使用场景，它可以让用户、业务／应用设计师、技术人员（设计、开发、测试）等所有方在系统开发完成前，就基本上知道了系统完成后的效果。应用用例可以提供“人-机-人”操作环境，通过与用户的共同确认帮助进行以下的验证（不限于此）。

        （1）模拟系统完成后的操作环境，感受应用操作的效率、人机友好满意度。

        （2）可以有效地提前解决隐性设计缺陷，减少开发完成后的软件商与用户之间的认知误差。

        （3）让系统干系人的认知全部统一，认知包括对以下内容的理解：架构、功能、操作等。除去对功能方面设计成果的验证外，应用用例还有一个重要作用就是对应用价值的验证，用例可以让用户直接感受到应用价值的存在。

        （1）业务价值：主要来自于业务设计的内容。

        ●　经过业务设计后，企业的各类过程清晰（业务流程），如合同流程、采购流程等。

        ●　企业的各类规则标准化（字典），如客商、材料、采购、支付等。

        ●　各类需求调研时的客户痛点的解决方案等。

        （2）应用价值：主要来自于应用设计的内容。

        ●　流程的“事找人”“人找事”的设计形式。

        ●　门户的“待办提醒”的设计形式。

        ●　窗体的人性化设计、布局等。

        ●　系统的随需应变能力（各类功能属性的灵活设置）等。

        ●　业务的痛点对策的实现方式等。

        （3）使用对象、使用场合。

        ●　应用设计师进行内部讨论、验证。

        ●　与用户的相关部门、岗位进行沟通、确认。

        ●　向后续设计、验证提供功能、逻辑、数据、机制的支持。

        ●　上线培训的重要参考资料等。可见，应用用例不是一个简单的由原型界面构成的链接过程，而是要包括应用设计的成果（价值）等，仅仅是界面的链接过程是不能展示出系统完成后的应用效果、价值的。分享应用用例，可以避免客户说“这不是我想要的”。

        最为保险的是与客户进行三次确认。

        第一次：在需求调研完成时，以需求规格说明书为基础进行功能内容的确认。

        第二次：在业务设计完成时，以业务用例为基础进行业务处理形式的确认。

        第三次：在应用设计完成时，以应用用例为基础进行系统应用形式的确认。

21.3.2　内容与能力

        1．作业内容

        一个完整的应用用例设计内容有三个部分：用例场景、用例导图和用例数据。

        （1）用例场景：首先设定验证对应的应用场景，然后根据场景选取验证的流程、功能等。

        （2）用例导图：应用用例主要是通过推演的方式进行验证，所以需要运行图作引导。    

        （3）用例数据：运行前所有要做的数据准备工作，也是重要的推演和验证对象。

21.3.3　用例设计1——用例场景

        应用用例的验证对象可以有两类，一类是继承业务用例的内容，加入系统功能后继续进行验证该业务在系统中的运行效果；另外一类是验证应用设计特有的内容，并不直接需要业务用例的结果。

        1．题目与目的

        应用用例与业务用例在场景设计选择上有所不同，业务用例更多的是验证业务本身（例如以某个业务线为主轴设计），而不在意该业务由哪个角色来处理，但是应用用例的“应用”不但要有主线而且还要针对角色设置用例，重点是站在某个角色的立场上将“该角色关心的内容整合成流程”加以推演。因此，在确定题目、目标和价值之前需要首先确定操作角色。

        （1）角色：按照部门、角色规划（董事长、成本会计、仓库管理员、…），或是一组角色（成本线会关联到很多的角色）。

        （2）题目：从该角色的视角出发，选定题目。

        （3）目标：根据上述题目，确定该角色关心什么、要什么结果。

        （4）价值：达到了目标后，可以给该角色带来什么价值。从角色出发设置用例场景，这就是为什么说应用用例可以验证客户的信息化价值的原因。

        为了可以达成目标，场景设计时可以考虑加入以下功能的推演。流程：采用“事找人”的流程设计方式，包括提交、审批、流程推送、通知等。管理：成本的关键节点的管控措施，如预算超额的处理（提示、警告、暂停）。修改：发生财务数据修改时的处理方法，如红字更正等。案例2作为下面用例导图设计时的参考场景。

21.3.4　用例设计2——用例导图

        用例导图，是用图形的方式，将场景的内容按照操作流程的顺序详细地呈现出来，它包含在系统中操作的主要步骤、主要操作功能（节点），以及想要呈现给读者的信息化环境下最具应用价值的内容。

        1．用例导图的构成

        用例导图的内容、方式可以根据应用设计师向用户、技术设计师展示的内容而定，但是有以下几个必须要有的核心内容。

        （1）操作步骤：给出应用用例的主线。

        （2）操作界面：给出操作步骤上每个节点的应用原型界面截图。

        （3）数据关系：给出每个节点上需要的外部数据源，如基础数据（字典）等。

        （4）管理架构图：给出具有管控功能的系统机制，说明如何进行管控。

        系统运行时的操作步骤不是业务设计中的业务流程，可以看作是在系统上运行的“业务流程”，例如，在业务用例中，业务流程是将业务功能用逻辑串联起来，但是在应用用例中，实现同样的流程可能是采用了“事找人”的流转方式，不但有业务功能，还有系统功能（这就是应用用例体现信息化价值的原因）。

21.3.5　用例设计3——用例数据

        这里讲的用例数据是个广义的概念，它包括所有系统运行前需要准备的数据，在这里要把这些数据的输入理解成是企业用户必须要做的系统运行“管理工作”。这些管理工作原本是由企业中的相关部门用手工方式进行的，最终用纸记录成册，或是编制成电子版的数据，当然有的企业也可能根本就没有进行规范化的整理工作。

        应用设计师要意识到：你交付给企业的不是一款软件，而是帮助企业构筑了一个信息化的工作环境，这个环境中除了有业务功能、流程之外，还有基础数据的内容，这些基础数据是企业管理信息化、标准化、规范化的重要构成部分。客观地说，没有健全的基础数据，无法实现真正的企业管理信息化。

小结

        用例设计，是在完成软件开发前对设计成果进行验证的最有效方法。它不但可以让所有的系统相关人在系统完成前对未来的系统有一个具象的感受，而且还可以避免由于设计缺陷给系统开发带来的损失。每一步的用例验证（业务用例、应用用例、测试用例）都是对系统开发成功增加的一份保险。可以肯定地说，在开发前能够编制出用例（业务和应用）并对产品的设计目的、内容、逻辑、质量、使用效果，以及期望的业务价值和应用价值等进行全面验证，则完成的系统一次上线成功率一定会非常高。反之，对于具有一定规模和复杂度的系统设计如果没有编制验证用例和验证，那么这个系统开发完成后存在重大问题的风险就会很大。编写用例对业务／应用设计师来说是一个综合挑战，它不但可以检验自己的产品设计成果，还是对个人能力提升程度进行的一次全面检验。在软件的开发过程中，业务／应用设计师应该是核心，如果要想做好这个核心人物，业务／应用设计师不但要精通概要设计（架构、功能和数据三层）、管理设计、价值设计，而且要精通业务用例设计和应用用例设计，只有如此，业务／应用设计师才能做到对以自己为核心完成的设计结果有把握，并确保软件开发过程在掌控之中。

        关于软件开发过程中设计与验证的时间是否合理的问题。

        大家时常谈到一个无奈（无解？）的问题：没有充分的时间做设计和验证，怎么办？这个问题是软件行业现在普遍存在的问题，而且有的极端情况是：不是设计和验证时间不够，而是根本就没有预留设计和验证时间。