Unser Projekt Protokoll
Wir haben uns auf dem Discord Server [zum Beitreten hier klicken] um 14:00 Uhr getroffen und uns erste Gedanken zur Projektidee gemacht. Dabei sind auch mehrere Ansätze entstanden, über die wir jedoch noch weiter diskutieren müssen.
Ohne weiteres Recherchieren kamen uns folgende APIs in den Sinn:
Um ein anfängliches Verständnis für APIs zu entwickeln wurden nach häufig genutzen APIs im Internet gesucht. Sie offenbarten einen ungefähren Blick auf die Möglichkeiten, die mit der Einbindung von APIs ins eigene Projekt möglich sind.
API-Suchmaschine: npmjs || Api List || ProgrammableWeb
- Currency Exchange API
- Deezer API
- Chicken Coop
- IMDb API
- Temp Mail API
- uNoGS API
- "Kochrezepte API" / Cocktail Db API
- Jokes API
- PokeAPI
- Minecraft API
- Dropbox API
- TheAudioDB
- TheMealDB
Die heutige Vorlesung hat unter anderem die Nutzerdaten, welche durch Drittmodule eventuell aufgezeichnet werden und zu schützen sind, behandelt. Daher wird nun primär nach Open Data Services gesucht. Zunächst muss die Domäne/Nutzungskontext erschlossen werden, welche mit einem Domänenmodell veranschaulicht werden muss, damit anhand dieser Darstellung benötigte APIs Dritter ausgewählt werden können.
Domäne/Problemraum: Von der Arbeit abschalten
--> Das grundlegende Ziel eines Systems: Es soll den Nutzer in der Domäne unterstützen und Problem/Teilprobleme lindern oder gar lösen.
Um die Domäne zu erfassen, wurde beschlossen, mithilfe von Figma zu erstellen. Dort sollen erste Entwürfe des Domänenmodells anhand der Analyse des Domänraums gemeinsam in den nächsten Tagen konzipiert werden.
Zielhierarchie:
- strategische Ziele: Ablenkung vom Alltag, Findungsübernahme von Entspannungsmitteln
- taktische Ziele: automatisiertes Zusammenstellen von passenden Komponenten, Freizeitaktivitäten, Stimmungsunterstützung
- operative Ziele: passende Kombination aus Cocktail & Musik
Use Case Instanz/Szenario:
-
Der gestresste Luther kommt von seinem Arbeitsplatz nach Hause und möchte nun einfach nur entspannen. Als Alternative zum klassischen "Feierabendbier" möchte er sich nun einen Cocktail genehmigen. Zur Entspannung zu Hause gehört auch die richtige Musik, um den Tag ausklingen zu lassen. Nach etlichen Aufrufen verschiedener Webseiten hat er endlich den Cocktail seiner Wahl gefunden und bemerkt, dass es nun schon recht spät geworden ist. Als Kompromiss schaltet Luther das Abendprogramm im Fernsehen an und setzt sich nach der Zubereitung des Cocktails auf das Sofa. Aktuell läuft eine Dokumentation über dubiose Unterwasserwelten im Atlantik. Dieses informative Thema ist Luther allerdings in der aktuellen Situation zu anstrengend, dennoch bemüht er sich nicht den Sender zu wechseln.
-
Besonders der kleine Barbetreiber Jürgen hat es nicht immer leicht, wenn es darum geht, die richtige Musik auszuwählen, die in seiner Kneipe/Bar laufen soll. Zurzeit nutzt er verschiedene Getränke je nach Saison. Jedoch würde er gerne flexibler zur Musik, die er gerade laufen lässt, gewisse Cocktails anbieten.
-
Endlich ist es soweit! Alice plant seit Wochen ihre Party zu ihrem 18. Geburtstag. Zutaten für Cocktails stehen bereit, wie auch eine Reihe an Knabberkram. Sogar ein Buffet wurde vorbereitet. Jedoch will ihr eine essentielle Komponente einfach nicht leicht fallen: die Wahl der Musik. Sie findet zwar viele Songs, welche ihr sehr zusprechen, aber wenn sie sich nähere Gedanken zu der Stimmung macht, welche die jeweiligen Songs verursachen, will ihr einfach kein passender Mix entstehen.
Eine erste Logo-Idee wurde erstellt, welche die grundlegenden Eigenschaften unserer Web API visualisieren soll.
Zunächst wurde das Logo und der zugehörige Banner unserer Web API überarbeitet.
Neben der Einholung eines Spotify-API-Keys für das anstehende Projekt wurde das Domänenmodell zur zuvor genannten Domäne finalisiert. Abrufbar ist das Modell auf der entsprechenden Wikiseite.
Zu Beginn wurde sich damit befasst, wie nun auf die Spotify Web API zugegriffen werden kann. Dafür wurde ein Developer Account beim besagten Anbieter erstellt und ein Key beantragt. Mit der zur Verfügung gestellten Dokumentation der Spotify API soll eine Anwendungslogik ähnlich einem Klassendiagramm erstellt werden und ein "proof of concept" einerseits über erstellte User Journeys und andererseits mit Codebeispielen die Möglichkeiten der Web API aufzeigen.
Danach wurden mithilfe des Domänenmodells Anwendungslogiken in Form von User Journeys formuliert, welche das entstehende System realisieren soll. Die Anwendungslogik wurde anhand von ersten Pseudocode modelliert und bedient sich an einem groben ersten Klassenmodell. Das Klassenmodell beschreibt dabei primär, wie die verschiedenen Klassen miteinander verbunden sind, und wann sie aufeinander zugreifen müssen. Dabei war das Wissen über die Spotify-API hilfreich, da wir beispielsweise gelernt haben, mit welchen Werten Spotify die Stimmung eines Songs beschreibt, und wir eine Idee erhalten konnten, wie die Kommunikation schlussendlich aussehen muss, und wie wir beispielsweise die Stimmung, mit der unser System arbeitet übersetzen in Werte, die für Spotify logisch sind.
Erste User Journeys wurden erstellt. Diese dienen dazu, chronologisch den Weg von einer Anfrage des Nutzers bis zum schlussendlichen Ergebnis darzustellen. So lässt sich einfach nachvollziehen, welche "Ebenen" des Systems bei welchen Schritten im Ablauf relevant werden. Schnittstellen zwischen Anwendungslogik und Datenbanken bzw. der Spotify-API werden deutlich. Die Bedeutung und der Nutzen der verwendeten Schnittstellen wird hervorgehoben.
Die User Journeys behandeln bis dato folgende Situationen:
1) Ein Nutzer stellt eine Anfrage mit einer angegebenen Stimmung an Beatdrinks, und erhält am Ende ein Cocktailrezept und Musik
2) Ein Nutzer hat bereits Rezept und Musik erhalten, doch etwas gefällt ihm nicht. Eine neue Anfrage mit anderen Präferenzen wird gestellt, und der Nutzer erhält schließlich eine neue Kombination.
Zunächst wurden weitere User Journeys erstellt, und die bereits vorhandenen nochmal überarbeitet.
Die neuen User Journeys behandeln folgende Situationen:
3) Ein Nutzer hat bereits Rezept und Musik erhalten, doch eine bestimmte Zutat des Cocktails gefällt ihm nicht (z.B. mag er kein Kokos). Er gibt an, welche Zutat unerwünscht ist, und erhält ein neues Rezept für einen Cocktail ohne diese Zutat. Das System merkt sich, welche Zutat unerwünscht ist.
4) Ein Nutzer gibt seine Präferenzen in spezifischeren Werten an; z.B. bestimmte Cocktail-Zutaten, bestimmte Musikrichtung,... und erhält ein Rezept und Musik, die auf diese Präferenzen zugeschnitten sind.
Anschließend wurde der Pseudocode weiter ausgearbeitet und an entsprechenden Stellen um weitere Funktionalitäten erweitert. Die User Journeys haben stark geholfen, Abläufe zu finden, welche im Pseudocode noch nicht repräsentiert waren. Außerdem wurden die erstellten Domänenmodelle und User Journeys im Git hinzugefügt und dokumentiert.
Um die Arbeitsaufteilung bis zum ersten Meilenstein festzuhalten, wurden gemeinsam mit Figma eine Arbeitsmatrix erstellt.
Bei der weiteren Besprechung wurde klar, dass die ürsprüngliche Aufteilung des proof-of-concept, der Anwendungslogik und des Pseudocodes fehlinterpretiert wurde. Nun wurde die Anwendungslogik und das Klassenmodell in den Pseudocode gelegt, sodass im proof-of-concept alleinig die Verwendung in textueller Form geschieht. Die aktuellste Version findet sich hier.
Zudem wurden untereinander die Fortschritte im Bereich Node.js und Javascript besprochen, um eine erste Angleichung des Wissenstandes für den ersten Meilenstein zu erzielen.
Nach der Feststellung, dass uns zur ersten Abnahme die REST-Schnittstellenmodellierung unserer API fehlt, wurde am heutigen Tag dieses Element angefangen, dies nachzuholen. Dabei handelt es sich um ein Artefakt, welches iterativ zu betrachten ist, da die Möglichkeit besteht, dass weitere Funktionalitäten während des Coding-Prozesses benötigt werden oder ein effizienteres Arbeiten ermöglicht.
Nach der Beendigung der ersten Version der REST-Schnittstellenmodellierung konnte eine klarere Einteilung der Coding-Aufgaben erfolgen:
- Sebastian Brock: Wartung, Verwaltung & Modifizieren der API-internen Cocktail-DB
- Nick Crisci: Verbindung der Beatdrinksinhalte + Umsetzung der Beatdrinks-Schnittstelle
- Paul Johne: Integrierung der Spotify API in Beatdrinks
Der Tag wurde genutzt, um den anderen Teammitgliedern in einem weiteren Discord-Meeting die eigene Coderealisierung und angepeilte Ziele zu vermitteln. Zudem wurden genauere Realisierungspunkte der Anwendungslogik bestimmt, die mit dem User-Input arbeiten und die andere Funktionalitäten der Cocktail-DB- und Spotify-Abfragen beeinflussen.
Die letzten Teile der Anwendungslogik werden ergänzt und erreichbar gemacht über die diversen Subressourcen. Für die Erstellung des Videos wurde sich mündlich im Discordmeeting unterhalten, damit der Rahmen von 10 Minuten nicht überschritten wird. Eine Verlinkung des entstandenen Vorstellungsvideos wurde in der Readme Datei hinterlegt.
