PHP – Endlich objektorientiert- P8

Da ein Objekteine Instanz, also ein Exemplar oder ein Beispiel einer Klasse darstellt, ist es sinnvoll,zunächst diese Beispiele zu betrachten, bevor man die abstrakteren Klassen modellie

Abbildung 3.46: Erfolgreiches Buchen eines Seminars auf Meeresspiegelebene

Diesem positiven Beispiel wird in Abbildung 3.47 ein Fehlschlag gegenübergestellt Indiesem Szenario hat sich der Kunde den Link auf einen Seminartermin in den Book-marks seines Internetbrowsers gemerkt und ruft diesen Link nun ab

Er gibt auch hier seine persönlichen Daten ein und erzeugt ein Buchungsobjekt, das anden Server gesendet wird Der Seminartermin ist jedoch bereits ausgebucht; der Kundehat sich also zu spät angemeldet

In diesem Fall ist vorgesehen, dass der Kunde eine Mitteilung erhält, dass dieser Terminbereits ausgebucht ist Zusätzlich erhält er eine Liste mit anderen möglichen Terminensowie eine Kontaktanschrift des Seminaranbieters Das Ziel des Geschäftsprozessesbesteht darin, den buchungswilligen potenziellen Kunden nicht zu verlieren

Abbildung 3.47: Buchungsversuch auf ein bereits ausgebuchtes Seminar

Objekte und Klassen in der Analyse

In der Praxis begehen Entwickler oft den Fehler, Klassendiagramme zu früh zu erstellen,

da sie ja möglichst bald entwickeln wollen und die Sachverhalte bereits sehr klar nen Dies ist jedoch eine trügerische Annahme

erschei-In der UML existiert ein weiterer Diagrammtyp, der zu wenig Beachtung findet DieObjektdiagramme sind an die Notation der Klassendiagramme angelehnt Da ein Objekteine Instanz, also ein Exemplar oder ein Beispiel einer Klasse darstellt, ist es sinnvoll,zunächst diese Beispiele zu betrachten, bevor man die abstrakteren Klassen modelliert;siehe dazu auch Abbildung 3.12, in der die Realität über die Objekte zu den Klassen abs-trahiert wird

Meinung

Eine gute Übung ist es, wenn Sie im Internet nach bereits fertigen men suchen und diese kritisch beurteilen Verstehen Sie den Ablauf? Ist er eindeutigspezifiziert? Was könnte man besser machen? Wenn Sie eine Vielzahl von Diagram-men gesehen und am besten mit anderen Personen diskutiert haben, werden Sie zueinem besseren Analytiker für objektorientierte Anwendungen

Aktivitätsdiagram-Beispiel

Ein Kunde hat Ihnen das Beispiel aus Abbildung 3.48 aufgezeichnet, welches Sie imnächsten Projekt in einer PHP-Anwendung realisieren sollen Der Kunde möchtegern ein Tool programmiert bekommen, mit dem man beliebig viele Punkte undDreiecke in ein bereits bestehendes Koordinatensystem eintragen kann

Abbildung 3.48: Von einem Kunden erstelltes Beispiel

Bevor Sie nun über dieses Beispiel diskutieren, sollten Sie es in ein Objektdiagrammüberführen Diese Umwandlung ist relativ einfach; viele Entwickler sehen sie deshalb als

zu trivial an Der Vorteil der Objektdiagramme besteht jedoch darin, dass Sie jedes bige Beispiel auf diese Weise in eine einheitliche Notation überführen können - genaudies ist der Sinn der UML Zusätzlich sind Objektdiagramme so nah am Beispiel orien-tiert, dass der Kunde die Objektdiagramme selbst noch lesen und dadurch wie auchAnwender und andere Stakeholder einen Einstieg in die Modellierung finden kann.Was also erkennen Sie in Abbildung 3.48? Es sind 3 Dreiecke und 9 Punkte zu erkennen

belie-Es gibt also Dreiecke und Punkte Damit haben Sie bereits die Klassen identifiziert Wie stehen die Klassen in Verbindung zueinander? Ein Punkt kann alleine existieren,siehe P6 Ein Dreieck kennt immer genau drei Punkte Ein Punkt kann aber auch mehrereDreiecke kennen, siehe P3

