Open Source im professionellen Einsatz

Newsletter abonnieren
Seite durchsuchen

HEFTARCHIV | NEWS | E-BIBLIOTHEK | VIDEO | BLOGS | WHITEPAPER | EVENTS | ACADEMY | ABO | SHOP

user friendly

  Home  »  Heft & Abo  »  Heftarchiv  »  2006  »  09  »  Ingenieurskunst  

RSS-Feed der aktuellen News von Linux-Magazin Online Folgen Sie Linux-Magazin Online auf Twitter
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark

Design by Contract

Eines der zentralen Konzepte von Eiffel heißt Design by Contract. Der so genannte Vertrag (Contract) beschreibt die Zusammenarbeit der einzelnen Softwarekomponenten eines Systems mit Hilfe präziser Zusicherungen, also semantischer Bedingungen.

Wie im echten Leben hat auch beim Design by Contract der Anbieter Verpflichtungen gegenüber dem Kunden und umgekehrt. Nur sind eben in der Softwarewelt Anbieter und Kunden Softwarekomponenten. Vorteile von Design by Contract sind:

  • Es hilft während der Implementation, weil die
    Zusicherungen gleichzeitig als Spezifikation der Software
    dienen.
  • Verträge unterstützen die Entwicklung korrekter
    Software. Mit Design by Contract denkt der Programmierer über
    die Anforderungen jeder Routine nach und setzt diese in
    Programmcode um.
  • Verträge dienen als Basis für die Dokumentation.
    Eiffelstudio zum Beispiel generiert die Dokumentation automatisch
    aus den Verträgen (»Project | Generate
    Documentation«).
  • Mit Verträgen ist es einfacher, Fehler in einem Programm
    zu finden, weil die Ausführung an der Fehlerstelle stoppt.
    Autotest [10] erstellt aus den Verträgen automatisch
    Tests.

In Eiffel gibt es drei Hauptkategorien von Vertragsbedingungen: Klasseninvarianten (»invariant«), Vorbedingungen (»require«) und Nachbedingungen (»ensure«). Weitere Vertragsbedingungen sind Check-Instruktionen, Schleifeninvarianten und -varianten.

Bei allen Vertragsbedingungen bestehen die Zusicherungen aus einer Kennzeichnung (Tag) und einem booleschen Ausdruck der Form Kennzeichnung:Boolescher_Ausdruck. Das Tag ist optional, aber zur Dokumentation und zum Debuggen sehr nützlich.

Normalerweise prüft Eiffelstudio nur Vorbedingungen. Um auch die anderen Zusicherungen zu kontrollieren, müssen Sie sie unter »Project | Project Settings« und »Default assertions« aktivieren.

Klasseninvarianten müssen gelten, sobald eine Instanz der Klasse erzeugt ist und anschließend vor und nach der Ausführung von beliebigen Features der Klasse. Diese Regel gilt nur für qualifizierte Aufrufe der Form Objekt.Routine. Unqualifizierte Aufrufe der Form Routine und Aufrufe von nicht exportierten Features müssen die Klasseninvariante nicht bewahren. Die Klasse »HELLO« besitzt die Invariante, dass das Attribut »name« nie auf »Void« zeigen (Listing 1, Zeile 43) und nie leer sein darf (Zeile 44).

Bedingungen in Routinen

Vor- und Nachbedingungen kommen in Routinen zum Einsatz, die folgende Struktur besitzen:

name (argument_1: TYP_1; argument_2: TYP_2):RUECKGABE_TYP is
    -- Kommentar
  do
    ... -- Implementation
  end

Nach dem Namen der Routine steht in Klammern eine optionale Liste von Argumenten. Falls es sich bei der Routine um eine Funktion handelt, folgt nach einem Doppelpunkt der Typ des Rückgabewerts und schließlich das Schlüsselwort »is«. Der Kommentar einer Routine ist zwar optional, ihn einfach wegzulassen gilt aber in der Eiffel-Welt als äußerst schlechter Stil.

Die Implementation der Routine beginnt mit dem Schlüsselwort »do« und endet mit »end«. Startet sie mit »once« statt mit »do«, läuft die Routine während der Ausführung des Systems nur beim ersten Aufruf tatsächlich ab - unabhängig davon, wer der Aufrufer war. Spätere Aufrufe vom selben oder einem anderen Aufrufer zeigen keinen Effekt. Ist die Routine eine Funktion, gibt sie immer das Resultat zurück, das sie beim ersten Aufruf berechnet hat. Zudem gibt es noch die optionalen Blöcke »local«, »require« und »ensure«.

Die Zeile 12 von Listing 1 definiert die Routine »make«, die ohne Argumente und Rückgabewert auskommt. Die Prozedur ruft das Feature »set_name« mit einer Zeichenkette als Argument auf (Zeile 15). Die Routine »greeting« (Zeile 23) gibt einen »STRING« zurück. Die Spezialvariable »Result« referenziert den Rückgabewert einer Funktion. Handelt es sich dabei um einen erweiterten Typ, enthält »Result« direkt das Objekt.

»Result« wird beim Eintritt in die Funktion mit dem Standardwert des Rückgabetyps (Tabelle 1) initialisiert. Zeile 26 weist »Result« die Zusammensetzung aus »"Hello, "«, dem Rückgabewert der Query »name« und »"!"« zu. Die Syntax einer Zuweisung in Eiffel ist Variable := Wert. Das Gleichheitszeichen prüft, ob zwei Referenzen identisch sind.

Tabelle 1:
Standardwerte für die Initialisierung von Typen

 

Typ

Initialisierungswert

»INTEGER«, »REAL«,
»DOUBLE«

»0«

»BOOLEAN«

»False«

»CHARACTER«

»'%U'« (NUL)

Referenztypen wie »STRING« und
»HELLO«

»Void«

Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark
Ähnliche Artikel
Verwandlungskünstler C- und C++-Entwicklung mit Eclipse
Here comes the sun Suns Java-Entwicklungsumgebung Netbeans
Babylon zu fünft Populäre Programmiersprachen treten gegeneinander an
Junge Pinguinbande Linux Tools für Eclipse
Babylon zu fünft Populäre Programmiersprachen treten gegeneinander an
Konservierungsmittel Objektdatenbank Db4o für Java und Mono
Whitepaper
Daten Migration - Eine Publikation von Bloor Research

Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.

Download PDF (Registrierung erforderlich)
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele

Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.

Download PDF (Registrierung erforderlich)
Kommentare (0)