© 2002 Arthur Alexander Reyes Intellectual Merit. Organizations often develop software applications for their use only. Such applications may be too specialized to generate adequate profits even in niche markets. To reduce coding effort, engineers use other software applications (Internet Explorer, Matlab, OPNET Modeler, legacy/stovepipe systems, custom libraries, etc.) as large-grained components in their new applications. Usually these applications-as-components (“appliponents”) were never intended to interoperate. Making appliponents interoperate is a problem in “ad hoc software interfacing”, “interface coding”, “glue coding”, or “low-level interfacing”. Ad hoc software interfacing has historically been detail-intensive, tedious, and relegated to less-skilled programmers. Such programmers often lack the skills needed to produce appropriate architectural abstractions with elegant and maintainable interfaces. Software engineering has made tremendous improvements in software interoperability. Standards and tools now exist that allow binary software components, developed by different organizations using different programming languages, to efficiently interoperate in-process or over a network (e.g., .NET, CORBA, etc.). Commercial software development environments now exist (e.g., Visual Studio, Visual Age, SoftWIRE, Matlab, MathCAD, Intelliun/VE, etc.) that allow engineers to build applications by “wiring components together”. Unfortunately, these only provide a partial solution. For example, selected appliponents support different interoperability standards, or none at all. Attempting to unify (wrap) selected appliponents under a single interoperability standard is not currently cost effective, nor especially wise for the long haul. If we could automatically abstract selected appliponents into a unifying architectural framework, wire them together using a graphical editor, discover and decompose missing components, and generate the needed implementation “glue code”, developing this kind of application would be considerably easier. The suite of formalisms, methods, and tools needed does not exist, but appears to be within reach: Inter-procedural data flow analysis can reverse engineer more applicative programming interfaces to source code, even under side effects. Appliponent I/O file formats can be induced manually from documentation and semi-automatically from example I/O files via grammatical induction. Sequential constraints on appliponent invocation can be manually induced from example client programs that use the appliponent and from appliponent API documentation. Data can be extracted from running appliponent UIs via screen scrapers. Data can be entered into running appliponent UIs via macro players. Using emulators, appliponents can be hosted on different platforms without recoding. Appliponents can be translated from one programming language to another. Data can be translated from the output language of one appliponent to the input language of another appliponent. Such translators can be generated using domain-specific language (DSL) tools. Canonical data interchange formats can be specified in XML, XDR, etc. In some cases, wrapper generators can make appliponents comply with a software interoperability standard. Specifications of naked data structures used by appliponents can be reverse engineered using a host of static and dynamic analyses. The pieces of the “ad hoc software interfacing” puzzle exist, but what is needed is a formalism that can unify the plethora of viewpoints, a method for exploiting the formalism, and a suite of integrated tools. We propose to develop these. The formalism will feature a multidimensional type system. It will represent the abstract syntax of data and appropriate concrete syntactic attributes as well (e.g., Unicode or EBCDIC, naked in memory or accessible via an API, C++ or Java, NTFS or NFS, local host or remote, etc.). It will represent both the abstract behavior of appliponent programs (e.g., combinational, sequential, concurrent, etc.) and concrete runtime attributes as well (e.g., COM or CORBA objects, standalone process or runs inside an interpreter process, etc.). The formalism will be applicative and graphical. Edges represent appliponent functions, procedures, packages, or classes, viewed applicatively. Nodes represent aggregates of data produced or consumed by edges. Each application’s architecture will duplicate and compose appliponent arcs and add new, “bridge” arcs to fill in gaps between appliponent arcs. The method will extend component based development (CBD) methods, but will support component decomposition as well. It will feature criteria for drawing applicative boundaries around appliponents characterized by hidden state, I/O, and side effects. In a refinement of the SEI’s Architecture Tradeoff Analysis (ATA) methods, the proposed method will evaluate candidate architectures for functionality, size, and development effort. The method will reward appliponent reuse without modification and discourage appliponent reuse with modification. The method will be amenable to design automation through heuristic search of the architecture space. Many of the tools needed already exist, but need to be integrated into a suite. Data flow analyzers and wrapper generators will play an important role in abstracting arbitrary appliponents into the applicative formalism. This integration of extant tools into a suite will itself be an example of ad hoc software interfacing. Broad Impacts. The broad impact of this research will be more cost effective “black box” reuse of appliponents. This research will discover ways in which shrink-wrapped and legacy appliponents can be transformed into robust server components that behave reliably under unforeseen clients. This will facilitate integration of information systems, such as in the U.S. Navy’s Network Centric Warfare (NCW) concept, which is important to national security. This research will provide formalism, method, and tools in an area where little support exist now. 2003-11-10 11:41:00