Coupling based structural metrics for measuring the quality of a software (synopsis)
Download as DOC, PDF0 likes280 views
This document discusses measuring the quality of software modularization using coupling-based structural metrics. It proposes dividing a large codebase into fine-grained modules at the leaf directory level and applying four metrics - module interaction index, non-API function closedness index, API function usage index, and implicit dependency index - to measure coupling between modules. The existing system divides a codebase into two large modules, making analysis difficult, while the proposed system allows for easier maintenance and analysis by dividing files into individual modules and applying the metrics to different software versions.
Coupling based structural metrics for measuring the quality of a software (synopsis)
- 1. Coupling based structural metrics for measuring the quality of software (Synopsis) 1
- 2. Objective: The main objective of this Project is to measure the quality of modularization of object-oriented projects by Coupling-based Structural metrics. Goal is to analyses or measure how the code is framed for the particular software and Applying Software metrics to show the result. Methodology Much work has been done during the last several years on automatic approaches for code reorganization. Fundamental to any attempt at code reorganization is the division of the software into modules, publication of the API (Application Programming Interface) for the modules, and then requiring that the modules access each other’s resources only through the published interfaces. Our ongoing effort, from which we draw the work reported here, is focused on the case of reorganization of legacy software, consisting of millions of line of non-object oriented code, that was never modularized or poorly modularized to begin with. We can think of the problem as reorganization of millions of lines of code residing in thousands of files in hundreds of directories into modules, where each module is formed by grouping a set of entities such as files, functions, data structures and variables into a logically cohesive unit. Furthermore, each module makes itself available to the other modules (and to the rest of the world) through a published API. The work we report here addresses the fundamental issue of how to measure the quality of a given modularization of the software. 2
- 3. Modularization In this context "module" is considered to be a responsibility assignment rather than a subprogram. The modularizations include the design decisions which must be made before the work on independent modules can begin. Quite different decisions are included for each alternative, but in all cases the intention is to describe all "system level" decisions (i.e. decisions which affect more than one module). 3
- 4. Existing System: In the existing system large number of coding are divided into only two modules, so each module contains large number of coding. So in the existing system performance analysis takes more time as well as not more accurate. Some of the earliest contributions to software metrics deal with the measurement of code complexity and maintainability . From the standpoint of code modularization, some of the earliest software metrics are based on the notions of coupling and cohesion . Low intermodule coupling, high intramodule cohesion, and low complexity have always been deemed to be important attributes of any modularized software. The above-mentioned early developments in software metrics naturally led several researchers to question their theoretical validity. Theoretical validation implies conformance to a set of agreed-upon principles and these principles are usually stated in the form of a theoretical framework. . Proposed System: Modern software engineering dictates that a large body of software be organized into a set of modules. A module captures a set of design decisions which are hidden from other modules and the interaction among the modules should primarily be through module interfaces. In software engineering parlance, a module groups a set of functions or subprograms and data structures and often implements one or more business concepts. This grouping may take place on the basis of similarity of purpose or on the basis of commonality of goal 4
- 5. In the Proposed system we considered the leaf nodes of the directory hierarchy of the original source code to be the most fine-grained functional modules. All the files (and functions within) inside a leaf level directory were considered to belong to a single module. In this manner, all leaf level directories formed the module set for the software. After that we apply Coupling-based Structural Metrics as follows Coupling-Based Structural Metrics Starting with this section, we will now present a new set of metrics that cater to the principles. We will begin with coupling-based structural metrics that provide various measures of the function-call traffic through the API’s of the modules in relation to the overall function-call traffic. For that we have find the following four factors. 1. Module interaction index 2. Non-API Function Closed ness Index 3. API Function Usage Index 4. Implicit Dependency Index 5
- 6. 2.3. Difference b/w Existing and proposed System, Existing system, Million lines of code are divided into two modules. It was very tedious to analysis the code. Not applied to different versions to show the difference. Proposed System, For easy maintenance and analyzing each file is divided into single module. Metrics is applied to different version of a same software system. 6
- 7. 3.1 Hardware Specification • Hard disk : 40 GB • RAM : 512 MB • Processor Speed : 3.00GHz • Processor : Pentium IV Processor 3.2 Software Specification • JDK 1.5 • Swing Builder • MS-Access 7