Design durch den Vertrag (DbC), auch bekannt als Vertragsprogrammierung, durch den Vertrag und die Programmierung des Designs durch den Vertrag programmierend, sind eine Annäherung, um Software zu entwerfen. Es schreibt vor, dass Softwareentwerfer formelle, genaue und nachprüfbare Schnittstelle-Spezifizierungen für Softwarebestandteile definieren sollten, die die gewöhnliche Definition von abstrakten Datentypen mit Vorbedingungen, Postbedingungen und invariants erweitern. Diese Spezifizierungen werden "Verträge", in Übereinstimmung mit einer Begriffsmetapher mit den Bedingungen und Verpflichtungen von Geschäftsverträgen genannt.

"Das Design durch den Vertrag" ist ein eingetragenes Warenzeichen der Eiffel Software in den Vereinigten Staaten. Microsoft nennt ihre Design durch den Vertrag "Durchführungsprogrammiercodeverträge".

Geschichte

Der Begriff wurde von Bertrand Meyer im Zusammenhang mit seinem Design der Programmiersprache von Eiffel ins Leben gerufen und zuerst in verschiedenen Artikeln beschrieben, die 1986 und den zwei aufeinander folgenden Ausgaben (1988, 1997) von seinem Buch Objektorientierter Softwareaufbau anfangen. Eiffel Software hat sich um Handelsmarke-Registrierung um das Design durch den Vertrag im Dezember 2003 beworben, und es wurde im Dezember 2004 gewährt. Der aktuelle Eigentümer dieser Handelsmarke ist Eiffel Software.

Das Design durch den Vertrag hat seine Wurzeln in der Arbeit an der formellen Überprüfung, formellen Spezifizierung und Logik von Hoare. Die ursprünglichen Beiträge schließen ein:

• Eine klare Metapher, um den Designprozess zu führen
• Die Anwendung auf das Erbe, insbesondere ein Formalismus für die Wiederdefinition und dynamische Schwergängigkeit
• Die Anwendung auf die Ausnahme, die behandelt
• Die Verbindung mit der automatischen Softwaredokumentation

Beschreibung

Die Hauptidee von DbC ist eine Metapher darauf, wie Elemente eines Softwaresystems mit einander, auf der Grundlage von gegenseitigen Verpflichtungen und Vorteilen zusammenarbeiten. Die Metapher kommt aus dem Betriebsleben, wo sich ein "Kunde" und ein "Lieferant" über einen "Vertrag" einigen, der zum Beispiel dass definiert:

• Der Lieferant muss ein bestimmtes Produkt (Verpflichtung) zur Verfügung stellen und wird berechtigt zu erwarten, dass der Kunde seine Gebühr (Vorteil) bezahlt hat.
• Der Kunde muss die Gebühr (Verpflichtung) bezahlen und wird berechtigt, das Produkt (Vorteil) zu bekommen.
• Sowohl Parteien müssen bestimmte Verpflichtungen, wie Gesetze als auch Regulierungen befriedigen, sich für alle Verträge wendend.

Ähnlich, wenn eine Routine von einer Klasse in der objektorientierten Programmierung eine bestimmte Funktionalität zur Verfügung stellt, kann es:

• Nehmen Sie an, dass eine bestimmte Bedingung auf dem Zugang durch jedes Kundenmodul versichert wird, das ihn nennt: Die Vorbedingung der Routine — eine Verpflichtung für den Kunden und ein Vorteil für den Lieferanten (die Routine selbst), weil es es davon befreit, Fälle außerhalb der Vorbedingung behandeln zu müssen.
• Versichern Sie ein bestimmtes Eigentum auf dem Ausgang: Die Postbedingung der Routine — eine Verpflichtung für den Lieferanten, und offensichtlich ein Vorteil (der Hauptvorteil, die Routine zu nennen), nach dem Kunden.
• Erhalten Sie ein bestimmtes Eigentum aufrecht, das auf dem Zugang angenommen ist und auf dem Ausgang versichert ist: die Klasse invariant.

Der Vertrag ist die Formalisierung dieser Verpflichtungen und Vorteile. Man konnte Design durch den Vertrag durch die "drei Fragen" zusammenfassen, die der Entwerfer wiederholt stellen muss:

• Was erwartet es?
• Was versichert es?
• Was erhält es aufrecht?

Viele Sprachen haben Möglichkeiten, Behauptungen wie diese zu machen. Jedoch denkt DbC, dass diese Verträge für die Softwaregenauigkeit so entscheidend sind, dass sie ein Teil des Designprozesses sein sollten. Tatsächlich empfiehlt DbC, die Behauptungen zuerst zu schreiben.

Der Begriff eines Vertrags streckt sich unten bis zu das Niveau der Methode/Verfahrens aus; der Vertrag für jede Methode wird normalerweise die folgende Information enthalten:

