Модель железнодорожной информационной системы

 

Введение

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

Информационная система (ИС) в целом - автоматизированная система, предназначенная для организации, хранения, пополнения, поддержки и представления пользователям информации в соответствии с их запросами.

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем, создаваемых в различных областях деятельности человека. Rational Rose - мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language) - стандартный язык для написания моделей анализа, проектирования и реализации объектно-ориентированных программных систем. UML может использоваться для визуализации, спецификации, конструирования и документирования результатов программных проектов. UML - это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования (Java, C++, Visual Basic, Object Pascal) и даже в таблицы для реляционной БД.

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


Анализ проектирования:


Рис.

Принципиально можно выделить 2 вида разбиения предметной области на составляющие элементы:

Алгоритмическая декомпозиция (основные элементы программы - строительные блоки - алгоритмы).

Объектная декомпозиция(основные элементы программы - виды абстракций (классы) и представители этих классов (объекты)).

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

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



Постановка задачи


Цель курсовой работы является закрепление теоретического материала дисциплины «Программные средства моделирования в САПР», а также приобретение навыков практического объектно-ориентированного проектирования информационных систем в среде Rational Rose.

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

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

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

.Купить билет;

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

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

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

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

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

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

.Кооперативную диаграмму;

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

.Диаграмму состояний;

.Диаграмму компонентов;

.Диаграмму размещения.



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


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

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

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

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

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

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

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

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


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


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

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

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


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


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

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

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



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

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

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

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


Рис.


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


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

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

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



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


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

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


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


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

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


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

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


Создание кооперативной диаграммы


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

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

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


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


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


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

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


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


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


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


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


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


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

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


Создание диаграммы классов


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

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


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


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

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

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

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

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


Создание диаграммы состояний


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

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

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

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


Создание диаграммы компонентов


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

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

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


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


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

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

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

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

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


Создание диаграммы размещения


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

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

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


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


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

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



Заключение


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

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

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

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

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



Список литературы


1.Скоз Е.Ю. Программные средства моделирования в САПР. Конспект лекций.

.У. Боггс, М. Боггс «UML и Rational Rose 2002» - Издательство «ЛОРИ», 2004.;


Введение информационный технология проектирование железнодорожный Информационная система (ИС) в целом - автоматизированная система, предназначенная для ор

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