Teaching Software Architecture Design - Building Intuition
Разбор подхода SADM от Len Bass: как тренировать архитектурную интуицию через декомпозицию, проверку гипотез и опровержимую аргументацию.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Whitepaper
Teaching Software Architecture Design - Building Intuition
Публикация ACM SIGCSE 2024 от Gaurav Agerwala и Len Bass.
Whitepaper
Teaching Software Architecture Design - Building Intuition
Публикация ACM SIGCSE 2024 от Gaurav Agerwala и Len Bass.
Paper предлагает учебный процесс, который делает архитектурное проектирование более прозрачным для студентов. Центральная идея: развивать инженерную интуицию через последовательную декомпозицию, проверку гипотез и аргументацию компромиссов.
Основа главы
Часть 1/2
Контекст статьи, SADM-процесс декомпозиции и работа с неизвестными через process steps.
Часть 2/2
Defeasible argumentation, критические вопросы и практики анализа гипотез по требованиям.
SADM on GitHub
Описание метода, презентации по quality attributes и дополнительные материалы курса.
SADM Description (PDF)
Краткое описание структуры метода и его учебного применения.
Контекст: от ACDM и ADD к SADM
Середина 2000-х
ACDM
Architecture Centric Design Method: итеративный подход, где архитектурное проектирование встроено в общий lifecycle разработки.
Начало 2000-х
ADD
Attribute Driven Design: методология, где архитектурные решения проверяются одновременно по функциональным требованиям и quality attributes.
Учебный формат
SADM
Software Architecture Design Method: более легковесный процесс для студентов, ориентированный на практику декомпозиции и аргументации решений в условиях неопределенности.
Цикл SADM для декомпозиции
Шаг 1
Взять требования как вход в дизайн-цикл.
Шаг 2
Построить контекстную диаграмму системы.
Шаг 3
Выбрать scope для текущей декомпозиции.
Шаг 4
Сформулировать гипотезу декомпозиции.
Шаг 5
Проверить гипотезу на функциональные сценарии (use cases).
Шаг 6
Проверить гипотезу на атрибуты качества (availability, performance, security и др.).
Шаг 7
Неясные моменты перенести в таблицу process steps.
Шаг 8
Повторять цикл до покрытия требований и стабилизации архитектурного решения.
Process Steps: что делать с неизвестными
Отложенные решения
Варианты, которые рано фиксировать без дополнительных данных. Например, выбор DBaaS против self-hosted решения.
Исследовательские активности
Сбор недостающей информации из внешних источников и ограничений домена (например, экосистема устройств в IoT-кейсе).
Активности по тестированию
Проверка архитектурных гипотез через прототипы и эксперименты до финальной фиксации решения.
Defeasible argumentation в архитектурном дизайне
Авторы учат студентов работать с опровержимой аргументацией: решения валидны, пока поддерживаются текущими данными. При изменении контекста дизайн-гипотезы должны пересматриваться, а не защищаться любой ценой.
- Аргумент принимается, если он обоснован доступными на текущий момент данными.
- Любой аргумент может быть пересмотрен при появлении новой информации.
- Новые данные могут опровергнуть исходные предпосылки и потребовать redesign.
- В инженерной практике эту логику удобно фиксировать через RFC и ADR артефакты.
Критические вопросы к дизайн-гипотезам
1) Анализ use cases
- Какие исключения в сценарии делают вклад предложенной декомпозиции недействительным?
- Есть ли побочные эффекты архитектуры, мешающие шагам use case?
- Нарушает ли решение другие требования системы (другие use cases или quality attributes)?
- Не нарушаются ли ограничения системы в основном сценарии и его исключениях?
2) Анализ атрибутов качества
- Можно ли показать, что решение соответствует известному архитектурному паттерну или reference architecture?
- Есть ли в предложенном дизайне другие паттерны, ухудшающие целевой quality attribute?
- Не мешает ли выбранный паттерн удовлетворению других требований системы?
- Какие контрпримеры или ограничения ослабляют текущий аргумент?
Практические выводы для инженеров
- Тренируйте архитектуру как цикл гипотез и проверок, а не как линейный «документ в конце».
- Явно отделяйте факты от предположений: все неизвестные переносите в process steps backlog.
- Учите команды формулировать аргументы и контраргументы по use cases и quality attributes.
- Фиксируйте решения в ADR и периодически пересматривайте их при изменении контекста.
Связанные главы
A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google
Практический кейс применения quality-attribute подхода в редизайне большой production-системы.
Using Architectural Kata in Software Architecture Course
Опыт обучения архитектуре через kata-формат и регулярную аргументацию решений.
A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making
Современный взгляд на структурированную поддержку архитектурных решений.