你真的知道UML图的作用吗?

      你真的知道UML是做什么用的吗?

      优秀的UML有什么特征?

      什么时候该用UML?或者说,什么时候不该用UML?

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

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

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

      我的感觉是:

      1、图是给人看的,图不能太复杂,否则看图还不如看代码。

      2、并不是所有的程序都要用UML图表示,或者说并不是所有的程序都适合用UML图来表示的。

 

 

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

 

 

 

UML适合做什么?不适合做什么?

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

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

 

 

 

图应该画成什么样?

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

 

 

 

何时绘图?

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

      2、当两个人或更多的人对一个特定的元素如何设计持不同意见,你需要你的团队协商时,应该绘图。将讨论限定在一个范围内,确定决策的方法,比如投票制公正裁决制。时间一到或已得出结论,就停止绘图。然后擦掉图。
      3、当你需要探讨一个设计思路时,况且画图能够帮你更好的地思考时,应该绘图。一旦得出结论,结束思考,就停止绘图,然后扔掉这些图。

      4、要向别人或者自己解释代码中某些部分的结构时,应该绘图。如果进一步的解释需要借助代码,就停止绘图。

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

 

 

 

何时不要绘图?

      1、不要因为流程的规定而绘图。

      2、不要因为这两个原因——不绘图会让自己内疚,或认为优秀的设计者都绘图——而绘图。优秀的设计者写代码,只是在必要的时候才绘图。

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

      4、不要为写代码的人绘图。真正的软件架构师应当参与编码,以实现自己的设计。

 

 

 

关于文档

      良好的文档是任何一个项目的根本。没有它,团队将在代码的汪洋大海中迷失方向。但另一方面,过多不恰当的文档反而适得其反:因为团队不仅要看所有这些杂乱的、容易误导人的文档,还要面对代码的汪洋大海。

      文档是必须写的,但是要谨慎。很多情况下,决定不编写哪些文档与决定编写哪些文档同样重要。

      复杂的通信协议需要用文档描述。

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

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

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

 

 

 

顺序图的应用场合

      1、需要立即向某人描述一组对象之间的协作方式时;

      2、想把这种协作关系形象化以便于自己思考时。

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

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

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

 

     

 

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

你可能感兴趣的:(你真的知道UML图的作用吗?)