用例建模相关知识总结

目录用例模型用例建模的作用用例建模：用例建模就是通过分析用户的功能性需求，得到用例模型的开发过程用例模型用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述了了系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过

LarryHai6

8791人浏览 · 2021-06-08 09:43:34

LarryHai6 · 2021-06-08 09:43:34 发布

用例模型

用例建模的作用

用例建模：用例建模就是通过分析用户的功能性需求，得到用例模型的开发过程

建立系统用例模型的过程就是对系统进行功能需求分析的过程。用例图的组成

用例模型

用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述了了系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例
用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程
用例是由系统的最终用户或外部环境发起的，用力地发起者成为参与者
每个用例只描述单独的任务，而不能描述多个任务，用例描述的任务必须是符合用户意图的完整的工作内容
用例必须产生一个对用户有意义的结果

用例建模的作用

    首先，用例模型是一种标准的语言，很容易成为开发人员之间交流和沟通的媒介，用例模型可以精确地定义软件需求，出现歧义的可能性很小，这可以保证用户和开发人员对需求理解的一致性
    其次，用例模型可以成为我们评估压法工作量的一个标准，特别是对于迭代式开发言。迭代式开发模型里，通常依据用例模型来划分软件的开发周期：优先级别高的用例会在早期的迭代周期中实现，而优先级别低的用例则被安排在后续的迭代周期中完成。可以通过限制每个迭代周期中的用例个数来保证迭代周期长度的合理性
    再次，用例模型在整个开发过程中都扮演着非常重要的角色，它可以驱动软件的分析和设计逐步细化
    最后，测试过程中使用的测试用例-----特别是那些关注软件功能的测试用例---往往也是根据用例模型来确定的

用例建模：用例建模就是通过分析用户的功能性需求，得到用例模型的开发过程

    确定系统边界
    确定参与者
    找出所有的用例
    确定每个用例的级别
    撰写用例的文字描述
    画出以整个系统为对象的顺序图

案例1

功能结构图

用例图

流程图

数据字典

er图

案例2

案例3

1. 根据订旅馆建模文档

绘制用例图模型（到子用例）

给出 make reservation 用例的活动图

2. 根据课程练习“投递员使用投递箱给收件人快递包裹”的业务场景
场景1： x科技公司发明了投递柜，它们自建了投递柜以及远程控制系统。注册的投递员在推广期免费使用投递柜。由于缺乏资源，仅能使用y移动平台向客户发送短信通知。
场景2：随着产品推广，x公司与各大快递z公司达成协议。x公司在快递柜上添加了二维码扫描装置，z公司的快递员不仅可在快递柜上登陆（由z公司提供认证服务），且可扫描快递单号，投递入柜后自动由z公司发短信给客户。客户取件后，自动发送给z公司投递完成。
场景3： x公司进一步优化服务，开发了微信小程序实现扫码取快递。如果用户关注了该公司公众号，直接通过过公众号推送给用户取件码等信息。不再发送短信。
备注：关于z公司投递员认证过程。一般采用用户登陆z公司，z公司用私钥签名的token（二维码包含公司名，用户ID，有效期等）；x公司扫描该二维码，用对应公钥验证该token。

    分别用多泳道图建模三个场景的业务过程
        场景1：

        场景2：

        场景3：

    根据上述流程，给出快递柜系统最终的用例图模型
        用正常色彩表示第一个业务流程反映的用例
        用绿色背景表述第二个业务场景添加或修改的用例，以及支持 Actor
        用黄色背景表述第三个业务场景添加或修改的用例，以及支持 Actor

UML需求建模图示

需求分析阶段的工作任务

什么是业务用例建模

1.业务需求是从客户角度提出的对系统的要求，一般也称为。初始需求
2.业务用例建模在创建模型的初始阶段，用来勾画系统的大致轮廓。
3.随着对需求的深入理解及与用户不断的沟通交流，进一步对用例进行细化，并根据实际需要，加入一些前期没有被标识出来的用例。

什么是用例图

用例图(Use Case Diagram)是显示一组用例、参与者以及它们之间关系的图。把客户的想法用更加容易理解的图形化样式展现给用户，它描述的是参与者从系统外部来看系统该有的功能。
在软件项目开发中，用例图是业务调研后，最先用来和用户交流讨论的重要的UML图。
也就是说，用例图中描述的是系统该有哪些功能，而不是怎么实现。
在UML中，一个用例模型由若干个用例图描述。

用例图的作用

用例图对开发的意义

用例图是从需求分析报告到软件系统设计的第一步，也是系统整个分析过程中最重要的图，它的改变将影响到其它图，用例建模贯穿整个软件开发的过程。
在这里插入图片描述
大学信息系统的一个用例图

