Werkzeugunterstützung für die Erstellung einer quellcodegebundenen Dokumentation für Aspekte in Softwaresystemen

Tesis , 2004 , 127 Páginas , Calificación: gut

Ciencias de la computación - Software

Diese Arbeit befasst sich mit Gesichtspunkten der Softwareentwicklung, die direkten oder indirekten Einfluss auf das Verständnis von Quellcodes haben. Ein Ziel der Darstellung ist es, Probleme bei der Entwicklung von Softwaresystemen und im speziellen bei der Wartung von Software aufzuzeigen. Wichtige Eckpunkte stellen dabei die Dokumentation von Softwaresystemen und die gedankliche Gliederung von Softwaresystemen in Aspekte dar. Ein Aspekt stellt eine gedanklich kapselbare Einheit von Verhalten dar.

Darüber hinaus wird eingegangen auf relevante Randbedingungen, die die Dokumentation, das bedeutet die Wissensbewahrung, beeinflussen. Dazu gehören beispielsweise Softwareentwicklungsprozesse, Normen und die Teamarbeit. Dabei wird nicht außer Acht gelassen, dass die Qualität von bewahrten Informationen und Wissen maßgeblich durch die beteiligten Personen geprägt wird. Ziel ist es, Kernfaktoren aufzuzeigen, die grundlegenden Einfluss auf das Verstehen von Softwaresystemen haben. Es wird ein technischer Lösungsansatz skizziert, der zu einer Verbesserung der Dokumentationsmöglichkeiten von Softwaresystemen führt.

Der praktische Teil der Arbeit beinhaltet die prototypische Umsetzung wichtiger vorgestellter Ansätze zur Dokumentation von Quellcode. Die Lösung besteht aus einem Softwarepaket, das sich in den Implementierungsprozess von Java Anwendungen integrieren lässt. Die Integration in den Implementierungsprozess wird durch die Einbindung in die Softwareentwicklungsumgebung Eclipse und die Erweiterung von SnipSnap, einem einfachen Content Management System realisiert. Es ermöglicht eine einfache Bedienung während der Implementierung.

Inhaltsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung

2 Hintergrund
2.1 Dokumentation von Softwaresystemen in der Softwareentwicklung
2.1.1 Dokumentation während der Implementierung
2.1.2 Typische Probleme im Rahmen der Wartung und Weiterentwicklung von Softwaresystemen
2.2 Qualitative Anforderungen an Softwaresysteme und deren Management
2.2.1 Einflussfaktoren auf die Dokumentation von Softwaresystemen während der Implementierung
2.2.2 Weiterentwicklung und Wartung von Software
2.3 Vorgehensmodelle in der Softwaretechnik
2.3.1 Betrachtung derunterschiedlichenVorgehensmodelle
2.3.2 Zusammenfassung
2.4 Einwirkungen des Menschen und des Arbeitsumfeldes auf die Dokumentation in der Softwareentwicklung
2.4.1 Mensch
2.4.2 Teamarbeit
2.4.3 Arbeitgeber
2.4.4 Kunde
2.4.5 Einflüsse des Arbeitsumfeldes auf die Erstellung einer Dokumentation
2.5 Informationsmanagement und Wissensmanagement in der Softwareentwicklung
2.5.1 Implementierung und Wartung
2.6 Zusammenfassung

3 Konzept einer quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen
3.1 Quellcodegebundene Dokumentation
3.2 Dokumentation von Aspekten in Softwaresystemen
3.3 Dokumentationselemente zum Bewahren von Wissen und Informationen
3.3.1 Dokumentationsvorlagen
3.4 Zusammenfassung

4 Technischer Lösungsansatz
4.1 Hypertext - Dokumentation
4.2 Quellcodegebundene Dokumentation
4.2.1 Abstrakter Syntaxbaum
4.2.2 Java-Quellcode in XML
4.2.3 Eudibamus
4.2.4 Funktionales Verhalten der Werkzeugunterstützung
4.2.5 Entscheidung
4.3 Zusammenfassung

5 Prototypische Umsetzung
5.1 Formularvorlagen in SnipSnap
5.1.1 Grundlegende Funktionsweise von SnipSnap
5.1.2 Erweiterungsmöglichkeiten von SnipSnap durch Makros
5.1.3 Formularansicht
5.1.4 Wissensmodell
5.2 Integration in die Entwicklungsumgebung
5.3 Anwendungsbeispiele
5.3.1 Implementierungsphase
5.3.2 Analyse- und Wartungsphase
5.4 Umsetzungen der Anforderung
5.5 Installation des Systems

6 Zusammenfassung - Fazit

7 Anhang
7.1 Abbildungsverzeichnis
7.2 Begriffsverzeichnis
7.3 Literaturverzeichnis

1 Einleitung

Softwareentwickler müssen derzeit möglichst schnell ihnen teilweise unbekannte Software­systeme verstehen, um geeignet auf die Wünsche der Kunden reagieren zu können. Das ist eine hohe Anforderung an die Wartbarkeit und Erweiterbarkeit bestehender Softwaresysteme. Den zentralen Punkt für das Verständnis von Softwaresystemen stellen die Dokumentation ei­nes Softwaresystems und der Quellcode dar. Die Dokumentation spiegelt die Bewahrung der Informationen und des Wissens zu Softwaresystemen und Systemteilen wider, wohingegen der Quellcode die technische Verwirklichung repräsentiert. Zwischen der Dokumentation und dem Quellcode kommt es zu einem Bruch des Informationsflusses, da zwischen den beiden Elementen meist keine direkte Verbindung existiert. Diese Problematik wird in den Kapiteln 2.1 „Dokumentation von Softwaresystemen in der Softwareentwicklung“ und 2.5 „Informati­onsmanagement und Wissensmanagement in der Softwareentwicklung“ dargelegt. Darüber hi­naus werden mögliche Einflüsse auf die Dokumentation im Kapitel 2.3 „Vorgehensmodelle in der Softwaretechnik“ und Kapitel 2.4 „Einwirkungen des Menschen und des Arbeitsumfeldes auf die Dokumentation in der Softwareentwicklung“ verdeutlicht. Die Dokumentation eines Softwaresystems kann wiederum auf die qualitativen Merkmale des Softwaresystems selbst Einfluss haben, dadurch dass Informationen und Wissen aus der Dokumentation für die Wei­terentwicklung und Wartung des Systems genutzt werden. Im Kapitel 2.2 „Qualitative Anfor­derungen an Softwaresysteme“ wird diese Abhängigkeit veranschaulicht.

Eine Lösungsidee, den dargestellten Informationsflussbruch zwischen Dokumentation und Quellcode zu überbrücken, wird in Kapitel 3 „Konzept einer quellcodegebundenen Dokumen­tation von Aspekten in Softwaresystemen“ veranschaulicht. Die Idee ist es, Quellcode mit In­formationen direkt zu verknüpfen und diese Dokumentationsmöglichkeit in die Entwicklungsumgebung des Entwicklers zu integrieren, um dadurch den bestehenden Bruch zwischen Information und Quellcode zu überbrücken. Damit wird es möglich, dem Entwickler möglichst transparent wichtige Informationen während der Arbeit mit dem Quellcode anzu­bieten. Im Kapitel 3.2 wird veranschaulicht, dass Softwaresysteme die Umsetzung gedanklich kapselbarer Einheiten von Verhalten, im weiteren Aspekte genannt, darstellen. Dabei können Aspekte über den Quellcode verteilt sein oder aber mehrere Aspekte können in einer Quellco­destelle realisiert sein. Diese Idee, Verhalten in gekapselten Einheiten zusammenzuführen, ist auf programmiertechnischer Seite durch aspektorientiertes Programmieren bekannt.

Im Kapitel 4 wird aufgezeigt, welche technischen Ansätze möglich sind, um Quellcode und Dokumentation miteinander zu verknüpfen. Kapitel 5 beschreibt die technische Realisierung des Werkzeuges, das die Idee der quellcodegebundenen Dokumentation für Aspekte in Soft­waresysteme umsetzt.

1.1 Problemstellung

Softwaresysteme bestimmen den Alltag der Menschen im 21. Jahrhundert. In den vergange­nen Jahren hat die Abhängigkeit des Lebens der Menschen von Softwaresystemen stetig zuge­nommen und wird sich noch weiter verstärken. „In einigen Bereichen, wie Banken und Versicherungen, werden nahezu alle Dienstleistungen durch Software-Einsatz realisiert.“ [BalOO] Es gibt so gut wie keinen Bereich des Lebens, der nicht durch Softwaresysteme auf die eine oder andere Art und Weise beeinflusst wird. Das hat zur Folge, dass die funktionellen Anforderungen und Qualitätsanforderungen an die Softwaresysteme immer weiter ansteigen. Darüber hinaus werden die Kosten für eine Investition in Softwaresysteme in der heutigen Zeit immer kritischer hinterfragt, denn: „Teilweise betragen die Softwarekosten 9O Prozent der Gesamtkosten.“ [BalOO]. Die Entwicklung von Softwaresystemen stellt dadurch zuneh­mend höhere Anforderungen an die Softwareunternehmen. Das führt dazu, dass Softwareent­wickler in kürzester Zeit komplexe Sachverhalte realisieren und den Qualitätsanforderungen gerecht werden müssen.

Der Großteil der Tätigkeit eines Softwareentwicklers besteht aus der Wartung von Software­systemen. McClure merkt dazu an: „Softwarewartung beherrscht den Lebenszyklus von Soft­ware. Deshalb wenden wir den größten Teil des Personals und der Mittel, die für den Softwarebereich zur Verfügung stehen, für die Wartung und nicht für die Entwicklung auf.“ [McC93]. Zu beachten ist, dass Softwarewartung nicht nur die „Instandhaltung“ von Soft­waresystemen umfasst. Der Anteil der eigentlichen Fehlerbehebung macht nur einen kleinen Teil der Softwarewartung aus. Schon 1991 machte die Systemerweiterung rund 4O% des ge­samten Wartungsaufwands aus [Sne91]. Softwarewartung umfasst auch die Weiterentwick­lung von Systemen wie z.B. die Weiterentwicklung von Iteration zu Iteration eines Softwaresystems, zumeist als Softwareentwicklung bezeichnet, aber auch die Weiterentwick- lung von „bestehenden“ Softwaresystemen z.B. durch das Hinzufugen neuer Funktionalitäten zu einem bestehenden System . Balzer teilt den englischen Begriff Maintenance in Wartung und Pflege, wobei er Wartung als Lokalisierung und Behebung von Fehlern und Pflege als Lo­kalisierung und Durchführung von Änderungen und Erweiterungen eines in Betrieb befindli­chen Softwaresystems definiert. Im weiteren setzt er Pflege mit Weiterentwicklung gleich und hält fest, dass es in einem evolutionären und inkrementellen Prozessmodell keine Pflegephase gibt, sondern die Pflegeaktivitäten sind die Erstellung einer neuen Produktversion [BalOO].

Das Problem bei der Softwarewartung besteht darin, dass bereits Systemteile vorhanden sind, die durch den Entwickler verstanden und erweitert werden müssen. Die vorhandenen System­teile wurden aber zumeist durch einen anderen Softwareentwickler implementiert. Der Ent­wickler benötigt nun Informationen und Wissen über die zu erweiternden vorhandenen Systemteile, um diese zu verstehen und dadurch geeignet erweitern zu können. Wenn keine zusätzlichen Informationen vorhanden sind, wird die Einarbeitung in das System erschwert. Curth stellt dazu fest: „Da große unstrukturierte Programme so schwer zu verstehen sind, hat jeder neue Programmierer, der mit der Wartung einer alten Anwendung beauftragt wird, eine flache Lernkurve.“ [CG89]. Diese „zusätzlichen“ Informationen zum Quellcode sind auch dann von Bedeutung, wenn der Softwareentwickler die Systemteile selbst entwickelt hat, sich aber nicht mehr an die Hintergründe erinnern kann. Dies ist in der Praxis meist schon nach kurzer Zeit der Fall. Das zeigt, dass Wissensmanagement für die Softwarewartung und für die Softwareentwicklung eine enorme Bedeutung hat.

Wissensmanagement in der Softwareentwicklung umfasst dabei das Wissen über zu erwei­ternde Systemteile und über die damit in Verbindung stehenden Systemteile, aber auch das Wissen über übergeordnete Systemanforderungen bzw. Entscheidungen (siehe Kapitel 2.5 „Informationsmanagement und Wissensmanagement in der Softwareentwicklung“).Wissens- management wird innerhalb der Softwareentwicklung durch die Dokumentation von Soft­waresystemen und Softwareentwicklungsprozessen und damit durch verbundene Tätigkeiten realisiert.(siehe Kapitel 2.1 „Dokumentation von Softwaresystemen in der Softwareentwick­lung“). Die grundsätzliche Bedeutung der Dokumentation für die Softwareentwicklung ist schon lange bekannt und erforscht [Leh94]. Leider wird der Dokumentation von Softwaresys­temen dennoch in Projekten vieler Unternehmen nicht die Bedeutung geschenkt, die erforder­lich ist, damit Informationsverlust und Wissensverlust nicht auftreten. Das zeigt sich meist daran, dass Softwaresysteme nicht oder nur unvollständig dokumentiert werden. Darüber hi­naus spiegeln die Dokumentationen zum Großteil nicht den aktuellen Stand der Systeme wie­der. Die Gründe, die dazu fuhren, sind vielfältig. Zu den verbreitetsten Gründen gehören die mangelnde Akzeptanz und das fehlende Verständnis dafür, dass auch die scheinbar unnötigen Informationen festgehalten werden sollten. Häufig wird von Entwicklern versucht darzulegen, dass für die Dokumentation keine Zeit mehr vorhanden war. Durch das Fehlen einer vollstän­digen und aktuellen Dokumentation wird die Softwarewartung respektive Softwareentwick­lung erschwert, weil erst geprüft werden muss, welche Teile der Dokumentation den aktuellen Stand des Softwaresystems widerspiegeln und welche nicht. Die Informationen und das Wis­sen, die verloren gegangen sind, müssen nun erst wieder erworben werden. Der Wiederbe­schaffung des Wissens zu einem Systemteil ist aber enorm aufwendig und teilweise ist dies z.B. beim Weggang des Mitarbeiters, der den Systemteil implementiert hat, auch nicht mehr möglich. Das führt im Extremfall dazu, dass ein System komplett neu implementiert werden muss. Darüber hinaus wird ein Teil des investierten Kapitals durch den Verlust von Informa­tionen und Wissen vernichtet. Zusätzlich muss für die Wiederbeschaffung der Informationen und des Wissens neues Kapital investiert werden, was zur Unwirtschaftlichkeit sowie schließ­lich zum Scheitern eines Projektes führen kann. Dieses Scheitern des Projektes durch enor­men Zeitverlust glaubte man aber gerade durch das Einsparen der Zeit, die für die Erstellung der Dokumentation nötig gewesen wäre, verhindern zu können. Gerade das Weglassen der Dokumentationsphase stellt sich aber häufig als kurzsichtige Entscheidung heraus und führt, wie dargestellt, zu enormen Problemen bei der Softwareentwicklung. Da Software in zuneh­mendem Maße als Investitionsgut verstanden wird, steht die Wirtschaftlichkeit der Investition im Mittelpunkt des Handelns [Kau94]. Es wird deutlich, dass das Wissen und die Informatio­nen zu Softwaresystemen bewahrt werden müssen, um möglichst wirtschaftlich auf die Anfor­derungen der Kunden reagieren zu können. Dieses Problem wurde erkannt und spiegelt sich in der Forderung des Kunden nach zertifizierten Entwicklungsprozessen auf Seiten des Auftrag­nehmers wider.

Zertifizierte Entwicklungsprozesse sind unabhängig überprüfte Entwicklungsprozesse einer Firma, die die Umsetzung einer bestimmten Norm z.B. der IS09001 widerspiegeln. Die IS09001 hält z.B. fest, welche Dokumentationen zu einem System am Ende vorhanden sein müssen. Durch die Etablierung von zertifizierten Entwicklungsprozessen im Unternehmen wird festgeschrieben, welche Dokumentationen zu einem System erstellt werden müssen. Das führt bei einem Großteil der Projekte dazu, dass eine Dokumentation geschaffen wird, welche nicht direkt mit dem implementierten Softwaresystem verbunden ist. Dadurch kommt es zu einem „Bruch“ zwischen Dokumentation und implementiertem Softwaresystem. Das führt dazu, dass die Informationen nicht mit konkreten Quellcodestellen direkt in Verbindung ge­bracht werden können. Dem Entwickler wird damit unnötigerweise das Verstehen konkreter Implementierungen erschwert. Ein Ansatz, diesem Problem zu begegnen, besteht in der Doku­mentation des Quellcodes z.B. in Java durch Javadoc. Die Quellcodedokumentation ermög­licht aber nur sehr eingeschränkt den direkten Rückschluss zu übergeordneten Zusammenhängen zwischen unterschiedlichen Quellcodestellen. Dadurch kommt es wieder­um zum „Bruch“ zwischen Implementierung und Dokumentation. Weiterhin enthalten Quell­codedokumentation und „normale“ Dokumentation zumeist Redundanzen, die bei Änderungen gepflegt werden müssen. In den meisten Fällen wird die Pflege vernachlässigt und Teile der Dokumentation bzw. Quellcodedokumentation sind inaktuell oder widersprüch­lich und damit zum Großteil unbrauchbar.

Durch Redokumentation versucht man sich innerhalb des Reengineering sich einen Überblick über die Funktionsweise eines Systems bzw. Systemteils zu verschaffen. „Redokumentation beinhaltet die Erzeugung einer für den Menschen verständlichen Darstellung des Quellcodes eines Programms und seiner Funktionalität, deren Inhalt mit dem Quellcode übereinstimmt.“ [StrOO] Dieser Ansatz überführt den Quellcode in ein anders sprachiges Modell wie z.B. UML, wodurch technische Zusammenhänge sichtbar werden. Die Erzeugung des Modells be­inhaltet aber nicht die Wiedergewinnung von „menschlichen“ Informationen und Wissen zu einzelnen Systemteilen. Gerade diese Informationen und das Wissen sind jedoch enorm wich­tig für das Verständnis des Systems sowie für eine schnelle Wartung.

Wie dargestellt, besteht die Hauptaufgabe eines Softwareentwicklers in der Wartung von Soft­ware. Diese Aufgabe stellt ihn aber immer wieder vor das Problem, dass für einen Großteil der zu wartenden bzw. erweiternden Softwaresysteme eine geeignete Dokumentation fehlt. Zum Beispiel bei der Erweiterung [Eclipse]durch ein eigenes Plugin führt die fehlende voll­ständige Dokumentation aller Extension Points zu einem enormen Zeitaufwand bei der Suche nach der gewünschten Erweiterungsstelle. Wie von Curth richtig feststellt, hat ein Entwickler, der ein bestehendes System erweitert, eine flache Lernkurve [CG89]. Diese Kurve möglichst steil zu halten, sollte Ziel der Dokumentation eines Softwaresystems sein.

1.2 Zielsetzung

Zunächst wird die Arbeit mögliche Einflüsse auf die Qualität und Art der Dokumentation ei­nes Softwaresystems darlegen. Dies ist notwendig, da kein technischer Ansatz zur Dokumen­tation von Softwaresystemen Erfolg haben kann, wenn den an der Softwareentwicklung beteiligten Partnern nicht bewusst ist, welche Arbeitsbereiche und Prozesse Einfluss auf die Dokumentation haben. Daher wird die Arbeit aufzeigen, dass wesentlichen Einfluss auf die Art der zu einem Projekt erstellten Dokumentation Softwareentwicklungsprozesse und Soft­wareentwicklungsmodelle haben, da in ihnen viele Arbeitsschritte, die die Dokumentation be­einflussen, festgeschrieben sind. Darüber hinaus wird darlegt werden, dass das Arbeitsumfeld eines Softwareentwicklers enormen indirekten Einfluss auf die Qualität der Dokumentation hat. Dazu ist anzumerken, dass beispielsweise fehlendes Verständnis für die Notwendigkeit der Einplanung von Arbeitszeit für die Dokumentation seitens des Arbeitgebers bzw. Projekt­leiters zum Weglassen der Dokumentationsphase durch den Entwickler führen kann.

Die Notwendigkeit, auch mögliche, durch die Dokumentation beeinflusste Bereiche zu be­leuchten, wird deutlich bei der Betrachtung des großen Einflusses der Dokumentation eines Softwaresystems auf die Qualität des Softwaresystems selbst. Gerade die Qualitätsmerkmale Erweiterbarkeit und Verständlichkeit eines Softwaresystems sind zum Großteil von einer qua­litativ hochwertigen Dokumentation abhängig.

Es wird deshalb dargelegt, dass Wissensmanagement in der Softwareentwicklung sich in der Dokumentation von Softwaresystemen widerspiegelt. Die Arbeit wird aufzeigen, dass die Do­kumentation von Softwaresystemen ein etablierter Arbeitsprozess innerhalb der Softwareent­wicklung ist und dieser Prozess für das Bewahren von Informationen und Wissen genutzt wird. Darüber hinaus wird deutlich gemacht, dass Wissensmanagement mehr bedeutet als das bloße Festhalten von Informationen und Wissen. Dazu wird erläutert, dass die Dokumentation von Softwaresystemen zu meist losgelöst von anderen Prozessen erfolgt, und eine Vernetzung der Informationen und des Wissens nicht stattfindet.

Ziel der Arbeit ist es, eine Möglichkeit aufzuzeigen, wie Informationen und Wissen über Sys­temzusammenhänge und Hintergründe zu Softwaresystemen und Systemteilen durch die Bin­dung an Quellcodeelemente vereinfacht festgehalten und vernetzt werden können. Die direkte Verbindung von Dokumentationselementen und Quellcodeelementen soll das Verstehen von Softwaresystemen bzw. Systemteilen durch den Softwareentwickler bei der Weiterentwick- lung und Wartung der Softwaresysteme erleichtern. Aufgezeigt wird, dass damit der Bruch zwischen normaler Dokumentation und dem Quellcode, der das Verständnis fur Zusammen­hänge zwischen verschiedenen Quellcodeelementen erschwert, behoben wird. Die Verbindung von Quellcodeelementen und Dokumentationselementen soll ermöglichen, dass der Informati­onsfluss von der Dokumentation zum Quellcode und umgekehrt ohne Systemwechsel rei­bungsfrei möglich ist. Wie aufgezeigt, ist es das primäre Ziel, die Implementierung und die Dokumentation so näher zusammenzubringen. Damit soll es möglich sein, Systemzusammen­hänge zwischen unterschiedlichen Quellcodeelementen auf einer höheren abstrakten Ebene, Dokumentationsebene genannt, sichtbar zu machen. Ein weiteres Ziel der Arbeit ist es, darzu­legen, dass für das Verständnis von Softwaresystemen das Verständnis der einzelnen Aspekte eines Softwaresystems entscheidend ist. Aspekte bilden gedanklich kapselbare Einheiten von Verhalten, die durch den Menschen besser aufgenommen und verstanden werden. Spezielle Dokumentationselemente ermöglichen das Dokumentieren von Aspekten und der Verbindung mit dem Quellcode. Dadurch kann die Verteilung eines Aspektes im Quellcode sichtbar ge­macht werden.

Ein prototypisches System zu implementierten, das die Dokumentation des Softwaresystems und die Verlinkung in den Quellcode ermöglicht und sich in den Implementierungsprozess des Entwicklers integriert, ist das Ziel des praktischen Teils der Arbeit.

2 Hintergrund

Die Softwareentwicklung unterliegt vielen verschiedenen Einflüssen. Diese Einflüsse können positiv aber auch negativ sein. In diesem Kapitel wird auf eine Vielzahl von Einflussfaktoren eingegangen, die direkten oder indirekten Einfluss auf die Dokumentation eines Softwaresys­tems haben. Der Hintergrund ist, dass der Erfolg technischer Neuerungen entscheidend vom Wissen über relevante Einflussfaktoren und deren Berücksichtigung bei der Lösung abhängt. Das Hauptaugenmerk wird dabei auf den Menschen, also den Entwicklern selbst liegen, da von ihnen die Art, die Qualität und der Umfang einer Dokumentation abhängen. Softwareent­wicklung und damit auch das Dokumentieren von Software ist ein kreativer Prozess, der von Menschen durchgeführt wird. Das sollte an keiner Stelle der Planung und des Managements vernachlässigt werden. Der Erfolg oder Misserfolg eines Softwareprojektes und der darin ent­haltenen Dokumentation hängt maßgeblich von Menschen, deren Motivation, Können und Entscheidungen ab und weniger als man glauben mag, von der Technik. Im Kapitel 2.1 wird dargelegt, welche Rolle die Dokumentation von Softwaresystemen in der Softwareentwick­lung spielt. Das Kapitel 2.2 betrachtet Qualitätsmerkmale von Softwaresystemen und die Ein­flussmöglichkeiten der Dokumentation auf diese und umgekehrt. Unterschiedliche Vorgehensmodelle für die Softwareentwicklung und den Einfluss der Vorgehensmodelle auf die Dokumentation eines Softwaresystems untersucht das Kapitel 2.3. Das Kapitel 2.4 zeigt mögliche Einflussfaktoren aus dem Arbeitsumfeld auf. Abschließend beleuchtet Kapitel 2.5 den Aspekt des Wissensmanagements im Zusammenhang mit der Dokumentation von Soft­waresystemen. Die Dokumentation von Software ist immer noch ein vernachlässigtes Feld in der Softwareentwicklung, wobei ihre Bedeutung für die Qualität eines Softwareproduktes nachgewiesen ist [Leh94].

2.1 Dokumentation von Softwaresystemen in der Softwareentwick­lung

Unter Dokumentation wird zumeist im alt hergebrachten Sinne das Sammeln, Erfassen, Be­schreiben, Darstellen und Ordnen von Dokumenten verstanden [HR89]. Das Deutsche Uni­versalwörterbuch definiert Dokumentation als die „Zusammenstellung, Ordnung u. Nutzbarmachung von Dokumenten [DUD03]. Die Ziele einer einheitlichen Dokumen­ tation sind nach Mayr [MayOl]:

- einheitliche Struktur der Dokumente
- rasche, einfache Erstellung neuer Dokumente
- parallele Erstellung bzw. Zusammenführung von Dokumenten
- Möglichkeiten zur Präsentation des Projektstands
- Möglichkeiten zur Projektkontrolle.

An der Definition von Mayr ist erkennbar, dass das vornehmliche Ziel einer Dokumentation in der einfachen Handhabung liegt.

Ein Dokument einer Dokumentation stellt eine „strukturierte, als Einheit erstellte u. gespei­cherte Menge von Daten“ [DUD03] dar und verfugt über eine ihm inne wohnende logische und inhaltliche Struktur sowie über ein definiertes Layout. Dadurch ist es möglich sich in un­terschiedlichen Dokumenten, die als Grundlage ein und dieselbe Vorlage haben, schneller zu­rechtzufinden. Sehr genau definierte Vorlagen können auch als Formular bezeichnet werden. Ein Formular definiert feste Bereiche, in denen bestimmte Informationen bzw. Angaben fest­gehalten werden können. Dokumente werden in der heutigen Zeit nur in Ausnahmefällen in Papierform aufbewahrt, sondern werden als digitales Medium in Computersystemen abgelegt. Das vereinfacht vor allem den Zugriff und die Bearbeitbarkeit der Dokumente. In der Soft­wareentwicklung bezeichnet der Begriff „Dokumentation“ umgangssprachlich sowohl den Prozess, d.h. die Tätigkeit des Dokumentierens, als auch das Produkt, d.h. das Ergebnis dieser Tätigkeit [Leh94]. Dabei dient die Dokumentation als Kommunikationsmedium zwischen den an der Softwareentwicklung beteiligten Personen. Die Dokumentation fasst also die Informa­tionen und das Wissen zu einem Softwaresystem sowie die die Entwicklung des Systems um­gebenden Prozesse strukturiert zusammen. Henzler stellt fest, die Grundlage jeder Dokumentation ist die Information [Hen92]. Die Fülle an verschiedenen Informationen zu ei­ nem Softwaresystem hat zur Folge, dass eine riesige Anzahl verschiedener Dokumentationen zu einem System und zu den das System umgebenden Prozessen erstellt werden können. Thal­ler merkt dazu an: „Ein nicht unerheblicher Teil des Aufwands für ein Software-Projekt be­steht in der Erstellung der Dokumentation.“ [Tha02]. Das macht den Stellenwert deutlich, den die Dokumentation innerhalb der Softwareentwicklung inne hat. Grupp versucht, durch die Einordnung der verschiedenen Dokumentationen in unterschiedliche Dokumentationsbereiche die Dokumentationen zu klassifizieren [Gru91]:

- Projektmanagementdokumentation oder Projektablaufdokumentation

Die Projektmanagementdokumentation umfasst alle das Projektmanagement betreffen­den Dokumentationen, wie z.B. die Dokumentation des Projektauftrags, der Planung, des Schriftwechsels und der Besprechungsprotokolle.

- Organisationsdokumentation oder Systemdokumentation

In der Organisationsdokumentation sind alle Dokumentationen enthalten, die während der Projektdurchführung anfallen, beispielsweise Analyse- und Entwurfsergebnisse so­wie Konzepte.

- Programmdokumentation

Die Programmdokumentation umfasst sowohl Programmieraufgaben als auch Program­miervorgaben sowie während der Programmierung erstellte Hilfsdokumente.

- Rechenzentrumsdokumentation

Die Rechenzentrumsdokumentation enthält z.B. die Dokumentationen zur Systembedie­nung.

- Benutzerdokumentation

Die Benutzerdokumentation enthält unter anderem Informationen zur Installation und Bedienung eines Softwaresystems.

Scheibl [Sch85] unterteilt die Dokumentationsbereiche in folgende Gruppen:

- Projektdokumentation bzw. projektbegleitende Dokumentation
- Entwicklungsdokumentation
- Produktdokumentation
- Benutzerdokumentation

Grupp und Scheibl entfernen sich bei ihren Klassifizierungen nicht all zu weit voneinander. Beide unterscheiden zwischen Projektdokumentation bzw. Projektmanagementdokumentation und die das Softwaresystem direkt betreffenden Klassifizierungen.

Wie bereits dargestellt, umfasst die Dokumentation eines Softwaresystems eine Vielzahl an unterschiedlichen Dokumentationen. Was alles innerhalb eines Softwareprojektes dokumen­tiert werden soll, wird durch einige festgeschriebene aber auch durch variable Faktoren be­stimmt. Die Umsetzung eines zertifizierten Entwicklungsprozesses (siehe Kapitel 2.3) führt dazu, dass von diesem Entwicklungsprozess geforderte Dokumentationen erstellt werden müssen. Diese Anforderungen sind in den jeweiligen Normen, wie z.B. der DIN, ISO, IEEE oder ANSI Norm, nach denen der Entwicklungsprozess zertifiziert ist, definiert. Darüber hi­naus können bestimmte Dokumentationen Bestandteil des Auftrags sein und müssen daher, wenn nicht vorhanden, zusätzlich erstellt werden. Festzuhalten ist, dass es über die geforder­ten Dokumentationen hinaus, im Idealfall eine gemeinsame Entscheidung des Entwickler­teams, des Projektleiters und möglicherweise des Kunden sein sollte, welches Wissen zusätzlich zu dokumentieren bzw. aufzubewahren ist.

