CFD eine proprietäre Beschreibungssprache für komplexe Steuerelemente der Fujitsu Siemens Computers ServerView Suite

Transkript

1 Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Arbeitsgruppe Softwaretechnik Warburger Straße Paderborn in Kooperation mit Fujitsu Siemens Computers GmbH Abteilung Server Management Heinz-Nixdorf Ring Paderborn CFD eine proprietäre Beschreibungssprache für komplexe Steuerelemente der Fujitsu Siemens Computers ServerView Suite Studienarbeit zur Erlangung des Grades Bachelor of Computer Science von Christian Ikenmeyer Am Willnteich Paderborn vorgelegt bei Prof. Dr. Wilhelm Schäfer und Prof. Dr. Odej Kao Paderborn, den 29. September 2005

2

3 Eidesstattliche Erklärung Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe sowie ohne Benutzung anderer als der angegebenen Quellen angefertigt habe. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Die Arbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen. Paderborn, den 29. September 2005 Christian Ikenmeyer _ iii

4 iv

5 Danksagung An dieser Stelle möchte ich Fujitsu Siemens Computers dafür danken, dass mir alle benötigten Quelltexte und firmeninternen Informationen zur Verfügung gestellt wurden, um diese Arbeit erfolgreich abzuschließen. Ich hoffe, dass die hier erzielten Resultate in Kürze in das betriebliche Umfeld integriert werden und so zur effizienten Lösung von Problemen im Geschäftsalltag beitragen. v

6 vi

7 Inhaltsverzeichnis 1 Einführung Motivation Ziel der Arbeit Struktur der Arbeit Ist-Zustand der Sprache Umfeld Syntax und Semantik Beispiele Zusammenfassung der Probleme im Ist-Zustand Anforderungen an die neue Sprache Anforderungsliste Zusammenfassung der Anforderungen Konzeption der neuen Sprache EFD als XML-Derivat Die Extensible Markup Language (XML) XML-Derivate als Programmiersprache Grundsätzliche Designentscheidung Anforderungsgerechter Sprachentwurf Informelle Definition Einsatz der neuen Sprache im betrieblichen Umfeld EFD-Programme in der Laufzeitumgebung Anpassungen der EFD an das betriebliche Umfeld Zusammenfassung und Ausblick...38 Anhang...39 A.1 Das verwendete Tool JACCIE...39 A.2 Formale Sprachdefinition der neuen Sprache EFD...40 A.2.1 Reguläre Ausdrücke...40 A.2.2 Kontextfreie Grammatik...42 A.2.3 Attributierung für Kontextsensitivität...43 A.2.4 Übersetzen nach Java...53 A.3 Ergänzende Semantikdefinitionen...60 Literaturverzeichnis...67 Abbildungsverzeichnis...69 Inhalt der CD-Rom...70 vii

8 viii

9 1 Einführung 1.1 Motivation Programmiersprachen sollen helfen, Computer zu nutzen, um möglichst schnell und effektiv Lösungen für Probleme zu erhalten. Dabei können mit jeder Programmiersprache bestimmte Denkweisen des Programmierers eleganter und schneller umgesetzt werden als andere. Um ein Problem mit minimalem Aufwand zu lösen, muss die von der Sprache am besten unterstützte Denkweise zum Anwendungsgebiet des Problems passen. Die Sprache sollte also optimalerweise für diese Art von Problemen geschrieben sein. Da es nicht kosteneffizient ist, für jedes Problem eine eigene Sprache zu entwerfen, lohnt sich der Entwurf einer Sprache nur dann, wenn es viele ähnliche Probleme gibt, von denen jedes mit dieser neuen Sprache effizient gelöst werden kann. Diese speziellen Sprachen verlieren den Anspruch, universell auch außerhalb ihres Problembereichs gut einsetzbar zu sein, haben aber in ihrem Anwendungsgebiet einen erheblichen Vorteil gegenüber universellen Programmiersprachen. Ausgehend von einer speziellen Programmiersprache lassen sich dann spezielle Werkzeuge mit graphischer Benutzeroberfläche zum Erstellen von Programmen anfertigen. Dieser Aufwand ist bei einer durchdachten Sprache und bei kleinen Problemen in der Praxis jedoch meist nicht zu rechtfertigen. Ein Beispiel für eine solche spezielle Programmiersprache ohne eigene Entwicklungswerkzeuge ist die Common Figure Description (CFD) von Fujitsu Siemens Computers, eine firmeninterne Sprache zur Beschreibung von Prozessen zur Erzeugung von Steuerelementen. 1.2 Ziel der Arbeit Da sich die Anforderungen an die CFD im betrieblichen Umfeld stetig verändern, blieben auch Änderungen an der Sprache selbst nicht aus. Dieser Anpassungsprozess zog sich über Jahre hin und wurde leider auch von einigen Entscheidungen begleitet, die gravierende Mängel in die Sprache einfügten. Zum Beispiel entspricht die Ausführungsreihenfolge von Anweisungen nicht immer der Anordnung der Anweisungen im Quelltext, sondern beruht auf anderen nicht intuitiven Verfahren, die das Programmieren und die Fehlersuche sehr erschweren 1. Eine neue Sprache, die Enhanced Figure Description (EFD), soll auf Basis der CFD entworfen werden, mit dem Ziel, alle bekannten Mängel der CFD zu beheben und so wieder eine Sprache zu schaffen, die effizient im Anwendungsgebiet eingesetzt werden kann. Zusätzlich gehört zu dieser Arbeit auch die Entwicklung und Implementierung einer lauffähigen Umgebung für EFD-Programme, die in das betriebliche Umfeld von Fujitsu Siemens Computers integriert werden kann (ein Übersetzer oder ein Interpreter für die EFD). 1.3 Struktur der Arbeit In Kapitel 2 wird der Ist-Zustand der CFD dargestellt. Das spezielle Anwendungsgebiet bei Fujitsu Siemens Computers und die vorhandenen Probleme werden hier gezeigt. Kapitel 3 enthält die Anforderungen an die EFD, welche in Kapitel 4 zum Entwurf der EFD führen. Kapitel 5 zeigt an Quelltextbeispielen die Funktionalität von EFD-Programmen. In diesem Kapitel werden auch Möglichkeiten zur Anpassung der EFD beschrieben. Kapitel 6 fasst die Ergebnisse kurz zusammen und gibt einen Ausblick auf das weitere Vorgehen bis zum Einsatz der neuen Sprache bei Fujitsu Siemens Computers. 1 vgl. Kap. 2.2 Syntax und Semantik - 1 -

