CN1446336A - 模块化计算机系统以及相关方法 - Google Patents

Abstract

本发明涉及一种用于开发将由计算机系统所实现的计算机项目的处理方法，该处理包括为了对满足需求的函数进行分类而进行的函数分析阶段、借助于计算机设备来创建项目组件以实现所述函数的阶段、对创建阶段期间所创建的组件的相同系统进行说明的阶段、以及将所述组件加载到系统存储器区域以由计算机来实现其组件的阶段，其特征在于在组件创建阶段期间，每个函数是完全由与此相关的组件来实现的，在组件说明阶段期间，所创建的每个组件被声明为系统载入组件，并且在组件载入阶段期间，提供了可自动搜索可提供所述函数的组件的装置，这与已载入组件所需的函数有关。

Description

模块化计算机系统以及相关方法

介绍

本发明涉及通常方式上的软件系统，该系统允许用户与计算机硬件相交互。

更具体的说，本发明涉及一种包括有操作系统的软件系统，该操作系统可提供灵活的性能和执行速度，即使在特强大的当今操作系统的情况下也难以想象该操作系统。

本发明还涉及与该系统有关的处理方法。

同样，如上所述，本发明可有利的适用于(但不局域限于此)开发与板上计算机系统相关的应用程序。

注意到操作系统是任何软件系统的主要构件，该操作系统是由与组成计算机系统的硬件直接交互的部件构成。

人们已经了解了许多操作系统，这些操作系统允许开发队伍创建一应用程序并允许最终用户实现这些应用程序。

现有的操作系统被大略分解成两个主要的类。单片体系结构

第一类由单片体系结构操作系统组成。这样的系统由包括三个主要层的单一软件组组成：

●通常所说的与系统内核相对应的底层。内核被定义为被永久加载到系统存储器并可被所有应用程序包所使用的无源特权代码集。

其根本任务是调节系统共享资源的使用。为了完成该任务，内核可满足某一重要功能(functionalities)的需求，包括：

√存储器的管理(在应用程序间分配存储资源以作为它们要求的功能等

  等)，

√处理过程的管理(调度、访问处理器的管理、多任务管理等等)，

√外围设备驱动器的管理，

√文件管理(名字、地址等等)，

√用户管理(访问、概况等等)。

●通常所说的专用于应用程序的顶层，用户与该顶层相交互以便将指令输入到系统并输入被传送到内核的请求。

●通常被称为“信息库”的中间级，该中间级有时被认为是一层并且在该中间级中周期性的函数(functionality)聚集在一起以允许将其快速实现。

附加在正文之后的图1示意性的表示了这种单片体系结构，该图1给出了层K(内核)、L(信息库)以及A(应用程序)的集中式且分层的结构。

“层”的定义可对操作系统的构件间的通信进行按级别的排列，最底层被定义为“特权”层，该层可被称为高级层。

因此这些层是共享同一特权的软件构件类。同时，特权被定义为使用计算机系统某一资源的能力(硬件资源或软件资源)。

如所述的，根据该单片体系结构的系统结构由单个软件组构成，该单个软件组是以“模块方式”(blockwise)进行编译的。

该结构的优点在于该系统通常是稳定且高速的。

然而，根据系统的灵活性和升级性该操作系统显示出重要的局限性。

实际上，对内核有系统的修改涉及对内核进行完全的重新编译。对于每一个修改而言，因此必须负责处理再次全部接受系统。

同时，因为系统的升级是麻烦且复杂的，因此不利于系统的不变性，且其维护是昂贵的。此外，由于连续“增加一方”而导致了系统成为不稳定的。

另外，在单板计算机系统的情况下(也就是说至少一个部分被集成到诸如车辆、携带式电话之类的移动硬件上)，该不变性显示出其自身是及其不利的，因为它还使它必须先验的固定一个表示操作系统特征的特定号码(例如速度的执行或存储器的大小等等是特权的事实)。

实际上，单板应用程序的多样性经常面临相关计算机系统所需的不同程序员，并且它有利于可对系统的主要特征进行自由定义和升级。

因此，由于在上文中所提到的缺点以及主要由于单片操作系统不变性的阻碍，因此该单片体系结构主要是用于不需要对硬件和软件进行重大升级的应用程序，并且它不适合于单板系统(on-board systems)。

微内核体系结构

为了减小该局限性，已经设计出第二类操作系统的体系结构。存在诸如图2所示的微内核型系统。

该图按照单片系统的方式给出了该微内核系统是由围绕一中心内核的同心层组成，该中心内核由操作系统的“核”构成。

内核构件MK在这里被简化为“微内核”，其仅仅可完成系统操作所需的基本功能，即：

●存储器的管理，

●过程的管理，至少关于通常所说的低级过程—与任务的转换有关。它指出某一微内核系统借助于服务器来管理高级过程，同时其他的微内核根据该微内核本身来管理它们，

●端口(邮箱)和传送消息的管理，

●各个驱动器间的硬件资源的分配属性(驱动器被定义为用于控制卡或任意外围设备操作的程序)。

传统上由单片系统的内核所完成的其他功能是由服务器S来完成的。这些服务器形成了应用程序A的顶层和信息库的L层之间的中间层，该L层直接环绕着微内核MK。它们比应用程序A优选。

该微内核体系结构可对操作系统进行升级而无需对整个系统进行重新编译；因此与单片系统相比，第二类操作系统具有一定的灵活性。

然而，该类体系结构仍然被构造成在中心内核周围的连续层，并且对于操作系统内部的所有信息交换必须通过微内核。

事实上，通过系统连续层的信息流通引起了额外的处理并使系统的所有操作慢下来，该信息流通比单片系统的情况还要多很多。

同时，因此对系统进行任意新的开发都必须使这些信息交换最佳化，因此使程序员的工作变得复杂。

因此与单片系统相比，虽然微内核系统提供了额外的灵活性，但是很显然微内核与过长的处理操作有关并仅仅表示不够好的解决方案。

对于现有体系结构的附加说明

此外，当今的系统(单片的和微内核的)都是以内核构件为中心，围绕在该内核周围的连续层被按级别排列以作为预先规定的访问特权的函数。

实际上在所有这些系统中，根据系统本身所固有的不变类型，每个程序有系统地与给定层相关，因此该程序有系统地附带一个超出程序员控制的特权层，因此形成了为现有系统所共有的第一个缺点。

因此，程序例如可以是：

●“内核”或“管理程序”或“系统”(管理与硬件相交互的特权代码)，

●无源函数的“信息库”构件(数学的、视频解压缩，等等)，

●应用程序包代码。

这些各种类型的代码经常与不同文件格式相对应，并且由操作系统的不同构件来进行不同的管理。

同时，因此不可能利用单个工具来显示所有安装在系统中的程序；同样的，它通常不可能在系统的操作期间替换“内核”部分，该部分形成了不透明且不可分的块。

它允许不同的工具被用于创建并调试这些不同类型的代码，因此在所有的情况下开发操作都是很复杂；这形成了为现有系统所共有的第二个缺点。

同时，应该知道的是现有系统形成了系统的绝对中心。该内核具有一个由其特权级别所作用的特定状态；这形成了为现有系统所共有的第三个缺点。

此外，为现有软件系统所共有的另一个特征是利用下述来执行它们的设计：

●函数分析阶段，该阶段根据所要实现的函数来描述系统，因此形成了一个非常直观且可立即理解的描述级，

●随后的写程序和编译程序，在该阶段期间可理解级别和可读性级别被相反的改变，程序形成了不透明设置，不透明设置的操作方式是预先规定的。

这些系统的程序对作为“自动操作”的请求进行操作，内核仅仅引入反作用以作为应用程序所明示的需要函数。

很显然内核经常根据应用程序所明示的需要来引入之后的反作用，尽管它对资源进行了处理并且可利用最优化的函数以改善系统的所有操作。这形成了现有系统的另外一个基本局限性。

如所述的，在本发明在另一方面的情况下，对系统所有组讲的操作方式进行集成并且将函数分析阶段过程中所建立的函数链接保留在系统的体系结构中。

这样，诸如由Java语言(注册商标)来表示有关的公知系统，可在下面一文中得到对该系统的说明。该文章的题目为“利用Java3.0版本来编写程序的入门，2000年夏”，作者为D.J.ECK——数学和计算机科学系，霍巴特和威廉史密斯大学，日内瓦，纽约，US24/05/2000，2001年3月7日访问因特网地址http：//math.hws.edu/cs124/downloads/javanotes3.pdf>。它有利于在建立实体间的关系过程中提供增加灵活性的真实度。

在已知语言(例如Java)的情况下可将术语“实体”理解为所采用的目标和类别。

在Java语言的情况下，事实上，如果给定实体实际上调用另外的其操作所需的实体，那么程序员必须明确的指定哪一个实体将被加载到系统随机存取存储器中以允许所述给定实体调用适当操作的实体。

因此很明显的是这类公知语言不过迫使从设计中选择正确的一个，尽管它实际上提供了与目标体系结构相关的灵活性，因此极大的限制了系统的灵活性。

