Characterizing and Diagnosing Architectural Degeneration of Software Systems from Defect Perspective

The architecture of a software system is known to degrade as the system evolves over time due to change upon change, a phenomenon that is termed architectural degeneration. Previous research has focused largely on structural deviations of an architecture from its baseline. However, another angle to observe architectural degeneration is software defects, especially those that are architecturally related. Such an angle has not been scientifically explored until now. Here, we ask two relevant questions: (1) What do defects indicate about architectural degeneration? and (2) How can architectural degeneration be diagnosed from the defect perspective? To answer question (1), we conducted an exploratory case study analyzing defect data over six releases of a large legacy system (of size approximately 20 million source lines of code and age over 20 years). The relevant defects here are those that span multiple components in the system (called multiple-component defects - MCDs). This case study found that MCDs require more changes to fix and are more persistent across development phases and releases than other types of defects. To answer question (2), we developed an approach (called Diagnosing Architectural Degeneration - DAD) from the defect perspective, and validated it in another, confirmatory, case study involving three releases of a commercial system (of size over 1.5 million source lines of code and age over 13 years). This case study found that components of the system tend to persistently have an impact on architectural degeneration over releases. Especially, such impact of a few components is substantially greater than that of other components. These results are new and they add to the current knowledge on architectural degeneration. The key conclusions from these results are: (i) analysis of MCDs is a viable approach to characterizing architectural degeneration; and (ii) a method such as DAD can be developed for diagnosing architectural degeneration

Change decision support:extraction and analysis of late architecture changes using change characterization and software metrics

Software maintenance is one of the most crucial aspects of software development. Software engineering researchers must develop practical solutions to handle the challenges presented in maintaining mature software systems. Research that addresses practical means of mitigating the risks involved when changing software, reducing the complexity of mature software systems, and eliminating the introduction of preventable bugs is paramount to today’s software engineering discipline. Giving software developers the information that they need to make quality decisions about changes that will negatively affect their software systems is a key aspect to mitigating those risks. This dissertation presents work performed to assist developers to collect and process data that plays a role in change decision-making during the maintenance phase. To address these problems, developers need a way to better understand the effects of a change prior to making the change. This research addresses the problems associated with increasing architectural complexity caused by software change using a twoold approach. The first approach is to characterize software changes to assess their architectural impact prior to their implementation. The second approach is to identify a set of architecture metrics that correlate to system quality and maintainability and to use these metrics to determine the level of difficulty involved in making a change. The two approaches have been combined and the results presented provide developers with a beneficial analysis framework that offers insight into the change process

Understanding Architecture Erosion: The Practitioners' Perceptive

