软件设计中的“三视图”

在学习机械设计时开始知道了“三视图”的概念：三视图是观测者从三个不同位置观察同一个空间几何体所画出的图形。

三视图已是正确反映物体长宽高尺寸正投影的工程图，在工程设计领域十分有用。

因为现实世界本身是三维的，任何现实世界中的立体物体都必然能被“三视图”正确投影到二维的纸面。

工程师们通过物体的三视图就能重新在头脑中抽象想象出实际物体在三维空间的形态，从而开展正确的建模、实施。

“三视图”对设计师的抽象要求更多是偏向形象思维，从三维向二维的互换是一种空间变化的形象思维而非逻辑思维。

如果读过科幻小说《三体》中关于“二向箔”的描述，大概就会对三维向二维转换产生一种直观、模糊的理解，而“三视图”对这种转换的描述是极其精确的。

形象思维抽象能力高低在一定层面上表现了工业设计领域悟性的高低，擅长者和不擅长者差距明显。

但在软件设计领域，和传统的工程设计领域有较大的不同，没有任何精确的视图描述能正确表达软件作品的最终形态。

传统工程设计领域的设计范围总是在三维和二维之间转换，这两个维度都是我们现实生活中能直观感受、触碰到的，相对容易理解。

也没有设计师会去设计一个四维的物体（如何去想象一个四维物体呢？）《三体》中曾细致描述过一个四维的气泡空间，但那只存在与科幻中，现实中我们没法设计出来。

软件设计领域则不然，软件不太容易被直观的感受和触碰，因此无论是软件设计师还是软件最终用户对软件作品的理解都困难的多。

软件作品总是多维的，一般情况也总是大于三维的，事实是软件设计和其他设计属于两种不同的基本思维领域。

形象思维设计领域直观、与现实维度接近易于理解。软件设计属于逻辑思维设计领域，与现实维度无关，它的抽象维度只存在于思想空间中。

不同软件作品拥有不同数量的抽象维度，这是软件设计复杂性的一种体现。

在上世纪90年代，诞生了UML（统一建模语言）一种涵盖软件设计开发所有阶段的模型化和可视化支持的建模语言。

从UML的出现中我们就可以知道，软件先驱们在不懈的努力来使软件设计从不可直观感受触摸的抽象思维空间向现实空间进行投影。

这是一种非常类似于传统工程设计领域“三视图”的尝试，但却又远远没有达到“三视图”的精确度。

无论是用例图、交互图、活动图、状态图、序列图、流程图、架构图，它们都在不同的方面模糊的反映了软件作品的最终形态，却又无法真正清晰的描述，总是雾里看花。

因此，软件工程设计领域中的方法论非常多，无论是早期的瀑布到敏捷、极限、领域驱动设计还是SOA（面向服务架构）都是为了解决软件设计领域实施复杂度的问题。

实施的难度在于目标的模糊，软件设计不像建筑设计，施工前我们有标准的工程图纸、国际标准、样本蓝图、比例缩微模型。

要说和建筑设计貌似唯一有个相似处就是概念图（想象买房子前看到广告上的那个概念图，和实际得到的房子），实际软件成品比之其概念图的差距可能还远远超过房子。

软件工程是一门研究用工程化方法构建和维护有效地、实用的和高质量软件的学科。

其目标是开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并且满足用户需求的软件产品。

其研究方向是如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，其目标重点在过程化方法，如何找到一种过程化方法来实现其目标。

在这个领域学习实践近十年之后，突然领悟到也许一开始从其他工程学科借鉴来的方法都是错误的，削足适履，软件工程正是歧路亡羊。

正如前文所述，软件设计的抽象维度只存在于思想空间中，而且维度远远高于现实世界的三维，从传统工程学科借鉴来三维方法学解决不了另一种空间中的高维度问题。

至于，正确的道路在哪里，还不知道，停下来想一想也好过在错误的道路上越走越远。