1.

Исходные данные

2
 Необходимость разработки информационной системы автоматизации для
предметной области железнодорожной пассажирской станции
2. Содержание разделов работы
Наименование Содержание работ по Трудое Срок Консультант:
разделов работы разделу мкость, выполнен
% ия
1 2 3 4 5
1 Пояснительная записка
Введение Анализ актуальности 2 14.12.20
проектируемой
информационной
системы
1 Аналитическая часть 3 14.12.20
1.1 Анализ предметной Описание 5 14.12.20
области библиотечного фонда
и требований к
информационной
системе
1.2 Постановка задачи Описание задачи 5 14.12.20
1.3 Метод разработки Описание методов 5 14.12.20
разработки
информационной
системы
1.4 Обоснование Описание проектных 5 14.12.20
проектных решений решений
2 Проектная часть 14.12.20 Шалунов А.В.
2.1 Диаграмма вариантов Описание диаграммы 5 14.12.20
использования вариантов
использования
2.2 Диаграмма классов Описание диаграммы 5 14.12.20
классов
2.3 Диаграмма Описание диаграммы 5 15.12.20
последовательности последовательности
2.4 Диаграмма Описание диаграммы 5 15.12.20
деятельности деятельности
2.5 Модель сущность Описание модели 3 15.12.20
связь сущность-связь
Заключение Вывод по результатам 2 15.12.20
работы
Список использованных 1 15.12.20
источников
Приложение Разработка диаграмм 50 20.12.20

3
СОДЕРЖАНИЕ

ВВЕДЕНИЕ................................................................................................................6
1 Аналитическая часть...............................................................................................7
1.1 Анализ предметной области..........................................................................7
1.2 Постановка задачи...........................................................................................7
1.3 Метод разработки............................................................................................9
1.3.1 StarUML...................................................................................................9
1.3.2 Visual Paradigm......................................................................................10
1.3.3 Издания продуктов................................................................................10
1.3.4 Управление требованиями...................................................................10
1.3.5 Моделирование данных........................................................................11
1.4 Обоснование проектных решений...............................................................11
2 Проектная часть.....................................................................................................12
2.1 Диаграмма вариантов использования (Use Case Diagram)........................12
2.2 Диаграмма классов (Class Diagram).............................................................14
2.3 Диаграмма последовательности (Sequence Diagram)................................18
2.4 Диаграмма деятельности (Activity Diagram)..............................................20
2.5 Диаграмма "Сущность - Связь" (Entity Relationship Diagram)..................21
ЗАКЛЮЧЕНИЕ........................................................................................................23
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ...............................................24
Приложение А. Диаграмма вариантов использования.........................................25
Приложение Б. Диаграмма классов........................................................................26
Приложение В. Диаграмма последовательности..................................................27
Приложение Г. Диаграмма деятельности..............................................................30
Приложение Д. Диаграмма «Сущность-Связь»....................................................32

4
 ВВЕДЕНИЕ

Современное развитие общества приводит к возрастанию объема и

усложнению задач, решаемых в области организации производства, процессов
планирования и анализа, финансовой работы, связей с поставщиками и
потребителями продукции, оперативное управление которыми невозможно без
организации современной автоматизированной информационной технологии.
Информационная технология направлена на целесообразное
использование информационных ресурсов и снабжение ими всех элементов
организационной структуры.
Таким образом, основная цель автоматизированной информационной
технологии - получать посредством переработки первичных данных
информацию нового качества, на основе которой вырабатываются оптимальные
управленческие решения.
Информационная технология справляется с существенным увеличением
объемов перерабатываемой информации, ведет к сокращению сроков ее
обработки и является наиболее важной составляющей процесса использования
информационных ресурсов в управлении.
Автоматизированная информационная технология непосредственно
связана с особенностями функционирования предприятия или организации.
Проектирование – один из первых этапов разработки информационной
системы. Успешное проектирование является залогом организованной,
упорядоченной, быстрой и эффективной разработки качественной
информационной системы. Проектирование включает изучение предметной
области, где будет применятся информационная система, разработку основных
концепций, компонентов информационной системы и требования к ней.
В рамках выполнения курсовой работы необходимо разработать модель
информационной системы РЖД посредством описания общих принципов
5
работы системы и с использованием диаграмм: вариантов использования,
классов, последовательности, деятельности и диаграммы «Сущность-Связь».

