Проектирование в UML Rational Rose

Федеральное агентство образования Российской Федерации Дальневосточный Государственный Технический Университет Институт Радиоэлектроники Информатики и Электротехники Факультет информационных и компьютерных технологий Кафедра информационных систем управления Лабораторная работа из курса «Автоматизированная разработка АСОИУ»

на тему «Проектирование в UML Rational Rose»

Выполнили: студенты группы Р5221

Пашин С.С.

Проверил: доцент Берёзкина Г. Л.

Владивосток 2009 г.

• Содержание
• Требования заказчика
• Задание к лабораторной работе
• Выполнение лабораторной работы
• Варианты использования и действующие лица
• Взаимодействие объектов
• Диаграмма последовательности
• Диаграмма кооперативная
• Классы и пакеты
• Представление компонентов
• Представление размещения
• Генерация программного кода
• Требования заказчика
• Библиотека. Разработать информационную систему для ведения каталога книг/читателей, поисковой системы, системы предварительных заказов на приобретение книг, а так же системы предварительной записи на использование дефицитной литературы и просмотра очереди.

Задание к лабораторной работе

Разработать информационную систему в соответствии с выданным заданием.

Варианты использования и действующие лица Взаимодействие объектов Классы и пакеты Атрибуты и операции Связи Представление компонентов Представление размещения

2. Сгенерировать программный код на языке заданном преподавателем.

3. Выполнить обратное проектирование программы, заданной преподавателем, или выбранной самостоятельно.

Отчет должен содержать информацию по каждому пункту задания.

Выполнение лабораторной работы

Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат.

Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Диаграммы Взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы Классов. Диаграммы Компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец диаграммы Размещения применяют для визуализации проекта распределенных систем.

Модель Rose — это картина системы. Она содержит все диаграммы UML, действующих лиц, варианты использования, объекты, классы, компоненты и узлы системы. Она детально описывает, что система содержит и как функционирует, поэтому разработчики могут использовать ее в качестве эскиза или чертежа создаваемой системы.

Варианты использования и действующие лица Представление Вариантов Использования, как правило, не зависит от реализации модели. Варианты использования и действующие лица описывают сферу применения проекта (project scope), но не вникают в такие детали его реализации, как, например, используемый язык программирования.

Одним из основных преимуществ применения диаграммы Вариантов Использования является то, что она предоставляет важную информацию. Взглянув на варианты использования, ваши клиенты поймут, какие функциональные возможности будут заложены в систему. Рассматривая действующих лиц, они выяснят, кто конкретно будет с ней взаимодействовать. Изучая все множество вариантов использования и действующих лиц, они определят сферу применения системы, что она должна будет делать. Это поможет им узнать также, что она не будет делать, и внести коррективы. Например, взглянув на диаграмму, пользователь может сказать: «Все это прекрасно, но я хочу иметь еще возможность получать отчет о десяти последних транзакциях для моего счета» .

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

Рис. 1 Диаграмма вариантов использования Диаграмма вариантов использования показывает, основные функции системы (купить книгу, взять книгу, регистрация и т. д.), взаимодействие объектов при выполнении вышеперечисленных функций. Что даёт общее представление о системе.

информационный класс rational rose

Взаимодействие объектов Существуют два типа диаграмм Взаимодействия: диаграммы Последовательности и Кооперативные диаграммы. Оба отображают события, участвующие в процессе обработки информации варианта использования, и сообщения, которыми обмениваются объекты. События на диаграмме Последовательности упорядочены по времени, а Кооперативная диаграмма организована вокруг самих объектов. В приводимом в конце главы упражнении мы построим диаграмму Последовательности для описания потока событий варианта использования «Ввести новый заказ» нашей системы обработки заказов.

С помощью диаграмм Взаимодействия проектировщики и разработчики системы могут определить классы, которые нужно создать, связи между ними, а также операции и ответственности (responsibilities) каждого класса. Диаграммы Взаимодействия — краеугольный камень, на котором возводится оставшаяся часть проекта.

Диаграммы Взаимодействия содержат:

Объекты: Можно использовать имена как объектов, так и классов, или того и другого.

Сообщения: С помощью сообщения один объект или класс запрашивает у другого выполнения какой-то конкретной функции. Например, форма может запросить у объекта Отчет напечатать ее.

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

Составим для разрабатываемой системы три диаграммы последовательности:

· Читатель берёт книгу;

· Читатель возвращает книгу;

· Регистрация читателя.

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

«Читатель берёт книгу»

Читатель, пришедший в библиотеку, желает взять выбранную им книгу. Диаграмма последовательности для этого случая представлена на рис. 2. Выделяются пять объектов: Читатель, Работник библиотеки, Поисковая система, БД и Книга. Стрелками показаны взаимодействия этих объектов, а именно пересылка сообщениями между этими объектами, необходимых для выполнения поставленной задачи.

Рис. 2 Диаграмма последовательности для «Читатель берёт книгу»

«Читатель возвращает книгу»

Читатель, пришедший в библиотеку, желает вернуть прочитанную книгу. Диаграмма последовательности для этого случая представлена на рис. 3. Выделяются пять объектов: Читатель, Работник библиотеки, учётная запись, БД и Книга. Стрелками показаны взаимодействия этих объектов, а именно пересылка сообщениями между этими объектами, необходимых для выполнения поставленной задачи.

Рис. 3 Диаграмма последовательности для «Читатель возвращает книгу»

«Регистрация читателя»

