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

МІНІСТЕРСТВО ОСВІТИ І НАУКИ

Національний аерокосмічний університет ім. М.Є. Жуковського “ХАІ”

Факультет економіки та менеджменту

Кафедра інженерії програмного забезпечення

КУРСОВИЙ ПРОЕКТ

з дисципліни: Програмне забезпечення корпоративних інформаційних систем

на тему: Програмне забезпечення для тарифікація міжнародних розмов з урахуванням історії абонентів

Студента

Чепурко Р.В.

Керівник

Дегтярева Т.Г

м. Харків - 2017 рік

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. АНАЛИЗ ТРЕБОВАНИЙ К WEB-ПРИЛОЖЕНИЯ ДЛЯ ПРЕДОСТАВЛЕНИЯ ТРАНСПОРТНЫХ УСЛУГ

1.1 Формулировка цели и постановка задач дипломного проекта

1.2 Требования заказчика

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

1.4 Обзор существующих аналогов

1.5 Требования к ПО

1.6 Спецификация вариантов использования

2. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ WEB-ПРИЛОЖЕНИЯ ДЛЯ ПРЕДОСТАВЛЕНИЯ ТРАНСПОРТНЫХ УСЛУГ

2.1 Обоснование выбора модели архитектуры программного обеспечения

2.2 Разработка архитектуры программного обеспечения

2.3 Построение диаграммы развертывания для реализации системы

2.4 Построение диаграмм деятельности

2.5 Проектирование модели данных

ВЫВОДЫ

ЛИТЕРАТУРА

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

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

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

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

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

1. АНАЛИЗ ТРЕБОВАНИЙ К WEB-ПРИЛОЖЕНИЯ ДЛЯ ПРЕДОСТАВЛЕНИЯ ТРАНСПОРТНЫХ УСЛУГ

1.1 Формулировка цели и постановка задач дипломного проекта

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

- защита от несанкционированного доступа;

- отображение маршрута для водителя;

- администрирования веб-сервиса.

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

1. Провести анализ требований к разработке программного обеспечения.

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

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

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

Программное обеспечение должно поддерживать три основных класса пользователей: Гость (неавторизованный пользователь), Водитель и Диспетчер.

Гость - неавторизованный пользователь, имеет возможность просматривать карту и торговые точки («О Системе», «Правила Пользования»), а также авторизоваться в системе. Основная функциональность сети не доступна Гостям системы.

Авторизированный пользователь, наследует права Гостя, и имеет ограниченный доступ к основной функциональности системы:

- просмотр заказов;

- просмотр маршрута заказа;

- управление личным аккаунтом;

Администратор имеет доступ к полной функциональности системы:

- добавление нового пользователя(водителя)

- редактировать список водителей;

- добавление нового заказа;

- редактирование заказа;

- формировать маршрута по заказу;

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

1.2 Требования заказчика

Мандатные требования

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

- незарегистрированный пользователь;

- авторизированный пользователь;

- администратор.

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

возможность просматривать домашнюю страницу;

Возможность просматривать страницу с информацией о программном обеспечении и правилами пользования.

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

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

возможность авторизоваться:

вводить Email;

вводить пароль.

Возможность восстанавливать пароль.

Возможность просмотра заказов.

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

Возможность просматривать информацию:

о маршруте;

о торговых точках;

о заказе.

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

возможность редактировать домашнюю страницу;

возможность добавить новый заказ:

вводить тип груза;

вводить дату;

вводить вес;

вводить пункт назначения;

возможность зарегистрировать нового пользователя:

вводить ФИО;

вводить Email;

вводить имя файла с фото;

вводить номер мобильного телефона;

вводить стаж;

вводить категорию водительского удостоверения;

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

имя;

фамилию;

номер мобильного телефона;

стаж;

категорию водительского удостоверения

Возможность редактировать информацию:

о маршруте;

о торговых точках;

о заказе;

Реализовать возможность подтверждения регистрации через электронную почту.

Реализовать возможность переключения языка (RU/EN).

Ограничительные требования

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

- Google Chrome 46.0 и выше;

- Firefox 42.0 и выше;

- Internet Explorer 11;

- Safari 5.1.7.

Для нормальной работы разрабатываемого ПО должны быть следующие минимальные характеристики:

