UML—时序图重思考

    不同的学习阶段，对UML的学习有不同的理解，现在有些明白老师为什么让自己在不懂的时候继续往下学的道理了，有些知识不经历过一些实践是不会引起注意的。

【以前的图】

        这是以前做的图：

                           

        没有学过分层思想之前，知识简单的理解，时序图是对象之间传递消息的顺序，强调的时间顺序。上图是自己针对对vb版机房收费系统上下机做的，简单的系统，简单的代码，然后就是简单的图。

【现在的图】

      以下是自己针对七层版.net机房收费系统的上机所做的图：

        相比较第一张图，做了许多灾难性的修改作业以及自己的一些思考：

        1.对生命线的思考。第一遍学习只是简单浏览了一遍时序图中的图符，了解了它是什么名字，对它所起到的功能却没有做出深入研究。生命线的截断就意味着一个方法、函数、程序的结束。

        七层的上机中，我对外观的简单理解是：B层一类一方法，facade类是对B层方法的重新排列组合；B层是一个个零部件，facade就是这些零部件组装起来的汽车。所以当B类的一个方法从建立到传回一个函数，就完成了一个“零部件”的生产，它的“生命”也就终结了，例如从Bll这个对象实例化的cardIsExit（）方法；但facade类是由好几个方法组件而成的，它们共同完成上机这个操作，因此它必须在输出给U层允许上机的boolean值时它的生命才算完结。

       2.时序图的起始是由用例来触发的。用例图的最重要的功能之一是：对用例图对需求的表达做出更精细化，更层次化的表达。因此我们不应该忽略用例在时序中所起到的举足轻重的位置。

       3.重用代码的提取和返回值问题。七层设计中，一个窗体的实现对同一个B层方法不止一次的使用。就像上面遇到的B层两次返回了对泛型集合list（entity.En_user），就可以考虑在facade层建立一个provide函数，返回一个就可以供给两个方法使用。

                                              

        在上面的上机流程图种我们看到有许多逻辑判断，当从底层数据库返回到B层的数据通常采用两种，一个是泛型集合，一个是布尔值。比如判断用户存不存在，所剩余额都要访问student表，如果前者使用的是Boolean值，还得从Facade层到D层重新一步步建立相同的方法。如果一开始就返回的是泛型集合的话，可以在facade层做一下判断，集合中不存在数据，就已经能证明该用户不存在了。

        如此思考问题的话，我们的B层类一定会大大减少的，同时也能让我们的系统运行大大减少开销。

【总结】

        不同的学习阶段有不一样的思考，这也在验证着我们的成长步伐。期待接下来的学习旅程。