Главная страница
qrcode

Курсова робота пояснювальна записка з навчальної дисципліни Аналіз та рефакторинг коду програмного забезпечення Тема роботи Програмна система для відслідковування та прогнозування наявних відносин людей в колективі І управління цими процесами


НазваниеКурсова робота пояснювальна записка з навчальної дисципліни Аналіз та рефакторинг коду програмного забезпечення Тема роботи Програмна система для відслідковування та прогнозування наявних відносин людей в колективі І управління цими процесами
Дата28.07.2020
Размер1.73 Mb.
Формат файлаdocx
Имя файлаpzpi-17-6-hryb-roman-report.docx
ТипПояснювальна записка
#89532
Каталог


Міністерство освіти і науки України

Харківський національний університет радіоелектроніки
Факультет комп’ютерних наук

Кафедра програмної інженерії

КУРСОВА РОБОТА

ПОЯСНЮВАЛЬНА ЗАПИСКА

з навчальної дисципліни «Аналіз та рефакторинг коду

програмного забезпечення»

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


Студент гр. ПЗПІ-17-6

Гриб Р.В.

(підпис)

Керівник роботи

доц. Лещинська І.О.

(підпис)

Роботу захищено« » 2020 р. з оцінкою

Комісія: доц. Лещинський В.О.

(підпис)

доц. Лещинська І.О.

(підпис)

ст.викл. Сокорчук І.П.

(підпис)

Харків

2020 р.

Харківський національний університет радіоелектроніки

Факультет комп’ютернихнаук Кафедра програмноїінженерії Спеціальність 121 – Інженерія програмногозабезпечення

Курс 3 Семестр 6 Навчальна дисципліна Аналізтарефакторингкодупрограмногозабезпечення
ЗАВДАННЯ

НА КУРСОВУ РОБОТУ СТУДЕНТОВІ

Грибу Роману Владиславовичу

Тема роботи: «Програмна система для відслідковування та прогнозування наявних відносин людей в колективі і управління цими процесами»

Термін узгодження завдання курсової роботи «4» квітня 2020 р.

Термін здачі студентом закінченої роботи «28» травня 2020 р.

4. Вихідні дані до проекту (роботи): В програмній системіпередбачити:

реєстрацію та авторизацію користувача в системі, проведення тестів на темперамент та тип характеру, конфіденційність психофізіологічних характеристик користувача, перегляд інформацію профілю, алгоритм аналізу та співвідношення психофізіологічних даних користувачів, завантаження результату співвідношення даних користувачів.
Використовувати ОС Windows 10, СКБД MySql, середовища розробки Visual Code, Android Studio.

5. Зміст пояснювальної записки (перелік питань, що належить розробити) вступ,

постановка задачі, проектування програмного проекту, структура бази

даних,описрозробленоїпрограмноїсистеми,висновки, перелік посилань,додатки.

6. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень)

архітектура проекту, схема бази даних, діаграма варіантів використання,

діаграма розгортання, інтерфейс головноїсторінки

КАЛЕНДАРНИЙ ПЛАН



Назва етапів курсової роботи

Термін виконання

етапів роботи

Примітка

1

Функціональна специфікація

програмного проекту

10.03.2020

виконано

2

Проектування програмного

проекту

20.03.2020

виконано

3

Кодування програмного проекту

13.04.2020

виконано

4

Оформлення пояснювальної записки

25.05.2020

виконано

5

Захист курсової роботи

28.05.2020

виконано


Дата видачі завдання « » 2020 р.

Керівник доц. Лещинська І.О.

(підпис)

Завдання прийняв до виконання ст.гр. ПЗПІІ-17-6 Гриб Р.В.

(підпис)

РЕФЕРАТ

Пояснювальна записка до курсової роботи: 36 с., 27 рис., 1 додаток, 8 джерел.

ER–DIAGRAM, NODE.JS, MYSQL SERVER, RESTFUL API, БАЗИ ДАНИХ, ПРОГРАМНА СИСТЕМА, ANDROID APP, ПРЕДМЕТНА ОБЛАСТЬ.

Об’єктом дослідження є між людська взаємодія у повсякденному житті, а також вивчення індивідуальних психофізіологічних характеристик людей, для застосування їх у подальшому створенні алгоритму співвідношення людей за цими характеристиками.

