ИС продажи билетов автотранспорт

 

 

2. Общая диаграмма вариантов использования

 

 

В самом общем  виде использование системы отражено на рисунке 1:

 

 

 

 

 

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

 

 

1. Уточнённая диаграмма вариантов использования

 

 

 

Сложность системы  не позволяет обойтись общим видом, и для дальнейшей разработки необходима большая детализация, представленная на рисунке 2:

 

 

 

 

Рисунок 2. Уточнённая диаграмма вариантов  использования ИС продажа билетов автотранспорт

 

 

 

3. Диаграмма активностей Продажи билета

 

 

 

На рисунке 3 представлена диаграмма активностей продажи билета. В данной активности (варианте использования «Оформить поездку») могут быть одинаково задействованы как Пассажир, самостоятельно использующий систему посредством терминала самообслуживания, так и Кассир, работающий с Пассажиром со своего АРМ, никакие другие роли здесь больше не требуются.

 

 

 

Рисунок 3. Диаграмма активностей продажи билетов

 

 

4. Диаграмма активностей Сдачи  билета

 

 

На рисунке 4 представлена диаграмма активностей  сдачи билета. Сдать билет Пассажир может только через Кассира в  кассе возврата, все операции с  системой производит Кассир.

 

 

 

Рисунок 4. Диаграмма активностей сдачи билета

 

 

 

 

5. Диаграмма активностей Получения отчёта

 

На рисунке 5 представлена диаграмма активностей  получения отчёта. Получить отчёт  может только СлужебныйКлиент(имяРоли) формы отчётов утверждены и разрешены для определённой роли.

 

 

Рисунок 5. Диаграмма активностей получения отчёта

 

6. Диаграмма классов предметной области

 

 

Диаграмма классов моделирует отношения  ключевых объектов. Данная диаграмма представлена на рисунке 6.

 

 

 

 

 

Рисунок 6. Диаграмма классов предметной области

 

 

 

 

 

 

 

 

 

 

 

 

3. Проблемы предметной области и концепция информационной системы

1. Проблемы предметной области

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

 

1. Несвоевременная сдача отчетности сотрудниками компании. Данная проблема объясняется большим количеством затраченного времени на сбор нужной информации, для представления ее в отчете о проделанной работе компании за определенный период.
2. Затраты большого количества временных и человеческих ресурсов на обработку документов и необходимость увеличивать эти ресурсы с ростом пассажиропотоков, как следствие, время составления и обработки документов неоправданно большое
3. Существенная потеря  от  не востребования  забронированных  билетов.

 

 

2. Концепция информационной системы

1. Основные понятия

1. Клиент – внешний объект, желающий воспользоваться услугами информационной системы, согласно его роли, которая определяет в том числе и права доступа.
2. Пассажир – роль Клиента - человек, желающий совершить поездку, воспользовавшись услугами автоперевозчика.
3. Служебный клиент(Кассир) – роль Клиента, в которую входит работа с пассажиром.
4. Внешний клиент – роль Клиента, для сопряжения с внешними системами.
5. Автобус – тип автобуса с описанием параметров.
6. Рейс – утверждённый маршрут с описанием параметров.
7. Расписание – перечень всех рейсов с описанием параметров.
8. Счёт оплаты – документ, содержащий реквизиты для оплаты поездки.
9. Подтверждение оплаты – документ, подтверждающий оплату счёта.
10. Билет – документ, дающий право воспользоваться услугой перевозки с описанием параметров.
11. Отчёт – документ, содержащий требуемую пользователем информацию в требуемом пользователем виде.

 

 

 

 

2. Функциональные требования

 

Основные  требования

 

1. Автоматизированное выписывание билетов для поездки.
2. Гарантировать совершенно точную, до последней минуты скорректированную информацию о рейсах до любого пункта назначения. Это обеспечит большую доступность последних сведений о свободных местах.
3. Вся нужная информация доступна с помощью одного запроса. Быстрое и простое получение комбинированных цен для сложных рейсов в одной операции.
4. Информация доступна в интерактивном режиме, запрос производится по любым обслуживаемым направлениям, пользователь может сам забронировать или оформить покупку билетов.
5. Немедленная выписка счёта с учётом маршрута поездки
6. Автоматизированные записи, электронным путём связывающие с выбранной банковской системой.
7. Получение и сохранение данных о пассажире(«профиль заказчика»), таких, как номера контактных телефонов, паспортные данные, пожелания по поводу предстоящей поездки, оценка услуг клиентом.
8. Быстрое и простое получение любых отчётов требуемой формы по требованию сотрудников автопредприятия, в соответствии с правами доступа.

Обеспечивающие требования

К информационной системе предъявляются следующие  обеспечивающие требования:

1. Обеспечивать защиту информации от несанкционированного доступа и изменения
2. Обеспечивать проверку правильности данных
3. Обеспечить идентификацию пользователя
4. Обеспечить возможность резервного копирования данных

Вспомогательные требования

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

1. Электронные формы стандартных документов
2. Иметь удобную систему поиска и фильтрации по различным параметрам
3. Возможность печати (на принтере) отчетов, форм и электронных копий документов
4. Возможность сохранения данных, отчетов, форм в отдельный файл для отправки по факсу или электронной почтой
5. Интуитивно-понятный интерфейс пользователя.

3. Нефункциональные требования

Перечислим  основные нефункциональные требования, предъявляемые к системе:

1. Масштабируемость системы
2. Работа системы в режиме 24 часа 365 дней в году
3. Клиент серверная архитектура
4. Наличие Web-интерфейса - это позволит легко обеспечить кроссплатформенность

4. Концептуальная модель информационной системы

 

Таблица 2 - Высказывания концептуальной схемы.

