SWSAD Homework6

1 简答题

1.1 用例的概念

用例 (use case) 是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。

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

场景 (scenario) ：场景是参与者和系统之间的一些列特定的活动和交互，也称为用例实例 (use case instance) 。
关系：场景是使用系统的一个特定情节或用例的一条执行路径。用例是一组相关的成功和失败场景的集合。
主场景：描述了满足涉众关注点的典型成功路径。要注意的是，它通常不包括任何条件和分支。
happy path：没有异常或错误条件的默认场景，即用户和系统可以很顺利、无误、符合预期地进行交互。

1.3 用例有哪些形式？

• 摘要：简洁的一段式概要，通常应用于主场景的描述。一般在早期需求分析过程中为快速了解主题和范围而使用。
• 非正式——非正式的的段落格式：用几个段落的文字覆盖不同场景。
• 详述：详细编写所有的步骤和各种变化，同时具有补充部分，如前置条件和成功保证。

1.4 对于复杂业务，为什么编制完整用例非常难？

复杂业务将会涉及到诸多的复杂场景，每个场景之间可能还有依赖关系，所以编写完整准确的用例将会非常难。复杂业务的场景多且复杂，并且其间关系复杂，再加上业务与需求本身就是需要不断迭代来确定的，编制用例时难以涵盖全部场景；对于单个场景，也难以考虑到所有的用户-系统的交互情况，所以复杂业务是很难编写出完整正式的用例的。

1.5 什么是用例图？

用例图用以描述用例名称和参与者及其之间的关系。用例图是一种优秀的系统语境图，能够展示系统边界与边界之外的事物以及系统如何被使用。

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

• 参与者：参与者是与系统交互的人或物。首先当然包括开发系统用户，除此之外，与开发的系统有关联的其他系统也算是参与者。符号是一个小人。
• 用例：用例是参与者可以感受到的系统服务或功能单元。我理解的就是用户可以使用开发的项目去做的任何事情。任何用例都不能在缺少参与者的情况下独立存在，同样，任何参与者也必须要有与之关联的用例。符号是一个圆框。
• 系统边界：指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。符号是一个方框。
• 关联关系：表示参与者和用例之间的交互。为通信途径，任何一方都可发送或可接收消息。符号是一个虚线箭头：---->，箭头指向消息接收方。
• 包含关系：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就是不完整的。包含关系最典型的应用就是复用。这种情况类似与在过程设计语言中，将程序的某一段算法封装成一个子过程，然后在从主程序中调用这一子过程。符号是一个虚线箭头，有<>标识。箭头方向指向被包含者。
• 扩展关系：扩展关系是指用例功能的延伸。与包含关系不同的是，扩展用例是可选的，如果缺少扩展用例。不会影响到基用例的完整性。符号是一个虚线箭头，有<>标识，箭头方向指向被继承者。
• 泛化关系：用例的泛化指的是一个父用例可以被特化形成多个子用例，用我们熟悉的语言来说就是继承关系。符号是一个实线箭头，箭头是个小三角，指向父用例。

1.7 用例图的画法与步骤

1. 确定参与者

   在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。

   • 谁将使用该系统的主要功能。
   • 谁将需要该系统的支持以完成其工作。
   • 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
   • 系统需要处理哪些硬件设备。
   • 与该系统那个交互的是什么系统。
   • 谁或什么系统对本系统产生的结果感兴趣。

   在对参与者建模的过程中，开发人员必须要牢记以下几点。

   • 参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。
   • 参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。
   • 参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。
   • 每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。
   • 每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。
   • 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。
   • 和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。

   参与者之间的关系：
   因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色 ，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。

2. 识别用例

   用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。

   识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。

   在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。

   • 特定参与者希望系统提供什么功能。
   • 系统是否存储和检索信息，如果是，由哪个参与者触发。
   • 当系统改变状态时，是否通知参与者。
   • 是否存在影响系统的外部事件。
   • 哪个参与者通知系统这些事件。

