Home > News & Events > MITRE Publications > The Edge >

What effort would be involved in replacing the Army's Appliqué interprocess communication system with the Distributed Computing Environment (DCE)? What are the performance implications of the message handling upgrade for Joint STARS? How do I extract the Cobra Gemini radar's tracking code so that I can use it to upgrade another radar system? To answer questions like these, a software engineer must become familiar with a software system containing hundreds of thousands of lines of code probably written in several programming languages.

The engineer can read the system documentation, but this is often incomplete, inaccurate, and not kept current with the software. The engineer can also examine the source code itself, using text-based search tools to search for words, variable names, and function names. In this case, the information is more reliable but may be more difficult to interpret: words found in comments may not reflect the actual code, and tracing the relationships between variables and functions is tedious and error-prone. In either case, the engineer attempts to put together a picture of the overall software architecture (that is, the components of the system and their interactions).

To help automate this process, MITRE is developing a reverse engineering tool, called ManSART (MITRE Software Architecture Recovery Tool). ManSART analyzes a system's source code and produces architecture-level descriptions of the system in the form of an object and directed graph representation. It can then generate a Web-based architecture documentation package or produce descriptions suitable as input to other software analysis tools.

As an illustration, recently we used ManSART to document the Cobra Gemini radar software. The software, written in C and FORTRAN, contained more than 170,000 lines of code. The 105-page Web-based documentation package generated by ManSART contains hyperlinked reports on task interactions, dependencies on commercial software modules, cross-language connections, procedure calls, and other architecture and source code details needed for understanding the Cobra Gemini software. One page from that documentation package depicts the software dependencies and the underlying infrastructure (operating system and commercial product layers) required for running the system shown in Figure 1.

Figure 1: Cobra Gemini radar software dependencies

Recovering Software Architectures
Software architectures define the components of a system and their interactions. These architectures provide the basis for understanding a software system in order to carry out various tasks over the system life cycle. Commercial reverse-engineering tools provide only a limited set of capabilities to help an engineer understand the organization and structure of a system. These capabilities operate at the level of procedures and data structures, not at the architecture level.

The challenge in recovering software architectures from source code lies in the fact that few programming languages provide constructs for architectural elements. Instead, system libraries and application programmer idioms form the basis for building software architectures. ManSART contains representations of various architectural styles (for example, interprocess communication, pipe and filter, repository) and mappings between those styles and the source code idioms used to realize those styles.

An Interprocess Communication Example
For example, the following call sends a message from one process (the one in which this call is executed) to another process (the one identified by the DESTINATION_ID variable):

CALL SND_MESSAGE (PEXP_PTHBMF, DESTINATION_ID, ACT_PROC, MSG_LENGTH, PEXA_NULL, PEXA_NO_CONFIRM, PEXA_NULL, PEXA_SELF, BIT_MAP, MSG_IDENTIFIER, STATUS)

This procedure call defines a relationship (interprocess communication) between two system components (the sending process and the receiving process). It is easy to recover the sending process automatically since it contains the above code fragment. The challenge is to recover the identity of the receiving process.

ManSART's representation of this particular interprocess communication idiom encodes the fact that the receiving component is specified by the second argument of the procedure call, in this case the value of the DESTINATION_ID variable. ManSART determines that value by analyzing the places in the source code where that variable is accessed and updated. Once ManSART has identified the components, it can integrate this information into a view that shows all of the interprocess communication. An example is shown in Figure 2.

Figure 2: Interprocess communication

After we have created different views, we choose those we wish to use in the Web-based documentation package and tell ManSART to generate the appropriate pages. Most of the Web-pages are automatically generated, but some require manual steps.

Summary
ManSART has been used to provide architecture-level information about several military systems to support various systems engineering tasks. These tasks have ranged from developing performance models to evaluate the impact of communication system upgrades to assessing a system's compatibility with the Defense Information Infrastructure Common Operating Environment.

---

For more information, please contact Melissa Chase using the employee directory.

---