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

Evaluation Criteria for Object-oriented Metrics

In this paper an evaluation model for object-oriented (OO) metrics is proposed. We have evaluated the existing evaluation criteria for OO metrics, and based on the observations, a model is proposed which tries to cover most of the features for the evaluation of OO metrics. The model is validated by applying it to existing OO metrics. In contrast to the other existing criteria, the proposed model is simple in implementation and includes the practical and important aspects of evaluation; hence it suitable to evaluate and validate any OO complexity metric

An Approach for the Empirical Validation of Software Complexity Measures

Software metrics are widely accepted tools to control and assure software quality. A large number of software metrics with a variety of content can be found in the literature; however most of them are not adopted in industry as they are seen as irrelevant to needs, as they are unsupported, and the major reason behind this is due to improper empirical validation. This paper tries to identify possible root causes for the improper empirical validation of the software metrics. A practical model for the empirical validation of software metrics is proposed along with root causes. The model is validated by applying it to recently proposed and well known metrics

The Assignment of Scale to Object-Oriented Software Measures

In order to improve productivity (and quality), measurement of specific aspects of software has become imperative. As object oriented programming languages have become more widely used, metrics designed specifically for object-oriented software are required. Recently a large number of new metrics for object- oriented software has appeared in the literature. Unfortunately, many of these proposed metrics have not been validated to measure what they purport to measure. In this paper fifty (50) of these metrics are analyzed

An Empirical investigation into metrics for object-oriented software

Object-Oriented methods have increased in popularity over the last decade, and are now the norm for software development in many application areas. Many claims were made for the superiority of object-oriented methods over more traditional methods, and these claims have largely been accepted, or at least not questioned by the software community. Such was the motivation for this thesis. One way of capturing information about software is the use of software metrics. However, if we are to have faith in the information, we must be satisfied that these metrics do indeed tell us what we need to know. This is not easy when the software characteristics we are interested in are intangible and unable to be precisely defined. This thesis considers the attempts to measure software and to make predictions regarding maintainabilty and effort over the last three decades. It examines traditional software metrics and considers their failings in the light of the calls for better standards of validation in terms of measurement theory and empirical study. From this five lessons were derived. The relatively new area of metrics for object-oriented systems is examined to determine whether suggestions for improvement have been widely heeded. The thesis uses an industrial case study and an experiment to examine one feature of objectorientation, inheritance, and its effect on aspects of maintainability, namely number of defects and time to implement a change. The case study is also used to demonstrate that it is possible to obtain early, simple and useful local prediction systems for important attributes such as system size and defects, using readily available measures rather than attempting predefined and possibly time consuming metrics which may suffer from poor definition, invalidity or inability to predict or capture anything of real use. The thesis concludes that there is empirical evidence to suggest a hypothesis linking inheritance and increased incidence of defects and increased maintenance effort and that more empirical studies are needed in order to test the hypothesis. This suggests that we should treat claims regarding the benefits of object-orientation for maintenance with some caution. This thesis also concludes that with the ability to produce, with little effort, accurate local metrics, we have an acceptable substitute for the large predefined metrics suites with their attendant problems

Relationship between Module Size, Alternative Cost and Bugs

Selle lõputöö eesmärgiks on uurida, kas alternatiivkulu (AC) ja mooduli suurus viivad suurema vigade arvuni tarkvaraprojektis. Kasutades nelja tarkvaraprojekti – JQuery, Font-Awesome, ReactJS ja Atom – versiooniajaloost ja vearaportitest eraldatud andmeid, arvutame me nende alternatiivkulud. Seejärel kasutame me Kendalli korrelatsiooni, et uurida AC ja vigade ning mooduli suuruse (mõõdetuna koodiridades) ja vigade vahelise seose tugevust. Me leidsime, et moodulite suuruse ja vigade vahel on tugev korrelatsioon kõigis neljas tarkvaraprojektis. Samas AC ja vigade vaheline seos jäi tõendamata. Oma uurimusest järeldame, et tarkvaraprojekti kvaliteeditagamise tegevuste käigus tuleks suurtele moodulitele pöörata rohkem tähelepanu. Alternatiivkulu ei ole oluline vigade asukoha tuvastamiseks.The aim of this thesis is to find out if Alternative Cost (AC) and size of modules lead to more bugs in a software project. Using the historical churn extracted from revisions data and bug reports data retrieved from four software projects namely, JQuery, Font-Awesome, ReactJS, and Atom, we calculate their AC. After which we use Kendall correlation to investigate the strength of association between AC and bugs, and module size (measured in Lines of Code) and bugs. We find a strong association between size of modules in all four software projects and bugs existing in them, while that of AC and bugs remain inconclusive. From our investigation, we conclude that when quality assurance activities are performed on a software project, modules with larger size should be given more attention. On the other hand, using our result, Alternative Cost is not relevant for bugs localization

Sustainability evaluation of software architectures

Long-living software systems are sustainable if they can be cost-efficiently maintained and evolved over their entire life-cycle. The quality of software architectures determines sus-tainability to a large extent. Scenario-based software archi-tecture evaluation methods can support sustainability anal-ysis, but they are still reluctantly used in practice. They are also not integrated with architecture-level metrics when evaluating implemented systems, which limits their capabil-ities. Existing literature reviews for architecture evaluation focus on scenario-based methods, but do not provide a criti-cal reflection of the applicability of such methods for sustain-ability evaluation. Our goal is to measure the sustainabil-ity of a software architecture both during early design us-ing scenarios and during evolution using scenarios and met-rics, which is highly relevant in practice. We thus provide a systematic literature review assessing scenario-based meth-ods for sustainability support and categorize more than 40 architecture-level metrics according to several design prin-ciples. Our review identifies a need for further empirical research, for the integration of existing methods, and for the more efficient use of formal architectural models. 1

Software Engineering Laboratory Series: Collected Software Engineering Papers

The Software Engineering Laboratory (SEL) is an organization sponsored by NASA/GSFC and created to investigate the effectiveness of software engineering technologies when applied to the development of application software. The activities, findings, and recommendations of the SEL are recorded in the Software Engineering Laboratory Series, a continuing series of reports that includes this document

Object-oriented complexity metrics for the Java programming language

Since its introduction in 1995 by Sun Microsystems, the Java programming language has been widely accepted by the software development community. Besides being a natural fit for Internet and World Wide Web (WWW) based applications, Java is also being used in other diverse application areas due to its simplicity, reduced learning-curve, portability, and Object-Oriented features. Given this tremendous potential for Java as a development language, there is a pressing need for software measures or metrics with which to manage the process of software development in Java. A good set of metrics can be very useful especially in the post-coding phases of the software life-cycle, such as testing and maintenance, in identifying those classes which are likely to be hard to test or modify. This research addresses these needs through an investigation into an Object-­Oriented metrics suite for Java. A set of metrics at the class-level is proposed, and a tool was developed to automate the collection of the metrics. Two experiments were conducted to determine which of the metrics were effective and useful measures of complexity. The experiments indicate that the number of non-static external references is a good complexity metric for Java.1997 best estimate for issue date and commencement year based on available information