Die implementierte Werkzeugumgebung entspricht in einigen Teilen
nicht der Konzeption. Um das Konzept vollständig zu verwirklichen,
sind umfangreiche Java oder Javascript Programme erforderlich.
Java bzw. Javascript sind auch bei einer verbesserten Versions-
und Konfigurationsverwaltung hilfreich.
In einigen Fällen sind in der Dokumentation
Links zu Seiten mit einem anderen Kontext notwendig. So zeigen
zum Beispiel die Frames, die eine Klasse umgeben, das Entwurfsmuster
an, dem diese Klasse angehört, vgl. Abschnitt 3.2.2. Wechselt
nun der Leser zu einer anderen Klasse, gehört die Klasse
nicht mehr dem Entwurfsmuster an und der Kontext hat sich verändert.
Die umliegenden Frames, die diesen Kontext anzeigen, sollten deshalb
einen neuen Inhalt bekommen oder gelöscht werden. Der Fall,
daß der Kontext wechselt, kommt auch in anderen Fällen
vor. Zum Beispiel existieren in dem Framework OSEFA zwei Abschnitte,
einer für die Konfiguration des Frameworks und ein anderer
Abschnitt, der das Design beschreibt. In beiden kommen unterschiedliche
Betrachtungen der Hot Spots des Framework vor, so daß hier
Linkbeziehungen sein sollten. Da aber der äußere Frame
anzeigt, ob man sich in der Konfiguration bzw. im Design befindet,
ist dies nicht möglich. In diesem Abschnitt zeige ich die
Lösung. Dabei verwende ich als Beispiel eine Klasse, deren
Kontext ein Entwurfsmuster ist. In den anderen Fällen ist
die Lösung gleich.
Um diese Funktionen zu verwirklichen, ist ein Java oder Javascript
Programm notwendig. Für das Programm sind Daten über
Diese Daten können in Schematext in Expanderfunktionen
gespeichert sein und so bei der automatischen Generierung
zur Verfügung stehen. Zu beachten ist, daß eine Seite
mehrere erlaubte Kontexte hat, weil z.B. eine Klasse Teil von
mehreren Entwurfsmustern ist. Aus diesen Daten erstellt Schematext
dann ein Programm, das den in Abbildung 29 dargestellten Ablauf
hat.
Für das Ermitteln des Kontexts (1) sind Funktionen zu nutzen,
die den umliegenden Frame zurückgeben. Der 2. Schritt, die
Abfrage, kann mit dem Namen des in 1 ermittelten Frames und den
Daten über die erlaubten Kontexte überprüfen, ob
der Kontext richtig ist. Ist der Kontext richtig, kann der Browser
die Seite einfach aufbauen (3). Ist der Kontext falsch, dann muß
der Browser zuerst die umgebenen Frames aufbauen (4). Da dieser
Vorgang die Informationen über die aktuelle Seite löscht,
muß eine zusätzliche Variable den Namen der Seite aufnehmen.
Der Browser muß dann statt des Inhaltsframe die gewünschte
Seite aufbauen. Dies ist durch Ändern des Links mit Java-
/ Javascriptbefehlen möglich.
Wie im Abschnitt 2.2.2 dargestellt, ist das Verwalten unterschiedlicher
Versionen und Konfigurationen sehr aufwendig. In der bestehenden
Werkzeugumgebung können deshalb die einzelnen Objekte, wie
die Klasse oder die Diagramme, zwar Versionen haben, jedoch sind
die einzelnen Versionen nicht zu einer Konfiguration zusammengefaßt.
Das Verwalten von unterschiedlichen Konfigurationen ist nur mit
zusätzlichem Programmieraufwand zu erreichen.
Abbildung 30: Navigieren in
unterschiedlichen Konfigurationen
Das Fehlen der Konfigurationen führt zu den in Abbildung
30 gezeigten Problemen. Die Abbildung zeigt drei unterschiedliche
Komponenten, z.B. Klassen. Von der ersten und der dritten Komponente
existieren jeweils 2 Versionen (Version A und B von der ersten
Komponente und Version D und E von der dritten Komponente). Von
der zweiten Komponente existiert nur eine Version (Version C).
Aus den unterschiedlichen Versionen sind nun zwei Konfigurationen
(Konfiguration 1 besteht aus Version A, C und D und Konfiguration
2 aus Version B, C und E) erstellt worden und das Zusammenspiel
der einzelnen Komponenten innerhalb einer Konfiguration soll dokumentiert
werden. Deshalb sollte das Ziel für eine Dokumentation sein,
daß beim Bewegen in der Dokumentation der Leser immer in
der gleichen Konfiguration bleibt, denn die Versionen aus unterschiedlichen
Konfigurationen sind nicht immer kompatibel und das kann zu Mißverständnissen
führen.
Daß der Leser immer in der gleichen Konfiguration bleibt,
ist nur schwer zu gewährleisten. Benutzt der Leser einem
Link aus der Navigationsleiste um von Komponente 1 Version A zu
Komponente 2 zu kommen, so ergeben sich noch keine Widersprüche,
da hier nur eine Version existiert. Will der Leser von dort aus
weiter zu der Komponente 3, so muß er zu der Version D gelangen,
wenn er in der gleichen Konfiguration bleiben will. Da aber von
der Komponente 2 nur eine Version vorhanden ist, ist der Ausgangspunkt
der Navigation nicht mehr zu bestimmen. Der Leser könnte
auch von der Version B der Komponente 1 kommen und dann müßte
er zu der Version E der Komponente 3 gelangen. Die Links in der
Version C der Komponente 2 hängen also von der Konfiguration
ab.
Abbildung 31: Trennen der Konfigurationen
für die Navigation
Eine einfache Lösung dieses Problems ist in Abbildung 31
dargestellt. Die Version C der Komponente 2 existiert in den Versionen
C1 und C2 zweimal. Der Inhalt der Versionen C1 und C2 ist identisch,
nur die Links, die von diesen Versionen ausgehen, sind unterschiedlich.
Diese einfache Lösung hat den Nachteil, daß der Speicherplatzbedarf
für die Dokumentation stark zunimmt. Denn in einigen Fällen
unterscheiden sich die Konfigurationen nur in einigen Komponenten,
weil zum Beispiel bei einer Fehlerbeseitigung nur ein oder zwei
Klassen betroffen sind oder weil für unterschiedliche Betriebsysteme
Konfigurationen existieren, die sich auch nur in wenigen Schnittstellenklassen
unterscheiden. In diesen Fällen sind dann aber alle anderen
Objekte zu verdoppeln.
Abbildung 32: Links zu Komponenten
statt zu Versionen
Besser ist es, wenn die Auswahl der Version die Komponente selbst
trifft, siehe Abbildung 32. Die Links gehen zu der Komponente
und die Komponente sucht anhand der aktuellen Konfiguration die
gewünschte Version aus. Da Links keine Parameter zulassen,
ist eine globale Variable zur Speicherung der aktuellen Konfiguration
notwendig. Durch ein Java- oder Javascriptprogramm kann die HTML-Seite
dann die zur Konfiguration gehörige Version auswählen
und der Browser stellt die Informationen dar.
Abbildung 33: Frames, die sich
mit der Version ändern
Das Java- bzw. Javascriptprogramm, das die Abbildung von der Konfiguration
auf die Version vornimmt, kann in der HTML-Seite sein, die die
Frameaufteilung vornimmt und das Linkziel der anderen HTML-Seiten
ist. Das Programm dort braucht aber nicht sofort die Inhalte der
einzelnen Frames auszusuchen. Wie man in Abbildung 33 sieht, sind
nicht alle Frames von der Version abhängig. Nur die mit dicken
Rahmen markierten Frames hängen von der Version ab. So enthält
der Kopf immer die gleichen Daten, wie den Namen und den Typ des
Objektes. Auch die Aufteilung der Frames ist immer gleich, so
daß sich auch die HTML-Seiten mit den Framedefinitionen
nicht ändern. In den anderen Frames kommen jedoch Änderungen
vor. Die Navigationsleiste einer Klasse ändert sich zum Beispiel,
wenn die Klasse bei der Änderung der Struktur Teil eines
Musters wird.
Damit das Datenaufkommen nicht zu groß wird, ist es von
Vorteil, wenn die Frames, die auch bei unterschiedlichen Versionen
den gleichen Inhalt haben, nur einmal vorhanden sind. Bei den
anderen Frames kann die Auswahl der anzuzeigenden Information
durch einen Austausch der Linkziele in den Framedefinitionen erfolgen,
d.h. ein Programm hängt zum Beispiel an den Namen des Linkziels
die Versionsnummer an und für jeden Frame existieren mehrere
Dateien, die sich durch die Versionsnummer unterscheiden. Die
Informationen in den Dateien entsprechen natürlich dann der
Versionsnummer.
Das Datenaufkommen kann aber noch weiter reduziert werden, wobei
der Aufwand für die Erstellung der Dokumentation wahrscheinlich
beträchtlich steigt. Die Reduzierung ist möglich, wenn
die Anpassung an die Version nicht durch Austausch der Datei sondern
in der Datei selbst erfolgt. In vielen Fällen sind die Änderungen
zwischen den Inhalten der Frames für unterschiedliche Versionen
nur gering. So kann in der Navigationsleiste oder im Verzeichnis
ein Link hinzukommen. Dafür eine neue Datei anzulegen ist
nicht sehr speicherplatzeffizient. In diesen Fällen kann
die Anpassung direkt in der HTML-Datei für den Frame erfolgen,
indem ein Programm den Link in Abhängigkeit zur Version einfach
ein- oder ausblendet.
Bei der hier aufgezeigten Lösung besteht jedoch das Problem,
daß ein Wechsel zu einer anderen Version einer Komponente
nicht möglich ist. Ein Leser sollte dies aber können,
da so die Entwicklung nachvollziehbar ist. Mit einer zweiten Variable
ist dieses Problem lösbar. Diese Variable nimmt bei einem
Link zu einer anderen Version die Versionsnummer auf. In den anderen
Fällen ist sie leer. Das Java- bzw. Javascriptprogramm kann
nun mit dieser Variable entscheiden, ob eine bestimmte Version
gewählt wurde oder die Auswahl der Version über die
Konfiguration erfolgt.
Durch die Nutzung einer Programmiersprache entstehen einige Möglichkeiten
bei der Seitengestaltung, die mit reinem HTML nicht machbar sind,
zum Beispiel
In dem Konzept habe ich vorgeschlagen, daß die Rücksprünge
in der Navigationsleiste sich immer auf die Ebene beziehen, in
der sie sich befinden, d.h. bei Betätigen des Rückknopfes
in der Systemebene bekommt der Leser die vorherige Seite auf der
Systemebene dargestellt. Um dies zu realisieren, sind ebenfalls
Programme notwendig. Zu jeder Ebene muß eine Liste verwaltet
werden, die die zuletzt angezeigten Seiten der Ebene aufnimmt.
Bei dem Aufbau einer Seite trägt sich diese Seite in die
Liste ein. Bei dem Betätigen des Rückknopfes ist nun
die letzte Seite aus der Liste zu erfragen und der Browser stellt
diese Seite dar. Zusätzlich ist diese Seite aus der Liste
zu löschen.
In einigen Fällen reichen einfache Links in der Navigationsleiste
nicht aus, um dem Leser alle sinnvollen Ziele anzubieten. So ist
gegenwärtig die Navigation über die Versionen eines
Objektes nur linear, obwohl bei der Entwicklung auch Versionsbäume
entstehen. Mit einer Programmiersprache können nun Auswahlfelder
zu den Links hinzukommen. Die alten Links ermöglichen dann
eine Navigation über die Revisionen des Objektes und über
das Auswahlfeld sind auch alle anderen Versionen erreichbar. Genauso
kann auch ein Auswahlfeld die Auswahl der Konfiguration ermöglichen,
siehe Abschnitt 4.3.2. Auch ist ein Zusammenfassen der Links durch
die Klassen eines Entwurfsmusters möglich. Wenn eine Klasse
in mehreren Entwurfsmustern enthalten ist, so können nicht
alle die Links zu den anderen Klassen der Entwurfsmuster in die
Navigationsleiste, da dort der Platz begrenzt ist. In diesem Fall
kann auch ein Auswahlmenüs helfen. In dem Menü wählt
der Leser das Entwurfsmuster aus, zu dessen Klassen er gelangen
will. Mit den Navigationspfeilen daneben wechselt er dann zu den
gewünschten Klassen. In diesem Fall ist immer nur ein Entwurfsmuster
in der Navigationsleiste enthalten und so wird erheblich Platz
eingespart.