用例驱动设计

引言

用例驱动设计是一种有效的软件工程化设计的方法论之一。整个过程分为需求获取、需求分析、系统分析、系统设计、编码实现、测试交付五个阶段。每个阶段环环相扣，形成一个迭代周期。

1 需求获取

整个需求获取阶段可以分为前期探索、获取业务、提炼规则、获取非功能需求四部分。

1.1 前期准备

前期探索，首先是要了解用户目前的业务现状；然后再是挖掘用户的业务目标；最后挖掘与业务相关的涉众对系统的期望。了解业务现状后，制定出更能打动消费者的业务目标是项目成功的关键。对于自定义产品的研发项目，挖掘业务目标和涉众更是产品成功定位的关键。此外，业务目标也是后面用例分析的起点和边界。

1.2 获取业务

整个获取业务包括发掘业务用例和业务主角、发掘业务用例场景、发掘业务用例实现、发掘业务用例实现场景四个步骤。

• 发掘业务用例和业务主角
  围绕着业务目标制定边界、去发掘业务用例和业务主角。整个过程需要输出以业务目标和业务主角两个维度呈现的业务用例视图和业务主角视图。
• 发掘业务用例场景
  发掘每个业务用例的业务流程，并以参与者和业务工人作为泳道、按活动图的形式输出业务用例场景视图。对于流程是属于一个场景的分支还是独立的场景，一般对于用户而言是独立的业务、即便两个场景很多流程一致，那么也得作为一个独立的业务场景。
  此外，该阶段还需要输出业务用例规约报表，包括前置条件、后置条件、执行者、主过程、分支过程、异常过程、业务规则、业务规则等。
• 发掘业务用例实现
  以每个业务用例场景输出一个业务用例实现视图。
• 发掘业务用例实现场景
  对业务用例实现所对应的业务用例场景活动图中的每个活动理出更细的业务流程，输出业务用例实现场景视图；视图以业务员和计算机作为泳道、按活动图方式呈现。此外，还可以输出时序图作为补充。

最后，以领域包图去分类归档上面的视图。归类方法有按业务模块、按业务目标、业务过程、按业务部门等方式。此外，业务用例重业务而非实现、不应有计算机相关的专业术语；业务用例实现可以有计算机相关概念、但不能深入到计算机的内部逻辑。

1.3 提炼规则

业务是说明系统能为用户做什么，而业务规则是说明用户希望系统怎么做。规则分为全局规则、交互规则和内禀规则。

• 全局规则
  全局规则是对整个系统的约束性要求。需要输出到补充规约中。
• 交互规则
  交互规则是对业务用例的约束，需要输出到前面的业务用例规约报表中，其中的前置条件、后置条件和业务规则都属于交互规则。
• 内禀规则
  内禀规则是对业务对象的约束，例如员工管理系统中，员工电话号码必须为11位。需要输出到后面的业务对象描述文档中。

1.4 获取非功能需求

非功能需求是指系统满足用户业务功能之外的特性，包括安全性、可靠性、互操作性、健壮性等。对每项非功能需求都需要输出非功能需求报表。

2 需求分析

整个需求分析阶段可以分为领域分析、概念分析和建立业务架构三部分。领域分析和概念分析最终都通过分析模型输出最终的模型视图。

2.1 领域分析

领域分析的目标是建立领域模型。更确切地说，就是定义合适的业务对象，使之满足前面的业务用例。
领域分析的方法论很多，最常见的领域分析步骤如下：

首先，罗列出一个个问题。然后针对每个问题去分析、建模、验证。

• 提出问题
  提出问题可以说是事先对问题的罗列，对架构师的系统性思维、全局思维、前瞻思维等要求比较高。如果有关键问题被遗漏，极有可能对后期造成不可估量的风险。
• 分析问题
  分析问题就是挖掘出领域模型，这个过程就像方程求解。未知数是领域对象、方程是对象交互场景、最终的解就是领域模型。找到领域模型就是找到了构成业务系统的基本对象。
• 建立模型
  经过分析问题后，建立出领域对象模型，然后以实体对象图的方式输出领域模型视图。
• 验证模型
  将建立的领域对象代入业务用例实现场景中去验证建立的模型是否满足业务需求，以参与者、领域对象为交互对象，按时序图方式输出领域对象场景视图。

2.2 概念分析

概念分析就是建立概念模型，为系统分析和设计提供铺垫。领域模型主要针对技术问题，而概念模型只针对业务。整个概念分析步骤如下：

• 确定核心业务流程
  概念模型贵在精准而非事无巨细。经过需求获取阶段建立的业务模型，可能很多都是冗余的，所以需要理出支持用户业务的核心业务，然后输出核心业务主线视图，以活动图方式呈现。
• 挖掘概念用例
  找出核心业务主线中每个活动的关键业务用例。这时，可能多个业务用例都与核心业务主线中的某个活动有关，那么只需要找出具备通用典型的业务用例。最后组成关键业务用例视图。
  在每个关键业务用例中，找出与核心业务主线最密切的环节，这些环节就是关键业务用例的概念用例，输出概念用例视图。
