CN111984311A - 一种基于运行日志的软件结构复现的方法 - Google Patents

Abstract

本发明公开了一种基于运行日志的软件结构复现的方法，该方法首先基于插装技术对软件系统进行动态插装，并获得原始日志；然后对原始日志进行预处理操作，即按照业务请求对原始日志分组并得到事件日志；最后使用首次提出的逆向挖掘算法，对事件日志进行挖掘并最终复现软件系统的结构模型。相对于传统获取软件结构模型的方法，本发明并不需要软件系统的源代码，而是基于成熟的插装技术，对使用Java语言实现的软件系统在运行时植入检测代码从而获得原始日志，最终挖掘得到结构模型。也可以对一个部署完成的软件系统在其正常工作时进行动态插装，而不对软件系统的正常使用造成太大影响。此外，本发明还提供了一种描述软件结构的形式化类图模型。

Description

一种基于运行日志的软件结构复现的方法

技术领域

本发明涉及软件逆向工程技术领域，具体涉及一种基于运行日志的软件结构复现的方法。

背景技术

软件结构模型可以帮助人们理解软件系统的内部组成结构，对软件系统的理解和维护起到极其重要的作用。然而，很多情况下软件系统的模型往往并不是能够直接获得的。例如一些早期就存在的遗留软件，很多文档或者模型已经缺失，或者在快速开发过程中就本身就缺少详细的模型文档，甚至很多遗留软件的源代码都已经缺失。这使得人们难以理解这些软件，从而导致维护遗留系统变成一件很困难的事情，也就无法对软件进行进一步的重用。软件逆向工程能够解决上述问题，具有重大现实意义和经济价值，也越来越受到人们的重视。

然而，现有的获得软件结构模型的相关工作都属于静态分析，即通过对软件系统的源代码或者编译后的目标码进行静态分析，从中抽象出软件结构模型的过程。然而正如上文所述，其实在某些情况下用户无法获得软件系统的源代码，这些工作也就无法适用了。同时静态分析常常利用源代码中的不同文件的包含来确定彼此之间的关系，然而很多时候即使包含了某文件的头文件，但在实际上却没有使用到这个文件，这样的判定规则必然存在一些误判。

因此，为了针对那些遗失源代码而只剩可执行程序的软件系统，同时为了提高复现的软件结构模型的准确性，目前亟待提出一种基于软件系统运行信息的软件静态结构模型逆向挖掘方法。

发明内容

本发明的目的是为了解决现有技术中的上述缺陷，提供一种基于运行日志的软件结构复现的方法。这是一种较为新颖的方法，本质上属于动态分析，通过软件系统运行时的真实动态信息来挖掘复现软件结构模型。

本发明的目的可以通过采取如下技术方案达到：

一种基于运行日志的软件结构复现的方法，该方法无需软件系统的源代码，可以对一个已经投入使用的软件系统进行动态插装，在几乎不影响其正常使用的同时获得原始日志，然后将原始日志预处理成事件日志，之后根据事件日志提取软件结构的基础信息，随后挖掘软件结构的关系信息，并最终构建一个形式化的软件结构模型，最终还可以对挖掘出的软件结构模型进行可视化展示。其特征在于，该方法包括以下步骤：

S1、针对一个由Java编程语言实现的软件系统，基于插装技术在其处于运行时进行动态插装，并最终收集到原始日志；

S2、将步骤S1中得到的原始日志进行预处理得到事件日志，即通过识别软件系统处理的业务请求将原始日志中的事件进行分组，从而最终得到事件日志；

S3、对步骤S2中得到的事件日志进行词法分析与信息提取，获得事件日志中的类组件集合；

S4、对步骤S2中得到的事件日志以及步骤S3中获得的类组件集合进行逆向挖掘，获得类组件之间的关系信息；

S5、利用形式化后的类图模型记录并描述上述得到的类组件集合信息与类组件之间的关系信息，进而构建最终的软件结构模型。也可以将模型进行可视化展示。

进一步地，所述的步骤S1过程如下：

S101、在软件系统每个部署的物理节点上，通过分布式插装工具对软件系统进行动态插装处理，该分布式插装工具利用java_agent库和javassist库所提供的技术支持，在软件系统运行时动态地对其植入获得方法运行信息的监测代码；

S102、插装工具在每个部署的物理节点上分布式地产生运行信息，通过日志，对每个部署的物理节点上产生的方法运行信息进行统一的日志收集，并按方法运行信息的产生时间进行排序，最终得到原始日志。

