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. [...]... Verfügung PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 195 3 – Vorgehensweise bei der Softwareentwicklung Hinweis Eine gute Übung besteht darin, aus dem Objekt- und Klassendiagramm der Analysephase aus der Seminarverwaltung ein Klassendiagramm der Designphase zu erstellen Zustände in einem Objekt: Zustandsdiagramme Zustandsdiagramme stellen endliche... herumliegt Außerdem existiert auch ein Hund, ohne einen Stock zu besitzen Wie Sie sehen, lässt sich mit der UML die gesamte reale Welt abbilden PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 193 3 – Vorgehensweise bei der Softwareentwicklung Abbildung 3.66: Klassengeflecht in Designform mit Vererbungshierarchie Da ein Hund auch ein Tier ist,... ebenso für die Verwendung agiler Methoden, die den Kunden durch das iterativ-inkrementelle Vorgehen stärker in den Entwicklungsprozess einbeziehen PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 191 3 – Vorgehensweise bei der Softwareentwicklung Diese Funktionalität wird in Sequenz- und Zustandsdiagrammen beschrieben, die die Interaktion von Objekten... einer Flugreservierung Jemand, der dieses Interface implementiert, muss die folgenden Methoden ausprogrammieren: ࡯ reservieren ࡯ stornieren ࡯ buchen PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 197 3 – Vorgehensweise bei der Softwareentwicklung Das Zustandsdiagramm beschreibt nun, in welcher Reihenfolge diese Methoden aufgerufen werden dürfen... stornierte Seminartermine werden zur Rechnungsstellung und für statistische Zwecke archiviert Abbildung 3.71: Zustandsdiagramm eines Seminartermins PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 199 3 – Vorgehensweise bei der Softwareentwicklung Meinung Ein präzise und vollständig ausformuliertes Zustandsdiagramm ist für den Entwickler eine große... Benutzer mit dem Server verbunden ist In diesem Fall wird die Verbindung unterbrochen, protokolliert und an einen Administrator des Systems übergeben PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 201 3 – Vorgehensweise bei der Softwareentwicklung Abbildung 3.73: Zustandsdiagramm eines Bankservers Abläufe im technischen Modell: Sequenzdiagramme... auf, weil das Empfangs- immer nach dem Sendeereignis vorkommt Analog tritt E2 nach S2 auf S2 tritt nach S1 auf, weil S2 unter S1 gezeichnet ist PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 203 3 – Vorgehensweise bei der Softwareentwicklung Abbildung 3.75: Kausale zeitliche Abhängigkeiten Auch Verzweigungen, also alternative Abläufe, können... UML-Diagramme! In diesem Fall können Sie erkennen, welche technischen Unterschiede aus einer anders gezeichneten Pfeilspitze resultieren können PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 205 3 – Vorgehensweise bei der Softwareentwicklung Abbildung 3.78: Synchrone und asynchrone Kommunikation Nachdem die formale Syntax der Sequenzdiagramme... der Apotheker das Rezept Ihnen ist es vielleicht in einer Apotheke schon einmal aufgefallen, dass der Apotheker sich die erste Zeile des Rezepts PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 207 3 – Vorgehensweise bei der Softwareentwicklung ansieht, zum Arzneischrank geht, dort das Medikament, sofern es im Lager vorhanden ist, entnimmt und... an die Seminarverwaltung weitergeleitet Dort wird nochmals geprüft, ob zu diesem Termin noch ein freier Platz existiert und die Buchung über das Seminarobjekt zu dem zugeordneten Termin durchgeführt PHP – Endlich objektorientiert Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 209 . www.verypdf.com to remove this watermark. Objektorientierte Programmierung PHP – Endlich objektorientiert 181 Abbildung 3.47: Buchungsversuch auf ein bereits. www.verypdf.com to remove this watermark. Objektorientierte Programmierung PHP – Endlich objektorientiert 183 Zentriert im oberen Viereck eines Objekts steht