元结构系统框架基本介绍

“元结构”系统平台框架基本介绍

2008-06-18

“元结构”系统平台框架基本介绍

目    录

1目前系统平台框架的技术定位（特征）... 3

1.1应用系统的界定... 3

1.2应用系统的主要特征... 3

1.3 系统平台框架的主要技术特征... 4

1.3.1系统平台框架的基本结构... 4

1.3.2系统平台框架可能涉及的主要概念... 5

1.3.3界面（用户界面）的结构化描述（元结构思想）... 6

1.3.4用户组织结构在系统设计中的地位... 8

1.3.5事件的应用... 8

1.3.6控制解释的概念... 8

1.3.7动态模型应用... 8

1.3.8系统控制信息流与信息（数据）的定位... 9

1.3.9系统应用权限的粒度进一步细化... 9

1.3.10系统拓展的方法... 9

1.3.11版本的概念的拓展... 10

1.3.12系统的可溯性定义... 10

1.3.13系统可持续升级的基本特征... 10

1.3.14应对系统变化的对策... 10

2系统框架可能的发展及解决的主要技术特征... 10

“元结构”系统平台框架基本思想概要说明

1目前系统平台框架的技术定位（特征）

1.1应用系统的界定

这里讲的应用系统主要是指利用IT（计算机等相关技术）技术实现的企业管理信息系统（一般意义下的MIS，ERP等）。应用系统是企业管理思想的载体或体现的一种工具。信息处理能力、方式是IT技术的强势能力。

1.2应用系统的主要特征

应用系统的变化表现在以下几个方面：

（1）       空间特性

    空间特性是指对应用对象而言，不同的应用对象即使是同一业务的应用也是不同的特点。表现了应用对象的应用多样性。多样性也是系统复杂性的一个表现。

（2）       时间特性

时间特性即是说在同一应用对象在不同的时间具有不同的要求。也就是说系统将随着时间推移而发生变化。这一特性是由市场竞争和管理者的认知所决定的。

从上面两个基本的因素来看，应用系统的变化和复杂性是应用系统的基本特征。

1.3 系统平台框架的主要技术特征

1.3.1系统平台框架的基本结构

用 户 的 业 务 应 用 系 统

1.3.2系统平台框架可能涉及的主要概念

在元结构系统框架的开发过程中涉及到较多的概念，这些概念的理解和应用是系统框架开发过程中十分重要的。目前我们对一些概念的定义还处于一个认识的阶段，有些概念比较难以定义（借用的一些名词可能更会存在问题）。对于平台的使用者可以不理睬这些概念，但如果理解了这些概念对设计和应用是有益的。

序号

概念

基本解释

01

生命周期

02

场景

03

场景变换与生命周期

04

条件（已知与未知）

05

条件的获取与方式

06

互动

07

数据

08

数据组织

09

数据处理

10

数据表现

11

数据映射

12

变化（不存在变化）〕

13

多样性

14

结构

15

元结构

16

元素

17

节点

18

事件

19

函数

20

描述与控制

21

复用与复用的对象

22

拓展与资源的引用

23

控制解释

24

业务

25

业务流程

26

业务实例化

27

流程的逻辑表达

28

流程的载体（规则的描述与控制

29

模糊控制

30

资源

31

开发权限

32

流程权限

33

业务操作权限

34

资源监控与管理

35

属性

36

行为属性（动态属性）

37

自然属性（静态属性）

38

从上到下的分析方法

39

从下到上的分析方法

40

二者结合的分析方法

41

递归算法

42

抽象的理解

43

模型

44

模型驱动

45

驱动模型

46

依赖

47

抽象与依赖

48

耦合

1.3.3界面（用户界面）的结构化描述（元结构思想）

系统的多样性和系统的复杂性，表明了系统描述的困难，同时系统生命力的表现，在某种意义上讲系统失去了多样性和复杂性系统的生命力将不复存在。

目前的基本做法是通过模版的方式来提升开发的效率。无论是代码级的重用还是更大粒度的复用。这种方法的前提是业务的理解与业务的浏览（或学习）量要足够的多。很多公司号称研究了数十万企业的管理业务及其流程，通过系统的业务抽象形成预置模版。包括SAP、普元、金蝶、用友本质上都是依据这样的思想，无论是动态配置还是静态配置或组件（构件）技术或目前的所谓SOA思想的实现。但目前所有厂商开始在SOA的思想下寻求新的方法，包括用友推出的A8（A6后为什么急于推A8 值得去研究一下。）、U9（号称世界级的世界上第一款基于SOA的应用开发平台）等。同样，金碟推出的OperaMasks也是一种尝试，尽管其号称“世界上最好的WEB开发框架。基本的估计是大家还在路上，谁都没有绝对的优势。

元结构的思想是期望通过将页面（业务表现）的多样性，通过元结构的方式进行描述、控制与管理。主要包括属性、结构、元素、数据、场景、数据组织、交换映射、事件等概念。

实际上，是采用了不依赖于业务表现的业务表现技术。从理论上讲，这种方法可以构建极其复杂的业务表现，而这种表现的实现工具是不依赖于任何的具体的业务表现，一句话，方法与业务无关。

我们目前所完成的主要工作（简要表明）：

1、系统平台主要功能列表：

2、 开发界面：、

（1）系统应用开发界面

事件（组件）

（2）单据模式开发界面

（3）工作流设计

3、各个部分功能详细说明略。

