Software Surveyor Overview

Software Surveyor

Gauges to Dynamically Deduce Componentware Configurations

Principal Investigator: Dr. David Wells

Object Services and Consulting, Inc.

Large, modern software applications, including DoD C4I systems, are constructed from custom and preexisting components from a variety of sources. Both the components and their organization with respect to each other must evolve over time as the result of new requirements, bug fixes, performance improvements, feature enhancements, and changes in their environments as the systems with which they interact change. An essential (but not sole) requirement for safely and predictably making these changes is knowing how the components use each other. This includes dynamic behavior that cannot be captured in any way other than to observe the behavior of the system running in its normal operating environment.

This effort builds gauges to collect, analyze, and present information about how deployed instances of distributed software actually interact, how this compares with the desired (specified) interaction patterns, how far the effects of changes can propagate and whether an anticipated action is likely to be safe, and to identify subtle differences between environments that might be the source of puzzling misbehavior. The results will be software gauges suitable for use in profiling applications constructed using a variety of important technologies such as Java, Dynamic Link Libraries (DLLs), Common Object Request Broker (CORBA), and Hypertext Transfer Protocol (HTTP). We will also develop tools to deploy these gauges to selectively collect information that is needed to diagnose particular problems, monitor the effect of recent reconfigurations, or to serve as inputs to other tools being used to plan or manage the evolution of a system. Such gauges are a necessary part of the feedback process needed for software evolution as envisioned by the DASADA program.

Gauges to be developed include:

Component connectivity gauges: Detect the potentially time varying runtime connectivity of component-based applications. Connectivity is measured as (connected-to, used), depending on whether the components have undergone a static or dynamic binding process and whether the resulting connection has actually been used. Based on component interactions measured at interception points.
Component interaction gauges: Measure the timing (when), usage (which operations were invoked), intensity (how often, how much data), responsiveness (how long responses take), and anomalous behavior (which exceptions were thrown and under what circumstances) of component interactions. Can give instantaneous results and/or aggregations across time. Based on component interactions measured at interception points.
Evolution safety gauges: Estimate (as a probability) whether a planned system evolution (e.g., a bug fix, performance upgrade, feature enhancement) will affect specific existing usage patterns. Based on a comparison of behavior measured using the above gauges with the reconfiguration actions proposed in the evolution plan.
Gauge placement gauges: Gauges to determine where (specific gauge and connection point) in a running system, specific gauges can be placed to collect desired usage information. Based on specifications of existing collection of gauges, implemented gauge insertion points, and information to be collected.

Gauges will be transparently attached to existing components or the pathways between them using existing “interceptor” technology. We will identify the kinds of information that can be collected at these interception points and collect, manage, aggregate, and visualize the collected information. Minimally, we will be able to determine dynamic component connectivity, function/method invocation, timing, and exceptions. This information will be used to reconstruct both the instantaneous and long term behavior of monitored applications. This will be demonstrated using a test application that exercises the three interconnection technologies (DLLs, CORBA, and HTTP).

Software releases, including code and documentation will be made annually. Annual demon-strations will exhibit the current capabilities of the gauges and point the way for further developments. Results will be documented in three major design documents, in addition to the manuals associated with the software releases.

The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S. Government