Übungsaufgaben UML-Klassendiagramm

Einstieg in objektorientierte Programmierung mit dem UML-Klassendiagramm

https://bildung.social/@oerinformatik/

https://oer-informatik.de/uml-klassendiagramm

tl/dr; (ca. 9 min Lesezeit): Übungsaufgabe zu Grundlagen der Objektorientierung und zum UML-Klassendiagramm. Es soll ein Ticketautomat modelliert werden mit Objektbeziehungen, Klassenbeziehungen, Kapselung, Polymorphie. (Zuletzt geändert am 05.04.2025)

Die Software eines Ticketautomats soll objektorientiert modelliert werden.

1. Jedes Ticket verfügt über einen spezifischen Preis, eine Ticketnummer und hat den Zustand bezahlt oder nicht bezahlt. Neue Tickets können nur erzeugt werden, wenn eine Ticketnummer mit übergeben wird. Jedes Ticket verfügt über eine Methode, mit der geprüft werden kann, ob das Ticket gültig ist. Um alle Eingaben validieren zu können, sollen alle Eigenschaften gekapselt werden.

   1. Was ist die Aufgabe eines Konstruktors?Antwort ein/ausblenden

   Konstruktoren sind diejenigen Methoden einer Klassen, die aufgerufen werden, wenn aus einer Klasse ein Objekt instanziiert wird. Konstruktoren legen fest, welche Parameter bei der Objekterzeugung übergeben werden müssen (oder können). Konstruktoren haben die Aufgabe, alles bereitzustellen (Abhängigkeiten, Defaultwerte, usw.), was das Objekt von Beginn an benötigt. In vielen Programmiersprachen heißt der Konstruktor genau wie die Klasse (in diesem Beispiel also: Ticket(...)), in Python trägt er einen speziellen Namen: __init__().

   2. Was versteht man unter “Kapselung”?Antwort ein/ausblenden

   Kapselung beschreibt, dass der Zugriff auf den Zustand eines Objekts (also auf die Attribute) von außerhalb eingeschränkt wird. Gekapselte Attribute erhalten die Sichtbarkeit private (nur innerhalb der Klasse sichtbar, UML: -) oder protected (nur innerhalb der Vererbungshierarchie sichtbar, UML: #). Damit kann nur noch innerhalb des Objekts auf dessen Zustand zugegriffen werden. Will man von außerhalb des Objekts auf den Zustand zugreifen, so nutzt man Getter- und Setter-Methoden, die öffentlich sichtbar (public, UML: +) sind. Kapselung eine rudimentäre erste Möglichkeit, das Information hiding Principle umzusetzen.

   Beispielcode eine gekapselten Attributs sieht z.B: in Java so aus:

   
   private double preis;
   public double getPreis(){
       return preis;
   }
   public void setPreis(double preis){
       this.preis = preis;
   }

   Python nutzt das Konzept der partiellen Sichtbarkeit nicht - hier kann man Properties nutzen oder die Attribute durch doppelten Unterstrich “verstecken” (self.__preis), wenn man das Konzept nachstellen will.

   3. Erstelle ein UML-Klassendiagramm für die oben genannte Klasse.Antwort ein/ausblenden

   

2. Neben den allgemeinen Tickets gibt es auch noch speziellere Tickets: Tagestickets und Saisontickets.

   • Tagesticket verfügen über ein Gültigkeitsdatum. Außerdem muss die Methode, die die Gültigkeit prüft, jetzt zusätzlich noch das Datum (Datentyp Date) prüfen. Tagestickets können nur erzeugt werden, wenn neben der Ticketnummer auch das Gültigkeitsdatum übergeben wird.

   • Saisontickets verfügen über einen Gültigkeitsbeginn und ein Gültigkeitsende. Bei der Ticketerzeugung muss die Ticketnummer, Gültigkeitsbeginn, Gültigkeitsende oder Ticketnummer, Gültigkeitsbeginn und Gültigkeitsdauer (in ganzen Tagen) übergeben werden. Auch hier muss die Methode zur Gültigkeitsprüfung erweitert werden.

   1. Was versteht man unter Überschreibung?Antwort ein/ausblenden

   Unter Überschreibung versteht man, wenn eine erbende Klasse eine Methode der Elternklasse neu implementiert und somit nicht deren Verhalten übernimmt. Dabei spielt es keine Rolle, ob die Methode der Elternklasse selbst wieder in der neuen Implementierung aufgerufen wird.

   Beispiel (Pseudocode / JANA):

   
   class Hund{
       belle(){
           print("Wuff")
       }
   }
   
   class Dackel extends Hund{
       belle(){
           print("Wau Wau")
       }
   }

   2. Was versteht man unter Überladung?Antwort ein/ausblenden

   Man nennt Methoden überladen, wenn es mehrere Methoden gibt, die den gleichen Namen, aber unterschiedliche Parametersätze haben. Sie unterscheiden sich in der Signatur (Name + Parameter), gelten somit eigentlich als komplett unabhängige Methoden. Üblich ist aber, dass identisch benannte Methoden das selbe Ziel verfolgen. Häufig ruft die speziellere Methode die allgemeinere auf, wie hier in diesem Pseudocode-Beispiel:

   
   class Robo{
       sageName(String name){
           print("Mein Name ist "+ name)
       }
       sageName(){
           sageName("Robo")
       }

   3. Erweitere das UML-Klassendiagramm aus der obigen Aufgabe um die beiden neuen Klassen Tagesticket und Saisonticket.Antwort ein/ausblenden

   

   4. Erkläre an dem Beispiel, was man unter “Polymorphie” versteht.Antwort ein/ausblenden

   Das Prinzip “Polymorphie” (“Vielgestalt”) beschreibt, dass ein Objekt in unterschiedlicher Gestalt auftreten kann. Das heißt, dass ein Objekt über Referenzen des Objekts selbst, über Referenzen der Elternelemente oder der implementierten Interfaces angesprochen werden kann.

   Dieses Konzept ist v.a. in stark typisierten Programmiersprachen relevant, in denen eine Referenz einen festen Referenztypen (die Klasse/das Interface der Referenz) hat.

   Im Rahmen der Polymorphie ist es wichtig, zwischen dem Instanztypen und dem Referenztypen zu unterscheiden: Instanztyp ist diejenige Klasse, aus der das Objekt erzeugt wird (durch Aufruf des Konstruktors, z.B. Tagesticket bei new Tagesticket()). Referenztyp ist derjenige Typ, mit dem die Variable deklariert wurde, der dann die Instanz zugewiesen wurde. Das ist häufig der gleiche Typ wie der Instanztyp, kann aber auch abweichen (z.B. ist der Referenztyp Ticket bei Ticket seinTicket = new Tagesticket();).

   Hierbei gibt der Referenztyp vor, welche Member (Methoden und Attribute) sichtbar sind. Der Instanztyp des Objektes gibt vor, welche Implementierung ausgeführt wird.

   Am Beispiel oben als Pseudocode erklärt:

   Ticket meinTicket = new Ticket(); //Referenztyp und Objekttyp ist identisch
   
   Tagesticket deinTicket = new Tagesticket(); //Referenztyp und Objekttyp ist identisch
   
   Ticket seinTicket = new Tagesticket(); //Referenztyp Ticket,  Objekttyp Tagesticket
   
   // nur die Methoden und Attribute, die Ticket hat, sind zugreifbar
   // verwendet wird aber die Implementierung von Tagesticket (z.B. bei istGueltig())
   seinTicket.istGuetlig(); //Aufruf möglich, da in Ticket vorhanden

3. In einer Buchung werden ein oder mehrere Tickets zusammengefasst, Tickets existieren nur in Buchungen. Mehrere Buchungen können in einer Rechnung zusammengefasst werden, existieren aber auch ohne zugehörige Rechnung.

   1. Wie nennt man die Objektbeziehung zwischen Ticket und Buchung?Antwort ein/ausblenden

   Es handelt sich um eine Komposition.

   Allgemein handelt es sich zunächst um eine Assoziation - also um zwei Objekte, bei denen ein Objekt die Member (Methode/Attribute) des anderen nutzt.

   Spezieller handelt es sich hierbei um eine Teil-Ganzes Beziehung: das Teil (Ticket) wird als Attribut (oder Attribut-Liste) innerhalb des Ganzen (Buchung) realisiert. Das Teil existiert nur innerhalb des Ganzen: es gibt keine Referenz auf ein Ticket außerhalb einer Buchung (also keine öffentliche Methode, die ein Ticket entgegennimmt oder zurückgibt, das Ticket Attribut ist privat gesetzt). Folglich wird beim Löschen der Buchung auch das Ticket gelöscht. Diese spezielle Konstellation nennt man Komposition.

   2. Wie nennt man die Objektbeziehung zwischen Buchung und Rechnung? Antwort ein/ausblenden

   Es handelt sich um eine Aggregation.

   Allgemein handelt es sich wie oben zunächst um eine Assoziation - also um zwei Objekte, bei denen ein Objekt die Member (Methode/Attribute) des anderen nutzt.

   Speziell handelt es sich hierbei (ebenso wie oben) um eine Teil-Ganzes Beziehung. Allerdings existiert das Teil (Buchung) auch außerhalb des Ganzen (Rechnung): es kann also Referenzen auf das Teil außerhalb des Ganzen geben. Praktisch heißt das: es gibt Methoden, die Buchungen zurückgeben oder übergeben bekommen. Folglich wird beim Löschen einer Rechnung nicht in jedem Fall auch die zugehörige Buchung gelöscht. Diese spezielle Konstellation nennt man Aggregation.

   3. Erstelle ein UML-Klassendiagramm der Klassen Ticket, Rechnung und Buchung.Antwort ein/ausblenden

   

Links und weitere Informationen

• Primärquelle: Klassendiagramme werden in Kapitel 11.4 der aktuellen Spezifikation von UML definiert: https://www.omg.org/spec/UML

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Einstieg in objektorientierte Programmierung mit dem UML-Klassendiagramm” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-klassendiagramm veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/umlklasse. Stand: 05.04.2025.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]