Machine learning components are being deployed across nearly every business sector and their importance is continually growing. However, the engineering practices for building these systems remain poorly understood compared to those for conventional software systems. This work provides practical guidance to support architects in designing and implementing machine learning-intensive systems, and identifies areas where there are gaps in understanding and achievement. Building on our prior research, we developed a checklist of quality concerns for architects of machine learning-intensive systems. This checklist was iteratively refined through expert interviews and subsequently validated in a workshop with experienced architects. The main result of this work is a comprehensive list of 40 checks, organized into two main categories and 16 subcategories. Also, we present the results of a workshop where the importance and degree of achievement of each check was assessed by 25 practicing architects of ML-intensive systems. The findings of this study contribute to a better understanding of the unique challenges of ML-intensive systems and offer initial guidance to practitioners, and researchers on areas where future work should be directed. The findings of this study offer valuable support to architects in addressing the unique challenges of ML-intensive systems and provide guidance to practitioners and researchers in terms of where future work should be focused.

The emergence of foundation models (FMs) has enabled the development of highly capable and autonomous agents, unlocking new application opportunities across a wide range of domains. Evaluating the architecture of agents is particularly important as the architectural decisions significantly impact the quality attributes of agents given their unique characteristics, including compound architecture, autonomous and non-deterministic behaviour, and continuous evolution. However, these traditional methods fall short in addressing the evaluation needs of agent architecture due to the unique characteristics of these agents. Therefore, in this paper, we present AgentArcEval, a novel agent architecture evaluation method designed specially to address the complexities of FM-based agent architecture and its evaluation. Moreover, we present a catalogue of agent-specific general scenarios, which serves as a guide for generating concrete scenarios to design and evaluate the agent architecture. We demonstrate the usefulness of AgentArcEval and the catalogue through a case study on the architecture evaluation of a real-world tax copilot, named Luna.

Software repositories are an essential source of information for software engineering research on topics such as project evolution and developer collaboration. Appropriate mining tools and analysis pipelines are therefore an indispensable precondition for many research activities. Ideally, valid results should not depend on technical details of data collection and processing. It is, however, widely acknowledged that mining pipelines are complex, with a multitude of implementation decisions made by tool authors based on their interests and assumptions. This raises the questions if (and to what extent) tools agree on their results and are interchangeable. In this study, we use two tools to extract and analyse ten large software projects, quantitatively and qualitatively comparing results and derived data to better understand this concern. We analyse discrepancies from a technical point of view, and adjust code and parametrisation to minimise replication differences. Our results indicate that despite similar trends, even simple metrics such as the numbers of commits and developers may differ by up to 500%. We find that such substantial differences are often caused by minor technical details. We show how tool-level and data post-processing changes can overcome these issues, but find they may require considerable efforts. We summarise identified causes in our lessons learned to help researchers and practitioners avoid common pitfalls, and reflect on implementation decisions and their influence in ensuring obtained data meets explicit and implicit expectations. Our findings lead us to hypothesise that similar uncertainties exist in other analysis tools, which may limit the validity of conclusions drawn in tool-centric research.

Smart contract-based applications are executed in a blockchain environment, and they cannot directly access data from external systems, which is required for the service provision of these applications. Instead, smart contracts use agents known as blockchain oracles to collect and provide data feeds to the contracts. The functionality and compatibility with smart contract applications need to be considered when selecting the best-fit oracle platform. As the number of oracle alternatives and their features increases, the decision-making process becomes increasingly complex. Selecting the wrong or sub-optimal oracle is costly and may lead to severe security risks. This article provides a decision support model for the oracle selection problem. The model supports smart contract decision-makers in selecting a secure, cost-effective, and feasible oracle platform for their applications. We interviewed oracle co-founders and smart contracts experts to refine and validate the decision model. Two real-world smart contract application case studies were used to evaluate the model. Our model prioritises and suggests more than one possible oracle platform based on the developer’s required criteria, security assessment and cost analysis. Moreover, this guided decision model serves to reveal issues that may go unnoticed if done haphazardly, reduce decision-making efforts and provide a cost-effective solution.

Complex software systems consist of multiple overlapping design structures, such as abstractions, features, crosscutting concerns, or patterns. This is similar to how a human body has multiple interacting subsystems, such as respiratory, digestive, or circulatory. Unlike in the medical domain, software designers do not have an effective way to distinguish, visualize, comprehend, and analyze these interleaving design structures. As a result, developers often struggle through the maze of source code. In this paper, we present anAutomated Concept Explanation(ACE) framework that automatically extracts and categorizes major concepts from source code based on the roles that files play in design structures and their topic frequencies. Based on these categorized concepts, ACE recovers four categories of high-level design models using different algorithms and generates a natural language explanation for each. To assess if and how ACE can help developers better understand design structures, we conducted an empirical study where two groups of graduate students were assigned three design comprehension tasks: identifying feature-related files, identifying dependencies among features, and identifying design patterns used, in an open-source project. The results reveal that the students who used ACE can accomplish these tasks much faster and more accurately, and they acknowledged the usefulness of the categorized concepts and structures, multi-type high-level model visualization, and natural language explanations.

Background: Software practitioners need reliable metrics to monitor software evolution, compare projects, and understand modularity variations. This is crucial for assessing architectural improvement or decay. Existing popular metrics offer little help, especially in systems with implicitly connected but seemingly isolated files.

Mobile applications (apps) have become an essential part of everyday life, offering convenient access to services such as banking, healthcare, and shopping. With these apps handling sensitive personal and financial data, ensuring their security is paramount. While previous research has explored mobile app developer practices, there is limited knowledge about the common practices and challenges that developers face in securing their apps. Our study addresses this need through a global survey of 137 experienced mobile app developers, providing a developer-centric view of mobile app security. Our findings show that developers place high importance on security, frequently implementing features such as authentication and secure storage. They face challenges with managing vulner-abilities, permissions, and privacy concerns, and often rely on resources like Stack Overflow for help. Many developers find that existing learning materials do not adequately prepare them to build secure apps and provide recommendations, such as following best practices and integrating security at the beginning of the development process. We envision our findings leading to improved security practices, better-designed tools and resources, and more effective training programs.

Technical Debt Management (TDM) can suffer from unpredictability, communication gaps and the inaccessibility of relevant information, which hamper the effectiveness of its decision making. These issues can stem from division among decision-makers which takes root in unfair consequences of decisions among different decision-makers. One mitigation route is Skin in the Game thinking, which enforces transparency, fairness and shared responsibility during collective decision-making under uncertainty. This article illustrates characteristics which require Skin in the Game thinking in Technical Debt (TD) identification, measurement, prioritisation and monitoring. We point out crucial problems in TD monitoring rooted in asymmetric information and asymmetric payoff between different factions of decision-makers. A systematic TD monitoring method is presented to mitigate the said problems. The method leverages Replicator Dynamics and Behavioural Learning. The method supports decision-makers with automated TD monitoring decisions; it informs decision-makers when human interventions are required. Two publicly available industrial projects with a non-trivial number of TD and timestamps are utilised to evaluate the application of our method. Mann–Whitney U hypothesis tests are conducted on samples of decisions from our method and the baseline. The statistical evidence indicates that our method can produce cost-effective and contextual TD monitoring decisions.

This workshop aims to address the common bad practices and habits that novice software engineering students develop and how educators can detect them and guide students towards better practices before they become ingrained. The workshop explored this by soliciting contributions of bad practices educators have observed in teaching introductory software engineering. Contributions were workshopped to develop a compendium of bad practices, along with proposed remediations and subsequently shared with the software engineering education community. The workshop concluded with recommendations for using the compendium to improve software engineering education.

Technical debt describes situations where developers write less-than-optimal code to meet project milestones. However, this debt accumulation often results in future developer effort to live with or fix these quality issues. To better manage this debt, developers may document their sub-optimal code as comments in the code (i.e., self-admitted technical debt or SATD). While prior research has investigated the occurrence and characteristics of SATD, this research has primarily focused on non-mobile systems. With millions of mobile applications (apps) in multiple genres available for end-users, there is a lack of research on sub-optimal code developers intentionally implement in mobile apps.In this study, we examine the occurrence and characteristics of SATD in 15,614 open-source Android apps. Our findings show that even though such apps contain occurrences of SATD, the volume per app (a median of 4) is lower than in non-mobile systems, with most debt categorized as Code Debt. Additionally, we identify typical elements in an app that are prone to intentional sub-optimal implementations. We envision our findings supporting researchers and tool vendors with building tools and techniques to support app developers with app maintenance.

