Klassen- und Implementationsdiagramm: Unterschied zwischen den Versionen

Aus SibiWiki
Zur Navigation springen Zur Suche springen
 
(16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 10: Zeile 10:


* Klasse, Objekt
* Klasse, Objekt
* hat-Beziehung, kennt, erbt von, ''"hat ein Attribut ... vom Typ List, das nur Objekte vom Typ... enthalten kann"''
* hat-Beziehung, kennt, erbt von, ''"hat ein Attribut ... vom Typ List, das nur Objekte vom Typ... enthalten kann"''
* Attribut, Attribut-Typ
* Attribut, Attribut-Typ
* Methode, Parameter, Parameter-Typ, Rückgabe-Typ, öffentliche Methode, private Methode
* Methode, Parameter, Parameter-Typ, Rückgabe-Typ, öffentliche Methode, private Methode
* get-Methode (=gibt nur ein Attribut zurück), set-Methode (=trägt nur einen neuen Wert in ein Attribut ein)
* get-Methode (=gibt nur ein Attribut zurück), set-Methode (=trägt nur einen neuen Wert in ein Attribut ein)
* Geheimnisprinzip


=Wofür braucht man Klassendiagramme?=
=Wofür braucht man Klassen- und Implementationsdiagramme?=


Klassendiagramme braucht man, um Softwaresysteme zu '''modellieren'''. Dabei wird im Klassendiagramm folgendes festgelegt:
Klassendiagramme braucht man, um Softwaresysteme zu '''modellieren'''. Dabei wird im Klassendiagramm folgendes festgelegt:
Zeile 27: Zeile 25:


Sehr vereinfacht sieht der Entwicklungsprozess so aus: <br/>Aus der ''Anforderungsermittlung'' (=einem Text, der mit dem Auftraggeber abgesprochen ist) zeichnet der ''Software-Architekt'' Klassendiagramme, die die gesamte in der Anforderungsermittlung beschriebene Funktionalität abbilden. In großen Systemen kann es mehrere hundert Klassen geben. <br/>Anschließend können die Programmierer die im Klassendiagramm beschriebenen Klassen implementieren (z.B. in Java).
Sehr vereinfacht sieht der Entwicklungsprozess so aus: <br/>Aus der ''Anforderungsermittlung'' (=einem Text, der mit dem Auftraggeber abgesprochen ist) zeichnet der ''Software-Architekt'' Klassendiagramme, die die gesamte in der Anforderungsermittlung beschriebene Funktionalität abbilden. In großen Systemen kann es mehrere hundert Klassen geben. <br/>Anschließend können die Programmierer die im Klassendiagramm beschriebenen Klassen implementieren (z.B. in Java).
=Anforderungen an Implementationsdiagramme=
''Die folgenden Anforderungen sind erst dann interessant, wenn man mehrere Klassen hat, die in Beziehung zueinander stehen!''<br/>''Was hier im folgende steht, ist nicht gedeckt durch Literatur etc. Es hat sich aber für den Unterricht, in der (einfachen) Praxis und auch im Zentralabitur als brauchbar erwiesen.''
Implementationsdiagramme sollen eine '''Software-Architektur für eine Software-Anwendung''' definieren.<br/>Deswegen gibt es zwei Grundanforderungen, die klar sind:
* Die Anforderungen müssen mit der Software-Architektur möglichst einfach realisierbar sein.
* Die Software-Architektur soll sich möglichst einfach implementieren lassen, d.h. in Quellcode übersetzen lassen.
Daraus lassen sich folgende '''Anforderungen''' ableiten:
'''Intuitiv verständlich'''<br/>Objektorientierung lebt davon, dass man mit ihrer Hilfe Szenarien aus der realen Welt möglichst "realitätsnah" modellieren und implementieren kann. Das sollte man nutzen, und deswegen sollten Implementationsdiagramme intuitiv verständlich sein.
'''Geheimnisprinzip:'''<br/>Jede Klasse sollte die Daten, die sie verwaltet, privat halten und nur einen kontrollierten Zugriff darauf bieten. <br/>Beispiel: Die Klasse <code>Fahrkartenautomat</code> sollte auf keinen Fall das Attribut <code>eingeworfenesGeld</code> öffentlich machen! Wer weiß, was ein anderer Programmierer dann damit tut??! Stattdessen sollte es eine Methode <code>geldEinwerfen</code> geben, bei der der Fahrkartenautomat den Zugriff auf <code>eingeworfenesGeld</code> steuern kann.
'''Möglichst Beziehungen nur in einer Richtung:'''<br/>
Das erleichtert später die Implementierung!
'''möglichst Top-Down:'''<br/>
Streng Hierachische Architekturen sind in der Regel leicht beherrschbar. Die Beziehungen gehen dann in der Regel von oben nach unten. Wenn ganz an der Spitze eine Klasse steht, die "alles kontrolliert", kann diese Klasse Aufgaben an untergeordnete Klassen delegieren.


=Vorgaben für das Zentralabitur=
=Vorgaben für das Zentralabitur=
Zeile 63: Zeile 82:


Das oben gegebene einfache Klassendiagramm kann z.B. wie folgt in Java implementiert werden.
Das oben gegebene einfache Klassendiagramm kann z.B. wie folgt in Java implementiert werden.
<code>
<code>
  public class Buch{
  public class Buch{
   
   
Zeile 88: Zeile 107:
   }
   }
  }
  }