10 2 Ist-Zustand der Sprache In diesem Kapitel wird der Ist-Zustand der CFD im Unternehmen Fujitsu Siemens Computers dargestellt. In Kapitel 2.1 wird das Anwendungsgebiet der Sprache erläutert. Kapitel 2.2 widmet sich der Syntax und Semantik. In Kapitel 2.3 werden einige Beispiele mit CFD- Quelltext gebracht. Während der gesamten Darstellung des Ist-Zustandes wird immer wieder auf Probleme der derzeitigen Lösung hingewiesen, welche beim Entwurf der EFD behoben werden sollen. Diese werden in Kapitel 2.4 noch einmal kurz zusammengefasst. Wichtig für den Entwurf der neuen Sprache EFD sind aber auch Vorteile, welche die CFD gegenüber anderen Sprachen hat. Diese sollen durch den neuen Entwurf nicht verloren gehen Umfeld Der Interpreter der firmeninternen Sprache CFD ist eingebettet in eine Software, die selbst in das Softwarepaket ServerView Suite von Fujitsu Siemens Computers eingebettet ist. Die ServerView Suite dient der Überwachung von Hardwaresystemen in Netzwerken und stellt eine grafische Benutzeroberfläche für die Systemverwaltung zur Verfügung. Da sie eine Vielzahl von Hardwarekomponenten zu überwachen hat, muss die grafische Benutzeroberfläche eine nicht unerhebliche Anzahl verschiedener Grafiken verwalten, die zudem auch noch abhängig vom Gerätestatus der einzelnen Hardwarekomponenten sind. Zu diesem Zweck wurde die in die ServerView Suite eingebettete Software ImageBuilder entwickelt. Dies ist eine Software, welche die große Anzahl an verschiedenen benötigten Grafiken schnell und möglichst Speicherplatz sparend liefert und diese Grafiken zusätzlich mit Funktionalität zur Administration der Hardwarekomponenten versieht. Jedes Hardwaresystem wird in der ServerView Suite als ein solches Steuerelement angezeigt, welches sich aus einzelnen Untersteuerelementen hierarchisch zusammensetzt. Diese können wieder weitere Untersteuerelemente enthalten, u.s.w.. Sowohl grafische Darstellung als auch Funktionalität wird bei diesem modularem Aufbau auf das umfassende Steuerelement übertragen, so dass komplexe zusammengesetzte Steuerelemente entstehen, die vom ImageBuilder erzeugt werden. Zur Beschreibung dieser hierarchischen Struktur wird die CFD verwendet. Diese besitzt geeignete Mittel, um allgemein modularen Aufbau zu beschreiben. Die Programme werden von einem in den ImageBuilder eingebetteten Interpreter interpretiert. Allen Hardwarekomponententypen von Fujitsu Siemens Computers ist eindeutig ein Satz von CFD-Programmen zugeordnet, die in Abhängigkeit vom Status der Hardwarekomponente (intakt, überhitzt, etc.) und Bildschirmauflösung die grafische Darstellung und die Interaktionsmöglichkeiten des zugeordneten Steuerelements beschreiben. Die physisch vorgegebene Hierarchie der verschiedenen Hardwarekomponenten (ein Cluster hat Schränke, ein Schrank hat Einschübe,_u.s.w.) lässt sich in der CFD perfekt abbilden. Aufgrund der ständigen Erweiterung des Produktportfolios von Fujitsu Siemens Computers werden regelmäßig neue CFD-Programme geschrieben. Dies wird jedoch nicht immer von fertig ausgebildeten Programmierern erledigt, sondern unter anderem von Informatikern im ersten Semester oder auch von Designern, die wenig oder noch nie programmiert haben. Dementsprechend unkompliziert muss es sein, die CFD zu erlernen und mit der CFD zu programmieren. Dieses Problem bezeichne ich mit dem Begriff Designerproblematik. Kann eine Hardwarekomponente mit den geringen Mitteln der CFD nicht implementiert werden, so muss sich der Designer an die Verantwortlichen für CFD wenden, die daraufhin 1 vgl. Kap. 3.1 Anforderungsliste unter Funktionalität - 2 -