6
 1 Аналитическая часть
1.1 Анализ предметной области

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

требования, для этого нужно провести анализ ее предметной области, разбить
систему на подсистемы или подразделения, определить входную и выходную
информацию.
Информационная система железнодорожной пассажирской станции
обладает базами данных: пассажир, билет, вагоны, поезда, рейсы.
Основной вид деятельности – пассажирские перевозки в дальнем или
пригородном сообщении, грузоперевозки, обслуживание и ремонт подвижного
состава, обслуживание инфраструктуры, проектирование и конструкторская
деятельность.
РЖД связана с кассирами, администраторами, а также с пассажирами.
При взаимодействии с системой РЖД пассажир может забронировать
билет, посмотреть доступные рейсы, отменить бронь.
Кассир, взаимодействуя с системой продает билеты, при продаже билета
просматривает доступные на данный момент рейсы и наличие свободных мест,
а также оформляет возврат билета.
Администратор пополняет базу рейсов и просматривать статистику.
При согласовании всех деталей, происходит подтверждение и
окончательная регистрация.

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

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

системы железнодорожной пассажирской станции.
Задачи, решаемые системой, которые потребуют создания различных
объектов БД (запросов и вычисляемых полей):
7
  сбор и хранение данных;
 обработка данных;
 забронировать билет;
 купить билет;
 узнать расписание движения поездов;
Система должна хранить информацию о билетах, поездах, рейсах,
вагонах, пассажирах, а также делать отчеты о количестве проданных билетов и
их оплате для любого заданного периода времени, собирать статистику.
Железнодорожные кассы, используя данную систему должны в
автоматизированном режиме выполнять свои стандартные функции, такие как:
предоставление информации о поездах, движущихся в запрошенных
направлениях, продажа и приём возвращаемых билетов, а также система
должна выполнять статистические функции, такие как создание отчётов по
самым востребованным направлениям, самым прибыльным поездам, отчёта по
проданным и возвращённым билетам и пр.
В разрабатываемой системе должны быть автоматизированы функции
забронировать билет, отменить бронь, посмотреть доступные рейсы, а также
внесения пассажиров в клиентскую базу и сбор статистики.
Для достижения этой цели будут использоваться UML-диаграммы,
наглядно представляющие работу данной системы.
Диаграммы, разрабатываемые в курсовой работе, должны быть
следующих видов:
 Диаграмма вариантов использования (Use Case Diagram);
 Диаграмма классов (Class Diagram);
 Диаграмма последовательности (Sequence Diagram);
 Диаграмма деятельности (Activity Diagram);
 Диаграмма «Сущность-Связь» (Entity Relationship Diagram).

8
 1.3 Метод разработки

В процессе разработки курсового проекта было использовано

программное обеспечение Visual Paradigm for UML.
Диаграмма компонентов UML представляет собой полностью
статическую структурную диаграмму. Предназначается она для того, чтобы
продемонстрировать разбиение определенной программной системы на
разнообразные структурные компоненты, а также связи между ними.
В процессе разработки были разработаны следующие UML-диаграммы:
- Use Case Diagram;
- Class Diagram;
- Sequence Diagram;
- Activity Diagram;
- Entity Relationship Diagram.

1.3.1 StarUML

StarUML – программная платформа моделирования, которая

поддерживает UML (Унифицированный Язык Моделирования). Она основана
на версии UML 1.4 и поддерживает нотацию UML версии 2.0 и одиннадцать
различных типов диаграмм. Она активно поддерживает подход MDA и
концепцию профилей UML. StarUML превосходен в отношении настройки
окружения пользователя и имеет высокую степень расширяемости в том, что
касается его функциональных возможностей [10].
StarUML – многофункциональный инструмент UML, написанный на
языке Delphi, который также имеет много встроенных языков
программирования (C, C++, Java и др.). Главной особенностью программного
средства является схема обзора, которая позволяет видеть состояние проекта и
9
рисовать графики вручную, можно выбрать шаблон и изменить его под свои
потребности. Свою законченную работу (проект) можно экспортировать в
формате jpeg, wmf [11].
1.3.2 Visual Paradigm

