CN102236549B

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

Info

Publication number: CN102236549B
Application number: CN201110106238.9A
Authority: CN
Inventors: S·杜塔; B·克劳福德
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2010-04-20
Filing date: 2011-04-18
Publication date: 2016-04-13
Anticipated expiration: 2031-04-18
Also published as: US8522217B2; CN102236549A; US20110258611A1

Abstract

通过将运行时和静态信息进行相关来导出增强软件体系结构图表，从而允许执行图表跨越运行时确定边界。运行时确定边界由在运行时作出的决策来定义，例如客户机-服务器边界、机器-机器边界、数据库-查询程序边界、web服务提供者-消费者边界、工厂调用程序-实例边界、接口调用-实现类边界、以及反射边界。相关可以涉及例如标识类型的实例、跟踪注入到通信信道的标识符、使用因果关系挂钩、和/或将离开调用程序的消息与进入被调用程序的消息进行比较。

Description

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

背景

各种工具和技术被用于计算机程序分析。部分或完全自动化的程序分析可以帮助进行程序优化、程序验证、程序实现(初始创建和/或后续修改)、程序缺陷检测、程序移植(porting)、以及其他努力。在分析计算机程序的行为时，给定方法可以检查和/或利用类型系统、源代码注释、模型检验、体系结构图表、性能配置文件(profile)、探测工具(instrumentation)、程序切片、继承/依存关系图、和/或其他工具和技术。

在程序分析中采用的两种不同的方法是动态程序分析和静态程序分析。动态程序分析是通过在真实和/或虚拟处理器上执行程序来执行的。可以选择测试输入以产生感兴趣的程序行为来进行动态分析；在一些情况下，也可使用来自实况生产服务器的输入。诸如代码覆盖等技术可以帮助确保获得被测试的程序的可能行为的代表性样本。然而，用来获得动态测试数据的探测工具可以更改被测试程序的执行速度和/或其他特性。静态代码分析是在不执行被分析的程序的情况下执行的。静态分析可以针对源代码、中间代码或其他目标代码、或这两者执行。例如，静态分析的深度和广度在只考虑各单独语句和声明的分析与考虑程序的完整源代码的分析之间变化。

概述

一些软件应用程序对提供不同角色、使用不同的技术、来自不同的供应商、和/或在其他方面彼此不同的片段进行组合。结果，可以定义软件应用程序的各部分之间的边界。然而，用来生成体系结构图表的分析工具通常不能自动地跨越这些边界，因而开发人员缺少可帮助改进或改编该应用程序的信息。

本文描述的一些实施例提供用于使用运行时所生成的数据来将各软件体系结构图表进行相关以提供横跨运行时确定边界的增强体系结构图表的一种或多种方法。“运行时确定边界”是在体系结构中至少部分地由在运行时作出并且因此不服从纯粹静态程序分析的决策所定义的边界。运行时确定边界的一些示例包括客户机-服务器边界、机器-机器边界、数据库-查询程序边界、web服务提供者-消费者边界、工厂调用程序-实例边界、接口调用-实现类边界、以及反射边界。

本文提供的一些方法定位软件体系结构中的运行时确定边界，获取程序(即软件体系结构的实例)的执行的运行时信息，以及将该运行时信息与静态软件体系结构图表进行相关。例如，运行时信息可以与顺序图表、分层图表、活动图表、类图表、和/或依存关系图表相关。相关可以通过例如标识类型的实例、通过跟踪注入到通信信道的标识符、通过使用因果关系挂钩、和/或通过将离开调用程序的消息与进入被调用程序的消息进行比较来实现。

本文描述的方法产生对跨运行时确定边界的执行历史进行记录(document)的增强体系结构图表。程序随后可被再次执行，并且可以产生第二增强体系结构图表以记录跨运行时确定边界的第二执行历史。这两个增强体系结构图表的比较可帮助开发人员更好地理解该程序。类似地，可以执行该程序的不同版本，并且该运行时信息可以被用来产生横跨运行时确定边界的另一增强体系结构图表。元数据也可被附加到数据源并且跨运行时确定边界来传播。

给出的示例仅是说明性的。本概述并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于限定所要求保护的主题的范围。相反，提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的某些概念。本发明用权利要求书来定义，且在本概述与权利要求书冲突的情况下，应以权利要求书为准。

附图说明

将参考附图来给出更具体的描述。这些附图仅示出了所选方面，且因此未完全确定覆盖或范围。

图1是示出具有至少一个处理器、至少一个存储器、诸如应用程序等软件体系结构的至少一个实例并具有可存在于多个网络节点上的操作环境中的其他项的计算机系统并且还示出配置的存储介质实施例的框图；

图2是示出用于将软件体系结构的静态信息和运行时信息进行相关的示例方法的示图；

图3是示出一些过程的步骤和配置的存储介质实施例的流程图；

图4示出适于进行本文所教导的相关的静态体系结构图表的示例；

图5示出适于进行本文所教导的相关的、图形式的静态体系结构的示例；

图6示出通过将运行时信息与图4的静态体系结构图表进行相关来产生的增强体系结构图表；

图7示出跨运行时确定边界的增强体系结构图表，它是通过将运行时信息与图4的静态体系结构图表以及其他静态信息进行相关来产生的；以及

图8示出跨运行时确定边界的增强体系结构图表，它是通过将运行时信息与图形式的静态信息进行相关来产生的。

具体实施方式

概览

当前软件应用程序使用各种技术和方法来帮助解除给定应用程序的各部分的耦合。解耦技术/方法的一些示例包括web服务以及其他远程过程/调用技术、数据库调用、以及工厂模式。本文还描述了和/或开发人员也熟悉解耦组件的其他示例。解耦创建应用程序的各部分之间或不同的应用程序之间的明确定义的一组边界。在运行时通过诸如订单处理组件调用外部信用卡处理服务、库存系统调用库存数据库以检索数量信息、基于系统配置来创建图形用户界面(GUI)等动作以及许多其他动作，跨越这些边界。

为了理解该应用程序以使得它可被改进或维护，从现有应用程序生成体系结构图表通常是有用的，并且有时是至关重要的。然而，生成这样的图表通常因为上述边界而不完整。用来生成这些图表的静态分析工具没有适当的方式来自动地跨越这些系统边界并将结果进行记录。例如，在以上示例中的第一示例中，静态图表将示出订单处理系统内的所有调用，但没有示出对信用卡处理服务的调用及其后续处理。同样，在第二示例中，静态图表将示出库存逻辑，但不能示出数据库调用和任何后续处理。在第三示例中，代码的静态分析将不足以完全描绘创建哪一GUI。

