Scenario-Based Software Architecture Evaluation Software Architecture Evaluation Methods: An Overview
Оригинал: Mugurel T. Ionita, Dieter K. Hammer, Henk Obbink
http://www.win.tue.nl/oas/architecting/aimes/papers/Scenario-Based%20SWA%20Evaluation%20Methods.pdf
Введение
Анализ разработки программного обеспечения и его оценка стали устоявшейся практикой среди проектировщиков ПО. Исследовательские группы предлагают различные методы для оценки качества архитектуры ПО. Ниже приведен список доступных сегодня методов, поддерживающих анализ атрибутов качества ПО:
- SAAM, Software Architecture Analysis Method
- ATAM, Architecture Trade-off Analysis Method
- CBAM, Cost Benefit Analysis Method
- ALMA, Architecture Level Modifiability Analysis
- FAAM, Family - Architecture Analysis Method
Software Architecture Analysis Method(SAAM)
SAAM - первый широко распространенный метод анализа архитектуры ПО.Изначально SAAM создавался для оценки модифицируемости, но позже был расширен для анализа архитектуры относительно показателей качества, таких как модифицируемость, портируемость, расширяемость, интегрируемость и функциональный охват.
Шаги в SAAM:
- Разработка сценариев: Определение типов деятельности, которые система должна поддерживать. Основная трудность при разработке сценариев заключается в определении основных видов применения, пользователей, атрибутов качества и наиболее важное - всех предполагаемых будущих изменений в системе.
- Описание архитектур(ы): SAAM представляет кандидатов архитектур(ы)
- Классификация и расстановка приоритетов сценариев: На этом этапе анализа сценарии классифицируются на прямые и косвенные. Прямой сценарий поддерживается кандидатом архитектуры. Косвенный сценарий - последовательность событий, при которой реализация архитектуры должна перенести изменения. Приоритет сценариев основан на процедуре голосования, результаты голосования будут представлять собой набор косвенных сценариев, которые считаются наиболее вероятны.
- Индивидуальная оценка косвенных сценариев: В случае косвенного сценария SAAM описывает, как архитектура должны быть изменена, чтобы соответствовать сценарию. Для каждого косвенного сценария должны быть определены архитектурные изменения, необходимые для облегчения этого сценария вместе с затронутыми компонентами новой системы и усилиями по осуществлению этих изменений.
- Оценка взаимодействия сценариев: Когда два или более сценариев хотят изменить одни и те же компоненты архитектуры, затронутые компоненты должны быть изменены или разделены на подкомпоненты, чтобы избежать взаимодействия различных сценариев.
- Создание общей оценки: Наконец, каждому сценарию присваивается вес с точки зрения их относительной важности для успеха системы. На основе этого взвешивания может быть предложен общий рейтинг, если сравниваются несколько архитектур.
Роли в SAAM:
- Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО. Их роль заключается в представлении бизнес-целей проекта, обеспечении атрибутов качества системы и представлении прямых и косвенных сценариев вместе с их приоритетами и классификацией.
- Внутренние заинтересованные стороны играют роль анализа, определения и представления архитектурных концепций.
- Команда SAAM проводит сеанс оценки SAAM. Состоит из оценщиков, экспертов в предметной области приложения, внешних экспертов (необязательно), и секретаря.
Architecture Trade-off Analysis Method(ATAM)
Метод анализа архитектурных компромиссов (ATAM). ATAM – это доработанная и улучшенная версия SAAM, которая позволяет пересматривать архитектурные решения относительно требований параметров качества и того, насколько хорошо эти решения отвечают конкретным целевым показателям качества.
Шаги в ATAM:
- Фаза презентации:
- Презентация ATAM
- Представление бизнес двигателей
- Представление архитектуры
- Фаза исследования и анализа:
- Определение архитектурных подходов
- Создание вспомогательного дерева атрибутов качества: Атрибуты качества, которые составляют систему “полезности”, выявляются и разносятся на разные уровни дерева.
- Анализ архитектурных подходов: На основе приоритетных сценариев, определенных на предыдущем этапе, архитектурные подходы, которые соответствуют этим сценариям, выявляются и анализируются.
- Фаза тестирования:
- Мозговой штурм и расставление приоритетов сценариев: Команда ATAM вместе с заинтересованными сторонами расставляют приоритеты сценариям путем голосования.
- Повторный анализ архитектурных подходов
- Фаза отчетности:
- Презентация результатов: Задокументированные архитектурные стили, окончательный набор сценариев и их приоритетов, риски, точки чувствительности. Однако ATAM не предлагает способы решения вышеуказанных выводов.
Роли в ATAM:
- Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
- Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры. Их роль заключается в анализе, определение и реализации архитектуры.
- Команда ATAM должна быть внешней по отношению к команде разработчиков по причинам нейтральности. Она приглашается, чтобы провести оценивание.
Cost Benefit Analysis Method(CBAM)
Метод анализа рентабельности (Cost Benefit Analysis Method, CBAM). Метод CBAM основное внимание уделяет анализу затрат, выгод и планированию последствий архитектурных решений.
Шаги в CBAM:
- Выберите сценарии и связанные с ними стратегии в области архитектуры
- Оценка качества и атрибутов
- Количественная оценка преимуществ каждого архитектурного стиля
- Подсчет стоимости каждого архитектурного стиля и расчет времени на его внедрение
- Вычисление “желания” внедрения каждого архитектурного стиля
- Принятие решения
Роли в CBAM:
- Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
- Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры.
- Команда CBAM не имеет прямого отношения к выбору архитектуры ПО, но проводит CBAM сессию.
Architecture Level Modifiability Analysis(ALMA)
Анализ модифицируемости на уровне архитектуры (Architecture Level Modifiability Analysis, ALMA). ALMA оценивает модифицируемость архитектуры для систем бизнес-аналитики.
Шаги в ALMA:
- Установите цель анализа
- Опишите архитектуру ПО
- Выявите сценарии, которые могут влиять на модифицируемость архитектуры
- Оцените сценарии из предыдущего пункта
- Интерпретируйте результаты: полученные результаты используются для прогнозирования затрат на техническое обслуживание.
Роли в ALMA:
- Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
- Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры.
- Команда ALMA не имеет прямого отношения к выбору архитектуры ПО, но их приглашают для проведения оценки.
Family - Architecture Analysis Method(FAAM)
Метод оценки семейства архитектур (Family Architecture Assessment Method, FAAM). FAAM оценивает архитектуры семейства информационных систем с точки зрения возможности взаимодействия и расширяемости.
Шаги в FAAM:
- Определите цель оценки
- Установите объем и содержание системы-семьи
- Установить будущие планы для семьи (интероперабельности,а также изменения растяжимости)
- Предоставьте указания заинтересованным сторонам, чтобы помочь им генерировать требования
- Подготовка требований к системе качества
- Подготовьте архитектуру
- Обзор артефактов
- Проверка архитектуры на соответствие установленным в пункте 2 требованиям с акцентом на легкость интеграции
- Отчет об итогах и предложения
Роли в FAAM:
- Внешние заинтересованные стороны не принимают участия в процессе разработки архитектуры ПО, их роль заключается в представлении бизнес контекста проекта.
- Внутренние заинтересованные стороны принимают непосредственное участие в процессе разработки ПО архитектуры.
- Команда FAAM не имеет прямого отношения к выбору архитектуры ПО, но их приглашают для проведения оценки.
Таблица сравнения различных методов анализа архитектуры ПО
Метод | Оценка Качества | Метрика | Описание процесса | Сильные стороны | Слабые стороны | Типы систем, к которым применим |
---|---|---|---|---|---|---|
SAAM | Модифицируемость | Классификация сценариев | Разумное | Определение потенциальных областей высокой сложности Открыт для любого архитектурного описания | Нет явной метрики качества Не отображает шаги | Все |
ATAM | Модифицируемость | Точки чувствительности Компромисные точки Поддерживается ATA | Хорошее | Генерация сценариев основана на требованиях Применим для статических и динамических свойств Вспомогательное дерево качества | Требует глубоких технических знаний | Все |
CBAM | Затраты и выгоды | Время и затраты | Разумное | Предоставляет бизнес измерения для определенных изменений системы Вносит ясность в неопределенность, связанную с оценками | Определение цен и выгоды может быть сделано участниками в открытой форме | Все |
ALMA | Модифицируемость | Влияние оценки Модифицируемость предсказываемой модели | Разумное | Критерий остановки генерации сценариев | Ограниченное множество случаев изучения Концентрируется на статических свойствах | Бизнес информационные системы |
FAAM | Совместимость и расширяемость | Различные специализированные таблицы и диаграммы | Очень хорошее | Акцент на расширении прав и возможностей команд | Доказан только в определенной среде Концентрируется на статических свойствах | Системы-семьи |
Список литературы
- Paul Clements, Rick Kazman and Mark Klein
- Evaluating Software Architectures: Methods and Case Studies, Addison Wesley, 2002. ATAM: Method for architecture evaluation”: ATAM - Architecture Trade-off Analysis Method report