看了《UML基础与应用》视频，跟着刘慧老师从面向对象技术到UML构成的学习，再从UML的九种图、关系到其在软件开发各个阶段的应用等，对UML有了些了解。在看视频的时候就特别想自己也画各种图。
　　学习完了这些理论基础之后，真正的到自己动手了，用RationalRose 来画图，安装好之后自己就迫不及待的试了试，毕竟在用例图中的小人还是挺吸引人的，在编辑区右侧的图形工具栏可以满足我们的各种需求，直接可以进行拖动添加，这也是我喜欢RatinalRose的原因之一。

　　关于UML十种图，已在UML基本构造块之十种图中介绍，在此就不重述了。我画的第一个图是用例图，画用例图的关键是找用例及其它们之间的关系，还有就是抽象出参与者，当然参与者不仅仅是指人，还可以是系统、子系统或外部实体。一下是我画机房收费系统的用例图，用例我是根据系统的功能来画的，若有不正确的地方，望读者多多指正。

　　当看完之后，不知读者们有什么感觉。其实，我画第一版用例图的时候图为了自己方便，用例名称全都是用中文来表示的，师傅说这太不profession了，所以改成了用英文来命名。当我满怀信心的叫师傅来验收的时候，没想到还是漏洞百出。这个用例图只有我自己能够看得懂，别人是看不懂的，因为一点备注都没有，要知道自己所画的图是用来给别人看的！是需要根据UML图来实现系统的各个功能的。
　　另外，在用例图中，用例之间的关联重要的是对包含（include）与扩展（extend）的理解。我的理解是：包含是多个用例有共同点，然后提取出来抽象成另一个新的用例，也就是说那多个用例里面包含这个新的用例，当多个用例有行为后，这个新的用例必定也执行这个行为。扩展就是一个基础用例可以拥有一个或多个扩展用例，扩展用例可以有一个，也可以有多个，也就是说扩展用例相对于基础用例是可有可无的。
　　在机房收费系统的用例图中我找不出用例之间有包含的关系，下面举个例子来说明包含关系：

　　假设有一个资源网站，维护人员要对网站的资源进行维护，包括添加、修改和删除资源。在添加和修改资源后都要对新添加和修改的资源进行预览，用来检查添加和修改的操作是否正确完成。
　　从图1（为方读者理解，用了中文命名用例）中可看出添加和修改资源都抽象出来一段行为，成为一个新的用例——预览资源。而原有的添加和修改资源这两个用例都会包含这个新抽象出来的资源。这样做的好处就是，以后如果对预览资源进行修改，则不会影响到添加和修改资源这两个用例，也不会发生描述不一致的情况，因为只是在一个用例中进行修改。
　　再来看一下，扩展关系又如何在机房收费系统中体现的，如图：

　　在图2中，基础用例是“StudentLoginRecord”（学生查看上机记录）和“StudentRechargeRecord”（学生查看充值记录），扩展用例是“exportExcel”（导出为excel表），在一般情况下，只要执行学生学生查看上机记录和学生查看充值记录用例即可。但如果学生想做成excel表打印出来，这时就不能执行用例的常规操作，如果去修改“StudentLoginRecord”和“StudentRechargeRecord”用例，势必增加系统的复杂性。这时就可以在这两个用例中插入一个用例，这样在学生想在查看之后导出为excel表，就可直接执行扩展用例“exportExcel”。
　　总之，用例图是根据需求来画的，主要是宏观上能实现哪些功能，满足用户的需求。此外，RationalRose还是得多多操作，这样才能熟练运用。在画之前也应该要明白这图是画来做什么的，画来给谁看的。
　　额，本想是做一篇总结的，又写成了单独的一篇关于用例图的博文~~~~(>_<)~~~~。