用例图新解

       初次接触UML图的时候，对它的感觉还不错，感觉不是很难。但是在实践的时候，却总是感觉自己在瞎画。

       下面浅浅的谈谈自己最近对用例的新的理解。

       用例图，是系统功能抽象的集合，将系统的功能进行合理的分类。它是系统功能最美的、最直接的可视化诠释。

        有人说：用例图是一种客户与开发者之间可以沟通、理解的表现形式，它是开发者与客户之间的可视化契约。我感觉说的非常好。

       个人认为，用例与界面几乎是一一对应的。就像实体类与数据库表的对应关系一样，尽管整体上是对应的，但是也有特殊情况让他们不对应。所以我刚才的用词是几乎。

        在这里，我就认为用例就是对应界面，这样我们从大方向上就不会错。

        当然，在用例图中，如果有几个相似的用例，我们可以把它们抽象出来一个父用例。比如机房收费系统中，关于用户的操作有添加用户、删除用户、查询用户等等，这是我们我们就可以抽象出来一个UserManager用例作为父用例。

        那么，在用例图中，还有一部分比较重要，就是用例图的关系。常见的关系有两种：一种是角色与用例中间的关系，另一种是用例与用力之间的关系。角色与用例之间的关系比较简单，就是使用关系。简单的理解是某一个角色使用某一个用例。用例与用例之间的关系主要有两种：包含关系与扩展关系。

        这两种关系很好辨认：包含是指父用例包含子用例，所以箭头是从父用例指向子用例，构成包含关系。而扩展关系我们应当理解为“扩展自”，就是用例扩展自哪一个用例，箭头应当指向被扩展的一方。

        这两种关系的含义也很好区分：包含关系中的父用例一般是抽象出来的，所以几乎没有与他对应的界面，界面都与它的子界面对应；而在扩展关系中，我们用下面的图做演示。

                                       

        在这个关系中，QueryItem（查询项目）用例是必须执行的，而DeleteItem（删除项目）可以执行，也可以不执行，所以我们说DeleteItem用例扩展自QueryItem用例。

       我们可以这样理解：我们想得到项目信息，我们就必须用QueryItem去查询项目信息，而查出来之后我们可以删除项目，也可以不删除。

谈完了对用例的最新的认知，下面谈谈它的作用。

用力图在需求、建模中的作用是毋庸置疑的。

       首先，由于用例图看起来非常直接，可视化效果非常好，用户能够投通过看用例图，加上系统分析员的解说，来充分了解系统，看看将来做成的系统到底是不是他们想要的，到底能不能满足他们的需求。所以说，用例图，可以看做是用户与需求分析员之间沟通的桥梁。

       其次，用例图在建模过程中，起着非常重要的作用。一个界面需要完成哪些功能,最好的根据就是按照用例进行建模。然后至于页面是否美观，这可以用div+css去实现，一些好的效果可以用js实现，同时用到局部更新的部分就需要用到AJAX，这些方面我也是菜鸟，正在学习中。欢迎大家同我一起研究、讨论，共同进步。

       最后，我们在确定好架构之后，然后类图、方法的确定，也需要根据用例来确定。

       所以说，用例图的重要性是不言而喻的。本文主要介绍了用例图的主要组成、关系，以及它的用途。我认为，用例图是做一个系统的第二步，做完可行性分析之后，最主要的就是确定好用例，因为一个好的用例图，就决定了它好的需求。同时，为后面的建模同时了非常大的便利。

      本文主要是个人学习UML图以来，对用例图的感知，希望一起学习的同学留下宝贵意见，大家共同进步。