% Pro kompilaci po částech (viz projekt.tex), nutno odkomentovat a upravit
%\documentclass[../projekt.tex]{subfiles}
%\begin{document}

\chapter{Úvod}

Již několik let lze pozorovat stoupající trend v~použití zařízení a systémů internetu věcí nejen pro soukromé účely. S~vývojem trhu a technologickými pokroky také roste zájem o~použití digitálních prostředků ve správě měst a obcí a jejich přilehlých oblastí, s~možností sdílení výsledných datových platforem s~různými zainteresovanými stranami, jako jsou i občané. Tento vývoj dodává tvar modernímu pojetí paradigmatu chytrého města, ovšem díky dynamičnosti a rozmanitosti trhu přetrvává problém s~použitím různorodých řešení od nezávislých poskytovatelů. Vyskytují se řešení slibující sjednocení těchto systémů do jetnotného celku, což snižuje frikci při jejich zavádění a vede k~udržitelnějšímu použití.

Jedno takové řešení nabízí česká společnost Logimic, s.r.o., která se soustřeďuje také na hardwarová i softwarová řešení internetu věcí pro využití v~průmyslu. Jejich platforma Smart City je specializovaná pro použití obecní správou ve snaze o~digitalizaci procesů nutných pro správu technických služeb, sledování stavu životního prostředí obce a podobně. Logimic umožňuje platformu provozovat jak vzdáleně, tak lokálně a jedná se o~celkové softwarové řešení s~datovou platformou, aplikační logikou i klientskou částí mimo jiné v~podobě webového rozhraní postaveného na technologii Angular. Odběratelé jsou subjekty z~pestré škály od malých po větší, od místních po zahraniční. Zároveň každá správa zpravidla požaduje možnost přístupu různých uživatelů pod různými rolemi a to současně, ať již se jedná o~správce systému či běžného občana.

Specifické požadavky na systém i GUI se mezi odběrateli liší a zároveň jsou proměnlivé v~čase. Platforma již umožňuje statickou konfiguraci pro potřeby individuálního klienta, ovšem každá změna této konfigurace vyžaduje práci vývojáře a opětovné sestavení a nasazení aplikace. Proto vznikl požadavek na umožnění dynamické konfigurace za běhu, jak na úrovni aplikace, tak na úrovni jednotlivých uživatelů. Tomáš Souček již ve své práci \cite{soucek:2023} vytvořil důkaz konceptu této vize umožňující konfiguraci za běhu. Výstupem práce jsou revize modelu konfiguračních metamodelů, rozšíření aplikačních služeb poskytující generické rozhraní pro manipulacemi s~dynamickými přetíženími konfigurací, nový aplikační modul s~obecným GUI pro správu konfigurací a nová koncepce úvodního dashboardu umožňující nastavení rozložení jeho widgetů na uživatelské i globální úrovni s~využitím nové služby. 

V~rámci práce bylo nutné seznámit se s~náležitostmi aplikací internetu věcí a paradigmatem chytrého města, což je náplní první teoretické kapitoly \ref{chapter:iot}. Pro bližší pochopení datového a logického modelu aplikace, ale i požadavků na změny, jsou v~kapitole \ref{chapter:cms} analyzovány systémy pro správu obsahu na teoretické i implementační úrovni. Před samotnou implementací je v~kapitole \ref{chapter:analysis} analyzován současný stav a požadavky na změnu a v~kapitole \ref{chapter:design} je navržena podoba této implementace popsané v~kapitole \ref{chapter:implementation}. Praktická část je zakončena testováním implementace v~kapitole \ref{chapter:testing} a výsledek práce je shrnut v~závěru v~kapitole \ref{chapter:conclusion}.

\chapter{Aplikace internetu věcí}\label{chapter:iot}
\textit{Internet věcí} (dále jen IoT) je velice aktuální technologický trend s~širokým dosahem napříč technologickým i socioekonomickým světem. Například \cite{rejeb:2022} v~roce 2022 uvedl, že trh IoT v~posledních letech zažil exponenciální růst a že tržní analytici předpovídají růst průmyslového IoT z~přibližně 77 miliard USD v~roce 2020 na 110 miliard USD do roku 2025. Dále \cite{statista:2023} předpovídá do roku 2030 nárůst celkového počtu připojených zařízení IoT téměř na 30 miliardy -- zhruba dvojnásobek oproti roku 2020.

Vedlejší efekt tak turbulentního trhu je velké množství izolovaných standardů a definic. Sporné je samotné označení \uv{internet} v~termínu IoT. Autoři \cite{rose:2015} poskytují přehled jednotlivých definic IoT od některých významných entit, kde nejvýraznější kolize vzniká právě v~použití pojmu internet. Obecný konsenzus ale lze najít v~přítomnosti vestavěných elektronických zařízení (\textbf{senzory} a \textbf{aktuátory}) a jejich komunikaci internetovými protokoly mezi sebou či stanicovými uzly.

Pro charakter trhu IoT a vysoké množství vývojářů a dodavatelů nelze spoléhat na vysokou úroveň vertikální integrace\footnote{V kontextu práce lze chápat vertikálně integrovanou platformu jako ucelený ekosystém kompatibilních hardware a software technologií, zpravidla od stejného dodavatele.}. Naopak se mnoho poskytovaných řešení snaží o~co nejlepší horizontální integraci, tedy kompatibilitu s~existujícími řešeními a platformami \cite{schermuly:2019}. Současně kladou spotřebitelé na provoz produktů IoT vysoké nároky v~ohledech jednoduché a dlouhodobé bezproblémové funkčnosti. Kombinace těchto faktorů nutí dodavatele vyvíjet produkty v~souladu s~uznanými konvencemi a standardy.

\section{Topologie sítě IoT a její prvky}
Pro pochopení konceptů IoT a jeho využití v~různých aplikacích je nutné znát význam jednotlivých uzlů a způsoby komunikace mezi nimi s~ohledem na využitelnost v~konkrétních případech užití. Podobně jako v~konvenčních IP sítích, i v~IoT existují koncové uzly nacházející se na okrajích topologie a mezi nimi se mohou nacházet komunikační mediátoři, shromažditelé a zpracovatelé dat a ostatní uzly vykonávající řídící či aplikační funkce.

Při pohledu na okrajové uzly, tedy samotná vestavěná zařízení specializovaná pro použití v~aplikacích IoT, lze zpozorovat dělení na dvě kategorie -- \textit{senzory} a \textit{aktuátory}. Senzor, tedy snímač, v~síti IoT vykonává roli vstupního zařízení pro danou aplikaci. Dokáže snímat stav fyzického prostředí a předávat informace o~něm aplikační logice v~souladu s~komunikačním protokolem, ať už se jedná o~měření povětrnostních podmínek, měření hladiny vody, či elektrické spotřeby atd. Naopak aktuátor funguje jako aktivní periferie aplikace IoT -- dokáže měnit stav fyzického prostředí na základě výstupů aplikační logiky. Ať už se jedná o~spínač, elektromotor, či elektronicky řízenou klimatizaci, jeho rolí je automatizace úkonů ve fyzickém prostředí na základě vstupů ze senzorů či pokynů lidského uživatele.

Protože nelze zaručit kompatibilitu komunikačních technologií a protokolů mezi koncovými uzly, či dokonce jejich přímé napojení na aplikační službu, je zapotřebí vrstva schopná abstrahovat komunikaci mezi koncovými uzly navzájem a mezi konc. uzly a aplikační službou. Taková vrstva se v~kontextu IoT nazývá \textit{brána} a může např. nabývat podoby mobilního telefonu schopného agregovat a spravovat různé domácí spotřebiče, který je zároveň připojený ke cloudové aplikační službě prostřednictvím internetu \cite{rfc7452}.


\subsection*{Komunikační model}
Po vymezení základních pojmů lze nastínit možné tvary, kterých může topologie IoT nabývat. Dokument \cite{rfc7452} a autor \cite{rose:2015} uvažují dělení na čtyři běžně používané komunuikační modely:

\begin{itemize}
     \item Zařízení do zařízení ilustruje model, kdy dva koncové uzly, i od jiných výrobců, jsou schopné komunikovat autonomně mezi sebou. Přes zdánlivou jednoduchost tohoto modelu, právě zde vyvstává mnoho problémů při snaze o~horizontální integraci. Nejen že musí dva takové uzly využívat stejné komunikační technologie, jako například ZigBee, ale pro nároky na nízkou cenu a energetickou spotřebu vestavěných zařízení je klíčové použití úsporných, proto často proprietárních, protokolů a bezpečnostních mechanismů. Pro výrobce je tak s~pomocí proprietárních technologií dosažitelnější vyrobit kompetitivní produkt oproti investice do obecných přístupů, což je jeden z~důvodů, proč se tento komunikační model vyskytuje spíše v~izolovaných sítích malého měřítka \cite{rose:2015}.% Viz obrázek \ref{fig:communicationmodel_devicetodevice}. \label{item:devicetodevice}

    % \begin{figure}[hbt]
    %     \centering
    %     \includegraphics[width=1\textwidth]{obrazky-figures/iot_communicationmodel_devicetodevice.pdf}
    %     \caption{Diagram komunikačního modelu zařízení do zařízení, inspirováno \cite{rose:2015, rfc7452}}
    %     \label{fig:communicationmodel_devicetodevice}
    % \end{figure}

    \item Zařízení do cloudu modeluje situaci, kdy uzel je přímo připojený do IP sítě pro komunikaci s~poskytovatelem aplikační služby. Zde aplikační služba nabývá vedoucí role a řídí chod sítě. Přestože jsou zde použity již existující technologie jako Wi-Fi a sada IP protokolů, horizontální integrace většinou bývá omezená a spotřebitel je nucen využívat cloudové služby od dodavatele samotných zařízení \cite{rose:2015}. \label{item:devicetocloud}

     \item Zařízení do brány je model běžně implementovaný pro umožnění správy rozmanité sady koncových zařízení v~reálném čase. Brána tu nadále komunikuje s~cloudovou aplikační službou poskytující vzdálený přístup či kolekci dat.% Viz obrázek \ref{fig:communicationmodel_devicetogateway}. \label{item:devicetogateway}

    % \begin{figure}[hbt]
    %     \centering
    %     \includegraphics[width=1\textwidth]{obrazky-figures/iot_communicationmodel_devicetogateway.pdf}
    %     \caption{Diagram komunikačního modelu zařízení do brány, inspirováno \cite{rose:2015, rfc7452}}
    %     \label{fig:communicationmodel_devicetogateway}
    % \end{figure}

    \item Model sdílení dat mezi aplikačními poskytovateli pojednává spíše o~sdílení datových a řídicích platforem mezi apl. poskytovateli, kde poskytovatele lze chápat jako cloudovou službu či datový server. Napovídá použití zavedených metod pro přenos strukturovaných dat mezi různými aplikacemi jako jsou aplikační rozhraní typu REST v~kombinaci s~JSON formátem a komunikace přes webové protokoly. Přínos pro spotřebitele spočívá v~schopnosti nativně exportovat a analyzovat data napříč platformami. Nepřímo se to může projevit jako zdánlivá \textbf{integrace několika platforem}.
\end{itemize}

\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.8\textwidth]{obrazky-figures/iot_communicationmodel_comparison.pdf}
        \caption{Porovnání topologií komunikačních modelů zařízení do zařízení (výše) a zařízení do brány (níže). Diagramy inspirovány \cite{rose:2015, rfc7452}.}
        \label{fig:communicationmodel_comparison}
\end{figure}

\pagebreak
\section{Chytrá města}
Se stále rostoucím množstvím a hustotou městských oblastí jsou přímo spojené potřeby hospodárně nakládat se zdroji a implementovat škálovatelné strategie pro efektivní správu městských infrastruktur, životního prostředí a administrativních potřeb občanů. Pojem \textit{chytré město} vznikl jako reakce na tyto potřeby \cite{giffinger:2007} a jeho definice je stejně mnohotvárná jako snahy o~vytvoření rámce pro řešení problémů rapidní urbanizace.

Giffinger a kol. se již v~roce 2007 snaží jako chytré město definovat takové, které k~vývoji přistupuje s~perspektivou do budoucnosti. Jako atributy takového přístupu jmenuje mimo jiné informovanost, flexibilitu a autonomii \cite{giffinger:2007, chourabi:2012}. Zároveň již tehdy uvažují roli informačních technologií v~průmyslu, vzdělávání a dopravě.

Na konci roku 2011 byla oficiálně registrována ochranná známka \uv{smarter cities} (\textit{chytřejší města}) společnosti IBM \cite{soderstrom:2014}. Některými publikacemi je tato kampaň kritizována jako finančně motivovaná snaha zevšeobecnit problémy světových měst do takové formy, pro kterou IBM příhodně poskytuje vlastní řešení \cite{soderstrom:2014, gavin:2022}. Přesto to byl významný milník v~šíření povědomí o~trhu s~IT řešeními pro rozvoj \textit{chytrých měst} a jeho legitimizaci \cite{soderstrom:2014}. Sajhau, tehdejší viceprezident divize Smarter Cities francouzské IBM, v~\cite{sajhau:2017} identifikuje tři kritéria, kterými lze město charakterizovat jako \uv{chytré}:

\begin{itemize}
    \item Přítomnost datových platforem -- Datovou platformu, ať již centrální či decentralizovanou, zde charakterizuje tak, že musí být schopna shromažďovat a \textbf{agregovat} rozsáhlé množství dat z~různých zdrojů.

    \item Relevantní informace dostupné na regionální úrovni -- Datové platformy musí umožnit redistribuci užitečných informací srozumitelným způsobem. Informace jsou otevřená data z~platforem a také predikce vytvořené pomocí analýz a kognitivního počítání\footnote{Technologický přístup umožňující spolupráci lidí a výpočetních zařízení na základě principů učení, modelování a generování hypotéz \cite{hurwitz:2015}.}.

    \item Účast občanů -- Účast občanů lze chápat jako pasivní či aktivní přispívání jednotlivých obyvatel do znalostní banky, tedy hlášení dopravní situace, hlasování o~projektech atd. Příklad pasivní účasti může být používání automobilů se senzory, jejichž data jsou shromažďována a analyzována pro identifikaci problémů jako např. synchronizace konkrétních semaforů.
\end{itemize}

\subsection*{Chytrá města jako aplikace internetu věcí}
S~technologickým vývojem v~oblasti IoT a pokroky v~integraci těchto technologií zasazují aktuálnější publikace koncept chytrých měst stále více do kontextu informačních technologií a IoT. Na základě tohoto vývoje dále vznikají termíny jako \uv{chytrá města založená na IoT} \cite{mehmood:2017}. Na druhou stranu kombinace rozvoje tohoto trhu a nejednoznačné definice chytrého města, způsobuje do budoucnosti riziko redukce těchto výrazů na pouhá marketingová hesla. Znepokojení s~touto skutečností existuje téměř stejně dlouho jako samotný pojem \cite{finger:2017}. Navzdory kritice lze v~\cite{mehmood:2017} najít několik případových studií úspěšných implementací digitalizace měst pomocí elektronických senzorů a aktuátorů zapojených do rozsáhlé síťové a datové platformy, viz tabulka \ref{tab:smart_city_case_studies}.

