Behauptung (Computerwissenschaft)

In der Computerprogrammierung ist eine Behauptung ein Prädikat (zum Beispiel eine wahre falsche Angabe) gelegt in ein Programm, um anzuzeigen, dass der Entwickler denkt, dass das Prädikat immer an diesem Platz wahr ist.

Zum Beispiel enthält der folgende Code zwei Behauptungen:

{x> 0 }\

x: = x + 1

{x> 1} </Quelle>

und, und sie sind tatsächlich an den angezeigten Punkten während der Ausführung wahr.

Programmierer können Behauptungen verwenden, um zu helfen, Programme anzugeben und über die Programm-Genauigkeit vernünftig zu urteilen. Zum Beispiel, eine Vorbedingung — eine Behauptung, die am Anfang einer Abteilung des Codes gelegt ist — bestimmt den Satz von Staaten, unter denen der Programmierer annimmt, dass der Code durchführt. Eine Postbedingung — gelegt am Ende — beschreibt den erwarteten Staat am Ende der Ausführung.

Das Beispiel verwendet oben die Notation für das Umfassen von Behauptungen, die von C.A.R. Hoare in seiner 1969-Zeitung verwendet sind. Diese Notation kann auf vorhandenen Hauptströmungsprogrammiersprachen nicht verwendet werden. Jedoch können Programmierer ungehemmte Behauptungen mit der Anmerkungseigenschaft ihrer Programmiersprache einschließen. Zum Beispiel, in C:

x = x + 1;

//{x> 1} </Quelle>

Die in die Anmerkung eingeschlossenen geschweiften Klammern helfen, diesen Gebrauch einer Anmerkung von anderem Gebrauch zu unterscheiden.

Mehrere moderne Programmiersprachen schließen überprüfte Behauptungen - Behauptungen ein, die an der Durchlaufzeit oder manchmal statisch überprüft werden. Wenn eine Behauptung zum falschen an der Durchlaufzeit bewertet, resultiert ein Behauptungsmisserfolg, der normalerweise Ausführung veranlasst abzubrechen. Das lenkt Aufmerksamkeit auf die Position, an der die logische Widersprüchlichkeit entdeckt wird und dem Verhalten vorzuziehend sein kann, das sonst resultieren würde.

Der Gebrauch von Behauptungen hilft dem Programmierer-Design, entwickeln Sie sich, und Grund über ein Programm.

Gebrauch

Auf Sprachen wie Eiffel bilden Behauptungen einen Teil des Designprozesses, und in anderen, wie C und Java, sie werden nur verwendet, um Annahmen an der Durchlaufzeit zu überprüfen. In beiden Fällen können sie für die Gültigkeit an der Durchlaufzeit überprüft werden, aber können gewöhnlich auch unterdrückt werden.

Behauptungen im Design durch den Vertrag

Behauptungen können als eine Form der Dokumentation fungieren: Sie können den Staat beschreiben, den der Code annimmt zu finden, bevor es läuft (seine Vorbedingungen), und der Staat, auf den der Code annimmt hinauszulaufen, wenn es beendet wird (Postbedingungen) laufend; sie können auch invariants einer Klasse angeben. Eiffel integriert solche Behauptungen in die Sprache und zieht sie automatisch heraus, um die Klasse zu dokumentieren. Das bildet einen wichtigen Teil der Methode des Designs durch den Vertrag.

Diese Annäherung ist auch auf Sprachen nützlich, die sie nicht ausführlich unterstützen: Der Vorteil, Behauptungsbehauptungen aber nicht Behauptungen in Anmerkungen zu verwenden, besteht darin, dass das Programm die Behauptungen jedes Mal überprüfen kann, wenn es läuft; wenn die Behauptung nicht mehr hält, kann ein Fehler ausgegeben werden. Das hält den Code davon ab, asynchron mit den Behauptungen zu kommen (ein Problem, das mit Anmerkungen vorkommen kann).

Behauptungen für die Laufzeitüberprüfung

Eine Behauptung kann verwendet werden, um nachzuprüfen, dass eine Annahme, die vom Programmierer während der Durchführung des Programms gemacht ist, gültig bleibt, wenn das Programm durchgeführt wird. Denken Sie zum Beispiel den folgenden javanischen Code:

int Summe = countNumberOfUsers ;

wenn (Gesamt% 2 == 0) {\

//ganz ist sogar

} sonst {\

//ganz ist sonderbarer und nichtnegativer

behaupten Sie (Gesamt% 2 == 1);

}\

</Quelle>

In Java, ist der Rest-Maschinenbediener (oder Modul) — wenn sein erster operand negativ ist, kann das Ergebnis auch negativ sein. Hier hat der Programmierer angenommen, dass das nichtnegativ ist, so dass der Rest einer Abteilung mit 2 immer 0 oder 1 sein wird. Die Behauptung macht diese Annahme ausführlich — wenn wirklich einen negativen Wert zurückgibt, kann das Programm einen Programmfehler haben.

