3.3 Die Komponenten der Werkzeugumgebung und ihre Bedienung

<body> <h1><font face="Arial">3.3. </font><a name="_Toc404828256"><font face="Arial">Die Komponenten der Werkzeugumgebung und die Bedienung</font></a> </h1> <p>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. </p> <h2><font size="4" face="Arial">3.3.1 </font><a name="_Toc404828257"><font size="4" face="Arial">Die Konfiguration </font></a><font size="4" face="Arial">von Schematext</font> </h2> <p>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 <i>Knotentypen</i> eingeführt. Es existieren <i>Knotentypen</i> für die Klassendiagramme, die Hot Spots, Entwurfsmuster, Klassen usw., siehe Abbildung 23. Für alle diese <i>Knotentypen</i> wurde die Bildschirmaufteilung entsprechend den Vorgaben aus Kapitel 2.2.2 mit Hilfe von Frames realisiert. Dafür sind <i>Unterknotentypen</i> eingeführt worden, die jeweils den Inhalt eines Frames beschreiben. Die <i>Unterknotentypen</i> für Bildschirmteile Kopf, Inhaltsverzeichnis und Navigation wurden so konfiguriert, daß Schematext diese Frames weitgehend automatisch generiert. </p> <p>Beim Bildschirmteil, der die Informationen aufnehmen soll, wurden die einzelnen <i>Unterknotentypen</i> zusätzlich um weitere <i>Unterknotentypen</i> ergänzt, um die Texte weiter zu gliedern. So existieren bei den Entwurfsmustern die <i>Unterknotentypen</i> 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]. </p> <p>Zusammen mit den <i>Knotentypen</i> wurden auch die <i>Linktypen</i> erstellt und deren Aussehen festgelegt. Die Beziehungen zwischen den <i>Knotentypen</i>, die die <i>Linktypen</i> ausdrücken , sind sehr komplex. Denn in den meisten Fällen gehen die <i>Links</i> 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 <i>Links</i> zu dem gleichen Objekt. Für alle <i>Links</i> aus unterschiedlichen Frames muß trotz des gleichen Ziels ein eigener <i>Linktyp</i> definiert werden. </p> <p>Damit Schematext die Navigationsleiste automatisch generieren kann wurden weitere <i>Linktypen</i> notwendig. Die meisten der schon vorhandenen <i>Linktypen</i> konnten nicht verwendet werden, da diese von einem Frame ausgehen. Damit aber die Seite bei Nutzung eines <i>Links</i> in der Navigationsleiste richtig aufgebaut werden kann, muß der <i>Linktyp</i> vom <i>Hauptknotentyp</i> ausgehen. Deshalb ist noch ein <i>Linktyp</i> von dem <i>Hauptknotentyp</i> zu den Objekten notwendig. </p> <p>Für die automatische Generierung der Navigationsleiste wurden zusätzlich einige <i>Linktypen</i> doppelt ausgeführt. Bei einem <i>Linkty</i>p wird auch ein Link in der Navigationsleiste eingefügt, bei dem anderen <i>Linktyp</i> wird kein weiterer <i>Linktyp</i> hinzugefügt. </p> <p><img src="IMG00023.gif" width="600" height="800"></p> <p><a name="_Ref403795128"><strong>Abbildung 23</strong></a><strong>: </strong><strong><i>Schema</i></strong><strong> der Dokumentation (Ausschnitt) </strong></p> <p>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 <i>Knoten</i> von dem <i>Links</i> 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 <i>Knoten</i>, hier das Entwurfsmuster, genutzt werden. Bei anderen Listen, z.B. der Liste aller Entwurfsmuster, ist ein neuer <i>Knoten</i> notwendig. Dabei wurde der dazugehörige <i>Knotentyp</i> so angelegt, daß die daraus von Schematext erstellte HTML-Seite nicht sichtbar wird, da diese Seite keinen Inhalt hat. </p> <p>Für die Versionierung wurden ebenfalls solche <i>Knotentypen</i> 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. </p> <p><font size="4" face="Arial">3.3.2 </font><a name="_Toc404828258"><font size="4" face="Arial">Der Datenfluß in der Werkzeugumgebung</font></a> </p> <p>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. </p> <p>Für das Einfügen von neuen Daten in die Dokumentation ist es notwendig, daß in Schematext neue <i>Knoten</i> erzeugt werden. Der <i>Knotentyp</i> entspricht dem Typ des beschriebenen Objekts. Danach werden neue <i>Links</i> erzeugt. Diese <i>Links </i>gehen von dem Verzeichnis in die Unterknoten des Inhalts. Mit diesen <i>Links</i> werden alle Abschnitte des Textes im Verzeichnis aufgeführt. Weiterhin muß ein <i>Link</i> von dem <i>Unterknoten</i> Navigation zu dem <i>Hauptknoten</i> erzeugt werden, damit Schematext die Navigationsleiste erzeugen kann. </p> <p>Nun folgt die Erzeugung von den <i>Links</i> zwischen den einzelnen Objekten. Der erzeugte <i>Knoten</i> steht in Beziehung mit anderen Objekten. Diese Beziehungen sollen als Links im erzeugten HTML-Dokument erscheinen. Deshalb müssen diese in Schematext als <i>Links</i> eingegeben werden. Dazu werden die vordefinierten <i>Linktypen</i> verwendet. Auch die <i>Links</i>, die später in die Texte eingefügt werden sollen, werden erzeugt. </p> <p>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 <i>Unterknoten</i> eine HTML-Datei. Diese Dateien werden in einem Unterverzeichnis des Verzeichnisses von FrontPage erzeugt. Der Filter wird in Kapitel 3.3.3 beschrieben. </p> <p><img src="IMG00024.gif" width="449" height="634"></p> <p><a name="_Ref399046064"><strong>Abbildung 24</strong></a><strong>: Der Datenfluß in der Werkzeugumgebung</strong> </p> <p>Die neuen HTML-Dateien können nun mit dem FrontPage Editor bearbeitet werden. Der Filter hat für alle <i>Unterknoten</i> 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 "<<i>Knotentypname</i>>_Inhalt<...>". Wenn der Text in kleinere Abschnitt unterteilt ist, wie bei den Entwurfsmustern mit Intent, Motivation usw., so stehen die Dateien in den Verzeichnissen "<<i>Knotentypname</i>>_<Abschnittname><...>". </p> <p>Bei der Eingabe von Texten in FrontPage können auch <i>Links</i> zu anderen Seiten der Dokumentation erzeugt werden. Es muß jedoch ein spezielles Format für den <i>Linknamen</i> eingehalten werden, da die Namen der Zieldateien erst nach dem Kompilieren mit Schematext bekannt sind. Damit diese <i>Links</i> von anderen Links, die nach Zielen außerhalb der Dokumentation verweisen, unterscheidbar sind, werden zwei spezielle Protokolle eingeführt. Während ein <i>Link</i> mit dem Protokoll "gi:" einen <i>Link</i> aus der von Schematext generierten Linkliste entfernt und ihn an die neue Stelle einfügt, wird bei einem <i>Link</i> mit dem Protokoll "ci:" eine Kopie des <i>Links</i> aus der Linkliste erzeugt. Statt an das Protokoll nun die Domain und den Pfad der Datei anzuhängen, wird an das Protokoll nun die <i>Linknummer</i> aus Schematext angehängt. Die <i>Linknummer</i> wird in Schematext im Menü "Eigenschaften" des <i>Links</i> angezeigt. Sie besteht aus den Buchstaben "li", einem Bindestrich und einer Zahl. Ein Vollständiger <i>Linkname</i> kann zum Beispiel "gi:li-488" sein. </p> <p>Der Filter für den Import schreibt die Eingaben zurück in die <i>SDL-Datei</i> 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. </p> <h3><font size="4" face="Arial">3.3.3 </font><a name="_Toc404828259"><font size="4" face="Arial">Die Filter</font></a> </h3> <p>Da die Möglichkeiten des <i>Schematext Editors</i> 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. </p> <p><img src="IMG00025.gif" width="294" height="348"></p> <p><a name="_Ref402018182"><strong>Abbildung 25</strong></a><strong>: Gewünschte Dateienanordnung</strong> </p> <p>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 <i>Knotentyp</i> ein eigenes Verzeichnis erstellt wird und in diesem Verzeichnis für alle <i>Unterknotentypen</i> 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 <i>Unterknotentypen</i> ist sinnvoll, weil einige <i>Unterknotentypen</i> nur für die Generierung notwendig sind und in die <i>Unterknoten</i> keine Daten eingegeben werden müssen. Damit sind alle Dateien zusammengefaßt, die die Texte aufnehmen. </p> <p>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. </p> <p><img src="IMG00026.gif" width="437" height="374"></p> <p><a name="_Ref402018236"><strong>Abbildung 26</strong></a><strong>: Implementierte Dateienanordnung</strong> </p> <p>Schematext generiert aber gegenüber der gewünschten Verzeichnisstruktur eine Verzeichnisebene weniger. Es wird jeweils ein Verzeichnis für alle <i>Knotentypen</i> erstellt. In diesem Verzeichnis werden die HTML-Dateien der <i>Knoten</i> und der <i>Unterknoten</i> dieses Typs erzeugt. Aus diesem Grund wurde die Verzeichnisstruktur des FrontPage-Verzeichnis abgeändert. Es wird nur noch eine Verzeichnisebene erzeugt. Damit die einzelnen <i>Unterknoten</i> besser zu unterscheiden sind, wird für jeden <i>Unterknotentyp</i> ein Verzeichnis erstellt. Der Name dieses Verzeichnis besteht dann aus einer Aneinanderreihung des <i>Knotentypnamens</i> und des <i>Unterknotentypnames</i>. 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. </p> <p>Bei der Namengebung für die Verzeichnisse und für die Dateien muß etwas vom <i>Knotennamen</i> abgewichen werden. Da Schematext es ermöglicht gleiche Namen für unterschiedliche <i>Knoten</i> bzw. <i>Knotentypen</i> zu verwenden, dies aber auf Dateiebene nicht möglich ist, muß der Dateiname mit einer eindeutigen Kennung versehen werden. Dazu wird die Identifikationsnummer des <i>Knotens</i> bzw. <i>Knotentyps</i> 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. </p> <p>Damit diese Verzeichnisstruktur mit den HTML-Dateien erstellt werden kann, ist es nötig, </p> <ul> <li>den <i>Knotentypnamen</i>, </li> <li>den <i>Unterknotentypnamen</i>, </li> <li>die <i>Unterknotentypidentifikationsnummer</i>, </li> <li>die <i>Knotennamen</i>, </li> <li>die <i>Knotenidentifikationsnummer</i> und </li> <li>den <i>Knoteninhalt</i> </li> </ul> <p>zu kennen. </p> <p>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. </p> <p>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 <i>Knotentypes</i>, wie folgt, aus (Die benötigten Informationen sind unterstrichen.): </p> <pre> <Class ID=:SC-4 Name="<u>Notation</u>" PosX=1516 PosY= 424> <Compo ID=<u>:CO-24</u> Name="<u>Notation</u>"> <Compo ID=<u>:CO-25</u> Name="<u>Kopf</u>" Included-in-super=NIL Expanders=( "(define (generate node) (html-header node) (title node) (html-footer node))" )></Compo> <Compo ID=<u>:CO-26</u> Name="<u>Inhalt</u>" Included-in-super=NI> </Compo> <Compo ID=<u>:CO-27</u> Name="<u>Nagivation</u>" Included-in-super=NIL Expanders=( "(define (generate node) (html-header node) (body node) (html-footer node))" )></Compo> </Compo> </Class> </pre> <p>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. </p> <p>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. </p> <p>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. </p> <table border="1"> <tr> <td width="298">FrontPage HTML-Datei</td> <td width="316">Schematext SDL-Datei </td> </tr> <tr> <td width="298"><code><a href="ci:li-10" <br> </code><font size="2" face="Courier New"><code>>xxxxx</a></code></font> </td> <td width="316"><code><HsdlLink COPY ID=:LI-10<br> </code><font size="2" face="Courier New"><code>>xxxxx</HsdlLink></code></font> </td> </tr> <tr> <td width="298"><code><a href="gi:li-11"<br> </code><font size="2" face="Courier New"><code>>yyyyy</a></code></font> </td> <td width="316"><code><HsdlLink GRAB ID=:LI-11<br> </code><font size="2" face="Courier New"><code>>yyyyy</HsdlLink></code></font> </td> </tr> </table> <p>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. </p> <table border="1"> <tr> <td width="298">FrontPage HTML-Datei</td> <td width="316">Schematext SDL-Datei </td> </tr> <tr> <td width="298"><code></code></font> <p><code><MAP NAME="FrontPageMap0"></code> </p> <p><code><AREA SHAPE="RECT" COORDS="46, 17, 166, 49" HREF="gi:li-12"></code> </p> <p><code></MAP></code> </p> <p><code><img src="../images/Anwendung.JPG" border="0" width="236" height="163" usemap="#FrontPageMap0"></code> </p> <p><code></code> </p> </td> <td width="316"><br> <br> <br> <br> <br> <br> <code><MAP NAME="FrontPageMap0"></code> <p><code><HDSLAREA SHAPE="RECT" COORDS="46, 17, 166, 49" id=:li-12></code> </p> <p><code></MAP></code> </p> <p><code><img src="../images/Anwendung.JPG" border="0" width="236" height="163" usemap="#FrontPageMap0"><br> </code></p> </td> </tr> </table> <p>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. </p> <h3><font size="4" face="Arial">3.3.5 </font><a name="_Toc404828260"><font size="4" face="Arial">Das automatische Einfügen von Querverweisen</font></a> </h3> <p>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. </p> <p>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 </p> <pre> s!\<Maschine\>!<eval>(glossar-link ':no-383 "&") </eval>! </pre> <p>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: </p> <pre> s!\<Maschinen\>!<eval>(glossar-link ':no-383 "&") </eval>! </pre> <p>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. </p> <p>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. </p> <h2><font size="4" face="Arial">3.3.5 </font><a name="_Toc404828261"><font size="4" face="Arial">Das Einfügen von Diagrammen</font></a> </h2> <p>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. </p> <p>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. </p> <p>Nach der Beseitigung der Verluste werden die notwendigen Ergänzungen vorgenommen. Dazu sind die folgenden Schritte notwendig: </p> <ol> <li>Ein Rechteck in Corel Draw erzeugen. </li> <li>Das Rechteck in Kurven umwandeln. </li> <li>Das Rechteck an die Plazierung der Klassen des Entwurfsmusters anpassen. </li> <li>Die Funktion Linse für die Fläche einstellen (Einstellungen: Transparentfolie, Rate 90%, Farbe blau). </li> </ol> <p>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. </p> <p>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. </p> <p>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. </p> <p>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. </p> <h2><font size="4" face="Arial">3.3.6 </font><a name="_Toc404828262"><font size="4" face="Arial">Beispiel: Das Einfügen eines Entwurfsmuster</font></a><font size="4" face="Arial">s</font> </h2> <p>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. </p> <h4>1. Einfügen eines <i>Knoten</i> für die Versionierung. </h4> <p>Wenn dies die erste Version des Entwurfsmusters ist, ist in dem Schematext <i>Struktur Editor</i> zuerst ein <i>Knoten</i> für die Versionierung zu erzeugen. Dazu wird ein <i>Knoten</i> vom Typ "Version Muster" mit dem Namen "Business Process (Strategy)" angelegt. </p> <h4>2. Einfügen des <i>Knoten</i>. </h4> <p>Nun wird der eigentliche Knoten mit dem <i>Knotentyp</i> "Pattern" für die Daten eingefügt. Der Namen des <i>Knoten</i> ist um den Versionstext zu erweitern, so daß der <i>Knotenname</i> "Strategy - Business Process (Searching & Choosing)" ist. Der Quellknoten ist der Versionierungsknoten "Business Process (Strategy)". </p> <h4>3. Herstellen der von Schematext benötigten <i>Links.</i> </h4> <p>Damit Schematext die Navigationsleiste und Teile des Inhaltsverzeichnisses automatisch erzeugen kann, werden zwischen den <i>Unterknoten</i> des Knotens "Strategy - Business Process (Fitting)" <i>Links</i> erzeugt. </p> <table border="3"> <tr> <td width="198"><font size="4">Quellknoten</font></td> <td width="227">Zielknoten </td> </tr> <tr> <td width="198">Navigation_2a</td> <td width="227">Hauptknoten </td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Intent</td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Motivation </td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Applicability </td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Structure</td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Participants </td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Consequences </td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Implementation </td> </tr> <tr> <td width="198">Verzeichnis_2a</td> <td width="227">Related Pattern </td> </tr> </table> <h4>4. Einfügen der Klassen, </h4> <p>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. </p> <h4>5. Einfügen der <i>Links</i> zu bzw. von dem Entwurfsmuster. </h4> <p>Das Entwurfsmuster ist im Klassendiagramm "Processing Control" enthalten und implementiert gleichzeitig den Hot Spot "Business Process". Da die <i>Links</i> von dem Verzeichnis- und von dem Inhaltsframe des Diagramms ausgehen sollen, sind die drei folgenden <i>Links</i> hinzuzufügen: </p> <table border="3"> <tr> <td width="265"><font size="4">Quellknoten</font></td> <td width="255">Zielknoten </td> </tr> <tr> <td width="265">Processing Control - Verzeichnis_2</td> <td width="255">Hauptknoten </td> </tr> <tr> <td width="265">Processing Control - Inhalt_2</td> <td width="255">Hauptknoten </td> </tr> <tr> <td width="265">Business Process - Hauptknoten</td> <td width="255">Hauptknoten </td> </tr> </table> <p>Zusätzlich werden <i>Links</i> zur Klasse "Strategy" erzeugt. Einen <i>Link</i> für die Verkettung aller Klassen des Entwurfsmusters und zwei weitere <i>Links</i> aus dem Verzeichnis und dem Text. </p> <table border="3"> <tr> <td width="265"><font size="4">Quellknoten</font></td> <td width="255">Zielknoten </td> </tr> <tr> <td width="265">Hauptknoten</td> <td width="255">Strategy</td> </tr> <tr> <td width="265">Verzeichnis_2a</td> <td width="255">Strategy</td> </tr> <tr> <td width="265">Structure </td> <td width="255">Strategy</td> </tr> </table> <p><img src="IMG00027.gif" width="592" height="444"></p> <p><a name="_Ref404402080"><strong>Abbildung 27</strong></a><strong>: Das Entwurfsmuster Strategy</strong> </p> <p>Aus den Schritten eins bis fünf folgt, die in Abbildung 27 dargestellte Struktur. </p> <h4>6. Nach FrontPage exportieren. </h4> <p>Dazu wird die Batchdatei "OSEFA htm.bat" gestartet. </p> <h4>7. Bearbeiten der einzelnen Abschnitte. </h4> <p>Nun sind die Texte einzugeben. Dazu werden die HTML-Dateien mit FrontPage bearbeitet. </p> <table border="3"> <tr> <td width="208"><font size="4">Verzeichnis</font></td> <td width="312">Datei </td> </tr> <tr> <td width="208">Pattern_-_Intent_70_</td> <td width="312">Strategy_-_Business_Process_(_Fitti_100.htm </td> </tr> <tr> <td width="208">Pattern_-_Motivation_68_</td> <td width="312">Strategy_-_Business_Process_(_Fitti_96_.htm </td> </tr> <tr> <td width="208">Pattern_-_Applicability_87_</td> <td width="312">Strategy_-_Business_Process_(_Fitti_234.htm </td> </tr> <tr> <td width="208">Pattern_-_Structure_58_</td> <td width="312">Strategy_-_Business_Process_(_Fitti_120.htm </td> </tr> </table> <h4>8. Automatische Generierung der <i>Links</i> zu den Klassen vorbereiten. </h4> <p>Damit <i>Links</i> 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 <i>Links</i> erzeugt werden können, wird in dieser Datei die Zeile </p> <pre> s!\<Strategy\>!<eval>(klasse-link ':no-430 "&") </eval>! </pre> <p>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 <i>Link</i> zu der Klasse Strategy (Identifikationsnummer ':no-430) mit dem Zielframe "Inhalt_2a" erzeugt. </p> <h4>9. Importieren der Daten in Schematext. </h4> <p>Dazu wird die Batchdatei "OSEFA komplett.bat" gestartet. </p> <h4>10. Übersetzen des Schemas. </h4> <p>Dazu wird die Funktion "Übersetzen Voll" aufgerufen. <br> </p> </body>