UML用例建模，业务用例建模、概念用例建模、系统用例建模，领域建模

在面向对象软件开发的过程中，针对复杂系统，我们一般会先进行相关建模来了解现实世界问题，通过抽象方法，建立模型来表征现实世界，获得对现实事物本身的理解，然后将这些理解到的知识概念化，并将这些逻辑概念组织起来，形成对所观察事务的内部结构和工作原理便于理解的表达。在UML中通过用例驱动的方式来一步一步获取对现实世界的理解。

一般我们通过如下三个用例建模步骤来获取对现实世界问题的认知，然后将其转化为计算机世界的实现，主要有如下三个步骤：

业务用例建模
概念用例建模
系统用例建模

业务用例建模

业务用例建模早于需求工作。一般我们常说的需求，或者常说的需求规格说明书指的是系统需求，是指将要搭建的系统需要实现的功能契约，是与计算机世界紧密关联的，仅仅是要在计算机世界实现的一部分业务需求，这部分需求来源于业务需求，业务需求不仅仅是系统需求，还有一部分需求可能是计算机无法实现的，而是人工实现的。业务需求是面向现实世界的，而系统需求则是面向计算机世界的
业务模型是想为现实世界中客户的真实业务建立模型，能够让我们与客户在业务理解上达成共识，这时候是不需要考虑计算机世界的。
业务模型要准确而完备的描述客户的业务，而系统用例可能只是业务的部分或者其中的一环。
在一些比较复杂的场景下，如果不建立业务模型，那么真实的业务链可能就不完整。

业务用例建模主要包含如下内容：

业务用例视图，包含业务主角和业务用例
业务用例场景，说明业务用例的执行过程，业务主角是如何使用业务完成业务目标
业务用例规约，针对每一个业务用例编写，说明业务用例的使用者、目标、场景、相关业务规则、相关业务实体
业务规则，必须遵守的法规、惯例，也有可能是操作规范、约束机制等
业务对象模型，描述业务模型中的关键独享
业务用例实现图
业务用例实现场景，针对每个业务用例实现，说明该实现方式的步骤，与业务用例场景类似，但是更为明确
包图，组织业务用例
可以通过活动图、时序图、协作图，发下业务用例场景
完整的业务用例模型如下：

概念用例建模

当系统规模比较庞大复杂时，这时候一般业务用例的粒度会比较粗，但是系统用例的粒度一般比较小，我们要将粗粒度的业务用例转换成较细的系统用例，这时候一般比较困难，而如果将业务用例的粒度弄得比较细，业务用例的数据又会激增。
这时候我们通过概念用例建模对粗粒度的业务用例进行相关的分析，找到关键、核心的工作单元，针对这些关键核心工作单元来建立模型以便简化业务

通过概念用例建模，我们得到比较核心重要且粒度相对细一些的用例模型，这个模型能够帮助我们从业务用例模型过度到系统用例模型。另外这个模型也能够帮助我们建立业务架构（如果需要）

概念用例建模主要包含如下内容：

概念用例分析，从业务用例模型中挑选出重要的和典型的业务用例场景，从中分析相关概念用例如何实现这些业务用例场景
分析类视图，从概念分析过程中，抽象出分析类的静态关系，得到的分析类将是我们理解系统实现的第一步
分析场景，使用分析类绘制对象交互图，从对象的角度去实现概念用例分析场景

概念用例可以通过这几种方式获得：1. 观察所有的业务用例场景，发现那种在不同的业务用例场景中多次出现 2. 通过客户分析获取对客户来说最重要的一些业务实体，然后了解这些业务实体可能进行的操作来获得备选用例 3. 通过绘制概念用例分析来检验备选的概念用例

我们通过分析业务用例得到概念用例，然后通过活动图、时序图、协作图对概念用例进行分析，根据分析结果，在集合鲁棒图、时序图、协作图、状态图，得到用例实现
完整的概念用例模型如下：

