Entwurf durch Vertrag

Ein Design nach Vertragsschema

Entwurf durch Vertrag (DBC), auch bekannt als Vertragsprogrammierung, Programmierung durch Vertrag und Design-by-Contract-Programmierung, ist ein Ansatz für Software entwerfen.

Es wird vorgeschrieben, dass Softwaredesigner definieren sollten formellpräzise und überprüfbare Schnittstellenspezifikationen für Softwarekomponenten, die die gewöhnliche Definition von erweitern Abstrakte Datentypen mit Voraussetzungen, Postconditions und Invarianten. Diese Spezifikationen werden gemäß a als "Verträge" bezeichnet konzeptionelle Metapher mit den Bedingungen und Verpflichtungen von Geschäftsverträgen.

Der DBC -Ansatz geht davon aus alle Client -Komponenten das ruft eine Operation auf a auf Serverkomponente Erfüllt die Voraussetzungen, die für diesen Vorgang festgelegt sind.

Wo diese Annahme als zu riskant angesehen wird (wie in Multi-Channel oder verteiltes Computer), das inverser Ansatz wird genommen, was bedeutet, dass die Serverkomponente Tests, dass alle relevanten Voraussetzungen zutreffen (vor oder während der Verarbeitung der Verarbeitung der Client -Komponente 's Anfrage) und antwortet mit einer geeigneten Fehlermeldung, wenn nicht.

Geschichte

Der Begriff wurde von geprägt von Bertrand Meyer im Zusammenhang mit seinem Design der Eiffel -Programmiersprache und erstmals in verschiedenen Artikeln ab 1986 beschrieben[1][2][3] und die beiden aufeinanderfolgenden Ausgaben (1988, 1997) seines Buches Objektorientierte Softwarekonstruktion. Eiffeltoftware beantragte eine Markenregistrierung für Entwurf durch Vertrag Im Dezember 2003 wurde es im Dezember 2004 gewährt.[4][5] Der derzeitige Eigentümer dieser Marke ist Eiffeltoftware.[6][7]

Das Design von Vertrag hat seine Wurzeln an der Arbeit an formelle Überprüfung, Formale Spezifikation und Hoare Logik. Die ursprünglichen Beiträge umfassen:

Beschreibung

Die zentrale Idee von DBC ist eine Metapher, wie Elemente eines Softwaresystems auf der Grundlage von gegenseitig miteinander zusammenarbeiten Verpflichtungen und Vorteile. Die Metapher stammt aus dem Geschäftsleben, wo ein "Kunde" und ein "Lieferant" einen "Vertrag" vereinbaren, der zum Beispiel das definiert:

  • Der Lieferant muss ein bestimmtes Produkt (Verpflichtung) bereitstellen und ist berechtigt zu erwarten, dass der Kunde seine Gebühr (Leistung) gezahlt hat.
  • Der Kunde muss die Gebühr (Verpflichtung) zahlen und hat berechtigt, das Produkt zu erhalten (Nutzen).
  • Beide Parteien müssen bestimmte Verpflichtungen wie Gesetze und Vorschriften erfüllen, die für alle Verträge gelten.

In ähnlicher Weise, wenn die Methode von a Klasse in Objekt orientierte Programmierung Bietet eine bestimmte Funktionalität, kann es:

  • Erwarten Voraussetzung- Eine Verpflichtung für den Kunden und ein Vorteil für den Lieferanten (die Methode selbst), da er ihn davon abhält, Fälle außerhalb der Voraussetzung zu bewältigen.
  • Garantieren eine bestimmte Eigenschaft beim Ausgang: die Methode der Methode Postkondition- Eine Verpflichtung für den Lieferanten und offensichtlich ein Vorteil (der Hauptvorteil der Aufruf der Methode) für den Kunden.
  • Verwalten Sie ein bestimmtes Eigentum, das bei der Einreise angenommen und beim Ausgang garantiert wird: die Klasseninvariante.

Der Vertrag entspricht semantisch zu a Hoare Triple was die Verpflichtungen formalisiert. Dies kann durch die "drei Fragen" zusammengefasst werden, die der Designer im Vertrag wiederholt beantworten muss:

  • Was erwartet der Vertrag?
  • Was garantiert der Vertrag?
  • Was behält der Vertrag bei?

Viele Programmiersprachen Einrichtungen haben zu machen Behauptungen wie diese. DBC betrachtet diese Verträge jedoch als so entscheidend für Software -Korrektheit dass sie Teil des Designprozesses sein sollten. Tatsächlich befürwortet DBC Zuerst die Behauptungen schreiben. Verträge können von geschrieben werden von Codekommentare, durchgesetzt von a Testsuite, oder beides, auch wenn es keine besondere Sprachunterstützung für Verträge gibt.

Der Begriff eines Vertrags erstreckt sich auf die Methode/Verfahrensebene. Der Vertrag für jede Methode enthält normalerweise die folgenden Informationen:

  • Akzeptable und inakzeptable Eingabetypen und ihre Bedeutungen
  • Rückgabewerte oder Typen und ihre Bedeutungen
  • Fehler und Ausnahme Zustandswerte oder -typen, die auftreten können, und deren Bedeutungen
  • Nebenwirkungen
  • Voraussetzungen
  • Postconditions
  • Invarianten
  • (seltener) Leistungsgarantien, z. Für Zeit oder Raum genutzt

Unterklassen in einem Vererbungshierarchie dürfen Voraussetzungen schwächen (aber nicht stärken) und die Postkonditionen und Invarianten stärken (aber nicht schwächen). Diese Regeln sind ungefähr Verhaltensuntertyp.

Alle Klassenbeziehungen sind zwischen Kundenklassen und Lieferantenklassen. Eine Kundenklasse ist verpflichtet, Anrufe bei Lieferantenfunktionen zu tätigen, bei denen der resultierende Zustand des Lieferanten vom Kundenaufruf nicht verletzt wird. Anschließend ist der Lieferant verpflichtet, einen Rückgabestatus und Daten bereitzustellen, die nicht gegen die staatlichen Anforderungen des Kunden verstoßen.

Beispielsweise kann ein Lieferantendatenpuffer erforderlich sein, dass Daten im Puffer vorhanden sind, wenn eine Löschfunktion aufgerufen wird. Anschließend garantiert der Lieferant dem Kunden, dass das Datenelement, wenn eine Löschfunktion seine Arbeit beendet ist, tatsächlich aus dem Puffer gelöscht wird. Andere Designverträge sind Konzepte von Klasseninvariante. Die Klasseninvariante garantiert (für die lokale Klasse), dass der Zustand der Klasse am Ende jeder Merkmalausführung innerhalb bestimmter Toleranzen aufrechterhalten wird.

Bei der Verwendung von Verträgen sollte ein Lieferant nicht versuchen zu überprüfen, ob die Vertragsbedingungen erfüllt sind - eine Praxis, die als bekannt ist Offensivprogrammierung- Die allgemeine Idee ist, dass Code "hart scheitern" sollte, wobei die Vertragsüberprüfung das Sicherheitsnetz ist.

Die "Fail Hard" -Sperte von DBC vereinfacht das Debuggen des Vertragsverhaltens, da das beabsichtigte Verhalten jeder Methode klar angegeben ist.

Dieser Ansatz unterscheidet sich erheblich von dem von Defensivprogrammierung, wo der Lieferant dafür verantwortlich ist, herauszufinden, was zu tun ist, wenn eine Voraussetzung gebrochen ist. In den meisten Fällen macht der Lieferant eine Ausnahme, um den Kunden darüber zu informieren, dass die Voraussetzung gebrochen wurde, und in beiden Fällen - DBC- und Defensivprogrammierung gleichermaßen - muss der Kunde herausfinden, wie er darauf reagieren soll. In solchen Fällen erleichtert DBC den Job des Lieferanten.

Design by Contract definiert auch Kriterien für die Korrektheit für ein Softwaremodul:

  • Wenn die Klasseninvariante und Voraussetzung wahr sind, bevor ein Lieferant von einem Kunden aufgerufen wird, dann wird die Invariante und die Postdition nach Abschluss des Dienstes wahr sein.
  • Bei Anrufen eines Lieferanten sollte ein Softwaremodul nicht gegen die Voraussetzungen des Lieferanten verstoßen.

Das Design nach Vertrag kann auch die Wiederverwendung von Code erleichtern, da der Vertrag für jeden Code vollständig dokumentiert ist. Die Verträge für ein Modul können als Form von angesehen werden Softwaredokumentation für das Verhalten dieses Moduls.

Leistungsauswirkungen

Die Vertragsbedingungen sollten während der Ausführung eines fehlerfreien Programms niemals verletzt werden. Verträge werden daher in der Regel nur im Debug -Modus während der Softwareentwicklung überprüft. Später bei der Veröffentlichung sind die Vertragsprüfungen deaktiviert, um die Leistung zu maximieren.

In vielen Programmiersprachen werden Verträge mit implementiert behaupten. Die Behauptungen werden standardmäßig im Freigabemodus in C/C ++ kompiliert und in C# ähnlich deaktiviert[8] und Java.

Wenn Sie den Python-Interpreter mit "-O" (für "Optimize" als Argument als Argument starten, veranlasst der Python-Codegenerator ebenfalls, keine Bytecode für Behauptungen auszugeben.[9]

Dies beseitigt effektiv die Laufzeitkosten von Behauptungen im Produktionscode-die Anzahl der in der Entwicklung verwendeten Behauptungen und Rechenaufwand für die Entwicklung-, da solche Anweisungen durch den Compiler keine solchen Anweisungen in die Produktion aufgenommen werden.

Beziehung zu Softwaretests

Das Design durch Vertrag ersetzt keine regulären Teststrategien, wie z. Unit -Tests, Integrationstests und Systemtests. Es ergänzt vielmehr externe Tests mit internen Selbsttests, die sowohl für isolierte Tests als auch in Produktionscode während einer Testphase aktiviert werden können.

Der Vorteil interner Selbsttests besteht darin, dass sie Fehler erkennen können, bevor sie sich als ungültige Ergebnisse des Kunden manifestieren. Dies führt zu früherer und spezifischerer Fehlererkennung.

Die Verwendung von Behauptungen kann als eine Form von angesehen werden Testen Sie Orakel, eine Möglichkeit, das Design durch Vertragsumsetzung zu testen.

Sprachunterstützung

Sprachen mit nativer Unterstützung

Sprachen, die die meisten DBC -Funktionen implementieren, umfassen nativ:

Zusätzlich die Standardmethode -Kombination in der Gemeinsames Lisp -Objektsystem hat die Methodenqualifizierer :Vor, :nach und :um Dadurch werden Schreibverträge unter anderem als Hilfsmethoden ermöglicht.

Sprachen mit Unterstützung von Drittanbietern

Verschiedene Bibliotheken, Präprozessoren und andere Tools wurden für vorhandene Programmiersprachen ohne native Design durch Vertragsunterstützung entwickelt:

Siehe auch

Anmerkungen

  1. ^ Meyer, Bertrand: Entwurf durch Vertrag, Technischer Bericht TR-EI-12/CO, Interactive Software Engineering Inc., 1986
  2. ^ Meyer, Bertrand: Entwurf durch Vertrag, in Fortschritte in der objektorientierten Software-Engineering, eds. D. Mandrioli und B. Meyer, Prentice Hall, 1991, S. 1–50
  3. ^ Meyer, Bertrand: Antrag auf "Design durch Vertrag" anwenden ", im Computer (IEEE), 25, 10, Oktober 1992, S. 40–51, ebenfalls verfügbar online
  4. ^ "United States Patent und Markenbüro Registrierung für" Design by Contract "". Archiviert von das Original Am 2016-12-21. Abgerufen 2009-06-22.
  5. ^ "United States Patent und Markenbüroregistrierung für das Grafikdesign mit Worten" Design by Contract "". Archiviert von das Original Am 2016-12-21. Abgerufen 2009-06-22.
  6. ^ "Markenstatus & Dokumentenabruf". Tarr.Uspto.gov.
  7. ^ "Markenstatus & Dokumentenabruf". Tarr.Uspto.gov.
  8. ^ "Behauptungen im verwalteten Code". msdn.microsoft.com.
  9. ^ Offizielle Python -Dokumente, Assert -Erklärung
  10. ^ Bright, Walter (2014-11-01). "D Programmiersprache, Vertragsprogrammierung". Digital Mars. Abgerufen 2014-11-10.
  11. ^ Hodges, Nick. "Schreiben Sie sauberer, höherwertiger Code mit Klassenverträgen in Delphi Prisma". Embarcadero -Technologien. Abgerufen 20. Januar 2016.
  12. ^ Findler, Fellisen Verträge für Funktionen höherer Ordnung
  13. ^ "Scala Standard Library Docs - Behauptungen". EPFL. Abgerufen 2019-05-24.
  14. ^ Starke Typisierung Als weitere "Vertragsdurchsetzung" in Scala siehe Diskussion bei scala-lang.org/.
  15. ^ "Code -Verträge". msdn.microsoft.com.
  16. ^ "Bean -Validierungsspezifikation". Beanvalidation.org.
  17. ^ "Software -Testhilfe von Experten | Parasoft Resources" (PDF).
  18. ^ "Archivierte Kopie" (PDF). Archiviert von das Original (PDF) am 2016-03-28. Abgerufen 2016-03-25.{{}}: CS1 Wartung: Archiviertes Kopie als Titel (Link) p. 2
  19. ^ "Keine Chance, unter Apache/Eclipse/MIT/BSD -Lizenz zu veröffentlichen? · Ausgabe #5 · Nhatminhale/Cofoja". GitHub.

Literaturverzeichnis

  • Mitchell, Richard und McKim, Jim: Design nach Vertrag: Mit Beispiel, Addison-Wesley, 2002
  • Ein Wikibook, der DBC eng mit dem Originalmodell beschreibt.
  • McNeille, Ashley: Ein Rahmen für die Semantik von Verhaltensverträgen. Verfahren des zweiten internationalen Workshops zur Verhaltensmodellierung: Foundation und Anwendungen (BM-FA '10). ACM, New York, NY, USA, 2010. In diesem Papier werden generalisierte Vorstellungen von erörtert Vertrag und Substituierbarkeit.

Externe Links