Klassen- und Implementationsdiagramm

Aus SibiWiki
Zur Navigation springen Zur Suche springen


  • Klassendiagramme sind wesentlicher Bestandteil der UML (=Unified Modeling Language).
  • Implementationsdiagramme gibt es nur in Nordrhein-Westfalen!

Vorgaben für das Zentralabitur

Hier die offiziellen Erläuterungen für Klassen- und Implementationsdiagramme:

Klassen- und Implementationsdiagramme (PDF)

Attribute und Methoden im Klassendiagramm

Klassendiagramm der Klasse Buch

Rechts ein einfaches Klassendiagramm für die Klasse Buch: Die Klasse Buch ist ein bloßer Informationsbehälter, d.h. die Klasse verfügt nur über get- und set-Methoden und nicht über eine eigene Logik.

Aufbau eines Klassendiagramms

Klassendiagramme haben immer drei Zeilen:

  1. Zeile: Der Name der Klasse
  2. Zeile: die Attribute der Klasse
  3. Zeile: die Methoden der Klasse
    1. Dabei wird als erstes der Konstruktor aufgeführt.

Syntax innerhalb des Klassendiagramms

Klassendiagramme haben eine eigene Syntax, die (leider!) von der Java-Syntax abweicht:

  • + bedeutet public
  • - bedeutet private
  • Attribute:
    • VOR dem Doppelpunkt: "+" bzw. "-" und der Attribut-Name
    • NACH dem Doppelpunkt: Attribut-Typ
  • Methoden:
    • erst "+" bzw. "-" (für public bzw. private)
    • Methoden-Name
    • Parameter (in Klammern!): VOR dem Doppelpunkt der Parameter-Name, NACH dem Doppelpunkt der Parameter-Typ.
    • NACH dem Doppelpunkt: Rückgabe-Typ der Methode

Java-Implementierung

Das oben gegebene einfache Klassendiagramm wird jetzt in Java übersetzt:

public class Buch{

  //Attribute
  private String titel;
  private int regalNr;

  //Konstruktor   
  public Buch(String pTitel){
     titel = pTitel;
  }

  // get- und set-Methoden
  public int getRegalNr() {
     return regalNr;
  }

  public void setRegalNr(int pRegalNr) {
     regalNr = pRegalNr;
  }

  public String getTitel() {
     return titel;
  }
}

Erstellen von Implementationsdiagrammen: Top-Down-Modellierung

Für das Erstellen von Implementationsdiagrammen gibt es keine festen Regeln, aber eine geeignete Vorgehensweise, die Top-Down-Modellierung:

  • Man ermittelt die Klassen, die sich aus dem Sachzusammenhang ergeben.
  • Man fängt bei der "obersten" Klasse an, die über allem steht und arbeitet sich immer weiter nach unten durch. Dabei stellt man fest, welche Beziehung zwischen den Klassen besteht.
  • Man zeichnet ein Implementationsdiagramm, in dem die Beziehungen zwischen den Klassen festgehalten werden.
  • Man zeichnet Klassendiagramme für die einzelnen Klassen, in denen Attribute und Methoden festgehalten werden.

Beispiel

Szenario:

Ein Medienplayer kann die Titel, die man hören möchte, in Wiedergabelisten verwalten. Folgende typische Operationen sollen im Modell enthalten sein:

  1. Für einen Titel werden der Name, der Interpret und die Länge in Sekunden gespeichert. (Um die Speicherung der Audio-Daten kümmert sich diese Modellierung nicht.)
  2. Ein Titel kann an einer beliebigen Position der Wiedergabeliste (d. h. am Anfang, am Ende oder an einer Stelle innerhalb der Liste) eingefügt werden. Ebenso kann ein beliebiger Titel aus der Liste gelöscht werden.
  3. Das Abspielen der Wiedergabeliste beginnt beim ersten Titel. Dann werden alle Titel nacheinander abgespielt. Man kann das Abspielen stoppen. Und man kann wieder an den Anfang der Wiedergabeliste gehen.
  4. In einem Medienplayer werden beliebig viele Wiedergabelisten verwaltet. Jede Wiedergabeliste hat einen Namen. Der Medienplayer kann immer nur eine aktive Wiedergabeliste haben. Die aktive Liste kann abgespielt werden.
  5. Im Medienplayer kann man eine Wiedergabeliste auswählen, indem man ihren Namen angibt. Man kann auch neue Wiedergabelisten anlegen, indem man einen Namen angibt. Und man kann die gerade aktive Wiedergabeliste löschen.
  6. Beim Abspielen einer Wiedergabeliste fragt der Medienplayer immer den nächsten Titel von der aktiven Wiedergabeliste an.

Aufgabe:

Entwerfen Sie ein Implementationsdiagramm. Begründen Sie Ihre Entscheidungen. Begründen Sie auch, ob Sie sich für Stack, Queue oder List entscheiden.

Lösung

Analyse

Bei der Analyse schreibt man formelhaft Begründungen für die Beziehungen der Klassen:

  • Aus dem Szenario ergeben sich die Klassen Medienplayer, Wiedergabeliste und Titel.
  • Medienplayer ist die "oberste" Klasse und damit der Ausgangspunkt der Modellierung.
  • Medienplayer hat eine Liste mit Inhaltsobjekten vom Typ Wiedergabeliste. List eignet sich besser als Queue oder Stack, weil damit das Auswählen der Wiedergabeliste nach dem Titel einfacher realisiert werden kann.
  • Medienplayer hat ein Attribut aktiveWiedergabeliste vom Typ <Wiedergabeliste, in dem die jeweils aktive Wiedergabeliste gespeichert wird.
  • WiedergabeListe kann nicht von List erben, weil sie sonst die Methode concat(List pList) zur Verfügung hätte, die im Szenario nicht vorgesehen ist.
  • Stattdessen: WiedergabeListe hat eine List mit Inhaltsobjekten vom Typ Titel. Queue oder Stack eignen sich nicht, weil man an beliebigen Stellen einfügen können muss.


Implementationsdiagramm: Beziehung der Klassen

Medienplayer-beziehungen.png

Implementationsdiagramm: Die einzelnen Klassen=

Medienplayer-klassen.png