Мобільний застосунок «Викладач ЧДТУ»

Плакся, Денис Дмитрович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9104
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Заспа, Григорій Олександрович	-
dc.contributor.author	Плакся, Денис Дмитрович	-
dc.date.accessioned	2026-03-25T18:26:22Z	-
dc.date.available	2026-03-25T18:26:22Z	-
dc.date.issued	2023-06-17	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9104	-
dc.description.abstract	АНОТАЦІЯ Плакся Денис Дмитрович Мобільний застосунок “Викладач ЧДТУ” 121 - Інженерія програмного забезпечення Черкаський державний технологічний університет Черкаси, 2023 Кваліфікаційна робота присвячена розробці мобільного додатку для викладачів. Метою даної роботи є розробка зручного та ефективного інструменту для викладачів університету, що сприятиме кращій організації процесу навчання, забезпеченню доступу до навчального матеріалу, спрощенню взаємодії зі студентами та підвищенню якості навчання. В рамках даної дипломної роботи буде виконано детальний аналіз поточних проблем та вимог викладачів щодо додатку. Також будуть проведені дослідження сучасних підходів до розробки мобільних додатків в контексті освіти. Це дозволить виявити потреби викладачів та визначити ключові функції та можливості, які повинен мати мобільний додаток для досягнення поставлених цілей. На основі отриманих знань буде розроблений та реалізований мобільний застосунок, який буде включати такі функції, як: 1 Перегляд груп де викладач є куратором 2 Перегляд студентів з заборгованістю 3 Перегляд особистої інформації 4 Перегляд розкладу Для розробки мобільного додатку буде використовуватись така технологія як Flutter [1]. Результатом є розроблений та протестований мобільний додаток для викладачів який вирішує поточні проблеми викладачів.	uk_UA
dc.description.abstract	ABSTRACT Denys Dmytrovych Mobile application "Teacher of ChDTU" 121 - Software engineering Cherkasy State Technological University Cherkasy, 2023 The qualification work is devoted to the development of a mobile application for teachers. The purpose of this work is to develop a convenient and effective tool for university teachers, which will contribute to a better organization of the learning process, providing access to educational material, simplifying interaction with students and improving the quality of learning. As part of this thesis, a detailed analysis of the current problems and requirements of teachers regarding the application will be performed. Studies of modern approaches to the development of mobile applications in the context of education will also be conducted. This will reveal the needs of teachers and determine the key functions and capabilities that a mobile application should have in order to achieve its goals. Based on the knowledge gained, a mobile application will be developed and implemented, which will include such functions as: 1 Viewing groups where the teacher is the curator 2 View students with debt 3 Viewing personal information 4 View schedule A technology such as Flutter will be used to develop the mobile application. The result is a developed and tested mobile application for teachers that solves the current problems of teachers	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	мобільний застосунок	uk_UA
dc.subject	викладач	uk_UA
dc.subject	університет.	uk_UA
dc.subject	mobile application	uk_UA
dc.subject	teacher	uk_UA
dc.subject	university	uk_UA
dc.title	Мобільний застосунок «Викладач ЧДТУ»	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна робота бакалавра Плакся Денис Дмитрович.pdf Restricted Access		3.1 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
 
на тему:  Мобільний застосунок «Викладач ЧДТУ»  
 
 
Виконав: студент 4 курсу, групи ПЗ-1904 
спеціальності 
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Плакся Д.Д 
 (прізвище та ініціали) 
Керівник  Заспа Г.О 
 (прізвище та ініціали) 
Рецензент   Крайовий В.М 
 (прізвище та ініціали) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2023 
 
 
                              ___     Черкаський державний технологічний університет_________________                                       
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем 
Кафедра  програмного забезпечення автоматизованих систем 
Освітній рівень  бакалавр 
Спеціальність 121 «Інженерія програмного забезпечення» 
Освітня програма Інженерія програмного забезпечення 
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________Голуб С.В. 
«___» _______________ 2023 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
          Плакся Денис Дмитрович___________________________ 
(прізвище, ім’я, по батькові) 
1.Тему проекту (роботи) Мобільний застосунок «Викладач 
ЧДТУ»____________________________________________________________________________ 
Керівник проекту (роботи) Заспа Григорій Олександрович, старший викладач  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 24 » лютого 2023 року 
№43/04 
2. Строк подання студентом проекту (роботи) 01 червня 2023 р. 
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління; вимоги до 
проекту; календарне планування проекту; управління ризиками проекту; управління 
ресурсами_______________________________________________________________________ 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ; 
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ;___________ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ;______________________ 
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ______________________ 
Висновки; _______________________________________________________________________ 
Список використаних джерел; ______________________________________________________ 
Додатки. ________________________________________________________________________ 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Модель предметної області;________________________________________________________ 
Діаграма класів;__________________________________________________________________ 
Діаграма прецендентів;____________________________________________________________ 
Діаграма пакетів;_________________________________________________________________ 
Діаграма компонентів;_____________________________________________________________ 
Діаграма діяльності;_______________________________________________________________ 
Діаграма послідовності;____________________________________________________________ 
 
 
 
 
6. Консультанти розділів проекту (роботи) 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 02 грудня 2022 р. 
 
КАЛЕНДАРНИЙ ПЛАН 
Строк 
виконання 
№ 
Назва етапів випускної роботи етапів Примітки 
п/п випускної 
роботи 
1 Постановка задачі 05.12.2022 виконано 
2 Підготовка завдання 13.12.2022 виконано 
3 Погодження завдання 16.12.2022 виконано 
4 Затвердження завдання 19.02.2022 виконано 
 Основна стадія   
1 Підбір матеріалів 27.02.2022 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.02.2022 виконано 
3 Розрахунок основних параметрів роботи 10.03.2022 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.03.2022 виконано 
5 Оформлення первісної редакції роботи 25.04.2022 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 10.05.2023 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 19.05.2023 виконано 
кінцевій редакції 
3 Попередній захист роботи 22.05.2023 виконано 
4 Затвердження роботи 29.06.2023 виконано 
5 Рецензування роботи 01.06.2023 виконано 
6 Захист роботи   
 
Студент _____________________ Плакся Д.Д. 
  (підпис)   (прізвище та ініціали) 
 
Керівник проекту (роботи) _____________________ Заспа Г.О. 
  (підпис)   (прізвище та ініціали) 
 
 
 
 
АНОТАЦІЯ 
Плакся Денис Дмитрович 
Мобільний застосунок “Викладач ЧДТУ” 
121 -  Інженерія програмного  забезпечення 
Черкаський державний технологічний університет 
Черкаси, 2023 
Кваліфікаційна  робота присвячена розробці мобільного додатку для викладачів. 
Метою даної роботи є розробка зручного та ефективного інструменту для викладачів 
університету, що сприятиме кращій організації процесу навчання, забезпеченню 
доступу до навчального матеріалу, спрощенню взаємодії зі студентами та підвищенню 
якості навчання. 
В рамках даної дипломної роботи буде виконано детальний аналіз поточних 
проблем та вимог викладачів щодо додатку. Також будуть проведені дослідження 
сучасних підходів до розробки мобільних додатків в контексті освіти. Це дозволить 
виявити потреби викладачів та визначити ключові функції та можливості, які повинен 
мати мобільний додаток для досягнення поставлених цілей. 
На основі отриманих знань буде розроблений та реалізований мобільний 
застосунок, який буде включати такі функції, як: 
1 Перегляд груп де викладач є куратором 
2 Перегляд студентів з заборгованістю 
3 Перегляд особистої інформації 
4 Перегляд розкладу 
Для розробки мобільного додатку буде  використовуватись така технологія як 
Flutter [1]. 
Результатом є розроблений та протестований мобільний додаток для викладачів  
який вирішує поточні проблеми викладачів. 
Ключові слова: мобільний застосунок, викладач, університет.  
ABSTRACT  
Denys Dmytrovych  
Mobile application "Teacher of ChDTU" 
121 - Software engineering 
Cherkasy State Technological University 
Cherkasy, 2023  
The qualification work is devoted to the development of a mobile application for 
teachers. The purpose of this work is to develop a convenient and effective tool for university 
teachers, which will contribute to a better organization of the learning process, providing 
access to educational material, simplifying interaction with students and improving the 
quality of learning. 
As part of this thesis, a detailed analysis of the current problems and requirements of 
teachers regarding the application will be performed. Studies of modern approaches to the 
development of mobile applications in the context of education will also be conducted. This 
will reveal the needs of teachers and determine the key functions and capabilities that a 
mobile application should have in order to achieve its goals. 
Based on the knowledge gained, a mobile application will be developed and 
implemented, which will include such functions as:  
1 Viewing groups where the teacher is the curator 
2 View students with debt 
3 Viewing personal information 
4 View schedule  
A technology such as Flutter will be used to develop the mobile application. The result 
is a developed and tested mobile application for teachers that solves the current problems of 
teachers 
Keywords: mobile application, teacher, university 
  
ЗМІСТ 
Вступ .................................................................................................................................. 5 
РОЗДІЛ 1 ........................................................................................................................... 9 
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ .......................................................................................................................... 9 
1.1 Актуальні проблеми що виникають під час виконання завдань ........................ 9 
1.2 Методи та засоби для розв'язання поставлених задач ..................................... 10 
1.3 Конкретизація завдань роботи ............................................................................ 11 
РОЗДІЛ 2 ......................................................................................................................... 12 
ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ ......................................................................................................................... 12 
2.1 Моделювання предметної області ...................................................................... 12 
2.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області ..................................................................................................... 12 
2.1.2 Елементи моделювання предметної області................................................... 13 
2.2 Формування та аналіз вимог ............................................................................... 18 
2.2.1 Формування вимог до програмного забезпечення .................................... 18 
2.2.1.1 Первинні і детальні вимоги ..................................................................... 18 
2.2.1.2 Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги .................................................................................................................... 19 
2.2.2 Формування вимог за допомогою діаграми прецедентів ......................... 21 
2.3 Проектування логічної структури програмного комплексу............................. 22 
2.3.1 Діаграми класів ............................................................................................ 22 
2.4 Архітектурне проектування ................................................................................ 24 
2.4.1 Діаграма компонентів .................................................................................. 24 
2.4.2 Розгортання програмної системи на апаратних засобах. діаграма 
розгортання ............................................................................................................ 26 
2. 5 Моделювання поведінки системи ...................................................................... 27 
2.5.1 Діаграма діяльності ...................................................................................... 27 
     
     
ЧДТУ 231921.007 ПЗ 
Зм Лист № документа Підпис Дата 
Розроб. Плакся Д.Д   Літ. Лист Лист 
ів. 
Мобільний 
Керівник Заспа Г. О.   [н] 3 75 
застосунок 
    
Н. контр. Півень О. Б. “Викладач ФІТІС, 
  
ЧДТУ” Кафедра ПЗАС, 
Затверд. Голуб С. В.   ПЗ-1904 
2.5.2 Діаграма послідовності ............................................................................... 28 
2.5.3 Діаграма комунікації ................................................................................... 29 
2.5.4 Діаграма скінченного автомату .................................................................. 30 
РОЗДІЛ 3 ......................................................................................................................... 31 
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ............... 31 
3.1 Розробка програмного комплексу ...................................................................... 31 
3.1.1 Обґрунтування вибору засобів реалізації .................................................. 31 
3.1.2 Опис структурної (функціональної) схеми ............................................... 32 
3.1.3 Опис логічної схеми системи ..................................................................... 34 
3.1.4 Розробка інтерфейсу користувача .............................................................. 34 
3.1.5 Опис розробки програмних компонентів .................................................. 36 
3.2 Тестування системи ............................................................................................. 37 
3.2.1 Модульне тестування................................................................................... 37 
3.2.2 Інтеграційне тестування .............................................................................. 38 
3.2.3 Системне тестування ................................................................................... 40 
3.2.4 Приймальне тестування .............................................................................. 42 
Висновок ......................................................................................................................... 44 
Список використаних джерел .................................................................................... 47 
ДОДАТОК А ................................................................................................................... 50 
ДОДАТОК Б ................................................................................................................... 52 
ДОДАТОК В ................................................................................................................... 54 
ДОДАТОК Г ................................................................................................................... 65 
     
     ЧДТУ 231921.010 ПЗ 
     
 
