- •Часть 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 (Питтсбург, сша).
7.7. Дискуссионные вопросы
1. Исходя из архитектуры, составляются рабочие группы. Они занимаются конструированием модулей, из которых состоит архитектура. Итак, в большинстве случаев в структуре рабочих групп отражена модульная декомпозиция. Каковы преимущества и недостатки формирования рабочих групп исходя из компонентной структуры или на основе какой-то другой архитектурной структуры — например, структуры процессов?
2. ADD предусматривает метод «разбиения» требований. В первую очередь удовлетворяются архитектурные мотивы и только после этого в контексте подстроенного под них решения осуществляются попытки удовлетворить всем остальным требованиям. Какие еще существуют методы разбиения применительно к проектной стратегии декомпозиции? Почему ни одна де* композиция не дает возможности удовлетворить всем требованиям?
3. Какие еще методики помогают построить первоначальную версию программ* ной архитектуры или архитектуры системы? Как в рамках этих методик решаются вопросы соответствия функциональным, коммерческим требованиям и требованиям по качеству?
4. Как ADD соотносится со специализированными методиками проектирования в категориях конечного результата, времени и ресурсов, необходимых для реализации сравниваемых методов? В каких случаях лучше обращаться к ADD и в каких — к специализированным методам?
ОТКУДА БЕРУТСЯ СТАНДАРТЫ?
Пару лет назад в Usenet проскользнула занимательная тема. Обсуждался следующий вопрос: почему в США принята весьма странная стандартная ширина железнодорожной колеи — 4 фута 8 1/2 дюймов. Выводы, которые были сделаны, одинаково справедливы для всех областей технологии, в которых применяются стандарты.
Оказалось, что причин принятия такого стандарта две: обратная совместимость с существующими системами и опыт железнодорожных архитекторов. Дело в том, что первые разработчики американской железнодорожной системы учились в Великобритании, работали с британским инструментом и равнялись на подвижной состав британского образца. Это обстоятельство лишь переводит вопрос на другой уровень: почему эта причудливая ширина колеи применялась в Британии?
Говорят, что британцы пользовались этим стандартом по точно тем же двум причинам, что и американцы, — из-за необходимости обеспечить совместимость со старыми образцами и исходя из опыта архитектора. Вагонетки (предшественники железных дорог) строились в расчете именно на эту ширину колеи. Строители железных дорог, переквалифицировавшись из строителей вагонеток, поначалу пользовались старым инструментом.
Но и у вагонеток есть своя история. Первые вагонетки конструировались по образцу повозок. Соответственно, первые строители вагонеток пользовались теми же инструментами и отталкивались от тех же представлений, которые ранее применялись в строительстве повозок. Как бы то ни было, наш вопрос остается без ответа — почему расстояние между колесами повозок должно было быть равным 4 футам и 8 1/г дюймам?
Это решение объяснялось современными условиями, соответствующими существовавшей на тот момент технологии: любое другое расстояние неизбежно приводило бы к поломке колес, потому что колеи на дорогах Британии в то время были именно этой ширины.
Дороги тоже не появились из небытия. Сдерживавший нововведения технологический стандарт обусловливал эту немаловажную особенность повозок. На этот раз причины следует искать в Риме. Первые магистральные пути в Британии строились римлянами, и происходило это в течение первых четырех веков нашей эры. Зачем римляне приняли такое решение? Да затем, что по дорогам такой ширины могли проехать их колесницы. Следовательно, ширина колеи в современных Соединенных Штатах связана с конструкцией римских колесниц, применявшихся двумя тысячелетиями ранее.
Но это еще не все.
Расстояние между колесами римской колесницы обусловливалось шириной упряжи, через которую в колесницу запрягалась лошадь. Упряжь не могла быть другой ширины, ибо в противном случае лошадь разрушала бы колею. Таким образом, мы можем уверенно утверждать, что сегодняшняя ширина рельсов в Соединенных Штатах установилась в результате следования ряду стандартов, каждый из которых обусловливался сочетанием технических Факторов, ограничениями, свойственными системам предыдущих поколений, и опытом ар-хитекторов. Итак, по совокупности факторов получается, что причиной, по которой ширина американских рельсов сегодня составляет именно ту величину, которую составляет, являет- Ся стандартный круп римского боевого коня.
Все эти доводы, быть может, не слишком убедительны, но — вдумайтесь! — какие могут быть последствия легкомысленного отношения к стандартам. Когда Наполеон напал на Рос- СИ|о, движение его армии в Восточной Европе, сильно замедлились — все потому, что колея на местных дорогах не соответствовала римскому стандарту. Нарушив временные рамки, они п°пали в условия русской зимы. Что случилось после этого, мы все прекрасно знаем.
— RK
