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

一.简答题
1.用例的概念
用例（use case）是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。
编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

2.用例和场景的关系？什么是主场景或 happy path？
每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。
主场景（happy path）

• 主场景对应于主系统交互，通常是“成功”场景。
• 最常用，直接地实现用户目标的故事

3.用例有哪些形式？
三种常用的用例形式

• 简短（高级层次）
  一段简短的总结，通常是主要成功场景。
  在早期需求分析期间，快速了解主题和范围。可能只需要几分钟就可以创建。
• 非正式（简便格式）
  非正式段落格式。涵盖各种场景的多个段落。
• 完全级
  所有的步骤和变化都写得很详细，并有支持部分，如前提条件和成功保证。
  在以简短的格式识别和编写了许多用例之后，然后在第一个需求研讨会期间，详细地编写了一些（例如10%）具有体系结构重要性和高价值的用例。

4.对于复杂业务，为什么编制完整用例非常难？
复杂业务逻辑的功能点可能异常分支较多，用例中很难覆盖全。
复杂业务的场景较多，场景较为复杂，完整用例要把所有的步骤和变化的都写的很详细，并有支持部分。满足这些要求的复杂业务完整用例很难实现。

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

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

• 参与者(Actor)：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
  
• 用例（Use Case)
  是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
  
• 系统边界
  系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
  
• 箭头
  箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
  • 包含关系（Include）：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。
    
  • 泛化关系（Generalization）：代表一般与特殊的关系。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
    
  • 关联关系（Association）：　表示参与者与用例之间的通信，任何一方都可发送或接受消息。
    
  • 扩展/延伸关系（Extend）：用例功能的延伸，表示在一定条件下，把新的行为加入到已有的用例中。获得的新用例叫做扩展用例，原有的用例叫做基础用例。扩展关系相当于为基础用例提供一个附加功能。
    

7.用例图的画法与步骤

• 对语境建模
  1.识别系统外部的参与者。
  2.将类似参与者组织成泛化的结构层次。
  3.在需要加深理解的地方，为每个参与者提供一个构造型。
  4.将参与者放入到用例图中，并说明参与者与用例之间的通信路径。
• 对需求建模
  1.识别系统的外部参与者来建立系统的语境
  2.考虑每一个参与者期望的行为或需要系统提供的行为。
  3.把这些公共的行为命名为用例。
  4.确定提供者用例和扩展用例。
  5.对这些用例，参与者和它们之间的关系建模。
  6.用注释修饰用例

8.用例图给利益相关人与开发者的价值有哪些？
用例图是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用。

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

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

知米背单词

百词斩

2.回答下列问题：
1.为什么相似系统的用例图是相似的？
相似系统的用例图的参与者是基本相同的。
相似的系统会有很多功能，服务重合，会有很多相似甚至相同的用例。
同时，用例之间的包含和扩展关系也有相似的地方。
因此，相似系统的用例图是相似的 。

2.如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
不同的时代有不同的技术和创新。人们的思维方式也不一样。与Asg_RH相比，有很多创新的用例出现。我们可以进行对比，将创新业务和技术标注鲜艳的颜色。

• 人们可以使用更加方便的工具进行预定。现在的人们可以使用智能手机或者PC端。
• 利用谷歌街景和AR技术，人们可以足不出户的查看旅店的环境，地段等细节。
• 根据用户反馈，大数据分析。精确的投放广告业务。分析用户群的特征，改善业务的体验。
• 不同的支付方式，Asg_RH只能用信用卡，而现在的支付方式多种多样。比如支付宝，微信支付等等。

3.如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
用色彩标注出创新（或区别于竞争对手的）用例或子用例，可以很直观的观察创新思路的位置和作用

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

product backlog是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算。在Scrum中表示可以预知的所有任务，包括未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。Prodcut Backlog永远处于不完整状态，它随着产品及其使用环境的变化而变化，它是动态的，管理层不断对之做出改变，确定产品需求，保证产品适用性、实用性和竞争性。

• ID：为一个唯一标识，在其他工作或者文档中想引用故事就使用这个ID来引用
• Name：2到10个字，通过简单的描述来说明故事
• 重要性(Imp)：这个优先级决定了sprint选择的故事，优先级越高的越早实现
• 初始估算(Est)： 这个由Team来根据故事描述内容来估算，产品负责人讲解完故事后，Team对不清楚的进行询问，大概了解后进行粗略估算。
• How do demo：从用户视角，从操作层面进行讲解这个故事如何通过软件来演示，也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写”如何演示“。
• Notes：相关信息、解释说明和对其他资料的引用等，一般都非常简短

ID	Name	Imp	Est	How do demo	Notes
1	Select Hotel	80	20	提供搜索界面，用户输入目的地/旅店名称，到达时间，旅店种类后，返回可以预定的旅店列表	有文本输入预测功能，语音输入功能
2	Make Reservation	70	25	填写详细入住时间，退房时间。旅店的楼层，房间等等	提供以往旅店评价，谷歌街景以供选择。
3	Use Shopping Basket	100	40	可以选择多家旅店，在购物车进行对比，最后选择一家。	以表格的形式对比不同的旅店
4	Make Payment	150	70	提供多种支付方式，用户可以选择自己喜欢的方式进行支付。	提供保险；订单发生错误，全额赔偿。

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

用例	事务	计算	原因	UC权重
Select Hotel	5	3		简单
Make Reservation	7	5		简单
Use Shopping Basket	10	7	健壮性	平均
Make Payment	15	15	安全等级高	复杂性