Dependencies among software entities are the foundation for much of the research on software architecture analysis and architecture analysis tools. Dynamically typed languages, such as Python, JavaScript and Ruby, tolerate the lack of explicit type references, making certain dependencies indiscernible by a purely syntactic analysis of source code. We call thesepossible dependencies, in contrast with theexplicit dependenciesthat are directly manifested in source code. We find that existing architecture analysis tools have not taken possible dependencies into consideration. An important question therefore is:to what extent will these missing possible dependencies impact architecture analysis?To answer this question, we conducted a study of 499 open-source Python projects, employing type inference techniques and type hint practices to discern possible dependencies. We investigated the consequences of possible dependencies in three software maintenance contexts, including capturing co-change relations recorded in revision history, measuring architectural maintainability, and detecting architecture anti-patterns that violate design principles and impact maintainability. Our study revealed that the impact of possible dependencies on architecture-level maintainability is substantial—higher than that of explicit dependencies. Our findings suggest that architecture analysis and tools should take into account, assess, and highlight the impacts of possible dependencies caused by dynamic typing.

Forming members of an organisation into coherent groups or teams is an important issue in any large-scale software engineering endeavour, especially so in agile software development where teams rely heavily on self-organisation and organisational flexibility. Butis there a recurrent organisational structure pattern in agile software engineering teams?and if sowhat does that pattern imply, in terms of software architecture quality?We address these questions using mixed-methods research in industry featuring interviews, surveys, and Delphi studies of real agile teams. In our study of 30 agile software teams we found that, out of seven organisational structure patterns that recur across our dataset, a single organisational pattern occurs over 37% of the time. This pattern: (a) reflects young communities (1-12 months old); (b) disappears in established ones (13+ months); and (c) reflects the highest number of architecture smells reported. Finally, we observe a negative correlation between a proposed organisational measure and architecture smells. On the one hand, these insights may serve to aid architects in designing not only their architectures but also their communities to best support their co-evolution. On the other hand, we observe that organisational structures in software engineering influence much more than simply software architectures, and we expect our results to lay the foundations of more structured and rigorous approaches to organisational structure studies and use in software engineering research and practice.

The IEEE International Conference on Software Architecture is the premier venue for practitioners and researchers interested in software architecture, in component-based software engineering and in quality aspects of software and how these relate to the design of software. ICSA has a strong tradition as a working conference, where researchers meet practicing software architects who can explain the problems they face in their day-to-day duties, and who can influence the future of the field.

Abstract Traditionally, the quality of a software or system architecture has been evaluated in the early stages of the development process using architecture quality evaluation methods. Emergent approaches like Industry 4.0 require continuous monitoring of both run‐time and development‐time quality properties, in contrast to traditional systems where quality is evaluated at specific milestones using techniques such as project reviews. Considering the dynamics and minimum down‐time imposed by the industrial production domain, it must also be ensured that Industry 4.0 system evaluations are continuously performed with high confidence and with as much automation as possible, using simulations, for instance. In this regard, there is a need to develop new methods for continuously monitoring and evaluating the quality properties of software‐based systems for Industry 4.0, which must be supported by automated quality evaluation techniques. In this research we analyze traditional architecture evaluation methods and Industry 4.0 scenarios, and propose an approach based on Digital Twins and simulations to continuously evaluate runtime quality aspects of the architecture and systems of industrial production plants. The evaluation is based on the instantiation of our approach for a concrete demand of an automation plant in the automotive domain.

Blockchain is a disruptive technology intended to implement secure decentralised distributed systems, in which transactional data can be shared, stored, and verified by participants of the system without needing a central authentication/verification authority. Blockchain-based systems have several architectural components and variants, which architects can leverage to build secure software systems. However, there is a lack of studies to assist architects in making architecture design and configuration decisions for blockchain-based systems. This knowledge gap may increase the chance of making unsuitable design decisions and producing configurations prone to potential security risks. To address this limitation, we report our comprehensive systematic literature review to derive a taxonomy of commonly used architecture design decisions in blockchain-based systems. We map each of these decisions to potential security attacks and their posed threats. MITRE’s attack tactic categories and Microsoft STRIDE threat modeling are used to systematically classify threats and their associated attacks to identify potential attacks and threats in blockchain-based systems. Our mapping approach aims to guide architects to make justifiable design decisions that will result in more secure implementations.

Design-time evaluation is essential to build the initial software architecture to be deployed. However, experts’ assumptions made at design-time are unlikely to remain true indefinitely in systems that are characterized by scale, hyperconnectivity, dynamism, and uncertainty in operations (e.g. IoT). Therefore, experts’ design-time decisions can be challenged at run-time. A continuous architecture evaluation that systematically assesses and intertwines design-time and run-time decisions is thus necessary. This paper proposes the first proactive approach to continuous architecture evaluation of the system leveraging the support of simulation. The approach evaluates software architectures by not only tracking their performance over time, but also forecasting their likely future performance through machine learning of simulated instances of the architecture. This enables architects to make cost-effective informed decisions on potential changes to the architecture. We perform an IoT case study to show how machine learning on simulated instances of architecture can fundamentally guide the continuous evaluation process and influence the outcome of architecture decisions. A series of experiments is conducted to demonstrate the applicability and effectiveness of the approach. We also provide the architect with recommendations on how to best benefit from the approach through choice of learners and input parameters, grounded on experimentation and evidence.

While state of the art of software refactoring research uses various quality attributes to identify refactoring opportunities and evaluate refactoring recommendations, the impact of refactoring on the security of software systems when improving other quality objectives is under-explored. It is critical to understand how a system is resistant to security risks after refactoring to improve quality metrics. For instance, refactoring is widely used to improve the reusability of code, however such an improvement may increase the attack surface due to the created abstractions. Increasing the spread of security-critical classes in the design to improve modularity may result in reducing the resilience of software systems to attacks. In this paper, we investigated the possible impact of improving different quality attributes (e.g., reusability, extendibility, etc.), from the QMOOD model, effectiveness on a set of 8 security metrics defined in the literature related to the data access. We also studied the impact of different refactorings on these static security metrics. Then, we proposed a multi-objective refactoring recommendation approach to find a balance between quality attributes and security based on the correlation results to guide the search. We evaluated our tool on 30 open source projects. We also collected the practitioner perceptions on the refactorings recommended by our tool in terms of the possible impact on both security and other quality attributes. Our results confirm that developers need to make trade-offs between security and other qualities when refactoring software systems due to the negative correlations between them.

We report on a large-scale empirical study investigating the relevance of socio-technical congruence over key basic software quality metrics, namely, bugs and churn. In particular, we explore whether alignment or misalignment of social communication structures and technical dependencies in large software projects influences software quality. To this end, we have defined a quantitative and operational notion of socio-technical congruence, which we callsocio-technical motif congruence(STMC). STMC is a measure of the degree to which developers working on the same file or on two related files, need to communicate. As socio-technical congruence is a complex and multi-faceted phenomenon, the interpretability of the results is one of our main concerns, so we have employed a careful mixed-methods statistical analysis. In particular, we provide analyses with similar techniques as employed by seminal work in the field to ensure comparability of our results with the existing body of work. The major result of our study, based on an analysis of 25 large open-source projects, is that STMC isnotrelated to project quality measures—software bugs and churn—in any temporal scenario. That is, we find no statistical relationship between the alignment of developer tasks and developer communications on the one hand, and project outcomes on the other hand. We conclude that, wherefore congruence does matter as literature shows, then its measurable effect lies elsewhere.