此外，这种公知系统不能在加载操作的过程中返回任何错误消息，因此它可将有故障的实体或者不能完成其任务的一个实体加载到系统中。同时，仅仅在系统的所有操作期间或在因此不得不被专门调度的测试操作期间记录下所述有故障的实体。

发明目的

本发明的主要目的就是提出一个可提供灵活性性能和执行速度性能的操作系统，即使对于当今最强大的操作系统也难以想象上述这些性能。

本发明的另一个目的就是提出一个软件系统，该系统可进一步克服上文中根据所有现有系统而提到的缺点。

本发明的又一个目的就是提出一种软件解决方案，该方案可处理在设计单板系统的过程中所固有的限制条件。

为了实现这些目的，本发明提出了一个处理过程以开发将由计算机系统所完成的计算机项目，该处理过程包括为了对满足需求的函数进行分类而进行的函数分析阶段、借助于计算机设备来创建项目组件以实现所述函数的阶段、对创建阶段期间所创建的组件的相同系统进行说明的阶段、以及将所述组件存入系统存储器区域以由计算机来实现其组件的阶段，

其特征在于

●在组件创建阶段期间，每个函数是完全由与此相关的组件来实现的，

●在组件说明阶段期间，所创建的每个组件被声明为系统载入组件，并且

●在组件载入阶段期间，提供了自动搜索可提供所述函数的组件的装置，这与已载入组件所要求的函数有关。

根据本发明的处理过程状况最好是但不局限于以下所述：

●执行所述自动搜索，同时也要考虑到条件，

●所述条件被表示为一个规范函数，该规范函数以逐一与各个组件相关的属性函数的形式表示。

●在创建组件的过程中，执行下述步骤：

创建组件的接口程序源文件，以便形成组件的“接口程序”部分，

创建至少一个可实现组件函数的代码源文件，以便形成组件的“执行”部分，

●为了形成组件的“执行”部分所创建的每个代码源文件可由任意一种编程语言来创建，

●每个组件可通过开发软件和/或硬件装置来实现与此有关的函数，

●每个组件的接口程序文件包括对所述组件所实现的函数进行说明，而与组件实现该函数的方式无关，

●接口程序文件还包括对该组件必须从其他部件所引入的函数进行说明以便实现其自身的函数，

●由可输出相同函数的另一组件来动态的替换每个组件，

●所述替换采用了下述步骤：

保存将被替换的组件的当前状态，

加载并初始化新的组件，

将被替换的组件的当前状态传送到新的组件，

在调用函数的组件和新的组件之间建立通信信道，

卸载将被替换的部件。

●如果不能正确的执行加载或初始化新的组件，那么提供了用于返回错误信息的装置，

●在创建组件的过程中，还执行下述步骤：

创建一个文件编写，在文件中指定：

√在代码源文件的创建过程中用于创建源文件的语言，

√与组件的“执行”部分相对应的代码源文件，

创建组件的标准型(prototype)，

对组件的“接口程序”部分和“执行”部分之间的链接进行编辑，因此产生可执行的组件标准型，

采用文件编写使得逐一对组件进行编译，并分别形成了组件“接口程序”部分的接口程序源文件以及组件“执行”部分的每个代码源文件的目标文件，

将前述步骤过程中所创建的目标文件封装成一个单一的可执行模块，

●在创建组件标准型的过程中，所创建的标准型包括：

由于对组件的接口程序源文件进行编译而产生的目标接口程序，

与组件“执行”部分的每个代码源文件有关的模型目标文件，

●在编译组件接口程序源文件的过程中，执行下述步骤：

对接口程序源文件的连贯性进行分析并核实，

将接口程序源文件转换成二进制数据，

自动生成至少一个文件，因此可调用将被组件所引入的函数，

●在对组件的“接口程序”部分与“执行”部分之间的链接进行编辑以产生可执行组件标准型之后，执行自动完整的测试步骤，在执行该步骤的过程中核实该项目是否是连贯的且是否已结束，

●在自动完整的测试过程中，对于该项目所需要的每一个函数而言，存在从一系列可访问的组件中搜索一个可完成所述函数的组件，

●在可完成所要求函数的几个组件都被确定的情况下，从这些组件中选择一个特定组件，

●在完整测试显示出该项目没有正确结束的情况下，发出一个表示不连贯性的错误消息，因此可对确定的组件进行修改和/或增加一些组件，

●对于已加载到系统中的每个组件而言，对该组件必须从其他组件所引入的函数的说明是可永久的访问所述用于自动搜索组件的装置，

●在将前述步骤期间所创建的目标文件封装成单一可执行模块的过程中，可核实由项目的各种接口程序部分所提供的所有函数实际上都已在相关的源文件中有所描述并已被编译，

●处理过程包括将加载到系统中的组件的映射加载到系统的随机存取存储区域中，

●当调用部件调用函数时将参考所述映射，因此可确定所述映射的组件是否可提供所调用的函数，

●所述装置是可参考所述映射的自动组件搜索，

●与加载到系统中的组件函数一样，在系统的操作过程中要实时更新所述映射，

●与所述其他组件的各个特权级别的函数一样，每个组件与一特权级别有关，该特权级别决定了组件访问其他组件的可能性，

●提供了用于自动卸载每个组件的装置，对于计算机项目的操作而言不再需要在该装置中所提供的函数，

●所述装置包括每个组件的惯用计数器，

●所述计数器对组件的数量进行计数，该组件引入了与计数器有关的组件的函数，并且只要所述组件的惯用计数器减少到零那么就卸载该组件，

●提供了用于自动释放所述已卸载组件所使用的资源的装置。

附图说明

参考随后的除去图1和图2的附图，通过阅读下述对本发明实施例的说明，根据本发明的系统的其他方面、目的以及优点则变得显而易见。在该附图中已经对图1和图2做了说明：

●图3a至3c根据本发明给出了操作系统的三个示意图；

●图4根据本发明给出了系统组件的示意图；

●图5给出了用于创建该组件的步骤的示意图；

●图6根据本发明给出了创建并采用操作系统组件的逻辑图；

●图7根据本发明给出了分配并加载系统软件组件的模式；

●图8根据本发明给出了在动态的加载并卸载系统组件过程中减少存储器使用量的示意图；

●图9根据本发明给出了动态替换系统组件的逻辑图；

●图10a，10b和10c根据本发明给出了加载到系统中的组件的三种映射。图10a与最小配置相对应，根据本发明在该配置中仅仅加载为系统初始化操作所绝对必需的组件。图10b与基本配置相对应，在该配置中进一步允许多线程管理。图10c与根据本发明的系统的增强型版本相对应。

对系统的总体介绍

已经阐述了无论是单片的还是微内核的现有系统都是有系统的区分作为与其相关的系统层函数的程序。

根据本发明的系统不按照这种方式来区分程序。相反，在本发明的情况下，操作系统包括整个非分层的组件。因此，根据原始特征，根据本发明的系统没有给出一个层式结构。

同时，尽管在本发明的情况下软件系统的程序员仍保留特定特权级别与每个系统组件相关的可能性(该特权级别可能对应于传统的现有系统状况下所使用的“内核”、“信息库”、“应用程序包”、或者按照请求已经创建了该特权级别)，但是程序员可自由的影响每个组件或者相反关联每个组件，并可为组件选择任意希望的特权级别。

应该指出的是术语“程序员”被定义为相关的一个人或一个研发组。应该理解的是，根据本发明的系统的主要好处是允许研发组以可能的最有效方式工作，每个研发者可通过开发一个组件来负责处理一个应用程序的一个函数。同时，由根据本发明的系统所提供的对特权的详尽管理展现出很大的可能性，例如：

●以“非特权”模式来创建、开发并完全测试一组件(应用程序信息包)，并且一旦开发结束且完全是有效的，那么以“特权”模式来利用目标(系统)。该方法允许通过以应用程序的形式来设计一“驱动器”来实现与微内核系统一样的精调灵活性，因此其后以“系统”模式来使用与单板内核相同的执行级别，

●在一组相同类型的组件内设计不同特权的可能性(例如“编码器/译码器”、数据编码器/译码器)：对于速度而言，可按照系统组件的形式来利用简单组件(例如，GIF“编码器/译码器”)；并且按照用户组件的形式来利用复杂组件(例如，HTML“编码器/译码器”或MacromediaFlash(注册商标))，但是速度不够快，然而可确保并提供完全的容错函数。

在基本情况下该选择可允许程序员来构造他的整个系统以作为他的目标的函数。

图3a至3c根据本发明给出了系统体系结构示意图，该结构仅仅体现出是以组件为基础的，并且不包括诸如内核或微内核之类的“中心”构件。

如上所述，这些组件的每一个自身存在于系统中；它们可被创建、编译、加载到系统的存储器中，并且可独立于另一个组件而卸载，因此可使：

●动态的更新系统(新的版本、校正程序错误，等等)，而无需任何重新引导，

●在设计软件系统的过程中通过提供改变硬件管理策略的可能性来阻止“姿态(stances)”的发生，该硬件管理策略是作为产品本身要求的函数，该“姿态”在由软件系统所抽象化的硬件系统中是相当不便的。