1.3.4用户组织结构在系统设计中的地位

如果构建的信息系统能够持续改进，用户的组织结构在系统的位置将发生前所未有的变化或重要性的提升。

主要的解决的问题是在企业管理演变中组织结构重组和业务重组给系统带来的变化问题。她的核心表现在系统的权限方面，但其基本的控制点在组织结构的管理。从另一个角度讲，应用系统的功能作为一种资源在企业生命周期内的运动变化，同样，资源是存在生命周期的，包括整体的生命周期和业务（资源实例化）一次过程的生命周期。

1.3.5事件的应用

   页面的表现我们试图通过元结构控制与管理的方式进行实现，但它只是业务的展现（表现）层面的东西，可能构不成业务的完全表现。事件的应用正是为了弥补这点的不足。事件的应用仍然是元结构思想的运用。

   事件的运用全面支持了系统的拓展和业务表现的复杂性要求。

1.3.6控制解释的概念

一般的方法是通过对各类CASE 的总结在系统形成一定的规则判断，一般以IF判断的形式出现。这种方式一般来说是有限情况的总结，应用比较“死”。

现在我们采用规则描述和规则组合的方式进行应用，通过系统“控制解释”引擎“翻译进行控制。适应的变化将更多，不是可数的CASE。

这种抽象的方法贯穿整个的设计之中。

1.3.7动态模型应用

动态模型的应用大体是元模型的应用。通过各个元模型构建一个新的模型，这个模型的描述是逻辑的，只有在实例化后成为一个真正的实例化业务应用模型。它基本的技术支撑是“控制解释“引擎的作用。

业务展现元结架模型

应用”元结构”的第一步是建立系统具体业务展现的“元结构”，业务展现的元结构是业务变化的根据和基础，它定义了业务变化的方式或获取信息交换的形式，在这个过程中业务过程被描述为"黑箱"，这里，黑箱定义了在不考虑具体怎样做的情况下，在这个阶段应当做些什么，功能模型的主要目的有：

(1)建立系统业务展现的基本“元结构”，通过系统提供的“业务展现框架模型”与开发人员的可视化交互来完成。也就是建立系统业务功能的展现方式，例如：信息字段的显示方式、排列等，它是业务表现的静态影像。

(2)根据业务的展现模型也就是业务表现的静态影像指导管理人员和咨询人员之间的对话(信息交流)。求证信息点正确性及信息流的方向与业务的处理方式。

(3)在上述分析的基础上，进一步确定业务的表达方式，为下一步的业务过程处理方式的进行建立基础。

业务行为属性元结构（功能过程）模型

业务行为元结构（功能过程）模型控制描述了具体业务功能的实现过程或者说是系统业务功能实现的目标。这是系统最低层次的业务行为（功能）建模过程。

（1）通过对业务过程的描述来实现业务功能的表现。业务过程的描述不完全是用户层面理解的业务过程，而是实现业务表现的信息处理与控制的过程。是用户需求的微观的、具体的信息表现的描述。

（2）通过“事件”的组合（根据业务实际的需要）来具体实现业务的过程，也就是建立生成目标用户环境(END-USER ENVIRONMENT)的过程。业务实现的用户环境。

（3）“事件”是业务引用的最小工作单元集合。“事件”的是通过可视化描述来完成的。

（4）建立目标用户环境（业务实例化过程）

业务组织元结构模型

业务组织模型是系统工作流和权限系统的一部分。业务组织模型根据分工、业务单元和部门（岗位）来描述组织结构，关键问题之一是组织中作用的识别。这里，作用指在过程执行中按惯例分配给某一个特定的人或工作组的行为或任务。模型的另一个特点是可以规定模型中不同组成部分之间的级别和功能关系。

1.3.8系统控制信息流与信息（数据）的定位

应用系统的信息控制不是应用系统业务层面的信息(数据)的控制。主要包括：组织结构变化的影响、权限信息、流程信息、版本信息、实例数据信息还包括信息协同的信息等。这些控制尽管某些厂家已经关注到，但目前为止我们还没有看到真正实现这些控制的报道。

1.3.9系统应用权限的粒度进一步细化

从以功能作为权限的控制粒度向单元行或列的信息单元控制粒度过渡，或其他更为细致的控制粒度。实现上述功能的前提是表现的结构化和可控性的实现。

1.3.10系统拓展的方法

通过“事件“形式进行系统拓展。“事件”形式的拓展，在某种程度上讲要方便“组件”形式。而且，我们的“事件”是解决一类“事情”，而实现与具体的“事情”无关，目前来看我们的“事件”的实现与表现方式比“组件”形式要“软性”一些。拓展的空间更大，“事件”是复用的，而“组件”可能其与系统整体结构有关，其“刚性”更强。

1.3.11版本的概念的拓展

由于结构的存在，系统的多个版本可以存在并通过“激活“与“时间”的方式加以引用。

1.3.12系统的可溯性定义

由于结构和版本的存在系统存在可溯性。

1.3.13系统可持续升级的基本特征

事件的应用、其它组件的集成。

1.3.14应对系统变化的对策

主要的含义：

1、  系统适应新的项目，重用程度高；

2、  系统应用发生变化，能够快速应对；

3、  远程平台性开发。

2系统框架可能的发展及解决的主要技术特征

1、  开发和部署平台的统一性

2、  开发和开发管理平台的统一性

3、  系统与客户服务管理的同一性