系统分析与设计 作业4

Posted on | In | 浏览 次
Words count in article: 2.1k | Reading time ≈ 7

简答题

  • 用例的概念

    use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.

    用例是相关成功和失败场景的集合，用来描述使用系统来达到一个目的的参与者。

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

    • 用例(use case)和场景(scenario)的关系：用例表示一组场景(a collection of scenarios)，场景属于用例的实例。
    • 主场景(the primary scenario)或happy path：主场景是最常用的一个业务场景，对应于主要的系统交互，通常是“成功”场景，表示系统所实现的基本业务。

  • 用例有哪些形式？

    • Brief(high level): 一段简单的概要，通常是主要成功案例。主要在早期需求分析中，快速了解主题和范围，创作可能只需几分钟
    • Casual(简便格式): 非正式格式，涵盖各种场景的多个段落，主要在早期需求分析中使用
    • Fully: 所有的步骤和变化都写得很详细，并有支持部分，如前提条件和成功保证。主要在确定了许多用例并以简短格式编写后，详细编写了一些具有架构意义和高价值的用例

  • 对于复杂业务，为什么编制完整用例非常难？
    复杂业务涉及到的场景比较多，业务流程复杂繁琐，不同场景之间存在关联，系统交互比较复杂，需要考虑的备选流众多，因此编制完整用例非常难

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

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

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

      1

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

      2

    • 用例之间的关系

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

        3

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

        4

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

        5

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

        6

    • 子系统(Subsystem) — 用来展示系统的一部分功能，这部分功能联系紧密

      7

  • 用例图的画法与步骤

    • 绘制系统边界
    • 确定参与者信息，包括
      • 主要参与者（primary actor）：通过使用服务实现用户目标
      • 协作参与者（supporting actor）：提供服务
      • 幕后参与者（offstage actor）：对用例的行为感兴趣
    • 确定参与者之间的关系
    • 根据需求识别和编制用例
      • 确认用例间关系，如 include 与 extend
      • 确认用例与参与者的关系
      • 确定外部接口，在用例的事件流中发现其他系统支持，并将其标注出来放在系统框的右边

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

    • 对于利益相关人而言
      • 更直观地了解系统的功能与用户交互情况，以确保其需求得到满足
      • 用例能够根据需要对复杂程度和形式化程度进行增减调节，通过修改或者增加图形间的关系，使得整个系统的实现过程变得更灵活。
    • 对于开发者而言
      • 明确系统的业务范围、服务对象（角色）、外部系统与设备
      • 帮助识别技术风险，提前实施关键技术原型公关与学习
      • 易于评估项目工作量，合理规划迭代周期，规划人力需要

建模练习题（用例模型）

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

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

    • 饿了么
      eleme

    • 扇贝单词
      shanbei

  • 然后，回答下列问题：

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

      相似的系统的需求大致是相同的，主要的业务逻辑类似，其系统的用例图因此也是类似的

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

      所选择的产品没有涉及到旅馆业务，但是个人认为对于旅馆的推荐上依据用户的历史预定以及一些检索记录来为客户进行更加个性化的推荐

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

      在用例图中对创新用例使用某种颜色进行高亮标记，这样可以快速定位到新的创新思路，同时可以依据创新用例在整个系统中的位置，判断其重要性。

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

      | ID | Name | Imp | Est | How to demo | Note |
      | :—: | :———: | :—: | :—: | :—————————————————————————————: | :—————————————————————————————: |
      | 1 | 注册 | 20 | 3 | 输入手机号，收到注册的验证码，输入验证码以及一些个人信息后，注册成功 | 注册成功后跳转到主页，并且保持登陆的状态 |
      | 2 | 登陆 | 10 | 2 | 手机验证码登陆、微信登陆等一些三方登陆测试 | |
      | 3 | 搜索酒店 | 50 | 10 | 根据输入信息能够匹配到正确的合适的酒店结果 | 可以根据价格、好评等方面进行排序展示 |
      | 4 | 预定酒店 | 100 | 15 | 用户选择好酒店的房间以及居住天数后进行预定 | 需要考虑相应酒店在指定日期内是否有相应的空闲房间，并且预定时候会锁定房间，此时别的用户不能再预定该房间 |
      | 5 | 支付订单 | 60 | 8 | 对预定的酒店进行支付，确保支付的金额正确 | 支持多种支付方式，如支付宝支付、微信支付 |
      | 6 | 查询订单 | 40 | 5 | 查询自己的订单情况 | 包含已完成的订单和未完成的订单 |

5. 根据任务4，参考[使用用例点估算软件成本](https://www.ibm.com/developerworks/cn/rational/edge/09/mar09/collaris_dekker/index.html)，给出项目用例点的估算

   |   用例   | 事务 | 计算 | UC权重 |
   | :------: | :--: | :--: | :----: |
   |   注册   |  1   |  1   |  简单  |
   |   登陆   |  3   |  1   |  简单  |
   | 搜索酒店 |  8   |  4   |  复杂  |
   | 预定酒店 |  5   |  3   |  平均  |
   | 支付订单 |  4   |  2   |  平均  |
   | 查询订单 |  3   |  2   |  平均  |