fixed typos and par indents

2025-02-14 02:14:34 +02:00
parent 88d7be1bd1
commit 1518aa7149
3 changed files with 44 additions and 47 deletions
--- a/README.md
+++ b/README.md
@ -1 +1 @@
-[Coursework](https://gitea.linerds.us/0x1D8/repo) paper, declared in [typst](https://typst.app/), using [this template](https://gitea.linerds.us/pencelheimer/typst_nure_template]).
+[Coursework](https://gitea.linerds.us/0x1D8/repo) paper, declared in [typst](https://typst.app/), using [this template](https://gitea.linerds.us/pencelheimer/typst_nure_template).
--- a/main.typ
+++ b/main.typ
@ -1,5 +1,4 @@
 #import "template.typ": *
-#import "@preview/indenta:0.0.3": fix-indent

 #let author = (
  name: "Білоус А. А.",
@ -113,30 +112,28 @@
  appendices: appendices,
 )

-#show: fix-indent()
-
 #nheading("Вступ")
-У сучасному світі істують мільйони пакунків з програмним забезпеченням, програмними бібліотеками та іншою інформацією.
+У сучасному світі існують мільйони пакунків з програмним забезпеченням, програмними бібліотеками та іншою інформацією.
 Інформаційні системи управління цими пакунками стали критично важливим елементом сучасної розробки програмного забезпечення. Їх значення особливо зросло з розвитком відкритого програмного забезпечення та модульного підходу до розробки, де кожен проект може залежати від десятків, сотень, або навіть тисяч сторонніх компонентів.

 Відсутність ефективних систем управління пакунками призводить до численних проблем у процесі розробки. Розробники стикаються з труднощами при пошуку потрібних бібліотек, виникають конфлікти версій, ускладнюється процес оновлення залежностей, а також з'являються проблеми з безпекою через використання застарілих версій компонентів. Це суттєво сповільнює процес розробки та може призвести до значних фінансових втрат.

-Метою цієї курсової роботи є розробка інформаційної системи "Репозиторій пакунків. Колаборація над пакунками", яка спрощує процес менеджменту пакунків, створення їх відносин, керування залежностями, та надання користувачам різних ролей у розвитку репозиторію. У процесі роботи над системою було проведено детальний аналіз зхожої системи AUR@aur, котра ефективно використовується для надання користувачам дистрибутиву Arch Linux@archlinux можливості публіковати свої пакунки. Було спроектовано реляційну базу даних і розроблено комп'ютерну програму, яка дозволяє взаємодіяти з репозиторієм.
+Метою цієї курсової роботи є розробка інформаційної системи "Репозиторій пакунків. Колаборація над пакунками", яка спрощує процес менеджменту пакунків, створення їх відносин, керування залежностями, та надання користувачам різних ролей у розвитку репозиторію. У процесі роботи над системою було проведено детальний аналіз схожої системи AUR@aur, котра ефективно використовується для надання користувачам дистрибутиву Arch Linux@archlinux можливості публіковати свої пакунки. Було спроектовано реляційну базу даних і розроблено комп'ютерну програму, яка дозволяє взаємодіяти з репозиторієм.

-Весь застосунок написано мовою програмування Rust@rust, для графічного інтерфейсу використовується бібліотека iced@iced, для взаємодії з базою даних використвуєтсья бібліотека SQLx@sqlx. Інформація зберігається у базі даних MySQL@mysql. Розробка виконувалася у текстовому редакторі Neovim@neovim.
+Весь застосунок написано мовою програмування Rust@rust, для графічного інтерфейсу використовується бібліотека iced@iced, для взаємодії з базою даних використовується бібліотека SQLx@sqlx. Інформація зберігається у базі даних MySQL@mysql. Розробка виконувалася у текстовому редакторі Neovim@neovim.

-= АНАЛІЗ ТА КОНЦЕПТУАЛЬНЕ МОДЕЛЮВАННЯ ПРЕДМЕТНОЇ ОБЛАСТІ
+= Аналіз та концептуальне моделювання предметної області
 #v(-spacing)
 == Аналіз предметної області
 Дослідження предметної області є ключовим етапом у розробці інформаційної системи "Репозиторій пакунків. Колаборація над пакунками". Основною метою даного аналізу є визначення функціональних вимог та технічних особливостей системи, необхідних для ефективного управління програмними пакунками та забезпечення продуктивної співпраці розробників.

-Репозиторій пакунків являє собою централізоване сховище інформації про програмне забезпечення, що забезпечує зберігання, версіонування та розповсюдження програмних компонентів. В сучасних умовах критично важливою є автоматизація таких процесів як управління залежностями, контроль версій, перевірка сумісності та забезпечення безпеки пакунків. Це дозволяє значно підвищити ефективність розробки програмного забезпечення та мінімізувати ризики, пов'язані з використанням сторонніх компонентів.
+Репозиторій пакунків являє собою централізоване сховище інформації про програмне забезпечення, що забезпечує зберігання, розповсюдження та контроль версій програмних компонентів. В сучасних умовах критично важливою є автоматизація таких процесів як управління залежностями, контроль версій, перевірка сумісності та забезпечення безпеки пакунків. Це дозволяє значно підвищити ефективність розробки програмного забезпечення та мінімізувати ризики, пов'язані з використанням сторонніх компонентів.

 Для створення ефективної системи управління пакунками необхідно ретельно проаналізувати існуючі рішення та їх особливості. Такий аналіз допомагає виявити найбільш важливі функціональні можливості та уникнути потенційних проблем при проектуванні власної системи.

 В якості системи-аналогу розглянемо Arch User Repository (AUR)@aur -- репозиторій користувацьких пакунків для дистрибутиву Arch Linux@archlinux. AUR є яскравим прикладом успішної реалізації концепції колаборативної розробки та управління пакунками. Система надає користувачам можливість самостійно створювати та поширювати пакунки, які не входять до офіційного репозиторію.

-При відвідуванні головної сторінки AUR @aur_main можна побачити статиску свого акаунту, всього репозиторію а також останні оновлення пакунків. За допомогою поля пошуку можна перейти до сторінки пошуку пакунків @aur_search.
+При відвідуванні головної сторінки AUR @aur_main можна побачити статистику свого акаунту, всього репозиторію а також останні оновлення пакунків. За допомогою поля пошуку можна перейти до сторінки пошуку пакунків @aur_search.

 #img("img/aur/aur_main.png", "Головна сторінка AUR")

@ -148,11 +145,11 @@

 #img("img/aur/aur_user.png", "Деталі користувача в AUR")

-Навігація по репозиторію здебільного здійснюється за допомогою гіперпосилань на сторінку пошуку де можна обрати досить багато критерій пошуку. Наприклад, при натисканні посилання "View this user's packages" в профілі користувача lsf, можна побачити всі пакунки котрі цей користувач підтримує @aur_search_func.
+Навігація по репозиторію здебільшого здійснюється за допомогою гіперпосилань на сторінку пошуку де можна обрати досить багато критерій пошуку. Наприклад, при натисканні посилання "View this user's packages" в профілі користувача lsf, можна побачити всі пакунки котрі цей користувач підтримує @aur_search_func.

 #img("img/aur/aur_search_func.png", "Фунціонал пошуку AUR")

-В контексті розробки пакункового репозиторію важливо визначити основні ролі користувачів та їхні потреби. Розробники пакунків виступають основними користувачами системи, створюючи та підтримуючи програмні компоненти, в той час як інші учасники можуть долучатися до процесу тестування, рецензування та вдосконалення пакунків.
+В контексті розробки репозиторію пакунків важливо визначити основні ролі користувачів та їхні потреби. Розробники пакунків виступають основними користувачами системи, створюючи та підтримуючи програмні компоненти, в той час як інші учасники можуть долучатися до процесу тестування, рецензування та вдосконалення пакунків.

 Аналіз інформаційної системи виявив наступні ключові об'єкти предметної області: читач, супроводжуючий, пакунок, база пакунку, залежності пакунків, відносини пакунків, роль користувача. Основним користувачем виступає читач, який потребує ефективних інструментів для отримання інформації про програмні компоненти.

@ -183,16 +180,16 @@
 - додавати, видаляти та оновлювати ролі інших користувачів для власних пакунків;
 - оновлювати чужі пакунки та бази пакунків до яких був наданий доступ редагування;
 - переглядати статистику свого акаунту;
- змінювати інформацію своєго акаунту;
+- змінювати інформацію свого акаунту;
 - вийти з акаунту;
 - видалити свій акаунт.

-Всі дані зберігатимуться в базі даних, яка містить пов'язані таблиці спроектовані таким чином, що б забезпечити цілістність і коректність даних в них. Розумне проектування бази даних забезпечить оптимізацію обробку, пошук та оновлення інформації. Кожному об'єкту предметної області, як от користувач, пакунок, база пакунку, залежності пакунків, відносини пакунків та роль користувача, буде відповідати певна таблиця. Для розуміння структури інформаційної системи спроектовано загаліну діаграму класів @class_diagram, яка є основою для проектування бази даних.
+Всі дані зберігатимуться в базі даних, яка містить пов'язані таблиці спроектовані таким чином, що б забезпечити цілістність і коректність даних в них. Розумне проектування бази даних забезпечить оптимізацію обробку, пошук та оновлення інформації. Кожному об'єкту предметної області, як от користувач, пакунок, база пакунку, залежності пакунків, відносини пакунків та роль користувача, буде відповідати певна таблиця. Для розуміння структури інформаційної системи спроектовано загальну діаграму класів @class_diagram, яка є основою для проектування бази даних.

 #img("img/class_diagram.png", "Загальна діаграма класів (рисунок виконаний самостійно)")

 Система буде зберігати наступні дані:
- об'єкт користувача буде зберігати інформацію про користувачів системи. Він буде містити ім'я користувача, електронну пошту, пароль, час останнього використання обілкового запису, та його час створення з оновленням. Ця інформація необхідна для автентифікації та авторизації користувачів, а також для аудиту дій користувачів в системі;
+- об'єкт користувача буде зберігати інформацію про користувачів системи. Він буде містити ім'я користувача, електронну пошту, пароль, час останнього використання облікового запису, та його час створення з оновленням. Ця інформація необхідна для автентифікації та авторизації користувачів, а також для аудиту дій користувачів в системі;
 - об'єкт бази пакунку буде зберігати базову інформацію про групи пакунків. Він дозволить об'єднувати пакунки зі спільними компонентами та користувачами. Містить ім'я та опис групи пакунків, а також час створення та останнього оновлення. Ця інформація дозволяє групувати пакунки за їх базовою функціональністю;
 - об'єкт типу ролі користувача буде описувати ролі користувачів у контексті груп пакунків. Містить ідентифікатор ролі, її ім'я та опис. Приклади ролей: submitter (відправник), packager (пакувальник), maintainer (супроводжуючий), flagger (позначник). Цей об'єкт визначає дозволи користувачів на певні дії з групами пакунків;
 - об'єкт ролі користувача буде прив'язувати користувачів до груп пакунків та визначати їх ролі в цих групах. Містить ідентифікатор групи пакунків, ідентифікатор користувача, ідентифікатор ролі та коментар від користувача. Ця інформація дозволяє визначити, хто, чому, і які права має в кожній групі пакунків;
@ -363,9 +360,9 @@
  + від первинного ключа id залежать всі неключові атрибути, а саме: arch, requirement, package, relation_type, relation_package_name;
  + таблиця відповідає всім вимогам 3НФ: всі атрибути атомарні, всі неключові атрибути залежать безпосередньо від первинного ключа id, відсутні транзитивні залежності.

-== Побудова логічної моделі бази даних шляхом нормалізаці
+== Побудова логічної моделі бази даних шляхом нормалізації

-Нормалізація структури даних відіграє фундаментальну роль у процесі проектування сучасних інформаційних систем, оскільки забезпечує створення раціональної архітектури даних, що ефективно запобігає надлишковості інформації та можливим аномаліям. В контексті розробки інформаційної системи пакункового репозиторію, нормалізація набуває особливої значущості через комплексну природу зв'зків між пакунками.
+Нормалізація структури даних відіграє фундаментальну роль у процесі проектування сучасних інформаційних систем, оскільки забезпечує створення раціональної архітектури даних, що ефективно запобігає надлишковості інформації та можливим аномаліям. В контексті розробки інформаційної системи пакункового репозиторію, нормалізація набуває особливої значущості через комплексну природу зв'язків між пакунками.

 Розмір ER-діаграми інформаційної системи містить понад 25 атрибутів, тому згідно з методичними вказівками з курсового проектування було обрано частину, що охоплює 5 взаємопов'язаних сутностей: "Користувач", "Пакунок", "База пакунку", "Тип ролі" та "Роль" @normal_er_frag. Така декомпозиція дозволяє детально опрацювати найбільш критичні аспекти системи, забезпечуючи при цьому можливість подальшого масштабування.

@ -379,7 +376,7 @@

 #img("img/normal/normal_t.png", "Універсальне відношення T (рисунок виконаний самостійно)")

-Всі визначені атрибути є неподільними, а значення атомарні. Сполучений первиний ключ який складаєтсья з "Пакунок id" та "Роль id" дозволяє унікально ідентифікувати кожний кортеж. Ключові поля не мають порожніх значень, кортежі не мають фіксованого порядку, тому, універсальне вдношення Т знаходиться в першій нормальній формі.
+Всі визначені атрибути є неподільними, а значення атомарні. Сполучений первинний ключ який складається з "Пакунок id" та "Роль id" дозволяє унікально ідентифікувати кожний кортеж. Ключові поля не мають порожніх значень, кортежі не мають фіксованого порядку, тому, універсальне відношення Т знаходиться в першій нормальній формі.

 Щоб перевірити універсальне відношення Т на відповідність другій нормальній формі (2НФ), потрібно проаналізувати його на існування часткових функціональних залежностей неключових атрибутів від частини первинного ключа.

@ -430,12 +427,12 @@
 == Загальні відомості
 Для забеспечення простоти, ефективності та елегантності розробки інформаційної системи "Репозиторій пакунків. Колаборація над пакунками" було використано операційну систему Arch Linux@archlinux та текстовий редактор Neovim@neovim.

-Для реалізації всієї комп'ютерної програми було обрано сучасну мову програмування Rust@rust, яка є надзвичайно швидкою, надійною та продуктивною. За зберігання даних відповідає база даних MySQL@mysql, вона відома своєю стабільнітю, можливостями та швидкістю. Для взаємодії з базою даних було обрано бібліотеку SQLx@sqlx, вона є дуже гарно спроектованим проектом, розрахована на асинхроні операції та підтримку багатьох баз даних на низькому рівні. Для написання інтерфейсу комп'ютерної програми було обрано бібліотеку iced@iced, ця бібліотека фокусується на простоті та безпеці програм з графічним інтерфейсом за допомогю дотримання принципів проектування Elm@elm.
+Для реалізації всієї комп'ютерної програми було обрано сучасну мову програмування Rust@rust, яка є надзвичайно швидкою, надійною та продуктивною. За зберігання даних відповідає база даних MySQL@mysql, вона відома своєю стабільнітю, можливостями та швидкістю. Для взаємодії з базою даних було обрано бібліотеку SQLx@sqlx, вона є дуже гарно спроектованим проектом, розрахована на асинхроні операції та підтримку багатьох баз даних на низькому рівні. Для написання інтерфейсу комп'ютерної програми було обрано бібліотеку iced@iced, ця бібліотека фокусується на простоті та безпеці програм з графічним інтерфейсом за допомогою дотримання принципів проектування Elm@elm.

 == Виклик і завантаження
-Користувач може взаємодіяти з ком'ютерною програмою після встановки її до своєї операційної системи та запуску бази даних.
+Користувач може взаємодіяти з комп'ютерною програмою після встановлення її до своєї операційної системи та запуску бази даних.

-Для зберігання даних використовується СУБД MySQL@mysql. База даних та комп'ютерна програма можуть знаходитись на різних пристроях. Перед тим як кінцевий користувач приступить до використання програми, системний адміністратор, котрий відповідає за роботу інформаційної системи, має налаштувати змінну середовища "DATABASE_URL" в котрій буде адреса до налаштованого екземпляру MySQL. Для максимальної зручності налаштування рекомендуєтсья використовувати контейнерізацю за допомогою Docker@docker, особливо рекомендується його інструмент Compose@compose.
+Для зберігання даних використовується СУБД MySQL@mysql. База даних та комп'ютерна програма можуть знаходитись на різних пристроях. Перед тим як кінцевий користувач приступить до використання програми, системний адміністратор, котрий відповідає за роботу інформаційної системи, має налаштувати змінну середовища "DATABASE_URL" в котрій буде адреса до налаштованого екземпляру MySQL. Для максимальної зручності налаштування рекомендується використовувати контейнеризацію за допомогою Docker@docker, особливо рекомендується його інструмент Compose@compose.

 Інформаційна система була розроблена з використанням мови Rust@rust, тому результуюча програма не потребує залежностей під час виконання і може бути використана у вигляді самодостатнього файлу виконання.

@ -443,23 +440,23 @@
 Інформаційна система полегшує колаборацію над пакунками у репозиторії для розробників. Система забеспечує інтуїтивний інтерфейс для навігації по пакункам, їх залежностям з відносинами, та користувачам. Перелік основних функцій системи:
 - управління пакунками та їх метаданими;
 - система користувацьких акаунтів;
- система різних рівней доступу користувачей до пакунків;
- пошу та категоризація пакунків за багатьма факторами;
+- система різних рівнів доступу користувачів до пакунків;
+- пошук та категоризація пакунків за багатьма факторами;
 - надання аналітичної інформації про репозиторій, пакунки та користувачів.

-Під час розробки було використано гексагональну архітектуру@hexagonal, також відому як "архітектура портів та адаптерів". Структура проекту складаєтсья з кількох рівнів @project_structure:
+Під час розробки було використано гексагональну архітектуру@hexagonal, також відому як "архітектура портів та адаптерів". Структура проекту складається з кількох рівнів @project_structure:
 + Шар взаємодії з базою даних (тека data):
  + декларація інтерфейсу взаємодії (тека ports);
  + імплементації взаємодії (тека adapters).
-+ Шар сервісів для бізенс логіки програми (тека service), cервіси мають:
+ Шар сервісів для бізнес логіки програми (тека service), cервіси мають:
  + декларацію репозиторію який бере дані з задекларованого шару бази даних (файли з назвою repository);
  + імплементацію адаптеру репозиторію який оперує отриманням даних з шару імплементації бази даних (файли з назвою adapter);
  + декларацію контракту який будується на репозиторії і описує дані з котрими буде працювати сервіс (файли з назвою contract);
  + імплеменацію сервісу котрий оперує над даними контракту та здійснює логічні операції з обчисленнями (файли з назвою service).
 + Шар графічного інтерфесу (тека src) використовує контракти з шару сервісів для валідації даних від користувача та надсилання запитів до логічної частини застосунку.
-+ Головний файл проекту (тека src, файл main.rs) відповідає за конпонування всих шарів:
+ Головний файл проекту (тека src, файл main.rs) відповідає за компонування всіх шарів:
  + встановлення підключення до бази даних;
-  + ініціалізацю адаптерів бази даних;
+  + ініціалізацію адаптерів бази даних;
  + ініціалізацію адаптерів репозиторіїв за допомогою створених підключень та адаптерів бази даних;
  + запуск сервісів передаючи їм створені репозиторії;
  + відображення та менеджмент графічних частин застосунку яким передаються сервіси.
@ -472,7 +469,7 @@
 Для інформаційної системи створено базу даних яка має дев’ять таблиць. Код для її створення яких описаний нижче.

 Таблиця "Users" містить інформацію про користувачів системи та має таку структуру:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
 - ім'я - унікальне текстове поле яке зберігає ім'я користувача (довжина до 31 символа), не може бути порожнім;
 - пошта - унікальне текстове поле яке зберігає електронну пошту користувача (довжина до 255 символів), не може бути порожнім;
 - пароль - текстове поле яке зберігає хеш пароля (довжина до 255 символів), не може бути порожнім;
@ -496,7 +493,7 @@ CREATE TABLE Users (
 ```

 Таблиця "PackageBases" містить інформацію про бази пакунків:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
 - назва - унікальне текстове поле, зберігає назву базового пакунку (до 127 символів), не може бути порожнім;
 - опис - текстове поле (до 510 символів), може бути порожнім, зберігає опис пакунку;
 - час створення - зберігає дату створення бази пакунку, не може бути порожнім;
@ -515,7 +512,7 @@ CREATE TABLE PackageBases (
 ```

 Таблиця "PackageBaseRoles" визначає ролі користувачів для роботи з пакунками:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
 - назва - унікальне текстове поле, зберігає назву ролі (наприклад: submitter, packager; довжина до 31 символу), не може бути порожнім;
 - опис - текстове поле яке описує роль (до 255 символів), може бути порожнім.

@ -535,9 +532,9 @@ INSERT INTO PackageBaseRoles (id, name) VALUES
 ```

 Таблиця "PackageBaseUserRoles" описує ролі користувачів для баз пакунків:
- база пакунку - числове поле (ціле додатнє число), зовнішній ключ на таблицю PackageBases;
- користувач - числове поле (ціле додатнє число), зовнішній ключ на таблицю Users;
- роль - числове поле (ціле додатнє число), зовнішній ключ на таблицю PackageBaseRoles;
+- база пакунку - числове поле (ціле додатне число), зовнішній ключ на таблицю PackageBases;
+- користувач - числове поле (ціле додатне число), зовнішній ключ на таблицю Users;
+- роль - числове поле (ціле додатне число), зовнішній ключ на таблицю PackageBaseRoles;
 - коментар - текстове поле для збереження приміток (до 255 символів), може бути порожнім;
 - (base, user, role) - складний (композитний) первинний ключ, необхідний для ідентифікації таблиці та забезпечення надійної роботи бази даних;

@ -558,8 +555,8 @@ CREATE TABLE PackageBaseUserRoles (
 ```

 Таблиця "Packages" містить інформацію про окремі пакунки:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
- база - зовнішній ключ (ціле додатнє число) на таблицю PackageBases;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- база - зовнішній ключ (ціле додатне число) на таблицю PackageBases;
 - назва - унікальне текстове поле для збереження назви пакунку (до 127 символів), не може бути порожнім;
 - версія - текстове поле для збереження версії пакунку (до 127 символів), не може бути порожнім;
 - опис - текстове поле для збереження опису пакунку (до 255 символів), може бути порожнім;
@ -587,7 +584,7 @@ CREATE TABLE Packages (
 ```

 Таблиця "DependencyTypes" визначає типи залежностей:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
 - назва - унікальне текстове поле, зберігає назву типу залежності (наприклад: depends, makedepends; довжина до 31 символу), не може бути порожнім.

 ```
@ -605,7 +602,7 @@ INSERT INTO DependencyTypes (id, name) VALUES
 ```

 Таблиця "PackageDependencies" відображає залежності пакунків:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
 - архітектура - текстове поле, зберігає цільову архітектуру залежності (до 63 символів), може бути порожнім;
 - умова - текстове поле, яке зберігає умову залежності (до 255 символів), може бути порожнім;
 - опис - текстове поле, зберігає опис залежності (до 127 символів), може бути порожнім;
@ -631,7 +628,7 @@ CREATE TABLE PackageDependencies (
 ```

 Таблиця "RelationTypes" визначає типи зв'язків між пакунками:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
 - назва - унікальне текстове поле яке зберігає назву зв'яку (наприклад: conflicts, provides; довжина до 31 символу), не може бути порожнім.

 ```
@ -648,9 +645,9 @@ INSERT INTO RelationTypes (id, name) VALUES
 ```

 Таблиця "PackageRelations" описує зв'язки між пакунками:
- id - службове додатнє число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
- архітектура - текстове поле, зберігає цільову архітектуру зв'яку (до 63 символів), може бути порожнім;
- умова - текстове поле, яке зберігає умову зв'яку (до 255 символів), може бути порожнім;
+- id - службове додатне число, необхідне для ідентифікації таблиці та забезпечення надійної роботи бази даних;
+- архітектура - текстове поле, зберігає цільову архітектуру зв'язку (до 63 символів), може бути порожнім;
+- умова - текстове поле, яке зберігає умову зв'язку (до 255 символів), може бути порожнім;
 - пакунок - зовнішній ключ на таблицю Packages;
 - тип зв'язку - зовнішній ключ на таблицю RelationTypes;
 - тип зв'язку з пакунком - текстове поле, зберігає назву пакунку, з яким є зв'язок (до 127 символів), не може бути порожнім.
@ -673,11 +670,11 @@ CREATE TABLE PackageRelations (

 == Опис програмної реалізації

-При запуску комп'ютерної програми стартовим екраном є сторінка логіну @repo_login. Користувачі з існуючими акаунтами можуть увійти у свій акаунт за допомогою пошти або юзернема та свого паролю який надійно та безпечно зберігається в базі даних у зашифрованому вигляді.
+При запуску комп'ютерної програми стартовим екраном є сторінка логіну @repo_login. Користувачі з існуючими акаунтами можуть увійти у свій акаунт за допомогою пошти або юзернейма та свого паролю який надійно та безпечно зберігається в базі даних у зашифрованому вигляді.

 #img("img/repo/repo_login.png", "Сторінка логіну")

-Якщо у користувача немає акаунту, то він може натиснути на кнопку реєстраці для переходу на сторікну реєстарції @repo_register. Щоб створити новий акаунт. Користувач має надати ім'я користувача, електрону пошту та пароль.
+Якщо у користувача немає акаунту, то він може натиснути на кнопку реєстрації для переходу на сторінку реєстрації @repo_register. Щоб створити новий акаунт. Користувач має надати ім'я користувача, електрону пошту та пароль.

 Форми логіну та реєстрації перевіряють дані на валідність та не будуть робити зайвих запитів, якщо надана інформація не відповідає правилам інформаційної системи. У випадку перевірок. які не можуть бути зроблені локально, система надішле запит до бази даних і відобразить результат у графічному інтерфейсі програми.

@ -685,7 +682,7 @@ CREATE TABLE PackageRelations (

 Після успішного логіну або реєстрації програма перейде на сторінку пошуку @repo_search, яка надає можливість шукати пакунки з багатьма способами фільтрування та сортування результатів. При наведені курсору миші на елементи пошуку можна побачити стисле пояснення їх функціоналу.

-Назва пакунку, його бази та його веб-покликання на ресурс є інтерактивними. Якщо натиснути на назву пакунку, то відкриється вікно з переглядом інформації та статистики про пакунок. Якщо натиснути на назву бази пакунку, то відкриється відкно де буде інформація про базу пакунку. При натисканні на веб-покликання, воно відкриєтсья в веб-браузері, котрий стоїть за замовчуванням в операціній системі користувача.
+Назва пакунку, його бази та його веб-покликання на ресурс є інтерактивними. Якщо натиснути на назву пакунку, то відкриється вікно з переглядом інформації та статистики про пакунок. Якщо натиснути на назву бази пакунку, то відкриється відкно де буде інформація про базу пакунку. При натисканні на веб-покликання, воно відкриється в веб-браузері, котрий стоїть за замовчуванням в операціній системі користувача.

 #img("img/repo/repo_search.png", "Сторінка пошуку")

@ -928,6 +925,6 @@ pub fn view(&self) -> Element<'static, Message> {

 Створена система забезпечує зручний інтерфейс для пошуку пакунків, управління пакунками та колаборації між розробниками. Реалізовано функціонал створення та оновлення пакунків, відстеження залежностей та взаємозв'язків між пакунками, а також систему ролей для контролю доступу.

-База даних спроектована на основі реляційної моделі та нормалізована до третьої нормальної форми, що забезпечує оптимальну структуру даних та відсутність їх надлишковості. Під час розробки було використано мову програмування Rust@rust, систему управління базами даних MySQL@mysql та графічну бібліотеку iced@iced. Крім того використовуєтсья контейнеризація за допомогою Docker@docker та Docker Compose@compose що забезпечує надійність роботи системи, її масштабованість та простоту розгортання в різних середовищах.
+База даних спроектована на основі реляційної моделі та нормалізована до третьої нормальної форми, що забезпечує оптимальну структуру даних та відсутність їх надлишковості. Під час розробки було використано мову програмування Rust@rust, систему управління базами даних MySQL@mysql та графічну бібліотеку iced@iced. Крім того використовується контейнеризація за допомогою Docker@docker та Docker Compose@compose що забезпечує надійність роботи системи, її масштабованість та простоту розгортання в різних середовищах.

 Розроблена інформаційна система значно спрощує процес управління та отримання інформації про програмні пакунки. Вона відповідає поставленим завданням та має потенціал подальшої реалізації завдяки використанню дуже модульної архітектури моделювання програмного забеспечення, відомої як Гексагональна архітектура@hexagonal.
--- a/template.typ
+++ b/template.typ
@ -73,7 +73,7 @@
  )

  set text(font: "Liberation Serif", size: 14pt, hyphenate: false, lang: "ua")
-  set par(justify: true, first-line-indent: 1.25cm)
+  set par(justify: true, first-line-indent: (amount: 1.25cm, all: true))
  set underline(evade: false)

  // set 1.5 line spacing