Aus was bestehen ein Dreieck und ein Punkt? Ein Dreieck besteht aus drei Punkten EinPunkt wiederum besteht aus genau zwei Koordinaten Alle diese Sachverhalte könnenSie in der normierten Darstellung auch in Abbildung 3.49 erkennen

Abbildung 3.49: Objektdiagramm des Beispiels

Zentriert im oberen Viereck eines Objekts steht zunächst dessen Name und durch einenDoppelpunkt getrennt der Name der Klasse Dies alles ist unterstrichen, um eine bessereUnterscheidbarkeit zu den Klassendiagrammen zu gewährleisten.

Besitzt ein Objekt zusätzliche Eigenschaften, werden sie in einem zweiten Viereck unterdem Namen benannt und deren aktuelle Wertausprägungen für das jeweilige Objekt ein-getragen Bei den Punkten sind dies die jeweiligen x- und y-Koordinaten Wenn einObjekt ein anderes Objekt kennt, wird diese Assoziation in einer Programmierspracheauch über eine Eigenschaft abgebildet Die Kenntnis von Objekten untereinander wirdjedoch in den Objekt- und auch in den Klassendiagrammen durch eine Linie gekenn-zeichnet Der Fokus der Assoziation liegt darin, dass zwei Klassen miteinander kommu-nizieren, die aber ansonsten eigenständig sind

Methoden werden in einem Objektdiagramm nicht berücksichtigt, da alle Objekte einerKlasse stets dieselben Methoden besitzen Bei den Objektdiagrammen nähert man sichalso der Modellierung über die gemeinsamen Eigenschaften von Objekten an

Abbildung 3.50: Objekt ohne Klassenbeschreibung und anonymes Objekt

Abbildung 3.50 zeigt in der linken Darstellung, dass Sie den Namen der Klasse nicht

bereits kennen müssen, wenn Sie ein Objektdiagramm zeichnen Frank kann ein Kunde,

Lieferant, Mitarbeiter oder nur irgendeine Person sein Genauso können Sie auch nyme Objekte erstellen, wenn Sie die Objekte nicht konkret benennen möchten So defi-niert die rechte Darstellung der Abbildung „ irgendeinen Kunden“

ano-Für die Implementierung können Sie aus dem Objektdiagramm als lage jedoch noch viel mehr erkennen Zunächst können Punkte auch ohne Dreiecke exis-tieren Sie können also beliebige Punkte zeichnen Wenn Sie aber ein neues Dreieck zeich-nen wollen, müssen Sie bereits in dessen Konstruktor drei Punkte übergeben, daansonsten das Dreieck nicht existieren kann

Diskussionsgrund-Die nächste Frage, die Sie sich als aufmerksamer Entwickler stellen müssen, lautet: nen Sie aus drei beliebigen Punkten ein Dreieck erstellen? Dies geht sicherlich nicht,wenn die drei Punkte auf derselben x- oder y-Koordinate liegen Denn dann würden Siekein gültiges Dreieck, sondern eine Strecke erzeugen, die keinen Flächeninhalt besitzt.Außerdem könnten Sie keine Winkelberechnungen durchführen, die ja vielleicht alsMethoden eines Dreiecks sinnvoll sind Genügt es also zu prüfen, ob sich die drei x- undy-Koordinaten der Punkte unterscheiden? Dazu kann man ein Gegenbeispiel erzeugen:P1x=1, P1y=1

Kön-P2x=2, P2y=2P3x=4, P3y=4Auch hier wird eine Strecke und kein Dreieck erzeugt Im Konstruktor eines Dreiecks

müssen Sie mit zwei der drei Punkten über die Geradengleichung y=ax+b eine Gerade

erzeugen und prüfen, ob der dritte Punkt auf dieser Geraden liegt Wenn dies der Fall ist,darf das Dreieck nicht erzeugt werden

Die Existenz des Dreiecks ist also von drei Punkten abhängig und jedes Dreieck kenntseine drei Punkte Wenn ein Punkt verschoben wird, verändern sich auch alle Dreiecke,die aufgrund dieses Punktes existieren Auch hier müssen Sie darauf achten, dass stetsalle Dreiecke gültig bleiben.