本文描述的一些实施例提供一组特征，该组特征便于并支持生成跨经解耦的系统边界的体系结构图表。这些特征可以在开发工具中提供，如VisualTeamSystem解决方案的一个版本，以及其他已授权工具(微软公司的标记)。这些特征中的一些包括对正在运行的应用程序的动态记录和跟踪、对应用程序的源代码的静态分析(例如，从源代码生成顺序图表)、探测现有代码来产生运行时踪迹、能够将以上踪迹归并成一个数据图的分析引擎、以及使用这样的数据图来生成增强体系结构图表。

各对应能力的一些示例在以下场景中示出。用户参与对要被分析的应用程序的一些或所有部分的动态记录。用户运行该应用程序以提供运行时数据以供分析。在运行该应用程序时，一实施例生成适当的日志和踪迹。这些踪迹可包含标识符，例如类型、方法、以及服务的统一资源标识符(URI)和其他ID。或者，可从对应用程序执行的仿真收集运行时数据的部分或全部，例如通过在硬件或软件仿真器上运行该应用程序。如本文所使用的，“执行”以产生运行时数据包括两种可能性，即实况执行和/或仿真执行。分析引擎构造踪迹和/或其他运行时数据的数据图，并使用标识符将跨系统边界的调用缝合在一起。该实施例使用数据图来构造增强体系结构图表，例如与运行时信息相关并且由该运行时信息在视觉上增强的顺序图表。

一些实施例为诸如类型、方法、以及这些方法之间的调用等应用程序人工产物提供公共寻址方案。这一寻址方案可由静态和动态分析代码来共享。一些实施例提供使用该共享的寻址方案来将这些多个图链接在一起的过程。在自动化链接不可能的情况下，一些实施例帮助用户将这些各种人工产物缝合在一起。

现在将参考诸如附图中示出的示例性实施例，且此处将使用具体语言来描述这些实施例。但是相关领域且拥有本发明的技术人员将想到的、此处所示的特征的更改和进一步修改以及此处所示的原理的其他应用应被认为是在权利要求书的范围内。

各术语的意义在本发明中阐明，因此权利要求书应仔细注意这些阐明来阅读。给出了具体示例，但是相关领域的技术人员将理解，其他示例也落入所使用的术语的意义内，且在一个或多个权利要求的范围内。各术语不必在此具有与其一般使用中、特定行业的使用中、或特定字典或字典集的使用中相同的意义。与各种措辞一起使用附图标记来帮助显示术语的宽度。给定一段文本中省略附图标记并不一定意味着该附图的内容没有被该文本讨论。发明人声称并行使其对于其自己的词典编纂的权利。各术语此处可在详细描述和/或申请文件的别处显式或隐式地定义。

如本文所使用的，“计算机系统”可包括例如一个或多个服务器、主板、处理节点、个人计算机(便携式或非便携式)、个人数字助理、蜂窝或移动电话、和/或提供至少部分地由指令控制的一个或多个处理器的其他设备。指令可以采用存储器和/或专用电路中的软件的形式。具体而言，尽管可以想到许多实施例在工作站或膝上型计算机上运行，但其他实施例可以在其他计算设备上运行，且任何一个或多个此类设备可以是给定实施例的一部分。

“多线程化”计算机系统是支持多个执行线程的计算机系统。术语“线程”应被理解为包括能够或经历同步的任何代码，并且可用另一名称来称呼，如“任务”、“过程”或“协同例程”。线程可以并行地、顺序地、或以并行执行(例如，多处理)和顺序执行(例如，时间片)的组合来运行。以各种配置设计了多线程化环境。执行线程可以并行地运行，或者线程可以被组织供并行执行但实际顺序地轮流执行。多线程化可以例如通过在多处理环境中在不同核上运行不同线程、通过对单个处理器核上的不同线程进行时间分片、或通过时间分片和多处理器线程化的某种组合来实现。线程上下文切换可以例如由内核的线程调度器、由用户空间信号、或由用户空间和内核操作的组合来发起。线程可轮流在共享数据上操作，或者每一线程可以例如在其自己的数据上操作。

“逻辑处理器”或“处理器”是单个独立的硬件线程处理单元。例如，每一个核运行两个线程的超线程化四核芯片具有8个逻辑处理器。处理器可以是通用的，或者它们可以针对诸如图形处理、信号处理、浮点算术处理、加密、I/O处理等特定用途来定制。

“多处理器”计算机是具有多个逻辑处理器的计算机系统。多处理器环境以各种配置出现。在一给定配置中，所有处理器可以在功能上是等价的，而在另一配置中，某些处理器可以借助具有不同硬件能力、不同软件分配或两者而不同于其他处理器。取决于配置，处理器可在单个总线上彼此紧耦合，或者它们可以是松耦合的。在某些配置中，处理器共享中央存储器，在某些配置中它们各自具有其自己的本地存储器，且某些配置中存在共享和本地存储器两者。

“内核”包括操作系统、系统管理程序、虚拟机、以及类似的硬件接口软件。

“代码”意味着处理器指令、数据(包括常量、变量和数据结构)或指令和数据两者。

“自动”意味着通过使用自动化(例如，由软件针对此处讨论的具体操作配置的通用计算硬件)，与不使用自动化相对。具体而言，“自动”执行的步骤并不是在纸张上用手执行或在人的脑海中执行的；它们是用机器来执行的。

贯穿本文，对任选的复数的使用意味着存在一个或多个所指示的特征。例如，“(诸)图表”意味着“一个或多个图表”或等效于“至少一个图表”。

贯穿本文，除非明确地另外规定，否则对过程中的步骤的任何引用假定该步骤可以由感兴趣的一方直接执行和/或由该方通过干预机器和/或干预实体来间接执行，且仍在该步骤的范围内。即，感兴趣的一方对步骤的直接执行并不是必需的，除非直接执行是明确规定的要求。例如，涉及感兴趣的一方的诸如向目的地“传送”、“发送”或“传递”等动作的步骤可涉及某一其他方的诸如转发、复制、上传、下载、编码、解码、压缩、解压、加密、解密等居间动作，但仍被理解为由该感兴趣的一方直接执行。

只要参考了数据或指令，就理解这些项目配置了计算机可读存储器，从而将其变换为特定物品，而非简单地存在于纸张上、人的脑海中、或作为例如线路上的瞬时信号。

操作环境

参考图1，用于一个实施例的操作环境100可包括计算机系统102。计算机系统102可以是多处理器计算机系统，也可以不是。操作环境可包括给定计算机系统中的一个或多个机器，它们可以群集的、客户机-服务器联网的、和/或对等联网的。

人类用户104可以通过使用显示器、键盘和其他外围设备106来与计算机系统102交互。系统管理员、开发人员、工程技术人员、以及最终用户各自都是特定类型的用户104。代表一个或多个人来行动的自动化代理也可以是用户104。存储设备和/或联网设备在某些实施例中可被认为是外围设备。图1中未示出的其他计算机系统可以使用经由例如网络接口设备到网络108的一个或多个连接来与计算机系统102或与另一系统实施例交互。

