Mining Architectural Information: A Systematic Mapping Study

Context: Mining Software Repositories (MSR) has become an essential activity in software development. Mining architectural information to support architecting activities, such as architecture understanding and recovery, has received a significant attention in recent years. However, there is an absence of a comprehensive understanding of the state of research on mining architectural information. Objective: This work aims to identify, analyze, and synthesize the literature on mining architectural information in software repositories in terms of architectural information and sources mined, architecting activities supported, approaches and tools used, and challenges faced. Method: A Systematic Mapping Study (SMS) has been conducted on the literature published between January 2006 and November 2021. Results: Of the 79 primary studies finally selected, 8 categories of architectural information have been mined, among which architectural description is the most mined architectural information; 12 architecting activities can be supported by the mined architectural information, among which architecture understanding is the most supported activity; 81 approaches and 52 tools were proposed and employed in mining architectural information; and 4 types of challenges in mining architectural information were identified. Conclusions: This SMS provides researchers with promising future directions and help practitioners be aware of what approaches and tools can be used to mine what architectural information from what sources to support various architecting activities.Comment: 68 pages, 5 images, 15 tables, Manuscript submitted to a Journal (2022

How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

A Portfolio View of a Microsoft Enterprise Architecture

An enterprise architecture (EA) establishes the organization-wide roadmap to achieve an organization’s mission through optimal performance of its core business processes within an efficient information technology (IT) environment. Simply stated, enterprise architectures are “blueprints” for systematically and completely defining an organization’s current (baseline) or desired (target) environment (Schekkerman, 2011). If defined, maintained, and implemented effectively, these blueprints assist in optimizing the interdependencies and interrelationships among the business operations of the enterprise and the underlying IT that support these operations. It has shown that without a complete and enforced EA (Strategic) Business Units, the enterprise run the risk of buying and building systems that are duplicative, incompatible, and unnecessarily costly to maintain and interface. While all the perspectives are key elements of the enterprise architecture, the focus of this project is scoped to three EA perspectives. The first two perspectives are EA’s application and technology architectures, their concepts and key patterns for construction of service oriented and message-based applications that exploit the emerging technology of asynchronous communication services. The third perspective covered is EA’s implementation perspective, which includes the design, development, setup, deployment, and administration of enterprise systems that enable enterprise architecture and modern agile software development and project management

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

Benefits and drawbacks of software reference architectures: A case study

Context: Software Reference Architectures (SRAs) play a fundamental role for organizations whose business greatly depends on the efficient development and maintenance of complex software applications. However, little is known about the real value and risks associated with SRAs in industrial practice. Objective: To investigate the current industrial practice of SRAs in a single company from the perspective of different stakeholders. Method An exploratory case study that investigates the benefits and drawbacks perceived by relevant stakeholders in nine SRAs designed by a multinational software consulting company. Results: The study shows the perceptions of different stakeholders regarding the benefits and drawbacks of SRAs (e.g., both SRA designers and users agree that they benefit from reduced development costs; on the contrary, only application builders strongly highlighted the extra learning curve as a drawback associated with mastering SRAs). Furthermore, some of the SRA benefits and drawbacks commonly highlighted in the literature were remarkably not mentioned as a benefit of SRAs (e.g., the use of best practices). Likewise, other aspects arose that are not usually discussed in the literature, such as higher time-to-market for applications when their dependencies on the SRA are managed inappropriately. Conclusions: This study aims to help practitioners and researchers to better understand real SRAs projects and the contexts where these benefits and drawbacks appeared, as well as some SRA improvement strategies. This would contribute to strengthening the evidence regarding SRAs and support practitioners in making better informed decisions about the expected SRA benefits and drawbacks. Furthermore, we make available the instruments used in this study and the anonymized data gathered to motivate others to provide similar evidence to help mature SRA research and practice.Peer ReviewedPostprint (author's final draft

Specialization in the iStar2.0 language

iStar2.0 has been proposed as a standard language for building goal- and agent-oriented models. It is an evolution of the former i* language, with the purpose of homogenising existing syntactical and semantic variations of basic i* constructs that researchers in the field introduced along the years. In its first version (2016), iStar2.0 was intentionally kept simple, and some constructs were merely introduced but not formally defined. One of them is the notion of specialization. The specialization relationship is offered by iStar2.0 through the is-a construct defined over actors (subactor x is-a superactor y). Although the overall meaning of this construct is highly intuitive, its semantics when it comes to the fine-grained level of the models is not defined in the standard. In this paper we provide a formal definition of the specialization relationship ready to be incorporated into a next release of the iStar2.0 standard language. We root our proposal over existing work on conceptual modeling in general, and object-orientation in particular. Also, we use the results of a survey that provides some hints about what definition do iStar2.0 modelers expect from specialization. As a consequence of this twofold analysis, we identify, define and specify a set of specialization operations that can be applied over iStar2.0 models. Correctness conditions for them are also formally stated. The result of our work is a formal proposal of specialization for iStar2.0 that allows its use in a well-defined manner and contributes to its standardization.Peer ReviewedPostprint (published version

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