Als Nächstes müssen Sie sich fragen, ob ein Punkt auch seine Dreiecke kennen muss Aufden ersten Blick scheint dies nicht nötig zu sein Was jedoch geschieht, wenn Sie einenPunkt löschen? In diesem Fall muss dieser zu löschende Punkt auch allen angeschlosse-nen Dreiecken den Befehl geben, sich zu löschen, da diese Dreiecke nicht ohne diesenPunkt existieren können Jeder Punkt muss also auch eine Liste mit angeschlossenenDreiecken verwalten Und wenn ein Dreieck gelöscht wird, muss es allen drei Punktenebenso mitteilen, dass es nicht mehr existiert Denn ansonsten würden diese Punkte nochReferenzen auf ein Dreieck besitzen, das nicht mehr existiert

Aus dem in Abbildung 3.48 dargestellten Objektdiagramm der Analyse müssen Sie imnächsten Schritt ein Klassendiagramm der Analyse erstellen Der Fokus der Analysebesteht darin, die Klassen und deren Beziehungen zu ermitteln Es wurde bereits festge-

stellt, dass die Klassen Punkt und Dreieck existieren, die sich gegenseitig kennen

Die möglichen Darstellungen einer Assoziation finden Sie in Abbildung 3.51 Wennkeine Pfeile eingezeichnet sind, machen Sie noch keine Aussage darüber, welche Klassewelche andere kennt Gerade zu Beginn der Analysephase ist dies üblich

Zusätzlich wird in der Abbildung ausgesagt, dass K3-Objekte K4-Objekte kennen können

Ob K4-Objekte auch K3-Objekte kennen können, ist nicht spezifiziert worden Wenn Sieeine Kenntnis explizit verbieten wollen, müssen Sie dies durch ein Kreuz darstellen So ist

es zwar sinnvoll, dass ein Richter Zugriff auf die Informationen eines Sträflings erhält,jedoch sollte dieser verständlicherweise aus Datenschutzgründen nicht den Wohnort undFamilienverhältnisse des Richters kennen dürfen Der untere Teil der Abbildung zeigt diegegenseitige Bekanntschaft zwischen Punkten und Dreiecken Welche Objekte welcheanderen Objekte kennen können, wird als Navigierbarkeit bezeichnet

Meinung

Dieser Ausblick, der von einem Objektdiagramm ausgeht und bis tief in die mentierung reicht, zeigt die notwendige Disziplin und Sorgfalt, die man als Analyti-ker und auch als Entwickler bei der (objektorientierten) Programmierung besitzenmuss Dies wird noch unterstützt davon, dass Sie als Autor der Klassen Punkt undDreieck bei Fehlern wesentlich leichter zur Verantwortung gezogen werden könnenals bei einem prozedural entwickelten Projekt, bei dem die Aufgaben mehrerer Ent-wickler nicht so stark voneinander trennbar sind

Imple-Abbildung 3.51: Navigierbarkeit der Assoziationen

Ein erstes Klassendiagramm der Analyse kann daher so aussehen, wie es in Abbildung3.52 dargestellt ist Jede Assoziation kann mit einer Beschriftung versehen werden, diedie Assoziation näher textuell beschreibt Der schwarze Pfeil zeigt dabei die Leserich-tung der Beschriftung an, also in diesem Fall „ Punkt – kann Eckpunkt sein von – Drei-eck“

Abbildung 3.52: Erstes Klassendiagramm der Analyse

Ein Punkt kann Eckpunkt eines Dreiecks sein, muss es aber nicht Ein Dreieck bestehtaber stets aus genau drei Eckpunkten Diese Abhängigkeiten werden als Multiplizitätenbezeichnet, die im Laufe der objektorientierten Analyse immer mehr herausgearbeitetwerden Abbildung 3.52 enthielt noch unspezifizierte Multiplizitäten Die Möglichkeit,Diagramme mehr oder weniger detailliert anzugeben, ist typisch für die UML-Spezifika-tion und macht diese Sprache für eine iterative Vorgehensweise tauglich, bei der die zuerstellende Software in mehreren Stufen verfeinert wird

Abbildung 3.53: Angabe von Multiplizitäten

Wenn man die Analyse des Dreieck-Punkte-Beispiels weiter fortführt, so fällt die che auf, dass ein Dreieck aus Punkten besteht Ein Punkt kann aber auch allein existierenoder gleichzeitig zu mehreren Dreiecken gehören Dabei handelt es sich folglich um eineAggregation Diese Beziehung wird in der UML durch eine nichtausgefüllte Raute dar-

