Objektorientierte Programmierung
LVA 185.162, VL 2.0, 2007 W

7. Übungsaufgabe

Themen:

dynamische Typvergleiche, Typumwandlungen, kovariante Probleme

Termine:

Ausgabe:	06.12.2007
reguläre Abgabe:	13.12.2007, 12:45 Uhr
nachträgliche Abgabe:	20.12.2007, 12:45 Uhr

Abgabeverzeichnis:

Aufgabe7

Programmaufruf:

java Test

Grundlage:

Skriptum bis Seite 124

Aufgabe

Welche Aufgabe zu lösen ist:

Arithmetische Ausdrücke werden oft als Bäume dargestellt (z.B. in Compilern). Die Blattknoten (Knoten ohne Nachfolger) enthalten Zahlen, alle anderen Knoten mathematische Operatoren wie z.B. +, *, trunc (Abschneiden einer Gleitkommazahl zu einer ganzen Zahl) oder int2float (Konvertierung einer ganzen Zahl zu einer Gleitkommazahl). Der Ausdruck (3 + 5) * trunc(2.7) sieht folgendermaßen aus:

        *
      /   \
     +    trunc
   /   \     \
  3     5    2.7

Ausdrücke in Baumform können ausgewertet werden, indem in jedem Teilbaum zuerst die Argumente und danach die Operation im Wurzelknoten ausgewertet werden (3 + 5 -> 8, trunc(2.7) -> 2, 8 * 2 -> 16). Bei den binären Operationen müssen die beiden Operanden und das Ergebnis vom selben Typ sein (ganze Zahlen oder Gleitkommazahlen), bei der unären Operation trunc ist der Operand eine Gleitkommazahl und das Ergebnis eine ganze Zahl, bei der unären Operation int2float ist der Operand eine ganze Zahl und das Ergebnis eine Gleitkommazahl. Stimmen die Typen der Operanden nicht überein, ist das Ergebnis einer Auswertung eine spezielle ungültige Zahl (z.B. ergibt trunc(2) -> ungültige Zahl).

Definieren Sie ihre eigene Klassenhierarchie zur Darstellung von Zahlen mit einem Obertyp Number und den Untertypen MyInteger (ganze Zahlen), MyFloat (Gleitkommazahlen) und NotaNumber (ungültige Zahl). Diese Klassenhierarchie kann in Zukunft beliebig erweitert werden, d.h. sowohl Number selbst als auch alle Untertypen von Number können weitere Untertypen haben.

Entwickeln Sie Java-Klassen bzw. Interfaces zur Darstellung von Knoten von Ausdrücken in Baumform. Es werden eigene Knotentypen für jeden Operator (+, *, trunc, ...) benötigt. Alle Typen zur Knotendarstellung müssen mindestens eine Methode mit dem Namen eval besitzen, die den Wert des durch den Baum dargestellten Ausdrucks berechnet. Bei Blattknoten liefert sie den gespeicherten Wert vom Typ Number. Andere Knoten müssen das Ergebnis aus den Operanden (Teilbäumen) berechnen. Dabei ist darauf zu achten, dass bei Addition und Multiplikation nur gleiche Operandentypen erlaubt sind. Sonst liefert die Berechnung eine ungültige Zahl (NotaNumber). Ein gültiges Ergebnis liefert trunc nur, wenn der Operand eine Gleitkommazahl ist, und int2float nur, wenn der Operand eine ganze Zahl ist. Der Wert eines Blattknotens soll jederzeit durch einen anderen Wert (auch von einem anderen Typ) ersetzt werden können.

Die Klasse Test soll die wichtigsten Normal- und Grenzfälle (nicht interaktiv) überprüfen und die Ergebnisse in allgemein verständlicher Form in der Standardausgabe darstellen. Unter anderem sollen Bäume aus ganzen Zahlen und Gleitkommazahlen und mit mindestens den Operationen +, *, trunc und int2float erstellt und ausgewertet werden. Es sollen auch Bäume ausgewertet werden, die als Ergebnis eine ungültige Zahl liefern.

Wie die Aufgabe zu lösen ist:

Beachten Sie, dass kovariante Probleme nicht direkt durch Subtyping dargestellt werden können. Achten Sie bei dynamischen Typüberprüfungen darauf, ob Sie instanceof oder getClass verwenden. Versuchen Sie, statische Typinformation zu verwenden, wo immer dies möglich ist, und setzen Sie dynamische Typabfragen und Typumwandlungen sparsam ein.

Lassen Sie sich durch den Begriff Baum nicht verwirren: Es werden nur Typen für Knoten von Bäumen benötigt, und es soll nicht überprüft werden, ob die erzeugten Strukturen wirklich Bäume sind.

Hinweise zur Beurteilung:

Der Schwerpunkt bei der Beurteilung liegt auf der vernünftigen Verwendung von dynamischer und statischer Typinformation (Typvergleiche und Typumwandlungen). Kräftige Punkteabzüge gibt es für

den unnötigen Verlust an statischer Typsicherheit
nicht verallgemeinerbare Erweiterungen (das heißt, das Programm funktioniert nur, wenn keine weiteren Klassen hinzukommen),
Verletzungen des Ersetzbarkeitsprinzips bei Verwendung von Vererbungsbeziehungen
und mangelhafte Funktionalität des Programms.

Punkteabzüge gibt es, wie bereits üblich, auch für unnötigen (oder unnötig komplexen) Code, mangelhafte Zusicherungen und falsche Sichtbarkeit.

Was im Hinblick auf die Abgabe zu beachten ist:

Schreiben Sie Ihre Lösung in das bereits existierende Verzeichnis Gruppe/Aufgabe7. Das Programm soll von diesem Verzeichnis aus durch java Test aufrufbar sein. Schreiben Sie (abgesehen von geschachtelten Klassen) nicht mehr als eine Klasse in jede Datei. Das Verzeichnis soll zu den Abgabezeitpunkten alle .java-Dateien enthalten, die Sie für Ihre Lösung benötigen. Bitte entfernen Sie alle .java-Dateien, die nicht zur Abgabe gehören. Dateien mit anderen Endungen werden bei der Beurteilung nicht berücksichtigt. Verzichten Sie auf die Verwendung von Verzeichnissen innerhalb von Gruppe/Aufgabe7.