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.
 
@@ -446,4 +485,4 @@ Ostatnim, najcięższym problemem jest aktualizacja pozycji kursora w edytorze t
 
 Ze względu na to, że aplikacja została napisana w pełni z wykorzystaniem natywnych technologii - Swift, SwiftUI, Combine, Multipeer Connectivity - projekt aplikacji jest niemożliwy do zbudowania bez posiadania komputera z najnowszą wersją systemu macOS oraz środowiska programistycznego Xcode. Kolejnym problemem jest obowiązek posiadania konta Apple Developer, który wymaga wyrażenia zgody na regulamin użytkowania oprogramowania dostarczanego przez firmę Apple do rozwoju aplikacji na systemy operacyjne iOS i iPadOS. Wszystkie wspomniane wymogi sprawiają, że kontrybucja do kodu źródłowego aplikacji jak i jej kompilacja we własnym zakresie jest bardzo utrudniona.
 
-Następnym problemem jest interfejs frameworku Multipeer Connectivity. Opiera się on na przekazywaniu obustronnie specjalnych obiektów oraz narzuca konkretne sposoby wymiany danych między instancjami aplikacji. Sprawia to, że implementacja, bez tworzenia dodatkowych warstw abstrakcji, nie jest możliwa do rozszerzenia o wsparcie innych systemów operacyjnych. Rozważaną alternatywą było użycie frameworku Network, który opiera się na przesyłaniu ramek TCP, ale to znacznie zwiększało złożoność całej implementacji.
+Następnym problemem jest interfejs frameworku Multipeer Connectivity. Opiera się on na przekazywaniu obustronnie specjalnych obiektów oraz narzuca konkretne sposoby wymiany danych między instancjami aplikacji. Sprawia to, że implementacja, bez tworzenia dodatkowych warstw abstrakcji, nie jest możliwa do rozszerzenia o wsparcie innych systemów operacyjnych. Rozważaną alternatywą było użycie frameworku Network, który opiera się na przesyłaniu ramek TCP, ale to znacznie zwiększało złożoność całej implementacji.

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/2. Implementation.typ"
-  #include "Chapters/3. Implementation.typ"
+  #include "Chapters/3. Tests.typ"
-  #include "Chapters/4. Tests.typ"
+  #include "Chapters/4. Summary.typ"
-  #include "Chapters/5. Summary.typ"
 ])
 
 #render-bib()