• 整理概念用例场景
  对每个概念用例输出概念用例场景视图。
• 理出关键的业务对象
  根据概念用例场景，理出参与其中的关键业务对象，并输出关键业务对象视图，即概念模型。关键业务对象可以包括在领域分析阶段建立的领域对象。
• 理出业务对象场景
  将建立的业务对象代入概念用例场景来验证概念模型是否合理，输出关键业务对象场景视图。视图以参与者、业务实体对象、系统边界、控制类对象、工程流控制器为交互对象。

2.3 整理业务架构

前面业务用例模型解释了业务细节、领域模型为业务问题提供了解决方案、概念模型提供了业务骨架，而建立业务架构就是对需求深入分析，抽象出相对独立的业务模块、形成自洽的业务构件。
整理业务架构的方法没有统一，主要考验架构师的抽象思维和边界思维。不过一般都从概念模型入手。最终以组件图的方式输出核心业务架构视图。此外，还有必要以领域包图等方式去呈现每个业务组件包含的分析类。

3 系统分析

需求分析以业务为中心分析并建立业务架构，那么系统分析阶段将围绕着系统为边界分析并建立系统架构，业务架构是拼图单元、系统架构就是拼图方法。整个系统分析阶段可以分为发掘系统用例、设计业务规则、梳理系统用例实现、设计系统架构四部分。

3.1 发掘系统用例

整个发掘系统用例过程，由发掘系统用例、梳理系统用例场景、梳理系统用例规约三个步骤进行。

• 发掘系统用例
  对每个业务用例实现对应的业务用例场景深入分析，通过映射、抽象、合并、拆分、演绎等手段发掘出系统用例，这是从业务需求到系统需求的过度。输出系统用例视图。
• 梳理系统用例场景
  对每个系统用例梳理出系统工作流程，并以参与者和计算机作为泳道、按活动图的形式输出系统用例场景视图。
• 梳理系统用例规约
  最后，需要对每个系统用例整理出系统用例规约报表。与业务用例一样，包括前置条件、后置条件、执行者、主过程、分支过程、异常过程、业务规则、业务规则等。

系统用例与业务用例不同的是，系统用例围绕着系统怎么实现业务的抽象过程、但不深入具体实现细节；而业务用例围绕着用户怎么完成业务、不涉及系统边界。
系统用例与业务用例实现相比，虽然业务用例实现场景中带有计算机术语、但不深入计算机怎么实现业务；但系统用例场景包含计算机怎么实现业务功能的抽象流程。

3.2 设计业务规则

设计规则就是将系统中的共性规则抽取出来，通过抽象出统一的设计去拥抱需求变化。对全局规则、交互规则、内禀规则分层次进行设计，以设计类方式呈现。

• 全局规则
  全局规则对整个系统均有效，交给工程师处理对系统的风险比较高，所以必须在系统分析阶段给出方案设计。例如，日志系统对于各个模块都需要使用，而且日志系统对日志的记录等级怎么划分、日志开关等等，都必须由系统分析阶段敲定。所有的全局规则以设计类方式输出全局规则设计视图，并对全局规则的所有操作都以对象时序图方式输出全局规则实现视图。
• 交互规则
  交互规则作用于系统用例场景，也需要在系统分析阶段设计出交互规则设计视图，并对交互规则的所有操作都以对象时序图方式输出交互规则实现视图。通常，还需要对所有的交付规则设计管理库，输出包括交互规则管理设计视图和交互规则管理实现视图。
• 内禀规则
  内部规则只作用于单个业务对象，影响的范围比较小，理论上可以由工程师自己搞定。例如前面的电话号码只有11位的内禀规则，当信息录入的时候，编码时对不是11位数字的电话号码输入给予提示！但是，个人认为架构师或资深工程师有必要提供规则引擎、或选择通用的规则匹配库，提供给开发人员降低开发成本。

3.3 梳理系统用例实现

整个梳理系统用例实现的过程分为发掘系统用例实现、梳理系统用例实现场景、整理系统用例分析模型三个步骤。

• 发掘系统用例实现
  对每个系统用例的可能实现方式进行分析，输出系统用例实现视图。例如员工管理系统中，录入员工信息这个系统用例可能有单条录入和批量录入两个系统用例实现。
• 梳理系统用例实现场景
  对每个系统用例实现输出系统用例实现场景视图。
• 整理系统用例分析模型
  整理系统用例分析模型相对复杂得多。首先，将系统用例实现场景结合领域模型和概念模型，梳理出场景中的实体对象，如果不足则需要定义补充；其次，定义控制对象来操作实体对象的数据、以系统交互为边界对象；然后，输出每个系统用例实现的系统用例实现交互视图，最后，对相关的交互视图整理合并为每个系统用用例的系统用例分析模型视图。
  系统用例实现交互视图以实体对象、边界对象、控制对象、规则管理库、工作流引擎和业务主角为交互对象，按时序图方式呈现；系统用例分析模型视图按分析类关系视图方式呈现。

3.4 设计系统架构