进一步地，所述的原始日志是由若干条软件系统中方法的运行信息组成。一条方法运行信息实际上是指软件系统中的一个方法在被调用时，植入的相应监测代码随之执行的产物。在本发明中，一条方法运行信息被定义为一个事件，一个事件主要包括当前方法执行的相关信息以及当前方法所属类的相关信息。前者具体包括当前方法名、执行当前方法的线程号、执行当前方法的节点信息、执行当前方法的时间戳与标识当前事件为开始还是结束的时间标识、以及当前执行当前方法的资源信息；后者包括类名、属性信息、方法信息、构造信息、当前类继承的父类以及当前类实现的接口信息。这些信息共同组成了一条事件记录。

进一步地，所述的步骤S2过程如下：

S201、根据事件的直接调用关系将步骤S1中获得的原始日志初步划分成若干个事件集合；

S202、将步骤S201得到的若干个事件集合按照线程之间的父子线程关系将属于一对父子线程的事件集合进行合并；

S203、将步骤S202得到的若干个事件集合按照节点的通信将相互通信的事件集合进行合并，并得到事件日志。

进一步地，所述的步骤S3过程如下：

S301、提取步骤S2得到的事件日志中的一条事件a，若此时在类组件集合中不存在事件a所对应的类组件，则收集事件中的类名、方法信息、属性信息以及构造信息并初步构建成一个类组件，然后将类组件加入类组件集合，按照以上操作对事件日志中的所有事件进行处理，得到初步类组件集合；

S302、提取步骤S301得到的初步类组件集合中的一个类组件A，进行如下两步的判断：

判断1：若类组件A实现了一个接口i，则构建一个类名为接口i且其他信息为空的类组件，并将构建的类组件加入类组件集合中；

判断2：若类组件A继承了一个父类c，且目前的类组件集合中不存在类组件对应于此父类c，则构建一个类名为父类c且其他信息为空的类组件，并将构建的类组件加入类组件集合中；

按照以上两步的判断操作对步骤S301得到的初步类组件集合中的所有类组件进行处理，得到完整的类组件集合。

进一步地，所述的步骤S4过程如下：

S401、对步骤S3得到的所有类组件进行查找，若类组件B以属性的方式存在于类组件A中，则令类组件A与类组件B之间存在关系r1；

S402、对步骤S3得到的所有类组件进行查找，若类组件A继承类组件B，则令类组件A与类组件B之间存在关系r2；

S403、对步骤S3得到的所有类组件进行查找，若类组件A实现一个类组件B，令类组件A与类组件B之间存在关系r3；

S404、对步骤S2得到的事件日志中的每个实例进行查找，若同一个实例中的事件a与事件b具有调用关系，同时所对应的类组件A和类组件B不存在关系r1，则令类组件A与类组件B之间存在关系r4；

S405、对上述步骤得到的关系进行进一步地判断和优化，确认得到的关系是否正确以及关系是否可以被继续细化，过程如下：

S405.1、对于一个关系r4所联系的类组件A与类组件B。如果存在一个类组件C与类组件A或者与类组件B存在关系r4，此时需要进一步判断此关系r4是否会被这些关系影响从而改变；

S405.2、考虑关系r1是否可能进一步被划分，在这里需要根据两个条件对其进行判断：

1)若类组件A与类组件B具有关系r1，此时不存在另一个类组件C与类组件B具有r1关系；

2)存在事件调用关系，调用事件代表的方法为类组件A中的构造方法，被调用事件代表的方法为类组件B中的构造方法；若同时满足上述两个条件则认为此关系r1可以被细分成关系r5。

进一步地，所述的步骤S404中判定事件a和事件b是否具有调用关系的过程如下：

S404.1、计算处于同一个实例中且位于同节点同线程的两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下三个条件：

1)事件a和被事件b的线程号和节点信息一致；

2)事件a的运行周期必须包含被事件b的运行周期；

3)在事件a开始至事件b开始的这段时间中不允许有一个事件c开始但未完成，其中事件c与事件a和事件b同属一个实例，且线程号和节点信息一致；

S404.2、计算处于同一个实例中且位于同节点不同线程的两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下两个条件：

1)事件a和被事件b的节点信息一致，线程号不一致；

2)事件a和被事件b资源信息属于同一对父子线程；

S404.3、计算处于同一个实例中且位于不同节点两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下两个条件：

1)事件a和被事件b的节点信息不一致；

2)事件a和被事件b资源信息属于同一对通信双方。

进一步地，所述的步骤S5中，基于Object-Z语言形式化后的UML类图模型描述上述得到的类组件集合与类组件之间的关系信息，进而构建最终的软件结构模型。

本发明相对于现有技术具有如下的优点及效果：

1)现有逆向获得软件系统的相关工作几乎都是从软件系统的源代码出发，而本发明提供了一种无需源代码，只需要可执行程序就能逆向挖掘软件系统静态结构模型的新颖方法。这是一种适用性极广的方法，为那些源代码已经遗失的遗留软件产品或无法获得源代码的软件提供一种有效可信的分析手段。

2)现有的逆向工作大多将头文件作为文件之间关系的重要依据，然而头文件的包含而文件没有与之产生任何联系也是颇为常见的，这样的判断必然会对准确率有一定的影响。而本发明基于方法的调用来判断类之间的联系，极大得提高了结果的可信度。

3)针对UML语言本身是一种半形式化的语言，没有精确的语义，不能直接用于精准的分析工作的问题，本发明提供了一种使用Object-Z语言形式化后的类图模型，能够精确地描述软件系统的内部组成结构，也更加符合实际的分析需求。

附图说明

图1是本发明实施例中公开的一种基于运行日志的软件结构复现的方法的流程图；

图2是本发明实施例中基于Object-Z语言形式化后的类图模型部分说明图；

图3是本发明实施例中动态插装过程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

现有的逆向获取软件系统静态结构模型的相关工作几乎都需要软件系统的源代码。本实施例针对这种限定条件，提供了一种基于运行日志的软件结构复现的方法。该方法在没有软件系统源代码的情况下，仅从一个可执行的软件系统出发，收集其在运行时所产生的运行信息，然后根据这些运行信息挖掘出准确的软件结构模型，并可为接下来的软件系统理解、分析以及维护等工作提供准确重要的依据。

如图1所示，公开了一种基于运行日志的软件结构复现的方法的流程图，包括以下步骤：

S1、针对一个由Java编程语言实现的软件系统，基于插装技术在其处于运行时进行动态插装，并最终收集到原始日志；

本实施例的步骤S1中，对一个由Java编程语言实现的软件系统进行动态插装并收集得到原始日志，具体过程如下：

S101、基于插装技术设计了一个分布式插装工具，该工具利用java_agent库和javassist库所提供的技术支持，在软件系统运行时动态地对其植入获得方法运行信息的监测代码。并且考虑到一个投入使用的软件系统可能部署在多个物理节点上，因此对每个部署的物理节点上都对软件系统进行动态插装处理；

S102、考虑到步骤S101中的插装工具将会在多个节点上分布式地产生运行信息，因此设计了一个统一的日志收集处理程序，此收集工具可以对所有节点上产生的方法运行信息进行统一的收集，并按方法运行信息的产生时间进行排序，最终得到原始日志。

其中，原始日志是由若干条软件系统中方法的运行信息组成。一条方法运行信息实际上是指软件系统中的一个方法在被调用时，植入的相应监测代码随之执行的产物。在本发明中，一条方法运行信息被定义为一个事件，一个事件主要包括当前方法执行的相关信息以及当前方法所属类的相关信息。前者包括当前方法名、执行当前方法的线程号、执行当前方法的节点信息、执行当前方法的时间戳与标识当前事件为开始还是结束的时间标识、以及当前执行当前方法的资源信息；后者包括类名、属性信息、方法信息、构造信息、当前类继承的父类以及当前类实现的接口信息。这些信息共同组成了一条事件记录。

S2、将步骤S1中得到的原始日志进行预处理得到事件日志，即通过识别软件系统处理的业务请求将原始日志中的事件进行分组，从而最终得到事件日志；

本实施例的步骤S2中，通过识别软件系统处理的业务请求将原始日志中的事件进行分组，从而最终得到事件日志，具体过程如下：

S201、根据事件的直接调用关系将步骤S1中获得的原始日志初步划分成若干个事件集合；

S202、将步骤S201得到的若干个事件集合按照线程之间的父子线程关系将属于一对父子线程的事件集合进行合并；

S203、将步骤S202得到的若干个事件集合按照节点的通信将相互通信的事件集合进行合并，并得到事件日志。

经过上述步骤S201-步骤S203得到的事件日志中，一个事件集合称作一个实例，即一个实例是一个事件序列，因此事件日志又可以看作是实例的集合。

S3、对步骤S2中得到的事件日志进行词法分析与信息提取，获得事件日志中的类组件集合；

本实施例的步骤S3中，首先需要提取组成一个软件结构模型中的基本组成内容，即对步骤S2得到的事件日志中的事件进行词法分析，提取软件结构的基础信息，即获取到软件系统的所有类组件集合，包括：

S301、提取步骤S2得到的事件日志中的一条事件a，若此时在类组件集合中不存在事件a所对应的类组件，则收集事件中的类名、方法信息、属性信息以及构造信息并初步构建成一个类组件，然后将类组件加入类组件集合，按照以上操作对事件日志中的所有事件进行处理，得到初步类组件集合；

S302、提取步骤S301得到的初步类组件集合中的一个类组件A，进行如下两步的判断：

判断1：若类组件A实现了一个接口i，则构建一个类名为接口i且其他信息为空的类组件，并将构建的类组件加入类组件集合中；

判断2：若类组件A继承了一个父类c，且目前的类组件集合中不存在类组件对应于此父类c，则构建一个类名为父类c且其他信息为空的类组件，并将构建的类组件加入类组件集合中；

按照以上两步的判断操作对步骤S301得到的初步类组件集合中的所有类组件进行处理，得到完整的类组件集合。

S4、对步骤S2中得到的事件日志以及步骤S3中获得的类组件集合进行逆向挖掘，获得类组件之间的关系信息；

本实施例的步骤S4中，还需要进一步挖掘软件结构的关系信息，也就是需要明确各个类组件之间的关系，因此基于步骤S2中已得到的事件日志和步骤S3中已得到的类组件集合，判断类组件之间的关系，具体过程如下：

S401、对步骤S3得到的所有类组件进行查找，若类组件B以属性的方式存在于类组件A中，则令类组件A与类组件B之间存在关系r1；

S402、对步骤S3得到的所有类组件进行查找，若类组件A继承类组件B，则令类组件A与类组件B之间存在关系r2；

S403、对步骤S3得到的所有类组件进行查找，若类组件A实现一个类组件B，令类组件A与类组件B之间存在关系r3；

S404、对步骤S2得到的事件日志中的每个实例进行查找，若同一个实例中的事件a与事件b具有调用关系，同时所对应的类组件A和类组件B不存在关系r1，则令类组件A与类组件B之间存在关系r4；

该步骤S404中判定事件a和事件b是否具有调用关系的具体过程如下：

S404.1、计算处于同一个实例中且位于同节点同线程的两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下三个条件：

1)事件a和被事件b的线程号和节点信息一致；

2)事件a的运行周期必须包含被事件b的运行周期；

3)在事件a开始至事件b开始的这段时间中不允许有一个事件c开始但未完成，其中事件c与事件a和事件b同属一个实例，且线程号和节点信息一致；

S404.2、计算处于同一个实例中且位于同节点不同线程的两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下两个条件：

1)事件a和被事件b的节点信息一致，线程号不一致；

2)事件a和被事件b资源信息属于同一对父子线程；

S404.3、计算处于同一个实例中且位于不同节点两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下两个条件：

1)事件a和被事件b的节点信息不一致；

2)事件a和被事件b资源信息属于同一对通信双方。

S405、对上述步骤得到的关系进行进一步地判断和优化，确认得到的关系是否正确以及关系是否可以被继续细化。

在步骤S405中，还需要对上述已经初步获得的关系r4和关系r1做进一步地判断与优化，即判断获得的关系r4是否可以被省略，以及初步得到的关系r1是否可以被进一步细化为关系r5，具体过程如下：

S405.1、对于一个关系r4所联系的类组件A与类组件B。如果存在一个类组件C与类组件A或者与类组件B存在关系r4，此时需要进一步判断此关系r4是否会被这些关系影响从而改变；

S405.2、考虑关系r1是否可能进一步被划分，在这里需要根据两个条件对其进行判断：

1)若类组件A与类组件B具有关系r1，此时不存在另一个类组件C与类组件B具有r1关系；

2)存在事件调用关系，调用事件代表的方法为类组件A中的构造方法，被调用事件代表的方法为类组件B中的构造方法；若同时满足上述两个条件则认为此关系r1可以被细分成关系r5。

S5、利用形式化后的类图模型记录并描述上述得到的类组件集合信息与类组件之间的关系信息，进而构建最终的软件结构模型。也可以将模型进行可视化展示。

本实施例的步骤S5中，需要使用一个准确的，无二义性的模型来描述本发明的结果。传统的UML类图是一种半形式化的模型语言，虽然可以描述软件系统的结构，但是表示信息不够准确，无法直接用于准确的分析工作。因此本实施例提出了一个基于Object-Z语言形式化后的UML类图模型来描述上述的类组件集合信息和类组件之间的关系信息。最终输出软件结构模型，也可以将模型进行可视化展示。

综上，本实施例提供的基于运行日志的软件结构复现的方法，首先对由Java编程语言实现的软件系统进行动态插装，收集得到原始日志。然后根据软件系统处理的请求将事件进行分组成一个个实例，从而预处理得到事件日志。接下来对事件日志进行挖掘，首先对整个事件日志进行词法分析，记录关于类的相关信息如类名，属性信息和方法信息等软件结构基础信息，然后对事件日志中的每一个实例进行挖掘，得到事件间的调用关系，基于事件间的调用关系和软件结构基础信息处理得到软件结构的关系信息。最终使用一个由Object-Z语言形式化的类图模型准确地描述得到的软件结构的基础信息和关系信息，这个模型即为本发明的最终输出成果，亦可以进行可视化展示。

实施例二

本实施例继续公开一种基于软件运行日志的软件结构模型复现的方法，如图1所示，本方法先从运行的软件系统中获取原始日志，然后将原始日志经由预处理、提取类组件信息，挖掘类组件之间的关系等操作最终得到软件系统结构模型。包括以下步骤：

T1、如图1所示对一个由Java编程语言实现的可执行软件程序在运行时进行动态插装，即指植入检测代码并执行的过程。

本实施例采用基于插装技术实现的动态代理，实现了一个插装工具。其本质是利用java_agent和javassist技术，在字节码加载入Java虚拟机后进行拦截，按照插装工具中事先约定的规则对需要插装的方法进行匹配。然后在所匹配方法的前后植入事先约定的检测代码。最终将修改后的代码重新转为字节码并加载入Java虚拟机中执行。

T2、收集软件系统运行信息，得到原始日志。

步骤T1中植入的监测代码目的是获得当前方法信息以及执行的信息。例如方法名，所属类名等，以及当前的时间，运行的线程号等信息。考虑到软件系统可能运行在多个物理节点上，必须对整个软件系统的运行进行动态插装，因此必须设计一个统一的收集程序按事件的产生顺序收集所有节点上产生的事件并最终得到一个原始日志文件，这样就好比软件系统只在单个节点上运行并产生事件，这样解决了事件分布式产生的问题。

T3、将原始日志初始化为事件日志。

将原始日志预处理为事件日志，其中，原始日志是产生事件的简单集合，考虑到一个软件系统可能并发地处理多个业务请求，因此产生的日志是多个业务逻辑产生的事件交杂在一起的。显然需要将事件按业务请求进行分组才能进行后续的工作。首先根据事件的时间戳计算日志之间的直接调用关系并进行初步划分成若干个事件集合，其次按照线程之间的父子线程关系将属于父子线程的事件集合进行合并，最后根据节点的通信将属于相互通信的事件集合进行合并得到事件日志。最后得到的事件日志将传入事件日志管理模块并存储至数据库中。

T4、对事件日志进行逆向挖掘工作，挖掘出软件结构的各项组成信息。

对事件日志进行逆向挖掘，主要工作包括：对事件日志进行词法分析得到软件结构的基础信息；基于软件结构的基础信息以及事件日志中挖掘得到软件结构的关系信息。详细步骤如下：

对事件日志进行词法分析得到软件结构的基础信息。具体做法为对事件日志中的每条事件进行词法分析，提取其中的类名，属性信息，方法信息以及构造信息进行记录，我们称这样一个数据结构为类元组，若此类元组尚未得到记录，则将其进行存储。用这种方式对事件日志中的所有事件分析完成后就能得到软件结构的基础信息。

对事件日志以及软件结构的基础信息挖掘得到软件结构的关系信息。首先，在上述得到的类元组中寻找一个以属性的方式存在于其他类中的类，令这种情况的两个类存在关系r1；同时从类元组中寻找类之间的继承和类与接口的实现，我们规定，若一个类继承另一个类，则两个类存在关系r2，若一个类实现一个接口，则两个类存在关系r3；然后对事件日志中的每个实例进行关系挖掘，计算同一个实例中日志的事件调用关系，具有调用关系的两个事件，其所属的类若不存在关系r1，则存在关系r4。

上述从实例中寻找具有调用关系的两个事件的具体做法为，计算同一个实例中的两个事件，若这两个事件满足调用，即一个调用事件导致被调用事件发生，则需要满足以下三个条件：1)调用事件和被调用事件的线程号和节点信息一致；2)调用事件的运行周期必须包含被调用事件的运行周期；3)在调用事件开始至被调用事件开始的这段时间中不允许有任何未完成的事件。此外，上述结果仅适用于在单节点下单线程的软件系统，对于多节点多线程的软件系统，还需要获得同节点下多线程之间的事件调用以及多节点之间的事件调用。前者通过事件中父子线程的信息进行判定，后者通过事件中线程间的通信信息进行判定。

最后还需要对上述已经获得的几种关系做进一步的优化。首先对于一个关系r4所联系的两个类。考虑这两个类与其他类可能存在关系r2或者r3，此时需要判定此关系r4是否成立。其次考虑关系r1是否可能进一步被划分，使用两个条件对其进行判断：1)若类A与类B具有关系r1，此时不存在另一个类C与类B具有r1关系；2)存在事件调用关系，调用事件代表的方法为类A的构造方法，被调用事件代表的方法为类B的构造方法；若同时满足上述两个条件则认为此关系r1可以被细分成关系r5。最终得到软件结构的关系信息。

T5、对软件结构的基础信息和关系信息进行整合，复现并展示最终的软件结构模型。

传统的UML模型本身是一种半形式化的语言，没有精确的语义，不能直接用于精准的分析工作。因此如图2所示，本实施例基于Object-Z语言对其进行形式化处理，得到用Object-Z语言描述的类图并将其作为本实施例的软件系统静态结构模型。结构模型管理模块使用此模型来准确地描述上述挖掘出的软件系统结构的基础信息和关系信息，并创建出模型文件，同时本模块还可将软件结构模型进行可视化展示。

可以看出，本实施例公开的基于软件运行日志的软件结构模型复现的方法的贡献在于：1)实现了在无法获得源代码的情况下依旧能够逆向获得形式化的软件系统静态模型；2)利用软件系统运行时的真实信息而非静态信息来推导软件系统模块之间的联系；3)提供了一种形式化的模型来描述软件系统的静态结构。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (8)

1.一种基于运行日志的软件结构复现的方法，其特征在于，所述的方法包括以下步骤：

S1、针对一个由Java编程语言实现的软件系统，基于插装技术在其处于运行时进行动态插装，并收集到原始日志；

S2、将步骤S1中得到的原始日志进行预处理得到事件日志，即通过识别软件系统处理的业务请求将原始日志中的事件进行分组，从而得到事件日志，所述的事件日志中，一个事件集合称作一个实例，即一个实例是一个事件序列，因此事件日志是实例的集合；

S3、对步骤S2中得到的事件日志进行词法分析与信息提取，获得事件日志中的类组件集合；

S4、对步骤S2中得到的事件日志以及步骤S3中获得的类组件集合进行逆向挖掘，获得类组件之间的关系信息；

S5、利用形式化后的类图模型记录并描述上述得到的类组件集合与类组件之间的关系信息，进而构建最终的软件结构模型，其中，所述的软件结构模型可进行可视化展示。

2.根据权利要求1所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的步骤S1过程如下：

S101、在软件系统每个部署的物理节点上，通过分布式插装工具对软件系统进行动态插装处理，该分布式插装工具利用java_agent库和javassist库所提供的技术支持，在软件系统运行时动态地对其植入获得方法运行信息的监测代码；

S102、插装工具在每个部署的物理节点上分布式地产生运行信息，通过日志，对每个部署的物理节点上产生的方法运行信息进行统一的日志收集，并按方法运行信息的产生时间进行排序，得到原始日志。

3.根据权利要求1所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的原始日志是由若干条软件系统中方法的运行信息组成，一条方法运行信息被定义为一个事件，一个事件包括当前方法执行的相关信息以及当前方法所属类的相关信息，所述的当前方法执行的相关信息包括当前方法名、执行当前方法的线程号、执行当前方法的节点信息、执行当前方法的时间戳与标识当前事件为开始还是结束的时间标识、以及当前执行当前方法的资源信息；所述的当前方法所属类的相关信息包括类名、属性信息、方法信息、构造信息、当前类继承的父类以及当前类实现的接口信息，当前方法执行的相关信息和当前方法所属类的相关信息共同组成一条事件记录。