• Annehmbare und unannehmbare Eingangswerte oder Typen und ihre Bedeutungen
• Geben Sie Werte oder Typen und ihre Bedeutungen zurück
• Fehler und Ausnahme-Bedingungswerte oder Typen, die, und ihre Bedeutungen vorkommen können
• Nebenwirkungen
• Vorbedingungen
• Postbedingungen
• Invariants
• (seltener) haben Leistungsgarantien, z.B für die Zeit oder den Raum verwendet

Unterklassen in einer Erbe-Hierarchie wird erlaubt, Vorbedingungen zu schwächen (aber sie nicht zu stärken) und Postbedingungen und invariants zu stärken (aber nicht schwächen sie). Diese Regeln kommen dem Verhaltenssubschreiben näher.

Alle Klassenbeziehungen sind zwischen Kundenklassen und Lieferant-Klassen. Eine Kundenklasse ist verpflichtet, Anrufe zu Lieferant-Eigenschaften zu machen, wo der resultierende Staat des Lieferanten durch den Kundenanruf nicht verletzt wird. Nachher ist der Lieferant verpflichtet, einen Rückstaat und Daten zur Verfügung zu stellen, der die Zustandvoraussetzungen des Kunden nicht verletzt. Zum Beispiel kann ein Lieferant-Datenpuffer verlangen, dass Daten im Puffer da sind, wenn eine löschen Eigenschaft genannt wird. Nachher versichert der Lieferant dem Kunden, dass, wenn eine löschen Eigenschaft seine Arbeit beendet, der Datenartikel tatsächlich vom Puffer gelöscht wird. Andere Designverträge sind Konzepte der "Klasse invariant". Die Invariant Klassengarantien (für die lokale Klasse), dass der Staat der Klasse innerhalb der angegebenen Toleranz am Ende jeder Eigenschaft-Ausführung aufrechterhalten wird.

Wenn

er Verträge verwendet, sollte ein Lieferant nicht versuchen nachzuprüfen, dass die Vertragsbedingungen zufrieden sind; die allgemeine Idee besteht darin, dass Code hart" mit der Vertragsüberprüfung "scheitern sollte, die das Schutznetz ist. DbC "fehlen hart" Eigentum vereinfacht das Beseitigen des Vertragsverhaltens, weil das beabsichtigte Verhalten jeder Routine klar angegeben wird. Das unterscheidet es deutlich von einer zusammenhängenden als Verteidigungsprogrammierung bekannten Praxis, wo der Lieferant dafür verantwortlich ist sich zu belaufen, was man tut, wenn eine Vorbedingung gebrochen wird. Meistens wirft der Lieferant eine Ausnahme, um den Kunden zu informieren, dass die Vorbedingung, und in beiden Fällen — DbC und Verteidigungsprogrammierung gebrochen worden ist — muss sich der Kunde belaufen, wie man darauf antwortet. DbC macht den Job des Lieferanten leichter.

Das Design durch den Vertrag definiert auch Kriterien für die Genauigkeit für ein Softwaremodul:

• Wenn die Klasse invariant UND Vorbedingung wahr sind, bevor ein Lieferant von einem Kunden genannt wird, dann werden der invariant UND die Postbedingung wahr sein, nachdem der Dienst vollendet worden ist.

Wenn

• es Anrufe zu einem Lieferanten macht, sollte ein Softwaremodul nicht die Vorbedingungen des Lieferanten verletzen.

Weil die Vertragsbedingungen in der Programm-Ausführung nie verletzt werden sollten, kann in ihnen entweder als die Fehler beseitigend bei Code verlassen oder von der Produktionsversion des Codes zusammen aus Leistungsgründen entfernt werden.

Das Design durch den Vertrag kann auch Codewiedergebrauch erleichtern, da der Vertrag für jedes Stück des Codes völlig dokumentiert wird. Die Verträge für ein Modul können als eine Form der Softwaredokumentation für das Verhalten dieses Moduls betrachtet werden.

Beziehung mit der Softwareprüfung

Einheitsprüfung prüft ein Modul in der Isolierung, um zu überprüfen, dass es seinen Vertrag entspricht, der annimmt, dass seine Subunternehmer ihrige treffen. Integrationsprüfung überprüft, ob die verschiedenen Module richtig zusammen arbeiten.

Sprachunterstützung

Sprachen mit der heimischen Unterstützung

Sprachen, die die meisten Eigenschaften von DbC heimisch durchführen, schließen ein:

• Kobra
• D,
• Eiffel
• Festung
• Lisaac
• Quecksilber
• Netter
• RPS-Obix
• Oxygene (früher Chrom)
• Schläger (einschließlich höherer Ordnungsverträge, und betonend, dass Vertragsübertretungen die schuldige Partei verantwortlich machen müssen und so mit einer genauen Erklärung tun müssen)
• Sather
• FUNKEN (über die statische Analyse von Programmen von Ada)

