Willkommen zur Vorlesung Nummer 13, Korrektheit und Formalisierung.
Wir möchten mit dieser Veranstaltung oder mit diesem Themenblock eine Brücke schlagen zur theoretischen Informatik.
Wir wissen alle, dass das einer der härteren Porken im Bachelorstudium ist.
Wir möchten gerne mit diesem Abschnitt die Brücke schlagen zwischen dem,
was wir als Vertragsmodell behandelt haben und dem,
was sie bei Logikprogrammierung bei Beschreibungen lernen,
um zu motivieren, auch warum wir das brauchen,
warum das für die Praxis eine Rolle spielt,
auch wenn mancher Braktiker sagt,
habe ich noch nicht gesehen,
habe ich
nicht damit gearbeitet
Wir haben wieder einige Fragen zu dem Thema, die wir
dann jeweils im Einzelnen durchgehen. Und hier die Frage 5,
die hat den Keks im Sinne von Weiterführen,
was wir hier jetzt nicht diskutieren, was sie aber,
wo sie natürlich gerne auch Feedback dafür kriegen können.
Aber was wir jetzt nicht so direkt behandeln. Ja,
wir starten mit dem, was Korrektheit ist und Fragen zunächst erstmal,
warum brauchen wir denn das?
Ja, zunächst lassen wir uns mal starten damit,
dass die Entwickler die Aufgabe haben, gute Software zu entwickeln.
Gut, gut
Etwas mit Eigenschaften zu tun. Und ein anderes Wort für
Eigenschaften ist Qualität. Also es geht uns um Softwarequalität.
Wir wollen Software, die zuverlässig ist. Das heißt,
die auch unter erschwerten Bedingungen das tut, was man von ihr erwartet.
Und deswegen muss man diese Software prüfen im Verhalten.
Sie wissen alle vom Abschnitt testen, Test ist kein Nachweis von gut,
ja, von Korrektheit, sondern ein Test ist maximal eine Stichprobe.
Und deswegen brauchen wir in irgendeiner Form eine maschinelle Prüfung.
Eine maschinelle Prüfung, dass ihr Software das tut, was sie will.
Und da werden wir jetzt drüber sprechen, liefern muss das formalisiert sein.
Eine formale Beschreibung haben wie können wir dann Korrektheit formal beschreiben?
Und es geht uns darum, abstrakte Datentypen, nämlich,
das ist ja der Kern, die theoretische Basis,
eine der theoretischen Basis von Objektorientierung,
dass wir das hier benutzen kann und da sinnvoll einsetzen können.
Verlassen Sie uns mit Zuverlässigkeit starten. Wir hatten schon über
Qualitätsmerkmale gesprochen und zuverlässig ist etwas, das korrekt ist,
also genauso wie es spezifiziert ist und gleichzeitig auch für unter erschwerden Bedingungen.
Also hier steht das bei Robustheit so angemessen auf Fälle reagieren,
die nicht in der Spezifikation so vorgesehen sind.
Das heißt, müssen einfach davon ausgehen, es gibt Fehler.
Ja, es gibt Fehlverhalten von Menschen, es gibt Fehler,
die in der Software existieren und diese mit diesen Fehlern müssen wir leben.
Ein robustes, ein robustes Auto zum Beispiel,
das geht halt nicht ganz gleich kaputt,
wenn die Straße mal nicht ganz eben ist. Ja,
so oder im Robustes Werkzeug, das tut seine Funktion auch noch,
wenn man es mal ein bisschen missbraucht, mal ein bisschen stärker ansetzt,
im Schraubenzieher eben als Hebel ansetzt oder was auch immer.
Ja, so also das ist das, was wir in
der Zuverlässigkeit wollen und zu der Frage Korrektheit, hatten Sie in SE1
Ich weiß, schon eine ganze Menge gesprochen. Nämlich,
dass Korrektheit immer sich darauf bezieht, wie ist denn das beschrieben?
Die Spezifikation, ja. Und doch, da sollte er,
dabei ist auch rausgekommen, dass das formal, also förmlich nachweisen,
im Sinne eines Beweises, dass das sehr schwierig ist.
Ja, und das ist der eine Punkt. Man kann es schlecht nachweisen, aber Voraussetzungen,
dass man überhaupt die ganze Sache in den Angriff nimmt,
ist, dass diese Spezifikation in einer Form ist,
dass sie eindeutig und widerspruchsfrei ist.
Ja, also formal definiert sein muss
Das ist eine Herausforderung und die zweite Herausforderung ist,
dass die Spezifikation selbst auch korrekt formuliert ist.
Ja, wir machen das an einem Beispiel,
um zu sagen, wie sich das in der Praxis verhält.
Wir nehmen an in der Spezifikation, also in der Aufgabenbeschreibung,
steht Medien, also es geht um eine Mediathek,
das kennen sie ja immer schon,
das ist ein Beispiel, was wir gewählt haben,
weil sie sich hoffentlich darunter was vorstellen können.
Medien dürfen nur an Kunden verliehen werden,
die mindestens das Alter der FSK-Beschränkung haben.
FSK heißt, freiwillige Selbstkontrolle der Medienwirtschaft,
da gab es dieses FSK 18,
FSK 12 und wie auch immer
Also, dass die Filme mit Blut und Schweiß und Tränen
, dass man die nicht die kleinen Kinder damit verängstigt.
So, also darum geht es hier und das ist eigentlich eine ganz einfache Regel.
Vergleiche das Alter mit der FSK, mit dem FSK-Kennzeichen eines Mediums.
Ja, so, hier sollte das relativ einfach sein,
dass es nicht irgendwelche Ausnahmen gibt,
die wir jetzt in der natürlich sprachlichen Formulierung nicht dabei haben.
So, aber wir haben jetzt hier drei, vier Sachen geschrieben.
Ja, also zum einen der formale Nachweis ist aufwendig,
weil wir müssen einen Beweis führen
Zum dritten, zum zweiten, die Spezifikation muss
formal definiert sein, was schon nicht so einfach ist.
Wir haben sie meistens in Textformen wie hier. Und drittens,
wir müssen nachweisen, dass die Spezifikation auch das macht,
was sie soll. Nicht, dass es da irgendwelche Schimpflöcher gibt,
wie wir Steuerschlüpflöcher in den vergangenen Jahren,
hatten die in den Gesetzen, die sich lesen,
wie irgendwie ganz kompliziert und klar formuliert, nein,
da gab es Schimpflöcher.
Ja, und diese Schimpflöcher sollen die sind auch noch vorbei,
die von den Spezifikationen halt nicht geben. So,
aus diesen drei Gründen folgt, dass das ganz selten gemacht wird,
dass da vor ihr steht, es ist nicht realistisch.
Ja, also das ist so ein bisschen
das Schwierige
Was wir aber machen können, ist testen. Ja,
testen, wie Sie wissen das, alles ist kein Nachweis für Korrektheit, es ist nur eine Stichprobe.
Wenn die Stichprobe schlecht ist, dann haben Sie irgendwie daneben gegriffen.
Also ich habe mal in einem Werk gearbeitet als Schüler,
wo es darum ging, ganz große Stückzahlen zu verarbeiten, sagen wir mal, Schrauben. Ja,
und da hat man nicht jeder einzelne Schraube nachgeprüft,
das war ein Spezialschrauben, ja, so,
aber man hat die einzelnen Firmen in einer großen Kiste,
zum Beispiel 100 Stück rausgesucht und für die Hundesstücke durften so und so viel gut sein,
dann hat man angenommen,
also zum Beispiel durften drei schlecht sein für den Hundesstück,
dann hat man angenommen,
auf diese ganze große Kiste sind es nur Ich sag mal,
300 schlechte.
Und dann war die Kiste akzeptiert. Und wenn nicht,
ging die ganze Kiste zurück. Und das ist,
der Wert einer Stichbruch. Ja, und das war,
das ist das, was wir mit Testen machen.
So, wenn wir nur die gültigen Eingabewerte testen,
dann ist das das, was wir als Positiv-Test haben.
Wenn wir nur, wenn wir auch unmültige Tellerwerte testen,
also die, die eine Fehlermeldung provozieren sollten, dann sind das Negativ-Tests.
Diese beiden Sachen hatten wir hier, genau, positiv,
negativ, kennen Sie von der Batterie.
In dem Fall heißt es, ja, das,
was wir erwarten, dass der hier nicht erwartet
So. Gleichzeitig. Anderes Thema,
andere Anforderungen ist nicht nur für den Kunden die Korrektheit wichtig,
sondern auch für denjenigen, der dort in Software wiederverwenden möchte.
Der Software in einem anderen Gebiet einsetzen möchte.
Wenn wir etwas haben, was so eine Prozentberechnung macht,
dann wollen wir die nicht nur bei Mehrwertsteuer berechnen,
sondern vielleicht auch noch bei einem Teil der Miete,
von der Raummiete oder irgend sowas.
Dazu muss dieses Modul klar verständlich sein, verständlich beschrieben sein.
Es muss klar sein, dass sie das tut,
was sie will,
nämlich Zuverlässigkeit und Korrektheit
Das, was wir als Programmierer aber haben,
sind Klassennamen in Signaturen. Was wir nicht haben,
ist eine Beschreibung, was tut das Ganze, Semantik.
Und deswegen ist diese Beschreibung der Schnittstelle so wichtig für uns. So,
wir haben schon mal gesehen,
dass ich beziehe mich jetzt auf AC1,
jedenfalls vom Vorjahr oder von einem Jahrgang vorher,
wo ich mir die Folien mal geholt habe,
ist das so,
dass wir hier
ein Interface-Beschreibung haben mit Bezahlung
Und die Bezeichnung sagen uns Menschen etwas. Ja,
also wir lesen Push und wir haben eine Vorstellung,
Push heißt irgendetwas da hinpacken.
Ja, und Pop heißt etwas da bekommen. Und das,
wenn jemand kein Englisch kann, dann ist das für den
schon ein bisschen schwieriger. Ja, oder Stack unter Queue
. Dann haben wir eine Vorstellung. Das heißt,
eigentlich ist die Beschreibung nur dann für uns verständlich,
wenn wir eine Assoziation in unserem Gehirn haben.
Deswegen sind sie informal. Nicht formal. Ja,
und hier heißt es, die Texte Interfaces sind semi-formale Spezifikationen.
Das ist eigentlich formal festgelegt
Void, was heißt das? Element bezieht sich einfach in die Definition,
was heißt die Semikole und so weiter, aber die Semantik,
nämlich was tut das eigentlich, die ist nicht formal definiert.
Ja, sie ist natürlich sprachlich angegeben in Form von Kommentaren,
wie auch immer. So, aber wir brauchen die,
auch für die Semantik. Und zwar, ich möchte
zwei Punkte angeben, für die wir es brauchen.
Zum einen, wenn wir mit einem Generator arbeiten,
Generatoren sind total beliebt, ja, alle schreiben Burra,
wir können was automatisieren,
wir sparen Arbeit
Ich habe da ein bisschen meine eigene Meinung,
weil wie oft spart man denn die Arbeit nur beim Erstmaligen.
Und wenn man dann immer ändert, hat man,
spart man nichts. Ja, aber gut,
also es gibt, man möchte gern bei schematischem Code,
der immer wieder sich wiederholt, möchte man gerne einen Generator einsetzen,
automatisch den Code erzeugen.
Und dazu muss man natürlich irgendwie Übersetzungsregeln haben.
Und diese Übersetzungsregeln müssen wir in einer Form sein,
dass der Automat, der Generator die lesen kann.
Und deswegen müssen die formal beschrieben sein. Ja,
Syntax des Inputs, Abbildung, Regeln für die Abbildung,
was da rauskommt.
Das ist die Generatorfrage.
Software generiert
Und wir wollen gerne Software auf Korrektheit automatisiert prüfen.
Oder wir möchten sie prüfen auf gutem Stil. Zum Beispiel
möchten wir prüfen, ist das eine gute, modulare Software?
Ist Separation of Konsions erfüllt? Diese Korrektheit hatten wir eben
schon mal oder sind die Anforderungen denn alle erfüllt?
Ja, wenn ich irgendwie eine vergesse.
Menschen tendieren dazu, Fehler zu machen. Ja,
man sagt, Menschen machen drei Prozent Fehler,
wenn sie sich ganz viel Mühe geben, dann sagt man auch ein Wortsempfehler.
Aber das bedeutet immer noch, bei 10.000 Elementen sind 100
falsch und 100 Anforderungen vergessen, wäre schon schlecht.
Ja, oder 100 mal irgendwelche Landesverhaltensschicht.
Das wäre schon schlecht
So, er sollte ein Telefon klingeln verzeihen. So,
wir machen aber hier und wir sehen weiter und schauen uns mal das an Beispiel an.
Ja, also wir haben so eine Beschreibung eines Interfaces,
ja, und wollen daraus Code generieren für dieses Interface.
Ja, so, wir haben hier die Bezeichnung von Feldern,
wir haben die Bezeichnung von Operationen, von Methoden,
ja, und können daraus etwas generieren. Ja,
so, und damit ist das soweit erstmal relativ klar,
ja, aber wir müssen erstmal wissen, Dieses lieb ist,
dass das ein Get, ja, dann ist der,
wenn der Generator das weiß hier, dass das Gib,
ein Get ist, dann kann er, wer weiß ja,
okay, das ist nur Dissouturn für irgendein Feld.
So, und UML-Attributnamen, wie werden die in Java-Feldnamen überführt?
Ist das 1 zu 1? Gibt es hier so einen
Unterstrich? Wie machen wir das? Das sind Regeln.
Der Generator ist ja dumm. Er muss eben das gesagt
kriegen, die euch regeln. Das wäre ein Punkt,
wo wir damit etwas machen werden
Wir können ja jetzt, das war das Beispiel für, warum Interphaces formal definiert sind.
Wir hatten das zwei Folien vorher schon, hier,
warum ist das so und das war die Frage 1,
ich springe deswegen mal zur Frage 1 zurück.
Dieses Interface, warum sind sie, welche Teile sind formal beschrieben,
welche informal, wo wir, sagt uns das,
Signaturen sind formal definiert, formal festlegt, Semantik ist informal.
So, wir machen mal weiter bei der,
ja wir hatten gerade diese automatisierte Prüfung,
sorry, hier waren wir gewesen,
bei der Code-Generierung und machen jetzt mal weiter
Und schauen uns an, wie das, ach so,
genau, hier gab es so ein bisschen Priminationen zu erwähnen,
was, genau, also wir, dieser Ghetter,
ja, ist ja nochmal empfindet, ja,
also es muss klar sein, gib Länge in Minuten,
wir als Menschen ist völlig klar,
das ist ein Ghetter und wir ist völlig klar,
es beziehen sich auf dieses Feld, aber der Generator ist ja dumm,
der muss das noch genauer wissen.
So, der nächste Punkt ist automatisierte Prüfung, ja,
die automatisierte Prüfung,
wir haben diese Regeln mit dieser FSK-Beschränkung und wir wollen gerne,
dass in irgendeiner Form spezifizieren,
dass es eine Maschine lesen kann
Ja, und zwar machen wir das mit Vorbedingungen und Nachbedingungen.
Ja, hier zunächst erstmal die Vorbedingung, das Alter des
Kunden ist größer gleich, als das FFBFSK-Kennzeichnung des Mediums.
Ja, das könnte man fast noch als Mensch auch verstehen.
Das heißt, zu Sachen ist das korrekt.
Die Maschine kann das auch lesen, aber die Übertragung von
dir nach mir ist schon ein Formalisierungsschritt. Ja,
so, und wenn das aber so formal beschrieben ist,
dann kann man auch hier eine Prüfung machen,
indem man hier zum Beispiel in der Server-Anweisung heraus macht
Surf-Anweisung ist, im Idealfall, diesen einfachen Fall hier, ganz genauso formuliert, wie die OCN-Regeln.
OCL ist die Object Constrained Language. Das ist etwas,
was eine Sprache für die Beschreibung von In-Varianten und Regeln,
die formal, die definiert ist,
zusammen mit der UML und von vielen Werkzeugen auch unterstützt wird.
In der Praxis gibt es leider nicht so viel zu den UCL zu sehen,
obwohl viele Leute, dass viele Informatiker das im Studium lernen,
so wie sie gerade hier das mal nur zu sehen kriegen,
in anderen Veranstaltungen gibt es dazu ein bisschen mehr,
aber in der Waffe spielt es nicht so eine große Rolle,
weil es zu wenig Leute kennen,
weil man zu wenig das für sinnvoll achtet,
das zu machen
Also das ist ein Beispiel für die automatisierte Prüfung.
Der West, die wesentliche. Wir sehen nochmal die Kennzeichen
. Zum einen, ich muss es aus der Natürlichsprachlichen,
also dann nicht formalen Beschreibung in eine Vorwahlbeschreibung dafür,
also der Schritt von mir und nach hier.
Das ist eine Herausforderung. Nächste Herausforderung ist, dass das dann auch korrekt ist.
Jemand muss es prüfen. Und dann muss ich eine Maschine haben,
die das hierher übersetzt, also aus dieser Beschreibung.
Das. Und dann kann ich natürlich eine Finale prüfen.
So, die Spezifikation von sind von Programmen zu prüfen,
ist also oder beschreiben, zu beschreiben ist deswegen wichtig,
vor allen Dingen für die Semantik. Damit könnten wir dann auch prüfen,
ob das Programm was richtig tut, zum Beispiel mit einem Beweiser,
ja, wir können die Korrektheit prüfen,
wenn die Spezifikation auf die Eingabewerte angewendet werden kann, ja,
und wir könnten sogar das ganze Beschreiben des Verhaltensprogramms beschreiben mit dieser Spezifikation,
ohne dass wir wirklich an eine Programmiersprache gebunden sind.
Das wäre doch
sehr schön
Und das ist auch die, haben wir ja bei unseren Fragen
als Frage 2 beformuliert, ich springe mal dahin zurück.
Ja, die Schwierigkeiten, die darin,
wenn keine formale Spezifikation vorliegt, dann können wir da alles das,
was auf der 12 liegt, nicht machen.
Ja, wir können also das nicht vorstellen.
Wir können nicht prüfen, dass das korrekt ist.
Und wir können das nicht unabhängig von der Programmiersprache bescheiden.
Das sind die Punkte, die wir jetzt mit dieser Frage dann zu tun haben.
Wenn wir also Ich habe hoffentlich damit in genügend genau erklärt,
warum brauchen wir denn eine Beschreibung der Semantik,
die besser ist als dieses natürlich Sprachliche.
Und dazu möchte ich jetzt drei Dinge vorstellen und
das ist jetzt die schon angekündigte Brücke in das theoretische Informatik
und das machen wir im nächsten Abschnitt