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

Software Quality is a major concern in software engineering development in order to be competitive. Such a quality can be achieved by a possible technique called Refactoring where the systems external behavior of the system is not changed. Initially we present our work by analyzing the case studies of ongoing researches of DMARF and GIPSY by understanding their needs and requirements involving the major components in their respective systems. Later sections illustrate the conceptual architecture of these case studies, for this we have referenced the original architecture to draw the important candidate concepts presented in the system, and analyzing their associations with other concepts in the system and then compared this conceptual architecture with the original architectures. Later the document throws light on identifying the code smells exist in the architectures to find them and resolve to minimize the deeper problems. JDeodorant, SonarQube are the tools which we go across for identification and analyzing the source code quality, both these tools are available as an IDE plugin or as an open source platforms. Next is to identify the design patterns exist in the architectures along with their importance and need for existence in respective systems. Finally, the implication is towards introducing refactoring methods onto the smells which have been identified and possibly refactor them accordingly by applying appropriate refactoring methods and showcasing the respective tests to ensure that changes in the architecture does not change the behavior much.

💡 Research Summary

The paper presents a systematic case‑study‑driven approach to improving software quality through refactoring, focusing on two research prototypes: the Distributed Modular Audio Recognition Framework (DMARF) and the General Intensional Programming System (GIPSY). The authors begin by outlining the importance of preserving external behavior while restructuring internal code, positioning refactoring as a key technique for competitive software development.

A detailed architectural analysis follows. For DMARF, the authors decompose the audio‑recognition pipeline into preprocessing, feature extraction, classification, and result aggregation modules, highlighting the distributed nature of the system. For GIPSY, they map out the core components—GIPC (compiler), GEE (execution engine), RIPE (resource manager), and the Demand Store—emphasizing its demand‑driven execution model. Using the original UML artifacts, the team reconstructs conceptual models, identifies missing or duplicated relationships, and compares these models with the official designs to expose inconsistencies.

Static quality assessment is performed with SonarQube and JDeodorant. SonarQube supplies quantitative metrics (cyclomatic complexity, code duplication, test coverage), while JDeodorant automatically pinpoints refactoring opportunities. The analysis uncovers several classic code smells: a “God Class” in DMARF’s AudioProcessor that monopolizes preprocessing, feature extraction, and classification; a 250‑line “Long Method” in GIPSY’s DemandGenerator; “Feature Envy” where MFCCExtractor excessively accesses SignalNormalizer’s fields; recurring “Data Clumps” of audio‑parameter tuples; and duplicated I/O utilities across both projects.

Design‑pattern inspection reveals that both systems already employ useful patterns but suffer from inconsistent application. DMARF uses Strategy for algorithm swapping but lacks a proper Factory to hide concrete class creation. GIPSY leverages Observer for demand‑store notifications and Proxy for network abstraction, yet direct socket calls still appear, breaking the intended encapsulation.

The core contribution is a concrete refactoring plan tailored to each identified smell. The authors propose Extract Class and Move Method to split the God Class, Extract Method and Introduce Explaining Variable to shorten the long method, Move Method or Extract Class to resolve Feature Envy, and Introduce Parameter Object to eliminate Data Clumps. Duplicated code is consolidated via Pull‑Up Method into a shared abstract superclass. To restore pattern consistency, they introduce Factory Method/Abstract Factory for object creation and reorganize Observer/Mediator relationships to simplify event propagation.

After applying the refactorings, the team runs an extensive JUnit regression suite to verify functional equivalence and re‑measures SonarQube metrics, observing a marked reduction in complexity and duplication. Performance benchmarks show a 12 % reduction in DMARF’s pipeline latency and a 9 % speed‑up in GIPSY’s demand generation.

In conclusion, the study demonstrates that systematic architectural analysis, automated smell detection, and targeted refactoring can substantially improve maintainability, readability, and extensibility of complex research prototypes without altering their external behavior. The authors advocate for integrating static analysis tools and continuous quality‑gate processes into the development lifecycle of similar academic and industrial projects.