</code>
</code>


=Beziehungen zwischen Klassen=
=Beziehungen zwischen Klassen=
[[File:Kennt-hat-erbt-von.png|thumb|kennt, hat, erbt von|209px]]
[[File:Kennt-erbt-von.png|thumb|kennt, erbt von|236px]]
Es gibt drei Beziehungstypen:
Es gibt zwei Beziehungstypen:
* '''Kennt'''-Beziehung: Ein Objekt der Klasse A kennt ein/mehrere Objekte der Klasse B.<br/>Beispiel: Fahrer '''kennt''' mehrere Tankstellen.
* '''Kennt'''-Beziehung ('''Assoziation'''): Ein Objekt der Klasse A kennt ein/mehrere Objekte der Klasse B.<br/>Beispiel: Fahrer '''kennt''' mehrere Tankstellen.
* '''Hat'''-Beziehung: Ein Objekt der Klasse A hat (=besitzt!) ein/mehrere Objekte der Klasse B. <br/>Beispiel: Fahrer '''hat''' einen Roller.
* '''Vererbung''': Klasse A erbt von Klasse B. Man sagt auch oft: A '''ist ein''' B <br/>Beispiel: Roller '''erbt von''' Fahrzeug, bzw. Roller '''ist ein''' Fahrzeug.
* '''Vererbung''': Klasse A erbt von Klasse B. Man sagt auch oft: A '''ist ein''' B <br/>Beispiel: Roller '''erbt von''' Fahrzeug, bzw. Roller '''ist ein''' Fahrzeug.


==Wie unterscheidet man Hat- und Kennt-Beziehung?==
''Anmerkung:''<br/>
Das hängt vom jeweiligen Szenario ab!
''Im UML-Standard gibt es noch einen dritten Beziehungstyp:''<br/>
 
''Hat-Beziehung: Ein Objekt der Klasse A hat (=besitzt!) ein/mehrere Objekte der Klasse B. <br/>Beispiel: Fahrer '''hat''' einen Roller.<br/>
Die entscheidende Fragestellung ist:<br/>
''Im Zentralabitur wird aber zwischen kennt-Beziehung und hat-Beziehung nicht unterschieden.''
''Was passiert, wenn man den "Besitzer" zerstört?''
* Wenn man das andere Objekt dann auch nicht mehr braucht (d.h. ebenfalls zerstören kann), dann ist das eine "Hat-Beziehung".
* Wenn das andere Objekt aber erhalten bleiben soll, dann ist es eine "Kennt-Beziehung".


==Multiplizitäten der Hat-Beziehung und der Kennt-Beziehung==
==Multiplizitäten der Kennt-Beziehung==
Multiplizitäten werden entweder genau oder mit einer Unter- und einer Obergrenze notiert:
Multiplizitäten werden entweder genau oder mit einer Unter- und einer Obergrenze notiert.<br/>
* '''1''': genau ein
Beispiele:
* '''0..1''': 0 oder ein
* '''1''': &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;genau ein
* '''2..4''': mindestens 2 und höchstens 4
* '''0..1''': &nbsp;&nbsp;&nbsp;0 oder ein
* '''1..*''': mindestens 1 (und höchstens beliebig viele)
* '''2..4''': &nbsp;&nbsp;&nbsp;mindestens 2 und höchstens 4
* '''1..*''': &nbsp;&nbsp;&nbsp;mindestens 1 (und höchstens beliebig viele)