Прецедент	Краткое описание
Аутентификация	Запускается Клиентом при совершении ответственных действий, позволяет  разграничить права доступа и  зафиксировать ответственность  конкретного лица.
Получить информацию (данные)	Запускается Клиентом системы, в зависимости  от роли, определённой аутентификацией, позволяет получить необходимую, разрешённую  информацию (посмотреть расписание, получить отчёт, получить данные для внешней АИС).
Забронировать	Запускается Пассажиром или Кассиром, непосредственно работающим с пассажиром, позволяет забронировать билет.
Оформить поездку (купить билет)	Запускается Пассажиром или Кассиром, непосредственно работающим с пассажиром, позволяет оформить продажу билета.
Снять бронь	Запускается Пассажиром или Кассиром, непосредственно работающим с пассажиром, позволяет снять бронь билета.
Возврат билета	Запускается Кассиром, непосредственно  работающим с пассажиром, позволяет  оформить возврат билета.
Обмен данными с БД	Запускается Системой, обеспечивает информационный обмен системы.

 

 

 

 

1. Списки ответственности

 

Определив на основе анализа функциональных требований архитектуру проектируемой  ИС, определим поведение в рамках концептуальной модели ИС. Для этого  зададим поведение системы процессом  оказания информационных услуг (в общем  случае преобразованием информации) и проанализируем его посредством  метода «черного ящика». В этом случае система предстает как один объект, на вход которого поступают входные сообщения, а на выходе, в зависимости от закона поведения, формируются выходные сообщения. Список названий выходных сообщений и вложенных в них данных или документов называют списком ответственности.[7]

 

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

 

Рисунок 7. Оформление продажи билета.

 

 

 

 

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

 

Рисунок 8. Оформление сдачи билета

 

 

1. Диаграмма классов концептуальной модели

 

Для разработки архитектуры ПО ИС, целесообразно использовать шаблон трехслойной архитектуры.[7]

Представим  основные высказывания по каждому слою архитектуры:

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

 

 

Представим  назначение классов по слоям в  таблице 3.

 

Таблица 3 – Назначение классов  концептуальной модели

 

№	Наименование класса	Назначение класса
Слой представления
	Client	Граничный класс, отвечающий за отображение  формы Клиента ИС, расписания, полей  ввода аутентификационных данных, отсылку параметров поиска и данных аутентификации.
	ClientPassenger	Граничный класс, потомок класса Client, отвечающий за отображение рабочей формы Пассажира, запуск процедур бронирования, отмены брони и покупки билета.
	ClientStaff	Граничный класс, потомок класса ClientPassenger, отвечающий за отображение рабочей формы Служебного Клиента (Кассира, Внешнего клиента), запуск процедур оформления возврата билета и получения отчёта.
Слой предметной области
	GateUI	Граничный класс, отвечающий за взаимодействие с классами слоя предметной области
	ControllerUI	Управляющий класс, методы которого отвечают за управление приложением в целом
	RulesUI	Класс хранения, содержащий данные бизнес-правил
	ControllerDB	Управляющий класс, методы которого отвечают за управление обменом данными с БД
	RulesDB	Класс хранения, содержащий данные правил работы с БД
	Timetable	Класс хранения, содержащий данные о расписании.
	Trip	Класс хранения, содержащий данные рейса.
	Bus	Класс хранения, содержащий данные автобуса.
	Ticket	Класс хранения, содержащий данные билета.
	Payment	Класс хранения, содержащий данные счёта  об оплате.
	ProofOfPayment	Класс хранения, содержащий данные документа  подтверждающего оплату.
	Report	Класс хранения, содержащий данные отчёта.
	Passenger	Класс хранения, содержащий данные пассажира.
	Staff	Класс хранения, содержащий данные служащего.
Слой источника данных
	GateDB	Граничный класс для взаимодействия с БД

 

 

 

 

 

 

 

Диаграмма классов, моделирующая структуру  ИС на концептуальном уровне, представлена на рисунке 9.

 

Рисунок 9. Диаграмма классов, моделирующая структуру ИС на концептуальном уровне

 

5. Логическая модель информационной системы

 

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

 

1. Модель поведения

Модель поведения разработана  посредством диаграмм последовательности. На рисунке 10 представлена модель поведения, моделирующая сдачу билета пассажиром через абстрактного Кассира (n).

 

Рисунок 10. Диаграмма последовательности, моделирующая сдачу билета

 

 

 

На рисунке 11 представлена модель взаимодействия, моделирующая сдачу билета пассажиром через абстрактного Кассира (n).

Рисунок 11. Диаграмма взаимодействия, моделирующая сдачу билета.

 

На рисунках 12 и 13 представлена диаграмма последовательности, моделирующая продажу билета.

 

Рисунок 12. Диаграмма последовательности, моделирующая продажу билета (начало).

 

 

Рисунок 13. Диаграмма последовательности, моделирующая продажу билета (окончание).

На рисунке 14 представлена диаграмма взаимодействия, моделирующая продажу билета:

Рисунок 14. Диаграмма взаимодействия, моделирующая продажу билета.

2. Модель структуры 

 

Представлена на рисунках 15 и 16 для более полной детализации:

Рисунок 15. Диаграмма классов, моделирующая ПО ИС на логическом уровне

 

Рисунок 16. Диаграмма классов ИС

 

6. Реализация модели в среде CASE-средства

 

 

В качестве примера реализации модели в среде Case-средства опишем процесс моделирования диаграмм логической модели ПО ИС.

 

1. Начало работы над проектом

 

 

В качестве среды разработки ИС было выбрано CASE-средство фирмы Rational Software Corporation – Rational Rose Enterprise Edition. Выбор был сделан, исходя из нижеперечисленных достоинств продукта.

Работа  продукта основана на универсальном  языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.