11 die Sprache um neue Möglichkeiten erweitern. Mit der wachsenden Zahl an Hardwarekomponenten und deren Sonderanforderungen in der Darstellung wurde die CFD jedoch sehr oft angepasst und der Sprachschatz der CFD ist stark gewachsen, so dass die Sprache nun nicht mehr einfach zu erlernen ist. Wegen der Designerproblematik wurde das Schreiben der CFD-Programme mittlerweile von Programmierern mit Erfahrung aus den Gebieten Java und CFD übernommen und selbst unter diesen findet sich niemand, der das komplette Funktionsspektrum der CFD beherrscht. Zusätzlich wurden aus Performancegründen Änderungen an der Sprache vorgenommen, die sie weiter verkomplizierten. Der Interpreter läuft unter anderem aufgrund dieser speziellen Anpassungen der CFD sehr effizient und kann Programme mit adäquater Geschwindigkeit ausführen, obwohl er in Java implementiert ist. Doch die Sprache ist in einem Zustand, in dem bei komplexen Programmen nur noch die Möglichkeit des Testens besteht, um Aussagen über die Korrektheit zu erhalten. Es existierte bis zu meiner Bachelorarbeit nicht einmal ein Dokument, das alle Möglichkeiten für syntaktische Strukturen komplett auflistet. Es ist wahrscheinlich, dass auch meine Nachforschungen nicht zu einer kompletten Beschreibung des Ist-Zustandes geführt haben und dass sich bei weiterem Suchen im spärlich dokumentierten Interpreter noch weitere Features finden lassen. Es wird von der EFD also erwartet, dass sie sehr leicht zu erlernen und zu beherrschen ist. Deshalb sollen dem Programmierer bei Fehlern ausführliche Fehlermeldungen gegeben werden. Zudem darf die Ausführung von EFD-Programmen nicht deutlich mehr Zeit brauchen als die Ausführung von gleichbedeutenden CFD-Programmen. 2.2 Syntax und Semantik Die Syntax der CFD ist nicht komplett formal beschrieben. Es gibt jedoch nur einen einzigen Interpreter, dessen Quellcode vorliegt (in Java geschrieben und in die ServerView Suite eingebettet). Anhand dieses Interpreters 1, einer veralteten Beschreibung 2 und mit Hilfe des Quelltextes vieler geschriebener CFD-Programme 3 kann man versuchen die Syntax und Semantik der Sprache zu identifizieren. Im Folgenden werden die Produktionen der CFD-Programme erzeugenden Grammatik aufgezählt und erläutert. Zudem werden sofort einige auffällige Probleme der Sprache angemerkt. Als Notation für die Grammatik wird die Erweiterte Backus Naur Form (EBNF) verwendet. Jedes Konstrukt der EBNF beschreibt eine Menge von Produktionen in Backus Naur Form (BNF). 1 [SNI04] 2 [FSC] 3 [SNI05] - 3 -

12 Im Einzelnen ist die EBNF wie folgt zu lesen 1 : EBNF-Konstrukt Bedeutung Gleichbedeutende BNF-Produktionen X ::= u (v) w Klammerung X ::= u Y w Y ::= v X ::= u [v] w Option X ::= u Y w Y ::= v ε X ::= u s* w Optionale Wiederholung X ::= u Y w Y ::= s Y ε X ::= u s+ w Wiederholung (mind. ein X ::= u Y w Vorkommen) Y ::= s Y s X ::= u (v s) w Wiederholung mit Trenner X ::= u Y w Y ::= v s Y v X ::= u (v1 v2) w Alternativen X ::= u Y w Y ::= v1 v2 Durch Hochkommata ' eingerahmte Zeichenketten sind Terminalsymbole (Terminale). Ein CFD-Programm erhält seine Eingaben über Umgebungsvariablen. Diese sind zum Beispiel: - Die Größe des Rechtecks, in das gezeichnet werden soll. - Der Status der Hardware, die dargestellt werden soll. - Die Umgebungsvariablen der Eltern-Hardwarekomponenten. - Die Liste der Kinder-Hardwarekomponenten, um diese mit einem CFD-Programm darzustellen (s.u. DataLines) - Ein Link zu einem speziellen Block, der ausgeführt werden soll (optional, s.u. HeaderIdentifier und DrawCfdWithAnchor ) Eine Liste der Variablen sei hier der Vollständigkeit halber angegeben. Die Bedeutung der verschiedenen Variablen ist hier nicht von Interesse. _CAGE, _SLOT, _CHANNEL, Status, Path, TreeName, TreeStatus, BaseType, InconsFlag, ErrorFlag, Children, HwAddress, OptionFlag, Index, Prefix, Suffix, OptionString, CfdFileName,RackName, RackType, RackPos Das Startsymbol der Grammatik ist CFD. Kommentare sind zeilenweise und werden mit # eingeleitet. Jedes CFD-Programm besteht aus einem oder mehreren Blöcken: CFD ::= ( Block )+ Jeder Block besteht aus einem Header und mehreren Zeilen. Jede Zeile ist entweder eine DataLine oder eine ClassLine. Jeder Header, jede DataLine und jede ClassLine dürfen im Programm nur genau eine Codezeile einnehmen. Unter Umständen werden Zeilen sehr lang und lassen sich nicht lesbar anordnen. Block ::= Header ( DataLine ClassLine )* 1 aus [Kas05i] Folie 211,

