Інформаційна система для замовлення послуги спільних перевезень по місту

СВЕРДЕЛ, Владислав
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/8590
Title:	Інформаційна система для замовлення послуги спільних перевезень по місту
Authors:	МИРОНЮК, Тетяна СВЕРДЕЛ, Владислав
Keywords:	WEB-ДОДАТОК;POSTGRESQL;NODEJS;JAVASCRIPT;WEBSTORM
Issue Date:	2023
Abstract:	У кваліфікаційній роботі бакалавра описаний процес створення додатку для надання послуги перевезень по місту. Метою роботи є дослідження процесу та розробки актуальної системи, яка зменшує час переміщення по місту. В результаті виконання кваліфікаційної роботи було створено веб додаток, який слугує продуктом для надання послуг по перевезенню по місту. Додаток скорочує затрачений користувачами час на подорожування по місту з точки А до точки Б, а також виконує роль помічника водіям, які хочуть отримати гроші за перевезення. Додаток запускається на різних пристроях в яких є підтримка браузеру. Додаток був створений на мові програмуванняJavaScript. Середовищем розробки будо обрано IDE від JetBrains – WebStorm. Як сервер для запуску JSвикористовувався NodeJS, який є зручним та найвідомішим сервером для роботи з серверним JavaScript. Кваліфікаційна робота бакалавра містить 61 сторінку пояснювальної записки, в тому числі 11 рисунків та 3 додатки. Для написання кваліфікаційної роботи бакалавра використано 14 літературних джерел.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/8590
Appears in Collections:	123 Комп’ютерна інженерія (Системне програмування)
Files in This Item:
File	Description	Size	Format
01_ТИТУЛКА_СВЕРДЕЛ_ДРУК-merged.pdf Restricted Access		1.73 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему:
«Інформаційна система для замовлення послуги
спільних перевезень по місту»
ЧДТУ.231931.005 ПЗ
Виконав: студент 4 курсу, групи СП-1906
спеціальності 123 – «Комп’ютерна інженерія»
за освітньою програмою – «Системне
програмування»
Владислав СВЕРДЕЛ
Керівник
к.т.н., доцент Тетяна МИРОНЮК
Рецензент
к.т.н., начальник відділу персоналу
ЗАЖОМА В.М.
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор ______ Володимир РУДНИЦЬКИЙ
Черкаси 2023 року
Форма № Н-9.01
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет: інформаційних технологій і систем
Кафедра: інформаційної безпеки та комп’ютерної інженерії
Освітньо-кваліфікаційний рівень: Бакалавр
Спеціальність 123 – Комп’ютерна інженерія
Освітня програма Системне програмування
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор _____________ Рудницький В.М.
«28» лютого 2023 року
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Сверделу Владиславу Олексійовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи: Інформаційна система для замовлення послуги спільних
перевезень по місту
Керівник роботи: к.т.н. Миронюк Тетяна Василівна
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «24» лютого 2023 р. № 43/04
2. Строк подання студентом роботи:
3. Вихідні дані до роботи:
 мова програмування серверної та інтересної частини TypeScript;
 система управління базою даних MySQL;
 фреймворк для серверної частини Express;
 фреймворк для побудови інтерфейсу ReactJS;
 сервер NodeJS.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
