UML建模之用例图

       用例图，是用来描述用户的需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。通常有客户和设计人员共同敲定。

       用例图通常有三部分构成，用例，角色，关系。关系包括关联，使用，泛化。其中使用是角色和用例之间的关系；泛化关系可以是角色之间的关系，也可以是用例之间的关系，例如，打电话可以繁华处打长途电话、打局内电话；关联关系有扩展和包含，还有别的（可以参考大象这本书），这里只介绍着两种。

       

       包含

       当从两个或者两个以上的原始用例提取公共行为。发现能够使用一个部件来实现某一个用例的一部分功能是很重要的时候，就应该使用包含关系。包含关系，可以理解为必不可少。例如下图，查询，修改和删除，必须建立在登陆者一个用例的基础上才可以。

                                           

       但是，也看到人曾这样用过包含：就是将上图中的查询、修改、删除进行抽象，抽象出一个粒度比较大的用例——维护。我个人认为这两种方向理解的包含都正确。因为UML本身就是4+1视图，用例视图在哪个阶段都可以用，在最初建模时，可能就只考虑到对学生的一个管理，至于有没有删，进一步建模时再定。所以关于建模我个人认为这两个版本都可以，但是如果按照上面的定义，这个里面其实只是涉及到了用例的粒度大小问题而已，并不存在着提取公共行为，那么就不称作为包含，这个和别人交流过，每个人看法不一样，到底怎样，还有待进一步的学习。

                                     

       扩展

       说完包含，那么就不得不说一下他的老冤家，扩展关系了。扩展，分离出不同行为。一个用例明显的混合了两种或者两种以上的不同场景，或者是根据情况可能发生多种事情。扩展，可以理解成可有可无。在某种场景下，当查询到一个人的信息时，可以进行修改，也可以不进行修改。此时的修改，就是一个扩展用例。扩展需要注意的是箭头的方向。

时间：2012-10-27    添加原因：对扩展有了新的认识

扩展关系可以通过判断是否可以从一个用例的执行中，在需要时转向执行另一个用例，执行完后返回继续，即存在扩展关系。

例如：在提交的时候判断有没有登录，如果没有，则跳转到登录界面进行登录操作，然后继续提交。在这里登录用例扩展了提交用例。

                               

      讨论

       争议最大的感觉还是包含关系，两种理解到底哪一种正确呢？

       其实我感觉第二种包含关系只是强词夺理的一种理解，因为在建模时，我感觉应该粒度进行统一，要用大粒度就统一用大粒度，最好不要再一个图里面出现一个用例包含子用例，让人感觉有点冗余。

       包含和扩展是用例图中最重要的两种关系，个人还是建议多在网上看看查一下，对二者进一步认识。但是在有些情况下你仍然觉得很难决定应该用include还是extend，那么停止纠结，就用include吧（因为包含比扩展更容易让人懂，而扩展比包含更容易让人懵）。“错”就“错”了。

       最后，说一下，用例之间不要随便搞“关系”，越简单越好。建模不是画艺术画，艺术画一般人看不懂，人那是意境。你把用例图画的很玄，各种关系各种用，生怕哪种没用上，被人说菜鸟，关系弄的贼复杂，最后自己都说不上来当初为什么加关系，或者加的勉勉强强！很不幸，方向错了。用例真正的价值在于用例的描述，所谓用例之间的关系往往价值不大还会适得其反。

       注：文章最后两段的观点引自http://blog.163.com/bit_runner/blog/static/5324221820109642330783/，哪里不对欢迎斧正。