系统分析作业6

1、简答题

用例的概念

用例是一系列相关的成功和失败场景的集合，这些场景描述了一个参与者使用一个系统来支持一个目标。用例是功能或行为需求，指示系统将做什么。就FURPS+需求类型而言，它们强调“F”，但也可以用于其他类型。

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

用例表示一组场景:主场景，加上零个或多个可选场景。
主场景对应于主要的系统交互，通常是“成功”场景。是最常用的，直接地实现用户目标的故事。

用例有哪些形式？

• 简洁模式(Brief (high level)）
  简短的一段概要，通常是成功的主场景。
  在早期的需求分析中，快速了解主题和范围。可能只需要几分钟来创建。
• 简便格式（Casual）
  非正式的段落格式。包含多种场景的多个段落。
• 详细描述(Fully)
  所有的步骤和变化都写得很详细，并有补充部分，如先决条件和成功的保证。
  在以一种简短的格式确定并编写了许多用例之后，在第一个需求研讨会期间，会详细地编写一些(例如10%)具有体系结构重要性和高价值的用例。

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

复杂业务的需求多，导致扩展部分较多，即除了主成功场景外的其他场景或分支，包括成功和失败路径。用例的格式导致编制复杂业务的完整用例非常难，因为这需要花费大量的时间编写，而且这些用例没有增加或增加很少的价值，并会导致大量的返工。

什么是用例图？

用例图是系统上下文的绝佳图景，它能显示用例和参与者的名称及其关系，给出了一个很好的系统及其环境的上下文图。
a.它是一个很好的上下文图
b.显示系统的边界，它外面的东西，以及如何使用它。
c.它作为一种沟通工具，总结了系统及其参与者的行为。

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

• Actor
  
  表示一个系统的用户，即与应用程序或系统进行交互的用户、组织或者外部系统。参与者用一个小人表示。
  参与者包括三类:系统用户；其他系统。在当前项目范围之外，需要建立与其他系统的接口；一些可以运行的进程
• use case
  外部可见的系统功能，表示对系统提供功能、服务的描述。用例用一个椭圆表示。
  
• association
  关联Association表示参与者与用例之间的关系。关联关系用一条直线表示，由参与者指向用例。
  
• Include
  较复杂的用例可以被分解为较小的用例，即该用例可以包含其他用例所具有的行为。包含关系使用带箭头的虚线表示，箭头指向被包含的用例。
  
• extends
  扩展Extend表示用例功能的延伸。把新的行为加入到基础的用例上，使得基础用例能够获得新的行为并能够提供新的附加功能。扩展关系使用带箭头的虚线表示，箭头指向基础用例。
  
• system scope
  确定系统的范围，边界是一个方框，用例在边界内，参与者在边界外
  

用例图的画法与步骤

• 需求识别步骤

1. 确定研讨的系统

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

2. 识别 Actors

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

3. 识别用例（服务）

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

4. 建立 Actor 和 Use Cases 之间的关联

• 请使用 无方向连线，表示两间之间是双向交互的协议

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

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

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

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

背单词APP

电影订票APP

然后，回答下列问题：

• 为什么相似系统的用例图是相似的？
  因为相似的系统，其目标人群和提供的功能时相似的，也就是说 actor 和 scenery 类似，所以 use case 也类似，最终的用例图也是类似的。

• 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
  如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
  可以对当前流行产品和目标用户进行调研，然后结合旧用例图，进行符合产品市场的改进，如在 ASG_RH 付款时需要 check out，但我们现在电子支付十分方便，可以更改为链接电子支付

• 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
  在项目早期，通过对比当前用例图和其它类似产品的用例图，提炼类似产品的先进业务，技术和商业模式，改进当前用例图，对于别人产品用例图中不足的地方，如缺少的业务和落后的技术，进行创新。同时，从用户的角度进行考虑，发掘用户需求。

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

ID	Name	Imp	Est	Iter
1	注册	10	2	1
2	登陆	10	2	1
3	查询酒店	50	5	1
4	预定酒店	50	5	1
5	订单管理	40	4	1
6	支付	40	3	1

• • Name 是产品特性，或用例名，或子用例名。它通常是树型结构
  • Imp 是特征的重要性，重要性评估维度很多，分为业务基础特征和创新业务特征。重要特征通常意味业务或技术价值，考虑优先完成或必须完成
  • Est 工作量估计
  • Iter n 预计从哪个迭代开始设计、编码该特征

---

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

ID	Name	事务	计算	UC权重
1	注册	3	2	简单
2	登陆	2	2	简单
3	查询酒店	4	4	复杂
4	预定酒店	4	3	复杂
5	订单管理	2	1	1=复杂
6	支付	3	3	平均