Visual Paradigm - мощное программное обеспечение для моделирования

UML-схем, предназначенное для разработчиков. Оно предлагает полноценную
платформу, способную упростить процесс разработки и поддерживающую
такие языки, как C#.NET, VB.NET и C++.NET.
Данное ПО поставляется с инструментами моделирования баз данных и
предоставляет функции, которые пригодятся разработчикам для планирования
программного обеспечения или моделирования классов.
Кроме того, редактор потока событий позволяет отслеживать каждое
пользовательское действие в проекте моделирования варианта использования.
Он может перепроектировать диаграммы из кода и обеспечить
инженерное проектирование для разных языков программирования.

1.3.3 Издания продуктов

Более дорогие издания предоставляют больше возможностей. В ноябре

2010 года были доступны следующие издания:
Сообщество (бесплатная версия для некоммерческого использования.
Поддерживает все 14 типов диаграмм UML. Только для некоммерческого
использования.)
 Modeler;
 Professional;
 Enterprise;
 Standard.

10
 1.3.4 Управление требованиями

Visual Paradigm поддерживает управление требованиями, включая

истории пользователей, примеры использования, диаграммы требований SysML
и текстовый анализ.
Диаграмма требований SysML указывает возможность или условие,
которые должны быть доставлены в целевой системе. Способность относится к
функциям, которые система должна поддерживать.
Условие означает, что система должна иметь возможность запускать или
выдавать результат с учетом определенного ограничения. Visual Paradigm
предоставляет диаграмму требований SysML для указания и анализа
требований.

1.3.5 Моделирование данных

Visual Paradigm поддерживает как диаграммы отношений сущностей

(ERD), так и диаграммы привязки объектов (ORMD). ERD используется для
моделирования реляционной базы данных. ORMD является одним из
инструментов для отображения сопоставления между классом из объектно-
ориентированного мира и сущности в мире реляционных баз данных.

1.4 Обоснование проектных решений

Для эффективного решения поставленной задачи необходимо

соответствующее техническое обеспечение. Техническое обеспечение данного
проекта включает в себя непосредственно ЭВМ (системный блок), монитор,
клавиатуру и манипулятор типа мышь.
При выборе ЭВМ необходимо руководствоваться рядом характеристик. К

11
таким характеристикам относятся надежность, стоимость, производительность,
объем памяти и другие.
К выбираемому программному обеспечению в данном случае относятся
операционная система (ОС) и выбранная среда программирования: Visual
Paradigm for UML.

12
 2 Проектная часть
2.1 Диаграмма вариантов использования (Use Case Diagram)

Диаграммы вариантов использования описывают взаимоотношения и

