Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

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

ATAM был разработан Институтом программной инженерии Университета Карнеги-Меллона . Его цель - помочь выбрать подходящую архитектуру для программной системы, обнаружив компромиссы и точки чувствительности.

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

Преимущества ATAM [ править ]

Ниже приведены некоторые из преимуществ процесса ATAM: [1]

  • выявленные риски на ранней стадии жизненного цикла
  • усиление взаимодействия между заинтересованными сторонами
  • уточнены требования к атрибутам качества
  • улучшенная архитектурная документация
  • документированная основа для архитектурных решений

Процесс ATAM [ править ]

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

Этапы процесса ATAM [ править ]

ATAM формально состоит из девяти шагов, описанных ниже: [2]

  1. Представить ATAM - представить концепцию ATAM заинтересованным сторонам и ответить на любые вопросы о процессе.
  2. Существующие бизнес-драйверы - каждый участник процесса представляет и оценивает бизнес-драйверы для рассматриваемой системы.
  3. Представьте архитектуру - архитектор представляет команде архитектуру высокого уровня с «соответствующим уровнем детализации».
  4. Определите архитектурные подходы - команда представляет и обсуждает различные архитектурные подходы к системе.
  5. Сгенерируйте служебное дерево атрибутов качества - определите основные бизнес-требования и технические требования к системе и сопоставьте их с соответствующим архитектурным свойством. Представьте сценарий для данного требования.
  6. Анализируйте архитектурные подходы - анализируйте каждый сценарий, оценивая их по приоритетности. Затем архитектура оценивается по каждому сценарию.
  7. Проведите мозговой штурм и определите приоритеты сценариев - среди более широкой группы заинтересованных сторон, представьте текущие сценарии и расширьте их.
  8. Анализируйте архитектурные подходы - повторите шаг 6 еще раз с дополнительными знаниями более широкого сообщества заинтересованных сторон.
  9. Представьте результаты - предоставьте всю документацию заинтересованным сторонам.

Эти шаги разделены на две фазы: Этап 1 состоит из шагов 1-6, и после этого этапа становятся известны состояние и контекст проекта, основные архитектурные требования и состояние архитектурной документации. Этап 2 состоит из шагов 7–9 и завершает оценку [3]

См. Также [ править ]

Ссылки [ править ]

  1. ^ "Метод анализа компромисса архитектуры" . Институт программной инженерии Карнеги-Меллона . Проверено 20 апреля 2018 .
  2. ^ Бас, Лен ; Клементс, Пол; Казман, Рик (9 апреля 2003 г.). Архитектура программного обеспечения на практике, второе издание . Эддисон Уэсли Профессионал.[ требуется страница ]
  3. ^ Rick Kazman; Марк Кляйн; Пол Клементс. «ATAM: Метод оценки архитектуры» (PDF) . Институт программной инженерии Карнеги-Меллона. п. 39f . Проверено 20 апреля 2018 .

Внешние ссылки [ править ]