An empirical study of object-oriented system evolution
Introduction
Object-oriented (OO) software development is an iterative process. An OO system evolves from the abstraction of an application domain to the complete implementation of classes in an inheritance hierarchy [1]. When an OO system is designed, the designers start by analyzing the application domain to extract abstractions. The identified concepts in the application domain are mapped to classes in the OO system. The relations among the identified classes indicate relations in the application domain. The process of identifying classes from application-domain abstractions, assigning data and operations attributes to the classes, and establishing relations among the classes continues in an iterative fashion until the set of classes, their attributes, and the class relations are mature. OO design, unlike Structured Design, does not have clear starting and ending points in the software development process. OO design begins as soon as the analysis of the application domain starts, and it does not end until the system is complete.1
OO software metrics have focused on the static measuring of software artifacts such as the implementation or design of a system [2], [3]. We believe that it is important to also quantitatively study time-related changes of software artifacts during development. Therefore, we propose three metrics, System Design Instability (SDI), Class Implementation Instability (CII), and System Implementation Instability (SII) to measure changes during OO design and implementation. These can be used in conjunction with the static metrics to provide useful information for project management, since they can be used to verify the project plan and assess project progress. This paper describes the use of the SDI and CII metrics in an empirical study, which allows us to make observations about OO software evolution.
Section snippets
Object-oriented system design
OO system design involves decisions about the number of classes, what names they take, and how to organize the classes into an inheritance hierarchy. These decisions are a part of the design process as the designer reflects the abstraction of the application domain in this structure. The changes of the number of classes and their names in an OO system reflect the changes in a designer's view of the application domain. The name of a class reflects an abstraction of an application domain concept.
Object-oriented class design
The structural design of a class involves defining the following items: the data and operation attributes, local interface,2 encapsulation,3 and the way that
Object-oriented metrics
The objective of this study is to measure the evolution of an object-oriented system. In this empirical study, we use the OO metrics suggested by Chidamber and Kemerer (C&K) [2] and Li and Henry [4] to measure the class-level design. The system-level design is measured by the SDI metric that we will discuss later in the paper. We use the CII and SII metrics, which are also discussed later in the paper, to measure the class and system-level implementation changes.
Chidamber and Kemerer introduced
Object-oriented metrics
The C&K metrics can measure certain aspects of an OO system, but not all. For example, the C&K metrics cannot measure the class name changes, the creation of new classes and the deletion of obsolete classes, all of which are related to the OO abstraction process. In order to measure these quantities, we introduce three new metrics, SDI, CII and SII to supplement the C&K metrics. The SDI metric measures the system-level design change. The CII and SII metrics measure the class-level and
Empirical study of OO software evolution
The project that was studied is a metadata subsystem that parses input data definitions to prepare final SQL statements for data retrieval from multiple sources. This project was developed in an industrial setting in which all factors of software development were carefully monitored. The factors that were tracked during development are software requirements, requirement changes, the understanding of requirements, software design (represented in the header files in C++), and the implementation
Class growth
Fig. 3 shows the number of classes at each data point of the development. There was a bit of uncertainty regarding the structuring of the classes at the beginning of the project. The number of classes showed a steady growth after the initial uncertainty was overcome. The growth of the classes started to level off towards the end of the project.
System design instability
Fig. 4 shows the SDI metric at each data point. It is clear that the system-level design was very unstable at the beginning of the project. This instability may be associated with the process of adjusting the application-domain abstractions and mapping them to classes in the system.
Class implementation instability
We believe that the SDI metric measures a different aspect of OO design than the C&K metrics [2]. In order to test this, we define the null and alternate hypotheses as follows.
Null hypothesis: the SDI metric measures the same aspect of OO design as the C&K design metrics.
Alternate hypothesis: the SDI metric does not measure the same aspect of OO design as the C&K metrics.
Table 1 shows the result of a Mann–Whitney non-parametric test comparing the SDI metric and the C&K metrics with a sample
Impact of OO implementation on OO design
So far we have defined and validated new instability measures for system design instability (SDI), class implementation instability (CII), and system implementation instability (SII). Using statistical techniques, we have demonstrated that the new SDI and SII metrics measure different aspects of OO design than are measured by the C&K metrics (the CII metric is an implementation metric rather than a design metric). However, when considering design instability, one also has to question whether,
Observation 1
The accumulative CC of a class (measured as the WMC metric in this study) seems to grow together with the implementation model. This observation agrees with a similar observation made by Li in the procedural paradigm [6]; however, this verifies that the relationship between cyclomatic complexity and LOC also holds for the OO paradigm. This observation indicates that, although the LOC and CC metrics measure different features in a module (a function or a class), they may be statistically
Observation 2
The poor correlation of the LOC and CTM metrics indicates that the message-passing aspect of a class design is likely to be determined by the designer's view earlier in the development cycle, rather than during the implementation of the class. This observation may also help project managers and engineers in planning the project. For example, once the message-trace diagrams or the interaction diagrams are created and stabilized, there is reasonable confidence that they may remain relatively
Observation 3
The poor correlation between the LOC and the CTA metrics indicates that the use of abstract data types in OO design is relatively independent of the implementation of a class. This observation may help a software team in the same way as Observation 2.
Observation 4
The poor correlation between the LOC and the LCOM metric indicates that the cohesiveness of a class is independent of the implementation of the class. This observation makes sense because the quality of an application-domain abstraction, rather than the amount of code needed to implement the abstraction, likely determines the cohesion of a class.
Observation 5
The correlation between the LOC and the NLM metric is inconclusive. We want to believe that the local interface of a class, which is measured by the NLM metric, should be determined by the abstraction of the class. But the inconclusiveness of this observation indicates that the local interface of a class may change because services are added to the original design of the class as more implementation is added to this and other classes.
Conclusions
We presented an empirical study of OO software evolution. Specifically, we proposed three evolutionary metrics—SDI, CII and SII—to study OO system evolution. The SDI and SII metrics can give indications of project progress, e.g. how complete the design and implementation is. This information can in turn be used to adjust a project plan in real time. For example, if the absolute value of the SDI metric stays relatively high and has not shown a downward trend, all the activities that depend on a
References (7)
- et al.
Object-oriented metrics that predict maintainability
Journal of Systems and Software
(1993) Another metrics suite for object-oriented programming
Journal of Systems and Software
(1998)Object-Oriented Analysis and Design with Applications
(1994)
Cited by (35)
Package-Level stability evaluation of object-oriented systems
2019, Information and Software TechnologyCitation Excerpt :System and architecture view-based metrics measure the stability of an application as one unit. System-level stability metrics take into account changes in the number of classes and lines of code, without paying attention to internal relationships and external connections ([16–18]). On the other hand, architecture-level stability metrics take into account the change in calls between classes [19–21]; however, they measure stability as a number for a whole system.
The transformation of requirements into software primitives: Studying evolvability based on systems theoretic stability
2011, Science of Computer ProgrammingBug localization using latent Dirichlet allocation
2010, Information and Software TechnologyCitation Excerpt :For this reason we examine the relationship between our approach and code instability. In the past, various stability metrics have been shown to accurately reflect the stability of software across multiple development iterations [1,16]. In this paper, we compare these metrics to the results of our approach to determine whether or not the instability of the software results in poorer operation of our LDA-based technique.
The effectiveness of software metrics in identifying error-prone classes in post-release software evolution process
2008, Journal of Systems and SoftwareAnalysis of Privacy Patterns from An Architectural Perspective
2022, 2022 IEEE 19th International Conference on Software Architecture Companion, ICSA-C 2022Assessing Growth and Instability of Open Source Software Systems
2021, 2021 IEEE 1st International Maghreb Meeting of the Conference on Sciences and Techniques of Automatic Control and Computer Engineering, MI-STA 2021 - Proceedings