CN105528464A - 一种自动判断关联数据技术状态一致性的版本管理系统 - Google Patents

Abstract

本发明涉及一种自动判断关联数据技术状态一致性的版本管理系统，包括版本库、版本管理器、技术状态一致性检查器和技术状态通知生成器，本系统可以根据工程设计数据具有明确上下游关系的特点，对工程设计数据定义数据包及其“上下游”关系，在文件提交时进行提交合法性检查，对上下游数据的技术状态一致性进行自动判断，发现潜在的技术状态不一致问题，并向相关设计人员提供技术动态变更通知，提醒相关设计人员及时更新过时数据，本系统不仅能控制版本状态还可以降低状态不一致的工程数据被误用的可能性，减少工程质量问题，避免经济损失，提高工作效率。

Description

一种自动判断关联数据技术状态一致性的版本管理系统

技术领域

本发明涉及一种自动判断关联数据技术状态一致性的版本管理系统，属于工程设计数据管理技术领域。

背景技术

工程数据之间的关联关系往往呈现“上下游”形式的相关，即依据相对固化的计算过程，以“上游数据”数据为计算输入，计算生成“下游数据”。在此种关系下，上游数据发生更改后，下游数据必须相应更改，否则将导致工程项目数据的不一致。

复杂产品设计过程产生的数据项目众多，数据项目之间的上下游关系极为复杂。容易出现上游数据变化后，相关设计人员未发现或未收到通知，没有及时更新下游数据，使项目数据的技术状态不一致。而且，由于上下游关联关系十分复杂，也难以依靠人工手段，判断数据整体上的状态一致性。当这种状态不一致的工程数据被误用后，往往导致工程质量问题，带来经济损失。

目前市面上存在多种版本管理系统，能够实现记录数据变化历史的记录功能，并能够支持多人对数据的协同修改。但是，现有的版本管理系统没有考虑到工程数据具有“上下游”形式的关系，不对更改数据所依赖的上游数据进行合法性检查，也不具备自动判断上下游技术状态一致性的功能。

市面上还存在一些流程管理软件，这些流程管理软件往往要求管理人员事先定义设计流程，以确定上下游传递关系，但流程的定义繁琐且经常变化，且采用这种流程管理软件管理工程设计之间的设计流程将导致各专业组难以灵活调整协同流程，工作效率低。

发明内容

本发明的技术解决问题是：克服现有技术的不足，针对复杂产品多专业工程设计数据设计特点，提供一种自动判断关联数据技术状态一致性的版本管理系统，保证上下游数据的一致性，降低状态不一致的工程数据被误用的可能性。

本发明的技术方案是：一种自动判断关联数据技术状态一致性的版本管理系统，包括版本库、版本管理器、技术状态一致性检查器和技术状态通知生成器，其中：

版本管理器，新建或导入工程数据，所述工程数据分项目存储，一个项目从项目根目录开始，包括根目录、子目录和文件名称及内容；将工程数据中指定的子目录定义为数据包，确定数据包“上下游”的关系，生成数据包“上下游”关系表和数据包“上下游”顺序表；为每个数据包定义用户权限，形成用户权限信息表；判断客户端文件提交合法性，将合法性判断结果发送给客户端；响应客户端文件提交申请，为变化或增加的文件及其各级父目录按照单调递增的原则分配新的版本号进行标识，更新工程数据版本；数据包状态表、数据包“上下游”关系表、数据包“上下游”顺序表、用户权限信息表和各个版本的工程数据均存入版本库；

技术状态一致性检查器，读取工程数据所有文件和目录版本，创建所有数据包版本快照；根据数据包“上下游”关系及数据包版本快照中的数据包版本号进行技术状态一致性检查，更新数据包状态表中的数据包状态，存入版本库；

技术状态通知生成器，读取版本库中的数据包状态信息、数据包“上下游”关系信息、用户权限信息，生成技术状态变化消息，根据用户权限信息，提供给与消息对应的数据包相关联的客户端。

数据包“上下游”关系表中记录各数据包的所有直接上游数据包，所述直接上游数据包定义为与该数据包存在“上下游”关系的所有数据包中与该数据包最近的上游数据包，其他各数据包均为间接上游数据包，直接上游数据包和间接上游数据包合为该数据包的上游数据包。

数据包状态表中存储每个数据包的状态，所述数据包状态依据以下原则分为“无需更新”、“已过时”和“待更新”三类：当本数据包的最新版本号大于其所有上游数据包的最新版本号时，本数据包为“无需更新”状态；当本数据包的版本号小于其至少一个直接或间接上游数据包，本数据包为“已过时”状态；当一个“已过时”数据包的所有上游数据包都是“无需更新”状态时，本数据包为“待更新”状态。

技术状态一致性检查器进行技术状态一致性检查的工作流程为：

(1)将所有数据包置为“无需更新”状态；

