Auch wir mussten uns mit der Frage befassen, wie die gemeinsame Arbeit in einem Entwicklungs-Projekt effizient koordiniert werden kann. Der sonst übliche Einsatz eines Versions-Kontroll-Systems wie CVS/RCS oder PVCS scheitert an der Vielzahl der im SAS-System verwendeten binären Formate (Frame, SCL, Format und Informat usw.) und ihrer Speicherung in SAS-Katalogen. Die SAS-Lösungen, z.B. SCM, decken nur einen Teil der Anforderungen ab. Notwendig ist aber eine integrierte Lösung, die mindestens folgende Anforderungen erfüllt:

• checkout / checkin für alle Dokumente und Programmteile, .B. Auch Installations- und Benutzeranleitungen.

• zentrale Speicherung wiederverwendbarer Elemente und projektspezifische Erstellung von Test- und Produktions-Versionen,

• platformübergreifende Lösung – alle Betriebssysteme müssen als Entwicklungs- und Test-Platform unterstützt werden.

Für uns kommt hinzu:

• Unterstützung von Notebooks, d.h. Entwickler können zeitweise auch außer Haus arbeiten,

• Unterstützung bei der technischen Dokumentation,

• effizientes Change-Management, d.h. Änderungen und Weiterentwicklungen müssen mit ihrem Anlass und Status protokolliert werden.

Mit unseren „xTools“ (xManager, XDWH, xRef, xMaintenance und xTools-Reporter) ist es uns gelungen diese Anforderungen weitgehend zu erfüllen.

Dank unserer langjährigen Erfahrung mit Dokumentations-Tools (die erste Version von xRef wurde bereits 1994 vorgestellt) und der konsequenten Verbindung von eigenem Training und sinnvollen Ergebnissen ist es uns gelungen, mit vertretbarem Aufwand eine zufrieden stellende Eigenentwicklung zu realisieren.

Der xManager

Der xManager ist unsere zentrale Applikation für die Teamarbeit. Mit ihm haben wir uns eine platformübergreifende Umgebung geschaffen, so dass wir auf verschiedenen Betriebssystemen am selben Projekt gemeinsam entwickeln und testen können.

Auf der Grundlage von SAS/Connect implementiert der xManager eine zentrale Verwaltung aller SAS-Objekte sowie zusätzlicher Text- und Binärdateien – z.B. auch Java-Archive und Office-Dokumente. Ein checkout/checkin-Mechanismus stellt sicher, dass ein Objekt⁽¹⁾ immer nur von einem Mitarbeiter bearbeitet wird. Eingecheckte Objekte werden automatisch an alle anderen Arbeitsplätze verteilt. Damit sich Entwickler beim Testen nicht gegenseitig behindern (und zur Sicherstellung der platformübergreifenden Entwicklung), ist es notwendig, dass die Entwickler immer über eine aktuelle, schreibgeschützte Kopie des Server-Bestands verfügen.
Einzige Ausnahme sind das Datenmodell aus XDWH und die dort modellierten Dateien, die zentral gehalten werden.

Der xManager unterstützt die Wiederverwendung von Objekten, indem Projekte definiert und die Objekte diesen Projekten zugeordnet werden. Daraus lässt sich dann automatisiert eine Testversion extrahieren, die nach dem erfolgreichen Abschluss der Tests zusammen mit dem aktuellen Stand der begleitenden Dokumente versioniert und ausgeliefert wird.

Anmerkung:

(1) Mit Objekt wird hier jedes Teil eines Informationssystems bezeichnet. Das mag für jemanden, der aus der objektorientierten Anwendungsentwicklung kommt seltsam anmuten. Aber bei der Konzeption einer Entwicklungsumgebung werden Programme, Dateien, SAS-Formate, Variablen, Indizes usw. verwaltet. Und in dieser Verwaltung erscheinen sie alle als Instanzen von Klassen, deren gemeinsame Oberklasse "Teil des Systems" heißen könnte. Für diese Oberklasse lassen sich eine Reihe von Anforderungen spezifizieren, die nachher für alle Teile der Anwendung gelten. Es ist deshalb durchaus nahe liegend, alles, was von einer Entwicklungsumgebung verwaltet wird, als Objekt zu betrachten, und die Umgebung selbst objektorientiert zu modellieren, auch wenn die Implementierung dann prozedural oder hybrid erfolgt.

Das Dokumentations-Tool xRef

Viele Style-Guides für Programme sehen vor, dass die Verwendung von Objekten (Dateien, Formate, Macros, Macro-Variablen, Methoden, Klassen usw.) im Kommentar-Kopf dokumentiert wird. Das ist aber aus verschiedenen Gründen nicht ausreichend:

• Bei wiederverwendbaren Modulen (Klassen, Macros etc.) muss zumindest ihre Verwendung außerhalb des Codes erfasst werden. Schließlich soll der Code nicht verändert werden, nur weil z.B. das Macro auch noch woanders verwendet wird.

• Viele Verwendungen (insb. manche Macro-Variablen, Formate, Methoden-Aufrufe, temporäre Dateien) sind zu unbedeutend, um im Kommentar-Kopf aufgeführt zu werden, würden diesen aufblähen und von Wichtigem ablenken.

• Die getrennte manuelle Erfassung ist fehleranfällig – insbesondere bei späteren Änderungen. Auch der räumliche Abstand zwischen dem Kopf und der entsprechenden Stelle in einem längeren Programm begünstigt Fehler.

