PDM支持协同开发的版本管理

【导读】
在产品开发设计中,一个设计对象可能会由于描述方法的不同、设计方案的差异或性能要求的差别在设计过程的各个阶段形成不同的版本。产品开发的设计过程总是分阶段、反复而非线
4.1版本管理
4.1.1版本的概念

  在产品开发设计中,一个设计对象可能会由于描述方法的不同、设计方案的差异或性能要求的差别在设计过程的各个阶段形成不同的版本。产品开发的设计过程总是分阶段、反复而非线性的,总要遵循一定的工作流程,每一个阶段都需要经过校核、审核和批准等既定的流程,形成最终的正式版本发放。版本反应了设计对象在产品开发过程中不断演变的动态变化。
 

  在产品设计过程中,可能会对设计对象进行多次的修改,版本状态也会随着发生多次的改变,因此设计人员希望可以随时能够查阅先前版本,也想保留设计过程中不断改进的中间结果,以便进行比较、优化。因此,版本是一个对象在设计过程中某一时间点上有意义的快照。设计的版本不仅包含了设计对象在当时的所有信息,而且还反应了该版本的设计对象与其相关联对象的联系。版本管理是系统地处理版本对象的方法,不仅要管理一个设计对象的各个版本,还要管理他们之间的关联关系。
 
4.1.2版本管理模型

  版本可以由用户自己创建,也能够从现存的版本中导出,因此,版本与版本之间存在导出与派生的关系,这种关系可以通过版本导出历史来描述。每一个存储版本都是设计过程中关键成果的显现,不同版本代表了设计成果的不同阶段或对不同方案的选择。版本管理模型按版本的导出规则分为线性模型、树形模型以及图结构模型。
 
  1、线性模型
  线性模型是最简单的版本管理模型,它依据版本出现的时间顺序进行依次排列,其中每个版本最多只可以有一个前驱版本即父版本,且只能有一个后续版本即子版本,呈单行链式结构,设计过程产生的新版本会自动插入链尾,除了最新版本外其余版本只读,如下图4-1所示:
 
图4-1线性版本模型
 
  线性版本模型的缺点就是不能反应不同版本逻辑间的关系。时间上出现在后面的版本不一定是由它的前驱版本得出的,不能够反应版本之间的依赖性。
 
  2、树形模型
  树形模型能够反应出产品开发过程中以某一个中间设计版本为基础,选择不同的设计方案得出的多个不同的设计结果。在该模型中,每个节点表示为一个版本,每一条边表示为版本间的依赖关系,如图4-2所示:
 
图4-2树形版本模型
 
  树形模型克服了线性版本模型的缺陷,具有层次清晰,关系明确,多个版本可以平行存在等特点。不过也有其局限性,即一个版本不能有多起始版本,或称为父版本,也不能反应出由多个版本合并成一个新版本的情况。
 
  3、图结构模型
  图结构模型即为有向无环图模型,它可以清楚地描述版本的历史信息,可以反应出多个版本融合成一个版本的情况。一个版本可以有多个初始版本,表示版本的合并;一个版本也可以有多个分支,表示版本的派生或修订。图结构模型的版本既可以平行存在,也可以存在多个父版本,能真实的反应版本之间的继承和依赖关系。因此它是一个比较完善的版本模型。如下图4-3所示:
 
图4-3图结构版本模型
 
  图结构版本模型支持多继承,能够表达出丰富的语义,但其缺点在于增加数据结构的复杂性为代价来表示版本之间的替换、继承和历史描述;同时,它也失去了树形结构所具有的层次性,它只能用节点序号来描述版本的产生次序和来源,无法表示该版本间的逻辑层次性。
 