13 Wichtigste Bestandteile eines Headers sind die Eigenschaften Size und State. Es können optional ein HeaderIdentifier, ein ImageName und Options angegeben werden. In einem CFD-Programm wird immer nur maximal ein Block ausgeführt, und zwar der erste Block, bei dem ein durch Umgebungsvariablen gesetztes Rechteck (die Größe des Bereichs, auf dem gezeichnet werden soll) das Rechteck der Größe Size umschließen kann. Zusätzlich muss noch der Hardwarekomponentenzustand aus den Umgebungsvariablen den Anforderungen des State im Header genügen. Wenn der Programmierer also seine Blöcke ungeschickt im Programm anordnet, kommt es zu dem Effekt, dass die hinteren Blöcke niemals ausgeführt werden können, da über ihnen ein passender kleinerer Block steht. Falls ein Block x aufgrund eines anderen Blocks y niemals ausgeführt werden kann, so heißt der Block x dominiert durch den Block y. Der Block y heißt dominierender Block. Abbildung 2.1: Dominanz von Blöcken In Abbildung 2.1 sieht man das Problem deutlich. Sei hierfür angenommen, dass die Blöcke alle den gleichen State besitzen. Der Block mit der Größe 150 x 100 wird von den Blöcken der Größe 300 x 150 und 200 x 200 dominiert. Die restlichen Blöcke dominieren sich jedoch nicht. Ihre Umordnung untereinander führt wohl zu anderen Ergebnissen bei der Programmausführung, jedoch wird kein Block nutzlos. Zur Überprüfung, ob es eine falsche Anordnung gibt, ist bis jetzt keine automatisierte Möglichkeit vorhanden. Dies ist ein Problem, da die Sprache an dieser Stelle die Reihenfolge von Befehlen vorschreibt, falsche Reihenfolgen aber aber vom Programmierer nur schwer erkannt werden können. Der HeaderIdentifier dient dazu, den Block eindeutig als Einsprungadresse in das CFD-Programm zu identifizieren (bereitgestellt von der ClassLine DrawCfdWithAnchor s.u.). Es gibt die Möglichkeit, das CFD-Programm nicht den ersten passenden Block durchlaufen zu lassen, sondern direkt einen bestimmten Block. Dieser wird über den HeaderIdentifier angesprochen. Wenn man wissen möchte, ob direkt in ein CFD- Programm gesprungen werden kann, so bleibt einem nur die Möglichkeit, jeden Block einzeln nach seinem HeaderIdentifier zu untersuchen. Der ImageName legt das zu verwendende Hintergrundbild fest und die Options dienen dazu, die Eigenschaften des entstehenden Steuerelements anzupassen. Header ::= '[' [HeaderIdentifier ','] Size ',' State ']' [ImageName] [Options] - 5 -

