qualitativ hochwertiger Programmcode...

[shoat]

volkard schrieb:

die von programmen gemessenen metriken wie "zeilen kommentar/zeilen code" oder "2 punkte für ein if, 5 für ein while und 6 für ein for und dann punkte pro funktion" taugen nix.

Ein Schwerpunkt meine Arbeit soll evtl. Metriken sein!

Soweit ich es bisher verstanden habe, dann Metriken eine Möglichkeit eine Programmcode mit Hilfe von bestimmten Berechnungsverfahren zu überprüfen. (Ich habe mich noch nicht sehr damit befaßt!)

Warum taugen sie nix? Wie soll ich meinem Auftraggeber begründen, dass die Mühe hier nicht lohnt?

Wäre schön, wenn Du es mir erklären könntest!
Vielen Dank!

Ciao
shoat

[Marc++us]

shoat schrieb:

Wenn Du mal Zeit und Lust hast, würde ich mich sehr freuen, wenn Du einmal mit eigenen Worten beschreiben würdest, was Du unter XP verstehst. Die Beschreibungen in den Büchern sind doch immer etwas umständlich! Vielleicht hast Du ja auch ein paar gute Links bzw. Bücherempfehlungen?

http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
http://www.c-plusplus.net/titelanzeige.php?ISBN=3827318327

[shoat]

Marc++us schrieb:

Für mich tritt Wiederverwendung als Entwicklungsziel ganz klar an letzte Stelle, an erste Stelle setze ich Fehlerfreiheit, dann kurze Entwicklungszeit, dann Wartbarkeit.

Warum ist Wartbarkeit für Dich so unwichtig? Ist es nicht besser, wenn man seinen Code von Anfang an immer so gut wartbar macht wie möglich?

Soweit mir bekannt ist, muss an eigentlich jeder Software nach der Auslieferung beim Kunden noch ewig oft rumgeschraubt werden. Wenn Wartbarkeit aber im Vergleich zu kurzer Entwicklungszeit unwichtig ist, dann wird Kommentierung und Dokumentation zwangsläufig vernachlässigt. Damit wird die nachträgliche Fehlerbehebung erschwert. So ist zwar die Software eher fertig, aber die Service-Kosten steigen. Unter diesem Gesichtspunkt ist schlecht und sogar unwirtschaftlich kurze Entwicklungszeit wichtiger zu nehmen als Wartbarkeit.

Oder ist in der meiner Argumentation ein Fehler?

Allgemein möchte ich noch sagen, dass ich (persönlich) beim Programmieren wesentlich schneller vorankomme, wenn ich den Programmcode gleich mit ordentlichen Kommentare versehe, keine kryptischen Befehle verwende und ich ihn ordentlich gestalte. Und zwar einfach deswegen, weil ich dann selber besser verstehe, warum ich was an eine bestimmten Stelle wie mache. Dieses Verstehen hilft mir dabei weniger Fehler zu machen bzw. Fehler schneller zu finden. Der Mehraufwand für Kommentierung etc. wird also durch die Einsparung bei der Fehlersuche und durch Fehlervermeidung mehr als wettgemacht.

Wie ist es bei Dir?

Viele Grüße!

Ciao
shoat

[shoat]

Hallo Leute,

zuerst mal Danke für die vielen Beiträge!

Wenn ich alles richtig verstanden habe, dann kann man zusammenfassend sagen, dass "guter" Programmcode durch folgende Eigenschaften charakterisiert werden kann:

- Er ist (möglichst) fehlerfrei
- Er ist gut kommentiert / dokumentiert und damit wartbar
- Er hat eine gute Performance / ist schnell
- Er ist plattformunabhängig / leicht portabel
- Er ist (wenigstens teilweise) wiederverwendbar

Einige der Punkte sind bestimmt nicht ganz unstrittig. Aber jeder der Punkte kann je nach Anwendung / Betrieb / Entwickler / Einsatzziel ein Qualitätsmerkmal darstellen!