Due to the conflicting nature of quality measures, there are always multiple refactoring options to fix quality issues. Thus, interaction with developers is critical to inject their preferences. While several interactive techniques have been proposed, developers still need to examine large numbers of possible refactorings, which makes the interaction time-consuming. Furthermore, existing interactive tools are limited to the ”objective space” to show developers the impacts of refactorings on quality attributes. However, the “decision space” is also important since developers may want to focus on specific code locations. In this paper, we propose an interactive approach that enables developers to pinpoint their preference simultaneously in the objective (quality metrics) and decision (code location) spaces. Developers may be interested in looking at refactoring strategies that can improve a specific quality attribute, such as extendibility (objective space), but such strategies may be related to different code locations (decision space). A plethora of solutions is generated at first using multi-objective search that tries to find the possible trade-offs between quality objectives. Then, an unsupervised learning algorithm clusters the trade-off solutions based on their quality metrics, and another clustering algorithm is applied within each cluster of the objective space to identify solutions related to different code locations. The objective and decision spaces can now be explored more efficiently by the developer, who can give feedback on a smaller number of solutions. This feedback is then used to generate constraints for the optimization process, to focus on the developer's regions of interest in both the decision and objective spaces. A manual validation of selected refactoring solutions by developers confirms that our approach outperforms state of the art refactoring techniques.

Architectural Technical Debt (ATD) refers to sub-optimal architectural design in a software system that incurs high maintenance “interest” over time. Previous research revealed thatATDhas significant negative impact on daily development. This paper contributes an approach to enable an architect to precisely locateATDs, as well as capture the trajectory of maintenance cost on each debt, based on which, predict the cost of the debt in a future release. TheATDsare expressed in four typical patterns, which entail the core of each debt. Furthermore, we aggregate compoundATDsto capture the complicated relationship among multipleATDinstances, which should be examined together for effective refactoring solutions. We evaluate our approach on 18 real-world projects. We identifiedATDsthatpersistentlyincur significant (up to 95 percent of) maintenance costs in most projects. The maintenance costs on the majority of debts fit into a linear regression model—indicating stable “interest” rate. In five projects, 12.1 to 27.6 percent of debts fit into an exponential model, indicating increasing “interest” rate, which deserve higher priority from architects. The regression models can accurately predict the costs of the majority of (82 to 100 percent) debts in the next release of a system. By aggregating relatedATDs, architects can focus on a small number of cost-effective compound debts, which contain a relatively small number of source files, but account for a large portion of maintenance costs in their projects. With these capabilities, our approach can help architects make informed decisions regarding whether, where, and how to refactor for eliminatingATDsin their systems.

Over the past three decades software engineering researchers have produced a wide range of techniques and tools for understanding the architectures of large, complex systems. However, these have tended to be one-off research projects, and their idiosyncratic natures have hampered research collaboration, extension and combination of the tools, and technology transfer. The area of software architecture is rich with disjoint research and development infrastructures, and datasets that are either proprietary or captured in proprietary formats. This paper describes a concerted effort to reverse these trends. We have designed and implemented a flexible and extensible infrastructure (SAIN) with the goal of sharing, replicating, and advancing software architecture research. We have demonstrated that SAIN is capable of incorporating the constituent tools extracted from three independently developed, large, long-lived software architecture research environments. We discuss SAIN's ambitious goals, the challenges we have faced in achieving those goals, the key decisions made in SAIN's design and implementation, the lessons learned from our experience to date, and our ongoing and future work.

Code bad smells are symptoms of poor design and implementation. There are several well-known smell types, such as large classes (aka God classes), code clones, etc. and they have been shown to lead to technical debt and hence to decrease code maintainability. Quality gates are a recent technology that prevents the automatic acceptance of push requests of code commits that have been identified as containing certain smells. However, it is a challenging activity to decide which smells should be included in the quality gate, as developers may choose to optimize short term benefits like time to market over long term benefits like maintainability. But some smells appear to provide no benefit to developers whatsoever and hence such smells should always be avoided. The aims of this paper are: 1) to identify "worst smells", i.e., bad smells that never have a good reason to exist, 2) to determine the frequency, change-proneness, and severity associated with worst smells, and 3) to identify the "worst reasons", i.e., the reasons for introducing these worst smells in the first place. To achieve these aims we ran a survey with 71 developers. We learned that 80 out of 314 catalogued code smells are "worst"; that is, developers agreed that these 80 smells should never exist in any code base. We then checked the frequency and change-proneness of these worst smells on 27 large Apache open- source projects. Our results show insignificant differences, in both frequency and change proneness, between worst and non-worst smells. That is to say, these smells are just as damaging as other smells, but there is never any justifiable reason to introduce them. Finally, in follow-up phone interviews with five developers we confirmed that these smells are indeed worst, and the interviewees proposed seven reasons for why they may be introduced in the first place. By explicitly identifying these seven reasons, project stakeholders can, through quality gates or reviews, ensure that such smells are never accepted in a code base, thus improving quality without compromising other goals such as agility or time to market.

In Dynamic Service Composition (DSC), an application can be dynamically composed using web services to achieve its functional and Quality of Services (QoS) goals. DSC is a relatively mature area of research that crosscuts autonomous and services computing. Complex autonomous and self-adaptive computing paradigms (e.g., multi-tenant cloud services, mobile/smart services, services discovery and composition in intelligent environments such as smart cities) have been leveraging DSC to dynamically and adaptively maintain the desired QoS, cost and to stabilize long-lived software systems. While DSC is fundamentally known to be an NP-hard problem, systematic attempts to analyze its scalability have been limited, if not absent, though such analysis is of a paramount importance for their effective, efficient, and stable operations. This article reports on a new application of goal-modeling, providing a systematic technique that can support DSC designers and architects in identifying DSC-relevant characteristics and metrics that can potentially affect the scalability goals of a system. The article then applies the technique to two different approaches for QoS-aware dynamic services composition, where the article describes two detailed exemplars that exemplify its application. The exemplars hope to provide researchers and practitioners with guidance and transferable knowledge in situations where the scalability analysis may not be straightforward. The contributions provide architects and designers for QoS-aware dynamic service composition with the fundamentals for assessing the scalability of their own solutions, along with goal models and a list of application domain characteristics and metrics that might be relevant to other solutions. Our experience has shown that the technique was able to identify in both exemplars application domain characteristics and metrics that had been overlooked in previous scalability analyses of these DSC, some of which indeed limited their scalability. It has also shown that the experiences and knowledge can be transferable: The first exemplar was used as an example to inform and ease the work of applying the technique in the second one, reducing the time to create the model, even for a non-expert.

Context: Evaluating software architectures in uncertain environments raises new challenges, which require continuous approaches. We define continuous evaluation as multiple evaluations of the software architecture that begins at the early stages of the development and is periodically and repeatedly performed throughout the lifetime of the software system. Numerous approaches have been developed for continuous evaluation; to handle dynamics and uncertainties at run-time, over the past years, these approaches are still very few, limited, and lack maturity. Objective: This review surveys efforts on architecture evaluation and provides a unified terminology and perspective on the subject. Method: We conducted a systematic literature review to identify and analyse architecture evaluation approaches for uncertainty including continuous and non-continuous, covering work published between 1990–2020. We examined each approach and provided a classification framework for this field. We present an analysis of the results and provide insights regarding open challenges. Major results and conclusions: The survey reveals that most of the existing architecture evaluation approaches typically lack an explicit linkage between design-time and run-time. Additionally, there is a general lack of systematic approaches on how continuous architecture evaluation can be realised or conducted. To remedy this lack, we present a set of necessary requirements for continuous evaluation and describe some examples.

Blockchain offers a distributed ledger to record data collected from Internet of Thing (IoT) devices as immutable and tamper-proof transactions and securely shared among authorized participants in a Peer-to-Peer (P2P) network. Despite the growing interest in using blockchain for securing IoT systems, there is a general lack of systematic research and comprehensive review of the design issues on the integration of blockchain and IoT from the software architecture perspective. This article presents a catalog of architectural tactics for the design of IoT systems supported by blockchain as a result of a Systematic Literature Review (SLR) on IoT and blockchain to extract the commonly reported quality attributes, design decisions, and relevant architectural tactics for the architectural design of this category of systems. Our findings are threefold:<?brk?> (i) identification of security, scalability, performance, and interoperability as the commonly reported quality attributes; (ii) a catalog of twelve architectural tactics for the design of IoT systems supported by blockchain; and (iii) gaps in research that include tradeoffs among quality attributes and identified tactics. These tactics might provide architects and designers with different options when searching for an optimal architectural design that meets the quality attributes of interest and constraints of a system.

