Rational Rose 2000 и UML Визуальное моделирование

На протяжении многих лет я слышала разные определения программной архитектуры: от «программная архитектура — это то, чем занимаются специалисты по программной архитектуре» до «программная архитектура — это политика». Я пришла к выводу, что для программной архитектуры очень трудно подобрать определение. Ее можно представить как набор средств, используемых для указания стратегических решений по структуре и поведению системы, взаимодействию между элементами системы и физическому размещению системы.

«Создание качественного архитектурного базиса необходимо для успешной реализации объектно-ориентированных проектов. Некоторые разработчики пытаются пропустить эту фазу, либо спешат с выпуском продукта, либо не верят в преимущества архитектурных решений. В любом случае результат всегда плачевный — недостаточная проработка этого шага приводит к постепенному распаду проекта»[6].

Развитие архитектуры — достаточно сложный вопрос. Архитектура системы развивается итеративно на стадии проработки. «Архитектура системы не возникает сразу. Она требует тщательного изучения прецедентов, создания прототипов для подтверждения основных концепций, создания архитектурного фундамента и других усилий в процессе задумки и проработки»[7]. Для проверки корректности решений на этапе проектирования моделируются работоспособные прототипы архитектуры. «Создание чего-то работоспособного очень важно, потому что позволяет группе специалистов проверять проектные предположения на практике»[8]³.

О разработчиках архитектуры

В каждом проекте должен участвовать главный специалист по архитектуре, у которого может быть несколько ассистентов. «В обязанности такого специалиста входит определение архитектуры программных продуктов, поддержка целостности архитектуры, оценка технических рисков проекта, определение порядка

выпуска последовательных версии и планирование их содержания, проведение консультаций для групп проектировщиков, разработчиков, сборщиков и тестеров, а также помощь в определении будущей маркетинговой стратегии»[9].

Представление архитектуры 4 + 1

Программная архитектура многомерна — она состоит из нескольких одновременно развивающихся представлений[10] (см. рис. 11.1).

Во всех последующих разделах этой главы рассказывается об элементах каждого представления и нотации языка UML для описания архитектурных решений.

Рис. 11.1. Представление архитектуры 4 + 1

Логическое представление

Логическое представление (logical view) архитектуры описывает функциональные требования к системе — то, что система должна обеспечивать для обслуживания пользователей. Логическая архитектура отображается на диаграмме классов, содержащей классы и отношения, которые представляют ключевые абстракции разрабатываемой системы.

Большинство нотаций языка UML содержится в самом логическом представлении архитектуры (классы, ассоциации, агрегации, обобщение, пакеты и др.). Оно вводится на фазе проработки при создании классов и пакетов, представляющих основные абстракции предметной области. Постепенно все больше классов и пакетов добавляется в модель для отражения решений, касающихся ключевых механизмов системы. Ключевой механизм — это решение относительно общих стандартов, правил и норм. Выбор ключевых механизмов системы часто называют тактическим проектированием (tactical design). «Плохое тактическое проектирование может уничтожить даже тщательно продуманную архитектуру, поэтому разработчики должны уменьшить этот риск, определив ключевые правила проекта»[11]. К некоторым ключевым механизмам относятся: язык разработки, хранение данных, удобный пользовательский интерфейс, обработка ошибок, механизмы взаимодействия, распределение и миграция объектов, сетевые средства.

На сегодняшний день существует много шаблонов, которые могут использоваться для реализации ключевых решений системы. Я настоятельно рекомендую изучить шаблоны, прежде чем предпринимать самостоятельные шаги.

Кроме того, концепции связности (cohesion), замкнутости (closure) и повторного использования (reuse) повлияют на ваш выбор. Роберт Мартин (Robert Martin) рассмотрел некоторые вопросы выбора пакетов системы в своей книге «Разработка объектно-ориентированных приложений на С++ с использованием методов Буча». Подходы и нотация Буча вполне применимы к методологии Rational Unified Process и языку UML. Отсюда вывод: язык UML может использоваться для отражения стратегических решений в системе при внесении пакетов и классов в модель для представления, реализации и документального описания этих решений.

Ключевые механизмы для задачи регистрации учебных курсов