UML和模式应用

用例：参与者的三种类型
    主要参与者：具有用户目标，并通过使用Sud服务的服务完成。发现驱动用例的用户目标。POS系统的收款员。
    协助参与者：为Sub服务提供服务。协助参与者通常是计算机系统，但也可以是组织或人。为了明确外部接口和协议。自动付费授权系统。
    幕后参与者：在用例行为中具有影响或利益，担不是主要或协助参与者。政府的税收机构。

 

用例：表示法
     摘要： 简洁的一段式概要，通常用语主成功场景。例如销售的成功流程。一般用语早起需求分析过程中，为快速了解主题和范围，可能只需要几分钟进行编写。
     非正式： 非正式的段落格式。用几个段落覆盖不同场景。例如在主场景的基础上，单独列段处理退货。使用场景同上。
     详述：  详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。在确定并以摘要的形式编写了大量用例后，在第一次需求讨论会中，详细编写其中少量（10%）左右的具有重要架构意义和高价值的用例。

用例：名词解释
   范围： 范围界定所要设计的系统。
   级别： 用户目标级别：描述了实现主要参与者目标的场景。
          子功能级别 ： 支持用户目标所需要的子步骤，当若干常规用例共享复制的子步骤时，则将其分离出来，创建为子功能级别用例。
   主要参与者：调用系统服务来完成目标的主要参与者。
   涉众及其关注点列表-重要！：
          它建议并接定了系统必须要做的工作。用例应该包括满足所有涉众关注点的事物。另外，在编写用例其余部分之前就确定涉众及其关注点，能够让我们更加清楚地了解细的系统职责。
   前置条件：给出在用例场景中开始之前必须永远为真的条件。
   成功保证（后置条件）：给出用例成功结束后必须为真的事物。
   主成功场景和步骤（基本流程）：
            它通常不包括任何条件或分支。条件和分支都退言道扩展部分。
            三个步骤：
            1.参与者之间的交互 2.确认过程（通常由系统来完成）3.系统完成的状态变更。
   扩展（或替代流程）：
       扩展场景是主成功场景的分支。有两部分组成：条件和处理
       准则：尽可能使用系统或参与这能够检测到的事物作为条件。【系统检测到与外部税务计算系统服务的通信故障】比【外部税务计算系统工作不正常】风格要好。因为这是系统能够检测到的条件。
       扩展场景结束的时候，默认情况下，重新并入主成功场景。
       
   执行其他用例场景：
       用例可以长生分支执行其他用例场景。
   特殊需求：
       于用例相关的非功能性需求，指令属性或约束。
        特殊需求写入用例中对于第一次编写的用例是合理的。然而，最终把所有分功能性需求集中于补充规格说明中，对于内容管理，可理解性和可读性而言更为有效，因为在架构分析师通常将这些需求作为整体考虑。
   技术和数据变元表：
        需求分析中通常会发现一些技术变元，这些变元是关于如何实现系统的，而非实现系统那些功能，这种变元需要记录在用例中。例如：POS系统必须使用读卡器和减排来支持输入信用卡账号。
   

用例：准则：以无用户界面约束的本质风格编写用例
       【管理员识别自己的身份】【系统对此身份进行认证】
        比
        【管理员在对话框中输入ID和口令】【系统对管理员进行认证】【系统显示“编辑用户”窗口】
        要好。
       
用例：准则：编写黑盒用例
  黑盒用例：不对系统内部工作，构件或设计进行描述。通过职责来描述系统。
      黑盒风格： 系统记录销售
      非黑盒风格： 系统将销售信息写入数据库  甚至   系统对销售信息生成SQLINSERT语句。

用例：准则：采用参与者和参与者目标的观点
      关注系统的用户或参与者来编写需求，询问其目标和典型情况
      关注理解参与者所考虑的有价值感受

用例：准则：如何发现用例：
      1. 选择系统边界
      2. 寻找主要参与者和目标
      3. 确定每个主要参与者的目标
      4. 定义满足用户目标的用例，根据其目标对用例命名。
 
用例：准则：什么样的测试有助于发现有用的用例
      1.老板测试，提交给老板，老板能看懂并满意的
      2.EBP测试，一个人于某一个时刻在一个地点执行的任务，用以响应业务事件。该任务能够增加可量化的业务价值，并且以持续状态留下数据。
      3.规模测试，需要多个步骤，3-10页的文本才能记录清楚。
      4.特别重要，特别复杂的单一步骤形式的工作。