设计系统架构的过程分为设计架构模型、验证架构模型、设计组件模型三个步骤。

• 设计架构模型
  经过技术选型和建立的业务架构，设计系统的宏观架构(即广度视角)。按包图方式输出系统架构广度视图。对于引入的框架需要给出标准文档和编程模型示例；特别地，若是自研的框架还需要给出框架设计实现(设计类图和交互图)。
• 验证架构模型
  结合系统用例实现场景和系统用例分析模型，分析系统用例在架构广度视角每个层次的实现，输出系统用例深度视角交互视图和系统用例深度视角分析视图；最后，整理出系统用例分析模型视图。
  系统用例深度视角交互视图按交互图方式输出，系统用例深度视角分析视图和系统用例分析模型视图按分析类关系图方式输出。所有图中除了包括梳理系统用例实现阶段的实体对象、边界对象、控制对象、规则管理库、工作流引擎和业务主角之外，还要包含架构模型中的设计类对象。这个过程除了验证架构设计合理性之外，还将架构模型代入各个系统用例实现场景并输出了深度视角。
• 拆分业务领域
  将前面建立的业务架构映射到领域功能模块，设计出实现所有系统用例的可复用功能组件。输出系统组件关系视图和系统组件部署视图，并整理组件完成系统用例功能的系统用例组件交互视图。如果说架构模型是按系统的层次划分、而系统组件模型则是按业务领域划分，两个维度缺一不可。同样，也有必要以领域包图方式去呈现每个系统组件包含的分析类。

4 系统设计

整个系统设计阶段可以为建立设计模型、建立开发视图两部分。

4.1 建立设计模型

建立设计模型的过程分为分析模型转设计模型、数据实体设计两个步骤。

• 分析模型转设计模型
  对每个系统用例分析模型映射出系统用例设计模型视图，以设计类图方式呈现。然后对设计模型视图的交互过程输出系统用例设计交互视图，以交互图方式呈现。
• 数据实体设计
  数据实体设计是对设计模型中的数据实体对象建立模型，包括缓存数据实体、持久化数据实体。以E-R图或其他多种方式输出数据模型视图。

4.2 建立开发视图

建立开发视图是将前面建立的系统架构落实到开发，主要分为划分开发边界、设计边界接口两个步骤。

• 划分开发边界
  根据前面建立的业务架构和系统架构，划分出开发阶段的功能组件、以包图方式输出开发架构视图。此外，还需要以单独的视图，对每个包归档上个阶段建立的设计模型和数据模型。
• 设计边界接口
  设计边界接口是将上阶段划分的开发边界细化，使之更加明确、使后续编码顺利并行开展。对每个功能包以设计类图方式输出模块接口设计视图。此外，还需要对每个功能包所依赖的具体哪些接口作出阐明。

5 编码实现

整个编码实现阶段可以分为约定开发规范、执行编码两阶段。

• 约定开发规范
  约定开发规范是包括制定编码规范、约定开发语言、编译器版本、三方库版本、代码仓库管理等等。
• 执行编码
  由于前面已定义了明确的功能边界，所以开发过程中会并行开展，这个阶段需要以设计模型为参考编写功能实现，还需要编写模块单元测试。此外，有可能效率高的成员提前完成了功能、但依赖另一个成员负责的功能还未开发完成，这时还需要针对依赖的模块编写fake代码进行回环测试。

6 测试交付

测试阶段以系统用例为基准，进行黑盒测试、直到最后所有的功能全部正常。这个过程中，会出现修改BUG的情况。因此，为了规避修正新问题引发之前已修复的问题再现，需要最后做一次全部功能的回归测试，且全部顺畅测试通过才可以正式对外交付。

总结

无论是用例驱动，还是领域驱动，最终都需要建立架构模型，虽然起点不一样、但终点相同；领域驱动更强调以领域模型为中心去设计，而用例驱动需要以用例为中心去分析。
用例驱动更需要架构师的业务和系统分析能力很好。正所谓：遇到青铜，则造成面向功能实现；遇到王者，就能以架构高度实现。因为用例驱动更取决于架构师的个人能力、相对领域驱动没那么多经验可以借鉴，这也是很多公司采用领域驱动的原因。如果说领域驱动是借鉴和发扬积累的领域经验、而用例驱动是发明和探索新的领域经验。
对于一些没有成熟解决方案的领域，需要通过用例驱动迭代出领域模型。领域驱动的初步模型一般是用例驱动迭代而成的，即便是你一开始就是在领域驱动，那么你一定是站在公司或前辈积累下的成熟领域经验的肩上，第一个吃螃蟹的人一定是值得感谢的。

升华

对于前面的六个过程，其实，在工程实践中可根据实际情况进行精简。以研发基础中间件为例：

• 需求获取
  这一阶段除了前期准备之外，其他的步骤可以省去；
• 分析阶段
  可以将需求分析和系统分析两个阶段合二为一；
• 系统设计
  这一阶段，可以根据项目情况省去建立设计模型、只保留建立开发视图；
• 编码测试
  不用想，这两个阶段是必不可少。