(2)遍历所有的数据包，对每个数据包进行“已过时”状态检查，即检查每个数据包的所有直接上游数据包的状态和版本，如果存在一个以上直接上游数据包为“已过时”状态或者存在一个以上直接上游数据包的版本号大于该数据包，则将该数据包更新为“已过时”状态，进入步骤(3)，如果该数据包的所有直接上游数据包均为“无需更新”状态且所有直接上游数据包的版本号均不大于该数据包，则保留本数据包的“无需更新”状态，进入步骤(3)；

(3)遍历所有“已过时”状态的数据包的每一个数据包的所有直接上游数据包，如果上游数据包均为“无需更新”状态，将该数据包改为“待更新”状态，直到所有“已过时”状态的数据包处理完毕。

技术状态一致性检查器工作流程中的步骤(2)中所述遍历所有数据包，对每个数据包进行“已过时”状态检查的一种方法为轮循遍历法：

(1)选取任意一个数据包，对该数据包进行“已过时”状态检查；

(2)选取工程数据中下一个数据包，重复进行“已过时”状态检查，直到所有的数据包都检查完毕，完成全部数据包的一轮“已过时”状态检查；

(3)重复执行步骤(1)～步骤(2)，循环对所有数据包进行新一轮“已过时”状态检查，直到本轮检测没有新增的数据包被更新为“已过时”状态为止。

技术状态一致性检查器工作流程中的步骤(2)中所述遍历所有数据包，对每个数据包进行“已过时”状态检查的另一种具体方法为排序遍历法：

(1)读取数据包“上下游”顺序表，所述数据包“上下游”顺序表中按照从上游至下游的顺序排列项目中所有的数据包；

(2)依次从数据包“上下游”顺序表中取出每个数据包，进行“已过时”状态检查，直到所有数据包检查完毕。

版本管理器创建数据包“上下游”顺序表的具体步骤为：

(1)新建一个空白列表：数据包“上下游”顺序表；

(2)新建一个数据包的列表A，将项目中所有的数据包以任意顺序放入列表A中；

(3)从列表A中的第一个数据包开始，依次针对每个数据包重复执行步骤(4)，直至列表A中的最后一个数据包处理完毕后，进入步骤(5)；

(4)如果该数据包没有上游数据包或其所有上游数据包都已在数据包“上下游”顺序表中，则将该数据包从列表A中移除，放置在一个临时的列表B中；

(5)将列表B中的所有数据包依次放置到数据包“上下游”顺序表最后一个元素之后，如果数据包“上下游”顺序表为空，则从头开始放置，进入步骤(6)；

(6)清空列表B；

(7)重复执行步骤(3)～步骤(6)，直到列表A为空，即其中所有数据包都已被转移至数据包“上下游”顺序表中。

版本管理器判断客户端文件提交合法性，将合法性判断结果发送给用户的工作流程为：

(1)用户需要修改工程数据时，将版本库中的工程数据下载到本地工作目录时，在本地工作目录中记录所有数据包当前版本记为下载时版本号；

(2)在客户端发起提交请求时，将上述下载时版本号同时提交至版本管理器，版本管理器判断本次更改涉及哪些数据包，选择每个已更改数据包，依次执行步骤(3)和步骤(4)；

(3)如果该数据包的直接或间接上游数据包的最新版本号大于“下载时版本号”，则报告“上游数据包已在上次下载后发生更改，请下载最新数据”的信息；

(4)如果该数据包为“已过时”状态，提示“上游数据包尚未完成更改，请等待直接上游数据包更改后再更改”；

(5)如果在步骤3和/或步骤4中报告了相应的提示信息，视为提交合法性检查失败，拒绝用户的此次提交。

版本管理器更新工程数据版本的具体工作流程为：

(1)响应客户端文件提交申请，将接收客户端提交的发生新增、修改、删除的文件和目录列入“更改列表”中；

(2)新建一个临时的空列表，称为“新版本列表”，用于存放将被分配新版本的文件和目录；

(3)从“更改列表”中的第一个文件或目录开始，逐个文件和目录进行以下步骤(4)～步骤(5)；

(4)如果该文件或目录不在新版本列表中，将该文件或目录存入新版本列表；

(5)从该文件开始，依次上溯其各级父目录，如果某一级父目录不在新版本列表中，则将其加入新版本列表；

(6)对“更改列表”中的所有文件及目录完成步骤(4)～步骤(5)之后，按版本号的生成规则，为本次更改形成一个新版本号；

(7)以新版本号和各文件、目录的路径为索引，将新版本列表中的所有文件和目录写入版本库。

技术状态通知生成器的工作流程为：

(1)在所有“已过时”和“待更新”状态的数据包，依次循环进行步骤(2)～(4)，每次处理一个数据包；

(2)如果该数据包为“待更新”状态，生成数据待更新的通知；

(3)如果该数据包为“已过时”状态，且其部分直接上游数据包为“无需更新”状态，生成预览上游数据通知；

