Model of the "department" ecosystem
An ecosystem model is proposed, which describes the main objects and their functions in such medium of a higher educational institution as a department. The main object of research in such models are conditions of the successful development and functioning of the department. In particular, the metho...
Збережено в:
| Дата: | 2024 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2024
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/664 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-664 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/2d/d7138c450361bca507524a5d9842ba2d.pdf |
| spelling |
pp_isofts_kiev_ua-article-6642025-02-15T15:32:56Z Model of the "department" ecosystem Модель екосистеми "Кафедра" Kryvyi, S.L. Grinenko, O.O. model; ecosystem; properties UDC 51.681.3 модель; екосистема; властивості УДК 51.681.3 An ecosystem model is proposed, which describes the main objects and their functions in such medium of a higher educational institution as a department. The main object of research in such models are conditions of the successful development and functioning of the department. In particular, the methods of planning an equal educational load for teachers, together with the employees of the university department and the management of the faculty are considered. The main actors in the ecosystem are teachers (called servers), who teach the courses. The proposed model makes it possible to simplify the drawing up of the schedule, to quickly respond to force majeure circumstances, necessary exchange of the teacher, etc. The properties of ecosystem models are verified by automata-network methods. Such ecosystem can be generalized and expanded by adding models of the faculty, university, and Ministry in order to control the work of the faculty, university, and ministry, the effectiveness of their functioning.Prombles in programming 2024; 2-3: 418-425 Пропонується модель екосистеми, в якій описані основні об’єкти та їхні функції у такому середовищі вищого навчального закладу як кафедра. Основним об’єктом дослідження в такій моделі є умови успішного розвитку та функціонування кафедри. Зокрема розглядаються способи планування рівномірного навчального навантаження на викладачів, взаємодія працівників кафедри між собою і керівництвом факультету. Основними діючими особами в екосистемі є викладачі (названі серверами), які викладають відповідні курси. Пропонована модель дозволяє спростити складання розкладу, оперативно реагувати на форс-мажорні обставини, необхідні заміни викладача тощо. Властивості моделі екосистеми досліджуються автоматно-мережевими методами. Така екосистема може узагальнюватися та розширюватися шляхом надбудови моделі факультету, університету, міністерства з метою контролю роботи факультету, університету, міністерства та ефективності їхнього функціонування.Prombles in programming 2024; 2-3: 418-425 Інститут програмних систем НАН України 2024-12-17 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/664 10.15407/pp2024.02-03.418 PROBLEMS IN PROGRAMMING; No 2-3 (2024); 418-425 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2024); 418-425 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2024); 418-425 1727-4907 10.15407/pp2024.02-03 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/664/716 Copyright (c) 2024 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-02-15T15:32:56Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
model ecosystem properties UDC 51.681.3 |
| spellingShingle |
model ecosystem properties UDC 51.681.3 Kryvyi, S.L. Grinenko, O.O. Model of the "department" ecosystem |
| topic_facet |
model ecosystem properties UDC 51.681.3 модель екосистема властивості УДК 51.681.3 |
| format |
Article |
| author |
Kryvyi, S.L. Grinenko, O.O. |
| author_facet |
Kryvyi, S.L. Grinenko, O.O. |
| author_sort |
Kryvyi, S.L. |
| title |
Model of the "department" ecosystem |
| title_short |
Model of the "department" ecosystem |
| title_full |
Model of the "department" ecosystem |
| title_fullStr |
Model of the "department" ecosystem |
| title_full_unstemmed |
Model of the "department" ecosystem |
| title_sort |
model of the "department" ecosystem |
| title_alt |
Модель екосистеми "Кафедра" |
| description |
An ecosystem model is proposed, which describes the main objects and their functions in such medium of a higher educational institution as a department. The main object of research in such models are conditions of the successful development and functioning of the department. In particular, the methods of planning an equal educational load for teachers, together with the employees of the university department and the management of the faculty are considered. The main actors in the ecosystem are teachers (called servers), who teach the courses. The proposed model makes it possible to simplify the drawing up of the schedule, to quickly respond to force majeure circumstances, necessary exchange of the teacher, etc. The properties of ecosystem models are verified by automata-network methods. Such ecosystem can be generalized and expanded by adding models of the faculty, university, and Ministry in order to control the work of the faculty, university, and ministry, the effectiveness of their functioning.Prombles in programming 2024; 2-3: 418-425 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2024 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/664 |
| work_keys_str_mv |
AT kryvyisl modelofthedepartmentecosystem AT grinenkooo modelofthedepartmentecosystem AT kryvyisl modelʹekosistemikafedra AT grinenkooo modelʹekosistemikafedra |
| first_indexed |
2025-07-17T10:08:10Z |
| last_indexed |
2025-07-17T10:08:10Z |
| _version_ |
1838410696245641216 |
| fulltext |
418
Інформатизація освіти
УДК 51.681.3 http://doi.org/10.15407/pp2024.02-03.418
С.Л. Кривий, О.О. Гріненко
МОДЕЛЬ ЕКОСИСТЕМИ “КАФЕДРА”
Пропонується модель екосистеми, в якій описані основні об’єкти та їхні функції у такому середовищі
вищого навчального закладу як кафедра. Основним об’єктом дослідження в такій моделі є умови успіш-
ного розвитку та функціонування кафедри. Зокрема розглядаються способи планування рівномірного
навчального навантаження на викладачів, взаємодія працівників кафедри між собою і керівництвом фа-
культету. Основними діючими особами в екосистемі є викладачі (названі серверами), які викладають
відповідні курси. Пропонована модель дозволяє спростити складання розкладу, оперативно реагувати на
форс-мажорні обставини, необхідні заміни викладача тощо. Властивості моделі екосистеми досліджу-
ються автоматно-мережевими методами. Така екосистема може узагальнюватися та розширюватися
шляхом надбудови моделі факультету, університету, міністерства з метою контролю роботи факультету,
університету, міністерства та ефективності їхнього функціонування.
Ключові слова: модель, екосистема, властивості.
S.L. Kryvyi, O.O. Grinenko
MODEL OF THE “DEPARTMENT” ECOSYSTEM
An ecosystem model is proposed, which describes the main objects and their functions in such medium of a
higher educational institution as a department. The main object of research in such models are conditions of the
successful development and functioning of the department. In particular, the methods of planning an equal edu-
cational load for teachers, together with the employees of the university department and the management of the
faculty are considered. The main actors in the ecosystem are teachers (called servers), who teach the courses.
The proposed model makes it possible to simplify the drawing up of the schedule, to quickly respond to force
majeure circumstances, necessary exchange of the teacher, etc. The properties of ecosystem models are verified
by automata-network methods. Such ecosystem can be generalized and expanded by adding models of the fac-
ulty, university, and Ministry in order to control the work of the faculty, university, and ministry, the effective-
ness of their functioning.
Key words: model, ecosystem, properties.
Вступ
В [1] була запропонована модель еко-
системи програмного забезпечення (ПЗ), яка
в даній роботі адаптується до побудови мо-
делі екосистеми, що обмежується областю
’’Кафедра” як основної ланки функціону-
вання закладу вищої освіти (ЗВО). На жаль,
обмеження на обсяг статті не дозволяють
описати детально всі властивості моделі,
тому описуються лише основні етапи її фун-
кціонування протягом одного робочого дня.
Загальна модель екосистеми
Об’єктом дослідження в екосис-
темі, яка належить до навчання у ЗВО, є ме-
тоди, моделі і засоби, які дають можливість
досліджувати взаємодію об’єктів з оточую-
чим середовищем, та взаємодію об’єктів
екосистеми між собою. Водночас головним
аспектом такої взаємодії є стійкий розвиток
екосистеми в цілому.
Предметом дослідження є процеси,
які відбуваються на такому об’єкті ЗВО як
кафедра та її оточенні (методи, взаємодія,
викладачі, студенти, розробники, замов-
ники, контролюючі органи тощо). Далі бу-
демо користуватися таким загальним озна-
ченням екосистеми [1].
Означення 1. Екосистемою (EC)
називається четвірка ES = (EE, E, B, SEB)
- EE - зовнішнє середовище;
- E - автономне сімейство
об’єктів, які взаємодіють між. собою і з
зовнішним середовищем (ядро EC);
- B - база знань, де зберігається
еволюція розвитку сімейства E як популяції
(макрознання EC);
© С.Л. Кривий, О.О. Гріненко, 2024
ISSN 1727-4907. Проблеми програмування. 2024. №2-3
419
Інформатизація освіти
- SEB - сервер для забезпечення вза-
ємодії між E, B та зовнішнім середовищем.
Рис. 1. Модель екосистеми верхнього рівня
Зовнішнє середовище EE - це зовні-
шнє оточення, в якому функціонує екосис-
тема (кафедра). До цього об’єкта належить
усе, що має зовнішній вплив на це функці-
онування.
Сімейство об’єктів E в 𝐸𝐸𝐸𝐸 загалом
можна інтерпретувати по-різному, але в да-
ному розгляді ці об’єкти отримують цілком
конкретну інтерпретацію, про яку йтиме
мова далі.
База знань B в 𝐸𝐸𝐸𝐸 відіграє роль схо-
вища знань про етапи розвитку кафедри,
про розроблені курси, лабораторні роботи
та практичні завдання, виконані проєкти,
інформацію про існуюче та нове ПЗ, відо-
мості про допущені помилки у виборі кур-
сів і завдань, про допущені помилки керів-
ництва, позитивний досвід, ухвалені рі-
шення, про ПЗ, яке використовується кафе-
дрою, про досвід і стаж роботи викладачів,
які працюють в даний час і про тих, які за-
лишили кафедру, про структуру кафедри,
освітні програми, навчальні програми, про-
грами окремих курсів, про завдання, які ви-
конані, і які виконуються працівниками ка-
федри тощо.
Сервер SEB служить для того, щоб
забезпечувати оперативну взаємодію між
E, B та зовнішнім середовищем EE. Сис-
тема E може безпосередньо працювати із
БЗ у разі, коли немає потреби використову-
вати сервер SEB. А коли потрібно отримати
доступ до певної приватної чи конфіденцій-
ної інформації, то необхідно дістати дозвіл
на доступ до такої інформації. Цю функцію,
зокрема, виконує сервер SEB. Крім того, у
даній екосистемі основними діючими осо-
бами такого сервера є завідувач кафедри,
професори, гаранти освітніх програм, ад-
міністратор системи. До їхніх функцій на-
лежать комунікація з зовнішнім середови-
щем (аналіз ринку, наукових досягнень,
взаємодія з деканатом, ректоратом та з ко-
легами інших кафедр, факультетів та вузів).
Складові ЕС та їхня
характеристика
Сімейство E, як ядро ЕС, зображу-
ється такою четвіркою, яку будемо нази-
вати серверною частиною ЕС,
𝐸𝐸 = (𝑆𝑆, Ω, 𝑜𝑜, 𝑓𝑓) (1)
де
− 𝑆𝑆 = {𝑆𝑆1, . . . , 𝑆𝑆𝑛𝑛} - скінченна мно-
жина, елементи якої називаються серве-
рами, в нашому випадку - це викладачі ка-
федри;
− 𝑄𝑄 = {𝑤𝑤1, . . . , 𝑤𝑤𝑛𝑛} - скінченна
множина операцій, які можуть виконува-
тися різними серверами, в нашому випадку
- це курси, які можуть викладатися викла-
дачами кафедри;
− 𝑜𝑜: 𝐵𝐵 → Ω - множина операцій, які
може виконувати окремо взятий сервер, в
нашому випадку - це курси, які може чи-
тати і читає конкретний викладач кафедри;
− 𝑓𝑓: 𝑆𝑆 × Ω → 𝐷𝐷 × 𝑄𝑄+ - функція,
значеннями якої є рік, місяць, день (область
D) і час виконання окремої операції на ок-
ремо взятому сервері в нашому випадку -
це конкретний курс, який читає або читав
конкретний викладач в певний період часу.
База Знань. Створення БЗ ґрунту-
ється на використанні мов дескриптивних
логік і передбачає означення множини ато-
марних концептів та атомарних ролей,
створення термінології (TBox), створення
множини фактів (ABox) та вибір логічної
мови і алгоритмів для цієї мови, за допомо-
гою яких відбувається генерація відповідей
на запити до БЗ. В термінах TBox і ABox
420
Інформатизація освіти
описується еволюція 𝐸𝐸𝐸𝐸 у часі, етапи роз-
витку, крах кафедри тощо. Базовим ядром
дескриптивних логік є логіка ALС, для ал-
горитмів якої існують ефективні реалізації
[3, 4].
Крім того, БЗ виконує також роль
сховища різного роду інформації: теми ди-
пломних робіт, дата захисту дипломної ро-
боти, програмні продукти, розроблені в ди-
пломних роботах, відомості про працевла-
штування випускників кафедри, особові
справи та дані викладачів, відомості про
стаж, терміни стажування, зміни в стано-
вищі працівника кафедри, зміни адреси, но-
мера телефону тощо. Ця інформація до-
ступна лише особам уповноваженим, зок-
рема, адміністратору БЗ. Наявність такої БЗ
дає можливість оперативно реагувати на за-
пити надання інформації про ту чи іншу
особу.
Сервер обміну SEB забезпечує опе-
ративну взаємодію між 𝐸𝐸, 𝐵𝐵 та оточуючим
середовищем. На цьому сервері знахо-
дяться запити до БЗ, які ще не були вико-
нані (в ситуації великого завантаження), ві-
дповіді на запити, які вже опрацьовані, але
не були затребувані, та поточна інформація
про стан БЗ і системи 𝐸𝐸. Основною функ-
цією цього сервера є взаємодія з зовнішнім
середовищем 𝐸𝐸𝐸𝐸. Ця взаємодія полягає в
отриманні інформації про зміни, які відбу-
ваються у зовнішньому середовищі, стан та
потреби ринку, досягнення конкурентів,
нові тенденції в розробці ПЗ, його ринкова
вартість тощо.
Серверна частина EC. В модель
серверної частини вкладаються в даному
випадку викладачі кафедри (сервери), які
задіяні в 𝐸𝐸. Дійсно, множина 𝑆𝑆 - це мно-
жина викладачів (штатні викладачі, суміс-
ники), 𝑄𝑄 - це курси, які можуть виклада-
тися і викладаються викладачами, 𝑜𝑜(𝑆𝑆𝑖𝑖) =
Ω𝑖𝑖 - це сукупність курсів (предметів), які
може викладати конкретний викладач 𝑆𝑆𝑖𝑖,
𝑖𝑖 = 1, … , |Ω|, 𝑓𝑓(𝑆𝑆𝑖𝑖, 𝑤𝑤𝑗𝑗) = (𝑦𝑦,𝑚𝑚, 𝑑𝑑, 𝑡𝑡𝑖𝑖), де 𝑆𝑆𝑖𝑖 ∈
𝑆𝑆, 𝑤𝑤𝑗𝑗 ∈ Ω, (𝑦𝑦,𝑚𝑚, 𝑑𝑑) ∈ 𝐷𝐷, 𝑡𝑡𝑖𝑖 ∈ 𝑄𝑄+ - час вико-
нання викладачем 𝑆𝑆𝑖𝑖 операції 𝑤𝑤𝑗𝑗. Водночас
сервери можуть передавати управління
один одному (в нашому випадку передача
управління робочими серверами один од-
ному регламентується розкладом), де та-
кими серверами є асистенти, доценти, про-
фесори. У разі форс-мажорних ситуацій
(неявка студентів, відсутність освітлення,
відсутність умов проведення заняття, хво-
роба викладача тощо) передбачається взає-
мозв’язок з завідувачем кафедри, методис-
тами кафедри, деканатом, заступниками де-
кана, деканом і передача їм управління для
розв’язання проблеми.
Значення функції 𝑓𝑓 відіграють важ-
ливу роль у 𝐸𝐸𝐸𝐸, за допомогою якої прово-
диться обчислення навантаження на ви-
кладачів та контроль за виконанням за-
вдань. Ці значення - кількісні (часові) оці-
нки складності виконання операцій в най-
гіршому випадку, або взяті з деяких емпі-
ричних спостережень. У даному випадку
враховується як кількість та час вико-
нання навантаження, так і час, витраче-
ний на підготовчі дії (створення курсу ле-
кцій, розробка практичних, семінарських
занять та лабораторних робіт,), чим і ви-
значається вибір викладачів для реалізації
відповідних операцій. Маючи в розпоря-
дженні значення функції 𝑓𝑓 , можна прогно-
зувати ризики в 𝐸𝐸𝐸𝐸 з урахуванням стажу,
досвіду та кваліфікації викладачів (ця ін-
формація береться з БЗ B). Прогнозування
затримок у роботі або ризиків зриву вико-
нання планових занять, передбачених роз-
кладом, дає можливість швидко реагувати
на виклики в 𝐸𝐸𝐸𝐸. Цього можна досягти
шляхом вчасних замін, завчасного інфор-
мування студентів про зміни в розкладі та
перенесення занять (за погодженням із де-
канатом).
Крім того, значення функції 𝑓𝑓 дають
підставу для пошуку оптимального шляху
виконання завдань в EC, оскільки в моделі
(1) припускається, що одне і те саме за-
вдання може виконуватися різними серве-
рами. А це дає можливість використову-
вати оптимізаційні алгоритми для побу-
дови такого плану проведення занять, який
421
Інформатизація освіти
рівномірно розподіляє навантаження на ви-
кладачів, передбачене нормативами, та ка-
федральне обладнання.
Дослідження властивостей моделі
Розглянемо деякі підходи до дослідження
властивостей моделі (1) та ілюстрацію вве-
деного формалізму на прикладі системи E.
В загальному випадку така система може
мати велику сукупність об’єктів, і тоді ви-
никає потреба у оперативному плануванні
й не просто плануванні, а оптимальному
плануванні й управлінні виконанням за-
вдань та доступом до її спільних ресурсів.
Можна запропонувати декілька методів по-
будови оптимального планування та управ-
ління. Складність розв’язання цих задач по-
лягає в тому, що в загальному випадку ці
задачі несуть у собі суперечності об’єктив-
ного характеру. Це і є причиною існування
декількох методів, оскільки для успішного
розв’язання такого типу задач вибирається
певний рівень абстракції, для якого і розро-
бляються відповідні методи. Такого типу
проблеми частіше за все формулюються у
вигляді деякої оптимізаційної задачі, а по-
тім розробляється метод розв’язання такої
задачі.
Далі розглядається автоматно-мережева
модель розв’язання задач планування роз-
поділу базових ресурсів у системі E [5, 6].
Нехай в системі (1)
Ω𝑖𝑖 = {𝑤𝑤1
𝑖𝑖 , 𝑤𝑤2
𝑖𝑖 , … , 𝑤𝑤|Ω𝑖𝑖|
𝑖𝑖 } (2)
означає множину курсів (операцій), які мо-
жуть викладатися (виконуватися) i-м ви-
кладачем (сервером): 𝑖𝑖 = 1, 2, . . . , |𝑆𝑆|,
𝑤𝑤1
𝑖𝑖 , 𝑤𝑤2
𝑖𝑖 , … ,𝑤𝑤|Ω𝑖𝑖|
𝑖𝑖 ∈ Ω. Отже,
𝑜𝑜(𝑆𝑆𝑖𝑖) = Ω𝑖𝑖 (3)
З рівностей (2) і (3) отримуємо, що
𝑓𝑓(𝑆𝑆𝑖𝑖, 𝑤𝑤𝑘𝑘
𝑖𝑖 ) = (𝑦𝑦,𝑚𝑚, 𝑑𝑑, 𝑡𝑡𝑘𝑘𝑖𝑖 ),
𝑖𝑖 = 1,2, … , |𝑆𝑆|, 𝑘𝑘 = 1,2, … , |Ω𝑖𝑖|
(4)
Оскільки в системі допускається мо-
жливість викладання одного і того пред-
мету різними викладачами, то це дає мож-
ливість рівномірного розподілу наванта-
ження і часу для різних викладачів. Отже,
Ω𝑖𝑖 ∩ Ω𝑗𝑗 ≠ ∅, (𝑖𝑖 ≠ 𝑗𝑗).
Звідси випливає, що в такій постано-
вці задача планування розкладу може мати
декілька способів реалізації в системі E.
Дійсно, довільне p-те завдання в E визнача-
ється розкладом занять і є послідовністю
занять (операцій)
𝑂𝑂𝑝𝑝̅̅ ̅ = 𝑜𝑜𝑝𝑝1𝑜𝑜𝑝𝑝2 … 𝑜𝑜𝑝𝑝𝑘𝑘 (5)
де 𝑜𝑜𝑝𝑝1, 𝑜𝑜𝑝𝑝2, … , 𝑜𝑜𝑝𝑝𝑘𝑘 ∈ Ω курси, передбачені
завданням. Оскільки кожне таке завдання
визначається власною послідовністю типу
(5) і існує декілька способів його реалізації
викладачами, то існують і різні варіанти ре-
алізації 𝑂𝑂𝑝𝑝̅̅ ̅. В зв’язку з такою ситуацією на-
кладемо таке обмеження:
Умова 1: початок виконання кож-
ним викладачем наступного завдання (опе-
рації) неможливий доти, доки він не закін-
чить виконання попереднього завдання
(операції).
Для того, щоб реалізувати це обме-
ження та оперативний зв’язок із керівниц-
твом та технічними службами у випадку
форс-мажорних ситуацій, виділимо у сис-
темі E спеціальні сервери X і У, які будемо
називати вхідним і вихідним відповідно,
на відміну від інших серверів, які будемо
називати робочими. Вхідний і вихідний
сервери є підсистемами, які забезпечують
взаємодію робочих серверів між собою і
керівництвом факультету або іншим кері-
вним органом, якому підпорядкована ка-
федра. За допомогою вхідного сервера ке-
рівництво викладає план реалізації за-
вдання j-гo дня (розклад-специфікацію), а
за допомогою вихідного сервера дистан-
ційно контролюється виконання завдання
робочими серверами, виконуються оголо-
шення, озвучуються накази, сповіщається
про небезпеку (наприклад, про повітряну
тривогу) тощо. Крім того, на вихідний сер-
вер викладаються робочими серверами ві-
домості про аварійне завершення вико-
нання завдання з метою узгодження місця
та часу проведення перерваного завдання з
керівним органом (наприклад, деканатом).
Звідси випливає, що вихідний сервер має
певний пріоритет щодо вхідного і робочих
серверів.
Отже, початок виконання деякої по-
слідовності операцій в системі (1) може
422
Інформатизація освіти
специфікуватися в термінах вхідного та ро-
бочих серверів, а її закінчення - в термінах
вихідного сервера. Взаємодія між серве-
рами повинна синхронізуватися в зв’язку з
тим, що різні операції можуть виконува-
тися декількома серверами. Така синхроні-
зація передбачається розкладом-специфіка-
цією виконання завдання. Але для операти-
вного реагування на непередбачувані випа-
дки і забезпечення виконання умови 1, вво-
дяться спільні булеві змінні 𝑏𝑏1, 𝑏𝑏2, … , 𝑏𝑏𝑚𝑚 =
0, значення яких може читати кожний із
серверів шляхом комунікації з вихідним
сервером. Тоді, наприклад, значення 𝑏𝑏1 =
0, 𝑏𝑏2 = 1, 𝑏𝑏3 = 0 означають, що сервер S2
зайнятий, а сервери S1 і S3 вільні і готові ви-
конувати операції завдання.
Модель екосистеми “Кафедра”
Для того, щоб продемонструвати
підхід до аналізу властивостей наведеної
моделі ЕС, розглянемо приклад дослі-
дження властивостей моделі екосистеми
“Кафедра”, яка має сім робочих серверів
виконання завдання одного робочого дня
кафедри, одним вхідним, одним вихідним
серверами та одним сервером управління.
Таку екосистему можна представити у гра-
фічному вигляді (див. рис. 2). Зауважимо,
що така конкретизація не обмежує загаль-
ності моделі, оскільки цю модель можна
адаптувати та деталізувати відповідно до
правил, які регламентують роботу конкрет-
ного ЗВО. Позначення 𝑆𝑆𝑚𝑚/𝑆𝑆𝑛𝑛 означає, що
реалізація операції може виконуватися або
на сервері 𝑆𝑆𝑚𝑚, або на сервері 𝑆𝑆𝑛𝑛.
На вхідний сервер X завантажується
розклад-специфікація завдання (j-гo робо-
чого дня кафедри) - послідовність операцій
(предметів) завдання. Коли виконання за-
кінчується, то його результат подається на
вихідний сервер Y. Для кожного завдання і
кожної пари приписується множина серве-
рів із множини 𝑆𝑆 = {𝑆𝑆1, 𝑆𝑆2, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆5, 𝑆𝑆6, 𝑆𝑆7} і
множина операцій із Ω = {𝑤𝑤1
1 − 𝑤𝑤1
4, 𝑤𝑤2
1 −
𝑤𝑤2
4, 𝑤𝑤3
1 − 𝑤𝑤3
4, 𝑤𝑤4
1 − 𝑤𝑤4
4}. Одна і та сама опе-
рація може бути приписана до різних за-
вдань.
Сервер управління D реалізує функ-
ції деканату, в його завдання входять фун-
кції регуляції виконання операцій або за-
вдань у випадку форс-мажорних ситуацій
(неможливість виконання операцій, хво-
роба виконавців, військові обставини
тощо), розв’язання спірних або конфлікт-
них питань. Крім того, однією з функцій
цього сервера є узгодження дати і часу пе-
реносу виконання завдань чи окремих опе-
рацій завдання. Ця функція досить важ-
лива, оскільки передбачає успішне функці-
онування деканату як органу управління і
комунікації з виконавцями.
Графічне зображення розкладу-
специфікації
Припустимо, що розклад завдання
j-гo дня роботи кафедри для чотирьох кур-
сів бакалаврату специфікується даними з
табл. 1.
Таблиця 1
Розклад-специфікація j-гo робочого дня кафедри для бакалаврату
j-й день Завдання 1 Завдання 2 Завдання 3 Завдання 4
Пара операція сервер операція сервер операція сервер операція сервер
1 𝑤𝑤1
1 𝑆𝑆1/𝑆𝑆4 𝑤𝑤1
2 𝑆𝑆4/𝑆𝑆2 𝑤𝑤1
3 𝑆𝑆5/𝑆𝑆3 𝑤𝑤1
4 𝑆𝑆7/𝑆𝑆1
2 𝑤𝑤2
1 𝑆𝑆2/𝑆𝑆3 𝑤𝑤2
2 𝑆𝑆5/𝑆𝑆1 𝑤𝑤2
3 𝑆𝑆4/𝑆𝑆6 𝑤𝑤2
4 𝑆𝑆5/𝑆𝑆3
3 𝑤𝑤3
1 𝑆𝑆2/𝑆𝑆4 𝑤𝑤3
2 𝑆𝑆3/𝑆𝑆6 𝑤𝑤3
3 𝑆𝑆7/𝑆𝑆2 𝑤𝑤3
4 𝑆𝑆4/𝑆𝑆2
4 𝑤𝑤4
1 𝑆𝑆3/𝑆𝑆6 𝑤𝑤4
2 𝑆𝑆3/𝑆𝑆5 𝑤𝑤4
3 𝑆𝑆1/𝑆𝑆4 𝑤𝑤4
4 𝑆𝑆1/𝑆𝑆6/𝑆𝑆7
423
Інформатизація освіти
Тоді, повертаючись до позначень із (2), діста-
ємо:
Ω1 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
Ω2 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
Ω3 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
Ω4 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
Ω5 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
Ω6 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
Ω7 = {𝑤𝑤1
1, 𝑤𝑤1
4, 𝑤𝑤2
3, 𝑤𝑤4
3, 𝑤𝑤4
4}
(6)
Процедури реалізації плану задаються
такими послідовностями:
X1𝑗𝑗 = {𝑤𝑤1
1, 𝑤𝑤2
1, 𝑤𝑤3
1, 𝑤𝑤4
1} =
(𝑆𝑆1 ∨ 𝑆𝑆4)(𝑆𝑆2 ∨ 𝑆𝑆3)(𝑆𝑆2 ∨ 𝑆𝑆4)(𝑆𝑆6 ∨ 𝑆𝑆3)
X2𝑗𝑗 = {𝑤𝑤1
2, 𝑤𝑤2
2, 𝑤𝑤3
2, 𝑤𝑤4
2} =
(𝑆𝑆2 ∨ 𝑆𝑆4)(𝑆𝑆1 ∨ 𝑆𝑆5)(𝑆𝑆3 ∨ 𝑆𝑆6)(𝑆𝑆3 ∨ 𝑆𝑆5)
X3𝑗𝑗 = {𝑤𝑤1
3, 𝑤𝑤2
3, 𝑤𝑤3
3, 𝑤𝑤4
3} =
(𝑆𝑆5 ∨ 𝑆𝑆3)(𝑆𝑆4 ∨ 𝑆𝑆6)(𝑆𝑆2 ∨ 𝑆𝑆7)(𝑆𝑆1 ∨ 𝑆𝑆4)
X4𝑗𝑗 = {𝑤𝑤1
4, 𝑤𝑤2
4, 𝑤𝑤3
4, 𝑤𝑤4
4} =
(𝑆𝑆1 ∨ 𝑆𝑆7)(𝑆𝑆3 ∨ 𝑆𝑆5)(𝑆𝑆2 ∨ 𝑆𝑆4)(𝑆𝑆1 ∨ 𝑆𝑆6
∨ 𝑆𝑆7)
(7)
де X𝑖𝑖𝑗𝑗 означає і-те завдання j-го дня роботи,
𝑖𝑖 = 1,2, … ,6.
На підставі розкладу-специфікації
виконання завдань, визначеного табл. 1,
можна реалізувати шляхи виконання за-
вдань. За цих обставин результати вико-
нання завдань фіксуються на вихідному
сервері Y, де у разі невиконання якоїсь опе-
рації інформація про це транзитом через усі
проміжні робочі сервери (або іншим мож-
ливим способом) передається на вихідний
сервер.
Рис. 2. Графічне зображення розкладу ви-
конання завдань j-гo робочого дня
Якщо на вихідному сервері фіксу-
ється невиконання якогось завдання або
якоїсь операції такого завдання, то за пого-
дженням із деканатом формується послідо-
вність дій, яка передається на вхідний сер-
вер для реалізації.
У разі успішного виконання за-
вдання інформація про це теж передається
на вихідний сервер, але така інформація не
передбачає реагування.
Властивості моделі
Що корисного можна отримати з на-
веденої моделі, які властивості можна про-
слідкувати за її допомогою?
Перше, що випливає з наведеної мо-
делі, - це можливість побудувати для ви-
кладачів зручний розклад реалізації за-
вдань із врахуванням рівномірності розпо-
ділу навантаження на викладачів. Дійсно,
виходячи із сказаного, отримуємо такі
шляхи виконання першого завдання на під-
ставі (7):
𝑆𝑆1, 𝑆𝑆2, 𝑆𝑆2, 𝑆𝑆6, 𝑆𝑆4, 𝑆𝑆2, 𝑆𝑆2, 𝑆𝑆6, 𝑆𝑆1, 𝑆𝑆3, 𝑆𝑆2, 𝑆𝑆6, 𝑆𝑆4, 𝑆𝑆3, 𝑆𝑆2, 𝑆𝑆6;
𝑆𝑆1, 𝑆𝑆2, 𝑆𝑆2, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆2, 𝑆𝑆2, 𝑆𝑆3, 𝑆𝑆1, 𝑆𝑆3, 𝑆𝑆2, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆3, 𝑆𝑆2, 𝑆𝑆3;
𝑆𝑆1, 𝑆𝑆2, 𝑆𝑆4, 𝑆𝑆6, 𝑆𝑆4, 𝑆𝑆2, 𝑆𝑆4, 𝑆𝑆6, 𝑆𝑆1, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆6, 𝑆𝑆4, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆6;
𝑆𝑆1, 𝑆𝑆2, 𝑆𝑆4, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆2, 𝑆𝑆2, 𝑆𝑆3, 𝑆𝑆1, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆3, 𝑆𝑆4, 𝑆𝑆3.
Серед цих шляхів вибирається той,
який найбільш зручний для викладачів та
прослідкувати їх навантаження. Оскільки
цих варіантів скінченна кількість, то їх
аналіз можна виконати вручну. Водночас,
виходячи з інформації про кваліфікацію
викладачів, їх ведення занять, рівень під-
готовки студентів та інших характерис-
тик, можна обрати найкращий шлях реа-
лізації виконання завдань у вибраній мо-
делі системи. Наприклад, реалізацію пер-
шого завдання можна виконати послідов-
ністю 𝑆𝑆2, 𝑆𝑆4, 𝑆𝑆4, 𝑆𝑆6 або послідовністю
𝑆𝑆4, 𝑆𝑆4, 𝑆𝑆2, 𝑆𝑆6, а також послідовністю
𝑆𝑆4, 𝑆𝑆2, 𝑆𝑆4, 𝑆𝑆6, яка, очевидно, не є зручною
для викладача 𝑆𝑆4.
Друге, можливість полегшити ро-
боту методистів як кафедри, так і методис-
тів деканату через внесення додаткової ін-
формації в графічне зображення. Ця інфор-
мація вноситься на випадок зриву вико-
нання якоїсь операції (наприклад, немож-
ливість фізичної присутності виконавця на
424
Інформатизація освіти
місці праці, затримка транспортних засобів
у корках, хвороба виконавця операції, від-
сутність студентів в аудиторії тощо).
Така модифікація графічного зобра-
ження виконання завдань набуває вигляду:
Рис. 3. Модифіковане графічне зображення
розкладу виконання завдань j-гo дня
У модифікованому таким чином гра-
фіку вказуються можливі заміни виконання
операцій іншими виконавцями, які в стані
повноцінно виконати операцію і можливо
завдання в цілому.
Третє, наявність такого графічного
зображення полегшує працівникам дека-
нату розробку розкладу роботи як кафедри,
так і факультету в цілому. Останнє потре-
бує графічних зображень від усіх кафедр
факультету. Водночас методисти дістають
змогу розробити розклад з мінімізацією кі-
лькості викладачів протягом робочого дня
у разі дефіциту аудиторного фонду та тех-
нічного обладнання.
Автоматно-мережева модель
екосистеми
Оскільки виконання завдань в сис-
темі відбувається паралельно, то будемо мо-
делювати процес виконання цих завдань ме-
режею автоматів, яка є підходящою матема-
тичною моделлю для таких процесів [2].
Спочатку розглянемо автоматне зображення
виконання одного завдання в системі.
Автомат, який моделює виконання
k-го завдання, набуває вигляду:
𝐴𝐴𝑘𝑘𝑘𝑘 = (𝐴𝐴 = {𝐷𝐷, 𝑋𝑋𝑘𝑘𝑘𝑘, 𝑊𝑊𝑘𝑘𝑘𝑘, 𝑌𝑌𝑘𝑘𝑘𝑘, 𝑆𝑆ℎ𝑘𝑘𝑘𝑘, 𝑤𝑤𝑘𝑘𝑘𝑘
1 , 𝑤𝑤𝑘𝑘𝑘𝑘
2 , 𝑤𝑤𝑘𝑘𝑘𝑘
3 , 𝑤𝑤𝑘𝑘𝑘𝑘
4 }, 𝑍𝑍𝑘𝑘𝑘𝑘 =
= {𝑏𝑏, 𝑏𝑏𝑘𝑘𝑘𝑘, 𝑠𝑠𝑘𝑘𝑘𝑘, 𝑡𝑡𝑘𝑘𝑘𝑘, 𝑎𝑎𝑘𝑘𝑘𝑘
1 , 𝑎𝑎𝑘𝑘𝑘𝑘
2 , 𝑎𝑎𝑘𝑘𝑘𝑘
3 , 𝑎𝑎𝑘𝑘𝑘𝑘
4 , 𝑏𝑏𝑘𝑘𝑘𝑘
1 , 𝑏𝑏𝑘𝑘𝑘𝑘
2 , 𝑏𝑏𝑘𝑘𝑘𝑘
3 , 𝑏𝑏𝑘𝑘𝑘𝑘
4 }, 𝐷𝐷, 𝑓𝑓𝑘𝑘𝑘𝑘, 𝐷𝐷),
де
- стан 𝑊𝑊𝑘𝑘𝑘𝑘 зображує ланцюжок ста-
нів виконання операцій 𝑤𝑤𝑘𝑘𝑘𝑘
1 , 𝑤𝑤𝑘𝑘𝑘𝑘
1 , 𝑤𝑤𝑘𝑘𝑘𝑘
1 , 𝑤𝑤𝑘𝑘𝑘𝑘
1 ;
- стани 𝑋𝑋𝑘𝑘𝑘𝑘, 𝑌𝑌𝑘𝑘𝑘𝑘 зображують вхід-
ний і вихідний сервери k-гo завдання;
- 𝑍𝑍𝑘𝑘𝑘𝑘 – вхідний алфавіт автомата;
- стан 𝑤𝑤𝑘𝑘𝑘𝑘
𝑟𝑟 зображує стани вико-
нання операції 𝑤𝑤𝑘𝑘𝑘𝑘
1 , 𝑟𝑟 = 1, 2, 3, 4;
- стан 𝑆𝑆ℎ𝑘𝑘𝑘𝑘 зображує планування
виконання аварійно закінченого завдання
𝑤𝑤𝑘𝑘𝑘𝑘
𝑟𝑟 , 𝑟𝑟 = 1, 2, 3, 4;
- символи 𝑏𝑏, 𝑏𝑏𝑘𝑘𝑘𝑘, 𝑠𝑠𝑘𝑘𝑘𝑘 означають по-
чаток виконання і успішне виконання за-
вдання відповідно;
- символи 𝑎𝑎𝑘𝑘𝑘𝑘
1 , 𝑎𝑎𝑘𝑘𝑘𝑘
2 , 𝑎𝑎𝑘𝑘𝑘𝑘
3 , 𝑎𝑎𝑘𝑘𝑘𝑘
4 , 𝑏𝑏𝑘𝑘𝑘𝑘
1 , 𝑏𝑏𝑘𝑘𝑘𝑘
2 ,
𝑏𝑏𝑘𝑘𝑘𝑘
3 , 𝑏𝑏𝑘𝑘𝑘𝑘
4 означають аварійне закінчення r-ї
операції і повторне виконання цієї операції
відповідно.
Початковим і заключним станом ав-
томата є стан D, а функція переходів 𝑓𝑓𝑘𝑘𝑘𝑘 зо-
бражена графом переходів на рис. 4.
Рис. 4. Автомат 𝐴𝐴𝑘𝑘𝑘𝑘 виконання k-гo за-
вдання j-гo дня
Тепер можна представити виконання за-
вдань j-гo дня роботи кафедри такою мере-
жею із автоматів:
425
Інформатизація освіти
Рис. 5. Мережа з автоматів, яка моделює
роботу j-гo робочого дня кафедри
Висновки
Як випливає зі сказаного, всі процеси,
задіяні в моделі, можуть бути автоматизо-
вані. А це дозволяє як в ручному, так і в ди-
станційному режимі виконувати управ-
ління таким об’єктом, як ’’Кафедра”. Зрозу-
міло також, що цю модель можна застосу-
вати до моделювання роботи факультету і
ЗВО в цілому.
Література
1. Kryvyi S., Opanasenko V., Grinenko Е. Logical
approach to the researcher of properties of
software engineering ecosystem. 11th Int. IEEE
Conf, on Dependable Systems, Services and
Technologies. (IEEE DESSERT 2020). – Kyiv,
2020, pp. 456-464.
2. Кривий С.Л. Скінченні автомати: теорія, ал-
горитми, складність. - Чернівці-Київ: Бук-
рек, 2020. - 427 с.
3. Baader F., Horrocks I., Carsten L., Sattler U. An
Introduction to Description Logics. -
Cambridge University Press, 2017. - 255 p.
4. Balmelli L.,Brown D., Cantor M., Mott M.
Model-driven systems development. IBM
Systems Journal, 2006. V. 45. Pp. 569-585.
5. Reisig W. Petri nets. An introduction. Springer
Verlag: Berlin Heidelberg, 1985. 161 p.
6. Arnold A. Finite Transition Systems: Semantics
of Communicating Systems. - Paris: Prentice
Hall, 1994. - 177 p.
References
1. Kryvyi S., Opanasenko V., Grinenko Е. Logical
approach to the researcher of properties of
software engineering ecosystem. 11th Int. IEEE
Conf, on Dependable Systems, Services and
Technologies. (IEEE DESSERT 2020). – Kyiv,
2020, pp. 456-464.
2. Kryvyi S. Skinchenni avtomaty: teoriya, algo-
ritmi, skladnist. – Chernivtsi-Kyiv: Bukrek,
2020. - 427 p.
3. Baader F., Horrocks I., Carsten L., Sattler U. An
Introduction to Description Logics. -
Cambridge University Press, 2017. - 255 p.
4. Balmelli L.,Brown D., Cantor M., Mott M.
Model-driven systems development. IBM
Systems Journal, 2006. V. 45. Pp. 569-585.
5. Reisig W. Petri nets. An introduction. Springer
Verlag: Berlin Heidelberg, 1985. 161 p.
6. Arnold A. Finite Transition Systems: Semantics
of Communicating Systems. - Paris: Prentice
Hall, 1994. - 177 p.
Одержано: 05.04.2024
Внутрішня рецензія отримана: 17.04.2024
Зовнішня рецензія отримана: 22.04.2024
Про авторів:
1Кривий Сергій Лук'янович,
доктор фізико-математичних наук,
професор
https://orcid.org/0000-0003-4231-0691
2Гріненко Олена Олександрівна,
кандидат технічних наук,
https://orcid.org/0000-0001-9673-6626
Місце роботи авторів:
1Київський національний університет
імені Тараса Шевченка,
тел. +38-097-334-60-56
E-mail: sl.krivoi@gmail.com
https://knu.ua/
2Київський національний університет
імені Тараса Шевченка,
Тел. +38-097-912-59-20
E-mail: olena.grinenko@knu.ua,
https://knu.ua
|