在面向对象软件开发的过程中,针对复杂系统,我们一般会先进行相关建模来了解现实世界问题,通过抽象方法,建立模型来表征现实世界,获得对现实事物本身的理解,然后将这些理解到的知识概念化,并将这些逻辑概念组织起来,形成对所观察事务的内部结构和工作原理便于理解的表达。在UML中通过用例驱动的方式来一步一步获取对现实世界的理解。
一般我们通过如下三个用例建模步骤来获取对现实世界问题的认知,然后将其转化为计算机世界的实现,主要有如下三个步骤:
业务用例建模早于需求工作。一般我们常说的需求,或者常说的需求规格说明书指的是系统需求,是指将要搭建的系统需要实现的功能契约,是与计算机世界紧密关联的,仅仅是要在计算机世界实现的一部分业务需求,这部分需求来源于业务需求,业务需求不仅仅是系统需求,还有一部分需求可能是计算机无法实现的,而是人工实现的。业务需求是面向现实世界的,而系统需求则是面向计算机世界的
业务模型是想为现实世界中客户的真实业务建立模型,能够让我们与客户在业务理解上达成共识,这时候是不需要考虑计算机世界的。
业务模型要准确而完备的描述客户的业务,而系统用例可能只是业务的部分或者其中的一环。
在一些比较复杂的场景下,如果不建立业务模型,那么真实的业务链可能就不完整。
业务用例建模主要包含如下内容:
可以通过活动图、时序图、协作图,发下业务用例场景
当系统规模比较庞大复杂时,这时候一般业务用例的粒度会比较粗,但是系统用例的粒度一般比较小,我们要将粗粒度的业务用例转换成较细的系统用例,这时候一般比较困难,而如果将业务用例的粒度弄得比较细,业务用例的数据又会激增。
这时候我们通过
概念用例建模对粗粒度的业务用例进行相关的分析,找到关键、核心的工作单元,针对这些关键核心工作单元来建立模型以便简化业务
通过概念用例建模,我们得到比较核心重要且粒度相对细一些的用例模型,这个模型能够帮助我们从业务用例模型过度到系统用例模型。另外这个模型也能够帮助我们建立业务架构(如果需要)
概念用例建模主要包含如下内容:
概念用例可以通过这几种方式获得:1. 观察所有的业务用例场景,发现那种在不同的业务用例场景中多次出现 2. 通过客户分析获取对客户来说最重要的一些业务实体,然后了解这些业务实体可能进行的操作来获得备选用例 3. 通过绘制概念用例分析来检验备选的概念用例
我们通过分析业务用例得到概念用例,然后通过活动图、时序图、协作图对概念用例进行分析,根据分析结果,在集合鲁棒图、时序图、协作图、状态图,得到用例实现
完整的概念用例模型如下:
系统建模就是我们常说的需求获取,系统用例也可以省去系统二字,就是我们常说的用例
。用例模型定义为系统既定功能及系统环境的模型,可以作为客户和开发人员之间的契约。
如果需求分析是从业务用例模型开始,那么到系统用例模型应该有足够信息来源来获取系统用例,如果没有业务用例建模,而是直接从系统用例建模开始,那么系统用例模型将从涉众请求开始,将涉众请求直接转化为用例模型。
系统用例模型主要内容如下“
计算机
交互达成目的,可使用交互图描述计算机
逻辑的概念化产物获取用例:
通过业务用例建模能够大致推导出来系统用例,通过分析业务用例场景,尤其是活动图(通过永道,能够发现业务主角和业务工人的职责活动),然后在进行如下操作:
完整的系统用例模型如下:
业务建模阶段,用例的粒度以每个用例能够说明一件完整的事情为宜,可以描述一项完整的业务流程
概念建模阶段,用例的粒度以每个用例能够描述一个完整的事件流为宜,可以描述一项完整业务流程中的一个步骤
系统建模阶段,用例的视角是针对计算机的,用例以一个用例能够描述操作者与计算机一次完整的交互为宜,另外一个参考的粒度是用例的开发工作量在一周左右为宜
不论粒度如何选择,必须把握在同一个需求阶段,所有的用例粒度是同一个量级的
另外,需要着重强调一点,粒度选择的本质还是边界认定不同而产生的,如果对选择粒度感到困难或者同一个阶段的粒度大小不一致情况,应该确认是否选择一个正确的边界并随时检察是否越过了边界
在我们进行用例建模的时候一定要注意边界的选择,我们说的用例的粒度必须是在同一个边界下说的。在对大型复杂需求分析的时候,我们首先可以将边界设置为整个业务,然后通过这个边界,我们分析内部逻辑,抽象识别出一些模块,然后在对这些模块使用边界,这时候,一个模块就是一个边界,我们在这这个边界内部进行分析。
在概念业务用例建模的时常用的是使用鲁棒图或者说分析类,主要如下几个元素构成:
注:本文绝大部门分来自Thinking In UML 第二版。