Case Tools
Case Tools
Computer Aided Software Engineering (CASE) tools are software tools for making the lives of engineers easier. For some years now there have been such tools on the market for electrical engineers, mechanical engineers (CAD tools are a form of CASE tools), software engineers, etc.
Many CASE tools are graphical in nature. The engineer enters data as a diagram. What happens with that diagram depends on the tool. Tools for electrical engineers might analyze circuit diagrams for power consumption, voltage requirements, etc.
There will eventually be 3 CASE tools listed on this page.
And as an added bonus, I will also place here an article on DV-Centro. DV-Centro is an enhanced and commercial version of research done at GE CR&D (developed in conjunction with Yokogawa, Japan). DV-Centro is not a CASE tool, but rather a C++ framework, designed to make complex graphics programming easier. I have not used DV-Centro for interface programming, but I have used its container classes and DV-Centro pointers in developing a parser for the BEACON project. These container classes represent some great ideas, which will probably end up showing up in the CASE tool I am designing.
BEACONBEACON is a CASE tool designed to allow mechanical engineers to efficiently develop software for GE's jet engines. In the traditional jet engine software development system, the mechanical engineer, who has a good understanding of what should be happening inside the engine, uses a CAD tool to draw a diagram describing what s/he wants to happen. S/He then takes this diagram to a computer programmer, who converts it to assembly language code which runs on the engine. The code is also converted, ideally by another programmer, to FORTRAN or C code, which is run on a simulator. The assembler is also run, and the results are compared. If the results do not match, the two sets of code are analyzed to see which is in error. The code is also laboriously analyzed by module testers to make sure that it will in fact do what the original diagram says it should. These module testers develop test cases to determine how the diagram works through the range of all inputs to make sure there are no overflows, divides by zero, etc.
With BEACON the diagram is entered in the BEACON graphics editor. BEACON itself then produces both the assembler and FORTRAN/C simulation code. BEACON also has the ability to generate test cases of the same type as those produced by module testers. At first glance any process that develops production code, simulation code, and test cases from the same source seems doubtful. But the source for this process is the same as the source for the above process - the diagram. In both cases all parts are produced from this same source. The only difference is that in the above process there is more human intervention. In both cases, if there is an error converting the diagram to source, that error will be caught. And in both cases, if there is an error in the diagram itself there is no way to catch it if it does not cause an error in the simulator (design flaws that cause overflows or divide errors can be caught, more subtle design errors cannot). GE claims that use of BEACON reduced software development time by 50% on the F-414-400 project. At that time the automated testing capabilities were rather immature. It is expected that the time/labor cost reduction will improve on future projects, due to improvements in this tool.
Beacon articles now on line are:
The first of these articles was presented at the at the IEEE conference on Computer-Aided Control System Design, which was given in Tuscon in March, 1994. The author, Magnus Rimvall, PhD., was kind enough to list me as an author on this paper. This is, however, stretching the truth. All the concepts in this paper were developed by Magnus. My part was that of a grunt programmer implementing those ideas. This paper has already been approved for publication by GE.
The second paper is a general paper on automated module testing. Beacon has the capability to generate module tests. Several approaches were studied on how to develop this capability. Two approaches that initially looked promising but were then rejected are discussed in this paper. A paper looking at a third approach (the approach that is which is now in use), may appear here at some point in the future. Lockheed-Marting, the developer of the third approach, is looking at patenting the approach. Nothing can be written about it until it has been decided whether to patent or not.
Beacon is now available from Applied Dynamics International (ADI). They can be found at http://www.adi.com. Or the can be reached by e-mail at adinfo@adi.com, or the BEACON marketing rep, Koos Zwaanenburg, can reached by calling (313) 973-1300.
Object Modeling ToolObject Modeling Tool (OMTool) was developed at GE CR&D to aide in the development of object oriented software. A high level design is entered into the tool using a notation similar to the object oriented design notation presented in James Rumbaugh's book, or in the books by Coad and Yourdon. Once the high level design is entered, a detailed design of each object can be done. This detailed design consists of adding data members and function member prototypes. Once the function member prototypes are entered the tool can then create C++ header files and skeletal source files. Once this is done it can bring up an emacs session with the source code file in it, so that the user can enter the actual code. With OMTool the source code must be entered by hand.
James Rumbaugh is at least partially responsible for the design of this tool, so the notation used by the tool is very close to that presented in his book. Unfortunatly, I do not have his book, nor do I possess a manual or example output from OMTool, so I at this point I will have to more or less guess at the notation. But the point of this paper is to give an overview of the capabilities of the tool, not to present a user's guide. So I hope that I will be forgiven if on occasion I resort to Coad and Yourdon notation.
OMTool is being marketted by Martin Marietta Advanced Concepts Center, in Valley Forge. Unfortunatly I have been lax in my homework and do not have information on how to contact them.
DV-Centro is a C++ framework originally designed to ease development of complex graphical systems. DV-Centro provides device independent graphics, graphical constraint management and event handling mechanisms to facilitate development. DV-Centro supports XMotif and MS-Windows interface styles.
As part of my work on BEACON, I developed a parser while making use of DV-Centro's container classes. I myself never used the XMotif interface. But I found the container classes intriguing enough to incorporate many of their concepts into my own tools, and to give a short paper on them here. All information presented here is available in the user's manual.
DV-Centro is available on SunOS, Solaris and HP-UX today. A Windows NT version will be available in 1996. DV-Centro is marketed by DataViews, inc. (http://www.dvcorp.com). For more information, contact
Kathy Wang
While using OMTool and DV-Centro to develop BEACON, myself and several other members of the BEACON project realized that all these tools were really just parts and pieces of one unified concept. OMTool could be used to develop the high level design and objects, BEACON could be used to develop the source code, and DV-Centro pointers and containers could be used by both to make the task of designing and implementing large software projects easier.
Not only that, but given these three existing tools, it would not be difficult to design a new tool incorporating all three aspects. Not only that, it is relatively easy to implement a "diagram level debugger". (While I was on BEACON we discussed the possibility of adding a diagram level real-time simulation tool, but it never got budgetted. The design of the debugger and the simulator are very similar.)
The above system by itself would be totally new and unique approach to software development. It could also be accompanied by a window design tool such as that now marketted with Visual C++, but made platform independent. An optimizing cross-compiler could be provided that would output source code for UNIX, WindowsNT or MacIntosh. It would then be possible to crank out application software for all three platforms in less time than it now takes to write software for ONE of these platforms.
In this space I will be presenting a series of articles detailing my design for such a system. This design will, of course, avoid the use of any proprietary code or concepts which I have knowledge of from my work on BEACON (i.e. it will NOT use the BDL processing described in Magnus Rimvall's BEACON paper).
This was page last updated on May 5, 1996
Send your comments on the content of these pages to
j_alan@prodigy.net
Return to the High Tech page