**Fallen jemanden noch andere wichtige Punkte ein, die in dieser Aufstellung vergessen wurden?
**
Zusätzlich würde ich gerne wissen, was jeder einzelne von Euch dafür tut, dass sein Programmcode die für ihn wichtigen Merkmale erfüllt.

Für zahlreiche Antworten wäre ich abermals sehr dankbar!
Nochmals vielen Dank für Eure Hilfe!

Viele Grüße!

Ciao
shoat

[shoat]

Marc++us schrieb:

shoat schrieb:

Wenn Du mal Zeit und Lust hast, würde ich mich sehr freuen, wenn Du einmal mit eigenen Worten beschreiben würdest, was Du unter XP verstehst. Die Beschreibungen in den Büchern sind doch immer etwas umständlich! Vielleicht hast Du ja auch ein paar gute Links bzw. Bücherempfehlungen?

http://www.c-plusplus.net/titelanzeige.php?ISBN=3827317096
http://www.c-plusplus.net/titelanzeige.php?ISBN=3827318327

Vielen Dank. Ich schau gleich mal rein!

Ciao
shoat

[Marc++us]

shoat schrieb:

Marc++us schrieb:

Für mich tritt Wiederverwendung als Entwicklungsziel ganz klar an letzte Stelle, an erste Stelle setze ich Fehlerfreiheit, dann kurze Entwicklungszeit, dann Wartbarkeit.

Warum ist Wartbarkeit für Dich so unwichtig? Ist es nicht besser, wenn man seinen Code von Anfang an immer so gut wartbar macht wie möglich?

Warte, warte, ich habe Wartbarkeit nicht als unwichtig eingestuft!

Ich habe nur Fehlerfreiheit vor die Wartbarkeit gesetzt...

1. Fehlerfreiheit
   Ganz klar - wenn das Produkt von Anfang an funktioniert, muß ich weniger warten.

2. kurze Entwicklungszeit
   Wenn die Sache zu lange dauert, bekomme ich kein Geld, Leute werden ungeduldig - dann komme ich nie zur Wartung oder Wiederverwendung

3. Wartbarkeit
   Nun darfst Du. Natürlich ist Wartbarkeit wichtig, aber wenn man abwägen muß ist es wichtiger, daß ein Programm fehlerfrei ist, als daß es wartbar ist. Denn wenn es funktioniert, muß man es weniger warten. Wartbarkeit hat für mich kaum was mit Kommentaren zu tun - unter Wartbarkeit verstehe ich ein gutes OO-Design, stabile Klassen, die genau das tun was sie sollen, klare Trennung, und schlanke Schnittstellen, geringe Kohäsion. Dann ist das Programm wartbar. Zur Not sogar mit wenig Kommentaren. Mir bringen Kommentare gar nichts, wenn dafür die Klassen 40 Methoden haben, wo man den Unterschied nicht mehr versteht. Ein gutes Design versteht man intuitiv wenn man es sieht, auch ohne viele Kommentare (durch die Namen, Denkweise, etc). Und ein solches Design ist auch wartbar (d.h. man kann Fehler lokal eingrenzen und neue Funktionen leicht aufbauen).

4. Wiederverwendung
   habe ich schon beschrieben

[Marc++us]

shoat schrieb:

- Er ist gut kommentiert / dokumentiert und damit wartbar

Diese Schlußfolgerung gefällt mir nicht.

Teile es auf:
- er ist gut kommentiert/dokumentiert
- er ist wartbar

Wie zuvor ausgeführt, beruht Wartbarkeit auch auf gutem Design des Programms.

Schlechtes Design mit vielen Kommentaren führt nicht zur Wartbarkeit.

[junix]

@Marcus: Du stellst die Fehlerfreiheit vor die Wartbarkeit. Da wir alle wissen, dass absolute Fehlerfreiheit nie möglich ist, und Wartungseingriffe sowieso nötig sind, würde es da nicht Sinn machen, wenn man die Wartbarkeit und die Fehlerfreiheit zumindest auf die selbe Stufe stellt, wenn nicht sogar die Wartbarkeit höher bewertet?