Ein Hauptvorteil dieser Technik besteht darin, dass, wenn ein Fehler wirklich vorkommt, es sofort und direkt, aber nicht später durch seine häufig dunklen Nebenwirkungen entdeckt wird. Da ein Behauptungsmisserfolg gewöhnlich die Codeposition meldet, kann man häufig den Fehler ohne das weitere Beseitigen genau feststellen.

Behauptungen werden auch manchmal an Punkten gelegt, die die Ausführung nicht erreichen soll. Zum Beispiel konnten Behauptungen an der Klausel der Behauptung auf Sprachen wie C, C ++, und Java gelegt werden. Jeder Fall, den der Programmierer absichtlich nicht behandelt, wird einen Fehler erheben, und das Programm wird abbrechen, anstatt in einem falschen Staat still weiterzugehen.

In Java sind Behauptungen ein Teil der Sprache seit der Version 1.4 gewesen. Behauptungsmisserfolge laufen auf Aufhebung hinaus, wenn das Programm mit den passenden Fahnen geführt wird, ohne die die behaupten Behauptungen ignoriert werden. In C werden sie durch den Standardkopfball hinzugefügt, der als ein Makro definiert, das einem Fehler im Fall vom Misserfolg Zeichen gibt, gewöhnlich das Programm begrenzend. Im Standard C ++ ist der Kopfball stattdessen erforderlich. Jedoch haben einige C ++ Bibliotheken noch das verfügbare.

Die Gefahr von Behauptungen besteht darin, dass sie Nebenwirkungen verursachen können, entweder indem sie Speicherdaten ändern, oder indem sie Faden-Timing ändern. Behauptungen sollten sorgfältig durchgeführt werden, so verursachen sie keine Nebenwirkungen auf dem Programm-Code.

Behauptungskonstruktionen auf einer Sprache berücksichtigen leichte probegefahrene Entwicklung (TDD) ohne den Gebrauch einer Drittbibliothek.

Behauptungen während des Entwicklungszyklus

Während des Entwicklungszyklus wird der Programmierer normalerweise das Programm mit ermöglichten Behauptungen führen. Wenn ein Behauptungsmisserfolg vorkommt, wird der Programmierer vom Problem sofort benachrichtigt. Viele Behauptungsdurchführungen werden auch die Ausführung des Programms halten — das ist nützlich, seitdem wenn das Programm fortgesetzt hat, hinter einer Behauptungsübertretung herzulaufen, ist vorgekommen, es könnte seinen Staat verderben und die Ursache des Problems schwieriger machen sich niederzulassen. Mit der Auskunft, die durch den Behauptungsmisserfolg gegeben ist (wie die Position des Misserfolgs und vielleicht einer Stapel-Spur oder sogar des vollen Programms setzen fest, ob die Umgebung Kernmüllkippen unterstützt, oder wenn das Programm in einem Testhilfeprogramm läuft), Programmierer gewöhnlich Problem befestigen. So stellen Behauptungen ein sehr starkes Werkzeug im Beseitigen zur Verfügung.

Statische Behauptungen

Behauptungen, die während der Übersetzung überprüft werden, werden statische Behauptungen genannt. Sie sollten immer gut kommentiert werden.

Statische Behauptungen sind in der Übersetzungszeit-Schablone metaprogramming besonders nützlich, aber können auch auf auf niedriger Stufe Sprachen in C durch das Einführen ungesetzlichen Codes verwendet werden, wenn (und nur wenn) die Behauptung scheitert. Zum Beispiel in C kann eine statische Behauptung wie das durchgeführt werden:

  1. definieren Sie COMPILE_TIME_ASSERT (pred) Schalter (0) {Fall 0:case pred:; }\

COMPILE_TIME_ASSERT (BOOLEAN BEDINGUNG);

</Quelle>

Wenn der Teil zum falschen dann bewertet, wird der obengenannte Code nicht kompilieren, weil der Bearbeiter zwei Fall-Etiketten mit derselben Konstante nicht erlauben wird. Der boolean Ausdruck muss eine Übersetzungszeit unveränderlicher Wert sein, zum Beispiel würde ein gültiger Ausdruck in diesem Zusammenhang sein. Diese Konstruktion arbeitet am Dateispielraum (d. h. nicht innerhalb einer Funktion) nicht, und so muss es innerhalb einer Funktion gewickelt werden.

Eine andere populäre Weise, Behauptungen in C durchzuführen, ist:

statische Rotforelle const static_assertion [(BOOLEAN BEDINGUNG)

? 1:-1

] = {'!'};

</Quelle>

