物件導向軟體之架構(Object-Oriented Software Construction)探討

Object-Oriented Software Metrics.

The metaphor of technical debt was introduced to express the trade off between productivity and quality, i.e., when developers take shortcuts or perform quick hacks. More recently, our work has shown that it is possible to detect technical debt using source code comments (i.e., self-admitted technical debt), and that the most common types of self-admitted technical debt are design and requirement debt. However, all approaches thus far heavily depend on the manual classification of source code comments. In this paper, we present an approach to automatically identify design and requirement self-admitted technical debt using Natural Language Processing (NLP). We study 10 open source projects: Ant, ArgoUML, Columba, EMF, Hibernate, JEdit, JFreeChart, JMeter, JRuby and SQuirrel SQL and find that 1) we are able to accurately identify self-admitted technical debt, significantly outperforming the current state-of-the-art based on fixed keywords and phrases; 2) words related to sloppy code or mediocre source code quality are the best indicators of design debt, whereas words related to the need to complete a partially implemented requirement in the future are the best indicators of requirement debt; and 3) we can achieve 90 percent of the best classification performance, using as little as 23 percent of the comments for both design and requirement self-admitted technical debt, and 80 percent of the best performance, using as little as 9 and 5 percent of the comments for design and requirement self-admitted technical debt, respectively. The last finding shows that the proposed approach can achieve a good accuracy even with a relatively small training dataset.

Using Natural Language Processing to Automatically Detect Self-Admitted Technical Debt

書評 カーリス Y. ボールドウィン/キム B. クラーク著 安藤晴彦訳『デザイン・ルール:モジュール化パワー』 Carliss Y. Baldwin & Kim B. Clark/Design Rules, Vol. 1: The Power of Modularity

In this paper, we propose and empirically validate a suite of hotspot patterns: recurring architecture problems that occur in most complex systems and incur high maintenance costs. In particular, we introduce two novel hotspot patterns, Unstable Interface and Implicit Cross-module Dependency. These patterns are defined based on Baldwin and Clark's design rule theory, and detected by the combination of history and architecture information. Through our tool-supported evaluations, we show that these patterns not only identify the most error-prone and change-prone files, they also pinpoint specific architecture problems that may be the root causes of bug-proneness and change-proneness. Significantly, we show that 1) these structure-history integrated patterns contribute more to error- and change-proneness than other hotspot patterns, and 2) the more hotspot patterns a file is involved in, the more error- and change-prone it is. Finally, we report on an industrial case study to demonstrate the practicality of these hotspot patterns. The architect and developers confirmed that our hotspot detector discovered the majority of the architecture problems causing maintenance pain, and they have started to improve the system's maintainability by refactoring and fixing the identified architecture issues.

Hotspot Patterns: The Formal Definition and Automatic Detection of Architecture Smells

Our recent research has shown that, in large-scale software systems, defective files seldom exist alone. They are usually architecturally connected, and their architectural structures exhibit significant design flaws which propagate bugginess among files. We call these flawed structures the architecture roots, a type of technical debt that incurs high maintenance penalties. Removing the architecture roots of bugginess requires refactoring, but the benefits of refactoring have historically been difficult for architects to quantify or justify. In this paper, we present a case study of identifying and quantifying such architecture debts in a large-scale industrial software project. Our approach is to model and analyze software architecture as a set of design rule spaces (DRSpaces). Using data extracted from the project's development artifacts, we were able to identify the files implicated in architecture flaws and suggest refactorings based on removing these flaws. Then we built economic models of the before and (predicted) after states, which gave the organization confidence that doing the refactorings made business sense, in terms of a handsome return on investment.

A case study in locating the architectural roots of technical debt

Our prior work showed that the majority of error-prone source files in a software system are architecturally connected Flawed architectural relations propagate defects among these files and accumulate high maintenance costs over time, just like debts accumulate interest We model groups of architecturally connected files that accumulate high maintenance costs as architectural debts To quantify such debts, we formally define architectural debt, and show how to automatically identify debts, quantify their maintenance costs, and model these costs over time We describe a novel history coupling probability matrix for this purpose, and identify architecture debts using 4 patterns of architectural flaws shown to correlate with reduced software quality We evaluate our approach on 7 large-scale open source projects, and show that a significant portion of total project maintenance effort is consumed by paying interest on architectural debts The top 5 architectural debts, covering a small portion (8% to 25%) of each project's error-prone files, capture a significant portion (20% to 61%) of each project's maintenance effort Finally, we show that our approach reveals how architectural issues evolve into debts over time

https://dl.acm.org/doi/pdf/10.1145/2884781.2884822

Identifying and quantifying architectural debt

Despite decades of research on software metrics, we still cannot reliably measure if one design is more maintainable than another. Software managers and architects need to understand whether their software architecture is "good enough", whether it is decaying over time and, if so, by how much. In this paper, we contribute a new architecture maintainability metric---Decoupling Level (DL)---derived from Baldwin and Clark's option theory. Instead of measuring how coupled an architecture is, we measure how well the software can be decoupled into small and independently replaceable modules. We measured the DL for 108 open source projects and 21 industrial projects, each of which has multiple releases. Our main result shows that the larger the DL, the better the architecture. By "better" we mean: the more likely bugs and changes can be localized and separated, and the more likely that developers can make changes independently. The DL metric also opens the possibility of quantifying canonical principles of single responsibility and separation of concerns, aiding cross-project comparison and architecture decay monitoring.

/pdf/decoupling-level-a-new-metric-for-architectural-maintenance-3mwjslokgw.pdf

Decoupling level: a new metric for architectural maintenance complexity

In large-scale software systems, error-prone or change-prone files rarely stand alone. They are typically architecturally connected and their connections usually exhibit architecture problems causing the propagation of error-proneness or change-proneness. In this paper, we propose and empirically validate a suite of architecture anti-patterns that occur in all large-scale software systems and are involved in high maintenance costs. We define these architecture anti-patterns based on fundamental design principles and Baldwin and Clark’s design rule theory. We can automatically detect these anti-patterns by analyzing a project’s structural relationships and revision history. Through our analyses of 19 large-scale software projects, we demonstrate that these architecture anti-patterns have significant impact on files’ bug-proneness and change-proneness. In particular, we show that 1) files involved in these architecture anti-patterns are more error-prone and change-prone; 2) the more anti-patterns a file is involved in, the more error-prone and change-prone it is; and 3) while all of our defined architecture anti-patterns contribute to file’s error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.

Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles

Recently there has been increased attention to the consequences of architecture design decisions and their impact on security. Architectural design decisions have been identified as being critical for achieving high levels of software system security. However the majority of this research has been anecdotal and there are few tools or methods for understanding the architectural relations among files, and their impact on security. In this paper we employ a DRSpace-based analysis approach to identify architectural design flaws and we show, via an empirical study of 10 open source projects, that areas of a software architecture that suffer from greater numbers of design flaws are highly correlated with security bugs, and high levels of churn associated with those security bugs. Finally, we show that a specific type of design flaw -- unstable interface -- is correlated with the greatest increase in software security bugs.

Qiong Feng

Papers

A case study in locating the architectural roots of technical debt

Identifying and quantifying architectural debt

Decoupling level: a new metric for architectural maintenance complexity

Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles

Towards an Architecture-Centric Approach to Security Analysis