55
Диаграмма последовательностей для функции «Поиск кратчайшего
пути» представлена на рисунке 24. Пользователь вводит адрес необходимой
ему парковки. Из сервера приложения данная информация отправляется в
БД, где информация обрабатывается и выводится в сервер приложения, либо
сообщение с координатами, либо сообщение с ошибкой. В случае, если
парковка была найдена в БД, то сервер приложения отправляет запрос в
сервер определения геопозиции и указывается текущая геопозиция
пользователя. На уровне сервера приложения определяется кратчайший путь
и информация отображается пользователю.
Рисунок 24. Диаграмма последовательности функции «Поиск
кратчайшего пути»
Диаграмма последовательностей для функции «Запрос в службу
технической поддержки» представлена на рисунке 25. Пользователь
отправляет запрос в сервер приложения, на уровне которого он проверяется и
запрос отправляется в сервер БД приложения. Далее сервер БД приложения
отправляет отчет об отправке запроса в сервер приложения и пользователь
получает сообщение об успешной отправке запроса.
56
Рисунок 25. Диаграмма последовательности функции «Запрос в
службу технической поддержки»
Диаграмма последовательностей для функции «Просмотр рекламы»
представлена на рисунке 26. Пользователь отправляет в сервер приложения
запрос о включении или отключении рекламы. В свою очередь, сервер
рекламных объявлений отправляет содержимое рекламы в сервер
приложения и реклама показывается пользователю.
Рисунок 26. Диаграмма последовательности функции «Просмотр
рекламы»
Диаграмма последовательностей для функции «Определение текущего
местоположения» представлена на рисунке 27. Пользователь деле запрос на
поиск местоположения, через сервер отправляется запрос в сервер
геолокации и результат, в виде текущей геопозиции отправляется на сервер и
к пользователю.
57
Рисунок 27. Диаграмма последовательности функции
«Определение текущего местоположения»
Далее было осуществлено моделирование классов, которые
определяют сущность информационной системы. Диаграмма классов
представлена на рисунке 28.
Рисунок 28. Диаграмма классов
Класс Users содержит информацию о пользователях системы, такую
как: логин и пароль.
Класс Zapros содержит информацию о запросах: текст запроса,
изображение - которые могут оставлять пользователи в службу технической
поддержки.
58
Класс Otzivi содержит информацию об отзывах: текст запроса,
изображение - которые могут оставлять пользователи о любой парковке.
Информация о парковках хранится в классе Parkovki, которые
содержит: название парковки, стоимость часа, стоимость суток, количество
мест, время начала работы, время окончания работы.
В классе Goroda хранится информация о городе: название города,
число парковок. В нашем случае хранится информация об одном городе.
Для города доступна своя реклама – класс Reklama, который содержит:
текст рекламы, изображение, дата публикации.
Диаграмма развертывания, представляющая графическое изображение
процессов, устройств и связей между ними, представлена на рисунке 29.
Рисунок 29. Диаграмма развертывания
Далее было выполнено проектирование базы данных. При
проектировании используется нормализация, которая подразумевает
преобразование отношений базы к виду, который отвечает нормальным
формам. На основе поставленной задачи и описания предметной области,
выявлены атрибуты базы данных. Для того, чтобы привести базу к первой
нормальной форме (1НФ) необходимо избавиться от неатомарных,
неделимых, данных, выбрать первичный ключ, однозначно определяющего
59
запись. База в первой нормальной форме представлена в таблице 6., а
первичные ключевые поля выделены цветом.
Таблица 6
Первая нормальная форма
Атрибут
Данные № 1
Данные №2
Код города
01
02
Код парковки
101
102
Число парковок
120
120
Название
парковки
Автомобильная парковка
№101
Автомобильная парковка
№102
Адрес
Монастырская, 10
Екатерининская, 109а
Цена за час
15 руб
15 руб
Цена за сутки
90 руб
90 руб
Количество мест
300
250
Врем открытия
8:30
8:30
Время закрытия
19:30
19:30
Код отзыва
110
111
Описание отзыва
Много доступных мест.
Близко к дому, дружелюбный
охранник.
Код
пользователя
1
2
Логин
Артем
Юрий
Пароль
1111
1202
E-mail
hgf@mai.ru
hkdhfkj@mail.ru
Номер телефона
7912885353
79194513903
Код запроса
1000
1001
Текст запроса
Не правильно
отображена информация
о парковке.
Не могу проложить маршрут.
Функция не работает.
Код рекламы
999
998
Название
рекламы
Магазин посуды
Магазин строительных
инструментов
Описание
рекламы
Реклама столовых
приборов.
Реклама новой техники
Дата публикации
11.06.2017
11.06.2017
Тип рекламы
Банерная реклама
Полноэкранная реклама
Длительность
1 день
3 часа
Количество
просмотров
399
420
Количество
кликов
33
101
Стоимость
3000
4000
Код
10001
10002
60
рекламодателя
ФИО
Сергеев Сергей
Сергеевич
Петров Петр Петрович
Название
«Кружки – ложки»
«Строим дом»
Организационная
форма
ООО
ИП
Телефон
+79191919198
+793665389
E-mail
kruzhki@yandex.ru
Dom@mail.ru
Отношение находится во второй нормальной форме тогда, когда оно
находится в 1НФ и все неключевые атрибуты функционально полно зависят
от потенциального ключа. Таким образом, с помощью ключевых полей,
можно разбить форму на 2 таблицы, которые определяют информацию о
парковке и пользователе. Разбиение полей на таблицы представлено в
таблице 7.
Таблица 7
Вторая нормальная форма
Информация о парковке
Информация о пользователе
Код парковки *
Код пользователя*
Название парковки
Логин
Цена за час
Пароль
Цена за сутки
e-mail
Количество мест
Номер телефона
Время открытия
Код запроса
Время закрытия
Текст запроса
Код города
Название города
Число парковок
Код отзыва
Текст отзыва
Код рекламы
Название рекламы
Описание рекламы
Дата публикации
Тип рекламы
Длительность
Количество просмотров
Количество кликов
Стоимость
Код рекламодателя
ФИО
Название
Организационная форма
61
Информация о парковке
Информация о пользователе
Телефон
E-mail
Отношение находится в третьей нормальной форме в случае, если оно
находится в 2НФ и отсутствуют транзитивные функциональные зависимости
неключевых атрибутов от ключевых. Далее, на рисунке 30. представлена
приведенная к третьей нормальной форме схема базы данных в MS Access.
Рисунок 30. Схема базы данных
Для того, чтобы определить необходимое пространство для данных,
произведем расчеты потенциального количества занятого пространства.
Согласно проанализированным данным, приложение в первое время его
реализации охватит минимум 220 парковок города. Данные для расчета
потенциального необходимого пространства представлены в таблице 8.
Таблица 8
Данные для расчета пространства на 1 парковку
Поле
Тип данных
Максимальный
объем (байты)
Код парковки
Счетчик
4
Название парковки
Короткий текст
256
Цена за час
Денежный
8
Цена за сутки
Денежный
8
Количество мест
Числовой
2
Время открытия
Дата и время
8
62
Время закрытия
Дата и время
8
Код города
Числовой
2
Название города
Короткий текст
256
Общий максимальный объем на 1 парковку составляет 554 байта.
Следовательно, количество байтов на 220 парковок равно 121 880 байтов, что
составляет 0,00011 Гигабайтов (ГБ).
Количество потенциальных пользователей в первый месяц составит
700 человек. Посчитаем количество пространства, которое может занять
данное количество пользователей в БД, информация для расчета
представлены в таблице 9.
Таблица 9
Данные для расчета пространства на 1 пользователя
Поле
Тип данных
Максимальный
объем (байты)
Код пользователя
Счетчик
4
Логин
Короткий текст
256
Пароль
Короткий текст
256
e-mail
Короткий текст
256
Номер телефона
Числовой
2
Код запроса
Числовой
2
Текст запроса
Короткий текст
256
Код отзыва
Числовой
2
Текст отзыва
Короткий текст
256
Общий максимальный объем на 1 пользователя составляет 1290 байт.
Следовательно, количество байтов на 700 пользователей равно 903 000
байтов, что составляет 0,00084 Гигабайтов (ГБ).
Следовательно, потенциальный необходимый объем БД при запуске
мобильного приложения составляет 0,00095 ГБ. Стоит отметить, что
количество занятого пространства будет увеличиваться по мере увеличения
числа пользователей и количества информации о платных парковках.
Как уже было сказано, для того, чтобы реализовать данный стартап,
необходимо разработать мобильное приложение «Агрегатор коммерческих
парковок», используя различные программные и аппаратные средства. Стоит
отметить, что данное приложение будет разрабатываться под управлением
операционной системы (ОС) Android. Данный выбор обосновывается тем,
63
что на январь 2017 года была определена следующая распространенность ОС
в России:
1. Windows Phone – 2.54%.
2. iOS – 26.56%.
3. Android – 68.87%.
На сегодняшний день, на рынке мобильных телефонов наиболее
популярной ОС является Android, что подтверждает данная статистика.
Таким образом, далее были определены минимальные требования к ПО и,
как результат, перечислены программные средства, необходимые для
разработки мобильного приложения «Агрегатор коммерческих парковок».
Были определены следующие требования к мобильному приложению:
1. Поддержка мобильной платформы Android (версия 3.0. и выше)
2. Быстрая скорость работы пользовательского интерфейса.
Для того, чтобы написать Android-приложение, будет использован
такой язык программирования, как Java.
Мобильное приложение базируется на клиент-серверной архитектуре,
поскольку планируется большое количество пользователей, существует
необходимость в централизованном управлении, безопасности и
необходимость в специализированном сервере. Так, были выделены
требования к программному обеспечению (ПО) и экспертным образом
выбраны соответствующие программные ресурсы.
Требования к ПО клиентского приложения и сервера приложений:
- Android Studio. Среда разработки мобильного приложения – экранных
форм, логики, запросов и так далее.
- GIMP. Графический редактор. Имеет широкий набор функций:
полный набор инструментов рисования и преобразования, работа со слоями,
поддержка широкого количества форматов файлов, большой набор фильтров,
наличие дополнительных плагинов. Поскольку нет необходимости
разрабатывать трудоемкий дизайн для данного приложения, то функций
такого графического редактора будет достаточно.
64
Выбор ПО для сервера базы данных (БД):
База данных для серверной части выбирается исходя из следующих
требований:
1. Возможность поддерживания большого набора типов данных.
2. Безопасность и целостность данных.
3. Возможность масштабирования.
4. Реализациях для UNIX-подобных платформ.
Сравнение свободно распространяемых СУБД представлено в
Приложении 5. Таким образом, была выбрана PostgreSQL. Несмотря на то,
что данная БД имеет некоторые недостатки, такие как: плохая
многопоточность, инициация вех процессов снаружи базы и сложность в
использовании, она является наиболее продвинутой СУБД и обладает
механизмом высокой мощности для контроля целостности данных.
- Redis. Сетевое журналируемое хранилище, выбран исходя из
следующих возможностей:
1. Возможность сохранять сессии и профили пользователей.
2. Возможность хранить промежуточные результаты вычислений при
обработке больших объемов данных.
3. Возможность хранения больших объемов данных.
Требования к веб-серверу следующие:
1. Высокий уровень безопасности.
2. Надежность и удобство.
3. Поддерживаемая ОС – Linux.
Таким образом, был выбран такой веб-сервер, как Apache.
Для разработки приложения также будут использованы некоторые
стандартные библиотеки: для поиска данных о парковках и основной
информации – JSON или xml parser, для определения локации пользователя
стандартная библиотека LocationManager.
Выбор хостинга основывается на следующих требованиях:
1. Круглосуточная и быстрая техническая поддержка.