用例建模 - 绘制用例图

1.简答题

1. 用例的概念
   • 用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
2. 用例和场景的关系？什么是主场景或 happy path？
   • 用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约；
   • 而场景是actors和系统之间特定的一系列动作和绘画，是用例的实例。
   • 每一个用例是一些场景的集合，包括了许多个场景。
   • 主场景对应的是系统的主要的交互，通常是“成功”的场景。主场景是最常用的，能直接地实现用户目标的流程。
   • 主成功场景（main success scenario）或者 happy path是典型的、无条件的、理想方式、无错误的系统最基本的成功场景。
3. 用例有哪些形式？
   • Brief(high level)
     • 摘要：简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间快速编写。
   • Casual
     • 非正式形式：非正式的段落格式，用几个段落覆盖不同的场景。
   • Fully
     • 详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。
4. 对于复杂业务，为什么编制完整用例非常难？
   • 因为复杂业务的场景较多，无法完整考虑各步骤的前置条件和成功保证；对于复杂的业务，很难将所有的目标、故事、使用场景遵循一定的顺序列举出来。而如果场景列举的不够全面，那么用例的完整性就难以保障。
5. 什么是用例图？
   • 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。 用例图是外部用户（被称为参与者）所能观察到的系统功能的模型图。
6. 用例图的基本符号与元素？
   • 系统边界

     • 指系统与系统之间的界限，边界内表示系统的组成部分，边界外表示系统外部。用例在系统内部，参与者在系统的外部。系统边界在UML图中用矩形来表示，同时定义系统的名称。

       

   • 参与者（Actor）

     • 参与者是系统以外的、使用系统或与系统交互的人或物。然包括开发系统用户，除此之外，与开发的系统有关联的其他系统也算是参与者。在UML图中用一个小人表示。

       

   • 用例（Use Case)

     • 用例是参与者可以感受到的系统服务或功能单元。有意义的单独工作单元。它向系统外部的人或事提供一个易于观察的高层次行为视图。在UML图中用椭圆表示。

       

   • 关系

     • 关联关系(Association)：在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方，表示的是参与者与用例之间的关系。

       

     • 包含关系(Include)：用尖括号标识的虚线箭头，指向被包含者，用例可能包含其他用例的功能来作为它正常处理的一部分。通常它假设，任何被包含的用例在基本程序运行时每一次都会被调用。

       

     • 扩展关系(Extend)：用尖括号标识的虚线箭头，指向被继承者，一个用例可以被用来扩展另一个用例的行为，通常使用在特别情况下使用，扩展用例是可选的，如果缺少扩展用例不会影响到基用例的完整性。

       

     • 泛化关系(Generalization)：空心实线箭头，指向父用例，用例的泛化指的是一个父用例可以被特化形成多个子用例，也就是继承关系。

       

7. 用例图的画法与步骤
   • 使用System框确定待研究的系统
   • 绘制参与者 Actors
     • 使用用例图的actor符号来绘制使用系统的主要参与者，通常放在所有系统边界的左边。
     • 使用用例图的Neighboursystem框来表示用例依赖的外部系统、服务、设备。
   • 绘制用例
     • 重命名用例
     • 从主要的事务流程开始，直到后面较小的交互为止
     • 将每个用例放入支持它的系统或主要子系统
     • 可以在系统边界外绘制用例来表明系统不支持该用例
   • 使用无方向连线建立Actor和Use Cases之间的关联，还有建立用例之间的业务关系。
   • 确定系统所关联的外部支持系统，放在系统边界的右边。
8. 用例图给利益相关人与开发者的价值有哪些？
   • 对于利益相关人：
     • 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应利益相关者提出的需求，而用例图则使得这种调节更加便利，可以通过修改修改用例图来实现。同时可以直观看到系统的功能和操作过程，保证系统按用户的需求进行设计。
   • 对于开发者：
     • 可以从用户的角度来描述系统的主要功能以及如何使用，符合人的自然认知，同时通过可视化来方便理解和获取需求
     • 帮助明确系统的主要服务对象以及所需要的外部系统与设备
     • 帮助预测项目可能出现的技术风险
     • 可以更好地计算项目的总体工作量，从而可以合理地规划迭代的周期还有人力物力的安排

