-
Notifications
You must be signed in to change notification settings - Fork 0
1.Projektidee_Ziel_Vorgehen
###"Musiqueue - Die Partyplaylist" Niklas feiert gerne Partys, doch er findet es doof, dass er immer die Songs die der DJ auswählt hören muss. Er selbst veranstaltet demnächst auch eine Party, möchte das ganze aber lieber anders handhaben. Seine Idee ist es, dass jeder sich ein bestimmtes Lied wünschen kann und das ganze dann automatisch in die Playlist eingefügt wird. Zudem würde er sich gerne im Nachhinein die Playlist des Abends angucken, um neue Musik für sich zu finden.
###Problem: Niklas möchte gerne ein System haben, mit Hilfe dessen er sich und seinen Gästen die Möglichkeit gibt, sich Songs zu wünschen. Doppelte Lieder oder Lieder, die schon einmal gespielt wurden, sollen dabei selbst verständlich ignoriert werden. Es ist Niklas aber auch noch sehr wichtig dabei, dass er immer noch die Entscheidungsgewalt besitzt, welche Lieder gespielt werden.
Das Ziel ist ein verteiltes System, welches durch eine Webanwendung verwendet wird. Hierbei wird ein besonderes Augenmerk darauf gelegt, dass viel Kommunikation zwischen einem Webservice und dem Dienstnutzer stattfindet.
Besonders wichtig bei der Umsetzung sind uns folgende Funktionen:
- Playlist, die von jedem Gast mit Musikwünschen erweitert werden kann und gleichzeitig Songs von nicht gewünschten Genres ablehnt
- Der DJ soll die Möglichkeit haben, auch wenn Songs vom Genre her passen, die Playlist zu verwalten
- Das Aufrufen der gespielten Playlist, sowohl während als auch nach der Party
Die Realisierung eines verteilten Systems basierend auf unserem Problemszenario ist für uns für uns aus mehreren Gründen sinnvoll. Zum einen führt es zum Eindruck, dass sowohl Partygäste, welche über ihr Mobiltelefon kommunizieren, als auch der DJ, welcher vermutlich seinen Personal Computer verwendet, alle nur ein Einprozessorsystem verwenden. Somit wird die komplette Verteiltheit des Systems verborgen. Der Zugriff auf die Ressourcen, wie die Songdatenbank, fällt den Akteuren zudem auch sehr einfach.
Die Entscheidung für den Webservice viel dadurch, dass sich so kein Akteur ein extra Programm zur Verwendung des verteilten Systems besorgen muss.
Als Ziel für uns würden wir das System zum Ende der 2. Projektphase gerne marktreif vorliegen haben.
Bei der Suche nach einer geeigneten Projektidee, sammelten wir mehrere Ideen und jeder entschied sich für ein Expose was er der Gruppe anschließend vorstellte. Mit unseren Betreuern entschieden wir uns schließlich für die "musiqueue", da hier viel Kommunikation zwischen mehreren Clients und einem Server stattfindet.
Bei der Festlegung der Ressourcen haben wir uns an der Idee orientiert und uns für die später formulierten REST- Spezifikationen entschieden. Hier kamen auch durch viele neue Ideen und verschiedenste Begründungen viele Änderungen zustande.
Über mehrere Gruppentreffen hinweg sammelten wir immer mehr Ideen für unsere Applikation. Zu viele Ideen. Deswegen haben wir uns für wenige, aber funktionierende Funktionen in der ersten Phase entschieden. Was unser System am Ende können soll, haben wir dann schlussendlich über das Use-Case Diagramm und die einzelnen Beschreibungen festgelegt.
Den Dienstgeber und der Dienstnutzer wurden dann in Einzelarbeit entwickelt, während die Teammitglieder dabei waren, das ganze nachzuvollziehen. In weiteren Schritten kommunizierten wir dann sehr viel, da ein sehr großer Zusammenhang zwischen Dienstgeber und Dienstnutzer vorhanden war. Und klärten uns über unklare Passagen gegenseitig auf und kamen schließlich zu einem übereinstimmenden Ergebnis.
In der nächsten Phase werden wir uns daran setzen, die fehlenden Funktionen zusammen zu entwickeln. Ein besonderes Augenmerk werden wir hier nochmal auf die Anwendungslogik des Dienstgebers legen, da wir in dem Bereich die größten Probleme hatten. Unser Ziel ist es, dass System so weit zu entwickeln, dass man es auf dem Markt verkaufen könnte.