Home
Im folgendem Text werden wir euch durch unseren gesamten Projekt-Prozess führen und zeigen wo im Wiki weitere Ausführungen zu den einzelnen Meilensteinen zu finden sind.
Die Begründung für unsere Entscheidungen haben wir in diesem Stil festgehalten.
Um unser Projektidee zu finden, haben wir per Brainstorming mehrere Probleme aus unserem Alltag gesammelt und uns für eines entschieden. Zu diesem haben wir ein Problemszenario erstellt, bei dem wir uns auch schon damit beschäftigt haben, wie das System heißen soll und welche Grundfunktionalität es haben soll.
Unser Ziel war es einen Service zu bauen, den wir in unserem eigenen Alltag auch verwenden könnten.
Unter Berücksichtigung des Problemszenarios haben wir dann ein Domänenmodell aufgebaut, welches wir durch mehrere Iterationen des Domänenmodell konkretisiert haben.
Zu Beginn hatten wir noch den Wunsch die Route zu den nahegelegenen Einkaufsort (Locations) über unseren Service anzubieten. Wir haben uns aus Zeitgründen dafür entschieden uns lediglich auf das Matching von "wishes" zu konzentrieren.
Eine Vorgabe des Projektes war die Einbindung eines externen Webservices. Unsere Wahl ist auf Google Firebase gefallen. Vorher haben wir unsere mehrere alternative Webservices angeschaut und abgewägt, welche bei der Lösung des Problemszenarios helfen könnten. Mit dem Proof of Concept haben wir sichergestellt, dass Google Firebase grundlegend die Funktionalität mitbringt, die wir benötigen. Im Verlauf des Projektes haben wir jedoch festgestellt, dass wir Erweiterungen an der Implementierung des Services vornehmen müssen.
Wir haben uns auf darauf konzentriert nur einen Web Service zu nutzen damit es nicht den zeitlichen Rahmen für unser Projekt sprengt und wir uns auf die Umsetzung der REST Funktionalitäten fokussieren können.
Nachdem wir die Findung von Domänen und Web Service abgeschlossen hatten, haben wir die Modellierung der Ressourcen auf Basis von REST vorgenommen. Innerhalb der Umsetzung haben sich die Ressourcen (analog zum Domänenmodell) verändert, sodass wir mehrere Iterationen der Ressourcen bearbeitet haben.
Bei älteren Iterationen der Ressourcen hatten wir das Problem, dass unsere Verschachtelung von Recourcen zu granular war. Wir haben zum Beispiel für jeden "User" eines Event eine eigene "Wishlist" angelegt. So kam es zu folgender Domain: "events/(eventID)/wishlists/(wishlistID)". Wir haben die "Wishes" als Eintrag eines Arrays in der "Wishlist" gespeichert. So konnte man seine "wishlist" nur bearbeiten indem man die vorherige überschrieb. In den neueren Iterationen wurde jeder "wish" dann als eigenes Dokument in einer Collection geposted und konnte somit eigenständig bearbeitet werden. Zudem haben wir nur noch eine "wishlist" (wishes) für alle User und die Verlinkung zum User wird über ein Feld in dem Dokument gelöst, was die Länge der URIs ein wenig verkürzt.
Nun waren wir bereit uns Gedanken um die Architektur unseres Systemes zu machen. Wir setzten uns mit der Beispiel Architektur aus dem Vorlesungsmaterial auseinander und überlegten, wie wir in unserem System die Funktionsteilung gestallten könnten. Im Abschnitt Node Module haben wir aufgelistet, welche Node.js Module wir verwenden und wofür wir sie brauchen.
Wir haben uns dafür entschieden Firebase ausschließlich mit dem Dienstgeber in Verbindung zu setzen. Wir wollten die Aufgabenbereiche des Nutzers und Gebers klar trennen und ein Zugriff des Nutzers auf die Datenbank würde diese saubere Trennung lösen.
Die Rest Architektur war ein zentraler Punkt dieses Projektes. Aus diesem Grunde haben wir viel Zeit darin investiert unsere Architektur so REST-Konform wie möglich zu gestalten. Der mit Abstand meist diskutierteste Aspekt unserer Architektur war das Ausführen des Matching Algorithmus bzw. der Zeitpunkt, zu dem dieser Algorithmus ausgeführt werden sollte. Hierfür gab es im Grunde zwei Möglichkeiten: Ein Ausführen des Algorithmus bei einem GET auf die Ressource “Shoppinglist” oder das Ausführen des Algorithmus bei einem POST auf die Ressource “Shoppinglist”. Die Gegenüberstellung dieser beiden Varianten und die Begründung unserer finalen Entscheidung haben wir im Kapitel REST festgehalten.
Eine genaue Beschreibung unseres Matching Algorithmus ist hier zu finden. Wir haben uns nach der Definition für Anwendungslogik aus dem Medieninformatik Wiki der TH Köln gerichtet.
Desweiteren haben wir uns überlegt wie genau die JSONs, die an unsere REST Schnittstelle geschickt werden, aufgebaut seinen sollen. Dazu haben wir ein JSON Schema für das Erstellen von Wishes erstellt. Dies haben wir unter dem Kapitel Datenstrukturen festgehalten.
Außerdem haben wir überlegt, wie wir Publish und Subscribe mit Faye in unser System integrieren können.
Wir haben uns ebenfalls angeschaut wie man über Firebase Functions die Pub/Sub Thematik umsetzen könnte, haben dies aber fallen gelassen, da diese Funktion für Node.Js keine guten Möglichkeiten zum subscriben bietet.
Für die Vorstellung des Projektes war es unsere Aufgabe Use Cases zu definieren, die auf Basis des Problemszenarios mit dem System lösbar sind.
Abschließend haben wir ein Fazit und offene Punkte verfasst. Unsere Abschluss Präsentation für den 16.07.2018 ist hier zu finden.
Um unsere Änderungen im Code aus der Verbesserungsphase bis zum 30. August besser nachvollziehen zu können und den Betreuern diese besser aufzuzeigen, haben wir einen neuen Branch erstellt. Diesen haben wir in einem Pull Request in den Master geführt.
Wir haben die Arbeitsteilung in dieser Matrix festgehalten.
Um das System einzurichten folge bitte einfach dieser Anleitung.