系统分析（4）

一、简答题

1. 用例的概念

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

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

用例通常通过一个参与者（Actor）向系统做出请求，系统根据参与者的请求，在不同的条件下，执行某一行为序列。每一个行为序列可以称之为一个场景，一个用例包含多个场景。场景也可以称之为用例的一个实例。

 

主场景是描述了当系统各项工作都正常进行时的用例的工作方式,参与者在用例中所遵循的主逻辑路径，也被称为happy path。

 

3. 用例有哪些形式？

1. Brief:简单的摘要，通常是用于描述成功案例,用于早期的需求分析中,快速了解主题和范围,创建时间比较短

2. Casual：非正式段落格式,有多个段落包含多个场景

3. Fully：包含所有场景的步骤和变化都写得很详细，并有支持部分，如先决条件和成功保障

 

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

对于复杂业务，无论是actor还是场景都比较多和复杂，无法预想到所有的actor的情况，也无法预想到所有的不同场景，所以编制完整用例非常难。

5. 什么是用例图?

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

 

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

1. actor参与者:参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

2. 用例:用例通常通过一个参与者（Actor）向系统做出请求，系统根据参与者的请求，在不同的条件下，执行某一行为序列。

3. 系统边界:系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

4. 箭头:箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

5. 用例之间的关系：

1. 包含关系(Include)：表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例。

2. 泛化关系(Generalization)：泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示，箭头指向父用例。

3. 关联关系(Association)：表示的是参与者与用例之间的关系。在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方。

4. 扩展/延伸关系(Extend)：表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例。

7. 用例图的画法与步骤

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

2. 识别 Actors :

1. 识别使用系统的主要参与者（primary actors）/角色(roles) 。使用用例图 actor符号 表示，通常放在系统的左边

2. 识别系统依赖的外部系统 :使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别

3. 识别用例 ：

1. 识别用户级别用例（user goal level） 以主要参与者目标驱动，收集主要参与者的业务事件

2. manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等

3. 识别子功能级别的用例,实现业务复用，复杂业务分解。

4. 正确使用用例与子用例之间的关系,如include和extend

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

 

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

1. 明确系统的业务范围、服务对象（角色）、外部系统与设备

2. 帮助识别技术风险，提前实施关键技术原型公关与学习

3. 易于评估项目工作量，合理规划迭代周期，规划人力需要

 

二、建模练习题  

背单词系统  

  

订电影票系统  

  

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

因为相似系统的目标功能和人群的行为是差不多的，即actor和场景都是类似的，所以用例也是相似的，导致用例图也会比较相似。

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

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

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

在项目的早期,可以通过分析当前用例图，并和其它产品的用例图进行横向对比,看一下类似产品的业务和技术，商业模式和我们设计的产品用例图中有什么相似或者不同的地方，取其精华，弃其糟粕，从别人产品用例图和我们初始用例图都缺少的业务功能或者业务细节和用户使用角度进行分析，定位创新的思路。

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

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

  

  

事务和计算

如果您拥有识别用例事务的能力，您是否需要对它们平等的重视？我们的策略是显示它们中的，每一个与事务（如果可以应用的话），但是有些时候并不计算它们的权重。我们的策略要比直接忽略它们更加直接。如果需要的话，调整原始的估算也十分的容易。

通过这种方式，您就能够看出框架的价值。如果用例计算十个事务的话，但是它们中只有三个值得处理，另外三个遵循框架，该用例是普通的而不是复杂的。