Spec#

• Vala
• VDM

Sprachen mit der Drittunterstützung

Verschiedene Bibliotheken, Vorverarbeiter und andere Werkzeuge sind für vorhandene Programmiersprachen ohne heimisches Design durch die Vertragsunterstützung entwickelt worden:

• Ada, über die MÜCKE pragmas für Vorbedingungen und Postbedingungen. Ada Rapporteur Group bereitet die Einschließung von Unterprogramm-Verträgen (AI05-0145) und Typ invariants (AI05-0146) in der zukünftigen Version von Ada, Ada 201X vor.
• C und C ++, über den DBC für den C Vorverarbeiter, GNU-Trottel, eCv statisches Analyse-Werkzeug oder der Digitale Mars C ++ stellt Bearbeiter, über die CTESK Erweiterung der Bibliothek von C. Loki einen Mechanismus genannt ContractChecker zur Verfügung, der nachprüft, dass eine Klasse Design durch den Vertrag folgt.
• C# (und andere.NET Sprachen), über Codeverträge (ein Projekt von Microsoft Research, das ins.NET Fachwerk 4.0 integriert ist)
• DELPHI PRISMA, sieh

http://edn.embarcadero.com/article/39398

• Irre über GContracts GContracts
• Java, über iContract2, Contract4J, jContractor, Jcontract, C4J, Google CodePro Analytix, STclass, Vorverarbeiter von Jass, der mit AspectJ, Java Modeling Language (JML), SpringContracts für das Frühlingsfachwerk, Modernen Jass, Verwenden von Custos AspectJ, Verwenden von JavaDbC AspectJ, JavaTESK mit der Erweiterung Javas, chex4j oval ist, javassist, oder Verträge für Java und das hoch anpassbare Java auf den Verträgen verwendend.
• JavaScript, über Cerny.js, ecmaDebug oder jsContract.
• Allgemeines Lispeln, über die Makromöglichkeit oder den CLOS metaobject Protokoll.
• Nemerle, über Makros.
• Perl, über die CPAN Modul-Klasse:: Vertrag (durch Damian Conway) oder Karpfen:: Gegebenheit (durch Raphael Manfredi).
• PHP, über ContractLib von Stuart Herbert.
• Pythonschlange, mit Paketen wie zope.interface, PyDBC oder Verträge für die Pythonschlange.
• Rubin, über DesignByContract von Brian McCallister, Rubinroten DBC oder rubinroten Vertrag.
• Tcl, über die XOTcl objektorientierte Erweiterung.

Allgemeine Werkzeuge

• Vollkommener Entwickler, über die Vollkommene Spezifizierungssprache, kann Verträge mit der statischen Codeanalyse nachprüfen und Programme auf Sprachen wie C ++ und Java erzeugen.

Siehe auch

• Teilbasierte Softwaretechnik
• Defensive, programmierend
• Formelle Methoden
• Logik von Hoare
• Modulprogrammierung
• Programm-Verbesserung
• Probegefahrene Entwicklung
• Programm-Abstammung
• Genauigkeit (Informatik)

Referenzen

Bibliografie

• Mitchell, Richard, und McKim, Jim: Design durch den Vertrag: durch das Beispiel, Addison-Wesley, die 2002
• Ein Beschreiben DBC nah zum ursprünglichen Modell.
• McNeile, Ashley: Ein Fachwerk für die Semantik von Verhaltensverträgen. Verhandlungen der Zweiten Internationalen Werkstatt auf dem Verhaltensmodellieren: Fundament und Anwendungen (BM-FA '10). ACM, New York, New York, die USA, 2010. Dieses Papier bespricht verallgemeinerte Begriffe von Contract und Substitutability.

Links

• Eine Einführung, um durch Contract(TM) Zu entwickeln
• Ursprünglicher Artikel IEEE Computer
• Isaac / Lisaac Projekt Haus-
• dlib C ++ Bibliothek
• Javanische Programmierung durch das Vertragsklassendienstprogramm
• GContracts - Programmierung durch den Vertrag mit irrem
• C2 Wiki: Design durch den Vertrag
• Die Klasse von Damian Conway:: Ziehen Sie Perl Modul von CPAN zusammen
• Der Karpfen von Raphael Manfredi:: Gegebenheit Perl Modul von CPAN
• GNU-Trottel
• Digitalvertrag von Mars (DBC) programmierend
• Klassenverträge im Delphi Prisma
• Vertragssprache und Werkzeuge für.NET
• Das Verwenden von Codeverträgen für den sichereren Code
• Vorteile und Nachteile; Durchführung in RPS-Obix