计算机系统102包括至少一个逻辑处理器110。如其他合适的系统等计算机系统102还包括一个或多个计算机可读非瞬态存储介质112。介质112可以是不同的物理类型。介质112可以是易失性存储器、非易失性存储器、固定在原处的介质、可移动介质、磁介质、光介质、和/或其他类型的非瞬态介质(与诸如仅传播信号的线路等瞬态介质形成对比)。具体地，诸如CD、DVD、记忆棒或其他可移动非易失性存储介质等配置的介质114在被插入或以其他方式安装时可以变为计算机系统的功能部分，从而使得其内容可被存取来供处理器110使用。可移动的配置的介质114是计算机可读存储介质112的一个示例。计算机可读存储介质112的某些其他示例包括内置RAM、ROM、硬盘、和不可由用户104容易地移动的其他存储设备。

介质114用可由处理器110执行的指令116来配置；“可执行”在此以宽泛的意义使用来包括机器代码、可解释代码、以及在例如虚拟机上运行的代码。介质114还用通过指令116的执行创建、修改、引用和/或以其他方式使用的数据118来配置。指令116和数据118配置它们所在的介质114；当该存储器是给定计算机系统的功能部分时，指令116和数据118还配置该计算机系统。在某些实施例中，数据118的一部分代表了诸如产品特性、库存、物理测量、设置、图像、读数、目标、量等的真实项目。如本文讨论的，这样的数据也被转换，例如通过相关、注入、标记、跟踪、视觉化、导出、绑定、开发、执行、修改、显示、创建、加载、和/或其他操作。

软件体系结构120对软件应用程序的组件、依存关系、动作、交互、结果、和/或其他方面进行记录，该软件体系结构120本身可以是其他软件应用程序的一部分或包括其他软件应用程序。记录可包括用统一建模语言和/或用其他格式编写的体系结构图表122、以及例如手册、版本历史、说明书、和/或部分和完整实现的形式的体系结构实例124。给定实例124通常包括源代码和/或目标代码126、类型128的可解析定义和实现、通信信道130的可解析定义和实现、数据源132的可解析定义和实现、以及软件开发的其他常见事件。图中示出的以软件体系结构实例124、其他软件、以及其他项作为形式的应用程序可部分或整个地驻留在一个或多个介质112内，从而配置这些介质。例如，操作环境也可以包括显示器134，以及其他硬件，例如，总线、电源、和加速器。

给定操作环境100可包括集成开发环境(IDE)136，其向开发人员提供了一组协调的软件开发工具。具体而言，对于一些实施例，合适的操作环境中的一些包括或帮助创建被配置成支持程序开发的Visual开发环境(微软公司的标记)。一些合适的操作环境包括环境(SunMicrosystems公司的标记)，并且一些操作环境包括利用诸如C++或C#(“C-Sharp”)等语言的环境，但本文的教导适用于各种各样的程序设计语言、程序设计模型、以及程序，以及一般适用于使用静态程序分析、动态程序分析、或这两者的努力。

一些项目在图1中以轮廓形式示出以强调它们不是所示操作环境的必需部分，但可以与在此讨论的操作环境中的项目进行互操作。在任何附图或任何实施例中，不能得出不采用轮廓形式的项目就一定是不需要的。

系统

图2示出适于与一些实施例一起使用的静态-动态相关的一些方面。如本文所教导的，相关工具202将静态和动态信息进行相关以产生增强体系结构图表204。增强体系结构图表204可以横跨“运行时确定边界”206(即，暗示在运行时作出的决策的边界)，并且因此不容易服从纯粹静态程序分析。增强体系结构图表204可以将与诸如体系结构图表216和静态分析所产生的图218等静态结构214相关的执行历史208(例如，代码路径212、变量值)和/或其他运行时信息210(例如，版本信息、所加载的动态库)视觉化。诊断元数据220也可被利用，并且可能被显示在增强体系结构图表204中。通过相关工具202而非通过正常执行所分析的应用程序来生成元数据220和/或将元数据220附加到数据源132。

参考图1和2，一些实施例提供了具有逻辑处理器110和存储器介质112的计算机系统102，该存储器介质由电路、固件和/或软件来配置以如此处所描述的通过将静态和运行时信息进行相关来对它们进行变换。在一些实施例中，能与逻辑处理器进行通信的存储器保持增强体系结构图表204。图表204通过驻留在存储器中来对存储器进行配置。增强体系结构图表204至少对应用程序222的执行历史208进行记录，即对软件体系结构120的实例124进行记录。具体而言，图表204对应用程序的跨运行时确定边界206的执行历史进行记录。

在给定实施例中，增强体系结构图表204可包括并横跨以下运行时确定边界206中的至少一个：客户机-服务器边界、机器-机器边界、数据库-查询_程序边界、web_服务_提供者-web_服务_消费者边界、工厂_调用程序-工厂_实例边界、接口_调用-实现_类边界、反射边界；在此使用“-”只是为方便起见，帮助对描述边界206的不同各方的文本进行视觉标识。增强体系结构图表204可包括以下软件体系结构图表中的一个或多个：顺序图表、分层图表、活动图表、类图表、依存关系图表。

在一些实施例中，增强体系结构图表204包括与来自执行历史的运行时信息相关的突出显示的代码路径212。例如，图6示出增强图表204，其中代码路径212使用编号和增加的线宽来突出显示。虽然图6示例中未示出，但在一些实施例中，图表204包括用于向用户示出跨越运行时确定边界206所采取的实际代码路径212的突出显示。相关工具202可被用来对边界206进行桥接。图表204可通过将静态和运行时分析结果进行组合来构建。代码路径212可以与运行时信息相关。

在某些实施例中，诸如人类用户I/O设备(屏幕、键盘、鼠标、图形输入板、话筒、扬声器、运动传感器等)等外围设备106将存在，以用于与一个或多个处理器110和存储器进行通信。然而，一实施例还可被深嵌入在系统中，使得没有人类用户104直接与该实施例交互。软件进程可以是用户104。

在某些实施例中，该系统包括通过网络连接的多个计算机。联网接口设备可使用诸如例如存在于计算机系统中的分组交换网络接口卡、无线收发机、或电话网络接口等组件来提供对网络108的接入。然而，一实施例也可通过直接存储器存取、可移动非易失性介质、或其他信息存储-检索和/或传输方法来通信，或者计算机系统中的一实施例可以在不与其他计算机系统通信的情况下操作。

过程