3. 确定用例间的关系

   用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。

   • 关联关系（Association）

     • 关联关系描述参与者与用例之间的关系，它是用于表示类的挂系的关联元类的实例。在UML中，关联关系用箭头来表示。
     • 关联关系表示参与者与用例之间的通信。不同的参与者可以访问相同的用例，一般说来它们和该用例的交互是不一样的，如果一样的话，说明它们的角色可能是相同的。如果两中交互的目的也相同，说明它们的角色是相同的，就可以将它们合并。

   • 包含关系（Include）

     • 虽然每个用例的实例都是独立的，但是一个用例可以用其它的更简单的用例来描述。这有点像通过继承父类并增加附加描述来定义一个类。一个用例可以简单地包含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在这种情况下，新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。在UML中，包含关系表示为虚线箭头交<<include>>字样，箭头指向被包含的用例。

     • 包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。

     • 包含关系使一个用例的功能可以在另一个用例中使用，如下所述。

       1. 如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。
       2. 一个用例的功能太多时，可以用包含关系建模两个小用例。

     • 要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。

   • 扩展关系（Extend）

     • 一个用例也可以被定义为基础用例的增量扩展，这被称作扩展关系，扩展关系是把新的行为插入到已有的用例中的方法。同一个基础用例的几个扩展用例可以在一起应用。基础用例的扩展增加了原有的语义，此时基础用例而不是扩展用例被作为例子使用。在UML中，扩展关系表示为虚线箭头加<>字样，箭头指向被扩展展的用例。
     • 基础用例提供了一组扩展点，在这些新的扩展点中可以添加新的行为，而扩展用例提供了一组插入片片段，这些片段能够被插入到基础用例的扩展点上。基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。一个用例可能有多个扩展点，每个扩展点可以出现多次。但是一般情况下，基础用例的执行不会涉及到扩展用例，只有特定的条件发生，扩展用例才被执行。扩展关系为处理异常或构建灵活的系统框架提供了一种有效的方法。

   • 泛化关系（Generalization）

     • 一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。
     • 在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。

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

对于利益相关人：

• 可以直观看到系统的结果和用户的功能体验, 保证系统按照用户的需求进行设计。
• 用例能够根据需要对复杂程度和形式化程序进行增减调节, 即能够响应用户(利益相关人)提出的需求, 而用例图则使得这种调节更加便利, 可以通过修改图形间的关系实现。

对于开发者：

• 用例图是设计者设计过程的结论与参考, 设计者与开发者之间的交流工具, 开发者开发过程的蓝图。
• 用例图使得开发者能够更明确地获得需求, 更好地理解需求。
• 用例图可以指导开发和测试, 同时可以在整个过程中对其他工作流起到指导作用。

2 建模练习题（用例模型）

• 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
  • 请使用用户的视角，描述用户目标或系统提供的服务
  • 粒度达到子用例级别，并用 include 和 exclude 关联它们
  • 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
  • 尽可能识别外部系统和服务
• 然后，回答下列问题：
  1. 为什么相似系统的用例图是相似的？
  2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
  3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
  4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
  5. 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算

携程定旅馆用例图：

美团订电影票用例图：

然后，回答下列问题：

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

相似系统的参与者、用例基本相同，主要业务逻辑基本相同。因此相似系统的用例图差别不大。

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

GPS系统在移动APP中的广泛应用，以及推荐算法的进步，使得基于用户位置和偏好的推荐系统成为可能。
评论系统可以指导用户更加精准的选择旅馆，相比于 Asg_RH 是一个进步。

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

在用例图中使用不同颜色标记创新思路，使得开发者很容易定位到产品创新。

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

ID	Name	Imp	Est	How
1	搜索旅馆	30	20	根据预定时间、退房时间、预定人数、星级、关键字等信息搜索匹配的酒店，显示相应的酒店列表。
2	选择旅馆	60	30	用户根据酒店列表选择酒店、房间等信息。
3	确认订单	40	20	确认所选订单，使用支付平台进行支付。
4	用户评价	30	10	订单完成后可以对旅馆进行评价。

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

用例	事务	计算	UC权重
搜索旅馆	4	2	简单
选择旅馆	5	3	一般
确认订单	1	1	简单
用户评价	2	1	简单