ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9110| Title: | CMS-системи для конструювання простих сайтiв |
| Authors: | Заспа, Григорій Олександрович Строганов, Янош Романович |
| Keywords: | автоматизація;CMS;менеджмент;управління;automation;CMS;management;control |
| Issue Date: | 17-Jun-2024 |
| Abstract: | АНОТАЦІЯ
Строганов Я.Р. – «CMS-системи для конструювання простих сайтiв»:
кваліфікаційна робота бакалавра з спеціальності 121 – «Інженерія програмного
забезпечення» ЧДТУ, м.Черкаси 2024 рік.
Метою виконання кваліфікаційної роботи бакалавра є створення
програмного забезпечення інформаційної системи CMS-систему для
конструювання простих сайтiв.
Система складається з наступних модулів:
1 Інформаційний пошук методів та засобів розв’язання заданих задач;
2 Конструювання програмного забезпечення інформаційної системи CMS
для конструювання простих сайтiв;
3 Проектування програмного забезпечення інформаційної системи CMS
для конструювання простих сайтiв;
4 Тестування усунення недоліків програмного забезпечення;
5 Провадження та супроводження програмного забезпечення.
Для розробки програмного забезпечення для CMS-системи для
конструювання простих сайтiв проектуванні інформаційні системи які включають
аналіз предметної області, розробку логічної структури системи, проектування
інтерфейсу, створення бази даних, проведення модульного, інтеграційного,
системного та приймального тестування.
Об’єктом роботи є процес проектування конструювання тестування
програмного забезпечення інформаційних систем
Ключові слова: автоматизація, CMS, менеджмент, ANNOTATION Stroganov Y.R. - "CMS-systems for designing simple websites": bachelor's thesis in the specialty 121 - "Software Engineering", Cherkasy, 2024. The purpose of performing The Bachelor's qualification work is to create a CMS Information System Software-a system for designing simple websites. The system consists of the following modules: 1 Information search for methods and tools for solving given problems; 2 Designing cms information system software for designing simple websites; 3 Designing cms information system software for designing simple websites; 4 Testing to fix software flaws; 5 Production and maintenance of software. For the development of software for CMS-systems for the design of simple sites designing information systems that include analysis of the subject area, development of the logical structure of the system, interface design, database creation, conducting modular, integration, system and acceptance testing. The object of the work is the process of designing designing testing software for information systems Keywords: automation, CMS, management, management |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9110 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна роота бакалавра Строганов Ягош Романович.pdf Restricted Access | 5.03 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: CMS-система для конструювання простих сайтiв
Виконав: студент 4 курсу, групи ПЗ-2004
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Строганов Я.Р.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент вказати
(прізвище та ініціали)
Черкаси 2024
482 ЧДТУ 242060.015 1201 1
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
«___» _______________ 2024 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Строганов Янош Романович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) CMS-системи для конструювання простих сайтiв
Керівник проекту (роботи) Заспа Григорій Олександрович (доповнити)
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «26 лютого»
2024 року № 60/04
2.Строк подання студентом проекту (роботи) 03.06.2024
3. Вхідні дані до проекту (роботи) 1) Платформа x86-64, Операційна система Windows 11, Мова
програмування PHP 8.3.8
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результатів дослідження у практику проектування програмного
забезпечення інформаційних систем
Розділ 3. Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки А, Додатки Б, Додатки В, Додатки Г.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Слайд №1. Слайд №2. Слайд №3. Слайд №4. Слайд №5. Слайд №6. Слайд №7. Слайд №8.
Слайд №9 Слайд №10. Слайд №11. Слайд №12. Слайд №13. Слайд №14. Слайд №15
78
482 ЧДТУ 242060.015 1201 1
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 2 грудня 2023 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 02.12.2023 виконано
2 Підготовка завдання 05.01.2024 виконано
3 Погодження завдання 16.01.2024 виконано
4 Затвердження завдання 26.02.2024 виконано
Основна стадія
1 Підбір матеріалів 27.02.2024 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.02.2024 виконано
3 Розрахунок основних параметрів роботи 10.03.2024 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2024 виконано
5 Оформлення первісної редакції роботи 25.03.2024 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з
керівником
2 Оформлення пояснювальної записки роботи в
кінцевій редакції
3 Попередній захист роботи
4 Затвердження роботи
5 Рецензування роботи
6 Захист роботи
Студент _____________________ Строганов Я.Р.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Заспа Г.О
(підпис) (прізвище та ініціали)
79
482 ЧДТУ 242060.015 1201 1
АНОТАЦІЯ
Строганов Я.Р. – «CMS-системи для конструювання простих сайтiв»:
кваліфікаційна робота бакалавра з спеціальності 121 – «Інженерія програмного
забезпечення» ЧДТУ, м.Черкаси 2024 рік.
Метою виконання кваліфікаційної роботи бакалавра є створення
програмного забезпечення інформаційної системи CMS-систему для
конструювання простих сайтiв.
Система складається з наступних модулів:
1 Інформаційний пошук методів та засобів розв’язання заданих задач;
2 Конструювання програмного забезпечення інформаційної системи CMS
для конструювання простих сайтiв;
3 Проектування програмного забезпечення інформаційної системи CMS
для конструювання простих сайтiв;
4 Тестування усунення недоліків програмного забезпечення;
5 Провадження та супроводження програмного забезпечення.
Для розробки програмного забезпечення для CMS-системи для
конструювання простих сайтiв проектуванні інформаційні системи які включають
аналіз предметної області, розробку логічної структури системи, проектування
інтерфейсу, створення бази даних, проведення модульного, інтеграційного,
системного та приймального тестування.
Об’єктом роботи є процес проектування конструювання тестування
програмного забезпечення інформаційних систем
Ключові слова: автоматизація, CMS, менеджмент, управління.
80
482 ЧДТУ 242060.015 1201 1
ANNOTATION
Stroganov Y.R. - "CMS-systems for designing simple websites": bachelor's thesis
in the specialty 121 - "Software Engineering", Cherkasy, 2024.
The purpose of performing The Bachelor's qualification work is to create a CMS
Information System Software-a system for designing simple websites.
The system consists of the following modules:
1 Information search for methods and tools for solving given problems;
2 Designing cms information system software for designing simple websites;
3 Designing cms information system software for designing simple websites;
4 Testing to fix software flaws;
5 Production and maintenance of software.
For the development of software for CMS-systems for the design of simple sites
designing information systems that include analysis of the subject area, development of
the logical structure of the system, interface design, database creation, conducting
modular, integration, system and acceptance testing.
The object of the work is the process of designing designing testing software for
information systems Keywords: automation, CMS, management, management
Keywords: automation, CMS, management, control.
81
482 ЧДТУ 242060.015 1201 1
ЗМІСТ
АНОТАЦІЯ ............................................................................................................ 6
ВСТУП .................................................................................................................... 8
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ..................................................................... 11
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ У
ПРАКТИКУ ПРОЕКТУ ВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ................................................................. 15
2.1 Моделювання предметної області .......................................................... 16
2.1.1 Предметна область моделювання. Модель предметної
області. Словник предметної області ........................................................ 17
2.1.2 Елементи моделювання предметної області ........................... 19
2.1.3 Розробка області моделювання ................................................ 21
2.2 Формування та аналіз вимог ............................................................ 23
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
\
нефункціональні вимоги ............................................................................. 24
2.2.2 Формування вимог за допомогою діаграм прецедентів......... 27
2.3 Проектування логічної структури програмного комплексу ......... 29
2.3.1 Діаграма класів ........................................................................... 30
2.3.2 Діаграма пакетів ......................................................................... 33
2.4 Архітектурне проектування ............................................................. 34
2.4.1 Діаграма компонентів ................................................................ 34
2.4.2 Розгортання програмної системи на апаратних засобах.
Діаграма розгортання .................................................................................. 36
2.5 Моделювання поведінки системи ................................................... 38
2.5.1 Діаграма діяльності .................................................................... 39
Зм. № Докум. ЧДТУ 242234.00 1ПЗ
Лист Підпис Дата
Р озроб. Бакалов А.І. «Однокористувацька FPS гра за Літ. Лист Листів
К
ерівник Олексюк. В.В. допомогою рушія UE5»
Н.контр. Півень О.Б. (Пояснювальна записка) ФІТІС, Кафедра ПЗАС,
Затв. Голуб С.В. ПЗС-2144 82
482 ЧДТУ 242060.015 1201 1
2.5.2 Діаграма послідовності ................................................................ 39
2.5.3 Діаграма комунікації ................................................................. 41
2.5.4 Діаграма скінченного автомату ................................................ 42
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ....................................................................................... 45
3.1 Розробка програмного комплексу .................................................... 45
3.1.1 Обґрунтування вибору засобів реалізації ................................ 46
3.1.2 Опис структурної (функціональної) схеми ............................. 50
3.1.3 Опис логічної схеми системи ................................................... 51
3.1.4 Розробка бази даних .................................................................. 52
3.1.5 Розробка інтерфейсу користувача ............................................ 53
3.1.6 Опис розробки програмних компонентів ................................ 58
3.2 Тестування системи .......................................................................... 61
3.2.1 Модульне тестування ................................................................ 61
3.2.2 Інтеграційне тестування ............................................................ 63
3.2.3 Системне тестування ................................................................. 66
3.2.4 Приймальне тестування............................................................. 67
3.3 Приклади впровадженого програмного комплексу ...................... 69
ВИСНОВКИ ................................................................................................. 71
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................. 72
ДОДАТОК А ................................................................................................ 75
ДОДАТОК Б ................................................................................................ 77
ДОДАТОК В ................................................................................................ 90
ДОДАТОК Г ................................................................................................ 94
ВСТУП
Зм. № Докум. ЧДТУ 242234.001ПЗ
Лист Підпис Дата
Р озроб. Бакалов АА.Ік. туальність теми: «Однокористувацька FPS гра за Літ. Лист Листів
К ерівник О лексюк. В.В. допомогою рушія UE5»
Н.контр. Півень О.Б. (Пояснювальна записка) ФІТІС, Кафедра ПЗАС8,3
З атв. Голуб С.В. ПЗС-2144
482 ЧДТУ 242060.015 1201 1
Актуальність визначається потребою у розробці програмного забезпечення
інформаційної системи менеджменту контенту (CMS) є надзвичайно потужним
інструментом для створення та управління веб-сайтами, особливо простими веб-
сайтами.
Система менеджмента контенту (CMS) дозволяє швидко створювати і
ефективно керувати веб-сайтами, знижуючи витрати на розробку і підтримку, та
може надавати широкий спектр інструментів для оптимізації впровадження
контенту та розширення можливостей сайту.
Актуальність теми полягає в тому, що така система є оптимальним
рішенням для малих підприємств, індивідуальних користувачів і організацій, які
потребують простого, але ефективного інструменту для створення та управління
своїми веб-ресурсами.
Мета і завдання розробки:
Метою роботи є розробка програмного забезпечення інформаційної
технології – розробити систему менеджменту контенту (CMS) яка поєднує в собі
функції адміністрування користувачів, відтворення та управління контентом.
Завдання:
1 Інформаційний пошук методів, засобів та методик побудови програмного
забезпечення інформаційних систем виконання поставлених завдань
2 Проектування програмного забезпечення інформаційної системи
менеджменту контенту (CMS)
3 Конструювання програмного забезпечення інформаційної системи
менеджменту контенту (CMS)
4 Тестування програмного забезпечення інформаційної системи
менеджменту контенту (CMS)
5 Впровадження та супроводження програмного забезпечення
інформаційної системи менеджменту контенту (CMS)
Об’єкт розробки
Процес побудови програмного забезпечення інформаційних систем.
Предмет розробки
84
482 ЧДТУ 242060.015 1201 1
процес побудови програмного забезпечення інформаційної системи систему
менеджменту контенту (CMS).
Методи проектування та конструювання
використання модульної архітектури для системи;
використовується простий та інтуїтивний інтерфейс для користувача;
система є гнучкою і може бути адаптована до потреб конкретного
клієнта;
система оптимізована для ефективного використання ресурсів сервера і
забезпечує стабільну роботу навіть при високих навантаженнях;
його розробка включає створення надійної бази даних для зберігання
інформації.
Опис отриманих результатів:
Розроблене програмне забезпечення для корисні та функціональної системи
управління контентом (CMS), яке може значно спростити управління контентом,
підвищити продуктивність та забезпечити комфортне середовище для
відтворення контенту.
Особистий внесок автора:
На основі аналізу цільової аудиторії та поточних потреб було розроблено
рішення свої вимог та планування можливостей майбутньої системи.
розробити модульну архітектуру системи, яка забезпечує гнучкість,
масштабованість і можливість легко додавати або видаляти функції;
розробка ключових компонентів системи, включаючи ядро, інтерфейс
користувача, набір базових функцій;
інтеграція та тестування функцій системи, забезпечення стабільності та
безпеки його роботи;
оптимізуйте використання ресурсів сервера, щоб система працювала
ефективно навіть при високому навантаженні;
розробка надійної системи зберігання даних для зберігання інформації
про користувачів та відтворений контент;
створення детальної документації та посібників з експлуатації для
спрощення використання та подальшої розробки системи управління
контентом (CMS).
85
482 ЧДТУ 242060.015 1201 1
РОЗДІЛ 1 ІСНУЮЧУ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАДАЧ
Є безліч систем управління контентом(CMS), які мають різну
функціональність. Більшість з них призначені для поліпшення взаємодії з
контентом і розширення функціональності веб-ресурсу. Але моє головне завдання
це дослідити ці системи і визначити їх плюси і мінуси.
WordPress
Плюси:
простота використання, інтуїтивно зрозумілий інтерфейс, легко
навчитися і використовувати;
велика кількість плагінів та тем;
велика спільнота користувачів та розробників, багато ресурсів і
документацій;
вбудовані можливості SEO та плагіни для поліпшення SEO.
підходить для різних типів сайтів – від блогів до інтернет-магазинів
мінуси:
через популярність є частою ціллю для хакерів, потребує регулярних
оновлень і додаткових заходів безпеки;
може сповільнюватись при використанні великої кількості плагінів;
для складних проектів може знадобитися значна адаптація та
програмування.
Joomla
Плюси:
більш гнучка у порівнянні з WordPress, підходить для складних сайтів;
вбудована підтримка багатомовних сайтів;
більш розширене управління користувачами та правами доступу;
широкий вибір розширень та модулів.
Мінуси:
менш інтуїтивно зрозуміла для початківців у порівнянні з WordPress;
86
482 ЧДТУ 242060.015 1201 1
менше шаблонів та розширень порівняно з WordPress;
вимагає регулярного оновлення та додаткових заходів.
Drupal
Плюси:
ідеально підходить для створення складних і масштабованих веб-
сайтів;
високий рівень безпеки, підходить для урядових і корпоративних
сайтів;
можливість створення унікальних функціональних рішень;
вбудована підтримка багатомовних сайтів.
Мінуси:
крута крива навчання, вимагає значних технічних знань;
менше доступних тем і модулів у порівнянні з WordPress;
часто вимагає найму професіональних розробників, що збільшує
витрати на розробку та підтримку.
Magento
Плюси:
високофункціональна платформа для створення інтернет-магазинів;
підходить для малих і великих підприємств;
вбудована можливість для SEO;
підтримує багатомовні та багатовалютні сайти.
Мінуси:
вимагає значних технічних знань для налаштування та управління;
високі витрати на розробку, підтримку та хостинг;
вимагає потужного хостингу для забезпечення швидкодії.
Wix
Плюси:
дуже простий у використанні, підходить для новачків;
широкий вибір красивих і адаптивних шаблонів;
87
482 ЧДТУ 242060.015 1201 1
не потрібно окремого хостингу, все включено в одну платформу;
потужні візуальні інструменти для налаштування дизайну
Мінуси:
обмежена можливість налаштування і розширення у порівнянні з
відкритими CMS;
обмежені можливості доступу до коду сайту для його кастомізації;
менш потужні SEO-інструменти в порівнянні з іншими CMS.
Постановка завдання цієї кваліфікаційної роботи бакалавра є створення
простої CMS для створення простих веб-сайтів.
Постановка задачі
Підчас розглядів аналогів було виявлено що ринку не притаманна розробка
нових подібних систем так як вже э велика кількість готових продуктів з широким
функціоналом а існуючі аналоги розробляємого проєкту застарілі, тому при
розробці кваліфікаційної роботи бралось до уваги вузконаправленість розробки.
Від самої системи вимагається
базовий набір функцій
простий користувацький інтерфейс
простота встановлення
88
482 ЧДТУ 242060.015 1201 1
ВИСНОВОК ДО РОЗДІЛУ 1
Основне завдання цього розділу кваліфікаційної роботи бакалавра з
розробки CMS-системи для конструювання простих сайтiв, що використовуються
для створення, управління та модифікації цифрового контенту на вебсайтах, це
аналіз аналогів розроблюваної системи, виділення їх плюсів, мінусів та виділення
базового набору функції та вимог до подібної системи.
Ця розробка матиме наступні характеристики:
модульна архітектура: CMS розроблена з використанням модульної
архітектури. Це полегшить додавання та видалення функцій, а також їх
розширення в майбутньому;
інтуїтивно зрозумілий інтерфейс: CMS оснащена інтуїтивно зрозумілим
інтерфейсом користувача, який дозволяє їм, користувачам, легко
керувати нею, CMS, не вивчаючи додаткові матеріали;
базовий набір функцій: розроблена CMS повинна мати базовий набір
функцій , а саме функцію управління обліковими записами
користувачів, функцію створення, управління та модифікації цифрового
контенту, та систему авторизації;
гнучкість: розроблена CMS має бути гнучкою і мати можливість
налаштування і адаптації до потреб конкретного замовника;
продуктивність: розроблена CMS має бути оптимізованою для
ефективного використання ресурсів сервера.
89
482 ЧДТУ 242060.015 1201 1
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
У цьому розділі основними ключовими моментами застосування
результатів досліджень у процесі проектування системи менеджменту контенту
(CMS).
Архітектура
Система менеджменту контенту (CMS), як і будь-яка інша подібна система,
має власну архітектуру, яка визначає їх структури та взаємодію між її
компонентами. Уявіть собі будинок, в якому кожен поверх відповідає за певну
функцію:
Підвал:
тут зберігається вся інформація, необхідна для роботи CMS:
користувачі, контент, пости і т.д;
це може бути схоже на "базову" базу даних, кеш або іншу систему
зберігання.
Перший поверх:
це те, що користувач бачить і з чим взаємодіє;
крім того, інтерфейс представлений у вигляді графічного інтерфейсу
користувача (gui) для взаємодії з користувачем.
Другий поверх:
це "мозок" системи, в якому виконується вся основна робота;
тут обробляються користувацькі запити, контролюється
автоматизація та виконується вся логіка.
вибір технологій та інструментів: основна технологія - PHP. Крім
того, для бази даних використовується MySQL.
Зручність використання: оскільки система повинна бути налаштована
індивідуально, основна параметрами зручності полягає у інтуїтивному інтерфейсі.
90
482 ЧДТУ 242060.015 1201 1
2.1 Моделювання предметної області
Моделювання предметної області - це процес створення абстрактного
представлення конкретної дипломної роботи, і моя мета - вивчити, проаналізувати
та спроектувати її. Цей процес використовується для кращого розуміння складних
систем, прийняття обґрунтованих рішень та покращення їх функціонування.
Ключові моменти:
область інтересів: визначає сфери діяльності, які необхідно
змоделювати;
моделювання предметної області: це абстрактне представлення домену,
яке може бути представлене діаграмами, формулами, комп'ютерними
програмами або пояснювальним текстом;
словник предметної області: набір термінів та визначень, які чітко
описують поняття, що використовуються в моделі;
елементи моделювання: до них відносяться об'єкти, атрибути,
відносини, події та правила;
область вивчення зовнішнього моделювання: це частина сфери
інтересів, на якій зосереджена модель.
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання: Система менеджменту контенту (CMS)
Модель предметної області
CMS - це кореневий вузол, який представляє основний елемент діаграми.
Користувач - користувачі взаємодіють з системою, можуть мати різні ролі
та виконувати функції системи:
взаємодія з системою: Користувачі використовують функції системи;
ролі: Ролі визначають, які дії можуть виконувати користувачі системи;
Пост – елемент сторінки, який надає контент:
типи контенту: візуальна та\або текстова контент;
текстовий контент: Повідомлення, що містять текст;
91
482 ЧДТУ 242060.015 1201 1
зображення: Повідомлення, що містять зображення;
інший контент: емодзі, смайлики, тощо.
Функції - функції використовуються для керування системою керування
контентом (CMS):
функції системи: функції, які користувачі використовують для взаємодії
з системою;
виконання функцій: процес виконання системою отриманих команд.
Нижче буде наведена сама діаграма предметної області Система
менеджменту контенту (CMS), з усіма копонентами і як вони пов'язані між собою.
Рисунок 2.1 – Діаграма предметної області CMS
92
482 ЧДТУ 242060.015 1201 1
Словник предметної області
Система менеджменту контенту (CMS)
це кореневий вузол, який представляє основний елемент діаграми;
взаємодіє з користувачами та виконує їхні команди;
Користувач (User)
користувачі взаємодіють з системою;
використовують функції системи для різних дій;
створюють текстові, зображувальні та інші види постів.
Пост (Post)
пости можуть бути різного типу і є основним засобом відтворення
інформації;
містять текстовий контент, зображення та інші типи (смайли, емодзі
тощо).
Сторінка (Page)
сторінка містять в собі контент із поста:
пост може буть різного типу і є основним засобом відтворення
інформації;
містять текстовий контент, зображення та інші типи (смайли, емодзі
тощо)
Функція (Function)
функції використовуються для керування системою;
інструкції, які користувачі надсилають для взаємодії з системою;
процес виконання системою отриманих команд.
93
482 ЧДТУ 242060.015 1201 1
Рисунок 2.2 – Словник предметної області
2.1.2 Елементи моделювання предметної області
При створенні моделі діаграми для спільного побудови діаграми
використовувалися наступні необхідні елементи і відносини UML.
Таблиця 2.1
Елементи моделювання
Елементи Їх Значення
Представляє роль, яку конкретний об'єкт (користувач,
адміністратор) відіграє у взаємодії з системою
Описує функції або послуги, які система надає суб'єктам
94
482 ЧДТУ 242060.015 1201 1
Продовження таблиця 2.1
Описує набір об'єктів, які мають спільні атрибути,
операції, відносини та семантику
Набір операцій, що визначають службу класу або
компонента
Модулі коду, що інкапсулюють логіку та дані
Фізичні елементи, присутні під час виконання для
реалізації розподіленої системи
Механізм групування елементів UML
Об'єкти можуть бути пов'язані з іншими елементами
діаграми UML, такими як класи, інтерфейси та інші
об'єкти, використовуючи різні типи відносин.
Таблиця 2.2
Зв’язки елементів моделювання
Елементи зв’язку Їх значення
Відношення - це взаємозв'язок між
екземплярами класу.
Сильна форма агрегації, де складові
частини існують виключно в контексті
цілого.
95
482 ЧДТУ 242060.015 1201 1
Продовження таблиця 2.2
Відношення "частина-ціле" між
класами
Відношення між загальним
суперкласом та більш
спеціалізованими підкласами
Відношення між класом або
компонентом та інтерфейсом, який
вони реалізують
Відношення, коли один елемент
залежить від іншого
Наступна діаграма класів показує структуру та основні компоненти системи
керування контентом, яка включає в себе наступні елементи:
Класи:
User
Атрибути:
id: int (унікальний ідентифікатор користувача);
username: varchar (ім'я користувача);
email: varchar (електрона пошта);
password: varchar (пароль);
active: boolean (чи є користувач активним);
added: datetime (коли був створений).
Методи:
users_add (params: id, username, email, password, active, added) (створює
користувача);
96
482 ЧДТУ 242060.015 1201 1
users_edit(params: username, email, password, active ) (дає можливість
редагувати окреми параметри користувача).
users_delete() (видаляє обліковий запис користувача)
Posts
Атрибути:
id: int (унікальний ідентифікатор повідомлення);
title: varchar (назва);
content: varchar (вміст повідомлення);
author: int (автор посту);
date: date (час редагування посту)
timestamp: datetime (час створення посту).
Методи:
add(params: title, content, date) (створює пост);
edit(params: title, content, date ) (редагує пост);
delete(): void (видаляє пост).
Page
Атрибути:
id: int (унікальний ідентифікатор повідомлення);
title: varchar (назва);
content: varchar (вміст повідомлення);
author: int (автор посту);
date: date (час редагування посту)
timestamp: datetime (час створення посту).
Методи:
відсутні
97
482 ЧДТУ 242060.015 1201 1
CMS
Атрибути:
$_SESSION[‘id’];
$_SESSION[‘message’];
Методи:
login (params: email, password) (вхід до облікового запису);
logout() (вихід з облікового запису);
secure() (перевіряє вхід в обліковий запис).
set_message () (додавання тексту до віконного повідомлення)
get_message () (вивід віконного повідомлення)
Database
Атрибути:
address: string(унікальний ідентифікатор сайту);
db_name: string (назва бази даних);
username: string (логін адміністратора);
password: string (пароль адміністратора);
Методи:
$connect = mysqli_connect() (підключення до бази даних);
98
482 ЧДТУ 242060.015 1201 1
Ця діаграма класів визначає структуру основних компонентів системи
керування контентом, таких як користувачі та пости. Це допомагає зрозуміти
відношення взаємозв'язки між різними компонентами та їх властивостями.
Рисунок 2.3 - UML-діаграма класів предметної області системи менеджменту
контентом (CMS)
99
482 ЧДТУ 242060.015 1201 1
2.1.3 Робоча область моделювання
Система керування контентом (CMS) являє собою набір програмних рішень,
які можуть спростити відтворення контенту на веб-ресурсі. Ці системи
допомагають ефективно управляти контентом.
Основні компоненти системи
Система керування контентом (CMS)
можливості системи: система може призводити перевірку користувачів
на наявність облікового запису адміністратора для впровадження мір
безпеки щодо доступу до панелі керування, займається обробкою
запитів до бази даних та відповідає за відтворення користувацького
контенту на веб-сторінці;
модерація: система надає можливість регулювати авторизованим особам
контент, що поступає до системи, редагувати чи видаляти небажані
повідомлення.
100
482 ЧДТУ 242060.015 1201 1
Рисунок 2.4 – Робоча область моделювання системи менеджменту контентом
(CMS)
CMS: Основний клас системи.
$_SESSION[‘message’] — це властивості для виводу повідомлень, що
відносяться до взаємодій із системою;
session_start() — методи для запуску системи.
AuthSystem: Клас для обробки команд, пов’язаних з авторизацією
користувачів та перевіркою наявності облікового запису.
username та password — поле логіну та паролю;
101
482 ЧДТУ 242060.015 1201 1
$_SESSION[‘id’] — витяг ідентифікатора користувача для перевірки
аутентифікації.
Database: Базовий клас для запитів до БД.
address, db_name, username, password — поля з інформацією для
авторизації у базі даних;
$connect = mysqli_conncet() — метод для підключення до бази даних.
PostsManager: Клас для управління відтвореним контентом.
id, title, content, author, date, added — поля з інформацією про пост;
posts_add(), posts_edit(), posts_delete() — методи для управління постами.
UserManager: Клас для управління обліковими записами користувачів.
id, username, email, password, active, added — список параметрів
користувача;
users_add(), users_edit() та users_delete() — методи длякерування
обліковими записами користувачів.
Pages: Клас для генерації сторінок з контентом із постів.
наслідує параметри від класу Posts;
не має своіх методів.
2.2 Формування та аналіз вимог
У цьому розділі описані вимоги, які необхідно визначити для розробки
програмного забезпечення, а також діаграми випадків використання для
візуалізації цих вимог.
По-перше, потрібно визначити основні та детальні вимоги. Основні вимоги
включають загальні цілі та функції, які програмне забезпечення повинно
виконувати. Наприклад, до них відносяться функції управління користувачами
(додавання та віидалення облікових записів), модерація контенту, а потім
уточнення цих вимог, щоб вони були чітко визначені і зрозумілі розробникам. Це
102
482 ЧДТУ 242060.015 1201 1
забезпечує належне виконання функції, враховуються обмеження і
встановлюються стандарти якості системи.
Потім розглядаються вимоги клієнтів та розробників. Вимоги замовника
відображають потреби та очікування щодо функціональності та якості
програмного забезпечення. Сюди входять прості вимоги до налаштування та
інтеграції, інтуїтивно зрозумілий інтерфейс, масштабованість та високий рівень
безпеки. Вимоги розробника включають технічні аспекти розробки та
впровадження системи, такі як використання сучасних середовищ, модульне
тестування, документація коду та використання систем контролю версій.
Ми також розглянемо функціональні та нефункціональні вимоги.
Функціональні вимоги визначають конкретні функції, які повинна надавати
система, такі як додавання, видалення чи зміна контенту на веб-сторінці.
Нефункціональні вимоги визначають характеристики системи, такі як
продуктивність, надійність, безпека та простота використання.
Щоб візуалізувати ці вимоги, можна використовувати діаграми
прецендентів використання, щоб допомогти проілюструвати взаємодію
користувача з системою за допомогою різних випадків використання. Це дозволяє
чітко визначити системні вимоги і зрозуміти, як різні частини програмного
забезпечення взаємодіють один з одним. Наприклад, діаграма прецендентів
використання системи керування контентом може показати, як адміністратори
можуть виконувати різні дії та як користувачі можуть отримувати різні послуги.
Ми можемо використовувати як текстові описи, так і візуалізацію,
103
482 ЧДТУ 242060.015 1201 1
використовуючи діаграми прецендентів використання, щоб краще зрозуміти всі
аспекти формування вимог до програмного забезпечення.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення.
Для утримання розробленної системи керування контентом не потрібно
потужного обладнання. Вимоги можуть змінюватися залежно від розміру сервера
та кількості користувачів, але в більшості випадків досить і скромної конфігурації.
Загальні рекомендації по обладнанню полягають в наступному:
Процесор:
сучасний двоядерний процесор, такий як Intel Core i3 або AMD Ryzen 3,
буде достатнім;
для більших серверів або більш ресурсномістких функцій, таких як
обробка мультимедіа, краще використання чотириядерних процесорів,
таких, як Intel Core i5 або AMD Ryzen 5.
Оперативна пам'ять (ОЗУ):
мінімум 2 Гігабайти ОЗУ, але рекомендується принаймні 4 Гігабайтів
для більш стабільної роботи;
для великих веб-сервісів з великим трафіком може знадобитися до 8
Гігабайтів ОЗУ або більше.
Накопичувач:
твердотільний накопичувач (SSD) об'ємом щонайменш 240 ГБ ;
якщо система зберігає великі обсяги даних, може знадобитися більший
накопичувач.
Мережевий інтерфейс:
стабільне Інтернет з’єднання швидкістю щонайменш 100 Мбіт/с.
Для користувачів, які хочуть взаємодіяти CMS, вимоги досить прості:
Внутрішній обліковий запис
104
482 ЧДТУ 242060.015 1201 1
користувачі повинні мати внутрішній обліковий запис. створення
облікового запису може призвести адміністратор сервісу.
Веб-Браузер
Для доступу до сервісу та взаємодії з ним користувачі можуть
використовувати принаймні один із наведених веб-браузерів:
Google Chrome;
Opera;
Mozila Firefox
Microsoft Edge.
Доступ до сервера
користувачі повинні мати доступ до мережі Інтернет або локального
сервера, на якому розміщена система.
Дозволи в системі
Усі облікові записи є адміністраторськими, тому кожен авторизований
користувач має повний обсяг дозволів
Знання інструментарію
система не потребує додаткових знань для її використання.
Підтримувані платформи
сервіс підтримується більшістю популярних веб-браузерів.
Первинні і детальні вимоги.
Первинні вимоги:
система повинна забезпечувати базові послуги управління та
відnворення контенту на веб ресурсі;
сільшість дій повинна виконуватись через графічний інтерфейс сервіса.
Детальні вимоги:
система повинна мати можливість створювати облікові записи
користувачів;
система повинна мати можливість редагувати облікові записи
користувачів;
105
482 ЧДТУ 242060.015 1201 1
система повинна мати можливість видаляти облікові записи
користувачів;
система повинна мати можливість керувати створеним користувачами
контентом та відтворювати його на головній сторінці;
система повинна мати можливість додавати створений користувачами
контент та відтворювати його на головній сторінці;
система повинна мати можливість редагувати створений користувачами
контент та відтворювати його на головній сторінці;
система повинна мати можливість редагувати створений користувачами
контент;
система повинна мати вбудований механізм обробки помилок та
непередбачених подій.
Вимоги замовника і розробника
Вимоги замовника (власника серверу):
простий та інтуїтивно зрозумілий графічний інтерфейс;
можливість виконувати базові дії для управління контентом;
Вимоги розробника:
використання актуальної версії PHP;
модульна архітектура для легкого розширення функціоналу;
підтримка розгортання на різних платформах (наприклад, локальний
сервер або хмарний сервіс).
Функціональні та нефункціональні вимоги
Функціональні вимоги:
створення/видалення користувачів;
редагування облікових записів;
створення\видалення контенту;
редагування створеного контенту;
повідомлення при глобальних подіях;
бази даних;
106
482 ЧДТУ 242060.015 1201 1
Нефункціональні вимоги:
час відгуку на команди не більше 2 секунд;
захист від зловмисного використання (наприклад, викрадення
інформації облікових записів);
висока доступність (цілодобовий режим роботи);
масштабованість для підтримки великої кількості функцій;
зрозумілий і структурований графічний інтерфейс.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Рисунок 2.5 - Діаграма прецедентів Адміністратора та Користувача
Таким чином, є 2 актори: користувач та адміністратор. Кожна окрема
функція (варіант використання) взаємодіє з системою управління контентом. Ось
список прецедентів та їх описи:
Прецеденти для "Адміністратор":
створення облікового запису – створення облікового запису в системі;
107
482 ЧДТУ 242060.015 1201 1
редагування облікового запису – редагування інформації облікового
запису;
видалення облікового запису – видалення облікового запису
адміністратора;
створення поста – створення поста на веб-ресурсі;
редагування поста – редагування змісту поста;
видалення поста -видалення поста з веб-ресурсу;
Прецеденти для "Користувач":
перегляд постів - перегляд змісту постів на веб-ресурсі;
Стрілки між акторами та прецедентами показують, хто ініціює виконання
кожного прецеденту, тим самим показує хто який має доступ до команд.
2.3 Проектування логічної структури програмного комплексу
На цьому етапі ви використовуєте діаграми класів та пакетів для розробки
логічної структури програмного пакету та візуалізації структури та компонентів
системи.
Спочатку потрібно створити діаграму КЛАСІВ програмного забезпечення.
Ця діаграма допомагає візуалізувати структуру системи, показуючи класи, їх
атрибути, методи і відносини між ними. Наприклад, визначте суперклас CMS для
системи управління вмістом. Цей клас включає методи запуску системи, обробки
запитів, управління обліковими записами користувачів, управління публікаціями
та управління вмістом. На додаток до основного класу створіть окремий клас для
кожної з цих функцій, які взаємодіють з CMS.
Потім створіть діаграму пакетів, яка допоможе вам організувати свої класи
в логічні групи або пакети. Це полегшує управління великими проектами та
покращує чіткість структури коду. У випадку системи управління вмістом класи
можуть використовуватися з такими параметрами, як управління користувачами
(клас, відповідальний за управління обліковими записами) та управління
електронною поштою (клас, відповідальний за управління вмістом), що дозволяє
організувати їх у пакети.
108
482 ЧДТУ 242060.015 1201 1
Таким чином, деки призначені для покращення логічної структури
програмних пакетів, структури та взаємозв'язків між класами, а також діаграм
класів, які візуалізують класи як логічні групи.
2.3.1 Діаграми класів
Нижче наведено діаграму класів для системи менеджменту контенту, де
кожен клас показує зв’язок з самою системою. Давайте детальніше розглянем
діаграму класів.
Рисунок 2.6 – Початкова діаграма класів
Ця діаграма є діаграмою класів для CMS, де кожен прямокутник
представляє клас. Давайте детальніше розглянемо кожен із цих класів:
1 CMS: це основний клас, який керує всіма функціями системи. Це
означає, що екземпляри цих класів включені як поля;
2 UserManager: клас, відповідальний за функцію управління обліковими
записами;
3 PostManager: клас, відповідальний за можливість управління постами та
їх контентом;
4 AuthSystem: клас, відповідальний за верифікаію та авторизацію
користувачів у системі;
5 PageCreator: клас, відповідальний за створення сторінки поста;
Розглянемо наповнену діаграму класів докладніше на наступній сторінці.
109
482 ЧДТУ 242060.015 1201 1
Ця діаграма класів для системи менеджменту контенту є детальним
поясненням кожного класу, його методів та атрибутів, а також їх
функціональності в рамках роботи бота. Розглянемо кожен клас детальніше:
CMS
Атрибути:
$_SESSION[‘id’] - токен для перевірки активної аутентифікованої сесії;
$_SESSION[‘message’] – запит для створення повідомлення при
глобальних діях;
Набір атрибутів таблиці users
Набір атрибутів таблиці posts
Методи:
Session_start() - запускає систему;
user_add() – створює обліковий запис;
user_edit() – редагує зміст обілкового запису;
user_delete() – видаляє обліковий запис;
post_add() – створює пост на веб-ресурсі;
post_edit() – редагує зміст посту на веб-ресурсі;
post_delete() – видаляє пост з веб-ресурсу;
secure() – перевіряє, чи є активна авторизована сесія;
login() – виконує авторизацію сесії;
loguоt() – виконує деавторизацію із сесії;
110
482 ЧДТУ 242060.015 1201 1
Це основний клас, який відповідає за керування системою менеджменту
контенту і координацію роботи інших класів. Його головні завдання включають
запуск системи, обробку запитів, керування користувачами (створювати,
редагувати та видаляти облікові записи) і модерувати контент.
Рисунок 2.7 – Повна діаграма класів
UserManager:
user_add() – створює обліковий запис;
user_edit() – редагує зміст облікового запису;
user_delete() – видаляє обліковий запис користувача.
PostManager:
post_add() – створює пост на веб-ресурсі;
111
482 ЧДТУ 242060.015 1201 1
post_edit() – редагує пост на веб-ресурсі;
post_delete() – видаляє пост з веб-ресурсу.
AuthSystem:
secure() – перевіряє на активну авторизовану сесію;
login() – виконує авторизацію до веб-ресурсу;
logout() – виконує деавторизацію з веб-ресурсу.
PageCreator:
create_page() – створює сторінку за даними посту.
Ця діаграма класів визначає структуру та взаємодію різних компонентів у
системі менеджменту контенту, забезпечуючи різноманітну функціональність,
таку як керування користувачами (створення, редагування та видалення облікових
записів), модерацію контенту, перевірку безпеки сесії.
2.3.2 Діаграми пакетів
На цій діаграмі показано взаємодію між методами функції UserManager і
його відносинами з базою даних. Коли користувач викликає один із трьох методів,
він обробляється системою через обробну команду і передається відповідному
обробнику запитів. Останній виконує функції, пов'язані з функцією управління
обліковими записами, і зберігає дані в базі даних.
Рисунок 2.8 – Діаграма пакетів для функції «UserManager»
112
482 ЧДТУ 242060.015 1201 1
На цій діаграмі представлені 4 основні пакети: користувач, бази даних,
функції, пости та їх взаємодія.
Давайте розглянемо можливі дії користувачів щодо записів постів в системі
менеджменту контенту:
створення нового запису посту: користувачі можуть створювати нові
пости, виконуючи певні дії в панелі інструментів та текстовому
редакторі, реалізованій у CMS. Функції, відповідальні за цей процес,
виконуються в пакеті функцій;
додатково до створення нових постів: користувачі можуть змінювати
надану інформацію, а саме заголовок, текст посту та дата поновлення.
Функція, що відповідають за цю функціональність, також реалізовані в
пакеті функцій;
на останок, через панель інструментів користувач може видалити запис
поста, присутній у системі.
Дана діаграма відображає структуру та взаємодію елементів у системі
менеджменту контенту, який має функціональність управління записами.
У пакеті Users міститься клас User, відповідальний за валідацію активної
сесії.
У пакеті CMS містяться набір методів класу PostManager.
У пакеті Database є клас PostsData, який відповідає за підключення до бази даних
для збереження зміню
Рисунок 2.9 – Діаграма пакетів для функції «PostsManager»
113
482 ЧДТУ 242060.015 1201 1
У пакеті CMS набір методів класу AuthSystem, який містить функції для
обробки запитів верифікації користувачів.
У взаємодії компонентів:
СМS виконує функцію login;
вкладена функція secure перевіряє, чи є на цей момент активна
верифікована сесія;
у випадку валідації сесії користувачу надається доступ до функціоналу
системи;
у випадку непровалідованої сесії система виконує вкладену функцію loguоt для її
закриття.
Рисунок 2.10 – Діаграма пакетів для функції «AuthSystem»
114
482 ЧДТУ 242060.015 1201 1
Рисунок 2.11 – Діаграма пакетів для функції «PageCreator»
2.4 Архітектурне проектування
У цьому розділі буде розглянут архітектурний дизайн програмних пакетів,
які використовують діаграми компонентів та діаграми розгортання для
візуалізації структури системи та розгортання на апаратному забезпеченні.
Спочатку створюється діаграму компонентів. Ця діаграма допомагає
візуалізувати основні програмні компоненти системи та їх взаємозв'язки. У
випадку з системою менеджменту контенту це будуть компоненти, відповідальні
за управління обліковими записами користувачів, управління контентними
записами, компонент генерації сторінок по контентним записам та
системиавтентифікації. Кожен з цих компонентів взаємодіє з основним
компонентом CMS.
Потім створюється схема розгортання, яка показує, як програмні
компоненти вбудовані в апаратне забезпечення. Це допоможе вам зрозуміти, як
розгорнути систему в реальному середовищі. Наприклад, ви можете розгорнути
розроблему систему менеджменту контенту на сервері з потрібними ресурсами
(процесор, пам'ять), забезпечити підключення до бази даних для зберігання
115
482 ЧДТУ 242060.015 1201 1
записів постів та даних користувачів.
Таким чином, у цьому розділі можна використовувати діаграми
компонентів для візуалізації структури системи та основних програмних
компонентів, а також для аналізу структури цих компонентів.
2.4.1 Діаграма компонентів
Діаграми компонентів - це дійсно важливий інструмент архітектурного
проектування програмних систем. Вони забезпечують візуальне представлення
системи на високому рівні, показуючи її компоненти, інтерфейси та залежності
між ними. Це дозволяє абстрагуватися від деталей реалізації та зосередитися на
загальній структурі та взаємодії між ключовими частинами системи.
Для створення діаграми компонентів виконуються наступні кроки:
1 Визначення системних компонентів: Компонент - це модуль, підсистема
або послуга, яка реалізує певну функцію або надає певну послугу. На
цьому етапі ідентифікуються та визначаються всі основні компоненти
системи.
2 Визначення інтерфейсів компонентів: Інтерфейс описує, яким чином
компонент взаємодіє та надає свої функції. Для кожного компонента
визначаються його інтерфейси, через які він буде взаємодіяти з іншими
частинами системи.
3 Визначення залежностей між компонентами: Залежності виникають,
коли один компонент використовує функціональність іншого
компонента. На цьому етапі визначаються всі залежності між
компонентами системи.
4 Візуальне представлення: Після визначення компонентів, інтерфейсів та
залежностей, вони візуально представляються на діаграмі. Компоненти
відображаються у вигляді прямокутників, інтерфейси - у вигляді кіл на
кордонах компонентів, а залежності - у вигляді стрілок між
компонентами, що вказують напрямок залежності.
116
482 ЧДТУ 242060.015 1201 1
Ця діаграма є архітектурним оглядом або діаграмою класів для системи
менеджменту контенту:
CMSystem: Це основний компонент, що представляє саму CMS;
Functions: Цей розділ містить різні класи команд, які може виконувати
бот, такі як UserManager, PostManager;
Utils: Цей розділ містить класи утиліт, зокрема PageCreator для генерації
наповнених сторінок по записам постів;
Events: Цей розділ містить класи слухачів подій, які обробляють різні
події у системі, зокрема AuthSystem.
На цій діаграмі показані взаємозв'язки і взаємодії між цими різними
компонентами, а також представлений огляд архітектури і функціональності.
Рисунок 2.12 – Діаграма компонентів
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання є ще одним артефактом архітектурного проектування,
який відображає розміщення компонентів програмної системи на фізичних вузлах
(серверах, пристроях) та їх взаємозв'язки. Вона допомагає візуалізувати топологію
системи та розподіл компонентів на апаратних засобах.
117
482 ЧДТУ 242060.015 1201 1
Для створення діаграми розгортання необхідно виконати наступні кроки:
1 Визначити апаратні вузли, на яких буде розгорнуто систему: Це можуть
бути сервери, пристрої, віртуальні машини тощо.
2 Визначити компоненти системи, які будуть розгорнуті на кожному вузлі.
3 Визначити взаємозв'язки між вузлами, такі як мережеві з'єднання або
протоколи взаємодії.
4 Візуалізувати вузли, компоненти та їх взаємозв'язки на діаграмі: Вузли
зображуються як вузли або пристрої, компоненти - як артефакти
всередині вузлів, а взаємозв'язки - як лінії між вузлами.
Нижче наведено діаграма розгортання CMS на апаратних засобах, яка
візуалізує архітектуру та його розміщення на апаратних засобах самої CMS.
Центральним компонентом є хостинг, на якому запущений сам код CMS..
Рисунок 2.13 – Діаграма розгортання CMS на апаратних засобах
Ця діаграма є діаграмою розгортання і відображає розміщення компонентів
CMS на апаратних засобах.
118
482 ЧДТУ 242060.015 1201 1
Діаграма містить наступні елементи:
Host: Це вузол, на якому розгорнуто основний компонент CMS, званий
"CMS". Цей компонент містить у собі підкомпоненти, які представляють
різні команди та функції бота, такі як UserManager, PostManager,
AuthSystem та PageCreator.
Ця діаграма розгортання візуалізує фізичне розміщення компонентів CMS
та їх взаємозв'язки, що допомагає краще зрозуміти топологію системи та вимоги
до інфраструктури. Вона також дає уявлення про різноманітність функцій та
команд, які реалізовані в CMS.
2.5 Моделювання поведінки системи
У цьому розділі ми розглянемо використання різних типів діаграм для
моделювання поведінки системи та візуалізації її взаємодії і функціональності.
По-перше, створимо діаграму дій (activity diagram), яка допоможе
візуалізувати робочий процес та дії в системі. На цій діаграмі показано, як
працюють ключові функції CMS, такі як обробка запитів, зміни даних про
користувачів, автентифікація та інші дії. Діаграми дій допоможуть вам зрозуміти
загальну послідовність дій і процесів, що відбуваються у вашій системі. Вони
особливо корисні для моделювання складних бізнес-процесів або алгоритмів з
розгалуженнями та циклами.
Далі діаграма послідовності покаже взаємодію об'єктів при виконанні
функцій, будь як пов’язаних зі змінами у базах даних. Вона візуалізує потік
повідомлень та виклики між об'єктами, що допомагає моделювати складні
сценарії взаємодії.
Діаграма взаємодії схожа, але більше фокусується на структурі зв'язків між
об'єктами. Вона ілюструє, як об'єкти обмінюються повідомленнями для
виконання функцій, наприклад, запуску лотереї. Корисна для високорівневого
моделювання взаємодії компонентів.
119
482 ЧДТУ 242060.015 1201 1
Діаграми станів моделюють різні стани об'єктів та події, що змінюють ці
стани. Вони візуалізують життєвий цикл складних об'єктів, як сесії користувачів
чи лотереї.
Нарешті, діаграми компонентів та розгортання візуалізують високорівневу
архітектуру, її компоненти, відносини та фізичне розгортання на різних вузлах.
Ці діаграми - корисні інструменти для аналізу вимог, проєктування та
документування архітектури і поведінки систем. Вони роблять складні системи
зрозумілішими та полегшують комунікацію в проєкті
2.5.1 Діаграма діяльності
На цьому рисунку показано простий потік управління командами, які
можуть мати атрибут @is_auth. Така функція гарантує несанкціоноване створення
запитів від звичайних користувачів. Спочатку CMS отримує повідомлення, що
містить команду. Після чого йде перевірка, чи має користувач дозвіл на
використання тої чи іншої функції панелі інструментів. Якщо є, надходить
підтвердження виконання команди, після чого запит набуде чинності. Якщо
користувач не має дозволів, буде надіслано повідомлення про те, що користувач
не має відповідних дозволів на використання команди.
Якщо використовувати команду, в якій вказаний аргумент @is_auth(),
користувачу знадобиться підвищений рівень доступу. Звичайні користувачі не
можуть використовувати його для доступу до функціоналу керування, вони
повинні мати обліковий запис з відповідними дозволами.
120
482 ЧДТУ 242060.015 1201 1
Рисунок 2.14 – Діаграма діяльності «Перевірка доступу до функцій»
2.5.2 Діаграма послідовності
На цій діаграмі відображається взаємодія між об'єктами User, CMS та
UserManager при виконанні команди "user_add()".
користувач створює запит з командою;
CMS викликає метод secure() для первірки авторизації;
UserManager викликає його метод user_add() при проходжені валідацції
авторизації;
залежно від результату перевірки прав та наявності аргументів,
виконується або не виконується створення облікового запису
користувача, і відправляється відповідне повідомлення;
якщо користувач не має прав, відправляється повідомлення про
відсутність прав.
121
482 ЧДТУ 242060.015 1201 1
Рисунок 2.15 – Діаграма послідовності роботи авторизованого користувача
для створення нового облікового запису у системі
2.5.3 Діаграма комунікації
На цій діаграмі комунікації ми бачимо взаємодію між об'єктами User, CMS
та UserManager при виконанні команди "user_edit()".
user відправляє запит до CMS;
CMS перевіряє наявність прав у User;
при наявності прав та присутності аргументів UserManager виконує
запит та передає інформацію до CMS;
CMS відправляє повідомлення з відповіддю про виконання функції;
при відсутності прав або відсутності аргументів CMS відправляє
повідомлення про неможливість виконання запиту;
122
482 ЧДТУ 242060.015 1201 1
Рисунок 2.16 – Діаграма комунікації роботи Користувача
2.5.4 Діаграма скінченного автомату
Ця діаграма є діаграмою станів, яка візуалізує різні стани, у яких може
перебувати система, в цьому випадку - CMS-система для конструювання
простих сайтiв, а також переходи між цими станами, викликані певними подіями
або діями.
Діаграма містить стани: Idle(Бездіяльність), ProcessingEvent(Обробка
повідомлення), ExecutingFunction(Виконання команди),
RespondToFunction(Відповідь на команду), WaitingForEvent(Очікування).
123
482 ЧДТУ 242060.015 1201 1
Рисунок 2.17 – Діаграма скінченого автомату
Переходи між станами відбуваються за такими подіями:
"отримано повідомлення" переводить бота зі стану "бездіяльність" у
"обробку повідомлення";
"розпізнано команду" переводить зі стану "обробка повідомлення" у
"виконання команди";
"не команда" переводить зі стану "обробка повідомлення" в "очікування
повідомлення";
"відповідь надіслана" переводить зі стану "відповідь на команду" назад
у "бездіяльність";
"вихід" переводить зі стану "очікування повідомлення" назад у
"бездіяльність".
124
482 ЧДТУ 242060.015 1201 1
ВИСНОВОК ДО РОЗДІЛУ 2
Ретельне дотримання етапів в цьому описаному розділі, сприятиме
систематичному та структурованому підходу до розробки програмного
забезпечення. Це дозволяє уникнути помилок і невідповідностей на ранніх етапах
проектування і знижує витрати на виправлення недоліків в подальшій розробці.
жовтні дек. Крім того, використання стандартизованих методів моделювання та
діаграм UML сприяє кращому спілкуванню між учасниками проекту та полегшує
подальше обслуговування та заміну програмного забезпечення.
125
482 ЧДТУ 242060.015 1201 1
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
Цей розділ описує процес розробки та тестування програмних пакетів,
включаючи вибір інструментів реалізації, визначення структурних та логічних
схем системи, розробку баз даних, інтерфейсів користувача та програмних
компонентів. Також описані різні типи випробувань, такі як модульні, інтегровані,
системні та приймальні випробування. Приклад реалізованого програмного
пакету наведено в кінці розділу.
3.1 Розробка програмного комплексу
У цих розділах розглядається процес розробки CMS-системи для
конструювання простих сайтiв. По-перше, вибір мови програмування,
середовища розробки, бібліотек та інших інструментів, що використовуються для
реалізації проекту, є правильним. У ньому описуються переваги і недоліки
обраних варіантів, а також відповідність вимогам проекту. Потім ми
представляємо структурну (функціональну) схему програмного дека і
візуалізуємо його основні компоненти і взаємозв'язки між ними. Він описує
призначення кожного компонента та його роль у загальній архітектурі системи.
Потім представлена логічна схема системи, що показує потік даних та
алгоритми, що використовуються в програмному пакеті. Він описує, як дані
переміщуються по системі, як вони обробляються та перетворюються на корисну
інформацію. Потім ми розглянемо процес розробки баз даних для CMS-система
для конструювання простих сайтiв. Структура бази даних- це таблиці, поля, типи
даних, ключі та відносини між таблицями. Також приділяється увага питанням
безпеки та продуктивності бази даних.
Наступним кроком буде визначення процесу розробки інтерфейсу
користувача для CMS-система для конструювання простих сайтiв. Враховується
дизайн інтерфейсу, його елементи, навігація, функціональність і простота
використання. Також буде приділено увагу доступності та адаптивності
інтерфейсів для різних пристроїв і платформ. Нарешті, наводиться докладний
126
482 ЧДТУ 242060.015 1201 1
опис розробки основних програмних компонентів або модулів програмного
пакету. Кожен компонент описує його функціональність, використовувані
алгоритми та функціональність програми, а також інтеграцію з іншими частинами
системи.
3.1.1 Обґрунтування вибору засобів реалізації
Мова програмування PHP була обрана для розробки CMS-система для
конструювання простих сайтiв.
PHP — мова програмування загального призначення, що використовується
для розробки Web-орієнтованого програмного забезпечення. На сьогодні PHP є
лідером серед мов програмування, що використовуються для створення
динамічних Web-сайтів. PHP використовується для розробки проектів різних
масштабів — від найпростіших сайтів до великих багатофункціональних Web-
сервісів.
Ця мова програмування надає наступні функції:
підтримується за замовчуванням майже будь-яким сучасним хостинг-
провайдером, що є запорукою доступної вартості серверів для додатку
або сайту, написаного цією мовою;
висока швидкість роботи. Останні версії PHP вражають швидкістю
відпрацювання скриптів у порівнянні з іншими мовами програмування;
з використанням PHP створено велику кількість систем управління
контентом (CMS) для сайтів, таких як WordPress, Joomla, Drupal —
системи загального призначення, OpenCart, Magento — системи для
управління Інтернет-магазинами. Це лише найбільш розповсюджені та
безкоштовні CMS, їх реальна кількість — безкоштовних та платних —
дуже велика.
MySQL
MySQL — характеризується великою швидкістю, стійкістю і простотою
використання, була розроблена для підвищення швидкодії обробки великих баз
даних. Вона має наступні переваги:
127
482 ЧДТУ 242060.015 1201 1
він не вимагає окремого серверного процесу, а файли бази даних
зберігаються у файловій системі;
кроссплатформенний може працювати в різних операційних системах
висока продуктивність для невеликих обсягів даних;
MySQL — вільна система керування реляційними базами даних. Ця система
керування базами даних (СКБД) з відкритим кодом була створена як альтернатива
комерційним системам.
3.1.2 Опис структурної (функціональної) схеми
Файлова система CMS-система для конструювання простих сайтiв
[CMS]
├── css/
│ ├── mdb.dark.min.css
│ ├── mdb.dark.min.css.map
│ ├── mdb.dark.rtl.min.css
│ ├── mdb.min.css
│ ├── mdb.min.css.map
│ └── mdb.rtl.min.css
├── includes/
│ ├── config.inc.php
│ ├── database.inc.php
│ ├── footer.inc.php
│ ├── functions.inc.php
│ └── header.inc.php
├── js/
│ ├── tinymce/
│ ├── mdb.es.min.js
│ ├── mdb.es.min.js.map
│ ├── mdb.umd.min.js
│ └── mdb.umd.min.js.map
├── upload/
128
482 ЧДТУ 242060.015 1201 1
│ ├── 213.jpg
│ └── Figure_1.png
├── dashboard.php
├── index.php
├── login.php
├── logout.php
├── post.php
├── posts_add.php
├── posts_edit.php
├── posts.php
├── upload.php
├── users_add.php
├── users_edit.php
└── users.php
Ця файлова система складається з наступних елементів:
css / - ця папка містить набір бібліотек стилів для графічного інтерфейсу
системи;
includes / - ця папка містить окремі модулі, які представляють основні
функції та елементи системи.;
js / - ця папка містить файли з виконувальним кодом текстового
редактору;
upload/ Ця папка містить зображення, які ви можете переглядати в
певному режимі;
129
482 ЧДТУ 242060.015 1201 1
3.1.3 Опис логічної схеми системи
Рисунок 3.1 – Опис логічної схеми системи
CMS
CMS -це програма, яка надає функціонал для менеджменту контенку. CMS
можуть використовуватися для створення простих вебсайтів.
Сервер баз даних
Сервер баз даних - це тип комп'ютера, який використовується для зберігання
та управління даними. Сервер баз даних зазвичай використовується самою CMS
для зберігання інформації користувача та постів.
3.1.4 Розробка бази даних
База даних MySQL використовується для зберігання різної інформації про
користувачів та створений ними контент в рамках CMS:
Схема бази даних включає такі основні таблиці:
1 users (користувачі):
id (номер запису);
username (ім’я);
email (електрона пошта);
password (пароль);
active (ідентифікатор активності);
added (дата створення запису).
130
482 ЧДТУ 242060.015 1201 1
Рисунок 3.2 – База даних «Users»
2 posts (пости):
user_id (ідентифікатор користувача);
username (ім'я користувача);
money (гроші);
position (позиція).
Рисунок 3.3 – База даних «Posts»
131
482 ЧДТУ 242060.015 1201 1
Рисунок 3.4 – Структура бази даних
На цій діаграмі показана структура бази даних, що складається з декількох
таблиць. Центральна таблиця – це "users", яка зберігає інформацію про
користувачів. Друга таблиця зберігає додаткову інформацію про пости у системі.
1 "users" - це таблиця у базі даних яка призначена для зберігання інформації
про користувачів;
2 "posts" - це таблиця, яка використовується для зберігання інформації постів,
яка включає назву посту, його контент, авторство, дата редактування та дата
створення.
3.1.5 Розробка інтерфейсу користувача
Інтерфейс користувача CMS-система для конструювання простих сайтiв
реалізований через текстовий канал, використовуючи команди та відповіді бота.
Важливо надати чіткий та інтуїтивно зрозумілий синтаксис команд, а також чітку
та інформативну відповідь.
Особливості інтерфейсу:
132
482 ЧДТУ 242060.015 1201 1
Користувацький інтерфейс
Рисунок 3.5 – Головна сторінка
Рисунок 3.6 – Сторінка авторизації
133
482 ЧДТУ 242060.015 1201 1
Рисунок 3.7 – Сторінка панелі інструментів
Рисунок 3.8 – Сторінка менеджменту користувачів
134
482 ЧДТУ 242060.015 1201 1
Рисунок 3.9 – Сторінка з інструментом додавання нового облікового запису
користувача
Рисунок 3.10 – Сторінка редагування інформації о користувачеві
135
482 ЧДТУ 242060.015 1201 1
Рисунок 3.11 – Сторінка менеджера постів
Рисунок 3.12 – Сторінка створення нового поста
136
482 ЧДТУ 242060.015 1201 1
Рисунок 3.13 – Сторінка поста з демонстрацією можливостей редактора
3.1.6 Опис розробки програмних компонентів
Основні програмні компоненти CMS-системи для конструювання простих
сайтiв:
Ініціалізація:
завантаження налаштувань;
ініціалізація системи на фізичній обчислювальній машині;
встановлення базових подій (готовність, помилки).
Обробники команд:
імпорт доступних команд;
парсинг вхідних повідомлень на предмет команд;
перевірка прав доступу користувача;
виклик відповідного обробника команди.
Обробники подій:
повідомлення (виділення повідомлень);
створення/видалення користувацьких облікових записів/постів (для
модерації);
редагування користувацьких облікових записів/постів;
137
482 ЧДТУ 242060.015 1201 1
База даних MySQL:
ініціалізація з'єднання з БД MySQL;
запити читання та запису даних;
обробка транзакцій та міграцій.
Утиліти:
пошук/форматування даних (Пости тощо).
3.2 Тестування системи
У цьому розділі описані різні типи тестів, що виконуються під час
розробки програмного комплексу. По-перше, розглянемо модульні тести, які
перевіряють правильність роботи окремих модулів або компонентів
системи. Він пояснює, які тести використовувались, як вони проводилися та
які результати були отримані. Нижче описані інтеграційні тести, які
перевіряють взаємодію між різними модулями або компонентами системи.
Він пояснює, як організовуються інтеграційні тести та які підходи та
інструменти використовуються для забезпечення належної взаємодії
компонентів.
Наступним кроком є опис системного тесту, який перевіряє роботу
всієї системи, включаючи її функціональність, продуктивність та
стабільність. Він пояснює, як організовані системні тести, які тестові
випадки та методи використовуються та які результати були отримані. Він
також описує процес приймальних випробувань, проведених замовником
або користувачем, щоб переконатися, що система відповідає вимогам та
специфікаціям.
3.2.1 Модульне тестування
Мова програмування PHP були використані для створення «CMS-системи
для конструювання простих сайтiв».
Функціонал який був створений для кваліфікаційної роботи бакалавра:
UserManagement;
138
482 ЧДТУ 242060.015 1201 1
PostManagement;
Login-Logout;
Таблиця 3.1
Модульне тестування
Модулі Функції Результат
UserManagement user_add, user_edit та Ця функція працює належним
user_delete чином і зберігає необхідну
інформацію в базі даних
PostManagement post_add, post_edit та Ця функція працює належним
post_delete чином і зберігає необхідну
інформацію в базі даних
Login-Logout login та logout Ця функція працює належним
чином
PageCreator page_create Ця функція працює належним
чином
Усі необхідні функції успішно пройшли тести та продемонстрували
очікуваний результат.
3.2.2 Інтеграційне тестування
Інтеграційне тестування перевірятиме взаємодію між різними
компонентами системи та базою даних.
Тестування взаємодії команд із базою даних включає:
Перевірку правильного збереження та оновлення інформації про
користувачів після виконання команд: /ban, /unban, /setbirthday, !earn, !work,
!crime, !balance, !leaderboard (!top), !gift, !bonus, !shop, !buy, !drop, !giveaway,
/kick, /mute, /unmute;
139
482 ЧДТУ 242060.015 1201 1
Тестування правильного зчитування інформації для користувачів із бази
даних при виконанні команд: !xp, !leaderboard.
Таблиця 3.2
Інтеграційне тестування
Команди Результати
user_add Команда працює належним чином, та правильно заносить інформацію
в базу даних
user_edit Команда працює належним чином, та видаляє інформацію з бази даних
user_delete Команда працює належним чином, та правильно заносить інформацію
в базу даних
post_add Команда працює належним чином, та правильно заносить інформацію
в базу даних
post_edit Команда працює належним чином, та правильно заносить інформацію
в базу даних
post_delete Команда працює належним чином, та правильно заносить інформацію
в базу даних
login Команда працює належним чином
logout Команда працює належним чином
page_create Команда працює належним чином
Усі команди, що працюють з базою даних, продемонстрували результати,
необхідні для зберігання та читання інформації як всередині, так і за межами бази
даних.
3.2.3 Системне тестування
Системне тестування перевіряє програмне забезпечення на повністю
інтегрованому системному рівні, щоб переконатися, що всі функціональні та
нефункціональні вимоги виконані, тобто внутрішня структура програми не
враховується, а орієнтована лише на зовнішню роботу.
140
482 ЧДТУ 242060.015 1201 1
Таблиця 3.4
Системне тестування
Системні функція Протестовано Працює Опис дії
UserManagement Так Так Менеджмент облікових записів
користувачів.
PostManagement Так Так Менеджмент записів постів
Login-Logout Так Так Авторизація та деавторизація у
системі
PageCreator Так Так Генерація сторінки поста
Всі функції пройшли системне тестування. Функція відповідає всім
функціональним і нефункціональним вимогам.
3.2.4 Приймальне тестування
Мета: Перевірка функціональності системи з точки зору звичайного
користувача та виявлення недоліків або покращень.
Перевірка основних команд
команда user_add: користувач успішно створений;
команда user_edit: користувач успішно відредагований;
команда user_delete: користувач успішно видален;
команди post_add: пост створений успішно;
команда post_edit: пост відредагован успішно;
команда post_delete: пост видален успішно;
команда login: користувач проходить авторизацію успішно;
команда logout: деавторизація проходить успішно;
команда page_create: сторінка генерується без помилок.
Перевірка нефункціональних вимог
швидкість реакції: команди виконуються без значних затримок;
стабільність: система працює без збоїв протягом тестового періоду;
інтуїтивність інтерфейсу: користувачі легко освоюють використання.
141
482 ЧДТУ 242060.015 1201 1
Зворотній зв'язок та пропозиції
Загальна оцінка:
Система працює стабільно і виконує всі основні функції відповідно до
вимог. Але з точки зору звичайного користувача додаткових функцій недостатньо.
Пропонується додати наступні функції:
коментарі: інтеграція системи коментарів під постами;
оцінки: можливість можливість користувачам оцуінювати той чи інший
пост;
покращення графічного інтефейсу: загальні поліпшення можливостей
графічного інтерфейсу та його читання.
Система потребує деяких удосконалень, щоб покращити взаємодію з
користувачем та підвищити рівень взаємодії з користувачем та розваг.
3.3 Приклади впровадженого програмного комплексу
Звичайно, головною метою залишається розкрити в повній межі дану
кваліфікаційну роботу бакалавра, але було обдумано, що CMS-системи для
конструювання простих сайтiв необхідно розширити функціонал та можливості.
Це значно підвищить автоматизацію програмних продуктів. Запровадження
автоматизованих систем, додавання нових модулів та створення інтерактивних
взаємодій може покращити досвід взаємодії з цим CMS-системи для
конструювання простих сайтiв та зробити його більш захопливим і корисним для
користувачів.
Іншими словами, пропонується розширити функціональність бота за
рахунок автоматизації певних процесів, інтеграції додаткових модулів та
розробки інтерактивних компонентів. Це дозволить зробити взаємодію з
системою більш різноманітною, цікавою та залучити більше користувачів..
Запуск CMS-системи для конструювання простих сайтiв на хостингу для
забезпечення 24-годинної доступності є важливим кроком у розвитку поточного
проекту. Однак реалізація цієї ідеї вимагатиме відповідних фінансових витрат на
послуги хостингу.
142
482 ЧДТУ 242060.015 1201 1
ВИСНОВОК ДО РОЗДІЛУ 3
У цьому розділі детально описуються практичні аспекти розробки та
тестування програмного забезпечення. Розглядалися питання, пов'язані з вибором
інструментів реалізації, структурним і логічним проектуванням системи,
розробкою баз даних і користувальницьких інтерфейсів, а також розробкою
окремих програмних компонентів. Особлива увага приділяється різним типам
тестування, особливо модульним, інтегрованим, системним і приймальним
випробуванням, які є невід'ємною частиною забезпечення якості програмного
забезпечення.
143
482 ЧДТУ 242060.015 1201 1
ВИСНОВКИ
В результаті цієї кваліфікаційної роботи бакалавра, було досліджено та
створення CMS-система для конструювання простих сайтiв. Початковою метою
було розробити систему, яка надає можливість створювати прості веб сайти.
Розроблена система успішно виконує всі поставлені завдання. Модульна
архітектура дозволила створити гнучку і легко масштабовану систему, яка може
бути адаптована до різних вимог. Простий інтерфейс спрощує управління
функціями системи без необхідності навчання складним командам, доступним
для всіх користувачів.
Базовий спектр функцій дозволив нам створити простий інструмент, який
значно полегшує можливості адміністраторів простих веб-ресурсів. Гнучкість і
налаштованість системи дозволяють їй адаптуватися до конкретних потреб
окремого замовника, що робить її більш гнучким у використанні.
Оптимізація для ефективного використання ресурсів сервера забезпечує
стабільну роботу навіть при високих навантаженнях, що важливо для підтримки
продуктивності і зниження вартості технічних ресурсів. Розроблена система
також забезпечує достатньо надійне зберігання інформації користувача за
допомогою створеної бази даних. Механізми, що застосовуються для
забезпечення безпеки, узгодженості і точності операцій, забезпечують стабільну і
надійну роботу системи.
В цілому, CMS-система для конструювання простих сайтiв, досягла своєї
мети, забезпечивши централізоване управління та наданеня базовогно
функціоналу. Ця система підвищує ефективність. Використання такої системи
може значно поліпшити взаємодію з веб-ресурсом і забезпечити зручний і
функціональний інтерфейс для користувачів і адміністраторів.
144
482 ЧДТУ 242060.015 1201 1
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Процес моделювання предметної області. Гайд для бізнес-аналітиків
https://dou.ua/forums/topic/42366/
2 Предметна область, моделювання предметної області
https://studfile.net/preview/5474325/page:2/
3 Моделювання даних
https://uk.wikipedia.org/wiki/Моделювання_даних
4 Вимоги до програмного забезпечення
https://uk.wikipedia.org/ wiki/Вимоги_до_програмного_забезпечення
5 Ключові методології розробки програмного забезпечення: робота команди
зсередини
https://wezom.com.ua/ua/blog/metodologija-razrabotki-programmnogo-obespechenija
6 Функціональні вимоги
https://uk.wikipedia.org/wiki/Функціональні_ вимоги
7 Що таке функціональні вимоги: приклади, визначення, повний посібник
https://visuresolutions.com/uk/blog/functional-requirements/
8 Аналіз вимог до програмного забезпечення
http://dspace.wunu.edu.ua/retrieve/14135/FCIT_kKN_sPZS_dAVPZ_%20LEC.pdf
9 PlantUML is a highly versatile tool that facilitates the rapid and straightforward
creation of a wide array of diagrams.
https://plantuml.com/
10 Розробка ER–моделі предметної області
https://web.posibnyky.vntu.edu.ua/fitki/10savchuk_organizaciya_bazdanih_znan/gl_2
6.html
11 Mind Mapping
https://www.adelaide.edu.au/writingcentre/sites/default/files/docs/learningguide-
mindmapping.pdf
12 Діаграма прецедентів
145
482 ЧДТУ 242060.015 1201 1
https://uk.wikipedia.org/wiki/Діаграма% прецендентів
13 Діаграма класів UML
https://www.mindonmap.com/uk/blog/what-is-uml-class-diagram/
14 Діаграма пакетів
https://www.wikiwand.com/uk/Діаграма_пакетів
15 Діаграма компонентів
https://www.mindonmap.com/uk/blog/uml-component-diagram/
16 Unified Modeling Language
https://uk.wikipedia.org/wiki/Unified_Modeling_Language#Представлення_компоне
нтів
17 Розгортання програмного забезпечення
https://uk.wikipedia.org/ wiki/Розгортання_програмного_забезпечення
18 Що таке deploy і навіщо він потрібен
https://foxminded.ua/deploi-tse/
19 Що таке деплой та для чого він потрібен
https://highload.today/uk/shho-take-deploj-ta-dlya-chogo-vin-potriben/
20 Моделювання поведінки системи
https://web.posibnyky.vntu.edu.ua/fksa/4bevz_proektuvannya_programnyh_zasobiv_s
ystem_upravlinnya/53-9.htm
21 Діаграма діяльності в UML: символ, компоненти та приклад
https://www.guru99.com/uk/uml-activity-diagram.html
22 Діаграма станів (UML)
https://uk.wikipedia.org/wiki/Діаграма_станів_(UML)
23 Автомати та їх різновиди
https://studfile.net/preview/9305984/page:9/
24 Діаграма послідовності
https://uk.wikipedia.org/uk.wikipedia.org/ wiki/Діаграма_послідовності
25 Проєктування програмного забезпечення засобами UML
http://mmsa.kpi.ua/sites/default/files/disciplines/Розробка%20і%20тестування
%20програм/didkovska_m_v_testing_lecture_6.pdf
146
482 ЧДТУ 242060.015 1201 1
26 Діаграма послідовності
https://dou.ua/forums/topic/40575/
27 Діаграма послідовності (Sequence Diagrams)
https://www.maxzosim.com/ sequence-diagrams/
28 Діаграма комунікації
https://uk.wikipedia.org/wiki/Діаграма_комунікації
29 What is Communication Diagram?
https://www.visual-paradigm.com/ guide/uml-unified-modeling-language/what-is-
communication-diagram/
30 Керування вимогами в розробці програмного забезпечення:
https://requirements.com/Content/Topics/Requirements-Management.aspx
31 Вимоги до програмного забезпечення: практичний посібник:
https://www.atlassian.com/software/jira/guides/create/requirements-gathering
32 Основи моделювання даних:
https://www.lucidchart.com/pages/er-diagrams
33 Введення до діаграм діяльності в UML:
https://creately.com/ diagram/ex ample/jn7xov92/activity-diagram-for-order-
management-system
34 Діаграма класів у UML: приклади та пояснення:
https://sparxsystems.com/resources/tutorials/uml2/class-diagram.html
35 Як створювати діаграми послідовності:
https://www.tutorialspoint.co m/uml/uml_sequence_diagram.htm
147
482 ЧДТУ 242060.015 1201 1
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2024 р.
CMS-система для конструювання простих сайтiв
Специфікація
482 ЧДТУ 242060 015
Листів 2
Розробник ________________ Строганов Я.Р.
Керівник ________________ Заспа Г.О.
2024
148
482 ЧДТУ 242060.015 1201 1
Позначення Найменування Примітка
482 ЧДТУ 242060 12 01 Лістинг програм
482 ЧДТУ 242060 34 01 Інструкція користувача
482 ЧДТУ 242060 90 01 Графічні матеріали
149
482 ЧДТУ 242060.015 1201 1
ДОДАТОК Б
CMS-система для конструювання простих сайтiв
Лістинг програм
482 ЧДТУ 242234 001 1201
Листів 14
Розробник ________________ Строганов Я.Р.
2024
150
482 ЧДТУ 242060.015 1201 1
Відслідковування положення сокету для рук
#include "Components/SceneComponent.h"
#include "Engine/OverlapResult.h"
#include "Engine/Level.h"
#include "EngineStats.h"
#include "Components/StaticMeshComponent.h"
#include "AI/NavigationSystemBase.h"
#include "Engine/MapBuildDataRegistry.h"
#include "GameFramework/PhysicsVolume.h"
#include "Components/BillboardComponent.h"
#include "Engine/Texture2D.h"
#include "ComponentReregisterContext.h"
#include "Physics/Experimental/PhysScene_Chaos.h"
#include "UnrealEngine.h"
#include "Logging/MessageLog.h"
#include "Net/UnrealNetwork.h"
#include "ComponentUtils.h"
#include "Framework/Notifications/NotificationManager.h"
#include "UObject/UObjectAnnotation.h"
#include "Widgets/Notifications/SNotificationList.h"
#include "UObject/UObjectThreadContext.h"
#include "UObject/UE5PrivateFrostyStreamObjectVersion.h"
#include "Engine/SCS_Node.h"
#include "DeviceProfiles/DeviceProfileManager.h"
#include "Interfaces/ITargetPlatform.h"
#include "DeviceProfiles/DeviceProfile.h"
#include "Net/Core/PushModel/PushModel.h"
#include "UObject/Class.h"
#include "UObject/ICookInfo.h"
#include "Misc/DataValidation.h"
#include "Misc/EnumRange.h"
#define LOCTEXT_NAMESPACE "SceneComponent"
namespace SceneComponentStatics
{
static const FName DefaultSceneRootVariableName(TEXT("DefaultSceneRoot"));
static const FName MobilityName(TEXT("Mobility"));
static const FText MobilityWarnText = LOCTEXT("InvalidMove", "move");
static const FName PhysicsVolumeTraceName(TEXT("PhysicsVolumeTrace"));
}
namespace SceneComponentCVars
{
bool bCheckRootComponentReplicationOnAttachedChildren = true;
static FAutoConsoleVariableRef
CVarCheckRootComponentReplicationOnAttachedChildren(
TEXT("s.CheckRootComponentReplicationOnAttachedChildren"),
bCheckRootComponentReplicationOnAttachedChildren,
TEXT("Scene Component OnRep_AttachedChildren:\n")
TEXT("false: fix up any children that are missing the parent, true:
fixes up all children except non-replicated root components (default)"),
ECVF_Default);
}
DEFINE_LOG_CATEGORY_STATIC(LogSceneComponent, Log, All);
DECLARE_CYCLE_STAT(TEXT("UpdateComponentToWorld"),
151
482 ЧДТУ. 242234.001 1201 2
#if WITH_EDITOR
/**
* A static helper function used meant as the default for determining if a
* component's Mobility should be overridden.
*
* @param CurrentMobility The component's current Mobility setting
* @param NewMobility The proposed new Mobility for the component in
question
* @return True if the two mobilities are not equal (false if they are equal)
*/
static bool AreMobilitiesDifferent(EComponentMobility::Type CurrentMobility,
EComponentMobility::Type NewMobility)
{
return CurrentMobility != NewMobility;
}
DECLARE_DELEGATE_RetVal_OneParam(bool, FMobilityQueryDelegate,
EComponentMobility::Type);
/**
* A static helper function that recursively alters the Mobility property for all
* sub-components (descending from the specified USceneComponent)
*
* @param SceneComponentObject The component whose sub-components you
want to alter
* @param NewMobilityType The Mobility type you want to switch
sub-components over to
* @param ShouldOverrideMobility A delegate used to determine if a sub-
component's Mobility should be overridden
* (if left unset it will
default to the AreMobilitiesDifferent() function)
* @return The number of descendants that had their mobility altered.
*/
static int32 SetDescendantMobility(USceneComponent const* SceneComponentObject,
EComponentMobility::Type NewMobilityType, FMobilityQueryDelegate
ShouldOverrideMobility = FMobilityQueryDelegate())
{
if (!ensure(SceneComponentObject != nullptr))
{
return 0;
}
TArray<USceneComponent*> AttachedChildren = SceneComponentObject-
>GetAttachChildren();
// gather children for component templates
USCS_Node* SCSNode =
ComponentUtils::FindCorrespondingSCSNode(SceneComponentObject);
if (SCSNode != nullptr)
{
// gather children from the SCSNode
for (USCS_Node* SCSChild : SCSNode->GetChildNodes())
{
USceneComponent* ChildSceneComponent =
Cast<USceneComponent>(SCSChild->ComponentTemplate);
if (ChildSceneComponent != nullptr)
{
AttachedChildren.Add(ChildSceneComponent);
}
}
79
482 ЧДТУ. 242234.001 1201 3
}
if (!ShouldOverrideMobility.IsBound())
{
ShouldOverrideMobility =
FMobilityQueryDelegate::CreateStatic(&AreMobilitiesDifferent, NewMobilityType);
}
int32 NumDescendantsChanged = 0;
// recursively alter the mobility for children and deeper descendants
for (USceneComponent* ChildSceneComponent : AttachedChildren)
{
if (ChildSceneComponent)
{
if (ShouldOverrideMobility.Execute(ChildSceneComponent-
>Mobility))
{
ChildSceneComponent->Modify();
// USceneComponents shouldn't be set Stationary
if ((NewMobilityType == EComponentMobility::Stationary)
&& ChildSceneComponent->IsA(UStaticMeshComponent::StaticClass()))
{
// make it Movable (because it is acceptable for
Stationary parents to have Movable children)
ChildSceneComponent->Mobility =
EComponentMobility::Movable;
}
else
{
ChildSceneComponent->Mobility = NewMobilityType;
}
ChildSceneComponent->RecreatePhysicsState();
++NumDescendantsChanged;
}
NumDescendantsChanged +=
SetDescendantMobility(ChildSceneComponent, NewMobilityType,
ShouldOverrideMobility);
}
}
return NumDescendantsChanged;
}
/**
* A static helper function that alters the Mobility property for all ancestor
* components (ancestors of the specified USceneComponent).
*
* @param SceneComponentObject The component whose attached ancestors
you want to alter
* @param NewMobilityType The Mobility type you want to switch
ancestor components over to
* @param ShouldOverrideMobility A delegate used to determine if a ancestor's
Mobility should be overridden
* (if left unset it will
default to the AreMobilitiesDifferent() function)
* @return The number of ancestors that had their mobility altered.
80
482 ЧДТУ. 242234.001 1201 4
*/
static int32 SetAncestorMobility(USceneComponent const* SceneComponentObject,
EComponentMobility::Type NewMobilityType, FMobilityQueryDelegate
ShouldOverrideMobility = FMobilityQueryDelegate())
{
if (!ensure(SceneComponentObject != nullptr))
{
return 0;
}
if (!ShouldOverrideMobility.IsBound())
{
ShouldOverrideMobility =
FMobilityQueryDelegate::CreateStatic(&AreMobilitiesDifferent, NewMobilityType);
}
int32 MobilityAlteredCount = 0;
while(USceneComponent* AttachedParent =
ComponentUtils::GetAttachedParent(SceneComponentObject))
{
if (ShouldOverrideMobility.Execute(AttachedParent->Mobility))
{
// USceneComponents shouldn't be set Stationary
switch(NewMobilityType)
{
case EComponentMobility::Stationary:
if (UStaticMeshComponent* StaticMeshParent =
Cast<UStaticMeshComponent>(AttachedParent))
{
StaticMeshParent->Modify();
// make it Static (because it is acceptable for
Stationary children to have Static parents)
StaticMeshParent->Mobility =
EComponentMobility::Static;
StaticMeshParent->SetSimulatePhysics(false);
}
break;
case EComponentMobility::Static:
AttachedParent->Modify();
if (UPrimitiveComponent* PrimitiveComponentParent =
Cast<UPrimitiveComponent>(AttachedParent))
{
PrimitiveComponentParent-
>SetSimulatePhysics(false);
}
AttachedParent->Mobility = NewMobilityType;
break;
default:
AttachedParent->Modify();
AttachedParent->Mobility = NewMobilityType;
}
AttachedParent->RecreatePhysicsState();
++MobilityAlteredCount;
81
482 ЧДТУ. 242234.001 1201 5
}
SceneComponentObject = AttachedParent;
}
return MobilityAlteredCount;
}
/**
* When a scene component's Mobility is altered, we need to make sure the scene
hierarchy is
* updated. Parents can't be more mobile than their children. This means that
certain
* mobility hierarchy structures are disallowed, like:
*
* Movable
* |-Stationary <-- NOT allowed
* Movable
* |-Static <-- NOT allowed
* Stationary
* |-Static <-- NOT allowed
*
* This method walks the hierarchy and alters parent/child component's Mobility
as a result of
* this property change.
*/
bool GNotifyAboutMobilityUpdate = true;
static void UpdateAttachedMobility(USceneComponent* ComponentThatChanged)
{
// Attached parent components can't be more mobile than their children.
This means that
// certain mobility hierarchy structures are disallowed. So we have to walk
the hierarchy
// and alter parent/child components as a result of this property change.
// track how many other components we had to change
int32 NumMobilityChanges = 0;
// Movable components can only have movable sub-components
if(ComponentThatChanged->Mobility == EComponentMobility::Movable)
{
NumMobilityChanges += SetDescendantMobility(ComponentThatChanged,
EComponentMobility::Movable);
}
else if(ComponentThatChanged->Mobility == EComponentMobility::Stationary)
{
// a functor for checking if we should change a component's Mobility
struct FMobilityEqualityFunctor
{
bool operator()(EComponentMobility::Type CurrentMobility,
EComponentMobility::Type CheckValue)
{
return CurrentMobility == CheckValue;
}
};
FMobilityEqualityFunctor EquivalenceFunctor;
// a delegate for checking if components are Static
82
482 ЧДТУ. 242234.001 1201 6
FMobilityQueryDelegate IsStaticDelegate =
FMobilityQueryDelegate::CreateRaw(&EquivalenceFunctor,
&FMobilityEqualityFunctor::operator(), EComponentMobility::Static);
// a delegate for checking if components are Movable
FMobilityQueryDelegate IsMovableDelegate =
FMobilityQueryDelegate::CreateRaw(&EquivalenceFunctor,
&FMobilityEqualityFunctor::operator(), EComponentMobility::Movable);
// if any descendants are static, change them to stationary (or
movable for static meshes)
NumMobilityChanges += SetDescendantMobility(ComponentThatChanged,
EComponentMobility::Stationary, IsStaticDelegate);
// if any ancestors are movable, change them to stationary (or static
for static meshes)
NumMobilityChanges += SetAncestorMobility(ComponentThatChanged,
EComponentMobility::Stationary, IsMovableDelegate);
}
else // if MobilityValue == Static
{
// ensure we have the mobility we expected (in case someone adds a
new one)
ensure(ComponentThatChanged->Mobility == EComponentMobility::Static);
if (USceneComponent* ParentComponent =
ComponentUtils::GetAttachedParent(ComponentThatChanged))
{
// Cannot set mobility on skeletal mesh component to static, so
detach instead, this is prevented in the editor when trying to attach a static
component to a skeletal mesh component
if (ParentComponent->CanHaveStaticMobility())
{
NumMobilityChanges +=
SetAncestorMobility(ComponentThatChanged, EComponentMobility::Static);
}
else
{
ComponentThatChanged-
>DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
if (GNotifyAboutMobilityUpdate)
{
// Fire off a notification
FText NotificationText =
FText::Format(LOCTEXT("ComponentDetachedFromParentDueToMobility", "Caused {0} to
be detached from its parent {1} because it does not allow to be static"),
FText::FromName(ComponentThatChanged->GetFName()),
FText::FromName(ParentComponent->GetFName()));
FNotificationInfo Info(NotificationText);
Info.bFireAndForget = true;
Info.bUseThrobber = true;
Info.ExpireDuration = 2.0f;
FSlateNotificationManager::Get().AddNotification(Info);
}
}
}
}
83
482 ЧДТУ. 242234.001 1201 7
// if we altered any components (other than the ones selected), then notify
the user
if (GNotifyAboutMobilityUpdate && NumMobilityChanges > 0)
{
FText NotificationText =
LOCTEXT("MobilityAlteredSingularNotification", "Caused 1 component to also change
Mobility");
if(NumMobilityChanges > 1)
{
NotificationText =
FText::Format(LOCTEXT("MobilityAlteredPluralNotification", "Caused {0} other
components to also change Mobility"), FText::AsNumber(NumMobilityChanges));
}
FNotificationInfo Info(NotificationText);
Info.bFireAndForget = true;
Info.bUseThrobber = true;
FSlateNotificationManager::Get().AddNotification(Info);
}
}
#if ENABLE_NAN_DIAGNOSTIC
if (RelativeRotationQuat.ContainsNaN())
{
logOrEnsureNanError(TEXT("USceneComponent:UpdateComponentToWorldWithParent
found NaN in parameter RelativeRotationQuat: %s"),
*RelativeRotationQuat.ToString());
}
#endif
// If our parent hasn't been updated before, we'll need walk up our parent
attach hierarchy
if (Parent && !Parent->bComponentToWorldUpdated)
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_UpdateComponentToWorldWith
Parent_Parent);
Parent->UpdateComponentToWorld();
// Updating the parent may (depending on if we were already attached
to parent) result in our being updated, so just return
if (bComponentToWorldUpdated)
{
return;
}
}
bComponentToWorldUpdated = true;
FTransform NewTransform(NoInit);
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_UpdateComponentToWorldWith
Parent_XForm);
// Calculate the new ComponentToWorld transform
const FTransform RelativeTransform(RelativeRotationQuat,
GetRelativeLocation(), GetRelativeScale3D());
#if ENABLE_NAN_DIAGNOSTIC
84
482 ЧДТУ. 242234.001 1201 8
if (!RelativeTransform.IsValid())
{
logOrEnsureNanError(TEXT("USceneComponent:UpdateComponentToWorldWithParent
found NaN/INF in new RelativeTransform: %s"), *RelativeTransform.ToString());
}
#endif
NewTransform = CalcNewComponentToWorld(RelativeTransform, Parent,
SocketName);
}
#if DO_CHECK
ensure(NewTransform.IsValid());
#endif
// If transform has changed..
bool bHasChanged;
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_UpdateComponentToWorldWith
Parent_HasChanged);
bHasChanged = !GetComponentTransform().Equals(NewTransform,
UE_SMALL_NUMBER);
}
// We propagate here based on more than just the transform changing, as
other components may depend on the teleport flag
// to detect transforms out of the component direct hierarchy (such as the
actor transform)
if (bHasChanged || Teleport != ETeleportType::None)
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_UpdateComponentToWorldWith
Parent_Changed);
// Update transform
ComponentToWorld = NewTransform;
PropagateTransformUpdate(true, UpdateTransformFlags, Teleport);
}
else
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_UpdateComponentToWorldWith
Parent_NotChanged);
PropagateTransformUpdate(false);
}
}
void USceneComponent::OnRegister()
{
// If we need to perform a call to AttachTo, do that now
// At this point scene component still has no any state (rendering,
physics),
// so this call will just add this component to an AttachChildren array of
a the Parent component
if (GetAttachParent())
{
if (AttachToComponent(GetAttachParent(),
FAttachmentTransformRules::KeepRelativeTransform, GetAttachSocketName()) ==
false)
85
482 ЧДТУ. 242234.001 1201 9
{
// Failed to attach, we need to clear AttachParent so we don't
think we're actually attached when we're not.
SetAttachParent(nullptr);
SetAttachSocketName(NAME_None);
SetShouldBeAttached(false);
SetShouldSnapLocationWhenAttached(false);
SetShouldSnapRotationWhenAttached(false);
SetShouldSnapScaleWhenAttached(false);
}
}
// Cache the level collection that contains the level in which this
component is registered for fast access in IsVisible().
const UWorld* const World = GetWorld();
if (World)
{
const ULevel* const CachedLevel = GetComponentLevel();
CachedLevelCollection = CachedLevel ? CachedLevel-
>GetCachedLevelCollection() : nullptr;
}
Super::OnRegister();
#if WITH_EDITORONLY_DATA
CreateSpriteComponent();
#endif
}
#if WITH_EDITORONLY_DATA
void USceneComponent::CreateSpriteComponent(UTexture2D* SpriteTexture)
{
CreateSpriteComponent(SpriteTexture, true);
}
void USceneComponent::CreateSpriteComponent(class UTexture2D* SpriteTexture, bool
bRegister)
{
if (bVisualizeComponent && SpriteComponent == nullptr && GetOwner() &&
!GetWorld()->IsGameWorld())
{
// Create a new billboard component to serve as a visualization of
the actor until there is another primitive component
{
FCookLoadScope EditorOnlyLoadScope(ECookLoadType::EditorOnly);
const EObjectFlags TransactionalFlag = GetFlags() &
RF_Transactional;
SpriteComponent = NewObject<UBillboardComponent>(GetOwner(),
NAME_None, TransactionalFlag | RF_Transient | RF_TextExportTransient);
}
SpriteComponent->Sprite = SpriteTexture? SpriteTexture :
LoadObject<UTexture2D>(nullptr,
TEXT("/Engine/EditorResources/EmptyActor.EmptyActor"));
SpriteComponent->SetRelativeScale3D_Direct(FVector(0.5f, 0.5f,
0.5f));
SpriteComponent->Mobility = EComponentMobility::Movable;
SpriteComponent->AlwaysLoadOnClient = false;
SpriteComponent->SetIsVisualizationComponent(true);
86
482 ЧДТУ. 242234.001 1201 10
SpriteComponent->SpriteInfo.Category = TEXT("Misc");
SpriteComponent->SpriteInfo.DisplayName = NSLOCTEXT("SpriteCategory",
"Misc", "Misc");
SpriteComponent->CreationMethod = CreationMethod;
SpriteComponent->bIsScreenSizeScaled = true;
SpriteComponent->bUseInEditorScaling = true;
SpriteComponent->OpacityMaskRefVal = .3f;
SpriteComponent->SetupAttachment(this);
if (bRegister)
{
SpriteComponent->RegisterComponent();
}
}
}
#endif
void USceneComponent::OnUnregister()
{
CachedLevelCollection = nullptr;
Super::OnUnregister();
}
void USceneComponent::EndPlay(EEndPlayReason::Type Reason)
{
Super::EndPlay(Reason);
if (Reason == EEndPlayReason::RemovedFromWorld && !HasBeenInitialized())
{
// Detach components which are in different streaming levels so that
this level can be properly garbage collected.
// Note that we explicitly want to check the outer hierarchy and not
the owning package because we want references that participate in GC.
UObject* Outermost = GetOutermostObject();
if (AttachParent && AttachParent->GetOutermostObject() != Outermost)
{
DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
}
TInlineComponentArray<USceneComponent*> ChildrenToDetach;
for (int32 i = 0; i < AttachChildren.Num(); ++i)
{
if (USceneComponent* AttachChild = AttachChildren[i].Get();
AttachChild && AttachChild->GetOutermostObject() != Outermost)
{
ChildrenToDetach.Add(AttachChild);
}
}
for (USceneComponent* Child : ChildrenToDetach)
{
Child-
>DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
}
}
}
87
482 ЧДТУ. 242234.001 1201 11
void USceneComponent::PropagateTransformUpdate(bool bTransformChanged,
EUpdateTransformFlags UpdateTransformFlags, ETeleportType Teleport)
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate);
if (IsDeferringMovementUpdates())
{
FScopedMovementUpdate* CurrentUpdate = GetCurrentScopedMovement();
if (CurrentUpdate && Teleport != ETeleportType::None)
{
// Remember this was a teleport
CurrentUpdate->SetHasTeleported(Teleport);
}
// We are deferring these updates until later.
return;
}
const TArray<USceneComponent*>& AttachedChildren = GetAttachChildren();
FPlatformMisc::Prefetch(AttachedChildren.GetData());
if (bTransformChanged)
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_T
ransformChanged);
{
// Then update bounds
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_U
pdateBounds);
UpdateBounds();
}
// If registered, tell subsystems about the change in transform
if(bRegistered)
{
// Call OnUpdateTransform if this components wants it
if(bWantsOnUpdateTransform)
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_O
nUpdateTransform);
OnUpdateTransform(UpdateTransformFlags, Teleport);
}
TransformUpdated.Broadcast(this, UpdateTransformFlags,
Teleport);
// Flag render transform as dirty
MarkRenderTransformDirty();
}
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_U
pdateChildTransforms);
// Now go and update children
//Do not pass skip physics to children. This is only used when
physics updates us, but in that case we really do need to update the attached
children since they are kinematic
if (AttachedChildren.Num() > 0)
88
482 ЧДТУ. 242234.001 1201 12
{
EUpdateTransformFlags ChildrenFlagNoPhysics =
~EUpdateTransformFlags::SkipPhysicsUpdate & UpdateTransformFlags;
UpdateChildTransforms(ChildrenFlagNoPhysics, Teleport);
}
}
#if WITH_EDITOR
// Notify the editor of transformation update
if (!IsTemplate())
{
GEngine->BroadcastOnComponentTransformChanged(this, Teleport);
}
#endif // WITH_EDITOR
// Refresh navigation
if (bNavigationRelevant && bRegistered)
{
UpdateNavigationData();
}
}
else
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_N
OT_TransformChanged);
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_U
pdateBounds);
// We update bounds even if transform doesn't change, as
shape/mesh etc might have done
UpdateBounds();
}
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_U
pdateChildTransforms);
// Now go and update children
if (AttachedChildren.Num() > 0)
{
UpdateChildTransforms();
}
}
// If registered, tell subsystems about the change in transform
if (bRegistered)
{
//QUICK_SCOPE_CYCLE_COUNTER(STAT_USceneComponent_PropagateTransformUpdate_M
arkRenderTransformDirty);
// Need to flag as dirty so new bounds are sent to render
thread
MarkRenderTransformDirty();
}
}
}
89
482 ЧДТУ. 242234 001 3401
ДОДАТОК B
CMS-система для конструювання простих сайтiв
Інструкція користувача
482 ЧДТУ. 242060 015 3401
Листів 3
Розробник ________________ Строганов Я.Р.
482 ЧДТУ. 242060 015 3401 1
2024
Перше що бачить користувач головне меню рисунок В 1. У головному меню є 3
функціональні кнопки це «Game», «Options» та «Exit»
1 «Home» - в перекладі як дім, відповідає за повернення на головну сторінку
2 «Dashboard» - в перекладі як налаштування, відповідає за відображення меню
керування
3 «Login» - в перекладі як авторізація, відповідає за вихід до облікового запсиу.
4 «Logout» - в перекладі як вихід, відповідає за деаторизацію.
Рисунок В.1 – Демонстрація головної сторінки
З будь якої сторінки можно перейти на головну натисканням кнопки «Home»
91
482 ЧДТУ. 242060 015 3401 1
Рисунок В.2 – Демонстрація меню налаштувань
91
В меню налаштувань користувачу доступно вибрати одну із досступних функцій
системи.
«User management» переводить на сторінку керування обліковими записами
користувачів (дивитися рисунок В.3).
«Post management» переводить на сторінку керування постами (дивитися рисунок
В.4).
Меню налаштувань можна викликати лише тоді, коли корустивач авторизован у
системі.
Рисунок В.3 – Демонстрація меню керування обіковими записами користувачів
У меню керування користувачами є три функціональні кнопки, «Add new
user», «Edit» та «Delete».
«Add new user» відкриває меню створення облікового запису як на рисунку
В.4. На ньому є поле ім’я користувача, є-мейлу, паролю та вказіник активності.
«Edit» має такий же сами інтерфейс як і попередня функція
«Delete» просто видаляє користувача
482 ЧДТУ. 242060 015 9001 1
Рисунок В.4 – Меню створення облікового запсиу
Рисунок В.5 – Демонстрація меню керування постами
У меню керування користувачами є три функціональні кнопки, «Add new
post», «Edit» та «Delete».
«Add new post» відкриває меню створення посту як на рисунку В.6. На
ньому є поле назві та змісту поста.
«Edit» має такий же сами інтерфейс як і попередня функція
«Delete» просто видаляє користувача
93
482 ЧДТУ. 242060 015 9001 1
Рисунок В.6 – Демонстрація меню керування постами
94
482 ЧДТУ. 242060 015 9001 1
ДОДАТОК Г
CMS-система для конструювання простих сайтiв
Графічні матеріали
482 ЧДТУ. 242060 015 9001
Листів 8
Розробник ________________ Строганов Я.Р.
2024
95
482 ЧДТУ. 242060 015 9001 1
Рисунок Г.1 – Перший слайд
Рисунок Г.2 – Вступ
96
482 ЧДТУ. 242060 015 9001 2
Рисунок Г.3 – Методи проектування та конструювання
Рисунок Г.4 – Вимоги замовника і розробника/функціонально та
нефункціональні вимоги
94
482 ЧДТУ. 242060 015 9001 3
Рисунок Г.5 – Діаграма прецендентів
5
Рисунок Г.6 – Проектування логічної структури
95
482 ЧДТУ. 242060 015 9001 4
Рисунок Г.7 – Архітектурне проєктування
Рисунок Г.8 – Проектування логічної структури
96
482 ЧДТУ. 242060 015 9001 5
Рисунок Г.9 – Моделювання поведінки системи
Рисунок Г.10– Моделювання поведінки системи
97
482 ЧДТУ. 242060 015 9001 7
Рисунок Г.11 – Структурна схема
Рисунок Г.12 – Інтерфейс користувача
100
482 ЧДТУ. 242060 015 9001 7
Рисунок Г.13 – Тестування
100
ЧДТУ 242060.015ПЗ
Рисунок Г.14 – Фінальний слайд
4