-junix

[Marc++us]

junix schrieb:

@Marcus: Du stellst die Fehlerfreiheit vor die Wartbarkeit. Da wir alle wissen, dass absolute Fehlerfreiheit nie möglich ist, und Wartungseingriffe sowieso nötig sind, würde es da nicht Sinn machen, wenn man die Wartbarkeit und die Fehlerfreiheit zumindest auf die selbe Stufe stellt, wenn nicht sogar die Wartbarkeit höher bewertet?

-junix

Das mag ich aus psychologischen Gründen nicht. Damit schafft man von Anbeginn an eine Rechtfertigung für Fehler, nach dem Motto "das wird sowieso nicht laufen, das weiß ja jeder, war schon immer so".

Das kann ich aus meiner Sicht als Ingenieur nicht akzeptieren, daß man etwas so baut, daß die beim Bauen gemachten Fehler leicht behebbar sind. Wenn Du darüber nachdenkst erkennst Du sicher, daß diese Vorgehensweise irgendwie seltsam ist.

Ich will fordern, daß die Anzahl an Fehlern von Anfang an gering ist. Diese Forderung treibt vor allem die Sorgfalt bei der Entwicklung, was wiederum zu eher robusten und wartbaren Designs führen wird. Wartbarkeit als Folge der Fehlerfreiheit.

[shoat]

Marc++us schrieb:

shoat schrieb:

- Er ist gut kommentiert / dokumentiert und damit wartbar

Diese Schlußfolgerung gefällt mir nicht.

Teile es auf:
- er ist gut kommentiert/dokumentiert
- er ist wartbar

Wie zuvor ausgeführt, beruht Wartbarkeit auch auf gutem Design des Programms.

Schlechtes Design mit vielen Kommentaren führt nicht zur Wartbarkeit.

Ok. Damit kann ich mich gut anfreuden. Ich werde es so in meine Aufzeichnungen übernehmen!

Danke!

Ciao
shoat

[shoat]

Marc++us schrieb:

Ich will fordern, daß die Anzahl an Fehlern von Anfang an gering ist.

Das bringt mich gleich zu meiner Frage von oben zurück.

Wie stellst Du sicher, dass Programmcode möglichst fehlerfrei ist?

Ok, Du testet!

Aber, wie?

Nur so alla: " Da schraube ich hier mal ein wenig rum und probiere da mal ein paar Fälle aus? "

Oder nutzt Du automatische Testtools? Vielleicht hast Du auch selber ein eigenes kleines Testframework? Oder etwas ganz anderes? Oder alles ein wenig?

Wäre für mich unheimlich wichtig zu wissen, wie es damit in der Praxis wirklich aussieht? Vor allem, weil es ja heißt, dass im Allgemeinen fast überall viel zu wenig getestet wird!

Ciao
shoat

[volkard]

shoat schrieb:

volkard schrieb:

die von programmen gemessenen metriken wie "zeilen kommentar/zeilen code" oder "2 punkte für ein if, 5 für ein while und 6 für ein for und dann punkte pro funktion" taugen nix.

Ein Schwerpunkt meine Arbeit soll evtl. Metriken sein!

ich weiß. das steht bereits recht offen im titel der arbeit.

Soweit ich es bisher verstanden habe, dann Metriken eine Möglichkeit eine Programmcode mit Hilfe von bestimmten Berechnungsverfahren zu überprüfen. (Ich habe mich noch nicht sehr damit befaßt!)

ja.

Warum taugen sie nix? Wie soll ich meinem Auftraggeber begründen, dass die Mühe hier nicht lohnt?

beispiel: kommentare pro zeile

double* find(double toFind,double* arr,int size)
{
   for(int i=0;i<size;++i)
      if(arr[i]==toFind)
         return &arr[i];
   return 0;
}

