发明内容
本发明的目的是提供一种信息处理装置,确保各种功能比较容易的用户化、更新和修改,而不需要对软件或电路结构做任何重大的修改。
为了实现上述的和其他的有关目的至少一部分,本发明由一种具有下文所讨论的第一种结构的信息处理装置来说明。信息处理装置具有多个基本功能模块,实现预定的基本功能。这些基本功能模块是被作为独立的元件构建的,并可以通过软件或硬件方式,例如,以电子电路的形式,加以实现。独立元件的安排使增加新模块和替换已有模块相对地容易。
在本发明的信息处理装置中,处理的技术要求是通过一个电子文件确定的。电子文件在多个基本功能模块中确定用于进行处理的基本功能模块。信息处理装置输入这个电子文件、分析电子文件并根据对电子文件的分析结果执行处理。由电子文件指定的基本功能模块顺序地启动去执行处理过程。
为了实现不同的处理过程的序列,本发明的信息处理装置具有按照电子文件的技术要求调用所要求的基本功能模块的多用途功能。通过一种基本功能模块的组合而执行的处理过程的实质的技术要求是在电子文件中被定义的。这个方案通过简单地改变一个外部给予的电子文件的内容保证信息处理功能的增加、修改和用户化,而不需要对信息处理装置的任何软件配置或硬件结构做重大的修改。
在本发明的信息处理装置中,基本功能模块的组合和电子文件一起完成下面讨论的不同的功能。
在本发明的第一种优先应用中,多个基本功能模块包括一个视窗生成模块,用来产生一个在信息处理装置上显示的视窗。电子文档定义视窗的一个技术规范和一个产生定时。信息处理装置在指定的产生定时启动视窗生成模块生成一个视窗。在信息处理装置中,这个方案使一个界面视窗或需要的任何其他的视窗能够在任意设定的时间显示出来。
在本发明的第二种优先应用中,电子文档包括确定处理过程的多种序列的一个执行顺序的流控制信息。信息处理装置以按照流控制信息的执行顺序启动基本功能模块。这个应用的方案被用来处理一个复杂的流,比如一个循环或条件转移。流控制信息通过信息处理装置加以翻译并被加入电子文档中。
本发明的第三种优先应用中,多个基本功能模块包括一系列组件显示模块。组件显示模块分别地表示构成视窗的显示组件,比如行、按钮和文本。电子文档定义构成视窗的各个显示组件的类型和位置。信息处理装置根据电子文档启动各自的组件显示模块,以便生成由电子文档定义的视窗。通过简单地修改电子文档的内容,比较容易地产生不同的视窗。
第三种应用的方案可以和第一种应用的方案相结合。即第一种应用的视窗生成模块可以发挥在第三种应用中的读出电子文档并启动各自的组件显示模块的功能。这种结合保证不同视窗的生成,同时自由地调整每个视窗的产生定时和视窗的转换。
在本发明的第四种优先应用中,多个的基本功能模块包括一系列组件操作模块。组件操作模块对输入到信息处理装置中的数据执行预先确定的操作,比如四种运算操作。电子文档定义数据的一种操作。信息处理装置根据电子文档启动各自的组件操作模块,以便执行对数据的操作。通过简单地修改电子文档的内容,比较容易地执行不同的操作。
为了达到上文的和其他的以前提及的有关目的至少一部分,本发明的信息处理装置可以包含一种下文所讨论的第二种结构。类似第一种结构,第二种结构具有多个的基本功能模块。在第二种结构中,每个基本功能模块响应对象的状态的一个变化被启动,对象的状态已经被预先映射到基本功能模块。第二种结构的信息处理装置管理这些对象和这些对象与各自的基本功能模块之间的映射关系。响应对象的一个状态变化,信息处理装置通知映射到状态发生变化的对象的基本功能模块。
这个方案使各自的基本功能模块的同步地启动比较容易实现,并且保证增加新的基本功能模块和替换已有的基本功能模块时,不需要对信息处理装置的任何软件或硬件做重大的修改。映射到基本功能模块的对象的使用保证了基本功能模块的增加和替换的正常操作。
为了控制一系列基本功能模块的连续启动,最好使每个基本功能模块具有在一个确定的对象上反映启动结果的功能。在一个实例中,一个第一基本功能模块和一个第二基本功能模块被顺序地启动。通过一个第一对象启动第一基本功能模块,并通过一个第二对象启动第二基本功能模块。第一基本功能模块具有在第二对象上反映启动结果的功能。则第一基本功能模块的启动容易地激发第二基本功能模块的启动。
在第二种结构的信息处理装置中,其中多个的基本功能模块包括一系列组件显示模块,一个优先的应用在涉及一个当前显示的视窗的对象中分别地管理为多个的视窗所共有的对象。在当前视窗变化为另一个视窗之后,后一个对象可能被从所管理的对象中删去。然而,不管视窗如何变化,前一个对象都是被存储的。分别地管理这些对象保证平滑地控制屏幕的显示。
在一个关于具有第二种结构的信息处理装置的优先应用中,每个基本功能模块注册一个到对象的映射。基本功能模块与对象之间的映射是按照基本功能模块的启动状态和启动的可能性被动态地注册的。这个方案有利地减轻了对基本功能模块的正常操作所要求的映射的管理负担。
在第二种结构的信息处理装置中,对应于每个基本功能模块的启动,一个优先应用建立一个映射到基本功能模块的对象,同时消除一个没有映射到任何已启动的基本功能模块的对象。这个方案能够按照基本功能模块的启动状态对对象进行所希望的建立和消除。这保证了对象的管理,同时有效地利用资源,例如存储资源。
为了达到上文的最起码的作用和其他的以前提及的有关目的,本发明的信息处理装置可能具有下文中讨论的一种第三种结构。第三种结构的信息处理装置被连接到一个网络上,并根据经过网络传输的信息执行一个预先确定的处理序列。第三种结构的信息处理装置存储被包括在一个经过网络传输的电子信息中的数据和一个定义数据格式的定义文档,分析定义文档,并根据对定义文档的分析建立或译码电子信息。通过定义文档定义所建立的电子信息的实质的规格说明。信息处理装置因此被要求具有按照定义文档建立电子信息的综合功能。第三种结构的方案通过简单地修改定义文档使建立和译码不同的电子信息相对地容易。
在一个优先应用中,第三种结构的信息处理装置具有一个数据管理模块,用来全面地管理与预先确定的处理序列有关的多个的数据。信息处理装置从数据管理模块取出被包括在所传输的电子信息中的数据,或通知数据管理模块从接收到的电子信息中提取的数据。这种方案保证了数据在信息信息处理装置与外部之间通过电子信息平滑地传送。
第三种结构可能使用一个或多个定义文档。在使用多个定义文档的情况下,电子信息可能指定使用一个或多个定义文档。这种方案保证了对多个定义文档的选择性使用。它不要求电子文档一对一的映射到定义文档。例如,电子文档按照条件转移的结果可能使用不同的定义文档。
上面讨论的第一到第三种结构可能被单独地或以组合的方式应用于信息处理装置。第一和第二种结构可能被应用于一个孤立的信息处理装置或一个连接到一个网络的信息处理装置。
由本发明的信息处理装置执行的处理的规范可能被任意的设定。有效地利用本发明的原理的一个有利的例子是图形数据处理。即本发明亦被用来控制一个信息处理装置,根据一个表格的图形数据完成图形处理的一个预定的序列。
图形处理装置具有多个基本功能模块,实现图形处理的预定序列的预定基本功能。电子文档以一种用于图形处理的基本功能模块能够识别的格式定义图形处理的技术要求。图形处理装置分析电子文档并顺序地启动通过分析电子文档而确定的基本功能模块,以便实现图形处理。有大量的各种各样的表格应用在会计软件中,并且有各种的相关数据处理序列。本发明原理的应用可以有利地减轻每个金融机构的图形处理装置用户化的负担。
在本发明的图形处理装置的一种优先应用中,多基本功能模块包括一个数据提取模块,用于从图形数据中提取符号数据或数值数据。电子文档指定在图形数据中进行提取的区域和所提取数据的属性。图形处理装置从而获得由电子文档定义的数据。这种方案保证对于多种格式来说,获取数据都相对简单。
在本发明的图形处理装置的另一种优先应用中,多基本功能模块包括一个图形显示模块、一个数据显示模块和一个数据修改模块。图形显示模块显示图形数据。数据显示模块显示从图形数据中提取的符号数据和数值数据。数据修改模块修改符号数据或数值数据。电子文档规定了图形数据和符号数据及数值数据中任何一个的一种显示格式,也规定了根据一个外部的输入对符号数据及数值数据中任何一个进行修改的一种方法。因此,根据电子文档的技术要求,图形处理装置完成图形、符号和数值的显示和数据的修改。这个方案使对广泛的各种各样的表格的数据进行的修改比较地容易。
上面的讨论只显示了图形处理装置的典型的结构。在上面讨论的信息处理装置的各种各样的方案中的任何一个也适用于图形处理装置。
在本发明的信息处理装置和图形处理装置中,电子文档可能是任何不同的格式。一个优先的实例是一个以XML描述的文档(以下称为XML文档)。XML文档代表一个以一种包括标记的标志语言描述的文档。标记可以任意地设定。XML的使用使电子文档所要求的各种指令能够比较容易地以标记的形式定义。
本发明并不仅限于上面讨论的信息处理装置或图形处理装置,此外还可以实现其他不同的应用。可能的应用包括对应于上面讨论的信息处理装置或图形处理装置的信息处理方法和图形处理方法,以及使计算机运行对应的数据处理序列的计算机程序。当本发明被应用到一个计算机程序时,最好计算机程序在一个浏览器上是可执行的。对此JAVA(注册商标)是一种可取的技术。这个方案使被执行的计算机程序与平台无关,并能够容易地利用XML文档作为电子文档。
另一个应用是一种存储介质,任何不同的计算机程序都被存储在其中。典型的存储介质包括软盘、CD-ROM、DVD、磁光盘、IC卡、IC芯片、盒式只读存储器、打孔卡片、其上印有条形码或其他码的印刷物、计算机的内部存储设备(象一个RAM或一个ROM存储器)和外部存储设备,以及各种各样以任何光的、磁的和电的方式可读的其他计算机的可读取介质。
通过下文中对照附图对优先实施例的详细描述本发明的上述的和其他的目的、特性、情况和优点将变得更加显而易见。
具体实施方式
实现本发明的一些方式在下文中被作为优先实施例以下面的顺序加以讨论:
A.第一实施例
A-1.系统结构
A-2.流定义
A-3.屏幕定义
A-4.各部分的链接
A-5.电子信息的传输
A-6.执行引擎
A-7.应用浏览器
A-8.信息总线
A-10.启动处理
A-11.流定义的指令处理
A-12.屏幕控制处理
B.第二实施例(图形处理系统)
B-1.系统结构
B-2.软件配置
B-3.图形处理
C.修改
A.第一实施例
A-1.系统结构
图1显示了在本发明的一个实施例中的一个信息处理装置100的系统结构。信息处理装置100由安装在一个通用计算机中的包括与图1所示相应的功能块的软件所构成。这些功能块可以使用硬件部件,代替所安装的软件。
信息处理装置100经过一个网络INT与一个Web服务器10和一个AP服务器20相连接。网络可以是一个广域网比如因特网或者是一个相对限制的网比如LAN(本地网)。
一个Web服务器10响应从信息处理装置100发出的一个要求,传输被称作屏幕定义12和流定义14的电子文档。屏幕定义12是一个定义视窗规范的电子文档。流定义14是一个电子文档,定义所处理的流,比如视窗的转换。这些电子文档的细节将在以后讨论。在这个实施例中电子文档是用XML描述的,尽管任何不同的格式也是可以使用的。
AP服务器20,协作信息处理装置100,执行数据处理的不同序列。例如,在一个系统中,一个主计算机从一个终端接收输入数据并执行数据处理的不同序列,终端对应于信息处理装置100而主计算机对应于AP服务器20。信息以电子信息16的形式在信息处理装置100和AP服务器20之间传输。产生电子信息16的方法将在以后讨论。在这个实施例中电子信息16是用XML描述的,尽管任何不同的格式也是可以使用的。
在这个实施例的系统结构中,信息处理装置100经过网络与Web服务器10和AP服务器20相连接,尽管信息处理装置100是可以构造成一种独立的形式。可以不使用Web服务器10和AP服务器20,这时信息处理装置100按照被执行的信息处理的规范,可以在一种独立的方式下工作。
下面说明包括在信息处理装置100中相应的功能块的细节。以软件方式实现的一个Web浏览器102被安装在信息处理装置100中,运行在一个预先确定的操作系统上,并且被用来浏览以一种标志语言比如HTML描述的文件。相应的功能块被安排工作在这个Web浏览器102上。在这个实施例中,JAVA(商标)是被用于实现这个方案。让功能块工作在Web浏览器102上的方案方便地使软件配置能够独立于平台。也可以选择安排功能块独立于Web浏览器102而工作。
一个基本小程序104被运行在Web浏览器102上并提供一个用于信息处理装置100的相应的功能块的操作平台,也就是一个执行引擎120、一个应用浏览器130和一个信息总线140。因此在规范中用来通过基本小程序104和相应的功能块实现信息处理的全部的机制被称为XML应用程序。在这个实施例中,这种机制是建立在XML基础上。然而,XML应用程序代表了下面在广义上所讨论的机制的概念,并因而不局限于是建立在XML基础上。
基本小程序104被构建为一个Java小程序。基本小程序104具有启动和终止其中确定的相应的功能块的功能和把计算机的键盘、鼠标等的操作结果(下面称为“关键事件”)传送到XML应用程序的相应的功能块的功能。
执行引擎120根据流定义14的规范,负责控制一般的处理流。因此当流定义14定义视窗的显示和转换时,应用浏览器130被启动。在确定向和从AP服务器20传送数据的情况下电子信息16被传送。电子信息16的内容依赖于AP服务器20并因此是通过一个用户化模块110进行调整的。执行引擎120向信息总线140输出从AP服务器20接收到的数据,并从信息总线140上取出将被传送到AP服务器20的数据。
按照屏幕定义12,应用浏览器130通过执行引擎120启动去显示一个视窗,并允许对该视窗进行操作。应用浏览器130是一个与Web浏览器102不同的程序。应用浏览器130包括多个GUI部分131a和多个逻辑部分132b来执行基本功能。GUI部分131a都是软件包,用来产生构成一个视窗的显示组件比如按钮和线。多个GUI部分131a是对应于相应的显示组件的类别而提供。逻辑部分132b都是软件包,用来完成视窗上的数据处理,例如四运算操作和输入条件的校验。多个的逻辑部分132b是对应于相应的处理类型而提供。应用浏览器130按照屏幕定义12启动这些部分去完成与被显示的视窗有关的不同的处理。
信息总线140负责控制GUI部分131a和逻辑部分132b的操作。信息总线140包括对应于多个GUI部分131a和逻辑部分132b的多个数据项141。每个部分被设定为由对应的数据项141的一个状态变化所触发并且使处理的结果反映到相应的数据项141。响应数据项141在管理程序下的一个状态变化,信息总线140通知相应的部分:状态改变,并由此启动相应的部分。信息总线140还负责保留要求进行处理的数据。如前所述,执行引擎120和AP服务器20之间传输的数据被信息总线140作为数据项141加以管理。
上述结构的信息处理装置100执行不同的处理序列。执行引擎120、应用浏览器130和信息总线140都是不依赖处理的规范并能够实现多功能的软件。由处理的规范确定的软件是以模块,如GUI部分131a和逻辑部分132b,的形式被提供的。例如,处理的实质的规范被以一种定义包括流定义14和屏幕定义12的电子文档中使用的这些部分的顺序的格式加以确定。信息处理装置100有利地保证了通过简单地改变电子文档的内容而容易的修改处理规范,而不需要显著地修改或增加软件。显示在图1中的各组成部分在下文中详细讨论。
A-2.流定义
图2显示了一个流定义14的框图。流定义14是一个定义执行引擎120的操作的电子文档,并且在本实施例中是以XML加以描述的。
流定义14包括一个XML说明语句、一个DTD(文档类型定义)和一个文本。DTD定义了用于流定义中的标识符。只有DTD可能被作为一个与流定义分开的文档来提供。
文本包括多个标识符,用来定义通过执行引擎120执行的处理的规范。执行引擎120典型地从顶部解释包括在流定义14的文本中的标识符并执行由相应的标识符定义的指令。例如,当一个显示产生指令被从流定义14中读出时,执行引擎120启动应用浏览器130显示一个视窗。屏幕定义12被要求用来显示视窗(见图1)。显示产生指令由此指定将被应用浏览器130涉及的的屏幕定义12的路径。
附图的下半部分显示了由标识符定义的指令的一个例子。指令被大致分为两组,一组为处理指令而另一组是光标控制指令。处理指令定义由执行引擎120实际执行的处理的规范。例如,处理指令包括向AP服务器20加载和由AP服务器20处理指令、排队和离队指令、以及视窗的按下和弹出指令。视窗的按下和弹出指令被包括在显示产生指令中。每个指令的细节将在以后结合执行引擎120的功能加以讨论。
光标控制指令定义标识符的解释和在流定义标识符的执行顺序。如上所述,原则上执行引擎120从顶部顺序地执行标识符。光标代表一个当前正被执行引擎120进行处理的对象标识符。依靠这个原则光标控制指令负责光标位置的移动。例如,如附图上半部分所示,包括在流定义14中的光标控制指令考虑条件转移变换处理的对象标识符到一个标识符D或一个标识符E。
如图2所示,这个实施例提供了十个光标控制指令。图3显示了光标控制命令的一个实例。一般地,XML标识符保持一种树结构。流定义14可能因此被用一种树结构表示,如图3所示。
光标控制指令‘FLOWDEF’定义流定义的一个路径。执行引擎120响应这个指令‘FLOWDEF’转换光标到一个子程序‘main’。
一个指令‘SUB’代表一个指定的子程序的说明。在图3的实例中,提供了三个子程序‘main’、‘yoko’和‘tate’。一个指令‘EXITSUB’代表一个指定的子程序的终止。执行引擎120响应这个指令从指定的子程序退出并转换光标到下一个标识符。
一个指令‘GOSUB’代表调用指定的子程序。响应一个指令‘GOSUB’‘yoko’,执行引擎120转换光标到子程序‘yoko’。
一个指令‘SWITCH’代表条件转移。一个指令‘CASE’按照一个指定条件显示光标的目的地。一个指令‘DEFAULT’代表默认的处理的一个序列。在图3的实例中,指令‘SWITCH’按照一个对象“condition”的状态实现条件转移。当对象“condition”处于状态“fine”时,在标识符‘CASE’“fine”之下的一个处理序列被执行。当对象“condition”处于状态“bad”时,在标识符‘CASE’“bad”之下的一个处理序列被执行。当对象“condition”不处于这些状态中的任何一种时,在标识符‘DEFAULT’之下的一个处理序列被执行。
一个指令‘LOOP’代表处理的一个确定的循环的执行。一个指令‘EXITLOOP’代表处理的一个确定的循环的终止。执行引擎120在指令‘LOOP’和指令‘EXITLOOP’之间重复地执行处理的一个序列。
一个指令‘NODATA’按照所涉及数据的存在和不存在转换处理的规范。在图3的实例中,在所涉及数据的不存在的情况下,由标识符A和B定义的处理的一个序列被执行。另一方面,在所涉及数据的存在的情况下,由标识符C定义的处理的一个序列被执行。
在流定义14中包含光标控制指令允许复杂的处理的描述,比如条件转移和循环处理。在图2和3所示的指令都只是例证,并且指令的数字和类型都不局限于这个实例。
A3.屏幕定义
图4显示了一个屏幕定义12的框图。屏幕定义12是一个定义应用浏览器130的操作的电子文档,并且在本实施例中是以XML加以描述的。
在屏幕定义12的文本中包括定义一个视窗的布局和在视窗上执行的操作细节的多个标识符。标识符大致地分为两组,即一组是屏幕信息而一组是部件信息。屏幕信息包括一个根据屏幕定义12的定义对每个视窗分配一个视窗ID的标识符。对应于在信息处理装置100中使用的每个视窗提供屏幕定义12。视窗ID是一个用来确认每个视窗的信息。
部件信息定义了用来启动GUI部件131a和逻辑部件132b的各种信息段。GUI部件131a包括各种用来在视窗上产生显示单元的软件包,例如显示文字字符串、输入文字字符串、显示图形和按钮。逻辑部件132b包括各种与在视窗上的操作相关的软件包,例如四运算操作和校验输入条件。在下面的描述中,避免混乱,除非另外的指定,作为GUI部件131a和逻辑部件132b提供的软件包被称为‘部件’,而由‘部件’产生的单独的显示单元和其他的对象称为‘部件对象’。
部件信息包括若干标识符,表示分配给每个GUI部件131a和逻辑部件132b的一个部件ID,以及部件的类别、位置、大小和参数。视窗可能包括多个由同一个部件产生的部件对象。例如,作为部件对象的多个按钮可能由一个GUI部件131a‘按钮’产生。部件的ID都是标识信息用来单独地管理由部件产生的多个部件对象。例如,部件的位置和大小可能被设置在屏幕上的一个坐标系统中。部件的参数是例如按钮的形状、颜色,或者文字的字体。
应用浏览器130从顶部顺序地读取在屏幕定义中的标识符并按照相应的标识符执行处理的序列。应用浏览器130读取用来每个所指定的部件指定ID和位置和大小的标识符,并按照标识符执行启动指定的部件的处理。对应于相应启动的部件的部件对象显示在视窗上,使之能够在视窗上操作。在图4中所示的标识符、GUI部件131a和逻辑部件132b都只是例证,并且标识符以及部件的数目和类型都不局限于这个实例。
A-4.各部分的链接
图5显示了各部分的链接。在本实施例的结构中,应用浏览器130经过信息总线140启动相应的部件。
信息总线140完成全部的数据项的管理。每个数据项具有一个内部值并且被映射到一个或多个在应用浏览器130中使用的部件。对每个数据项映射关系被注册。在所示意的实例中,一个数据项A具有一个内部值A并被映射到一个部件A。一个数据项B具有一个内部值B并被映射到一个部件B。当某个数据项的值出现变化时,信息总线140负责将该变化通知到被映射到某个数据项的部件。在本实施例的结构中,信息总线140的这个功能允许相应的部件按以下方式被人工地启动。
在一个实例中,假设在屏幕定义12中的一个标识符定义了部件A的启动。应用浏览器130读取这个标识符并改变数据项A的一个值A到一个指定的值作为部件A的启动触发器。信息总线140将这个改变通知到被映射到数据项A的部件A。部件A响应通知被启动。在这个实例中,部件A已经被编程为在启动后去改变数据项B的值。这样部件A的启动触发数据项B的值B的改变。信息总线140将该改变通知到被映射到数据项B的部件B。部件B响应通知被启动。
如此使用在信息总线140管理下的数据项便于多个部件的连接。例如,响应一个按钮的按下,显示的一个字符串连同显示的按钮的一个变化可能被容易地改变。
通过数据项启动相应的部件便于添加新的部件和替换已有的部件。在一个实例中,假设准备增加一个与部件A一起被启动的新部件C。在这种情况下,所要求的处理在应用浏览器130中提供了一个用于部件C的软件包,并把部件C添加为数据项B的一个对象部件。部件A的启动触发数据项B的值的一个变化。信息总线140把变化通知部件B和C二者,以便启动这些部件B和C。在这种方式中,添加一个与部件A链接的新部件是容易得到的,而不需要对部件A的内容进行修改。
这个实施例运用图5所示的步骤启动多个部件并获得这些部件之间灵活的链接。例如,一个修改的步骤可能引起例如部件A直接启动部件B和C。
A-5.电子信息的传输
图6显示了对一个电子信息进行制作和译码的处理过程。执行引擎120经过电子信息16从和向AP服务器20传输数据。电子信息16要求按照数据的类别和由AP服务器20提供的应用程序的内容具有一种格式。执行引擎120按照图6所示的处理过程容易地制作不同格式的电子信息16。
执行引擎120在接收或传输电子信息16时读取一个RELAX112,这个RELAX112是一个用来指定一种所要求的格式的电子文档。在本实施例中,RELAX文档112可能具有任何的不同格式并在此实施例中为XML。将被接收和传输电子信息16采用多个格式,以便提供一组RELAX文档112。RELAX文档112可能被预先存储在信息处理装置100中,或者可能例如由Web服务器10提供。
当执行的处理附有数据传输时,一个所要求的RELAX112的选定是在流定义14中被指定的。在图6显示了这样的一个例子。当用于条件转移的条件是“fine”时,一个路径A被指定作为所要求的RELAX112。另一方面,当用于条件转移的条件是“bad”时,一个路径B被指定作为所要求的RELAX112。响应路径名从执行引擎120到用户化模块110的传送,用户化模块110选择对应于路径名的RELAX112,并根据所选择的RELAX112制作用于传输的电子信息16或对接收到的电子信息16进行译码。执行引擎120伴随着电子信息16的传输和接收向和从信息总线140传输数据。
执行引擎120不具备依赖于每个电子信息16的创建功能,但是具有根据RELAX112制作电子信息16的多用途的功能。执行引擎120的这种多用途的功能允许不需要修改执行引擎120而创建不同的电子信息16。
A-6.执行引擎
图7显示了包括在一个执行引擎120中的模块。执行引擎120具有由软件构成的多个功能块。各个功能块都在一个主控制器121的控制下工作的。
一个流控制器122负责读取流定义并按照流定义的内容控制处理。如先前参考图2的讨论,流定义包括处理指令和光标控制指令。流控制器122解释每个光标控制指令并按照光标控制指令的内容执行光标的位移。主控制器121解释每个处理指令并响应处理指令启动功能块。
一个关联控制器123控制一个视窗的显示并响应指令‘Push’(隐藏视窗)或‘Pop’(再现视窗)被启动(见图2)。关系控制器123适当地启动或停止应用浏览器实现对于视窗的显示的控制。
一个交换控制器125完成关于向和从AP服务器20传输电子信息的通信控制。交换控制器125响应指令‘Upload’(向服务器传输)或‘Transaction’(与服务器通信)被启动(见图2)。在本实施例中,电子信息是根据RELAX而创建的。交换控制器125使用一个RELAX选择器116、一个附加器115和一个通信插件117处理电子信息。RELAX选择器116负责用来制作或解释电子信息的RELAX文档。附加器115产生关于包括在被传输的电子信息中的数据的一个标题和其他的附加信息。通信插件117按照通信协议向和从AP服务器20传输电子信息。按照AP服务器20的功能和通信协议的类别,这些功能要求用户化。在这个实施例的结构中,这些功能由此是被包括在用户化模块110中并且是分别地由包括在执行引擎120中的多功能块所提供的。
一个队列控制器124负责使交换控制器125和关联控制器123保持同步。队列控制器124响应处理指令‘Queue’(加入队列)或‘Dequeue’(从队列移去)被启动(见图2)。队列控制器124创建一个将被向交换控制器125传送的通信线程126,并把通信线程126存储到一个队列中。交换控制器125根据队列在一个恰当的时间与AP服务器20建立通信。通信线程126保留从AP服务器20接收到的数据并按照接收到的数据在恰当的时间启动关联控制器123显示一个视窗。队列的使用能够预先与AP服务器20通信并存储通信结果,而由此保证视窗的平滑转换。
A-7.应用浏览器
图8显示了包括在一个应用浏览器130中的模块。应用浏览器130具有在一个主控制器121的控制下工作的多个功能块。
一个视窗产生模块134负责根据屏幕定义的规范产生构成每个视窗的部件对象。一个视窗显示模块135响应一个来自主控制器133的指令顺序地显示部件对象构成视窗。相反,一个视窗取消显示模块136隐藏部件对象消除视窗。一个视窗删除模块137废除部件对象来删去关于视窗信息。一个路径设置模块138设置用来标识每个视窗的一个路径的名称,即一个视窗ID。
在视窗上使用的相应的部件对象都是通过部件131产生的,并被在一个对象表139中加以管理。部件131包括先前讨论过的GUI部件131a和逻辑部件132b。应用浏览器130的各个功能通过向对象表139中注册以及显示和隐藏部件对象加以实现。
A-8.信息总线
图9显示了包括在一个信息总线140中的模块。信息总线140具有一种合并数据项141的功能。在这个实施例的结构中,有多个总线148被建立在信息总线140中。各个总线148按照数据项141的类别分类完成管理。总线148包括预先提供的静态总线,以及按照要求产生的动态总线。
总线获得模块146产生一个总线148。一个总线清除模块147消除一个不需要的总线。在这个实施例中,提供了八种类别的总线148。一种类别的总线可能包括多个总线。例如,按照视窗的内容,对于一个未来视窗的总线[6]到[8]的每个类别可能包括多个总线。
对应每个总线148提供管理数据项141的功能块。一个数据项获得模块142获得代表一个对象数据项的状态的一个值,这个值包括在管理的对象中。数据项获得模块142也具有产生一个数据项的功能。如上所述,数据项是一个用于获得多个部件连接的对象。本实施例的系统按照一个部件的操作状态动态地产生一个数据项。数据项获得模块142执行检索并确定是否一个一个确定的部件的操作所要求的的数据项被包括在管理的对象中。当不包括时,数据项获得模块142产生所要求的数据项并把所产生的数据项添加到管理的对象中。这个方案保证了用于数据项管理的硬件资源的有效利用。
一个数据提取模块143从数据项中提取被包括在由执行引擎120创建的电子信息中的数据。一个数据清除模块144清除保留在数据项中的数据。包括在管理对象中的数据项被注册在一个数据项表145中。上面讨论的功能块涉及这个数据项表145去实现相应的功能。
在图9中列举了数据项141的功能。数据项141具有以下五项功能。一个数值设置功能设置一个外部通知的数值到数据项141中保留的数值,并且在数值发生变化的情况下,把这种变化通知映射到数据项141的一个或多个部件。这对应于前面参考图5所讨论的实现链接的功能。响应一个外部询问,一个数值获得功能应答数据项141中保留的数值。一个部件注册管理功能在数据项141中保留的数值发生变化的情况下,管理作为通知的对象的那些部件。一个部件注册消除功能一个一个单独地消除一个部件的注册,而一个全部部件注册消除功能同时地消除全部部件的注册。这些功能使数据项141能够象前面参考图5所讨论的那样控制部件的启动和链接。
在本实施例的结构中,每个部件131积极地完成向数据项141中的注册。在图9中也列举了部件131的功能。
部件131具有以下五项功能。一个变化检测功能检测在数据项141中保留的数值的变化。这对应于从数据项141接收改变通知的功能。一个通知功能通知外部关于一个部件对象的产生、显示、隐藏和废除。一个数据项获得功能检索部件131所映射的数据项141。一个数据项监控功能完成部件131向所映射的数据项141的注册。一个参数值获得功能获取在产生一个部件对象的处理中确定的一个参数。
在本实施例的结构中,部件131负责向它所映射的数据项141注册。在一个修改后的应用中,数据项141可以检索和注册部件131。在本实施例的结构中,数据项141通知部件131关于在数据项141中保留的数值发生了变化。在一个修改后的应用中,部件131持续监控在数据项141中保留的数值并检测数值的变化。
如上面讨论的信息处理装置100能够根据电子文档,比如流定义、屏幕定义和RELAX文档灵活地处理、产生和解释电子信息。处理的技术要求通过简单地修改这些电子文档被容易地和灵活地改变,而不需要改变XML应用程序的基本结构。
A-10启动处理
下文说明启动XML应用程序和按照流定义执行处理的相应的步骤过程。
图10是一个显示一种启动过程的流程图。响应一个操作者输入的一个XML应用程序基本页面的一个URL,这个过程开始于信息处理装置100中浏览器的活动状态。XML应用程序基本页面代表一个Web页,这个Web页提供一个基本小程序104并且在这个实施例中是被用XML描述的。URL可以指定信息处理装置内部的一个位置或在外部Web服务器10中的一个位置。
响应输入的URL,信息处理装置100使用浏览器读取XML应用程序基本页面(步骤S10)并启动由XML应用程序基本页面提供的基本小程序104(步骤S11)。基本小程序104是一个软件包,用来提供XML应用程序运行的平台,如前面参考图1所讨论的。
由于基本小程序104的作用,信息处理装置100产生应用浏览器130(步骤S12)。这里产生的应用浏览器130对应于用来启动XML应用程序的平台的浏览器。应用浏览器130读取一个预先通过基本小程序104指定的初始屏幕定义(步骤S13)。按照这个初始屏幕定义产生的视窗以后被称为是“基本视窗”。应用浏览器130启动基本视窗上的执行引擎120(步骤S14)。这实现允许XML应用程序操作的状态。
执行引擎120读取流定义(步骤S15),并根据流定义调用应用浏览器130去产生一个初始视窗(步骤S16)。通过执行引擎120被读取流定义的URL已经被预先设置。另外,URL可以通过基本小程序104或初始屏幕定义被给出。
图11是显示启动后的屏幕结构的示意图。XML应用程序运行在已经读取了XML应用程序基本页面的Web浏览器102上。基本小程序104运行在XML应用程序基本页面上。
基本小程序104产生一个应用浏览器130A,作为XML应用程序的平台,并提供一个XML应用程序基本视窗。执行引擎120被在XML应用程序基本视窗上启动。用来提供通信和其他功能的一个插件也可以按照要求被启动。然后执行引擎120启动一个应用浏览器130B。如前面所讨论的,应用浏览器130B启动各种不同的部件131去建立一个视窗。部件131包括GUI部件131a和逻辑部件131b二者。响应用于在流定义中显示和转换视窗的每个指令,应用浏览器130B的启动被调用。
按照上面的过程完成XML应用程序的启动,执行引擎120根据流定义开始真正的处理。
A-11.流定义的指令处理
图12是一个显示一个由执行引擎120执行的处理序列的流程图。执行引擎120读取流定义(步骤S20),解释包括在流定义中的标识符(步骤S21),并根据流定义的标识符确定处理(步骤S22)。
当流定义确定用来屏幕显示的处理时,执行引擎120执行关联控制(步骤S23)。关联控制启动应用浏览器130去产生一个视窗并能够在屏幕上操作。在应用浏览器130启动期间,信息处理装置100的控制已经转移到应用浏览器130。在步骤S23,执行引擎120等待通过应用浏览器130执行的处理序列的完成。当流定义确定电子信息的处理时,执行引擎120执行交换控制(步骤S24)。交换控制涉及的是RELAX文档并创建或译码电子信息。执行引擎120按照标识符的内容可以执行其他处理不同序列,虽然没有被具体地显示出来。
执行引擎120反复地执行上述的处理序列直到流定义的技术要求被完成(步骤S25)。
A-12.屏幕控制处理
图13是一个显示一个屏幕控制处理的流程图。响应来自执行引擎120的一个调用指令,应用浏览器130被启动(步骤S30)去完成对屏幕的处理,比如屏幕显示。
应用浏览器130首先读取调用指令确定的屏幕定义(步骤S31)并按照屏幕定义的技术要求实现屏幕显示(步骤S32)。如前所述,根据屏幕显示的技术要求通过调用相应的部件获得屏幕显示。
在这种情况中,应用浏览器130等待一个关键事件的输入(步骤S33)。在信息处理装置100中,关键事件是键盘和鼠标的操作的一个结果。基本小程序104检测这些输入装置的操作并向信息总线140输出一个代表操作的详细资料的信息。应用浏览器130监控信息总线140并根据该输出检测关键事件。
当关键事件是一个涉及视窗的转换、与AP服务器20通信、删除一个视窗或终止XML应用程序的执行指令时,应用浏览器130终止所要求的操作并将控制返回到执行引擎120(步骤S36)。在执行指令要求移除屏幕显示的情况下,比如删除一个视窗或终止XML应用程序,应用浏览器130消除当前屏幕上的显示,然后返回控制到执行引擎120。另一方面,在执行指令不要求移去屏幕显示的情况下,比如视窗的转换或通信,应用浏览器130立即将控制返回到执行引擎120,而不需要消除当前显示。
当关键事件不是任何执行指令时,应用浏览器130启动对应于关键事件所需要的GUI部件和逻辑部件(步骤S35)。这种关键事件的例子包括在屏幕上输入数据、按钮的操作和一个域的详细说明。如前面参照图5所讨论的,通过改变映射到相应的部件的数据项的值,所要求的部件的启动是容易实现的。
应用浏览器130显示一个结果视窗并允许根据屏幕定义来在视窗上操作。这里有一种可能,既应用浏览器130在一种双重方式中被执行引擎120调用。本实施例的结构允许产生多个应用浏览器130。多个应用浏览器130可以单独地执行上面的处理序列以获得并行处理。
第一种实施例的信息处理装置100具有下面所讨论的优点。
第一种优点是由执行引擎120和应用浏览器130执行的实质性处理的细节可以通过外部的包括流流定义14、屏幕定义12和RELAX文档的电子文档加以确定。这种方案容易地实现处理的技术要求的变化和扩展,而不需要修改软件。
第二种优点是由应用浏览器130使用的各自的部件131是被作为单独的模块构建的。这种结构便于添加新的部件和替换已有的部件。
第三种优点是各个部件彼此不是直接地相连接,但通过数据项彼此相链接。用于多部件联合的对象的协调保证了容易替换已有的部件和添加新的部件。
第四种优点是运行在Web浏览器上的XML应用程序是不依赖于平台的并具有高的通用性。
B.第二实施例(图形处理系统)
第一实施例关注多用途信息处理系统。下面所讨论的本发明的第二实施例关注一个图形处理系统,作为XML应用程序的一个具体的实例。
B-1.系统结构
图14是显示在本发明的一个第二实施例中的一个图形处理系统的结构的示意图。在财会软件中,图形处理系统被用来根据表格,比如划拨书进行交换。系统利用从包括在每个表格中的信息所获得的符号数据和数字数据(以下统称为“表格数据”)和通过扫描相应交易的表格获得的图象数据。
图形处理系统包括一个图形作业流系统200和一个基本交易系统300,它们通过一个网络彼此连接。图形作业流系统200执行表格的图形数据和表格数据的注册、校正和询问。基本交易系统300负责执行交换。由基本交易系统300执行的交换包括那些不利用任何表格的。为了方便,以下的描述只关注利用表格数据的交换。
基本交易系统300具有一个交易服务器320和一个主计算机330,它们可以是分开的或是一体的。交易服务器320负责管理在一个交易数据库310中的交换所需要的交易数据,并响应来自客户机250和350的要求提供交易数据。例如,交易数据包括帐目信息和每个用户的交换记录。主计算机330根据交易数据实际上完成不同的交换。
图形工作流系统200具有一个图形服务器220。图形服务器220负责存储表格的图形数据和表格数据作为图形档案210,并响应来自客户机250和350的要求提供图形档案210。
图形数据和表格数据通过客户机250输入到图形工作流系统200中(以下称为“图形客户机”)。图形客户机250操作一个扫描仪204扫描每个表格202并获得表格202的图形数据。图形客户机250使取得的图形数据接受OCR处理以获得表格数据并把图形数据和表格数据注册到图形服务器220。
如果需要,由使用与图形服务器220连接的一个图形客户机250的另一个操作者对注册的表格数据进行检验和校正。响应操作者的指令,图形客户机250平行地显示一个图形数据和表格数据的列表,其中图形数据和表格数据是被检验的对象。操作者把表格数据与图形数据进行比较并检查出表格数据的任何错误。操作者校正检查出的表格数据的错误,并更新图形档案210的内容。
B-2.软件配置
图15显示了一个图形工作流系统200的软件配置。在实施例的结构中,图形服务器220和图形客户机250二者都按照XML应用程序完成各自的处理序列。因此用来启动XML应用程序的功能块被构建在图形服务器220和图形客户机250中。
XML应用程序可以被只用于图形服务器220和图形客户机250二者中的任一个,并也可以被用于基本交易系统300。
图形服务器220具有一个应用核心225。应用核心225是一个执行引擎、一个应用浏览器和一个信息总线的统称。如在第一实施例中讨论的,应用核心225是通过一个基本小程序在一个Web浏览器上所提供的。
图形服务器220还具有应用部件224和一个交易流定义223,它们被用于由应用核心225执行的处理。图形服务器220不负责屏幕显示并因此不包括屏幕定义。
交易流定义223确定一系列处理过程以在图形档案210的表格中管理从图形客户机250接收到的图形数据和表格数据以及一系列处理过程以响应来自图形客户机250和其他客户机的要求提供图形数据和表格数据。
图形服务器220还包括一个Web查询模块221和一个基本交易协作模块222。Web查询模块221响应来自一个客户机的要求提供一个HTML文件格式的图形档案,该要求不涉及XML应用程序。基本交易协作模块220完成各种需要与基本交易系统300协作的处理序列。例如,简单的比较图形数据和表格数据不能验证一个帐户数字。基本交易协作模块222使用基本交易系统300来验证帐户数字。
图形客户机250具有一个应用核心253、应用部件252和交易定义251。由于图形客户机250负责在屏幕上操作,交易定义251包括一个流定义和一个屏幕定义二项。
图形客户机250还包括一个表格识别模块254。在本实施例的结构中,提供表格识别模块254作为独立地由XML应用程序启动的一个软件包。作为替换,表格识别模块254也可以依赖于XML应用程序。表格识别模块254把每个表格的图形数据送到OCR进行处理以获得表格数据。通过一个表格定义255,OCR的一个对象区域被指定给每个表格。
按照XML应用程序,图形客户机250完成除采集表格数据之外的处理。例如,流定义确定每个表格的图形数据的采集、表格的图形数据与由表格识别模块254获得的表格数据的对应关系以及为了存储在图形档案210中所作的格式转换。屏幕定义确定这种处理所要求的视窗的操作。
流定义还确定各种用于校正表格数据的处理,例如,一种关于向操作者提供从图形档案210中提取的图形数据和表格数据的处理,和一种接受对表格数据的校正的处理。屏幕定义确定用于这种校正的视窗,例如,一个用来以对比的方式列举图形数据和表格数据的视窗和一个接受校正的视窗。
在本实施例的结构中,图形客户机250与图形服务器220之间的通信是建立在一种HTTP协议上的。在第一种实施例中说明的电子信息被用于图形客户机250与图形服务器220之间的数据传输。应用核心253和225指的是创建和译码电子信息的RELAX文档。
B-3.图形处理
图16是一个显示一般图形处理的流程图,这是一个由图形客户机250和图形服务器220执行的完整的工作流程。双框代表由图形客户机250执行的处理。
图形客户机250首先读取一个表格图形(步骤S500)并完成表格识别以产生表格数据(步骤S501)。图形客户机250然后把表格数据映射到图形数据并注册映射关系(步骤S502)。图形客户机250以一种预先确定的格式存储表格数据和图形数据并以一种预先确定的格式把表格数据和图形数据传送到图形服务器220。图形服务器220把接收到的数据注册到图形档案210的一个预定的区域。
数据可以以任何不同的格式存储,而在这个实施例中是以XML格式存储的。换句话说在XML格式中表格数据被归入相应的项并且用指定的标识符记录。用于存储图形数据的路径名也被以XML格式记录。这种方案便于确定表格数据到图形数据的映射关系并能够实现合并。在这个实施例的程序中,在这个时刻数据是以非完全校正和检验的状态被注册的。
在注册数据之后,图形服务器220完成一个交易协作处理(步骤S503)。例如,如前所述交易协作处理包括帐目数字的鉴别。
[0139]在完成图形数据和表格数据的注册后,工作流变换到一个校正步骤(步骤S504)。校正步骤由图形客户机250加以执行。图形客户机250的终端和操作者可能是与数据注册时不同。当操作者向图形客户机250发出“校正处理”的指令时,图形客户机250从注册在图形档案210的数据中提取非完全校正和检验的状态数据。操作者把表格数据与图形数据相比较并完成对表格数据所要求的校正。校正后的数据被传送到图形服务器220。图形服务器220接收校正后的数据并更新图形档案210的内容。类似于数据注册时,图形服务器220完成一个交易协作处理(步骤S505)。此时数据具有非完全检验的状态。
然后工作流变换到检验图形数据和表格数据的一个过程(步骤S506)。在数据校正处理之后是处理的过程(步骤S504)。校正处理针对任何错误再次检验表格数据并且当不要求时可以忽略。
当图形客户机250向图形服务器220传送校正后的数据时,图形服务器220向收到的数据加上一个检验完全的状态并更新图形档案210的内容,以便允许数据查询(步骤S507)。上面的各种处理序列能够实现查询来自图形档案210和基本交易系统300的图形数据和表格数据。
图形客户机250主要按照XML应用程序完成上面的各种处理。处理的实际内容由图形客户机250的交易定义251确定。在产生表格数据的过程中(步骤S501),XML应用程序被运用到启动表格识别模块254的步骤和获得识别结果的步骤,其中模块254是一个独立的XML应用程序。
图形服务器220也主要按照XML应用程序完成上面的各种处理序列。处理的实际内容由图形服务器220的交易流定义223确定,尽管在图16中没有被显示出来。
第二个实施例的图形处理系统运用XML应用程序对表格数据和图形数据进行处理。在各种各样的财会软件中存在着大量不同的表格由于多种交换,因此需要不同的图形处理序列。按照XML应用程序处理的实际内容由交易定义251和交易流定义223确定。这个方案保证了在大量不同的所需要的处理中比较容易的实现用户化和修改技术要求。
第二个实施例是关于财会软件中的图形处理。本发明的原理也可应用于一个不同的商业用途表格,例如,保险公司的保险结算。
C.修改
在上面讨论的第一和第二实施例中,信息处理装置100、图形客户机250和图形服务器220都是被连接到网络上的。XML应用程序可以不是被一个连接到网络上的计算机所启动,而是可以被一个独立的计算机所启动。在由一个独立的计算机所启动的情况下,处理所要求的流定义和屏幕定义可以被预先存储在计算机中或可以从一个记录介质提供,比如一个CD-ROM。
在上面的实施例中,XML应用程序是由软件实现的。一种可能的修改提供了完成执行引擎120、应用浏览器130和信息总线140的功能的电路结构,并因此将XML应用程序构造为硬件。这种硬件结构也方便地保证了比较容易的实现用户化和处理过程的修改,而不需要对电路做任何重要的改变和替换。
在第一种实施例中讨论的XML应用程序的功能块的部件可以被省略。例如,只有执行引擎120的基本功能,即根据流定义14的处理,可能依赖于XML应用程序,同时电子信息16的处理和对屏幕显示的处理可以是独立于XML应用程序的。或者只有电子信息16的处理和对屏幕显示的处理可能依赖于XML应用程序。
本发明的方案保证了通过简单地改变外部给予的电子文档的内容增加、修改和用户化信息处理功能,而不需要对信息处理装置本身的软件配置或硬件结构做重大的改变。
上述实施例和它们的应用在所有方面都是作为例证性的而不是限制性的。在不离开本发明的主要特性的范围和精神的情况下,可能存在多种修改、变化和替换。例如,上面讨论的控制处理的序列可以通过一个硬件结构代替软件配置加以实现。
本发明的范围和精神通过附带的权利要求所指出的,胜过通过上述说明的。