Разработка информационной системы "РЖД"

Разработка объектно-ориентированной модели железнодорожной информационной системы с использованием языка UML. Диаграмма последовательности для варианта "Забронировать билет". Главная особенность диаграммы кооперации. Генерация программного кода С++.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 30.06.2015
Размер файла 2,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Содержание

Введение

Глава 1. Постановка задачи

1.1 Описание предметной области

1.2 Выбор среды реализации

Глава 2. Разработка информационной системы «РЖД

2.1 Диаграмма вариантов использования

2.2 Диаграмма последовательности

2.3 Коопертивная диаграмма

2.4. Диаграмма классов

2.5 Диаграмма компонентов

2.6 Диаграмма размещения

2.7 Генерация программного кода С

2.8 Rational Rose Data Modeler

2.9 Rational Rose и SQL Server

Заключение

Библиографический список

Приложение

Введение

UML - Унифицированный язык моделирования представляет собой язык визуального моделирования, разработанный для спецификации, визуализации, проектирования и документирования как компонентов программного обеспечения, так и бизнес-процессов и многих других систем. Язык UML одновременно является мощным и простым средством моделирования, который эффективно используется для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения.

Целью курсового проекта является разработка объектно-ориентированной модели железнодорожной информационной системы с использованием языка UML.

Для реализации данной задачи в качестве среды разработки информационной системы был использован программный продукт Rational Rose 2000 Enterprise v6.5.

Глава 1. Постановка задачи

Необходимо смоделировать информационную систему «РЖД». Данная система предоставляет возможность пользователям:

1. Забронировать билет через интернет;

2. Забронировать билет через кассу:

купить билет;

узнать о расписании движения поездов;

узнать о возможности пересадки.

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

При проектировании модели информационной системы должны быть созданы:

диаграмма вариантов использования;

диаграмма последовательности;

кооперативная диаграмма;

диаграмма классов;

диаграмма компонентов;

диаграмма размещения.

1.1 Описание предметной области

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

Основные направления коммерческой деятельности компании - грузовые и пассажирские перевозки. Доля РЖД в грузообороте транспортной системы РФ составляет около 42 %, в пассажирообороте - около 33 %

1.2 Выбор среды реализации

Rational Rose - CASE-средство визуального моделирования объектно-ориентированных информационных систем, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Гради Буча, Джеймса Рамбо и Айвара Джекобсона. Работа продукта основана на унифицированном языке моделирования.

Унифицированный язык моделирования (Unified Modeling Language) - язык визуального моделирования, предназначенный для спецификации, визуализации и документирования объектно-ориентированных систем и бизнес-процессов во время их проектирования и разработки.

С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей: семантики и нотации.

Семантика (semantics) - система правил и соглашений, определяющих толкование и придание смысла конструкциям некоторого языка.

Нотация (notation) - система условных обозначений, принятая в некотором языке для изображения и визуализации модели.

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

Глава 2. Разработка информационной системы «РЖД»

2.1 Диаграмма вариантов использования

Диаграмма вариантов использования определяет поведение системы с точки зрения пользователя.

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

Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. Действующее лицо (actor) - это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. Действующие лица делятся на три основных типа - пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.

Разрабатывая диаграммы Вариантов использования нужно придерживаться следующих правил:

не моделировать связи между действующими лицами;

не соединять стрелкой непосредственно два варианта использования;

каждый вариант использования должен быть инициирован действующим лицом.

Диаграмма вариантов использования для информационной системы РЖД выглядит следующим образом:

Рисунок 1. Диаграмма вариантов использования

На этой диаграмме одно действующее лицо. Существует также пять основных действий, выполняемых моделируемой системой:

забронировать билет,

забронировать билет On-Line ,

купить билет,

узнать о возможности движения с пересадкой,

узнать расписание движения поездов.

На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами.

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

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

2.2 Диаграмма последовательности

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

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

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

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

В данной диаграмме действующее лицо -Магомедова С.К., а объекты - сайт РЖД, личный расчетный счет, база данных РЖД. Магомедова С.К. выбирает маршрут и дату отправления.

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

Диаграмма Последовательности для варианта использования «Забронировать билет On-Line»

Рисунок 3. Диаграмма последовательности для варианта использования «Забронировать билет On-Line»

Магомедова С.К. регистрируется на сайте РЖД, выбирает маршрут, желаемое место и дату, далее происходит обращение к БД РЖД, она определяет наличие заданного билета.

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

Диаграмма Последовательности для варианта использования «Купить билет».

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

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

Диаграмма Последовательности для варианта использования «Узнать расписание движения поездов».

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

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

Диаграмма Последовательности для варианта использования «Узнать о возможности пересадки».

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

