原论文题目：Identifying Software Components from Object-Oriented APIs
Based on Dynamic Analysis
1 前言
近十几年的研究都表明通过API(Application Programming Interfaces )来进行软件程序的编写，能够大大提高编程效率。在面向对象的API中，最基本的单元就是类，类封装了相关功能，对外提供了一个公用的使用接口。JDK、.NETframework等等都是非常复杂而又庞大的API，这些API里面包含了大量的类和方法，去理解并使用这些大量的类会消耗很大的精力和时间。
API为软件提供了相应的功能接口，API的重用（reuse）是通过在一些重用场景下对API重新组合使用实现的。然而，不同的软件会有不同的重用场景，这取决于软件对API功能的需求。大量不同的重用场景，导致会有大量的api重新组合以满足这些场景。为了更好的理解这些重用场景，有学者提出了方法论，把API之间频繁共同使用的场景抽象出来，抽象这些场景为一个高级视图。在分析软件是如何使用（重用）API时，频繁的共同使用模式会被识别出来。这些抽象出来的共用模式，能够在软件工程师执行某些任务的时候给予支持，这些支持包括，API的重组，API的文档，API的理解以及API的策略执行等。
重用场景指的是，在构建软件的过程中，某些情境下，只需要调用jdk中某些类或方法就可实现这些功能，不过需要将这些类或方法重组。
在面向对象的API中标识组件主要是通过将API中提供的功能抽象成一个高级视图来实现的，标示组件能够提升API文档化。除了能够将API文档化，标识组件还能够帮助实现将面向对象的API迁移到面向组件的API。这样的一个重构的过程支持满足基于组件的存储仓库，而且还允许通过使用选定的组件开发大型软件应用程序并基于灵活的体系结构将它们集成在一起，从而获得基于组件的软件工程的好处。
和面向对象的类相比，软件组件更容易被理解，重用性也更高。这种认知是基于二者的粒度不同，面向对象是细粒度，而软件组件是粗粒度。此外，组件通过其提供的和必需的接口清楚地定义它们的依赖关系，以一种显式的方式，以便于和面向对象的方法进行对比。以上是提出组件识别方法的动机，这些方法是基于对面向对象软件源代码的分析来确定组件的。
现有的组件识别方法旨在从面向对象的软件应用程序源代码中识别组件。它们只依赖于OO依赖项(例如，方法调用、共享类型等)来识别类之间的依赖项。但是，在软件OO API的上下文中，还应该考虑API类之间的共同使用依赖关系，以确定可以重用的类/方法，以实现特定的场景。这需要好好分析API以及客户端程序的源代码。
为OO设计程序的方法论不能直接应用于OO的api.以往的方法是基于对OO api的源代码及其客户端应用程序的静态分析。由于我们使用OO API处理实际的客户端，动态分析允许更好地捕获API使用的实例。使用静态分析的方法通常受到处理动态特性(如多态性和类装入)的困难的限制。
文中在这里开始提出了自己的方法论，以往的方法都是静态的组件识别，现在是动态分析的组件识别技术。能够处理某些静态处理不了的特性。
在本文中，我们提出了一种在OO api中识别可重用组件的方法。我们的方法是基于客户端应用程序和目标OO API之间交互的动态分析。因此，我们为在客户端应用程序中实现的不同使用场景生成执行跟踪。这些执行跟踪通过其方法调用实现API类之间的依赖关系。我们假设组件是通过API类来标识的，这些API类经常被客户端应用程序重用。因此，我们认为在执行跟踪形式中经常出现的方法组提供了组件的接口，这些方法的所有者API类构成了该候选组件的结构。为了评估我们的方法，我们将它应用于三个Java api，它们的客户机来自DaCapo基准。结果表明，该方法的精度为98%。
本文的其余部分如下所示。第2节介绍了我们的方法背后的框架。第3部分描述了识别与api的客户端应用程序的使用场景相关的执行跟踪的过程。在第4节中，我们使用一个提议的质量函数，根据执行场景中出现的关系识别api方法的图表示。第5节展示了如何根据基于图形的聚类算法识别组成组件的类。评价结果见第6节。有关的工作在第7节中讨论。结论和今后的工作将在第8部分提出。
2 建议的方法和框架
在这一节中，我们将概述、总结原则并提出建议方法的过程。
2.1 方法总览
我们提出了一种确定可重用组件的方法，这种方法是通过动态分析客户端程序和API之间的交互来实现的。