Метою роботи є розробка програмної системи, яка допоможе організаторам міжлюдських взаємодій виявити найкращі співвідношення між людьми на основі їх психофізіологічних характеристик на засадах об'єктно-орієнтованого програмування, використання баз даних.

Методи розробки базуються на використанні середи розробки Android Studio, Microsoft Visual Code, мов програмування Java, JavaScript, Node.Js та бази даних mysql.

В результаті отримана програмна система, яка дозволяє пройти тести на темперамент та тип характеру і в результаті чого отримати рекомендації щодо організації людських взаємодій для компаній, які організовують ці взаємодії.

ЗМІСТ


ВСТУП 5

1 АНАЛІЗ ПРЕДМЕТНОЇ ГАЛУЗІ 6

2 ПОСТАНОВКА ЗАДАЧІ 7

3 АРХІТЕКТУРА ТА ПРОЕКТУВАННЯ ПРОГРАМНОЇ СИСТЕМИ 8

3.1 Архітектура програмної системи 8

3.2 Проектування бази даних 9

3.3 Серверна частина 10

3.4 Клієнтська частина 15

3.5 Мобільний застосунок 19

3.6 IoT частина 23

4 ОПИС ПРИЙНЯТИХ ПРОГРАМНИХ РІШЕНЬ 25

4.1 Серверна частина 25

4.2 Веб клієнт 26

4.3 Мобільний клієнт 28

4.4 IoT клієнт 32

ВИСНОВКИ 33

ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ 34

ДОДАТОК А 35


ВСТУП




На сьогоднішній день людям з різним набором психофізіологічних особливостей доводиться проводити час разом. Це може бути поїздка на громадському транспорті, взаємодія людей у колективах, організація місць на виставах в театрах і тому подібне.

У кожної людини є свої власні вподобання та бажання щодо взаємодії з іншими людьми – існує поняття інтровертів та екстравертів, дві протилежності, які між собою не можуть взаємодіяти з комфортом. Як зробити взаємодію людей більш комфортною, підвищити рівень продуктивності на підприємствах, та як зробити це так, щоб не доставити незручності людям – основні питання, які виникають під час організаційних процесів на робочих місцях, та взагалі – у повсякденному житті.

Метою курсової роботи є розробка системи, яка допоможе організаторам між людських взаємодій створювати комфортні умови для людей шляхом отримання співвідношення людей між собою. Програмна система буде зберігати інформацію про тип характеру і темперамент людей. Організатори людських взаємодій зможуть з легкістю здійснювати запит до системи на отримання співвідношення між людьми та використовувати результат аналізу даних у власних цілях щодо співвідношення людей один до одного, що було б неможливо без використання даної системи.

1 АНАЛІЗ ПРЕДМЕТНОЇ ГАЛУЗІ




На сьогоднішній день людям з різним набором психофізіологічних особливостей доводиться проводити час разом. Це може бути поїздка на громадському транспорті, взаємодія людей у колективах, організація місць на виставах в театрах і тому подібне.

На даний момент на ринку існує безліч глобальних систем, які являються зручними інструментами при організації робочих процесів та взаємодії у колективах, такі як: Trello, To Do List, Taskmanager, PeopleOrganizer, але ж такі системи цілком і повністю залежать від людини яка власноруч створює умови для людської взаємодії і найчастіше не враховуючи людські інтереси, а робить це за здібностями та рівнем знань.

Існує багато аналогічних систем, які тестують користувачів за їх психофізіологічними характеристиками, це такі як: TemperamentTest, Personality Test, IdealPersonalTest, але такі системи не пов’язані ніяк з іншими системами. Вони лише тестують та беруть дані користувачів і надають їх тим самим користувачам, тобто в повсякденному житті це не принесе багато користі. Розроблена в результаті курсової роботи система, буде не тільки тестувати людей на психофізіологічні характеристики, але й проводити аналіз цих характеристик, та виводити співвідношення людей між собою, тобто сумісність людей один з одним.

У наш час під час любого процесу взаємодії людей організатори намагаються створювати дуже комфортні зовнішні умови, але ці умови є однаковими для усіх, а кожна людина – індивідуальність, тому треба враховувати її вподобання та намагатися створювати внутрішній комфорт. Система буде враховувати темперамент та характер кожного користувача для створення внутрішнього комфорту кожної людини в колективі.