Monolithic systems increasingly suffer from maintainability and scalability issues as they grow in functionality, size, and complexity. It is widely believed that (micro)service-based architectures can alleviate these problems as each service is supposed to have the following characteristics: clearly defined functionality, sufficient modularity, and the ability to evolve independently. Industrial practices show that service extraction from a legacy monolithic system is labor-intensive and complex. Existing work on service candidate identification aims to group entities of a monolithic system into potential service candidates, but this process has two major challenges: first, it is difficult to extract service candidates with consistent quality; second, it is hard to evaluate the identified service candidates regarding the above three characteristics. To address these challenges, this paper proposes the Functionality-oriented Service Candidate Identification (FoSCI) framework to identify service candidates from a monolithic system. Our approach is to record the monolith's execution traces, and extract services candidates using a search-based functional atom grouping algorithm. We also contribute a comprehensive service candidate evaluation suite that uses interface information, structural/conceptual dependency, and commit history. This evaluation system consists of 8 metrics, measuring functionality, modularity, and evolvability respectively of identified service candidates. We compare FoSCI with three existing methods, using 6 widely-used open-source projects as our evaluation subjects. Our results show that FoSCI outperforms existing methods in most measures.

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.

Software engineering is now more than ever a community effort. Its success often weighs on balancing distance, culture, global engineering practices and more. In this scenario many unforeseen socio-technical events may result into additional project cost or “social” debt, e.g., sudden, collective employee turnover. With industrial research we discovered community smells, that is, sub-optimal patterns across the organisational and social structure in a software development community that are precursors of such nasty socio-technical events. To understand the impact of community smells at large, in this paper we first introduce CodeFace4Smells, an automated approach able to identify four community smell types that reflect socio-technical issues that have been shown to be detrimental both the software engineering and organisational research fields. Then, we perform a large-scale empirical study involving over 100 years worth of releases and communication structures data of 60 open-source communities: we evaluate (i) their diffuseness, i.e., how much are they distributed in open-source, (ii) how developers perceive them, to understand whether practitioners recognize their presence and their negative effects in practice, and (iii) how community smells relate to existing socio-technical factors, with the aim of assessing the inter-relations between them. The key findings of our study highlight that community smells are highly diffused in open-source and are perceived by developers as relevant problems for the evolution of software communities. Moreover, a number of state-of-the-art socio-technical indicators (e.g., socio-technical congruence) can be used to monitor how healthy a community is and possibly avoid the emergence of social debt.

Architecture design is notoriously difficult to teach and to learn. Most competent architects in industry have deep knowledge won from long years of experience. But if we want architecture design to be methodical and repeatable, we need better ways of teaching it. Simply waiting for an aspiring young architect to accumulate 10 or 20 years of experience is not acceptable if we believe that software engineering is a true engineering discipline that can be taught and learned in a reasonable time-frame. In this talk I will describe my experiences based on over 20 years of teaching software architecture design (and analysis), to both undergraduates and industry professionals. I will reflect on three aspects of teaching design, each of which was a major “lesson learned” for me: 1) the need for a methodical approach to design, 2) role-playing and game-play as a means of engaging learners to learn a method, and 3) tool-support for teaching.

Architecture design is notoriously difficult to teach and to learn. Most competent architects in industry have deep knowledge won from long years of experience. But if we want architecture design to be methodical and repeatable, we need better methods for teaching it. Simply waiting for an aspiring architect to accumulate 10 or 20 years of experience is not acceptable if we believe that software engineering is a true engineering discipline that can be taught and learned in a reasonable time-frame.

In this paper we present Software Archinaut-a tool used to help identify technical debt hotspots in an architecture, and manage the evolution of the architecture once these hotspots are discovered. Archinaut is a platform that integrates analyses from different tools. It supports three main usage scenarios: 1) understanding the architecture, 2) identifying technical debt hotspots, and 3) monitoring and controlling the evolution of the architecture. We illustrate these scenarios by using Apache Kafka as an example.

Dependencies among software entities are the basis for many software analytic research and architecture analysis tools. Dynamically typed languages, such as Python, JavaScript and Ruby, tolerate the lack of explicit type references, making certain syntactic dependencies indiscernible in source code. We call these possible dependencies, in contrast with the explicit dependencies that are directly referenced in source code. Type inference techniques have been widely studied and applied, but existing architecture analytic research and tools have not taken possible dependencies into consideration. The fundamental question is, to what extent will these missing possible dependencies impact the architecture analysis? To answer this question, we conducted an empirical study with 105 Python projects, using type inference techniques to manifest possible dependencies. Our study revealed that the architectural impact of possible dependencies is substantial---higher than that of explicit dependencies: (1) file-level possible dependencies account for at least 27.93% of all file-level dependencies, and create different dependency structures than that of explicit dependencies only, with an average difference of 30.71%; (2) adding possible dependencies significantly improves the precision (0.52%~14.18%), recall(31.73%~39.12%), and F1 scores (22.13%~32.09%) of capturing co-change relations; (3) on average, a file involved in possible dependencies influences 28% more files and 42% more dependencies within architectural sub-spaces than a file involved in just explicit dependencies; (4) on average, a file involved in possible dependencies consumes 32% more maintenance effort. Consequently, maintainability scores reported by existing tools make a system written in these dynamic languages appear to be better modularized than it actually is. This evidence strongly suggests that possible dependencies have a more significant impact than explicit dependencies on architecture quality, that architecture analysis and tools should assess and even emphasize the architectural impact of possible dependencies due to dynamic typing.

Abstract Usability is a highly desired but often ignored software quality. Effective user interfaces tend to increase learnability, effectiveness and user satisfaction. But usability is often neglected in the early stages of software development and is thus frequently not address in a system's architectural design. Furthermore, because usability is often neglected or deferred, it is difficult to estimate the effort specifically spent on adding or improving usability mechanisms in the software architecture and in code. In this work, we present a case study where we analyze the impact of introducing a variety of usability mechanisms to a mobile application and we report on the architectural changes that must be made in the software architecture to accommodate them. We also report on the additional code required to implement these usability mechanisms and we investigate the users' satisfaction of combining and using several usability mechanisms in a mobile application. Finally, we evaluated user responses—both positive and negatives—to these usability mechanisms via a questionnaire involving 25 users from different roles and different organizations and including contextual interviews to analyze the qualitative responses of the subjects. Our results show that apart from the relatively modest modeling and coding effort, the combination of several usability mechanisms seems beneficial for users of mobile systems and increases the satisfaction during the interaction with the system.

Summary Microservices have gained wide recognition and acceptance in software industries as an emerging architectural style for autonomic, scalable, and more reliable computing. The transition to microservices has been highly motivated by the need for better alignment of technical design decisions with improving value potentials of architectures. Despite microservices' popularity, research still lacks disciplined understanding of transition and consensus on the principles and activities underlying that transition. In this paper, we report on a systematic mapping study that consolidates various views, approaches and activities that commonly assist in the transition to microservices. The study aims to provide a better understanding of the transition; it also contributes a working definition of the transition and technical activities underlying it. We term the transition and technical activities leading to microservice architectures as microservitization. We then shed light on a fundamental problem of microservitization: microservice granularity and reasoning about its adaptation as first‐class entities. This study reviews state‐of‐the‐art and ‐practice related to reasoning about microservice granularity; it reviews modeling approaches, aspects considered, guidelines and processes used to reason about microservice granularity. This study identifies opportunities for future research and development related to reasoning about microservice granularity.

Summary Forges are online collaborative platforms to support the development of distributed open source software. While once mighty keepers of open source vitality, software forges are rapidly becoming less and less relevant. For example, of the top 10 forges in 2011, only one survives today—SourceForge—the biggest of them all, but its numbers are dropping and its community is tenuous at best. Through mixed‐methods research, this article chronicles and analyze the software practice and experiences of the project's history—in particular its architectural and community/organizational decisions. We discovered a number of suboptimal social and architectural decisions and circumstances that, may have led to SourceForge's demise. In addition, we found evidence suggesting that the impact of such decisions could have been monitored, reduced, and possibly avoided altogether. The use of sociotechnical insights needs to become a basic set of design and software/organization monitoring principles that tell a cautionary tale on what to measure and what not to do in the context of large‐scale software forge and community design and management.

