- •Часть 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 (Питтсбург, сша).
9.2. Представления
Вероятно, наиболее важным понятием документирования программной архитектуры является «представление» (view). В главе 2 мы определили программную архитектуру системы как «структуру структур системы, охватывающих элементы, их внешние свойства и отношения между ними». Кроме того, как мы установили, под представлением подразумевается отображение связного набора архитектурных элементов, составленного с позиции заинтересованных лиц и в расчете на использование заинтересованными лицами. Структурой называется сам набор таких элементов в том виде, в котором они существуют в программном или аппаратном обеспечении.
Также в главе 2 мы пришли к выводу о том, что программная архитектура как комплексный объект не поддается одномерному описанию. Для иллюстрации этого утверждения мы сравнили программную архитектуру с архитектурой зданий, заметив попутно, что подобного рода аналогиями не следует злоупотреблять. В архитектуре зданий применяется сразу несколько проекций: планы помещений, фасадные представления, электротехнические, водопроводные и вентиляционные схемы, схемы перемещения, проекции с прямым солнечным светом и солнечной радиацией, планы охранных систем и многие другие. Какое из этих представлений можно назвать архитектурой? Никакое. Какие из них являются проводниками архитектуры? Все.
С понятием представления, которое можно вкратце определить как способ фиксации структуры, связан основной принцип документирования программной архитектуры:
Документирование архитектуры подразумевает документирование всех значимых представлений с последующей фиксацией сведений, относящихся одновременно к нескольким представлениям.
Принцип этот полезен тем, что он помогает разбить проблему документирования архитектуры на ряд менее обширных элементов. Этому разделению соответствует структура оставшейся части главы:
♦ выбор значимых представлений;
♦ документирование представления;
♦ документирование сведений, относящихся к нескольким представлениям.
9.3 Выбор значимых представлений
Как вы помните, в главе 2 рассматривался ряд структур и представлений. Какие представления следует считать значимыми? Для ответа на этот вопрос необходимо знать заинтересованных лиц и предпочтительные для них способы пользования документацией — лишь располагая этими сведениями, вы сможете составить удобный для них пакет документации. Любой вариант применения архитектуры — как средства постановки задач конструкторов, основы для изучения системы, восстановления ее свойств или планирования проекта — можно свести к отдельному заинтересованному лицу, предполагающему задействовать документацию архитектуры соответствующим образом. Не менее серьезное влияние на выбор представлений для дальнейшего документирования оказывают наиценнейшие для большинства заинтересованных в разработке системы лиц атрибуты качества. К примеру, многоуровневое представление (layered view) сообщает сведения о переносимости системы. По представлению размещения (deployment view) можно судить о производительности и надежности системы. И так далее. За отражение этих атрибутов качества в документации ратуют аналитики (а быть может, и сам архитектор), в задачу которых входит проверка архитектуры на предмет ее им соответствия.
Короче говоря, различные представления соответствуют отдельным задачам и вариантам использования. Именно по этой причине мы призываем к выбору того или иного представления или набора представлений. Их выбор зависит от задач потребителей документации. Представления ставят акценты на разные элементы системы и/или установленные между ними связи.
Таблица 9.2. Заинтересованные лица и виды архитектурной документации, представляющиеся для них наиболее полезными1
Заинтересованное лицо |
Модульные представления |
Представления «компонент и соединитель» |
Представления распределения |
||||
Декомпозиции |
Вариантов использования |
Классов |
Многоуровневое |
Разные |
Размещения |
Реализации |
|
Руководитель проекта |
s |
s |
|
s |
|
d |
|
Участник группы разработчиков |
d |
d |
d |
d |
d |
s |
s |
Тестировщики и сборщики |
|
d |
d |
|
s |
s |
s |
Специалисты по сопровождению |
d |
d |
d |
d |
d |
s |
s |
Разработчик приложений в рамках линейки продуктов |
|
d |
s |
o |
s |
s |
s |
Таблица 9.2 (продолжение)
Заинтересованное лицо |
Модульные представления |
Представления «компонент и соединитель» |
Представления распределения |
||||
Декомпозиции |
Вариантов использования |
Классов |
Многоуровневое |
Разные |
Размещения |
Реализации |
|
Заказчик |
|
|
|
|
s |
о |
|
Конечный пользователь |
|
|
|
|
s |
s |
|
Аналитик |
d |
d |
S |
d |
s |
d |
|
Специалист по инфраструктуре |
s |
s |
|
s |
|
s |
d |
Новое заинтересованное лицо |
x |
x |
x |
x |
x |
x |
x |
Архитектор и его преемники |
d |
d |
d |
d |
d |
d |
s |
1 Приводится по изданию [CJements 03] (адаптированная версия)
Условные обозначения: d — подробная информация, s — отдельные детали, о — обзор, х — любая информация.
В табл. 9.2 приводится репрезентативная совокупность заинтересованных лиц, а также те представления, которые они, как правило, находят для себя полезными. Исходя из данных этой таблицы удобно делать выводы для конкретных случаев. Какие представления из тех, что подходят для заинтересованных в данной системе лиц, можно составить? Часть представлений, описанных в главе 2, отражены в табл. 9.2. В главе 2 представления разделены на три группы: модульные, распределения и «компонент и соединитель» (component-and-connector, С&С). Следовательно, архитекторы должны отвечать на три вопроса о любом проектируемом ими программном обеспечении:
Какова его структура как набора блоков реализации?
Какова его структура как набора элементов с заданным поведением и взаимодействием периода прогона?
Каковы его отношения с непрограммными структурами среды?
Существуют и другие представления. Представление отражает произвольный набор элементов системы и установленных между ними отношений. Следовательно, представлением может быть любое сочетание элементов и отношений, которое, по вашему мнению, имеет шансы оказаться интересным части заинтересованных лиц. Ниже приводится состоящая из трех этапов процедура подбора представлений для конкретного проекта.
1. Составьте список возможных представлений. Начните с составления для своего проекта таблицы заинтересованных лиц/представлений, отталкиваясь при этом от содержания табл. 9.2. Скорее всего, список заинтересованных лиц будет отличаться от отраженного в нашей таблице; в любом случае, вы должны учесть их всех. В столбцах выразите применимые к вашей системе представления. Некоторые из них (например, модульное представление и представление вариантов использования) носят универсальный характер; иные (многоуровневое представление, а также большинство представлений из группы «компонент и соединитель» — в частности, клиент-серверное представление и представление совместно используемых данных) подходят только для соответствующим образом спроектированных систем. Разобравшись с содержанием строк и столбцов, заполните все ячейки, отразив в них степень детализации сведений о каждом представлении, необходимую тем или иным заинтересованным лицам: здесь возможны произвольная детализация, обзор, средняя или высокая детализация.
Комбинируйте представления. Скорее всего, количество представлений, отраженных в составленном по результатам первого этапа списке, окажется недопустимым. Для того чтобы сократить список, найдите в таблице представления, требующие не более чем обзорной детализации или служащие ограниченному числу заинтересованных лиц. Проверьте, нельзя ли удовлетворить их запросы другим, более универсальным представлением. Затем найдите представления, которые можно комбинировать — выразить в одном сводном представлении информацию из нескольких исходных представлений. В небольших по масштабу проектах информативное содержание представления реализации, как правило, адекватно отражается в представлении декомпозиции на модули. Последнее, в свою очередь, хорошо сочетается с представлениями вариантов использования и многоуровневым представлением. Наконец, представление размещения можно скомбинировать с любым представителем группы «компонент и соединитель», отражающим распределение компонентов между аппаратными элементами, — например, с представлением процессов.
Расставляйте приоритеты. Представления, оставшиеся после выполнения второго этапа, должны соответствовать потребностям сообщества заинтересованных лиц. Теперь необходимо решить, какие из этих представлений имеют первостепенное значение. Конкретное решение зависит от деталей проекта; впрочем, вы в любом случае должны помнить, что полностью завершать работу над одним представлением, прежде чем приступать к следующему, совершенно не обязательно. Информация, детализированная на уровне обзора, представляет некоторую ценность, так что наши предпочтения — на стороне метода разработки материала «в ширину». Кроме того, интересы одних заинтересованных лиц в ряде случаев ставятся выше интересов других. Не забывайте о том, что руководитель проекта и менеджмент компаний-партнеров часто требуют внимания и предоставления той или иной информации.
