Einleitung

Qualitätssicherung sollte sich durch die ganze Projektlaufzeit (von der Analyse bis zur Wartung) durchziehen. Qualitätssicherung in der Implementierungsphase ist sehr schwierig, falls die Analyse fehlerhaft oder unvollständig durchgeführt wurde. Nichtvorhandene oder lückenhafte Analysedokumente sollten uns aber nicht dazu verleiten, auf Qualitätsicherung während der Implementation zu verzichten.

Der Source Code sollte folgenden Ansprüchen genügen:

• Korrektheit
• Vollständigkeit
• Erweiterbarkeit
• Wartbarkeit
• Wiederverwendbarkeit

Korrektheit und Vollständigkeit sind ohne ordentliche Analysedokumente schlecht nachweisbar und messbar.

Erweiterbarkeit und Wartbarkeit sind oft eine Frage des Programmier und Designstils der erlernbar ist. Die im Anhang angegebene Smalltalk Inspektionsliste, sowie das Werkzeug SmallLint helfen die häufigsten Stilfehler zu vermeiden.

Wiederverwendbarkeit erhält man i.a. nicht ohne extra Zeitaufwand. Am Ende eines Projektes sollte ein erfahrener Mitarbeiter aus dem vorhandenen Code "Software-Werkzeuge" bauen und dokumentieren.

Qualitätsmanagement

Code Inspektion sollte erfolgen:

• bevor eine Softwarekomponente freigegeben wird.
• sobald eine gewisse Qualität garantiert werden muss.
• (z.B vor dem Besuch des Kunden, oder der Mitarbeiter in Urlaub geht).
• auf Wunsch eines Mitarbeiters, falls er selbst über Korrektheit seines Codes unsicher ist.
• nach ca. 2 höchstens 4 Implementierungswochen (bei Anfaenger öfters, bei Profis seltener).
• Der Zeitpunkt der Inspektion sollte frühzeitig bekannt gegeben werden, so daß sich der Mitarbeiter vorbereiten kann.

Es wird der SourceCode eines Mitarbeiters, sowie die dazugehörige Dokumentation auf die obengenannten Qualitätskriterien überprüft. Die gefundenen Fehler sollten schriftlich festgehalten, und im nächsten Inspektionsprozess nochmals überprüft werden.

Es sollte nicht die Leistung des Mitarbeiters sondern die Qualität des Codes bzw. Dokuments kontrolliert werden. Die Aufgabe der CodeInspektion kann auch sein, neue Mitarbeiter einzuweisen. (z.B vor Urlaubsvertretung).

Eine Inspektion hat nur Sinn, wenn definiert ist, welcher Mitarbeiter für welche Klassen bzw. Applikationen verantwortlich ist.

An einer Code-Inspektion sollten mindestens 2, aber höchstens 5 Mitarbeiter teilnehmen:

• Der Autor des Codes
• Der Projektverantwortliche
• Mitarbeiter die den Code ggf. ergänzen bzw. ändern oder zur Verwendung verstehen müssen.

Für die Mitarbeitere die den Code verwenden müssen reicht aber oft eine klar definierte Schnittstelle aus.

Der Inspektionsprozeß

Der Autor sollte vor der Inspektion, alle betroffenen Klassen und Applikationen versionieren, und entsprechend kennzeichnen (z.B.: für Review 1.1.0 ). Sollten gleichzeitig mehrere Applikationen getestet werden, kann eine neue ConfigurationMap erzeugt werden.

Fehler bzw. Verbesserungsvorschlaege, die während der Inspektion auftreten, können gleich im Notizenfeld von Envy protokolliert werden. Die gefundenen Fehler sollten in folgende 3 Prioritätsklassen eingeteilt werden:

Klassen und Applikationen sollten nur freigegeben, falls sie keine Fehler vom Typ S und I enthalten.

Eigene Kommentare zu der Inspektions Checkliste im Anhang:

Gerade Envy erlaubt es Basis-Klassen in eigenen Applikationen erweitern, und man sollte als Programmierer auch den Mut besitzen, davon Gebrauch zu machen. Allerdings sollte das Verhalten von bekannten Methoden nicht verändert werden.

Zu 2) Das Law of Demeter

Zu Vermeiden sind Ausdrücke der folgenden Form:

self attribute nextAttribut anotherAttr add: anObject.

Sende Nachrichten nur an:

• Sich selbst
• Parameter der Methode
• Instanzvariable
• Falls die Instanzvariable eine Collection enthaelt, einem Element der Collection.

Klassenkommentare sollten Pflicht sein. Dazu gehört eine Kurzbeschreibung der Klasse. (Wenn man nicht in wenigen Sätzen ausdrücken kann, was die Aufgabe der Klasse ist, so deutet dies auf einen schlechten Design hin). Danach erfolgt eine Beschreibung der Instanz- und Klassenvariablen (Namen der Variable, Welche Werte sie annehmen koennen und Kurzbeschreibung). Sinnvoll ist auch die Beschreibung mit welchen Klassen sie

zusammenarbeiten (Im Sinne von CRC-Cards).

Methodenkommentare sind in den meisten Fällen unnötig , falls die Namen der Methoden und Parameter sinnvoll gewählt sind. Dazu kommt, daß die Länge einer Methode nicht grösser als 10 Zeilen sein soll. Ist eine Methode ohne Kommentar nicht zu verstehen, so deutet es auf einen schlechten Design hin. Trotzdem gilt: Lieber einen Kommentar zuviel als einen Kommentar zuwenig.

Bsp:

Tabelle<<editiere: aZeile

(aZeile isMemberOf: UeberschriftsZeile ) ifTrue: [ Screen default bell ].

(aZeile isMemberOf: FesterKommentarZeile) ifTrue: [Screnn default bell].

(aZeile isMemberOf: EditierZeile) ifTrue: [ aZeile editiere ].

Besser ist folgende Version

UeberschriftsZeile<< isEditierbar

^false

FesterKommentarZeile<< isEditierbar

^false

EditierZeile<< isEditierbar

^true

Tabelle<<editiere: aZeile

aZeile isEditierbar ifTrue: [ aZeile editiere]

IfFalse: [ Screen default bell].

Mit der Methode become: kann man die internen ObjektId’s zweier Objekte austauschen:

Beispiel: ApplicationWindows allInstances do: [ :each | each become: String new ].

Dies ist ein Beispiel das angewendetet werden kann, falls das Image gewachsen ist, weil die ApplicationWindows nicht sauber aufgelöst wurden. Achtung: Die Methode become: sollte nie innerhalb eines Programms aufgerufen werden, hoechstens für das TroubleShooting in einem unsauberen Image.

Zu 35) Klassen die nil als Oberklassen haben,

Dies ist in Smalltalk durchaus möglich und in äusserst seltenen Fällen durchaus gewollt. Damit wird verhindert, dass ein Objekt Methoden versteht, die in der Klasse Object implementiert sind.

• Kent Beck: Smalltalk Best Practice Patterns, Prentice Hall ISBN: 0-13-476904-X

• Klimas, Edward J. u.a: Smalltalk with Style, Prentice Hall ISBN 0131655493

• Smalltalk Report: besonders Kolumne Smalltalk Idioms von Kent Beck