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

The main significance of this document is two source systems namely GIPSY and DMARF. Intensional languages are required like GIPSY for absoluteness and forward practical investigations on the subject.DMARF mainly focuses on software architectural design and implementation on Distributed Audio recognition and its applications such as speaker identification which can run distributively on web services architecture. This mainly highlights security aspects in a distributed system, the Java data security framework (JDSF) in DMARF. ASSL (Autonomic System Specification Language) frame work is used to integrate a self-optimizing property for DMARF. GIPSY mainly depends on Higher-Order Intensional Logic (HOIL) and reflects three main goals Generality, Adaptability and Efficiency.Comment: 35 page

Towards Refactoring of DMARF and GIPSY Case Studies -- A Team 5 SOEN6471-S14 Project Report

This paper presents an analysis of the architectural design of two distributed open source systems (OSS) developed in Java: Distributed Modular Audio Recognition Framework (DMARF) and General Intensional Programming System (GIPSY). The research starts with a background study of these frameworks to determine their overall architectures. Afterwards, we identify the actors and stakeholders and draft a domain model for each framework. Next, we evaluated and proposed a fused DMARF over GIPSY Run-time Architecture (DoGRTA) as a domain concept. Later on, the team extracted and studied the actual class diagrams and determined classes of interest. Next, we identified design patterns that were present within the code of each framework. Finally, code smells in the source code were detected using popular tools and a selected number of those identified smells were refactored using established techniques and implemented in the final source code. Tests were written and ran prior and after the refactoring to check for any behavioral changes.Comment: 46 page

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

Software architecture consists of series of decisions taken to give a structural solution that meets all the technical and operational requirements. The paper involves code refactoring. Code refactoring is a process of changing the internal structure of the code without altering its external behavior. This paper focuses over open source systems experimental studies that are DMARF and GIPSY. We have gone through various research papers and analyzed their architectures. Refactoring improves understandability, maintainability, extensibility of the code. Code smells were identified through various tools such as JDeodorant, Logiscope, and CodePro. Reverse engineering of DMARF and GIPSY were done for understanding the system. Tool used for this was Object Aid UML. For better understanding use cases, domain model, design class diagram are built.Comment: 29 page

Towards Refactoring DMARF and GIPSY OSS

We present here an exploratory and investigatory study of the requirements, design, and implementation of two opensource software systems: the Distributed Modular Audio Recognition Framework (DMARF), and the General Intensional Programming System (GIPSY). The inception, development, and evolution of the two systems have overlapped and in terms of the involved developers, as well as in their applications. DMARF is a platform independent collection of algorithms for pattern recognition, identification and signal processing in audio and natural language text samples, become a rich platform for the research community in particular to use, test, and compare various algorithms in the broad field of pattern recognition and machine learning. Intended as a platform for intensional programming, GIPSY's inception was intended to push the field of intensional programming further, overcoming limitations in the available tools two decades ago. In this study, we present background research into the two systems and elaborate on their motivations and the requirements that drove and shaped their design and implementation. We subsequently elaborate in more depth about various aspects their architectural design, including the elucidation of some use cases, domain models, and the overall class diagram of the major components. Moreover, we investigated existing design patterns in both systems and provided a detailed view of the involved components in such patterns. Furthermore, we delve deeper into the guts of both systems, identifying code smells and suggesting possible refactorings. Patchsets of implementations of selected refactorings have been collected into patchsets and could be committed into future releases of the two systems, pending a review and approval of the developers and maintainers of DMARF and GIPSY.Comment: Team 6, SOEN6471 Summer 2014; 67 page

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).Comment: 53 page

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.Comment: 54 pages, 53 figure

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.Comment: 40 page

DMARF AND GIPSY High Level Architecture and Requirements Analysis

In the current scenario, many organizations invest on open-source systems which are becoming popular and result in rapid growth, where in many of them have not met the quality standards which resulted in need for assessing quality. Initially we represent our work by analyzing the two open source case studies which are (1) Distributed Modular Audio Recognition Framework (DMARF) is an open-source framework which consists of Natural Language Processing (NLP) implemented using Java which facilitates extensibility by adding new algorithms, (2) General Intensional Programming System (GIPSY) is a platform designed to support intensional programming languages which are built using intensional logic and their imperative counter-parts for the intensional execution model. During this background study we identified few metrics which are used to assess the quality characteristics of a software product defined by ISO standards. Among the metrics, we identified the number of the java classes and methods using SonarQube. Followed by that, the actors and stakeholders have been categorized and focused on the evolution of fully dressed use cases. Besides, we analyzed the requirements and compiled the conceptual UML domain model diagrams with the responsibilities and relationships based on the functionalities, which leads to the creation of the class diagrams. Later the analysis and interpretation of results has been done using the metric tools to verify results which have been implemented and to identify the code smells accordingly. Finally the implication is towards performing the system level refactoring by applying appropriate refactoring methods to enhance the quality and performance of the open source systems. Besides, the respective test cases have been portrayed to ensure that there is not much behavioral change with the existing architecture.Comment: 59 page

On Design and Implementation of the Distributed Modular Audio Recognition Framework: Requirements and Specification Design Document

We present the requirements and design specification of the open-source Distributed Modular Audio Recognition Framework (DMARF), a distributed extension of MARF. The distributed version aggregates a number of distributed technologies (e.g. Java RMI, CORBA, Web Services) in a pluggable and modular model along with the provision of advanced distributed systems algorithms. We outline the associated challenges incurred during the design and implementation as well as overall specification of the project and its advantages and limitations.Comment: 53 pages, 8 figures, 2 tables. A 2006 report on software design and implementation of Distributed MARF, which is a distributed extension of classical MARF documented at arXiv:0905.1235 . Parts are to appear at the CISSE'08 conference (Springer). The content of the document and code are open-source and released at http://marf.sf.net ; v2 adds missing .ind fil

Managing Distributed MARF with SNMP

The scope of this project's work focuses on the research and prototyping of the extension of the Distributed MARF such that its services can be managed through the most popular management protocol familiarly, SNMP. The rationale behind SNMP vs. MARF's proprietary management protocols, is that can be integrated with the use of common network service and device management, so the administrators can manage MARF nodes via a already familiar protocol, as well as monitor their performance, gather statistics, set desired configuration, etc. perhaps using the same management tools they've been using for other network devices and application servers.Comment: 39 pages, 16 figures, TOC, index. A large portion of this report has been published at PDPTA'08. This 2007 report is a successor of the original DMARF work documented at arXiv:0905.2459 ; v2 adds missing .ind file for the inde