2 ПОСТАНОВКА ЗАДАЧІ




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

За допомогою мобільного клієнта будуть збиратися дані користувачів та передаватися у базу даних. Мобільний клієнт повинен використовувати операційну систему Android, не нижче версії Android 5.0.

За допомогою IoT система буде показувати користувачеві коефіцієнт його корисної дії або відсоток комфортності в умовах, створених організаторами чи роботодавцями. IoT повинно бути реалізовано на Raspberry Pi.

Організатори будуть мати змогу за допомогою Web-сервісу надсилати захищену інформацію на сервер, де буде проводитись обробка та аналіз даних і повертатися готовий результат. Web-сервіс повинен включати в себе використання спеціальних скриптів JavaScript.

Для роботи з базою даних повинна використовуватися мова mysql, та хмарне сховище Heroku.

Програмна система повинна містити наступний функціонал:

ОФ-1 – Реєстрація та авторизація користувачів в системі;

ОФ-2 – Шифрування даних;

ОФ-3 – Профіль користувача;

ОФ-4 – Тестування на визначення психофізіологічних характеристик користувача;

ОФ-5 – Запит на отримання аналізу даних для сторонніх сервісів;

ОФ-6 – Створення груп чи колективів людей;

ОФ-7 – Аналіз, відправлених сторонніми сервісами даних;

ОФ-8 – Локалізація;

ОФ-9 – Завантаження результату аналізу;

ОФ-10 – Реєстрація та авторизація компаній в системі;

3 АРХІТЕКТУРА ТА ПРОЕКТУВАННЯ ПРОГРАМНОЇ СИСТЕМИ

3.1 Архітектура програмної системи




Програмна система передбачає 4-х рівневу архітектуру, яка буде складатися з 4 рівнів: рівня мобільного клієнту, веб-клієнт, клієнту IoT, та рівня серверу, який в свою чергу приймає та оброблює запити з клієнтів, та відправляє відповідь до клієнтів, де у свою чергу клієнти оброблюють відповідь від серверу та відображають користувачу (див. рис. 3.1).


Рисунок 3.1 – Діаграма розгортання архітектури
Мобільний клієнт повинен містити в собі рівень бізнес логіки, для проведення тестувань на психофізіологічні характеристики користувачів та обробки результатів тестування.

IoT клієнт необхідний для того, щоб користувач мав змогу приєднатися до групи людей, у так звану «кімнату», яку створили організатори заходу.

Серверний рівень архітектури повинен містити в собі рівень бізнес логіки для аналізу психофізіологічних характеристик користувачів та отримання запитів з клієнтів, обробки та посилання обробленої відповіді до клієнтів.


3.2 Проектування бази даних




Усі сутності, атрибути та зв’язки бази даних було організовано у ER-діаграмі (див. рис. 3.2).

Рисунок 3.2 – ER-діаграма
На рисунку 3.1 наведено 5 сутностей, це:

Сутність User – зберігає дані користувача, а саме: унікальний ідентифікатор(індекс в базі даних), пароль у вигляді hash-коду, електронна пошта(унікальна для кожного користувача), ПІБ(прізвище, ім’я та по-батькові) користувача, а також hash-інформація про темперамент та тип характеру.

Сутність Company – зберігає всю інформацію про компанію, а саме: унікальний ідентифікатор(індекс в базі даних), назва компанії, а також вид компанії за напрямком діяльності.

Сутність CompanyRoom – зберігає інформацію про «кімнату» колективу людей, яку створюють компанії та організатори міжлюдських взаємодій, а саме: унікальний ідентифікатор кімнати, ідентифікатор компанії що створила кімнату, кількість користувачів які під’єдналися до кімнати, а також ідентифікатор користувача

Сутність CompanyRoomContract – зберігає інформацію про уявний «контракт» між людиною та компанією, тобто зберігає інформацію про те яка людина і у якому колективі людей знаходиться, і містить: унікальний ідентифікатор контракту, ідентифікатор кімнати до якої приєднується користувач, а також ідентифікатор користувача.

