The FORTRAN Structuring Experts
The COMP-AID Company has developed a methodology for rapidly
Existing Code
First, let's consider what clarifying old code procures for us, with the further understanding that we are going to broaden the definition of "old" to signify any existing code, regardless of whether it is old legacy code or recently coded modules.
We suggest that clarifying any existing Fortran module will procure four significant advantages for you, as relating to
Documentation
After viewing the examples in our brochure, you will note that not only is the structured (or refactored, or clarified) module grouped into a set of independent Functional Blocks, but that also each functional block of code, regardless of its hierarchical level, is preceded by a single comment line of the form
C <event>: process-description
where event describes the logical state of affairs for control to have arrived at this block of code, and process description describes what we are going to do now that we are there.
Our RENUMF program also prints out all these one line comments as a "Functional Block Outline" , as illustrated in Figure 7 on page 18 of the brochure, thereby providing a documentation for each associated structured module.
Business Rules
You may be wanting to upgrade/modernize an existing system, and it would certainly be nice if you could extract the business rules employed in the old system, as that would certainly guide you in the upgrade process. By structuring each of these old legacy Fortran modules, you arrive at these business rules as just part of the structuring process.
Moreover, as we note on the first page of our brochure, this is a very rapidly converging process, depending almost linearly on the original number of Fortran statements in each module before structuring.
Security
Security is certainly at the forefront of our concerns. For example, a recent online article on May 26, 2004 by Robert Lemos of Cnet News.com, titled "Will code check tools yield worm-proof software?", notes that
"Nearly 4,000 security flaws have been found in software during each of the last two years, but software developers still don't routinely do automatic checks for such vulnerabilities. Legal ramifications, however, could change that."
Mr. Lemos then observes that
"Several companies have gone into the business of creating and providing "static source code checkers" to handle such spot-checks. While many agree that the time is right, some say the technology's not ripe--which could make for additional costs and distract from the checking already being done."
With RENUMF and our methodology of structuring by Functional Blocks, the technology is proven and the cost is minimal. Now, while admittedly the software mentioned in the online article most likely use C++ or Java, yet there are security concerns that could also be lurking within your Fortran code. How do you know that some programmer hasn't placed a back door trap in some of the modules, permitting subsequent unsavory manipulation unknown to your company? Unless you have someone view every line of code in all your modules comprising your system, you really don't. But if you structure these modules, then you really do know what every module does.
You can let us structure your modules, or you can acquire our RENUMF Fortran programming aid and let your own programmers do it.
Before you dismiss illicit insider threats within your own organization, please consider the August 2004 report, Insider Threat Study: Illicit Cyber Activity in the Banking and Finance Sector, which was written by Dr. Marisa Randazzo and Dawn Cappelli of Carnegie Mellon University, CERT Coordination Center, under the sponsorship of the U.S. Secret Service.
Maintainability/Enhancebility
But you just don't end up with the above three benefits for each structured Fortran module, you also at the same time end up with a module that is subsequently extremely easy to maintain, as well as to enhance. That's a bargain that is hard to surpass.
New Code
The FBO methodology aids the programmer in the design and implementation of the algorithmic representation of the module in five ways:
__________________________________
[1] Niklaus Wirth, "Program development by stepwise refinement", CACM 14, 4 (April 1971), 221-227.
[2] Chris Sibbald, "Taming Chaos with SysML", Software Development 14, 3 (March 2006), 43-44.
- reclaiming/documenting old difficult-to-understand Fortran code
- designing/implementing/coding new Fortran code
Existing Code
First, let's consider what clarifying old code procures for us, with the further understanding that we are going to broaden the definition of "old" to signify any existing code, regardless of whether it is old legacy code or recently coded modules.
We suggest that clarifying any existing Fortran module will procure four significant advantages for you, as relating to
- Documentation
- Business Rules
- Security
- Maintainability/Enhancebility
Documentation
After viewing the examples in our brochure, you will note that not only is the structured (or refactored, or clarified) module grouped into a set of independent Functional Blocks, but that also each functional block of code, regardless of its hierarchical level, is preceded by a single comment line of the form
C <event>: process-description
where event describes the logical state of affairs for control to have arrived at this block of code, and process description describes what we are going to do now that we are there.
Our RENUMF program also prints out all these one line comments as a "Functional Block Outline" , as illustrated in Figure 7 on page 18 of the brochure, thereby providing a documentation for each associated structured module.
Business Rules
You may be wanting to upgrade/modernize an existing system, and it would certainly be nice if you could extract the business rules employed in the old system, as that would certainly guide you in the upgrade process. By structuring each of these old legacy Fortran modules, you arrive at these business rules as just part of the structuring process.
Moreover, as we note on the first page of our brochure, this is a very rapidly converging process, depending almost linearly on the original number of Fortran statements in each module before structuring.
Security
Security is certainly at the forefront of our concerns. For example, a recent online article on May 26, 2004 by Robert Lemos of Cnet News.com, titled "Will code check tools yield worm-proof software?", notes that
"Nearly 4,000 security flaws have been found in software during each of the last two years, but software developers still don't routinely do automatic checks for such vulnerabilities. Legal ramifications, however, could change that."
Mr. Lemos then observes that
"Several companies have gone into the business of creating and providing "static source code checkers" to handle such spot-checks. While many agree that the time is right, some say the technology's not ripe--which could make for additional costs and distract from the checking already being done."
With RENUMF and our methodology of structuring by Functional Blocks, the technology is proven and the cost is minimal. Now, while admittedly the software mentioned in the online article most likely use C++ or Java, yet there are security concerns that could also be lurking within your Fortran code. How do you know that some programmer hasn't placed a back door trap in some of the modules, permitting subsequent unsavory manipulation unknown to your company? Unless you have someone view every line of code in all your modules comprising your system, you really don't. But if you structure these modules, then you really do know what every module does.
You can let us structure your modules, or you can acquire our RENUMF Fortran programming aid and let your own programmers do it.
Before you dismiss illicit insider threats within your own organization, please consider the August 2004 report, Insider Threat Study: Illicit Cyber Activity in the Banking and Finance Sector, which was written by Dr. Marisa Randazzo and Dawn Cappelli of Carnegie Mellon University, CERT Coordination Center, under the sponsorship of the U.S. Secret Service.
Maintainability/Enhancebility
But you just don't end up with the above three benefits for each structured Fortran module, you also at the same time end up with a module that is subsequently extremely easy to maintain, as well as to enhance. That's a bargain that is hard to surpass.
New Code
The FBO methodology aids the programmer in the design and implementation of the algorithmic representation of the module in five ways:
- It accommodates Wirth's (1971) [1] method of viewing program construction as a sequence of refinement steps.
- The use of the "<event>: process-description" notation is at a sufficiently high level (i.e., sufficiently abstract) as to permit the designer to rapidly brainstorm various algorithmic approaches with a minimum of rewriting.
- Because each "<event>: process-description" occupies only one line, the programmer always has a large global view of the design/implementation as it unfolds.
- It permits the programmer to produce the FBO on his or her terminal, as opposed to writing the "<event>: process-description"s on paper which would severely impede the expression of the flow of ideas. (Of course, for a very long FBO, we often print out a copy of the current status of the FBO, so that we can still view that portion that is no longer showing on the screen, thereby maintaining our global view.)
- It forces the programmer to concentrate on the design. In this sense, the methodology mirrors one of the newer phrases, Model-Driven Development, which simply implies "an iterative, top-down development process that ensures that the big picture is clearly defined before the focus shifts to the details." [2]
__________________________________
[1] Niklaus Wirth, "Program development by stepwise refinement", CACM 14, 4 (April 1971), 221-227.
[2] Chris Sibbald, "Taming Chaos with SysML", Software Development 14, 3 (March 2006), 43-44.
Last updated on August 19, 2019
Keywords:
Fortran
refactor
structure
clarify
document
refactor
structure
clarify
document
Do You Have any Production Programs
coded in Fortran 77?
If the answer is "Yes",
then you need RENUMF.
Our newest technical report, Use of RENUMF in Clarifying (Refactoring) a Non-trivial FORTRAN 77 Module (The DFNRT Subroutine), provides a step-by-step illustration of the use of RENUMF in clarifying a particular method of numerical iteration (the bisectional method), so that it is highly understandable. This report is provided in the DOWNLOAD section of our web site.coded in Fortran 77?
If the answer is "Yes",
then you need RENUMF.
You will note that this report, dated May 25, 2018, is a thorough recasting of an earlier report, simply titled Overview of RENUMF I.4. Not only are the computer listing of the various steps of the processes much more legible in this current report, but the power of RENUMF's Functional Block Outline is much more clearly shown.
Our Must-See Report
Please don't forget to view our revised Technical Report, Programming in Standard FORTRAN by Functional Blocks: A Rigorous Structured Approach.
This report demonstrates that FORTRAN programs with go to statements, when utilizing Functional Blocks, can be made highly maintainable and easy to understand, thereby readily accommodating a proof of correctness.
