Rational Rose 2000 и 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) архитектуры позволяет показать и проверить логическое представление, представления процессов, компонентов и средств внедрения. Диаграммы взаимодействий и диаграммы последовательности действий создаются для того, чтобы продемонстрировать, как различные элементы проектирования взаимодействуют для получения нужного поведения.

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

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

Глава 12. Выпуск версий

В плане выпуска версий (iteration release plan) представлены расписания для каждого шага развития системы. «Такой план должен определять серию архитектурных выпусков, постепенно расширяющихся по функциональности и в конечном счете охватывающих требования ко всей системе»[12].

«В плане выпуска версий должны излагаться специфичные для версии цели:

□ реализуемые возможности;

□ уменьшаемые с данной версией риски;

□ устраняемые версией дефекты.

Критерии выхода:

□ обновленные сведения о возможностях;

□ обновленный план уменьшения рисков;

□ документ, содержащий сведения о результатах выпуска версии;

□ получение результатов тестирования продукта, включая список дефектов;

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

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