（1）--什么是用例
我发现，在OO和UML几乎一统天下的今天，仍有很多系统分析员对OO和UML一知半解，甚至包括很多已经使用了很久UML的系统分析员。
于是打算写一个系列文章，将多年来的工作经验做一个总结。对初学者起个启蒙作用，也希望抛砖引喻，与各路大虾共同探讨，共同提高。
这个系列文章将以我对OO和系统分析的理解为主，从UML基础开始，阐述面向对象的需求分析方法，过程，并以RUP为例，阐述如何将OO过程与软件过程有机结合在一起，做一个真正OO应用。
好了，今天是第一篇。想得很远，真希望我能坚持下去，呵呵
用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。
这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。
最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。
如果用例不是功能的话，它是什么呢？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？我的回答是：错！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入-->计算-->输出。这让你想到了什么？DFD图？这可是典型的面向过程分析模式。因此我说把用例当做功能点的分析员实际在做面向过程的分析。
而用例则不是计算机术语，UML除了在计算机行业中应用，它也经常被应用在其它行业中。用例是一种需求方法学，虽然软件危机和OO的发展促成了它的诞生并被完美的融合进了OO体系，形成了
UML，但它实际上并不是软件行业的专用品。如果非要从功能的角度解释，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式。实际上，把用例解释为某个参与者(actor)要做的一件事可能更为合适。这样的一件事有以下几个特征：
一、这件事是相对独立的。这意味着它不需要与其它用例交互而独自完成参与者的目的。也就是说这件事从“功能”上说是完备的。读者可能会想到，用例之间不是也有关联关系吗？比如扩展，比如实现，比如继承，它看上去并不是独立的嘛。关于这个问题，笔者会在后续的文章里详细说明。这里稍微解释一下，用例之间的关系是分析过程的产物，而且这种关系一般的产生在概念层用例阶段和系统层用例阶段。对于业务用例，这个特征是很明显的。
二、这件事的执行结果对参与者来说是可观测的和有意义的。例如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。又比如说，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？
三、这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例总是由一个参与者发起，并且满足特征二。例如从ATM
取钱是一个有效的用例，ATM吐钞却不是。因为ATM是不会无缘无故吐钞的，否则，我从此天天守在ATM旁，生活无忧矣。
四、这件事必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的，但是笔者所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。
除去以上的特征，笔者觉得用例的含义还要更深些。首先，用例的背后是一种需求方法论。其核心是以参与者为中心（区别于以计算机系统为中心），从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式），并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。换句话说，用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作了。其次，用例简直就是为OO而生的，其思想完美的符合OO。用例分析方法试图找到问题领域内所有相对独立的参与者和事件，并把业务流程当成是这些参与者和事件之间的交互结果（在UML用活动图或序列图来描述）。因此，用例方法被吸纳到OO之后，UML得以以完备的形式出现，用例成为了真正的OO核心。在
RUP里，这种核心作用被发挥到极致，产生了用例驱动（usecase driven）的软件过程方法，在RUP里，软件生产的所有过程和产物都是围绕着用例形成的。
可以说，用例分析是OO的第一步。如果用例分析本身出了问题，对业务架构，软件架构的影响是很大的，将大大削弱OO的优势--复用、扩展。笔者认为软件复用可以分为三个层次，最低层次的复用是代码级复用，这是由OO语言特性提供支持的，例如继承，聚合，多态；较高层次的复用是组件级复用，这是由设计模式提供支持的，例如Factory模式,
Builder模式；最高层次的复用则是服务级复用，这在很大程度上是由应用服务器和通讯协议来提供支持的，例如最近炒得火热的SOA（面向服务的应用）架构。用例分析的好坏也许对代码级和组件级的复用影响不太大，但对服务级的复用影响却是巨大的。笔者认为服务级复用是OO的最高境界，而结构良好的用例分析则是达到这一境界的基础。
闲话：
今天你OO了吗？
如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到下一个环节的。那么很不幸，你还在做面向过程的事情。
如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？....那么恭喜你，你已经OO啦！
（2）--用例的类型与粒度
在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
先说说用例类型的问题。
用例类型，有的资料翻译为版型，英文原文是stereotype。在Rose中默认的类型有business
usecase , business usecase realization和use case realization三种。相应的，就是指
业务用例：
业务用例实现：
用例实现：
若不指定类型，则它就是通常意义上的use case ：
Rose中定义了上述默认类型，但是也可以自定义用例类型。初学用UML建模的人常常在这些类型中迷失，搞不清楚这些类型是什么含义，什么时候该使用什么类型。简单说，需求分析中的各个阶段要描述和分析的目标不同，为表达不同的视角和分析目标，需要使用不同的用例类型。笔者的观点是，用例类型的区分是为了形式上的统一，但用例类型既然可以自定义，它就是一个很灵活的用法，不必墨守成规，大可在工作中根据实际情况定义适合自己项目特点和软件过程的用例类型。不过，默认的用例类型已经几乎可以满足需求分析的各个阶段，自定义的必要性并不大，并且UML的意义就是使用统一的形式描述需求，因此最好使用默认的类型。
说到需求分析阶段，那么需求分析都有些什么阶段呢？一般来说，需求分析要经过业务建模，用例分析和系统建模三个阶段才能完成需求工作，这三个阶段分别做什么笔者会在以后的文章的详细阐述，这里为了说明用例类型的含义和使用，先简单介绍一下。
1、业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生。这个阶段通常使用业务用例和业务用例实现两种类型；
2、用例分析是系统分析员采用OO方法来分析业务用例的过程，这个阶段又称为概念模型阶段。这个阶段通常使用无类型的用例。用例分析是一个过渡过程，但笔者认为其非常重要，业务架构通常在这个阶段产生。
3、系统建模是将用户的业务需求转化为计算机实现的过程。这个阶段通常使用无类型的用例和用例实现两种类型。系统范围，项目计划，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。
所谓business usecase，是用来描述用户原始需求的，它的含义是站在用户的角度，使用用户的业务术语来描述用户在其业务领域所做的事情。业务用例命名，描述都必须采用纯业务语言，而不能出现计算机术语。因为业务模型是系统分析员与用户讨论需求，达到一致理解的基础，必须使用用户熟悉的，不会有歧义的专业术语以避免系统分析员与用户对同一事件的理解误差。business
usecase realization是达到需求可追溯要求的一个连接点，是用户在其业务场景中如何做这一件事的载体。
笔者自己在用例分析和系统建模阶段不区分用例类型，都使用无类型的use case，但在这两个阶段，用例的含义还是有所差别的。用例分析阶段，用例主要是从
业务模拟的概念上，从OO的视角来分解、组合业务用例，粗略的建立一个业务架构。而在系统建模阶段，用例主要是从计算机视角描述需求，规定开发范围，作为项目计划的依据，为系统设计做准备。usecase
realization的含义可从business use case realization推知。
再来说说用例的粒度问题。
粒度是令人迷惑的。比如在ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例，显然，取钱包含了后续的其它用例，取钱粒度更大一些，其它用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小用例合适呢？这个问题并没有一个标准的规则，笔者可以给大家分享的经验是根据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到验证密码，填写申请单，查找书目等业务中的一个步骤。在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽象业务用例中的概念模型。例如，宽带业务需求中有申请报装，申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料，受理业务，现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单，审核申请单，派发任务单等。可理解为一个操作界面，或一个页面流。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。
上述的粒度划分方法笔者是用相对比较具体化的一些依据来说明。实际上，用例粒度的划分依据（尤其是业务用例）最标准的方法是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。这个说法比较笼统，也比较难以掌握。，举个例子，某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段话中能得出多少用例呢？请记住一点，用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。这样，实际上适合用例是：借书。只有一个，其它都只是完成这个目的过程--这里讨论的用例指的是业务用例--这个例子是比较明显的能够区分出参与者完整目的的，在很多情况下可能并没有那么明显，甚至会有冲突。读者可以从自己实际的情况去找出这种例子。以后的文章中笔者会做一些讨论。
但是上述的粒度选择并不是一个标准，只是在大多数情况下这样的粒度选择是比较合适的。笔者的意思也不是告诉读者上述哪一种是最好的，而只是把一些常用的比较，划分方法告诉读者，期望的是帮助读者在工作实践中自己总结出一套适合自己的方法来。现实情况中，一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。比如，
针对一个50人年的大型项目应该选择更大的粒度，如果用例粒度选择过小，可能出现上百甚至几百个业务用例，造成的后果是需求因为过于细碎和太多而无法控制，较少的用例有助于把握需求范围，不容易遗漏。而针对一个10人月的小项目应该选择小一些的粒度，如果用例粒度选择过大，可能只有几个业务用例，造成的后果是需求因为过于模糊而容易忽略细节。一般来说，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。
不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。这应该很好理解，在描述一栋建筑时，我们总是把高度，层数，单元数等合在一起介绍，而把下水道位置，插座数量等合在一起介绍。如果你这样介绍一栋楼：这栋楼有10层，下水道在厨房东南角，预留了15个插座，共有5个单元，听众一定会觉得云山雾罩，很难在脑子里形成一个清晰的影像。
如果对上面两个问题读者还有疑惑，不用着急，在以后的文章中应该会逐步加深理解。
预告：下一篇文章将通过一个例子，阐述获取用例的一般方法和如何判断用例的粒度是否合适。
Q&A
--------------------------------------------------------------------------
Q：由 pushboy 发布
在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。"
"在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。"
那么，这样一个场景 —— 用户管理，有增删改查
这里，是把 用户管理 作为一个用例，还是把增删改查分别作为用例呢？
他们每一个都是一个完整的业务流程和一次完整交互，而且也都是一个actor发起的动作；怎么来确认呢？
我们的前提是一个普通的比如说财务系统，而不是一个用户管理系统
A：这个问题很好，用例的粒度总是在这样左也可右也可之间难以决定。对这个问题来说，我的观点是业务用例应当用“管理用户”或“维护用户”作为合适的粒度，而增，删，改，查则在作为系统用例。我的理由是：
增删改查不能做为一个完整的业务来理解。作为一个管理业务，数据只有先增，才会有改，才会有删。增删改查结合起来才能完成actor的管理目的，只删或只增加都不是业务的全部。是否是一项完整业务，要看actor的目标，而不是事情是否完整。这个例子中，actor的目标是为了增加一个用户吗？是为了删除一个用户吗？都不是，而是为了管理用户，这个目标包括了用户这个实体的整个生命周期。
再讨论深一些，如果业务要求对用户除了增删改查，还有别的要求，例如权限升级，用户在组织机构中复杂的关系变更，用户与外部系统的交互....实际的情况可能会更多，那么，如果将每个都作为一个业务用例，很容易造成一个结果，这些原本与用户这个实体紧密关联，共同组成用户实体生命周期的业务，被割裂成多个独立的业务，因为定义了多个用例（请参看本人第一篇中的用例特征第一条）。要知道，在RUP中，用例驱动的含义是，一个用例就是一个分析单元，设计单元，开发单元，测试单元甚至部署单元。相信读者都知道，把紧密关联的业务分成多个独立部分去实施是高成本的，高风险的。
另外，为什么我要说在系统用例阶段要把增，删，改，查又分出来呢？原因在于，系统用例的目的是为了将actor的业务用计算机模拟出来。我们都知道，一般情况下，增，删，改，查对一个actor来说是不会同时发生的，每次actor只会完成其中的一个行为。分开来，有利于详细分析模拟这一行为的细节而不至于混淆。另一方面，对WEB应用来说，针对数据的增，删，改，查等，很容易形成所谓的“模板”，增加用户用这个模板，增加其它基础数据可能也用同一个模板，无非是操作的数据（实体）不同而已。因此，在很多情况下，这些模板是可以复用的。对这个例子来说，在系统用例阶段，我们可以用“管理用户”
include “增加用户”来表示这个实现关系，同时，让“增加用户”，“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例，这样，可复用的模板体现在“增加数据”用例上，而具体业务，则体现在“增加XX数据”上。实际上，这也是一种OO思想的体现。
只有一个查询是比较特殊的，查询一般不一定只局限于一个actor，也不一定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情况，查询可以作为一个业务用例出现。
（3）--业务建模之涉众
从这一篇开始，笔者将借助一个虚拟的实例来阐述获取用例的方法，以及如何判断用例获取是否完备，粒度选择是否合适。事实上，在做这些工作时，我们正在进行需求分析的第一个阶段，即业务建模阶段。借助这个例子，笔者同样会阐述业务建模到底应该做什么，做到什么地步才能说明业务需求已经完整，可以称为一份完整的需求规格说明书了。
一般来说，只有当以下工作都完成，才能说业务模型建立完成，它们是：
- 发现和定义涉众
- 画定业务边界
- 获取用例
- 绘制用例场景图
- 绘制业务实体模型（领域模型）
- 编制词汇表
下面笔者开始就一个事例来说明如何完成这些工作，这只是一个虚拟的事例，它的合理性和真实性请读者不必追究。
现在我们接到一个项目，是一个网上图书借阅系统，初步跟客户接触，网上图书馆的业务负责人这样告诉我：
我们原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便，而且随着藏书的增加和读者群的增长，尤其而且大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借/还书，这样可以省掉大量的场地维护和工作人员成本支出，同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，我们已经联系了A特快专递公司和B城市物流公司，初步达成协议，由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要付费的。还书也是基本同样的过程。
好了，通过这番谈话，我们已经基本上了解了系统目标。一些着急的系统分析员已经准备开始着手询问借书的流程，借阅人的资格认证问题了，甚至有的人已经凭借多年的开发经验在脑海中绘制出了一幅网页，考虑如何实现这个系统了。
笔者要说的是，请您千万不要着急往下走。因为我们得到的仅仅是一个由非计算机专业人员规划出的很粗略的构想，其可行性如何都尚未得到证实，在这样的基础下就开始细化，将来出现反复甚至失败的危险是很大的。
在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business
Actor 。有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。
什么是涉众？涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意思的user是指系统的使用者，这仅是涉众中的一部分。如何理解与业务系统相关的一切人和事？笔者可以给大家分享的经验是通过以下大类去寻找：
业主是系统建设的出资方，投资者，它不一定是业务方。比如可以假设这个图书馆的网络化建设是由一家国际风险投资机构投资的，它本身并不管理图书馆，它只是从资本上拥有这个系统并从借书收入中获得回报。
了解业主的期望是必须和重要的，业主的钱是这个项目存在的原因。若系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。
一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。
业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如CEO，高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分的重要，实际上，系统建设正是业务提出者经营和管理意志的体现。他们的期望一般比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。业务提出者一般最关心系统建设能够带来的社会影响，效率改进和成本节约。换句话说，他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略的，因此留给了系统建设者很大的调整空间和规避风险的余地。
业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一。他们关心系统将如何实现他们的管理职能，如何能方便的得知业务执行的结果，他们如何将指令下达，以及如何得到反馈。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。系统分析员必须要把业务管理者的思路，想法弄清楚，业务建模的结果也必须与业务管理者达成一致。在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法，以规避导致高技术风险或高成本风险的不合理要求。
业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员。他们最关心的内容是系统会给他们带来什么样的方便，会怎样的改变他们的工作模式。他们的需求最细节，系统的可用性，友好性，运行效率与他们关系最多。系统界面风格，操作方式，数据展现方式，录入方式，业务细节都需要从他们这里了解。他们将成为系统是否成功的试金石。Look
and Feel ，表单细节等是系统分析员与他们调研时需要多下功夫的地方。这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是不统一的，各种古怪的要求都有。他们的期望必须服从业务管理者的期望，因此，系统分析员需要从他们的各种期望中找出普遍意义，解决大部分人的问题，必要时可以依靠业务管理者来影响和消除不合理的期望。
第三方是指与这项业务而关联的，但并非业务方的其他人或事。比如在这个事例中，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上借书系统的一个涉众。
第三方的期望对系统来说不起决定性意义，但会起到限制作用。最终在系统中，这种期望将体现为标准、协议和接口。
另一种典型的第三方是项目监理，系统分析员也必须弄清楚监理的期望。
承建方，也就是你的老板。老板的期望也是非常重要的。老板关心的是通过这个项目，能否赚到钱，是否能积累核心竞争力，是否能树立品牌，是否能开拓市场。老板的期望将很大的影响一个项目的运作模式，技术选择，架构建立和范围确定。比如，老板试图通过这个项目打开一个市场，树立起品牌，不惜成本，那么，系统分析员需要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构，选择那些较新，但风险较高的技术。反之，如果老板只想通过这个项目赚更多的钱，系统分析员就需要引导业务方压缩业务范围，选择风险小的成熟技术，甚至不用考虑业务架构，考虑系统的可维护性，而较少考虑系统扩展能力。
一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？
相关的法律法规是一个很重要的，但也最容易被忽视的涉众。这里的法律法规，既指国家和地方法律法规，也指行业规范和标准。例如，这个借阅系统中要建立借阅人档案，就必须保障借阅人的隐私权；要与网上银行交易，必须遵守信息安全法等。若遇到业务方提出违反了法律法规的要求时，系统分析员要能给他们指出来，说服无果的情况下要在合同里留下免责条款。否则一不小心惹上官司可是件郁闷的事。
另外，有时必须得遵守一些行业规范。例如本事例是网上借阅，网络需求决定了需要遵守HTML规范，才能保证借阅者能正常浏览网页。
用户是一个抽象的概念，是指预期的系统使用者。用户可能包括上述的任何一种涉众。用户涉众模型建立的意义是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的，需要编程实现。而上述的其它涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其它的涉众。在Rose中建模的时候，也只需要建立用户的模型，其它涉众则只需要体现在文档中即可。
这篇文章只能到此为止了，否则太长的话，读者该不耐烦了。只好在此分节。下一节笔者将一步步将涉众的期望导出，并得到需求范围的大致轮廓。
（4）--业务建模一般步骤和方法
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。
本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：
第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。
第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。
第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。
书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。
笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。
建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business
actor 类型。参考上一篇的需求描述
第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business
use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business
actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例
第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity
diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的
business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否
business actor 和 business use case定义不完善或错误。如果不是所有的business
actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business
actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。
第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity
diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。
第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business
entity 类型。
第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。
第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为
boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business
actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business
use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business
usecase下说明。不过本实例中笔者还是按照正规方法来建模的。
需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式。
经过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需要写业务架构文档、用例规约和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。
预告：下一篇笔者将讲述如何根据业务模型建立系统概念模型。这里先说一点，系统概念模型建立最主要依据的是第三步、第四步、第五步建立的业务/用例场景和业务实体模型。这也突显了场景和实体模型的重要程度。
| 
