These problems stem from differing backgrounds. The maintainer may lack the detailed knowledge of the phenomenon that the original designer possessed. The person chosen to design and implement to the code will necessarily have a certain degree of expertise in the field and be able to call on that knowledge to create the model. The designer will, of course, write the code using terminology specfic to the field, and the maintainer could face a jargon-block that makes the code incomprehensible. Even profuse commenting of the code may not help the hapless maintainer since the comments would call upon the same knowledge, and hence use the same jargon, that the designer used to write the code. "Initialize the covariance matrix" may have a self-evident meaning for an expert in navigation systems, but to someone with a background in computer science it means nothing.
For example, assume the simple case of wanting to add the result of one computation to the computation of another. The maintainer might be told "Add the result of the secondary driver value to the feedback loop of the primary driver." An engineer trained in the the phenomeon being modeled could probably find the code segments in question without a problem and make the mod quickly. But since a great deal of maintenance gets performed by people with far less background in the field, this simple modification may require days of research into what the original module does, where the relevant sections of the code lie, and only then can the single line of code be added.
Given a diagram of the code, the maintainer faces a far easier task. Consider this figure drawn by our Math Model Manipulator which depicting the hypothetical code:
Any maintainer can easily see what needs to be done. The lower part of the diagram needs to be joined with the upper. Using the Math Model Manipualtor, the user could easily generate a new diagram depicting the required functional relationship. It would look something like this:
Using the print capability of the Math Model Manipulator, the user could generate a new figure suitable for insertion into any documentation of the code. But the code still needs to be modified.
The Math Model Manipulator does more than draw pretty pictures. It has a code generation feature which translates the figure into working code in either Ada, Fortran, or C/C++. A single diagram can be used to create modules in any of these languages, and we would be more than happy to work with someone desiring to work in another language.
It also offers the ability to tie the code it create into a number of simulation systems, including American Computational's Generic Host Independent Operating SysTem and J-MASS. It can also create code for "generic" purposes, meaning that the code is not targetted to any specific system but instead receives values from and returns values through a formal parameter list, allowing users to create control modules that interface with the rest of the system and also to create lower-level modules for internal use. The "world" icons on the diagrams represent values coming into the module from or going from the module to somewhere outside of itself. How they get represented in code would depend on which interface the user selected.
Using our Math Model Manipulator, all the maintainer would need to do would be to modify the figure and the code would be generated automatically. It eases software maintenance to an amazing degree, and provides the ability to update documentation as well. It addresses the very areas of software maintenance that drive the costs of such work to exorbitant heights.
We have designed the Math Model Manipulator to meet the needs of simulation engineers. It uses the block diagram format familiar to almost anyone in the field, a format easily learned by anyone new to the field.
Unlike some software companies that design such tools for others but do not use them for their own purposes, we do the type of work that this program eases on an almost daily basis. We applied our experience with the design and implemenation of math models to ensure that the Math Model Manipulation has the types of features that you will need. If it does not suit your needs, it would not suit ours since we will always be an active user of the code as well as its marketer.
For more information, or for a demonstration copy of the program, send mail to Mike Miedlar or give him a call at 937-667-4884.