Table 2 - uploaded by Gillian Z. Heller
Content may be subject to copyright.
Data for six successive versions of three Linux kernel modules
Source publication
The increase in maintenance of software and the increased amounts of reuse are having major positive impacts on the quality of software, but are also introducing some rather subtle negative impacts on the quality. Instead of talking about existing problems (faults), developers now discuss potential problems, that is, aspects of the program that do...
Contexts in source publication
Context 1
... for six successive versions of three kernel modules are shown in Table 2, and also in Figure 1, which displays the data of Table 2 in graphical form. A blank in the date column denotes that the code has not changed between successive versions. ...
Context 2
... for six successive versions of three kernel modules are shown in Table 2, and also in Figure 1, which displays the data of Table 2 in graphical form. A blank in the date column denotes that the code has not changed between successive versions. ...
Context 3
... were 914 instances of common coupling between module Panic.c and all the other modules in version 2.1.104 of Linux. As can be seen in the second column of Table 2, the number of instances of common coupling then steadily increased to 946 in version 2.1.109, even though the code for Panic.c ...
Similar publications
The importance of object-oriented software metrics is increasing day by day to evaluate and predict the quality of software. Coupling is one of the object-oriented metrics. It is a dependency degree to which one program module depends on one of the other modules. Coupling measures play a significant role in the quality aspect of object-oriented sof...
Citations
... According to the recent studies 90% of the maintenance is carried out in either corrective or perfective ways whereas corrective alone corresponds to 70% of all modifications [6]. Thus corrective maintenance is also called as 'traditional maintenance' and the other forms are referred as 'software evolution'. ...
... 5 Wilde and Huitt 1992 [26] Illustrated some unique maintenance issues of OO systems and evaluated the difficulties linked to it. 6 Li and Henry 1993 [27] Considered the applicability of OO complexity metrics in two commercial systems and summarized that these metrics can predict of maintenance effort. 7 Chidamber and Kemerer 1994 [12] Explored some of the OO design metrics for computing maintainability effort such as WMC, DIT, NOC, CBO, RFC and LCOM. ...
Software quality is an integral aspect of development scheme that determines the degree to which the software in use will meet the expectations of the customer. Maintainability has obtained its significance as an attribute of software quality. However in spite of the importance, there are no definite criteria to measure it. Hence great research interest is required for developing and applying sophisticated techniques to estimate software maintenance effort. As the object-oriented systems use a large number of small methods, a unique maintenance problem is associated with it. The relationship between OO metrics and software maintenance effort is complex and non linear. This paper surveys the different studies regarding software maintainability on object-oriented paradigm which provide further assistance in succeeding researches.
... After a software product is released, it requires continued maintenance and evolution. Coupling between software modules strengthens the dependency of one module on others and increases the probability that changes in one module may affect the other modules, which makes maintenance and evolution difficult and more likely to introduce regression faults (Banker et al., 1993;Schach et al., 2003;Yu et al., 2004). It has been shown that strong coupling is related to fault-proneness of a software system (Kafura and Henry, 1981;Selby and Basili, 1991;Troy and Zweben, 1981). ...
Coupling measures the degree of dependencies between software modules. Considerable research has been performed to relate software coupling with software understandability, maintainability, and reusability, which are the key properties of software maintenance and evolution. However, only a few research works have been reported that study the relationships between software coupling and software performance. This study implemented two benchmarks that measure and compare the performance of software programs implemented with different kinds of coupling, common coupling, data coupling, and stamp coupling. The experiment is run on three different platforms, Windows, Linux, and Mac. The results show that (1) the relative performance of systems implemented using different software coupling is platform dependent; (2) while loose coupling is more favorable than strong coupling with respect to software maintenance and evolution, it has the drawback of reduced performance of a software program. Based on this study, we make some suggestions to balance the use of strong coupling and loose coupling in designing evolving software systems in order to achieve both maintainability and evolvability without compromising on performance.
... The software couplings can be divided as data coupling (simple data are passed as parameters in a function call), stamp coupling (data structures are passed as parameters in a function call), external coupling (two modules access the same file/database), and common coupling (two modules access the same global variable), in which, common coupling is considered to be a strong form of coupling. That is, common coupling induces high degree of dependencies between software modules and accordingly makes software modules difficult to understand, maintain , and reuse [8, 7]. Software evolution is inevitable. ...
... Many software products, such as operating systems and database systems, are called kernel-based software [2]. That is, the software system consists of architecture and/or platform independent kernel modules, together with specific architecture and/or platform dependent nonkernel modules [8, 1]. Software product line is another example of kernel-based system, in which, the core assets are considered as kernel modules, and custom assets are considered as nonkernel modules.Figure 1 depicts the production of kernel-based software: Each implementation/installation of kernel-based software involves the use of all kernel modules and optional nonkernel modules. ...
Common coupling increases the interdependencies between software modules. It should be avoided if possible. In previous work, we presented two types of categorization of common coupling, one is for single-kernel-based software, one is for multi-kernel-based-software. In this paper, we analyze the relationships between these two types of categorization and apply them to study the evolution of the complexity of Apple Darwin. The same conclusion about Darwin's evolution is drawn based on the two types of categorization of common coupling: From version XNU-517 to version XNU-792, Darwin has restructured to reduce the number of diculty-inducing high category (level) global variables in order to reduce the system complexity. However, due to the definition-use dependencies, the complexity of Darwin induced by global variables has increased from version XNU-517 to version XNU-792.
... [140] 2009 CIA 1 1 Discussed an approach for the comparision of the change impact analysis methods based on the architectural level. [159] Proved that the common coupling should be calculated on temporal variables like release dates rather than release sequence number. Validated on Linux. ...
... There are several different coupling categorizations [1], [2], [3], all of which include common coupling (two modules are common coupled if they access the same global variable). Common coupling is considered to be a strong form of coupling, that is, it induces a high degree of dependency between software components, making the components difficult to understand and maintain [4]. Coupling between components strengthens the dependency of one component on others and increases the probability that changes in one component may affect other components, which makes maintenance difficult and likely to introduce regression faults [5], [6]. ...
Process management is one of the most important and relevant tasks in operating system design. In this paper, we investigate the process management in Linux, FreeBSD, and Darwin. We compare the data structures used to represent process and the global variables used to control the current active process in three operating systems. Based on the definition-use analysis, we study how the number of instances of process control global variable can affect the maintenance of the operating system kernel. This effect is demonstrated in an empirical study in the relationship between the number of kernel lines of code modified and the number of instances and number of definitions of process controller global variable. We conclude that the way process management implemented in Linux makes it more difficult to maintain than FreeBSD and Darwin. 1. Introduction Coupling is a measure of the degree of dependency between two software components (classes, modules, packages, or the like). A good software system should have high cohesion within each component and low coupling between components. There are several different coupling categorizations [1], [2], [3], all of which include common coupling (two modules are common coupled if they access the same global variable). Common coupling is considered to be a strong form of coupling, that is, it induces a high degree of dependency between software components, making the components difficult to understand and maintain [4].
... There are many different categorizations of coupling, all of which include common (global) coupling (two software components are common coupled if they reference the same global variable). Certain types of coupling, especially common coupling, are considered to present risks for software development and, in particular, for maintenance [7]. Common coupling can also be used to measure the dependencies between software components [8]. ...
... There are several different coupling categorizations [6, 9], all of which include common coupling. Common coupling is considered to be a strong form of coupling, that is, it induces strong dependencies between software components, making software components difficult to understand, maintain, and reuse [7]. If a software component has strong dependencies (such as common coupling) on other components, it requires more effort to be adapted to a new environment. ...
An obstacle to software reuse is the large number of major modifications that frequently have to be made as a consequence of dependencies within the reused software components. In this paper, common coupling is categorized and used as a measure of the dependencies between software components. We compared common coupling in three operating systems, Linux, FreeBSD, and Mach, and related it to the reuse effort of these systems. The measure is evaluated by studying the creation of two operating systems, MkLinux which is based on the reuse of Linux and Mach, and Darwin which is based on the reuse of FreeBSD and Mach. We conclude that the way that common coupling is implemented in Linux kernel induces large dependencies between software components, which required more effort in order to be reused to produce MkLinux, while the common coupling implemented in the Mach and FreeBSD kernels induces few dependencies between software components, which required less effort in order to be reused to produce Darwin.
... There are many different categorizations of coupling, all of which include common (global) coupling (two software components are common coupled if they reference the same global variable). Certain types of coupling, especially common coupling, are considered to present risks for software development and, in particular, for maintenance [7]. Common coupling can also be used to measure the dependencies between software components [8]. ...
... There are several different coupling categorizations [6,9], all of which include common coupling. Common coupling is considered to be a strong form of coupling, that is, it induces strong dependencies between software components, making software components difficult to understand, maintain, and reuse [7]. ...
An obstacle to software reuse is the large number of major modifications that frequently have to be made as a consequence of dependencies within the reused software components. In this paper, common coupling is categorized and used as a measure of the dependencies between software components. We compared common coupling in three operating systems, Linux, FreeBSD, and Mach, and related it to the reuse effort of these systems. The measure is evaluated by studying the creation of two operating systems, MkLinux which is based on the reuse of Linux and Mach, and Darwin which is based on the reuse of FreeBSD and Mach. We conclude that the way that common coupling is implemented in Linux kernel induces large dependencies between software components, which required more effort in order to be reused to produce MkLinux, while the common coupling implemented in the Mach and FreeBSD kernels induces few dependencies between software components, which required less effort in order to be reused to produce Darwin.
... However, to enable intermodule communication, some form of coupling must exist . Common coupling is an undesirable form of coupling introduced when modules reference the same global data [12] (and worse, common coupling can be clandestine in the sense that it can be introduced without explicit changes to a module; see [16] ). The many reasons why global variable usage is considered harmful and therefore should be avoided are well documented in [8, 12, 17, 24]. ...
... We chose to extract the data ourselves since we already had an existing infrastructure for analyzing ELF object files and also to improve efficiency. Schach et al. [16] and later Yu et al. [24] examined global variable usage in the Linux kernel. The initial work in [16] discovered that slightly more than half of all modules examined suffered from some form of clandestine coupling. ...
... Schach et al. [16] and later Yu et al. [24] examined global variable usage in the Linux kernel. The initial work in [16] discovered that slightly more than half of all modules examined suffered from some form of clandestine coupling. The latter work in [24] continued the examination of clandestine coupling between kernel and non-kernel modules in Linux. ...
As the useful life expectancy of software continues to increase, the task of maintaining the source code has be- come the dominant phase of the software life-cycle. In order to improve the ability of software to age and successfully evolve over time, it is important to identify system design and programming practices which may result in increasing the difficulty of maintaining the source code. This study attempts to correlate the use of global data to the maintainability of several widely deployed, large scale software projects as they evolve over time. Two measures are proposed to quantify the maintenance effort of a project. The first measure compares the number of CVS revisions for all source files in a release to the number of revisions applied to the files where the usage of global data is most prevalent. A second degree of change is characterized by contrasting the amount of source code that was changed overall with the changes made to those source files which contain the majority of the references to global data. We observed a statistically significant positive correla- tion between the number of file revisions to global variable references and lines of code changed to global variable ref- erences. In all cases the correlation between the number of revisions and global variable references was stronger. This provides evidence that global variable usage negatively im- pacts software maintainability by increasing both the num- ber and the extent of the changes required to accomplish a maintenance phase task.
... Another issue that has surfaced is aliasing, which may be considered as a variant of clandestine common coupling [22]. As before, let ptr be a pointer to a variable of type struct type. ...
Common coupling (sharing global variables across modules) is widely accepted as a measure of software quality and maintainability; a low level of common coupling is necessary (but not sufficient) to ensure maintainability. But when the global variables in question are large multi-field data structures, one must decide whether to consider such data structures as single units, or examine each of their fields individually. We explore this issue by re-analyzing a case study based on the Linux operating system. We determine the common coupling at the level of granularity of the component fields of large, complex data structures, rather than at the level of the data structures themselves, as in previous work. We claim that this is the appropriate level of analysis based on how such data structures are used in practice, and also that such a study is required due to concern that coarse-grained analysis leads to false coupling. We find that, for this case study, the granularity does not have a decisive effect on the results. In particular, our results for coupling based on individual fields are similar in spirit to the results reported previously (by others) based on using complete data structures. In both cases, the coupling indicates that the system kernel is vulnerable to modifications in peripheral modules of the system.
... Since Stevens et al. (1974) introduced the concept of software component dependency, reference coupling, including some specific categories, such as common coupling (Schach et al., 2003; Yu et al., 2004) has been widely studied (Chidamber and Kemerer, 1994; Briand et al., 1999; Arisholm et al., 2004). Most of the work performed in the past decades is intended to understand the relationship between reference coupling and the external quality factors of a software product. ...
After a software system has been delivered, it inevitably has to change to remain useful. Evolutionary coupling measures the
change dependencies between software components. Reference coupling measures the architecture dependencies between software
components. In this paper, we present a method to correlate evolutionary coupling and reference coupling. We study the evolution
of 597 consecutive versions of Linux and measure the evolutionary coupling and reference coupling among 12 kernel modules.
We compare 12 pairs of evolutionary coupling data and reference coupling data. The results show that linear correlation exists
between evolutionary coupling and reference coupling. We conclude that in Linux, the dependencies between software components
induced via the system architecture have noticeable effects on kernel module co-evolution.