As software systems evolve, their architecture is meant to adapt accordingly by following the changes in requirements, the environment, and the implementation. However, in practice, the evolving system often deviates from the architecture, causing severe consequences to system maintenance and evolution. This phenomenon of architecture erosion has been studied extensively in research, but not yet been examined from the point of view of developers. In this exploratory study, we look into how developers perceive the notion of architecture erosion, its causes and consequences, as well as tools and practices to identify and control architecture erosion. To this end, we searched through several popular online developer communities for collecting data of discussions related to architecture erosion. Besides, we identified developers involved in these discussions and conducted a survey with 10 participants and held interviews with 4 participants. Our findings show that: (1) developers either focus on the structural manifestation of architecture erosion or on its effect on run-time qualities, maintenance and evolution; (2) alongside technical factors, architecture erosion is caused to a large extent by non-technical factors; (3) despite the lack of dedicated tools for detecting architecture erosion, developers usually identify erosion through a number of symptoms; and (4) there are effective measures that can help to alleviate the impact of architecture erosion.Comment: The 29th IEEE/ACM International Conference on Program Comprehension (ICPC

Understanding, Analysis, and Handling of Software Architecture Erosion

Architecture erosion occurs when a software system's implemented architecture diverges from the intended architecture over time. Studies show erosion impacts development, maintenance, and evolution since it accumulates imperceptibly. Identifying early symptoms like architectural smells enables managing erosion through refactoring. However, research lacks comprehensive understanding of erosion, unclear which symptoms are most common, and lacks detection methods. This thesis establishes an erosion landscape, investigates symptoms, and proposes identification approaches. A mapping study covers erosion definitions, symptoms, causes, and consequences. Key findings: 1) "Architecture erosion" is the most used term, with four perspectives on definitions and respective symptom types. 2) Technical and non-technical reasons contribute to erosion, negatively impacting quality attributes. Practitioners can advocate addressing erosion to prevent failures. 3) Detection and correction approaches are categorized, with consistency and evolution-based approaches commonly mentioned.An empirical study explores practitioner perspectives through communities, surveys, and interviews. Findings reveal associated practices like code review and tools identify symptoms, while collected measures address erosion during implementation. Studying code review comments analyzes erosion in practice. One study reveals architectural violations, duplicate functionality, and cyclic dependencies are most frequent. Symptoms decreased over time, indicating increased stability. Most were addressed after review. A second study explores violation symptoms in four projects, identifying 10 categories. Refactoring and removing code address most violations, while some are disregarded.Machine learning classifiers using pre-trained word embeddings identify violation symptoms from code reviews. Key findings: 1) SVM with word2vec achieved highest performance. 2) fastText embeddings worked well. 3) 200-dimensional embeddings outperformed 100/300-dimensional. 4) Ensemble classifier improved performance. 5) Practitioners found results valuable, confirming potential.An automated recommendation system identifies qualified reviewers for violations using similarity detection on file paths and comments. Experiments show common methods perform well, outperforming a baseline approach. Sampling techniques impact recommendation performance

Software Architecture in Practice: Challenges and Opportunities

Software architecture has been an active research field for nearly four decades, in which previous studies make significant progress such as creating methods and techniques and building tools to support software architecture practice. Despite past efforts, we have little understanding of how practitioners perform software architecture related activities, and what challenges they face. Through interviews with 32 practitioners from 21 organizations across three continents, we identified challenges that practitioners face in software architecture practice during software development and maintenance. We reported on common software architecture activities at software requirements, design, construction and testing, and maintenance stages, as well as corresponding challenges. Our study uncovers that most of these challenges center around management, documentation, tooling and process, and collects recommendations to address these challenges.Comment: Preprint of Full Research Paper, the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '23

Mechanically Stable Solid Freeform Fabricated Scaffolds with Permeability Optimized for Cartilage Tissue Engineering.

Clinical treatment options for articular cartilage repair are progressing with the incorporation of synthetic matrices alongside current autologous chondrocyte implantation techniques. This work explores mechanical and mass transport design of potential matrices. Solid freeform fabrication (SFF) is used to create highly reproducible scaffolds with precise structural features in order to explore the mechanical potential of 3D designed poly(ε-caprolactone) (PCL) and poly(glycerol sebacate) (PGS) scaffolds, and to examine the effects of a designed physical property, permeability, for cartilage regeneration. Our first aim explores the potential of PCL and PGS scaffolds to provide temporary mechanical function within a tissue defect. We find that PCL mimics the viscoelastic nature of cartilage; however its stiffness properties cannot be changed through alterations in molecular weight or melting temperature. Fabricated into the architectures explored, it has aggregate modulus (HA) values within the correct magnitude, but higher than native cartilage. Furthermore, we demonstrate the importance of mechanically testing PCL scaffolds at physiological temperatures and we quantify their contraction in polar environments. Poly(glycerol sebacate) has never been used for cartilage tissue engineering. We characterize how variations in the molar ratios of glycerol to sebacic acid (during pre-polymer synthesis) or variations in curing time can be used to change the stiffness of PGS, enabling fabrication of scaffolds with a wide range of architectures (designed for optimal tissue regeneration) that all support in vivo loads. Chondrocytes seeded onto PGS produce cartilaginous matrix and express cartilage specific genes similar to or better than cells cultured on PCL, showing the biocompatibility of PGS for cartilage applications for the first time. Our second aim looks at enhancing cartilage regeneration by optimizing scaffold permeability. We show that chondrocytes prefer a lower permeable scaffold that mimics the natural environment of native tissue, producing significantly more matrix and increased expression of cartilage specific markers. Bone marrow stromal cells (BMSCs) display the opposite trend, favoring a higher permeable environment for chondrogenic differentiation, as displayed through collagen 2 to collagen 1 expression, suggesting that increased access to chondrogenic induction factors in media is more important to these cells than mimicking the low permeable environment of native tissue.Ph.D.Biomedical EngineeringUniversity of Michigan, Horace H. Rackham School of Graduate Studieshttp://deepblue.lib.umich.edu/bitstream/2027.42/61582/1/jessmw_1.pd

Technical Debt Decision-Making Framework

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

Technical Debt Decision-Making Framework

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

Chondro progenitor cell response to specifically modified substrate interfaces

Current visions in cartilage repair aim at moving from fibrocartilaginous to a more hyaline like repair tissue by combining autologous cells of different origins (in situ recruited or in vitro precultivated) with repair supporting biomaterials. The role of a chondro-supportive biomaterial within a cartilage defect is seen to support infiltration/recruitment of chnodroprogenitor cells (CPC), accelerate their chondrogenic differentiation and to protect/modulate the newly formed tissue. Overall, this thesis aimed at studying whether modification of selected substrate interface properties allows for modulating chondroprogenitor cell phenotype & function under expansion or differentiation conditions in vitro. The goal was to contribute to the definition of material characteristics which could be implemented in the design of biomaterials in order to improve current matrix assisted cartilage repair strategies and outcomes. Substrate composition & architecture (Chapter I) were found to modulate the chondrogenic differentiation of mesenchymal stem cells (MSC). Using a di block copolymer model substrate (Polyactive®) with a more hydrophobic composition better supported MSC chondrogenesis, than a more hydrophilic composition. Moreover, a highly interconnected 3D fibre deposited scaffold architecture allowed for the formation of larger MSC aggregates and was found to considerably better support MSC chondrogenesis than compression molded scaffolds. Restricting cell/substrate interaction specifically to an RGD-containing peptide ligand (Chapter II) modulated the de-differentiation of proliferating HAC and their subsequent capacity to form cartilaginous matrix. This demonstrated the advantage of small ECM fragments in combination with protein resistant materials to control cell/surface interaction. An important finding was the better maintenance of the HAC chondrocytic phenotype during expansion. It suggests, that an RGD-restricted substrate has the potential to improve the outcome of matrix assisted in situ cartilage repair, which initially requires recruited/infiltrated CPC to proliferate, while keeping/inducing their capacity to form cartilaginous matrix. Substrate elasticity allowed for modulating the chondrogenic commitment of HAC (Chapter III). The finding, that a soft substrate (0.3kPa) better supported the chondrogenic phenotype of HAC than i.e. a stiffer substrate (75kPa) suggests this parameter to be promising for modulating the outcome of matrix assisted cartilage repair. Overall, this thesis demonstrates that substrate properties hold substantial potential to modulate CPC behaviour, which could be exploited to improve materials employed in matrix assisted cartilage repair. Yet, although differentially supporting CPC chondrogenesis, none of the substrates was per se chondro-inductive (see chapter I and III) but required for additional, exogenic stimuli as for e.g. transforming growth factor beta (TGF). Thus, modulatory substrate properties as i.e. architecture, composition, ligand presentation and stiffness should be combined with the instructive capacity of soluble stimuli to exploit the full potential of biomaterials in cartilage repair