用例图在需求分析阶段起到很重要的作用,它将用例图形化,给人直观,便捷感觉。
这篇就讲述下需求分析阶段所涉及到用例及用例图的内容。
一.需求分析和用例 的一些基本概念:
需求:系统(或者项目)必须提供的能力和必须遵从的条件。
用例:是文本形式的情节描述,用于需求的发现和记录,用例会影响后续的ooa&d工作。
参与者(actor):某种据用行为的事物,可以是人(由角色标识)、计算机系统或者组织。
场景(scenario):是参与者和系统之间的一系列特定的活动和交互。
包括:主成功场景和交替场景(主路径和扩展路径)
系统边界:参与者是系统外部有行为的事物,内部事物不叫参与者。
系统边界是由要开发的系统的,随着需求想法的不同而不同。
二.用例应用注意事例:
用例的目的 :用例强调用户的目标和观点
需求分析时应该考虑的问题 :
谁使用系统?他们的使用的典型场景是什么?它们的目的是什么?
用例编写的形式 :
摘要--需求分析早期使用,通常用于主成功场景。
非正式--需求分析早期使用,可以覆盖不同的场景。
详述--详细编写所有步骤及各种变化。
用例的名称应该使用动词开始。
编写用例的时候应该尽量使用行业的专业名称,而不是计算机专业术语。
三.如何发现用例:
1.选择系统边界
2.确定主要参与者
3.确定每个主要参与者的目标(合适的用例粒度:基本路径10步之内)
4.定义满足用户目标的用例,根据其目标对用例命名。
真实项目发现用例的一种思维习惯--了解企业的架构和权力分布 :
调研需求时最先弄清楚有多少个部门、多少个岗位(参与者);
然后找到每个岗位的业务代表,问他们类似的问题:
平时都做什么?(参与者目标)
这件事情是谁交办的?
做完后需要通知或者传达给谁?
做这件事情需要写些什么表格?(了解数据的属性,以便自己整理)
四、用例关联以及一些术语
包含关系--主要目的是避免用例文本的重复编写。
扩展关系--可以讲可选路径中的场景抽象为扩展关系(但一般是没有必要的)。
泛化关系--两个或者更多的用例咋行为、结构、目的等方面存在共性时,可以使用泛化关系。
PS:用例彼此之间可能具有联系。
避免陷入用例关系的陷阱:不要话太多时间争论在用例图中如何关联用例,而不关注更重要的编写用例文本。