Object-Oriented Design Metrics and Code Quality Assessment

Overview of Object-Oriented Programming

This report evaluates whether software metrics can be used in determining the quality of design of object-oriented software. Various metrics and metrics tools are applied in this evaluation, alongside analysis of how source code implementations integrate with existing systems.

Oracle (2010) defines object-oriented programming as "a method of programming based on a hierarchy of classes, and well-defined and cooperating objects." The concept of OOP is rapidly becoming significant and practical in application development. This importance stems from its ability to adequately represent the various complex relationships required for applications to be designed. Additionally, OOP represents otherwise complex relationships while maintaining data consistency.

OOP has been effectively implemented across diverse fields of software and computer engineering, including system analysis, system design, operating systems, computer programming, and database management systems. Understanding the core characteristics of OOP is essential for evaluating design quality through metrics.

Encapsulation and Access Control

Encapsulation is a fundamental attribute of OOP meaning that all data in objects are contained and hidden inside the object, with access restricted only to members of the given class. Different programming languages enforce encapsulation at varying strictness levels. C++, for example, implements multiple access levels:

Public: Can be accessed by all objects. Protected: Access is limited to members of the same class or their descendants. Private: Access is limited to members of the same class. Internal: Access is limited to the current assembly. Protected Internal: Access is limited to the current assembly or types derived from the containing class.

These access modifiers allow developers to control information visibility, reducing unintended dependencies and improving code maintainability. By hiding implementation details, encapsulation supports the measurement of design complexity through metrics that assess coupling and cohesion.

Inheritance, Composition, and Association

Inheritance helps objects work together by defining relationships among classes in the object-oriented language realm. It enables objects to inherit data values and methods from other classes, promoting reusability and systematic organization of objects with similar attributes. When class A inherits from class B, class A is considered a subclass while class B is a superclass. This type of inheritance can proceed through multiple levels to form a class hierarchy.

Composition and aggregation represent techniques for building new objects from one or more existing objects that support some or all of the new object's required interfaces. Certain objects may contain only data, while others contain both objects and data. For example, a person class may contain name and gender attributes along with an address class.

Association is a form of relationship that exists among classes with multiple instances. These three mechanisms—inheritance, composition, and association—form the structural foundation upon which design metrics operate to evaluate code quality.

Object-Oriented Metrics in Java

The empirical validation of OOP design metrics is critical for establishing their reliability. El Grasberg et al. (2000) performed this validation for commercial Java applications in their article "Validating Object-oriented Design Metrics on a Commercial Java Application." Their work focused on empirical validation of metrics developed by Briand et al. (1997) and Chidamber and Kemerer (1994).

The study utilized data sourced from Java applications implemented in an XML editor. The measured external attribute for the study was reliability, assessed through the incidence of prerelease faults in certain classes—referred to as fault-proneness. Extensive literature has documented empirical validation of these metrics (Briand et al., 1997; Briand et al., 2000; El-Emam et al., 2001). The El Grasberg article replicated these studies to accumulate evidence regarding metric validity.

The authors presented a detailed cognitive theory to justify the chosen metrics and stated hypotheses relating design metrics to application fault-proneness. Existing evidence supporting these hypotheses suggests possible reasons why certain metrics are regarded as leading indicators of fault-proneness. The authors noted that, to their knowledge, this work marked the initial attempt in postulating a cognitive-principles-based theory for object-oriented metrics. The article revealed that many object-oriented metrics do have a significant association with an application's fault-proneness.

Object-Oriented Metrics in C++

Basili et al. (1996) presented an empirical study investigating OOP design metrics in their article "A Validation of Object-Oriented Design Metrics as Quality Indicators." Their goal was to assess metrics as chief predictors of fault-prone classes and determine whether they can serve as indicators of code quality. The same groups of metrics were utilized throughout to assess the frequencies of maintenance for various classes.

To accurately perform validation, data were collected from a spectrum of eight medium-sized data management systems with the same requirements. All eight systems were developed using a sequential life cycle model and the C++ programming language. This consistent environment allowed for controlled assessment of how metrics perform across different systems with shared requirements and language constraints.

Feature-Oriented Programming with Ruby

Ruby demonstrates how object-oriented principles extend to feature-oriented programming. Günther and Sunkle (2009) explored this in "Feature-Oriented Programming with Ruby," examining how features—characteristics of software used to distinguish members of a program family—can be effectively implemented in OOP contexts.

Program families are comparable to Software Product Lines (SPLs), which are sets of related programs with different characteristics. Features reflect stakeholder requirements and address the challenge of structuring assets to improve productivity and reusability. Ruby's rbFeatures extension demonstrates that features should be enabled in object-oriented programming to improve productivity and achieve abstract modeling with concrete implementation at the same abstraction level.

Ruby's approach to feature-oriented design shows how modern languages integrate metrics-friendly design patterns that support both quality measurement and code flexibility.

Conclusion

The conclusion derived from the articles examined is that metrics have practical use in object-oriented programming and are, to a large extent, a reflection of the quality of software design. The quality factors most affected by design include complexity of classes and methods, design of package structure, and the level of abstraction of the system. These measurable attributes provide developers and managers with concrete tools for assessing and improving software quality across diverse programming languages and development contexts.