- процессор, работающий на частоте не меньше 1ГГц;

- оперативная память не меньше 2 Гб;

- сводное пространство на жестком диске не менее 2Гб.

Разрабатываемое ПО должно корректно обрабатывать ошибки пользователя.

Разрабатываемое ПО должно обрабатывать запросы пользователя не больше чем за 1,5 секунды при стабильном подключении интернета и скорости 2МБ.

Дизайн пользовательского интерфейса в разрабатываемом ПО должен быть спроектирован в соответствии с требованием Style Guide Microsoft.

Каждая страница разрабатываемого ПО должна содержать:

- логотип;

- верхнее навигационное меню;

- форма выбора языка интерфейса;

- форма авторизации/ссылка выхода из системы;

- нижний колонтитул с информацией о разработчике.

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

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

- определить общие границы и контекст моделируемой предметной области;

- сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

При помощи полученного от заказчика текстового описания было начато создание диаграммы вариантов использования. В ходе работы было выделено двадцать четыре прецедента и три актера:

- администратор;

- зарегистрированный пользователь;

- незарегистрированный пользователь.

Созданная диаграмма приведена на рисунке 1.1.

Рисунок 1.1 - Диаграмма вариантов использования Web-приложения для предоставления транспортных услуг

1.4 Обзор существующих аналогов

Выбор приложения является весьма актуальной задачей для пользователей в сети Интернет. При анализе сайтов для предоставления транспортных услуг следует учитывать:

1) функциональность;

2) простой и понятный интерфейс;

3) стоимость.

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

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

Программное обеспечение «Sat.ua»

Преимущества ПО «sat.ua»:

- возможность рассчитать стоимость перевозки;

- возможность отследить груз.

Недостатки ПО «sat.ua»:

- доступность только по Украине;

- устаревший стиль;

- плохой Usability (много информации на странице);

- непродуманная навигация.

Программное обеспечение «dalethgroup.com»

На рисунках 1.4 - 1.5 представлен интерфейс ПО «dalethgroup.com»

Преимущества ПО «dalethgroup.com»:

- доступен онлайн чат;

- быстрая обратная связь;

- международная компания;

Недостатки ПО «dalethgroup.com»:

- высокая стоимость услуг;

- непродуманная навигация;

Обобщенные результаты оценки существующих аналогов приведены в таблице 1.1.

Таблица 1.1 - Обобщенные результаты оценки аналогов - конкурентов

Вопросы	Ответы	Вес
Архитектура и Навигация	sat.ua	dalethgroup.com
Соответствует ли структура сайта целям, для достижения которых он предназначен?	0,5	0,5	1
Понятна ли схема навигации?	1	1	2
Можно ли определить, в каком месте сайта вы находитесь?	1	1	2
Является ли разумным количество элементов в навигационных панелях?	1	0	1
Логично ли отсортированы элементы навигационных панелей?	0,5	1	2
Соответствуют ли названия гиперссылок названиям страницы?	3	3	3
Отчетливо ли выделены гиперссылки?	1	2	3
Существует ли отчетливо выделенная ссылка на главную страницу?	0,5	0,5	1
Существует ли возможность поиска информации на сайте?	0	0	1
Существует ли карта сайта?	0	0	1
Каждая ли страница позволяет понять, на каком сайте вы находитесь?	0	1	2
Может ли пользователь управлять навигацией по сайту?	2	2	2
Планировка и Дизайн
Превышает ли размер страницы размер окна?	0	0	1

Анализ результатов оценки сайтов конкурентов показал, что количество отрицательных ответов для сайта sat.ua = 55 %, а для сайта dalethgroup.com = 54 % (результаты показаны на рисунке 1.6), что превышает 50 %, поэтому было принято решение разрабатывать «Web-приложение, для предоставления транспортных услуг».

1.5 Требования к ПО

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

ПО должно поддерживать три уровня пользователей:

- неавторизированный пользователь;

- авторизированный пользователь;

- администратор.

Режим незарегистрированного пользователя:

просматривать домашнюю страницу;

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

Режим Авторизированного пользователя наследует права неавторизированного пользователя и имеет дополнительные функции:

редактировать свой профиль: удалять профиль, изменять пароль, изменять фото;

авторизоваться:

