用例图验收启示录-这就是思维的过程！

UML中用例图和类图验收可谓是一波三折，为什么会有种江郎才尽的感觉呢……（未完待续）

第一次验收时间：2013.03.11

第二次验收时间：2013.03.17

第三次验收时间：2013.03.19

这就是：思维。虽然，图中还存在不足的地方，但是每一张图都会比上一张图更逼近与正确的思路。

        刚看完Rose画图视频的时候，对于用例图中的Actor和UseCase有了初步的了解。但是，在实际运用到“机房收费系统”中的时候，就会犯一个致命的错误：本来用例图是面向需求的部分的，最忌讳的就是想“该怎么实现呢？”。而，我恰恰就是犯了这样的错误。

        本来一张很简单的图，在第一遍画图的时候，我却总是在想：这个用例和那个用例是include关系呢？还是extend关系呢？（强制性的告诉自己，肯性有一定关系的！）

        第二个问题：用例的抽象。拿AddUser用例和DelectUser用例来讲，我会告诉自己这两个用例共属于“MaintainUser（用户管理用例）”这个用例。可是，对于“MaintainUser”这个用例而言，实际上并非是用户的需求。用户可能告诉我：我需要一个增加系统用户的功能，还需要一个删除用户的功能。据此分析：用户真正的功能需求是：AddUser和DelectUser，而不是MaintainUser，因为实际系统中我并没有对这个抽象的用例进行实现。这就是所谓的图和代码不对应的问题。

        第三个问题：用例之间的关系不清楚！假设用户的功能需求是：添加系统用户AddUser和删除系统用户DelectUser，据此分析：删除系统用户的前提是：查找出用户并显示出来，然后选择相应的系统用户进行删除。同样，添加系统用户的前提也是查找并显示出系统用户，在系统用户名称不重复的前提下，添加新的系统用户。所以，对应Operator的用例应该是：AddUser，DelectUser，QueryUser（其中的include可以画也可以不花）。而我却错误的理解为：要想DelectUser的前提，应该是曾经AddUser过这个用户，否则又怎能进行删除操作呢？虽然，这样想表面上看起来是没有错误的。但是，这样想是应该在“实现阶段”要做的事情，而不是在“用户图"这个大环境要思考的事情。

        用例图是考虑功能的，而不是思考该怎样实现的！也不是考虑，功能之间的执行顺序（那是：协作图！）。更不是考虑数据之间的怎样流动的（那是数据流）！

第一次验收：用例图-Administrator-1.0

第二次验收：用例图-Administrator-2.0

第三次验收：用例图-Administrator-3.0

第四次验收：用例图-Administrator-4.0

第一次验收：用例图-Operator-1.0

第二次验收：用例图-Operator-2.0

第三次验收：用例图-Operator-3.0

第四次验收：用例图-Operator-4.0

第一次验收：用例图-GeneralUser-1.0

第二次验收：用例图-GeneralUser-2.0

第三次验收：用例图-GeneralUser-3.0

第四次验收：用例图-GeneralUser-4.0

第四次验收：用例图-Main-4.0