《Thinking in UML》学习1——参与者与用例

一、参与者（actor）

1、参与者的定义

        参与者的定义：actor是在系统之外与系统交互的某人或某事物。它在建模过程中处于核心地位。

       注意：在参与者存在的场景中，系统边界是一个很重要的概念，一提到参与者，我们就必须想到系统边界的存在，否则参与者就是可疑的。

2、怎么找到参与者？

      通过回答下面两个问题来确定：

      * 谁对系统有着明确的目标和要求并且主动发出动作？

      * 系统是为谁服务的？

     参与者也称为主角，记住只有主动启动了某个业务的人或事物，才能称为参与者。

     参与者可以非人，代表功能性的需求的用例有一个特征是：不存在没有参与者的用例，用例不会自己启动。反过来讲，如果一个需求确实找不到启动者，那么我们可以肯定这不是一个“功能性需求”，可能是系统的一个“可用性要求”或“期望的效果”。

3、与参与者有联系的几个概念

       （1）、业务主角（business actor）

         业务主角是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用，是与业务系统有着交互的人和事物，他们用来确定业务的范围。

注：在软件项目中，业务范围和系统范围是不同的，业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都是客观存在的。系统范围是指软件将要实现的那些对应于业务功能的系统功能。

        业务主角的特殊性在于，它针对的是业务人员而非计算机用户，业务主角是非常重要的，建立业务模型、查找业务用例都必须使用业务主角,而不是普通的参与者。

        在初始需求分析阶段，请务必使用业务主角。

       判断业务主角的问题：

       * 业务主角的名称是否是客户的业务术语？

       * 业务主角的职责是否在客户的岗位手册里有对应的定义？

       *  业务主角的业务用例是否都是客户的业务术语？
       *  客户是否对业务主角能顺利理解？

      （2）、业务工人（business worker）

       位于系统边界之内，被动响应主角的需求，以完成主角的业务目标为任务，充当“配角”角色。

       不需要为“业务工人”建立业务模型，他们只在主角的业务模型中出现，经常出现的地方是领域模型和用例场景。

       怎样区分业务工人与参与者？

      首先，如果系统边界确定，最直接的办法是判断是在边界之外还是边界之内？

      如果边界尚不清楚，可以通过以下问题帮助澄清：

              * 他是主动向系统发出动作的吗？

              * 他有完整的业务目标吗？

              * 系统是为他服务的吗？

     如果上述三个问题的答案都是否定的，那一定是业务工人。

      （3）、涉众（stakeholder），也称为干系人

        涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。

4、参与者与其他概念的关系

      （1）、参与者与涉众的关系

       涉众虽然与这个系统有利益相关，但并不是所有的涉众都是系统的参与者。

       参与者是涉众的代表。参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。

       （2）、参与者与用户的关系

        用户（user）是指系统的使用者，通俗一点说就是系统的操作员。

        用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。

        （3）、参与者与角色的关系

        角色（role）是参与者的职责，角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色。一个角色代表系统中的一类职责，例如“文件审批”可能是“办公自动化系统”中的一个职责。

       角色一般适合用在概念阶段的模型里，以表达业务的逻辑理解。

       另外，由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定为多个角色。

5、参与者核心地位的体现

       参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求；参与者通过代理给其他用户或将自身实例化称用户来使用系统；参与者的职责可以用角色来归纳，用户被指定扮演哪个或者哪些角色因此来获得参与者的职责。

       系统是以参与者的观点来决定的。参与者对系统的要求，对系统的表述完全决定了系统的功能性。

6、如何保证发现的参与者是正确的呢？检查点列表

      回答下面的检查点列表中的问题有助于检查发现的参与者是否正确。

      *  是否您已经找到所有的参与者？也就是说，是否您已经对系统环境中的角色都进行了说明和建模？（找到并说明所有用例后才能确定）

      * 每个参与者是否至少涉及到一个用例？删除未在用例说明中提及的所有参与者，或与用例无通信关联关系的所有参与者。

      * 您是否列出至少两名可以作为特定参与者的人员？如果不能，请检查参与者所建模的角色是否为另一角色的一部分。如果是这样，您应该将该参与者与另一参与者合并。

      * 是否有参与者担任与系统相关的相似角色？ 如果有，您应该将他们合并到一个主角中。

     * 是否有两个参与者担任与用例相关的同一角色？如果有，您应该利用参与者泛化关系来为他们的共享行为建立模型。

     * 特定的参与者是否将以几种（完全不同的）方式使用系统？或者，他使用用例是否出于几个（完全不同的）目的？如果是这样，您也许应该有多个参与者。

     * 参与者是否有直观名称和描述性名称？ 用户和客户是否能理解这些名称？ 参与者的名称务必与其角色相符。否则，应对其进行更改。

二、用例（use case）

1、用例的定义

        用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。换句话说，一个用例就是参与者（actor）交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。一个用例的场景称为用例的实例。

        一个完整的用例定义由参与者、前置条件、场景、后置条件构成。

