Assignment
Write a program to read one or more Java.class files, provided via command-line parameters, and calculate several metrics based on the compiled code.
Metrics
Your program must calculate the following metrics:
1. For each class: Lack of cohesion in methods 4 (LCOM4).
- This metric must be calculated for each class provided.
- For this purpose do not include constructors, toString() or equals() meth- ods.
- You should disregard all toString() or equals() methods, regardless of pa- rameters, not just those from Object.
- Do not calculate LCOM4 for interfaces.
2. For all classes: Coupling between object classes (CBO). CBO should be calculated based on the provided classes, to do this you will need to parse the code attributes, the constant pool itself will not provide the correct information
Input Data
Your program must accept the class filenames as command-line parameters (not via con- sole input). Each class filename may simply be "ClassName.class".
It may also have a path component; e.g., "dir/ClassName.class" or "/usr/local/ClassName.class" or "../../tmp/ClassName.class", etc.
Your code is required to work with .class files of version 51.0, corresponding to Java
7. You can handle other versions at your discretion. You should not try to parse the complete class file for a version you are not handling. You should produce an adequate error message and your README/report should detail which versions you are handling.
Error Handling
You MAY NOT assume that ANY input data (including the contents of the class files themselves) is valid! Your code must gracefully handle ALL potential errors relating to input data.
Specifically, your program must handle errors as follows:
- Give the user a helpful error message; and
- If possible, proceed with whatever input data is valid. Do not abort the program except as a last resort. (For instance, if a parsing error occurs in part of one class file, everything up to that point may still be usable. You should be able to attempt the remaining class files too.)
Output
You program must produce both a terminal and text file output as follows
- Terminal: a summary of each class's LCOM4, and the overall CBO
- Class names should be fully translated. i.e.: public, final, extends etc. . .
- Method names should be fully translated. i.e.: flags, return and parameter types.
- File: a Graphviz/Neato compatible file specifying the graphical representation of each class's LCOM4 diagram and the CBO diagram for all classes (wikipediapro- vides a basic introduction to the format required. See the documentation for more detail.)
- Classes may be represented by just their names.
- Method names may be abbreviated, only the name and parameters are required (in order to distinguish between overloaded methods).
- LCOM4 graphs should distinguish between class fields and methods.
- You DO NOT need to specify formatting information for the graphs, the syntax and core information will suffice.
Output Format
The output must be understandable to a user with no knowledge of the Java class file format (but still with knowledge of the Java language itself).
Specifically, adhere to the following when outputting information:
- Use indentation to make it easy to see which methods belong to which class.
- Constructors and static initialisers must be identified as such.
- Always show parameter types for methods and constructors, and return types for methods. Show types in a Java form, not a JVM form (e.g. "int" rather than "I"). You may keep or discard package names (e.g. "java.lang.") at your discretion.
- Avoid outputting unnecessary information (such as the constant pool entries).
Coding
You may optionally make use of the already-partially-implemented ClassFileParser pro- gram (available on Blackboard). You will have to decide how best to adapt it for your purposes.
You may write your code in any language, provided you can demonstrate it working on the Linux lab machines in building 314. ClassFileParser itself is written in Java.
Testing and Code Quality
To ensure your code is of high quality:
(a) Develop test cases to check all required functionality. Your tests must cover a broad range of situations, including boundary cases, complex cases and real-world cases. Obviously, your application should pass the tests!
For each test case, you must of course manually determine the expected metric results, to determine whether your code passes or fails the test. For this purpose, you may use the javap tool to see the JVM instructions, or simply calculate the metrics based on the source code. Remember that JVM can add things in.
Real-world test cases should involve typical (or better still, very complex) Java classes from open-source Java applications. For instance, you might consider classes from NetBeans, or from java.awt.swing, etc.
(b) Use RSM, PMD, or another tool approved by the lecturer to find and fix readabil- ity/maintainability issues. You may decide that some issues do not require fixing, but if so you must justify your decision.
Report
Prepare a report that includes the following (must be in .pdf format):
Compiling and Running: Briefly explain how to compile and run your code from the command-line on one of the Linux lab machines in building 314. If you have used Java, this may be as simple as:
[user@pc]? cd MySourceCodeDirectory [user@pc]? javac *.java
[user@pc]? java MyAmazingApplication filenames ...
However, if it's more complicated for any reason, please let the marker know! This should also be included in an appropriate README file.
Functionality: State which functionality you have successfully implemented, to the best of your knowledge.
Design: Explain your design:
(a)structurally, describing each class you have developed or modified, and (b)algorithmically, describing (in high level terms) the significant steps in your code and any important data structures it uses.
Testing: Describe your test cases, justify how you designed them, how you computed the expected values, and provide the actual results of your testing. Describe any bugs you are aware of.
Quality: State any code quality issues raised by RSM, PMD or the relevant tool used, and give your response to each.
Referencing: State precisely which code is yours and which isn't. Of the source files that make up your application, state precisely:
(a)which files are entirely your work,
(b)which pre-existing files are entirely unmodified (if any), and (c)which pre-existing files you modified (if any), where, and how.
As before (in Assignment 1), your report should:
- Have normal spacing and a sensible layout.
- Be logically structured, using headings where appropriate.
- Use good English, with proper spelling and grammar.
- Comprehensively demonstrate that you know what you are doing!
Submission
Submit the following electronically to the Assignment 2 area on Blackboard:
- A completed Declaration of Originality;
- The complete source code for your application, including any pre-existing code you use (so that the marker can easily compile and run your application);
- The complete source code for your test cases;
- Your report (in .pdf format);
- The output from RSM or PMD (or the relevant equivalent tool) in a single file called quality.txt, quality.html or quality.zip (if there are multiple files).
Attachment:- ClassFile.rar