图3以流程图300示出了某些方法实施例。在某些实施例中，附图中所示的过程可以例如，由在脚本控制下的相关工具202、IDE136和/或其他软件来自动，执行，需要极少或不需要用户输入。各过程可以部分地自动执行，且部分地手动执行，除非另外指明。在给定实施例中，可以重复一过程的零个或多个所示步骤，可能对不同参数或数据进行操作。一实施例中的各步骤也可按与图3中列出的从上到下次序不同的次序来完成。各步骤可以串行地、以部分重叠的方式、或完全并行地执行。遍历流程图300来指示在一过程期间执行的步骤的次序可以在过程的一种执行与过程的另一种执行之间变化。流程图遍历次序也可在一个过程实施例与另一过程实施例之间变化。各步骤可被省略、组合、重命名、重组合、或采用其他方式，而不脱离所示流程，只要所执行的过程是可操作的且符合至少一个权利要求。

此处提供了各示例来帮助说明该技术的各方面，但是本文中给出的示例并未描述所有可能的实施例。各实施例不限于此处提供的具体实现、排列、显示、特征、方法或情形。给定实施例可以例如包括另外的或不同的特征、机制和/或数据结构，并且还可另外脱离此处提供的示例。

在边界定位步骤302，一实施例定位运行时确定边界206。例如，可以使用一些静态分析工具、通过GUI的用户输入、运行时信息、和/或其他机制来实现步骤302。

在运行时信息获取步骤304，一实施例获取运行时信息210，例如通过在文件或RAM中定位该信息。例如，可以使用剖析器、探测工具、其他动态分析工具、通过GUI的用户输入、和/或其他机制来实现步骤304。

如本文讨论的，在相关步骤306期间，一实施例将诸如静态结构214等静态分析信息与运行时信息210进行相关。可以使用例如类型实例标识的结果、“染色”注入的结果、消息比较的结果、和/或本文所述的其他技术的结果来实现步骤306。

在相关步骤306，给定实施例可以使用一个或多个直接相关336、间接相关338、和/或用户标识的相关340。这些类别在此是为方便起见提供的，在此讨论的技术的其他视图可以对特定相关工具和技术进行不同的分类。

记住，用户标识的相关340是用户标识的并且随后可被用来与静态图表缝合在一起的各体系结构组件之间的运行时连接。在一些实施例中，用户可以使用一组技术来标识跨边界206的相关340。一种技术将跨体系结构图表的各视觉元素进行相关。

例如，用户可以选择一个顺序图表上的PlaceOrder(下订单)方法，并使用用户界面视觉姿势将它链接到另一个图表上的SubmitOrder(提交订单)方法。这一用户标识的相关340随后可被用来将两个图表直接缝合在一起，并影响基于运行时的分析来生成在后继生成时已将这两种方法链接在一起的图表。

另一种技术将源代码中的各项进行相关。例如，通过使用源代码中的一组属性，用户可以指示PlaceOrder方法间接调用SubmitOrder方法。这一用户标识的相关340随后将被用来生成其中自动发生缝合的图表。

又一种技术使用相关340中的用户定义的模式来将各项进行相关。例如，用户可以输入一模式，该模式指示如果每一次分析都检测到对接口OrderStrategy(订单策略)的调用，则该分析应当将该接口与使用诸如“AsyncOrderStrategy(同步订单策略)”等名称匹配*OrderStrategy(*是词汇通配符)的对指定系统中的任何类的任何PlaceOrder调用进行链接。

又一种技术将兴趣集中于指定存储区域或设备，例如存储器或数据库。例如，用户可以将数据库中的OrderItem(订单项)表标记为用户标识的相关340的一部分，使得在分析发现改变该表的两个分开的调用的情况下，该分析将这些调用进行相关。

间接相关338是各组件通过“第三方”(通常是数据存储)组件彼此交互的方式。例如，如果组件A将一订单条目记录写入数据库，并且组件B取回该订单条目来履行订单，则组件A和B的静态图表可被连接。在一些情况下，数据库的静态图表还可作为增强体系结构图表204的一部分来连接。数据存储跟踪是间接相关338技术，它可如下地进行。当组件A在运行时存储数据时(在存储器存储、文件存储、数据库存储、或任何其他数据存储介质112中)，该数据可被加标签、染色、或以其他方式标识其源。当组件B在运行时取回数据时，可以确定A与B之间的关联。另外，可以确定A、B与数据存储之间的关联。

直接相关336工具和技术的若干示例在以下讨论，即，类型标识、标识符跟踪、因果关系挂钩、消息内容比较、消息时间比较。直接相关技术的另一示例是通信基础结构跟踪：在两个组件之间的通信机制的给定实现是内置跟踪时，该内置跟踪输出(在运行时创建)可被用来连接各静态图表。

在边界类别确定步骤308期间，一实施例确定与所定位的边界206一致的至少一个类别336。给定边界可以与一个以上类别一致，例如边界可以既是web提供者-消费者边界又是机器-机器边界。可以使用静态信息来对一些边界进行分类，例如，如果静态分析标识数据库查询，则该边界可被假定为数据库-查询程序边界。一些边界可由开发人员通过GUI手动进行分类。

也可从运行时信息标识一些边界。例如，考虑具有web客户机和web服务器的系统。从在简单对象访问协议(SOAP)请求离开客户端应用程序并随后进入服务器应用程序时捕捉的运行时信息中，可以作出相关306和运行时边界的分类化。在这种情况下，边界可被置于web服务消费者-提供者类别。进程间通信提供另一示例。在将消息写到信道(套接字、管道，等等)时和在从信道读取消息时，可以捕捉运行时信息，相关和分类化可被完成。在这种情况下，边界可被置于进程间通信类别。

在体系结构表示步骤310，一实施例通过获取、准备、显示、和/或以其他方式利用软件体系结构图表来表示软件体系结构120。取决于上下文，所讨论的图表可以是静态图表122或增强图表204。

在图表比较步骤312期间，一实施例比较两个或更多个增强体系结构图表204。与本文讨论的一些其他步骤一样，比较步骤312可以从系统观点或用户观点来看待。即，取决于上下文，比较312可由在工具202的控制下(使用处理器110和存储器)自动地比较图表204的系统来完成，和/或比较312可由操作工具202的用户104完成。取决于实施例和开发人员的指令，可以比较增强图表的任何方面。例如，实际代码路径212、边界206处的数据值、边界206的交叉/非交叉、和/或动态地加载的组件可被比较312。

在元数据附加步骤314期间，一实施例(或指导一实施例的用户)将元数据202附加到应用程序数据源132。元数据可以采取属性、消息、消息内容附录、标识符、和/或其他数据的形式，该元数据在应用程序222的正常执行中不存在而是改为出于诊断的目的来附加的。可以使用常见的动态分析工具和技术来附加元数据。

