计算机软件的一个方面是必须通过修改、增和/或减来对它进行周期
性的更新，以便继续为用户提供适当的功能、使软件最优化、以及改正
在软件使用过程中出现的错误和差异。当软件中加入了新的特征后，为
了给用户提供新软件的特征，需要尽快用新版本取代旧软件。
在某些类型的计算机系统，如独立或批处理系统中，将软件从一个
版本变为另一个版本几乎没有任何障碍。典型的处理方式是在一天中没
有什么任务的时间关闭计算机系统，并且维修人员随时待命，然后将旧
软件去掉，换上新版本软件，此后重新启动计算机系统，所有未来的数
据处理都由新版本软件来进行。当然，这一处理过程假定新软件已经在
一个脱机系统中作了适当的检测和调试，使得软件人员和运行管理者相
信该软件会适当地执行它所赋予的功能，而不会出现需要整个计算机系
统暂停并重新启动的不适当中断。
在其他类型的计算机系统，如现代化的存储程序控制(SPC)电信
交换系统(在工业界简称为“交换机”)中，在系统中检测新版本软件
或改变软件都不如在独立或批处理系统中那么简单。例如，如果不放在
实际的操作处理呼叫中，新的软件版本就不能有效地进行测试。而软件
必须在运行时进行测试，以便确定它在实际操作条件下是否会适当地运
行，以及新的软件部分是否能与构成运行的SPC交换机系统一部分的所
有其它软件块适当接口。另外，电信交换机系统事实上从不停止运行。
由于人类社会对电信服务的持续需要，理想的情况是这些系统永远不停
止运行，没有任何中断。也就是说，即使在下班时间或晚上，系统中也
有持续的电信业务量在进行处理，交换机操作的任何中断都会导致电信
业务不希望的破坏，这种破坏会严重地损坏系统的操作和效力以及系统
用户对它的认可程度。
电信交换系统的这些实时要求给包括新的或改进功能的软件强化
版本或其部分的测试、以及在交换机中包括错误校正或“故障修理”的
软件替换而不破坏交换机处理的现有电信业务量做了严格的限制。因
此，采用传统的“编辑--编译--连接--装载--运行”方法将新版本的软件
成分或单元集成到系统中是不符合要求的。
在运行的计算机系统，如电信交换机中替换软件的另一个问题
是旧软件中的进程与新软件中的进程之间的状态转换，特别是它们的同
步。一个进程使用或包括资源对象，该资源对象是在一个硬件资源或内
部数据结构中处理信息的对象类型。在本发明中应该理解状态转换是资
源对象的状态转换。一个资源对象的状态具有分配或解除分配的特征。
在旧软件中的进程和新软件中的进程之间的状态转换对系统的用户是
必不可少的，原因是资源对象的状态可以由多个事务利用并存活。进程
的状态随时间变化，这使得它不能事先将这些进程的状态结合到新版本
软件中，从而如果它要存活下来的话，它必须在旧软件与新软件的替换
过程中从旧软件转换为新软件。人们所欢迎的是这样一种方法，该方法
提供这样一种可能性，即在系统运行时与旧版本软件和新版本软件的状
态转换一起修改或扩展软件，而不需要任何停机时间。
在解决与将新软件结合到正运行的计算机系统相关的问题上已经
做了许多努力，例如，一些目前使用的不以独立或批量方式操作的先进
的联机操作系统将以与独立或批量系统所使用的方法明显不同的方式
来解决替换旧软件的问题。然而，尽管比在独立系统下更透明一些，这
种系统仍然是由人工替换软件，需要单个用户或用户组主动选择是否采
用新的或修改的软件版本来处理。这一选择可以由用户通过修改将要由
在其单个用户标识下运行的进程所使用的软件的串接来执行。该选择在
以周或月来计的一段固定的时间对用户保持有效，在这一时间软件在每
个在先级别中无差异地成功运行之后在串接结构中升迁几级。当到达串
接结构的顶级时，声明该软件是“可操作的”，这时旧版本软件不再让
系统用户使用。将新软件插入系统以及该软件在各个级别的升迁，是由
一个配置管理过程和在每个级别报告、批准、跟踪软件版本和执行批准
的改变的一个手动过程来控制的。
就用于在批量或独立系统中更新软件的方法而言，以这种方式将新
的或修改的软件结合到系统中具有公知的缺点。系统主要是手动的高劳
动强度系统，非常复杂并耗费时间，它将是否以及在何种情况下系统将
以某个新软件来操作留给用户控制，没有任何方式来执行逐步的、被限
制的联机使用以使得错误不会扩展或立即影响所有正在进行的操作。控
制对新的或修改的软件的存取的方法直接与执行该软件的单个用户发
生联系并局限于该用户。
另外，这一方法不提供任何手段从旧版本软件到新版本软件转换状
态，因此，从旧软件到新软件的状态转换丢失了，这当然会对用户产生
不利的影响。
还作过其它努力来解决至少某些与在运行的计算机系统中更新软
件相关的问题。例如，在Telefonaktiebolaget L. M.Ericsson的美国申请
07/907294中，公开了在正运行的计算机系统中替换软件的一个方法，采
用这个方法可以在电信交换机的实际运行中测试和改变软件，而不破坏
正经过系统的电信业务量。然而，这个方法并不直接针对从旧版本软件
到新版本软件转换状态。即使该方法意识到这种状态转换的需要，它也
没有描述任何手段来同步从旧软件到新软件的数据转换。
因此，在电信工业中如果能够在电信交换机的实际操作中测试和改
变软件，包括从旧软件到新软件进程的状态转换，而不破坏正通过系统
的电信业务量是非常有用的。本发明提供了这样一种方法。
计算机系统如SPC电信交换机系统的动态行为可以主要被描述为一
系列并行、相对独立的事务(也被称之为“线程”或“事件串”)，其
中每个事务包括一些相关的活动。一个事务通常执行系统的外界用户看
得见并对他们功能上有用的作业。在电信交换机系统中一个典型的事务
可能是一次呼叫。
根据本发明采用具有状态转换的平滑改变技术的联机软件替换使
用面向事务的软件和能够同时存储旧软件版本和新软件版本的一个存
储器。将状态转换到新版本的一次平滑改变通过允许不断进行中的事
务，即“旧的业务量”，使用旧的软件版本运行完成来实现。在软件改
变已经开始后起动的事务，即“新业务量”，以逐渐和受控的方式使用
新软件版本运行。包括将要从旧软件版本转换为新软件版本的状态的进
程在软件改变的一开始是在旧软件的控制之下的。通过不同的同步信
号，新软件能够在“有所需求的基础上”存取旧软件控制的进程的状态，
以便最后成为包括所更新的状态的进程的所有者，前提是新软件的测试
没有任何干扰。
由本发明的具有状态转换的平滑软件改变技术所满足的主要要求
包括最小或无用户干扰和高度的系统可用性。本发明的主要特征包括：
(1)在一次事务处理(如一次呼叫)中一个单独的系统用户感受最小
或无干扰，原因是一个也只有一个软件版本控制每个特定的事务处理，
即从事务处理的开始到结束系统或者使用旧的软件版本或者使用新的
软件版本； (2)系统的单个用户不会由于软件的改变而经历任何不可
用性，原因是在改变时两个软件版本是并行使用的；(3)由于在旧版
本和新版本软件之间受控制的状态转换，在旧软件中不会丢失任何进程
的状态。
要由系统处理和传送的进程的状态在本文中可以分成两种不同的
类别：(1)在一个事务处理过程中被处理并使用而在事务处理结束后
被删除的动态进程；(2)由多个事务处理使用并使其存活的静态进程，
例如在电信系统中，包括关于连接到系统的用户号或由某些用户使用的
缩位号码的状态的进程。
与要求最小干扰的联机软件替换相关的一个关键问题是必须将旧
软件版本的状态转移到新软件版本。由于旧软件版本和新软件版本在软
件改变过程中是并行运行的，显然不需要转移动态进程，即进程将在它
开始被启动的软件版本中结束。然而，为了能够控制例如一个新的呼叫
将在哪一个软件版本中执行，需要提供一个选择点来指示业务量到适当
的软件版本运行。
本发明提供了在系统升级时识别使用哪个软件版本的机制。除了常
规的业务测试外，通信业务还要在选择点被予以识别，然后被指引到新
的软件版本，后者在它执行常规(实际)的业务之前必须进行测试。
另一方面，本发明的方法也提供了从旧版本软件到新版本软件静态
进程的状态转移的同步手段。根据本发明，在旧版本软件和新版本软件
中执行的进程之间的状态转移的同步包括以下操作：
PrepareShutdown(准备关机)是在旧软件(即由于系统升级将要
被替换的软件)中声明的一个静态进程上的第一操作，该操作使应用程
序为将要被替换的软件的即将结束作出准备。当收到PrepareShutdown
信号之后，旧软件中的静态进程公布或启动一个应用程序特定接口来传
送资源对象(状态)。资源对象是一种对象类型，它的主要目的是处理
在一个硬件源或一个内部数据结构中的信息，即随着资源对象的转移这
种信息的状态也被转移。
当该第一操作完成之后，开始应用程序在新软件中的静态进程，用
测试业务调用新的静态进程，并通过旧静态进程拥有的状态转移的接口
从旧静态进程得到必要的资源。如果测试业务在新版本软件上无干扰运
行，那么将由新版本软件执行正常的业务，但状态转移的接口仍然由旧
静态进程所拥有。
如果该正常业务也没有受到任何干扰，那么将一个Takeover(接
管)信号加到新软件内的静态进程中，利用该操作，新软件将通过由旧
静态进程拥有的状态转移的接口获得对所有旧静态进程中的剩余资源
的控制。
此后将CommitShutdown(执行关机)操作施加到旧静态进程上。
应用程序接着清除用PrepareShutdown操作公布或启动的状态转移的接
口。
最后将CommitTakeover(执行接管)操作施加到新版本软件上。
新的静态进程被告之新的软件被提交。与旧软件系统部分相关的进程被
终止。
如果新软件不能适当地运行，那么升级过程可能被反向。如果反向
是在Takeover操作前进行的，那么可以在对用户不产生任何干扰的情况
下执行该反向。反向是通过将CommitTakeover操作施加到旧版本软件
而非新版本软件来执行的。
为了更好地理解本发明及其进一步的目的与优点，下面将结合附图
来进行描述，其中：
根据本发明包括了状态转换的用新软件替换旧软件的方法可以以
举例的方式用于SPC电信交换系统(下面称为交换机)中。图1示出了一
个通用的电信系统，包括交换机2、分布式处理器4、应用软件6、数据
库8和电话10。交换机2与一个或多个处理器4相连。处理器4也连接到应
用软件6和数据库8，这在现有技术中是公知的。
为了完全理解本发明的方法是如何用于这样一个系统中的，下面将
对图2所示的系统结构进行描述。
这个结构中的最基本单元是操作系统，其中包括了最基本的功能。
根据本发明的操作系统包括例如称之为系统升级的一个功能。本发明方
法使用的系统升级功能可以由面向对象的程序设计如C++来实现。系统
升级功能在Telefonaktiebolaget L.M.Ericsson的美国申请07/907294，“在
计算机操作过程中改变软件的系统”中做了比较接近的描述，该申请在
此作为参考文献。在操作系统的顶部是应用软件，在这个例子中它被分
为两个部分，即与所有软件应用程序通用的一部分(APP)，如作为电
信系统通信标准的#7信令，和每个应用的特定软件，如ISDN、POTS、
GSM、VLL等等。
在例如上面描述的电信系统中，被频繁替换或升级的软件是应用软
件，如ISDN、GSM等等。在本发明中应该理解软件替换或升级可以是
从替换全部应用软件到其中一小部分的任何行为。
采用本发明的方法，在升级过程中新版本软件将与旧版本软件共
存，这样可以用测试业务测试新软件，与此同时正常的业务在旧版本软
件中运行。如果出现可以与新软件相联系的故障，升级将被反向，并且
新软件将被去掉。系统升级过程中的反向是由在系统升级软件内的内部
检测的异常启动的。故障管理可以强制执行一次反向，维护工程师也可
以中断升级并反向。
如上所述，典型的是一次只替换部分软件。要被替换的软件被称为
一个变化单元。在图3中示出了一个未变化软件单元20通过称为方向点
的一个寻址机构22连接到一个旧的变化单元12和一个新的变化单元
14。未变化的接口16和18将旧的变化单元12和新的变化单元14与寻址机
构22相连。图3示出了在旧的软件版本和新的软件版本中都有一个变化
单元的情况，即旧的变化单元12和新的变化单元14。新的变化单元14通
过定义被选择为接口16，它与未变化软件20的现有接口18兼容，这意味
着未变化软件与旧软件版本和新软件版本(变化单元)都能够合作。
本发明的这一方面，即提供事务处理的动态定向或重新定向，通过
引入和使用方向点而被简化。这些方向点包括事务处理可以在其中以特
定的方式被定向的分布式系统中的位置。图3中所示的寻址机构22表示
方向点的实现和系统的事务处理被单个指向新的或者旧的软件版本的
装置。这些方向点能够以三种不同的方式操作。第一，它们可以通过分
析与系统正处理的业务量相联系的功能名称来触发，根据这一操作方
法，业务量可以指向需要执行必要处理的特定功能的新的或者旧的软件
版本。第二，根据作为与软件的运行链接的的结果所提供的信息，事务
处理可以被指示执行一个程序的新的或旧的软件版本。
现在介绍同步的两种不同情况，一种是没有反向，这意味着升级成
功，一种是在系统升级过程中启动反向。没有反向的第一种情况示于图
4，有反向的第二种情况示于图5。图中进程用切掉了四角的一个矩形表
示。一个资源可以拥有一个或多个资源对象。资源对象的例子是时隙、
声音提示装置等等。
图4示出了当一个旧版本软件由一个新版本软件替换时的没有反向
的系统升级过程中同步的不同阶段。
在第一阶段，在新软件被装入并且新的静态进程开始之前，用
PrepareShutdown信号调用旧软件内的旧静态进程，位于旧软件内的静
态进程通过该信号意识到即将到来的终止和取消，并准备状态转换，旧
静态进程公布或启动一个应用程序定义的接口来转换资源对象的状
态，这里公布用来定义本进程与其他进程的通信方式。这个接口可能以
后会由新版本软件内的静态进程调用来分配资源对象。根据上面提及的
美国申请07/907294，旧静态进程也可以通知邻近的进程，例如一个分配
器进程，关于即将到来的终止，以便路径可以朝向冗余的其它选择。在
第一阶段所有业务量都由旧版本软件按原样处理，第一阶段在新软件装
入后结束。
在第二阶段，新软件内的静态进程以一种不同于初始启动的状态开
始，即该静态进程必须以一种指示在新旧版本软件内的新旧静态进程之
间将有一个状态转换的方式开始。在这一阶段，新的静态进程接收测试
业务，如果测试业务的执行没受到任何干扰，那么随后接收正常(实际)
的业务。在测试业务过程中的状态转换的同步将结合图6作详细的描
述，图6说明系统升级过程中的状态转换。在该第二阶段，正常业务首
先由旧版本软件进行处理，与此同时测试业务由新版本软件进行处理。
此后所有在测试业务结束之后起始的“新”业务将由新版本软件进行处
理，“旧”业务，即测试业务结束之前的正常业务，将由旧版本软件处
理，直到其结束为止。
由于这个例子描述了没有反向的系统升级，因此测试业务以及其后
执行的正常业务都没有任何干扰。因此，在第三阶段，用Takeover信号
指令新软件内的静态进程要求旧软件内的静态进程的所有资源对象，这
是由系统升级功能引进的对新软件内声明的静态进程的第一操作。为状
态转换公布或启动的应用程序定义的状态接口由这个新静态进程调
用，来转换资源对象的控制并接收所有资源对象。在这个第三阶段，除
了由旧软件处理的剩余旧业务外，几乎所有业务量都由新软件处理。
在第四阶段，用CommitShutdown信号指示旧进程消除所有服务，
即旧进程将不再获得资源对象。有关这个CommitShutdown信号施加到
旧进程的时间可以采用两个不同的准则。第一，可以在旧软件处理的所
有旧业务都结束后施加到旧进程上，这保证在系统升级时不会干扰正在
进行中的业务，因为旧软件的服务要直到没业务处理后才消除。第二，
在系统升级启动后某个时间将该信号作用到旧进程，这常常会加快升级
过程，但要冒丢失一些业务(呼叫)的风险。当该服务被消除后，用于
资源对象转换的接口被撤消。当CommitShutdown信号被发出之后，所
有业务都将由新版本软件进行处理。
此后，在第五阶段，旧软件被限制并消除，在第六阶段，新进程是
先前由旧进程要求的资源对象的唯一拥有者。这由CommitTakeover信
号指示给新进程。这个信号在系统升级功能被保证时发出，并且静态进
程将使该升级得以生存。
图5示出了当一个旧版本软件由一个新版本软件替换时的有反向的
系统升级过程中同步的不同阶段。与图4相比这一情况的主要差别是
CommitTakeover信号的接收者。在这一情况下在旧软件中执行的静态
进程是资源对象的接受者和拥有者。反向可以由运行与维护技术员启
动，也可以自动进行。
系统升级过程中的反向可以在CommitShutdown信号之前的任何时
间进行，CommitShutdown信号如上结合图4所述被施加到旧的静态进
程。升级过程反向的阶段不同，得到的结果也会不同。下面参考图5来
描述两个不同的反向情况。
在第一种情况下，如箭头CommitTakeover1所示，反向在第二阶段
进行，即在新的静态进程接受Takeover信号之前进行。在第二阶段，第
一测试业务以及随后的正常业务将由新的静态进程处理。如果在测试业
务期间由于新软件的原因发生了问题，反向将通过将CommitTakeover
信号施加到旧的静态进程来启动，既可以自动也可以由升级工程师进
行。由于在这个例子中旧的静态进程仍然是所有资源对象的拥有者，因
此旧静态进程的状态不会因为反向而丢失。唯一发生的事件是测试业务
被暂停。测试业务的时间是最常用也最适合进行反向的时间，因为用户
不会受到任何影响。反向也可以在第二阶段的稍后时间发生，即在新软
件开始执行正常业务时发生。如果反向在这一时间发生，旧静态进程的
状态仍然不会因为反向而丢失。如果新软件有严重的问题，那么执行正
在进行的正常业务就会有问题，但新软件仍然会试图处理正常业务直到
它终止为止。反向之后，即信号CommitTakeover被施加到旧的静态进
程之后，开始的所有正常业务都将由旧软件处理。
在第二种情况下，如箭头CommitTakeover2所示，反向在信号
Takeover施加到新的静态进程后进行，即在第四阶段进行。在Takeover
信号之后，如上所述，新软件已经控制了所有的资源对象。通过将信号
CommitTakeover加到旧的静态进程，可以进行反向，但在Takeover信
号和CommitTakeover信号之间的时间被改变的新静态进程的状态将被
丢失。
在信号CommitShutdown施加到旧的静态进程之后也可以反向，但
所有状态都会丢失，原因是旧软件必须要初始启动。
参考图6来描述系统升级期间状态转换的同步。如上所述在第一阶
段被启动或公布的状态转换接口必须由应用程序指定，以使得新静态进
程可以协调并转移来自旧进程的资源对象的控制。在图6和下面的描述
中将在接口内采用下述一般操作。
GetResource(获得资源)，该操作将一个特定资源对象的控制从
旧静态进程转移到新静态进程，当新静态进程需要旧静态进程控制的一
个特定的资源对象时这个操作被调用。
GetAnyResource(获得任何资源)，该操作将一个任意资源对象的
控制从旧静态进程转移到新静态进程，当新静态进程需要旧静态进程控
制的任意资源对象时这个操作被调用。
GetAllResource(获得所有资源)，该操作将旧静态进程中的所有
剩余资源对象的状态信息控制转移到新静态进程，当新静态进程收到信
号Takeover之后这一操作才能执行。
下面将结合图6对系统升级期间的同步与状态转移作较详细的描
述，其中将升级过程分为八个阶段。
在升级过程开始之前，业务量将在旧软件中照常运行。在第一阶
段，用PrepareShutdown操作通知旧静态进程由于系统升级而即将终
止，此后，如上所述，应用程序启动或公布使后继的系统升级成为可能
的状态转移接口。然后在第二阶段开始新软件内的应用程序的静态进
程。在这一阶段启动或公布的端口名与旧软件中相同。
之后新软件在第三阶段准备接收测试业务。测试业务可以是计算机
产生的业务，也可以是由运行和维护工程师执行的“实际”业务。在测
试业务期间，新软件将需要旧版本软件的静态进程所拥有的资源对象。
新静态进程通过状态转移接口采用GetAnyResource操作从旧静态进程
得到必要的资源对象。但即使新静态进程能够对资源对象进行存取，它
们仍然由旧静态进程拥有。
如果测试业务期间没有任何干扰，那么在第四阶段新的静态进程将
由正常业务调用，并通过状态转移接口由GetResource或
GetAnyResource操作从旧的静态进程得到必要的资源对象。在新的业务
由新软件处理期间，已由新的静态进程要求但仍然由旧的静态进程拥有
的资源对象的状态可以改变。这个改变被转回到旧静态进程，因为它们
是这些资源对象的拥有者。如果没这么做，那么在反向成为必须时这个
更新的状态信息就会丢失。在这个阶段之后，没有丢失状态信息风险的
反向将不再存在。
在第五阶段，新的静态进程由系统升级功能Takeover调用，后者又
启动GetAllResources操作。新的静态进程现在具有对来自旧静态进程的
所有资源对象的控制。在第六阶段，旧的静态进程由CommitShutdown
操作调用，并且应用程序消除在第一阶段启动或公布的接口。此后，在
第七阶段，旧静态进程由系统升级功能终止。在最后的第八阶段，由系
统升级通知新的静态进程新软件被指定使用。与旧软件系统部分相关的
进程将被终止。
下面将结合图7a--7n对平滑系统升级方法作用到一个资源服务器的
实际例子进行描述。资源服务器是控制资源池分配与解除分配的一个静
态进程，资源池是相互等同的那些资源对象，即一个池内的所有资源对
象都是可以相互交换的，如DTMF接收器、一条路径中的信道或回波消
除器。在图7中R指定表示一个资源池的对象。如果资源是空闲的，那么
它的背景是明的，如图7a的左侧所示，如果资源被分配，那么它是暗的，
如图7a的右侧所示，不受资源服务器控制的一个资源用虚线标识，如图
7c的右侧所示。
在启动系统升级之前，资源的分配与解除以正常的方式操作，如图
7a所示。如果被请求的一个资源不能被分配，那么通知请求程序没有资
源，这一行为即使在有一个正在进行的系统升级并且通过状态转换接口
做了分配时也不改变。
下面将结合图6描述的8个阶段来说明作用到资源服务器的平滑系
统升级方法。
如图7b所示，应用程序被告之由于系统升级而即将终止。如上所
述，当收到信号PrepareShutdown后资源服务器公告状态转换接口，此
后，如图7c所示，一个新的资源服务器在第二阶段开始，新的资源服务
器中的资源是图7c所示的未由资源服务器控制的资源。旧的资源服务器
仍然照常执行资源分配与解除分配的调用。
在第三阶段，测试业务向着新的资源服务器发送，而正常业务向着
旧的服务器发送，如图7d所示。对新资源服务器所需要的资源的控制由
GetResource操作经由状态转换的接口取出。如图7e所示，在图7d中由
测试业务请求的资源在新的资源服务器中被分配。
当新资源服务器成功地处理了测试业务之后，正常业务将在第四阶
段被指向新资源服务器，如图7f所示。对资源的控制在需要时由
GetAnyResource操作经由状态转换接口取出。在第四阶段有两种可能
性：资源被从新资源服务器分配和解除分配，如图7g和7h所示，在右下
角的资源在图7g中被分配并在图7h返回；另一种情况是如果资源早在第
三阶段由旧资源服务器分配时，那么在新资源服务器中被解除分配，在
这种情况下，新资源服务器用GetResource操作经由状态转换的接口请
求对这个特定资源的控制，如图7i所示。图7b中在左上角的资源在第一
阶段保留在旧资源服务器中，在第四阶段返回到新资源服务器。用
GetResource操作经由状态转换的接口请求对资源的控制。
在第五阶段，如图7j和7k所示，经由状态转换接口取得对所有剩余
资源的控制。新资源服务器由系统升级功能用Takeover操作调用，剩余
的资源用GetAllResources操作经由状态转换接口取出，如图7j所示。在
GetAllResources操作之后，新资源服务器控制了所有的资源，如图7k
中左下角中的资源向新资源服务器的转移所示。
在第六阶段，如图7l所示，用CommitShutdown操作从系统升级调
用旧资源服务器，如前面结合图6所描述的那样。在第七阶段，如图7m
所示，旧资源服务器由系统升级功能终止。在最后的第八阶段，与旧软
件系统部分相关的动态进程由系统升级功能CommitTakeover终止。
通过前面的描述相信本发明的方法已清楚明白。尽管图中所示和
描述的方法是优选的，但显然在不脱离权利要求书限定的本发明精神和
范围的前提下是可以作出各种变化和改进的。