UML图分析

你真的知道UML是作什么用的吗？

      优秀的UML有什么特征？

      何时该用UML？或者说，何时不应用UML？

      学了一学期的软件工程，本身捣鼓了一个小系统，对UML这个东西有了一点感悟。我的以为，UML是一个“貌似”能描述系统构架的东东，有不少人热衷于画这个东东，甚至热衷于画异常复杂的UML图，并以此为炫耀的资本。我一度很纳闷，好像画了这个东西，面子上就能过得去，就表示你的这个系统是符合软件工程规范的。真的是这样吗？

      区区一个图而已，能成为衡量软件质量的标准吗？

      我很怀疑。但在用UML图这件事上，个人经验太少，不知道什么是对，什么不对。

      个人感受是：

      一、图是给人看的，图不能太复杂，不然看图还不如看代码。

      二、并非全部的程序都要用UML图表示，或者说并非全部的程序都适合用UML图来表示的。

 

 

      在学校的图书馆瞎逛，偶然碰见了《UML FOR JAVA PROGRAMMERS》一书，我惊讶地发现了书中阐述了许多我困惑的问题。书中的许多警句训诫更是让我醍醐灌顶，摘录以下，以之为后事之师：

 

 

 

UML适合作什么？不适合作什么？

      一、UML很是方便于软件开发者之间沟通设计思想。UML特别适用于就关键设计思想进行沟通。另外一方面，UML不是特别适合交流算法的细节。

      二、UML适用于建立大型软件结构的路线图，这种图帮助开发者看清楚类与类之间的关系。

 

 

 

图应该画成什么样？

      图尤为适合于他人交流思想，有助于解决设计问题。细节不要多，只要能使你实现目标。

 

 

 

什么时候绘图？

      一、当若干人须要同时进行开发时，这些人都须要理解一个系统的某个部分的设计结构时，应该绘图。当全部的人都达成一致的时候，中止画图。

      二、当两我的或更多的人对一个特定的元素如何设计持不一样意见，你须要你的团队协商时，应该绘图。将讨论限定在一个范围内，肯定决策的方法，好比投票制公正裁决制。时间一到或已得出结论，就中止绘图。而后擦掉图。
      三、当你须要探讨一个设计思路时，何况画图可以帮你更好的地思考时，应该绘图。一旦得出结论，结束思考，就中止绘图，而后扔掉这些图。

      四、要向别人或者本身解释代码中某些部分的结构时，应该绘图。若是进一步的解释须要借助代码，就中止绘图。

      五、项目接近尾声，客户要求将图归入文档以转交给另外一方时，应该绘图。

 

 

 

什么时候不要绘图？

      一、不要由于流程的规定而绘图。

      二、不要由于这两个缘由——不绘图会让本身内疚，或认为优秀的设计者都绘图——而绘图。优秀的设计者写代码，只是在必要的时候才绘图。

      三、在编码前的设计阶段，不要为了建立详尽的文档而绘图。这样的文档几乎一文不值，还浪费了大量的时间。

      四、不要为写代码的人绘图。真正的软件架构师应当参与编码，以实现本身的设计。

 

 

 

关于文档

      良好的文档是任何一个项目的根本。没有它，团队将在代码的汪洋大海中迷失方向。但另外一方面，过多不恰当的文档反而拔苗助长：由于团队不只要看全部这些杂乱的、容易误导人的文档，还要面对代码的汪洋大海。

      文档是必须写的，可是要谨慎。不少状况下，决定不编写哪些文档与决定编写哪些文档一样重要。

      复杂的通讯协议须要用文档描述。

      复杂的关系模式须要用文档描述。

      复杂的可重用框架须要用文档描述。

      可是，它们都不须要成百页的UML。软件文档应该言简意赅。软件文档的价值与它的大小成反比。

 

 

 

顺序图的应用场合

      一、须要当即向某人描述一组对象之间的协做方式时；

      二、想把这种协做关系形象化以便于本身思考时。

      顺序图只是偶尔为之以锻炼分析能力的工具，而并非必不可少的文档。

      偶尔在白板上绘制顺序图是颇有价值的。在一张小卡片上绘制五、6个顺序图，描述了子系统中最经常使用的交互场景，这样的纸“价值千金”。相反，一个充斥了上千个顺序图的文档，其价值还不如打印它们所用的纸。

      上个世纪90年代，软件开发的最大谬论之一是，开发人员在编写代码以前应该为全部的方法绘制顺序图。事实证实，这极大地浪费了时间。千万不要这样作。

 

     

 

      我认为，一切的关键是，画图是为了帮助咱们思考、交流和编程，不要为了画图而画图。