This paper present our tool suite called DV8. The objective of DV8 is to measure software modularity, detect architecture anti-patterns as technical debts, quantify the maintenance cost of each instance of an anti-pattern, and enable return on investment analyses of architectural debts. Different from other tools, DV8 integrates data from both source code and revision history. We now elaborate on each of DV8's capabilities.

Energy consumption is a concern in the data-center and at the edge, on mobile devices such as smartphones. Software that consumes too much energy threatens the utility of the end-user's mobile device. Energy consumption is fundamentally a systemic kind of performance and hence it should be addressed at design time via a software architecture that supports it, rather than after release, via some form of refactoring. Unfortunately developers often lack knowledge of what kinds of designs and architectures can help address software energy consumption. In this paper we show that some simple design choices can have significant effects on energy consumption. In particular we examine the Model-View-Controller architectural pattern and demonstrate how converting to Model-View-Presenter with bundling can improve the energy performance of both benchmark systems and real world applications. We show the relationship between energy consumption and bundled and delayed view updates: bundling events in the presenter can often reduce energy consumption by 30%.

Architecture degradation has a strong negative impact on software quality and can result in significant losses. Severe software degradation does not happen overnight. Software evolves continuously, through numerous issues, fixing bugs and adding new features, and architecture flaws emerge quietly and largely unnoticed until they grow in scope and significance when the system becomes difficult to maintain. Developers are largely unaware of these flaws or the accumulating debt as they are focused on their immediate tasks of address individual issues. As a consequence, the cumulative impacts of their activities, as they affect the architecture, go unnoticed. To detect these problems early and prevent them from accumulating into severe ones we propose to monitor software evolution by tracking the interactions among files revised to address issues. In particular, we propose and show how we can automatically detect active hotspots, to reveal architecture problems. We have studied hundreds of hotspots along the evolution timelines of 21 open source projects and showed that there exist just a few dominating active hotspots per project at any given time. Moreover, these dominating active hotspots persist over long time periods, and thus deserve special attention. Compared with state-of-the-art design and code smell detection tools we report that, using active hotspots, it is possible to detect signs of software degradation both earlier and more precisely.

In this paper, we propose an architecture model called Design Rule Space (DRSpace). We model the architecture of a software system as multiple overlapping DRSpaces, reflecting the fact that any complex software system must contain multiple aspects, features, patterns, etc. We show that this model provides new ways to analyze software quality. In particular, we introduce an Architecture Root detection algorithm that captures DRSpaces containing large numbers of a project's bug-prone files, which are called Architecture Roots (ArchRoots). After investigating ArchRoots calculated from 15 open source projects, the following observations become clear: from 35 to 91 percent of a project's most bug-prone files can be captured by just 5 ArchRoots, meaning that bug-prone files are likely to be architecturally connected. Furthermore, these ArchRoots tend to live in the system for significant periods of time, serving as the major source of bug-proneness and high maintainability costs. Moreover, each ArchRoot reveals multiple architectural flaws that propagate bugs among files and this will incur high maintenance costs over time. The implication of our study is that the quality, in terms of bug-proneness, of a large, complex software project cannot be fundamentally improved without first fixing its architectural flaws.

Background: Though much research has been conducted to investigate software maintenance activities, there has been little work charactering maintenance files as a community and exploring the evolution of this community. Aims: The goal of our research is to identify maintenance communities and monitor their evolution-birth, growth, death and rejuvenation. Method: In this paper, we leveraged a social community detection algorithm---clique prelocation method (CPM)---to identify file communities. Then we implemented an algorithm to detect new communities, active communities, inactive communities and reactivated communities by cumulatively detecting and constantly comparing communities in time sequences. Results: Based on our analysis of 14 open-source projects, we found that new communities are mostly caused by bug and improvement issues. An active community can be vigorous, on and off, through the entire life of a system, and so does an inactive community. In addition, an inactive community can be reactivated again, mostly through bug issues. Conclusions: These findings add to our understanding of software maintenance communities and help us identify the most expensive maintenance spots by identifying constantly active communities.

Despite efforts in the security community to quickly index and disseminate vulnerabilities as they are discovered and addressed, there are concerns about how to scale up the knowledge management of vulnerabilities given its dramatic growth rate. To address these concerns, recent research shifted towards more proactive approaches, in particular leveraging text mining methods to improve vulnerability identification and dissemination to security investigators. While providing a starting point for understanding vulnerability trends, recent methods are still reliant on curated identifiers, such as 'CVE-*', hence missing the majority of cybersecurity activity. We show that we can leverage overlapping textual themes in software vulnerabilities to identify related software vulnerability discussions without prior knowledge of identifiers. Our method obtained 86% accuracy in identifying related vulnerabilities with minimal pre-processing in a noisy community.

Enabling rapid feature delivery is essential for product success and is therefore a goal of software architecture design. But how can we determine if and to what extent an architecture is "good enough" to support feature addition and evolution, or determine if a refactoring effort is successful in that features can be added more easily? In this paper, we contribute a concept called the Feature Space, and a formal definition of Feature Dependency, derived from a software project's revision history. We capture the dependency relations among the features of a system in a feature dependency structure matrix (FDSM), using features as first-class design elements. We also propose a Feature Decoupling Level (FDL) metric that can be used to measure the level of independence among features. Our investigation of 17 open source projects shows that files within each feature space are much more likely to be changed together, hence each feature space forms a meaningful maintainable unit that should be treated separately. The data also show that the history-based FDL is highly correlated a structure-based maintainability metric: Decoupling Level (DL). When we examine a project's evolution history, we see that if a system is well-modularized, it is more likely that features can be added independently. For shorter periods of time, however, FDL and DL may not be consistent, e.g., when the addition of new features deviates from the designed architecture or does not involve parts of the system that have architecture flaws. In such cases, FDL and FDSM can be used to monitor potential architecture degradation caused by improper feature addition.

In this paper, we report our experiences of applying three complementary automated software architecture analysis techniques, supported by a tool suite, called DV8, to 8 industrial projects within a large company. DV8 includes two state-of-the-art architecture-level maintainability metrics—Decoupling Level and Propagation Cost, an architecture flaw detection tool, and an architecture root detection tool. We collected development process data from the project teams as input to these tools, reported the results back to the practitioners, and followed up with telephone conferences and interviews. Our experiences revealed that the metrics scores, quantitative debt analysis, and architecture flaw visualization can effectively bridge the gap between management and development, help them decide if, when, and where to refactor. In particular, the metrics scores, compared against industrial benchmarks, faithfully reflected the practitioners’ intuitions about the maintainability of their projects, and enabled them to better understand the maintainability relative to other projects internal to their company, and to other industrial products. The automatically detected architecture flaws and roots enabled the practitioners to precisely pinpoint, visualize, and quantify the “hotspots" within the systems that are responsible for high maintenance costs. Except for the two smallest projects for which both architecture metrics indicated high maintainability, all other projects are planning or have already begun refactorings to address the problems detected by our analyses. We are working on further automating the tool chain, and transforming the analysis suite into deployable services accessible by all projects within the company.

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.

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.

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.

Attribute Driven Design (ADD)--a method for designing software architectures--was originally developed by the Software Engineering Institute in 2000.ADD 2.0, was published in 2006. Recently we have made some significant changes to ADD to make it easier to enact, to make it better aligned with the way that software is developed today, and hence to improve its adoption by the software architecture practitioner community.In this tutorial we will introduce ADD 3.0 and explain the key changes that we made to its previous versions. We will also present a detailed real-world case study, in the domain of big data, and walk the participants through a few iterations of the method showing how the steps are performed in practice. Then the participants will have the opportunity to enact several iterations of the method on their own. We will place particular emphasis on the design decisions that are made in the different design iterations: how different concepts are used in different iterations, and how these decisions are made more confidently through the use of a reusable catalog of design concepts, how these are documented, and how these can be analyzed within the design process.

