系统分析与设计作业四

文章目录

系统分析与设计作业四1、简答题1.用例的概念2.用例和场景的关系？什么是主场景或 happy path？3.用例有哪些形式？4.对于复杂业务，为什么编制完整用例非常难？5.什么是用例图？6.用例图的基本符号与元素？7.用例图的画法与步骤8.用例图给利益相关人与开发者的价值有哪些？ 2、建模练习题（用例模型）

1、简答题

1.用例的概念

用例是软件工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。包含了一系列相关的成功和失败场景的集合，这些场景描述了一个角色和系统的交互，来支持一个目标。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。每个用例都有一个名字和一段简述。用例的详细描述本质上是一些叙述，说明了用户如何使用系统来完成他们认为重要的事情，以及系统做了些什么来满足这些需要。

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

关系：场景是参与者和系统之间一个特定的交互行为和会话，也被称为用例实例。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。用例就是对全部用例场景的抽象，用例场景就是从用例中实例化出来的一组活动主场景或 happy path：每个用例提供了一个主场景和若干个可选场景，主场景/happy path对应于主要的系统交互，通常是“成功”的场景，它是最常用的，典型的、无条件的、理想方式、无错误的系统最基本的成功场景

3.用例有哪些形式？

Brief概要型：通常是一段总结性的文字，主要描述主要的成功场景，便于快速了解主题和范围，可快速创建Casual简便型：通常用非正式的格式描述不同的场景Fully 完整型：详细描述所有步骤和分支情况，有支持的部分，比如前提条件和成功场景的保证

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

复杂的业务涉及到很多场景，且场景与场景之间存在复杂的关联，因此负责业务的场景也很复杂（比如会出现很多分支），编制用例时容易遗漏一些业务和需求，很难全覆盖编制完整用例需要熟悉各种业务场景、流程和建模相关的专业知识，对用例编写者的水平要求较高业务与需求本身就是需要不断迭代来确定的，还有可能会变化，因此项目初期很难编写出完整正式的用例的

5.什么是用例图？

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。通过用例图，人们可以获知系统不同种类的用户和用例。

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

​ 用例图有四个部分：参与者（Actor)，用例（Use Case)，系统边界，关系

参与者（actor）：参与者是与系统交互的人或物。包括开发系统用户，除此之外，与开发的系统有关联的其他系统也算是参与者。在UML图中用一个小人表示，也可以用带«actor»关键字的类矩形表示 用例（Use Case）：用例是有意义的单独工作单元。它向系统外部的人或事提供一个易于观察的高层次行为视图，是参与者可以感受到的系统服务或功能单元。在UML图中用椭圆表示

系统边界：指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境，用例在系统内部，执行者在系统的外部。在UML图中用一个矩形框表示

关系

关联：表示参与者和用例之间的交互。为通信途径，任何一方都可发送或可接收消息。箭头指向消息接收方。在UML中用直线表示

包含：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用用例就是不完整的，通常它假设，任何被包含的用例在基本程序运行时每一次都会被调用。包含关系最典型的应用就是复用。这种情况类似与在过程设计语言中，将程序的某一段算法封装成一个子过程，然后在从主程序中调用这一子过程。在UML中，包含关系用带箭头的虚线段加《includes》表示，箭头指向被包含的用例

扩展：扩展关系是指用例功能的延伸。与包含关系不同的是，扩展用例是可选的，如果缺少扩展用例。不会影响到基用例的完整性。在UML中，扩展关系用带箭头的虚线段加《extends》表示，要注意的是箭头指向基用例

泛化：用例的泛化指的是一个父用例可以被特化形成多个子用例，页就是继承关系。在UML中，泛化关系用空心箭头表示，箭头指向的是父用例

7.用例图的画法与步骤

主要步骤就是确定用例图的三大元素：参与者、用例、关系

识别参与者以及外部系统, 包括:

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

识别用例(服务)

识别用户级别用例(user goal level)

识别子功能级别的用例(sub function level)

特定参与者希望系统提供什么功能

系统是否存储和检索信息，如果是，由哪个参与者触发

当系统改变状态时，是否通知参与者

是否存在影响系统的外部事件

哪个参与者通知系统这些事

通过用例之间的业务关系，建立参与者和用例之间的关联

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

利益相关人: 可以直观看到系统的结果和用户的功能体验, 保证系统按照用户的需求进行设计用例能够根据需要对复杂程度和形式化程序进行增减调节, 即能够响应用户(利益相关人)提出的需求, 而用例图则使得这种调节更加便利, 可以通过修改图形间的关系实现 开发者 用例图是设计者设计过程的结论与参考, 设计者与开发者之间的交流工具, 开发者开发过程的蓝图用例图方便开发者评估工作量，合理规划迭代周期，规划人力资源用例图与用户和系统交互相关，它们使软件开发者在开发之前或当中就能够开始用户接口设计。用例图使得开发者能够更明确地获得需求, 更好地理解需求，确定系统的业务范围，是开发人员和最终用户的很好的沟通桥梁用例图可以指导开发和测试, 同时可以在整个过程中对其他工作流起到指导作用用例图在项目中可复用。用例在每一次迭代中都能进一步演化，用例可以用于捕获需求，成为程序员的开发依据，发展为测试用例，到最后成为用户手册

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

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、订电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

请使用用户的视角，描述用户目标或系统提供的服务粒度达到子用例级别，并用 include 和 exclude 关联它们请用色彩标注出你认为创新（区别于竞争对手的）用例或子用尽可能识别外部系统和服务

酒店预订

电影预订

回答下列问题：

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

相似系统面对的参与者和用例是相似的, 用例之间的关系也是同构的，场景有很多重复的元素，用户的需求都是相似的（如增删查改）。因此同类型的不同系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的

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

由上一题可知，同为订旅馆业务，主用例基本相同，所以创新点多出现在子用例

不同时代：随着技术的进步，可以将最新的一些信息技术加入到用例图中。例如高效快捷的注册登录验证技术（比如微信扫码，QQ账号登陆）、更高效的支付方式（从银行卡支付到微信、支付宝支付等）不同地区：考虑不同地区的审美风格、以及不同地区的政策，宗教，风俗习惯，语言等，比如中文输入，中文语音

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

对于创新的用例，使用区别于常规用例的颜色背景的用例图表示，直观地观察其在系统中的作用。如果创新位于较高的父级，则作用比较大，可能是商业模式的创新和业务的创新；如果是子类或者是被包括的关系，则作用相对较小，可能是技术创新

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

以喵眼电影用例图为例

IDNameImpestHow to demoNotes1注册2010用户信息收集、邮箱验证实现突出注册渠道2登录205登录，然后收到登录成果的反馈注意增强登录成功的反馈3注销205登录，然后注销，然后收到注销的反馈注意增强注销成功的反馈4订单管理9080下订单、取消订单、评价订单、使用客户服务使用分页技术避免大规模的数据库查询5查询选择100100根据旅馆的价格、地点、特色等进行筛选，同时基于数据分析提供喜好推荐使用缓存，防止输入一半的信息丢失6支付5030登录，然后查找电影，然后订一张票，然后付款，在订单中检查刚刚的订单状态是已支付突出交易数额和支付渠道

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

根据用户点方法，对用例分配权重的标准是：

简单用例：1 到 3 个事务，权重=5一般用例：4 到 7 个事务，权重=10复杂用例：多于 7 个事务，权重=15 用例事务计算原因UC权重注册32使用微信/QQ API简单登陆32使用微信/QQ API简单注销11简单查找电影1010复杂订电影票128使用流程框架复杂支付53使用支付api简单