ЧДТУ 231921.007 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
IDE – Integrated development environment, Інтегроване 
середовище розробки 
UML – Unified Modeling Language, уніфікована мова 
моделювання 
REST – Representational State Transfer, «передача 
репрезентативного стану» 
HTTP – HyperText Transfer Protocol, протокол передачі даних 
API – Application Programming Interface, інтерфейс 
програмування застосунків 
 5 
 
ЧДТУ 231921.007 ПЗ 
Вступ 
Актуальність теми: тема "Мобільний застосунок "Викладач ЧДТУ" має 
велику актуальність в сучасному світі, де мобільні технології є невід'ємною 
частиною нашого життя. Університетська освіта не є винятком, тому що вона 
стикається з новими викликами та можливостями, що пропонують мобільні 
технології. Таким чином, мобільні застосунки можуть бути корисними для 
викладачів університету в багатьох аспектах. 
Один з головних аспектів, де мобільні застосунки можуть бути 
корисними, - це організація навчання. Мобільний застосунок дозволяє 
викладачам управляти своїми курсами, завданнями та матеріалами для 
навчання. Вони можуть створювати та оновлювати матеріали, надавати доступ 
до курсів та завдань, відстежувати прогрес студентів та надавати зворотний 
зв'язок. Крім того, мобільні застосунки дозволяють викладачам швидко 
оновлювати свої курси та матеріали відповідно до останніх тенденцій та змін у 
своїй галузі. 
Інший аспект, де мобільні застосунки можуть бути корисними, - це 
спілкування зі студентами. Мобільні застосунки можуть стати інструментом для 
зв'язку викладача зі студентами. Викладачі можуть використовувати чат-боти, 
щоб відповідати на запитання студентів, надавати додаткову інформацію та 
надавати підтримку. Це допомагає збільшити ефективність навчання та 
зменшити час, необхідний для відповіді на запитання студентів. 
Третій аспект, де мобільні застосунки можуть бути корисними для 
викладачів університету, - це збільшення доступності до навчання. Мобільні 
застосунки дозволяють студентам навчатися з будь-якого місця та в будь-який 
час, що робить навчання більш гнучким та зручним для студентів. Також 
мобільні застосунки можуть бути корисні для студентів з інвалідністю або 
обмеженими можливостями, які мають складнощі з доступом до традиційних 
форм навчання. Застосунки можуть забезпечити більш доступний та зручний 
спосіб навчання для цієї групи студентів. 
 6 
 
ЧДТУ 231921.007 ПЗ 
В цілому, можна сказати, що мобільні застосунки мають великий 
потенціал для поліпшення процесу навчання та навчання в університетах. Вони 
допомагають забезпечити більш ефективне та доступне навчання для студентів 
та полегшують роботу викладачів, що може допомогти підвищити якість освіти. 
Отже, тема "Мобільний застосунок викладача університету" має велику 
актуальність та є важливою для подальшого розвитку університетської освіти. 
Мета дослідження: Спроектувать мобільний застосунку для викладачів 
університету як інструменту для підвищення якості та результативності 
навчального процесу. 
Для досягнення цієї мети, можна визначити такі завдання дослідження: 
1 Проаналізувати наявність та функціональні можливості мобільних 
застосунків, що використовуються викладачами університету; 
2 Визначити, які функції мобільних застосунків викладачі використовують 
найчастіше, та їх вплив на результативність навчального процесу; 
3 З’ясувати думки викладачів про зручність використання мобільного 
застосунку в роботі та їх оцінку його ефективності; 
4 Вивчити думки студентів про використання мобільного застосунку в 
навчальному процесі та його вплив на якість навчання; 
5 Зробити висновки щодо ефективності використання мобільного 
застосунку викладачами університету в навчальному процесі та 
рекомендації щодо подальшого використання цього інструменту. 
Об'єкт розробки: мобільного застосунку є сам застосунок як інструмент 
для підвищення якості та результативності навчального процесу. У рамках 
дослідження можна вивчати функціональні можливості застосунку, його 
зручність використання викладачами та студентами, а також ефективність його 
впливу на навчальний процес. До об'єкту дослідження також можна включити 
викладачів та студентів, які використовують застосунок, або які могли б 
використовувати його в майбутньому. 
 7 
 
ЧДТУ 231921.007 ПЗ 
Методи проектування та конструювання: функціональні можливості та 
ефективність використання в навчальному процесі. Конкретні аспекти, які 
можна вивчати в рамках дослідження, можуть включати такі питання, як: 
1 функції застосунку та їх призначення в навчальному процесі 
(наприклад, можливості для створення тестів, завдань, збору та аналізу 
результатів тощо); 
2 рівень зручності та доступності застосунку для викладачів та 
студентів; 
3 ефективність використання застосунку в підвищенні якості та 
результативності навчального процесу (наприклад, вплив на рівень знань 
та навичок студентів, підвищення зацікавленості до навчання тощо); 
4 оцінка задоволеності викладачів та студентів від використання 
застосунку та їхні рекомендації щодо його подальшого використання; 
5 переваги та недоліки використання мобільного застосунку 
порівняно з іншими методами та інструментами навчання. 
Інструментарій. При виборі між Flutter, Ionic[2] або React Native[3] для 
розробки мобільного додатку для викладачів університету, я враховував ряд 
факторів і вагомих переваг кожної з цих платформ. Всі платформи мають свої 
особливості, що можуть бути важливими для вашого проекту. Однією з 
ключових переваг Flutter порівняно з Ionic або React Native є його нативна 
продуктивність та швидкодія. Саме тому для розробки мобільного додатку було 
обрано Flutter. 
Також було обрано NEST.JS[4] Framework. Це універсальний фреймворк з 
відкритим вихідним кодом для JS[5]- платформи. 
Для розробки БД було обрано PostgreSQL[6]. Який є рішенням для малих 
і середніх додатків.Зазвичай PostgreSQL використовується як сервер, до якого 
звертаються локальні або видалені клієнти, проте в дистрибутив входить 
бібліотека внутрішнього сервера, що дозволяє включати PostgreSQL в автономні 
програми. 
 8 
 
ЧДТУ 231921.007 ПЗ 
Сформульовані результати досліджень: 
 
1 проаналізовані існуючі методи та засоби розв’язання поставлених 
завдань; 
2 проведено теоретичні дослідження; 
3 проведено проектування програмного забезпечення; 
4 проведено моделювання предметної області; 
5 розроблено та протестовано програмне забезпечення. 
 
Ключові слова: інформаційна система, моделювання, програмне забезпечення, 
тестування програмного забезпечення, вимоги. 
 9 
 
ЧДТУ 231921.007 ПЗ 
Розділ 1 
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ 
1.1 Актуальні проблеми, що виникають в процесі виконання завдань 
Під час проектування та розробки мобільного застосунку для викладачів 
університету можуть виникнути різноманітні проблеми. 
Ось декілька з них: 
1 створення зручного інтерфейсу. Важливо, щоб застосунок був простим та 
зрозумілим для викладачів. Це може стати викликом, оскільки потрібно 
враховувати різні потреби та пріоритети різних користувачів; 
2 інтеграція з існуючими системами. Викладачі вже використовують різні 
інструменти для управління своїми курсами та студентами, такі як 
Deanoffice. Розробка застосунку, який може легко інтегруватися з цими 
системами, може виявитися складною задачею; 
3 забезпечення безпеки даних. Мобільні застосунки мають доступ до 
великої кількості конфіденційної інформації, такої як особисті дані 
студентів та викладачів. Ми повинні забезпечити високий рівень захисту 
цих даних, щоб запобігти несанкціонованому доступу до них; 
4 забезпечення стабільності та швидкості роботи. Важливо, щоб застосунок 
працював швидко та без перебоїв. Це може бути складним завданням, 
особливо якщо викладачі використовують застосунок одночасно та з 
різних місць; 
5 забезпечення сумісності з різними платформами. Оскільки викладачі 
можуть використовувати різні пристрої з різними операційними 
системами, важливо, щоб застосунок працював на різних платформах, 
наприклад, на IOS[7] та Android[8]; 
6 надання корисної функціональності. Важливо, щоб застосунок надавав 
корисні функції для викладачів, такі як можливість перегляду розкладу, 
перегляд груп де викладач куратор; 
 10 
 
ЧДТУ 231921.007 ПЗ 
7 забезпечення зручності використання. Мобільний застосунок має бути 
зручним у використанні та повинен мати інтуїтивно зрозумілий 
інтерфейс. Це допоможе викладачам ефективно використовувати 
застосунок та зекономити час на його вивчення; 
8 відповідність законодавству. Розробники повинні дотримуватися 
законодавства та правил щодо захисту даних, авторських прав та інших 
аспектів, щоб уникнути правових проблем під час розробки та 
експлуатації застосунку. 
1.2 Методи та засоби, які вже використовуються для усунення 
проблем та виконання завдань 
Існують різноманітні методи та засоби розв'язання поставлених задач для 
мобільного застосунку викладача університету, зокрема: 
1 використання готових мобільних фреймворків, таких як Flutter, React 
Native або Xamarin [9]. Ці фреймворки дозволяють розробникам 
створювати крос-платформні [10] мобільні додатки, використовуючи 
єдиний код для різних платформ. Це значно зменшує час розробки та 
витрати на тестування; 
2 використання готових засобів та бібліотек для розробки окремих функцій 
додатку, наприклад, календар, зберігання даних, обробка зображень тощо. 
Це може зменшити час розробки та полегшити процес створення 
мобільного застосунку; 
3 Flutter сам по собі не забезпечує безпеку даних автоматично, оскільки це 
залежить від способу обробки даних та зберігання їх на сервері або в 
мобільному пристрої. Проте, Flutter надає засоби для захисту даних в 
рамках своїх можливостей. Ось кілька способів, якими Flutter ми 
забезпечили безпеку даних. Ми використовували криптографічні 
бібліотеки, такі як flutter_cryptography [11] або flutter_secure_storage [12], 
для шифрування та захисту конфіденційних даних, таких як паролі і 
ключі доступу. Наший додаток взаємодіє з сервером, тому ми повинні 
використовувати безпечне з'єднання HTTPS [13], щоб захистити передачу 
 11 
 
ЧДТУ 231921.007 ПЗ 
даних між клієнтом і сервером. Flutter підтримує з'єднання HTTPS за 
допомогою пакету http [14], який використовує бібліотеку dart:io [15]; 
4 інтеграцію додатку з іншими системами було перенесено на бекенд 
частину. Таким чином всю роботу з іншими системами буде робити 
бекенд, що в свою чергу знімає навантаження з мобільного додатку. 
Вибір конкретного методу та засобу залежить від конкретних потреб та 
вимог проекту, а також від досвіду та навичок розробника. 
1.3 Конкретизація завдань роботи: 
1 створення облікового запису для викладача та налаштування особистого 
кабінету, де буде доступна основна інформація про викладача (ім'я, 
прізвище, контактні дані); 
2 створення сторінки де викладач матиме можливість переглянути список 
груп де він куратор, боржників, а також вибіркові дисципліни студентів; 
3 створення сторінки логіну де викладач матиме змогу запам'ятати 
пароль, щоб не вводити його кожен сеанс роботи з додатком; 
4 перегляд розкладу; 
5 можливість використовувати додаток на різних платформах; 
6 безпечне збереження JWT [16] в пам'яті мобільного додатку. 
Ці завдання стануть основою для розробки мобільного застосунку для 
викладача університету. 
 12 
 