This article contributes an architecture-centric methodology, called AABA (Architecture-centric Agile Big data Analytics), to address the technical, organizational, and rapid technology change challenges of both big data system development and agile delivery of big data analytics for Web-based Systems (WBS). As the first of its kind, AABA fills a methodological void by adopting an architecture-centric approach, advancing and integrating software architecture analysis and design, big data modeling and agile practices. This article describes how AABA was developed, evolved and validated simultaneously in 10 empirical WBS case studies through three CPR (Collaborative Practice Research) cycles. In addition, this article presents an 11th case study illustrating the processes, methods and techniques/tools in AABA for cost-effectively achieving business goals and architecture agility in a large scale WBS. All 11 case studies showed that architecture-centric design, development, and operation is key to taming technical complexity and achieving agility necessary for successful WBS big data analytics development. Our contribution is novel and important. The use of reference architectures, a design concepts catalog and architectural spikes in AABA are advancements to architecture design methods. In addition, our architecture-centric approach to DevOps was critical for achieving strategic control over continuous big data value delivery for WBS.

Sustaining large open source development efforts requires recruiting new participants; however, a lack of architectural documentation might inhibit new participants since large amounts of project knowledge are unavailable to newcomers. We present the results of a multitrait, multimethod analysis of the effects of introducing architectural documentation into a substantial open source project-the Hadoop Distributed File System (HDFS). HDFS had only minimal architectural documentation, and we wanted to discover whether the putative benefits of architectural documentation could be observed over time. To do this, we created and publicized an architecture document and then monitored its usage and effects on the project. The results were somewhat ambiguous: by some measures the architecture documentation appeared to effect the project but not by others. Perhaps of equal importance is our discovery that the project maintained, in its Web-accessible JIRA archive of software issues and fixes, enough architectural discussion to support architectural thinking and reasoning. This “emergent” architecture documentation served an important purpose in recording core project members' architectural concerns and resolutions. However, this emergent architecture documentation did not serve all project members equally well; it appears that those on the periphery of the project-newcomers and adopters-still require explicit architecture documentation, as we will show.

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.

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.

A Security Pattern encapsulates security design expertise that addresses recurring information security problems in the form of a credentialed solution. It also presents potential problems and trade-offs in its application. This paper proposes a novel classification model for security patterns. Based on our review of more than one hundred security patterns, we categorize security patterns according to the type of vulnerability they address and also identify similar or identical patterns with different names. Our literature review indicates that there exists very little research on the categorization of security patterns based on vulnerabilities. Any attackers need to exploit existing vulnerabilities to break the security of an information system. To solve security problems effectively, we have to fix their root causes, which are vulnerabilities. The primary contribution of this paper is twofold: (1) to propose a novel security pattern classification model that helps software designers choose an appropriate security pattern once they know the type of a vulnerability they would like to remove and (2) to identify missing security patterns, which naturally emerge as a result of classifying security patterns according to the vulnerabilities they address. The identification of missing patterns could be useful in soliciting help to develop more patterns from the security community to tackle the vulnerabilities currently not handled by the existing patterns.

Customer requirements are critical factors in the success of a software project. Owing to their importance, several methods for understanding customer requirements have been studied in requirements engineering. Although previous studies have mainly focused on the elicitation and analysis of requirements, a method for validating elicited requirements from the customers' perspective has not been actively studied. In this paper, we propose a customer requirements validation (Curve) method using the mental model technique, which is used for analyzing customers' behaviors and their mental states. The Curve provides clear criteria for requirements validation, an integrated framework for evaluating requirements, and it enables prioritization of key requirements based on customers' inner needs. Through this method it is possible to produce software products that better satisfy customers' true needs.

There is growing interest in continuous delivery practices to enable rapid and reliable deployment. While practices are important, we suggest architectural design decisions are equally important for projects to achieve goals such continuous integration (CI) build, automated testing and reduced deployment-cycle time. Architectural design decisions that conflict with deploy ability goals can impede the team's ability to achieve the desired state of deployment and may result in substantial technical debt. To explore this assertion, we interviewed three project teams striving to practicing continuous delivery. In this paper, we summarize examples of the deploy ability goals for each project as well as the architectural decisions that they have made to enable deploy ability. We present the deploy ability goals, design decisions, and deploy ability tactics collected and summarize the design tactics derived from the interviews in the form of an initial draft version hierarchical deploy ability tactic tree.

In this paper, we investigate software architecture as a set of overlapping design rule spaces, formed by one or more structural or evolutionary relationships and clustered using our design rule hierarchy algorithm. Considering evolutionary coupling as a special type of relationship, we investigated (1) whether design rule spaces can reveal structural relations among error-prone files; (2) whether design rule spaces can reveal structural problems contributing to error-proneness.We studied three large-scale open source projects and found that error-prone files can be captured by just a few design rule sub-spaces. Supported by our tool, Titan, we are able to flexibly visualize design rule spaces formed by different types of relationships, including evolutionary dependencies. This way, we are not only able to visualize which error-prone files belong to which design rule spaces, but also to visualize the structural problems that give insight into why these files are error prone. Design rule spaces provide valuable direction on which parts of the architecture are problematic, and on why, when, and how to refactor.

In this tool demo, we will illustrate our tool---Titan---that supports a new architecture model: design rule spaces (DRSpaces). We will show how Titan can capture both architecture and evolutionary structure and help to bridge the gap between architecture and defect prediction. We will demo how to use our toolset to capture hundreds of buggy files into just a few architecturally related groups, and to reveal architecture issues that contribute to the error-proneness and change-proneness of these groups. Our tool has been used to analyze dozens of large-scale industrial projects, and has demonstrated its ability to provide valuable direction on which parts of the architecture are problematic, and on why, when, and how to refactor. The video demo of Titan can be found at https://art.cs.drexel.edu/~lx52/titan.mp4

While modularity is highly regarded as an important quality of software, it poses an educational dilemma: the true value of modularity is realized only as software evolves, but student homework, assignments and labs, once completed, seldom evolve. In addition, students seldom receive feedback regarding the modularity and evolvability of their designs. Prior work has shown that it is extremely easy for students and junior developers to introduce extra dependencies in their programs. In this paper, we report on a first experiment applying a tool-supported architecture review process in a software design class. To scientifically address this education problem, our first objective is to advance our understanding of why students make these modularity mistakes, and how the mistakes can be corrected. We propose tool-guided architecture review so that modularity problems in students' implementation can be revealed and their consequences can be assessed against possible change scenarios. Our pilot study shows that even students who understand the importance of modularity and have excellent programming skills may introduce additional harmful dependencies in their implementations. Furthermore, it is hard for them to detect the existence of these dependencies on their own. Our pilot study also showed that students need more formal training in architectural review to effectively detect and analyze these problems.

Software design, development and evolution commonly require programmers to model design decisions, visualize implemented programs, and detect conflicts between design and implementation. However, common design notations rarely reconcile theoretical concerns for rigor and minimality with the practical concerns for abstraction, scalability and automated verifiability. The language of Codecharts was designed to overcome these challenges by narrowing its scope to visual specifications that articulate automatically-verifiable statements about the structure and organization of object-oriented programs. The tokens in its visual vocabulary stand for the building-blocks of object-oriented design, such as inheritance class hierarchies, sets of dynamically-bound methods, and their correlations. The formalism was tailored for those pragmatic concerns which arise from modeling class libraries and design patterns, and for visualizing programs of any size at any level of abstraction. We describe design verification , a process of proving or refuting that a Java program (i.e. its native code) conforms to the Codechart specifying it. We also describe a toolkit which supports modeling and visualization with Codecharts, as well as a fully-automated design verification tool. We conclude with empirical results which suggest gains in both speed and accuracy when using Codecharts in software design, development and evolution.

This paper describes an analysis of some of the challenges facing one portion of the Electrical Smart Grid in the United States - residential Demand Response (DR) systems. The purposes of this paper are twofold: 1) to discover risks to residential DR systems and 2) to illustrate an architecture-based analysis approach to uncovering risks that span a collection of technical and social concerns. The results presented here are specific to residential DR but the approach is general and it could be applied to other systems within the Smart Grid and to other critical infrastructure domains. Our architecture-based analysis is different from most other approaches to analyzing complex systems in that it addresses multiple quality attributes simultaneously (e.g., performance, reliability, security, modifiability, usability, etc.) and it considers the architecture of a complex system from a socio-technical perspective where the actions of the people in the system are as important, from an analysis perspective, as the physical and computational elements of the system. This analysis can be done early in a system's lifetime, before substantial resources have been committed to its construction or procurement, and so it provides extremely cost-effective risk analysis.

