Als nächstes möchte ich mich mit Ihnen darüber damit beschäftigen,
wie wir nun genau die Semantik eines Computerprogramms beschreiben können,
wie kann so eine Formale Beschreibung aussehen und wie schon angekündigt,
dass es soll ein bisschen eine Brücke sein,
eine Motivation sein, warum es sinnvoll ist,
wichtig ist, dass Sie als Informatiker diese Techniken kennen.
Sie landen nicht bei uns, wir weisen schnell die drei Sachen
jetzt nur vor, Sie lernen die bei theoretischer Informatik.
Zunächst, wir behandeln drei Ansätze und fangen an mit
der DNA zu, Sorry, die notationalen Semantik.
Ja, und das ist ein Weg, das Verhalten,
die Veränderung, die ein Programm vornimmt,
zu betrachten anhand der Änderungen, die es im Speicher gibt.
Ja, also wir betrachten die Wirkungsweise des Programmes als Änderung
von Speicherzuständen. Und deswegen betrachten wir das so,
dass wir die Menge aller möglichen Speicherzustände,
dass also die Inhalte von Speicherzellen oder die Inhalte von Variablen,
dass wir die betrachten, was haben die Anweisungen für Wirkungen darauf.
Also wir gehen über von der Menge der Anweisungen vor einem Schritt,
bis der Speicherzustände vor einem Schritt zur Menge der Speicherzustände nach einem Schritt,
also die Variablenbelegung vorher, Variablenbelegung nachher.
Und das als Ergebnis einer Funktion. Ja,
ich habe irgendwie zum Beispiel, wir addieren etwas.
Dann gibt es vorher ein Feld mit zum Beispiel dem Wert.
Drei und danach hat das Wert das Feld den Wert fünf.
Ja, und das Ganze ist das Ergebnis einer Addition,
um die wir um die Höhe zwei. Ja,
also wir ordnen sozusagen eine Zuordnung, das sieht strukturell,
sieht das so aus, dass wir Funktion,
eine Zuordnung zwischen Vorzustand im Folgezustand hat, hier Z und Z-Strich.
Ja, und die Semantik definiert dann diese Funktion,
die das tut. Das ist eine Möglichkeit,
wir kümmern uns jetzt nicht darum, wir hatten vorher gesagt,
ja, das Ganze ist unabhängig von der Programmiersprache.
Wir kümmern uns jetzt gar nicht darum, wie das gemacht wird.
Ja, zum Beispiel, wir addieren hier,
dann wird auch wieder Übertrag behandelt.
Da wird was geprüft, ob wir einen Überlauf haben oder so.
All das wird hier überhaupt nicht beschrieben oder wir sortieren etwas.
Wie geht denn dieses Sortieren? Das wird hier nicht beschrieben,
sondern nur, was bis vorher,
was ist nach
Damit haben wir hinreichend vereinfacht, um das Programmiersprach unabhängig zu beschreiten.
Das ist der erste Einsatz, den mutationale Semantik.
Beginnt gleich über zum zweiten Ansatz, die Operationale Semantik,
operational, da steht Operation drin, ja,
und dabei beschreiben wir, was ein Programm tut.
Dieses, was ein Programm tut, hängt immer damit zu
sagen, wie wird denn das getan? Das heißt,
die Maschine, die das tut, spielt dabei eine Rolle.
Also wenn wir wieder Addition machen würden, ja,
dann ist es sehr entscheidend, im Zehner-System oder im Binärsystem,
diese Additionentürchen, weil der Übertrag jedes Mal anders funktioniert.
Und was es uns hilft, was dieses dem Semantik dann leisten kann,
sie kann das Verhalten des Programms beschreiben und damit auch sagen,
ob ein anderes Programm das Gleiche tut und damit, dann möglicht es uns,
das Programm, ein Programm durch ein anderes zu ersetzen.
Damit wir das können, beziehen wir uns bei dieser Maschine,
die die Operationen liefert, auf deren Basis wir das beschreiben,
beziehen wir uns auf eine Erdachte,
auf eine abstrakte Maschine
Und diese abstrakte Maschine, die hat ein paar Sets von Grundoperationen,
aus denen müssen wir den Biooperationen zusammensetzen, die wir tatsächlich machen.
Und das ist diese Spezifikation. Wir sagen, welche Operationen werden
denn jetzt hier ausgeführt mit den Mitteln, diese einfache Maschine zu machen.
Also für diejenigen von Ihnen, die binär Berechnung,
binäre Additionen kennen, ja, die können sich vorstellen,
okay, ich beschreibe jetzt, was passiert mit diesen Bits,
mit Übertrag und addieren und die logischen Regeln und,
und, oder.
Damit kann ich also beschreiben, was eine Addition tut.
Ich kann damit auch beschreiben,
was ein Wurzel ziehen tut,
das ist
nur ein bisschen aufwendiger
Und ich kann damit auch beschreiben, wie Ernährungsverfahren funktioniert,
was ein Sinuswert berechnet. Das ist dann nochmal ein bisschen aufwendiger.
Aber ich kann es immer auf diesen Operationen dieser erdachten,
dieser abstrakten Maschine tun. Und dann brauche ich nur noch eine Übersetzung,
eine Umabbildung von dieser abstrakten Maschine auf meinen wirklichen Prozessor,
der etwas tut.
Und schon kann ich Programme generieren. Super, so einfach ist das.
Also, was ich habe, ist alter Zustand.
Neuer Zustand und eine Anweisungsfolge. Also, wir haben etwas,
was vor der Anweisung passiert,
vor der Ausführung
eine Anweisung
Meinen alten Zustand, zum Beispiel JZ, ja,
und dann tun wir etwas,
wenn mir der alte Zustand mit I1-Einheit zu tun hat,
dann ist der zweite Zustand die 1,
der Zustand von ihm 2 plus 1, also danach.
Ja, so, und damit haben wir auch welche Anweisungen verfolgt. Ich habe hier mal einen,
einen Link gebracht zu einem Lehrstuhl aus Stuttgart,
die das ein bisschen in einem Skript erklären,
aber ich bin sicher,
dass sie haben bei der theoretischen Informatik Ausbildung in unserer Inversität
auch solche Materialien,
die ich gerade hier nicht zur Verfügung hatte
So, das war der zweite Weg. Ja,
wir haben ja eine Frage, die sich darauf bezieht,
das war dir die Frage 3,
auf welche Weise beschreiben diese drei Arten die Semantik eines Programmes.
Ja, und wir finden jetzt schon Sachen,
die dazu genotational, aufgrund des Speicherzustands vorher und nachher,
operational aufgrund der Operationen einer abstrakten Maschine,
die das eben ausführt und was ist axyomatische ist,
das schauen wir uns jetzt gleich an.
Ja, das steht ja auf der nächsten Folie,
der hat dritte Ansatz,
die axymatische Semantik
Aktion ist eine Regel, eine Beziehung zwischen Vor- und Nachbedingungen,
vorher, nachher, die wir verwenden können.
Und das ist das, was praktisch bisher die größte Rolle spielt,
was am häufigsten eingesetzt wird. Und das ist etwas,
was wir auch gleich noch bei den abstrakten Datentypen handeln.
Und wissen wir auch, was man mit UCL darstellen kann.
Was es tatsächlich in den meisten ÖML-Werkzeugen wirklich auf den einzelnen Arbeitsplätzen auch gibt.
Man muss es nur benutzen. Wir legen bei der Axiomatischen Semantik,
legen wir die Regeln fest zwischen den Vorbedingungen und den Nachbedingungen,
also zwischen dem Vorher und dem Nachher
Sie werden sagen, oh, das haben wir doch
bei denen der Zintelzentren, denen multational auch schon gemacht.
Ja, da haben wir es aber für die Speicherzustände gemacht.
Und hier machen wir es für Bezüge zwischen Bedingung. Ja,
also wir betrachten die Veränderung dieser Variablen,
die wir dabei haben und formulieren diese Vor- und Nachbedingungen für
die einzelnen Elemente unserer Spezifikation, für die einzelnen fachlichen Sachen.
Und damit drücken wir die Semantik aus. Ja,
und wenn wir das anwenden, können wir das auch,
diese Sequenz verschritten, die könnten wir auch nutzen,
um einen Beweis zu führen
Es gibt dazu ein Beispiel, wie wenn das für die Importe,
für das Imperative Programmierparadigma macht, also das,
was irgendwie die prozeduralen und die Objekte in den Programmierstrafen,
Sprachen drauf basieren.
Und das ist das Kalkül von den Herrn Huawe.
Sie sehen hier in der Jahreszahl 1969,
das ist schon sehr lange abrupt und deswegen kann man davon ausgehen,
dass das gut ist und ich möchte es Ihnen
kurz auf der nächsten Folie vorstellen
Zunächst erst mal, wie sowas aufgebaut, das besteht aus drei Teilen.
Da sagen wir dazu, ein Trippel, P und Q,
was sich das Ganze, P und Q sind die Prädikate.
Das sind Bedingungen, logische Ausdrücke, wobei P vor der Ausführung
und deswegen Vorbedingungen und cool nach der Ausführung, deswegen Nachbedingungen geht.
Und A ist die Anweisung, ist der Schritt, der hier getan wird.
So, soweit ist es erst mal nur die Struktur,
das sagt uns noch nicht so viel, was passiert denn da?
Wirksam wird es erst dadurch,
dass man es anwendet und wir machen hier
ein kleines Beispiel
Wir machen ein Interement, Inkrementaddition um eins, das kommt ganz häufig vor bei ganzen Zahlen.
Ja, so, wir sagen jetzt, okay,
wir haben eine Menge, eine Vorbedingung, zum Beispiel,
dass das X zwischen 1 und 1000 liegt,
das ist die Vorbedingung, Vorausführung der Operation.
Nachausführung der Operation, und das ist die Operation hier,
und Nachausführung der Operation haben wir die Bedingung formuliert,
dass es X zwischen 0, also größer als 0 ist,
und kleiner gleichtausend Tierarten, also einen kleinen Unterschied bemerken,
wir haben da kleinertausend hier darf es auch tausend erreichen.
Das heißt, wenn es hier nur 199 war,
wird es noch stimmen und hier wird es dann auch gerade noch stimmen.
Ja, also deswegen ist das so,
dass das hier gerade die Vor- und die Nachbringung zu der Operation war,
passend zu der Anweisung empathie, weil so ist es ja auch.
So, und auf diese Weise kann ich sagen, was passiert vor,
was ist vorher der Zustand, was ist nachher der Zuständen,
was ist die temperative Anweisung, die ich damit beschreibe.
So, das muss gelten, dass das immer wahr ist im Sinne von,
hält auch an, es ist nicht unendlich. Ja,
also insbesondere dann, wenn wir einen Bezug haben auf sich selbst,
zum Beispiel so Tiere oder machen den gleichen Schritt nochmal,
wenn es noch nicht genau genug ist, es muss ein Ende gehen.
Das terminiert. Ja, so, das ist also,
sie haben die Jahreszeit gesehen, wann es beschrieben ist,
es bezieht sich vor allen Dingen auf zuweisende Sequenzen,
Bedingungen, Schleifen. Dafür ist es wirklich wertvoll,
dafür ist es wirklich wichtig und es ist in der Praxis
anwendbar für diesen Tools vorhanden und wie gesagt,
das würde ich auch nutzen, um in OCL Vor- und Nachbedingungen zu beschreiben.
So, bevor wir weitergehen, möchte ich kurz etwas sagen,
wie wir das einschätzen. Wie ich das als Praktiker einschätzen möchte.
Es ist möglich, imperative Programme als partiell korrekt zu beweisen.
Mit diesen Dingen, die wir anfangs als Einschränkung genannt haben.
Ich muss beweisen, dass meine Spezifikation wirklich korrekt ist. Nicht,
dass ich etwas aufgeschrieben habe, was zwar irgendwie toll klingt,
aber nicht die Realität trifft. Das ist deswegen schwierig,
weil ich die Realität meistens ja nicht kenne,
aber ich bin kein Fachmann des Gebiets und einfach mal des Gebiets kommt,
dass dann dieses Yuara-Gold-König lesen
Das heißt, da kein Zielbesetzungsproblem geben. Ja,
und dann muss ich es Frau Mal definiert haben,
das wäre mit dem Moara Kölpier möglich.
Und da muss ich es halt nur überprüfen.
Und das Prüfwerkzeug muss korrekt sein. So. Deswegen partiell korrekt,
weil wir das nicht für das gesamte Programm machen wird.
Das ist für Objekt orientierte Programme etwas aufwendig, weil wir
diesen Konstrukt haben, mit über Referenzen, auf andere Elemente zuzugreifen.
Und da muss ich sehr viele Dinge in meine Prüfung einbeziehen.
Wenn ich das nur imperativ mache, nur ich sowas wie,
wenn es vielleicht nichts ergibt, es zu XPlus 1,
dann ist es relativ einfach.
Aber wenn das X und das Y dann Objekte sind,
an denen wieder was dran hängt, über weitere Objekte dürfte es sehr schwierig.
Man macht das Ganze nicht manuell, sondern weil das eben
dann schon sehr schwierig ist, sondern man macht es semi-automatisch.
Semi-automatisch heißt, es läuft nicht vollautomatisch, sondern semi halt.
Und wir brauchen also einen Experten,
der diesen Teil der Vor- und Nachbedingungen formuliert,
die für das Werkzeug zuschneidet und dann sagt, ja,
ist das korrekt.
Doch, das tragt trotzdem einen großen Wert,
nämlich dort, wo ich es unbedingt brauche,
weil das Risiko damit zu tun hat, Sicherheitskritische Bereiche.
Daher kann ich nachweisen,
was das und das sicher funktioniert
Wir haben gelegentlich so ein Bali im Glück. Ja,
dann sagt man manchmal, oh, da ist es dann da schief gelaufen.
Ich kenne bis jetzt nur Fälle. Ich habe ein paar Kollegen in meinem Umfeld,
die sich mit formaler Spezifikation für solche Transportsysteme beschäftigen.
Und von denen höre ich, dass es eigentlich immer nur menschliche Fehler sind.
Zum Teil bedingt dadurch, dass die Technik so kompliziert ist und kompliziert zu bedienen.
Aber es gab in den letzten Jahren keinen Fall, wo die Technik im Fehler gemacht hat. Ja,
also diese Technik für diese Transportsachen, wo zum Beispiel,
sie müssen sie, Eisenbahn, ja,
da gibt es eine Weiche und sie müssen den Zustand,
wir müssen gefährliche Zustände vermeiden, zum Beispiel,
Auf der einen Seite der Weiche,
auf der anderen Seite war ich ein Zug gleichzeitig fährt,
dass sie dann auf dieser Weiche sich treffen und dann gab es.
Diese sogenannte Flankenfahrt, das muss man vermeiden. Da gibt es deswegen manchmal die so,
vielleicht haben sie das schon mal aufgefallen,
da gibt es manchmal so eine Stumme, bevor das rübergeht,
ist da geradeaus noch eine Weiche und ein Prellbock.
Da denkt sich, was ist denn das,
wenn man da ein Lockup stellen oder was?
Nein, das ist die Sicherung. Ja,
also wenn das irgendwas schieflaufen sollte,
fährt der Zug auf den Prellbock,
dann kracht es lieber dort,
als dass es unterwegs auf der Strecke geht
Ja, also das ist ja nur so ein Beispiel,
wo etwas korrekt ein fehlhafter Zustand ausgeschlossen werden muss.
Und da kann ich die Korrektheit wirklich beweisen. Und da
benutze ich solche Aviser dafür. Das ist nur ein kleiner
Teil des Programmes, der auf diese Weise beriefen wird.
Aber da wird das wirklich angewandt. Und da ist es
sinnvoll. So, soweit erstmal dazu. Wir kommen gleich
zur abstrakten Datentypen. Das machen wir im nächsten Abschied