4.2 Vergleich/Bewertung: Schematext und FrontPage

Das Programm Schematext hat bei der Erstellung der Konzeption für die Dokumentation sehr geholfen. Mit dem Programm war es schnell und einfach möglich, Konzepte auf ihre Praxistauglichkeit zu überprüfen. So konnte durch Anpassen der entsprechenden Expanderfunktion zum Beispiel die Hintergrundfarbe schnell geändert werden. Dadurch ließ sich leicht eine geeignete Farbkombination für die Frames finden.
Für eine Anwendung der Werkzeugumgebung zur Dokumentation muß die Werkzeugumgebung einfach zu bedienen sein. Besonders die Eingabe der Informationen für die Dokumentation muß einfach sein. Dafür ist Schematext jedoch nur bedingt geeignet. Wie man im Kapitel 3.3.2 sieht, ist das Hinzufügen von Informationen arbeitsaufwendig. Die Änderung der Darstellung der Informationen, die unter Schematext einfach ist, ist bei dem Einsatz der Werkzeugumgebung nur noch selten notwendig, da das Konzept für die Dokumentation fertig ist. Deshalb stellt sich die Frage, ob ein anderes Programm Schematext nicht ersetzen kann. Denn die Werkzeugumgebung von Schematext benötigt nur die Funktionen für die automatische Generierung. FrontPage zusammen mit dem Software Developer's Kit kann diese Funktionen auch übernehmen.

4.2.1 Probleme bei der Nutzung von Schematext

Bei der Nutzung von Schematext als Werkzeug in der Werkzeugumgebung gibt es Probleme, weil das Programm keine OLE-Schnittstelle besitzt, über die ein externes Programm oder andere Werkzeuge Schematext steuern können. Aus diesem Grund treten Probleme

Wenn neue Daten von externen Quellen in die Dokumentation eingefügt werden sollen, muß ein Importfilter diese Daten in die SDL-Datei und in die entsprechende HTML-Datei im FrontPage-Verzeichnis schreiben. So sind vom Importfilter, zum Beispiel für das Einfügen einer neuen Klasse, mehrere Schritte durchzuführen:

Diese Schritte sind durch die Struktur der SDL-Datei zum Teil sehr aufwendig.
Da das Importieren der Daten nicht ausreicht, muß das Schema in Schematext weiter bearbeitet werden. Für eine komfortable Benutzerführung stellt Schematext keine Funktionen zur Verfügung. In vielen Fällen muß der Anwender eine Folge von Aktionen ausführen, z.B. eine Klasse anlegen, Methoden anlegen, Attribute anlegen und Links zwischen den Objekten erzeugen. Eine gute Benutzerführung fragt den Anwender nach Einfügen einer Klasse, ob er die zugehörigen Methoden und Attribute eingeben möchte. Dies ist mit Schematext nicht möglich. Auch das Vormerken von noch zu erledigenden Arbeiten unterstützt Schematext nicht. Da die Bearbeitung von einer Dokumentation komplex ist, wäre es für den Anwender vorteilhaft, wenn er diese Arbeiten in einer ToDo-Liste verwalten kann und von dort aus die Arbeiten beginnen kann.
Ebenfalls nachteilig für eine Benutzerführung ist, daß die Menüs und Fenster von Schematext fest vorgegeben sind. Da die Anpassung der Fenster an die Erfordernisse der Dokumentation nicht möglich ist, muß die Eingabe und das Verändern von zusätzlichen Daten (z.B. eine Versionsnummer) über Schemefunktionen im Expander Editor erfolgen. Dies erfordert jedoch mehr Kenntnisse bei dem Anwender als eine einfache Eingabe in einem angepaßten Fenster.
Problematisch sind auch die Zugriffsmöglichkeiten auf die Daten von anderen Knoten. In einigen Fällen ist es sinnvoll, wenn Schematext bei der Generierung einer HTML-Seite auf die Scheme-Funktionen von anderen Knoten zugreifen kann. Damit wäre es zum Beispiel möglich, unterschiedliche Bezeichner für Link zu verwenden. So besteht ein Link zu einem Entwurfsmuster immer aus dem kompletten Namen mit Typ und dem Kontext des Entwurfsmusters. In der schmalen Spalte des Inhaltsverzeichnisses kann man aber zum Teil auf den Typ verzichten. Eine zweite Schemefunktion, z.B. "name-kurz", kann den kürzeren Name zwar aufnehmen, aber bei der Generierung des Links kann Schematext nicht auf diese Funktion zugreifen.
Dieses Verhalten von Schematext vergrößert auch die Komplexität der Beziehungen im Struktur Editor. So sind aus diesem Grund mehrere Links von unterschiedlichen Unterknoten zum gleichen Ziel notwendig, siehe Abschnitt 3.3.1, da kein Zugriff auf die Links von dem Hauptknoten möglich ist.

