Merge chapters of implementation and requirements

Thesis/Chapters/2. Implementation.typ

@@ -2,6 +2,45 @@
 #set heading(numbering: "1.1")
 
 = Implementacja <implementacja>
+
+W poniższym rozdziale opiszę specyfikację wymagań dla projektowanej aplikacji do współtworzenia notatek w architekturze peer to peer oraz jej pełną implementację. Celem wymagań jest określenie zakresu funkcjonalności oraz ograniczeń technologicznych, których będę się trzymać w ramach proponowanej implementacji. Wyodrębnię dwóch aktorów:
+
+- Użytkownika - osoba zarządzająca notatkami przez interfejs graficzny zaimplementowany w ramach implementacji,
+- Klient - instancja implementowanej aplikacji na urządzeniu fizycznym.
+
+Same wymagania zostały podzielone odpowiednio na wymagania funkcjonalne i niefunkcjonalne.
+
+== Wymagania funkcjonalne
+- System musi umożliwiać rozgłaszanie swojej obecności w sieci lokalnej, by móc zostać wykrytym przez innych klientów.
+- System musi umożliwiać wyszukiwanie innych aktywnych klientów znajdujących się w zakresie lokalnego otoczenia oraz lokalnej sieci.
+- System musi pozwalać na wysyłanie zaproszeń do połączenia się z wykrytymi klientami.
+- System musi na bieżąco wyświetlać listę aktualnie połączonych klientów.
+
+- System musi umożliwiać utworzenie nowej notatki tekstowej.
+- System musi umożliwiać edycję treści istniejącej notatki.
+- System musi umożliwiać trwałe usunięcie notatki.
+- System musi automatycznie tworzyć unikalny identyfikator oraz znacznik czasowy dla nowych notatek.
+- System musi pozwalać na zdefiniowanie tytułu notatki, będącego niezależnym parametrem od treści notatki.
+
+- System musi enkodować strukturę danych notatki do formatu umożliwiającego przesył notatki do połączonych klientów.
+- System musi dekodować otrzymane zakodowane dane o notatce i przekształcić je w natywny obiekt reprezentujący notatkę w systemie.
+- System musi automatycznie rozsyłać zaktualizowaną treść notatki do wszystkich aktualnie połączonych klientów w jak najkrótszym czasie od wykrycia zmian.
+- System musi nadpisać istniejącą notatkę nowo otrzymaną kopią, gdy obie posiadają ten sam identyfikator, ale otrzymana kopia zawiera nowszy znacznik czasowy.
+
+- System musi zapisywać wszystkie notatki w trwałej pamięci urządzenia.
+- System musi odświeżać interfejs z listą notatek w czasie rzeczywistym.
+
+== Wymagania niefunkcjonalne
+- System musi wspierać urządzenia mobilne firmy Apple z zainstalowanymi systemami operacyjnymi iOS lub iPadOS w wersji 18.0 lub wyższej.
+- Kod źródłowy powinien być napisany w języku Swift z wykorzystaniem deklaratywnego frameworka do budowy interfejsów graficznych - SwiftUI.
+- Operacje zapisu do plików oraz procesy sieciowe muszą być wykonywane poza głównym wątkiem - wątkiem obsługującym interfejs graficzny aplikacji.
+- Czas propagacji zmian w notatce do innego połączonego klienta nie powinien wynosić więcej niż 1 sekunda.
+- System musi obsłużyć przypadek zerwania połączenia, bez uszkodzenia notatki oraz rzucania wyjątków uniemożliwiających dalsze funkcjonowanie systemu.
+- System musi zapewnić szyfrowaną komunikację między klientami.
+- Interfejs użytkownika musi być responsywny i dostosowywać się do różnych rozmiarów ekranów i ich orientacji w zakresie urządzeń tworzonych przez Apple.
+- Wygląd aplikacji powinien spełniać oficjalne wytyczne projektowe Apple Human Interface Guideliens.
+- System powinien automatycznie dostosowywać paletę kolorów interfejsu graficznego do aktualnie ustawionego motywu systemowego.
+
 == Projekt architektury systemu <projekt>
 Przygotowana implementacja bazuje na architekturze Model-View. Jest to podejście, gdzie cała logika biznesowa jest zawarta w modelach, które bezpośrednio są przekazywane do warstwy prezentacji (View). Na tej warstwie jest wykonywane odpowiednie formatowanie danych, gdzie też brane pod uwagę są preferencje zapisu i językowe użytkownika. Model-View to uproszczony wariant popularnej w aplikacjach mobilnych architektury Model-View-ViewModel (MVVM), gdzie ViewModel jest warstwą zajmującą się przekształcaniem modelów biznesowych na gotowe do prezentacji obiekty. Warstwa View wtedy zajmuje się przede wszystkim definiowaniem struktury interfejsu użytkownika oraz logiką związaną z dostępnością (wsparcie dla funkcjonalności czytników ekranów, skalowaniem interfejsu). Przygotowana implementacja nie zawiera złożonej logiki prezentacji ani rozbudowanego graficznego interfejsu użytkownika, więc w celu uproszczenia kodu zdecydowałem się na porzucenie użycia warstwy ViewModelu.
 

