Effective software engineering techniques are needed to increase the reliability of software systems, to increase the productivity of development teams, and to reduce the costs of software development. Organizations search for an effective software engineering process as they strive to reach higher process maturity levels, produce better software, and win new contracts. To aid in this search for better methods of software engineering, the Software Engineering Research Center's (SERC) Design Metrics Research Team at Ball State University has analyzed university and industry software to be able to correctly identify error-prone units during the design phase of software development. The research team has developed and tested their design metrics De, Di and D(G) over a six-year period and has found them to be excellent predictors of error-prone units.
The Design Metrics Analyzer for Ada (DMAA) has been developed to automate metrics collection and calculation of Ada systems. This tool improves the metrics collection by ensuring the accuracy of metrics calculation and by minimizing the interference with the existing work load of a software engineer. The DMAA collects 104 metrics, including the Zage design metrics De, Di and D(G), LOC, limited terminal semicolon count, comments, embedded comments, V(G) and other primitive syntactical constructs on each Ada unit. Ada procedures, functions, tasks, generics and package specifications or bodies are considered as Ada units. DMAA also provides a complete design metrics analysis. This proven technology yields a list of stress points, which are units that are considered to be error-prone or difficult for developers. This analysis is performed at the module and package level. A set analysis is also performed in which units identified as stress points by one, two or all three of the design metrics, De, Di and D(G) are grouped into sets. Managers or developers might investigate which units were flagged by all three metrics. This total analysis assists software engineers in determining which components in a system need to be reexamined. This analysis also can be completed on any of the metrics that the tool collects.
The DMAA accepts Ada specifications and/or Ada code as input. The DMAA tool does not require that Ada input files be in compiled order, meaning that one can evaluate a whole system or subsystems of a developing product. Since the DMAA can accept partial systems and since the input files to the DMAA may be disconnected subsets of a system, the DMAA also performs a connectivity analysis. The connectivity report identifies the number of subsystems and the number of modules contained in each subsystem. This analysis can also identify redundant modules and dead code.
From the given input, the DMAA generates a variety of content reports. The content information reports that are produced are named overloaded, unit information, files analyzed, call structure, call index, generic, rename and variable table. The overloaded report contains a listing of all the overloaded unit names followed by their parameters. The unit information report is a textual summary of information available about each unit. For example, this report contains a listing of local variables declared and global variables used, including the original declaration and location. The parentage of a variable is identified for the developer or maintainer. The unit information report also lists the fan-in (called_by) and fan-out (calls) of each module in expanded name notation. This is especially useful in systems with units of the same name. To determine which files were included in an execution of the tool, the files analyzed report would be reviewed. Also included here is a LOC count for each file. The call structure report textually reproduces the calling structure of the modules contained in the submitted files. Each page of the report identifies the subsystem and the root module. It also identifies generics, renames and modules that were not included as input. The call index is a companion report to call structure. It is an alphabetized index of each module location in the call structure report. All generic module templates and their instantiations are listed in the generic report. All renamed modules and their actual names are listed in the rename report. The variable table report contains all variables, their type, location of their declaration, and the list of modules which access and/or modify it. These reports provide developers with detailed, specific information about the system submitted to the DMAA.
DMAA executes on the Unix platform.