4.1.3PDM中的版本管理
  PDM中的版本管理可以分为对事务对象的管理和对数据对象的管理,前者如对零件、部件、文件夹等的管理,后者如对各种文档,流程数据等的管理等。PDM对这些对象一般采用的是线性版本管理模型,按照时间的先后顺序系统自动生成一个版本号,且不允许重复。产品设计的过程是设计对象从一个工作状态转向另一个工作状态迁移的过程,将各设计对象的各版本及其状态进行综合,可以反映出各设计对象设计过程的变迁。
 
  在PDM的版本管理中,采用不同的版本状态来表示各个数据库版本,主要有四种版本状态:工作状态、提交状态、发放状态和冻结状态,对应的版本称之为工作版本、提交版本、发放版本和冻结版本。
 
  1、工作版本是处于设计阶段的版本,是停留在设计人员私有数据库中待完成的版本。因为它属于当前设计者所有,因此其他设计人员不能访问。工作版本一般是由设计人员的初始设计产生,也可以从其他状态版本导出,比如从提交版本、冻结版本,以及其他工作版本也可以导出新的工作版本。
 
  2、提交版本是指设计工作已经完成,需要提交到项目组版本库中,等待审批人员进行确认审批的版本。提交版本不允许修改和删除,可以查看,但不可以引用。提交版本只有审批人员具有相关圈阅权限,其他人员只能浏览。在审批过程中如需修改,相关人员可以通过检出操作将提交版本导出到自己的私人工作区中。
 
  3、发放版本是指提交版本通过审批流程的检查、批准后,通过发放操作产生的版本。发放版本也被称为有用版本,一个设计结果只有通过发放后,才能用来进行生产活动。发放状态的版本不能修改,只能对其查询。
 
  4、冻结版本在设计过程的某段时间内,若需要版本的状态保持不变,或是已达到了某种要求设计,在一定时间内保持不变的版本,为了将其状态固定,通常通过冻结操来完成,称之为冻结版本。冻结版本通常存储在项目组的公用版本库中,不允许对其更新和删除,但是冻结版本在进行解冻操作后即可以成为工作版本,即可对他进行操作。提交版本在审批阶段即为冻结版本,发放版本也可以发作是一种冻结版本。四种类型版本的逻辑关系如下图4-4所示:
 
图4-4版本间的逻辑关系
 
  首先,设计人员接到工作任务时开始工作,创建工作版本。在设计人员完成工作任务后,将工作结果提交给相关人员评审,这时版本状态变为提交,即成为了提交版本。在提交版本评审过程为了保证工作的严肃性,除评审人员其他任何人都不能对正在评审的设计成果进行修订,所以必须对其冻结,使其成为了冻结版本。
 
  如果评审结果是设计存在缺陷或者是不满足有关指标等没有通过,那么设计人员需要根据评审意见和建议对原设计结果进行修改,此时冻结版本将进行解冻操作,转换成设计人员的工作版本;如果评审意见是设计结果正确合理,并且通过了各级审核,最终得到认可,可以用于生产实践,则进行批准操作,此时冻结版本就成为发放版本。
 
  发放的版本需要长久保存,不能随意对其进行修改和删除,进行要进行归档处理。企业经常通过对产品进行改进换代升级,来满足用户的新需求。产品改进通常是在原先已发放版本的基础上进行,即通过拷贝,对原版本进行改进操作,使其成为新的工作版本。
 
4.2协同开发中的版本管理
4.2.1协同开发版本管理的需求

  产品协同开发过程要求多个设计人员在分布网络环境下进行协同工作,为了保证协同工作的顺利完成,必须通过版本管理来确保开发过程信息的完整性,因此对协同开发过程的版本管理提出了如下要求:
 
  (1)能够记录开发过程的历史信息。实际的项目开发中,同一设计对象常常会有多个不同的设计方案,因此就会有多个不同的设计版本产生。一个好的设计版本通常是对多个设计版本进行分析、比较、综合后得到的,如此便要求版本管理系统不仅能够保留设计的最终结果,还能够保留设计过程中有关的方法和信息,即要求版本管理系统不仅能够对多种设计方案进行保留和管理,还可以将不断变化的设计模式和设计历史进行记录。
 
  (2)能够管理整个项目的进程。一个开发项目通常包含着若干个设计对象,各个对象之间互相依赖,版本管理不仅能够保留各个设计对象的历史版本,还要能够记录整个项目的变迁。如此版本管理在记录设计对象各个版本信息的同时,也要对整个项目目录版本的变化进行记录。

  (3)能够进行快速便捷的查阅。协同开发系统分布于整个网络上,与产品设计、制造相关的数据和模型都寄存在服务器数据库中。随着开发工作的进行,大量的设计、制造对象的版本都需要进行存储,这就要求版本管理系统能够在大量数据的版本库中能够迅速准确地查找出目标版本,提高版本管理的效率。
 
  (4)能够清晰处理版本间关系。版本管理除了要存储各个设计对象的不同版本之外,还要保存不同版本之间的关系,即版本之间的依赖关系。在数据库中进行数据版本存储通常采用上述三种版本模型中的一种。究竟选择采用哪一种合适的版本模型,能够完成版本简单、完整、清晰地存储,达到数据冗余少,扩展强,易于理解和实现的目的,这些都需要根据项目的复杂程度,设计版本保留的要求和版本的显示效果来进行选择。
 