4.2.2 FrontPage mit dem Software Developer's Kit

FrontPage besteht aus drei Teilprogrammen:

Der FrontPage Editor dient zum Bearbeiten von einzelnen HTML-Seiten, wie in Abschnitt 3.1.5 beschrieben. Der FrontPage Explorer hilft beim Bearbeiten und bei der Wartung eines HTML-Angebotes. Dieser Explorer zeigt den Zusammenhang zwischen den einzelnen HTML-Seiten an, indem das Programm die Links graphisch darstellt. Der Benutzer kann dann von hier aus den FrontPage Editor aufrufen. Zusätzlich bietet das Programm weitere Funktionen für die Verwaltung der HTML-Seiten, so kann man mit dem FrontPage Explorer die HTML-Seiten verschieben und das Programm korrigiert automatisch die Links zwischen den Seiten. Außerdem kann der FrontPage Explorer überprüfen, ob alle Links zwischen den HTML-Seiten korrekt sind. Die ToDo-List hilft bei der Verwaltung der anstehenden Arbeiten. So können von den beiden anderen Programmen direkt Einträge in diese Liste hinzugefügt werden. Dies ist zum Beispiel beim Erstellen einer neuen Seite sinnvoll. Von dieser Seite gehen eventuell Links zu noch nicht angelegten Seiten. Der FrontPage Editor legt dann diese Seite an und fügt die Seite in die ToDo-Liste ein, damit diese Seite später bearbeitet wird. Durch die Bearbeitung der Seite wird diese aus der ToDo-Liste gestrichen. Durch Anzeigen der ToDo-Liste erhält man so immer einen aktuellen Stand über die noch auszuführenden Arbeiten. Dies ist bei der Erstellung von HTML-Angeboten besonders wichtig, da diese nicht linear strukturiert sind.
Der Benutzer kann alle drei Programmteile über Schnittstellen anpassen [Microsoft]. Der FrontPage Software Developer's Kit beschreibt für diesen Zweck die Schnittstellen der Programme. Es stehen mehrere Möglichkeiten zur Verfügung:

Wesentliche Voraussetzung zur Erweiterung der Programme ist das Hinzufügen von neuen Menüpunkten, die das Erreichen der neuen Funktionen ermöglichen. Die neuen Menüpunkte dienen zum Starten von eigenen externen Programmen. Die Registry von Windows nimmt die Daten für die neuen Menüpunkte auf.
Einige Funktionen benötigen neue HTML-Tags. Ein weiteres Programm kann dann diese HTML-Tags zum Beispiel in einem anschließenden Übersetzungsschritt durch eigene Texte ersetzen. Da der FrontPage Editor ihm unbekannte HTML-Tags nur durch ein Zeichen darstellt, ist es für eine WYSIWYG-Darstellung notwendig, für neu eingeführte HTML-Tags entsprechende Ersetzungen zu definieren. Der FrontPage Editor kann bei der Darstellung auf dem Bildschirm diese Tags durch definierte HTML-Tags, Text und/oder Grafiken ersetzen.
Mit Templates und Wizards kann FrontPage neue Seiten interaktiv erstellen. Dabei gibt es Templates und Wizards für einzelne Seiten, die der FrontPage Editor benutzt, und auch Templates und Wizards für mehrere Seiten, die der FrontPage Explorer benutzt. Die Templates und Wizards definieren das Layout der Seite. Diese Seiten stehen dann zur weiteren Bearbeitung zur Verfügung und der Benutzer hat bei der Nutzung der Templates bzw. Wizards Arbeit gespart. Die Templates sind einfache Dateien, die den Aufbau der Seite beschreiben und auch mit FrontPage erstellt werden. Die Wizards sind eigenständige Programme, die FrontPage mit Parameter aufrufen. Der Wizard kann nicht nur ein Grundgerüst der Seite erstellen, sondern auch durch weitere Befehle die Bearbeitung der Seite unterstützen. Deshalb ist die Erstellung von neuen Seiten mit Wizards wesentlich flexibler, aber die Entwicklung eines neuen Wizard ist aufwendiger und eine Programmiersprache, wie Visual Basic oder C++, ist erforderlich.
Alle drei Programme besitzen eine OLE-Schnittstelle, mit der die Bearbeitung der Daten durchgeführt wird. So kann ein externes Programm über die OLE-Schnittstelle des FrontPage Editors eine Seite im Editor öffnen und dort Text hinzufügen. Ebenso kann die ToDo-Liste durch externe Kommandos verändert werden.

4.2.3 Erstellen der Dokumentation mit FrontPage

