- •Часть 1. Планирование архитектуры
- •Заключение
- •Дополнительная литература
- •4.10. Дискуссионные вопросы
- •Глава 8. Моделирование условий полета. Конкретный пример архитектуры, ориентированной на интегрируемость
- •8.4. Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 9. Документирование программной архитектуры
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 10. Реконструкция программной архитектуры
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 6. Управление воздушным движением. Пример разработки, ориентированной на высокую готовность
- •Глава 7. Проектирование архитектуры
- •Глава 11. Метод анализа компромиссных архитектурных
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 12. Метод анализа стоимости и эффективности — количественный подход к принятию
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 13. Всемирная паутина. Конкретный пример реализации способности к взаимодействию 374
- •Глава 14. Линейки программных продуктов.
- •Заключение
- •Дополнительная литература
- •Глава 15. CelsiusTech. Конкретный пример разработки
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Заключение
- •Часть 1. Планирование архитектуры
- •Часть 2. Создание архитектуры
- •Часть 3. Анализ архитектуры
- •Часть 4. От одной системы к множеству
- •Часть 1
- •Глава 1
- •1.1. Откуда берутся варианты архитектуры?
- •1.2. Программный процесс и архитектурно-экономический цикл
- •1.3. Из чего складывается «качественная» архитектура?
- •1.4. Заключение
- •1.5. Дискуссионные вопросы
- •Глава 2
- •2.1. Чем является программная архитектура и чем она не является
- •2.2. Другие взгляды на архитектуру
- •2.3. Архитектурные образцы, эталонные модели и эталонные варианты архитектуры
- •2.4. Почему программная архитектура так важна?
- •2.5. Архитектурные структуры и представления
- •2.6. Заключение
- •2.7. Дополнительная литература
- •2.8. Дискуссионные вопросы
- •Глава 3
- •3.1. Связь с архитектурно-экономическим циклом
- •3.2. Требования и атрибуты качества
- •3.3. Архитектура авиационной электронной системы а-7е
- •3.4. Заключение
- •3.5. Дополнительная литература
- •3.6. Дискуссионные вопросы
- •Часть 2
- •Глава 4
- •4.1. Функциональность и архитектура
- •4.2. Архитектура и атрибуты качества
- •4.3. Атрибуты качества системы
- •4.4. Практическое применение сценариев атрибутов качества
- •4.5. Другие атрибуты качества системы
- •4.6. Коммерческие атрибуты качества
- •4.7. Атрибуты качества архитектуры
- •4.8. Заключение
- •4.9. Дополнительная литература
- •4.10. Дискуссионные вопросы
- •Глава 5
- •5.1. Определение тактики
- •5.2 Тактики реализации готовности
- •5.3. Тактики реализации модифицируемости
- •5.4. Тактики реализации производительности
- •5.5. Тактики реализации безопасности
- •5.6. Тактики реализации контролепригодности
- •5.7. Тактики реализации практичности
- •5.8. Взаимосвязь тактик и архитектурных образцов
- •5.9. Архитектурные образцы и стили
- •5.10. Заключение
- •5.11. Дополнительная литература
- •5.12. Дискуссионные вопросы
- •Глава 6
- •6.1. Связь с архитектурно-экономическим циклом
- •6.2. Требования и атрибуты качества
- •6.3. Архитектурное решение
- •6.4. Заключение
- •6.5. Дополнительная литература
- •6.6. Дискуссионные вопросы
- •Глава 7
- •7. 1. Архитектура в контексте жизненного цикла
- •7.2. Проектирование архитектуры
- •1. Выбор модуля для декомпозиции
- •2А. Выбор архитектурных мотивов
- •2Ь. Выбор архитектурного образца
- •2D. Задание интерфейсов дочерних модулей
- •7.3. Формирование рабочих групп
- •7.5. Заключение
- •7.6. Дополнительная литература
- •7.7. Дискуссионные вопросы
- •Глава 8
- •8.1 Связь с архитектурно- экономическим циклом
- •8.2. Требования и атрибуты качества
- •8.3. Архитектурное решение
- •8.2 Заключение
- •8.5 Дополнительная литература
- •8.6. Дискуссионные вопросы
- •Глава 9
- •9.1. Варианты применения архитектурной документации
- •9.2. Представления
- •9.3 Выбор значимых представлений
- •9.4. Документирование представления
- •9.5. Перекрестная документация
- •9.6. Унифицированный язык Моделирования
- •9.7. Заключение
- •9.8. Дополнительная литература
- •9.9. Дискуссионные вопросы
- •Глава 10
- •10.1. Введение
- •10.2. Извлечение информации
- •10.3. Создание базы данных
- •10.4. Объединение представлений
- •10.5. Реконструкция
- •10.6. Пример
- •10.7. Заключение
- •10.8. Дополнительная литература
- •10.9. Дискуссионные вопросы
- •Часть 3
- •Глава 11
- •Результаты проведения оценки по методу атам
- •Этапы atam
- •1 Источник: приводится по изданию [Clements 02а] (адаптированная версия).
- •11.4. Система Nightingale: конкретный пример проведения оценки по методу атам
- •11.5. Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 12
- •Результаты оценки по методу свам
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 13
- •13.1. Отношение к архитектурноэкономическому циклу
- •13.4. Еще одна итерация архитектурноэкономического цикла: эволюция вариантов веб-архитектуры систем электронной коммерции
- •13.7. Заключение
- •13.8. Дополнительная литература
- •13.9. Дискуссионные вопросы
- •Часть 4
- •Глава 14
- •За счет чего работают линейки программных продуктов?
- •Варианты архитектуры линеек продуктов
- •Факторы, усложняющие применение линеек программных продуктов
- •Заключение
- •Дополнительная литература
- •Дискуссионный вопрос
- •Глава 15
- •Связь с архитектурноэкономическим циклом
- •Требования и атрибуты качества
- •Архитектурное решение
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 16
- •Связь с архитектурноэкономическим циклом
- •16.3. Архитектурное решение
- •16.4. Решения по размещению системы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 17
- •17.2. Требования и атрибуты качества
- •17.3. Архитектурное решение
- •17.4. Механизм реализации атрибутов качества в архитектуре Luther
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 18
- •18.1. Воздействие компонентов на архитектуру
- •18.2. Архитектурное несоответствие
- •18.3. Компонентное проектирование как поиск
- •18.4. Пример приложения aseilm
- •18.5. Заключение
- •18.6. Дополнительная литература
- •Глава 19
- •19.1. Снова архитектурноэкономический цикл
- •19.2. Создание архитектуры
- •19.3. Архитектура в рамках жизненного цикла
- •Влияние коммерческих компонентов
- •Заключение
- •8 Все перечисленные специалисты работают в корпорации Inmedius (Питтсбург, сша).
Глава 11
Метод анализа компромиссных архитектурных решений — комплексный подход к оценке архитектуры
(в соавторстве с Марком Кляйном)
06 услугах, которые нам оказывают другие люди, мы судим по тому, насколько существенными они кажутся им, а на действительную их ценность как-то не обращаем внимания.
Фридрих Нище
Настоящая глава представляет собой обзор метода анализа компромиссных архитектурных решений (Architecture Tradeoff Analysis Method, АТАМ) — комплексной универсальной методики оценки программной архитектуры. В соответствии со своим названием этот метод обнаруживает степень реализации в архитектуре тех или иных задач по качеству, а также (исходя из допущения о том, что любое архитектурное решение влияет сразу на несколько задач по качеству) механизм их взаимодействия — другими словами, их взаимозаменяемость.
Оценить архитектуру крупной системы весьма не просто. Во-первых, чем больше система, тем масштабнее ее архитектура и тем протяженнее промежуток времени, за который о ней можно составить некое представление. Во-вторых, согласно Ницше (см. эпиграф) и архитектурно-экономическому циклу (Architecture Business Cycle, ABC), любая компьютерная система призвана решать коммерческие задачи; таким образом, и ходе оценки необходимо устанавливать связи между этими задачами и техническими решениями. Наконец, крупные системы, как правило, характеризуются многочисленностью заинтересованных лиц, а для того чтобы за ограниченный промежуток времени проанализировать их позиции, процесс оценки ш'обходпмо внимательно контролировать. Итак, из всего вышесказанного понят
но, что основной проблемой в контексте оценки архитектуры является ограниченность по времени.
Основное назначение АТАМ состоит в том, чтобы выявить коммерческие задачи, поставленные в контексте разработки системы и проектирования архитектуры. Вкупе с участием заинтересованных лиц это помогает специалистам по оценке сфокусироваться на тех элементах архитектуры, которые играют первостепенную роль для реализации упомянутых задач.
В этой главе мы перечислим этапы АТАМ и рассмотрим их с функциональной точки зрения. Для иллюстрации теоретического материала мы также приведем конкретный пример употребления АТАМ, основанный на нашем собственном опыте.
Участники АТАМ
Ниже перечислены группы специалистов, участие и сотрудничество которых является необходимым условием проведения процесса АТАМ.
Группа оценки. Специалисты из этой группы не должны участвовать в разработке оцениваемой архитектуры. Как правило, численность группы составляет 3-5 человек. Каждому из них назначается ряд ролей, которые он должен исполнять в период оценки. (Описание этих ролей, а также желательные характеристики каждой из них приводятся в табл. 11.1.) В некоторых случаях группа оценки являет собой постоянное подразделение, регулярно проводящее действия по оценке вариантов архитектуры; в иных ситуациях ее участники подбираются из числа специалистов с серьезными знаниями в области архитектуры для выполнения конкретной задачи. Иногда группы оценки и разработки набираются из сотрудников одной компании, однако не исключается вариант заказа оценки у третьей стороны. В любом случае это должны быть компетентные, объективные люди без предубеждений и корыстных целей.
Лица, ответственные за проект. Полномочия участников этой группы позволяют им выполнять для проекта представительские функции и принимать решения о внесении в него изменений. Как правило, в их число входят руководитель проекта, а также (при наличии такового) заказчик, финансирующий разработку. Кроме того, речь идет об архитекторе — ведь, согласно основному принципу оценки архитектуры, архитектор должен принимать в этом процессе самое деятельное участие. Наконец, одним из представителей проекта обычно является специалист, ответственный за проведение оценки; даже если ои не наделеи такими полномочиями, участие его в рассматриваемой группе обязательно.
Заинтересованные в архитектуре лица. Заинтересованным лицам, естественно, хочется, чтобы архитектура не отклонялась от проекта. Способность этих людей выполнять свои задачи напрямую зависит от того, в какой степени архитектура реализует модифицируемость, безопасность, высокую надежность и прочие атрибуты качества. В число заинтересованных лиц входят разработчики, тестировщики, сборщики, специалисты по сопровождению, инженеры по эффективности, пользователи, конструкторы систем, взаимодействующих с рассматриваемой системой, и многие другие. В ходе оценки от них требуется сформулировать конкретные задачи по реализации атрибутов качества, при выполнении которых систему можно будет признать удачной. Нормальным следует считать участие в процессе оценки 12-15 заинтересованных лиц.
Таблица
11.1.
Распределение ролей между участниками
группы оценки
Роль
Обязанности
Предпочтительные
характеристики
Руководитель
Планирует
оценку; общается
Организованность,
группы
с
заказчиком и гарантирует
управленческие
способности,
выполнение
его требований; утверждает
навыки
ведения переговоров
договор
о проведении оценки; набирает
с
заказчиком, выполнение
специалистов
в группуоценки;
обязанностей
в установленные
координирует
составление и предоставление
заказчикусводного отчета (обязанности
по его составлению можно делегировать)
сроки
Руководитель
Ответствен
за проведение оценки;
Способность
выступать перед
специалистов
содействует
выявлению сценариев;
аудиторией;
развитые навыки
по
оценке
координирует
отбор сценариев и их
содействия;
компетентность
классификацию
согласно приоритетам;
в
вопросах архитектуры; опыт
содействует
процессу оценки сценариев
участия
в оценке вариантов
в
контекстеархитектуры; содействует
архитектуры;
способность
проведению
местного анализа
отличить
беспредметные прения от дискуссии,
потенциально ведущей к получению
ценных выводов
Секретарь
В
процессе выявления сценариев
Хороший
почерк; способность
по
сценариям
пишет
сценарии на лекционном
сосредоточивать
специалистов
плакате
или белой доске; фиксирует
на
задаче формулирования идеи
согласованные
формулировки
(сценария);
понимание
сценариев;
не позволяет остальным
технической
терминологии
участникам
углубляться в дискуссии
и
способность резюмировать
до
получения точных формулировок
соответствующие
дискуссии
Секретарь
по
Работая
на портативном компьютере
Крепкие
навыки быстрого
результатам
или
на рабочей станции, в электронной
клавишного
набора; способность
форме
фиксирует результаты:
оперативно
восстанавливать
непроверенные
сценарии, соображения,
в
памяти нужную информацию;
влияющие
на их составление
компетентность
в архитектурных
(во
многих случаях они не отражаются
вопросах;
навыки быстрого
в
формулировкесамогосценария),
усвоения
технических проблем;
резолюции
сценариев применительно
отсутствие
комплексов,
к
архитектуре; в его обязанности также
позволяющее(в
подходящий
входит
предоставление всем участникам
момент)
прервать дискуссию для
печатной
версии списка всех принятых
прояснения
вопроса и фиксации
сценариев
нужной
информации
Источник:
приводится no
изданию
[Clcmcnts
02a]
(адаптированная
версия).
Роль |
Обязанности |
Предпочтительные характеристики |
Хронометрист |
Помогает руководителю специалистов по оценке придерживаться графика; ограничивает время, уделяемое на этапе оценки каждому из сценариев |
Способность в нужный момент прерватьдискуссию и напомнить ее участникам о временных ограничениях |
Наблюдатель |
Вырабатывает способы усовершенство |
Внимательность при |
за процессом |
вания или видоизменения процесса оценки; в основном остается в тени, но изредка может высказывать руководителю разумные соображения относительно процесса оценки; отчитывается о проведенном процессе и формулирует предложения на будущее; крометого, обязандетально изложить участникам группы оценки сведения, относящиеся к накопленному ранее опыту |
наблюдении; серьезная компетентность в вопросах оценки; опыт осуществления методики архитектурной оценки |
Координатор |
Помогает руководителю специалистов |
Серьезные знания по части |
процесса |
по оценке соблюдать все этапы метода оценки |
подробностей этапов метода; способность предоставления руководителю специалистов по оценке полезных консультаций |
Дознаватель |
Поднимает архитектурные вопросы, о которых не подумали заинтересованные лица |
Серьезные знания в области архитектуры; понимание потребностей заинтересованных лиц; опыт работы с системами в сходных предметных областях; способность поднимать дискуссионные вопросы и добиваться их рассмотрения; хорошее знание оцениваемых атрибутов качества |
