建模与设计
我们经常说：“使用用例对业务过程进行重组”，其可能意味着：
“在重组前，通过用例对其原过程文档化。”
“通过用例创建符合设计要求的外部行为需求。”
“重新设计后，使用用例对新过程文档化。”
事实上，所有这些含义都应该是对的，并且都值得关注。读者可以按自己的意愿去理解其中的一个。
但是通常在谈论用例时，我总是说业务过程建模或文档化，而不是业务过程重组或设计。因为用例仅仅是对过程文档化，不能代表过程重组或设计。在创造性设计时，设计者需要经历一个思维跳跃的过程，但用例不能告诉他们怎样去做。通常，每个层次文档所描述的是下一个层次设计必须满足的行为需求（实际上，我们却说“这次设计满足这些行为需求”）。
引入新技术经常会导致业务过程改变。它们分别是从面向技术的核心业务，从新业务过程到技术，及从技术直接驱动，对业务过程进行重组。这些方法中的任何一种方法都是可行的。
从核心业务
在这种自上而下的分析方法中，正如Reengineering the
Corporation一书（Hammer，1984）中所描述的那样，首先应该仔细识别组织中的核心业务。在这步工作结束时，应该弄清楚：
在组织行为中的项目相关人员；
该组织必须满足其需求的外部主执行者；
该组织必须响应的触发事件；
该组织提供的服务，以及对项目相关人员的成功结果。
注意，上面的内容并没有指出该组织如何工作，而只有设定其行为边界条件的信息。通常，它们也是用例的边界信息：项目相关人员与利益、主执行者与目标，以及成功保证。
业务过程设计的环境可以采用业务黑盒用例进行记录，公司或组织作为被设计系统（如图15-1所示）。
在这个阶段，可以充分利用当前新技术，创建新资源组和新过程组。当今社会，计算机系统成为组级主要的动态存储和动态通信渠道。在Reengineering the Corporation这本书中，给出了许多不同改革行动导致不同业务设计的例子，当然它们的效率也不一样。结果是产生一个新的公司或组织设计（如图15-2所示）。
过程革新的结果，就是用白盒用例对系统文档化。这些用例展示了人与各部门（也可能是计算机）之间的交互作用，以及这些作用所产生的组织外部可见行为。
另外，开发真正完备的白盒用例，应该与任何完整用例集或业务过程模型一样，考虑系统失败及异常处理等情况。当然，在此过程中可以选择命名用例中的技术，或若满足系统需求则不命名。
本文节选自《编写有效用例》一书
[美]Alistair
Cockburn（阿利斯泰尔.科伯恩) 著
王雷，张莉译
电子工业出版社出版
图书详细信息:
http://www.cnblogs.com/broadview/archive/2012/07/11/2586451.html