зависимости между группами вариантов использования и действующих лиц,
участвующими в процессе.
Важно понимать, что диаграммы вариантов использования не
предназначены для отображения проекта и не могут описывать внутреннее
устройство системы.
Диаграммы вариантов использования предназначены для упрощения
взаимодействия с будущими пользователями системы, с клиентами, и особенно
пригодятся для определения необходимых характеристик системы. Другими
словами, диаграммы вариантов использования говорят о том, что система
должна делать, не указывая сами применяемые методы.
Вариант использования (use case)
Вариант использования описывает, с точки зрения действующего лица,
группу действий в системе, которые приводят к конкретному результату.
Варианты использования являются описаниями типичных
взаимодействий между пользователями системы и самой системой. Они
отображают внешний интерфейс системы и указывают форму того, что система
должна сделать (именно что, а не как).
Действующее лицо (actor)
Действующее лицо является внешним источником (не элементом
системы), который взаимодействует с системой через вариант использования.
Действующие лица могут быть как реальными людьми (например,
пользователями системы), так и другими компьютерными системами или
внешними событиями.
Действующие лица представляют не физических людей или системы, а их
роли. Эти означает, что, когда человек взаимодействует с системой различными
13
способами (предполагая различные роли), он отображается несколькими
действующими лицами. Например, человек, работающий в службе поддержки и
принимающий от клиентов заказы, будет отображаться в системе как «участник
отдела поддержки» и «участник отдела продаж».
Действующие лица могут иметь два типа связей с вариантами
использования:
Простая ассоциация — отражается линией между актером и вариантом
использования (без стрелки). Отражает связь актера и варианта использования.
Направленная ассоциация — то же что и простая ассоциация, но
показывает, что вариант использования инициализируется актером.
Обозначается стрелкой.
Описание варианта использования
Описания вариантов использования являются текстовыми пояснениями.
Они обычно принимают форму заметки или документа, который каким-то
образом прикрепляется к варианту использования и описывает процесс или
активность.
Все диаграммы языка являются графами специального вида, содержат
вершины (геометрические фигуры), связанные ребрами (дугами). Связи
обозначаются различными линиями на плоскости, внутри фигур пишется
текст, около вершин и связей могут изображаться некоторые графические
символы.
Каждая роль требует для себя вполне определенного сервиса
(обслуживания). Актант обычно изображается на диаграммах как “человек” с
надписью (символ человека).
Актант находится вне системы, и его внутренняя структура не
определяется. Он является источником/приемником сообщений.
Таким образом, вариант использования означает моделирование
некоторой части функциональности или поведения системы.
Вариант использования имеет имя и означает некоторую
14
последовательность действий, видимых внешнему источнику/приемнику
(актанту).
Связь между актантом и вариантом использования показывается
ассоциацией.
На диаграмме вариант использования изображается обычно эллипсом,
внутри ставится имя. Между актантами и вариантами использования
ассоциация – единственный вид связи [1].

Для данной информационной системы РЖД выделено 3 актера:

1) Пассажир
Актер «Пассажир» может забронировать билет, посмотреть доступные
рейсы, отменить бронь.
2) Кассир
Актер «Кассир» может продать билет, продать забронированный билет,
оформить возврат билета, посмотреть доступные рейсы.
3) Администратор
Актер «Администратор» может пополнять базу рейсов и просматривать
статистику.
Диаграмма вариантов использования приведена в приложении А.

2.2 Диаграмма классов (Class Diagram)

Диаграмма классов (Class diagram) - диаграмма, на которой показано

множество классов, интерфейсов, коопераций и отношений между ними.
Ее изображают в виде множества вершин и дуг. Диаграмма классов
определяет типы классов системы и различного рода статические связи,
которые существуют между ними. На диаграммах классов изображаются также
атрибуты классов, операции классов и ограничения, которые накладываются на
связи между классами. [2]
15
 Свойства представляют единое понятие, воплощающееся в двух
совершенно различных сущностях: в атрибутах и в ассоциациях.
Атрибут описывает свойство в виде строки текста внутри
прямоугольника класса.
Ассоциация – это непрерывная линия между двумя классами,
направленная от исходного класса к целевому классу. Имя свойства (вместе с
кратностью) располагается на целевом конце ассоциации.
Целевой конец ассоциации указывает на класс, который является типом
свойства. Большая часть информации в обоих представлениях одинакова, но
некоторые элементы отличаются друг от друга. В частности, ассоциация может
показывать кратность на обоих концах линии.
Кратность свойства обозначает количество объектов, которые могут
заполнять данное свойство [3].
Для данной информационной системы созданы следующие классы:
 Интерфейс пассажира;
 Пассажир;
 Билеты;
 Интерфейс кассира;
 Интерфейс администратора;
 Вагоны;
 Поезда;
 Рейсы;
 Статистика.

Класс Интерфейс пассажира, кассира, администратора и статистика

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

16
 Остальные классы имеют стереотип entity – сущностные – объекты этих
классов представляют собой блоки длительно хранимой информации,
используемые для организации баз данных и знаний, файловых систем
хранения данных различной логической структуры [4].

