观辰技术原理

观辰零代码智能软件平台是元模型驱动的构件平台，脱胎于面向构件的技术思想，在提高生产力和增强业务应变能力方面具有明显的技术优势。开放式架构（开放式插件架构、开放式元模型架构、开放式构件架构）是观辰平台的设计理念，将所有与业务相关的部分视为扩展点，平台提供对扩展点的自动发现和查找机制。除了一个微内核外，平台所有的功能都是通过插件对扩展点扩展的方式实现，这意味着整个平台具有很强的扩展能力。

针对构件工厂遇到的难题，观辰平台提出了一套体系完备的解决方案，并已收到了良好的效果，总结起来就是四大技术要点：平台一体化、元模型驱动、零代码和最短设计路径。通过平台一体化可以从源头消除生产环境与运行环境的差异；采用元模型驱动可以为构件提供丰富的业务描述；零代码装配构件方式可以极大降低构件装配的技术门槛，使得批量生产成为可能；最短设计路径则可以让构件装配更有效率。下面针对这四大技术要点分别进行阐述：

平台一体化

平台一体化可分为平台化和一体化两个方面来阐述。观辰平台首先是一个运行时（Runtime）平台，所有构件运行在观辰平台运行时之上，这种运行机制具有诸多好处。首先平台运行时为构件提供了很多基础支撑，开发构件可以利用这些基础支撑来减少开发工作量。其次所有构件都由平台运行时统一管理，可以方便地实现一些全局性的功能，如：全局调优、运行监控、动作侦听等等。另外平台运行时还可以为构件间的通讯提供中介服务。

一体化是指平台不仅仅是运行平台，同时还是设计平台，这一点是观辰平台的独特优势。运行和设计一体化的方式从源头上拉近了应用与需求的距离，有效解决应用与需求脱节的问题。一体化机制使得在设计时也可以获得构件的运行时信息，并采用这些信息来辅助设计。一体化的一个具体体现就是观辰平台没有采用专门的开发工具，直接使用浏览器完成从设计到使用的全部工作。在应用试运行阶段，一体化方式可以快速响应调整，应用时如果产生了调整需求，设计人员可以直接在应用界面进行调整。

元模型驱动

元模型也可称为元数据模型，其作用主要有两个：一是为构件提供控制数据；二是为构件间的交互提供共同规范。观辰平台提供了开放式的元模型架构和统一的元数据管理，这主要是为了弥补纯构件式架构的不足。在没有一套相对统一的元模型的情况下，每个构件都必须定义一套自有的元模型，一来开发工作量很大，再者构件间的交互也是一个难题。

采用统一的元模型需要特别考虑灵活性和扩展性，为此观辰平台采用了开放式元模型架构，体现在元模型全部通过可自由插拔的插件方式挂入平台，这样就可以自行扩展需要的元模型。 统一的元模型也使得平台能够实现一些全局性的功能，如：设计文档自动生成、整体性能调优、元数据包导入导出、自动辅助测试等等。

零代码

零代码指的是一种表象，本质的含义是采用彻底的封装，屏蔽与业务无关的技术细节。纵观计算机语言的发展历史，从汇编语言到高级语言再到面向对象语言，一直朝着符合人类思维模式的方向演化。每一种成功的语言都做到了对低级语言相对完整的封装，比如使用Java语言编程时，并不要求同时使用汇编语言或C语言。

对于构件平台而言，元模型就是构件平台使用的领域语言（DSL），是相对于面向对象语言更高层的语言。描述构件行为以及粘合构件等工作都应使用元模型来完成，其中粘合构件是构件装配的主要工作，如果仍使用细粒度的低层语言粘合构件，效率和质量都很难得到保证。其次如果采用低层语言粘合构件，即便只是少量的代码，也使得构件装配人员必须掌握很多底层语言编程细节。另外需要关注的是，使用代码粘合构件时，构件装配者需要在业务场景和编程场景之间频繁进行切换，这同样也会带来很大的生产开销。

但零代码一直是构件平台的难题，其难点在于应用的不确定性，一种业务模式下适合的元模型放到另一种业务模式下可能就不再适合。从逻辑上分析也不可能存在一种适应所有业务模式的万能元模型，要解决元模型与应用间的矛盾，应从产生元模型的源头入手，让元模型能够随着应用的变化而不断演化。观辰平台就是在开放式的元模型架构下，实现了大量的基础元模型，做到了完全使用元模型来进行构件化生产；如果现有元模型无法满足新的业务模式需求，可以通过插件方式扩展元模型和构件，且插件完全可以由第三方开发商来开发完成，并不需要平台厂商的介入。

最短设计路径

最短设计路径体现对生产效率的重视，尽可能减少使用构件装配应用时需要进行的上下文切换动作。在整个设计中尽量减少层次，去掉不必要的中间环节。在观辰平台的现有元模型中，几乎所有的元模型都具有业务含义，这样使用者就可以直接使用元模型来描述实际业务，当业务描述完成，元模型也就同时完成。在传统开发中设计和实现需要分为两个步骤进行，而在观辰平台上仅需要设计元模型一个步骤即可，平台会自动将设计的元模型转换为实际的应用功能。

在元模型设计上遵循最短设计路径，元模型是对实际应用的逐层抽象，通过对构件使用人员的实际使用情况分析得出，元模型的抽象层次深度问题以及元模型与业务的关联度问题都会对构件使用人员正确理解模型产生直接影响。调查发现人们通常很容易理解带业务概念的元模型，而很难理解纯技术概念的元模型，特别是一层以上的纯技术概念的元模型。

设定U（Understanding）为构件使用人员对模型理解程度，BM（Business Model）为业务元模型的理解程度，TM（Technical Model）为纯技术元模型的理解程度，PI（Personal Intellect）为人的理解力，则有如下公式：

从上面的公式可以得出，元模型的抽象层次对模型理解程度的影响最大。同时构件人员对业务元模型（BM）的理解程度通常能达到90%以上，而对纯技术元模型的理解程度平均只有50%左右，所以要尽量避免引入纯技术元模型，即使必须引用纯技术元模型，抽象层次也不要超过一层。

最短设计路径也体现在生产工具的人机交互设计上，在基于观辰平台搭建应用过程中，往往只需要一步操作，就可以从应用前端到达设计界面。同时由于平台一体化的优势，在设计的每一步变化都会直接体现在实际运行中，无需经过中间过程（注：许多平台往往需要经过一个编译或发布的过程）。