Uncovering Architectural Design Decisions

TL;DR

This paper introduces a technique to identify and analyze architectural design decisions in software systems, addressing gaps in understanding how decisions are made, represented, and evolve over time.

Contribution

It provides a systematic method for uncovering architectural decisions from existing systems, enhancing understanding of their role and evolution.

Findings

Successfully applied to over 100 system versions

Accurately uncovers embedded architectural decisions

Helps in understanding decision impact and system evolution

Abstract

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 open- source systems, and found that it can accurately uncover the architectural design decisions embodied in the systems.