PHP – Endlich objektorientiert- P8

3 – Vorgehensweise bei der Softwareentwicklung
180
Abbildung 3.46: Erfolgreiches Buchen eines Seminars auf Meeresspiegelebene
Diesem positiven Beispiel wird in Abbildung 3.47 ein Fehlschlag gegenübergestellt. In
diesem 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 an
den Server gesendet wird. Der Seminartermin ist jedoch bereits ausgebucht; der Kunde
hat sich also zu spät angemeldet.
In diesem Fall ist vorgesehen, dass der Kunde eine Mitteilung erhält, dass dieser Termin
bereits ausgebucht ist. Zusätzlich erhält er eine Liste mit anderen möglichen Terminen
sowie eine Kontaktanschrift des Seminaranbieters. Das Ziel des Geschäftsprozesses
besteht darin, den buchungswilligen potenziellen Kunden nicht zu verlieren.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Objektorientierte Programmierung
PHP – Endlich objektorientiert 181
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 erschei-
nen. Dies ist jedoch eine trügerische Annahme.
In der UML existiert ein weiterer Diagrammtyp, der zu wenig Beachtung findet. Die
Objektdiagramme sind an die Notation der Klassendiagramme angelehnt. Da ein Objekt
eine 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 Aktivitätsdiagram-
men suchen und diese kritisch beurteilen. Verstehen Sie den Ablauf? Ist er eindeutig
spezifiziert? Was könnte man besser machen? Wenn Sie eine Vielzahl von Diagram-

men gesehen und am besten mit anderen Personen diskutiert haben, werden Sie zu
einem besseren Analytiker für objektorientierte Anwendungen.
Beispiel
Ein Kunde hat Ihnen das Beispiel aus Abbildung 3.48 aufgezeichnet, welches Sie im
nächsten Projekt in einer PHP-Anwendung realisieren sollen. Der Kunde möchte
gern ein Tool programmiert bekommen, mit dem man beliebig viele Punkte und
Dreiecke in ein bereits bestehendes Koordinatensystem eintragen kann.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3 – Vorgehensweise bei der Softwareentwicklung
182
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 belie-
bige Beispiel auf diese Weise in eine einheitliche Notation überführen können - genau
dies 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 auch
Anwender 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.
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 mehrere
Dreiecke kennen, siehe P3.
Aus was bestehen ein Dreieck und ein Punkt? Ein Dreieck besteht aus drei Punkten. Ein
Punkt wiederum besteht aus genau zwei Koordinaten. Alle diese Sachverhalte können
Sie in der normierten Darstellung auch in Abbildung 3.49 erkennen.
Abbildung 3.49: Objektdiagramm des Beispiels
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Objektorientierte Programmierung
PHP – Endlich objektorientiert 183

Zentriert im oberen Viereck eines Objekts steht zunächst dessen Name und durch einen
Doppelpunkt getrennt der Name der Klasse. Dies alles ist unterstrichen, um eine bessere
Unterscheidbarkeit zu den Klassendiagrammen zu gewährleisten.
Besitzt ein Objekt zusätzliche Eigenschaften, werden sie in einem zweiten Viereck unter
dem 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 ein
Objekt ein anderes Objekt kennt, wird diese Assoziation in einer Programmiersprache
auch über eine Eigenschaft abgebildet. Die Kenntnis von Objekten untereinander wird
jedoch 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 einer
Klasse stets dieselben Methoden besitzen. Bei den Objektdiagrammen nähert man sich
also 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 ano-
nyme Objekte erstellen, wenn Sie die Objekte nicht konkret benennen möchten. So defi-
niert die rechte Darstellung der Abbildung „irgendeinen Kunden“.
Für die Implementierung können Sie aus dem Objektdiagramm als Diskussionsgrund-
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, da
ansonsten das Dreieck nicht existieren kann.
Die nächste Frage, die Sie sich als aufmerksamer Entwickler stellen müssen, lautet: Kön-
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 Sie
kein gültiges Dreieck, sondern eine Strecke erzeugen, die keinen Flächeninhalt besitzt.
Außerdem könnten Sie keine Winkelberechnungen durchführen, die ja vielleicht als