Сутність Analysis – зберігає вся інформацію про аналіз результатів користувачів, а саме – унікальний ідентифікатор аналізу, його результат, загальна кількість людей, які брали участь в аналізі, а також ідентифікатор компанії, яка провела цей аналіз.

Як вказано на рисунку 3.1 зв’язки 1:М розташовані між:

Сутністю User та CompanyRoomContract;

сутністю CompanyRoom та CompanyRoomContract;

сутністю Company та CompanyRoom;

сутністю Company та Analysis.





3.3 Серверна частина




Для реалізації серверної частини та обробки запитів було використано мову Node.js, та хмарне сховище Heroku для збереження бази даних у віддаленому доступі.

Загальні можливості роботи з серверною частиною було відображено у UseCase діаграмі (див. рис. 3.3).

Рисунок 3.3 – UseCase діаграма серверу
Користувач (User), використовуючи мобільну програму може мати можливість:

Зареєструватися у системі (SignUp) – під час реєстрації, пароль користувача хешується за допомогою модуля bcript – бібліотека в node.js, створена для хешування інформації, користувач під час реєстрації вводить наступні дані: пошта, ПІБ користувача, пароль.

Авторизуватися (Login) – у результаті вдалої авторизації, серверна частина генерує та відправляє клієнтській частині спеціальний ключ-токен, використовуючи який, клієнтська частина отримує змогу використовувати основні запити до серверу, так як не авторизований користувач не зможе це зробити.

Отримати інформацію про себе (GetProfileInfo) – під час використання даного запиту користувачеві відправляється інформація про його психофізіологічні характеристики, а також дані, які він вказував при реєстрації, окрім паролю.

Змінити інформацію про себе (UpdateProfile) – запит на зміну імені користувача, яке він вказував при реєстрації.

Скласти тест на темперамент (PassTheTemperamentTest) – серверна частина не зберігає інформацію про тести (питання, правильні відповіді, бали за тест), а лише зберігає результат тесту, який приходить у вигляді запита на зміну темпераменту користувача.

Скласти тест на тип характеру (PassTheTypeCharacterTest) – серверна частина не зберігає інформацію про тести (питання, правильні відповіді, бали за тест), а лише зберігає результат тесту, який приходить у вигляді запита на зміну типу характеру користувача.

Компанія (Company), використовуючи веб-клієнт може мати можливість:

Зареєструватися у системі (SignUp) – під час реєстрації, пароль компанії хешується за допомогою модуля bcript – бібліотека в node.js, створена для хешування інформації, під час реєстрації компанія вводить наступні дані: пошта, ім’я компанії, тип компанії за напрямком.

Авторизуватися (Login) – у результаті вдалої авторизації, серверна частина генерує та відправляє клієнтській частині спеціальний ключ-токен, використовуючи який, клієнтська частина отримує змогу використовувати основні запити до серверу, так як не авторизований користувач не зможе це зробити.

Створити «кімнату» для користувачів (CreateCompanyRoom) – компанія має змогу «кімнату», куди можуть приєднуватися користувачі, використовуючи свій IoT пристрій.

Відправити дані на аналіз (SendDataToAnalyse) – компанія має змогу відправити ідентифікатори користувачів з «кімнати» до серверу, де в свою чергу, функція аналізу збирає дані з БД для отримання інформації про психофізіологічні характеристики користувачів. Тобто сама компанія не може володіти такою інформацією, вона лише знає унікальні ідентифікатори користувачів, тобто зберігається конфеденційність.

Отримати результат аналізу (GetAnalyseResult) – компанія має можливість отримати дані аналізу використовуючи певний запит.

Завантажити результат аналізу (DownloadTheResult) – компанія після відправки запиту на отримання результату аналізу сумісності користувачів із «кімнати» має змогу завантажити файл з інформацією про відсотки сумісності між користувачами.

Серверна частина, написана на node.js складається із каталогів та двох файлів необхідних для запуску серверу (див. рис. 3.4).

Рисунок 3.4 – Діаграма класів серверу
Файл server.js – головний файл, який використовується для запуску серверу. Він використовує дані про сервер та URL – адреси для отримання запитів з клієнтів. Дані про сервер підключаються з файлу app.js.