Zeile 118: Zeile 134:


'''Erläuterung:'''
'''Erläuterung:'''
* Jeder Fahrer '''besitzt genau einen''' Roller.<br/>Wenn man den Fahrer "zerstört", dann braucht man auch den Roller nicht mehr.
* Jeder Fahrer '''kennt genau einen (nämlich seinen)''' Roller.
* Jeder Fahrer '''kennt mindestens eine, aber beliebig viele''' Tankstellen.
* Jeder Fahrer '''kennt mindestens eine, aber beliebig viele''' Tankstellen.


Zeile 135: Zeile 151:


==Beziehungen zwischen Klassen==
==Beziehungen zwischen Klassen==
* <u>Kennt</u> bzw. <u>hat</u> ein Objekt der Klasse A ein (oder mehrere) Objekt(e) der Klasse B?
Folgende Fragestellungen helfen beim Erstellen von Beziehungen:
* <u>Kennt-Beziehung / Assoziation</u>: <u>Kennt</u> ein Objekt der Klasse A ein (oder mehrere) Objekt(e) der Klasse B?  
** <u>Multiplizität</u>: <u>Wieviele</u> Objekte der Klasse B?
** <u>Multiplizität</u>: <u>Wieviele</u> Objekte der Klasse B?
* Welches Objekt <u>ist ein</u> Objekt einer anderen Klasse?
* <u>Vererbung</u>: Welches Objekt <u>ist ein</u> Objekt einer anderen Klasse? Welche Klasse <u>erbt</u> Attribute und Methoden einer anderen Klasse?


=Erstellen von Implementationsdiagrammen: Top-Down-Modellierung=
=Erstellen von Implementationsdiagrammen: Top-Down-Modellierung=
Zeile 149: Zeile 166:
===Szenario:===
===Szenario:===


//TODO
Peter hat einen Motorroller. In der Nähe gibt es eine Tankstelle, bei der Peter tanken kann.
Einige von Peters Freunden haben auch Motorroller.
 
Es soll jetzt eine Anwendung entwickelt werden, in der das Fahren und Betanken der Motorroller simuliert werden kann. Auch das Bezahlen vom eigenen Guthaben soll simuliert werden.


===ausführliches Klassendiagramm:===
===ausführliches Klassendiagramm:===
Zeile 160: Zeile 180:
'''Klasse <code>Person</code>'''
'''Klasse <code>Person</code>'''


<code>
<code>
  public class Person
  public class Person
  {
  {
     private Roller meinRoller;
     '''private Roller meinRoller;'''
     '''private Tankstelle dieTankstelle;'''
     '''private Tankstelle dieTankstelle;'''
     private String name;
     private String name;
Zeile 171: Zeile 191:
     {
     {
         name = pName;
         name = pName;
         meinRoller = new Roller();
         '''meinRoller = new Roller();'''
     }
     }
    
    
Zeile 215: Zeile 235:
     }
     }
  }
  }
</code>
</code>


'''Erklärung:'''
'''Erklärung:'''
Zeile 228: Zeile 248:
Diese Klasse erscheint nicht im Klassendiagramm, ist aber sinnvoll, um die Simulation überhaut starten zu können. Hier wird die Beziehung zwischen <code>Person</code> und <code>Roller</code> hergestellt.
Diese Klasse erscheint nicht im Klassendiagramm, ist aber sinnvoll, um die Simulation überhaut starten zu können. Hier wird die Beziehung zwischen <code>Person</code> und <code>Roller</code> hergestellt.


<code>
<code>
  public class Simulation
  public class Simulation
  {
  {
Zeile 241: Zeile 261:
     }
     }
  }
  }
</code>
</code>