Рассмотрим атрибуты и операции, присущие граничному классу:

Класс Интерфейс пассажира:
 +Посмотреть доступные рейсы();
 +Забронировать билет();
 +Отменить бронь();
 -Запросить подтверждение();
 -Вывести форму ввода();
 -Подтвердить введенные данные();
 -Сформировать отчет().

Класс Интерфейс кассира:

 +Продать забронированный билет();
 +Продать билет();
 +Оформить возврат билета();
 -Вывести форму ввода();
 -Подтвердить введенные данные();
 -Запросить подтверждение();
 +Сформировать отчет();

Класс Интерфейс администратора:

 +Пополнить базу рейсов();
 -Вывести форму ввода();
 -Подтвердить введенные данные();
17
  -Запросить подтверждение();
 +Сформировать отчет().

Класс Статистика:
 -ID билета;
 +Структурировать данные().
Теперь рассмотрим подробнее атрибуты и операции, присущие
сущностным классам:
Класс Пассажир:
 -ID пассажира;
 -ФИО;
 +Добавить данные().

Класс Билет:
 -ID билета;
 -ID пассажира;
 -ID поезда;
 -ID вагона;
 -Место;
 -Цена;
 -Льготы;
 -Бронь;
 -Статус;
 +Изменить статус брони();
 +Изменить статус().

Класс Рейсы:
 -ID рейса;
18
 -ID поезда;
 -ID билета;
 -Маршрут поезда;
 -Дата;
 +Найти доступные рейсы();
 +Добавить данные().
Класс Вагоны:
 -ID вагона;
 -ID поезда;
 -Номер вагона;
 -Тип вагона;
 -Кол-во мест;
 -Занятые места;
 +Найти вагоны();
 -Найти свободные места();
 +Изменить список свободных мест().

Класс Поезда:
 -ID поезда;
 -Номер поезда;
 -Тип поезда;
 -Время прибытия;
 -Время отправления;
 +Найти поезд().
Разработанная диаграмма классов представлена в приложении Б.

2.3 Диаграмма последовательности (Sequence Diagram)

19
 Для моделирования взаимодействия объектов во времени в языке UML
используются диаграммы последовательности.
На диаграмме последовательности изображаются только те объекты,
которые непосредственно участвуют во взаимодействии.
Ключевым моментом для диаграмм последовательности является
динамика взаимодействия объектов во времени.
Графически каждый объект изображается прямоугольником и
располагается в верхней части своей линии жизни.
Линия жизни объекта (object lifeline) изображается пунктирной
вертикальной линией, ассоциированной с единственным объектом на
диаграмме последовательности.
Линия жизни служит для обозначения периода времени, в течение
которого объект существует в системе и, следовательно, может потенциально
участвовать во всех ее взаимодействиях.
Если объект существует в системе постоянно, то и его линия жизни
должна продолжаться по всей плоскости диаграммы последовательности от
самой верхней ее части до самой нижней.
В UML каждое взаимодействие описывается совокупностью сообщений,
которыми участвующие в нем объекты обмениваются между собой. Сообщение
(message) представляет собой законченный фрагмент информации, который
отправляется одним объектом другому.
Прием сообщения инициирует выполнение определенных действий,
направленных на решение отдельной задачи тем объектом, которому это
сообщение отправлено.
Таким образом, сообщения не только передают некоторую информацию,
но и требуют или предполагают выполнения ожидаемых действий от
принимающего объекта [5].
Были выделено семь сценариев работы в системе:
1. Посмотреть доступные рейсы – сценарий, когда пассажир может,
20
 найти доступные рейсы, вагоны, свободные места;
2. Забронировать билет – сценарий, когда пассажир может
забронировать билет найдя нужный рейс;
3. Отменить бронь – сценарий, когда пассажир может ранее
забронированную бронь отменить;
4. Продать забронированный билет – сценарий, когда кассир может
продать забронированный билет;
5. Продать билет – сценарий, когда кассир, посмотрев доступные
рейсы, может продать билет пассажиру;
6. Оформить возврат – сценарий, когда кассир может оформить
возврат билета;
7. Пополнить базу рейсов – сценарий, когда администратор может
пополнять базу рейсов.
Диаграммы последовательности для пассажира, кассира и
администратора представлены в приложении В.

