软件架构的图形工具


Author: Kimmy

前两天朋友在群里提了一个问题,架构师除了用框图(就是那种大框套小框的所谓架构图)之外还有什么工具(原话是,“架构师不画框框还能画啥”)。

其实所谓的架构图也没有统一的标注,日常流行的那种框图甚至都只是在国内的互联网公司中用的比较多,动不动就三四层,每一层都堆满了小方块,告诉你这一部分是什么,但实际这既没办法表示技术实现层面上的关联关系,也很难确保业务架构上的划分。唯一可能还在用的原因估计就是受众大部分已经接受了“架构图”这样一个概念(实际跟之前我吐槽的“充血模型”类似,是个本地产品),再加上方方正正是我们传统文化所能接纳的基本内容吧。

软件架构是一种无法以简单的一维方式进行说明的复杂实体。 -Paul Clements 《软件架构编档》

架构视图模型

前面提到了,现在比较流行的“架构图”基本上就是个废物,因为起不到任何说明作用,所有的点都需要另外的信息来说明。这种图形能够吸引人无非就是在给人展示说,你看我多厉害,能把这些方块排得整整齐齐。

毕竟一个项目需要非常多的人参与,有各种类型的角色,所以为了能够让这些人分别了解到自己需要的信息,实际是有着不同的视图来展示软件架构。一个典型的归类方式是4+1架构视图模型:

这里的“视图”(view)并非是以图形(diagram)的方式呈现。但4+1架构视图模型会给到我们一个指导,架构设计有哪些可以呈现的部分、以及沟通和展示的方面。而涉及到具体的工具层面,各种图形也可以充分展示不同类型的信息。

软件设计图形的分类

软件设计图形按照用途可以分为描述结构、描述行为和描述交互的三种类型图形。

然而工作中遇到过非常多和同事沟通的场景,对方要么只能使用某一种工具来表达(最多的自然就是时序图,因为大部分人关注细节),要么就是干脆毫无逻辑的画框框和线条。虽然早已经过了1990年代和20世纪初那段疯狂吹OOAD的时代,UML等所谓的设计工具在具体的工作流程中也已经越来越少用了,但使用图形来描述思路依然是一个合格的研发人员必备的能力。无论用来与需求方沟通理清楚业务,还是与其他研发沟通讨论设计思路,使用通用语言来表达都能让沟通的效率和正确性提升。

松散图形

前面说过,上世纪90年代左右,随着面向对象设计的逐渐风靡和软件设计复杂度的提升,有很多老家伙们创造了不少的工具,比如GoF的《设计模式》中使用的OMT,就是James Rumbaugh在通用电气工作的时候创造的方法,后来被Grady Booch和Ivar Jacobson(三人又被称为“The Three Amigos”,Grady Booch是OOAD早期的倡导者,同时也给《设计模式》写了序)挖到了Rational,一起设计了UML。

但是OOAD的整体思路略显庞大,特别在敏捷和精益愈发被重视的今天,作为一个细节设计的方法已经不太适合当前的思路,于是在2010年后就不再太被人常提起,不过好在是给我们留下了不少工具、模式和实践方法。

UML就是OOAD的产物之一,在合并(“unified”)了多个建模工具之后有了这样一个庞然大物。但这种庞然大物必然会导致一个非常高的学习成本,所以也慢慢少有人用了。只剩一些非常直观的图形还有人能够用气。 另外本身UML设计过度复杂,并不是所有的部分都适合使用,Martin Fowler就写过一本小册子《UML精粹》(UML Distilled)来简单讲解一些图形的适用场景和设计思想,非常值得一读。

UML这种庞然大物既然不太受欢迎了,也没多少人真正能看得懂,其实就进一步地有一些不那么严谨但是也能被接受的图形出现了。

其实选择的工具只要是经过团队一致统一的,并不限于具体的展示形式,UML虽然做到了“统一”,但很难统一所有人对于它的认知,所以不如把一些趁手的工具用好。最重要的其实还是要像前面提到的,确定你要沟通的场景和对象,来选择正确的表述内容。

总之不要老是画框框就好。

创建时间:2020-07-14 最近更新时间:2024-07-26