2、用例的特征

**用例是相对独立的

       用例从“功能”上说是完备的。用例本质体现了系统参与者的愿望，不能完整达到参与者愿望的不能称为用例。用例不需要与其他用例交互，而是独立完成参与者的目的。

**用例的执行结果对参与者来说是可观测的和有意义的

**某件事情必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

**用例必然是以动宾短语形式出现的。

       用例必须由一个动作和动作的受体。

**一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至是部署单元。

3、用例的粒度

       在项目过程中要根据阶段不同，使用不同的粒度。例如，在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜，可理解为一个用例描述一项完整业务中的一个步骤。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者和计算机的一次完整交互为宜。

       无论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。

       粒度选择的问题本质上还是因为边界认定不同而产生的。如果用户对选择粒度感到困难，或者出现了同一阶段粒度大小不一的情况，你应当首先确认你是否选择了一个正确的边界并时时检查自己是否越过了这个边界。

    

5、用例的获得

       用例的来源就是参与者对系统的期望。所以发现用例的前提条件是发现参与者。

       * 一个明确的有效的目标才是一个用例的来源。

       * 一个真实的目标应当完备地表述主角的期望。

       *一个有效的目标应该在系统边界内，有主角发动，并具有明确的后果。

6、用例的几个误区

      （1）、用例和功能的误区

        功能和用例很类似，但是从本质上说功能和用例是完全不同的。

       在描述一个事物的时候，我们可以从以下三个观点出发：

       第一种描述：结构性观点，即事物的客观存在，描述事物的构件组成，该观点不能够说明事物的功能性信息。比如描述自行车，说自行车有刹车系统、传动系统等组成。

       第二种描述：功能性观点，说明事物可利用的价值。比如描述自行车，可以骑行，可以载物。该观点不能够说明事物在某些情形下的真正价值，也就是它缺乏上下文环境，没有人来使用。事物的所有可利用价值可能是无意义的。

        第三种描述：使用者观点，说明事物对于使用者的意义，以及使用者可以怎么使用它，得到什么样的利益。它从表面揭示了事物相对于使用者来说是什么，能做什么，可以获得什么。比如说描述自行车，自行可可供使用者蹬踏前进、可以捏合刹车。

        对于已经存在的事物，随便从这三方面的观点来描述，都可以把事物描述清楚，但是对与陌生的事物，甚至是不存在的事物，我们不能从结构观点去描述它，最好的方法是从使用者的观点去描述它。

        从使用者的观点出发描述软件是非常合适的。

        使用者观点实际上就是用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得到结构性的和功能性的内容，最终实现用例，也就实现了使用者的观点。

       总结如下：

      * 功能是脱离使用者的愿望而存在的。它是描述工具的，而不是站在使用者的角度描述使用者的愿望的。用例是描述使用者愿望的，描述的是使用者对系统的使用要求。

      *功能是孤立的，给一个输入，通过计算就有一个固定的输出。用例是系统性的，它需要描述谁在什么情况下通过什么方式达到什么目的。

      *如果非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，对应于不同的应用场景，这些“功能”体现在不同的组合方式。

     （2）、目标与步骤的误区

      用例是一个完整目标，要达到目标要分几个步骤，但只有完整的目标才是用例；实际上步骤也可以作为用例，在概念建模阶段，由于需求已经捕获,在对需求进行分析时，实际上我们已经进入了用例的内部。进入用例内部意味着边界已经发生改变，而边界的改变必然导致参与者也在改变，自然的，参与者的完整目的也就改变了，这样就可以将步骤分解为一个新的用例。

       （3）、用例粒度误区

       产生用例粒度错误的原因是分不清目标和步骤。

      用例粒度被误用的误区常常是在同一个需求阶段中的用例粒度大小不一，该问题产生的本质是因为建模者心目中没有一个清楚的边界，边界决定分析阶段的抽象层次，一个抽象层次决定了哪些信息该暴露哪些不应该暴露，如果错误地暴露了就会导致程序结构混乱。

7、用例的几个版型

（1）、业务用例（business use case ）

          业务用例，专门用于需求阶段的业务建模,用于描述客户现有的业务，相对应的，它的参与者就是业务主角。站在业务主角的立场上看到的边界是业务边界而非系统边界。

         业务用例实现（business use case realization ），也称为业务用例实例，是业务用例的一种实现方式。一个业务用例的多个业务用例实例都是为了达到同一个目的，业务用例实例表达了同一项业务的不同实现方式。

（2）、概念用例（conception use case）

        概念用例用于概念建模。

 （3）、系统用例

系统用例，简称用例。系统用例是用来定义系统范围、获取功能性需求的，系统用例是软件系统开发的全部范围，系统用例是我们得到的最终需求。

系统用例实现也是实现对象追溯到需求的一个重要环节，用例实现正是连接起用例模型和系统实现之间的桥梁。