The continuous evolution and unpredictability underlying service-based systems leads to difficulties in making exact QoS claims about the dependability of architectures interfacing with them. Hence, there is a growing need for new methods to evaluate the dependability of architectures interfacing with such environments. This paper presents a method for evaluating the security quality attribute of architectures in service-based systems. The proposed method combines some properties of the Architectural Tradeoff Analysis Method (ATAM) and security testing using Implied Scenario. In particular, the scenario elicitation process of ATAM is improved by utilising Implied Scenario technique to generate scenarios which may be undetected using plain ATAM. An industrial case study of a problem related to securing data at the Software-as-a-Service layer on Force.com Cloud platform is adopted to validate the new method. The results indicate that our method found four additional security scenarios beyond the plain ATAM, resulting in four new risks and two new tradeoff points.

In any IT-intensive organization, it is useful to have a model to associate a value with software and system architecture decisions. More generally, any effort---a project undertaken by a team---needs to have an associated value to offset its labor and capital costs. Unfortunately, it is extremely difficult to precisely evaluate the benefit of "architecture projects"---those that aim to improve one or more quality attributes of a system via a structural transformation without (generally) changing its behavior. We often resort to anecdotal and informal "hand-waving" arguments of risk reduction or increased developer productivity. These arguments are typically unsatisfying to the management of organizations accustomed to decision-making based on concrete metrics. This paper will discuss research done to address this long-standing dilemma. Specifically, we will present a model derived from analyzing actual projects undertaken at Vistaprint Corporation. The model presented is derived from an analysis of effort tracked against modifications to specific software components before and after a significant architectural transformation to the subsystem housing those components. In this paper, we will discuss the development, implementation, and iteration of the model and the results that we have obtained.

This paper presents an integrated service-oriented enterprise system development framework (called the BITAM-SOA Framework) as well as an instantiated design process model (called the Service Engineering Schematic) that was a result from a three-year action research case study with a Fortune 50 company in the financial services industry. The BITAM-SOA Framework and Schematic advance are both business-IT alignment and software architecture analysis techniques supporting the engineering of enterprise-wide service-oriented systems-that is, service engineering.

Service engineering, the application of engineering disciplines to develop service-oriented enterprise systems (service systems) with predicable results, has faced a brand new array of challenges in recent years. Existing development approaches that might help addressing these challenges are scattered in separate research fields or in different units of an organization, just like the "blind men and the elephant." This article presents a 3-year action research case study with a Fortune 50 company in the financial services industry, validating an integrated service-oriented business-IT alignment framework, called the BITAM-SOA Framework, to shed light on complex service engineering issues, including the interplay between business-IT alignment approaches (alignment via architecture, via governance and via communication) and Service Oriented Architecture adoption as well as methodological challenges of service engineering. The importance of the social dimension of service engineering is illuminated. The results yield lessons learned, managerial insights and integrated methods for effective service engineering.

Validation and verification are mandatory activities that software companies must perform when developing software products with a high degree of quality. Currently, more companies become aware that adopting CMMI (the software process maturity model developed by the Software Engineering Institute) can be a way to develop quality software. However, some companies are resistant to adopt CMMI maturity level 2 because they do not considerer this maturity level a benefit since its implementation is expensive and does not cover the validation and verification efforts. The simultaneous adoption of CMMI maturity level 2 with validation and verification process areas (from maturity level 3) lacks some methodological recommendations, since some dependencies exist between those two CMMI maturity levels. This PhD thesis will propose one approach to conciliate validation and verification practices with of CMMI maturity level 2 and by adopting ISO/IEC 29119 standard to fulfill a product lifecycle perspective.

An organization is architecturally competent if it has the ability to acquire, use and sustain the skills and knowledge necessary to carry out architecture-related practices that lead to systems that serve the organization's business goals. This paper presents some principles of architecture competence, based on four models that aid in explaining, measuring, and improving the architecture competence of an individual or an organization with respect to these principles, The principles are based on a set of fundamental beliefs about software architecture.

Over the past four years the University of Hawaii has been steadily moving towards an "active learning" approach to software engineering education by replacing passive slide-show lectures with a series of short lectures followed by in-class exercises, enabled though the use of wireless networked laptops. In this paper we report on our experiences and early results with this approach. The results suggest that students like this approach more, do better, and evaluate the courses more positively.

This paper outlines our experiences with making architectural tradeoffs between performance, availability, security, and usability, in light of stringent cost and time-to-market constraints, in an industrial web-conferencing system. We highlight the difficulties in anticipating future architectural requirements and tradeoffs and the value of using agility and experiments as a tool for mitigating architectural risks in situations when up front pen- and-paper analysis is simply impossible.

Much research in the software architecture field has focused on the purely technical aspects of architecting: architectural styles, documentation, analysis, architecture description languages, reverse engineering, and so forth. In this working session we seek to explore a less exhaustively studied, but equally important, realm: architectural competence. What defines a competent software architect? And equally important, what defines an architecturally competent software development organization? In particular, we seek to better understand the following issues: (a) What do architects actually do on a day-to-day basis? (b) What skills and knowledge must a competent architect have? (c) What does it mean to be a competent architect? (d) What can an organization do to get the best performance from its software architects? (e) How can we measure architectural competence of an individual or an organization and how can we increase this? Our goal for this working session is to propose an initial "theory" of architectural competence, even if very informally rendered, and then provide some practical guidance deriving from that theory to practicing architects (and to those who aspire to be architects), as well as technical managers in software development organizations.

This paper focuses on the human aspects of architecting software-in particular, the duties, skills, and knowledge of software architects. We present the results of a survey of approximately 200 public sources of information aimed at professional software architects that we conducted in the summer of 2006. We summarize what those sources have to say about the duties, skills, and knowledge that competent architects must perform and have.

This paper presents the 8th International Workshop on Economics-Driven Software Engineering Research (EDSER-8).

One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. In this paper, we describe a technique that uses runtime observations about an executing system to construct an architectural view of the system. In this technique, we develop mappings that exploit regularities in system implementation and architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations and are formally defined using Colored Petri Nets. In this paper, we describe a system, called DiscoTect, that uses these mappings and we introduce the DiscoSTEP mapping language and its formal definition. Two case studies showing the application of DiscoTect suggest that the tool is practical to apply to legacy systems and can dynamically verify conformance to a preexisting architectural specification.

Summary form only given. Architecture analysis and design methods such as ATAM, QAW, ADD and CBAM have enjoyed modest success in recent years and are being adopted by many companies as part of their standard software development processes. They are used in the software lifecycle, as a means of understanding business goals and stakeholder concerns, mapping these onto an architectural representation, and assessing the risks associated with this mapping. These methods have evolved a set of shared component techniques. In this article the author describes how these techniques can be combined in countless ways to create needs-specific methods. The author demonstrates the generality of these techniques by describing a new architecture improvement method called APTIA (analytic principles and tools for the improvement of architectures). APTIA almost entirely reuses pre-existing techniques but in a new combination, with new goals and results. Lastly, the author exemplifies APTIA's use in improving the architecture of a commercial information system.

One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. In this paper, we describe a technique that uses run time observations about an executing system to construct an architectural view of the system. With this technique, we develop mappings that exploit regularities in system implementation and architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations. We describe the current implementation of a tool that uses these mappings, and show that it can highlight inconsistencies between implementation and architecture.

As current virtual environments are less visually rich than real-world environments, careful consideration must be given to their design to ameliorate the lack of visual cues. One important design criterion in this respect is to make certain that adequate navigational cues are incorporated into complex virtual worlds. In this paper we show that adding 3D spatialized sound to a virtual environment can help people navigate through it. We conducted an experiment to determine if the incorporation of 3D sound (a) helps people find specific locations in the environment, and (b) influences the extent to which people acquire spatial knowledge about their environment. Our results show that the addition of 3D sound did reduce time taken to locate objects in a complex environment. However, the addition of sound did not increase the amount of spatial knowledge users were able to acquire. In fact, the addition of 3D auditory sound cues appears to suppress the development of overall spatial knowledge of the virtual environment.