Softwaresysteme nehmen in den meisten Fällen schon nach kurzer Zeit an Größe und Kom­plexität zu und werden damit für den Softwareentwickler unüberschaubar. Auf Seite des Pro­jektmanagements wird es mit zunehmender Projektgröße immer schwieriger, den aktuellen Stand des Projektes zu überschauen und alle wichtigen Fakten bei der Fülle an Informationen im Auge zu behalten. Daher wird versucht, alle wichtigen Informationen und Erkenntnisse festzuhalten. Für die einzelnen Bereiche eines Projektes stehen dafür unterschiedliche Doku­mentationstypen zur Verfügung. Was genau dokumentiert wird, hängt von den aufgezeigten Anforderungen sowie den Erfahrungen der Projektmitglieder ab. Das folgende Zitat soll noch einmal die Bedeutung der Dokumentation für die erfolgreiche Durchführung eines Projekt be­legen: „Wenn den Studenten der Informatik gesagt wird, dass die von ihnen erstellte Software gut dokumentiert werden muss, dann glauben sie es so lange nicht, bis sie ein von ihnen er­stelltes und nicht dokumentiertes Programm nach einiger Zeit selbst ändern müssen.“ [Pra03] Dieses Beispiel mag sich zwar nur auf eine kleines Softwaresystem beziehen, aber die Folgen einer fehlenden Dokumentation werden auch hier schon deutlich. Die Auswirkungen einer fehlenden Dokumentation auf die Qualität komplexer Softwaresysteme potenzieren sich. Da­her sollte der Erstellung der Dokumentation die entsprechende Bedeutung geschenkt werden, da die Qualität einer Dokumentation entscheidend für die Verwendbarkeit des Softwaresys­tems ist.

Ein häufiger Fehler, der zu qualitativ minderwertigen bzw. unvollständigen Dokumentationen führt, ist in der Tatsache begründet, dass die Dokumentation eines Softwaresystems mit der Fertigstellung des Systems als abgeschlossen betrachtet wird. In der Folge werden Änderun­gen, die am System z.B. bei Wartungsarbeiten durchgeführt werden, nicht in der Dokumenta­tion berücksichtigt [Leh94]. Damit spiegelt die Dokumentation nicht mehr den aktuellen Stand des Softwaresystems wider. Das Ziel einer Dokumentation sollte es aber sein, folgende Einschätzung zu widerlegen, ,,... die einzige wahre Beschreibung des Programms ist das Pro­gramm selber...“ [Sne91].

Die Qualität der Dokumentation ist für ihre Nutzbarkeit entscheidend. Wichtige Qualitäts­merkmale einer Dokumentation sind Vollständigkeit, Korrektheit, Konsistenz sowie Änder­barkeit [ZusOl]. Vollständigkeit definiert das Vorhandensein aller wichtigen Informationen sowie die Korrektheit der Übereinstimmung der Informationen mit den der Dokumentation zu Grunde liegenden Quellen. Unter Konsistenz versteht man die Widerspruchsfreiheit der Do­kumentation. Die Änderbarkeit gewährleistet die problemlose Bearbeitung der Dokumentati­on. Für genauere quantitative Anforderungen an die Dokumentation sei an dieser Stelle auf Lehner [Leh94] und Stetter [Ste81] verwiesen, die dieses Thema näher beleuchten.

Diese Arbeit befasst sich vornehmlich mit dem Dokumentieren von Informationen und Wis­sen, das direkt den Quellcode und das Softwaresystem selbst betrifft. Interessant sind dabei vor allem die mit dem Quellcode in Zusammenhang stehenden Entscheidungen und Hinter­gründe, die für das Verständnis des Systems und seiner einzelnen Komponenten wichtig sind. Dazu wird im weiteren dargestellt, wie wichtige Informationen während der Implementierung dokumentiert werden sollten. Darüber hinaus wird beleuchtet, welche Bedeutung die Doku­mentation für die Wartung bzw. Weiterentwicklung eines Softwaresystems hat. Ziel ist es, mögliche Probleme beim Dokumentieren innerhalb des Implementierungs- und Wartungspro­zesses zu veranschaulichen.

2.1.1 Dokumentation während der Implementierung

Die entscheidende Bedeutung kommt der Erfassung der Informationen und des Wissens wäh­rend der eigentlichen Implementierungs- bzw. Weiterentwicklungsphase zu. Nur während der Implementierung wird neuer Quellcode erzeugt. Damit ist klar, dass vornehmlich im Verlaufe der Implementierung alle Entscheidungen, welche die Funktionalität des Softwaresystems be­treffen, umgesetzt werden. Die Implementierungsphase eines Softwaresystems sollte daher die Dokumentation der Problemlösung und der Implementierungsentscheidungen durch geeignete Verbalisierung und Kommentierung beinhalten [BalOO]. Dieser Prozess sollte nicht aufge­schoben werden, damit keine Hintergrundinformationen zur praktischen Umsetzung verloren gehen. Balzer merkt dazu an: „Der Aufwand für die Dokumentation wird reduziert, wenn zu dem Zeitpunkt, an dem die Information anfällt, von demjenigen, der sie erzeugt oder verarbei­tet, auch dokumentiert wird.“ [BalOO]. Dazu lässt sich festhalten, dass zu jedem anderen Zeit­punkt meist nicht wieder alle Informationen greifbar sind und damit Informationen verloren gehen können.

Ein Softwaresystem ist demzufolge so zu dokumentieren, dass zu einem späteren Zeitpunkt Wartung sowie Einarbeitung in das System effektiv und fehlerfrei möglich sind.

Zum Implementierungsprozess gehört außer der Dokumentation auch die Festlegung gemein­samer Programmierrichtlinien sowie das Führen eines Fehlerbuches [BalOO] und die Einhal­tung darüber hinaus gehender Programmierprinzipien. Programmierrichtlinien sind ein weit verbreitetes Mittel, um für einen einheitlichen Quellcode zu sorgen. Zu den Programmierricht­linien gehören unter anderem:

- Die Wahl geeigneter Bezeichner für Pakte, Klassen, Methoden, Attribute, Variablen uvm..

- Die Verwendung von Quellcodedokumentationen zur Erklärung von kleineren Quellcode­abschnitten.

- Das einheitliche Formatieren der Programmiersprachenanweisungen, z.B. Klammerung von Methoden.

- Die einheitliche Beschreibung von Softwaresystemteilen wie Klassen durch:
- Kurzbeschreibung,
- Name der Programmierer
- Versionsangaben
- uvm.

Eine sehr detaillierte, vollständige Darstellung aller Programmierrichtlinien findet sich im Lehrbuch der Software-Technik [BalOO]. Anzumerken bleibt, dass das gemeinsame Verwen­den einheitlicher Standards sehr großen Einfluss auf die Lesbarkeit des Quellcodes hat, vor al­lem bei nicht selbst dokumentierenden Sprachen wie Java.

Die Frage bleibt, weshalb werden dennoch so wenige Softwaresysteme vollständig dokumen­tiert, wo doch die Vorteile klar auf der Hand zu liegen scheinen. Als Hauptursache wird von den Entwicklern und Unternehmen vor allem der hohe Zeitbedarf für die Dokumentation ei­nes Softwaresystems angegeben. Zusätzlichen Zeitbedarf als KO-Kriterium für die Dokumen­tation anzusehen, ist in Anbetracht der möglichen Folgen des Fehlens einer Dokumentation sehr kurzsichtig. Das Scheitern eines Projektes wirkt sich stärker auf das Unternehmen aus als die Verschiebung eines Termins oder das Überschreiten des Projektbudgets. Diese Erkenntnis setzt sich oftmals nur dann durch, wenn durch das Fehlen einer Dokumentation eigene Soft­wareprojekte gescheitert sind. Die Wahrnehmung des latenten Problems wird oft dadurch ge­trübt, dass ein „pfiffiger Programmierer in letzter Sekunde das Runder noch herumreißt“. Diese Notlösung wird meist sogar noch als „Erfolg“ angesehen. Bei der Betrachtung meiner eigenen Programmiererfahrungen zeigt sich, dass mangelnde Disziplin sowie begrenzte Erfah­rungen im Dokumentieren meistens die Ursache dafür waren, dass ein Softwaresystem nicht oder unvollständig dokumentiert wurde. Ein Softwaresystem verursacht jedoch nicht die Hauptkosten während der Entwicklung, sondern mehr als 2/3 der Kosten entstehen bei der Wartung und Weiterentwicklung des Systems [BalOO]. Gerade bei der Weiterentwicklung res­pektive Wartung kann sich das Fehlen einer Dokumentation sehr kostenintensiv auswirken.

2.1.2 Typische Probleme im Rahmen der Wartung und Weiterent­wicklung von Softwaresystemen

Die Wartung von Softwaresystemen bestimmt den Alltag der Programmierer. Wartung um­fasst die Fehlerkorrektur, Änderung der ursprünglichen Anforderungen sowie Verbesserung von Funktionalität und Leistung [McC93]. Für die Wartung eines Softwaresystems benötigt der Programmierer Informationen über das zu wartende System bzw. die zu wartenden Teile des Systems. Grundlage aller Information stellt die Dokumentation des Softwaresystems dar, da in ihr die Konzepte und die Umsetzung des Systems dokumentiert sind. Ziel des Entwick­lers ist es, sich die Teile aus der Dokumentation herauszusuchen, die für ihn interessant er­scheinen. Im Weiteren wird der Entwickler versuchen, die Informationen aus der Dokumenta­tion mit konkreten Quellcodestellen, die zu verändern oder zu erweitern sind, in Verbindung zu bringen. Diese Aufgabe kann sich als schwierig erweisen, da in einer Dokumentation selten direkte Verweise auf Quellcodestellen enthalten sind. Dadurch kommt es zu einem Bruch zwi­schen Dokumentation und Quellcode. Abhilfe würde eine quellcodegebundene Dokumentati­on schaffen, wie sie in Kapitel 3 „Konzept einer quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen“ vorgestellt wird. Ohne eine derartige Dokumentation muss der Entwickler versuchen, die Informationen und das Wissen, die in der Dokumentation ent­halten sind, mit dem Quellcode in Verbindung zu bringen. Wie schnell er betreffende Quell­codestellen findet, hängt davon ab, wie genau diese Stellen in der Dokumentation beschrieben sind.

Die Voraussetzung für dieses Vorgehen ist aber die Existenz einer vollständigen und korrek­ten Dokumentation des Softwaresystems, was aber meistens nicht der Fall ist. Große Proble­me treten oft dann auf, wenn die Dokumentation fehlerhaft, unvollständig oder inaktuell ist. In einem solchen Fall trifft die Aussage zu, dass die einzige wahre Beschreibung des Programms das Programm selber zu [Sne91]. Im vorliegenden Fall ist es erforderlich, dass zunächst fest­gestellt wird, welchen Stand des Systems eine vorhandene Dokumentation widerspiegelt. Der zweite Schritt ist zu versuchen, die fehlende Information aus dem Quellcode wiederzugewin­nen. Dazu wird meist auf das Reengineering des Softwaresystems gesetzt. Reengineering be­inhaltet Reverses Engineering und das wiederum Redokumentation (siehe Abbildung 1: Begriffliche Einordnung des Reengineering).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Begriffliche Einordnung desReengineering

Ziel des Reverse Engineering ist es, das Softwaresystem zu redokumentieren und damit Ent­wurfsinformationen aus dem Quellcode zu erzeugen, die es erleichtern, das Programm zu ver­stehen [McC93]. Reengineeringmaßnahmen werden immer durch Werkzeugunterstützung realisiert. Festzuhalten ist, dass die Redokumentation immer Teil der Wartung sein sollte, da so die Aktualität der Dokumentation überprüft wird. Redokumentationswerkzeuge sind heute meist schon in die Entwicklungsumgebung (IDEs - Integrated Developement Environment zu deutsch integrierte Entwicklungsumgebung) integriert und ermöglichen somit schnell den Quellcode beispielsweise in eine beliebige UML - Ansicht zu transformieren. Welche Mög­lichkeiten Reengineering für die Wartung bietet, soll hier nicht weiter vertieft werden. Festzu­halten ist, dass menschliches Wissen und genaue Hintergründe zu bestimmten Realisierungen nicht allein aus dem Quellcode wiedergewonnen werden können. Zur Vertiefung der Reengi- neeringthematik sei auf „Software-Reengineering“ [Kau94], „Reengineering Ein integrales Wartungskonzept zum Schutz von Software-Investition“ [Thu90] sowie „Software-Automati­sierung - Reengineering-Repositiry Wiederverwendbarkeit“ [McC93] verwiesen.

Bei der Wartung von Softwaresystemen sollte darauf geachtet werden, dass die Dokumentati­on des Systems aktualisiert wird. Das heißt, dass die vorgenommenen Änderungen und Hin­tergründe vermerkt werden. Wie bereits kurz angesprochen, wird im Kapitel 3 erläutert, welche Möglichkeiten die quellcodegebundene Dokumentation für die Wartung von Soft­waresystemen bieten könnte. Anzumerken ist, dass gerade in der Wartung oftmals direkt mit dem Quellcode gearbeitet wird. Das Ziel dieser Arbeit ist es, durch die quellcodegebundene Dokumentation dem Entwickler innerhalb seiner Entwicklungsumgebung zu visualisieren, dass an dem von ihm untersuchten Quellcode eine Dokumentation hängt. Diese Dokumentati­on ließe sich dann auf Wunsch sehr einfach darstellen. Dadurch soll der Bruch zwischen Do­kumentation und Quellcode behoben werden.

2.2 Qualitative Anforderungen an Softwaresysteme und deren Ma­nagement

An Softwaresysteme werden im zunehmenden Maße höhere Qualitätsanforderungen gestellt. Der Grund dafür ist, dass Software in immer mehr Bereichen eingesetzt wird, in denen ein Versagen nicht nur zu wirtschaftlichen Verlusten, sondern auch zur Gefährdung von Men­schenleben führen kann [Bal00]. Daher müssen Softwaresysteme eine Vielzahl von Qualitäts­anforderungen erfüllen. Diese Qualitätsanforderungen werden in Qualitätsmerkmalen genauer definiert. Unter einem Qualitätsmerkmal versteht man die Eigenschaft einer Ware, die die Qualität der Ware ausmacht. Qualität wird als Güte, das heißt als Grad der guten Beschaffen­heit eines Erzeugnisses, definiert [DUD03]. Für die Softwareentwicklung ist ein Qualitäts­merkmal ein Satz von Eigenschaften eines Softwareprodukts, anhand dessen seine Qualität beschrieben und beurteilt wird. Ein Softwarequalitätsmerkmal kann über mehrere Stufen in Teilmerkmale verfeinert werden [Imb04]. In der ISO 9126 wird Softwarequalität wie folgt de­finiert: „Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Soft­wareproduktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen“. Balzer merkt dazu an: „Die Software-Qualität wird allgemein oder bezogen auf einzelne Entwicklungen durch Qualitätsmerkmale beschrieben“ [Bal00].

Software-Qualitätsmerkmale nach ISO 9126 sind:

- Funktionalität: Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Si­cherheit

Funktionalität definiert als Qualitätsmerkmal das Vorhandensein von Funktionen mit fest­gelegten Eigenschaften, wobei diese Funktionen die definierten Anforderungen erfüllen.

- Zuverlässigkeit: Reife, Fehlertoleranz, Wiederherstellbarkeit

Unter Zuverlässigkeit wird die Fähigkeit der Software verstanden, ihr Feistungsniveau un­ter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.

- Benutzbarkeit: Verständlichkeit, Erlernbarkeit, Bedienbarkeit

Benutzbarkeit betrachtet den Aufwand, der zur Benutzung eines Softwaresystems erforder­lich ist und beinhaltet die individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe.

- Effizienz: Zeitverhalten, Verbrauchsverhalten

Unter Effizienz versteht man das Verhältnis zwischen dem Feistungsniveau einer Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.

- Änderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit

Das Qualitätsmerkmal Änderbarkeit betrachtet den Aufwand, der zur Durchführung vorge­gebener Änderungen notwendig ist. Unter einer Änderung werden die Korrekturen, Ver­besserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen sowie der funktionalen Spezifikationen verstanden.

- Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit

Unter Übertragbarkeit wird die Eignung der Software verstanden, von einer Umgebung in eine andere übertragen zu werden. Eine Umgebung kann sowohl eine organisatorische Um­gebung als auch eine Hardware- oder Software-Umgebung einschließen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Qualitätsmerkmale nach ISO 9126

Es stellt sich die Frage, wie kann die Erfüllung definierter Qualitätsmerkmale in einem Soft­waresystem überprüft sowie gewährleistet werden und welche Qualitätsmerkmale soll ein Softwaresystem erfüllen. Die Überprüfung und das Management von Qualitätsmaßnahmen unterliegt dem Qualitätsmanagement. Das Qualitätsmanagement teilt sich in produktorientier­tes sowie prozessorientiertes Qualitätsmanagement. Das prozessorientierte Qualitätsmanage­ment überprüft den Prozess der Erstellung eines Produktes und aus ihm gehen konstruktive und analytische Qualitätsmaßnahmen hervor. Produktorientiertes Qualitätsmanagement über­prüft die Qualitätsmerkmale eines Produktes und seiner Zwischenergebnisse. Unter konstruk­tiven Qualitätsmaßnahmen wird der Einsatz von technischen (z.B. Werkzeugeinsatz, uvm.) und organisatorischen Maßnahmen verstanden. Analytische Maßnahmen zielen auf das Mes­sen und Analysieren sowie Testen von Qualitätsanforderungen ab. Zu den analysierenden Ver­fahren zählen die statische Programmanalyse, das Review, der Walkthrough und das Audit eines Softwaresystems. Ein Review ist ein mehr oder weniger formal geplanter und struktu­rierter Analyse- und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutach­tern präsentiert und von diesem kommentiert oder genehmigt werden (IEEE-Norm 729-1983). Für die Messung von Qualitätsanforderungen werden Metriken verwendet. Beispielsweise zählt dazu, die Messung der Abhängigkeit einer Klasse in einem Paket [Wul02]. Testende Verfahren überprüfen dagegen das Verhalten des Systems z.B. anhand von UnitTests. In Java wird beispielsweise JUnit [JUnit] zum Testen von Schnittstellen verwendet. Organisatorische Maßnahmen definieren zu Projektbeginn Richtlinien, wie beispielsweise Dokumentations­richtlinien, Standards und Checklisten, welche gewisse Rahmenbedingungen für die Erstel­lung eines Softwaresystems und den Prozess der Erstellung des Systems gewährleisten. Alle diese Maßnahmen zusammen überprüfen und verbessern die Qualität eines Softwaresystems und leisten damit einen wichtigen Beitrag, qualitativ hochwertigere Softwaresysteme zu ent­wickeln. Zu beachten ist, dass die Verbesserung eines Entwicklungsprozesses nicht zwangs­läufig zu einer Verbesserung der Produktqualität führt.

Der Anspruch an eine professionelle Softwareentwicklung ist es, die geforderten Qualitäts­merkmale für ein Softwaresystem zu erfüllen. Maßnahmen, die für die Erfüllung der verlang­ten Qualitätsanforderungen nötig sind, kosten häufig Zeit und Geld. Diese Tatsache muss dem Kunden vermittelt und verdeutlicht werden. Dabei kann als Argument angeführt werden, dass diese Kosten zumeist während der Wartungsphase eingespart werden können, da Qualitäts­merkmale wie Zuverlässigkeit und Änderbarkeit den Wartungsaufwand verringern helfen. Es ist aber zu beachten, dass es Qualitätsmerkmale gibt, die sich gegenseitig behindern [ZusOl], so z.B. Effizienz und Erweiterbarkeit. Daher sollten schon von Projektbeginn an die grundle­genden Qualitätsmerkmale eines Softwaresystems von und mit dem Kunden zusammen fest­geschrieben werden [ZusOl]. Darüber hinaus wirken sich externe Elemente der Softwareentwicklung, wie die Dokumentation eines Softwaresystems, nicht unwesentlich auf die Qualität des Softwaresystems selbst aus. Die Güte der Qualitätsmerkmale Änderbarkeit und Benutzbarkeit werden beispielsweise von der Dokumentation eines Softwaresystems be­einflusst [MayOl]. Es zeigt sich, dass die Dokumentation den Einsatz und die Wartung von Softwaresystemen unterstützt. Da die Wartung einen Großteil der Tätigkeit eines Entwicklers ausmacht (etwa 2/3), ist der Einfluss einer guten Dokumentation für die zukünftige Qualität des Systems bedeutend. In den nächsten Abschnitten sollen daher die Einflüsse und Einfluss­möglichkeiten auf und von der Dokumentation eines Softwaresystems auf die Qualität eines Systems beleuchtet werden. Dazu wird zunächst betrachtet, welche quantitativen Anforderun­gen an ein Softwaresystem Einfluss auf die Dokumentation des Systems haben. Im weiteren wird dargestellt werden, welchen Anteil die Dokumentation an der Qualität des Softwaresys­tems selbst hat.

Für die intensivere Betrachtung des Themas Qualitätsmanagement und Softwareentwicklung empfiehlt sich Software Engineering mit UML und dem Unified Process [ZusOl], Projekt En­gineering - Ingenieurmäßige Softwareentwicklung in Projektgruppen [MayOl] und das Lehr­buch der Software-Technik [BalOO]. Das Thema Qualitätsmanagement kann, wie die Buchtitel zeigen, nicht losgelöst von Entwicklungsprozessen und den beteiligten Entwicklern betrachtet werden und Qualitätsmanagement macht nur einen kleinen Teil des ganzheitlichen Prozesses der Softwareentwicklung aus.

2.2.1 Einflussfaktoren auf die Dokumentation von Softwaresyste­men während der Implementierung

Wie bereits dargestellt, hängen die Qualitätsmerkmale Änderbarkeit und Benutzbarkeit eines Softwaresystems nicht unerheblich von der Qualität respektive der Verständlichkeit der Doku­mentation des Softwaresystems ab. Gerade die Erlernbarkeit und Modifizierbarkeit eines Soft­waresystems kann durch eine qualitativ hochwertige Dokumentation beeinflusst werden. Damit zeigt sich, dass die Qualitätsanforderungen, die an ein Softwaresystem gestellt werden, nicht allein durch das System selbst, erfüllt werden. Gerade die Bewahrung der Informationen und des Wissens während der Implementierung hat Einfluss auf die zukünftige Qualität des Softwaresystems. Werden beispielsweise quantitative Anforderungen und Wünsche des Kun­den nicht dokumentiert, fehlt deren Umsetzung im Endprodukt und beeinflusst damit das Qualitätsmerkmal Richtigkeit. Darüber hinaus kann das Fehlen von wichtigen Informationen, die beispielsweise die Hintergründe und Entscheidungen eines Implementierungsdetails erläu­tern, schwerwiegende Folgen hervorrufen und damit das Qualitätsmerkmal Stabilität beein­flussen. So kann zum Beispiel die Verwendung eines veralteten Treibers für die Datenbank sich bei der Wartung als scheinbar mögliche Ursache eines Fehlers darstellen und damit ein Update auf die aktuelle Version als sinnvoll erachtet werden. Der Hintergrund der Nutzung des Treibers ist aber eine spezielle Anpassung auf die hausinterne Datenbank. Ein Austausch des Treibers würde unter bestimmten Bedingungen bei der Jahresabschlussrechnung zu einem erheblichen Datenverlust führen und so das Qualitätsmerkmal Funktionalität - Sicherheit be­einflussen. Da dieser Fehler erst bei der Auslieferung des Systems aufgetreten ist, wurde ver­gessen, Testfälle für diese Konstellation zu schreiben und lediglich eine Notiz in der Dokumentation vorgenommen. Problematisch könnte es werden, wenn diese Notiz nicht di­rekt mit dem Treiber in Verbindung gebracht wurde, da sie dann innerhalb der Wartungsakti­ vitäten leicht übersehen werden könnte. Abhilfe kann an dieser Stelle die quellcodegebundene Dokumentation schaffen (siehe Kapitel 3), die einen Vermerk direkt am Treiber oder dem Build-Skript ermöglicht. Um mögliche negative Einflüsse auf die Qualität eines Softwaresys­tems zu vermeiden, sollte es möglich sein, wichtige Hintergrundinformationen und Entschei­dungen zu einem Softwaresystem durch ihr Dokumentieren zu bewahren. Ziel dabei ist es, mögliche, erst später das System direkt betreffende, negative Einflüsse auf die Qualität des Softwaresystems zu vermeiden. Daher kommt der Dokumentation im Verlauf der Implemen­tierungsphase eine wichtige Bedeutung für den Informationsaustausch zu. Gerade bei der Wartung von Softwaresystemen wirken sich anfängliche Qualitätseinbußen bei der Änderbar­keit des Systems, die durch die Dokumentation beeinflusst werden, negativ auf die Zuverläs­sigkeit, Funktionalität und Übertragbarkeit eines Softwaresystems aus.

2.2.2 Weiterentwicklung und Wartung von Software

Die Qualität der Dokumentation, die teilweise die Güte der Qualitätsmerkmale Änderbarkeit und Benutzbarkeit widerspiegelt, wirkt sich bei der Wartung eines Systems indirekt auf die Funktionalität, Übertragbarkeit und Zuverlässigkeit des Softwaresystems aus. Beispielsweise können wichtige Informationen, die das System betreffen, für den Wartungsprozess verloren gegangen sein, die eigentlich in der Dokumentation hätten zu finden sein müssen. Dadurch kann die Wartung oder Weiterentwicklung des Systems erschwert werden. Darüber hinaus kann die Lösung, aus Unwissenheit über die Konzeption des Gesamtsystems, parallel zu ei­nem bereits existierenden Lösungsansatz des Systems implementiert worden sein. Oder aber die Information in der Dokumentation sind inaktuell oder falsch und daher nicht für die aktu­elle Systemversion verwendbar. Im schlimmsten Fall wird dies nicht bemerkt und auf Grund falscher Annahmen wird das System geändert und damit fehleranfälliger. Es ist aber auch möglich, dass viel Zeit in die Weiterentwicklung des Systems unter Betrachtung der falschen Annahmen investiert und erst zu einem späterem Zeitpunkt in der Weiterentwicklung dieser Fehler bemerkt wird. Die Folgen können zum Scheitern des Projektes oder aber zu einer enor­men Kostenexplosion führen.

Die Mängel in Aktualität sowie Richtigkeit einer Dokumentation können während der War­tung des Softwaresystems Auswirkungen auf die spätere Qualität des Systems haben. Daher sollten diese Faktoren bei der Erstellung der Dokumentation in der Implementierungsphase und bei nötigen Anpassungen der Dokumentation infolge Änderungen des Systems bei War­tungsaktivitäten berücksichtigt werden. Ist dies nicht der Fall, kann mangelnde Professionali­tät im Umgang mit der Dokumentation eines Softwaresystems, wie dargestellt, zu erheblichen Problemen führen. So kann z.B. die lose Verbindung von Dokumentation und Quellcode, da keine direkte Verbindung zwischen Dokumentation und Quellcode besteht, die Umsetzung der geforderten Belange erschweren. Ziel ist es, durch die in Kapitel 3 vorgestellte quellcode­gebundene Dokumentation von Aspekten, dieses Problem zu beheben. Die Idee ist dabei, den Quellcode in der Entwicklungsumgebung sichtbar mit Information zu verknüpfen.

2.3 Vorgehensmodelle in der Softwaretechnik

Vorgehensmodelle beschreiben einen festgelegten organisatorischen Rahmen der Softwareent­wicklung. Festgelegt wird, welche Aktivitäten in welcher Reihenfolge von welchen Rollen zu erledigen sind und welche Ergebnisse dabei entstehen und wie diese in der Qualitätssicherung überprüft werden [Imb04]. Damit strukturiert ein Vorgehensmodell den Entwicklungsprozess konzeptionell. Vorgehensmodelle bauen zum Großteil auf grundlegenden Arbeitsschritten bzw. Phasen auf. Zu diesen Phasen zählen die Analyse-, Entwurfs-, Implementierungs- und die Testphase. Diese Phasen zusammengenommen und die Ordnung ihrer zeitlichen Abfolge bezeichnet man als Software-Lebenszyklus [MayOl]. Die meisten Vorgehensmodelle beinhal­ten darüber hinaus übergeordnete Bereiche wie das Projektmanagement, die Arbeitsorganisati­on und die Qualitätssicherung. Das Ziel eines definierten Vorgehensmodells ist die Erhöhung der Qualität der zu erstellenden Software durch bessere Transparenz und Steuerbarkeit der Softwareentwicklung [Lux02]. Durch die Verwendung eines Vorgehensmodells soll die Pro­jektplanung und Durchführung kontrollierbarer und planbarer werden. Durch die Festlegung planbarer Einzelschritte wird für alle beteiligten Parteien klarer, wann, was und wie bearbeitet werden muss und welche Arbeitsschritte auf welchen anderen aufbauen. Im weiteren sollen die bekanntesten Vorgehensmodelle kurz vorgestellt werden, um die möglichen unterschiedli­chen Vorgehensweisen in der Softwareentwicklung darzulegen. Ziel dabei ist es aufzuzeigen, weshalb manche Vorgehensmodelle die Erstellung einer Dokumentation berücksichtigen und andere wiederum nicht und welche Vorgehensmodelle das im Einzelnen sind. Zusätzlich soll festgestellt werden, in welchen Phasen der Vorgehensmodelle die Erstellung einer Dokumen­tation geplant ist und wie der Aspekt der Wartung im Zusammenhang mit der Dokumentation eines Softwaresystems berücksichtigt wird.

2.3.1 Betrachtung der unterschiedlichen Vorgehensmodelle

Es sollen im Weiteren die folgenden sehr bekannten Vorgehensmodelle unter dem Aspekt der Dokumentation von Softwaresystemen betrachtet werden:

- Build-and-Fix-Cycle - chaotisches Vorgehensmodell
- Phasenmodell - sequenzielles Vorgehensmodell mit strikter Trennung der Arbeitsschritte
- Wasserfallmodell - sequenzielles Vorgehensmodell mit Trennung der Arbeitsschritte und der Möglichkeit in vorhergehende Phasen zurückzuspringen
- V-Modell und das W-Modell- sequenzielle Vorgehensmodelle mit starker Einbeziehung von Softwaretests
- Spiralmodell - evolutionäres Vorgehensmodell, das interatives Vorgehen ermöglicht.