==Beispiel für die Q1 (Listen)==
==Beispiel für die Q1 (Listen)==
Zeile 264: Zeile 284:
* <code>Medienplayer</code> ist die "oberste" Klasse und damit der Ausgangspunkt der Modellierung.
* <code>Medienplayer</code> ist die "oberste" Klasse und damit der Ausgangspunkt der Modellierung.
* <code>Medienplayer</code> '''hat''' eine Liste mit '''Inhaltsobjekten''' vom Typ <code>Wiedergabeliste</code>. <code>List</code> eignet sich besser als <code>Queue</code> oder <code>Stack</code>, weil damit das Auswählen der Wiedergabeliste nach dem Titel einfacher realisiert werden kann.
* <code>Medienplayer</code> '''hat''' eine Liste mit '''Inhaltsobjekten''' vom Typ <code>Wiedergabeliste</code>. <code>List</code> eignet sich besser als <code>Queue</code> oder <code>Stack</code>, weil damit das Auswählen der Wiedergabeliste nach dem Titel einfacher realisiert werden kann.
* <code>Medienplayer</code> '''hat''' ein Attribut <code>aktiveWiedergabeliste</code> vom Typ <Wiedergabeliste</code>, in dem die jeweils aktive Wiedergabeliste gespeichert wird.
* <code>Medienplayer</code> '''hat''' ein Attribut <code>aktiveWiedergabeliste</code> vom Typ <code>Wiedergabeliste</code>, in dem die jeweils aktive Wiedergabeliste gespeichert wird.
* <code>WiedergabeListe</code> kann nicht von <code>List</code> '''erben''', weil sie sonst die Methode <code>concat(List pList)</code> zur Verfügung hätte, die im Szenario nicht vorgesehen ist.
* <code>WiedergabeListe</code> kann nicht von <code>List</code> '''erben''', weil sie sonst die Methode <code>concat(List pList)</code> zur Verfügung hätte, die im Szenario nicht vorgesehen ist.
* Stattdessen: <code>WiedergabeListe</code> '''hat''' eine <code>List</code> mit '''Inhaltsobjekten''' vom Typ <code>Titel</code>. <code>Queue</code> oder <code>Stack</code> eignen sich nicht, weil man an beliebigen Stellen einfügen können muss.
* Stattdessen: <code>WiedergabeListe</code> '''hat''' eine <code>List</code> mit '''Inhaltsobjekten''' vom Typ <code>Titel</code>. <code>Queue</code> oder <code>Stack</code> eignen sich nicht, weil man an beliebigen Stellen einfügen können muss.
=Implementationsdiagramme erläutern=
Eine mögliche Aufgabenstellung kann sein:
''Beschreiben Sie die dargestellten Klassen und deren Beziehungen zueinander.''
Hier kommt es darauf an, dass man '''Fachbegriffe''' verwendet!!


===Implementationsdiagramm: Beziehung der Klassen===
===Implementationsdiagramm: Beziehung der Klassen===
Zeile 285: Zeile 299:


[[Datei:Medienplayer-klassen.png]]
[[Datei:Medienplayer-klassen.png]]
=Implementationsdiagramme erläutern=
Eine mögliche Aufgabenstellung kann sein:
''Beschreiben Sie die dargestellten Klassen und deren Beziehungen zueinander.''
Hier kommt es darauf an, dass man '''Fachbegriffe''' verwendet!!
==Beispiel==
[[Datei:Implementationsdiagramm-medienplayer.png]]
'''Aufgabe:'''
''Beschreiben Sie die dargestellten Klassen und deren Beziehungen zueinander.''
'''Mögliche Lösung:'''
''Fachbegriffe sind jeweils <u>unterstrichen</u>, wenn sie das erste Mal vorkommen.''
'''Beschreibung der Klassen: '''
* Die <u>Klasse</u> Titel hat drei <u>private Attribute</u>. Im <u>Konstruktor</u> muss an Werte für die drei Attribute angeben. Es gibt für jedes Attribut eine <u>öffentliche get-Methode</u>.
* Die Klasse Wiedergabeliste hat ein privates Attribut name; dafür muss man im Konstruktor einen Wert angeben. Außerdem gibt es eine öffentliche get-Methode für name.
* Die Klasse Wiedergabeliste hat weitere öffentliche Methoden, z.T. mit <u>Parametern</u> vom <u>Typ</u> Song. Die Methoden geben nichts zurück.
* Die Klasse Medienplayer hat - abgesehen von wiedergabeListen (s.u.) - keine Attribute. Der Konstruktor hat keine Parameter. Es gibt drei öffentliche Methoden mit Parameter vom Typ String; eine Methode gibt ein boolean zurück, die anderen beiden geben nichts zurück.
'''Beschreibung der Beziehungen:'''
* Die Klasse Wiedergabeliste hat ein <u>privates Attribut songListe vom Typ List. Die Liste enthält Objekte vom Typ Song</u>.
* Die Klasse Medienplayer hat ein privates Attribut wiedergabeListen vom Typ List. Die Liste enthält Objekte vom Wiedergabeliste.

