系统分析与设计第四次作业

---

一、简答题

---

1.用例的概念

用例：是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。用例一般是由软件开发者和最终用户共同创作的。

---

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

场景：是指用户实际应用场景的过程，又被称为用例实例，通过各种动作组合起来，是实例化的用例，从一个用例可以实例化出多个用例场景。 用例事实上就是一系列场景的集合。

主场景：对应于主要系统交互，通常是“成功”场景，最常用、最直接地实现用户目标的场景，反映的是用户最为基本的目的。

Happy path：是一个没有异常或错误条件的默认场景。它让执行成果的能继续运行到最后，从而生成积极的响应。

---

3.用例有哪些形式？

• 摘要：简洁的一段式概要，通常用于主场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间编写。
• 非正式：非正式的段落格式，用几个段落覆盖不同的场景。
• 详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。包含完整的场景建立，完整的步骤以及用例的细节，以及一些可能发生的情况的应对以及如何确保一个成功的场景

---

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

由于业务复杂、需求多且杂，用例下的场景会非常多且复杂。随着时间更迭，开发过程中需求会发生变化，用例场景不仅会越来越多，并且也会相应产生变化。很难完整地考虑到所有的场景情况，并且有些业务难以使用用例抽象描述出来。用例间的关系在多个用例之间是很复杂的，有些用例关系难以理清。

---

5.什么是用例图？

用例图：是指由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。用例图是外部用户所能观察到的系统功能的模型图。用例图是系统的蓝图，呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模，它显示了系统的边界，展示了与系统交互的外部对象，描述了系统的使用方法。

---

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

• 参与者 (Actor)：表示一个系统用户，包括与应用程序进行交互的用户、组织或外部系统
  
• 用例 (Use Case)：表示一个用例，通常用作对系统提供的功能、服务的一种描述
  
• 包含关系 (Includes)
  
• 扩展关系 (Extends)
  
• 关联关系 (Association)
  
• 泛化关系：
  

---

7.用例图的画法与步骤

• 确定系统边界：
  • 使用系统方框表示一个用例系统
  • 正确命名系统或子系统
• 识别参与者
  • 识别使用系统的主要参与者 (primary actors) / 角色(roles)
    • 使用用例图 actor符号表示，通常放在系统的左边
    • 企业应用可以通过企业组织架构，业务角色与职责识别
    • 互联网应用则必须通过市场分析，确定受众范围
    • 千万不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。例如，你的系统服务对象是程序员，但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同
  • 识别系统依赖的外部系统
    • 使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别
    • 例如：Account System（财务系统），教务系统，第三方身份认证、地理信息服务、短信服务等第三方在线服务，GPS 等等
• 识别用例：
  • 识别用户级别用例（user goal level）
    • 以主要参与者目标驱动
    • 收集主要参与者的业务事件
    • 必须满足以下准则：boss test，EBP test，Size Test
    • manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等
  • 识别子功能级别的用例（sub function level）
    • 子用例特征
      • 业务复用。例如：现金支付
      • 复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现
      • 强调技术或业务创新。例如：“识别人脸”，尽管从用户角度是单步操作，但背后涉及技术解决方案是比较复杂的
    • 正确使用用例与子用例之间的关系
• 建立 Actor 和 Use Cases 之间的关联
  • 请使用 无方向连线，表示两间之间是双向交互的协议

---

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

• 对于利益相关人：
  • 可以直观看清系统的结果以及用户的功能体验，提供了系统使用和行为的摘要视图，
  • 提供用户使用系统流程的说明。
  • 能够根据业务场景的复杂程度和形式化程序进行增减调节，能够通过用例图进行系统功能的增减以及修改，满足相应利益相关人提出的需求。
    使得系统能够注重其参与者的用户体验。
• 对于开发者：
  • 明确系统的业务范围、服务对象、外部系统与设备。
  • 可以帮助将大型系统划分为多个模块。每个模块本身可以由用例图表示。
  • 帮助识别技术风险，提前实施关键技术原型公关与学习。
  • 易于评估项目工作量，合理规划迭代周期，规划人力需要。

---

二、建模练习题（用例模型）

---

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

并满足以下要求：

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

携程：

猫眼电影：

---

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

因为系统相似，用例面对的参与者也是相似的人群，用例系统的需求是相似的，核心功能也是相似的，连同用例之间的关系也是相似的，因此设计绘制的用例图也是相似的。即使有特色的扩展服务，也是在基本业务上的扩展，都是为了满足相同的需求而提出的，所以最终相似系统的用例图是相似的。

---

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

不同时代、不同地区用户的需求在细节上的要求是不一样的，Asg_RH用例图只设计了用户主要满足的基本需求，而没有在这部分细节上进行创新和设计。例如：新时代用户的需求不仅仅体现在基本的入住地点、入住时间等信息，还包括了预定酒店级别、酒店+景点结合、酒店风格(如民宿)、酒店价格(特价or区间)、酒店附近交通等信息的搜索选择，可以在用例图中突出这些方面的重要性。同时如今的产品则综合考虑了更多功能，更加人性化。不同地区的旅馆在服务、价格、交通方面都会有较大的差别，可以在用例图中突出这些方面的重要性。

---

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

• 在用例图中对创新用例使用某种颜色进行高亮标记，可以很方便地让需求方、开发人员快速了解该系统的创新功能以及该模块相关依赖和输入输出结果。

• 可以根据用例图中的位置来定位它在系统中的作用，定义越靠近参与者的为创新思路作用越大的。

---

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

以携程酒店用例系统为例：

ID	Name	imp	EST	How to demo	Notes
1	find hotel	30	10	1.输入目的地、入住时间等信息根据GPS获取匹配附近酒店列表 2.输入酒店名字，精确定位匹配同名酒店列表	智能排序酒店列表，如：价格、评分、距离等，用户可自行选择酒店
2	make reservation	15	2	选择入住房间类型、入住人数、入住时间等信息，核对房间价格和时间等信息后确认订房账单	确认机制避免误选
3	login	20	5	使用第三方微信账号登陆携程	关联微信账号
4	pay	25	8	使用第三方支付微信支付支付账单	对接第三方支付接口
5	manage basket	10	5	管理订房账单，可选退订改时间等	管理后台核实操作信息，不允许用户频繁修改操作

---

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

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

用例	事务	计算	原因	uC比重
find hotel	4	6	智能排序推荐框架	复杂
make reservation	5	4		复杂
login	1	2		简单
pay	2	3		一般
manage basket	1	2		简单

---