Darüber hinaus werden die zwei derzeit populärsten Vorgehensmodelle, der Rational Unified Process (RUP) und Extreme Programming (XP) betrachtet. Die Ansätze beider Prozesse könnten nicht gegensätzlicher sein. Beim RUP handelt es sich um einen schwergewichtigen Entwicklungsprozess und bei XP um einen leichtgewichtigen (agilen) Prozess. Beim agilen Entwicklungsprozess XP werden zielorientiert nur benötigte Produkte erzeugt und so lange gepflegt, wie diese einen Nutzen für das Projekt haben. Der Ration Unified Process dagegen ist ein schwergewichtiger Prozess, der relativ viel bürokratischen Aufwand erfordert. Dabei reichen die Aufgaben von der Erstellung einer Kostenabschätzungen über die Anfertigung von Prüfberichten bis zur Erzeugung von Visionsdokumenten.

Zunächst wird der Build-and-Fix-Cyle betrachtet, ein sehr chaotisches Vorgehensmodell.

Build-and-Fix-Cycle

Unter dem Build-and-Fix-Cycle Vorgehensmodell ist das einfache Implementieren einer Idee, die der Programmierer im Kopf hat, zu verstehen. Der Programmierer definiert keine explizi­ten Qualitätsanforderungen und arbeitet so lange am System, bis es seinen Vorstellungen ent­spricht. Es werden keine Analysedokumente, Entwurfsdokumente oder eine Dokumentation erstellt. Das Vorgehen des Entwicklers folgt keinem einheitlich geplanten Vorgehen. Der Hin­tergrund dieses Vorgehens ist das einfache und schnelle Implementieren einer eigenen Soft­warelösung, an die keine nennenswerten Ansprüche gestellt werden. Meist werden aus den kleinen Softwarelösungen größere Projekte und das chaotische Vorgehen am Anfang hat gro­ße Auswirkungen auf die spätere Weiterentwicklung. Daher ist dieses Vorgehensmodell auf Grund seines chaotischen Vorgehens fur jedwedes professionelle Softwaresystem abzulehnen.

Phasenmodell

Das Phasenmodell wurde auf Grund der Anforderungen, Projekte der öffentlichen Hand nach einheitlich Richtlinien abwickeln zu können, entwickelt. Dem Vorgehen des Phasenmodells liegt die Idee zugrunde, dass die Softwareentwicklung in genaue Phasen geteilt werden kann. Jede Phase liefert ein klar definiertes Ergebnis, ohne das nicht in die nächste Phase überge­gangen werden kann. Diese Ergebnisse sind zu meist wohldefinierte Dokumente. Ziel des Phasenmodells ist es, Softwareprojekte einfacher planbar, organisierbar und kontrollierbar zu machen. Dieses Vorgehen führt dazu, dass erst sehr spät greifbare Produkte entstehen. Das macht es sehr schwierig, frühzeitig auf Änderungswünsche des Kunden reagieren zu können. Darüber hinaus kann nach der Planungsphase nicht mehr auf geänderte Kundenanforderungen reagiert werden, da ein Rückschritt in eine frühere Phase nicht möglich ist.

Bei der praktischen Umsetzung zeigt sich aber, dass das strenge Trennen der einzelnen Phasen sich als sehr nachteilig auswirkt, da dadurch ein Reagieren auf Änderungen und späte Ent­scheidungen so gut wie nicht möglich ist. Die Dokumentation wird beim Phasenmodell in der Implementierungsphase erstellt. Problematisch für die Dokumentation ist es, wenn durch die strenge Trennung der Phasen mögliche Veränderungen am Quellcode nicht mehr in der Doku­mentation vermerkt werden, wenn diese beispielsweise in der Wartung durchgeführt werden. Darüber hinaus erweist sich die Trennung der einzelnen Dokumente (Pflichtenheft, Dokumen­tation, uvm.) als nachteilig für den Informationsfluss, da eine Vernetzung der Information nur sehr schwierig realisierbar ist. Dieses Vorgehensmodell ist abzulehnen, da nicht im angemes­senen Rahmen auf die heutigen Kundenanforderungen reagiert werden kann und damit schon von vornherein klar ist, dass das Vorgehen zergliedert wird und damit außerhalb der eigentli­chen Planung erfolgt. Darüber hinaus widerspricht die starre Trennung der Phasen dem nor­malen Umfeld der Softwareentwicklung.

Wasserfallmodell

Das Wasserfallmodell ist eine Weiterentwicklung des sequenziellen Phasenmodells. In ihm sind Rückschritte aus einzelnen Phasen in darüber liegende Phasen möglich. Um eine Kosten­explosion zu vermeiden, sollten die Rückschritte möglichst nicht über mehrere Phasen erfolgen. Zusätzlich wurde die Validierung der Ergebnisse der einzelnen Phasen eingeführt, um die Auswirkungen von Fehlentscheidungen zu begrenzen und den Softwareprozess besser kon­trollieren zu können. Dabei ist festzustellen, dass sich das Wasserfallmodell besonders für kleinere Teams eignet, die gemeinsam an allen Phasen arbeiten können [MayOl]. Wie beim Phasenmodell ist die starre Teilung in Phasen nachteilig für mögliche späte Änderungswün­sche, da diese sehr teuer werden. Daher eignet sich das Modell vor allem für Projekte mit klar definierten Zielen. Die Dokumentation des Systems erfolgt auch beim Wasserfallmodell in der Implementierung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Wasserfallmodell

V-Modell und W-Modell

Das V-Modell gliedert den Entwicklungsprozess in die Phasen Anforderung, Grobentwurf, Feinentwurf, Modulspezifikation und Programmierung sowie Modultest, Integrationstest, Sys­temtest und Abnahmetest. Dabei bilden die Tests die Qualitätskontrolle der dazugehörigen Entwicklungsphasen und entsprechen den unterschiedlichen Sichten auf das System. Ziel des Vorgehens ist es, die Umsetzung der einzelnen Entwicklungsphasen durch geeignete Testpha- sen zu kontrollieren und damit die Produktqualität zu verbessern. Die einzelnen Entwick­lungsphasen sind dabei wie beim Wasserfallmodell streng gekapselt und folgen einem sequen­ziellen Ablauf. Dadurch ist es sehr schwierig, auf Änderungen der Anforderungen zu reagieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: V-Modell

Darüber hinaus werden wichtige das System betreffende Informationen, wie beim Wasserfall­modell in unterschiedlichen Dokumenten festgehalten, da sie in unterschiedlichen Phasen er­stellt werden. In den Anforderungsdokumenten sind beispielsweise keine Rückschlüsse auf Implementierungsentscheidungen möglich. Auch die Dokumente des Grobentwurfes ermögli­chen keine Rückschlüsse auf die direkte Implementierung und so können mögliche Änderun­gen des Designs wegen Problemen bei der Implementierung dort nicht beschrieben sein. Für die Wartung des Systems sind die existierenden Tests für die einzelnen Entwicklungsphasen von Vorteil, da diese als Regressionstest verwendet werden können. Auf die Wartungsaktivi­täten von Systemen geht das Modell aber nicht weiter ein. Insgesamt stellt die Kontrolle der einzelnen Phasen durch Tests eine zu begrüßende Erweiterung gegenüber dem Wasserfallmo­dell dar. In punkto Flexibilität des Entwicklungsprozesses wurden aber keine Fortschritte ge­genüber dem Wasserfallmodell erreicht.

Das W-Modell stellt eine Erweiterung des V-Models dar. Ziel des W-Modells ist die frühe Planung des Testes der einzelnen Entwicklungsphasen, um eine mögliche Aufwandsabschät­zung für die späteren Tests aufstellen zu können. Parallel zu den Entwicklungsphasen Anfor­derungsdefinition, Grobentwurf, Feinentwurf, Modulspezifikation wird die Planung der jeweiligen Teststrategien für die einzelnen Phasen betrieben. Dadurch kann das Risiko für die spätere Testphase minimiert und Probleme, die das Systemumfeld betreffen, früh erkannt wer­den. Von Vorteil ist es, dass dadurch die Testbarkeit des Systems frühzeitig im Auge behalten wird. Durch dieses Vorgehen ist es möglich, das Softwaresystem umfangreicher zu testen als es durch das V-Modell möglich ist, da das System in punkto Testbarkeit von Anfang an opti­miert wird. Für die Belange der Dokumentation eines Softwaresystems hat sich beim W-Mo- dell gegenüber dem V-Modell nichts geändert. Weiterhin wird die Dokumentation des Systems seitens des Vorgehensmodells eher vernachlässigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: W-Modell

Spiralmodell

Das Spiralmodell ist ein Vorgehensmodell, das es ermöglicht, während des Entwicklungspro­zesses auf notwendige Änderungen einzugehen und damit versucht, mögliche Projektrisiken zu minimieren. Es handelt sich beim Spiralmodell um einen evolutionären Entwicklungspro­zess. Die Entwicklung eines Softwaresystems erfolgt dabei in einzelnen Zyklen und das Sys­tem entwickelt sich von Prototyp zu Prototyp, bis es den Anforderungen des Kunden entspricht und ausgeliefert werden kann. Vorteilhaft ist dieses Vorgehen vor allem dann, wenn der Kunde nicht genau sagen kann, was er will, aber wenn er das System „anfassen und sehen“ kann, dann genau weiß, wie es auszusehen hat. Darüber hinaus ermöglicht das Spiral­modell einen fließenden Übergang in die Wartungsphase. Die Wartung stellt einen weiteren Entwicklungszyklus im Spiralmodell dar. Ein Zyklus des Spiralmodells besteht aus folgenden Teilen:

1. Bestimmung der Ziele, Alternativen und Restrisiken des aktuellen Entwicklungszyklus
2. Bewertung der Alternativen sowie Identifizierung und Beseitigung von Restrisiken
3. Entwicklung des Produktes und Prüfung der nächsten Produktstufen
4. Planung des nächsten Entwicklungszyklus

Ein Zyklus kann dabei als Vorgehensmodell beispielsweise das Wasserfallmodell oder aber das V-Modell bzw. W-Modell zu Grunde liegen haben [ZusOl]. Die Anzahl der Zyklen bis zum fertigen Produkt sind beliebig und hängen von den auftretenden Problemen und Anforde­rungen des Kunden ab. Problematisch ist, dass beim Spiralmodell eine genaue Abschätzung der Kosten und des Zeitbedarfs nur mit viel Erfahrung möglich ist.

Abbildung in dieser Leseprobe nicht enthalten

Die Dokumentation wird beim Spiralmodell von Zyklus zu Zyklus weiterentwickelt und damit gut in den Entwicklungsprozess mit integriert. Darauf zu achten ist, dass die möglichen Risi­ken und Alternativen aus der 2. Phase, die nicht implementiert wurden, mit Begründung in der Dokumentation festgehalten werden, um so die Hintergründe für die Entscheidung transparent und nachvollziehbar aufzubewahren. Die Verwendbarkeit des Spiralmodells auch für die War­tung eines Softwaresystems ermöglicht die Integration der Dokumentation des Systems in den Wartungsprozess. Die Wartung stellt dabei einfach einen weiteren Zyklus im Spiralmodell dar. Ein Zyklus im Spiralmodell wird durch das Wasserfallmodell oder auch jedes beliebige andere Vorgehensmodell beschrieben. Bei der Dokumentation sollte darauf geachtet werden, dass sich der Dokumentationspozess vollständig durch einen Zyklus des Spiralmodells zieht und damit in alle Phasen des verwendeten Vorgehensmodells integriert wird. Nur so können alle getroffenen Anforderungen, Entscheidungen und Implementierungsdetails dokumentiert werden und die vollständige Bewahrung des Wissens wird möglich.

Extreme Programming (XP)

Extreme Programming ist wie dargestellt ein leichtgewichtiger respektive agiler Entwick­lungsprozess bzw. ein Vorgehensmodell, das erst mit der objektorientierten Softwareentwick­lung und der Möglichkeit, Quellcode zu refaktorisieren [FowOO], Einzug in die Softwareentwicklung gehalten hat. XP ist ein quellcode- und testgetriebener iterativer Ent­wicklungsprozess. Die Idee von XP ist es, die Iterationen sehr klein zu halten, um auf Ände­rungen des Kunden, der in den Entwicklungsprozess mit eingebunden wird, reagieren zu können. Die maximale Teamgröße beträgt etwa 15 Entwickler.

XP erfreut sich unter den Entwicklern großer Beliebtheit, da der Wegfall der als so störend empfundenen bürokratischen Zwänge (Erzeugung von Analyse-, Design- und Entwicklungs­dokumente) die Arbeit des Entwickler wieder auf das Wesentliche, die Implementierung des Softwaresystems konzentriert. Zu beachten ist dabei aber, das noch viele andere kleine Merk­male des Prozesses erst das Umfeld schaffen, in dem XP gedeihen kann. Darüber hinaus ver­langt der Prozess von den Entwicklern viel Disziplin und Erfahrung.

Das Risiko der Entwicklung, auf späte Anforderungen des Kunden nicht mehr reagieren zu können, soll durch die iterative Entwicklung und direkte Einbeziehung des Kunden in den Entwicklungsprozess minimiert werden. Darüber hinaus soll bei der Implementierung des Systems immer auf den einfachsten Ansatz gesetzt werden und komplexere Probleme durch die Verwendung von Entwurfsmustern der Schrecken genommen werden. Ziel ist, so das Ver­ständnis für das System und seine Erweiterbarkeit zu erleichtern. Kernbestandteil von XP ist u.b. das Arbeiten in einem Team und in einem den menschlichen Bedürfnissen angepassten Umfeld. Das fängt beim paarweisen Programmieren (Paar-Programming) [KirOl] an und geht über eine definierte 4O Stunden-Woche bis hin zur gemeinsamen Planung der nächsten Iterati­on durch Story- und Aufgabenkarten (Task Cards). Ein Unterschied zum Spiralmodell ist die testgetriebene Entwicklung. Das heißt, dass zuerst der Test des zu implementierenden Quell­codes implementiert wird und die Implementierung selbst dann fertig ist, wenn der Test erfüllt wird [EH01].

Die Dokumentation in XP hat keine direkte Bedeutung, da der Prozess den Quellcode als Do­kumentation des Systems versteht. Wenn der Auftraggeber eine Dokumentation des Systems verlangt, wird dies als extra Feature bzw. eigenes Produkt betrachtet, für das eine Zeit- und Kostenplanung erstellt wird. Der Gedanke von XP ist es, gerade durch den einfach gehaltenen Quellcode mögliche Wartungsaktivitäten zu vereinfachen. Darüber hinaus soll durch die Ein­beziehung des ganzen Teams in die Implementierung wie auch das paarweise Programmieren jedem Entwickler das vollständige Verstehen des Quellcodes ermöglicht werden, da so der Verlust eines Entwicklern oder auch mehrerer Entwickler kompensiert werden kann. Leider fehlen die direkten Verbindungen von Quellcode und Storys sowie von Quellcode und Aufga­benkarten (Task Cards), aber auch die Dokumentation von Entscheidungen und Erklärungen zur Implementierung. In der Diplomarbeit von Ebel „Aufgabenorientierte Verknüpfung von Anforderungen und Programmcode auf Basis einer Wissensmanagementumgebung“ [Ebe04] wird die Verbindung von Story sowie Task Cards und Quellcode untersucht. Die Verknüp­fung von Quellcode und Dokumentation beleuchtet und veranschaulicht diese Arbeit in Kapi­tel 3.

Rational Unified Process (RUP)

Der Rational Unified Process (RUP) [RUP] ist ein ein iteratives, inkrementelles, Anwen­dungsfall getriebenes und Architektur zentriertes Vorgehensmodell für objektorientierte Soft- ware[BEM03]. Ziel ist es, die Produktivität des Entwicklers zu erhöhen und dem Projektleiter Kontrollmöglichkeiten für die Planung und die Ergebnisse des Projektes an die Hand zu ge­ben. Dies wird durch die folgenden Eigenschaften von RUP unterstützt werden:

- generisches Prozess-Modell
- ergebnisorientiert
- Unified Modelling Language ™ (UML ®) ist die zentrale Notation [UML]
- Use Cases basiert
- unterstützt den prototypischen Ansatz
- vollständige Werkzeugunterstützung

RUP unterscheidet den Softwareentwicklungsprozess in zwei Dimensionen, die Zeitachse (Phasen) und die Arbeitsinhalte (Workflow). Die zeitlichen Aspekte werden in RUP in Phasen zusammengefasst. Dabei besteht das Vorgehensmodell aus folgenden Phasen:

- Konzeptionsphase
- Entwurfsphase
- Konstruktionsphase
- und Übergangsphase.

Die vier Phasen werden jeweils von einem Meilenstein abgeschlossen. Für die einzelnen Pha­sen ist genau definiert, welche Ziele verfolgt, welche Aufgaben erfüllt und Ergebnisse erwar­tet werden. Die Anforderungen, die ein Meilenstein erfüllen muss, schreibt RUP fest vor. Dadurch ist für jede Arbeitsphase klar definiert, welche Aufgaben respektive Anforderungen zu erfüllen sind. Die zweite Dimension der Arbeitsinhalte umfasst die Kernarbeitsabläufe und die unterstützenden Kernarbeitsabläufe. Zu den Kernarbeitsabläufen (Core Process Workflow) gehören die Geschäftsprozessmodellierung (Business Modeling), die Erfassung der Anforde­rungen (Requirements), die Analyse sowie das Design (Analysis & Design), die Implementie­rung (Implementation), der Test (Test) und die Verteilung (Deployment).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 Rational Unified Process (RUP)

Die Kernarbeitsabläufe (Core Supporting Workflows) bestehen aus dem Konfigurationsmana­gement sowie Änderungsmanagement (Configuration & Change Management), dem Projekt­management (Project Management) und dem Umgebungsmanagement (Enviroment). Die Schwerpunktverteilung der einzelnen Arbeitsabläufe über den Projektverlauf hinweg kann man der Abbildung 7 entnehmen. XP wird durch eine komplette Werkzeugpalette in der Bear­beitung der einzelnen Phasen und Arbeitsabläufe unterstützt und damit können die unter­schiedlichen Informationen miteinander vernetzt werden. Die Werkzeugunterstützung und Vernetzung und ist ein enormer Vorteil des Prozesses. Als nachteilig erweisen sich aber leider die hohen Kosten für die Werkzeugeinführung.

RUP hält eine Vielzahl von Informationen und Hintergründen in Dokumenten fest. Der Pro­zess wird so kontrollierbarer und abschätzbarer. Inwieweit die Dokumente miteinander ver­netzt werden können, hängt von der technischen Umsetzung ab. Eine direkte Verbindung von Quellcode und Dokumentation wäre dabei von einem enormen Vorteil. Die Fülle an doku­mentierten Entscheidungen ermöglicht es, die Wartung des Systems gut zu unterstützen, wenn die Dokumentation vollständig und aktuell ist. Der Rational Unified Process erstellt eine gro­ße Fülle an Dokumenten. Ob eine Straffung für das Verständnis nicht sinnvoll wäre, soll an dieser Stelle dahingestellt bleiben. Der Aufwand, der für die Softwareentwicklung getrieben wird, ist im Gegensatz zu XP sehr hoch.

2.3.2 Zusammenfassung

Die vorgestellten Vorgehensmodelle berücksichtigen die Erstellung einer Dokumentation mehr oder weniger. Bei XP wird die Dokumentation im Prozess selbst nicht direkt berück­sichtigt und RUP hält eine Vielzahl von Einzelheiten fest. Das Wasserfallmodell, das V-Mo- dell sowie das W-Modell berücksichtigen die Dokumentation nur in der Implementierungsphase. Dort ist aber keine direkter Rückschluss auf Entscheidungshinter­gründe aus erster Hand möglich. Darüber hinaus wird keine Aussage darüber getroffen, wie die Dokumentation in der Wartungsphase zu behandeln ist. Festzuhalten bleibt, dass die Do­kumentation meist als losgelöstes Produkt von der eigentlichen Software betrachtet wird und auf das Problem der fortlaufenden Dokumentation in den Vorgehensmodellen nicht eingegan­gen wird. Um dies zu ändern, stellen Vorgehensmodelle den Ausgangspunkt bei der Einfüh­rung und Durchsetzung veränderter Arbeitsweisen dar. Um die Wissensbewahrung stärker in der Softwareentwicklung zu etablieren, sollte für die einzelnen Phasen eines Vorgehensmo- dells klar dargelegt werden, welche Informationen sinnvollerweise bewahrt werden sollten. Der Prozess der Informations- und Wissensbewahrung wird aber immer stark von den einzel­nen Mitarbeitern und deren Sensibilisierung fur diese Problematik sowie dem Arbeitsumfeld abhängen.

2.4 Einwirkungen des Menschen und des Arbeitsumfeldes auf die Dokumentation in der Softwareentwicklung

Die Dokumentation von Software ist ein Prozess, der beeinflusst wird durch die Softwareent­wicklung, das Arbeitsumfeld, die menschlichen Bedürfnisse und Interessen, aber auch durch die technischen Gegebenheiten. Diese Ansichten werden seit Ende der 60er Jahre, als auf Grund der Softwarekrise zwei Arbeitskonferenzen zum Thema Software Engineering in Gar­misch und Rom stattfanden, heiß diskutiert. Auf den Arbeitskonferenzen wurden zwei grund­sätzliche Hauptursachen für die Probleme verantwortlich gemacht. Ein Teil der Teilnehmer war der Ansicht, dass die Probleme der Softwaretechnik auf Probleme mit der Kommunikati­on, Kooperation und Organisationsstruktur zurückzuführen sind. Die anderen Teilnehmer wa­ren der Auffassung, dass die Krise auf fehlende Software-Technologien zurückzuführen ist [PAS94]. Allein diese intensiv geführte Diskussionen macht klar, dass es wohl beide Faktoren sind, die enormen Einfluss auf die Softwareentwicklung haben. In diesem Kapitel werden da­her das Umfeld der Softwareentwicklung und der Dokumentation von Software sowie die Einflüsse auf diese Faktoren beleuchtet.

Einer aktuellen Studie (An der Studie haben insgesamt 2001 Frauen und Männer über 18 Jah­re teilgenommen.) aus dem Jahr 2003 von Gallup [Gallup] zufolge machen 70 Prozent der deutschen Arbeitnehmer nur Dienst nach Vorschrift. Festgestellt wurde dabei, dass Chefs sel­ten andere Meinungen zulassen und die Vorgesetzten kaum Interesse am Mitarbeiter selbst zeigen. Dadurch fühlt sich der Arbeitnehmer nicht mit dem Unternehmen verbunden und macht nur die ihm aufgetragenen Aufgaben, also Dienst nach Vorschrift. Der Schaden, der da­bei für die Wirtschaft durch Fehlzeiten und niedrige Produktivität entsteht, wird mit etwa 220 Milliarden Euro jährlich angegeben. Diese Problematik hat natürlich auch Einfluss auf einen kreativen Prozess wie die Softwareentwicklung und die Dokumentation von Softwaresyste­men und sollte daher keinesfalls vernachlässigt werden (siehe Kapitel 2.4.1).

Für die Softwareentwicklung und damit auch für die Dokumentation hat die Organisation von leistungsfähigen Teams eine gewichtige Bedeutung. Die Art, wie ein Team organisiert ist, legt fest, wieviel Einfluss ein einzelner Entwickler auf die Entwicklung eines Softwaresystems hat (siehe Kapitel 2.4.2). Darüber hinaus haben bestimmte grundlegende Ansichten des Arbeitge­bers sowie des Kunden Auswirkungen auf die Erstellung der Dokumentation. Wird die Doku­mentation eines Softwaresystems beispielsweise als sinnlos und unnötig generell abgelehnt, wird dem Entwickler, selbst wenn er eine Dokumentation erstellen möchte, die Zeit dafür feh­len, weil für ihn vom Projektleiter die notwendige Entwicklungszeit nicht eingeplant wurde (siehe Kapitel 2.4.3). Auf Seiten des Kunden kann die Meinung vorherrschen, dass die Erstel­lung einer Dokumentation so nebenbei passiert und keine Kosten verursacht. In einem solchen Fall gerät der Auftragnehmer enorm unter Druck. Der Auftragnehmer sollte daher versuchen, dem Kunden klar zu machen, dass die Erstellung der Dokumentation geplant werden muss und Kosten verursacht. Zusätzlich sollte er die Gründe für eine Dokumentation von Software­systemen stärker hervorheben und die Einsparung von Kosten bei der Wartung darlegen (siehe 2.4.4).

Es zeigt sich, dass viele nicht sofort erkennbare Faktoren Einfluss auf die Softwareentwick­lung und damit auf die Erstellung der Dokumentation haben. Gerade die Erstellung einer Do­kumentation ist bei Softwareentwicklern keine beliebte Arbeitsaufgabe. Daher sollte versucht werden, das Umfeld, in der die Dokumentation erstellt wird, so zu optimieren, dass der Soft­wareentwickler sich aufgehoben fühlt und auch diese Arbeit gern und zielstrebig erledigt.

2.4.1 Mensch

Der Mensch ist ein Lebewesen, das Bedürfnisse hat. Diese Bedürfnisse haben sich im Laufe der Zeit erweitert und verändert. Die Maslowsche Bedürfnispyramide (siehe Abbildung 8) geht von der Annahme aus, dass Menschen danach suchen, unbefriedigte Bedürfnisse zu be­friedigen. Sofern eine Person die dauerhafte Befriedigung einer der aufgeführten Bedürfnisse als weitgehend sichergestellt ansieht, verliert diese Bedürfniskategorie ihre handlungsmoti­vierende Wirkung. Allerdings können Veränderungen der Lebenssituation wie Krieg, Arbeits­losigkeit etc. dazu führen, das ein ehemals befriedigtes Bedürfnis erneut als unbefriedigt angesehen wird, und somit eine erneute handlungsmotivierende Bedeutung erhält [MotOl].

Damit sich die Motivatoren (siehe Abbildung 8) Wertschätzung und Selbstverwirklichung entfalten können, müssen die Defizitbedürfnisse erfüllt sein. Zu den Defizitbedürfnissen, die durch das Arbeitsumfeld beeinflusst werden können, gehören die Sicherheitsbedürfnisse (kein Angst um den Arbeitsplatzes und das Einkommen) und die sozialen Bedürfnisse (Zusammen­halt & Kontakt mit Menschen, Akzeptanz). Dadurch werden aber auch die physiologischen Bedürfnisse (Bedürfnis nach Nahrung, Wohnung und Kleidung) beeinflusst, da erst durch das Gehalt die Möglichkeit geschaffen wird, sich Nahrungsmittel und Kleidung zu kaufen. Das bedeutet, dass das Arbeitsumfeld Einfluss auf alle Defizitbedürfnisse haben kann. Wenn die­ser Einfluss aber negativ ist, ist es nicht möglich, die Motivatoren zu aktivieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Maslowischen Bedürfnispyramide

Durch das Ansprechen der Motivatoren können aber die Mitarbeiter stärker daran interessiert werden, sich für das Unternehmen einzusetzen. Das Aktivieren der Motivatoren im Arbeits­umfeld geschieht durch das Ansprechen der Wertschätzungsbedürfnisse (Anerkennung des Menschen, seiner Leistung, Einräumen von optionalem Gestaltungsspielraum) und der Selbst­verwirklichungsbedürfnisse (freie Gestaltung der Arbeit, Verantwortung) wodurch die Mitar­beiter über die „Dienst nach Vorschriftschwelle“ gehoben werden und so in besonderem Maße zum Unternehmenserfolg beitragen können. Gerade dies scheint aber in vielen deutschen Un­ternehmen leider zu misslingen [Gallup]. Daher ist es notwendig, ein Umfeld zu schaffen, in dem sich die Softwareentwickler wohl fühlen. Die Softwareentwickler messen den Herausfor­derungen ihrer Tätigkeit eine ähnlich große Bedeutung zu wie dem Jahresgehalt [DeMOl]. Daher ist es notwendig, ihnen diese Herausforderung zu bieten, um damit mögliche negative Auswirkungen auf die Softwareentwicklung und die Dokumentation zu minimieren. Eine mangelndes Interesse bzw. fehlende Motivation, die Dokumentation zu erstellen, hat zur Fol­ge, dass wichtige Information nicht oder ungenügend festgehalten werden. Daraus können sich hohe Wartungskosten aber auch hohe Einarbeitungsaufwände für neue Mitarbeiter erge­ben. Gerade dies zu vermeiden und die Motivatoren zu aktivieren, sollte Ziel eines umsichti­gen Managements sein.

2.4.2 Teamarbeit

Die Teamarbeit stellt das grundsätzliche organisatorische Arbeitsumfeld in der Softwareent­wicklung dar. Nur durch das gemeinsame Bearbeiten von komplexen Aufgaben in einer Grup­pe von Entwicklern können diese Aufgaben gelöst werden. Für einen einzelnen Entwickler ist der Arbeitsaufwand für die Lösung der Aufgabe meist zu groß und darüber hinaus kann nicht jeder Entwickler alle erforderlichen Fähigkeiten besitzen. Der Vorteil eines Teams ist, dass durch Arbeitsteilung, Zusammenwirken von unterschiedlichen Personen sowie Ideen- und Wissensaustausch (Kommunikation) fast alle Probleme gemeinsam gelöst werden können. Ein Team ist eine harmonische Gruppe von Menschen, die sich gemeinsamen Zielen ver­pflichtet, Freude an der Arbeit hat und hervorragende Leistungen bringt [Tha02].

Teams können unterschiedlich organisiert sein. Zum einem existiert die bekannte hierar­chische bzw. autokratische Organisation von Teams, zum anderen die demokratische Organi­sation. Häufig herrscht der Glaube vor, dass die Teams im eigenen Unternehmen demokratisch agieren. Dies ist aber meist nur zwischen gleichrangigen Gruppenmitgliedern und nicht innerhalb des gesamten Teams der Fall. Das wird vor allem dann deutlich, wenn Teile des Teams an bestimmten Prozessen nicht beteiligt werden oder gar nur gefilterte Infor­mationen erhalten. Der Grund dafür liegt in den direkten und indirekten Organisationsstruktu­ren der Unternehmen und Institutionen. Direkte Organisationsstrukturen bestehen aus Hierarchien und besitzen damit eine ihnen innewohnende „Weisungsbefugnis“, durch die es zu Kommunikationsproblemen im Team kommen kann. Die strenge Hierarchie führt häufig dazu, dass Probleme und Fehler nicht oder erst sehr spät an höhere Ebenen weitergeleitet wer­den. Das haben viele Unternehmen erkannt und die Organisationsform ihrer Teams angepasst und Hierarchieebenen in ihnen minimiert oder ganz aufgehoben. Durch die Besitzstandswah­rung entstehen aber meist indirekte Organisationsstrukturen, die dazu führen, dass immer noch bestimmte Teammitglieder nicht an Entscheidungen beteiligt werden. Meist herrscht die Angst vor, sich mit zu vielen Entwicklern bei einem Meeting in unendlichen Diskussionen zu verlieren. Verkannt wird dabei aber häufig, dass durch eine wenn auch nur minimale physi­sche oder auch geistige Beteiligung aller Teammitglieder am Entscheidungsprozess das Ge­samtverständnis und die Akzeptanz für das gemeinsame Produkt steigen. Diese Akzeptanz stellt einen unschätzbaren Wert für die Produktivität dar, denn es kommt zu einem „Ein­schwören“ des Teams, weil sich alle als zum Team gehörend fühlen.