ЧДТУ 231921.007 ПЗ 
Розділ 2 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
СИСТЕМИ 
2.1 Моделювання предметної області 
Перед початком проектування та розробки програми необхідно провести 
аналіз предметної області. Цей процес, відомий як концептуалізація предметної 
області, включає ідентифікацію об'єктів та їх зв'язків, які є необхідними для 
вирішення конкретної задачі. Розуміння бізнес-процесів та потреб замовника є 
важливим етапом, але само по собі недостатнім для створення якісної 
інформаційної системи. Необхідно також визначити, яку саме інформацію система 
повинна обробляти і які зв'язки існують між об'єктами. 
Мета побудови моделі предметної області полягає в створенні графічного 
відображення логічної структури предметної області. Логічна модель предметної 
області включає класи та їх взаємозв'язки, що ілюструють сутність цих елементів. 
Побудова моделі починається з ідентифікації абстракцій, які існують у реальному 
світі, тобто основних концептуальних об'єктів, присутніх у системі. 
Якщо використовувати ітеративний процес розробки програмного 
забезпечення, то кожній ітерації відповідатиме своя модель предметної області, 
яка відображатиме сценарії прецедентів, реалізовані на даному етапі. Таким 
чином, модель предметної області змінюється та розвивається протягом процесу 
розробки системи. 
Модель предметної області є важливою моделлю об'єктно-орієнтованого 
аналізу, яка відображає концептуальні класи або об'єкти реального світу в 
термінах предметної області, а не програмні компоненти. Це своєрідний словник 
основних абстракцій у просторі задачі. Доменні об'єкти, що описують поняття з 
предметної області, є основними елементами моделі предметної області. Зазвичай 
ця модель відображається на діаграмі класів, яка представляє собою візуальний 
словник важливих абстракцій або візуальний словник предметної області. 
Побудова моделі починається з ідентифікації абстракцій, які існують у 
реальному світі, тобто основних концептуальних об'єктів, присутніх у системі. 
 13 
 
ЧДТУ 231921.007 ПЗ 
Якщо використовувати ітеративний процес розробки програмного забезпечення, 
такий як Rational Unified Process (RUP) [17] або екстремальне програмування 
(eXtreme Programming, XP) [18], то кожній ітерації відповідатиме своя модель 
предметної області, яка відображає сценарії прецедентів, реалізовані на даному 
етапі. 
Таким чином, модель предметної області змінюється та розвивається 
протягом процесу розробки системи. 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Модель  предметної  області  –  це  найважливіша  модель 
об’єктно-орієнтованого аналізу, яка відображає візуальне подання 
концептуальних класів або об’єктів реального світу в термінах предметної 
області, а не програмні компоненти. Такі моделі також називають 
концептуальними моделями або моделями об’єктів предметної області. Це свого 
роду словник основних абстракцій, тобто найважливіших іменників у просторі 
задачі. 
Іменники, які описують поняття з предметної області, називають 
доменними об’єктами. На самому початку аналізу і проектування необхідно 
створити модель предметної області, в якій всі доменні об’єкти будуть 
зображені на одній великій діаграмі класів. 
У термінології UML [19] модель предметної області – це діаграма класів. 
Зазвичай в цій моделі опускається велика частина деталей, зокрема атрибути та 
операції (методи) класів. Ось чому можна вважати, що модель предметної 
області є зведеною діаграмою класів, як візуальний словник важливих 
абстракцій або візуальний словник предметної області. 
Словник  предметної  області  –  часто  згадуване  поняття 
об’єктно-орієнтованого  аналізу  і  проектування.  Усі  теоретики 
об’єктно-орієнтованого підходу стверджують, що словник термінів предметної 
області – найважливіший артефакт, що лежить в основі аналізу і проектування, 
 14 
 
ЧДТУ 231921.007 ПЗ 
яким автори прецедентів можуть користуватися. 
2.1.2 Елементи моделювання предметної області 
У об’єктно-орієнтованих системах структура коду визначається класами 
(узагальненими об’єктами). Класифікація означає, що об’єкти з однаковими 
структурами даних (атрибутами) і поведінкою (операціями) групуються у класи. 
Тому, перш ніж приступати до кодування, треба з’ясувати, які класи 
знадобляться. З цією метою слід намалювати одну або декілька діаграм класів. 
Насправді, це перший крок до отримання справжньої діаграми класів, при якій 
потрібно представити систему в цілому. Потім у процесі роботи над 
прецедентами поступово уточнюються діаграми і врешті-решт буде отримано 
детальну статичну модель системи. 
Модель предметної області повинна бути побудована до складання 
варіантів використання, щоб уникнути дублювання понять. Якщо схожі назви 
потрапляють в тексти варіантів використання, то знайти їх там набагато 
складніше, ніж у словнику проекту. Модель предметної області, яка є діаграмою 
класів аналітичного рівня, – перше наближення до статичної структури 
системи. 
Вимоги до системи зазвичай виглядають як фрази, побудовані у вигляді 
тверджень: система повинна робити те і не повинна робити це. Тобто, кращими 
джерелами класів, мабуть, є високорівневий опис завдання, високорівневі 
вимоги, описи прецедентів, і експертна оцінка завдання. У міру уточнення 
даного переліку необхідно враховувати, що: 
– іменники та іменні групи стають об’єктами і атрибутами; 
 
– дієслова і дієслівні групи стають операціями і асоціаціями; 
 
– родовий відмінок показує, що іменник має бути атрибутом, а не 
об’єктом. 
Для моделювання предметної області та при проектуванні системи в 
цілому будемо використовувати мову UML Для діаграм мови UML існують три 
 15 
 
ЧДТУ 231921.007 ПЗ 
типи візуальних позначень: графічні символи, зв’язки (єднальні елементи), 
текст (рисунок 2.1-2.2). 
 
 
Рисунок 2.1 – Основні графічні символи UML 
 
Рисунок 2.2 – Єднальні елементи UML 
 16 
 
ЧДТУ 231921.007 ПЗ 
Більшість розробників при створенні ПЗ задіють лише невелику 
підмножину мови UML. Необхідно знайти свою підмножину, яка б підходила 
для розв’язання вашої задачі. 
При проектуванні ПЗ кваліфікаційної роботи необхідно використовувати 
основні діаграми мови UML для моделювання предметної області, формування 
та аналізу вимог до системи, логічної і фізичної структури та поведінки системи 
(рисунок 2.3). 
 
 
Рисунок 2.3 – Основні діаграми UML 
Під час виявлення об'єктів у предметній області важливо встановити 
взаємозв'язки між ними. Два основних види відношень, які особливо цікавлять 
нас, це узагальнення і агрегація. Узагальнення відображає відношення між 
підкласом і суперклассом, позначається символом "<|––" і вказує на існування 
відношення "є". Агрегація відображає відношення між цілим об'єктом і його 
частинами, позначається символом "<>––" і вказує на існування відношення "має". 
Поміж класів предметної області можуть існувати інші типи відношень, 
включаючи прості асоціації, позначені символом "–––". Однак, узагальнення та 
агрегація є особливо важливими видами відношень. Класи, які відображають 
модель предметної області, потім використовуються для побудови статичної 
моделі на діаграмі класів. 
 17 
 
ЧДТУ 231921.007 ПЗ 
У результаті модель предметної області, доповнена асоціаціями 
(статичними відношеннями) між парами класів, повинна адекватно описувати 
аспекти завдання, не залежні від часу (статичні), і в цьому нагадувати діаграми 
сутність-зв’язок, що використовуються в моделюванні даних. 
Необхідно також відвести фіксований час на побудову початкової моделі 
предметної області. Не потрібно домагатися її досконалості, просто необхідно її 
закінчити швидше, а потім модифікувати у міру просування вперед. 
Класи в UML – це місце для розміщення атрибутів (даних-членів) і 
операцій (функцій, що виконуються об’єктами). Проте, починаючи моделювати 
предметну область, не потрібно витрачати багато часу на ідентифікацію 
атрибутів і операцій; це потрібно буде робити при уточненні і наповненні 
статичної частини моделі. 
Враховуючи потреби викладачів та особливості університетського 
середовища, я визначив основні сутності, такі як викладачі, курси, студенти, 
оцінки тощо. Для кожної сутності визначив властивості, наприклад, викладач 
може мати ім'я, прізвище, спеціальність, а студент - ім'я, прізвище, номер групи. 
Також встановив взаємозв'язки між сутностями. Наприклад, викладач 
може вести кілька курсів, а студенти можуть бути зареєстровані на певні курси. 
Взаємозв'язки допомагають відтворити взаємодію між сутностями в рамках 
університетської системи. 
Щодо інтерфейсу додатку, я врахував простоту використання та зручність 
для викладачів. Додаток повинен мати інтуїтивно зрозумілий інтерфейс, 
зроблений відповідно до дизайну з урахуванням принципів юзабіліті. 
Нарешті, при моделюванні предметної області мобільного додатку 
викладача університету, я врахував особливості університетського середовища, 
такі як захист конфіденційної інформації та вимоги щодо безпеки даних. 
Застосувавши відповідні обмеження та правила, забезпечив безпеку і 
конфіденційність даних в додатку. 
Отже, з урахуванням вищезазначеного, я моделював предметну область 
мобільного  додатку  викладача  університету,  створюючи  структуру, 
 18 
 
ЧДТУ 231921.007 ПЗ 
взаємозв'язки та функціональність, що відповідають потребам викладачів та 
вимогам університетського середовища. 
2.2 Формування та аналіз вимог 
2.2.1 Формування вимог до програмного забезпечення 
2.2.1.1 Первинні і детальні вимоги 
Аналіз вимог - це процес розуміння та документування того, що система 
повинна здійснювати і якими умовами вона повинна задовольняти. Його мета - 
виявити, обговорити і зафіксувати, що саме потрібно від системи, у зрозумілій 
формі як для клієнтів, так і для розробників. Результатом аналізу вимог є 
документ, який називається специфікацією вимог або специфікацією вимог до 
програмного забезпечення. 
Для моделювання і опису процесів розробки додатку використовують 
уніфіковану мову моделювання (UML). Усі діаграми в UML можна умовно 
розділити на дві категорії: поведінкові і структурні. 
Поведінкові діаграми відображають процеси, які відбуваються в модельованому 
середовищі. Вони дозволяють представити послідовність дій, взаємодію 
об'єктів та інші аспекти системи. 
Структурні діаграми відображають елементи, з яких складається система. 
Вони використовуються для проектування архітектури системи і відображають 
компоненти, класи, залежності між ними тощо. 
Усі ці типи діаграм можуть використовуватися як для моделювання 
бізнес-процесів, так і для проектування архітектури системи. 
Розрізняють дві категорії представлення вимог: вимоги замовника 
(первинні вимоги) і вимоги розробника (детальні вимоги). Відрізняються вони 
одна від одної мірою опрацювання описів. 
Первинні вимоги документують бажання і потреби замовника і пишуться 
мовою, зрозумілою замовникові. Роботу із створення первинних вимог 
називають збором або формуванням вимог. На стадії проектування вимоги 
відображаються діаграмою прецедентів (варіантів використання, Use Case). 
 19 
 
ЧДТУ 231921.007 ПЗ 
Детальні вимоги документуються у спеціальній, структурованій формі, 
вони деталізовані стосовно до первинних вимог. Роботу зі створення детальних 
вимог називають аналізом вимог. На стадії проектування детальні вимоги 
документуються спеціальною структурованою мовою за допомогою діаграм 
діяльності та діаграм взаємодії. 
Деякі проблеми можуть бути породжені відсутністю чіткого розуміння 
відмінності між цими категоріями вимог. Пояснимо відмінність між ними. 
Наприклад, вимога замовника має вигляд: 
2.2.1.2 Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги 
ВИМОГИ ЗАМОВНИКА 
1 ПЗ повинно забезпечити можливість перегляду розкладу; 
2 ПЗ повинно забезпечити можливість перегляду вільних дат для відпустки; 
3 ПЗ повинно забезпечити можливість заповнення певної інформації через 
додаток. 
ВИМОГИ РОЗРОБНИКА 
1.1 викладач повинен мати можливість перегляду розкладу студентів груп, 
в якій він є куратором; 
1.2 викладач повинен мати можливість перегляду розкладу дисциплін, які 
він викладає; 
1.3 викладач повинен мати можливість перегляду розкладу за довільними 
параметрами; 
2.1 викладач повинен мати можливість побачити дати відпусток 
заброньовані іншими викладачами; 
3.1 викладач повинен мати можливість виставити семестрові оцінки 
студентові за дисципліну (екзамен або залік); 
3.2 викладач повинен мати можливість обирати студентам теми 
кваліфікаційної роботи; 
2.1.3 Робоча область моделювання 
 20 
 