Tatsa-gestellt Zusätzlich können noch die x- und y-Koordinaten als Eigenschaften der Punkteangegeben werden.

Abbildung 3.54: Fertiges Klassendiagramm der Analyse für Punkte und Dreiecke

Eine Komposition unterscheidet sich in der UML nur durch die Tatsache, dass in diesemFall eine ausgefüllte Raute verwendet wird Außerdem sollte man keine Multiplizität aneiner Komposition angeben, da diese stets 1 beträgt Genau so ist ja die Kompositiondefiniert

Als Beispiel für eine Komposition kann man eine Datei sehen, die sich stets in einem zeichnis befinden muss Eine Datei ist ohne eine Verzeichnisstruktur nicht existenzfähig.Wird eine Datei gerade über ein Netzwerk übertragen, so verliert sie für eine gewisseZeit ihre Existenz als Datei Man könnte sie dann als Datenstrom oder als Datenpaketebezeichnen Ein Verzeichnis kann jedoch auch leer sein, also keine Dateien enthalten

Ver-Abbildung 3.55: Beispiel einer Komposition

Ebenso werden fachliche Vererbungsbeziehungen in der objektorientierten Analyse

fest-gehalten Im folgenden Beispiel einer Universität wurden die Klassen Angestellter, dent und Hilfskraft mit einigen Eigenschaften und Methoden bereits ermittelt Die Namen

Stu-der Methoden werden separiert unter die Eigenschaften geschrieben An dem Beispielder Abbildung 3.56 fällt eine große Schnittmenge der Eigenschaften und der Methodenauf Da eine doppelte Implementierung von identischem Quellcode zur besseren Wart-barkeit zu vermeiden ist, sollte in einem solchen Fall eine Vererbung genutzt werden

Abbildung 3.56: Klassen vor Einführung einer Vererbungshierarchie

Offensichtlich beinhalten alle Klassen die Eigenschaften name, anschrift und tum, was auf eine Vererbungsstruktur deutet Zusätzlich ist überall die Methode drucke- Anschrift() vorhanden Sowohl die Studenten, als auch die Hilfskräfte besitzen die Eigen- schaften matrikelnr, immatrikulation und die Methode druckeAusweis().

geburtsda-Der Unterschied zwischen diesen beiden Klassen besteht nur darin, dass eine Hilfskraftzusätzlich Beschäftigungen hat und eine Liste ihrer Arbeitszeiten drucken kann EineHilfskraft ist also ein spezieller Student, sodass die Vererbung hier eindeutig festgehal-ten werden kann

Eine Hilfskraft ist jedoch nicht fest angestellt Ebenso ist ein Angestellter kein Student, dadiese Klassen jeweils verschiedene Attribute besitzen, beispielsweise eine Personalnum-mer anstatt einer Matrikelnummer Hier lässt sich also keine direkte Vererbung auf-bauen Die Lösung besteht darin, alle Gemeinsamkeiten der drei Klassen in einer abs-trakten Oberklasse als Container für gemeinsame Eigenschaften und Methodenzusammenzufassen So resultiert die Klassenhierarchie aus Abbildung 3.57 Abstrakte

Klassennamen werden kursiv geschrieben oder um den Vermerk {abstract} ergänzt

Wie es bei einer Vererbung typisch ist, werden alle Eigenschaften und Methoden derOberklasse auf die Unterklasse mit vererbt Wie Sie erkennen, ist keine mehrfache Dekla-

ration mehr vorhanden Den Vererbungspfeil können Sie mit der Phrase ist ein benennen.

So ist ein Angestellter eine Person, ebenso wie ein Student Eine Hilfskraft ist ein ler Student

speziel-Abbildung 3.57: Resultierende Vererbungshierarchie

