Deductive Software Architecture Recovery via Chain-of-thought Prompting
Разбор дедуктивного подхода SAR с LLM: reference architecture, индикаторы компонентов и рекурсивная классификация кода с оценкой расхождения от целевой архитектуры.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Whitepaper
Deductive Software Architecture Recovery via Chain-of-thought Prompting (2024)
Работа про top-down SAR с применением LLM-классификации.
Whitepaper
Deductive Software Architecture Recovery via Chain-of-thought Prompting (2024)
Работа про top-down SAR с применением LLM-классификации.
В рубрике #Architecture подход показан как попытка перенести инженерную дедукцию в процесс SAR: сначала зафиксировать целевую архитектуру, затем системно проверить, как код ей соответствует на уровне методов, классов и модулей.
Основа главы: Part I
Telegram пост #3044
Идея top-down SAR и отличие от классического bottom-up подхода.
Основа главы: Part I
Telegram пост #3044
Идея top-down SAR и отличие от классического bottom-up подхода.
TL;DR
- Классический SAR чаще строится bottom-up: сначала метрики и зависимости кода, затем попытка восстановить архитектурную картину.
- В paper предложен дедуктивный top-down подход: сначала задаётся reference architecture, потом код классифицируется по её компонентам.
- Это позволяет измерять не только «что есть сейчас», но и разрыв между целевой архитектурой и фактической реализацией.
- Авторы тестируют подход на K-9 Mail и получают baseline precision/recall 72% и 71%.
Bottom-up vs Top-down в SAR
Bottom-up SAR (классический подход)
- Старт с анализа кода, метрик, зависимостей и графов вызовов.
- Фокус на текущем состоянии системы без жёсткой привязки к целевой архитектуре.
- Результат полезен для картирования проекта, но хуже отвечает на вопрос «где архитектурный drift».
Deductive top-down SAR (подход paper)
- Сначала фиксируется референсная архитектура и её компоненты.
- Кодовые единицы классифицируются на соответствие компонентам по индикаторам.
- Итогом становится карта соответствия и расхождений между intended architecture и реальным кодом.
Phase 1. Reference architecture definition
1. Select reference architecture
Выбирается архитектурный шаблон (например, layered architecture, MVC, MVVM, Onion).
2. Define architectural components
Фиксируются компоненты референсной архитектуры, к которым позже будет относиться код.
3. Define component and interaction indicators
Для каждого компонента задаются текстовые индикаторы ответственности и правил взаимодействия.
Пример индикаторов для presentation layer
- Pr1: метод задаёт атрибуты UI-компонентов (например, текст поля/виджета).
- Pr2: метод подписывает/уведомляет слушатели пользовательских событий.
- Pr3: метод преобразует domain-объекты в визуальное представление.
Основа главы: Part II
Telegram пост #3045
Разбор шагов классификации и результатов PoC на K-9 Mail.
Основа главы: Part II
Telegram пост #3045
Разбор шагов классификации и результатов PoC на K-9 Mail.
Phase 2. Code unit classification
4. Evaluate code units against indicators
LLM получает код + индикаторы и возвращает бинарную оценку соответствия по каждому индикатору.
5. Aggregate classified code units
Классификация агрегируется по уровням (method -> class -> namespace -> module) и повторяется рекурсивно.
Важная деталь: фаза работает рекурсивно снизу вверх. Сначала классифицируются методы, затем результаты агрегируются в классы, потом в namespaces/packages и выше до нужного архитектурного уровня.
Prompt skeleton для классификации
In a layered software architecture, one of the layers is the (layer_name) layer, which (layer_responsibility).
Consider the context of an Android Java project "(project_name)":
(project_domain_description)
Here are some indicators that a Java method in the project may belong to a class in the (layer_name) layer:
(layer_indicators)
The class "(class_name)" contains the method "(method_name)":
(method_source_code)
Check whether this method satisfies each indicator above.
Mention specific lines that support your reason.
At the very last line, write boolean verdicts separated by commas.
If indeterminate, write "false".Результаты PoC на K-9 Mail
72%
Precision
Насколько часто отнесённые к компоненту элементы действительно относятся к нему.
71%
Recall
Какую долю релевантных элементов метод смог корректно найти.
- Подход ближе к реальной инженерной практике, где команда обычно знает базовую архитектурную модель системы.
- Качество результата сильно зависит от формулировки индикаторов: расплывчатые правила ведут к нестабильной классификации.
- Рекурсивная агрегация позволяет подниматься к нужному уровню абстракции, но требует аккуратного контроля ошибок на нижних уровнях.
- Метод полезен как инструмент архитектурной диагностики, а не как полностью автономный «архитектурный судья».
Что авторы предлагают улучшать дальше
Расширение набора референсных архитектур и индикаторов под разные домены.
Полевые исследования в компаниях, чтобы проверить переносимость метода на production-кодовые базы.
Улучшение точности/полноты за счёт refinement prompt strategy и richer project context.
Связанные главы
Prompt Pattern Sequence for Architecture Decision-making
Структурированный подход к применению LLM в архитектурных решениях.
Quality Metrics in Software Architecture
Систематизация архитектурных метрик и ограничения metric-only подходов.
QA-guided Architecture Re-Design at Google
Как quality attributes используются в реальном процессе архитектурного редизайна.