3.3 基于场景建模

用户满意度是度量基于计算机系统或产品成果的最重要的方式之一。因此，如果软件工程师了解最终用户（和其他参与者）希望如何与系统交互，软件团队就能够更好、更准确地刻画需求特征，完成有针对性的分析和设计模型。因此，使用UML需求建模将从开发用例、活动图和泳道图形式的场景开始。

3.3.1 新建初始用例

用例从某个特定参与者的角度出发，采用简明的语言描述一个特定的使用场景。如果想让用例真正有价值，就必须知道：①编写什么？②应该有多详细？③如何组织说明？

需求工程工作首先是起始和导出，它们提供了开始编写用例所需要的信息。运用需求收集会议、QFD和其他需求工程机制来确定干系人，定义问题范围，说明整体运行目标，建立优先级顺序，概述所有已知的功能需求，描述系统将处理的信息（对象）。

开发用例时，应列出特定参与者执行的功能或活动。这些可以从所需系统功能的列表，通过与干系人交流，或通过评估活动图（作为需求建模中的一部分而开发）获得。

3.3.2 细化初始用例

为了全面理解用例描述功能，描述交互操作是非常必要的。因此，主场景中的每个步骤将通过如下提问得到评估。

●在这一状态点，参与者能进行一些其他动作吗？

●在这一状态点，参与者有没有可能遇到错误的条件？如果有可能，这些错误会是什么？

●在这一状态点，参与者有没有可能遇到其他行为（如由一些参与者控制之外的事件调用）？如果有，这些行为是什么？

这些问题的答案导致创建一组次场景（Secondary Scenarios）。次场景属于原始用例的一部分，但是表现了可供选择的行为。

用例应该注明异常处理，即如果软件能检测出异常所发生的条件，就应该在检测出后马上处理这个条件。在某些情况下，异常处理可能拖累影响其他用例处理条件的开发。

3.3.3 编写正规用例

当一个用例包括关键活动或描述一套具有大量异常处理的复杂步骤时，应采用更为正规的方法。在很多情况下，不需要创建图形化表示的用户场景。然而，当场景比较复杂时，图形化表示将更有助于理解。UML提供了图形化表现用例的能力。图3-8所示为SafeHome产品描述了一个初步的用例图，每个用例由一个椭圆表示。

图3-8 SafeHome系统的初步用例图

每种建模注释方法都有局限，如果描述不清晰，用例也可能会误导或产生歧义。一个用例关注功能和行为需求，一般不适用于非功能需求。用例方法不适用于必须特别详细和精准的需求建模情景（如关键安全系统），但软件工程师会遇到的绝大多数情境都适用于基于场景建模。如果开发得当，用例是重要的建模工具之一。