tgoop.com/book_cube/3035
Last Update:
Teaching Software Architecture Design - Building Intuition - Part I (Рубрика #Architecture)
Прочитал недавно интересный whitepaper про обучение архитектуре от Gaurav Agerwala, Len Bass. Заинтересовался я этой статьей из-за ее автора - Len Bass, который является соавтором классической книги "Software Architecture in Practice" и преподает в Carnegie Mellon University. И могу отметить, что я не был разочарован - подход авторов к обучению чем-то напоминает тот процесс system design interview, что мы практикуем у себя в компании:) Кстати, описание подхода есть на Github
Ну а теперь давайте перейдем к самой статье.
Исследователи в статье рассказывают о своем методе и структуре курса, который ставит себе целью демистифицировать процесс проектирования софта и помочь студентам думать аналитически, одновременно развивая интуицию, о компромиссных решениях, принимаемых на этапе проектирования. Но начинается все с введения, где авторы вспоминают про разные процессы проектирования
- ACDM (Architecure Centric Design Method) - итеративный подход из середины двухтысячных к проектированию софта, который ставит проектирование в центр процессов разработки. Подробнее можно почитать здесь
- ADD (Attribute Driven Design) - системная методология из начала двухтысячных для проектирования софта, которая фокусируется на внедрении и приоритизации атрибутов качества (quality attributes) одновременно с функциональными требованиями. Цель в том, чтобы создать эффективную архитектуру, которая будет удовлетворять как функциональные, так и нефункциональные требования.
К обоим подходам имел отношение Len Bass, но для студентов он решил сделать процесс SADM (Software Architecture Design Method), который доступен на GitHub и который фокусируется на ключевых активностях по идентификации и анализу верхнеуровнего дизайна на основе требований. В этом он похож на ADD, но он менее формален и фокусируется на том, чтобы помочь студентам наработать интуицию. Здесь фокус скорее не на отдельных шагах сложного процесса, а на практике в дизайне сложных систем, где много неизвестных. Сама суть метода SADM в том, чтобы дать дизайнером инструмент для работы с этими неизвестными. SADM - это метод для декомпозиции системы или компонета, который выглядит так
- У нас на входе есть требования
- Мы строим контекстную диаграмму
- Дальше выбираем scope для декомпозиции
- Предлагаем гипотезу того, как можно сделать декомпозицию
- Проверяем, что при этом мы удовлетворяем функциональные требования (сценарии)
- Проверяем, что при этом удовлетворяем атрибуты качества (кстати, в Github репозитории есть презентации про такие атрибуты как availability, performance, observability, security, modifiability, integrability)
- Если у нас есть неизвестные моменты, то мы заносим их в таблицу с process steps, чтобы разобраться с ними позже
Такая декомпозиция идет пока мы не декомпозировали систему на части так, чтобы закрыть все требования.
А теперь немного про process steps, куда мы переместили моменты, по которым требовалась дополнительная работа. Собственно, там могут быть 3 активности
- Отложенные решения - это решения, что мы отложили до появления новой информации. Например, использовать DBaaS решение или разворачивать самому кастомную технологию. Это решение может принимать после некоторого количества итерацаций SADM процесса
- Исследовательские активности - возможно требуется дополнительный сбор информации и поиск по внешним источникам, например, варианты подключаемых устройств к умному дому при дизайне IoT системы
- Активности по тестированию - некоторые решения стоит принимать после построения прототипа и проверки гипотез на нем.
Продолжение разбора статьи в следующем посте.
#Architecture #Software #Engineering #SelfDevelopment
BY Книжный куб
Share with your friend now:
tgoop.com/book_cube/3035