16341016.github.io

Follow me on GitHub

一、简答题

1. 用例的概念

  • 用例(英语:use case),或译使用案例、用况,是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标。编写用例时要避免使用技术术语,而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

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

  • 场景的定义:是客户与系统之间的交互行为。场景是用例的实例,一用例是场景的集合。
  • 用例和场景的关系:用例就是一组相关的成功和失败场景集合,用来描述参与者如何使用系统来实现其目标。
  • 主场景,是场景中最主要的交互,一般是经常出现的,用户最常用的场景流程。

3. 用例有哪些形式?

  • Brief(high level):通常是主场景的总结,在早期分析需求的过程中,breif形式可以帮助开发者和客户快速了解软件系统的主题和应用范围等信息,可以快速创建
  • Casual(简便格式):非正式的段落格式;覆盖多个场景的几个段落,与breif近似,在早期需求分析过程中,有助于快速了解主题和范围
  • Fully:用例中所有的步骤和变化都写得很详细,包括前置条件等应用环境。所有的用户样例都已经定制出初步版本后,优先级更高的用例会被详细编写。

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

  • 复杂业务的需求多,导致扩展部分较多,即除了主成功场景外的其他场景或分支,包括成功和失败路径。而在整个用例编写过程当中,理想路径与扩展场景相结合也只能尽可能满足“几乎”所有涉众所关注的问题,因为有些问题最好是作为非功能性需求在补充规格说明中描述,而不是直接在用例中说明。因此由于业务的复杂性,用例的增加也只能覆盖大部分已出现的情形,而无法完全覆盖所有情景,也就“不完整”。同时,用例可能会遗漏一些关键信息或包含错误的陈述。

5. 什么是用例图?

  • 用例图是一种以绘图的方式展现用例场景的表示方法。用例图以用户和用户行为为主,可以体现出用户与系统的交互场景,并使用图形化的方式,形象地展示出系统的边界和使用方法,对于开发者和使用者来说,都可以通过用例图了解系统与用户间可能的交互行为

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

  • 参与者(actors):表示系统中的用户,即与系统交互的对象
  • 用例(use case):用户与系统的交互行为,可以理解为用户可以使用系统做的事情
  • 包含关系(include):被指向的用例为发起用例的行为之一
  • 扩展关系(extend):被指向的用例为发起用例的扩展功能
  • 泛化关系(generalization):被指向的用例是发起用例的特例之一
  • 关联关系(association):表示参与者与用例之间的关系

7. 用例图的画法与步骤

  • 确定系统边界,先使用方框画出系统边界并标记系统名称
  • 确定参与者,明确参与者是谁:用户?管理员?设备?只要是使用系统产生交互的对象都是参与者,在系统边界外部使用参与者符号,添加参与者信息
  • 确定用例,明确系统中的用例场景都有什么:确定系统功能,确定用例之后,在系统方框内添加用例符号并标识用例信息,明确参与者与用例之间的交互关系:确定参与者与用例之间的关系之后就可以使用关联关系的符号将两者相连,明确用例之间的关系:明确将用例之间的关系,分别为泛化关系、包含关系、扩展关系,分别用这三种关系的符号连接相应的用例
  • 确定外部接口,外部接口可能是一些API的调用,在系统方框外用其他的方框标识调用的外部api,并使用关联关系符号将接口与调用此接口的用例相连

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

  • 用例图便于帮助未参与需求设计的开发者更好地理解系统功能,是开发者与产品负责人沟通的桥梁
  • 用例图可以形象地展示系统边界以及系统功能,对于项目工作量的呈现也是十分形象化的
  • 用例图可以帮助开发者梳理项目开发流程与技术要点,便于开发者进行研究学习与开发准备

建模练习题(用例模型)

  • 选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
    • 请使用用户的视角,描述用户目标或系统提供的服务

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

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

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

      • 携程预订酒店UML:

      携程

      • 淘票票订票UML:

      淘票票

  • 然后,回答下列问题:

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

他们的核心业务逻辑相似。在用户的角度上,用户所需进行的操作也是类似的。因此系统的用例图是相似的。

2. 如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术,如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用

  • 从不同时代的用户对操作便捷性的需求出发,可以使用当下更为便捷的技术来满足。例如在支付功能上,以往只能使用银行卡进行支付,而如今可以使用微信支付等方式,验证指纹即可顺利支付。

  • 也可以从用户对功能的需求角度出发,利用当下的技术进行新功能的加入。例如用户的评价功能和排序功能,这些功能能够让用户在较短的时间内过滤掉评分低的酒店,快速选到心仪的酒店,提升用户体验。这也是Asg_RH所不具备的功能。

3. 请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表

  • 定位城市:手动选择城市或者使用GPS自动定位城市
  • 预定房间:选择酒店、房型,并选择入住时间和天数
  • 确认订单:提供入住人信息并校对
  • 支付:银行卡支付、微信或支付宝支付
  • 评价:对酒店的评价

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

用例 业务 计算 原因 UC权重
定位城市 3 2   平均
预定房间 7 6   困难
确认订单 2 1   简单
支付订单 3 3   平均
用户评价 2 1   简单