\begin{table}[hbt]
\centering
\caption{Případové studie implementace paradigmatu chytrého města, převzato z~\cite{mehmood:2017}}
\label{tab:smart_city_case_studies}
\begin{tabularx}{\textwidth}{|l|c|X|X|}
\hline
Město & Populace & Přínosy & Hlavní partneři \\ \hline

Busan, J. Korea & 3{,}4 mil. & bezpečnostní služba pro děti/seniory, inteligentní námořní systém pomocí dronů, chytré parkování, přechody a využití energie & městská správa, Cisco, ETRI, KETI, SK Telecom, KT \\ \hline

Santander, Španělsko & 0{,}1 mil. & chytré měření teploty, intenzity dopravy, vlhkosti, ukazatelů vody, dopravní plány, atd. & Ericsson, Telefonica, Telefonica I+D \\ \hline

Chicago, USA & 2{,}7 mil. & chytrá elektrická síť, nouzová upozornění & Cisco, IBM, správa města \\ \hline

MK, UK & 0{,}2 mil. & chytrá doprava, snížení emisí uhlíku, chytrá energie a řízení vody & rada města, Samsung, Huawei, CATAPULT, Univerzita v~Cambridgi \\ \hline
\end{tabularx}
\end{table}

Cepero a kol. v~\cite{cepero:2022} uvádí, že kvanta dat generovaná vestavěnými systémy jsou pro lidské účastníky náročná na zpracování a správu. Pokouší se vytvořit přehled využívaných technologií a technik pro vizualizaci dat systémů IoT chytrých měst a jako klíčovou technologii uvádí \textit{dashboard}. Ten charakterizují jako vizuální rozhraní umožňující monitorovat nejdůležitější data \uv{rychlým pohledem} pro dosažení jednoho či více cílů, jako mohou být správa automatizovaného sběru odpadu a monitorování ovzduší. Pro vyhovění této definici je vhodné buď provést patřičnou analýzu uživatelských potřeb s~ohledem na důležitost datových údajů a jejich čitelnost, nebo alespoň umožnit uživatelům si rozhraní náležitě konfigurovat. Autoři \cite{cepero:2022} také poukazují na důležitost volby vhodné vizuální reprezentace položek, kdy například pouhé zasazení číselných hodnot do spojnicového grafu je přínosné pouze pro uživatele specializujícího se v~dané oblasti. Je vhodnější použít relativní indikátory, ukazatele vyzývající k~uživatelské akci v~případě potřeby apod. Viz příklady dashboardů na obrázku \ref{fig:edag_dashboard}.

\begin{figure}[hbt]
    \centering
    \includegraphics[width=1\textwidth]{obrazky-figures/edag_dashboard.png}
    \caption[Ukázka dashboardu]{Vizualizace dat IoT chytrého města pomocí dashboardu na platformách společností EDAG\footnotemark (výše) a Logimic (níže)}

    \label{fig:edag_dashboard}
\end{figure}