在类型标识步骤316期间，一实施例标识一个或多个类型128实例。将应用程序的不同部分中的类型实例进行匹配可以在相关306期间执行，以帮助使用运行时信息210(即，运行时确定的类型实例)来将各静态图表122缝合在一起。步骤316可以使用解析、表查找、和/或其他常见机制来完成。

在标识符跟踪步骤318期间，工具202从应用程序中的一个位置到另一位置来跟踪被工具202注入到通信信道130流的标识符。注入的标识符可被看作元数据220的示例。可以在相关306期间执行在注入的标识符行进到应用程序的各不同部分时对该注入的标识符的跟踪，以帮助使用运行时信息210(即，标识符跨越边界206时的路径)来将各静态图表122缝合在一起。标识符注入在本文中有时被称为“染色注入”，并且可以使用常见机制来实现。

在使用因果关系挂钩步骤320期间，一实施例在相关306期间使用因果关系挂钩338。步骤320可以使用例如美国专利第7293256号中提供的教导来实现，该专利通过这一引用结合于此。

在消息内容比较步骤322期间，一实施例将调用程序处的消息内容与被调用程序处的消息内容进行比较，以帮助在相关306期间通过使用运行时信息210(即，消息跨越边界206时的路径)来将各静态图表122缝合在一起。内容比较可以帮助将消息彼此区分，从而使得跟踪给定消息的路径成为可能。

在消息时间比较步骤324期间，一实施例将调用程序处的消息时间与被调用程序处的消息时间进行比较，以帮助在相关306期间通过使用运行时信息210(即，消息跨越边界206时的路径)来将各静态图表122缝合在一起。由关于传输等待时间的实验数据或假设来进行补充的时间比较可帮助将消息彼此区分，从而使得跟踪给定消息的路径成为可能。

在静态结构获取步骤326期间，一实施例获取静态体系结构214，例如通过在网络中、在本地文件系统中、或在RAM中找出该结构。例如，如果工具202生成静态图表122，则步骤326可以使用由相关工具202生成的文件名或其他URI来实现。即使工具202与先前由与工具202不同的某一软件生成的静态图表一起工作，步骤326也可使用来自用户104的输入来实现。

在增强体系结构图表导出步骤328期间，一实施例从静态信息和运行时信息导出增强体系结构图表204。导出步骤328一般对应于相关步骤306，而不管术语方面的差异。在此使用两个术语来帮助说明所提供的教导的不同方面。具体而言，“相关”可被理解为强调如何导出增强图表204，而“导出”可被理解为强调在增强图表204中什么被相关。

在视觉呈现步骤330期间，一实施例在视觉上呈现增强图表204，例如通过将图表204显示在显示器134上或打印输出。

在元数据位置指示步骤332期间，一实施例指示例如在视觉呈现步骤330期间元数据220的应用内的一个或多个位置。所指示的元数据可被附加到数据源，和/或例如可以是被跟踪318的注入的标识符。描述图表的某一方面的元数据可以来自各种源，例如，用户、其他代码分析工具、其他描述或文档。

在存储器配置步骤334期间，存储器介质112由相关工具202、增强体系结构图表204、或以其他方式结合本文讨论的静态-运行时信息相关来配置。

上述步骤及其相互关系在下文中结合各种实施例来更详细地讨论。

一些实施例提供使用运行时生成的数据来将各软件体系结构图表进行相关的过程。该过程利用设备中的能与至少一个逻辑处理器进行通信的存储器。该过程包括定位302软件体系结构中的运行时确定边界206。软件体系结构至少部分地由至少一个软件体系结构图表122来表示310(例如，由顺序图表、分层图表等表示)。该过程获取针对304软件体系结构的实例124的至少一个执行的运行时信息210(函数级和/或其他)，并将运行时信息的至少一部分与至少一个软件体系结构图表进行相关306。该过程随后产生对跨运行时确定边界的执行历史进行记录的增强体系结构图表204。

在一些实施例中，定位步骤302确定308运行时确定边界适合以下类别336中的至少一个类别：客户机-服务器边界、机器-机器边界、数据库-查询_程序边界、web_服务_提供者-web_服务_消费者边界、工厂_调用程序-工厂_实例边界、接口_调用-实现_类边界、反射边界。然而，这些不一定是仅有的可能边界206。也可使用不同的边界类别206。运行时确定边界类别的一些其他示例包括：订单处理组件-外部信用卡处理服务边界、库存系统-库存数据库边界、GUI创建程序-系统配置边界、由利用最终用户所选择的数据库的代码所定义的边界、以及由利用从数据库中查找端点的web服务的代码所定义的边界。给定边界206可以属于一个或多个类别336。

在一些实施例中，该过程比较312两个或更多个图表204。例如，一个过程包括以上定位、获取、以及相关步骤，并且还包括获取针对304软件体系结构的同一实例的另一执行的运行时信息，将该运行时信息的至少一部分与至少一个软件体系结构图表进行相关306，从而产生对跨运行时确定边界的执行历史进行记录的另一增强体系结构图表，并随后比较312这两个增强体系结构图表。作为另一示例，一个过程包括以上的原始定位、获取、以及相关步骤，并且还包括获取304软件体系结构的不同实例的执行的运行时信息，将该运行时信息的至少一部分与至少一个软件体系结构图表进行相关306，从而产生对跨运行时确定边界的执行历史进行记录的另一增强体系结构图表，并随后比较312这两个增强体系结构图表。

常见机制可被用于静态分析，以将元数据附加到体系结构图表或程序图的各节点，并使用该数据来进行静态确认。然而，在本文提供的一些实施例中，一过程将元数据220附加314到数据源132，并且执行元数据跨运行时确定边界206的传播。例如，一过程可将元数据附加到数据源来指示332信任其中的数据的位置。

更一般地，取决于开发人员想要知道关于被分析的程序的什么信息，所附加314的元数据220的类型可以广泛变化。元数据可以指示数据的源以及该源是否可被信任。元数据可以指示关于数据的值的一些事情，例如它是否为空(例如，基于用于空的条件块测试)。元数据可以指示与分配数据的方式有关的一些事情，例如它是被垃圾收集的还是需要被消费者显式地释放。与其中分析不跨越运行时边界的纯粹静态空间不同，一些实施例跨越边界206将所附加的元数据携带到没有静止地连接的第二体系结构图表/程序图。一旦使用运行时信息通过相关将各图表进行了连接，则可以将该元数据附加到图表/图中的节点并将其跨越运行时边界206流传送。