В этой диаграмме действующим лицом является Магомедова С.К., а объектами: экран, менеджер транзакций, БД РЖД. Магомедова С.К. инициализирует экран, далее происходит ввод транзакции, обращение к менеджеру транзакций, а затем к базе данных РЖД. База данных осуществляет поиск возможных поездов для пересадки и осуществляет вывод информации на экран.

2.3 Кооперативной диаграммы

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

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

В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. На этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров. Следовательно, если необходимо явно специфицировать взаимосвязи между объектами в реальном времени, лучше это делать на диаграмме последовательности. Кооперативные диаграммы создаются практически одновременно с диаграммами Последовательности. Достаточно нажать функциональную клавишу F5. Кооперативная диаграмма для варианта использования «Забронировать билет On-Line».

Рисунок 7. Кооперативная диаграмма для варианта использования «Забронировать билет On-Line»

Кооперативная диаграмма для варианта использования «Забронировать билет».

Рисунок 8. Кооперативная диаграмма для варианта использования «Забронировать билет»

Кооперативная диаграмма для варианта использования «Купить билет».

Рисунок 9. Кооперативная диаграмма для варианта использования «Купить билет»

Кооперативная диаграмма для варианта использования «Узнать расписание движения поездов».

Рисунок 10. Кооперативная диаграмма для варианта использования «Узнать расписание движения поездов»

Кооперативная диаграмма для варианта использования «Узнать о возможности пересадки»

Рисунок 11. Кооперативная диаграмма для варианта использования «Узнать о возможности пересадки»

Как видно из рисунков 7,8,9,10,11, здесь представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее уяснить последовательность событий.

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

2.4 Диаграммы классов

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

Для моделируемой системы диаграмма классов выглядит следующим образом:

Рисунок 12. Диаграмма классов «ИС РЖД»

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

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

Атрибут - это элемент информации, связанный с классом. Из диаграммы видно, например, атрибут класса ID является закрытым, т.е. он не виден никаким другим классам. Остальные атрибуты этого класса - видимые.

Операции реализуют связанное с классом поведение. Операция включает три части - имя, параметры и тип возвращаемого значения.

Таким образом, диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними.

2.5 Диаграммы компонентов

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

Диаграмма компонентов, показывает, как выглядит модель на физическом уровне. Выбрав в качестве языка программирования С++, для каждого класса созданы соответствующие этому языку компоненты.

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

Рисунок 13. Диаграмма компонентов ИС РЖД

Главный компонент, который фактически управляет остальными это Сервер РЖД.

Каждый компонент состоит из двух частей:

1. Спецификация - это заголовочный файл для сведений о прототипах функций для класса (не закрашенная часть);

2. Тело пакета - часть, которая содержит код операции класса (закрашенная часть).

Диаграмма компонентов показывает, как выглядит модель на физическом уровне.

2.6 Диаграмма размещения

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

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

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

Рисунок 14. Диаграмма размещений

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

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

2.7 Генерация программного кода С++

Язык C++ является одним из наиболее широко применяемых на практике объектно-ориентированных языков. В Rational Rose 2000 предусмотрена возможность генерации программного кода C++, а также интеграции с языком Visual C++ v6 компании Microsoft. Для генерации программного кода на стандартном C++ необходимо:

создать компоненты;

определить компоненты для классов;

установить свойства генерации программного кода;

выбрать класс или компонент для генерации на диаграмме классов или компонентов; железнодорожный информационный билет программный

для генерации выбрать Tools > C++ > Code Generation;

выбрать в меню Tools > C++ > Browse Header или Browse Body для просмотра сгенерированного программного кода.

В C++ создание компонентов для классов (файла реализации и заголовочного файла) является необязательным. Rational Rose генерирует файлы *. cpp и *. h для каждого класса. Тем не менее, настоятельно рекомендуется создавать компоненты, что позволит управлять отображением классов на компоненты и моделировать зависимости между компонентами.

При генерации с помощью Rational Rose 2000 программного кода Visual C++ применяется программа-мастер. Для запуска этого мастера необходимо выбрать Tools > Visual C++ Update Code, после чего стартует инструментальное средство обновления.

Для генерации программного кода Rational Rose 2000 выбирает нужные для генерации кода сведения из всех данных, вводимых в окнах спецификации различных элементов модели.

Ниже представлен листинг сгенерированного программного кода на языке С++:

#include "База данных РЖД.h"

{

//##ModelId=5550A1B00063

База данных РЖД::add ticket()

};

{

//##ModelId=5550A60C0296

База данных РЖД::proverit reis()

};

{

//##ModelId=5550A76D0361

База данных РЖД::proverit nalichie svobodnyh mest()

};

{

//##ModelId=5550A791004A

База данных РЖД::opname()

};

#ifndef БАЗА_ДАННЫХ_РЖД_H_HEADER_INCLUDED_AAAE103A

#define БАЗА_ДАННЫХ_РЖД_H_HEADER_INCLUDED_AAAE103A