Aktuelle Version vom 11. Januar 2024, 19:43 Uhr


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

Fachbegriffe

  • Klasse, Objekt
  • hat-Beziehung, kennt, erbt von, "hat ein Attribut ... vom Typ List, das nur Objekte vom Typ... enthalten kann"
  • Attribut, Attribut-Typ
  • Methode, Parameter, Parameter-Typ, Rückgabe-Typ, öffentliche Methode, private Methode
  • get-Methode (=gibt nur ein Attribut zurück), set-Methode (=trägt nur einen neuen Wert in ein Attribut ein)
  • Geheimnisprinzip

Wofür braucht man Klassen- und Implementationsdiagramme?

Klassendiagramme braucht man, um Softwaresysteme zu modellieren. Dabei wird im Klassendiagramm folgendes festgelegt:

  • Name, Attribute (mit Typ) und Methoden (mit Parameter und Rückgabetyp) jeder einzelnen Klasse.
  • Die Beziehungen zwischen den Klassen.

Nicht festgelegt wird im Klassendiagramm die konkrete Programmierung.

Sehr vereinfacht sieht der Entwicklungsprozess so aus:
Aus der Anforderungsermittlung (=einem Text, der mit dem Auftraggeber abgesprochen ist) zeichnet der Software-Architekt Klassendiagramme, die die gesamte in der Anforderungsermittlung beschriebene Funktionalität abbilden. In großen Systemen kann es mehrere hundert Klassen geben.
Anschließend können die Programmierer die im Klassendiagramm beschriebenen Klassen implementieren (z.B. in Java).

Anforderungen an Implementationsdiagramme

Die folgenden Anforderungen sind erst dann interessant, wenn man mehrere Klassen hat, die in Beziehung zueinander stehen!
Was hier im folgende steht, ist nicht gedeckt durch Literatur etc. Es hat sich aber für den Unterricht, in der (einfachen) Praxis und auch im Zentralabitur als brauchbar erwiesen.


Implementationsdiagramme sollen eine Software-Architektur für eine Software-Anwendung definieren.
Deswegen gibt es zwei Grundanforderungen, die klar sind:

  • Die Anforderungen müssen mit der Software-Architektur möglichst einfach realisierbar sein.
  • Die Software-Architektur soll sich möglichst einfach implementieren lassen, d.h. in Quellcode übersetzen lassen.


Daraus lassen sich folgende Anforderungen ableiten:

Intuitiv verständlich
Objektorientierung lebt davon, dass man mit ihrer Hilfe Szenarien aus der realen Welt möglichst "realitätsnah" modellieren und implementieren kann. Das sollte man nutzen, und deswegen sollten Implementationsdiagramme intuitiv verständlich sein.

Geheimnisprinzip:
Jede Klasse sollte die Daten, die sie verwaltet, privat halten und nur einen kontrollierten Zugriff darauf bieten.
Beispiel: Die Klasse Fahrkartenautomat sollte auf keinen Fall das Attribut eingeworfenesGeld öffentlich machen! Wer weiß, was ein anderer Programmierer dann damit tut??! Stattdessen sollte es eine Methode geldEinwerfen geben, bei der der Fahrkartenautomat den Zugriff auf eingeworfenesGeld steuern kann.

Möglichst Beziehungen nur in einer Richtung:
Das erleichtert später die Implementierung!

möglichst Top-Down:
Streng Hierachische Architekturen sind in der Regel leicht beherrschbar. Die Beziehungen gehen dann in der Regel von oben nach unten. Wenn ganz an der Spitze eine Klasse steht, die "alles kontrolliert", kann diese Klasse Aufgaben an untergeordnete Klassen delegieren.

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

