
- •Часть 1. Планирование архитектуры
- •Заключение
- •Дополнительная литература
- •4.10. Дискуссионные вопросы
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 6. Управление воздушным движением. Пример разработки, ориентированной на высокую готовность
- •Глава 7. Проектирование архитектуры
- •Глава 8. Моделирование условий полета. Конкретный пример архитектуры, ориентированной на интегрируемость
- •8.4. Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 9. Документирование программной архитектуры
- •Заключение
- •Дополнительная литература
- •Дискуссионные вопросы
- •Глава 10. Реконструкция программной архитектуры
- •Глава 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 (Питтсбург, сша).
2.2. Другие взгляды на архитектуру
Программная архитектура как дисциплина стремительно развивается, но все же она еще молода; поэтому какого-то универсального, повсеместно принятого ее определения не существует. Но и недостатка в вариантах определений не наблюдается. Большинство из них, как правило, сходятся в том, что любая архитектура состоит из структур, элементов и связей между ними; то, что они не взаимозаменяемы, объясняется расхождениями в деталях.
Программная архитектура изучается путем фиксации применяемых проектировщиками принципов конструирования и действий, которые они используют в процессе работы с реальными системами. Таким образом, предпринимается попытка выделить универсальные черты системного проектирования; в этом качестве программная архитектура имеет дело с самыми разными операциями, понятиями, методами, подходами и результатами. Именно поэтому в сообществе специалистов по программной инженерии распространены некоторые другие, отличные от приведенного выше, определения программной архитектуры; поскольку какие-то из них вам наверняка встретятся, вы должны понимать, что они подразумевают, и знать, на основе каких аргументов в том или ином случае можно построить дискуссию. Отдельные, наиболее ходовые определения приводятся ниже.
Архитектура — это проект, поднятый на высокий уровень. Действительно, лошадь относится к млекопитающим, однако они не равнозначны. В процессе проектирования решаются разные задачи, в том числе и неархитектурные — взять хоть вопрос об инкапсуляции значимых структур данных. Интерфейсы этих структур, без сомнения, относятся к архитектуре, но собственно их отбор — нет.
Архитектура — это общая структура системы. Согласно распространенному (но неверному) мнению, у любой системы одна структура. Мы-то знаем, что это не так, а если кто-то вознамерится утверждать обратное, спросите его, какую конкретно структуру он имеет в виду. Эффект будет не только педагогическим. Как мы увидим впоследствии, наполнение системы атрибутами качества, которые в конечном итоге определяют ее успех или провал, происходит именно через разнообразные структуры. Множественность структур в рамках архитектуры составляет суть самого этого понятия.
Архитектура - это структура компонентов программы или системы, взаимосвязи, а также принципы и нормы их проектирования и развития во времени. Это одно из ряда процессно-ориентированных определений, включающих дополнительные сведения о принципах и нормах. Многие считают, что в состав архитектуры входят декларация потребностей заинтересованных лиц и логическое обоснование, регламентирующее реализацию их требований. Действительно, сбор такой информации важен и необходим с точки зрения профессионализма. Однако мы не считаем, что эти документы являются частью архитектуры, — никто ведь не берется утверждать, что руководство пользователя автомобиля входит в состав автомобиля. Архитектуру, к какой бы системе она ни относилась, можно исследовать и проанализировать, не располагая знаниями о процессах ее проектирования и развития.
Архитектура — это компоненты и соединители. Под соединителями имеется в виду механизм периода прогона, предназначенный для передачи в рамках системы сигналов управления и данных. Следовательно, данное определение ориентировано на архитектурные структуры периода прогона. К примеру, соединителем является UNIX-канал. Согласно этой логике, все архитектурные структуры, которые не относятся к периоду прогона (например, рассмотренное выше статическое разделение на ответственные блоки реализации), признаются второстепенными. В то же время в контексте решения системных задач они не менее важны, чем структуры периода прогона. Рассуждая об «отношениях» между элементами, мы имеем в виду все отношения - те, что реализуются в период прогона, и те, что к нему не относятся.
Все дискуссии по поводу программной архитектуры крутятся вокруг структурности систем. Иногда словом «архитектура» обозначают конкретный архитектурный образец (например, клиент-сервер), в других случаях — область исследований (например, книгу об архитектуре), однако в большинстве случаев под «архитектурой» имеют в виду структурные аспекты конкретной системы. Именно их мы пытались отразить в своем варианте определения.