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

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

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

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

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

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

Поскольку многие разработчики владеют именно С++, а в дальнейшем систему планируется расширять для автоматизации других потребностей университета, то в качестве основного языка был выбран С++. Разработчики архитектуры выяснили, что для создания графического интерфейса пользователя (ГИП) потребуется определенный набор графических элементов управления, и в модель был добавлен пакет Элементы управления ГИП (GUI Controls). Стратегия хранения данных предполагает использование отдельного класса доступа к базе данных (теневого класса) для каждого информационного класса в системе. Существуют и другие стратегии, например с применением механизмов наследования. Но именно эта стратегия выбрана потому, что уже накоплен достаточный опыт в реализации такого метода хранения и он считается наименее рискованным. На текущем этапе в модель добавляется пакет для доступа к базе данных, содержащий необходимые теневые классы. Для обработки исключений решено использовать механизмы языка С++ catch и throw. Вместо обработчиков исключений в модель добавлен общий пакет Обработка ошибок (Error Handling). И наконец, в систему добавлен набор классов для реализации основных коммерческих операций Базовые средства (Foundation). Пакеты, представляющие ключевые решения для системы регистрации курсов, показаны на рис. 11.2.

Рис. 11.2. Система регистрации учебных курсов

Так как Обработка ошибок и Базовые средства используются всеми остальными пакетами системы, они являются глобальными пакетами (global packages).

Выбор глобальных пакетов в программе Rational Rose состоит из следующих шагов:

1. Щелкните правой кнопкой мыши по пакету на диаграмме классов.

2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Параметры), чтобы вызвать диалоговое окно настройки параметров пакета.

3. Выберите вкладку Detail (Детально).

4. Установите флажок Global (Глобальный).

5. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно настройки параметров.

Представление реализации

Представление реализации (implementation view) определяет реальную организацию программных модулей в среде разработки. Оно учитывает потребности в простоте разработки, управлении программными средствами, повторном использовании кода, а также языковых и инструментальных ограничениях.

Элементами моделирования в представлении компонентов (component view) являются пакеты, компоненты и связи между ними.

Пакет в данном представлении архитектуры — это физический раздел системы. Пакеты организованы в виде иерархии уровней или слоев, где каждый уровень имеет четко определенный интерфейс. На рис. 11.3 изображена типичная схема уровней системы.

Рис. 11.3. Уровни системы

Нотация языка UML для изображения пакетов в представлении компонентов напоминает изображение пакетов в логическом представлении — см. рис. 11.4. Для создания пакетов в представлении компонентов в программе Rational Rose:

1. Щелкните правой кнопкой мыши по разделу Component View (Представление компонентов) в окне браузера.

2. В появившемся контекстно-зависимом меню выберите команду New => Package (Создать => Пакет). В список объектов браузера будет добавлен новый пакет New Package.

3. Введите нужное имя пакета.

Рис. 11.4. Нотация языка UML для пакетов

Главная диаграмма компонентов обычно представляет определенные для системы пакеты.

Чтобы получить главную диаграмму компонентов в программе Rational Rose:

1. Дважды щелкните по диаграмме Main Diagram (Главная диаграмма) в разделе Component View (Представление компонентов) в окне браузера, чтобы открыть диаграмму.

2. В списке браузера щелкните по пакету и перетащите его на диаграмму.

3. Повторите второй шаг для других пакетов, которые нужно поместить на диаграмму.

4. Чтобы добавить отношения зависимости, щелкните по кнопке Dependency (Отношение зависимости) на панели инструментов, затем по пакету-клиенту и проведите линию связи к пакету-поставщику.

Главная диаграмма компонентов для задачи регистрации учебных курсов показана на рис. 11.5.

Рис. 11.5. Главная диаграмма компонентов

Компоненты исходного кода

В представлении компонентов модели компоненты исходного кода — это программные файлы, содержащиеся внутри пакетов. Тип файлов зависит от языка программирования (например, в С++ — файлы. h и срр, в Java — .Java, в PowerBuilder — .pbl). Каждый компонент связан с каким-либо языком. Классы в логическом представлении отображаются на компоненты в представлении компонентов. Для С++ один класс отображается в один компонент. Однако иногда на один компонент может быть отображено больше одного класса. Это обычно происходит в том случае, когда между классами существует очень тесная связь. Напри-

мер, контейнер и его итератор содержатся в одном. h- и одном срр-файле. Значит, класс-контейнер и класс-итератор будут отображаться на один компонент. Я также видела классы, которые используются как шаблон взаимодействия, отображаемый на один физический файл. Нотация языка UML для компонента показана на рис. 11.6.

Рис. 11.6. Нотация языка UML для компонента

Программные компоненты в задаче регистрации учебных курсов

Это относительно простая система, вот почему было принято решение обеспечить отображение один в один между классами и компонентами — каждый класс имеет собственный файл заголовка и срр-файл.