在一些实施例中，可以使用所附加的元数据来检测受污染的数据流。在将跨边界206的各系统进行相关306之后，可具有封装了整个应用程序的控制流程图。随后可以将任何控制流程/数据流分析从每一分立组件内扩展到整个应用程序。例如，如果不能信任的数据进入一个组件(例如，作为URL查询参数)并随后被跨越边界传送到第二组件，则一实施例可继续以将该数据标记为不能被在第二组件中完成的任何数据流分析所信任，而非对该数据作出假设。在该数据被传递通过应用程序222中的各组件时，元数据允许该实施例保留该不能信任的指定，以得到更完整的应用程序分析。同样，如果数据传递通过已知的净化函数，则可以附加元数据220以将该数据标记为能信任的，并在应用程序分析中保留该指定。因此，一实施例可以避免对推测上不能信任而实际上能信任的数据的使用进行报告。

在一些实施例中，相关步骤306包括标识316类型实例。例如，可以基于类型名、基于类型内容、使用在执行期间记录的对象标识符、和/或基于类型的数量来标识316所调用的类型的实例。

在一些实施例中，相关步骤306包括跟踪318使用常见的“染色注入”机制被注入到通信信道的标识符。在一些实施例中，相关306包括使用因果关系挂钩338。在一些实施例中，相关306包括将离开调用程序的消息的内容与进入被调用程序的消息的内容进行比较322，并且在一些实施例中，将离开调用程序的消息的时间与进入被调用程序的消息的时间进行比较324。

一些实施例执行相关过程，包括获取针对304软件体系结构的实例的执行的运行时信息、获取326包含关于软件体系结构的静态信息的静态体系结构、从运行时信息和静态信息(增强体系结构图表记录实例的跨运行时确定边界的执行历史)导出328增强体系结构图表、以及在以下至少一个中在视觉上呈现330增强体系结构图表：显示器、打印输出。

例如，一个实施例获取326静态跨越体系结构图表形式的静态体系结构214，即表示软件体系结构在运行时确定边界206的相对两侧上的各部分的图表。随后，该实施例(至少部分地；可涉及其他动作)通过修改静态跨越体系结构图表包括该图表与软件体系结构的实例的运行时信息之间的相关，来导出328增强体系结构图表。

作为另一示例，一个实施例获取326表示软件体系结构在运行时确定边界206的第一侧的第一部分的第一静态体系结构图表122以及表示软件体系结构在运行时确定边界206的第二侧的第二部分的第二静态体系结构图表122的形式的静态体系结构。随后，该实施例(至少部分地；可涉及其他动作)通过使用软件体系结构的实例的运行时信息210将这些图表进行组合，来导出328增强的体系结构图表。

作为又一示例，一个实施例基于对软件体系结构的实例的静态分析来获取326静态数据图218形式的静态体系结构。随后，该实施例(至少部分地；可涉及其他动作)通过修改静态数据图以反映软件体系结构的实例的运行时信息210，并随后基于该经修改的数据图生成增强体系结构图表，来导出328增强体系结构图表204。

配置的介质

一些实施例包括配置的计算机可读存储介质112。介质112可包括盘(磁、光或其他)、RAM、EEPROM或其他ROM、和/或其他可配置存储器，包括在特定的非瞬态计算机可读介质(与线路和其他传播信号介质形成对比)。配置的存储介质可以特别地是诸如CD、DVD或闪存等可移动存储介质114。可以是可移动或不可移动并且可以是易失性或非易失性的通用存储器可被配置成使用数据118和指令116形式的从可移动介质114和/或诸如网络连接等另一源读取的诸如相关工具202和/或增强体系结构图表204等项目来形成配置的介质的实施例。配置的介质112能够使计算机系统执行用于通过此处揭示的导出增强体系结构图表204来变换数据的过程步骤。图1到3因而帮助示出配置的存储介质实施例和过程实施例，以及系统和过程实施例。具体而言，图3所示或此处另外教示的过程步骤中的任一个可用于帮助配置存储介质来形成配置的介质实施例。

其他示例

以下提供其他细节和设计考虑。如同此处的其他示例一样，在一给定实施例中，所描述的特征可个别和/或组合地使用，或完全不使用。

本领域的技术人员将理解，实现细节可涉及诸如具体API和具体样本程序等具体代码，因此不需要出现在每一实施例中。本领域的技术人员还将理解，讨论细节时所使用的程序标识符和某些其他术语是特定于实现的，且因此不需要属于每一实施例。然而，尽管它们不一定需要存在于此，但仍提供了这些细节，因为它们可通过提供上下文来帮助某些读者，和/或可示出此处讨论的技术的许多可能实现中的几个。

对于使用运行时生成的数据来将各静态软件图表进行相关的方法，首先考虑以下内容。可以使用诸如基于对代码的建模和解释的控制流程分析等常见的静态代码探查机制来生成静态软件图表。诸如Visual2010环境中的顺序图表等工具和诸如FxCop工具和PREfast工具等静态代码分析工具利用静态分析技术(微软公司的标记)。

一般而言，静态代码探查对在不执行查询的情况下不能被确认的控制作出假定，如条件语句的结果或循环的迭代次数。另外，对于松耦合的系统，静态代码分析在不运行程序的情况下不能知道该系统最终将使用什么类、数据、和/或服务。例如，考虑以下代码：

在第1行，静态代码分析不能知道调用“Purchase(购买)”函数的结果，该调用可能成功或它可能失败。出于这一原因，即使对于给定执行只采取一条路径，全面的静态代码分析也对该条件语句的两条路径都进行建模。这一建模的结果在诸如Visual2010环境中提供的顺序图表等顺序图表中示出，其中两条路径都被示出。

同样在第1行中，如果CustomerOrder(客户订单)是web服务，则静态代码分析不能知道哪一端点正在提供这一服务，这一端点是在运行时绑定的。类似地，静态代码分析不能单独确定CustomerOrderweb服务可以利用什么服务，如可以使用哪一信用卡授权服务或哪一客户订单历史服务(如果有的话)。

简言之，使用静态代码分析技术，只能够为每一系统创建覆盖可被静态地理解的代码路径的单独图表。静态分析不能单独将这些图表连接在一起或解释在任何给定程序运行中采取的确切路径。

相反，一些实施例使用从在运行时的应用程序收集的信息(例如，使用Visual2010解决方案中的IntelliTrace^TM特征)。随后，实际执行流程可被连接到体系结构图表，并且如在本文中教导的，可通过将多个系统之间的调用进行相关来将这些系统的图表连接在一起。

使用在应用程序222正在运行时收集的数据，运行时元素(如调用哪一方法以及采取哪一执行路径通过该方法)可被用来创建体系结构图表204或将各现有静态体系结构图表122(如顺序图表)进行连接以示出执行的实际路径212。例如，可以创建或连接到顺序图表中的实例级生命线。各种技术可被用来在相关306和导出328期间这样做，例如包括基于试探法的对象匹配或对象id跟踪。一旦运行时数据被用来创建或连接至体系结构图表，这些图表就可被通过图表之间的调用来连接到一起。

