Architector Framework Overview

• Architector Framework is an automated system that reconstructs Java architectures by formalizing dependencies and aligning source code with layered conceptual models.
• The framework employs search-based heuristics, including greedy clustering and hill-climbing, to optimize fitness metrics and reduce architectural violations.
• Architector supports precise source-level refactorings such as MoveMethod, MoveConstant, and ExcludeParameter to systematically reverse architectural erosion.

The Architector Framework is an automatic system for software architecture reconstruction and source code refactoring, aimed at mitigating or reversing architectural erosion in non-trivial Java systems. By formally modeling conceptual software architecture, extracting dependency structures, and supporting a set of source-level migration operations, Architector enables the alignment of physical system architecture with a desirable layered conceptual model. Its prototype implementation demonstrates the use of clustering, hill-climbing, and search-based source transformation to reconstruct and realign software architectures, facilitating the reduction of architectural violations and preservation of maintainability, testability, and development velocity (Schmidt et al., 2014).

1. Formal Definition of Conceptual Architecture

Architector models a system’s architecture as a tuple $A = (I, L, \mu, \prec)$ where $I = \{i_1, \ldots, i_n\}$ is the set of implementation units (Java classes, interfaces, modules), $L = \{L_1, ..., L_k\}$ is an ordered set of architectural layers, $\mu : I \to L$ assigns each implementation unit to exactly one layer, and $\prec$ orders the layers.

A set of static dependencies $\operatorname{Dep} \subseteq I \times I$ (including method calls, field accesses, inheritance, parameter passing) is extracted from the source code. A conceptual architecture is one in which the following property holds ideally: for all $(i, j) \in \operatorname{Dep}$, either $\mu(i)\prec\mu(j)$ or $\mu(i)=\mu(j)$, i.e., dependencies do not point from a lower to a higher layer.

Internally, architectures are represented as directed, layered graphs $G = (I, E)$ with edge weights $w(i, j)$ set to $CBO(i, j)$—the count of distinct dependencies from $i$ to $j$. Architector’s metamodel is a domain-specific EMF-style metamodel with Layer and ImplementationUnit classes, a dependsOn reference, and a layerIndex attribute. For visualization and validation, UML component diagrams and JHotDraw-based node-link views (swimlane layouts) are exported.

2. Algorithms for Architecture Reconstruction

Architector performs architecture reconstruction using a three-stage, search-based heuristic process:

(1) Parsing & Dependency Extraction: Java source is parsed using RECODER to build an abstract syntax tree (AST) and extract dependencies with counts (calls, accesses, etc.). $CBO(i,j)$ is computed for coupling quantification.

(2) Initial Greedy Clustering: Starting with $k=2$ layers (increasing up to $k=3$ as warranted), implementation units are greedily assigned to layers to maximize local cohesion and minimize inter-layer coupling.

(3) Steepest-Ascent Hill-Climbing: Single units are iteratively moved between layers to optimize a global fitness function (described below) until no single move yields improvement.

The framework employs the following metrics:

• Cohesion: $$C(G) = \frac{1}{|G|^2} \sum_{i,j \in G} \operatorname{dependence}(i,j)$$, where $G \subseteq I$.
• Coupling: $$X(G,H) = \sum_{i \in G} \sum_{j \in H} \operatorname{dependence}(i,j)$$ for $G, H \subseteq I$.
• Solution Quality (SQ):

$SQ(\mu) = \frac{|L|}{1 + \text{CouplingWeighted}}$

with violations partitioned into resolvable ($V_1$) and unresolvable ($V_2$), and

$$\text{CouplingWeighted} = \sum_{(i,j)\in \operatorname{Dep},\ \mu(i)\not\preceq\mu(j)} \begin{cases} 0.25 \cdot CBO(i,j), & \text{if } (i,j)\in V_1\ 2.0 \cdot CBO(i,j), & \text{otherwise} \end{cases}$$

Higher $SQ$ indicates fewer/less severe violations and more layers.

The reconstruction algorithm can be summarized as:

function reconstructArchitecture(I, Dep): bestμ ← greedyInitial(I, Dep) bestScore ← SQ(bestμ) improved ← true while improved: improved ← false for each i in I, for each layer ℓ' ≠ bestμ(i): μ' ← bestμ with μ'(i)=ℓ' score' ← SQ(μ') if score' > bestScore: bestμ ← μ'; bestScore ← score'; improved ← true break return (bestμ, bestScore)

