Abstract: Enabling quick feature delivery is essential for product success and is therefore a goal of software architecture design. But how may we determine if and to what extent an architecture is “good enough” to support feature addition and modification, or determine if a refactoring effort is successful in that features may be added more easily? The applications may use Feature Space and Feature Dependency, derived from a software project's revision history that capture the dependency relations among the features of a system in a feature dependency structure matrix (FDSM), using features as first-class design elements. The applications may also use a Feature Decoupling Level (FDL) metric that may be used to measure the level of independence among features.

Abstract: Groups of architecturally connected files may incur and accumulate high maintenance costs as architectural debts. To quantify such debts, architectural debt, which is a term used herein, may be identified, quantified, measured, and modeled. A history coupling probability matrix for this purpose may search for architecture debts through the lens of 4 patterns of prototypical architectural flaws shown to correlate with reduced software quality. Further, a new architecture maintainability metric—Decoupling Level (DL)—measures how well the software can be decoupled into small and independently replaceable modules. The DL metric opens the possibility of quantitatively comparing maintainability between different projects, as well as monitoring architecture decay throughout software evolution.

Abstract: The method and system is called I-FAR: Interactive, Facet-based Architecture Recovery. Inspired by the idea that each system feature, pattern, or concern may have its own design space, the method defines a “facet” as a set of files that have one primary purpose, such as the implementation of a feature or the management of a cross-cutting concern such as performance, security, logging, etc.

Abstract: Enabling quick feature delivery is essential for product success and is therefore a goal of software architecture design. But how may we determine if and to what extent an architecture is “good enough” to support feature addition and modification, or determine if a refactoring effort is successful in that features may be added more easily? The applications may use Feature Space and Feature Dependency, derived from a software project's revision history that capture the dependency relations among the features of a system in a feature dependency structure matrix (FDSM), using features as first-class design elements. The applications may also use a Feature Decoupling Level (FDL) metric that may be used to measure the level of independence among features.

Abstract: Errors in software may be detected via the use of design rule spaces and architecture root detection. Design rule spaces may reveal multiple overlapping modular structures of a software system, and reveal structural relations among error-prone files and structural problems contributing to error-proneness. Root detection may extract a few groups of architecturally connected files, which may be connected through problematic architecture relations that propagate errors among these files, and thus influence system error-proneness. The root detector may locate the core architecturally connected file groups that contribute to the error-proneness of a system. The root detection process may, beginning with a set of error-prone files, search and link other files that are architecturally related. The output of the root detection process may be a set of design rule spaces ordered by the number of error-prone contained therein.

Abstract: Groups of architecturally connected files may incur and accumulate high maintenance costs as architectural debts. To quantify such debts, architectural debt, which is a term used herein, may be identified, quantified, measured, and modeled. A history coupling probability matrix for this purpose may search for architecture debts through the lens of 4 patterns of prototypical architectural flaws shown to correlate with reduced software quality. Further, a new architecture maintainability metric—Decoupling Level (DL)—measures how well the software can be decoupled into small and independently replaceable modules. The DL metric opens the possibility of quantitatively comparing maintainability between different projects, as well as monitoring architecture decay throughout software evolution.

Abstract: Errors in software may be detected via the use of design rule spaces and architecture root detection. Design rule spaces may reveal multiple overlapping modular structures of a software system, and reveal structural relations among error-prone files and structural problems contributing to error-proneness. Root detection may extract a few groups of architecturally connected files, which may be connected through problematic architecture relations that propagate errors among these files, and thus influence system error-proneness. The root detector may locate the core architecturally connected file groups that contribute to the error-proneness of a system. The root detection process may, beginning with a set of error-prone files, search and link other files that are architecturally related. The output of the root detection process may be a set of design rule spaces ordered by the number of error-prone contained therein.

Abstract: A binary augmented constraint network (BACN) allows dependency relationships to be determined without solving constraints. BACN models design decisions as first-class members and expresses how decisions make assumptions upon each other using logical constraints. Pairwise dependency relations (PWDRs) are determined based on the BACN. A design rule hierarchy (DRH) based on assumption relations among design decisions identifies parallelizable tasks within software design. Modules within the same layer of the hierarchy suggest concurrent tasks. Dependencies between layers or within a module suggest possible need for communication. In one configuration, decisions within the top layer of the hierarchy are the most influential design rules, which dominate the rest of the system, and are kept stable. The decisions within subsequent layers assume design decisions in previous layers. The design decisions within each layer are clustered into modules.