使用各种技术来将系统之间的调用进行相关306(如染色注入、因果关系、消息比较、时间比较等)，确切是什么系统被调用、这些系统调用什么系统等的运行时数据可被用来将分开的图表连接在一起，从而产生跨越运行时边界206的增强体系结构图表204。运行时数据提供这一连接，因为在松耦合系统中，所使用的服务和系统的配置直至运行时为止才知道的，并且可以在运行的生命期期间变化。

以下是用于组合静态和动态数据来产生跨系统边界206进行相关的图表204的一个实施例，以伪码的形式示出。注意，顺序图表和IntelliTrace^TM特征仅仅是特定示例；其他实施例可以使用不同的图表和/或不同的运行时信息收集机制。在这一上下文中，一个方法的伪码形式如下：

1.使用诸如Visual2010解决方案等工具来生成静态顺序图表122。

2.生成应用程序的至少包含函数级调用信息210的IntelliTrace^TM运行时日志，但该日志可包含更细粒度的信息，如所采取的通过该函数的路径。

3.使用以下技术中的至少一种来将函数级(以及函数内级)运行时信息(以什么次序调用什么函数)与静态顺序图表进行相关306：

a.使用某一比较函数来标识316通过它们的名称和/或内容来调用的类型的实例，并将这些实例连接到静态顺序图表生成器所生成的实例。

b.通过在运行时记录的标识每一实例的对象id来标识316类型的实例并将这些实例连接到静态顺序图表生成器所生成的实例。

4.部分地通过使用来自IntelliTrace^TM日志的相关信息将分开的顺序图表连接到一起来导出增强图表204。在静态顺序图表包含不带有端点的函数调用时，使用诸如以下相关技术来填充该端点：

a.通过将可跟踪的标识符注入通信信道(如http请求/响应中的附加首部)来使用染色注入跟踪318将调用程序连接到被调用程序。

b.使用320结合于此的美国专利7293256中描述的因果关系挂钩。

c.使用试探法来将离开调用程序的消息与进入被调用程序的消息进行比较322并将满足某一比较函数的那些消息相连接。

d.使用试探法来比较324时间并连接在时间上相对近的消息(使用时间比较函数)。

图4到8进一步示出了一些实施例。图4示出适于本文所教导的相关306的静态体系结构图表的示例。具体而言，图4示出顺序图表，这是一种交互图表122。该顺序图表和本文讨论的许多其他图表与统一建模语言(UML)相兼容，并且一些实施例将相关306功能与UML绘图功能集成在一起。然而，一些实施例可以使用与UML不一致的静态体系结构图表，并且一些实施例可以使用UML工具不支持的绘图功能。

图5提供图4中示出的软件体系结构的不同视图。具体而言，图5示出数据流程图，这也是图的形式的静态体系结构的示例。如本文所使用的，“图”可以是体系结构图表或任何其他数据结构，假定该结构具有通过链路连接的节点。图5因而可以被表征为图和/或图表。

图6示出通过将运行时信息与图4的静态体系结构图表进行相关306来产生的增强体系结构图表。在这一示例中，图4的图表被用两种方式来增强。

第一，在执行期间提交的订单的身份被记录并且对开发人员可用。具体而言，注释框602声称“orderSubmitted-orderId＝12(提交的订单-订单id＝12)”，意味着当orderSubmitted变量在运行时被传递到op.PlaceOrder()例程时，在运行时捕捉了orderId值12。在相关工具202中，运行时信息(如，特定订单的ID、或其他信息)可被显示在弹出框602中，如工具提示或更持久的框602中，例如从而用可帮助用改进对代码的理解的信息来扩充静态图表。更一般地，一旦对静态相关306作出了运行时，则随后可以将在运行时收集的附加数据与原始静态图表进行关联以产生增强图表。在给定实施例中，这样的关联可以在运行时发生或在运行时之后的任何时间发生。

第二，代码在执行期间所采取的实际路径在图6的增强图表上示出。在这一图示中，在事件上的较宽的线和编号标记了所采取的路径。这一代码路径的各部分被标记为“1.Main(主要)”，“2.CreateOrderProcessor(创建订单处理程序)”，“3.PlaceOrder(下订单)”，“4.Purchase(购买)”，“5.CreateOrderResult(创建订单结果)”，以及“6.PurchaseSuccess(购买成功)”。在相关工具202中，着色、移动、线宽度、图表的动画、和/或其他突出显示机制可被用来标记所采取的路径。同样，给定的增强体系结构图表204可以显示运行时值(例如，orderID)，可以显示代码路径212，和/或可以用本文教导的其他方式来增强。

图7示出跨运行时确定边界206的增强的体系结构图表，在该示例中运行时确定边界206位于“orderResult：OrderResult(订单结果)”组件与“CustomerOrderImplementation(客户订单实现)”组件之间。因为CustomerOrderImplementation是web服务，所以边界206不能用纯粹的静态分析来桥接。通过将运行时信息与图4的静态体系结构图表并与最右侧组件CustomerOrderImplementation和CreditCardService(信用卡服务)的其他静态信息进行相关，边界206可被桥接，从而便于改进对跨边界的代码的理解。

图8示出跨运行时确定边界206的增强体系结构图表。图8的图表示出将两个图(即，边界206每一侧上的图)形式的运行时信息与静态信息进行相关的结果。

结论

尽管此处将具体实施例明确地图示并描述为进程、配置的介质或系统，但可以理解，对一种类型的实施例的讨论一般也可扩展到其他实施例类型。例如，结合图3的过程描述还帮助描述经配置的介质，并帮助描述如结合其他附图讨论的那些系统和制品等系统和制品的操作。并不能得出一个实施例中的限制一定要加进另一实施例中。具体而言，各过程不一定要限于在讨论诸如配置的存储器等系统或产品时提出的数据结构和安排。

并非附图中所示的每一项目都需要存在于每一实施例中。相反，一实施例可以包含附图中未明确示出的项目。尽管此处在文字和附图中作为具体示例示出了某些可能性，但各实施例可以脱离这些示例。例如，一示例的具体特征可被省略、重命名、不同地分组、重复、以硬件和/或软件不同地实例化、或是出现在两个或更多示例中的特征的混合。在某些实施例中，在一个位置处示出的功能也可在不同位置提供。

通过附图标记对全部附图作出了引用。在附图或文字中与给定的附图标记相关联的措辞中的任何明显的不一致性应被理解为仅仅是拓宽了该标记所引用的内容的范围。

如此处所使用的，诸如“一”和“该”等术语包括了所指示的项目或步骤中的一个或多个。具体而言，在权利要求书中，对一个项目的引用一般意味着存在至少一个这样的项目，且对一个步骤的引用意味着执行该步骤的至少一个实例。

