Глава 12. Выпуск версий
Глава 12. Выпуск версий
Процесс планирования версий
В плане выпуска версий (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);
? поле ввода Номер предмета (Course number);
? список Учебные курсы (Course offerings);
? кнопку OK;
? кнопку Отмена (Cancel);
? кнопку Выход (Quit).
После того как преподаватель ввел название и номер предмета, система получит и отобразит список учебных курсов. Затем преподаватель может выбрать учебный курс. При щелчке по кнопке ОК объекту предмет направляется сообщение.
Реализация пользовательского интерфейса зависит от выбранной библиотеки классов. Ее рассмотрение выходит за рамки данной книги. В этом разделе говорится о проектировании интерфейса. Как правило, он создается с помощью специальных инструментов для построения графических интерфейсов пользователя. В данном случае, после создания классов ГИП, могут быть использованы средства возвратного проектирования программы Rational Rose для добавления классов к модели.
Добавление классов уровня проектирования
Классы обычно добавляются в модель, чтобы выяснить, как реализовать что-либо в системе. Например, в системе регистрации курсов определено, что преподаватель должен ввести пароль, который обязательно проверяется. Для реализации этой задачи в систему добавляется класс, проверяющий пароль. По мере добавления классов в систему они отображаются на соответствующих диаграммах.
Обновленная диаграмма классов для задачи регистрации учебных курсов изображена на рис. 12.2. В этой точке жизненного цикла я буду показывать только названия стереотипов, потому что в модель добавляется разная детальная информация.
Вам необязательно поступать таким же образом. Чтобы стереотипы по умолчанию отображались только в виде названий, выберите в меню команду Tools => Options (Сервис => Параметры), затем вкладку Diagram (Диаграмма) и установите переключатель Label (Название) в группе переключателей Stereotype display (Отображение стереотипов).
Использование шаблонов
Шаблоны проектирования (design patterns) содержат решения общих проблем при проектировании программ. Шаблоны проектирования используются в системе при решении вопросов «как». Говоря словами Грейди Буча, «шаблоны — это круто»[16]. Они позволяют повторно использовать удачные решения в области проектирования и архитектуры. Благодаря этому можно получить более простые в обслуживании системы и повысить производительность труда. Как и другие классы, создаваемые на этом этапе жизненного цикла, классы, составляющие шаблоны, добавляются в модель и на диаграмму классов. Например, шаблон абстрактный конструктор (Abstract Factory) может использоваться для получения объектов пользователь (RegistrationUser) различного типа. На сегодняшний день издано много книг с описанием шаблонов проектирования. Одна из наиболее популярных — книга Е. Гаммы (Е. Gamma) «Шаблоны проектирования: элементы многократно используемых объектно-ориентированных программ» (Design Patterns: Elements of Reusable Object-Oriented Software), выпущенная издательством Addison-Wesley в 1995 году.
Проектирование отношений
На этапе проектирования отношений должны быть приняты решения относительно следующих вопросов: направленность (navigation), содержание (containment), уточнение (refinement) и реализация мощности (multiplicity implementation).
Направленность
Ассоциации и агрегации являются двунаправленными отношениями. Во время проектирования ассоциативные связи проверяются, чтобы выяснить, действительно ли нужна двунаправленность. По возможности отношения создаются однонаправленными (то есть проходимыми в одну сторону) — их так легче реализовать и поддерживать.
Для указания направленности отношения в программе Rational Rose:
1. Щелкните правой кнопкой мыши по линии ассоциативной или агрегаци-онной связи.
2. В появившемся контекстно-зависимом меню выберите команду Navigation (Направленность), чтобы изменить направленность отношения.
Некоторые однонаправленные ассоциации показаны на рис. 12.3.
Рис. 12.3. Направленность отношений
Содержание
В модели также необходимо определить тип содержания в агрегационном отношении. Содержание может быть реализовано по значению или по ссылке. Первое предполагает эксклюзивное владение для содержащего класса (агрегата) и изображается в виде закрашенного ромба. Второе не предполагает эксклюзивного владения и изображается в виде незакрашенного ромба.
Для указания типа агрегационного содержания в программе Rational Rose:
1. Дважды щелкните по линии агрегационной связи, чтобы открыть диалоговое окно настройки параметров отношения.
2. Выберите вкладку Detail (Детально) для роли, представляющей «целое» в агрегации.
3. Установите нужный тип содержания в группе переключателей Containment (Содержание).
4. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно.
Отношение с содержанием по значению (класс параметры курса преподавателя (ProfessorCourseOptions) содержит класс добавление учебного курса (AddACourseOffering)) и отношение с содержанием по ссылке (отношение класса параметры курса преподавателя (ProfessorCourseOptions) к классу список доступных идентификаторов (ValidlDList)) показаны на рис. 12.4.
Рис. 12.4. Содержание
Уточнение
На данном этапе ассоциативные отношения могут быть преобразованы в отношения зависимости (dependency relationship). Они означают следующее: объект, запросивший услугу (клиент) у другого объекта (поставщика услуги), не имеет представления о расположении объекта-поставщика.
Ему необходимо сообщить, где находится объект-поставщик. Обычно объект-поставщик передается как параметр в один из методов класса-клиента или объявляется локально в области действия метода класса-клиента. Отношения зависимости изображаются пунктирной стрелкой, направленной от клиента к поставщику.
Последовательность создания отношений зависимости в программе Rational Rose:
1. Щелкните по кнопке Dependency Relationship (Отношение зависимости) на панели инструментов.
2. Щелкните по классу, выступающему в качестве клиента.
3. Перетащите линию связи к классу-поставщику.
Отношение зависимости между классами учебный курс (CourseOffering) и учебный курс БД (DBCourseOffering) показано на рис. 12.5.
Рис. 12.5. Отношение зависимости
Реализация мощности отношений
Мощность отношения со значением, равным единице, реализуется в виде встроенного объекта, ссылки или указателя. Мощность со значением больше единицы обычно реализуется с использованием класса-контейнера (то есть множества или списка). В этом случае список также может быть либо встроенным объектом, либо указателем на класс-контейнер. Решение об обновлении модели (чтобы показать все используемые классы-контейнеры) зависит от самого проекта.
Я обычно не показываю все контейнеры, чтобы не усложнять диаграмму. Вместо этого я устанавливаю параметры генерации кода в программе Rational Rose для выбора правильного контейнера.
Проектирование отношений в задаче регистрации учебных курсов
Для сценария Добавление курса для преподавания (Add a Course to Teach) должны быть спроектированы следующие отношения:
? отношение классов параметры курса преподавателя (ProfessorCourse Options) и добавление учебного курса (AddACourseOffering);
? отношение классов параметры курса преподавателя и список доступных идентификаторов (ValidlDList);
? отношение классов добавление учебного курса и предмет (Course);
? отношение классов предмет и учебный курс (CourseOffering);
? отношение классов учебный курс и преподаватель (Professor);
? отношение классов учебный курс и учебный курс БД (DBCourseOffering).
Отношение классов «параметры курса преподавателя» и «добавление учебного курса»
Как отмечалось ранее, реальный состав класса добавление учебного курса зависит от выбранных элементов пользовательского интерфейса. Проектировщики решили использовать отношение агрегации с содержанием по значению между классами, потому что время жизни окон взаимозависимо. Отношение направлено от класса добавление учебного курса к классу предмет.
Отношение классов «параметры курса преподавателя» и «список доступных идентификаторов»
Класс список доступных идентификаторов используется во многих окнах для проверки правильности указанного имени пользователя. Проектировщики решили использовать однонаправленную ассоциацию от класса параметры курса преподавателя к классу список доступных идентификаторов.
Отношение классов добавление «учебного курса» и «предмет»
Это также класс пользовательского интерфейса. Проектировщики решили использовать отношение, направленное от класса добавление учебного курса к классу предмет.
Отношение классов «предмет» и «учебный курс»
Это отношение направлено в одну сторону — от класса предмет к классу учебный курс. Кроме того, это агрегационное отношение с содержанием по значению, так как все взаимодействия с классом учебный курс проходят через класс предмет.
В данном проектном решении предполагается, что классы предмет и учебный курс взаимозависимы. В соответствии со сценарием так и должно быть. Но давайте рассмотрим получение выписки для студента. Если класс выписка
(Transcript) — это всего лишь указатель на учебные курсы, которые прослушал студент, то такая схема не подойдет. Классы предмет и учебный курс в этом случае будут существовать независимо (и агрегация должна быть реализована по ссылке). Таким образом, всегда есть отношения, которые могут видоизменяться при появлении новых сценариев.
Отношение классов «учебный курс» и «преподаватель»
Проектное решение, основанное исключительно на данном сценарии, показывает, что отношение между классами учебный курс и преподаватель должно быть отношением зависимости. Это видно из того, что объект преподаватель является параметром операции добавить преподавателя (addProfessor) класса учебный курс. Однако есть и другой сценарий для этого прецедента — просмотр расписания (Review schedule). Здесь объект преподаватель должен «знать» связанные с ним объекты учебный курс. Следовательно, отношения зависимости не будет. Кроме того, сценарий Создание каталога (Create catalog) требует, чтобы каждый класс учебный курс был проинформирован о назначенном преподавателе. На основе этих сведений можно заключить, что отношение не меняется — это двунаправленная ассоциация.
Отношение классов «учебный курс» и «учебный курс» БД
Это отношение может стать отношением зависимости, потому что объект учебный курс БД передается объекту учебный курс как параметр при вызове операции сохранения.
Обновленные диаграммы классов, выполненные при проектировании решения для отношений, показаны на рис. 12.6 и 12.7. Эти решения, возможно, претерпят изменения при добавлении прецедентов и сценариев.
Рис. 12.6. Обновленная главная диаграмма классов для пакета Интерфейс
Рис. 12.7. Обновленная диаграмма классов
Проектирование атрибутов и операций
Во время анализа достаточно указать только имена для атрибутов и операций. На этапе проектирования для атрибутов необходимо указать типы данных и начальные значения, а для операций — сигнатуры. Тип данных для атрибута может определяться языком программирования. Это может быть, например, целочисленный (integer) тип либо более сложный — строка (string) из библиотеки классов. Если требуется инициализация атрибута начальным значением при создании объекта класса, то эти сведения также помещаются в класс. В терминах методологии сигнатура операции включает список параметров (parameter list) и возвращаемый класс (return class). Для параметров и возвращаемого класса также должны быть указаны типы данных. Для атрибутов и операций необходимо определить тип доступа: общедоступный (public), защищенный (protected) или скрытый (private). Атрибуты обычно скрыты, тогда как операции могут быть скрытыми или общедоступными. Если класс является частью иерархии наследования, атрибуты и операции могут быть объявлены как защищенные, чтобы к ним получили доступ классы-потомки.
Чтобы установить типы данных и начальных значений атрибутов в программе Rational Rose:
1. Щелкните правой кнопкой мыши по классу в списке браузера или по диаграмме.
2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Открыть параметры).
3. Выберите вкладку Attributes (Атрибуты).
4. Щелкните по полю ввода начального значения или типа данных для перехода в режим редактирования.
5. Введите нужный тип данных или начальное значение атрибута.
Последовательность определения сигнатур операций в программе Rational Rose:
1. Щелкните правой кнопкой мыши по классу в списке браузера или по диаграмме.
2. В появившемся контекстно-зависимом меню выберите команду Open Specification (Открыть параметры). Откроется диалоговое окно Class Specification (Параметры класса).
3. Выберите вкладку Operations (Операции).
4. Дважды щелкните по операции, чтобы вызвать диалоговое окно Operation Specification (Параметры операции).
5. Укажите возвращаемый класс на вкладке General (Общие).
6. Выберите вкладку Detail (Детально).
7. Щелкните правой кнопкой мыши по списку Arguments (Аргументы).
8. В появившемся контекстно-зависимом меню выберите команду Insert (Добавить). В список аргументов будет добавлен новый аргумент. Укажите для него имя, тип данных и значение по умолчанию.
9. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно Operation Specification.
10. Щелкните по кнопке ОК, чтобы закрыть диалоговое окно Class Specification.
11. Чтобы получить сигнатуру операции на диаграмме классов, воспользуйтесь настройкой параметров отображения, выбрав команду меню Tools => Options (Сервис => Параметры).
12. Чтобы вывести сигнатуру операции только для определенных классов, выделите нужные классы и выберите команду меню Format => Show Operation Signature (Формат => Показать сигнатуру операции).
Атрибуты и операции классов можно также указать непосредственно на диаграмме классов, выбрав нужный элемент и воспользовавшись следующим форматом: атрибут: тип = начальное значение
операция (аргумент: тип = значение по умолчанию): возвращаемый класс
Некоторые операции и атрибуты для задачи регистрации учебных курсов показаны на рис. 12.8.
Рис. 12.8. Атрибуты и операции на уровне проектирования
Проектирование наследования
Во время анализа были определены иерархии наследования для ключевых абстракций. На этапе проектирования эти иерархии дорабатываются, чтобы:
? повысить степень повторного использования;
? добавить классы уровня проектирования;
? добавить классы из выбранных библиотек.
Диаграммы, созданные в ходе анализа, просматриваются для выявления общности атрибутов, операций и отношений. Для вновь обнаруженных общих элементов определяются суперклассы. Это уменьшает общий объем кода и способствует тому, что одно и то же свойство не будет проявляться по-разному в различных классах, если оба класса наследуют его из общего суперкласса.
Проектирование и генерация кода
Последний шаг на стадии проектирования версии — добавление методов, необходимых каждому классу С++, например конструкторов, деструкторов, копирующих конструкторов. Их можно добавить вручную, но это достаточно трудоемко. Поэтому средства генерации кода в программе Rational Rose позволяют добавлять методы такого типа.
Программа Rational Rose содержит разные средства для генерации кода. Код формируется на основе информации, полученной из диаграмм, спецификаций и параметров, указанных в свойствах генерации кода для всех элементов каждого типа. Подробное руководство по созданию кода в Rational Rose представлено в приложениях.
Кодирование, тестирование и документирование версии
Один из заключительных шагов в построении версии — реализация содержания методов на выбранном языке программирования. В этом процессе используются диаграммы взаимодействий, потому что они отражают следующую информацию: кто сделал, что сделал — для кого и когда.
Тестирование представляет собой очень важную составляющую интерактивного и инкрементального жизненного цикла. В ходе анализа и проектирования появляются планы и процедуры тестирования. Для этих целей используются прецеденты, так как они описывают то, что система должна выполнять. Версию нужно протестировать на предмет выполнения задач, определенных в прецедентах. Новые версии также объединяются с предыдущими версиями — вас не интересует готовность всей системы, чтобы собрать их вместе. Версия оценивается для того, чтобы выяснить, устраняет ли она связанные с ней риски. Все неустраненные риски (а также вновь появившиеся) присваиваются следующей версии.
Решения, принятые относительно проектирования версий, отражаются в моделях версий. Эта информация используется для получения документации, которая должна составляться итеративным образом. Я обнаружила, что системы, требующие завершения проекта, чтобы приступить к документированию, редко имеют хорошую документацию (очень часто ее нет совсем).
Использование возвратного проектирования для подготовки очередной версии
В ходе реализации текущей версии модель необходимо обновить, чтобы отразить в ней все изменения, выполненные в коде (добавленные методы или новые классы). Вместо обновления вручную можно воспользоваться возвратным проектированием (reverse engineering) программы Rational Rose, позволяющим получить модель на основе реализации. Эта информация может быть добавлена к уже существующей модели. Подробное руководство по средствам возвратного проектирования в программе Rational Rose 2000 представлено в приложениях.
Резюме
План выпуска версий содержит расписания для каждого шага развития системы. Сценарии, созданные в процессе анализа, являются основными входными данными на этой стадии разработки. Сценарии изучаются и сортируются согласно степени риска, важности для заказчика и потребности в первоочередной разработке определенных базовых сценариев.
После выпуска очередной версии риски переоцениваются, и план проекта при необходимости обновляется.
На ранних стадиях жизненного цикла проекта для граничных классов системы создаются пустые классы, после чего они должны быть доработаны. В них нужно внести данные о количестве и расположении окон, а также создать обработчики событий, поступающих от пользователей. Классы обычно добавляются в модель, чтобы была точная информация о том, как реализовать что-либо в системе. Шаблоны позволяют повторно использовать удачные решения в области проектирования и архитектуры. Это способствует созданию более простых в обслуживании систем и повышению производительности труда. Как и другие классы, создаваемые на этом этапе жизненного цикла, классы, составляющие шаблоны, добавляются в модель и на диаграмму классов. На этапе проектирования для отношений должны быть определены следующие параметры: направленность, содержание, уточнение и реализация мощности; для атрибутов — типы данных и начальные значения, для операций — сигнатуры. Диаграммы, полученные в ходе анализа, просматриваются для определения наследования. Операции в иерархии наследования изучаются для выявления полиморфизма. При его обнаружении операция объявляется виртуальной (virtual) или чисто виртуальной (pure virtual).
Последний шаг на стадии проектирования версии — добавление методов, необходимых каждому классу (например, конструкторов, деструкторов или копирующих конструкторов, если выбран язык программирования С++). В программе Rational Rose 2000 предусмотрены средства для формирования кода. Код генерируется на основе информации, полученной из диаграмм, спецификаций и параметров, указанных в свойствах генерации кода для всех элементов каждого типа.
На заключительном этапе реализуется содержание методов средствами выбранного языка программирования. Каждая версия должна быть протестирована и описана в документации, только после этого ее можно считать завершенной. Версия оценивается, и все неустраненные риски присваиваются следующей версии.
Данный текст является ознакомительным фрагментом.