Chef-Progammierer- Team

Eine stark verbreitete Teamorganisationsform ist das Chef-Progammierer-Team, bei dem der Chef, unterstützt von einigen Assistenten, das Softwaresystem entwickelt [PAS94]. Problema­tisch ist dabei, dass alle Entscheidungen allein vom Chef, einem sehr fähigen aber nicht un­fehlbaren Entwickler getroffen werden. Darüber hinaus kennt außer dem Chef niemand das fertige Softwaresystem genau, weil keine weiteren Entwickler an allen Entscheidungen betei­ligt waren. Da stellt sich natürlich die Frage, wer bei einer möglichen Wartung des Systems diese durchführt und wie ein Informationsverlust beim Weggang des Entwicklers vermieden werden kann. Eine Lösungsmöglichkeit stellt die Dokumentation des Systems dar. Das Pro­blem dabei ist, dass nur der Chef eine qualitativ hochwertige Dokumentation erzeugen kann, da nur er alle Details des Systems kennt. Aber Zeitnot und fehlende Priorität gefährden das Erstellen der Dokumentation. Das Chef-Entwickler-Team stellt damit nicht die ideale Organi­sationsform eines Teams dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Erweitertes Chef-Programmierer-Team

Die erweiterte Form des Chef-Programmierer-Teams besteht aus einer hierarchischen Organi­sationsstruktur (siehe Abbildung 9). Dabei leitet jeder Seniorprogrammierer ein Team von Ju- niorprogammierern, die die eigentliche Implementierungsarbeit leisten. Die Entwurfsarbeit wird dabei von den Seniorprogrammierern übernommen. Das führt aber zu Problemen, da die Kommunikation zwischen den Juniorprogrammiern teilweise nur über die Zwischenebene der Seniorprogrammierer und damit gefiltert erfolgt. Hierarchische Kommunikationswege beein­trächtigen die Qualität, Quantität und Schnelligkeit des Informationsflusses [MayOl]. Zusätz­lich ist die Autonomie der Gruppen gegenüber ihrer Umwelt beim erweiterten Chef­Programmierer-Team durch die Hierarchie eingeschränkt, da immer eine Interaktion mit den anderen Gruppen bei übergreifenden Problemen notwendig ist. Für die Dokumentation des Systems bedeutet das, dass es bei der Erstellung zu Überschneidungen und Lücken in der Do­kumentation kommen kann. Grund dafür ist, dass Entwurfsentscheidungen und die Implemen­tierung dieser kein Teammitglied genau kennt. Die Juniorprogrammierer kennen nicht alle Hintergründe des Systems und die Seniorprogrammierer besitzen nicht das Detailwissen über die Implementierung. Darüber hinaus kennen die einzelnen Teams nicht die Systemteile der anderen Teams und etwaige Benutzung eigner Systemteile durch sie. Daher ist diese Art der Teamorganisation für den Austausch von Wissen und die Zusammenarbeit bei der Erstellung einer Dokumentation nachteilig. Die Folge ist eine schlechte Qualität der Dokumentation, da die Dokumentation nicht homogen wirkt.

Die demokratische Organisation von Teams

Die demokratische Organisation von Teams ermöglicht es, dass sich jedes Teammitglied in den Arbeitsprozess einbringen und je nach seinen Fähigkeiten auch die Leitung des Teams übernehmen kann [PAS94]. Diese Faktoren bewirken eine enorme Dynamik, die sich aus der Maslowischen Bedürfnispyramide (siehe Abbildung 8) ergibt. Die Vorteile einer demokrati­schen Organisation von Teams sind vielfältig. Dazu gehören das schnellere Erkennen von Fehlern, eine bessere Kontrolle der Projektfortschritte, die Minimierung der Negativefolgen eines Personalwechsels und der Anstieg der allgemeinen Arbeitszufriedenheit in der Gruppe. Auf den Strukturen eines demokratischen Teams baut die Idee des „egoless Programming“ auf. Viele Entwickler betrachten den von ihnen implementierten Quellcode als ihr Eigentum und erweitern ihr Ego um diesen. Daraus ergeben sich Probleme beim Kritisieren des Codes durch andere Entwickler. Um diese Problem zu vermeiden, soll sich der Programmierer ge­genüber seinen Kollegen öffnen und den Quellcode als Eigentum des Projektteams begreifen. Diese Öffnung des Programmierers bezeichnet man als „egoless programing“ [Wei98]. Durch das Öffnen des Programmieres ist es möglich, dass der Quellcode in der Gruppe oder von ein­zelnen Teammitgliedern geprüft werden kann, ohne dass Kritik an der Implementierung als Kritik an dem einzelnen Entwickler verstanden wird, sondern als Motivation für die Gruppe, die den Quellcode gemeinsam implementiert und auch den Fehler gefunden hat. Extreme Pro­gramming (siehe Seite 30) baut auf denselben Grundvorstellungen wie das „egoless program­ming“ und die demokratischen Teams auf und erfreut sich gerade auch wegen der damit verbundenen Möglichkeit, sich in die Entwicklung mit einzubringen, großer Beliebtheit.

Für die Dokumentationserstellung hat ein demokratisches Team einige Vorteile. Entwickler können sich beispielsweise die Arbeit teilen und sich darüber hinaus gegenseitig unterstützen und erkennen gemeinsam schneller, welche Informationen wirklich wichtig sind und welche nicht. Die Dokumentation sollte in demokratischen Teams auch dazu verwendet werden, viel hintergründiges Wissen zwischen den Teammitgliedern auszutauschen, um es damit gleich­zeitig zu bewahren. Die Teamkonstellation schafft darüber hinaus durch die enge Bindung der Teammitglieder eine Basis für den ungezwungenen Austausch von Informationen. Denn häu­fig passiert es noch, dass Informationen von einzelnen Entwicklern zurückgehalten werden, weil sie diese nicht teilen wollen, da sie glauben, sich so einen Vorteil gegenüber den anderen Entwicklern verschaffen zu können. Hilfreich ist in solchen „persönlichen“ Teams, wenn kon­textbezogene Informationen abgelegt und automatisch jedem Teammitglied zugänglich ge­macht werden können. So ist es jedem Teammitglied möglich, die Informationen anzupassen bzw. zu erweitern oder zur Diskussion zu stellen.

2.4.3 Arbeitgeber

Der Arbeitgeber hat das Ziel, aus den Aufträgen, die er bekommen hat, Gewinn zu erwirt­schaften, d.h. wirtschaftlich zu arbeiten. Um dieses Ziel zu erreichen, versucht er alle Projekte mit Erfolg im vorgegebenen Zeit- und Kostenrahmen durchzuführen. Um das zu schaffen, stellt er Teams von Entwicklern zusammen und übergibt ihnen den Projektauftrag. Ziel des Arbeitgebers ist es nun, den Teams die erforderlichen Randbedingungen zu schaffen sowie fi­nanzielle Mittel zur Verfügung zu stellen, damit sie den Auftrag erfolgreich durchführen kön­nen. Darüber hinaus wird er versuchen, seine Mitarbeiter so zu managen, dass sie gerne bei ihm arbeiten und ihre Bedürfnisse befriedigt werden (siehe Abbildung 8 Maslowsche Bedürf­nispyramide). Bei der Planung des Projektes ist drauf zu achten, dass der Arbeitgeber Men­schen und geplante Arbeitsmonate nicht gleichgesetzt, denn Menschen und geplante Arbeitszeiten sind nicht austauschbar, da immer Reibungsverluste auftreten [PAS94]. Zu enge Zeitpläne führen automatisch zu ungewollten Qualitätseinbußen.

Das Managen der Teams umfasst die Zusammenstellung der Teams, deren Einschwörung, Motivation und Konfliktbewältigung. Darüber hinaus muss ein Umfeld für das Team geschaf­fen werden, in dem es produktiv arbeiten kann. Dazu gehören Räume für die Mitarbeiter, für Diskussionsrunden, für die Präsentation, aber auch Räume, in denen sich die Mitarbeiter für eine Weile entspannen können, um danach weiterzuarbeiten. In vielen Unternehmen wurden diese Ruheräume in den letzten Jahren einführt, so zum Beispiel 1995 am Hauptsitz der IBM in der Schweiz [Sie02]. Der Erfolg gibt dem Unternehmen recht. Anzumerken ist, dass ein be­fürchteter Missbrauch völlig ausgeblieben ist. Wichtig für das Gelingen eines Projektes ist aber auch die Ausstattung mit den richtigen Hilfsmitteln. Dazu zählen beispielsweise schnelle Computer, die das Arbeiten nicht behindern oder auch Softwaresysteme, welche die Projektar­beit sinnvoll unterstützen.

Diese Faktoren mögen in erster Linie nichts mit der Erstellung von Dokumentationen von Softwaresystemen zu tun haben, beeinflussen aber diese in hohem Maße. Verstehen sich bei­spielsweise einige Teammitglieder überhaupt nicht, geht viel Zeit mit unnötigen Streitereien verloren und darunter leidet auch die Erstellung der Dokumentation. Da Dokumentation aber die Bewahrung von Informationen und Wissen ist, wird klar, dass sich Probleme im Team auch auf die Qualität der Dokumentation auswirken, da der Austausch von Informationen be­hindert wird. Eine andere Problematik kann die fehlende nötige Ruhe bei der Arbeit sein. Ste­hen den Mitarbeitern zum Beispiel nur laute Großraumbüros zur Verfügung, leidet darunter die Qualität der Dokumentation, da sich der Entwickler nicht konzentrieren kann, weil bei­spielsweise im Raum geredet, diskutiert oder telefoniert wird [DT99]. Nicht unerheblich stö­rend und Zeit fressend können veraltete Arbeitsmittel sein. Wenn beispielsweise das System (Hardware) für das Starten der Software, die zum Erstellen der Dokumentation dient, sehr lan­ge braucht, wird der Entwickler schon allein durch diese Tatsache davor zurückschrecken, das System zu benutzen. Er möchte nur ungern seinen Arbeitsprozess unterbrechen. Auf der Soft­wareseite führen veraltete und nicht den Möglichkeiten und Bedürfnissen anpassbare Software zum steten Ärgernis der Entwickler, weil die Tätigkeit des Dokumentierens unnötig erschwert wird. Alle diese Probleme haben einen negativen Einfluss auf die Dokumentationen, denn da­durch verlieren die Mitarbeiter das Interesse an diesen Aufgaben.

Den Auftraggeber (Kunden) und das Team Zusammenzufuhren und in Konfliktfällen zu ver­mitteln, ist u.a. Aufgabe des Arbeitgebers. Wichtig ist es dabei vor allem, dass die Erstellung einer Dokumentation gegenüber dem Kunden plausibel vertreten und vermittelt wird, da die Erstellung einer Dokumentation Kosten für den Kunden verursacht.

2.4.4 Kunde

Der Kunde bezahlt Geld dafür, dass der von ihm erteilte Auftrag erfüllt wird. Die meisten Softwareentwicklungsprojekte erfordern eine intensive, vorherige Abstimmung, in deren Er­gebnis ein detaillierter verbindlicher Projektplan mit definierten Meilensteinen vereinbart wird. In vielen Fällen wird ein Produkt speziell auf die Bedürfnisse und Anforderungen des Kunden zugeschnitten. Vertrauen und Zusammenarbeit spielt für das gemeinsame erfolgreiche Realisieren des Projektes eine entscheidende Rolle, dazu zählt von Anfang an ein offener Um­gang mit Problemen, Risiken und Entscheidungen, die den Projekterfolg tangieren. (Hätte bei­spielsweise Toll Collect die Bundesregierung in den Jahren 2002/03 frühzeitig über seine Probleme bei der Projektrealisierung informiert, hätte die Abschaffung der bestehenden Vi­gnette verzögert werden können, um so den finanziellen Schaden zu minimieren.) Werden Ri­siken bei der Sicherheit des Systems zugunsten der Kosten verschwiegen, kann das zu Regressansprüchen seitens des Kunden gegenüber dem Auftragnehmer führen und das Ver­hältnis so gestört sein, dass eine weitere Zusammenarbeit nicht möglich ist. Der Kunde muss gerade bei individuellen Lösungen bereit sein, eigene Mitarbeiter für die direkte Zusammenar­beit mit dem Entwicklerteam einzusetzen. Einen vorbildlichen Ansatz stellt die Grundidee von XP dar, mindestens einen Mitarbeiter des Kunden in das Entwicklerteam aufzunehmen, der jederzeit alle auftretenden Fragen beantworten oder weiterleiten kann, da gerade Software­entwicklung kein Prozess ist, der bis ins Letzte geplant werden kann. Der gemeinsame Um­gang mit Problemen ist besonders wichtig für das gegenseitige Vertrauen und für die spätere Zusammenarbeit. Wie bereits dargestellt, verursacht Softwareentwicklung einen hohen Teil der insgesamt anfallenden Kosten für ein Softwaresystem [Sne91]. Diese Kosten zu minimie­ren, Risiken und Entscheidungen zu dokumentieren, ist Bestandteil einer erfolgreichen Pro­jektrealisierung.

Denn gerade das Dokumentieren von kritischen Entscheidungen und möglichen Problemen kann für eine spätere Weiterentwicklung von enormem Vorteil sein. Dazu ist es aber erforder­lich, dass der Kunde im Einzelfall akzeptiert, dass es nicht immer die ideale Lösung gibt oder aber diese mehr kostet. Fehlt dieses Verständnis beim Auftraggeber, verführt das den Auftrag­nehmer mit einem hohem Risiko zu arbeiten. Die Folgen treten dann zumeist erst viel später zu Tage und können sehr kostenintensiv werden. Die Dokumentation ist ein sehr sensibler Produktteil. Ihre Güte und daraus entstehende Folgen hängen nicht unwesentlich von der Zu­sammenarbeit und dem Vertrauen zwischen Kunden und Auftraggeber ab. Zu beachten ist, dass verschwiegene kritische Punkte auch durch ein Reengineering des Softwaresystems meist nicht entdeckt werden können. Der Gesetzgeber hat in jüngster Zeit die Aufsichtspflicht für Unternehmen (insbesondere für Banken und Versicherungen), die ihre IT im Outsourcing be­treiben lassen, erheblich verschärft. Hauptgrundlage für die Wahrnehmung dieser Verantwor­tung sind fehlerfreie, aktuelle Dokumentationen auch von Anwendungsprogrammen.

2.4.5 Einflüsse des Arbeitsumfeldes auf die Erstellung einer Doku­mentation

Die Einflüsse des Arbeitsumfeldes auf die Dokumentation sind auf den ersten Blick meist nicht erkennbar, aber dennoch können sie, wie sich gezeigt hat, große Auswirkungen auf die Qualität der Dokumentation eines Softwaresystems und damit auf das Softwareprojekt selbst haben. Diese Einflüsse sind meist nicht nur technischer Natur. Wie aufgezeigt, wirken sich vor allem die sogenannten „weichen Faktoren“ direkt auf die Softwareentwicklung aus. Dazu gehören unter anderem die menschlichen Bedürfnisse, wie sie Maslow darstellt, aber auch der Teamzusammenhalt. Dies zu beachten ist wichtig bei der Planung und Durchführung eines Softwareprojektes. Gerade die Qualität sensibler Arbeitsergebnisse wie die Dokumentation ei­nes Softwaresystems hängt stark von den Umfeldbedingungen ab.

2.5 Informationsmanagement und Wissensmanagement in der Softwareentwicklung

Informations- und Wissensmanagement spielt in der Softwareentwicklung eine entscheidende Rolle bei der erfolgreichen Durchführung von Projekten. Gerade bei der Entwicklung von Software müssen oftmals zwischen weit voneinander getrennten Lokationen Anforderungen der Kunden, Entscheidungen aber auch Erkenntnisse zu Problembereichen kommuniziert wer­den [RL02].

Als problematisch erweist sich die Haltung zahlreicher Unternehmen gegenüber dem Wis­sensmanagement. Über 50% der Unternehmen haben kein Wissensmanagement. (Quelle: KPMG: Knowledge Management - Research Report, 1998). Die Umfrage von 1998 befasst sich zwar nicht vornehmlich mit Unternehmen aus der Softwareentwicklung, es wird aber deutlich, dass viele Unternehmen das Wissensmanagement vernachlässigen. In den letzten Jahren erst ist die Sensibilität zu diesem Thema gewachsen. Die Unternehmen fangen an zu erkennen, dass die wichtigste Ressource in innovativen Branchen wie der Softwareentwick­lung das Wissen ist. Der Erwerb von Wissen verursacht hohe Kosten. Sie können minimiert werden, wenn das Wissen nicht mehrfach bzw. wiederholt erworben werden muss. In diesem Zusammenhang stellt sich die Frage, was Wissen eigentlich ist? Probst definiert Wissen fol­gendermaßen:

„Wissen bezeichnet die Gesamtheit der Kenntnisse und Fähigkeiten, die Individuen zur Lö­sung von Problemen einsetzen. Dies umfasst sowohl theoretische Erkenntnisse als auch prak­tische Alltagsregeln und Handlungsanweisungen. Wissen stützt sich auf Daten und Informationen, ist im Gegensatz zu diesen jedoch immer an Personen gebunden. Es wird von Individuen konstruiert und repräsentiert deren Erwartungen über Ursache-Wirkungs-Zusam- menhänge.“ [PRR03]

Es wird dabei ein Unterschied zwischen explizitem und implizitem Wissen gemacht. Explizi­tes Wissen umfasst greifbares und damit beschreibbares, formalisierbares, zeitlich stabiles Wissen, welches standardisiert, strukturiert und methodisch in sprachlicher Form beispiels­weise in Dokumenten, Datenbanken und Patenten eindeutig festgehalten und repräsentiert werden kann.[PRR03] Im Gegensatz dazu ist implizites Wissen in den Köpfen von einzelnen Individuen gespeichert und beinhaltet sowohl kognitive Elemente wie subjektive Einsichten, Wahrnehmungen, Intuitionen und Gefühle. Dieses Wissen lässt sich nur schwer formalisieren und kommunizieren. Damit ist es schwierig implizites Wissen zu transportieren und anderen Arbeitnehmern zur Verfügung zu stellen.

Das Wissensmanagement hat die Aufgabe, das Umfeld und den Austausch von Wissen zu för­dern und zu organisieren. Das Wissensmanagement umfasst Maßnahmen, die es erlauben das Wissen effizient zu nutzen. Diese können dabei sowohl organisatorischer, personeller aber auch technischer Natur sein. Das kann bei der Einführung von Wissensmanagement unterstüt­zenden Organisationsformen, die die hierarchischen Strukturen minimieren, anfangen und geht bis zu gemeinsamen außerbetrieblichen Unternehmungen, die die Mitarbeiter näher zu­sammenbringen. Hauptaufgabe des Wissensmanagements ist es dabei, die Barrieren, die das Verteilen von Wissen beeinflussen, zu minimieren. Als solche haben sich in einer Umfrage die Zeitknappheit, fehlendes Bewusstsein fürs Wissensmanagement, Unkenntnis über den Wissensbedarf aber auch die Einstellung „Wissen ist Macht“ erwiesen (Quelle: Bullinger, H..- J.; Wörner, K.; Pieto, J.: Wissensmanagement heute - Daten, Fakten, Trends; Ergebnisse einer Unternehmensstudie des Fraunhofer-Instituts für Arbeitswissenschaft und Organisation in Zu­sammenarbeit mit dem Manager Magazin, 1997).

Als die klassischen Kernbausteine des Wissensmanagements verstehen sich die Wissensiden­tifikation, der Wissenserwerb, die Wissensentwicklung, die Wissensverteilung, die Wissens­nutzung und die Wissensbewahrung. Wichtig für das Wissensmanagement ist es zu erkennen, wer Wissen zu einem definierten Thema oder Problem hat. Damit kommt der Wissensidentifi­kation eine zentrale Bedeutung zu. Bei der Wissensidentifikation wird erkannt, ob und in wel­chem Umfang Wissen von außen benötigt wird. Wenn dies der Fall ist, ist es notwendig Wissen zu erwerben, was meist nicht ohne Probleme möglich ist. Daher kommt der zielge­richteten unternehmenseigenen Wissensentwicklung eine hohe Bedeutung zu. Für eine rei­bungsfreie Wissensentwicklung ist es vor allem erforderlich, dass Barrieren weggeräumt werden, um so den Wissenserwerb der Mitarbeiter bewusst zu fördern. Ein wichtiger Schritt ist dabei die Verteilung von bestehendem Wissen. Möglich wird das durch technische aber auch organisatorische Maßnahmen. Im Einzelnen kann ein Softwaresystem zum Festhalten und Austauschen von Wissen genauso wichtig sein wie das Aufheben unnötiger räumlicher Trennungen. Ist das Wissen im Unternehmen erst einmal vorhanden, muss es effektiv genutzt werden. So ist es z.B. notwendig, die richtigen Personen in die Vorbereitung wichtiger Ent­scheidungen einzubeziehen. Darüber hinaus ist die optimale Zusammenstellung von Teams und die Integration aller Mitarbeiter förderlich für die Nutzung des Wissens des Einzelnen. Damit das Wissen der Mitarbeiter z.B. beim Weggang oder durch einfaches Vergessen für das Unternehmen nicht verloren geht, muss das Wissen bewahrt werden. Die Wissensbewahrung stellt eine der schwierigsten und komplexesten Bereiche des Wissensmanagements dar. Die Wissensbewahrung ist auch einer der wichtigsten Teilbereiche des Wissensmanagements für die Softwareentwicklung. Viel Wissen ist während der Entwurfs-, Design- und Implementie­rungsphase zu einem Softwaresystem vorhanden, das zumeist dann im Laufe der Entwicklung verloren geht. Die Aufgabe der Dokumentation eines Softwaresystems ist es, diesen Verlust an Wissen zu minimieren. Dabei kommen auf den Softwareentwickler große Herausforderung zu. Er muss erkennen, welches Wissen bewahrt werden soll. Dies ist schwierig, da für den in­ternen Entwicklerkreis vieles als selbstverständlich gilt. Hilfreich dabei ist, wenn klar ist, wel­che Wissensziele erreicht werden sollen. Für die Softwareentwicklung stellt sich dabei die konkrete Frage, was soll alles dokumentiert werden. Soll z.B. nur die Struktur oder auch jedes Detail des Systems beschrieben werden? Die verschiedenen Vorgehensmodelle verwenden unterschiedliche Strategien zum Thema Wissensbewahrung. XP setzt fast vollständig auf das Entwicklerteam für die Bewahrung des Wissens und sorgt dafür, dass das Wissen an alle Teammitgliedern weitergegeben wird. RUP dagegen nutzt für die Bewahrung des Wissens die unterschiedlichen Dokumentationensmöglichkeiten eines Softwaresystems und dessen Ent­wicklungsprozess. Für die Wartung ist die Bewahrung des Wissens durch die Dokumentation von Vorteil, da das Verständnis des Systems erleichtert wird. XP dagegen setzt nur auf den Quellcode als Dokumentation, weil das Vorgehensmodell postuliert, dass die einzige wahre Dokumentation der Code selbst ist und andere Dokumentationen zum Großteil inaktuell sind.

Welche Variante im Einzelfall am effektivsten ist, kann nur ein praktischer Feldversuche klä­ren. Festzuhalten bleibt aber, dass für einen Auftraggeber in erster Linie mehr Sicherheit ge­boten wird, wenn das System dokumentiert ist, da der Quellcode keine Entscheidungen und Hintergründe festhalten kann.

Wissensmanagement zielt in der Softwareentwicklung vornehmlich auf das Dokumentieren des Softwareentwicklungsprozesses und des Systems ab. Nicht unwesentlichen Anteil am Er­folg des Wissensmanagements haben die beteiligten Entwickler selbst. Erfolgreiche Teamar­beit und Zusammenhalt zwischen den beteiligten Entwicklern fördert in hohem Maße die Kommunikationsfreudigkeit zwischen den beteiligten Personen und somit auch den Informati­ons- und Wissensaustausch. Der Weg zu einer guten Software führt über ein gutes Team. Wenn Konkurrenzdenken vorherrscht, entstehen hohe Barrieren für den Austausch von Wis­sen und Informationen. Der umgangssprachliche Ausdruck „Wissen ist Macht“ verdeutlicht im Softwareentwicklungskontext, dass Wissen die Macht darstellt, um Probleme bestmöglich lösen zu können. Wir befinden uns im Zeitalter der Wissensgesellschaft, in dem stetes Lernen und Erweitern des bestehenden Wissens wichtig für die persönliche Zukunft ist. Dies gilt auch für die Zukunft von Unternehmen und für die Qualität der von ihnen erzeugten Produkte.

2.5.1 Implementierung und Wartung

Für die Implementierung und die Wartung eines Softwaresystems ist die Bewahrung des Wis­sens der entscheidende Rentabilitätsfaktor mit Langzeitwirkung. Langfristig können nur sol­che Firmen bestehen, die ausreichende Innovationskraft besitzen und erkennen, dass ihre Mitarbeiter ein Gut darstellen, in das sie investieren müssen. Dazu gehören Schulungen und Weiterbildungen oder auch die Übernahme der Kosten für Fachzeitschriften. Wissensmanage­ment bedeutet für die Softwareentwicklung vor allem Wissensbewahrung. Nur durch die Wis­sensbewahrung können Fehler vermieden und damit die Lernkurve eines Entwicklers bei der Einarbeitung in ein System minimiert werden. Ohne den Erwerb neuen Wissens fehlt den Un­ternehmen das Know-how, um neue erfolgreiche Softwareprodukte entwickeln zu können. Wissensmanagement nimmt für die Rentabilität und die Zukunft eines Softwareunternehmens eine Schlüsselfunktion ein.

2.6 Zusammenfassung

Die dargestellten Grundlagen bilden die Voraussetzung für die Einführung einer neuen techni­schen Möglichkeit, Softwaresysteme zu dokumentieren. Dabei sollten vor allem die bestehen­den Probleme mit der Wartung von Softwaresystemen Motivation sein, einen neuen Weg bei der Dokumentation von Softwaresystemen einzuschlagen. Der bestehende Bruch zwischen Dokumentation und Quellcode erschwert das Verstehen eines Softwaresystems unnötig. Die­ser Bruch führt häufig dazu, dass die Dokumentation inaktuell ist. Gezeigt hat sich, dass die Vorgehensmodelle enormen Einfluss auf die Art der zu einem Softwaresystem erstellten Do­kumentation haben, da sie festschreiben, welche Dokumentationen wann zu erstellen sind. Für die Qualität von Softwaresystemen ist es wichtig, dass erkannt wird, welche Faktoren Einfluss auf die Softwareentwicklung und damit auf die Dokumentation von Softwaresystemen haben. Grundlegend für eine gute Dokumentation ist ein ausreichendes Verständnis für den Prozess des Wissensmanagements innerhalb der Softwareentwicklung. Die Leistungen und Fähigkei­ten der eingesetzten Mitarbeiter entscheiden, ob ein Projekt Erfolg hat oder scheitert. Wichtig ist es vor allem zu erkennen, dass trotz vieler Beteuerungen die Probleme der Softwareent­wicklung und Dokumentation von Softwaresystemen nicht nur rein technischer Natur sind. Denn ohne die Einbeziehung der Bedürfnisse der Mitarbeiter wird jeder noch so gute techni­sche Ansatz an Wirkungskraft verlieren. Ttrotzdem kann ein verbesserter technischer Ansatz die bestehenden Möglichkeiten stark erweitern.

3 Konzept einer quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen

Im Kapitel 2 wurde erläutert, dass eine Vielzahl von Faktoren Einfluss auf die Qualität sowie auf Art und Umfang einer Dokumentation eines Softwaresystems haben. Zu den direkten Ein­flussfaktoren gehören quantitative Anforderungen an ein Softwaresystem sowie Vorgehens­modelle, die festlegen, wann und wie Teile der Dokumentation erstellt werden müssen. Deutlich wurde, dass durch die Aufteilung der Dokumentation in unterschiedliche Teildoku­mente, die Phasen abhängig erstellt werden, eine Vernetzung der Informationen und des Wis­sens nicht stattfindet. Die Betrachtung der unterschiedlichen Einflüsse macht deutlich, dass die theoretischen und technischen Ansätze zum Dokumentieren von Softwaresystemen die Betrachtung der Dokumentation und der Implementierung als Einheit nicht ermöglichen. Ur­sache dafür ist, dass die Dokumentation des Softwaresystems sowie die Dokumentation der Hintergründe der Implementierung zu meist, wenn überhaupt, zeitversetzt in separaten Doku­menten erfolgt. Dabei hat sich in der Praxis herausgestellt, dass viele Hintergrundinformatio­nen zu konkreten Stellen der Implementierung eines Softwaresystems vor allem in der Wartung benötigt werden, die durchschnittlich Zweidrittel des Arbeitsumfanges eines Ent­wicklers ausmacht. Diese benötigten Informationen stehen aber in der Wartungsphase selten zur Verfügung, da wie dargestellt, die Dokumentation und der Quellcode keine Einheit bilden. Zusätzlich zeigt sich gerade bei der Wartung, dass es erforderlich ist, dass eigene Erkenntnisse und Erklärungen zu bestimmten Quellcodestellen direkt an diese gebunden und dokumentiert werden. Durch die direkte Bindung der Information an den Code können diese nicht wieder verloren gehen und stehen auch anderen Entwicklern zur Verfügung.

Der Bruch zwischen Dokumentation und Quellcode, der technischer und organisatorischer Natur sein kann, ist die Ursache dafür, dass Softwaresysteme von den Entwicklern in solchen Konstellationen im nachhinein nur schwer verstanden werden können. Dieser Bruch verhin­dert die direkte Vernetzung von Informationen aus der Dokumentation mit konkreten Quellco­destellen und die Rollenzuweisung des Quellcodes in Beziehung zu den konkreten Informationen. Festgestellt hat diese Problem auch schon Mayr und dazu angemerkt: „Bedingt durch die Komplexität moderner Softwaresysteme eignet sich sequenzieller Text immer weni­gerer zur Dokumentation. Eine moderne Systemdokumentation kann z.B. adäquat als Hyper­text in Verbindung mit automatisch extrahierter Information aus dem Quellcode erstellt werden.“ [MayOl]. Das Ziel dieser Arbeit ist es, die Dokumentationsmöglichkeiten von Soft­waresystemen zu erweitern. Dazu wird nicht wie von Mayr vorgeschlagen der Quellcode in die Dokumentation extrahiert, sondern durch die Verbindung von Dokumentation und Quell­code der Bruch des Informationsflusses vermieden. In Kapitel 3.l ist dazu dargelegt, was un­ter einer quellcodegebundenen Dokumentation zu verstehen ist und wie damit der Bruch zwischen Quellcode und Dokumentation behoben werden kann. Es wird darüber hinaus auf­gezeigt, wie einzelne Teile der quellcodegebundenen Dokumentation als Aspekte bzw. Teil­aspekte festgehalten oder diesen zugeordnet werden können und somit das konzeptionelle Gesamtverständnis des Softwaresystems erleichtert. Ein Aspekt stellt eine gedanklich kapsel­bare Einheit von Verhalten in einem Softwaresystem dar. Durch die Dokumentation von Aspekten oder der Zuordnung von Informationen zu diesen entsteht eine Dokumentation, die in die einzelnen funktionalen Bestandteile des Softwaresystems gegliedert ist (siehe Kapitel 3.2). Zur Erleichterung der Dokumentation von Information und Wissen werden darüber hi­naus Dokumentationsvorlagen eingeführt, die durch die Verwendung der quellcodegebunde­nen Dokumentation das Arbeiten und Verstehen des Quellcodes erleichtern. Diese Vorlagen ermöglichen es, der Dokumentation des Softwaresystems eine einheitliche Struktur vorzuge­ben. Durch diese einheitliche Struktur und durch die Integration der quellcodegebundenen Do­kumentation in die Entwicklungsumgebung werden den Anforderungen einer einheitlichen Dokumentation, wie sie durch Mayr [MayOl] definiert sind, Rechnung getragen.

