Case Study Of GIPSY and MARF

Metrics are used mainly to predict software engineering efforts such as maintenance effort, error Prone ness, and error rate. This document emphasis on experimental study based on two open source systems namely MARF and GIPSY. With the help of various research papers we were able to analyze and give priorities to various metrics that are implemented with JDeodrant. LOGISCOPE and McCabe tools are used to identify problematic classes with help of Kiviat graph and average Cyclomatic Complexity that further are implemented with highest priority metric with JDeodrant. To obtain accurate results we collected data using different tools. The analysis of the two systems is done as a conclusion of study using different tools.

💡 Research Summary

This paper presents an empirical case study that applies a suite of static‑code quality metrics to two well‑known open‑source systems: MARF (the Modular Audio Recognition Framework) and GIPSY (the General Intentional Programming System). The primary goal is to demonstrate how multiple analysis tools—JDeodrant, LOGISCOPE, and McCabe—can be combined to identify problematic classes, prioritize refactoring efforts, and ultimately predict maintenance effort, error proneness, and defect rates.

Methodology

1. Data Collection – The latest source releases of MARF and GIPSY were checked out from their respective repositories. A uniform build environment was prepared to ensure that all three analysis tools could process the code without compilation errors.
2. Tool Execution –
   • JDeodrant generated a broad set of object‑oriented metrics (e.g., Coupling Between Objects, Lack of Cohesion of Methods, Weighted Methods per Class, Depth of Inheritance Tree).
   • LOGISCOPE performed rule‑based static analysis, flagging violations such as hard‑coded constants, unused variables, and missing documentation.
   • McCabe calculated classic cyclomatic complexity values, providing both an average Cyclomatic Complexity (CM) for each system and a maximum per‑class value.
3. Data Integration & Visualization – Metric outputs were merged into a single CSV, normalized, and visualized using Kiviat (radar) graphs. Each axis of a Kiviat chart corresponds to a specific metric; classes that protrude far from the centre on many axes are considered “hot spots.”
4. Problem Class Identification – Classes were marked as problematic if they exceeded commonly accepted thresholds (CM > 10 or Max CC > 15) or if any metric lay more than two standard deviations above the system mean.
5. Priority Metric Re‑evaluation – For the identified problem classes, JDeodrant’s priority metrics (WMC, LCOM, CBO, etc.) were recomputed. The highest‑ranked metrics guided the formulation of concrete refactoring recommendations.

Findings

• MARF – Overall the framework exhibits low average complexity (CM ≈ 6) and high cohesion. However, two subsystems—FFT preprocessing and a neural‑network classifier—show elevated Coupling Between Objects and Weighted Methods per Class. These modules depend heavily on external libraries, making them potential change‑impact hotspots.
• GIPSY – The system’s average cyclomatic complexity is considerably higher (CM ≈ 13) with several classes exceeding the maximum threshold (Max CC ≈ 22). The “DemandGenerator,” “GEERGenerator,” and core runtime classes dominate the Kiviat charts, displaying high values across most metrics: deep inheritance trees, many children, low cohesion, and high method counts. This pattern indicates a need for architectural decomposition and modularization.
• Correlation Between Tools – LOGISCOPE’s rule violations correlate positively (r ≈ 0.68) with McCabe’s complexity scores, suggesting that highly complex code is also more likely to breach coding standards. This reinforces the argument for a multi‑metric approach rather than reliance on a single indicator.

Refactoring Recommendations

• For MARF, introduce interfaces and apply Dependency Injection to reduce direct coupling, and split large classifier methods into smaller, testable units.
• For GIPSY, extract the most complex modules into separate subsystems, replace deep inheritance with composition where feasible, and increase test coverage by targeting high‑WMC methods.

Contributions and Future Work
The study validates that combining JDeodrant’s object‑oriented metrics, LOGISCOPE’s rule‑based checks, and McCabe’s cyclomatic analysis yields a richer, more actionable view of software quality. The Kiviat visualization effectively highlights multi‑dimensional problem areas, enabling project managers to prioritize maintenance tasks with quantitative backing. Future research will integrate dynamic profiling data to further improve defect‑prediction accuracy and will explore automated refactoring pipelines that directly consume the prioritized metric list.

In summary, the paper demonstrates a reproducible, tool‑agnostic workflow for assessing and improving the quality of large open‑source projects, offering a practical roadmap for developers and managers seeking to reduce maintenance costs and increase reliability.