skip to content W3C SVG

Аттрибутивный дизайн

2019-09-11 14:51:12 +0600 +0600

Attribute-Driven Design (ADD)

Метод ADD - это подход к определению архитектуры программного обеспечения, в котором процесс проектирования основан на требованиях к качеству программного обеспечения. ADD следует за рекурсивным процессом, который разбивает систему или системный элемент, применяя архитектурная тактики и модели, которые удовлетворяют требованиям к атрибуту качества.

В основе данного метода лежит простой подход:

  • Планирование (На базе аттрибутов качества определяются архитектурные элементы )

  • Выполнение (Архитектурные элементы имплементируются для проверки аттрибутов качества)

  • Проверка (Проверяются результаты работы предыдущего пункта)

В англоязычных источниках метод называется: Plan, Do, Check

• Plan: Quality attributes and design constraints are considered to select which
types of elements will be used in the architecture.
• Do: Elements are instantiated to satisfy quality attribute requirements as well
as functional requirements.
• Check: The resulting design is analyzed to determine if the requirements are
met.

Описанный выше процесс выполняется до тех пор пока ASR http://architectvelichko.com/blog/asr/ будет достигнут.

Более детально механизм работы Attribute-Driven Design (ADD) видно на картинке.

Как видно из картинки выше аттрибуты качества, функциональные/нефункциональные требования, а также требования заказчика являются входным источником данных для механизма ADD. Более детальную информацию про функциональным и нефункциональным требованиям можно найти ССЫЛКА_________ТУТ

Результатом ADD является дизайн системы с точки зрения ролей, обязанностей, свойств и взаимосвязей между элементами программного обеспечения.

Проект, полученный в результате ADD, документируется с использованием различных типов архитектурных представлений (Architectural View). Документирования архитектуры будет рассмотрено в следующих статьях.

Далее по шагам

Шаг 1

На первом этапе вы подтверждаете, что имеется достаточно информации о требованиях для продолжения ADD. По сути, вы должны убедиться, что заинтересованные стороны системы расставили приоритеты в соответствии с целями бизнеса и задачами. Вы также должны подтвердить, что имеется достаточно информации о требованиях к качеству для продолжения.

Как архитектор, вы используете список требований с приоритетами, чтобы определить, на какие системные элементы нужно обратить внимание во время проектирования. Вы учитываете требования и их потенциальное влияние на структуру архитектуры в порядке убывания важности для заинтересованных сторон.

Требования, которые не были приоритезированы, должны быть помечены и возвращены заинтересованным сторонам для ранжирования.

Кроме того, вы должны определить, достаточно ли информации об атрибутах качества требований системы. Каждое требование к качеству должно быть выражается в форме «стимул-ответ». Каждое требование должно быть описано, как реакция измеряемого атрибута качества системы на конкретный стимул с указанием следующего: • источник стимула

• стимул

• артефакт

• среда

• ответ

• мера реагирования

Знание этой информации для каждого требования к качеству помогает архитектору выбрать различные шаблоны проектирования и тактику для достижения этих требований.

Шаг 2 Определение элементов подлежащих разбиению

На этом втором шаге вы выбираете, какой элемент системы будет фокусом проектирования на последующих шагах.

Достигнуть этого шага можно двумя способами.

  1. Вы впервые достигли шага 2 как часть разработки «с нуля». Единственный элемент, который вы можете разложить - это сама система. По умолчанию все требования собранны для этой системы.

  2. Вы дорабатываете частично спроектированную систему и уже посещали Шаг 2 ранее. В этом случае система была разделена на два или более элементов, и уже были собранны к этим элементам. Вы должны выбрать один из этих элементов, как фокус последующих шагов.

Во втором случае вы можете выбрать элемент для фокусировки на основе одной из этих областей:

  • Текущий вид архитектуры
  • Риск и сложность
  • Бизнес требования
  • Требования заказчика

Шаг 3 Определение бизнес драйверов

На данный момент вы выбрали элемент системы для декомпозиции, и заинтересованные стороны расставили приоритеты для любых требований, которые влияют на этот элемент. На этом этапе вы оцените эти же требования во второй раз, исходя из их относительного влияния на архитектуру. Влияние на архитектуру (architectural impact) может меть следующие значения:

  • high impact

  • medium impact

  • low impact

Таким образом каждому требованию присваиваются две оценки:

  1. Приоритет для заказчика

  2. Влияние (impact) на систему.

Приоритет также имеет значение в диапазоне (high medium low).

Обычно напротив каждого требования пишут что-то такое :

(H,H) (H,M) (H,L) (M,H) (M,M) (M,L) (L,H) (L,M) (L,L).

Первая буква показывает приоритет для заказчика, влияние на систему.

