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