ЧДТУ 231921.007 ПЗ 
Робоча область моделювання програмування охоплює використання 
різних методів та технік для дослідження та аналізу програмних систем. Вона 
займається вивченням різних аспектів програмування, таких як алгоритми, 
структури даних, архітектури програмного забезпечення та процеси розробки 
програмного забезпечення. 
Один з видів моделювання програмування - це математичне моделювання, 
яке використовує математичні методи для опису програмних систем та їх 
взаємодій. Це дозволяє досліджувати та аналізувати різні аспекти програмного 
забезпечення, такі як його ефективність, надійність, безпека та інші. 
Інший тип моделювання програмування - це моделювання процесу 
розробки програмного забезпечення. Це включає в себе використання моделей, 
що описують етапи та процеси розробки програмного забезпечення, що 
дозволяє поліпшувати якість та ефективність розробки програмного 
забезпечення. 
Інші методи моделювання програмування включають в себе використання 
графічних моделей та схем, що дозволяють візуалізувати та аналізувати 
програмні системи та їхні взаємодії. Це може включати в себе моделювання 
процесів взаємодії між користувачами та програмним забезпеченням, а також 
візуалізацію структури та компонентів програмного забезпечення. 
Робоча область моделювання програмування є дуже важливою для 
розробки програмного забезпечення, оскільки вона дозволяє досліджувати та 
аналізувати програмні системи з різних точок зору та покращувати їх якість 
При моделюванні предметної області для мобільного додатку викладача 
університету, я провів детальний аналіз вимог та особливостей цієї області. 
Враховуючи потреби викладачів та особливості університетського 
середовища, я визначив основні сутності, такі як викладачі, курси, студенти, 
оцінки тощо. Для кожної сутності визначив властивості, наприклад, викладач 
може мати ім'я, прізвище, спеціальність, а студент - ім'я, прізвище, номер групи. 
Також встановив взаємозв'язки між сутностями. Наприклад, викладач 
може вести кілька курсів, а студенти можуть бути зареєстровані на певні курси. 
 21 
 
ЧДТУ 231921.007 ПЗ 
Взаємозв'язки допомагають відтворити взаємодію між сутностями в рамках 
університетської системи. 
Однією з ключових функцій мобільного додатку для викладачів є 
можливість перегляду розкладу. Тому я врахував функціональність, що дозволяє 
викладачам отримувати доступ до розкладу за групою та викладачем. 
Щодо інтерфейсу додатку, я врахував простоту використання та зручність 
для викладачів. Додаток повинен мати інтуїтивно зрозумілий інтерфейс, 
зроблений відповідно до дизайну з урахуванням принципів юзабіліті. 
Нарешті, при моделюванні предметної області мобільного додатку 
викладача університету, я врахував особливості університетського середовища, 
такі як захист конфіденційної інформації та вимоги щодо безпеки даних. 
Застосувавши відповідні обмеження та правила, забезпечує безпеку і 
конфіденційність даних в додатку. 
Отже, з урахуванням вищезазначеного, я моделював предметну область 
мобільного додатку викладача університету, створюючи структуру, 
взаємозв'язки та функціональність, що відповідають потребам викладачів та 
вимогам університетського середовища. 
 
 
Рисунок 2.4 – Робоча область 
2.2.2 Формування вимог за допомогою діаграми прецедентів 
 22 
 
ЧДТУ 231921.007 ПЗ 
 
 
Рисунок 2.5 – діаграми прецедентів 
 
 
2.3 Проектування логічної структури програмного комплексу 
2.3.1 Діаграми класів 
Діаграма класів - це графічний інструмент для моделювання програмного 
коду, який візуально відображає структуру класів, їх атрибути та методи, а 
також зв'язки між ними. Кожен клас представлений у діаграмі у вигляді 
прямокутника, де вказується його назва, вміст та атрибути. 
Атрибути класу - це властивості, що визначають його характеристики, і 
вони записуються під назвою класу у вигляді змінних.Методи класу визначають 
його поведінку та дії, які він може виконувати, і зазвичай записуються під 
атрибутами у вигляді функцій. 
Зв'язки між класами в діаграмі класів можуть використовувати різні типи 
залежностей, такі як агрегація, композиція, спадкування та залежності. Ці 
зв'язки демонструють, як класи взаємодіють один з одним та як вони 
взаємодіють з об'єктами інших класів. 
 23 
 
ЧДТУ 231921.007 ПЗ 
У діаграмі класів також можуть бути представлені інші елементи, такі як 
інтерфейси, переліки, структури та нумерації. Ці елементи допомагають уявити 
структуру програми та взаємодії між її компонентами. 
В процесі проектування діаграми класів для мобільного застосунку я 
враховував різні аспекти. Спочатку я аналізував вимоги до застосунку, щоб 
зрозуміти його функціональність та потреби користувачів. На основі цього 
аналізу я ідентифікував основні класи, які будуть присутні в системі. 
Далі я визначив зв'язки між класами та їх взаємодію. Це включало 
визначення асоціацій, композицій, агрегацій та спадкування між класами. Я 
враховував логіку системи та потреби користувачів, щоб встановити правильні 
зв'язки. 
Після цього я визначив атрибути та методи для кожного класу. Я 
зосередився на тих атрибутах та методах, які були необхідні для досягнення 
функціональності застосунку. Наприклад, для класу "Викладач" я визначив 
атрибути, такі як ім'я, електронна пошта та пароль, а також методи для 
авторизації та реєстрації. 
Я також враховував принципи об'єктно-орієнтованого програмування, такі 
як інкапсуляція, спадкування та поліморфізм, при проектуванні діаграми класів. 
Це допомогло забезпечити модульність та розширюваність системи. 
Крім того, я планував структуру діаграми класів, забезпечуючи чистоту та 
зрозумілість коду. Я групував класи за функціональними блоками та 
використовував зрозумілі назви класів та методів, щоб полегшити розуміння 
системи іншими розробниками. 
Усе це допомогло мені створити діаграму класів для мобільного 
застосунку, яка ясно відображає структуру системи, взаємозв'язки між класами 
та їх функціональність. 
Можна виділить такі класи: 
1 користувач: Представляє користувача додатку. Може мати атрибути, такі 
як ім'я, прізвище, електронна пошта та пароль; 
 24 
 
ЧДТУ 231921.007 ПЗ 
2 викладач: Підклас користувача, який відображає викладача ЧДТУ. Може 
мати додаткові атрибути, пов'язані з викладацькою діяльністю, наприклад, 
кафедра, посада тощо; 
3 студент: Представляє окремого студента в групі. Може мати такі 
атрибути як ім'я, фамілія, прізвище, група, вибіркові дисципліни тощо; 
4 група: Представляє окрему групу, на факультеті в ЧДТУ. Може мати 
атрибути, такі як назва групи, код, факультет тощо; 
5 розклад: Представляє розклад занять. Містить інформацію про час, місце і 
курс, що проводиться. 
 
 
 
 
Рисунок 2.6 - Діаграма класів 
 25 
 
ЧДТУ 231921.007 ПЗ 
2.4 Архітектурне проектування 
2.4.1 Діаграма компонентів 
Діаграма компонентів (Component diagram) - це графічний засіб 
моделювання структури системи, що дозволяє відобразити компоненти 
системи, їх взаємозв'язки та взаємодію між ними. 
На діаграмі компонентів компоненти зображаються у вигляді 
прямокутників, а взаємозв'язки між ними - у вигляді ліній, що вказують на 
залежності та взаємозв'язки між компонентами. Компонент може бути 
представлений як фізичний об'єкт, наприклад, комп'ютер або сервер, або як 
логічний об'єкт, наприклад, бібліотека або база даних. 
Діаграма компонентів дозволяє відобразити структуру системи, розбити її 
на складові частини та визначити взаємодію між ними. Ця діаграма може 
допомогти розробникам зрозуміти, які компоненти повинні бути розроблені та 
як вони мають взаємодіяти між собою. Крім того, вона може допомогти в 
плануванні тестування, управлінні ризиками та підвищенні ефективності 
розробки. 
При проектуванні діаграми компонентів для мобільного застосунку я 
виконав наступні кроки: 
1. визначення основних компонентів: Ідентифікував основні компоненти, які 
будуть використовуватись у застосунку, такі як користувацький інтерфейс 
(UI), логіка додатку, база даних і зовнішні сервіси; 
2. встановлення взаємозв'язків між компонентами: Визначив зв'язки та 
залежності між компонентами, щоб відобразити, як вони взаємодіють між 
собою. Наприклад, можуть бути залежності між компонентами UI та 
логікою додатку, а також між логікою додатку та базою даних; 
3. врахування границь компонентів: Визначив межі кожного компонента та 
його інтерфейси. Це дозволяє чітко визначити, як компоненти 
взаємодіють один з одним та які функції доступні через їх інтерфейси; 
 26 
 
ЧДТУ 231921.007 ПЗ 
4. розподіл функціональності: Розподілив функціональність між різними 
компонентами, забезпечуючи, що кожен компонент відповідає за 
конкретну частину логіки або функціоналу застосунку; 
5. розгляд безпеки та захисту: Врахував аспекти безпеки та захисту при 
проектуванні діаграми компонентів. Відмічав компоненти, які містять 
конфіденційну інформацію або потребують особливих заходів безпеки; 
6. використання стандартних компонентів: Враховував наявність 
стандартних компонентів або бібліотек, які можна використовувати в 
застосунку, замість розроблення нових компонентів; 
7. розгляд масштабування та розширення: Забезпечував гнучкість системи. 
У Flutter компоненти організовані в ієрархію і складаються з віджетів. 
Віджети - це будівельні блоки, з яких ви можете створювати власні компоненти. 
Вони можуть бути зведені до двох основних категорій: StatelessWidget [20] 
(віджет без стану) та StatefulWidget [21] (віджет зі станом). 
У системі управління станом додатку я використовую бібліотеку Bloc [22]. 
Bloc - це простий та потужний пакет управління станом, що дозволяє ефективно 
передавати та оновлювати дані між компонентами додатку. 
 
Рисунок 2.7 - Діаграма загальної комунікації 
 27 
 
ЧДТУ 231921.007 ПЗ 
 
 
Рисунок 2.8 - Діаграма комунікації на прикладі перегляду груп 
2.4.2 Розгортання програмної системи на апаратних засобах. діаграма 
розгортання 
Для роботи системи потрібно лише персональний телефон на якому буде 
запускатись збілджений APK [23] для виводу результатів роботи системи 
рис.2.8. 
 
 
 
Рисунок 2.9 – Діаграма розгортання апаратних засобів системи 
 28 
 
ЧДТУ 231921.007 ПЗ 
 
2.5 Моделювання поведінки системи 
2.5.1 Діаграма діяльності 
Діаграма діяльності (Activity diagram) - це графічний засіб моделювання 
бізнес-процесів та системних функцій, що використовуються в розробці 
програмного забезпечення та проектуванні систем. 
Ця діаграма може відображати послідовність дій, різні види активностей, 
рішення та умови, що дозволяють розробникам та іншим учасникам проекту 
зрозуміти, як взаємодіють різні частини системи, що відбувається в процесі 
виконання дій та які рішення приймаються. 
За  допомогою  діаграми  діяльності  можна  легко  представити 
бізнес-процеси та інші складні процеси у вигляді послідовності кроків, що 
дозволяє виявляти помилки та оптимізувати роботу системи. 
1. викладач відкриває додаток на своєму мобільному пристрої і виконує вхід 
до системи, вводячи свої облікові дані; 
2. система перевіряє введені дані викладача для аутентифікації [24] та 
перевіряє їх на вірність; 
3. після успішної аутентифікації система перенаправляє викладача на 
особистий кабінет; 
4. в додатку викладач може перейти до сторінки з інформацією про групи; 
5. система відображає списки груп, де викладач куратор. Кожна група може 
мати назву, номер групи та іншу інформацію, яку викладач може 
переглядати; 
6. після закінчення перегляду інформації про групу викладач може 
повернутися до списку груп або вибрати іншу сторінку для перегляду; 
7. коли викладач завершує перегляд інформації про групи та більше не має 
дій, він може вийти з додатку або перейти до інших функцій системи. 
 29 
 