\footnotetext{Převzato z~\url{https://smartcity.edag.com/referenzen/dashboard-framework/}.}

\section{Existující řešení správy IoT}
Téma vizualizace a správy dat generovaných vestavěnými systémy IoT není pouze významnou součástí diskuze o~chytrých městech. Jde o~problém týkající se téměř všech odvětví IoT, proto je vhodné prozkoumat existující platformy a uživatelská rozhraní.

Podobně jako v~jiných problematikách IoT, i při studiu existujících platforem IoT mezi akademiky a odborníky koluje několik způsobů klasifikace. Z~nejvyšší úrovně lze platformy dělit na softwarová a hardwarová řešení. Tento postoj je problematický, protože existují vysoce proprietární kompletní řešení od jistých dodavatelů, které je nutné uvažovat jako jednotnou platformu. Podobně nevyhovující jsou klasifikace na základě technologií, ceny, funkčnosti či konkrétní oblasti využití. Před výčtem jednotlivých produktů je v~rámci práce zřejmě nejvhodnější jednotlivé platformy rozdělit podle charakterizace cílového odběratele, jak nastiňují autoři \cite{babun:2021, perry:2016}.

\subsection*{Platformy IoT pro jednotlivce a domácí využití}
Vlastnosti spotřebitelských platforem odráží požadavky jejich uživatelů -- jednoduchá instalace a konfigurace bez odborných znalostí, zachování funkcionality při použití komponent od různých dodavatelů a nízké vstupní náklady. Uživatel neočekává kompletní řešení na míru, ale modulární ekosystém zařízení a aplikací. U~většiny spotřebitelských produktů IoT je velká část přidané hodnoty v~samotném zařízení, které funguje jako modul pro stávající uživatelovu síť. I~kvůli tomu architektura takové sítě následuje spíše komunikační modely \textit{zařízení do cloudu} či \textit{zařízení do brány} \cite{perry:2016}. V~kontextu spotřebitelských platforem může lokální bránou být takzvaný \textit{smart hub}, ze kterého lze centrálně zadávat pokyny pro správu chytrých spotřebičů.

\textit{Samsung SmartThings} je proprietární platforma pro automatizaci domácnosti. SmartThings využívá model \textit{zařízení do brány}, kde bránou může kromě fyzického hubu být i mobilní aplikace pro chytrý telefon. Tato platforma nabízí úrovně abstrakce pro správu zařízení -- zaprvé zařízení, pro kompatibilitu s~platformou, implementují na své straně aplikační rozhraní pro komunikaci s~bránou, nehledě na použité nízkoúrovňové protokoly a technologie. Zadruhé existuje aplikační rozhraní pro programování aplikací spouštěných na bráně v~objektově orientovaném jazyce Groovy. Tyto aplikace jsou řízeny událostmi, které jsou analogií pro žádosti o~přerušení. Obslužná rutina obsluhuje příslušnou událost generovanou zařízením či uživatelským vstupem. Rutina může zahrnovat manipulaci s~daty či odesílání požadavků ostatním zařízením. Pro jisté případy užití je nevyhovující právě uzavřenost zdrojových kódů nižších úrovní. \textit{Apple HomeKit} je konkurenční proprietárni platforma, navíc s~uzavřeným přístupem k~vývoji aplikací. Narozdíl od SmartThings není její topologie modelována kolem centrálního hubu. Hlavní komponentou je zde zařízení samotné, které má opět aplikačním rozhraním definovanou jistou množinu \uv{služeb}, které poskytuje a které mohou odebírat či pomocí \uv{akcí} využívat ostatní zařízení. Aplikační vývoj pro HomeKit probíhá v~jazycích Swift nebo Objective C.

\textit{OpenHAB} je alternativa postavená na multiplatformním jazyce Java s~otevřenými zdrojovými kódy. Politika otevřenosti této platformy se zároveň odráží v~její koncepci -- pomáhá s~rozvojem horizontální integrace, protože existuje komunitní snaha jakékoliv zařízení, nehledě na výrobce, do platformy integrovat. Nachází se zde tři stavební prvky -- \uv{věci}, \uv{předměty} a \uv{vztahy}. Věc je individuální fyzické zařízení, předměty jsou abstrakce těchto zařízení na aplikační úrovni ve formě komunikačních rozhraní a vztahy reprezentují spojení mezi němi, včetně fyzického propojení konkrétními technologiemi. OpenHAB operuje nad spouštěčemi, které mohou být podmíněně vyvolány událostmi (např. ze zařízení), systémově nebo na základě časovaných podnětů. Jedná se tu o~čistý komunikační model \textit{zařízení do brány} \cite{babun:2021}.

\begin{figure}[hbt]
    \centering
    \includegraphics[width=1\textwidth]{obrazky-figures/iot_platforms_consumer_ui_examples.png}
     \caption[Příklady UI správy IoT]{Příklady UI správy zařízení spotřebitelských platforem IoT\footnotemark}
    \label{fig:iot_platforms_consumer_ui_examples}
\end{figure}

\footnotetext{Převzato z~\url{https://www.apple.com/home-app/} a \url{https://www.openhab.org/}.}


\subsection*{Platformy IoT pro podniky a instituce}
V~určitých charakteristikách se průmyslová a infrastrukturní řešení IoT se od těch spotřebitelských výrazně liší. Obecně jsou zde mnohem vyšší nároky na spolehlivost, dostupnost a v~jistém smyslu i bezpečnost. Autor \cite{perry:2016} uvádí, že při implementaci základů pro takovou platformu je žádoucí upřednostňovat spolehlivost před inovací. Oproti spotřebitelským platformám, kde většinu přidané hodnoty představují samotná zařízení, zde celá hodnota spočívá v~celkové implementaci, tedy sběru a agregaci dat a automatizovaném řízení aktuátorů na základě nich \cite{perry:2016}. Dále uvádí, že jistá část potenciálu těchto řešení v~průmyslu zůstává nevyužitá, protože, narozdíl od spotřebitelské domény, podniky platformy IoT chápou pouze jako nástroj pro sběr a agregaci dat. V~takových případech je plně využita pouze polovina pomyslného duplexního kanálu pro komunikaci zařízení s~bránou či cloudem. Přesto existují podniky, které se svými platformami nakládají progresivněji, například v~případové studii \cite{lyyra:2016} analýza ukázala, že již v~roce 2016 jistý automobilový výrobce pro jeden ze svých prvních úspěšných modelů za tři a půl roku dálkově vydal 117 softwarových aktualizací, tedy průměrně jednu aktualizaci přibližně každých jedenáct dní.


\textit{Microsoft IoT Core} je obecná platforma IoT uváděná jako vysoce flexibilní, bez specifického zaměření na jeden průmyslový sektor \cite{babun:2021}. Nabízí napojení na cloudové aplikační řešení stejného dodavatele, kdy odpadá provozovateli platformy nutnost spravovat vlatní brány a databázová řešení. Odnož této platformy, nazývající se \textit{FarmBeats}, je specializovaná na použití v~zemědělství. Řeší několik výzev provozu a správy IoT v~tomto sektoru, především problémy související s~odlehlostí zemědělských oblastí. Například kvůli nespolehlivému připojení má platforma proprietární zařízení fungující jako brány, které když ztratí připojení do sítě, jsou schopné data z~přilehlých uzlů lokálně uchovat, i tyto uzly automatizovaně řídit. Až při opětovném navázání připojení se autonomně synchronizují s~aplikací v~cloudu. Další z~problémů je napájení i výměna baterií v~odlehlých oblastech farem a statků, proto jsou využity vysoce energeticky úsporné komunikační protokoly jako \textit{Bluetooth Low Energy}. Konkurence jménem \textit{Amazon Web Service Iot} je postavená na velice podobném obchodním a architekturálním modelu jako MS IoT Core. \textit{ThingWorx} je další platforma pro obecné průmyslové IoT poskytující vývojářům zařízení aplikační RESTová rozhraní a vývojové kity. Podobně jako předchozí platformy poskytuje nativní podporu dashboardů.

\begin{figure}[hbt]
    \centering
    \includegraphics[width=1\textwidth]{obrazky-figures/iot_platforms_industry_ui_microsoft.png}
    \caption[Ukázka konfigurovatelného dashboardu]{Ukázka konfigurovatelného dashboardu Microsoft IoT core\footnotemark}
    \label{fig:iot_platforms_industry_ui_microsoft}
\end{figure}
\footnotetext{Převzato z~\url{https://learn.microsoft.com/en-us/azure/iot-central/core/howto-manage-dashboards}.}


\section{Bezpečnostní hrozby aplikací IoT}
Díky strmému nárůstu počtu a dostupnosti aplikací IoT začíná společnost alarmujícím tempem delegovat stále více kritické funkce na automatizovaná řešení IoT. Příkladem mohou být autonomní motorová vozidla, policejní a hasičské drony či monitoring a správa elektrických sítí v~rámci chytrých měst \cite{hassan:2019}. Je proto vhodné pozastavit se nad kybernetickými i společenskými riziky těchto implementací a úskalími jejich eliminace.

\subsection*{Útoky na integritu sítě}
Integritou sítě lze chápat především atributy důvěrnost, spolehlivost a dostupnost \cite{kominos:2014}. Jedna z~možných klasifikací útoků na integritu sítě IoT sleduje jednotlivé úrovně architektury IoT jako možné body zájmu útočníků. Autoři \cite{alaba:2017} shromáždili přehled bezpečnostních rizik následující toto dělení:

\begin{itemize}
    \item Hardware -- Hardwarové uzly sítě IoT jsou mimo jiné přímo vystavené okolnímu světu a tak často náchylné na fyzické útoky. Například existuje volně dostupný aplikační rámec pro auditování sítí využívajících technologie ZigBee, tzv. \uv{KillerBee}\footnote{Dostupný z~\url{https://github.com/riverloopsec/killerbee}.} napsaný v~jazyce Python, který však lze zneužít pro vykonávání útoků jako například \uv{Replay Attack}. Ten spočívá v~zachycení legitimního provozu a jeho přehrávání, například za účelem neoprávněné autentizace. Kompletní kit pro použití KillerBee nástrojů, zahrnující antény a mikrokontroléry, vychází v~přepočtu na 1\,000\,Kč \cite{wright:2019}. Tyto bezpečnostní nedostatky koření v~použití výpočetně a paměťově úsporných protokolů jako kompromis mezi zabezpečením zařízení a jeho výrobní a provozní cenou. Podobně jsou Bluetooth řešení náchylná mimo jiné na útoky typu \textit{DoS} či \textit{naslouchání}.

    \item Komunikační síť -- V~předchozím bodu byly diskutovány některé běžné typy útoků na bezdrátová řešení komunikace. Komunikace na fyzické vrstvě však může být i v~síti IoT řešena kabely, adaptéry a směrovači. Obecně platí, že tato média jsou méně náchylná na kybernetické útoky, už jen díky soustředění komunikace na vymezený prostor přenosového média, ke kterému lze mnohem snáze vynucovat řízený přístup. Na druhou stranu je nutné zajistit dostatečnou redundanci pro minimalizaci rizika ztráty dostupnosti.

    \item Aplikační vrstva -- Zde jsou uvažovány hrozby vycházející z~implementace aplikací shromažďujících, agregujících a prezentujících data IoT a ovládacích prvků aktuátorů. Příkladem může být celkové aplikační řešení pro chytré město či správa a řízení fyzického přístupu studentů do budovy školy. Měla by být činěna obecná opatření pro zabezpečení informačních systémů a datových shromaždišť. Z~možných typů útoků na tuto vrstvu stojí za zmínku \textit{DoS} či dokonce \textit{sociální inženýrství}. Rizika jsou zde ztráta integrity a důvěrnosti dat, únik citlivých údajů mimo oprávněné entity a jiné.
\end{itemize}

\subsection*{Citlivá data a soukromí}
Další postoj vůči bezpečnost systémů IoT pohlíží na citlivou rovnováhu symbiózy lidí a \uv{chytrých} zařízení zasahujících do stále větší části životního prostoru. Všechny senzory, od chytrých hodinek přes komponenty chytré domácnosti až po sledování pohybu osob na veřejných prostorech, generují rozshálé množství dat o~jednotlivcích i skupinách lidí. Nemalá část těchto dat má navíc citlivý charakter. Potenciální hrozby nespočívají pouze v~typickém úniku dat či jejich narušení. Pro některé zaujaté strany jsou citlivá osobní data cennou komoditou. Motivace mohou být finanční, ovšem za problematické je často považováno i využití IoT řídícími orgány pro vynucování zákonů či směrnic. Jedním z~populárních případů je systém implementovaný v~Číně, kde rozsáhlá hardwarová a aplikační síť IoT funguje jako vládní periferie pro řízení okrsků a dohled nad populací \cite{dai:2018}.


Pro zajištění kontroly nad osobními daty lze učinit několik opatření. Autoři \cite{atlam:2019} náležitě poukazují na nedostatečné \textbf{povědomí veřejnosti} o~rizicích vztahujících se na osobní soukromí a bezpečnost dat. Uvádí, že to je jeden z~hlavních problémů při obraně vůči narušování soukromí, protože spotřebitelé a uživatelé neví, jak si udržet vlastnictví svých dat a chránit je. Optimálně musí uživatel či subjekt znát celý proces získávání, zpracování a udržení či sdílení dat o~jeho osobě. Dále je na dodavateli, aby tento proces implementoval způsobem který dodržuje předpoklady pro zachování soukromí subjektů. Jeden z~takových předpokladů je \textbf{minimalizace dat}, tedy redukce získávání dat pouze na taková, která jsou nezbytně nutná pro poskytování dané služby. Dále je nutná \textbf{anonymizace dat}, tedy znemožnění ztotožnění konkrétního subjektu či skupiny se záznamy o~nich. Příkladem hrubého porušení tohoto předpokladu muže být provázání záznamů o~fyzické osobě s~jejím rodným číslem. Na nižších úrovních je také žádoucí využít \textbf{kryptografické techniky} při přenosu i shromažďování dat. Tento přístup často nelze v~IoT optimálně implementovat kvůli již zmiňovaným problémům s~výpočetní a paměťovou kapacitou zařízení. Dále je žádoucí implementovat síť a komunikační protokoly mezi zařízeními takovým způsobem, který omezuje potřebu některá data shromažďovat či dokonce přenášet do datových shromaždišť. Například chytrá žárovka může napřímo komunikovat s~ovladačem bez prostředníků ve formě cloudových služeb. Kromě systémově technických opatření je také klíčové poskytnout uživateli \textbf{nástroje pro správu přístupu} k~jeho datům umožňující mu spravovat, které subjekty mohou přistupovat k~jakým údajům. Problematika implementace a využívání takových nástrojů úzce souvisí s~povědomím veřejnosti o~problematice soukromí a etického nakládání s~daty.







\chapter{Redakční systémy}\label{chapter:cms}
Redakční systémy čili systémy pro správu obsahu (dále jen \textit{CMS} z~anglického \textit{Content Management Systems}) jsou dle \cite{barker:2015} softwarové balíky poskytující jistou úroveň automatizace úkonů nutných pro efektivní správu a konzumaci obsahu. Typicky se CMS skládá z~několika funkčních modulů -- jmenovitě repozitář obsahu (databáze), rozhraní pro jeho správu a rozhraní pro jeho konzumaci.

Pro pochopení koncepu CMS je nutné vymezit definici \textit{obsahu}. Boiko v~\cite{boiko:2005} klade důraz na rozdíl mezi \textit{daty}, \textit{informacemi} a \textit{obsahem} a rozvádí, jak spolu tyto pojmy souvisí. Obecně data lze v~tomto kontextu chápat jako kolekci atomických znalostních jednotek na nejnižší úrovni. Informace by poté byly interpretace těchto dat, které nesou jistou informační hodnotu, tedy schopnost snížit entropii systému dle formální definice informační entropie \cite{beale:2011}. Obsah jsou dle \cite{barker:2015, boiko:2005} až informace obalené metadaty, které se stanou \textbf{užitečné pro uživatele} a jsou určené ke konzumaci člověkem prostřednictvím uživatelského rozhraní. Narozdíl od samotných dat, které tvoří jisté dogma, obsah je neustále ve stavu toku a obměňování a spíše než zaznamenávat minulost, má poskytovat kontext pro budoucí rozhodnutí uživatele.

\section{Redakční proces a získávání informací}
Aby mělo smysl CMS provozovat, je nutné mít zdroj obsahu, který do něj lze ukládat a následně spravovat. Jedním z~možných zdrojů jsou uživatelé systému v~roli kreativců, čili \textit{autorů}. Proces tvorby obsahu, přímo určeného pro daný CMS, autory se nazývá \uv{redakční proces} a dle \cite{boiko:2005} se tento pojem dá vztahovat pouze na originální obsah tvořený lidmi. CMS by tedy v~rámci redakčního procesu mělo sloužit pouze jako nástroj usnadňující kreativní práci pomocí užitečných informativních a interaktivních prvků uživatelského rozhraní.

Na druhou stranu je často žádoucí umožnit do CMS průtok informací z~externích zdrojů, přičemž ideálně je tento proces, zahrnující sběr, sanitaci, konverzi a agregaci dat, automatizovaný. Případem užití může být dashboard IoT platformy, zobrazující aktuální agregované informace. Tento proces, zvaný \uv{získávání}, zahrnuje několik netriviálních kroků právě protože takto získávaná data zpravidla nevznikly účelně pro použití v~daném CMS a jejich formátování pro to není uzpůsobené. Přesto je získávání o~něco jednodušší v~případě, že jsou data alespoň strukturována v~některém ze standardních formátů určených pro opětovné užití, jako například \textit{XML} či \textit{JSON}.

\section{Řízení přístupu}
CMS jsou používány především skupinami či organizacemi lidí a výpočetních systémů, většinou s~jistou formou hiearchie. Proto je požadováno aby systém uměl tuto hiearchii odrážet v~možnostech správy a vynucování přístupů k~jednotlivým akcím nad jednotlivými objekty databáze. Není například žádoucí, aby běžný občan mohl upravovat globální vzhled domovské stránky systému pro přehledy z~městského IoT.

Je nutné vymezit pojmy \textit{role uživatele} a \textit{uživatelská role} \cite{boiko:2005, barker:2015}. Zatímco role uživatele odkazuje na roli daného jednotlivce v~organizaci, uživatelská role, či skupina, je v~kontextu informačního systému chápána jako označení pro množinu systémových uživatelů, do které jsou tito uživatelé agregováni. Uživatelská role, včetně názvu a jejích členů, je ideálně analogií role v~reálné organizaci. Zde vyplývá jedna z~nejzásadnějších výhod CMS -- na jednotlivé role lze aplikovat různě sofistikovaná pravidla pro přístup k~specifickým akcím nad specifickými objekty. Pokud by se konfigurace těchto oprávnění vztahovala pouze na jednotlivé uživatele, administrace by se rychle stala velmi náročnou a nakonec neudržitelnou.

V~reálné implementaci se na objekty CMS vážou oprávnění provádět akce mapovaná na role či uživatele, kdy tato mapa bývá označována \textit{ACL} (z~anglického \textit{Access Control List}), viz obrázek \ref{fig:cms_acl_diagram}. Bývá také možné agregovat samotné objekty do skupiny, na kterou je možné ACL aplikovat. V~neposlední řadě však může být požadováno \textbf{přetížení} oprávnění daných ACL, např. u~konkrétní role \uv{administrátor} může být vyžadován implicitní přístup k~jakékoliv akci nad jakýmkoliv objektem, bez nutnosti konfigurace. Každá platforma pak implementuje vlastní algoritmus pro řešení těchto konfliktů pravomocí.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/cms_acl_diagram.pdf}
        \caption[UML diagram datového modelu pro řízený přístup v~CMS]{UML diagram příkladového datového modelu řešící řízený přístup k~akcím nad objektem.}
        \label{fig:cms_acl_diagram}
\end{figure}

\section{Souběžný přístup}
Kvůli požadavkům na moderní CMS musí tyto systémy umožňovat souběžný přístup několika uživatelů k~jednomu zdroji v~jediný moment. Zpravidla nastává situace, kdy má k~jednomu zdroji několik různých uživatelů, kromě oprávnění číst, také práva k~zápisu či editaci. Následně vznikne \textit{chyba souběhu} (angl. \textit{race condition}), kdy tito uživatelé si v~editaci konkurují a zpravidla vítězí ten, který změny do databáze uložil jako poslední, viz příklad na obrázku \ref{fig:cms_race_condition}. Patří mezi povinnosti CMS vyřešit právě tyto konflikty, a předejít tak nepředvídatelnému chování.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/cms_race_condition.pdf}
        \caption[Sekvenční diagram chyby souběhu ve víceuživatelském CMS]{Sekvenční diagram chyby souběhu ve víceuživatelském CMS.}
        \label{fig:cms_race_condition}
\end{figure}

\subsection*{Exkluzivní přístup}
Jeden z~možných přístupů k~tomuto problému je uzamykání režimu editace jednotlivých položek \cite{boiko:2005}. Spočívá v~ukládání speciálního příznaku, tzv. \textit{zámku}, na položce, který indikuje, zda již položka není editována jiným uživatelem. V~případě že ano, je zpravidla dalšímu zájemci o~editaci dočasně poskytnuta statická kopie pro čtení, o~čemž je informován např. formou \textit{widgetu}\footnote{Prvek GUI zobrazující volatilní informaci v~uživatelsky čitelném formátu.}. V~reálné implementaci je nutné uvažovat i tzv. \textit{životnost} zámku, po jejíž expiraci je položka automaticky uvolněna pro editaci novým zájemůcm. Sledování životnosti zabraňuje uzamčení obsahu na neomezenou dobu v~případě, kdy uživatel řádně neukončí editovací režim zrušením či uložením změn. Přesto je nutné uživateli umožnit obsah upravovat déle, než stanovuje doba živnotnosti -- například redakční systém \textit{DokuWiki} implementuje na klientské straně (v~prohlížeči) mechanismus, který při uživatelské aktivitě v~editovacím poli průběžně obnovuje životnost zámku asynchronní komunikací se serverem \cite{dokuwiki:2023}.

Při implementaci zámků je zároveň nutné definovat požadovanou granularitu položek obsahu, na které budou zámky aplikovány. Například při editaci článku může být, v~závislosti na případu užití, žádoucí uzamknout pouze konkrétní sekci či kapitolu, nebo naopak celý článek.

\subsection*{Kolaborace v~reálném čase}
Progresivnější přístup k~problému souběžné editace je umožnit kolaboraci v~reálném čase za použití technologií asynchronní komunikace a reaktivních uživatelských rozhraní. Cílový stav takových implementací je rozhraní, které v~uživateli tvoří dojem sdílení jediné instance editované položky, jejíž stav v~reálném čase reflektuje akce všech uživatelů.

V~kontextu webových CMS je tohoto možné docílit metodou aktivního dotazování (angl. \textit{polling}), aktuálnější a především efektivnější \cite{pimentel:2012} metodou je ovšem použití technologie \textit{WebSocket}, umožňující plně duplexní komunikaci mezi serverovou a klientskou částí.

\section{Modulární architektura}
Již dlouhou dobu vzniká velké množství softwaru v~rámci kolektivního úsilí několika vývojářů. To, spolu s~rostoucí komplexitou vyvíjených systémů, nutí vývojáře používat architektonické vzory umožňující logické dělení produktu na udržitelné stavební bloky. Toto je obvzlášť kritické při vývoji konkurenceschopného CMS, vzhledem k~tomu jak moc většina současných systémů zakládá na úsilí open-source komunit, zahrnujících řádově i stovky či tisíce členů. Další zřejmou výhodou takového přístupu je implicitní flexibilita výsledného systému, kdy výraznou část funkcionality lze změnit volbou různých bloků schopných plynulé spolupráce pomocí definovaných rozhraní.

\textit{Moduly}, někdy nazývané \textit{plugins} či \textit{addons}, jsou výsledkem správné dekompozice softwaru v~souladu s~takovou architekturou. Modul je dle \cite{hofmeister:2000} koherentní část programu skrývající vnitřní datové struktury a algoritmy a naopak poskytující definované rozhraní v~rámci nějaké \textit{služby} poskytované zbytku aplikace. Nelze u~této definice pominout úzké souvislosti s~paradigmatem \textit{objektově orientovaného programování}, které je často při implementaci modulárních aplikací použito.

V~kontextu CMS jsou moduly často chápány jako rozšíření jádra platformy o~nějakou funkcionalitu, i když je ideálně i samotné jádro postaveno modulárně. Populární současné CMS umožňují vyhledávání komunitně tvořených modulů a instalaci \uv{kliknutím}. Samozřejmostí bývá správa pluginů včetně aktivace a deaktivace \textbf{za běhu aplikace}. Populární jsou například pluginy umožňující editaci stránek stylem \textit{WYSIWYG} a další, viz následující sekce.

\section{Současné redakční systémy}

V~současnosti mají open-source CMS největší podíl na trhu, viz obrázek \ref{fig:cms_market_share}. I~z~tohoto důvodu budou prozkoumány nejpoužívanější open-source CMS, tedy WordPress, \textit{Joomla} a \textit{Drupal}. Dále bude do průzkumu zařazen i systém DokuWiki, protože byly jeho zdrojové kódy analyzovány pro funkcionalitu exkluzivního přístupu pomocí zámků.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/cms_market_share.pdf}
        \caption[Rozložení podílu na trhu současných CMS]{Rozložení podílu na trhu současných CMS k~prosinci 2023 podle \cite{w3techs:2023}.}
        \label{fig:cms_market_share}
\end{figure}

\subsection*{WordPress}
WordPress, či \textit{WordPress.org} (nezaměňovat s~komerční variantou na klíč \textit{WordPress.com}) je v~jádru webová open-source platforma umožňující provoz a správu blogu postavená na jazyce PHP s~využitím databázového systému MySQL. Vznikl v~roce 2003 jako reakce na chybějící dostupná řešení pro provoz blogu bez hlubokých technických znalostí. Rok poté vznikla verze s~modulární architekturou umožňující vznik nepřeberného množství komunitně vyvíjených pluginů \cite{wpbeginner:wordpress:2023}, což také umožnilo transformaci platformy spíše na vysoce flexibilní CMS. K~prosinci 2023 existuje téměř $60\,000$ volně dostupných pluginů a mnoho dalších komerčních\footnote{Dle \url{https://wordpress.org/plugins}.}.

WordPress v~jádru umožňuje správu uživatelských rolí a poskytuje výčet předem definovaných rolí a jejich ACL, viz obrázek \ref{fig:cms_wordpress_user_roles}. V~základu je souběžný přístup řešen metodou exkluzivního přístupu, ovšem existují pluginy umožňující kolaborační styl editace. Podobně lze pluginy rozšířit či změnit téměř jakoukoliv funkcionalitu, jako například SEO\footnote{Optimalizace pro vyhledávače, z~anglického \textit{Search Engine Optimalization}.} či prvky zabezpečení.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/cms_wordpress_user_roles.png}
        \caption[Ukázka správy rolí platformy WordPress]{Ukázka správy rolí platformy WordPress\footnotemark.}
        \label{fig:cms_wordpress_user_roles}
\end{figure}
\footnotetext{Převzato z~\url{https://kinsta.com/blog/wordpress-user-roles}.}

\subsection*{Joomla}
Joomla (někdy psáno \textit{Joomla!}), vyvíjená od roku 2005, je webová CMS platforma postavená na technologiích PHP a MySQL. Poskytuje klíčové správcovské nástroje CMS jako uživatelské role ale i funkcionalitu jako jazykové mutace rozhraní a podobně. Samotná platforma pro správu a provoz vyžaduje oproti platformě WordPress o~něco hlubší povědomí o~webových technologiích pohánějících CMS. Joomla je sama o~sobě poněkud deterministická ohledně způsobu vykreslování stránek -- rigorózně následuje architektonický vzor \textit{MVC} (z~anglického \textit{Model-View-Controller}) a při vykreslování hojně využívá tzv. šablonovacího systému pro oddělení logiky kontroléru (\textit{controller}) a zobrazení (\textit{view}).

Přestože zastoupením na trhu zdaleka nedosahuje na WordPress, vyhrává Joomla mimo jiné od roku 2014 téměř soustavně cenu \textit{Best Free CMS} každoroční soutěže \textit{CMS Critic People's Choice Awards}\footnote{Viz \url{https://docs.joomla.org/Joomla!\_Awards}.}. Cena je rezervována zdarma dostupným CMS a hlasování se účastní veřejnost, především čtenáři portálu \textit{CMS Critic}.

\pagebreak
\subsection*{Drupal}
Drupal, podobně jako předchozí platformy, je webový open-source CMS postavený na technologiích PHP a MySQL, případně PostgreSQL. Drupal je ještě o~něco komplikovanější na používání, než Joomla. V~kombinaci s~ještě o~něco menším podílem na trhu a nižším počtem dostupných pluginů se může Drupal jevit jako velmi neatraktivní platforma.

Přesto existuje zásadní charakteristika, kterou se Drupal vyznačuje a díky které je zdánlivě první volbou vládních a veřejných institucí -- bezpečnost vůči kybernetickým útokům. Drupal je vlastní komunitou prezentován jako samozřejmá volba pro projekty citlivé na zabezpečení a potvrzují to i analýzy jako \cite{alghofaili:2018}, kde autor naměřil nižší náchylnost Drupalu na bezpečnostní díry, jak ve výchozí konfiguraci, tak po instalaci dodatečných pluginů oproti konkurenčním CMS WordPress a Joomla. Analýza zahrnovala útoky typu \textit{Cross-Site-Scripting}, \textit{SQL injection} a další.

\subsection*{Dokuwiki}
DokuWiki je open-source wiki software vyvíjený od roku 2004. Přestože se přímo nejedná o~CMS, poskytuje klíčové prvky CMS jako správu uživatelských rolí (zde skupin), konfiguraci ACL či verzování. Především poskytuje zajímavý pohled na řešení perzistentního úložiště -- DokuWiki k~funkci vůbec nevyžaduje typický databázový systém, všechen obsah je ukládán do hiearchické struktury v~systémovém úložišti. To platí i pro veškerá metadata, například zámky jsou v~souborovém systému reprezentovány jako seznamy uživatelských identifikátorů, zapisovaných pod hešovaným identifikátorem objektu\footnote{Na základě analýzy \url{https://github.com/dokuwiki/d okuwiki}.}. Samotné skripty systému jsou implementovány v~jazyce PHP.

Bohužel popularita DokuWiki je kontinuálně na ústupu\footnote{Podle \url{https://w3techs.com/technologies/details/cm-dokuwiki}.}. Možná vysvětlení jsou dostupnější a jednodušší provoz databázových systémů, úspěch konkurenční platformy \textit{MediaWiki} či výrazně nižší počet pluginů ($1\,388$ k~prosinci 2023 \cite{dokuwiki:2023}) vůči ostatním platformám primárně zaměřeným na správu obsahu.


\chapter{Analýza}\label{chapter:analysis}
Cílem této bakalářské práce je implementovat rozšíření klientské části platformy\footnote{\url{https://www.logimic.com/cs/platforma/}} \textit{Smart City}\footnote{Na webu společnosti Logimic je platforma ozačována názvem \textit{ACADA\texttrademark}, což je název konkrétní instance platformy pro zahraničního klienta.}, která je součástí softwarového řešení od společnosti \textit{Logimic, s.r.o.} (dále jen \textit{Logimic}). Výsledné rozšíření by mělo umožňovat uživatelskou konfiguraci aplikačních modulů \textbf{za běhu aplikace}.

V~rámci analýzy je nutné seznámit se s~platformou a její strukturou z~pozice uživatele i vývojáře, zjistit aktuální stav modularizace a konfigurovatelnosti aplikace a specifikovat požadavky na výsledné rozšíření na základě uživatelských požadavků.


\section{Logimic a Smart City}\label{section:logimic_and_smart_city}
Logimic je česká společnost specializující se na vývoj a poskytování cloudových řešení v~oblasti softwaru i hardwaru pro aplikace IoT. Logimic dodává svá řešení tuzemským i zahraničním klientům, přičemž stěžejním produktem firmy je aplikační platforma Smart City. Cílovými klienty platformy jsou subjekty usilující o~integraci digitálních technologií do správy své obce či oblasti v~souladu s~paradigmem chytrého města. Smart City, ve své podstatě informační systém, má za cíl poskytnout sjednocující rozhraní pro libovolnou množinu různorodých systémů IoT a umožnit v~rámci jednotného uživatelského rozhraní jejich správu a monitorování s~minimálními požadavky na technické znalosti uživatelů.

Klientská část Smart City je dostupná ve dvou variantách a to jako mobilní a webová aplikace. Předmětem této práce je webová verze, koncipovaná jako responzivní jednostránková aplikace (dále jen \textit{SPA} z~angl. \textit{single page application}) postavená na technologiích \textbf{Angular}\footnote{Aplikační rámec založený na kompontentách. \url{https://v13.angular.io}} a \textbf{TypeScript}\footnote{Nadmnožina JavaScriptu se striktním typováním. \url{https://www.typescriptlang.org}}, s~využitím knihoven třetích stran a to především \textbf{PrimeNG}\footnote{Knihovna pro Angular poskytující interaktivní komponenty uživatelského rozhraní. \url{https://primeng.org}}. Na serverové části obstarává perzistentní úložiště databáze typu \textit{PostgreSQL}, ovšem klientská část je od přímé komunikace s~databází odstíněna mezilehlým aplikačním rozhraním typu \textit{REST}.


\subsection*{Architektura aplikace}

Na nejnižší úrovni aplikační architektury se nachází Angular komponenty, které jsou součástí Angular modulů. Ty jsou principiálně schopny fungovat samostatně a poskytují v~rámci aplikace ostatním modulům jistou službu, ať už se jedná o~vykreslování jednotlivých widgetů či řízení \textit{routingu}\footnote{Instanciace a zobrazování příslušných komponent na základě poloze uživatele uvnitř GUI.}. Vrcholový modul \texttt{app} výhradně obstarává pouze import a instanciaci modulů druhé úrovně, mezi které patří nezbytné aplikační služby jako router, přetěžování konfigurací a podobně. V~rámci logické i adresářové struktury jsou Angular moduly jádra aplikace rozděleny do několika skupin, podle toho jaký typ služby v~rámci aplikace poskytují. Pro tuto práci nejrelevantnější skupina druhé úrovně modulů jádra (pod \texttt{app}) je \texttt{\textbf{lgmc-platform}}. Ta zastřešuje služby pro manipulaci s~aplikační konfigurací a pro řízení celkového aplikačního stavu včetně objektu uživatele, aplikované konfigurace, atd.

Na druhou stranu v~architektuře existují aplikační moduly, tedy aplikační bloky vysoké úrovně abstrakce, které lze dle potřeb klienta aktivovat či deaktivovat a narozdíl od Angular modulů v~aplikačním jádře by neměla být činnost jádra aplikace na nich závislá. V~několika ohledech jsou tedy moduly této aplikace analogií pro modulární architekturu populárních CMS.
Aplikační moduly ve Smart City většinou slouží pro vykreslování grafických rozhraní, a proto bude v~práci často skloňovaná předpona \texttt{\textbf{lgmc-gui}}, což je název skupiny těchto apl. modulů. Zahrnuje veškeré komponenty vykreslované jako obrazovky GUI, včetně uživatelského rozhraní pro konfigurace, dashboardy apod. Pokud to obrazovka vyžaduje, jsou při jejím vykreslení použity widgety ze skupiny \texttt{lgmc-g}, které jsou specificky vyvinuté pro použití v~projektu Smart City, viz zjednodušené schéma aplikační architektury na obrázku \ref{fig:smart_city_application_architecture}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_application_architecture.pdf}
        \caption[Schéma aplikační architektury projektu Smart City]{Zjednodušené schéma aplikační architektury projektu Smart City}
        \label{fig:smart_city_application_architecture}
\end{figure}

\newpage
\subsection*{Aktuální stav konfigurovatelnosti}
Veškeré konfigurace aplikace i modulů mají pevně definovaný model pomocí tzv. \textit{interface} jazyka TypeScript.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_config_interface_hiearchy.pdf}
        \caption[Hiearchie konfiguračních rozhraní aplikace Smart City]{Diagram hiearchie konfiguračních rozhraní.}

        \begin{tabular}{r@{: }l}
        \texttt{LgmcAppConfig} & vrcholové rozhraní aplikační konfigurace \\ \texttt{LgmcModuleConfig} & rozhraní konfigurace apl. modulu \\
        \texttt{LgmcGuiDashboardConfig} & konkrétní implementace \texttt{LgmcModuleConfig}
        \end{tabular}
        \label{fig:smart_city_config_interface_hiearchy}
\end{figure}

Obrázek \ref{fig:smart_city_config_interface_hiearchy} s~legendou ilustruje hiearchii konfiguračních rozhraní aplikace. Vrcholové rozhraní \texttt{LgmcAppConfig} dále odkazuje na podřazené rozhraní specifikující datové modely částí aplikačního jádra (API, autentizace, apod.) a také na konfigurační rozhraní jednotlivých apl. modulů. Celý datový model konfigurací tedy následuje stromovou strukturu s~kořenem v~\texttt{LgmcAppConfig}, přičemž významné bude rozhraní \texttt{LgmcModuleConfig} definující konfigurovatelné položky sdílené všemi moduly.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_config_diagram.pdf}
        \caption[Diagram definice statické konfigurace aplikace Smart City]{Diagram definice statické konfigurace.}
        \label{fig:smart_city_config_diagram}
\end{figure}

Obrázek \ref{fig:smart_city_config_diagram} ilustruje způsob definice statické konfigurace. Její konkrétní hodnoty jsou v~první řadě definované ve statickém adresáři projektu \uv{configs} jako instance konfiguračních rozhraní. Tyto hodnoty jsou při inicializaci objektu \texttt{LgmcAppConfigManager}\footnote{Objekt je součástí jádra ve skupině \texttt{lgmc-platform}.} přetíženy některou z~konfigurací definovaných pro konkrétní prostředí (\textit{environments}). Přestože toto řešení umožňuje vytvářet a spravovat konfigurace pro různé klienty a prostředí, stále jsou konfigurační objekty a jejich přetížení definovány pouze staticky a je při jakékoliv úpravě nutné aplikaci znovu sestavit a nasadit.

Nádstavbu tohoto systému, sloužící jako důkaz koncepce dynamické konfigurovatelnosti, implementoval ve své práci Tomáš Souček \cite{soucek:2023}. Souček do aplikace zavedl koncept \textit{\textbf{metamodelů}} -- modely popisující stávající konfigurační modely, které jsou do jisté míry nutné pro umožnění dynamické konfigurace aplikace uživatelem. Metamodel totiž popisuje které položky modelu jsou editovatelné, za jakých okolností a další náležitosti. Zároveň Souček v~rámci práce zajistil zřízení perzistentního úložiště dynamických konfigurací na straně databáze a příslušných metod API a implementoval apl. modul \texttt{lgmc-gui-configs} s~grafickým rozhraním pro manipulaci s~těmito konfiguracemi.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_configs_diagram_big.pdf}
        \caption[Diagram manipulací s~konfiguracemi v~aplikaci Smart City]{Zjednodušený diagram definic a manipulací s~konfiguracemi. Statická konfigurace je nově přetěžována dynamickou konfigurací uloženou v~databázi, kterou lze manipulovat metodami speciálního apl. modulu. Přetížení konfigurace je vyhodnoceno při inicializaci aplikace a odběratelé konfigurace jsou od této skutečnosti odstíněni službou pro manipulaci s~konfiguracemi aplikačního jádra.}

        \begin{tabular}{r@{: }l}
        \texttt{lgmc-gui-configs} & apl. modul s~GUI pro obecné konfigurace implementovaný Součkem
        \end{tabular}
        \label{fig:smart_city_configs_diagram_big}
\end{figure}

Nedostatky Součkova řešení, znázorněného na obrázku \ref{fig:smart_city_configs_diagram_big}, spočívají v~koncepci metamodelů a práci s~nimi. Především metamodely všech modulů jsou umístěné v~jediném adresáři, jakožto součást \texttt{lgmc-gui-configs}, ale lze jmenovat i jejich těžkopádnost (soubor \uv{modules.metamodel.ts} čítá $4724$ řádků) či chybějící možnost dynamického odvozování metamodelů v~případě chybějící definice. Dále chybí rozhraní pro manipulaci s~dynamickými konfiguracemi z~jiných aplikačních modulů, takže jejich úprava je omezená na použití \texttt{lgmc-gui-configs}.

\section{Analýza uživatelských potřeb}

Souček ve své práci \cite{soucek:2023}, konzultací s~vývojáři Logimic, indentifikoval tři typy lidi pracujících s~aplikací:

\begin{itemize}
    \item Vývojář -- má znalosti a schopnosti nutné k~libovolné manipulaci s~aplikací a jejími konfiguracemi. Úpravy od vývojáře však přichází s~vysokou cenou a dlouhým spožděním a to mimo jiné i kvůli nutnosti znovu sestavovat aplikaci při jakémkoliv zásahu do zdrojového kódu včetně statických konfigurací. Součkovo řešení do jisté míry práci vývojáře usnadňuje, protože nyní lze statickou konfiguraci za běhu přetěžovat a to přímo z~grafického rozhraní poskytnutého \texttt{lgmc-gui-configs}, ve kterém se vývojář orientuje, protože zná souvislosti uvnitř aplikační architektury.

    \item Správce systému IoT -- spravuje přidělený systém prostřednictvím aplikace Smart City, včetně uživatelů, skupin zařízení apod. Jeho organizační role je reflektovaná uživatelskou rolí \uv{System Administrator}, na kterou Součkovy metamodely odkazují v~rámci přidělování oprávnění k~editaci určitých konfiguračních hodnot. Tento přístup však koliduje s~již existujícím systémem pro správu ACL uvnitř Smart City, takzvanými \textit{Přístupovými formuláři} (dále jen \textit{accessForms}). Správce zpravidla nedisponuje stejnou mírou znalostí jako vývojář, ovšem po zaškolení je schopen použít grafické rozhraní \texttt{lgmc-gui-configs} k~přetěžování konfigurací za běhu.

    \item Uživatel systému IoT -- v~rámci systému má nejnižší pravomoce a před implementací dynamické konfigurace mu zbývala spíše pasivní role konzumenta obsahu (indikátorů zařízení atd.) bez schopnosti si jakkoliv grafické rozhraní přizpůsobit. Jelikož není žádoucí, aby běžný uživatel měnil globálně vzhled či rozložení aplikace, Souček, v~rámci jeho řešení, oddělil v~datovém modelu od dynamické konfigurace konfigurační vrstvu, přetěžující globální nastavení pouze z~pohledu konkrétního uživatele. Umožnil tedy takto uživateli si uživatelské rozhraní do vhodné míry přizpůsobit dle vlastních potřeb. Nedostatek však spočívá v~nízké uživatelské přívětivosti modulu \texttt{lgmc-gui-configs}, kdy nezaškolený uživatel, bez znalostí programových závislostí, není schopen tento modul efektivně využívat, viz příklad na obrázku \ref{fig:smart_city_configs_gui_current}.
\end{itemize}

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_configs_gui_current.png}
        \caption[Příklad konfiguračního formuláře Součkova řešení]{Příklad konfiguračního formuláře z~modulu \texttt{lgmc-gui-configs}. Běžný uživatel nezná význam většiny položek a navigace konfiguracemi není inuitivní.}
        \label{fig:smart_city_configs_gui_current}
\end{figure}

\newpage
\section{Požadavky na změnu}

V~rámci práce je očekáván návrh a implementace modulu, který bude stavět na Součkově řešení ale eliminuje zmiňované nedostatky. Jmenovitě by tedy mělo dojít k~refaktorizaci metamodelů takovým způsobem, aby nebyly centralizovány uvnitř jediného modulu, ale definovány v~rámci individuálních modulů a také by měl výsledný model nových metamodelů být znatelně sofistikovanjěší, co se týče definice jejich rozhraní a hodnot. Navíc je žádoucí implementovat rozhraní, které je schopné generovat dočasné metamodely v~případě, že je vyžadována konfigurace modulu bez definovaného metamodelu. Nakonec je požadováno integrovat definice oprávnění do stávajícího systému Přístupových formulářů, odkazujícího na konfigurovatelné uživatelské role.

S~ohledem na uživatelskou přívětivost by finální řešení mělo směřovat do stavu, kdy uživatel nemusí konfigurace provádět z~centrálního menu a místo toho by přímo do konkrétních modulů skupiny \texttt{lgmc-gui} byly vykreslovány specifické ovládací prvky umožňující uživateli přizpůsobovat si rozhraní přirozeným způsobem přímo na místech, kde uživatel očekává projevení jeho změn.
Z~toho vyplývá nutnost vyšší míry granularity metamodelů, kdy například u~dashboardu je potřebné specifikovat zcela rozdílné konfigurovatelné položky (rozložení indikátorů) například vůči postrannímu menu (přizpůsobení ikonek).

V~neposlední řadě je vhodné ošetřit exkluzivní přístup, jak vyplynulo z~analýzy používaných CMS v~kapitole \ref{chapter:cms}.

\chapter{Návrh řešení}\label{chapter:design}

Z~provedené analýzy vyplývá, že je nutné navrhnout a implementovat úpravy stávajících metamodelů a sofistikovaněji je integrovat do aplikační architektury. Dále je nutné přeformulovat manipulaci s~konfiguracemi z~pohledu uživatele pro vyšší uživatelský komfort. Při návrhu těchto změn je nutné dbát na modulární architekturu stávající aplikace a zachovat její strukturu.


Jelikož Souček při realizaci svého řešení v~\cite{soucek:2023} zvolil vhodnou metodu perzistentního ukládání dynamických konfigurací, není nutné provádět výrazné změny datového modelu na straně databáze. Souček se totiž rozhodl konfigurační hodnoty ukládat jako objekt kódovaný v~prostém řetězci formátu JSON, což umožňuje zvolit libovolný tvar konfiguračního modelu se zachováním stávajícíh definic datového modelu a aplikačního rozhraní, včetně metod pro invokaci metod API na klientské části. To vyplývá i ze skutečnosti, že data ve formátu JSON lze přímo deserializovat na objekt v~jazycích JavaScript a TypeScript.


\section{Metamodely}\label{section:metamodels}

V~rámci návrhu je potřebné identifikovat konkrétní nedostatky aktuálních metamodelů a nastínit jejich řešení. V~první řadě lze v~Součkově řešení identifikovat několik položek v~datovém modelu metamodelů, které jsou buď redundantní, nebo mají nevhodně definovanou a vymezenou datovou doménu. Několik těchto nedostatků také vychází z~toho, že nebylo využito metod objektově orientovaného programování při implementaci metamodelů, především \textit{typů} (ang. type) jazyka TypeScript, které mimo jiné umožňují využít dědičnost. V~Součkově technické zprávě je již uveden výčet položek stávajících metamodelů včetně jejich významu, zde jsou uvedeny změny, které budou nad jednotlivými položkami provedeny včetně jejich motivace:

\begin{itemize}
    \item \texttt{type} -- bude zahozena jelikož způsob vykreslení uzlu a jeho položek lze procedurálně vyvodit z~jeho struktury.

    \item \texttt{editable} -- tato položka momentálně definuje, která uživatelská role má oprávnění popisovanou konfigurační hodnotu měnit. Tento přístup je však poměrně restriktivní, protože uvažuje pouze konkrétní výčet čtyř rolí bez ohledu na potenciální proměnlivost těchto rolí v~aktuálním systému. Navíc nabývá zdánlivě arbitrárních číselných hodnot, což snižuje přehlednost souboru s~metamodelem a vede k~překlepům při jeho definici. Položka tedy bude nahrazena novou položkou \texttt{\textbf{permissions}}, která bude výčtového typu (dále jen \textit{enum}), nabývajícího jedné z~hodnot \texttt{hidden}, \texttt{readable} a \texttt{writeable}. Tato míra omezení bude implicitně jednotná pro všechny uživatele bez ohledu na roli, ovšem bude možné zavést specifickou \textit{accessForm}, která konkrétním rolím umožní přístup úrovně \texttt{writeable} ke všem konfiguracím.

    \item \texttt{hideUpdateBtn} -- bude zahozena, její logickou hodnotu lze implicitně vyvodit z~nově zavedené \texttt{permissions}.

    \item \texttt{uniqueTitle} -- bude zahozena, zřejmě se jedná o~redundantní přetížení položky \texttt{label}. Pro specifičtější potřeby bude možné základní typ rozšířit o~položku podobného významu.

    \item \texttt{label}, \texttt{icon} -- budou zachovány.

    \item \texttt{children} -- bude zachována a to pomocí vlastnosti jazyka TypeScript, která umožňuje při definici typu definovat cyklickou referenci na sebe sama v~rámci jeho atributů.

    \item \texttt{columns}, \texttt{requiredParams}, \texttt{redirect} -- jedná se o~vysoce specifické položky a při popisu některých konfiguračních položek jsou neúčelné. Budou zahozeny a v~případě potřeby zavedeny v~konkrétních rozšířeních základního typu.
\end{itemize}

Jak již bylo nastíněno, bude zaveden nový typ pod názvem \textbf{\texttt{LgmcMetaConfig}} pro obecný popis konfigurovatelné položky. Tento typ je vhodné definovat v~\texttt{lgmc-platform-model}, jelikož zde již existují definice všech konfiguračních typů. Do základního typu\\\texttt{LgmcModuleConfig}, definujícího společné konfigurační položky všech modulů, bude přidán atribut \textbf{\texttt{metamodel}} typu \texttt{LgmcMetaConfig}. Jelikož je však implementace metamodelů náročná a ne u~každého modulu nutně potřebná, bude tento atribut zachován jako volitelný. Nový atribut bude naplněn ve statické konfiguraci aplikace, tedy vedle definic statických konfigurací samotných modulů, což povede k~očekávané decentralizaci definic metamodelů. Zároveň tento atribut bude při vykreslování konfiguračního GUI ignorován, protože není účelné dovolit dynamickou konfiguraci samotných metamodelů. Výsledný datový model metamodelů, jak vyplývá z~tohoto návrhu, je ilustrován na obrázku \ref{fig:smart_city_new_metamodels_model}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_config_datamodel.pdf}
        \caption[Nový datový model datamodelů]{Diagram tříd nového datového modelu metamodelů.}
        \label{fig:smart_city_new_metamodels_model}
\end{figure}

\subsection*{Dynamické načítání metamodelů}
Pro správné vykreslení konfiguračních obrazovek a dynamickou konfiguraci je nutné, aby byl konfigurační modul schopný načítat a zpracovávat metamodel konfigurovaného modulu. Načítání metamodelu modulu, jehož metamodel je explicitně definován, je triviální i v~nově navržené architektuře s~decentralizovanými metamodely, protože je přímo součástí konfigurace modulu a tedy je přímo získatelný službou \texttt{lgmc-app-state-service}, která již poskytuje metody pro získávání konfigurací. Cílem této práce je však také implementovat mechanismus, který umožní konfiguraci modulu bez specifikování jeho metamodelu. Za tímto účelem bude implementován tzv. \textit{implicitní metamodel}, tedy metamodel dynamicky odvozený z~modelu daného modulu.

Jako prvotní přístup k~tomuto problému se nabízí tzv. \textit{reflexe}, tedy získávání metadat o~třídě či typu z~jejich instance. Jelikož však TypeScript nativně reflexi za běhu neumožňuje a dle rozhovoru s~vývojáři není žádoucí do aplikace zavádět dodatečné knihovny, byl zvolen přístup procházení atributů instance konfigurace modulu, čímž lze odhalit název, typ a hodnotu atomických atributů. Zároveň lze odhalit neatomické atributy, které jsou zároveň iterovatelné, což umožní vygenerování implicitního metamodelu s~odpovídajícími úrovněmi zanoření. Výstupem by tedy měla být metoda nového modulu zapouzdřující tuto logiku a poskytující metamodel na základě vstupní konfigurace, viz vývojový diagram na obrázku \ref{fig:smart_city_config_loadmetamodel}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_config_loadmetamodel.pdf}
        \caption[Vývojový diagram načítání metamodelů]{Vývojový diagram navržené logiky načítání metamodelů.}
        \label{fig:smart_city_config_loadmetamodel}
\end{figure}

Jelikož nelze zaručit uživatelskou přívětivost ani korektní řízení přístupu při použití implicitních metamodelů, bude každý takto vygenerovaný metamodel mít hodnotu \texttt{hidden} v~atributu \texttt{permissions}. Konfigurace takového modulu tedy bude možná pouze uživatelem s~příslušnou rolí a přístupovým formulářem, který přětěžuje tento atribut.

\section{Exkluzivní přístup}

Jelikož by měla výsledná konfigurovatelnost za běhu být dostupnější a přívětivější pro širší skupinu uživatelů Smart City, je navýšeno riziko chyby souběhu a konfliktního chování při přístupu ke konfiguračním rozhraním více uživateli současně. Z~tohoto důvodu je vhodné zavést do systému mechanismus, který bude tyto chyby schopný ošetřit. Dynamickou konfiguraci lze provádět na aplikační i uživatelské úrovni, ovšem chyba souběhu hrozí pouze na aplikační, tudíž na úrovni individuálního uživatele nebude brána v~úvahu.

Jako vhodné řešení byly uváženy časované zámky a to na úrovni konfigurace samotných modulů. Do typu \texttt{LgmcModuleConfig} tedy bude přidám atribut \texttt{timedLock} nového typu \texttt{LgmcConfigTimedLock}, který bude držet identifikátor uživatele a čas vytvoření. Tento zámek bude do konfigurace navázán při každém autorizovaném přístupu k~dynamické konfiguraci daného modulu a v~časové smyčce obnovován při setrvávající aktivitě uživatele. Zámek bude zneplatněn pokud nastane jedna  z~následujících situací:

\begin{itemize}
    \item Uživatel řádně ukončil režim konfigurace -- uživatel řádně opustil konfigurační GUI modulu uložením či zrušením změn.
    \item Vypršela časová platnost zámku -- časový údaj v~zámku je starší, než stanovuje hranice, kterou lze nastavit v~konfiguraci nově vzniklého konfiguračního modulu.
\end{itemize}

Význam zámku je logické přetížení oprávnění měnit konfiguraci (atribut \texttt{permissions} metamodelu) na hodnotu \texttt{readable}, aby nedošlo k~chybě souběhu. Stejně jako platnost zámku, bude možné i intervaly mezi obnoveními nastavit v~konfiguraci nově vznikajícího modulu. Pro rozlišení mezi stavy \texttt{readable} a uzamčení zámkem, bude při uzamčené konfiguraci vykreslen speciální widget informující uživatele o~této skutečnosti.


\section{Speciální konfigurační zobrazení}

Stávající modul pro dynamickou konfiguraci je z~hlediska GUI řešen jako analogie procházení konfiguračních objektů v~uživatelsky čitelné formě. Pro zlepšení uživatelské zkušenosti je však nutné uživatele dále odstínit od datového modelu aplikace pomocí speciálních konfiguračních obrazovek uzpůsobených pro konkrétní konfigurovatelné položky, jako například rozložení indikátorů na úvodním dashboardu. Tato speciální zobrazení je nutné implementovat zvlášť v~jejich příslušných modulech a to pomocí invokace metod \textbf{nové služby pro manipulaci s~konfiguracemi}, viz návrh komunikace mezi modulem a službou na obrázku \ref{fig:smart_city_config_dashboard_communication}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/smart_city_config_dashboard_communication.pdf}
        \caption[Sekvenční diagram komunikace s~konfigurační službou]{Sekvenční diagram navržené komunikace mezi modulem dashboardu a konfigurační službou. Modul dashboardu je odstíněn od logiky uzamykání obsahu.}
        \label{fig:smart_city_config_dashboard_communication}
\end{figure}

V~rámci této práce bude konkrétně implementováno zobrazení pro konfiguraci rozmístění indikátorů a karet v~modulu dashboardu. Momentálně je umístění těchto položek dáno jejich pořadím v~polích vracených službami skupiny \uv{dashboard-provider}, poskytovanými různými aplikačními moduly. Jejich datové modely reprezentují typy\\\texttt{LgmcGDashboardIndicatorModel} a \texttt{LgmcGDashboardCardModel}. Oba typy je potřeba rozšířit o~unikátní identifikátor, podle kterého bude možné sledovat konfiguraci umístění konkrétního widgetu, která bude součástí konfigurace dashboardu. Samotné vykreslení GUI pro přemisťování karet s~funkcí \textit{drag and drop} obstará externí knihovna \textit{Gridster2}\footnote{\url{https://github.com/tiberiuzuld/angular-gridster2/tree/master}}. Viz sekce \ref{section:design_gui} s~návrhem uživatelského rozhraní na obrázku \ref{fig:design_mockup3}.


\section{Uživatelské rozhraní}\label{section:design_gui}
Podobně jako v~momentálním řešení, bude rozhraní vykreslováno pomocí proprietárních komponent ze skupiny \texttt{lgmc-g} pro zachování vizuální identity aplikace. Celkově bude obecné konfigurační GUI podobné Součkovu řešení, ovšem některé ovládací i vizuální prvky byly pozměněny aby lépe odpovídaly struktuře a využití nových metamodelů, viz skicy na obrázcích \ref{fig:design_mockup1} a \ref{fig:design_mockup2} a jejich popisky. Dále je na obrázku \ref{fig:design_mockup3} skica speciálního konfiguračního zobrazení pro dashboard. Červeně jsou popisky uvnitř skicy a modrý efekt znázorňuje místo stisku před přechodem do následující obrazovky.

Na všech těchto zobrazeních, na které bude možné aplikovat časovaný zámek, bude v~případě uzamčení vykresleno tlačítko \uv{Aktualizovat} jako neklikatelné s~náležitou informací o~této skutečnosti, viz návrh na obrázku \ref{fig:design_mockup4}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.9\textwidth]{obrazky-figures/smart_city_config_mockup4.pdf}
        \caption[Widget s~informací o~uzamčeném zdroji]{Příklad widgetu informujícího uživatele, že momentální konfigurační položky jsou uzamčeny.}
        \label{fig:design_mockup4}
\end{figure}


\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.9\textwidth]{obrazky-figures/smart_city_config_mockup1.pdf}
        \caption[Skica vykreslení složených položek v~konfiguračním GUI]
        {Podvětve aktuálního uzlu budou ve výchozí konfiguraci zobrazeny jako záznamy v~tabulce. Zanořit se do hlubší větve bude možné proklikem řádku.}
        \label{fig:design_mockup1}
\end{figure}

\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.9\textwidth]{obrazky-figures/smart_city_config_mockup2.pdf}
        \caption[Skica vykreslení kombinovaných položek v~konfiguračním GUI]
        {První záložka, pojmenovaná podle \texttt{title} aktuálního uzlu, bude obsahovat jeho listy a podvětve. Některé podvětve mohou volitelně být vykresleny jako další záložky s~vlastním vykreslením jejich listů a podvětví, což bude řízeno novým parametrem \texttt{displayAtParentLevel} v~metamodelu. Proklikem na řádek opět dojde k~zanoření.}
        \label{fig:design_mockup2}
\end{figure}

\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.9\textwidth]{obrazky-figures/smart_city_config_mockup3.pdf}
        \caption[Skica speciálního konfiguračního zobrazení dashboardu]{Skica speciálního konfiguračního zobrazení vykreslovaného v~modulu \texttt{lgmc-gui-dashboard}. Vyreslení implementuje a obstarává \texttt{lgmc-gui-dashboard}, ovšem využívá služeb nového konfiguračního modulu pro načítání a ukládání konfigurací, kontrolu zámků apod. Uživatel s~příslušnou \textit{accessForm} bude schopen si vybrat, zda editovat globální konfiguraci či konfiguraci specifickou pro něj. Interaktivní GUI s~funkcí drag and drop bude vykresleno s~pomocí externí knihovny Gridster2.}
        \label{fig:design_mockup3}
\end{figure}



\chapter{Implementace}\label{chapter:implementation}
Tato kapitola se věnuje implementaci navrženého řešení pomocí konkrétních technologií, nástrojů a algoritmů. Součástí popisu implementace jsou charakteristiky konkrétních postupů pro vývoj navržených změn ale i obeznámení s~různými problémy a úskalími, které v~rámci tohoto vývoje vyvstaly, a jejich řešením.\\Jako první kapitola v~sekci \ref{section:app_data_model_extension} popisuje implementaci potřebných rozšíření datového modelu, poté sestavení aplikační služby pro manipulaci s~konfiguracemi v~sekci \ref{section:configuration_api}, následuje implementace GUI pro obecné konfigurace v~sekci \ref{section:gui_config_module} a nakonec je popsán vývoj konfiguračního zobrazení v~modulu dashboardu \textbf{ve spolupráci s~Ondřejem Darmopilem} v~sekci \ref{section:special_dashboard_config_gui}.

\section{Rozšíření datového modelu aplikace}\label{section:app_data_model_extension}
Pro rozšíření datového modelu v~souladu s~návrhem je nutné zasáhnout do aplik. modulu \texttt{lgmc-platform-model}, který shromažďuje téměř veškeré definice typů a rozhraní související s~aplikační konfigurací. Datový model je nutné rozšířit o~definici metamodelu, časového zámku a jejich přidružených typů a poté je nutné dosavadní model provázat s~těmito typy.

Jak je uvedeno v~návrhu v~sekci \ref{section:metamodels}, nový typ \textbf{\texttt{LgmcMetaConfig}} bude obsahovat atributy \texttt{label}, \texttt{icon}, \texttt{permissions} a \texttt{children}. Jedná se o~položky primitivních datových typů, kromě \texttt{children} -- zde je nutné využít vlastnosti kompilátoru TypeScript, která dovoluje definici rekurzivního typu a navíc se musí jednat o~násobnou položku s~unikátními klíči:
\begin{center}
\begin{BVerbatim}
children?: {
    [child: string]: LgmcMetaConfig;
};
\end{BVerbatim}
\end{center}
Typ \texttt{LgmcConfigTimedLock}, reprezentující časový zámek, bude držet položky \texttt{userId} a \texttt{timestamp} typu \texttt{Date}, přičemž bude nutné ošetřit její serializaci a deserializaci při komunikaci s~databází. 

\subsection*{Provázání se stávajícím modelem}
Byl zvolen přístup sloučení položek s~metamodelem a časovým zámkem do společného typu \texttt{LgmcConfigurable}, což jasně značí záměr umožnit konfiguraci položky. O~tento typ budou konkrétně rozšířeny definice typů \texttt{LgmcAppConfig}, modelující celkovou konfiguraci aplikace, a \texttt{LgmcModuleConfig}, modelující konfiguraci konkrétního modulu, viz sekce \ref{section:logimic_and_smart_city} a \ref{section:metamodels}. Tento postup jasně vymezuje granularitu uzamykání konfigurací a definicí metamodelů na dvě úrovně -- na úrovni samotné aplikace a na úrovni jednotlivých modulů, což také kopíruje adresářovou strukturu stávajících modelů.

\subsection*{Definice metamodelů}
Jak vyplynulo z~analýzy, je potřebné decentralizovat definice metamodelů tak, aby adresářová struktura s~metamodely kopírovala adresářovou strukturu modelů, tedy datových typů aplikační konfigurace. Z~tohoto důvodu, a pomocí vhodně zvolené granularity definic metamodelů, budou metamodely definovány v~$1+n$ lokacích, kde $n$ značí počet aplikačních modulů. Konstanta $1$ odkazuje na metamodel nejvyšší konfigurační úrovně, tedy položky aplikačního jádra jako jsou \texttt{api}, \texttt{auth} či \texttt{router}. Pro přehlednost budou i tyto položky umístěny do samostatných souborů a sloučeny do koherentního objektu v~souboru \texttt{app.metamodel.ts}. Díky řádné definici a zjednodušení datového typu metamodelů bude nadále definování dodatečných metamodelů snažší a méně náchylné na chybovost, i protože lze využít funkcí IDE a kompilátoru pro typové nápovědy a kontroly. 



\section{Aplikační služba pro manipulaci s~konfiguracemi}\label{section:configuration_api}
V~druhé fázi implementace je nutné zkonstruovat aplikační službu (dále jen \textit{služba}), která bude modulům aplikace schopna poskytovat služby jako jsou načítání a přetěžování konfigurací či ukládání změn konfigurace do perzistentního úložiště. Tato služba bude tvořit základy pro vystavění požadovaných konfiguračních rozhraní a především odstíní zbytek aplikace od komunikace s~databází, logiky přetěžování konfigurací a podobně. Dále, jelikož je celkový přepis aplikace na novou konfigurační architekturu rámcově nemožný, je nutné zachovat co nejvyšší možnou míru zpětné kompatibility s~existujícími aplikačními moduly.

\subsection*{Definice rozhraní služby}\label{subsection:api_interface}
Přestože se práce vyhýbá označování služby jako \uv{API}, jelikož její rozhraní nebude mít přesah mimo samotnou aplikaci, je nutné její rozhraní řádně definovat. První fáze návrhu bude vycházet z~požadavků na poskytované služby z~pohledu modulů, které budou s~konfiguracemi manipulovat. Následuje výčet metod, které budou v~rámci rozhraní implementovány ve tvaru \uv{název metody (parametry) -- popis metody}.

\begin{itemize}
    \item \texttt{getAppConfig(includeUserConfig)} -- vrátí momentálně používanou konfiguraci, kdy \texttt{includeUserConfig} určuje, zda uvažovat přetížení uživatelskou konfigurací.

    \item \texttt{getModuleConfig(moduleId, includeUserConfig)} -- funkčně podobná předchozí metodě, ovšem izoluje konfiguraci konkrétního modulu, což pomůže dále odstínit moduly od logiky procházení konfigurací.
    
    \item \texttt{updateGlobalAppConfig(newGlobalAppConfig, toDb)},\\\texttt{updateUserAppConfig(newMergedAppConfig, toDb)} -- aktualizují globální konfiguraci či její uživatelské přetížení, kde \texttt{new\dots AppConfig} je kompletní objekt typu \texttt{LgmcAppConfig}, čili extrakce rozdílů konfigurací bude vyřešena v~rámci těchto metod a ostatní moduly budou tak při jejich používání od této logiky odstíněny. Příznak \texttt{toDb} řídí, zda novou konfiguraci nahrát do databáze, či zda pouze aktualizovat vnitřní stav aplikace.

    \item \texttt{updateModuleConfig(moduleId, newModuleConfig, global, toDb)} -- funkčně podobná předchozím metodám, specializovaná pro konfiguraci konkrétního modulu.

    \item \texttt{isModuleConfigTimeLocked(moduleId)} -- zjistí, zda se v~konfiguraci modulu nachází časovaný zámek zamezující přihlášenému uživateli jeho konfiguraci. Měla by uvažovat situaci, kdy na modul, dle jeho metamodelu, nelze aplikovat časovaný zámek, aby toto nemusel ošetřovat programátor samotného modulu.

    \item \texttt{timeLockModuleConfig(moduleId)},\\\texttt{timeUnlockModuleConfig(moduleId)} -- metody pro uzamčení či odemčení konfigurace modulu
\end{itemize}

\subsection*{Datový model služby}
Aby bylo možné navržené rozhraní implementovat, je nutné správně určit datový model perzistentního úložiště i vnitřního stavu služby. Jelikož Souček již ve své práci \cite{soucek:2023} navrhl schéma rozšíření databáze pro ukládání konfigurací, proběhla revize tohoto návrhu. Po domluvě s~vývojáři Logimic jsme se rozhodli schéma zredukovat ze $3$ tabulek ($1$ s~konfiguracemi a $2$ vazební) na $2$ tabulky -- globální a uživatelská konfigurace.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/api_db_model.pdf}
        \caption[Schéma datového modelu databáze]{Schéma rozšíření datového modelu databáze, kde tučné písmo značí primární klíče a \texttt{mn\_user\_id} odkazuje na záznam v~tabulce \texttt{mn\_user}. Tato vazba ošetří integritu databáze, kdy není žádoucí uchovávat konfiguraci neexistujícího uživatele. Záznamy v~\texttt{config} budou nadále typu řetězce formátovaného jako JSON, což umožní ukládat konfigurace arbitrárního tvaru bez navyšování komplexity schématu.}
        \label{fig:api_db_model}
\end{figure}

\noindent
Konfiguraci je nutné vázat na konkrétní aplikaci, protože provozní architektura Smart City uvažuje provoz několika instancí aplikace pod jedinou databází. Z~tohoto důvodu byl pro zachování integrity dat rozšířen typ \texttt{LgmcApiConfig} o~položku \texttt{appId}, aby bylo možné deterministicky sledovat a nastavit aplikační ID konkrétní instance. Tato hodnota tedy bude předávána v~komunikaci prostřednictvím RESTového API. 

Co se týče datového modelu z~hlediska vnitřního stavu aplikace, je nutné rozlišovat $3$ různé úrovně konfigurace -- statickou, dynamickou globální a dynamickou uživatelskou. To umožní tyto úrovně separátně sledovat, odvozovat rozdíly mezi němi atd.

\subsection*{Implementace služby}
Datový model služby i metody jejího rozhraní budou implementovány jako rozšíření služby \texttt{lgmc-platform-app-state.service}, která je již napříč aplikací používaná pro získávání konfigurace. V~momentálním stavu existuje ve službě atribut \texttt{appConfig} typu \texttt{BehaviorSubject} z~knihovny RxJs\footnote{\url{https://rxjs.dev}}, který umožňuje \textit{pozorovatelům} odebírat jeho aktuální hodnotu v~souladu s~návrhovým vzorem \textit{Observer}. Tato architektura bude zachována, ovšem \texttt{appConfig} bude roztříštěn do $3$
 atributů \texttt{globalAppConfig}, \texttt{userAppConfig} a \texttt{mergedAppConfig}, kde \texttt{mergedAppConfig} bude sám o~sobě \textit{pozorovatel} dvou zbývajících částí pomocí metody \texttt{combineLatest} knihovny RxJs.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/api_observables.pdf}
        \caption[Schéma architektury získávání konfigurace v~aplikační službě]{Schéma architektury ukládání konfigurace ve službě. Komponenty, které doposud pozorovaly stav \texttt{appConfig} budou přepojeny na \texttt{mergedAppConfig}, jelikož ten v~nové architektuře představuje kompletní konfiguraci. Ve výjimečných případech může komponenta naslouchat \texttt{globalAppConfig}, pokud to případ užití vyžaduje.}
        \label{fig:api_observables}
\end{figure}

Obrázek \ref{fig:api_observables}, vyobrazuje jak budou existující \textit{pozorovatelé} přepojeni. Z~hlediska relace s~navrženým datovým modelem bude statická konfigurace reprezentována již existujícím atributem \texttt{appConfig} stávající služby \texttt{LgmcAppConfigManager}\footnote{\texttt{LgmcAppConfigManager} se mimo jiné stará o~přetěžování statické konfigurace statickou konfigurací prostředí.}, dynamická globální konfigurace nově vzniklým \texttt{globalAppConfig} a dynamická uživatelská konfigurace atributem \texttt{userAppConfig}. Přetěžování konfigurace objekty z~databáze bude v~metodách svého rozhraní a v~hodně \texttt{mergedAppConfig} orchestrovat nově vznikající služba. V~komponentách, které pouze jednorázově získávaly hodnou \texttt{appConfig} aniž by se přihlašovali k~jeho pozorování, bude k~tomuto účelu sloužit nová metoda \texttt{getAppConfig}, viz definice rozhraní služby výše.

Při přechodu na tuto architekturu byla sice zachována vysoká míra zpětné kompatibility, ovšem nastala jedna výjimka v~komponentě \texttt{app}, která v~následující pasáži pozorovala stav jedné \textit{observable} (\texttt{userAvatar}) a při její změně četla hodnotu druhé \textit{observable} (\texttt{mergedAppConfig}):
\begin{center}
\begin{BVerbatim}
this.appStateService.userAvatar.subscribe((userAvatar: string) => {
    if (this.mergedAppConfig?.layout.useAvatar == false)
      this.userAvatar = "";
    else
      this.userAvatar = userAvatar;
});
\end{BVerbatim}
\end{center}
Jelikož nová architektura vyvolává přetěžování konfigurace v~různých časech (asynchronní dotazy na databázi apod.), tento přístup selhal jelikož docházelo mezi dvěma \textit{observables} k~chybě souběhu. Problém byl vyřešen použitím již zmíněné metody \texttt{combineLatest}, která vyvolá událost při události v~jedné z~obou \textit{observables}. Při analýze kódu nebyly nalezeny další instance podobných chyb.

Klíčový okamžik běhu aplikace je její inicializace. Vývojový diagram na obrázku \ref{fig:api_init_flow_diagram} znázorňuje proces inicializace z~hlediska konfigurace, který probíhá po korektní inicializaci všech \textit{observables}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/api_init_flow_diagram.pdf}
        \caption[Vývojový diagram inicializace]{Vývojový diagram procesu inicializace z~hlediska konfigurací. Načtení statické konfigurace před kritickými operacemi jako autentizace je nutná jelikož obsahuje nastavení kritických částí aplikačního jádra (API a podobně).}
        \label{fig:api_init_flow_diagram}
\end{figure}

Jelikož budou bloky stahování a slučování dynamických konfigurací opětovně volané z~ostatních metod rozhraní (především \texttt{isModuleConfigTimeLocked}), budou pro lepší znovupoužitelnost kódu zabaleny do jednotné interní metody \texttt{pullDbConfigs}. Právě ta bude zajišťovat přetěžování konfigurace aktuálními konfiguracemi z~databáze a jelikož z~hlediska optimalizace není optimální do databáze ukládat celkovou konfiguraci ale pouze objekt reprezentující její změny, musí tato metoda využít mechanismus podobný stávající metodě \texttt{mergeDeep}, která je již využívaná k~přetěžování statické konfigurace konfigurací prostředí. Tento mechanismus již patřičně upravil a implementoval Souček v~separátní metodě. V~rámci této práce bude metoda přesunuta do \texttt{lgmc-platform-utils} a upravena, aby přetěžovaný objekt nebyl upravován \textit{in situ}\footnote{Přetěžování \textit{in situ} bylo způsobeno vlastnostmi jazyka JavaScript, které způsobují že objekty jsou předávány referencí a pro potlačení tohoto chování je nutné implementovat vlastní algoritmus pro hloubkové kopírování objektů}.

Před přenosem konfigurace zpět do databáze (např. \texttt{updateGlobalAppConfig}) je kvůli již zmíněné optimalizaci nutné extrahovat rozdíly mezi dvěma konfiguračními objekty. Podobně jako metodu pro slučování změn, i tuto metodu již implementoval Souček a v~tomto případě bude pouze přesunuta do \texttt{lgmc-platform-utils}, pro zachování sémantické struktury aplikace. V~rámci nové architektury je však nutné definovat které konfigurační objekty budou použity pro extrakci globálního či uživatelského přetížení. Budeme-li uvažovat různé konfigurace jako množiny dvojic $(kl\acute{\iota}\breve{c}, hodnota)$, lze rozdíly mezi němi vyjádřit jako rozdíly množin. S~těmito předpoklady lze odvodit následující výrazy, kdy výsledná přetížení na levé straně výrazů budou nahrávána do databáze:
% \begin{figure}[hbt]
% \renewcommand{\figurename}{Příklad}
% \centering
% \begin{align}
% \text{globální přetížení konfigurace} &= \text{statická konfigurace} - \text{nová globální konfigurace} \nonumber \\
% \text{uživatelské přetížení konfigurace} &= \text{globální konfigurace} - \text{nová sloučená konfigurace} \nonumber
% \end{align}
% \caption[Vyjádření vztahů mezi konfiguracemi]{Vyjádření vztahů mezi konfiguracemi a jejich přetíženími. Přetížení na levé straně budou nahrávána do databáze.}
% \end{figure}\label{fig:dynamic_configuration_overloads_relations}
\begin{equation}
\begin{aligned}
\text{globální přetížení konfigurace} &= \text{statická konfigurace} - \text{nová globální konfigurace} \\
\text{uživatelské přetížení konfigurace} &= \text{globální konfigurace} - \text{nová sloučená konfigurace}
\nonumber
\end{aligned}
\end{equation}

\newpage
Návratovou hodnotu \texttt{isModuleConfigTimeLocked} lze vyjádřit následující pravdivostní hodnotou: \texttt{konfig. modulu je uzamykatelná \&\& modul má platný zámek \&\&\\přihlášený uživatel není majitelem zámku}. V~reálné implementaci je potřeba ještě před těmito kontrolami provolat \texttt{pullDbConfigs} pro získání aktuálních zámků a zkontrolovat zda je předané id modulu platné. Zjišťování platnosti zámku bude řešeno porovnáním délky života zámku s~konstantou platnosti zámku. Tato konstanta bude součástí konfigurace nového modulu s~konfiguračním GUI. Uzamčení či odemčení konfigurace spočívá pouze ve vytvoření či smazání zámku z~konfigurace modulu a aktualizaci konfigurace přes \texttt{update\dots AppConfig}. Zda je modul uzamykatelný bude určeno \textbf{novým volitelným parametrem metamodelu \texttt{isTimeLockable}}, jehož výchozí hodnota bude uvažována jako \texttt{false}.

Nakonec, jelikož je metamodel součástí konfigurace, je při nahrávání konfigurací do databáze nutné metamodel z~objektu vypustit. To bude ošetřeno přímo v~metodách\\\texttt{update\dots AppConfig} implementací vlastního parametru \texttt{replacer} metody \texttt{JSON.strigify}.

\section{Modul obecného konfiguračního rozhraní}\label{section:gui_config_module}
V~třetí fázi implementace bude vyhotoven nový modul pro vizualizaci zanořené aplikační konfigurace a vykreslení formulářů pro její editaci.

\subsection*{Datový model modulu}
Na definici datového modelu modulu se dá pohlížet dvěma optikami -- na jeho konfigurační model, či stavové proměnné jeho komponent. Z~hlediska modelu budou definovány následující atributy:
\begin{itemize}
    \item \texttt{timedLockDuration} -- již zmiňovaná konstanta určující životnost zámku v~sekundách. Operativně bude nastavena na $30\,s$.
    \item \texttt{globalConfigScopeAccessForm} -- identifikace \textit{accessForm}, určující zda má uživatel oprávnění upravovat globální přetížení konfigurace.
    \item \texttt{implicitMetamodelAccessForm} -- identifikace \textit{accessForm}, určující zda má uživatel oprávnění upravovat konfiguraci na základě implicitního metamodelu, což zahrnuje oprávnění zapisovat i do nezapisovatelných položek.
\end{itemize}
V~souvislosti s~modelem bude také co nejpodrobněji definován metamodel nového modulu, jako jedna z~předloh pro tvorbu jiných metamodelů pro ostatní programátory společnosti.

\subsection*{Architektura modulu}
Přestože je návrh uživatelského rozhraní inspirován Součkovou implementací modulu, bude se jeho architektura, kvůli změnám v~koncepci metamodelů a ve snaze řešení lépe generalizovat, výrazně 
lišit. Klíčový rozdíl spočívá v~dělení modulu na komponenty -- nový modul nebude rozdělen na komponenty specifické pro různé části konfigurace. Naopak, celá konfigurace bude uvažována jako stromová struktura a vznikne jediná obecná komponenta pro procházení této struktury a úpravu aktuální větve skrze formulář. Pro specifické zobrazení některých větví bude rozšířen metamodel o~specifické atributy, na které bude při vykreslování brán zřetel. Jak z~návrhu vyplývá, hlavní kategorizace uzlů spočívá v~dělení na větve (které budou vykresleny jako řádek tabulky či záložka akordeonu) a listy (které budou vykresleny jako položky formuláře). Součástí šablony komponenty tedy budou $2$ metabloky pro vykreslování jednoho z~těchto typů uzlů, které budou dynamicky instanciovány v~reakci na změnu vnitřního stavu komponenty, viz obrázek \ref{fig:gui_architecture}.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/gui_architecture.pdf}
        \caption[Architektura komponenty konfiguračních rozhraní]{Architektura komponenty modulu konfiguračních rozhraní. Zpětná vazba bude realizována obsluhou \textit{událostí} frameworku Angular\footnotemark.}
        \label{fig:gui_architecture}
\end{figure}
\footnotetext{\url{https://angular.io/guide/event-binding-concepts}}

Z~hlediska řízení šablony bude dogma tvořeno právě interní reprezentací metamodelu. Například v~případě impl. metamodelů bude tato reprezentace vycházet i z~podoby konfigurace, ovšem komunikačním kanálem od komponenty do šablony bude přenášen pouze daný metamodel v~obecné podobě.

\subsection*{Datový model komponenty}
Stavové proměnné, které se budou během života komponenty měnit a na jejichž hodnotu musí reagovat jiné části komponenty, budou opět implementovány jako \texttt{BehaviorSubjects}. Z~těch budou nejvýznamnější následující proměnné:

\begin{itemize}
    \item \texttt{currMetamodelPath} -- cesta zanoření do aktuálního uzlu metamodelu\,/\,konfigurace, reprezentována polem klíčů.

    \item \texttt{currConfigScope} -- aktuálně zvolená úrověň konfigurace (globální\,/\,/uživatelská). Výchozí hodnota bude uživatelská úroveň a uživatel bez příslušné \textit{acessForm} ji nebude moci změnit.
\end{itemize}

Mimo to je potřeba sledovat aktuální metamodel dekonstruovaný do formy vhodné pro šablonu. Z~toho důvodu vzniknou nové typy \texttt{LgmcMetaConfigBranch} a \texttt{LgmcMetaConfigLeaf}, oba rozšiřující \texttt{LgmcMetaConfig}. Protože jsou oba typy specificky určené pro použití v~novém modulu, budou definované v~rámci něj. Následují rozšiřující atributy pomocného typu \texttt{LgmcMetaConfigLeaf}:
\newpage
\begin{itemize}
    \item \texttt{metamodelPath} -- cesta v~metamodelu jako pole klíčů.

    \item \texttt{config} -- reference objektu s~konfigurací pro navázání hodnoty s~formulářovým polem.

    \item \texttt{isBool} -- příznak, zda pole vykreslit jako \textit{checkbox}.
    
    \item \texttt{children} -- přetížení typu \texttt{children}, aby list nemohl obsahovat potomky.
    
    \item \texttt{metamodelPathSerialized} -- serializovaná cesta, bude sloužit pro identifikaci polí v~HTML.
    
    \item \texttt{valid} -- příznak, zda je aktuální hodnota \texttt{config} validní, bude řídit vykreslení chybové hlášky.
\end{itemize}
\noindent
Atributy \texttt{LgmcMetaConfigBranch} budou \texttt{metamodelPath} a \texttt{childrenSplit}, který bude dále obsahovat potomkové větve a listy. Význam \texttt{childrenSplit} spočívá ve vykreslování větví, které se mají vykreslit jako záložka akordeonu. U~těch je totiž potřeba sledovat její potomky kategorizované na větve a listy, podobně jako u~momentální větve.

Aby nedošlo k~zásahu do konfigurace aplikace kvůli předávání objektů jako referencí, bude uchovávána lokální kopie uživatelské konfigurace, aktualizovaná při její změně (docíleno odebíráním \textit{observable}).

\subsection*{Implementace modulu}
Při inicializaci komponenty, tj. v~jejím konstruktoru, musí v~první řadě být inicializovány všechny \textit{observables} a jejich odběratelé. Následuje seznam použitých \textit{observables} a účel jejich odběru:
\begin{itemize}
    \item \texttt{appStateService.appInitialized} -- příznak stavu inicializace aplikace. Při jeho sepnutí bude načten metamodel a inicializována \texttt{currMetamodelPath}.
    
    \item \texttt{appStateService.mergedAppConfig} -- atribut služby implementované v~sekci \ref{section:configuration_api}. Při jeho změně budou vytvořeny nové kopie konfigurací a provedena kontrola uživatelových oprávnění.

    \item \texttt{currMetamodelPath}, \texttt{configScope} -- jejich změna značí potřebu přepočítat vnitřní reprezentaci metamodelu pro vykreslování.
\end{itemize}

Vyhodnocení vnitřní reprezentace metamodelu pro vykreslování bude obstarávat metoda \texttt{prepareMetamodelForRender}. Ta projde všemi potomky aktuálního uzlu metamodelu, kategorizuje je na větve a listy a vyhodnotí atributy a příznaky nutné pro vykreslení, jako např. \texttt{displayUpdateBtn}\footnote{Tlačítko \uv{Aktualizovat} bude zobrazeno v~případě, že bude při průchodu nalezen alespoň jeden zapisovatelný list.}. Další povinností této metody bude vykreslit \textit{navigační breadcrumbs} podle aktuální cesty metamodelu. O~samotné vykreslení se stará dedikovaná komponenta na úrovni aplikace, ovšem její stav lze řídit skrze \texttt{appStateService}, mimo jiné metodou \texttt{addNavigationItem}. Ta přijímá argument popisující \textit{navigační breadcrumb} mimo jiné jeho popiskem, ikonou a cestou. Aby fungoval proklik z~navigačních položek, vyžaduje navigační komponenta specifikování celé cesty v~položce. Jelikož \texttt{prepareMetamodelFormRender} zná pouze cestu v~metamodelu, je nutné derivovat zdrojovou cestu v~aplikaci z~konfigurace nového modulu. Ta bude vyhodnocena v~obsluze události \texttt{appStateService.mergedAppConfig} a ukládána do proměnné \texttt{originRoute}, ke které bude cesta v~metamodelu připojována.

Dále vyvstal problém s~nastavením popisku z~metamodelu, kdy při implicitním metamodelu, či nesprávně definovaném popisku, se komponenta navigace pokoušela popisek automaticky přeložit pomocí \texttt{TranslatePipe} a objektu ve formátu \textit{i18n}\footnote{\url{https://angular.io/guide/i18n-overview}}. V~tomto případě mohla hodnota popisku náhodně ukazovat na cestu uvnitř \textit{i18n} objektu, viz obrázek \ref{fig:gui_label_translate_bug}.
\begin{figure}[hbt]
        \centering
        \includegraphics[width=1\textwidth]{obrazky-figures/gui_label_translate_bug.png}
        \caption[Chyba s~překladem popisků v~navigaci]{Chyba s~překladem popisků v~navigaci. \uv{[object Object]} naznačuje, že se šablona pokouší serializovat složený objekt vrácený \texttt{TranslatePipe}.}
        \label{fig:gui_label_translate_bug}
\end{figure}
\noindent
Řešení je otestovat datový typ výsledku překladu a v~případě, že se nejedná o~řetězec, podstrčit popisek rozšířený o~\textit{leading whitespace}, což potlačí jeho překlad. Jelikož se tento problém opakovaně objevoval i v~šabloně implementované komponenty, byla pro modul implementována speciální \texttt{SafeLabelTranslatePipe} nahrazující \texttt{TranslatePipe}, která funguje na stejném principu (kontrola datového typu překladu).

U~načtení metamodelu při incializaci aplikace nepostačuje pouze jeho přečtení z~konfig. aplikace ale je nutné také propojit oddělené články metamodelu a v~případě potřeby vygenerovat implic. metamodel.

\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.87\textwidth]{obrazky-figures/gui_link_metamodels.pdf}
        \caption[Vizualizace propojení metamodelů]{Vizualizace propojení článků metamodelů.}

        \begin{tabular}{r@{: }l r@{: }l}
        $1$ & nalezení prvního listu & $2$ & nalezení článku v~konfiguraci\\
        $3$& vytvoření vazby & $4$& pokračování v~průchodu listy 
        \end{tabular}
        
        \label{fig:gui_link_metamodels}
\end{figure}
\noindent
Operace nové metody \texttt{linkMetamodels}, znázorněná na obrázku \ref{fig:gui_link_metamodels}, spočívá v~\textbf{prohledávání listů metamodelu do hloubky}, kdy podle dané cesty otestuje přítomnost článku v~konfiguraci a případně vytvoří novou vazbu v~lokální kopii metamodelu, viz legenda. Na druhou stranu, generování implicitního metamodelu, vyvolávané po \texttt{linkMetamodels}, vyžaduje navštívení každého uzlu. Operace nad každým uzlem zahrnují nastavení uzlu na \textit{zapisovatelný} a vygenerování jeho chybějících potomků podle tvaru uzlu v~konfiguraci. Zde také proběhne derivace chybějících popisků.

Potvrzení a validace formuláře opět spočívá v~obsluze Angular události (zde proklik potvrzovacího tlačítka). Po aktualizaci konfigurace sice nová služba notifikuje všechny odběratele, je však nad rámec této práce verifikovat, zda budou všechny moduly a komponenty korektně reagovat na tuto změnu. Proto, po domluvě s~vývojáři, byla implementována aktualizace stránky přes API prohlížeče, což inherentně vyvolá opětovnou inicializaci aplikace. To přineslo další problém, kdy hláška o~úspěchu byla zobrazena příliš krátce. Řešení je nastavit příznak o~zobrazení hlášky v~\textit{sessionStorage} a jeho kontrola a smazání při inicializaci komponenty.

\section{Speciální konfigurační zobrazení pro dashboard}\label{section:special_dashboard_config_gui}
V~této sekci bude popisována i spolupráce s~Darmopilem, který v~rámci své práce \cite{darmopil:2024} mimo jiné implementoval komponentu \texttt{lgmc-g-grid}.

\subsection*{Rozhraní komponenty dynamické mřížky}
Darmopil při implementaci komponenty mřížky pomocí knihovny Gridster2, definoval a implementoval datový model komponenty včetně typu generického widgetu. Programatické ovládání komponenty skrze úpravu jejích vnitřních stavových proměnných je však, z~pohledu programátora používajícího tuto komponentu, nekomfortní a docházelo by k~duplikaci kódu. Z~toho důvodu bylo ve spolupráci s~Darmopilem navrženo a implementováno rozhraní komponenty v~podobě veřejných metod:

\begin{itemize}
    \item \texttt{startEditMode()} -- spustí editační mód.

    \item \texttt{stopEditMode(saveConfig)} -- zruší editační mód a dle příznaku \texttt{saveConfig} nedělá nic, nebo vrátí konfiguraci do stavu před editačním módem.

    \item \texttt{getConfig(), setConfig()} -- přístupové metody ke konfiguraci mřížky.
\end{itemize}

\subsection*{Datový model dashboardu}
Perzistentní ukládání a sledování rozmístění widgetů na mřížce vyžaduje rozšíření konfiguračního modelu modulu dashboardu. Do položky \texttt{pages.dashboard} tedy přibyde atribut \texttt{gridWidgets}, což bude pole záznamů typu zkonstruovaného množinovými operacemi nad typem pro generický widget mřížky -- vynecháním atributu \texttt{component}, což je dynamicky předávaná třída vnitřní komponenty widgetu a přídáním \texttt{id}, dle kterého budou widgety identifikovány. Zápis v~jazyce TypeScript vypadá následovně:
\begin{center}
\begin{BVerbatim}
type LgmcGGridWidgetConfig = Omit<LgmcGGridInput<any>, 'component'> & {
  id: string
}
\end{BVerbatim}
\end{center}
\noindent
Tato metoda konstrukce typu zajistí, že při změně v~základovém typu bude nová definice dynamicky vyhodnocena.

Dále je potřeba zajistit správnou identifikaci widgetů, takže v~tzv. \textit{providers}, což jsou služby ostatních GUI modulů poskytující widgety pro dashboard, bude konfigurace widgetů doplněna o~unikátní identifikátory.

\subsection*{Implementace zobrazení v~dashboardu}
Podobně jako v~sekci \ref{section:gui_config_module}, i zde zásadní roli bude hrát nová konfig. služba. V~podstatě se opět jedná o~obsluhu událostí šablony a provolávání metod \texttt{lgmc-g-grid} či služby. Jediná komplikace spočívá v~rozlišení globálního\,/\,uživatelského přetížení konfigurace. Zde je, v~případě spuštění editace v~globálním režimu, nutné namapovat na widgety jejich globální konfiguraci a při zrušení editace vyčkat na vyhodnocení nové konfigurace a zpět namapovat widgety dle uživatelského přetížení této konfigurace.



\chapter{Testování}\label{chapter:testing}
Testování, jakožto nejvýznamnější součást kontroly kvality při vývoji software, pomáhá redukovat náklady spojené s~chybovým chováním v~produkčním prostředí. Tato kapitola se zabývá koncepcí a výsledky autorských testů.

\section{Testovací prostředí}
Aby se testovací prostředí co nejvíce podobalo produkčnímu, byla použita technologie \textit{Docker} pro sestavení a spuštění instance webového serveru ve virtuálním stroji dle produkční konfigurace. Konkrétně se jedná o~Node.js verze 18 a Angular verze 13 běžící na distribuci \textit{Debian}. Instance serveru \textit{Nginx}  poskytuje zkompilované statické soubory webové aplikace přes \textit{HTTP}. Jediný významný rozdíl spočívá ve volbě statické aplikační konfigurace -- byla zvolena konfigurace ukazující na testovací koncové body API apod., aby nedošlo k~narušení produkčního prostředí.

\section{Testovací metoda}
Samotné testovací sady byly implementovány v~testovacím software Cypress\footnote{\url{https://www.cypress.io}}. Jedná se o~tzv. \textit{end-to-end testování}, tedy o~simulaci uživatelských interakcí s~aplikací či jejími komponentami a ověřování jejich výstupů.
\begin{figure}[hbt]
        \centering
        \includegraphics[width=0.84\textwidth]{obrazky-figures/testing_scenario_flow_diagram.pdf}
        \caption[Vývojový diagram testovacího scénáře]{Vývojový diagram průběhu testovacího scénáře. Blok \texttt{beforeEach} je automaticky vykonán před každým scénářem.}
        \label{fig:testing_scenario_flow_diagram}
\end{figure}
Obrázek \ref{fig:testing_scenario_flow_diagram} ilustruje navržený vývoj testovacího scénáře. Příhlášení uživatele a reset dynamických konfigurací jsou implementovány jako součást bloku \texttt{beforeEach} pro redukci duplicitního kódu.

Jelikož spouštění testovacích scénářů vyžaduje přístup k~objektu služby\\\texttt{lgmc-app-state.service}, který by za běžných okolností neměl být externím skriptům dostupný, byla do souboru \texttt{cypress.Dockerfile}\footnote{Soubor se specifikací sestavení obrazu virtuálního stroje technologie Docker.} přidána direktiva, která před sestavením projektu do zdrojového kódu podstrčí instrukci vystavující objekt služby. Dále podobným způsobem dojde i k~vystavení ID widgetů na dashboardu, čímž rozdíly s~produkčním prostředím končí.

\newpage
\section{Testovací scénáře}
Scénáře byly implementovány jako součásti testovacích sad, tedy v~samostatných souborech s~jejich specifikací. Každá sada by měla otestovat jeden aspekt rozšíření implementovaného v~kapitole \ref{chapter:implementation}.

\subsection*{Sada \texttt{app-state-service}}
Sada otestuje nové rozhraní rozšířené služby pro manipulacemi s~konfiguracemi.
\begin{itemize}
    \item Výchozí konfigurace -- výchozí konfigurace bez přetížení vrácená \texttt{appConfig} by se měla shodovat se statickou konfigurací.
    
    \item Nastavení a získání globální konfigurace -- po provolání \texttt{updateGlobalAppConfig} by se změna měla projevit do globální i uživatelské konfigurace vrácené \texttt{getAppConfig}.
    
    \item Nastavení a získání uživatelské konfigurace -- po provolání \texttt{updateUserAppConfig} by se změna měla projevit do i uživatelské konfigurace vrácené \texttt{getAppConfig} ale ne do globální konfigurace.
    
    \item Nastavení a získání globální konfigurace modulu -- po provolání\\\texttt{updateGlobalModuleConfig} by se změna měla projevit do globální i uživatelské konfigurace vrácené \texttt{getModuleConfig}.
    
    \item Nastavení a získání uživatelské konfigurace modulu -- po provolání\\\texttt{updateUserModuleConfig} by se změna měla projevit do i uživatelské konfigurace vrácené \texttt{getModuleConfig} ale ne do globální konfigurace.
    
    \item Časované zámky -- ve výchozí konfiguraci by měla \texttt{isModuleConfigTimeLocked} vracet \texttt{false}. Po provolání \texttt{timeLockModuleConfig} by se v~konfiguraci modulu měl nacházet zámek, ovšem \texttt{isModuleConfigTimeLocked} by měla nadále vracet \texttt{false} jelikož je uživatel majitel zámku. Po provolání \texttt{timeUnlockModuleConfig} by se v~konfiguraci modulu zámek opět neměl nacházet.
\end{itemize}

\newpage
\subsection*{Sada \texttt{gui-configs}}
Sada otestuje nové grafické rozhraní pro manipulaci s~obecnými konfiguracemi.
\begin{itemize}
    \item Nastavení názvu záložky pro uživatele -- po změně názvu záložky (datová cesta\\\texttt{labels}\,\textrightarrow\,\texttt{tabTitle}) v~uživatelské konfiguraci, by měla záložka mít nový název.
    \item Deaktivace avataru pro uživatele -- po deaktivaci už. avataru v~postranní nabídce (datová cesta \texttt{layout}\,\textrightarrow\,\texttt{userAvatar}) v~uživatelské konfiguraci, by se avatar neměl zobrazovat.
    \item Deaktivace avataru globálně -- po deaktivaci už. avataru v~postranní nabídce v~globální konfiguraci, by se avatar neměl zobrazovat a v~uživatelské konfiguraci by měla vykreslená hodnota reflektovat tuto změnu, jelikož nedošlo k~uživatelskému přetížení.
    \item Deaktivace avataru globálně a přetížení pro uživatele -- Po deaktivaci už. avataru v~postranní nabídce v~globální konfiguraci a přetížení (jeho aktivaci) v~uživatelské konfiguraci by se avatar měl opět zobrazovat.
    \item Navigace z~URL -- po navštívení GUI se specifikovanou datovou cestou v~URL by se mělo rozhraní vykreslit na této cestě.
    \item Validace položky -- pokud má položka v~metamodelu definovaný validátor, měla by se při jeho neuspokojení zobrazit chybová hláška a potvrzení formuláře by nemělo být možné. Po zadání uspokojivé hodnoty by se hláška zobrazovat neměla a potvrzení by mělo být opět možné.
\end{itemize}

\subsection*{Sada \texttt{gui-dashboard}}
Sada ostestuje nové grafické rozhraní pro konfiguraci rozložení widgetů na dashboardu.
\begin{itemize}
    \item Změna rozložení globálně -- po změně rozložení widgetů v~globální konfiguraci by se změna měla projevit v~momentálním zobrazení i v~zobrazení po opětovné inicializaci.
    \item Změna rozložení pro uživatele -- po změně rozložení widgetů v~uživatelské konfiguraci by se změna měla projevit v~momentálním zobrazení i v~zobrazení po opětovné inicializaci.
    \item Zrušení změn -- po změně rozložení widgetů a kliknutí na tlačítko \uv{Zrušit} by se rozložení mělo vrátit do původního stavu.
\end{itemize}

\section{Výsledky testování}
Po vyhodnocení automatizovaných testů se ukázaly jako úspěšné všechny kromě \uv{Nastavení názvu záložky pro uživatele}. Ta byla inicializována, spolu s~citlivými službami, při inicializaci jádra ještě před získáním konfiguračních přetížení z~databáze. Na základě toho proběhla dodatečná refaktorizace umožňující nekritickým částem jádra se inicializovat po získání dynamického přetížení konfigurace.

Funkcionalita a implementace byly demonstrovány vývojářům a vedení firmy. Nakonec jsem, s~ohledem na pozitivní zpětnou vazbu, zhotovil videoukázky sloužící jako průvodce novými rozhraními pro klienty a zároveň jako marketingový materiál použitelný při nabídce tohoto rozšíření.

%Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nunc auctor. Phasellus rhoncus. Aenean fermentum risus id tortor. Mauris elementum mauris vitae tortor.


\chapter{Závěr}\label{chapter:conclusion}
Cílem této práce bylo ve spolupráci s~firmou Logimic, s.r.o. navrhnout a implementovat rozšíření umožňující dynamickou konfiguraci webové aplikace platformy Smart City. Rožšíření mělo zredukovat čas a úsilí vývojářů strávené laděním statických konfigurací pro jednotlivé klienty a zároveň mělo běžným uživatelům přinést nové možnosti přizpůsobení rozhraní v~uživatelsky přívětivé formě. Celkový záměr tedy byl delegovat konfigurační úkony na klienta a jeho uživatele, což by společnosti umožnilo působit spíše v~roli techické podpory.

K~pochopení problematiky chytrých měst a požadavků uživatelů platforem pro jejich správu, bylo nejprve nutné nastudovat současné aplikace internetu věcí a také charakteristiky a principy populárních redakčních systémů. Pro zachování architektonické integrity aplikace a jejích částí, bylo nutné podrobně nastudovat a pochopit její koncepci a seznámit se s~technologiemi na kterých staví.

Navržené rozšíření reflektuje modulární architekturu aplikace a nabylo podoby rozšíření aplikačních služeb pro manipulacemi s~konfiguracemi a nového aplikačního modulu s~obecným uživatelským rozhraním pro přetěžování konfigurací. Na straně perzistentního úložiště došlo ke zjednodušení datového modelu a na klientské straně byl datový model náležitě redefinován bez nutnosti redefinovat API mezi těmito částmi. Zároveň byl rekonceptualizován modul úvodního dashboardu a jeho \textit{providers} tak, aby s~využitím nové aplikační služby a GUI komponenty vytvořené v~rámci Darmopilovy práce \cite{darmopil:2024}, bylo možné konfigurovat rozložení jeho widgetů uživatelsky přívětivou formou.

Metamodely, poprvé představené v~Součkově práci \cite{soucek:2023}, které obsahují metadata o~konfiguračních objektech, byly přepracovány tak, aby jejich tvorba byla méně náročná a náchylná na chybovost. Zároveň jejich nová implementace lépe kopíruje adresářovou i datovou strukturu aplikace. Jelikož je však jejich definice nevyhnutelně časově náročná a vyžaduje opět zásah do statické konfigurace, byl implementován koncept tzv. implicitních metamodelů. Ty umožní administrátorům s~odpovídajícími znalostmi a oprávněními ihned po nasazení využívat plný potenciál nového GUI pro dynamické přetěžování konfigurací.

Po úspěšných testech s~uživateli bude rozšíření nasazeno v~produkčním prostředí, což vývojářům umožní soustředit se také na další jeho využití, jako mohou být konfigurace uživatelských stylů. Takové změny by vyžadovaly zásahy do datového modelu aplikace, ovšem implementace samotného rozšíření je dostatečně generická, aby se dokázalo na tyto případné změny automaticky adaptovat. Prozatím jeho nasazení přinese úspory v~nákladech na vývojářskou práci spojenou s~úpravami konfigurací a přínosy pro klienty v~podobě zkrácené doby mezi požadavkem na změnu konfigurace a její realizací. Jeho potenciál, jako nástroje pro přizpůsobování uživatelského rozhraní, lze dále rozšiřovat úpravou stávajících modulů s~použitím nové aplikační služby s~generickým rozhraním.
\vspace*{-7mm}