- ввод Email;

- ввод пароля.

восстанавливать пароль;

добавляет заказ на карту;

просматривать информацию:

- о маршруте;

- о торговых точках;

Режим Администратора наследует все права авторизированного пользователя и имеет дополнительные функции:

редактировать домашнюю страницу;

возможность добавить новый заказ:

- вводить тип груза;

- вводить дату;

- вводить вес;

- вводить пункт назначения;

редактировать профили пользователей:

- имя;

- фамилия;

- адрес электронной почты;

- имя файла фото (не обязательно);

- стаж;

- категория водительского удостоверения;

Редактировать информацию:

- о заказе;

- о маршруте;

- о торговых точках;

В ПО должна быть реализована функция подтверждения регистрации через электронную почту.

В ПО должна быть реализована функция переключения языка (RU/EN).

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

Разработанное ПО должно работать в браузерах следующих версий:

- Google Chrome 46.0 и выше;

- Firefox 42.0 и выше;

- Internet Explorer 11;

- Safari 5.1.7.

Разрабатываемо ПО должно работать на ПК с таким минимальным набором характеристик:

- процессор, работающий на частоте не меньше 1ГГц;

- оперативная память не меньше 2 Гб;

- сводное пространство на жестком диске не менее 2Гб.

Приложение должно корректно обрабатывать ошибки пользователя.

Время обработки запросов пользователя не должно превышать 1,5 секунды при стабильном подключении интернета и скорости 2МБ.

Дизайн пользовательского интерфейса должен быть спроектирован в соответствии с требованиями Style Guide Microsoft.

Каждая страница системы должна содержать:

- логотип;

- верхнее навигационное меню;

- форма выбора языка интерфейса;

- форма авторизации/ссылка выхода из системы;

- нижний колонтитул с информацией о разработчике.

Построение матрицы трассируемости требований

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

Матрица трассируемости применима практически на всех этапах процесса разработки и позволяет:

1.6 Спецификация вариантов использования

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

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

Созданные спецификации приведены в таблицах 1.3 - 1.18.

Таблица 1.3 - Спецификация вариантов использования «Редактирование контента веб-страниц»

Идентификатор	01
Название	Редактирование контента веб-страниц
Участники	Администратор
Описание	Администратор переходит на форму редактирования и изменяет содержимое статических страниц веб-сервера.
Предусловие	Открыто окно с контентом
Постусловие	Внесены изменения в наполнение статических веб-страниц
Основной поток событий	Администратор изменяет контент веб-страниц. Администратор нажимает кнопку «Сохранить изменения».
Альтернативный поток	Кнопка «Сохранить изменения» не нажата - изменения не сохраняются.

Таблица 1.4 - Спецификация вариантов использования «Редактирование аккаунта»

Идентификатор	02
Название	Редактирование публикаций всех пользователей
Участники	Пользователь
Описание	Пользователь редактирует или удаляет данные своего аккаунта.
Предусловие	Открыта личная страница пользователя
Постусловие	Сохранены внесенные изменения

Таблица 1.5 - Спецификация вариантов использования «Редактирование аккаунтов пользователя»

Идентификатор	03
Название	Редактирование аккаунтов пользователя
Участники	Администратор
Описание	Администратор редактирует профиль пользователя.
Предусловие	Открыта личная страница пользователя.
Постусловие	Сохранение результатов редактирования аккаунта пользователя
Основной поток событий	Администратор выполняет переход на страницу с профилем пользователя. Вносит изменения в профиль пользователя. Нажимает на кнопку «Сохранить».
Альтернативные потоки	Кнопка «Сохранить» не нажата - изменения профиля не сохраняются. Администратор удаляет аккаунт пользователя.

Таблица 1.6 - Спецификация вариантов использования «Просмотр страницы о системе»

Идентификатор	04
Название	Просмотр страницы о системе
Участники	Незарегистрированный пользователь.
Описание	Незарегистрированный пользователь просматривает информацию о системе.
Предусловие	Открыта страница «О системе»
Постусловие	Пользователь проинформирован о возможностях и назначении системы.
Основной поток событий	Пользователь нажимает на кнопку «О системе». Пользователь просматривает информацию о системе

Таблица 1.8 - Спецификация вариантов использования «Авторизация на сайте»

