面向方面软件动态耦合的度量

耦合性是两个模块间相互作用的测度。面向方面编程是一种新的编程范型,它支持关注点的分离。目前,对于面向方面软件耦合度量的常用方法是对软件进行结构分析和静态代码分析。然而,由于系统中的动态绑定以及代码中大量无用的方面代码导致静态度量结果无法精确地反映程序运行时的实际耦合。首先提出适用于面向方面软件的动态耦合度量框架。接着,在该框架的基础上,根据不同的耦合关系类型,形式化定义了动态耦合度量指标集,并验证数学属性。最后,讨论了动态耦合度量工具的实现。     

A Survey of Dynamic Software Metrics

Software metrics help us to make meaningful estimates for software products and guide us in taking managerial and technical decisions. However, conventional static metrics have been found to be inadequate for modern object-oriented software due to the presence of object-oriented features such as polymorphism, dynamic binding, inheritance and unused code. This fact motivates us to focus on dynamic metrics in place of traditional static metrics. Moreover, dynamic metrics are more precise than static metrics as they are able to capture the dynamic behaviour of the software system during measurement. These dynamic metrics are usually obtained from the execution traces of the code or from the executable models. In this paper, advantages of dynamic metrics over static metrics are discussed and then a survey of the existing dynamic metrics is carried out. These metrics are characterized into different categories such as dynamic coupling metrics, dynamic cohesion metrics. Towards end of the paper, potential research challenges and opportunities in the field of dynamic metrics are identified.     

基于UML时序图的系统运行时耦合度量方法

面向对象耦合性是软件质量重要的内部属性，该文分析了现有基于静态分析的耦合度量，以及其因继承和多态的使用而产生对运行时耦合度量的不足。提出了以用于系统动态建模的UML时序图为基础，定义了反映系统运行时的耦合度量指标，并通过实例验证了耦合指标定义的可操作性和实用性。     

Using the Conceptual Cohesion of Classes for Fault Prediction in Object-Oriented Systems

High cohesion is a desirable property of software as it positively impacts understanding, reuse, and maintenance. Currently proposed measures for cohesion in Object-Oriented (OO) software reflect particular interpretations of cohesion and capture different aspects of it. Existing approaches are largely based on using the structural information from the source code, such as attribute references, in methods to measure cohesion. This paper proposes a new measure for the cohesion of classes in OO software systems based on the analysis of the unstructured information embedded in the source code, such as comments and identifiers. The measure, named the Conceptual Cohesion of Classes (C3), is inspired by the mechanisms used to measure textual coherence in cognitive psychology and computational linguistics. This paper presents the principles and the technology that stand behind the C3 measure. A large case study on three open source software systems is presented which compares the new measure with an extensive set of existing metrics and uses them to construct models that predict software faults. The case study shows that the novel measure captures different aspects of class cohesion compared to any of the existing cohesion measures. In addition, combining C3 with existing structural cohesion metrics proves to be a better predictor of faulty classes when compared to different combinations of structural cohesion metrics.     

Quantifying structural attributes of system decompositions in 28 feature-oriented software product lines

A key idea of feature orientation is to decompose a software product line along the features it provides. Feature decomposition is orthogonal to object-oriented decomposition—it crosscuts the underlying package and class structure. It has been argued often that feature decomposition improves system structure by reducing coupling and by increasing cohesion. However, recent empirical findings suggest that this is not necessarily the case. In this exploratory, observational study, we investigate the decompositions of 28 feature-oriented software product lines into classes, features, and feature-specific class fragments. The product lines under investigation are implemented using the feature-oriented programming language Fuji. In particular, we quantify and compare the internal attributes import coupling and cohesion of the different product-line decompositions in a systematic, reproducible manner. For this purpose, we adopt three established software measures (e.g., coupling between units, CBU; internal-ratio unit dependency, IUD) as well as standard concentration statistics (e.g., Gini coefficient). In our study, we found that feature decomposition can be associated with higher levels of structural coupling in a product line than a decomposition into classes. Although coupling can be concentrated in very few features in most feature decompositions, there are not necessarily hot-spot features in all product lines. Interestingly, feature cohesion is not necessarily higher than class cohesion, whereas features are more equal in serving dependencies internally than classes of a product line. Our empirical study raises critical questions about alleged advantages of feature decomposition. At the same time, we demonstrate how our measurement approach of coupling and cohesion has potential to support static and dynamic analyses of software product lines (i.e., type checking and feature-interaction detection) by facilitating product sampling.     

