3.1 参与者,Actor
参与者,定义了用户在系统交互过程中扮演的角色,其可以是一个人,也可以是另一个相关的系统。
3.2 用例,Use case
用例实例(场景)是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果,一个用例定义一组用例实例(场景)。
一个用例应为参与者提供(实现)一个价值。
3.3 事件流
就像类对应于对象一样,一个用例的实例就是使用场景,用例就是对使用场景进行抽象的总结:
1)前置条件:指在用例启动时,参与者(Actor)与系统应置于什么状态,这个状态应该是系统能够检测到的、可观测的;
2)后置条件:用例结束时,系统应置于什么状态,这个状态也应该是系统能够检测得到的、可观测的;
3)基本事件流:基本事件流是对用例中常规、预期路径的描述,也被称为Happy day场景,这时大部分时间所遇到的场景;它将体现系统的核心价值;
4)扩展事件流:主要是对一些异常情况、选择分支进行描述。
建议大家在编写事件流时,注意以下几点:
1)使用简单的语法:主语明确,语义易于理解;
2)明确写出 "谁控制球":也就是在事件流描述中,让读者直观地了解是参与者在控制还是系统在控制;
3)从俯视的角度来编写:指出参与者的动作,以及系统的响应,也就是第三者的角度;
4)显示过程向前推移:也就是第一步都有前进的感(例如,用户按下tab键做为一个事件就是不合适的);
5)显示参与者的意图而非动作(光有动作,让人不容易直接从事件流中理解用例);
6)包括 "合理的活动集"(带数据的请求、系统确认、更改内部、返回结果);
7)用 "确认"而非"检查是否":(如系统确认用户密码正确,而非系统检查用户密码是否正确);
8)可选择地提及时间限制;
9)采用 "用户让系统A与系统B交互"的习惯用语;
10)采用 "循环执行步骤x到y,直到条件满足"的习惯用语。
四、Alistair Cockburn眼中的用例分析技术
在使用用例分析技术时,很多人都觉得如何确定用例的粒度是一个难点,而且感觉到用例没有什么规则遵从,甚至有无所适从的感觉。正如Cockburn先生提出的学习用例分析技术的 "守、破、离"的三个阶段:
1)守:练习基本功夫,遵循规则,照章行事;
2)破:能突破传统,因地制宜地灵活应用; 3)离:超脱任何招式与规则,达到无招胜有招的境界。
但用例分析技术却让第一阶段的初学者感到无法很快地掌握。而其所著 "编写有效用例"则想为用例分析技术补充规则,让大家能够更好地掌握。
Cockburn先生在Ivar Jacobson的基础上,做了一些补充:
1)用例是契约,是系统与涉众之间达成的契约。也就是将用例朝着形式化的方向发展;
2) 将用例分成三级:
◆ 概要级:包括多个用户目标(显示用户目标运行的语境,显示相关目标的生命周期、为低层用例提供一个目录表);
◆ 用户目标级
◆ 子功能级
不过,对于Cockburn先生的贡献,用例始祖Ivar大师并未做出任何反应。本人在实践中认为,Cockburn先生的思路与理念对于初学用例分析技术的人来说,十分有价值,使得用例分析技术更具操作性,当其同时也有点画地为牢的感觉,也许Cockburn先生也意识到这点,因此第三阶段就是 "离",没有规则,按需灵活使用。
五、如何在开发过程中应用用例分析技术
用例分析技术在需求过程中的地位如下图所示: