CN102385511B - 跨动态边界的运行时分析的可视化 - Google Patents

Abstract

公开了跨动态边界的运行时分析的可视化的技术，其涉及带有多个组件的软件程序的架构图的建立。可能通过执行所述软件程序的静态代码分析来访问标识组件中的至少一些和组件间关系的静态模型。还可以通过执行软件程序并观察所述执行来得出所述软件程序的动态行为，从而实现动态分析。这些动态行为可能是仅仅基于对计算机程序的静态代码分析不能容易地得到的，诸如交换的参数值、执行的路径和附加的被调用组件。然后使用所述静态模型和动态行为来建立结构图以生成计算程序的更完整的表示。

Description

跨动态边界的运行时分析的可视化

技术领域

本发明涉及创建软件的构架图的技术。

背景技术

软件所提供的功能变得越来越复杂。架构图(architectural diagram)被用于提供对于软件功能和/或结构的概观。有多种类型的用于软件的架构图。在这些架构图之中一般有一些对于软件组件的可视化呈现，和组件之间关系的一些可视化。统一建模语言(UML)是一种标准化的建模语言，且包括一组创建软件密集系统的可视化的图形标记技术。所述UML界定多个不同类型的架构图。

从历史看，架构图最初曾经被人工构建，其中作者绘出图来强调该软件的设计或需求。最近，使用了架构图的自动生成。这样的自动系统实现对源代码、中间代码和/或二进制码的静态代码分析。所述系统可以从静态代码分析得出信息，从该信息中可以得出代码的静态模型，所述静态模型表示了各软件的组件及其关系。从那个静态模型中，可以自动构建架构图。

发明内容

此处描述的至少一个实施例与带有多个组件的软件程序的架构图的建立(formulatoin)有关。标识组件中的至少一些以及组件之间关系的静态模型被访问。比如，软件程序的代码的静态代码分析可以展示出组件的标识和与组件间的关系相关的信息。还可以通过执行软件程序并观察所述执行来得出所述软件程序的动态行为，从而实现动态分析。这些动态行为可能并不能从静态模型中容易地理解。然后使用所述静态模型和动态行为来建立架构图以生成所述计算程序的更完整的表示。所述架构图可能可以被显示在显示器上用于人工解释。

本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

附图简述

为了描述可以获得上面所列举的及其他优点和特征的方式，下面将参考附图来呈现对各实施例的更具体的描述。可以理解，这些附图只描绘了样本实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加属性和细节来描述和解释各实施例，在附图中：

图1示出了可用于采用此处所描述的实施例的示例计算系统；

图2示出了可在其中实现计算机程序分析的环境；

图3示出了用于建立架构图的方法的流程图；

图4示出了仅由从静态代码分析得到的信息来构建的序列图。

图5修改了图4以包括从动态分析中得到的附加动态行为的表示，该动态行为的形式为在计算机程序的实际执行期间所遍历的执行路径的标识。

图6修改了图5以附加地表示与在计算机程序执行期间组件之间交换的参数的实际值相关的动态行为。

图7修改图5以进一步表示动态行为，该动态行为的形式为计算机程序执行期间所调用，但并非由计算机程序自身所定义的附加组件；

图8是用于描述定界试探方法(scoping heuristics method)的序列图；

图9是用于描述先行估计的试探方法的序列图；

具体实施方式

根据此处描述的实施例，描述了含有多个组件的软件程序的架构图的建立。通过可能是执行所述软件程序的静态代码分析来访问标识至少一些组件以及组件间关系的静态模型。还可以通过执行软件程序并观察所述执行来得出所述软件程序的动态行为，从而实现动态分析。这些动态行为可能或许不能从单独的静态模型中容易地理解，诸如交换的参数值、执行的路径和被调用的额外组件。然后使用所述静态模型和动态行为来建立架构图以生成所述计算程序的更完整的表示。

所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。从而，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变都被权利要求书的范围所涵盖。

首先，将参考图1来描述关于计算系统的某些介绍性讨论。然后，参考图2到图9来描述软件程序架构图的建立的实施例。

首先，参考图1来描述关于计算系统的介绍性讨论。计算系统现在越来越多地采取多种多样的形式。计算系统可以例如是手持式设备、电器、膝上型计算机、台式计算机、大型机、分布式计算系统，或者甚至通常不被视为计算系统的设备。在本说明书以及权利要求书中，术语“计算系统”被广义地定义为包括包含至少一个处理器以及其上能含有可由处理器执行的计算机可执行指令的存储器的任何设备或系统(或其组合)。存储器可以采取任何形式，并可以取决于计算系统的特性和形式。计算系统可以分布在网络环境中，并可包括多个组分计算系统。

如图1所示，在其最基本的配置中，计算系统100通常包括至少一个处理单元102和存储器104。存储器104可以是物理系统存储器，该物理系统存储器可以是易失性、非易失性、或两者的某种组合。术语“存储器”在此也可用来指诸如物理存储介质等非易失性大容量存储。如果计算系统是分布式的，则处理、存储器和/或存储能力也可以是分布式的。如此处所使用的那样，术语“模块”或“组件”可以指在计算系统上执行的软件对象或例程。此处所描述的不同组件、模块、引擎，以及服务可以实现为在计算系统上执行的对象或进程(例如，作为分开的线程)。

在随后的描述中，参考由一个或多个计算系统执行的动作描述了各实施例。如果这样的动作是以软件实现的，则执行动作的相关联计算系统的一个或多个处理器响应于已经执行了计算机可执行指令来引导计算系统的操作。这样的操作的示例涉及对数据的操纵。计算机可执行指令(以及被操纵的数据)可以存储在计算系统100的存储器104中。计算系统100还可包括可用于提供诸如此处所述客户界面之类的各种具体客户界面的显示器112。计算系统100还可包含允许计算系统100例如通过网络110与其他消息处理器通信的通信信道108。

本发明的各实施例可以包括或利用包括诸如一个或多个处理器和系统存储器的计算机硬件的专用或通用计算机，这将在以下做出进一步讨论。本发明范围内的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两种完全不同的计算机可读介质：计算机存储介质和传输介质。

计算机存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备、或可用于存储计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的任何其他介质。

“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一通信连接(硬连线、无线、或硬连线或无线的组合)传输或提供给计算机时，该计算机将该连接适当地视为传输介质。传输介质可包括可用于承载计算机可执行指令或数据结构形式的所需程序代码装置并可由通用或专用计算机访问的网络和/或数据链路。上述的组合也应被包括在计算机可读介质的范围内。

此外，在到达各种计算机系统组件之后，计算机可执行指令或数据结构形式的程序代码装置可从传输介质自动转移到计算机存储介质(或者相反)。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块(例如，“NIC”)内的RAM中，然后最终被传送到计算机系统RAM和/或计算机系统处的较不易失性的计算机存储介质。由此，应当理解，计算机存储介质可被包括在同样(或甚至主要)利用传输介质的计算机系统组件中。

计算机可执行指令例如包括，当在处理器处执行时使通用计算机、专用计算机、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言等中间格式指令、或甚至源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解的是，所附权利要求书中定义的主题不必限于上述特征或动作。相反，上述特征和动作是作为实现权利要求的示例形式而公开的。

本领域的技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可以在其中通过网络链接(或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合)的本地和远程计算机系统两者都执行任务的分布式系统环境中实践。在分布式系统环境中，程序模块可以位于本地和远程存储器存储设备中。

图2示出了可在其中实现计算机程序201的分析的环境200。所述计算机程序201可以自动地使用静态代码分析210或动态分析220而被分析。

在静态代码分析210中，检验模块211检验计算机程序的源代码、中间代码和/或二进制代码。从静态代码分析可以确定代码的静态模型。作为示例，软件程序201的多个组件可以与这些组件之间的多个关系一起被标识出来。比如，在图2中，探测模块211标识组件212A，212B和212C及其相应关系213A，213B和213C。静态代码分析可以用于建立计算机程序的静态模型而不论在所述计算机程序中的组件数量。静态代码分析在现有技术中是已知的。

在动态分析220中，计算机程序201实际上使用执行模块221(如，计算机处理器)而被执行。在本详细描述和在权利要求中，在动态分析的上下文中代码被“执行”还包括代码被模拟，在此情况下代码是在模拟器上，而不是在真实的机器上运行。由此，所述计算机程序的动态行为222可以由观察模块223观察到，从而藉此生成有关计算机程序201的附加动态信息224。

静态代码分析210和动态分析220可以由计算机可执行指令指导的计算系统来实现，所述计算机可执行指令存在于一个或多个计算机可读介质上。这样的计算机可读介质可以形成计算机程序产品。

图3示出了用于建立架构图的方法的流程图；方法300可以使用图2的环境200来执行。相应的，图3在此将会频繁参看图2来描述。

方法300包括对计算机程序的一组组件的标识和该一组组件之间关系的的访问(动作301)。通过这样作，方法300访问所述软件程序的静态模型。这个静态模型可以从所述软件程序的状态分析(动作311)(诸如静态代码分析210)的结果中得到。另选地或附加地，所述标识可以是手动产生的标识(动作312)。例如，编程者可以分析与计算机程序相关的代码和/或文档，借此标识软件程序中的至少一些组件和组件之间的关系。

另外，执行所述软件程序的动态分析(动作302)。所述动态分析(动作302)被示为与得到组件标识的动作(动作301)相平行，以强调本方法的实施例并不限于一个动作在另一个动作之后发生的实施例。动态分析标识所述软件程序的动态行为。动态行为可能不是从静态代码分析中可得到的信息，或者可能是单从静态代码中很难以得到的信息。

然后建立架构图(动作303)，该架构图结合静态模型和动态行为(动作303)。然后，架构图可以被显示(动作304)。如之前所提到的，根据此处描述的原理，此处并没有对所生成的架构图的类型作出限制。示例包括序列图和依赖图。

动态行为的示例将会在下文中结合图4到图7而提供，其中所述架构图为序列图。图4示出了由仅从静态代码分析得到的信息而构建的序列图。因此，图4仅表示了代码的静态模型。图5到图7示出将通过所述代码的动态分析得到的动态行为加到所述静态模型上的序列图。例如，图5修改了图4以包括动态行为，该动态行为的形式为在所述计算机程序的实际执行期间遍历的执行路径的标识。图6修改了图5以附加地包括与在计算机程序的执行期间组件之间交换的参数的实际值相关的动态行为。图7修改图5以进一步标识动态行为，其形式为在计算机程序的执行期间被调用，但并非由计算机程序自身所定义的附加组件。图4到图7中的每一个仅是使用此处描述的原理而生成的架构图的示例。使用此处描述的原理可以构建任何类型的架构图。

图4示出序列图400，其表示可仅基于静态代码分析而生成的示例序列图。静态代码分析标识出四个程序组件401、402、403和404。静态代码分析还标识出这些组件之间的关系。在一个序列图中，那些关系是函数调用和返回。

在图4中，静态代码分析显示出程序401发出调用“创建订单处理器(CreateOrderProcessor)”，其导致订单处理器(OrderProcessor)402的产生。订单处理器402执行其处理然后返回。

然后，程序401发出调用“下订单(PlaceOrder)”给订单处理器402。然后，订单处理器402发出“购买(Purchase)”调用到客户订单(CustomerOrder)403中，然后客户订单403返回。

可以如“如果(If)”框411所表示的那样实现一些条件逻辑。“如果”框411中流程执行的条件是购买(Purchase)调用是否成功地返回。如果成功了，则订单处理器402发出创建订单结果(Create OrderResult)调用，藉此导致订单结果(orderResult)404的产生，订单结果404然后返回。然后，购买成功(PurchaseSuccess)调用由订单处理器402发出至订单结果404中，然后订单结果404返回。如果所述条件没有被满足，则返回错误状态，如“如果”框411的否则(else)部分所清晰显示地那样。

一旦处理完成，订单处理器402将控制返回给程序401。再次重申，序列图400可以仅从静态代码分析中生成。

图5示出序列图500，其中图4的静态模型由从所述计算机程序的动态分析中得到的动态行为所补充。在这个情况中，动态信息是当执行计算机程序时使用的实际执行路径。在图5所示情况中，路径为分支，但是执行路径还可以是回路。执行路径在图5中使用交错箭头来表示。然而，颜色或其他可视化手段也可以被用于将实际执行路径与其他可能的执行路径区别开。

参看图5，实际执行路径由所述程序401的实例化开始。然后，创建订单处理器被调用以产生订单处理器402。返回后，则订单处理器402用“购买”方法来调用客户订单403。返回后，动态路径信息说明：在订单处理器402用“创建订单结果”方法调用订单结果404，以及订单处理器402随后调用“购买成功”方法此二步骤被实际执行之后，在“如果”框411中的特定条件应该已经被满足。在被动态分析所观察的执行期间，“如果”框411中“否则”部分所规定的的调用没有被执行。因此，可以观察实际执行路径，并与计算机程序的静态结构合并。

图6示出序列图600，其中图5进一步由从所述计算机程序的动态分析中得到的附加动态行为所补充。在这个情况下，动态行为是在调用中交换的参数的实际值。具体的，函数调用601由显示参数“订单Id”(orderId)的值是12的可视化611来补充。

图7示出序列图700，其中图5进一步由从所述计算机程序的动态分析中得到的附加动态行为所补充。在这个情况下，动态行为是计算机程序的执行期间被调用的实际外部模块的身份，以及被标识的与这些外部模块的交互。这些外部模块701和702可以是由静态代码难以标识或不可能标识的模块。例如，计算机程序，具体为客户订单模块403可能使用客户订单执行(CustomerOrderImplementation)模块701来对信用卡收费，该模块701又可能使用信用卡服务模块(CreditCardService)702来授权信用卡。

本说明书现在将会描述静态模型如何可与动态行为合并。此处将描述两个宽泛的分类，有关如何使用此处描述的原理来实现静态模型和动态行为的相关。第一个分类从在静态模型和动态行为之间映射程序执行流程的视角来解决这个问题。第二个分类从在静态模型和动态行为之间映射对象实例(序列图中的生命线)的视角来解决这个问题。

现在将描述在静态模型和动态行为之间映射程序执行流程的第一个分类。将动态行为匹配到静态模型上可能是非常有挑战的—不论从质(正确度)的方面还是从量(性能)的方面而言。取决于数据质量，能使用不同的算法。此处提到的所述算法使用这样的概念：跟随自动态行为中的事件开始通过静态模型的执行路径，并将动态事件链接到静态模型中的位置。

如果动态事件和静态模型已经足够详细以至于可能准确地将动态事件匹配到静态模型中的位置的话，那么仅跟随通过静态模型的执行路径并将动态事件匹配到静态模型位置的很直接的算法就足够了。

如果静态模型或动态事件不够详细的话，那么匹配动态事件到静态模型位置可能变得不明确。这样的不明确可能会有多种形式，诸如不能辨认哪个重载的(overloaded)方法被调用了，循环被迭代了多少次或者采用了条件的哪个分支。为解决这样的不明确，可使用各种算法和试探法。

一个这样的算法朴素地在所述静态模型的有限范围内搜索并应用试探法来决定执行如何通过静态模型继续。一旦决定作出，另一个在有限范围内的搜索发生，以此类推直到找出了通过所述静态模型的完整执行路径。这个算法可使用用于解决不明确(ambiguity)的更先进技术，诸如使用先行估计(look ahead)以确保接下来N个事件，而不仅仅是下一个事件能匹配到静态模型。

另一个更复杂的算法将该问题构思为类似于常规的表达匹配。静态模型定义了从中产生动态行为的模式(pattern)，问题是找到所述动态行为如何从所述静态模型中产生的推导。再次重申，试探法可以被用于解决一些类型的不明确。

现在将描述可被用在匹配算法中的六个试探法的示例。每一个可能被与另一个结合使用。

1.定界(scope)

将结合图8的序列图800而描述定界试探法的示例。一旦消息1在图中匹配，我们知道下一个消息必定发生在图8的虚线框部分801中。这样大幅地减少了需要被匹配的消息组。试探法不需要知道图中是否有另一个消息2，因为可能已经出现的唯一消息2就是所显示的那个。

2.消息/方法名称

在这个示例中，出现的方法的名称与图中的消息/方法的名称相匹配。这种简单的字符串匹配消除了大多数的选项，在一些情况下可能返回精确匹配。然而，如果不是如此，可使用接下来的试探法示例。

3.参数的数量

从消息/方法名称的试探法示例中得出的可能匹配的经过滤列表进一步使用方法的参数的数量来过滤。例如，考虑运行时跟踪(runtime trace)“method＝Foo(Param1，Param2)”{类型在这个示例中并不重要)。现在假设对于消息/方法名称的可能匹配的列表包括了如下四个可能的匹配：Foo(int)，Foo(int，string)，Foo(string，string)，和Foo(int，string，string)。将可能匹配的列表与运行时跟踪进行比较，可能匹配的列表可被进一步过滤到只有两个可能的匹配Foo(int，string)，Foo(string，string)。这是一个重要的中间步骤，因为这能在有大量重载的示例中进一步减少数据组。

4.类型

方法的调用(invocation)目标类型可被用于过滤匹配组。进一步地，参数的类型能被用于明确进一步的关系(tie)。返回类型能被用于再进一步地予以明确。

5.先行估计

将结合图9的序列图900而描述先行估计(look ahead)试探法的示例。参看图9，所述方法可以通过对在已经匹配的事件之后发生的事件进行匹配来过滤可能的选项。由于有两个消息2的发生，下一个消息被评估来看是否我们能找到匹配。如果该评估看到消息3接下来发生(如在图9中的情况)，那么该分析能推断采用哪个路径。可以通过基于数据量而减少先行估计的数量从而进一步优化该方法。这个方法还能被用于明确循环和条件。

6.确定在循环中放多少动态事件

最大适合规则(maximal munch rule)能被用于循环，所谓最大适合规则放置尽量多的动态事件到循环中。最大适合规则如下通过解析理论和工程(works)而得出。

假设如下代码被用于评估：

进一步假设代码遇到了来自动态数据的调用流：A，A，A，A，A，A，…。

在这个情况下，所述分析分配尽可能多的A给循环，并且可能使用先行估计试探法来计算出一个A(第六个A)要被保存下来以用于循环之后的调用。

回想映射静态模型到动态行为的第二个分类是在静态模型与动态行为之间映射对象实例。一个能用于在静态模型和动态动作之间连接对象实例的技术在此处被称为“对象标识符相关”。当静态模型被建立时，对象的实例被跟踪，不论用于指代所述对象的别名(可变名称)是什么。在动态分析期间，对象的实例也被跟踪。当在两个模型中的对象标识符系统相关时，对象实例以及在这些实例上的操作能在静态模型和动态行为之间被对齐。一个这样做的方法如下：

1.当建立静态模型时，确定对象实例并分配给每个实例唯一的标识符，使用该标识符而不论用于指代所述实例的别名(alias)是什么。

2.当从程序的执行中标识动态行为时，收集容许唯一地标识对象实例的信息。例如，对于带有不可移动的堆(heap)对象(例如，C++)的系统，跟踪对象实例的地址一般就足够了。对于带有按不同分类(garbage)收集的堆(例如，CLR)的系统，跨分类收集地跟踪对象实例，其中在堆空间被压缩时，这些对象实例可能被重新放置。

3.在执行动态分析时，使用在步骤2中收集的对象标识符以保持对象实例。

4.当模型被结合时，通过将在程序的执行中的已知点处的对象标识符进行同步来相关两个对象标识符系统。取决于所收集数据的级别，这可能位于每个指令、每个对象分配、每个函数中的模块、每个函数调用、每个函数进入点和/或每个函数返回点。使用以下的代码示例，如果id＝1的对象实例在静态模型的第4行产生，而动态模型中产生的对象id＝101，那么这两个标识符能被链接，然后，当其中一个标识符被看到的时候，静态模型和动态行为之间的对象实例可被映射。该技术容许在静态模型或动态行为中的稀疏记录/建模。比如，如果动态分析仅在每次创建对象并调用函数时记录数据，则静态模型和动态行为之间的相关性将会在那里同步(也就是，静态id1将会在第4行上被映射到动态id101)，且然后，如果作出动态函数调用(在静态模型中不可行，因为该调用是动态的)，则传递带有动态id101的对象，带有静态id1的对象实例将会被正确地相关，即便该信息在静态模型中并非是原始可得的(第12行)。

接下来是参考以上的代码示例。

相应的，此处描述的原理允许自动构建结合了在计算机程序的执行中得到的动态行为和静态模型的架构图，提供对于计算机程序的结构和操作的丰富呈现和直觉理解。本发明可被具体化为其他具体形式而不背离其精神或本质特征。所描述的诸实施例在各方面将仅被视为说明性的而不是限制性的。本发明的范围因此由所附的权利要求而不是由该以上描述来指示。落入权利要求的等价物的含义和范围的所有改变都包含在权利要求的范围内。

Claims (10)

1.一种计算机实现的方法，包括：

通过执行软件程序的静态代码分析来访问标识所述软件程序的一组组件中的至少一些组件以及所述组件间关系的静态模型的动作；

基于所述软件程序的执行进行动态分析以标识所述软件程序的动态行为的动作；和

自动建立架构图的动作，所述架构图将所述静态模型和由动态分析所标识的动态行为相结合，所述结合通过以下来实现：

1)在所述静态模型和所述动态行为之间映射程序执行流程；以及

2)在所述静态模型和所述动态行为之间映射对象实例。

2.根据权利要求1所述的方法，其特征在于，所述动态行为包括在所述计算机程序的执行期间在组件之间交换的参数的实际值。

3.根据权利要求1所述的方法，其特征在于，所述动态行为包括在所述计算机程序的执行期间所遍历的执行路径的标识。

4.根据权利要求1所述的方法，其特征在于，所述动态行为包括在所述计算机程序的执行期间被调用，但并不是所述计算机程序所定义的附加组件。

5.如权利要求1所述的方法，其特征在于，所述架构图是序列图。

6.如权利要求1所述的方法，其特征在于，所述架构图是依赖图。

7.根据权利要求1所述的方法，其特征在于，访问软件程序的一组组件的标识以及该组组件之间的关系的动作包括：

访问所述一组组件的手动生成的标识以及该组组件之间的关系的动作。

8.根据权利要求1所述的方法，其特征在于，所述计算机可执行指令进一步被构造从而所述计算机系统进一步执行下述动作:

显示自动生成的架构图的动作。

9.一种计算机实现的方法，包括：

基于对计算机程序的代码的检查或知晓来访问所述计算机程序的静态代码分析的结果的动作；

通过执行所述计算机程序的静态代码分析来访问标识所述计算机程序的一组组件中的至少一些组件以及所述组件间关系的静态模型的动作；

基于所述计算机程序的执行进行动态分析以标识所述计算机程序的动态行为的动作；和

自动建立架构图的动作，所述架构图将所述静态模型和从动态分析所标识的动态行为相结合，所述结合通过以下来实现：

1)在所述静态模型和所述动态行为之间映射程序执行流程；以及

2)在所述静态模型和所述动态行为之间映射对象实例。

10.一种计算机实现的系统，

用于访问标识软件程序的一组组件以及该组组件之间的关系的静态模型的装置；

用于基于所述软件程序的执行进行动态分析以标识所述软件程序的动态行为的装置；和

用于自动建立架构图的装置，所述架构图将所述静态模型和由动态分析所标识的动态行为相结合，所述结合通过以下来实现：

1)在所述静态模型和所述动态行为之间映射程序执行流程；以及

2)在所述静态模型和所述动态行为之间映射对象实例。