diese funktion krieg offensichlich null punkte, obgleich sie fast perfekt ist.
dafür bekommt aber dieser humbug total viele punkte:

/****************************************************************************
FUNKTION find
Parameter: toFind - Zahl, die gesucht wird
Parameter: arr - Array, das durchsucht wird
Parameter: size - Größe des Arrays
Rückgabewert: Adresse der gefundenen Zahl
Zweck: Diese Funktion such eine Zahl und gibt deren Adresse zurück. Sie gibt 
NULL zurück, wenn keine gefunden wurde.
****************************************************************************/
double* find(double toFind,double* arr,int size)
{
   int i,*result=NULL;
   for(i=0;i<size&&result;++i)
      if(arr[i]==toFind)
         result=arr[i]+i;
   return result;
}

die funktion deklariert i und *result in einer zeile, was unfug ist, weil a) i innerhalb des for lokaler wäre, b) result=NULL ein eigener bedeutungsinhalt ist, der ne eigene zeile verdient, c) result=NULL eh weg sollte, weils umständlich ist. sie hat ne zu große laufbedingung. sie will die adresse des i-ten elements und schreibt iteratorensyntax statt "adresse von a[i]". also einfach nur schlecht lesbar, die funktion.

Und dann soll es noch leute geben, die normalerweise verdammt wenig code erzeugen. die es halt oft schaffen, mit einem zehntel dessen auszukommen, was die kollegen verbraten. allein die kleinheit ist offensichlicher gewaltiger wartungsvorteil. den erkennt aber keine metrik. es werden ja nicht zwei lösungen zum selben problem verglichen und kein bot (und nicht einer von 100 chefs) kann wissen, wieviel code man wirklich braucht.

void Mobile::go(int richtung)
{
   switch(richtung)
   {
      case 0: goNorthWest(); break;
      case 1: goNorth(); break;
      case 2: goNorthEast(); break;
      case 3: goWest(); break;
      case 4: ; break;
      case 5: East(); break;
      case 6: goSouthWest(); break;
      case 7: goSouth(); break;
      case 8: goSouthEast(); break;
   }
}
void goNorthWest()
{
   x-=1;
   y-=1;
}
//..und noch sieben funktionen
//(1*10+8*2)/9==2.9 zeilen pro funktion

zwerfällt bei langem anstarren zu
void Mobile::go(int richtung)
{
int rx=richtung%3-1;
int ry=richting/3-1;
x+=rx;
y+=ry;
}
//4 zeilen pro funktion, schlechter gemetirkt.
[/cpp]

die metriken helfen meiner meinung nach, um zu bewerten, ob idiot a besser codet als idiot b, aber sie sperren reihenweise die sehr guten lösungen aus.

was ist, wenn der, der das MVC-konzept verwendet, um das modell von der oberfläche abzukoppeln, um das modell sogar plattformunabhängig zu haben, das mit einem if pro modellklasse bezahlen muß? die blinden metriken sehen überhaupt nicht, obs was taugt. haben keine ahnung von exceptionsicherheit. geben keinen minuspunkt, weil obige find-funktion, obwohl sie danach schreit, nicht zum template wurde. geben nix auf schlechte kommentare und erst recht nix auf schlechten bezeichner.

deinem chef kannste eigentlich nicht begründen, daß metriken, außer in seltenen spezialfällen nix taugen. immerhin hat er schon davon gehört. und metriken begeistern chefs. endlich ein werkzeug, um den entwicklern da unten mal auf die finger zu schauen.
aber ich kenne deinen chef nicht. er könnte auch der eine von hundert sein.

[junix]

Marc++us schrieb:

Das mag ich aus psychologischen Gründen nicht. Damit schafft man von Anbeginn an eine Rechtfertigung für Fehler, nach dem Motto "das wird sowieso nicht laufen, das weiß ja jeder, war schon immer so".

