0 作业

作业的用例大概 10 个左右

1 用例建模基础

需求的问题

• 难捕获 -> 从用户视角看问题
• 易变 -> 合理的架构
  -> 用例

1.1 参与者

• 关键词：边界
• 参与者：在系统外，透过系统边界与系统进行有意义交互的任何事物
  • 系统外：参与者不是系统的一部分，处于系统的外部
  • 系统边界：参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定
  • 与系统交互：系统需要处理其交互过程，即系统职责
    与系统进行信息交互
  • 任何事物：人、外系统、外部因素、时间
  • 系统角色
    • 参与者与使用系统的物理人和职务没有关系
    • 需要从参与系统的角色(作用)来寻找参与者

1.1.1 识别参与者的思路

• 系统在哪些部门使用
• 谁向系统提供信息、使用和删除信息
• 谁使用系统中的信息完成业务
• 谁对系统进行维护
• 与外部系统是否有关联
• 时间参与者：一种习惯用法，用于激活那些系统定期的、自动执行的用例

1.1.2 参与者之间的关系：泛化

• 在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享
• 如：系统中经理可以参加雇员的所有用例
  

1.1.3 文档化参与者

参与者的文档没有固定的格式，但至少应该包含如下信息

• 描述：为每一个参与者提供一个简要的描述，准确地描述该参与者的所扮演的角色和职责
• 基本特征：针对参与者的职责范围、物理环境、使用习惯、用户数量和类型、使用系统的频率等特性进行说明
• 相关的涉众和典型用户

1.2 用例

• 关键词：价值
• 简洁定义：参与者使用系统达到某个目标
• 定义
  • 一个用例定义一组用例实例（场景）
  • 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值
• 要点
  • 可观测→用例止于系统边界
    描述交互，而不是内在的系统活动
    如数据库的操作就不是参与者可观测的
  • 结果值→用例是有意义的目标
    
  • 系统执行→结果值由系统生成
    系统需要处理的，由系统生成
  • 由参与者观测→业务语言、用户观点
    

1.2.1 用例粒度

• 用例是一组用例实例的抽象；其内部要有路径，路径要有步骤
• 错误 1：粒度过细，陷入功能分解
  
  • 通过执行用例，参与者完成想做的事情(最终的目的)，并为参与者产生所需要的价值
  • 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言
• 错误 2：CRUD（增删改查）掩盖了业务本身，用例变成了关系数据库的建模
  • 如果确实是 CURD：把四个用例改成“管理 xx”即可
    如果有复杂交互的路径，独立出去形成用例即可
    

1.2.2 确定用例

从参与者的角度入手，通过分析参与者使用系统达成的目标来识别用例

• 参与者的日常工作是什么
• 参与者在业务中承担什么样的作用
• 参与者是否生成、使用或删除系统相关信息
• 参与者是否需要把外部变更通知系统
• 系统是否需要把内部事情通知参与者，通知参与者过程就是系统用例的行为
• 是否存在进行系统维护的用例

用例数量的参考基准

• 1个系统中存在十几个用例(或更少)
• 1个用例中有多个用例实例(场景)

1.3 关联关系：参与者和用例

• 关联关系：参与者参与用例的执行
  • 箭头（关联的方向）并不代表数据流或业务流的方向
  • 箭头代表通信的发起方|
    
    • 箭头由通信的主动方指向被动方，或者说不带箭头的一方会受到带箭头一方的影响
    • 不带箭头意味着没有考虑这种影响的方向

2 文档化用例

2.1 编写用例文档

• 用例图建立需求基本分解结构

• 用例文档详细描述需求细节

• 用例图是骨架，而用例文档则是其内在的肉

• 用例文档：描述用例与外界交互的规格说明书

  • 需求的核心内容，而用例图作为用例文档的索引图
  • 进一步的精度：有层次的文档
  • 文档中每一句话都有其价值

2.2 用例文档的组成

• 涉众

  • 用例相当于参与者在台上表演，而最重要的是台下的观众(涉众)的利益
  • 涉众有轻重缓急，甚至存在利益冲突
  • 编写用例文档的过程就是描述如何满足涉众之间的利益，达到涉众利益的平衡

• 前置和后置条件

  • 前置条件约束在用例开始前系统的状态
    • 作为用例的入口限制，它阻止参与者触发该用例，直到满足所有条件
    • 说明在用例触发之前什么必须为真
  • 后置条件约束用例执行后系统的状态
    • 用例执行后什么必须为真
    • 对于存在各种分支事件流的用例，则可以指定多个后置条件
  • 注意
    • 只有在用例的使用者将这些条件视为附加价值是才使用
    • 条件必须是系统可以感知的
    • 前置条件必须是在用例执行前就可以感知
      

• 事件流：描述用例交互
  

  • 重点写：1和4（可观测的、体现客户利益的文字）
  • 要点
    • 使用业务语言：使用用户平时所使用的语言进行描述
      ❌系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息…
      ✅系统按照查询条件搜索商品的详细信息
    • 重点描述参与者与系统交互的信息
      以参与者或系统作为主语描述
      • 参与者……
      • 系统……
        示例
      • 出纳员接收顾客的付款—顾客的付款数可能高于商品总额
      • 出纳员录入顾客所付的现金总额
      • 系统显示出应找还给顾客的余额，打印付款收据
    • 不使用“例如”、“等”不清晰的表达
    • 不要过多的考虑界面细节
    • 不要描述系统内部处理细节，要描述从系统外部所看到的活动
    • 要明确描述用例的开始和结束
    • 不仅需要描述基本事件流，还需要考虑备选事件流
      • 基本事件流
        • 用例的主路径、愉快路径（Happy Path）
        • 通常用来描述一个理想世界，即没有任何错误发生的情况
        • 复杂的基本流可以分解成多个子流
      • 备选事件流
        • 基本事件流中的分支或异常情况
        • 注意如何与基本流衔接
  • 分支和循环的描述
    • 分支：放到备选路径中
      • 参与者的选择
      • 另一条成功线路
      • 系统进行验证
      • ……
    • 循环：直接描述
  • 利用活动图可视化事件流
    

