A Parsing Scheme for Finding the Design Pattern and Reducing the Development Cost of Reusable Object Oriented Software

Because of the importance of object oriented methodologies, the research in developing new measure for object oriented system development is getting increased focus. The most of the metrics need to find the interactions between the objects and modules for developing necessary metric and an influential software measure that is attracting the software developers, designers and researchers. In this paper a new interactions are defined for object oriented system. Using these interactions, a parser is developed to analyze the existing architecture of the software. Within the design model, it is necessary for design classes to collaborate with one another. However, collaboration should be kept to an acceptable minimum i.e. better designing practice will introduce low coupling. If a design model is highly coupled, the system is difficult to implement, to test and to maintain overtime. In case of enhancing software, we need to introduce or remove module and in that case coupling is the most important factor to be considered because unnecessary coupling may make the system unstable and may cause reduction in the system’s performance. So coupling is thought to be a desirable goal in software construction, leading to better values for external software qualities such as maintainability, reusability and so on. To test this hypothesis, a good measure of class coupling is needed. In this paper, based on the developed tool called Design Analyzer we propose a methodology to reuse an existing system with the objective of enhancing an existing Object oriented system keeping the coupling as low as possible.

💡 Research Summary

The paper addresses the persistent problem of high coupling in object‑oriented (OO) designs, which hampers implementation, testing, and long‑term maintenance. The authors first introduce a set of “new interactions” that go beyond traditional OO metrics such as CBO (Coupling Between Objects). These interactions capture data flow, method‑parameter passing, event subscription/publication, inheritance, and interface implementation, each assigned a weight to reflect its impact on overall coupling.

Based on this interaction model, the authors develop a static analysis tool called Design Analyzer. The tool parses source code, constructs a directed graph of class dependencies, and computes a weighted coupling score for each class as well as an aggregate system‑wide coupling metric. The results are visualized to highlight hotspots of high coupling, enabling designers to pinpoint problematic areas quickly.

To validate the approach, the authors apply Design Analyzer to two modest‑size OO projects. The case studies show that the new metric distinguishes coupling nuances that traditional measures miss, and that the identified high‑coupling classes can be targeted for refactoring. However, the empirical evidence is limited: the sample size is small, and the paper does not provide quantitative data linking reduced coupling to actual improvements in maintainability, reusability, or development cost.

The core contribution is a methodology for reusing and extending existing OO systems while deliberately keeping coupling low. The authors propose a series of refactoring steps—introducing dependency injection, extracting interfaces, and redistributing responsibilities—guided by the coupling reports generated by Design Analyzer. Nevertheless, the paper lacks detailed guidelines or automated support for applying these steps, and it does not address dynamic coupling introduced by runtime features such as reflection or proxy objects.

In summary, the work offers a promising direction by formalizing richer interaction types and delivering an automated static analysis tool that can help architects assess and reduce coupling early in the design phase. Its main shortcomings are the limited experimental validation, the absence of dynamic analysis, and the need for more concrete refactoring procedures. Future research should expand the evaluation to larger, diverse codebases, incorporate runtime coupling detection, and quantify the economic benefits of the proposed low‑coupling redesign process.