In the “heroic” age of computers, even the smallest machine filled a frigid air-conditioned room, and all lines of code ended at column 80. Programmers worked to the rasp and clack of card punch machines, and they probably programmed in Assembly, FORTRAN, or COBOL.

Those days are in the past, but those languages live on. Fortran is now a niche language, but an important one. In the world of scientific computation, it and C/C++ reign supreme. It’s no accident that the three most widely used tools for high-performance computing--message passing interface (MPI) for distributed computing, OpenMP for shared-memory computing, and OpenACC for accelerator computing--all have bindings for just these two languages.

With the release of the Fortran 2003 standard, Fortran is now a fully object-oriented (OO) language. Marked by clear, jargon-free prose, this paper presents the ForUML application, created by the authors for extracting unified modeling language (UML) class diagrams from code written in modern Fortran. The tool works by reverse engineering--in other words, by creating the diagrams from the code. It combines in one package a handful of available open-source tools with code written in Java. Creation of the diagrams involves four stages: 1) parsing, using the Open Fortran Parser; 2) extraction, in which the parsed Fortran code is interpreted and common object-oriented entities are created; 3) generation, in which these objects are expressed in the Extensible Markup Language (XML) metadata interchange format (XMI); and 4) importing, in which the open-source ArgoUML tool is used to convert the XMI data into UML diagrams. For testing, the application was used to generate diagrams for five existing programs. The diagrams were checked by hand, and the results are excellent.

This paper will interest readers who have a use for the tool presented. The introduction points out the usefulness of visual aids such as UML diagrams for maintaining and developing programs. Once an OO application reaches a certain level of complexity, diagrams are almost essential. There are, however, other uses for the tool that the paper goes into. The authors point out that many scientific and engineering application programmers are not computer scientists; they are engineers and scientists first. Few universities offer Fortran courses, and if they do, the course is often given by a science department, such as physics, rather than the computer science department. Fortran programmers who employ ForUML will learn many aspects of coding and OO theory they may not have been aware of. This tool places them on a common footing with colleagues who use C/C++, and this will allow them to better express and share their ideas. This applies especially to those working on mixed-language applications. Similarly, for programmers learning Fortran, the tool will assist them in translating the Fortran syntax into concepts or terms with which they are already familiar. For example, what is known as a class in most OO languages is called a derived type in modern Fortran.

The authors note that they are investigating the possibility of releasing the program as open-source software. I hope they do. It merits wide use.