大象Thinking in UML读书笔记☞ 第三章

3.1 版型

          ◆版型是UML中的一个概念，也叫作类型、构造型。版型是对UML中基础元素赋予一个特殊的意义，使得这个元素可以描述特定的场合。

          ◆例如类有接口、边界类、实体类、控制类等版型。

          ◆用户可以依据系统需要自己创建版型，例如工作组、文档等。

3.2 参与者（亦可以成为主角）

3.2.1定义：

         ◆定义：系统外部与系统进行交互的人或物

         ◆如何界定系统内部和外部：

             a.确定谁对系统有明确的目标和要求并主动向系统发起了动作？

             b.系统主要是为谁服务

         ◆如何确定参与者：

          a.直接且主动向系统发起动作并获得反馈的人或物

            eg: 对于一个机票预订系统

                 >甲某通过机票预订系统购票，甲某是参与者

                 >贾某打呼叫中心人工坐席，让人工坐席通过机票预订系统为其购票，则人工坐席是参与者

                 >贾某通过呼叫中心语音系统访问机票预订系统购票，呼叫中心语音系统是参与者

                 >将呼叫中心作为机票预订系统的子系统，贾某通过呼叫中心人工坐席/语音系统订票，则贾某是参与者，人工坐席变成了业务工人。

3.2.3 业务主角

     ◆定义: 业务主角是参与者的一个版型，是与业务系统进行交互的人或物，用来确定业务范围。

      ◆业务范围与系统范围区别：

         a.业务范围是本项目涉及的所有客户业务

         b.系统范围是指软件将要实现的那些对应于客户业务的功能，一般是业务范围的子集。

      ◆如何确定业务主角选取是否正确：

            a.业务主角的名称和业务用例是否是客户的业务术语

            b.业务主角的职责是否在客户的岗位职责手册中有明确定义

            c.客户是否能很容易的理解该业务主角

      ◆开发人员做需求分析人员时易范的错误：

         a.和客户沟通进行业务建模时，从计算机系统的角度来考虑问题，客户可能会因为相信技术人员在计算机方面的权威而再业务需求没有描述的

         很清楚的前提下认可开发人员对需求的定义与描述，导致在开发结束时客户认为开发的系统不是他们想要的。

         b.和客户沟通进行业务建模时，主观的在内心中假设了业务在计算机里的实现方式且没能确切的理解客户的实际业务，导致开发出来后客户认

         为系统不符合他们的业务流程。

3.2.4 业务工人

      ◆定义：处于系统内部的参与者，称为业务工人。

      ◆区分业务工人和参与者：

         a.是不是主动向系统发起动作

         b.有没有明确的业务目标或需求

         c.系统是为他服务吗

      ◆例子：

         对于呼叫中心作为购买机票系统的子系统的系统，用户通过呼叫中心的人工坐席来从机票购买系统进行购票，这时，用户是参与者， 人工坐席就是业务工人。

3.2.5 参与者与涉众的关系：

      ◆涉众的定义：所有和待开发的系统利益相关的人或事，涉众的需求可能会影响系统的建设。

      ◆参与者是涉众的代表，参与者对系统的要就就是系统需求的来源。

3.2.6 用户与参与者的关系

     ◆用户是系统的操作员，是参与者的代表，但并非所有的参与者都是用户，一个用户可以代理多个参与者。

     ◆例子：

        自动化办公系统建设，局长是参与者，向系统提出如何审批的要求；但后面是秘书来代替局长和系统进行直接交互，所以局长不是系统的最终用户。

3.2.7 参与者与角色的关系

     ◆定义：角色是参与者的职责，是重多参与者职责中抽象出来的相同的一部分职责，使用角色可以为系统带来很好的灵活性。

     ◆用户和角色的关系：用户  1vs多 参与者 ==> 用户 1vs多角色

3.2.8 参与者的核心地位

     ◆核心地位表现在：系统是以参与者的角度进行设计的，参与者的要求决定了系统的功能性。

3.2.9 检查点：

     ◆如何保证发现的参与者都是正确的：

      a.找到并说明了所有用例 ==> 来确认是否找到所有的参与者

      b.去除不涉及用例或和用例无通信关联关系的参与者

      c.保证系统中至少有两个可以作为特定参与者的人员，并合并角色有子集关系的参与者

      d.是否有参与者担任与系统相关的相似角色？有则将他们合并成一个参与者。通信关联关系和用例说明参与者和系统是如何相关关联关系的。

      e.是否有两个参与者担任与用例相关的同一角色？有则使用参与者泛化关系来未他们的共享行为建立模型

      f.特定的参与者是否以几种完全不同的方式使用系统？他使用的用例是否出于几个完全不同的目的？是的话将其化成多个参与者。

      g.参与者是否有直观的名称和描述性名称？用户和客户是否都能理解这些名称？

