Modellorientierung in informatische Modelle Die Modellorientierung beziehungsweise das informatische Modellieren ist in der Informatik sehr prominent und taucht in den unterschiedlichsten Anwendungsformen auf.  Nachfolgend werden ohne Anspruch auf Vollständigkeit einige informatische Modelle wiederholen vorgestellt, die unter anderem von Peter Hupwieser für den Informatikunterricht benannt wurden. Es sei dazu angemerkt, dass Professor Hupwieser bis 2021 Professor an der TU München war.  Das heißt, das meiste, was er vorgestellt und publiziert hat, bezieht sich primär auf den Informatikunterricht in Bayern.  Der unterscheidet sich dann gegebenenfalls zu anderen Bundesländern. Er tut das jedenfalls zu Nordrhein-Westfalen. Alles was er formuliert hat, gilt so zunächst primär für Bayern. Dort wurde es auch umgesetzt, wenngleich er natürlich allgemeingültige Aussagen zur Sinnhaftigkeit seiner Vorschläge getätigt hat.  Eine Diagrammart, die er vorschlägt, sind die Datenstruktur-Diagramme.  Wie Sie sehen haben diese Diagrammformen ziemlich Ähnlichkeit mit Entity-Relationship-Diagrammen, denn sie repräsentieren einen statischen Eindruck des Systems.  Buchtitel beispielsweise haben hier verschiedene Attribute, die einen jeweiligen Datentypen haben und die Hauptbestandteile dieser Diagrammart sind die Sequenz der Verbund und der Varianteverbund. Die Datensstruktur-Diagramme dienen dazu, sich einen groben, datenorientierten Überblick  über die statische Struktur eines Systems zu beschaffen und sind insbesondere gut dazu  zu verstehen, dass auch Diagrammtypen, wenngleich Programmiersprachen unabhängig, immer in einem gewissen zeitlichen Kontext einzuordnen sind.  Zu Zeiten prozedural-imperativer Programmierung mag dieser Diagrammtyp aktueller gewesen sein,  als das heute bei dem objektorientierten Paradigma der Fall ist, aber alles Alte wird  irgendwann wieder neu. Vergessen Sie also nicht, wenn Sie Diagrammtypen studieren und deren Einordnung beispielsweise in einem didaktisch-schulischen Kontext immer auch die zeitliche Umgebung dieser Aussagen mit ins Kalkül zu ziehen und zu bedenken.  Die Entity-Relationship-Diagramme im Bereich der Datenbanken finden Sie praktisch in allen Bundesländern, in allen Lehrplänen wieder, in Bayern wie in Nordrhein-Westfalen.  Und Sie gehören zu den am häufigsten in Informatikvorlesungen genannten Informatischen Modellen.  Sie besitzen eine große Schnittmenge mit Modelltypen der objektorientierten Programmierung. Das hat dann in Schule zur Folge, dass, wenn Sie die objektorientierte Programmierung schon unterrichtet haben,  können Sie die Entity-Relationship-Diagramme aus dem Datenbankbereich erfahrungsgemäß recht zügig behandeln.  Es geht da mehr um Notationsformen, wie schreibt man was auf.  Aber die grundsätzliche Denkweise, die ist schon bekannt.  Was man anhand der Datenbanken und der dortigen Entity-Relationship-Diagramme besonders gut sehen kann,  ist, dass die Datenbanken, die man anhand der Datenbanken und der Datenbanken-Diagramme sehen kann,  dass die Datenbanken, die man anhand der Datenbanken sehen kann,  dass die Datenbanken, die man anhand der Datenbanken sehen kann,  dass die Datenbanken, die man anhand der Datenbanken sehen kann,  dass die Datenbanken, die man anhand der Datenbanken sehen kann,  dass die Datenbanken, die man anhand der Datenbanken sehen kann,  dass die Datenbanken, die man anhand der Datenbanken sehen kann, der Problem-Löse-Prozess. Wie kommt man vom Problem zur informatischen Lösung? Wie kommt man vom Problem zur informatischen Lösung?  Warum eignen sich da Datenbanken besonders gut? Warum eignen sich da Datenbanken besonders gut?  Weil aufgrund der Sache heraus, sie zunächst vom Problem ausgehend eine Entscheidung treffen müssen, Weil aufgrund der Sache heraus, sie zunächst vom Problem ausgehend eine Entscheidung treffen müssen,  wie sie das Problem informatisch angehen, in dem Fall per Datenbank, wie sie das Problem informatisch angehen, in dem Fall per Datenbank,  und dann ist dem Lernenden direkt klar, dass man nicht einfach los tippen kann, sondern zunächst mal ein Modell braucht, und dann ist dem Lernenden direkt klar, dass man nicht einfach los tippen kann,  und dann ist dem Lernenden direkt klar, dass man nicht einfach los tippen kann, und dann ist dem Lernenden direkt klar, dass man nicht einfach los tippen kann,  und dann ist dem Lernenden direkt klar, dass man nicht einfach los tippen kann, und dann ist dem Lernenden direkt klar, dass man nicht einfach los tippen kann, er diagram formuliert damit das allgemein lesbar ist bedarf es einer gewissen konvention was die notation angeht und dann stellt sich die frage wenn das er diagram welches der objekt orientierten modellierung sehr ähnlich ist wenn das vorhanden ist wie kommt man zur implementierung da ist dann das problem dass beispielsweise n zu m relation nicht direkt relational abbildbar sind das heißt es muss eine ein weiteres modell in einer geeigneteren für die implementation geeigneteren form aus dem vorhergehenden modell in dem fall dem diagram erstellt werden das dann gegebenenfalls noch mal normalisiert werden muss und dann erst implementiert wird das heißt die  modell und dann erstellt werden  das heißt die modell und dann erstellt werden muss und dann erstellt werden muss und dann erstellt werden muss und dann erstellt werden muss und dann erstellt werden muss und dann erstellt werden muss und dann erstellt werden muss. Bildung von modellketten und die modelltransformation kann hier erfahren werden ohne dass es künstlich eingeführt werden muss und da modellketten sowie modelltransformation neben der vielfalt an modellen eine für die informatik typische ausprägungsform für modellbildung allgemein darstellt  modelltransformation neben der vielfalt an modelltransformation neben der vielfalt an modelltransformation  neben der vielfalt an modelltransformation haben sie hier auch eine hohe repräsentativität des komplexes modellbildung als auch einen schönen bezug zur abstrakten allgemeinen modelltheorien  dort wenn sie sich erinnern in allgemeinen modelltheorien gibt es vermittlungsphänomene prätterition, kontrastierung, transkodierung, abundanz beispielsweise in der allgemeinen  modelltheorie die zwischen originale und modell stattfinden und all das finden  sie auf ganz natürliche weise in der anwendung wieder wenn sie sich mit  datenbanken beschäftigen vom problem wird die entscheidung getroffen an der  datenbank zur problemlösung zu verwenden da wird das er diagramm  genutzt anschließend als zweite komponente der kette und der transformationen kommen sie zum relationalen modell welches als dritte komponente der kette die normalisierten formen  zur folge hat die dann implementiert werden  vielleicht deswegen finden sie er diagramme in wohl allen leerplänen an Schule wieder und Peter Hupfwieser hat diese Diagrammart dann auch aus gutem Grund empfohlen.  Der Klassiker für zustandsorientierte Modellierung ist das Zustandsübergangsdiagramm, der Automat aus der theoretischen Informatik.  Dort haben sie es mit ganz intuitiven Elementen zu tun. Die einzelnen Zustände werden durch Kreise visualisiert.  Null bis beliebig viele Endzustände durch Doppelkreise und ein, genau ein Startzustand durch einen entsprechenden Startpfeil.  Die Zustandsübergänge werden beschriftet, damit man weiß, durch welche Eingabe, als Element des Eingabealphabets, man von Zustand zu Zustand wechseln kann.  Das einfachste Modell ist der Lichtschalter mit seinen zwei Zuständen ein und aus.  Und so. Den Zustandsübergang visualisiert hier durch Pfeile. Das ganze ist ein dynamischer  Vorgang. Immer wenn es darum geht, dynamische Vorgänge zu visualisieren,  also modelltechnisch zu erfassen, ist ein automat ein mögliches Instrument dafür.  In der theoretischen Informatik, in einigen Bundesländern, machen sie das  ansatzweise im Leistungskurs zumindest. ist die Entwicklung von Compilern und den Untermengen, also  PASA, Scanner, Lexa und diese ganzen Elemente.  Auch dort finden Sie das Modell des Automaten wieder.  In Nordrhein-Westfalen ist das Automaten-Modell dem Bereich Automaten und  formale Sprachen  zugeteilt.  Aber aufgrund seiner hohen Repräsentativität findet sich das  in so gut wie allen Lehrplänen in irgendeiner Form wieder.  Bei der funktionalen Modellierung mit Hilfe von Datenflussdiagrammen, die Sie hier sehen,  werden komplexe Systeme abgebildet.  Ohne auf die Details der Abbildung einzugehen,  ist es eine der Stärken dieses Diagrammtyps. Dass man verschiedene Abfraktionsniveaus hat und die Hauptbestandteile des Gesamtsystems miteinander kommunizieren lässt und erst mal als solche erfasst.  Im Beispiel ist hier eine Online-Bank abgebildet und wie Sie sehen, sind hier die Hauptbestandteile in den Kreisen erfasst.  Es gibt eine Web-Server-Komponente und mit dem ... ... Anwender, interagierender User, einen Browser-Komponente, dann gibt es einen Anwendungsserver,...  ... eine Einheit, die sich um die Kommunikation kümmert und eine, die, sagen wir mal,...  ... Probleme verhindert, was die User und die Interaktion mit dem System angeht.  Das ist also eine ganz abstrakte Sichtweise auf ein System,... ... und ist besonders hilfreich bei komplexen Systemen, wo man schnell den Wald vor lauter Bäumen nicht mehr sieht.  Da bieten sich Datenflussdiagramme an.  Neben dem Entwurfsdiagramm und dem Implementationsdiagramm sowie dem Klassendiagramm,...  ... sind sicherlich die Objektdiagramme Klassiker im modernen Informatikunterricht,... basierend auf der Tatsache oder resultierend auf der Tatsache, dass momentan die objektorientierte Programmierung an Schulen gelehrt wird.  Entsprechend müssen Objekte auch irgendwie darstellen können und das passiert mit einem Objektdiagramm.  Von Bundesland zu Bundesland gibt es auch da kleine Unterschiede, was die Notation angeht. Grundsätzlich aber haben sie die drei Bestandteile, Klassenname, Attribute und Methoden und dann werden die in Form des Objektdiagramms visualisiert.  Upfisa schlägt noch ein recht ungewöhnliches Diagramm-Exemplar vor und zwar das Objektklasse-Diagramm. Was ist da ungewöhnlich dran? Nun, es vermischt die Klassen mit Objekten innerhalb eines Diagramms und das ist recht ungewöhnlich.  Sie sehen hier in den Kästen die jeweiligen Klassen und im unteren Bereich in den abgerundeten Ecken sehen sie die Objekte. Das heißt, man hat sowohl die zugrunde liegenden Klassen als auch deren Ausprägung in Objektform in einem einzigen Diagrammtyp vereint.  Sie sehen auch, dass hier differenziert wird, welcher Art die Verbindungen sind.  Es gibt die Enthältverbindungen, es gibt die Instanziiertverbindungen. Und die Vererbung ist abgeleitet von. Das ist eine andere Art an Modellierung  heranzugehen mit dem Ziel Klassen und Objekte in einem Diagramm sichtbar zu  halten. Ob das Ziel jetzt sinnvoll ist oder ob gerade die die Trennung der  beiden Ebenen zwischen Klasse und Objekt in verschiedenen Diagrammen jetzt sinnvoller ist.  Das überlasse ich Ihrem eigenen nachdenken.  Hubwieser jedenfalls meint das Objekt-Klasse-Diagramm wäre sinnvoll.  Eine weitere Diagrammform ist das Interaktions- oder das Sequenzdiagramm. Das findet beispielsweise bei der Definition von Protokollenanwendung, da geht es ja darum, ganz genau festzulegen, wer, wann, wem, was sagt.  Ein weiteres Beispiel für den Einsatzbereich von solchen Diagrammen ist der Zugriff auf gemeinsame Ressourcen.  Das geht nicht zu jeder Zeit von jedem beliebig, sondern es muss gewisse Synchronisationskonzepte dafür geben.  Vielen Dank. Denken Sie beispielsweise an einen Netzwerkdrucker.  Ein Job muss zunächst mal abgearbeitet werden, bevor Platz für den nächsten ist.  Sie können nicht beides irgendwie wild mischen, das funktioniert nicht.  Und eine Möglichkeit, das in Diagrammform zu pressen, ist das Interaktions- und Sequenzdiagramm und wird deswegen auch vorgeschlagen.  Jetzt haben wir schon eine ganze Menge an ... Modelltypen wiederholt und das ist ja auch nur ein Ausschnitt. Da stellt sich dann die Frage, wie kann man sich a) die verschiedenen Diagrammtypen merken und b) wie kann man die einordnen.  Diese Einordnung hilft ja oftmals auch dem eigenen Denken über. Das Denken über Probleme, in dem Fall das Denken über die verschiedenen Diagrammtypen und ihre Einsatzzwecke. Gerade auch für den Allgemeinbildendenbereich, den sie dann an Schulen vorfinden.  Und da bieten sich solche Klassifizierungs- und Kategorisierungs-Schemata an.  Als Gedächtnisstütze, als Hilfe für das eigene Denken.  Dies, ein Vorschlag von Hubwieser und Breu ist recht bekannt und in Form einer Tabelle hier ausschnittsweise abgebildet. Da wurde eben genau dieser Versuch unternommen. Es wurden Klassen gebildet mit  verschiedener Schwerpunktsetzung und dann nach einem gewissen  Kategorisierungsschema dort Zielsetzung und Diagrammtyp jeweils eingetragen.  Solche Klassifizierungs- und Kategorisierungsschema da sind nicht  pragmatisch zu verstehen. Also so ist es jetzt und alles andere ist falsch. Was sind das? Das sind einfach Vorschläge, diese Vielfalt an etwas, in dem Fall von Diagrammtypen, mal zu ordnen und der Menge herzuwerden.  So sollten sie diese Tabellen und Strukturierungshilfen deuten.  Wie ist jetzt der? Ansatz von Hubwieser zu sehen. Also zunächst einmal muss gesagt werden,  dass Hubwiesers Überlegungen tatsächlich schulpraktische Auswirkungen in Bayern  gehabt haben. Also viele seiner Ideen sind auch tatsächlich umgesetzt worden.  Er hat also als einer der wohl eher wenigen Didaktikvertreter Auswirkungen auf die Schulpraxis gehabt. Sein Ansatz betonte Modellierung in hohem  Maße und er meinte, dass wenig bis teilweise gar keine Implementierung  dieser Modelle notwendig sei. Das ist eine Grundaussage seines Ansatzes und  gleichzeitig auch Quelle diverser Probleme. Wer sich für die Details  interessiert Es gibt verschiedene Publikationen natürlich von Hubwieser, aber auch deren Umsetzung in die Schulpraxis in Form von verschiedenen Schulbüchern.  Professor Hubwieser hat auch ein bekanntes Didaktik-Lehrbuch geschrieben. Didaktik der Informatik beim Springer Verlag.  Welche Probleme gab es mit seinem Ansatz?  Nun ja, zunächst die Modellierung ist so einfach jetzt nicht zu erlernen. Vom Gegenstandsbereich, der dazu modellieren ist und vom Problem nicht viel Ahnung hat und nicht programmieren kann.  Zwar muss man für ein Modell nicht programmieren, aber Sie wissen aus eigener Erfahrung,  dass diese Ebenen der Modellierung und der Implementierung schon eine gewisse Wechselwirkung zueinander haben.  Und wenn jemand noch nie programmiert hat, sprich mit der informatischen Denkweise gar nicht vertraut ist,  dann hat er auch... große Probleme, sinnvolle Modelle zu erstellen. Ferner sind Modelle immer auch so ein bisschen Ansichtssache. Es gibt da nicht ein hartes richtig und falsch, was der Überprüfbarkeit und damit indirekt auch der Lernbarkeit doch sehr abträglich ist. Denn wenn sie kaum eine Aussage bekommen können, ob ist denn mein Modell jetzt richtig, ja oder nein,  ja oder nein. Sondern das immer so im Graubereich, ja es könnte richtig sein, aber der und der Problemfall liegt vor, dann haben sie da gerade als Anfänger schon ein Problem und sie können sich kaum selber überprüfen.  Ferner stellt sich natürlich die Frage, ob durch einen weitgehenden oder vollständigen Verzicht auf Implementierung denn ein sinnvoll abgerundetes Bild auf die Informatik geboten wird. Wenn Sie sich also für die Details von Ubwesers Überlegungen interessieren,  konsultieren Sie seine Lehrbücher und Publikationen. Wesentliche Diagrammtypen  aus der Sichtweise der Modellorientierung wurden Ihnen nun vorgestellt.