Scenario-Based Software Architecture Evaluation Software Architecture Evaluation Methods: An Overview
Введение
Анализ разработки программного обеспечения и его оценка стали устоявшейся практикой среди проектировщиков ПО. Исследовательские группы предлагают различные методы для оценки качества архитектуры ПО. Ниже приведен список доступных сегодня методов, поддерживающих анализ атрибутов качества ПО:
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