Hallo, ich begrüße Sie ganz herzlich zur Vorlesung 10,
bei der es um Objekte und Typenentwurf insbesondere darum geht,
wie wir guten Entwurf erreichen. Dieses,
das starten wir mit einer Einleitung, bei der wir nochmal motivieren,
warum Qualität wichtig ist und dann zu den Inkredienzen,
zu den Regeln für guten Entwurf kommen und da über dem Ganzen schwebt die Frage,
was brauchen wir denn, damit andere den Code gut verstehen,
gut weiterentwickeln, auch ohne dass wir dabei sind und sagen,
so und so geht es.
Das Ganze von dem Hintergrund,
wir arbeiten mit großen Systemen, wir wollen,
wir haben viele Beteiligte und diese Beteiligte müssen versuchen,
die gleichen Gedanken zu haben
Das ist ja, wie man weiß, ganz schwierig,
weil Gedankenübertragung typischerweise, nur der Theorie funktioniert.
Ich wünschte, die anderen müssten. Ja,
und wie erzähle ich die Idee meinen Kollegen, meiner Kollegin,
das funktioniert am besten, wenn die Ideen klar sind,
wenn die Ideen gut beschrieben sind, gut ausgegedrückt sind.
Und wenn sie sie nicht so stark voneinander abhängig finden,
sind wir Fehler vermeiden. Das habe ich schon,
eigentlich habe ich schon alles gesagt, was wir heute machen wollen,
doch lassen sie uns dabei starten.
Wir haben, wir fangen an mit halt,
wir waren die eine Reihe von Fragen,
die wir jetzt nacheinander durchgehen,
wie sie das ja schon von uns kennen
Lassen Sie uns zunächst erst mal starten, damit, was ist Qualität?
Was ist Entwurfsqualität? Wir hatten schon gesagt, was wir als,
Laserpointer brauchen wir hier, was für Qualitätsziele es gibt.
Hier sind die noch mal kurz im Baumform dargestellt. Ja,
also es gibt Funktionalität, Zuverlässigkeit, Benutzbarkeit, die Wartbarkeit,
Effizienz, Portabilität und die Wartbarkeit ist besonders wichtig für langfristige Entwicklung.
Das ist das, was wir brauchen. Also man muss
es leicht verstehen können, leicht ändern können.
Also der Umfang von Abhängigkeiten muss leicht sein.
Das Ganze soll stabil sein, mit geringem Aufwand testbar
So viel ganz schnell, ganz schnell durchnauf.
Eigentlich wollen wir erreichen, dass es möglichst gut ist.
Qualität ist eine Eigenschaft von, oder das ist ein Nachwerkerfüllen
an Eigenschaft. Und das, was wir brauchen,
ist ja das, was unser Auftraggeber möchte.
Ja, wir haben die Äußerung, die inneren Qualitätsmerkmale,
äußeren sind die, die der Auftraggeber sieht.
Das sind also diese drei hier zum Beispiel plus Effizienz.
Und die innerer Umständigkeit, Wortbarkeit, das haben wir,
das sind diese beiden hier.
Modularität gehört Unterwartbarkeit dazu
So, das ist das, was wir erreichen wollen.
Das ist das, was wir für unser System,
was für unser System dann der Hut ist.
Ich möchte noch mal kurz wiederholen, das haben wir schon
mal gesehen, das Bild, was ist das eigentlich?
Entwurf. Ja, so magisch, was liegt das so libellös?
Wir versuchen es ein bisschen konkreter zu machen. Also,
wir haben zunächst Anforderungen, die der Auftraggeber hat.
Er möchte etwas. Zunächst hat er das nur im Kopf,
vielleicht schreibt das noch auf und das sind für große Systeme durchaus große Dokumente.
Also, sag mal so, so ein fetter Akt,
Ordnung, weil Text, ja, oder tausend Word-Files,
die alle irgendwelche Features beschreiben,
das sind Anforderungen
Und der Lösungsraum, das sind am Ende Quellcode-Files, alles Mögliche zusammen.
Und was wir erreichen wollen für große Systeme,
wir wollen denen diese Problemstellung, den Problemraum verstehen.
Und dann wollen wir die Lösung bauen, die zunächst erstmal jeder versteht,
eine Struktur, an der wir das prüfen können.
Und das machen wir so, dass wir verschiedene Tätigkeiten einsetzen,
die haben wir sie schon mal gesehen, dieses Bild in dieser Form.
Also wir machen die Anforderungsanalyse,
die erstellt so ein Modell des Problemsraums aus dem Entwurf,
machen wir eine Lösung oder im Entwurf machen wir eine Lösung
aus dem Problemraummodell
Lösungsformudellen, wo wir zum Beispiel Entwurfsmuster einsetzen oder auch Technologieneinsätze,
wie ein bestimmtes Paket zur Gui-Bildung oder ein bestimmtes Paket,
Framework für die Verschlüsselung oder ein bestimmtes Framework,
mit dem wir die Prozessoren auf Grafikkarten ansprechen.
So, und dann setzen wir guten Entwurf ein,
um daraus guten Code zu machen.
Und hier sind Entwurfsregeln und hier sind Entwurfsregel drin.
Das ist das, womit wir uns heute beschäftigen würden.
So, und noch ein weiterer Klick hier, um das
ein bisschen konkreter zu machen, was das denn eigentlich ist.
Also hier hatte ich schon gesagt, Das ist dieser Aktenordner
voll natürlichsprachlichem Text. Das ist vielleicht noch eine Anforderungsbeschreibung,
wenn sie im besten Fall tatsächlich als Use-Case-Modell,
damit wir es ein bisschen besser verstehen.
Manchmal auch nur die Idee beim Auftraggeber im Kopf und wir müssen
das erst rausbekommen. Das machen diese Requibment-Engineering-Leute. So,
wenn die das herausbekommen haben, versuchen wir ein klares Modell zu erstellen,
versuchen wir das so zu machen, dass es wieder versteht.
Modell, das Problem raus, das könnten zum Beispiel fachliche Klasse sein.
Das können Geschäftsregeln sein, also was gehört hier dazu.
Das, was die daraus, was der Entwerfer der Architekt
daraus entwickelt,
ist ein System im Großen
Das sind Kästchen und Linien, die die Lösung beschreiben,
zum Beispiel was für Komponenten gibt es.
Wie sieht die Softwarearchitektur aus im Sinne von Komponenten und Schnittstellen?
Daran kann man schon prüfen, ist denn alles da?
Ist das gut verteilbar? Ist es potenziell schnell genug?
Ist es zuverlässig genug? Haben wir von den Datenzugriffen her
Sicherheitsmöglichkeiten? Ja, das kann man alles nicht nachträglich machen.
Das muss hier schon drin sein. So, und dann wird das implementiert,
kodiert und dass da hinten rauskommt, sagt es schon.
Quellcode, das Ganze in Paketen organisiert,
universiert, der Testcode gehört natürlich mit dazu
Der ist ja vor dem Quellcode da, wo wir Testfirst machen,
aber auch sowas wie Bildmechanismen wie MacFiles und die Dokumentation gehört unmittelbar dazu.
Das erstmal nochmal zum Entwurf. Den Begriff hatten wir,
glaube ich, auch schon mal,
wir überführen etwas aus dem Problembremsmodell, in eine technische Lösung.
Das ist dann das Lösungsmodell. Und genau diese Warnung bezieht sich
auf die Bezeichnung, Entwurf, Entwurf bezeichnet die deutschen,
leider sowohl die Tätigkeit als auch das Ergebnis.
Im Englischen ist das so
So, wir wollen methodisch vorgehen. Wir kennenlernen hier in
der Vorlesung die Methode. Wann? Kennen, Merkzeug,
Materialansatz? Oder haben Sie vorgehend das Vorgehensmodell Scrum,
wo wir dann dabei steht, für das irgendwie organisiert man das in Sprints?
Was für Rollen gibt es? Wer macht was? Und
wir müssen in dieser Zeit ganz viele Entscheidungen treffen auf diesem Weg.
Ich nehme mal zurück hier auf diesen Weg von hier nach hier
müssen wir Entscheidungen treffen. Nicht nur über die Entwurfsregeln,
Entwurfsprinzipien, sondern zum Beispiel auch welche von den Paketen,
Softwareprodukten, die es so gibt,
wenn wir denn
Ja, hier stehen solche Sachen drunter, ja, also Entwurfsmuster anwenden,
Bausteine auswenden, das Datenbanksystem ist zum Beispiel ein Baustein,
um mich entlassen Bibliotheken für Gui-Tools für Performance, über Pharaparallelverarbeitung.
Ja, und wir müssen die Schnittstellen gestalten,
das sind auch wichtige Entscheidungen und wir wollen diese Prinzipien anwenden und das ist der Punkt.
Da wollen wir heute drüber reden, welche Beziehungen das sind. Und diese Behilfsmittel,
dass das gut wird, ja, sind zum einen Wissen, ja,
Wissen, da sammelt man während der Erfahrung in Projekten,
das haben wir natürlich hoffentlich aus dieser Vorlesung,
wenn sie gut verfolgt haben,
haben sie wenigstens den einen oder anderen Anstich mitgenommen
Und vielleicht haben sie das ein oder andere weitergelesen.
Vorgehensweisen, Entwürfsmethodenprinzipien, all das. Und natürlich wiederverwendbarer Baustein
. Solche abstrakten Bausteine wie Paddln sich noch implementieren muss.
Aber ganz konkrete wiederverwendbare Bausteine, die Quellcode ist,
Frameworks, die Klassenbiothek nicht einfach nur einsätze, zukaufen.
Ganz wichtig ist, dass wir die verschiedenen Arbeitsgebiete betrachten,
wie man da verschiedene Kenntnisse, die man haben muss.
Ich muss wissen, wie Implementierung funktioniert.
Ich muss wissen, wie objektuntiert der Entwurf funktioniert.
Ich muss wissen,
die fachliche Struktur funktioniert
Und die Architektur funktioniert. Das wollen wir alles haben.
Okay, guter Entwurf. Erstmal im Überblick, im Wegweiser,
was wollen wir erreichen? Lose Kopplung, hohe Korresion.
Das sind ganz wichtige Kernpunkte, auf die wir jetzt eingehen weiter.
Dazu gehört zu Loser, kommt ja um Schnittstellen, in Luftsentscheidung,
Kapselung, Geheimnisprinzip, Zyklenverwaltung und dieses magische Bezeichnung läuft demütter.
Hohe Kollision, ja, innerhalb der Klassenpakete kommt ein enger Zusammenhalt,
dass wir ja keine Replikate haben, geeignete Bezeichnung.
Und nicht so viele große Sachen, die eigentlich nur Sammlungen sind. Und wir wollen Zuständigkeit weiter,
damit jeder andere das versteht, wieder zu der Qualität zurück,
wenn wir ein großes Team sind, muss jeder versuchen,
müssen wir versuchen, das wieder ein gleiches Verständnis hat.
Und das geht natürlich am besten, wenn klar ist,
wer ist für was zuständig vom Code, nicht nur von der Mitarbeitung.
Starten Sie mit uns mit Kohession. Kohession kennen wir,
vielleicht ändern Sie sich auch mal den Physikunterricht,
da war das der Zusammenhalt zwischen Teilchen und hier ist die Menge der Aufgaben,
die ein Software-System zu tun hat, entscheidet darüber,
haben die viel mit der Nummer zu tun,
haben sie wenig miteinander zu tun.
Und wenn sie wenig miteinander zu tun haben,
dann ist das irgendwie nicht so gut. Wir wollen versuchen,
das innerhalb einer Komponente einer Klasse, einer Einheit eines Pakets,
alle Sachen sehr viel miteinander zu tun haben und wenig mit denen außen.
Warum? Wegen der Arbeitsorganisation. Wir packen dieses Team,
was sich darum kümmert, dieses Arbeitspaket zu einem Team oder zu einem einzelnen Bearbeiter.
Und dann braucht er sich nur darum zu kümmern.
Und die anderen brauchen nur die Schnittstellen zu wissen.
Und je besser das funktioniert, desto besser funktioniert die Abgrenzung
von Arbeit
So einfach ist das. Und so kompliziert zu erreichen. Ja,
also wir wollen möglichst hohe Kollisionen, dass das,
was einer zu tun hat, was ein Team zu tun hat,
ein Arbeitspaket, viel miteinander zu tun hat.
Und das soll in einem Modul triebstücken. Da dachten wir mal den Quellgut,
dass das, worum es geht, wir wollen Klassen,
die eine klar definierte Aufgabe, eine verständliche Aufgabe haben,
damit jeder, der ein neues Projekt findet,
der diese Klasse aufmacht, sofort weiß,
ah, die ist dafür zuständig.
Das soll natürlich über den Namen präsentiert werden,
aber es soll auch präsentiert werden darüber, was sie so tut.
Ja, also wenn der Klasse mit hoher Korresion,
da haben wir einen Film zum Beispiel gibt es den Titel,
die Länge und die Freigabe, Altersklasse, irgendwas Übergabe.
Und wenn wir eine Klasse haben, wo das nicht so richtig klar ist,
hier ein Programm, dann gibt es alles mögliche.
In den Live-Format bringen, dann kann man nur sagen,
okay, irgendwie nützlich wird die schon sein.
Diese magischen Utilities. Ja, ganz gefährlich. Wenn es nur eine Sammlung ist,
manchmal lässt sie sich nicht vermeiden, man braucht auch Sammlung.
Aber versuchen sie immer ganz klar zu machen, was ist wofür.
Sonst haben wir ganz schnell Sammlung, Endsammlung, zwei Sammlung
, drei. Und wenn die was Neues haben,
dann weiß man nicht, wo packe ich es denn hinzu.
Ja, also ganz klare Zuständigkeit
Toten sollten ebenfalls für eine Aufgabe vorgesehen sein.
Und zwar sollte ganz klar sein, was die macht.
Wenn wir so eine haben, die ganz verschiedene Sachen machen
kann, ist es nicht so richtig klar.
Und damit ist die Kursion nicht so einfach.
Besser ist es wirklich klare Aufgaben zu haben.
Nicht nur eine, die hier über Parameter das macht,
sondern wirklich separate Klassenmethoden für die verschiedenen Funktionen.
Für Modularität brauchen wir nicht nur hohe Koalition,
sondern wir wollen auch zwischen den Modulen möglichst Unabhängigkeit erreichen.
Also Kopplung, Lose,
Kopplung ist möglichst Unabhängigkeit
Warum das auch wieder wegen Arbeitsteilung, damit das Team A nicht ständig wegen jedem pupst,
das Team B fragen muss. Weil es vielleicht dann auch,
damit ist es auch mehr möglich,
die eine Aufgabe eben nach Indien zu geben oder Rumänien oder zu einem Team beim Subauftragnehmer,
beim Unterauftragnehmer, weil die nicht so viel miteinander zu reden haben,
weil klar ist, da gibt es eine klare Schnittstelle,
ansonsten haben die nichts miteinander zu tun,
eine lose Kopf.
Lose Kopplung wollen wir erreichen, indem wir wenig Abhängigkeiten erreichen.
Und solche Abhängigkeiten sind vor allen Dingen Benutzbeziehungen, Vererbungsbeziehungen.
Und worauf trifft das zu? Auf Methoden, Klassen,
Pakete, Subsysteme
Wir wollen lose Komplott erreichen, ja, hier,
wenn eine Klasse mit allen verbunden ist, ganz schlecht,
ja, wenn sich an dieser Klasse was ändert,
müssen wir alle sechs, ringsrum hier nochmal anschauen,
das ist schon mal schlecht, aber wenn jeder mit jeder verbunden ist,
katastrophal, ja, wenn ihr eine ändern wollt,
müssen wir ja alle angucken.
Hier, wenn wir die einändern wollen, muss man nur
den angucken. Wenn wir hier die einen ändern wollen,
müssen wir hier fünf solche Beziehungen verfolgen.
Das wollen wir nicht, ja. Sie wissen,
wenn bei Kommunikation kann auch mal was schiefgehen,
man spricht sich nicht richtig ab,
man versteht sich nicht richtig
Lassen Sie uns das klarlegen, dass man nichts mehr absprechen muss.
Das ist schon ganz klar, wie die Beziehungen sind.
Sie kennen diese Prinzipien natürlich. Das ist nicht neu für Sie
. Sie kennen schon Design by Contract. Da war,
da letztlich das Gleiche. Wir machen klare Bedingungen,
was die Voraussetzungen, Vorbedingungen, was sind die Nachbedingungen.
Und dann ist das klar, was sie dort zu tun hat.
Damit ist auch so eine Interkopionthek auch zu lösen, Komponenten bei.
So, diese losen Kopplungen wegen Verständlichkeit und vor allen Dingen
, weil Änderungen dann leichter durchzuführen.
Änderungen ist ja das, was wir immer tun müssen.
Wir müssen die Software an das reale Leben anpassen,
das reale Leben verändert sich
Geschäftsprozesse werden optimiert, Firmen strukturieren sich um,
legen ihren Einkauf zusammen oder eine ganz neue Geschäftsprozesse entstehen,
ganz neue Produkte und Dienstleistungen entstehen.
Oder auch einfach nur so was Simples wie ein Plattformwechsel von
einer lokalen Anwendung in die Cloud.
Ja, muss ich irgendwie viele Sachen umstellen.
Und dazu muss ich wissen, wie die Sachen funktionieren.
Und dazu sollte ich eine Änderung nicht auf alle aufbreiten,
noch mal das Bild hier zurück,
wenn wir diese eine Änderung hier haben und die beide sich nur dahin aus.
Super, dann können wir damit leben. Aber wenn
sich hier die alle miteinander zu tun haben,
dann breitet sich das überall hinaus
Sie wissen ja, jeder mit jedem, das wächst quadratisch.
Also wenn wir 10.000 Elemente haben, ja,
dann ist das 10 hoch 8 Verknüpfung.
Ja, es ist irgendwie ganz schlecht. Also wir wollen hier,
war das überhaupt durch 7 mit den 10,
um 8 kleine Quizfahrt an Sie, rechnen Sie es mal aus.
Okay, wir machen aber hier weiter. Wir möchten,
ich möchte Ihnen ein Beispiel bringen für implizite Kopplung,
weil dieses explizite Kopplung, was wir hier haben, ja,
das sollte ich vielleicht noch drauf eingehen, steht auf dieser Folie.
Explizit heißt, es ist im Quellcode zu sehen. Ja,
in Velcode ist es klar nachweisbar,
damit können Sie von Werkzeugen das finden und man sagt,
oh, diese Klasse hängt von der ab.
Bitte, wenn du die änderst, prüf doch die auch mal.
Das ist sozusagen schon der leichtere Fall. Schwieriger wird es
, wenn es implizit ist. Implizit heißt irgendwie unsichtbar.
Und dazu, wir schauen ja zwischendurch zu den Faden,
ich lasse mal Fragen verpassen hier.
Wir haben hier den Begriff Kopplung, Lösekupplung strebenswert und Begriff Koalition.
Ja, und bevor wir zu dem immer auf die Meter kommen.
So, wo waren wir jetzt gerade gewesen? Nein,
wir waren, hier fehlen die Foliennummern,
das ist ja ganz schlecht,
die müssen wir
gleich mal anschauen
Doch zunießen, nun zu diesem Beispiel mit der impliziten Kopplung,
also der, die ich nicht so richtig sehe.
Bei der impliziten Kopplung haben wir, haben wir zunächst,
gehen wir mal davon aus, wir haben einen fachlichen Behälter,
der Klient ruft den auf und wir haben die Schnittstellen,
dass er die Elemente alle nacheinander in einer Reihenfolge liefert.
Und die Implementation macht das so, dass die Reihenfolge dann eine Alphabetisch das macht.
Ist ja irgendwie logisch, kann man gut machen. Und der Implementierer,
der diesen fachlich diese Klasse anschaut, mit dem fachlichen Container der sagt,
okay, das Ding macht ja alphabetisch super,
dann brauche ich keine alphabetische Funktion mehr und mache das so.
Ja, so, Monate später macht jemand anderes, ja,
vielleicht auch Jahre später, vielleicht sogar dasselbe und weiß es nicht mehr,
der macht da eine Änderung, ja,
und hier kommt eine neue Klasse hin,
die zum Beispiel mit einer anderen Datenstruktur arbeitet,
fachlich viel performanter ist oder von der Sicherheit viel besser ist,
vielleicht sogar in der Zukunft eine zugekaufte Klasse aus einem anderen Paket.
So, er nimmt die rein,
die macht auch die gleiche Schnittstelle,
alles sieht super aus,
dummerweise macht sie nicht
die alphabetische Sortierung
Ja, also das ist sozusagen ein Verhalten, ein Unterschied.
Ja, und dann ist der Effekt, dass das,
was der Klient eigentlich macht, er zeigt ihr alphabetisch,
funktioniert irgendwie nicht mehr.
Der Benutzer will sortieren und sagt hier, in der Reihenfolge
und das Ding tut nicht. Ja, großes Geschwein,
große Fehlermeldung, wollen wir als Entwickler nicht. Ja,
also deswegen hier nochmal zurück, ja, Implementierung,
implizite Kopplung, das ist, was wir nicht nachweisen,
das war ein Beispiel dafür, das ist was, was schwierig ist.
So, Nun gibt es hier ein Gesetz,
das klingt so ein bisschen wie diese bekannte Biomarke,
die Meter, hat aber damit nichts zu tun.
Ich denke jedenfalls, dass es damit nichts zu tun hat,
sondern es ist eine Richtlinie für lose Kopplung.
Und hier, das ist das Gesetz selber,
müssen wir gar nicht unbedingt so ganz genau wissen.
Wichtig ist nur, man sollte nur die Ängsten,
Vertrauten, die ganz nahen Leute kontaktieren,
also nur Methoden von sich selber, von Parametern,
davon von Objekten und von Exemplarvariablen.
Und nicht sowas ganz,
ganz langes
Sie haben bestimmt bei Objektorientierung gelernt, wie toll das geht,
dass man immer hier sowas aufruft,
also der Student hat eine Operation,
also dieses Objekt hat eine Operation, Get Record und das,
was die zugegebt hat, ein Exam-Entry und du hast der zurückgebt,
das ist eine Liste und da können wir uns hinzufügen.
Ja, ich lasse mir hier von einer Liste von einem
Rekord, von einem Studenten was geben.
Das ist von Objekt zu Objekt und wenn wir das sowas zulassen,
bedeutet das, wir haben dort ganz klar Referenzen,
die wir weitergeben von dieser Klasse, von dieser Liste,
die irgendwo ganz anders implementiert ist,
Und die wird, eine Änderung würde sich sehr stark auswirken.
Dieses Beispiel mit der langen Aufzeichnung ist ein Beispiel dafür,
dass wir also wirklich hier, dass wir tatsächlich über diese Kette,
die wir hier haben, auf ganz andere Klassen zugreifen.
Und dann sind die, sagen, sehr stark gekoppelt.
Änderungen erschwert, Änderungen im Sinne von, wir haben hier Abhängigkeiten.
Und diese Abhängigkeiten wirken,
dass eine Änderung vielleicht von hier ganz hinten sich in dem
Listenelement sich über die Liste Übrigens Objekt bis hierhin auswirkt,
obwohl man auf den ersten Blick das gar nicht in den Glas S, die direkten Bezug.
Beispiele war das, was wir hier haben, besser,
ist, dass wir hier eine Operation haben und die etwas tut.
Mir ein Beispiel ist was anderes. Ich sollte nicht hineingreifen,
wie das sein Lieb gestört wird, sondern ich sollte sagen,
ich würde ihm sein Lieb sagen, flieg mal dorthin.
Die Zuständigkeit bei dem Satellitenlassen, dass er selber seine Büsen steuert,
dem hier oben den Studenten selber sagen, okay,
was ist denn,
wie ist denn dein Gesamtergebnis gerade
So, die Definition, was nur auf die mit der SPM
jetzt hier mal nicht durch. Und ich möchte dann,
bevor wir zu Zuständigkeiten kommen, nochmal zu der Frage gehen.
Nämlich hier, Sie sollten in der Lage sein,
die Kopplung zu erläutern. Kopplung aus dem Sinne von,
wir wollen dort eine lose Kopplung haben, ja,
weil wir, damit sich Änderungen nicht so ausbreiten,
damit die Teams miteinander wenig Kommunikation nötig haben,
wenn sie eine Aufgabe erfüllen.
Kommission, wir wollen,
dass die Sachen viel miteinander zu tun haben,
dass also die Aufgaben wirklich eng zusammenhängen,
damit man gleich versteht,
was ist wohl zuständig
Und dieses Gesetz, das sagt eben lose Kopplung.
Und bei Delegation, das war diese lange Kette,
ja, das ist natürlich eigentlich nett,
wenn wir so eine Objekte und hier die Delegation haben,
aber wir geben die Referenz weiter.
Und das ist immer die Gefahr,
dass wir damit sehr starke Kopplungen erreichen.
Soweit erstmal. Dazu weiter geht es
gleich im nächsten Abschnitt