У файлі app.js – зберігаються усі шляхи та всі модулі (бібліотеки), підключені до серверу. Тут розписуються всі шляхи на обробку запитів, які в свою чергу під’єднуються з каталогу routes.

Структура серверної частини складається з декількох каталогів, які взаємодіють між собою.

Каталог «routes» та всі файли що там знаходяться – зберігають обробники запитів, а також посилаються на каталог «controller», так як запит, отриманий від клієнта проходить спершу через каталог «route», який використовує код з каталогу «controller» для обробки запиту. В свою чергу файли з каталогу «controller» не тільки виконують роль обробника запитів, а й також використовують файли з каталогу «model», в яких зберігаються моделі, тобто сутності бази даних, так як з бд ми працюємо, використовуючи ORM під назвою Sequelize.

Каталог «database» необхідний для того щоб працювати з базою даних. Файл «links» створює зв’язки між сутностями бази даних.

Каталог «middleware» містить файл «check-auth», який використовується у всіх файлах з каталогу routes, який має функцію перевірки спеціального ключа-токена, який перевіряється під час отримання запитів, і у разі відсутності токену відправиться спеціальна помилка «Unauthorized», що означає, що клієнт, який відправив запит – не авторизований, і у нього немає доступу до тих чи інших команд серверу.

На рисунку 3.4 знаходяться спеціальні класи-моделі: User, Company, CompanyRoom, CompanyRoomContract, Analysis, кожна з яких має свій відповідний файл у кожному з переліченому вище каталогів «route», «model» та «controller», тобто наприклад у кожному з перелічених каталогів є файл user.js, який виконує певну функцію в залежності від каталогу у якому знаходиться.

Серверна частина є головною частиною, яка працює з даними, запитами, які приходять з клієнтів. Тобто запити, відправлені з веб чи мобільного клієнтів будуть проходити через файли з каталогу «controller», для того щоб опрацювати ці запити. І в свою чергу ці спеціальні файли-контроллери взаємодіють з таблицями бази даних з хмарного сховища Heroku (див. рис. 3.5).

Рисунок 3.5 – Діаграма розгортання серверу


3.4 Клієнтська частина




Для реалізації веб-клієнту було використано мову JavaScript, а також мову розмітки HTML та каскадні таблиці стилів (CSS).

Користувачем у даному разі є компанії, інакше – організатори між людських взаємодій. Для неавторизованих користувачів доступна лише реєстрація (див. рис. 3.6).

Рисунок 3.6 – UseCase діаграма веб частини
На відміну від неавторизованих користувачів, авторизовані мають змогу переглядати повність весь сайт та використовувати повний функціонал, а саме:

створення «кімнат» користувачів (CreateConnectionRoom) – необхідно створити пароль для кімнати;

перегляд «кімнат», та користувачів у ньому(GetAllRooms);

відправляти дані на аналіз та отримання і завантаження відсоткового співвідношення(GetAnalysis), але за умови, якщо у «кімнаті» більше двох осіб.

Стан веб-клієнту змінюється в залежності від дій користувача. На рисунку 3.7 було описано залежність від дій користувача і станів сайту.


Рисунок 3.7 – Діаграма станів веб частини

Опинившись вперше на сайті, користувач знаходиться на сторінці логіну (Logining), де має змогу перейти на сторінку реєстрації компанії (Registrationing), або якщо вже є аккаунт то перейти до основної частини сайту(блок «site»).

Так як компанії мають змогу створити «кімнату» для групи людей, тому при натисканні «Connection Room» відкриється форма створення кімнати, де користувач вводить пароль «кімнати» і у результаті вдалого запиту кімната буде створена і форма закриється.

Також користувач має змогу переглянути уже існуючі кімнати компанії (Showing Rooms form). Та при натисканні на конкретну кімнату можна переглянути сторінку з учасниками групи людей (Showing Room analysis page). І також отримати файл з відсотковою сумісністю людей у групі, натиснувши «Get analysis», після чого система перейде в стан «Downloading result» і почнеться завантаження файлу з результатом.

У будь-який момент часу, користувач може закрити вкладку з сайтом і перейти до стану «Close site», на якому сайт закривається.

Також під час виконань дій із веб-клієнтом, система напряму взаємодіє з веб-клієнтом, у вигляді запитів, та відповідей (див. рис. А.1).