(4)如果该数据包为“已过时”状态，且其所有直接上游数据包均为“已过时”状态，生成数据过时通知。

本发明的有益效果为：

(1)本发明对工程设计数据的历史版本进行记录和管理，能有效控制工程数据的技术状态，保证设计团队基于统一的、有效的数据源开展工作，方便协同工作，提高工作效率；

(2)复杂产品的设计过程中，多专业之间反复、快速地进行多种形式的迭代，实际执行的设计流程非常复杂。本发明打破了多变的设计流程的概念，只需定义数据之间的上下游关系这种相对固定的关系，即可保证上下游数据的一致性，提高了工程设计工作效率；

(3)复杂产品设计过程产生的数据项目众多，数据项目之间的“上下游”关系极为复杂，本发明可以对上下游数据的技术状态一致性进行自动判断，发现潜在的技术状态不一致问题，并向相关设计人员提供技术状态变更通知，提醒相关设计人员及时更新过时数据项目，应用本系统后，可以降低状态不一致的工程数据被误用的可能性，减少工程质量问题，避免经济损失；

(4)本发明针对技术状态一致性检查器遍历所有数据包，对每个数据包进行“已过时”状态检查提出了轮循遍历和排序遍历两种遍历方法，轮循遍历法流程简单，适用于对于数据包较少的项目，对于数据包数量大的项目采用排序遍历法对所有数据包遍历一遍即可标识出所有“已过时”状态的数据包，所消耗的机时少，能大大地提高检测效率；

(5)本发明根据工程数据“上下游”关系，在下游客户端提交数据时，根据其所依赖的上游数据版本变化对更改的数据进行合法性检查，发现下游用户进行工程设计时所使用的上游数据不是最新版本，向该用户发出提示消息，待下游用户消除了上下游数据状态不一致的问题后才能接受用户的文件提交，保证上下游数据技术状态一致；

(6)本发明在上游客户端提交数据时，更新上游数据版本后，自动判断关联数据技术状态一致性，并及时提醒相关的下游客户端及时更新过时数据以保证上下游数据状态一致；

(7)本发明为工程设计组内所有人员合理设置用户权限，对上下游数据的技术状态一致性进行自动判断发现的潜在的技术状态不一致问题，向相关管理人员提供动态通知，管理人员可以预览整个项目的通知和整个项目的技术状态，对整个项目有个全面的了解和掌控，增加了检验手段，提高了管理效率。

附图说明

图1为本发明的系统组成框图；

图2为本发明实施例火箭总体设计数据包“上下游”关系图；

图3为本发明技术状态一致性检查器工作流程图(轮循遍历法)；

图4为本发明版本管理器创建数据包“上下游”顺序表工作流程图；

图5为本发明技术状态一致性检查器工作流程图(排序遍历法)；

图6为本发明版本管理器提交合法性检查流程图；

图7为本发明版本管理器更新版本流程图；

图8为本发明技术状态通知生成器工作流程图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明：

工程设计特别是大型的工程设计通常涉及到多个专业融合，某一个专业的设计数据往往是另一个专业设计的基础，当其中任一个专业的设计数据发生变更势必会影响到另一个专业数据的设计。以在运载火箭设计领域的应用为例，某火箭总体设计的过程中包括了总体专业、气动专业、弹道专业和姿态控制专业，总体专业设计师负责总体参数、理论外形设计，气动专业设计师负责计算气动特性，弹道专业设计师负责计算标准弹道，姿态控制专业设计师负责系统控制能力分析。其中，气动特性计算依赖于理论外形设计，标准弹道数据依赖总体参数和气动特性，控制能力分析又依赖于总体参数、标准弹道、气动特性。如此错综复杂的数据关系一旦出现各个数据之间技术状态不一致，最终输出的结果将不可实现，带来重大损失，因此，建立一种适用于复杂产品工程设计的自动判断关联数据技术状态一致性的版本管理系统非常必要。

本发明提出一种自动判断关联数据技术状态一致性的版本管理系统，包括版本库、版本管理器、技术状态一致性检查器和技术状态通知生成器，如图1所示。下面详细介绍一下各个部分的功能和工作流程：

一.版本库

版本库为计算机存储介质，用来存储工程数据、数据包状态表、数据包“上下游”关系表、数据包“上下游”顺序表和用户权限信息表。

工程数据分项目存储，为从项目根目录开始的由目录和文件组成的树形结构，包括根目录、子目录和文件名称及内容。

工程数据建立后，在初始状态下，系统中的所有文件和目录具有同一个最小版本号，系统使用正整数对版本进行标识，如“1”。

版本管理系统允许对数据进行更改，每次更改以提交作为条件，一次提交包含对一个或多个目录或文件的内容改变、增加或删除，这些文件和目录可以位于同一个或不同的目录中。在一次提交中发生内容改变，或增加的目录和文件需要有新的版本号进行标识，系统自动分配一个比之前所有版本号都大的正整数作为这次提交内容的版本号，如“2”。更改后，同时记录更改前后的版本，并用不同的标识符对版本进行标识，版本号单调递增，如：此次提交的内容在系统中既存在“1”版本，也存在“2”版本。

