Часть 8. Проектирование архитектуры системы.
Программная архитектура - набор средств, используемых для указания стратегических решений по структуре и поведению системы, взаимодействию между элементами системы и физическому размещению системы.
Создание качественного архитектурного базиса необходимо для успешной реализации объектно-ориентированных проектов.
Развитие архитектуры - достаточно сложный вопрос. Архитектура системы развивается итеративно на стадии проработки. Архитектура системы требует тщательного изучения Вариантов использования, создания прототипов для подтверждения основных концепций, создания архитектурного фундамента и других усилий в процессе задумки и проработки. Для проверки корректности решений на этапе проектирования моделируются работоспособные прототипы архитектуры.
В каждом проекте должен участвовать главный специалист по архитектуре, у которого может быть несколько ассистентов. В обязанности такого специалиста входит определение архитектуры программных продуктов, поддержка целостности архитектуры, оценка технических рисков проекта, определение порядка выпуска последовательных версий и планирование их содержания, проведение консультаций для групп проектировщиков, разработчиков, сборщиков и тестеров, а также помощь в определении будущей маркетинговой стратегии.
1 Пять уровней архитектуры
Программная архитектура многомерна - она состоит из нескольких одновременно развивающихся уровней (см. рис. 15.1).
2 Логический уровень
Логическое представление (logical view) архитектуры описывает функциональные требования к системе - то, что система должна обеспечивать для обслуживания пользователей. Логическая архитектура отображается на диаграмме классов, содержащей классы и отношения, которые представляют ключевые абстракции разрабатываемой системы.
Большинство нотаций языка UML содержится в самом логическом представлении архитектуры (классы, ассоциации, агрегации, обобщение, пакеты и др.). Оно вводится на фазе проработки при создании классов и пакетов, представляющих основные абстракции предметной области. Постепенно все больше классов и пакетов добавляется в модель для отражения решений, касающихся ключевых механизмов системы. Ключевой механизм - это решение относительно общих стандартов, правил и норм. Выбор ключевых механизмов системы часто называют тактическим проектированием (tactical design). К некоторым ключевым механизмам относятся: язык разработки, хранение данных, удобный пользовательский интерфейс, обработка ошибок, механизмы взаимодействия, распределение и миграция объектов, сетевые средства.
Роберт Мартин (Robert Martin) рассмотрел некоторые вопросы выбора пакетов системы в своей книге "Разработка объектно-ориентированных приложений на C++ с использованием методов Буча". Подходы и нотация Буча вполне применимы к методологии Rational Unified Process и языку UML. Отсюда вывод: язык UML может использоваться для отражения стратегических решений в системе при внесении пакетов и классов в модель для представления, реализации и документального описания этих решений.