根据本发明的系统的每个组件被专用于单个函数，与传统的操作系统相反，传统操作系统中的内核已经实现了多个函数以及大多数程序。

同时，为了实现与此有关的函数，每个组件要求执行一个或多个其他组件的一个或多个函数。

因此，为了操作，根据本发明的系统配置了每个已加载到其存储器中的给定组件以与其他组件进行通信，这些其他组件实现了给定组件本身操作所需的函数。

图3a至3c因此包括用于表示通信信道的箭头，这些通信信道是由系统在确定组件之间建立的，以允许它们将函数传送到另一个组件。

这些图还示出了系统体系结构的动态特性，如图3c所示的组件31可由组件32来替换以实现相同的函数，而无需要求改变任意另一个组件。在下文中将详细描述这些方面。

组件—通常需要考虑的事项■一般的定义

应该理解的是，组件是根据本发明的系统的基本构件，因此准确的定义它是很重要的。

本发明意义上的组件是一隔离的、独立的且自主的编码构件。如极其详尽的描述，根据本发明的系统的每个组件具有下列性质：

●它可实现唯一的函数，它专用于该函数，

●它可完全实现该函数。在单个组件中执行给定函数。在运行一应用程序或其他任何程序的过程中，如果一组件想要改变给定的函数，这可使不必对一个以上的组件进行修改或替换。

●正象目标的基本原理一样，由组件来实现给定函数的方式是不被使用该函数的其他组件所知，

●独立的编译每个组件，因此可形成一个独立的可执行文件，将该文件比拟为一囊组件(也被称为一“模块”组件)。在编译的过程中，不需对组件间的链接进行编辑。这允许由此以来的未被发现的灵活性，特别是根据可实现系统的基本函数并位于传统系统的内核中的组件，

●每个组件与可执行代码相关，借助于同样与各个组件相关的一接口程序可将该代码封装在其模块中。在设计组件的过程中，设计者借助于为了该应用程序所特定设计的描述语言来在由组件接口程序的源版本所形成的文本文件中描述该组件所提供的函数。该描述仅仅是对与该组件有关的系统有用的信息。该封装可保证不存在边缘效应并且不存在系统组件间的不可控制的互相依存。

根据本发明的系统组件因此是一个完全已封装(在模块中)的且借助于接口而与系统的剩余部分相隔离的软件目标，如所述的，该系统具有属性：

●复用性和模块性(在各种应用程序或各种更通用的程序中可采用一个和相同的组件)，

●与环境无关(每个组件被独立的产生并可在系统中被独立的加载和卸载)，

●动态链接(组件调停请求，且不是有系统的)，

●限定给定函数的范围。组件C包括两个主要部分，如图4所示：

●IMP部分，该部分可实现与组件有关的函数，且按照惯例将其称为组件的“执行部分”。该部分与将被执行以实现组件函数的代码相对应，和/或与硬件构件上所执行的硬件相对应。应将术语“代码”理解为一个或多个程序，该程序是由任一种本来就为人所知的语言写成，所述程序可实现与组件相关的函数并为此执行一个或多个函数。

●组件的“接口程序”部分INT，该部分是允许与系统的其他组件进行通信的说明部分。■组件的封装

每个组件被封装成一“模块”，链接目标文件的可执行文件与接口程序相对应并与组件的代码相对应。如上所示，按照自治的方式为每个组件生成该文件，而与构成根据本发明的系统的其他组件无关。

为了产生一组件，必须定义组件之外的函数并且在执行的过程中必须使用其结果；这在传统的函数分析方案的范围内。

另一方面，应该理解的是，根据本发明的系统保存由于该函数分析阶段而产生的语义信息直到组件的执行范围为止。

这非常有利于系统的升级并增加了其可读性。

借助于应用程序所创建的以及前面所提到的相关语言，在组件的接口程序源文件中描述了组件之外的函数。

更准确的说，与组件C相关的每个接口程序源文件INT可完整的描述该组件。它描述了必须从其他部件引入的接口程序构件以及那些输出到其他部件的接口程序构件。

如下文图5示意性所示，该文件将被编译(借助于编译文件MF，并调用文件编写)并与和执行部分IMP的代码(即组件执行部分的每一个源文件)相对应的目标文件相链接以形成模块M，该模块构成了组件的可执行版本。后面的文章中将说明创建接口程序源文件所使用的相关语言。

如所述的，模块M于是被加载到目标50(该目标被定义为计算机硬件，根据本发明的软件系统在该硬件上进行操作)，并立即由存在在该目标中的其他组件来识别。■组件的执行部分

执行部分IMP是组件的操作核心。该部分可有效的实现组件的函数。根据代码所采用的函数，可由该执行部分按照各种方式来实现该函数。

因此，然而当考虑到不同规范时，各种组件可实现一个函数以及相同的函数，该规范是在设计应用程序或设计包含组件的程序的过程中预先规定的，或者是在应用程序的实际执行过程中动态确定的。

以属性的形式描述了这些规范(例如空的、字符等等)，这些规范与组件的接口程序相关并且在下文中描述这些规范。

这规范被表示为这些属性中的一个属性的函数，在输出函数的组件接口程序中、在引入使比较操作符(如下文所述的<，>，＝，等等)与该属性相关联的函数的组件接口程序中定义了该函数。

同时，根据组件之外的规范的函数(例如硬件)或根据系统的当前状态以及执行过程中的应用程序来静态的或动态的处理系统或应用程序。

每个组件的接口程序文件因此提供了一组信息元(meta-information)，如所述的，该信息根据前面所提到的规范函数(该函数与组件的版本、该组件的位置、系统状态的数据项等等)可允许系统的特定组件以相关的方式来管理组件间的关系。

还应该指出的是如果由一代码(函数的“软件”执行)可唯一的实现每个函数，那么还可包括至少一个可实现函数的硬件构件(函数的“硬件”执行)。■组件的接口程序部分

接口程序部分可准确的描述组件提供了哪一个函数并且在其执行期间哪一个功能必须被提供。

按照由应用程序所开发的相关语言，它定义了所需的将作为组件输入的数据的格式以及由组件输出的数据格式。该格式仅仅取决于所实现的函数，并不取决于执行部分实现函数的过程。

该接口程序部分可构造由组件所实现的函数的说明，而与执行部分实现该函数的方式无关，无论代码以哪一种模式来采用函数，该函数保持不变。它可执行相同的处理操作，请求输入相同的信息并提供相同的输出数据。

因此接口程序部分可对系统进行充足的升级。因此由硬件执行在后面实现了函数的软件执行(对应于其执行部分是由代码所组成的组件)。

在这种情况下，对应的组件包括一接口程序文件，但是其执行部分由非常简单的程序组成，该程序描述了与硬件构件的链接。

相反，由函数的软件执行来替换硬件执行，而对其他组件不会产生任何影响。

在对组件的模块进行说明的过程中利用关键字“接口程序”来定义接口程序。

下面的表格描述了函数的各种属性；这些属性与组件(方向＝引入)或组件所提供(方向＝输出)的函数所请求的函数有关；

属性	方向	说明
			唯一的	输出	在本地系统中存在该接口程序的单一执行。该系统因此仅仅加载第一个执行并拒绝随后的一个。
外来的	引入	该接口程序是从另一个组件中引入的
			加载时间	引入	该接口程序被自动加载，同时作为使用它的组件
运行时间	引入	根据使用该接口程序的组件要求来加载接口程序(动态管理—参见与相关管理有关的段落)
			所要求的	引入	对于操作而言接口程序是不可缺少的。如果与该接口程序有关的函数实际上没有被引入，那么不加载该组件
多样的	引入	引入所有的输出该接口程序所要求的函数的组件

借助于各种属性在其文本文件中定义了接口程序。如下文所述的例子：

inprocess supervisor module{

interface component{

/*定义了被输出的接口程序*/

}

foreign loadtime required interface codec{

  /*定义了被输入的接口程序*/

}}；→接口程序的属性：

接口程序的属性可定义在该文本前面所提到的规范。与C语言一样(已注册的标志)，它们被分类。下面的表格描述了属性的各种类型：

属性	说明
		Void	空的(与C语言类型一样)
Char	8比特整数
		Short	16比特整数
Int，long	32比特整数
		Long long	64比特整数
Float	浮点数
		Double	双精度型(与C语言类型一样)
Sturct name	结构
		Union name	结构
String	由0所结束的UTF-8字符串
		Boolean	布尔型
Memarea	存储器区域
		Enum name	枚举型

下述扩展名与这些属性有关：

扩展名	说明
		signed	带符号的值(作为默认)
unsigned	不带符号的值
		const	常量

在接口程序文件进行相关说明的过程中，操作符可指定接口程序的属性。因此只有在其他接口程序的属性值与定义明确的规范相对应时，它们可允许引入另一个接口程序。

下述操作符与接口程序的属性相关：

操作符	说明
		In	该参数是输入(作为默认)
Out	该参数是输出并由所调用的函数提供
		Inout	该参数是输入/输出
＝	赋值操作符
		＝＝	同上的C语言
