What is softwaretrace.org?Softwaretrace.org is an Open Source Project with the goal of developing a tool to assist software developers and maintainers to determine the ripple affect of a change in one source file has on other applications and libraries which use thefunctionality implemented in that source file.
I started developing software in 1972 in High School using a PDP-8 and DEC Basic. I graduated from college in 1978 and have been actively maintaining and developing software professionally since that time. For the first 10 years of my career I did moremaintenance work, by this I mean modifying enhancing existing software written by other developers and other firms. At that time most of work I was involved with was done in FORTRAN or Assembler Language, C and Unix were just starting to come into mainstream during the early 80's.
The computers at that time were slower and had less resources. It was important to keep each source module to a minimum in order to reduce rebuild times. Under some operating systems this also allowed one to manually overlay the application into memory segments that could be swapped at a specific page register. The normal rule of thumb we used was to put one function/subroutine per source file. During the design process it was critical to determine how much could functionality could be shared and to develop as much of the code base as possible as libraries.
We now get to the basic problem that I am attempting to provide a solution for which is when you change file in a library, you impact N number of other files and applications. Current source code management tools track changes at the file level but do not have a way of identifying which applications are currently using a file or items with in a file in library.
Before I continue I need to define some terminology. I will be referring to an item which is checked in to a configuration management system at an atomic level as a module. A module may contain just definitions, a single function, multiple functions depending on the language used.
In 1988 I worked on project that we had a contract to upgrade an existing system. The system contained over 300,000 lines of FORTRAN and over 180,000 lines of assembler language. The system could not be totally rebuilt from source due to configuration management failings. What documentation was available was outdated and did not match the existing source code base. In order to get a basic view in to the as-built/existing system what we did was to generate cross reference listings for all the source code. This was then post processed into a format we could use to load a database. We then loaded this information to a Rbase (http://www.rbase.com) database on a PC. The database was rather simple. It had a table which had a fields for the application name, library name, flag indicating if this was a library or an application, the function name and a function the function called.
From this basic table we were able to develop a simple database application which could report the calling hierarchy starting at the application level. This allowed us to get a basic understanding of the system structure. The overall system was comprised of over 60 incooperating tasks with a complex InterProcess Comunication (IPC)relationships so this was not simple a system to understand.
Thinking this was great tool I tried to convince the powers that be that we had something which would really help us not only on this project but others as well. Outside of my department head there was a complete lack of interest.
There was several reasons for the lack of interest the first was the need for a Relational Database Management System (RDBMS) to store the cross reference data in. At this time the RDBMS licenses were extremely expensive The need to develop import tools for the cross reference output from various compilers was a concern. It was also a fact that updating the database still required manual steps which allowed for it to get out of sync with source code. We would have to develop customize user interfaces for each platform we wish to support. Since that time several things have changed. First three open source RDBMS engines are available Firebird, MySQL and PostgreSQL, the common use of cvs, the world wide web and web browsers which provide a common front-end across platforms.
What I am attempting to develop is a reasonable robost what I like to call aRipple Effect Analyzer for software. The first open source implementation isbackended by MySQL and uses Apache, Tomcat,xcerces and PHP for it's implementation. To keep the input simple the information is imported from the XML files generated by d oxygen(http://www.doxygen.org).
For the initial version of the Ripple Analyzer in order to process you
source code you must first run the source though doxygen specifying
XML output is required. The more source code you run through doxygen the better.
Since doxygen will be able to build a more complete picture of your application.
I will be providing an import application will be provided to populate the
database. The initial version will work at the source file level only which
matches the way cvs reports changes. If you have any questions, comments or
suggestions please e-mail me at evbruno@softwaretrace.org
Implementation Schedule
Supporters and Contributors to this effort:
| Last updated on 1 Jan 2005 |