机房收费——用例图

用例视图包括用例图、协作图、序列图和活动图。

用例图概念：用来描述软件设计过程中的用户需求,在需求分析阶段产生。

1、活动者：    谁对系统的某一需求感兴趣

组织中哪一部分使用系统

谁从系统的使用中收益

谁向系统提供信息

谁将维护系统

系统是否使用外部资源

系统和已存在的系统是否交互

2、 用例

3、事件流：简要说明、前提条件、主事件流、其他事件流和事后条件

4、元素之间的关系：1）概括关系：表示几个元素的某些共性

                      2）包含关系：使一个用例的功能可以再另一个用例中使用

                                   3）扩展关系：允许一个用例扩展另一个用例提供的功能

在学习《机房收费系统》的时候只是简单的根据业务需求，完成了代码的编写，不明白什么是面向对象和面向过程，学完了《软件工程》和《UML》了解了面向对象和面向过程的区别，现在开始用面向对象的思想编写《机房收费系统》的文档。针对《机房》的用例图，首先搞清楚谁是执行者，什么是用例，又有怎样的事件流。《机房》的权限设置，表明了系统有3个执行者，我们要清楚每个执行者的权利是什么，他们之间有什么联系等。下面是《机房收费系统》的用例图：

我理解的三者之间成了继承关系，其实也不能全算是继承，他们之间的关系只不过是与继承有点相似而已，操作员确实有一般用户的功能，但他们之间不属于父类和子类的关系，这个还需要认真讨论一下。

看着做好的机房收费系统，从三种角色的角度考虑抽象出每一个功能就是一个用例，用例和用例之间的联系就是功能之间的联系，注意到图中的虚线，开始只是大概明白什么意思，也没有深究，验收的时候师傅问我为什么账单和日结账单还有周结账单之间用的是include而日结账单和打印之间用的是extend，我开始支支吾吾的回答不上来，回来之后仔细查了一下，总结一点就是前者是必须后者是不必须的。

百度上的概念：

包含（include）：当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。

扩展（extend）：extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。

用例图就是梳理系统的业务功能，明白每部分业务功能由谁负责，每部分的关系等。上面的用例图只是对系统功能的罗列和整合，用例图还可以从三个主要功能的角度出发画出，角度不同，画出的用例图也不同。