需要指出的是版本号不一定连续，只要单调递增即可。比如，为体现版本变化与时间的对应关系，可以使用从某一约定时刻算起的、更改发生时刻的毫秒数为版本号。

系统中的另一项重要功能是在一个目录中的内容发生变化时，自动为该目录也形成新版本。当一次提交的内容包含某个目录中的文件或子目录时，该目录自动被纳入此次提交的范围之内，视为其内容也发生了改变，并依次上溯直到根目录。这些目录在提交后均获得新版本。

因此，版本库中存储了工程数据的所有版本，版本库中的目录和文件均可存在多个版本，并用不同的标识符对版本进行标识，版本库以版本号和路径共同作为其中存储的目录和文件的索引。

由于版本库所需要的存储容量大，一般情况下，版本库建立在服务器中，也可以是普通计算机。

数据包在版本库中对应于项目里的各个子目录，一般情况下，一个数据包对应一个子目录。如火箭总体设计项目包括5个数据包：总体参数数据包、理论外形数据包、气动特性数据包、标准弹道数据包和控制能力分析结果数据包，它们分别存放在项目不同子目录中。

数据包状态表，用来存储数据包的更新情况。数据包的状态通过比较其上游数据包和本数据包的版本号来确定，根据以下原则分为“无需更新”、“已过时”和“待更新”三类：

(1)当本数据包的最新版本号大于其所有上游数据包的最新版本号时，本数据包为“无需更新”状态；

(2)当本数据包的版本号小于其至少一个直接或间接上游数据包，本数据包为“已过时”状态；

(3)当一个已过时数据包的所有上游数据包都是“无需更新”状态时，本数据包为“待更新”状态。

“待更新”状态是“已过时”状态的一种特例，是“已过时”的数据包中所有上游已经就绪，可以立即开始更改的数据包，其他“已过时”数据包则因为自身的直接上游数据包尚未全部完成更新，暂不能立即更新。

当所有数据包均为“无需更新”状态时，系统认为所有数据包的技术状态一致，否则，系统认为“待更新”及“已过时”状态标记处需要更新的数据包。

数据包“上下游”关系根据工程设计中相对固化的计算过程来确定，以“上游数据”数据为计算输入，计算生成“下游数据”。数据包“上下游”关系表中记录各数据包的所有直接上游数据包和间接上游数据包，一个数据包的直接上游数据包的直接上游数据包是该数据包的间接上游数据包，以此类推，一个数据包的所有间接上游数据包的直接上游数据包也是该数据包的间接上游数据包；数据包之间不能嵌套，如数据包A的上游数据包仍为数据包A；不允许用户定义循环依赖的数据包上下游关系，即任何数据包的直接或间接上游数据包不能是其自身，如数据包A的上游数据包为数据包B，数据包B的上游数据包为数据包A。如图2所示：气动特性数据包的直接上游数据包为理论外形数据包；标准弹道数据包的直接上游数据包为总体参数数据包和气动特性数据包；控制能力分析结果数据包的直接上游数据包为总体参数数据包、标准弹道数据包和气动特性数据包，理论外形数据包为控制能力分析结果数据包的间接上游数据包。

数据包“上下游”顺序表按照从上游至下游的顺序排列项目中所有的数据包。

用户权限信息表，用来定义哪些用户对那些数据可以浏览或修改的权限。在工程设计中，考虑到各个专业组的设计工作由不同专业组的人员完成，项目组中还包括项目主管、检验人员等管理人员，为了数据安全为每个用户定义不同的权限，只能浏览和修改与自己相关的数据包。另外，管理人员可以预览整个项目的通知和整个项目的技术状态，对整个项目有个全面的了解和掌控，增加了检验手段，提高管理效率。

二.版本管理器

版本管理器，用来新建工程数据；将工程数据中的子目录定义为数据包，确定数据包“上下游”的关系，生成数据包“上下游”关系表和数据包“上下游”顺序表；为每个数据包定义用户权限，形成用户权限信息表；判断客户端文件提交合法性，将合法性判断结果发送给用户；响应客户端文件提交申请，更新工程数据版本；

如图6所示，版本管理器判断客户端文件提交合法性，将合法性判断结果发送给用户的工作流程为：

(1)用户需要修改工程数据时，将版本库中的工程数据下载到本地工作目录时，在本地工作目录中记录所有数据包当前版本记为下载时版本号；

(2)在客户端发起提交请求时，将上述下载时版本号同时提交至版本库，版本管理器判断本次更改涉及哪些数据包，选择每个已更改数据包，依次执行步骤3～步骤4；