Die quellcodegebundene Dokumentation versteht sich nicht als Ersatz für die Redokumentati- on von Quellcodes beim Reengineering, sondern als Ergänzung dazu. Die Redokumentation ermöglicht nur die Transformation des Quellcode in eine andere Darstellungsform und nicht die Wiedergewinnung von Hintergrundinformationen und Entscheidungen zum Softwaresys­tem. Durch die quellcodegebundene Dokumentation ist es aber möglich zusätzliche Quellco­destellen übergreifende Informationen zu bewahren. Durch die Bewahrung insbesondere des Wissens aus der Entwicklung wird das Verstehen des Softwaresystems erleichtert.

3.1 Quellcodegebundene Dokumentation

Die Dokumentation von Quellcode erfolgt derzeit zum Großteil durch die Kommentierung von Codestellen im Quellcode direkt (Quellcodedokumentation genannt) oder aber durch das Beschreiben des Verhaltens von Codes in separaten Dokumenten. Die Quellcodedokumentati­on ermöglicht es dabei nicht, eine Codestelle direkt mit anderen Quellcodestellen in Verbin­dung zu bringen und so das Konzept des Softwaresystems darzustellen. Die Dokumentation in separaten Dokumenten ermöglicht dagegen zwar die konzeptionelle Beschreibung des Sys­tems, nicht aber die direkte Einbeziehung der (aktuellen) Implementierung des Quellcodes. Die Folge ist ein Informationsflussbruch zwischen Dokumentation und Quellcode bzw. Imple­mentierung (siehe Abbildung 10 links).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Weg zur quellcodegebundenenDokumentation

Dieser Bruch zwischen der konzeptionellen Beschreibung des Softwaresystems und der Um­setzung im Quellcode kann durch die Verbindung von Quellcode und Dokumentation aufge­hoben werden. Die Verbindung von Code und Dokumentation vernetzt das Konzept des Systems sowie deren Beschreibung und die Implementierung miteinander (siehe Abbildung 10 rechts). Diese Vernetzung wird durch den Hypertextansatz ermöglicht. „Hypertext beruht auf der nichtlinearen Organisation von Wissen in Netzwerken (den Hypertextbasen) und auf der ebenfalls nichtlinearen Erarbeitung von Information aus den in den Netzwerken gespei­cherten Wissensobjekten .“ [Kuh02] Der Hypertextansatz ermöglicht das Verbinden von

Quellcode und Dokumentation. Dabei können von jedem Objekt (Dokumentationsstellen oder Quellcodestelle) eine beliebige Anzahl von Verknüpfungen ausgehen, so dass sich dem Nut­zer die Wahl eröffnet, der Verknüpfung zu einem neuen Objekt nachzugehen, die ihm beson­ders interessant erscheint [Kuh02]. Damit ist es nun möglich, den an einer Quellcodestelle hängenden Dokumentationen zu folgen. Mit der Dokumentation, die Information sowie Ent­scheidungen und Hintergründe zu einer Quellcodestelle enthält, können wiederum andere Co­destellen oder Dokumentationen verknüpft sein, wodurch die Codestellen über die Dokumentation miteinander vernetzt werden. Durch diese Verknüpfungen entsteht ein Wis­sensnetz, welches eine abstrakte Dokumentation des Quellcodes darstellt. Diese Verknüpfung von Quellcode und Dokumentation ermöglicht somit die quellcodegebundene Dokumentation von Softwaresystemen. Mit der Möglichkeit Verknüpfungen zu spezifizieren, wird es zusätz­lich möglich, die Rolle, die eine verknüpfte Quellcodestelle im Bezug zur Dokumentation spielt, zu definieren. Im weiteren wird diese Spezifizierung der Verknüpfung Rollenzuwei­sung einer Quellcodestelle genannt.

Durch die Verbindungen der verschieden Quellcodestellen über Dokumentationselemente bzw. Informationen werden die Codestellen, wie dargestellt, miteinander vernetzt und es ent­steht eine abstrakte Dokumentationsebene. Diese Dokumentationsebene schafft eine über die Quellcodedokumentation hinausgehende Möglichkeit, dass Softwaresystem zu beschreiben und greift damit den Gedanken von Lehner auf: „Die programminterne Dokumentation darf nicht nur auf Programmkommentare reduziert werden.“ [Leh94]. Die abstrakte Dokumentati­onsebene ermöglicht die Beschreibung der Konzepte des Softwaresystems durch die Verlin­kung von Informationen mit dem Quellcode. Unterstützt wird die Beschreibung durch die Rollenzuweisungen der einzelnen Verknüpfungen. Die Umsetzung der Idee der quellcodege­bundene Dokumentation ist das Ziel des praktischen Teils der Arbeit.

Anforderungen an eine technische Umsetzung

Die Anforderungen, die an ein Gesamtsystem zum quellcodegebundenen Dokumentieren von Software gestellt werden, sind vielfältig. Zu beachten ist dabei vor allem, dass sich das Sys­tem ohne Qualitätseinbußen für den Implementierungsprozess in die Entwicklungsumgebung einpassen lässt.

Kernanforderungen

Zu den Kemanfordernngen an ein System zur Umsetzung der quellcodegebundenen Doku­mentation gehören die direkte Verbindung von beliebigen Quellcodestellen mit beliebigen Dokumentationselementen und die Rollenzuweisungen für Quellcodestellen abhängig vom Dokumentationselement. Die direkte Verbindung von Quellcodeelementen und Dokumentati­onselementen muss durch eine m:n Verbindung zwischen den Elementen möglich sein, da nur so eine quellcodegebundene Dokumentation erreicht wird. Damit kann eine beliebige Quell­codestelle mit beliebig vielen Dokumentationsstellen verbunden sein und eine Dokumentation kann wiederum auf beliebig viele Codestellen verweisen. Darüber hinaus ist eine Rollenzu­weisung für jede Verknüpfung eines Quellcodelements mit einem Dokumentationselement nötig, um eine Einordnung der Quellcodestelle im Zusammenhang mit dem Dokumentations­element möglich zu machen.

Für die effektive Verwendung eines Werkzeugs zur quellcodegebundenen Dokumentation muss dieses Werkzeug möglichst gut in den Implementierungsprozess integrierbar sein. Im Detail beinhaltet das die Versionierbarkeit der Dokumentation parallel zum Quellcode, die In­tegration des Werkzeugs in die Entwicklungsumgebung sowie die Verwendbarkeit des Werk­zeugs im Zusammenspiel mit dem Refaktorisieren von Quellcodes. Da die Erstellung der quellcodegebundenen Dokumentation in die Implementierungsphase eines Softwaresystems rückt, ist es erforderlich, dass der Prozess der quellcodegebundenen Dokumentation in die Im­plementierungsphase integriert wird. Dazu ist es notwendig, dass die Dokumentation zum Quellcode, wie der Code selbst, versioniert werden kann, da Quellcode und Dokumentation eine Einheit bilden. Es ist erforderlich, dass beim Zurückgreifen auf eine ältere Quellcodevari­ante auch ein Zurückgreifen auf die zu dieser Quellcodeversion passenden Dokumentation möglich ist. Aus technischer Sicht ist die Versionierung der Dokumentation kein Problem. Weit schwieriger stellt sich die Problematik der Versionierung bei der Betrachtung der Doku­mentation als Medium zum Bewahren des Wissens dar. Grund dafür ist, dass die Verschmel­zung von unterschiedlichen Dokumentationsversionen nicht automatisch überprüft werden kann, da die Syntax und Semantik von Texten nicht automatisch auf ihre inhaltliche Richtig­keit überprüfbar ist. Daher wird für die Versionierung der Dokumentation unter Umständen viel „Handarbeit“ des Entwicklers erforderlich sein. Eine weitere wichtige Anforderung stellt die Verwendbarkeit des Werkzeugs im Zusammenhang mit dem Refaktorisieren des Quellco­des dar, da mögliche Zusammenhänge zwischen Dokumentation und Quellcode verändert werden. Festzustellen ist, dass das Refaktorisieren eines Quellcodes, der mit der Dokumentati­on verbunden ist, schwierig zu automatisieren ist. Dabei wäre aus technischer Sicht zu unter­suchen, ob sich die Refaktorisierungsmöglichkeiten für Quellcodes auf die folgenden drei Varianten herunterbrechen lassen.

- Verschieben der gesamten dokumentierten Quellcodestelle

In diesem Fall wird die Verknüpfung zur Dokumentation mit verschoben.

- Teilen der dokumentierten Quellcodestelle in mehrere Quellcodestellen

Die Verknüpfung zur Dokumentation wird um die Verknüpfungen der neu hinzugekom­men Quellcodestellen erweitert und zu einer Quellcodestelle wiederum zusammengefasst.

- Ersetzen und Verändern einer dokumentierten Quellcodestelle

Die alte Verbindung zum Quellcode wird durch die neue Verknüpfung zwischen veränder­ter Quellcodestelle und Dokumentation ersetzt.

Wäre dies der Fall, könnten die Verbindungen zwischen der Dokumentation und dem Quell­code aus technischer Sicht automatisch angepasst werden. Zu beachten ist dabei aber, dass durch Refaktorisierung des Quellcodes sich auch die konzeptionelle Ausrichtung des Systems ändern kann und somit die Dokumentation angepasst werden muss. Das Ändern der Doku­mentation kann dabei nicht automatisiert durchgeführt werden, sondern müsste vom Entwick­ler per Hand erfolgen. Unterstützen könnte den Entwickler dabei die Entwicklungsumgebung, indem sie die mit dem refaktorisierten Quellcode in Verbindung stehenden Dokumentatio- nenselemente als „zu überarbeiten“ kennzeichnet. Wie am Versionieren und Refaktorisieren von Quellcodes zu erkennen ist, ist die quellcodegebundene Dokumentation eine sehr imple­mentierungsnahe Tätigkeit. Diese Nähe zur Implementierung macht es erforderlich, dass ein Werkzeug zur Erstellung einer quellcodegebundenen Dokumentation in die Entwicklungsum­gebung des Entwicklers eingebettet wird. Dadurch wird die Idee, die Dokumentation in die Implementierungsphase zu integrieren, verwirklicht.

Anforderungen

Ein Werkzeug zur quellcodegebundenen Dokumentation sollte über die Kernanforderungen hinaus noch weitere Anforderungen erfüllen. Die einfache Bedienbarkeit und Erweiterbarkeit muss Ziel einer praktischen Umsetzung sein und beinhaltet die einfache Installation und Inte­gration des Systems in die bestehende Entwicklungsumgebung sowie einen standardisierten Zugriff auf das System sowie die Anpassbarkeit an die eigenen Bedürfnisse. Erforderlich für eine umfangreiche Dokumentation des Softwaresystems ist, dass das System fur die Beschrei­bung des Softwaresystems funktionale Mittel bereitstellt, die eine über die einfache textliche Beschreibung hinaus gehende Dokumentation ermöglichen. Die Integrationsmöglichkeit von externem Wissen, zum Beispiel aus dem Intranet oder Internet, sollte das Werkzeug unterstüt­zen. Darüber hinaus wäre eine persönliche Erweiterbarkeit des funktionalen Umfangs sinn­voll, damit es den Unternehmen bzw. den Entwicklern möglich ist, den Prozess der quellcodegebundenen Dokumentation an die Anforderungen des eigenen Entwicklungsprozes­ses anzupassen. Ein wichtiges Kriterium für die Qualität einer Dokumentation ist ihre Aktua­lität. Damit die Aktualität überprüft werden kann, sollten Quellcodestellenverknüpfungen Information darüber enthalten, bei welcher Codeversion die Verbindung erstellt wurde und welche Quellcodeversion die aktuelle Dokumentation widerspiegelt. Wünschenswert wäre es, wenn das Werkzeug das paarweise Programmieren, wie es aus dem Extreme Programming bekannt ist, unterstützt. Da die Dokumentation ein wichtiges Wirtschaftsgut darstellt, ist es er­forderlich, dass das System einen Schutz vor Manipulation durch unberechtigte Personen bie­tet.

Wie bereits dargelegt, ermöglicht die quellcodegebundene Dokumentation die Verknüpfung von Code- und Dokumentationselementen, stellt aber kein Konzept dar, wie das Verhalten ei­nes Softwaresystems effektiv beschrieben werden kann. Hintergrund des nächsten Kapitels ist es aufzuzeigen, wie durch die Ausrichtung der Dokumentation auf das Dokumentieren von konkreten gedanklich kapselbaren Einheiten von Verhalten, das System kurz und aussagekräf­tig beschrieben werden kann.

3.2 Dokumentation von Aspekten in Softwaresystemen

Der Aspektbegriff ist in der aktuellen Softwaretechnikdiskussion vor allem im Bereich der ob­jektorientieren Softwareentwicklung ein häufig genutzter und verschieden interpretierter Be­griff. Die wohl bekannteste Verwendung des Aspektbegriffs findet sich in der aspektorientierten Programmierung wieder. Ziel der aspektorientierten Programmierung (AOP) ist es, die Verhaltenseigenschaften eines Systems, die nicht (notwendigerweise) an funktionale Komponenten gebunden sind, wie beispielsweise die Fehlerbehandlung, Persis­tenz, Synchronization/Kommunikation, Replikation, Koordination, Speicherverwaltung und Echtzeitbedingungen als Aspekte des Verhaltens des Systems zu betrachten und getrennt zu implementieren [MarOO]. Dies ist möglich, da die Aspekte, wie dargestellt, nur eine lose Ver­bindung mit dem Softwaresystem eingehen. Es ist dabei strittig, ob die Umsetzung von Aspekten auf nichtfunktionales Verhalten beschränkt ist. Auf diese Diskussion soll an dieser Stelle nicht eingegangen werden, da sie nicht Gegenstand der Arbeit ist. Festzuhalten bleibt aber, dass in AOP implementierte Aspekte Verhalten bündeln und damit das Verständnis für die Funktionsweise des Systems erleichtern. Das Verhalten der Aspekte wird durch das Defi­nieren von Verbindungspunkten (join points) wieder an das Softwaresystem geknüpft und von einem Aspekt-Weber mit dem Programm zur Kompilier- oder aber Laufzeit verwoben [Stü02].

Das Verständnis des Aspektbegriffs aus der aspektorientieren Programmierung wird in dieser Arbeit aufgegriffen. Im Zusammenhang mit der quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen wird ein Aspekt als konkrete gedanklich kapselbare Einheit von Verhalten definiert. Ein Softwaresystem setzt sich unter diesem Gesichtspunkt aus vielen unterschiedlichen Aspekten zusammen. Den Hintergrund bildet die Erkenntnis, dass einerseits jede Quellcodestelle in objektorientierten Systemen mindestens einem oder auch mehreren Aspekten und andererseits einem Aspekt beliebig viele Quellcodestellen zugeordnet sein kön­nen. Diese Zuordnungen bilden eine gedankliche Gruppierung des Verhaltens des Software­systems. Im weiteren stellen Aspekte damit die Umsetzung von Anforderungen an ein Softwaresystem dar. Dadurch spiegeln konkrete Quellcodestellen die Umsetzung der Anforde­rungen an das Softwaresystem wider. Die abstrakte Betrachtung von Quellcodestellen als Teil eines Aspektes und damit auch als Teilrealisierung einer funktionalen Anforderungen verein­facht das Verständnis für das Softwaresystem. Durch die Dokumentation der Aspekte und Teilaspekte sowie die Rollenzuweisung der Quellcodestellen im jeweiligen Kontext, wird die bereits angesprochene abstrakte Dokumentationsebene geschaffen. Die Einbeziehung der Aspektdokumentation strukturiert die abstrakte Dokumentationsebene nach der Umsetzung von kapselbarem Verhalten des Systems, wodurch das einfachere Verstehen des gesamten Softwaresystems ermöglicht wird. Die vollständige Realisierung der dargelegten Gedanken, findet in der quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen ihre Vollendung. Die quellcodegebundene Dokumentation von Aspekten in Softwaresystemen ver­steht sich als die Dokumentation von Aspekten in Softwaresystemen und die beliebige Zu- und Einordnung in die Quellcodestellen zu dieser Dokumentation. Der Grund für die Einbe­ziehung der Aspektidee als Strukturierungsmittel in die Dokumentation begründet sich aus den Vorteilen, die sich bei der Verwendung der aspektorientierten Programmierung für das

Verständnis der einzelnen Belange gezeigt haben. Anzumerken ist, dass die aspektorientierte Programmierung nicht ersetzt, sondern ergänzt werden soll. Die Dokumentation wird durch die Verwendung der aspektorientierten Programmierung nicht hinfällig, denn gerade die Defi­nition der Erweiterungspunkte verlangt nach einer Dokumentation der Hintergründe.

Es zeigt sich, dass durch die quellcodegebundene Dokumentation von Aspekten in Software­systemen eine neuartige Chance eröffnet wird, Wissen verhaltensabhängig festzuhalten. Damit größere Aspekte auch in kleine zerlegbar und somit strukturierter festgehalten werden können, besteht die Möglichkeit, Aspekte beliebig oft in Teilaspekte zu zerlegen. In dem so entstande­nen Aspektbaum kann sich der Entwickler entlang der Äste immer detaillierter über die Ein­zelheiten und Hintergründe der Implementierung informieren. Die Verteilung von Aspekten in der Implementierung wird durch die Analyse der Quellcodeverbindungen der Aspektdoku­mentation ermöglicht. Damit ist es möglich zu erkennen, wie sich die Aspekte an den Quell­codestelle verteilen. Interessant ist dabei zu erkennen, ob ein Aspekt weit über den Code verstreut ist und ob es Quellcodestellen gibt, die mehrere Aspekte realisieren, wodurch zu er­kennen ist, dass das Ändern dieser Codestelle viele nicht vorhersehbare Seiteneffekte hervor­ruft.

Anforderungen an eine technische Umsetzung

Ein System zur quellcodegebundenen Dokumentation von Aspekten im Softwaresystemen muss die direkte Dokumentation von Aspekten und eine Zuordnung von Dokumentationsele­menten zu diesen Aspekten sowie die Verbindung mit dem Quellcode ermöglichen, wie sie bereits für die quellcodegebundene Dokumentation möglich ist. Erforderlich ist es auch, dass die Dokumentation eines Aspektes in beliebig viele Teilaspekte beliebig tief aufgeteilt werden kann, um so große gedankliche Einheiten in kleinere, besser verständliche Einheiten aufteilen zu können. Darüber hinaus ist eine grafische Visualisierung der Verteilung der dokumentier­ten Aspekte durch die Visualisierung der verknüpften Quellcodestellen nötig, um die Vertei­lung der Aspekte über die Implementierung darzustellen.

3.3 Dokumentationselemente zum Bewahren von Wissen und In­formationen

Die Anforderungen an eine Dokumentation nach Mayr zeigen, dass es vor allem darauf an­kommt, dass eine Dokumentation einheitlich und ohne viel Aufwand erstellt werden kann [MayOl]. Deutlich wurde aber auch, dass die unterschiedlichen Vorgehensmodelle genaue Vorstellungen haben, welche Dokumentationen erzeugt werden müssen. Dabei werden ein­heitliche Vorgaben und Strukturen vorgeschrieben. Es ist also von Bedeutung, wie das Wissen und die Informationen bewahrt werden. Für die Implementierung von immer wiederkehrenden Anwendungsfällen bzw. abstrakten funktionalen Anforderungen haben sich Entwurfsmuster als das geeignete Mittel herausgestellt. Sie bilden in der Softwareentwicklung Architekturen, die mit Erfolg immer wieder verwendet werden und dann in einer eindeutigen Vorlage festge­halten werden. Die Entwurfsmuster werden in Katalogen gesammelt. Den bekanntesten Kata­log für Entwurfsmuster liefert das Buch „Entwurfsmuster“ von Gamma, Helm, Johnson und Vlissides dar [GamOl]. Auf die Dokumentation von Informationen und Wissen bezogen, bil­den vor allem innerbetriebliche Vorlagen die Wahl des Mittels, um die Informationen festzu­halten. Dabei haben sich im Laufe der verschiedenen Softwareprojekte zu meist einheitlichen Vorlagen herausgebildet. In einer Firma, in der der Autor tätig war, gab es solche Vorlagen beispielsweise für Besprechungen (Besprechungsprotokolle). Die Idee der Muster und Vorla­gen wird in Kapitel 3.3.1 für die quellcodegebundene Dokumentation von Softwaresystemen aufgegriffen. Es wird dargelegt, wie Dokumentationsvorlagen zum Festhalten der Informatio­nen und des Wissens verwendet werden können. Die Dokumentationsvorlagen bilden dabei ähnlich den Entwurfsmustern, eine definierte Struktur zum Bewahren von Informationen und Wissen. Im Gegensatz zu den Mustern wird diese Struktur aber nicht als starr angesehen, son­dern kann an die eigenen Bedürfnisse angepasst werden.

3.3.1 Dokumentationsvorlagen

Dokumentationsvorlagen bilden den Versuch, Informationen, die von vielen Entwicklern und Autoren für die Dokumentation von Quellcode als sinnvoll erachtet werden, zu bündeln und als Vorlage für die quellcodegebundene Dokumentation anzubieten. Bei der Recherche der Frage, wie soll Quellcode dokumentiert werden, wurden immer wieder ähnliche Vorschläge und Vorschriften zur Dokumentation von Codes gefunden. Darüber hinaus offenbarten sich bei der Einführung der quellcodegebundenen Dokumentation von Aspekten immer wieder­kehrende Strukturen zur Dokumentation des Quellcodes. Dazu gehört die Dokumentation von Aspekten und Teilaspekten, von Projektdaten, Wartungsaktivitäten, Entscheidungsprozessen, die Beschreibung der Erweiterungsmöglichkeiten des Systemverhaltens aber auch die Doku­mentation von verwendeten Entwurfsmustern. Die aufgeführten Vorlagenvorschläge habe kei­nen Anspruch auf Vollständigkeit, sondern sollen die Möglichkeiten aufzeigen, die sich durch

3.3 Dokumentationselemente zum Bewahren von Wissen und Informationen die quellcodegebundene Dokumentation ergeben. Die quellcodegebundene Dokumentation macht es dabei möglich, verschiedenste Implementierungsdetails einfach zu beschreiben und sichtbar zu machen. Durch die Vernetzung der unterschiedlichen Dokumentationselemente entsteht die abstrakte Dokumentationsebene, welche, wie dargestellt, das Verständnis fur die Implementierung eines Softwaresystems erleichtert.

Es hat sich gezeigt, dass über die Dokumentation von Quellcode hinaus ein persönliches Feh­lertagebuch ein sinnvolles Mittel darstellt, um die eigenen Erkenntnisse zu Fehlern bei der Im­plementierungsarbeit festzuhalten [BalOO]. Durch das Festhalten bzw. Dokumentieren der eigenen Fehler können wiederkehrende ähnliche Fehler schnell gefunden oder gleich vermie­den werden. Die Verbindung von Quellcode und Dokumentation ermöglicht dabei die Vernet­zung der Fehlertagebucheinträge mit dem Code. Zum Beispiel bei der Verwendung von Frameworks kann dies sehr hilfreich sein, da bei der Erstellung einer neuen Instanz des Fra­meworks die Wiederholung eines dokumentierten Fehlers vermieden werden kann.

Die Dokumentationsvorlagen sollen vor allem eine Anregung darstellen, wie Informationen und Wissen strukturiert festgehalten und damit schneller wiedergefunden werden können. Der Benutzer der quellcodegebundenen Dokumentation soll darüber hinaus angeregt werden, die Vorlagen an seine eigenen Bedürfnisse anzupassen oder aber eigene neue Vorlagen zu erstel­len. Wichtig bei der Verwendung von Vorlagen ist, dass bei der Nutzung im Einzelnen von der eigentlichen Vorlage abgewichen werden kann. Den Hintergrund bildet dabei die Feststel­lung, dass Entwickler beim Festhalten von Informationen und Wissen nicht eingeschränkt sondern unterstützt werden wollen. Dieser Anspruch soll durch die Verwendung von Vorla­gen umgesetzt werden.

Allen Ausprägungen der Dokumentationsvorlagen ist gemein, dass mit ihnen beliebig viele Quellcodestellen verknüpft und den Verknüpfungen Rollen zugewiesen werden können. Darü­ber hinaus gehörtjedes Dokumentationselement, das sich auf den Quellcode bezieht, zu einem festen Projekt.

Projektdatendokumentation

Die Dokumentation wichtiger Eckdaten zum Projekt wird in vielen Unternehmen unterschied­lich sein. Die Projektdatendokumentationsvorlage zielt dabei im Folgenden auf die wichtigs­ten Informationen zu einem Projekt ab. Zunächst sind das projektorganisatorische Informationen, wie 3 Konzept einer quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen

- Name des Projektes
- Kurzbezeichnung des Projektes
- Beschreibung des Projektes
- Zeitrahmen des Projektes
- Projektplan
- Projektleiter
- Projektteammitglieder

Im Weiteren werden der Kundendaten und Kundenanforderungen oder aber ein Verweis auf das Anforderungsdokument festgehalten, wie

- Auftraggeber
- Ansprechpartner
- Anforderungsbeschreibung

Für die reibungsfreie Projektarbeit sollten darüber hinaus wichtige technische und organisato­rische Details festgehalten werden. Dazu zählen:

- Nameskonvention

- Projektablagen (CVS-Zugang, Dokumentenablagepfad)

Die Projektdatenbeschreibung stellt vor allem für neue Mitarbeiter die erste Anlaufstelle dar, um sich über das Projekt zu informieren. Aber auch bei organisatorischen Fragen ist die Pro­jektbeschreibung die erste Informationsquelle.

Dokumentation von Aspekten und Teilaspekten

Die Dokumentationsvorlage für Aspekte oder Teilaspekte ermöglicht die Beschreibung von konkreten gedanklich kapselbaren Einheiten oder Teileinheiten von Verhalten. Gerade für komplexe Aspekte besteht dabei die Möglichkeit, diese in Teilaspekte zu zerlegen. Das grund­legende Merkmal der Dokumentation von Aspekten liegt im Sichtbarmachen von konkreten gedanklich kapselbaren Einheiten von Verhalten und deren konkreten Umsetzungen im Quell­code. Damit stellt die Vorlage die Umsetzung der Idee der quellcodegebundenen Dokumenta­tion von Aspekten in Softwaresystemen dar. Durch die Vernetzung der verschiedenen Dokumentationselemente entsteht die dargestellte abstrakte Dokumentationsebene, die das Verständnis des Systems erleichtert.

Der Unterschied zwischen einem Aspekt und einem Teilaspekte liegt darin, dass ein Teil­aspekte immer einem Aspekt zugeordnet ist. Die Dokumentationsvorlage für Aspekte wie Teilaspekte enthält folgende Punkte:

- Name

Der Name für den Aspekt oder Teilaspekt beschreibt griffig den Hintergrund des Aspektes.

- Beschreibung

Die Beschreibung des Aspektes enthält alle wichtigen Informationen, die für das Verständ­nis des Aspektes wichtig sind.

- Liste aller direkt oder indirekt verbundenen Teilaspekte
- Liste aller direkt oder indirekt verbundenen Quellcodestellen und deren Rollenzuordnung
- Liste aller dem Aspekt direkt zugeordneten Dokumentationselemente
- Liste aller dem Aspekt indirekt zugeordneten Dokumentationselemente
- Autor
- Erstellungsdatum
- Modifikationsdatum
- Möglichkeit der Kommentierung

Durch die Listen der Zuordnungen werden die Dokumentationselemente direkt miteinander vernetzt. Über Links innerhalb der Beschreibung oder zu anderen Textelementen werden Wis­sensinhalte indirekt miteinander verbunden.

Dokumentation von Entscheidungsprozessen

Gerade die Diskussion über unterschiedliche Varianten einer späteren Lösung sollte festgehal­ten werden. Die Nachvollziehbarkeit der Entscheidung wird so klarer, da die Vor- und Nach­teile nicht zu einem späteren Punkt erneut diskutiert werden müssen. Bei einer späteren Wartung stellt sich die Frage, weshalb wurde so entschieden. Durch die Dokumentation der Entscheidung kann diese Frage eindeutig beantwortet werden. Die Vorlage bietet zum Fest­halten der Entscheidungen folgende Daten an:

- Name
- Zuordnung zu einem Aspekt
- Beschreibung der Anforderungen

- Beschreibung der unterschiedlichen Varianten
- Wann wurde die Entscheidung gefällt
- Wer hat die Entscheidung getroffen
- Welche Variante soll wie eingesetzt werden
- Weshalb wurde die Entscheidung so gefällt (Vor- und Nachteile)
- Liste aller verbunden Quellcodestellen Dokumentation von Mustern im Quellcode

Muster werden bei der Implementierung von Softwaresystemen häufig verwendet. Die Ver­wendung wird durch die Wahl der Bezeichner transparent gemacht. Darüber hinaus kann es aber nötig sein, die Verwendung der Muster genauer zu beschreiben. Die Dokumentationsvor­lage für Muster bietet folgende Daten an:

- Name
- Name des verwendeten Entwurfsmusters
- Verweis auf die abstrakte Beschreibung des Musters im Musterkatalog
- Beschreibung der Verwendung des Musters
- Hintergrund (z.B. beim Entwurfsmuster Strategie kann dargestellt werden, welche anderen Varianten denkbar sind oder zu einem späteren Zeitpunkt implementiert werden sollen)
- Liste der verbunden Quellcodestellen

Dokumentation von Wartungsaktivitäten

Nach Lehner sollten folgende Angaben zu den Wartungsaktivitäten in der Dokumentation ei­nes Softwaresystems festgehalten werden [Leh94]:

- Wer führte die Änderung durch?
- Was wurde geändert?
- Wann wurde die Änderung durchgeführt?
- Wo im Programm wurde etwas geändert?
- Warum wurde das Programm geändert?
- Wer hat den Wartungsauftrag gegeben?