2.4 Диаграмма деятельности (Activity Diagram)

При моделировании поведения проектируемой или анализируемой

системы возникает необходимость не только представить процесс изменения ее
состояний, но и детализировать особенности алгоритмической и логической
реализации выполняемых системой операций.
Для моделирования процесса выполнения операций в языке UML
используются диаграммы деятельности. Каждое состояние на диаграмме
деятельности соответствует выполнению некоторой элементарной операции, а
переход в следующее состояние выполняется только при завершении этой
операции.
Таким образом, диаграммы деятельности позволяют реализовать в языке
UML особенности процедурного и синхронного управления, обусловленного
21
завершением внутренних деятельностей и действий.
Основным направлением использования диаграмм деятельности является
визуализация особенностей реализации операций классов, когда необходимо
представить алгоритмы их выполнения.
В контексте языка UML деятельность (activity) представляет собой
совокупность отдельных вычислений, выполняемых автоматом, приводящих к
некоторому результату или действию (action).
На диаграмме деятельности отображается логика и последовательность
переходов от одной деятельности к другой, а внимание аналитика фокусируется
на результатах. Результат деятельности может привести к изменению состояния
системы или возвращению некоторого значения [6].
Диаграмма деятельности представляет по существу обычную блок-
схему.
На ней показываются деятельности - шаги в выполнении процесса,
изображаемые в виде прямоугольников с сопряженными дугами
горизонтальными сторонами и переходы между ними, показываемые
стрелками. Предусмотрена возможность ветвления, изображаемая в виде ромба.
На этих диаграммах можно показать распараллеливание процесса на
подпроцессы и слияние подпроцессов.
Для обозначения этих действий используются жирные горизонтальные
или вертикальные линии. Все элементы могут быть проименованы [7].
В разработанной диаграмме для пассажира, показано, что пассажир
может выбрать действие – посмотреть доступные рейсы, забронировать билет,
отменить бронь, затем происходит вывод формы для ввода, после чего система
формирует и регистрирует отчет путем подтверждения.
В разработанной диаграмме для кассира, показано, что кассир может
выбирать действие – посмотреть доступные рейсы, продать билет, оформить
возврат билета, продать забронированный билет, затем происходит вывод
формы для ввода, после чего система формирует и регистрирует отчет путем
22
подтверждения.
В разработанной диаграмме для администратора, показано, что он может
пополнить базу рейсов введя данные в форму и посмотреть статистику, затем
сформировать отчет.
Диаграмма деятельности пассажира, кассира и администратора
представлена в приложении Г.

2.5 Диаграмма "Сущность - Связь" (Entity Relationship Diagram)

Диаграммы "сущность-связь" предназначены для разработки моделей

данных и обеспечивают стандартный способ определения данных и отношений
между ними.
Фактически с помощью ERD осуществляется детализация хранилищ
данных проектируемой системы, а также документируются сущности системы
и способы их взаимодействия, включая идентификацию объектов, важных для
предметной области (сущностей), свойств этих объектов (атрибутов) и их
отношений с другими объектами (связей).
Сущность представляет собой множество экземпляров реальных или
абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.),
обладающих общими атрибутами или характеристиками.
Любой объект системы может быть представлен только одной
сущностью, которая должна быть уникально идентифицирована. При этом имя
сущности должно отражать тип или класс объекта, а не его конкретный
экземпляр.
Отношение в самом общем виде представляет собой связь между двумя и
более сущностями. Другими словами, сущности представляют собой базовые
типы информации, хранимой в базе данных, а отношения показывают, как эти
типы данных взаимоувязаны друг с другом [8].
Атрибут сущности - это именованная характеристика, являющаяся
23
некоторым свойством сущности.
Ключ сущности - это неизбыточный набор атрибутов, значения которых в
совокупности являются уникальными для каждого экземпляра сущности.
Неизбыточность заключается в том, что удаление любого атрибута из
ключа нарушается его уникальность [9].
В данной курсовой работе были созданы следующие сущности:
Пассажир, Билет, Вагоны, Рейсы, Поезда.
Их ключевыми атрибутами являются ID пассажира, ID билета, ID вагона,
ID рейса, ID поезда.
Разработанная диаграмма «Сущность-Связь» представлена в приложении
Д.