＜	同上的C语言
		＜＝	同上的C语言
＞	同上的C语言
		＞＝	同上的C语言
！＝	同上的C语言
		&&	布尔型AND该逻辑AND的结果不同于零
！&	&&的补该逻辑AND的结果是零

关键字“undef”可用作属性或函数的比较值。在下文的实施例中，所考虑的组件需要一个被命名为编码器/译码器的接口程序，该接口程序包括一个被命名为maintype的32为整形参数，它的值恰好是2。该接口程序必须保证得到可把一字符串作为参数并可返回一个32位带符号整数的一函数Func{}。

Foreign loadtime required interface codec{

    /*对引入的接口程序进行定义*/

    int mainType＝＝2；

    int Func(string name)！＝underf；

    ...

}

因此可通过对编程接口程序进行描述而实现被提供或被请求的函数的提供和要求。组件例如可提供“调度表”编程接口程序(该调度表允许创建/分解/操作过程和线程并使其相同步)，以及请求“存储器”接口程序(存储器管理)、“定时器”接口程序等等(时间定时器的管理，在给定时间之后调度表需要该定时器来中断一过程)。

这些编程接口程序包括以下两个方面：

●参数(版本、存储器管理类型、序列的参数等等)，

●以及组件执行时所调用的方法(函数)。

在提供和请求给定接口程序的过程中都需要利用参数，因此可明白这样一个事实，即与组件有关的存储器接口程序是在其版本1.5.2中(在提供接口程序的过程中所专使的一参数)；或者这样一个事实，即存在其版本至少为1.0.0然而并非1.0.4的存储器接口程序的请求，因为我们知道具有一个不可避免的“错误”(在接口程序请求过程中所专使的一参数)。

同时，接口程序的内容包括由程序员借助于为此应用程序所创建的语言而编写的一说明。

由相关的编译器按照二进制格式在与组件代码和有关数据相同的容量中来编译该语言，该二进制格式包括在由模块所构成的可执行组件中。

在执行时系统根据所要求的函数很容易的利用该二进制格式，使得与组件链接。

该语言还被用于指定组件包括哪一种类型的代码(“系统”或别的方式)以及哪一种类型的代码可存取给定函数(例如可为“系统”调用程序限制系统的“危险”函数)；这可选择最优化的通信设备。

组件—创建并加载到系统

现在根据图6，来详细描述创建根据本发明的系统组件的步骤以及在根据本发明的系统中实现其步骤的过程。

图6是一逻辑流程图，该流程图中的纵列表示在创建并开发根据本发明的系统组件过程中所使用的各个构件。从左到右，该表格因此由以下组成：

●与其组件相对应的两列“COMP”，最左列“INT”与接口程序部分相对应，而紧挨着一列“IMP”与执行部分相对应，

●用作组件编译文件的一文件编写列“MF”，

●与组件设计构件相对应的一“COMPIL DEP”列，该构件与编译器相关，该构件特定的由应用程序来开发以对组件进行编译，

●与已知文件类型的编译器相对应的一列“COMPIL CODE”，该文件由组件代码组成，

●与链接编辑器相对应的一列“LINK”，

●与根据本发明的系统的特定开发工具相对应的一列“KBIM”，该开发工具在设计项目(在下文中定义了该概念)的过程中经常被使用，

●专用于表示根据本发明的系统的一特定组件，并被命名为管理程序(或GD)一列“GD”，如所示的，该管理程序由根据本发明的系统内核组成，但是完全不同于现有技术的内核和微内核，

●与根据本发明的特定组件相对应的一列“LOAD”，加载程序可将系统组件加载到目标的随机存取存储区域中，

●最右的一列表示所描述的各种阶段。

■组件的创建

这里我们对“项目”作出一般性的定义，该项目表示在根据本发明的系统中具有共同目的的一组组件。项目因此与应用程序相对应，但是更一般的说该项目与由计算机系统所执行的并不同与该应用程序(例如外围设备管理程序)的任何类型的程序相对应。

在创建将在根据本发明的系统中所执行的项目以前，按照传统的方式，在步骤601执行函数分析(AF)阶段。

该阶段可定义所需的各种组件、它们各自的函数以及这些函数(该函数必要由其他组件来创建)的每一个相对应的需求。如所示的，可使用已加载到系统中的组件来为项目提供某一函数。

一旦执行了前面的分析，则可以知道与组件有关的需求，程序员为每个组件连续执行步骤602至606：

●在602，创建组件的接口程序源文件，在该文件中利用应用程序所开发的相关语言来描述组件的特征。在本文中稍后我们将回到该语言的特征和其主要的可能性，

●在603，程序员于是以一种或多种已知类型的语言来创建代码，即可满足组件函数需求的源文件。在该步骤的过程中，仅仅根据标准型来定义由组件所输出的函数，并不编写相应的代码。

当启动一处理过程时，应具体说明的是函数与将进行的一处理或一操作相对应(用法语来表示函数的说明)，例如存储器的管理，因此管理它们对目标处理器、图形显示器等等的存取。我们所称的函数即为还要负责处理操作的一软件代码。函数是可转换为函数的编程语言的软件(因此得名)。

在所有的编程软件中，按照与我们的系统完全相同的方法来负责处理函数。它包括：

√定义输入和输出参数(它们的名字和它们的类型)的一标准型。该标准型被链接到我们的组件(其作用是相同的)的接口程序部分，

√一代码部分。该部分对数据进行处理并且因此可确定在输出端所提供的结果。还应当具体说明的是函数的标准型定义了函数的名字、其输入参数(它们的名字和它们的类型)以及由该函数所返回的结果信息，

●在604，程序员创建一文件编写，在该文件编写中特别指出：

√在前面的步骤603期间所创建的源文件所使用的语言，

√与部件执行部件相对应的源文件，

√编译选项，

●在605，程序员利用相关的编译器以及与组件标准型所使用的语言相对应的编译器来创建，包括：

√由相关编译器对在602所创建的组件接口程序源文件进行编译所产生的目标接口程序。为了对该接口程序进行编译，相关编译器分析接口程序的源文件文本，并核实其连贯性，并且将其转换成可为GD所理解的二进制数据。相关的编译器自动产生用于调用函数的文件，该函数被在接口程序中所引用并提供给组件。

这些文件是由相关编译器所产生的“包括(include)”型文件。为每个代码实现语言生成了一个“包括”文件。这些文件的作用是在计算机系统中在该组件区域之外定义一个名称空间(即与其对应的上下文环境是相关的)并且与它该组件的区域不同，该名称空间使得所述组件可以访问其接口程序中所需的函数。因此这些“包括”文件的每一个定义可被组件接口程序所调用的结构，按照这样一种方式可将在接口程序中所生成的请求转换成实现语言所使用的结构和名字，该“包括”文件与该实现语言有关，

√在603所创建的每一个源文件的目标文件；在此时每个目标文件与其函数没有被完全编写的标准型源文件相对应，

●在606，程序员于是对组件执行部分的目标接口程序与目标文件之间的链接进行编辑，按照这种方式可产生一个可执行的组件标准型。

KBIM于是在607对标准型组件的全部组进行完整的测试，因此开发了所设想的项目，核实所创建的项目是否连贯且是否已结束(也就是说该项目所需的所有函数都存在于该项目之内)。

在进行完整的测试期间，KBIM备有所有组件接口程序的列表和说明。因此，KBIM在这些组件中搜索可实现该项目所需函数的组件。如果几个组件都可实现所需函数，那么KBIM促使程序员在这些部件中进行选择。于是将由KBIM所自动查找的组件或由程序员所指定的组件添加到构成该项目的组件中。该新的组件还需要KBIM企图将其解析的其他函数。KBIM于是可自动的解析一项目所需的大多数函数。

如果该项目没有被正确的结束，KBIM向程序员发出一个表示非连贯性的错误信息并且后者将返回到一系列步骤602至606，使得可修改应用程序的某些组件和/或添加一些组件；如果项目是连贯的且已结束，那么在608程序员通过在该执行部分的源文件中编写函数的整个文本而实现组件执行部分的代码的函数标准型。

在609，按照与创建可执行组件函数的目标文件代码相同的方式，程序员开发文件编写以编译每个独立的部件。在该步骤的过程中，文件编写产生了相关编译器以及用于创建代码的语言的编译器。对于当前正进行开发的项目的每个组件而言都重复步骤608和609。

在610，程序员于是开发链接编辑器以为每个组件创建一个可执行模块，所述模块与在编译步骤605和609过程中所创建的一组目标文件相关(在步骤605期间创建了目标接口程序，然而在步骤609期间创建与代码有关的目标文件)。

在与封装模块中的组件相对应的这种链接编辑过程中，编辑器核实由项目的各种接口程序所提供的各种函数事实上已完全在相关的源文件中有所描述并已被编辑。■组件的说明

因此一旦为项目的每个组件创建一个可执行模块，程序员必须声明存在这些组件，使得该系统要考虑这些可执行模块。在611执行该声明，在程序员将每个组件声明为一“载入程序”的步骤过程中，根据本发明的载入程序本身指定了系统的组件。

