Refine
Document Type
- Master's Thesis (4)
- Bachelor Thesis (3)
Language
- German (7)
Has Fulltext
- yes (7)
Is part of the Bibliography
- no (7)
Keywords
Institute
Insbesondere aufgrund der Zugehörigkeit zum sehr aktuellen und viel betrachteten Thema Machine Learning ist die genetische Programmierung mit ihren vielseitigen Anwendungsmöglichkeiten ein sehr interessantes Gebiet. Wie in allen Forschungsschwerpunkten gibt es auch hier viele Ansätze die standardmäßige Vorgehensweise weiter zu verbessern – einer dieser Ansätze ist die Verwendung von Subroutinen. Diese könnten in diesem Kontext auch als Methoden, Funktionen oder ähnliches bezeichnet werden und bedeuten, dass vom Algorithmus neben dem eigentlichen Programm auch wiederverwendbare Folgen von Anweisungen entwickelt werden, die über einen Bezeichner an beliebigen Stellen verwendet werden können. Hierfür gibt es bereits diverse Konzepte, die in Tests sehr gute Ergebnisse erzielt haben und eine Verbesserung gegenüber der standardmäßigen genetischen Programmierung ohne Subroutinen erreichen konnten. Diese Tests fanden allerdings immer in sehr spezialisierten Testumgebungen statt. Besonders interessant sind allerdings solche Systeme zur genetischen Programmierung, die (theoretisch) beliebige Probleme lösen kann, da sie für eine Vielzahl von Problemstellungen verwendet werden können.
Das Ziel dieser Arbeit ist es, zu untersuchen, ob und inwiefern die Verwendung von Subroutinen auch in einem solchen allgemeinen System zur genetischen Programmierung, das theoretisch dazu in der Lage ist, beliebige Probleme zu lösen, möglich und sinnvoll ist.
Vergleich von nativer App- und Cross-Platform-Entwicklung (Facebook React Native und Google Flutter)
(2020)
Die Entwicklung mobiler Applikationen für iOS und Android ist in der Regel mit viel Arbeit verbunden, da man für beide Plattformen gezwungenermaßen unterschiedlichen Quelltext schreiben muss. Abhilfe für dieses Problem schaffen Cross-Platform-Frameworks wie React Native von Facebook oder Flutter von Google. Anhand dieser Frameworks lassen sich Apps für beide Plattformen mit nur einer Codebase entwickeln. Eine kritische Stelle und oft gebrauchtes Kontra-Argument gegen die Entwicklung mit Cross-Platform-Frameworks ist die Hardwarenähe der nativen Applikationen, an welcher es den Frameworks vermeintlich mangelt. Doch wie ist der Stand der Dinge im Jahr 2020? Können Cross-Platform-Frameworks inzwischen performant und einfach auf Hardwarekomponenten zugreifen und machen damit die mühsame, native Entwicklung für iOS und Android vor allem in Anbetracht der Entwicklung von größerer Enterprise-Software obsolet?
Dieser Frage wird in dieser Arbeit nachgegangen und generell überprüft wie tauglich die Cross-Platform-Entwicklung ist. Nach dem Lesen dieser Bachelorarbeit sollte entschieden werden können, ob Cross-Platform-Frameworks für das Anwendungsproblem des Lesers geeignet sind. Um die Forschungsfrage zu beantworten, wurden je zwei Applikationen im Rahmen einer Fallstudie für je iOS und Android entwickelt, damit geprüft werden konnte, wie förderlich die zuvor genannten Frameworks sind. Der Fokus der Arbeit liegt also auf der Güte bzw. dem heutigen Stand der Cross-Platform-Entwicklung, vor allem im Bezug auf die Benutzung von Hardwarekomponenten bzw. betriebssystemspezifischen Diensten (Bluetooth, Kamera, etc.).
Die Ergebnisse der Fallstudie zeigen, dass es stets auf den Kontext und die Komplexität der zu realisierenden Anwendung ankommt inwiefern Cross-Platform-Frameworks verwendet werden können. In simplen Anwendungsfällen können Frameworks meist zu einer erheblichen Kostenminimierung und Zeitersparnis führen, wohingegen bei komplexeren Anwendungen relativ schnell Grenzen und starke Abhängigkeiten erreicht werden.
Die Arbeit untersucht die Anwendung von maschinellem Lernen zur Erkennung von Aktivitäten von Schiffen anhand von AIS-Signalen. Das Automatic Identification System (AIS) wird von Schiffen genutzt, um Informationen über ihren Status in regelmäßigen Intervallen zu übertragen. Auf Basis der Daten wurden mithilfe von Machine Learning-Algorithmen aus der Gruppe der überwachten Klassifikationsalgorithmen Modelle gelernt, die in der Lage sind zu erkennen, welcher Aktivität ein Schiff zu einem Zeitpunkt nachgeht.
Da das erfolgreiche Lernen eines Modells von einer sorgfältigen Datenvorbereitung abhängt, wurden verschiedene Verfahren zur Datenvorbereitung verwendet. Anschließend wurden verschiedene Algorithmen eingesetzt, darunter der Random Forest und k-NN, um Modelle zu lernen.
Die Ergebnisse zeigen, dass die Aktivitäten mit einer Genauigkeit von bis zu 99% erkannt werden konnten, wenn in der Datenvorbereitung geeignete Verfahren gewählt wurden.
Das Bedürfnis Daten in Echtzeit zu analysieren und auf Ereignisse zu reagieren, ist innerhalb aller Branchen in den letzten Jahren stark gestiegen. Als die Analysetechnik für Echtzeitdatenströme hat sich das Complex Event Processing (CEP) durchgesetzt. Mithilfe von Regeln lassen sich kausale, temporale und räumliche Zusammenhänge von Ereignissen definieren und durch eine CEP-Engine evaluieren. Die Konstruktion von Regeln hat sich dabei als einschränkende Faktor von CEP herausgestellt. Greedy4Cep ist ein algorithmischer Ansatz zur automatisierten Erstellung von CEP-Regeln anhand eines historischen Datenstromes.
Zusammen mit der Microservice-Bewegung werden immer häufiger synchrone Request-Response-Schnittstellen nach dem REST-Paradigma entwickelt, um Service-Landschaften zu integrieren. Die Einfachheit des Paradigmas verleitet viele Organisationen, nahezu die komplette Interprozesskommunikation ihres Ökosystems über diese Art von Schnittstelle abzuwickeln – nicht ohne Konsequenzen.
Diese Arbeit entwickelt Ansätze, wie die Integrationsprobleme, die bei übermäßiger Verwendung von REST entstehen, mithilfe von Event-Driven Architecture gelöst werden können, ohne den Status quo dieser Organisationen außer Acht zu lassen. Dafür werden der gegenwärtige Zustand der Integrationsmuster und eingesetzten Infrastruktur von Event-Driven Architecture kritisiert und Kriterien erarbeitet, die pragmatische und zugängliche Integrationsansätze erfüllen müssen. Um die Einführungskosten gering zu halten, wird eine Middleware entwickelt, die in bestehende REST-Schnittstellen eingesetzt werden kann und auf Basis der API-Aufrufe Events generiert. Darauf aufbauend werden vier Integrationsmuster entwickelt, die eine schrittweise Transformation zu Event-Driven Microservices ermöglichen. Um die Zugänglichkeit der Eventing-Infrastruktur zu erhöhen, wird außerdem wird die Standardisierung der Event-Struktur durch die CloudEvents-Spezifikation vorgeschlagen. Um die Zugänglichkeit weiter zu erhöhen, erfolgt die Kommunikation der Services nicht direkt mit dem Event-Broker, sondern über Proxies, die die Events per HTTP annehmen oder ausspielen. Um die Transparenz über den Datenfluss im System zu wahren, werden alle Produzenten und Konsumenten werden mitsamt ihrer Events durch den Beschreibungsstandard AsyncAPI dokumentiert.
Nach einer Validierung dieser Ansätze mithilfe eines Prototyps kommt diese Arbeit zu der Erkenntnis, dass der Einsatz der entwickelten Middleware für alle Organisationen sinnvoll ist, die bereits viele REST-Schnittstellen im Einsatz haben. Die Standardisierung der Event-Struktur und des Event-Protokolls mittels CloudEvents und HTTP-Proxies sowie die Dokumentation durch AsyncAPI empfiehlt sich auch unabhängig des Status quo für alle Organisationen, die Event-Driven Microservices entwickeln möchten.
Evaluierung und konzeptioneller Vergleich der Complex Event Processing Engine Siddhi anhand Esper
(2018)
Das schnelle Verarbeiten großer Datenmengen ist mittlerweile ein wesentlicher Bestandteil in vielen Wirtschaftszweigen, wie zum Beispiel der Finanz- und der Logistikbranche, und somit auch ein wichtiger Erfolgsindikator. Dabei ist es wichtig, dass eingehende Datenströme aus einer Vielzahl von verschiedenen Quellen (z.B. Sensoren oder Geschäftsprozessen) nicht auf langer Zeit persistiert, sondern schnellstmöglich analysiert und auf diese entsprechend reagiert wird. Diese Anforderung wird mithilfe der Softwaretechnologie Complex Event Processing (CEP) umgesetzt. Die eintreffenden Daten eines Datenstroms werden in CEP als Ereignisse bezeichnet, die eine Zustandsänderung des Systems repräsentieren.
Eines der Hauptziele von CEP ist es, aus einfachen Ereignissen aggregierte, d.h. komplexe Ereignisse einer höheren Abstraktionsebene zu erzeugen, indem Berechnungen und Korrelationen mit anderen Ereignissen durchgeführt werden oder auch Muster in Ereignisströmen erkannt werden um beispielsweise Auffälligkeiten wie Kreditkartenbetrug aufzuspüren. Der Gebrauch von CEP erfordert entsprechende Komponenten, die auf Ereignisse reagieren und diese weiter behandeln. Als Kernkomponente werden in verteilten Systemen sogenannte CEP Engines eingesetzt, die Ereignismuster in den Datenströmen erkennen. CEP Engines nutzen dabei eine Ereignisanfragesprache, sodass der Benutzer eine Ereignisregel definiert, die permanent Ereignisse nach der festgelegten Bedingung auswertet. Im Laufe der letzten Jahre hat sich eine große Reihe an verfügbaren CEP Engines von unterschiedlichen großen Softwareherstellern wie Oracle, TIBCO, IBM oder SAP angesammelt, sodass die Entscheidung für eine passende CEP Engine für ein verteiltes System schwerfällt. In dieser Arbeit wird die Open-Source CEP Engine namens Siddhi vorgestellt, die als leichtgewichtige und leistungsstarke Engine mit zahlreichen Erweiterungen zur Verarbeitung von Ereignissen veröffentlicht wurde. Das Ziel der Arbeit war dabei, Siddhi auf potenzielle Fähigkeiten zu untersuchen und mithilfe von konzeptionellen sowie technischen Kriterien zu vergleichen und zu evaluieren. Um Siddhi anhand der aufgestellten Kriterien sinnvoll zu bewerten, wurde die etablierte CEP Engine Esper als direkter Vergleichskandidat herangezogen. Des Weiteren wurden beide CEP Engine mit einer selbst erdachten Fallstudie umgesetzt, die eine "Gesundheitsüberwachung" simulieren soll. Am Ende der Arbeit wurde die Bewertung des Vergleichs zwischen Siddhi und Esper tabellarisch zusammengefasst und eine anschließende Beurteilung mithilfe des resultierenden Ergebnis formuliert, wann die Verwendung der CEP Engine Siddhi für empfehlenswert erscheint.