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
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6910| Title: | Автоматизована інформаційна система збирання та передачі інформації про показники лічильників комунальних послуг: серверна частина |
| Authors: | Тарасенко , Ярослав Володимирович Мельник, Артьом Станіславович |
| Keywords: | інформаційна система;сервер;інформаційний обмін;програмне забезпечення;автоматизована інформаційна система |
| Issue Date: | 16-Jun-2021 |
| Abstract: | Ідея створення цього продукту виникла для полегшення роботи з лічильниками. Адже наразі схожих програмних продуктів не існує, які б вирішували задачі зберігання, обробки та відправлення даних лічильників на конкретні комунальні підприємства. Тому виникла ідея створити єдину інформаційну систему, яка буде складатися з мобільного додатку і серверної частини для нього, який матиме змогу для зручного додавання і обробки даних. Наразі додатку, який би виконував ті функції, які заплановані не має. Існують часткові рішення для конкретних підприємств, але їх багато і всі вони різні, що ускладнює роботу з інформацією. Ідеєю єдиного додатку є зібрати сервіси усіх підприємств в одного місці для зручної роботи з ними. Програмування сервера використовується для надання клієнтській частині чи мобільному додатку інтерфейс для роботи з сервером та базою даних. Для коректної роботи нашого серверу потрібна архітектура, та правильно спроектована база даних. До серверної частини можна звертатися з будь якого пристрою, що дає змогу мультиплатформності, тому це є ідеальним варіантом для єдиного додатка. Визначено завдання: • Аналіз відомих рішень. Знайти інші існуючі рішення, і розглянути їх переваги та недоліки; • Створити архітектуру проекту; • Спроектувати базу даних; • Реалізація програмних модулів для забезпечення зберігання інформації; • Провести тестування на виявлення помилок. • Оформити пояснювальну записку до кваліфікаційної роботи. Так, у даній роботі ми розглянемо мови програмування та суміжні технології, що і безпосередньо становлять поняття серверного програмування. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6910 |
| Appears in Collections: | 126 Інформаційні системи та технології (Web-технології, web-дизайн) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| РЕП_БАК_Мельник_WebC-1911.pdf Restricted Access | 2.69 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ ПРОЕКТУВАННЯ Пояснювальна записка до кваліфікаційної роботи бакалавра на тему: «Автоматизована інформаційна система збирання та передачі інформації про показники лічильників комунальних послуг: серверна частина» Виконав студент 4 курсу, групи WebC-1911, спеціальності 126 – Інформаційні системи та технології, освітня програма – Web- технології, Web-дизайн, Мельник А.С. Керівник к.т.н. Тарасенко Я.В. Рецензент д.т.н., доцент, полковник служби цивільного захисту, начальник відділу організації наукової діяльності, Черкаський інститут пожежної безпеки імені Героїв Чорнобиля Національного університету цивільного захисту України Мирошник О.М. Черкаси – 2021 року ЗМІСТ ВСТУП .............................................................................................................................. 3 1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ ................................................................... 6 1.1 Розробка вимог ........................................................................................ 6 1.2 Огляд існуючих рішень .......................................................................... 8 1.3 Опис вхідної та вихідної інформації .................................................. 14 1.4 Визначення структури бази даних .................................................... 15 1.5 Формування технічних умов .............................................................. 22 1.6 Обґрунтування технічного завдання ................................................ 25 1.6.1 Вимоги до ІС в цілому ..................................................................... 25 1.6.2 Функціональні вимоги до ІС ........................................................... 26 1.6.3 Загальна архітектура рішення ......................................................... 30 1.6.4 Вимоги до гарантійної підтримки .................................................. 30 1.6.5 Вимоги до надійності програмного забезпечення ІС та збереженості програми ......................................................................................... 30 1.6.6 Вимоги до інформаційного обміну між модулями системи ........ 31 1.6.8 Вимоги до технічного забезпечення .............................................. 31 2. ПРОЕКТНА ЧАСТИНА .................................................................................... 32 2.1 Загальна структура ІС ......................................................................... 32 2.2 Функції ІС ............................................................................................... 36 ВИСНОВКИ ................................................................................................................. 74 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................ 77 ВСТУП Ідея створення цього продукту виникла для полегшення роботи з лічильниками. Адже наразі схожих програмних продуктів не існує, які б вирішували задачі зберігання, обробки та відправлення даних лічильників на конкретні комунальні підприємства. Тому виникла ідея створити єдину інформаційну систему, яка буде складатися з мобільного додатку і серверної частини для нього, який матиме змогу для зручного додавання і обробки даних. Наразі додатку, який би виконував ті функції, які заплановані не має. Існують часткові рішення для конкретних підприємств, але їх багато і всі вони різні, що ускладнює роботу з інформацією. Ідеєю єдиного додатку є зібрати сервіси усіх підприємств в одного місці для зручної роботи з ними. Програмування сервера використовується для надання клієнтській частині чи мобільному додатку інтерфейс для роботи з сервером та базою даних. Для коректної роботи нашого серверу потрібна архітектура, та правильно спроектована база даних. До серверної частини можна звертатися з будь якого пристрою, що дає змогу мультиплатформності, тому це є ідеальним варіантом для єдиного додатка. Визначено завдання: Аналіз відомих рішень. Знайти інші існуючі рішення, і розглянути їх переваги та недоліки; Створити архітектуру проекту; Спроектувати базу даних; Реалізація програмних модулів для забезпечення зберігання інформації; Провести тестування на виявлення помилок. Оформити пояснювальну записку до кваліфікаційної роботи. Так, у даній роботі ми розглянемо мови програмування та суміжні технології, що і безпосередньо становлять поняття серверного програмування. Метою роботи є вдосконалення вирішення проблем, як: Децентралізація передачі показників лічильників для різних комунальних підприємств; Впровадження загальної системи обліку та аналізу споживання комунальних послуг для споживача; Ручне зчитування показників лічильника та введення їх в певну систему обліку комунальних послуг. Рішенням у вирішенні таких проблем є проектування та створення серверу для роботи з базою даних і клієнтами, які матимуть змогу вносити та змінювати інформацію. Актуальність полягає в оригінальності інформаційної системи, через те, що прямих конкурентів для інформаційної системи не існує. Об’єктом дослідження роботи є існуючі рішення для передачі показників лічильників від користувача до сервера . Предметом дослідження даної роботи є серверна частина разом із базою даних, до якої звертається сервер, для виконання однієї з чотирьох основних функцій управління даними, а саме додавання, читання, редагування і видалення. 1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ 1.1 Розробка вимог За допомогою сервера мобільний додаток зможе контролювати витрати на комунальні послуги, контролювати та вести статистику по даним лічильників, передавати дані лічильників до підприємств та переглядати статистику витрат лічильників та історію показників. Так, як цей продукт буде працювати з різними типами підприємств, то він має добре працювати і швидко відповідати на запити мобільного додатку. Основну частину обробки даних складуть операції додавання, редагування та видалення даних. Структура бази даних повинна моделювати такі інформаційні об’єкти (ІО), як «Лічильник», «Група лічильників», «Показник лічильника», «Організація» та «Адреса», а також створити зв’язки між вказаними інформаційними системами та їх властивості. Ці зв’язки повинні відповідати вимогам отримання інформації, яка після обробки буде відправлена користувачам. Вимоги до технічного забезпечення сервера: Тактова частота: не менше 2 ГГц; Оперативна пам’ять: не менше 8 Гб; Доступ до мережі інтернет; Вимоги до програмного забезпечення: Windows Server / Linux; NodeJS: версії 14.11.0; NPM: версії 6.14.8; PostgreSQL: версії 13; Необхідні npm пакети: Express: версії 4.17.1; JsonWebToken: версії 8.5.1; Joi: версії 17.3.0. 1.2 Огляд існуючих рішень Перед проектуванням серверу, я переглянув існуючі додатки та дещо схожі варіанти і оцінив їх за власною думкою. Оцінка додатків рахувалась по функціональності та зручності у використанні. Додатки, які були переглянуті: «Коммунальные услуги» [1] Додаток застарілий, останнє оновлення було здійснене 2015 року. З плюсів можна визначити ідею, все інше ж до мінусів. З функціоналу тут тільки: Додавання поточного показника; Історія витрат по лічильникам. Рисунок 1.1 – Сторінка додатку в Play Market Додаток не є зручним і функціональним, про що свідчать відгуки додатку Додаток «Комуналка» [2] На відміну від минулого додатку, цей досі підтримується. З плюсів можна відмітити: Можливість оплати з додатку; Привабливий дизайн; Перегляд історії переводів і оплати. З мінусів ж можна назначити, роботу додатка на кількох областях країни і низьку оцінку користувачів, що може свідчити, про неготовність додатку. Рисунок 1.2 – Сторінка додатку «Комуналка» Додаток «Єдиний рахунок» [3] В цьому додатку присутня деяка частина функціоналу, яка частково допомагає у вирішенні задачі полегшення роботи, але в ньому все працює дуже довго й некоректно, або ж не працює взагалі, на що й скаржаться користувачі, про що свідчить загальна оцінка додатку. Рисунок 1.3 – Відгуки «Єдиний рахунок» Деякі комунальні служби задля зручності передавання показників, пропонують їх передачу не через дзвінки, чи папірці, а через мережу інтернет. Але кожна організація робить по-різному, наприклад: Для передачі показників світла, потрібно мати Viber, та кожного разу вписувати адресу та номер споживача, що не є швидко і зручно. Рисунок 1.4 – Приклад передачі показників у Viber З передачею показників газу, потрібно відкрити веб-сторінку підприємства і заповнити велику форму. Щоб це виконати потрібно ввести: Номер особового рахунку; Номер телефону; Повну адресу, включно з містом. Рисунок 1.5 – Форма для передачі показників газу Для передачі показників води, потрібно реєструватись на сайті водоканалу. На мою думку, це найшвидший варіант, через те, що тут присутня реєстрація, що значить вказувати кожного разу потрібно тільки нове значення самого лічильника, а не повну інформацію про споживача (повна адреса та особовий рахунок). Рисунок 1.6 – Передача показників води 1.3 Опис вхідної та вихідної інформації Вхідна інформація – це інформація яка буде використовуватись у програмі і в надалі буде оброблена. Вихідна інформація – це інформація яка пройшла етап обробки або використання, і сформована для показу результатів. Вхідними даними для серверу є: Інформація про споживача, який користується послугами комунальних підприємств; Інформація про адреси, які зв’язані з підприємствами і групами лічильників; Інформація про підприємства; Інформація про групи лічильників, які зв’язані з користувачем; Інформація про дані лічильника, які зв’язані з лічильником; Інформація про лічильник, який зв’язаний з користувачем, групою лічильників, типом ресурсу. Вихідними даними для серверу є: Список усіх записів з одного лічильника; Інформація про користувача, який авторизується; Інформація про підприємства за певним типом; Інформація про споживача за його ідентифікатором; Інформація про адресу за її ідентифікатором; Інформація про всі лічильники і їх дані певного користувача; 1.4 Визначення структури бази даних [14, 15, 19, 25] Будь-які дані, з якими працює сервер потрібно десь зберігати. Зазвичай сервери зберігають дуже великий обсяг інформації і тому аби не зберігати її на сервері, що потягне за собою зменшення швидкодії сервера, до нього під’єднують базу даних, в якій сервер зберігає інформацію і спілкується з нею через певний інтерфейс. База даних(БД) – це систематизований і згрупований і добре організований набір даних. У базі даних інформація організована і логічно згрупована, завдяки чому можна легко управляти цими даними(додавати, змінювати, видаляти, зчитувати). У базі даних пов'язані дані групуються в таблиці, кожна з яких складається з рядків та стовпців. Система Управління Базами Даних(СУБД) – це програма, яка дозволяє користувачу мати доступ до бази даних, маніпулювати даними – тобто додавати дані, видаляти, змінювати. Існують декілька типів БД, а саме: Ієрархічна; Мережева; Реляційна. Перша модель, тобто ієрархічна є першою моделлю БД і була представлена у як деревоподібна структура в ієрархії. Недоліком такої структури є те, що дані і зв’язки між ними повинні бути визначні з самого початку, проте така структура є надзвичайно швидкою в зрівнянні з іншими типами БД. В мережевій моделі є подібності з ієрархічною, але в доповнення вона дає можливість створювати різносторонні вузли. Під час з’єднання вузлів додається мережа, за допомогою якої користувач за швидший час може отримати доступ до потрібної інформації. Така модель підходить для таких структур, як семантичні, персональні мережі та мережі компаній. В реляційній моделі БД інформація зберігається в таблицях, які мають стосунки (зв’язки) між собою. Будь-який запис являє собою рядок, який містить всі поля в стовпчиках. Таке рішення є найпопулярнішим, тому й ми будемо використовувати такий тип БД. Існують різні типи реляційних БД, а саме: MySQL; PostgreSQL; Microsoft SQL Server. В нашому сервері ми будемо використовувати саме PostgreSQL, тому що, в ній присутня підтримка табличного простору, збережених процедур, об’єднань. Також в ній присутня асинхронна реплікація. PostgreSQL – це реляційна система керування базами даних, яка працює на всіх існуючих системах. В ній присутні такі функції як декларативне розбиття таблиць, поліпшені паралельні запити, а також вона має більш безпечнішу автентифікацію. Для коректної роботи БД, потрібно правильно спроектувати її структуру. База даних, яка буде працювати з сервером буде містити в собі шість таблиць, зв’язаних між собою. З них три таблиці пов’язані з лічильником, інші ж з організацією, споживачем і адресом. Нижче представлена структура бази даних: Таблиця 1.4.1 – Структура таблиці «Адреса» Найменування даних Тип даних Реквізит PK AI FK Код адреси INT() address_id PK AI Тип вулиці VARCHAR() street_type Назва вулиці VARCHAR() street_name Місто VARCHAR() city Номер будинку VARCHAR() house_number Номер квартири VARCHAR() apartment_number Таблиця 1.4.2 – Структура таблиці «Організація» Найменування даних Тип даних Реквізит PK AI FK Код організації INT() organization_id PK AI Назва VARCHAR() name Тип ресурсу VARCHAR() resource_type Адреса INT() address_id address_id ЄДРПОУ VARCHAR() edrpou Таблиця 1.4.3 – Структура таблиці «Споживач» Найменування даних Тип даних Реквізит PK AI FK Код споживача INT() consumer_id PK AI Ім’я VARCHAR() name Прізвище VARCHAR() surname По-батькові VARCHAR() patronymic Електронна пошта VARCHAR() email ПРО-аккаунт BOOLEAN() pro Пароль VARCHAR() password Таблиця 1.4.4 – Структура таблиці «Група лічильників» Найменування даних Тип даних Реквізит PK AI FK Код групи INT() meters_group_id PK AI Назва VARCHAR() name Код споживача INT() consumer_id consumer_id Код адреси INT() address_id address_id Таблиця 1.4.5 – Структура таблиці «Лічильник» Найменування даних Тип даних Реквізит PK AI FK Код лічильника INT() meter_id PK AI Особовий рахунок VARCHAR() personal_account Назва VARCHAR() name Тип ресурсу VARCHAR() address_id Код організації INT() organization_id organization_id Код групи лічильників INT() meters_group_id meters_group_id Таблиця 1.4.6 – Структура таблиці «Показник лічильника» Найменування даних Тип даних Реквізит PK AI FK Код показника INT() meter_data_id PK AI Код лічильника INT() meter_id meter_id Значення лічильника INT() value Дата додавання на сервер TIMESTAMP() date Після створення реляційної бази даних, потрібно створити зв’язки для коректної роботи всередині бази даних. [13] Для зберігання інформації необхідна реляційна база даних – сховище даних, розділених на менші набори даних (таблиці), щоб виключити зайву інформацію, а потім пов'язаних між собою на основі спільних частин інформації (полів). Наприклад, реляційна база даних для планування події може містити таблицю з відомостями про клієнтів, таблицю з відомостями про постачальників і таблицю з відомостями про подію. Таблиця з відомостями про подію може містити поле, яке зв'язує її з таблицею клієнтів, і поле, яке зв'язує її з таблицею постачальників. Таким чином, якщо змінився номер телефону постачальника, відповідні дані можна змінити лише один раз у таблиці постачальників, і не потрібно змінювати ці дані для кожної події, до якої залучено цього постачальника. Реляційна база даних складається з таблиць, які зв’язані між собою. Заповненість таблиці задається кількістю полів, їх типом і максимальним розміром кожного стовпця, а також унікальним ключем таблиці. Рядки ж являють собою дані, які записані в цю таблицю, що означає 1 рядок – 1 запис у базі даних, і мають унікальний ключ. Зв'язки між таблицями в нашій базі даних визначаються за рахунок однакових значень полів таблицях. Розглянемо види зв’язків: [8] Зв’язок виду один до одного, створюється у випадку, коли всі поля в обох таблицях є ключовими. Зв’язок один до багатьох має місце, коли запису з першої таблиці можуть відповідати декілька записів другої таблиці. Зв’язок багато до одного, являє собою протилежність зв’язку одного до багатьох. У випадку коли в одному чи декільком записам основної таблиці зв’язується один запис другої таблиці. Для нашого випадку достатньо зв’язку одного типу, а саме один до багатьох. Рисунок 1.7 – Структура бази даних 1.5 Формування технічних умов [7 , 9] Оскільки цей сервер повинен обробляти десятки, а то й сотні запитів, він має працювати без жодних помилок чи збоїв, тому треба чітко вказати завдання і дотримуватись його. Програмний продукт повинен працювати стабільно і безвідмовно при наявності наступних характеристик системи: Операційна система - Windows Server / Linux; Оперативна пам’ять – 8ГБ DDR4; Процесор – 4-х ядерний з тактовою частотою 2ГГц; Пам’ять – SSD 1Тб; Вихід до мережі інтернет зі швидкістю, не менше ніж 500Мбіт/с. Сервери працюють і отримують запити від клієнтів по протоколу HTTP у стилі «запит-відповідь». Для того, аби клієнт зміг відправити дані, їх потрібно позначити, тобто вказати їх дію, ознаку. Зазвичай, їх потрібно було підписати як формат JSON. REST – це технологія, що дозволяє взаємодіяти з сервером та дозволяє не вказувати формат і передавати дані так, як вони є. Передаються вони за допомогою HTTP-запиту в якому вказується метод обробки. Зазвичай використовується лише два методи які підтримує HTML, це GET і POST і оскільки вони є стандартними, то їх підтримують всі браузери. Але насправді метод HTTP може бути абсолютно будь-яким, але є деякі загальноприйняті, такі як: PUT – використовують для оновлення інформації на ресурсах; DELETE – використовують для видалення; PATCH – використовують для часткової зміни даних; OPTIONS – використовується для задання параметрів з’єднання. Існує п’ять обов’язкових обмежень для написання REST-додатків. Виконання всіх п’яти обмежень є обов’язкове для REST-систем. Обмеження, які накладаються, задають роботу сервера в тому, як він зможе обробляти и відповідати на запити клієнтів. Діючи в рамках обмежень, сервер отримує властивості, такі як: масштабованість, простоту, мобільність, надійність, відстежуваність і продуктивність. Якщо додаток порушує хоча б одне обмеження, то він не вважається REST-системою. Обов’язковими умовами вважається: 1. Модель клієнт-сервер Розмежування потреб є принципом, що лежить в основі даного накладається обмеження. Потреба розділити інтерфейс клієнта від функцій, які виконує сервер, що зберігає дані, підвищує мобільність клієнтського інтерфейсу на інші платформи, а спрощення серверної частини покращує масштабованість. 2. Відсутність стану програми Протокол взаємодії між клієнтом і сервером потребує дотримання наступної умови, а саме, що в період між запитами клієнта жодна інформація про стан клієнта на сервері не зберігається. Всі запити від клієнта повинні створені так, щоб сервер отримав всю інформацію для обробки запиту. 3. Кешування Відповіді від сервера, в свою чергу, запити повинні мати позначення як такі, що кешуються чи ні, з ціллю не допустити такої ситуації, де клієнт може отримати застарілі чи невірні дані у відповідь на наступні запити. Правильне використання кешування може частично чи повністю прибрати деяку взаємодію клієнта з сервером. 4. Однаковість інтерфейсу Наявність уніфікованого інтерфейсу являє собою вимоги дизайну REST- сервісів. Уніфіковані інтерфейси дають можливість кожному сервісу розвиватися окремо від інших. До таких інтерфейсів додаються наступні чотири умови: Ідентифікація ресурсів; Маніпуляція ресурсами; «Само описувані» повідомлення; Гіпермедіа, як сервіс для зміни стану додатку. 5. Слої Зазвичай клієнт не взмозі точно визначити, взаємодіє він напряму з сервером чи з проміжним вузлом, в зв’язку з ієрархічною структурою мереж. Використання проміжних серверів здатне підняти масштабованість за рахунок балансування навантаження по серверам. REST завжди фокусується на ресурсах і на тому, настільки ефективно розробник працює з ним, використовуючи HTTP. HTTP визначає наступну структуру запиту: Рядок запиту (request line); Заголовок запиту (header fields); Тіло повідомлення (body). HTTP визначає структуру і відповіді від сервера: Рядок стану (status line); Поле заголовку відповіді (header fields); Додаткове тіло повідомлення (body). 1.6 Обґрунтування технічного завдання 1.6.1 Вимоги до ІС в цілому Для користувачів ІС повинна представляти собою сервер, з яким вони можуть взаємодіяти, а саме, внести дані лічильників за поточний місяць, дізнатися різницю між минулим показником, додати свою адресу для коректної відправки у комунальні підприємства. ІС повинна включати такі компоненти: Сервер для роботи з клієнтами; Базу даних, для зберігання інформації; Інтерфейс, по якому клієнтські додатки можуть спілкуватися з сервером. В ІС повинні бути реалізовані наступні функціональні можливості: Реєстрація споживача за електронною адресом; Отримання та обробку інформації з ІС користувача та додавання в відповідні для цього таблиці БД. Зберігання даних про користувача, його лічильників та його дані. Можливість додати декілька лічильників одному користувачу. Перевірку даних лічильника на коректність нового значення, що задав користувач. Доступ до ІС повинен отримуватись тільки з ІС користувача, яка була спеціально створена під ІС сервера. Для роботи з ІС сервера необхідно мати останню версію клієнтського додатку. До ІС не має бути несанкціонованого доступу, що може привести до передачі конфіденційної інформації третім особам. Користувачем ІС може бути будь-яка авторизована особа. Автентифікація користувачів відбувається із застосуванням бібліотек криптографічного перетворення. Доступ до персональної інформації про споживача, його адресам та особовим рахунків не повинна бути отримана іншим користувачами. ІС має забезпечувати: Використання HTTPS протоколів для роботи користувачів; Формування статистики витрат на основі даних з лічильників, отриманих з БД; Реєстрацію нового користувача. Створюване програмне забезпечення ІС повинно відповідати наступним вимогам: Відповідність функціоналу інтерфейсу ІС сучасним вимогам; Невеликий час відповіді на запити; Робота з базами даних; Шифрування інформації. 1.6.2 Функціональні вимоги до ІС ІС розробляється по модульному принципу, тобто система складається з окремих модулів, кожен з яких реалізує певний набір функцій, притаманних виключно йому. В ІС реалізовується наступні модулі: Модуль «Адреса»; Модуль «Організація»; Модуль «Споживач»; Модуль «Лічильник»; Модуль «Група лічильників»; Модуль «Показник лічильника». В наступних пунктах наведено орієнтовний перелік відомостей, які будуть задіяні у кожному модулі. Модуль «Адреса» Цей модуль призначений для зберігання і надання інформації про адреси, що зберігаються в ІС, та зв’язані з групою лічильників чи організацією. У модулі містяться наступні відомості про адресу: Унікальний ідентифікатор адреси; Тип вулиці; Назва вулиці; Номер будинку; Номер квартири. Модуль «Організація» Цей модуль призначений для зберігання і надання інформації про організації, що зберігаються в ІС. У модулі містяться наступні відомості про організацію: Унікальний ідентифікатор організації; Назва організації; Ідентифікатор адреси; Тип ресурсу; Код ЄДРПОУ. Модуль «Споживач» Цей модуль призначений для зберігання і надання інформації про споживача, що зберігаються в ІС. У модулі містяться наступні відомості про споживача: Унікальний ідентифікатор споживача; Прізвище; Ім’я; По-батькові; Електронна адреса; Пароль. Про-аккаунт. Модуль «Лічильник» Цей модуль призначений для зберігання і надання інформації про лічильник, що зберігаються в ІС, та зв’язаний з групою лічильників. У модулі містяться наступні відомості про лічильник: Унікальний ідентифікатор лічильника; Назва; Тип ресурсу; Ідентифікатор організації; Ідентифікатор групи лічильників. Модуль «Група лічильників» Цей модуль призначений для зберігання і надання інформації про групу лічильників, що зберігаються в ІС, та зв’язаний з адресом і споживачем. У модулі містяться наступні відомості про групу лічильників: Унікальний ідентифікатор групи лічильників; Назва групи; Ідентифікатор споживача; Ідентифікатор адреси. Модуль «Показник лічильника» Цей модуль призначений для зберігання і надання інформації про показники лічильників, що зберігаються в ІС, та зв’язаний з адресом і споживачем. У модулі містяться наступні відомості про показники лічильників: Унікальний ідентифікатор показника лічильника; Дата і час; Ідентифікатор лічильника; Значення лічильника. 1.6.3 Загальна архітектура рішення ІС серверу повинна бути побудована за класичною дворівневою архітектурою: БД – сервер. ІС повинна включати такі компоненти на відповідних рівнях: 1) На рівні БД: Сервер БД, який містить інформацію щодо показників лічильника, повинен перевіряти коректність нових даних, яких хоче ввести споживач, аби вони не були занадто великими, стосовно минулого запису. 2) На рівні сервера: Сервер прикладного програмного забезпечення, який реалізує основну бізнес-логіку ІС. Сервер повинен розкладатись на хмарному сервері. Сервер БД повинен використовуватись при виконанні операцій додавання та зміни інформації, щодо групи лічильників чи лічильника. Сервер повинен реалізовувати основний функціонал ІС через загальну мережу передавання даних та забезпечувати взаємодію зі всіма компонентами ІС. Сервер повинен забезпечувати відсутність прямого доступу до серверів БД та захист інформації від впливу ззовні. 1.6.4 Вимоги до гарантійної підтримки Все програмне забезпечення, яке буде розгорнуто при реалізації ІС, має забезпечуватись гарантійною підтримкою протягом шести календарних місяців з дати розгортання ІС. 1.6.5 Вимоги до надійності програмного забезпечення ІС та збереженості програми В ІС повинні використовуватись механізми ідентифікації і перевірки дійсності із застосуванням бібліотек криптографічного перетворення. Створювана ІС повинна включати можливість отримання прямого доступу будь-якого користувача до, доступних йому, компонентів. У разі виникнення непередбачуваних критичних ситуацій, аварій, відмов технічних засобів, збоїв, у роботі програмного забезпечення, повинна мати можливість відтворення своєї працездатності з резервних копій за короткий проміжок часу та з мінімальними втратами інформації. 1.6.6 Вимоги до інформаційного обміну між модулями системи Передача інформації між компонентами системи має виконуватись стандартними протоколами на рівні програмного забезпечення. 1.6.7 Вимоги режимів функціонування системи ІС повинна забезпечувати функціонування в режимі 24 години на добу днів на тиждень без необхідності зупинки її роботи для проведення планового регламентного технічного обслуговування. 1.6.8 Вимоги до технічного забезпечення Для забезпечення функціонування ІС сервер має мати необхідні технічні засоби, які відповідають вимогам: Процесор: не гірше Intel Xeon E5-2667 8x3.2ГГц; Оперативна пам’ять 16Гб DDR4; Мережевий адаптер 1ГБіт; Жорсткий диск 8Тб; SSD 256Гб. 2. ПРОЕКТНА ЧАСТИНА 2.1 Загальна структура ІС На сьогоднішній день більшість користувачів до вподоби ті програмні засоби, які працюють достатньо швидко. [6, 7] Інформаційна система – це взаємозв’язана сукупність засобів і методів, що використовуються для зберігання, обробки і видачі інформації для досягнення цілей управління. В сучасних умовах основним технічним засобом обробки інформації є мобільний телефон чи комп’ютер. Більшість сучасних ІС перетворюють не тільки інформацію, а й дані. Тому їх часто називають системами обробки даних. ІС обробки даних за степенем механізації процедур перетворення даних, діляться на системи ручної обробки, механізовані, автоматизовані і системи автоматичної обробки даних. Найважливішими принципами проектування ефективних ІС вважаються наступні: Принцип інтеграції – полягає в тому, що дані, які обробляються, які одного разу додали в систему, використовуються для рішення великої кількості задач; Принцип системності – полягає в обробці даних на різних аспектах, щоб отримати інформацію, яка буде необхідна для прийняття рішень на всіх рівнях управління; Принцип комплексності – полягає в механізації і автоматизації процедур перетворення даних на всіх етапах, функціонування ІС. Інформаційні системи також класифікуються: По функціональному призначенню; По об’єктам управління; По характеру використання результативної інформації. Структуру ІС складають сукупність окремих її частин, що називаються підсистемами. Структура системи – порядок і принципи взаємодії елементів системи, які задають основні властивості системи. Якщо ж різні елементи системи, розставлені в різних рівнях, то така структура називається ієрархічною. ІС забезпечують зберігання, обробку, пошук, збір і видачу інформації, яка знадобиться в процесі прийняття рішень задач із будь-якої області. Інформаційні системи зазвичай складаються з менших систем, які відповідають за роботу окремих частин програмного продукту, що називаються підсистема. Підсистема – це частина системи, яка виділена, по будь-якому признаку. Загальну структуру ІС можна роздивлятися як сукупність підсистем, не дивлячись на область ІС. В цьому випадку говорять про структурний признак класифікації, а підсистеми називають такими, які забезпечують. Приклад підсистем додатку зображено на рисунку 2.1.1. Рисунок 2.1.1 – Блок-схема підсистем додатку [12] Функціональні підсистеми реалізують і підтримують моделі. Методі і алгоритми отримання інформації. Склад функціональних підсистем достатньо різноманітний і залежить від предметної області використання ІС і її специфіки. В склад забезпечуючих підсистем входять: Інформаційне забезпечення – методи і засоби проектування інформаційної бази системи, включаючи системи класифікації і кодування інформації. Технічне забезпечення – комплекс технічних засобів, які задіяні в технологічному процесі перетворення інформації в системі. Програмне забезпечення включає в себе сукупність програм, що регулярно застосовуються, необхідних для вирішення функціональних задач і програм, що дозволяють найбільш ефективно використовувати обчислювальну техніку, забезпечуючи користувачам найбільшу зручність в роботі. Математичне забезпечення – сукупність математичних методів, моделей і алгоритмів обробки інформації, використовуваних в системі. Лінгвістичне забезпечення – сукупність мовних засобів, які використовуються в системі, що мають ціль підвищення якості її розробки і облегшити співпрацю користувача з системою. Організаційні підсистеми також можуть відноситися до забезпечуючим підсистемам, але більше направлені в першу чергу на забезпечення зручної та швидкої роботи користувачів і для цього всі підсистемо, які відносяться до цієї категорії можуть бути виділені. Інформаційне забезпечення – єдина система класифікації і хешування інформації, уніфікованих систем документації, схем моделей і інформаційних потоків а також методології проектування БД. [11] Технічне забезпечення – комплекс технічних засобів, які призначені для роботи інформаційної системи, технічна документація до даного комплексу і технологічні процеси. До категорії технічних засобів складають: Комп’ютери; Пристрої обчислення, додавання і зберігання інформації; Пристрої передачі даних. О.П. Буйницька в своїй книгі [10] зазначає, що програмне і математичне забезпечення – сукупність методів, алгоритмів, моделей і програм для реалізації цілей і задач ІС, а також для правильної роботи різних спеціалізованих технічних засобів. До засобів математичного забезпечення відносяться: Засоби моделювання процесів управління; Задачі управління; Методи математичного програмування, математичної статистики, теорії масового обслуговування. До складу програмного забезпечення належать спеціалізовані програмні продукти, загальносистемні додатки, а також технічна документація. Організаційне забезпечення – це сукупність засобів і методів, які визначають взаємодію модулів один з одним, в процесі використання інформаційної системи. 2.2 Функції ІС До основних функцій ІС входять функції додавання та обробки інформації та ресурсів і їх зберігання в БД. Для коректної обробки запитів споживачів, дана ІС має виконувати такі функції як: Додавання даних показників лічильника; Отримати всі записи з одного лічильника; Зареєструвати користувача; Авторизувати користувача; Отримати інформацію про користувача за його ідентифікатором; Отримати всі групи лічильників, та список лічильників, що до них належать, та всі записи від лічильника; Видалити споживача та всю інформацію, що відноситься його профілю; Оновити дані користувача; Отримати інформацію про адресу за її ідентифікатором; Додати нову адресу; Оновити дані про адресу; Видалити адресу; Створити нову групу лічильників; Отримати список лічильників з однієї групи; Оновити дані групи лічильників; Видалити групу лічильників, лічильники, які до неї відносились та всі записи з показниками, що відносяться до лічильника; Створити організацію; Отримати інформацію про організацію по її ідентифікатору; Оновити дані про організацію; Отримати список організацій, по типу ресурсу; Створити новий лічильник; Оновити дані про лічильник; Видалити лічильник та всі його записи показників; Перевіряти на коректність дані існуючої адреси; Перевіряти на коректність дані нової адреси; Перевіряти чи існує адреса з тими даними, які були введені користувачем; Перевіряти чи існує адреса в БД; Знайти користувача по електронній адресі; Перевірити чи існує в БД запис лічильника з тими даними, які запросив користувач; Отримати всі лічильники за ідентифікатором групи; Отримати останній запис показника з одного лічильника по його ідентифікатору; Отримати всі групи лічильників конкретного користувача; Перевірити чи існує в БД запис групи лічильників з тими даними, які запросив користувач; Отримати організацію за номером ЄДРПОУ; Перевірити чи існує в БД запис організації з тими даними, які запросив користувач; Перевіряти на коректність дані існуючого користувача; Перевіряти на коректність дані нового користувача; Генерувати унікальний токен для користувача; Перевіряти на коректність дані існуючого лічильника; Перевіряти на коректність дані існуючої групи лічильників; Перевіряти на коректність дані нової групи лічильників; Перевіряти на коректність дані існуючої організації; Перевіряти на коректність дані нової організації; Перевіряти на авторизованого користувача; Усі функції мають працювати без жодного порушення в роботі, без збоїв і неправильних обчислень в роботі. Кожна функція має чітко виконувати саме те, що вказано в технічному завданні. Далі розберемо як створено і реалізовано кожну функцію, разом з моделями і блок-схемами: 1. Додавання показників лічильника Дана функція потрібна для можливості зберігання усіх показників з подальшою обробкою цих даних. Блок-схема цієї функції зображена у вигляді алгоритму на рисунку 2.1. На рисунку 2.2 зображено код функції. На рисунку 2.3 зображено результат роботи функції. Рисунок 2.1 – Блок-схема алгоритму функції №1 Рисунок 2.2 – Код функції №1 Рисунок 2.3 – Результат роботи функції №1 2. Отримати всі записи з одного лічильника Дана функція повертає всі записи показників, що зв’язані з лічильником, який вказаний по його ідентифікатору. Блок-схема зображена на рисунку 2.4, код програми – 2.5, результат роботи – 2.6. Рисунок 2.4 – Блок-схема функції №2 Рисунок 2.5 – Код функції №2 Рисунок 2.6 – Результат роботи функції №2 3. Зареєструвати користувача В кожній ІС, де користувачі можуть користуватися додатком, має бути реєстрація і авторизація. Ця функція служить для реєстрації. На рисунку 2.7 зображено блок-схему алгоритму, на рисунку 2.8 – код програми, результат роботи – на рисунку 2.9. Рисунок 2.7 – Блок-схема функції №3 Рисунок 2.8 – Код функції №3 Рисунок 2.9 – Результат роботи 4. Авторизувати користувача Функція авторизації була частково описана вище, також є схожою з минулою функцією. На рисунку 2.10 зображено блок-схему алгоритму, на рисунку 2.11 – код програми, результат роботи – на рисунку 2.12. Рисунок 2.10 – Блок-схема функції №4 Рисунок 2.11 – Код функції №4 Рисунок 2.12 – Результат роботи функції №4 5. Отримати інформацію про користувача за його ідентифікатором Ця функція служить для отримання повних даних про користувача, які запитується по його ідентифікатору. На рисунку 2.13 зображено блок-схему алгоритму, на рисунку 2.14 – код програми, результат роботи – на рисунку 2.15. Рисунок 2.13 – Блок-схема функції 5 Рисунок 2.14 – Код функції №5 Рисунок 2.15 – Результат роботи функції №5 6. Отримати всі групи лічильників, та список лічильників, що до них належать, та всі записи від лічильника На рисунку 2.16 зображено блок-схему алгоритму, на рисунку 2.17 – код програми, результат роботи – на рисунку 2.18. Рисунок 2.16 – Блок-схема функції 6 Рисунок 2.17 – Код функції №6 Рисунок 2.18 – Результат роботи функції №6 7. Видалити споживача та всю інформацію, що відноситься його профілю На рисунку 2.19 зображено блок-схему алгоритму, на рисунку 2.20 – код програми, результат роботи – на рисунку 2.21. Рисунок 2.19 – Блок-схема функції №7 Рисунок 2.20 – Код функції №7 Рисунок 2.21 – Результат роботи функції №7 8. Оновити дані користувача На рисунку 2.22 зображено блок-схему алгоритму, на рисунку 2.23 – код програми, результат роботи – на рисунку 2.24. Рисунок 2.22 – Блок-схема функції №8 Рисунок 2.23 – Код функції №8 Рисунок 2.24 – Результат роботи функції №8 9. Отримати інформацію про адресу за її ідентифікатором На рисунку 2.25 зображено блок-схему алгоритму, на рисунку 2.26 – код програми, результат роботи – на рисунку 2.27. Рисунок 2.25 – Блок-схема функції №9 Рисунок 2.26 – Код функції №9 Рисунок 2.27 – Результат роботи функції №9 10. Додати нову адресу На рисунку 2.28 зображено блок-схему алгоритму, на рисунку 2.29 – код програми, результат роботи – на рисунку 2.30 . Рисунок 2.28 – Блок-схема функції №10 Рисунок 2.29 – Код функції №10 Рисунок 2.30 – Результат роботи функції №10 11. Оновити дані про адресу На рисунку 2.28 зображено блок-схему алгоритму, на рисунку 2.29 – код програми, результат роботи – на рисунку 2.30 . Рисунок 2.28 – Блок-схема функції №11 Рисунок 2.29 – Код функції №11 Рисунок 2.30 – Результат роботи функції №11 12. Видалити адресу Адреса видаляється в той момент, коли видаляється користувач. На рисунку 2.31 зображено блок-схему алгоритму, на рисунку 2.32 – код програми . Рисунок 2.31 – Блок-схема функції №12 Рисунок 2.32 – Код функції №12 13. Створити нову групу лічильників На рисунку 2.33 зображено блок-схему алгоритму, на рисунку 2.34 – код програми, результат роботи – на рисунку 2.35 . Рисунок 2.33 – Блок-схема функції №13 Рисунок 2.34 – Код функції №13 Рисунок 2.35 – Результат роботи функції №13 14. Отримати список лічильників з однієї групи На рисунку 2.36 зображено блок-схему алгоритму, на рисунку 2.37 – код програми, результат роботи – на рисунку 2.38 . Рисунок 2.36 – Блок-схема функції №14 Рисунок 2.37 – Код функції №14 Рисунок 2.37 – Результат роботи функції №14 15. Оновити дані групи лічильників На рисунку 2.39 зображено блок-схему алгоритму, на рисунку 2.40 – код програми, результат роботи – на рисунку 2.41 . Рисунок 2.39 – Блок-схема функції №15 Рисунок 2.40 – Код функції №15 Рисунок 2.41 – Результат роботи функції №15 16. Видалити групу лічильників, лічильники, які до неї відносились та всі записи з показниками, що відносяться до лічильника На рисунку 2.42 зображено блок-схему алгоритму, на рисунку 2.43 – код програми, результат роботи – на рисунку 2.44 . Рисунок 2.42 – Блок-схема функції №16 Рисунок 2.43 – Код функції №16 Рисунок 2.44 – Результат роботи функції №16 17. Створити організацію На рисунку 2.45 зображено блок-схему алгоритму, на рисунку 2.46 – код програми, результат роботи – на рисунку 2.47 . Рисунок 2.45 – Блок-схема функції №17 Рисунок 2.46 – Код функції №17 Рисунок 2.47 – Результат роботи функції №17 18. Отримати інформацію про організацію по її ідентифікатору На рисунку 2.48 зображено блок-схему алгоритму, на рисунку 2.49 – код програми, результат роботи – на рисунку 2.50 . Рисунок 2.48 – Блок-схема функції №18 Рисунок 2.49 – Код функції №18 Рисунок 2.50 – Результат роботи функції №18 19. Оновити дані про організацію На рисунку 2.51 зображено блок-схему алгоритму, на рисунку 2.52 – код програми, результат роботи – на рисунку 2.53 . Рисунок 2.51 – Блок-схема функції №19 Рисунок 2.52 – Код функції №19 Рисунок 2.53 – Результат роботи функції №19 20. Отримати список організацій, по типу ресурсу На рисунку 2.54 зображено блок-схему алгоритму, на рисунку 2.55 – код програми, результат роботи – на рисунку 2.56 . Рисунок 2.54 – Блок-схема функції №20 Рисунок 2.55 – Код функції №20 Рисунок 2.56 – Результат роботи функції №20 21. Створити новий лічильник На рисунку 2.57 зображено блок-схему алгоритму, на рисунку 2.58 – код програми, результат роботи – на рисунку 2.59 . Рисунок 2.57 – Блок-схема функції №21 Рисунок 2.58 – Код функції №21 Рисунок 2.59 – Результат роботи функції №21 22. Оновити дані про лічильник На рисунку 2.60 зображено блок-схему алгоритму, на рисунку 2.61 – код програми, результат роботи – на рисунку 2.62 . Рисунок 2.60 – Блок-схема функції №22 Рисунок 2.61 – Код функції №22 Рисунок 2.62 – Результат роботи функції №22 23. Видалити лічильник та всі його записи показників На рисунку 2.63 зображено блок-схему алгоритму, на рисунку 2.64 – код програми, результат роботи – на рисунку 2.65 . Рисунок 2.63 – Блок-схема функції №23 Рисунок 2.64 – Код функції №23 Рисунок 2.65 – Результат роботи функції №23 24. Перевіряти на коректність дані існуючої адреси Дана функція призначена для того, аби перевіряти на правильність дані, які ввів користувач при оновленні адреси і якщо якість дані не співпадають зі заданими параметрами, то користувач отримає помилку з текстом, в якому вказано де саме він зробив помилку. На рисунку 2.66 зображено код програми. Рисунок 2.66 – Код функції №24 25. Перевіряти на коректність дані нової адреси Дана функція схожа з минулою але відмінність в них є, а саме ця функція перевіряє коректність даних при створенні адреси. На рисунку 2.67 зображено код програми. Рисунок 2.67 – Код функції №25 26. Перевіряти чи існує адреса з тими даними, які були введені користувачем Дана функція проводить пошук адреси з тими даними, які ввів користувач, і повертає значення «true» або «false», якщо існує чи не існує така адреса. На рисунку 2.68 зображено код програми. Рисунок 2.68 – Код функції №26 27. Перевіряти чи існує адреса в БД Дана функція схожа з минулою, але дана функція проводить пошук не за даними, а за ідентифікатором. На рисунку 2.69 зображено код програми. Рисунок 2.69 – Код функції №27 28. Знайти користувача по електронній адресі Дана функція проводить пошук користувача в БД за електронною адресою, і повертає користувача, якщо такий є. На рисунку 2.70 зображено код програми. Рисунок 2.70 – Код функції №28 29. Перевірити чи існує в БД запис лічильника з тими даними, які запросив користувач Дана функція проводить пошук лічильника з тими даними, які ввів користувач і повертає його, якщо такий є. На рисунку 2.71 зображено код програми. Рисунок 2.71 – Код функції №29 30. Отримати всі лічильники за ідентифікатором групи Дана функція проводить пошук лічильників за ідентифікатором групи лічильників та повертає список таких лічильників. На рисунку 2.72 зображено код програми. Рисунок 2.72 – Код функції №30 31. Отримати останній запис показника з одного лічильника по його ідентифікатору Дана функція проводить пошук останнього запису показника за лічильником, ідентифікатор якого визначає користувач. На рисунку 2.73 зображено код програми. Рисунок 2.73 – Код функції №31 32. Отримати всі групи лічильників конкретного користувача Дана функція проводить пошук усіх груп лічильників які належать конкретному користувачу. На рисунку 2.74 зображено код програми. Рисунок 2.74 – Код функції №32 33. Перевірити чи існує в БД запис групи лічильників з тими даними, які запросив користувач Дана функція робить пошук по БД за тими даними, що задав користувач і якщо така група існує, повертає значення «true». На рисунку 2.75 зображено код програми. Рисунок 2.75 – Код функції №33 34. Отримати організацію за номером ЄДРПОУ Дана функція робить пошук в БД по номеру ЄДРПОУ і повертає організацію, якщо така є, інакше – значення «false». На рисунку 2.76 зображено код програми. Рисунок 2.76 – Код функції №34 35. Перевірити чи існує в БД запис організації з тими даними, які запросив користувач Дана функція проводить пошук організації з тими даними, які ввів користувач, і повертає значення «true» або «false», якщо існує чи не існує така організація. На рисунку 2.77 зображено код програми. Рисунок 2.77 – Код функції №35 36. Перевіряти на коректність дані існуючого користувача Дана функція проводить перевірку на коректність даних користувача. На рисунку 2.78 зображено код програми. Рисунок 2.78 – Код функції №36 37. Перевіряти на коректність дані нового користувача Дана функція проводить перевірку на коректність даних користувача, який реєструється. На рисунку 2.79 зображено код програми. Рисунок 2.79 – Код функції №37 38. Генерувати унікальний токен для користувача Дана функція генерує унікальний набір символів, який зв’язується з ідентифікатором користувача, який реєструється. На рисунку 2.80 зображено код програми. Рисунок 2.80 – Код функції №38 39. Перевіряти на коректність дані існуючого лічильника Дана функція перевіряє дані, які були введені користувачем, про групу лічильників. На рисунку 2.81 зображено код програми. Рисунок 2.81 – Код функції №39 40. Перевіряти на коректність дані існуючої групи лічильників Дана функція перевіряє на коректність дані про групу лічильників, яка оновлюється. На рисунку 2.82 зображено код програми. Рисунок 2.82 – Код функції №40 41. Перевіряти на коректність дані існуючої організації Дана функція перевіряє на коректність дані про існуючу організацію. На рисунку 2.83 зображено код програми. Рисунок 2.83 – Код функції №41 42. Перевіряти на коректність дані нової організації Дана функція перевіряє на коректність дані про організацію, що створюється. На рисунку 2.84 зображено код програми. Рисунок 2.84 – Код функції №42 43. Перевіряти на авторизованого користувача Дана функція перед обробкою запитів перевіряє чи авторизований користувач, що надіслав цей запит, і якщо він не авторизований, то повертає про це помилку. На рисунку 2.85 зображено код програми. Рисунок 2.85 – Код функції №43 ВИСНОВКИ В кожному етапі розробки даного серверного додатку, я дотримувався загальних правил архітектури та структури системи, щоб кінцева архітектура була в рамках загальноприйнятих стандартів. Для додатку я власноруч розробив модель додатку. Він включає в себе декілька підсистем, а конкретно шість підсистем, які співпрацюють між собою, і крім того спілкуються з базою даних. В системі присутній модуль реєстрація і авторизації. При створенні самої БД проводився аналіз предметної області. Створюючи даний додаток, що був дипломною роботою, я закріпив теоретичні знання з баз даних та отримав практичні навички щодо проектування та створення баз даних. Крім того, я вивчив основні інструменти та принципи створення бази даних за допомогою PostgreSQL і, поглибивши свої знання у серверній розробці, перейти на серверну частину та працювати вже безпосередньо з глобальною мережею та хмарами. Виконання роботи складалося з семи етапів: Першим етапом був аналіз відомих рішень. Знайшовши варіанти існуючих рішень, було переглянуто і проведено аналіз існуючих рішень, розглянуто їх недоліки та переваги; Другим етапом було створення архітектури додатку; Третім етапом було створення структури БД; Четвертим етапом було написання програмного коду додатку; П’ятим етапом було створення бази даних; На шостому етапі було проведене тестування на швидкість відповіді і обробки даних; Останнім сьомим етапом було створення пояснювальної записки до диплому; В даній роботі було розглянуто процес, методи та засоби створення інформаційної системи для роботи з мобільним додатком, від інтерфейсу співпраці з додатками до роботи з базою даних. Завдання, які були поставлені та їх виконання: 1. Аналіз відомих рішень: Перед проектуванням архітектури додатку та бази даних було переглянуто існуючі рішення та дещо схожі варіанти і було оцінено степінь готовності продуктів та їх переваги і недоліки. 2. Створити архітектуру проекту: Після обробки інформації про існуючі варіанти, було створено архітектуру додатку на основі паттерну mvc, а саме model-service-controller. 3. Спроектувати базу даних: Знаючи, яка інформація нам потрібна для роботи додатку, було спроектовано схему бази даних, яка ідеально підходить для наших потреб. 4. Реалізація програмних модулів: Використовуючи вище названі технології, було розроблено окремі модулі, які працюють між собою. 5. Провести тестування на виявлення помилок. В кінці реалізації програмних модулів, було проведено тестування, на виявлення помилок реагування сервера на ті чи інші дані. В кінці тестування було виявлено, що сервер коректно працює з даними, якщо ті введені правильно чи з помилками. В результаті виконання даної роботи були вирішені завдання, поставлені на початку роботи. Розроблена ІС стійко виконує всі свої функції. Я впевнений, що мені вдалося створити зручну для користувачів та просту в адмініструванні інформаційну систему. СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 1. Додаток «Комунальні послуги» URL: https://play.google.com/store/apps/details?id=com.atlant.kommunalkafree 2. Додаток «Комуналка» URL: https://play.google.com/store/apps/details?id=com.wallet.komunalka 3. Додаток «Єдиний Рахунок» URL: https://play.google.com/store/apps/details?id=ua.vn.softgeneration.pay 4. И. Браун. “Веб-разработка с применением Node и Express. Полноценное использование стека JavaScript. 2-е издание.”, 2021 5. Євгеній Моргунов «PostgreSQL. Основы языка SQL. Учебное пособие PostgreSQL. Основы языка SQL. Учебное пособие», 2019 6. Олена Струтинська “Інформаційні системи та мережеві технології”, 2008 7. Володимир Павлиш, Лариса Гліненко, Наталія Шаховська “Основи інформаційних технологій і систем ”, 2018 8. Стаття “Зв’язки в реляційних базах даних”, URL: https://infopedia.su/4x5d2a.html 9 Стаття «Поняття, класифікація та види інформаційних систем» URL: https://totrdlo.ru/uk/gde-ispolzuyut-informacionnye-sistemy-ponyatie-klassifikaciya- i.html 10. Буйницька О.П Інформаційні технології та технічні засоби навчання, 2012 11 В.І. Стоян, О.С. Даневич, М.Й. Мац Казначейська система, 2002 12 М.П. Войнаренко, О.М. Кузьміна, Т.В. Янчук Інформаційні системи і технології в управлінні організацією, 2015 13 Є.М. Нужний, І.В. Клименко, О.О. Акімов Інстументальні засоби електронного офісу, 2016 14. М. Тамер Ёсу, Патрик Вальдуриес «Принципы организации распределенных баз данных», 2020 15. Гектор Гарсиа-МолинаДжеффри Д. УльманДженнифер Уидом «Системы баз данных. Полный курс», 2016 16. Пилко И. С. «Информационные и библиотечные технологии», 2006 17. Таненбаум Э.С., Бос Х. «Современные операционные системы. 4-е издание», 2015 18. Томас Коннолли, Каролин Бегг «Базы данных. Проектирование, реализация и сопровождение», 2017 19. Кемпбелл Л., Бази даних. Інжиніринг надійності, 2020 20. Ольга Сазонец, Інформаційні системи і технології в управлінні зовнішньоекономічною діяльністю, 2014 21. Борис Погріщук, Ю. Паночишин, Комп’ютерна техніка та інформаційні технології, 2012 22. Алекс Янг, Брэдли Мек, Майк Кантелон «Node.js в действии, 2-е издание», 2015 23. М. Тамер Есу,Патрик Вальдуриес, «Принципы организации распределенных баз данных», 2020 24. Осипов Дмитрий Леонидович, Технологии проектирования баз данных, 2019 25. К. Дж. Дейт «Введение в системы баз данных (8-е издание)», 2020