4.2.2协同开发版本管理的特点

  产品协同开发过程中的版本管理呈现以下三个不同的特点: 
  (1)多版本
  多版本就是指在某个时刻一个设计对象会有多个设计版本同时存在,版本管理的这个特性是由协同开发的特点造成的,它与多个成员在时间和空间的上分散特点有关,因此我们可以从这两方面对多版本进行分类。
 
  时间多版本在项目的开发中,对设计结果的修改是一种经常性的活动,每一次的修改都可能有新版本的产生。出于对版本的保护,在新版本没有得到批准实用的情况下,旧版本必须保存不得删除,如此在版本库中就会同时存在新旧两个版本。这种可以用时间先后来标记的版本称之为时间多版本。
 
  空间多版本是与协同开发过程中有多个成员参与的特点有关。对于同一个对象,不同领域的专家考虑的出发点不同,这就会导致同一对象可能会出现多个不同的设计版本。空间多版本又可以分为平行空间多版本和视图空间多版本。平行空间多版本是指系统中同时存在一个对象的多个对等的版本,它是由于多个设计人员对同一设计结果进行修改产生的,每个设计方案都有其合理性。
 
  当然,这只不过是一种临时现象,在项目完成之后会有一个唯一公认的设计版本。而视图空间多版本是指在项目组的公共空间中存放着发放公认的设计结果,而在私人的工作空间中存放着自己对设计结果的工作经历,有意见、方案,计算过程等等有用的信息,可以为以后的设计工作的顺利进行有帮助。因此在公共空间和私人空间中存放着不同的版本信息,称之为视图空间多版本,
 
  (2)动态性
  动态性是指版本状态在产品开发过程中时刻发生着变化,每个状态的版本都存在一定的生命周期。随着设计工作的推进,设计对象的版本状态会发生相应的改变,如下图4-5所示的版本的动态变化:
 
图4-5版本的动态变化
 
  (3)关联性
  关联性是指同一个项目中各子项目或子对象的版本之间相互关联。一个项目对象往往是由简单的子项目或任务组成,呈复合特性,因此,各个子项目或子对象的当前有效版本整合成整个项目的一个有效版本。各个子对象之间存在相互制约关系,比如常见而又重要的尺寸约束关系,影响着产品的装配过程。在产品开发过程中,这种约束关系会映射到产品设计对象的版本关系上。因此,一个设计对象的版本在横向上也不是独立的,与其他设计对象紧密相关。
 
4.3协同开发中版本并发控制机制
  协同开发环境下版本并发控制是版本管理所要解决的一个基本问题。分散在协同环境下的产品开发是一个多人协助的活动,设计人员需要在私人工作空间中处理一些数据,还需要从服务器数据库中贡献某些数据,即需要与数据库进行交互。
 
  在项目的开发过程中设计人员可能会同时对某些数据进行存取,如此便要求版本控制系统能够支持多用户对共享数据进行并发存取的操作。所有的版本管理系统都面临这样的问题,即如何满足使用者对某些数据的共享,不让他们相互阻碍和干扰。版本控制的作用在于方便项目参与人员之间的协同工作,防止同时访问数据库时产生冲突,从而实现并发操作
 