Thesis/Chapters/2. Requirements.typ

@@ -1,40 +0,0 @@
-#set heading(numbering: "1.1")
-
-= Wymagania systemowe <wymagania>
-W poniższym rozdziale opiszę specyfikację wymagań dla projektowanej aplikacji do współtworzenia notatek w architekturze peer to peer. Celem jest określenie zakresu funkcjonalności oraz ograniczeń technologicznych, których będę się trzymać w ramach proponowanej implementacji. Wyodrębnię dwóch aktorów:
-
-- Użytkownika - osoba zarządzająca notatkami przez interfejs graficzny zaimplementowany w ramach implementacji,
-- Klient - instancja implementowanej aplikacji na urządzeniu fizycznym.
-
-Same wymagania zostały podzielone odpowiednio na wymagania funkcjonalne i niefunkcjonalne.
-
-== Wymagania funkcjonalne
-- System musi umożliwiać rozgłaszanie swojej obecności w sieci lokalnej, by móc zostać wykrytym przez innych klientów.
-- System musi umożliwiać wyszukiwanie innych aktywnych klientów znajdujących się w zakresie lokalnego otoczenia oraz lokalnej sieci.
-- System musi pozwalać na wysyłanie zaproszeń do połączenia się z wykrytymi klientami.
-- System musi na bieżąco wyświetlać listę aktualnie połączonych klientów.
-
-- System musi umożliwiać utworzenie nowej notatki tekstowej.
-- System musi umożliwiać edycję treści istniejącej notatki.
-- System musi umożliwiać trwałe usunięcie notatki.
-- System musi automatycznie tworzyć unikalny identyfikator oraz znacznik czasowy dla nowych notatek.
-- System musi pozwalać na zdefiniowanie tytułu notatki, będącego niezależnym parametrem od treści notatki.
-
-- System musi enkodować strukturę danych notatki do formatu umożliwiającego przesył notatki do połączonych klientów.
-- System musi dekodować otrzymane zakodowane dane o notatce i przekształcić je w natywny obiekt reprezentujący notatkę w systemie.
-- System musi automatycznie rozsyłać zaktualizowaną treść notatki do wszystkich aktualnie połączonych klientów w jak najkrótszym czasie od wykrycia zmian.
-- System musi nadpisać istniejącą notatkę nowo otrzymaną kopią, gdy obie posiadają ten sam identyfikator, ale otrzymana kopia zawiera nowszy znacznik czasowy.
-
-- System musi zapisywać wszystkie notatki w trwałej pamięci urządzenia.
-- System musi odświeżać interfejs z listą notatek w czasie rzeczywistym.
-
-== Wymagania niefunkcjonalne
-- System musi wspierać urządzenia mobilne firmy Apple z zainstalowanymi systemami operacyjnymi iOS lub iPadOS w wersji 18.0 lub wyższej.
-- Kod źródłowy powinien być napisany w języku Swift z wykorzystaniem deklaratywnego frameworka do budowy interfejsów graficznych - SwiftUI.
-- Operacje zapisu do plików oraz procesy sieciowe muszą być wykonywane poza głównym wątkiem - wątkiem obsługującym interfejs graficzny aplikacji.
-- Czas propagacji zmian w notatce do innego połączonego klienta nie powinien wynosić więcej niż 1 sekunda.
-- System musi obsłużyć przypadek zerwania połączenia, bez uszkodzenia notatki oraz rzucania wyjątków uniemożliwiających dalsze funkcjonowanie systemu.
-- System musi zapewnić szyfrowaną komunikację między klientami.
-- Interfejs użytkownika musi być responsywny i dostosowywać się do różnych rozmiarów ekranów i ich orientacji w zakresie urządzeń tworzonych przez Apple.
-- Wygląd aplikacji powinien spełniać oficjalne wytyczne projektowe Apple Human Interface Guideliens.
-- System powinien automatycznie dostosowywać paletę kolorów interfejsu graficznego do aktualnie ustawionego motywu systemowego.

Thesis/main.typ

@@ -13,10 +13,9 @@
 #zut-template([
   #include "Chapters/0. Introduction.typ"
   #include "Chapters/1. Theoretical Scope.typ"
-  #include "Chapters/2. Requirements.typ"
-  #include "Chapters/3. Implementation.typ"
-  #include "Chapters/4. Tests.typ"
-  #include "Chapters/5. Summary.typ"
+  #include "Chapters/2. Implementation.typ"
+  #include "Chapters/3. Tests.typ"
+  #include "Chapters/4. Summary.typ"
 ])
 
 #render-bib()