Увійшовши в перший раз до сайту, користувач зареєструє свою компанію перейшовши до сторінки реєстрації (Registration Page) і після уведення даних та натиснення кнопки «Sign up» відбудеться відправлення запиту до серверу, у свою чергу сервер надсилає запит до бази даних щодо створення нової компанії, і якщо все відбувається вдало – користувача повертає на сторінку авторизації (Login page).

Авторизація відбувається подібним шляхом – вводяться дані, відправляється запит та у разі вдалого виконання операції – користувачу надається доступ до основної частини сайту та пересилає на головну сторінку (Main page).

Створення «кімнати» для групи людей відбувається аналогічним образом як і з реєстрацією, посилається запит на створення нової «кімнати».

На формі всіх кімнат компанії «Rooms form», відбувається запит на отримання всіх кімнат з бази даних конкретної компанії по тій же схемі – запит до сервера, а потім запит до бази даних і повернення результату.

У разі якщо користувач бажає отримати відсоткове співвідношення людей у групі за зрівнянням по психофізіологічним параметрам, то у разі натиснення «Get analysis», буде відправлено запит до сервера, передано ідентифікатори користувачів у кімнаті, проаналізовано співвідношення людей, та повернеться результат. Веб-клієнт самостійно формує та виводить форму завантаження результату, тому користувач має змогу завантажити результат аналізу.

При натисненні на «Logout», користувач опиниться на сторінці логіну.


3.5 Мобільний застосунок




Для реалізації мобільного клієнту було використано мову Java, та бібліотеку retrofit2 для роботи з запитами до серверу.

Користувачем у даному мобільному клієнті є будь-яка людина. Для того щоб користуватися мобільним клієнтом треба пройти реєстрацію та авторизуватись (див. рис. 3.8).

Рисунок 3.8 – UseCase діаграма мобільної частини
Користувач має можливість перейти до профілю та отримати інформацію про себе (GetProfileInfo), а також змінити інформацію про себе, зокрема – ім’я (Edit profile).

Основний функціонал мобільної частини системи полягає в тому щоб провести тестування для людини на тип характеру та темперамент людини і зберігати ці данні у базі даних. Тому користувач має можливість пройти тест на темперамент (StartTemperamentTest) та тест на тип характеру (StartTypeCharacterTest).

Мобільна частина складається з каталогів, та класів всередині цих каталогів (див. рис. 3.9).

Рисунок 3.9 – Діаграма класів мобільної частини
Авторизація та все, що пов’язано з нею знаходиться у каталозі login. При першому запуску, користувачу відкривається сторінка класу MainActivity.java. Якщо користувач вже має аккаунт то після введення пошти та паролю, дані збираються і проходять крізь клас LoginResponse.java, де в свою чергу перетворюються на JSON-рядок і відправляється на сервер, а також відповідь із сервера «проходить» через цей клас, та отримується токен і ідентифікатор користувача, який увійшов. В каталозі також присутній інтерфейс Api_JSON_Authorization, який містить в собі метод, який формує та відправляє запит до серверу, використовуючи спеціальні шаблони бібліотеки retrofit2.

Функціонал реєстрації знаходиться у каталозі registration. Аналогічно авторизації, сторінка реєстрації знаходиться в файлі Registration.java. Клас, через який «проходять» дані – RegistrationResponse.java, інтерфейс для зв’язку з сервером – Api_JSON_Registration.

Функціонал профілю користувача знаходиться у каталозі profile. Інтерфейс для управління бібліотекою retrofit – Api_JSON_Profile, головний клас – Profile, клас для збору та відправки даних – ProfileResponse.java, а також клас User.java, який також збирає дані користувача.

Основний функціонал знаходиться в окремій групі Quizer (див. рис. 3.10).


Рисунок 3.10 – Quizer класи
Головний та перший файл – Quizer.java – перша сторінка після авторизації – клас в якому користувач може вибрати, який тест проходити йому, та в залежності від цього він потрапить на клас з тестом на темпераментом (QuizActivity.java), чи на тест на тип характеру (CharacterTestActivity.java).

