在面向对象软件开发的过程中，针对复杂系统，我们一般会先进行相关建模来了解现实世界问题，通过抽象方法，建立模型来表征现实世界，获得对现实事物本身的理解，然后将这些理解到的知识概念化，并将这些逻辑概念组织起来，形成对所观察事务的内部结构和工作原理便于理解的表达。在UML中通过用例驱动的方式来一步一步获取对现实世界的理解。
一般我们通过如下三个用例建模步骤来获取对现实世界问题的认知，然后将其转化为计算机世界的实现，主要有如下三个步骤：
- 业务用例建模
- 概念用例建模
- 系统用例建模
业务用例建模
业务用例建模早于需求工作。一般我们常说的需求，或者常说的需求规格说明书指的是系统需求，是指将要搭建的系统需要实现的功能契约，是与计算机世界紧密关联的，仅仅是要在计算机世界实现的一部分业务需求，这部分需求来源于业务需求，业务需求不仅仅是系统需求，还有一部分需求可能是计算机无法实现的，而是人工实现的。业务需求是面向现实世界的，而系统需求则是面向计算机世界的
业务模型是想为现实世界中客户的真实业务建立模型，能够让我们与客户在业务理解上达成共识，这时候是不需要考虑计算机世界的。
业务模型要准确而完备的描述客户的业务，而系统用例可能只是业务的部分或者其中的一环。
在一些比较复杂的场景下，如果不建立业务模型，那么真实的业务链可能就不完整。
业务用例建模主要包含如下内容：
- 业务用例视图，包含业务主角和业务用例
- 业务用例场景，说明业务用例的执行过程，业务主角是如何使用业务完成业务目标
- 业务用例规约，针对每一个业务用例编写，说明业务用例的使用者、目标、场景、相关业务规则、相关业务实体
- 业务规则，必须遵守的法规、惯例，也有可能是操作规范、约束机制等
- 业务对象模型，描述业务模型中的关键独享
- 业务用例实现图
- 业务用例实现场景，针对每个业务用例实现，说明该实现方式的步骤，与业务用例场景类似，但是更为明确
- 包图，组织业务用例
可以通过活动图、时序图、协作图，发下业务用例场景
完整的业务用例模型如下：
概念用例建模
当系统规模比较庞大复杂时，这时候一般业务用例的粒度会比较粗，但是系统用例的粒度一般比较小，我们要将粗粒度的业务用例转换成较细的系统用例，这时候一般比较困难，而如果将业务用例的粒度弄得比较细，业务用例的数据又会激增。
这时候我们通过概念用例建模对粗粒度的业务用例进行相关的分析，找到关键、核心的工作单元，针对这些关键核心工作单元来建立模型以便简化业务
通过概念用例建模，我们得到比较核心重要且粒度相对细一些的用例模型，这个模型能够帮助我们从业务用例模型过度到系统用例模型。另外这个模型也能够帮助我们建立业务架构（如果需要）
概念用例建模主要包含如下内容：
- 概念用例分析，从业务用例模型中挑选出重要的和典型的业务用例场景，从中分析相关概念用例如何实现这些业务用例场景
- 分析类视图，从概念分析过程中，抽象出分析类的静态关系，得到的分析类将是我们理解系统实现的第一步
- 分析场景，使用分析类绘制对象交互图，从对象的角度去实现概念用例分析场景
概念用例可以通过这几种方式获得：1. 观察所有的业务用例场景，发现那种在不同的业务用例场景中多次出现 2. 通过客户分析获取对客户来说最重要的一些业务实体，然后了解这些业务实体可能进行的操作来获得备选用例 3. 通过绘制概念用例分析来检验备选的概念用例
我们通过分析业务用例得到概念用例，然后通过活动图、时序图、协作图对概念用例进行分析，根据分析结果，在集合鲁棒图、时序图、协作图、状态图，得到用例实现
完整的概念用例模型如下：
系统用例建模
系统建模就是我们常说的需求获取，系统用例也可以省去系统二字，就是我们常说的用例。用例模型定义为系统既定功能及系统环境的模型，可以作为客户和开发人员之间的契约。
如果需求分析是从业务用例模型开始，那么到系统用例模型应该有足够信息来源来获取系统用例，如果没有业务用例建模，而是直接从系统用例建模开始，那么系统用例模型将从涉众请求开始，将涉众请求直接转化为用例模型。
系统用例模型主要内容如下“
- 业务用例，在系统用例模型中使用精华关系连接到业务用例，表明软件过程的可追溯性，说明哪些系统用例是从哪些业务用例演化出来的，如果没有业务用例建模过程，不需要
- 概念用例，作为从业务用例到系统用例的过度，概念用例只能起到获取用例的指导作用
- 系统用例视图，包括参与者、用例，是系统功能性需求的高层视图
- 系统用例规约，采用文档形式描述参与者如何启动和终止用例，参与者如何使用用例完成目标，用例执行的事件流，相应的规则等内容
- 补充规约，说明与用例相关的非功能性需求
- 系统用例规则
- 系统用例实现
- 系统用例场景，描述参与者如何与
计算机交互达成目的，可使用交互图描述 - 分析对象，用例场景中代表
计算机逻辑的概念化产物
获取用例：
通过业务用例建模能够大致推导出来系统用例，通过分析业务用例场景，尤其是活动图（通过永道,能够发现业务主角和业务工人的职责活动），然后在进行如下操作：
- 排除用例，如果参与者不需要使用计算机，那么可以排除这个候选用例
- 合并用例，如果用例的结果相似，可以考虑合并这些候选用例
- 抽象用例，通过分析归纳业务用例场景，发现一些用例中存在一些相同的过程，可以抽象出一个描述这些相同行为的用例
- 补充用例，增加与业务实现无关，但是对系统运行必须的非业务需求，如备份系统数据等
完整的系统用例模型如下：
粒度选择
业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，可以描述一项完整的业务流程
概念建模阶段，用例的粒度以每个用例能够描述一个完整的事件流为宜，可以描述一项完整业务流程中的一个步骤
系统建模阶段，用例的视角是针对计算机的，用例以一个用例能够描述操作者与计算机一次完整的交互为宜，另外一个参考的粒度是用例的开发工作量在一周左右为宜
不论粒度如何选择，必须把握在同一个需求阶段，所有的用例粒度是同一个量级的
另外，需要着重强调一点，粒度选择的本质还是边界认定不同而产生的，如果对选择粒度感到困难或者同一个阶段的粒度大小不一致情况，应该确认是否选择一个正确的边界并随时检察是否越过了边界
在我们进行用例建模的时候一定要注意边界的选择，我们说的用例的粒度必须是在同一个边界下说的。在对大型复杂需求分析的时候，我们首先可以将边界设置为整个业务，然后通过这个边界，我们分析内部逻辑，抽象识别出一些模块，然后在对这些模块使用边界，这时候，一个模块就是一个边界，我们在这这个边界内部进行分析。
在概念业务用例建模的时常用的是使用鲁棒图或者说分析类，主要如下几个元素构成：
- 边界类
- 控制类
- 实体类
注：本文绝大部门分来自Thinking In UML 第二版。
标签：模型,系统,业务,建模,用例,粒度,UML 来源： https://blog.csdn.net/LeoHan163/article/details/122096413
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。