Methoden eines Dreiecks sinnvoll sind. Genügt es also zu prüfen, ob sich die drei x- und
y-Koordinaten der Punkte unterscheiden? Dazu kann man ein Gegenbeispiel erzeugen:
P1x=1, P1y=1
P2x=2, P2y=2
P3x=4, P3y=4
Auch 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.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3 – Vorgehensweise bei der Softwareentwicklung
184
Die Existenz des Dreiecks ist also von drei Punkten abhängig und jedes Dreieck kennt
seine 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 stets
alle Dreiecke gültig bleiben.
Als Nächstes müssen Sie sich fragen, ob ein Punkt auch seine Dreiecke kennen muss. Auf
den ersten Blick scheint dies nicht nötig zu sein. Was jedoch geschieht, wenn Sie einen
Punkt 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 diesen
Punkt existieren können. Jeder Punkt muss also auch eine Liste mit angeschlossenen
Dreiecken verwalten. Und wenn ein Dreieck gelöscht wird, muss es allen drei Punkten
ebenso mitteilen, dass es nicht mehr existiert. Denn ansonsten würden diese Punkte noch
Referenzen auf ein Dreieck besitzen, das nicht mehr existiert.
Aus dem in Abbildung 3.48 dargestellten Objektdiagramm der Analyse müssen Sie im
nächsten Schritt ein Klassendiagramm der Analyse erstellen. Der Fokus der Analyse
besteht 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. Wenn
keine Pfeile eingezeichnet sind, machen Sie noch keine Aussage darüber, welche Klasse

welche 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 Sie
eine 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 und
Familienverhältnisse des Richters kennen dürfen. Der untere Teil der Abbildung zeigt die
gegenseitige Bekanntschaft zwischen Punkten und Dreiecken. Welche Objekte welche
anderen Objekte kennen können, wird als Navigierbarkeit bezeichnet.
Meinung
Dieser Ausblick, der von einem Objektdiagramm ausgeht und bis tief in die Imple-
mentierung reicht, zeigt die notwendige Disziplin und Sorgfalt, die man als Analyti-
ker und auch als Entwickler bei der (objektorientierten) Programmierung besitzen
muss. Dies wird noch unterstützt davon, dass Sie als Autor der Klassen Punkt und
Dreieck bei Fehlern wesentlich leichter zur Verantwortung gezogen werden können
als bei einem prozedural entwickelten Projekt, bei dem die Aufgaben mehrerer Ent-
wickler nicht so stark voneinander trennbar sind.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Objektorientierte Programmierung
PHP – Endlich objektorientiert 185
Abbildung 3.51: Navigierbarkeit der Assoziationen
Ein erstes Klassendiagramm der Analyse kann daher so aussehen, wie es in Abbildung
3.52 dargestellt ist. Jede Assoziation kann mit einer Beschriftung versehen werden, die
die 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 besteht
aber stets aus genau drei Eckpunkten. Diese Abhängigkeiten werden als Multiplizitäten
bezeichnet, die im Laufe der objektorientierten Analyse immer mehr herausgearbeitet

werden. 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 zu
erstellende 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 Tatsa-
che auf, dass ein Dreieck aus Punkten besteht. Ein Punkt kann aber auch allein existieren
oder gleichzeitig zu mehreren Dreiecken gehören. Dabei handelt es sich folglich um eine
Aggregation. Diese Beziehung wird in der UML durch eine nichtausgefüllte Raute dar-
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3 – Vorgehensweise bei der Softwareentwicklung
186
gestellt. Zusätzlich können noch die x- und y-Koordinaten als Eigenschaften der Punkte
angegeben 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 diesem
Fall eine ausgefüllte Raute verwendet wird. Außerdem sollte man keine Multiplizität an
einer Komposition angeben, da diese stets 1 beträgt. Genau so ist ja die Komposition
definiert.
Als Beispiel für eine Komposition kann man eine Datei sehen, die sich stets in einem Ver-
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 gewisse
Zeit ihre Existenz als Datei. Man könnte sie dann als Datenstrom oder als Datenpakete
bezeichnen. Ein Verzeichnis kann jedoch auch leer sein, also keine Dateien enthalten.
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, Stu-
dent und Hilfskraft mit einigen Eigenschaften und Methoden bereits ermittelt. Die Namen
der Methoden werden separiert unter die Eigenschaften geschrieben. An dem Beispiel
der Abbildung 3.56 fällt eine große Schnittmenge der Eigenschaften und der Methoden

auf. 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
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Objektorientierte Programmierung
PHP – Endlich objektorientiert 187
Offensichtlich beinhalten alle Klassen die Eigenschaften name, anschrift und geburtsda-
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().
Der Unterschied zwischen diesen beiden Klassen besteht nur darin, dass eine Hilfskraft
zusätzlich Beschäftigungen hat und eine Liste ihrer Arbeitszeiten drucken kann. Eine
Hilfskraft 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, da
diese 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 Methoden
zusammenzufassen. 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 der
Oberklasse 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 speziel-
ler Student.
Abbildung 3.57: Resultierende Vererbungshierarchie
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3 – Vorgehensweise bei der Softwareentwicklung
188

