原文连接：http://ieeexplore.ieee.org/xpls/abs_all.jsp?isnumber=30525&arnumber=1407821&count=18&index=4
声明：初涉翻译，纯属业余爱好，有什么不当的地方欢迎大家多多指教，先谢谢啦，这个版本是粗略的翻译版本，
肯定存在大量的错误和不足，会在2天后发一个改进版本：）希望大家监督：）
译文：
后现代时期的软件设计
Translator: Albert Li
近三十多年来，软件设计取得了巨大的进步。但是这种进步并不是持续的：（而是）伴随在某些高原时期间的跳跃前进。例如，在结构化方法及功能分解的高原时代之后，面向对象设计刚刚浮出水面的时期，结构化与面向对象软件设计之间的碰撞跳跃贯穿于整个80年代末90年代初。如今它（面向对象设计）到达了一个上升后的稳定（高原）时期。它逐渐成为主流、法典、并且其中一部分已经以UML的形式标准化。
到达了高原时期并不是负面的，它是为了每一个学科有时间去整合良好的实践、去反省、以及去提出批评来促进进一步的发展。并且胆大的冒进需要一些时间来达到成熟——去“跃过横沟”，如杰弗里.摩尔雄辩地描述的那样，去获得关键大量的从业者跨越我们的工业超越渴望早点收养的阶段。科技、实践、以及方法必须要在学校教授，必须靠工具的支持。它们一定要证明它们的价值超越任何合理的质疑以及有时一些质疑甚至是在一些工业标准里被铭记的事实。所有的这一切都需要时间和努力——因此，这就是这些高原时期的价值所在。
随着时间的过去，当我们开发了更加庞大更加复杂的系统，我们实现的软件设计拥有几层嵌套的层次，这些层次从模块或者类的层次上升到系统或者企业架构层次。那确切的说是在十年前IEEE Software第一次发表它的“软件架构”专题，并且哪个时候依然被Mary Shaw和David Garlan描述为新兴学科。如今软件架构好像已经到达了高原时期，同时它的概念和技术在我们软件的发展中将继续锤炼。
后现代编程
可能我们已经达到了另外一个，被James Noble和Robert Biddle机敏地称作为“后现代编程”的更加基础的高原时期。计算机科学并没有获得一个极其宏大的描述来解释它们所有，那些巨大的图景——我们没有找到一个如同物理基本规律在其他工程学科上所扮演的角色那样的软件的基本规律。我们依然生活在网络泡沫破灭和Y2K问题世界末日所带来痛苦的余味中。因此，在这个好像所有的事情都有一点掌控但并不是真的在掌控之中的后现代时期，软件设计的下一个方向是什么？那里将是下一个高原？
关于软件设计我们应该问我们自己两个问题：我们身处何处？和我们想从这里走向何方？以及甚至可能是，软件设计到底是什么？
我们身在何处？
回答“我们身处何处？”是《导向软件工程知识主体项目》这篇文章的目的之一。Swebok 用广义浅简的观点为软件设计回答了这个问题。在有关这个问题的《IEEE 软件》杂志中，Javie Grzas和Mario Piattini在软件设计知识上走的更加狭义和深入。他们展示了我们怎样能够系统地收获和组织我们这些在软件设计原则和启发、模式、最佳实践，和糟糕的软件味道中捕获到的各式各样的集体的知识、经验，和智慧——使之成为一个连贯的整体。为了做这些，他们为我们提供了一个微型架构的设计知识的存在理论。
另外一篇文章在这个问题上，六个在软件架构概念和建筑学的回顾上的先驱，分享了一些在他们四个公司里的超过800个项目的17年的经验和实践。显然地，建筑学回顾的实践已经很成熟并且证明了他们的价值。
我们从这里走向何方？
Noble和Biddle看到我们前方的“软件开发垃圾堆”。但是这个好像非常特别，并且限定在小型软件开发成果中。软件设计的过程必须被设计地在上游和下游都与其周围的工程进程更好地相适应。我们的（软件）过程并不是天衣无缝的。在上游，用户的需要与我们表达需求的方式是一回事，而我们的设计和设计的方式是另一回事，这其间依旧存在着一个宽广的裂缝。Standish集团的报告使之更加明了：我们软件开发失败的主要原因是我们没有能力去正确地处理用户和他们的变更需要。我们试图去用各种各样的手段来缓解这些——比如说极限编程的现场客户。在下游，我们依旧在努力分析我们的设计，去证明这些设计都是正确的并且他们完成了需求。然而最终，我们的设计与程序员手工编写的代码之间依然存在着裂缝。所有这些裂缝在最近的15年里已经变的窄小了，但是他们依旧是我们软件产业持续地生产伟大软件产品的一个主要障碍。面向方面软件开发可能是在上游和下游中减少裂缝的一个途径。在上游AOSD(面向方面软件开发)提供了一个更加自然的方式来表达某些非功能性的需求。同时，在下游，它或多或少自动地编排合适的代码，减少程序员翻译（[翻译是]典型的一个错误倾向和单调乏味的过程）的需要。我们正计划在明年早期的《IEEE Software》的在关于面向方面软件开发上一个特刊。
模型驱动开发毅然决然地使图减小下游的裂缝。它的目的在于给软件设计人员一个在模型层次上的而不是在代码层次上的表达一个广义语意的途径，并且提供一个自动化的方式来生成令人烦扰的程序。在这个问题上Guy Caplat和Jean-Louis Sourrouille在他们的文章里向我们介绍了模型映射的概念：我们怎样把概念和实体从一个模型转化为另外一个模型——特别是从一个平台无关的模型转化到一个特定平台的模型。同时评判委员会依旧没有一个最佳的方式来生成特定领域语言，这些作者们强烈提倡使用语言扩展（来反对语言修改）。
我们把我们的鼻子贴在我们的蓝图上贴的太近了吗？很多研究者和参与者想要把我们的焦点从设计元素（类、子系统、接口等等）转向设计决定本身。这个更加中心的概念将成为设计牛X软件系统过程中的一等公民，并且特别是在架构化的决定上更是如此。Jeff Tyree和Art Ackerman提供了一个在现有架构化的方法下未能将设计决定作为一级实体的令人信服的问题分析。作者认识到在架构过程中做出的决定的重要性，它是系统开发的和维护的关键所在，并且他们声称我们可以作出系统化的决定并且用一个有用的途径来文档化。管理设计决定可能是端到端追踪（捕获设计基本原理，分析提交的变更影响或者收获可复用的当简单地复用代码不可行时知道怎样办）的关键所在。
软件设计的边界
如果我们进一步缩小需求工程（上游）与编程（下游）之间的缝隙，我们可能会问，什么是软件设计的边界？在这个问题上我的文章里，我暗示我们正在设计甚至在我们不那样称呼它的时候。换句话说，在我们得到或捕获需求的时候或在我们编码和测试的时候，我们就正在做关于当下系统的决定：这就是作设计。因此软件设计是一个比我们通常所想的要宽泛的概念。为了让你信服，我抛出我们在更加普遍的工程框架设计中软件开发的概念，那就是由架构师John Gero所开发的功能-行为-结构框架。
随着一个更加集成更加压缩的过程，软件设计在我们的后现代并没有消亡。虽然银弹依旧如雾里看花般难以琢磨，但是我们在用我们现有的知识建立根基和开拓新的道路上取得了显著的进步。而且其他的工程原理到目前为止也没有找到银弹。