在步骤611的过程中，被声明为组件的载入程序将组件存储在载入程序的一个专用列表中，该载入程序汇集了在此所声明的一组组件。

步骤611是这样一个步骤，即按照一总的方式该步骤与当前正进行开发的项目有关，开发与被声明为至少是一个载入程序的项目相关的一组组件——每个载入程序与计算机的一介质相对应(磁盘、网络等等)，将与该载入程序有关的组件存储在该介质上。■将组件加载到系统

上述描述是用于创建并声明一“项目”的步骤，该项目包括几个组件。下面来说明开发图6的下半部所示的这些组件。

在620，组件C1调用它所需的函数F1。该调用引发了两种可能性：

●或者，利用组件接口程序中的“加载时间”属性来定义函数F1(上面已经描述了该“加载时间”属性)。在这种情况下，在加载组件C1之前，GD搜索可实现该函数F1的组件并将该组件加载到系统中。

√如果该组件本身需要“加载时间”函数，那么再次在加载组件C1之前，GD还加载实现该函数的组件。GD因此递归的加载为实现各种“加载时间”函数所需的所有函数，该GD将会遇到这些函数(下面将说明怎样将组件加载到系统中)，

●或者，利用“运行时间”属性来定义函数F1(上面已经描述了该“允许时间”属性)。组件C1必须明确的调用另一个函数、由GD所提供的“depmgr”以调用“运行时间”函数F1。为此，必须利用C1接口程序中的“加载时间”属性来声明绝对的“depmgr”函数，因此可利用该接口程序，只要C1被加载并被初始化(参见如上的“加载时间”函数的处理)。

C1于是可引入正在使用它的时刻由步骤620所调用的“loadtime”函数F1。于是由GD加载可实现函数F1的组件。如果在该组件被加载时它需要一个函数(在其接口程序由“loadtime”所声明的函数)，那么实现该“loadtime”函数的组件也将被加载。

因此GD递归的加载实现各种“loadtime”函数所需的所有函数，该GD将会遇到这些函数(下面将进一步说明怎样将组件加载到系统中)。只要已解析了在其解答过程中所遇到的所有“loadtime”函数，那么C1因此将获得在620开始所需的函数F1。如果未解析在C1进行加载过程中所要求的一个函数(该函数被声明为“loadtime”)，那么不加载C1。C1实际上不能实现其函数的任务，因为它不能使用其所需要的另一个函数。

如果该项目的一个部件没有实现C1需要引入的函数，C1属于该该项目并且将其声明为具有该项目的系统的一个下载程序，如所示的，该系统确定了可为C1提供该函数的另一个项目的组件。

为了这些被永久加载到系统随机存取存储器中的GD，通过其“链接图表”来搜索链接图表的一组件的接口程序目标文件是否表示该部件提供了C1所需的函数。

为此，GD对接口程序文件的“二进制”文本进行说明，该“二进制”文本存储在可执行组件中，并且在执行的过程中由“加载程序”将它加载到/传送到GD。

首先GD搜索与所需的(所引入的)一个接口程序具有相同名字的接口程序处理。当它发现相同的接口程序时，于是它在这些接口程序内核实存在所需函数的所有属性并且满足任一个限制和条件(比0.6.2具有更高的版本)。

GD链接图表是一列已被加载到系统中的组件，也就是说如上述步骤622所描述，不但未声明这些组件，而且其目标接口程序文件已被引入到对象随机存取存储器区域中，且这些组件与链接图表的另一个组件相连以调换所提供的/或所需的函数。

存储在对象随机存取存储器区域中的链接图表因此是已加载组件的瞬时像，该链接图表可被动态修改。该链接图表是唯一的并且与GD相关，该GD可访问该链接图表的信息。

如果在步骤621的过程中GD可确定由链接图表的一组件提供了由C1所调用的函数(将该链接图表称为C2“被调用的组件”，同时C1是“调用”部件)，它可通过在627将组件C2的特征引入到组件C1中而建立组件C2与组件C1之间的通信信道。

更确切地说，GD为C1构造了一个被称为“视图”的数据结构，该结构提供了与将要着手进行的引入而有关的视图。该“视图”包括所引入函数的属性值以及指针(或者该视图可直接影响诸如系统调用、线程移动等等的代码)。该“视图”直接起源于“include”文件中的相关编译器所产生的要素。

如果GD在621中确定了由C1所调用的函数不是由链接图表中的任一个组件提供的，那么它将一个接一个的查询系统的加载程序列表，因此可确定被声明为加载程序的一个组件是否提供了C1所需的函数。步骤622表示对载入程序的查询。

在该查询过程中，GD利用一“加载程序”函数，该函数对每个“加载程序”所查看的一系列组件所需要的函数进行处理。该“加载程序”函数允许GD将加载程序组件所输出的函数与所要求的将被引入的函数进行比较。它还允许GD加载和卸载单独的组件，来自介质的加载程序与对象随机存取存储器有关。

应具体说明的是根据本发明的每个系统加载程序与可存储组件的介质相关；对于每个加载程序而言它因此与存储器磁盘有关，或例如与CD—ROM型的任一个其他记录支持体有关。尤其根据附图7对多个加载程序进行说明。

如果该组件位于系统的一系列加载程序的一个中(步骤623)，那么在625中其列表包括该组件的第一加载程序将已确定组件C2的目标接口程序传送到相关管理程序，并且在626中GD自身将该组件C2的“视图”传送到组件C1(步骤627)。

在加载组件C2时，GD已将C2的“视图”存储在系统存储器区域，该“视图”是由GD动态创建的，并且在卸载该组件的同时将破坏该“视图”。该区域与可访问该区域的组件同处于相同的地址空间。

如果在步骤623的过程中GD的搜索可确定位于一个加载程序的列表中的可提供所需函数的组件原来是无效的，那么系统在624而停止。

在任何情况下，将组件C1加载到系统的随机存取存储器中可引起GD自动搜索可提供函数F1的组件C2，该函数F1是组件C1进行操作所需要的。

同时，如果组件C1调用不仅仅一个函数而是几个函数时，同样的GD将执行自动搜索可提供这些所需函数的组件。

值得注意的是，与已知的系统相比，根据本发明的系统可提供附加灵活性的等级。

实际上，在利用实体所构造的已知系统的情况下，程序员必须为每个给定调用实体指定系统的一系列其他实体，这些其他实体是所述调用实体的操作所需的，并且这些其他实体不得不被加载到系统中以为了该调用实体的适当操作。

因此，在这些已知系统的情况下，通常不用函数来表示实体的需要，但是用特定实体来表示实体的需要(例如这是java语言的情况)。

同样，在本发明的情况下，几个不同组件中的每一个往往都与调用组件C1有关，因为所述不同的组件提供了相同的函数。

同样，本发明的其他优点是从与组件有关的规则中派生而来的，在GD自动搜索可提供第一组件所需函数的组件的过程中GD要考虑这些规则。

实际上，在搜索组件的过程中GD不但搜索可提供所需函数的组件，而且还更准确的搜索可提供与特定条件有关的所述函数的组件，该特定条件是根据本文前面所提及的规则来表示的。

在现有语言的情况下(例如Java语言类型—注册商标)，实际上，程序员必须绝对在调用实体与被调用实体之间创建一个明确的链接。因此很显然的是不能按照可提供与本发明相同灵活度的方式来开发这类已知系统，本发明本身可提供更好的维护以及升级(例如可产生已增强的版本)，在该发明中可按照不同的方式由可实现相同函数的其他组件来代替可提供所需函数的组件，或者增加了可实现所述函数的新组件以至可将所选择的新的可能性提供给GD。

这样，本发明极其的构造了可改进的系统，在该系统中可随意替换仅仅一个或多个所希望的组件。

每个已替换组件提供了一函数，该函数已由被替换的旧组件来提供。

然而，可随意的修改可实现该函数的特定装置，该装置可以是软件和/或硬件。

在对应用程序的体系结构中，这种可能性尤其有利。该应用程序是诸如对安装在各个站点的系统网络进行维护或对移动类设备(例如移动电话或个人管理器)进行维护，为了对这些应用程序进行升级因此不希望一个应用程序物理的返回到中心站点。

因此，可通过简单的将来自中心站点的一个或多个新组件下载到这些设备中而对安装在上述类型设备中的应用程序进行升级，而无需不必将其物理的移动到分布在任一区域上的设备。

而且，替换这些组件不需要对使用它们的计算机系统进行重新编译。

在可提供C1所需函数的组件C2已被确定(或许规则满足接口程序(1)所需的条件)且在627将C2的特征引入到C1中的情况下，根据组件C2已形成或未形成链接图表的一部分(步骤628)，相关管理器将进行不同的操作。

如果C2输入链接图表，那么GD直接进入步骤633以创建C1和C2之间的通信信道。为此，系统或者使用上述四个通信模式中的一个，或者使用特定创建的一特定模式，例如在C1和/或C2的接口程序中所指定的特征函数；＝＞直接调用

这是一种快速方法。直接调用所需的函数或方法，并且直接返回其结果。这不存在中间编码。当两个组件位于同一个设备上时的相同地址空间并处于相同特权级别上时，相关管理器选择该装置。

