In diesem Kapitel zeige ich die für die Implementierung notwendigen Arbeiten. Zusätzlich wird auch das Zusammenspiel der einzelnen Werkzeuge in der implementierten Werkzeugumgebung dargestellt. Der erste Abschnitt zeigt die Konfiguration von Schematext für die Werkzeugumgebung. Danach folgt eine Darstellung des Datenflusses zwischen den einzelnen Werkzeugen in der Werkzeugumgebung. Daran schließen sich zwei Abschnitte an, die sich mit zwei Arbeitsschritten beschäftigen. Dies ist zum einen das Konvertieren der Daten von Schematext nach FrontPage und umgekehrt und zum anderen das automatische Einfügen von Links mit dem Programm SED. Es folgt ein Beschreibung der Arbeiten für das Einfügen von Diagrammen und zuletzt zeige ich an einem Beispiel die Arbeiten, die auszuführen sind, um neue Daten in die Dokumentation aufzunehmen.
Ausgangspunkt für die Arbeit mit der Werkzeugumgebung ist das Programm Schematext. Hier wird das Aussehen aller Objekte definiert. Für alle Arten von Beschreibungen wurden Knotentypen eingeführt. Es existieren Knotentypen für die Klassendiagramme, die Hot Spots, Entwurfsmuster, Klassen usw., siehe Abbildung 23. Für alle diese Knotentypen wurde die Bildschirmaufteilung entsprechend den Vorgaben aus Kapitel 2.2.2 mit Hilfe von Frames realisiert. Dafür sind Unterknotentypen eingeführt worden, die jeweils den Inhalt eines Frames beschreiben. Die Unterknotentypen für Bildschirmteile Kopf, Inhaltsverzeichnis und Navigation wurden so konfiguriert, daß Schematext diese Frames weitgehend automatisch generiert.
Beim Bildschirmteil, der die Informationen aufnehmen soll, wurden die einzelnen Unterknotentypen zusätzlich um weitere Unterknotentypen ergänzt, um die Texte weiter zu gliedern. So existieren bei den Entwurfsmustern die Unterknotentypen Intent, Motivation, Applicability, Structure, Participants, Consequences, Implementation und Related Pattern. Bei den Entwurfsmustern entspricht die Einteilung weitgehend der Einteilung der Entwurfsmuster in [Gamma et. al., 1995].
Zusammen mit den Knotentypen wurden auch die Linktypen erstellt und deren Aussehen festgelegt. Die Beziehungen zwischen den Knotentypen, die die Linktypen ausdrücken , sind sehr komplex. Denn in den meisten Fällen gehen die Links für eine Beziehung zwischen zwei Objekten nicht nur von einem Frame aus, sondern von mehreren Frames, z.B. vom Verzeichnis- und vom Inhaltsframe gehen Links zu dem gleichen Objekt. Für alle Links aus unterschiedlichen Frames muß trotz des gleichen Ziels ein eigener Linktyp definiert werden.
Damit Schematext die Navigationsleiste automatisch generieren kann wurden weitere Linktypen notwendig. Die meisten der schon vorhandenen Linktypen konnten nicht verwendet werden, da diese von einem Frame ausgehen. Damit aber die Seite bei Nutzung eines Links in der Navigationsleiste richtig aufgebaut werden kann, muß der Linktyp vom Hauptknotentyp ausgehen. Deshalb ist noch ein Linktyp von dem Hauptknotentyp zu den Objekten notwendig.
Für die automatische Generierung der Navigationsleiste wurden zusätzlich einige Linktypen doppelt ausgeführt. Bei einem Linktyp wird auch ein Link in der Navigationsleiste eingefügt, bei dem anderen Linktyp wird kein weiterer Linktyp hinzugefügt.
Abbildung 23: Schema der Dokumentation (Ausschnitt)
Da in der Navigationsleiste wenig Platz ist, werden einige HTML-Seiten linear verbunden, z.B. alle Klassen in einem Entwurfsmuster oder alle Entwurfsmuster. Das heißt, der Leser kommt nur zu der vorherigen oder der nachfolgenden Seite einer Liste und kann sich von dort weiter nach vorne bzw. hinten bewegen, um alle Seiten der Liste zu erreichen. Die Links zu diesen Seiten werden als Pfeile dargestellt. Diese Pfeile werden von Schematext automatisch generiert. Dazu benötigt Schematext jedoch einen Knoten von dem Links zu jedem Element der Liste ausgehen, damit Schematext die Elemente der Liste kennt. Bei einigen dieser Listen, z.B. den Klassen eines Entwurfsmusters, können vorhandene Knoten, hier das Entwurfsmuster, genutzt werden. Bei anderen Listen, z.B. der Liste aller Entwurfsmuster, ist ein neuer Knoten notwendig. Dabei wurde der dazugehörige Knotentyp so angelegt, daß die daraus von Schematext erstellte HTML-Seite nicht sichtbar wird, da diese Seite keinen Inhalt hat.
Für die Versionierung wurden ebenfalls solche Knotentypen angelegt. Damit läßt sich allerdings nur eine lineare Liste aufbauen. Somit ist auch kein Versionsbaum möglich, was für das Beispiel der Nachdokumentation von OSEFA nicht erforderlich ist, sondern nur eine Liste von aufeinander folgenden Versionen. In dem Abschnitt 4.3.3 ist eine Lösung für einen Versionsbaum vorhanden.
3.3.2 Der Datenfluß in der Werkzeugumgebung
Der Datenaustausch zwischen den einzelnen Programmen in der Werkzeugumgebung erfolgt über Dateien. Dies ist nötig, weil keine direkte Anbindung von FrontPage an Schematext existiert. Da keine OLE-Server-Schnittstelle für Schematext existiert und keine Informationen über die OLE-Client-Schnittstelle von Schematext zu erhalten war, war es nicht möglich, selbst eine komfortablere Anbindung über die OLE-Schnittstelle zu entwickeln.
Für das Einfügen von neuen Daten in die Dokumentation ist es notwendig, daß in Schematext neue Knoten erzeugt werden. Der Knotentyp entspricht dem Typ des beschriebenen Objekts. Danach werden neue Links erzeugt. Diese Links gehen von dem Verzeichnis in die Unterknoten des Inhalts. Mit diesen Links werden alle Abschnitte des Textes im Verzeichnis aufgeführt. Weiterhin muß ein Link von dem Unterknoten Navigation zu dem Hauptknoten erzeugt werden, damit Schematext die Navigationsleiste erzeugen kann.
Nun folgt die Erzeugung von den Links zwischen den einzelnen Objekten. Der erzeugte Knoten steht in Beziehung mit anderen Objekten. Diese Beziehungen sollen als Links im erzeugten HTML-Dokument erscheinen. Deshalb müssen diese in Schematext als Links eingegeben werden. Dazu werden die vordefinierten Linktypen verwendet. Auch die Links, die später in die Texte eingefügt werden sollen, werden erzeugt.
Danach erfolgt die Konvertierung der Daten nach HTML für FrontPage. Dafür wird das Schema in Schematext gespeichert und dann der Filter für den Export benutzt, siehe Abbildung 24. Dieser erzeugt für alle neuen Unterknoten eine HTML-Datei. Diese Dateien werden in einem Unterverzeichnis des Verzeichnisses von FrontPage erzeugt. Der Filter wird in Kapitel 3.3.3 beschrieben.
Abbildung 24: Der Datenfluß in der Werkzeugumgebung
Die neuen HTML-Dateien können nun mit dem FrontPage Editor bearbeitet werden. Der Filter hat für alle Unterknoten eine Datei erstellt. Es müssen aber nur die Dateien bearbeitet werden, die für den Frame Inhalt zuständig sind. Diese Dateien stehen, wenn der Text nicht in kleinere Abschnitte unterteilt ist, im Verzeichnis "<Knotentypname>_Inhalt<...>". Wenn der Text in kleinere Abschnitt unterteilt ist, wie bei den Entwurfsmustern mit Intent, Motivation usw., so stehen die Dateien in den Verzeichnissen "<Knotentypname>_<Abschnittname><...>".
Bei der Eingabe von Texten in FrontPage können auch Links zu anderen Seiten der Dokumentation erzeugt werden. Es muß jedoch ein spezielles Format für den Linknamen eingehalten werden, da die Namen der Zieldateien erst nach dem Kompilieren mit Schematext bekannt sind. Damit diese Links von anderen Links, die nach Zielen außerhalb der Dokumentation verweisen, unterscheidbar sind, werden zwei spezielle Protokolle eingeführt. Während ein Link mit dem Protokoll "gi:" einen Link aus der von Schematext generierten Linkliste entfernt und ihn an die neue Stelle einfügt, wird bei einem Link mit dem Protokoll "ci:" eine Kopie des Links aus der Linkliste erzeugt. Statt an das Protokoll nun die Domain und den Pfad der Datei anzuhängen, wird an das Protokoll nun die Linknummer aus Schematext angehängt. Die Linknummer wird in Schematext im Menü "Eigenschaften" des Links angezeigt. Sie besteht aus den Buchstaben "li", einem Bindestrich und einer Zahl. Ein Vollständiger Linkname kann zum Beispiel "gi:li-488" sein.
Der Filter für den Import schreibt die Eingaben zurück in die SDL-Datei von Schematext. Dafür stehen zwei Wege zur Verfügung. Bei einem Weg werden zusätzlich zur Konvertierung auch Querverweise ins Glossar eingefügt. Da das Einfügen von Querverweisen sehr lange dauert und gleichzeitig zu Problemen führt (siehe Abschnitt 3.3.4), gibt es auch die Möglichkeit diesen Ersetzungsvorgang auszulassen. Mit dem so erzeugten Text können dann schnell Änderungen überprüft werden.
Da die Möglichkeiten des Schematext Editors sehr begrenzt sind, wurde eine Möglichkeit gesucht, die das Editieren von Inhalten mit FrontPage ermöglicht. Durch die Kombination von Schematext und FrontPage hat man einerseits einen komfortablen HTML-Editor und anderseits kann Schematext viele Teile automatisch generieren. Da der FrontPage Editor nur HTML-Dateien lesen kann, wurde es nötig, die SDL-Datei in mehrere HTML-Dateien zu konvertieren.
Abbildung 25: Gewünschte Dateienanordnung
Da aus einer Datei mehrere Dateien erstellt werden müssen stellt sich zuerst die Frage, wo diese Dateien gespeichert werden sollen und wie diese Dateien heißen sollen. Damit die Dateien leicht gefunden werden können, habe ich ein eigenes Verzeichnis "FrontPage" für diese Dateien angelegt. Da jedoch sehr viele Dateien entstehen, ist es nötig weitere Unterverzeichnisse anzulegen. Zuerst war geplant, daß für jeden Knotentyp ein eigenes Verzeichnis erstellt wird und in diesem Verzeichnis für alle Unterknotentypen weitere Unterverzeichnisse erstellt werden. In diesen Unterverzeichnisse sollten dann die Dateien abgespeichert werden, so daß sich die in Abbildung 25 dargestellte baumartige Verzeichnisstruktur ergeben hätte. Die Strukturierung nach Unterknotentypen ist sinnvoll, weil einige Unterknotentypen nur für die Generierung notwendig sind und in die Unterknoten keine Daten eingegeben werden müssen. Damit sind alle Dateien zusammengefaßt, die die Texte aufnehmen.
Mit dieser Verzeichnisstruktur ist jedoch das Einfügen von Grafiken schlecht möglich. Die Grafiken, die bei der Bearbeitung mit FrontPage in die HTML-Dateien eingefügt werden, müssen auch für die von Schematext erstellten HTML-Dateien zugreifbar sein. FrontPage fügt beim Einfügen von Grafiken die relativen Adressen der Grafiken in die HTML-Datei ein. Damit ist es nicht möglich, daß die Grafiken für die Bearbeitung mit FrontPage und die Grafiken in der fertigen Version der Dokumentation in einem Verzeichnis liegen. Deshalb müssen die Grafiken vom FrontPage-Verzeichnis zu dem Schematextverzeichnis kopiert werden. Damit das Kopieren der Grafiken von dem FrontPage-Verzeichnis zu dem Schematextverzeichnis einfach ist, müssen sich alle Grafiken in einem Unterverzeichnis befinden. Eine Kopie dieses Unterverzeichnisses muß dann so erstellt werden, daß die Bilder in dem kopierten Unterverzeichnis von der fertigen Dokumentation über den gleichen relativen Pfad erreichbar sind, wie die Originalbilder von FrontPage aus. Ansonsten müßten die Filterprogramme zusätzlich alle Pfadangaben für Bilder abändern, was einen großen Aufwand verursacht.
Abbildung 26: Implementierte Dateienanordnung
Schematext generiert aber gegenüber der gewünschten Verzeichnisstruktur eine Verzeichnisebene weniger. Es wird jeweils ein Verzeichnis für alle Knotentypen erstellt. In diesem Verzeichnis werden die HTML-Dateien der Knoten und der Unterknoten dieses Typs erzeugt. Aus diesem Grund wurde die Verzeichnisstruktur des FrontPage-Verzeichnis abgeändert. Es wird nur noch eine Verzeichnisebene erzeugt. Damit die einzelnen Unterknoten besser zu unterscheiden sind, wird für jeden Unterknotentyp ein Verzeichnis erstellt. Der Name dieses Verzeichnis besteht dann aus einer Aneinanderreihung des Knotentypnamens und des Unterknotentypnames. Diese Verzeichnisstruktur (siehe Abbildung 26) hat nur den Nachteil, daß das Verzeichnis FrontPage sehr viele Unterverzeichnisse besitzt, so daß das Auffinden der gewünschten Datei etwas erschwert wird.
Bei der Namengebung für die Verzeichnisse und für die Dateien muß etwas vom Knotennamen abgewichen werden. Da Schematext es ermöglicht gleiche Namen für unterschiedliche Knoten bzw. Knotentypen zu verwenden, dies aber auf Dateiebene nicht möglich ist, muß der Dateiname mit einer eindeutigen Kennung versehen werden. Dazu wird die Identifikationsnummer des Knotens bzw. Knotentyps verwendet. Diese Identifikationsnummer wird einfach an den Namen angehangen. Weil es noch weitere Beschränkungen bei der Verwendung von Dateinamen gibt, werden einige Zeichen, wie die Umlaute und Sonderzeichen, aus dem Dateinamen entfernt. Außerdem wird die Länge der Dateinamen begrenzt.
Damit diese Verzeichnisstruktur mit den HTML-Dateien erstellt werden kann, ist es nötig,
zu kennen.
Diese Informationen sind in der SDL-Datei enthalten. Die SDL-Datei ist eine reine Textdatei, die allerdings strukturiert ist. Jedes Objekt aus dem Schema hat einen eigenen Abschnitt in der SDL-Datei. Dieser Abschnitt beginnt mit einem "<" und einem Bezeichner für den Typ des Objektes. Danach folgen einige Informationen über das Objekt, wie zum Beispiel der Name, die Position auf dem Bildschirm usw. Diese Informationen werden mit einem Bezeichner eingeleitet und nach einem Gleichheitszeichen steht dann der Text. Dieser Text steht zum Teil in Anführungszeichen.
Nach diesen Informationen folgt ein ">"-Zeichen. Nun folgen die enthaltenen Objekte, z.B. die Unterknotentypen eines Knotentyps, die jeweils wieder einen eigenen Abschnitt besitzen. Erst danach endet der Abschnitt des gesamten Objektes mit der Zeichenfolge "</" Bezeichner des Typs und ">". So sieht die Beschreibung eines Knotentypes, wie folgt, aus (Die benötigten Informationen sind unterstrichen.):
<Class ID=:SC-4 Name="Notation"
PosX=1516 PosY= 424>
<Compo ID=:CO-24 Name="Notation">
<Compo ID=:CO-25 Name="Kopf" Included-in-super=NIL
Expanders=(
"(define (generate node) (html-header node) (title node) (html-footer node))" )></Compo>
<Compo ID=:CO-26 Name="Inhalt" Included-in-super=NI>
</Compo>
<Compo ID=:CO-27 Name="Nagivation" Included-in-super=NIL
Expanders=(
"(define (generate node) (html-header node) (body node) (html-footer node))" )></Compo>
</Compo>
</Class>
Zur Erzeugung der HTML-Dateien aus der SDL-Datei mußte ein Parser geschrieben werden, der die SDL-Datei nach den Bezeichnern durchsucht und dann die nötigen Informationen ausliest. Mit diesen Informationen müssen dann die Verzeichnisse und die Dateien angelegt werden. Diese Dateien müssen einen Kopf (HTML-Tag "head") und einen Rumpf (HTML-Tag "body") besitzen, damit FrontPage diese Dateien lesen kann. In diese Dateien muß zusätzlich der Textinhalt des Knotens geschrieben werden.
Der Filter für die Übertragung der Texte von den HTML-Dateien zu der SDL-Datei muß wesentlich mehr Aufgaben erfüllen. Er muß zunächst wieder einige Daten aus der SDL-Datei lesen. Diese Daten werden benötigt, damit der Filter die HTML-Dateien finden kann. Dabei muß der Inhalt der SDL-Datei in eine neue SDL-Datei geschrieben werden, aus der Schematext die Informationen für die Erstellung der Dokumentation liest. Kommt der Filter beim Parsen der SDL-Datei an die Textinhalte der Knoten, so muß dieser Text überlesen werden. Gleichzeitig muß die HTML-Datei des Knotens gelesen werden und der Inhalt der Datei den alten Text in der SDL-Datei ersetzen.
Dabei müssen jedoch noch einige Änderungen vorgenommen werden. So muß der Kopf und die Rumpfmarkierungen (HTML-Tag "body") entfernt werden. Innerhalb des Rumpfes sind auch Teile zu ändern. Wenn ein Link die neu eingeführten Protokolle ("ci: "und "gi:") besitzt, erfolgt ein Umwandlung des Links in einen spezielle Schematextlink, d.h., der Filter wandelt den Tag "<a>" in einen Tag "<HDSLLink>" um. Dabei muß die mit "href" angegebene Ziel-URL in das Schematextformat umgewandelt werden.
| FrontPage HTML-Datei | Schematext SDL-Datei |
<a href="ci:li-10" >xxxxx</a>
|
<HsdlLink COPY ID=:LI-10>xxxxx</HsdlLink>
|
<a href="gi:li-11">yyyyy</a>
|
<HsdlLink GRAB ID=:LI-11>yyyyy</HsdlLink>
|
Für den Tag "<area>"ist diese Umwandlung ebenfalls erforderlich. Da bei diesem Tag FrontPage einen Kommentar einfügt, ist dieser Kommentar ebenfalls zu löschen. Denn dieser Kommentar kann zu Problemen führen, wenn die fertige Dokumentation in einem Internet-Angebot intregiert werden soll. Wird dieses Angebot mit dem FrontPage Explorer bearbeitet nutzt dieser die Informationen über die Links aus dem Kommentar, anstatt die umgewandelten Links direkt zu lesen.
| FrontPage HTML-Datei | Schematext SDL-Datei |
<!--webbot
bot="ImageMap" startspanrectangle="
(46,17) (166, 49) gi:li-12"
|
<MAP NAME="FrontPageMap0">
|
Die von dem Exportfilter erzeugten HTML-Dateien sollten immer erhalten bleiben. Denn die Rückumwandlung der Links von dem Schematextformat mit "HDSLlink" in eine für FrontPage lesbaren Link mit "a" bedeutet einen weiteren Aufwand. Deshalb wurde diese Konvertierung im ersten Filter weggelassen. Dafür überschreibt dieser Filter aber bestehende Dateien nicht, somit bleiben die Links auch nach einem Benutzen des Exportfilters intakt. Nach dem Löschen der HTML-Dateien lassen sich diese zwar mit dem Exportfilter neu erzeugen, jedoch kann FrontPage die Links nicht mehr richtig darstellen.
Es sollen einige Links automatisch erzeugt werden. Dies sind zum Beispiel die Links zu den Begriffserklärungen im Glossar. Zur Automatisierung habe ich das Programm SED (siehe Abschnitt 3.1.3) verwendet. Damit SED jede HTML-Datei bearbeitet, habe ich ein kleines Programm geschrieben, das die Unterverzeichnisse von dem Verzeichnis FrontPage nach HTML-Dateien durchsucht und dann SED mit jeder dieser Dateien als Parameter aufruft.
SED ersetzt nun alle Begriffe durch den Begriff und die entsprechenden Ergänzungen für die Links. Damit SED diese Änderungen vornehmen kann, sind alle Begriffe und die notwendigen Ergänzungen in einer Steuerdatei für SED aufgeführt. Die Links werden nicht direkt eingefügt, statt dessen werden Funktionsaufrufe zu neu geschriebenen Schematextfunktionen eingefügt. Mit dieser Lösung ist es möglich, die Target-Frames anzugeben. Diese Funktionen benötigen den Zielknoten und den Text des Links als Parameter. Aus diesen Informationen generiert dann Schematext beim Kompilieren die Links. Mit
s!\<Maschine\>!<eval>(glossar-link ':no-383 "&") </eval>!
wird zum Beispiel für den Begriff Maschine ein Link zu dem Knoten Nummer "':no-383" mit dem Zielframe Glossar erzeugt (Dies ist die Seite im Glossar, die den Begriff Maschine erklärt.). Für den Plural von den gesuchten Begriffen muß eine eigene Zeile in die Steuerdatei aufgenommen werden, z.B. für Maschinen:
s!\<Maschinen\>!<eval>(glossar-link ':no-383 "&") </eval>!
Die so erzeugten Ergänzungen können jedoch nicht direkt in die HTML-Dateien geschrieben werden, denn nach Änderungen muß das Programm SED in den Dateien neue Querverweise einfügen. Bei diesem Bearbeiten findet SED den Begriff erneut und fügt wiederum neue Ergänzungen für den Link ein. Diese überlappen sich mit den alten Ergänzungen und Schematext kann den Text nicht mehr übersetzen. Deshalb werden Kopien erzeugt. Aus diesen Kopien erzeugt der Importfilter eine neue SDL-Datei, aus der dann Schematext die Dokumentation erzeugen kann. Die Kopien der HTML-Dateien werden anschließend gelöscht.
Bei der Implementierung dieser Funktion wurde etwas von der Konzeption abgewichen. In der Konzeption wurde vorgesehen, Links zu Klassen nicht an allen Stellen einzufügen, sondern nur an Stellen, wo dies sinnvoll ist. Dies hätte einen erheblichen Aufwand bei der Erstellung der Steuerdateien bedeutet, da für jede HTML-Datei einzeln eine Steuerdatei erstellt werden muß. In der Implementierung wurde deshalb nur eine Steuerdatei für alle HTML-Dateien vorgesehen. Somit ist es nicht möglich bestimmte Links nur in einem bestimmten Kontext zu erzeugen. In dem Beispiel gehen aus diesem Grund von einem Begriff keine zwei Links aus (vgl. Abschnitt 3.2.3), da der zweite Link sich immer auf nur einen bestimmten Kontext bezog.
Die Klassendiagramme müssen um die erweiterte Notation ergänzt werden. Dies geschieht mit Corel Draw. Danach muß Corel Draw die Grafik in das JPEG-Format konvertieren, damit die HTML-Browser die Diagramme anzeigen können.
Die mit Rational Rose erstellten Diagramme werden dazu nach Corel Draw übertragen. Diese Übertragung wird durch die Kopierfunktion in Rational Rose und die Einfügefunktion in Corel Draw vorgenommen. Mit dieser Methode treten in den Diagrammen die geringsten Verluste auf. Hier müssen nur die Pfeile der Benutztbeziehungen und Teile der Vererbungsbeziehungen wiederhergestellt werden. Bei anderen Methoden war die Schrift nicht zu lesen oder es fehlten noch mehr Teile der Grafik.
Nach der Beseitigung der Verluste werden die notwendigen Ergänzungen vorgenommen. Dazu sind die folgenden Schritte notwendig:
Bei den Teildiagrammen ist ebenso ein Rechteck zu zeichnen. Durch Umwandlung des Rechtecks in Kurven kann der Rahmen um die Klassen angepaßt werden. Der Rahmen dieses Kurvenzugs ist grau und 0,76 mm breit.
Zusätzliche Rechtecke dienen der Beschriftung. Diese Rechtecke nehmen dann den Beschriftungstext auf. Der Text ist bei Entwurfsmustern und Teildiagrammen schwarz und bei Hot Spots rot.
Die Corel Draw Funktion "Exportieren" speichert die Diagramme im JPEG-Format im Verzeichnis "Frontpage\images". Das Diagramm hat 16 Millionen Farben, das Größenverhältnis 1:1 und 75 dpi Auflösung. Durch diese Parameter hat das Bild eine gute Qualität und verbraucht dennoch wenig Speicherplatz.
Dieses Bild kann dann in FrontPage über die Funktion "Bild einfügen" in die entsprechende Seite aufgenommen werden. Hier können auch Teile des Diagramms, z.B. die Klassen, als Links markiert werden. Der Linkname entspricht dem Format, das in Abschnitt 3.3.2 angegeben ist.
Hier soll am Beispiel eines Entwurfsmusters gezeigt werden, welche Schritte notwendig sind, um neue Texte in die Dokumentation aufzunehmen. Das Entwurfsmuster "Strategy" aus dem Framework OSEFA dient als Beispiel. Dieses Entwurfsmuster hat in dem Framework die Funktion "Business Process". Für andere Teile der Dokumentation ist die Vorgehensweise weitgehend identisch.
Wenn dies die erste Version des Entwurfsmusters ist, ist in dem Schematext Struktur Editor zuerst ein Knoten für die Versionierung zu erzeugen. Dazu wird ein Knoten vom Typ "Version Muster" mit dem Namen "Business Process (Strategy)" angelegt.
Nun wird der eigentliche Knoten mit dem Knotentyp "Pattern" für die Daten eingefügt. Der Namen des Knoten ist um den Versionstext zu erweitern, so daß der Knotenname "Strategy - Business Process (Searching & Choosing)" ist. Der Quellknoten ist der Versionierungsknoten "Business Process (Strategy)".
Damit Schematext die Navigationsleiste und Teile des Inhaltsverzeichnisses automatisch erzeugen kann, werden zwischen den Unterknoten des Knotens "Strategy - Business Process (Fitting)" Links erzeugt.
| Quellknoten | Zielknoten |
| Navigation_2a | Hauptknoten |
| Verzeichnis_2a | Intent |
| Verzeichnis_2a | Motivation |
| Verzeichnis_2a | Applicability |
| Verzeichnis_2a | Structure |
| Verzeichnis_2a | Participants |
| Verzeichnis_2a | Consequences |
| Verzeichnis_2a | Implementation |
| Verzeichnis_2a | Related Pattern |
Zur kompletten Bearbeitung des Entwurfsmuster müssen die Klassen des Musters eingegeben werden. Deshalb werden nun für alle Klassen des Entwurfsmuster Knoten erzeugt. Als Beispiel für die Klassen dient die Klasse "Strategy". Wo in diesem Beispiel diese Klasse verwendet wird, müssen die gleichen Schritte auch mit den anderen Klassen des Entwurfsmusters durchgeführt werden. Das Einfügen einer Klasse entspricht dem Einfügen eines Musters.
Das Entwurfsmuster ist im Klassendiagramm "Processing Control" enthalten und implementiert gleichzeitig den Hot Spot "Business Process". Da die Links von dem Verzeichnis- und von dem Inhaltsframe des Diagramms ausgehen sollen, sind die drei folgenden Links hinzuzufügen:
| Quellknoten | Zielknoten |
| Processing Control - Verzeichnis_2 | Hauptknoten |
| Processing Control - Inhalt_2 | Hauptknoten |
| Business Process - Hauptknoten | Hauptknoten |
Zusätzlich werden Links zur Klasse "Strategy" erzeugt. Einen Link für die Verkettung aller Klassen des Entwurfsmusters und zwei weitere Links aus dem Verzeichnis und dem Text.
| Quellknoten | Zielknoten |
| Hauptknoten | Strategy |
| Verzeichnis_2a | Strategy |
| Structure | Strategy |
Abbildung 27: Das Entwurfsmuster Strategy
Aus den Schritten eins bis fünf folgt, die in Abbildung 27 dargestellte Struktur.
Dazu wird die Batchdatei "OSEFA htm.bat" gestartet.
Nun sind die Texte einzugeben. Dazu werden die HTML-Dateien mit FrontPage bearbeitet.
| Verzeichnis | Datei |
| Pattern_-_Intent_70_ | Strategy_-_Business_Process_(_Fitti_100.htm |
| Pattern_-_Motivation_68_ | Strategy_-_Business_Process_(_Fitti_96_.htm |
| Pattern_-_Applicability_87_ | Strategy_-_Business_Process_(_Fitti_234.htm |
| Pattern_-_Structure_58_ | Strategy_-_Business_Process_(_Fitti_120.htm |
Damit Links zur Klasse "Strategy" in den Texten des Entwurfsmusters aufgenommen werden, ist die Steuerdatei für SED zu erweitern. Die Datei heißt "wandeln.txt" und befindet sich im Verzeichnis "Programm". Damit diese Links erzeugt werden können, wird in dieser Datei die Zeile
s!\<Strategy\>!<eval>(klasse-link ':no-430 "&") </eval>!
hinzugefügt. Der Eintrag zwischen den ersten und zweiten Ausrufungszeichen gibt an, daß SED nach dem Wort ("\<" und "\>") "Strategy" suchen soll. Der folgende Teil fügt die Funktion "klasse-link" ein, die einen Link zu der Klasse Strategy (Identifikationsnummer ':no-430) mit dem Zielframe "Inhalt_2a" erzeugt.
Dazu wird die Batchdatei "OSEFA komplett.bat" gestartet.
Dazu wird die Funktion "Übersetzen Voll"
aufgerufen.