Варианты индивидуального задания определяются преподавателем.
Для выполнения всех лабораторных работ предлагается единый порядок, предусматривающий следующие шаги
- Ознакомиться с постановкой задачи и исходными данными.
- Разработать предлагаемую в работе диаграмму
- Реализовать разработанную диаграмму в среде Rational Rose
- Сохранить файл модели
- Составить отчет по проделанной работе
Начало работы с
Rational Rose Enterprise Edition
Запуск программы: Пуск -> Программы -> Rational Rose Enterprise Edition -> Rational Rose Enterprise Edition.
Интерфейс программы включает следующие элементы (рис. 1):
Рисунок 1. Главное окно Rational Rose
- Браузер (browser) -используется для быстрой навигации по модели;
- Панели инструментов (toolbars) - обеспечивает быстрый доступ к наиболее распространенным командам;
- Окно диаграммы (diagram window) - используется для просмотра и редактирования одной или нескольких диаграмм UML;
- Окно документации (documentation window) - используется для работы с документацией элементов модели;
- Журнал (log) - применяется для просмотра ошибок и отчетов о результатах выполнения различных команд.
Браузер
Браузер - это иерархическая структура, позволяющая легко осуществлять навигацию по модели. Все добавляемые в модель элементы выводятся в окне браузера.
С помощью браузера можно:
- добавлять к модели элементы (сценарии, действующих лиц, классы, компоненты, диаграммы и т.д.);
- просматривать существующие элементы модели;
- просматривать существующие отношения между элементами модели;
- перемещать элементы модели;
- переименовывать элементы модели;
- добавлять элементы модели к диаграмме;
- связывать элемент с файлом или адресом в сети Интернет;
- группировать элементы в пакеты;
- работать с детализированной спецификацией элемента;
- открывать диаграмму.
Браузер поддерживает четыре представления (view): представление Вариантов Использования, Компонентов, Размещения и Логическое представление. Содержимое данных представлений представлено в следующей таблице:
Представление | Содержание | |||||||
Представление Вариантов Использования |
| |||||||
Логическое представление |
| |||||||
Представление компонентов |
| |||||||
Представление размещения |
|
Представление Вариантов Использования
Это представление включает в себя всех действующих лиц, все варианты использования и их диаграммы для конкретной системы. Оно может также содержать некоторые диаграммы последовательности и диаграммы коопераций. Представление Вариантов Использования - это взгляд на систему, независимый от ее реализации. Основное внимание здесь уделяется представлению высокого уровня, отображающему, что система будет делать, а не как она будет делать это.
В начале работы над проектом представление Вариантов Использования необходимо заказчикам, аналитикам и менеджерам проекта. Работая с вариантами использования, их диаграммами и документацией, они смогут прийти к соглашению о том, как должна выглядеть система на высоком уровне. Еще раз подчеркнем, что это представление рассматривает только, что именно будет делать система. Обсуждение деталей ее реализации следует оставить на будущее.
В процессе работы над проектом все члены команды могут ознакомиться с этим представлением, чтобы достичь понимания системы на высоком уровне. Документация варианта использования описывает соответствующий поток событий. С помощью этой информации специалисты по контролю качества смогут приступить к созданию тестовых программ для системы, а технические писатели - документации для пользователей. Аналитики и заказчики будут уверены, что учтены все требования. Разработчики поймут, какие высокоуровневые элементы системы предстоит создать и как будет работать ее логика.
Согласовав варианты использования и действующих лиц, заказчики должны будут принять решение и по поводу области применения (scope) системы. После этого разработчики смогут перейти к ее Логическому представлению, уделяющему больше внимания тому, как система будет реализовывать поведение, определяемое вариантами использования.
Логическое представление
Логическое представление концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает их взаимодействие. Логическое представление включает в себя, помимо прочего, конкретные требуемые классы, диаграммы классов и диаграммы состояний. С их помощью разработчики могут сконструировать детальный проект создаваемой системы.
Часто разработка Логического представления осуществляется в два этапа. Сначала определяются классы анализа (analysis classes). Они не зависят от языка программирования. Создавая их в первую очередь, разработчики могут увидеть структуру системы, не углубляясь в специфические особенности конкретного языка. В языке UML для изображения классов анализа используют следующие пиктограммы:
Рисунок 2. Изображения классов
Классы анализа могут появляться также на диаграммах взаимодействия в представлении Вариантов Использования. После определения всех классов анализа каждый из них может быть преобразован в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с другой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Допустим, что это будет класс Java. Тогда для реализации того, что мы заложили в класс анализа, нам могут понадобиться два класса Java. Это значит, что отсутствует строгое соответствие между классами того и другого типа. Классы проекта изображают на диаграммах взаимодействия Логического представления системы.
В этом представлении основное внимание уделяется логической структуре системы. Мы изучаем данные и поведение системы, определяем ее составные части и исследуем взаимодействие между ними. Одной из ключевых особенностей здесь является возможность повторного использования (reuse). Тщательно соотнося данные и поведение классов, группируя классы вместе и исследуя взаимодействие между классами и пакетами, можно определить, какие из них допускают повторное использование.
Почти все участники команды должны изучить Логическое представление системы, однако более всего оно полезно для разработчиков и архитекторов. Взглянув на классы и их диаграммы, аналитики смогут убедиться, что все бизнес-требования будут реализованы в коде. Изучая классы, пакеты и диаграммы классов, специалисты по контролю качества поймут, из каких элементов состоит система и какие нуждаются в тестировании, а с помощью диаграмм состояний увидят, как должны вести себя конкретные классы. Менеджер проекта из тех же элементов представления сможет уяснить, хорошо ли структурирована система, а также получить оценку степени ее сложности.
Однако больше всего этим представлением пользуются разработчики и архитекторы. Первые выяняют, какие классы надо создавать, а также какие данные и поведение должен иметь каждый класс. Для вторых важнее всего структура системы в целом. Их задача — добиться того, чтобы архитектура системы была стабильна, но в то же время гибка настолько, чтобы адаптироваться к изменениям в требованиях. Другая задача - рассмотреть возможность повторного использования.
Определив классы системы и нанеся их на диаграммы, можно приступить к работе с представлением Компонентов, имеющим дело с физической структурой системы.
Представление Компонентов
Представление Компонентов содержит информацию о библиотеках кода, исполняемых файлах, динамических библиотеках и других компонентах моделей.
Представление Компонентов более всего используется теми участниками проекта, кто отвечает за управление кодированием, компиляцию и размещение приложения. Часть компонентов - это библиотеки кода. Остальные - динамические компоненты, например, исполняемые файлы и файлы динамических библиотек (DLL). С помощью этого представления разработчики могут понять, какие библиотеки кода были созданы и какие классы содержатся в каждом из них.