Fourth PM Homework…..

系统分析与设计 – Homework 4

姓名：陈明亮

学号：16340023

简答题

1. 用例的概念

• 在软件与系统工程中，用例（Use Case）用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

  ​

• 同时，用例也是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。

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

• 用例与场景的关系： 用例也称用例实例，是相关的成功与失败场景的集合，因为用例包含若干场景。参与者与系统之间的一个特定的行为和交互序列也称用例。

  ​

• 主场景或happy path： 主场景（happy path）也被称为“理想路径”场景，或“基本流程”及“典型流程”。它描述了满足涉众关注点的典型成功路径。它是典型的、无条件的、理想方式的主成功场景。用例是成功和失败场景的集合，其中主场景是用户与系统之间的主要交互，是最常用的实现用户目标的场景。

3. 用例有哪些形式？

用例的形式有如下三种：

• 简洁Brief：通常是简短的一段总结，描述主要的成功场景happy path，在需求分析中利于快速了解主题以及范围，几分钟内便可创建。
• 非正式型Casual：非正式段落格式，使用几个段落覆盖不同的场景。
• 完整型Fully：所有的变化、所有的步骤都会写得很详细，并且有补充的部分，比如前提条件与成功保证。

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

• 因为对于复杂业务，其涉及的场景数量会变得很多，而各个场景之间的关联使得用例设计变得特别困难，因为用例是各个成功与失败场景的集合。

  ​

• 用例的编写需要对这些场景熟悉，并且需要建模知识与注意用户交互的相关细节，但依旧无法完整地覆盖各种实际中可能会出现的情况，用例总是不完整的。所以编制完整用例非常难。

5. 什么是用例图？

• 用例图User Case由参与者Actor、用例Use Case，边界以及它们之间的关系构成的用于描述系统功能的视图。

  ​

• 用例图同时也是参与者（外部用户）所能观察到的系统功能的模型图。用例图是系统的蓝图。

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

用例图基本符号与元素：

• 参与者Actor

  • 表示一个系统的用户，即与应用程序或系统进行交互的用户、组织或者外部系统。参与者用一个小人表示。

  • 参与者包括三类

  • 系统用户

  • 其他系统。在当前项目范围之外，需要建立与其他系统的接口。

  • 一些可以运行的进程

    ​

• 用例Use Case

  • 外部可见的系统功能，表示对系统提供功能、服务的描述。用例用一个椭圆表示。 ​

• 用例之间的关系：

  • 关联Association表示参与者与用例之间的关系。关联关系用一条直线表示，由参与者指向用例。

  • 泛化Inheritance，可以理解为继承关系，父用例可以特化为若干个子用例。子用例与父用例相似，但表现更为特别的行为。子用例继承父用例的所有结构、行为以及用例关系。父用例与子用例之间的关系极为泛化关系。泛化关系用带箭头的直线表示，箭头指向父用例。

  • 包含Include，较复杂的用例可以被分解为较小的用例，即该用例可以包含其他用例所具有的行为。包含关系使用带箭头的虚线表示，箭头指向被包含的用例。

  • 扩展Extend表示用例功能的延伸。把新的行为加入到基础的用例上，使得基础用例能够获得新的行为并能够提供新的附加功能。扩展关系使用带箭头的虚线表示，箭头指向基础用例。

7. 用例图的画法与步骤

用例图的画法与步骤如下：

• 确定研讨的系统，画出一个system框表示待研究的系统

  • 正确命名系统或子系统，不能将研究的系统名称起的太泛。

    ​

• 识别Actors

  • 识别使用系统的主要参与者Primary Actors以及角色Actor

  • 将参与者（小人）画在系统边界的左侧。

  • 企业应用可以通过企业组织架构，业务角色与职责识别。

  • 互联网应用则必须通过市场分析，确定受众范围。

  • 不要使用”用户“代表系统的使用者，以免国语通用导致缺少用户体验。

  • 识别系统依赖的外部系统

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

  • 需要将一些专业功能赋予专业系统。

    ​

• 识别用例（服务）

  • 识别用户级别用例user goal level

  • 以主要参与者目标驱动

  • 收集主要参与者的业务事件

  • 必须满足以下准则

    • boss test
    • EBP test
    • Size Test

  • 识别子功能级别的用例sub function level

  • 子用例特征

    • 业务复用。
    • 复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现。
    • 强调技术或业务创新。

  • 正确使用用例与子用例之间的关系

    • << include >> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义。

    • << extend >> 表示子用例是父用例的可选场景或技术特征。

    • 箭头表示的依赖关系，<< include >> 箭头指向子用例；<< extend >> 箭头指向父用例。

      ​

• 确定参与者Actors与用例Use cases之间的关系，并用无方向的连线将它们连接起来表示双向的交互协议。

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

利益相关人：

• 用例图可以直观看清系统的结果以及用户的功能体验，提供了系统使用和行为的摘要视图，保证系统能够按照用户的需求进行设计，并且便于与利益相关人进行沟通，及时对系统功能进一步完善。

• 用例图能够根据业务场景的复杂程度和形式化程序进行增减调节，能够相应利益相关人提出的需求。通过用例图进行系统功能的增减以及修改更加便利。

• 用例图使得系统能够注重其参与者的用户体验。

  ​

开发者：

• 用例图能够为开发者提供参考，使得设计的过程更加清晰明确。同时用例图也是系统的蓝图，是开发过程的蓝图。
• 用例图能够更明确客户的需求，使得开发者能够更好理解客户需求，相应客户的需求。
• 用例图能够明确系统的范围以及其提供功能的情况、与外部系统之间的关系，便于开发者进行系统的实现。
• 用例图便于评估其项目工作量，能够知道设计、开发以及测试，便于管理者明确其项目开发的迭代周期，能够在软件开发过程中起到很好的规划作用。

建模练习题

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

• 请使用用户的视角，描述用户目标或系统提供的服务

• 粒度达到子用例级别，并用 include 和 exclude 关联它们

• 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例

• 尽可能识别外部系统和服务

  ​

  扇贝单词

  

  百词斩

  

回答下列问题：

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

这是因为用例图由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。如果系统是相似的，在相似的最终目标下，系统的参与者、用例、边界以及它们之间的关系构成也是相似的，最终画出来的用例图是相似的。

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

该题不涉及旅馆预定业务。抱歉。

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

通过在用例图中使用与其他用例不同的颜色进行标记的方法，能够使得开发者快速定位到该用例图中的创新点。并且可以查看该创新思路在用例中的位置。如果在主用例中则它很重要，否则相对来说并不是特别重要。

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

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

• Previous
  系统分析与设计 第三次课程作业
• Next
  系统分析与设计 第五次课程作业