3. Source Code Refactoring and Migration

Architector supports three atomic source-level transformations, defined for classes $C, C'$, method $M$, and parameter $p$:

1. MoveMethod$(M: \text{Method}, C \to C')$: Relocates $M$ from $C$ to $C'$ if preconditions (no name conflict, only statics/parameters referenced) are met. All call sites and related imports/qualifiers are updated.
2. MoveConstant$(k: \text{Constant}, C \to C')$: Semantics and constraints are analogous to MoveMethod.
3. ExcludeParameter$(p: \text{parameter of } M)$: Removes $p$ from $M$ if not essential to API and relocates statements using $p$ to call sites or applies observer patterns.

Refactoring is orchestrated as an iterative search: for each generation, all single-step refactoring variants are produced, their violation counts and SQs are calculated, and the variant with minimal violations (or, on tie, maximal SQ) is selected. This process repeats until no further improvement is possible or a generation budget is exhausted.

The primary cost is:

$$V(\mu) = |\{(i, j) \in \operatorname{Dep_{phys}} : \mu(i) \not\prec \mu(j)\}|$$

with secondary cost $-\!SQ(\mu)$. Optimization proceeds as greedy steepest descent on the $(V, -SQ)$ cost vector.

4. Framework Structure and Operational Workflow

Architector consists of the following high-level modules:

1. Parser & Dependency Analyzer: Reads all Java sources, constructs the AST, and extracts the dependency graph with $CBO$ weights.
2. Conceptual Reconstruction Engine: Performs clustering and hill-climbing to generate the reflexion model $(I, L, \mu, \operatorname{Dep})$.
3. Refactoring/Migration Engine: Applies supported refactorings and evaluates the resulting code variants.
4. User Interface: Provides visualization of layers, implementation units, and violation statistics; user controls enable freezing assignments or adjusting layer counts.

The operational workflow is as follows:

1. The user specifies a Java project root.
2. All source files are scanned; the dependency graph is constructed.
3. Reconstruction yields the initial layered model, $\mu_0$.
4. The UI displays proposed layers and violations; user may intervene.
5. The migration engine enumerates and applies single refactorings.
6. Each variant is re-analyzed; violation counts and $SQ$ recomputed.
7. The best variant is chosen for the next generation; steps (5)–(7) are repeated.
8. Output is the refactored source tree with architecture aligned as closely as possible to the conceptual model.

5. Empirical Assessment and Case Studies

Architector’s evaluation utilized controlled experiments with a 15-class Java MVC system (5 Model, 5 View, 5 Controller). The system’s ideal SQ (perfect 3-layered architecture, no erosion) is 0.66185. Erosion was modeled by injecting $N=1...11$ violations (e.g., misplaced methods, parameters, constants) across runs. Observed trends are summarized:

N	Layers	Misplaced Units	Detected Violations	SQ
1	3	0	1	0.64835
3	3	1	2	0.55833
6	3	2	4	0.42652
11	2	5	8	0.52345

SQ degrades with growing erosion, though reconstructions preserve meaningful groupings (Model/View/Controller) until maximal deterioration causes reduction to two layers. In source code migration experiments with the most eroded instance (10 violations, fixed at 2 layers), violations were reduced rapidly within three to four generational refining steps (from 10 to 3 violations). SQ fluctuates but overall improves with successive generations.

6. Illustrative Example on a Java Mini-System

A minimal User system with classes UserController, UserModel, and UserView is mapped as:

• Layer₁: {UserController} (Controllers)
• Layer₂: {UserModel, DbConnector} (Models)
• Layer₃: {UserView} (Views)

With only legal dependencies (Controller → Model/View, Model → DbConnector), Architector’s clustering reconstructs the intended layering in one step; no violations. If a violation is introduced (e.g., UserModel invoking UserView.render), this unity is detected as a lower-to-higher dependency violation.

Refactoring options are proposed:

• Move audit method from UserModel to UserController
• Exclude parameter and inject via Controller
• Move render from UserView to UserModel (semantically undesirable)

Architector’s refactoring engine moves the offending method, eliminating violations and improving solution quality. The final structure exhibits only directional dependencies respecting the conceptual architecture; violations are reduced to zero, and the architecture is realigned.

---

This comprehensive exposition details Architector’s mathematical model, reconstruction and refactoring processes, the system’s modular composition and workflow, empirical evaluation results, and an end-to-end Java example, as delineated in (Schmidt et al., 2014).