将地址空间定义为逻辑存储器区域，该区域中的代码地址或数据地址意味着可使所有组件访问该区域。指向代码或数据的指针按照从一组组件到另一个组件的方式来传递，而无需修改其值，指针可访问相同的数据。

在本发明中，术语“地址空间”还意指公共的特权、定义一“空间”的地址空间或具有相同特权级别的一类目标；可按照相同的方式由各种组件来访问被指向的一个目标以及相同地址空间。

同时，例如因此可利用较低级别的特权来定义一“用户”空间，并用较高级别的特权来定义一“管理程序”空间。

利用可同时访问两个空间的计算机系统的处理器来对每个过程的“用户”空间与“管理程序”之间的一致性指针进行编译，但是“用户”数据不能引用位于“管理程序”空间的数据。

特权是组件间进行访问的可能性；在源接口程序中可利用下述特权级别：

级别	说明
		处理中	执行位于相同地址空间的模块，因为它是调用方。
生产	在其自己的处理过程中执行组件，在其加载过程中创建组件。应当指出的是当加载标识有“spawn”的组件时，GD自动请求一个专用于调度的“调度程序”组件以创建一个由C1启动的过程以及一个对应的地址空间。组件因此包含在该过程的地址空间中，并且假借有源构件(这可执行处理操作而无需除启动组件之外的任何操作)并非无源构件来进行操作，如组件未表示“spawn”的情况(该组件仅仅等待被调用以便执行一处理操作)。在步骤621之前，GD区分组件的该特权级别。
		输入输出	模块执行输入/输出操作(驱动器)。
管理程序	必须在管理程序的模式下执行组件(最高特权级别)

为了将这些特权级别中的一个分配给组件，程序员在对组件的模块进行定义的过程中固定对应参数，将该定义限制在正文类型范围内：

inprocess supervisor module{

/*对模块进行定义*/

}；

因此，通常，给定的特权级别可与每个单独组件相关、与以该组件访问其他组件的可能性为条件的所述特权级别相关，如所述其他组件的各个特权级别的函数。

另外如所述的，组件的特权级别的相关性给出了该组件由某一组件的接口程序所提供的“视图”函数的可能性，如实际上与这些其他组件相关的特权级别的函数。

同时，如以下所述，由与某一特定组件单独相关的运算符来短接组件间的由特权级别所建立的访问次序，该特权级别与各个组件单独相关。

下面是该调用的例子：

●管理程序组件调用管理程序组件，

●用户组件(来自较低特权级别的组件)调用位于相同地址空间的用户组件(如利用了用于管理共用信息库以及无源函数的组件的应用程序)。

如果存储器部件未提供保护，那么该方法是所采用的仅仅一个方法，这可对为其产品而构造系统的技术人员进行选择，因此在缺乏保护的情况下可提供极其快的系统。

当该组件仅仅提供了一个地址空间时，存储器组件不能提供“系统”型的保护。这种类型的存储器管理未提供保护(在同一空间内的所有操作并可能损坏或修改属于其他组件的代码或数据)，但是这仅仅是某一对象未处理任何“MMU(存储器管理构件)”的一种可能。＝＞系统调用：

将请求转向到一系统调用。后者将来自用户堆栈的参数传输到管理程序堆栈，改变特权的级别，生成一调用，返回特级的较低级别并直接返回结果。

当用户组件(非特权的)调用管理程序组件的函数时选择该方法，只要该函数授权非特权组件以可使用它。

在相关描述语言的标准下通过关键字“promote”来进行该授权。同时，一般说来，下述关键字与一组件有关(在由应用程序所开发的语言的语法中，关键字被简单的放在属性或方法的前面，他们将改变其方法的操作方式)：

关键字	说明
		promote	这可从用户组件中调用在“管理程序”组件中所实现的函数。
untrusted	与promote一样，但是无需自动转换到管理程序模式。
		async	立即退还调用部分并并行的继续对函数进行处理：在这种情况下，通过“视图“的间接调用在用于创建一线程的GD代码处结束(该GD本身也条约上述讨论的函数)并立即移交(在所

	创建的线程中继续执行)。
		serial	禁止与函数同时作用的调用(保持其他调用部分将被装入)

因此，通过关键字“promote“所配置的上述已提及的授权可短接在别处所建立的特权级别，以便可单独授权一组件可访问另一组件，对于另一组件而言其自身的特权级别不能使它访问。＝＞线程的转换

根据本发明的系统将执行线程的逻辑管理(标识符、优先权、系统堆栈等等)从其物理管理(处理器环境、用户堆栈、包含线程的地址空间，等等)中分离出来。

当组件调用位于另一地址空间的函数并且是同步(调用方是处于待定结果的程序块)时，调用方“转移”成被调用方并且执行处理。

为此，线程的逻辑部分“层叠”其当前的物理部分，并将其自身加入到在被调用方的地址空间中所创建的新物理部分。

于是在被调用方的环境中执行所需函数的代码(也就是说在相同的地址空间和相同的包含过程中)，但是在调用方的逻辑线程中。一旦该函数结束了，调用线程使其原始的物理部分“出栈”并再次“转换”为调用方。

线程转换代码还用于在对存储器区域进行拷贝或重映射这两个方向上发送参数以及被提供作为参数的字符串等等。

该机制避免了代价更大的传统方法，该方法包括组合一消息、将消息发送到位于被调用方的线程、中断调用方的线程、分解被调用方的消息、执行所需函数、根据其结果来再组合消息，根据其结果来再分解一消息，唤醒调用方、再次中止被调用方。

该机制还可以避免与同步传送消息有关的许多问题，例如优先权的逆转(这里，利用调用方的优先权来执行被调用方的函数)、资源的计算(在调用方对机器时间进行递减计数)、以及所必须的维持被调用组件中的线程“存储区”，该被调用组件处于睡眠状态，占用了不必要的存储器资源直至接收到调用，以及如果发生大量调用，则存在不够充足的资源量问题(这里，调用方转换为被调用方，总是存在所需线程的精确数目)。

该方法可极大的优化地址空间之外的调用这种最常见的情况：在同一机器上进行同步调用。＝＞消息的传送

与基本的微内核系统的情况相反，例如，在该系统中该方法是有组织的被采用，它仅仅用于未在上述类别范围内的调用，例如：

●异步本地调用(调用方未保持待定结果的程序块)，

●对另一机器的远程调用。

消息的传送包括对消息中所提供的参数进行编码、将消息路由到目的地组件、对其进行解码、执行函数、将结果存储在消息中，将其返回到调用方。如上所述，该方法尤其适于异步调用(稍后将发送结果信息)，并适于远程调用，按照任何一种方式该方法都需要构造网络包。

返回至根据图6所给定的说明，一通信信道的创建是与函数的调用有关以将调用组件C1记录在被调用组件C2的执行部分。

被命名为Register()的函数除了它们自己的特定函数之外还形成了“组件”函数的一部分，该函数是由系统的所有组件提供的。该“组件”函数包括四个函数：

●初始化，

●去除初始化，

●记录，

●去除记录。

如果GD在628确定组件C2没有形成链接图表部分，那么在629它调用组件C2的加载程序，使得将C2列入到对象的随机存取存储器并在631更新该链接图表。

因此图7说明了链接图表G，，GD将一组件或来自第一加载程序的存储器区域72的组件集P2引入到该图表中，因此允许C1已存在于该链接图表中(C1先前已从另一加载程序的存储器区域71中被引入，它形成了具有另一加载程序的项目P1的部分)以与被调用组件C2相连，在步骤623的过程中已由GD确定了该组件C2以在加载程序中搜索可提供C1所需函数的加载程序。

实际上再次调用在步骤607由KBIM所执行的完整测试过程中(参见图6)，KBIM核实由一组件所调用的每个函数不是绝对的由一个和相同项目的一组件来提供的，但是一般来说是由加载到软件系统的一组件来提供的。

再次返回到图6，已描述过步骤631导至步骤633。

同时，尽管已描述过对由组件C1所调用的组件C2进行加载，但是应当理解的是组件C1本身已被另一个组件调用，并且应当理解的是当引导系统时它必须对函数的调用进行初始化。

为此，当启动一应用程序时，GD需要一“交互”函数并搜索可提供该函数的组件。GD还可引入需要该函数的组件。在所有的情况下，该“交互”函数将调用另一组件，该另一组件依次调用至少一个其他组件。相关管理器

已说明了相关管理器是一个被永久加载到根据本发明的系统中的组件。它可构造各种组件之间的链接，各种组件构成了一应用程序；由组件的接口程序建立了这些链接。

根据本发明的有利方面，仅仅那些在应用程序和系统的操作方面所使用的组件将被加载，因此可优化所需的资源。根据下述模式的一种可实现这种优化：■在执行的过程中自动加载组件

当组件被加载使得被执行时，相关管理器分析用其接口程序所表示的其相关性并且自动设法对其中所表示的所有相关性进行解析，也就是说为该组件提供它所需的所有函数，并且还通过同样也设法提供每一组件而“结束”相关系统，因此可采用它所需的函数。

