5. Existierende Browser 5.1.   Traditionelle Werkzeuge für Eiffel Bertrand Meyer hat in [Meyer 88] drei Werkzeuge beschrieben, die den Umgang mit Eiffel erleichtern sollten: short, flat und good. Diese wurden auch z.B. mit ISE Eiffel 2.x ausgeliefert. short gibt zu einer als Parameter angegebenen Klasse das Interface aus. Es sind nur die in dieser Klassen definierten Merkmale sichtbar und nicht die geerbten. Das Werkzeug ist "batchorientiert", d.h. eine interaktive Arbeit (abgesehen von einem erneuten Aufruf mit anderen Parametern) wird nicht unterstützt. (Anmerkung: Ich verwende hier einen etwas anderen Werkzeugbegriff als WAM, wo Interaktivität bereits in der Definition eines Werkzeuges enthalten ist.) Durch den Aufruf von "short Klassenname" erhält man die Klassenschnittstelle der angegebenen Klasse. Die Merkmale der Klasse erscheinen grundsätzlich in der Reihenfolge ihres Auftretens im Quelltext. Als zusätzliche Dokumentation erscheinen lediglich die Kommentare im Quelltext der Klasse. Diese Art der Darstellung wird als Short-Form bezeichnet. flat erweitert eine Klasse um die Eigenschaften, die sie von ihren Oberklassen erbt. Man erhält so die volle Schnittstelle einer Klasse, wie sie von ihren Benutzern (Clients) verwendet werden kann, die sog. Flat-Form. Diese Erweiterung ist wichtig, weil sehr häufig nur wenige Operationen in einer Klasse spezialisiert werden, während eine größere Zahl von Operationen unverändert übernommen wird. Um in Verbindung mit den eben beschriebenen short die volle Schnittstelle einer Klasse inklusive ihrer geerbten Operationen, die sog. Flatshort-Form, zu erhalten, ist das Unix Kommando "flat Klassenname | short" nötig. flat ist ebenfalls nicht interaktiv. Die eigentliche Intention von short war es, keine separate Dokumentation zu den erstellten Klassen pflegen zu müssen und alle Informationen im Klassentext unterzubringen und dann mit short zu extrahieren. In diesem Sinne ist short in der Tat ein brauchbarer Ersatz für ein Online-Manual zu den einzelnen Klassen. Ein Vorteil ist sicher, daß die Dokumentation immer auf dem gleichen Stand wie die Implementation ist. Auch wenn Meyer behauptet, man würde durch dieses Vorgehen die Dokumentation "essentially for free" erhalten ([Meyer 88], Seite 346), so ist es doch notwendig, eine gute, strukturierte Dokumentation (als Kommentar) in den Quell­text zu schreiben, damit diese dann mit short extrahiert werden kann. Als einen Browser kann man dieses Gespann sicherlich nicht bezeichnen. Auch eine klassen­übergreifende Dokumentation, um die Verwendung der Klassen zu verdeutlichen, kann durch sie nicht ersetzt werden. (Trotzdem liefert ISE fast ausschließlich mit short produzierte Dokumentation zur Eiffel-Bibliothek aus.) Im Umgang mit short und flat stellt sich die mangelnde Interaktivität als besonders hinderlich heraus. Bei jedem Verweis auf andere Klassen muß zu diesen gesondert die Schnittstelle angefordert werden. Oft ist auch das Volumen der zu einer Klasse gelieferten Informationen so groß, daß sich kaum ein Vorteil gegenüber dem direkten Betrachten des Quelltextes ergibt. Es ist nicht sichtbar, in welchem Zusammenhang eine Klasse verwendet wird. Man kann zwar die Oberklassen sehen, nicht aber, ob es bereits andere Klassen gibt, die eine bestimmte Klasse benutzen oder von ihr erben. Auch fehlt es völlig an Möglichkeiten, die Informationsflut zu filtern. Immer werden alle Informationen zu einer Klasse präsentiert. So ist die Ausgabe von short für eine durch­schnittliche Bibliotheksklasse oft mehrere Bildschirmseiten lang. Als abschreckendes Beispiel zeigt Abb. 2 die keinesfalls kurze Ausgabe von short zur Klasse LINKED_LIST aus ISE Eiffel 3. Das Beispiel ist bereits um ca. 2/3 gekürzt und zeigt, wie unübersichtlich die Ausgabe sein kann. Die Flatshort-Form (also die volle Klassenschnittstelle) ist ca. dreifach so lang. Ein weiteres Filtern der Informationsflut ist nicht möglich. Die Kommentierung und Strukturierung ist direkt aus dem Quelltext übernommen und sieht bei weniger gut formatierten Quelltexten entsprechend unübersichtlicher aus.   indexing        description: "Sequential, one-way linked lists"        status: "See notice at end of class"        names: linked_list, sequence        representation: linked        access: index, cursor, membership        contents: generic        date: "$Date: 94/01/04 12:25:59 $"        revision: "$Revision: 1.3 $"   class interface LINKED_LIST [G]   creation        make   feature  --  Access          cursor: CURSOR              --  Current cursor position               first: like item              --  Item at first position               index: INTEGER              --  Index of current position               item: G              --  Current item               last: like item              --  Item at last position        feature  --  Cursor movement          back              --  Move to previous item.               finish              --  Move cursor to last position.              --  (Go before if empty)        ensure              empty_convention: empty implies before               forth              --  Move cursor to next position.               go_i_th (i: INTEGER)              --  Move cursor to `i'-th position.               go_to (p: CURSOR)              --  Move cursor to position `p'.               move (i: INTEGER)              --  Move cursor `i' positions. The cursor              --  may end up `off' if the offset is too big.        ensure              moved_if_inbounds: ((old index + i) >= 0 and (old index + i) <= (count + 1)) implies index = (old index + i);              before_set: (old index + i) <= 0 implies before;              after_set: (old index + i) >= (count + 1) implies after               start              --  Move cursor to first position.        ensure              empty_convention: empty implies after               [...]          invariant        prunable: prunable;        end -- class LINKED_LIST Abb. 2: Short-Form der Klasse LINKED_LIST (gekürzt) Der graphische Browser good unterstützt das interaktive Untersuchen des Systems und stellt die Beziehungen der Klassen graphisch dar. Prinzipiell ist good dazu gedacht, das Zusammen­spiel aller Klassen eines Eiffel-Universums darzustellen. Dies gelingt aber nur sehr bedingt, da "die Arbeitsfläche beschränkt ist und die Funktionen zum Filtern der Informationsmenge nicht ausreichen" ([Strunk 92]). Auch ist kein Zugriff auf den Quelltext der dargestellten Klassen vorgesehen ([GamWeiMar 89]), und die Bedienung weist diverse Probleme auf. Statt auf good weiter einzugehen, beschreibe ich im nächsten Abschnitt die neue Entwicklungsumgebung von ISE, die good ersetzt hat (siehe [Strunk 92] für eine ausführlichere Kritik an good). Die hier beschriebenen Werkzeuge wurden zusammen mit ISE Eiffel 2.x ausgeliefert. Bei anderen Compilern sind z.T. ähnliche, aber z.T. auch überhaupt keine Werkzeuge enthalten (so z.B. SiG Eiffel/S), so daß man bei ihnen auf das Handbuch und das Studium der Quelltexte für die Bibliotheken angewiesen ist. Bei der Arbeit mit nicht vom Compiler-Hersteller gelieferten Quelltexten ist man ausschließlich auf die direkte Arbeit mit dem Quelltext angewiesen. 5.2.   Die Entwicklungsumgebung von ISE Eiffel 3 In der neusten Version von ISE Eiffel 3 hat man einige der Probleme der alten Werkzeuge erkannt. Die Entwicklungsumgebung ist erweitert worden [Meyer 94], und es steht innerhalb der Entwicklungsumgebung ebench ein Klassen-Browser, das sog. Class Tool, zur Verfügung. Das Class Tool stellt per default den Quelltext der Klasse dar. Durch Anklicken eines Icons am unteren Rand des Fensters kann man stattdessen die bereits beschriebene Short-Form, Flat-Form oder Flatshort-Form darstellen lassen. Insoweit sind die bisherigen Umgangsformen nur auf eine graphische Oberfläche umgesetzt worden. Abb. 3: Das Class Tool mit der Klasse LINKED_LIST Alternativ können die Ober- oder Unterklassen in textueller Darstellung als Baum angezeigt werden. Weiterhin kann man sich statt des Klassentextes eine Liste der Benutzer (Clients) der Klasse, der benutzten Klassen (Supplier), der Attribute der Klasse, der Routinen der Klasse, der aufgeschobenen (deferred) Routinen, der einmalig (once) ausgeführten Routinen oder der externen Routinen anzeigen lassen. Da man beliebig viele Fenster mit dem Class Tool öffnen kann, stehen alle Darstellungsformen auch parallel zur Verfügung. Änderungen können aber nur in der Quelltext-Darstellung vorgenommen werden. Da das Class Tool jedoch hauptsächlich als Browser ausgelegt ist, sind die Editor-Funktionen dementsprechend nur wenig mächtig. Die Darstellung in den anderen Fenstern wird bei Änderungen nicht aktualisiert. Die Funktionen um nur Attribute, nur Routinen o.ä. darzustellen (siehe Abb. 4) beziehen sich immer nur auf die aktuell bearbeitete Klasse, so daß ein gezieltes, klassenübergreifendes Suchen nach bestimmten Merkmalen nicht möglich ist.   Quelltext der Klasse anklickbarer Quelltext Flat-Form Short-Form Flatshort-Form Oberklassen Unterklassen Kunden Lieferanten Attribute Routinen Aufgeschobene Merkmale einmalig ausgeführte Routinen externe Routinen Abb. 4: Die Icons des Class Tool Die alten Umgangsformen sind fast 1:1 auf eine graphische Oberfläche übertragen worden. Es ist nun zwar leichter, eine Short-Darstellung zu bekommen, aber die grundsätzliche Kritik, daß weitere Einschränkungen der Informationsmenge möglich sein sollten, bleibt bestehen. Es können immer entweder nur die Oberklassen oder nur die Unterklassen dargestellt werden und nicht die volle Vererbungshierarchie. Auch ist die textuelle Darstellung, die Vererbung durch Einrückungen darstellt, nur bedingt in der Lage, Mehrfachvererbung sinnvoll darzustellen. Da sie baumartig strukturiert ist, kann es vorkommen, daß bei Mehrfach­vererbung eine Klasse auch mehrfach in der Vererbungshierarchie auftaucht, ohne daß zu erkennen wäre, daß sie anderen Orts noch einmal auftaucht. Ein Beispiel: In Abb. 5 taucht die Klasse LINKED_TREE sowohl als Unterklasse von DYNAMIC_TREE als auch als Unterklasse von LINKED_LIST auf. Der geneigte Leser möge selbst beurteilen, ob es ihm aufgefallen wäre. Abb. 5: Darstellung von Vererbung im Class Tool Die Bedienung des Browsers ist gewöhnungsbedürftig und entspricht nicht unbedingt dem Styleguide der jeweiligen Plattform. Andererseits ist die Bedienung von ISE Eiffel 3 auf allen unter­stützten Plattformen gleich, was man auch als Vorteil werten kann. Ein Beispiel für die ungewöhnliche Bedienung: Um im Class Tool die Implementation einer verwendeten Klasse anzeigen zu lassen muß zunächst auf die anklickbare Darstellung umgeschaltet und dann der Klassenname mit der rechten Maustaste auf das Icon des Class Tools gezogen werden. Die z.T. ins Feld geführte mangelnde Stabilität des Browsers (vergl. [Shipman 94]) ist bei mir nicht aufgetreten. 5.3.   Browser für andere objektorientierte Sprachen Da mir keine weiteren Browser für Eiffel zur Verfügung standen, habe ich auch einige Browser für andere objektorientierte Sprache betrachtet, um ihre Funktionalität mit der von Eiffel-Browsern zu vergleichen. 5.3.1.         Der Browser von Visual C++ Visual C++ von Microsoft stellt eine integrierte Entwicklungsumgebung zur Verfügung, die unter anderem auch einen Browser enthält (vergl. [Microsoft 93]). Ein Compilerschalter sorgt dafür, daß während des Compilierens zum jeweiligen Projekt eine Datenbank für den Browser aufgebaut wird. Diese Datenbank steht dann nach dem Linken des Projektes zur Verfügung. Der Browser stellt eine Liste der Namen aller Klassen, Methoden etc. des Projektes dar. Zu jedem dieser Einträge kann man sich eine Liste mit den Definitionen des Namens und allen Verwendungen anzeigen lassen. Die dargestellten Einträge können auf Funktionen, Variablen, Typen, Makros oder Klassen eingeschränkt werden. Zusätzlich können sie noch durch Wild­cards in begrenztem Maße eingeschränkt werden. Abb. 6: Der Browser von Visual C++ Über den Call Graph bzw. den Caller Graph kann dargestellt werden, welche Funktion von einer anderen aufgerufen wird. Benutzt-Beziehungen auf Klassenebene können nicht betrachtet werden. Um die Vererbungshierarchie darstellen zu lassen, kann man sich entweder den Graph der Oberklassen oder den Graph der Unterklassen anzeigen lassen. Um die Menge der angezeigten Informationen zu reduzieren, kann man einen Untergraph zu einem Knoten zusammenfassen lassen ("Colapse Node"). Eine Kombination der beiden Graphen ist nicht möglich, bzw. man müßte alle Unterklassen der Wurzelklasse anzeigen lassen. Durch die baumartige Anordnung läßt sich Mehrfachvererbung nicht sinnvoll darstellen. Bei allen Darstellungen kann man durch einen Doppelklick auf das Symbol zu seiner Definition gelangen. Da der Compiler die Informationen für die Browser-Datenbank sammelt, können nur compilierbare Quelltexte überhaupt untersucht werden. Sogar korrekte Klassen können nicht betrachtet werden, wenn es noch inkorrekte Klassen an anderen Stellen im Projekt gibt. Eine zusätzliche Problematik ist die Konsistenz der Browser-Informationen: Nach Änderungen im Quelltext sind die Informationen im Browser inkonsistent, bis das Projekt erneut compiliert und gelinkt wird. Der Benutzer wird nicht über den inkonsistenten Zustand informiert. Selbst bei kleinen Projekten wird der (ohnehin schon recht langsame) Compiler durch das Sammeln von Browser-Informationen erheblich verlangsamt, so daß man den Browser nur aktiviert, wenn man meint, ihn dringend zu brauchen. Auch die Bedienung des Browsers ist etwas umständlich, da jede Veränderung der Such­einstellungen mit einem Klick auf "Display Result" bestätigt werden muß. 5.3.2.         Sniff+ Sniff+ ist eine auf C und C++ ausgerichtete Entwicklungsumgebung, die von der Firma TakeFive, Salzburg vertrieben wird. Ein Ziel von Sniff+ ist es, die Entwicklung von großen Softwareprojekten[5] zu unterstützen. Eine ganze Reihe von Werkzeugen ist eng miteinander integriert, um die Bearbeitung der Quelltexte zu erleichtern ([Bischofberger 92]). Die zu bearbeitenden Dateien werden mit dem Projekt-Editor in Projekte und Unterprojekte zusammengefaßt. Auf diese Weise ist es möglich, große Projekte in Module und Bibliotheken zu strukturieren und somit überschaubarer zu machen. Zusätzlich steigert dieses Vorgehen die Effizienz von Sniff+, da für alle Benutzer die Informationen über die verwalteten Quelltexte zentral vorgehalten werden können. Der Editor erlaubt ein hypertext-artiges Navigieren zwischen den im Quelltext vorkommenden Methoden. Mit einem Doppelklick auf ein an der Seite aufgelistetes Symbol gelangt man wahlweise zu dessen Definition bzw. Implementation. (Anmerkung: In C++ ist es üblich, die Definition und Implementation von Methoden zu trennen, meist sogar in unterschiedliche Dateien.) Abb. 7: Der Editor von Sniff+ Weiterhin markiert der Editor Klassen-, Methoden- und Variablennamen sowie Kommentare und abstrakte Klassen farblich bzw. mit einem anderen Font. Der Programmierer kann so auf einer höheren Ebene als der einer Textdatei arbeiten. Er ist jedoch nicht, wie bei der Arbeit mit vielen syntaxgesteuerten Editoren, in seiner Freiheit eingeschränkt, den Quelltext frei zu formatieren oder auch über längere Zeit hinweg syntaktisch inkorrekten Quelltext zu bearbeiten. Sobald Änderungen des Quelltextes im Editor gespeichert werden, werden die Symbol­definitionen für den Editor und alle anderen Browser-Werkzeuge aktualisiert. Auch die Anzeige aller geöffneten Fenster wird sofort automatisch aktualisiert. Der Hierarchie-Browser stellt die Vererbungshierarchien graphisch dar. Mit einem Doppel­klick auf eine Klasse gelangt man zu ihrer Definition bzw. Implementation oder über das Menü in eine beliebige andere Komponente von Sniff+. Um die Zahl der angezeigten Klassen zu reduzieren, stehen mehrere Möglichkeiten zur Verfügung: Man kann eine Reihe von Klasse markieren und alle anderen ausblenden lassen, oder man kann die dargestellte Hierarchie auf die Ober- und Unterklassen einer bestimmten Klasse reduzieren lassen, an der man gerade interessiert ist. Zusätzlich besteht die Möglichkeit, die Anzeige auf bestimmte Unterprojekte zu reduzieren. Auch im Hierarchie-Browser sind abstrakte Klassen durch kursive Schrift hervorgehoben, da sie oft abstrakte Protokolle implementieren, über die Klassen miteinander interagieren. Abb. 8: Der Hierarchie-Browser von Sniff+ Der Class-Browser stellt alle Merkmale einer Klasse dar. Dabei können wahlweise alle Merkmale oder nur die in der Klasse selbst definierten Eigenschaften dargestellt werden. Wahlweise können auch nur ganz bestimmte Oberklassen aus dem (mit angezeigten) Vererbungsgraph ausgeblendet werden. Zu jedem dargestellten Merkmal wird die Klasse angezeigt, in der es definiert wurde. Weiterhin können die angezeigten Merkmale nach verschiedenen Kategorien (Methoden, Variablen, Konstanten etc.) ein- und ausgeblendet und mit regulären Ausdrücken weiter eingeschränkt werden. Einige Eigenschaften der angezeigten Merkmale werden visuell hervorgehoben (z.B. Sichtbarkeit, abstrakte Methode). Wahlweise werden auch die von dieser Klasse überladenen Eigenschaften der Oberklassen mit angezeigt. Abb. 9: Der Class-Browser von Sniff+ Der Symbol-Browser erlaubt es, nach den Definitionen bestimmter Symbole (Namen) über ganze Projekte hinweg zu suchen. Da der Symbol-Browser die Syntax von C bzw. C++ kennt, wird aber nicht auf Text-Ebene, sondern bereits auf der Ebene von Klassen- und Methoden­namen etc. gearbeitet. So kann der Symbol-Browser beispielsweise alle Methodennamen eines Unterprojekts darstellen, die mit dem Präfix "Create" beginnen. Um die Verwendung von Namen innerhalb des Quelltextes finden zu können, gibt es den Retriever. Er erlaubt die Suche nach regulären Ausdrücken über ein ganzes (Teil-)Projekt hinweg. Er ist dem Unix-Werkzeug grep jedoch dadurch überlegen, daß er die Syntax von C/C++ kennt und die Suche auf bestimmte syntaktische Konstrukte einschränken kann. Er wäre beispielsweise in der Lage, alle Zuweisungen auf mit dem Präfix "Window" beginnende Variablen zu finden. Die Extraktion der Informationen erfolgt mit einem sog. Fuzzy-Parser[6], so daß es nicht nötig ist, die Quelltexte zu compilieren, um sie browsen zu können. Mehr noch müssen die Quelltexte überhaupt nicht compilierbar sein, da der Fuzzy-Parser sich bemüht, auch aus Quelltexten mit syntaktischen Fehlern die Informationen über deren Struktur zu extrahieren. Auf diese Weise kann Sniff+ auch mit einer großen Zahl von Compilern eingesetzt werden, deren Syntax sich oft im Detail unterscheidet. Normalerweise wird das Fenster des jeweiligen Werkzeugtyps mit den neuen Informationen gefüllt, sobald man andere Informationen selektiert. Es besteht zusätzlich aber auch die Möglichkeit, Fenster als "frozen" zu markieren, so daß für weitere Sichten zusätzliche Fenster geöffnet werden. Die Stärke von Sniff+ besteht darin, daß man auf der Ebene von symbolischen Informationen und Konstrukten der Programmiersprache arbeiten kann, da alle Werkzeuge die Syntax der Programmiersprache kennen und die Arbeit mit ihr unterstützen. 5.4.   Funktionalität von Browsern Die folgende Tabelle zeigt die Funktionalität der verschiedenen Browser im Überblick:   short/flat ISE Eiffel 3 Visual C++ Sniff+ Vererbungs-Graph nein ja, baumartig (nur Ober- oder nur Unterklassen) ja, baumartig (nur Ober- oder nur Unterklassen) ja Darstellung von wiederholter Vererbung - nein (Klassenname taucht mehrfach auf) nein (Klassenname taucht mehrfach auf) ja Vererbungs-Graph filterbar - nein ja ja Benutzung nein ja nur für Funktionen und Methoden, nicht auf Klassen-Ebene ja (Retriever, Cross-Referencer geplant) Benutzung berücksichtigt Polymorphie nein nein nein nein Symbole nein nur zur aktuellen Klasse ja ja Symbole im Editor markiert nein nein ja ja Symbole filterbar nach Kategorien nein ja ja ja Symbole filterbar nach Wildcards nein nein ja (eingeschränkt, keine echten regulären Ausdrücke) ja muß Quelltext compilierbar (fehlerfrei) sein ja (implementations­abhängig) ja ja, muß sogar linkbar sein nein Aktualisierung der Datenbasis manuell (explizite Anforderung) automatisch, nach Speicherung der Änderungen beim nächsten Compilieren und Linken des Projekts (bis dahin inkonsistent) automatisch, nach Speicherung der Änderungen verschiedene Sichten gleichzeitig ja (mehrere Fenster bzw. Ausdrucke nötig) ja (sofern keine ungespeicherten Änderungen) nein ja Aktualisierung der verschiedenen Sichten manuell (explizite Anforderung) nein - automatisch beim Speichern der Änderung GUI nein ja ja ja Verfügbarkeit im Lieferumfang des Compilers im Lieferumfang des Compilers im Lieferumfang des Compilers muß extra erworben werden Projekt-Konzept nein ja ja ja untersuchte Version ISE Eiffel 2 (nach [Meyer 88]) ISE Eiffel 3 Visual C++ 1.0 Sniff+ 1.1 5.5.   Anforderungen an einen Eiffel-Browser Ein Eiffel-Browser sollte es dem Entwickler erlauben, auf einer möglichst hohen Abstraktions­ebene zu arbeiten. Wichtig ist die Visualisierung des Software-Designs und nicht die Implementierungsdetails in einer speziellen Sprache (vergl. [KilGryZül 93], S. 69). Im Sinne des Arbeitens auf möglichst hohen Niveaus wäre es wünschenswert, wenn der Browser auch die verwendeten Design-Pattern (vergl. [Gamma 92] und [Gamma 95]) darstellen könnte. Um auch größere Projekte bearbeiten zu können, ist es unbedingt notwendig, die dargestellte Informationsmenge filtern zu können. Hier bietet sich ein Filtern nach Kategorien (Klassen, Methoden, Methoden mit speziellen Eigenschaften) an. Weiterhin sollte es aber auch möglich sein, die dargestellten Symbole mit Wildcards zu filtern bzw. explizit anzugeben, welche Klassen z.B. in einer Vererbungshierarchie angezeigt werden sollen. Eins der wichtigsten Strukturierungsmittel in der objektorientierten Programmierung ist die Vererbung (auch wenn sie von verschiedenen Schulen unterschiedlich eingesetzt wird). Daher muß ein Browser für Eiffel die Vererbungs-Hierarchie möglichst flexibel darstellen können. Wünschenswert wäre auch die Darstellung, welche Klassen einander benutzen. Eine solche Darstellung ist aber nur aussagekräftig, wenn Polymorphie berücksichtigt wird. Da es aber erst zur Laufzeit feststellbar ist, welche Klassen wirklich benutzt werden, müßten alle möglichen Benutzungs-Beziehungen vom Browser dargestellt werden, was zu einer unübersichtlichen und damit entwerteten Darstellung führt (vergl. [Bischofberger 94a]). Es sollte möglich sein, mehrere Sichten auf den Quelltext gleichzeitig zu haben. Wichtig ist aber auch, daß diese bei Änderungen im Quelltext sofort (und automatisch !) aktualisiert werden. Auch ein noch so guter Browser wird nicht alle Fragen über den Quelltext auf einer abstrakten Ebene beantworten können. Daher sollte auch der Rückgriff auf den Quelltext mit einem integrierten Editor immer möglich sein. Aber auch im Editor sollte die bearbeitete Sprache z.B. durch Syntax-Highlighting (hervorgehobene Anzeige verschiedener syntaktischer Strukturen, z.B. Methodennamen, Kommentare etc.) unterstützt werden. Um den Browser von speziellen Eiffel-Implementationen unabhängig zu halten, muß er auch ein eigenes Projekt-Konzept haben. Zwar wurde von Meyer in der Sprachreferenz eine Beschreibungssprache für Eiffel-Universums vorgeschlagen (LACE), aber alle vorhandenen Implementationen haben eine eigene inkompatible Variante implementiert. Um aber die verwendeten Bibliotheksklassen finden zu können, muß der Browser den Umfang des Eiffel-Universums kennen, d.h. der Programmierer muß die Möglichkeit haben, alle zum Universum gehörigen Teile dem Projekt hinzuzufügen. Prinzipiell sollte eine möglichst flexible Handhabung möglich sein, denn die hier zu unter­stützende Tätigkeit ist sehr anspruchsvoll, und der Entwickler einer Browsers wird niemals alle möglichen Umgangsformen mit dem von ihm entwickelten Browser vorhersehen können. Der Benutzer sollte also dynamisch die dargestellten Informationen filtern und durchsuchen können.