系统用例建模

系统建模就是我们常说的需求获取，系统用例也可以省去系统二字，就是我们常说的用例。用例模型定义为系统既定功能及系统环境的模型，可以作为客户和开发人员之间的契约。

如果需求分析是从业务用例模型开始，那么到系统用例模型应该有足够信息来源来获取系统用例，如果没有业务用例建模，而是直接从系统用例建模开始，那么系统用例模型将从涉众请求开始，将涉众请求直接转化为用例模型。

系统用例模型主要内容如下“

业务用例，在系统用例模型中使用精华关系连接到业务用例，表明软件过程的可追溯性，说明哪些系统用例是从哪些业务用例演化出来的，如果没有业务用例建模过程，不需要
概念用例，作为从业务用例到系统用例的过度，概念用例只能起到获取用例的指导作用
系统用例视图，包括参与者、用例，是系统功能性需求的高层视图
系统用例规约，采用文档形式描述参与者如何启动和终止用例，参与者如何使用用例完成目标，用例执行的事件流，相应的规则等内容
补充规约，说明与用例相关的非功能性需求
系统用例规则
系统用例实现
系统用例场景，描述参与者如何与计算机交互达成目的，可使用交互图描述
分析对象，用例场景中代表计算机逻辑的概念化产物

获取用例：
通过业务用例建模能够大致推导出来系统用例，通过分析业务用例场景，尤其是活动图（通过永道,能够发现业务主角和业务工人的职责活动），然后在进行如下操作：

排除用例，如果参与者不需要使用计算机，那么可以排除这个候选用例
合并用例，如果用例的结果相似，可以考虑合并这些候选用例
抽象用例，通过分析归纳业务用例场景，发现一些用例中存在一些相同的过程，可以抽象出一个描述这些相同行为的用例
补充用例，增加与业务实现无关，但是对系统运行必须的非业务需求，如备份系统数据等

完整的系统用例模型如下：

粒度选择

业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，可以描述一项完整的业务流程

概念建模阶段，用例的粒度以每个用例能够描述一个完整的事件流为宜，可以描述一项完整业务流程中的一个步骤

系统建模阶段，用例的视角是针对计算机的，用例以一个用例能够描述操作者与计算机一次完整的交互为宜，另外一个参考的粒度是用例的开发工作量在一周左右为宜

不论粒度如何选择，必须把握在同一个需求阶段，所有的用例粒度是同一个量级的

另外，需要着重强调一点，粒度选择的本质还是边界认定不同而产生的，如果对选择粒度感到困难或者同一个阶段的粒度大小不一致情况，应该确认是否选择一个正确的边界并随时检察是否越过了边界

在我们进行用例建模的时候一定要注意边界的选择，我们说的用例的粒度必须是在同一个边界下说的。在对大型复杂需求分析的时候，我们首先可以将边界设置为整个业务，然后通过这个边界，我们分析内部逻辑，抽象识别出一些模块，然后在对这些模块使用边界，这时候，一个模块就是一个边界，我们在这这个边界内部进行分析。

在概念业务用例建模的时常用的是使用鲁棒图或者说分析类，主要如下几个元素构成：

边界类
控制类
实体类

最后来聊聊领域建模.

领域模型，通过抽象现实世界当中的事物，以概念年化的手段用模型定义下来，是将领域概念以可视化的方式抽象成模型，不仅关注重要的领域概念，还刻画了领域概念之间的关系。

领域建模与用例驱动的思路正好相反，用例驱动都是由表及里，先通过外在的、可见的业务来慢慢分析发现内在的机制。
而领域建模则相反，是通过分析内在的机制，在实现外在的表现，需要团队必须有相应领域的资深专家，从需求中找出体现业务本质的事务、规则、结构,赌气进行建模，定义出业务运行的规律和原理，在这个基础上再去搭建具体的程序设计。

领域模型推导：

注：本文绝大部门分来自Thinking In UML 第二版。