Идентификатор	06
Название	Авторизация на сайте
Участники	Зарегистрированный пользователь
Описание	Пользователь вводит свои данные для входа на личный аккаунт
Предусловие	Открыта страница сайта
Постусловие	Выполнен вход в аккаунт пользователя
Основной поток событий	Пользователь нажимает на кнопку «Login or register». Пользователь вводит логин. Пользователь вводит пароль. Пользователь нажимает на кнопку «Вход».
Альтернативные потоки	Пользователь ввел неверные данные при авторизации - вывод сообщения об ошибке и очистка полей авторизации. Пользователь нажал на кнопку «Забыл пароль» - открывается форма для восстановления пароля

Таблица 1.9 - Спецификация вариантов использования «Добавление маршрута»

Идентификатор	07
Название	Добавление маршрута
Участники	Администратор
Описание	Администратор добавляет новый маршрут, в общую таблицу маршрутов
Предусловие	Отрыто окно с маршрутами
Постусловие	Добавлен новый маршрут
Основной поток событий	Администратор нажимает кнопку «Добавить». Администратор заполняет необходимые поля. Администратор нажимает кнопку «Сохранить»
Альтернативные потоки	Поток A	В процессе добавления Администратор заполнил не все поля - вывод сообщения о некорректно заполненной форме добавления маршрута

Таблица 1.10 - Спецификация вариантов использования «Изменение маршрута»

Идентификатор	08
Название	Изменение маршрута
Участники	Администратор
Описание	Администратор изменяет маршрут, находящийся в общей таблице маршрутов
Предусловие	Отрыто окно с маршрутами
Постусловие	Маршрут изменен
Основной поток событий	Администратор нажимает кнопку «Изменить». Администратор изменяет необходимые поля. Администратор нажимает кнопку «Сохранить»
Альтернативные потоки	Поток A	В процессе добавления Администратор не корректно заполнил поля - вывод сообщения о некорректно заполненной форме изменения маршрута

Таблица 1.11 - Спецификация вариантов использования «Добавление транспортного средства»

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

Таблица 1.12 - Спецификация вариантов использования «Изменение транспортного средства»

Идентификатор	10
Название	Изменение транспортного средства
Участники	Администратор
Описание	Администратор изменяет транспортное средство, находящееся в общей таблице транспортных средств
Предусловие	Отрыто окно с транспортными средствами
Постусловие	Транспортными средство изменено
Основной поток событий	Администратор нажимает кнопку «Изменить». Администратор изменяет необходимые поля. Администратор нажимает кнопку «Сохранить»
Альтернативные потоки	Поток A	В процессе добавления Администратор не корректно заполнил поля - вывод сообщения о некорректно заполненной форме изменения транспортного средства

Таблица 1.13 - Спецификация вариантов использования «Добавление заказа»

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

Таблица 1.14 - Спецификация вариантов использования «Изменение заказа»

Идентификатор	12
Название	Изменение
Участники	Администратор
Описание	Администратор изменяет груз, находящееся в общей таблице видов груза
Предусловие	Отрыто окно с видами груза
Постусловие	Груз изменен
Основной поток событий	Администратор нажимает кнопку «Изменить». Администратор изменяет необходимые поля. Администратор нажимает кнопку «Сохранить»
Альтернативные потоки	Поток A	В процессе добавления Администратор не корректно заполнил поля - вывод сообщения о некорректно заполненной форме изменения груза

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

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

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

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

2. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ WEB-ПРИЛОЖЕНИЯ ДЛЯ ПРЕДОСТАВЛЕНИЯ ТРАНСПОРТНЫХ УСЛУГ

2.1 Обоснование выбора модели архитектуры программного обеспечения

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ.three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентскоеприложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, которыйв свою очередь подключен к серверу базы данных.

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

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

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

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

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

Достоинства.

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующиедостоинства трёхуровневой архитектуры:

1) масштабируемость;

2) конфигурируемость -- изолированность уровней друг от друга позволяет (при правильном развертыванииархитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев илипри плановом обслуживании на одном из уровней;

3) высокая безопасность;

4) высокая надёжность;

5) низкие требования к скорости канала (сети) между терминалами и сервером приложений;

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