ЧДТУ 231921.007 ПЗ 
 
 
 
 
Рисунок 2.10 - Діаграма діяльності 
 
2.5.2 Діаграма послідовності 
Діаграма послідовності (Sequence diagram) - це один з графічних засобів 
моделювання взаємодії між об'єктами в системі або програмному забезпеченні. 
Ця діаграма дозволяє відобразити послідовність повідомлень, які 
відправляються між об'єктами, що беруть участь у взаємодії, та час, що 
потрібний для їх виконання. Діаграма послідовності є одним з ключових 
інструментів для проектування системи та забезпечення правильного 
спілкування між різними компонентами системи. 
На діаграмі послідовності об'єкти зображаються у вигляді вертикальних 
ліній, які називаються лініями життя, а повідомлення між ними - у вигляді 
стрілок, що вказують напрямок передачі повідомлення. Діаграма може містити 
різні види повідомлень, такі як синхронні, асинхронні, повернення, виключення 
 30 
 
ЧДТУ 231921.007 ПЗ 
тощо, що дозволяє більш детально відобразити взаємодію між об'єктами в 
системі. 
 
 
Рисунок 2.11 - Діаграма послідовності «Перегляд груп» 
 
2.5.3 Діаграма комунікації 
Діаграма комунікації (Communication diagram) - це графічний засіб 
моделювання взаємодії між об'єктами в системі або програмному забезпеченні. 
Ця діаграма дозволяє відобразити взаємодію між об'єктами в системі за 
допомогою повідомлень, що передаються між ними. На діаграмі комунікації 
об'єкти зображуються у вигляді прямокутників, а повідомлення - у вигляді 
стрілок, що вказують напрямок передачі повідомлення. 
Ця діаграма є дуже схожою на діаграму послідовності, проте вона може 
бути корисною для моделювання складних взаємодій, де повідомлення 
передаються між багатьма об'єктами. 
Діаграма комунікації дозволяє показати послідовність повідомлень між 
об'єктами, їх типи, параметри, час, необхідний для передачі повідомлень та 
може відобразити взаємодію в реальному часі. Ця діаграма є корисним 
 31 
 
ЧДТУ 231921.007 ПЗ 
інструментом для розуміння інтерфейсів та взаємодії між об'єктами в складних 
системах. 
 
Рисунок 2.12 - Діаграма комунікації 
 
 
2.5.4 Діаграма скінченного автомату 
 
 
 
 
 
Рисунок 2.13 - Діаграма скінченного автомату 
 32 
 
ЧДТУ 231921.007 ПЗ 
Розділ 3 
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
3.1 Розробка програмного комплексу. 
3.1.1 Обґрунтування вибору засобів реалізації. 
Вибір Flutter як засобу реалізації мого проекту має декілька обґрунтувань. 
Перш за все, Flutter є кросплатформеним фреймворком розробки, що дозволяє 
створювати мобільні додатки для різних платформ, таких як Android та iOS, з 
єдиною кодовою базою. Це означає, що я можу писати один набір коду і 
запускати його на різних пристроях, що збільшує продуктивність та зменшує 
зусилля для розробки та підтримки додатків на різних платформах. Крім того, 
Flutter забезпечує швидкодію завдяки використанню власного движка 
рендерингу Skia [25]. Цей движок дозволяє створювати високопродуктивні 
додатки з багатошаровим рендерингом, що забезпечує плавну анімацію та 
відзивчивий інтерфейс користувача. 
Багатошаровий рендеринг також сприяє легкості реалізації власного 
дизайну та забезпечує високу якість візуального відображення мого додатку. 
Flutter також надає багатий набір вбудованих віджетів, що спрощує розробку 
різноманітних елементів інтерфейсу користувача. За допомогою цих віджетів я 
можу швидко створювати та налаштовувати різні елементи додатку, що 
дозволяє ефективно використовувати свій час та зусилля при розробці. Крім 
того, Flutter має активну та розгалужену спільноту розробників, яка забезпечує 
підтримку, документацію та велику кількість готових рішень та пакетів для 
використання у моєму проекті. 
Додатково, Flutter має вбудовану підтримку гарячого перезавантаження 
(hot reload [26]), що дозволяє швидко бачити зміни в реальному часі під час 
редагування коду. Це значно прискорює процес розробки та дозволяє швидко 
вносити зміни та перевіряти їх ефект без необхідності повного 
перекомпілювання [27] додатку. 
 33 
 
ЧДТУ 231921.007 ПЗ 
Крім того, Flutter підтримує використання розширених можливостей та 
сторонніх плагінів. Я можу легко інтегрувати функціональність зовнішніх 
бібліотек або API [28], що дозволяє розширити можливості мого додатку та 
використовувати існуючі рішення для реалізації певних функціональних вимог. 
Загалом, вибір Flutter як засобу реалізації проекту зумовлений його 
кросплатформенністю, швидкодією, багатим набором віджетів, активною 
спільнотою розробників, можливістю гарячого перезавантаження та 
розширеними можливостями. Цей фреймворк дозволяє ефективно розробляти 
високоякісні та мультиплатформенні додатки з невеликими зусиллями та 
часовими витратами. 
3.1.2 Опис структурної (функціональної) схеми 
Структурна (функціональна) схема є інструментом, що використовується 
для візуалізації і опису функціональної організації складних систем. Вона 
зображає взаємозв'язки та взаємодії між компонентами системи, які можуть 
бути фізичними або логічними елементами. Структурна схема відображає 
структуру системи, тобто як компоненти пов'язані між собою і як вони 
взаємодіють, а також описує їх функції та взаємозалежності. 
Опис структурної схеми допомагає зрозуміти, як працює система в 
цілому, відображаючи її основні складові та їх залежності. Це дозволяє 
аналізувати, оптимізувати та покращувати систему, а також спрощує розробку 
нових компонентів або модифікацію існуючих. Структурна схема забезпечує 
уявлення про загальну архітектуру системи і служить основою для подальшого 
проектування, розробки та управління системою. Вона є ефективним 
інструментом для комунікації між розробниками, інженерами та іншими 
зацікавленими сторонами, оскільки надає графічне відображення системи, що є 
більш доступним і зрозумілим, ніж текстовий опис. 
Структурна схема також полегшує розробку нових компонентів або 
внесення змін до існуючих. Крім того, вона є ефективним інструментом для 
комунікації між розробниками, інженерами та іншими учасниками проекту, 
 34 
 
ЧДТУ 231921.007 ПЗ 
оскільки забезпечує графічне відображення системи, що є більш доступним і 
зрозумілим, ніж простий текстовий опис. 
Розглянемо на рис 3.1 структурну схему застосунку. 
 
 
Рисунок 3.1 - Структурна схема застосунку 
 35 
 
ЧДТУ 231921.007 ПЗ 
3.1.3 Опис логічної схеми системи 
 
Рисунок 3.2 - Логічна схема застосунку 
 
 
3.1.4 Розробка інтерфейсу користувача 
Розробка інтерфейсу користувача є ключовим етапом в процесі створення 
програмного продукту. Вона вимагає уваги до деталей та зосередженості на 
потребах користувача. Ефективність інтерфейсу полягає в здатності 
передбачити вимоги користувачів та забезпечити зручну взаємодію з 
інформаційною системою. 
Процес проектування інтерфейсу користувача включає наступні етапи: 
1 аналіз вимог користувачів: Ретельний аналіз потреб та очікувань 
користувачів є важливим кроком у проектуванні інтерфейсу. Це включає 
розуміння цільової аудиторії, їхніх завдань та контексту використання 
продукту; 
2 розробка інформаційної архітектури: Планування та організація 
структури  інформації  у  продукті.  Це  включає  розташування  та 
 36 
 
ЧДТУ 231921.007 ПЗ 
організацію різних елементів інтерфейсу, таких як меню, навігаційні 
панелі та секції; 
3 створення прототипів: Розробка прототипів допомагає візуалізувати та 
перевірити функціональність інтерфейсу перед його реалізацією. Це може 
бути набір макетів екранів, що демонструють основні функції та 
взаємодію елементів інтерфейсу; 
4 вибір стилістики та дизайну: Розробка привабливого та зручного для 
використання дизайну інтерфейсу. Враховуючи брендові вимоги, 
вибираються кольори, шрифти, графічні елементи та компоненти; 
5 реалізація інтерфейсу на Flutter: Після визначення дизайну та стилістики 
інтерфейсу можна перейти до реалізації за допомогою Flutter. Flutter надає 
багато вбудованих віджетів, які можна використовувати для побудови 
інтерфейсу. Використовуючи ці віджети, ви можете створювати кнопки, 
тексти, списки, форми та інші елементи, необхідні для вашого додатка; 
6 тестування та відладка: Після реалізації інтерфейсу важливо протестувати 
його на різних пристроях та розмірах екрану, щоб переконатися, що він 
виглядає та працює належним чином. Виправте будь-які помилки, які 
виявляються під час тестування, та вдоскональте інтерфейс для кращої 
взаємодії з користувачем; 
7 оптимізація та покращення: Після завершення реалізації інтерфейсу 
можна провести оптимізацію для забезпечення плавності та 
продуктивності додатка. Ви можете використовувати різні методи для 
оптимізації, такі як лінива загрузка [29] контенту, кешування [30] даних та 
покращення швидкості завантаження; 
8 постійне вдосконалення: Інтерфейс користувача - це живий елемент 
програмного продукту, і він може змінюватися з часом. Слухайте 
зворотний зв'язок користувачів та збирайте дані про використання, щоб 
розуміти, як покращити інтерфейс та надати більш зручний досвід для 
користувачів. 
 37 
 
ЧДТУ 231921.007 ПЗ 
 
3.1.5 Опис розробки програмних компонентів 
 
Рисунок 3.3 - Схема програмних компонентів 
Widget є основним будівельним блоком для створення інтерфейсу 
користувача. Віджет можна розглядати як невелику частину екрану, яка може 
бути видимою, інтерактивною або статичною. 
Віджети використовуються для створення різноманітних елементів 
інтерфейсу, таких як кнопки, тексти, зображення, поля вводу, списки та багато 
іншого. Вони можуть мати різні властивості, наприклад, розмір, колір, шрифт, 
обробники подій та макет. 
BLoC (Business Logic Component) - це паттерн управління станом, який 
використовується в архітектурі Flutter для відокремлення бізнес-логіки від 
інтерфейсу користувача.BLoC базується на концепції подій, стану і потоків 
даних. Основна ідея полягає в тому, що вся бізнес-логіка розміщується в 
окремому компоненті, який називається BLoC. BLoC слідкує за станом додатку 
і обробляє події, які впливають на цей стан. 
У BLoC є два основні компоненти: 
1 події (Events [31]): Це вхідні події або дії, які відбуваються в додатку, 
наприклад, натискання кнопок або завантаження даних; 
2 стан (State [32]): Це поточний стан додатку, який може змінюватися 
внаслідок обробки подій. Кожен стан є незмінним об'єктом. 
Репозиторій (repository [33]) - це обгортка навколо одного або кількох 
постачальників даних, з якими взаємодіє шар BLoC. 
Провайдер (providers [34]) - це провайдер даних для додатку. Його 
основна роль - це робити запити на бекенд отримати відповідь і передати її до 
репозиторію. 
 38 
 
