- •Часть 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 (Питтсбург, сша).
5.6. Тактики реализации контролепригодности
Тактики контролепригодности призваны упрощать тестирование при завершении того или иного этапа разработки программного продукта (рис. 5.10). Архитектурные методики повышения контролепригодности программного обеспечения известны не так широко, как их аналоги в более изученных областях модифицируемости, производительности и готовности. В пользу их развития свидетельствует то обстоятельство, что на тестирование уходит весьма значительная доля средств, выделяемых на разработку системы, а значит, любые действия архитектора, направленные на снижение этой стоимости, приобретают большую ценность.
В главе 4 мы представили оценку проекта как одну из методик тестирования, однако в данный момент нас интересуют только вопросы тестирования работающей системы. Любой режим тестирования направлен на обнаружение неисправ-
гостей. Для того чтобы это стало возможным, в тестируемый программный продукт следует сначала направить входные данные, а затем собрать выходные.
Отправка в тестируемый программный продукт входных и сбор выходных данных обычно осуществляются специальной тестирующей программой (test harness). Вопросы проектирования и генерации таких программ мы не рассматриваем, хотя во многих системах на это уходит много времени и средств.
Мы намерены обратить ваше внимание на две категории тактик тестирования: тактики подачи входных и сбора выходных данных и тактики внутреннего мониторинга.
Входные/выходные данные
Ниже перечислены тактики контроля входных и выходных данных.
♦ Запись/считывание. В данном случае предполагается сбор информации, проходящей через интерфейс, и ее применение тестирующей программой в качестве входных данных. Информация, проходящая через интерфейс во время нахождения системы в нормальном режиме, сохраняется в репозитарии и представляется одновременно как выходные данные одного компонента и входные данные другого. Запись этой информации позволяет генерировать для одного из них тестовые входные данные и сохранять тестовые выходные данные в расчете на последующий анализ.
♦ Отделение интерфейса от реализации. Разделение интерфейса и реализации обеспечивает возможность замены реализаций в зависимости от целей тестирования. Реализация-заглушка позволяет тестировать оставшиеся элементы системы в отсутствие компонента-оригинала. Оригинальный ком-понент можно заменить специализированным компонентом-тестировщи- ком оставшихся элементов системы.
♦ Специализация путей/интерфейсов доступа. Наличие специализированных интерфейсов тестирования позволяет собирать и специфицировать значения переменных компонента, причем проводятся эти операции либо с помощью тестирующей программы, либо независимо от нормальной работы компонента. К примеру, доступ к метаданным может осуществляться через специализированный интерфейс, через который тестирующая программа координирует свои операции. Специализированные пути/интерфейсы доступа следует отделять от путей/интерфейсов доступа, обеспечивающих обычную функциональность. Наличие в архитектуре иерархии тестовых интерфейсов обеспечивает возможность применения тестов на любом из ее уровней и наблюдения за реакцией посредством тестовых функций.
Внутренний мониторинг
Поддержка процесса тестирования со стороны отдельного компонента обеспечивается путем реализации тактик на основе его внутреннего состояния.
♦ Встроенные мониторы. Компонент может обслуживать информацию о состоянии, рабочей нагрузке, мощности, безопасности и любые другие данные,
доступ к которым можно получить через интерфейс. Интерфейс этот мо-жет быть постоянным или временным; для введения временных интерфейсов применяются, в частности, аспектно-ориентированное программирование и макрокоманды процессора. Во многих случаях события регистрируются при активизированных режимах мониторинга. Фактически, такие режимы увеличивают издержки тестирования, поскольку после их выключения снова приходится проводить тесты. С другой стороны, повышенная обозримость действий компонента, как правило, значительно перевешивает издержки, связанные с дополнительным тестированием.
Схема тактик контролепригодности приводится на рис. 5.11.
