UML用例图简单的讲就是显示参与者与系统中的用例之间的关系。（即系统如何与外部参与者交互）所以，开发用例模型应该从项目风险承担者的角度而不是项目开发者的角度出发，每个用例表示系统提供给其用户的一段功能。

一、用例图所使用的事物与关系

1. 参与者——直接外部用户

1）定义：它不属于系统的一部分，但能以某种方式对系统起作用。

比如：在机房收费系统中，就有三个参与者一般用户，操作员和管理员。

     

2）如何选取

选取参与者应充分考虑以下问题：

- 系统开发完成之后，有哪些人会使用这个系统？

- 系统需要从哪些人或其他系统中获得数据？

- 系统会为哪些人或其他系统提供数据？

- 系统会与哪些其他系统相关联？

- 系统是由谁来维护和管理的？

3）参与者之间的关系

在机房收费系统中三个参与者之间是一种泛化关系（泛化关系主要针对的是父类，继承主要针对的是子类。）如图：

 

2.用例——表示系统提供给其用户的一段功能

1）定义

简单的用例就是系统通过与参与者的交互进行的一连贯的功能，比如维修工进行定期维修，顾客购买一瓶饮料。

2）如何选取

- 参与者为什么要使用该系统？

- 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？

- 参与者是否会将外部的某些事件通知给该系统？

- 系统是否会将内部的某些事件通知该参与者？

3）用例之间的关系

在机房收费系统中最多的关系就是包含关系，其次就是拓展和泛化。

3.关系总结

 

二、机房收费系统UML图

三、出现的问题

1. 操作

Rose出现 “relation from A to B would cause an Invalid circular inheritance"问题

原因：这是由于我当时删除一个错误联系直接按了delete键，事实上并没有真正删除。

解决方法：首先恢复原来的错误，然后按ctrl+delete键删除。

2. 设计

通过着色进行分类。在《UML风格》和《图论思想与UML》里面对于着色讲解了很多。

3. 关系

因为在“学生基本信息维护”中既有查询信息也有修改信息，如果我认为缺少修改信息不会影响到学生基本信息维护的完整性，只有触发修改按钮才会进行修改，所以在这我选择的是拓展。

四、总结

看了好多师哥师姐的用例图的总结，不仅理清了关系思路还对整体结构有了一定的把控。

 

 

用例图——机房收费系统