用例建模

UML需求建模图示

需求分析阶段的工作任务

什么是业务用例建模

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

什么是用例图

1.用例图(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)关系

1. 包含关系中的基本用例(base use case) 的执行依赖于包含用例的执行，如果没有包含用例，则基本用例的执行是不完整的。
2. 包含用例是可重用的用例──多个用例的公共用例（公共行为）。
3. 该用例本身具有独立的业务逻辑，同时也可能被其它用例所引用，或者这个用例需要独立封装。
4. 要使用包含关系，必须在子用例中说明基础用例行为包含的详细位置，类似于功能调用。
   
   
   b. 扩展关系（Extend）
   一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。
   

详解：扩展(extend)关系

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

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


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

详解：泛化(generalization)关系

~当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。
~泛化关系是对父用例具有一定的强依赖关系，子用例表示父用例的特殊形式，可以继承父用例的行为和属性，还可以添加自己的行为和属性。

用例阐述

审核用例模型