(3)如果该数据包的直接或间接上游数据包的最新版本号大于“下载时版本号”，则报告“上游数据包已在上次下载后发生更改，请下载最新数据”的信息；

(4)如果该数据包为“已过时”状态，提示“上游数据包尚未完成更改，请等待直接上游数据包更改后再更改”；

(5)如果在步骤3和/或步骤4中报告了相应的提示信息，视为提交合法性检查失败，拒绝用户的此次提交。

如图7所示，所述版本管理器更新工程数据版本是指接受用户提交的对工程数据中的一个或多个目录或文件的内容改变、增加或删除，为变化或增加的文件及其各级父目录分配新的版本号进行标识，依次上溯到该项目根目录，并记录工程数据内容变更前后所有目录和文件的版本，将工程数据以新的版本形式存入版本库，具体工作流程为：

(1)响应客户端文件提交申请，将接收客户端提交的发生新增、修改、删除的文件和目录列入“更改列表”中；

(2)新建一个临时的空列表，称为“新版本列表”，用于存放将被分配新版本的文件和目录；

(3)从“更改列表”中的第一个文件或目录开始，逐个文件和目录进行以下步骤4～步骤5；

(4)如果该文件或目录不在新版本列表中，将该文件或目录存入新版本列表；

(5)从该文件开始，依次上溯其各级父目录，如果某一级父目录不在新版本列表中，则将其加入新版本列表；

(6)对“更改列表”中的所有文件及目录完成步骤4～步骤5之后，按版本号的生成规则，缺省的生成规则是新版本号＝最大的现有版本号+1，为本次更改形成一个新版本号；

(7)以新版本号和各文件、目录的路径为索引，将新版本列表中的所有文件和目录写入版本库。

版本管理器的另一个功能在生成数据包“上下游”关系表后，创建数据包“上下游”顺序表，如图4所示，其具体步骤为：

(1)新建一个空白的有序列表：数据包“上下游”顺序表；

(2)新建一个数据包的列表A，将项目中所有的数据包以任意顺序放入列表A中；

(3)从列表A中的第一个数据包开始，依次针对每个数据包重复执行步骤(4)，直至列表A中的最后一个数据包处理完毕；

(4)如果该数据包没有上游数据包，或其所有上游数据包都已在数据包“上下游”顺序表中，则将该数据包从列表A中移除，放置在一个临时的列表B中；

(5)将列表B中的所有数据包，依次放置到数据包“上下游”顺序表最后一个元素之后，如果数据包“上下游”顺序表为空，则从头开始放置，进入步骤(6)；

(6)清空列表B；

(7)重复执行步骤(3)～(6)，直到列表A为空，即其中所有数据包都已被转移至数据包“上下游”顺序表中。

数据包“上下游”顺序表中按照从上游至下游的顺序排列项目中所有的数据包，如图2所示的火箭总体设计数据包“上下游”顺序表中的数据包依次为：总体参数数据包、理论外形数据包、气动特性数据包、标准弹道数据包和控制能力分析结果数据包。

三.技术状态一致性检查器

技术状态一致性检查器，读取工程数据所有文件和目录版本，创建所有数据包版本快照，根据数据包“上下游”关系及数据包的版本，进行技术状态一致性检查，更新版本库中数据包状态表中的数据包状态。

如图3所示，技术状态一致性检查器进行技术状态一致性检查可以采用轮循遍历法，其具体工作流程为：

(1)将所有数据包置为“无需更新”状态；

(2)任意选取一个数据包，进入步骤(3)；

(3)考察该数据包的所有直接上游数据包的状态和版本，如果存在一个以上直接上游数据包为“已过时”状态或者存在一个以上直接上游数据包的版本号大于该数据包，则将该数据包更新为“已过时”状态，进入步骤(4)，如果该数据包的所有直接上游数据包均为“无需更新”状态且所有直接上游数据包的版本号均不大于该数据包，则保留本数据包的“无需更新”状态，进入步骤(5)；

(4)记录“有数据包被改为‘已过时’状态”这一信息，进入步骤(5)；

(5)任意选取下一个数据包，重复执行步骤(3)，直到所有的数据包都处理完毕；

(6)如果在步骤(4)中记录了“有数据包被改为‘已过时’状态”这一信息，重复执行步骤(2)～步骤(5)，循环对所有数据包进行新一轮状态检查，直到本轮检测没有新增的数据包被更新为“已过时”状态为止；

(7)任意选取一个“已过时”状态的数据包，进入步骤(8)；

(8)考察该数据包的所有直接上游数据包，如果上游数据包均为“无需更新”状态，将该数据包改为“待更新”；

(9)选取下一个“已过时”状态的数据包，重复执行步骤(8)，直到所有“已过时”状态的数据包处理完毕。

