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

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 предусмотрены средства для формирования кода. Код генерируется на основе информации, полученной из диаграмм, спецификаций и параметров, указанных в свойствах генерации кода для всех элементов каждого типа.

На заключительном этапе реализуется содержание методов средствами выбранного языка программирования. Каждая версия должна быть протестирована и описана в документации, только после этого ее можно считать завершенной. Версия оценивается, и все неустраненные риски присваиваются следующей версии.