Herzlich willkommen zur letzten Etappe in unserer Vorlesung Konzeptionelle Modellierung.

Sie sehen vielleicht, ich habe schon wieder ein Verband, der Herr Neumann hat nicht gelogen.

Ich war wirklich am Fuß verletzt, jetzt habe ich schon wieder die nächste Verletzung.

Ich soll mich nicht davon abhalten, hier die letzte Vorlesung noch abzuhalten.

Also wir waren stehen geblieben im Kapitel UML, das hat der Herr Neumann letzte Woche abgeschlossen.

Sie haben das auch in den Übungen gemacht. Das ist natürlich ein sehr breites Kapitel,

und das können wir nur sehr punktuell hier behandeln.

Trotzdem ein paar Worte hier zur Zusammenfassung noch.

Beim letzten Mal hat der Herr Neumann noch das wichtige Kapitel UML Klassendiagramme mit Ihnen behandelt.

Da haben Sie natürlich festgestellt, da gibt es wahnsinnig viele Parallelen zu dem,

was wir hier behandelt haben mit unseren ER Diagrammen.

Das hat natürlich seinen guten Grund, die UML Klassendiagramme, die haben schließlich ihre Wurzeln

in der ER Modellierung.

Das, was letztlich mit UML Klassen modelliert wird, das kennt man auch schon nicht nur aus objektorientierten Programmiersprachen,

sondern auch bereits aus prozeduralen Programmiersprachen, das hat man da abstrakte Datentypen genannt.

Also anstatt nur Datentypen zu definieren, definiert man bei abstrakten Datentypen,

welche Strukturen haben meine Daten plus welche Operationen sind auf diesen Daten zulässig.

Und genau das macht man, wenn man UML Klassendiagramme erstellt.

Das macht im Prinzip genau das gleiche, wie wenn ich ein ER Diagramm beschreibe.

Ich beschreibe, welche Entities haben wir das genannt in unserer ER Terminologie,

welche Objekte letztlich möchte ich beschreiben, über welche Attribute beschreibe ich die.

Und dazu, welche Operationen kann ich auf diesen Objekten anwenden.

In der objektorientierten Terminologie heißt das Methoden, aber letztlich ist das nichts anderes als die Spezifikation eines zulässigen Verhaltens.

Das möchte ich jetzt nicht in großem Detail wiederholen, es gibt eine ganze Reihe von weiteren Diagrammarten,

die hier noch aufgeführt sind, die wir nicht im Detail behandeln.

Da möchte ich nur einen Punkt rausgreifen, nämlich diese Komponentendiagramme.

Komponenten sind erst einmal etwas anderes als Klassen.

Ich kann eine Software erstellen und meine Software besteht typischerweise aus vielen Klassen.

Und die Objekte dieser Klasse interagieren, um gemeinsam eine Funktionalität bereit zu stellen, zu realisieren.

Komponenten, anders als Klassen, sind eigenständige Einheiten der Installation.

Ich muss eine Komponente für sich allein installieren können und die ist dann lauffähig.

Das ist etwas anderes als eine Klasse.

Dafür gibt es einen eigenen Diagrammtyp.

Es gibt noch weitere Diagrammtypen, die wir hier nicht aufgeführt haben,

aber entscheidend sind die Klassendiagramme, da haben wir eine ganze Reihe von Parallelen entdeckt zu unseren ER-Diagrammen.

Das wiederholen wir nicht, hier alles im Detail.

Das haben wir ausführlich mit Herrn Neumann besprochen.

Was wir kurz noch einmal wiederholen wollen, ist die Geschichte mit der Metamodellierung.

Warum machen wir das denn eigentlich mit der Metamodellierung?

Metamodelle sind sozusagen Modelle über Modelle.

Dabei handelt es sich um eine linguistische Abstraktion.

Ich schreibe auf der Metaebene die Sprache, die ich verwende, um meine Modelle zu erstellen.

Warum mache ich das? Aus verschiedenen Gründen.

Einmal, um meine Sprache auf konsistente Art und Weise erweitern zu können.

Eine Zielsetzung.

Eine Zielsetzung ist, die Beschreibungsdaten, die letztlich meine Modelle darstellen,

solche Beschreibungen portierbar zu machen, austauschbar zu machen,

indem ich die Modellelemente, die ich dafür verwende, in eine definierte Semantik reinpacke,

indem ich die interpretierbar mache sozusagen.

Das als wesentliche Vorbedingung.