uml基础-用例图

目录

一.相关概念

1.基本元素：

2.用例：

3.参与者：

4.关系：

5.系统边界：

6.图形：

7.使用：

二、建立用例图

1）找出系统中的参与者和用例

2）区分用例优先次序

3）构建用例图模型

一个小例子-图书馆管理系统

---

一.相关概念

1.基本元素：

用例，参与者，它们之间的关系，系统边界

通过分析上面几个元素可知，通过用例图，我们可以知道谁是系统相关的用户以及他们需要系统提供什么功能

2.用例：

描述系统功能（可以设身处地想一下你用这个系统时想让它干什么）

注意用例在功能上是完整的，它从参与者接收输入，又将产生结果输出给参与者（即用例由参与者执行，然后结果也要反馈给参与者）

用例的名字一般是一个动宾结构（如：新增图书）

用例描述：一般没有硬性规定的格式，一般包括用例编号，用例概述，前置条件，基本事件流，其他事件流，异常事件流，后置条件

事件流要写完整，包括参与者执行了什么操作，（基于这个操作）系统给出了什么反馈

前置条件就是用户只有完成了这个条件，才能进行基本事件流操作（如：管理员打开图书管理界面）

后置条件就是执行完该用例将执行什么动作

3.参与者：

与系统进行交互的外部实体（不是特指人，可以是其他设备、系统等）

也不代表人本身，是一个扮演的角色（就像把影视剧看作一个系统，演员a扮演了狼人这个角色，她同时又扮演了吸血鬼，那在这个系统中，她就不叫演员a而是狼人和吸血鬼）

4.关系：

关联：表示参与者与用例之间的关系，就是参与者用系统的什么功能（如：管理员新增图书）

用例之间的关系：

包含：基本用例重用包含用例中的步骤（如新增图书与查询图书，理解一下就是在我们现实生活中你要是想新增图书是不是得先查一下然后再增）

            基本用例可能是也可能不是一个完整的用例，执行基本用例一定会执行包含用例

             重复处理两个或多个用例时使用

 扩展：基本用例是一个完整用例，不需子用例的参加也能完成一个完整的任务，只有当基本用例中的扩展点被激活时，子用例才会被执行（如还书和交罚款用例，只有满足交罚款的条件时才需要交罚款）

              扩展用例几种情况：用例的一部分是可选的（将可选与必选分开）

                                           只在特定条件下才执行的分支

                                           一组行为，插入的行为和顺序取决于执行基本用例时与主角进行的交互

               基本用例一定是完整用例，执行基本用例不一定会执行拓展用例

                对一个正常行为的变形采用多种控制方式

泛化：指一般与特殊之间的关系（如查找图书与精确查找、模糊查找用例，精确和模糊都是查找的一种方式，即是它的特殊形式）

             对一个正常行为的变形只是偶尔描述

分组：用例很多需要组织起来的时候用包来进行整理（包就像我们通常熟知的文件夹）

            两种情况：一个系统包含多个子系统

                                与用户会谈，一个需求用一个用例单独表达，可以用包将需求进行分类

5.系统边界：

边界界定的系统就像一个黑盒子，用户只关心系统有什么功能，而不需知道功能具体是怎么实现的

用例是系统所能提供的功能，所以属于系统中放在边界内，而用户不属于系统只是使用该系统的功能放在边界外

6.图形：

用例在uml中是一个椭圆形

关联：实线箭头，参与者指向用例（可以理解为参与者使用用例）

包含：虚线箭头上标《include》，基本用例指向包含用例（可以理解为执行基本用例需要用到包含用例）

扩展：虚线箭头上标《extend》，扩展用例指向基本用例（就像打游戏中触发了隐藏关卡，隐藏关卡通关后你还是在本关吧）

泛化：实线空心三角形，特殊指向一般（子类指向父类）

7.使用：

一般在需求分析时使用，用例就是用户的需求

理论上可以把一个系统的所有用例都画出来，但是一般没必要，画复杂的重要的即可

并且用例不是系统的全部需求，只是功能性方面的

二、建立用例图

1）找出系统中的参与者和用例

      找出参与者可以思考以下几个问题：

                    谁将使用系统的主要功能

                    谁需要系统的支持来完成日常工作任务

                    谁负责维护、管理并保持系统正常运行

                    系统需要处理哪些硬设备

                    系统需要和哪些外部系统交互

                    系统运行所产生的结果谁比较感兴趣

      找出用例可以思考以下几个问题：

                    每个角色执行的操作有什么

                    什么角色将要创建、存储、改变、删除或读取系统中的信息

                    什么用例会创建、存储、改变、删除或读取这个信息

                    角色需要通知系统外部的突然变化吗

                    系统需要通知角色正在发生的事情吗

                    什么用例将支持和维护系统

2）区分用例优先次序

      某些用例需在其他用例之前完成，因为它们之间相互依赖

3）构建用例图模型

       将找好的用例和角色放入并用关系相连接

总结下来就是，首先找出使用该系统的用户，然后思考该用户需要进行哪些操作（找出用例）

一个小例子-图书馆管理系统

1）找参与者

                    谁将使用系统的主要功能                       ：图书管理员、读者

                    谁需要系统的支持来完成日常工作任务：图书管理员

                    谁负责维护、管理并保持系统正常运行：图书管理员

                    系统需要处理哪些硬设备                        ：无

                    系统需要和哪些外部系统交互                 ：无

                    系统运行所产生的结果谁比较感兴趣      ：图书管理员、读者

      2）找用例

                    每个角色执行的操作有什么  （这个地方不唯一，根据用户需求，可能有不同的操作）                                 

                        图书管理员：增加、删除、修改图书基本信息

                                                增加、删除、修改读者信息

                                                查询读者、图书基本信息

                                                借书、还书图书记录的管理

                          读者：查询、修改个人信息

                                       查询图书信息、借阅信息

3）基于以上需求，可以建立用例如下：（用例的多少要合理，如果太多，可以考虑合并）

       新增图书、删除图书、查询图书、修改图书信息    ——》图书管理

       新增读者、删除读者、修改读者、查询读者信息         ——》读者管理     

       借书、还书、借阅信息     ——》借阅管理

4）绘制用例图如下：

      在需求分析中我们可以知道，读者和管理员都能进行的操作有查询图书、查询读者信息、查询借阅信息其他都是管理员可以进行的操作

在这里稍微解释以下，管理员与读者管理等用例和读者与查询读者信息等用例是一个双向关联的关系，就是说管理员进行读者管理，读者管理也与管理员有关