Evaluating code complexity triggers,use of complexity measures and the influence of code complexity on maintenance time

Code complexity has been studied intensively over the past decades because it is a quintessential characterizer of code’s internal quality. Previously, much emphasis has been put on creating code complexity measures and applying these measures in practical contexts. To date, most measures are created based on theoretical frameworks, which determine the expected properties that a code complexity measure should fulfil. Fulfilling the necessary properties, however, does not guarantee that the measure characterizes the code complexity that is experienced by software engineers. Subsequently, code complexity measures often turn out to provide rather superficial insights into code complexity. This paper supports the discipline of code complexity measurement by providing empirical insights into the code characteristics that trigger complexity, the use of code complexity measures in industry, and the influence of code complexity on maintenance time. Results of an online survey, conducted in seven companies and two universities with a total of 100 respondents, show that among several code characteristics, two substantially increase code complexity, which subsequently have a major influence on the maintenance time of code. Notably, existing code complexity measures are poorly used in industry.     

The effectiveness of software metrics in identifying error-prone classes in post-release software evolution process

Many empirical studies have found that software metrics can predict class error proneness and the prediction can be used to accurately group error-prone classes. Recent empirical studies have used open source systems. These studies, however, focused on the relationship between software metrics and class error proneness during the development phase of software projects. Whether software metrics can still predict class error proneness in a system’s post-release evolution is still a question to be answered. This study examined three releases of the Eclipse project and found that although some metrics can still predict class error proneness in three error-severity categories, the accuracy of the prediction decreased from release to release. Furthermore, we found that the prediction cannot be used to build a metrics model to identify error-prone classes with acceptable accuracy. These findings suggest that as a system evolves, the use of some commonly used metrics to identify which classes are more prone to errors becomes increasingly difficult and we should seek alternative methods (to the metric-prediction models) to locate error-prone classes if we want high accuracy.     

Distance-based software measurement: necessary and sufficient properties for software measures

Axiomatic approaches to software measurement present sets of necessary, but not sufficient measure axioms. The insufficiency of the measure axioms implies that they are useful to invalidate existing software measures, but not to validate them. In this paper, a set of measure axioms is presented whose sufficiency is guaranteed by measurement theory. The axioms referred to are the metric axioms, used in mathematics to define measures of distance. We present a constructive procedure that defines software measures satisfying these axioms. As an illustration of distance-based software measurement, a measure is defined for the aggregation coupling of object classes.     

MMRUC3: A recommendation approach of move method refactoring using coupling,cohesion, and contextual similarity to enhance software design

Placement of methods is one of the most important design activities for any object‐oriented application in terms of coupling and cohesion. Due to method misplacement, the application becomes tightly coupled and loosely cohesive, reflecting inefficient design. Therefore, a feature envy code smell emerges from the application, as many methods use more features of other classes than its current class. Hence, development and maintenance time, cost, and effort are increased. To refactor the code smell and enhance the design quality, move method refactoring plays a significant role through grouping similar behaviors of methods. This is because the manual refactoring process is infeasible due to the necessity of huge time and most of the existing techniques consider only coupling‐based and/or cohesion‐based information of nonstatic entities (methods and attributes) for the recommendation. However, this article proposes an approach that uses contextual information, based on information retrieval techniques, along with dependency (coupling and cohesion)‐based information of the application for the recommendation. In addition, the approach incorporates both static and nonstatic entities in the recommendation process. For validation, the approach is applied on seven well‐known open source projects. The results of the experimental evaluation indicate that the proposed approach provides better results with an average precision of 18.91%, a recall of 69.91%, and an F‐measure of 29.77% than the JDeodorant tool (a widely used eclipse plugin for refactorings). Moreover, this article establishes several relationships between the accuracy of the approach and project standards and sizes.     