Damit das Erstellen einer Dokumentation nicht zu aufwendig ist, muß die Werkzeugumgebung Teile der HTML-Seiten selbst erstellen. Dies ist durch Programmierung eines Wizards für FrontPage möglich. Ein Wizard kann, wie Schematext, die Frames für den Kopf, das Inhaltsverzeichnis und die Navigationsleiste erstellen. Er muß jedoch einige Eingabedaten bekommen. So muß für den Kopf der Name das Objektes und für das Inhaltsverzeichnis die Beziehungen zu anderen Objekten bekannt sein. Diese Daten müssen in einer Datenbank zur Verfügung stehen oder direkt von der Entwicklungsumgebung kommen. Der Vorteil, den hier eine Datenbank bietet, ist hier noch größer als in Abschnitt 4.1.1. Denn eine SDL-Datei kann noch einige Daten aufnehmen, hier jedoch existiert keine Gelegenheit zum Ablegen der Daten.
Der Wizard kann für das Erstellen der HTML-Seiten die OLE-Funktionen des FrontPage Editors nutzen. Dazu muß der Wizard, wie die Scheme-Funktionen im Schematextexpander, die HTML-Befehle in die HTML-Datei schreiben. Unter Schematext ist für die Generierung des Kopf-Frames die Scheme-Funktion "Generate" zuständig:

(define (generate node) (html-header node) (emit "<table width=100%><tr><td width=20%>" nl) (emit-anchor-top to-home-link) (if (and to-toc-link (not (included? node))) (begin (emit (std-img icon-void) nl) (emit-anchor-top to-toc-link))) (if (and to-index-link (not (included? node))) (begin (emit (std-img icon-void) nl) (emit-anchor-top to-index-link))) (emit "</td><td width=60%>" nl) (title node) (emit "</td><td width=20%></td></tr></table>" nl))

Diese Funktion kann einfach nach C/C++ portiert werden. Dazu müssen die folgenden Umwandlungen vorgenommen werden:

Scheme

 C/C++
die Funktionsaufrufe wie
(html-header node)

 		in Funktionsaufrufe, z.B.
html_header(node)
die Ausgabefunktion "emit", wie
(emit "</td><td width=60%>" nl)

 		durch OLE-Funktionen vom FrontPage Editor
vtiInsertHTML
("</td><td width=60%>\n");
die Abfragefunktionen, wie
to-home-link

 		durch Variablen oder Datenbankabfragen
die if-Funktion, wie
(if (and to-index-link ...)))
(begin (emit ...)
(emit-anchor-top ...)))

 		durch die if-Funktion, z.B.
if (to_index_link and ...)
{ vtiInsertHTML(...);
emit_anchor_top(...);
};
die Ausgabefunktion "emit-contents", wie
(emit-content node)

 		durch Aufruf des Frontpage Editors
vtiOpenWebPage( ... );

Der Wizard kann dann das Layout der HTML-Seite genauso erzeugen, wie es Schematext kann. Dabei ist die Reihenfolge umgekehrt. Der Wizard erzeugt zuerst das Layout als Grundgerüst und dann kann der Benutzer den zusätzlichen Text eingeben. Bei Schematext gibt der Benutzer zuerst den Text ein und dann erzeugt Schematext die komplette HTML-Seite. Durch diese Reihenfolge bestehen bei der FrontPage-Lösung schon alle HTML-Seiten, wenn der Anwender die Texte editiert. Der Anwender kann deshalb beim Eingeben von Links die komfortablen Eingabefenster von FrontPage benutzen und muß nicht die Zahlen für die Links aus Schematext heraussuchen.
Zur Unterstützung des Anwenders sind Eintragungen durch den Wizard in der ToDo-Liste möglich. So kann der Wizard alle zu bearbeitenden Seiten in diese Liste eintragen, so daß der Anwender immer über die notwendigen Arbeiten informiert ist. Bei der Eingabe der Texte kann der Anwender auch unterstützt werden, da hier die FrontPage Menüs angepaßt werden können.
Schwierigkeiten treten bei Änderungen der Software in der Entwicklungsumgebung auf. Der Wizard kann nicht direkt aus den neuen Daten die Seiten erzeugen. Denn der Anwender hat eventuell schon zusätzliche Texte in den Seiten eingegeben. Diese Texte darf der Wizard nicht überschreiben. Wenn die Daten fest vorgegebene Abschnitte betreffen, wie z.B. Linklisten, ist dies meist kein Problem. Der Anwender hat an diesen Stellen keine Änderungen vorgenommen. Der Wizard muß also nur den Abschnitt ersetzen. Um die richtigen Stellen zu finden, sind eventuell zusätzliche Marken erforderlich. Diese Marken können HTML-Kommentare sein.
Schwieriger ist es, wenn die Änderungen Bestandteil des Textes sind. Da der Wizard hier nicht zwischen den Eingaben des Anwenders und den automatisch erzeugten Texten unterscheiden kann, muß der Wizard diese notwendigen Änderungen dem Anwender überlassen. Der Wizard kann aber die notwendigen Tätigkeiten in die ToDo-Liste eintragen. Eine andere Lösung für dieses ist es, die Eingaben von FrontPage auch in die Datenbank zu übernehmen und dann aus der Datenbank die HTML-Seiten zu generieren. Hierzu muß jedoch auch ein Programm zur Übernahme der Daten in die Datenbank geschrieben werden, das die in FrontPage geschriebenen Texte extrahiert.

