Книжный куб

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part I (Рубрика #Architecture)

Вчера перед сном прочитал интересный whitepaper про процесс SAR (Software Architecture Recovery) при помощи LLMs. Мне идея показалась интересной, чтобы кратко рассказать про нее.

1) Стандартный подход к Software Architecture Recovery обычно работал снизу-вверх (bottom-up). Условно, некоторый анализатор кода запускался строил архитектурные метрики, которые как-то характеризовали архитектуру проекта (что-то в духе кейсов из книги "Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture", про которую я уже рассказывал)
2) В этом paper исследователи решили пойти сверху-вниз (top-down) и начать с задания референсной архитектуры, а дальше уже классифицировать части кода как относящиеся к той или иной части этой референсной архитектуры. Это позволяет не просто собрать текущее состояние архитектуры как было в стандартном подходе, а оценить расхождение между референсной архитектурой проекта и тем, что у нас есть на самом деле:)
3) Авторы говорят о том, что этот подход больше похож на то, как работают software engineers, так как обычно инженеры знают какая базовая архитектура в проекте, поэтому могут использовать эти знания при изучении кода

Дальнейшее описание процесса в следующем посте, а в приложении к этому основные иллюстрации с описанием процесса, описанием индикаторов компонентов архитектуры, а также промптом для LLM, который используется в классификации.

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

www.tgoop.com/book_cube/3044

2.1K viewsAlexander Polomodov, edited  Jan 28 at 06:09

Deductive Software Architecture Recovery via Chain-of-thought Prompting - Part I (Рубрика #Architecture)

Вчера перед сном прочитал интересный whitepaper про процесс SAR (Software Architecture Recovery) при помощи LLMs. Мне идея показалась интересной, чтобы кратко рассказать про нее.

1) Стандартный подход к Software Architecture Recovery обычно работал снизу-вверх (bottom-up). Условно, некоторый анализатор кода запускался строил архитектурные метрики, которые как-то характеризовали архитектуру проекта (что-то в духе кейсов из книги "Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture", про которую я уже рассказывал)
2) В этом paper исследователи решили пойти сверху-вниз (top-down) и начать с задания референсной архитектуры, а дальше уже классифицировать части кода как относящиеся к той или иной части этой референсной архитектуры. Это позволяет не просто собрать текущее состояние архитектуры как было в стандартном подходе, а оценить расхождение между референсной архитектурой проекта и тем, что у нас есть на самом деле:)
3) Авторы говорят о том, что этот подход больше похож на то, как работают software engineers, так как обычно инженеры знают какая базовая архитектура в проекте, поэтому могут использовать эти знания при изучении кода

Дальнейшее описание процесса в следующем посте, а в приложении к этому основные иллюстрации с описанием процесса, описанием индикаторов компонентов архитектуры, а также промптом для LLM, который используется в классификации.

#Architecture #Software #Metrics #LLM #AI #ML #Engineering #RnD

BY Книжный куб