2.建模练习题（用例模型）

• 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
  • 请使用用户的视角，描述用户目标或系统提供的服务
  • 粒度达到子用例级别，并用 include 和 exclude 关联它们
  • 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
  • 尽可能识别外部系统和服务

选择了健身软件 Keep 和 订电影票和旅馆的美团 来进行用例图的绘制：

1. Keep：

   

2. 美团：

   

• 然后，回答下列问题：
  1. 为什么相似系统的用例图是相似的？
     • 因为相似的系统下，用户的基本需求大多是差不多的，如携程、去哪儿还有美团订旅馆，既然面向的用户群体大致相同，而且所面向用户的需求也大致相同，那么三者系统所提供的服务也是大致相同的，所以绘制出的用例图中，actor和use case以及参与者和用例间的关系也是相似的，最终得到的用例图也自然是相似的。
  2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
     • 不同时代：不同时代下，技术的发展程度也是不一样的，用户的需求也是不一样的。不同时代下会有不同的推荐算法、不同的支付方式以及不同的外部系统服务提供（地图API和运行商提供的短信服务）；根据用例图，可以去考虑某些业务是亟待创新的，或者哪些业务创新后整个系统的效率是会有显著提升的，这样就可以通过用例图来分析到那些技术是最需要更新的。
     • 不同地区：考虑不同地区的风俗以及发展程度，比如发达城市的核心地段的用户对星级酒店的需求会更高一些，小城市中或者大学城这类位于城市较偏远的地方的用户更倾向于选择旅馆，所以可以根据用例图针对不同地区的用户重点发展不同的业务。
  3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
     • 根据用例图，就可以在系统为用户提供服务的所有流程上去考虑创新点，每一个用例不论是父用例还是子用例都有其可创新之处，扩展用例可以插入到用例图中的系统内的每一个位置上，所以我们可以从用例图的系统工作的流程中来定位创新思路，在每一个用例上考虑业务创新或者技术创新的可能性，同时考虑可能可以加入的新的商业模式。
  4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
     • Backlog 条目一般包括以下字段：
       • ID：统一标识符，就是个自增长的数字而已。以防重命名条目以后找不到它们。
       • Name：简短的、描述性的条目名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他条目区分开。它一般由2到10个字组成。
       • Importance：产品负责人评出一个数值，指示这个条目有多重要。例如10或150。分数越高越重要。
       • Initial Estimate：团队的初步估算，表示与Backlog其他条目相比，完成该条目所需的工作量。最小的单位是story point，一般大致相当于一个“一个人一天理想的工作量（man-day）”。
       • How to demo：它大略描述了这个Backlog条目应该如何在 sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到什么样的结果”。
     • 根据上面所绘制的美团订旅馆的用例图来编制开发计划表：

     ID	Name	Imp	Est	How to Demo	Note
     1	登陆	3	5	通过外部平台或者手机号获取验证码进行登陆	使用其他平台登陆需要使用外部平台所提供的API，不论哪种形式都需要绑定手机号方便告知用户订单详情
     2	选择旅馆	10	20	选择地点、入住时间段，然后选择具体旅馆	需要设计出合适的智能推荐算法
     3	建立订单	5	7	将选取好的旅馆信息整合并生成待支付订单
     4	支付	3	3	通过微信或者支付宝支付来支付订单	支付成功或者失败都要以短信形式告知用户，支付成功则将订单信息发送给用户绑定的手机

  5. 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算
     • 根据用户点方法，对用例分配权重的标准是：
       • 简单用例：1 到 3 个事务，权重=5
       • 一般用例：4 到 7 个事务，权重=10
       • 复杂用例：多于 7 个事务，权重=15

     用例	# 事务	# 计算	原因	UC权重
     登陆	5	3	需要绑定手机号	一般
     选择旅馆	7	6	根据不同条件逐步筛选，同时还有较多例外流程	一般
     建立订单	2	2		简单
     支付	4	3	支付结果需短信告知用户	一般

• Previous
  RxJava 源码解析
• Next
  Android 拓展思考