Embed Size (px)
Citation preview
jonas bucher
B E N U T Z E R S P E Z I F I Z I E RT E C O D E G E N E R I E R U N G I NM O S A I C
B E N U T Z E R S P E Z I F I Z I E RT EC O D E G E N E R I E R U N G I N M O S A I C
jonas bucher
Diplomarbeit
Februar 2011
Jonas Bucher: Benutzerspezifizierte Codegenerierung in Mosaic, Diplomar-beit, © Februar 2011
hochschule:Ostfalia, Hochschule für angewandte Wissenschaften - HochschuleBraunschweig/Wolfenbüttel -
fakulät / studiengang:Informatik, Medieninformatik
erstprüfer:Prof. Dr. Jürgen KreysigOstfalia, Hochschule für angewandte Wissenschaften - HochschuleBraunschweig/Wolfenbüttel -
zweitprüfer:Dipl.-Ing. Stefan KuntscheTechnische Universität Berlin
A B S T R A C T
This diploma thesis describes the development of an extension for thesoftware tool MOSAIC that enables the user to generate user specifiedcode. The tool enables the user to solve symbolic equations directly orto translate them into a fixed set of programmatic specified languages.To fill the gap resulting from a limitation of fixed defined languagespecifiactions, MOSAIC is extended with a new view - the „LanguageSpecification Editor“. With this nearly arbitrary mathematical langua-ges can be specified and used for code generation.
This work describes the following points:
• Introduction to formal languages und code generation.
• Analysis of the syntax and language structure of computer alege-bra systems.
• Approach and implementation of the language specification me-thodology.
• Development of the Swing-based GUI in Netbeans.
• Development the XML-based format for saving the languagespecifications.
Z U S A M M E N FA S S U N G
Die vorliegende Diplomarbeit beschreibt die Entwicklung einer Er-weiterung für das Softwaretool MOSAIC zur benutzerspezifiziertenCodegenerierung. Das Tool ermöglicht es, symbolische Gleichungendirekt zu lösen, oder sie in eine feste Anzahl von programmatischspezifizierten Sprachen zu übersetzen. Um die Nachteile von festenSprachspezifikationen zu beheben, wird MOSAIC um eine Ansicht, den„Language Specificator Editor“ erweitert. Mittels dieser neuen Ansichtist es möglich, nahezu beliebige mathematische Sprachen zu spezifizie-ren und zur Codegenerierung zu nutzen.
Die Arbeit beschreibt die folgenden Punkte:
• Einführung in formale Sprachen und Codegenerierung.
• Analyse der Syntax und Sprachelemente von Computeralgebra-systemen.
• Entwurf und Implementierung der der Spezifikationsmethodik.
• Entwicklung der Swing-basierten GUI in Netbeans.
• Entwicklung des XML-basierten Formates zur Speicherung derSprachspezifikationen.
v
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbst-ständig und ohne Benutzung anderer als der angegebenen Hilfsmittelangefertigt habe. Die aus fremden Quellen direkt oder indirekt über-nommenen Gedanken sind als solche kenntlich gemacht. Die Arbeitwurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungs-behörde vorgelegt und auch noch nicht veröffentlicht.
Braunschweig, den 14. Februar 2011
I N H A LT S V E R Z E I C H N I S
1 Einleitung 1
1.1 Problemstellung und Motivation 3
1.2 Übersicht 4
2 Grundlagen 5
2.1 Formale Sprachen 5
2.1.1 Formale Sprachen in der Computeralgebra 6
2.1.2 XML 6
2.2 Codegenerierung 8
2.2.1 Codegenerierung für mathematische Modelle 10
2.3 MOSAIC 11
2.3.1 Technologien 11
2.3.2 Arbeitsablauf 12
2.3.3 Modulare Bestandteile 13
2.4 NetBeans 14
2.4.1 GUI-Builder 14
3 Spezifizierung mathematischer Sprachen 17
3.1 Analyse 17
3.1.1 Allgemeine Spracheigenschaften 18
3.1.2 Mathematische Operationen 19
3.1.3 Strategien zur Übersetzung von Variablennamen 20
3.1.4 Code-Bestandteile 20
3.2 Das XML-Datei-Format 22
4 Das Codegenerierungs-Modell 23
4.1 Anforderungen 23
4.2 Das Block-Handle-Modell 24
4.3 Beispiel 26
5 Software-Integration 29
5.1 Das MOSAIC-Framework 29
5.2 Die Language-Specification-Komponenten 30
5.2.1 Codegenerierung mit dem Block-Handle-Modell 30
5.2.2 GUI 32
5.2.3 Language Specifiaction Editor 32
6 Zusammenfassung und Ausblick 39
literaturverzeichnis 41
vii
A B B I L D U N G S V E R Z E I C H N I S
Abbildung 1 MOSAIC im Evaluation-Editor - Ansicht der sym-bolischen Gleichungen 2
Abbildung 2 Überblick der verschiedenen Codegenerierungs-varianten 9
Abbildung 3 Arbeitsablauf in MOSAIC - Technische Sicht 12
Abbildung 4 Arbeitsablauf in MOSAIC - Logische Sicht 12
Abbildung 5 Bestandteile einer Notation (Quelle: MOSAIC UserGuide[Kun10]) 13
Abbildung 6 Ausschnitt des GUI-Builders von NetBeans 16
Abbildung 7 Struktur der Sprachspezifizierungs-Logik 17
Abbildung 8 Wortbildungselemente am Beispiel des WortesTextdatei 18
Abbildung 9 Schritte der Modelltransformation 24
Abbildung 10 Gruppierung von Code-Bestandteilen in Blöcke 25
Abbildung 11 Benutzerspezifzierte Codegenierung für einen Co-deabschnitt in MATLAB mittels des Block-Handle-Modells 27
Abbildung 12 Klassendiagramm der Block-Struktur 31
Abbildung 13 Ansicht des Editors der allgemeinen Spracheigen-schaften 33
Abbildung 14 Ansicht des Editors der mathematischen Opera-tionen 34
Abbildung 15 Ansicht des Editors der Variablennamen-Übersetzungsstrategie 35
Abbildung 16 Ansicht des Editors der Code-Bestandteile 36
Abbildung 17 Ansicht des Editors zum Endergebnis 37
L I S T I N G S
2.1 Beispiel: Aussagen in einer formale Sprache (MATLAB) 5
2.2 Beispiel eines XML-Dokuments . . . . . . . . . . . . . . . 7
3.1 Die Sprachspezifiaktions-Datei im XML-Format . . . . . 22
4.1 Beispiel eines XML-Dokuments . . . . . . . . . . . . . . . 28
viii
1E I N L E I T U N G
In der vorliegenden Arbeit soll die benutzerspezifizierte Codegenerie-rung für das Software-Tool MOSAIC entwickelt werden.
Das Web-basierte Computeralgebrasystem (CAS) MOSAIC wurde imFachgebiet Dynamik und Betrieb technischer Anlagen (DBTA) der Tech-nischen Universität Berlin, unter Leitung von Herrn Stefan Kuntscheentwickelt. Es entstand im Kontext der Systemverfahrenstechnik undsoll eine benutzerfreundliche mathematische Modellierungsumgebung,basierend auf aktuellen Internetstandards anbieten. Des Weiteren soll esdie Kooperation von Arbeitsgruppen fördern, die mit unterschiedlichenSoftwareinfrastrukturen arbeiten (vgl. Website1). Modeling SimulationApplication and Interaction for Chemical Processes (kurz MOSAIC) istkeine, wie der Name nahe legen könnte, auf den verfahrenstechnischenBereich beschränkte Modellierunsumgebung. Das Tool kann in allenwissenschaftlichen Disziplinen Anwendung finden, in denen mathema-tische Berechnungen in Form symbolischer Gleichungen durchgeführtwerden. Der Name wurde übernommen von einem gleichnamigenund ebenfalls am DBTA entwickelten Vorgänger, von Rodolphe Zerry[Zer08]. Das MOSAIC auf dem diese Arbeit basiert, ist eine Neuent-wicklung und basiert lediglich auf den Grundgedanken des Vorgängers.
MOSAIC ermöglicht es mit symbolischen Gleichungen (siehe Ab-bildung 1) zu arbeiten - Symbolisch meint analog zur Darstellungvon Mathematik in der Literatur. Die Gleichungen können zu Glei-chungssystemen zusammengefasst werden und diese im beschränk-ten Umfang programmintern gelöst und grafisch dargestellt werden.Seine Hauptanwendung besteht jedoch in der Transformation dieserGleichungssysteme in andere mathematische Sprachen, also in aus-führbaren Quellcode anderer computerbasierter Rechenprogramme.In diesen anderen Software-Tools, kann dann die Lösung, mittels desvon MOSAIC generierten Quellcodes, berechnet werden. Der Trans-formationsprozess wird im Weiteren als Codegenerierung bezeichnet.Bekannte Vertreter von computerbasierten Rechenprogrammen sindbeispielsweise MATLAB, Scilab, Mathematica und gPROMS.
In Domänen in denen MOSAIC Anwendung finden kann, wie z.B.der Verfahrenstechnik, werden neben den bereits genannten Tools auchweitere eingesetzt. Die Verwendung dieser Vielzahl von Tools ist begrün-det durch problemspezifische Vor- und Nachteile, personenspezifischenPräferenzen sowie stark variierende Lizenzkosten. In jedem dieser Toolswird ein mathematisches Problem in einer eigenen Sprache formuliert.Auch wenn die Unterschiede zwischen den verschiedenen Sprachender Tools oft marginal sind, ist der Quellcode der verschiedenen Toolsuntereinander inkompatibel. Wird ein mathematisches Problem also ineiner Sprache modelliert, ist es an das dazugehörige Tool gebunden.
1 http://www.mosaic-modeling.de
1
2 einleitung
Abbildung 1: MOSAIC im Evaluation-Editor - Ansicht der symbolischen Glei-chungen
1.1 problemstellung und motivation 3
Um diese Problematik zu verdeutlichen, wird das Ganze anhanddes folgenden Beispiels dargestellt. Zwei Ingenieure arbeiten an derLösungen des gleichen mathematischen Problems und verwenden dazujeweils ein anderes CAS-Tool. Um sich austauschen zu können, wäre essehr hilfreich die Problemmodellierung vergleichen zu können. DieseModellierung unterscheidet sich allerdings in der verwendeten Sprache,also im Tool-spezifischen Quellcode. Der Leser mag nun annehmen,dass die beiden sich im Vorfeld auf die Verwendung eines Tools einigenkönnten. Aufgrund der erwähnten Faktoren, oder auch bei unvorher-gesehen Kooperationen, ist dies in der Praxis oft nicht der Fall. DieseLücke kann durch Benutzung von MOSAIC geschlossen werden. Diebeiden Ingenieure modellieren dabei in symbolischer Art und Weiseund vergleichen auch ihr Modell auf dieser Ebene. Die abschließendenBerechnung findet dann nach der Codegenerierung, wieder in der je-weils vorhandenen Infrastruktur (dem jeweiligen Tool) statt.
Diese Diplomarbeit wurde mit dem Textsatzprogramm LaTeX unddem classicthesis2-Paket von André Miede erstellt. Der typografische Stilvon classicthesis ist inspiriert von dem Buch The Elements of TypographicStyle [Bri02]. Als Texteditor diente die freie Software TeXnicCenter.
1.1 problemstellung und motivation
Für MOSAIC soll die benutzerspezifizierte Codegenerierung entwickeltwerden. Wie eingangs ist erwähnt, ist die Anzahl der zur Codegenerie-rung zur Verfügung stehenden Sprachen beschränkt. Die Spezifikationder Sprachen geschieht bislang programmatisch durch die MOSAIC-Entwickler. Ziel der Arbeit ist es, dass der Benutzer selbst eigene ma-thematische Sprachen spezifizieren und sie anschließend zur Codege-nerierung nutzen kann. Auch ein nachträgliches Editieren soll möglichsein. Der sogenannte „Language Specification Editor“ (kurz LangSpecEditor) soll eine benutzerfreundliche grafische Benutzeroberfläche (GUI)bieten, die eine möglichst freie Spezifikation von mathematischen Spra-chen ermöglicht. Diese selbst erstellen Spezifikationen sollen dann zurCodegenerierung genutzt werden können. Hieraus ergeben sich diefolgenden Punkte:
• Analyse der bestehenden mathematischer sprachspezifikations-und codegenerierungs-Methodiken.
• Entwicklung eines Dateiformates zur Speicherung von Sprachs-pezifikationen.
• Entwurf eines Modells zur (freien) Sprachspezifizierung.
• Implementierung des Sprachspezifikations-Editors in MOSAIC,was die Anbindung an den bestehenden Mechanismus der Code-generierungu beinhaltet.
Nach Umsetzung der Arbeit kann ein MOSAIC-Benutzer seine sym-bolisch formulierten mathematischen Probleme, in die Sprachen vonnahezu allen auf dem Markt verfügbaren computerbasierten Rechen-programme transformieren (Einschränkung: Es können nur Sprachenspezifiziert werden, in denen Gleichungssysteme explizit definierbar
2 http://www.miede.de/index.php?page=classicthesis
4 einleitung
sind!). Hat ein Benutzer eine neue Sprachspezifikationen erstellt, kanner darüber hinaus in effizienter Weise selbst Modifikationen vornehmenund Derivate erzeugen. Auch ein Austausch von Sprachspezifikationenmit anderen Nutzern wird dadurch möglich
1.2 übersicht
Die vorliegenden Arbeit vermittelt dem Leser zunächst das technologi-sche Grundlagenwissen. Anschließend wird er hin zur Modellierungund programmatischen Umsetzung des LangSpec Editors geführt.
In Kapitel 2 werden die Grundlagen zu formalen Sprachen undder Codegenerierung vermittelt. Es folgt eine Einführung in das ToolMOSAIC und die Entwicklungsumgebung, mit der es programmiertwurde. In Kapitel 3 werden mathematische Sprachen auf ihre Syntaxund Bestandteile untersucht und darauf aufbauend, ein Dateiformatzur Speicherung dieser entworfen. Im folgenden Kapitel 4 werdendie Hauptbestandteile einer Sprache durch ein implementierungsu-nabhängiges Modell spezifizierbar gemacht. Kapitel 5 beschreibt dieRealisierung des gesamten Sprachspezifizierungs-Konzepts in MOSA-IC. Abschließend fasst Kapitel 6 die erreichten Ergebnisse zusammenund beschreibt mögliche Weiterentwicklungen.
2G R U N D L A G E N
In diesem Kapitel wird eine Einführung in die Grundlagen der formalenSprachen gegeben und darauf aufbauend der XML-Standard betrachtet.Anschließend wird der Begriff der Codegenerierung erläutert unddie verschiedenen Varianten erklärt. Im Weiteren wird MOSAIC mitseinen Funktionen und ihm zu Grunde liegenden Konzepten vorgestellt.Abschließend wird auf die zur Entwicklung des Language SpecificationEditors verwendeten Entwicklungsumgebung eingegangen.
2.1 formale sprachen
„Eine formale Sprache stellt eine zumeist mit Hilfe der natürlichen Spra-che festgelegte künstliche Sprache dar“ [KNG08]. Sie dienen der exak-ten Beschreibung zum Umgang mit Zeichenketten. Damit ermöglichensie eine Definition von zulässigen Ausdrücken und deren Bedeutung(vgl. [AE78]). Anwendungen finden sie neben der Informatik beispiels-weise auch in der Modellierung von Geschäftsprozessen und sonstigenFeldern, in denen die Zeichen eindeutige Bedeutungen zugeordnetwerden müssen. Beispiele für formal definierte Sprachen sind Program-miersprachen wie Java, C++ und Fortran, Auszeichnungssprachen wieHTML, XML und LaTeX, oder auch die grafische ModellierungsspracheUML.
So wie in der natürlichen Sprache deutsch, besitzen auch Aussagenin einer formalen Sprache eine Bedeutung - Die sogenannte Semantik.Im Gegensatz zu der möglichen Mehrdeutigkeit einer Aussage in einernatürlichen Sprache, ist diese in einer formalen Sprache eindeutig.Ein Beispiel hierfür ist der Programmcode in Listing 2.1. Bei einerAusführung des Quellcodes auf einem PC mit installierter MATLAB-Software, wird die Maschine dazu angewiesen, auf der Ergebnissegrafisch darzustellen. Welche Arten von Aussagen in Sprachen, oderbezogen auf das Beispiel, in MATLAB noch existieren, wird durchderen Syntax festgelegt. Die Syntax definiert den Aufbau von gültigenAusdrücken, basierend auf einer Menge Zeichen. Eine gültige Aussagewird als wohlgeformt bezeichnet. Die Definition der Syntax von formalenSprachen wird durch ein Regelsystem festgelegt, dass durch einenSyntaxgraphen dargestellt werden kann.
Listing 2.1: Beispiel: Aussagen in einer formale Sprache (MATLAB)
1 %
2 % Printing function
3 %
4 function[] = displayResults(X_ITER)
5
6 % print variable values to display
7 disp([’e0_x = ’, num2str(X_ITER(1))]);
8 disp([’e0_y = ’, num2str(X_ITER(2))]);
9
10 end
5
6 grundlagen
2.1.1 Formale Sprachen in der Computeralgebra
Auch in Computeralgebrasystemen werden formale Sprachen zur Mo-dellierung der zu lösenden Problemstellung verwendet. Diese ähnelngängigen Programmiersprachen, sind aber weniger mächtig. Man könn-te sie als auf Mathematik spezialisierte Programmiersprachen bezeich-nen, oft auch noch mit einem speziellem Fokus auf ein mathematischesTeilgebiet.
Die Syntax von Aussagen in den Sprachen von CAS ähnelt sich oft.Damit einher geht auch meist (nicht immer!) eine semantische Überein-stimmung. So ist beispielsweise der Additionsoperator in den meistenSprachen durch das gleiche Zeichen (+) spezifiziert. Untersucht mandiese Sprachen auf ihre Bestandteile, findet man die folgenden Gruppenvon Aussagen:
• Rechenoperatoren
• Deklaration und Verwendung von Variablen, Gleichungen, . . .
• Lösungsfunktionen
• Aufrufe zur (grafischen) Darstellung
• Allgemeine Anweisungen (Berechnungsgenauikeit, systemspezfi-sche Anweisungen, . . . )
• Kommentare
Eine detaillierte Ausführung zur Konstruktion von gültigen Aussagen,die vorhergehend Sprach-Bestandteile genannt wurden, findet manmeist in dem zugehörigen Handbuch des jeweiligen CAS.
2.1.2 XML
Die Extensible Markup Language (XML) ist eine vom W3C spezifizierteAuszeichnungssprache, die 2008 in der fünften Ausgabe herausgebenwurde. Das W3C ist ein Gremium, dass es sich zur Aufgabe gemacht,Standards für Internettechnologien zu spezifizieren (vgl. Website1). Zuden bekannten Spezifikationen zählen beispielsweise: SVG, HTML undDOM. Des Weiteren zählt auch die SGML (Standard Generalized MarkupLanguage) dazu, von der XML eine abgeleitete Untermenge ist. XMLwurde dazu entworfen, Daten in strukturierter Form zu speichern unddabei unabhängig von Soft- und Hardware zu sein. Die Trennung vonDaten und ihrer Darstellung ist dabei ein wichtiger Grundgedanke. Wiedie in einer XML-Datei gespeicherten Daten später dargestellt werden,obliegt dem Anwender bzw. dessen Software.
Ein XML-Dokument ist hierarchisch aufgebaut und setzt sich zu-sammen aus Inhalt und Markup (Auszeichnungselemente). Der Inhalt istdabei meist reiner Text, kann aber auch aus Binärdaten bestehen. DasMarkup strukturiert und beschreibt den Inhalt dabei gleichzeitig. DieSpezifikation des W3C macht keinerlei Vorgaben über die Namen vongültigen Markup-Elementen. Diese, im weiteren XML-Elemente genannt,werden selbst erstellt und erweitern damit jedes mal die Sprache (dt.
1 http://www.w3.org/Consortium
2.1 formale sprachen 7
erweiterbare Auszeichnungssprache). In Listing 2.2 ist ein Beispiel für einXML-Dokument zu sehen. Es speichert Informationen über die vor-handenen Bücher eines Buchladens - Anders formuliert, es dient alsDatencontainer.
XML-Elemente werden durch Tags realisiert. Ein Tag besteht aus inspitzen Klammern eingeschlossenem Text (<beispielTag>). Ein solchesXML-Element kann neben dem Inhalt auch Attribute mit Attributwer-ten enthalten (<beispielTag bspAttributID="42">).
Aufgebaut ist eine XML-Datei wie folgt:
1. (Optionale) XML-Entitäten (ermöglichen das Einbinden von an-deren XML-Dokumenten oder z.B. wiederkehrende Inhalte durchein eigens definiertes Element zu ersetzen).
2. Notwendige XML-Deklaration (<?xml version="1.0"?>). Diesekann als weitere optionale Attribute noch eine Angabe zur Zei-chenkodierung (encoding="UTF-8") und einen Verweis auf eineDokumenttypdefinition (DTD) beinhalten (im Beispiel ist diesnicht der Fall (standalone="yes")).
3. Mindestens das Wurzelelement, gefolgt von optionalen Verarbei-tungsoptionen und optionalen Kommentaren.
Listing 2.2: Beispiel eines XML-Dokuments
1 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
2 <bookstore>
3 <book category="SCIFI">
4 <title lang="en">The Hitch-Hikers Guide To The Galaxy
</title>
5 <author>Douglas Adams</author>
6 <year>1985</year>
7 <price>29,99</price>
8 </book>
9 <book category="CHILDREN">
10 <title lang="en">Harry Potter</title>
11 <author>J K. Rowling</author>
12 <year>2005</year>
13 <price>29.99</price>
14 </book>
15 <book category="WEB">
16 <title lang="de">Einstieg in XML: Aktuelle Standards:
XML Schema, XSL, XLink (Galileo Computing)</title>
17 <author>Helmut Vonhoegen</author>
18 <year>2009</year>
19 <price>34,90</price>
20 </book>
21 </bookstore>
Bevor auf eine Softwareanwendung mit einem XML-Dokument arbeitenkann, sollte zunächst dessen Wohlgeformtheit überprüft werden. Dieseist gegeben, wenn:
8 grundlagen
• Alle vorhandenen Elemente korrekt verschachtelt sind. Das be-deutet, dass jedes geöffnete Element auf der selben hierarchischenEbene auch wieder geschlossen werden muss - Bevor also einnächstes Eltern- oder Geschwisterelement auftaucht.
• Jedes nicht leere Element einen StartTag und EndTag besitzt (imBsp.: <year>1985</year>).
• Sämtliche (optional vorhandenen) Attribute eines Elements un-terschiedliche Namen besitzen. Außerdem muss deren Wert inHochkommata eingeschlossen sein (Im Bsp.: <category=SCIFI>).
• Genau ein Wurzelelement vorhanden ist (im Bsp.: <bookstore>).
Neben der Prüfung auf Wohlgeformtheit existiert noch eine weitereÜberprüfungsmethode - Die Validierung. Ist ein Dokument valide, so istes gleichzeitig auch wohlgeformt. Die Wohlgeformtheit ist Vorrausset-zung für eine Validität. Da jegliche vorkommenden Elemente in einemXML-Dokument selbst definiert sind, muss auch spezifisch dafür eineÜberprüfungsmechanismus entwickelt werden. Eine für die meistenüberschaubaren Projekte ausreichende Methode, stellt die Überprüfungper DTD dar. Soll ein Dokument in komplexerer Art und Weise über-prüft werden, geschieht dies durch die (meist aufwendige) Definitioneiner Schemadatei. Diese ermöglicht komplexere Beschreibungen desInhaltes der XML-Dokumente und damit der Vorschriften für Elementeund Attribute.
Das Document Object Model (DOM) ist in diesem Zusammenhangeine weitere relevante W3C-Spezifikation. Sie legt eine Schnittstelleund damit einen standardisierten Zugriff auf XML-Dokumente fest.Das Dokument wird dabei als Baumstruktur repräsentiert und istdynamisch les- und editierbar. Die DOM-Schnittstelle ist in vielengängigen, für das Internet relevanten Programmier- und Skriptsprachenimplementiert.
2.2 codegenerierung
Der Prozess der Codegenerierung bezeichnet eine Transformationsme-thodik, die dem Zweck dient Quellcode zu generieren. Das Generat,also das Ergebnis einer Codegenerierung ist meist ausführbarer Quellco-de einer Programmiersprache, oder Quellcode einer anderen formalenSprache. Die Transformation ist also je nach Anwendungsdomäne, eineÜbersetzung in eine andere Sprache oder eine andere Repräsentationinnerhalb der Ausgangssprache. Die Quelle ist hierbei ebenso in Codein einer formalen Sprache, wie das Ergebnis. Beide Seiten können auchauch in Form eines (formalen) Diagramms spezifiziert sein. Ein Bei-spiel hierfür ist ein UML-Diagramm, dass selbst Ausgangspunkt einerCodegenerierung sein kann, dass aber auch ausgehend vom Quellcodegeneriert werden kann (Reverse Engineering). Ein Beispiel für eine textu-elle formale Quelle, ist ein MathML-Code. In MOSAIC nutzt dies alsGrundlage zum mathematischen Problemformulierungen, für die dannCode generiert werden kann. Die formale Beschreibung einer gesamtenSoftware, also die Spezifikation eines Modells, von dem ausgehendausführbarer Quelltext generiert werden kann, ist zentraler Bestandteilder modellgetriebenen Softwareentwicklung (MDSD).
2.2 codegenerierung 9
Die Vorteile der Codegenerierung sind in einer höheren Quellcode-Qualität und einer Produktivitätssteigerung des Softwareentwicklungs-prozesses begründet [Her03]. Diese Qualität lässt sich u.A. an der Wie-derverwendbarkeit und der Wartbarkeit des Quellcodes messen. Durcheine einmal spezifizierte Quelle, entsteht ein jederzeit reproduzierbaresGenerat. Sollen Anpassungen an diesem Ergebnis vorgenommen, oderFehler korrigiert werden, kann dies in effizienter Weise durch Modifika-tion der Quelle erreicht werden. In diesem Zusammenhang sei auch dassogenannte Templating erwähnt. Ein Template ist ein Gerüste für einenProgramm-Baustein. Ein solcher Baustein dient als Ausgangspunktfür eine Codegenerierung. Das Templating ermöglicht die genanntehohe Wiederverwendbarkeit von bereits existierenden Bausteinen zurCodegenerierung. Dies geschieht durch Anpassung dieser Bausteineals Grundlage für neue Programmbestandteile.
Die Abbildung 2 zeigt einen schematischen Überblick über verschie-denen Varianten der Codegenerierung. Im wesentlichen kann zwischenzwei verschiedenen Ansätzen unterschieden werden. Es gibt zum einenden vollautomatisiert gesteuerten Generierungsprozess und zum ande-ren, den durch einen Benutzer gesteuerten, also manuellen Weg. In derautomatisierten Variante wird die Transformation durch einen Benut-zer oder ein System ausgelöst und findet ohne weiteren Eingriff statt.Beispiele hierfür sind Präprozessoren in Programmierumgebungen,die ein Syntax-Highlighting sowie eine syntaktische Fehlerkorrekturermöglichen. Des Weiteren existiert in Java das Konzept der Annota-tionen, durch die unter anderem eine Daten-Persistierung (dauerhafteSpeicherung) durchgeführt werden kann. Der Programmierer anno-tiert hierbei Bestandteile des Quellcodes und die Umgebung generiertvollautomatisiert während der Kompilierung, den zur Persistierungnötigen Quelltext.
Abbildung 2: Überblick der verschiedenen Codegenerierungsvarianten
10 grundlagen
Die manuell gesteuerte Codegenerierung ist eine händisch durch-geführte Methode, die von einem Benutzer durch Programmierung,oder mittels Benutzung einer Software durchgeführt wird. Ein Beispielhierfür ist der später detaillierter erläuterte GUI-Builder in NetBeans.Der Builder ermöglicht es dem Programmierer mittels einer GUI vorde-finierte Bausteine auszuwählen, für die dann automatisiert Quellcodegeneriert wird. Er kann hierbei hierbei manuell Einstellungen vorneh-men. Diese manuell getroffenen Einstellungen wirken sich dann aufden generierten Quellcode aus. Das kann beispielsweise die Auswahleiner Hintergrundfarbe sein.
Dem weiteren Verlauf der Arbeit liegt die manuell gesteuerte Code-generierung zugrunde, die durch einen Benutzer ausgelöst wird undauf formalen Codequellen basiert - Die benutzerspezifizierte Codegene-rierung.
2.2.1 Codegenerierung für mathematische Modelle
Auf dem derzeitigen Markt existiert eine Vielzahl von Softwaretools,die basierend auf formalen Quellen Code generieren. Interessant fürdiese Arbeit sind jedoch ausschließlich Tools, bei denen ein Modell inverschiedene Zielcodes transformiert werden kann. Ein weitere undwichtige Einschränkung für die zu betrachtenden Tools ist, dass derZielcode durch den Benutzer selbst spezifiziert werden kann. Der Ziel-code soll dabei durch ein weiteres Modell beschrieben werden, einsogenanntes Metamodell. Ein Modell ist eine Abstraktion eines Originals.In einem Metamodell ist das Original der Bestandteil einer Modellbil-dung (vgl. [Sta74]). Anders gesagt wird mit einem Metamodell durchVerwendung der Bestandteile des Originales, ein weiteres Modell er-zeugt.
Das kommerzielle CAS Maple erfüllt die zuvor definierten Kriterienund wird stellvertretend betrachtet. Neben einigen bereits vordefinier-ten Sprachen ist es in Maple auch möglich, mathematische Modelledurch in benutzerspezifizerte Sprachen zu übersetzen. Dazu kann einebereits definierte Sprache erweitert, oder von Grund auf neu spezifiziertwerden. Maple übersetzt den Code eines vorhandenen Modells in einensogenannten Intermediate Code. Von diesem Code ausgehend findet dieÜbersetzung in andere Sprachen statt. Der Intermediate Code ist einevereinfachte baumartige Darstellung des ursprünglichen mathemati-schen Modells. Um eine neue Sprache zu spezifizieren, existiert eineSprache, mit der die Transformation in eine andere Sprache beschriebenwird. Der Ablauf besteht zusammengefasst aus den folgenden Punkten:
1. Übertragung des (symbolischen) Modells in das Tool.
2. Interne Transformation des Modells in ein weiteres Modell (Zwi-schenmodell).
3. Erstellung eines Metamodells zur Erlangung des gewünschtenZielmodells. Anders formuliert; Spezifizierung der Transforma-tionen in die Zielsprache, ausgehend vom Metamodell.
2.3 mosaic 11
2.3 mosaic
In symbolischer Form modellierte mathematische Modelle durch Code-generierung in die Sprachen anderer mathematischer Rechenprogram-me zu übersetzen - Das ist die für dieser Arbeit relevante Funktionalitätvon MOSAIC. In der Entwicklung der Software stand die Modulari-tät der Bestandteile, aus denen sich ein mathematische formulierteProblemstellung zusammensetzt im Vordergrund. So besteht beispiels-weise ein Gleichungssystem zunächst einmal aus Gleichungen. DieseGleichungen können sich wieder aus Variablen, Parametern und Funk-tionen zusammensetzen. Sämtliche der erwähnten Komponenten einesGleichungssystems werden in MOSAIC getrennt behandelt und sindund damit modular vorhanden. Dadurch entsteht eine hohe Wieder-verwendbarkeit aller Komponenten. Es werden nachfolgend die zumEinsatz kommenden Technologien, der Arbeitsablauf daran anknüp-fend die Funktionalitäten von MOSAIC erklärt.
2.3.1 Technologien
MOSAIC wurde mit Java in NetBeans entwickelt. Es verfolgt das Kon-zept Software as a Service (SaaS) und benötigt zur Benutzung einenJava-fähigen Webbrowser (Mozilla Firefox, Microsoft Internet Explorer,Apple Safari, . . . ) sowie eine installierte Java-Laufzeitumgebung (JRE 6,Update 22). Neben der aus diesem Konzept resultierenden Plattformu-nabhängigkeit, ist hierdurch auch eine Benutzung mittels sogenannterThin-Clients möglich. Um Zugang zu erlangen, wird ein Benutzerkontobenötigt. Die Speicherung der erzeugten Daten erfolgt Server-seitigunter dem jeweiligen Benutzerkonto. Auch der gewollte Austausch vonDaten ist durch diese Server-basierte Struktur möglich.
Die Abbildung 3 zeigt den Arbeitsablauf in MOSAIC aus technischerSicht. Zur Eingabe von mathematischen Modellen, bzw. Modellbe-standteilen wird in MOSAIC eine TeX-basierte Sprache verwendet. DieSyntax dieser Sprache kann dem, auf der MOSAIC-Website verfüg-baren User-Guide [Kun10] entnommen werden. Zum Speichern dereingegebenen mathematischen Modelle wird eine eigens entwickel-te Variante von MathML (Mathematical Markup Language) eingesetzt.MathML ist eine aus XML abgeleitet Sprache, die sich selbst wieder-um aus zwei Teilsprachen besteht. Das Presentation-MathML und dasContent-MathML. In der eigens entwickelten Variante wurde diesebeiden vereinigt. Presentation-MathML dient hauptsächlich der Dar-stellung mathematischer Ausdrücken und Content-MathML wurde zurBeschreibung deren Struktur entworfen. Die Vereinigung ermöglicht es,mathematische Ausdrücke eindeutig zu beschreiben und darzustellen.So ist es in MOSAIC möglich, beispielsweise eine Gleichung in derselben Datei eindeutig in zu spezifizieren selbige auch zur gerendertenDarstellung zu nutzen. Mit gerendert ist hierbei die symbolische Dar-stellung des Content-MathML gemeint, die auch von vielen gängigenWeb-Browsern unterstützt wird.Im weiteren Verlauf auf Abbildung 3 wird eine der Literatur entnom-mene Problemstellung nach Modellierung in MOSAIC mittels Codege-nerierung in eine Zielsprache transformiert. Dort kann sie dann danngelöst werden. Dieser Schritt ist Gegenstand der nachfolgenden Kapitel.
12 grundlagen
Abbildung 3: Arbeitsablauf in MOSAIC - Technische Sicht
2.3.2 Arbeitsablauf
Dieser Abschnitt gibt einen Überblick über die Schritte, die zur Mo-dellierung einer mathematischen Problemstellung in MOSAIC nötigsind. Die eingeführten Begriff werden im darunter folgenden Abschnitterklärt. In Abbildung 4 ist schematisch dargestellt. Der Arbeitsablaufbesteht aus den Schritten:
1. Notationen für alle vorkommenden Symbole erstellen.
2. Gleichungen erstellen.
3. Funktionen erstellen, falls benötigt.
4. Gleichungen, eventuell vorhandene Funktionen und weitere Glei-chungssysteme zu einem Gleichungssystem zusammenführen.
5. Evaluation erstellen. Hier findet die Modellierung des zu lösendenProblems statt.
6. Codegenerierung zur abschließenden Berechnung auf der Ziel-plattform.
Abbildung 4: Arbeitsablauf in MOSAIC - Logische Sicht
2.3 mosaic 13
2.3.3 Modulare Bestandteile
Die GUI von MOSAIC besteht aus drei Hauptkomponenten (sieheAbbildung 1). In der Editor-Bar am linken Rand sind sämtliche verfüg-baren Editoren aufgelistet. Das Content-Panel zeigt den jeweils aktivenEditor an und mittels des oben stehenden File-Panels, werden erzeug-te Daten und Änderungen an solchen gespeichert. Es folgt nun einekurze Vorstellung der Editoren, die zur Erzeugung der hier relevantenBestandteile eines mathematischen Modells in MOSAIC nötig sind (vgl.[Kun10]). Kurz deshalb, denn die ausführlich Analyse der aufgeführtenBestandteile erfolgt in ??.
Notations
Ein Notation weist den Symbolen die in einem mathematischen Modellvorkommen eine Bedeutung zu. Diese Bedeutung wird für jedes Symboldurch einen kurze Beschreibung vorgenommen. Eine Notation ist somitimmer auf ein konkretes Modell bezogen. In MOSAIC muss aus diesemGrunde jede Gleichung, Funktion und jedes Gleichungssystem eineNotation benutzen. Die folgenden Arten von Symbolen sind vorhanden(vgl. Abbildung 5):
• Base Names
• Superscripts
• Subscripts
• Indices
Abbildung 5: Bestandteile einer Notation (Quelle: MOSAIC UserGuide[Kun10])
Equations
Eine Equation ist eine Gleichung die mindestens aus einer Beschreibungbesteht und eine Notation benutzen muss. Des Weiteren kann eineGleichung eine Parameter List benutzen.
Equations Systems
Equations Systems sind Gleichungssysteme in denen keinerlei spezifi-sche Werte festgelegt werden. Die geschieht erst in einem späterenSchritt, beim Erstellen einer Evaluation. Ein solches Gleichungssystemwird durch Zusammenführung von Equations, Functions und weiterenEquation Systems erstellt.
14 grundlagen
Functions
Eine Function hat in MOSAIC definierte Eingabewerte und einen Aus-gabewert, die durch Variablen spezifiziert werden. Da eine Functionunabhängig von der Notation des Equations System in dem sie verwendetwird ist, müssen die Ein- und Ausgabevariablen explizit den korespon-dierenden Variablen des Equations System zugewiesen werden (mittelsKonnektoren).
Evaluations
Eine Evaluation dient der Modellierung eines Gleichungssystemes. Siestellen eine Instanzierung des zuvor noch allgemein modellierten Glei-chungssystems dar. Mit Hilfe einer Evaluation wird ein Problem voll-ständig modelliert und für die Berechnung, sprich Codegenerationverfügbar gemacht. Es müssen dazu Designvariablen klassifiziert undWertzuweisungen für sie vorgenommen werden. Maximale Indexwertemüssen festgelegt und die geratenen Werte für die auch zu klassifizie-renden Iterationsvariablen festgelegt werden.
2.4 netbeans
Die NetBeans IDE ist, wie bereits Namen erkennbar, eine integrierte Ent-wicklungsumgebung (Integrated Development Environment, kurz IDE)die von der Oracle Corporation (ehemals Sun Microsystems) entwickeltwird. Das Open-Source-Projekt wurde in Java und auch hauptsächlichfür dieses entwickelt, unterstützt aber weitere Sprachen wie beispiels-weise C++ und PHP. Die IDE gehört zu den größten und weit ver-breitetsten im Bereich der Java-Entwicklung und besitzt viele Features.Dazu zählen:
• Zahlreiche Werkzeuge für Java-EE-Entwicklung.
• Unterstützung bei Erstellung UML-Diagrammen, inklusive Rever-se Engineering.
• Entwicklung von RCP-Anwendungen (eigenständige Anwendun-gen die auf gezielte ausgewählte Techniken der IDE aufbauen).
• GUI-Builder (ist Gegenstand des nächsten Unterkapitels).
Die aktuelle Version (derzeit 6.9.1) ist unter http://netbeans.org zufinden.
2.4.1 GUI-Builder
GUI-Builder sind Softwaretools die einen Programmierer bei der Erstel-lung von grafischen Benutzeroberflächen unterstützen. UmfangreichereGUIs von heutigen Java-Anwendungen werden zumeist mit solchenBuildern erstellt. Sie bieten durch das direkt ersichtliche Endergebniseinen hohen Vorteil bezogen auf die Entwicklungsdauer. Dies wird un-ter anderem dadurch erreicht, das ein Programmierer sich die wenigertief die dahinter stehenden Technologien einarbeiten muss. KomplexeOberflächen mit Fenstern, Auswahlmenüs und Tabellen können miteinem GUI-Builder aus vorgefertigten Bausteinen zusammengestelltwerden. Dies kann dabei meist ohne das schreiben einer einzigen ZeileQuellcode geschehen. Um eine so erstellte GUI mit der Programmlogik
2.4 netbeans 15
zu verbinden, bietet eine Editor meist weitere Hilfestellungen an.
Der GUI-Builder von NetBeans gehört zu dessen Basiskomponentenund trägt die Bezeichnung Swing GUI Builder (vormals Matisse GUIBuilder). Er bietet aber auch Java-AWT-Bausteine und weitere Kompo-nenten für beispielsweise Java-Persistenz-Anwendungen an. Er bestehtaus einen grafischen Editor mit vier Fenstern:
• Design-Editor
• Palette
• Properties
• Inspector
Im Hauptfenster, dem Design-Editor, wird die zu erstellende grafischenOberfläche modelliert. Diese wird zusammengestellt aus den Elemen-ten die in der Palette zur Verfügung stehen. Dies geschieht per Drag andDrop (ziehen und fallenlassen. Hinzugefügte Elemente können nach Se-lektion mithilfe des Properties-Fensters konfiguriert werden. In diesemFenster können weitere Konfigurationen eines Elementes vorgenom-men werden. Dazu zählt beispielsweise das Eventhandling, mit demsich Aktionen wie das Verhalten bei Mausklicks steuern lassen. Einenhierarchischen Überblick über die erstellte Oberfläche bietet das Inspec-tor-Fenster an.
Die Abbildung 6 zeigt GUI-Builder von NetBeans beim Editiereneines Unter-Panels von MOSAIC. Ein Panel ist eine grundlegende Fläche,auf der weitere Elemente angeordnet werden können. In der Abbildungist ein Button selektiert. Links im Inspector-Fenster ist zu sehen, dassder Button neben dem Panel platziert ist. Auf der rechten Seite, direktneben dem Hauptfenster sind im Properties-Fenster die für den Buttoneinstellbaren Attribute zu sehen. Am äußeren Rand zeigt die Palettedie per Drag and Drop hinzufügbaren Elemente an.
16 grundlagen
Abbildung 6: Ausschnitt des GUI-Builders von NetBeans
3S P E Z I F I Z I E R U N G M AT H E M AT I S C H E R S P R A C H E N
In diesem Kapitel werden zunächst die Bestandteile von mathemati-schen Sprachen untersucht. MOSAIC unterstützt bereits die Codege-nerierung für viele Sprachen. Deren Spezifizierung ist Grundlage derAnalyse. Aufbauend auf den daraus gewonnen Komponenten, wirdeine XML-Datei-Format zur strukturierten Spezifizierung von mathe-matischen Sprachen erstellt.
3.1 analyse
Die Syntax der in MOSAIC bereits zur Codegenerierung zu Verfügungstehenden Sprachen, ist programmatisch im Quelltext von den Entwick-lern spezifiziert worden. Dort existiert eine abstrakte Spezifikation fürSprachen im Allgemeinen, von der der sich konkrete Sprachen ableiten.In der Abbildung 7 wird dies dargestellt.
Abbildung 7: Struktur der Sprachspezifizierungs-Logik
Die abstrakte Sprachspezifikation beinhaltet bereits die, zur vollständi-gen Spezifizierung einer Sprache notwendigen Bestandteile sind. Dadiese Spezifikation abstrakt ist, müssen beim Erstellen einer neuenSprache die abstrakt vorhanden Bestandteile implementiert werden.Diese Bestandteile können vier Kategorien eingeteilt werden - Allge-meine Spracheigenschaften, mathematische Operationen, Strategien zurÜbersetzung von Variablennamen und die Definition des eigentlichenZielcodes. Diese Kategorien werden in den folgenden Unterabschnittengenauer analysiert.
Um die Bestandteile mathematische Operationen benennen zu kön-nen, werden die Begriffe Affix, Prefix, Infix und Suffix eingeführt. Inder Abbildung 8 werden diese veranschaulicht. Die Begriffe entstam-men der Linguistik und werden dort Wortbildungselemente genannt.Der Affix ist zur Spezifikation von mathematischen Operationen nichtrelevant, ist aber im Umgang mit Variablennamen von Bedeutung.
17
18 spezifizierung mathematischer sprachen
Abbildung 8: Wortbildungselemente am Beispiel des Wortes Textdatei
3.1.1 Allgemeine Spracheigenschaften
In MOSAIC müssen bei der Spezifikation einer Sprache einige Ent-scheidungen getroffen werden. Diese sind von zentraler Bedeutungauf programmatischer Ebene, da sie z.B. durch das Einbinden einesInterfaces realisiert werden. Eine wichtige Entscheidung ist die Fest-legung auf den Typ der Gleichungssysteme. Intern sind für die un-terschiedliche Typen, jeweils andere (Java-)Methoden zuständig. Überdie Rückgabewerte dieser Methoden wird auf die Bestandteile derGleichungssysteme zugegriffen. Ähnlich verhält es sich mit der Unter-stützung direkter Funktionen. Ist die Unterstützung gewünscht, sinddiese durch entsprechende Methoden verfügbar. Die erwähnten undandere zu spezifizierende Eigenschaften werden nun in drei Kategorienaufgelistet:
Sprach-Einstellungen
• Unterstützung direkter Funktionen
• Benutzung von analytischen Derivativen
• Unterscheidung zwischen Groß- und Kleinschreibung (case sensi-tivity)
Gleichungssystem-Typen
• Nicht-lineare algebraraische Gleichungen (NLE)
• Gewöhnliche Differentialgleichungen (ODE)
• differential-algebraischen Gleichung (DAE)
Zahlen-Einstellungen
• Globaler Pre- und Suffix
• Erzwingen von Fließkommadarstellung
3.1 analyse 19
3.1.2 Mathematische Operationen
Eine mathematische Operation besteht aus einem Operator und Ope-randen. Der Operator schreibt dabei vor, wie mit den Operanden zuverfahren ist. Eine Operation setzt sich dabei aus bis zu fünf Bestand-teilen zusammen. Das sind ein oder zwei Operanden und ein bis dreiBestandteile, die die Operation spezifizieren. In der Mathematik werdenOperation mit ihren Bestandteile n-Stellige Verknüpfungen genannt,wobei n die Anzahl der Operanden angibt. Eine Sprachspezifikation inMOSAIC spezifiziert die Operationen der Grundrechenarten sowie dieelementaren mathematischen Funktionen. Diese sind ein- bis zweistelli-ge Verknüpfungen. So könnte die in einem CAS-Tool beispielsweise dieAddition wie folgt definiert sein: add(1,2). Die Additions-Operationbesteht dabei beiden Zahlen 1 und 2 (Operanden) und restlichen Be-standteilen der zweistelligen Verknüpfung add( , ).
In MOSAIC sind die Operationen in der Sprachspezifikation als (Java-)Methoden realisiert. Eine Methoden erwartet dabei als Eingangspa-rameter die Operanden. Spezifiziert wird die Operation durch denRückgabewert der Methoden. Dazu werden die Bestandteile der Ope-rationen mit den Operanden konkateniert. Nachfolgend werden dieOperationen mit zwei Operanden aufgelistet:
Grundrechenarten
• Addition
• Subtraktion
• Multiplikation
• Division
Elementare mathematische Funktionen
• Potenzfunktionen
• Radizierung
Operationen mit nur einem Operanden:
weitere Elementare mathematische Funktionen
• Exponentialfunktion
• Natürlicher Logarithmus
• Sinus-Funktion
• Cosinus-Funktion
Zudem werden an dieser Stelle noch die Strukturierungszeichen aufge-listet, da sie als strukturierende Operation mit einem Operator aufge-fasst werden kann.
Strukturierungszeichen
• Klammern
20 spezifizierung mathematischer sprachen
3.1.3 Strategien zur Übersetzung von Variablennamen
Variablen besitzen einen Namen und einen Wert und können einem Na-mensraum zugeordnet sein. In der symbolischen Darstellung (vgl. Ab-bildung 5) kann der Namen höher- und tiefergestellte Zeichen (Super-und Subskript) beinhalten. Wenn diese symbolische Darstellung inQuellcode übersetzt werden soll, muss aus der 2-dimensionalen Dar-stellung eine 1-dimensionale werden. Um den Variablennamen aberzu erhalten, können die einzelnen Namensbestandteile mithilfe vontrennenden Zeichen konkateniert werden. Alternativ kann die Über-setzungsstrategie des globalen Indexes verwendet werden. Dabei wirdzwar der Name nicht durch den Verbunde seinen ursprünglichen Be-standteile eindeutig identifiziert, sondern durch eine fortlaufende Num-mer. Da i.d.R. eine Variable nicht aus einer alleinstehende Zahl bestehenkann, wird diese mit einem zu spezifizierenden Prefix und/oder einemSuffix konkateniert.
Bei der Variablennamen-Übersetzungsstratgie werden die zu tren-nenden Bestandteile durch einen Infix spezifiziert. Nachfolgend derenAuflistung:
Variablennamen-Strategie
• Namesraum zum Basisnamen
• Führendes Superskript
• Führendes Subskript
• Führender Indexname
• Indexnamen zum Indexwert
• Variablennamen umgebender Affix (optional)
Des Weiteren kann der gesamte Namen noch von einem Pre- und Suffixumgeben werden. Da sich der Namen selbst schon aus den aufgeführtenBestandteilen zusammensetzt, werden diese hier als Affixe bezeichnet.
Weitere Bestandteile der Variablennamen-Strategie
• Variablennamen umgebende Affixe (optional)
3.1.4 Code-Bestandteile
In diesem Unterabschnitt werden die restlichen Bestandteile einerSprachspezifikation in MOSAIC betrachtet. Diese sind von zwei zuvorerläuterten Faktoren abhängig, dem Typ Gleichungssystems und derEntscheidung ob direkte Funktionen unterstützt werden. Je nach Typdes Gleichungssystems liegen unterschiedliche Arten von Variablenund Gleichungen vor. Sämtliche Spezifikation von beispielsweise Kom-mentaren, Darstellungsanweisungen und Lösungsaufrufen, also dieeigentliche Spezifikation der Syntax einer zu spezifizierenden Sprache,wird im nachfolgenden Kapitel gesondert behandelt. Hier werden nurdie Bestandteile des eigentlichen Gleichungssystems betrachtet.
3.1 analyse 21
Es folgen die Bestandteile eines Gleichungssystems in Abhängigkeitdes Typs. Jedes dieser Bestandteile setzt sich wiederum aus eigenenBestandteilen zusammen, die mit angegeben werden.
Gleichungssystem-Typ: NLE
• Variablen (Namen, Werte, Anzahl)
• Parameter (Namen, Werte, Anzahl)
• Differentialvariable (Name, Startwert, Endwert)
• Algebraische Gleichungen (Werte, Anzahl)
Gleichungssystem-Typ: ODE
• Explizite Zustandsvariablen (Namen, Initialwerte, Anzahl)
• Parameter (Namen, Werte, Anzahl)
• Differentialvariable (Name, Startwert, Endwert)
• ODE-Gleichungen (Werte, Anzahl)
Gleichungssystem-Typ: DAE
• Implizite Zustandsvariablen (Namen, Initialwerte, Anzahl)
• Explizite Zustandsvariablen (Namen, Initialwerte, Anzahl)
• Parameter (Namen, Werte, Anzahl)
• Differentialvariable (Name, Startwert, Endwert)
• Algebraische Gleichungen (Werte, Anzahl)
• ODE-Gleichungen (Werte, Anzahl)
Soll die Verwendung von direkten Funktionen unterstützt werden, müs-sen diese spezifiziert werden. Eine direkte Funtion besteht aus einemAufruf und einer Implementierung. In beiden Teilen sind Variablenund Parameter verfügbar. Sie bestehen im Detail aus folgenden zuspezifizierenden Bestandteilen:
Unterstützung direkter Funktionen
• Funktionsaufruf (Name, Ausgabevariablenname)
Aufruf-Variablen (Namen, Anzahl)
Aufruf-Parameter (Namen, Anzahl)
• Funktionsimplementierung (Name, Wert, Ausgabevariablenname)
Eingabe-Variablen (Namen, Anzahl)
Bibliotheks-Parameter (Namen, Anzahl)
22 spezifizierung mathematischer sprachen
3.2 das xml-datei-format
Der Abschnitt zeigt die Umsetzung der zuvor gefundenen Bestandteilein Form einer XML-Struktur. Diese Bestandteile sind in vier Haupt-gruppen eingeteilt worden. Die Gruppierung ist in der XML-Strukturübernommen worden. Als Dateinamenserweiterung wurde die Bezeich-nung .moslsp gewählt, wobei davon die erste Hälfte für MOSAIC stehtund der zweite für Language Specification.
Das Listing 3.1 zeigt exemplarisch eine gekürzte und minimale Ver-sion einer MATLAB-Sprachspezifikaton. Es fehlen dort die restlichenOperatoren und der gesamte Inhalt des FullCode-Elements (Zeile 36),zu Spezifikation die Grundlagen im nachfolgenden Kapitel erarbeitetwerden.
Listing 3.1: Die Sprachspezifiaktions-Datei im XML-Format
1 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
2 <LangSpecDef langname="user defined matlab"
langversion="1.0">
3 <GlobalSettings CaseSensitive="true"
GlobalFunctionsSupported="false"
UseAnalyticDerivatives="false">
4 <UniqueNamingIndexSeparator/>
5 <SystemType>NLE</SystemType>
6 <NumberSettings ForceFloatingPoint="true">
7 <NumberInterpreterAffixes>
8 <Prefix/>
9 <Suffix/>
10 </NumberInterpreterAffixes>
11 </NumberSettings>
12 </GlobalSettings>
13 <Operators>
14 <Add>
15 <Prefix/>
16 <Infix>+</Infix>
17 <Suffix/>
18 </Add>
19 <Subtract>
20 <Prefix/>
21 <Infix>-</Infix>
22 <Suffix/>
23 </Subtract>
24 </Operators>
25 <VariableNamings GlobalIndexUsed="true">
26 <GlobalIndex>
27 <Prefix>_</Prefix>
28 <Suffix>_</Suffix>
29 </GlobalIndex>
30 </VariableNamings>
31 <FullCode/>
32 </LangSpecDef>
4D A S C O D E G E N E R I E R U N G S - M O D E L L
In diesem Kaptitel wird ein Modell erstellt, von dem ausgehend diebenutzerspezifizierte Codegenerierung ermöglicht wird. Dafür werdenzunächst die Anforderungen an diese Modell erörtert. Danach wird mitdiesen Kriterien das Modell erstellt. Zum Abschluss wird mit diesemBeispiel modelliert.
4.1 anforderungen
Benutzerspezifizierte Codegenerierung ist eine manuell durch einenBenutzer gesteuerte Variante der Codegenerierung. Der Benutzer be-einflusst dabei das Endergebnis - Das Generat. Beeinflussung bedeutetdabei, dass der Benutzer das Generat kontrollieren kann. Bezogenauf den den LangSpec Editor soll der Benutzer sämtliche Freiheit, alsoKontrolle über das Generat haben. Dies ist notwendig um mathemati-sche Sprachen von CAS spezifizieren zu können. Deren Syntax erlaubtmeist eine relativ große Freiheit im Bezug auf die Anordnung undAbfolge von Ausdrücken und Anweisungen. So ist beispielsweise dieDeklaration von Variablen und Parametern innerhalb des Quellcodesnicht zwangsläufig immer an selbiger Position anzutreffen. Die gefor-derte Freiheit in der Modellierung einer zu spezifizierenden Sprachebringt gleichzeitig eine Problematik mit sich. Wäre ein feste Abfolgevon Bestandteilen aller mathematischen Codes gegeben, könnte maneinen Benutzer sequentiell durch den Spezifizierungsprozess leiten.Man würde ihn in anweisen, der Reihe nach die Spezifikation allernotwendigen Bestandteile vorzunehmen. Dies ist jedoch nicht gegebenund somit muss der Benutzer die Kontrolle über die Anordnung derzu spezifizierenden Code-Bestandteile haben.
Im vorangegangen Kapitel wurden die Bestandteile einer mathe-matischen Sprache in vier Hauptgruppen eingeteilt. Die allgemeinenEigenschaften einer Sprache, die Operatoren sowie die Strategien zurÜbersetzung von Variablennamen wurden dort bereits klassifiziert undmit ihren Bestandteilen spezifizierbar gemacht. Wie die Bestandteile dervierten Gruppe, die Code-Bestandteile spezifiziert werden, ist dabei nochoffen geblieben. Darum geht es im Folgenden. Als Beispiel für einesdieser Code-Bestandteile werden nun die Parameter herausgegriffen. Inder MOSAIC-internen Repräsentation einer Evaluation sind von diesendie Namen, die Werte und die Anzahl bekannt. In Sprachspezifikationkonnte also auf diese Bestandteile zugegriffen werden. Der Zugriffauf diese muss nun nicht nur dem MOSAIC-Programmierer, sondernauch dem einem Benutzer ermöglicht werden. Dazu muss also derZugriff auf Name, Wert, und da es sich um eine Menge von Parameternhandeln kann, auch deren Anzahl für den Benutzer verfügbar gemachtwerden. Es muss also eine Referenz zu diesen hergestellt werden kön-nen. Solche Referenzen werden in der Informatik als Handles bezeichnet.Da diese Handles die Referenz zu eine aus dem Quellcode stammendenBestandteil darstellen, werden sie als Linked-to-Code-Handles bezeichnet.
23
24 das codegenerierungs-modell
Im folgenden Abschnitt wird ein Modell für diesen Zugriff auf alle inMOSAIC vorhandenen Bestandteile erarbeitet.
4.2 das block-handle-modell
Das Block-Handle-Modell dient der Erstellung eines neuen Modells desursprünglichen Gleichungssystems durch Verwendung seiner Bestand-teile - Es ist also ein Metamodell. Das neue Modell (der generierteCode), ist eine Transformation des ursprünglichen Modells in Dieses.Das Metamodell dient der Erstellung dieses neuen Modells und spe-zifiziert dabei die Transformation. Die Abbildung 9 veranschaulichtdiese Umwandlung. In der Mitte ist das Block-Handle-Modell zu sehen,dessen Konzept nachfolgend erstellt wird.
Abbildung 9: Schritte der Modelltransformation
Der Quellcode eines modellierten Problems in einer mathematischeSprache besteht aus vielen Bestandteilen. Diese sind meist in Abschnittegegliedert. So existiert beispielsweise ein Abschnitt in dem Variablendefiniert werden, ein Abschnitt in dem Kommentare stehen und inWeiterer, in dem Gleichungen definiert sind. Auch Verschachtelungendurch Klammer- oder Einrückungsstrukturen sind zu finden. Um dieseBestandteile modellierbar zu machen, werden sie in Abschnitte unter-teilt. Ein Abschnitt wird als Block bezeichnet. Unterteilt man sämtlicheQuellcodeabschnitte in Blöcke, entsteht eine hierarchische Anordnungvon Blöcken, welche einer Baumstruktur entspricht. Um einen Blockeindeutig zu bezeichnen, wird ihm ein Handle zugeordnet. Ein Blockbeinhaltet also einen Codeabschnitt und ist durch ein Handle eindeutigzu identifizieren. In der Abbildung 10 ist diese Gruppierung zu Blöckenund deren Handles zu sehen.
Als Beispiel für Codeabschnitte wurden zuvor Kommentare undVariablendefinitionen erwähnt. Kommentare können dabei durch eineneinfachen Block spezifiziert werden. Im Falle von Variablen ist dieskomplexer. Diese existieren in MOSAIC in Listen (Arrays), auf die perIndex zugegriffen wird. Der Index wird dabei in Schleife (Loop) erhöht.Dieses Vorgehen kann analog auch in der zu spezifizierenden Sprache
4.2 das block-handle-modell 25
Abbildung 10: Gruppierung von Code-Bestandteilen in Blöcke
der Fall sein. Um dies zu realisieren wird ein weiterer Blocktyp einführt,bei dem der Inhalt durch Listen geknüpft ist, der Schleifenblock. DieCodebestandteile auf deren Inhalt nur durch solche Schleifenblöcke zu-gegriffen werden, sind können daran erkannt werden, dass eine Menge>= 1 von ihnen existieren kann.
Ein gesamter zu spezifizierender Code kann also durch Blöcke mo-delliert werden, die in einer Baumstruktur dargestellt werden. JederBaum besitzt ein Wurzelelement (Wurzel-Block), unter dem sich alleweiteren anordnen. Bezogen auf den Code, enthält also der oberstenBlock sämtliche weiteren Blöcke, die hier Kindblöcke genannt werden.Ein Block besitzt neben drei bereits bekannten Eigenschaften, nocheine weitere, die verfügbaren Kind-Handles. Diese sind die Handles derdirekten Kindblöcke. Wird in dem Inhalt eines Blocks ein Kindhandlebenutzt, wird dieses in beim Ausführen der Codegenerierung durchden Inhalt des zugehörigen Kindblocks ersetzt. Diese Prozedur läuftrekursiv ab, findet also in jedem einzelnen Block statt.
Zu den verfügbaren Kindhandles kommen jedoch noch weitere,die Linked-to-Code-Handles. Eine detaillierte Auflistung der Linked-to-Code-Handles findet sich in Abschnitt 3.1.4. Es gibt noch weitereLinked-to-Code-Handles, die Global Handles. Diese werden jedem Blockangehängt. Dazu zählen:
• Dimension der Variablenmenge
• Dimension der Parametermenge
• Dimension der Gleichungsmenge
• Handle des direkten Funktionsaufrufes
• Handle der direkten Funktionsimplementierung
Sowie im Falle der Unterstützung von direkten Funktionen:
• Handle des direkten Funktionsaufrufes
• Handle der direkten Funktionsimplementierung
26 das codegenerierungs-modell
Damit sind alle Codeelemente spezifizierbar geworden. Das Modellermöglicht eine freie benutzerspezifizierte Codegenerierung. Zur Über-sicht sind abschließend noch einmal alle Eigenschaften eines Blockesdargestellt.
Block
• Handle (eindeutiger Bezeichner)
• Typ (Block oder Schleifenblock)
• Inhalt (Spezifikation)
• Verfügbare Kind-Handles (Handels der direkt untergeordnetenBlöcke, Linked-to-Code-Handles (inkl. Globale Handles))
4.3 beispiel
In Abbildung 10 ist die Gruppierung von Codeabschnitten dargestellt.Will ein Benutzer eine Sprache spezifizieren, geht er genau in umgekehr-te Reihenfolge vor. Er modelliert mit Hilfe des Block-Handle-Modellsdie gewünschte Codespezifikation. Die Abbildung 11 zeigt dies an demselben MATLAB-Codeausschnitt. Das Block-Handle-Modell ist dafür ingrafischer Weise dargestellt.
4.3 beispiel 27
Abbildung 11: Benutzerspezifzierte Codegenierung für einen Codeabschnitt inMATLAB mittels des Block-Handle-Modells
28 das codegenerierungs-modell
In vorangegangen Kapitel wurde die Realisierung der Codebestand-teile in Form des XML-Datei-Formats auf dieses Kapitel verschoben.Das Listing 4.1 zeigt dies für den in diesem Kapitel betrachtetenMATLAB-Code.
Listing 4.1: Beispiel eines XML-Dokuments
1 <Block>
2 <Handle>_BLOCK_1_</Handle>
3 <Specification>function[Y] = getFunVal(X_ITER,PARAMS)
4
5 % read out variables
6_VARS_
7
8 % read out parameters
9_PARS_
10
11 % evaluate the function values
12_EQUAS_
13
14 end
15 </Specification>
16 <EquationsAE>
17 <Handle>_EQUAS_</Handle>
18 <Specification> Y(_CTR_NAME_) = _VALUE_;
19 </Specification>
20 <SepName>_SEP_NAME_</SepName>
21 <CtrName>_CTR_NAME_</CtrName>
22 <Value>_VALUE_</Value>
23 </EquationsAE>
24 <Variables>
25 <Handle>_VARS</Handle>
26 <Specification> _NAME_ = X_ITER(_CTR_);
27 </Specification>
28 <Value>_VALUE_</Value>
29 <Name>_NAME_</Name>
30 <SepName>_SEP_</SepName>
31 <CtrName>_CTR_</CtrName>
32 </Variables>
33 <Parameters>
34 <Handle>_PARS_</Handle>
35 <Specification> _NAME_ = PARAMS(_CTR_);
36 </Specification>
37 <Value>_VALUE_</Value>
38 <Name>_NAME_</Name>
39 <SepName>_SEP_</SepName>
40 <CtrName>_CTR_</CtrName>
41 </Parameters>
42 </Block>
5S O F T WA R E - I N T E G R AT I O N
5.1 das mosaic-framework
MOSAIC ist ein Web-basierte Anwendung. Sie setzt sich zusammenaus einer Server- und einer Client-Komponente. Der Server verwalteteine Datenbank in der alle Daten gespeichert werden. Darüber ist auchder Austausch der Modellbestandteile sowie der Sprachspezifikationenmöglich. Der Client, den Teil den ein Benutzer sieht, ist als Java-Appletrealisiert. Auf Quellcode-Ebene sind die folgenden von Interesse:
de.dbta.mosaic.gui (GUI-Komponenten)
Hier befinden sich die gesamten Komponenten der MOSAIC-GUI. Die-se setzt sich aus vielen einzelnen Panels (Fenstern) zusammen, die aufeinem dem Applet platziert sind. Alle Haupteditoren sind auf demBasicGeneralEditorPanel angeordnet. Von diesem leitet auch der LangSpecEditor ab, wodurch er mit einem Controller verbunden wird und einenReporter Zugriff erhält. Der Controller stellt die Verbindung zum Modellher und der Reporter dient dem Warnungs- und Informationsmanage-ment.
de.dbta.mosaic.model.syntax (Namenstabellen, XML-Zugriff)
In MOSAIC werden alle Strings in einer Klasse namens NameTable zen-tral abgelegt. Somit wird sichergestellt, dass diese nur global geändertwerden können. In diesem Package befinden sich auch der ModelParserund der ModelWriter. Diese Klassen dienen dem Erstellen von Datei-en. Hier ist auch das XML-basierte Sprachspezifikationsformat .moslspdefiniert.
de.dbta.mosaic.model.transform (Codegeneratoren, Sprachspezfika-tionen)
In diesem Package befinden sich die „hart-codierten“ Sprachspezifika-tionen sowie die Codegeneratoren für die verschiedenen Gleichungs-systemtypen. Es existiert dabei eine Codegenerator-Klasse von der sichdann die weiteren (NLE, ODE, DAE) ableiten. In diesem Package wirdauch die benutzerspezifizierte Sprachspezifkationsklasse realisiert.
Damit ein ein instanziertes Gleichungssystem, also eine Evaluationfür die Codegenerierung verfügbar wird, müssen die folgenden Kriteri-en erfüllt sein:
• Degree of Freedom = 0 (Variablenklassifizierung)
• Spezifikation aller Operationen
• Auswahl einer Variablennamen-Übersetzungsstrategie und Spezi-fikation deren Bestandteile
29
30 software-integration
• Festlegung auf eine Gleichungssystemtyp
• Groß-Kleinschreibungs-sensitiv
5.2 die language-specification-komponenten
In diesem Abschnitt wird die Kernarbeit der Implementierung desneuen Ansatzes der benutzerspezifizierten Codegenerierung betrachtet.Das ist zum einen die Implementierung des Block-Handle-Modells undzum anderen die Erstellung der GUI.
5.2.1 Codegenerierung mit dem Block-Handle-Modell
Die zentrale Klasse der benutzerspezifizierten Codegeneration ist die:de.dbta.mosaic.model.transform.LangSpecUserDefined. In ihr wer-den Elemente einer Sprachspezifikation hinterlegt. Von ihr aus wirdauch auf die Bestandteile der Gleichungssysteme zugegriffen. Außer-dem sind dort Überprüfungsmethoden realisiert, die einem BenutzerHilfestellungen beim Erstellen einer Sprachspezifikation geben. Dazuzählt die Überprüfung auf Verwendung der minimal zu spezifizieren-den Elemente wie Variablen oder Gleichungsblöcke. Weiterhin bietetsie Methoden die den Benutzer warnen, wenn er beispielsweise im Laufder Sprachspezifikation der Gleichungssystemtyp ändert (z.B. ODE-Gleichungen im NLE-System).
Der Codegenerator in MOSAIC ruft diese Klasse auf um die Code-generierung zu starten. Dazu existiert für jeden der drei Gleichungs-systemtypen eine, den Generierungsprozess anstossenden Methode.Abhängig von diesem Typ werden dann die jeweiligen Modellbestand-teile (Variablen, Gleichungen, . . . ) in den (Java-) Methodenparameternübergeben. Von diesen Methoden aus wird die eigentliche Codegene-rierung per Block-Handle-Modell gestartet.
Die Abbildung 12 zeigt das Klassendiagramm der existierenden Blö-cke und ihre Vererbungshierarchie. Die Mutterklasse Block enthält diefür die Codegenerierung zuständige Methode generateCodeForThis().Diese Methode wird von jeder erbenden Klasse überschrieben, da je-der Block auf andere Linked-to-Code Bestandteile zugreift. SämtlicheBlöcke definieren sich ihren Blocktyp und der den verfügbaren Kind-handles. Durch ein Flag namens isEditable kann deren Darstellung inder GUI beeinflusst werden. Sollen diese änderbar sein, muss dieses aufden Wert true gesetzt werden. Die generateCodeForThis()-Methodeverfährt nach dem folgenden Algorithmus:
• Überprüfe ob in der Spezifikation (Inhalt des Blocks) Kindhandlesenthalten sind.
• Wird das erste Kindhandle gefunden, das zu einem Kindblockgehört, ersetze dieses mit dessen Spezifikation. Diese wird rekur-siv fortgesetzt, bis alle Kindblöcke abgearbeitet und die gesamteeigene Spezifkation durchsucht wurde.
• Wird ein eine Linked-To-Code-Handle gefunden, wird es mit demjeweiligen Codebestandteil (Modellelement) ersetzt.
5.2 die language-specification-komponenten 31
Abbildung 12: Klassendiagramm der Block-Struktur
32 software-integration
Der in Abbildung 12 zu sehende FullCode-Block ist der Wurzelblockdes Baumes. Er ist selbst Unterklasse von Block und implementiertwiederum eine eigene Codegenerierungsmethode.
5.2.2 GUI
5.2.3 Language Specifiaction Editor
Der LangSpec Editor setzt sich aus fünf Unterpanels zusammen, diein den folgenden Unterabschnitten gezeigt werden. Die ersten vierdienen der Spezifizierung der im Laufe dieser Arbeit kategorisiertenSprachbestandteile. Der fünfte ermöglicht es, eine Evaluation zu laden,anhand der die Sprachspezifikation getestet werden kann.
Für den LangSpec Editor wurden wiederverwendbare Komponentenentwickelt. Diese ermöglichen einen durchgehenden Stil der GUI undverringern den Entwicklungsaufwand. Dazu gehören die Panels zur:
• Spezifikation der Wortbildungselemente (mit Syntaxhervorhe-bung)
• Ausgabe bereits spezifizierter Operatoren (mit Syntaxhervorhe-bung)
• Information über die minimal zu definierenden Sprachbestandtei-le
5.2 die language-specification-komponenten 33
Global Language Settings
Abbildung 13: Ansicht des Editors der allgemeinen Spracheigenschaften
34 software-integration
Operations
Abbildung 14: Ansicht des Editors der mathematischen Operationen
5.2 die language-specification-komponenten 35
Variable Namings
Abbildung 15: Ansicht des Editors der Variablennamen-Übersetzungsstrategie
36 software-integration
Code Elements
Abbildung 16: Ansicht des Editors der Code-Bestandteile
5.2 die language-specification-komponenten 37
Overall Results
Abbildung 17: Ansicht des Editors zum Endergebnis
6Z U S A M M E N FA S S U N G U N D A U S B L I C K
Die benutzerspezifzierte Codegenerierung in MOSAIC wurde ermög-licht. MOSAIC ist damit nicht mehr limitiert auf die Codegenerierungeiner festen Anzahl von Sprachen.
Durch die implementierte Spezifizierungsstruktur kann ein Benutzermathematische Sprachen flexibel strukturieren und ist frei in der Wahlder Syntax. Die Panels des Sprachspezifikations-Editors sind in intuiti-ver Reihenfolge angeordnet und unterstützen dadurch den Benutzer.Eine weitere Hilfestellung bietet sich Benutzer bei Spezifizierung vonWortbildungselementen, wo eine Syntaxhervorhebung zur Trennungder Operanden geschieht. Die einzelnen Editoren orientieren sie amStil der restlichen MOSAIC-GUI und reduzieren somit ein wenig dieKomplexität dieser neuen Funktionalität von MOSAIC. Wie auch dort,wird der Benutzer durch Hinweise vor eventuellen Fehlern gewarnt.
Ist eine Sprachspezifikation einmal erstellt worden, kann sie wiederin den Editor geladen und angepasst werden. Bestehende Sprachspezifi-kationen können so auch als Templates für die Erstellung von weiterenSprachen, bzw. Derivaten dienen. Das XML-Datei-Format ist in seinerStruktur leicht erweiterbar und somit können weitere Elemente gut inden vorhandenen Aufbau integriert werden.
Im Weiteren Verlauf kann die GUI noch verbessert werden. Die Hand-habung der Baumdarstellung im Code Elements-Editor könnte durcheine Drag-and-Drop-Editierbarkeit erleichtert werden. Eine weitere Auf-gabe wäre die Spezifizierung aller bereits unterstützten Sprachen mitdem LangSpec Editor. Diese könnten dann den Benutzern verfügbargemacht werden und diese könnten sie auf ihre Bedürfnisse anpassen.
39
L I T E R AT U RV E R Z E I C H N I S
[AE78] A.K., Salomaa ; E.W., Deeterich: Formale Sprachen. Springer,1978. – ISBN 9783540090304
[Bri02] Bringhurst, Robert: The Elements of Typographic Style. Hartley& Marks, 2002 (Version 2.5)
[Her03] Herrington, Jack: Code Generation In Action. Manning, 2003
[KNG08] Kurbel, Karl ; Norbert Gronau, Jörg B.: Enzyklopädieder Wirtschaftsinformatik. Website, 2008. – Verfügbar aufhttp://www.enzyklopaedie-der-wirtschaftsinformatik.
de/wi-enzyklopaedie/lexikon/technologien-methoden/
Sprache, Abruf am 14.02.2011.
[Kun10] Kuntsche, Stefan: MOSAIC User Guide. Website, 2010. –Verfügbar auf http://www.mosaic-modeling.de/documents/mosaic_users_manual.pdf, Abruf am 14.02.2011.
[Sta74] Stachowiak, Herbert: Allgemeine Modelltheorie. Springer,1974
[Zer08] Zerry, Rodolphe: MOSAIC, eine webbasierte Modellierungs-und Simulationsumgebung für die Verfahrenstechnik, TechnischeUniversität Berlin, Diss., 2008
41