Класи схожі за структурою, адже виконують майже однакові функції. Інтерфейси, через які встановлюється зв’язок із сервером – Api_JSON_ResultTemperament та Api_JSON_ResultTypeOfCharacter, містять функцію встановлення результату тесту у відповідне поле в інформації про користувача.

QuestionModel.java та QuestionCharacterModel.java містять в собі структуру запитань, які в свою чергу будують запитання у головних класах QuizActivity та CharacterTestActivity.

TemperamentModel.java та TypeOfCharacterModel.java – необхідні для керування даними перед відправкою на сервер запиту на оновлення темпераменту чи типу характеру користувача.

Класи ResultTemperamentActivity.java та ResultTypeOfCharacterActiviti.java – це сторінки остаточного результату за тест, вони просто відображають результат тесту після його завершення.

Тестування у мобільній частині – це локальний функціонал, не пов’язаний з роботою з сервером напряму, окрім реєстрації, авторизації та роботи з даними користувача (див. рис. 3.11).


Рисунок 3.11 – Діаграма розгортання мобільної частини
Мобільна частина використовує бібліотеку retrofit2 для зв’язку із сервером, реалізуючи спеціальні інтерфейси Api_JSON_ Registration, Api_JSON_Authorization та Api_JSON_Profile.

В свою чергу запити серверу до бази даних використовують http-запити, для передачі даних чи їх зміни.


3.6 IoT частина




Для реалізації IoT-клієнту було використано мову Node.js, відображено на емуляторі VirtualBox.

Система передбачає увімкнення користувачем пристрою (Connect device), після чого пристрій збирає та відправляє дані до кімнати(Connect to Connection Room), яку створювала та чи інша компанія, після чого користувач стане зареєстрованим у кімнаті компанії (див. рис. 3.12).


Рисунок 3.12 – UseCase діаграма IoT частини
IoT-пристрій не має так багато станів, як той же веб-клієнт, але й сам у свою чергу добре виконує свої функції (див. рис. 3.13).


Рисунок 3.13 – Діаграма станів
У стані «Отримання даних авторизації з серверу»(«Getting authorization info from server») система збирає дані авторизації користувача та посилає запит на логін, в результаті якого з серверу присилається ідентифікатор користувача, який зберігається в теперішній сессії девайсу.

У стані «Відправити дані про користувача до серверу»(«Send data about current user to server») система відправляє дані про користувача (його темперамент та тип характеру) до кімнати з’єднання, і у результаті вдалої відправки – закриває теперішню сесію системи.

Увесь функціонал IoT знаходиться в окремому файлі connectUs.js, який посилає запити до серверу і отримує відповіді та відображає користувачу (див. рис. 3.14).

Рисунок 3.14 – Діаграма розгортування

Функціонал працює напряму з контроллерами серверу – CompanyRoomController та UserController через запити http, так само як і сервер до бази даних.

4 ОПИС ПРИЙНЯТИХ ПРОГРАМНИХ РІШЕНЬ

4.1 Серверна частина




На основі попередньо спроектованих діаграм було спроектовано серверну частину, яка складається з каталогів (див. рис. 4.1).


Рисунок 4.1 – Загальна структура серверної частини
Каталог route – маршрути для прийняття url-запитів. Каталог controllers – приймає запит від каталогу route на виконання конкретної функції, тобто оброблює запит. Каталог database використовує класи моделі з каталогу model, для взаємодії з даними бази даних (див. рис. 4.2).


Рисунок 4.2 – Загальна структура серверної частини

4.2 Веб клієнт




У веб частині системи реалізовано взаємодію компанії або організаторів заходів із системою.

Для того щоб отримати доступ до основних функцій, необхідно вперше пройти авторизацію (див. рис. 4.3), або реєстрацію в системі (див. рис. 4.4).


Рисунок 4.3 – Сторінка авторизації


Рисунок 4.4 – Сторінка реєстрації
Компанія може створити «кімнату», де відбувається підключення людей, для збору та аналізу їх психофізіологічних характеристик, для цього необхідно вписати пароль для кімнати, який в свою чергу буде передаватися на IoT пристрій користувачам (див. рис. 4.5)


Рисунок 4.5 – Форма створення кімнати
Проаналізувати та завантажити результат співвідношення людей між собою за їх темпераментами та типами характеру, можна у формі «кімнати» (див. рис. 4.6).

