系统分析与设计_HW4

hw4

简答题

用例的概念

用例是文本形式的情节描述，用于说明参与者参与系统来实现的某些目标。用例是文本而不是图形，用例指示系统将做什么，是一组成功或失败的场景，描述对象是用户，用例建模是编写文本。

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

**关系：**用例是场景的集合，每个用例提供了一个或多个场景。

**主场景：**每个用例包含一个主场景，系统主要交互是主场景，一般是最成功的场景，也是能直接实现用户目标的场景。

**happy path：**没有异常或错误条件的默认场景，即用户和系统可以很顺利、无误、符合预期地进行交互。

用例有哪些形式？

• **Brief(high level)：**通常是主场景的总结，在早期分析需求的过程中，breif形式可以帮助开发者和客户快速了解软件系统的主题和应用范围等信息，可以快速创建。

• **Casual(简便格式)：**非正式的段落格式；覆盖多个场景的几个段落，与breif近似，在早期需求分析过程中，有助于快速了解主题和范围。

• **Fully：**用例中所有的步骤和变化都写得很详细，包括前置条件等应用环境。所有的用户样例都已经定制出初步版本后，优先级更高的用例会被详细编写。

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

复杂的业务涉及很多场景，且场景与场景之间存在复杂的关联。如果场景不够全面，那么用例的完整性就难以保障。

编制完整用例需要熟悉各种业务场景、流程和建模相关的专业知识，对编写者的水平要求较高。

什么是用例图？

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

用例图是系统的蓝图，它呈现了一些参与者、一些用例以及他们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

用例图（use case）是外部用户（被称为参与者）所能观察到的系统能能的模型图。

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

四个基本部分元素有：

• **参与者：**参与者是与系统交互的人或物。首先当然包括我们的开发系统用户，除此之外，与我们开发的系统有关联的其他系统也算是参与者。

  在UML图中我们用一个小人表示。

  

• **系统边界：**指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。

  在UML图中我们用一个矩形表示。
  

• **用例：**用例是参与者可以感受到的系统服务或功能单元。我理解的就是用户可以使用我们开发的项目去做的任何事情

  任何用例都不能在缺少参与者的情况下独立存在，同样，任何参与者也必须要有与之关联的用例。在UML图中我们用椭圆表示：
  

• 关系：

  • **关联：**表示参与者和用例之间的交互。为通信途径，任何一方都可发送或可接收消息。

    箭头指向：指向消息接收方。在UML中用直线表示
    

  • **泛化：**用例的泛化指的是一个父用例可以被特化形成多个子用例，用我们熟悉的语言来说就是继承关系。

    在UML中，泛化关系用空心箭头表示，箭头指向的是父用例。
    

  • **包含：**包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就是不完整的。
    

  • **扩展：**扩展关系是指用例功能的延伸。与包含关系不同的是，扩展用例是可选的，如果缺少扩展用例。不会影响到基用例的完整性。
    

    在UML中，扩展关系用带箭头的虚线段加《extend》表示，要注意的是箭头指向基用例。

用例图的画法与步骤

1. 确定参与者
   在获取用例前首先要确定系统的参与者， 开发人员可以通过回答以下的问题来寻找系统的参与者。
   （1） 谁将使用该系统的主要功能。
   （2） 谁 将需要该系统的支持以完成其工作。
   （3） 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
   （4） 系 统需要处理哪些硬件设备。
   （5） 与该系统那个交互的是什么系统。
   （6） 谁或什么系统对本系统产生的结果感兴趣。

2. 识别用例
   用例图对整个系统建模过程非常重要，在绘 制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个 问题。识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系 统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。
   在识别用例的过程 中，通过回答以下几个问题，系统分析者可以获得帮助。
   （1） 特定参与者希望系统提供什么功能。
   （2） 系 统是否存储和检索信息，如果是，由哪个参与者触发。
   （3） 当系统改变状态时，是否通知参与者。
   （4） 是 否存在影响系统的外部事件。
   （5） 哪个参与者通知系统这些事件。

3. 确立用例间的关系

   使得用例结构化

4. 确定关联的外部支持系统

   放在系统框右边。

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

1. 用例图描述了系统功能、需求范围，一来明确业务范围（方便开发人员理解），二来明确功能范围（便于用户理解）

2. 使用用例图使利益相关人能更形象准确地传达对需求的认识，清晰地表达其想法

3. 帮助评估工作量

建模练习题（用例模型）

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

回答下列问题：

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

因为相似系统的功能、用户都是很类似的，从而确定的系统边界、参与者和用例场景都是很类似的，进而导致用例图很相似。

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

• 随着时代变化，新技术不断产生，因此可以使用新技术替换/丰富旧用例图中的技术（比如使用支付宝支付、微信支付丰原来的单一支付方式）

• 对于不同的地区，则应该充分考虑结合当地特色，比如在订餐系统的推荐功能中，为用户推荐当地特色美食，并且考虑一些地方的特殊性（如自治区，西藏），尊重当地饮食习惯进行推荐

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

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

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

Name	Imp	Est	demo	Notes
登录系统	30	10	用户输入用户信息，邮箱密码电话，来进行登录或者第一次注册	一个邮箱电话对应一个账号，添加电话的原因防止过度乱注册
订单系统	50	20	根据距离的远近查找旅馆，选择套房，下单，取消订单，预约等	注重距离的远近，地区的安全性，和事实的套房信息
支付系统	10	5	多种支付手段，支付宝，微信，银联，现金	保证用户资金安全
评价系统	30	10	评价，住完旅馆后可以在评价系统上进行评价，也可以参看他人的评价	收集用户的评价反馈，优化用户的体验，商家进行改进

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

用例	事务	计算	原因	UC权重
注册登录	2	2	登录，注册两个功能，比较简单	简单
订单	6	6	有搜索，选择，预订，下订单，取消订单，一系列操作比较复杂	复杂
支付	3	3	三种支付方式，/	简单
评价	3	2	评价，投诉等功能	平均