Порядок выполнения работы. Варианты индивидуального задания определяются преподавателем

Варианты индивидуального задания определяются преподавателем.

Для выполнения всех лабораторных работ предлагается единый порядок, предусматривающий следующие шаги

1. Ознакомиться с постановкой задачи и исходными данными.
2. Разработать предлагаемую в работе диаграмму
3. Реализовать разработанную диаграмму в среде Rational Rose
4. Сохранить файл модели
5. Составить отчет по проделанной работе

Начало работы с
Rational Rose Enterprise Edition

Запуск программы: Пуск -> Программы -> Rational Rose Enterprise Edition -> Rational Rose Enterprise Edition.

Интерфейс программы включает следующие элементы (рис. 1):

Рисунок 1. Главное окно Rational Rose

1. Браузер (browser) -используется для быстрой навигации по модели;
2. Панели инструментов (toolbars) - обеспечивает быстрый доступ к наиболее распространенным командам;
3. Окно диаграммы (diagram window) - используется для просмотра и редактирования одной или нескольких диаграмм UML;
4. Окно документации (documentation window) - используется для работы с документацией элементов модели;
5. Журнал (log) - применяется для просмотра ошибок и отчетов о результатах выполнения различных команд.

Браузер
Браузер - это иерархическая структура, позволяющая легко осуществлять навигацию по модели. Все добавляемые в модель элементы выводятся в окне браузера.
С помощью браузера можно:

• добавлять к модели элементы (сценарии, действующих лиц, классы, компоненты, диаграммы и т.д.);
• просматривать существующие элементы модели;
• просматривать существующие отношения между элементами модели;
• перемещать элементы модели;
• переименовывать элементы модели;
• добавлять элементы модели к диаграмме;
• связывать элемент с файлом или адресом в сети Интернет;
• группировать элементы в пакеты;
• работать с детализированной спецификацией элемента;
• открывать диаграмму.

Браузер поддерживает четыре представления (view): представление Вариантов Использования, Компонентов, Размещения и Логическое представление. Содержимое данных представлений представлено в следующей таблице:

Представление Вариантов Использования

Это представление включает в себя всех действующих лиц, все варианты использования и их диаграммы для конкретной системы. Оно может также содержать некоторые диаграммы последовательности и диаграммы коопераций. Представление Вариантов Использования - это взгляд на систему, независимый от ее реализации. Основное внимание здесь уделяется представлению высокого уровня, отображающему, что система будет делать, а не как она будет делать это.

В начале работы над проектом представление Вариантов Использования необходимо заказчикам, аналитикам и менеджерам проекта. Работая с вариантами использования, их диаграммами и документацией, они смогут прийти к соглашению о том, как должна выглядеть система на высоком уровне. Еще раз подчеркнем, что это представление рассматривает только, что именно будет делать система. Обсуждение деталей ее реализации следует оставить на будущее.
В процессе работы над проектом все члены команды могут ознакомиться с этим представлением, чтобы достичь понимания системы на высоком уровне. Документация варианта использования описывает соответствующий поток событий. С помощью этой информации специалисты по контролю качества смогут приступить к созданию тестовых программ для системы, а технические писатели - документации для пользователей. Аналитики и заказчики будут уверены, что учтены все требования. Разработчики поймут, какие высокоуровневые элементы системы предстоит создать и как будет работать ее логика.

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

Логическое представление

Логическое представление концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает их взаимодействие. Логическое представление включает в себя, помимо прочего, конкретные требуемые классы, диаграммы классов и диаграммы состояний. С их помощью разработчики могут сконструировать детальный проект создаваемой системы.

Часто разработка Логического представления осуществляется в два этапа. Сначала определяются классы анализа (analysis classes). Они не зависят от языка программирования. Создавая их в первую очередь, разработчики могут увидеть структуру системы, не углубляясь в специфические особенности конкретного языка. В языке UML для изображения классов анализа используют следующие пиктограммы:

Рисунок 2. Изображения классов

Классы анализа могут появляться также на диаграммах взаимодействия в представлении Вариантов Использования. После определения всех классов анализа каждый из них может быть преобразован в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с другой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Допустим, что это будет класс Java. Тогда для реализации того, что мы заложили в класс анализа, нам могут понадобиться два класса Java. Это значит, что отсутствует строгое соответствие между классами того и другого типа. Классы проекта изображают на диаграммах взаимодействия Логического представления системы.

В этом представлении основное внимание уделяется логической структуре системы. Мы изучаем данные и поведение системы, определяем ее составные части и исследуем взаимодействие между ними. Одной из ключевых особенностей здесь является возможность повторного использования (reuse). Тщательно соотнося данные и поведение классов, группируя классы вместе и исследуя взаимодействие между классами и пакетами, можно определить, какие из них допускают повторное использование.

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

Однако больше всего этим представлением пользуются разработчики и архитекторы. Первые выяняют, какие классы надо создавать, а также какие данные и поведение должен иметь каждый класс. Для вторых важнее всего структура системы в целом. Их задача — добиться того, чтобы архитектура системы была стабильна, но в то же время гибка настолько, чтобы адаптироваться к изменениям в требованиях. Другая задача - рассмотреть возможность повторного использования.

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

Представление Компонентов

Представление Компонентов содержит информацию о библиотеках кода, исполняемых файлах, динамических библиотеках и других компонентах моделей.
Представление Компонентов более всего используется теми участниками проекта, кто отвечает за управление кодированием, компиляцию и размещение приложения. Часть компонентов - это библиотеки кода. Остальные - динамические компоненты, например, исполняемые файлы и файлы динамических библиотек (DLL). С помощью этого представления разработчики могут понять, какие библиотеки кода были созданы и какие классы содержатся в каждом из них.