iModel软件观

软件系统是复杂的

    软件世界一直被认为是错综复杂的意识世界，它高度抽象，缺乏可以简化表现的载体；这一认识基于软件构造过程及其工具本身的抽象性和复杂性，同时也基于软件试图表现的现实世界的复杂性；

软件系统是变化的

软件系统是现实世界的抽象表现，而现实世界是不断演进和变化的，所以表现他的软件系统也必须随之变化，否则不变的软件就会随着所反映的客观对象的变化而失去软件的使用价值。

复杂和变化是不可避免的

    软件系统所表现的现实世界是错综复杂的，所以软件系统的复杂性是无法避免的；

    软件系统所表现的现实世界是不断变化的，所以固定不变的软件系统的价值无法长期持续下去的事实也是无法避免的；

软件危机

    越来越庞大的软件规模，越来越复杂的业务规则和不断变化的业务需求与反映迟顿、生产力低下的软件生产之间形成了新的软件危机；传统的软件生产方式已经不能适应这种需求和变化，如果每个项目都是从需求分析开始，经历概要设计、详细设计、编码、测试、发布一系列软件工程步骤，如果每次变化都书写新的变更说明，重做变更设计，对原程序进行变更修改，再编译发布，每次软件变更都是项目负责人的一场恶梦，所谓没项目难，有项目更难。失调的投入产出，不确定风险，质量难于保证，难于维护和扩展是软件行业的现状。

软件的原子

  为了找到现实世界的本质，科学家们不断的探索构成现实世界的最小物质，为了解决软件主要矛盾，我们也必须找到构成软件的原子，只有这样我们才能从根本上解决软件危机，如果我们对软件进行最本质的简化，我们可以发现软件其实具有最为简单的体系构造：

　所有的软件系统都是由两个基本元素组成，数据和规则；软件所做的一切就是，按照指定的规则，对指定的数据进行处理；

所以构建软件就是构建组成软件的数据和规则，面象过程时代的“数据结构+算法”的理念就是这种表现，面象对象的开发方法也一样，对象中包含了数据和规则，其中的事件机制也无非是增加执行规则的时机限定而已；面向服务只不过将抽象层次再次提高，内部依然是由数据和规则构成。

业界的解决办法

    要想让软件随需求变化而变化，则软件必须不能是固定死的代码，OMG在2001年提出的MDA架构就是一种理论上行之有效的解决办法，那就是为软件建模，再根据模型生成对应平台的代码，再编译为可运行的程序，此种方法可以解决软件开发的主要矛盾，我们只需要维护一套与平台无关的模型就可以了，余下的事都交给变换工具去完成，想想确实应该如此，不过现实情况并没有想象中的理想，软件的复杂性和变化性与建模语言的描述和表现力差这个矛盾让这个美好理想在短时间之内很难变为现实；

    另一些企业企图使用一套固定模型来描述和构建软件系统，得到的结果就是要么模型描述能力差而无法构建复杂软件，要么是模型描述基本的软件结构，代码完成复杂的业务规则这样“半自动”的解决方案。

iModel的解决之道

    从软件反映的客观世界是复杂和变化的观点为依据，iModel认为，软件的模型也必须可以是随需而变的模型，模型本身也必须要有可扩展性，可维护性，如何才能做到这点呢？iModel提出了“模型+插件”的解决方案，也就是使用基本模型和插件模型来描述软件，基本模型就是构成软件基本组成要素的模型，如业务元素，字段，业务表，实体，功能，界面等，插件模型是iModel独有的理念，插件模型就是一系列为了扩充基本模型描述能力的可复用的软件组件描述，该组件是用插件技术实现的。

n     iModel的插件不同于一般意义上的插件，它是一种可以带参数的进一步描述基本模型对象的可复用的软件组件，插件可以附着在基本模型对象上（也就是插件的主体对象），插件可以自动响应主体对象的消息并自动完成相关操作，让主体对象满足一定的业务规则或者让主体完成一定的功能。同一个插件可以通过参数调整对不同主体对象进行差异化描述，同一个主体对象也可以用多个插件进行描述。

    这样就可以先使用基本模型描述软件一般的结构和功能，复杂系统再使用插件模型进一步描述，从而解决一套固定模型无法描述复杂系统的问题，插件模型是随时可通过插件参数调整和更换的，可以随着业务需求的变化而方便的更换插件，从而解决了一套软件无法随需而变的问题。