George M. Crews received his bachelors in General Engineering from the University of Nevada at Las Vegas, and his masters in Engineering Science from the University of Tennessee at Knoxville. He is a "generalist" with over 15 years experience in mechanical and software engineering design and analysis. He may be contacted at 109 Ashland Lane, Oak Ridge, TN 37830 (615) 481-0414.
As a mechanical engineer, my experience with analysis programs falls in the areas of structural stress, fluid dynamics, heat conduction, and thermal/hydraulic system simulation. Such programs present the technical software developer with a number of unique problems, not least of which is providing a user-friendly interface.
Though program users tend to be computer literate, input data can often be voluminous and tedious to prepare; the typical user may make many runs with only slight modifications as design optimization is often accomplished by repeated analysis. Both input and output must be stored and presented in a manner that allows independent verification and validation. Finally, the information output from one program may be required as input by another.
Another big headache is that modern (i.e., graphical) user interfaces tend to be hardware or system-software specific. A good universal interface would free the developer from the nuances of different machines and operating systems, while at the same time representing a standard that machine-specific routines can work with.
MEL is my solution for making such technical programs more user-friendly and modularized. MEL (for MEtaLanguage data processor) is a set of input/output utilities that provides a standard interface between the program and the user. It can translate input data written in "pseudo-English" (Example 1) making the data available to the program as variables (Example 2) . It can also translate program variables (Example 3) into pseudo-English (Example 4) . Effort was made to provide data objects that could be easily incorporated into almost any engineering analysis program (Example 5) .
The pseudo-English look of MEL means that I/O will be more readable and comprehensible to the user (or checker).
Secondly, MEL is object oriented in that it provides a structured and encapsulated I/O interface. Thus, development time will be reduced and future changes can be made to the program more easily.
Thirdly, MEL's grammar is simple and unambiguous, with both input and output formats identical so that output from one program may serve directly as input to another. Finally, MEL can read and write data directly to a file so that a permanent record of a run and its results are available.
Description
In MEL the smallest unit of pseudo-English I/O is called a "descriptor." Its purpose is to describe something, either data or a command, to a program. The general format for descriptors is much like function calls in a typical programming language. An I/O unit consists of a descriptor name (somewhat like a function name), followed by a parameter list, followed by an end-of-unit symbol (the semi-colon). For example, consider the following MEL descriptor, which could be used as part of the input to a piping network analysis program:
pipe, length = 100 (ft), diameter = 6 (in);This is a pipe descriptor whose parameters are length and diameter. The values assigned to these parameters would be 100 and 6, and in units of feet and inches, respectively. Although the tokens (names and parameters) making up descriptors are customized by the developer for each individual application program, the above grammar remains the same for all programs using MEL. (See Example 1 and Example 4. )MEL's format was chosen for its simplicity, while allowing for as much flexibility as possible without introducing ambiguity. In MEL, tokens may be abbreviated as long as they remain uniquely identifiable. MEL assumes a default parameter order if parameter names are missing. Comments may be included by enclosing them in double quotes; parameter values may be labeled as "unknown," etc. These format choices are designed to make programs incorporating MEL as convenient to the user as possible.
Incorporating MEL
In order to incorporate MEL into one of your own programs, you must customize the mel.h header file to be included in your application source code file. First create a "dictionary" for both input and output that defines the proper spelling, number, and types (integer, array, etc.) of data associated with each descriptor and parameter. (Note that by simply changing spellings in the dictionary you could go from pseudo-English to "pseudo-French" or some other "pseudo-language.") The task of defining dictionaries has been made as painless as possible by providing complete instructions and an example program on the MEL diskette available through the CUG library. (The diskette contains MEL source code, header file, documentation and instructions, an example program, and a conversion factor routine. Since a listing of all MEL routines would run over 50 pages, a complete listing has not been included with this article.) You will need to prepare documentation for the user, defining the dictionaries and explaining what the tokens mean.To obtain data from a descriptor, you must first read it and then extract the data (see Example 2) . An example of outputing data is shown in Example 3. Allowing the user to input data with different units requires conversion to internal units (ASTM, 1982). Included on the MEL diskette is a routine that can convert more than 150 different units. Additional units and conversion factors can easily be added to the source code.
How MEL Was Developed
An early decision was to write MEL in C. Fortran is the traditional language for scientific programs; however, engineers like myself are beginning to realize that there is more to technical software development than simply correctly coding a complex algorithm. ANSI C has a number of significant non-numerical advantages over Fortran (Kempf, 1987). C allows for more flexible structured programing and data encapsulation techniques to be applied (also see Jeffery, 1989). C has more operators and program control constructs than Fortran. C allows indirection (pointers) where Fortran does not. C more easily interfaces to existing system software since much of this software is itself written in C. Also, C is a popular language for unconventional computer architectures such as parallel processors (Lusk, 1987) and neural networks.Let me also mention some of C's shortcomings, which are related to its relative naivete for scientific purposes. Dynamic array dimensioning in C is convoluted (Press, 1988). C does not have the numerical library that Fortran does. And finally, C does not allow operator overloading for data structures (complex numbers for example) nor does it have an exponentiation operator. However, I do not think these deficiencies are difficult to overcome.
Partly as an experiment to form my own opinion about OOP, the design of MEL incorporates the object-oriented paradigm. I chose to make use of C's preprocessor to restrict the visibility of public type, function, and data declarations to just those objects that the application program may need at a certain place (see Example 5) . (The private type, function, and variable data needed by the MEL routines themselves are not shown in the example and are hidden from your program by other defined/undefined manifest constants.) For another approach refer to the article by Jeffery.
Summary And Future Enhancement
Software engineering is rapidly evolving and everyone seems to have his or her own ideas about what makes a good user-interface. I believe MEL is a practical answer to the spectrum of interface problems confronting the developer and user of complex technical programs.Some may criticize MEL for its verbosity (as compared to Fortran's fixed field format), the time a user must spend learning to use MEL (versus a more interactive interface), and the somewhat clumsy way objects must be (or at least, were) encoded in C. These points are legitimate and are inherent in MEL's design. No design can be all things to all people.
The next steps in MEL's evolution might be incorporating it into a language sensitive editor, a graphical output post-processor, and perhaps later, into an expert system shell specialized for the type of analysis being performed.
Bibliography
George M. Crews, "HAPN—A Hydraulic Analysis of Piping Networks Program," Masters Thesis in Engineering Science, University of Tennessee, Knoxville, 1989. A portion of this thesis describes MEL and how it was developed and used for a specific analysis program.David Jeffery, "Object-Oriented Programming in ANSI C," Computer Language Magazine, February, 1989. This article discusses the object-oriented paradigm and a way to implement it in C.
James Kempf, Numerical Software Tools in C, Prentice-Hall, Inc., 1987. This book contains an introduction to both numerical programming and C. The emphasis of the text is on creating small routines that can be used as building blocks for larger programs. Possible shortcomings are its lack of data hiding and that it treats doubly dimensioned arrays statically rather than dynamically.
Ewing Lusk, Overbeek, et al., Portable Programs for Parallel Processors, Holt, Reinhart and Winston, Inc., 1987. This book describes a set of C tools for use on a broad range of parallel machines.
William H. Press, Flannery, et al., Numerical Recipes in C, Cambridge University Press, 1988. Based on an earlier Fortran edition, this is a great cookbook giving a wide range of oven-tested recipes for the numerical gourmet. It shows the correct way to handle multidimensioned arrays (dynamically). A complaint sometimes heard is that a few of the algorithms are getting obsolete due to rapid advances in numerical techniques being made.
ASTM E 380-82 Standard for Metric Practice, American Society for Testing Materials, 1982. This standard contains many useful conversion factors between English and metric units.