Ein sehr hilfreiches, jedoch zu selten eingesetztes Mittel der UML sind die ren, mit denen Sie spezifizieren, wie Sie eine Vererbung durchführen Abbildung 3.58zeigt, dass Sie Angestellte spezialisieren können nach Vollzeit- und Teilzeitkräften.Andererseits können Sie in Ihrer Anwendung auch eine Unterscheidung anhand derTätigkeiten der Angestellten vornehmen Beide Ideen sind sicherlich korrekt Welche Artder Vererbung Sie letztlich wählen, hängt von der Art der Anwendung ab, die Sie erstel-len wollen Wenn Sie in Ihrer Anwendung eher Arbeitszeiten verwalten, so ist die ersteIdee sinnvoller, bei einer Verwaltung von Berufsgruppen die zweite

Diskriminato-Es ist in der Analyse durchaus üblich, mehrere richtige Lösungen zu erstellen, die jedochvöllig verschiedene Ansätze verfolgen Letztlich sollten Sie mit der Zeit erkennen, wel-cher Lösungsansatz der bessere ist

Abbildung 3.58: Vererbung mit Diskriminatoren

Wenn eine Assoziation zwischen zwei Klassen komplexer dargestellt werden muss alsmit einer stichwortartigen textuellen Beschreibung, dann kann man dazu in der Analyse-phase eine eigene Klasse verwenden, die die Assoziation genauer beschreibt

Nehmen wir als Beispiel an, Sie wollen die Beziehung zwischen einem Leser und einemBuch genauer beschreiben Da es sich um eine Bibliothekssoftware handeln soll, sindLeser und Bücher über Ausleihen miteinander verbunden Eine Ausleihe hat unter ande-rem ein Datum, zu dem der Leser das Buch ausgeliehen hat und die Möglichkeit, dieAusleihe ein- oder mehrfach zu verlängern Wie die Assoziationsklasse letztlich umge-setzt wird, ist Aufgabe der Entwickler im Systemdesign

Abbildung 3.59: Beispiel einer Assoziationsklasse

Assoziationen sind auch zwischen mehr als zwei Klassen möglich Diese Assoziationenwerden als „ n-äre Assoziationen“ bezeichnet So wird die Beziehung zwischen einemPassagier, einem Flug und einem Sitzplatz über die Reservierung hergestellt Das Erken-nen solcher Zusammenhänge bildet den Kern der objektorientierten Analyse

Abbildung 3.60: Beispiel einer n-ären Assoziation

Eine weitere Besonderheit der objektorientierten Analyse sind reflexive Assoziationen,bei denen Objekte einer Klasse andere Objekte derselben Klasse kennen können Dabeisind oft verschiedene Rollen von Bedeutung, deren Bezeichnung an die Assoziationgeschrieben werden können

Im Beispiel in Abbildung 3.61 sind sowohl die Chefs als auch deren Mitarbeiter stellte eines Unternehmens Da Angestellte nur einmalig mit ihrer Personalnummer imSystem registriert sein sollen und ein Angestellter gleichzeitig Chef und Mitarbeiter sein

Ange-kann, macht eine Aufspaltung der Klasse in die Klassen Chef und Mitarbeiter keinen Sinn.

Abbildung 3.61: Beispiel einer reflexiven Assoziation

Wie würden Sie eine solche Beziehung realisieren? Im Quellcode bedeutet dies, dass die

Klasse Angestellter zwei Datenfelder als Eigenschaften verwaltet In dem ersten Feld ChefVon werden die Referenzen auf andere Angestellte gespeichert, von denen dieser Angestellte der Vorgesetzte ist Das zweite Feld $istMitarbeiterVon beinhaltet Referenzen

$ist-auf Angestellte, denen dieser Angestellte weisungsbefugt ist Generell kann eine xive Assoziation stets mit zwei Datenfeldern realisiert werden

refle-Beispiel

Wie sind ein Kaufinteressent, ein Artikel und ein Verkäufer in der Modellierung einander verbunden? Die Antwort lautet: Über ein Verkaufsgespräch, das im Nach-hinein protokolliert wird

mit-Als abschließendes Beispiel der Analysephase wird nochmals das Beispiel der verwaltung aufgegriffen Abbildung 3.62 zeigt zunächst ein Objektdiagramm Das Ver-waltungssystem verwaltet Seminare mit deren Terminen Die Abbildung zeigt zwei kon-krete Termine, wobei es bei einem Termin bereits zwei Anmeldungen von Kunden gibt.Das Anmeldungsobjekt verbindet also die Kunden mit einem Seminartermin Zusätzlichwerden jedem Termin ein Raum und ein Dozent zugeordnet.