因此GD可自动的将组件加载到链接图表中，该组件用于解析所引入的其属性为“loadtime”的接口程序，并且GD还解析它们的相关性并创建这些各种组件间的通信信道，如它们各自位置的函数。

因此根据上述所定义的任一种通信模式来创建通信信道；它包括可调用与参数有关的函数的任意数据的传输路径(特定的每一个通信模式)，并覆盖由函数所执行的处理所产生的返回值。

只要通信信道被创建，组件可直接与另一个组件通信。■动态的加载并卸载组件：

当所引入的接口程序具有“runtime”属性时，使用该接口程序的组件将请求加载可执行该接口程序的组件，仅仅当该组件需要与该接口程序有关的函数时。因此该“runtime”属性是上述已描述的“loadtime”属性的备选项。

该管理可准确的确定可执行该接口程序的属性，该接口程序必须被加载，如动态参数的函数，当加载需要该函数的组件时这些参数是不为所知的。

例如，“文本”组件可引入编码/译码接口程序，因此可对它所接收的文件进行解压缩，该“文本”组件可接收几种类型的文件。

在接收文件的过程中，“文本”组件可搜索适于对该文件进行解压缩的编码/译码接口程序，如其扩展部分的函数。为此，它使用相关管理器的Query()函数，将搜索参数传送到它。

因此它借助于Open()函数命令相关管理器来加载组件。它因此可使用该组件的编码/解码接口程序以对文件进行解压缩。

当解压缩结束时，“文本”组件要求对所使用的编码/译码组件进行卸载。

因此它可动态的加载一组件。这可允许组件被加载，仅仅当需要这些组件来执行一处理时。因此当该组件的处理结束时该组件被卸载。

根据另一实施例，在下载图像的过程中应用程序可显示该图像并且随后不必对图像的格式进行处理或特别对它们进行处理。

因此该应用程序动态的下载组件以对图像格式进行处理、请求它处理文件使得可显示图像，并且该应用程序随后将该组件卸载。只有当绝对需要该组件时，才将该组件加载到存储器中，这可使在各种组件中公用存储器资源，如在给定的瞬间进行处理操作的函数。

因此该方法可对较大的减少所需的存储器资源。

相关管理器还可自动管理加载和卸载组件以作为它们使用的统计量和存储器资源的函数。该管理于是对与应用程序的程序员而言是完全透明的。

图8的图表给出了对拥有几种存储器资源的一系统的组件进行动态管理的益处。在该实施例中，应用程序像显示了两种图像，一GIF和一JPEF。顺序处理每个图像，因此可动态的加载并卸载组件。

在该实施例中，对组件进行动态的加载和卸载可减少所需的最大存储器资源。

另外，在大多数情况下，就性能而言该加载和卸载不是显而易见的。

实际上，组件的模块具有已减小的大小(大约从几百字节到几千字节)。因此将它们加载到存储器的操作是执行速度非常快的一个操作。另外，大多数应用程序顺序执行处理操作并且通常是由用户提供了输入信息并且将输出信息提供给用户。

因此，在人类的尺度上，加载并且卸载组件所需的几微妙实际上是不能被感觉到的；在图8所示的实施例的情况下，根据下述顺序来执行操作：

●加载图像(加载JPEG代码)，

●在显示屏上显示该图像，

●用户，

●加载另一个图像(卸载JPEG代码并卸载GIF代码)，

●显示另一个图像。

与其他的处理操作相比，加载和卸载时间是微不足道的。■由相关管理器来优化资源

相关管理器管理每个组件的惯用计数器。该计算器对组件的“引入者”数目进行计数，也就是说从与计数器相关的组件中引入了一函数的组件。只要一组件的惯用计数器减小到0，则卸载该组件。

当不再使用一组件时，相关管理器可自动的释放由该组件所使用的资源。

值得注意的是本发明因此可尤其对系统所使用的资源进行有效的优化，而无需装载系统操作的通用方式。

实际上，已知系统通常采用周期性的装置以检验组件的状态，定期“接管”的特定任务采用所述装置，使得可确定必须被卸载的组件。

这些的定期检验任务不完全适于实时的，因为它不能利用好的反作用性来修改将被追踪的组件状态。

此外，该类型的操作方式需要多任务的环境，因为存在核实任务。

在Java语言中可得到对采用定期检验这类操作方式的说明，检验任务采用了“不用构件收集程序”型的构件。■与硬件构件所负责处理的函数有关的说明：

已经陈述了组件的执行部分与一代码相对应(该代码包括一个或多个程序，因此可实现组件的函数)，但是它还与一硬件执行相对应，该硬件执行是基于包括有电子电路的硬件构件。

因此，可由组件C1来负责处理一函数，该组件C1利用电子电路来执行它(例如视频解压缩电路)。然而，该函数还可由只基于软件而执行它的组件C1负责。如果对一应用程序而言实际上存在该电子电路并且正确的操作，那么系统将使用该组件C1。另一方面，如果不存在电子电路或者如果该电子电路不能被正确的操作，那么系统按照对另一组件透明的方式来使用组件C1＇。在所有的情况下，函数都被负责处理。

同样的，如果目前由软件代码来负责处理函数，那么它稍后将由利用一电子电路可实现它的一组件按照对另一组件完全透明的方式来负责处理。

图9的框图说明了组件C1由另一组件C＇1来代替，该C＇1输出了相同的函数。

如900所示，当前C1正在执行，拥有与C1进行通信的信道并因此在链接图表中与它相链接的组件C2在901请求用C＇1来替换C1。

GD于是请求C1保存它的当前状态(步骤902)，这是由C1在步骤903负责处理的。GD因此记载并初始化C1＇(904和905)。

如果未正确的执行C＇1的加载和初始化(步骤906)，那么GD将一个错误返回到请求方C2。

如果正确的执行C＇1的加载和初始化，那么GD在908将C1的当前状态传送到C＇1，因此C＇1配置了与其本身相同的状态。

为了这些目的，C＇1对所传送的当前状态进行说明并接受它或拒绝它(910)。

如果C＇1拒绝了它，则GD卸载C＇1(911)并去除初始化(912)。GD于是将一个错误消息返回到请求方(913和914)。

如果现在C＇1接受了C1的当前状态，那么GD通过用C＇1替换其中C1来更新其图表(916)。它因此为C＇1重建了通信信道；这些信道是C1所使用的那些信道。因此GD去除初始化并卸载C1(918和919)。

一旦替换操作已被正确的执行，GD将通知其中的C2(920，921)；后面将继续它的操作。

如上所述的是根据本发明的系统以及其中的应用程序的基本原理(根据图6位于其他事物中)。

假设我们指定它还可使组件C1的接口程序参数化，因此当GD搜索可输出由C1所引入的函数的一组件时，在与图6的步骤627相等价的步骤中，它继续在已被加载到系统中的一组组件中搜索并将链接图表的可输出该函数的每个组件的“视图”传送到C1。

作为参数化的选择规则的函数，C1将在由CD所确定的这些组件当中为其选择一个适当的组件。

假设我们还指定，在其当前版本中，根据本发明的系统需要最少四个组件以操作，如图10a所示(在该图中箭头表示在组件间传送的函数—这类图因此表示链接图表)。

存在下述组件：

●“交互作用”，如已陈述的，为了对系统的操作进行初始化则需要该“交互作用”，

●“往复移动”，这被“交互作用”所调用并且其本身也调用下述两种组件：

●GD，

●以及最终的“VMM”，同样还调用GD的所谓存储器组件或存储器管理组件。图10b给出了类似的系统的最小配置，在该配置中增加了三种组件“CPU”、“TIMER3”、以及“SCHED”，因此可允许多线程管理。

最后，图10c表示对根据本发明的系统进行改进的配置，该配置形成了一个小的应用程序。

在该图中，“交互作用”组件使用“COM”组件来进行通信，因此可在网络上交换数据并且使用“GUI”(图形接口程序)组件以显示图形表示。

“MOUSE”组件可管理MOUSE外围设备。它传送与该外围设备的状态改变有关的信息(移动，点击按钮)。“GUI”组件使用“WINDOW”以及“BUTTON”组件以执行“INTERACTION”组件所需的显示。

“WINDOW”和“BUTTON”组件使用GIF和JPEG编码/译码组件以在它们各自的显示区域来显示图像。

GUI、COM、WINDOW、BUTTON、GIF以及JPEG组件都使用系统基本组件的函数。然而，在图10c中未表示与这些函数相对应的链接，因此该图没有过载。

将组件分类成函数域，这些函数域不是域特权级别相对应的类别，但是是一种使用类型。如下是各种与某一组件相关的函数域：

函数域	说明
		SHEDULE	调度程序组件—MULTILEVEL
GESTION MEMOIRE	存储器管理组件—VMM—PCI
		BUS	总线管理组件—ISA—PCI
COMM	通信组件—ETHERNET—FTP—IPSTACK—SERIAL
		INPUT	输入系统管理组件—ELOTOUCH(触感面板)—KEYMAP—PCKBD—PS2MOUSE(PS2鼠标)—REBOOT(看门狗)
