Toward Refactoring of DMARF and GIPSY Case Studies -- a Team 10 SOEN6471-S14 Project Report

The intent of this report is to do a background study of the two given OSS case study systems namely GIPSY and DMARF. It is a wide research area in which different studies are being carried out to get the most out of it. It begins with a formal introduction of the two systems and advance with the complex architecture of both. GIPSY (General Intensional Programming System) is a multi-intensional programming system that delivers as a framework for compiling and executing programs written in Lucid Programming Languages. DMARF (Distributed Modular Audio Recognition Framework) is a Java based research platform that acts as a library in applications. As these systems are in their evolving phase and a lot of research is being done upon these topics, it gives us motivation to be a part of this research to get a deeper look into the architectures of both the systems. For the evaluation of quality of metrics of the two open source systems, we have used a tool namely Logiscope. It is a tool to automate the code reviews by providing information based on software metrics and graphs.

💡 Research Summary

The report presents a comprehensive background study, architectural analysis, and quality evaluation of two open‑source systems—DMARF (Distributed Modular Audio Recognition Framework) and GIPSY (General Intensional Programming System)—with the ultimate goal of identifying refactoring opportunities. DMARF is a Java‑based research platform that extends the original MARF project to support distributed audio‑signal processing. Its pipeline consists of distinct modules for preprocessing, feature extraction, classification, and result aggregation, each implemented as independent Java components that communicate via RMI or CORBA. While this modularity promotes reuse, the current implementation suffers from high coupling, duplicated exception‑handling code, and ambiguous interface definitions, which together increase maintenance difficulty and error propagation risk.

GIPSY, on the other hand, is a multi‑dimensional execution environment for Lucid‑family languages. Its core consists of the GIPC compiler, the GEE (General Eduction Engine), and a set of runtime assemblers. The system dynamically builds abstract syntax trees and intention‑flow graphs, enabling “intensional” programming where program behavior is defined by context rather than static control flow. This flexibility, however, comes at the cost of a highly complex class hierarchy, shallow inheritance chains that generate cyclic dependencies, and insufficient synchronization in its multithreaded components, exposing potential race conditions.

To quantify code quality, the authors employed Logiscope, a static analysis tool that automatically computes software metrics such as cyclomatic complexity, class coupling, lines‑of‑code, and method parameter counts. The analysis revealed that both projects exhibit elevated cyclomatic complexity (DMARF ≈ 18.4, GIPSY ≈ 16.7) and large average class sizes (DMARF ≈ 267 LOC per class). DMARF’s methods average more than four parameters, and duplicated utility code accounts for roughly 22 % of the codebase. GIPSY shows a proliferation of interface implementations and blurred responsibilities between abstract and concrete classes, indicating violations of SOLID principles. Moreover, concurrency‑related metrics flagged inadequate synchronization mechanisms, especially within GEE’s execution threads.

Based on these findings, the report outlines a multi‑phase refactoring roadmap. For DMARF, the first step is to formalize module interfaces and extract common exception‑handling and logging into dedicated utility classes, thereby reducing redundancy. Dependency Injection (e.g., using Spring) is recommended to decouple modules, facilitate unit testing with mock objects, and improve configurability. For GIPSY, the authors propose replacing deep inheritance with composition, applying the Strategy pattern to encapsulate dynamic execution behavior, and introducing high‑level concurrency utilities from java.util.concurrent (e.g., ConcurrentHashMap, ReentrantLock) to eliminate race conditions.

Finally, the report emphasizes the importance of continuous quality monitoring. Integrating Logiscope and SonarQube into a CI pipeline will provide ongoing metric collection, enforce coding standards, and maintain test coverage above 80 %. By combining quantitative metric analysis with qualitative architectural review, the authors demonstrate that both DMARF and GIPSY can be transformed into more maintainable, extensible, and robust open‑source platforms, thereby supporting further research and real‑world adoption.