ЧДТУ 231921.007 ПЗ 
3.2 Тестування системи 
3.2.1 Модульне тестування 
Модульне тестування в Flutter дозволяє вам перевірити окремі модулі або 
функціональні частини вашого додатку з метою виявлення помилок і 
переконання у їх правильному функціонуванню. Ось деякі важливі аспекти 
модульного тестування в Flutter: 
1 пакет flutter_test [35]: У Flutter для модульного тестування 
використовується пакет flutter_test, який містить класи та функції, що 
допомагають писати й запускати тести; 
2 функція test(): Головним елементом модульних тестів є функція test(), яка 
дозволяє вам описати тестовий сценарій. Ви можете використовувати 
різні методи expect() для перевірки очікуваних результатів; 
3 віртуальний апарат WidgetTester: Якщо ви хочете тестувати віджети 
Flutter, вам знадобиться віртуальний апарат WidgetTester. Він дозволяє вам 
запускати тести для віджетів та взаємодіяти з ними, перевіряти їх стан та 
реакцію на різні події; 
4 асинхронні тести: У Flutter модульні тести можуть бути асинхронними, 
оскільки багато операцій, таких як анімація чи мережеві запити, є 
асинхронними за своєю природою. Ви можете використовувати ключове 
слово async та метод tester.pump() для взаємодії з асинхронними 
операціями в тестах; 
5 групування тестів: Ви можете групувати тести, щоб зручно організувати 
вашу тестову сутність. Ви можете використовувати функцію group() для 
створення груп тестів та ієрархічної структури для організації ваших 
тестів; 
6 запуск тестів: Ви можете запустити свої модульні тести з командного 
рядка, використовуючи команду flutter test. Це запустить усі 
модульні тести в вашому проекті та поверне результати в консолі. Ви 
також можете виконати тести з інтегрованого середовища розробки (IDE 
[36]), натиснувши на відповідну кнопку або комбінацію гарячих клавіш; 
 39 
 
ЧДТУ 231921.007 ПЗ 
7 мокування залежностей: У модульному тестуванні важливо забезпечити 
ізоляцію модулів і функцій від залежностей, таких як база даних або 
мережеві запити. Для цього можна використовувати мокування (mocking 
[37]) залежностей, щоб створити псевдо об'єкти або підроблені 
замінники, які можна контролювати під час тестування; 
8 покриття коду тестами: Однією з мет цілей модульного тестування є 
досягнення високого покриття коду тестами. Це означає, що якомога 
більше функцій, методів та гілок коду повинні бути покриті тестами. Це 
допоможе виявити потенційні проблеми та забезпечує більшу впевненість 
у роботі вашого додатку. 
Написання модульних тестів дозволяє забезпечити стабільність та надійність 
вашого додатку, спрощує виявлення помилок і покращує розуміння вашого коду. 
Необхідно приділяти достатню увагу модульному тестуванню для підтримки 
високої якості вашого Flutter-додатку. 
3.2.2 Інтеграційне тестування 
Інтеграційне тестування в Flutter - це процес тестування взаємодії різних 
компонентів вашого додатку, таких як віджети, модулі, сервіси та зовнішні 
залежності. Цей вид тестування дозволяє перевірити, чи працюють компоненти 
разом належним чином та чи зберігається правильна функціональність. 
Ось кілька ключових аспектів інтеграційного тестування в Flutter: 
1 пакет flutter_test: Для написання інтеграційних тестів використовується 
пакет flutter_test, який забезпечує необхідні класи та функції для писання і 
запуску тестів; 
2 віртуальний апарат WidgetTester: Інтеграційні тести використовують 
віртуальний апарат WidgetTester, який дозволяє вам запускати тести для 
віджетів та взаємодіяти з ними. Ви можете симулювати події, такі як 
натискання кнопок або прокрутка екрану, та перевіряти реакцію додатку 
на ці події; 
3 запуск додатку у тестовому середовищі: Під час інтеграційного 
тестування  ваш  додаток  запускається  у  спеціальному  тестовому 
 40 
 
ЧДТУ 231921.007 ПЗ 
середовищі, яке дозволяє контролювати його стан і взаємодіяти з ним. Це 
дозволяє перевірити, чи працюють компоненти разом належним чином; 
4 асинхронні тести: Інтеграційні тести можуть бути асинхронними, 
оскільки ваш додаток може включати асинхронні операції, такі як 
мережеві запити або анімація. Ви можете використовувати ключове слово 
async та метод pump() від WidgetTester, щоб керувати асинхронними 
операціями в тестах; 
5 ізоляція тестових середовищ: Інтеграційні тести найкраще виконувати в 
ізольованому середовищі, щоб забезпечити незалежність від реальних 
залежностей та зовнішніх факторів. Це може включати використання 
підроблених (mock) сервісів або баз даних, щоб замінити реальні 
залежності під час тестування; 
6 налаштування тестових сценаріїв: При написанні інтеграційних тестів 
важливо визначити тести, які відображають реальні сценарії взаємодії 
користувача з додатком. Це може включати тести на перехід між 
екранами, взаємодію зі списками або формами, тестування аутентифікації 
тощо; 
7 перевірка очікуваних результатів: Під час інтеграційного тестування 
важливо перевіряти очікувані результати взаємодії компонентів. Ви 
можете використовувати методи expect() для порівняння отриманих 
результатів з очікуваними значеннями або станом; 
8 запуск тестів: Інтеграційні тести можна запускати з командного рядка за 
допомогою команди flutter test. Це запустить усі інтеграційні тести 
в вашому проекті та поверне результати в консолі. Також можна 
виконувати тести з інтегрованого середовища розробки, як IDE, 
натискаючи відповідну кнопку або комбінацію гарячих клавіш. 
Інтеграційне тестування в Flutter допомагає забезпечити правильну 
взаємодію компонентів вашого додатку, виявляти проблеми і підвищувати 
загальну якість програмного забезпечення. 
 41 
 
ЧДТУ 231921.007 ПЗ 
3.2.3 Системне тестування 
Системне тестування на Flutter - це процес тестування поведінки вашого 
додатку в реальному середовищі, симулюючи взаємодію користувача з 
додатком. Це дозволяє перевірити, чи працює ваш додаток відповідно до 
очікувань, а також виявити можливі проблеми і дефекти. 
Ось кілька ключових аспектів системного тестування в Flutter: 
1 використання пакету flutter_driver [38]: Для написання системних тестів у 
Flutter використовується пакет flutter_driver, який надає необхідні класи та 
функції для взаємодії з вашим додатком на рівні UI; 
2 запуск тестів на реальних пристроях або емуляторах: Системні тести 
можна виконувати на реальних фізичних пристроях або емуляторах, щоб 
перевірити поведінку додатка в реальних умовах; 
3 взаємодія з елементами користувацького інтерфейсу: Під час системного 
тестування ви можете симулювати дії користувача, такі як натискання 
кнопок, введення тексту, прокрутка екрану та інші події. Ви можете 
використовувати методи driver.tap(), driver.enterText(), driver.scroll(), щоб 
здійснювати ці дії; 
4 перевірка очікуваних результатів: Важливо перевірити, чи отримуєте 
очікувані результати від вашого додатку. Ви можете використовувати 
метод driver.waitFor() для очікування певного стану або елемента на 
екрані та метод expect() для порівняння фактичних результатів з 
очікуваними значеннями; 
5 запуск тестів: Системні тести можна запускати з командного рядка за 
допомогою команди flutter drive. Ви також можете виконувати тести з 
інтегрованого середовища розробки, такого як Android Studio [39] або 
Visual Studio Code [40]; 
6 конфігурація тестового середовища: Перед запуском системних тестів 
важливо налаштувати тестове середовище. Це може включати 
встановлення параметрів, налаштування даних тестової бази даних або 
завантаження певних конфігураційних файлів. Налаштування тестового 
 42 
 
ЧДТУ 231921.007 ПЗ 
середовища допоможе забезпечити стабільні та передбачувані умови для 
виконання системних тестів; 
7 обробка винятків та помилок: Під час системного тестування можуть 
виникати непередбачувані ситуації, помилки або винятки. Важливо 
обробляти ці випадки відповідним чином, записувати журнали помилок 
та надавати корисну інформацію для подальшого аналізу; 
8 написання стабілізаційних тестів: Крім основних системних тестів, 
рекомендується написання стабілізаційних тестів для перевірки 
стабільності додатку під час тривалого періоду використання або при 
великому навантаженні. Ці тести можуть допомогти виявити можливі 
проблеми з витоком пам'яті, великим споживанням ресурсів або іншими 
проблемами продуктивності; 
9 автоматизація тестування: Для ефективного виконання системних тестів 
рекомендується автоматизувати їх запуск та виконання. Це можна зробити 
за допомогою різних інструментів або фреймворків автоматизованого 
тестування, таких як Jenkins, CI/CD [41] пайплайни або інші інструменти 
тестування; 
10 системне тестування в Flutter допомагає забезпечити правильну роботу 
вашого додатку в реальних умовах та забезпечити високу якість продукту. 
3.2.4 Приймальне тестування 
Приймальне тестування (acceptance testing) в Flutter - це процес перевірки, 
чи відповідає ваш додаток вимогам і очікуванням користувачів перед його 
релізом або впровадженням виробництва. Це остаточна фаза тестування перед 
тим, як додаток буде випущений для широкого загалу користувачів. 
Ось декілька ключових аспектів приймального тестування в Flutter: 
1 визначення тестових сценаріїв: Приймальне тестування передбачає 
визначення тестових сценаріїв, які відображають реальні ситуації 
використання додатку користувачами. Це може включати тестування 
основних функціональностей, навігації між екранами, роботи з формами, 
взаємодії з базою даних та інші сценарії використання додатку; 
 43 
 
ЧДТУ 231921.007 ПЗ 
2 використання реальних пристроїв або емуляторів: Приймальні тести слід 
виконувати на реальних пристроях або емуляторах, щоб переконатися, що 
додаток працює на різних пристроях і платформах згідно очікувань. 
3 взаємодія з реальними користувачами: Приймальне тестування може 
включати взаємодію з реальними користувачами, які випробовують 
додаток і надають зворотний зв'язок. Це може включати збір думок, 
оцінки, виявлення проблем або пропозицій щодо покращення додатку; 
4 тестування різних сценаріїв використання: Приймальне тестування має 
охоплювати різні сценарії використання вашого додатку. Це включає 
нормальні сценарії, альтернативні шляхи, вводу некоректних даних, 
роботу з різними ролями або правами доступу, тестування реакції додатку 
на помилки та винятки, а також інші сценарії, які можуть зустрітися в 
реальному використанні; 
5 валідація інтерфейсу користувача: Приймальне тестування також включає 
перевірку інтерфейсу користувача на відповідність вимогам та дизайну. 
Вам слід перевірити, що елементи UI відображаються правильно, 
взаємодія з ними є інтуїтивно зрозумілою, текст та графіка 
відображаються належним чином, а також переконатися, що кольори, 
шрифти та макети відповідають дизайну; 
6 тестування продуктивності та навантаження: Приймальне тестування 
може включати тестування продуктивності та навантаження вашого 
додатку. Це означає перевірку його швидкодії, часу відгуку, витривалості 
та працездатності при великому обсязі даних або навантаженні. Важливо 
переконатися, що додаток може ефективно працювати навіть при 
високому навантаженні або вимогах до продуктивності; 
 44 
 
ЧДТУ 231921.007 ПЗ 
ВИСНОВОК 
У рамках даної дипломної роботи було спроектовано та розроблено 
мобільний додаток "Викладач ЧДТУ", який призначений для полегшення 
роботи викладачів та покращення комунікації зі студентами. В результаті 
проектування та розробки додатку було показано, що використання мобільних 
технологій у сфері освіти може принести значну користь і сприяти покращенню 
навчального процесу. 
Основними функціями додатку є можливість створення розкладу занять, 
оголошень, завдань для студентів, а також сповіщення про важливі події та 
зміни в розкладі. Крім того, додаток надає можливість викладачам оцінювати 
роботи студентів, вести електронний журнал успішності, а також здійснювати 
індивідуальний зв'язок зі студентами через систему приватних повідомлень. 
Під час розробки додатку була проведена аналіз сучасних підходів до 
мобільного навчання та комунікації, вивчено вимоги викладачів та студентів 
щодо функціональності додатку. Застосування технологій розробки мобільних 
додатків, таких як Flutter, дозволило створити кросплатформений додаток, який 
працює на різних мобільних пристроях з оптимальною продуктивністю. 
Оцінка ефективності додатку проводилась шляхом збору фідбеку від 
викладачів та студентів, які використовували додаток під час пілотного запуску. 
Отримані результати свідчать про позитивний вплив додатку на організацію 
навчального процесу, зручність комунікації та покращення загального 
сприйняття інформації студентами. Багато викладачів відзначили зменшення 
зусиль, необхідних для управління розкладом занять, організації завдань та 
оцінювання студентів. Студенти, у свою чергу, відзначили зручність доступу до 
розкладу, можливість отримувати сповіщення про зміни та оголошення в 
режимі реального часу, а також зручність спілкування з викладачами через 
систему приватних повідомлень. 
Отже, мобільний додаток "Викладач ЧДТУ" виявився ефективним 
інструментом для полегшення роботи викладачів та покращення комунікації зі 
студентами.  Впровадження  такого  додатку  може  сприяти  підвищенню 
 45 
 