当项目的数据包数量小，层次较少时，采用上述方法遍历所有数据包的次数不多，流程简单，当项目的数据包数量大、层次较多，需要遍历的次数较多，比较费时，技术状态一致性检查器还可以采用另一种检查方法进行“已过时”状态检查，该方法先采用版本管理器对数据包进行“上下游”排序，形成按照从上游到下游的顺序排列的数据包“上下游”顺序表，然后按照数据包“上下游”顺序表中的顺序依次取出数据包，进行“已过时”状态检查，直到所有数据包都检查完毕，再遍历所有“已过时”的数据包，检查每个数据包的直接上游数据包是否均为“无需更新”状态，将该数据包改为“待更新”状态。

这种方法只需要对所有数据包进行一次遍历就能将所有的“已过时”数据包检测出来，对于数据包数量大的情况，大大提高系统进行状态一致性检查效率。

技术状态一致性检查器在客户端提交数据之后立即对版本库中数据包状态表中的数据包状态进行更新。

四.技术状态通知生成器

技术状态通知生成器，读取版本库中的数据包状态信息、数据包“上下游”关系信息、用户权限信息，根据技术状态一致性检查结果，生成技术状态变化消息，根据用户权限信息，提供给与消息对应的数据包相关联的客户端。

如图8所示，技术状态通知生成器的工作流程为：

(1)在所有“已过时”和“待更新”状态的数据包，依次循环进行步骤(2)～(4)，每次处理一个数据包；

(2)如果该数据包为“待更新”状态，生成数据待更新的通知，如“该数据的间接上游已更改，且部分直接上游已完成更改，请预览已就绪的上游数据并准备更改该数据”；

(3)如果该数据包为“已过时”状态，且其部分直接上游数据包为“无需更新”状态，生成预览上游数据通知，如“该数据的间接上游已更改，且部分直接上游已完成更改，请预览已就绪的上游数据并准备更改该数据”；

(4)如果该数据包为“已过时”状态，且其所有直接上游数据包均为“已过时”状态，生成数据过时通知，如“该数据的间接上游已更改，但直接上游尚未完成更改，请关注”的信息。

技术状态通知生成器产生的通知信息根据用户权限表中所表示的数据包和用户的关联关系，只提供给与消息对应的数据包相关联的用户。

技术状态通知生成器在每次技术状态检查器完成检查后立即执行，一旦发现的潜在的技术状态不一致问题，及时通知相关设计人员提供技术动态变更通知，提醒相关设计人员及时更新过时数据项目，如果被通知用户处于离线状态，用户开机后系统向该用户自动推送技术状态通知。

本系统还可以同时向相关管理人员提供动态通知，管理人员也可以随时预览整个项目的技术状态，对整个项目有个全面的了解和掌控，增加了检验手段，提高了管理效率。

实施例1：

以运载火箭总体设计为例，假设目前工程数据中总体参数数据包、理论外形数据包的最新版本号为2，气动特性数据包的最新版本号为3，标准弹道数据包的最新版本号为4，控制能力分析结果数据包的最新版本号为5。如图2所示。

此时，总体专业设计师提交了新版本的理论外形数据包，版本号为6。技术状态检查器采用轮循遍历法开始对上述数据进行技术状态一致性检查。其检查过程如下：

首先，将所有数据包置为“无需更新”状态；

然后，判断哪些数据包为“已过时”状态：

第一次遍历所有数据包，此次遍历中，气动特性数据包由于其上游理论外形数据包的版本号6大于其自身版本号3，因此被置为“已过时”状态。

第二次遍历所有数据包，此次遍历中，标准弹道数据包和控制能力分析结果数据包由于上游气动特性数据包的状态为“已过时”，因此也被置为“已过时”状态。

第三次遍历所有数据包，此次遍历中，由于没有新的数据包从“无需更新”状态被改为“已过时”状态，因此不在进行第四次遍历，停止“已过时”状态的判断。

接着，判断哪些“已过时”状态的数据包实际为“待更新”状态：

依次遍历所有“已过时”状态数据包，只有气动特性数据包的全部直接上游数据包(理论外形)都是“无需更新”状态，被更改为“待更新”状态。

整个技术状态一致性检查过程结束。

技术状态一致性检查的最终结果为：

无需更新：总体参数、理论外形

待更新：气动参数

已过时：标准弹道、控制能力分析结果

技术状态通知生成器针对每个数据包生成技术状态通知，其结果为：

为“待更新”状态的气动参数数据包所对应的客户端发出通知：“该数据包的所有上游数据包(理论外形)已完成更改，请及时更改该数据包”；

为“已过时”状态的标准弹道和控制能力分析结果数据包对应的客户端发出通知：“该数据包的间接上游(理论外形)已更改，但直接上游(气动特性)尚未完成更改，请关注”。

通过上述技术状态检查器的检查和技术状态通知器的及时通知，下游客户端获知上游客户端已经对系统数据进行了变更，下游数据尽快确认技术状态并及时更改下游数据，以保证下游数据包的数据与上游数据包的数据状态一致，大大地提高了研发效率，确保了工程设计的质量。

实施例2：