• In binären Objekten wie Class- und Frame-Entries lassen sich solche Kommentare nicht unterbringen.

Bei XRef, unserem Cross-Reference-Tool, setzen wir deshalb konsequent auf die automatische Analyse von Kommentaren und Code. Dabei unterscheiden wir zwischen Verwendungen (Aufrufen, Macros, Macro-Variablen), die nur im Code vorkommen, und solchen, die zusätzlich in einem Kommentar aufgeführt sind. Die Kommentare können dabei im Kommentarkopf und/oder an der jeweiligen Stelle im Code stehen.

Das Datenmodellierungs-Tool XDWH

XDWH ist ein Teil unseres Konzepts zur Planung und Dokumentation eines DWH und wurde schon 1999 auf der SEUGI und der DISK vorgestellt. Kerngedanke ist, dass eine einheitliche Verwendung von Namen dann erreicht wird, wenn Variablen und Indizes in einem Repository definiert und dokumentiert werden. Die Dateien werden aus diesen Variablen zusammengesetzt. Der Code zur Erstellung der leeren bzw. Aktualisierung von existierenden SAS-Dateien wird dann automatisch generiert.

Neben einer konsistenten Verwendung von Namen wird dadurch auch erreicht, dass Formate, Variablen und Indizes zentral gepflegt werden können, und sich Änderungen automatisch auf alle Dateien auswirken.

Die Dateien lassen sich zu „Bereichen“ (Subjects und Prozesse) zusammenstellen. Zu diesen Bereichen können auch ER- und Datenfluss-Diagramme erzeugt werden.

XDWH ist multi-user-fähig. D.h. es unterstützt ein Concurrent-Update des Datenmodells und implementiert ein der jeweiligen Situation entsprechendes Locking.

Bei der Erstellung der Dokumentation werden auch die Ergebnisse der xRef-Analyse berücksichtigt und mit ausgegeben.

Change-Management mit xMaintenance

Zum Lebenszyklus einer Anwendung gehört die Beseitigung auftretender Fehler und die Weiterentwicklung. Diese Änderungen können nur nachvollzogen werden, wenn ihre Dokumentation in die Dokumentation der Anwendung integriert wird. Bei unserer 1995 auf der SEUGI erstmals vorgestellten Lösung implementieren wir

• die Erfassung der Anforderung (bzw. des Fehlers),

• die Beschreibung der Lösung und eine Liste der geänderten oder neu erstellten Objekte,

• die Zusammenstellung der Änderungen zu einer oder mehreren Anforderungen in Paketen und

• die Integration dieser Informationen in das Dokumentations-System zu xRef.

Die neue Version ist zur Zeit in Arbeit und wird eine Erfassung der Anforderungen über das Intranet (Browser) sowie eine Integration in den xManager beinhalten. Dazu soll auch die Erfassung von speziellen Hinweisen zu Dateien, Variablen und Programmen kommen, die dann in der Dokumentation mit ausgegeben werden.

Die Ausgabe der Dokumentation mit dem xTools-Reporter

Nach dem Erstellen der Test- oder Produktions-Version einer Anwendung sollten sich auch die dazu gehörenden Dokumente nicht mehr ändern (bis auf Test- und Fehler-Protokolle). Bei der Auslieferung reichen deshalb auch für die automatisch erstellte Dokumentation statische Dateien.

In der Entwicklungsphase ist es aber wichtig, dass auch die technischen Beschreibungen zu den einzelnen Objekten immer auf dem aktuellen Stand gehalten werden und leicht verfügbar sind. Deshalb müssen alle eingecheckten Objekte regelmäßig (bei uns automatisch in der Nacht und manuell bei Bedarf) analysiert werden. Die Ergebnisse dieser Analysen werden aber nur in der xTools-Datenbank gespeichert. Die eigentlichen Dokumente werden bei der Abfrage dynamisch über ein Servlet und HTMLOUT (unserer Implementierung für „Server-Pages“ in SAS) erzeugt. U.a. wird damit sicher gestellt, dass immer alle aktuellen Verwendungen eines Objekts ausgegeben werden. Andernfalls müssten auch die Seiten für Objekte neu erstellt werden, die selbst nicht geändert wurden.

Das Servlet ist so ausgelegt, dass statische (manuell erstellte) Dokumente und dynamisch zu erzeugende Seiten kombiniert werden können. Dabei können für Links auf dynamisch erstellte Dokumente normale HTML-Pfade verwendet werden, die nach der Erstellung der vollständigen statischen Dokumentation nicht mehr angepasst werden müssen.

Status und Verfügbarkeit

Mit Ausnahme von xMaintenance, das nur für die SAS-Version 6 zur Verfügung steht und zur Zeit neu entwickelt wird, werden alle Tools intern produktiv eingesetzt.

Der xManager, das Dokumentations-Tool xRef und der xTools-Reporter sind vollständig getestet und können nach der Fertigstellung von Installations- und Benutzeranleitung ausgeliefert werden. Der strukturierte und modulare Aufbau ermöglicht die flexible Anpassung an unterschiedliche Bedingungen. Z.B. kann die Verarbeitung von Kommentaren an die Konventionen des Unternehmens angepasst werden. Auch der Umfang und das Layout der Ausgaben des xTools-Reporters lassen sich unternehmens-spezifisch gestalten.

In XDWH fehlen noch einige Features der Vorgänger-Version. Z.B. wäre es wünschenswert, die Struktur bestehender Datenbanken automatisch zu importieren.