• 补充约束

  • 用例重点在于描述功能需求，而其它方面的补充约束：
    • 与特定用例相关的补充约束，作为该用例文档中一部分来描述
    • 一些全局性的补充约束，单独形成一份独立的文档，如“补充需求规约”文档
  • 补充约束
    • 数据需求
    • 业务规则
    • 非功能需求
    • 设计约束

• 场景：用例的一次执行，按照特定条件执行事件流时的具体流程、执行示例

  • 用例中的每个分支潜在产生一个独立场景
  • 将用例的部分基本流和若干备选流结合起来，就可以构成不同的使用场景
  • 基本场景 + 辅助场景

3 重构用例模型

利用用例建模高级技术重构用例模型

• 用例关系
  通过用例关系将复杂的用例进行适当的分解，以便于提高需求的复用性和可扩展性等，从而使用例模型的结构更合理

  • 包含
    提取公共步骤，便于复用
    大指小
  • 扩展
    通过扩展用例对基用例增加附加的行为
    小指大
  • 泛化
    派生用例继承泛化用例的行为并添加新行为

• 用例分包
  将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模

• 用例分级
  可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑

3.1 用例关系

3.1.1 Include(包含)

• 从两个或多个用例行为中提取公共部分的能力，主要用于支持用例行为的复用
• 基用例中复用被包含用例的行为

3.1.2 Extend (扩展)

某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示功能被扩展

• 为了将基用例的一些特殊情况分离出来，在保持基用例本身相对完整的情况下处理这些特殊行为
• 即不改变基用例，对基用例的行为进行扩展
  
  

3.1.3 Generalization (泛化)

表示子用例继承了父用例

• 用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系
• 父用例常常是抽象用例

3.2 用例分包

• 对于大规模系统，当用例数量很多时，难以在一个层次上一次性描述所有用例
• 用例分包
  • 让系统的用例图能够更为清晰的表现出系统的业务逻辑关系和层次
  • 对系统进行模块的分割，这种分割将影响到系统今后的开发、系统的最终表现形式
• 常见的分包方式
  • 基于业务主题的分包
  • 按照参与者分包
  • 基于开发团队的分包
  • 基于发布情况的分包

3.3 用例分级

• 为什么用例分级
  根据用例优先级来进行迭代开发
• 用例分级原则
  • 用例分级的一个基本原则
    高级别用例是那些对系统核心架构影响最大的用例
  • 提高用例级别的特性：
    • 对架构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例
    • 体现系统核心业务流程的用例
    • 存在开发风险的用例
    • 涉及新技术或需要创新的用例
    • 能够尽快投入使用并带来直接经济效益的用例
• 用例分级实施策略
  • 可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级
  • 依照上述的影响用例级别的特性给用例打分（特性也可能带有权值）
    

4 其他

4.1 用例与需求规约

• 用例模型由用例图、参与者文档和用例文档组成，通过这三部分来表示系统需求
  可以合并为一个文档，也可为每个用例单独编制文档
• 补充规约文档
  • 需求规约中还应该包含对数据要求、非功能需求、设计约束、用户界面、验收标准等内容的约定
  • 可以是单独的文档，可以与用例模型合并在一个完整的文档中
• 数据规约文档
  分析阶段编制，本次作业不包含

4.2 用例建模的适用场合

• 用例是从参与者角度捕获系统功能，当系统只有一个或没有参与者时，显然不是非常有效的
• 用例捕获功能需求，因此对于系统的非功能需求不是有效
  • 当遇到下述情况时，用例是需求捕获的最好选择
    • 系统由功能需求所主导
    • 系统具有很多类型的用户，系统对他们提供不同的功能
    • 系统具有很多接口
  • 当遇到下述情况时，用例是一个糟糕的选择：
    • 系统由非功能需求所主导（如：google）
    • 系统具有很少的用户
    • 系统具有很少的接口（非内部功能）
    • 如：嵌入式系统、算法复杂但接口少的系统等

4.3 用户故事

• 用户故事（Use Story）：一种轻量级的、有效的用户需求描述方式

• 都是从用户角度描述用户渴望得到的功能

• 目的不同

  • 用例：为了在用户与开发团队之间形成文档化的规约
  • 用户故事：是帮助发布和迭代计划的制定，是作为占位符，为有关详细用户需求的对话服务的

• 描述的粒度不同：

  • 用例：规范化、系统化，包含不同的用例场景
  • 用户故事：以用户使用场景为基础，轻量级的需求描述方式，是敏捷方法中主流的需求建模技术
    
    

• 用户故事地图

  • 用户故事地图（User Story Mapping）已经成为敏捷需求规划中的一个流行方法
  • 用户故事地图可以将Backlog变成一张二维地图，而不是传统的简单列表
    http://www.woshipm.com/pd/2067818.html
  • 可以尝试使用教学系统的中“实训”功能在线编制用户故事地图