Wie die einzelnen Klassen implementiert werden, das entscheidet der zuständige Programmierer; er muss sich aber genau an die Vorgaben des Klassendiagramms halten.

Das oben gegebene einfache Klassendiagramm kann z.B. wie folgt in Java implementiert werden.


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;
  }
}

Beziehungen zwischen Klassen

kennt, erbt von

Es gibt zwei Beziehungstypen:

  • Kennt-Beziehung (Assoziation): Ein Objekt der Klasse A kennt ein/mehrere Objekte der Klasse B.
    Beispiel: Fahrer kennt mehrere Tankstellen.
  • Vererbung: Klasse A erbt von Klasse B. Man sagt auch oft: A ist ein B
    Beispiel: Roller erbt von Fahrzeug, bzw. Roller ist ein Fahrzeug.

Anmerkung:
Im UML-Standard gibt es noch einen dritten Beziehungstyp:
Hat-Beziehung: Ein Objekt der Klasse A hat (=besitzt!) ein/mehrere Objekte der Klasse B.
Beispiel: Fahrer hat einen Roller.
Im Zentralabitur wird aber zwischen kennt-Beziehung und hat-Beziehung nicht unterschieden.

Multiplizitäten der Kennt-Beziehung

Multiplizitäten werden entweder genau oder mit einer Unter- und einer Obergrenze notiert.
Beispiele:

  • 1:       genau ein
  • 0..1:    0 oder ein
  • 2..4:    mindestens 2 und höchstens 4
  • 1..*:    mindestens 1 (und höchstens beliebig viele)


Beispiel

Beziehungen zwischen Roller, Fahrer und Tankstelle