仍然采用实施例1中的数据包初始状态，如图2所示。

假设此时，姿态控制专业设计师将最新版本的数据更新到个人工作目录，其工作目录中的数据包版本如下：

总体参数：版本2；

理论外形：版本2；

气动特性：版本3；

标准弹道：版本4；

控制能力分析结果：版本5。

同时，版本管理器在该工作目录中记录更新版本号5。

假设姿态控制专业设计师依据此版本数据，开始了新一轮的控制能力分析，准备输出新的控制能力分析结果。

在此期间，总体专业设计师更新了理论外形数据包，新的版本号为6。

姿态控制专业设计师完成了新一轮的控制能力分析，通过版本管理器将新的控制能力分析结果数据包作为更改提交，版本管理器将更新的数据包以及工作目录中记录的更新版本号5同时提交至服务器端。

版本管理器的服务器端收到此提交请求后，开始对提交的合法性进行判断。由于提交只涉及到一个数据包“控制能力分析结果”，因此判断只针对该数据包进行。

由于该数据包的一个上游数据包“理论外形”的最新版本号为6，大于更新版本号5，因此提示“上游数据包(理论外形)已在上次更新后发生更改，请更新最新数据”的信息。

假设总体专业设计师更新了理论外形数据包之后，技术状态一致性检查器对数据一致性进行了检查，对数据包的状态进行了更新，那么，该控制能力分析结果数据包的状态为“已过时”，因此提示“上游数据包(气动特性)尚未完成更改，请等待直接上游数据包更新后再更改”。

由于出现上述提示信息，提交合法性检查失败，拒绝此次提交，设计师根据系统提示，对所采用的上游数据版本进行确认之后，再重新提交正确的数据包，确保各个数据包的状态一致。

合法性检查的技术手段与技术状态一致性检查的技术手段相互补充，能有效地避免因为下游设计师使用的上游数据包的数据过时，导致提交的新的下游数据与系统中上游数据包的数据不对应的问题，维护了工程数据版本的一致性，可以降低状态不一致的工程数据被误用的可能性，减少工程质量问题，避免经济损失。

本发明说明书中未作详细描述的内容属于本领域专业技术人员公知技术。

Claims (10)

1.一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于包括版本库、版本管理器、技术状态一致性检查器和技术状态通知生成器，其中：

版本管理器，新建或导入工程数据，所述工程数据分项目存储，一个项目从项目根目录开始，包括根目录、子目录和文件名称及内容；将工程数据中指定的子目录定义为数据包，确定数据包“上下游”的关系，生成数据包“上下游”关系表和数据包“上下游”顺序表；为每个数据包定义用户权限，形成用户权限信息表；判断客户端文件提交合法性，将合法性判断结果发送给客户端；响应客户端文件提交申请，为变化或增加的文件及其各级父目录按照单调递增的原则分配新的版本号进行标识，更新工程数据版本；数据包状态表、数据包“上下游”关系表、数据包“上下游”顺序表、用户权限信息表和各个版本的工程数据均存入版本库；

技术状态一致性检查器，读取工程数据所有文件和目录版本，创建所有数据包版本快照；根据数据包“上下游”关系及数据包版本快照中的数据包版本号进行技术状态一致性检查，更新数据包状态表中的数据包状态，存入版本库；

技术状态通知生成器，读取版本库中的数据包状态信息、数据包“上下游”关系信息、用户权限信息，生成技术状态变化消息，根据用户权限信息，提供给与消息对应的数据包相关联的客户端。

2.根据权利要求1所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述数据包“上下游”关系表中记录各数据包的所有直接上游数据包，所述直接上游数据包定义为与该数据包存在“上下游”关系的所有数据包中与该数据包最近的上游数据包，其他各数据包均为间接上游数据包，直接上游数据包和间接上游数据包合为该数据包的上游数据包。

3.根据权利要求2所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述数据包状态表中存储每个数据包的状态，所述数据包状态依据以下原则分为“无需更新”、“已过时”和“待更新”三类：当本数据包的最新版本号大于其所有上游数据包的最新版本号时，本数据包为“无需更新”状态；当本数据包的版本号小于其至少一个直接或间接上游数据包，本数据包为“已过时”状态；当一个“已过时”数据包的所有上游数据包都是“无需更新”状态时，本数据包为“待更新”状态。

4.根据权利要求3所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述技术状态一致性检查器进行技术状态一致性检查的工作流程为：

(1)将所有数据包置为“无需更新”状态；

(2)遍历所有的数据包，对每个数据包进行“已过时”状态检查，即检查每个数据包的所有直接上游数据包的状态和版本，如果存在一个以上直接上游数据包为“已过时”状态或者存在一个以上直接上游数据包的版本号大于该数据包，则将该数据包更新为“已过时”状态，进入步骤(3)，如果该数据包的所有直接上游数据包均为“无需更新”状态且所有直接上游数据包的版本号均不大于该数据包，则保留本数据包的“无需更新”状态，进入步骤(3)；