检测JavaScript类的内聚耦合Code Smell

Code Smell是软件程序中存在不良设计和不良实现的征兆.正确地检测和识别Code Smell可以指导软件重构,提高软件的可用性和可靠性.通过Code Smell的度量指标,可以量化软件的设计问题.JavaScript已成为最常用的编程语言之一,类是JavaScript的设计模式,优秀类的设计体现为高内聚和低耦合.现有关于JavaScript内聚耦合的Code Smell研究均在微观的层面,即函数和语句上进行.它们可以提供程序实现的重构建议,但无法分析内聚耦合相关的软件系统设计问题.针对FE、DC和Blob这3种类的内聚耦合Code Smell,提出一种JavaScript类的内聚耦合Code Smell检测方法JS4C.该方法基于静态分析,同时适用于客户端和服务端程序.它通过遍历软件系统中所有的类,利用源程序的文本相似度特征和结构特征,识别Code Smell并检测其强度.在结构特征检测中,JS4C使用了经扩展的对象类型推断及非严格的耦合分散度度量法NSCDISP,有效地降低了解释型语言的静态分析过程中,类型信息缺失对检测产生的影响.实验通过对6个开源项目的分析表明,JS4C对内聚耦合设计问题有良好的检测效果.     

Estimating software testing complexity

ContextComplexity measures provide us some information about software artifacts. A measure of the difficulty of testing a piece of code could be very useful to take control about the test phase.ObjectiveThe aim in this paper is the definition of a new measure of the difficulty for a computer to generate test cases, we call it Branch Coverage Expectation (BCE). We also analyze the most common complexity measures and the most important features of a program. With this analysis we are trying to discover whether there exists a relationship between them and the code coverage of an automatically generated test suite.MethodThe definition of this measure is based on a Markov model of the program. This model is used not only to compute the BCE, but also to provide an estimation of the number of test cases needed to reach a given coverage level in the program. In order to check our proposal, we perform a theoretical validation and we carry out an empirical validation study using 2600 test programs.ResultsThe results show that the previously existing measures are not so useful to estimate the difficulty of testing a program, because they are not highly correlated with the code coverage. Our proposed measure is much more correlated with the code coverage than the existing complexity measures.ConclusionThe high correlation of our measure with the code coverage suggests that the BCE measure is a very promising way of measuring the difficulty to automatically test a program. Our proposed measure is useful for predicting the behavior of an automatic test case generator.     

Better software through operational dynamics

Much of the existing theory about software focuses on its static behaviour, based on analysis of the source listing. Explorers of requirements, estimation, design, encapsulation, dataflow, decomposition, structure, and code complexity all study the static nature of software, concentrating on source code. I call this the study of software statics, an activity that has improved software quality and development, and one that we should continue to investigate. However, quality software remains difficult to produce because our understanding has an incomplete theoretical foundation. There is little theory that addresses software's dynamic behaviour in the field, in particular, how software performs under load. I use the term operational dynamics to differentiate this activity from software statics and from system dynamics, which involves process simulation     

Software defect prediction using Bayesian networks