Diese Anforderungen an die Dokumentation eines Wartungsvorganges greift die Vorlage zur Dokumentation von Wartungsaktivitäten auf. Die Dokumentation einer Wartungsaktivität kann darüber hinaus einem Aspekt oder Teilaspekt sowie einer bestehenden Dokumentation zugewiesen werden. Zu den Eigenschaften der Vorlage gehören:

- Name

Der Name stellt eine griffige Abkürzung der eigentlich Beschreibung dar.

- Datum der Änderung
- Zuordnung zu einem Aspekt
- Zuordnung zu einem bestehenden Dokumentationselement
- Auftraggeber der Wartungsaktivität
- Beschreibung der Wartungsaufgabe
- Hintergrund der Änderung
- Ausführender Entwickler
- Liste aller geänderten Quellcodestellen
- Beschreibung der Durchführung

Durch die Wartungsdokumentation können wichtige Informationen festgehalten und so nach­vollziehbar gemacht werden.

Dokumentation von Erweiterungsmöglichkeiten des Systemverhaltens

Häufig werden Funktionalitäten implementiert, die erweitert werden können. Ein Beispiel stellen die Erweiterungsmöglichkeiten von SnipSnap durch Markos dar (mehr zu SnipSnap in Kapitel 4 und 5). Durch die Dokumentation der Erweiterungsmöglichkeiten z.B.im Quellcode wird anderen Entwicklern die Erstellung eigener Makros vereinfacht. Wichtig ist dabei, eine genaue Handlungsanleitung festzuhalten und die Wirkungsweise der einzelnen Funktionen zu beschreiben:

- Name
- Vorgehensbeschreibung
- Liste alle verbunden Quellcodestellen

Persönliches Fehlertagebuch

Das persönliche Fehlertagebuch ermöglicht die Speicherung von verschiedenen Fehlertage­bucheintragungen zu unterschiedlichen Projekten. Die Gruppierung der Fehlertagebucheinträ­ge nach definierten Kriterien ist dabei fur eine besseres Wiederfinden sinnvoll. Die Idee des Fehlertagebuches stammt von Balzer, der dafür im „Lehrbuch der Softwaretechnik“ ein For­mular vorgibt [BalOO]. Dieses Formular wird für die Vorlage eines Fehlertagebucheintrages aufgegriffen.

Fehlertagebucheintrag

Ein Fehlertagebucheintrag sollte folgende Details festhalten:

- Aussagekräftiger Name des Fehlers
- Wann entdeckt(Datum)?
- Name des betroffenen Programms
- Ursache des Fehlers
- Wie konnte der Fehler rückverfolgt werden?
- Weshalb waren Gegenmaßnahme unwirksam?
- Welche Programmierregel/Gegenmaßnahme hilft, diesen Fehler zu vermeiden?
- Beschreibung des Fehlers (Quellcode Auszug)
- Liste der verbunden Quellcodestellen

Durch das Festhalten der unterschiedlichen Informationen werden der Fehler und dessen Hin­tergrund transparent und es erleichtert später das Finden ähnlicher Fehler.

Zusammenfassung

Dokumentationsvorlagen stellen Strukturelemente dar, die die Informationen und das Wissen geordnet festhalten. Dadurch wird das Wiederfinden von Informationen erleichtert und darü­ber hinaus die Struktur der Wissensdokumentation vereinheitlicht. Es ist von Vorteil, dass die Vorlagen problemlos auf die eigenen Bedürfnisse angepasst werden können und somit flexi­bel einsetzbar sind. Die Vorlagen sind nicht starr, sondern ermöglichen auch Abweichungen in konkreten Ausprägungen, damit wird der Entwickler beim Festhalten der Informationen und des Wissens umfangreich unterstützt.

3.4 Zusammenfassung

Die quellcodegebundene Dokumentation von Aspekten in Softwaresystemen ermöglicht die abstrakte Beschreibung eines Softwaresystems während der Implementierung. Dabei entsteht eine abstrakte Dokumentationsebene, die die direkte Verbindung zwischen Quellcode und Do­kumentation ermöglicht. Durch die Beschreibung des Verhaltens eines Systems sogar vor oder während der eigentlich Implementierungsarbeit ist gesichert, dass möglichst wenig Wissen über die Implementierung sowie über Entscheidungen und Hintergründe zum Code verloren gehen. Darüber hinaus können andere Teammitglieder, die an den selben Quellcodeelementen arbeiten, an dem Wissen der anderen Entwickler teilhaben, ohne dass eine direkte Kommuni­kation zwischen allen Beteiligten stattfinden muss. Die Verwendung von Dokumentationsvor­lagen erleichtert dabei das Festhalten der Informationen und des Wissens zum Softwaresystem oder deren Implementierung. Die Vorlagen geben einen einheitlichen Rahmen vor, um die Struktur der Dokumentation zu vereinfachen. Gerade für die Wartung ist von Vorteil, dass das System durch eine abstrakte Sicht sehr implementierungsnah beschrieben wird. Die Wartung eines Softwaresystems wird größtenteils von Entwicklern durchgeführt, die das System noch nicht kennen. Ihnen wird die Einarbeitung durch die Beschreibung des Systems vereinfacht. Mit dem Ansatz der quellcodegebundenen Dokumentation soll der Fehler vermieden werden, dass die Dokumentation als fertig betrachtet wird, wenn die Software fertig gestellt ist. Soft­waresysteme sind nie fehlerfrei und müssen daher immer gewartet werden. Gerade bei der Durchführung der Wartung fällt es schwer ins Gewicht, wenn die Dokumentation zum Soft­waresystem fehlt. Ein neuer Entwickler muss dann erst das System analysieren und die rele­vanten Systemteile kennenlernen. Dabei macht sich der Entwickler viele Notizen zum Softwaresystem und sammelt seine Erkenntnisse zu einzelnen Quellcodeelementen. Die quell­codegebundene Dokumentation unterstützt den Entwickler auch bei dieser Tätigkeit, indem er seine Erkenntnisse sofort festhalten und sammeln kann. Durch das Sammeln und direkte An­binden der Informationen an den Quellcode kann dieses Wissen nicht mehr verloren gehen. Gerade durch das Dokumentieren auch aller kleinen Systemteile und das Ordnen der Informa­tionen zu Aspekten entsteht eine zusammenhängende Dokumentation, die dem Entwickler ei­nen Gesamtüberblick über das System ermöglicht.

4 Technischer Lösungsansatz

Das Konzept der quellcodegebundenen Dokumentation von Aspekten in Softwaresystemen verlangt von der technischen Realisierung die Umsetzung verschiedenster Anforderungen. Die Betrachtung der Lösungsansätze im Rahmen dieser Diplomarbeit wird sich auf die Entwick­lung von Programmen in der Programmiersprache Java beschränken. Das bedeutet, dass die quellcodegebundene Dokumentation von Aspekten in Softwaresystemen ausschließlich für Softwaresysteme, die in der Programmiersprache Java entwickelt werden, realisiert wird. Java ist eine sehr verbreitete plattformunabhängige objektorientierte Programmiersprache, die in den letzten Jahren immer mehr an Bedeutung gewonnen hat [Java].

Die technische Realisierung erfordert eine vollständige Einpassung in den Implementierungs­prozess. Diese Anforderung macht es erforderlich, dass sich die Umsetzung in eine Entwick­lungsumgebung für die Programmiersprache Java integrieren lässt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: EclipseArchitektur

Die integrierte Entwicklungsumgebung (IDE) des Eclipse Projektes erfüllt diese Anforderun­gen. Das Eclipse Projekt baut auf der Idee der freien Software (Open Source - offenen Quel­len) auf und bietet mit der Eclipse Plattform eine offene und erweiterbare Entwicklungsumgebung vornehmlich für die Programmiersprache Java an. Der Idee der freien Software (Open Source) liegt die Open Source Lizenzierung zugrunde. Diese Lizenzen legen unter anderem fest, dass der Quellcode eines Systems frei zugänglich sein muss und beliebig erweitert werden darf [OpenSource]. Die Begriffe Entwicklungsumgebung und -plattform werden synonym verwendet. Die Entwicklungsumgebung Eclipse baut auf einer vollständig durchgehenden Pluginstruktur und der Infrastruktur fur die Laufzeitumgebung (Plattform Runtime) für die Plugins auf (siehe Abbildung 11) [Wey03]. Das Ziel des Eclipse Projektes ist die nahtlose Integration anderer Entwicklungswerkzeuge (Plugins) in die Entwicklungsplatt­form. Die Entwicklungsumgebung (Plugin Development Environment (PDE)) unterstützt da­bei selbst direkt die Entwicklung von Plugins [Wid03]. Eclipse bildet damit einen wichtigen Teil in einem Gesamtsystem zur quellcodegebundenen Dokumentation. Ein System zur Doku­mentation des Softwaresystems wird in Kapitel 4.1 vorgestellt. Das Kapitel 4.2 untersucht mögliche technische Umsetzungen zur quellcodegebundenen Dokumentation. Das Hauptau­genmerk wird dabei auf der Verbindung von Quellcode und Dokumentation liegen.

4.1 Hypertext - Dokumentation

Das Internet und im besonderen das World Wide Web (WWW) ist in den letzten Jahrzehnten das einzigartige Medium für die Verbreitung von Informationen geworden. Hintergrund ist ei­nerseits die problemlose Vernetzung von Rechnern und andererseits die Einfachheit, mit der Informationen öffentlich gemacht werden können. Insbesondere die Standardisierung der Hy­perText Markup Language (HTML) [HTML] hat daran einen besonderen Anteil. Die quellco­degebundene Dokumentation von Softwaresystemen setzt bei der Verbindung von Quellcode und Dokumentation auf den Hypertext-Ansatz. Daher ist es nur konsequent, wenn die Doku­mentation als Hypertext verfasst wird. Damit ist es möglich, die Dokumentation beliebigen Teammitgliedern barrierefrei zur Verfügung zu stellen. Darüber hinaus hat sich gezeigt, dass beliebige Informationen benutzergerecht dargestellt werden können, da das Integrieren von anderen Medien wie Video, Sound, 3D-Visualisierung uvm. in den Hypertext kein Problem darstellt. Damit bietet der Hypertext ein unermessliche Fülle an Möglichkeiten Softwaresyste­me zu dokumentieren.

Für die technische Umsetzung der Dokumentation soll ein System verwendet werden, das die Dokumentation des Softwaresystems einfach verwalten kann. Das System soll jedem Ent­wickler die Möglichkeit bieten, neue Informationen zu dokumentieren sowie an dem Wissen der anderen Entwicklern zu partizipieren. Entscheidend für die Wahl eines solchen Systems ist es, dass es sich bei dem Produkt um ein Open Source Projekt handelt, an dem aktiv gear­beitet wird und das Zukunftsaussichten bietet. Hintergrund dieser Anforderung ist es, dass ein System für die quellcodegebundene Dokumentation beliebig angepasst werden kann und z.B. im Falle eines Fehlers im System der Quellcode zur Verfügung steht, um diesen Fehler selbst beheben zu können. SnipSnap ist ein Weblog und Wiki System erfüllt die gestellten Anforderungen für die Doku­mentation des Quellcodes [SnipSnap].

Wiki

„Wikis sind im World Wide Web verfügbare Seitensammlungen, die von Benutzern nicht nur gelesen, sondern auch online verändert werden können. Sie können somit als abgespeckte of­fene Content Management Systeme angesehen werden.“ [Wikipedia] Ein Content Manage­ment System (CMS) ist eine zu meist serverseitig realisierte Software, welche die Verwaltung von Webseiten stark vereinfacht und somit das Management von Webseiten auch Laien über den Webbrowser ermöglicht. Wikis verwenden zum Layouten und Verlinken der Texte Tags (alle Tags zusammen genommen bezeichnet man als WikiSyntax), die leichter zu erlernen sind als HTML Syntax. Das Wort wiki stammt aus dem hawaiianischen und dort bedeutet „wiki wiki“ so viel wie „schnell“. Schnell Informationen ohne viel Aufwand anderen Men­schen zur Verfügung zu stellen und die Menschen daran teilhaben zu lassen, ist das Ziel eines Wikis. Da viele Menschen die Möglichkeit haben, Informationen einzustellen, zu ergänzen oder zu verbessern, wird die Qualität der Informationen verbessert und umfassender.

Wiki Einsatz im Unternehmensumfeld

Wikis bieten Unternehmen wie jedes CMS die Möglichkeit, Informationen zwischen den Ar­beitnehmern auszutauschen. Im Besonderen ermöglicht ein Wiki dabei vor allem den unge­zwungenen, demokratischen Austausch von Informationen. Dabei kann ein Wiki die indirekten Kommunikationswege erweitern und Informationen, die z.B. auf dem Flur ausge­tauscht werden können, allen Mitarbeitern zugänglich machen.

Vor- und Nachteile

Gerade das Teilen von Wissen muss sich aber als Unternehmensphilosophie etabliert haben, da ein Wiki sonst keinen Anklang bei den Mitarbeitern findet. Denn wie bereits in Kapitel 2.5 festgestellt wurde, hängt die Wissensteilung sehr stark von den beteiligten Personen und damit auch vom Zusammengehörigkeitsgefühl ab. Vorteil eines Wikis ist es, dass jeder Mitarbeiter beliebige Informationen einstellen, ergänzen und verbessern kann. Dabei wird dies aber gera­de im Unternehmenskontext als nachteilig angesehen, da so Informationen manipuliert wer­den können. Durch Einführung von Zugangskontrollen und Versionieren der Informationsver­änderungen sowie Festhalten der Autoren, ist ein unbemerktes Manipulieren von Informatio­nen nicht möglich. Da jedem Mitarbeiter dies bewusst ist und er auch öffentlich als Autor zu erkennen ist, wird es kaum zu einem wie auch immer gearteten Missbrauch kommen. Als schwierig kann sich der Einsatz eines Wikis in Unternehmen erweisen, die streng hierarchisch strukturiert sind, da der demokratische Grundgedanke nicht der Firmenphilosophie entspricht.

Für Gestaltung und Vernetzung der Informationen bieten Wikis eine Vielzahl von Möglich­keiten an. Über die Wikisyntax können Texte beliebig optisch gestaltet und miteinander ver­linkt werden. Dafür muss meist eine einfache Wikisyntax erlernt werden. Die Bereitschaft diese Syntax zu lernen, sollte durch den Arbeitgeber unterstützt werden, da sonst eine hohe Barriere für die Nutzung des Wikis entsteht. Der Zugang zu einem (serverseitigen) Wiki er­folgt ohne Zusatzsoftware über den Webbrowser und der Einsatz des Systems ist relativ kos­tengünstig realisierbar. Somit verursacht die Einführung eines Wikis keine größeren Kosten.

SnipSnap

SnipSnap ist ein Weblog und Wiki System, das im Zusammenhang mit dem KOGITO Projekt [KOGITO] am Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik FIRST in Ber­lin entsteht [FIRST]. Die Entwicklung von SnipSnap ist noch nicht abgeschlossen und es kommen mit jedem Release eine Fülle an neuen Möglichkeiten hinzu, um Informationen zu verwalten. Darüber hinaus ist SnipSnap ein Open Source Projekt unter der GPL Lizenz [GPL] und ermöglicht so die Mitarbeit von interessierten Entwicklern. SnipSnap ist in Java geschrie­ben und baut auf dem Jetty Webserver und Servletcontainer auf [Jetty]. Als Wiki Renderengi- ne verwendet SnipSnap Radeox eine Render Engine API für Wikis [Radeox]. Ein besonderer Vorteil von SnipSnap und Radeox ist die Erweiterbarkeit des Wikifunktionsumfangs durch Makros. Diese Makros können ohne Modifikationen des Systems zusätzlich geladen werden und so die Funktionalität des Wikis beliebig erweitern [Sch03]. Durch die Verwendung der vorgegebenen und durch Makros unterstützten Wikisyntax sind die Möglichkeiten, Inhalte in SnipSnap zu layouten, sehr umfangreich. Die Verwendung der Wikisyntax ist schnell zu erler­nen und wird durch eine umfangreiche Hilfe unterstützt. Die Informationen werden in SnipS­nap als so genannte Snips, zu deutsch Informationsschnipsel, abgelegt. Snips sind das einzige Element, um Informationen zu speichern. Damit haben alle Informationselemente (Snips) fest­gelegte gleiche Eigenschaften und können dennoch darüber hinaus individuell angepasst wer­den. Die Verknüpfung von externen Informationen aus dem Internet mit einem Snip, hängt von den Möglichkeiten der Wikisyntax ab. Von Haus aus unterstützt SnipSnap die gängigen Möglichkeiten, Hypertext miteinander zu verlinken und es kann, wie dargelegt, durch die Ver­wendung eigener Makros beliebig erweitert werden. Die Vernetzung der Informationselemen­te in SnipSnap selbst geht aber noch einen Schritt weiter. In SnipSnap ist es möglich, Snips zu typisieren sowie über Labels miteinander zu verbinden und einzuordnen, Inhalte der Snips miteinander zu verknüpfen und Metainformationen zu den Snips zu speichern. Ab der SnipS­nap Version 0.5a wurde die automatische Versionsverwaltung von Snips eingeführt. Damit werden Veränderungen an den Informationsinhalten nun sichtbar gemacht.

Auf der technischen Seiten ist es durch die Verwendung der XML-Remote Procedure Call (XML-RPC) Schnittstelle von SnipSnap möglich, das System als Webservice anzusprechen [XML-RPC]. Damit kann man auf das System direkt zugreifen und es so in die Gesamtarchi­tektur eines Systems zur quellcodegebundenen Dokumentation integrieren (siehe Kapitel 5). Die Installation von SnipSnap ist nicht kompliziert und durch die Verwendung von Java auf allen gängigen Plattformen möglich.

4.2 Quellcodegebundene Dokumentation

Die Kernanforderungen an die quellcodegebundene Dokumentation sind:

- Verbindung von beliebigen Quellcodestellen mit beliebigen Dokumentationselementen (m:n Verbindung)
- Zuweisung einer Rolle für eine Verbindung im Zusammenhang mit dem jeweiligen Kon­text.

Grundlage dieser Betrachtung ist nur Quellcode, der in der Programmiersprache Java ge­schrieben ist, da die Arbeit nur die Verbindung zwischen Java-Quellcode und Dokumentati­onselementen umsetzt. In Java lassen sich bestimmte Strukturelemente über ihren Bezeichner und dessen Namensraum eindeutig bestimmen und referenzieren. „Ein Name identifiziert ein Objekt. Zur eindeutigen Zuordnung ist jedoch der entsprechende Kontext - eben der Namens­raum zu beachten.“[Wikipedia] Zu diesen Elementen gehören:

- Pakete - Eindeutigkeit: vollständiger Paketname
- Klassen - Eindeutigkeit: vollständiger Paketname + Klassenname
- lokale Klassen (in [lokalen] Klassen oder Methoden) - Eindeutigkeit: Vollständiger Paket­name + Klassenname +([Methodenname] + [lokaler Klassenname])* + Name der Lokalen- klasse
- Paketzugehörigkeit einer Klasse - Eindeutigkeit: Vollständiger Paketname + Klassenname + Paketstatment in der Klasse
- Variablendeklarationen in einer Klasse, Methoden und einem Konstruktor -Eindeutigkeit: Vollständiger Paketname + Klassenname + [Methodenname/Konstruktorenname] +Varia- blenname
- Konstruktoren- und Methodenparameterdeklarationen - Eindeutigkeit: Vollständiger Pa­ketname + Klassenname + [Methodenname/Konstruktorname] +Variablenname
- Konstruktoren - Eindeutigkeit: Vollständiger Paketname + Klassenname + Kostruktor“name“ incl. Parametername
- Methoden - Eindeutigkeit: Vollständiger Paketname + Klassenname + Methodenname incl. Parametername

Das Ziel, beliebige Quellcodestellen identifizieren zu können, ist in Java ohne die Speiche­rung zusätzlicher Informationen am Quellcode nicht möglich, da Anweisungen innerhalb ei­ner Methode nicht eindeutig referenziert werden können. Somit können Quellcodestatements innerhalb einer Methode, dazu zählen beispielsweise Methodenaufrufe, Schleifen aber auch anonyme Klassen nicht referenziert werden, weil die gleichen Anweisungen mehrfach inner­halb eines Methodenrumpfs Vorkommen können. Damit kann nicht bestimmt werden, welche der möglicherweise mehrfach vorkommenden Anweisungen referenziert wurde. Das Spei­chern der Zeilennummer, in der ein Statement steht, stellt keinen Gewinn dar, da schon durch das Umformatieren diese Zeilennummern nicht mehr stimmen. Auch viele andere denkbare Ansätze fuhren nicht zum Ziel, wenn die Referenzierungen während der Modifikationen nicht angepasst werden. Es ist also erforderlich, dass die Entwicklungsumgebung die Referenzie- rung von Quellcodestellen unterstützt bzw. um diese Unterstützung erweitert wird. Für die verwendete Entwicklungsplattform Eclipse, ist derzeit kein Plugin bekannt, das die vollständi­ge Referenzierung von Quellcode ermöglicht. Zwei theoretische Ansätze und ein bereits tech­nisch realisierter Ansatz sollen im Weiteren betrachtet werden. Dabei soll untersucht werden, welcher Ansatz für die prototypische Umsetzung der quellcodegebundenen Dokumentation von Aspekten in Softwaresystem für diese Arbeit verwendet werden soll. Zu einem ist da die

Möglichkeit durch Erweiterung des abstrakten Syntaxbaums die Informationen direkt an die­sen zu binden und im Quellcode persistent zu speichern (siehe Kapitel 4.2.1) und zum anderen der Ansatz, Java Quellcode in srcML bzw. JavaML zu speichern und somit Verknüpfungen als weitere Eigenschaft einer XML-Repräsentation eines Quellcodeelementes zu speichern (siehe Kapitel 4.2.2). Diese beiden Ansätze beruhen auf einer relativ aufwändigen Erweite­rung der Eclipse Plattformen. Daher soll zusätzlich Eudibamus, ein eingeschränkter Ansatz, der es erlaubt bestimmte Quellcodeelemente und mit beliebigen anderen Elementen zu ver­knüpfen, betrachtet werden (siehe Kapitel 4.2.3).

4.2.1 Abstrakter Syntaxbaum

Der abstrakte Syntaxbaum in Englisch „Abstract Syntax Tree“ AST stellt eine Zwischenrepre­sentation des Quellcodes dar [Pin03]. Diese baumähnliche Darstellung des Quellcodes, wird in vielen integrierten Entwicklungsumgebungen und strukturorientierten Editoren verwendet [Mic03]. Der AST wird vor allem für den Compiler und das Reverse Engineering aber auch für das Refaktorisieren von Quellcodes eingesetzt. Der abstrakte Syntaxbaum stellt den Quell­code in seiner exakten syntaktischen Struktur dar und ermöglicht so die Analyse des Codes. Die Grammatik der Programmiersprache, in diesem Fall Java, legt dabei fest, wie einzelne Statements zu parsen und deren abstrakte Syntaxbaumzweige aufzubauen sind [Hav03]. Um nun mit Hilfe des AST Informationen über die Verbindung zwischen Quellcodestellen und der Dokumentation speichern zu können, muss das AST - Datenmodell um die Speicherung der Verknüpfung für alle Elemente erweitert werden. Möglich ist auch, dass jedem Element eine eindeutige ID zugeordnet und die Verknüpfung extern gespeichert wird. Darüber hinaus müs­sen die Informationen über mögliche Verknüpfungen, im weiteren Metainformationen ge­nannt, persistent abgelegt werden. Denn der AST wird in der Entwicklungsumgebung Eclipse automatisch aus den jeweiligen Quellcodedateien erst aufgebaut, wenn er benötigt wird, daher müssen die Metainformationen persistent abgespeichert und eingelesen werden. Diese Metain­formationen können z.B. durch eine entwickelte JavaDoc-Erweiterung direkt im Quellcode oder in einer extra Datei gespeichert werden. Beim persistenten Speichern der Metadaten im Quellcode muss der Editor so angepasst werden, dass die Metainformationen aus der Quellco­deansicht gefiltert werden. Darüber hinaus müssen die gespeicherten Metadaten beim Offenen bzw. Laden einer Datei ausgelesen, auf Richtigkeit überprüft und am AST gespeichert wer­den.

Für die Verwendung des AST-Konzepts zur Verlinkung von Dokumentation und Quellcodee­lementen müssen folgende Anforderungen realisiert werden:

- Anpassung der AST-Elemente, was eine Modifikation von Eclipse zur Folge hat. Damit kann das Problem bestehen, dass für jede neue Eclipseversion die AST-Erweiterung ange­passt werden muss.
- Erstellung von AST-Visitors zum Modifizieren des AST und zum Auslesen der Informa­tionen.
- Eine persistente Speicherungslösung zur Speicherung der Metadaten. Die persistente Spei­cherung der Daten außerhalb des Quellcodes kann dazu führen, dass der Quellcode unbeab­sichtigt verändert wird und damit die Verknüpfungen zerstört werden.

Festhalten lässt sich, dass die Erweiterung des AST für die vollständige Integration der quell­codegebundenen Dokumentation in die Entwicklungsumgebung Eclipse ein gute Wahl ist. Denn durch die Verwendung des AST besteht die Möglichkeit, dass die Verknüpfungen, ohne viel Mehraufwand z.B. beim Refaktorisieren des Quellcodes erhalten bleiben oder aber durch minimale Anpassung des Refaktorisierungalgorithmus übernommen werden.

Die nicht einschätzbaren Unwägbarkeiten bei der Erweiterung des ASTs und der hohe Ent­wicklungsaufwand haben mich dazu bewegt, nach weiteren Möglichkeiten für die technische Realisierung der quellcodegebundenen Dokumentation Ausschau zu halten.

4.2.2 Java-Quellcode in XML

XML (Extensible Markup Language) ist derzeit der wohl populärste Standard zur Definition von Auszeichnungssprachen (Markup Languages (ML)) [XML]. XML wurde von SGML ab­geleitet [SGML]. Grundlage der XML Auszeichnungssprachen bildet das jeweilige XML- DTD-Datenmodell. Die unterschiedlichen Auszeichnungssprachen wie z.B. SOAP [SOAP] oder aber Mathematical Markup Language [MathML] ermöglichen es, die speziellen Informa­tionsinhalte zu beschreiben und darüber hinaus die Datenspeicherung und deren Repräsentati­on zu trennen. Für die Darstellung der Daten wird zu meist der XSLT Standard verwendet [XSLT]. Die Daten können durch Auszeichnungssprachen strukturiert und somit durch Com­putertechnik ausgewertet werden. Der einfache Text „In Berlin ist es heute 37°C warm.“ ist durch ein Softwaresystem nur schwer auszuwerten. Dagegen ist der Text, „In <ort>Berlin</ort> ist es <datum value=“23.8.2003“>heute</datum> <temp ort=“berlin“>37°

C</temp> warm.“, durch ein Computersystem auswertbar. Damit gewinnt die Auszeichnungs­sprache fur Beschreibungen von Informationen an Bedeutung, da so über die einfache textuel­le Beschreibung hinausgehend die Inhalte beschrieben werden können. Der große Vorteil von XML besteht darin, dass unterschiedliche Inhaltselemente miteinander verknüpft werden kön­nen. Anzumerken ist, dass in XML das dargestellte Beispiel nicht so einfach verwendet wer­den kann, sondern dass noch einige Randbedingungen zu erfüllen sind. Zur Vertiefung dieses Themas empfiehlt sich „Einstieg in XML“ [Hel04] oder „XML“ [Amm03].

Mit einer Auszeichnungssprache, die auf XML basiert, ist es also möglich, Daten strukturiert abzulegen und genauer zu beschreiben. Welche Möglichkeiten sich beispielsweise durch die Speicherung von Java-Quellcode unter Verwendung der Java Markup Language (JavaML) er­geben, hat Badros untersucht [Bad02]. Eine weitere Auszeichnungssprache für Quellcode ba­sieren auf XML, im weiteren XML-Quellcodeformat genannt, ist srcML. Wie JavaML ist auch srcML noch kein definierter Standard. Die Transformation aus einem normalen Quellco­de in JavaML und zurück wird durch die Verwendung von XSL ermöglicht. Der Hintergrund, Quellcode im XML-Format zu speichern ist, dass immer mehr Informationen durch die Ent­wicklungsumgebungen aus dem Quellcode gewonnen werden müssen. Im Gegensatz zum AST liegen diese Informationen dann schon für die unterschiedlichen Werkzeuge in einem einheitlichen Format vor und müssen nicht für die Werkzeuge erst generiert werden. Darüber hinaus kann Quellcode im XML-Quellcodeformat beliebig dargestellt und editiert werden, womit den unterschiedlichen Benutzeransprüche z.B. in der Frage der Quellcodeformatierung beliebig entsprochen werden kann. Darüber hinaus lassen sich mit XML-Quellcodeformaten die unterschiedlichen Quellcodeelemente auch beliebig verlinken. Die Unterschiede zwischen den unterschiedlichen Quellcoderepräsentationsformen macht noch einmal die Abbildung 12 deutlich, srcML steht dabei als Repräsentant für die XML-Quellcodeformate. SrcML ist ein XML-Quellcodeformat, das im Gegensatz zu JavaML beispielsweise die originale Codefor­matierung erhält [CMM02].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Vergleich Klartext, AST und srcML [CMM02]

Mit der Möglichkeit Quellcodeelemente mit der Dokumentation zu verlinken, erfüllen die XML-Quellcodeformate die Kernanforderungen der quellcodegebundenen Dokumentation. Für die Integration einer Sprache wie srcML oder JavaML als Grundlage für die Bewahrung des Quellcodes müssen viele Bereiche der Entwicklungsumgebung Eclipse angepasst und er­weitert werden, da ein Austausch der Quellcoderepräsentation viele unterschiedliche Funktio­nalitäten berührt. Dazu gehören z.B. die Darstellung im Editor oder aber auch das Einlesen und Schreiben von Quellcode. Dies würde einen generellen Umbruch in der Entwicklungsum­gebung erfordern, der nur durch die Eclipse Entwickler selbst durchführbar ist. Sehr wahr­scheinlich wird dieser Schritt eines Tages gemacht, da sich beispielsweise bisher solche übergreifenden Ideen, wie das Verfolgen von Concerns über den gesamten Entwicklungspro­zess, wie es beispielsweise von Juri Memmert mit dem Cosmos Ansatz verfolgt wird, nicht realisieren lassen [Mem02a].

Eine anderer Versuch, die Speicherung von Quellcode im XML-Quellcodeformat in die Ent­wicklungsplattform Eclipse zu integrieren, könnte darin bestehen, dass die gängige Speiche­rung von Quellcode zusätzlich um die parallele Transformation des Quellcodes in ein XML- Quellcodeformat und die Speicherung in separaten Dateien inclusive der Verknüpfungen er­weitert wird. Dabei ergibt sich das Problem, dass die Metainformationen immer mühselig mit­geführt und zwischengespeichert werden müssen, um in die XML Repräsentation eingepflegt zu werden. Damit arbeitet diese Lösungsidee aber an den entwicklungsunterstützenden Werk­zeugen wie dem Refaktorisieren von Quellcode vorbei. Sinnvoll wäre es daher, eine XML ba­sierte Auszeichnungssprache für die persistente Speicherung der Metadaten des AST­Ansatzes zu verwenden und den AST-Ansatz umzustellen. Diese Lösung würde aber eine Menge technischer Möglichkeiten unbeachtet lassen.

