昨晚针对我所画的uml图让师傅进行了一下验收，我也从一个宏观的角度对我这个阶段的学习有了一定的了解，挺感谢师傅的。开始听前辈们说她们在验收uml图之后才发现自己的很多了解犹如管中窥豹，但是处于某些原因（或许是为了赶进度）就不会再改正。虽说我的进度比较慢但是我不希望自己在这纷扰的学海中浮躁，我还是要尽自己所能稳重求快。废话说了这么多进入正题吧。

    首先从系统的需求开始吧，也就是针对用例图遇到的问题进行汇总：用例图是描述系统需求的，在uml中是属于比较宏观的了，其他的图除了实现图之外其他的都是针对某个小用例而言的。在画用例图时，关系之间的注释表明的不太完善，这个缺陷会导致项目经理或者用户在了解需求时很费劲。另外对扩展和包含两类关系的运用不太好。对此，急需重申一遍两者的用法：包含是完成一个用例必须设计到另一个用例，而扩展是可以让问题解决锦上添花的用例关系。例如：我要起床必须要穿衣的，但是我可以化妆也可以素颜出门，也就是化妆针对起床出门用例来说是扩展关系。（呵呵，可能不太恰当，但是就是这个道理啦。）如下图：

    确定需求之后就要去明白系统的问题域，对系统的静态架构进行描述。这就需求绘制类图和对象图以及包图之间的关系了。往往一个系统的类图会有很多，怎样才能做到尽可能的完整呢。这就必须要明确一个主线了。我的原则是从用户角色开始、接下来是边界类、控制类和实体类。我的原则依据是从用户出发，按与用户接触最近的界面然后是一系列的逻辑操作，之后是内部的数据库表实体进行描述的，师傅说我的分类思想和三层有些相似，我现在还没有学到三层只能理解到这种程度了。与此，我在uml图类图中出现的问题如下：我的类图描述不准确，每个窗体都应该建立一个类图，之后是每个功能的实现方法整体封装成一个类，但是我是直接把功能当作了类的实现中的一个操作方法，这样在代码实现阶段是很不可能的事情。还有当初对于包图的理解不够深，不知道怎么用，进而在uml图类图中也只是一带而过，没有具体的描述。在这里急需重申一些包图的用法：在画类图的时候尽量让类之间的关系少一些，也就是松耦合的思想，这样可以保持类的独立性。但是有时候有需要指明类之间的关系怎么办呢。这就需要包图发挥作用了，可以把类图用包图进行分类，然后类之间的关系用包之间的调用来完成。

    在所有的图中，师傅说画的相对到位的就是活动图了。所以在这里就不提活动图有什么问题了。

    活动图强调系统的动态行为，而状态图是针对行为出现的结果进行描述的。虽说师傅评价我的状态图画的还算可以吧。但是我还是在验收过程中遇到了自己的一个严重不足，我在画图初始，企图用一张状态图描述系统所有的情况，这种观点是很不现实的，就算可以勉强实现也会导致问题域不明确。所以在这里主要就是注意一下状态图只能描述一个对象在整个过程中的变化情况。

     系统的动态行为明确之后，就需要对用例的具体实现形式进行描述了。这就用到了交互图，交互图包括序列图和协作图两部分，具体的可以点击“交互图”查看。在这里我所犯的错有：试图用一幅图描述整个系统，实际这也是不现实的。一个消息从建立到传递、返回和销毁之后就可以结束本交互图，进而另一个活动的描述需要重新建立一张图。在我的交互图中还需注意的一点是：所有的对象都是从类中进行实例化出来的所以一般格式是：（object name）：class name其中的对象名可以省略这样的类叫匿名类。但是很多人的对象是临时命名的。导致在对象之间进行交互时不能通过调用彼此的操作来实现。这就像过年的时候租赁女友似的，虽然临时定义一个女友可以让你带回家见爸妈。但是毕竟你们之间没有很大的默契，所以难免会出现 你发出一个信号对方无法应答的闹剧。uml图中的对象也一样，只有把提前定义好的类进行实例化，才可以直接调用彼此的操作。

      最后到了实现的阶段，也就是需要用到实现图了，实现图包含组件图和部署图两种。由于现阶段我们对实现图运用和把握不太准确，这里就只能了解到这个程度了。需要完善的地方我会在以后的学习中不断的改进。

这是我昨晚的收获，经历验收过程之后终于我也可以把uml的9类图，像冰糖葫芦一样穿起来了，当然我还有许多需要完善。这里调用一句矫情的话来表达自己的思想吧：生命不息，学不止步。。。。O(∩_∩)O