4.3.4　用例建模

通过用例模型的建立来描述用户需求，建立模型的步骤为：发现和定义涉众、确定系统边界、获取用例、绘制用例图、编写用例规约等。

1.发现和定义涉众

涉众是与要建设的业务系统相关的一切人和事。涉众不等于用户，如何理解与业务系统相关的一切人和事？可通过以下类去寻找：

（1）业主是系统建设的出资方，投资者不一定是业务方，只是从资本上拥有这个系统并从中获得回报。建设成本、建设周期将直接影响到可以采用的技术、可以选用的软件架构、可以承受的系统范围。

（2）业务提出者是业务规则的制定者，一般是指业务方的高层人物，比如CEO、高级经理等，他们制定业务规则，圈定业务范围，规划业务目标，一般最关心系统建设能够带来的社会影响、效率改进和成本节约，系统分析员不必太费心去试图说服他们接受一个意志相左的方案。

（3）业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。业务管理者的期望相对比较细化，是需求调研过程中最重要的信息来源。系统分析员必须把业务管理者的思路和想法弄清楚，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法，以规避导致高技术风险或高成本风险的不合理要求。

（4）业务执行者是指底层的操作人员，是与将来的计算机直接交互最多的人员，他们最关心的内容是系统会给他们带来什么样的方便，会怎样改变他们的工作模式。系统的可用性、友好性、运行效率与他们的关系最多，系统界面风格、操作方式、数据展现方式、录入方式、业务细节都需要从他们这里了解。表单细节等是系统分析员与他们调研时需要多下功夫的地方，系统分析员需要从他们的各种期望中找出普遍意义，解决大部分人的问题，必要时可以依靠业务管理者来影响和消除不合理的期望。

（5）第三方是指与这项业务关联的，但并非业务方的其他人或事，比如在一个系统中，交费是通过网上银行支付的，则网上银行就成为系统的一个涉众，第三方的期望对系统来说不起决定性意义，但会起到限制作用，这种期望将体现为标准、协议和接口。

（6）承建方就是你的老板。老板的期望也是非常重要的，老板关心的是通过这个项目，能否赚到钱，是否能积累核心竞争力，是否能树立品牌，是否能开拓市场。老板的期望将很大地影响一个项目的运作模式、技术选择、架构建立和范围确定。

（7）相关的法律法规。相关的法律法规是一个很重要的，也最容易被忽视的涉众，这里的法律法规，既指国家和地方法律法规，也指行业规范和标准，项目的实现一定要符合法规和标准。

（8）用户是一个抽象的概念，是指预期的系统使用者。用户可能包括上述任何一种涉众，用户涉众模型建立的意义是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的。而上述的其他涉众，则有可能只是在需求阶段有用，最终并不与系统发生交互。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其他的涉众。在Rose中建模时，只需要建立用户的模型，其他涉众则只体现在文档中即可。

（9）定时器是角色，站在系统边界外驱动系统的一切人、事物、甚至规则都有可能是角色，系统边界划定后，边界以内的，只有用例，边界以外的，向系统主动发出动作的，是角色，被动地从系统获得消息的是接口。

2.确定系统边界

系统边界即面对的问题领域，站在边界外的是角色，边界内的是用例，明确系统边界很重要，它决定了用户对系统的视角和能够得出的结果。

3.获取用例

用例分为业务用例和系统用例。业务用例描述业务需求，系统用例描述系统需求。

（1）业务用例：用来捕获功能性需求，功能性需求是由角色的业务目标来体现的。也就是对于角色来说，所负责的业务需要由一系列的业务目标组成，定义满足用户目标的用例，按照这些目标定义用例，业务用例体现了需求。

获取业务用例的方式可以通过数据流图的功能层次划分，也可以通过对用户的描述进行分析获取，用例以能完成参与者目的为依据，要符合基本的“输入—处理—输出”描述。

（2）系统用例：需求的实现有多种方式，如何实现它是由系统用例来体现的，它们并不是一个简单的细分关系。对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪些部分是要纳入系统建设范围的。

（3）两者联系：业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例是完全的直接需求，而是完全的直接需求；系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式。要建设的系统功能性需求由这些系统用例构成，所以，业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。

4.绘制用例图

UML提供用例图来说明参与者、用例及其之间的关系，用例图充当一种交流工具，概括了系统及参与者的行为。画用例图的建议如下：

（1）画出参与者，标识参与者之间的关系。

（2）筛选用例，用优化组合方法解决用例间的冲突和重复问题，描述用例之间的关系，主要关系有：包含、扩展等。

（3）描述参与者与用例之间的关联。

5.编写用例规约

相对于用例图来讲，将用例工作利用文本进行详细描述，为用例分析提供依据，是更加重要的工作。用例规约的书写应包括：

（1）用例名称：按项目规范命名。

（2）执行者：用例的主导者。

（3）用例描述：用例的目的。

（4）前置条件：启动用例的条件。

（5）后置条件：用例结束时应满足的条件。

（6）基本事件流：描述在满足前提条件下启动用例后，按时间顺序执行者与软件系统的相互作用。

（7）异常事件流：按时间顺序描述在正常序列的相互作用中发生异常情况时，软件系统与执行者的相互作用。

（8）备注：应向设计者转达除功能需求以外的非功能需求、设计约束条件和限制，以及有待解决的事项等。