jMetra Analysis:
Lines of code:
Lines of code increased by 300 lines overall. The apps package actually became smaller while the gui and services packages increased in size. More specially, the peerdiscover class has reduced in size, this is a sign of refactoring since we have not reduced the functionality. A large portion of the increase in lines is attributed to the new classes, MPdialog, PrefScreen increased, Musicprofile, Search, SearchRequest, SearchResponse, ShareFolder, Uploader, and UploadListener. Also of note, several classes decreased in lines of code which is a sign of refactoring.
Method count:
The majority of methods were added to the services and gui pakckage as discussed with above. The method count increased due to new classes while several classes decreased in lines of code which is a sign of refactoring.
Class count:
The majority of classes were added to the services and gui pakckage as discussed with above. The class count increased due to new classes, no classes where removed nor are there any that appear empty.
Overall:
Efforts should focus on the new classes and methods within, Also, many of the past classes reduced in size and method count. The refactored classes also needs testing and review.
JMT Analysis:
Coupling Between Objects (CBO):
MainGUI and ServicesApi continue to be the ones with highest CBO value. PeerDiscovery should be added to the list of classes that have to be looked at for the reasons behind high CBO value. ConfigurationInfo, JxtaSocketLinuxwif, MPDialog, and MessageHandler are also notably above the average
Response for a Class (RFC):
Is to measure Complexity. The larger the number of methods that can be invoked from a class, the greater the complexity of the class. A worst case value for possible responses will assist in appropriate allocation of testing time. ConfigurationInfo, SearchScreen, ServicesAPI, MusicProfile, PerfScreen, and FileInfo, have relatively high RFC. These classes need to be reviewed for reasons behind their high RFC values. A special effort should be made to review the ServicesApi class, because it has relatively high CBO and RFC.
Public Interface for Class (JMT)
MainGUI, ConfigurationInfo, FileInfo, MusicProfile, and ServicesApi, all show up as exceptional locations as they are much higher than the averages. These classes should be reviewed an maybe refactored to make sure that we need this many public accessors.
Methods per Class (MPC):
ConfigurationInfo, ServicesApi, MusicProfile, FileInfo, and PerfScreen have relatively high number of MPC, which contribute for higher RFC. The increase in methods are showing up where functionality has increased. This is probably ok but it looks like some classes contain much more functionality than others.
Fields per Class:
ConfigurationInfo and FileInfo class have relatively high number of FPC. Configuation info appears to be turinging into more of a data container with accessory functions.
Overall:
Though averages have not changed, the total number of methods have changed from 139 to 231 and total number of classes have changed from 19 to 32, which could be taken as a measure of new functionality added to the project. However, this measure should furthur be looked at in conjunction with the increase and variation in lines of code. This comparision helps us to find out where most of the new code is added and no one module or class is made relatively more complex.
Review MainGUI, JxtaSocketLinuxwif, MessageHandler, MPDialog, ConfigurationInfo, ServicesApi, MusicProfile and PrefScreen classes and make them less complex, if possible. Testing should focus on the new classes and also to verify the refactored classes.
JMetrics Analysis:
Cyclomatic complexity:
PeerDiscovery, PrefScreen, ConfigurationInfo, FileInfo, MusicProfile, ServicesApi, show up as the most complex. The complexity in the gui components should be reviewed and possibly refactored to remove an application logic from
Lines of code:
The lines of code view from Jmetrics showes many new classes including MPDialog, FileTransferRequest, id3, JxtaServerSocketLinuxwifi, JxtaSocketLinuxwifi, MessageHandler, SearchRequest, SearchResponse, ServicesApi, and WifiMessage.
Old class that have grown considerably include PrefScreen, SearchScreen, ConfigurationInfo, and MusicProfile.
New classes and classes that have grown significantly need some review and testing.
Method count:
The method count view from Jmetrics showes many new classes including MPDialog, FileTransferRequest, id3, JxtaServerSocketLinuxwifi, JxtaSocketLinuxwifi, MessageHandler, SearchRequest, SearchResponse, ServicesApi, and WifiMessage.
This metric also shows that ConfigurationInfo, FileInfo, and MusicProfile have grown significantly compared to the other classes.
Overall:
ConfigurationInfo, FileInfo, and MusicProfile are existing classes that have undergone many changes that need testing. Also, there are many new classes to test and review and possibly refactor.
RMS Analysis:
Fields per class:
Besides the new classes, MainGUI, SearchScreen, StatusScreen, ConfigurationInfo, FileInfo, and ServicesApi. are notably above the average. The data for this metric shows many classes with just a few fields, but most of these are unchanged from the last set of metrics. Classes with a large number of fields may be taking on to many tasks and could be split up. Review these classes and refactor if functionality should move elsewhere in the system. The RMS and JMT fields per class metric show a large discrepancy for FileInfo, FileIOHelper, ServicesApi, and WifiMessage. This difference is a possible sign of an overly complex class.
Methods per class:
The methods per class data shows several exceptional cases including ConfigurationInfo, FileInfo, FileTransferResponse, MusicProfile, and ServicesApi. ServicesApi only increased by one from the last set of metrics but is still quite large. I'm also mentioning FileTransferResponse even though it's a new class. I is interesting to see that FileTransferResponse has a lot more methods than FileTransferRequest, this should be reviewed but alas this was a typo upon further investigation.
Weighted Methods per Class
StatusScreen showed up as the exceptional case for this metric. Interesting to see this class show up as exceptional and no others. This shows the value of having different views and different metrics. This is a cylclomatic complexity metric that has singled out just one class. Review this class to find out why. ConfigurationInfo again shows up exceptional has having the single most complex method in the entire project. Review this method for sure by first going back to the RMS output and finding which method was critical.
Parameters per method:
This metric didn't show any really exceptional cases like the other metrics did. MPDialog and PrefScreen are the standouts but probably becasue they need to store more variables than other classes reletive to the logic that more or less just access the data.
Overall:
Review and test the new classes while checking old classes that have changed. Old classes of note are ConfigurationInfo, FileInfo, StatusScreen, FileIOHelper, ServicesApi. Other classes show up as exceptional as well so review them during code reviews.