用例建模 - 绘制用例图

• 简答题
  • 用例的概念
  • 用例和场景的关系？什么是主场景或 happy path？
  • 用例有哪些形式？
  • 对于复杂业务，为什么编制完整用例非常难？
  • 什么是用例图？
  • 用例图的基本符号与元素？
  • 用例图的画法与步骤
  • 用例图给利益相关人与开发者的价值有哪些？
• 建模练习题（用例模型）
  • 携程
  • 畅邮
  • 然后，回答下列问题：
    • 为什么相似系统的用例图是相似的？
    • 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术。
    • 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
    • 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
    • 根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算

简答题

用例的概念

用例是一组成功或失败的场景，描述了一个使用者使用系统进行操作来达成一个目标的行为。

用例和场景的关系？什么是主场景或 happy path？

系统根据参与者的请求，在不同的条件下，执行某一行为序列。每一个行为序列可称为一个场景。一个用例包含多个场景，场景也可以称为用例的一个实例。

主场景（happy path）描述了满足涉众关注点的典型成功路径。它是典型的、无条件的、理想方式的主成功场景。主场景是用户和系统之间的主要交互，是最常用的实现用户目标的场景。

用例有哪些形式？

摘要：简洁的一段式摘要，通常用于主成功场景。

非正式：非正式的段落格式，用几个段落覆盖不同场景。

详述：详细编写所有步骤与各种变化，同时具有补充部分，如前置条件和成功保证。

对于复杂业务，为什么编制完整用例非常难？

对于复杂业务，其涉及的场景数量会变得很多，而各场景之间的关联使得用例设计变得特别困难。因为用例是各个成功与失败场景的集合，用例的编写需要对这些场景熟悉，并且需要建模知识与注意用户交互的相关细节，但仍无法完整地覆盖实际中可能出现的情况。用例总是不完整的，所以编制完整用例非常难。

什么是用例图？

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。表现了一些用例及其关系。

用例图的基本符号与元素？

• Actor

  表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

• System

  用来展示系统的一部分功能，这部分功能联系紧密。

• Use Case

  用例就是外部可见的系统功能，对系统提供的服务进行描述。 用椭圆表示

• Relationship

  关联、泛化、包含、扩展

用例图的画法与步骤

1. 确定研讨的系统
   • 使用用例图 System框 表示一个待研究的系统
   • 正确命名系统或子系统，例如 Reserve Hotel。
   • 千万不要将研究的系统的名称起的太泛，如“网上商店”。正确的姿势是“网上书店”，以避免业务空泛问题

1. 识别 Actors
   • 识别使用系统的主要参与者（primary actors）/角色(roles)
   • 使用用例图 actor符号 表示，通常放在系统的左边
   • 企业应用可以通过企业组织架构，业务角色与职责识别
   • 互联网应用则必须通过市场分析，确定受众范围
   • 千万不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。例如，你的系统服务对象是程序员，但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同
     • 识别系统依赖的外部系统
   • 使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别
     • <<system>> 例如：Account System（财务系统），教务系统
     • <<service>> 例如：第三方身份认证、地理信息服务、短信服务等第三方在线服务
     • <<device>> 例如：GPS 等等
   • 要将一些专业功能赋予专业系统。对于 Reserve Hotel 系统，除了订单配送、支付、销售账单由其他专业系统完成外，房源管理都应由独立系统完成，以确保系统的简洁与专业。大而全的软件是软件失败的主要因素之一

1. 识别用例（服务）
   • 识别用户级别用例（user goal level）
   • 以主要参与者目标驱动
   • 收集主要参与者的业务事件
   • 必须满足以下准则
     • boss test
     • EBP test
     • Size Test
   • manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等
     • 识别子功能级别的用例（sub function level）
   • 子用例特征
     • 业务复用。例如：现金支付
     • 复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现 强调技术或业务创新。例如：“识别人脸”，尽管从用户角度是单步操作，但背后涉及技术解决方案是比较复杂的
   • 正确使用用例与子用例之间的关系
     • <<include>> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！
     • <<extend>> 表示子用例是父用例的可选场景或技术特征。
     • <<include>> 箭头指向子用例；<<extend>> 箭头指向父用例。箭头表示的依赖关系！
2. 建立 Actor 和 Use Cases 之间的关联
   • 请使用 无方向连线，表示两间之间是双向交互的协议

用例图给利益相关人与开发者的价值有哪些？

明确了业务范围，服务对象，对用户需求和技术需求更加明确，可以更好的进行任务规划和安排。同时明确了系统的边界，可以确定开发任务的范围，避免范围的扩散。可以提供对任务的划分依据，合理的设定开发周期，进行任务分配。

建模练习题（用例模型）

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

• 请使用用户的视角，描述用户目标或系统提供的服务
• 粒度达到子用例级别，并用 include 和 exclude 关联它们
• 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
• 尽可能识别外部系统和服务

携程

畅邮

然后，回答下列问题：

为什么相似系统的用例图是相似的？

相似系统往往具有相似的参与者、用例、用例间的关系、支持系统

如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术。

不同时代的文化，用户习惯，技术级别，法律法规均有所不同，针对所在时代的特点，需要对用例或外部系统进行设配与创新，可以用较为鲜明的颜色展现出这些创新点。

如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

通过在用例图中使用与其他用例不同的颜色进行标记的方法，能够快速定位到该用例图中的创新点。

请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算

根据用户点方法，对用例分配权重的标准是：

• 简单用例：1 到 3 个事务，权重=5
• 一般用例：4 到 7 个事务，权重=10
• 复杂用例：多于 7 个事务，权重=15