Die weiteren Möglichkeiten, die das Speichern von Quellcode im XML-Format mit sich brin­gen, sind vielfältig und gehen über die hier besprochenen Möglichkeiten noch hinaus. Bei­spielsweise ist es möglich die Codeversionen direkt zu speichern, Zugangskontrollen für Quellcodeelemente einzuführen und vieles mehr. An dieser Stelle soll auf diese Möglichkei­ten nicht genauer eingegangen werden, da sie für die quellcodegebundene Dokumentation kei­ne direkte Relevanz haben. Es sei dazu auf die Arbeit „Prospects of encoding Java source code in XML“ von Simic und Topolnik [ST02] verwiesen.

4.2.3 Eudibamus

Eudibamus [Eudibamus] wird im Rahmen des KOGITO Projektes, wie SnipSnap, am Fraun­hofer-Institut für Rechnerarchitektur und Softwaretechnik FIRST in Berlin entwickelt. Den Kern von Eudibamus bildet ein Eclipse Plugin, das den Mozilla Webbrowser in Eclipse inte­griert, um so das „Surfen“ im WWW aus der Entwicklungsumgebung heraus zu ermöglichen. Dazu wurden die wichtigsten Interaktionsmöglichkeiten des Browsers mit dem Benutzer auf SWT angepasst. Den wichtigsten Teil von Eudibamus bildet die integrierte Verlinkungschnitt­stelle zwischen Quellcode und SnipSnap. Dabei ermöglicht die Schnittstelle die Umsetzung von Paketen, Klassen und Methoden Bezeichnern aus dem Javaquellcode in eindeutige SnipS- napURLs, die auf namensgleiche Snips verweisen und ermöglicht damit so die eingeschränkte Verbindung von Quellcodestellen und Snips. Hintergrund ist die einfache, nicht explizite Ver­linkung von in Java (über den Bezeichner und dessen Namensraum) eindeutigen Elementen mit Snips. Der Bezeichner und der Namensraum eines Elementes wird dabei in eine eindeuti­ge URL konvertiert. Damit stellt Eudibamus eine Alternative für die prototypische Umsetzung der quellcodegebundenen Dokumentation dar. Im weiteren soll zunächst betrachtet werden, welches funktionale Verhalten eine bestmögliche und umfassende Integration eines Werk­zeugs zur quellcodegebundenen Dokumentation in den Implementierungsprozess ermöglicht. Dabei wird vor allem auf die Benutzung von Eclipse während des Implementierungsprozesses eingegangen.

4.2.4 Funktionales Verhalten der Werkzeugunterstützung

Im folgenden werden das funktionale Verhalten beim Ändern von verlinkten Quellcodes, das Verlinken von Quellcodes, das Löschen einer Verlinkung zum Quellcode und das Ändern der Verlinkung zum Code erläutert.

Ändern von Quellcode

In allen vorgestellten Ansätzen ist eine vollständige Werkzeugunterstützung notwendig, um den Quellcode zu ändern und mögliche veränderte Verknüpfungen zwischen Quellcode und Dokumentation anzupassen. Wichtig dabei ist vor allem die Unterstützung beim Umbenennen und Modifizieren von verknüpften Quellcodestellen. Offen ist dabei aber noch, wie generell mit Änderungen an verknüpften Quellcodestellen umgegangen werden soll. Wichtig ist aber vor allem, dass sich die Benutzung des Systems in den Implementierungsprozess möglichst reibungsfrei integrieren lässt. Das Verändern eines Statements (z.B. ein Statement wird durch einen Methodenaufruf ersetzt) führt bei allen drei Ansätzen zuerst einmal zum direkten Ver­lust der Verknüpfung, wenn diese nicht an ein neues Element geknüpft wird. Die Frage ist, wie sollte die Entwicklungsumgebung und im speziellen der Editor entscheiden, welches Ele­ment durch welches andere ersetzt wurde. Dies könnte durch direkte Interaktion mit dem Be­nutzer erfolgen, was aber den Implementierungsprozess möglicherweise unnötig stören könnte. Eine anderer Ansatz wäre es, durch das halbautomatische Erkennen und Visualisieren gegenüber dem Benutzer das Löschen oder Ersetzen einer Quellcodestelle im Editor zu reali­sieren. Der Ansatz, der bei den drei bekanntesten Textverarbeitungssystemen StarOffice-Wri- ter (in Version 7.0) [StarOffice], OpenOffice-Writer (in Version 1.1) [OpenOffice] und Microsoft Winword [MSOffice] (in Version 2000) beim Verändern von markierten Text in­nerhalb eines Dokumentes Verwendung findet, könnte Abhilfe schaffen. Das visuelle Hervor­heben repräsentiert dabei eine Verknüpfung mit der Dokumentation im Editor bspw. von Eclipse. Das Vorgehen, das sich aus den drei Textverarbeitungssystemen ableiten lässt, könnte dabei wie folgt aussehen:

- Vollständiges Markieren und Löschen der Quellcodestelle, löscht die Verknüpfung.
- Ersetzen und Hinzufügen von Zeichen innerhalb der Quellcodestelle verändert die Ver­knüpfung (Verknüpfung bleibt erhalten).
- Das Anfügen von Zeichen an eine verknüpfte Quellcodestelle könnte wahlweise als das Er­weitern der verknüpften Quellcodestelle oder aber als das Schreiben eines neuen Quellco­destatement interpretiert werden. Diese Funktionalität sollte durch den Benutzer spezifisch anpassbar und möglichst über eine Tastenkombination wechselbar sein.

Durch dieses Verhalten integriert sich die Arbeit mit verlinkten Quellcode vollständig in der Implementierungsphase und ermöglich die schnelle Implementierung von Codes.

Verlinken von Quellcode

Das Verlinken von Quellcodeelementen ist schwierig ohne Unterbrechungen in den normalen Implementierungsprozess zu integrieren. Folgende Vorgehensweisen wären denkbar:

- Sofortiges Verlinken

Durch die Auswahl einer Dokumentation als aktuelle zu verlinkende Dokumentation wird der Quellcode, der nun implementiert wird, automatisch mit der Dokumentation verknüpft. Wenn die Dokumentation noch nicht besteht, kann sie von vornherein angelegt werden und dann als aktuelle Dokumentation ausgewählt werden.

- Nachträgliches Verlinken

Durch das Markieren von Codes, können beliebige Quellcodeelemente mit einer Dokumen­tation verlinkt werden. Dabei kann aus bestehenden Dokumentationen eine ausgewählt oder aber eine neue Dokumentation angelegt werden.

Löschen der Verlinkung zum Quellcode

Das Löschen einer Verbindung zwischen Quellcode und Dokumentation ist sehr einfach. Dazu muss sich der Cursor im Editor von Eclipse innerhalb der Quellcodestelle befinden des­sen Verbindung gelöscht werden soll und über das Kontextmenü oder eine definierte Tastatur­kombination wird die Verbindung gelöscht. Eine sinnvolle Erweiterung kann dabei sein, dass in den Einstellungen des Plugins festgelegt werden kann, ob das Löschen einer Verbindung zwischen Quellcode und Dokumentation eine Sicherheitsabfrage erfordern soll. Wenn mehre­re Verbindungen zu einer Quellcodestelle existieren, kann die zu löschende Verbindung im Kontextmenü oder aber über eine Popupfenster ausgewählt werden.

Ändern der Verlinkung zum Quellcode

Das Ändern einer Verknüpfung funktioniert wie das Löschen einer Verlinkung. Der Cursor befindet sich innerhalb der Quellcodestelle, deren Verlinkung geändert werden soll und über das Kontextmenü oder eine Tastaturkombination kann eine neue Dokumentation für die beste­hende aus einem Popupfenster ausgewählt werden. Bei der Existenz mehrerer Verlinkungen wird die gewünschte Verbindung direkt über das Kontextmenü oder über ein Popupfenster ausgewählt. Natürlich ist auch das Anlegen einer neuen Dokumentation möglich, auf die dann verlinkt wird.

Zusammenfassung

Der Prozess der Erzeugung einer Dokumentation ist ein neuer Arbeitsschritt in der Implemen­tierungsphase. Sinnvoll ist es, zuerst die Dokumentation anzulegen und durch das Dokumen­tieren zunächst einmal alle nun folgenden Arbeitsschritte und zu erwarteden Ergebnisse zu durchdenken. Danach folgt die Implementierung der Anforderung. Während der Implementie­rung der Quellcodestelle oder am Ende sollten dann noch wichtige Erkenntnisse und Entschei­dung festgehalten werden. Nun können die Quellcodestellen auch genau eingeordnet und in Beziehung zu einander gebracht werden.

4.2.5 Entscheidung

Die prototypische Umsetzung der quellcodegebundenen Dokumentation von Aspekten im Softwaresystem sollte möglichst als Gesamtsystem wirken und in einem überschaubaren Zeit­rahmen implementierbar sein. Darüber hinaus reicht es für die Veranschaulichung der Grund­idee der quellcodegebunden Dokumentation von Aspekten aus, wenn die Verknüpfung wichtiger Quellcodeelemente realisiert wird. Vordergründig sollte die Installation und Ver­wendung des Gesamtsystems schnell und einfach möglich sein, um so die Hürde für das Aus­probieren der Umsetzung der quellcodegebundenen Dokumentation gering zu halten. Die Abbildung 13 vergleicht dabei noch einmal die unterschiedlichen Lösungsansätze miteinan­der. Dabei wird deutlich, dass die Möglichkeit, beliebige Quellcodeelemente dokumentieren zu können, höhere Kosten verursacht. Denn für die Verwendung des AST-Ansatz oder des XML-Ansatz müssen vor allem an der Entwicklungsumgebung Eclipse größere Modifikatio­nen vorgenommen werden. Das hat zur Folge, dass ein nicht abschätzbarerer Aufwand für die Anpassung der Lösung an neuere Eclipseversionen nötig ist. Darüber hinaus, wird damit die Installation des Gesamtsystems unnötig erschwert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Vergleich

Eudibamus befindet sich derzeit zwar noch in der Entwicklung, bietet aber ausreichend Funk­tionalität, um die quellcodegebundene Dokumentation von Aspekten zu veranschaulichen. Gerade auch weil der Eudibamusansatz die Integration eines Webbrowsers in die Entwick­lungsumgebung einschließt und somit ermöglicht, die Dokumentation direkt zu bearbeiten, wird die Umsetzung der quellcodegebundenen Dokumentation unter Verwendung des Eudiba- musplugin fur Eclipse realisiert. Im weiteren werden die Vor- und Nachteil von Eudibamus dargelegt und die Einschränkungen für die quellcodegebundene Dokumentation aufgezeigt.

Vor- und Nachteile der Verwendung von Eudibamus und SnipSnap

Das Eudibamus Plugin für Eclipse ermöglicht die Integration der Bedienung von SnipSnap in die Entwicklungsumgebung und damit in den Implementierungsprozess. Dadurch ist es mög­lich die Dokumentation zu den einzelnen Quellcodeelementen darzustellen. Der Bruch, der zwischen herkömmlicher Dokumentation und Quellcode bestand, wird somit aufgehoben. Es ist nun möglich, sich direkt in der Entwicklungsumgebung die mit dem Quellcode verbunde­nen Dokumentation anzeigen zu lassen und so dem Entwickler zu eröffnen, sich in der abs­trakten Dokumentationsebene frei zu bewegen. Der Vorteil dabei ist, dass der Entwickler direkt über die Dokumentationselemente zu den verbundenen Quellcodeelementen gelangt. Diese Elemente können vornehmlich nur Pakte, Klassen und Methoden sein. Die Erweiterung um alle anderen eindeutig identifizierbaren Javaelemente, wie sie bereits aufgelistet wurden, stellt keine Hürde dar. Nachteilig ist aber die fehlende Integration von Eudibamus und SnipS­nap in die Refaktorisierungsmöglichkeiten und die fehlende Interaktion bei der Veränderung von verlinkten Quellcodeelementen. Diese Unterstützung kann aber durch ein Plugin, das den Editor und das Refaktorisieren erweitert, implementiert werden.

4.3 Zusammenfassung

Die Entscheidung für Eudibamus und SnipSnap steht zum Teil auch mit dem Arbeitsumfeld des Autors in Verbindung, der am Fraunhofer-Institut für Rechnerarchitektur und Software­technik FIRST in Berlin tätig ist. Dort hat er die Möglichkeiten und Chancen von SnipSnap kennengelernt. Der Einblick, der ihm in das SnipSnap Projekt gewährt wurde, hat gezeigt, dass der Funktionsumfang von SnipSnap, der das Dokumentieren von Softwaresystemen er­möglicht, noch anwachsen wird. Das Gesamtsystem mit Eclipse als Entwicklungsumgebung und SnipSnap als Dokumentationsplattform ermöglicht durch ihre Plattformunabhängigkeit die Unterstützung der gängigen Betriebsysteme. Damit wird eine große Hürde für die Verwen­dung des Systems in den unterschiedlichen Bereichen genommen.

5 Prototypische Umsetzung

Das Werkzeug „myAspectMap“ setzt die quellcodegebundene Dokumentation von Aspekten prototypisch um. Der Name „myAspectMap“ entsteht durch die Zusammensetzung der fol­genden Synonyme:

my - durch Entwickler erstellte Dokumentation

Aspekt - konkrete gedanklich kapselbare Einheit von Verhalten eines Softwaresystems

Map - abstrakte Dokumentationsebene, die ein Softwaresystem beschreibt

MyAspectMap ermöglicht die Erstellung einer Dokumentation fur konkrete gedanklich kap­selbare Einheiten von Verhalten eines Softwaresystems und die Vernetzung der Dokumentati­on- und Quellcodeelemente, wodurch eine abstrakte Dokumentationsebene entsteht. Das Werkzeug stellt die praktische Umsetzung dieser Arbeit durch den Autor dar und beinhaltet sowohl die Erweiterungen und Veränderungen an SnipSnap wie auch die Plugins zur Erweite­rung von Eclipse. Die Projektseite von myAspectMap ist unter http://myaspectmap.berlios.de/ zu finden.

Die Umsetzung besteht aus dem Zusammenspiel des Wiki- und Weblogsystems SnipSnap un­ter Verwendung des Eudibamusplugins für Eclipse sowie die Integration der quellcodegebun­denen Dokumentation in die Entwicklungsumgebung Eclipse. Die Abbildung 14 zeigt die realisierten Erweiterungen und Modifikation sowie die Kommunikationswege zwischen den unterschiedlichen Systemen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Prototypische Realisierung - Technische Ansicht

Für die Realisierung der vorgeschlagenen Dokumentationsvorlagen wurden in SnipSnap fol­gende Erweiterungen und Implementierungen vorgenommen:

- Erweiterung von SnipSnap um eine Formularansicht
- Erweiterung der Makroidee um sich selbst darstellende Formularmakros
- Einführung von CSS-Vorlagen für die Formularmakros
- Implementierung generisch verwendbarer Formularmakros
- Erweiterung der RenderEngine zum Speichern und Darstellen der Formularmakros in der Formularansicht
- Implementierung von Hilfsmakros

Auf die einzelnen Umsetzungsdetails der Dokumentationsvorlagen, geht das Kapitel 5.1 „For­mularvorlagen in SnipSnap“ ein.

Der zweite Teil der praktischen Umsetzung beinhaltet die Integration von SnipSnap durch das Eudibamusplugin in Eclipse sowie die Verbindung von Quellcode und Dokumentation. Die Verbindung von Code und Dokumentation umfasst die Visualisierung von Quellcodestellen, die mit Dokumentationselementen verbunden sind, und die Integration des Dokumentations­prozesses in die Entwicklungsumgebung Eclipse. Die praktische Realisierung umfasst nach­folgende Punkte:

- Anpassung des Layouts von SnipSnap für eine bessere Darstellung innerhalb eines kleinen Pluginfensters von Eudibamus.
- Implementierung eines Eclipse Plugin zum Visualisieren der verknüpften Quellcodestellen durch Erweiterung des „Marker“-Ansatzes von Eclipse
- Erweiterung des Plugins um einen XML-RPC Client
- Implementierung eines XML-RPC Handlers für die Kommunikation mit SnipSnap
- Implementierung eines XML-RPC Wrapper Plugins, um die Verwendung der XML-RPC Bibliothek in Eclipse zu ermöglichen
- Implementierung einer Eclipseansicht zur Auswahl von Dokumentationselementen für die Verknüpfung mit Quellcodestellen

Die Umsetzungsdetails werden im Kapitel 5.2 „Integration in die Entwicklungsumgebung“ genauer dargestellt. Im Kapitel 5.3 wird die Verwendung des Werkzeugs mit Hilfe von Benut­zungsszenarien veranschaulicht. Dabei wird anhand von Beispielen die Dokumentation von Quellcodeelementen während des Implementierungsprozesses und der „Nachdokumentation“ innerhalb der Wartungsphase dargestellt. Darüber hinaus werden die Möglichkeiten der ent­standenen abstrakten Dokumentationsebene für das Verständnis des Softwaresystems veran­schaulicht.

5.1 Formularvorlagen in SnipSnap

Für die Einführung von Formularen in SnipSnap ist es erforderlich die Funktionsweise von SnipSnap zu beschreiben (siehe Kapitel 5.1.1). Im Anschluss daran wird erläutert, wie die Wi­kisyntax von SnipSnap durch Makros erweitert werden kann (siehe Kapitel 5.1.2). Auf dem Makrokonzept aufbauend wird die Einführung von Formularmakros erläutert. Formularma­kros stellen variable Komponenten zur Erzeugung von beliebigen Formularen in SnipSnap dar (siehe Kapitel 5.1.3). Die Grundlage für das Formularkonzept in SnipSnap bildet die Formu­laransicht für Snips, die Integration dieser Ansicht in SnipSnap wird in Kapitel 5.1.3 erläutert. Abschließend wird dargelegt, wie Formularvorlagen in SnipSnap erstellt werden können (sie­he Kapitel 5.1.3).

5.1.1 Grundlegende Funktionsweise von SnipSnap

SnipSnap ist ein Wiki. Ein Wiki ist eine im World Wide Web verfügbare Sammlung von Sei­ten, die von den Benutzern nicht nur gelesen, sondern auch online geändert werden können. SnipSnap ist darüber hinaus eine Serverapplikation, die auf einem Java Web Server und Servlet Container namens Jetty läuft.

Auf SnipSnap kann damit über den Webbrowser zugegriffen werden. In einem SnipSnap- System können beliebig viele Seiten, genannt Snips, gespeichert sein. Diese Seiten können In­formationen zu beliebigen Themen enthalten. Snips sind damit nach außen nichts weiter als normale Webseiten. Der Vorteil eines SnipSnap-Systems ist, dass über den Webbrowser di­rekt neue Snips bzw. Seiten angelegt, bestehende Snips geändert oder gelöscht werden kön­nen. Darüber hinaus kann nach Begriffen innerhalb des Systems gesucht werden. Das Standardsuchergebnis liefert dabei alle Snips, die den gesuchten Begriff enthalten. Die Abbil­dung 15 veranschaulicht einen Snip zum Thema „aktuelle Softwareversionen“. Es wird deut­lich, dass Snips nach außen hin genauso wie normale Webseiten aussehen. Gegenüber einer normalen Webseite kann ein Snip aber direkt vom Benutzer editiert werden, indem in der Funktionsleiste eines Snips auf „edit“ geklickt wird. Es erscheint dann, wie in Abbildung 16 dargestellt, die Editoransicht eines Snips. In dieser wird der gesamte Snip Kontext in einer frei editierbaren Eingabemaske angezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: SnipSnap

Der Kontext in einem Wikisystem wird im Gegensatz zu einer normalen HTML-Seite nicht mit Hilfe von HTML-Tags sondern über die WikiSyntax layoutet. Die WikiSyntax für SnipS­nap befindet sich in jedem SnipSnap-System im Snip „snipsnap-help“ [SnipSyntax]. Die Wi­kisyntax für SnipSnap verwendet beispielsweise zwei hintereinander folgende Unterstriche vor und hinter einem Wort zum Fettschreiben des Wortes in der Normalansicht (siehe Abbil­dung 16 und 17 die Softwareversionsnummern). Eine weitaus größere Möglichkeit zum Dar­stellen von Inhalten in SnipSnap bieten Makros. Makros sind in diesem Fall eine Art Layoutvorlage, deren Inhalt durch Makroparameter ergänzt und bestimmt werden kann. Auf die Funktionsweise von Makros geht das Kapitel 5.1.2 genauer ein.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: SnipSnap Editoransicht

Metainformationen zu einem Snip

Über den normalen Kontext hinaus kann ein Snip Metainformationen über sich selbst spei­chern. Diese Metainformationen ermöglichen beispielsweise die Speicherung des Typs eines Snips oder aber die Art, wie er dargestellt werden soll. Konfigurationsdateien von SnipSnap sind in SnipSnap selbst als Snips abgelegt. Damit der Kontext dieser Konfigurationssnips nicht in der Normalansicht interpretiert wird, kann ihnen beispielsweise eine andere Darstel­lungsart zugewiesen werden. Die Möglichkeiten der Verwendung von Labels sind vielfältig. Darüber hinaus können Labels wie Markos selbst definiert und nachgeladen werden. Da sich diese Funktionalität in einem Umbruch befindet, sei an dieser Stelle auf die Projektseite von SnipSnap verwiesen [SnipSnap].

5.1.2 Erweiterungsmöglichkeiten von SnipSnap durch Makros

Für die Einführung von dynamischen Formularen in SnipSnap ist es erforderlich, zunächst die standardisierte Erweiterungsmöglichkeit von SnipSnap durch Makros zu beschreiben. Die Makros stellen die Grundlage für die Erweiterung von SnipSnap um Formularmakros dar. Makros sind, wie beschrieben, eine Möglichkeit, um die Wikisyntax von SnipSnap beliebig zu erweitern. SnipSnap unterscheidet zwischen Radeoxmakros und SnipSnapmakros. SnipS- napmakros ermöglichen den Zugriff innerhalb des Makros auf den Snip, in dem sie ausgeführt werden. Im Weiteren wird im Zusammenhang mit Makros nur noch von SnipSnapmakros ge­sprochen. Makros können von unterschiedlichen Entwicklern losgelöst von SnipSnap wie Plu­gins entwickelt werden. Ein Makro wird durch eine eigene Klasse realisiert, die von der Klasse SnipMacro erbt und wie in Abbildung 17 (Code) dargestellt, die execute und getname Methode implementiert. Die getname Methode muss einen eindeutigen Namen für ein Makro zurückgeben, um die Verwendung des Markos durch den Makronamen (siehe Abbildung 17 (blau)) eindeutig der Klasse des Makros zuordnen zu können. Dies ist erforder­lich, um die im SnipSnap-System geladenen Makros bei ihrer Verwendung eindeutig zu iden­tifizieren. In der Normalansicht werden die Makros dargestellt bzw. ausgeführt. Anstelle der Makrosyntax wird die in der execute Methode definierte Ausgabe visualisiert (siehe Abbil­dung 17 (Normalansicht)). Bei der Verwendung eines Makros können diesem beliebig viele Parameter mit übergeben werden. Wofür die Makroparameter verwendet werden, hängt von der Implementierung der execute Methode ab. SnipSnap kann dabei nicht direkt die Gültig­keit der Parameter überprüfen. Die Überprüfung der Parameter ist nur in der execute Me­thode möglich. Im Beispiel Abbildung 17 wird der erste mit übergebene Parameter hinter dem Text mit ausgegeben. Der zweite Parameter wird innerhalb der execute Methode nicht ver­wendet und ist damit gegenstandslos. Die Klasse des Makros kann darüber hinaus eine Me­thode getParamDescription überschreiben (die Methode getParamDescription liefert standardmässig nur einen Hinweistext). Der Rückgabewert der Methode beschreibt in der Hilfe von SnipSnap die Makroparameter des Makros. Darüber hinaus kann die Klasse des Makros eine weitere Methode überschreiben, um eine spezielle Beschreibung des Makros in der Hilfe anzuzeigen. Um die selbst entwickelten Makros in SnipSnap zu integrieren, müssen die Class-Dateien der Makros zusammen mit der Konfigurationsdatei „org.radeox.macro.Ma- cro“, die im Verzeichnis „META-INF/services“ stehen, in eine JAR-Datei gepackt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Verwendung eines Makros Codeansicht, Editoransicht, Normalansicht

Um die einzelnen Makros zu registrieren wird in der Konfigurationsdatei in je eine Zeile der vollständige Klassenname eines Makro geschrieben. Damit die Makros beim Start von SnipS- nap automatisch geladenen werden, muss die JAR-Datei in das Bibliotheksverzeichnis der SnipSnap Applikation kopiert werden. Weitere Informationen zur Implementierung von Mar­kos findet man auf den Projektseiten von SnipSnap [SnipSnap].

5.1.3 Formularansicht

SnipSnap ermöglicht standardmässig nur die einfache Erstellung von Snips in der Editoran­sicht durch das direkte Schreiben von Wikisyntax (siehe Abbildung 16). Das Ausfullen von Formularen wird dabei nicht durch das System unterstützt. SnipSnap wurde daher um eine Formularansicht erweitert. Die Formularansicht ist eine spezielle Editoransicht für Snips, die vom Typ Formular sind. Die Abbildung 18 veranschaulicht den praktischen Unterschied zwi­schen einem Formularsnip und einem normalen Snip.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Formularsnip und ein normaler Snip in der Nomialansicht

In der Formularansicht können Daten formalisiert eingegeben werden. Die Formularansicht stellt eine neue zusätzliche Ansicht für Snips des Typs Formular in SnipSnap dar. Die Formu­laransicht selbst gibt dabei den technischen Rahmen für die Formulare vor. Die Formulare selbst können durch spezielle Makros, sogenannte Formularmakros, beschrieben werden. For­mularmakros stellen dabei eine Erweiterung der bestehenden Makroidee dar. Durch das Be­schreiben des Snipkontexts unter Verwendung von Fomularmakros und die Zuweisung des Typs Formular als Label (engl. Form) ist es möglich einen Snips nicht nur in der normalen Editoransicht, sondern auch in der Formularansicht darzustellen. Die Erweiterung der Makroi­dee durch Formularmakros wird im Folgenden erläutert.

Form ularmakros

Für die Formularansicht ist es wie dargestellt erforderlich, dass das Makrokonzept von SnipS­nap um Formularmakros erweitert wird. Der Ansatz, dass ein Makro selbst weiß, wie es in der Normalansicht dargestellt werden möchte, wurde auch für die Formularansicht aufgegriffen. Ein Formularmakro erbt von der Klasse AbstractFormViewSnipMacro. Diese Klasse erweitert die Schnittstelle der Klasse SnipMacro um die Methoden editOutput und storeOutput. In der Methode editOutput definiert ein Formularmakro, wie es in der Formularansicht dargestellt wird und in der Methode storeOutput legt es fest, wie die ein­gegeben Daten aus der Formularansicht abgespeichert werden sollen. Um die Implementie­rung von Formularmakros zu vereinfachen, enthält die Klasse AbstractFormViewSnipMacr einige Hilfsmethoden. Darüber hinaus implementiert die Klasse die Speicherung der Daten aus der Formularansicht generisch, so dass die Methode storeOutput nur in sehr speziellen Fällen überschrieben werden muss. Zu den Methoden, die durch ein Formularmakro implementiert werden müssen, gehören die Methoden edi- tOutputHock und execute. Die Methode editOutput der Klasse AbstractForm- ViewSnipMacro ruft dabei die spezielle Implementierung der Methode editOutputHock eines Formularmakros auf. Die Methode editOutputHock enthält den Teil an Funktionalität, der speziell für dieses Makro implementiert wurde. Die Schnittstel­le eines Formularmakros veranschaulicht die Abbildung 19 noch einmal genau. Damit ist es nun möglich, beliebige Formularmakros für die speziellen Bedürfnisse der Dokumentations­vorlagen zu implementieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: Schnittstelle einesFormularmakros

Anzumerken ist, dass gerade die Mehrfachverwendung von Makros in einem Snip und die Speicherung von Daten über die Formularansicht, die Einführung von speziellen Ids bei der Interpretierung der Makros für die Formularansicht und die Auswertung der Formularansicht nötig gemacht haben. Für diese Details sei auf den Quellcode der praktischen Umsetzung ver­wiesen.

Die Realisierung der Anforderungen durch Dokumentationsvorlagen erfordert die Implemen­tierung von generischen Formularmakros, da der Großteil von Formularen in WWW aus we­nigen verschiedenen Elementen zusammengesetzt wird. Im Speziellen wurden folgende Formularmakros implementiert:

Implementierte Formularmakros

Textbox

Makrosyntax

{docu_textbox:<Beschriftung>}Inhalt{docu_textbox}

Formularansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20 :Formularmakro "docujextbox" Formularansicht

Normalansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Formularmakro "docujextbox" Normalansicht

Textarea

Makrosyntax

{docu_textarea:<Beschriftung>}Inhalt{docu_textarea}

Formularansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 22 :Formularmakro "docujextarea" Formularansicht

Normalansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 23: Formularmakro "docujextarea" Normalansicht

Text

Makrosyntax

{docu_text:<Beschriftung für die Formularansicht>}Inhalt

{docu_text}

Formularansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 24: Formularmakro "docujext" Formularansicht

Normalansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 25: Fomiularmakro "docujext" Normalansicht

Label-Selection

Makrosyntax

{form_label:<Name des Labels>, <Typ des Labels>, <Beschrif­tung>, Eingabefeld [true/false], [Listenname des Labels], [Listenwert des Labels], Wert als Link[true/false] }?? {form_label}

Formularansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 26: Formularmakro "form_Jabel"Formularansicht

Normalansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 27: Fomiularmakro "form Jabel" Normalansicht

Wrapper für SnipSnapmakros Makrosyntax

{docu_macrowrapper:<Beschriftung in der Fomularansicht>, <Makroname>, [Parameter des Makros]*}??{docu_macrowrapper}

Formularansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 28: Formularmakro "docujnacrowrapper" Formularansicht

Normalansicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 29: Formularmakro "docujnacrowrapper" Normalansicht

Darüber hinaus wurden einige weitere Makros zur Verbesserung der Visualisierung der For­mularansicht implementiert. An dieser Stelle sei auf die Lösung des praktischen Teils verwie­sen.

Technische Lösung der Formularansicht

Die technische Lösung der Formularansicht stellt die Grundlage des Formularkonzeptes für SnipSnap dar. Die Implementierung beinhaltet folgende Teile:

- FormViewServlet und JSP-Seite für die Formularansicht
- FormStoreServlet für die Speicherung der Inhalte aus der Formularansicht
- FormViewRenderEngine zum Aufbau der Formularansicht
- FormStoreRenderEngine zum Auswerten und Speichern der Formularansicht
- FormViewFilter für die RenderEngine zum Aufbau der Formularansicht
- FormStoreFilter für die RenderEngine zum Auswerten und Speichern der Formularansicht

