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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После завершения очередной версии риски переоцениваются и план проекта при необходимости обновляется. «Для большинства проектов план определяет пять (плюс-минус два) промежуточных выпусков»[15].

Процесс планирования версий представлен на рис. 12.1.

Рис. 12.1. Процесс планирования версий

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

Версия 1:

Сохранение сведений о преподавателе Выбор курсов для преподавания Создание учебного плана Версия 2:

Сохранение сведений о студенте Составление каталога Версия 3:

Регистрация на курсы

Запрос списка учебных классов

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

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

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

После изучения сценариев, связанных с прецедентом Выбор курсов для преподавания (Select Courses to Teach), созданы окна для добавления, удаления и просмотра и определены следующие требования:

? преподаватель должен ввести пароль для входа в систему. Для ввода пароля создано отдельное окно;

? если пароль верен, на экране появляется окно Параметры курса преподавателя (ProfessorCourseOptions). Оно содержит поле для указания семестра и группу кнопок: Добавить курс (Add Course), Удалить курс (Delete Course), Просмотр расписания (Review Schedule), Печать расписания (Print Schedule).

В этой книге проектирование рассматривается на примере операции Добавить курс (Add Course) для данного сценария. Важно отметить, что проект системы не может основываться только на одном сценарии — он развивается по мере создания новых сценариев. Я выбрала один сценарий для иллюстрации нотаций Rational Unified Process и UML, которые могут быть использованы для представления различных решений при проектировании.

Операция Добавить курс подразумевает добавление преподавателя к учебному курсу в качестве учителя. Этот сценарий требует отдельного окна для ввода преподавателем необходимой информации. Я назвала это окно Добавление (Addition). Оно содержит следующие элементы:

? поле ввода Название предмета (Course name);