Дизайн, основанный на атрибутах

Attribute-driven design ^{[1] [2]} (также называемый ADD или Attribute-driven design method) — это методология создания программных архитектур, которая учитывает качественные атрибуты программного обеспечения. Ранее он был известен как Architecture Based Design Method (или ABD), но из-за проблем с товарными знаками название было изменено на Attribute-driven design около 2001 года. ^[3]

В книге «Архитектура программного обеспечения на практике» ^[4] авторы описывают ADD как итеративный метод, который на каждой итерации помогает архитектору выполнять следующие шаги:

• Выберите часть системы для проектирования.
• Упорядочить все архитектурно значимые требования к выбранной части. Это означает, что вы выбираете все атрибуты качества и бизнес-цели, которые могут повлиять на архитектуру этой фазы.
• Создайте архитектуру для выбранной части, которая соответствует выбранным архитектурно значимым требованиям, и протестируйте эту конструкцию.

Успешное начало ADD возможно только при наличии следующих ресурсов:

• функциональные требования
• требования к качеству
• ограничения

Конечно, мы не можем ждать, пока все эти требования будут окончательно определены, поскольку это может занять некоторое время. Процесс ADD может начаться, как только будет доступен набор ASR (архитектурно значимых требований, которые представляют собой три ресурса, перечисленных выше).

1. Выберите элемент системы для проектирования
   • Выберите элемент системы, который еще не разработан. В первой итерации это будет сама система. Позже нужно будет сделать выбор между несколькими элементами. Этот выбор может быть основан на доступности персонала, доступности входных ресурсов, смягчении рисков и т. д. Если у вас нет ни одного из этих ограничений, предлагается использовать стратегию «в ширину».
2. Определите архитектурно значимые требования (ASR) для выбранного элемента
   • Определите ASR, которые наиболее важны для этого выбранного элемента. Вам следует расставить приоритеты этих требований, чтобы убедиться, что ваш дизайн отражает наиболее важные ASR.
3. Сгенерировать проектное решение для выбранного элемента
   • Этот шаг является сердцем ADD, поскольку архитектура будет создана на этом шаге. Создаваемая вами архитектура должна отражать выбранные ASR. Вы можете сделать это, используя архитектурные шаблоны или тактики. В большинстве случаев вам придется делать компромисс между несколькими тактиками и ASR.
4. Оставшиеся требования к инвентаризации и выбор входных данных для следующей итерации
   • Взгляните на перечисленные ASR и посмотрите, выполнены ли они уже с вашим текущим дизайном. Для каждого ASR вам придется проверить, выполнен ли он, делегирован ли он одному из дочерних элементов, распределен между дочерними элементами или не может быть выполнен. В последнем случае вам нужно будет изменить архитектуру.
5. Повторяйте шаги 1–4, пока все ASR не будут удовлетворены.
   • Повторить!

Набор эскизов архитектурных видов, а не полноценная подробная архитектура.

В последние годы ADD был существенно обновлен, чтобы включить в него проектирование, специфичное для платформы, например, выбор технологий и фреймворков через каталоги концепций дизайна, а также подчеркнуть принятие и документирование архитектурных решений . ^[5]