用例建模-绘制用例图

1、简答题

用例的概念

用例（use case）是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

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

用例是场景的集合，每个用例提供了一个或多个场景。

主场景（happy path）：对应于主系统交互，通常是成功场景；直接地实现用户目标的场景

用例有哪些形式？

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

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

对于复杂的业务来说，需求多，会导致拓展部分也多，用例中很难全覆盖。

同时由于复杂业务的场景较多且复杂，完整用例很难实现步骤和变化都写的详细

什么是用例图？

用例图是指由参与者（actor）、用例（use case），边界以及他们之间的关系构成的用于描述系统功能的视图。用例图（use case）是外部用户（被称为参与者）所能观察到的系统能能的模型图。用例图是系统的蓝图，它呈现了一些参与者、一些用例以及他们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

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

参与者(Actor)：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

用例（Use Case)：是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

用例图的画法与步骤

对语境建模 识别系统外部的参与者。将类似参与者组织成泛化的结构层次。在需要加深理解的地方，为每个参与者提供一个构造型。将参与者放入到用例图中，并说明参与者与用例之间的通信路径。 对需求建模 识别系统的外部参与者来建立系统的语境考虑每一个参与者期望的行为或需要系统提供的行为。把这些公共的行为命名为用例。确定提供者用例和扩展用例。对这些用例，参与者和它们之间的关系建模。用注释修饰用例

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

对于利益相关人 用例强调了用户的目标和观点，使得用户能够更多地参与到系统的设计当中去，保证系统按照用户的需求进行设计。而用例图则将用例图形化、具象化了，使得整个系统中用例、参与者之间的关系更加清晰地表达出来。用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。 对于开发者 用例图使得开发者能够更明确地获得需求，更好地理解需求。用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

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

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求： 请使用用户的视角，描述用户目标或系统提供的服务粒度达到子用例级别，并用 include 和 exclude 关联它们请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例尽可能识别外部系统和服务

然后，回答下列问题：

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

相似系统的用例图的参与者是基本相同的相似的系统由很多功能、服务是相同的，因此会出现相似甚至相同的用例

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

针对不同时代，我们应该从时代当前新兴发展的技术出发，观察是否能够应用到我们已有用例图的用例中针对不同地区，我们可以参考不同地区用例图与当地风俗习惯的结合，从而进行有针对性的服务

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

根据用例图中创新业务和技术的位置，如果是直接于actor相连接，则是比较重要的创新点，甚至为一大板块；如果是子用例的拓展用例，则是具有一定局限性的创新点

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

IDNameImpEstHow do demoNotes1搜索旅店8030在输入栏输入目的地、城市或者景点，或者在地图上直接选择相应位置的淋巴管根据旅馆的历史成交以及用户的评价进行排序推荐2预订房源6020选择居住的人数以及居住的时间居住人数有增减人数的选择3支付10020选择多种支付方式进行支付注意支付接口的信息安全4分享故事6050用户可以发帖分享自己的故事，可以浏览评价他人的故事注意编辑界面的UI问题 ID：为一个唯一标识，在其他工作或者文档中想引用故事就使用这个ID来引用Name：2到10个字，通过简单的描述来说明故事重要性(Imp)：这个优先级决定了sprint选择的故事，优先级越高的越早实现初始估算(Est)： 这个由Team来根据故事描述内容来估算，产品负责人讲解完故事后，Team对不清楚的进行询问，大概了解后进行粗略估算。How do demo：从用户视角，从操作层面进行讲解这个故事如何通过软件来演示，也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写“如何演示”。Notes：相关信息、解释说明和对其他资料的引用等，一般都非常简短

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

用例业务计算原因UC比重搜索旅店32简单预订房源64平均支付11简单分享故事107复杂