系统分析与设计作业(四)
课程名称系统分析与设计任课老师潘茂林老师
学号16340015专业（方向）软件工程(计应)姓名陈彬彬Email944131226@qq.com开始日期2019/05/20完成日期2019/05/22
文章目录
系统分析与设计作业(四)一.简答题1. 用例的概念2. 用例和场景的关系？什么是主场景或 happy path？3. 用例有哪些形式？4. 对于复杂业务，为什么编制完整用例非常难？5. 什么是用例图？6. 用例图的基本符号与元素？7. 用例图的画法与步骤8. 用例图给利益相关人与开发者的价值有哪些？
二. 建模练习题0. 建模练习1. 为什么相似系统的用例图是相似的？2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表5. 根据任务4，参考 [使用用例点估算软件成本](https://www.ibm.com/developerworks/cn/rational/edge/09/mar09/collaris_dekker/index.html)，给出项目用例点的估算
一.简答题
1. 用例的概念
用例，或使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。用例一般是由软件开发者和最终用户共同创作的。
2. 用例和场景的关系？什么是主场景或 happy path？
场景，或用例场景指用户实际应用场景的过程，通过各种动作组合起来，是实例化的用例，从一个用例可以实例化出多个用例场景。 简单讲，用例就是对全部用例场景的抽象，用例场景就是从用例中实例化出来的一组活动。
主场景对应于主要系统交互，通常是“成功”场景，最常用、最直接地实现用户目标的场景。
Happy path是一个没有异常或错误条件的默认场景。它让执行成果的能继续运行到最后，从而生成积极的响应。
3. 用例有哪些形式？
摘要：简洁的一段式概要，通常用于主场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间编写。非正式：非正式的段落格式，用几个段落覆盖不同的场景。详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。
4. 对于复杂业务，为什么编制完整用例非常难？
复杂业务编制完整用例非常难的原因有：
由于业务复杂、需求多且杂，用例下的场景会非常多且复杂。随着时间更迭，开发过程中需求会发生变化，用例场景不仅会越来越多，并且也会相应产生变化。很难完整地考虑到所有的场景情况，并且有些业务难以使用用例抽象描述出来。用例间的关系在多个用例之间是很复杂的，有些用例关系难以理清。
5. 什么是用例图？
用例图是指由参与者(Actor)、用例(Use Case)，边界以及它们之间的关系构成的用于描述系统功能的视图。用例图(User Case)是外部用户(被称为参与者)所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
6. 用例图的基本符号与元素？
参与者(Actor)：一个小人，表示一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
用例(Use Case)：一个圆框，表示对系统提供的功能、服务的一种用例描述。
边界：一个方框，表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。
用例间的关系
包含关系：虚线箭头加上《include》标志，箭头方向指向被包含者。表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。
拓展、延伸关系：虚线箭头加上《extends》，箭头方向指向基础用例。表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。
泛化关系：实线空心三角箭头，箭头方向指向父用例。表示一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
关联关系：一条直实线。表示参与者与用例之间的关系。
7. 用例图的画法与步骤
确定系统边界：
使用系统方框表示一个用例系统正确命名系统或子系统 确定参与者：
确定使用该系统主要功能的参与者确定需要该系统的支持以完成其工作的参与者确定维护、管理该系统，保持该系统处于工作状态的参与者确定对本系统结果感兴趣，与本系统有关的人或系统等。 识别用例：
特定参与者希望系统提供什么功能，由哪个参与者触发当系统改变状态时系统功能的变化，是否通知参与者是否存在影响系统的外部事件 确定用例之间的关系：
思考用例之间的业务关系，如包含关系、扩展关系和泛化关系正确使用关系符号表示 确定关联的外部系统
确定外部系统与用例系统的关系判断外部系统对用例系统的影响，用直线连接影响部分。
8. 用例图给利益相关人与开发者的价值有哪些？
对于利益相关人：
可以直观看清系统的结果以及用户的功能体验，提供了系统使用和行为的摘要视图，提供用户使用系统流程的说明。能够根据业务场景的复杂程度和形式化程序进行增减调节，能够通过用例图进行系统功能的增减以及修改，满足相应利益相关人提出的需求。使得系统能够注重其参与者的用户体验。 对于开发者：
明确系统的业务范围、服务对象、外部系统与设备。可以帮助将大型系统划分为多个模块。每个模块本身可以由用例图表示。帮助识别技术风险，提前实施关键技术原型公关与学习。易于评估项目工作量，合理规划迭代周期，规划人力需要。
二. 建模练习题
0. 建模练习
选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
请使用用户的视角，描述用户目标或系统提供的服务粒度达到子用例级别，并用 include 和 exclude 关联它们请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例尽可能识别外部系统和服务
携程酒店 Ctrip
美团外卖 Meituan
1. 为什么相似系统的用例图是相似的？
因为系统相似，用例面对的参与者也是相似的人群，用例系统的需求是相似的，核心功能也是相似的，连同用例之间的关系也是相似的，因此设计绘制的用例图也是相似的。
2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
不同时代、不同地区用户的需求在细节上的要求是不一样的，Asg_RH用例图只设计了用户主要满足的基本需求，而没有在这部分细节上进行创新和设计。例如下面两图所示，新时代用户的需求不仅仅体现在基本的入住地点、入住时间等信息，还包括了预定酒店级别、酒店+景点结合、酒店风格(如民宿)、酒店价格(特价or区间)、酒店附近交通等信息的搜索选择，有着不同地区、时代体现出来的更丰富的需求，可能会有较大的差别，可以在用例图中突出这些方面的重要性。
Asg_RH:
Ctrip:
3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
可以通过设置用例的背景颜色显示出创新思路对其他部分的影响，可以根据用例图的用户级别来判断其作用可以根据用例图中的位置来定位它在系统中的作用，定义越靠近参与者的为创新思路作用越大的。
4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
以携程酒店用例系统为例：
IDNameimpESTHow to demoNotes
1find hotel30101.输入目的地、入住时间等信息根据GPS获取匹配附近酒店列表2.输入酒店名字，精确定位匹配同名酒店列表智能排序酒店列表，用户可自行选择酒店2make reservation152选择入住房间类型、入住人数、入住时间等信息，核对房间价格和时间等信息后确认订房账单确认机制避免误选3login205使用第三方微信账号登陆携程一次登陆页面记忆保存，对接第三方登陆接口4pay258使用第三方支付微信支付支付账单对接第三方支付接口5manage basket105管理订房账单，可选退订改时间等管理后台核实操作信息，不允许用户频繁修改操作
5. 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算
简单用例：1 到 3 个事务，权重=5一般用例：4 到 6 个事务，权重=10复杂用例：多于 7 个事务，权重=15
用例事务计算原因uC比重
find hotel89智能排序推荐框架复杂make reservation64一般login22简单pay44一般manage basket62一般