There are lots of different software metrics discovered and used for defect prediction in the literature. Instead of dealing with so many metrics, it would be practical and easy if we could determine the set of metrics that are most important and focus on them more to predict defectiveness. We use Bayesian networks to determine the probabilistic influential relationships among software metrics and defect proneness. In addition to the metrics used in Promise data repository, we define two more metrics, i.e. NOD for the number of developers and LOCQ for the source code quality. We extract these metrics by inspecting the source code repositories of the selected Promise data repository data sets. At the end of our modeling, we learn the marginal defect proneness probability of the whole software system, the set of most effective metrics, and the influential relationships among metrics and defectiveness. Our experiments on nine open source Promise data repository data sets show that response for class (RFC), lines of code (LOC), and lack of coding quality (LOCQ) are the most effective metrics whereas coupling between objects (CBO), weighted method per class (WMC), and lack of cohesion of methods (LCOM) are less effective metrics on defect proneness. Furthermore, number of children (NOC) and depth of inheritance tree (DIT) have very limited effect and are untrustworthy. On the other hand, based on the experiments on Poi, Tomcat, and Xalan data sets, we observe that there is a positive correlation between the number of developers (NOD) and the level of defectiveness. However, further investigation involving a greater number of projects is needed to confirm our findings.     

Using structural and textual information to capture feature coupling in object-oriented software

Previous studies have demonstrated the relationship between coupling and external software quality attributes, such as fault-proneness, and the application of coupling to software maintenance tasks, such as impact analysis. These previous studies concentrate on class coupling. However, there is a growing focus on the study of features in software, and features are often implemented across multiple classes, meaning class-level coupling measures are not applicable. We ask the pertinent question, “Is measuring coupling at the feature-level also useful?” We define new feature coupling metrics based on structural and textual source code information and extend the unified framework for coupling measurement to include these new metrics. We also conduct three extensive case studies to evaluate these new metrics and answer this research question. The first study examines the relationship between feature coupling and fault-proneness, the second assesses feature coupling in the context of impact analysis, and the third study surveys developers to determine if the metrics align with what they consider to be coupled features. All three studies provide evidence that feature coupling metrics are indeed useful new measures that capture coupling at a higher level of abstraction than classes and can be useful for finding bugs, guiding testing effort, and assessing change impact.     

Estimating test effectiveness with dynamic complexity measurement

This paper presents an investigation into four distinct aspects of software complexity. An initial partition of the software complexity domain would be the attributes of static software complexity and those of dynamic software comlexity. Static complexity measurement views all program modules monolithically. That is, all of the code for all of the modules is measured as extracted from source code files. When computer software is actually executed, not all modules are executed to the same extent. Some receive a large proportion of execution activity. Further, when these modules execute, not all code in the modules executes. If just the code that is executed is measured for complexity a completely different view of the program module emerges. In this investigation we will examine the static complexity of a program together with the three dynamic measures of functional, fractional, and operational complexity. The eminent value of the dynamic metrics is shown in their role as measures of test outcomes.     

源代码漏洞静态分析技术

漏洞这一名词伴随着计算机软件领域的发展已经走过了数十载。自世界上第一个软件漏洞被公开以来,软件安全研究者和工程师们就一直在探索漏洞的挖掘与分析方法。源代码漏洞静态分析是一种能够贯穿整个软件开发生命周期的、帮助软件开发人员及早发现漏洞的技术,在业界有着广泛的使用。然而,随着软件的体量越来越大,软件的功能越来越复杂,如何表示和建模软件源代码是当前面临的一个难题;此外,近年来的研究倾向于将源代码漏洞静态分析和机器学习相结合,试图通过引入机器学习模型提升漏洞挖掘的精度,但如何选择和构建合适的机器学习模型是该研究方向的一个核心问题。本文将目光聚焦于源代码漏洞静态分析技术(以下简称:静态分析技术),通过对该领域相关工作的回顾,将静态分析技术的研究分为两个方向:传统静态分析和基于学习的静态分析。传统静态分析主要是利用数据流分析、污点分析等一系列软件分析技术对软件的源代码进行建模分析;基于学习的静态分析则是将源代码以数值的形式表示并提交给学习模型,利用学习模型挖掘源代码的深层次表征特征和关联性。本文首先阐述了软件漏洞分析技术的基本概念,对比了静态分析技术和动态分析技术的优劣;然后对源代码的表示方法进行了说明。接着,本文对传统静态分析和基于学习的静态分析的一般步骤进行了总结,同时对这两个研究方向典型的研究成果进行了系统地梳理,归纳了它们的技术特点和工作流程,提出了当前静态分析技术中存在的问题,并对该方向上未来的研究工作进行了展望。     

