1   参与者

例 3.1  在一个银行业务系统中，可能会有以下参与者

客户 ：在银行业务系统中办理了账户的居民。他们通过银行业务系统进行金融交易

柜台营业人员 ：负责银行业务系统具体操作事务的办事人员。他们为客户办理存款、取款等金融交易

Mail 系统 ：负责银行业务系统向个人发送电子邮件的软件系统

知识点----参与者之间的关系

参与者之间的关系：

1.1泛化关系

泛化关系 ：一般参与者与特殊参与者之间的关系

 

在一个大学图书管理系统中，可能的需求如下：

        读者在大学图书管理系统中办理了借书证。读者分学生和教师。读者借还书籍要通过图书管理员之手来完成。系统管理员负责大学图书管理系统的借书证维护和图书数据维护等操作。读者可以自己在终端机上直接进行借还书，也可以通过图书管理员来完成。

 

参与者之间的泛化关系的作用

例 3  在一个网上购物系统中，一定会遇到用户权限问题。普通用户只能浏览网站上陈列的商品，而注册会员除了普通用户具有的操作之外，还有权限进行在线购物

 

参与者之间的泛化关系的作用

共同点 ：普通用户操作的所有功能，注册会员也能操作

不同点 ：注册会员还能操作普通用户不能操作的功能

结论 ：普通用户作为一般参与者，注册会员作为特殊参与者

 

参与者之间的泛化关系的作用

有效地减少了参与者与用例之间的关联关系的个数，简化了用例模型

 

 

1.2关联关系

关联关系：起通信的作用，即描述了：一个参与者完成系统的一项功能

 

2   用例

2.1   用例的概念

§ 在一个大学图书管理系统中，可能的需求如下：

        读者在大学图书管理系统中可以查找图书。读者分学生和教师。读者借还书籍要通过图书管理员之手来完成。为了方便工作，图书管理员也可以查找图书。系统管理员负责大学图书管理系统的借书证维护和图书数据维护等操作。

用例图：

2.2   用例之间的关系

用例的特征

• 站在系统外部，看到的系统功能
• 用户提出的一些可见的功能需求
• 总是被参与者启动
• 必须是一个完整的描述
• 可以进行独立的功能检测
• 是对系统行为的动态描述
• 用例的设置代表了软件系统的功能划分
• 用例的实例是系统的一次具体执行过程
• 动态执行过程可以用UML的交互作用来说明

提问：试分析下述系统中，有哪些用例？

例3.6超市购买商品系统的部分需求陈述如下：

顾客带着所要购买的商品到达超市的一个销售点终端（终端设在门口附近），销售点终端负责接收数据、显示数据和打印购物单。

营业员通过销售点终端录入每项商品的通用产品代码，如果出现多个同类商品，营业员还要录入该商品的数量。系统确定商品的价格，并将商品代码、数量信息加入到正在运行的系统；系统显示当前商品的描述信息和价格。

 

找出上例中的参与者与用例

找参与者，主要找系统外的客观实体：

顾客，营业员，销售点终端。

找用例，主要找参与者看到的功能：

接收数据（接收顾客购买的商品的信息），

显示数据（显示顾客购买的商品的信息），

打印购物单（打印顾客购买的商品的信息），

商品信息维护（确定每件商品的代码及单价）

用例之间的关系：泛化关系，包含关系，扩展关系 

泛化关系 ： 特殊用例 继承、覆盖、增加 一般用例 的行为

例 3.7  在一个在线股票经纪人系统中，下图给出了交易行为中部分交易类型之间的关系

泛化关系：特殊用例继承、覆盖、增加一般用例的行为

例 3.8  在一个学校信息管理系统中，下图给出了查找人行为中部分特殊身份查找之间的关系

包含关系 ： 基本用例 的行为必然执行 包含用例 的行为

例 3.9  在一个网上购物系统中，当注册会员在线购物时，网上购物系统需要对顾客的信用进行检查，检查输入的信用卡号是否有效

扩展关系 ： 基本用例 的行为条件执行 扩展用例 的行为

例 3.10  在一个图书借阅系统中，当读者还书时，如果借书时间超期，则需要交纳一定的滞纳金，作为罚款

 

