Architecture Report

Circular dependency among 7 components: Antipattern <-> Clustering <-> Default <-> Facts <-> Metrics <-> Topics <-> Util

Why: Dependency cycles make components tightly coupled — you cannot change, test, or deploy any component in the cycle independently. This hinders maintainability, increases build times, and makes the system harder to understand.

Fix: Break the cycle by introducing an interface/abstraction that one component depends on, inverting the dependency direction. Consider the Dependency Inversion Principle (DIP).

Affects: Antipattern, Clustering, Default, Facts, Metrics, Topics, Util

The Default component mixes unrelated responsibilities: graph structures (BipartiteGraph, Vertex), clustering metrics (MoJo, MoJoCalculator), configuration (Config), smell analysis (MergeInterfaceBasedSmell2Issues), and utilities (StringUtil, Cluster).

Why: Having entities in a default/unnamed package indicates poor organization. This component lacks conceptual cohesion—developers must understand disparate concepts (graph theory, metrics, smell detection) to work with it. Changes to any one concern risk breaking unrelated functionality. The vague responsibility 'Entities in (default)' confirms no clear architectural purpose.

Fix: Dissolve this component. Move MoJo* classes to Metrics, BipartiteGraph/Vertex to a dedicated graph package or Functiongraph, Config to a configuration package, MergeInterfaceBasedSmell2Issues to Antipattern, and StringUtil to Util. Eliminate the default package entirely.

Affects: Default

The Clustering component contains 44 entities spanning multiple sub-concerns: clustering algorithms (ACDC, ClusterMatcher), file I/O (RSFOutput, TAInput, RsfToDot), serialization/stopping criteria (8 criterion classes), architecture representations (Architecture, ReadOnlyArchitecture), and graph utilities (Edge, Node, SubGraph).

Why: This is the largest component in the system, violating the Single Responsibility Principle. Developers working on clustering algorithms must navigate I/O code and vice versa. Testing becomes difficult as test fixtures must cover diverse functionality. The component has 6 dependencies, suggesting it's doing too much. Evolution is risky—adding a new file format requires changes in a component primarily about clustering logic.

Fix: Split into focused subcomponents: clustering.algorithms (ACDC, ClusterMatcher, pattern matching), clustering.io (RsfToDot, RSFOutput, TAInput), clustering.criteria (all Criterion classes), and clustering.models (Architecture, Cluster, FeatureVectors). Keep only core algorithm orchestration in the top-level Clustering component.

Affects: Clustering

The Facts component contains 33 entities with fundamentally different purposes: source code parsers (CSourceToDepsBuilder, JavaSourceToDepsBuilder), file format readers (RsfReader, ODEMReader, MakeDepReader, UnderstandCsvToRsf), version control integration (Commit, VersionTree, GitLabRestHandler), issue tracking (JiraImporter, IssueRecord, IssueComment), and decision analysis (DecisionAnalyzer, DecisionRankingEngine).

Why: This component conflates data acquisition (parsing, reading), external system integration (Git, Jira), and architectural analysis (decision ranking). Changes to Jira integration could break dependency parsing. The component depends on 6 other components (Antipattern, Clustering, Functiongraph, Json, Util, Util2), indicating it's a hub doing too much. New developers cannot understand 'Facts' without understanding 5+ distinct domains.

Fix: Refactor into focused components: facts.parsers (all *ToDepsBuilder, *Reader classes), facts.vcs (Commit, VersionTree, Git* classes), facts.issues (Jira*, IssueRecord, IssueComment), facts.analysis (DecisionAnalyzer, ChangeAnalyzer, RecovArEngine), and facts.core (DependencyGraph, Change). Each subcomponent should have a single reason to change.

Affects: Facts