本发明涉及软件工程和数据库技术，尤其涉及一种在软件配置和管理中构建软件配置管理时态对象变更模型的方法和系统。
背景技术：
：：变更影响分析是软件配置管理的又一个关键技术。变更影响分析是保证软件质量的重要手段，可以减少软件维护和测试成本，因为只需要对受影响的软件对象(模型、构件或者其他软件对象)进行维护和测试。首先分析各种软件对象变更原因和变更方式，然后分析其导致的影响规律。变更是软件开发过程中的一个重点问题，一个优秀的软件变更影响分析算法对于整个软件系统开发是非常重要的。当前国内外对于软件变更影响分析的相关研究不少，但大多数都是基于源码集的变更影响分析，较少是基于软件体系结构层面的变更影响分析，而对于过程级的软件变更影响分析的相关研究更少。虽然已经有研究人员开始在基于已有的变更影响分析研究成果上，从静态发展到动态，考虑支持版本演化中的变更影响分析，但却仍然没有真正从时态的角度来考虑变更影响分析。我们总结了已有的软件变更影响分析方法，分析对比其优缺点，并且在参考现有的变更影响分析算法成果中，加入了时态性，研究基于图和时态的软件开发过程的变更影响分析方法。首先分析各种软件对象变更原因和变更方式，然后分析其导致的影响规律。软件生命周期对象(softwarelife-cycleobjects,slos)，也叫作软件产品或者软件制品，是软件开发中产生的成果，我们研究基于过程级的变更影响分析，故而所述的生命周期对象是软件开发过程中的抽象实体，它可以是需求或者需求项，也可以是设计、模型或者构件等等。变更影响分析主要包括在同一类实体内部的依赖性分析(如需求依赖性分析)和整个开发周期内多种软件周期对象之间关系的追踪性分析。一个软件变更最终的影响范围由以下两个因素决定:1)软件变更的类型；2)发生变更的实体所处的上下文环境，主要指该实体与其他实体的各种依赖关系。一、变更影响分析研究现状现有技术中有关软件变更影响分析的方法主要有如下三个不同的领域：(1)源代码(sourcecode)可以是静态的(static)、动态的(dynamic)或者在线的(online)。(2)形式模型(formalmodels)进一步分为体系结构(architectural)和需求(requirements)模型，来反映软件开发的早期阶段，也就是需求捕捉(requirementscapturing)和体系结构推理(architecturalreasoning)。(3)各种软件过程产物(miscellaneousartifacts)包括各种文档(documents)和数据来源(datasources)，例如文档(documentation)、缺陷跟踪(bugtrackers)和配置文件(configurationfiles)等。国内外研究现状具体如下：(1)源代码(sourcecode)许多变更影响分析的研究方法都是从继承关系、方法调用行为和其它程序实体间的依赖关系推理出来的。通过分析源码文件、类包、类、方法、声明和变量来预测变更的传播。源码级的变更影响分析方法不适用在软件设计的早期阶段和需求分析。静态的(static)代码分析是从源码中提取信息来构造调用图、切片和其它用来评估一个变更影响的方法。相比之下，动态的(dynamic)和在线的(online)方法通过工具编码或编译二进制文件来收集方法执行信息。这些所谓的执行追踪是在程序执行后的分析(动态的)或者是在执行时(在线的)并发进行变更的评估。代码级的变更影响分析都有如下技术：①调用图(callgraphs)，②依赖性分析(dependencyanalysis)，③程序切片(programslicing)，④执行追踪(executiontraces)，⑤显式规则(explicitrules)，⑥信息检索(informationretrieval)，⑦概率模型(probabilisticmodels)，⑻历史挖掘(historymining)，⑨混合技术(combinedtechnologies)，⑩其它技术(othertechnologies)。(2)体系结构模型(architecturalmodels)例如uml构件图能够在一个比源码更为抽象的层面上评估体系结构的变更，这个能够在开发的早期阶段和在基于模型开发(modelbaseddevelopment，mbd)上进行影响分析的方法在近年来越来越重要。然而即使是允许细粒度结果的体系结构分析都要依赖于底层的建模语言，例如分析复杂的uml类图。典型的粒度包括系统、子系统、构件和类。(3)需求模型(requirementsmodels)正式的需求是软件开发过程中的第一个可用的工件，并且在确定一个程序的最终版本前会经历许多变化。如果需求被形式化建模语言如uml，那么由于需求依附于一个结构良好的元模型，此时可以把它们视为是形式分析的对象。相比之下,如果他们被表示为纯文本,那么就只有文本检索的方法如信息检索(informationretrieval，ir)的方法可用了。(4)各种软件过程产物(miscellaneousartifacts)变更不只是发生在源代码或构件模型上，这已经是一个公认的事实了。文件编制、配置文件、故障追踪器和类似的软件辅助内容也是频繁变更的对象了。然而，变更这样的实体(例如当一个配置文件变更了)也可能影响软件，在这样的实体(主要是不同类型的文件)中执行影响分析,也因此成为研究社群的一个问题。(5)混合领域(combinedscopes)典型的软件开发过程是由不同的阶段组成的,即从需求分析和体系结构推理开始，然后逐步进行实现。当变更软件时,不限制它们对某种工件的影响，那么变更一个需求可以影响不同的体系结构模型,以及已经实现的源码构件。因此，综合分析是在所有可用的工件中进行追踪影响所必须的手段。然而，这需要能够处理可能涉及的各种类型的工件的复杂概念。二、时态对象实体概念和依赖关系建模软件需求、设计、模型、构件、参数和软件产品等软件开发要素及其之间的复杂联系，建立集成统一的数据模型，是软件开发支撑平台的基础，也是核心工作。图1显示了现有技术中集成统一数据模型的软件开发平台框架示意图。但是以上存在不能将时态技术应用到软件开发平台中的弊端。本发明提出从时间维度出发，综合利用时态图技术和时态数据库技术，研究软件开发诸要素及其复杂联系的时态建模方法，设计集成统一的时态数据模型和存储模型，该模型包括软件需求(requirement)库、设计(design)库、模型(model)库、构件(component)库、参数(parameter)库、软件产品(softwareproduct)库和时态实体联系数据图(temporalentity-relationshipdatagraph)；在此基础上，研究时态数据维护、检索和分析技术，可以为新的软件开发支撑平台开发提供基础性的支持。图2显示以时态实体联系数据图为核心的集成统一数据模型，这是本发明思想的基础。软件需求、设计、模型、构件、参数和软件产品等实体对象都具有不同的版本，每个版本具有相应的发布时间、使用时间和停用时间。具有时态属性，并且其状态随时间变化的实体，称为时态实体。图3描述了a实体(例如构件)和b实体(例如软件)的4种版本时态联系，其中at0,at1,at2,at3,at4,at5….由虚箭头线相连随时间发展演化成a实体的各个版本对象，b实体也有类似随时间演化的版本序列，每个时刻版本对象上的时态标签为该对象的有效时间“[发布时间,停用时间)”,边上的标签表示两个版本对象建立联系的有效时间“[开始时间，结束时间)”；图3表示at0版本“使用”bt0版本；图3表示a实体由at1版本升级为at2版本，bt1版本不变；图3表示at3版本不变，bt3版本升级为bt4版本；图3表示at3升级为at5版本，bt4版本升级为bt5版本。上述a和b两类时态实体之间的四种时态联系，实际上为两类时态联系：a版本变化，b版本同步变化；a版本变化，b版本不变化。图3表明，软件开发中的软件需求、设计、模型、构件、参数和软件等时态实体本身不仅存在随时间演化的版本联系，时态实体之间存在复杂的时态联系。因此，结合时态扩展实体联系e-r模型和时态图(temporalgraph)模型，研究软件开发要素的时态建模方法，构建软件开发要素的概念模型，构建时态实体联系图，可以描述上述六类实体之间的动态时态联系。依赖关系，是软件实体间最主要的一种关系，尤其是在软件开发过程中，软件实体类之间的依赖关系以及实体类内部之间的依赖关系，对软件的变更影响分析以及风险分析等都具有非常大的影响。然而，目前对于依赖关系的研究工作大多集中于代码级的研究。软件开发过程中，一共有六个主要的实体，即需求、设计、模型、构件、软件以及支持数据，这六个实体间存在大量的依赖关系，同样的，实体内部也包含多种依赖关系。在软件系统中，某一部分发生变更之后，其代码的变更可能会发生在许多不同的模块中，甚至于，波及到整个系统，这就是变更的连锁反应(chainreaction)，而这种连锁反应就是由实体间的依赖关系引起的。当某一个实体发生变更或失效时，实体间的依赖关系可能会导致与其有所关联的实体都发生变化，甚至于是失效，因而，软件实体间的依赖关系也成为了软件实体的变更影响分析以及失效风险分析的基础。如何将软件实体依赖关系分析并且表现出来，对于软件的其他分析有很大的帮助。本发明提出的基于时态的对象变更模型的建模方法即基于以上时态建模和依赖关系的思想。技术实现要素：本研究针对于软件开发过程中需求、设计、模型、构件、软件和支持数据等六类实体之间的过程级依赖关系进行研究，并且提出了一种软件实体依赖性分析方法。本发明请求保护一种一种基于时态的对象变更模型的建模方法，其特征在于包括：步骤1，根据时态实体以及时态实体之间的联系，建立数据库模式；其中时态实体包括软件开发要素中的以下至少一种：软件需求、设计、模型、构件、软件产品、开发单位、开发人员；时态实体具有时态属性，该时态属性包括时态实体的版本信息和/或有效时间信息；时态实体联系包括时态实体内部的依赖关系或时态实体之间的依赖关系；其中该时态实体还包括变更；其中建立数据库模式包括将时态实体和时态实体联系在数据库环境中以包括表table、视图view、存储过程的方式来创建，其中建立专门的联系表relationtable来表达时态实体的内部联系和时态实体之间的外部联系，其中表、视图中还包括时态属性字段来表达时态实体的以上时态属性；步骤2，构建多层时态依赖图mtdg(multilayertemporaldependencygraph)，包括：定义每种时态实体分别对应多层时态依赖图中的一层layer，定义每种时态实体的一个具体对象为该层layer中的一个结点e，定义层内的结点与结点之间的有向边为内部依赖(即内部联系)，定义层间的结点与结点之间的有向边为外部依赖(即外部联系)；定义由以上所有结点和有向边构成的图为多层时态依赖图；输入以上数据库模式，获取其中包括表、视图、存储过程的所有数据库模式ds(databaseschema)；初始化多层时态依赖图的层数mtdg.layercnt为0；开始非空循环，条件为“数据库模式不为空”；如果获得的数据库模式是一个时态实体；多层时态依赖图的层数mtdg.layercnt加1；生成当前层的时态依赖图中的结点；否则，如果获得的数据库模式是一个内部联系；生成层内依赖关系，其包括生成层内结点之间的有向边；否则，如果获得的数据库模式是一个外部联系；生成层间依赖关系，即外部依赖关系，其包括生成层间结点之间的有向边；结束非空循环，条件为“数据库模式不为空”；输出多层时态依赖图mtdg；其中，输出的多层时态依赖图中包括变更层，并且还包括以下至少一层：软件需求层、设计层、模型层、构件层、软件产品层、开发单位层、开发人员层。本发明请求保护一种一种基于时态的对象变更模型的建模系统，包括：数据库模式构建模块，根据时态实体以及时态实体之间的联系，建立数据库模式；其中时态实体包括软件开发要素中的以下至少一种：软件需求、设计、模型、构件、软件产品、开发单位、开发人员；时态实体具有时态属性，该时态属性包括时态实体的版本信息和/或有效时间信息；时态实体联系包括时态实体内部的依赖关系或时态实体之间的依赖关系；其中该时态实体还包括变更；其中建立数据库模式包括将时态实体和时态实体联系在数据库环境中以包括表table、视图view、存储过程的方式来创建，其中建立专门的联系表relationtable来表达时态实体的内部联系和时态实体之间的外部联系，其中表、视图中还包括时态属性字段来表达时态实体的以上时态属性；构建包含变更层的依赖图构建模块，构建多层时态依赖图mtdg(multilayertemporaldependencygraph)，包括：定义每种时态实体分别对应多层时态依赖图中的一层layer，定义每种时态实体的一个具体对象为该层layer中的一个结点e，定义层内的结点与结点之间的有向边为内部依赖(即内部联系)，定义层间的结点与结点之间的有向边为外部依赖(即外部联系)；定义由以上所有结点和有向边构成的图为多层时态依赖图；输入以上数据库模式，获取其中包括表、视图、存储过程的所有数据库模式ds(databaseschema)；初始化多层时态依赖图的层数mtdg.layercnt为0；开始非空循环，条件为“数据库模式不为空”；如果获得的数据库模式是一个时态实体；多层时态依赖图的层数mtdg.layercnt加1；生成当前层的时态依赖图中的结点；否则，如果获得的数据库模式是一个内部联系；生成层内依赖关系，其包括生成层内结点之间的有向边；否则，如果获得的数据库模式是一个外部联系；生成层间依赖关系，即外部依赖关系，其包括生成层间结点之间的有向边；结束非空循环，条件为“数据库模式不为空”；输出多层时态依赖图mtdg；其中，输出的多层时态依赖图中包括变更层，并且还包括以下至少一层：软件需求层、设计层、模型层、构件层、软件产品层、开发单位层、开发人员层。本发明获得的有益技术效果：可以自动化地帮助软件研发人员了解软件开发中的各种依赖关系，有助于在软件部分发生变更(例如版本变更、人员变更)是发现其中的依赖关系，提高软件维护效能。附图说明图1是现有技术一个基于集成统一数据模型的软件开发平台框架示意图。图2是本发明一个以时态实体联系数据图为核心的集成统一数据模型。图3是本发明一个两类软件开发要素实体a和b的4种版本时态联系图。图4是本发明一个总体时态概念结构图(时态ter图)。图5是本发明一个以需求为核心的分时态ter图。图6是本发明一个需求内部之间的分时态ter图。图7是本发明一个以设计为核心的分时态ter图。图8是本发明一个设计内部之间的分时态ter图。图9是本发明一个以模型为核心的分时态ter图。图10是本发明一个模型内部之间的分时态ter图。图11是本发明一个以构件为核心的分时态ter图。图12是本发明一个构件内部联系的分时态ter图。图13是本发明一个以软件为核心的分时态ter图。图14是本发明一个以支持数据为核心的分时态ter图。图15是本发明一个以项目为中心的分时态ter图。图16是本发明一个以配置为核心的分时态ter图。图17是本发明一个版本树示例。图18是本发明一个简单的构件依赖图。图19是本发明一个实体依赖树。图20是本发明一个多层依赖图示例。图中实线为层内依赖关系，虚线为层间依赖关系。任意两层间都可以有依赖关系。图21是本发明一个传入耦合示例图。图22是本发明一个传出耦合示例图。图23是本发明一个实体距离计算。图24是本发明一个实体依赖图示例。图25是本发明一个正向实体依赖分析结果。图26是本发明一个逆向实体依赖分析结果。图27是本发明一个双向实体依赖分析结果。图28是本发明一个推导出开发人员只见依赖关系示意图。图29是本发明一个开发人员d7依赖于d4推导关系示意图。图30是本发明一个增加了变更层的多层时态依赖图示例。具体实施方式一、本发明的实现环境本发明的实现可以采用例如下列工具和环境，但是仅仅是可选的工具和环境之一，并不用于限定本发明的保护范围。□数据库采用oracle11gexpress数据库。□数据库中间件采用hibernate。□开发语言采用java。□web开发框架采用wicket和html。□开发工具采用开源的开发工具eclipse。□图形标准和显示采用svg和d3.js。二、时态实体概念结构设计及其时态实体关系图本发明基于时态建模方法，结合关系数据库技术和时态数据库技术，构建包括软件需求、设计、模型、构件、支持数据和软件产品等软件开发要素实体及其联系的概念模型。如图4所示的总体时态概念结构图(时态ter图)，体现了软件需求、设计、模型、构件、支持数据、软件产品、开发单位、开发人员、项目等时态实体之间的联系关系(依赖)。下表1.1是对图4中时态e-r图中符号的说明。表1.1时态ter图的符号说明说明：(1)总的时态e-r图只是反映出最主要的实体之间的联系，此处略去了某些辅助实体之间的联系。(2)实体内部之间的联系可以根据需要将在分e-r图中画出(此处省略)，例如需求实体内部的联系(依赖关系)分为父子层次联系、引用联系、复用联系等。(3)实体的属性需要设定时变属性。2.1以需求为核心的概念结构设计及其分时态实体联系图ter图5是以需求为核心的分时态ter图。其表达了以需求为核心时的积累需求之间的关系以及与其它软件开发要素之间的关系。原始需求、使用需求、系统需求、软件需求，实际上为各种需求项(requirementitems)。各类需求项内部之间具有层次结构、复用和参照等各种联系，为了e-r图简洁，上述各种联系在上图中没有画出。图6表达了需求内部之间的分时态ter图。与软件需求一样，系统需求、使用需求和原始需求也有类似的联系。2.2以设计为核心的概念结构设计及其分时态实体联系图ter图7是以设计为核心的时态ter图。图中显示了以设计为核心时，设计与其它软件开发要素之间各种联系。在图中，设计，实际上为各种设计项(designitems)。设计项内部之间具有层次结构、复用和参照等各种联系，为了e-r图简洁，上述各种联系在上图中没有画出。图8是设计内部之间的分时态ter图，其中可见设计内部的关系主要是父子关系和依赖关系。2.3以模型为核心的概念结构设计及其分时态实体联系图ter图9是以模型为核心的分时态ter图。图中给出了以模型为核心时，其与其它软件开发要素之间的联系。图中各类型模型之间具有复用和参照等各种联系，为了e-r图简洁，上述各种联系在上图中没有画出。图10是模型内部之间的分时态ter图。图中可见模型内部之间的关系主要是父子关系和依赖关系。2.4以构件为核心的概念结构设计及其分时态实体联系图ter图11是以构件为核心的分时态ter图。图中显示了构件与其它软件开发要素之间的关系。各类构件之间具有复用、引用和组合等各种联系，为了e-r图简洁，上述各种联系在上图中没有画出。构件在具体开发上，可能是一个构件选定一种构件模型，并实现一种构件实现代码，因此，构件模型和实现代码，只是构件分类的两个重要属性，在逻辑设计时，也许并不需要把他们作为实体对待。图12是构件内部联系的分时态ter图。可见在构件内部中主要包括父子关系和依赖关系。2.5以软件产品为核心的概念结构设计及其分时态实体联系图ter图13是以软件为核心的分时态ter图。图中显示了以软件为核心时，该时态实体与其它时态实体之间的关系。2.6以支持数据为核心的概念结构设计及其分时态实体联系图ter图14以支持数据为核心的分时态ter图。图中显示了以支持数据为核心时，该时态实体与其它时态实体之间的关系。(1)设计与构件相关，不与构件实现直接相关；(2)支持数据全集，实际上因为只有一个，不用具体存储。2.7以项目为核心的概念结构设计及其分时态实体联系图ter图15是以项目为中心的分时态ter图。图中显示了以项目为核心时，该时态实体与其它时态实体之间的关系。在该图中产品分解结构粒度细化到哪个层次、工作分解结构粒度细化到哪个层次、产品分解结构、工作分解结构和设计等其他实体之间的联系如何，则取决于具体的软件项目。2.8以配置项为核心的概念结构设计及其分时态实体联系图ter图16是以配置为核心的分时态ter图。图中显示了以配置为核心时，该时态实体与其它时态实体之间的关系。三、构建时态实体及其联系的逻辑模型本部分基于以上时态实体、依赖关系的发明构思，设计相应的关系数据库逻辑模型，包括软件需求、设计、模型、构件、支持数据和软件产品等软件开发要素实体及其之间联系的逻辑模型，特别是时态实体之间的时态联系逻辑模型，也包括相应的时态完整性约束。概念结构设计识别出时态实体、时态属性和时态联系，并建立了时态实体联系图ter图。数据库逻辑模型(即数据库模式)：由时态实体和时态实体联系两部分组成,而每个时态实体有两部分组成：一部分为记录非时态属性的实体基本表table，另一部分为记录时态版本属性的实体版本信息表table。在软件工程中每个以上时态实体的版本形成一棵多分枝的版本树，分枝又能合并，因此版本树是一个有向无环图(dag)。图17显示了这样一颗版本树示例。对于某个实体的版本树，可以根据该实体的版本及其记录的先序版本，逐步倒推出该版本相关的版本树。可以将时态实体和时态实体联系在例如oracle数据库环境中创建，其中建立数据库模式包括将时态实体和时态实体联系在数据库环境中以包括表table、视图view、存储过程的方式来创建，其中建立专门的联系表relationtable来表达时态实体的内部联系和时态实体之间的外部联系，其中表、视图中还包括时态属性字段来表达时态实体的以上时态属性；以下数据库模式表table、视图view中，涉及“实体内部的联系及其属性”、“实体外部的联系及其属性”的，体现了时态实体的内部联系和外部联系，更重要的是体现了时态实体的内部依赖和外部依赖。以下数据库模式表table、视图view中的时间属性，或者代表了该时态实体的有效时间，或者代表该时态与其它时态实体之间联系(依赖)的有效时间validtime；以下数据库模式表table、视图view中，涉及“变更”的表table、视图view、字段field则可用于以上时态实体变更分析。四、依赖基本概念(1)依赖(dependency)基本定义从变更影响的角度出发，依赖是指元素间存在的一种特定的语义连接和动态关联关系，当某个元素发生变更时，与之有依赖关系的另一个元素也会发生相应的变更，从而保证软件系统演化的完整性和一致性。下面给出实体及其依赖关系的相关定义。定义2.1实体型(entitytype,et):实体型et定义为(ua，doma，f,ub),ua为et的m个属性集合{a1,a2,…,am}，doma为取值范围集合{dom1,dom2,…domn},f为ua到doma的映射，即ai对应的取值范围为domi,ub为et的n个行为集合{b1,b2,…,bn}；et定义可以简写为(ua，ub)；实体(entity)e是实体型et的实例(instance)，et也是e的集合。定义2.2时态实体型(temporalentitytype,tet):时态实体型tet定义为(ua，doma，f，ub，vt)，简写为(et，vt)或者(ua，ub，vt),即在有效时间vt(validtime)内有效的et,而vt为有效开始时间(validstarttime)ts和有效结束时间(validendtime)te组成的右半开时间区间[ts,te)的集合。时态实体et是实体型tet的实例(instance)，tet也是et的集合。定义2.3依赖(dependency)：依赖关系d：e1×dt×e2，定义为两个实体型e1和e2，以及依赖类型(dependencytype,dt)上的三元组；给定任意两个实体ei和ej，依赖类型dtk，如果ej的属性ai或者行为bi发生变更后，也会导致ei的属性aj或者行为bj发生变更，则称ei依赖ej于dtk，记为：d＝{<ei，dtk,ej>|ei∈e∧ej∈e∧dt∈dt∧dtk＝f(ai|bi,aj|bj)}，其中f(ai|bi,aj|bj)表示dtk跟ai(或bi)和aj(或bj)有关，即一个实体的不同属性或者行为，与另外一个实体的不同属性或行为之间可能存在着不同类型的依赖。当e1与e2相同时，dtk为实体型内部的依赖关系；当e1和e2不同时，dtk为实体型之间的依赖关系。定义2.4时态依赖(temporaldependency)：时态依赖dt：d×vt，即在有效时间vt内存在的依赖关系d，在有效时间实体ei依赖ej于dtk,记为dt＝{<ej，dtk,ei，[ts,te)>}|ei∈e1∧ej∈e2∧[ts,te)∈vt∧dtk∈dt∧dtk＝f(ai|bi,aj|bj)}。假设依赖dtk不随时间变化。(2)依赖的性质不同实体之间的依赖关系是反自反的、不对称的、传递的，证明如下：■反自反性依赖是基于不同实体之间关系为前提，也就是说，依赖指代的是两个或多个不同实体之间一个或多个实体的变化对于其他实体的影响，实体本身的变化不能够称作依赖，因此，依赖关系是反自反的。■不对称性采用反证法来证明。假设a与b是两个实体，且a依赖于b，b依赖于a。根据依赖关系的定义，当a变化时，b也发生变化；同理，b发生变化时，a也发生变化。则当a发生变化时，会引起a本身变化，这与依赖关系是反自反的相矛盾。所以，不同实体之间的依赖关系是不对称的。■传递性假设a、b、c是三个不同的实体，且a依赖于b，b依赖于c，则根据依赖关系定义，c的变化会引起b的变化，b的变化会引起a的变化，即c的变化引起了a的变化，也就是说a依赖于c，所以说实体之间的依赖关系是传递的。(3)依赖关系的分类实体具有属性(attribute)和行为(behavior)，属性所引起的依赖通常称为属性依赖(attributedependency,ad)，行为引起的依赖称为行为依赖(behaviordependency，bd)。从面向对象程序的角度来看，实体对应为对象，对象具有属性和方法，对象属性引起的依赖通常成为数据依赖(datadependency,dd)，而对象方法引起的依赖通常称为方法依赖(methoddependency,md)。定义2.5属性依赖(attributedependency)若一个实体ei的属性ai引用ej的属性aj，或者是ei的行为bi引用ej的属性aj，即当ej的属性aj变更将引起ei的属性ai或者行为bi变更，称ei依赖ej于ad,记为ad＝{<ei,ad,ej>|ei∈e1∧ej∈e2∧ad∈dt∧ad＝f(ai|bi,aj)}。属性依赖属于静态依赖。实体存在着各种各样的行为，实体行为之间也存在依赖关系。实体行为的复杂性使得实体行为之间的依赖关系比属性依赖更为复杂。行为依赖属于动态依赖。定义2.6行为依赖(behaviordependency)若一个实体ej的行为bj变更将引起ei的行为bi变更，称ei依赖ej于bd,记为bd＝{<ei,bd,ej>|ei∈e1∧ej∈e2∧bd∈dt∧bd＝f(bi,bj)}。除了属性依赖(数据依赖)与行为依赖(方法依赖)之外，还有一些依赖关系的定义。实际上，依赖关系可以从不同的角度来分类，详情如下：■从依赖的作用分为结构依赖、行为依赖和可跟踪性依赖(参见表2.1)。表2.1常用的实体间依赖关系■从依赖的社会性分：技术性依赖、技术社会性依赖、社会性依赖(仅与人有关的依赖)■从依赖的来源分：直接依赖、间接依赖、导出依赖(根据依赖的传递特性从直接依赖和间接依赖推导出来的)。五、依赖性分析自从提出依赖性分析以来，依赖性分析技术的研究、发展和应用已经经历了40多年，取得了一系列的理论成果和开展了部分实际应用。(1)依赖性分析定义从程序级别上讲，依赖性分析是一种分析、理解和维护程序的重要手段，它反映了程序中语句、模块之间的执行顺序和相互调用关系。从实体级别上来讲，依赖性分析是一种分析、理解和维护实体及其联系的重要手段，它反映了实体之间互相影响的关系和影响的程度。一般来说，人们采用两种方法进行依赖性分析：一种是沿着被依赖的方向由前(源头)至后(目的)的正向分析方法，例如，从需求到设计到构件到软件的分析方向，也称跟踪性分析。另一种是沿着依赖的方向由后(目的)至前(源头)的逆向分析，例如，从软件到构件到设计到需求的分析方向，也称溯源分析。六、实体依赖关系通常，实体间的关系可以细分为：关联关系、聚合关系、组合关系、泛化关系、依赖关系。关联关系、聚合关系、组合关系、泛化关系与依赖关系都是实体间的关系，但是它们具有的部分属性满足依赖关系，因而可以称为弱依赖关系。在依赖性分析过程中，可以作为依赖关系考虑。(1)实体间关系定义■关联关系：描述了给定实体之间语义的连接描述，提供了不同实体间可以相互作用的连接。■聚合关系：聚合关系是关联关系的一种特殊形式，表示实体与实体间的“整体-部分”关系。聚合关系可以细分为一般聚合关系和共享聚合关系。■组合关系：组合是聚合的一种特殊情况。在组合中，成员对象的生命周期取决于聚合的生命周期。■泛化关系：泛化关系描述了父类和子类在分类学上的关系。■依赖关系：依赖关系描述是两个实体之间的语义上的连接关系，一个实体是独立的，另一个实体是非独立的，它依赖于独立的实体，如果独立的实体发生改变，将会影响依赖该实体的实体。(2)软件开发实体间依赖关系软件开发过程中需求、设计、模型、构件、软件和支持数据等实体之间存在着许多的操作以及构成关系，实体之间存在着层次变化，因而实体之间存在依赖关系；而实体内部也会随着时间以及版本的变化存在大量的变更状况，因而实体内部也存在依赖关系。■实体之间的依赖关系√需求和设计、设计和模型、设计和构件存在跟踪性依赖(traceabilitydependency)；√构件与软件之间存在结构依赖(如组成依赖)：软件是由多个构件经过多种组合方式形成的；√支持数据与模型、支持数据与构件存在数据依赖；■实体内部依赖关系√需求内部:不同需求之间结构依赖(包括内容依赖、引用依赖、复用依赖、同步依赖等等)；原始需求和使用需求、使用需求和系统需求、系统需求和软件需求之间的跟踪性依赖；需求不同版本之间存在版本依赖。√设计内部：存在结构依赖、版本依赖。√模型内部：概念模型、数学模型和工程模型之间存在跟踪性依赖；模型之间存在结构依赖、版本依赖。√构件内部：构件之间存在结构依赖(如同步依赖、互斥依赖、组合依赖、包含依赖等等)：构件的方法之间存在行为依赖，构件之间还可能存在数据依赖和版本依赖。√软件内部：与构件类似，软件之间存在结构依赖、行为依赖、数据依赖和版本依赖。七、针对软件实体的依赖性分析以构件作为实例。直至目前,没有一个关于构件的统一规范定义。但综合分析已有的几种典型定义,不难发现构件具备以下基本特征:构件是近乎独立的、可替换的、满足一定功能的模块；对所处的环境或上下文有一定的依赖关系；构件通常符合一组接口标准,构件之间通过接口进行通讯。构件软件是多个构件(可以是异质的)通过连接件进行组装而形成的系统,是一种松耦合结构。研究者在对构件软件进行体系结构分析、测试或可靠性评估过程中,利用多种方式对构件软件系统进行了建模表示。例如,wu等人用构件交互图cig(componentinteractiongraph)描述构件间的交互场景；还有依赖矩阵、构件迁移概率图等表示方式。但最被普遍认同和广泛使用的还是构件依赖图cdg(componentdependencygraph)模型。构件依赖图定义如下：定义2.7构件依赖图(componentdependencygraph)构件软件可用一个四元组形式的依赖图cdg＝(v,e,vs,vt)表示,其中v为表示构件的顶点集,e是表示连接件的边集,vs和vt分别表示起始、终止结点。构件顶点集v和连接件边集e可进一步定义如下:v＝{〈vi,cpxi〉}(1≤i≤|v|),其中vi为第i个构件的标识符,cpxi为构件vi的复杂性。e＝{〈eij,pij〉}(1≤i,j≤|v|),其中eij为由构件vi连接到构件vj的连接件的标识符,pij为连接件eij被执行的概率。图18显示了一个简单的构件依赖关系图。其中从起始点s开始，到终止结点t，<es1,1>表示构件s到构件v1的连接件标识符为es1，其es1被执行的概率为1；<v1,0.4>表示构件v1的构件复杂性为0.4。其中，构件复杂性是指构件的复杂程度的度量。对于代码可见的情形,可以认为程序控制流图的圈复杂性、代码行数以及包含的库文件数目均会对构件的复杂性产生影响。对于构件ci,其复杂性的3个分量(圈复杂性cci、行复杂性lci和库包含复杂性libi)，参考文献中有公式可以计算。其中程序控制流图的圈复杂性，是用来衡量一个程序模块所包含的判定结构的复杂程度，数量上表现为独立路径的条数，即合理地预防错误所需测试的最少路径条数对于代码不可见的外部构件,构件开发者一般运用xml等标准、易于交换的文件格式提供构件的梗概信息(元数据),典型的有代码总行数、方法数目及方法间的调用关系等。构件使用者可以利用这些信息对构件的复杂性进行粗略的估计。八、基于时态图，建模软件配置管理对象之间的依赖关系本发明提出软件配置管理对象之间的依赖关系可以建模成一个时态有向图，其中实体对应时态图的结点，依赖关系对应时态图的边；在该图中，不仅要考虑结点的时态性，也要考虑边的时态性。设计基于关系数据库存储的时态数据生成时态图的算法，以及相应的时态图的更新维护方法。8.1依赖图建模为了方便理解，人们一般用图的形式来表示各种依赖关系，并提出许多依赖图的模型，主要由程序依赖图pdg、系统依赖图sdg、对象依赖图odg和类依赖图cdg等，也可以使用图形化的方法表示实体间的各种依赖关系。除了常用的一些依赖图之外，还可以通过依赖观察矩阵、依赖树等一些方法对实体、程序、函数等之间的依赖关系进行展示和描述。(1)有向依赖图实体间的依赖关系可以使用有向依赖图来表示。有向依赖图的定义如下。定义2.7有向依赖图(directeddependencygraph)设有向依赖图dg＝(v，e)中，v为结点vi的集合，记为v＝{vi}，其中，节点vi表示实体ei，i＝1，2，…，n。e为结点间有向边〈vi，vj〉的集合，其中，序偶〈vi，vj〉表示结点vi依赖于结点vj，1≤i≤n，1≤j≤n。简单地说，就是一个有向依赖图主要由两种元素的集合来表达，即有向依赖图的结点以及结点间的有向边。在实体的有向依赖图中，一个结点就表示一个实体，而结点间的有向边则是由一对序偶<vi，vj>来表示，其中vi与vj表示的都是有向依赖图中的结点，<vi，vj>表示结点vi依赖于结点vj。对于实体间的依赖关系，通常是指实体间的调用关系(或者是包含关系)，用实体间的依赖边表示，从代表调用实体(或起始实体)的节点指向代表被调用实体(或终结实体)的节点。(2)多粒度依赖关系图定义2.8多粒度依赖图(multi-granulardependencygraph)对于给定依赖图g＝<v,e,dt>，结点既可以是实体(entity)，也可以是实体属性(attribute)，也可以是实体的行为(behavior),则v＝ve∪va∪vb，e＝v×dt×v，其中dt表示依赖类型集合。例如，对于给定一个基于java的面向对象软件p，多粒度有向图g的结点可以分别是类、成员函数和成员变量，而dt＝{inheritance,membership,call,use}，在类粒度上使用类-成员关系图为面向对象软件建模，在方法粒度上使用控制调用图为成员函数建模。更具体地，e＝v×dt×v表示为三个集合的笛卡尔积，其结果也是一个集合，该集合中每个元素是一个三元组(vi,dt,vj)，其中第一个分量vi来自v×dt×v的第一个集合v，第二个分量dt来自v×dt×v的第二个集合dt，第三个分量vj来自v×dt×v的第三个集合v。(vi,dt,vj)实际上就是一条边的表示方法，其vi是边的起点，vj是边的终点，dt表示边的类型。所以，e＝v×dt×v表示e是一个边的集合，每条边是一个三元组。实际上，e应该是v×dt×v的子集，而不等于v×dt×v。所以更准确的表示是：(3)依赖矩阵当考虑实体间的依赖时，也可以建立一个矩阵模型来体现实体间的依赖关系。具体的依赖观察矩阵定义如下：定义2.9依赖矩阵(dependencymatrix)矩阵m＝n×n，其中n表示n个实体的集合，矩阵元素依赖对<e1,dt,e2>表示实体e1依赖e2于dt(dt为依赖类型)，其中依赖对的为数据依赖关系则为数据依赖观察矩阵，为控制依赖关系则为控制依赖观察矩阵。例如软件开发过程中，存在需求依赖矩阵，需求设计依赖矩阵等等。(4)实体依赖树除了经常使用的依赖图和依赖观察矩阵之外，还可以使用依赖树来表示实体间的依赖关系，而依赖树一般是由依赖图转化而来的。定义2.10实体依赖树(entitydependencytree)对于依赖图dg＝(v,e),从给定结点vs出发，到终止结点vt，转化成一棵生成树：依赖图树dgt＝(vt,et，vrt),其中vt为表示实体的结点集,vrt为根结点，et为表示实体依赖的有向边集。由于依赖图中不可能存在依赖循环子图，因此，从一个给定点出发，一定能生成一棵生成树。由依赖图向依赖树的转化方法如下：第1步,给定结点vs作为根结点vrt，同时记根节点为当前结点。第2步,对任一当前结点,广度优先搜索dg,将当前节点每一条出向边作为dgt中对应结点的一条边,该边目标结点作为当前结点的儿子结点。当满足如下两个条件之一时，dgt中的结点终止扩展：(1)若当前结点是终止结点vt；(2)若当前节点(设它处于dgt的第i(i>1)层)在dgt的1至i-1层出现过。第3步,迭代进行第2步的遍历,直到所有节点都不能扩展为止。一个简单的依赖树如图19所示。其中给出了经过以上算法，起点s依赖于结点c1，结点c1有分别依赖于结点c2、结点c3，结点c2、结点c3同时依赖于结点c4，结点c4依赖与结点t，到达终点。由此生成了一个实体依赖图树。由以上定义来看，有向依赖图、多粒度依赖图是目前用得较多的依赖模型，而依赖矩阵可以用来作为依赖关系的输入模型，而依赖树可以作为依赖关系的输出模型。(5)多层依赖图模型在深入研究依赖关系各种建模方法的基础上，提出了多层依赖图模型。定义2.11多层依赖图(multilayerdependencygraph)每一层li定义为一个多粒度依赖图li＝gi＝(vi,ei,dti)，该层只有相同类型的实体及其属性和行为构成，对于每个结点vi都有一个属性记录其所在层号。多层依赖图mdg＝(l,el,dtl),其中l为每一层多粒度依赖图集合gi，el为层间依赖关系<vi,dtl,vj>的集合，每个依赖关系由vi和vj来自不同的层，vi∈vi,vj∈vj,dtl∈dtl。从上述定义可以看出，一方面，mdg可以看作是关于图的图(graphofgraph),是由各层的有向依赖图构成的图；另一方面，其实质仍然是一个有向多粒度图，等价于g＝(∪i＝1nvi,∪i＝1nei∪el，∪i＝1ndti∪dtl)。更具体地，在物理上，多层依赖图mdg，实际上等价于一个多粒度图g，其顶点集合v等于各层多粒度依赖图的顶点集合vi的并集∪i＝1nvi，边集合e等于各层多粒度依赖图的边集合ei的并集∪i＝1nei(其中u表示集合的并运算符，其下标i＝1和上标n表示从1到n的n个集合的并)，再并上层间边的集合el，其边的类型集合等于各个多粒度依赖图的边的类型集合dti的并集∪i＝1ndti，再并上层间边集合的类型dtl(6)多层时态依赖图模型首先回顾单层依赖图的(实际上是一个图)的定义：根据定义2.8定义多粒度时态依赖图g＝<v,e,dt>，即定点集合v是普通结点和时态结点的结合，边e是普通边和时态边的集合，为了统一表示，普通结点和普通边的有效时间记为其创建时间开始至正无穷(+∞)，其结点为vi表示为(vi,vt)，其中vt为其有效时间，边ei表示为(vi,dt,vj,vt),即从vi到vj的边，边类型为dt,有效时间为v。然后定义多层时态依赖图。定义2.12多层时态依赖图(multilayertemporaldependencygraph)每一层li定义为一个多粒度依赖图li＝gi＝(vi,ei,dti)，若vi为时态实体集合，ei为时态依赖集合，则称li为多粒度时态依赖图；若多层依赖图mdg＝(l,el,dtl),若l为多粒度时态依赖图，el为层间时态依赖关系<vi,dtl,vj，vt>的集合，其中vt为有效时间，则称mdg为多层时态依赖图。根据以上定义2.12，多层时态依赖图的相关数据结构可以如下：数据结构为：图20给出了一个多层依赖图示例。图中实线为层内依赖关系，虚线为层间依赖关系。任意两层间都可以有依赖关系。图20中的多层依赖图包括需求层、设计层、开发人员层、开发单位层共4个层l。其中需求层和设计层又构成了技术层；开发人员层和开发单位层又构成了社会层。设计层中有结点s1、s2、s3、s4、其中设计层内依赖关系包括s1依赖于s2、s2依赖于s4、s4依赖于s3；设计层与开发人员层的层间依赖关系包括s2依赖d4、s4和s3均依赖d3。更多示例性的层内依赖关系、层间依赖关系可从图20中看出。在图20的示例中，这些层内依赖关系、层间依赖关系可以直观地看出来，在数据库中，这些依赖关系则存储或“隐藏”在一张张table中，需要本发明的解决方案将其“挖掘”出来。针对软件开发过程管理，以需求、设计、模型、构件、软件和支持数据为例，可以分为六层，实际上还要考虑到变更、项目、开发人员、开发机构等实体，则分层更多。分层的主要好处是，在逻辑上让可以更清楚地理解复杂依赖图的结构。图20是软件开发过程管理的部分分层时态依赖图示例。下面介绍多层时态依赖图的生成算法(如算法2.1)。算法2.1:多层时态依赖图生成算法mtdgga(multilayertemporaldependencygraphgenerationalgorithm)算法2.1结合第三节的逻辑模型(也就是数据库设计中的数据库模式databaseshema，包括表table、视图view等)，进一步说明如下：input为数据库中的所有数据模式，包括第三节中的所有表table、视图view。以上所有表table分为实体table、实体之间的联系table、实体内部的联系table三类。output为多层时态依赖图，其数据结构参见定义2.12下的相关数据结构。算法2.1中的如下步骤(后续简称算法2.1步骤3－8)：是对数据库中的所有时态实体及其内部联系、外部联系的挖掘并建立多层时态依赖图的过程。其中的各个实体、关系均对应第三节中的逻辑模型。举例来说，根据第三节在数据库中建立的逻辑模型，该逻辑模型至少包括以下将建立为多层时态依赖图中的“层”，每“层”又至少包括如下实体、内部联系、以及层间联系。第一层为需求层：实体例如为：需求关系requirements，需求版本关系reqver_vt层内联系为：需求层次依赖联系reqhierarchy层内联系为：需求版本依赖联系：reqverdependency第二层为设计层：实体例如为：设计关系design，设计版本关系desver_vt层内联系为：设计层次联系deshierarchy层内联系为：设计版本依赖联系desverdependency第三层为模型层：实体例如为：模型关系model,模型版本关系modver_vt层内联系为：模型层次联系modhierarchy层内联系为：模型版本依赖联系modverdependency第四层为构件层：实体例如为：构件关系component,构件版本关系comver_vt层内联系为：构件层次联系comhierarchy层内联系为：构件版本依赖联系comverdependency第五层为软件层：实体例如为：软件关系software,软件版本关系softver_vt层内联系为：软件层次联系softhierarchy(层内联系为：软件版本依赖联系softverdependency第六层为支持数据层：实体例如为：支持数据关系supdataset,支持数据版本supver_vt层内联系为：支持数据版本联系supverrelship_vt第七层为变更层：变更关系change_vt该层内没有联系，层间联系通过“变更类型chgtype，变更前版本号prechgverid,变更后版本号postchgverid”三个属性与其他层间建立联系，例如变更类型为“需求变更”，则变更前版本号prechgverid与第一层需求层内的需求版本对象相对应，建立联系；变更后版本号postchgverid也与第一层需求层内的需求版本对象相对应，建立联系。当变更类型为设计变更、模型变更、构件变更、软件变更和支持数据变更时，变更相应的与其对应的层和层内对象建立联系。第一层与第二层层间联系：需求版本与设计版本之间可跟踪性联系：trac_reqver_desver第二层与第三层层间联系：设计版本与模型版本可跟踪性联系trac_desver_modver第三层与第六层层间联系：模型版本与支持数据版本可跟踪性联系trac_modver_suppver第二层与第四层层间联系：设计版本与构件版本可跟踪性联系trac_desver_comver第四层与第六层层间联系：构件版本与支持数据版本可跟踪性联系trac_comver_suppver第四层与第五层层间联系：构件版本与软件版本可跟踪性联系trac_comver_softver。按照上面各层说明，第一层至第六层，每层内的实体是对应的实体对象及其各个版本对象，例如：第一层需求层，包含需求对象，以及每个需求对象的各个版本对象；层内联系主要是：父子层次联系和版本对象之间的依赖联系，而版本对象之间的依赖联系主要是相关依赖联系、同步依赖联系等，详情参见表2.1常用的实体间依赖关系。第七层变更层，则只包含各个变更对象，没有版本对象，层内对象之间没有联系。该层与其它层的联系，见之前对“第七层为变更层”的介绍举例说明。根据以上举例，举例说明算法2.1中循环的执行过程：从算法2.1执行2步循环开始，第3步，判断requirements是一个实体关系，则第4步，增加一层，第5步，建立需求层时态依赖图，(循环)第3步，判断reqver_vt是一个时态实体关系，则第5步由于需求时态实体关系依赖需求实体关系，则仍然在需求层建立需求版本对象。(循环)第6步，判断reqhierarchy为internalrelationship，则第7步，生成层内需求实体依赖联系；(循环)第6步，判断reqverdependency为internalrelationship，则第7步，生成层内需求版本实体依赖联系；(循环)第8步，判断trac_reqver_desver为需求层与设计层之间的联系，则第9步，生成需求层与设计层之间的联系其他依次类推。8.2多层时态依赖图的性质(1)异构性(heterogeneous)依赖图中存在异构的实体(如需求、设计、模型、构件等等)，也存在异构的不同粒度的结点(如实体、属性和行为等结点)。(2)多层性(mutilayer)同类实体为一次，每层都是一个多粒度有向依赖图。(3)多粒度(multigranular)每一层都存在实体、属性和行为等不同粒度。(4)有向性(directed)依赖关系具有不对称性，因此必须是有向的。如实体a依赖b于dt，等价的描述是：b被a依赖于dt-1,但都统一记为：记为<a,dt,b>。(5)非循环性(acyclic)由于依赖的反自反性，依赖不能存在循环，因此，有向依赖图中也不能存在循环子图。(6)稀疏性(sparse)由于实体通常只跟少数其他实体有依赖关系，依赖图中也会存在一个个子的依赖社区，总体上，依赖图表现出稀疏性。(7)动态性(dynamic)由于会不断有新的实体(如新的需求项、构件、模型等)加入依赖图，有些不再使用的实体也会被淘汰，因此总体上，依赖图会不断变化，呈现出较大的动态性。(8)时态性(temporal)依赖图中存在时态实体、实体也可能存在时态属性，其中一个最主要的时态变化，是需求、设计、模型、构件、软件等的版本性，他们会随时间不断演变产生新的版本，依赖图因此会随时间的变化不断演变，变现出很强的时态特性。深入理解和分析依赖图的以上特性，对依赖图的依赖性分析具有很重要的意义。九、设计基于时态的软件配置管理对象依赖关系发现算法本发明考虑到软件系统生命周期软件缺陷修复、功能增强、性能改进、需求增加、运行环境改变等均要求构件和软件系统等对象具有较强的演化能力，对象之间的依赖关系也可能在随时间不断发生变化演化。同时，由于多版本并行开发，某个软件对象演化特征并不是简单的随时间线性演化，由于不同用户要求或运行环境要求而存在多个版本分支随时间演化而构成一个版本树。因此有必要研究基于时态的对象依赖关系发现算法研究。随着需求、设计、模型、构件等复用程度的增加，软件开发过程的各类实体之间的依赖关系也变得越来越复杂。因此有必要统计和分析各类实体的依赖关系，分析各类实体的稳定性、抽象性和是否存在循环依赖的问题，分析各类实体依赖关系的合理性，甚至可以发现不必要的依赖关系。对于设计的分层时态依赖图，既可以在整个图上执行各种依赖分析任务，也可以选择只在某层上执行分析任务，使得依赖分析任务执行比较灵活。另外，目前考虑分层的模型，一方面是为了在逻辑上容易理解复杂的时态依赖图，另外，在图形化显示方面，也可以按分层的思想来显示，也更有利于理解实体之间的依赖关系。为了进行依赖性分析，借鉴代码质量的评价指标，定义几个类似的依赖性评价指标：定义2.13传入耦合ca(afferentcouplings)依赖于被分析实体的其他实体的数量，即有多少实体依赖于它，用于衡量实体的职责，以评估变更实体造成的影响。图21给出了传入耦合示例图，其中n个实体entity1、entity2、……entityn均依赖于entity0。如图21所示，ca越大，更改entity0造成的影响越大，ca越小，更改entity0造成的影响越小。定义2.14传出耦合ce(efferentcouplings)被分析的实体所依赖的其他实体的数量，即它依赖了多少其他实体，用于衡量实体的独立性，以评估外界的更改如何影响实体。图22给出了传出耦合示例图，其中实体entity0分别依赖于n个实体，从实体entity1、entity2、……到entityn。如图22所示，ce越大，外界变更对该实体的影响越大，ce越小，外界变更对该实体的影响越小。定义2.15实体不稳定性i(entityinstability)定义i＝ce/(ce+ca)，用于衡量实体的不稳定性，取值范围为[0,1]，i＝0表示实体最稳定，i＝1表示实体最不稳定。如这个等式所示，传出耦合对包的稳定性起作用：一个包越依赖于其他包，面对更改时它越容易受到连锁反应的影响，换句话说，如果这个实体不依赖于任何其他实体，则它是最稳定的。反过来说，一个实体越被依赖，它越不可能发生更改。在开发、设计和实现实体时，依赖于稳定的实体是有益的，因为这些实体不太可能更改；而不稳定的实体依赖性会在发生变更时增大系统发生间接变更的风险。定义2.16实体抽象性a(entityabstractness)如果软件开发过程的实体越与具体的项目和应用背景无关，越能用到更多的项目和应用中去，就越抽象。抽象性a取值范围为[0,1],取值为0，表示最具体，不抽象；取值为1，表示最抽象。该取值可以由该实体与具体应用无关的特征和全部特征的比值得出，或者由专家凭经验给出，或者利用该实体的复用度来估计。定义2.17实体距离d(enttitydistance)图23给出了实体距离计算的示意图。被分析实体和理想曲线a+i＝1的垂直距离(如图23所示)，用于衡量实体在稳定性和抽象性之间的平衡。理想的实体要么完全是抽象的和稳定(a＝1，i＝0)，要么完全是具体类和不稳定(a＝0，i＝1)。取值范围为[0,1]，d＝0表示完全符合理想标准，d＝1表示实体最大程度地偏离了理想标准。即实体要么是抽象的，不依赖任何其他实体(完全是抽象类和稳定)；要么是具体的，不被任何其他实体依赖。定义2.18循环依赖c(cycle)循环依赖的数量。定义2.19依赖强度s(severityofdependency)定义多层时态有向依赖图的边的权值为依赖强度s(severityofdependency)。通常该依赖强度默认值为1，即完全依赖，依赖强度为0表示不依赖，取值范围为[0,1]。某个实体直接依赖另外一个实体，其依赖强度通常由业务人员或者业务专家给出。由于依赖存在传递性，结点a到c之间的间接依赖强度不断减弱，由a到c的最短路径上的所有边的依赖强度相乘得出,再除以(ln(最短路径的边数)+1)。2.1)例如，设a----0.8--->b---0.9---->c,则a--->>c的依赖强度有下列公式计算：severityofdep(a,c)＝severityofdep(a,b)×severityofdep(b,c)/(ln(最短路径的边数)+1)＝0.8×0.9×/(ln2+1)在做依赖性分析之前，可以遍历整个图，计算各个结点的传入耦合、传出耦合、稳定性、抽象性等性能指标。在分析结果中可以显示各个结点的上述指标。目前研究如下分析算法和分析结果展现算法。直接依赖统计分析算法2.2基本思想是采用宽度优先算法遍历整个图，计算每个结点的传入耦合ca、传出耦合ce和实体稳定性i。如果每个实体的抽象性给定，则可以根据定义2.17计算每个结点的实体距离d。算法2.2:直接依赖统计分析算法ddsa(directdependencystatistics&analysisalgorithm)实际上，结点的传入耦合ca也表示该结点代表的实体被多少个其他实体依赖，也表示一种被使用情况；而传出耦合ce也表示该实体依赖了多少个其他实体，也表示一种使用情况。通过算法2.2计算出每个结点的各个指标参数后，可以如表2.2的表格方式，把有向依赖图展现出来，方便用户浏览。表2.2实体依赖浏览表示例依赖链分析(1)从给定实体出发的直接依赖和间接依赖分析从给定实体出发，查找其直接依赖和间接依赖关系，实际上是从给定实体出发，生成一棵生成树的过程。由于依赖关系的反自反特性，有向依赖图中不存在循环，所以一定能够生成一棵树，该生成树的最大高度由给定的最大间接依赖层数lmax确定，从而避免生成太高的生成树，难以显示，也不便于理解。算法2.1的基本思想是，采用宽度优先算法生成实体依赖树，同时也要保持原有的分层特性，便于理解。算法2.3:依赖链分析算法dla(dependencylinkanalysisalgorithm)对于实体依赖树，可以使用例如d3.js这样的强大的可视化图形显示工具来显示，也需要设计相应的分层显示算法。(2)从给定实体出发的正向依赖分析和逆向依赖分析算法dla实际上是一个正向依赖链分析算法，即沿着a依赖于b，b依赖于c，c依赖于d，...的依赖链正向分析实体之间的直接和间接依赖关系。为了实现逆向依赖分析算法，只需把算法did的宽度优先遍历出边，改为宽度优先遍历入边，就可以实现逆向依赖分析，即沿着a被b依赖，b被c依赖，c被d依赖，...的方向一直分析下去，是一种逆向依赖链分析方法。把算法dla改造为一个通用的正向或者逆向分析算法，如算法mdla所示，只需要通过一个控制变量就可以控制正向或逆向分析，当然也可以双向分析。算法2.4:多向依赖链分析算法mdla(multidirectionaldependencylinkanalysisalgorithm)正向分析或者逆向分析，产生的是一个实体依赖树，比如容易清楚地显示实体之间的依赖关系，但是当同时进行双向分析时，很容易把依赖和被依赖关系混合在一起，这样就需要在显示时，采用比较灵活方便的方式来显示。另外正向分析结果和逆向分析结果合并在一起，并不等于同时进行的双向分析结果。这一点将在实现时予以区分。举例说明如下：图24显示了一个与时态实体a相关的所有依赖关系的图。图中既包括从a开始的依赖关系：a依赖于b、c，b依赖于w，c依赖于z；同时也包括从a开始的被依赖关系：a被d、e依赖，d被b依赖，b被g、f依赖。图24中还包括了与结点b、c有依赖关系的其它结点x、y、u、v。针对图24所示的实体依赖图，图25显示了正向实体依赖分析结果为：a依赖于b、c，b依赖于w，c依赖于z。针对图24所示的实体依赖图，图26显示了逆向实体依赖分析结果为：a被d、e依赖，d被b依赖，b被g、f依赖。针对图24所示的实体依赖图，图27显示了双向实体依赖分析结果为：从a开始的依赖关系：a依赖于b、c，b依赖于w，c依赖于z；从a开始的被依赖关系：a被d、e依赖，d被b依赖，b被g、f依赖。图24中还包括了与结点b、c有依赖关系的其它结点x、y、u、v。可以证明，当lmax等于1时，算法mdlaa分析算法满足：mdla(正向分析)+mdla(逆向分析)＝mdla(双向分析)；当lmax大于1时，算法mdla分析算法满足：mdla(正向分析)+mdla(逆向分析)<>mdla(双向分析)；因此改进算法mdla为tmdla，可以实现当lmax为任何值时，tmdla(正向分析)+tmdla(逆向分析)＝tmdla(双向分析)。这样可以减少图的二次遍历，从而提高分析效率。改进的基本思想是：设立两个队列，一个正向队列，一个逆向队列，对正向队列的所有结点，都只进行正向分析；对逆向队列的结点，都只进行逆向分析。算法如下：算法2.5:通用多向依赖链分析算法tmdla(truemultidirectionaldependencylinkanalysisalgorithm)(3)从给定两个实体出发，分析它们之间的依赖关系给定两个，或者多个实体，分析他们之间的依赖关系，实际上是一个有向图搜索生成steiner树的问题，这个问题在数据库信息检索领域已经有很多研究。解决该问题的基本思想是：把有向图当做无向图看待，然后把给定的实体对应的结点当做叶子结点，从每个叶子结点出发并行执行一个最短路径算法(如dijkstra算法)，直到找到一个公共的结点或者找不到为止，该算法为banks算法。如果接着在该结果的基础上，进一步优化，可以采用star算法。(4)检测多层依赖图中的循环依赖多层依赖图在整体上还是一个有向图。由于有向图的循环检测算法时间复杂性通常为o(n2)，比较耗费时间。因此，一方面，可以在整个图上检测循环依赖，另一方面，也可以只在某一层上检测循环依赖。另外，如果不考虑时态约束，则多层依赖图中可能存在较多的循环依赖，但是，若从时态的角度考虑，有些依赖关系是有有效性，即在某个有效时间范围内是有效的，当查询时间不在其有效范围之内，则那些依赖关系相当于是不存在的。因此，需要把目前已有的在有向图上检测环的算法，改为时态的有向环检测算法。为了检测环，借鉴一个改进的深度优先(depthfirst)搜索算法，称之为着色的dfs算法。其基本思想是：初始，所有结点标记为白色(white,即未被访问过)，当它被访问过，标记为灰色(grey)，当它的所有后裔结点都被完全访问过，它被标记为黑色(black)。如果一个灰色结点被再次遇到(访问)，则存在一个环。时态的有向图环检测算法2.6所示。算法2.6:检测循环依赖算法dcd(detectingcycledependencyalgorithm)算法2.7:结点访问算法visit//booleanvisit(graphmtdg,vertexv,validtimeqvt):社会性分析开发人员之间的社会性依赖关系，通常是通过与其他实体之间的技术-社会性依赖关系和技术性依赖关系推导得出来的。这里又分为直接推导出来的，还是间接推导出来的。如图28所示。图28是一个推导出开发人员只见依赖关系示意图。其显示了开发人员d7依赖于d4，d4依赖于d3，d5依赖于d3，其具体的依赖关系推导过程可能是直接推导出来的，也可能是间接推导出来的。根据开发人员和需求，开发人员和设计之间的依赖关系(其意义是指需求或者设计分配给某个开发人员来完成，因此也可以理解为需求或者设计依赖该开发人员)，推导出开发人员之间存在依赖关系，其依赖强度由公式2.1得出。图29显示了开发人员d7依赖于d4推导关系示意图。在图中，由于r1—>r2—>s2,则推导出d7依赖d4，其依赖强度(权值)由公式2.1得出。这里从r1到s2有两条路径，则d7和d4之间存在两个依赖关系，对应存在两条边，其依赖强度不一样。依据每条依赖边，可以查询其依赖路径详情。社会性依赖图产生算法如下：算法2.8:社会性依赖图生成算法sdgg(socialdependencygraphgenerationalgorithm)算法2.8只是一个简单的社会性依赖图的生成算法。在实现时，讲依据实验情况，进一步改进该生成算法。(1)从给定开发人员出发分析其直接依赖的其他开发人员和间接依赖的开发人员(2)从给定开发人员出发的正向依赖分析和逆向依赖分析(3)从给定两个开发人员出发，寻找他们之间的依赖关系基于社会性依赖图，可以直接采用多层时态依赖图上的算法2.3到2.6，按照上述三种情况分析开发人员之间依赖关系。时态性分析对于多层时态依赖图，结点和边都有有效时间。上述各种分析算法，通过增加一个查询时间区间，在处理过程中增加时间区间过滤，就可以实现基本的时态依赖分析算法。(1)对给定实体，分析其版本演化情况对应算法2.5.输入增加一维输入参数“有效时间”validtime。(2)对给定实体，分析其依赖关系随版本变化情况该分析对应算法2.5输入增加一维输入参数“有效时间”validtime。(3)对给定实体，分析其被依赖(被使用)情况该分析对应算法2.2。十、变更分析本发明研究通用的变更影响分析方法来支持需求、设计、模型、构件、软件和支持数据等软件开发过程实体的变更影响分析。下面以需求变更为例，概述变更相关概念和过程。变更类型，指引起变更的原因类型，可分为需求变更、设计变更、代码优化、用户文档优化和计划变更等。变更优先级，依据变更的重要性、紧迫性和对关键业务的影响程度，以及对系统安全性和稳定性的影响程度，可分为critical、high、middle和low等4级。变更标志，分为新增、修改和删除。变更影响分析，包括变更影响对工作量和进度的影响，发生风险的可能性与影响程度，以及需要回测的范围。可能影响的工作产品，包括项目计划、需求文档、概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例以及用户文档。十一、构建软件配置管理对象变更模型本发明基于时态和图模型，构建软件对象内部以及对象之间的依赖、交互及架构关系，以进行变更影响分析。从不同的角度来看，可以对由软件对象建立不同的模型。例如，从外部用户的角度,构件的主要功能是提供api，于是可以建立api模型；从系统层面看，构件之间存在着交互关系，还有组合、配置等多种架构关系，可以建立相应的系统模型。因此，建立合适的软件对象以及系统模型是软件对象变更影响分析的重要前提。基于多层时态依赖图模型，我们把需求、设计、模型、构件、软件和支持数据等所有实体的变更，统一当做一个单独的变更层，从而可以在多层时态依赖图中增加一个变更层，如图30所示。图30是增加了变更层的多层时态依赖图示例。其中，变更层中有节点c1到c6，其中层内依赖正向关系(a依赖于b)为：c4、c1、c5、c2、c6、c3；层间依赖正向关系为参见图中：c4依赖于r1，c1依赖于r1，c5依赖于r1，c2依赖于r2，c6依赖于s4，c3依赖于s3。为了简单起见，结点和边的时态约束没有标注，默认每个结点和每条边都有一个有效时间。在“3.1以需求为核心的数据库模式逻辑设计(table和view)”中，有基于变更的时态实体设计——表table：变更change_vt、变更状态chgstat_vt；还有基于变更的视图view设计——需求变更view_reqchg_vt。在其后各小节的数据库逻辑模型的设计中，存在外部视图的设计，例如设计变更视图、模型变更视图等等。这是因为，每个对象都有变更，在逻辑模型中(table、view及其字段)设计出来了。具体例如：“3.2以设计为核心的数据库模式逻辑设计(table和view)”中，有视图view——设计变更view_deschg_vt；“3.3以模型为核心的数据库模式逻辑设计(table和view)”中，有视图view——模型变更view_modchg_vt；“3.4以构件为核心的数据库模式逻辑设计(table和view)”中，有视图view——构件变更view_comchg_vt；“3.5以软件为核心的数据库模式逻辑设计(table和view)”中，有视图view——软件变更view_softchg_vt；“3.6以支持数据为核心的数据库模式逻辑设计(table和view)”中，有视图view——；“3.7以项目为核心的数据库模式逻辑设计(table和view)”中，有视图view——；“3.8以配置为核心的数据库模式逻辑设计(table和view)”中，有视图view——配置项变更view_cichg_vt。关于逻辑模型table中的字段此处不再赘述，可以参照第三节“逻辑模型”中各个逻辑模型table中与“变更”相关的字段。因此，基于之前算法2.1多层时态依赖图生成算法mtdgga构建时态依赖图时，可以如图30增加变更层，从而可以构建基于时态的对象变更模型。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例该的方法。以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的
技术领域：
：，均同理包括在本发明的专利保护范围内。当前第1页12当前第1页12