Im Klassendiagramm rechts sind die Beziehungen zwischen Roller, Fahrer und Tankstelle dargestellt. (Attribute und Methoden der einzelnen Klassen sind hier nicht aufgeführt.

Erläuterung:

  • Jeder Fahrer kennt genau einen (nämlich seinen) Roller.
  • Jeder Fahrer kennt mindestens eine, aber beliebig viele Tankstellen.

Erstellen von Klassendiagrammen

Klassendiagramme sind vor allem Planungswerkzeuge für die Entwicklung umfangreicher Software-Systeme.

Mithilfe von Klassendiagrammen kann man festlegen, was programmiert werden muss.

Attribute, Konstruktor, Methoden

Folgende Fragestellungen helfen beim Erstellen von Klassendiagrammen:

  • Attribute: Welche Informationen müssen Objekte der Klasse speichern, damit sie im Szenario funktionieren können?
  • Parameter des Konstruktors: Welche Information muss man angeben, wenn man ein Objekt der Klasse erzeugt?
  • Methoden: Was kann man mit Objekten der Klasse tun?
    • Parameter der Methoden: Welche Information muss man der Methode mitgeben, damit sie arbeiten kann?
    • Rückgabetyp der Methoden: Gibt die Methode eine Information zurück? Welchen Datentyp hat die Rückgabe?

Beziehungen zwischen Klassen

Folgende Fragestellungen helfen beim Erstellen von Beziehungen:

  • Kennt-Beziehung / Assoziation: Kennt ein Objekt der Klasse A ein (oder mehrere) Objekt(e) der Klasse B?
    • Multiplizität: Wieviele Objekte der Klasse B?
  • Vererbung: Welches Objekt ist ein Objekt einer anderen Klasse? Welche Klasse erbt Attribute und Methoden einer anderen Klasse?

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 für die EF

Szenario:

Peter hat einen Motorroller. In der Nähe gibt es eine Tankstelle, bei der Peter tanken kann. Einige von Peters Freunden haben auch Motorroller.

Es soll jetzt eine Anwendung entwickelt werden, in der das Fahren und Betanken der Motorroller simuliert werden kann. Auch das Bezahlen vom eigenen Guthaben soll simuliert werden.

ausführliches Klassendiagramm:

Vollständiges Klassendiagramm

Java-Quelltext:

In den Quelltexten sind fett gedruckt die Teile, die die Beziehungen zwischen den Klassen herstellen.

Klasse Person


public class Person
{
   private Roller meinRoller;
   private Tankstelle dieTankstelle;
   private String name;
   private double geld;
  
   public Person(String pName)
   {
       name = pName;
       meinRoller = new Roller();
   }
  
   public void setTankstelle(Tankstelle pTankstelle)
   {
     dieTankstelle = pTankstelle; 
   }
  
   public void geldErhoehen(double pBetrag)
   {
       geld += pBetrag;
   }
    
   public boolean geldVermindern(double pBetrag)
   {
       if(geld < pBetrag){
           return false;
       }
       geld -= pBetrag;
       return true;
   }
   
   public boolean tanken(double pLiter)
   {
       double kosten = dieTankstelle.tanken(pLiter);
       if(kosten > geld)
       {
           return false;
       }
       boolean erfolg = meinRoller.tanken(pLiter);
       if(erfolg == false)
       {
           return false;
       }
       geld -= kosten;
       return true;
   }
    
   public boolean fahren(double pKm)
   {
       boolean erfolg = meinRoller.fahren(pKm);
       return erfolg;
   }
}

Erklärung:

  • Die hat-Beziehung zwischen Person und Roller wird hergestellt, indem im Konstruktor von Person ein Roller erzeugt wird.
  • Dieser Roller wird im Attribut meinRoller gespeichert.
  • Die Person kann jetzt Aufgaben an meinRoller delegieren, indem sie geeignete Methoden von meinRoller aufruft.
  • Die kennt-Beziehung zwischen Roller und Tankstelle wird durch die Methode setTankstelle hergestellt.
  • Die Person kann jetzt das tanken an die Tankstelle delegieren.

Klasse Simulation

Diese Klasse erscheint nicht im Klassendiagramm, ist aber sinnvoll, um die Simulation überhaut starten zu können. Hier wird die Beziehung zwischen Person und Roller hergestellt.


public class Simulation
{
   private Person frank;
   private Tankstelle aral;
  
   public Simulation(){
       frank = new Person("Frank");
       aral = new Tankstelle("Aral");
       aral.setPreis(1.43);
       frank.setTankstelle(aral);
   }
}

Beispiel für die Q1 (Listen)

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

Zuerst werden nur die Beziehungen zwischen den Klassen in einem Diagramm dargestellt.

Attribute und Methoden werden noch nicht dargestellt. Das erleichtert WESENTLICH die Modellierung und das Zeichnen!

Medienplayer-beziehungen.png

Implementationsdiagramm: Die einzelnen Klassen

Jetzt werden die einzelnen Klassen mit Attributen und Methoden dargestellt.

Medienplayer-klassen.png





Implementationsdiagramme erläutern

Eine mögliche Aufgabenstellung kann sein:

Beschreiben Sie die dargestellten Klassen und deren Beziehungen zueinander.

Hier kommt es darauf an, dass man Fachbegriffe verwendet!!

Beispiel

Implementationsdiagramm-medienplayer.png Aufgabe: Beschreiben Sie die dargestellten Klassen und deren Beziehungen zueinander.

Mögliche Lösung:

Fachbegriffe sind jeweils unterstrichen, wenn sie das erste Mal vorkommen.

Beschreibung der Klassen:

  • Die Klasse Titel hat drei private Attribute. Im Konstruktor muss an Werte für die drei Attribute angeben. Es gibt für jedes Attribut eine öffentliche get-Methode.
  • Die Klasse Wiedergabeliste hat ein privates Attribut name; dafür muss man im Konstruktor einen Wert angeben. Außerdem gibt es eine öffentliche get-Methode für name.
  • Die Klasse Wiedergabeliste hat weitere öffentliche Methoden, z.T. mit Parametern vom Typ Song. Die Methoden geben nichts zurück.
  • Die Klasse Medienplayer hat - abgesehen von wiedergabeListen (s.u.) - keine Attribute. Der Konstruktor hat keine Parameter. Es gibt drei öffentliche Methoden mit Parameter vom Typ String; eine Methode gibt ein boolean zurück, die anderen beiden geben nichts zurück.

Beschreibung der Beziehungen:

  • Die Klasse Wiedergabeliste hat ein privates Attribut songListe vom Typ List. Die Liste enthält Objekte vom Typ Song.
  • Die Klasse Medienplayer hat ein privates Attribut wiedergabeListen vom Typ List. Die Liste enthält Objekte vom Wiedergabeliste.