14 In den Options kann zum Beispiel festgelegt werden, dass das Steuerelement auf Mausklicks überhaupt nicht reagiert ( {NoButton} ). Falls nicht das gesamte Steuerelement auf Mausklicks reagieren soll, kann die Fläche, die auf Mausklicks reagiert, über ButtonOptions angepasst werden. Mit ButtonLevel kann die reagierende Fläche nach vorne vor die Kind-Steuerelemente oder nach hinten hinter das Elternsteuerelement versetzt werden. Options::= '{NoButton}' ButtonOptions ButtonLevel ButtonOptions ::= '{ButtonOptions}' xpos ',' ypos ',' Width ',' Height ButtonLevel ::= '{ButtonLevel}' integer DataLines und ClassLines beschreiben Aktionen des Programms. Sie werden allerdings nicht von oben nach unten ausgeführt, sondern in jedem Block werden erst die ClassLines von oben nach unten ausgeführt und dann die DataLines. Die syntaktische Anordnung kann hier also die eigentliche Semantik verschleiern. Das Konzept der DataLines stellt die Kernfunktionalität der CFD dar. Eine DataLine beschreibt, mit welchem CFD-Programm die nächsten (den Anforderungen entsprechenden) Kind-Elemente dargestellt werden sollen. Solch ein Aufruf erzeugt pro passendem Kind ein weiteres Steuerelement im Steuerelement. Die LocationDescription beschreibt die Anforderungen, die an die Kind-Elemente gestellt werden, nämlich einen Hardwareadressfilter, der auf die Hardwareadresse des Kindes passen muss (s.u.). Position gibt die Position des ersten neuen Steuerelements im Steuerelement an, dx und dy geben an, um wie viele Pixel das nächste passende Steuerelement verschoben dargestellt wird. next gibt das CFD-Programm an, dass für jedes passende Kind aufgerufen werden soll. So entsteht die rekursive Verlinkung von CFD-Programmen zur Erstellung komplexer Steuerelemente. DataLine ::= '(' LocationDescription ')' Position ',' Size ',' dx ',' dy ',' next Die LocationDescription beschreibt einen Bereich von Hardwareadressen, den Hardwareadressfilter, in dem die Hardwareadresse des Kind-Elementes liegen muss, damit es angezeigt wird. LocationDescription ::= ( LocationRange ' ' ) LocationRange ::= '*' LocationRangeEnumeration LocationRangeEnumeration ::= LocationRangeEnumerationElement LocationRangeEnumerationElement ',' LocationRangeEnumeration LocationRangeEnumerationElement ::= integer integer '..' integer - 6 -

15 Bei den DataLines wurde zu Gunsten der Performanz folgende zusätzliche Regelung getroffen: Die LocationRange ganz links heißt Cage-Adressfilter. Die dazugehörige Zahl in der Hardwareadresse einer Komponente heißt Cage-Adresse. Wenn der Cage-Adressfilter eine Liste aus nur einer Zahl ist, so wird diese zwischengespeichert. Beim nächsten Auftreten einer DataLine mit einem Cage-Adressfilter, der eine Liste aus nur einer Zahl ist, die echt größer ist als die zwischengespeicherte Zahl, werden alle Kindelemente mit Cage-Adresse bis zur zwischengespeicherten Zahl aus der weiteren Behandlung ausgeschlossen. Weitere DataLines sehen diese Kindelemente nicht mehr und überspringen sie beim Adressfiltertest. Bei mehreren DataLines mit unterschiedlichen Adressfiltern sind die Reihenfolgen also nicht beliebig. Der Programmierer hat selbst darauf zu achten, die DataLines in der richtigen Reihenfolge aufzurufen. Eine automatisierte Überprüfung, ob die komplizierten Regelungen zur Reihenfolge bei einem Programm eingehalten wurden, gibt es nicht und selbst erfahrene CFD-Programmierer kommen bei manchen Anordnungen bei der Frage der Korrektheit ins Grübeln. Um den Sachverhalt verständlicher zu machen, folgt hier ein Beispiel: ( 2 1) 0, 0, 11, 11, -12, 0, ASPs.cfd ( 2 4) 0, 0, 11, 11, -12, 0, ASPs.cfd ( 2 2) 0, 0, 11, 11, -12, 0, ASPs.cfd (1,4 2,3) 0, 0, 11, 11, -12, 0, ASPs.cfd ( 4 2,3) 0, 0, 11, 11, -12, 0, ASPs.cfd (3,5 2,3) 0, 0, 11, 11, -12, 0, ASPs.cfd (2,5 2,3) 0, 0, 11, 11, -12, 0, ASPs.cfd Die ersten drei Zeilen bleiben von der Performance-Anpassung unberührt, da die Cage- Adresse nicht springt. Die 4. Zeile kann auch keinen Sprung erzeugen, da der Cage- Adressfilter aus einer Liste mit mehr als einer Zahl besteht. Ein Sprung geschieht erst in der 5. Zeile. Ab dann werden alle Kinder mit Cage-Adresse kleiner gleich 2 nicht mehr betrachtet. Deshalb wird zwar die 6. Zeile noch korrekt ausgeführt, die 7. Zeile jedoch nicht mehr. Laut Angaben von Fujitsu Siemens Computers bringt dieses Vorgehen einen Performance- Schub von ungefähr 50 % und kann deshalb nicht abgeschafft werden. Position ::= xpos ',' ypos Size ::= Width ',' Height HeaderIdentifier ::= String ImageName ::= String dx ::= integer dy ::= integer next ::= String xpos ::= integer ypos ::= integer Width ::= integer Height ::= integer State ::= String Zusätzlich zu den durch Hochkommata ' eingerahmten Zeichenketten sind auch integer und String Terminale, d.h. es gibt keine Produktion mit integer oder String auf der linken Seite. Für diese beiden Terminale gilt: integer Terminale sind Zeichenketten, die von Java in Integer-Klassen eingelesen werden können. String Terminale sind beliebige Zeichenketten. Es gibt kein Symbol, das die Zeichenketten (Integer oder Strings) vom Rest - 7 -

