系分HW6
1、简答题
-
用例的概念
用例代表着系统中各个项目相关人员(多种用户角色,管理者等)之间就系统的行为所达成的契约,是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标
-
用例和场景的关系?什么是主场景或 happy path?
用例是多个不同场景的集合,happy path 是指无异常或错误发生的原始场景。
-
用例有哪些形式?
用例能够以不同形式化程度或格式进行编写:
摘要
- 简洁的一段式概要,通常用于主成功场景。
- 何时使用:在早期需求分析过程中使用,目的是为了快速了解主题和范围。可能只需要几分钟进行编写。
非正式
- 非正式的段落格式。用几个段落覆盖不同场景。
- 何时使用:在早期需求分析过程中使用,目的是为了快速了解主题和范围。可能只需要几分钟进行编写。
详述
- 详细编写所有步骤及各种变化,同时具有补充部分,如前置条件和成功保证。
- 何时使用:确定并以摘要形式白那些了大量用例后,在第一次需求讨论会中,详细地编写其中少量(例如10%)的具有重要架构意义和高价值的用例。
-
对于复杂业务,为什么编制完整用例非常难?
因为复杂业务会有很多场景,不同场景会有不同的行为,而用例是场景的集合,复杂的行为会导致用例的复杂
-
什么是用例图?
用例图是一种优秀的系统语境图,能够展示系统边界、位于边界之外的事务以及系统如何被使用,也可用以概况系统及其参与者的行为。
-
用例图的基本符号与元素?
基本符号:
1、参与者(Actor):表示的是一个系统用户,也就是与应用程序进行交互的用户、组织或者外部系统。
2、用例(Use Case):表示的是对系统提供的功能、服务的一种描述。
3、系统框:软件用例的集合
4、用例之间的关系:
**包含关系(Include):**表示用例可以简单地包含其他用例所具有的行为,并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示,箭头指向被包含的用例。
泛化关系(Generalization):泛化指的是一个父用例可以被特化形成多个子用例,而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示,箭头指向父用例。
**关联关系(Association):**表示的是参与者与用例之间的关系。在UML中常用一条直线,或者是一条带箭头的线条来表示,箭头指向信息接收方。
**扩展/延伸关系(Extend):**表示在一定条件下,把新的行为加入到已有的用例中,获得的新用例叫做扩展用例,原有的用例叫做基础用例,相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示,箭头指向基础用例。
-
用例图的画法与步骤
1)添加系统框并命名系统
2)添加actor
3)编写用例
4)编写用例的依赖
5)若有多个actor,重复2~4步骤
-
用例图给利益相关人与开发者的价值有哪些?
- 对利益相关人:
- 可以直观地了解系统的功能和使用方法/步骤
- 可以用于检查系统的完整性
- 可以从中添加创新业务
- 对开发者:
- 有一个清楚的开发流程和子类依赖关系
- 可以模块化开发
- 对利益相关人:
2、建模练习题(用例模型)
-
选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
- 请使用用户的视角,描述用户目标或系统提供的服务
- 粒度达到子用例级别,并用 include 和 exclude 关联它们
- 请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例
- 尽可能识别外部系统和服务
-
然后,回答下列问题:
-
为什么相似系统的用例图是相似的?
- 因为相似的系统提供的业务有其内在的基本流程,每个要运维这个业务的系统都需要实现。
-
如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术
-
针对不同时代,我们可以从技术入手,实现过去时代无法实现的功能,将业务过程和技术结合,创新表现形式,此外,还可以从新技术入手,增加应用场景;
-
针对不同地区,结合地区的文化风俗,地理人文,提供针对性的服务,包括表现方式,用户操作习惯等,还可以根据地区的节日,在平台上“举办”庆祝活动
-
-
如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
- 用例图可以呈现系统现有的模块功能,给项目经理对系统直观的认识,当有新技术或新需求时,项目经理(或设计者)可以根据用例图进行拓展和补充
-
请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
ID为一个唯一标识,确定后最好固定不变,在其他工作或者文档中想引用故事就使用这个ID来引用
Name 2到10个字,通过简单的描述来说明故事,如果要很多字才能表达这个故事,那很有可能这个故事太大,或者不清楚
重要性 这个优先级决定了sprint选择的故事,优先级越高的越早实现
初始估算 这个由Team来根据故事描述内容来估算,产品负责人讲解完故事后,Team对不清楚的进行询问,大概了解后进行粗略估算。从估算的角度出发,故事不应该太短,但也不能太过于详细,不需要把具体的规则和算法写进去。
How do demo 从用户视角,从操作层面进行讲解这个故事如何通过软件来演示,也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写”如何演示“。
Notes相关信息、解释说明和对其他资料的引用等,一般都非常简短。ID Name Imp Est How do demo Notes 1 Find hotel 80 25 在输入栏输入地点和时间范围或者直接在地图上选择相应位置的旅馆 根据用户评价等信息对旅馆进行排序,为用户推荐更好的旅馆 2 Make reservation 70 20 选择旅馆和房间类型后,确认个人信息并提交保证金即可 尽可能地提供全面的图片和文字描述,以确保房间与用户的期望值相差不大 3 Pay 60 15 选择使用信用卡或者其他电子支付手段 使用多种支付API,注意接口处的信息对应与用户的信息安全 -
根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算
用例 #业务 #计算 原因 UC 比重 查找酒店 3 2 简单 预订酒店 6 4 平均 支付订单 1 1 简单
-