(3)遍历所有“已过时”状态的数据包的每一个数据包的所有直接上游数据包，如果上游数据包均为“无需更新”状态，将该数据包改为“待更新”状态，直到所有“已过时”状态的数据包处理完毕。

5.根据权利要求4所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述技术状态一致性检查器工作流程中的步骤(2)中所述遍历所有数据包，对每个数据包进行“已过时”状态检查的一种方法为轮循遍历法：

(1)选取任意一个数据包，对该数据包进行“已过时”状态检查；

(2)选取工程数据中下一个数据包，重复进行“已过时”状态检查，直到所有的数据包都检查完毕，完成全部数据包的一轮“已过时”状态检查；

(3)重复执行步骤(1)～步骤(2)，循环对所有数据包进行新一轮“已过时”状态检查，直到本轮检测没有新增的数据包被更新为“已过时”状态为止。

6.根据权利要求4所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述技术状态一致性检查器工作流程中的步骤(2)中所述遍历所有数据包，对每个数据包进行“已过时”状态检查的另一种具体方法为排序遍历法：

(1)读取数据包“上下游”顺序表，所述数据包“上下游”顺序表中按照从上游至下游的顺序排列项目中所有的数据包；

(2)依次从数据包“上下游”顺序表中取出每个数据包，进行“已过时”状态检查，直到所有数据包检查完毕。

7.根据权利要求1所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述版本管理器创建数据包“上下游”顺序表的具体步骤为：

(1)新建一个空白列表：数据包“上下游”顺序表；

(2)新建一个数据包的列表A，将项目中所有的数据包以任意顺序放入列表A中；

(3)从列表A中的第一个数据包开始，依次针对每个数据包重复执行步骤(4)，直至列表A中的最后一个数据包处理完毕后，进入步骤(5)；

(4)如果该数据包没有上游数据包或其所有上游数据包都已在数据包“上下游”顺序表中，则将该数据包从列表A中移除，放置在一个临时的列表B中；

(5)将列表B中的所有数据包依次放置到数据包“上下游”顺序表最后一个元素之后，如果数据包“上下游”顺序表为空，则从头开始放置，进入步骤(6)；

(6)清空列表B；

(7)重复执行步骤(3)～步骤(6)，直到列表A为空，即其中所有数据包都已被转移至数据包“上下游”顺序表中。

8.根据权利要求1所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述版本管理器判断客户端文件提交合法性，将合法性判断结果发送给用户的工作流程为：

(1)用户需要修改工程数据时，将版本库中的工程数据下载到本地工作目录时，在本地工作目录中记录所有数据包当前版本记为下载时版本号；

(2)在客户端发起提交请求时，将上述下载时版本号同时提交至版本管理器，版本管理器判断本次更改涉及哪些数据包，选择每个已更改数据包，依次执行步骤(3)和步骤(4)；

(3)如果该数据包的直接或间接上游数据包的最新版本号大于“下载时版本号”，则报告“上游数据包已在上次下载后发生更改，请下载最新数据”的信息；

(4)如果该数据包为“已过时”状态，提示“上游数据包尚未完成更改，请等待直接上游数据包更改后再更改”；

(5)如果在步骤3和/或步骤4中报告了相应的提示信息，视为提交合法性检查失败，拒绝用户的此次提交。

9.根据权利要求1所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述版本管理器更新工程数据版本的具体工作流程为：

(1)响应客户端文件提交申请，将接收客户端提交的发生新增、修改、删除的文件和目录列入“更改列表”中；

(2)新建一个临时的空列表，称为“新版本列表”，用于存放将被分配新版本的文件和目录；

(3)从“更改列表”中的第一个文件或目录开始，逐个文件和目录进行以下步骤(4)～步骤(5)；

(4)如果该文件或目录不在新版本列表中，将该文件或目录存入新版本列表；

(5)从该文件开始，依次上溯其各级父目录，如果某一级父目录不在新版本列表中，则将其加入新版本列表；

(6)对“更改列表”中的所有文件及目录完成步骤(4)～步骤(5)之后，按版本号的生成规则，为本次更改形成一个新版本号；

(7)以新版本号和各文件、目录的路径为索引，将新版本列表中的所有文件和目录写入版本库。

10.根据权利要求1所述的一种自动判断关联数据技术状态一致性的版本管理系统，其特征在于所述技术状态通知生成器的工作流程为：

(1)在所有“已过时”和“待更新”状态的数据包，依次循环进行步骤(2)～(4)，每次处理一个数据包；

(2)如果该数据包为“待更新”状态，生成数据待更新的通知；

(3)如果该数据包为“已过时”状态，且其部分直接上游数据包为“无需更新”状态，生成预览上游数据通知；

(4)如果该数据包为“已过时”状态，且其所有直接上游数据包均为“已过时”状态，生成数据过时通知。