ЧДТУ 231921.007 ПЗ 
продуктивності навчального процесу, покращенню організації та зменшенню 
адміністративного навантаження на викладачів. Крім того, зручний доступ до 
інформації та можливість взаємодії в режимі онлайн сприяють активному 
залученню студентів до навчання та підвищенню їх мотивації. 
На основі отриманих результатів рекомендується подальше 
вдосконалення додатку, враховуючи фідбек від користувачів, додавання нових 
функцій та можливостей, що дозволять ще більше оптимізувати роботу 
викладачів та поліпшити комунікацію в університетському середовищі. Досвід 
розробки та впровадження даного додатку може бути корисним для інших 
освітніх установ, які прагнуть покращити ефективність навчального процесу та 
забезпечити зручність комунікації між викладачами та студентами. 
Крім того, важливо зазначити, що мобільний додаток "Викладач 
університету" може відкрити нові перспективи для розвитку електронного 
навчання та дистанційного освітнього процесу. Зокрема, додаток може стати 
платформою для проведення вебінарів, віртуальних лекцій та дискусій, що 
дозволить розширити можливості навчання за межами аудиторії та привернути 
викладачів та студентів з інших регіонів. 
Крім того, подальший розвиток додатку може включати інтеграцію з 
іншими освітніми платформами та системами, такими як системи управління 
навчальним процесом та електронні бібліотеки, для забезпечення широкого 
спектру функціональних можливостей викладачів та студентів. 
У майбутньому також можна розглядати можливість розширення додатку 
на інші мобільні платформи, такі як iOS, або розробку додаткових модулів, 
спрямованих на підтримку специфічних потреб освітнього процесу, наприклад, 
організацію професійної практики або моніторингу академічного прогресу 
студентів. 
У підсумку, мобільний додаток "Викладач ЧДТУ" представляє собою 
потужний інструмент для оптимізації роботи викладачів та поліпшення 
взаємодії зі студентами. Подальший розвиток і вдосконалення додатку мають 
 46 
 
ЧДТУ 231921.007 ПЗ 
великий потенціал для сприяння ефективності навчального процесу та 
створення сучасного та інноваційного освітнього середовища. 
 47 
 
ЧДТУ 231921.007 ПЗ 
Список використаних джерел 
 
1 Flutter - [Електронний ресурс] - Режим доступу: https://flutter.dev/ 
2 Ionic - [Електронний ресурс] - Режим доступу: https://ionicframework.com/ 
3 React Native - [Електронний ресурс] - Режим доступу: 
https://reactnative.dev/ 
4 Nest js - [Електронний ресурс] - Режим доступу: https://docs.nestjs.com/ 
5 JS - [Електронний ресурс] - Режим доступу: 
https://developer.mozilla.org/ru/docs/Web/JavaScript 
6 PostgreSQL - [Електронний ресурс] - Режим доступу: 
https://www.postgresql.org/ 
7 IOS - [Електронний ресурс] - Режим доступу: 
https://uk.wikipedia.org/wiki/IOS 
8 Android - [Електронний ресурс] - Режим доступу: 
https://www.android.com/what-is-android/ 
9 Xamarin - [Електронний ресурс] - Режим доступу: 
https://learn.microsoft.com/ru-ru/xamarin/get-started/what-is-xamarin 
10 Кросплатформні проекти - [Електронний ресурс] - Режим доступу: 
https://www.netguru.com/blog/flutter-for-cross-platform-app-development 
11 flutter_cryptography - [Електронний ресурс] - Режим доступу: 
https://pub.dev/packages/cryptography 
12 flutter_secure_storage - [Електронний ресурс] - Режим доступу: 
https://pub.dev/packages/flutter_secure_storage 
13  HTTPS - [Електронний ресурс] - Режим доступу: 
https://www.ukraine.com.ua/uk/blog/seo-optimization/chto-takoe-https-i-zache 
m-on-nuzhen-kazhdomu-sajtu.html 
14 http_flutter - [Електронний ресурс] - Режим доступу: 
https://pub.dev/packages/http 
15 dart:io - [Електронний ресурс] - Режим доступу: 
https://api.flutter.dev/flutter/dart-io/dart-io-library.html 
 48 
 
ЧДТУ 231921.007 ПЗ 
16 JWT - [Електронний ресурс] - Режим доступу: https://jwt.io/introduction 
17 Rational Unified Process - [Електронний ресурс] - Режим доступу: 
https://en.wikipedia.org/wiki/Rational_unified_process 
18 eXtreme Programming - [Електронний ресурс] - Режим доступу: 
https://www.nimblework.com/agile/extreme-programming-xp/ 
19 UML  -  [Електронний  ресурс]  -  Режим  доступу: 
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what- 
is-uml/ 
20 StatelessWidget - [Електронний ресурс] - Режим доступу: 
https://api.flutter.dev/flutter/widgets/StatelessWidget-class.html 
21 StatefulWidget - [Електронний ресурс] - Режим доступу: 
https://api.flutter.dev/flutter/widgets/StatefulWidget-class.html 
22 Bloc - [Електронний ресурс] - Режим доступу: 
https://bloclibrary.dev/#/ 
23  APK - [Електронний ресурс] - Режим доступу: 
https://www.makeuseof.com/tag/what-is-apk-file/ 
24 Aутентифікація - [Електронний ресурс] - Режим доступу: 
https://www.techtarget.com/searchsecurity/definition/authentication 
25 Skia - [Електронний ресурс] - Режим доступу: 
https://levelup.gitconnected.com/flutters-skia-engine-takes-cross-platform-app- 
development-to-a-new-level-85cc5f92ca9b 
26 Hot reload - [Електронний ресурс] - Режим доступу: 
https://docs.flutter.dev/tools/hot-reload 
27 Компілятор - [Електронний ресурс] - Режим доступу: 
https://jaytillu.medium.com/3-flutter-compilation-process-e602d939e147 
28 API - [Електронний ресурс] - Режим доступу: 
https://aws.amazon.com/ru/what-is/api/ 
 49 
 
ЧДТУ 231921.007 ПЗ 
29 Lazy loading - [Електронний ресурс] - Режим доступу: 
https://codewithflutter.com/flutter-listview-lazy-loading/ 
30 Кешування - [Електронний ресурс] - Режим доступу: 
https://www.techtarget.com/searchstorage/definition/cache 
31 Events - [Електронний ресурс] - Режим доступу: 
https://blog.logrocket.com/state-management-flutter-bloc-pattern/ 
32 State - [Електронний ресурс] - Режим доступу: 
https://blog.logrocket.com/state-management-flutter-bloc-pattern/ 
33 Repository - [Електронний ресурс] - Режим доступу: 
https://bloclibrary.dev/#/architecture?id=repository 
34 Providers - [Електронний ресурс] - Режим доступу: 
https://bloclibrary.dev/#/architecture?id=data-provider 
35 flutter_test - [Електронний ресурс] - Режим доступу: 
https://api.flutter.dev/flutter/flutter_test/flutter_test-library.html 
36 IDE - [Електронний ресурс] - Режим доступу: 
https://aws.amazon.com/ru/what-is/ide/ 
37 Моки - [Електронний ресурс] - Режим доступу: 
https://en.wikipedia.org/wiki/Mock_object 
38 flutter_driver - [Електронний ресурс] - Режим доступу: 
https://api.flutter.dev/flutter/flutter_driver/flutter_driver-library.htm 
39 Android Studio- [Електронний ресурс] - Режим доступу: 
https://developer.android.com/studio 
40 VS Code - [Електронний ресурс] - Режим доступу: 
https://code.visualstudio.com/ 
41 CI/CD - [Електронний ресурс] - Режим доступу: 
https://www.redhat.com/en/topics/devops/what-is-ci-cd 
 50 
 
ДОДАТОК А 
 
 
ЗАТВЕРДЖЕНО: 
Зав. кафедри ПЗАС 
проф. Голуб С.В. 
 
 
 
 
 
 
 
МОБІЛЬНИЙ ЗАСТОСУНОК «Викладач ЧДТУ» 
 
 
Специфікація 
ЧДТУ 231921.007 ПЗ 
Листів 2 
 
 
 
 
 
Розробник    Плакся Д.Д 
   
Керівник    Заспа Г.О 
   
Н.Контроль    Півень О.Б. 
 
 
 
 
 
 
 
 
Черкаси 2023 
 51 
 
Позначення Найменування Примітка 
 Документація  
482.ЧДТУ 231921.007 34-01 Інструкція  
користувача 
482.ЧДТУ 231921.007 12-01 Лістинг програми  
482.ЧДТУ 231921.007 90-01 Презентація  
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 52 
 
ДОДАТОК Б 
 
 
 
 
 
 
 
 
 
МОБІЛЬНИЙ ЗАСТОСУНОК «Викладач ЧДТУ» 
 
 
 
 
 
 
Інструкція користувача 
482.ЧДТУ 231921.007 34-01 
Листів 2 
 
 
 
 
 
Розробник:   Плакся Д.Д 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2023 
 
 
482.ЧДТУ 231921-007 34-01 
 