//##ModelId=55509E470079

class База данных РЖД : public Менеджер транзакции

{

public:

//##ModelId=5550A1B00063

add ticket();

//##ModelId=5550A60C0296

proverit reis();

//##ModelId=5550A76D0361

proverit nalichie svobodnyh mest();

//##ModelId=5550A791004A

opname();

//##ModelId=5550A1EA011F

Tip Poezda;

//##ModelId=5550A1FF00EE

Class;

//##ModelId=5550A7D3036A

Data;

private:

//##ModelId=5550A1D60361

Time;

};

#endif /* БАЗА_ДАННЫХ_РЖД_H_HEADER_INCLUDED_AAAE103A */

#include "Касса РЖД.h"

{

//##ModelId=5550D59503E5

Касса РЖД::zapros dannyh o schete()

};

{

//##ModelId=5550D5B10134

Касса РЖД::zapros klassa i vagona()

};

{

//##ModelId=5550D5D001A5

Касса РЖД::vidacha kvitanciy()

};

#ifndef КАССА_РЖД_H_HEADER_INCLUDED_AAAE541C

#define КАССА_РЖД_H_HEADER_INCLUDED_AAAE541C

//##ModelId=55509D91035C

class Касса РЖД

{

public:

//##ModelId=5550D59503E5

zapros dannyh o schete();

//##ModelId=5550D5B10134

zapros klassa i vagona();

//##ModelId=5550D5D001A5

vidacha kvitanciy();

//##ModelId=5550D6040295

Name;

//##ModelId=5550D62B022C

Marshrut;

//##ModelId=5550D63A01FD

Tip poezda;

//##ModelId=5550D64601C5

Class;

private:

//##ModelId=5550D61D00A5

Identification number;

};

#endif /* КАССА_РЖД_H_HEADER_INCLUDED_AAAE541C */

#include "Менеджер транзакции.h"

{

//##ModelId=5550AAAE0214

Менеджер транзакции::Formirovanie zaprosa()

};

{

//##ModelId=5550AAC70076

Менеджер транзакции::Otpravka zaprosa()

};

{

//##ModelId=5550AAD702CC

Менеджер транзакции::opname()

};

{

//##ModelId=5550C900032D

Менеджер транзакции::podtverzhdenie polucheniya bileta()

};

{

//##ModelId=5550CB7B0117

Менеджер транзакции::Vidacha kvitancii na poluchenie()

};

#ifndef МЕНЕДЖЕР_ТРАНЗАКЦИИ_H_HEADER_INCLUDED_AAAE0F5B

#define МЕНЕДЖЕР_ТРАНЗАКЦИИ_H_HEADER_INCLUDED_AAAE0F5B

//##ModelId=55509E7700C8

class Менеджер транзакции

{

public:

//##ModelId=5550AAAE0214

Formirovanie zaprosa();

//##ModelId=5550AAC70076

Otpravka zaprosa();

//##ModelId=5550AAD702CC

opname();

//##ModelId=5550C900032D

podtverzhdenie polucheniya bileta();

//##ModelId=5550CB7B0117

Vidacha kvitancii na poluchenie();

private:

//##ModelId=5550CBA303AB

Spiski;

//##ModelId=5550CBC601E5

Kontactnaya informaciya;

};

#endif /* МЕНЕДЖЕР_ТРАНЗАКЦИИ_H_HEADER_INCLUDED_AAAE0F5B */

#include "Экран.h"

{

//##ModelId=5550CC8F0176

Экран::Inicializaciya ekrana()

};

{

//##ModelId=5550CD9B00CD

Экран::Vvjod tranzakcii()

};

{

//##ModelId=5550CDE1025D

Экран::Vvod nachalnih dannih()

};

{

//##ModelId=5550CF650065

Экран::Vibor marshruta, reisa, tipa vagona()

};

#ifndef ЭКРАН_H_HEADER_INCLUDED_AAAE05C4

#define ЭКРАН_H_HEADER_INCLUDED_AAAE05C4

//##ModelId=55509E64005A

class Экран

{

public:

//##ModelId=5550CC8F0176

Inicializaciya ekrana();

//##ModelId=5550CD9B00CD

Vvjod tranzakcii();

//##ModelId=5550CDE1025D

Vvod nachalnih dannih();

//##ModelId=5550CF650065

Vibor marshruta, reisa, tipa vagona();

//##ModelId=5550CFA20276

Name;

//##ModelId=5550D38F0395

Destination;

//##ModelId=5550D399017D

Data;

private:

//##ModelId=5550CFAA003D

Identification number;

};

#endif /* ЭКРАН_H_HEADER_INCLUDED_AAAE05C4 */

Rational Rose Data Modeler