Seminar-Abbildung 3.62: Objektdiagramm der Seminarverwaltung

Im nächsten Schritt wird nun aus diesem Objektdiagramm das Klassendiagramm derAnalysephase abgeleitet Die Namen der Klassen kann man bereits aus dem Objektdia-gramm entnehmen Sie lauten

ein-Abbildung 3.63: Erstes Klassendiagramm der Seminarverwaltung (Analysephase)

Klassen im objektorientierten Design

In der Designform beinhalten Klassendiagramme alle notwendigen Methoden undEigenschaften Es existieren bereits Modellierungswerkzeuge, die aus solchen Diagram-men Coderümpfe für verschiedene objektorientierte Programmiersprachen wie Java, C#und auch PHP generieren Diese müssen dann vom Entwickler nur noch mit Funktiona-lität gefüllt werden

Während sich die objektorientierte Analyse auf den Geschäftsprozess konzentriert undihn in einem fachlichen Modell abbildet, fokussiert sich das objektorientierte Design aufdas so genannte technische Modell Dies ist die weitere Abstraktion des fachlichenModells auf die Fähigkeiten einer objektorientierten Programmiersprache Die hiererstellten Diagramme (zumeist Klassen-, Zustands- und Sequenzdiagramme) dienenden Entwicklern als direkte Vorlage für die objektorientierte Programmierung Hierkann man erkennen, dass der Aufwand der Implementierung im Vergleich zur Analyseund Design geringer geworden ist, wie es im RUP-Modell beschrieben wurde Dies giltebenso für die Verwendung agiler Methoden, die den Kunden durch das iterativ-inkre-mentelle Vorgehen stärker in den Entwicklungsprozess einbeziehen

Diese Funktionalität wird in Sequenz- und Zustandsdiagrammen beschrieben, die dieInteraktion von Objekten untereinander beschreiben Diese Diagramme werden wiede-rum von den Anwendungsfall- und Aktivitätsdiagrammen abgeleitet.

Zunächst einmal muss in einem vollständigen Klassendiagramm angegeben werden,wie jede Eigenschaft und jede Methode außerhalb der Klasse von anderen Objekten

gesehen wird Es wurde bereits gesagt, dass Eigenschaften standardmäßig private sein

sollen, um die Datenkapselung der Objektorientierung zu gewährleisten Wenn schaften auch direkt aus Unterklassen angesprochen werden sollen, können diese als

Eigen-protected deklariert werden Methoden sind Dienste der Klasse, die normalerweise von anderen Klassen verwendet werden sollen Daher sind Methoden im Normalfall public

einzustufen Nur wenn es sich um Hilfsmethoden handelt, die innerhalb der Klasse

ver-wendet werden, sollten diese private oder protected deklariert werden Für diese

Sichtbar-keiten besitzt die UML eine eigene Schreibweise

Abbildung 3.64: Sichtbarkeiten public, protected und private

Bei den Attributen sollten Sie in der Designphase zusätzlich die zu verwendendenDatentypen und falls nötig den Startwert angeben, der bei der Erzeugung eines neuenObjekts verwendet werden soll Bedenken Sie, dass sich jedes Objekt zu jedem Zeitpunkt

in einem gültigen Zustand befinden muss So ist ein Bruch, der die Eigenschaften zähler und nenner hat, bei nenner=0 ungültig und darf nach den Regeln der Mathematik nicht

als Bruch bezeichnet werden Achten Sie daher stets auf gültige Initialisierungswertebereits in der UML-Darstellung!

Auch bei den Methoden sollten Sie Datentypen der Parameter benennen, die als ben der Methode notwendig sind Zusätzlich sollten Sie, falls vorhanden, den Datentypdes Rückgabewerts der Methode angeben Dies ist auch dann sinnvoll, wenn Sie eineuntypisierte Sprache wie PHP verwenden, bei der Sie den Variablen keine Datentypenzuweisen müssen

Einga-In Abbildung 3.65 sehen Sie die UML-Darstellung der Klasse Bruch in Designform Die Eigenschaften zähler und nenner sind nicht öffentlich zugänglich und werden auch beim

Default-Konstruktor so initialisiert, dass ein gültiger Bruch entsteht Die dritte