16 des Quellcodes abgrenzt. Die Kommata der Parameterlisten übernehmen diese Aufgabe. Zusätzlich gilt, dass nur das zum Terminal gehört, was zwischen dem ersten und letzten Zeichen steht, das kein Leerzeichen, Tabulator oder ähnliches ist. Dadurch ergeben sich Zeilen, die auf den ersten Blick nicht durchschaubar sind, wie etwa die folgende ClassLine: {Text} 0, 15, $Name$ $ScsiControllerSpeed$ Id: $ScsiControllerId$, Dialog, 12, (0,0,0) Das Erkennen der Literale ist wegen der fehlenden Markierungszeichen sehr schwierig. Um die 8 Literale im Beispiel deutlich zu machen, sind sie hier durch graue Hinterlegung hervorgehoben dargestellt: {Text} 0, 15, $Name$ $ScsiControllerSpeed$ Id: $ScsiControllerId$, Dialog, 12, (0,0,0) In String-Terminalen gibt es anders als in Integer-Terminalen die Möglichkeit über $<name>$ den Wert der Umgebungsvariablen <name> einzufügen. Im Quelltext sind Strings und Integer nicht voneinander zu unterscheiden. Der Interpreter arbeitet intern ausschließlich mit Strings. Die Syntax und Semantik des Nichtterminals ClassLine ist komplizierter. Der Grund für die Einführung der ClassLines wird passend beschrieben durch ein Zitat aus der Dokumentation der Java-Schnittstelle zu CFD: A hardcoded class is used to display parts of a CFD file that can not be displayed in the regular CFD grammar. 1 Wo die Funktionalität von CFD nicht ausreicht, wird also direkt auf bestimmte Java-Klassen und deren Funktionalität zurückgegriffen. Die ClassLines bieten diese direkte Schnittstelle zum Interpreter, der in Java geschrieben ist. Der Interpreter führt die gewünschte Funktionalität der Java-Klassen mit den übergebenen Parametern aus. Die einzelnen verfügbaren Klassen sind mit ihren Parameterlisten auch durchspezifiziert. Die Produktion die folgende Form. ClassLine ::= '{' ClassName '}' ( ClassLineArgument ',' ) [',' Condition] ClassLineArguments können zudem noch beliebig mit runden Klammern geklammert werden. Die Klammerung dient der Übersichtlichkeit und gruppiert zum Beispiel Parameter wie die RGB-Werte einer Farbe. Diese Klammerung sei erwähnt, findet sich jedoch nicht in der Produktion wieder, um Unübersichtlichkeit zu vermeiden. Die Klammern werden vom Interpreter nicht gelesen. Es muss also zum Beispiel nicht zu jeder öffnenden auch eine schließende Klammer geben, was zu Verwirrung und unleserlichem Quelltext führen kann. Optional haben ClassLines noch eine Bedingung Condition, welche für die Ausführung erfüllt sein muss. Condition ::= 'IF' SingleCondition (BoolConnection SingleCondition)* BoolConnection ::= ( 'AND' 'OR' ) Der Interpreter hält sich nicht streng an diese Syntax und wertet jede Zeichenkette, die nicht AND ist als OR. Diese Vorgehensweise kann nur als bedenklich eingestuft werden, denn wenn ein Programmierer beispielsweise ein exklusives Oder benutzen möchte, könnte er auf die Idee kommen, zu testen, ob der Interpreter einen Fehler bei der Verwendung von XOR meldet. Das tut er nicht, jedoch wird das Programm nicht wie gewünscht interpretiert. 1 [SNI03] - 8 -