1 Обґрунтування вибору тематики та огляд існуючих рішень
2 Обґрунтування вибору програмних засобів
3 Проектування та побудова архітектури програмного продукту
Висновки
Додатки
Список використаних джерел
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
1. Специфікація
2. Текст програми
6. Консультанти розділів роботи:
Розділ Прізвище, ініціали Підпис, дата
консультанта завдання видав завдання прийняв
7. Дата видачі завдання: 27 лютого 2023 року
КАЛЕНДАРНИЙ ПЛАН
Термін
№ з/п Назва етапів роботи виконання Примітка
етапів роботи
1 Отримання завдання 01.03 – 14.03 виконано
2 Збір матеріалу 15.03 – 1.04 виконано
3 Обробка матеріалу 02.04 – 10.04 виконано
4 Вибір програмного забезпечення та його виконано
обґрунтування 11.04 – 15.04
5 Розробка програмного продукту 16.04 – 26.04 виконано
6 Розробка бази даних 27.04 – 05.05 виконано
7 Синхронізація програмного продукту з базою 06.05 – 11.05 виконано
даних та тестування програмного продукту
8 Оформлення пояснювальної записки 12.05 – 22.05 виконано
9 Оформлення графічного матеріалу 22.05 – 31.05 виконано
10 Подання кваліфікаційної роботи на відгук та 01.06.23 виконано
рецензування
11 Захист кваліфікаційної роботи 07.06.23
Студент ____________________________ Владислав СВЕРДЕЛ
(підпис)
Керівник роботи _____________________________ Тетяна МИРОНЮК
(підпис)
АНОТАЦІЯ
У кваліфікаційній роботі бакалавра описаний процес створення
додатку для надання послуги перевезень по місту.
Метою роботи є дослідження процесу та розробки актуальної системи,
яка зменшує час переміщення по місту.
В результаті виконання кваліфікаційної роботи було створено веб
додаток, який слугує продуктом для надання послуг по перевезенню по
місту. Додаток скорочує затрачений користувачами час на подорожування по
місту з точки А до точки Б, а також виконує роль помічника водіям, які
хочуть отримати гроші за перевезення. Додаток запускається на різних
пристроях в яких є підтримка браузеру.
Додаток був створений на мові програмуванняJavaScript. Середовищем
розробки будо обрано IDE від JetBrains – WebStorm. Як сервер для запуску
JSвикористовувався NodeJS, який є зручним та найвідомішим сервером для
роботи з серверним JavaScript.
Кваліфікаційна робота бакалавра містить 61 сторінку пояснювальної
записки, в тому числі 11 рисунків та 3 додатки. Для написання
кваліфікаційної роботи бакалавра використано 14 літературних джерел.
Ключові слова: WEB-ДОДАТОК, POSTGRESQL, NODEJS,
JAVASCRIPT, WEBSTORM.
ANNOTATION
The bachelor's qualification work describes the process of creating an
application for the providing of transportation services in the city.
The aim of the work is research of process and development of the actual
system which reduces time on movement on the city.
As a result of the qualification work, a web application was created, using
which you can use the services of other drivers for transportation around the city in
cars. The application reduces the time spent by users traveling around the city from
point A to point B, and also acts as an assistant to drivers who want to get money
for transportation. The application runs on various devices that have browser
support.
The application was created using the JavaScript programming language.
The IDE from JetBrains – WebStorm will be chosen as the development
environment. NodeJS was used as a server to run JS, which is a convenient and
well-known server for working with server-side JavaScript.
The bachelor's work contains 61 sheets of explanatory note, including
11 pictures and 3 appendices. 14 literary sources were used to write the bachelor's
thesis.
Key words:WEB-ДОДАТОК, POSTGRE SQL, NODE JS, JAVA SCRIPT,
WEBSTORM.
ЗМІСТ
ВСТУП..................................................................................................................... 3
1 ОБГРУНТУВАННЯ ВИБОРУ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ОГЛЯД
ІСНУЮЧИХ РІШЕНЬ.............................................................................................5
1.1 Обґрунтування вибору предметної області..............................................5
1.2 Аналіз існуючих рішень.............................................................................6
1.3 Постановка завдання...................................................................................8
2 ОБГРУНТУВАНЯ ВИБОРУ ПРОГРАМНИХ ЗАСОБІВ ДЛЯ РОЗРОБКИ...9
3 ПРОЕКТУВАННЯ ТА ПОБУДОВА АРХІТЕКТУРИПРОГРАМНОГО
ПРОДУКТУ........................................................................................................... 24
3.1 Опис поверхневої архітектури.................................................................24
3.2 Побудова та проектування серверної архітектури програмного
забезпечення .......................................................................................................... 29
3.3 Проектування архітектури інтерфейсу ................................................... 33
3.4 Проектування архітектури бази даних додатку.....................................36
3.5 Проектування прототипу графічного інтерфейсу..................................41
ВИСНОВКИ...........................................................................................................45
ДОДАТКИ:
А – Популярність компонентних фреймворків на момент 2022 року
Б – 482.ЧДТУ.31931-01 Інформаційна система для замовлення послуги
спільних перевезень по місту
ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ……………………………………….61
ЧДТУ.231931.005 ПЗ
Змн. Арк. № докум. Підпис Дат
РозрКобив Свердел В.О. а
Керівник Миронюк Т.В. Інформаційна система Літ. Лист Листів
2 61
Рецеанзент Зажома В.М. для замовлення послуги
Н.Контроль Гресько С.О. спільних перевезень по Кафедра ІБ та КІ
Затвфердив Рудницький В.М. місту гр. СП-1906
е Пояснювальна записка
д
р
а
К
К
-
0
6
ВСТУП
В процесі отримання послуг для користувача однією з найважливіших
умов є комфортне їх надання. Наприклад, основною вимогою для створення
великої кількості інтернет магазинів є те, що споживач хоче отримувати
каталог товарів у більш стислому форматі з комфортним та швидким
пошуком; замовлення доставкою інгредієнтів для приготування або
комплексних наборів готових для вживання зменшує час, що включає процес
приготуванні їжі. Всі розглянуті фактори викликали велику потребу у
створенні програмних додатків для бізнесу.
Однією з найпопулярніших послуг, особливо в останні роки, що
спрощує життя, економить час та гроші споживачів являється послуга
сумісних поїздок. Дана послуга створює комфорт та є більш економною в
порівнянні з таксі, наприклад, в тому випадку, якщо ви спізнюєтеся на
роботу.
Підсумовуючи вище сказане, можна вказати, що тема кваліфікаційної
роботи бакалавра «Інформаційна система для замовлення послуги спільних
перевезень по місту» є досить актуальною на сьогодні, оскільки реалізований
додаток, надає можливість оптимізувати необхідні потреби користувача
щодо перевезень по місту.
Мінімальний функціоналом, що необхідний при розробці додатку,
включає наступні вимоги:
реалізація персонального аканту для різних ролей;
верифікація аканту за номером телефону або використовуючи акаунт в
соціальній мережі з підтвердженим діючим номером телефону;
відображення карти міста;
функція зчитування геолокації з телефону користувача;
автоматичне розрахуваннявартостів процесі створення замовлення;
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 3
а
виведення для водіїв пропозицій нових замовлень.
Реалізація визначених під час дослідження вимог дає можливість
досягти поставленої мети в роботі, тобто розробити функціонал програмного
додатку, що надасть можливість отримати повний цикл послуг по
перевезенню пасажирів.
Описаний перед розробкою план виконання роботи не виключає
можливість того, що буде додано новий функціонал в процесі реалізації
програмного додатку.
Програмний додаток, що розробляється для користувача повинен
відображатися у зручній формі. Для того, щоб розроблений додатку
підтримувався на мобільному телефоні, його буде розроблено як Web-
додаток, що в свою чергу, надасть можливість доступу з різного типу
браузерів.
Результатом розробки програмного додатку є функціональний додаток,
який задовольняє всім визначеним вимогам та реалізований за допомогою
фреймворку Express та серверу NodeJs, мови програмування JavaScript.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 4
а
1 ОБГРУНТУВАННЯ ВИБОРУ ПРЕДМЕТНОЇ ОБЛАСТІ ТА ОГЛЯД
ІСНУЮЧИХ РІШЕНЬ
1.1 Обґрунтування вибору предметної області
Тематика кваліфікаційної роботи бакалавра була визначена
враховуючи потреби населення. Характерною рисою сучасного суспільства,
де технології стрімко розвиваються, змінюються та вдосконалюються, є
прагнення до економії часу та отримання максимального комфорту. Продукт,
який є актуальним для користувача, повинен бути не тільки зручним, але й
корисним. Іншими словами, не достатньо просто надати послугу, важливо
задовольнити потребу та максимально спростити процес замовлення послуги
для користувача. Основною перевагою розробки додатку є можливість
максимально скоротити зусилля, що необхідні для досягнення мети.
Розробка Web-додатку для замовлення послуг міського транспорту є
актуальною темою для реалізації програмних продуктів. Це пов'язано з тим,
що окрім виконання основної функції надання послуги, вона також включає в
себе комплексний аспект. Наприклад, такий підхід до ведення бізнесу
дозволяє значно підвищити лояльність клієнтів та збільшити їх кількість.
Відсутність необхідності телефонувати, тобто замовляти послуги в
кілька кліків, є важливим аспектом для того, щоб зробити продукт
актуальним і конкурентоспроможним на ринку. Комплексність продукту-
ключовий аспект у розробці сервісних продуктів сьогодні. Інклюзивність
означає розробку способів взаємодії з додатком. Спрощений інтерфейс
забезпечує візуальну підтримку з чіткими зображеннями замість тексту (на
відміну від текстової підтримки), чіткі зображення доступні для іномовних
людей та осіб з обмеженими можливостями, такими як дислексія.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 5
а
Сьогодні послуги перевізника мають певну цінність у повсякденному
житті людей, як зручна альтернатива громадському транспорту.
У цьому випадку розробка та впровадження програмного продукту,
який дозволяє надсилати запити та отримувати відповідь у найкоротші
терміни, може підтримати ключову особливість послуг перевізника, а саме
швидкість. Такі деталі, як GPS-моніторинг, можуть допомогти мінімізувати
взаємодію між клієнтом і перевізником та підвищити рівень довіри до
перевізника.
Таким чином, актуальність впровадження веб-додатку для замовлення
послуг перевізника базується на бажанні клієнта, тобто користувача,
отримати простий, безпечний та комфортний сервіс. Дотримання
вищезазначених пунктів забезпечить попит з боку широкого кола
користувачів.
1.2Аналіз існуючих рішень
Для того, щоб визначити основні задачі поставлені під час реалізації
кваліфікаційної роботи бакалавра, необхідно було проаналізувати існуючі на
ринку програмні рішення. Для цього було обрано та проаналізовано наступні
мобільні додатки – Uber та Uklon.
Ці додатки були обрані через їх загальну популярність серед
користувачів та велику клієнтську базу в Україні. Для забезпечення якості та
повноти дослідження обидва додатки аналізувалися окремо.
Uber Technologies Inc. Uber – американська міжнародна компанія,
додатки якої доступні в 67 країнах світу. Компанія спеціалізується на наданні
таких послуг, як пошук, виклик і оплата таксі та приватних водіїв[1].
Додаток пропонує близько двадцяти різних видів послуг, які
відрізняються в різних країнах. Таким чином, окрім пасажирських
перевезень, Uberпропонує доставку додому продуктів (UberEATS), дітей від
3років (UberKIDS), доставку піци (UberPIZZA), перевезення домашніх
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 6
а
тварин (UberPET), оренду автомобілів (UberTRIP), а також автономні
велосипеди та самокати.
Сервіс Uber Drive доступний у семи містах України, використовується
для доставки клієнтів по місту, розгорнутий у багатьох напрямках.
На сайті та в мобільному додатку Uber користувачі можуть одноосібно
впливати на вартість послуги, обираючи певні умови, які впливають на
ціноутворення. Це дозволяє користувачам замовляти таксі підвищеного або
економ-класу, розділити маршрут з іншим пасажиром, а потім платити за
підсумкове замовлення. Також є вибір автомобілів, пристосованих для
інвалідів у візках, і автомобілів з дитячими кріслами [1].
Реалізований функціонал мобільного додатку в кваліфікаційній роботі
бакалавра відрізняється від функціоналу мобільного додатку Uber Drive тим,
що, він простіший в реалізації, також дозволяє клієнтам обирати клас
автомобіля, а також по-різному впливати на ціну та оплату при замовленні.
Структура реалізованого інтерфейсу залишається такою ж, як і було
заплановано до реалізації.
Uklon-один з перших сервісів замовлення таксі в Україні; подібно до
додатку Uber, Uklon дозволяє користувачам замовляти послуги без
необхідності дзвонити в диспетчерську службу, і отримувати весь
необхідний функціонал в мобільному додатку або на веб-сторінці [2].
У додатку передбачена рейтингова система, де клієнт (пасажир) може
оцінити сервіс за п'ятибальною шкалою. Згідно з його функціоналом, запит
користувача спочатку надсилається до диспетчерської служби, де
розподіляється між водіями. При виборі перевізника пріоритет надається
водієві з найвищим рейтингом. При оформленні замовлення користувач може
вибрати тип транспортного засобу, замовити доставку, викликати водія і т.д..
Вищезгадані додатки використовують GPS для відстеження
місцезнаходження та пересування пасажирів і транспортних засобів, а також
можуть візуалізувати маршрути на карті.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 7
а
1.3 Постановка завдання
На основі проведених досліджень функціоналу обраних для
дослідження додатків та беручи за основу їх функціонал було визначено
деякі основоположні критерії, які буде розроблено під час реалізації web-
додатку:
наявність окремих персональних акаунтів для користувачів та
перевізника з доступом до особистого кабінету та історій поїздок;
один із пунктів реєстрації являється включення верифікації за
допомогою акаунту в соціальній мережі з підтвердженим діючим номером
телефону або за номером телефону;
функція зчитування геолокації з телефону користувача;
наявність функціоналу для автоматичного розрахунку ціни перед тим,
як буде виконано замовлення;
відображення карти міста в додатку;
виведення та перегляд актуального списку замовлень для перевізників.
Основною вимогою, під час реалізації інтерфейсу, що було визначено в
процесі дослідження обраних додатків з аналогічними послугами, є розробка
максимально зрозумілого та простого у використанні функціоналу.
Серед основних важливих для користувача пунктів можна виділити:
наявність зручного поля під час введення адреси, що відображається з
визначеною точкою на карті; обрахунок та виведення вартості послуги на
екран перед замовленням; можливість переглянути інформації про водія,
фото та марку автомобіля, номерний знаки; відображення рейтингу водія.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 8
а
2 ОБГРУНТУВАНЯ ВИБОРУ ПРОГРАМНИХ ЗАСОБІВ ДЛЯ
РОЗРОБКИ
Працюючи з технологіями різних професій складно ігнорувати
технології, котрі у всіх на устах. В сфері розробки web-додатків фаворитом є
JavaScript. Так як більшість додатків потребують інтерактивності або
отримання даних з серверів і маніпулювання ними без перезавантаження
сторінки, щоб реалізувати дані потреби було обрано саме скриптову мову
програмування JavaScript. Традиційно JavaScript використовується як
інструмент для побудови візуального інтерфейсу для користувача. Через
свою простоту дана мова програмування отримала шанувальників в IT сфері,
які організували велику спільноту відкритого коду (Open Source Community),
що застосовує дану мову програмування у своїй роботі. Спільнота розпочала
написання бібліотек для розробки, що почали використовуватися
розробниками. Але найкращі технології, зазвичай, випускаються великими
компаніями. Тому, щоб стабілізувати ринок розробки, деякі з компаній
почали працювати над реалізацією великих фреймворків та бібліотек для
побудови інтерфейсу[3].
Зазвичай, більшість web-додатків складаються з двох функціональних
частини, щоб надати користувачу у використання повноцінний продукт –
Front-end (тобто, візуальна частина додатку, за допомогою якої користувач
взаємодіє з додатком) та Back-end (функціональна частина, що відповідає за
бізнес логіку додатку, за процеси, що виконує та запускає користувач через
інтерфейс при цьому взаємодіючи з додатком, або автоматичні процеси, що
необхідні для обробки даних на сервері, наприклад, CRON). Внутрішня
частина дозволяє організувати дані та забезпечити належну роботу на стороні
клієнта. Ця частина програмного забезпечення не взаємодіє безпосередньо з
користувачем. Для взаємодії з серверною частиною програми
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 9
а
використовується API. Не всі дані доступні на сервері, тому доступність
даних для особи, яка намагається зробити запит, регулюється розробником
[4].
API в основному створюється для передачі даних в інші частини
програми з використанням прав доступу, згенерованих у вигляді
зашифрованих ключів.
У кваліфікаційній роботі бакалавра для реалізації додатку, буде
розроблено частину Back-end та макети для Front-end частини.
Java Script буде використовуватися як основна мова для серверної
частини та інтерфейсу, але, оскільки, вона не має прямого введення коду,
виникають різні проблеми, які заважають написанню невеликих програм ,але
з ними можна впоратися. При написанні програм з сотнями і тисячами рядків
коду ці постійні помилки і нестандартна логіка, стають серйозною
проблемою. Кожна мова має свої недоліки, JavaScript мова, що призначена
для негайного використання, згодом перетворилася на інструмент для
написання додатків з мільйонами рядків коду. Такі інструменти мають багато
проблем з реалізацією, які неможливо усунути будь-якими способами. Ось
кілька прикладів[4]:
¾оператор рівності в JavaScript примусово використовує свої
аргументи, що призводить до неочікуваної поведінки.
¾JavaScript може отримати доступ до властивостей, яких не існує.
TypeScript являється мовою, яка є надбудовою JavaScript. Виходячи з
цього, синтаксис JavaScript є допустимим для TypeScript. Однак, TypeScript є
типізованою надбудовою, а це означає, що мова додає правила використання
для різних типів значень. Розглянемо дане поняття на прикладі. Якщо,
наприклад, в JavaScript число розділити на масив, як результат буде Infinity
(безкінечність) (Infinity - тип даних у JavaScript). Якщо виконати таке ділення
в TypeScript, то буде повернуто повідомлення про помилку. Крім того,
основною властивістю TypeScript є зберігання тієї ж поведінки в процесі
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 10
а
виконання, що й у JavaScript, а це означає, що TypeScript також
являєтьсямовою програмування, що зберігає поведінку JavaScript в процесі
виконання.Це говорить про те, що можна робити перехід між двома мовами,
при цьому не турбуючись про відмінності та тонкощі при реалізації, які
можуть примусити програму перестати працювати.
Щобзастосовувати бібліотеки або фреймворкив процесі розробки,
необхідно встановити 2 пакети: перший – оригінальна бібліотека; другий
бібліотека для TypeScript, що надасть можливість аналізувати код, проводити
валідаціюкоду на момент написання, та підтримувати функції бібліотеки [5].
Для розробки бекендної частини(сервер) буде використано NodeJs.
NodeJs – це середовище виконання JavaScript, а не фреймворк чи бібліотека.
Реалізація виконання JavaScript базується на інструменті під назвою Chrome
V8. Цей інструмент створений компанією Google і написаний на мові C++.
Роль V8 в обробці коду при використанні NodeJs, як двигуна, полягає в
перетворенні коду JavaScript в більш ефективний машинний код, замість
використання інтерпретатора. На ринку є й інші рушії (Rhino, Spider Monke,
Nashorn), але хоча більшість сучасних JavaScript – рушії використовують
однаковий підхід,V8 унікальний тим, що не створює проміжного коду[6].
У JavaScriptі NodeJs є свої зони відповідальності: механізм JavaScript
повинен виконати цикл підготовки; парсер HTML витягує всі скрипти, до
дані за допомогою тегів<script>; і движок NodeJs повинен виконати цикл
підготовки. Код з цього джерела завантажується з мережі, кешу або
встановленого Service Worker. Відповіддю буде запитуваний скрипт у
вигляді байтового потоку, який буде оброблений декодером потокового
байтового потоку. Декодер розпізнає зарезервовані ключові слова з коду,
створює токен і надсилає його синтаксичному аналізатору резерву та
основному синтаксичному аналізатору. Двигун використовує два парсери:
попередній і основний. Щоб зменшити час завантаження сайту, движок
намагається уникати парсинг у коду, який непотрібен в даний момент.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 11
а
Попередній парсер обробляє код, який може бути використаний пізніше, в
той час як основний парсер обробляє код, який потрібен негайно[4].
На рисунку 2.1 показано, як працюють парсери JavaScript двигуна.
Рисунок 2.1 – Робота парсера двигуна для JavaScript
Синтаксичний аналізатор створює вузли на основі токенів, отриманих
від декодера байтового потоку. За допомогою цих вузлів створюється
абстрактне синтаксичне дерево (АSТ). Рисунок2.2 ілюструє процес створення
абстрактного синтаксичного дерева.
Потім інтерпретатор проходить через AST і генерує байт-код на основі
інформації, що міститься в AST. Після того, як байт-код повністю
згенеровано, АSТ видаляється, щоб звільнити місце в пам'яті. Байт-код
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 12
а
надсилається оптимізуючому компілятору разом зі з генерованими
прив'язками типів.
Оптимізуючий компілятор отримує байт-код і з генеровані прив'язки та
генерує з них високооптимізований машинний код [5].
Рисунок 2.2 – Створення абстрактного синтаксичного дерева
За допомогою NodeJs і JavaScript можна створити додаток, але це буде
складно і ні до чого доброго не приведе, оскільки JavaScript був створений
як мова для маніпулювання DOM-деревом сторінки. Для побудови інтерфейс
у потрібно використовувати HTML або CSS, які є стандартними
інструментами для верстки. Жодна з цих мов не має нічого спільного з
програмуванням, оскільки не має можливості маніпулювати пам'яттю або
створювати логічні структури. Перша використовується для побудови блоків
сторінки та створення семантичної розмітки, яка допомагає пошуковим
роботам аналізувати додаток; друга-для модифікації стандартного
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 13
а
візуального вмісту сторінки на основі розмітки HTML; третя - для створення
семантичної розмітки для сторінки на основі розмітки HTML.
Оскільки запланований додаток матиме важкий динамічний
користувацький інтерфейс, необхідно обрати компонентний фреймворк для
побудови інтерфейсу та оптимізувати розробку за рахунок ефективної
взаємодії з сервером. За останній рік лідерами серед компонентних
фреймворків стали React, VueJs та Angular.
Статистику популярності компонентних фреймворків станом на
2021рік наведено в додатку А.
Для реалізації інтерфейсу додатку було обрано React. Для дослідження
та порівняння буде застосовано 2 фреймворки – це React та Angular, оскільки
технологія Vue хоча і має непогану технологічну частину, але застосовуючи
досвід роботи з React та Angular дають можливість об’єктивного оцінювання
переваг та недоліків цих технологій. Два обрані для порівняння
фреймворкиза своєю функціональністю є зовсім різними, а тому порівнювати
їх це всеодно, що порівнювати яблука та апельсини. Але, оскільки, головна їх
функція побудова інтерфейсу і вони єнайпопулярнішими технологіями від
великих компаній Facebook та Google, дані фреймворкимають функціонал,
що є більш революційним ніж функціонал інших технології.
React являється бібліотекою, а Angular –це фреймворк. Це означає, що з
Angular можна отримати готову архітектуру з усіма необхідними для
розробки бібліотеками, протестовану командою розробників. В принципі,
більшість реалізованих бібліотек фреймворків покривають всі базові рішення
для створення додатків. Однак React, як бібліотека, також має більшість
рішень, що надають можливість легко досягти такої ж повної реалізації, як і
фреймворк, встановивши необхідні бібліотеки. Це означає, що React є більш
гнучким у своїй реалізації, дозволяючи розробнику використовувати лише те,
що було вирішено встановити самостійно [6].
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 14
а
Найбільша різниця між цими двома технологіями полягає в управлінні
станом об'єктів, а саме, Angular являється стандартом, що поставляється з
прив'язкою даних, в той час як React забезпечує односторонній потік даних і
вимагає Redax для обробки незмінних даних. Жодна з них не є кращою за
іншу, оскільки вони є протилежними підходами.
Angular являється більш типізованим і застосовує більшість рішень у
стандартному наданні коду, але всі переваги React можна отримати лише
застосовуючи різні бібліотеки для React. Гнучкість при побудові коду є
основною перевагою React. Оскільки, для великих Enterprise рішень
основним є типізація та контроль додатком написаного коду. Такі рішення
більш притаманні при розробці великою командою, але коли мова заходить
про розробку однією людиною, дуже тяжко щось зламати в процесі роботи з
React, в свою чергу, гнучкість прискорить розробку.
Як фреймворк Back-end буде застосовано Express. Фреймворк для
бекенду необхідний для більш комфортної розробки додатків
односторінкових та багатосторінкових. Фреймворк взагалі означає, що
більша частина коду вже реалізована. А це означає, що на основні рутинні
проблеми, що виникають при створенні додатків не потрібно зважати.
Особливості Express.js[7]:
швидка розробка на стороні сервера. Фреймворк надає багато
загального функціоналу для створення масштабованих додатків, що в свою
чергу призводить до економії часу;
Middleware (проміжне програмне забезпечення). Частина програми,
яка забезпечує доступ до бази даних, клієнтські запити та інші проміжні
програми;
Маршрутизація. Надання механізму маршрутизації, який допомагає
підтримувати стан сторінки за її URL- адресою;
шаблони. Механізм створення динамічного контенту на веб-сторінці
шляхом побудови HTML- сторінок на стороні сервера.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 15
а
Для передачі даних від сервера до клієнта необхідно використовувати
спеціальні механізми доставки даних. З основних існуючих механізмів
можна виділити лише два: REST і GraphQL; REST радить кілька ідей, таких
як сервери без статусу і структурований доступ до ресурсів. Однак REST API
виявився негнучким у задоволенні швидкозмінних вимог клієнтів, які
отримують до нього доступ, а GraphQL був розроблений для задоволення
потреб більш гнучких і ефективних. Також GraphQL усуває багато недоліків і
неефективності, з якими розробники стикаються при взаємодії з REST API.
Основна перевага GraphQL полягає в тому, щодо різних даних можна
отримати доступ в одному запиті, а сервер повертає дані у вигляді JSON.
REST API використовуються для доступу до декількох кінцевих точок
для отримання даних, і GraphQL буде корисним для цього проекту, оскільки,
він вирішує кілька проблем, пов'язаних зі специфікацією реалізації. Додаток
повинен обробляти велику кількість даних одночасно, і з збільшенням
кількості даних в зв’язках збільшується і кількість даних, які потрібно
просіяти під час обробки. При використанні REST API виникають проблеми
при отриманні даних. Наприклад, якщо потрібно отримати дані електронної
пошти і пароля з сервера під час аутентифікації, REST API має отримати всі
дані про користувача і використовувати дані, доступні в даний момент.
GraphQL може отримати тільки ті дані, які використовуються в процесі
обробки. Вирішення таких проблем називається "Надмірне завантаження".
Також є й проблема «Недобір даних» або «проблема n + 1». Недозабір
зазвичай означає, що певна кінцева точка не надає достатньої кількості
необхідної інформації. Для того, щоб отримати все необхідне, потрібно
виконати додаткові запити. Це може призвести до ситуації, коли клієнту
спочатку потрібно завантажити список елементів, а потім зробити по одному
додатковому запиту для кожного з елементів, щоб отримати необхідні дані.
Також можна точно вказати, яка саме інформація цікавить кожного клієнта,
таким чином отримуючи глибоке розуміння того, як використовуються
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 16
а
наявні дані. За допомогою GraphQL дані, що запитуються з серверної
системи можна проаналізувати детально [8].
Оскільки у додатку застосовується строга типізація даних, буде добрим
рішенням розробити типізацію і для даних, що передаються за запитом
клієнта. GraphQL застосовує сильну систему типізації, яку можна
застосовувати без додаткових бібліотек. Усі типи даних, що налаштовуються
в API, записуються у схему при допомозі мови визначення GraphQL SDL.
Дана схема слугує місточком між клієнтом та сервером, що визначає спосіб
доступу клієнта до даних. Це є дуже важливим, оскільки, після того, як схему
було визначено, в процесі роботи в команді, що працюють над інтерфейсом
та серверною частиною, можуть робити кожен свою частину роботи без
подальшого обговорення, оскільки, вони всі знають певну структуру даних,
що пересилається по мережі.
Використання GraphQL також покращує інтерактивність інтерфейсу.
Якщо порівнювати це рішення з REST API, то воно є прикладом
структурування кінцевих точок відповідно до дисплею програми. Це
комфортно, оскільки клієнту потрібно лише звернутися до певної точки, щоб
отримати всю інформацію, необхідну для конкретного дисплея. Основним
недоліком цього підходу є те, що його не можна швидко змінити на
інтерфейсі. Кожного разу, коли змінюється користувацький інтерфейс, існує
більший ризик того, що потрібно більше або менше даних, ніж раніше. Тому
внутрішня система також повинна бути скоригована, щоб відповідати новим
потребам у даних. Це знижує продуктивність і значно уповільнює
можливість введення нових динамічних елементів в продукт, а GraphQL
вирішує цю проблему, надаючи гнучку функціональність, що дозволяє
вносити зміни на стороні клієнта без будь-якої додаткової роботи на сервері.
Оскільки клієнт може вказати точні вимоги до даних, розробнику сервера
непотрібно вносити жодних змін у разі зміни дизайну інтерфейсу або
даних [6].
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 17
а
Останньою основною архітектурною частиною, яку необхідно
розробити при створенні додатку – це База даних. Із основних відомих та
доступних баз даних, що можна використати при розробці проекту – це бази
даних двох типів: реляційні бази даних та нереляційні бази даних (NoSQL).
Реляційні Бази даних – назва походить від того, що тип з'єднання даних
є реляційним, тобто логічні структури даних, такі як таблиці даних, подання
та індекси, відокремлені від фізичних структур зберігання. Це тип Бази
даних, який зберігає пов'язані між собою точки даних і забезпечує доступ до
цих даних. Дані зберігаються у вигляді стовпців і рядків таблиці. Кожен
рядок таблиці представляє запис, стовпець таблиці – атрибут, а кожне поле в
таблиці – значення даних. Реляційні бази даних використовує у кожній
таблиці, що має ключове поле, яке вказує однозначно на кожен рядок. Дані
ключові поля можна застосовувати в процесі підключення однієї таблиці
даних до іншої. Розглянутий тип бази даних являється найбільш популярним
та широко використовуваним. Реляційна база даних має переваги для
застосування у високонавантажених та простих системах [9]:
 відносно проста у використанні. Якщо необхідно використовувати базу
