系统分析与设计 第六周

系统分析与设计 第六周 )

---

1 简答题

1.1 用例的概念

解答：

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

---

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

解答：

• 1> 用例与场景的关系

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

• 2> 什么是主场景或happy path

每个用例都包含一个主场景，这个场景是用户和系统发生主要交互，是最常用实现用户目标的场景。

---

1.3 用例有哪些形式？

解答：

用例有三种常见的形式：

• 1> Brief（high level）

简洁型，通常是简短的一段总结，描述主要的成功场景，在早起需求中快速了解主题和范围，可以快速创建。

• 2> Casual

随意型，非正式的段落格式，涵盖各种场景的多个段落。

• 3> Fully

完整型，所有的步骤和变化都写得很详细，并有支持部分，如先决条件和成功的保证。

---

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

解答：

• 复杂业务活动包含很多用例，他们与过程关系用户难以理解，功能业务逻辑十分复杂，且非常耗时
• 场景与场景之间存在复杂的关联，如果场景不够全面，那么用例的完整性就难以保障
• 业务与需求本身就是需要不断迭代来确定的，一直处于变化的状态

---

1.5 什么是用例图？

解答：

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

---

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

基本元素如下：

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

---

1.7 用例图的画法与步骤

解答：

1> 确定参与者

• 谁将使用该系统的主要功能。
• 谁将需要该系统的支持以完成其工作。
• 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
• 系统需要处理哪些硬件设备。
• 与该系统那个交互的是什么系统。
• 谁或什么系统对本系统产生的结果感兴趣。

2> 识别用例

• 特定参与者希望系统提供什么功能。
• 系统是否存储和检索信息，如果是，由哪个参与者触发。
• 当系统改变状态时，是否通知参与者。
• 是否存在影响系统的外部事件。
• 哪个参与者通知系统这些事件。

3> 确定用例间的关系

• 用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。

---

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

解答：

用例图描述了一个系统的主要功能以及怎样去使用，可以让人清楚的知道系统的各个模块以及各部分功能的关系，对系统进行了可视化，在开发过程可以起到指导作用，能够帮助更合理的进行人员的安排。也可以便于向用户阐述系统功能。

---

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

2.1 绘制用例图

解答：

• 1> 美团外卖

• 2> 猫眼电影

---

3 回答下列问题

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

解答：

• 1> 相似系统的主要业务逻辑类似，比如查询系统通常只是查询内容的不同，而登录、注册、查询、管理订单这些基本功能都是相同的，用例的类型基本固定，与子用例的关系也类似。
• 2> 相似系统面向的Actor是相似的，从Actor视角定义的用例也是相似的，连同用例之间的关系都是相似的。这本质是因为相似系统的功能需求是相似的。

---

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

解答：

• 1> 利用时代发展的新技能不断丰富功能，例如越来越精准的数据预测等。
• 2> 不断把握用户的需求，根据用户的需求不断优化产品。
• 3> 针对不同环境推出符合当地特色服务，例如不同省市尊重当地习俗。

---

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

解答：

通过在用例图定位的创新思路（标记的创新用例），可以方便项目经理（业务创新）、需求方（商业模式创新）、开发者（技术创新）明确创新点。

---

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

解答：

Name	Imp	Est(man-day)	How to demo	Notes
搜索旅店	10	3	选择城市；入住离店日期；关键字搜索	搜索应当预先设置默认值；用户可对搜索结果进行排序
预定房间	7	4	选择旅店；入住离店日期；房间类型；房间数量	应排除已被预订的房间；对房间进行排序
确认订单	7	3	填写入住信息	必须填写：联系方式；身份证号
支付	5	2	选择付款方式	注意多种付款方式的接口；支付失败后退款
管理订单	4	2	查看已支付的订单；取消订单	取消订单需要三方确认；退款

---

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

解答：

根据用户点方法，权重分配为：

• 简单用例：1 到 3 个事务，权重=5
• 一般用例：4 到 7 个事务，权重=10
• 复杂用例：多于 7 个事务，权重=15

用例	事务	计算	权重
搜索酒店	3	2	简单
预定房间	4	4	一般
确认订单	3	2	简单
付款	2	2	简单
管理订单	2	2	简单