Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9026| Title: | Програмне забезпечення додатку модульного організатора задач та подій з можливістю індивідуального налаштування» |
| Authors: | Куницька, Світлана Юріївна Метелz, Данііл Андрійович |
| Keywords: | ВЕБ-ЗАСТОСУНОК;МОДУЛЬНА ОРГАНІЗАЦІЯ;ПЛАНУВАННЯ ЗАДАЧ;REACT;NEXT.JS;БАЗА ДАНИХ;АУТЕНТИФІКАЦІЯ;АВТОРИЗАЦІЯ;ІНТЕРФЕЙС КОРИСТУВАЧА;API;ТЕСТУВАННЯ;WEB APPLICATION;MODULAR ORGANIZATION;TASK PLANNING;REACT;NEXT.JS;DATABASE;AUTHENTICATION;AUTHORIZATION;USER INTERFACE;API;TESTING |
| Issue Date: | 17-Jun-2025 |
| Abstract: | АНОТАЦІЯ
Кваліфікаційна робота бакалавра на тему «Програмне забезпечення додатку модульного організатора задач та подій з можливістю індивідуального налаштування» містить 107 сторінок, 2 таблиці, 55 рисунків, список використаних джерел з 11 найменувань, 4 додатки.
Актуальність теми визначається потребою у розробці програмного забезпечення модульного додатку для планування задач та подій, що характеризується динамічністю, високою інтенсивністю інформаційних потоків та постійним зростанням кількості завдань, організація особистого часу та ефективне планування стають критично важливими як у повсякденному житті, так і в професійній діяльності. З огляду на це, попит на інструменти для управління задачами та подіями невпинно зростає.
Метою виконання кваліфікаційної роботи бакалавра є розробка застосунку для модульної організації та планування задач, який забезпечить ефективне управління завданнями, підвищить продуктивність користувачів та спростить процес планування.
Головні завдання при проектуванні інформаційної системи є аналіз вимог, розробка архітектури та інтерфейсу, моделювання даних, забезпечення безпеки, інтеграція API, тестування та документування.
Об'єктом роботи є процеси створення програмного забезпечення для модульної організації та планування задач, який включає інтерфейс користувача, серверну частину та базу даних для збереження і обробки інформації про завдання та користувачів. Предметом розробки є процеси побудови програмного забезпечення для модульної організації та планування задач, включаючи архітектуру системи, алгоритми управління завданнями та інтерфейс користувача.
Вирішено наступні поставлені задачі
1.
Розроблено архітектуру веб-застосунку для модульної організації та планування задач.
2.
Спроєктовано базу даних для зберігання інформації про завдання та користувачів.
3.
Реалізовано інтерфейс користувача з використанням Next.js і Tailwind CSS.
4.
Забезпечено аутентифікацію та авторизацію, а також протестовано функціональні можливості системи.
Практичне значення отриманих результатів. Розроблене програмне забезпечення для модульного організатора задач і подій з функцією індивідуального налаштування має суттєве прикладне значення. Система дозволяє ефективно управляти особистим та робочим часом, завдяки гнучкій структурі модулів, які можна адаптувати під конкретні потреби користувача.
Особистий внесок автора. Участь та публікація тез у міжнародній науково-практичній конференції «SCIENTIFIC, RESEARCH: MODERN CHALLENGES AND FUTURE PROSPECTS» Мюнхен, Німеччина, 9-11 червня 2025. ANNOTATION The bachelor's qualification work titled "Modular task and event organizer application software with customizable features" contains 107 pages, 2 tables, 55 figures, a list of references with 4 sources, and 5 appendices. The purpose of this bachelor's qualification work is to develop a web application for modular organization and task planning, which will ensure efficient task management, increase user productivity, and simplify the planning process. The main objectives in designing the information system include requirements analysis, architecture and interface development, data modeling, security provision, API integration, testing, and documentation. The object of the work is a web application for modular organization and task planning, which includes a user interface, server side, and a database for storing and processing information about tasks and users. The subject of the development is the methods and tools for creating a web application for modular organization and task planning, including system architecture, task management algorithms, and user interface. The following tasks were accomplished: 1. The architecture of the web application for modular organization and task planning was developed. 2. A database was designed to store information about tasks and users. 3. A user interface was implemented using Next.js and Tailwind CSS. 4. Authentication and authorization were provided, and the system's functionality was tested. Practical significance of the results. The developed software for a modular organizer of tasks and events with the function of individual customization has significant practical value. The system allows for effective management of personal and working time due to the flexible structure of modules that can be adapted to the specific needs of the user. Personal contribution of the author. Participation and publication of abstracts in the international scientific and practical conference “SCIENTIFIC, RESEARCH:MODERN CHALLENGES AND FUTURE PROSPECTS” Munich, Germany, 9-11 June 2025. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9026 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Метеля Данііл Андрійович.pdf Restricted Access | 1.65 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Програмне забезпечення додатку модульного організатора
задач та подій з можливістю індивідуального налаштування»
Виконав: студент 4 курсу, групи ПЗ-2104
спеціальності 121 «Інженерія програмного
забезпечення»
Студент Метеля Д.А.
(прізвище та ініціали)
Керівник Куницька С. Ю.
(прізвище та ініціали)
Рецензент Захарова М.В.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, д.т.н.,
професор
_________________ Сергій ГОЛУБ
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Метелі Даніілу Андрійовичу
1. Тема роботи: «Програмне забезпечення додатку модульного організатора задач та подій з
можливістю індивідуального налаштування»
Керівник роботи к.т.н., доцент Куницька Світлана Юріївна,
Затверджені наказом Черкаського державного технологічного університету №53/03-03
від «_25__» ____02________ 2025 року
2. Строк подання студентом роботи _____12/06/2025_______
3. Вхідні дані до роботи: модульний застосунок для планування та організації часу,
індивідуальне налаштування відображення даних.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результату дослідження у практику проектування програмного
забезпечення інформаційних систем
Розділ 3 Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Додаток А – Документація_________________________________________________
Додаток Б – Специфікація програми_________________________________________
Додаток В – Текст програми________________________________________________
Додаток Г – Презентаційний матеріал_______________________________________
6. Консультанти розділів роботи
7. Дата видачі завдання «_02_»________грудня__________2024р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 02.12.2024 виконано
2 Підготовка завдання 13.12.2024 виконано
3 Погодження завдання 16.12.2024 виконано
4 Затвердження завдання 19.02.2025 виконано
Основна стадія
1 Підбір матеріалів 27.02.2025 виконано
2 Аналіз шляхів вирішення поставленої 04.02.2025 виконано
задачі
3 Розрахунок основних параметрів роботи 10.03.2025 виконано
4 Вибір кінцевого варіанту проектного 17.03.2025 виконано
рішення
5 Оформлення первісної редакції роботи 25.03.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень 31.04.2025 виконано
з керівником
2 Оформлення пояснювальної записки 13.05.2025 виконано
роботи в кінцевій редакції
3 Попередній захист роботи 19.05.2025 виконано
4 Затвердження роботи
5 Рецензування роботи
6 Захист роботи 16.06.2025
Студент _____________________ Метеля Д. А.
Керівник роботи _____________________ Куницька С. Ю.
АНОТАЦІЯ
Кваліфікаційна робота бакалавра на тему «Програмне забезпечення додатку
модульного організатора задач та подій з можливістю індивідуального
налаштування» містить 107 сторінок, 2 таблиці, 55 рисунків, список використаних
джерел з 11 найменувань, 4 додатки.
Актуальність теми визначається потребою у розробці програмного
забезпечення модульного додатку для планування задач та подій, що
характеризується динамічністю, високою інтенсивністю інформаційних потоків та
постійним зростанням кількості завдань, організація особистого часу та ефективне
планування стають критично важливими як у повсякденному житті, так і в
професійній діяльності. З огляду на це, попит на інструменти для управління
задачами та подіями невпинно зростає.
Метою виконання кваліфікаційної роботи бакалавра є розробка застосунку
для модульної організації та планування задач, який забезпечить ефективне
управління завданнями, підвищить продуктивність користувачів та спростить
процес планування.
Головні завдання при проектуванні інформаційної системи є аналіз вимог,
розробка архітектури та інтерфейсу, моделювання даних, забезпечення безпеки,
інтеграція API, тестування та документування.
Об'єктом роботи є процеси створення програмного забезпечення для
модульної організації та планування задач, який включає інтерфейс користувача,
серверну частину та базу даних для збереження і обробки інформації про завдання
та користувачів.
Предметом розробки є процеси побудови програмного забезпечення для
модульної організації та планування задач, включаючи архітектуру системи,
алгоритми управління завданнями та інтерфейс користувача.
Вирішено наступні поставлені задачі
1. Розроблено архітектуру веб-застосунку для модульної організації та
планування задач.
2. Спроєктовано базу даних для зберігання інформації про завдання та
користувачів.
3. Реалізовано інтерфейс користувача з використанням Next.js і Tailwind CSS.
4. Забезпечено аутентифікацію та авторизацію, а також протестовано
функціональні можливості системи.
Практичне значення отриманих результатів. Розроблене програмне
забезпечення для модульного організатора задач і подій з функцією
індивідуального налаштування має суттєве прикладне значення. Система дозволяє
ефективно управляти особистим та робочим часом, завдяки гнучкій структурі
модулів, які можна адаптувати під конкретні потреби користувача.
Особистий внесок автора. Участь та публікація тез у міжнародній науково-
практичній конференції «SCIENTIFIC, RESEARCH: MODERN CHALLENGES
AND FUTURE PROSPECTS» Мюнхен, Німеччина, 9-11 червня 2025.
Ключові слова: ВЕБ-ЗАСТОСУНОК, МОДУЛЬНА ОРГАНІЗАЦІЯ,
ПЛАНУВАННЯ ЗАДАЧ, REACT, NEXT.JS, NEST.JS, БАЗА ДАНИХ,
АУТЕНТИФІКАЦІЯ, АВТОРИЗАЦІЯ, ІНТЕРФЕЙС КОРИСТУВАЧА, API,
ТЕСТУВАННЯ.
ANNOTATION
The bachelor's qualification work titled "Modular task and event organizer
application software with customizable features" contains 107 pages, 2 tables, 55 figures,
a list of references with 4 sources, and 5 appendices.
The purpose of this bachelor's qualification work is to develop a web application
for modular organization and task planning, which will ensure efficient task management,
increase user productivity, and simplify the planning process.
The main objectives in designing the information system include requirements
analysis, architecture and interface development, data modeling, security provision, API
integration, testing, and documentation.
The object of the work is a web application for modular organization and task
planning, which includes a user interface, server side, and a database for storing and
processing information about tasks and users. The subject of the development is the
methods and tools for creating a web application for modular organization and task
planning, including system architecture, task management algorithms, and user interface.
The following tasks were accomplished:
1. The architecture of the web application for modular organization and task planning
was developed.
2. A database was designed to store information about tasks and users.
3. A user interface was implemented using Next.js and Tailwind CSS.
4. Authentication and authorization were provided, and the system's functionality was
tested.
Practical significance of the results. The developed software for a modular
organizer of tasks and events with the function of individual customization has significant
practical value. The system allows for effective management of personal and working
time due to the flexible structure of modules that can be adapted to the specific needs of
the user.
Personal contribution of the author. Participation and publication of abstracts in
the international scientific and practical conference “SCIENTIFIC, RESEARCH:
MODERN CHALLENGES AND FUTURE PROSPECTS” Munich, Germany, 9-11 June
2025.
Keywords: WEB APPLICATION, MODULAR ORGANIZATION, TASK
PLANNING, REACT, NEXT.JS, NEST.JS, DATABASE, AUTHENTICATION,
AUTHORIZATION, USER INTERFACE, API, TESTING.
ВСТУП ................................................................ Ошибка! Закладка не определена.
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ ........................................................... Ошибка! Закладка не определена.
1.1 Сучасні підходи для планування часу ..... Ошибка! Закладка не определена.
1.2 Огляд веб-застосунків для організації та планування часу ................ Ошибка!
Закладка не определена.
1.3 Використання сучасних технологій для розв’язання поставленної задачі
......................................................................... Ошибка! Закладка не определена.
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ........ Ошибка! Закладка не определена.
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ............................................. Ошибка! Закладка не определена.
2.1 Моделювання предметної області ........... Ошибка! Закладка не определена.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області ..................................... Ошибка! Закладка не определена.
2.1.2 Модель предметної області ............... Ошибка! Закладка не определена.
2.1.3 Формування та аналіз вимог ............. Ошибка! Закладка не определена.
2.2 Формування та аналіз вимог .................... Ошибка! Закладка не определена.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги. Первинні та детальні вимоги ....... Ошибка! Закладка не определена.
2.2.2 Діаграма Прецедентів ........................ Ошибка! Закладка не определена.
2.3 Проектування логічної структури програмного комплексу ............... Ошибка!
Закладка не определена.
2.3.1 Діаграми класів .................................. Ошибка! Закладка не определена.
2.4 Архітектура проектування ....................... Ошибка! Закладка не определена.
2.4.1 Діаграма компонентів........................ Ошибка! Закладка не определена.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ................................................. Ошибка! Закладка не определена.
ЧДТУ 252160-012 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Метеля Д.А «Програмне забезпечення додатку Літ. Лист Листів
Пере вір. Куницька С.Ю. модульного організатора задач та подій з 3
Рецензент Захарова М.В. можливістю індивідуального
налаштування»
Н. Контр. Півень О.Б. ФІТІС, кафедра ПЗАС, ПЗ-2104
Пояснювальна записка.
Затверд. Голуб С.В.
2.5.3 Діаграма комунікації ............... Ошибка! Закладка не определена.
2.5.4 Діаграма скінченного автоматуОшибка! Закладка не
определена.
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ .....................Ошибка! Закладка не
определена.
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ............................................... Ошибка! Закладка не определена.
3.1 Розробка програмного комплексу.. Ошибка! Закладка не определена.
3.1.1 Обґрунтування вибору засобів реалізаціїОшибка! Закладка не
определена.
3.1.2 Опис структурної (функціональної) схемиОшибка! Закладка не
определена.
3.1.3 Опис логічної схеми ................ Ошибка! Закладка не определена.
3.1.4 Розробка бази даних ................ Ошибка! Закладка не определена.
3.1.5 Розробка інтерфейсу користувачаОшибка! Закладка не
определена.
3.1.6 Опис розробки програмних компонентівОшибка! Закладка не
определена.
3.2 Тестування системи ........................ Ошибка! Закладка не определена.
3.2.1 Модульне тестування .............. Ошибка! Закладка не определена.
3.2.2 Інтеграційне тестування .......... Ошибка! Закладка не определена.
3.2.3 Системне тестування ............... Ошибка! Закладка не определена.
3.2.4 Приймальне тестування ........... Ошибка! Закладка не определена.
3.3 Приклади впровадженого програмного комплексу Ошибка! Закладка
не определена.
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ....................Ошибка! Закладка не
определена.
ВИСНОВКИ ............................................. Ошибка! Закладка не определена.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ . Ошибка! Закладка не определена.
Додаток А ................................................. ОшЧДиТбУк а25!2 З16а0к-0л1а2 дПкЗа не определена.
Змн. Арк. № докум. Підпис Дата
Д одаток Б .......... .......... .............................. Ошибка! Закладка не определена.
Додаток В .................................................. Ошибка! Закладка не определена.
Додаток Г .................................................. Ошибка! Закладка не определена.
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Сучасні підходи до планування часу
Ефективне управління завданнями та подіями грає вагому роль в підвищенні
особистої продуктивності та організації часу. Основними кроками такого
управління є створення списків завдань, планування подій, розставлення
пріоритетів та відстеження прогресу виконання. Традиційні методи, наприклад,
запис завдань у паперовий блокнот або використання електронних таблиць, все ще
залишаються актуальними, але з розвитком технологій вони все частіше
доповнюються новими інноваційними підходами. Існують такі підходи:
- модульні органайзери задач – дозволяють користувачам створювати
персоналізовані рішення для управління задачами та подіями завдяки гнучкій
структурі та можливостям додавання або видалення модулів відповідно до
потреб;
- веб-додатки для управління часом – забезпечують автоматизацію планування
та нагадувань, синхронізацію із зовнішніми календарями й можливість
інтеграції з іншими інструментами для більш ефективної організації часу;
- хмарні сервіси для зберігання та доступу до задач – забезпечують доступ до
задач і подій із будь-якого пристрою, синхронізуючи дані в реальному часі
та забезпечуючи високий рівень безпеки.
1.2 Огляд веб додатків для організації часу та планування задач
Веб-додатки для організації задач і подій є важливим інструментом для
сучасних користувачів. Вони допомагають автоматизувати планування,
структурувати розклад і забезпечують доступ до важливої інформації у зручний
час. Популярні веб-додатки:
- Notion – це універсальний веб-додаток для організації роботи, який поєднує
функціонал для створення нотаток, управління задачами, ведення баз даних,
таблиць, календарів та інших інструментів. Він підтримує індивідуальне
налаштування робочих просторів, що робить його популярним серед
користувачів для особистого та командного використання. Переваги цього
застосунку: універсальність (підтримує нотатки, бази даних, списки справ,
вікі, календарі тощо.), гнучкість (легко налаштовується під особисті або
командні потреби), кросплатформеність (веб, мобільних пристроях та ПК).
Недоліки: може бути повільним (особливо при великій кількості даних або
на слабких пристроях), складний для новачків (потрібно час, щоб розібратися
у всіх можливостях).
Рисунок 1 – Вигляд веб-додатку Notion
- Trello – популярний інструмент управління задачами, побудований на базі
канбан-дошки. Користувачі можуть створювати проєкти, розбивати їх на
задачі й організовувати роботу за допомогою модулів, таких як списки та
картки. Переваги: простота у використанні (інтуїтивний інтерфейс на основі
канбан-дошок), візуальне управління задачами (зручно бачити статуси задач
у вигляді карток). Недоліки: обмеженість у масштабуванні (складно
керувати великими проєктами або командами), обмежені можливості
безкоштовної версії (багато функцій доступні лише в платному тарифі).
Рисунок 2 – Вигляд сайту Trello
- ClickUp – багатофункціональний веб-додаток для управління задачами,
планування часу та організації роботи. Додаток дозволяє персоналізувати
інтерфейс і функціонал відповідно до типу роботи (особисті задачі, командні
проєкти, стратегічне планування). Переваги: все в одному (завдання,
документи, цілі, трекер часу, календар тощо в одній платформі), потужна
кастомізація (статуси, поля, шаблони, автоматизації). Недоліки:
перевантажений інтерфейс (новачкам може бути складно швидко
розібратись), іноді повільна робота (особливо в складних або великих
робочих просторах).
Рисунок 3 – Вигляд сайту ClickUp
1.3 Використання сучасних технологій для розв’язання поставленої
задачі
Для створення веб-додатку "Програмне забезпечення додатку модульного
організатора задач та подій з можливістю індивідуального налаштування"
застосовуються сучасні технології, що забезпечують високу продуктивність,
гнучкість і зручність для користувачів:
1. Frontend:
- React (Next.js): Забезпечує швидку і зручну розробку інтерфейсу
користувача, підтримує компонентний підхід, що ідеально підходить для
створення модульних систем.
- Tailwind CSS: Надає можливість легко налаштовувати дизайн, адаптуючи
його до потреб користувача.
- TypeScript: Забезпечує надійну типізацію, що сприяє створенню стабільного
і передбачуваного коду.
2. Backend:
- Node.js із NestJS: Використовується для створення масштабованого
серверного додатку з організованою архітектурою.
- REST API або GraphQL: Надає можливість гнучкої взаємодії між
клієнтською і серверною частинами додатку.
3. База даних:
- PostgreSQL: Забезпечують надійне зберігання даних, підтримують складні
запити для організації подій і задач.
4. Безпека:
- Реалізація функцій аутентифікації та авторизації (наприклад, через OAuth2
або JWT) для захисту даних користувачів.
Ці інструменти дозволяють розробляти додаток, що зможе надавати
модульну архітектуру додатку.
1.3.1 Виклики і обмеження існуючих рішень
1. Обмеження персоналізації: багато існуючих додатків для організації задач
та подій, таких як Trello, Notion або ClickUp, хоча і пропонують значну
гнучкість у налаштуванні, часто мають обмеження щодо індивідуального
налаштування інтерфейсу або функціональності в межах певних шаблонів. У
деяких випадках додаткові функції потребують додаткових платних підписок
або складних налаштувань, що може бути не зручним для користувачів, які
хочуть мати доступ до всіх можливостей без додаткових витрат.
2. Продуктивність і швидкість: деякі додатки можуть страждати від проблем
із продуктивністю при великих обсягах даних, таких як велика кількість
задач, подій або складних інтеграцій. Це особливо помітно при обробці
великих обсягів даних, що може призвести до затримок у оновленні
інформації або ускладнити пошук і фільтрацію даних. Для веб-додатку, що
потребує високої продуктивності, важливо забезпечити оптимізовану
архітектуру та швидкий доступ до даних.
3. Інтеграція з іншими сервісами: хоча більшість сучасних додатків для
організації задач підтримують інтеграцію з іншими сервісами, такими як
календарі або інші системи управління проектами, реалізація таких
інтеграцій може бути обмежена. Наприклад, інтеграція може не охоплювати
всі популярні сервіси або бути складною у налаштуванні, що обмежує
можливості для персоналізації та автоматизації процесів.
4. Обмежена підтримка мобільних і десктопних версій: деякі додатки
можуть працювати добре в браузері, але їх мобільні версії можуть бути
недостатньо оптимізованими для користувачів, які потребують зручності в
мобільному використанні. Це може призводити до поганого користувацького
досвіду на мобільних пристроях, обмежуючи можливості для організації
задач та подій "на ходу".
5. Неоптимізовані функції планування та прогнозування: існуючі рішення,
як правило, добре справляються з обліком задач і подій, але відсутність більш
просунутих інструментів для прогнозування та автоматизації процесів може
бути значним обмеженням. Наприклад, можливість прогнозувати майбутні
задачі, оцінювати продуктивність або оптимізувати розклад за допомогою
машинного навчання є недоступною в більшості стандартних додатків для
планування.
6. Проблеми з масштабованістю: багато додатків не здатні ефективно
масштабуватися при збільшенні кількості користувачів або задач. Це може
бути обмеженням для тих, хто потребує організації завдань в рамках великих
команд або складних проектів з великою кількістю задач, етапів і підзадач.
Масштабованість є важливим аспектом для веб-додатку, що має на меті
працювати з великими обсягами даних.
ВИСНОВОК ДО РОЗДІЛУ 1
В першому розділі досліджено сучасні технології та шляхи організації часу і
розглянуто наявні веб-застосунки для управління завданнями.
Також обґрунтовано сучасні технології розробки веб-застосунків, які будуть
сприяти реалізації власного застосунку. Існує ряд викликів та обмежень у вже
наявних рішеннях, зокрема: відсутня досить низька адаптивність інтерфейсу,
обмежена масштабованість, використання складного методу налаштування,
відсутність підтримки модульного підходу організації завдань. Виходячи з мого
аналізу, вже існуючих рішень, я дійшов до думки розробки нового веб-застосунку,
який буде приймати сучасні вимоги користувачів, запропонує гнучкий функціонал
для модульного планування завдань і забезпечить ефективне управління часом із
обліком специфіки індивідуальної діяльності.
У розділі також проаналізовано сучасні технології веб-розробки, які можуть
бути використані для створення нового рішення. Зокрема, було відзначено
переваги використання таких технологій, як NextJS, TypeScript, Node.js/NestJS, що
забезпечують швидку розробку, масштабованість та високу продуктивність
застосунку. Окрему увагу приділено безпеці, адаптивності інтерфейсу та зручності
користування.
Також було визначено основні виклики при створенні подібних систем:
необхідність забезпечення стабільної роботи при зростанні обсягу даних,
створення інтуїтивно зрозумілого інтерфейсу користувача, забезпечення надійного
збереження інформації.
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТ ДОСЛІДЖЕННЯ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
Моделювання предметної області є важливою частиною створення веб-
додатку, що забезпечує організацію задач та подій з можливістю налаштування під
індивідуальні потреби користувачів. Це моделювання дозволяє визначити основні
об'єкти системи, їх властивості, взаємозв'язки та дії, які можуть бути виконані над
ними. Для розробки такого додатку потрібно враховувати кілька ключових
аспектів.
Моделювання є важливим етапом у створенні веб-додатку для організації
задач та подій з можливістю індивідуального налаштування. Визначення основних
сутностей, їх властивостей та взаємозв'язків допомагає забезпечити чітку та
ефективну структуру додатку, що дозволяє користувачам зручно управляти своїми
задачами, подіями та проектами.
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання для веб-додатку, що дозволяє організувати
задачі та події з індивідуальним налаштуванням, включає сутності, взаємозв'язки
між ними, а також правила та функціональні можливості, які визначають поведінку
додатку. Основною метою є забезпечення користувача зручним інтерфейсом для
ефективного управління задачами та подіями, а також надання можливості
налаштовувати додаток під індивідуальні потреби.
Модель предметної області
Рисунок 4 – Діаграма бази даних
Модель предметної області мого веб-додатку описує основні об'єкти та
взаємозв'язки, що регулюють процеси організації та управління задачами та
подіями в системі. Вона забезпечує структуру для збору, обробки, зберігання та
аналізу даних користувачів, а також надає можливість персоналізації інтерфейсу та
налаштувань для оптимізації управління часом і завданнями. Модель предметної
області відображає основні елементи, з якими користувач взаємодіє в додатку.
Словник предметної області
Колекція даних – набір сутностей (полів, колонок, значень), які об’єднав
користувач у єдиному місці по певним характеристикам.
Користувач – особа, що взаємодіє з системою через інтерфейс додатку. Має
власний акаунт та колекції даних.
Календар - інтерфейсна та логічна частина системи, що відображає задачі й
події у форматі календаря (день, тиждень, місяць).
Аутентифікація/Авторизація - процес перевірки особи користувача під час
входу в систему.
Інтерфейс користувача (UI) - графічне середовище, через яке користувач
взаємодіє з системою: форми, кнопки, вікна, списки. Клієнтська частина додатку.
DTO (Data Transfer Object) - об'єкт, призначений для перенесення даних між
різними шарами (рівнями) програми або між клієнтом і сервером. DTO не містить
бізнес-логіки — лише структуровані дані.
Репозиторій – програмний компонент, який відповідає за доступ до бази
даних.
Сервіс - логічний рівень застосунку, що містить реалізацію бізнес-логіки.
Контролер - компонент програмної архітектури, який приймає запити від
користувача або клієнтської частини системи, передає дані до відповідного сервісу
для обробки, а потім формує відповідь.
Layer (Рівень архітектури) - логічне розділення системи на частини
відповідно до їх функцій.
2.1.2 Елементи моделювання предметної області
Моделювання предметної області є ключовим етапом у процесі розробки
програмного забезпечення, що дозволяє формалізувати знання про систему,
визначити її структуру, сутності та взаємозв’язки між ними.
На цьому етапі здійснюється абстрагування від технічної реалізації та
зосередження уваги на логіці предметної області, що є фундаментом для
подальшого проєктування архітектури системи.
Основними елементами моделювання предметної області є сутності
(об'єкти), атрибути, зв’язки, а також правила і обмеження, що визначають
поведінку системи.
1. Користувач (User)
Опис: Представляє індивідуального користувача веб-додатку, який
взаємодіє з організатором задач та подій
Атрибути:
- ідентифікатор користувача (UserID);
- логін (username);
- імя;
- прізвище;
- email;
- пароль;
2. Відображення (View)
Опис: Сутність, яка групує дані користувача за потрібною йому
семантичною значимістю. Користувач створює набори відображення і заповнює їх
до відповідної йому тематики
Атрибути:
- ідентифікатор відображення (ViewID);
- назва (Name);
- формати відображення (Formats);
- дані (Columns, Records);
- дата створення (Created At);
- дата редагування (Updated At);
- індентифікатор користувача (UserID);
3. Колонки (Columns)
Опис: Сутність для налаштування колонок у певному View. Дозволяє
користувачу налаштовувати набір колонок для відображення даних за їх типом.
Атрибути:
- ідентифікатор колонки (ColumnID);
- назва колонки (Name);
- тип даних колонки (Data Type);
- дата створення (Created At);
- дата редагування (Updated At);
- ідентифікатор відображення (ViewID);
4. Рядки (Rows)
Опис: Сутність, яка групує записи у відповідні рядки.
Атрибути:
- ідентифікатор рядка (ID);
- ідентифікатор відображення (ViewID);
5. Строкові значення (RowValues)
Опис: Сутність, яка зберігає значення рядків.
Атрибути:
- ідентифікатор значення (ID) ;
- ідентифікатор рядка (RowID) ;
- значення (Value) ;
- індетифікатор колонки (ColumnID) ;
Взаємозв'язки між об'єктами:
1. Користувач (User) ↔ Задача (View)
- користувач може створювати, редагувати або видаляти відображення. Кожне
відображення належить конкретному користувачу;
- відображення має атрибут UserID, який вказує на ідентифікатор користувача,
що її створив або з яким вона пов'язана;
Взаємозв'язок: 1 користувач → багато відображень (One-to-Many)
2. Відображення (View) ↔ Колонки (Columns)
- відображення можуть бути пов'язані з конкретними колонками;
- кожна колонка може бути прив'язана до одного відображення;
Взаємозв'язок: багато колонок ↔ одне відображення (Many-to-One)
3. Строки (Rows) ↔ Відображення (Views)
- кожен строка має бути прив’язана до конкретного відображення;
Взаємозв'язок: багато строк → 1 відображення (Many-to-One)
4. Строкові значення (RowValues) ↔ Строки (Rows)
- кожне строкове значення на лежить до певної строки;
- Кожна строка може містити багато строкових значень;
Взаємозв'язок: багато строкових значень → 1 строка (Many-to-One)
5. Строкові значення (RowValues) ↔ Колонок (Columns)
- кожне строкове значення належить до певної колонки;
Взаємозв'язок: багато строкових значень ↔ 1 колонка (Many-to-One)
2.1.3 Робоча область моделювання
Робоча область моделювання є концептуальним та візуальним простором, у
межах якого здійснюється побудова моделей програми. Вона об’єднує всі необхідні
елементи, інструменти та зв’язки, які використовуються для представлення
предметної області, визначення її структури, поведінки та функціональних
взаємозв’язків між компонентами.
Основною метою формування робочої області є створення централізованої
структури, яка охоплює всі логічні частини майбутнього застосунку. Також у
робочій області розміщуються UML-діаграми, що відображають різні аспекти
системи: структуру, поведінку, потоки даних, логіку взаємодії. Діаграму вже
сформованої області моделювання можна переглянути на рисунку 4.
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
1. Первинні вимоги – це загальні очікування від системи, що
формуються на основі потреб користувачів:
- додаток має допомагати користувачам відслідковувати, планувати та
створювати власні задачі;
- інтерфейс додатку повинен бути зручним, інтуїтивно зрозумілим та
доступним для широкого кола користувачів;
2. Детальні вимоги уточнюють конкретні аспекти системи:
- додаток має підтримувати можливість створення декількох
відображень для різних наборів даних;
- функція створення нового запису та нової колонки;
- підтримка відображення наборів даних у різних виглядаха;
- функція редагування та видалення записів;
Вимоги замовника і розробника.
У процесі розробки програми виникають дві основні групи вимог: вимоги
замовника та вимоги розробника.
Вимоги замовника – це вимоги, які замовник висуває щодо
функціональності програми. Зазвичай вони описують, що додаток має робити для
кінцевого користувача:
- можливість створювати власні набори відображень до конкретних даних;
- простота використання та зручність інтерфейсу для швидкого доступу до
основних функцій;
- підтримка різних типів даних для роботи з плануванням (дати, селекти та ін.) ;
Вимоги розробника включають технічні аспекти, які забезпечують
ефективну роботу програми:
- використання сучасних технологій для створення ефективного веб-
застосунку;
- створення зручного і продуктивного коду, який легко підтримувати і
масштабувати;
- дотримання стандартів безпеки для захисту персональних даних
користувачів;
Функціональні та нефункціональні вимоги
1. Функціональні вимоги визначають конкретні функції, які повинна
виконувати система:
- можливість реєстрації та авторизації користувачів з використанням
пароля;
- інтерфейс для додавання, редагування і видалення записів в
відображенні;
- функціонал для побудови колонок, записів та відображень.
- автоматичне оновлення даних, після їх редагування, створення або
видалення;
2. Нефункціональні вимоги включають вимоги до продуктивності, безпеки,
надійності та доступності програми:
- продуктивність: додаток має забезпечувати швидкий доступ до даних
користувача та оперативну обробку транзакцій;
- безпека: всі записи щодо задач повинні бути лише у користувача, який
їх створив;
- надійність: додаток повинен забезпечувати безперервну роботу та
коректну обробку даних;
- зручність: додаток повинен мати інтуїтивно зрозумілий інтерфейс з
мінімальним навчанням для користувачів;
2.2.2 Діаграма Прецедентів.
Рисунок 5 – Діаграма прецедентів
Опис Прецедентів
Основні прецеденти, що відображають функціональні можливості
мобільного додатку, можуть бути такими:
1. Реєстрація та авторизація користувача
- актори: новий користувач;
- опис: користувач створює обліковий запис, надаючи ім'я, електронну пошту
та пароль. Після реєстрації користувач входить до системи через електронну
пошту та пароль;
- кроки:
1. Користувач вводить свої дані (ім'я, email, пароль).
2. Підтверджує реєстрацію через email (якщо це необхідно).
3. Користувач входить в систему для доступу до своїх задач і подій.
- результат: Користувач успішно зареєстрований і має доступ до особистого
кабінету;
2. Створення задачі
- актори: зареєстрований користувач;
- опис: користувач створює нову задачу для себе, вказуючи її назву, опис,
пріоритет, термін виконання та категорію;
- кроки:
1. Користувач натискає кнопку "Створити задачу".
2. Вводить назву, опис, дату виконання, пріоритет та категорію.
3. Натискає "Зберегти", і задача додається до списку.
- результат: задача успішно створена і збережена в системі;
3. Редагування задачі
- актори: зареєстрований користувач;
- опис: користувач редагує раніше створену задачу, змінюючи її статус, дату
виконання, опис або пріоритет;
- кроки:
1. Користувач знаходить задачу в списку.
2. Користувач натискає "Редагувати" і вносить зміни.
3. Користувач зберігає зміни.
- результат: задача оновлена з новими даними;
4. Видалення задачі
- актори: зареєстрований користувач;
- опис: користувач може видаляти задачі або події, які більше не потрібні;
- кроки:
1. Користувач вибирає задачу або подію, яку потрібно видалити.
2. Натискає "Видалити".
3. Підтверджує дію.
- результат: Задача або подія видаляється з системи;
2.3 Проектування логічної структури програмного комплексу
2.3.1 Діаграми класів
Рисунок 6 – Діаграма класів
Опис кожної таблиці бази даних, представленої в діаграмі класів:
1. User
- атрибути: ID, username, email, password, firstName, lastName, createdAt;
2. Views
- атрибути: ID, name, formats, data, createdAt, userID, lastModified;
3. Columns
- Атрибути: ID, name, dataType, createdAt, updatedAt, viewID;
4. Rows
- атрибути: ID, viewID;
5. RowValues
- атрибути: ID, rowID, columnID, value;
2.3.2 Діаграма пакетів
Ця діаграма демонструє архітектуру веб-застосунку, побудовану за
принципом клієнт-сервер. Клієнтська частина включає UI-компоненти, сторінки та
middleware для автентифікації. Вона взаємодіє з серверною частиною,
реалізованою на основі NestJS, де розміщені контролери, сервіси, модулі, DTO та
репозиторії. Сервер обробляє запити і працює з базою даних PostgreSQL, яка
зберігає інформацію про користувачів, події, рядки, стовпці та їх значення. Уся
система розгорнута в Docker-контейнерах, що містять як бекенд, так і базу даних.
Рисунок 7 – Діаграма пакетів
2.4 Архітектурне проектування
2.4.1 Діаграма компонентів
Рисунок 8 – Діаграма компонентів
Основні компоненти:
1. Клієнтський застосунок (Client App):
- опис: компонент, відповідальний за взаємодію з користувачем через браузер.
Виконує відображення інформації, отримання введених даних, відправлення
запитів на проміжний сервер та відображення результатів;
- підкомпоненти: екран аутентифікації, екран завдань, екран категорій, екран
тегів, екран налаштувань;
2. API Gateway Сервер:
- опис: приймає запити від клієнта, виконує обробку маппінг даних, здійснює
зв'язок з основним сервером;
- підкомпоненти: маппери дани;
3. Backend (Server)
- опис: Приймає запити, виконує бізнес логіку;
- підкомпоненти: Модулі, контролери, сервіси;
4. База даних (Database):
- опис: Зберігає сутності та дані.
- підкомпоненти: таблиці, користувачі, теги, категорії, завдання,
налаштування;
Зв'язки між компонентами:
- кієнтський додаток ↔ API Gateway: відправлення запитів та отримання
відповідей;
- API Gateway ↔ API сервер: відправлення даних та отримання результатів.
- API Сервер ↔ база даних: запити до бази даних для запису, отримання та
обробки інформації.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Рисунок 9 – Діаграма розгортання
Опис розгортання програмної системи на апаратних засобах:
Для розробки додатку веб-додатку можна передбачити таку архітектуру
розгортання, яка включає наступні апаратні та програмні ресурси:
1. Клієнтський застосунок
- призначення: Забезпечення взаємодії користувача із системою через
мобільний або веб-додаток. Відповідає за візуалізацію даних та обробку дій
користувача., відображати фінансову інформацію, рекомендації, аналітику;
- програмне забезпечення: Фреймворк Next.js для побудови клієнтського
застосунку;
2. Back-end
- програмне забезпечення: Node.js для обробки запитів, виконання бізнес-
логіки та надсилання відповідей;
- API: Інтерфейс, що забезпечує обробку запитів від клієнтського додатку та
відправку відповідей;
3. База даних:
- зберігання даних: база даних (наприклад, PostgreSQL або MongoDB) для
зберігання інформації про користувачів, завдання, тегів та інші дані, пов'язані
з особистими налаштуваннями користувача;
Діаграма розгортання:
Діаграма розгортання може включати такі вузли та зв’язки між ними:
- клієнтський додаток, що взаємодіє з: сервером, на який надсилає запити
для збереження, видалення або редагування даних;
- сервер: має зв'язок з базою даних для зберігання та отримання даних.,
взаємодіє з клієнтським додатком для обробки даних та збереження даних
в базі даних;
2.5 Моделювання поведінки системи
2.5.1 Діаграма діяльності
Опис діаграми діяльності:
1. Початок роботи з додатком:
- користувач запускає додаток – початковий етап, коли користувач
відкриває веб-додаток;
- авторизація / реєстрація – перевірка існуючого облікового запису або
створення нового акаунту;
2. Основний інтерфейс додатку:
- головна сторінка – відображення основної сторінки, відображення
швидких дій для користувача та відображення основної інформації;
- вибір дії – користувач обирає одну з функцій: cтворити нове завдання,
проглянути існуючи завдання, редагувати завдання, видалити
завдання;
Рисунок 10 – Діаграма діяльності
3. Початок роботи з додатком:
- користувач запускає додаток – початковий етап, коли користувач
відкриває веб-додаток;
- авторизація / реєстрація – перевірка існуючого облікового запису або
створення нового акаунт;
4. Основний інтерфейс додатку:
- головна сторінка – відображення основної сторінки, відображення
швидких дій для користувача та відображення основної інформації;
- вибір дії – користувач обирає одну з функцій: cтворити нове завдання,
проглянути існуючи завдання, редагувати завдання, видалити
завдання;
5. Додавання нового завдання:
- введення назви завдання – користувач заповнює назву завдання;
- додаткові опціональні поля – додає додаткові значення в завданні
(категорія, статус та ін.) ;
6. Проглянути список завдань:
- список завдань – користувач відкриває список з існуючими
завданнями;
7. Редагувати завдання:
- відкрити потрібне завдання – користувач відкриває потрібне
завдання.
- редагування необхідних полів – користувач змінює значення в
потрібних йому полях;
8. Видалити завдання
- видалення завдання – користувач обирає, який запис хоче видалити
та підтверджує свої дії;
9. Вихід з додатку
- завершення сесії – користувач виходить з додатку;
2.5.2 Діаграма послідовності
Основні етапи взаємодії описані нижче:
1. Авторизація користувача
- запуск додатка – користувач відкриває додаток для початку роботи;
- облікові дані – перевіряється наявний обліковий запис або виконується
реєстрація нового;
- доступ до інтерфейсу – після успішного входу відкривається основний
інтерфейс додатка;
Рисунок 11 – Діаграма послідовності
2. Додавання завдання
- користувач обирає функцію "Додати нове завдання";
- користувач вводить основні поля: назва;
- користувач натискає на кнопку «Створити завдання» і відображається
результат;
3. Редагування завдання
- ініціювання редагування – користувач відкриває завдання, яке потрібно
змінити;
- отримання даних завдання – система завантажує актуальну інформацію
про завдання з бази даних;
- редагування параметрів – користувач вносить зміни до назви, тегів, статусу
або інших полів завдання;
- збереження змін – оновлені дані передаються до серверу, де система
оновлює їх у базі даних;
- відображення результату – користувач бачить оновлене завдання з
актуальними змінами;
4. Видалення завдання
- ініціювання видалення – користувач вибирає завдання та натискає опцію
видалення;
- підтвердження дії – система запитує підтвердження видалення для
запобігання випадковим діям;
- видалення даних – після підтвердження система передає запит на сервер для
видалення завдання з бази даних;
- оновлення інтерфейсу – інтерфейс користувача автоматично оновлюється,
видаляючи завдання зі списку;
5. Вихід з системи
- користувач ініціює вихід з системи;
- сессія закінчується – користувач повертається на сторінку авторизації;
2.5.3 Діаграма комунікації
Рисунок 12 – Діаграма комунікації
Основні етапи взаємодії:
1. Авторизація користувача
- мета: забезпечити перевірку прав доступу користувача до додатку;
- ключові кроки:
1. Користувач вводить свої облікові дані в інтерфейсі додатку.
2. Інтерфейс надсилає запит на авторизацію до контролера.
3. Контролер здійснює перевірку облікових даних у базі даних.
4. База даних повертає результат перевірки (успішна авторизація або
помилка), який контролер передає назад до інтерфейсу
2. Додавання нової транзакції
- мета: додати інформацію про нову транзакцію в систему;
- ключові кроки:
1. Користувач вводить деталі транзакції через інтерфейс.
2. Інтерфейс передає запит на збереження транзакції контролеру додатку.
3. Контролер додає транзакцію в базу даних.
4. База даних підтверджує успішне збереження, контролер оновлює
баланс і передає інформацію інтерфейсу.
3. Створення нового завдання
- мета: додати нове завдання до списку задач користувача;
- ключові кроки:
1. Користувач вводить дані для нового завдання (назва, тег, статус та
інше) через інтерфейс додатку.
2. Інтерфейс передає запит на створення нового завдання до контролера
додатку.
3. Контролер обробляє отримані дані та зберігає їх у базі даних.
4. База даних повертає підтвердження успішного створення завдання, яке
контролер надсилає до інтерфейсу.
5. Інтерфейс оновлює список задач, відображаючи нове
завдання.користувачу.
4. Редагування завдання
- мета: оновити інформацію про вибране завдання;
- ключові кроки:
1. Користувач відкриває завдання та вносить зміни (назва, тег, статус
тощо) через інтерфейс додатку.
2. Інтерфейс передає запит на редагування завдання до контролера.
3. Контролер отримує оновлені дані та оновлює відповідний запис у базі
даних.
4. База даних повертає підтвердження успішного оновлення, яке
контролер передає інтерфейсу.
5. Інтерфейс оновлює відображення завдання з урахуванням внесених
змін
5. Видалення завдання
- мета: видалити вибране завдання зі списку задач;
- ключові кроки:
1. Користувач вибирає завдання та ініціює запит на його видалення через
інтерфейс додатку.
2. Інтерфейс передає запит на видалення завдання до контролера.
3. Контролер надсилає команду на видалення відповідного запису з бази
даних.
4. База даних підтверджує успішне видалення, після чого контролер
передає цю інформацію інтерфейсу.
5. Інтерфейс оновлює список задач, видаляючи вибране завдання.
2.5.4 Діаграма скінченого автомату
Опис основних компонентів діаграми взаємодії:
1. Користувач – взаємодіє з додатком, виконуючи дії, такі як авторизація,
створення транзакцій, запуск аналізу чи прогнозування.
2. Інтерфейс – візуальна частина додатку, яка дозволяє користувачу вводити
інформацію та отримувати результати у зручній формі.
3. Сервер – обробляє бізнес-логіку, приймає запити від інтерфейсу, працює з
базою даних і виконує обчислення за допомогою моделі машинного
навчання.
4. База даних – відповідає за збереження інформації про користувачів,
транзакції, налаштування та інші дані системи.
Рисунок 13 – Діаграма скінченого автомату
Основні сценарії взаємодії в діаграмі:
1. Авторизація користувача
- процес: Користувач намагається увійти в систему через клієнт;
- послідовність:
1. Користувач вводить логін і пароль.
2. Інтерфейс передає дані серверу для авторизації.
3. Сервер звертається до бази даних для перевірки облікових даних.
4. База даних відповідає успішним входом або повідомленням про
помилку.
5. Сервер повертає інформацію інтерфейсу, який повідомляє користувача
про результат авторизації. Клієнтський застосунок – опрацьовує
помилку.
2. Створення нового завдання
- процес: користувач додає нове завдання через клієнтський застосунок;
- послідовність:
1. Користувач вводить дані нового завдання (назва, опис, тег, статус
тощо) в інтерфейсі.
2. Інтерфейс передає введені дані на сервер для створення завдання.
3. Сервер обробляє отримані дані та передає їх у базу даних для
збереження.
4. База даних зберігає нове завдання та надсилає підтвердження про
успішне створення. Сервер повертає відповідь інтерфейсу, який
оновлює список задач і повідомляє користувача про успішне створення
завдання або обробляє помилку.
3. Редагування завдання
- процес: Користувач змінює інформацію про існуюче завдання через
клієнтський застосунок;
- послідовність:
1. Користувач вибирає завдання та вносить зміни (назва, опис, тег, статус
тощо) в інтерфейсі.
2. Інтерфейс передає оновлені дані на сервер для редагування завдання.
3. Сервер отримує нову інформацію та оновлює відповідний запис у базі
даних.
4. База даних підтверджує успішне оновлення даних завдання.
5. Сервер повертає відповідь інтерфейсу, який оновлює відображення
завдання та повідомляє користувача про успішне редагування або
обробляє помилку.
4. Видалення завдання
- процес: користувач видаляє завдання з клієнтського застосунку;
- послідовність
1. Користувач вибирає завдання для видалення через інтерфейс додатку.
2. Інтерфейс передає запит на видалення завдання на сервер.
3. Сервер обробляє запит і видаляє відповідний запис з бази даних.
4. База даних підтверджує успішне видалення завдання.
5. Сервер повертає відповідь інтерфейсу, який оновлює список завдань та
повідомляє користувача про успішне видалення або обробляє помилку.
5. Налаштування бюджету та сповіщень
- процес: користувач налаштовує бюджетні ліміти та сповіщення;
- послідовність:
1. Користувач вказує налаштування через інтерфейс.
2. Інтерфейс надсилає дані контролеру для збереження.
3. Контролер оновлює відповідні налаштування в базі даних.
4. База підтверджує збереження, і контролер передає це інтерфейсу.
5. Інтерфейс повідомляє користувача про успішне збереження
налаштувань.
ВИСНОВОК ДО РОЗДІЛУ 2
У другому розділі було здійснено впровадження результатів дослідження у
практику проєктування програмного забезпечення. Проведено детальне
моделювання предметної області, побудовано модель предметної області,
сформовано словник основних термінів.
Це дозволило краще зрозуміти специфіку завдань, які вирішує система, та
визначити ключові сутності для її реалізації. Були сформульовані первинні та
деталізовані вимоги до програмного забезпечення, з урахуванням побажань
замовника та технічних обмежень.
Визначено функціональні та нефункціональні вимоги, що стали основою для
побудови UML-діаграм. На основі вимог побудовано діаграму прецедентів, яка
відображає взаємодію користувачів із системою. Виконано проєктування об'єктно-
орієнтованої структури застосунку за допомогою діаграм класів, що дозволило
визначити основні об'єкти, їх атрибути та зв’язки. Основними класами додатку є:
Task, View, User та Calendar. Було визначено атрибути кожного класу, а також їх
методи. Наприклад, клас Task включає поля: назва, опис, колонки, дані, а також
методи для створення, редагування і видалення. Зв’язки між класами реалізують
асоціації, композицію та наслідування, що забезпечує розширюваність і повторне
використання компонентів.
Також розроблено архітектуру застосунку та побудовано поведінкові
діаграми: діаграму діяльності, діаграму послідовності, діаграму комунікації та
діаграму скінченого автомату.
Діаграма пакетів описує логічне групування класів у відповідні пакети
(модулі). Такий поділ забезпечує модульність, підтримку принципу розділення
відповідальностей та полегшує тестування і супровід.
Діаграма послідовності ілюструють порядок взаємодії об’єктів у часі для
конкретних сценаріїв, таких як створення нової задачі, авторизація або
налаштування подій.
Діаграма комунікації відображає ті самі сценарії, що й послідовності, але
акцентує увагу на структурі взаємозв’язків між об'єктами. Наприклад, при
налаштуванні колекції даних, користувач взаємодіє з інтерфейсом UI, який передає
запит у відповідний сервіс, що далі опрацьовує інформацію через доступ до
репозиторіїв.
Діаграма скінченого автомату описує зміну станів системи або об'єктів
залежно від дій користувача або внутрішніх подій.
Діаграма діяльності демонструє алгоритм виконання операцій та сценарії
використання, наприклад: процес реєстрації нового користувача, створення задачі.
Діаграма компонентів відображає архітектурну структуру системи на рівні
логічних компонентів: інтерфейс користувача, сервісна логіка (business logic), база
даних.
Всі ці діаграми описують логіку роботи системи, порядок виконання дій та
сценарії взаємодії між компонентами системи. Усі побудовані моделі та діаграми
слугували фундаментом для подальшої реалізації програмного забезпечення на
етапі розробки.
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
Розробка програмного комплексу є основним етапом у розробці мого
застосунку, на якому проєктні рішення трансформуються у конкретну реалізацію.
На основі результатів моделювання, аналізу вимог, а також створених UML-
діаграм було здійснено поетапне створення веб-застосунку для планування задач
та подій, який забезпечує гнучке управління часом та персональну адаптацію під
потреби користувача.
Основною метою розробки було створення функціонального, інтуїтивно
зрозумілого та масштабованого застосунку, який дозволяє користувачам
ефективно планувати свою діяльність, контролювати виконання задач, отримувати
нагадування та змінювати налаштування відповідно до власних уподобань.
Система реалізована за принципами багаторівневої архітектури, що
забезпечує модульність, ізольованість компонентів і можливість розширення.
Основні компоненти системи:
- UI – забезпечує взаємодію з кінцевим користувачем;
- cервісний рівень - обробляє запити користувача, реалізує бізнес-логіку;
- контролери: координують передачу даних між UI та сервісами;
- DTO - використовуються для передачі структурованих даних між клієнтом і
сервером;
- репозиторії - реалізують доступ до бази даних;
3.1.1 Обґрунтування вибору засобів реалізації
У процесі розробки програмного забезпечення особливо важливо правильно
обрати технологічний стек, який забезпечує ефективну розробку, масштабованість,
підтримуваність та хорошу продуктивність системи. Для реалізації клієнтської
частини було обрано Next.js, а для серверної – NestJS.
Вибір програмних та апаратних засобів для реалізації проєкту здійснювався
з урахуванням вимог до продуктивності, масштабованості, модульності та
зручності підтримки веб-застосунку. Основними критеріями були швидкодія
інтерфейсу, ефективна обробка запитів на сервері, а також можливість легкої
інтеграції з базою даних та зовнішніми сервісами.
У якості середовища для клієнтської частини було обрано Next.js, який є
одним із найпопулярніших фреймворків для розробки веб-інтерфейсів на основі
React. Next.js забезпечує підтримку серверного рендерингу, статичної генерації
сторінок та оптимізацію продуктивності, що особливо важливо для сучасних
застосунків з великою кількістю динамічного контенту. Основною мовою
програмування для реалізації як клієнтської, так і серверної частини було обрано
TypeScript. Ця мова забезпечує безпеку типів, зручність при рефакторингу та
підвищує надійність коду, що є особливо важливим у великих проєктах. Завдяки
використанню TypeScript в обох частинах застосунку вдалося забезпечити
узгодженість типів між фронтендом і бекендом, що зменшує кількість помилок на
етапі виконання.
Nest.js підтримує модульну структуру, впровадження залежностей, а також
має інтеграцію з ORM-бібліотеками, зокрема TypeORM. Це дозволяє ефективно
працювати з базами даних і реалізовувати REST API з чітким розділенням логіки
за відповідальністю. Крім того, Nest.js надає можливість розширення
функціональності за допомогою middleware, guard-ів, інтерсепторів і декораторів,
що дозволяє гнучко налаштовувати обробку запитів. Для зберігання даних
використовувалася реляційна база даних PostgreSQL, яка забезпечує надійність,
високу продуктивність та підтримку складних запитів. Інтеграція з нею була
реалізована за допомогою TypeORM, що дозволило зручно працювати з моделями
даних у TypeScript-середовищі.
Апаратне середовище для розробки включає персональний комп’ютер із
сучасним багатоядерним процесором, 16 ГБ оперативної пам’яті та твердотілим
накопичувачем (SSD), що забезпечує швидку компіляцію, запуск застосунків та
виконання тестів.
Тестування клієнтської частини здійснювалося в актуальних версіях
браузерів (Google Chrome, Firefox), а серверна частина розгорталася у середовищі,
подібному до майбутнього продакшн-середовища — Docker-контейнерах. Для
забезпечення оптимізації процесу розробки, а також контролю якості коду
використовувалися сучасні інструменти, зокрема ESLint, Prettier, Vitest, а також
Postman для перевірки роботи API. Таким чином, вибір інструментів реалізації був
зумовлений потребою створення надійного, масштабованого та продуктивного
веб-застосунку, орієнтованого на сучасні вимоги до фронтенду та бекенду.
3.1.2 Опис функціональної схеми
На рисунку 14 зображено функціональну схему взаємодії клієнтської та
серверної частин у процесі отримання та обробки даних. У запропонованій
архітектурі застосунку ключовими компонентами є користувач, інтерфейс клієнта
(Next.js), серверна логіка (Nest.js) та база даних (PostgreSQL).
Система реалізована таким чином, щоб забезпечити чітку структуровану
взаємодію між компонентами та можливість масштабування. У типовому сценарії
користувач взаємодіє з клієнтським інтерфейсом, побудованим з використанням
фреймворку Next.js. Через форму або інший елемент інтерфейсу користувач
надсилає запит — наприклад, для отримання списку об’єктів, відфільтрованих за
певними критеріями. Цей запит обробляється клієнтською логікою та надсилається
до API, реалізованого на Nest.js. Серверна частина на базі Nest.js отримує HTTP-
запит, обробляє його за допомогою контролерів, сервісів і, за потреби, middleware
або guard-ів. Потім відповідний сервіс звертається до бази даних через ORM (у
нашому випадку - TypeORM), виконує потрібні SQL-запити з урахуванням
критеріїв фільтрації та формує відповідь.
Дані, отримані з бази, проходять обробку на рівні сервісу, після чого
передаються назад клієнту у вигляді JSON-відповіді. Клієнтська частина,
отримавши відповідь, оновлює стан інтерфейсу (через React state або сторонні
бібліотеки управління станом) та відображає дані користувачу.
Рисунок 14 - Функціональна схема фреймворку
3.1.3 Опис логічної схеми системи
Процес функціонування модульного веб-додатку для планування задач
побудований на чітко визначеній структурі взаємодії між клієнтським інтерфейсом,
серверною логікою та базою даних. Логічна схема включає в себе основні операції:
створення, оновлення, перегляд задач, фільтрація за категоріями, управління
пріоритетами, створення нагадувань та збереження результатів. Послідовність дій
організована таким чином:
1. Ініціалізація системи. При запуску веб-додаток ініціалізує базу даних, що
містить таблиці для задач, категорій, пріоритетів, користувачів, тощо.
Серверна частина (Nest.js) ініціалізує зв'язок із базою даних через ORM та
налаштовує API для обробки запитів від клієнта.
2. Створення задач. Користувач через клієнтський інтерфейс (Next.js) може
додавати нові задачі, вказуючи назву, опис, дату виконання, пріоритет,
категорію тощо. Запит на створення задачі надсилається до серверної
частини, де обробляється, зберігається у базі даних та передається
підтвердження клієнту.
3. Оновлення та редагування задач. Користувач може редагувати існуючі
задачі, змінюючи їх характеристики (наприклад, дату виконання чи
категорію). Оновлені дані надсилаються до серверної частини, де
відбувається їх оновлення в базі даних.
4. Створення подій в календарі. Користувач через клієнтський інтерфейс
календаря може створювати події, вносити уточнюючі дані (дата початку,
дата завершення, локація та нотатки), редагувати та видаляти події.
5. Взаємодія з користувачем. Усі запити на створення, оновлення або перегляд
задач обробляються через API серверної частини. Відповідь передається
клієнтському інтерфейсу у вигляді JSON-даних. Клієнтські компоненти
оновлюють інтерфейс відповідно до нових даних.
6. Завершення роботи. При виході з додатка або його закритті дані задач
зберігаються в базі даних. Система гарантує, що всі задачі та налаштування
збережені без втрат, і подальший доступ до них можливий при повторному
вході.
Рисунок 15 - Блок-схема логічної роботи системи
3.1.4 Розробка бази даних
У рамках даного веб-додатку для планування задач, основні дані, такі як
задачі, події та користувачі та користувачі, будуть зберігатися в реляційній базі
даних. Розробка бази даних передбачає наступні етапи, від концептуальної до
фізичної моделі. Використання реляційної бази даних дозволить забезпечити
збереження даних на тривалий період і легке масштабування. На першому етапі
важливо визначити основні об'єкти проблемної області додатку, їх атрибути та
взаємозв'язки. Після визначення об'єктів і їх взаємозв'язків, створюється логічна
модель даних. Фізична модель даних, використовуючи ORM, описує конкретну
реалізацію таблиць та їх атрибути в реляційній базі даних. Цей етап включає
проектування індексів, первинних та зовнішніх ключів для забезпечення цілісності
та ефективності.
3.1.5 Розробка програмного інтерфейсу
Програмний інтерфейс для користувача є ключовою складовою в моєму
модульному застосунку. Основною метою є створення інтуїтивно зрозумілого,
адаптивного та функціонального інтерфейсу, який дозволяє користувачам
ефективно взаємодіяти з системою. Для реалізації клієнтської частини було
використано стек технологій: TypeScript, Next.js (React-фреймворк), а також
Tailwind CSS для стилізації.
Користувацький інтерфейс побудований за компонентною архітектурою, де
кожен елемент (форма, кнопка, таблиця, діалогове вікно тощо) реалізований у
вигляді окремого компонента. Такий підхід сприяє повторному використанню
коду, кращій підтримуваності проєкту та спрощенню масштабування.
Основні екрани застосунку:
- головна сторінка — відображає короткий огляд швидких дій для створення
задач та подій;
- бічне меню — для швидкої навігації по доступним колекціям даних та
календарю;
Рисунок 16 – Частина програмного інтерфейсу: бічне меню та головна
сторінка
- cписок задач – містить перелік задач з можливістю створення, редагування
та видалення;
Рисунок 17 - Частина програмного інтерфейсу: список задач
- календар подій — інтерактивний календар із візуалізацією запланованих
подій;
Рисунок 18 – Частина програмного інтерфесу: календар подій
- форма створення/редагування задач і подій — модульна форма з валідацією
введених даних;
Рисунок 19 - Частина програмного інтерфесу: діалогове вікно для створення
нової колонки в колекції даних
- сторінка профілю користувача — дозволяє змінювати особисту інформацію
та налаштування;
Щодо технічної реалізації:
- TypeScript забезпечує статичну типізацію, що дозволяє зменшити кількість
помилок під час розробки та полегшує маштабування проеєту. На перший
погляд здається, що можна обмежитись використанням JavaScript для
виконання проекту, але коли додаток виходить за межі однієї сторінки та має
навантажену логіку по роботі з даними, то варто застосовувати TypeScript,
що я й зробив, як для клієнтської частини, так і для серверної;
- Next.js використовується для створення маршрутизації, SSR (server-side
rendering) та оптимізації продуктивності. Це дозволяє пришвидшити
початкове завантаження сторінки покращити SEO та безпеку додатку;
- Tailwind CSS дозволяє швидко створювати адаптивний інтерфейс без
написання кастомних CSS-файлів;
- GraphQL забезпечує ефективну взаємодію з серверною частиною,
дозволяючи клієнту запитувати лише необхідні дані. Колекції даних містять
також додатку мета інформацію для побудови таблиць, але ця інформація
нам не потрібна у бічному меню, тому GraphQL вирішує саме цю проблему;
Клієнт взаємодіє з сервером, реалізованим на NestJS, через GraphQL та Rest
API. Наприклад, при створенні нової колекції даних надсилає GraphQL мутацію на
сервер, де вона обробляється відповідним резолвером, після чого дані зберігаються
в базі даних PostgreSQL за допомогою TypeORM. Такий самий принцип роботи
застосовується і для Rest API ендпоінтів.
У результаті розроблено зручний та адаптивний інтерфейс користувача, що
дозволяє ефективно керувати задачами та подіями. Такий інтерфейс не лише
полегшує роботу користувача з системою, а й демонструє можливості сучасних
підходів до розробки веб-застосунків і застосування багатьох технологій на
практиці і саме там, де вони вирішують певні проблеми.
3.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів веб-додатку виконувалася з урахуванням
модульного підходу. Це дозволяє забезпечити масштабованість, розширюваність
та повторне використання коду, а також спрощує тестування й обслуговування
проєкту. Програмна система поділяється на клієнтську (фронтенд) та серверну
(бекенд) частини, кожна з яких реалізує окремі функціональні модулі. Архітектура
компонентів та застосунків (клієнт та сервер) повинні кричати о своєму призначені,
як це описано у книзі “Чиста Архітектура” Роберта Мартіна. Тому я був
зосереджений саме на тому, щоб при відкритті проєктів можна було одразу
зрозуміти з чим розробник має справу. Клієнтська частина була розбита на
компоненти, які потім збирались в цілі екрани. Основні компоненти розроблені
згідно з принципами розділення відповідальності (Separation of Concerns) та
односпрямованого потоку даних.
Основні клієнтські компоненти:
- collectionView – відповідає за маппінг даних перед їх відмалюванням.
Вирішує який компонент відобразити в залежності від вхідних даних;
- tableView/ListView – відповідає суто за UI частину, відмальовує
таблицю/список;
- calendar — реалізує інтерактивний календар, що відображає події та дозволяє
створювати/редагувати їх за допомогою модальних вікон;
- dialog — універсальний компонент для діалогових вікон, який
використовується при взаємодії з задачами, подіями та повідомленнями.
Створений в єдиному екземплярі, відмальовує переданий контент;
- userSettings — сторінка для перегляду та редагування даних користувача;
Серверна частина реалізована на основі NestJS, що є фреймворком для
створення масштабованих серверних додатків за допомогою TypeScript.
Архітектура побудована за принципом Domain-Driven Design, що забезпечує
логічне розділення на доменні області. Весь додаток поділений на модулі, що
забезпечує модульність серверної частини.
- authModule — реалізує аутентифікацію користувачів за допомогою JWT-
токенів. Підтримує реєстрацію, вхід, вихід та перевірку прав доступу;
- usersModule — містить функціонал для роботи з обліковими записами
користувачів (зміна пароля, редагування профілю тощо);
- tasksModule — забезпечує CRUD-операції над задачами. Включає GraphQL-
резолвери, DTO, сервіси та репозиторії для взаємодії з базою даних;
- calendarModule — аналогічно до TasksModule реалізує логіку для подій:
створення, редагування, видалення, прив’язка до дати;
У розробленому застосунку до авторизації та захисту даних користувачів
використовується JWT (JSON Web Token). Цей підхід забезпечує безпечну і
масштабовану модель контролю доступу до ресурсоємних операцій та чутливої
інформації.
При успішній авторизації на серверній частині створюється токен доступу у
форматі JWT, який містить унікальний ідентифікатор користувача та інші службові
дані (наприклад, час дії, роль тощо). Цей токен передається клієнту й зберігається
на його стороні (у cookie з флагом HttpOnly). Кожен наступний запит до захищених
API супроводжується передачею токена в заголовку Authorization, що дає змогу
серверу ідентифікувати користувача без повторної авторизації.
Для забезпечення ізольованого доступу до даних система реалізує перевірку
ключів доступу на рівні сервісного рівня. Усі запити до бази даних проходять
попередню перевірку, під час якої ідентифікатор користувача, витягнутий із JWT,
порівнюється з метаданими ресурсів. Це гарантує, що користувач може взаємодіяти
лише зі своїми власними даними (наприклад, подіями чи завданнями), виключаючи
несанкціонований доступ до сторонніх ресурсів.
У системі збереження паролів реалізовано з дотриманням сучасних стандартів
інформаційної безпеки. Паролі користувачів не зберігаються у відкритому вигляді,
а проходять процес хешування перед записом у базу даних. Для цього
використовується криптографічно стійкий алгоритм хешування — наприклад,
bcrypt, який має вбудований механізм солювання (додавання випадкового рядка до
паролю перед хешуванням)
3.2 Тестування системи
3.2.1 Модульне тестування
У процесі розробки веб-додатку було реалізовано модульне тестування як
важливу складову забезпечення якості програмного забезпечення. Основною
метою модульного тестування є перевірка логіки окремих функціональних
одиниць системи — таких як сервіси, компоненти, утіліти та окремі бізнес-функції
— в ізольованому середовищі.
Для тестування клієнтської частини (Next.js) використовувалися зв’язка
Vitest + Testing Library + jsdom, що дозволяє симулювати DOM-середовище та
тестувати компоненти React у поведінковому стилі.
Рисунок 20 – Уривок коду з тестування компонента, який відображає
користувача
Рисунок 21 – Тестування пагінації в таблиці
В таблиці 1 представлені результати тестування клієнтської частини
Таблиця 1 – Модульне тестування
Ім’я модульного тесту Очікуваний результат Отриманий результат
Відображення задач у Компонент відображає Компонент відображає
вигляді таблиці/списку передані задачі передані задачі
Перегляд різних Пагінація реагує на Пагінація реагує на
наборів даних за кліки користувача та кліки користувача та
допомогою пагінації відображає потрібні відображає потрібні
дані дані
Маніпуляція даними за Компонент реагує на Компонент реагує на
допомогою визначених натискання видалення, натискання видалення,
дій редагування та передає редагування та передає
необхідні дані необхідні дані
Відображення подій у Передані дані Передані дані
вигляді календаря відображаються у відображаються у
вигляді календаря вигляді календаря
Відображення Передані дані повинні Передані дані
переданого контенту у відображатись у відображаються у
діалоговому вікні модальному вікні модальному вікні
Навігація в сайдбарі Сайдбар повинен Сайдбар навігує на
навігувати на сторінки клікнуті сторінки
задач
Вихід з системи При кліку видаляються При кліку видаляються
дані користувача з дані користувача з
клієнту та надсилається клієнту та надсилається
відповідний запит на відповідний запит на
сервер сервер
3.2.2 Інтеграційне тестування
Інтеграційне тестування було спрямоване на перевірку взаємодії між
окремими модулями клієнтської та серверної частин додатку, а також перевірку
повного життєвого циклу обробки запитів між фронтендом, GraphQL API та базою
даних.
Для реалізації інтеграційних тестів було використано Vitest у поєднанні з
supertest для бекенду та testing-library/react для клієнта.
Таблиця 2 – Інтеграційне тестування
Ім’я інтеграційного Очікуваний результат Отриманий результат
тесту
Реєстрація нового Створення запису Створення запису
користувача користувача у базі та користувача у базі та
повернення JWT токена повернення JWT токена
Створення задачі Авторизований Авторизований
користувач створює користувач створює
задачу, запис задачу, запис
зберігається у зв’язаній зберігається у зв’язаній
таблиці tasks таблиці tasks
Оновлення задачі Перевірка правильності Перевірка правильності
змін у базі, повернення змін у базі, повернення
зміненного об'єкта на зміненного об'єкта на
клієнт клієнт
Створення події в Перевірка збереження Перевірка збереження
календарі зв’язку з користувачем зв’язку з користувачем
та коректності полів, та коректності полів,
повернення оновленого повернення оновленого
об'єкту об'єкту
Обробка помилок Запит без токена має Запит без токена
авторизації повертати відповідну повертає відповідну
помилку помилку
У результаті інтеграційного тестування, результати якого наведено в таблиці
2, було підтверджено коректну взаємодію всіх компонентів системи. Тестування
показало, що система ефективно обробляє різноманітні сценарії взаємодії між
сутностями, подіями та архетипами, що свідчить про її стабільність і готовність до
експлуатації в реальному середовищі.
3.2.3 Системне тестування
Системне тестування є завершальним етапом тестування програмного
забезпечення, під час якого перевіряється повна інтегрована система на
відповідність вимогам, визначеним на етапі проектування. Для модульного веб-
додатку з планування задач та подій було проведено комплексне тестування усіх
функціональних і нефункціональних аспектів системи.
Під час системного тестування перевірялися такі основні критерії:
- функціональність: перевірено, чи всі модулі (створення, редагування,
видалення задач і подій; фільтрація та пошук; взаємодія користувача з
інтерфейсом) працюють відповідно до заданої логіки;
- сумісність: протестовано роботу додатку в різних браузерах (Google Chrome,
Mozilla Firefox);
- продуктивність: виконано навантажувальні тести для перевірки, як система
поводиться під час обробки великої кількості даних, запитів та одночасних
користувачів;
- безпека: перевірено доступ до приватних даних користувача, обмеження прав
доступу, коректну роботу з токенами авторизації;
- цілісність даних: перевірено, чи всі операції з даними (створення, оновлення,
видалення) коректно зберігаються в базі даних PostgreSQL за допомогою
GraphQL API та TypeORM;
Результати системного тестування засвідчили, що веб-додаток працює
стабільно, відповідає функціональним вимогам, демонструє високу продуктивність
і забезпечує якісний користувацький досвід. Це дозволяє зробити висновок про
готовність системи до впровадження та подальшого використання.
3.2.4 Приймальне тестування
Приймальне тестування є фінальним етапом в моєму тестуванні для перевірки
якості програмного забезпечення перед його впровадженням у продуктивне
середовище. Метою цього етапу є підтвердження того, що розроблений модульний
веб-додаток повністю задовольняє вимоги кінцевого користувача та готовий до
реального використання.
Під час приймального тестування були виконані наступні дії:
- перевірка відповідності функціоналу технічному завданню – протестовано
ключові сценарії роботи додатку, включно зі створенням, редагуванням,
фільтрацією та видаленням задач і подій;
- оцінка зручності використання інтерфейсу – декілька користувачів
протестували систему, після чого були зібрані відгуки щодо зручності
використання модулій;
- симуляція типових користувацьких дій – змодельовано повсякденну роботу
з додатком, включаючи сценарії з помилковими або неочікуваними діями,
щоб перевірити стійкість системи;
- перевірка документації – оцінено наявність та якість супровідної
документації для розробників (модульне тестування);
Приймальне тестування показало, що:
- функціональність додатку повністю відповідає поставленим вимогам;
- інтерфейс є інтуїтивно зрозумілим і зручним для користувачів;
- система коректно реагує на всі вхідні дані, зокрема неочікувані чи помилкові;
- додаток готовий до розгортання в продуктивному середовищі;
3.3 Приклади впровадження програмного комплексу
3.3.1 Розгортання системи
У межах мого проєкту було обрано підхід до розгортання, заснований на
використанні системи контролю версій Git та інструментів контейнеризації Docker.
Усі репозиторії, пов’язані з додатком, розміщені на платформі GitHub, що
забезпечує централізований доступ до коду, зручне відстеження змін і спільну
роботу над проєктом. Система складається з двох частин: серверної (backend) і
клієнтської (frontend).
Для початку користування системою потрібно спочатку розгорнути серверну
частину. Для цього необхідно:
- клонувати репозиторій із GitHub;
- налаштувати змінні середовища (файл .env), що містять конфігураційні дані:
параметри доступу до бази даних (ім’я користувача, пароль, порт, назва
бази);
- секретний ключ для генерації та перевірки JWT-токенів;
- запустити сервер за допомогою Docker Compose, який автоматизує
розгортання середовища;
Саме цей етап розгортання дуже спрощує docker-compose, він забезпечує
консистентне середовища розробки і продакшену, швидке розгортання всієї
інфраструктури (база даних + NestJS додаток) однією командою, ізолює сервіси,
що спрощує налагодження та обслуговування, зменшує кількость помилок,
пов’язаних з розбіжностями у середовищах.
Після того, як ми розгорнули та запустити серверне середовище, нам
потрібно розгорнути клієнтське середовище. Для цього потрібно:
- клонувати репозиторій клієнта з GitHub;
- скопіювати файл .env.example у .env і задати змінні середовища,
зокрема:адресу серверного API (URL);
- встановити залежності через пакетний менеджер;
- запустити додаток;
У результаті було реалізовано зручне та ефективне розгортання системи
шляхом використання GitHub для зберігання коду, Docker Compose для
автоматизації запуску інфраструктури та конфігураційних файлів .env для
налаштування середовища.
ВИСНОВОК ДО РОЗДІЛУ 3
У третьому розділі було всебічно охарактеризовано процес реалізації мого
застосунку від планування до тестування. На етапі проєктування визначено логічну
структуру системи, обґрунтовано вибір архітектурного підходу та реалізовано
інтеграцію між клієнтською та серверною частинами додатку.
Було розроблено графічний інтерфейс користувача з акцентом на зручність
взаємодії та швидкість доступу до основних функціональних можливостей.
Важливою складовою стала розробка програмних компонентів, які було
реалізовано з дотриманням принципів модульності, повторного використання та
зручності масштабування.
Особливу увагу приділено процесу тестування, що охоплює всі рівні
перевірки коректності роботи системи: модульне тестування за допомогою Vitest
дозволило виявити помилки на ранніх етапах розробки. Інтеграційне тестування
підтвердило узгодженість взаємодії між окремими модулями. Системне та
приймальне тестування продемонстрували відповідність реалізованої системи як
технічним, так і функціональним вимогам.
Окремим етапом стала підготовка до розгортання додатку. Репозиторії з
клієнтською та серверною частинами розміщені на GitHub, а інструкції з
конфігурації середовища наведені у відповідних .env файлах. Завдяки
використанню Docker та docker-compose забезпечено зручне розгортання всієї
інфраструктури, включаючи базу даних та сервер додатку. Такий підхід дозволяє
легко перенести систему в будь-яке середовище та забезпечити стабільну її роботу
без потреби у складному налаштуванні.
ВИСНОВКИ
Під час виконання поставленого завдання для кваліфікаційної роботи
бакалавра було реалізовано повний цикл розробки програмного забезпечення –
модульного організатора задач і подій з можливістю індивідуального
налаштування, що відповідає сучасним вимогам до інтерактивних web-застосунків.
У першому розділі було проведено аналіз існуючих аналогів програмних
рішень, які орієнтовані на планування особистої діяльності. Вивчено
функціональні можливості популярних додатків, таких як Notion, Trello та ClickUp.
На основі виявлених сильних і слабких сторін сформульовано постановку задачі —
створення масштабованого, адаптивного інструменту з гнучкою архітектурою,
який поєднує функціональність системи управління завданнями та календаря
подій.
У другому розділі, під час етапу проєктування, було виконано моделювання
предметної області, розроблено структуру бази даних із використанням реляційної
моделі на основі PostgreSQL. Побудовано систему UML-діаграм, зокрема: діаграму
прецедентів, діаграму класів, діаграми послідовності, комунікації, діяльності,
компонентів та розгортання. Вони відображають логіку роботи системи,
архітектурні компоненти та взаємодію між користувачами та елементами системи.
У третьому розділі була виконана реалізація програмного забезпечення
здійснювалася із використанням сучасного технологічного стеку. Для фронтенду
застосовано Next.js у поєднанні з Tailwind CSS, що дозволило інтерфейс із високим
рівнем кастомізації. Серверну частину розроблено за допомогою фреймворку
Nest.js, з використанням HTTP як протоколу обміну даними між клієнтом і
сервером, також був застосований GraphQL для деяких модулів застосунку для
запобігання отримання надлишкової при реалізації певних модлулів. Взаємодія з
базою даних відбувається через ORM та безпосередні SQL-запити до PostgreSQL,
що забезпечило гнучкість та ефективність при обробці запитів. Особливу увагу
приділено модульності архітектури, що дало змогу реалізувати окремі
функціональні блоки: керування задачами, планування подій та персоналізовані
налаштування. Завдяки використанню HTTP-запитів та GraphQL було досягнуто
ефективної взаємодії між клієнтською та серверною частинами.
На завершальному етапі виконано комплексне тестування програмного
комплексу, що включало перевірку функціональності, обробки помилок, стрес-
тестування та валідацію введених даних. Значну увагу було приділено модульному
тестуванню, яке здійснювалось за допомогою фреймворку Vitest, що забезпечує
швидке виконання тестів та інтеграцію з екосистемою React. Для тестування
компонентів користувацького інтерфейсу застосовувалась бібліотека React Testing
Library, яка дозволяє емулювати взаємодію користувача з UI, перевіряти
коректність рендерингу, поведінку компонентів у різних станах та відповідність їх
логіці застосунку. Використання цих інструментів дало змогу автоматизувати
перевірку критичних частин коду, підвищити якість та надійність продукту, а
також виявити потенційні помилки на ранніх етапах розробки. Результати
модульного тестування підтвердили коректність реалізації бізнес-логіки,
стабільність роботи UI-компонентів і відповідність функціоналу технічним та
функціональним вимогам.
Розроблений програмний застосунок є гнучким, зручним у використанні та
технічно придатним для подальшого розширення, інтеграції нових функцій та
впровадження в реальні умови експлуатації.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Martin R. Clean Architecture: A Craftsman's Guide to Software Structure and
Design. — Prentice Hall, 2017. — 272 p.
2. Лега Ю. Г. Управління якістю в проектах: навч. посіб. / Ю. Г. Лега, О. М.
Донець, С. Ю. Куницька; М-во освіти і науки, молоді та спорту України,
Черкас. держ. технол. ун-т. – Черкаси: Черкас. держ. технол. ун-т, 2013. –
356 с. ISBN 978-966-402-114-9 https://er.chdtu.edu.ua/handle/ChSTU/5541.
3. Лабораторний практикум з дисципліни «БАЗИ ДАНИХ» для здобувачів
освітнього ступеня «бакалавр» за спеціальністю 121 – Інженерія
програмного забезпечення, освітня програма «Інженерія програмного
забезпечення» галузі знань 12 - Інформаційні технології усіх форм
навчання [Електронний ресурс] / [упоряд. С.Ю. Куницька, С.В. Голуб,
В.В. Метелап] ; М-во освіти і науки України, Черкас. держ. технол. ун-т. –
Черкаси : ЧДТУ, 2024. – 57 с. https://er.chdtu.edu.ua/handle/ChSTU/5608.
4. Booch G. Design Patterns. Elements of Reusable Object-Oriented Software. —
Addison-Wesley, 1994. — 395 p.
5. Beck K. Test Driven Development: By Example. — Addison-Wesley
Professional, 2002. — 240 p.
6. Методичні вказівки до виконання лабораторних робіт з дисципліни
«Управління проектами» для студентів спеціальностей 7.03050401 і
8.03050401 - “Економіка підприємства” усіх форм навчання / Укл. Донець
О.М., Куницька С.Ю. – Черкаси: ЧДТУ, 2011. – 62 с.
https://er.chdtu.edu.ua/handle/ChSTU/5546.
7. Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language. — Addison-Wesley, 2003. — 160 p.
8. Fowler M., Beck K. Refactoring: Improving the Design of Existing Code. —
Addison-Wesley, 1999. — 431 p.
9. Методичні рекомендації до підготовки кваліфікаційної роботи бакалавра
для здобувачів вищої освіти зі спеціальності 121 «Інженерія програмного
забезпечення» усіх форм навчання / Упорядники: Голуб С.В., Заспа Г.О.,
Куницька С.Ю., Півень О.Б. Катаєва Є.Ю., Салапатов В.І., Метелап В.В.,
Олексюк В.В.; М-во освіти і науки України, Черкас, держ. технол. ун-т.
Черкаси: ЧДТУ, 2023. 130 с. https://er.chdtu.edu.ua/handle/ChSTU/5607.
10. Fowler M. Patterns of Enterprise Application Architecture. — Addison-Wesley,
2002. — 533 p.
11. Методичні рекомендації до виконання лабораторних робіт з дисципліни
«WEB-ПРОГРАМУВАННЯ» частина 1 для здобувачів освітнього ступеня
«бакалавр» за спеціальністю 121 – Інженерія програмного забезпечення,
освітня програма «Інженерія програмного забезпечення» галузі знань 12 -
Інформаційні технології усіх форм навчання [Електронний ресурс] /
[упорядники: С.Ю. Куницька, В.В. Метелап, В.В. Немченко] ; М-во освіти
і науки України, Черкас. держ. технол. ун-т. Черкаси : ЧДТУ, 2024. - 96 с.
https://er.chdtu.edu.ua/handle/ChSTU/5609.
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2025 р.
«Програмне забезпечення додатку модульного організатора задач та подій з
можливістю індивідуального налаштування»
Специфікація
482.ЧДТУ.252160.012
Листів 2
Розробник ________________ Метеля Д.А.
Керівник ________________ Куницька С. Ю.
2025
Позначення Найменування Примітка
Документація
482.ЧДТУ 252160 12 01 Текст програми
482.ЧДТУ 252160 34 01 Інструкція користувачеві
482.ЧДТУ 252160 90 01 Графічні матеріали
ДОДАТОК Б
«Програмне забезпечення додатку модульного організатора задач та подій з
можливістю індивідуального налаштування»
Текст програми
482.ЧДТУ.252160 21 01
Листів 17
Розробник ________________ Метеля Д.А.
2025
const titilliumWeb = Titillium_Web({
variable: '--font-titillium-web',
weight: ['200', '300', '400', '600', '700', '900'],
subsets: ['latin'],
display: 'swap',
});
export const metadata: Metadata = {
title: 'Structify',
description: 'Noncommercial project management tool',
};
export default function RootLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
return (
<html lang="en" suppressHydrationWarning>
<body className={cn(titilliumWeb.variable, 'antialiased bg-noise')}>
<ApolloProvider>
<Toaster position="bottom-right" />
<ToastProvider placement="bottom-right" />
<HeroUIProvider>
<ThemeProvider defaultTheme="light" enableSystem>
<AuthGuard>{children}</AuthGuard>
<Dialog />
<Drawer />
</ThemeProvider>
</HeroUIProvider>
</ApolloProvider>
</body>
</html>
);
'use client';
import { useEffect } from 'react';
import dynamic from 'next/dynamic';
import { useRouter } from 'next/navigation';
import type { Column } from '@/features/columns/lib';
import {
initColumns,
useColumnStore,
} from '@/features/columns/services/columns.store';
import type { RowValue } from '@/features/row-value/lib';
import { initializeRows, useRowsStore } from '@/features/rows/services';
import { useViewFormatStore } from '@/features/view/services';
import { Skeleton } from '@/shared/ui/kit/skeleton';
import { PageSizeDropdown } from './page-size-dropdown';
import { TableView } from './table-view';
import { ViewHeader } from './view-header';
const Pagination = dynamic(
() => import('@/shared/ui/kit/pagination').then(mod => mod.Pagination),
{
ssr: false,
loading: () => <Skeleton width={160} height={32} />,
},
);
export function CollectionView({
viewId,
rows,
columns,
page,
pageSize,
totalPages,
}: {
viewId: string;
columns: Column[];
rows: Record<string, string>[];
rowValues: RowValue[];
page: number;
pageSize: number;
totalPages: number;
}) {
useEffect(() => {
initializeRows(rows);
initColumns(columns);
}, [rows, columns]);
const router = useRouter();
const { data } = useRowsStore();
const { columns: cols } = useColumnStore();
const { activeView } = useViewFormatStore();
return (
<section>
<ViewHeader viewId={viewId} />
<TableView
columns={cols}
rows={data}
viewId={viewId}
rowValues={rowValues}
makeList={activeView === 'list'}
/>
total={totalPages}
page={page}
onChange={nextPage => {
router.push(`?page=${nextPage}&pageSize=${pageSize}`);
}}
/>
<PageSizeDropdown page={page} currentPageSize={pageSize} />
</section>
</section>
);
}
'use client';
import { useCallback, useMemo } from 'react';
import dynamic from 'next/dynamic';
import type { Column } from '@/features/columns/lib';
import type { RowValue } from '@/features/row-value/lib';
import { Edit } from '@/shared/ui/icons';
import { Chip } from '@/shared/ui/kit/chip';
import { useDialogStore } from '@/shared/ui/kit/dialog';
import {
getKeyValue,
Table,
TableBody,
TableCell,
TableColumn,
TableHeader,
TableRow,
} from '@/shared/ui/kit/table';
import { ViewActions } from './view-actions';
const ColumnEditDialog = dynamic(
() =>
import('@/features/columns/components').then(mod =>
mod.ColumnEditDialog),
{
ssr: false,
},
);
export function TableView({
columns,
rows,
viewId,
rowValues,
makeList = false,
}: {
columns: Column[];
rows: Record<string, string>[];
viewId: string;
rowValues: RowValue[];
makeList?: boolean;
}) {
const { open, registerContent } = useDialogStore();
const extendedColumns = useMemo(
() => [
...columns,
{
id: 'actions',
key: 'actions',
name: '',
dataType: 'text',
variants: [],
[columns],
);
const handleEditColumn = useCallback(
(column: Column) => {
registerContent({
title: 'Edit Column',
content: <ColumnEditDialog value={column} />,
});
open();
},
[registerContent, open],
);
return (
<Table isStriped={makeList} hideHeader={makeList}>
<TableHeader columns={extendedColumns}>
{column => (
<TableColumn key={column.key}>
<div className="flex items-center gap-2">
{column.name}
{column.key !== 'actions' && (
<button onClick={() => handleEditColumn(column)}>
<Edit size={14} />
</button>
)}
</div>
</TableColumn>
)}
</TableHeader>
<TableBody items={rows} emptyContent={'No rows to display.'}>
{item => (
<TableRow key={item.key}>
{columnKey => {
if (columnKey === 'actions') {
return (
<TableCell className="flex items-center justify-end gap-
3">
<ViewActions
rowId={item.key}
item={item}
columns={columns}
viewId={viewId}
rowValues={rowValues}
/>
</TableCell>
);
}
const column = extendedColumns.find(col => col.key ===
columnKey);
const value = getKeyValue(item, columnKey);
return (
<TableCell>
{column?.dataType === 'select' && value ? (
<Chip variant="flat">{value}</Chip>
) : (
value
)}
</TableCell>
);
}}
</TableRow>
)}
</TableBody>
</Table>
);
}
'use client';
import { useEffect } from 'react';
import dynamic from 'next/dynamic';
import { useRouter } from 'next/navigation';
import type { Column } from '@/features/columns/lib';
import {
initColumns,
useColumnStore,
} from '@/features/columns/services/columns.store';
import type { RowValue } from '@/features/row-value/lib';
import { initializeRows, useRowsStore } from '@/features/rows/services';
import { useViewFormatStore } from '@/features/view/services';
import { Skeleton } from '@/shared/ui/kit/skeleton';
import { PageSizeDropdown } from './page-size-dropdown';
import { TableView } from './table-view';
import { ViewHeader } from './view-header';
const Pagination = dynamic(
() => import('@/shared/ui/kit/pagination').then(mod => mod.Pagination),
{
ssr: false,
loading: () => <Skeleton width={160} height={32} />,
},
);
export function CollectionView({
viewId,
rows,
columns,
rowValues,
page,
pageSize,
totalPages,
}: {
viewId: string;
columns: Column[];
rows: Record<string, string>[];
rowValues: RowValue[];
page: number;
pageSize: number;
totalPages: number;
}) {
useEffect(() => {
initializeRows(rows);
initColumns(columns);
}, [rows, columns]);
const router = useRouter();
const { data } = useRowsStore();
const { columns: cols } = useColumnStore();
const { activeView } = useViewFormatStore();
return (
<section>
<ViewHeader viewId={viewId} />
<TableView
columns={cols}
import { Module } from '@nestjs/common';
import { AuthModule } from '~/modules/auth/auth.module';
import { HeadersManagerModule } from '~/modules/headers-manager/headers-
manager.module';
import { UserModule } from '~/modules/user/user.module';
import { CalendarModule } from './modules/calendar/calendar.module';
import { ColumnModule } from './modules/column/column.module';
import { AppConfigModule } from './modules/config/config.module';
import { DatabaseModule } from './modules/database/database.module';
import { GqlModule } from './modules/gql/gql.module';
import { RowModule } from './modules/row/row.module';
import { RowValueModule } from './modules/row-value/row-value.module';
import { ViewModule } from './modules/view/view.module';
import { ViewDataModule } from './modules/view-data/view-data.module';
@Module({
imports: [
ViewModule,
AppConfigModule,
DatabaseModule,
GqlModule,
AuthModule,
UserModule,
HeadersManagerModule,
ColumnModule,
RowModule,
RowValueModule,
ViewDataModule,
CalendarModule,
],
})
export class AppModule {}
import { Response } from 'express';
import { Body, Controller, Post, Res, UseInterceptors } from
'@nestjs/common';
import { ResponseFormatInterceptor } from '~/shared/interceptors/response-
format';
import { AuthService } from './auth.service';
import { RefreshTokenDTO, SignInDTO, SignUpDTO } from './dto';
@UseInterceptors(ResponseFormatInterceptor)
@Controller('auth')
export class AuthController {
constructor(private readonly authService: AuthService) {}
@Post('sign-up')
async signUp(@Body() signUpDTO: SignUpDTO) {
return this.authService.signUp(signUpDTO);
}
@Post('sign-in')
async signIn(
@Body() signInDTO: SignInDTO,
@Res({ passthrough: true }) res: Response,
) {
const tokens = await this.authService.signIn(signInDTO);
res.cookie('refreshToken', tokens.refreshToken, {
httpOnly: true,
secure: process.env.NODE_ENV === 'production',
sameSite: 'strict',
maxAge: 30 * 24 * 60 * 60 * 1000,
});
return { accessToken: tokens.accessToken };
}
@Post('refresh-token')
async refreshToken(
@Body() refreshTokenDTO: RefreshTokenDTO,
@Res({ passthrough: true }) res: Response,
) {
const tokens = await this.authService.refreshToken(refreshTokenDTO);
res.cookie('refreshToken', tokens.refreshToken, {
httpOnly: true,
secure: process.env.NODE_ENV === 'production',
sameSite: 'strict',
maxAge: 30 * 24 * 60 * 60 * 1000,
});
return { accessToken: tokens.accessToken };
}
}
import {
Controller,
Get,
Headers,
Query,
UseGuards,
UseInterceptors,
} from '@nestjs/common';
import { JwtService } from '@nestjs/jwt';
import { ViewDataService } from '~/modules/view-data/view-data.service';
import { AuthGuard } from '~/shared/guards/auth-guard';
import { ResponseFormatInterceptor } from '~/shared/interceptors/response-
format';
import { getTokenFromAuthHeader } from '~/shared/lib/token';
@UseGuards(AuthGuard)
@UseInterceptors(ResponseFormatInterceptor)
@Controller('view-data')
export class ViewDataController {
constructor(
private readonly viewDataService: ViewDataService,
private readonly jwtService: JwtService,
) {}
@Get()
async getData(
@Headers('Authorization') authHeader: string,
@Query('viewId') viewId: string,
@Query('page') page: number = 1,
@Query('page_size') pageSize: number = 15,
) {
const token = getTokenFromAuthHeader(authHeader);
const userId = this.jwtService.decode(token).id;
return this.viewDataService.getViewData({ userId, viewId, page, pageSize
});
ДОДАТОК В
«Програмне забезпечення додатку модульного організатора задач та подій з
можливістю індивідуального налаштування»
Інструкція користувачеві
482.ЧДТУ 252160 34 01
Листів 6
Розробник ________________ Метеля Д.А.
2025
Перша сторінка додатку надає можливість швидких дій щодо існуючих
методів управління даними: створити нову задачу або створити нову подію. Також
користувач зі стартової сторінки може навігуватись по додатку: перейти на
конкретну колекцію даних, змінити персональні дані або переглянути події на
календарі.
Рисунок В.1 – Перша сторінка сайту
Після переходу на обрану колекцію даних у вкладці “Views” ми можемо
проглянути збережені дані у форматі таблиці або списку. На сторінці наявна
пагінація разом з відображеними даними та швидкими діями щодо них:
редагування та видалення.я
Рисунок В.2 – Відображення колекції даних у вигляді таблиці
Рисунок В.3 – Відображення швидких дій для роботи з даними
Рисунок В.4 – Діалогове вікно для редагування запису
Рисунок В.5 – Діалогове вікно для видалення запису
При переході на сторінку календаря користувач може побачити свої
заплановані події у декількох варіація: на місяць, на неділю, на день або ж у вигляді
списку.
Рисунок В.6 – Відображення подій на цілий місяць
Рисунок В.7 – Відображення подій на неділю
При натисканні на події відкривається бічне меню з інформацією щодо
запису та діями: видалення та редагування.
Рисунок В.8 – Відображення деталей події
Рисунок В.9 – Редагування події
При реєстрації користувач повинен вказати лише свій логін, а інші дані, такі
як ім’я та прізвище є опціональними. За бажанням, користувач може змінити своє
прізвище, ім’я та логін.
Рисунок В.10– Персональній налаштування