Die UML ist eben eine Sprache, das Hilfe der UML ist eben,
dass wir für die Softwareentwicklung eine Sprache definieren,
die eigentlich einen universellen Anspruch hat,
die eben in allen Bereichen der Softwareentwicklung einsetzbar ist,
die auch weit verbreitet ist,
damit eben viele verschiedene Entwickler oder vielleicht auch eben andere Leute,
die an der Softwareentwicklung beteiligt sind,
die dieselbe Sprache verwenden können,
dass sie auch besser untereinander das dokumentieren können und dann eben untereinander präsentieren können und das Verständnis dafür da ist.
Dafür ist eben eine vereinheitlichte Sprache richtig und wichtig.
Wenn wir jetzt mal vielleicht dieses Beispiel der Klassendiagramme uns angucken,
das ist im Prinzip die einzige verbreitete Sprache,
das macht, was sie dort tut.
Sicherlich werden in Softwareentwicklungen auch andere proprietäre oder selbsterstellte Bilder gemalt,
die vielleicht nicht die UML darstellen, aber das ist im Prinzip dann keine echte Sprache.
Und das ist auch der Grund,
warum wir hier das versuchen zu lernen und gleich auch richtig zu machen,
dass wir sagen, okay, wir haben eine Lotation,
diese ist standardisiert, dann können wir sie auch verwenden,
wenn jetzt eben irgendwo im Unternehmen das anders gemacht wird,
dann muss man das wahrscheinlich akzeptieren.
Aber das ist natürlich nicht unser Anspruch, wenn wir hier
aus der theoretischen Sicht eben uns mit Klassendiagramm oder mit Klassenmodellierung beschäftigen.
Und das gilt im Prinzip auch für die anderen Diagramme.
Klar, bei den Ablaufdiagrammen, insbesondere nachher bei diesen Aktivitätendiagrammen,
das ähnelt dann schon ein bisschen auch der Geschäftsprozessmodellierung.
Da kann man sagen, gut,
einerseits aufgrund des universellen Anspruchs gibt es sowas auch in der UML,
weil natürlich Abläufe modelliert werden
Andererseits kann man natürlich sagen, ich nehme eine BPMN für die Geschäftsprozesse,
dann brauche ich hinterher keinen Ablaufdiagramm mehr in der Software abzubilden.
Wenn sie aber dann eher so diese Kommunikation der Objekte untereinander darstellen wollen,
dann mag die BPMN dann unter Umständen auch nicht mehr so übersichtlich sein.
Da muss man dann eben mal sehen, welches ist vielleicht
das Modell, das Diagramm, was man am besten einsetzt.
Gut, diese verschiedenen Diagramme und Techniken hatte ich dann schon angesprochen.
Ich hatte das auch eben schon angesprochen mit dieser Meta-Modellierung
Sie haben halt eben diese verschiedenen Meta-Ebene. Wir sagen immer
diese M0-Ebene, ist die Objektebene. Also auf der Objekt,
dem es dann die fertige Software oder die Realität im Prinzip anzusiedeln.
Also ein Kunde, der in der Realität ist, ist natürlich auf der M0-Ebene.
Aber für die Softwareentwicklung interessiert uns der Kunde,
der im Hauptspeicher durch ein eindeutig identifizierbares Objekt repräsentiert wird.
Das ist das, was uns da interessiert. Und dass wir
dann eben die Objektebene in unserer Software, wie gesagt,
für solche Objekte müssen wir halt eben die Klassen definieren,
die Struktur definieren, die Attribute, Das sind dann die Instanzvariablen und die Methoden oder Funktionen definieren.
Das machen wir dann eben auf der Klassenebene für eine Klasse,
die wie nähern wir es allgemein und erzeugen dann davon während des Programmablaufsobjekte.
Und um eben diese verschiedenen Diagramme, Klassendiagramme oder eben auch Objektdiagramme
gibt es auch oder Interaktionsdiagramme oder was es da alles gibt,
zu modellieren, gibt es eben diese Mieter Object Facility.
Das ist eine eigens für die UML entwickelte Meta-Modellionsprache, um diese einzelnen Diagrammtypen zu beschreiben.
Also dann wird der Moff definiert. Es gibt eine Class,
in der Class gibt es Attribute, Attribut besteht aus einer Sichtbarkeit,
aus einem Bezeichner, aus einem Datentyp.
Es kann eine Initialisierung stattfinden und eine Methode besteht aus dem und dem und dem.
Das ist halt dann eben diese Konstrukte, was man halt hat.
Sichtbarkeit, Datentyp, Bezeichner, habe ich jetzt so genannt.
Das sind halt eben Dinge,
die dann in der Moff erstmal definiert werden müssen und dann muss eben definiert werden,
wie die praktisch dann eben zusammenspielen in den einzelnen Klassendiagrammen diese verschiedenen Konstrukte,
die es da gibt.
Gut und darauf aufbauen kann man dann auch noch ein Meta-Meta-Modell machen,
was dann wieder diese Moff-Klassen, diese Moff beschreibt,
aber das Ist mehr so eine theoretische Sichtweise.
Wir haben ja eben, hatte ich schon auch angesprochen,
ein Klassendiagramm, Objektdiagramme, Komponentendiagramme und Verteilungsdiagramme.
Das sind, die stellen dann die Struktur dar.
Klassendiagramme werden wir uns eben intensiv angucken. Objektdiagramme werde ich
in ein paar Nebensetzen mal kurz erklären. Da kommt nicht viel Neues hinzu,
weil wir dann eben ja im Prinzip nur die Daten setzen für die Objekte,
den Zustand sozusagen abbilden und diese Objekte,
die brauchen wir dann wiederum in anderen Diagrammtypen.
Gut, und Komponentendiagramme und Verteilungsdiagramme machen wir hier nicht,
weil wir hier nicht so viel Softwarearchitekturen beschreiben.
Aber das kann man dann eben so übergeordnet sehen für so eine Struktur.
Wie soll die ablaufen? Welche Komponenten laufen auf welchem Server
? Das ist natürlich auch wichtig für eine größere Software.
Und dann gibt es sowas wie Use Case Diagramme, Aktivitätsdiagramme,
Interaktionsdiagramme, Zustandsautomaten, die eine unterschiedliche Bedeutung haben. Die Use Case Diagramme wundert man sich vielleicht,
warum die bei den Verhaltensdiagrammen sind,
weil die Use Case Diagramme beschreiben im Prinzip eine Software sehr abstrakt,
sehr allgemein, kann man gut in der Planung einer Software definieren,
wo man eher so allgemein die Use Cases,
also im Prinzip so diese Grundfunktionalitäten, wofür ist die Software eigentlich da,
wo man das beschreibt, wo man versucht, mit wenigen Use Cases eine ganze Software zu beschreiben.
Bei Weitem nicht so detailliert wie ein Klassendiagramm,
wovon dann eben auch Methodenebene einzelne Funktionen dann,
die da detailliert dargestellt werden können. Ja gut,
dieses Use Case Diagramme werden zwar als Verhaltensdiagramm gemacht,
weil man halt eben Abhängigkeiten definieren kann,
welche Use Cases sozusagen welche mit einbeziehen bzw. auf welche
anderen Folgen
Dementsprechend kann man da mit so einem Verhalten so einen Ablauf darstellen,
sind sicherlich aber dafür eigentlich nicht geeignet. Use-Case-Diagramme macht man häufig intuitiv,
wenn man irgendwie eine PowerPoint-Präsentation macht und eine Software vorstellen will,
dann bringt man die wichtigen Punkte,
die malt man in irgendwelche Kreise rein und dann sagt man,
wer benötigt diese Use-Cases und dann malt man da Strichmännchen dran
oder irgendwas anderes dran oder im Wesentlichen wird das Use-Case-Diagramm dann auch so aufgebaut.
Aktivitätsdiagramme eben als Ablaufdiagramm, ähnlich wie die BPMN oder die
anderen Prozessmodelle
Ein bisschen mehr auf die Softwareentwicklung bezogen, werde ich dann auch zeigen. Diese Zustände,
die wir haben, werden dann eher nicht so klassisch abgebildet,
wie wir es aus den Prozessmodellungssprachen kennen,
sondern eher in dieser Objektsprache oder mit diesen Objekten,
die wir halt eben in der UML definieren.
Gut, und diese Interaktionsdiagramme, Sequenzen, Kommunikationsdiagramme,
da dreht man im Prinzip die Sichtweise um,
wenn die Aktivitätsdiagramme mehr aus der Funktionssicht einen Ablauf darstellen,
dann tun die Interaktionsdiagramme das mehr aus der Objektssicht
Wie gesagt, man muss nicht immer für jeden Ablauf alle Diagramme machen.
Sie sind dann teilweise auch sehr ähnlich, dass kein Mehrwert
unbedingt dadurch entsteht, dass man ein weiteres Diagramm macht.
Und dieser Zustandsautomaten, die habe ich auch hier zwar noch genannt,
aber dann aus der Vorlesung rausgeschmissen, weil sie eigentlich so ganz schön sind.
Man kann sie gut erklären und am Ende habe ich mich mal irgendwann gefragt,
ob wann schon jemals irgendjemand ein Zustandsautomaten oder so ein Spacechart eingesetzt hat,
habe ich auch mal rumgehört.
Im Prinzip ist das etwas, theoretisch ganz schön ist,
weil man sagen kann, okay,
auf welchen das Ereignis wird welche Aktion durchgeführt und wie ändert sich der Zustand denn der Software.
Aber am Ende außer dem Beispiel mit der Digitaluhr,
wo man irgendwie auf die Knöpfe drückt und dann fängt die Uhr an zu blinken.
Und dann kann man die Uhrzeit vorstellen oder so.
Über dieses Beispiel hinaus gibt es eigentlich keine dokumentierten Anwendungsfälle und
auch in den Projekten oder mit den Leuten,
mit denen ich gesprochen habe, werden die wohl auch eher nicht eingesetzt.
Gehören wir zur UML, aber ich habe sie aus diesem Grund eher nicht mehr verwendet.
Wohingegen die anderen Diagramme, die ich hier nenne,
durchaus sinnvoll sind. Die Interaktionsdiagramme vielleicht nicht unbedingt,
dass jetzt so viel damit modelliert wird,
aber gerade auch für das Verständnis der Objektorientierung finde ich es gerade in der Vorlesung gut,
dass man sich da mit einmal beschäftigt.
Gut, kommen wir dann zu den UML-Klassendiagrammen.
Bei NuMAL-Klassendiagrammen haben wir ja gesagt, wir haben im Prinzip
so die Struktur der Software darzustellen. Es ist so,
dass wir natürlich irgendwo die Realität kennen vielleicht, irgendwie analysieren.
Wir haben vielleicht auch die Abläufe analysiert
Wir müssen uns überlegen, welche Daten müssen gespeichert werden?
Welche Funktionen brauchen wir eigentlich? Bevor wir dann eben die Prozesse
wirklich umsetzen können, müssen wir natürlich die einzelnen Prozessschritte,
die einzelnen Funktionen irgendwie abbilden.
Zumindest die, die dann auch in dieser Software abgebildet werden sollen.
Und wir müssen dann eben dafür sorgen,
dass diese Daten auch wirklich im Hauptspeicher dann jeweils vorhanden sind.
Wir müssen uns damit beschäftigen, aus welchen Datenbanksystemen die vielleicht kommen,
brauchen wir ein eigenes Datenbanksystem.
Aber das ist wieder auch gar nicht unbedingt die Aufgabe der Softwareentwicklung,
die Softwareentwicklung sagt erstmal vor allen Dingen,
welche Daten benötigen wir
Welche Funktionalitäten wollen wir umsetzen? Und das machen wir bei
einer objektorientierten Programmiersprache alles in Klassen. Wir müssen uns
halt erst mal überlegen, welche Klassen brauchen wir?
Brauchen wir jetzt irgendwie den Kunden? Brauchen wir eine Rechnung
? Brauchen wir eine Bestellung? Brauchen wir einen Artikel?
Brauchen wir eine Rechnungsposition? Also das sind vielleicht alles irgendwelche
Klassen, die wir definieren müssen.
Müssen wir die vielleicht dann eben noch mal ein bisschen spezifizieren?
Brauchen wir verschiedene detaillierte Klassen? Also müssen wir Rechnung und Rechnungsposition
getrennt machen? Oder lassen wir das in einer Klasse?
Haben wir wirklich nur eine Art von Kunden, die wir abbilden?
Oder haben wir Geschäftskunden und Präsenz Privatkunden, sind das vielleicht
unterschiedliche Kunden oder sind die dann doch eher ähnlich?
Das sind alles Fragen, die man als allererstes stellen muss
und dann auch erstmal so eine Grundstruktur vor allen Dingen und
man wird die dann auch nach und nach dann immer weiter verfeinern.
Aber diese Grundstruktur überhaupt zu sagen, was brauchen wir?
Das ist dann eben diese Klassifikation oder diese Typisierung, die wir als allererstes machen müssen.
Wir werden das hier in den Übungen auch selber machen.
Ich werde irgendwie einen Aufgabentext schreiben, wo ich relativ deutlich am Anfang sage,
welche Klassen ich sozusagen erwarte für dieses Programm.
Andererseits kann man manchmal auch sagen, okay,
ich hätte hier vielleicht eine Klasse mehr gemacht oder eine weniger,
dann können wir darüber diskutieren.
Es gibt hier nicht unbedingt immer eine Lösung. Es ist auch so in der Praxis,
wenn man Software entwickelt, der eine macht so,
der andere macht es anders und für beides gibt es Argumente.
Wichtig ist mir hier,
dass sie in den Übungen und in der Vorlesung lernen,
was wir da eigentlich tun,
dass sie sozusagen dann auch mit diskutieren können,
mit argumentieren können oder zumindest auch erkennen können,
welchen Unterschied macht es,
ob ich ein Modell und damit nachher auch meine Softwarestruktur
so oder anders aufbaue
Einmal ist es unwichtig, da muss man auch nicht lange diskutieren.
Manchmal mag es aber dann eben irgendwelche Auswirkungen haben,
die man dann eben versucht, auch schon von Anfang an mit einzubeziehen.
Gut, wenn man diese Klassifikation hingekriegt haben,
gibt es im Prinzip nur zwei weitere Sachen,
die wir machen müssen, auch wenn hier noch vier weitere Sachen stehen.
Es gibt einmal diese Generalisierung, Spezialisierung, das ist eben das Gleiche,
obwohl man vielleicht denken könnte, das ist das Gegenteil,
das ist wohl eine Frage der Perspektive wieder.
Also wenn wir jetzt sagen, wir haben einen Kunden,
können wir sagen, es gibt vielleicht allgemeine Dinge,
die zu einem Kunden gehören, eine Adresse,
eine Kundennummer, Name, ein Vorname oder sowas.
Aber jetzt mag es sein, dass wir eben unterscheiden zwischen Privatkunden und Geschäftskunden.
Und der Geschäftskunde hat zusätzlich vielleicht noch einen Ansprechpartner,
vielleicht eine separate Lieferadresse, vielleicht irgendwelche,
besonderen Rabatte und der Privatkunde, der hat vielleicht noch eine Bonitätsprüfung,
die gemacht werden muss oder sonst irgendetwas.
Also wir können vielleicht sagen, wir kommen nicht mit einer Kundenklasse aus.
Wir müssen sie spezialisieren. Wir machen eine spezielle Klasse,
die heißt Privatkunde und die andere Klasse
heißt Geschäftskunde
Können aber auch sagen, das, was beide gemeinsam haben, das können wir generalisieren.
Und deswegen, wenn wir aus der Subklasse kommen,
also aus dem Speziellen, aus dem Geschäftskunden,
aus Privatkunden, dann generalisieren wir das und schreiben alles,
was dann generell ist, alles in die Kundenklasse rein.
Und wenn wir aus der Kundensicht kommen, dann spezialisieren wir das.
Deswegen ist es das Gleiche. Das ist in der Programmierung
dann diese Vererbung. Das werden wir uns angucken. Gut,
und dann haben wir eigentlich nur noch die Assoziation und die Assoziation,
da gibt es noch zwei Spezialformen von.
Bei der Assoziation, das ist die Beziehung zwischen den Klassen untereinander,
die brauchen wir mal dann,
wenn wir beispielsweise jetzt eine Rechnung haben zu dieser Rechnung,
Da gehört ein Kunde, dieser Kunde.
Der hat irgendwelche Bestellungen durchgeführt. Bei den Bestellungen wollen irgendwelche
Artikel bestellt und vielleicht auch geliefert oder hoffentlich auch geliefert.
Und dann haben wir eben diese Rechnung.
Und diese Rechnung besteht dann meinetwegen aus Kunde,
aus vielleicht dann einzelnen Attributen selber, Datum,
Rechnungsdatum und vielleicht noch irgendwelche anderen Sachen.
Rechnungsnummer. Und dann meinetwegen aus Rechnungspositionen,
die Rechnungsposition bestehen dann vielleicht aus dem Artikel und bin halt dann eine Menge und ein Preis.
Und dann gibt es noch die Summe der gesamten Rechnung und
das Zahlungsziel und irgendwelche anderen Sachen
Und da müssen wir eben sehen,
wir kommen jetzt hier eigentlich nicht mit einer Klasse aus.
Wir müssen diese Klassen so miteinander in Beziehung setzen, dass das,
was wir abbilden wollen, auch sinnvoll abgebildet wird.
Und das ist halt eben dann diese Assoziation, die wir praktisch benutzen.
Und diese Assoziation ist sozusagen die eine Beziehung,
mit der wir uns gleich intensiv erstmal beschäftigen werden.
Gut, dann gibt es die Aggregation,
die Aggregation ist sozusagen ein bisschen verstärkend, dass wir sagen,
wir sagen nicht die Rechnung, hat einen Kunden.
Also an der Stelle würden wir sagen,
das ist eine Assoziation
Wir können aber auch sagen, beispielsweise die Rechnung besteht aus Rechnungspositionen.
Und wir waren ja in eine klasse Rechnung haben und eine klasse Rechnungsposition,
dann würden wir sagen, die Rechnung besteht aus Rechnungspositionen.
Und dann können wir sagen, das ist eine Aggregation,
das ist eine andere Symbolik, eine andere Notation,
hat für die Programmierung im Prinzip gar keine große Auswirkung oder gar keine Auswirkung.
Es ist eine Spezialform der Assoziation. Man könnte es auch
als Assoziation machen und sagen, die Rechnung hat Rechnungspositionen.
Das ist im Prinzip so sprachlich, die Assoziation,
sagen wir, ist eben dieses,
hat eine Beziehung,
die Rechnung hat einen Kunden
Die Rechnung hat, Rechnungspositionen. Und wenn wir sagen können,
besteht aus, dann ist es dann eben eine Aggregation.
Aber es ist eher etwas Sprachliches. Es ist etwas,
was wir ausdrücken wollen. Aber das ist ja auch das,
was in der Modellierung das Ziel manchmal ist, dass ja gewisse Dinge zeigen wollen.
Und dann wird man vielleicht mal eine Aggregation malen,
um dann eben zu unterstreichen, wie die Beziehung da ist.
Und dann gibt es noch diese Komposition,
das ist dann eben so eine existenzielle Beziehung, das würde man sagen,
okay, diese Rechnungspositionen könnten auch existenziell von der Rechnung abhängig sein.
Das heißt eben, es klingt immer so dramatisch,
aber es heißt eigentlich nur,
dass diese Rechnungspositionen innerhalb der Rechnung mal existieren können,
dass wir eben keine Rechnungspositionen haben, die außerhalb einer Rechnung steht.
Sie wird halt immer von diesen Rechnungen dann erzeugt,
meinetwegen und mit der Rechnung, wenn wir sie zerstören würden,
das Objekt zerstören würden, würden auch die Rechnungspositionen zerstört werden.
Das hat eine Auswirkung auf die Programmierung,
ist jetzt aber für uns auch nicht so richtig.
Gut, gucken wir uns das nochmal im Detail an.
Fangen wir erstmal an mit der Klassifikation.
Ich habe hier wahllos ein paar Daten aufgeschrieben. Ich sage,
wir haben Artikel 1, das ist eben Farbdrucker,
der hat dann
eine Bezeichnung
Und wir haben dafür einen Hersteller, der hat auch eine Nummer.
Und der Hersteller hat auch einen Namen. Dann haben wir
eben in der zweiten Zeile irgendeinen Artikel 2 und einen Hersteller dazu.
Das ist zufälligerweise der Gleiche. Und Artikel 3 ist dann
ein anderer Hersteller und der Artikel 4 auch. So,
und wenn wir jetzt mal überlegen, welche Klassen brauchen wir,
liegt das hier relativ klar auf der Hand.
Wir wollen eine Artikelklasse haben und wir wollen eine Herstellerklasse haben.
Und wenn wir jetzt mal überlegen,
welche Attribute gehören eigentlich in die Artikelklasse,
dann sind das im Prinzip die alle,
die mit A anfangen,
nämlich die Artikelnummer,
die Artikelbezeichnung und der Artikelpreis
Und welche gehören in die Herstellerklasse? Natürlich die mit Hart anfangen,
die Herstellernummer und der Herstellername. So einfach ist es natürlich
nicht immer, aber das soll ja erstmal das Beispiel sein.
Damit haben wir die Aufgabe der Klassifikation praktisch schon gelöst.
Ich habe jetzt hier die Notation schon verwendet. Ich habe
hier das Minus gesetzt. Das ist sozusagen die Sichtbarkeit,
nennen wir das, ob ein Attribut, Private oder Public ist.
Wir werden diese Sichtbarkeit jetzt nicht so ausführlich behandeln.
Das ist für die Programmierung wichtig,
aber jetzt nicht für die Modellierung so sehr.
Wir machen immer dieses Minus davor und das heißt eben,
sie sind private
Dann haben wir den Bezeichner, Artikelnummer, also ein R-A-D-Z und A-P-R.
Dann kommt Doppelpunkt und dann kommt der Datentyp.
Da haben wir Endtager als Ganzzahlen. Also die Artikelnummer soll
eine ganze Zahl sein, haben wir festgelegt.
Die Artikelbezeichnung sollen stringen, also ein Text sein.
Und der Artikelpreis soll eine Dezimalzahl, also ein Double sein.
Hersteller Nummer soll wieder ein Endtager sein und der Herstellernahme
auch wieder ein Text als so ein String.
Wir können uns jetzt mal hier Können Sie sich es mal selber
überlegen? Dann würde er sagen, wir haben folgende Daten.
Wir haben Kunden mit Nachnamen, Vornamen, Straßennummer,
Hausnummer und so weiter. Und wir wollen dazwischen Lieferadressen und
Rechnungsadressen unterscheiden. Der Kunde verfügt über ein Konto mit Kontonummer
und das Konto bezieht sich dann eben auf einen Kunden.
Jetzt müssen wir uns mal überlegen, was brauchen wir?
Welche Klassen brauchen wir? Wir brauchen sicherlich irgendwie eine Klasse Kunde
. Brauchen wir irgendwie eine Klasse, Lieferadresse und Rechnungsadresse?
Oder brauchen wir eine Klasse Adresse? Müssen wir uns überlegen
Und dann haben wir gesagt, ein Konto gibt es auch noch.
Brauchen wir eigentlich eine Klasse fürs Konto?
Oder können wir sagen, der Kunde hat ja ein Konto?
Können wir die Kontodaten vielleicht direkt in den Kunden mit aufnehmen?
Müsste man sich eben auch überlegen, wie macht man das?
So, auch hier gibt es schon im Prinzip Fragestellungen,
die man bei der Klassifikation beantworten müsste.
Oft ist es so, dass man diese Fragen stellen müsste,
dass man den Sachverhalt besser kennen müsste.
Wir können sich ja mal darüber Gedanken machen,
wie sie es hier sozusagen abbilden würden,
welche Klassen sie definieren würden.
Da würde ich auch nochmal überlegen,
welche anderen Möglichkeiten gibt es und
welche Fragen
man stellen müsste
Das ist sozusagen jetzt erstmal so für sie als Aufgabe.
Wir können das nachher nochmal aufgreifen,
aber ich lasse das erstmal so weit stehen,
die Aufgaben oder die Beispiele oder die Fragestellungen,
die hier in den Folien sind, die lasse ich erstmal offen,
wenn da in den Übungen Fragen zu kommen, beantworte ich das gern.
Gut, wir haben eben jetzt nochmal die Notation allgemein,
wenn wir sagen, wir haben eine Klasse,
hatte ich gesagt, die hat eine Sichtbarkeit,
hat einen Namen oder einen Bezeichner,
hat einen Datentyp,
wir können einen Initialwert vergeben,
hier zum Beispiel gleich
Hier auch gleich N.N. Punkt. Das wäre eben dann
der Wert, der am Anfang drinsteht.
Und wir können auch eine Zusicherung definieren und sagen,
okay, der Artikelpreis muss immer röstergleich null sein.
Wir müssen dann eben sehen, wie das in der Programmiersprache umgesetzt wird.
Aber ich werde auch oft sagen, wir modellieren ja nicht für eine Programmiersprache.
Wir modellieren erstmal ein Modell. So, und dieses Modell
soll dann umgesetzt werden. Und ein paar Aufgaben müssen ja
die Programmierer nachher auch noch übernehmen und sich überlegen, wie sie es umsetzen.
Auf der anderen Seite sage ich dann auch manchmal,
wir müssen bei der Modellierung auch die Implementierung im Blick haben,
weil wenn wir zu abstruse Modelle machen,
dann versteht ihr erstmal keiner und zweitens kann man die vielleicht dann auch gar nicht umsetzen.
Also immer so ein Mittelweg, natürlich sollen wir uns nicht jede Kleinigkeit hier schon überlegen,
wie man sie programmiert, dann bräuchten wir nichts zu motivieren.
Aber umgekehrt dürfen wir natürlich auch nicht zu weit weg von der Programmierung sein.
So, die Modellierung der Methoden erfolgt dann in ähnlicher Weise. Also wenn wir eine Methode definieren,
machen wir das im unteren Bereich der Klasse,
die Klasse haben wir hier oben mit dem Bezeichner,
dann die Attribute und dann kommen halt eben die Methoden haben wir die Methode,
die Sichtbarkeit, sei es Plus-Gesetz, plus heißt Public,
gehe ich jetzt aber auch nicht groß drauf ein,
was das bedeutet, kann man sich aber vorstellen,
dass es halt eben öffentlich ist,
dass man von weiter darauf zugreifen kann.
Dann der Bezeichner der Methode oder der Name der Methode,
dann kommt die Parameterliste mit Datentyp immer.
Er ist der Name des Parameters, Doppelpunkt-Datentyp und dann den Datentyp der Methode.
Hier haben wir die Methode, die nennen wir brechende Netto,
die soll anscheinend aus dem Artikelpreis, der einen Brutto-Preis ist,
und zu unter zu Hilfenahme der Umsatzsteuer oder des Umsatzsteuersatzes eben den Netto-Preis berechnen.
Und das Ergebnis zurückgeben. Das heißt eben,
wir müssen den Umsatzsteuersatz kennen, dementsprechend brauchen wir den hier als Parameter,
weil es den ja nicht im Artikel gibt.
Und wir müssen halt dann eben auf Basis dieses Artikelpreises und auf
dieses Attribut können wir aus der Methode berechnen und netto darauf zugreifen,
müssen wir dann eben diesen Netto-Preis berechnen und zurückgeben.
Also das ist dann der Rückgabewert der Methode, bezeichnen wir das. Also das Ergebnis der Methode,
wenn sie halt einen Taschenrechner nehmen und da irgendwie den Sinus von X reintippen,
dann wird der Parameter der X und das Ergebnis der Sinus von X, wer dann eben der Rückgabe wehrt. So,
jetzt haben wir hier eine andere Methode,
da habe ich die Klammern leer gelassen, das heißt,
ich will irgendwelche Daten ausgeben, aber die Daten,
die ich ausgeben will, sind meinetwegen die Daten,
die hier in den Attributen gespeichert sind, also die Artikelnummer,
Artikelbezeichnung, Artikelpreis will ich meinetwegen ausgeben,
die muss ich dann nicht als Parameter übergeben oder darf ich gar nicht mal übergeben,
sinnvollerweise, weil ich dann eben, ja,
das ja doppelt machen würde,
also bei der Datenausgabe will ich die Daten des Objektes hier ausgeben,
die in diesen Instanzvariablen oder in diesen Attributen
gespeichert sind
Und wenn ich mal irgendwie eine Ausgabe machen will,
dann brauche ich auch kein Ergebnis. Ich will die nicht zurückgeben,
sondern ich will die irgendwo auf dem Bildschirm ausgeben beispielsweise.
Dann gibt es vielleicht gar keinen Rückgabewert der Methode.
Ich habe da jetzt nichts vergessen, sondern wenn eine Methode nichts zurückgibt,
dann schreibt man nichts hin. In Programmiersprachen wird die nichts,
wenn man nichts zurückgibt, wird das meinetwegen als Boyd bezeichnet,
in Java beispielsweise in anderen Programmiersprachen,
in Bushu-basic.net unterscheiden wir zwischen den Subs und den Function,
dass wir sozusagen dann eine Sub,
nämlich hier hat keinen Rückgabewert und eine Function,
wer das,
die hätte Einrückgabewert
Und das Gleiche machen wir hier bei dem Hersteller auch.
So, und damit haben wir im Prinzip die Klassifikation abgeschlossen.
Wir haben alle Notationselemente kennengelernt, die wir brauchen, um eine Klasse darzustellen.
Das ist nicht viel. Aber natürlich ist die Schwierigkeit, die Anwendung.
Man muss halt eben überlegen, welche Attribute gehören in welche Klasse.
Wie definiere ich die? Wenn man ins Reell macht,
muss man sich dann auch überlegen, welche Datentypen vergebe ich.
Das liegt meistens auf der Hand. Aber da muss man sich überlegen,
welche Zusicherung braucht man. Vielleicht hat man irgendwelche Konsistenzen,
die man für die Daten benötigt,
dass eine Zahl zwischen 0 und 100 liegen muss und eine
andere größere Null sein muss und eine dritte muss wieder irgendwie anders sein.
Das sind halt eben Sachen,
die man sich auch schon überlegen sollte und vor allen Dingen auch die Methoden,
die Funktionen, weil häufig ist es so, dass man sagt,
okay, wir wollen jetzt eine Methode haben, die heißt beispielsweise Rechnungsbetrag berechnen.
Dann würde man sagen, okay,
wahrscheinlich schreibe ich die in die klasse Rechnung rein,
aber dann muss man ja für diesen Rechnungsbetrag die einzelnen Rechnungspositionen
bewerten und dann muss ich eben sehen,
dass ich die auch wieder jeweils berechnen muss und dann wieder die Summe ausgeben muss.
Also gut, ich werde dabei bleiben. Sie gehört in die Klasse-Rechnung,
aber vielleicht wird ein anderer auf andere Ideen kommen.
Und da muss man dann immer abwägen, was ist sinnvoll,
in welche Methode kommt sinnvollerweise, in welche Klasse.
Und manchmal bei großeren Projekten trennt man dann auch,
dann sagt man, okay, diese Klasse wird uns zu groß.
Das kann auch ein Grund dann sogar manchmal sein.
Und man sagt, ich trenne jetzt die Logik.
Ich mache zwei Klassen oder mehrere Klassen draus und die Methoden,
die dafür zuständig sind, machen das und die kommen da rein.
Also das kann schon dann eben eine etwas anspruchsvollere Aufgabe sein,
diese Klassifikation
Aber von der Notaktion her ist es im Prinzip das,
was ich hier gezeigt habe.
Da ist nicht viel zu lernen. Es gibt dann zwar noch so
ein paar Erweiterungen, die man ja mal gebrauchen kann.
Aber im Prinzip muss man dann auch wieder irgendwie ein bisschen verstehen,
was eigentlich Programmierung ist. Ich habe ja vorhin gesagt,
wir haben für jedes Objekt die Daten einzeln zu speichern.
Die Aussage stimmt auch. Wir haben eben unsere Attribute,
Artikel und Matike, bezahlten Artikelpreis.
Die sind dann eben für jeden Artikel unterschiedlich.
Ich habe verschiedene Artikelobjekte
Jedes Objekt hat seine eigenen Daten, seinen eigenen Bereich.
Und wenn ich die Daten in einem Objekt ändere,
hat das keine Auswirkungen auf die anderen Objekte.
Jetzt gibt es eine Ausnahme, das sind die sogenannten Klassenattribute.
Die Klassenattribute gehören sozusagen zur Klasse, werden einmal für die Klasse gespeichert,
schreibt man auch eben in die Klasse mit rein.
Von der Programmierung her, aber die gehören ihm nicht zu den Objekten.
Und deswegen, wenn wir sowas haben wollen,
ich habe das hier mal so definiert,
dass ich sage, wir haben die Anzahl der Artikel,
die soll immer hochgezählt werden,
wenn ein neues Artikelobjekt erzeugt wird
Dann wollen wir das eben nicht immer haben,
dass jedes neu bei Null anfängt zu zählen und jeder für sich
anfängt zu zählen und sagt, wie viele Objekte gibt es?
Und jedes Objekt sagt natürlich, es gibt sich und zählt dann eben auf eins hoch.
Nein, es soll eben für alle Artikel gezählt werden.
Und dann müssen wir es halt eben einmal für die Klasse
speichern und dann könnten wir das hochzählen.
Ist jetzt vielleicht nicht so ein ideales Beispiel,
aber mir fiel ja jetzt nichts Besseres ein.
Ist auch nicht etwas, was wirklich wichtig ist.
Vielleicht haben wir das mal in der Übungsaufgabe drin,
wo wir sagen, das könnten wir als Klassenattribut machen,
aber nicht ganz so richtig.
Und dann gibt es auch diese abgeleiteten Attribute,
die mit dem Slash hier definiert werden
Würden wir in der Programmierung wahrscheinlich eher als Berechnungsgrundlage, also als Berechnung,
als Methode programmieren. Aber wenn wir jetzt sagen, okay,
die Bewertung, die ergibt sich aus irgendwelchen anderen Attributen,
meinetwegen aus der Qualitätskennzahl und der Kostengennzahl.
Und wenn wir solche Kennzahlen haben,
dann können wir da meinetwegen eine Formel hinterlegen und sagen,
das ist sozusagen die Formel für die Bewertung.
Klassisches Beispiel für abgeleitete Attribute ist das Alter,
wenn man das Geburtsdatum für eine Person speichert,
dann kann man das Alter jeweils berechnen,
dann wäre das eben auch eine Berechnung nach dieser Form,
dass wir sagen,
wir nehmen das heutige Datum und beziehen das dann aufs Geburtsdatum
Und können dann eben das Alter berechnen. Aber da ich
jetzt hier keine Person oder so als Beispiel habe,
musste ich mir was anderes ausdenken.
Gut, vielleicht werden wir auch nochmal ein abgeleitetes Attribut sehen,
aber hat jetzt auch nicht so die ganz große Bedeutung.
Gut, und ich hatte auch versprochen,
dass ich einmal kurz auf die Objektdiagramme eingehe. Ja,
die Objektdiagramme sind im Prinzip das Gleiche wie die Klassendiagramme.
Nur wir sagen, jetzt wollen wir ein Objekt darstellen.
Ein Objekt, habe ich gesagt, ist eindeutig unterscheidbar.
Deswegen unterstreichen wir das hier. Wir können eine Objektreferenz
davor schreiben,
dieses A-Doppelpunkt-Artikel
Meistens lässt man das auch noch weg.
Schreibt nur Doppelpunktartikel und sagt, jetzt habe ich ein Objekt.
Und dann kann ich in das Objekt praktisch Werte eintragen,
weil es beinhaltet ja Daten.
Das Objekt hat einen Zustand. Und dann kann meinetwegen der
Zustand sich ändern. Ich rufe die Methode Preiserhöhung auf.
Und dann wird eben aus dem Artikelpreis vielleicht aus 129,95,
139,95. Und dann hat diese Methode sozusagen den Zustand des Objektes geändert.
Wir sagen immer bei den Mekhoden,
es gibt einen Ausgangszustand oder einen Anfangszustand.
Dann läuft die Methode ab und dann gibt es
einen Endzustand
Weil man verändert sich nicht unbedingt der Zustand des Objektes,
aber dann sind eben Anfangszustand, Endzustand gleich.
Wenn wir zum Beispiel hier sagen, berechne netto,
dann würden wir hier sagen, wir haben den Artikelpreis,
109, 29, 95.
Das wäre ja der Bruttopreis. Wir lassen die Methode berechnen netto ausführen.
Die berechnen netto, würde dann eben beim Umsatzsteuersatz von 19 Prozent
den entsprechenden Wert berechnen und dann eben zurückgeben.
Dann würden sich aber diese Daten hier alle nicht ändern.
Und dann haben wir halt eben Ausgangszustand gleich Endzustand.
Aber grundsätzlich könnte auch eben die Methode sagen, okay,
ich erinnere den Artikelpreis oder die Artikelbezeichnung oder die Artikelnummer
Ändert sich der. Also jede Methode innerhalb eines,
die wir innerhalb einer Klasse definieren,
kann dann eben auf den Zustand praktisch des Objektes zugreifen.
Aber mit den Objektdiagrammen machen wir auch nicht weiter.
Wir haben nur nachher diese Darstellung mit diesem Doppelpunktartikel und sagen,
das ist jetzt ein Objekt und dann lassen wir die Inhalte auch immer der Übersichtlichkeit weg.
So, kommen wir dann zu den Assoziationen. Das ist nochmal sehr wichtig,
diese Assoziationen sind eben die Beziehungen zwischen den Klassen.
Wichtig ist, dass wir eine Assoziation zwischen Klassen definieren und nicht zwischen Attributen.
Wenn Sie an die Datenmodellierung denken, dann werden wir vielleicht
gewisse Ähnlichkeiten feststellen. Da gab es ja auch solche Beziehungen,
aber die haben wir ja mal zwischen Schlüssel und Fremdschlüsselattribut hergestellt,
also Primär- und Fremdschlüsselattribut. Das machen wir hier nicht.
Wir sagen jetzt hier, wir haben meinetwegen einen Hersteller,
der Hersteller, der stellt verschiedene Artikel her.
Also der Hersteller hat eine Artikelliste, diese Artikelliste ist halt beliebig lang.
Der kann null oder beliebig viele Artikel herstellen.
Und dann schreiben wir es auch immer bei der Artikelseite hin,
was der Hersteller macht, also immer auf die entgegengesetzte Seite,
ein Unterschied zur Datenmodellierung.
Und wir können sagen, der Artikel für den Artikel,
für diesen einen Artikel gibt es immer einen Hersteller.
Für den Drucker HP XYZ ist halt dann immer der Hersteller HP.
Und für den Monitor Dell 43-17 ist dann der Hersteller natürlich Dell.
Also dementsprechend, so wie wir hier Hersteller definieren,
gibt es diesen Artikel immer nur von einem Hersteller.
Und dann wäre das hier eine 1-zu-N-Beziehung, die wir definieren.
Also wenn wir es allgemein sagen, sagen wir hier A,
steht in Beziehung zu B. Hier ist sozusagen von A aus
gesehen, sagen wir beliebig viele und B,
kann eben auf ein Objekt zurückgreifen
Und das ist im Prinzip diese Beziehung, die wir machen.
Wir könnten dir vielleicht auch sagen, naja, nee,
könnten wir ja nicht sagen, die Frage wäre,
können wir sagen, du steht ein Hersteller aus Artikeln, eher nicht.
Deswegen würden wir hier keine Aggregation machen. Wir können das
aber nochmal ein bisschen ausführlicher aufschreiben. Also jetzt habe ich
die ganze Klasse nochmal aufgeschrieben und die Assoziation dazu.
Weil sonst hätten wir auch gar nicht das,
was wir ganz am Anfang hatten, darstellen können.
Wir wollten ja schon diesen Zusammenhang zwischen Artikeln und Herstellern darstellen, die ganzen Daten haben.
Und ich habe das jetzt mal hier spaßeshalber in Java übersetzt.
Wie gesagt, sie müssen nicht notwendigerweise eine Programmiersprache kennen,
aber ich werde hier schon Beispiele, Code-Beispiele aufbringen, für diejenigen,
die programmieren, ein bisschen was kennen, hilft das und vielleicht den anderen sogar auch.
Also wir sagen, es gibt im Prinzip eine klasse Hersteller,
das wird dann in Java mit Public Class definiert und dann haben wir dieses Minus,
das heißt Private, hatte ich vorhin gesagt,
das ist die Sichtbarkeit oder in der Programmiersprache der Gültigkeitsbereich und dann sage ich hier eben diese Datentypen,
der Endager ist in Java ein End,
der String bleibt ein String, der Double ist auch ein Double,
wir haben dann eben diese vier Attribute,
die ersten vier Attribute hier durch vier Instanzvariablen abgebildet.
Das Attribut-Bewertung, das abgeleitete Attribut, habe ich hier als Methode abgebildet,
weil das halt eben in Java jetzt nicht hinter einem Attribut eine Formel stecken kann,
sondern ich muss dann eine Methode definieren.
Das ist halt eben der Unterschied wieder zwischen Modellierung und Programmierung.
Vielleicht gibt es andere Programmiersprachen, wo ich sagen kann,
dieses Attribut berechnet sich immer aus den und den Attributen.
Ich lege da eine Formel hinter und dann kann ich das praktisch so machen.
Hier ist sozusagen die Formel in eine Methode reinzuprogrammieren.
Dieses Return-Qualität kennst du halt durch Kostenkennzahl habe ich ausgekraut ein bisschen,
weil das aus dem Klassendiagramm nicht ersichtlich wird.
Ich habe es aber als Beispiel mal gemacht, dass man sieht,
das ist irgendwie eine Funktionalität, die dahinter steht.
Aber ich habe, das sehen wir hier nicht, wie sich das berechnet.
So, genau, dann wäre das Attribut jetzt auch geklärt. So,
und dann haben wir noch diese Assoziation und diese Assoziation,
die würden wir im Jahr aber auch durch eine Instanzvariable darstellen.
Weil wenn wir sagen, der Hersteller hat eine Artikelliste,
dann sagen wir auch der Hersteller, der referenziert verschiedene Artikel,
die sozusagen von ihm angeboten werden
Und das würden wir in einer Programmiersprache oder in Java
jetzt mit einer Arelist abbilden können oder mit einem Array.
Wir können da verschiedene Speicherstrukturen verwenden. In anderen Programmiersprachen auch
in VW.net oder in C-Sharp hören wir das als List bezeichnen.
Das sind halt eben die Möglichkeiten, die wir da haben.
Und das ist halt, dass wir diese Assoziation als Instanzvariable hier abbilden,
ist halt eben das Vorgehen, wie man so etwas übersetzt.
Das ist in den meisten Programmiersprachen so in objektorientierten Programmiersprachen,
dass wir halt eben diese Referenzen auf Objekte anderer Klassen direkt
in die Instanzvariablen oder in die Attribute der Klasse mit aufnehmen.
Hier als Liste, weil wir natürlich hier null bis Stern haben.
Wenn wir jetzt bei die Klasse Artikel übersetzen würden,
dann würden wir sagen, okay, wir brauchen nur einen Hersteller,
dann würden wir hier hinschreiben Private-Hersteller.
Also als Datentyp-Hersteller, Großhersteller im Schreiben und dann ein Kleinheitshersteller ist Zeichner.
Wie gesagt, diese Fähigkeit, dass jetzt das Übersetzen müssen,
brauchen sie im Prinzip nicht,
auch wenn wir das nochmal in der Übungsaufgabe machen,
so fürs Verständnis.
Aber wer jetzt vielleicht das nicht so ganz durchdringt,
weil er kein Java kann,
ist dann doch
nicht ganz so dramatisch
Gut, ich will jetzt nochmal ein Beispiel zeigen,
wo wir eben die verschiedenen Assoziationen und die Klassifikationen einmal durchgehen.
Auch ich zeige jetzt hier beispielhaft, wie man es machen kann.
Da gibt es sicherlich auch wieder verschiedene Möglichkeiten. Ich sage,
wir haben halt eben so eine Studierendenverwaltung,
da wollen wir eben Anmeldungen von Studierenden und Verwalten,
die sich zu irgendwelchen Vorlesungen anmelden,
so ähnlich wie wir es in Stine machen.
Und man muss sich einloggen und wir keine Login-Daten hatten,
muss sich registrieren und nach dem Einloggen kann man sich an
oder abmelden
Und man kann ihn sich auch wieder ausloggen und im Prinzip
kann man sich zu beliebig vielen Vorlesungen anmelden und in
den Vorlesungen können erstmal auch beliebig viele Studierende angemeldet sein.
So, das habe ich jetzt mal übersetzt,
dass ich gesagt habe, okay, was brauchen wir eigentlich als Klassen?
Klar, wir brauchen eine Klasse, die nennen wir Student
und wir brauchen eine Klasse, die nennen wir Vorlesung.
Dann sagen wir aber noch,
wir brauchen jetzt eine Klasse für die Teilnahme,
wie die Teilnahme sollen vielleicht auch Daten gespeichert werden,
wann sich der Student angemeldet hat,
vielleicht später dann auch die Punkte,
die er da gemacht hat,
die Note oder irgendwelche anderen Sachen
Also die Anmeldung wollen wir ja erstmal alle speichern.
Vielleicht müssen wir auch noch speichern, ob die Anmeldung angenommen wurde.
Also ob der wirklich in dem Kurs drin ist oder eben nicht.
Da kann man eben sich vieles überlegen, was sind so
eine Teilnahmeklasse mit rein muss. Und dann will ich noch
so eine Verwaltungsklasse haben, wo ich sage, okay,
ich brauche irgendwie einen Einstiegspunkt nachher für diese ganze Verwaltung.
Ich muss das Login irgendwie abbilden und Lockout und sonst was.
Muss ich auch eben sehen,
dass ich in der Verwaltung dann in dieser Verwaltungsklasse dann eben
diese Funktionalitäten
auch initiieren kann
Gut, dann machen wir die Attribute beim Studenten,
sage ich, einfach nach Username Passwort und dann eben,
ob er authentifiziert ist oder nicht.
Soll da gespeichert werden. Bei der Vorlesung sage ich,
Titel, Raum, Dozent, wie auch immer.
Und bei der Teilnahme sage ich,
es soll ein Anmeldedatum geben, Punkte geben, Note geben.
Und das ist im Prinzip das,
was wir hier an Daten erstmal als Attribute definieren.
Und dann sage ich hier bei der Verwaltung, Student soll
sich registrieren können. Also wenn er sich registriert,
gibt es ihn ja noch gar nicht.
Und deswegen wird sozusagen dieses Studentobjekt
da erst erzeugt
Oder erstmal ein Studentobjekt mitgegeben, wo die Daten drinstehen zu dem Studenten
und der muss dann registriert werden. Das machen wir zentral,
also das sollte man nicht beim Studenten machen,
weil der Student existiert ja noch nicht bei der Registrierung,
dementsprechend haben wir das hier in die Verwaltung reingemacht.
Und das Login genauso,
da soll Username und Passwort hier meinetwegen übergeben werden und dann
wird das überprüft und dann wird meinetwegen Studentobjekt in dem System gespeichert,
welcher dann authentifiziert ist und dann die Funktionalitäten aufrufen kann.
So kann man das abbilden, man kann es auch anders machen,
aber nur so als Idee, dass ich eben sage,
wir brauchen so eine Verwaltungsklasse
Beim Studenten selber sage ich,
der kann sich zu einer Vorlesung anmelden oder abmelden.
Dazu muss er dann eben immer sagen, welche Vorlesung es ist.
Es muss als Parameter mit übergeben werden. Student ist klar
, aber dann eben für die Vorlesung. Und er kann
den Lockout-out initiieren. Ist halt anders als beim Block-in,
beim Lockout ist er ja vorhanden und dann kann er ihn auch initiieren.
Das Anmelden und Abmelden hätte ich auch in die Vorlesung reinpacken können.
Dann hätte ich sagen müssen, okay,
bei der Vorlesung meldet sich ein Student an oder ab.
Ich brauche das aber ehrlich gesagt nur einmal.
Ich brauche das nicht
in beide reinzuprogrammieren
Das machen wir nämlich, dass wir beide Seiten praktisch hier haben,
bringen wir gleich anders ab. Und bei Vorlesungen habe ich
jetzt hier auch noch irgendwie irgendeine Teilnehmerliste, soll zurückgegeben werden.
Oder ein Datenexport bei der Teilnehmerliste, sage ich,
da sollen die Teilnehmer als Text, als Stwing zurückgegeben werden.
Und dann habe ich hier angegeben, Doppelpunkt Stwing. Und dieses Stern bedeutet,
dass eben mehrere Elemente zurückgegeben werden, also auch eine Liste.
Gut, dann definieren wir hier Assoziationen. Wir sagen,
der Student kann beliebig viele Teilnahmen haben und wir können das hier auch mal machen.
Und die Vorlesung kann auch die wie viele Teilnahmen haben.
Das heißt eben, der Student kann sich zu mehreren Vorlesungen
praktisch anmelden. Also beliebig viele Teilnahmen haben,
die sich jeweils auf eine Vorlesung beziehen, hier die Eins.
Und die Vorlesung kann eben beliebig viele Teilnahmen haben,
die sich jeweils auf ein Studentobjekt beziehen.
Damit können wir halt eben alles abbilden. Wir haben halt eben diese Klasse,
die Beziehung, dass sie einen Student zu einer Vorlesung anmeldet,
haben wir oder an einer Vorlesung teilnimmt,
haben wir halt eben hier in dieser Teilnahmeklasse
dann abgebildet
Und da haben wir eben diese Einzel-Stern-Beziehungen jeweils,
weil wir aus der Teilnahme heraus eindeutig wissen wollen,
welcher Student nimmt an welcher Vorlesung teil.
Also eindeutig den Studentobjekt und eindeutig das Vorlesungsobjekt definieren,
weil nur für den können wir dann auch die Punkte und die Note speichern.
Die Punkte und die Note können wir nicht beim Studenten speichern,
dann würden die ja für alle Vorlesungen gelten.
Oder ich kann sie auch nicht bei der Vorlesung speichern,
dann würden sie ja alle für alle Studenten gelten.
Also dementsprechend kommt das hier in diese Mittelklasse rein,
die nennen wir später auch Assoziationsklasse,
weil wir eben hier eigentlich eine Assoziation zwischen Student und Vorlesung
haben wollen
Also die Beziehung besteht zwischen den beiden,
aber die Daten zu dieser Assoziation müssen wir eben separat speichern.
Das speichern wir separat in der Klasse. Und dementsprechend nennen
wir das dann hier Assoziationsklasse. Dann sagen wir noch,
diese Verwaltung soll eben alle Studentobjekte mit integrieren,
soll sozusagen eine Liste auch von allen Studenten haben und natürlich auch von allen Vorlesungen.
Deswegen sagen wir hier auch dieses Stern. Ich gebe hier immer
die Rückrichtung an. Hier war es ja auch sinnvoll,
wie habe ich ja gesagt, brauchen wir.
Hier sagen wir, okay,
es gibt wahrscheinlich nur ein Objekt dieser Klasseverwaltung,
weil das ist sozusagen der Ausgangspunkt von allem
Und dann würden wir eben sagen, okay,
hier gibt es eben ein Objekt, auf das zugegriffen wird,
können wir hier die Eins reinschreiben.
Oder halt auch weglassen. Muss man immer gucken,
was das bedeutet, wenn wir eine Assoziation in beiden Seiten lesen,
dann speichern wir sozusagen beim Student die Teilnahmeobjekte nachher ab.
Und bei der Teilnahme auch das Studentobjekt. Das Gleiche mit
der Vorlesung. Das bedeutet, wir lesen die Assoziation in beide Richtungen.
Das bedeutet eben, dass wir die Informationen redundant speichern.
Theoretisch würde es reichen, wenn wir sagen,
wir haben alle Teilnahmeobjekte
Dann könnte man eben ja zurückschließen, welcher Student bei welcher Vorlesung teilnimmt.
Aber das wäre zu aufwendig und deswegen sagen wir hier,
macht das nur Sinn, die auch wirklich in beide Richtungen zu lesen.
Hier umgekehrt, ob wir aus dem Studenten heraus auf die Verwaltung zugreifen müssen,
ist fraglich, da mussten wir vielleicht die Rückrichtung nicht wirklich benutzen.
Gut, dann werde ich zum Abschluss noch
die Aggregation kurz erklären und auch dann nochmal die Komposition,
die Aggregation ist halt eben diese Verstärkende, besteht Ausbeziehung.
Das hat jetzt keinen inhaltlichen Mehrwert. Wir sagen
eine Artikelgruppe besteht aus mehreren Artikeln. Wir sagen,
die Artikelgruppe hat mindestens einen Artikel oder beliebig viele.
Einen Artikel bezieht sich immer auf eine Artikelgruppe, sagen wir hier.
Wenn wir das sagen, dann kann es keine,
also dann sind die Artikelgruppen des Jugend, dann kann es
keine Artikel geben, die in verschiedenen Artikelgruppen drin sind.
Wenn wir zum Beispiel sagen,
wir haben eine Artikelgruppe Drucker und wir haben eine Artikelgruppe Scanner,
dann wäre ja vielleicht ein Faxscanner in beiden drin
Das könnten wir dann nicht abbilden. Also bei Narz Aggregation
dürfte hier aber auch ein Stern stehen und vielleicht würde man
hier auch eher einen Stern machen, wenn man sagt,
die hat hier Gruppen, sollen nicht es jung sein.
Trotzdem würden wir sagen, die Artikelgruppe besteht aus Artikeln und
umgekehrt sicherlich nicht. Der Artikel besteht nicht aus Artikelgruppen,
selbst wenn er in mehreren Artikelgruppen drin sein kann.
Also das ist so die Aggregation, hat aber sonst keine Auswirkungen.
Und dann eben diese Komposition, hier habe ich nochmal das Rechnungsbeispiel,
dass ich sage, das ist diese existenzielle Abhängigkeit.
Wir können sagen, okay, die Rechnung referenziert eben Rechnung,
Positionsobjekte, die hier definiert werden, die hier erzeugt werden,
aus der Rechnungsposition heraus, kann ich eben die Rechnung nicht referenzieren.
Und es bedeutet auch, dass die Rechnungsposition von keinem anderen Objekt
heraus angesprochen wird. Weil wenn ich jetzt eben existenzielle Abhängigkeit
definiere und die Rechnung zerstöre und damit alle Rechnungspositionsobjekte zerstöre,
dürfen natürlich keine anderen Objekte davon betroffen sein.
Und deswegen hat das schon eine technische Auswirkung.
Aber da wir hier das nicht programmieren,
ist das für uns
auch nicht
so wichtig
Und dann will ich noch mal die Assoziationsklassen hier zeigen.
Wir hatten das ja im Prinzip eben schon gehabt.
Wir hatten gesagt, die Vorlesung und der Student sind miteinander verbunden.
Ich hatte die Assoziation da nicht gemalt.
Ich habe sie jetzt hier mal hingemalt und gesagt,
okay, die Vorlesung hat verschiedene Teilnehmerliste mit verschiedenen Studentobjekten.
Und der Student hat eben seine Vorlesung praktisch hier die
verschiedenen Daten dazu. So, und diese Assoziation,
dazu brauchen wir eben
verschiedene weiterführende Daten
Sagen wir hier, okay,
wir machen diese Assoziationsklasse und verknüpfen die hier mit 1 zu Stern,
die an der Stelle ist das die 1 nach oben gerutscht.
Also hier ist die 1 und hier das Stern und genau das Gleiche,
was da vorhin aufstand. Und wir haben halt eben diese zusätzlich aufgemacht,
das ist auch redundant, das brauchen wir ja nicht,
weil ja die hier rüber verknüpft sind,
brauchen wir diese direkte Beziehung eigentlich nicht zu definieren.
Egal wie, man könnte es auch anders modellieren,
man kann es auch anders malen,
dass man diese Assoziation zwischen Student und Vorlesung definiert und dann
einfach mit einer gestrichelten Linie auf diese Assoziation diese Klasse dann
setzt und dann versteht man vielleicht den Namen Assoziationsklasse auch besser,
weil das ist sozusagen die Klasse, die sich auf diese Assoziation bezieht.
Aber inhaltlich oder von der Sache her, sind diese beiden Darstellungen praktisch dieselben.
Also die drücken das selber aus und dementsprechend könnte man
eingehen in der Modellierung auch mit einer Variante auskommen,
also ohne diese gestrichelte Linie.
Aber es gibt sie nun mal und deswegen wollte ich sie
jetzt auch nicht verheimlichen.
Okay, nächstes Mal machen wir dann mit der Vererbung
weiter und das war es dann für diese Woche