共同点：包含用例和扩展用例都补充了基本用例的行为

不同点：包含用例必然被执行，扩展用例条件被执行

性质：因为基本用例的行为被包含用例或扩展用例的行为延伸了，所以基本用例的行为依赖于包含用例或扩展用例的行为。所以，包含关系和扩展关系都是依赖关系的特例

在一个网上购物系统中，当注册会员浏览商品时，他可能临时决定在线购物。当他决定在线购买商品后，就必须下订单。此外，他也可以直接在线购物。

 

在一个停车场信息系统中，可能的需求如下：

1、汽车到达入口处，驾驶员停下车，在取卡机上按下取卡按钮，获得停车卡。

2、取出停车卡后，系统启动栏杆抬起。汽车通过后，栏杆放下。

3、驾驶员在缴费机上缴费后，获得出场卡。

4、汽车到达出口处，驾驶员停下车，插入出场卡。若出场卡有效，则栏杆抬起；否则不抬起，并发出警报。

 

2.3   用例之间的包含关系和扩展关系的区别

在扩展关系中，基本用例是可以独立存在的用例。

在包含关系中，基本用例一定会执行包含用例部分。

如果需要重复处理两个或多个用例时，可以考虑使用包含关系，实现一个基本用例对另一个用例的引用。

当处理正常行为的变形而且只是偶尔描述时，可以考虑只用泛化关系。

当处理正常行为的变形而且希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。

  

在一个网上购物系统中，当注册会员浏览网站时，他可能临时决定购买商品。当他决定购买商品后，就必须将商品放进购物车，然后下订单。 

如果网上购物系统的需求是这样的：注册会员既可以在线购物，又可以浏览商品后决定在线购物。则 

相同点：它们都是基本用例行为的一部分。换句话说，最初的基本用例中的部分行为被提取出来，单独形成了一个用例。

不同点：在基本用例的每一次执行时，包含用例都一定会被执行，而扩展用例只是偶尔被执行。

关系是模型元素之间具体的语义联系。关系可以分为关联、泛化、依赖、实现等几种。

泛化关系表示的是两个类元之间的关系。

依赖关系表示的是两个元素或元素集之间的一种关系。

3   用例描述

用例描述

是一个关于参与者与系统如何交互的规范说明

没有描述 的用例就像是一本书的 目录 ，人们只知道该目录标题，但并不知道该目录的具体内容是什么

不同的问题域 ，相同名字的用例可能完成不同的操作过程

银行“取款”用例的用例描述

基本流程

1 、要求用户重新输入密码进行验证

2 、密码正确后，用户输入取款金额

3 、判断该储户的账户余额是否足额

4 、若足额，则输出等额的人民币现金。修改账户余额

5 、若不足额，则本次取款操作失败

 

4   用例建模

用例模型主要应用在需求分析时使用。

用例建模的基本步骤：

（1）找出系统外部的参与者和外部系统，确定系统的边界和范围。

（2）确定每一个参与者所期望的系统行为，即参与者对系统的基本业务需求。

（3）把这些系统行为作为基本用例。

（4）区分用例的优先次序。

（5）细化每个用例。使用泛化、包含、扩展等关系处理系统行为的公共或变更部分。

（6）编写每个用例的用例描述。

（7）绘制用例图。

（8）编写项目词汇表。

确定系统的边界：

系统边界是指系统与系统之间的界限

系统边界定义了由谁或什么（即参与者）来使用系统，系统能够为参与者提供什么特定服务

确定系统边界就是要定义好什么是系统的组成部分（边界内）和什么是系统的外部（边界外）

在用例图中，系统边界用实线方框图形符号表示

用例绘制在方框里面（即边界里面）

参与者绘制在方框外面（即边界外面）

 

5   用例建模中常见的问题分析

用例的设计原则

1、需求和用例的关系

2、需求应该有层次地组织起来

3、不要从用例直接推论出设计

用例模型的复杂度

1、用例包

2、用例的粒度

3、用例图

用例模型的检查

1、功能需求的完备性

2、模型是否易于理解

3、是否存在不一致性

4、避免二义性语义