[测试]可执行模型

    1.1  模型的概念
    模型从广义角度来讲是对一个应用系统的描述，比如说描述一个进销存系统等等

    例：所有进销存系统需要的一切细节都称为模型的一部分，比如 流程，界面，数据等。

    总之模型是一个广义概念，在这里叙述的模型涵盖了应用系统中所有要求的细节

    计算机系统直接运行这个模型来满足客户的要求称之为可执行模型。

    1.2  计算机开发的进化：
    代码数据混合 -> 结构化和文件出现 -> 面向对象和数据库的出现 -> 对象关系映射，持久化，框架的出现

    MDA 模型驱动法 -> 模型运行 -> 人即计算机

    第一部分是传统开发的进化过程

    第二部分是现代和未来开发的进化过程

    想象一下，为什么要有 j2ee ，为什么要有 Struts ，为什么要有数据库？ 这些其实与用户的业务并没有 什么关系 ，说到底计算机只是一个工具，用来解决现实问题 ，这样说好象是把计算机的地位下降了，其实不然，是揭示了计算机真正的地位，软件系统就是业务系统的一层皮，所有我们现在熟悉的开发方法，语言之类都是临时的，最终随着大型软件的越来越多，开发方法越来越先进，程序员最先会失业，然后沦为技术支持一类，就象电梯管理员

    我想这个可执行模型就是来实现这一目的

    1.3  描述模型
    1.3.1  业务模型描述，与平台无关
    对模型描述有很多种方法，如 uml ， script ，自定义图，工作流图等 , 基本上可分为 图、表格、脚本、文字，对模型有用的基本上前三种

    文字描述基本上没用，因为除非人工智能有大发展，否则自然语言计算机是没办法懂的，最流行的肯定是 uml 图 ，基本上 uml 图可以做到描述很多东西了，粗的结构，功能，甚至流程 ，对象等。所以说比较一个应用系统大方面的描述基本上用 uml 足够了

    剩下的就象有人说的“我们只关心细节”，其实细节才是模型描述中的难点，重点 ，因为我们现在要运行模型，那么我们想要计算机系统做的或呈现的信息，显然都需要写入模型描述 ，而且要计算机系统能看懂的，那么细节有很多方面，比如 复杂的流程，复杂的域逻辑，复杂的 UI 用户交互 ，那么图显然不可能完成所有的，至少 uml 图是不行的 ，因为从人的习惯上来讲，脚本描述即接近语言的描述是有存在必要 ，虽然可以扩展 uml 图来满足模型的所有描述，但是脚本的信息归纳程度要远高于图 ，就好象为什么人类用文字进化图形 ，所以脚本的描述肯定也会存在，但是可以用图形主导的方式

    总之模型的描述，主要指的是业务模型描述，包括 各种细节。可以以图为中心，脚本语言为辅助来进行描述

    1.3.2  计算机呈现描述，计算机特殊输入描述。
    除业务之外，计算机中特殊的描述也是模型描述的一部分，主要是两类：呈现和输入， 也即 I/O ，这里指的是与人工的交互

    因为这些描述与业务是无关的，其实是因为引入计算机才引起的，所以要特殊描述，而且需要技术人员的参与 ，比方说显然目前的计算机系统对泡茶还是没什么研究的，那么技术人员要阻止这样的描述，比如 CRT 和液晶的不同 ，显卡的不同 ，比如屏幕有多大，另外模板、风格等 应该放入模型 ，因为从计算机应用系统角度来讲是一个不可分割的部分 ，因为模型毕竟还是描述计算机应用系统的

    只是其中分为两部分：业务描述和计算机描述。

    1.3.3  可视化设计
    可视化设计是模型能顺利描述的保障，也是推广模型和运行模型强有力的工具，就象 jbuilder 推动了 j2ee 一样，当然这不是必须，但是成功的必选

    1.4  执行模型
    模型可以描述，那么至少一半以上的工作完成了，接下来另一半的工作是执行

    1.4.1  执行方式
    一种方法：源代码、中间码或本地码生成，执行

    另一种方法：直接解释执行

    这两种方法其实差别不算大，但是由于计算机软件系统本身的巨大差别，特别是细节的巨大差别，想以一种单一模型在任何地方都可以运行，其中兼容性的问题必须解决。

    任何一种业务描述都可能产生平台问题，比如： tree 这个控件在 windows 中有的，但 aix 中没有，所以 sun 是自己在 aix 中写了一个控件才做到跨平台， 象呈现方面还算好的，如果是事件方面可能更糟，比如有某种特殊系统中不支持某种事件，那么可能是灾难，解决这类问题有时候可以取巧，比如说用 java 来解决服务端的跨平台，用 browser 来解决 ui 的跨平台，但是要注意这个模型其实是不限于 b/s 结构的，其描述广泛到了所有的计算机系统，特殊结构是非常需要花大量成本来实现的，甚至可能不放入兼容列表中，现在我的目标是仅限于 b/s 结构，已经很麻烦了

    现在再来说一下这两种方法为什么本质是相同的，源代码、中间码或本地码是将模型转为另一种描述，然后执行交由另一个运行器去运行，也可以理解为一种解释，只是解释的方法有点不同

    当然分开还有一些必要，至少在开发中有很大的意义，那么运行模型最大问题在于如何真实地解释这个模型的描述，假定要求下降到了特定平台上

    对模型描述的计算机呈现必须要有这几个要素：将模型描述解析和构造成中间临时对象，将这些对象串起来放在合适的预先配置好的框架上，启动和停止，也就是 build -> place -> start and stop ，引入框架就是 减少执行模型的工作量，解析显然是为了放置而做准备

    举个例子：

    模型中提到的数据显然要放入 orm 中，例如 hibernate 或 ejb ，流程放入 workflow engine ，服务放入 session bean 或 spring ，这是基本要素，但不仅仅是这些 ， build -> place -> start and stop

    兼容、优化、部署、管理 也是必须的

    这一章说了模型运行器需要包括的要素，和运行的方式

    1.5  成功的要点
    1.5.1  应用，丰富的行业应用及各种业务应用
    应用必须放在第一条，有大量应用支撑的软件不会死，即使有多烂

    1.5.2  可视化的集成环境，对象是业务专家，普通 office 应用者。
    这个难度非常高，要让普通的 officer 来用必须要相当地人性化

    1.5.3  兼容多种计算机环境，数据库、应用服务器、集群、外部系统接口。有良好地伸缩性。
    这个又是很头疼的事，光兼容性一项就足以让一个百人公司专注考虑两年以上

    1.5.4  支持多种软件厂商集成。
    这个市场推扩的支持，显然更多的集成更不容易死，其实是在扩展第一点。

    最后希望这些成功要素能给真正实现产品的人以启迪