The Second International Workshop on From SofTware Requirements to Architectures (STRAW'03) was held in Portland, Oregon, USA on 9 May 2003 just after the Twenty-Fifth International Conference on Software Engineering (ICSE'03). This brief paper outlines the motivation, goals, and organization of the workshop.

The terms architecture, design, and implementation are typically used informally in partitioning software specifications into three coarse strata of abstraction. Yet these strata are not well-defined in either research or practice, causing miscommunication and needless debate. To remedy this problem we formalize the Intension and the Locality criteria, which imply that the distinction between architecture, design, and implementation is qualitative and not merely quantitative. We demonstrate that architectural styles are intensional and non-local; that design patterns are intensional and local; and that implementations are extensional and local.

The First International Workshop on the Relationships between Software Engineering and Human-Computer Interaction was held on May 3-4, 2003 as part of the 2003 International Conference on Software Engineering, in Portland, OR, U.S.A. This workshop was motivated by a perception among researchers, practitioners, and educators that the fields of Human-Computer Interaction and Software Engineering were largely ignoring each other and that they needed to work together more closely and to understand each other better. This paper describes the motivation, goals, organization, and outputs of the workshop.

This paper outlines experiences with using economic criteria to make architecture design decisions. It briefly describes the CBAM (Cost Benefit Analysis Method) framework applied to estimate the value of architectural strategies in a NASA project, the ECS. This paper describes the practical difficulties and experiences in applying the method to a large realworld system. It concludes with some lessons learned from the experience.

In this paper we discuss a set of architecture-based methods for architecture design and analysis that have been developed over the past 10 years at the Software Engineering Institute. We then discuss the need for integrating these architecture-based methods, both with each other and into an organization's system development life cycle, based on experience with NASA's EOSDIS project. We discuss the framework for doing this integration, and present a life cycle view of architecture-based design and analysis methods.

No abstract available.

No abstract available.

The benefits of a software system are assessable only relative to the business goals the system has been developed to serve. In turn, these benefits result from interactions between the system's functionality and its quality attributes (such as performance, reliability and security). Its quality attributes are, in most cases, dictated by its architectural design decisions. Therefore, we argue that the software architecture is the crucial artifact to study in making design tradeoffs and in performing cost-benefit analyses. A substantial part of such an analysis is in determining the level of uncertainty with which we estimate both costs and benefits. We offer an architecture-centric approach to the economic modeling of software design decision making called CBAM (Cost Benefit Analysis Method), in which costs and benefits are traded off with system quality attributes. We present the CBAM, the early results from applying this method in a large-scale case study, and discuss the application of more sophisticated economic models to software decision making.

This tutorial will discuss, exemplify, and involve the students in the use of Attribute-Based Architectural Styles (ABASs)—architectural styles accompanied by explicit analysis reasoning frameworks—in both the design and analysis of software and system architectures. The tutorial has several objectives: to introduce the students to a catalog of ABASs covering performance, availability, testability, modifiability, and usability; to convince students that ABASs provide a basis for insightful reasoning about a software architecture's ability to meet its quality attribute goals; and to demonstrate the utility of ABASs by showing examples of how ABASs are used to design and analyze real-world system architectures. We will present some large excerpts from our growing ABAS handbook and show that ABASs help us in designing architectures efficiently and predictably and in quickly finding architectural risks and tradeoffs when doing analysis.

Article Experience with performing architecture tradeoff analysis Share on Authors: Rick Kazman Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Mario Barbacci Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Mark Klein Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , S. Jeromy Carrière Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile , Steven G. Woods Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PAView Profile Authors Info & Claims ICSE '99: Proceedings of the 21st international conference on Software engineeringMay 1999 Pages 54–63https://doi.org/10.1145/302405.302452Online:16 May 1999Publication History 103citation1,056DownloadsMetricsTotal Citations103Total Downloads1,056Last 12 Months16Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The article describes our view on the importance of exchanging not only system information in the reengineering community, but also exchanging a description of the semantics that underly the extraction, annotation and augmentation of the information one wishes to exchange. The semantics are more than the schema of the information exchanged. They include the rationale for the structure of the schema itself. We also make the point that we need to be explicit about what it means to reconstruct architecture, in terms of the architectural semantics that we are hypothesizing for the system being analyzed. We present the discussion in the context of a revised set of levels based on the CORUM II model.

This paper presents the Architecture Tradeoff Analysis Method (ATAM), a structured technique for understanding the tradeoffs inherent in the architectures of software-intensive systems. This method was developed to provide a principled way to evaluate a software architecture's fitness with respect to multiple competing quality attributes: modifiability, security, performance, availability, and so forth. These attributes interact-improving one often comes at the price of worsening one or more of the others-as is shown in the paper, and the method helps us to reason about architectural decisions that affect quality attribute interactions. The ATAM is a spiral model of design: one of postulating candidate architectures followed by analysis and risk mitigation, leading to refined architectures.

When performing architectural analysis on legacy software systems, it is frequently necessary to extract the architecture of the system, because it has not been documented, or because its documentation is out of date. However, architectural information does not exist directly in the artifacts that we can extract. The architecture exists in abstractions; compositions of extracted information. Thus, extracted artifacts must be able to be flexibly aggregated and combined. We call this process "view refinement and fusion". This paper presents a workbench for architectural extraction called Dali, and shows how Dali supports flexible extraction and fusion of architectural information. Its use is described through two extended examples of architectural reconstruction.

Multimedia information retrieval is a challenging problem because multimedia information is not inherently structured.Jabber is an experimental system that attempts to bring some structure to this task.Jabber allows users to retrieve records of videoconferences based upon the concepts discussed.In this paper we introduce ConceptFinder, a sub-system within Jabber, and show how it is able to process the spoken text of a meeting into meeting topics.Con-ceptFinder can make subtle distinctions among different senses of the same words, and is able to summarize a set of related words, giving a name to each topic.Users can then use this name to query or browse the stored multimedia, through Jabber's user interface.By presenting information that closely matches a user's expectations, the challenge of multimedia retrieval is rendered more tractable.

Building a system at the architectural level can be thought of as decomposition into components followed by a series of exercises in matching. Components must be composed with each other via matching mechanisms; matching signatures within those mechanisms ensures that data and control flows through the system; and matching semantics among the components ensures that the system meets its behavioral requirements. The standard concepts of software architecture (components, connectors, styles) have been widely used with little more than intuitive understanding of their meaning. Mechanism matching is currently an ad hoc exercise that relies on the peculiarities of programming language facilities. This paper presents a set of well-known but informally described software architectural elements used in system composition, and taxonomizes them under a basic set of characteristic features. This classification allows us to describe legal combinations of architectural elements by performing a simple matching exercise on the relevant features of the member elements. This classification also allows us to identify architectural elements that can be substituted for each other and satisfy the same mechanism matching requirements. This leads to delayed binding of architectural mechanisms, which in turns provides increased flexibility and greater opportunities for reuse of units of computation.

Three dimensional computer applications such as CAD packages are often difficult to use because of inadequate depth feedback to the user.It has, however, been shown that audio feedback can help improve a user's sense of depth perception.This paper describes an experiment which evaluates the use of three different audio environments in a 3D task undertakeh by visually impaired users.The three audio environments map tonal, musical, and orchestral sounds to an (x, y, z) position in a 3D environment.In each environment the user's task is to locate a target in three dimensions as accurately and quickly as possible.This experiment has three important results: that audio feedback improves performance in 3D applications for all users; that visually impaired users can use 3D applications with the accuracy of sighted users; and that visually impaired users can attain greater target accuracy than sighted users in a sound-only environment.

Virtual environments are often unsuitable for delicate operations because of the poverty of feedback, particularly tactile and force feedback.However, force feedback done properly requires large, heavy, expensive equipment.We have experimented with a particular form of tactile feedback using vibration as a substitute for force feedback.Substituting vibration for force feedback is intuitively appealing because it is cheap and low cost.But is it effective?Unfortunately, the answer is both "yes" and "no".We describe an experiment evahtating the effect of vibrotactile sensory substitution on user performance during a grasping task with delicate virtual objects.We found that adding vibrotactile feedback to visual and audio feedback improved task completion time for novice users, but led to increased grasp pressure over repeated uses of the system.