4.2.4 Vergleich der beiden Lösungsansätze

Bei der Benutzerführung ist die Lösung mit einem Wizard für FrontPage besser als die Lösung mit Schematext. So entfällt das umständliche Wechseln zwischen den Programmen Schematext und FrontPage Editor. Auch die Eingabe von Links aus dem Text ist unter FrontPage wesentlich einfacher.
Es ist auch kein Auftrennen der Seite in kleinere Abschnitte notwendig, wodurch die Eingabe überschaubarer wird. Allerdings muß bei einer Lösung mit FrontPage vom Anwender erwartet werden, daß er Teile der Seite nicht verändert. So darf er nicht die Linkziele für die Abschnittsüberschriften löschen. Denn sonst fehlen diese Linkziele später in dem fertigen Produkt und der Browser findet dann die Linkziele nicht und gibt Fehlermeldungen aus. Ein Schutz dieser Textteile ist in FrontPage leider nicht möglich.
Auch bei der Gestaltung der Seiten ist eine Lösung mit einem FrontPage Wizard einer Lösung mit Schematext überlegen. Durch die eigene Programmierung bestehen bedeutend mehr Gestaltungsmöglichkeiten als mit Schematext. Der Schema Expander dient zwar auch der Programmierung, jedoch sind bei ihm einige Einschränkungen vorhanden. An einigen Stellen sind nicht alle benötigen Daten zu ermitteln, da kein Zugriff auf externe Funktionen anderer Objekte möglich ist (siehe Abschnitt 4.2.1).
Für den Einsatz von Schematext spricht der Aufwand bei der Programmierung. Hier sind nur ein Programm für das Einfügen der Daten in die SDL-Datei notwendig, dabei können einige Programmteile aus den Filtern aus Abschnitt 3.3.3 wiederverwendet werden, so daß der Aufwand wahrscheinlich nicht so groß ist. Bei der Lösung mit dem Wizard für FrontPage muß der Wizard neu geschrieben werden. Dort sind neben einem Importprogramm auch Programme für das Erstellen der Seiten erforderlich. Da diese Seiten für die unterschiedlichen Objektarten, wie Klassendiagramme, Klassen und Methoden, ein unterschiedliches Layout besitzen, muß für jedes dieser Objekte eine eigene Funktion geschrieben werden (In Schematext ändert sich bei unterschiedlichen Objekten nur der Knotentypidentifikationsnummer.). Obwohl dabei schon die Vorgaben aus dem Schematext Expander vorhanden sind, ist der Arbeitsaufwand dafür groß.
Ein weiterer Vorteil von Schematext ist die Möglichkeit, mehrere Varianten der Dokumentation zu erzeugen. Damit das Know-How der Entwicklungsfirma geschützt bleibt, dürfen die Kunden nicht alle Details des Entwurfs erfahren. So wird von dem Beispiel OSEFA im Internet eine Version veröffentlicht. Damit nicht alle die Details der Implementierung erfahren, fehlt bei dieser Dokumentation die Beschreibung der Klassen. Für den internen Gebrauch an der FH-Konstanz ist die Dokumentation komplett für eine Weiterentwicklung vorhanden. Schematext hat beide Varianten aus dem gleichen Datenbestand erstellt. Die Auswahl der Variante erfolgt einfach über eine Funktion im Schema Expander. Bei der Lösung mit FrontPage ist das Generieren von zwei Varianten nicht so einfach, da der Wizard das Grundgerüst der Dokumentation schon vor der Eingabe erstellt. Somit müssen die Eingaben für die zwei Varianten zweimal vorgenommen werden.
Für die Weiterentwicklung der Werkzeugumgebung ist meiner Meinung nach ein Wechsel auf eine Lösung mit FrontPage vorzunehmen. Denn mit Schematext sind die Probleme bei der Benutzerführung zu groß, so daß keine annehmbare Lösung erreichbar ist. Die Probleme mit einem FrontPage Wizard sind lösbar, auch wenn der Arbeitsaufwand für die Lösung groß ist.





© Technische Informatik