2.2 Разработка архитектуры программного обеспечения

Уровень пользовательского интерфейса располагается на компьютере конечного пользователя (клиент). Пользователи имеют возможность посылать запросы и получать обработанную информацию, то есть работают, по сути, в режиме "тонкого клиента", терминала.

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

Уровень бизнес-логики и обработки данных располагается на сервере и часто называется сервером приложения. На данном уровне находится большая часть бизнес-логики. Данный уровень представлен в проекте BusinessLogic.

Рисунок 2.1 - Модель трехуровневой архитектуры «Клиент - сервер приложений - сервер БД»

СУБД, в которой хранятся данные, необходимые для функционирования промежуточного уровня. Этот уровень может выполняться на отдельном сервере базы данных. Клиент отвечает только за пользовательский интерфейс и, возможно, выполняет некоторую очень простую логическую обработку данных, например, проверку корректности ввода данных. Основная бизнес-логика приложения теперь находится на собственном выделенном уровне, который физически связан с клиентом и сервером базы данных посредством локальной или глобальной вычислительной сети. При этом предполагается, что один сервер приложений может обслуживать множество клиентов [3].

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

Уровень представления реализован в системе с помощью MVC ASP.NET Web Application.

Проект MVCApplicationTransportServices имеет свою архитектуру, а именно построен при помощи паттерна проектирования MVC [4].

Архитектура проекта MVCApplicationTransportServices изображена на рисунке 2.2.

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

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

2.3 Построение диаграммы развертывания для реализации системы

Для публикации приложения необходимо иметь сервер, который будет выполнять хостинг «Веб-приложения для предоставления транспортных услуг».

Рисунок 2.5 - Диаграмма развёртывания Web-приложения для предоставления транспортных услуг

Сервер должен быть подключён к Базам данных локально и иметь доступ к сети Интернет. Таким образом пользователь «Веб-приложения для предоставления транспортных услуг» может использовать приложения при наличии у него Смартфона/ПК/Ноутбука, которые в свою очередь подключены к сети Интернет. На рисунке. 2.5 приведена схема развёртывания приложения.

2.4 Построение диаграмм деятельности

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

На рисунке 2.6 изображена диаграмма деятельности спецификации «Регистрация пользователя».

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

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

Рисунке 2.7 - Диаграмма деятельности спецификации «Добавление маршрута»

Рисунок 2.9 - Диаграмма деятельности спецификации «Изменение маршрута»

2.5 Проектирование модели данных

Выделение сущностей и атрибутов

Для предметной области «Предоставление транспортных услуг» я выделил следующие сущности:

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

Груз (Admin) - сущность, содержащая всех диспетчеров, которыебудут работать.

Маршруты (Order) - сущность, содержащая все заказы, по которым будут осуществляться грузоперевозки.

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

ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

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

На рисунке 2.11 показана ER-модель предметной области.

Рисунок 2.11 - ER-модель предметной области

Построение логической модели данных

На рисунке 2.12 изображена логическая модель базы данных Web-приложения предоставление транспортных услуг.

Рисунок 2.12 - Логическая модель данных Web-приложения предоставление транспортных услуг

Описание таблиц и полей

В таблицах 2.3 - 2.6 приведены описания таблиц и полей базы данных управление грузоперевозками.

Таблица 2.3 - Таблица Автомобиль «Vehicle»

Название поля	Тип	Ограничение	Примечания
IdVehicle	Integer	PK	Id транспортного средства
Mark	Varchar(50)		Марка
Model	Varchar(50)		Модель
TypeofVehicle	Varchar(50)		Тип автомобиля
Capacity	Float		Грузоподъемность
Area	Float		Площадь платформы
Size	Float		Объем платформы

Таблица 2.4 - Таблица «Диспетчер» (Admin)

Название поля	Тип	Ограничение	Примечания
IdAdmin	Integer	PK	Id диспетчера
Email	Varchar(50)		Емейл
Name	Varchar(50)		Имя
Surname	Varchar(70)		Фамилия
MiddleName	Varchar(50)		Отчество
Phone	Integer		Телефон
PhotoURL	Varchar(50)		Адрес фотографии
Password	Varchar(50)		Пароль

Таблица 2.5 - Таблица «Заказ» (Order)