如何建立用例模型

建立系统用例模型的过程就是对系统进行功能需求分析的过程。

用例图的组成

1.参与者（actor），又叫执行者，是指系统外部与系统交互的人或其他系统。

2.用例（use case）是系统所提供的一个功能（或某一特定用法）的描述，是执行者和系统交互的一个完整过程。用例具有响应性、回执性、完整性，分为业务用例和系统用例。

UML需求建模过程

用例建模技术

确定系统的范围和边界

1.系统的范围是指系统问题域的目标、任务、规模和系统提供的功能和服务。
2.系统的边界就是系统内外的分界线，用一个实线方框表示。
3.系统开发的主要任务是对系统边界内的元素进行分析、设计和实现，系统边界外部的事物统称为执行者。

识别参与者

1.参与者：又称执行者。是在系统之外，透过系统边界与系统进行有意义交互的任何事物。
2.参与者可以是人、另外一个系统、硬件设备、其它用例等系统外部的实体。有主要参与者、协助参与者、幕后参与者之分。
3.参与者是用来执行用例的。
4.识别参与者的方法：
~谁使用系统的主要功能
~谁改变系统的数据
~谁从系统获取信息
~谁需要系统的支持以完成日常工作任务
~谁负责日常维护、管理并保证系统正常运行
~系统需要应付（处理）哪些硬件设备
~系统需要和哪些外部系统交互
~谁（或什么）对系统运行产生的结果（值）感兴趣
时间、气温等内部外部条件
5.识别参与者

识别用例

1.什么是用例
（1）在UML中，用例被定义成系统执行的一个动作（功能单元）。只显示系统外部的功能表现，不考虑系统内部的实现过程。
（2）用户与计算机之间的典型交互。
（3）惟一的名字。
（4）表示方法
参与者和用例分别描述了**“谁来做？”和“做什么？”**这两个问题。

2.识别用例
~参与者希望系统提供什么功能；
~系统是否存储和检索信息，如读取、创建、删除、修改、存储等；如果是，这个行为由哪个参与者触发；
~当系统改变状态时，是否通知参与者；
~是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。
~系统需要哪些输入输出？谁从系统获取信息？
一般是抽取业务调研报告中的动词或动词词组。

需要注意的是：用例必须是由某一个参与者触发而产生的活动，如果存在跟参与者不进行交互的用例，则可以考虑并入其它用例，或者检查是否缺少参与者。反之，每个参与者也必须至少涉及一个用例。

3.识别用例的方法
~在具体的需求分析过程中，先从用户角度识别出系统的大致功能（大用例），就像一个黑盒一样，不涉及其内部的任何信息。
~如果该用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部结构，找出黑盒内部的参与者和用例（小用例）。
~就这样不断的打开黑盒，分析黑盒，再打开新的黑盒，直到整个系统可以被清晰的了解为止。

识别用例间的关系

1.用例图中的关系
用例图中有以下几种关系，应用这些关系的目的是为了从系统中抽取出公共行为和其变体。

（1）参与者与用例之间的关系

关联关系：表示参与者与用例之间的通信。

（2）参与者之间关系

泛化关系：
参与者之间可以有共同的属性和行为，因此可使用泛化关系来描述多个参与者之间的公共行为。它们之间有特殊和一般的关系。

（3）用例之间关系

a.包含关系（Include）
指一个用例可以包含其他用例具有的行为，并把它所包含的用例行为作为自身用例的一部分。其实就是基础用例中一个不得不执行的用例部分。

详解：包含(include)关系

    包含关系中的基本用例(base use case) 的执行依赖于包含用例的执行，如果没有包含用例，则基本用例的执行是不完整的。
    包含用例是可重用的用例──多个用例的公共用例（公共行为）。
    该用例本身具有独立的业务逻辑，同时也可能被其它用例所引用，或者这个用例需要独立封装。
    要使用包含关系，必须在子用例中说明基础用例行为包含的详细位置，类似于功能调用。


    b. 扩展关系（Extend）
    一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。

详解：扩展(extend)关系

    扩展关系表示一个业务用例的执行有时需要对用例的功能进行扩展。将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。
    基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。基础用例没有扩展用例也是完整的。
    扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。
    4.值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。

扩展用例是以隐含形式插入基用例的，它并不在基本用例中显示。
在以下情况下，可使用扩展用例：
1.表明用例的某一部分是可选的系统行为（这样就可以将模型中的可选行为和必选行为分开）。
2.表明只在特定条件下才执行的分支流。

c. 泛化关系（Generalization）
一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。

详解：泛化(generalization)关系