4.根据权利要求1所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的步骤S2过程如下：

S201、根据事件的直接调用关系将步骤S1中获得的原始日志初步划分成若干个事件集合；

S202、将步骤S201得到的若干个事件集合按照线程之间的父子线程关系将属于一对父子线程的事件集合进行合并；

S203、将步骤S202得到的若干个事件集合按照节点的通信将相互通信的事件集合进行合并，并得到事件日志。

5.根据权利要求1所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的步骤S3过程如下：

S301、提取步骤S2得到的事件日志中的一条事件a，若此时在类组件集合中不存在事件a所对应的类组件，则收集事件中的类名、方法信息、属性信息以及构造信息并初步构建成一个类组件，然后将类组件加入类组件集合，按照以上操作对事件日志中的所有事件进行处理，得到初步类组件集合；

S302、提取步骤S301得到的初步类组件集合中的一个类组件A，进行如下两步的判断：

判断1：若类组件A实现了一个接口i，则构建一个类名为接口i且其他信息为空的类组件，并将构建的类组件加入类组件集合中；

判断2：若类组件A继承了一个父类c，且目前的类组件集合中不存在类组件对应于此父类c，则构建一个类名为父类c且其他信息为空的类组件，并将构建的类组件加入类组件集合中；

按照以上两步的判断操作对步骤S301得到的初步类组件集合中的所有类组件进行处理，得到完整的类组件集合。

6.根据权利要求5所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的步骤S4过程如下：

S401、对步骤S3得到的所有类组件进行查找，若类组件B以属性的方式存在于类组件A中，则令类组件A与类组件B之间存在关系r1；

S402、对步骤S3得到的所有类组件进行查找，若类组件A继承类组件B，则令类组件A与类组件B之间存在关系r2；

S403、对步骤S3得到的所有类组件进行查找，若类组件A实现一个类组件B，令类组件A与类组件B之间存在关系r3；

S404、对步骤S2得到的事件日志中的每个实例进行查找，若同一个实例中的事件a与事件b具有调用关系，同时所对应的类组件A和类组件B不存在关系r1，则令类组件A与类组件B之间存在关系r4；

S405、对上述步骤得到的关系进行进一步地判断和优化，确认得到的关系是否正确以及关系是否可以被继续细化，过程如下：

S405.1、对于一个关系r4所联系的类组件A与类组件B。如果存在一个类组件C与类组件A或者与类组件B存在关系r4，此时需要进一步判断此关系r4是否会被这些关系影响从而改变；

S405.2、考虑关系r1是否可能进一步被划分，在这里需要根据两个条件对其进行判断：

1)若类组件A与类组件B具有关系r1，此时不存在另一个类组件C与类组件B具有r1关系；

2)存在事件调用关系，调用事件代表的方法为类组件A中的构造方法，被调用事件代表的方法为类组件B中的构造方法；若同时满足上述两个条件则认为此关系r1可以被细分成关系r5。

7.根据权利要求6所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的步骤S404中判定事件a和事件b是否具有调用关系的过程如下：

S404.1、计算处于同一个实例中且位于同节点同线程的两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下三个条件：

1)事件a和被事件b的线程号和节点信息一致；

2)事件a的运行周期必须包含被事件b的运行周期；

3)在事件a开始至事件b开始的这段时间中不允许有一个事件c开始但未完成，其中事件c与事件a和事件b同属一个实例，且线程号和节点信息一致；

S404.2、计算处于同一个实例中且位于同节点不同线程的两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下两个条件：

1)事件a和被事件b的节点信息一致，线程号不一致；

2)事件a和被事件b资源信息属于同一对父子线程；

S404.3、计算处于同一个实例中且位于不同节点两个事件，若这两个事件满足调用，即事件a的发生导致事件b的发生，则必须满足以下两个条件：

1)事件a和被事件b的节点信息不一致；

2)事件a和被事件b资源信息属于同一对通信双方。

8.根据权利要求1所述的一种基于运行日志的软件结构复现的方法，其特征在于，所述的步骤S5中，基于Object-Z语言形式化后的UML类图模型描述上述得到的类组件集合与类组件之间的关系信息，进而构建最终的软件结构模型。

Images