Человек, пришедший в библиотеку желает зарегистрироваться, чтоб получать возможность брать книги для чтения домой. Диаграмма последовательности для этого случая представлена на рис. 4. Выделяются четыре объекта: Читатель, Работник библиотеки, учётная запись, БД. Стрелками показаны взаимодействия этих объектов, а именно пересылка сообщениями между этими объектами, необходимых для выполнения поставленной задачи.

Рис. 4 Диаграмма последовательности «регистрация читателя»

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

Выше мы строили диаграммы последовательности для случаев: Читатель взял книгу, читатель вернул книгу и регистрация читателя. Теперь еж приведём кооперативные диаграммы для этих же случаев (рис. 5,6,7), для отслеживания всех взаимодействий объектов.

Рис. 5 Диаграмма кооперации «Читатель берёт книгу»

Рис. 6 Диаграмма кооперации «Читатель возвращает книгу»

Рис. 7 Диаграмма кооперации «Регистрация читателя»

Классы и пакеты Объектом называют нечто, заключающее (инкапсулирующее) в себе некоторые данные и поведение. Это термин, описывающий реальные, конкретные предметы. Данные объекта называются атрибутами (attributes). Поведение объекта представляется его операциями (operations). В среде Rose объекты помещают на диаграммы Взаимодействия. Когда действующее лицо (представляющее собой стереотип класса) или какой-то другой класс переносится на диаграмму Взаимодействия, автоматически создается экземпляр объекта этого класса. Удаление объекта с диаграммы Rose не приводит к удалению класса из модели.

Класс — это некая сущность, представляющая собой как бы схему объекта. Иными словами, класс определяет данные и поведение, которыми должен обладать объект.

На языке UML такие элементы, как действующие лица, варианты использования, классы и компоненты, можно сгруппировать в пакеты (packages). В частности, в представлении Вариантов Использования можно сгруппировать в пакеты варианты использования и действующих лиц В разрабатываемой системе, не было особого смысла создавать пакеты, т.к. объём информации достаточно маленький. Основные классы представлены на рис. 8. Построив диаграммы Взаимодействия объектов, были выявлены основные операции классов и составлены необходимые атрибуты, и соответствующие атрибутам типы данных.

Рис. 8 Диаграмма классов для разрабатываемой системы Представление компонентов Компонентом (component) называется физический модуль кода. Компонентами бывают как библиотеки исходного кода, так и исполняемые файлы. Например, если вы работаете на языке C++, то файлы .СРР и .Н будут отдельными компонентами. Получающийся при компиляции исполняемый .ЕХЕ файл также является компонентом системы.

Перед началом генерации кода необходимо соотнести каждый из файлов с соответствующими компонентами. На языке C++ каждый класс соотносится с двумя компонентами, один из которых соответствует .СРР файлу этого класса, а другой — .Н файлу.

На рис. 9 представлен общий вид диаграммы компонентов, состоящей из основного исполняющего файла (main.exe) взаимодействующего с драйверами базы данных, дополнительными библиотеками и компонентами самой базы данных.

Рис. 9 Обобщённая диаграмма компонентов Представление размещения Представление Размещения (Deploymen: view). Оно отражает физическое распределение готового приложения, включая размещение и топологию сети, а также локализацию в ней компонентов системы. Рассматриваются и такие проблемы, как определение требуемой полосы пропускания сети, предполагаемого количества параллельно работающих пользователей, действий при неполадках на сервере и т. д.

Представление Размещения содержит процессоры, устройства, процессы и связи между процессорами и устройствами. Все они наносятся на диаграмму Размещения (Deployment diagram). Для системы и, следовательно, для модели Rose может быть создана только одна диаграмма Размещения.

Диаграмма размещения для разрабатываемой системы представлена на рис. 10. Сервер БД является отдельной машиной на которой стоит База данных, к примеру, Paradox. По средством сети сервер соединяется с двумя рабочими станциями, на которых установлена программа main. exe, которая производит все необходимы операции, обращаясь лишь к серверу за информацией из БД. Общим разделяющим ресурсом рабочих станций является лазерный принтер.

Рис. 10 Диаграмма размещения для разрабатываемой системы

Генерация программного кода Данный программный пакет позволяет генерировать код для большого количества языков программирования, С++, ADA, Java, Basic и т. д. Мы же буде генерировать код на языке С++.

Сгенерированные программные компоненты представлены на рис. 11.

Рис. 11 Сгенерированные программные компоненты Сгенерированный программный код для компонента «Работник_библиотеки.h» подставлен ниже.

#ifndef РАБОТНИК_БИБЛИОТЕКИ_H_HEADER_INCLUDED_C3CD2C49

#define РАБОТНИК_БИБЛИОТЕКИ_H_HEADER_INCLUDED_C3CD2C49

//##ModelId=3C32E1BA036B

class Работник_библиотеки

{

public:

//##ModelId=3C32E3D30186

Принять_заказ ();

//##ModelId=3C32E3DB000F

Регистрация_клиента ();

//##ModelId=3C32E3E3035B

Принятие_книги ();

//##ModelId=3C32E3EA00DA

Выдача_книги ();

private:

//##ModelId=3C32E4060399

string ФИО;

//##ModelId=3C32E40B004E

string Должность;

//##ModelId=3C32E40F030D

string Оклад;

};

#endif /*

РАБОТНИК_БИБЛИОТЕКИ_H_HEADER_INCLUDED_C3CD2C49 */