1 Підготовка середовища:Встановіть Flutter та Dart на свою систему, якщо їх 
ще немає. Завантажити їх можна з офіційних сайтів Flutter 
(https://docs.flutter.dev/get-started/install) та Dart (https://dart.dev/get-dart). 
2 Завантаження та встановлення застосунку: 
◻ Завантажте програмне забезпечення серверного застосунку 
"Викладач ЧДТУ" з репозиторію проекту (GitHub). 
◻ Розпакуйте завантажений архів з кодом проекту. 
◻ Відкрийте командний рядок або термінал та перейдіть до папки 
проекту. 
3 Запуск додатку: 
◻ Відкрийте середовище розробки та виконайте команду 
flutter run lib/main.dart. 
◻ Після успішного запуску ви побачите запущений емулятор з додатком. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
54 
 
 
ДОДАТОК В 
 
 
 
 
 
 
 
 
 
МОБІЛЬНИЙ ЗАСТОСУНОК «Викладач ЧДТУ» 
 
 
 
 
 
 
Лістинг програми 
482.ЧДТУ 231921.007 12-01 
Листів 11 
 
 
 
 
 
Розробник:   Плакся Д.Д 
 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2023 
 
 
482.ЧДТУ 231921-007 12-01 
group_page.widget.dart 
import 
'package:deanoffice_teacher_mobile/block/group/statement_bloc.dart'; 
import 
'package:deanoffice_teacher_mobile/block/group/statement_event.dart'; 
import 
'package:deanoffice_teacher_mobile/block/group/statement_state.dart'; 
import 
'package:deanoffice_teacher_mobile/widgets/group/general_information_bl 
ock.dart'; 
import 'package:flutter/material.dart'; 
import 'package:flutter_bloc/flutter_bloc.dart'; 
 
import '../constant/styles.dart'; 
import '../repository/group_repository.dart'; 
 
class Group extends StatefulWidget { 
const Group({Key? key}) : super(key: key); 
 
@override 
State<Group> createState() => _GroupState(); 
} 
 
class _GroupState extends State<Group> { 
final GroupBloc groupBloc = GroupBloc(); 
 
List<DropdownMenuItem<String>> get dropdownItems { 
List<DropdownMenuItem<String>> menuItems = [ 
const DropdownMenuItem(child: Text("Вибіркові дисципліни"), value: 
"selectedDisciplines"), 
const DropdownMenuItem(child: Text("Дисципліни студентів"), value: 
"disciplines"), 
const DropdownMenuItem(child: Text("Борги студентів"), value: 
"debts"), 
const  DropdownMenuItem(child:  Text("Список  груп"),  value: 
"groups"), 
const DropdownMenuItem(child: Text("Список студентів"), value: 
"students"), 
]; 
return menuItems; 
} 
 
@override 
Widget build(BuildContext context) { 
return Padding( 
padding: const EdgeInsets.all(18.0), 
child: Column( 
mainAxisAlignment: MainAxisAlignment.start, 
children: [ 
Row( 
 56 
 
482.ЧДТУ 231921-007 12-01 
mainAxisAlignment: MainAxisAlignment.spaceBetween, 
children: [Text("Groups"), Icon(Icons.add)], 
), 
const SizedBox( 
height: 30, 
), 
DropdownButtonFormField( 
decoration: const InputDecoration( 
enabledBorder: OutlineInputBorder( 
borderSide: BorderSide(color: Colors.grey, width: 1), 
), 
focusedBorder: OutlineInputBorder( 
borderSide: BorderSide(color: Colors.grey, width: 1), 
), 
), 
value: 'groups', 
isDense: true, 
items: dropdownItems, 
onChanged: (String? value) { 
groupBloc.add(GroupDropdownChangeEvent(value!)); 
}, 
), 
const SizedBox( 
height: 15, 
), 
BlocProvider( 
create: (context) => groupBloc, 
child: BlocConsumer<GroupBloc, GroupState>( 
buildWhen: (_, state) => 
state is GroupNameState || 
state is GroupContentState || 
state is GroupStudentState, 
listener: (context, state) => {}, 
bloc: groupBloc, 
builder: (_, state) { 
if (state is GroupNameState) { 
return Expanded( 
child: SingleChildScrollView( 
child: _buildGroupName(state.groupName))); 
} 
 
if (state is GroupStudentState) { 
return Expanded(child: 
_buildGroupStudent(state.groupStudent)); 
} 
 
return Expanded( 
child: _getScreenContent(state.screenContent)); 
}, 
), 
 57 
 
482.ЧДТУ 231921-007 12-01 
) 
], 
)); 
} 
 
Widget _buildGroupName(List<GroupName> groupName) { 
return ListView.builder( 
padding: const EdgeInsets.all(8), 
scrollDirection: Axis.vertical, 
shrinkWrap: true, 
itemCount: groupName.length, 
itemBuilder: (BuildContext context, int index) { 
return GeneralInformationWidget(information: 
groupName[index].name); 
}); 
} 
 
Widget _buildGroupStudent(List<GroupStudent> groupStudent) { 
return SingleChildScrollView( 
child: Column( 
children: [ 
for (int i = 0; i < groupStudent.length; i++) ...[ 
Column( 
children: [ 
Row( 
children: [ 
const Expanded(child: Divider()), 
Padding( 
padding: const EdgeInsets.all(8.0), 
child: Text(groupStudent[i].groupName)), 
const Expanded(child: Divider()), 
], 
), 
 for (int x = 0; x < groupStudent[i].students.length; x++) 
...[  
GeneralInformationWidget( 
information: "${groupStudent[i].students[x].surname} 
${groupStudent[i].students[x].name} 
${groupStudent[i].students[x].patronimic}", 
), 
], 
], 
) 
] 
], 
)); 
} 
 
Widget _getScreenContent(GroupDropdownContent screenContent) { 
return SingleChildScrollView( 
 58 
 
482.ЧДТУ 231921-007 12-01 
child: Column( 
children: [ 
Container( 
child: Column( 
children: [ 
Row( 
children: const [ 
Expanded(child: Divider()), 
Padding( 
padding: EdgeInsets.all(8.0), 
child: Text("ПЗ-1904")), 
Expanded(child: Divider()), 
], 
), 
GeneralInformationWidget( 
information: 'Test User 1', 
), 
GeneralInformationWidget( 
information: 'Test User 1', 
), 
GeneralInformationWidget( 
information: 'Test User 1', 
), 
], 
), 
), 
Container( 
child: Column( 
children: [ 
Row( 
children: const [ 
Expanded(child: Divider()), 
Padding( 
padding: EdgeInsets.all(8.0), 
child: Text("ПЗ-1904")), 
Expanded(child: Divider()), 
], 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
 59 
 
482.ЧДТУ 231921-007 12-01 
child: Text('Безпека програм та даних 2')), 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
], 
), 
), 
Container( 
child: Column( 
children: [ 
Row( 
children: const [ 
Expanded(child: Divider()), 
Padding( 
padding: EdgeInsets.all(8.0), 
child: Text("ПЗ-1904")), 
Expanded(child: Divider()), 
], 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
], 
), 
), 
Container( 
child: Column( 
 60 
 
482.ЧДТУ 231921-007 12-01 
children: [ 
Row( 
children: const [ 
Expanded(child: Divider()), 
Padding( 
padding: EdgeInsets.all(8.0), 
child: Text("ПЗ-1904")), 
Expanded(child: Divider()), 
], 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
Container( 
height: 50, 
margin: const EdgeInsets.only(bottom: 20.0), 
decoration: Styles.roundedBorderWithShadow, 
child: const Center( 
child: Text('Безпека програм та даних 2')), 
), 
], 
), 
), 
], 
), 
); 
} 
} 
 
 
group_bloc.dart 
import 
'package:deanoffice_teacher_mobile/block/group/statement_event.dart'; 
import 
'package:deanoffice_teacher_mobile/block/group/statement_state.dart'; 
import 
'package:deanoffice_teacher_mobile/repository/group_repository.dart'; 
import 'package:flutter_bloc/flutter_bloc.dart'; 
 61 
 
482.ЧДТУ 231921-007 12-01 
class GroupBloc extends Bloc<GroupEvent, GroupState> { 
final groupRepository = GroupRepository(); 
 
GroupBloc(): super(GroupContentState(GroupDropdownContent.groups)) { 
on<GroupDropdownChangeEvent>((event, emit) async { 
final selectedContent = groupPages[event.pageIndex]; 
 
if(selectedContent == GroupDropdownContent.students) { 
List<GroupStudent>? groupStudent = await 
groupRepository.getStudents(); 
 
if(groupStudent != null) { 
emit(GroupStudentState(groupStudent, selectedContent!)); 
return; 
} 
} 
 
if (selectedContent == GroupDropdownContent.groups) { 
List<GroupName>? groupName = await groupRepository.getGroups(); 
if(groupName != null) { 
emit(GroupNameState(groupName, selectedContent!)); 
return; 
} 
} 
 
if (selectedContent != null) { 
emit(GroupContentState(selectedContent)); 
} 
}); 
} 
} 
 
enum GroupDropdownContent { 
debts, 
students, 
disciplines, 
selectedDisciplines, 
groups, 
} 
 
Map<String, GroupDropdownContent> groupPages = { 
'debts': GroupDropdownContent.debts, 
'students': GroupDropdownContent.students, 
'selectedDisciplines': GroupDropdownContent.selectedDisciplines, 
'disciplines': GroupDropdownContent.disciplines, 
'groups': GroupDropdownContent.groups, 
}; 
 
 
group_repository.dart 
 62 
 
482.ЧДТУ 231921-007 12-01 
import 'dart:convert'; 
import 'dart:io'; 
import 'package:deanoffice_teacher_mobile/service/token_service.dart'; 
import 'package:http/http.dart'; 
import '../config/config.dart'; 
 
class GroupRepository { 
final tokenService = TokenService(); 
 
Future<List<GroupName>?> getGroups() async { 
String? token = await tokenService.get('jwt'); 
UserInfo userInfo; 
 
if(token != null) { 
userInfo = await tokenService.decodeToken(token); 
 
final queryParameters = { 
'userId': userInfo.decodedToken['userId'].toString(), 
}; 
final uri = 
Uri.http(Config.backendUrl2, '/groups/by-user/', queryParameters); 
final response = await get(uri, headers: { 
HttpHeaders.authorizationHeader: 'Bearer $token', 
HttpHeaders.contentTypeHeader: 'application/json', 
}); 
 
List<GroupName> groupName = sampleFromJson(response.body); 
return groupName; 
} 
} 
 
Future<List<GroupStudent>?> getStudents() async { 
String? token = await tokenService.get('jwt'); 
UserInfo userInfo; 
 
if(token != null) { 
userInfo = await tokenService.decodeToken(token); 
 
final queryParameters = { 
'userId': userInfo.decodedToken['userId'].toString(), 
}; 
final uri = 
Uri.http(Config.backendUrl2, '/groups/students/by-user/', 
queryParameters); 
final response = await get(uri, headers: { 
HttpHeaders.authorizationHeader: 'Bearer $token', 
HttpHeaders.contentTypeHeader: 'application/json', 
}); 
 
List<GroupStudent> groupName = studentFromJson(response.body); 
 63 
 
482.ЧДТУ 231921-007 12-01 
return groupName; 
} 
} 
} 
 
 
List<GroupName> sampleFromJson(String str) { 
final jsonData = json.decode(str); 
return List<GroupName>.from(jsonData.map((x) => 
GroupName.fromJson(x))); 
} 
 
List<GroupStudent> studentFromJson(String str) { 
final jsonData = json.decode(str); 
return List<GroupStudent>.from(jsonData.map((x) { 
return GroupStudent.fromJson(x); 
})); 
} 
 
class GroupName { 
final String name; 
 
const GroupName({ 
required this.name, 
}); 
 
factory GroupName.fromJson(Map<String, dynamic> json) { 
return GroupName( 
name: json['name'], 
); 
} 
} 
 
class GroupStudent { 
final String groupName; 
final List<StudentName> students; 
 
const GroupStudent({ 
required this.groupName, 
required this.students, 
}); 
 
factory GroupStudent.fromJson(Map<String, dynamic> jsonObject) { 
return GroupStudent( 
groupName: jsonObject['groupName'], 
students: List.from(jsonObject['students'].map((x) { 
return StudentName.fromJson(x); 
}), 
)); 
} 
 64 
 
482.ЧДТУ 231921-007 12-01 
} 
 
class StudentName { 
final int id; 
final String name; 
final String surname; 
final String patronimic; 
 
const StudentName({ 
required this.id, 
required this.name, 
required this.surname, 
required this.patronimic, 
}); 
 
factory StudentName.fromJson(Map<String, dynamic> json) { 
return StudentName( 
id: json['id'], 
name: json['name'], 
surname: json['surname'], 
patronimic: json['patronimic'], 
); 
} 
} 
 65 
 
ДОДАТОК Г 
 
 
 
 
 
 
 
 
 
МОБІЛЬНИЙ ЗАСТОСУНОК «Викладач ЧДТУ» 
 
 
 
 
 
 
Презентація 
482.ЧДТУ 231921.007 90-01 
Листів 6 
 
 
 
 
 
Розробник:   Плакся Д.Д 
 
 
 
 
 
 
 
 
 
 
 
 
Черкаси 2023 
 
 
482.ЧДТУ 231921-007 90-01 
 
Рисунок Г.1 Слайд 1 
 
Рисунок Г.2 Слайд 2 
 
 
 
Рисунок Г.3 Слайд 3 
 67 
 
482.ЧДТУ 231921-007 90-01 
 
 
Рисунок Г.4 Слайд 4 
 
Рисунок Г.5 - Слайд 5 
 68 
 
482.ЧДТУ 231921-007 90-01 
 
 
Рисунок Г.6 Слайд 6 
 
Рисунок Г.7 Слайд 7 
 69 
 
482.ЧДТУ 231921-007 90-01 
 
 
Рисунок Г.8 Слайд 8 
 
Рисунок Г.9 Слайд 9 
 70 
 
482.ЧДТУ 231921-007 90-01 
 
 
Рисунок Г.10 Слайд 10 
 71
ChSTU repository

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