Ein sehr hilfreiches, jedoch zu selten eingesetztes Mittel der UML sind die Diskriminato-
ren, mit denen Sie spezifizieren, wie Sie eine Vererbung durchführen. Abbildung 3.58
zeigt, dass Sie Angestellte spezialisieren können nach Vollzeit- und Teilzeitkräften.
Andererseits können Sie in Ihrer Anwendung auch eine Unterscheidung anhand der
Tätigkeiten der Angestellten vornehmen. Beide Ideen sind sicherlich korrekt. Welche Art
der 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 erste
Idee sinnvoller, bei einer Verwaltung von Berufsgruppen die zweite.
Es ist in der Analyse durchaus üblich, mehrere richtige Lösungen zu erstellen, die jedoch
vö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 als
mit 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 einem
Buch genauer beschreiben. Da es sich um eine Bibliothekssoftware handeln soll, sind
Leser 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, die
Ausleihe 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 Assoziationen
werden als „n-äre Assoziationen“ bezeichnet. So wird die Beziehung zwischen einem
Passagier, einem Flug und einem Sitzplatz über die Reservierung hergestellt. Das Erken-
nen solcher Zusammenhänge bildet den Kern der objektorientierten Analyse.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Objektorientierte Programmierung
PHP – Endlich objektorientiert 189
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. Dabei
sind oft verschiedene Rollen von Bedeutung, deren Bezeichnung an die Assoziation
geschrieben werden können.
Im Beispiel in Abbildung 3.61 sind sowohl die Chefs als auch deren Mitarbeiter Ange-
stellte eines Unternehmens. Da Angestellte nur einmalig mit ihrer Personalnummer im
System registriert sein sollen und ein Angestellter gleichzeitig Chef und Mitarbeiter sein
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 $ist-
ChefVon werden die Referenzen auf andere Angestellte gespeichert, von denen dieser
Angestellte der Vorgesetzte ist. Das zweite Feld $istMitarbeiterVon beinhaltet Referenzen
auf Angestellte, denen dieser Angestellte weisungsbefugt ist. Generell kann eine refle-
xive Assoziation stets mit zwei Datenfeldern realisiert werden.
Beispiel
Wie sind ein Kaufinteressent, ein Artikel und ein Verkäufer in der Modellierung mit-
einander verbunden? Die Antwort lautet: Über ein Verkaufsgespräch, das im Nach-
hinein protokolliert wird.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3 – Vorgehensweise bei der Softwareentwicklung
190
Als abschließendes Beispiel der Analysephase wird nochmals das Beispiel der Seminar-
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ätzlich
werden jedem Termin ein Raum und ein Dozent zugeordnet.
Abbildung 3.62: Objektdiagramm der Seminarverwaltung
Im nächsten Schritt wird nun aus diesem Objektdiagramm das Klassendiagramm der

Analysephase abgeleitet. Die Namen der Klassen kann man bereits aus dem Objektdia-
gramm entnehmen. Sie lauten
࡯
Seminarverwaltung
࡯
Seminar
࡯
Termin
࡯
Raum
Profitipp
Versuchen Sie nicht, zwingend n-äre Assoziationen oder reflexive Assoziationen bei
einer objektorientierten Analyse zu finden. Nur wenn diese besonderen Fälle wirk-
lich von Bedeutung sind, sollten Sie sie auch verwenden. Ansonsten laufen Sie
Gefahr, Ihre Problemstellung auf die UML zurechtzubiegen, anstatt die UML-Nota-
tion auf Ihr Problem anzuwenden.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Objektorientierte Programmierung
PHP – Endlich objektorientiert 191
࡯
Dozent
࡯
Anmeldung
࡯
Kunde
Die erste Version des Diagramms ist in Abbildung 3.63 dargestellt und benennt erst ein-
mal die Beziehungen zwischen den Klassen textuell. Es kann in weiteren Schritten um
Multiplizitäten, Aggregationen bzw. Kompositionen sowie um die Navigierbarkeiten
erweitert werden.
Abbildung 3.63: Erstes Klassendiagramm der Seminarverwaltung (Analysephase)

Klassen im objektorientierten Design
In der Designform beinhalten Klassendiagramme alle notwendigen Methoden und
Eigenschaften. 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 und
ihn in einem fachlichen Modell abbildet, fokussiert sich das objektorientierte Design auf
das so genannte technische Modell. Dies ist die weitere Abstraktion des fachlichen
Modells auf die Fähigkeiten einer objektorientierten Programmiersprache. Die hier
erstellten Diagramme (zumeist Klassen-, Zustands- und Sequenzdiagramme) dienen
den Entwicklern als direkte Vorlage für die objektorientierte Programmierung. Hier
kann man erkennen, dass der Aufwand der Implementierung im Vergleich zur Analyse
und Design geringer geworden ist, wie es im RUP-Modell beschrieben wurde. Dies gilt
ebenso für die Verwendung agiler Methoden, die den Kunden durch das iterativ-inkre-
mentelle Vorgehen stärker in den Entwicklungsprozess einbeziehen.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.