Object-oriented class maintainability prediction using internal quality attributes

ContextClass maintainability is the likelihood that a class can be easily modified. Before releasing an object-oriented software system, it is impossible to know with certainty when, where, how, and how often a class will be modified. At that stage, this likelihood can be estimated using the internal quality attributes of a class, which include cohesion, coupling, and size. To reduce the future class maintenance efforts and cost, developers are encouraged to carefully test and well document low maintainability classes before releasing the object-oriented system.ObjectiveWe empirically study the relationship between internal class quality attributes (size, cohesion, and coupling) and an external quality attribute (class maintainability). Using statistical techniques, we also construct models based on the selected internal attributes to predict class maintainability.MethodWe consider classes of three open-source systems. For each class, we account for two actual maintainability indicators, the number of revised lines of code and the number of revisions in which the class was involved. Using 19 internal quality measures, we empirically explore the impact of size, cohesion, and coupling on class maintainability. We also empirically investigate the abilities of the measures, considered both individually and combined, to estimate class maintainability. Statistically based prediction models are constructed and validated.ResultsOur results demonstrate that classes with better qualities (i.e., higher cohesion values and lower size and coupling values) have better maintainability (i.e., are more likely to be easily modified) than those of worse qualities. Most of the considered measures are shown to be predictors of the considered maintainability indicators to some degree. The abilities of the considered internal quality measures to predict class maintainability are improved when the measures are combined using optimized multivariate statistical models.ConclusionThe prediction models can help software engineers locate classes with low maintainability. These classes must be carefully tested and well documented.     

Using information retrieval based coupling measures for impact analysis

Coupling is an important property of software systems, which directly impacts program comprehension. In addition, the strength of coupling measured between modules in software is often used as a predictor of external software quality attributes such as changeability, ripple effects of changes and fault-proneness. This paper presents a new set of coupling measures for Object-Oriented (OO) software systems measuring conceptual coupling of classes. Conceptual coupling is based on measuring the degree to which the identifiers and comments from different classes relate to each other. This type of relationship, called conceptual coupling, is measured through the use of Information Retrieval (IR) techniques. The proposed measures are different from existing coupling measures and they capture new dimensions of coupling, which are not captured by the existing coupling measures. The paper investigates the use of the conceptual coupling measures during change impact analysis. The paper reports the findings of a case study in the source code of the Mozilla web browser, where the conceptual coupling metrics were compared to nine existing structural coupling metrics and proved to be better predictors for classes impacted by changes.

Composition inference for UML class diagrams

Knowing which associations are compositions is important in a tool for the reverse engineering of UML class diagrams. Firstly, recovery of composition relationships bridges the gap between design and code. Secondly, since composition relationships explicitly state a requirement that certain representations cannot be exposed, it is important to determine if this requirement is met by component code. Verifying that compositions are implemented properly may prevent serious program flaws due to representation exposure. We propose an implementation-level composition model based on ownership and a novel approach for identifying compositions in Java software. Our approach is based on static ownership inference; it is parameterized by class analysis and is designed to work on incomplete programs. We present empirical results from two instantiation of our approach. For one of these instantiations, on average 40% of the examined fields account for relationships that are identified as compositions. In addition, we present a precision evaluation which shows that the analysis achieves almost perfect precision—that is, it almost never misses composition relationships. The results indicate that precise identification of interclass relationships can be done with a simple and inexpensive analysis, and thus can be easily incorporated in reverse engineering tools that support iterative model-driven development.