UML笔记（二）--用例图

  用例图在需求分析阶段起到很重要的作用，它将用例图形化，给人直观，便捷感觉。

  这篇就讲述下需求分析阶段所涉及到用例及用例图的内容。

  一.需求分析和用例 的一些基本概念：

     需求：系统（或者项目）必须提供的能力和必须遵从的条件。

     用例：是文本形式的情节描述，用于需求的发现和记录，用例会影响后续的ooa&d工作。

     参与者（actor）：某种据用行为的事物，可以是人（由角色标识）、计算机系统或者组织。

     场景（scenario）:是参与者和系统之间的一系列特定的活动和交互。

                                包括：主成功场景和交替场景（主路径和扩展路径）

    系统边界：参与者是系统外部有行为的事物，内部事物不叫参与者。

                   系统边界是由要开发的系统的，随着需求想法的不同而不同。

 

 二.用例应用注意事例：

     用例的目的 ：用例强调用户的目标和观点

     需求分析时应该考虑的问题 ：

       谁使用系统？他们的使用的典型场景是什么？它们的目的是什么？

     用例编写的形式 ：

         摘要--需求分析早期使用，通常用于主成功场景。

         非正式--需求分析早期使用，可以覆盖不同的场景。

         详述--详细编写所有步骤及各种变化。

     用例的名称应该使用动词开始。

     编写用例的时候应该尽量使用行业的专业名称，而不是计算机专业术语。

 

三.如何发现用例：

    1.选择系统边界

    2.确定主要参与者

    3.确定每个主要参与者的目标（合适的用例粒度：基本路径10步之内）

    4.定义满足用户目标的用例，根据其目标对用例命名。

 

    真实项目发现用例的一种思维习惯--了解企业的架构和权力分布 ：

    调研需求时最先弄清楚有多少个部门、多少个岗位（参与者）；

    然后找到每个岗位的业务代表，问他们类似的问题：

       平时都做什么？（参与者目标）

       这件事情是谁交办的？

       做完后需要通知或者传达给谁？

       做这件事情需要写些什么表格？（了解数据的属性，以便自己整理）

 

四、用例关联以及一些术语 

      包含关系--主要目的是避免用例文本的重复编写。

      扩展关系--可以讲可选路径中的场景抽象为扩展关系（但一般是没有必要的）。

      泛化关系--两个或者更多的用例咋行为、结构、目的等方面存在共性时，可以使用泛化关系。

 

 PS:用例彼此之间可能具有联系。

      避免陷入用例关系的陷阱：不要话太多时间争论在用例图中如何关联用例，而不关注更重要的编写用例文本。