даних на основі цієї моделі без потреби занурюватися в конфігурацію
системи. Мова SQL надає можливість швидко навчитися і ефективно
застосовувати базу даних для своїх цілей;
 відповідати певним правилам цілісності. Наприклад, правило для
цілісності можуть показувати, що в таблиці не допускаються дублікати
рядків, щоб виключити можливість входження в базу даних некоректної
інформації;
 збереженість процедур. Реляційні бази даних надають можливість для
зберігання процедури-блоки коду, до яких можна отримати доступ,
просто викликавши програму. Наприклад, одна збережена процедура
надає можливість забезпечити узгоджені мітки для записів користувачів
на декількох додатках;
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 18
а
 блокування та паралельність баз даних. Конфлікти можуть виникати,
коли кілька користувачів або додатків намагаються одночасно змінити
одні й ті ж дані. Блокування та паралелізм зменшують ймовірність
конфліктів, зберігаючи при цьому цілісність даних. Блокування запобігає
доступу інших користувачів або програм до даних під час їх оновлення.
У невеликій кількості баз даних блокування застосоване до всієї
таблиці, що має негативний вплив на програмну продуктивність. Інші бази
даних, наприклад, реляційні бази даних Oracle, використовують блокування
на рівні записів, при цьому, залишаючи інші записи в таблиці доступними,
що в свою чергу, допомагає забезпечити кращу програмну продуктивність. У
випадку, коли деяка кількість користувачів або додатків одночасно
виконують запити в одній базі даних, даною діяльністю керує паралельність.
Дана можливість надає можливість правильного доступу до користувачів та
додатків відповідно до політик, що визначені для контролю даних. Наведемо
декілька прикладів існуючих, на сьогоднішній день, баз даних на основі
реляційної моделі: MySQL, Oracle,SQLite, PostgreSQL,IBM DB2.
Нереляційні бази даних – на відміну від традиційних реляційних баз
даних, є те, що вони зберігають дані в нетабличному форматі. Тому
нереляційні бази даних можуть базуватися на структурах даних, подібних до
документів. Хоча документи можуть бути дуже детальними, вони можуть
містити багато різних типів інформації в різних форматах. Таким чином,
нереляційні бази даних набагато гнучкіші, ніж реляційні, оскільки різні типи
інформації можуть бути організовані поруч. Нереляційні бази даних частіше
використовуються, коли потрібно упорядити великі обсяги складних і
різноманітних даних. Нереляційні бази даних можуть бути швидшими,
оскільки їм не потрібно переглядати кілька таблиць, щоб отримати відповідь,
як у випадку з реляційними базами даних. Отже, нереляційні бази даних
ідеально підходять для зберігання даних, які часто змінюються, і для
додатків, які мають справу з багатьма різними типами даних. Нереляційні
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 19
а
бази даних можуть підтримувати додатки, що швидко розвиваються і
потребують динамічної бази даних, яка швидко змінюється і має справу з
великими обсягами складних неструктурованих даних [9].
Переваги нереляційних баз даних:
призначений для хмарного хостингу. Нереляційні бази даних можуть
бути чималими. А в деяких випадках, вони можуть зростати в геометричній
прогресії, вимагаючих остингового середовища, яке може рости і
розширюватися;
чимала організація наборів даних. Бази даних не тільки можуть
зберігати великі обсяги інформації, але й легко виконувати запити до цих
наборів даних. Масштаб і швидкість є ключовими привілеями нереляційних
баз даних. Це стосується процесора, вводу/виводу, пам'яті та ін.. Реляційні
бази даних з відкритим вихідним кодом не дадуть таких же результатів, як
деякі нереляційні бази даних;
гнучке розширення бази даних. Дані не є статичними. Коли
збирається більше інформації, нереляційні бази даних можуть поглинати ці
нові точки даних і наповнювати існуючу базу даних новими рівнями
часткових значень, навіть у випадку, якщо вони не збігаються з типами даних
існуючої інформації.
Дослідивши обидва типи баз даних можна виділити 3, які будуть
служити кращою СУБД: MySQL, MongoDB, PostgreSQL.
MongoDB – це нереляційна база даних, яка залежить від конкретного
застосування і не може бути панацеєю для всіх додатків. Є кілька ситуацій,
коли база даних на основі документів може бути корисною[9]:
¾структура даних невизначена, у тому випадку, коли починаєте
використовувати базу даних. Іншими словами, MongoDB є корисним
інструментом, коли структура типів бази даних сильно змінюється кінцевим
додатком (це також може бути реалізовано за допомогою SQL, який може
змінювати типи, але з якою швидкістю);
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 20
а
¾плануються великі обсяги даних, а також швидке збільшення нових
даних. Це дуже специфічна перевага, оскільки доступ до даних, тобто
швидкість запису в базу даних і читання з неї, зазвичай може бути досягнуто
за допомогою власної бази даних, яку можна розширити, якщо дозволяє
апаратне забезпечення, але дизайнер і замовник повинні вирішити, чи варто
дані зміни робити програму.
MySQL є реляційною базою даних і не вимагає складної конфігурації.
Її можна гнучко конфігурувати відповідно до потреб користувача, але в
такому випадку, будь-яка конфігурація буде діяти як вузький прохід у
додатку. Єдиними перевагами цього інструменту є його простота, здатність
системи створювати бази даних за допомогою SQL, реляційна модель та її
транзакційна природа. Якщо говорити про недоліки даної бази даних, то вони
є більш критичними, а саме:
чутливість до нестабільності сервера. Якщо неправильно завершити
MySQL можна зламати деякі таблиці з даними, які в подальшому можна буде
відновити тільки з цілого бекапу, і лише в тому випадку, якщо вони існують.
В останніх версіях заявлена більш велика стабільність до таких ситуацій;
зміна структури даних може бути дуже важким процесом, тим більше
якщо зав’язків між таблицями багато;
погана продуктивність. Навіть кластер не допоможе перебільшити
показник в приблизно 20 МБайт у секунду.
PostgreSQL – база даних схожа на MySQL але є кращою якщо
правильно її налаштувати. Дуже стабільна СУБД, у якої майже відсутня
можливість впасти та втратити дані в таблицях при навантаженні, що може
стати вирішальним фактором при обранні бази даних. База даних є гнучкою у
схемі даних та представлена у вигляді JSON, BJSON. Проста та зручна при
розширюванні в кластери та процесі шардингу таблиць [10].
Підсумовуючи вище сказане можна зробити наступні висновки, що
MongoDB, як база даних для розробки додатку – не підходить, оскільки
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 21
а
додаток не потребує швидкого росту і власне сама база даних навряд чи
досягне розміру до 200-300 гігабайтів за короткий проміжок часу, а також
відсутність транзакційності у своєму стандартному вигляді викликає
труднощі при оптимізації системи та викликає проблеми, які необхідно буде
вирішувати самостійно розробляючи код. Взагалі, бази даних типу, що
розглядається, потребують більш специфічного рішення, можливо,
наприклад, як додаткова база даних для збору великогооб’єму інформації за
короткий проміжок часу та в подальшому її обробки. MySQL та PostgreSQL
побудовані на реляційній архітектурі, що показала свою стабільність за всі
роки існування. В той же час ці бази даних відрізняються за своїм
фунціоналом.
MySQL має низьку пропускну здатність та потребує великої кількості
оптимізації задля досягнення хороших показників. PostgreSQL на противагу
MySQL є об'єктно-реляційною базою даних, в той момент, як MySQL є
просто реляційною базою даних. А, це означає, що PostgreSQL включає в
себе наступний функціонал: успадкування таблиці та перевантаження
функцій, що в деяких випадках може бути важливим приреалізації певного
функціоналу. PostgreSQL реалізує Multiversion Concurrency Control (MVCC)
функції без блокування читання. PostgreSQL підтримує паралельні
планування запитів, які можуть бути використанні кількома
процесорами/ядрами, а також PostgreSQL може створювати індекси
неблокуючим способом.
Для розробки додатку в кваліфікаційній роботі бакалавра буде
застосовано базу даних PostgreSQL, як інструмент з високим потенціалом і з
легким розширенням.
В процесі роботи та застосування бази даних в додатку необхідно
застосовувати ОРМ. ОРМ являється інструментом для процесу mapping між
об’єктами та системами баз даних. Тобто, різні системи баз даних мають
доступ до даних різноманітними способами, а ORM надає допомогув
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 22
а
підтримці об’єктів, навіть у тому випадку, коли джерела та програми, до яких
вони хочуть отримати доступ, змінюються з часом. ORM, як правило,
використовується в процесі впорядкування передачі даних між базами даних.
Переваги застосування ORM [10]:
запит для декількох таблиць. Навіть у випадку використання
нереляційних баз даних ОРМ надає змогу виконувати запити до декількох
таблиць;
легкий перехід з однієї бази даних на іншу. Додаток не повинен бути
прив’язаний до ОРМ і бази даних. Вся бізнес логіка додатку повинна бути
ізольована, тобто відокремлена від ОРМ. В такому випадку переходити між
базами даних або ОРМ легше;
виключення зайвого коду. ОРМ працює на одній і тій же мові, що і
додаток.
Для ОРМ реалізованого в кваліфікаційній роботі бакалавра додатку
буде застосовано бібліотеку TypeORM, оскільки дана ОРМ вміщує в себе
бібліотеку TypeScript, що володіє кращою документацією ніж інші ОРМ,
наприклад, такі як: Sequelize, Bookshelf.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 23
а
3 ПРОЕКТУВАННЯ ТА ПОБУДОВА АРХІТЕКТУРИ
ПРОГРАМНОГО ПРОДУКТУ
3.1 Опис поверхневої архітектури
В додатку, що розробляється повинен бути реалізований визначений
функціонал. Під час реалізації додатку його структура може виглядати
структурованою та лаконічною, але з його подальшою розробкою можна
отримати засмічення проекту, оскільки при розробці не було використано
шаблони проектування (Patterns) та кращі практики програмування (Best
practices).
Основною концепцією, що була застосована при побудові додатків,
була концепція «Розшарування» системи. Суть даної концепції полягає у
розділені великих частин системи на більш прості частини.
На рисунку 3.1 наведено основну архітектура додатку, що
розробляється.
Першим шаром в системі побудованій на концепції “Розшарування”
являється рівень представлення. Даний рівень представлення
повинензабезпечувати огляд усього, що відноситься до можливостей
комунікації користувача з системою. При реалізації такими засобами можуть
бути: текстовий інтерфейс, командний інтерфейс (CLI)або графічний
інтерфейс. Графічний інтерфейс при реалізації додатку буде застосований у
вигляді шару представлення у додатку. Клієнтом, що буде вступати у
взаємодію з функціоналом серверної частини буде Браузер. Клієнт (браузер)
буде комунікувати з серверною частиною через 2 додатки.
Одним з них є SPA додаток (Single Page Application), що буде
реалізовано з використанням технології ReactJS. Для комунікації замовника
та виконавця буде застосовано додаток, що виконаний у вигляді чату та
реалізований на ReactJS. Даний додаток буде працювати на стороні сервера
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 24
а
за допомогою веб-сокетів. Інтерфейсна частина проекту буде
реалізовуватися, як окремий додаток, мати свою архітектуру та запускається
окремо від серверної частини в наступних проектах.
Рисунок 3.1 – Візуальне представлення архітектури додатку, що
розробляється
Інтерфейсом, що використовується для комунікації між сервером та
додатками є API розроблене на основі структурованої мови GraphQL. Інакше
кажучи, клієнтський додаток завантажується окремо, при цьомузастосовує
свої статичні ресурси під час відображення інтерфейсу, а при наступному
кроці отримує дані з серверу за запитомвикористовуючи API.
При наступному кроці, запити співпрацюють з логікою домену, а саме,
з логікою предметної області та бізнес логіка. Основний функціонал додатку
описує саме доменна логіка. Сюди можна віднести обрахунки на основі
отриманих даних, обробку команд, які були надіслані від шару
представлення перевірка та безпосередньо отримання даних. Сервер, що
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 25
а
запущенопри застосуванні NodeJS, back-end на основі Express,при
використанні описаного функціоналу виконує операції над даними. Сервер
також виконує деякі операції на back-end, які не можуть бути виконані у
реальному часі, але повинні бути виконані - застосовують функціонал черги.
Даний функціонал черги являється базовим функціоналом операційної
системи, що має назву CRON. До функціоналу відкладеного виконання
відноситься: логування (використовується для отримання звітів про роботу
системи та запис інформації у файл) та відправка пошти у вигляді запиту на
сервіси, а саме, пошти SMTP (Simple Mail Transfer Protocol).
Шар домену також відповідає за передача даних до джерела даних.
Третім шаром в концепції «Розшарення» є шар джерело даних. Даний
шар в своїй реалізації являє підмножину функцій, які встановлюють
взаємодію зі сторонніми системами та забезпечують виконання завдань в
інтересах додатку. Реалізований код для цієї категорії відповідає за
моніторинг транзакцій, обмін повідомленнями,управління іншими додатками
і так далі. Для більшості Enterprise додатків основна частина логіки для
джерела даних міститься в одній СУБД.
Не зважаючи на те, що концепція “Розшарення” є основним концептом,
що використовується при побудові більшості додатків, все ж таки спосіб
його реалізації напряму залежить від рівня складності розроблюваного
додатку.
Форма концепції «Розшарення» може бути довільного формату, але у
кожному розроблюваному додатку має бути ідентифікованою. Крім
розглянутого вище функціоналу, в процесі написання додатку буде
застосовано правило, яке торкається взаємодії шарів, тобто,не допускається
залежність бізнес-логіки та джерела даних від рівня представлення. Це
означає, що в коді додатку не має бути викликів функцій представлення з
коду джерела даних або бізнес логіки. Дане правило надає можливість
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 26
а
спростити можливість адаптації для рівня представлення або замінитирівень
альтернативним варіантом зі збереженням основи додатку.
Для правильної роботи та підтримки системи «Розшарування»
необхідно організувати структуру папок. Правильно організована структура
папок має важливу роль, оскільки розуміння того, що та куди покласти
прискорює розробку. Також при розробці додатку командою розробників –
це являється обов’язковою умовою, оскільки, у кожного розробника свій
стиль написання коду, який потрібно стандартизувати в один вигляд. Також
така структура забезпечує чіткість розуміння того, яка саме функціональність
і де використовується, а також дозволяє організувати код в окремі
контейнери, якими потім простіше керувати.
На рисунку 3.2 наведенозаплановану архітектура серверної частини,
що відповідає концепції розшарування.В процесі реалізації архітектура
серверної частини може доповнюватися.
В процесі створення додатку будуть застосовані визначенні підходи до
написання коду програми.
Нижче наведено перелік практик, що використовуються:
DRY (Don’t Repeat Yourself). Дана практика перекладається, як «Не
повторюйся». Основне правило, якого необхідно дотримуватися в процесі
реалізації програмного забезпечення для даної практики, спрямоване на
зменшення повторення інформації в коді. Кожна частина логіки програми
повинна мати лише одне, однозначне подання в системі.
SRP (Single Responsibility Principle). Принципом даної концепції є те,
що будь-який окремий об'єкт побудований за правилами об'єктно-
орієнтованого програмування (ООП) має бути розроблений для однієї
визначеної функції.
(KISS) “Keep it simple, stupid”. Даний принцип KISS являється
описовим, і дозволяє зробити код програми простим і зрозумілим для
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 27
а
полегшення його розуміння. Для того, щоб полегшення розуміння коду без
його запуску непотрібно робити його складним.
YAGNI (You ain’t gonna need it). Дане правило означає «Вам це не
знадобиться» і використовується при створенні програмного забезпечення.
Суть даного твердження в тому, що деякі властивості, щоє потребами
розроблюваного програмного забезпечення в майбутньому, не потрібно
створювати зараз, оскільки, на даний момент «це вам не знадобиться».
Рисунок 3.2 – Структура файлів реалізованої серверної частини проекту
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 28
а
3.2 Побудова та проектування серверної архітектури програмного
забезпечення
Бізнес логіка додатку, під час своїх найгірших реалізацій, буває дуже
складною із застосуванням великої кількості правил та умов, що описують
різні варіанти використання реалізованої системи та особливості її
поведінки. Для полегшення усунення розглянутих труднощів і призначені
об'єкти.
В процесі проектування серверної частини додатку, необхідно
орієнтуватися на наступні три основних патерни, що використовуються при
реалізації бізнес логіки додатку:
1) сценарій транзакцій додатку (Transaction Script);
2) модель предметної області додатку (Domain Model);
3) модуль таблиці додатку (Table Module).
Сценарій транзакцій додатку(Transaction Script)являє собою
найпростішу реалізацію бізнес логіки. Розроблювані додатки для даного
патерну може сприйматися, як послідовність транзакцій. Одна з транзакцій
спроможна модифікувати дані, інша з них, сприймати дані в
структурованому вигляді. Певним фрагментом логіки описується кожен
процес взаємодії клієнта з сервером. Процес організації логіки
обчислювального процесу з використанням патерну (шаблону) організовано
переважно у вигляді єдиної процедури, що звертається безпосередньо до бази
даних або через взаємодію з кодом через оболонку.
Принцип дії патерну - сценарій транзакцій, заключається в наступному:
логіка роботи розподіляється по транзакціях, що виконуються в системі. При
цьому структурувати код по модулях необхідно обґрунтовано. Застосування
підходу, що розглядається, не повинно викликати труднощів, при умові, що
транзакція не виявилася занадто складною.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 29
а
Особливість підходу, що буде застосовано при реалізації серверної
частини додатку, полягає в наступному: немає необхідності турбуватися про
існування та варіативності функціонування інших паралельних транзакцій.
Місце розташування сценарію буде залежати від організації системи.
При застосуванні моделі предметної області (Domain Model) додаток
буде побудовано з використанням додаткового шару об'єктів. Об'єктно-
орієнтована модель предметної області схожа на схему відповідної існуючої
бази даних, але все ж між ними є багато відмінностей.
Відомо два типи реалізації шаблону моделі предметної області:
простий та складний. Простий шаблон дуже схожий на схеми бази даних, а
також містить в собі по одному об'єкту домена з розрахунку на кожну
таблицю. Складний шаблон відмінний від структури бази даних і може
включати ієрархії та успадкування. Складна модель предметної області
відображає заплутану бізнес логіку більш адекватно, але складніша в процесі
відображення у вигляді реляційної схеми бази даних. Однією з типових
проблем бізнес-логіки є надмірне збільшенням об'єктів. Для виключення
даної проблеми цього можна розмежувати функціонал. Розглянемо
наступний приклад, об'єкт для замовлення машини має деякий перелік
функцій, що відрізняються специфічним характером та вузьким
призначенням. При реалізації даного об’єкту, якщо покласти на один клас
всю логіку, що необхідно реалізувати, можна збільшити клас до величезних
розмірів. Для того, щоб уникнути ситуації збільшення класу, необхідно
виділити загальні характеристики замовлення таописати їх в однойменному
класі, а інші характеристики винести у допоміжні класи та реалізувати у
вигляді шару “представлення” або “сценарію транзакцій”.
Від ступеня складності поведінки системи залежить їївикористання.
Якщо розробка програмного забезпечення передбачає часто змінюванні
бізнес-правила, що включають розгалуження,перевірки, обчислення та ін., в
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 30
а
такому випадку для їх реалізації розглянутий патерн цілком підходить. Якщо
реалізований додаток набагато простіший, тобто, в ньому реалізовано пару
операцій обчислення, то в такому випадку краще використовувати “сценарій
транзакцій”.
Одна з проблем предметної області полягає в створенні інтерфейсів для
реляційних баз даних. Суть цієї проблеми полягає в тому, що зчитування і
запис інформації з бази даних з необхідними її перетвореннями
ускладнюється.
Модуль таблиці (Table Module) передбачає дотримання принципу
«SOLID», тобто розробка по одному класу на кожну таблицю бази даних, а
також створення єдиного екземпляру класу, що містить всю логіку обробки
даних в таблиці. Розроблюваний патерн відрізняється від існуючого тим, що
при обслуговувані додатком безлічі запитів на поїздку відповідно до моделі
предметної області (Domain Model) буде створено окремий об'єкт для
кожного замовлення. Модуль таблиці додатків (Table
Module)передбачаєрозробку всього одного об'єкта, що об’єднує всі
замовлення.
В додатку, що розробляється, буде застосовано перший шаблон, а саме
“сценарій транзакцій”. Як показує практика, даний шаблон являється кращим
рішення,оскільки необхідно враховувати потреби в деяких реалізаціях. При
зміні напрямку та функціоналу додатку можна легко адаптувати його код під
інший функціональний підхід, як і навпаки, але навпаки не є необхідним.
Вибір рішення для розробки додатку витікає з його призначення, головним
рішенням якого є простота. Для невеликих додатків дуже характерним і
природним є саме такий тип організації логіки, що є ефективним з точки зору
сприйняття і продуктивності. В міру того, як буде ускладнюватися логіка
програмного забезпечення, буде розумніше використовувати другий шаблон
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 31
а
- “представлення”. Розмір додатку, що розробляється, не вимагає додавання
цілого шару об'єктів для ефективної його реалізації.
Розглянутий вище шаблон являється основний при побудові серверної
частини. При реалізації правильної структури додатку необхідно
використовувати розумний стек шаблонів. Не зважаючи на те, що шаблони і
не являються “срібною кулею” при написанні коду програми, але все ж таки
вони являються тою практикою, яка пройшла час і описує всі можливі
основні кроки, що застосовуються для побудови ефективного функціоналу.
Зазвичай, при створенні бізнес логіки додатку, необхідно розділити її
на 2 частини:
1. Логіка домену (Domain Logic), що працює тільки з предметною
областю;
2. Логіка додатку (Application Logic), що описує сферу відповідальності
додатку.
Не бажано розміщувати реалізацію логіки додатку в основних класах
домену, оскільки це може призвести до небажаними наслідків.
По-перше, якщо клас реалізує специфічну логіку програми та залежить
від різних інструментів – це зменшує ймовірність повторного використання
класу домену.
По-друге, змішування двох категорій логіки в поєднанні одних і тих же
класів викликає труднощі при можливій новій реалізації логіки додаткута
привикористанні специфічних інструментальних засобів, за умовою, що
виникає така необхідність.
У таких випадках використовується ще один шаблон, який має назву
“шар служб (Service Layer)”, що включає розподіл логіки за окремими
шарами та забезпечує переваги розшарування.
На рисунку3.3наведено визначені шари та місця розташування
кожного з сервісів відносно архітектури додатку, що буде реалізовано.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 32
а
Рисунок3.3 – Архітектура додатку, що розробляється з використанням
сервісу
3.3 Проектування архітектури інтерфейсу
Для розробки інтерфейсу додатку використовуються макети
інтерфейсу та написаний на компонентному фреймворку додаток.
Оскільки досить важливо, щоб додаток виглядав та взаємодіяв
відповідно до визначеного функціоналу та був вбудований у платформу для
якої розробляється, використовується компонентний фреймворк. Сучасні
бібліотеки реалізованих компонентів для розробки інтерфейсу користувача
мають широкий набір частин, що доступні для розробника. Такими
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 33
а
компонентами може бути перелік елементів від кнопок до елементів
введення, випадаючих списків і так далі.
Для реалізації інтерфейсу користувача необхідні і більш прості
компоненти, а саме, заголовки, панелі вкладок і сітки. Основна проблема,яка
при цьому виникає полягає в тому, що Інтернет,на початку свого створення,
не проектувався як платформа додатків, а був побудований для об'єднання
дослідницьких робіт. При використанні інструментів для мережі Інтернет
доступні деякі компоненти HTML, а саме кнопки, введення, перемикачі,
повзунки, таблиці та багато іншого, все ж таки їх недостатньо для коректної
розробки у сучасних додатках призначеного для користувача інтерфейсу.
Під час написання коду для програмного забезпечення буде
застосовуватися ReactJs разом з іншими бібліотеками, що на дасть
можливість комфортно розробити інтерфейс додатку.
Наведемо перелік бібліотек, що будуть використанні в процесі
розробки програмного додатку:
react-router – додаткова бібліотека від ReactJS,що буде використана для
створення маршрутизацію та на дасть можливість відображати різні сторінки
в додатку та отримувати різні дані;
apollo – бібліотека, що встановлюється разом з іншими бібліотеками,
основною задачею якої є забезпечення правильного функціонування додатку.
Вона на дасть можливість виконувати запити з використанням graphql на
сервер та отримувати дані в форматі json, що в подальшому будуть
використовуватися під час відображення даних в уже скомпонованих та
описаних компонентах;
axios. Це розширена бібліотека, що застосовується для серверної і
клієнтської частини,та робить запити на сервер для отримання даних. Дана
бібліотека відповідає за автоматичне перетворення відповіді від сервера в
json формат, а також відправляє і скасовує запити;
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 34
а
google-maps-react. Стандартна бібліотека від React,що допомагає
використовувати google карти для відтворення місцевості. Додаток,що
розробляється, повинен мати таку інтеграцію для відображення клієнта і
водія на карті;
typescript. Бібліотека,що являється надбудовою над javascript та надає
можливість зробити додаток більш контрольованим і стабільним.
На рисунку 3.4наведено структуру проекту для розробки інтерфейсу
для користувача.
Рисунок. 3.4 – Структура проектної частини інтерфейсу користувача
Структура ReactJs програми не є строгою, а це означає, що в більшості
випадків можна розробляти будь-яку ієрархію каталогів, і головне, щоб всі
компоненти додатку були підключені до свого батьківського компоненту або
головного компоненту, що в свою чергу, підключений до головного або до
іншого батьківського компоненту. Також є переваги і для побудови
правильних структур, які додатково використовуються як шаблон.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 35
а
3.4 Проектування архітектури бази даних додатку
На сьогоднішній день, існує велика кількість додатків, які не
вимагають довготривалого зберігати дані, але існують і такі програми,
основною задачею яких є зберігання стану об'єкта. Для розроблюваного в
рамках кваліфікаційної роботи бакалавра додатку основною задачею є
довготривале зберігання даних та надавати можливість маніпулювати цими
даними різними способами.
У звичайному вигляді, для реалізації бізнес логіки програмного
продукту, більшість використовуваних даних повинна зберігатися в базі
даних. Для реалізованого програмного додатку було обрано реляційний тип
бази даних.
На рисунку 3.5 наведено перелік таблиць, що входять до бази даних,
що буде реалізована в даній кваліфікаційній роботі бакалавра.
Рисунок. 3.5 – Структура схема бази даних проекту
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 36
а
Для кінцевого продукту реалізована база даних може відрізнятися від
початкової.
Інструментом, що використовується для роботи з розроблюваною
базою даних на рівні коду програми виступає TypeORM. Використання ORM
являється нормальною практика при написанні програмних додатків,
оскільки використання даного інструменту спрощує багато задач.
Використовуючи відомі підходи під час реалізації та використання
даних можна отримати приріст швидкості розробки. Існує 2 основних
шаблону, які вирішують дану задачу:
Data Mapper;
Active Record.
Реляційні тип бази даних та об'єкти застосовують різні механізми для
структурування даних. Дані бази даних не відображають більшість
характеристик об'єктів, наприклад, колекції та спадкування. В процесі
побудови об'єктної моделі, що оперує великим обсягом бізнес-логіки
застосування даних механізмів дозволить краще організувати дані та
поведінку, що цим данимвідповідає. Але це, може призвести і до деяких
негативних наслідків, наприклад, до розбіжностей об'єктної та реляційних
схем.
Зазвичай, об'єктна модель даних та реляційна база даних повинні
виконувати обмін даними між собою, а проблема розбіжності схем може
ускладнити дане завдання. В разі, якщо об'єкт з об’єктної моделі
ознайомленийіз структурою реляційної бази даних, то зміна хоча б однієї з
моделей призводить до необхідності зміни для іншої.
Для вирішення такої задачі найчастіше використовується Data Mapper,
щоявляє собою шар програми, який визначає об'єкти, які будуть розміщені в
оперативній пам'яті, відокремлено від бази даних. Основною задачею Data
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 37
а
Mapper являється передача даних між об'єктами і базою даних, та їх ізоляція
один від одного.
Завдяки використанню даного шаблону об'єкти, що поміщуються в
оперативну пам'ять можуть і не підозрювати про існування бази даних. Тому
зазвичай, об’єктам і не потрібний інтерфейс SQL або схема даних, в свою
чергу, схема бази даних не знає про об'єкти, що її використовують. За цим же
правилом Data Mapper також прихований від рівня домену. Основною
функцією Data Mapper є процес, що забезпечує можливість змінюватися
схемі бази даних та об'єктній моделі незалежно один від одного.
Як правило, дана необхідність виникає також і в процесі застосування
шаблону Domain Model. Основною перевагою Domain Model є можливість
роботи з даними без врахування структури бази даних, як на етапі
проектування, так і в процесі тестування проекту або його збірки, при умові,
що мова йде про компільовані додатки. Для даного випадку створеним
об'єктам домену не відома структура бази даних, оскільки всі виведення
виконуються перетворювачами.
Основна перевага, що притаманна Data Mapper поширюється
безпосередньо і в процесі написання коду програми, оскільки надає
можливість працювати з об'єктами домену без застосування принципу
зберігання необхідної інформації в базі даних. В разі зміни шаблону Domain
Model не виникає необхідності змінювати структуру бази даних, а також у
разі, якщо наявні складні відображень, і особливо,в тому випадку, коли
потрібно використовувати готову базу даних.
Але незважаючи на всі переваги даних шаблонів, їх використання може
створювати і деякі проблеми. У поточному рішенні такою проблемою є
розробка нового шару коду. Для того, щоб уникнути даної проблеми можна
використати альтернативний підхід Active Record для роботи з даними.
Підсумовуючи вище сказане можна визначити, що основним критерієм для
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 38
а
вибору підходу та шаблону в процесі реалізації являється складність бізнес
логіки.
Основним правилом є те, що використовувати Domain Model без Data
Mapper можна, але не навпаки. Якщо модель для розробки є досить простою,
а розробник контролює сам всі зміни, що вносяться в структуру бази даних,
то використання Active Record не призведе до небажаних наслідків.
Active Record являється об’єктом, що виконує роль оболонки для рядка
таблиці або представлення бази даних. Active Record інкапсулює доступ до
бази даних, а також додає до даних логіку домену[11].
Якщо говорити простіше, то даний об'єкт охоплює і дані і поведінку
системи. Оскільки більша частина даних є постійною, то вони повинні
зберігатися в базі даних. Розглянутий шаблон застосовує більш очевидні
підходи для яких логіка доступна до даних включаючи і об'єкт домену. При
застосуванні даного шаблону додаток знає як зчитувати з бази дані, і як
записувати їх в базу. В основі шаблону Active Record лежить Domain Model
логіка, а саме класи, що повторюють структуру записів бази даних, що
використовується. Кожний активний запис відповідає за збереження та
завантаження інформації в базу даних, а також за саму логіку домену, що
застосовується даними.
Структура даних для Active Record має точно відповідати таблиці бази
даних. Тобто, кожне поле об'єктуповинне відповідати одному стовпцю
таблиці. Якщо говорити про значення полів, то їх слід залишати такими ж,
якими їх було отриманояк результат виконання запиту, оскільки жодного
перетворення на даному етапі робити непотрібно [12].
Методи шаблону Active Record призначені для виконання таких
операцій:
створення нового екземпляру Active Record та подальшого його запису
в таблицю;
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 39
а
створення екземпляру Active Record на основі рядка, що був отриманий
як результат виконання запиту;
оновлення бази даних, а також вставка даних з об'єкта в неї;
статичні методи пошуку для виконання стандартних запитів та
повернень Active Record;
розробка частини фрагментів бізнес логіки;
використання методів get і set для витягування та встановлення значень
полів.
Класи, що створюються з шаблоном Active Record є дуже зручними для
розробки, але в свою чергу, не дають можливість повністю відокремитися від
реляційної бази даних. Даний недолік надає можливість застосовувати менше
шаблонів, що призначені для відображення об'єктної моделі на основі бази
даних.
Оскільки Active Record сильно пов'язана з базою даних, то кращою
практикою вважається застосовувати для цього шаблону статичні методи
пошуку. В процесі реалізації додатку для кваліфікаційної роботи методи
пошуку не буде виділено в окремий клас, оскільки в такому випадку
використанні рішення стануть схожими на інший шаблон. Великою
перевагою під час використання даного шаблону є не тільки табличне
рішення, а й рішення, що використовуються для представлень і запитів.
Одним із головних критеріїв для вибору шаблону Active Record для
реалізованого проекту є те, щовін добре підходить для не сильно складної
логіки домена [13].
А саме оновлення, створення, видалення та зчитування. Також даний
підхід добре справляється із задачею при вирішенні якої необхідно
витягувати та перевіряти на правильність окремий запис. Оскільки головною
перевагою Active Record є простота, але він також і не позбавлений
недоліків. Основним таким недоліком є те, шаблон добре себе показує лише
в тому випадку, коли він точно накладається на ізоморфну схему.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 40
а
У випадку, коли додаток є складним, більшість розробниківпри такій
умові захоче застосувати,наприклад,колекції і спадкування, але такий спосіб
не досить добре виводиться на обраному шаблоні. При умові ще й додавання
цих елементів в шаблон частково може призвести до ускладнення того, що
відбувається в коді програми.
Принцип роботи додатку при застосуванні шаблону Active Record та
TypeORM заключається в тому, що більша частина стандартного
функціоналу для маніпуляції даними вже розроблено, а також реалізовано і
модель даних, яка співпрацюєіз схемою розробленої бази даних, а також
розширюється за рахунок стандартного класу BaseEntity.
На рисунку 3.6 наведено принцип застосування шаблону Active Record
та TypeORM.
Рисунок 3.6 – Розширення класу моделі додатку з використанням TypeORM
класу
При застосуванні нового класу, що описує архітектуру таблиць з
використанням існуючого шаблону можна розширити готовий функціонал
додатку при цьому одержати усі корисні функції для роботи з даними.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 41
а
3.5 Проектування прототипу графічного інтерфейсу
Інструментами для розробки інтерфейсу додатку, щоб він виглядав
однаково на різних пристроях і для різних розмірів екрану являється Auto
Layout та Stack View.
Auto Layout являється інструментом, що робить динамічне обчислення
розміру та позицій всіх елементів інтерфейсу основуючись на правилах
заданих для того або іншого з елементів. Даний інструмент надає розробнику
можливість розробити один єдиний інтерфейс без вимоги у підганянні
розмірів під визначені розміри екранів пристроїв. Auto Layout основуючись
на правила робить це самостійно, тобто динамічно змінюючи інтерфейс
додатку відповідно до зміни розмірів екрану пристрою [14].
Stack View є інструментом для автоматичного позиціонування
елементів у вікні додатку. Stack View надає можливість створити стек
елементів та настроїти їх позиціонування з використанням наступних
параметрів:
- Axis означає горизонтальну або вертикальну орієнтацію;
- Distribution визначає положення елементів у визначеній
орієнтації;
- Spacing визначає простір між сусідніми елементами.
Першим та основним контролером додатку являється HomeVC,
зображення якого наведенона рисунку3.7. Головний елементом в даному
контролері є MK MapView, що виводить мапу на якій будуть відображені
основні інформаційні елементи, а саме: геолокація
користувача,місцезнаходження водія, а також наведено візуальне зображення
маршруту майбутньої поїздки. У верхній частині буде знаходитися кнопка
відкриття для меню, назва додатку, а також фото зареєстрованого
користувача. Під цими елементами також буде знаходитися вертикально
орієнтований Stack View із текстовими полями для можливості введення
адреси для майбутньої поїздки. У нижній частині прототипу додатку
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 42
а
розташовані кнопка для відміни поїздки, кнопка запиту поїздки,і кнопка для
фіксації на мапі поточного місцезнаходження користувача.
Ще одним контролером являється LeftSidePanelVC,зображення якого
наведено на рисунку3.7, буде відображатися під час натискання на кнопку
відкриття меню. Основними елементами даного контролеру є перемикач
режимів для водія, який може побачити лише користувач з роллю “водій”,
горизонтальний Stack View для виведення основної інформації про
користувача, і кнопка,яка веде до контролера реєстрації та входу.
Рисунок 3.7 – Інтерфейси для контролерів HomeVC та LeftSidePanelVС
Наступним інтерфейсом для якого розроблено прототип є контролер
LoginVC, зображення для якого наведено на рисунку 3.8. Тут розроблено
вертикальний Stack View з короткою інформацією про додаток, з елементом
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 43
а
Segmented Control за допомогою якого можна обрати ролі користувача, з
текстовими полями для введення email та паролю користувача з кнопкою
входу для зареєстрованих користувачів та формою для реєстрації для
незареєстрованих користувачів, а також кнопкою закриття вікна.
Останнім розробленим прототипом інтерфейсу є інтерфейс контролеру
PickupVC, що наведено на рисунку 3.9.
Рисунок 3.8 – Інтерфейс контролеру Рисунок 3.9 – Інтерфейс контролеру
LoginVC LoginVC
Даний контролер буде відображатисялише для водіїв,якіпрямують у
зазначеним користувачем, що виконав запит поїздки, напрямку. Основними
елементами цього контролеру буде MKMapView, що використовуватиметься
для відображення маршруту майбутньої поїздки, а також кнопки прийняття
або відміни поїздки.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 44
а
ВИСНОВКИ
Під час виконання кваліфікаційної роботи бакалавра було реалізовано
серверну частину додаток та розроблено макети для клієнтської частини.
Додаток, що реалізується орієнтований на різних типів користувачів та
являється продуктом, що надає послуги перевезення по місту.
Розроблений в рамках кваліфікаційної роботи бакалавра програмний
продукт скорочує витрачання користувачами часу під час проїзду по місту з
одногопункту до іншого, а також являється помічником для водіїв, що хочуть
повернути частину вартості за перевезення. Однією з переваг розробленого
додатку є те, що він адаптований для використання на різних пристроях в
яких є підтримка браузеру.
В першому розділі було наведено обґрунтування вибору даної теми
роботи, проведено огляд існуючих програмних рішень реалізації подібних
додатків та визначено задачі, які необхідно реалізувати.
В другому розділі роботи було проаналізовано існуючі сучасні
інструменти для web-технологій, що дозволять розробку інтерактивного
інтерфейсу, стабільної серверної частини додатку для розробки логіки
продукту та оптимізованого стабільного сховище для зберігання даних
користувачів, що використовуватимуть додаток.
Під час дослідження було визначено, що найкращими для поєднання
технологіями в процесі реалізації додатку виявились технології: ReactJS,
NodeJS, ExpressJS, що реалізовані на базі мови JavaScript та надбудови типу
TypeScript. Для передачі даних між frond-end та back-end реалізованого
додатку застосовується патерн Apollo GraphQL, для зберігання даних
PostgreSQL з об’єктно-реляційним відображенням (ORM), що має назву
TypeORM.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 45
а
Розроблена логіка додатку орієнтована на двох видів користувачів –
водій та пасажир. Перед початком використання додатку кожен користувач
має зареєструватися. Для цього необхідно підтвердити свою особистість
через пошту або номер телефону, а також ввівши необхідні цифри, що
прийдуть, для підтвердження. Обом типам користувачів доступна функція
редагування особистого профілю та можливість використання основного
функціоналу додатка.
Для водія основним функціоналом є пошук клієнтів, а клієнта – пошук
підходящого виконавця. Перед тим, як розпочати пошук виконавця клієнту
необхідно ввести дві адреси (пункти відправки та прибуття) або встановити
маркери на необхідних місця на карті. Після того, як клієнт знаходить
потрібного виконавця на даному маршруті, виконавцю пропонують ціну та
скидають пункти відправки та прибуття клієнта. Якщо ціну узгоджено та
водій приймає замовлення, спілкування користувачів продовжується вже з
використанням чату. Для того, щоб повідомити клієнта про своє прибуття до
пункту відправки водій натискає на відповідну кнопку. Для водія також
передбачена функція відмови від замовлення. Після прибуття до місця
призначення водій повідомляє про завершення поїздки натисненням на
відповідну кнопку. Розрахунок за надані послуги виконується за готівку.
Для реалізації програмного додатку було використано шаблони
проектування і кращі практики. Також розроблений додаток можна легко
модифікувати та вдосконалювати. Він не являється кращим на ринку, а тому
для його вдосконалення можна додати декілька важливих функціональних
можливостей, а саме: можливість обрати клас авто в процесі пошуку
замовлення, виконувати оплату використовуючи банківську карту або
рахунок в деяких платіжних системах, розробити додаток для менеджерів або
лінії підтримки, для того, щоб мати можливість маніпулювати додатком
через інтерфейс на рівні адміністратору.
ЧДТУ.231931.005ПЗ
Зм. Лист № докум. Підпис Дат 46
а
ДОДАТОК А
Популярність компонентних фреймворків
на момент 2021 року
ДОДАТОК Б
«ЗАТВЕРДЖУЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор Володимир РУДНИЦЬКИЙ
__________________
«___» _____________ 2023 р.
Інформаційна система для замовлення послуги
спільних перевезень по місту
Специфікація
482.ЧДТУ.31931-01
Листів 2
Розробник _______________ Владислав СВЕРДЕЛ
Керівник _______________ Тетяна МИРОНЮК
Черкаси 2023
2
482.ЧДТУ.31931-01
Позначення Найменування Примітка
Документація
482.ЧДТУ.31931-01 12 01 Текст програми
ДОДАТОК В
Інформаційна система для замовлення послуги
спільних перевезень по місту
Текст програми
482.ЧДТУ.31931-01 12 01
Листів 11
Розробник: Владислав СВЕРДЕЛ
Черкаси 2023
2
482.ЧДТУ.31931-01 12 01
User.ts – модель даних користувача.
import { compare, hash } from "bcrypt"
import { IsEmail } from "class-validator"
import {
BaseEntity,
BeforeInsert,
BeforeUpdate,
Column,
CreateDateColumn,
Entity, ManyToOne, OneToMany,
PrimaryGeneratedColumn,
UpdateDateColumn
} from "typeorm";
import Chat from "./Chat";
import Message from "./Message";
import Ride from "./Ride";
import Place from "./Place";
@Entity()
class User extends BaseEntity {
@PrimaryGeneratedColumn()
id: number;
@Column({
type: "varchar",
unique: true,
nullable: true
}) @IsEmail()
email: string | null;
@Column({
type: "boolean",
default: false
})
verifiedEmail: boolean;
@Column({ type: "text" })
firstName: string;
@Column({ type: "text" })
lastName: string;
@Column({ type: "text", nullable: true })
bio: string;
@Column({ type: "int", nullable: true })
age: number;
3
482.ЧДТУ.31931-01 12 01
@Column({ type: "text", nullable: true })
pass: string;
@Column({ type: "text", nullable: true })
phoneNumber: string;
@Column({
type: "boolean",
default: false
})
verifiedPhoneNumber: boolean;
@Column({ type: "text", nullable: true })
facebookId: string;
@Column({
type: "boolean",
default: false
})
isDriving: boolean;
@Column({
type: "boolean",
default: false
})
isRiding: boolean;
@Column({
type: "boolean",
default: false
})
isTaken: boolean;
@Column({
type: "double precision",
default: 0
})
lastLng: number;
@Column({
type: "double precision",
default: 0
})
lastLat: number;
@Column({
type: "double precision",
default: 0
})
4
482.ЧДТУ.31931-01 12 01
lastOrientation: number;
@OneToMany(type => Chat, chat => chat.passenger)
chatsAsPassenger: Chat[];
@OneToMany(type => Chat, chat => chat.driver)
chatsAsDriver: Chat[];
@OneToMany(type => Message, message => message.user)
messages: Message[];
@OneToMany(type => Ride, ride => ride.passenger)
ridesAsPassenger: Ride[];
@OneToMany(type => Ride, ride => ride.driver)
ridesAsDriver: Ride[];
@OneToMany(type => Place, place => place.user)
places: Place[];
@CreateDateColumn()
createdAt: string;
@UpdateDateColumn()
updatedAt: string;
get fullName(): string {
return `${this.firstName} ${this.lastName}`
}
public passwordsComparing(password: string): Promise<boolean> {
return compare(password, this.pass)
}
@BeforeInsert()
@BeforeUpdate()
async savePassword(): Promise<void> {
if(this.pass) {
this.pass = await this.hashPassword(this.pass);
}
}
private hashPassword(password: string): Promise<string> {
return hash(password, 10)
}
}
export default User;
5
482.ЧДТУ.31931-01 12 01
Chat.ts – модель даних Чату
import {
BaseEntity, Column,
CreateDateColumn,
Entity, ManyToOne, OneToMany, OneToOne,
PrimaryGeneratedColumn,
UpdateDateColumn
} from "typeorm";
import Message from "./Message";
import User from "./User";
import Ride from "./Ride";
@Entity()
class Chat extends BaseEntity {
@PrimaryGeneratedColumn()
id: number;
@OneToMany(type => Message, message => message.chat, { nullable: true })
messages: Message[];
@Column({ nullable: true, type: "int" })
passengerId: number
@ManyToOne(type => User, user => user.chatsAsPassenger)
passenger: User;
@Column({ nullable: true, type: "int" })
rideId: number;
@OneToOne(type => Ride, ride => ride.chat)
ride: Ride;
@Column({ nullable: true, type: "int" })
driverId: number
@ManyToOne(type => User, user => user.chatsAsDriver)
driver: User;
@CreateDateColumn()
createdAt: string;
6
482.ЧДТУ.31931-01 12 01
@UpdateDateColumn()
updatedAt: string;
}
export default Chat;
Message.ts – модель повідомлення
import {
BaseEntity,
Column,
CreateDateColumn,
Entity, ManyToOne,
PrimaryGeneratedColumn,
UpdateDateColumn
} from "typeorm";
import Chat from "./Chat";
import User from "./User";
@Entity()
class Message extends BaseEntity {
@PrimaryGeneratedColumn()
id: number;
@Column({ type: "text" })
text: string;
@Column({ nullable: true, type: "int" })
chatId: number;
@ManyToOne(type => Chat, chat => chat.messages)
chat: Chat;
@ManyToOne(type => User, user => user.messages)
user: User;
@CreateDateColumn()
createdAt: string;
7
482.ЧДТУ.31931-01 12 01
@UpdateDateColumn()
updatedAt: string;
}
export default Message;
EmailSignUp.resolvers.ts – логіка реєстрації за допомогою email.
import { Resolvers } from "../../../types/resolvers";
import { EmailSignUpMutationArgs, EmailSignUpResponse } from
"../../../types/graph";
import User from "../../../entities/User";
import createJWT from "../../../utils/jwt";
const resolvers: Resolvers = {
Mutation: {
EmailSignUp: async (_, args: EmailSignUpMutationArgs):
Promise<EmailSignUpResponse> => {
const { email } = args;
try {
const user = await User.findOne({ email });
if (user) {
return {
ok: true,
error: "Please, login first",
token: null
};
} else {
const newUser = await User.create({ ...args }).save();
const token = createJWT(newUser.id);
return {
ok: true,
error: null,
token
}
}
} catch (error) {
return {
8
482.ЧДТУ.31931-01 12 01
ok: false,
error: error.message,
token: null
}
}
}
}
}
export default resolvers;
EmailSignIn.resolvers.ts – логіка авторизації за допомогою email.
import { Resolvers } from "../../../types/resolvers";
import { EmailSignInMutationArgs, EmailSignInResponse } from
"../../../types/graph";
import User from "../../../entities/User";
import createJWT from "../../../utils/jwt";
const resolvers: Resolvers = {
Mutation: {
EmailSignIn: async (_, args: EmailSignInMutationArgs):
Promise<EmailSignInResponse> => {
const { email, pass } = args;
try {
const user = await User.findOne({ email });
if (!user) {
return {
ok: false,
error: "User with this email doesn't exist",
token: null
};
}
const checkPassword = await user.passwordsComparing(pass);
if (checkPassword) {
const token = createJWT(user.id);
return {
ok: true,
9
482.ЧДТУ.31931-01 12 01
error: null,
token
};
} else {
return {
ok: false,
error: "Wong password",
token: null
};
}
} catch (error) {
return {
ok: false,
error: error.message,
token: null
}
}
}
}
};
export default resolvers;
SubscribeOnNearestDriver.resolvers.ts – логіка пошуку водія на карті.
import { withFilter } from "graphql-yoga";
import User from "../../../entities/User";
const resolvers = {
Subscription: {
SubscribeOnNearestDriver: {
subscribe: withFilter(
(_, __, { pubSub }) => pubSub.asyncIterator('driverUpdate'),
(payload, _, { context }) => {
const user: User = context.currentUser;
const {
SubscribeOnNearestDriver: { lastLat: driverLastLat, lastLng: driverLastLng }
10
482.ЧДТУ.31931-01 12 01
} = payload;
const { lastLat: userLastLat, lastLng: userLastLng } = user
return (
driverLastLat >= userLastLat - 0.05 &&
driverLastLat >= userLastLat + 0.05 &&
driverLastLng >= userLastLng - 0.05 &&
driverLastLng >= userLastLng + 0.05
);
})
}
}
};
export default resolvers;
facebookAuth.resolvers.ts – вхід у аккаунт через facebook.
import { Resolvers } from "../../../types/resolvers";
import { FacebookAuthMutationArgs, FacebookAuthResponse } from "../../../types/graph";
import User from "../../../entities/User";
import createJWT from "../../../utils/jwt";
const resolvers: Resolvers = {
Mutation: {
FacebookAuth: async (_, args: FacebookAuthMutationArgs):
Promise<FacebookAuthResponse> => {
const { facebookId } = args
try {
11
482.ЧДТУ.31931-01 12 01
const isUserExist = await User.findOne({ facebookId })
if (isUserExist) {
const token = createJWT(isUserExist.id);
return {
ok: true,
error: null,
token
};
}
} catch (e) {
return {ok: false, error: e.message, token: null}
}
try {
const createUser = await User.create({...args}).save();
const token = createJWT(createUser.id);
return {ok: true, error: null, token}
} catch (e) {
return {ok: false, error: e.message, token: null}
}
}
}
}
export default resolvers;
ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Uber. Режим доступу: https://uk.wikipedia.org/wiki/Uber
2. Uklon. Режим доступу: https:// uk.wikipedia.org/wiki/Uklon
3. Stefanov, Stoyan. JavaScript Patterns: Build Better Applications with Coding
and Design Patterns. Sebastopol, CA: O’Reilly Media, 2010.
4. Resig, John, Bear Bibeault, and Josip Maras. Secrets of the JavaScript Ninja.
2nd ed. Shelter Island, NY: Manning Publications, 2016.
5. Rozentals N. Mastering TypeScript – Second Rozentals N.; Livery Place:
Packt Publishing Ltd, Published: February 2017 – 643p.
6. Kyle Simpson. You Don't Know JS: Scope & Closures. 2014. 236 р.
7. Джин Кім, Патрік Дебуа, Джон Вілліс, Джез Хамбл. Книга Керівництво
по DevOps. 2018. 512 с.
8. David Flanagan. JavaScript: The Definitive Guide, 7th Edition. O'Reilly
Media, Inc. – 2020. – pp. 1080 с. - ISBN: 9781491952023
9. MapKit Framework [Електронний ресурс] – 2019. – Режим доступу до
ресурсу: https://developer.apple.com/documentation/mapkit
10.PostgreSQL Global Development Group. PostgreSQL Documentation.
Режим доступу: https://www.postgresql.org/docs/
11.Relational vs. NoSQL data. Режим доступу: https://learn.microsoft.com/en-
us/dotnet/architecture/cloud-native/relational-vs-nosql-data
12. Apple Developer Documentation. Режим доступу:
https://developer.apple.com/design/human-interface-guidelines/layout
13.Auto Layout Guide: Anatomy of a Constraint. Режим доступу:
https://developer.apple.com/library/archive/documentation/UserExperience/C
onceptual/AutolayoutPG/AnatomyofaConstraint.html
14.About an Xcode IDE for Apple application development [Електронний
ресурс] – 2018. – Режим доступу до ресурсу: https://medium.com/worst-
ios- developer/about-an-xcode-ide-for-apple-application-development-
68b161088e53
Лист
ЧДТУ.231931.005 ПЗ т
Зм. Лист № докум. Підпис Дат 61
а
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