Für spezielle Details der Implementierung sei auf den Quellcode der praktischen Lösung ver­wiesen. Im Folgenden wird nur das Zusammenspiel der unterschiedlichen Komponenten be­schrieben. Abbildung 30 veranschaulicht das Zusammenwirken der einzelnen Komponenten. Der Darstellungsrahmen der Formularansicht wird durch das FormViewServlet und die dazu­gehörige JSP-Umsetzung realisiert. Die Aufgabe, den Kontext eines Snips für die Formularan­sicht zu interpretierten, übernimmt eine speziell implementierte FormViewRenderEngine. Diese RenderEngine baut auf der Verwendung eines speziellen FormViewFilters zur Anzeige von Snips auf. Der Filter analysiert den SnipSnapKontext und filtert alle Makros heraus. In ei­nem weiteren Schritt überprüft der Filter, ob es sich beim gefilterten Makro um ein Formular­makros handelt. Ist dies der Fall, wird die Methode editOutput des Makros ausgeführt.

Handelt es sich bei den gefilterten Teilen des Kontextes beispielsweise um SnipSnapMakros, werden diese und alle anderen Inhalte wie in der Normalansicht interpretiert. Darüber hinaus speichert der Filter zusätzliche Daten über die verwendeten Makros und ermöglicht somit die Bereitstellung von Zusatzinformationen, die durch den HttpServletRequest des Servlets transportiert werden. Nun kann das Formular vom Webbrowser geladen und darge­stellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 30: Funktionsweise der Formularansicht

Nachdem das Formular ausgefüllt oder verändert wurde, können diese Modifikationen abge­speichert werden. An dieser Stelle greift das FormStoreServlet die Daten aus dem HttpServletRequest auf und verarbeitet die Daten aus dem Formular mit den intern ge­speicherten Variablen. Anschließend leitet das Servlet die Daten an die FormStoreRenderEn- gine weiter. Diese verwendet einen speziellen FormStoreFilter, der wiederum aus dem Snip- kontext die Formularmakros herausfiltert und über die storeOutput Methode der Formu­larmakros die Daten für die einzelnen Makros abspeichert.

Gerade für die Datenspeicherung müssen einige Hilfsfunktionalitäten verwendet werden, da die Speicherung der Daten im Snipkontext nicht einfach zu realisieren ist.

Festzuhalten bleibt, dass damit beliebige, von unterschiedlichen Entwicklern implementierte Formularmakros, verwendet werden können. Darüber hinaus ist es zur grafischen Verschöne­rung der Formularansicht möglich auch normale Makros, die jedwede HTML Funktionalität implementieren, zu verwenden. Der FormularMakroWrapper für normale Makros erlaubt es, die Standardmakros von SnipSnap editierbar in die Formularansicht zu integrieren.

Aufbau von Formularvorlagen

Die Formularansicht ermöglicht zusammen mit den Formularmakros die Verwendung von Formularen in SnipSnap. Im Folgenden wird dargestellt, wie Vorlagen in SnipSnap aufgebaut und verwendet werden können.

Die Formularmakros werden in der Standardeditoransicht dazu benutzt den Inhalt des Snips zu beschreiben. Weiterhin muss der Typ des Snips auf „Form“ gesetzt werden. Nun ist es möglich den Snip in der Formularansicht darzustellen. Man kann damit beliebige Snips als Formularvorlagen erstellen. Ein spezielles Makro ermöglicht darüber hinaus die Erstellung ei­nes beliebigen Formularsnips aus einer Vorlage durch Eingabe eines Namens für den Formu- larsnip und die Auswahl einer Formularvorlage durch Eingabe des Snipnamens oder durch die direkte Auswahl der Vorlage. Dadurch kann zum Beispiel direkt aus einer Dokumentations­vorlage eine beliebige Dokumentation erstellt werden.

5.1.4 Wissensmodell

Das Wissensmodell beschreibt die Typisierung und Verlinkungsmöglichkeiten von Dokumen­tationselementen bzw. Snips, Codesnips und Formularen. Codesnips sind direkte Repäsenta- tionen von JavaElementen, die eindeutig über ihren Namen referenzierbar sind. Codesnips stellen die Verbindungen zwischen Javaelementen und Dokumentationselementen, im weite­ren nur noch Dokumentationssnips genannt, dadurch her, dass ein Codesnip das eindeutige Abbild eines Javaelementes ist. Dadurch ist es möglich, alle Informationen, die an einem Ja­vaelemente gespeichert werden sollen, direkt am Codesnip zu speichern.

Labels sind in SnipSnap nur sehr eingeschränkt verwendbar, da einem Snip ein Label nur ein­mal zugewiesen werden kann. Beispielsweise ist es nicht möglichen, dass ein Snip zwei glei­che Labels mit unterschiedlichen Werten besitzt. Daher wurde ein zusätzliches Dokumentationssniptyplabel eingeführt, um einem Label mehr als einen Typ zuweisen zu können. Darüber hinaus erfolgte eine Erweiterung des Standardtyplabel um die Typen „Form“ (Formular), „FormTemplate“ (Formularvorlage) und „Codesnip“. Das Dokumentationssnip­typlabel, genannt „ExtendedType“ Erweitertertyp. Standardmässig sind die folgenden Typen für ExtendedTyplabel schon vorgegeben:

- aspect (Aspektdokumentation)
- aspectpart (Teilaspektdokumentation)
- project (Projektdokumentation)
- patter (Musterdokumentation)
- docu (Dokumentation)
- maintenanceactivity (Wartungsaktivitätendokumenation)

Die Einschränkungen der Labelfunktionalität wirken sich besonders stark auf die direkte Ver­linkung von Snips mit anderen Snips aus. So ist es beispielsweise nicht möglich, in einem La­bel eine Liste von Snip zu speichern und so einen Snip mit beliebig vielen anderen Snips zu verlinken. Daher wird für eine m:n, m:l und l:n Verbindung in dem Wert eines Label eine se- rialisierte Liste von Werten gespeichert. So kann das Label „connectedDocus“ des Codesnips beliebig viele Verbindungen zu Dokumentationssnips halten. Die Verbindungen zwischen ei­nem Codesnip und den Dokumentationssnips werden ausschließlich im Codesnip gespeichert. Das heißt, dass eine Dokumentationssnip nicht weiß mit welchem Codesnip er verbunden ist. Ein Dokumentationssnip kann aber die zentrale Instanz fragen mit welchem Codesnip er in Verbindung steht. Falls es möglich wird, in SnipSnap Snips umzubenennen, kann die Refak- torisierungsunterstützung für die quellcodegebundene Dokumentation problemloser imple­mentiert werden. Da so nicht die Dokumentationssnips sondern nur die Codesnips verändert werden müssen.

Zur direkten Verbindung von Aspekten und Teilaspekten, Dokumentationssnips mit Aspekten und die Zuordnung von Dokumentationssnip zu Projekten, wurden noch folgende Labeltypen eingeführt:

- partofaproject (Teil eines Projektes)

Es ist so möglich, direkt auf den Projektsnip zu verweisen.

- parentaspect (Eltern Aspekt)

Jeder Teilaspekt kann genau einem Elternaspekt zugewiesen werden.

- partofaaspect (Teil eines Aspekts)

Beliebige Dokumentation können einem Aspekt zugewiesen und so in die abstrakte Doku­mentationsebene eingeordnet werden.

Für die Einführung weiterer Labels sei auf die Erweiterungsmöglichkeit von SnipSnap ver­wiesen, die es erlaubt, Labels wie Makros selbst zu implementieren [SnipSnap].

Snips können in SnipSnap nicht nur über Labels direkt miteinander verlinkt werden, sondern sie können auch indirekt über ihren Kontext miteinander verbunden werden. Dazu muss nur im Snipkontext eines Snips durch einen Link auf einen anderen Snip verwiesen werden. Dabei stellt ein Link auf einen anderen Snip nichts anderes dar, als einen Hyperlink (wie er aus HTML bekannt ist). Darüber hinaus kann der Inhalt von Snips direkt in andere Snips hinein­gepackt werden, ohne ihn hineinkopieren zu müssen. Alle diese indirekten Möglichkeiten Snips miteinander zu verbinden, bietet SnipSnap schon von sich aus. Darüber hinaus ist durch die Projektentwickler von SnipSnap geplant, die Labelfunktionalität zu erweitern, da deren Funktionalität, wie sich gezeigt hat, nicht ausreicht. Für die Demonstration der quellcodege­bundenen Dokumentation reichen die Möglichkeiten zur Vernetzung der Informationen res­pektive Snips in SnipSnap aus.

5.2 Integration in die Entwicklungsumgebung

Die Integration in die Entwicklungsumgebung umfasst vor allem die Verbindung von Quell­code- und Dokumentationselementen. Die Verbindung von Quellcodeelementen und Snips er­folgt indirekt durch die Referenzierung der eindeutigen Namen der JavaElemente. In der praktischen Umsetzung ist es möglich, Klassen, Methoden und Pakete mit Snips zu verlinken. Die Realisierung der m:n Verbindung zwischen Dokumentationselementen bzw. Snips und Quellcode bzw. JavaElementen erfolgt über Codesnips. Die Verbindungen zwischen Codeele­menten und Dokumenatiosnips wird in den Metadaten des entsprechenden Codesnips im La­bel „connectedDocus“ gespeichert. Zusätzlich wird für jede Verbindung die Rolle, die eine Quellcodestelle im Zusammenhang mit der verlinkten Dokumentation spielt, festgehalten. Die

Abbildung 31 veranschaulicht diese Verbindungen noch einmal deutlich. Die Anforderung, beliebige Quellcodestellen zu verlinken, wurde in der prototypischen Umsetzung nicht reali­siert, da zur einfachen Veranschaulichung des Konzeptes der quellcodegebundenen Dokumen­tation sich die gewählte Umsetzung am besten eignet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 31: Quellcode Dokumentationsverbindung durch Codesnips und Snips

Die Dokumentation des Softwaresystems wird innerhalb der Entwicklungsumgebung durch das Eudibamusplugin (Webclient) dargestellt. Über Eudibamus ist es möglich, die Dokumen­tationen zu erstellen und zu verändern ober auch zu löschen. Um die verlinkten Quellcodestel­len innerhalb der Entwicklungsumgebung visualisieren, anlegen, löschen oder verändern zu können, kommuniziert das myAspectMap Plugin über XML-RPC mit dem SnipSnap-System. Durch den XML-RPC Handler, der in SnipSnap integriert wurde, können Daten aus SnipSnap ausgelesen und geschrieben werden. Damit ist es möglich, direkt aus der Entwicklungsumge­bung Eclipse heraus die Quellcode-Dokumentation respektive Codesnip - Snip Verbindungen anzulegen, zu löschen oder zu bearbeiten. Die Abbildung 14 auf Seite 84 veranschaulicht die­se Kommunikationswege noch einmal deutlich.

Das myAspectMap dient vor allem der Visualisierung und dem Management von Verbindun­gen zwischen Quellcode und Dokumentation. Dazu implementiert es einen Dokumentations­marker fur den Ruler (linke Statusleiste in der Eclipse Quellcodeansicht) sowie die nötigen Kontextmenüs zum Anlegen, Verändern und Löschen eines Markers. Diesen Marker nutzt das Plugin auch zum Visualisieren bestehender Verbindungen zwischen Quellcodeelementen und Dokumentationssnips. Für die einzelnen Implementierungsdetails sei auf den Quellcode der Umsetzung verwiesen. Anzumerken ist, dass für die Verwendung von XML-RPC ein Wrap- perPlugin geschrieben werden musste, um die XML-RPC Bibliotheken in Eclipse verwenden zu können. Außerdem wurde ein reduziertes Layout für die Darstellung von Snips in Eudiba- mus implementiert, da das Browserfenster meist als kleines Pluginfenster verwendet wird. Die Kommunikation des Eclipse Plugin mit SnipSnap über XML-RPC beschränkt sich zum Groß­teil auf die Übermittlung von Listen von Dokumentationselementen und auf das Anlegen und Modifizieren von Codesnips. Die Details können direkt dem Quellcode entnommen werden.

5.3 Anwendungsbeispiele

Die Verwendung des Werkzeuges wird für die wichtigsten Entwicklungsphasen exemplarisch dargestellt. Zunächst wird die quellcodegebundene Dokumentation von Aspekten während der Implementierung betrachtet. Im Anschluss folgt die Darstellung des Vorgehens beim Doku­mentieren von bestehenden Softwaresystemen unter Verwendung der quellcodegebundenen Dokumentation. Viele bestehende Systeme sind wie bereits dargestellt, nicht oder nur unzurei­chend dokumentiert. Gerade dann hat der Entwickler große Probleme, das System zu verste­hen. Der Entwickler ist dann gezwungen, das System Schritt für Schritt zu analysieren. Dabei fallen immer mehr Informationen zu bestimmten Quellcodestellen und Erkenntnisse über das Zusammenspiel unterschiedlicher Systemteile an. Der Entwickler versucht nun während der Analyse des Systems, Notizen über das Wissen und die Informationen anzufertigen, die er zum System gewonnen hat. Zumeist werden diese Notizen in vom Quellcode getrennten Text­dokumenten festgehalten. Eclipse bietet für das Festhalten von wichtigen Randbemerkungen Lesezeichen (engl. Bookmarks) an. Diese können alledings nicht miteinander verbunden oder anderen Entwicklern zugänglich gemacht werden. Hier schafft die Umsetzung der quellcode­gebundenen Dokumentation Abhilfe.

5.3.1 Implementierungsphase

Durch die quellcodegebundene Dokumentation des Softwaresystems während der Implemen­tierungsphase ist das direkte Festhalten aller wichtigen Fakten zum Softwaresystem möglich. In welchen Schritten ein System bei der Implementierung dokumentiert werden kann, wird im Folgenden anhand eines Beispiels näher beschrieben.

Ein Entwickler bekommt den Auftrag, ein Makro für SnipSnap zu implementieren, das einen beliebigen Text farbig darstellen kann. Der Entwickler macht sich zunächst Notizen in einem Snip, im weiteren als Gedankensnip bezeichnet (in Eclipse unter Verwendung der Eudibamus- plugin), welche Informationen er für die Implementierung des Makros benötigt. Da er bereits einige Makros für SnipSnap implementiert hat, kennt er sich mit den Grundlagen der Imple­mentierung eines Makros aus. Es fehlen tuen ihm aber noch Informationen darüber, wie der Text durch HTML-Tags farbig angezeigt werden kann. Dazu surft er zu den Webseiten von SELFHTML und sucht die ihm fehlenden Informationen heraus. Den Link zu der konkreten Seite bei SELFHTML hält er zusammen mit einem Vermerk in seinem Gedankensnip fest. Nun kann er anfangen das Makro zu implementieren. Nach kurzer Zeit ist das Plugin fertig und er testet es in einem SnipSnap-System. Dabei stellt er fest, dass er einen Fehler gemacht haben muss, denn der Text, den er eingegeben hat, wird nicht dargestellt. Nach den Testen und Ausprobieren ermittelt er, dass er den falschen Makroparameter für die Darstellung des Textes verwendet hat. Nachdem er den Fehler analysiert und herausgefunden hat, dass durch das Kontrollieren der erforderlichen Parameter vor deren Verwendung der Fehler abgefangen werden kann, hält er sein Wissen in einem Fehlertagbucheintrag fest. Den Eintrag verlinkt er darüber hinaus direkt mit der Methode der Klasse des Makros, in der der Fehler aufgetreten ist, sowie mit der Basisklasse des Makros. Der Entwickler behebt den Fehler und das Makro funktioniert nun wie gewollt. Anschließend dokumentiert er die Realisierung des Makro kurz in seinem Gedankensnip und macht diesen zu einer Dokumentation, die er wiederum mit der Klasse des Makros verbindet. Die Dokumentation weist er nun dem Teilaspekt „Makro-Vi­sualisierung von Text“ zu. Damit ist der Entwickler fertig und wendet sich der nächsten Auf­gabe zu.

Es ist zu erkennen, dass das Dokumentieren des Softwaresystems parallel zum Implementie- rungspozess abläuft und ohne den Entwickler zu behindern.

5.3.2 Analyse- und Wartungsphase

Das Implementierungsbeispiel greift die Beschreibung der Möglichkeiten der quellcodegebun­dene Dokumentation für die Analyse- und Wartungsphase auf.

Einige Tage nach der Implementierung des Makros für SnipSnap zum farbigen Darstellen von Texts soll das Makro, um die Verwendbarkeit in der Formularansicht erweitert werden. Da der Programmierer, der das Makro implementiert hat, krank ist, wird ein anderer Entwickler gebeten, das Makro zu erweitern bzw. umzubauen.

Leider kennt sich der Entwickler nicht mit der Entwicklung von Makros für SnipSnap aus. Daher liest er zunächst einmal die Dokumentation, die er an der Implementierung des Makros entdeckt hat. Schnell wird ihm klar, wie das Makro implementiert wurde. Es stellt sich für ihn nur noch die Frage: „Wie kann ich aus einem normalen Makro ein Formularmakro machen?“ Dazu surft er durchs Netz und entdeckt auf den myAspectMap Webseiten eine Beschreibung des Formularmakrokonzeptes. Den Link zu der Seite und seine Gedanken hält er in dem be­reits existierenden Dokumentationssnip zur Klasse fest. Bei der Suche nach der Implementie­rung eines Formularmakros stellt er fest, dass bereits einige Makros für das bestehende System implementiert, aber nicht dokumentiert wurden. Er macht sich nun daran, die Funkti­onsweise eines bestehenden Formularmakros nachzuverfolgen und hält dazu seine Erkenntnis­se in einem neuen Dokumentationssnip fest und verlinkt diesen mit der analysierten Makroklasse sowie mit dem Aspekt „Makro“. Nach und nach wird ihm klarer, wie das Kon­zept funktioniert. Bei seiner Suche im SnipSnapDokumentationssystem stößt er auf eine Do­kumentation über die Konfigurationsdateien für die Registrierung von Makros. Er verbindet die bestehende Dokumentation des zu erweiternden Makros indirekt über einen Link mit der Dokumentation, die eine Funktionsweise der Konfigurationsdatei beschreibt und verlinkt sie mit der existierenden Konfigurationsdatei. Dem Entwickler ist nun klar, das er nun nur noch eine zusätzliche Methode implementieren und von der Basis Klasse AbstractForm- ViewSnipMacro erben muss. Er testet seine Implementierung und stellt fest, dass es zu ei­nem Fehler in der Formularansicht kommt. Bei der Betrachtung der Klasse entdeckt er den verlinkten Fehlertagebucheintrag. Dabei kommt ihm der Gedanke, dass er vielleicht in der Methode editOutputHock die falschen Parameter benutzt hat. Nachdem er festgestellt hat, dass das der Fehler war, testet er das Makro erneut. Nun funktioniert es. Zum Abschluss seiner Arbeit erstellt er unter Verwendung der Dokumentationsvorlage fur Wartungsaktivitä­ten noch die Dokumentation zu seiner Implementierung und wendet sich dann anderen Aufga­ben zu.

Wie sich zeigt, integriert sich die quellcodegebundene Dokumentation gut in den Analyse- und Wartungsprozess und ermöglicht somit die schnelle Bearbeitung selbst unbekannter Pro­blemfelder.

5.4 Umsetzungen der Anforderung

An die Umsetzung der quellcodegebundenen Dokumentation wurden eine Vielzahl von An­forderungen gestellt. Dazu zählen die Integration in den Implementierungsprozess, die Ver­bindung von beliebigen Quellcodestellen mit Dokumentationselementen, die Unterstützung bei der Erstellung einer einheitlichen Dokumentation sowie die Beschreibung von Aspekten durch Teilaspekte und die Zuordnung von Dokumentationselementen zu Aspektbeschreibun­gen. Die Realisierung der Anforderungen wird im Folgenden kurz noch einmal zusammenge­fasst.

Die Integration in den Implementierungsprozess beinhaltet die einfache Arbeit mit den Ver­bindungen zwischen Quellcode- und Dokumentationselementen, wie sie in Kapitel 5.3 darge­stellt wurden. Darüber hinaus werden die Verbindungen direkt in der Entwicklungsumgebung visualisiert. Die Integration von myAspectMap in die Refaktorisierungsmöglichkeit von Eclipse, wurde nicht umgesetzt. Die geforderte Versionierung der Dokumentation bzw. der Snips wird direkt von SnipSnap unterstützt und ermöglicht auch den Vergleich zwischen un­terschiedlichen Dokumentationsversionen. Die Verbindung von beliebigen Dokumentations­elementen und Quellcodestellen wurde in der prototypischen Umsetzung auf die Verbindung von beliebigen Dokumentationselementen und Paketen, Klassen und Methoden beschränkt. Darüber hinaus wurde das Konzept der Dokumentationsvorlagen vollständig umgesetzt und ermöglicht so die Erstellung einer einheitlichen Dokumentation. Die Möglichkeiten der Doku­mentation sind dabei nicht auf die einfache textuelle Beschreibung beschränkt, sondern es ist möglich, beliebige Inhalte, die im WWW dargestellt werden können, zu verwenden bzw. durch Makros zu integrieren. Es ist auch möglich, die Dokumentation mit externem Wissen aus dem Intranet oder Internet über Links zu verknüpfen. SnipSnap kann, da es über den Web­browser benutzt wird, auch für das Paarprogramming aus XP eingesetzt werden. Ein Entwick­ler programmiert beispielsweise und der andere Entwickler schreibt schon die Dokumentation.

Dabei ist die sofortige Verbindung von Quellcode und Dokumentation durch den program­mierenden Entwickler möglich. Dies wird dadurch erreicht, dass der dokumentierende Ent­wickler auf dem SnipSnap-System des programmierenden Entwicklers arbeitet. Der Schutz der Dokumentation ist durch eine Zugriffskontrolle des SnipSnap-System gegeben. Abschlie­ßend lässt sich sagen, dass durch die Verbindung beliebiger Teilaspektdokumentationen mit Aspektdokumentationen ein Aspekt in kleineren Einheiten beschrieben werden kann. Es ist dabei auch möglich, beliebige Dokumtationselemente mit Aspekten oder Teilaspekte zu ver­knüpfen. Die Verteilung der Aspekte im Quellcode wird dabei in SnipSnap durch die Auflis­tung der verbundenen Quellcodestellen realisiert.

SnipSnap bietet durch die Fülle an Funktionalitäten eine Reihe von Möglichkeiten, um ein Softwaresystem zu dokumentieren und darüber hinaus die Kommunikation zwischen den Mit­arbeitern zu vereinfachen.

5.5 Installation des Systems

Die Installation der prototypischen Umsetzung der Arbeit, im weiteren myAspectMap ge­nannt, erfolgt in mehren Schritten. Zunächst ist es erforderlich, dass folgende Pakete aus dem Internet heruntergeladen werden:

- Aktuelle von myAspectMap unterstützte Version von Eclipse [Eclipse]
- Modifiziertes SnipSnap von myAspectMap [myAspectMap]
- myAspectMap Plugin für Eclipse und das modifizierte SnipSnap [myAspectMap]

Im nächsten Schritt wird Eclipse und das MyAspectMap Plugin für Eclipse wie unter Eclipse üblich in das Pluginverzeichnis installiert. Danach wird das modifizierte SnipSnap Paket wie von SnipSnap beschrieben, entpackt und SnipSnap wie üblich installiert. Bei Problemen mit SnipSnap empfiehlt es sich, die Projektseite von SnipSnap zu studieren. Die sehr aktive Ge­meinschaft hilft gern. Danach können SnipSnap und Eclipse gestartet werden und die Einstel­lungen am myAspectMap Plugin für Eclipse vorgenommen werden.

Im Laufe des Frühjahrs 2004 wird es auf den Projektseiten von myAspectMap auch einen Patch für die jeweils aktuelle SnipSnapversion geben, um SnipSnap direkt selbst für myA­spectMap anpassen zu können.

6 Zusammenfassung - Fazit

Die Werkzeugunterstützung für die Erstellung quellcodegebundener Dokumentation für Aspekte in Softwaresystemen versetzt den Entwickler in die Lage, sein Wissen und seine In­formationen zu Softwaresystemteilen direkt während der Implementierung am Quellcode fest­halten zu können. Darüber hinaus kann ein Entwickler nun seine Gedanken und Schlüsse zu einem bestehenden System quellcodenah bei der Analyse eines Systems in der Wartungsphase dokumentieren. Durch die Werkzeugunterstützung ist es möglich, die unterschiedlichen Infor­mationen und Dokumentationen miteinander zu vernetzen und so das einfachere Verständnis für das Softwaresystems durch andere Entwickler zu fördern. Bei der Dokumentation des Quellcodes und der Vernetzung der Dokumentationen entsteht eine abstrakte Dokumentati­onsebene, die das System beschreibt und den Bruch zwischen der gängigen Dokumentation ei­nes Softwaresystems und dem Quellcode aufhebt. Als Vorteil hat sich dabei die Gliederung der Dokumentation in Aspekte und Teilaspekte des Softwaresystems erwiesen, da so die Do­kumentation des Systems in gedanklich kapselbare Einheiten von Verhalten strukturiert wird. Die Realisierung besteht aus einem System, das das Wiki SnipSnap für die Dokumentation von Quellcode und Eclipse für die Integration des Werkzeugs in eine Entwicklungsumgebung miteinander verbindet. Dabei unterstützt das System die Verknüpfung von Quellcodeelemen­ten und strukturierten Dokumentationselementen sowie die Visualisierung der Verknüpfungen in der Entwicklungsumgebung.

Wie sich gezeigt hat, hängt eine bessere Dokumentation von Softwaresystemen nicht nur von der Realisierung möglicher Werkzeug ab, sondern erfordert die Berücksichtigung vieler Aspekte. Bevor in eine neue technische Lösung investiert wird, um die Arbeitsleistung zu er­höhen und zu verbessern, sollte das Arbeitsumfeld analysiert und bewertet werden. Nur so kann sichergestellt werden, dass die Rentabilität der Investition nicht durch ein schlechtes Ar­beitsumfeld gefährdet wird. Wenn das Umfeld den Entwickler stark bei seiner Tätigkeit be­hindert, kann allein durch ein neues Werkzeug keine Qualitäts- oder Produktivitätssteigerung erzielt werden.

In Zukunft werden integrierte Entwicklungsumgebungen eine immer stärkere Vernetzung un­terschiedlichster bisher getrennt agierender Prozesse miteinander ermöglichen. Der Ansatz von Juri Memmert [Mem02a], der die Vernetzung aller Entwicklungszyklen und deren Arte­fakte sowie die Verfolgung der Mutation der Artefakt vorsieht, geht diesen Weg noch konse­quenter, als es der Ansatz der quellcodegebundenen Dokumentation kann. Die vielen unterschiedlichen Produktteile eines Softwaresystems werden immer enger miteinander ver­woben, um den Informations- und Wissensgewinn der dabei entsteht, fur qualitativ hochwerti­gere und komplexere Softwareprodukte zu nutzen. Die unterschiedlichen Brüche, wie sie zwischen der Anforderungsbeschreibung, den Analysedokumenten, den Designdokumenten, der eigentlichen Dokumentation und der zentralen Realisierung des Systems d.h., der Imple­mentierung bestehen, müssen aufgehoben werden, um das Systemverständnis zu erleichtern und den steigenden Anforderungen gerecht zu werden.

Der nächste Entwicklungsschritt des Projektes myAspectMap, könnte im Rahmen eines Open- Source Projektes die Umsetzung der Verlinkung von beliebigen Quellcodeelementen sein. Denkbar ist auch, dass das Werkzeug um die Verfolgung und Aufzeichnung von Quellcode- browsing Sitzungen erweitert wird. Dazu könnte der Weg, den ein Entwickler durch den Code nimmt, aufgezeichnet und von ihm an beliebigen Stellen dokumentiert werden. Die so gewon­nenen Informationen könnten Aufschluss über die Herkunft von Erkenntnissen bei der Analy­se des Systems geben. Grundlegend erfordern alle Ansätze, die Quellcodes mit anderen Informationen vernetzen wollen, die Möglichkeit, einzelne Elemente des Quellcodes zu refe- renzieren. Wie die Arbeit darstellt, ist ein vielversprechender Ansatz die Speicherung von Quellcode im XML-Format. Die Realisierung der quellcodegebundenen Dokumentation für Aspekte in Softwaresystemen stellt dabei einen ersten Schritt dar, um die Möglichkeiten der Verbindung von Quellcode und Information eingehender zu erproben.

7 Anhang

7.1 Abbildungsverzeichnis

Abbildung 1: Begriffliche Einordnung des Reengineering

Abbildung 2: Qualitätsmerkmale nach ISO 9126

Abbildung 3: Wasserfallmodell

Abbildung 4: V-Modell

Abbildung 5: W-Modell

Abbildung 6: Spiralmodell

Abbildung 7 Rational Unified Process (RUP)

Abbildung 8: Maslowsche Bedürfnispyramide

Abbildung 9: Erweitertes Chef-Programmierer-Team

Abbildung 10: Weg zur quellcodegebundenen Dokumentation

Abbildung 11: Eclipse Architektur

Abbildung 12: Vergleich Klartext, AST und srcML [CMM02]

Abbildung 13: Vergleich

Abbildung 14: Prototypische Realisierung - Technische Ansicht

Abbildung 15: SnipSnap

Abbildung 16: SnipSnap Editoransicht

Abbildung 17: Verwendung eines Makros Codeansicht, Editoransicht, Normalansicht

Abbildung 18: Formularsnip und ein normaler Snip in der Normalansicht

Abbildung 19: Schnittstelle eines Formularmakros

Abbildung 20 :Formularmakro "docu_textbox" Formularansicht

Abbildung 21: Formularmakro "docu_textbox" Normalansicht

Abbildung 22 :Formularmakro "docu_textarea" Formularansicht

Abbildung 23: Formularmakro "docu_textarea" Normalansicht

Abbildung 24: Formularmakro "docu_text" Formularansicht

Abbildung 25: Formularmakro "docu_text" Normalansicht

Abbildung 26: Formularmakro "form_label" Formularansicht

Abbildung 27: Formularmakro "form_label" Normalansicht

Abbildung 28: Formularmakro "docu_macrowrapper" Formularansicht

Abbildung 29: Formularmakro "docu_macrowrapper" Normalansicht

Abbildung 30: Funktionsweise der Formularansicht

Abbildung 31: Quellcode Dokumentationsverbindung durch Codesnips und Snips

7.2 Begriffsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

• Universidad: Technical University of Berlin
• Calificación: gut
• Autor: Diplom Informatiker Peter Glöckner (Autor)
• Año de publicación: 2004
• Páginas: 127
• No. de catálogo: V120512
• ISBN (Ebook): 9783668110311
• ISBN (Libro): 9783668147874
• Idioma: Alemán
• Etiqueta: Werkzeugunterstützung, Erstellung, Dokumentation, Aspekte, Softwaresystemen