17 SingleCondition ::= Operand Operator Operand Operand ::= integer String Operator ::= 'EQ' 'GT' 'LT' 'NEQ' 'IN' 'NIN' Alle Operatoren arbeiten mit ähnlichen Semantiken sowohl auf Integern als auch auf Strings. EQ ( equal ) ist der Vergleichsoperator. NEQ ( not equal ) seine Verneinung. GT ( greater than ) vergleicht, ob der linke Operand größer als der rechte ist (bei Strings lexikographisch wie in Java 1 ). LT ( less than ) vergleicht, ob der linke Operand kleiner als der rechte ist. IN untersucht, ob der linke Operand im rechten Operanden enthalten ist (der rechte Operand ist eine Liste: bei Strings ein String mit Semikolon ; getrennt und mit eckigen Klammern [_] geklammert, bei Integern genauso nur mit zusätzlicher Verwendung von zwei Punkten.. zwischen Integern). NIN ist die Verneinung von IN. Ein Beispiel für die Verwendung von IN bei Integern ist: {DrawCfd} 250, 150, 750, 550, not_supported.cfd, IF $../../../basetype$ IN [M400;M200R] AND $_CAGE$ IN [1;11;20..27] AND $_CHANNEL$ EQ 0 Zeilenumbrüche dienen hier der Lesbarkeit, dürfen aber im Quelltext nicht existieren. Unäre Operatoren sind nicht implementiert. Ein Negationsoperator fehlt, jedoch gibt es fast jeden Operator auch in seiner negierten Form. Die Auswertung eines booleschen Ausdrucks geschieht immer von links nach rechts, unabhängig von der natürlichen Präzedenz der Operatoren und und oder. Seien A, B, C und D Ausdrücke. Dann gilt in der CFD: A AND B OR C AND D entspricht A ( B ( C D) ) = ( A B) ( A C D) anstatt ( A B) ( C D) Diese Art der Ausdrucksauswertung hat zur Folge, dass aus der Syntax die Semantik nur noch sehr schwierig zu erschließen ist. In der Regel interpretiert ein gelernter Programmierer die Auswertung eines booleschen Ausdrucks auf den ersten Blick sogar falsch. Außerdem gilt, dass die Ausdrucksauswertung bei AND minimal 2 geschieht, d.h. der linke Operand wird ausgewertet, aber der rechte Operand wird nicht ausgewertet, wenn der linke schon als logisch falsch ausgewertet wurde. Entsprechendes gilt jedoch nicht für OR. Dies führt zu Ausdrücken, die in höchstem Maße unleserlich sind, da sich die Semantik hinter einem komplizierten, nicht intuitiven Regelwerk verbirgt. Da es mittlerweile sehr viele Klassen zur Verwendung in ClassLines gibt, werden sie in dieser Arbeit nicht alle behandelt 3. Einige der wichtigsten Klassen und ihre Bedeutung sollen aber kurz erläutert werden, um einen Eindruck vom Mechanismus der ClassLines zu erhalten: - Fill - Text - DrawCfd - DrawCfdWithAnchor - LoadMos 1 siehe hierfür [Sun03] 2 short-circuit evaluation, vgl. [Seb92] S. 247f 3 Der Vollständigkeit halber sind sie hier aufgelistet: CenteredText, CFDFileClassLine, CFDFileDrawLine, DrawCfd, DrawCfdWithAnchor, DrawComponent, DrawComponentWithoutButton, DrawImage, DrawLine, Fill, FillComplete, LoadMos, Slider und Text

18 Fill Parameter sind PositionX, PositionY, Width, Height, ColorR, ColorG und ColorB. Ein Aufruf füllt die Zeichenfläche mit einem farbigen Rechteck. ColorR, ColorG und ColorB beschreiben die Farbwerte im RGB-Modell, PositionX und PositionY beschreiben die Position der linken oberen Ecke und Width und Height bestimmen die Größe des Rechtecks. Text Parameter sind PositionX, PositionY, Text, Font, FontSize, ColorR, ColorG, ColorB. Optionale Parameter sind Style, BackgroundColor und BorderColor. Wird nur ein optionaler Parameter angegeben, so wird er als Style interpretiert. Zwei optionale Parameter als Style und BackgroundColor. Ein Aufruf schreibt den Text aus dem Text-Parameter an die Position, die durch PositionX und PositionY angegeben wird. Font und FontSize bestimmen Zeichensatz und Größe. ColorR, ColorG und ColorB beschreiben die Farbe des Textes im RGB-Modell. DrawCfd Parameter sind PositionX, PositionY, Width, Height und CfdFileName. An der durch PositionX und PositionY angegebenen Stelle auf der Zeichenfläche wird eine Zeichenfläche der Breite Width und Höhe Height bereitgestellt, in die das CFD-Programm mit dem Namen CfdFileName zeichnen kann. Dieses Programm wird daraufhin ausgeführt. Ist die Ausführung beendet, kehrt der Programmfluss in das aufrufende CFD-Programm zurück. DrawCfdWithAnchor Parameter sind PositionX, PositionY, Anchor und CfdFileName. Die Funktionsweise ist die von DrawCfd, jedoch wird im ausgerufenen CFD-Programm nicht der von der Größe her passende Block ausgeführt, sondern der durch Anchor direkt angesprungene Block. Einsprungadressen in CFD-Programme können im Header eines Blocks durch den HeaderIdentifier (s.o.) festgelegt werden. LoadMos ( Load Memory Objects ) Der erste Parameter ist der Klassenname einer Java-Klasse. Alle weiteren sind Namen von Variablen dieser Klasse. Durch den Aufruf von LoadMos wird überprüft, ob die darzustellende Hardwarekomponente von dem Typ ist, der durch den ersten Parameter spezifiziert wurde. Ist dies der Fall, so wird für jeden weiteren Parameter eine Umgebungsvariable eingeführt mit Namen des Parameters. So kann für ein Objekt des Typs Disk zum Beispiel WriteCacheOn abgefragt werden. Die Umgebungsvariable WriteCacheOn wird durch den Aufruf {LoadMos} Disk,WriteCacheOn zur Verfügung gestellt und ihr Wert kann mit $WriteCacheOn$ in Strings eingefügt werden