Рисунок 4.6 – Форма кімнати

4.3 Мобільний клієнт




Мобільний клієнт надає можливість користувачу пройти тест на темперамент та тип характеру, а також переглядати власний профіль, та можливість змінити ім’я у профілі, але для того щоб отримати доступ до повного функціоналу, користувачу необхідно зареєструватися (рисунок 4.7), чи пройти авторизацію (рисунок 4.8).

Рисунок 4.7 – Сторінка реєстрації


Рисунок 4.8 – Сторінка авторизації
Для того щоб розпочати тестування, необхідно вибрати вид тестування, який потрібен користувачу (рисунок 4.9), і пройти усі питання тесту (рисунок 4.10).

Рисунок 4.9 – Сторінка категорій


Рисунок 4.10 – Сторінка тесту

Результат відображається користувачу після закінчення тесту (рисунок 4.11), а переглянути інформацію про себе користувач має можливість в профілі на головній сторінці застосунку (рисунок 4.12).


Рисунок 4.11 – Сторінка результату тесту

Рисунок 4.12 – Сторінка профіля

4.4 IoT клієнт




IoT частина взаємодіє з сервером, шляхом посилання запитів. Користувачем є людина, яка хоче приєднатися до «кімнати», тобто в групу людей що яким-небудь чином взаємодіють.

Для цього користувачу необхідно пройти авторизацію шляхом увімкнення пристрою, а також необхідно увести спеціальний пароль, який вказується з боку організації. При вдалому запиті система добавить користувача у групу людей (див. рис. 4.13).


Рисунок 4.13 – Відправлення запиту з IoT частини

ВИСНОВКИ




В даній курсовій роботі була спроектована і реалізована програмна система для спрощення організації між людських взаємодій. Було створено серверну частину, веб-клієнт, мобільний клієнт та IoT-клієнт, а також було створено і розписано діаграми до кожної з частин системи.

А також було проаналізовано предметну область і створено вимоги до програмної системи, створено документ специфікації програмного забезпечення.

Було самостійно вивчено принципи написання чистого коду, основ рефакторингу та реіжинірингу коду, закріплено теоретичні знань та практичних навички, отриманих в ході вивчення даної навчальної дисципліни.

Програмна система та її складові частини було розроблено за допомогою середовища розробки Visual Code (серверну та веб частини, а також IoT), Android Studio (мобільна частина), та MySql Workbench, за допомогою якої було здійснено швидкий доступ до бази даних.

Були виконані всі вимоги, які були перераховані в розділі постановки завдання.

ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ




1. Нормалізація баз даних. URL: https://ukrbukva.net/92785-Normalizaciya-baz-dannyh.html. (дата звернення: 27.12.2020).

2. Бьюли А. Вивчаємо SQL - СПб.: Вид.: Символ-Плюс; 2007. – 312 с.

3. Чистий код // Рефакторінг: від брудного до чистого. Refactoring.Guru. URL: https://refactoring.guru/uk/refactoring/what-is-refactoring. (дата звернення: 24.05.2020).

4. Сучасний посібник використання JavaScript URL: https://learn.javascript.ru/. (дата звернення: 07.04.2020).

5. Android Studio та створення нового проекту. URL:https://metanit.com/java/android/1.2.php. (дата звернення: 12.04.2020).

6. RESTful API Server – Doing it the right way: [Електронний ресурс] – режим доступу до ресурсу : http://blog.mugunthkumar.com/articles/restful-api-serverdoing-it-the-right-way-part-1/. (дата звернення: 22.03.2020).

7. RESTful API design with Node.js: [Електронний ресурс] – режим доступу до ресурсу : https://hackernoon.com/restful-api-design-with-node-js-26ccf66eab09. (дата звернення: 22.03.2020).

8. Heroku. How to deploy your server. URL:https://devcenter.heroku.com/articles/getting-started-with-nodejs. (дата звернення: 24.03.2020).

9. Raspbian Jessie on VirtualBox. URL: https://www.avoiderrors.com/install-raspbian-virtualbox/. (дата звернення: 06.05.2020).


ДОДАТОК А


Діаграма послідовності для веб частини

Рисунок А.1 – Діаграма послідовності
перейти в каталог файлов


связь с админом