(3565**79) 2012-08-01 13:32:25
潘老师，报表、计划都是为了管理层服务的，属于系统用例吧？
(3565**79) 2012-08-01 13:33:10
在业务用例中不会体现
潘加宇 (3504847) 2012-08-01 13:34:05
"业务用例"不会体现
"业务用例"的实现"业务序列图"会有的
(3565**79) 2012-08-01 13:34:28
业务序列图只会使用计划
(3565**79) 2012-08-01 13:34:48
可是计划的设置是由很多功能组成的
潘加宇 (3504847) 2012-08-01 13:35:17
属于支撑的流程，也要画出来的
组织中的所有活动都要看作是为某个业务用例的实现做贡献
潘加宇 (3504847) 2012-08-01 13:35:57
"计划的设置是由很多功能组成的"这句话不严谨，尝试表达得更清楚一点
(3565**79) 2012-08-01 13:36:05
报表相关要求在业务序列中没有出现，是不是我画漏了？
潘加宇 (3504847) 2012-08-01 13:37:08
第一条路线是主要的，思考的焦点是"执行者对组织的期望和组织对执行者的承诺"的平衡点，注意不要出现"患者到医院挂号"的用例。第二条路线用于补漏，找到之前可能会遗漏的执行者和用例。
采用第二条路线思考时，会出现的一个错误是直接将内部活动作为业务用例。只要了解基本道理，稍加注意就可以避免这个错误。这条路线还引出一个值得商讨的话题：管理型业务用例。
例如，公交公司里有调度员负责制订运营计划，计划哪条线路配备多少台车，配备多少司机，每天多少个运行班次，每班的发车时间。如果以公交公司为研究对象，调度员是业务工人，所以"调度员à制订运营计划"不是业务用例，那么这个工作归属于哪个业务用例呢？通过思考调度员为什么要"制订运营计划"，一直向外推，可能会得到类似"公司董事会：提高公交线路效率"这样的用例，即管理型业务用例。
以前我也支持这样的做法，但是发现这样的"管理型业务用例"很容易被滥用，而且容易和愿景混淆。现在我更倾向于将这样的流程归纳到类似于"市民->乘车"这样的用例下面。如果研究对象是公交公司，调度流程是乘车的支撑流程。业务用例是组织为组织服务，在不同的场景中，两个组织的各种系统形成不同的交互。
(3565**79) 2012-08-01 13:37:13
如设置计划项目、计划周期、不同单位的计划关系等
潘加宇 (3504847) 2012-08-01 13:37:24
图3-15 实现业务用例的不同场景
"管理型业务用例"还隐含另一个问题：也许现在挑选的研究范围并不合适。如果调度流程是需要改进的核心流程，说明选择公交公司为研究范围不合适，应该缩小为公交公司调度室。
潘加宇 (3504847) 2012-08-01 13:38:15
"设置计划项目、计划周期、不同单位的计划关系"这些事情不会无缘无故发生的
潘加宇 (3504847) 2012-08-01 13:39:16
你要从组织的角度看，如果不"设置计划项目、计划周期、不同单位的计划关系"，会怎么样？找到所对应的组织的价值（即业务用例），把相应业务流程画在该用例下面
潘加宇 (3504847) 2012-08-01 13:40:11
"设置计划项目、计划周期、不同单位的计划关系"很可能不会是同一时间内做的，也可能不是同一个人做的，也可能不是在一个业务流程里做的
(3565**79) 2012-08-01 13:40:14
"设置计划项目、计划周期、不同单位的计划关系"这些事情不会无缘无故发生的
是为了在支付这个业务中使用计划，没有计划就不能支付
潘加宇 (3504847) 2012-08-01 13:41:38
切不可这样想，"里面都修改了计划的数据，所以看成一件事情"，这就变成了从内部设计来分割业务流程了
潘加宇 (3504847) 2012-08-01 13:42:13
你就在支付下面画业务序列图，一个用例下面可以画很多张业务序列图
潘加宇 (3504847) 2012-08-01 13:42:36
参见场景4