19 2.3 Beispiele Eine Zeile in einem CFD-Programm ist durchschnittlich etwa 45 Zeichen lang 1. Ein CFD- Programm hat eine durchschnittliche Dateigröße von 1607 Bytes (etwa 36 Zeilen) 2. Die Hälfte der Programme ist kleiner als 978 Bytes (etwa 22 Zeilen) 3. Es handelt sich also um viele sehr kleine Programme, die sich gegenseitig oft aufrufen, um ihre volle Funktionalität auszuüben. Auffällig bei vielen CFD-Programmen ist es, dass die einzelnen Befehle meist keine Wechselwirkungen untereinander haben. Es können neue Befehle hinzukommen und alte weggenommen werden, ohne bestehende Befehle in ihrer Semantik zu verändern. Somit verhält sich CFD in diesem Punkt vollkommen anders als zum Beispiel Java, wie folgendes Java-Beispiel zeigt: Integer i = new Integer (1); verdopple(i); System.out.println(i); In Java gehören üblicherweise mehrere Befehle zusammen, um einen Programmablauf zu beschreiben. Im Beispiel lassen sich die ersten beiden Zeilen nicht löschen ohne Fehler hervorzurufen. Wenn in CFD-Programmen jedoch Wechselwirkungen vorliegen, so sind diese oft nicht sofort ersichtlich, wie es bei den bereits erwähnten Performanzanpassungen der DataLines der Fall ist. Zusätzlich zu dieser Unabhängigkeit der Anweisungen untereinander sind viele Anweisungen oft auch unabhängig von den Eingabeparametern des CFD-Programms, denn Parameterlisten bestehen häufig vollständig aus Literalen. 1 Schätzwert zur Verdeutlichung der Dateigrößen 2 [SNI05] 3 [SNI05]

20 Die folgenden Beispiele dienen der Verdeutlichung der Probleme der CFD. Ein Unterstrich _ am Ende einer Zeile bedeutet, dass der Zeilenumbruch im Programm nicht existieren darf, hier aber der Lesbarkeit halber eingefügt wurde. Nach einem Unterstrich wird die Fortsetzung der Zeile eingerückt dargestellt. Einige Stellen im Programm sind mit Zahlen markiert, um im weiteren Text darauf zu referenzieren. Dies sind Teile des Original-Quellcodes eines typischen CFD-Programms aus dem Einsatz in der Praxis: [750,550,*] {DrawCfd} 0, 0, 750, 550, $../basetype$.cfd {DrawCfd} 250, 150, 750, 550, not_supported.cfd, _ IF $../../basetype$ IN [M600;M600R;M200;PP400E;PP400RE;PP200RE;_ PP600RE;PP200;PW650;PW650D;PW850;PW850D;PW900D;PW900E;PW1500;_ PW1500E;PW1500D; PCI-Disk_Box;PW250;PW250D;PW450;PW450D;PW450Q;_ PW450QD;PW400P;PW400PD] AND $_CAGE$ IN _ [1;11;20..27;64..96; ; ] {DrawCfd} 250, 150, 750, 550, not_supported.cfd, _ IF $../../../basetype$ IN [M600;M600R;M200;PP400E;PP400RE;PP200RE;_ PP600RE;PP200;PW250;PW250D;PW450;PW450D;PW450Q;PW450QD;PW400P;_ PW450PD] AND $_CAGE$ IN [1;11;20..27] {DrawCfd} 250, 150, 750, 550, not_supported.cfd, _ IF $../../../basetype$ IN [M400;M200R] AND $_CAGE$ IN _ [1;11;20..27] AND $_CHANNEL$ EQ 0 {DrawCfd} 250, 150, 750, 550, not_supported.cfd, _ IF $../../../basetype$ IN [PW2500;PWHPC2500] _ (1) AND $_CAGE$ IN [ ] AND $_CHANNEL$ EQ 1 # Rm 400 PCI / EISA Boards [480,80,*] {DrawImage} 10, 17, PciScsi_64_64.gif {Fill} 83, 3, 92, 74, (160,160,160) {Fill} 178, 3, 92, 74, (0,0,0) {Fill} 179, 4, 90, 72, (255,255,255) {Fill} 273, 3, 92, 74, (0,0,0) {Fill} 274, 4, 90, 72, (255,255,255) (2,3 * 0..2) 84, 4, 90, 72, 95, 0, $basetype$.cfd # Rm 400e PCI / EISA Boards [378,38,*] {DrawImage} 70, 3, PciScsi_32_32.gif (* *) 110, 0, 140, 38, 0, 0, Rm400Scsi.cfd # Rm 400e PCI / EISA single controller boards [350,80,*] {DrawCfd} 0, 0, 350, 80, Color.cfd # show the position for the OLR [LEVEL2SIZE,201,201,*] {DrawCfdWithAnchor} 0, 0, LEVEL2SIZE, $../basetype$.cfd (2)