No abstract

From its very inception, the study of software architecture has recognized architectural decay as a regularly occurring phenomenon in long-lived systems. Architectural decay is caused by repeated changes to a system during its lifespan. Despite decay's prevalence, there is a relative dearth of empirical data regarding the nature of architectural changes that may lead to decay, and of developers' understanding of those changes. In this paper, we take a step toward addressing that scarcity by conducting an empirical study of changes found in software architectures spanning several hundred versions of 14 opensource systems. Our study reveals several new findings regarding the frequency of architectural changes in software systems, the common points of departure in a system's architecture during maintenance and evolution, the difference between system-level and component-level architectural change, and the suitability of a system's implementation-level structure as a proxy for its architecture.Index Terms-software architecture, architectural change, software evolution, open-source systems, architecture recovery.

Over the past three decades, considerable effort has been devoted to the study of software architecture. A major portion of this effort has focused on the originally proposed view of four "C"s-components, connectors, configurations, and constraints-that are the building blocks of a system's architecture. Despite being simple and appealing, this view has proven to be incomplete and has required further elaboration. To that end, researchers have more recently tried to approach architectures from another important perspective-that of design decisions that yield a system's architecture. These more recent efforts have lacked a precise understanding of several key questions, however: (1) What is an architectural design decision (definition)?(2) How can architectural design decisions be found in existing systems (identification)? (3) What system decisions are and are not architectural (classification)? (4) How are architectural design decisions manifested in the code (reification)? (5) How can important architectural decisions be preserved and/or changed as desired (evolution)? This paper presents a technique targeted at answering these questions by analyzing information that is readily available about software systems. We applied our technique on over 100 different versions of two widely adopted opensource systems, and found that it can accurately uncover the architectural design decisions embodied in the systems.

No abstract

No abstract

When designing a software system, architects make a series of design decisions that directly impact the system's quality. The number of available design alternatives grows rapidly with system size, creating an enormous space of intertwined design concerns that renders manual exploration impractical. We present eQual, a model-driven technique for simulation-based assessment of architectural designs. While it is not possible to guarantee optimal decisions so early in the design process, eQual improves decision quality. eQual is effective in practice because it (1) limits the amount of information the architects have to provide and (2) adapts optimization algorithms to effectively explore massive spaces of design alternatives. We empirically demonstrate that eQual yields designs whose quality is comparable to a set of systems' known optimal designs. A user study shows that, compared to the state-of-the-art, engineers using eQual produce statistically significantly higherquality designs with a large effect size, are statistically significantly more confident in their designs, and find eQual easier to use. CCS CONCEPTS • Software and its engineering → Software design engineering; Software implementation planning.

No abstract

No abstract