大多数软件人员应该对UML并不陌生,什么是UML?它是Unified Modeling Language,它是一种建模语言,它是进行需求分析和概要设计的利器。在您的理解中,什么是UML呢?它仅仅是那些图形、文本和符号的集合吗?还是一种用文本、图形和符号的集合来描述现实生活中各类事物、活动、及其之间关系的语言呢?我听到过两种声音:有许多软件从业人员甚至软件企业认为,UML是非常重要的,系统分析员、软件设计师必须精通UML,这一观点可以从大多数企业的招聘信息中得到:“xxx职务,精通UML……”。又有一部分人说,UML似乎也没多大用处,使用UML的图形来画画流程图倒是不错的选择。对于前者,有过分夸大UML之嫌疑,这也直接导致国内很多初学者在还没有弄清楚UML是什么的情况下盲目地学习和追捧UML,最后收效甚微;而后者呢?认为完全没有必要使用UML,这将使得系统中各角色之间的直观交流变得困难。 UML是什么? 1. UML是一种标准。在这里说标准,似乎太深奥了,说协议或许更好些。UML是一种协议,它是系统分析人员和设计人员之间、软件从业人员与客户之间所应遵循的一种通讯协议。就好像FTP服务器程序与客户端程序需要通讯,首先大家都要遵循一种协议(FTP协议)。通过使用UML,系统分析人员不仅可以很直观地记录客户需求,为系统设计提供具体的、可参考的系统分析模型,而且可以很方便地与设计人员甚至客户进行交流,因为大家都遵循同一协议,交流就变得容易和直观了。从客户角度来讲,如果希望更好的表达自己的需求信息,并能够很好的与专业人员进行交流,是不是也应该多关注一下UML呢? 2. UML是统一建模语言。什么是“统一”?它表示UML并不仅仅是软件系统的“专利”,非软件行业同样可以使用UML进行建模描述。同时,它也更好地证实了“UML是一种标准”这一说法。什么是“语言”?因为它有自己的语法和语义。UML的各个元素有着自己的语义,而元素的组织形式却遵循着一定的语法规则。从语法强度来讲,UML应该和自然语言的语法强度平级,因此UML应该会出现二义性问题。UML应该是一种描述性语言(DL),描述对象就是系统分析与系统设计的思想。 UML不是什么? 1. UML不是方法论。UML不能对问题域提供一套解决方案,这是系统分析员和软件设计师的职责。它仅仅是一种语言,支持UML标准的软件也仅仅是一套系统建模工具,它就像一般的编程语言一样,比如C#语言本身并不能帮你解决实际的业务问题,具体问题如何解决,就需要编程人员很好地使用C#语言来编程实现。总的来说,系统的分析思路、设计与构架思想是来自于系统分析员与软件设计师本身的,而不是来自于UML。而系统分析员和软件设计师对系统的分析与设计能力却是来源于多年的项目分析、设计经验。 2. UML不是必须的。一个伟大的系统分析师或软件构架师可以不懂UML,但不能没有超强的分析设计能力。不懂UML会使得互相之间直观的交流变得困难,但不一定会影响分析师与构架师的表达和交流能力,如果他们之间使用另一种方式进行交流,或许效果会比UML更好。 3. UML不是一定的。在使用UML建模的时候,并没有一个“绝对正确”或者“绝对错误”的模型,只能说模型的合理或者不合理。例如使用UML来对一个基于两层(Two-layer)结构的学籍管理系统进行建模是完全可以的,但或许使用三层(Three-layer)结构会更加合理。这也充分证明了“系统分析与设计的好坏在于人,而不在于UML”这一结论。 由此可见,我们应该正确对待UML,只有在了解了这些问题后,才能更好地学习、使用UML,让UML更好地服务于我们的分析与设计。
|