4.3.1协同开发中信息共享问题。
  在产品协同开发过程中,一个工作往往由两个或两个以上的开发人员协作完成的,每个协作者都对其有编辑、修改和上传的权限,这样在版本库中能很轻易地覆盖掉别人的工作成果,所以要求版本控制系统能够很好的解决设计信息在协作者之间的共享,防止因为意外操作而相互覆盖导致有关信息的丢失。
 
  如下图4-6所示,两个协作者共同对版本库中的文件W进行修改,设计师A首先完成他的工作,上传到服务器数据库中;接着,设计师B完成自己的工作,也上传服务器,这样就会把设计师A的修改版本覆盖掉。虽然设计师A的修改内容可能在数据库中做了记录不会被覆盖,但是设计师A的修改结果却不会出现在设计师B的上传版本中,因此版本库中最新的版本就不会出现设计师A的工作结果。
 
图4-6协同开发中的文件共享
 
4.3.2传统加锁解决方案
  在大多数的版本管理系统中,对共享信息的处理机制是采用的是“锁定修改-解锁”的方案来解决问题,这是一个很简单的解决方案。在某段时间内,版本库中的共享文件只允许被一个人操作。如下图4-7所示,在需要多个人对文件编辑修改时,设计师A首选读取该文件同时对其进行锁定,这样就保证了其他人员不能对其进行编辑修改和上传,因此设计师B不能读取该文件。如果设计师B发出编辑请求时,则服务器数据库也会拒绝该请求。只有设计师A将自己的修改版本上传数据库后解锁,设计师B才能进行读取锁定并做修改的操作。
 
图4-7传统文件共享解决方案
 
  虽然加锁方案解决了版本覆盖的问题,但是在实际应用过程中,其暴露出来的缺点也是显而易见的:锁定可能导致版本的管理问题;锁定可能导致不必要的等待和线性开发;锁定可能导致文件错误的安全状态等等。因此这种方案经常会制约和阻碍产品协同开发用户的工作进程。
 
4.3.3拷贝记录解决方案
  加锁解决方案是通过强制执行线性开发来解决版本的数据一致性问题,虽然方案简单有效但其效率低下。针对“锁定-修改-解锁”解决方案的缺点,本文提出“拷贝记录-修改提交-整合提示”的新的解决方案。
 
  在该方案中,每个设计师将共享版本在私人工作空间中建立一个工作拷贝,即公共工作空间的发放版本和在私人工作空间的工作版本的一个映射;同时,系统记录每个拷贝的设计师地址,为后面整合提示信息的发送保存依据。
 
  设计师在工作时只需要对自己的工作拷贝进行修改,而不需要访问公共空间的发放版本,这样就实行了并行化工作,克服了传统解决方案的线性开发,同时,由于不存在锁定,传统方案导致的管理问题和安全状态问题也就不复存在了。
 
  如下图4-8所示,当其中的一个设计师(如设计师A)完成修改后将自己的更改结果提交到版本库时,此时系统会根据先前记录做了拷贝的设计师地址,自动给还没有提交的其他设计师发送最新上传的版本信息和相应的修改记录。其他设计师(如设计师B)在获得最新版本信息后进行确认,然后检查最新版本与自己的修改是否存在冲突,如果没有冲突,在将自己的修改合并到最新版本中进行整合,之后提交到版本库中;如果经检查存在冲突,在列出冲突所在的具体位置,再进行讨论和修改。
 
  如果其他设计师没有确认最新的版本信息而直接提交版本库,系统则会给出当前版本已更新的提示,要求设计师查收最新版本信息和检查修改结果是否存在冲突。这样设计师B提交到版本库中的版本就包含了两个设计师最新的修改结果,设计师A也可以通过更新来获得最新的版本信息。
 
图4-8支持协同开发的文件共享解决方案
 
  在“拷贝记录-修改提交-整合提示”的新解决方案中,每个设计师都有自己的工作拷贝,可以各自并行工作,而不会相互影响,很好的实现了并行设计,提高了工作效率。同时,管理人员也不需要去解决“锁定-修改-解锁”方案中由于设计人员的疏忽而导致的死锁问题。在实践的运行过程中,本文提出的新方案运行平稳,设计师可以并行工作,不必等待,当工作于同一个文件时,很少会有交迭发生,信息提示及时,版本更新信息明确,且整合冲突方式简单,花费的解决时间远比等待解锁的时间要少。
 
