【.NET机房重构】——UML图新认识

    前几天听别人给我讲什么是LinQ查询，之前对这个是有过一点点的接触的，但是当时学习重点不在这上面，于是就没有深入研究。现在再听他讲，我发现了LinQ查询应该是可以替代反射来实现换数据库的。他说这种查询是凌驾于各种数据库的查询语句之上的，也就是说它可以查询任何一种数据库；于是我就想到，那是不是说明，可以利用它来实现更换数据库。他还说，使用这种查询方式可以减少代码的错误，但是这只是网上说的，具体怎么做不知道；我就想，会不会是跟反射扯上关系了？因为利用反射的话，需要写两套不同数据库操作的D层类，如果用LinQ查询，是不是就只用一套类就行了？减少了代码量，自然就减少错误率了。（以上知识性的东西均需验证！！）

    单就这件事而言，其实对任何知识的学习都是要重复的，相同的知识在不同的时间，具有不同的知识储备的情况下，对它的理解是不一样的。

    刚开始学UML时，就对第一版机房收费系统进行补图。机房重构时，发现自己上来就画图根本什么都不会，于是又进行了第二次的补图经历。不过，虽然都是补图，但是对UML图的认识是大不一样了。

    回顾一下自己以前的总结：UML精华所在——四种关系九种图，看到的其实都是视频里的东西，或者是从网上查到的东西，没有自己的想法。经过第二次的补图经历之后，对UML图的认识又多了很多。

  UML简介

    Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 UML定义了用例图、类图、时序图、对象图、状态图、协作图、活动图、构件图和部署图九种图，从不同的角度对系统进行描述，便于系统的分析和构造。但是在一些画图工具中，又派生出了视图的概念，其实本质上是一样的。

  UML视图

UML中共分为五种视图，分别是：用例视图、逻辑视图、进程视图、设计视图、部署视图。五种视图的关系如下：                                              

用例视图

从外部角色的视角来展示系统的功能。角色与系统进行交互，它可以是一个用户，也可以是另外一个系统。用例是对系统功能需求的概括描述，系统的使用被描述为用例视图中的多个用例。用例视图在系统建模中处于中心地位，是其他视图的驱动因素。用例视图在系统需求分析时起着重要的作用，系统开发的最终目标就是要与用例视图中的描述相一致。

用例视图包括用例图、时序图，有时候需要活动图、状态图、协作图等的辅助。

逻辑视图

用系统的静态结构和动态行为来展示系统内部的功能是如何实现的，其侧重点在于如何得到功能，这就要求逻辑视图能够剖析和展示系统的内部。系统的静态结构通过类图和对象图，而动态行为使用交互图和活动图进行描述。

逻辑视图包括类图、对象图、交互图和活动图，利用类图和对象图来描述系统的静态结构，动态行为则由交互图和活动图进行描述。

   设计视图

展示代码的组织和执行，描述系统的主要功能模块和各个模块之间的关系，主要被开发人员使用。

设计视图包括时序图、活动图、状态图等，主要是开发人员合作开发时交流用到。

   进程视图

展示与系统处理性能相关的主要元素，包括可伸缩性、吞吐量、基本时间性能。过程视图将系统划分为进程和处理器，通过这种方式来分析和设计系统如何有效利用资源、并行执行、处理来自外界的异步事件，除了要将系统划分为并发运行的线程以外，还要处理线程的通信和同步。

进程视图包括动态图（状态图、交互图、活动图）和实现图（交互图和部署图）

   部署视图

利用节点来展示系统部署的物理架构。节点可以是电脑或者设备，将这些节点相互连接起来就可以分析和展示在物理架构中系统是如何部署的。

部署视图主要包含组件图和部署图。

为什么了解视图

之所以要了解视图，是因为图的关系。重构时选的EA画的图，最大的体会是太难用了。并不是说软件本身不适合自己的需求，而是软件功能太强大了，以至于自己不会用。这就涉及到EA的用法了，我对它研究的还不是很透彻，还有很大的进步空间。不过，对于机房重构画图，这些是足够了。在EA中，图是要分层画的。它是一个建模工具，图的构建作为一项工程来说，那么每种视图就是该工程下的一部分，而每种图又是视图中的组成部分。不同的视图下，画图环境是不一样的，就是说不同的视图下图形元素和关系是不同的，如果图建错了位置，会出现找不到关系的问题。

以上的都是对UML图理论上的新认识，下面是在实践过程中，对图到底怎么画的新认识。

对于机房收费系统中，比较重要的图有四种，包图、类图、时序图和用例图。用例图表现了系统的用户需求，即系统到底要实现那些功能，所以用例图是一切图的基础。用例图中的每个用例都代表一个功能，该功能给程序员开发时程序员需要了解该功能的具体执行过程，于是就用到了时序图。包图最浅显的理解就是给三层架构用的，把不同的层打成包，通过包之间的关系来显示层与层之间的关系。自然而然，类图也就是包含在包中的，每一层中有哪些类，类与类之间有哪些关系都囊括其中了。虽然UML中有九种图，从不同角度去描述系统，但是图与图之间是有关系的，因为它们描述的是同一个系统，这之间的关系也就在建模时体现了。

总结

还是文章最前面的一句话，不同的时间对相同的知识理解是不同的，因为你掌握的东西不同，学习的需求也不同。不只是对知识，重构画图时对导师制的理解也更加深刻。虽然经历了一年半的导师制，但是确切说来，对它的了解只限于表面。画图时，好多东西是上网查也很难得到的，因为这些都是经验，都是别人撞得头破血流得到的，导师制很好的体现了站在巨人的肩膀上。