Hoch hinaus…<\/h2>\n\n\n\n\n\n\n\n
Bevor wir uns \u00fcber die Architektur Gedanken machen konnten, musste zuerst einmal eine Anwendungsidee her. Wir haben uns hier f\u00fcr eine Elevation API entschieden. Aber was ist denn eine Elevation API? Eine Elevation API ist eine API, die einem zu einem durch L\u00e4ngen- und Breitengrad definierten Punk der Erdoberfl\u00e4che die H\u00f6he des entsprechenden Punkts \u00fcber normal Null ausgibt. (Z.B. hat der Punkt mit den Koordinaten 48.742275\u00b0 Nord, 9.101177\u00b0 Ost (Haupteingang der HdM) die H\u00f6he 459 m. Derartige H\u00f6heninformationen werden f\u00fcr viele Anwendungen ben\u00f6tigt. Man kann sich die H\u00f6he eines Punktes auch einfach in Google Earth anzeigen lassen, indem man mit der Maus \u00fcber einen Punkt f\u00e4hrt. Die H\u00f6he wird dann unten rechts angezeigt.<\/p>\n\n\n\n Wie kamen wir also nun auf die Idee, unsere eigene Elevation API zu entwickeln? Nun, wenn man mit Google Earth arbeitet, bekommt man hier recht schnell ein Problem. Denn w\u00e4hrend man sich die H\u00f6heninformationen in Google Earth selbst problemlos anzeigen lassen kann, werden sie nicht exportiert. Das hei\u00dft, wenn man z.B. einen Pfad in Google Earth definiert und dann f\u00fcr die weitere Verwendung in einer anderen Anwendung exportiert, werden alle Punkte mit der H\u00f6he 0m ausgegeben (Gleichzeitig bietet Google eine eigene [kostenpflichtige] Elevation API an. Ein Schelm, wer b\u00f6ses dabei denkt…\ud83d\ude42). Wer also H\u00f6heninformationen f\u00fcr seine Anwendung braucht, muss sich diese auf anderem Wege beschaffen. Daf\u00fcr kann man z.B. auf kostenlose Elevation APIs wie OpenTopoData<\/a> zur\u00fcckgreifen. Dieses Konzept hatte uns also neugierig gemacht, sodass wir uns an die Entwicklung unserer eigenen Elevation API gemacht haben…<\/p>\n\n\n\n Nachdem die Idee f\u00fcr eine Anwendung nun feststand, war die erste gr\u00f6\u00dfere technische Entscheidung, welche Plattform wir f\u00fcr das Backend benutzen wollten. Hier haben wir uns recht schnell f\u00fcr ASP.NET Core und C# entschieden, da wir bereits Erfahrung mit C# (und teilweise auch mit ASP.NET Core) hatten. Hier spielte also eher Bequemlichkeit, als technische Aspekte eine Rolle. Ein Fehler, der uns sp\u00e4ter an einer Stelle noch geh\u00f6rig Kopfschmerzen bereiten sollte. F\u00fcrs Erste entwickelten wir aber munter darauf los…<\/p>\n\n\n\n An dieser Stelle machten wir uns zu Nutze, dass Visual Studio (unsere IDE) bereits Vorlagen f\u00fcr Konfigurationen enth\u00e4lt, um die Anwendung in einem Docker Container zu hosten. Wir mussten also nur die entsprechende Vorlage bei der Projekterstellung ausw\u00e4hlen und Visual Studio erledigte den Rest (erzeugt z.B. das Dockerfile). Es gibt hier sogar die M\u00f6glichkeit, bei jedem App-Start auszuw\u00e4hlen, ob man die Anwendung im Container oder doch lieber nativ auf dem Host ausf\u00fchren will. Mehr Flexibilit\u00e4t kann man sich also nicht w\u00fcnschen. Allerdings hat das, wie so oft, wenn einem die IDE Arbeit abnimmt, auch den Nachteil, dass man, wenn man mit der Materie (in diesem Fall Docker) noch nicht so vertraut ist, nicht unbedingt alles versteht, was das unter der Haube passiert, sodass man dann, wenn man etwas konfigurieren m\u00f6chte, erst Nachforschungen anstellen muss, wie das funktioniert. Das ist zwar heutzutage (aufgrund von stackoverflow.com und co.) recht einfach. Dennoch sollte man sich idealerweise, bevor man mit solchen Presets arbeitet, grundlegend in die Materie einarbeiten, um die eigene Anwendung nachher besser zu verstehen und Zeit bei der Entwicklung zu sparen.<\/p>\n\n\n\n Die grunds\u00e4tzliche Struktur des Backends ist recht simpel. Ein einfacher Web-Server (ASP-NET Core verwendet Kestrel) mit einem Endpunkt zur Abfrage von H\u00f6hendaten. Der Endpunkt unterst\u00fctzt sowohl GET-Requests, in welchen die Koordinaten in der URL stehen, also auch POST-Requests mit den Koordinaten im Body (JSON-Format). Dabei k\u00f6nnen auch mehrere Koordinaten gleichzeitig angefragt werden.<\/p>\n\n\n\n Beispiele f\u00fcr Anfragen: Als Ergebnis bekommt man (sowohl f\u00fcr GET-, als auch f\u00fcr POST-Reqests) im Erfolgsfall eine Antwort in der Form:<\/p>\n\n\n\n Im Fehlerfall wird ein entsprechender HTTP Statuscode zur\u00fcckgegeben.<\/p>\n\n\n\n F\u00fcr die Bearbeitung einer Anfrage werden auf dem Server grob zusammengefasst zwei wichtige Schritte ausgef\u00fchrt. Zun\u00e4chst wird die Anfrage eingelesen und in Koordinatenpunkte umgewandelt. Sollte dabei ein Fehler auftraten (z.B. wegen eine ung\u00fcltigen Anfrage [z.B. ein Buchstabe in einer Koordinate] oder falsche Formatierung]) wird direkt ein Fehler zur\u00fcckgegeben. Diese Pr\u00fcfung geschieht der Einfachheit halber (in unserer kleinen Anwendung) direkt im Elevation Controller (Controller sind in ASP.NET Core die Komponenten, die die HTTP-Anfragen erhalten und f\u00fcr das Senden der Antwort zust\u00e4ndig sind.) Ist die Umwandlung erfolgreich, werden zu den Koordinatenpunkten die H\u00f6heninformationen ermittelt. Sobald das geschehen ist, wird die Antwort gesendet.<\/p>\n\n\n\n Um die H\u00f6heninformationen f\u00fcr eine Koordinate zu gewinnen, brauchten wir zun\u00e4chst die Rohdaten. Also Dateien, in welchen die H\u00f6hendaten f\u00fcr einen bestimmten Bereich gespeichert waren. F\u00fcr solche Daten gibt es mehrerer Quellen (u.a. von der NASA). Wir entschieden uns f\u00fcr den EU-DEM v1.1-Datensatz von Copernicus<\/a>. Copernicus bietet als europ\u00e4isches Projekt Daten in besonders hoher Aufl\u00f6sung (25 m x 25 m, d. h. alle 25 Meter ein Messpunkt) f\u00fcr den Bereich Europa.<\/p>\n\n\n\n Die Daten wurden in Form von GeoTIFFs bereitgestellt. Das sind spezielle TIFF-Bilddateien, die die H\u00f6hendaten in den Pixeln enthalten und zus\u00e4tzlich bestimmte zus\u00e4tzliche Informationen wie z.B. das verwendete Koordinaten-Projektionssystem in den Metadaten. Wir haben also die Daten f\u00fcr den Bereich Deutschland heruntergeladen. Da diese Daten recht gro\u00df sind (ca. 8,3 GB nur f\u00fcr Deutschland), haben wir uns entschieden, uns f\u00fcr dieses Projekt auf Deutschland zu beschr\u00e4nken. (ACHTUNG: Das bedeutet, dass Anfragen f\u00fcr Koordinaten au\u00dferhalb Deutschlands (bzw. der Koordinatenbl\u00f6cke im Datensatz, welche Deutschland enthalten [E40N20 & E40N30 -> siehe Karte]) nicht funktionieren.)<\/em><\/strong><\/p>\n\n\n\n Als n\u00e4chsten, mussten wir den Zugriff auf die H\u00f6hendaten implementieren. Um die verschiedenen GeoTIFF-Dateien zu einem Raster zusammenzuf\u00fcgen und aus diesem, H\u00f6heninformationen abzufragen, entschieden wir uns, die bekannte Bibliothek GDAL<\/a> zu verwenden.<\/p>\n\n\n\n Bis hierher verlief die Entwicklung des Backends relativ fl\u00fcssig. Hier aber fiel uns jetzt die Wahl der Plattform auf die F\u00fc\u00dfe. GDAL ist f\u00fcr derartige Raster-Aufgaben, wie wir sie in unserer Anwendung brauchten, wie geschaffen und auch weit verbreitet. Allerdings handelt es sich bei GDAL um eine Python<\/strong>-Bibliothek. Die direkte Einbindung in unsere Anwendung war also nicht m\u00f6glich. Wir brauchten also einen .NET Core Port von GDAL. Wir entschieden uns f\u00fcr das Paket MaxRev.Gdal.Core<\/em>. <\/p>\n\n\n\n Die Implementierung der n\u00e4chsten ca. 20 Zeilen Code dauerte einige Stunden.<\/p>\n\n\n\n Im Grunde war das, was wir zu erreichen versuchten, nicht sehr kompliziert. Wir wollten – wie gesagt – die GeoTIFF-Daten in ein Raster zusammenf\u00fcgen und H\u00f6heninformationen daraus abfragen. Das l\u00e4sst sich mit GDAL in etwa 20 Zeilen Code realisieren. ABER: da wir nicht GDAL direkt, sondern einen Port verwendeten, wich die Klassen- und Methodennamen oft von der (dokumentierten) Originalversion von GDAL ab. Und da der von uns verwendete (aber auch alle anderen) GDAL-Port nicht sehr weit verbreitet ist, gab es auch kaum Hilfestellungen dazu im Internet (z.B. Foreneintr\u00e4ge). Erschwerend kam noch dazu, dass solche Ports oft unvollst\u00e4ndig sind und einige Funktionalit\u00e4ten des Originals nicht implementiert sind, was f\u00fcr noch mehr Verwirrung und Unsicherheit sorgte. Wir mussten uns also jede Zeile Code durch Probieren und aufw\u00e4ndige Internetrecherche hart erarbeiten. Wir haben sogar andere GDAL-Ports ausprobiert, die aber alle noch schlechter funktionierten.<\/p>\n\n\n\n Am Ende waren wir froh, dass wir funktionierenden Code zusammenbekommen hatten, der unsere Aufgabe erf\u00fcllte. W\u00fcrden wir unsere Anwendung jetzt allerdings erweitern und neue Funktionalit\u00e4t implementieren wollen, st\u00fcnden wir wieder vor dem gleichen Problem.<\/p>\n\n\n\n Ein weiteres Hindernis, das es zu bew\u00e4ltigen gab, war, dass der EU-DEM v1.1-Datensatz ein anderes Projektionssystem (ETRS89 \/ LAEA Europe), als das gew\u00f6hnliche L\u00e4ngen-\/Breitengrassystem (WGS 84) verwendet. Wir mussten also erst einen Weg finden, die vom Benutzer angefragten Koordinaten in L\u00e4ngen- und Breitengrad in Koordinaten im ETRS89 \/ LAEA Europe-System umzuwandeln. Auch hier hatten wir es wieder mit der selben Problematik wie bei GDAL zu tun. Es gab zwar einige Anleitungen im Internet, wie diese Koordinatenumrechnung zu bewerkstelligen war, jedoch bezog sich keine davon auf .NET Core und C#. Auch hier mussten wir uns am Ende wieder auf eine kleine Drittanbieter-Bibliothek (DotSpatial.Projections<\/em>) verlassen, wobei Dokumentation und Communityinhalte hier ebenso d\u00fcrftig waren, wie bei GDAL, sodass auch die Implementierung dieses Codes deutlich mehr Zeit in Anspruch nahm, als uns das lieb gewesen w\u00e4re.<\/p>\n\n\n\n Am Ende war es jedoch soweit, und wir hatten unsere funktionierende Anwendung. Jetzt mussten wir nur noch einen Weg finden, die H\u00f6hendaten (in Form der zwei GeoTIFF-Dateien und einer (von GDAL) generierten VRT-Rasteratei) in unserem Container zur Verf\u00fcgung zu stellen. Eine M\u00f6glichkeit w\u00e4re gewesen, die Dateien einfach in das Docker-Image zu packen. Da die Dateien aber, wie gesagt, mehrere GB gro\u00df waren, h\u00e4tte das das Image unn\u00f6tig aufgeblasen und unhandlich gemacht. Stattdessen entschieden wir uns, die Dateien auf dem Host zu speichern und den entsprechenden Ordner im Container zu mounten. Dies kann durch Angabe eines Parameters beim Start des Docker-Containers bewerkstelligt werden:<\/p>\n\n\n\n Dieser Parameter stellt den Ordner “D:\/elevation\/data” (hier beispielhaft der Ordner auf dem Host mit unseren Daten) im Container unter “\/app\/data” zur Verf\u00fcgung. Da wir aber in aller Regel den Container nicht selbst starteten, sondern, die IDE das f\u00fcr uns erledigt, mussten wir den Parameter noch in der .csproj-Datei des Projekts mit<\/p>\n\n\n\n festlegen.<\/p>\n\n\n\n ACHTUNG:<\/strong> Aufgrund der Dateigr\u00f6\u00dfe, sind die GeoTIFF-Dateien nicht im Repository enthalten und m\u00fcssen manuell heruntergeladen werden. Danach muss der Pfad zu den Dateien im Projekt angepasst werden, um es erfolgreich ausf\u00fchren zu k\u00f6nnen. Eine genauere Anleitung hierzu findet sich in der README-Datei im Repository des Backends.<\/p>\n\n\n\n Abschlie\u00dfend war das Backend noch zu testen. Dazu implementierten wir noch einige Unit Tests, sowohl f\u00fcr den Controller (hier wurde vor allem getestet, dass der Controller bei fehlerhaften Anfragen, entsprechende Fehlercodes zur\u00fcckgab), als auch f\u00fcr das Datenset (korrekte H\u00f6hendatenabfrage). Letzteres erwies sich aufgrund der Plattformproblematik erneut als z\u00e4her als gedacht. Um den GDAL-Port bei der Programmausf\u00fchrung zu initialisieren muss der Befehl<\/p>\n\n\n\n einmal ausgef\u00fchrt werden. Dieser Befehl steht in unserer Anwendung in der Startup.cs-Datei, welche beim Anwendungsstart ausgef\u00fchrt wird. Da Unit Tests jedoch eine eigene Ausf\u00fchrungskonfiguration haben und die Startup.cs-Datei nicht ausf\u00fchren, wurde der GDAL-Port zun\u00e4chst nicht initialisiert. Dies hatte zur Folge, dass das Datenset nicht initialisiert wurde und wir somit st\u00e4ndig eine NullPointer-Exception bekamen. Dies ist unserer Meinung nach schlechte Codequalit\u00e4t des Ports, da es hier keine Fehlermeldung gab, sondern einfach NULL als Wert f\u00fcr den Datensatz zur\u00fcckgeben wurde ohne irgendeine Kontextinformation, die die Fehlersuche erleichtert h\u00e4tte. Aufgrund der mangelnden Dokumentation hat die L\u00f6sungsfindung auch hier deutlich zeitaufw\u00e4ndiger als n\u00f6tig. Letztlich fanden wir die L\u00f6sung, und f\u00fcgten den Initialisierungsbefehl in die Tests ein. Danach bekamen wir korrekte Ergebnisse. Als Unit Test-Framework verwendeten wir xUnit.net.<\/p>\n\n\n\n Wir kommen zum n\u00e4chsten Puzzleteil des Projektes, dem Stresser.<\/p>\n\n\n\n Um erkennen zu k\u00f6nnen, welche Auswirkungen eine hohe Anzahl von Anfragen auf das System hat und wie wir dagegen vorgehen k\u00f6nnen, m\u00fcssen wir zuerst das System mit einer hohen Anzahl an Abfragen stressen. Man k\u00f6nnte hier fast von einer DDoS-Attacke sprechen. Allerdings m\u00fcssen wir nicht ganz so weit gehen und ein ganzes Botnetz f\u00fcr diesen Test zu erschaffen, das w\u00e4re dann doch etwas zu viel des guten. Welche Alternativen haben wir? Es geht darum, eine reproduzierbare Testumgebung f\u00fcr das Backend zu schaffen, um in einem realistischen Umfeld erkunden zu k\u00f6nnen, wie sich die Elevation API unter Last verh\u00e4lt. <\/p>\n\n\n\n Wir wollen nat\u00fcrlich nicht einfach mit irgendeiner beliebigen Sprache ein Programm schreiben, das in einem for-Loop sequenziell einige HTTP-Requests versendet. Wir wollen m\u00f6glichst schnell und unkompliziert unsere API mit hunderten oder auch hunderttausenden Anfragen m\u00f6glichst parallel stressen. Wir wollen m\u00f6glichst keinen Overhead. Einfach ein kleines Programm, das keine Framework-Infrastruktur um sich ben\u00f6tigt, um zu existieren. Nat\u00fcrlich wollen wir das Ganze konfigurieren k\u00f6nnen: Welche URL soll gestresst werden, wie h\u00e4ufig, mit welcher HTTP-Methode und welchem Body Inhalt. Am besten w\u00e4re dazu ein Web-Interface, um nicht bei jedem Ausf\u00fchren als erstes –help tippen zu m\u00fcssen.<\/p>\n\n\n\n Also sammeln wir mal die Anforderungen:<\/p>\n\n\n\n Bevor wir anfangen den Stresser zu bauen, m\u00fcssen wir entscheiden, welche Sprache wir w\u00e4hlen. In den Topf geworfen wurde .NET. Zwar bietet das Framework gute Performance, hat mir jedoch als Framework schon zu viel Overhead. Dazu kommt, dass wir keinerlei Erfahrung damit haben. JavaScript\/Node, war die zweite Option und bringt einiges mit, was hier hilfreich ist. Allerdings ist es nicht gerade f\u00fcr seine Geschwindigkeit oder Nebenl\u00e4ufigkeit bekannt. Entschieden haben wir uns letztendlich f\u00fcr GoLang. Die Idee kam daher, dass wir vor Jahren schon einmal in der Sprache entwickelt habe, aber seither keine Ber\u00fchrung mehr damit hatte. Was f\u00fcr Go spricht, ist, dass es mit Fokus auf Nebenl\u00e4ufigkeit entwickelt wurde. Die Standard-Bibliothek bringt alles mit, was wir ben\u00f6tigen. Au\u00dferdem kompilieren Go Programme zu einer einzigen kleinen Executable, in der alle Abh\u00e4ngigkeiten enthalten sind.<\/p>\n\n\n\n Also let’s Go. <\/p>\n\n\n\n Der Stresser besteht aus drei Komponenten:<\/p>\n\n\n\n Es gibt ein paar verschiedene M\u00f6glichkeiten, den Stresser in Go umzusetzen. Um herauszufinden, welche nun die Beste ist, haben wir verschiedene M\u00f6glichkeiten implementiert, die Performance gemessen (Zeit ben\u00f6tigt, um X Anfragen zu verschicken) und verglichen.<\/p>\n\n\n\n Die wesentlichen drei M\u00f6glichkeiten sind:<\/p>\n\n\n\n Um die Effizienz der verschiedenen M\u00f6glichkeiten zu messen, wurden zwei Metriken gemessen:<\/p>\n\n\n\n Das ganze Inkrementell auszuf\u00fchren d\u00fcrfte die einfachste M\u00f6glichkeit sein, ist aber wie man sich denken kann auch die ineffizienteste. Hierzu werden in einer Schleife eine Anfrage nach der n\u00e4chsten gesendet. Die Frage, ob es Performance-Unterschiede zwischen For-\/While-\/ oder anderen Schleifen gibt, ist obsolet, da Go nur eine Variante anbietet.<\/p>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/ElevationExample.png\")
<\/a>Das Backend<\/h2>\n\n\n\n
Die Plattform<\/h3>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/NET_Core_Logo.svg_-2.png\"){kind=logo}
<\/a><\/figure>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/Csharp_Logo-1.png\"){kind=logo}
<\/a><\/figure>\n<\/figure>\n\n\n\nEine gew\u00f6hnliche REST-API<\/h3>\n\n\n\n
GET:<\/strong> http:\/\/localhost:8080\/api\/elevation?coordinates=48.00,9.00;-12.34,-23.45
POST:<\/strong> localhost:8080\/api\/elevation
[Body]<\/em><\/p>\n\n\n\n[ \n {\n "latitude": 48,\n "longitude": 9 \n },\n { \n "latitude": 49.1,\n "longitude": 10.2\n }\n]<\/code><\/pre>\n\n\n\n[\n {\n "latitude": 48,\n "longitude": 9,\n "altitude": 739.7893850836467\n },\n {\n "latitude": 49.1,\n "longitude": 10.2,\n "altitude": 492.73202840246756\n }\n]<\/code><\/pre>\n\n\n\nDer Kern des Ganzen: die H\u00f6hendaten und ihre Verarbeitung<\/h3>\n\n\n\n
Das Datenset<\/h4>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/copernicus-1024x535.png\")
<\/a>GDAL…der Troublemaker<\/h4>\n\n\n\n
![\"\"\/](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/08\/gdalicon.png\")
Koordinate ist nicht gleich Koordinate<\/h4>\n\n\n\n
Enbindung der Daten in den Container<\/h4>\n\n\n\n
docker run <strong>--volume D:\/elevation\/data:\/app\/data:ro<\/strong><\/code><\/pre>\n\n\n\n<DockerfileRunArguments>-v "D:\/elevation\/data:\/app\/data:ro"<\/DockerfileRunArguments><\/code><\/pre>\n\n\n\nBackend-Unit Tests<\/h3>\n\n\n\n
GdalBase.ConfigureAll();<\/code><\/pre>\n\n\n\nZusammenfassung der Hindernisse und Erkenntnisse aus der Backend-Entwicklung<\/h3>\n\n\n\n
\n
Den Server stressen<\/h2>\n\n\n\n
Anforderungen<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/Zeichnung-2-1024x259.png\")
<\/a><\/figure>\n\n\n\nUmsetzung<\/h3>\n\n\n\n
\n
Um den Stresser zu konfigurieren, ben\u00f6tigen wir ein Web-Interface. Zwar ist es m\u00f6glich, das mittels Web-Templates<\/a> direkt in Go umzusetzen, aber was soll der Geiz. Wir erstellen das Web-Frontend mit React. Das ist zwar absolut Overkill, aber es geht nur darum m\u00f6glichst schnell und unkompliziert eine Weboberfl\u00e4che zu erstellen. In dieser Web-Oberfl\u00e4che k\u00f6nnen wir dann die definierten Parameter konfigurieren, den Stresser starten und das Resultat einsehen.<\/li>\n\n\n\n
Das mit React erstellte Frontend liefern wir mit einem Go Fileserver als statische Dateien aus. Dieser Go-Server fungiert au\u00dferdem als Proxy und startet den Stresser.<\/li>\n\n\n\n
Um den Stresser auch ohne Overhead verwenden zu k\u00f6nnen, wird er als zus\u00e4tzliches Go-Programm geschrieben, welches alle ben\u00f6tigten Parameter \u00fcber die Kommandozeile bekommt. So kann er einerseits \u00fcber das Web-Frontend gestartet werden, allerdings auch einfach \u00fcber die Kommandozeile, falls ben\u00f6tigt.
<\/li>\n<\/ol>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/stresser-frontend-1024x832.png\")
<\/a>\n
\n
\n
Inkrementell<\/h4>\n\n\n\n
![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/Untitled-Diagram-Page-2.drawio.png\")
<\/a><\/figure>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/Untitled-Diagram-Page-3.drawio.png\")
<\/a><\/figure>\n\n\n\n![\"\"](\"https:\/\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/02\/Untitled-Diagram-Page-4.drawio.png\")
<\/a><\/figure>\n\n\n\n