4.4版本管理的存储模型
  版本的存储与软件系统的结构设计密切相关。当前大多数的版本控制系统是将版本进行集中统一存储,将版本存放到一台服务器的数据库上。为了适应未来大范围的协同工作,以及减轻通信压力,一些版本控制系统可能会将版本副本在多站点进行加载的版本控制方法。
 
  此方法尽管会增加数据存储的冗余,并且也会增大维护多站点数据一致性的难度,但能够减轻通信压力,提高协同工作效率。不过采用何种版本存储方式,需要视系统的规模来定。版本存储所要解决的问题是:怎样在数据庞大的版本库中准确、迅速地找到目标版本,怎样减少版本存储过程中的数据冗余。
 
  目前版本管理控制系统采用的版本存储模型主要有完整存储模型和差值存储模型。完整存储模型就是将版本的所有信息完整地存储在服务器数据库中,它的特点是版本存取的速度快,但是需要大量的存储空间,信息存储的冗余量大。
 
  通常情况下同一个设计对象的不同版本之间的差异不是很大,因此经常会出现多个版本都包含同一个文件的现象。差值存储是指完整存储初始版本以及存储以初始版本为基版本与当前版本之间的差异信息,其他完整的版本信息可以由基版本与差异信息恢复构成。
 
  差值存储能够大大减少存储空间,但是当差值版本结构深度过大,或者现版本离基版本过远,差异内容过多时,版本的存取速度都将受到较大影响。由于差值存储的版本差异信息与基版本有依赖关系,因此如果基版本被破坏或丢失,那么其他版本的恢复将很困难甚至无法恢复。在实际的项目中,因为考虑到完整存储会极大地浪费存储空间,所以目前常见的绝大多数的版本控制系统都采用差值存储方式。
 
4.4.1版本差值存储模型
  目前常见的版本差值存储模型有以下几种类型:
  (1)基差值存储模型:Vi=V0+△i|条件,其中V0是基版本,△i|条件是版本Vi相对于版本V0通过有关条件进行差值运算得到的差异信息。该差值模型完整存储基版本,以及所有后续版本与基版本V0之间的差值信息。该差值版本存储模型的优点是算法简单,在版本存取时只需要与基版本进行差值恢复运算,不需要对前面所有的前驱版本进行任何处理,即只涉及到当前版本与基版本,这样的版本存储模型具有存储速度快,而且节省空间的特点。
 
  不过随着当前现版本离基版本越远,版本结构深度的增加,版本之间的差异内容也会增多,当差异内容增加到一定程度时,基差值存储模型的空间效率便会大大降低,差值恢复的难度也随之加大。同时,基版本是基差值存储的核心版本,如果基版本丢失,则后续差值版本信息将全部失效。
 
  (2)前差值存储模型:Vi+1=Vi+△i|条件(i≥0),当i=0时,V0为基版本,其中△i|条件是版本Vi+1在版本Vi的基础上根据运算条件得到的差值信息。该差值存储模型也是只对初始版本信息进行完整存储,即完成存储基版本V0,对于其他每个版本只存储与其前驱版本的差值信息。
 
  由于两个版本相连而又是派生关系,所以差异内容相对来说则更少,因此大大减少了数据冗余,有效地提高了空间利用效率。但是该模型的缺点也很明显,那就是每次存取某一版本时,都必须从基版本开始逐层遍历所有前驱版本并逐一地差值恢复,如此这样,版本存取速度要受到很大影响,尤其是当版本的结构越深,那么存取的响应时间明显增长,速度减慢。
 
  而且该模型的存储是通过连续迭代方式进行的,所以只要中间的某一版本被磨坏或丢失,那么后续版本都将无法恢复。虽然该模型最大程度地利用了空间存储效率,但是对于那些要求版本存取速率快、响应时间短和版本数据安全较高的系统来说,该模型还是难以胜任。
 
  (3)后差值存储模型:Vi+1=Vi+△i|条件①,Vi=△i|条件②(i≥0),该模型有逻辑前后关系,即先进行①运算后进行②运算,即该模型只对当前最新的版本信息进行完整存储,以及对于其他版本与其后续版本之间的差值信息进行存储,即当Vi+1是版本树中最后一个版本时将存储其完整版本信息,Vi则存储Vi+1和Vi之间的差值信息△i|条件。
 
  该版本存储模型突出的优点是能够有效减少数据冗余和快速得到最新的完整版本信息,与前差值存储模型相比,该模型提取最新版本的时间比较少;但缺点是在提取非最新版本时,需要应用一定的算法,代价较大,因为系统需要逆向逐次进行旧版本差值恢复直到目标版本为止;如果最新版本丢失,那么所有版本都将无法恢复。
 