Обычно на первом проходе выбирают 5-6 наиболее важных (H,H)(H, M) требований для дальнейшего анализа.

Эти требования называют candidate architectural drivers

Надо указать, что в процессе исследования начальный список может измениться (какие-то из требований уйти, а какие-то будут добавлены)

Шаг 4 Выбрать концепции построения дизайна удовлетворяющие бизнес драйверы

На шаге 4 вы должны выбрать основные типы элементов, которые появятся в архитектуре и типы отношений между ними. Ограничения дизайна и требования к качеству атрибутов ( candidate architectural driver) используются для определения типов элементов и их отношений.

На шаге 4 Архитектор должен двигаться по списку

  1. Определить основные проблемы/сложности построения архитектуры связанные с бизнес драйвером.

  2. Для каждой проблемы проектирования создайте список альтернативных шаблонов, которые решают проблему. Каждый шаблон должен быть детально расписан:

    • Эстимация

    • Список параметров шаблона

    • Сложность исполнения

    • Чем отличается от альтернатив

  3. Выберите шаблоны из списка, которые вы считаете наиболее подходящими для удовлетворения вашего заданного требования. Запишите обоснование вашего выбора, чтобы решить, какие шаблоны подходят

Затем надо создать табличку как показано ниже :

В таблице нужно описать плюсы и минусы каждого шаблона.

Можно задуматься над следующими вопросами описывая плюсы и минусы:

  • Какие компромиссы ожидаются при использовании каждого шаблона?

  • Насколько хорошо модели сочетаются друг с другом?

  • Являются ли какие-либо шаблоны взаимоисключающими (т.е. вы можете использовать любой шаблон А или шаблон Б, но не оба)?

  • Существуют ли уже готовые технические имплементации шаблонов

  1. Соедините шаблоны в архитектурные шаблоны или архитекторские техники

  2. Опишите выбранные вами шаблоны, начав захватывать различные архитектурные представления.

Создание документации будет в отдельной статье.

  1. Оцените и устраните несоответствия в концепции проекта:

а. Оцените дизайн в сравнении с архитектурными драйверами. При необходимости используйте модели, эксперименты, симуляции, формальный анализ и архитектурные методы оценки.

б. Определите, есть ли какие-либо архитектурные драйверы, которые не были рассмотрены.

с. Оцените альтернативные модели или примените дополнительную тактику, если дизайн не удовлетворяет архитектурным драйверам.

д. Оцените дизайн текущего элемента по сравнению с дизайном других элементов в архитектуре и устраните любые несоответствия.

шаг 4 Выводы:

Концепция дизайна, которую вы приняли на шаге 4, приведет вас к принятию (или, по крайней мере, к рассмотрению) следующих дизайнерских решений:

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

  • Вы определили некоторые функции, связанные с различными типами элементов (например вы поняли что хартбит будет в каждом сервисе)

  • Вы определили модель взаимодействия между компонентами

  • вы определились с основными абстракциями проекта

Шаг 5 Создавать архитектурные элементы и Распределить обязанности

На этом шаге уже происходит реализация первых версий продукта. Критерием успешного выполнения 5 шага считается создание концептов всех элементов системы, чтобы адресовать все функциональные требования.

Алгоритм действий можно описать так:

  1. Создайте по одному инстансу продукта (сервиса или компонента), каждый инстанс должен удовлетворять одно требование

  2. Присвойте зоны ответственности каждому элементу

  3. Опишите связи элементов

  4. Опишите каналы связи между элементами

  5. Опишите слой данных

  6. Задайте себе вопрос масштабируемости

  7. Проанализируйте и задокументируйте результат шага 5.

Шаг 6 Определить интерфейсы для созданных элементов

На данном шаге необходимо задуматься о публичных интерфейсах. Данный шаг требует внимания так как является той частью системы которая наиболее бросается в глаза.

Обычно на этом этапе так же рассматривают такие вещи как:

  • синтаксис операций (например, подпись)

  • семантика операций (например, описание, предварительные и постусловия, ограничения)

  • обмен информацией (например, оповещение о событиях, глобальные данные)

  • обработка

Шаг 7 Проверка и уточнение требований на примере созданного архитектурного концепта

На данном этапе идут проверки. Тут важно убедится в том, что все аттрибуты адресованы.

Если все аттрибуты покрыты, то проверяем оставшиеся аттрибуты, которые не вошли в изначальный список. Нужно понять могут ли они быть покрыты текущей архитектурой. Если все хорошо, то результат конвертируют в дизайн проекта. Если ответ нет, то шаг 1-7 повторяют до момента пока не будет достигнут успех.

Документация и дизайн будут рассмотрены в других статьях.

ЧТО МОЖНО почитать
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2006_005_001_14795.pdf