电子文件的管理系统及其方法 【技术领域】
本发明是一种电子文件管理系统及其方法，尤其涉及一种用于项目开发中对电子文件管理的系统及方法。
背景技术
在当今社会中，项目开发需要团队合作，优秀的文件的管理已经成为全球各种机构必须面对的迫切问题，文件管理系统用来处理源码修改的版本控制和并发修改冲突。现在有很多种文件管理工具，比较优秀的例如Subversion。Subversion是一款开放源代码的版本控制系统，它将目录作为一类特殊的文件来处理，因此Subversion能够类似记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，Subversion能够准确记录操作前后的历史联系。
通常，Subversion的处理流程是：用户可以对工作目录WorkFolder进行增加、删除、修改、拷贝等操作文件、处理并发冲突问题以及记录文件的修改历史的过程中，直到对此版的更新完成，这时工作目录的版本为此版发布的版本。当需要再次升级版本时，则循环执行上述操作。
但是，Subversion的版本管理仍存在一定的问题和不足。具体如下：一是，在项目的版本更新完成后，不能自动的另外记录此生成版本的内容。这样当用户想从已经发布的某版中查找内容，首先会从其工作目录WorkFolder修改的版本历史中找到需要的版本，然后，将此版内容保存到本机，并据此从本机保存的版本中查找需要的文件。如此操作会非常的繁琐，尤其是存在的修改历史很多时，从而降低开发效率。
二是，在上述处理流程中，由于用户操作WorkFolder没有权限上的优先级次划分，分工不明确。因此在整个项目开发的过程中，缺少流程化的管理过程，这样可能造成同时有几个用户均打算做同一项任务，对开发带来问题，并造成不必要的人员资源浪费。
最后，在Subversion的开发过程中，仅通过人为告知某用户要做的任务，这样可能会造成告知重复或告知有误差等问题。
【发明内容】
本发明的目的旨在至少解决现有技术中的上述问题。
为此，本发明的实施例提出一种能够简化项目文件版本更新过程、提高项目开发效率的电子文件管理系统及其方法。
根据本发明的一个方面，本发明实施例提供了一种电子文件的管理方法，用以支持一计算机系统中对于电子文件的创建、修改和版本的管理作业，包括以下步骤：在所述计算机的一储存设备中配置一第一记录单元和一第二记录单元；在所述第一记录单元中创建一版本目录，用以储存所述电子文件的版本信息；在所述第二记录单元中创建一工作目录，用以储存所述电子文件；根据对工作目录的电子文件的版本更新操作，在所述版本信息中记录不同阶段下对所述工作目录中的电子文件的操作历史以及对应的内容更新，其中所述不同阶段包括流程化的设计阶段、编辑阶段和审核阶段且所述不同阶段对应设置有权限管理；以及记录所述工作目录最终更新版本的对应内容到一单独的电子文件中，以作为对所述工作目录最终更新版本进行下一版本更新的基础。
根据本发明进一步的实施例，所述单独电子文件还包括在不同阶段与工作目录最终更新版本的内容对应的权限信息和审核信息。
根据本发明进一步的实施例，所述电子文件的管理方法还包括在所述不同阶段对应的所述工作目录操作完成后自动发送相关信息到下一阶段的步骤，其中所述相关信息包括对所述工作目录操作的更新内容及/或对所述更新内容的审核指示。
根据本发明进一步地实施例，根据所述工作目录更新的版本次序命名所述单独电子文件。
根据本发明的另一方面，本发明实施例提供了一种电子文件的管理系统，用以支持一计算机系统中对于电子文件的创建、修改和版本的管理作业，包括储存设备、第一记录单元、权限设置程序和第二记录单元；这里，第一记录单元配置于所述储存设备中，所述第一记录单元具有一版本目录，用于根据对工作目录的版本更新操作，记录不同阶段下对所述工作目录的操作历史以及对应的内容更新，其中所述不同阶段包括流程化的设计阶段、编辑阶段和审核阶段，权限设置程序用于设置所述不同阶段的权限管理。第二记录单元配置于所述储存设备中，所述第二记录单元具有一工作目录，用以储存所述电子文件，以及记录所述工作目录最终更新版本的对应内容到一单独文件中，以作为对所述工作目录最终更新版本进行下一版本更新的基础。
根据本发明进一步的实施例，所述单独电子文件还包括在所述不同阶段与所述工作目录最终更新版本的内容对应的权限信息和审核信息。
根据本发明进一步的实施例，所述电子文件的管理系统还包括信息发送程序，用于在所述不同阶段对应的所述工作目录操作完成后自动发送相关信息到下一阶段。所述相关信息包括对所述工作目录操作的更新内容及/或对所述更新内容的审核指示。
根据本发明进一步的实施例，所述第二记录单元根据所述工作目录更新的版本次序命名所述文件。
本发明通过将工作目录发布版本的内容自动保存到一单独文件中，从而能够在项目版本再次升级时作为内容更新的原始基础，因此简化了现有技术存在的繁琐操作，提高文件管理的效率。
另外，本发明通过对不同阶段设置权限，因此对工作目录的操作进行优先级划分，分工明确，减少不必要的人员资源浪费，提高项目开发的安全性、严密性。并且，将不同阶段与工作目录最终更新版本的内容对应的权限信息和审核信息也包含在上述保存文件中，从而根据此文件能够方便地了解有关人员对发布版本有关的操作及审核历史记录。
本发明还通过在不同阶段对应的所述工作目录操作完成后，以电子邮件的形式自动发送关于工作目录操作的更新内容及/或对更新内容的审核指示的信息，从而能够确保项目版本更新处理的流程化、及时性及正确率。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
【附图说明】
本发明的上述和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本发明的电子文件的管理系统结构图；
图2为本发明实施例的电子文件管理目录结构图；
图3为本发明的电子文件的管理方法步骤流程图；
图4为本发明实施例对不同阶段设置权限管理的示意图；
图5为本发明实施例具有权限管理的流程化控制过程；
图6为本发明实施例在不同阶段发送相关信息的流程图；
图7为本发明实施例在项目开发流程中的状态显示示意图；和
图8为本发明实施例工作目录的版本更新流程示意图。
【具体实施方式】
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
首先，请参考图1，该图为本发明的电子文件管理的系统结构图。本发明电子文件的管理系统用以支持一计算机系统中对于电子文件的创建、修改和版本的管理作业，如图所示，该管理系统包括存储设备10，存储设备10中配置有第一记录单元12和第二记录单元14。其中，第一记录单元12具有一版本目录，用于根据对例如项目开发等文件工作目录的版本更新操作，在版本信息中记录不同阶段下对工作目录的电子文件的操作历史以及对应的内容更新。第二记录单元14具有一工作目录，用以储存上述被操作的电子文件，并记录工作目录最终更新版本的对应内容到一单独电子文件中，以作为对工作目录最终更新版本进行下一版本更新的基础文件。
下面，以项目开发为例并结合图2对本发明的电子文件的管理系统实施例做出详细描述。需要指出的是，本发明不局限于仅用于项目开发的文件管理，其他各种类似需要电子文件管理的系统仍可适用。
在图2所示电子文件管理的目录结构图中，各节点说明如下：
Project：需要管理的项目
WorkFolder：项目的所有文件，作为文件管理的工作目录，也称为工作目录。
Revision：工作目录版本发布后，记录此发布版本的项目文件的内容。
WorkFolder为工作目录，是用户对其进行操作的目录，第一记录单元12则根据用户对工作目录在不同阶段下的操作，对工作目录的操作历史以及对应的内容更新进行记录，并放置在WorkFolder下相应的子目录或文件下。
在本实施例中，例如不同阶段包括设计阶段、编辑阶段和审核阶段。
对于设计阶段，设计者设计项目的开发方案，并完成开发草案等。因此，设计者在该阶段中会对WorkFolder进行新增、修改及/或删除文件等操作，完成初步设计规划。这里，系统通过第一记录单元12保存此次修改结果，并记录修改历史，例如修改对应的时间和内容等。
在编辑阶段，编辑者按照设计者的设计要求，完成对负责的文件的修改。系统保存此次修改结果、记录修改历史。这里，系统再次通过第一记录单元12保存此次修改结果，并记录修改历史。
对于审核阶段，审核者审核编辑者对此版内容的完成是否符合版本发布。这里，第一记录单元12将工作目录对应电子文件的历史修改进行保存，并记录审核操作的有关信息，例如审核结果、审核日期等。
Revision是记录WorkFolder的发布版本的项目内容的目录，其中记录有通过以上阶段确定的最终发布版本的内容，以作为对工作目录最终更新版本进行下一版本更新的基础。
第二记录单元14根据工作目录更新的版本次序命名所述文件。Revision 1、Revision 2到Revision 5等记录有不同升级版本的历史内容，例如这里以升序方式表示版本的先后顺序，Revision 1表示最早的升级发布版本内容，Revision5表示最新的升级发布版本内容。当用户需要查找历史版本内容时，打开该记录的版本，从中查找即可获得。当进行下一版本的升级时，通过当前最新Revision，能够自动获得作为升级基础的项目版本内容，将其拷贝到WorkFolder目录下，即能够在此内容基础上进行修改等更新操作，实现当前版本的升级。
根据本发明的一个实施例，第二记录单元14可以设定Revision下记录最终发布版本的内容的文件为不可编辑状态，以确保版本内容的安全性和稳定性。
现在，返回参考图1。如图所示，本发明电子文件管理系统还包括权限设置程序16，以用于设置不同阶段的权限管理。不同阶段之间为流程化的处理过程。这里，仍结合应用于项目开发环境下的文件管理系统进行说明。
在项目开发过程中，权限设置程序16可以根据用户在项目开发中担当的职位，负责的任务，按级别为项目设置用户的权限。例如设计者负责项目开发草案设计，编辑者负责根据设计者的设计草案进行编辑处理，编辑者完成的任务由设计者初审是否符合设计要求，并且在设计者通过的情况下，交由审核者再次进行审核，审核者则将审核结果发送给设计者。
不同阶段的用户通过预先设定的权限得到自己的工作任务，各负其职，完成项目开发。项目的整个开发过程是在设计者设计、编辑者按照设计方案开发、审核者控制版本发布的智能化控制下完成的。这样，电子文件管理系统体现了项目安全性、严密性，严紧性的开发。
对于权限设置程序16的权限设置，不同阶段用户根据自己的权限对工作目录所做出的设计、编辑、修改、审核等操作信息及对应的权限信息，可以记录在保存最终更新版本的内容的单独文件中，并与最终更新版本的内容的位置对应。
例如，设计者在设计阶段给出项目开发草案，编辑者按照草案进行编辑完成，并交由审核者审核。如果经过上述各个阶段，工作目录更新后的最终更新版本的内容即为设计者的最初草案，中间没有修改，并且编辑者的编辑通过了审核并以此内容进行发布，那么，记录最终版本内容的文件中，在设计阶段、编辑阶段及审核阶段对应的最终更新版本内容是相同的，并且同时记录有三个用户的权限信息，以及设计者对编辑者的编辑操作进行过初审、审核者对设计者初步审核后的编辑者提交的版本更新进行后续审核等相关的审核信息。
另外，如图1所示，本发明电子文件管理系统还包括信息发送程序18，用于在项目开发的不同阶段对应的工作目录操作完成后自动发送相关信息到下一阶段。相关信息包括对不同阶段工作目录操作的更新内容及/或对更新内容的审核指示，在本发明一个实施例中，信息发送程序18可以通过电子邮件或其他方式发送相关信息。
例如在项目开发过程中，当完成任务后、或分配任务给成员，不用人为告知，本系统的信息发送程序18会自动的发邮件通知相关人员，用户只需要在执行相关操作时，书写邮件内容后提交即可。对于上述具有设计、编辑和审核阶段的实施例，设计者将设计草案的工作目录提交后，信息发送程序18即会受到相应命令，将设计者编写的有关设计草案的内容发送，告知其需要完成的开发任务；或者，在编辑者按照其要求完成任务后也会将更新的内容等情况报告给设计者以进行初步审核，相应地，设计者也再次将审核的情况等信息发送给编辑者。同样地，根据项目开发的流程设计，利用信息发送程序18可实现编辑者与审核者，以及审核者与设计者之间也存在相应的信息通讯。
如图1所示，电子文件管理系统还包括状态设置程序20，用于设置显示工作目录处于不同阶段的状态图标。例如，工作目录版本更新过程中的状态分别包括：初始、草案中、待修改、修改中、待初审、待发行，其中的每个状态代表项目开发的对应阶段，利用不同的图标可以显示工作目录所处的当前状态。这样使用户一目了然，通过图标即可知道开发到达了哪个阶段。这里，需要指出的，例如待修改、修改中可以分别表示编辑阶段的初始激活编辑操作的时间点和后续的修改时间段。
下面结合图3至图8对本发明实施例的电子文件的管理方法说明如下，本发明电子文件的管理方法用以支持一计算机系统中对于电子文件的创建、修改和版本的管理作业。
首先，请参考图3，该图为本发明的电子文件的管理方法总体步骤流程图。如图所示，本发明的电子文件管理方法包括以下步骤：在计算机的一储存设备中配置一第一记录单元和一第二记录单元(步骤102)；然后，在第一记录单元中创建一版本目录，用以储存电子文件的版本信息(步骤104)。在第二记录单元中创建一工作目录，用以储存上述电子文件(步骤106)。根据对工作目录的电子文件的版本更新操作，在第一记录单元中存储的版本信息中记录不同阶段下对工作目录的操作历史以及对应的内容更新(步骤108)；以及记录工作目录最终更新版本的对应内容到一单独电子文件中，以作为对工作目录最终更新版本进行下一版本更新的基础文件(步骤110)。
通过本发明电子文件管理方法的步骤108及步骤110，可以得到图2实施例所示文件管理的目录结构，其中Project节点表示需要管理的项目，WorkFolder节点表示项目的所有文件，作为文件管理的工作目录，也称为工作目录。Revision表示工作目录版本发布后，记录此发布版本的项目文件的内容。
WorkFolder为工作目录，是用户对其进行操作的目录，步骤108描述根据用户对工作目录在不同阶段下的操作，对工作目录的操作历史以及对应的内容更新进行记录，并放置在WorkFolder下相应的子目录或文件下。
在本实施例中，不同阶段例如包括设计阶段、编辑阶段和审核阶段。
对于设计阶段，设计者设计项目的开发方方案，并完成开发草案等。因此，设计者在该阶段中会对WorkFolder进行新增、修改及/或删除文件等操作，完成初步设计规划。这里，保存此次修改结果，并记录修改历史，例如修改对应的时间和内容等。
在编辑阶段，编辑者按照设计者的设计要求，完成对负责的文件的修改。系统保存此次修改结果、记录修改历史。这里，再次保存此次修改结果，并记录修改历史。
对于审核阶段，审核者审核编辑者对此版内容的完成是否符合版本发布。这里，将工作目录的历史修改进行保存，并记录审核操作的有关信息，例如审核结果、审核日期等。
Revision是记录WorkFolder的发布版本的项目内容的目录，其中记录有通过以上阶段确定的最终发布版本的内容，以作为对工作目录最终更新版本进行下一版本更新的基础。
Revision文件的命名可以根据工作目录更新的版本次序完成。例如，Revision 1、Revision 2到Revision 5等记录有不同升级版本的历史内容，例如这里以升序方式表示版本的先后顺序，Revision 1表示最早的升级发布版本内容，Revision 5表示最新的升级发布版本内容。当用户需要查找历史版本内容时，打开该记录的版本，从中查找即可获得。当进行下一版本的升级时，通过当前最新Revision，能够自动获得作为升级基础的项目版本内容，将其拷贝到WorkFolder目录下，即能够在此内容基础上进行修改等更新操作，实现当前版本的升级。
并且，可以设定Revision下记录最终发布版本的内容的文件为不可编辑状态，以确保版本内容的安全性和稳定性。
现在，请参考图4，图4为本发明实施例对不同阶段设置权限管理的示意图。
如图所示，在权限管理设置过程中，首先通过增加、删除、修改等操作设定版本更新需要的用户(步骤202)。然后，为每个用户设置权限(步骤204)。用户权限包括设计权限、编辑权限、审核权限等，即，该用户为设计者、编辑者还是审核者。当然，具体根据实际工作中的管理要求进行设定。并且，一个用户可同时具有一个以上的权限。最后，将权限设置保存(步骤206)。
在项目开发过程中，可以根据用户在项目开发中担当的职位、负责的任务，按级别为项目设置用户的权限。例如设计者负责项目开发草案设计，编辑者负责根据设计者的设计草案进行编辑处理，编辑者完成的任务由设计者初审是否符合设计要求，并且在设计者通过的情况下，交由审核者再次进行审核，审核者则将审核结果发送给设计者。不同阶段的用户通过预先设定的权限得到自己的工作任务，各负其职，完成项目开发。
对于上述设置权限的不同阶段，可以是流程化控制过程。这里，仍结合应用于项目开发环境下的电子文件管理方法进行说明。图5为本发明实施例具有权限管理的流程化控制过程。如图所示，在本发明实施例的电子文件管理方法流程化过程中，首先是设计阶段，由设计者设计草案(步骤302)，并在设计完成后提交草案(步骤304)。判断提交的草案是否需要初审(步骤306)，若不需要初审，则直接提交编辑者申请该设计草案内容作为工作目标版本更新的内容进行发行(步骤314)。
若需要初审，则提交给编辑者按照设计者草案的规划对工作目录进行修改编辑(308)，这里对应编辑阶段。编辑者将修改的结果提交给设计者初审(步骤310)，设计者审核编辑者的修改是否符合其设计要求，以决定是否通过初审(步骤312)。若未通过初审，返回到步骤302。若通过初审，则告知审核结果给编辑者，再由编辑者申请发行(步骤314)。下面是审核阶段，审核者对编辑者申请发行的版本内容进行审核(步骤316)，然后判断审核是否通过(步骤318)。通过审核则发行此版本，并告知设计者(步骤322)；否则，告知设计者需要修改的内容(步骤320)，并返回到设计阶段由设计者再根据审核要求进行设计草案修改。
通过上述图5的实施例可知，项目的整个开发过程是在设计者设计、编辑者按照设计方案开发、审核者控制版本发布的智能化、流程化控制下完成的。这样，电子文件管理系统体现了项目安全性、严密性，严紧性的开发。
对于上述权限设置，不同阶段用户根据自己的权限对工作目录所作出的设计、编辑、修改、审核等操作信息及对应的权限信息，可以记录在保存最终更新版本的内容的单独文件Revision中，并与最终更新版本的内容的位置对应。
另外，本发明电子文件的管理方法还包括在不同阶段对应的工作目录操作完成后自动发送相关信息到下一阶段的步骤，相关信息包括对不同阶段工作目录操作的更新内容及/或对更新内容的审核指示。下面，结合图6实施例，对相关信息发送过程作出说明。
图6为本发明实施例在不同阶段发送相关信息的流程图，该实施例中，设计者、编辑者及审核者可以通过电子邮件发送相关信息。
如图6所示，设计者在完成设计草案任务后，会将设计者编写的有关设计草案的内容通过邮件发送给编辑者(步骤402)，以告知其需要完成的开发任务。编辑者根据接收邮件内容完成任务，并发邮件将更新的内容等情况报告给设计者(步骤404)，以进行初步审核。设计者根据编辑者发送的相关信息对其任务完成情况进行审查，并再次发邮件给编辑者(步骤406)，以告知其审查结果，审查不通过的，还会发送有关草案修改的内容。若编辑者得知其完成的任务通过(步骤408)，则申请版本发布，并发送邮件给审核者(步骤410)，以告知其版本修改的内容。审核者通过审核申请版本发布的内容，得出审核结果，并发邮件给设计者(步骤412)。
通过上述步骤可知，相关信息包括对工作目录操作的更新内容及/或对更新内容的审核指示等。在项目开发过程中，当完成任务后、或分配任务给其他成员，不用人为告知，用户只需要在执行相关操作时，书写邮件内容后提交，即可即自动的发邮件通知相关人员。
另外，本发明电子文件管理方法还包括设置用于显示工作目录处于不同阶段的操作状态图标的步骤。现在，参考图7对状态显示说明如下。图7为本发明实施例在项目开发流程中的状态显示示意图。
如图7所示，工作目录版本更新过程中的状态分别包括：初始、草案中、待修改、修改中、待初审、待发行，其中的每个状态代表项目开发的对应阶段，利用不同的图标可以显示工作目录所处的当前状态。
如图所示，在初始状态下，设计者开始编辑开发草案(步骤502)。这时，显示初始状态图标。然后，设计者对需要更新升级的工作目录进行设计，并规划出草案(步骤504)，这时，图标显示为在草案中状态下。接着，提交工作目录(步骤506)，此时系统保持此次修改结果、记录修改历史，工作目录状态为待修改。提交的同时，自动以电子邮件方式将编写邮件的内容发送给编辑者，告知其需要完成的开发任务。
编辑者收到设计者的电子邮件后，这时图标显示待修改状态，并激活编辑状态开始进行编辑(步骤508)。然后，按照设计者的设计要求，完成对负责的文件的修改(步骤510)。编辑完成后提交工作目录(步骤512)，此时图标显示状态为修改中，并且系统保存此次修改结果、记录修改历史。提交的同时，自动将编写任务以邮件内容形式发送给分配这个任务的设计者，告知完成情况，请求其审查任务的完成情况。
这里需要指出，步骤502及步骤508对应的状态为一个点，不是过程，是属于该权限的用户开始操作工作目录时其状态就发生改变。
设计者收到请求初审的邮件后，审查编辑者完成情况(步骤514)，并进一步判断是否符合设计要求(步骤518)。若符合要求则表示工作目录修改通过初审；系统保存此次工作目录的修改，并发邮件给编辑者告知其通过初审。若不符合要求，则转到步骤502。此时，工作目录的状态图标为初始。
编辑者收到通过初审的邮件后，申请发行本版内容(步骤502)。编辑者提交申请请求(步骤522)，系统保存工作目录的修改，工作目录状态变为待发行。提交的同时发邮件给审核者，请求其发行此版内容。
在待发行状态下，审核者根据邮件内容审核此版内容(步骤524)，并判断完成是否符合版本发布(步骤526)。若不符合，则给出拒绝本版发行的命令(步骤530)，工作目录状态图标变为初始，保存历史修改，同时发邮件给设计者，告知需要需改的内容。若符合，则同意发行(步骤528)，工作目录状态变为为正常，保存历史修改。自动的保存此版的内容，并命名为Revision+此版的(步骤532)，同时发邮件给设计者，告知此版通过发，版本升级成功。通过图标用户即可知道开发到达了哪个阶段。
最后，结合项目开发的不同阶段以及对应的权限，图8给出了本发明电子文件管理方法实施例的总体流程图。
如图8所示，首先，设计者对应的状态包括初始状态A和草案中B，这时主要执行的步骤包括对工作目录进行设计，新增、修改、删除文件，完成初步规划(步骤602)，和提交工作目录，并发送邮件给完成此任务的所有编辑者(步骤604)。这里，可以设置是否需要设计者进行初审的步骤(步骤606)。
接下来，编辑者对应的状态包括待修改C和修改中D，主要步骤包括根据设计者要求，完成对工作目录指定内容的修改(步骤608)，提交工作目录更新内容给设计者初审(步骤610)。
之后，设计者对应的是待初审状态E，对应包括的步骤有：设计者查看编辑者的修改的内容是否符合要求(步骤620)；符合设计要求，则通过初审，否则不通过，通过向编辑者发送邮件告知其初审结果，并提出要求(步骤622)；以及设置初始是否通过(步骤624)。
然后，编辑者处理的操作是确认从初始状态经过修改又达到初始状态的工作目录为版本完成(步骤626)，提交申请对该版本的发行，并发邮件给审核版本发行的审核者(步骤628)。
下面阶段，审核者对应包括待发行状态F，并且执行审查版本(步骤630)、提交是否同意审核通过，邮件告知设计者审核结果、建议等(步骤632)以及是否同意审核通过(步骤634)的操作。
最后，对于通过审核的工作目录版本，自动生成保存此版的内容并命名为版本名称+版本号的版本文件(步骤636)，同时工作目录状态变为初始状态(步骤638)。至此，项目的修改的一个版本管理流程完成。
当然，本发明还可有其它多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。