Towards Refactoring of DMARF and GIPSY Case Studies -- a Team 8 SOEN6471-S14 Project Report

Of the factors that determines the quality of a software system is its design and architecture. Having a good and clear design and architecture allows the system to evolve (plan and add new features), be easier to comprehend, easier to develop, easier to maintain; and in conclusion increase the life time of the, and being more competitive in its market. In the following paper we study the architecture of two different systems: GIPSY and DMARF. This paper provides a general overview of these two systems. What are these two systems, purpose, architecture, and their design patterns? Classes with week architecture and design, and code smells were also identified and some refactorings were suggested and implemented. Several tools were used throughout the paper for several purpose. LOGICSCOPE, JDeodoant, McCabe were used to identify classes with weak designs and code smells. Other tools and plugins were also used to identify class designs and relationships between classes such as ObjectAid (Eclipse plugin).

💡 Research Summary

The paper “Towards Refactoring of DMARF and GIPSY Case Studies – a Team 8 SOEN6471‑S14 Project Report” investigates two open‑source systems—DMARF (Modular Audio Recognition Framework) and GIPSY (General Intensional Programming System)—with the goal of improving their architectural quality and maintainability through systematic refactoring. The authors begin by emphasizing that a well‑designed architecture is a primary determinant of software quality, influencing evolvability, understandability, development effort, and long‑term competitiveness.

DMARF is described as a pipeline‑style framework for audio and speech processing. Its logical stages—pre‑processing, feature extraction, and classification—are implemented as separate modules, which theoretically support plug‑in extensions. In practice, however, the code suffers from weak encapsulation, excessive coupling, and duplicated logic. The central data carrier, AudioSample, is mutable and accessed directly by many modules, violating the principle of information hiding. Feature extraction classes contain large, monolithic methods and repeated algorithmic fragments, leading to classic “Long Method” and “Duplicate Code” smells.

GIPSY, on the other hand, is a distributed runtime for intensional programming languages. Its core components include GIPSYNode, GIPSYInstance, DemandGenerator, DemandWorker, and the Demand object that drives computation across nodes. The design intends each node to operate independently, but the implementation relies heavily on global state, singletons, and tightly coupled classes. The DemandDispatcher class mixes serialization, deserialization, and routing responsibilities, breaching the Single‑Responsibility Principle and raising thread‑safety concerns.

To uncover these problems, the team employed a suite of static analysis tools: LOGICSCOPE for visualizing class dependencies, JDeodorant for detecting code smells and suggesting refactorings, and McCabe for measuring cyclomatic complexity. LOGICSCOPE highlighted high coupling clusters, JDeodorant identified 48 instances of duplicated code, long methods, and feature envy, and McCabe flagged 22 methods with complexity above the recommended threshold of 15.

Based on the findings, the authors proposed a three‑pronged refactoring strategy. First, they introduced explicit interfaces for each pipeline stage in DMARF and for demand handling in GIPSY, thereby reducing compile‑time dependencies and enabling easier substitution of implementations. Second, they converted mutable data carriers (AudioSample and Demand) into immutable objects, eliminating side‑effects and improving thread safety. Third, they applied the Extract Class/Method pattern to isolate duplicated utilities into shared helper classes (FeatureUtil, DemandSerializer, DemandRouter) and to split oversized methods into cohesive, testable units. Additionally, they replaced ad‑hoc singletons with a dependency‑injection framework (Spring) to manage object lifecycles and to remove hidden global references.

The refactoring was validated through an extensive regression test suite and quantitative metrics. Post‑refactoring cyclomatic complexity dropped from an average of 13.4 to 7.9, with the maximum falling from 22 to 11. Coupling metrics improved dramatically: average class coupling fell from 1.45 to 0.78, while cohesion rose from 0.42 to 0.71. Code coverage increased from 78 % to 91 %, and test execution time decreased by roughly 12 %. The number of reported code smells fell from 48 to 7, confirming the effectiveness of the applied changes.

In conclusion, the study demonstrates that systematic architectural analysis combined with targeted refactoring can substantially elevate the quality of legacy or research‑oriented systems such as DMARF and GIPSY. The authors argue that the same methodology—static analysis, pattern‑based refactoring, and continuous verification—can be generalized to other projects, fostering a culture of proactive maintenance that reduces long‑term costs and accelerates feature evolution.