Wenn der Teil zum falschen dann bewertet, wird der obengenannte Code nicht kompilieren, weil Reihe keine negative Länge haben kann. Wenn tatsächlich der Bearbeiter eine negative Länge dann erlaubt, sollte das Initialisierungsbyte (der Teil) sogar solche übernachsichtigen Bearbeiter veranlassen sich zu beklagen. Der boolean Ausdruck muss eine Übersetzungszeit unveränderlicher Wert sein, zum Beispiel würde ein gültiger Ausdruck in diesem Zusammenhang sein.

Beide dieser Methoden verlangen eine Methode, einzigartige Namen zu bauen. Moderne Bearbeiter unterstützen __ SCHALTER __ Vorverarbeiter definiert, der den Aufbau von einzigartigen Namen, durch das Zurückbringen monotonically von steigenden Zahlen für jede Kompilationseinheit erleichtert.

C11 und C ++ 11 stellen statische Behauptungen durch den Gebrauch dessen zur Verfügung.

Das Deaktivieren von Behauptungen

Die meisten Sprachen erlauben Behauptungen, ermöglicht oder allgemein, und manchmal unabhängig arbeitsunfähig zu werden. Behauptungen werden häufig während der Entwicklung ermöglicht und während der Endprüfung und auf der Ausgabe dem Kunden arbeitsunfähig. Nicht Überprüfung von Behauptungen vermeidet die Kosten, die Behauptungen zu bewerten, während, die Behauptungen annehmend, frei von Nebenwirkungen sind, noch dasselbe Ergebnis unter üblichen Zuständen erzeugend. Unter anomalen Bedingungen, Behauptungsüberprüfung unbrauchbar machend, kann bedeuten, dass ein Programm, das abgebrochen hätte, fortsetzen wird zu laufen. Das ist manchmal vorzuziehend.

Einige Sprachen, einschließlich C und C ++, entfernen völlig Behauptungen während der Übersetzung mit dem Vorverarbeiter. Java verlangt, dass eine Auswahl zum Laufzeitmotor passiert wird, um Behauptungen zu ermöglichen. Die Auswahl fehlend, werden Behauptungen umgangen, aber sie bleiben immer im Code, wenn nicht optimiert, weg durch einen JIT Bearbeiter an der Durchlaufzeit oder ausgeschlossen durch, wenn (falsche) Bedingung während der Übersetzung so sie keinen Laufzeitraum oder Zeitkosten in Java auch zu haben brauchen.

Programmierer können immer bauen checkt in ihrem Code ein, die immer durch das Umleiten oder die Manipulierung der normalen Behauptung überprüfenden Mechanismen der Sprache aktiv sind.

Vergleich mit dem Fehlerberühren

Es lohnt sich, Behauptungen vom alltäglichen Fehlerberühren zu unterscheiden. Behauptungen sollten verwendet werden, um logisch unmögliche Situationen zu dokumentieren und Programmierfehler zu entdecken —, wenn der Unmögliche vorkommt, dann ist etwas Grundsätzliches klar falsch. Das ist vom Fehlerberühren verschieden: Die meisten Fehlerbedingungen sind möglich, obwohl einige sehr unwahrscheinlich sein können, in der Praxis vorzukommen. Mit Behauptungen weil ist ein Mehrzweckfehler, Mechanismus behandelnd, unklug: Behauptungen berücksichtigen Wiederherstellung von Fehlern nicht; ein Behauptungsmisserfolg wird normalerweise die Ausführung des Programms plötzlich halten. Behauptungen zeigen auch keine benutzerfreundliche Fehlermeldung.

Denken Sie das folgende Beispiel, eine Behauptung zu verwenden, um einen Fehler zu behandeln:

interne Nummer *ptr = malloc (sizeof (interne Nummer) * 10);

behaupten Sie (ptr);

//verwenden Sie ptr

...

</Quelle>

Hier ist der Programmierer bewusst, dass das einen Zeigestock zurückgeben wird, wenn Gedächtnis nicht zugeteilt wird. Das ist möglich: Das Betriebssystem versichert nicht, dass jeder Anruf erfolgreich sein wird. Wenn aus dem Speicherfehler vorkommt, wird das Programm sofort abbrechen. Ohne die Behauptung würde das Programm fortsetzen zu laufen, bis ptr dereferenced, und vielleicht länger abhängig von der spezifischen Hardware war, die wird verwendet. So lange Behauptungen nicht arbeitsunfähig sind, wird ein unmittelbarer Ausgang gesichert. Aber wenn ein anmutiger Misserfolg gewünscht wird, muss das Programm den Misserfolg behandeln. Zum Beispiel kann ein Server vielfache Kunden haben, oder kann Mittel halten, die sauber nicht veröffentlicht werden, oder er neutrale Änderungen haben kann, um einem datastore zu schreiben. In solchen Fällen ist es besser, einer einzelnen Transaktion zu fehlen, als, plötzlich abzubrechen.

Siehe auch

Links


Die Provinz / Herzog von Connaught und Strathearn
Impressum & Datenschutz