【收藏】宋兴烈：变革前的思索

    上学时，我最不喜欢的就是作文课，作文在我心目中就是“憋文”，憋出来的文章。今天，孟岩约我写篇总结和体会2004年的文章，时间很紧。感觉又开始上作文课 ，“憋”吧…

       一、软件业面临的挑战——适应技术和需求易变性

    荷马在他的史诗中描述了西西弗斯的故事，他必须将一块巨石推上海蒂斯的一座小山，但每当接近山顶时，巨石又会滚下来，因此西西弗斯的苦役用无止境。而当今的IT软件人正是现在版的西西弗斯——面临的是快速变化的技术和越来越复杂的需求。(摘自《应用MDA》)

许多软件业同仁已经察觉到，软件业正站到了一个新的巨大的技术变革的前沿。看看最近炙手可热的技术和标准：面向构件编程、面向方面编程（AOP）、产生式编程（GP）、动态语言、模型驱动架构（MDA）、语义Web（Semantic Web）、Web服务、面向服务架构（SOA）、BPEL等等。事实上，我们已经再一次被大量全新的技术和标准所包围。在诸多的新标准和技术中，究竟那一种方案，会让软件业迎来一次革命性的变革？在这些看似不同的方案中，他们是否有共同的方向？这个共同的、最重要的方向是什么？面对汹涌而来的新标准和新技术浪潮，在变革的前夜，探寻软件技术变革和突破的走向，就是我这一年学习和思索的主题。

    需求推动IT发展，IT发展又刺激新的更大更复杂的需求，这是IT发展的巨大动力源泉。软件业从硬件分化出来那天开始，就面临着适应技术变化和需求变化的挑战。特别是，硬件、网络和通讯的快速发展拉近了时空，以前所未有的速度影响人们的生活、企业的经营和社会的发展，这更使软件业雪上加霜，面临更加严重的危机和挑战。

    正是技术和需求的易变性，导致软件危机，也催生一次又一次的软件业变革。更好的适应技术和需求的易变性既是软件业变革的推动力也是变革的方向和检验标准。

二、迎接挑战——分离模型与实现

       OMG组织以特有的影响力将MDA推到了这场变革的中心。MDA定义了平台无关模型(PIM)、平台相关模型（PSM）和代码以及它们之间的关系。MDA的关键思想包含两部分：模型和驱动，这里的模型是指PIM，驱动的方法是将PIM通过变换工具自动生成平台相关模型（PSM），进一步生成代码。

      PIM的“独立于平台”这个说法有模糊性，容易让人误解。正是因为这一点，PIM遭到业界部分人士（包括知名人士）的质疑，认为PIM根本就不存在，是空中楼阁。我们先来看看《应用MDA》一书中关于PIM的一个小结：

l         PIM更准确的定义应该是“独立于平台的计算模型”。

l         平台独立性是一个相对的说法。当声称某个语言或者模型是独立于平台的，你必须说明独立于哪些平台技术。

l         当前，独立于平台意味着独立于信息格式化技术、3GL、4GL、分布式组件中间件和消息中间件。

这个解释还是不够清晰，我们再看看《解析MDA》中对PIM的描述：

PIM是具有高抽象层次、独立于任何实现技术的模型。

这里指出了“独立于平台”实际上是独立于实现技术。这对我们理解MDA非常重要。

    我的理解，任何软件系统包括模型和实现两部分，模型是对系统的描述，实现是利用特定技术在特定平台或环境中对模型的解释。模型仅仅负责对系统的描述，与实现技术无关。我把这一点称为模型的实现技术无关性。分离模型与实现，这样做具有合理性吗？有什么好处呢？ 是否符合软件业变革的方向和检验标准呢？

    让我们再听听布鲁克斯在《没有银弹》文中的论述：“所有软件活动包括根本任务——打造构成抽象软件实体的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们影射成机器语言” 。

    我把布鲁克斯的根本任务理解为表达模型，次要任务理解为实现模型。分离模型与实现就是分离软件活动中的根本任务与次要任务这两个关注面。模型实现是软件活动的次要任务，当然，这并不是说它不重要。我理解布鲁克斯的观点是根本任务的复杂性远远超过次要任务的复杂性，换句话说，就是次要任务相比根本任务，要容易解决的多。

    在讨论分离的合理性与好处之前，我们先关注模型实现的两种方式。一种是直接执行，就是使用动态执行引擎直接执行，我把这个动态执行引擎称为模型的运行平台；另一种是模型变换，就是把模型变换为更容易执行的目标语言表达的模型，目标语言一般情况是抽象程度更低的语言，这里的变换通常需要变换定义和相应的变换工具。