Eigen-schaft anzahl bezieht sich nicht wie die beiden anderen EigenEigen-schaften auf jeden Bruch, sondern gehört zur Klasse Bruch selbst Dies sieht man daran, dass diese Eigenschaft

unterstrichen ist

Zusätzlich zum Default-Konstruktor existiert ein zweiter Konstruktor, bei dem Sie denZähler und Nenner als Ganzzahlen übergeben Wie bei Konstruktoren üblich, existiertkein Rückgabewert

Abbildung 3.65: Eine Klasse in Designform

Als Dienste dieser Klasse werden 5 Methoden skizziert, die öffentlich verwendet werdenkönnen Man kann zu einem Bruch eine Ganzzahl, eine Fließkommazahl – 0.34 ent-spricht 34/100 – und einen anderen Bruch addieren Es gibt eine Methode, die prüft, obder Bruch gerade den Wert 0 hat, also ob der Zähler=0 ist Diese Methode gibt einen

Wahrheitswert zurück Die letzte Methode getAnzahl() gehört ebenso zur Klasse selbst und gibt den aktuellen Zählerstand der erzeugten Brüche, der in anzahl festgehalten

wird, zurück Der Zählerstand wird bei jedem Aufruf des Default-Konstruktors mentiert und bei jedem Destruktoraufruf dekrementiert

inkre-Im nächsten Beispiel existiert, wie bereits bei der Person in der Analysephase, eine

trakte Klasse, von der man keine Objekte anlegen kann Diese Klasse Tier besitzt eine trakte Methode gibLaut() Wenn man von einer Unterklasse von Tier Objekte anlegen will, muss man diese abstrakte Methode mit Quellcode füllen Die Unterklassen Katze und Hund tun dies Zusätzlich definieren sie noch die öffentlichen Methoden miauen() bzw bellen() Die Methode gibLaut() beinhaltet dann intern nur den Aufruf von miauen() bzw bellen() So kann ein Datenfeld von Tieren erstellt werden, in das man sowohl Katzen als auch Hunde ablegen kann Auf jedem Tier in dem Feld kann man dann gibLaut() aufru-

abs-fen und man hört entweder ein Miauen oder ein Bellen (Abb 3.18) Dies entspricht derAnwendung der Polymorphie

Jedem Hund kann man zusätzlich einen Stock geben Der Hund kennt dann seinenStock Der Stock selbst ist dumm und hat weder eigene Eigenschaften noch Methoden.Ein Stock kann auch ohne Hund existieren, wenn er im Wald herumliegt Außerdemexistiert auch ein Hund, ohne einen Stock zu besitzen Wie Sie sehen, lässt sich mit derUML die gesamte reale Welt abbilden

Abbildung 3.66: Klassengeflecht in Designform mit Vererbungshierarchie

Da ein Hund auch ein Tier ist, kann er folgende Methoden ausführen:

쮿 Hund(String) als Default-Konstruktor, der wiederum Tier(String) aufruft, um den

Namen des Tieres zu speichern

쮿 getName() aus der Klasse Tier

쮿 gibLaut() aus der Klasse Hund

쮿 bellen() aus der Klasse Hund

쮿 nimmStock(Stock) aus der Klasse Hund, wobei der Hund ein Stockobjekt

entgegen-nimmt

쮿 gibStock() aus der Klasse Hund, bei der der Hund sein Stockobjekt wieder abgibt

Eine Dogge ist ein spezieller Hund, der auch beißen kann Da eine Dogge auch ein Hundist, kann sie auch einen Stock kennen und alle Methoden eines Hundes ausführen EineKatze ist zwar auch ein Tier wie ein Hund, kann aber keinen Stock kennen

Abschließend wird noch vorgestellt, wie man das Konzept der Interfaces in sendiagrammen darstellen kann Da ein Interface ausschließlich Funktionalitätbeschreibt, beinhaltet es lediglich Methodendefinitionen, die jedoch noch nicht imple-mentiert sind Diese Methodendefinitionen können mit der abstrakten Methode

UML-Klas-gibLaut() der Tierklasse verglichen werden Im Beispiel der Abbildung 3.67 wird ein

all-gemeines Datenzugriffsinterface beschrieben, das zunächst unabhängig von einerDatenbank ist