Название поля	Тип	Ограничение	Примечания
IdOrder	Integer	PK	Id заказа
Name	Varchar(50)		Название заказа
Email	Varchar(50)		Водитель
Date	Data		Дата маршрута
PointA	Varchar(500)		Точка отправления
PointB	Varchar(500)		Точка доставки
Client	Date		Заказчик
Number	Integer		Номер заказчика
IdVehicle	Integer	FK	Id транспортного средства
IdDriver	Integer	FK	Id водителя

Построение физической модели данных

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

Рисунок 2.13 - Физическая модель базы данных Web-приложения предоставление транспортных услуг.

Разработка SQL-скриптов для реализации таблиц баз данных

SQL-скрипт для создания таблицы «Пользователи»:

CREATE TABLE [dbo].[Driver] (

[Name] NVARCHAR (50) NOT NULL,

[Surname] NVARCHAR (50) NOT NULL,

[Middle_name] NVARCHAR (50) NULL,

[Email] NVARCHAR (100) NOT NULL,

[Phone] NVARCHAR (30) NULL,

[IsAdmin] BIT DEFAULT ((0)) NOT NULL,

[PhotoURL] NVARCHAR (100) NULL,

[Password] NVARCHAR (50) NOT NULL,

[DrivingExpirience] FLOAT (53) NULL,

[RightsCategory] NVARCHAR (50) NULL,

PRIMARY KEY CLUSTERED ([Email] ASC)

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

SQL-скрипт для создания таблицы «Автомобили»:

CREATE TABLE [dbo].[Vehicles] (

[IdVehicle] INT NOT NULL,

[Mark] NVARCHAR (50) NULL,

[Model] NVARCHAR (50) NULL,

[TypeofVehicle] NVARCHAR (50) NULL,

[Capacity] FLOAT (53) NULL,

[Area] FLOAT (53) NULL,

[Size] FLOAT (53) NULL,

PRIMARY KEY CLUSTERED ([IdVehicle] ASC)

);

SQL-скрипт для создания таблицы «Диспетчер»:

CREATE TABLE [dbo].[Admin] (

[IdProduct] INT NOT NULL,

[Name] NVARCHAR (50) NULL,

[Typeofproduct] NVARCHAR (50) NULL,

[Weight] FLOAT (53) NULL,

[Height] FLOAT (53) NULL,

[Length] FLOAT (53) NULL,

[Price] NCHAR (10) NULL,

PRIMARY KEY CLUSTERED ([IdProduct] ASC)

);

SQL-скрипт для создания таблицы «Заказы»:

CREATE TABLE [dbo].[Order] (

[IdOrder] INT NOT NULL,

[Name] NVARCHAR (50) NULL,

[Email] NVARCHAR (100) NULL,

[Date] DATE NULL,

[PointA] NVARCHAR (500) NULL,

[PointB] NVARCHAR (500) NULL,

[Client] NVARCHAR (50) NULL,

[Number] NVARCHAR (50) NULL,

[IdVehicle] INT NULL,

[IdProduct] INT NULL,

PRIMARY KEY CLUSTERED ([Idщквук] ASC)

);

Описание методов классов для реализации системы

В результате разработки Web-приложения были реализованы следующие проекты:

- DataBase;

- BusinessLogic;

- MVCApplicationTransportServices;

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

В проекте DataBase определена модель разрабатываемого приложения и его сущности. Диаграмма классов DataBase представлена на рисунке 2.18.



Рисунок 2.18 - Диаграмма классов проекта DataBase

Проект содержит следующие доменные объекты приложения:

- Driver;

- Order;

- Admin;

- Vehicle.

Класс Driver предназначен для описания сущности «Пользователь». Свойства класса:

- int DriverId - уникальный идентификатор водителя;

- string Name - имя пользователя;

- string Middle_name - фамилия пользователя;

- string Last_name - отчество пользователя;

- string Password - пароль пользователя;

- string Email - адресс электронной почты пользователя;

- float DrivingExpirience - стаж;

- string RightCtegory - категория;

Клас Order предназначен для описания сущности «Заказ». Свойства класса:

- string Name - название маршрута;

- string Email - идентификатор водителя;

- date Date - дата маршрута;

- string PointA - точка отправления;

- string PointB - точка доставки;

- string Client - заказчик;

- int Number - номер заказчика;

- int IdVehicle - идентификатор транспортного средства;

- int IdDriver - идентификатор водителя;

Класс Admin предназначен для описания сущности «Диспетчер». Свойства класса:

- string Name - имя пользователя;

- string Middle_name - фамилия пользователя;

- string Last_name - отчество пользователя;

- string Password - пароль пользователя;

- string Email - адресс электронной почты пользователя;

Класс Vehicle предназначен для описания сущности «Транспортные стредства». Свойства класса:

- int IdVehicle - уникальный идентификатор записи в таблице Vehicle;

- string Mark - идентификатор адресанта сообщения;

- string Model - Модель;

- string TypeofVehicle - Тип автомобиля;

- float Capacity - Грузоподъемность;

- float Area - Площадь платформы;

- float Size - Объем платформы;

Проект BusinessLogic предназначен для описания механизма обработки пользовательских запросов и взаимодействия пользователя с приложением. Диаграмма классов проекта представлена на рисунке 2.19.



Рисунок 2.19 - Диаграмма классов проекта BusinessLogic

Проект BusinessLogic содержит следующие интерфейсы:

- IDriverRepository;

- IOrderRepository;

- IAdminRepository;

- IVehicleRepository.

Интерфейс IUsersRepository предназначен для взаимодействия с репозиторием EFUsersRepository. Свойства интерфейса:

- метод IEnumerable<User> GetUsers() - предназначен для выборки всех пользователей с БД;

- метод User GetUserById(int id) - предназначен для выборки пользователя с указанным идентификатором;

- метод User GetUserByName(string userName) - предназначен для выборки пользователя с указанным логином;

- метод MembershipUser GetMembershipUserByName(string userName) - предназначен для инициализации нового экземпляра класса MembershipUser при регистрации нового пользователя;

- метод GetUserNameByEmail(string email) - предназначен для выборки пользователя с указанным адресом электронной почты;

- метод void CreateUser(string userName, string password, string email, string firstName, string lastName, string middleName) - содержит параметры регистрируемого пользователя;

- метод bool ValidateUser(string userName, string password) - предназначен для проверки валидации логина и пароля пользователя;

- метод void SaverUser(User user) - описывает механизм сохранения нового пользователя в базу данных.

Интерфейс IOrderRepository предназначен для взаимодействия с репозиторием EFOrderRepository.

Интерфейс IVehicleRepository предназначен для взаимодействия с репозиторием EFVehicleRepository.

Интерфейс IPAdmintRepository предназначен для взаимодействия с репозиторием EFAdminRepository.

Проект BusinessLogic содержит следующие классы реализации интерфейсов:

- EFDriverRepository;

- EFVehicleRepository;

- EFAdminRepository;

- EFOrderRepository.

Класс EFUsersRepository содержит обьекты для доступа к данным приложения, предназначен для описания механизма хранения данных о пользователе. Методы класса:

- метод public EFUsersRepository (EFDbContext context) - конструктор класса;

- метод public IEnumerable<User> GetUsers() - предназначен для выборки всех пользователей с БД;

- метод public User GetUserById(int id) - предназначен для выборки пользователя с указанным идентификатором;

- метод public User GetUserByName(string userName) - предназначен для выборки пользователя с указанным логином;

- метод public System.Web.Security.MembershipUser GetMembershipUserByName(string userName) - предназначен для инициализации нового экземпляра класса MembershipUser при регистрации нового пользователя;

- метод public string GetUserNameByEmail(string email) - предназначен для выборки пользователя с указанным адресом электронной почты;

- метод public void CreateUser(string userName, string password, string email, string firstName, string lastName, string middleName) - содержит параметры регистрируемого пользователя;

- метод public bool ValidateUser(string userName, string password) - предназначен для проверки валидации логина и пароля пользователя;

- метод public void SaverUser(User user) - описывает механизм сохранения нового пользователя в базу данных.

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

Краткое описание классов и методов «Web-приложения для предоставления транспортных услуг»:

- AccountController - к основным функциям класса относятся реалирегистрация, авторизация, подтверждение регистрации.

- OrderController - к основным функциям класса относятся добавление, удаление и изменение маршрута, поиск маршрута, выбор ма...