Musikinformationssystem – Modell

Musikinformationssystem – Modell
Aufgabenbeschreibung
Das Verwalten von Musikinformationen ist in der heutigen Zeit eine wichtige
Anwendungsdomäne, dass sowohl privat (lokales Informationssystem), Community orientiert
als auch kommerziell gefordert ist. Eine erste Aufgabe auf dem Weg zu einem
Informationssystem besteht darin, ein Klassenmodell für die Anwendung und die
dazugehörigen Integritätsbedingungen zu entwerfen und zu definieren. Sie sollen dies unter
Verwendung des UML Tools USE durchführen.
Ein weiterer wichtiger Punkt ist die Dokumentation ihres Entwurfs, damit die getroffenen
Design-Entscheidungen später nachvollzogen werden können. Dies gehört ebenfalls zu der
geforderten Lösung. Kommentieren Sie ihr Design innerhalb der USE Datei.
Beschreibung der zu modellierenden Informationen und
Integritätsbedingungen
Es sollen Informationen über CDs, Musiker, Bands und Musikstücke zur Verfügung gestellt
werden. Darüber hinaus sollen Ähnlichkeiten zwischen Bands/Musikern sowie
Klassifizierungen von CDs und Musikstücken modelliert werden.
Eine CD hat einen Titel und besteht aus einer Menge von Musikstücken in geordneter
Reihenfolge (Abspielreihenfolge). Jedes Musikstück und jede CD hat eine Länge, ein
Aufnahmedatum und ein Titel und wurde von einem Künstler (Musiker oder einer Band)
erstellt. Einer CD ist entweder ein hauptverantwortlicher Künstler ("Pink Floyd") oder ein
Provider ("Bravo Hits") zugeordnet. Die maximale Laufzeit einer CD darf durch die
Musikstücke nicht überschritten sein. Diese Informationen müssen vorhanden sein. Dasselbe
Musikstück kann sich auf unterschiedlichen Alben an unterschiedlicher Reihenfolge befinden.
Ein Musikstück kann aber auch in unterschiedlichen Versionen existieren (Live, …). Ein
Album wird von einem Tonträgerunternehmen (Plattenfirma) produziert.
Einem Musikstück kann eine Hörprobe zugeordnet sein. Zu einem Musikstück soll die
Information bereitgestellt werden, welcher Musiker welches Instrument spielt. Zu jeder CD
kann auch ein Bild des Covers und URLs für Online Stores hinterlegt werden.
Eine CD/Musikstück wird durch genau ein Genre beschrieben. Genre sollen hierarchisch
modelliert werden können (Rock->Hard Rock->…). Darüber hinaus soll eine weitere
Klassifikation durch einen kontrollierten, erweiterbaren Wortschatz möglich sein. Die
Zuordnung mehrerer Klassifikationen soll möglich sein.
Ein Musiker/eine Band hat einen Namen. Der Sortiername soll spezifizierbar sein (Eric
Clapton -> Clapton, Pink Floyd-> Pink Floyd).
Ein Musiker kann zu einem Zeitpunkt als Solist und/oder als Bandmusiker tätig sein. Ein
Musiker kann aber zu einem Zeitpunkt nur Mitglied einer Band sein. Außerdem kann ein
Musiker unterschiedliche Instrumente spielen. Die Integrität mit den CD Informationen muss
gewahrt bleiben.
Eine Band kann zu unterschiedlichen Zeitpunkten unterschiedliche Bandmitglieder haben.
Überlegen Sie sich wie die Constraints realisiert werden sollten. Sie haben im Wesentlichen
die Entscheidung zwischen strukturellen Maßnahmen (Multiplizitäten in Beziehungen),
Klassen Invarianten (Name darf nicht null sein, Musiker muss einen Namen haben) und
operationalen Constraints (beim Erzeugen einer CD muss der Musiker angegeben werden, das
Enddatum muss nach dem Startdatum liegen, eine Besetzung (Musiker, Instrument) darf nur
hinzugefügt werden, wenn der Musiker das Instrument auch spielen kann).
Stellen Sie durch Operationssimulation die Korrektheit ihrer Constraint-Definition sicher.
Strukturelle Bedingungen und Invarianten können durch Objektinstanziierungen getestet
werden.
Containerklassen müssen nicht modelliert werden (z.B. Artists, CDs, …).
Anforderungen
Ihre Aufgabe ist es, ein UML Klassendiagramm zu modellieren und die beschriebenen
Attribute und Beziehungen im Klassendiagramm zu implementieren. Die geforderten und
impliziten Integritätsbedingungen sollen in OCL ausgedrückt werden. Des Weiteren sind alle
Bestandteile des Klassendiagramms zu dokumentieren. Verwenden Sie auf jeden Fall
sprechende Namen. Lesen Sie hierzu die „Java Code Konventionen“, da später eine
Anwendung geschrieben werden soll.
Hinweise
1. Die Anzahl der zu modellierenden Klassen beträgt in etwa 12 (abhängig vom Design).
2. Die „Java Code Conventions“ finden Sie hier
3. Spätester Abgabetermin: 18.12.09