系统分析与设计homework4

1.简答题

1.用例的概念

用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

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

用例通常通过一个参与者（Actor）向系统做出请求，系统根据参与者的请求，在不同的条件下，执行某一行为序列。每一个行为序列可以称之为一个场景，一个用例包含多个场景。场景也可以称之为用例的一个实例。 主场景是描述了当系统各项工作都正常进行时的用例的工作方式,参与者在用例中所遵循的主逻辑路径，也被称为happy path。

3.用例有哪些形式？

• brief:简单的摘要，通常是用于描述成功案例,用于早期的需求分析中,快速了解主题和范围,创建时间比较短
• casual:非正式段落格式,有多个段落包含多个场景
• fully:非正式段落格式,有多个段落包含多个场景

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

对于复杂业务来说，可能出现的情况非常多，所以无论是actor还是场景都比较多和复杂，此种情况下要考虑到所有的Actor和场景不仅实现起来非常难，而且实际上没有实施的必要。所以对于复杂业务来说，编制完整用例是很难的。

5.什么是用例图？

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。

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

• 参与者(Actor):表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。

• 用例(Use Case)：表示的是对系统提供的功能、服务的一种描述。

• 用例之间的关系：

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

7.用例图的画法与步骤

• 确定研讨的系统:使用用例图 System框 表示一个待研究的系统。正确命名系统或子系统

• 识别 Actors :

  • 识别使用系统的主要参与者（primary actors）/角色(roles) 。使用用例图 actor符号 表示，通常放在系统的左边
  • 识别系统依赖的外部系统 :使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别

• 识别用例 ：

  • 识别用户级别用例（user goal level） 以主要参与者目标驱动，收集主要参与者的业务事件
  • manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等
  • 识别子功能级别的用例,实现业务复用，复杂业务分解
  • 正确使用用例与子用例之间的关系,如include和extend

• 建立 Actor 和 Use Cases 之间的关联 :使用 无方向连线，表示两间之间是双向交互的协议

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

• 对于利益相关人：

  • 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
  • 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。

• 对于开发者来说：

  • 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
  • 用例图使得开发者能够更明确地获得需求，更好地理解需求。
  • 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

2.建模练习题(用例模型)

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

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

  电影订票系统
  
  
  
  
  背单词系统
  

• 然后，回答下列问题：

  1. 为什么相似系统的用例图是相似的？
     
     答：相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。

  2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术?
     
     答：首先可以先画出并查看旧时代的，多个地区相同产品的用例图，然后可以从中找出不足的地方，加以改进，例如删掉一些冗余的功能，进行市场调研看下这些旧产品有什么用户期望的功能缺失，可以进行补充创新，或者说结合当前时代的技术新特点，像室内定位，区块链等新技术，对原有的业务功能进行创新。

  3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
     
     答：项目早期对用例图进行分析，通过横向对比其他同类产品的用例图，可以很直观地发现当前市场上此类产品的一般设计模式。同时，我们也可以对产品设计的不足和用户的痛点一目了然，我们针对用例图上某方面存在的不足，提出比较合理的解决方案，将其作为我们产品的创新点，作为我们的主要竞争力。

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

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