下面，讨论分离能否迎接软件业面临的挑战——适应技术和需求的易变性。

    首先，模型与实现分离后，能够很好的适应技术易变性。由于实现往往高度依赖特定技术和特定平台，当技术发生迁移时，只需针对这种技术作相应的实现，编写相应的运行平台或变换工具。所以，能够比较好的应对实现技术发展带来的挑战。

    其次，我们看看适应需求易变性方面。模型与实现分离后，应对需求的变更，就是调整模型，然后重新实现即可。看看重新实现的代价，如果模型的实现是采用直接执行方式，我们不需要做任何事情，如果采用模型变换方式，只需重新变换，然后发布实施即可。从这里可以看出，模型的实现是很容易适应需求变化的。分离后，能否适应需求易变性，关键是看模型本身是否比较容易随需而变。如果模型本身不容易改变，则适应需求易变性就是空话。

    举个例子，看看互联网，网站就是一个模型，HTML和URL是这个模型的描述语言，它的实现方式是直接执行，Web服务器和浏览器是运行平台。想想，如果没有Web这种模型和实现分离的手段，而采用3GL编程的模式，现在的Web会是怎样的一种景象。

让我们再看看MDA，MDA的思路分离了模型和实现，这无疑迈出了迎接挑战的最重要的步伐。但是，到目前为止依然有不少质疑MDA方向的声音，这是为什么？MDA在模型表达方面做的工作还远远不够。MDA 的四层模型表达能力虽然比3GL提升不少，但依然不够，很多的业务逻辑无法直接描述，只能用过程型的计算逻辑表达。而OMG组织在MDA的方向重点是模型变换，也就是说，MDA目前的努力依然是在解决次要任务。

    相对于复杂概念结构的模型表达，模型的实现方式是变换还是直接执行并不重要。响应布鲁克斯的呼吁吧，我们是该关注根本任务的时候了。

三、关注根本任务——模型表达

       3GL的问题到底在哪？让我们先做个假设，SOA 时代已经变为现实，整个互联网就像运行着的一个进程，调用远程服务与调用内部方法一样方便。是否就解决布鲁克斯说的根本复杂性了呢？当然还存在问题。

    机器指令、汇编语言、第三代编程语言（包括结构化3GL和面向对象3GL）和网络出现之后的各种RPC（包括CORBA、DCOM、EJB、SOAP等）的发展都是以计算为核心、围绕提升计算平台的抽象层次，其主体是采用过程性表达，用指令告诉计算平台如何做。

       3GL的表达范式不适合用来表达复杂概念结构，不适合用来表达多种多样的模型，不适合用来表达计算无关模型（CIM），导致了软件业的根本困难，使软件业无法应对需求的易变性和复杂性。如何表达这些多种多样的模型呢？

    事实上，由于3GL表达的局限性，已经产生了多种专用的领域表达语言，就我熟悉的企业应用软件领域来看，比如SQL语言、工作流描述语言（XPDL、BPEL、XLANG、WSFL、BPML、WSCI）、规则描述语言、权限描述语言、界面描述语言等等。这些语言的共同特征是表达目标领域比较自然、简洁和表达能力强，而且与实现无关。它们都能比较好的适应技术和需求变化。

    这能给我们什么启发呢？要表达模型，需要用合适的表达语言。当然，通用的模型表达语言并不容易突破，这也许是3GL后的抽象层次提升到现在都不理想的原因吧。但不要悲观，我们看看可能的方向。

    模型表达是知识的表达。知识表达按范式分有说明性（Declarative paradigm）和过程性（Imperative paradigm），按作用分有结构和动态表达。到目前为止，并没有适合计算机处理的统一知识表达手段。但有多种领域、学科在做探索。比如人工智能学科。人工智能中有多种知识表达方式，比如演绎系统、产生式系统、框架结构、语义网络、描述逻辑和过程性知识。这些方式构成了强大的知识表达体系和应用能力，其中有不少在软件中以得到应用，比如目前主流的规则引擎都是采用产生式系统，不少专家推理和知识系统采用一阶谓词逻辑表达。

    我们再看看Web的发展方向。W 3C 明确指出，语义Web是方向，而且已经做了不少工作，取得不少进展。今年刚刚通过OWL（Web Ontology Language）为推荐标准，这为语义Web的发展奠定了坚实的基础。OWL基于描述逻辑（Description Logic），在表达结构和语义方面有其独到之处。最近，根据OWL，OMG也开始定义自己的本体表达语言ODM（Ontology Definition Metamodel）。这些情况表明，形式化的语义表达和推理即将姗姗来迟，这将为模型提供结构方面的形式化语义表达能力。这一点非常重要，因为到目前为止，软件处理的都是弱语义数据。这不但容易引起非常多的不应该产生的错误，而且软件几乎没有语义关联和推理等智能处理能力。

    如何融合声明性和过程性、结构和动态表达方式，形成协调、适合计算机处理、表达能力强和富语义的模型表达体系，甚至统一的模型表达语言，也许是突破根本复杂性的希望所在。

四、希望现代版西西弗斯的苦役早日结束

    面对苦役，我们技术人员应该怎么办？首先，认清各种技术的实质是解决根本问题还是次要问题。其次，深入领域，学习、应用甚至创造特定领域模型表达语言是应对技术和需求易变性的不变之策。