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

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

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

В плане выпуска версий (iteration release plan) представлены расписания для каждого шага развития системы. «Такой план должен определять серию архитектурных выпусков, постепенно расширяющихся по функциональности и в конечном счете охватывающих требования ко всей системе» [12] Booch, Grady. Object Solutions. Redwood City, CA: Addison-Wesley, 1995. .

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

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

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

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

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

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

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

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

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

□ план выпуска версий, содержащий измеримые вычисляемые критерии для оценки результатов следующей версии» [13] Kruchten, Philippe. A Rational Development Process. Rational Software Corporation. Available at www.rational.com . .

Сценарии, созданные на этапе анализа, являются основными входными данными для этой стадии разработки. Сценарии изучаются и сортируются согласно степени риска, важности для заказчика и потребности в первоочередной разработке определенных базовых сценариев. Эта задача наилучшим образом решается рабочей группой, в состав которой входят эксперт по предметной области, аналитик, специалист по архитектуре и специалисты по тестированию. «Сценарии должны быть сгруппированы так, чтобы для очередного выпуска они совместно обеспечивали реализацию значительной части поведения системы и указывали на необходимость рассмотрения следующего наибольшего риска» [14] Booch, Grady. Object Solutions. Redwood City, CA: Addison-Wesley, 1995. .

После завершения очередной версии риски переоцениваются и план проекта при необходимости обновляется. «Для большинства проектов план определяет пять (плюс-минус два) промежуточных выпусков» [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);

□ поле ввода Номер предмета(Course number);

□ список Учебные курсы(Course offerings);

□ кнопку OK;

□ кнопку Отмена(Cancel);

□ кнопку Выход(Quit).

После того как преподаватель ввел название и номер предмета, система получит и отобразит список учебных курсов. Затем преподаватель может выбрать учебный курс. При щелчке по кнопке ОКобъекту предмет направляется сообщение.

Реализация пользовательского интерфейса зависит от выбранной библиотеки классов. Ее рассмотрение выходит за рамки данной книги. В этом разделе говорится о проектировании интерфейса. Как правило, он создается с помощью специальных инструментов для построения графических интерфейсов пользователя. В данном случае, после создания классов ГИП, могут быть использованы средства возвратного проектирования программы Rational Rose для добавления классов к модели.