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

1、简答题

• 用例的概念

  • 用例是描述参与者使用系统去达到某种目的一系列相关的成功和失败情景。
  • 用例是文本文档而不是图，即用例建模的过程主要是文本编写，而不是制图。
  • 用例与面向对象无关。
  • 用例是经典面向对象分析与设计的一个关键需求输入。
  • 用例是表现系统功能的功能性或行为性需求。

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

  • 场景是参与者与系统之间的一系列特定的活动和交互，也称为用例实例。
  • 主场景 (primary scenario)，也被称为 happy path，是系统主要的交互，通常是成功的场景，是最常用的直接地实现用户目标的场景。

• 用例有哪些形式？

  • 摘要(Brief)：简洁的一段式概要，通常用于主成功场景。用于早期需求分析过程中，为了快速了解主题和范围。
  • 非正式(Casual)：非正式的段落格式，用几个段落覆盖不同场景。同样，用于早期需求分析过程中，为了快速了解主题和范围。
  • 详述(Fully)：详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。

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

  • 完整用例是结构化的，它展示了更多细节，并且更为深入。对于复杂的业务，其业务流程很复杂，涉及很多的场景，场景之间的关联也非常多，很难将所有的用例和场景按照一定顺序列举出来。同时，如果用例编写者对各个业务流程的理解存在偏差，用例的准确性和完整性就难以保证。

• 什么是用例图？

  • 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图是外部用户（被称为参与者）所能观察到的系统功能的模型图，是系统的蓝图。
  • 用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

• 用例图的基本符号与元素？
  1、参与者(Actor)：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
  
  2、用例(Use Case)：表示的是对系统提供的功能、服务的一种描述。
  
  3、系统边界：表示正在建模系统的边界，边界内表示系统的组成部分，边界外表示系统外部。UML中系统边界用一个方框表示，并附上系统的名称，参与者在边界的外部，用例在边界内。
  
  4、用例之间的关系：

  a. 包含关系(Include)：表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例。
  
  b. 泛化关系(Generalization)：泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示，箭头指向父用例。
  
  c. 关联关系(Association)：表示的是参与者与用例之间的关系。在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方。
  
  d. 扩展/延伸关系(Extend)：表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例。
  

• 用例图的画法与步骤

  • 绘制系统边界。
  • 绘制参与者，将参与者画在所有系统边界以外。
  • 绘制用例，考虑每一个参与者是如何使用系统的，将相应的用例画在对应的系统中，用线将用例和参与者关联起来。
  • 绘制用例间的关系：如包含关系、扩展关系和泛化关系。
  • 绘制关联的外部支持系统，用线将支持系统和对应的用例关联起来。

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

  • 对于利益相关人：
    • 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
    • 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
  • 对于开发者来说：
    • 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
    • 用例图使得开发者能够更明确地获得需求，更好地理解需求。
    • 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

2、建模练习题

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

（1）携程网

（2）淘票票

回答下列问题：
（1）为什么相似系统的用例图是相似的？

因为对于相似的系统，其服务对象是相似的，因而业务逻辑都是相似的，所以在绘制用例图的时候所产生的用例和用例间的关系都是相似的，最终导致绘制出来的用例图是相似的。而它们的不同点在于各个系统在实现各自的业务逻辑时的创新方式与特色。

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

可以将当地的发展特色（如：旅游景点，地区特产等）作为推荐参考改进推荐算法；根据用户历史操作的习惯（如：价格因素，时长等），结合当地旅馆的实际情况为用户推荐合适的旅馆。

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

在用例图中用色彩标注出出创新的用例或子用例，能够方便开发人员尽快了解该系统的创新点。

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

ID	Name	Imp	Est	How to demo	notes
1	注册	10	5	本系统账号注册或关联第三方账号	注册账号
2	登录	10	5	本系统账号登录或关联第三方账号	用户登录
3	酒店搜索	30	20	根据用户输入搜索符合条件的酒店	显示符合用户需求的酒店
4	酒店筛选	25	20	筛选符合更多条件的酒店	只显示满足条件的酒店
5	酒店排序	25	20	根据各种条件进行排序	确定酒店优先级
6	酒店详情	15	15	查看酒店详细资料	参考信息
7	酒店预订	20	20	查看酒店空闲房间，用户确定房型和入住时间等	用户预定房间
8	费用支付	20	20	选择支付方式	关联第三方支付平台
9	评论	5	5	用户入住后可对该酒店进行评价	用户点评

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

根据用户点方法，对用例分配权重的标准是：
简单用例：1 到 3 个事务，权重=5
一般用例：4 到 7 个事务，权重=10
复杂用例：多于 7 个事务，权重=15

用例	#业务	#计算	原因	UC权重
注册	3	2	关联外部系统	简单
登录	3	2	多种登录方式	简单
酒店搜索	10	8	多条件搜索	复杂
酒店筛选	7	4	多条件筛选	一般
酒店排序	5	4	按条件决定酒店优先级	一般
酒店详情	3	2	酒店详情	简单
酒店预订	5	5	及时更新	一般
费用支付	8	8	多种支付方式以及保证支付安全	复杂
评论	3	2	用户交流	简单