标题是仅出于方便起见的；关于给定话题的信息可在其标题指示该话题的节之外找到。

所提交的所有权利要求和摘要是该说明书的一部分。

尽管在附图中示出并在以上描述了各示例性实施例，但对本领域技术人员显而易见的是，可以作出不背离权利要求书中阐明的原理和概念的多种修改。尽管用结构特征和/或进程动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述权利要求中的具体特征或动作。给定定义或示例中标识的每一装置或方面不一定要存在于每一实施例中，也不一定要在每一实施例中都加以利用。相反，所描述的具体特征和动作是作为供在实现权利要求时考虑的示例而公开的。

落入权利要求书的等效方案的含义和范围内的所有改变应被权利要求书的范围所涵盖。

Claims

1.一种使用运行时生成的数据来将各软件体系结构图表进行相关的方法，该方法被用于设备中的可与至少一个逻辑处理器进行通信的存储器中，该方法包括以下步骤：

定位(302)软件体系结构中的运行时确定边界，所述软件体系结构至少部分地由至少一个软件体系结构图表来表示，所述运行时确定边界是在所述软件体系结构中至少部分地由在运行时作出并且因此不服从纯粹静态程序分析的决策所定义的边界；

获取(304)所述软件体系结构的实例的至少一个执行的运行时信息；

将所述运行时信息的至少一部分与至少一个软件体系结构图表进行相关(306)，从而产生对跨所述运行时确定边界的执行历史进行记录的增强体系结构图表；以及

将元数据附加到(314)数据源，并跨所述运行时确定边界来传播所述元数据。

2.如权利要求1所述的方法，其特征在于，所述定位步骤包括确定(308)所述运行时确定边界适合以下类别中的至少一个：

客户机-服务器边界；

机器-机器边界；

数据库-查询_程序边界；

web_服务_提供者-web_服务_消费者边界；

工厂_调用程序-工厂_实例边界；

接口_调用-实现_类边界；

进程间通信边界。

3.如权利要求1所述的方法，其特征在于，还包括由以下软件体系结构图表中的至少一个来表示(310)所述软件体系结构：

顺序图表；

分层图表；

活动图表；

类图表；

依存关系图表。

4.如权利要求1所述的方法，其特征在于，还包括：

获取(304)针对所述软件体系结构的同一实例的另一执行的运行时信息；

将所述运行时信息的至少一部分与所述至少一个软件体系结构图表进行相关(306)，从而产生对跨所述运行时确定边界的执行历史进行记录的另一增强体系结构图表；以及

将这两个增强体系结构图表进行比较(312)。

5.如权利要求1所述的方法，其特征在于，还包括：

获取(304)针对所述软件体系结构的不同实例的执行的运行时信息；

将这两个增强体系结构图表进行比较(312)。

6.如权利要求1所述的方法，其特征在于，所述相关步骤还包括以下步骤中的至少一个：

基于类型名来标识(316)被调用的类型的实例；

基于类型内容来标识(316)被调用的类型的实例；

通过在执行期间记录的对象标识符来标识(316)类型的实例；

基于类型的数量来标识(316)类型的实例；

基于通信基础结构跟踪来标识(316)类型的实例。

7.如权利要求1所述的方法，其特征在于，所述相关步骤还包括以下步骤中的至少一个：

跟踪(318)注入到通信信道中的标识符；

跟踪(318)由第一组件存储在存储介质中并由第二组件从该存储介质取回的数据；

使用(320)因果关系挂钩；

将离开调用程序的消息的内容与进入被调用程序的消息的内容进行比较(322)；

将离开调用程序的消息的时间与进入被调用程序的消息的时间进行比较(324)。

8.一种相关方法，所述方法包括以下步骤：

获取(304)针对软件体系结构的实例的执行的运行时信息；

获取(326)包含关于所述软件体系结构的静态信息的静态体系结构；

从所述运行时信息和所述静态信息导出(328)增强体系结构图表，所述增强体系结构图表记录所述实例的跨运行时确定边界的执行历史，所述运行时确定边界是在所述软件体系结构中至少部分地由在运行时作出并且因此不服从纯粹静态程序分析的决策所定义的边界；

将元数据附加到(314)数据源，并跨所述运行时确定边界来传播所述元数据；以及

在以下至少一个中在视觉上呈现(330)所述增强体系结构图表：显示器、打印输出。

9.如权利要求8所述的方法，其特征在于，还包括：

获取(326)表示所述软件体系结构在所述运行时确定边界的第一侧的第一部分的第一静态体系结构图表以及表示所述软件体系结构在所述运行时确定边界的第二侧的第二部分的第二静态体系结构图表的形式的静态体系结构；以及

至少部分地通过使用所述软件体系结构的实例的运行时信息将这些图表进行组合来导出(328)增强体系结构图表。

10.如权利要求8所述的方法，其特征在于，还包括：

基于对所述软件体系结构的实例的静态分析来获取(326)静态数据图形式的静态体系结构；以及

至少部分地通过修改所述静态数据图以反映所述软件体系结构的实例的运行时信息，并随后基于该经修改的数据图生成增强体系结构图表，来导出(328)所述增强体系结构图表。

11.如权利要求8所述的方法，其特征在于，所述导出步骤还包括以下步骤中的至少三个：

基于类型名来标识(316)被调用的类型的实例；

基于类型内容来标识(316)被调用的类型的实例；

通过在执行期间记录的对象标识符来标识(316)类型的实例；

基于类型的数量来标识(316)类型的实例；

基于通信基础结构跟踪来标识(316)类型的实例；

跟踪(318)注入到通信信道中的标识符；

使用用户标识的相关(340)；

使用(320)因果关系挂钩；

12.一种计算机系统，包括：

逻辑处理器(110)；

可与所述逻辑处理器进行通信的存储器(112)；

驻留在所述存储器中的增强体系结构图表(204)，所述增强体系结构图表记录软件体系结构的实例(124)的跨运行时确定边界(206)的执行历史，所述运行时确定边界是在所述软件体系结构中至少部分地由在运行时作出并且因此不服从纯粹静态程序分析的决策所定义的边界；

驻留在所述存储器中的软件，所述软件在由所述逻辑处理器执行时执行以下过程：

定位(302)软件体系结构中的运行时确定边界；

13.如权利要求12所述的系统，其特征在于，所述增强体系结构图表(204)包括并跨越以下运行时确定边界(206)中的至少一个：

客户机-服务器边界；

机器-机器边界；

数据库-查询_程序边界；

web_服务_提供者-web_服务_消费者边界；

工厂_调用程序-工厂_实例边界；

接口_调用-实现_类边界。

14.如权利要求12所述的系统，其特征在于，所述增强体系结构图表包括与来自所述执行历史的运行时信息(210)相关的被突出显示的代码路径(212)。