Rational Rose Data Modeler это инструмент, позволяющий моделировать базы данных и внедрять их в проекты. Data Modeler использует три модели -- объектную модель, модель данных и модель хранения данных. Данный инструмент оперирует терминами унифицированного языка моделирования (Unified Modeling Language - UML) и терминами теории баз данных. Для работы с моделями необходимо понимать принципы разработки баз данных. Data Modeler поддерживает стандарт ANSI SQL 92 в следующих СУБД:

IBM DB2 MVS и UDB 5.x, 6.x и 7.0;

Oracle 7.x и 8.x;

Microsoft SQL Server 6.5, 7.0 и 2000;

Sybase Adaptive Server 12.x.

Data Modeler поддерживает связь между объектной моделью и моделью данных, трансформируя одну в другую и наоборот. При построении приложения Data Modeler использует объектную модель. Можно строить приложение, основанное на модели данных, трансформируя ее в объектную модель. Физическая база данных создается на основе модели данных. Модель данных можно создать следующими способами:

трансформировать имеющуюся объектную модель в модель данных;

применить реинжиниринг (Reverse Engineering) имеющейся базы данных или файла DDL ;

построить модель данных.

Рисунок 15. Схема модели данных

Rational Rose и SQL Server

Rational Rose поддерживает несколько СУБД, одной из которых является SQL Server. При проектировании больших систем, как правило, предполагается хранение каких-либо данных. Возникает необходимость создавать базы данных. Продукт Rational Rose предоставляет огромные возможности для этого.

Используя Data Modeler, можно создать логическую или физическую модель данных, после чего экспортировать ее в SQL Server, причем без каких-либо потерь в структуре.

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

В результате такого экспорта возникает физическая база данных SQL Server со всеми указанными при экспорте параметрами.

База данных SQL Server представлена в приложении.

Заключение

В ходе выполнения курсового проекта была смоделирована ИС «РЖД». Разработанная система наглядно демонстрирует основные преимущества визуального моделирования. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создваемых систем.

Преимущества:

данный подход позволяет ускорить процесс разработки ПО;

наглядность проектируемой модели в процессе разработки, что позволяет легко вносить изменения в модель без редактирования кода.

Данный курсовой проект позволил изучить особенности языка UML, который научил быстро составить представление о технологии, познакомиться с ней на концептуальном и понятийном уровне, а также приобрести навыки работы с пакетом программных продуктов Rational Rose.

Библиографический список

ГОСТ 34.321-96. Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными.

ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению.

ГОСТ Р ИСО/МЭК ИСО/МЭК 12207-95. Информационная технология. Процессы жизненного цикла программных средств.

Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000. - 581 с.

Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2002. - 432 с.

Буч Г. Язык UML. Руководство пользователя / Г. Буч, А. Джекобсон, Дж. Рамбо. - 2-е изд. - М.: ДМК, 2006. - 496 с.

Иванова Г. С. Технология программирования: Учебник для вузов / Г. С. Иванова. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

Леоненков А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM RATIONAL ROSE: учебное пособие/ А.В. Леоненков. 2006г

Леоненков А. В. Самоучитель UML 2 / А. В. Леоненков - СПб.: БХВ-Петербург, 2007. - 576 с.

Иванов Д. Ю. Основы моделирования на UML: Учеб. пособие / Д. Ю. Иванов, Ф. А. Новиков. - СПб.: Изд-во Политехн. ун-та, 2010. - 249с.

Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом «Вильямс», 2001. - 496 с.

Балдин, К.В. Информационные системы в экономике [Электронный ресурс]: учебное пособие/ Балдин К.В., Уткин В.Б. - Электрон. текстовые данные. - М.: Дашков и К, 2012. - 39 c. - Режим доступа: http://www.iprbookshop.ru/10922.

Гаспариан, М.С. Информационные системы и технологии. [Электронный ресурс]; учеб. пособие/ М.С. Гаспариан, Г.Н. Лихачева.- Электрон, текстовые данные.- М.: Евразийский открытый институт, 2011- Режим доступа: http://iprbookshop.ru/10680.

Дьяконов, В.П. Новые информационные технологии [Электронный ресурс]: учеб. пособие/ В.П. Дьяконов В.П.- Электрон, текстовые данные - М.: СОЛОН-ПРЕСС, 2008 - Режим доступа: http://iprbookshop.ru/8663.-

Золотов, С.Ю. Проектирование информационных систем [Электронный ресурс]: учеб. пособие/ Золотов, С.Ю. - Томск: Эль Контент,Томский государственный университет систем управления и радиоэлектроники, 2013 - Режим доступа: http://iprbookshop.ru/13965.-

Информационные системы и технологии. Часть 1, Часть 2. [Электронный ресурс]: монография/ под ред. Акутиной СП.- Электрон, текстовые данные.- Перо, Центр научной мысли, 2012.- Режим доступа: http://iprbookshop.ru/8982, 8983.

Приложение

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.