[全程建模]系统用例与业务用例的讨论之二——系统用例是如何产生的
北京-FireSpider 男 15:45:39
关于业务用例和系统用例，我还是有点糊涂。我总觉得业务用例应该是客户方的。不论业务用例是基于信息系统的还是手工的。而开发方在构建信息系统时应该没有业务用例的概念，只有系统用例的概念。只不过有些系统用例是实现业务用例，有些系统用例没有相关的业务用例，仅是为系统起支撑作用而已。
青润 15:46:12
你好像是理解错了。
北京-FireSpider 男 15:46:36
是，根据您哪天说的，应该是理解错了。
青润 15:47:03
业务用例都是用户业务相关的用例。
系统用例是为了构建整个系统才提出来的，诸如：权限管理，角色设定之类的。
北京-FireSpider 男 15:47:29
您的意思是这样的吧：
1、系统中与业务无关的用例是“系统用例”。
2、与业务有关的用例是“业务用例”。
青润 15:48:20
系统用例本身不会支持用户的直接业务。
但是，类似邮件这类用例会因为属于新业务的增加而扩展了用户业务范围产生的用例，虽然以前用户没有邮件相关的业务操作（在手工工作的方式下），但是因为邮件触发了新的业务形式带来的用例，仍然是业务用例，而不是系统用例。
fochaillee15:48:19
搞得这么纠结
北京-FireSpider 男 15:48:58
如果是这样的话，业务模型中应该只有业务，没有用例的概念，用例（不论是业务用例还是系统用例）都应是系统的概念？
青润 15:49:21
业务用例，其实就可以认定为用户的业务需求。
北京-FireSpider 男 15:49:38
如果权限是用户要求的呢？
青润 15:49:58
业务用例被称为business uc
转换为开发用的用例的时候，一般会进行拆分或者组合。
在人工操作的时候，权限这类用例是通过任命解决的，也就是人脑子中存在的一个位置，它并不表现在日常的操作中。
青润 15:51:23
所以，它就是系统用例。
可能会在一些会签，批文等上面表现出某个人的职位，但是实际上，这并不是用户业务中直接需要管理的部分。往往是已经指定的。
北京-FireSpider 男 15:52:03
哦，也就是说，当系统中提供的功能，在日常业务处理中不会用到，但在系统中却支撑用户进行业务操作的功能，就是系统用例？
青润 15:52:06
因为这里的权限是指在业务系统中，对数据的操作权限，这些数据在以往都是纸面上表现出来的，并没有目前的数据库系统，也就是说，它不是物质形态存在的。
或者可以这样说，好像也不是特别恰当。
因为你的权限系统所管理的东西，并不是现实中的权限和职位。
青润 15:53:24
只是这个权限和职位的映射。
青润 15:55:10
有些例子不太好举，我考虑一下如何表达能够更清晰。
北京-FireSpider 男 15:56:02
哦，是这样。在全程建模中，业务用例来自于现实的业务，很好发现，但系统用例怎样发现出来？
我知道有些是通过经验发现的，比如权限，因为所有的业务系统都要有权限。
青润 15:58:10
嗯。
系统用例是在构建系统的时候，进行业务间关系表示中逐渐推到出来的必须独立存在的用例。
除了权限，还有日志管理（用于安全监督的功能），包括日志记录、日志分析、日志统计和报警处理，最后这个报警处理往往是需要根据经验设定报警界线然后实现的。
同样的还有类似异常处理管理。
说实话，我最近10年看到的系统中，如我当年那样进行系统的异常处理开发的，还真没有。
北京-FireSpider 男 16:00:29
嗯。
是不是系统用例需要依靠相应的系统用例列表和客户的需要来发现和确认？
比如：目前有权限管理、日志管理、异常管理等等，那么如果客户需要权限管理，我就根据权限管理的规范来生成相应的系统用例？
青润 16:01:57
可以这样认为。
系统用例是逐渐发现的，最开始都是因为系统运行不下去后提出的解决办法形成了新的系统用例，后来逐渐就成为经验积累后形成的设计——这也就是经验丰富的设计人员和新手之间的巨大差别。
而这些是不可能在类似普通的面试中得到的。
北京-FireSpider 男 16:03:19
呵呵，最早发现并制定这些系统用例的人，应该是最牛的，开拓者呀。
青润 16:04:02
呵呵，最开始的系统开发没有用例的概念，所以，随着用例概念的提出，初始的系统用例就已经形成了。
北京-FireSpider 男 16:04:09
后来的人，都只是根据用户的需要，加入这些系统用例而已。
青润 16:04:39
是的。
北京-FireSpider 男 16:04:53
但是在业务领域建模时，不涉及微机的概念，却也有用例的概念。
青润 16:05:11
是的。用例是一个大的概念。
北京-FireSpider 男 16:06:13
此时的用例和前面所说的系统内的业务用例有啥区别和联系？
青润 16:07:16
业务用例都要进行分析，然后分离出系统可以实现的用例和不可以实现的以及外部用例。
系统可以实现的用例，就是本系统内的用例，不可以实现的用例一般是用户的天真想法或者在短时间内无法做到的技术实现，外部用例就是需要与其他系统挂接，从其他系统中获取结果的用例。
北京-FireSpider 男 16:13:00
哦，当系统上线后，基于系统的业务，就属于是新的业务用例？
青润 16:13:37
不可实现的用例，将来也可能变成可实现的用例，这一点是需要提醒出来的。
北京-FireSpider 男 16:15:43
嗯，谢谢老师。我先想想。