Du bemerkst vielleicht an meiner Zögerlichen Art, vorzuschlagen, dass die Wartbarkeit stärker bewertet werden sollte, dass ich diesen Gedanken natürlich auch shcon hatte. Wartbarkeit beinhaltet allerdings nicht nur die Behebung von Fehlern sondern auch ggf. die Änderung oder das Hinzufügen von Verhalten und Funktionsweisen, da der Kunde erfahrungsgemäss erst exakt weiss was er will, nachdem er den ersten Kontakt mit dem Entwurf hatte.

Es sollte selbstverständlich nicht als Rechtfertigung für Fehler dargestellt werden. Das macht keinen Sinnn und ist auch blöd. Aber das sollte eigentlich jedem auch klar sein. Ausserdem ist eine fehlerfreie Anwendung ja irgendwo durch auch eine Visitenkarte. "Ah der Kerl schreibt software die im ersten Release bestimmt nicht läuft!" oder "Ah, die Software des Typen läuft immer schon im ersten Release den er in die Hand gibt". Mir persönlich wäre letzteres Bild lieber (auch wenn ich leider weit davon entfernt bin. aber da bin ich selberschuld.)

Fehler sind immer ärgerlich (sowohl für den Produzenten als auch den Konsumenten) und müssen daher immer möglichst vermieden werden. Trotzdem halte ich jeden der behauptet auf Anhieb fehlerfreie Software (komplexer als ein Hello World selbstverständlich (o; ) zu produzieren für einen Aufschneider... Was nicht heissen muss, dass er sich nicht bemüht möglichst fehlerfrei zu arbeiten. Aber wir sind alles menschen. UNd kein System, egal wie gut, sützt vor der Dummheit und Bequemlichkeit der Menschen die es anwenden (sollten). Naja lange rede kurzer sinn: Ich denke nicht, dass man die Heraufstufung der Wartbarkeit als Entschuldigung bzw. Rechtfertigung für Fehler interpretieren sollte... Das wäre ja eine Interpretation ala "ich hab ja nen Pneuhändler, also fahr ich doch einfach über das Nagelbrett drüber" (wobei gilt Pneuhändler = Wartbarkeit bzw. Möglichkeit Probleme zu fixen und Nagelbrett = potentieller Bug) und wer bitteschön denkt schon so?

-junix

[shoat]

@ volkard / Metriken

Ich habe das Problem verstanden. Deswegen werde ich mich mal in das Thema selber kurz einarbeiten, um eine eigene Meinung zu haben. Dabei werde ich immer Deine Warnung im Hinterkopf behalten! In jedem Fall werde ich danach meinem "Chef" die Probleme darlegen. Mal schauen, was er dazu sagt.
(Vielleicht ist er ja der eine von hundert.)

Zum Glück soll mein Hauptschwerpunkt ja auch "automatisertes Testen" sein. Hoffentlich hast Du dagegen nicht auch einen berechtigten starken Einwand.

Vielen Dank für Deinen Beitrag!
Und viele Grüße!

Ciao
shoat

[volkard]

shoat schrieb:

Zum Glück soll mein Hauptschwerpunkt ja auch "automatisertes Testen" sein. Hoffentlich hast Du dagegen nicht auch einen berechtigten starken Einwand.

automatisiertes testen ist klasse.

[Helium]

2. kurze Entwicklungszeit
   Wenn die Sache zu lange dauert, bekomme ich kein Geld, Leute werden ungeduldig - dann komme ich nie zur Wartung oder Wiederverwendung

Genau das ist der Punkt. Ich als Hobbyprogrammierer stehe unter keinerlei Zeitdruck und kann soviel Zeit mit einem wiederverwendbaren Desing verbrauchen, wie ich will.

Wie zuvor ausgeführt, beruht Wartbarkeit auch auf gutem Design des Programms.

Ich würde das "auch" durch "größten Teils" ersetzen.

Wie stellst Du sicher, dass Programmcode möglichst fehlerfrei ist?

Unit-Tests. Unglaublich hilfreich. Ansonten Pre-Konditionen. Postkonditionen sind In C++ meistens nicht ganz so leicht umzusetzen.
Ansonten sind es immer sehr Situatonsabhängige Dinge.

[Windoof]

shoat schrieb:

Vielleicht als Anregung hier gleich mal ein paar Dinge, die mir spontan dazu eingefallen sind.
Qualitativ hochwertiger Code:

ist (möglichst) fehlerfrei -> er funktioniert -> verschiedene Testverfahren anwenden.

Fehlerfrei sollte jeder Code sein, das mit der Funktion ist doppelt gemoppelt.

shoat schrieb:

ist einfach und leichtverständlich geschrieben -> damit er wartbar und von anderen verstanden werden kann -> erreichbar durch gute Kommentierung und Einhaltung von Programmierrichtlinien.

Ich würde einfach sagen: Es sollten so viele Zeilen kommentiert sein, wie möglich und die Variablen sollten sinnvolle Namen haben, z.B. statt Button1 sollte man OK_Button nehmen usw.

shoat schrieb:

wird nur einmal geschrieben und kann dann beliebig oft wiederverwendet werden -> write once use anywhere -> durch Objektorientierung.

Und vor allem sollte es so wenig wie möglich code sein, d.h. kürzen, kürzen, kürzen.

Du solltest nicht so allgemein denken, sondern wirklich ins Detail gehen, denn we willst du sonst 100 Seiten voll kriegen?

[junix]

Windoof schrieb:

Fehlerfrei sollte jeder Code sein, das mit der Funktion ist doppelt gemoppelt.

Nö, wieso? Ich kann fehlerfreien Code schreiben, dessen Funktion bestimmt nicht dem entspricht, was ich eigentlich wollte... Nur dass der compiler drüberrauscht ohne zu meckern, bedeutet nicht, dass der Code richtig ist.

Windoof schrieb:

Ich würde einfach sagen: Es sollten so viele Zeilen kommentiert sein, wie möglich

Soviel Kommentar wie nötig, dünkt mich die bessere Formulierung.

Windoof schrieb:

und die Variablen sollten sinnvolle Namen haben, z.B. statt Button1 sollte man OK_Button nehmen usw.

Selbstredend. denn damit ersparst du dir wieder Kommentare -> Soviel Kommentar wie nötig bzw. selbstdokumentierende Software

Windoof schrieb:

Und vor allem sollte es so wenig wie möglich code sein, d.h. kürzen, kürzen, kürzen.

Kann ich so nicht unterstützen. Wieso extra kryptisch codieren, und dafür 5 Zeilen kommentar schreiben, wenn ich mit ein paar Zeilen mehr code und vielleicht noch ein paar Zwischenvariablen den Code mehr oder weniger selbsterklärend gestalten kann? Es ist ein Abwägen, was wann wieviel sinn macht. Bedenke: Der compiler optimiert auch selber einen grossen Teil des codes...

Windoof schrieb:

Du solltest nicht so allgemein denken, sondern wirklich ins Detail gehen, denn we willst du sonst 100 Seiten voll kriegen?

Es geht wohl nicht darum 100 Seiten zu füllen, sondern um qualitativ guten Inhalt abzuliefern. Und da ist ein Aufbau mit einer Überleitung von Allgmeinen Apsekten zu detailierteren Betrachtungen gar nicht mal so schlecht. Nur kann er die gut selber detailierter betrachten, denn er soll ja die Arbeit selber schreiben. Was er allerdings im Moment macht ist sehrgut: Er holt sich aspekte aus einem grossen Wissens und Ideenpool...

-junix

[shoat]

Hallo Helium!

Helium schrieb:

Wie stellst Du sicher, dass Programmcode möglichst fehlerfrei ist?

Unit-Tests. Unglaublich hilfreich. Ansonten Pre-Konditionen. Postkonditionen sind In C++ meistens nicht ganz so leicht umzusetzen.

Wäre toll, wenn Du mir kurz erklären könntest, was es mit Pre- und Postkonditionen auf sich hat. Ich habe davon noch nie was gehört und auch in den Büchern, die ich lese, gibt es darauf bisher keinen Hinweis. Ich bin auch für einen Link sehr dankbar!

Natürlich habe ich mal auch mal kurz gegooglt, aber unter den deutschen Begriffen gibt es nur zwei Treffer, wo ich den geistreichen Hinweis bekomme, dass es sich um Vor- / Nachbedingungen handelt.
(Einmal im Zusammenhang mit UML-Diagrammen und einmal im Zusammenhang mit dem Compiler.)

Bei den englischen Begriffen ist es uferlos (~ 185.000 Treffer).

Danke für Deine Hilfe!

Ciao
shoat

[Marc++us]

shoat schrieb:

Wäre toll, wenn Du mir kurz erklären könntest, was es mit Pre- und Postkonditionen auf sich hat. Ich habe davon noch nie was gehört und auch in den Büchern, die ich lese, gibt es darauf bisher keinen Hinweis. Ich bin auch für einen Link sehr dankbar!

Change books.

Auszug:

*Beschreibung von Vor- und Nachbedingungen
Ein üblicher und sehr hilfreicher Ansatz bei der Dokumentation von Verhalten jeglicher Art ist die Einführung von Vor- und Nachbedingungen. Dieser Ansatz kann zusammen mit anderen textbasierten Methoden, aber auch mit grafischen Ansätzen verwendet werden.

 Vorbedingung: eine Vorbedingung ist eine Aussage, die das Gesamtgebilde erfüllen muss bevor ein Verhalten abläuft. Die Existenz dient dazu sicherzustellen, dass das Verhalten wie geplant ablaufen kann. Zum Beispiel muss zur Absage einer Zimmerreservierung zunächst eine erfolgreiche Zimmerreservierung erfolgt sein, und Sie müssen dabei die Person sein, die das Zimmer reserviert hatte.

 Nachbedingung: eine Nachbedingung ist eine Aussage, die erfüllt sein muss nachdem ein Verhalten erfolgreich abgelaufen ist. Zum Beispiel ist nach erfolgreicher Stornierung einer Zimmerreservierung der Raum als frei gekennzeichnet und die Belastung der Kreditkarte wurde annulliert.

 Invariante: abgesehen von Vor- und Nachbedingungen müssen Sie Invarianten («Unveränderliche») garantieren - Bedingungen die vor und nach der Ausführung eines Verhaltens erfüllt sind. Zum Beispiel ist die Anzahl der Personen pro Raum an einem bestimmten Tag niemals kleiner 0.

Invarianten sind echte Bedingungen, die immer wenn ein anders Objekt auf das ausführende Objekt schaut erfüllt sind. Bei Multithreading-Systemen, wo ein Objekt mehr als eine Operation gleichzeitig ausführen kann, ist es möglich dass ein Objekt eine Operation ausführt und gleichzeitig sein Status abgefragt wird. Das bedeutet, dass die Invariante niemals, nicht einmal kurzfristig, verletzt werden darf.

Wenn Sie einen vollständigen Satz an Vor- und Nachbedingungen für ein Verhalten abliefern, definieren Sie das Verhalten ohne Annahmen über das Design zu treffen. Jeder Aufrufer des Verhaltens oder der Operation versucht sicher zu stellen, dass die Vorbedingungen erfüllt sind bevor er das Verhalten aufruft. Danach garantiert das aufgerufene Objekt, dass die Nachbedingungen erfüllt werden - nachdem das Verhalten beendet ist. Dieser Ansatz wird manchmal auch als Design-by-Contract (nicht wörtlich übersetzbar, sinngemäß ein Design nach Absprache) bezeichnet. Hiermit wird dem Designer erlaubt, dass er tut was er will, solange er die Absprachen einhält.*