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

Каждый класс должен быть описан в документации! Проверьте уникальность имен классов и просмотрите все описания на предмет их полноты. Выясните, что все атрибуты и операции полностью документированы. На заключительном этапе убедитесь в соблюдении всех стандартов, форматов, спецификаций и правил оформления, определенных для проекта.

Резюме

По мере добавления новых прецедентов и сценариев нужно добиваться однородности модели. Это особенно актуально, когда несколько групп разработчиков проектируют различные части модели. Классы проверяются на предмет необходимости:

  объединения двух или более классов;

  разделения класса;

  исключения класса из модели.

Проверка целостности происходит на протяжении всего жизненного цикла проекта. Она требуется для параллельной разработки нескольких представлений системы и для синхронизации фрагментов системы. Существует три основных способа проверки целостности: проход по сценарию, отслеживание событий и просмотр документации модели.

Глава 11. Проектирование системной архитектуры

Потребность в архитектуре

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

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

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

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

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

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

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

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

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

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

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

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