Для создания компонентов в программе Rational Rose:

1. Откройте диаграмму компонентов.

2. Щелкните по кнопке Component (Компонент) на панели инструментов.

3. Щелкните по диаграмме, чтобы поместить на нее компонент. Новый компонент также будет добавлен в список браузера.

4. Введите имя нового компонента.

Простая диаграмма компонентов показана на рис. 11.7.

Рис. 11.7. Программные компоненты

Отображение классов на компоненты в программе Rational Rose предусматривает выполнение следующих действий:

1. Щелкните правой кнопкой мыши по компоненту в списке браузера.

2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Открыть параметры).

3. Щелкните по вкладке Realize (Реализация).

4. Щелкните правой кнопкой мыши по нужному классу в списке классов.

5. В появившемся контекстно-зависимом меню выберите команду Assign (Присвоить).

6. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно настройки параметров компонента.

Класс можно присвоить компоненту путем перетаскивания класса из окна браузера на изображение компонента в браузере или на диаграмме компонентов.

Диалоговое окно настройки параметров компонента учебный курс (Course Offering) показано на рис. 11.8.

Рис. 11.8. Диалоговое окно настройки параметров для компонента учебный курс

Представление процессов

Представление процессов (process view) отражает структуру программной реализации системы. Представление процессов учитывает такие потребности, как производительность, надежность, масштабируемость, целостность, управление системой и синхронизация. Компоненты также ис-

пользуются в этом представлении архитектуры. Для представления программных (run-time) и исполняемых (executable) компонентов системы создается диаграмма компонентов. Компоненты связаны отношением зависимости. Программные компоненты отображают классы на программные библиотеки, такие как Java-апплеты, элементы Active-X и динамические библиотеки. Исполняемые компоненты показывают интерфейсы и зависимости вызовов между исполняемыми модулями. Для демонстрации типа компонента может быть использован стереотип. Интерфейсные классы, созданные на этапе проектирования, изображаются с помощью леденцовой нотации (lollypop notation) — см. рис. 11.9.

Рис. 11.9. Интерфейс компонента

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

В системе регистрации учебных курсов созданы две динамические библиотеки (DLL) — для обработки информации о предметах и учебных курсах и для работы с базой данных. Такой подход был выбран исходя из возможных изменений в структуре курсов и в стратегии взаимодействия с базой данных.

При наличии изменений достаточно воспользоваться другой библиотекой. В системе есть три исполняемых модуля — один для регистратора, чтобы осуществлять ввод данных и управление информацией в системе; один для студента и один для преподавателя с целью получения доступа и использования системы. Между исполняемыми модулями нет никакого взаимодействия. Диаграмма компонентов для исполняемого модуля преподавателя (ProfessorOptions.exe) показана на рис. 11.10.

Рис. 11.10. Исполняемый модуль ДЛЯ преподавателя

Представление средств внедрения

Представление средств внедрения (deployment view) отображает программные средства на узлы вычислительных систем (processing nodes). Оно показывает конфигурацию элементов обработки (processing elements) и работающих на них программных процессов. Представление средств внедрения учитывает такие потребности, как доступность системы, надежность, быстродействие и масштабируемость. Чтобы показать различные узлы вычислительных систем и связи между ними, создаются диаграммы внедрения (deployment diagrams). Такая диаграмма демонстрирует распределение компонентов по предприятию. Элементы обработки представлены в виде узлов вычислительных систем, которые соединены линиями, показывающими коммуникационные каналы между ними.

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

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

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

После изучения определенных для данной задачи компонентов, существующих аппаратных средств и оценки загруженности системы в период регистрации

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

Последовательность создания диаграммы внедрения в программе Rational Rose:

1. Программа Rational Rose автоматически создает диаграмму внедрения. Чтобы открыть диаграмму, дважды щелкните по ней в окне браузера.

2. Чтобы создать узел, щелкните по кнопке Processor (Процессор) на панели инструментов, а затем по диаграмме.

3. Введите названия для нового узла вычислительной системы.

4. Для создания соединения между узлами щелкните по кнопке Connection (Соединение) на панели инструментов, а затем по одному из узлов на диаграмме внедрения и проведите линию связи к другому узлу.

Диаграмма внедрения для задачи регистрации учебных курсов показана на рис. 11.11.

Рис. 11.11. Диаграмма внедрения

Представление прецедентов

Представление прецедентов (use case view) архитектуры позволяет показать и проверить логическое представление, представления процессов, компонентов и средств внедрения. Диаграммы взаимодействий и диаграммы последовательности действий создаются для того, чтобы продемонстрировать, как различные элементы проектирования взаимодействуют для получения нужного поведения.

Резюме

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

Архитектура также описывает физическую организацию системы. Для отражения физической реализации используется диаграмма компонентов. Диаграмма внедрения отображает конфигурацию аппаратных средств системы.

Данный текст является ознакомительным фрагментом.