当我们嘲笑UML的时候,我们应该嘲笑什么

按:上周偶尔谈起UML,想到自己UML、UP(统一过程)的知识有5-6年没更新了,干脆趁没忘光都吐出来。吐槽文,达意第一,术语使用不严谨。

——————————————————-

为了嘲笑UML,我们必须追溯UML的初衷,于是我们必须了解现实世界和软件世界之间天然的隔阂。虽然人们对软件已经习以为常,但是软件的构造并不像其他物理工具的制造那样透明。对软件一无所知的人来说,“编程”一词或多或少包含了“魔法”的成分。

如果对软件的内在机制有所了解,就可以更容易地表达软件与现实之间的鸿沟——即,描述现实世界的自然语言和描述软件世界的机器语言之间的失配(mismatch)。现实世界的需求不能轻易地被机器语言表达,这是鸿沟所在,或者更专业地说,是软件构造复杂度的来源。

一直以来,计算机行业用两种方法降低这种复杂度。第一种方法是对机器语言进行封装——通过引入高级语言、面向对象等概念,使编程语言可以更直接地描述现实世界。

(题外话,这是为什么从数(美)学上看编程语言越来越dirty。因为虽然Lisp很美——美到某本书某页最下方巴掌大的Lisp代码包含了计算的本质,但这种美却不能帮助Lisp更好地描述dirty的现实世界。)

但因为任何编程语言本质上都和图灵机等价,所以编程语言与现实世界的接近程度是有极限的。现存的编程语言依然难以直接描述复杂的现实。

于是计算机行业用第二个办法来弥合现实与软件的隔阂,这就是建模(modelling)——通过建模将现实世界抽象为模型,使现实世界更加清晰精确;编程语言不再直接描述现实世界,而是描述现实世界的模型。

“建模”包含两部分内容:首先是行为(“建”),即如何构造模型的方法;其次是结果(“模”),即作为方法制品的模型。

UML模型是一种用于构造软件的模型,是现实世界和软件世界的有效中介物。UML模型被用来描述现实世界的结构,并保证描述结果和软件结构天然近似。

但UML不是一种建模方法,UML没有定义将现实世界转化为UML模型的建模方法。实际上,使用UML模型的建模方法被称为“Unified Software Development Process(统一软件开发过程,缩写为UP)”。

UP的官方定义语是“用例驱动,以架构为中心,迭代增量的开发过程”。UP以模型为中介,降低软件开发的复杂度,帮助人们更容易地将现实世界的需求转化为软件。UML模型仅仅是UP的制品,而且仅仅是制品中的重要部分。一个未必恰当的比喻:UP是催动UML招式的内功心法。

遗憾的是现实中UP被丢弃、被遗忘、被不为人知。于是产生了各式各样对UML的误用:

– 比如,以为UML用例图就是用例;以为画小人圈圈就描述了需求。实际上,UP中首先要用文档附以领域模型和业务模型描述需求。每个用例都是从需求中抽取,并且是包含参与者、前置条件、后置保证、主要事件流、扩展事件流的完整文字描述。用例图仅仅用来追溯索引用例的图示。

– 比如,以为UML只包含类图;以为类图是银弹;以为使用UML就是画一张事无巨细的类图。其实UP中包含构造系统类图的完整流程方法,这包括:首先抽象现实世界的概念关系构造领域模型类图。而后以用例为中介精化领域类图,从用例中抽取包含新辨识概念关系的分析类图。而分析类图又会在后面的过程中被精化为设计类图,直到被用来指导具体实现。

– 比如,因为各种误用,以为软件开发的复杂性是UML造成的,以为摆脱UML就摆脱了软件开发的复杂性。实际上,软件开发天然复杂。摆脱UML不意味着人们可以用编程语言直接描述(具备一定复杂度的)最终系统。相反人们还是会以“土法炼钢”的方式构造自己的中介物。

此处我也无意为UP布道。不过我想说当我们像上面那样使用UML并造成混乱的时候,我们不应该嘲笑UML,UML应该嘲笑我们,因为我们才是混乱的根源。

当我们嘲笑UML的时候,我们到底应该嘲笑什么?

UML或曰UP的最大问题在于:它们认为模型是解决一切问题的银弹。

实际上以建模来弥平现实与软件的鸿沟,需要经历两个步骤:首先是对现实进行抽象,将现实转化为一种更精确更易理解的模型;第二步则是将模型“具象”到软件世界,即用编程语言实现获得的模型。其中的第一个步骤中,模型作为最终制品很重要;但第二个步骤必须落实到编程语言对软件实现上。

UP没有认清这一点,所以UP没有定义出模型使用的边界,没有给出在抽象过程结束后抛弃模型的时机,也因此没有将注意力集中到编程语言对软件的实现上。相反UP要求对模型不断精化,要求模型不断接近最终的软件。

这导致UML或者更广义建模研究的终极理想成为:通过精化的模型直接生成运行软件,或者更直白地说企图用模型替代编程语言。

然而无论直观感觉,还是多年的研究结果都表明:在企图精确描述软件世界时,模型并不比编程语言更优越——即,在深入到一定细节后,表达等量的内容,模型和编程语言同样复杂(如果前者不是更复杂的话)。

所以以模型替代编程语言的所有努力看上去是注定会失败的。UML是所有这些徒劳无功的形象代言人。

因此,我想,只有当我们看到那些事无巨细的类图、极端精确的时序图,看到那些双向转换模型的纷繁规则,看到那些神似编程语言的“建模语言”时,我们才可以去嘲笑UML。

因为这些多少代表了UML/UP以为自负可以达到,但其实不可能达到的境地。

当我们嘲笑UML的时候,我们应该嘲笑什么》上有3条评论

  1. Pingback引用通告: 当我们嘲笑uml的时候,我们应该嘲笑什么 » Changshan's blog

发表评论

电子邮件地址不会被公开。