GFX	图形接口管理组件—GFX—BUTTON

	—WINDOW—SCROLLBAR—TEXT—IMAGE
		SON	音频管理组件—AUDIO编解码器
IMAGES	图像和视频管理组件—JPEG编解码器—GIF编解码器—PNG编解码器—BMP编解码器—MPEG编解码器
		FILE SYSTEM(FS)	磁盘管理组件—FAT—HDD—CD

值得注意的是由于根据本发明的系统的所有组件是根据相同的形式来实现的，因此系统按照相同的方式来管理所有的组件并且按照相同的方式将上述所提及的组件的有用参数应用程序到组件，而不管它们的特权级别。

最后，显而易见的是根据本发明的系统可使：

●对于程序员而言，具有对操作系统所有构件的一个概观，而不管它们的特权级别，

●使用相同的工具可创建这些各种组件，

●影响各部分之间的交互作用，而无任何限定。由系统组件的数目来表示系统的功率，但是在传统的系统中(单片和微内核)用可能互连的数目来表示，各部件间的通信装置受限制的且是固定的。它需要通过任意的瓶颈而有系统的进行(内核数目的限制，无论这是单片内核还是微内核，等等)。通信装置的相关管理以及动态创建可克服上述限制，

●为所有类型的代码提供相同的属性。在本发明的情况下，存在这样一个事实，即不再需要设计一个用于管理内核模块、信息库、或甚至是应用程序“插件”的系统。上述所有这些都被组件管理系统所代替。

●在将来可创建与需要实现的函数一样多的组件。这可使对根据本发明的系统进行完全升级。

另外，如这里所描述的，本发明通过在许多情况下返回错误信息而为开发者提供了极大的可读性和反应性。

实际上，在加载组件的过程中，为该组件自动执行一函数(Init)。该函数(Init)检验已加载组件的操作所需的一组组件实际上已加载到系统中。在这样的一种情况下，即该检验不能满足(至少一个所需函数还未实现，或者提供所需函数的组件与有缺陷的硬件构件相关，等等)，那么将一个错误消息返回到调用方。

另外，在被调用组件与有缺陷的构件(硬件和/或软件)相关的情况下，它被自动的加载到系统的随机存取存储器中。

此外，根据附图9可知，当组件被调用时还返回错误消息。

因此，如果不存在硬件或软件构件或者硬件或软件构件在操作调用组件时是有缺陷的，因此错误消息继续是一个已被通知的消息，而无需系统测试的整个操作。

Claims (29)

1、用于开发将由计算机系统所实现的计算机项目(P1、P2)的处理方法(process)，该处理包括为了对满足需求的函数进行分类而进行的函数分析阶段(601)、借助于计算机设备来创建项目组件(C1、C2)以实现所述函数的阶段、对创建阶段期间所创建的组件的相同系统进行说明的阶段、以及将所述组件加载到系统存储器区域以由计算机来实现其组件的阶段，

其特征在于

●在组件创建阶段期间，每个函数是完全由与此相关的组件来实现的，

●在组件说明阶段期间，所创建的每个组件被声明为系统载入组件，并且

●在组件载入阶段期间，提供了可自动搜索可提供所述函数的组件的装置，

  这与已载入组件所需的函数有关。

2、根据在前权利要求的处理方法，其特征在于执行所述自动搜索，同时也要考虑到条件。

3、根据在前权利要求的处理方法，其特征在于所述条件被表示为一个规范函数，该规范函数以逐一与各个组件相关的属性的函数的形式来表示。

4、根据在前权利要求的处理方法，其特征在于在创建组件的过程中，执行下述步骤：

●创建组件的接口程序源文件(602)，以便形成组件的“接口程序”部分(INT)，

●创建至少一个可实现组件函数的代码源文件(603)，以便形成组件的“执行”部分(IMP)。

5、根据在前权利要求的处理方法，其特征在于为了形成组件的“执行”部分所创建的每个代码源文件可由任意一种编程语言来创建。

6、根据在前两项权利要求其中之一的处理方法，其特征在于每个组件可通过开发软件和/或硬件装置来实现与此有关的函数。

7、根据在前四项权利要求其中之一的处理方法，其特征在于每个组件的接口程序文件包括对所述组件所实现的函数进行说明，而与组件实现该函数的方式无关。

8、根据在前权利要求的处理方法，其特征在于接口程序文件还包括对该组件必须从其他部件所引入的函数进行说明以便实现其自身的函数。

9、根据在前权利要求其中之一的处理方法，其特征在于由可输出相同函数的另一组件(C＇1)来动态的替换每个组件(C1)。

10、根据在前权利要求的处理方法，其特征在于所述替换采用了下述步骤：

●保存将被替换的组件的当前状态，

●加载并初始化新的组件，

●将被替换的组件的当前状态传送到新的组件，

●在调用函数的组件和新的组件之间建立通信信道，

●卸载将被替换的组件。

11、根据在前权利要求的处理方法，其特征在于如果不能正确的执行加载或初始化新的组件，那么提供了用于返回错误信息的装置。

12、根据在前四项权利要求其中之一的处理方法，其特征在于在创建组件的过程中，还执行下述步骤：

●创建一个文件编写(604)，在文件编写中指定：

  √在代码源文件的创建过程中用于创建源文件的语言，

  √与组件的“执行”部分相对应的代码源文件，

●创建组件的标准型(605)，

●对组件的“接口程序”部分和“执行”部分之间的链接进行编辑(606)，因此产生可执行的组件标准型，

●采用文件编写使得逐一对组件进行编译(609)，并分别形成了组件“接口程序”部分的接口程序源文件以及组件“执行”部分的每个代码源文件的目标文件，

●将前述步骤过程中所创建的目标文件封装成一个单一的可执行模块(610)。

13、根据在前权利要求的处理方法，其特征在于在创建组件标准型的过程中，所创建的标准型包括：

●由于对组件的接口程序源文件进行编译而产生的目标接口程序，

●与组件“执行”部分的每个代码源文件有关的标准型目标文件。

14、根据在前权利要求的处理方法，其特征在于在编译组件接口程序源文件的过程中，执行下述步骤：

●对接口程序源文件的连贯性进行分析并核实，

●将接口程序源文件转换成二进制数据，

●自动生成至少一个文件，因此可调用将被组件所引入的函数。

15、根据在前三项权利要求其中之一的处理方法，其特征在于在对组件的“接口程序”部分与“执行”部分之间的链接进行编辑以产生可执行组件标准型之后，执行自动完整的测试步骤(607)，在执行该步骤的过程中核实该项目是否是连贯的且是否已结束。

16、根据在前权利要求的处理方法，其特征在于在自动完整的测试过程中，对于该项目所需的每一个函数而言，存在从一系列可访问的组件中搜索一个可完成所述函数的组件。

17、根据在前权利要求的处理方法，其特征在于在可完成所需函数的几个组件都被确定的情况下，从这些组件中选择一个特定组件。

18、根据在前两项权利要求其中之一的处理方法，其特征在于在完整测试显示出该项目没有正确结束的情况下，发出一个表示不连贯性的错误消息，因此可对确定的组件进行修改和/或增加一些组件。

19、根据在前七项权利要求其中之一的处理方法，其特征在于对于已加载到系统中的每个组件而言，对该组件为了实现其自身的函数必须从其他组件所引入的函数进行的说明是可永久的访问所述用于自动搜索组件的装置(GD)。

20、根据在前八项权利要求其中之一的处理方法，其特征在于在将前述步骤期间所创建的目标文件封装成单一可执行模块的过程中(610)，可核实由项目的各种接口程序部分所提供的所有函数实际上都已在相关的源文件中有所描述并已被编译。

21、根据在前九项权利要求其中之一的处理方法，其特征在于处理过程包括将加载到系统中的组件的映射(G)存储在系统的随机存取存储区域中。

22、根据在前权利要求的处理方法，其特征在于当调用组件调用函数时将参考所述映射，因此可确定所述映射的组件是否可提供所调用的函数。

23、根据在前权利要求的处理方法，其特征在于所述自动组件搜索装置(GD)可参考所述映射。

24、根据在前三项权利要求其中之一的处理方法，其特征在于与加载到系统中的组件函数一样，在系统的操作过程中实时更新所述映射。

25、根据在前权利要求其中之一的处理方法，其特征在于与所述其他组件的各个特权级别的函数一样，每个组件与一特权级别有关，该特权级别决定了组件访问其他组件的可能性。

26、根据在前权利要求其中之一的处理方法，其特征在于提供了用于自动卸载每个组件的装置，对于计算机项目的操作而言不再需要在该组件所提供的函数。

27、根据在前权利要求的处理方法，其特征在于所述装置包括每个组件的使用计数器。

28、根据在前权利要求的处理方法，其特征在于所述计数器对引入与该计数器有关的组件的函数的组件数量进行计数，并且只要所述组件的使用计数器减少到零那么就卸载该组件。

29、根据在前权利要求的处理方法，其特征在于提供了用于自动释放所述已卸载组件所使用的资源的装置。

Images