系统分析设计---作业4
文章目录
简答题
- 用例的概念
用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中，用以说明某参与者使用系统以实现某些目标。
- 用例和场景的关系？什么是主场景或 happy path？
- 场景：场景是参与者与系统之间的一系列特定的活动和交互，也称为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。
- 用例与场景的关系：用例就是一组相关的成功和失败场景集合，用于描述参与者如何使用系统来实现其目标。
- 主场景或happy path：这是用例最基本的组成部分，它描述了满足涉众关注点的典型成功路径。要注意的是，主场景通常不包括任何条件或分支，这是为了保持连贯性，并且将所有的条件处理都延迟到扩展部分。这种具有争议的做法更易于理解和扩展。
- 用例有哪些形式？
- Brief（摘要）:简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为了快速了解主题和范围，只需要几分钟进行编写。
- Casual（非正式）:非正式的段落格式，用几个段落覆盖不同场景
- Fully（详述）:详细编写所有步骤以及各种变化，同时具有补充部分，如前置条件和成功保证，确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量（例如10%）的具有重要架构意义和高价值的用例
- 对于复杂业务，为什么编制完整用例非常难？
复杂业务的需求多，导致扩展部分较多，即除了主成功场景外的其他场景或分支，包括成功和失败路径。而在整个用例编写过程当中，理想路径与扩展场景相结合也只能尽可能满足“几乎”所有涉众所关注的问题，因为有些问题最好是作为非功能性需求在补充规格说明中描述，而不是直接在用例中说明。因此由于业务的复杂性，用例的增加也只能覆盖大部分已出现的情形，而无法完全覆盖所有情景，也就“不完整”。同时，用例可能会遗漏一些关键信息或包含错误的陈述。
- 什么是用例图？
用例图：是指由参与者（Actor）、用例（Use Case）,系统边界以及它们之间的关系构成的用于描述系统功能的图。
- 用例图的基本符号与元素？
基本符号与元素有：
- 参与者：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统
- 用例：表示的是对系统提供的功能、服务的一种描述
用例之间的关系：
- 包含关系：表示用例可以简单包含其他用例所具有的行为，并把它包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例。
- 泛化关系：泛化指的是一个父用例可以被特例化为多个子用例，而父用例与子用例之间的关系就是泛化关系，在UML中用空心三角箭头的实现表示，箭头指向父用例。
- 关联关系：表示的是参与者与用例之间的关系，在UML中常用一条直线来表示，箭头指向信息接受方。
- 扩展/延伸关系：表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例。
- 用例图的画法与步骤
- 定义主题： 主题是我们正在设计的业务，软件系统，子系统，组件，设备等，或者只是试图了解它是如何工作的，定义他是什么类型的系统，他的范围或边界是非常重要的。给他一个正确的名称，并使用适当的构造型。通过声明一个主题，我们正在定义系统的边界，以便能够确定系统内部的内容或内容，以及外部的内容或内容。
- 定义演员：UML Actor是主题需要服务的用户，Actor是一个外部实体，可以是设计系统的人类用户，也可以是使用我们系统的其他系统或设备。actor应该根据他们在我们系统中扮演的角色来命名。
- 定义用例：当我们定义我们正在设计或分析的系统的边界以及系统的外部用户时，我们需要定义这些用户从系统中需要什么。每个用例 都指定了主题为actor提供的完整且有用的功能单元。用例应反映用户的需求和目标，并应由演员发起。顶级用例应描述提供给actor的完整功能单元。
- 描述用例行为：用例行为(behaviors)可以用自然语言文本（不透明行为）来描述，
- 用例图给利益相关人与开发者的价值有哪些？
- 对于利益相关人：
- 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
- 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
- 对于开发者来说：
- 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
- 用例图使得开发者能够更明确地获得需求，更好地理解需求。
- 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。
建模练习题（用例模型）
-
选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
- 请使用用户的视角，描述用户目标或系统提供的服务
- 粒度达到子用例级别，并用 include 和 exclude 关联它们
- 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
- 尽可能识别外部系统和服务
- 分析去哪儿旅游App，用例图如下
- 分析美团外卖App，用例图如下
-
然后，回答下列问题：
- 为什么相似系统的用例图是相似的？
在相似的系统中，用户的预期目标是一样的，不用的系统需要达到用户期望的目的是一样的。如订票系统都需要用户提供时间、地点、票的类型等。为了提供相似的服务，相似的系统之间的用例图也是相似的。
- 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
- 从技术的角度出发：当下订旅馆业务的软件，，更最求效率和速度，相比于Asg_RH用例图，当下订旅馆的无疑拥有更好的筛选系统，可以更加快速的选择自己想要的旅馆。
- 从业务创新的角度出发：相比于传统，当下的订旅馆扩展和创新了很多业务，如增加房型，变更提供房间的方式，这些都使得用户的选择更多，用户体验更好。
- 从时代的角度出发：当下订旅馆业务呈现多元化，并且在用户的信息保护上有了很大的突破和进展。
- 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
- 依据用例图中的每一个用例可以很清楚的知道，当前用例是其他系统所没有的，即创新点
- 依据创新用例在用例图中的关系和位置，可以很清楚的知道，创新用例依据的外部系统或者从属关系，很好的定位其服务方式和服务场景，发挥更好的服务效果。
- 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
Product Backlog 是 Scrum 的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（Story），有时候也叫做 Backlog 条目。 一般包括以下字段：
- ID：统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
- Name（名称）：简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
- Importance（重要性）：产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
- Initial Estimate（初始估算）：团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“一个人一天理想的工作量（man-day）”。
- How to demo（如何做演示）：它大略描述了这个故事应该如何在 sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。
ID Name Imp Est How to demo Notes 1 搜索住房 100 40 用户选择时间、地点、人数点击搜索；按照地理位置推荐住房 需要拥有住房大数据，GPS定位系统API，良好的表单提交功能 2 预定住房 80 30 用户挑选心仪的住房并预定 需要有良好的筛选算法，构建快速高效的筛选系统 3 支付住房 50 10 用户预定好房间，提交订单并支付 良好的接口，对接外部第三方的支付平台 4 评价旅馆 50 10 用户对已完成订单的商家进行评价 需要有良好的评价机制和考评制度
- 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算
用例 业务 计算 原因 UC 比重 搜索住房 3 2 简单 预定住房 6 4 平均 支付住房 1 1 简单 评价旅馆 2 1 简单