Applicability of Weyuker’s Properties on OO Metrics: Some Misunderstandings

Weyuker’s properties have been suggested as a guiding tool in identification of a good and comprehensive complexity measure by several researchers. Weyuker proposed nine properties to evaluate complexity measure for traditional programming. However, they are extensively used for evaluating object-oriented (OO) metrics, although the object-oriented features are entirely different in nature. In this paper, two recently reported OO metrics were evaluated and, based on it; the usefulness and relevance of these properties for evaluation purpose for object-oriented systems is discussed

Practices in the Squale Quality Model (Squale Deliverable 1.3)

This document presents the Squale Software Quality Model as defined by Qualixo. It first reviews existing quality models and presents the Squale model with its particular- ity, namely a practice layer. Then it reviews in details an instance of this Squale Model with its Factors, Criteria and Practices, giving precise definitions and description1. Fi- nally, it discusses possible future enhancements of this model like new practices or its agreement with the program life-cycle and the change of needs during this life cycle

Software Metrics for Package Remodularisation

There is a plethora of software metrics \cite{Lore94a, Fent96a, Hend96a, Han00a, Lanz06a} and a large amount of research articles. Still there is a lack for a serious and practically-oriented evaluation of metrics. Often metrics lack the property that the software reengineer or quality expert can easily understand the situation summarized by the metrics. In particular, since the exact notion of coupling and cohesion is complex, a particular focus on such point is important. In the first chapter of the present document, we present a list of software metrics, that are commonly used to measure object-oriented programs. In the second chapter we present our proposition for package metrics that capture package aspects such as information hiding and change impact limits

Cohesion Metrics for Improving Software Quality

Abstract Software product metrics aim at measuring the quality of software. Modu- larity is an essential factor in software quality. In this work, metrics related to modularity and especially cohesion of the modules, are considered. The existing metrics are evaluated, and several new alternatives are proposed. The idea of cohesion of modules is that a module or a class should consist of related parts. The closely related principle of coupling says that the relationships between modules should be minimized. First, internal cohesion metrics are considered. The relations that are internal to classes are shown to be useless for quality measurement. Second, we consider external relationships for cohesion. A detailed analysis using design patterns and refactorings confirms that external cohesion is a better quality indicator than internal. Third, motivated by the successes (and problems) of external cohesion metrics, another kind of metric is proposed that represents the quality of modularity of software. This metric can be applied to refactorings related to classes, resulting in a refactoring suggestion system. To describe the metrics formally, a notation for programs is developed. Because of the recursive nature of programming languages, the properties of programs are most compactly represented using grammars and formal lan- guages. Also the tools that were used for metrics calculation are described.Siirretty Doriast

Visualizing Software Structure Understandability

Software architecture design is known to be driven by the quality attributes we may want to satisfy. Among them, modifiability plays an important role since software maintenance takes the lion's share in the software development costs. However, to successfully maintain a legacy system, the latter must be sufficiently understood so that the maintenance team will not introduce new bugs when correcting others. Then we present a software metric that we called the Autonomy Ratio (AR). We show this dynamic metric to be a good indicator of the system's structure understandability. Since we end up with hundreds of values for a single system, we represent these values as a hierarchical map: the "Autonomy Ratio Map". The contribution of the paper is to link the AR metric with theories of software comprehension, to show how the AR Map helps in assessing software structure understand-debility, and to present an empirical validation of it

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Exploring the eradication of code smells: An empirical and theoretical perspective

This article has been made available through the Brunel Open Access Publishing Fund - Copyright @ 2010 Hindawi Publishing CorporationCode smells reflect code decay, and, as such, developers should seek to eradicate such smells through application of “deodorant” in the form of one or more refactorings. However, a relative lack of studies exploring code smells either theoretically or empirically when compared with literature on refactoring suggests that there are reasons why smell eradication is neither being applied in anger, nor the subject of significant research. In this paper, we present three studies as supporting evidence for this stance. The first is an analysis of a set of five, open-source Java systems in which we show very little tendency for smells to be eradicated by developers; the second is an empirical study of a subsystem of a proprietary, C# web-based application where practical problems arise in smell identification and the third, a theoretical enumeration of smell-related refactorings to suggest why smells may be left alone from an effort perspective. Key findings of the study were that first, smells requiring application of simple refactorings were eradicated in favour of smells requiring more complex refactorings; second, a wide range of conflicts and anomalies soon emerged when trying to identify smelly code; an interesting result with respect to comment lines was also observed. Finally, perceived (estimated) effort to eradicate a smell may be a key factor in explaining why smell eradication is avoided by developers. The study thus highlights the need for a clearer research strategy on the issue of code smells and all aspects of their identification and measurement.The research in this paper was supported by a grant from the UK Engineering and Physical Sciences Research Council (EPSRC) (Grant no: EP/G031126/1

Software Metrics Evaluation Based on Entropy

Software engineering activities in the Industry has come a long way with various improve- ments brought in various stages of the software development life cycle. The complexity of modern software, the commercial constraints and the expectation for high quality products demand the accurate fault prediction based on OO design metrics in the class level in the early stages of software development. The object oriented class metrics are used as quality predictors in the entire OO software development life cycle even when a highly iterative, incremental model or agile software process is employed. Recent research has shown some of the OO design metrics are useful for predicting fault-proneness of classes. In this paper the empirical validation of a set of metrics proposed by Chidamber and Kemerer is performed to assess their ability in predicting the software quality in terms of fault proneness and degradation. We have also proposed the design complexity of object-oriented software with Weighted Methods per Class metric (WMC-CK metric) expressed in terms of Shannon entropy, and error proneness