From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,677566500df644a3 X-Google-Attributes: gid103376,public From: "Jeffrey D. Cherry" Subject: Re: Popular Design Diagram Methods For Ada Date: 2000/02/03 Message-ID: <3899C15B.3C81B9E9@utech.net>#1/1 X-Deja-AN: 581167567 Content-Transfer-Encoding: 7bit References: <38986B2C.D4BDB7A4@quadruscorp.com> To: "Marin D. Condic" X-Accept-Language: en,pdf Content-Type: text/plain; charset=us-ascii X-Trace: azure.impulse.net 949600641 190 207.154.66.65 Organization: Logicon MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-02-03T00:00:00+00:00 List-Id: My group has looked at a lot of Ada code. The software that we've looked at was developed by different companies (I'm with the IV&V contractor). It's almost exclusively Ada83, but there is some Ada95. The various projects range in size from about 30KLOC to over 250KLOC. As you would expect, we're always looking for better tools to automate the code analysis process. We can't depend on the developer's software design diagrams since they often don't exist or are not updated through the long development cycle. We also need to focus on the code, since its what actually does the work. Another limitation is that we only have PCs on which we may do the analysis. Thus, any tool we consider must run under Windows 95/98 or NT. We have one Linux machine that we've just recently acquired, so things are looking up. Given the above context, and if you're talking just code analysis ... not, for example, requirements tracking or automated testing ... then we've been using a tool called "Understand for Ada" by Scientific Toolworks, Inc. They also have a C++ and FORTRAN variant of the same tool. Their web site is at http://www.scitools.com. We've found that this tool gives you the most bang for the buck. It generates a variety of reports and diagrams that we've found quite useful, and the latest version (1.3, currently in beta but due out at the end of February) is an impressive improvement over the previous version (1.2.7). The tool doesn't generate UML diagrams (I'll address that topic below) but the diagrams it does generate gives you an idea of structure and other dependency relationships. The browser makes navigation of these diagrams easy and we use the text reports for additional processing and analysis. We've tried reverse engineering options in tools such as Rational's Rose and Software Through Pictures from Aonix, but were unimpressed with their results. The reason these reverse engineering tools don't help that much is because we look at (mostly) Ada83 code and these tools generate UML diagrams. Since Ada83 isn't as object-oriented as Ada95, the resulting class diagrams are uninformative. This isn't a failure of the tool but merely a consequence of the implementation. What we would like to see in these reverse engineering tools, but haven't seen, is as follows: 1) Class diagrams should use the data type name for the class name, and component boxes should list all the explicitly defined primitive operations on the type. Implicit primitive operations could be listed as well but should be "hidable" from the diagram. 2) Component diagrams should be generated to show the relationships of the source files and their resulting application programs and/or libraries. 3) For a given subprogram, generate an activity diagram. Other UML diagrams are, IMHO, not creatable from the source without some, or a lot of, input from the user. Use Case diagrams, I think, are not derivable from the code, but must be generated by the user(s). Statechart diagrams would be very difficult to generate from the code due the variety of ways to implement a state machine. Sequence diagrams might be generated for common GUIs, but would require help from the user for event definition and callback routines, and at the very least would require processing files other than Ada source. Collaboration diagrams would be even more difficult since the interaction must be defined by the user. Deployment diagrams may be generated but again require the user to define the partitioning of applications to nodes, etc. Something that, once again, can't be derived from the source code. If you have money that you can devote to a project, you may want to consider using ASIS to develop your own analysis tools. We've identified several ASIS tools that we'd like to develop but simply don't have the resources. Also, if you use a real operating system (i.e. _not_ Windows), there are many more analysis tools available. -- Regards, Jeffrey D. Cherry Senior IV&V Analyst Logicon Space and Information Operations Logicon Inc. a Northrop Grumman company