3.3.用例

3.3.1 用例的基本概念：

>定义：用例定义了一组用例实例，每个用例实例对应系统的一系列操作，这些操作生成了特定主角的可观测值。

>组成：参与者、前置条件、场景、后置条件。

  eg:

  贾某做米饭。对于做饭这个用例，其前置条件是有米，后置条件是做出来的饭，用电饭锅做还是用蒸笼做是两个场景，用电饭锅做时用精米不淘米直接蒸和用粗米淘米后再蒸这是用例对于不同条件的处理场景。

3.3.2 用例的特征：

  >用例是相互独立的: 即单个用例即可完成参与者的某个意愿，而完全不需要借助其他用例。

  >用例的执行结果对参与者是可观测和有意义的：比如用户访问系统删除某条记录，系统在删除前对记录进行了备份。这里的备份数据就不是用户的用例，因为       用户无法对其进行观测。

  >用例必须由参与者发起，用例不该自动启动，也不该主动调用另一个用例。例如用户取钱里取钱是一个用例，ATM机主动吐钱时吐钱不是一个用例因为没有参 

    与者进行发起。

  >用例必然是以动宾短语结构出现的，入取钱，做报表

  >一个用例就是一个需求单元、设计单元、开发单元、测试单元，甚至可能是一个部署单元

3.3.3 用例粒度：

  >标准的粒度：用例粒度应能的描述参与者的某个完整的目的。

  >在业务建模时，用例的粒度以能说明一件具体的事情为宜，如取钱。

  >在概念建模时，用例的粒度以能描述一个完整的事件流为宜，如填写取款单

  >在系统建模时，用例的视角是针对计算机的，用例粒度以能够描述清楚用户和系统的一次完整交互为宜。在RUM（统一建模）中，项目计划要依据系统模型来       编写，所以另一个可供参考的粒度是一个用例的开发时间控制在一周左右为宜

  #注意：

  在同一个需求解读，所有的用例的粒度要保持一致。

3.3.4 用例的获得

●从客户那里获得用例前要问的问题：

  您对系统的期望是什么？

  你打算在这个系统里做什么事？

  你对这件事的目的是什么？

  您做完这件事要一个什么结果？

●确定用例时要做的事情： 

   多个主角的目标呈现交集，且这些目标是某个完整目标的一部分，则将这些用例和并成一个，并假定这这几个主角都只是合并后的业务用例的业务工人。

   两个主角谈论的目标有交集，但的确是两个目标，则应该当做两个用例来看待

3.3.5 用例和功能的误区：

●描述事物的三个出发点：

  这个事物是什么？

  这个事物可以做什么？

  这个事物被人们用来做什么？

●功能： 重在描述这个事物可以做什么。

  功能是脱离使用者意愿而存在的

  功能是独立的

●用例：重在描述这个事物被人们用来做什么。

  从功能角度来描述用例，用例可以看做是为实现某个目标而组合在一起的一系列功能的集合。

3.3.6目标和步骤的误区：

● 目标是参与者对系统的完整期望，是一个完整的事件；而完整这个事件要经过很多步骤，单独的步骤无法完整的反应参与者的目标，故不能作为用例。

● eg:

   参与者去邮局寄信，寄信这个目标可以分为买信封、买邮票、给钱等几个步骤，对于寄信的参与者人来说，单独的给钱不是他对系统的目标，让他来邮局

给完钱就走他页肯定不干，所以给钱是步骤，不是目标，在当前的业务建模中它不能作为用例。

3.3.7用力力度的误区：

●在同一需求阶段，务必保证用例粒度一致，紧守系统边界。

3.3.8 业务用例

●业务用例是用例的一种版型，在业务建模中使用，主要用于获取功能性业务

3.3.9 业务用例实现

●业务用例实现是业务用例的实例，用于描述同一业务用例的不同实现方式

3.3.10 概念用例

●概念用例用于概念建模，用于获取业务用例中的核心业务逻辑。

3.3.11 系统用例

●系统用例用于系统建模，也就是平时说的用例，用于获取功能性需求，是从系统的视角来看待问题。

3.3.12 用例实现

●即系统用例实现，一个用例实现代表了一个用例的一种实现方式，是连接用例模型和系统实现之间的桥梁，对数据库表设计、类设计有指导作用