4.4.2其他存储方式
  (1)关键版本存储。是根据产品设计的需要,将产品设计过程中产生的不同版本划分为关键版本和非关键版本,非关键版本是在产品设计过程只起到一个桥梁作用,当关键版本生成之后,可以根据需要对非关键版本进行删除或保留。关键版本原则上给予保留。不过每个设计者对关键版本的认识存在区别,因此主观性很强。对于那些级别高,资历深的设计者的版本可能会更多的存储。
 
  (2)有限版本存储。数据库的版本不能无限制的存储,只保留有限的几个版本,随着新版本的生成,系统自动删除一些老的版本。这种方法能节省存储空间,但不能完全保留版本历史,造成访问时数据的缺失。
 
4.4.3融合差值存储模型
  在实际的项目中,设计对象的不同版本之间特别是相邻版本之间存在很大的相似性,使用差值存储方式进行存储,可以较好地减少数据存储冗余,提高存储效率。基差值存储模型,只涉及初始版本与当前版本,当差值内容较大时存储空间效率降低;前差值存储模型,对于新版本的建立比较容易,但是获取新版本效率则比较低;后差值存储模型,获取新版本比较便利,获取其他中间版本的代价则较大。
 
  差值存储的一个共同的缺陷是,数据的安全性集中在一个基版本上,如果基版本被删除或丢失,则其余版本都将无法恢,设计对象的版本历史记录等于丢失。虽然差值存储的是差异信息,但随着派生版本深度的增加,相对变更的内容在不断增多,进行版本存取时又必须从基版本开始逐层的恢复,所需的响应时间变长。因此本文提出一个新的差值存储模型——融合差值存储模型,该模型能够融合上述差值存储模型的优点,兼顾完整版本存储存取速度快的特性。
 
  融合差值存储模型保存三种完整版本,一种是基础版本(源版本),一种是中间版本(阶版本),另一个是最新版本。该模型采用阶段跳跃式进行版本差值存储,模型中包含一系列的“阶”,每一“阶”都会存储一个完整版本即阶版本,这个阶版本就是上述的基版本,每个“阶”中都会存储一组以阶版本为基版本计算而得的差值数据。融合差值存储模型如下所示:
 

  其中{V0,△(V0,V1),△(V0,V2)……△(V0,Vn-1)}和{Vn,△(Vn,Vn+1),△(Vn,Vn+2)……△(Vn,Vn+m-1)}为两个阶,V0和Vn分别为各个阶内的基版本即阶版本,Vn=V0+△(V0,Vn),各个阶内都以阶版本为参照进行差值运算和存储,Vm为当前的最新版本。该模型在提高空间存储效率的同时也大大提高了系统版本数据的抗风险能力,即使中间某一阶版本信息被丢失,也不同担心差值存储信息的失效,可以通过其他的阶版本恢复还原。
 
  如何最有效的利用融合差值存储模型存储版本数据,还需要研究版本阶的生成条件。阶过小,系统的空间开销就较大;阶过大,则版本的存取速率将受到影响。本文通过以下几种方法来实现对版本阶的设定:
 
  (1)指定阶规模。在系统中事先指定每个阶的规模大小,即每个阶内有多少组差值。比如指定每10组差值为一个阶,则第11个版本信息生成时,系统自动将其完整存储。
 
  (2)指定差值容量。在系统中事先指定每阶最大的差值容量,即该阶的最后一个差值的大小。比如指定10M为差值容量,当某个差值容量大于该数值时,系统自动将其完整存储。
 
  (3)指定版本树深度。在版本差值存储过程中,随着版本树深度的增加,版本差异内容随着增多,版本存取速度受到加大的影响。因此在系统中事先指定版本树深度,当新版本的版本树深度达到指定版本深度时将其完整存储。从版本树纵向和横向综合考虑,给出了存储阀值的计算公式。
 
  (4)关键版本。在设计的反复修改过程中,如果某一次修改较多,对后面产生较大的影响或是后面工作的基础时,可以将其定义为关键版本,进行完整存储。当然这种方法的主观性很重要,受资深和级别高的设计者的影响较大。这种方法可以配合上述方法一起使用。
 
  在融合差值存储模型中可以考虑同时使用上述四种版本阶的设定方法,系统事先计算各阶值,然后进行人为分析比较,选择空间开销小和存取速度快的综合最优阶值。
 
  采用融合差值存储模型进行版本存储具有以下几个优点:
  (1)将最新版本进行完整储存,便于更频繁的访问和修改,提高了时间效率。
  (2)完整存储阶版本,可以方便中间版本信息的获取,提高存取速度。
  (3)阶内版本进行差值存储,较少了数据的冗余,提高了空间利用率。
  (4)如果基础版本或中间某一阶版本被破坏,不会影响其他版本信息的恢复,减少了基版本的风险,提高了系统版本数据的安全性。
 
  总之,该模型在空间效率和时间效率上进行有效的平衡,不仅大大节省数据存储空间,同时版本的安全性和版本的存取速度得到了保证。
 
