1.简答题
- 用例的概念
用例是在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标。编写用例时要避免使用技术术语,而应该用最终用户或者领域专家的语言。 - 用例和场景的关系?什么是主场景或 happy path?
用例场景是实例化的用例,一个用例实例化可以出来多个场景。用例就是对全部用例场景的抽象,用例场景就是从用例中实例化出的一组活动。
主场景是实现用户目标的最简单,最直接的场景,是一个没有异常或错误条件的默认场景 - 用例有哪些形式?
- 摘要格式:简短的一段式总结,通常是主要的成功场景。
- 简便格式:非正式的段落形式,多个包括不同场景的段落。
- 完整格式:所有的步骤和变化都被详细地记录,还包括提供支持的单元,比如前提条件和成功的保障
- 对于复杂业务,为什么编制完整用例非常难?
复杂业务对应的设计场景会非常多,场景之间的相互关联使得用例建模变得十分复杂。在前期的考虑中,很有可能遗漏一些业务和需求,因此对于复杂业务想要编制完整用例会非常困难。 - 什么是用例图?
用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统,以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素,如系统、参与者和用例,并且显示这些元素之间的各种关系,如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图,帮助开发团队以一种可视化的方式理解系统的功能需求。 - 用例图的基本符号与元素?
- 元素
- 参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
- 用例(Use Case)——用例就是外部可见的系统功能,对系统提供的服务进行描述。用椭圆表示。
- 子系统(Subsystem)——用来展示系统的一部分功能,这部分功能联系紧密。
- 参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
- 关系
- 关联(Association):表示参与者与用例之间的通信,任何一方都可发送或接受消息。
- 泛化(Inheritance):就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
- 包含(Include):包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。包含关系对典型的应用就是复用,也就是定义中说的情景。但是有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。
- 扩展(Extend):扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。将基用例中一段相对独立并且可选的动作,用扩展(Extension)用例加以封装,再让它从基用例中声明的扩展点(Extension Point)上进行扩展,从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
- 关联(Association):表示参与者与用例之间的通信,任何一方都可发送或接受消息。
- 元素
- 用例图的画法与步骤
- 确定执行者:一个执行者就是一种作为使用系统角色的代表,比如一个人可能在用例图中扮演多种角色
- 确定系统的范围与边界
- 确定用例:就是执行者所要做的事情,主要存在的问题就是一个用例粒度的掌握.
- 将用例归档:就是分析用例,哪些是主流程用例,哪些是扩展用例,判断用例之间的执行顺序,比如只有执行了用例A,才能执行用例B
- 将用例细化:用例图的完善一个循环渐进的过程
- 用例图给利益相关人与开发者的价值有哪些?
用例图的主要目的是帮助开发团队以一种可视化的方式来理解系统的功能需求, 包括基于基本流程的“角色”之间的关系,以及系统内用例之间的关系。开发者可以明确自身所需开发的系统交互功能模型,利益相关人员可以明确地了解系统的交互过程而不必考虑相关技术。
建模练习题(用例模型)
- 选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
- 请使用用户的视角,描述用户目标或系统提供的服务
- 粒度达到子用例级别,并用 include 和 exclude 关联它们
- 请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例
- 尽可能识别外部系统和服务
定旅馆:
买电影票:
- 然后,回答下列问题:
- 为什么相似系统的用例图是相似的?
相似系统的业务逻辑是相似的,用例的类型基本固定,与子用例的关系也相似,所以用例图也相似。 - 如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术
可以同时向客户推荐旅店所在地的风景名胜,美食,游玩线路推荐等信息;也可以通过客户以往订房记录推荐与之前类似价位和服务的酒店。 - 如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用
使用高亮进行标记 - 请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
- 根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算
- 为什么相似系统的用例图是相似的?
ID | Name | Imp | Est | How to Demo | Notes |
---|---|---|---|---|---|
1 | 查询酒店 | 40 | 15 | 在地图上查询酒店,得到精准地理位置信息 | 使用外部地图的api |
2 | 订购酒店 | 80 | 30 | 选择旅馆,房间,确认订单 | 如果有余力再加入筛选,历史选择等功能 |
3 | 管理订购信息 | 10 | 5 | 管理历史记录,删除订购信息等 | 数据库的设计与使用 |
4 | 支付费用 | 40 | 15 | 选择支付方式 | 支持各种支付,使用外部api |
ID | 用例 | 事物 | 权重 |
---|---|---|---|
1 | 查询酒店 | 2 | 简单 |
2 | 订购酒店 | 3 | 简单 |
3 | 管理订购信息 | 1 | 简单 |
4 | 支付费用 | 3 | 简单 |