skip to content W3C SVG

ATAM:SM Method for Architecture Evaluation

2018-08-29 12:52:36 +0600 +0600

This is meta description

ATAM:SM Method for Architecture Evaluation - Способы сравнения архитектуры

Если программная архитектура является ключевым бизнес-активом для организации, тогда архитектурный анализ также должна быть ключевой практикой для этой организации. Зачем? Потому что архитектура сложна и вовлекает много компромиссов дизайна. Без проведения формального процесса анализа организация не может обеспечить принятие архитектурных решений, особенно тех, которые влияют на достижение таких качественных атрибутов, как производительность, доступность, безопасность и модифицируемость, - это те, которые надлежащим образом снижают риски.

В этой статье я хочу рассказать алгоритм анализа архитектурного решения АТАМ.

Для чего нужен ATAM?

ATAM позволяет оценить последствия принятых архитектурных решений в контексте Функциональных и нефункциональных требований.

Если говорить более точно то ATAM позволяет оценить наше архитектурное решение на наличие рисков и зон с возможными рисками.

ATAM имеет несколько свойств и признаков, которые необходимо особо выделить:

  • ATAM можно выполнить на раннем этапе жизненного цикла разработки программного обеспечения.

  • ATAM делается быстро и дешево так как оценивает артефакты архитектуры, а не имплементации

  • ATAM анализ зависит от детализации архитектуры

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

Этот последний пункт имеет решающее значение для понимания целей ATAM; мы не пытаемся точно предсказать поведение атрибутов качества. Это было бы невозможно на ранней стадии проектирования. ATAM создан не для измирений, а для выявления рисков, чувствительных зон, конкурирующих мест(risks, sensitivity points, and tradeoff points ) .

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

Точки чувствительности - это параметры в архитектуре, с которыми некоторые измеримые характеристики атрибута качества сильно коррелируют. Пример если убрать blue-green builds , то availability (Доступность) может снизится.

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

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

Очень часто требования и дизайн решения бывают расплывчатыми и не однозначными. Важно перед началом ATAM максимально детализировать требования и дизайн.

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

https://tools.adidas-group.com/bitbucket/projects/PIM/repos/ods-rds-terraform/pull-requests/68/diff

  • На какие стимулы должна реагировать архитектура?

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

  • Какие ключевые архитектурные решения влияют на выполнение требования атрибута?

АТАМ по шагам

Я постараюсь очень кратко по шагам расписать как оно должно работать в теории. На практике все шаги применяются редко.

Часть 1 - знакомство

  1. Рассказать про АТАМ (можно пересказать то что описано выше.) заинтересованным сторонам (обычно представители заказчика, архитекторы или архитекторы, представители пользователей, сопровождающие, администраторы, менеджеры, тестировщики, интеграторы и т. д.).

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

  3. Архитектор опишет предложенную архитектуру, сосредоточив внимание на том, как его архитектура относится к бизнес-драйверам и как решает бизнес цели и задачи.

Часть 2 - Исследования и анализ

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

  2. Создать quality attribute utility tree (будет рассказано ниже) - Факторы качества, которые составляют «полезность» системы (производительность, доступность, безопасность, модифицируемость и т. д.), с указанием вплоть до сценариев, помеченных стимулами и ответами, и расставленных по приоритетам. Тут главное нарисовать граф в главном узле которого находится слово “utility”, а от главного узла отходят узлы в которых описаны основные Требования и сценарии. А рядом, справа, описаны основные стратегии, применения этих стратегий позволяет достичь заданного атрибута. См. картинку ниже

  3. Анализ архитектурных подходов. Основываясь на приоритетных факторах, определенных в пункте 2, архитектурные подходы, которые учитывают эти факторы, выявляются и анализируются (например, архитектурный подход, направленный на достижение целей производительности, будет подвергнут анализу производительности). На этом этапе архитектурные риски, точки чувствительности, и точки обмена определены.

Часть 3 - Тестирование

  1. Мозговой штурм и расстановка приоритетов. На основе сценариев, и архитектурных подходов сгенерированных в параграфе 3. раздела Исследования и анализ. Тут главное получить более широкий набор сценариев от всех заинтересованных сторон. (Пишем еще сценарии тестирования для покрытия утилитного дерева)

  2. Анализировать архитектурные подходы. Этот шаг повторяет шаг 3. раздела Исследования и анализ, но здесь сценарии из предыдущего пункта считаются тестовыми примерами для анализа архитектурны определенной до сих пор до сих пор. Эти сценарии тестирования могут раскрыть дополнительные архитектурные подходы, риски, точки чувствительности и компромиссы, которые затем документируются.

Часть 3 - Отчет

  1. На основе информации, собранной в ATAM (стили, сценарии, специфичные для атрибута вопросы, дерево утилит, риски, точки чувствительности, компромиссы) ATAM Команда представляет результаты собравшимся заинтересованным сторонам и потенциально пишет отчет детализация этой информации вместе с любыми предлагаемыми стратегиями смягчения.

Опять же выше было много сказано про атрибуты качества (quality attribute) и про сценарии. Просто для того что бы все были в одном контексте.

Aтрибуты качества (quality attribute) - это то свойство системы которое точно можно измерить и протестировать.

Сценарий это последовательность действий выполняемая системой, в результате какого-то стимула, результат и/или ход выполнения которого можно протестировать или измерить.


Деревья утилит обеспечивают нисходящий механизм для прямого и эффективного перевода бизнеса драйверы системы в конкретные сценарии качества атрибута. Например, в электронной коммерции Систему два из бизнес-драйверов можно сформулировать так:
«безопасность является основой успеха системы, поскольку обеспечение конфиденциальности данных наших клиентов имеет первостепенное значение »;
и «модифицируемость имеет решающее значение для успеха системы, так как мы должны быть в состоянии быстро реагировать на быстро развивающийся и очень конкурентный рынок ».
Прежде чем мы сможем оценить архитектуру, эти системные цели должны быть более конкретными. Более того, нам нужно понять относительную важность этих целей по сравнению с другими целями качества атрибута, таких как производительность, чтобы определить, где мы должны сосредоточить наше внимание во время оценки архитектуры. Деревья утилит помогают конкретизировать и расставить приоритеты для целей качества. Примером служебного дерева является показано на рисунке выше.

На самом деле все выше описанное не так уж и сложно. Ниже показана картинка, которая объясняет все проще

Картинку читаем сверху вниз и слева на право:

  1. Берем бизнес драйверы и архитектуру на вход.

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

  3. Получаем сценарии и решения принятые архитектором .

  4. Анализируем пункты 1,2,3.

  5. Получаем риски, trade off, чувствительные места.

  6. Делаем отчет.

  7. Полученный отчет превращем в пункт номер 1 и повторяем процедуру.

Спасибо за длинное чтиво.

не нажимайте на ссылку ниже.

https://www.youtube.com/watch?v=YG8jcViTAyU

продолжение следует…

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