Software Metrics for Demeter/Java Programs ------------------------------------------ Team : Kirti Chandratreya and Bijoyini Chatterjee. ----- Host : Binoy Samuel. ----- Project Description : ------------------- The project is designed to collect the software metrics for the Demeter/Java programs. The metrics are classified as those which can be collected directly from the class dictionary and those which depended on the java code ( in the behavior file and the generated java code ). The main concentration for the project was to collect all the metrics for the program from the class dictionary. The metrics were further classified as suggested by the Journal article ( mentioned in Credits ). The classfication was Simple system level metrics, Derived system level metrics, Class external metrics and class internal metrics. Of the above classification the class dictionary metrics fell partially in the sections of simple system level metrics, Derived system level metrics and class external metrics. Many of the software metrics depended on the java code, which is not implemented in this project. Credits : -------- The main reference to the project is the article " Automated Metrics and Object-Oriented Development " in the Dr. Dobbs Journal issued in December 1997. The article is written by Jagdish Bansiya and Carl Davis. The project growth plan followed the plan ( with some variations ) described in the text book " UML Distilled" by Martin Fowler with Kendall Scott. Also, we would like to give credit to Mr. Doug Orleans and Mr. Binoy Samuel, for their timely valuable suggestions for the project. The Project Details : -------------------- The Class Dictionary used : demjava.cd ( version 0.6.4 ) Growth Plans used : The growth plans was distributed at two levels 1. Structural simplifications and 2. Behavioral simplifications. Structural Simplifications : After the couple of assignments and the discussions with our host, we felt comfortable working with the full demjava.cd grammar and so, did not work on smaller simplified grammar. Behavioral simplifications : Most of the evolutionary development of the software took place in the behavoiral aspect of the project. 1. The metrics were first classified in terms on the ones depending on the class dictionary (.cd file ), ones requiring the .beh files and the ones requiring a combination of the two and finally the ones dependent on the java code. 2. The ones depending on the class dictionary were discussed, designed and implemented. Each of the metric which was implemented followed the following pattern : Selection of metric, Designing the Strategy, Checking previous reusability of visitors, Implementation and finally testing. 3. The Evolutionary development of the metrics : The following sections depict the in sequence the way the project evolved. Number of Classes in the system : This metric counts the number of classes in the system. Implemented as : NOC.beh Number of Independent Classes in the system : The Independent classes are the classes that are not inherited by any classes in the system. Implemented as : StandAlone.beh Number of Abstract classes in the system : Counts the number of classes that have been defined purely for organization of the information in the system. In the grammar this is done by using the inheritance heirarchies. The Base classes for the grammar would yield the Abstract classes for the system. Implemented as : NOAbs.beh After the above metrics were implemented, most of the metrics depended on the building of the heirarchies in the system. To reduce the computation and actual processing time for the metrics depending on the heirarchies, CreateHeir.beh was developed which takes input the entire class dictionary file and generates the reduced class dictionary containing only inheritance heirarchy related grammar rules in the form of Alternation classes. To print and handle classes of the system with their names, a supporting traversal was created which extracted the String for the classname from the Name Object Initially, the CreateHeir.beh was designed to handle the pure alternation classes. This then evloved to handle the inheritances generated by *extends* feature. With the new reduced grammar the next set of the metrics were developed. Number of Inheritance Heirarchies : Counting the number of heirarchies in the system Implemented as : CountHeir.beh Number of Single Inheritances in the system : Count the number of class ( subclass ) that use single inheritance in the system. Implemented as : NumbSingInh.beh Number of Internal Nodes and Number of Leaf Nodes. The metric was designed to count all of the above type of classes. As a by product of this metric the Total number of Nodes in the Inheritance heirarchies were found. Although this calculation was not needed in this metric is provided foundation for developing the average depth and width metrics. Implemented as : TotalNodes.beh The Next set of the metrics involved the summing of the depths and widths of theindividual heirarchies and calculating averages The Depth of the Nodes/ Ancestors of the class : As the Demeter/Java does not support multiple inheritance, the depth of the inheritance would indicate the number of ancestors for the class The Depth of the class Node = Length of the path from the root to child The Ancestors = number of nodes along the path from the root to the class. Implemented as : AvgDepth.beh The Average Depth/ Average number of ancestors : Implemented as : AvgDepth.beh The Average width of the Nodes : Average number of children per class in the inheritance heirarchy. Implemented as : AvgWidth.beh Parts of the Project which could be developed further : ------------------------------------------------------ 1. The project, presently has all the implemented metrics run independently from each other. So, each metric is compiled and run separately. Some of the programs produce more than one software metric. The further extension to the above project could be to generate a tabular display for the software metrics. 2. Integrate software metrics depending on the Demeter/Java and Java Code to build a complete package to collect the software metrics. Known Bugs : 1. The Demeter/Java grammar parses successfully multiple inheritance due to the *extends* feature. We, have assumed that the user will not use multiple inheritance and uses the *extends* feature in the Demeter/Java spirit. 2. For many of the metrics a reduced grammar needs to be first created. Else, the program will work on the original inputs but produce incorrect results. Test inputs : ----------- The test inputs for the project were small simplistic grammars which we wrote to test the software metrics. Finally the test input was the demjava.cd grammar itself. The inputs can be found in the directory : /proj/demsys/com3360/f97/BijAndKirti/project/input/*.cd /proj/demsys/com3360/f97/BijAndKirti/project/input/Newfile Test outputs : ------------ The outputs included in the project are located in directory : /proj/demsys/com3360/f97/BijAndKirti/project/output/* The interesting input/output pair for the project : -------------------------------------------------- During the evolution phase of the software metrics for the heirarchies, we designed for and tested out several approaches for creating the Heirarchies from the input class dictionary. One of the supporting programs in the project called CreateHeir.beh creates a set of Alternation classes from all the possible Alternation classes and *extends* feature. The Input : See /proj/demsys/com3360/f97/BijAndKirti/project/input/demjava.cd The Output : See /proj/demsys/com3360/f97/BijAndKirti/project/output/Newfile The interesting input/output pair for the project which could be improved : -------------------------------------------------------------------------- Interesting enough, is the CreateHeir.beh, which creates a new file containing the heirarchies in terms of the Alternation classes. This program could be improved to create an object of forest of heirarchies, instead of writing into the file to be used by subsequent heirarchy metrics programs. The forest of heirarchie s could be then used to collect the heirarchy metrics. This is one suggested improvement for the project performance. //---------------------------------------------------------------------------// Please answer the following questions: Question : Did you change the generated Java code? Answer : No, the generate java code was not changed at all. Question : If you had the priviledge to have one of my graduate students as host or if you had interactions with the teaching assistant, an evaluation of their performance would be welcome. We would like to take this opportunity to thank Binoy Samuel and Doug Orleans for all the suggestions and discussions for the project. The interactions with them helped us in better and quicker understanding of the grammar and the pitfalls we may run into. //----------------------------------------------------------------------------//