24
 ЗАКЛЮЧЕНИЕ

В процессе выполнения данной курсовой работы была реализована

информационная система железнодорожной пассажирской станции, которая
позволяет автоматизировать все действия, необходимые для её нормального
функционирования.
Для этого была изучена предметная область, а также типология UML-
диаграмм и особенности их построения для данной системы.
Кроме того, был произведен анализ некоторых существующих программ
для получения необходимого результата по поставленным задачам и выбор
самого оптимального для данного проекта варианта.
Для наглядного представления всех аспектов разработанной системы
были созданы следующие виды диаграмм: диаграмма вариантов использования,
диаграмма классов, диаграмма последовательности (для 7 сценариев),
диаграмма деятельности (для 3 пользователей) и диаграмма «Сущность-Связь».

25
 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1) UML. Диаграмма вариантов использования и правила ее построения –

Narod.ru [Электронный ресурс]. Режим доступа:
http://deryabych.narod.ru/4/4.html
2) Синтаксис и семантика основных объектов UML – koi.tspu.ru
[Электронный ресурс]. Режим доступа:
http://koi.tspu.ru/koi_books/gazizov/l12p02.htm
3) Диаграммы классов: основы UML – Src-Code.net [Электронный
ресурс]. Режим доступа: http://src-code.net/diagrammy-klassov-osnovy-uml/
4) UML – StudFiles [Электронный ресурс]. Режим доступа:
http://www.studfiles.ru/preview/2114176/page:5/
5) Диаграмма последовательности (sequence diagram) – DimDim
Software [Электронный ресурс]. Режим доступа: http://www.info-
system.ru/designing/methodology/uml/theory/sequence_diagram_theory.html
6) Диаграмма деятельности (activity diagram) – DimDim Software
[Электронный ресурс]. Режим доступа: http://www.info-
system.ru/designing/methodology/uml/theory/activity_diagramm_theory.html
7) Диаграммы UML – Библиофонд [Электронный ресурс]. Режим
доступа: http://bibliofond.ru/view.aspx?id=792249
8) Диаграммы “сущность-связь” – Interface [Электронный ресурс].
Режим доступа: http://www.interface.ru/fset.asp?Url=/case/defs5.htm
9) Диаграммы "Сущность – связь" – narod.ru [Электронный ресурс].
Режим доступа: http://veselyy89.narod.ru/Blok_2/Vopros_12.htm
10) StarUML. Руководство разработчика – StudFiles [Электронный
ресурс]. Режим доступа:: http://www.studfiles.ru/preview/2497143/
11) StarUML – Get App [Электронный ресурс]. Режим доступа:
http://get-app.ucoz.ru/load/prochee/staruml/9-1-0-523

26
27
Приложение А. Диаграмма вариантов использования

28
Приложение Б. Диаграмма классов

29
 Приложение В. Диаграмма последовательности

Рисунок В.1 – Диаграмма последовательности для пассажира «Посмотреть

доступные рейсы»

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

билет»

30
Рисунок В.3 – Диаграмма последовательности для пассажира «Отменить бронь»

Рисунок В.4 – Диаграмма последовательности для кассира «Продать

забронированный билет»

31
Рисунок В.5 –

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

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

Рисунок В.7 – Диаграмма последовательности для администратора

«Пополнить»

33
 Приложение Г. Диаграмма деятельности

Рисунок Г.1 – Диаграмма деятельности для пассажира

Рисунок Г.2 – Диаграмма деятельности для кассира

34
Рисунок Г.3 – Диаграмма деятельности для администратора

35
Приложение Д. Диаграмма «Сущность-Связь»

36