4.4.4差值存储方式的适用范围
  差值存储也不是可以存储所有的数据或文件,也有其适用范围。对于内容量比较大的文件,如一些多媒体文件,大型的图纸文件等等,做差量的恢复计算都需要占用较大的系统资源,对于这类文件不适合采用差值方式进行存储;对于那些压缩数据和图像数据,这类数据的特点是即使做了很小的改动都会对实际数据产生很大的影响,所以这类数据的存储也不适合采用差值存储方式,对于这类型的文件可以通过技术压缩对其完整版本进行存储。
 
  适合采用差值存储的文件有文档类数据、代码类数据和关键业务性数据等,还可以对文件集来的数据信息进行存储,即单个文件内容不变化,整个文件集的内容变动。对于那些信息差异量小文件版本,采用差值存储比较有效,但当差异较大内容较多时,差值的恢复计算不仅会降低存储和恢复的效率,还可能影响版本的存取速度。因此,我们可以事先要对进行文件差值存储的大小设定一些的规则限制,超过限额的文件建议采用技术压缩进行完整存储。这样既可以提高空间利用率又可以提高版本的存取效率。
 
4.5总结

  本章主要研究的是协同开发中的版本管理,分为两大部分。第一部分是基本的版本管理,由版本的概念引导出版本的结构模型以及版本管理中PDM中的应用;第二部分主要是协同开发中的版本管理,首先介绍了协同开发中版本管理的需求以及特点,然后对协同开发中版本管理的并发控制技术和版本存储技术进行了相关研究。
 
  在版本并发控制中本文提出了“拷贝记录-修改提交-整合提示”新的版本控制机制,能够支持并行协同的工作,提高工作效率;在版本存储模型中,在总结各种版本差值存储的优缺点后,提出了改进的差值存储模型-融合差值存储模型,该模型集各差值存储模型的优点,在节省存储空间的同时,可以提高版本存取速度以及方便快速查阅版本的历史记录。
 

  • 2019-05-29 10:21
  • 我要分享:
声明:文章"PDM支持协同开发的版本管理"为XXX公司原创文章,转载请注明出处,谢谢合作!您所在位置:PLM系统 > PLM新闻 > PDM资讯 >

联系清泰代表

  • 申请支持留下信息,我们将与您联系
  • 400热线马上知道,4006-185-708
热门文章
热门标签

内蒙古快3 博盈彩票计划软件 内蒙古快3 159彩票 159彩票 八马彩票 内蒙古快3走势图 170彩票 166彩票平台 内蒙古快3走势图