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/8924| Title: | WEB-ЗАСТОСУНОК ДЛЯ ОРГАНІЗАЦІЇ РОБОЧИХ ПРОЦЕСІВ |
| Authors: | Куницька, Світлана Юріївна Калайда, Вадим Русланович |
| Keywords: | WEB-ЗАСТОСУНОК;ОРГАНІЗАЦІЯ;РОБОЧІ ПРОЦЕСИ;REACT;БАЗА ДАНИХ;АУТЕНТИФІКАЦІЯ;АВТОРИЗАЦІЯ;ІНТЕРФЕЙС КОРИСТУВАЧА;API;ТЕСТУВАННЯ |
| Issue Date: | 21-Jun-2025 |
| Abstract: | АНОТАЦІЯ Калайда В.Р., кваліфікаційна робота бакалавра на тему «WEB-ЗАСТОСУНОК ДЛЯ ОРГАНІЗАЦІЇ РОБОЧИХ ПРОЦЕСІВ». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2025. Мета виконання кваліфікаційної роботи бакалавра: проектування та конструювання web-застосунку, як платформи для візуалізації та управління завданнями, що сприяє підвищенню продуктивності команди шляхом оптимізації робочих потоків та мінімізації проектних затримок. Завдання при проектуванні інформаційної системи: провести аналіз існуючих рішень, визначити їхні переваги та недоліки; розробити архітектуру програмної системи та відобразити взаємодію її компонентів побудувавши діаграми; визначити функціональні та нефункціональні вимоги; обґрунтувати інтеграції API інструментів розробки; описати додаток за допомогою структурних і функціональних схем; спроектувати базу даних та інтерфейс; провести тестування програмної системи; створити інструкцію користувача. Об'єкт роботи: процес розробки web-застосунку для організації робочих процесів. Предмет розробки: методи та засоби створення WEB-застосунку для організації робочих процесів, включаючи архітектуру системи, алгоритми управління завданнями та інтерфейс користувача. Вирішено наступні поставлені задачі: 1. Проаналізовано існуючі аналоги web-застосунку. 2. Розроблено архітектуру програмної системи та її взаємопов’язаних компонентів та створено діаграми моделювання поведінки системи. 3. Спроектовано базу даних автоматизованої інформаційної системи. 4. Розроблено інтерфейс користувача спроектованого web-застосунку ReactJS та Styled-Components. 5. Проведено тестування розробленого програмного забезпечення, аутентифікація та авторизація інформаційної системи. Обсяг кваліфікаційної роботи бакалавра – містить 3 розділи, рисунки, таблицы, джерела в списку посилань, 4 додатки. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/8924 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Калайда Вадим Русланович.pdf Restricted Access | 5.78 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: «WEB-ЗАСТОСУНОК ДЛЯ ОРГАНІЗАЦІЇ РОБОЧИХ
ПРОЦЕСІВ»
Виконала: студентка 4 курсу, групи ПЗ-2104
спеціальності
121 «Інженерія програмного забезпечення»
Студент Калайда В.Р.
(прізвище та ініціали)
Керівник Куницька С. Ю.
(прізвище та ініціали)
Рецензент Захарова М. В.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС,
д.т.н., професор
__________________Сергій ГОЛУБ
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Калайді Вадиму Руслановичу
1. Тема роботи: «WEB-ЗАСТОСУНОК ДЛЯ ОРГАНІЗАЦІЇ РОБОЧИХ
ПРОЦЕСІВ»_____________________________________________________________________
Керівник роботи к.т.н., доцент Куницька Світлана Юріївна_____________________________
Затверджені наказом Черкаського державного технологічного університету №_53/03-03____
від «25» 02 2025 року
2. Строк подання студентом роботи 10.06.2025_______________________________________
3. Вхідні дані до роботи: серверна платформа Node.js, мова програмування JavaScript, веб-
фреймворк Express.js, бібліотека React, NoSQL база даних MongoDB, бібліотека для Node.js
Mongoose, набір інтерфейсів API____________________________________________________
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити):
1 Існуючі методи та засоби розв’язання поставлених завдань;___________________________
2 Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;____________________________________________________________
3 Розробка та тестування програмного забезпечення;___________________________________
Висновки;_______________________________________________________________________
Список використаних джерел;______________________________________________________
Додатки.________________________________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
Додаток А - Специфікація___________________________________________________
Додаток Б – Текст програми розробки_________________________________________
Додаток В – Інструкція користувачеві_________________________________________
Додаток Г – Графічні матеріали_______________________________________________
6. Консультанти розділів роботи
7. Дата видачі завдання «_02_»_грудня_2024р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 03.12.2024 виконано
2 Формування рішень задач 11.12.2024 виконано
3 Погодження завдання 22.12.2024 виконано
Основна стадія
1 Підбір матеріалів 12.02.2025 виконано
2 Аналіз шляхів вирішення поставлених 20.02.2025 виконано
задач
3 Розробка діаграм, як проектного рішення 24.03.2025 виконано
4 Визначення вимог 30.03.2025 виконано
5 Проектування додатку. Розробка 28.04.2025 виконано
інтерфейсної частини
Заключна стадія
1 Узгодження прийнятих проектних 05.05.2025 виконано
рішень з керівником
2 Оформлення пояснювальної записки 16.05.2025 виконано
роботи в кінцевій редакції
3 Попередній захист роботи 19.05.2025 виконано
4 Затвердження роботи 10.06.2025 виконано
5 Рецензування роботи 17.06.2025 виконано
6 Захист роботи 20.06.2025 виконано
Студент _____________________ Калайда В.Р.
Керівник роботи _____________________ Куницька С. Ю.
АНОТАЦІЯ
Калайда В.Р., кваліфікаційна робота бакалавра на тему «WEB-
ЗАСТОСУНОК ДЛЯ ОРГАНІЗАЦІЇ РОБОЧИХ ПРОЦЕСІВ». Напрям підготовки
121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2025.
Мета виконання кваліфікаційної роботи бакалавра: проектування та
конструювання web-застосунку, як платформи для візуалізації та управління
завданнями, що сприяє підвищенню продуктивності команди шляхом оптимізації
робочих потоків та мінімізації проектних затримок.
Завдання при проектуванні інформаційної системи: провести аналіз
існуючих рішень, визначити їхні переваги та недоліки; розробити архітектуру
програмної системи та відобразити взаємодію її компонентів побудувавши
діаграми; визначити функціональні та нефункціональні вимоги; обґрунтувати
інтеграції API інструментів розробки; описати додаток за допомогою структурних
і функціональних схем; спроектувати базу даних та інтерфейс; провести
тестування програмної системи; створити інструкцію користувача.
Об'єкт роботи: процес розробки web-застосунку для організації робочих
процесів.
Предмет розробки: методи та засоби створення WEB-застосунку для
організації робочих процесів, включаючи архітектуру системи, алгоритми
управління завданнями та інтерфейс користувача.
Вирішено наступні поставлені задачі:
1. Проаналізовано існуючі аналоги web-застосунку.
2. Розроблено архітектуру програмної системи та її взаємопов’язаних
компонентів та створено діаграми моделювання поведінки системи.
3. Спроектовано базу даних автоматизованої інформаційної системи.
4. Розроблено інтерфейс користувача спроектованого web-застосунку
ReactJS та Styled-Components.
5. Проведено тестування розробленого програмного забезпечення,
аутентифікація та авторизація інформаційної системи.
Обсяг кваліфікаційної роботи бакалавра – містить 3 розділи, рисунки,
таблицы, джерела в списку посилань, 4 додатки.
Ключові слова: WEB-ЗАСТОСУНОК, ОРГАНІЗАЦІЯ, РОБОЧІ
ПРОЦЕСИ, REACT, БАЗА ДАНИХ, АУТЕНТИФІКАЦІЯ, АВТОРИЗАЦІЯ,
ІНТЕРФЕЙС КОРИСТУВАЧА, API, ТЕСТУВАННЯ.
ЗМІСТ
ВСТУП .................................................................................................................. 5
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ ............................................................................................................. 8
1.1 Існуючі методи до розв’язання поставленого завдання ............................ 8
1.2 Огляд аналогів ............................................................................................. 9
1.3 Сформовані задачі для проектування ....................................................... 13
1.4 Використання сучасних технологій для розв’язання поставленної задачі
..............................................................................................................................15
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ......................................................... 17
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ............................................................................................................. 18
2.1 Моделювання предметної області ............................................................ 18
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області ....................................................................................... 19
2.1.2 Елементи моделювання предметної області . ... ....................................23
2.1.3 Робоча область моделювання ............................................................. 29
2.2 Формування та аналіз вимог ..................................................................... 29
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги. .......................................................................................................... 30
2.2.2 Формування вимог за допомогою діаграми прецедентів . ................. 34
2.3 Проектування логічної структури ............................................................ 37
2.3.1 Діаграми класів.................................................................................... 38
2.3.2 Діаграми пакетів .................................................................................. 42
ЧДТУ 252153.006 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Калайда В.Р «WEB-застосунок для організації Літ. Лист Листів
Перевір. Куницька С.Ю. робочих процесів» 3
Реценцезнт Захарова М.В
Пояснювальна записка.
Н. Контр. Півень О.Б. ФІТІС, кафедра ПЗАС, ПЗ-2104
Затверд. Голуб С.В.
2.4 Архітектурне проектування..............................................................................43
2.4.1 Діаграма компонентів ................. ..........................................................44
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання .................................................................................................. 45
2.5 Моделювання поведінки системи .... ...........................................................47
2.5.1 Діаграма діяльності . .................... ..........................................................47
2.5.2 Діаграма послідовності ....................................................................... 49
2.5.3 Діаграма комунікації . .................. ..........................................................52
2.5.4 Діаграма скінченого автомату .... ...........................................................55
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ .......................................................... 57
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
............................................................................................................................. 60
3.1 Розробка програмного комплексу ............................................................ 60
3.1.1 Обґрунтування вибору засобів реалізації .......................................... 60
3.1.2 Опис структурної (функціональної) схеми ........................................ 62
3.1.3 Опис логічної схеми системи ............................................................. 63
3.1.4 Розробка бази даних ............................................................................ 65
3.1.5 Розробка інтерфейсу користувача ...................................................... 72
3.1.6 Опис розробки програмних компонентів ........................................... 84
3.2 Тестування системи................................................................................... 87
3.2.1 Модульне тестування .......................................................................... 87
3.2.2 Інтеграційне тестування ...................................................................... 89
3.2.3 Системне тестування........................................................................... 91
3.2.4 Приймальне тестування ...................................................................... 93
3.3 Приклади впровадження програмного комплексу .................................. 94
3.3.1 Розгортання системи ........................................................................... 94
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ........................................................ 96
ВИСНОВКИ ....................................................................................................... 97
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ........................................................... 98
ДОДАТКИ ........................................................................................................ 100
ЧДТУ 252153.006 ПЗ
Змн. Арк. № докум. Підпис Дата
ВСТУП
Актуальність теми. Сучасний ринок вимагає від організацій високої
гнучкості та здатності швидко адаптуватися до змін. З цією метою, багато
компаній застосовують різноманітні методи управління проектами та робочими
процесами. Одним із найбільш ефективних і поширених інструментів для
оптимізації робочих потоків є Канбан-дошка. Це візуальний інструмент, який
дозволяє контролювати завдання на всіх етапах їх виконання, забезпечуючи
прозорість і зручність в управлінні робочими процесами. Це популярний
інструмент у середовищі Agile, адже дозволяє гнучко реагувати на зміни,
забезпечуючи при цьому чітке уявлення про поточний стан завдань і проектів.
Мета і завдання розробки. Метою є проектування та конструювання web-
застосунку, як платформи для візуалізації та управління завданнями, що сприяє
підвищенню продуктивності команди шляхом оптимізації робочих потоків та
мінімізації проектних затримок.
Задачі розробки:
1. Проаналізувати існуючі аналоги web-застосунку.
2. Розробити архітектуру програмної системи та її взаємопов’язаних
компонентів та створити діаграми моделювання поведінки системи.
3. Спроектувати базу даних автоматизованої інформаційної системи.
4. Розробити інтерфейс користувача спроектованого web-застосунку
ReactJS та Styled-Components.
5. Провести тестування розробленого програмного забезпечення,
аутентифікацію та авторизацію інформаційної системи.
В ході проектування програмної системи було сформовано наступні
завдання: змоделювати предметну область, сформувати та проаналізувати вимоги
до проекту, спроектувати логічну структуру веб-сайту, зробити архітектурне
проектування, змоделювати поведінку системи та відобразити в спроектованій
системі всі етапи конструювання програмної системи.
Об’єкт розробки. Об'єктом роботи є процес розробки web-застосунку для
організації робочих процесів.
Предмет розробки. Предметом розробки є методи та засоби створення
WEB-застосунку для організації робочих процесів, включаючи архітектуру
системи, алгоритми управління завданнями та інтерфейс користувача
Методи проектування та конструювання. Під час розробки було
застосовано об’єктно-орієнтований підхід (ООП) для моделювання основних
сутностей системи — таких як дошки, картки, користувачі — із використанням
принципів наслідування, інкапсуляції та поліморфізму. Для забезпечення
масштабованості й модифікованості використано модульне проєктування: окремі
модулі відповідають за аутентифікацію, керування завданнями, планування подій,
комунікацію між учасниками та сповіщення. Також було застосовано
функціонально-орієнтоване проєктування на рівні бізнес-логіки окремих
компонентів, що спростило реалізацію логіки взаємодії між елементами системи.
Опис отриманих результатів. В результаті було розроблено web-
застосунок, який дозволяє візуалізувати всі етапи роботи і створити обмеження
одночасно виконуваних завдань. Спрощує управлінські рішення щодо
організаційних моментів будь якого проекту. Для роботи програмної системи
було спроектовано базу даних для наповнення інформаційними даними, що
забезпечує контроль та обробку інформації. Проведено моделювання поведінку
програмної системи, що дозволяє візуально визначити правильність побудованої
логіки та здійснено тестування програмного забезпечення видами тестування, що
надало можливість відлагодити помилки системи. Захист інформаційних даних
відбувається через авторизацію та автентифікацію.
Практичне значення отриманих результатів. Розроблений web-
застосунок дозволяє контролювати завдання на всіх етапах їх виконання,
забезпечуючи прозорість і зручність в управлінні робочими процесами. Важливим
є правильне налаштування критеріїв для кожного етапу роботи, що дозволяє
організувати роботу таким чином, щоб завдання рухалися безперервно, без
затримок, а розробка механізмів значно сприяє підвищенню ефективності роботи
команд через використання цього інструменту.
Система забезпечує:
− створення й редагування карток з налаштуванням термінів, пріоритетів
і відповідальних осіб;
− групування карток за категоріями;
− відстеження статусів виконання та загального прогресу;
− персоналізацію структури даних відповідно до потреб користувача.
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
Однією з основних проблем, що виникають при організації робочих
процесів, є недоліки в управлінні часом та завданнями. Без чіткої організації та
контролю за виконанням задач, команди можуть стикатися з проблемами
затримок, перевантаження та незадоволення результатами. Використання Канбан
дозволяє вирішити цю проблему шляхом візуалізації всіх етапів роботи і
обмеження одночасно виконуваних завдань.
Однак, незважаючи на численні переваги, впровадження Канбан не є
безпроблемним. Як зазначають Дж. Гріффітс і С. Кемпбелл (2018), «найбільша
проблема при впровадженні Канбан-системи полягає в тому, що організації
повинні бути готові до змін у корпоративній культурі і на практиці адаптувати
свої робочі процеси» [2, с. 102]. Це може вимагати навчання персоналу,
коригування внутрішніх процедур і зміни підходів до управління проектами.
1.1 Існуючі методи до розв’язання поставленого завдання
Існує низка інструментів для впровадження Канбан в організаціях, серед
яких найпопулярнішими є Trello, Jira, Asana та Microsoft Planner. Кожен з цих
інструментів має свої особливості та може використовуватись в різних умовах :
Інструменти для організації робочих процесів із використанням Канбан-
дошки мають суттєві відмінності, що залежать від специфіки проекту, масштабу
команди та функціональних можливостей. Trello відрізняється простотою у
використанні та швидким стартом, що робить його ідеальним для невеликих
проектів та персональних завдань. Однак при роботі з великими проектами або
командами його функціонал може виявитися недостатнім. З іншого боку, Jira
забезпечує розширені можливості для управління складними проектами, але її
функціонал може бути перевантаженим для малих команд. Asana пропонує гнучке
управління завданнями та різноманітні подання даних, проте її функціонал
автоматизації та аналітики може бути обмеженим.
Велика різниця між інструментами полягає в рівні аналітики. Jira надає
потужну аналітику та можливість детального аналізу прогресу проектів, тоді як у
Trello ці можливості обмежені без додаткових розширень. Також автоматизація
робочих процесів краще реалізована в Jira, тоді як Asana та Trello мають більш
базові рішення для автоматизації. Важливим моментом є те, що жоден з
інструментів не спеціалізується винятково на Канбан; вони пропонують інші
функції і методології, що може розмивати фокус.
Для покращення існуючих інструментів можна зосередитися на створенні
більш інтуїтивно зрозумілих рішень для автоматизації робочих процесів без
складної конфігурації. Глибша інтеграція аналітичних функцій також була б
корисною для більш точного відстеження продуктивності команди. Мобільні
рішення потребують вдосконалення, щоб забезпечити користувачам доступ до
повноцінного функціоналу Канбан-дошок незалежно від місцезнаходження.
1.2 Огляд аналогів
Кожен з описаних додатків має свої переваги і обмеження. Проте, більшість
із них фокусуються на обліку даних, не маючи можливостей для детального
прогнозного аналізу, який став би можливим при використанні машинного
навчання.
1. Microsoft Planner — інструмент для управління завданнями,
інтегрований з екосистемою Microsoft 365. Дозволяє створювати канбан-дошки,
призначати задачі учасникам, встановлювати дедлайни та відстежувати прогрес.
Завдяки тісній інтеграції з Teams, Outlook і OneDrive є зручним рішенням для
команд, що вже працюють у середовищі Microsoft (рисунок 1.1).
Основні характеристики:
− інтеграція з Microsoft 365: Planner є частиною пакету Microsoft 365,
що забезпечує тісну інтеграцію з Outlook, Teams, OneDrive та іншими
сервісами, спрощуючи управління завданнями в єдиному робочому
середовищі;
− Канбан-дошка: інтерфейс базується на візуальній моделі Канбан, де
завдання представлені у вигляді карток, які можна переміщати між
стовпцями (етапами виконання);
− спільна робота: Planner дозволяє призначати завдання членам команди,
додавати дедлайни, вкладення, контрольні списки та коментарі;
− простота використання: мінімалістичний інтерфейс і автоматична
синхронізація з Microsoft Teams дозволяють легко інтегрувати
інструмент у щоденну командну роботу.
Рисунок 1.1 – Загальний інтерфейс дошки Microsoft Planner
Недоліки:
− залежність від екосистеми Microsoft: Planner найефективніше працює
лише в межах Microsoft 365. Якщо команда не використовує інші
сервіси Microsoft, робота з Planner може бути обмеженою або
незручною;
− обмежена функціональність для складних проектів: Відсутність
розширених налаштувань робочих процесів, автоматизації та гнучких
прав доступу робить Planner менш придатним для масштабних або
специфічних проєктів;
− недостатня аналітика: інструмент не має вбудованих потужних звітів
або дашбордів, що ускладнює глибокий аналіз виконання задач без
сторонніх засобів, таких як Power BI.
2. Jira - розширений інструмент, який використовується для управління
проектами в більш складних організаційних структурах. Jira підтримує Канбан-
метод і дозволяє автоматизувати багато процесів, що значно підвищує
ефективність роботи команд.
Рисунок 1.2 – Інтерфейс дошки Jira
Основні характеристики:
- потужний функціонал для складних проектів: Jira пропонує розширені
функції для управління проектами, включаючи можливість побудови
багаторівневих робочих процесів, налаштування автоматизації завдань і
створення детальних звітів;
- інтеграція з методологіями Scrum і Kanban: ця платформа підходить як
для гнучких команд, що використовують Agile, так і для традиційних
методологій;
- розширена аналітика: Jira пропонує глибокий аналіз даних, що дозволяє
відстежувати продуктивність команди та прогрес проекту;
- інтеграції: підтримує широкий спектр інтеграцій із іншими
інструментами для розробки ПЗ та управління проектами.
Недоліки:
- складність налаштування: початкова настройка може бути складною, що
вимагає часу і ресурсів для адаптації;
- ціна: у порівнянні з іншими інструментами, Jira може бути дорогою,
особливо для невеликих команд;
- перевантаженість функціями: для малих проектів або користувачів, які
шукають прості рішення, функціонал може бути надмірно складним.
3. Asana — ще один інструмент для організації завдань, який дозволяє
зручно візуалізувати робочі процеси і керувати проектами з використанням
Канбан-дошки (рисунок 1.3). Asana також має функції для обміну коментарями та
інтеграції з іншими програмами.
Основні характеристики:
- візуалізація та різноманітність подань: Asana дозволяє організовувати
завдання у вигляді списків, календарів, дошок і таймлайнів;
- інтеграція з іншими інструментами: підтримує інтеграції з Google
Workspace, Slack, Dropbox та іншими сервісами;
- гнучке управління завданнями: користувачі можуть легко налаштовувати
завдання, встановлювати пріоритети, додавати підзадачі і контролювати
дедлайни;
- зручний для командної роботи: завдання можуть мати коментарі,
вкладення, повідомлення та нагадування.
Рисунок 1.3 – Інтерфейс дошки Asana
Недоліки:
- відсутність гнучкої автоматизації: можливості автоматизації процесів
обмежені у порівнянні з Jira;
- складність в обслуговуванні великих команд: при роботі з великими
проектами Asana може стати менш гнучкою;
- відсутність спеціалізації на Канбан: Asana є багатофункціональним
інструментом, і Канбан є лише однією з її функцій. Тому платформа
може бути менш оптимізованою для виключно Канбан-методології.
1.3 Сформовані задачі для проектування
Сьогодення диктує нам нові умови праці та співпраці в будь якій діяльності
та напрямку. Все більше користуються онлайн інструментарієм, що дозволяє не
тільки здійснювати управлінські рішення, а й виконувати інші потреби в
залежності від поставлених задач.
Спроектований веб-додаток має певні переваги для великих запитів щодо
онлайн виконання поставлених задач, тобто контроль виконання та вирішення
організаційних питань, як показав огляд існуючих аналогів, не є проблемою для
керівництва над будь яким проектом.
Додаток має відповідати наступним вимогам:
− створення інтерфейсу web-додатку зрозумілого та простого у
використанні;
− проектування бази даних для наповнення та можливості обробки
інформації, зокрема переміщення по стовпцям переліку завдань;
− забезпечення надійного зберігання великих обсягів даних;
− гнучкість системи при обробці великого масиву даних;
− захист даних та розмежування доступу до табличних структур
інформаційної системи.
Для нормальної роботи проектованого web-додатку з використанням
повного інструментарію та функціоналу було виділено п’ять основних задач:
1. Проаналізувати існуючі аналоги web-застосунку.
2. Розробити архітектуру програмної системи та її взаємопов’язаних
компонентів та створити діаграми моделювання поведінки системи.
3. Спроектувати базу даних автоматизованої інформаційної системи.
4. Розробити інтерфейс користувача спроектованого web-застосунку
ReactJS та Styled-Components.
5. Провести тестування розробленого програмного забезпечення,
аутентифікацію та авторизацію інформаційної системи.
1.4 Використання сучасних технологій для розв’язання поставленої
задачі
Для створення WEB-застосунку для організації робочих процесів
використовуються сучасні технології, що забезпечують високу
продуктивність, зручність та гнучкість для користувачів:
1. Frontend:
- ReactJS: бібліотека JavaScript, яка дозволяє створювати динамічні та
інтерактивні інтерфейси користувача з використанням компонентного
підходу;
- MUI: набір готових компонентів інтерфейсу, що забезпечує швидку
розробку з дотриманням принципів Material Design;
- Styled-Components: інструмент для написання CSS безпосередньо в
JavaScript, що забезпечує гнучке та ізольоване стилізування компонентів.
2. Backend:
- Node.js: серверне середовище виконання JavaScript, яке забезпечує високу
продуктивність і масштабованість додатку;
- Express: легкий фреймворк для Node.js, що спрощує створення серверної
логіки та маршрутизації;
- REST API: архітектурний стиль, який дозволяє клієнтським і серверним
частинам ефективно обмінюватися даними через HTTP-запити.
3. База даних:
- MongoDB: документоорієнтована NoSQL база даних, що забезпечує
гнучке зберігання та швидкий доступ до структурованих і
неструктурованих даних.
4. Безпека:
- JWT (JSON Web Token): технологія для безпечної передачі даних між
клієнтом і сервером, яка використовується для реалізації аутентифікації та
авторизації користувачів.
Інструменти для організації робочих процесів із використанням Канбан-
дошки мають суттєві відмінності, що залежать від специфіки проєкту, масштабу
команди та функціональних можливостей. Microsoft Planner інтегрується в
екосистему Microsoft 365, що робить його зручним вибором для команд, які вже
використовують інші сервіси Microsoft, як Teams чи Outlook. Його простий
інтерфейс дозволяє швидко створювати Канбан-дошки, планувати завдання та
працювати над проєктами в межах знайомого середовища. Проте за межами
екосистеми Microsoft функціональність Planner може бути обмеженою, а
гнучкість налаштувань поступається спеціалізованим рішенням. З іншого боку,
Jira забезпечує розширені можливості для управління складними проєктами, але її
функціонал може бути перевантаженим для малих команд. Asana пропонує гнучке
управління завданнями та різноманітні подання даних, проте її функціонал
автоматизації та аналітики може бути обмеженим.
Велика різниця між інструментами полягає в рівні аналітики. Jira надає
потужну аналітику та можливість детального аналізу прогресу проєктів, тоді як у
Microsoft Planner ці можливості доволі базові. Також автоматизація робочих
процесів краще реалізована в Jira, тоді як Asana та Planner мають більш обмежені
рішення. Важливим моментом є те, що жоден із інструментів не спеціалізується
винятково на Канбан; вони пропонують інші функції і методології, що може
розмивати фокус.
Для покращення існуючих інструментів можна зосередитися на створенні
більш інтуїтивно зрозумілих рішень для автоматизації робочих процесів без
складної конфігурації. Глибша інтеграція аналітичних функцій також була б
корисною для більш точного відстеження продуктивності команди. Мобільні
рішення потребують вдосконалення, щоб забезпечити користувачам доступ до
повноцінного функціоналу Канбан-дошок незалежно від місцезнаходження.
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто актуальні проблеми, пов’язані з
організацією робочих процесів, зокрема неефективне управління завданнями,
перевантаження команд та відсутність прозорості у виконанні задач. Як
ефективне рішення було проаналізовано підхід Канбан, що дозволяє візуалізувати
робочі процеси та обмежувати кількість одночасних завдань. Разом з тим,
впровадження Канбан-систем потребує готовності до змін у внутрішній культурі
організації, що створює додаткові виклики.
Було проведено огляд існуючих веб-додатків з підтримкою Канбан-дошок
— Microsoft Planner, Jira та Asana. Кожен із цих інструментів має свої переваги:
інтеграцію з екосистемами, розширені функції аналітики чи зручність у
користуванні. Проте, жоден із них не є універсальним рішенням: одні обмежені
функціональністю поза екосистемою (Planner), інші — надмірно складні для
малих команд (Jira), або не мають гнучкої автоматизації (Asana).
Також у розділі було проаналізовано сучасні технології, які можуть бути
використані для розробки власного веб-застосунку, що поєднує переваги
аналізованих рішень. Зокрема, було обґрунтовано доцільність використання
ReactJS для створення інтерфейсу, Node.js і Express для побудови backend-
частини, MongoDB як гнучкої бази даних, а також JWT для реалізації безпечної
авторизації. Застосування цих технологій дозволить реалізувати продуктивний,
масштабований і зручний веб-застосунок для управління завданнями з
використанням Канбан-моделі.
Таким чином, аналіз існуючих рішень та технологій підтвердив доцільність
розробки власного веб-застосунку, який буде орієнтований на потреби сучасних
користувачів: зручність інтерфейсу, модульність, адаптивність, ефективне
управління навантаженням і підтримка індивідуального підходу до організації
робочих процесів.
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
Моделювання предметної області - це процес створення абстрактного
представлення спроектованої програмної системи. Цей процес використовується
для кращого розуміння складних систем, прийняття обґрунтованих рішень та
покращення їх функціонування.
Ключові моменти:
- область інтересів: визначає сфери діяльності, які необхідно змоделювати;
- моделювання предметної області: це абстрактне представлення домену,
яке може бути представлене діаграмами, формулами, комп'ютерними програмами
або пояснювальним текстом;
- словник предметної області: набір термінів та визначень, які чітко
описують поняття, що використовуються в моделі;
- елементи моделювання: до них відносяться об'єкти, атрибути, відносини,
події та правила;
- область вивчення зовнішнього моделювання: це частина сфери інтересів,
на якій зосереджена модель.
2.1 Моделювання предметної області
Моделювання предметної області є ключовим етапом у процесі створення
програмного забезпечення для управління робочими процесами із застосуванням
Канбан-дошки. Основне завдання цього етапу полягає у відображенні реальних
бізнес-процесів, задач, ролей і взаємодій, що мають місце в межах організації чи
проекту, з метою їхньої адаптації у програмне середовище. В ході моделювання
здійснюється формалізація елементів предметної області, що дозволяє
проєктувати компоненти системи, зокрема структуру даних, інтерфейси та
основний функціонал, що забезпечують виконання завдань користувачів.
Особлива увага приділяється розмежуванню ролей користувачів, що можуть
взаємодіяти з дошкою, а також правилам і обмеженням, що впливають на робочі
процеси. Завдяки цьому вдається створити програмне забезпечення, яке точно
відповідає потребам користувачів і дозволяє їм підвищити продуктивність.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання.
У випадку організації робочих процесів із застосуванням Канбан-дошки
предметна область моделювання охоплює автоматизацію та впорядкування
завдань, пов’язаних з управлінням потоками роботи в різних проєктах або
організаціях. Основна мета моделювання – створення інтерактивної системи, яка
дозволяє візуалізувати, оптимізувати і регулювати хід робочих процесів,
підвищуючи продуктивність команд і забезпечуючи прозорість усіх етапів
виконання задач. Предметна область фокусується на таких ключових аспектах, як
створення, призначення і переміщення завдань по стовпцях Канбан-дошки,
контроль над витратами часу та ресурсів, аналіз продуктивності й інтеграція з
іншими інструментами.
Ключові компоненти моделювання:
- авторизація користувачів: забезпечує можливість входу до системи
для різних ролей (менеджери, члени команди) з доступом до відповідних функцій.
Після авторизації користувачі можуть створювати та переглядати задачі,
здійснювати контроль над їхнім виконанням і комунікувати з іншими
учасниками;
- завдання: включають створення карток задач, що представляють
елементи роботи. Завдання мають опис, пріоритет, виконавця, статус та дедлайн.
Вони переміщуються між стовпцями відповідно до стадій виконання – "Зробити",
"У процесі", "Завершено" тощо. Можливість деталізації кожного завдання
забезпечує гнучке управління роботою;
- стовпці Канбан-дошки: відображають різні етапи робочого процесу.
Кожен стовпець представляє певний статус завдань, що дозволяє легко
візуалізувати їхнє переміщення по дошці. Застосовуються обмеження кількості
задач у конкретних стовпцях для уникнення перевантаження та оптимізації
роботи команди;
- коментарі та обговорення: ця функція дозволяє користувачам
обмінюватися думками, надавати зворотний зв'язок та уточнювати деталі задач
безпосередньо на картках, що сприяє швидкому вирішенню питань і підвищенню
командної комунікації;
- моніторинг та аналітика: надає статистику щодо виконаних задач,
часу на їхнє виконання, продуктивності команди та інших показників, що
дозволяє виявляти вузькі місця в процесах та здійснювати їх оптимізацію;
- інтеграція з іншими сервісами: включає можливість з'єднання з
календарями, месенджерами чи іншими системами, що сприяє кращій організації
роботи.
Модель предметної області.
Модель відображає ключові компоненти процесу планування, виконання та
контролю завдань на різних етапах за допомогою Канбан-дошки, що забезпечує
прозорість, гнучкість та зручність використання інструментарію.
Основні компоненти предметної області включають:
1. Авторизація користувачів. Для доступу до системи користувачі
повинні пройти авторизацію за допомогою логіна та пароля. Це дозволяє:
- отримати доступ до персоналізованого робочого простору;
- створювати, редагувати та відстежувати завдання;
- взаємодіяти з іншими учасниками команди.
2. Канбан-дошка. Головний інтерфейс системи складається з кількох
стовпців, що відображають різні етапи виконання завдань (наприклад,
"Заплановано", "У роботі", "Завершено"). Завдання у вигляді карток
перетягуються між стовпцями, забезпечуючи візуальний контроль за прогресом.
3. Завдання. Завдання створюються у формі карток із такими
характеристиками:
- опис – інформація про завдання, що включає цілі та очікувані результати;
- пріоритет – встановлення важливості завдання;
- відповідальний – призначення конкретного учасника для виконання;
- дедлайн – визначення кінцевого терміну.
4. Стовпці та етапи робочого процесу. Система дозволяє гнучко
налаштовувати стовпці Канбан-дошки відповідно до потреб команди, наприклад:
- "Заплановано";
- "У процесі";
- "Готово";
- додаткові етапи (наприклад, "Очікує підтвердження").
5. Комунікація та коментарі. Для покращення взаємодії учасники
можуть залишати коментарі до карток завдань. Це сприяє оперативному обміну
ідеями, постановці уточнюючих питань та вирішенню робочих моментів.
6. Моніторинг прогресу. Система надає засоби для відстеження стану
виконання завдань, включаючи:
- візуальний прогрес завдань через переміщення карток;
- статистику за продуктивністю, тривалістю виконання та іншими
показниками.
7. Налаштування обмежень. Канбан-система підтримує обмеження на
кількість завдань у певних стовпцях. Це допомагає уникати перевантаження та
підвищувати продуктивність команди.
8. Інтеграція з іншими системами. Канбан-дошка може інтегруватися з
іншими сервісами (наприклад, електронною поштою, календарями або засобами
для відстеження часу), що забезпечує більш ефективне управління робочими
процесами.
Схема моделі предметної області включає такі основні елементи:
1. Користувачі:
- адміністратори;
- учасники команди.
2. Завдання та картки:
- ідентифікатори завдань;
- пріоритети, дедлайни;
- відповідальні особи.
3. Стовпці Канбан-дошки:
- етапи процесу;
- гнучкість налаштування.
4. Комунікація:
- коментарі та повідомлення.
5. Аналітика та звіти:
- статистика завдань;
- продуктивність.
Словник предметної області:
- Інструментарій організації робочих процесів із застосуванням
Канбан-дошки – це програмне забезпечення, що дозволяє організувати та
управляти робочими процесами за допомогою Канбан-дошки, надаючи
можливість командного планування, відстеження прогресу завдань та підвищення
ефективності роботи.
- Канбан-дошка – візуальний інструмент, що відображає процес
виконання завдань у вигляді карток, які переміщуються між стовпцями (етапами
робочого процесу). Кожен стовпець відображає окрему фазу (наприклад,
"Заплановано", "У роботі", "Завершено"), надаючи користувачам зручний спосіб
контролю за статусом завдань.
- Картка завдання – елемент Канбан-дошки, що представляє конкретне
завдання. Картка містить інформацію про завдання, таку як назва, опис, дедлайн,
пріоритет та призначений виконавець. Завдання може переміщуватися між
стовпцями відповідно до його статусу.
- Користувач – особа, яка взаємодіє з інструментом організації робочих
процесів. Це може бути член команди, відповідальний за виконання завдань, або
адміністратор, що налаштовує процеси та контролює роботу системи.
- Адміністратор – користувач, що має розширені права доступу до
системи. Він може створювати та редагувати Канбан-дошки, налаштовувати
стовпці та обмеження, а також призначати завдання іншим користувачам.
- Стовпці Канбан-дошки – етапи робочого процесу, що відображаються
на Канбан-дошці. Стовпці можуть бути налаштовані відповідно до потреб
команди і зазвичай включають стадії, як-от "Заплановано", "У процесі" та
"Завершено".
- Завдання – одиниця роботи, яка повинна бути виконана в рамках
процесу. Завдання має чітко визначену мету, призначеного виконавця, дедлайн та
інші характеристики. Завдання створюються, редагуються та виконуються
користувачами системи.
- Пріоритет завдання – характеристика завдання, що визначає його
важливість і вплив на загальний робочий процес. Завдання з вищим пріоритетом
повинні виконуватись першочергово.
- Дедлайн – кінцевий термін, до якого завдання має бути виконане.
Встановлення дедлайнів допомагає контролювати час виконання завдань і
уникати затримок.
- Комунікація – функція, що дозволяє користувачам обмінюватись
коментарями та питаннями в рамках конкретного завдання. Це сприяє
оперативному вирішенню питань і взаємодії між членами команди.
- Обмеження роботи – можливість встановлення максимального числа
завдань, що можуть бути одночасно в одному стовпці Канбан-дошки. Це дозволяє
запобігати перевантаженню команди та підвищує продуктивність.
- Інтеграція – процес поєднання Канбан-дошки з іншими системами чи
сервісами, наприклад, електронною поштою або засобами для відстеження часу,
що покращує ефективність управління робочими процесами.
- Node.js – серверна платформа для виконання JavaScript коду, що
забезпечує високу продуктивність і масштабованість, використовується для
розробки серверної частини інструменту організації робочих процесів.
- Express.js – веб-фреймворк для Node.js, що полегшує створення
серверних застосунків та API, використовується для управління запитами й
обробки даних у системі.
- React – бібліотека для створення інтерфейсів користувача, що
використовується для розробки фронтенд-частини інструменту. React забезпечує
динамічне оновлення інтерфейсу без перезавантаження сторінки, покращуючи
користувацький досвід.
- MongoDB – NoSQL база даних, яка використовується для зберігання
та управління даними, такими як інформація про завдання, користувачів та їх
взаємодії в інструменті.
- Mongoose – бібліотека для Node.js, що дозволяє працювати з
MongoDB, спрощуючи збереження, отримання та модифікацію даних у системі.
- API (Application Programming Interface) – набір інтерфейсів, що
забезпечують взаємодію між різними компонентами інструменту, дозволяючи
обробляти запити користувачів та передавати дані.
2.1.2 Елементи моделювання предметної області
Моделювання предметної області — це важливий етап розробки
програмного забезпечення. Він дає змогу структурувати знання про систему,
визначаючи її ключові компоненти, їхні властивості та зв'язки.
На цьому етапі основна увага приділяється логіці системи та її функціоналу,
ігноруючи технічні деталі реалізації. Це забезпечує надійну основу для
подальшого проєктування архітектури ПЗ.
Головними складовими моделі предметної області є сутності (об'єкти), їхні
характеристики, взаємозв'язки, а також правила та обмеження, що описують
роботу системи (рисунок 2.2).
Рисунок 2.1 – Основні використані позначення UML[5]
1. Користувач (User)
Опис: Представляє індивідуального користувача системи, який може
створювати та брати участь у дошках, картках і списках.
Атрибути:
− ім’я (name);
− прізвище (surname);
− email (email);
− пароль (password);
− аватар (avatar);
− колір користувача (color);
− список дошок (boards) – ідентифікатори пов’язаних дошок.
2. Дошка (Board)
Опис: Основний простір для організації задач, що складається зі списків,
карток, учасників і журналу активностей.
Атрибути:
− назва дошки (title);
− тип фону (isImage);
− посилання на зображення фону (backgroundImageLink);
− опис дошки (description);
− активність (activity) – список дій користувачів на дошці (дії, дата, тип,
назва картки тощо);
− учасники (members) – список користувачів із ролями, email, ім’ям,
кольором тощо;
− списки (lists) – ідентифікатори списків, що належать дошці; дата
створення та оновлення (timestamps).
3. Список (List)
Опис: Підрозділ дошки, який групує картки за певною категорією або
етапом.
Атрибути:
− назва списку (title);
− картки (cards) – ідентифікатори карток, що належать цьому списку;
− власник (owner) – ідентифікатор дошки, якій належить список.
4. Картка (Card)
Опис: Окрема задача або подія в межах списку. Може містити опис,
учасників, мітки, дату дедлайну, вкладення, чеклісти, активності тощо.
Атрибути:
− заголовок (title);
− опис (description);
− мітки (labels) – текст, колір, задній колір, стан вибору;
− учасники (members) – користувачі, прикріплені до картки;
− дата (date) – початок, дедлайн, час дедлайну, нагадування, виконано;
− вкладення (attachments) – список файлів із посиланнями, назвами та
датами;
− активності (activities) – дії користувачів, включаючи коментарі;
− власник (owner) – ідентифікатор списку, якому належить картка;
− обкладинка (cover) – колір, розмір;
− чеклісти (checklists) – назви чеклістів, пункти та статус виконання
кожного з них.
Рисунок 2.2 – Схема бази даних
Взаємозв’язки між об'єктами (рисунок 2.1):
1. Користувач (User) ↔ Дошка (Board)
− користувач може створювати багато дошок;
− у моделі user є масив boards — ідентифікатори дошок, що належать
користувачу;
− крім цього, користувач може бути учасником дошки через масив
members у board.
Взаємозв’язок: 1 користувач → багато дошок (One-to-Many).
2. Дошка (Board) ↔ Список (List)
− кожна дошка має набір списків (поле lists);
− кожен список належить лише одній дошці (поле owner).
Взаємозв’язок: 1 дошка → багато списків (One-to-Many).
3. Список (List) ↔ Картка (Card)
− кожен список може містити багато карток (поле cards);
− кожна картка належить лише одному списку (поле owner).
Взаємозв’язок: 1 список → багато карток (One-to-Many)
4. Користувач (User) ↔ Картка (Card)
− користувач може бути доданий до картки як учасник (members);
− у картці є поле members.user і watchers.user, що вказує на об'єкти user.
Взаємозв’язок: багато користувачів ↔ багато карток (Many-to-Many через
вкладені масиви).
5. Дошка (Board) ↔ Активності (activity)
− активність створюється користувачем у контексті дошки;
− у кожній активності є посилання на користувача (activity.user).
Взаємозв’язок: 1 дошка → багато активностей (з користувачами).
6. Картка (Card) ↔ Активності (activities)
− картка може містити локальні активності або коментарі;
− вони зберігаються у полі activities.
Взаємозв’язок: 1 картка → багато активностей.
7. Картка (Card) ↔ Вкладення / Мітки / Чеклісти / Дати
− всі ці елементи належать до конкретної картки, як вкладені сутності;
− створюють складну структуру даних, пов’язану з життєвим циклом
задачі.
Взаємозв’язок: 1 картка → багато вкладених сутностей.
2.1.3 Робоча область моделювання
Робоча область моделювання для інструментарію організації робочих
процесів із застосуванням Канбан-дошки охоплює всі аспекти проектування та
функціонування системи для покращення управління завданнями та оптимізації
командної роботи. Основна мета розробки цього інструментарію — забезпечити
ефективне візуальне управління робочими процесами шляхом використання
Канбан-дошки, яка дозволяє планувати, відслідковувати та контролювати
виконання завдань у реальному часі. Робоча область моделювання визначає всі
компоненти системи, їх взаємодію, а також основні функції, які необхідні для
досягнення прозорості та підвищення ефективності робочих процесів.
2.2 Формування та аналіз вимог
У цьому розділі описані вимоги, які необхідно визначити для розробки
програмного забезпечення, а також діаграми випадків використання для
візуалізації цих вимог.
Визначено основні та детальні вимоги. Основні вимоги включають загальні
цілі та функції, які програмне забезпечення повинно виконувати. Прості вимоги
до налаштування та інтеграції, інтуїтивно зрозумілий інтерфейс, масштабованість
та відповідний рівень безпеки.
Ми також розглянемо функціональні та нефункціональні вимоги.
Функціональні вимоги визначають конкретні функції, які повинна надавати
програмна система. Нефункціональні вимоги визначають характеристики
системи, такі як продуктивність, надійність, безпека та простота використання.
Щоб візуалізувати ці вимоги, можна використовувати діаграми
прецендентів використання, щоб допомогти проілюструвати взаємодію
користувача з системою за допомогою різних випадків використання. Це дозволяє
чітко визначити системні вимоги і зрозуміти, як різні частини програмного
забезпечення взаємодіють один з одним. Ми можемо використовувати як текстові
описи, так і візуалізацію, використовуючи діаграми прецендентів використання,
щоб краще зрозуміти всі аспекти формування вимог до програмного
забезпечення.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення.
Формування вимог до інструментарію організації робочих процесів із
застосуванням Канбан-дошки є важливим етапом, який визначає всі необхідні
функції та характеристики системи для забезпечення ефективного управління
завданнями, прозорого моніторингу та поліпшення командної взаємодії. Цей
процес включає первинне визначення основних можливостей системи, а також
деталізацію кожної функції для їх практичної реалізації.
Первинні і детальні вимоги.
Первинні вимоги описують загальні можливості інструментарію:
- авторизація користувачів: забезпечення входу для різних ролей (менеджери,
члени команди) з доступом до відповідних функцій;
- канбан-дошка: візуалізація завдань у вигляді карток, що переміщуються між
стовпцями, які відображають різні етапи виконання завдань;
- створення та управління завданнями: можливість створювати нові завдання
з детальною інформацією, встановлювати пріоритети та призначати
відповідальних;
- комунікація: коментарі та обговорення завдань безпосередньо в картках для
покращення взаємодії між членами команди;
- моніторинг продуктивності: збір статистики для аналізу часу виконання
завдань і ефективності команди;
- інтеграція: підключення до інших сервісів, таких як календарі чи
месенджери, для поліпшення організації роботи. Детальні вимоги – це
деталізовані вимоги до системи, які включають в себе більш точну
інформацію про функціонал системи.
Детальні вимоги уточнюють первинні та забезпечують конкретні
інструкції для розробки:
1. Авторизація користувачів:
- сторінка входу повинна мати поля для введення логіна і пароля;
- для різних ролей (менеджери, учасники команди) доступні функції
повинні відповідати рівню прав доступу;
- у разі неправильного введення даних користувачу має відображатися
зрозуміле повідомлення про помилку.
2. Канбан-дошка:
- головний інтерфейс складається зі стовпців, що відображають етапи
виконання завдань, таких як "Заплановано", "У процесі", "Завершено" ;
- можливість налаштування стовпців відповідно до потреб команди
(наприклад, "Очікує перевірки");
- інтерактивне переміщення карток завдань між стовпцями.
3. Завдання:
- кожне завдання має такі параметри: опис, пріоритет, відповідальний,
дедлайн;
- можливість встановлення дедлайну для кожного завдання;
- функціонал для редагування завдань та відстеження змін.
4. Комунікація та коментарі:
- доступність текстових полів для коментарів до завдань;
- сповіщення користувачів про нові коментарі та відповіді на них.
5. Моніторинг продуктивності:
- відображення статистики, пов’язаної із завданнями (час виконання, статус,
прогрес);
- інтерактивні звіти для аналізу ефективності роботи команди.
6. Інтеграція:
- система повинна мати можливість інтеграції з календарями для
планування зустрічей;
- підтримка інтеграції з месенджерами або іншими сервісами для
покращення комунікації.
Описані вимоги є основою для подальшої розробки системи, її тестування
та впровадження, забезпечуючи ефективне управління робочими процесами та
зручний користувацький інтерфейс для роботи з Канбан-дошкою.
Вимоги замовника і розробника.
Вимоги замовника формуються на основі потреб кінцевих користувачів –
менеджерів проектів, членів команд та інших учасників, що взаємодіють із
системою Канбан-дошки. Вони визначають основні функції, зручність і
ефективність роботи, що забезпечують оптимізацію процесів:
- інтерфейс системи повинен бути простим і інтуїтивно зрозумілим для
користувачів усіх рівнів;
- система має забезпечувати зручне створення та переміщення завдань по
Канбан-дошці;
- завдання мають відображати ключову інформацію (опис, статус,
відповідального, термін виконання) і бути доступними для редагування;
- необхідна можливість комунікації та обговорення в межах кожної задачі;
- система повинна підтримувати інтеграцію з іншими інструментами для
спрощення робочих процесів і аналітики.
Вимоги розробника відображають технічні аспекти реалізації Канбан-
дошки, враховуючи вибрані технології та архітектуру:
- інтерфейс має відповідати сучасним стандартам веб-дизайну та бути
адаптованим для мобільних пристроїв;
- система повинна бути побудована з використанням технологій, що
забезпечують високу продуктивність та масштабованість;
- дані користувачів і завдань мають зберігатися в захищеній базі даних з
можливістю регулярного резервного копіювання;
- інтеграція з календарями, месенджерами та іншими сервісами повинна
здійснюватися за допомогою API для зручного обміну даними.
Функціональні та нефункціональні вимоги.
Функціональні вимоги описують конкретні дії, які спроектована програмна
система повинна виконувати:
- авторизація користувачів: вхід у систему для менеджерів та членів команд
через логін і пароль;
- канбан-дошка: створення стовпців та управління завданнями (додавання,
редагування, переміщення між етапами);
- завдання: можливість створення карток із описом, статусом,
відповідальним, дедлайном і пріоритетом;
- коментарі до завдань: обмін повідомленнями між користувачами в межах
кожної картки;
- інтеграція: підтримка підключення календарів та інших робочих
інструментів для синхронізації даних;
- моніторинг і аналітика: перегляд статистики завдань, продуктивності
команди та інших ключових показників.
Нефункціональні вимоги
Нефункціональні вимоги визначають характеристики системи, які
забезпечують її якісну роботу:
- продуктивність: система повинна обробляти запити на додавання чи
переміщення завдань за 1-2 секунди;
- безпека: персональні дані користувачів повинні бути зашифровані, а
доступ – захищений;
- зручність використання: інтерфейс повинен бути зрозумілим навіть для
недосвідчених користувачів;
- надійність: система має працювати стабільно навіть під великим
навантаженням;
- масштабованість: підтримка зростання кількості завдань і користувачів без
зниження продуктивності.
Чітко визначені вимоги є важливими для досягнення ефективної взаємодії
між командою розробників і замовниками, а також для забезпечення відповідності
кінцевого продукту його цільовому призначенню.
2.2.2 Формування вимог за діаграмою прецедентів
Опис Прецедентів.
Основні прецеденти, що відображають функціональні можливості
мобільного додатку, можуть бути такими (рисунок 2.3):
1. Прецедент «Зареєструватись у системі»:
- призначення: реєстрація облікового запису користувача у системі;
- основний потік подій: на екрані реєстрації користувач вводить необхідні
дані для створення акаунту, і натискає кнопку «Sign Up». При успішній
реєстрації виконується зберігання даних користувача до MongoDB;
- альтернативний потік подій: якщо користувач вже зареєстрований, система
відобразить відповідне повідомлення;
- виняткова ситуація 1: введено неправильні дані – система відобразить
відповідне повідомлення.
2. Прецедент «Увійти в обліковий запис»:
- призначення: вхід користувачем в обліковий запис системи;
- основний потік подій: користувач вводить дані облікового запису даний
варіант використання починає виконуватися, коли користувач натискає
кнопку на сторінці входу. При успішному вході в акаунт користувача буде
перенаправлено на головну сторінку системи з дошками;
- альтернативний потік подій: якщо користувач не зареєстрований, система
відобразить відповідне повідомлення;
- передумова: користувач має бути зареєстрований у системі;
- виняткова ситуація 1: введено неправильні дані – система відобразить
відповідне повідомлення.
3. Прецедент «Вийти з облікового запису»:
- призначення: вихід користувачем із облікового запису системи;
- основний потік подій: користувач натискає на іконку свого користувача в
правому верхньому куту сторінки, після чого з’являється меню з кнопкою
«Вийти». При успішному виконанні операції, користувача буде виведено з
акаунту системи;
- передумова: користувач повинен увійти до системи.
4. Прецедент «Керувати робочими дошками»:
- призначення: керування користувачем робочими дошками;
- основний потік подій: користувач знаходиться на головному екрані системи,
на якому він має доступ до створення робочих дошок. Обравши робочу
дошку, користувач може переглянути його вміст. Для створення робочої
дошки використовується кнопка «Нова дошка» посередині сторінки. Для
редагування робочої дошки, потрібно увійти на її сторінку, а потім в
правому верхньому кутку натиснути кнопку «Показати меню». Після її
натискання відкриється бокове меню, в якому користувач може побачити
історію дошки, а також змінити її опис або задній фон.
- альтернативний потік подій: якщо не створено жодного робочої дошки,
система відобразить відповідне повідомлення;
- передумова: користувач повинен увійти до системи.
5. Прецедент «Керувати списками задач»:
- призначення: керування користувачем списками задач на Kanban-дошках;
- основний потік подій: користувач знаходиться на сторінці обраної Kanban-
дошки, на якому він може створювати, переміщати та редагувати списки
задач. Для створення списку задач використовується кнопка «Додати
список», яка завжди знаходиться в кінці всіх списків. Для зміни назви
списку, потрібно клацнути на назву. А для видалення, потрібно натиснути
кнопку з трьома крапка в правому верхньому кутку списку.
- передумова: користувач знаходиться на екрані Kanban-дошки.
Рисунок 2.3 – Діаграма прецендентів
6. Прецедент «Керувати картками з задачами»:
- призначення: керування картками з задачами на Kanban-дошках;
- основний потік подій: користувач знаходиться на екрані обраної Kanban-
дошки. Створення карток відбувається шляхом натискання кнопки «+
картка» внизу списку карток. Потрібно лише ввести заголовок картки в
полі, яке з’явиться після натискання кнопки. При натисканні на картку
відбувається відкривається модальне вікно з інформацією про картку, в
якому користувач може переглянути всі відомості задачі. Також в цьому
модальному вікні, він може видалити картку, додати. користувача, додати
ярлик, додати контрольні списки, змінити колір оформлення, додати
коментарі, змінити опис чи заголовокб подивитися історію цієї картки.
Переміщення задач відбувається шляхом затискання лівої кнопки маші на
картці у списку та перетягування її на нову позицію у поточному або
новому списку.
- передумова: користувач знаходиться на екрані Kanban-дошки із
щонайменше одним списком задач на ній.
2.3 Проектування логічної структури
У цьому підрозділі буде детально розглянуто проектування логічної
структури інструменту для організації робочих процесів за допомогою Канбан-
дошки. Спочатку ми надамо діаграми класів, які відображатимуть взаємодію між
основними компонентами системи, їх атрибути та методи. Це допоможе краще
зрозуміти логіку роботи інструменту та структуру його елементів. Кожен клас
буде відповідати за функціональність окремих частин системи, таких як завдання,
етапи процесу, користувачі, статистика, історія змін та налаштування. Далі ми
зобразимо взаємозв'язки між класами, що визначатимуть, як різні компоненти
взаємодіють між собою та сприяють ефективному управлінню робочими
процесами.
Така структура дозволить створити чітке уявлення про поведінку об'єктів у
системі, а також спростить розробку та подальшу інтеграцію нових
функціональностей.
У цій роботі ми розробляємо логічну структуру програмного пакету,
використовуючи діаграму класів та діаграму пакетів для візуалізації структури та
компонентів системи.
По-перше, створено діаграму класів програмного забезпечення. Ця діаграма
допомагає візуалізувати структуру системи, показуючи класи, їх атрибути, методи
і відносини між ними. Потім створено діаграму пакетів, яка допомогла
організувати свої класи в логічні групи або пакети. Це полегшує управління
великими проектами та покращує чіткість структури коду.
2.3.1 Діаграми класів
Опис кожної таблиці бази даних, представленої в діаграмі класів (рисунок
2.4):
1. Клас User (Користувач)
Опис: Відповідає за збереження та управління інформацією про
користувачів системи. Містить дані, необхідні для ідентифікації, авторизації та
персоналізації інтерфейсу користувача. Також зберігає зв'язок із дошками, до
яких має доступ користувач.
Поля:
− _id: ObjectId – Унікальний ідентифікатор, який автоматично генерується
MongoDB;
− name: string – Ім’я користувача (обов’язкове);
− surname: string – Прізвище користувача (обов’язкове);
− email: string – Унікальна електронна пошта користувача, яка
використовується для авторизації (обов’язкова);
− password: string – Хешований пароль користувача (обов’язковий);
− color: string – Колір, пов’язаний із користувачем (колір іконки користувача,
задається автоматично);
− boards: ObjectId[] – Масив посилань на об'єкти моделі Board, які
представляють дошки, у яких користувач бере участь.
2. Клас Board (Дошка)
Опис: Модель представляє дошку проєкту, яка містить списки, картки,
учасників та історію дій. Відповідає за структуру робочого простору .
Поля:
− _id: ObjectId – Унікальний ідентифікатор дошки.
− title: string – Назва дошки (обов’язкове).
− isImage: boolean – Прапорець, що вказує, чи використовується зображення
як фон (за замовчуванням true).
− backgroundImageLink: string – Посилання на фонове зображення
(обов’язкове).
− activity: Array<Object> – Історія дій на дошці. Кожна дія включає:
- user: ObjectId – Посилання на користувача, який виконав дію.
- name: string – Ім’я користувача.
- action: string – Опис дії (наприклад, "створив картку").
- date: Date – Дата дії (за замовчуванням поточна).
- edited: boolean – Чи редагувалася дія (за замовчуванням false).
- cardTitle: string – Назва картки, до якої стосується дія.
- actionType: string – Тип дії (за замовчуванням 'action').
- color: string – Колір, пов’язаний із користувачем у дії.
− members: Array<Object> – Список учасників дошки. Кожен учасник має:
- user: ObjectId – Посилання на користувача.
- name: string – Ім’я.
- surname: string – Прізвище.
- email: string – Електронна пошта.
- role: string – Роль користувача (owner або member, за
замовчуванням 'member').
- color: string – Колір користувача (для візуального
представлення).
− lists: ObjectId[] – Масив посилань на об’єкти моделі List, які представляють
стовпці Канбан-дошки.
− description: string – Опис дошки (за замовчуванням порожній рядок).
− createdAt / updatedAt: Date – Дата створення та останнього оновлення дошки
(генерується автоматично)
3. Клас List (Стовпець)
Опис: Модель представляє список завдань на Канбан-дошці, що складається
з карток. Кожен список має заголовок, масив карток та посилання на дошку, до
якої він належить.
Поля:
- id: string – Унікальний ідентифікатор Канбан-дошки;
- name: string – Назва дошки;
- columns: Column[] – Массив стовпців, які містять завдання.
Методи: addColumn() removeColumn() moveTaskBetweenColumns().
4. Клас Column (Стовпець Канбан-дошки)
Опис: Відображає різні етапи робочого процесу на Канбан-дошці.
Поля:
- id: string – Унікальний ідентифікатор стовпця;
- name: string – Назва стовпця;
- tasks: Task[] – Массив завдань у стовпці.
Методи: addTask() removeTask() editColumn().
5. Клас Comment (Коментар)
Опис: Відповідає за комунікацію між користувачами у межах завдання.
Поля:
- id: string – Унікальний ідентифікатор коментаря;
- taskId: string – Ідентифікатор завдання, до якого належить коментар;
- userId: string – Ідентифікатор користувача, який залишив коментар;
- content: string – Текст коментаря;
- createdAt: Date – Дата створення коментаря.
Методи: addComment() editComment() deleteComment().
6. Клас Analytics (Аналітика)
Опис: Надає засоби для відстеження прогресу та продуктивності.
Поля:
- boardId: string – Ідентифікатор дошки, для якої проводиться аналіз;
- statistics: object – Об’єкт зі статистичними даними.
Методи: generateReport() analyzePerformance().
Рисунок 2.4 – Діаграма класів web-застосунку
2.3.2 Діаграми пакетів
Рисунок 2.5 – Діаграма пакетів
Детальний опис діаграми пакетів:
1. Client - містить інтерфейс користувача, розроблений з використанням
ReactJS:
- UI components — це багаторазові візуальні елементи (наприклад,
кнопки, інпути, модалки);
- Pages — сторінки додатку, які збирають компоненти у повноцінні
екрани для взаємодії користувача з системою.
Клієнт надсилає HTTP-запити до сервера (через REST API або WebSockets),
взаємодіючи з бекендом.
2. Server - реалізований з використанням Node.js/Express, виконує
логіку застосунку:
- controllers — обробляють вхідні запити від клієнта;
- services — містять бізнес-логіку, яка викликається з контролерів;
- middlewares — обробники проміжної логіки, як-от авторизація;
- routes — опис маршрутів API та пов’язування їх з контролерами.
Сервер приймає запити від клієнта та звертається до бази даних MongoDB.
3. MongoDB - використовується як основна NoSQL база даних:
- documents — основні одиниці зберігання даних у BSON-форматі;
- collections — набори документів (аналог таблиць у реляційній БД);
- references — посилання між документами для реалізації зв’язків
(наприклад, userId у документі Card).
MongoDB взаємодіє з сервером, отримуючи або повертаючи дані через
драйвер або ORM (наприклад, Mongoose).
Взаємодія між пакетами:
1. Client → Server: запити на отримання/створення/редагування ресурсів.
2. Server ↔ MongoDB: збереження, оновлення та читання даних.
3. MongoDB → Server → Client: результати передаються назад
користувачу.
2.4 Архітектурне проектування
2.4.1 Діаграма компонентів
Рисунок 2.6 – Діаграма компонентів
Основні компоненти:
1. Клієнтський застосунок (Client):
− Опис: Компонент, що забезпечує взаємодію з користувачем у
середовищі веббраузера. Його функції включають показ інформації,
зчитування даних, введених користувачем, надсилання запитів до
серверної частини та виведення отриманих відповідей.
− Підкомпоненти: Сторінка аутентифікації, сторінка дошок, сторінка
дошки зі стовпцями та картками.
2. Backend (Server):
− Опис: Обробляє запити клієнта, реалізує основну логіку роботи
додатку та відповідає за взаємодію з базою даних.
− Підкомпоненти: Логічні модулі, контролери для обробки маршрутів,
сервіси для виконання внутрішніх операцій.
3. База даних (Database – MongoDB):
− Опис: Відповідає за збереження даних у форматі документів.
Забезпечує гнучке зберігання вкладених структур, що ідеально
підходить для динамічних вебдодатків.
− Підкомпоненти: Колекції: users (користувачі), boards (дошки), lists
(списки), cards (картки завдань). Кожна колекція містить документи з
гнучкою структурою, що відповідає своїй сутності.
Зв'язки між компонентами:
− клієнтський додаток ↔ серверна частина (Backend): клієнт надсилає HTTP-
запити (GET, POST, PUT, DELETE) до сервера для обробки даних, а сервер
повертає відповідь із результатами;
− серверна частина ↔ база даних (MongoDB): сервер виконує запити до бази
даних для збереження, оновлення, видалення або отримання потрібної
інформації;
− клієнтський додаток ↔ база даних (непрямо): клієнт отримує або змінює
дані у базі через сервер, не маючи прямого доступу до бази.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Рисунок 2.6 – Діаграма розгортання
Опис розгортання програмної системи на апаратних засобах:
1. Клієнт:
- призначення: забезпечення взаємодії користувача із системою через
веб-додаток. Відповідає за візуалізацію даних та обробку дій користувача;
- програмне забезпечення: Бібліотека React.js.
2. Back-end:
- програмне забезпечення: Node.js та ExpressJs для обробки запитів,
виконання бізнес-логіки та надсилання відповідей;
- API: інтерфейс, що забезпечує обробку запитів від клієнта відправку
відповідей.
3. База даних:
- зберігання даних: база даних (наприклад, MongoDB) для зберігання
інформації про користувачів, дошки, стовпці та картки.
Діаграма розгортання може включати такі вузли та зв’язки між ними:
- клієнт, що взаємодіє з сервером, на який надсилає запити для
збереження, видалення або редагування даних;
- сервер (Backend): має зв'язок з базою даних для зберігання та
отримання даних.
- взаємодіє з клієнтом.
2.5 Моделювання поведінки системи
2.5.1 Діаграма діяльності
Рисунок 2.7 – Діаграма діяльності
Рисунок 2.8 – Діаграма діяльності в UML
Опис діаграми діяльності:
1. Початок роботи з веб-застосунком:
− «Старт»: користувач ініціює роботу з веб-застосунком;
− «Сторінка завантажена»: веб-сторінка застосунку відображається
користувачеві;
− «У користувача є аккаунт?»: система перевіряє, чи має користувач
обліковий запис.;
− «Так»: користувач перенаправляється на етап Вхід, де вводить свої
облікові дані;
− «Ні»: користувач перенаправляється на етап Реєстрація, де створює
новий обліковий запис;
− після успішного входу або реєстрації користувач потрапляє на
«Домашню сторінку».
2. Робота з дошкою:
− «Що користувач збирається зробити?»: користувачеві надається вибір
дій, пов'язаних з дошкою;
− «Створити нову дошку»: користувач ініціює процес створення нової
дошки;
− «Відкрити існуючу дошку»: користувач обирає одну зі своїх існуючих
дошок;
− після створення або відкриття дошки користувач переходить до етапу
Редагування дошки.
3. Робота зі стовпчиком:
− «Що користувач збирається зробити?»: користувачеві надається вибір
дій всередині відкритої дошки, пов'язаних зі стовпчиками;
− «Використати існуючий стовпчик»: користувач обирає один з наявних
стовпчиків на дошці;
− «Створити новий стовпчик»: користувач ініціює процес створення
нового стовпчика на дошці;
− «Видалити стовпчик»: користувач обирає стовпчик для видалення;
− після вибору, створення або видалення стовпчика (якщо це
передбачає подальші дії), користувач переходить до етапу
Редагування стовпчика.
4. Робота з карткою:
− «Що користувач збирається зробити?»: користувачеві надається вибір
дій всередині стовпчика, пов'язаних з картками;
− «Відкрити існуючу картку»: користувач обирає одну з наявних карток
у стовпчику;
− «Створити нову картку»: користувач ініціює процес створення нової
картки у стовпчику;
− «Видалити картку»: користувач обирає картку для видалення зі
стовпчика;
− після вибору, створення або видалення картки (якщо це передбачає
подальші дії), користувач переходить до етапу Редагування картки.
5. Завершення роботи:
− «Кінець»: користувач завершує свою роботу з веб-застосунком
(явного кроку "Вихід" на діаграмі немає, але це є логічним
завершенням сесії).
2.5.2 Діаграма послідовності
Основні етапі для діаграми послідовності (рисунок 2.9):
1. Авторизація користувача
- запуск клієнтського додатку — користувач відкриває веб-інтерфейс;
- введення облікових даних — користувач вводить email та пароль;
- відправка запиту на сервер — фронтенд відправляє POST-запит з
обліковими даними;
- перевірка у базі даних — сервер шукає відповідного користувача в
колекції users, перевіряє пароль;
- надсилання токена — у випадку успішної авторизації сервер надсилає
токен сесії (JWT);
- отримання доступу до інтерфейсу — клієнт отримує доступ до дошок
(boards) користувача.
Рисунок 2.9 – Діаграма послідовності
2. Створення дошки:
- користувач натискає "Створити дошку" — у клієнті запускається форма;
- введення назви та фону — користувач заповнює поля, обирає фон;
- надсилання POST-запиту — дані передаються на сервер;
- створення нового об'єкта Board у MongoDB — сервер додає запис до
колекції boards;
- оновлення поля boards у моделі User — ID нової дошки додається до
списку користувача;
- відображення створеної дошки — клієнт отримує відповідь і оновлює
інтерфейс.
3. Додавання картки до списку:
- користувач обирає список на дошці — інтерфейс дозволяє додати нову
картку;
- введення назви картки — користувач створює коротке завдання;
- відправка POST-запиту на сервер — дані нової картки передаються у
backend;
- створення Card у MongoDB — сервер додає документ у колекцію cards з
посиланням на список (List);
- оновлення списку (List) — ID нової картки додається до поля cards
відповідного списку;
- повернення оновлених даних клієнту — нова картка з’являється у
відповідному списку.
4. Редагування картки:
- користувач відкриває картку — відображається детальна інформація;
- внесення змін — редагуються поля (опис, учасники, чекліст, мітки тощо);
- натискання "Зберегти" — надсилається PATCH/PUT-запит на сервер;
- оновлення картки в базі — сервер оновлює документ у колекції cards;
- відображення змін — клієнт оновлює інтерфейс відповідно до відповіді.
5. Видалення картки:
- користувач натискає "Видалити" — система запитує підтвердження;
- підтвердження дії — користувач погоджується;
- відправка DELETE-запиту на сервер — картка позначається до видалення;
- видалення документа з колекції cards — сервер видаляє відповідний
документ;
- всновлення списку (List) — ID картки видаляється з поля cards;
- оновлення інтерфейсу — картка зникає з відображення у клієнта.
6. Вихід із системи:
- користувач натискає "Вийти" — виконується клієнтська дія;
- видалення токена з локального сховища — токен стирається з браузера;
- редірект на сторінку логіну — користувач повертається до авторизації.
2.5.3 Діаграма комунікації
Оновлений опис етапів взаємодії (рисунок 2.10):
1. Авторизація користувача:
Мета: Перевірити права доступу до системи. Ключові кроки:
- користувач вводить логін і пароль;
- інтерфейс передає ці дані до UserController;
- UserController перевіряє дані у базі (users);
- повертається токен авторизації та відкривається інтерфейс.
2. Створення дошки:
Мета: Додати нову дошку. Ключові кроки:
- користувач вводить назву дошки;
- інтерфейс надсилає запит до BoardController;
- BoardController створює новий запис у колекції boards;
- інтерфейс оновлюється.
3. Створення стовпця (List)
Мета: Додати новий список (стовпець) до дошки. Ключові кроки:
- користувач додає назву стовпця;
- інтерфейс надсилає запит до ListController;
- ListController створює list і прив’язує до board;
- інтерфейс відображає новий стовпець.
Рисунок 2.10 – Діаграма комунікації
4. Створення картки:
Мета: Додати картку до списку на дошці. Ключові кроки:
- користувач заповнює дані картки;
- інтерфейс передає їх до CardController;
- CardController створює картку та додає її до обраного list;
- інтерфейс оновлює відображення.
5. Редагування картки:
Мета: Оновити дані картки. Ключові кроки:
- користувач редагує картку;
- інтерфейс надсилає зміни до CardController;
- CardController оновлює картку в базі (cards);
- інтерфейс показує оновлену версію.
6. Видалення картки:
Мета: Видалити картку зі списку. Ключові кроки:
- користувач натискає кнопку видалення;
- інтерфейс надсилає запит до CardController;
- CardController видаляє картку з cards та прибирає з масиву карток у
list;
- інтерфейс оновлюється.
2.5.4 Діаграма скінченного автомату
Зробимо опис основних компонентів діаграми скінченого автомату.
Основні компоненти:
1. Користувач – взаємодіє з системою: авторизується, створює дошки,
списки (стовпці), картки, редагує чи видаляє їх.
2. Інтерфейс – клієнтська частина, через яку користувач виконує дії.
3. Контролери (UserController, BoardController, ListController,
CardController) – обробляють запити, виконують бізнес-логіку.
4. База даних – зберігає користувачів, дошки, списки та картки.
Рисунок 2.11 – Діаграма скінченного автомату
Основні сценарії переходів у діаграмі:
1. Авторизація користувача:
- процес: Користувач вводить логін/пароль;
- переходи:
- [*] → Авторизація;
- Авторизація → Головна сторінка : якщо вхід успішний;
- Авторизація → [*] : якщо вхід неуспішний.
2. Створення нової дошки:
- процес: користувач натискає "Створити дошку", вводить назву;
- переходи:
- Головна сторінка → Створення дошки;
- Створення дошки → Перегляд дошки;
3. Створення списку (List):
- процес: користувач на дошці створює новий список;
- переходи:
- Перегляд дошки → Створення списку;
- Створення списку → Перегляд дошки.
4. Створення картки:
- процес: користувач у списку створює картку;
- переходи:
- Перегляд дошки → Створення картки;
- Створення картки → Перегляд дошки.
5. Редагування картки:
- процес: користувач натискає на картку та змінює її дані;
- переходи:
- Перегляд дошки → Редагування картки;
- Редагування картки → Перегляд дошки.
6. Видалення картки:
- процес: користувач натискає "Видалити картку";
- переходи:
- Перегляд дошки → Видалення картки;
- Видалення картки → Перегляд дошки.
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі було здійснено моделювання основних процесів і
структури програмного забезпечення, яке реалізує систему керування завданнями
за допомогою Канбан-дошок. В межах розділу виконано аналіз предметної
області, що дало змогу чітко визначити ключові об’єкти системи – користувач,
дошка, список (стовпець) і картка – та описати їх взаємозв’язки.
Розроблено словник термінів, що забезпечує однозначне тлумачення
функціональних елементів системи. На основі цього сформульовано вимоги до
програмного забезпечення, серед яких виділено як функціональні (створення та
редагування дошок, списків, карток, авторизація користувачів), так і
нефункціональні (зручність інтерфейсу, швидкодія, масштабованість).
Для візуалізації логіки взаємодії користувача із системою створено діаграму
прецедентів. Проєктування об'єктної моделі реалізовано за допомогою діаграми
класів, що дало змогу структурувати основні сутності та їх характеристики.
Результатом детального моделювання інформаційної системи стало
створення комплексного пакету UML-діаграм, який відображає як функціональні,
так і структурні, динамічні та поведінкові аспекти системи.
Моделювання дозволило глибоко проаналізувати предметну область,
структуру даних, логіку взаємодії між компонентами та життєвий цикл об'єктів.
Було побудовано дев’ять типів UML-діаграм, кожна з яких відіграла унікальну
роль у відображенні системи з різних точок зору:
− діаграма прецедентів (Use Case Diagram) Ця діаграма дозволила
визначити основні дії, які можуть виконувати користувачі системи (реєстрація,
авторизація, створення дошки, створення та редагування карток тощо), а також
описати взаємозв’язки між актором і функціональністю системи. Вона слугувала
відправною точкою для подальшого детального аналізу вимог;
− діаграма класів (Class Diagram) Представила основні сутності
предметної області, їхні атрибути, методи, а також зв’язки між ними. Зокрема,
описано класи таких об'єктів, як Користувач, Дошка, Картка, Колонка, Тег тощо.
Діаграма дозволила визначити логічну структуру системи та її об'єктну модель ;
− діаграма пакетів (Package Diagram) Була використана для
структурування проєкту на логічні модулі. Завдяки ній стало можливим візуально
розділити функціональність на окремі підсистеми (автентифікація, керування
картками, робота з дошками, інтерфейс тощо), що сприяє зручному
масштабуванню та підтримці коду;
− діаграма компонентів (Component Diagram) Відобразила
архітектурну структуру системи на рівні програмних компонентів: фронтенд,
бекенд, база даних, API тощо. Це дало змогу зрозуміти, як реалізуються окремі
частини системи та яким чином вони взаємодіють через інтерфейси;
− діаграма розгортання (Deployment Diagram) Показала фізичну
інфраструктуру розгортання системи: сервер додатків, база даних, веб-клієнт
тощо. Завдяки цій діаграмі стало можливим оцінити ресурси, необхідні для
хостингу системи, а також передбачити точки потенційного навантаження;
− діаграма діяльності (Activity Diagram) Продемонструвала логіку
виконання процесів у системі — таких як авторизація, створення дошки,
створення та редагування картки. Вона чітко ілюструє алгоритм роботи з
урахуванням можливих гілок, умов і циклів, що дозволяє ефективно розробляти
бізнес-логіку;
− діаграма послідовності (Sequence Diagram) Відобразила взаємодію
між об’єктами в часі, наприклад, під час процесів створення картки або
переміщення її між колонками. Вона дозволила зрозуміти часову послідовність
викликів методів між клієнтом, сервером і базою даних;
− діаграма комунікації (Communication Diagram) Показала структуру
повідомлень і взаємозв’язків між об’єктами під час виконання функцій. На
відміну від послідовності, вона більше фокусувалася на каналах взаємодії, що дає
розуміння архітектури з погляду комунікаційної топології;
− діаграма скінченого автомату (State Machine Diagram) Була
використана для моделювання зміни станів об’єктів системи, зокрема картки.
Діаграма показала переходи між станами «створено», «у роботі», «завершено»,
«видалено», а також події, які ці переходи ініціюють. Це стало підґрунтям для
побудови логіки обробки змін.
Загалом, моделювання в UML дозволило досягти таких результатів:
− формалізувати структуру та функціонування системи на різних рівнях
абстракції;
− виявити ключові об'єкти, їх атрибути, методи та зв’язки;
− спроєктувати поведінкову логіку компонентів системи;
− візуалізувати архітектуру, інфраструктуру та залежності між
модулями;
− забезпечити основу для командної роботи та подальшого
програмування.
Ретельне опрацювання кожної діаграми сприяє зниженню ризику помилок у
майбутній реалізації, полегшує комунікацію між учасниками проєкту
(розробниками, дизайнерами, тестувальниками) та створює ґрунт для
масштабування системи. UML-моделі, створені на цьому етапі, також
відіграватимуть ключову роль у тестуванні, документації та підтримці готового
програмного продукту.
Таким чином, другий розділ закладає системну, логічну та структуровану
основу для розробки програмної системи управління завданнями в стилі Kanban.
Побудовані діаграми є необхідним інструментом у забезпеченні якісної розробки,
яка відповідає вимогам сучасної інженерії програмного забезпечення.
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
У цьому підрозділі описується процес створення програмного комплексу
для організації роботи з використанням Kanban-дошки. Особливу увагу приділено
як архітектурі системи, так і вибору технологій, структурі застосунку, а також
організації взаємодії між клієнтською, серверною частинами та базою даних.
Застосунок створено з урахуванням вимог до масштабованості, зручності
використання, безпеки й продуктивності.
Розробка відбувалася поетапно, що дало змогу уникнути надмірної
складності на старті й поступово розширювати функціональність. На першому
етапі було визначено загальну концепцію, цільову аудиторію та ключові функції,
які повинна реалізовувати система. Було сформовано технічне завдання,
визначено основні модулі та продумано логіку взаємодії між ними. Далі —
вибрано технологічний стек, спроєктовано базу даних і структуру інтерфейсу,
після чого почалася безпосередня розробка компонентів системи.
Основна ідея застосунку — надати користувачам простий і водночас
функціональний інструмент для візуального управління завданнями. Kanban-
підхід дозволяє бачити всі етапи роботи, легко переміщати задачі між колонками
відповідно до їхнього стану ("Заплановано", "У процесі", "Виконано" тощо), що
підвищує прозорість і контроль над процесом.
Кожна складова системи розроблялася з урахуванням принципів
модульності, повторного використання коду, розширюваності та зручності
тестування. Важливу роль відіграє також дотримання сучасних стандартів веб-
розробки, що забезпечує надійність і зручність застосунку для кінцевого
користувача.
Загальна архітектура базується на клієнт-серверній моделі: інтерфейс
користувача функціонує як SPA (Single Page Application), що динамічно взаємодіє
із сервером через HTTP-запити. Серверна частина виконує роль логічного ядра
системи, обробляючи запити, керуючи базою даних, перевіряючи права доступу
та забезпечуючи бізнес-логіку. У свою чергу, база даних відповідає за зберігання
користувацької інформації, структурованої за допомогою взаємопов’язаних
документів.
Також у процесі розробки особливу увагу приділено безпеці: реалізовано
автентифікацію за допомогою JWT, захист маршрутів, валідацію вхідних даних на
клієнтському та серверному рівнях. Це дозволяє запобігти потенційним загрозам і
несанкціонованому доступу до важливої інформації.
Таким чином, розробка програмного комплексу включала комплексну
роботу над усіма рівнями системи: від формування загальної ідеї й технічного
проєктування — до реалізації, тестування й підготовки до розгортання..
3.1.1 Обґрунтування вибору засобів реалізації
У процесі розробки веб-застосунку важливо обрати технології, які
забезпечують гнучкість, продуктивність, зручність підтримки та швидкість
розробки. Для досягнення цих цілей було обрано сучасний стек технологій, що
добре себе зарекомендував у створенні масштабованих SPA (Single Page
Applications).
Клієнтська частина реалізована з використанням ReactJS — бібліотеки, яка
дозволяє ефективно створювати інтерфейси з реактивною логікою та повторно
використовуваними компонентами. Завдяки її віртуальному DOM та
односпрямованому потоку даних вдалося забезпечити високу швидкодію та
зручність масштабування застосунку. Для стилізації компонентів було обрано
Styled-Components, що дало змогу застосовувати CSS безпосередньо в JavaScript-
коді, забезпечуючи ізоляцію стилів, динамічну зміну тем та покращену
читабельність стилів на рівні компонента.
Серверна частина реалізована на основі Node.js із використанням
фреймворку ExpressJS. Такий вибір пояснюється високою продуктивністю
Node.js, побудованого на подієвій неблокуючій моделі, що забезпечує ефективну
обробку одночасних запитів. ExpressJS, у свою чергу, дозволив швидко
налаштувати REST API з чітким розділенням відповідальності, використовуючи
роутери та middleware.
Для зберігання даних було обрано MongoDB — документно-орієнтовану
NoSQL базу даних, яка відмінно підходить для зберігання структурованих та
напівструктурованих даних. Робота з базою здійснюється через ODM-бібліотеку
Mongoose, яка спрощує побудову схем, валідацію та взаємодію з базою даних,
інтегруючись безпосередньо з Node.js-оточенням.
У якості середовища розробки використовувався MacBook Pro 14” з
процесором Apple M2 Pro та 16 ГБ оперативної пам’яті. Така конфігурація
забезпечує високу продуктивність при компіляції, запуску серверної частини,
тестуванні та одночасній роботі з кількома інструментами розробки. Загалом
обрані засоби реалізації забезпечують надійність, масштабованість та гнучкість
веб-застосунку, дозволяючи ефективно реалізувати всі вимоги, поставлені в
рамках цього проєкту.
3.1.2 Опис функціональної схеми
На рисунку 3.1 зображено функціональну схему взаємодії основних
компонентів застосунку в процесі обробки даних та відповіді на запити
користувача. Архітектура проєкту побудована з урахуванням принципів
розділення відповідальності, гнучкості та масштабованості.
Користувач взаємодіє з веб-інтерфейсом, створеним за допомогою ReactJS.
Через елементи UI (наприклад, форми або кнопки) користувач ініціює запити до
серверної частини. Клієнтська логіка формує HTTP-запити (методи GET, POST,
PUT, DELETE) та надсилає їх до REST API, реалізованого на базі Node.js з
використанням ExpressJS.
Серверна частина приймає запит і передає його до відповідного маршруту
(router). Далі логіка обробляється у контролерах і сервісах, які взаємодіють з
базою даних MongoDB через бібліотеку Mongoose. База даних зберігає
інформацію у вигляді документів, що дозволяє гнучко працювати зі структурами
даних.
Після отримання необхідної інформації, дані обробляються на сервері та
повертаються у вигляді JSON-відповіді до клієнта. React-інтерфейс, у свою чергу,
оновлює стан додатку та відображає оновлену інформацію користувачеві. Така
структура дозволяє ефективно організувати обробку даних, зберігаючи чітку
межу між фронтендом і бекендом.
Рисунок 15 – Функціональна схема
3.1.3 Опис логічної схеми системи
Процес функціонування веб-застосунку для управління задачами з
використанням Kanban-дошки побудований на чіткій взаємодії між клієнтською
частиною, серверною логікою та базою даних. Система реалізована з
використанням сучасного технологічного стеку, що забезпечує високу
продуктивність, гнучкість і масштабованість.
У логічну схему роботи системи входять наступні етапи:
1. Ініціалізація клієнта та підключення до сервера. При запуску веб-
застосунку клієнтська частина, реалізована за допомогою ReactJS,
відображає стартовий інтерфейс користувача. За допомогою бібліотеки
MUI реалізовано компоненти інтерфейсу, а Styled-Components
забезпечують локальне стилізування компонентів. Клієнт надсилає
запити до серверної частини через REST API, реалізоване на Express.
2. Реєстрація та авторизація користувача. Користувач може
зареєструватися або увійти в систему, надавши свої облікові дані.
Серверна частина на базі Node.js приймає ці запити, перевіряє
відповідність даних і у випадку успішної авторизації генерує JWT-
токен. Цей токен зберігається на клієнті у LocalStorage і
використовується для доступу до захищених ресурсів.
3. Створення дошки. Авторизований користувач має змогу створити
нову Kanban-дошку. Клієнтська частина формує запит на створення
дошки (з назвою, кольором або іншими параметрами), який
надсилається на сервер. Сервер створює новий документ у базі даних
MongoDB, де дошка прив’язується до ID користувача.
4. Створення списків та карток. У межах дошки користувач може
створювати списки (наприклад, "Заплановано", "У процесі",
"Виконано") та додавати до них картки із завданнями. Кожна картка
містить назву, опис, дату створення тощо. Відповідні дані зберігаються
у базі як документи lists та cards, з посиланням на відповідну дошку та
список. Усі запити проходять через REST API та обробляються
сервером, який оновлює дані в MongoDB.
5. Редагування та видалення елементів. Користувач має змогу
редагувати назви дошок, списків, карток або видаляти їх. Усі ці дії
ініціюються на клієнтській частині, після чого надсилається
відповідний HTTP-запит (PUT, DELETE) до API. Сервер обробляє
запит і оновлює або видаляє відповідні документи в базі даних.
6. Отримання та відображення даних. Для відображення існуючих
дошок та вмісту на клієнті надсилається GET-запит до серверної
частини. API повертає відповідні JSON-дані, які клієнт обробляє та
динамічно відображає у вигляді Kanban-дошки з можливістю
переміщення карток між списками (drag-and-drop).
7. Забезпечення безпеки доступу. Всі запити, що стосуються захищених
ресурсів (наприклад, створення або редагування дошок),
супроводжуються JWT-токеном. На сервері реалізовано перевірку
токена з метою авторизації користувача та запобігання
несанкціонованому доступу до даних інших користувачів.
8. Завершення роботи. При виході користувача з системи токен
видаляється з клієнта, і доступ до захищених маршрутів припиняється.
Усі створені дані зберігаються в MongoDB і будуть доступні при
наступному вході в систему
Рисунок 16 – Блок-схема логічної роботи системи
3.1.4 Розробка бази даних
У процесі створення веб-застосунку для організації робочих процесів за
допомогою канбан-дошки було передбачено використання документоорієнтованої
бази даних MongoDB, що забезпечує гнучке та масштабоване зберігання
інформації. Основними сутностями системи є користувачі, дошки, списки
(колонки) та картки (завдання).
Розробка бази даних охоплює декілька послідовних етапів. На початку
формується концептуальна модель, яка відображає ключові об’єкти предметної
області та логіку їхньої взаємодії. Далі створюється логічна структура —
визначаються схеми документів, типи полів, обов’язковість заповнення, зв’язки
між сутностями. Наприклад, кожна дошка має прив’язку до певного користувача,
а кожна картка належить до конкретного списку.
Фізична реалізація бази даних виконується за допомогою Mongoose —
бібліотеки для Node.js, що надає зручний інтерфейс для роботи з MongoDB і
дозволяє описувати схеми, накладати валідацію та забезпечувати узгодженість
даних. На цьому етапі також проєктуються індекси для прискорення пошуку, а
також реалізуються механізми автентифікації з використанням JWT, що
забезпечує захист доступу до приватних даних користувача.
Завдяки вибору MongoDB як сховища, система отримує високу гнучкість у
структурі даних, що дозволяє швидко адаптуватися до нових функціональних
вимог без необхідності суттєвих змін у базовій архітектурі.
3.1.5 Розробка програмного інтерфейсу
Інтерфейс користувача є важливим елементом мого веб-застосунку, адже
саме через нього здійснюється основна взаємодія з системою. Його розробка була
спрямована на забезпечення зручності, логічної структури та швидкого доступу
до функціоналу. Основна мета — створити зрозуміле, адаптивне та приємне у
використанні середовище для роботи з дошками, списками та картками.
Для реалізації клієнтської частини застосунку був використаний стек, що
включає ReactJS — популярну бібліотеку для побудови інтерфейсів на основі
компонентного підходу. Усі елементи інтерфейсу, такі як кнопки, поля введення,
діалогові вікна та картки завдань, реалізовані у вигляді окремих, багаторазово
використовуваних компонентів. Для стилізації інтерфейсу застосовано бібліотеку
MUI, яка забезпечує відповідність принципам Material Design, а також Styled-
Components для створення ізольованих стилів безпосередньо в JavaScript-коді.
Такий підхід до побудови інтерфейсу дозволяє не лише підтримувати
високий рівень гнучкості та повторного використання коду, але й забезпечує
зручність у підтримці та подальшому масштабуванні проєкту. Інтерфейс
адаптується до різних розмірів екранів, що гарантує комфортне користування як
на комп’ютерах, так і на мобільних пристроях.
Основні елементи WEB-додатку:
− Початкова сторінка для неавторизованих користувачів
Рисунок 17 – Початкова сторінка
− Сторінка реєстрації
Рисунок 18 – Сторінка реєстрації
− Сторінка авторизації
Рисунок 19 – Сторінка авторизації
− Сторінка для авторизованого користувача з усіма його дошками,
можливістю створити нову (з вибором заголовку, запрошенням
користувачів для колаборації та вибором фону блоку з дошкою) та
хедером з такими функціями, як повернутися на головну сторінку з
дошками, випадаючим списком з дошками, пошуковим полем (дає
змогу фільтрувати потрібні дошки та картки) та іконкою користувача,
після натискання на яку, можна вийти з акаунту.
Рисунок 20 – Головна сторінка авторизованого користувача з дошками
Рисунок 21 – Головна сторінка з дошками з відкритим модальним вікном для
створення
− Сторінка дошки зі ствопцями, картками, кнопками для додавання
нових членів команди та переглядом меню дошки.
Рисунок 22 – Сторінка дошки
Рисунок 23 – Вигляд вікна для створення списку на сторінці дошки
Рисунок 24 – Вигляд створеного списку на сторінці дошки
Рисунок 25 – Вигляд створення картки в списку на сторінці дошки
Рисунок 26 – Вигляд списку з карткою в ньому на сторінці дошки
− Бічне меню праворуч, який відкривається після натискання кнопки
“Показати меню” праворуч. Це бічне меню містить історію дошки, дає
можливість подивитися інформацію про дошку та відредагувати її, а
також змінити фон, чи то колір, чи то Unsplash картинка.
Рисунок 27 – Вигляд бічного меню дошки
Рисунок 28 – Вигляд бічного меню з відкритою вкладкою Про цю дошку
Рисунок 29 – Вигляд бічного меню з відкритою вкладкою Змінити фон
Рисунок 30 – Вигляд бічного меню з відкритою вкладкою Змінити фон/Фото
Рисунок 31 – Вигляд бічного меню з відкритою вкладкою Змінити фон/Колір
− Модальне вікно картки з описом, ярликами, членами команди,
дедлайнами, обкладинкою, вкладеннями, коментарями, історією,
checklist’ами та можливістю видалити картку.
Рисунок 32 – Вигляд модального вікна картки
Рисунок 33 – Додавання члена картки
Рисунок 34 – Додавання ярликів
Рисунок 35 – Додавання checklist’а
Рисунок 36 – Додавання дедлайнів
Рисунок 37 – Додавання вкладень
Рисунок 38 – Вибір обкладинки
Рисунок 39 – Написання коментаря
Рисунок 40 – Вигляд картки з усіма заповненими даними
Рисунок 41 – Вигляд картки з усіма заповненими даними в списку
Щодо технічної реалізації, у процесі створення веб-застосунку для
організації задач було застосовано сучасний технологічний стек, що забезпечує
гнучкість, масштабованість і зручність як для користувачів, так і для розробників.
Кожна обрана технологія відіграє конкретну роль у вирішенні практичних завдань
і покращенні загальної архітектури системи.
На клієнтській стороні використано ReactJS, що дозволяє реалізувати
компонентну архітектуру та спрощує керування станом інтерфейсу. Компоненти,
такі як дошки, списки, картки, форми, кнопки та модальні вікна, були розроблені
з урахуванням принципів повторного використання та модульності. Для стилізації
застосовано MUI, що значно пришвидшує створення естетично привабливого і
адаптивного інтерфейсу. У поєднанні з Styled-Components це дозволило створити
унікальні стилі без винесення CSS в окремі файли, що позитивно вплинуло на
ізольованість та читабельність коду.
На серверній стороні реалізацію побудовано з використанням Node.js та
Express, що забезпечує просту і гнучку розробку REST API. Через ці API клієнт
здійснює всі необхідні запити: створення, оновлення, видалення та отримання
інформації про дошки, списки й картки. Аутентифікація та авторизація
реалізовані з використанням JWT (JSON Web Token), що гарантує безпечний
обмін даними між клієнтом і сервером та дозволяє захищати доступ до ресурсів
системи.
Дані користувачів, завдань і структури проєкту зберігаються у MongoDB —
документоорієнтованій NoSQL базі даних, яка забезпечує високу продуктивність і
дозволяє гнучко оперувати вкладеними структурами, що добре відповідає
концепції дошок зі списками та картками.
Кожна з технологій була обрана не випадково — вони вирішують конкретні
завдання: гнучка структура зберігання даних, модульність інтерфейсу, швидкість
відповіді API, захист маршруту та зручне масштабування системи. Такий підхід
дозволив реалізувати ефективний та адаптивний інструмент для управління
задачами, який легко розширювати та підтримувати в майбутньому.
3.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів веб-застосунку здійснювалася відповідно
до принципів модульності та розділення відповідальності. Такий підхід дозволяє
не лише спростити підтримку системи, але й забезпечити її масштабованість у
разі розширення функціональності. Проєкт поділено на дві основні частини —
клієнтську та серверну, кожна з яких реалізує свої власні функціональні модулі,
відповідно до сучасних архітектурних практик.
Клієнтська частина
Інтерфейс користувача побудований на основі ReactJS, з використанням
MUI для компонентів і Styled-Components для індивідуальної стилізації.
Архітектура побудована компонентно: загальні елементи повторно
використовуються в межах різних сторінок. Структура організована у вигляді
модулів за функціональним призначенням.
Основні компоненти:
− CreateBoardModal – діалогове вікно для створення нової дошки, що
включає логіку введення даних, перевірки та стилізовану обгортку.
− EditCardModal – модульне діалогове вікно редагування картки, розбите
на підкомпоненти:
− Actions, Attachments, ActivityLog, Comment, Description, Labels,
Background — кожен компонент відповідає за окрему секцію
функціоналу картки.
− ReUsableComponents містить елементи, які використовуються
повторно в межах діалогового інтерфейсу.
− RightDrawer – бічне меню, що дозволяє керувати зовнішнім виглядом
дошки (наприклад, зміна фону), а також містить вкладки (MainMenu,
ContentMenu, BackgroundMenu) для навігації.
− AlertSnackbar, LoadingScreen, DropdownMenu, ProfileBox – допоміжні
UI-компоненти для виводу повідомлень, відображення стану
завантаження та взаємодії з користувачем.
Кожна сторінка (наприклад, BoardPage, LoginPage, RegisterPage)
реалізується як окремий модуль із власною логікою, що дозволяє підтримувати
чисту структуру та гнучко керувати навігацією в межах застосунку. Сторінки
захищено за допомогою компонентів ProtectedRoute та FreeRoute, які перевіряють
авторизаційний статус користувача.
Управління станом реалізовано через Redux, а бізнес-логіка API викликів
винесена у сервісний шар (services/), що забезпечує централізовану взаємодію з
бекендом.
Серверна частина
Серверна частина реалізована з використанням Node.js та Express.js. Вона
побудована за класичною трирівневою архітектурою: маршрути — контролери —
сервіси, з окремим шаром моделей (Mongoose) та мідлварами для перевірки
доступу.
Основні компоненти:
− Маршрути (routes/) — визначають REST-ендпоінти для роботи з
основними сутностями: board, card, list, user.
− Контролери (controllers/) — відповідають за обробку запитів, прийом
даних та виклик відповідного сервісу. Наприклад, card.js контролює
логіку створення, оновлення та видалення карток.
− Сервіси (services/) — інкапсулюють бізнес-логіку. Вони взаємодіють з
базою даних через моделі, реалізуючи перевірки, фільтрацію,
трансформацію даних тощо.
− Моделі (models/) — описані з використанням Mongoose, визначають
схеми документів MongoDB. Наприклад, модель Card включає поля
назви, опису, міток, прикріплень та прив’язку до відповідного списку.
− Мідлвари (middlewares/) — проміжні обробники, зокрема auth.js, який
перевіряє JWT-токени при захищених запитах.
Система реалізована з урахуванням сучасних підходів до забезпечення
безпеки та контролю доступу. Основу автентифікації становить механізм токенів
JSON Web Token (JWT), який дозволяє створити безпечну, масштабовану й
ефективну модель взаємодії між клієнтом і сервером.
Після успішної реєстрації або входу користувача сервер створює унікальний
підписаний токен, який містить ID користувача та інші метадані, необхідні для
автентифікації. Токен зберігається на клієнтській частині у сховищі LocalStorage,
що дозволяє повторно використовувати його для здійснення запитів до захищених
маршрутів без потреби постійного повторного входу.
Кожен захищений запит супроводжується цим токеном у заголовку
Authorization (Bearer-токен). На стороні сервера реалізовано middleware для
перевірки дійсності токена: якщо токен відсутній, недійсний або прострочений,
запит не обробляється, і користувач отримує повідомлення про відмову в доступі.
Крім аутентифікації, впроваджено також рівні авторизації. Наприклад,
користувач має доступ лише до тих ресурсів (дошок, списків, карток), які
прив’язані до його облікового запису. Навіть при наявності валідного токена,
перевіряється, чи дійсно ресурс належить саме цьому користувачеві. Це дозволяє
уникнути спроб несанкціонованого доступу до даних інших користувачів.
Додаткові заходи безпеки реалізовані на рівні розробки застосунку.
Зокрема, паролі користувачів не зберігаються у відкритому вигляді — для їх
шифрування використовується алгоритм хешування, що забезпечує високий
рівень захисту у разі витоку даних. Також у системі впроваджено механізми
обробки помилок: критичні помилки не відображаються користувачу, а логуються
у захищене сховище для подальшого аналізу розробниками. Логування подій
допомагає відстежувати потенційно підозрілу активність та своєчасно реагувати
на інциденти безпеки.
Усі ці заходи у комплексі формують надійний захист системи та гарантують
безпечне зберігання й обробку даних користувачів. Таке рішення дозволяє не
тільки забезпечити конфіденційність та цілісність інформації, а й підтримує
масштабування системи без шкоди для її безпеки.
В результаті реалізації проєкту створено гнучкий, структурований та
розширюваний веб-додаток. Завдяки чіткій організації коду та дотриманню
архітектурних патернів (зокрема, розділення обов'язків), забезпечується легкість в
обслуговуванні та адаптації системи до нових вимог.
3.2 Тестування системи
3.2.1 Модульне тестування
У процесі розробки веб-додатку було впроваджено модульне тестування як
невід’ємну складову забезпечення якості програмного забезпечення. Основною
метою модульного тестування є перевірка коректності роботи окремих логічних
одиниць системи — таких як сервіси, утиліти, контролери та компоненти — в
ізольованому середовищі, без впливу зовнішніх залежностей.
Клієнтська частина
Для тестування клієнтської частини, реалізованої на базі React,
використовувався фреймворк Jest у поєднанні з React Testing Library. Цей зв’язок
дозволяє проводити тестування компонентів у поведінковому стилі, наближеному
до реальної взаємодії користувача з інтерфейсом. Для емулювання браузерного
середовища використовувалась бібліотека jsdom, яка забезпечує доступ до DOM-
API під час виконання тестів у середовищі Node.js.
Особливу увагу приділено тестуванню:
− функціональних компонентів, які мають внутрішній стан або
обробляють події;
− повторно використовуваних UI-елементів (наприклад, кнопок,
модальних вікон, випадаючих меню);
− логіки рендерингу та умовного відображення контенту.
Серверна частина
Серверна частина, реалізована з використанням Node.js та Express, також
покривалась модульними тестами за допомогою Jest. Завдяки використанню
шарів services та controllers, було можливо легко ізолювати тестовані одиниці від
зовнішніх залежностей, таких як база даних чи зовнішні API.
У тестах активно застосовувалися:
− моки та шпигуни (jest.mock, jest.fn) для заміни реальних залежностей
фіктивними;
− тестування бізнес-логіки у сервісах (наприклад, створення картки,
переміщення між списками, перевірка прав доступу);
− тестування контролерів, включно з обробкою валідних та невалідних
запитів;
− перевірка помилкових сценаріїв (обробка винятків, помилки
аутентифікації тощо).
Усі модулі тестувалися в ізольованому середовищі, що дозволило виявляти
помилки на ранніх етапах розробки без потреби запуску повного застосунку або
реального сервера бази даних.
В таблиці 3.1 представлені результати тестування клієнтської частини.
Таблиця 3.1 – Модульне тестування
Ім’я модульного тесту Очікуваний результат Отриманий результат
Правильне Всі дошки Всі дошки
відображення дошок з відображаються з усією відображаються з усією
усією інформацією інформацією а також з інформацією а також з
правильним фоном правильним фоном
Відображення всіх Усі колонки Усі колонки
колонок у коректному відображаються у відображаються у
порядку та зі порядку створення, порядку створення,
збереженим контентом мають збережений мають збережений
заголовок та картки заголовок та картки
Відображення Картка відображається Картка відображається
модального вікна з усіма збереженими з усіма збереженими
картки з усіма налаштуваннями налаштуваннями
налаштуваннями
Маніпуляція з картками Картки можуть Картки пересовуються
за допомогою пересовуватися між між стовпчиками по
визначених дій стовпчиками по затисканню кнопки
затисканню кнопки миші
миші
Коректне відображення Бічне меню повинне Бічне меню
бічне меню дошки відкриватися по кліку відкривається по кліку
на кнопку “Меню” і на кнопку “Меню” і
відображати відображає інформацію
інформацію про дошку. про дошку. А також дає
А також давати можливість
можливість відредагувати всі поля
відредагувати всі поля
Вихід з системи При кліку видаляються При кліку видаляються
дані користувача з дані користувача з
клієнту та надсилається клієнту та надсилається
відповідний запит на відповідний запит на
сервер сервер
3.2.2 Інтеграційне тестування
Інтеграційне тестування у рамках цього проєкту проводилося з метою
перевірки коректної взаємодії між окремими модулями клієнтської та серверної
частин, а також перевірки повного життєвого циклу обробки запитів від
користувача до бази даних. Це дозволило переконатися, що окремі частини
системи не лише працюють правильно в ізоляції (як у модульному тестуванні), а й
функціонують належним чином у взаємозв’язку.
Для серверної частини (побудованої на Node.js + Express) інтеграційні тести
були реалізовані з використанням бібліотеки Jest у поєднанні з supertest, що дало
змогу емулювати HTTP-запити до REST API без потреби запуску повноцінного
клієнта. З метою ізоляції від продуктивного середовища використовувалась
тестова база даних MongoDB, що створювалась за допомогою бібліотеки
mongodb-memory-server. Це дозволяло запускати базу в пам’яті під час
тестування, не зачіпаючи реальні дані.
Інтеграційне тестування охоплювало ключові бізнес-сценарії, зокрема:
− реєстрацію та автентифікацію користувача; створення, оновлення та
видалення дошок (boards), списків (lists) і карток (cards);
− перевірку авторизації доступу до захищених маршрутів;
− перевірку зв’язків між сутностями (наприклад, зв’язок між дошкою та
її списками, або списком і його картками).
Для клієнтської частини, реалізованої на React (Next.js), були створені
інтеграційні тести з використанням React Testing Library, які дозволяли перевіряти
логіку користувацької взаємодії (створення картки, переміщення між списками
тощо) разом із симуляцією запитів до API. Основна увага приділялася тестуванню
повних функціональних потоків — від взаємодії користувача до зміни стану в
інтерфейсі та оновлення даних на сервері.
У результаті проведеного інтеграційного тестування було підтверджено
узгоджену роботу всіх компонентів системи та стійкість програми до помилкових
сценаріїв.
Таблиця 3.2 – Інтеграційне тестування
Ім’я інтеграційного Очікуваний результат Отриманий результат
тесту
Реєстрація нового Користувач Користувач
користувача створюється в базі, створюється в базі,
повертається JWT токен повертається JWT токен
Авторизація з Повернення статусу 401 Повернення статусу 401
неправильним токеном та повідомлення про та повідомлення про
помилку авторизації помилку авторизації
Створення нової дошки Авторизований Авторизований
користувач створює користувач створює
дошку, яка зберігається дошку, яка зберігається
в базі в базі
Додавання картки до Картка зберігається в Картка зберігається в
списку базі, зв’язується з базі, зв’язується з
відповідним списком відповідним списком
Редагування назви Зміни зберігаються в Зміни зберігаються в
списку базі, оновлене значення базі, оновлене значення
повертається клієнту повертається клієнту
Видалення картки Картка видаляється з Картка видаляється з
бази бази
Отримання списків для Повертається масив Повертається масив
дошки списків, пов’язаних із списків, пов’язаних із
заданою дошкою заданою дошкою
3.2.3 Системне тестування
Системне тестування стало завершальним етапом перевірки працездатності
веб-застосунку. На цьому рівні оцінювалась вже повністю інтегрована система —
як з клієнтською, так і з серверною частинами — з метою перевірки її
відповідності вимогам, сформульованим на етапі аналізу та проєктування.
Оскільки створений застосунок виконує функції управління задачами за
принципом канбан-дошки, системне тестування охоплювало ключові аспекти
функціональності, а також нефункціональні характеристики, важливі для
стабільної роботи в реальному середовищі. У процесі тестування було перевірено:
− Функціональну повноту: усі основні сценарії взаємодії з системою —
створення, редагування та видалення дошок, списків і карток;
переміщення карток між списками; автентифікація та авторизація
користувачів — виконувались відповідно до заданої логіки. Також
протестовано реакцію інтерфейсу на помилки та невалідні дії.
− Кросбраузерну сумісність: було здійснено перевірку функціонування
інтерфейсу у найпопулярніших браузерах — Google Chrome та Mozilla
Firefox. У результаті було підтверджено коректне відображення
компонентів та стабільну роботу клієнта незалежно від браузера.
− Продуктивність: для оцінки навантаження серверної частини були
змодельовані ситуації з високою кількістю одночасних запитів
(наприклад, масове створення карток або швидкі переходи між
дошками). Система залишалася стабільною й демонструвала допустимі
показники часу відповіді.
− Безпека: проведено ручну перевірку захищеності маршрутів. Зокрема,
тестувалися сценарії доступу без JWT-токену або з підробленим
токеном. Всі запити належним чином блокувалися, а приватні дані
залишалися недоступними для неавторизованих користувачів.
− Цілісність даних: усі CRUD-операції з даними в базі даних MongoDB
перевірялися на коректність збереження. Тестувалась поведінка
системи при одночасному оновленні, видаленні та читанні одних і тих
же сутностей. Система зберігала узгодженість даних та уникала станів
гонки.
У результаті проведеного системного тестування було встановлено, що веб-
застосунок виконує свої функції відповідно до вимог, забезпечує стабільну роботу
при навантаженні, не має критичних вразливостей безпеки та пропонує
користувачеві інтуїтивно зрозумілий інтерфейс. Це свідчить про технічну
готовність системи до впровадження та використання в реальному середовищі.
3.2.4 Приймальне тестування
Приймальне тестування стало завершальним етапом перевірки готовності
веб-застосунку до впровадження в робоче середовище. Його основна мета —
переконатися, що реалізований функціонал повністю відповідає очікуванням
кінцевого користувача та вимогам, визначеним на етапі постановки задачі.
Цей етап передбачав не лише технічну перевірку, а й залучення
користувачів до тестування функціоналу системи в умовах, наближених до
реального використання. Під час приймального тестування були виконані такі дії:
− перевірка відповідності функціоналу технічним вимогам. Було
протестовано ключові сценарії: реєстрація та вхід користувача,
створення та редагування дошки, додавання списків і карток, зміна
статусу задач шляхом перетягування, видалення елементів, пошук і
фільтрація. Усі функції працювали відповідно до проєктної
документації;
− оцінка інтерфейсу користувача. Прототип застосунку було надано
кільком тестувальникам, які здійснили типові дії — від створення нової
задачі до налаштування профілю. Зібрані відгуки підтвердили
інтуїтивність інтерфейсу, логічну структуру розмітки та зручність у
навігації між розділами;
− симуляція реального використання. Були змодельовані ситуації
типового щоденного використання застосунку: одночасна робота
декількох користувачів, швидке переміщення великої кількості задач,
навмисне введення некоректних даних (наприклад, пусті назви або
надто довгі рядки). У результаті застосунок продемонстрував стійку
поведінку, валідував введення та коректно обробляв помилки;
− аналіз технічної документації. Було оцінено доступність та
змістовність документації для розробників, зокрема частину, що
стосується REST API, структури MongoDB-колекцій та логіки
автентифікації через JWT. Документація виявилася достатньо повною
для того, щоб інший розробник міг швидко розібратися в архітектурі та
принципах роботи системи.
За підсумками приймального тестування зроблено такі висновки:
− Веб-застосунок відповідає функціональним та нефункціональним
вимогам, визначеним на етапі проєктування. Інтерфейс є доступним,
зручним і не потребує спеціального навчання для початку роботи.
Система демонструє стабільну поведінку навіть у нештатних або
помилкових ситуаціях. Проєкт повністю готовий до розгортання в
продуктивному середовищі та подальшого використання
користувачами.
3.3 Приклади впровадження програмного комплексу
3.3.1 Розгортання системи
Для розгортання веб-застосунку було обрано підхід, заснований на
використанні системи контролю версій Git та хмарних сервісів для зберігання та
обробки даних. Увесь вихідний код системи зберігається в окремих репозиторіях
на платформі GitHub, що забезпечує зручне керування версіями, спільну розробку
та централізований доступ до проєкту.
Система має двокомпонентну архітектуру — серверну частину (backend) і
клієнтську частину (frontend). Розгортання кожного з компонентів відбувається
окремо, але з урахуванням взаємної інтеграції через REST API.
Розгортання серверної частини
Серверна частина побудована за допомогою Node.js та Express, з
підключенням до хмарної бази даних MongoDB Atlas. Розгортання виконується
локально або на хостингу, без використання контейнеризації.
Для запуску необхідно виконати такі кроки:
− Клонувати відповідний репозиторій із GitHub.
− Створити файл конфігурації .env на основі шаблону .env.example,
вказавши такі параметри:
− URI до бази даних MongoDB Atlas;
− секретний ключ для генерації JWT-токенів;
− порт, на якому працює сервер;
− час життя JWT-токенів.
− Встановити залежності командою yarn install.
− Запустити сервер у режимо розробки (yarn run dev).
У результаті серверна частина підключається до віддаленої бази даних
MongoDB Atlas і забезпечує повноцінну роботу REST API.
Розгортання клієнтської частини
Фронтенд реалізовано з використанням ReactJS, що дозволяє створювати
динамічні сторінки з високою швидкодією. Для запуску клієнта потрібно:
− Клонувати репозиторій клієнтської частини з GitHub.
− Скопіювати файл .env.example у .env і налаштувати змінні, зокрема:
базову адресу до серверного API.
− Встановити залежності за допомогою менеджера пакетів (yarn install).
− Запустити застосунок командою yarn start.
Такий підхід до розгортання забезпечує простоту запуску та
масштабованість проєкту. Використання GitHub дозволяє легко відслідковувати
зміни в коді, а підключення до MongoDB Atlas знімає необхідність налаштування
локального середовища для бази даних. Розмежування на клієнтську та серверну
частини дає можливість гнучко керувати розвитком та впровадженням системи в
майбутньому.
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі було розглянуто процес розробки та тестування веб-
застосунку для організації робочих процесів за допомогою Kanban-дошки. На
основі сучасного технологічного стеку — ReactJS, Node.js, Express та MongoDB
— реалізовано повноцінну систему з чітким розділенням відповідальності між
клієнтською та серверною частинами.
Було обґрунтовано вибір кожного компонента: React забезпечив гнучке та
швидкодійне створення інтерфейсу з можливістю повторного використання
компонентів; Styled-Components та MUI надали засоби для гнучкої стилізації та
адаптивності інтерфейсу. Серверна логіка побудована на Express, що дозволило
реалізувати REST API з чіткою структурою маршрутизації та контролерів. Для
роботи з даними використано MongoDB з бібліотекою Mongoose, що спростило
побудову схем та валідацію, а також забезпечило високу гнучкість при зберіганні
напівструктурованої інформації.
Сформовано як функціональну, так і логічну архітектуру системи, що
враховує етапи автентифікації, обробки даних, оновлення інтерфейсу та захисту
ресурсів. У процесі розробки було реалізовано всі ключові функції: створення та
редагування дошок, списків і карток, drag-and-drop для переміщення задач, а
також перевірка прав доступу через JWT.
На завершення було приділено увагу організації структури бази даних та
підготовці до розгортання системи. Завдяки ретельно продуманій архітектурі
застосунок готовий до подальшого масштабування та адаптації під різні сценарії
використання, забезпечуючи стабільну роботу та зручний користувацький досвід.
ВИСНОВКИ
У результаті виконання роботи було здійснено комплексний аналіз,
проєктування та реалізацію веб-застосунку для організації робочих процесів за
допомогою Канбан-дошки.
На етапі теоретичного дослідження виявлено ключові проблеми сучасного
управління завданнями, серед яких — перевантаження команд, неефективна
комунікація та відсутність прозорості. У якості ефективного підходу
проаналізовано Канбан-модель, що дозволяє візуалізувати процеси та підвищити
керованість робочого навантаження. Також здійснено огляд популярних систем
(Microsoft Planner, Jira, Asana) та обґрунтовано доцільність створення власного
адаптивного рішення на основі сучасних технологій: ReactJS, Node.js, Express та
MongoDB.
На етапі моделювання системи було сформовано цілісне уявлення про
функціонування програмного продукту: розроблено словник термінів, визначено
вимоги, змодельовано ключові сутності та взаємодії у вигляді UML-діаграм
різних типів (прецедентів, класів, компонентів, діяльності, послідовності тощо).
Це дозволило чітко структурувати архітектуру системи, закласти основу для її
масштабування та забезпечити прозорість комунікації в командній роботі.
На етапі реалізації було побудовано повнофункціональний веб-застосунок із
поділом на клієнтську та серверну частини. Реалізовано всі основні функції:
авторизацію, створення та редагування дошок, списків, карток, переміщення задач
за допомогою drag-and-drop, обмеження доступу через JWT. Система побудована
з урахуванням вимог масштабованості, зручності використання та безпеки.
Таким чином, результати роботи демонструють ефективність комплексного
підходу до створення програмного забезпечення: від аналізу проблематики та
моделювання — до розробки готового продукту, який відповідає актуальним
вимогам сучасних команд і організацій.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Бойко, А. М. Основи розробки веб-застосунків. – Київ: Видавництво Ліра-К,
2021. – 240 с.
2. Паламарчук, В. І. Технології розподілених інформаційних систем: навчальний
посібник. – Київ: КНУ, 2020. – 198 с.
3. Дьяків, О. І. Проєктування інтерфейсів користувача: навчальний посібник. –
Львів: ЛНУ ім. І. Франка, 2022. – 142 с.
4. Гринчук, С. О. Системи управління проєктами та командна робота //
Електронне наукове фахове видання "Інформаційні технології і засоби
навчання", №3 (85), 2022. – https://journal.iitta.gov.ua
5. Шевченко, М. В. Організація командної роботи за методологією Kanban //
"Вісник НТУУ КПІ. Інформатика, управління та обчислювальна техніка", №1,
2021.
6. Chacon, S., Straub, B. Pro Git (2nd ed.) – Apress, 2014. – https://git-
scm.com/book/en/v2
7. GitHub Docs. GitHub REST API documentation – https://docs.github.com/rest
8. Node.js Documentation – https://nodejs.org/en/docs
9. React Documentation – Meta – https://react.dev/
10. MDN Web Docs. JavaScript Guide – Mozilla Developer Network –
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide
11. MongoDB Documentation – https://www.mongodb.com/docs/
12. Beck, K. Extreme Programming Explained: Embrace Change. – Addison-Wesley,
2004.
13. Pressman, R. S. Software Engineering: A Practitioner's Approach. – McGraw-Hill,
2014.
14. Sommerville, I. Software Engineering (10th Edition). – Pearson, 2015.
ДОДАТКИ
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2025 р.
«WEB-застосунок для організації робочих процесів»
Специфікація
ЧДТУ 252153-006 ПЗ
Листів 2
Розробник ________________ Калайда В.Р.
Керівник ________________ Куницька С. Ю.
2025
Позначення Найменування Примітка
Документація
482.ЧДТУ 252153 12 01 Текст програми
482.ЧДТУ 252153 90 01 Графічні матеріали
ДОДАТОК Б
«WEB-застосунок для організації робочих процесів»
Текст програми
482.ЧДТУ 252153 21 01
Листів 16
Розробник ________________ Калайда В.Р.
2025
482.ЧДТУ 252153 21 01
client/src/app.js
import React, { useEffect } from "react";
import Index from "./pages/IndexPage/Index";
import Login from "./pages/LoginPage/Login";
import Register from "./pages/RegisterPage/Register";
import Alert from "./components/AlertSnackBar";
import {BrowserRouter, Routes, Route} from "react-router-dom";
import Boards from "./pages/BoardsPage/Boards";
import ProtectedRoute from "./routes/ProtectedRoute";
import { loadUser } from "./services/user";
import Store from "./redux/store";
import FreeRoute from "./routes/FreeRoute";
import Board from "./pages/BoardPage/Board";
import {WaterMark} from "./Styled";
const App = () => {
useEffect(() => {
loadUser(Store.dispatch);
}, []);
return (
<BrowserRouter>
<Alert />
<WaterMark>
<span>Розроблено Калайдою Вадімом, ПЗ-2104</span>
</WaterMark>
<Routes>
<Route element={<FreeRoute />}>
<Route path="/" element={<Index />} />
<Route path="/login" element={<Login />} />
<Route path="/register" element={<Register />} />
</Route>
<Route element={<ProtectedRoute />}>
<Route path="/boards" element={<Boards />} />
<Route path="/board/:id" element={<Board />} />
</Route>
</Routes>
</BrowserRouter>
);
};
export default App;
server/server.js
3
482.ЧДТУ 252153 21 01
const dotenv = require('dotenv');
const express = require('express');
const unless = require('express-unless');
const mongoose = require('mongoose');
const cors = require('cors');
const userRoute = require('./routes/user');
const boardRoute = require('./routes/board');
const listRoute = require('./routes/list');
const cardRoute = require('./routes/card');
const auth = require('./middlewares/auth');
dotenv.config();
const app = express();
app.use(cors());
app.use(express.json());
auth.verifyToken.unless = unless;
app.use(
auth.verifyToken.unless({
path: [
{ url: '/user/login', method: ['POST'] },
{ url: '/user/register', method: ['POST'] },
],
})
);
mongoose.Promise = global.Promise;
mongoose
.connect(process.env.MONGO_URI, {
useNewUrlParser: true,
useUnifiedTopology: true,
})
.then(() => {
console.log('Database connection has been set up successfully!');
})
.catch((err) => {
console.log(`Database connection failed!`);
console.log(`Details : ${err}`);
});
app.use('/user', userRoute);
app.use('/board', boardRoute);
app.use('/list', listRoute);
app.use('/card', cardRoute);
app.listen(process.env.PORT, () => {
console.log(`Server has been started on port: ${process.env.PORT}`);
});
server/helpers.js
4
482.ЧДТУ 252153 21 01
const validateCardOwners = async (card = null, list, board, user, isCreate =
false) => {
const validate = isCreate ? true : list.cards.filter((item) => item.toString()
=== card._id.toString());
const validate2 = board.lists.filter((item) => item.toString() ===
list._id.toString());
const validate3 = user.boards.filter((item) => item.toString() ===
board._id.toString());
return validate && validate2 && validate3;
};
const labelsSeed = [
{ text: '', color: '#61bd4f', backColor: '#519839', selected: false },
{ text: '', color: '#f2d600', backColor: '#d9b51c', selected: false },
{ text: '', color: '#ff9f1a', backColor: '#cd8313', selected: false },
{ text: '', color: '#eb5a46', backColor: '#b04632', selected: false },
{ text: '', color: '#c377e0', backColor: '#89609e', selected: false },
{ text: '', color: '#0079bf', backColor: '#055a8c', selected: false },
];
const createRandomHexColor = () => {
const values = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 'A', 'B', 'C', 'D', 'E', 'F'];
let hex = '#';
for (let i = 0; i < 6; i++) {
const index = Math.floor(Math.random() * values.length);
hex += values[index];
}
return hex.toString();
};
module.exports = {
validateCardOwners,
labelsSeed,
createRandomHexColor,
};
server/controllers/user.js
const bcrypt = require("bcryptjs");
const userService = require("../services/user");
const auth = require("../middlewares/auth");
const register = async (req, res) => {
const { name, surname, email, password } = req.body;
if (!(name && surname && email && password))
return res
.status("400")
.send({ errMessage: "Будь ласка заповніть всі обов'язкові поля!" });
const salt = bcrypt.genSaltSync(10);
const hashedPassword = bcrypt.hashSync(password, salt);
req.body.password = hashedPassword;
5
482.ЧДТУ 252153 21 01
await userService.register(req.body, (err, result) => {
if (err) return res.status(400).send(err);
return res.status(201).send(result);
});
};
const login = async (req, res) => {
const { email, password } = req.body;
if (!(email && password))
return res
.status(400)
.send({ errMessage: "Будь ласка заповніть всі обов'язкові поля!" });
await userService.login(email, (err, result) => {
if (err) return res.status(400).send(err);
const hashedPassword = result.password;
if (!bcrypt.compareSync(password, hashedPassword))
return res
.status(400)
.send({ errMessage: "Ваш email/пароль неправильний!" });
result.token = auth.generateToken(result._id.toString(), result.email);
result.password = undefined;
result.__v = undefined;
return res
.status(200)
.send({ message: "Користувач увійшов успішно!", user: result });
});
};
const getUser = async (req, res) => {
const userId = req.user.id;
await userService.getUser(userId, (err, result) => {
if (err) return res.status(404).send(err);
result.password = undefined;
result.__v = undefined;
return res.status(200).send(result);
});
};
const getUserWithMail = async(req,res) => {
const {email} = req.body;
await userService.getUserWithMail(email,(err,result)=>{
if(err) return res.status(404).send(err);
const dataTransferObject = {
name: result.name,
surname: result.surname,
color: result.color,
email : result.email
};
return res.status(200).send(dataTransferObject);
6
482.ЧДТУ 252153 21 01
})
}
module.exports = {
register,
login,
getUser,
getUserWithMail,
};
server/services/user.js
const userModel = require("../models/user");
const { createRandomHexColor } = require("../helpers");
const register = async (user, callback) => {
const newUser = userModel({ ...user, color:createRandomHexColor()});
await newUser
.save()
.then((result) => {
return callback(false, { message: "Користувача створено успішно!" });
})
.catch((err) => {
return callback({ errMessage: "Email вже використовується!", details: err
});
});
};
const login = async (email, callback) => {
try {
let user = await userModel.findOne({ email });
if (!user) return callback({ errMessage: "Ваш email/пароль неправильний!" });
return callback(false, { ...user.toJSON() });
} catch (err) {
return callback({
errMessage: "Щось пішло не так",
details: err.message,
});
}
};
const getUser = async (id, callback) => {
try {
let user = await userModel.findById(id);
if (!user) return callback({ errMessage: "Користувача не знайдено!" });
return callback(false, { ...user.toJSON() });
} catch (err) {
return callback({
errMessage: "Щось пішло не так",
details: err.message,
});
}
};
7
482.ЧДТУ 252153 21 01
const getUserWithMail = async (email, callback) => {
try {
let user = await userModel.findOne({ email });
if (!user)
return callback({
errMessage: "Немає зареєстрованого користувача з цим email.",
});
return callback(false, { ...user.toJSON() });
} catch (error) {
return callback({
errMessage: "Щось пішло не так",
details: error.message,
});
}
};
module.exports = {
register,
login,
getUser,
getUserWithMail,
};
server/controllers/board.js
const boardService = require('../services/board');
const create = async (req, res) => {
const { title, backgroundImageLink } = req.body;
if (!(title && backgroundImageLink))
return res.status(400).send({ errMessage: 'Назва та/або зображення не можуть
бути null' });
await boardService.create(req, (err, result) => {
if (err) return res.status(500).send(err);
result.__v = undefined;
return res.status(201).send(result);
});
};
const getAll = async (req, res) => {
const userId = req.user.id;
await boardService.getAll(userId, (err, result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
const getById = async (req, res) => {
const validate = req.user.boards.filter((board) => board === req.params.id);
if (!validate)
return res.status(400).send({ errMessage: 'Ви не можете бачити цю дошку, якщо
ви не є її учасником або власником!' });
// Call the service
8
482.ЧДТУ 252153 21 01
await boardService.getById(req.params.id, (err, result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
const getActivityById = async (req, res) => {
const validate = req.user.boards.filter((board) => board === req.params.id);
if (!validate)
return res.status(400).send({ errMessage: 'Ви не можете бачити цю дошку, якщо
ви не є її учасником або власником!' });
// Call the service
await boardService.getActivityById(req.params.id, (err, result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
const updateBoardTitle = async (req, res) => {
const validate = req.user.boards.filter((board) => board === req.params.id);
if (!validate)
return res
.status(400)
.send({ errMessage: 'Ви не можете змінити заголовок цієї дошки, якщо ви не є
її учасником або власником!' });
const { boardId } = req.params;
const { title } = req.body;
// Call the service
await boardService.updateBoardTitle(boardId, title, req.user, (err, result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
const updateBoardDescription = async (req, res) => {
const validate = req.user.boards.filter((board) => board === req.params.id);
if (!validate)
return res
.status(400)
.send({ errMessage: 'Ви не можете змінити опис цієї дошки, якщо ви не є її
учасником або власником!' });
const { boardId } = req.params;
const { description } = req.body;
// Call the service
await boardService.updateBoardDescription(boardId, description, req.user, (err,
result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
const updateBackground = async (req, res) => {
const validate = req.user.boards.filter((board) => board === req.params.id);
if (!validate)
return res
.status(400)
9
482.ЧДТУ 252153 21 01
.send({ errMessage: 'Ви не можете змінити задній фон цієї дошки, якщо ви не є
її учасником або власником!' });
const { boardId } = req.params;
const { background, isImage } = req.body;
// Call the service
await boardService.updateBackground(boardId, background, isImage, req.user,
(err, result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
const addMember = async (req, res) => {
const validate = req.user.boards.filter((board) => board === req.params.id);
if (!validate)
return res
.status(400)
.send({ errMessage: 'Ви не можете додати учасника до цієї дошки, якщо ви не є
її учасником або власником!' });
const { boardId } = req.params;
const { members } = req.body;
// Call the service
await boardService.addMember(boardId, members, req.user, (err, result) => {
if (err) return res.status(400).send(err);
return res.status(200).send(result);
});
};
module.exports = {
create,
getAll,
getById,
getActivityById,
updateBoardTitle,
updateBoardDescription,
updateBackground,
addMember,
};
server/services/board.js
const boardModel = require('../models/board');
const userModel = require('../models/user');
const create = async (req, callback) => {
try {
const { title, backgroundImageLink, members } = req.body;
let newBoard = boardModel({ title, backgroundImageLink });
newBoard.save();
const user = await userModel.findById(req.user.id);
user.boards.unshift(newBoard.id);
await user.save();
10
482.ЧДТУ 252153 21 01
let allMembers = [];
allMembers.push({
user: user.id,
name: user.name,
surname: user.surname,
email: user.email,
color: user.color,
role: 'owner',
});
await Promise.all(
members.map(async (member) => {
const newMember = await userModel.findOne({ email: member.email });
newMember.boards.push(newBoard._id);
await newMember.save();
allMembers.push({
user: newMember._id,
name: newMember.name,
surname: newMember.surname,
email: newMember.email,
color: newMember.color,
role: 'member',
});
newBoard.activity.push({
user: user.id,
name: user.name,
action: `додав користувача '${newMember.name}' до цієї дошки`,
});
})
);
newBoard.activity.unshift({ user: user._id, name: user.name, action: 'створив
цю дошку', color: user.color });
newBoard.members = allMembers;
await newBoard.save();
return callback(false, newBoard);
} catch (error) {
return callback({
errMessage: 'Щось пішло не так',
details: error.message,
});
}
};
const getAll = async (userId, callback) => {
try {
const user = await userModel.findById(userId);
const boardIds = user.boards;
const boards = await boardModel.find({ _id: { $in: boardIds } });
boards.forEach((board) => {
board.activity = undefined;
11
482.ЧДТУ 252153 21 01
board.lists = undefined;
});
return callback(false, boards);
} catch (error) {
return callback({ msg: 'Щось пішло не так', details: error.message });
}
};
const getById = async (id, callback) => {
try {
const board = await boardModel.findById(id);
return callback(false, board);
} catch (error) {
return callback({ message: 'Щось пішло не так', details: error.message });
}
};
const getActivityById = async (id, callback) => {
try {
const board = await boardModel.findById(id);
return callback(false, board.activity);
} catch (error) {
return callback({ message: 'Щось пішло не так', details: error.message });
}
};
const updateBoardTitle = async (boardId, title, user, callback) => {
try {
const board = await boardModel.findById(boardId);
board.title = title;
board.activity.unshift({
user: user._id,
name: user.name,
action: 'оновив заголовок цієї дошки',
color: user.color,
});
await board.save();
return callback(false, { message: 'Успіх!' });
} catch (error) {
return callback({ message: 'Щось пішло не так', details: error.message });
}
};
const updateBoardDescription = async (boardId, description, user, callback) => {
try {
const board = await boardModel.findById(boardId);
board.description = description;
board.activity.unshift({
user: user._id,
name: user.name,
action: 'оновив опис цієї дошки',
color: user.color,
});
await board.save();
return callback(false, { message: 'Успіх!' });
} catch (error) {
12
482.ЧДТУ 252153 21 01
return callback({ message: 'Щось пішло не так', details: error.message });
}
};
const updateBackground = async (id, background, isImage, user, callback) => {
try {
const board = await boardModel.findById(id);
board.backgroundImageLink = background;
board.isImage = isImage;
board.activity.unshift({
user: user._id,
name: user.name,
action: 'оновив фон цієї дошки',
color: user.color,
});
await board.save();
return callback(false, board);
} catch (error) {
return callback({ message: 'Щось пішло не так', details: error.message });
}
};
const addMember = async (id, members, user, callback) => {
try {
const board = await boardModel.findById(id);
await Promise.all(
members.map(async (member) => {
const newMember = await userModel.findOne({ email: member.email });
newMember.boards.push(board._id);
await newMember.save();
board.members.push({
user: newMember._id,
name: newMember.name,
surname: newMember.surname,
email: newMember.email,
color: newMember.color,
role: 'member',
});
board.activity.push({
user: user.id,
name: user.name,
action: `додав користувача '${newMember.name}' до цієї дошки `,
color: user.color,
});
})
);
await board.save();
return callback(false, board.members);
} catch (error) {
13
482.ЧДТУ 252153 21 01
return callback({ message: 'Щось пішло не так', details: error.message });
}
};
module.exports = {
create,
getAll,
getById,
getActivityById,
updateBoardTitle,
updateBoardDescription,
updateBackground,
addMember,
};
client/src/pages/BoardsPage/Boards.js
import LoadingScreen from "../../components/LoadingScreen";
import React, { useEffect, useState } from "react";
import { useDispatch, useSelector } from "react-redux";
import { getBoards } from "../../services/boards";
import Navbar from "../../components/Navbar";
import { Container, Wrapper, Title, Board, AddBoard } from "./Styled";
import CreateBoard from "../../components/Modals/CreateBoardModal/CreateBoard";
import { useNavigate } from "react-router";
import background from "../../images/boards-background.jpeg";
const Boards = () => {
const dispatch = useDispatch();
const navigate = useNavigate();
const { pending, boardsData } = useSelector((state) => state.boards);
const [openModal, setOpenModal] = useState(false);
const [searchString, setSearchString] = useState('');
const handleModalClose = () => {
setOpenModal(false);
};
const handleClick = (e) => {
navigate(`/board/${e.target.id}`)
}
useEffect(() => {
getBoards(false,dispatch);
}, [dispatch]);
return (
<>
{pending && <LoadingScreen />}
<Container background={background}>
<Navbar searchString={searchString} setSearchString={setSearchString} />
<Wrapper>
<Title>Ваші дошки</Title>
{!pending &&
boardsData.length>0 &&
14
482.ЧДТУ 252153 21 01
boardsData.filter(item=>searchString?item.title.toLowerCase().includes(searchStrin
g.toLowerCase()):true).map((item) => {
return (
<Board key={item._id} link={item.backgroundImageLink}
isImage={item.isImage} id={item._id} onClick={(e)=>handleClick(e)}>
{item.title}
</Board>
);
})}
{!pending && (
<AddBoard onClick={() => setOpenModal(true)}>
Нова дошка
</AddBoard>
)}
{openModal && <CreateBoard callback={handleModalClose} />}
</Wrapper>
</Container>
</>
);
};
export default Boards;
client/src/pages/BoardsPage/Styled.js
import styled from 'styled-components';
export const Container = styled.div`
background-image: url(${(props) => props.background});
background-position: 50%;
background-size: cover;
height: 100vh;
width: 100vw;
position: fixed;
top: 0;
left: 0;
`;
export const Title = styled.h1`
cursor: default;
font-weight: 400;
font-size: 1.5rem;
text-align: center;
width: 100vw;
margin-bottom: 1rem;
color: lightblue;
text-shadow: 3px 0px 7px rgba(81, 67, 21, 0.8), -3px 0px 7px rgba(81, 67, 21,
0.8),
0px 4px 7px rgba(81, 67, 21, 0.8);
user-select: none;
`;
export const Wrapper = styled.div`
15
482.ЧДТУ 252153 21 01
margin-top: 3.1rem;
width: 100%;
height: calc(100vh - 3.1rem);
padding: 1rem;
display: flex;
flex-direction: row;
justify-content: center;
align-items: center;
flex-wrap: wrap;
align-content: flex-start;
overflow-y: auto;
`;
export const Board = styled.div`
color: white;
padding: 0.6rem;
margin: 0 0.8rem 1rem 0.8rem;
width: 200px;
height: 120px;
border-radius: 5px;
${(props) =>
props.isImage ? 'background-image: url(' + props.link + ');' : 'background-
color: ' + props.link + ';'}
background-position: center center;
background-size: cover;
-webkit-box-shadow: rgba(0, 0, 0, 0.3) 0 1px 3px;
-moz-box-shadow: rgba(0, 0, 0, 0.3) 0 1px 3px;
box-shadow: rgba(0, 0, 0, 0.3) 0 1px 3px;
opacity: 88%;
cursor: pointer;
will-change: opacity;
transition: opacity 450ms;
&:hover {
opacity: 100%;
transition: opacity 150ms;
font-weight: 600;
}
`;
export const AddBoard = styled(Board)`
background-color: transparent;
background-image: linear-gradient(to right, #0b486b 0%, #f56217 51%, #0b486b
100%);
font-size: 1.2rem;
transition: 2s;
opacity: 65%;
background-size: 200% auto;
color: white;
display: flex;
align-items: center;
justify-content: center;
text-decoration: none;
font-weight: 600;
&:hover {
background-position: right center;
color: #fff;
16
482.ЧДТУ 252153 21 01
transition: 400ms ease-in;
}
`;
client/src/pages/LoginPage/Login.js
import React, { useState } from "react";
import { useDispatch } from "react-redux";
import { useNavigate } from "react-router-dom";
import { login } from "../../services/user";
import Background from "../../components/Background";
import {
BgContainer,
Container,
FormSection,
FormCard,
Form,
Title,
Input,
Button,
Hr,
Link, PageTitleContainer, PageTitle,
} from "./Styled";
const Login = () => {
let navigate = useNavigate();
const dispatch = useDispatch();
const [userInformations, setUserInformations] = useState({
email: "",
password: "",
});
const handleSubmit = (e) => {
e.preventDefault();
login(userInformations, dispatch);
};
return (
<>
<BgContainer>
<Background />
</BgContainer>
<Container>
<PageTitleContainer onClick={() => navigate("/")}>
<PageTitle>Kalaida V</PageTitle>
</PageTitleContainer>
<FormSection>
<FormCard>
<Form onSubmit={(e) => handleSubmit(e)}>
<Title>Вхід</Title>
<Input
type="email"
placeholder="Email"
required
value={userInformations.email}
onChange={(e) =>
17
482.ЧДТУ 252153 21 01
setUserInformations({
...userInformations,
email: e.target.value,
})
}
/>
<Input
type="password"
placeholder="Пароль"
required
value={userInformations.password}
onChange={(e) =>
setUserInformations({
...userInformations,
password: e.target.value,
})
}
/>
<Button>Увійти</Button>
<Hr />
<Link
fontSize="0.85rem"
onClick={() => navigate("/register")}
>
Зареєструватися
</Link>
</Form>
</FormCard>
</FormSection>
</Container>
</>
);
};
export default Login;
18
ДОДАТОК В
«WEB-застосунок для організації робочих процесів»
Графічні матеріали
482.ЧДТУ 252153 012 ПЗ
Листів 16
Розробник ________________ Калайда В.Р.
2025
482.ЧДТУ 252153 21 01
Рисунок В.1 – Тема роботи
Рисунок В.2 – Вступ
2
482.ЧДТУ 252153 21 01
Рисунок В.3 – Виконані задачі роботи
Рисунок В.4 – ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
3
482.ЧДТУ 252153 21 01
Рисунок В.5 – Огляд аналогів: Microsoft Planner
Рисунок В.6 – Огляд аналогів: Jira
4
482.ЧДТУ 252153 21 01
Рисунок В.7 – Мета, об’єкт та предмет роботи
Рисунок В.8 – Методи проєктування та конструювання
5
482.ЧДТУ 252153 21 01
Рисунок В.9 – Опис отриманих результатів
Рисунок В.10 – Практичне значення отриманих результатів
6
482.ЧДТУ 252153 21 01
Рисунок В.11 – Діаграма прецедентів
Рисунок В.12 – Діаграма класів
7
482.ЧДТУ 252153 21 01
Рисунок В.13 – Діаграма пакетів
Рисунок В.14 – Діаграма компонентів
8
482.ЧДТУ 252153 21 01
Рисунок В.15 – Діаграма розгортання
Рисунок В.16 – Діаграма діяльності
9
482.ЧДТУ 252153 21 01
Рисунок В.17 – Діаграма послідовності
Рисунок В.18 – Діаграма комунікації
10
482.ЧДТУ 252153 21 01
Рисунок В.19 – Діаграма скінченного автомату
Рисунок В.20 – Функціональна схема
11
482.ЧДТУ 252153 21 01
Рисунок В.21 – Блок-схема логічної роботи системи
Рисунок В.22 – Інтерфейс користувача: Головна сторінка
12
482.ЧДТУ 252153 21 01
Рисунок В.23 – Інтерфейс користувача: Реєстрація та авторизація
Рисунок В.24 – Інтерфейс користувача: Дошки
13
482.ЧДТУ 252153 21 01
Рисунок В.25 – Інтерфейс користувача: Дошка
Рисунок В.26 – Інтерфейс користувача: Історія дошки з налаштуваннями та
стовпчик
14
482.ЧДТУ 252153 21 01
Рисунок В.27 – Інтерфейс користувача: Картка
Рисунок В.28 – Тестування: модульне
15
482.ЧДТУ 252153 21 01
Рисунок В.29 – Тестування: інтеграційне
Рисунок В.30 – Фінальний слайд
16
482.ЧДТУ 252153 21 01
1