Editor für eine DSL anhand der Spring Validierungssprache. Praktikum MDSD SS008 Uni Augsburg

Transkript

1 Editor für eine DSL anhand der Spring Validierungssprache Praktikum MDSD SS008 Uni Augsburg Hadi Deniz Wissam Odeh Wei Zhao

2 Gliederung Einleitung 1 1. Spring Validation Validation Einführung Validator allgemein Valang Validator Valang Valang Syntax Regelkonfiguration Aussagen Operatoren OAW und XText MDSD Modell Metamodell MDSD Definition OpenArchitectureWare OpenArchitectureWare Definition OpenArchitectureWare Komponente Vor- und Nachteile XText Framework XText Architektur Language Projekt in Details Editor Projekt in Details Generator Projekt xtext Grammatik XPand Framework Struktur Wichtige Befehle in Überblick Die Eclipce Rich Client Plattform Plattform für Rich-Clients Die Eclipse RCP für das Projekt Oberfläche für Editor Integration von Plug-in Erstellung einer Aplikation Implementierung OpenArchitectureWare- (Implemnierung) DSL für Valang Constraints Extentions Outline Auto-Complete (Syntaxvervollständigung) xpand-templates Die Eclipse Rich Client Plattform (Implementierung) Eclipse Plattform für Rich-Clients Die Eclipse RCP für das Projekt RCP-Implementierung Architekturen von Editor Zusammenfassung und Ausblick

3 Einleitung Software Projekte sind immer von Umfang her großer und komplexer geworden. Um diese Komplexität zu vermeiden, bietet MDSD die Möglichkeit ein Teil dieser Software automatisch zu generieren und Subsysteme wieder zu verwenden. In unserem Projekt werden wir mit Hilfe von OpenArchitekturWare(OAW) Framework ein Editor für eine DSLs anhand der Spring-Validierungssprache realisieren. In dieser Dokumentation stellen wir in erstem Kapitel Validierung und Validator von Spring vor. Im nächsten Kapitel kennen wir xtext und xpand von OAW lernen und in drittem Kapitel behandeln wir die Architektur und Konzept von Eclipse RCP. Im letzten Kapitel wird die konkrete Implementierung durchgeführt. 1. Spring Validation 1.1 Einführung Validierung(Validation) ist die dokumentierte Beweisführung, dass ein System die Anforderungen in der Praxis erfüllt. In der Softwaretechnik bezeichnet Validierung (auch Plausibilisierung, als Test auf Plausibilität, oder engl. Sanity Check genannt) die Kontrolle eines konkreten Wertes darauf, ob er zu einem bestimmten Datentyp gehört oder in einem vorgegebenen Wertebereich oder einer vorgegebenen Wertemenge liegt. Sie ist ein wichtiger Aspekt der Qualitätssicherung, der sicherstellen soll, dass ein implementiertes Programm den vorher aufgestellten Anforderungen genügt. Die meisten Programmfehler und Sicherheitsprobleme sind letztlich auf fehlende Plausibilisierung von Eingabewerten zurückzuführen 1. Die Validierung ist ein wichtiges Instrument, um die Qualität von Arbeitsergebnissen sicherzustellen, in der pharmazeutischen Technologie, Biotechnologie, analytischen Chemie, klinischen Medizin oder Computertechnologie. Zu diesem Zweck wird ein dokumentierter Nachweis erbracht, der stets vor der Entwicklung oder Einführung eines Computersystems geführt wird. Validierung und Verifizierung werden manchmal verwechselt. Verifikation ist die Überprüfung, ob ein System die formale Spezifikation erfüllt. Umgangssprachlich ist die Validierung Antwort auf die Frage : baue ich das richtige Haus? Und Verifizierung ist die Antwort auf die Frage: baue ich das Haus richtig? Validator Validators sind die Werkzeuge die uns ermöglichen die Gültigkeit von unserem Kode festzustellen. Validator die wir hier benutzen sind die implementierungen von Springframework. Springframework hat zwei Arten von Validators; Einer ist programmatischer Validator,in dem Validierungsregeln schon kodiert sind und der andere ist 1 2

4 deklarativer Validator, was Validierungsregeln und Beschränkungen auf Konstruktionen beruhen 2. In unserem Fall werden wir die zweite Validator behandeln. Für die declarativer Validator hat Spring drei Validierungswerkzeuge Commons Validator Valang Validator Bean Validation Framework Der Commons Validator verwendet eine XML-Konfigurationsdatei um die Beschränkung declerativ zu spezifizieren. Allerdings, ist die Konfiguration nicht intuitiv, und seine Konfiguration-Format ist sehr verbose. Das Bean Validation Framework ist das neueste und wurde entwickelt, um die Lücken in den anderen verfügbaren Validierung Werkzeuge, nämlich commons Validator und Valang Validator zu füllen. Die wichtigsten Ziele dieses Framework sind: Ermöglichen klare Trennung von Interessen, wenn es zur Validierung kommt. Extrahieren Sie die besten Eigenschaften von den anderen Ansätze(Werkzeuge) und vereinigen sie in einem Rahmen Die neueste Technologie und und Methoden verwenden Macht die die Validierungsregeln so intuitiv und einfach wie möglich für die Definition in der Anwendungen. Bean validation Framework-Validator ist das Beste unter diesen Tools, weil es flexibler, leistungsfähiger ist. Ausserdem unterstützt es auch XML Deklaration. (hier wird noch erweitert ) Da unsere Arbeit auf Valang basiert werden wir uns hier hauptsächlich auf Valang-Validator konzentrieren Valang Validator Valang, das für Validierungssprache steht, ist eine Sprache, die spezifisch für die Validierung der Zielobjekte bestimmt ist. Seine Darstellung ist kurz und spezifisch auf das Erhalten von valiedierende Daten ausgerichtet. Das ist ein Opensource Projekt und in Spring Modulen zu erhalten. Wie man eigenes Validator schreibt werden wir mit dem Beispile in Syntaxteil verdeutlichen. Die zwei wichtigste Klasse von Spring-Validation sind die Klassen org.springframework.validation.validator und org.springframework.validation.errors. Die Klasse Errors bedient wie eine Registry für die Errors, die mit dem ziel Objekt kombiniert sind. Validator interface bietet einen Vorgang um ziel Objekt zu validieren und kombinierte Errors zu registrieren. Unsere Kode werden hier überprüft und im Fall eines Fehlers wird ein gebundenen Fehler vom Errors geholt und angezeigt. 1.2 Valang Valang(Validation Language), bietet einen einfachen und intuitiven Weg zum Erstellen von Spring Validator. Valang hat drei wichtige Ziele 2 Expert Spring MVC and Web Flow 3

5 Validierungsregeln Schnell und ohne Java Klassen zu schreiben Vereinfacht die Verwendung von Spring Validation Werkzeuge Erstellt die Validationsregeln kompakt, lesbar und einfach bedienbar Hier unten werden wir ein Beispiel überprüfen <bean id="personvalidator" class="org.springmodules.validation.valang.valangvalidator"> <property name="valang"> <value> <![CDATA[ { firstname : length(?) < 30 : 'First name too long' : 'first_name_length' : 30} { lastname : length(?) < 50 : 'Last name too long' : 'last_name_length' : 50 } ]]> </value> </property> </bean> Hier wie wir sehen erstens keine neue klasse wurde erstellt aber man verwendet hier eine vordefinierte Klasse. Zweitens PersonValidator ist kein Teil von Java Kode aber könnte eine java Klasse(ValangValidator) instanzieren. Als drittes die Validationsregeln wurden mit Valang expression Language geschrieben, welche sehr einfach und schnell zu schreiben sind. Um diese regeln zu schreiben hat Valang einen umfangreichen Syntax Valang Syntax Valang Syntax basiert auf Valang Expression language und valang validation rule configration. Ein Teil von diesen Regeln und funktionen sins vordefiniert ein Teil können wir selber definieren Regelkonfiguration: Alle Regeln werden in geschweifte Klammer geschrieben und die Felder werden mit : trennen. Es gibt obligatorische Felder und optionale Felder mit folgendem Beispiel lernen wir Grundstruktur kennen. Bsp; { firstname : length(?) < 30 : 'First name too long' : 'first_name_length' : 30} Grundstruktur { <key> : <predicate_expression> : <message> [: <error_code> [: <args> ]] } <key>=firstname- das ist der Schlüßelname mit dem ein Error verbunden ist. Das ist validierende Zielobjekt. : <predicate_expression>=length(?)-das ist eine Valangaussage was das prädikat definiert. Das ist die Beschränkung die gesucht ist.? ist für firstname damit wird Redundant vermieden 4

6 <message> = first name too long das ist Error Nachricht kann leer gelassen werden. In dem Fall wird ein default Nachricht ausgegeben Die oberen drei Felder sind obligatorisch den Rest ist optional die sind die Nachrichten die man über Error Kode mehr details geben kann Aussagen: Die Prädikate(Aussagen ), die wir bei den Regeln verwenden, werden mit Expression Language wie folgend definiert. <expression> ::= <expression> ( ( "AND" "OR" ) <expression> )+ <predicate> <predicate> besteht aus operatoren, literalen, bean mathematische Ausdrücken. properties, Funktionen, und Operatoren Binary Operators: diese haben Leftseite und Linkeseite String, Boolean, Date and Number Operatoren: = == IS EQUALS!= <> >< IS NOT NOT EQUALS Number und Date Operatoren: > GREATER THAN IS GREATER THAN < LESS THAN IS LESS THAN >= => GREATER THAN OR EQUALS IS GREATER THAN OR EQUALS <= =< LESS THAN OR EQUALS IS LESS THAN OR EQUALS Unary Operatoren: Die haben nur Linkeseite. Object Operatoren: NULL IS NULL NOT NULL IS NOT NULL String Operatoren: HAS TEXT / HAS NO TEXT HAS LENGTH / HAS NO LENGTH IS BLANK / IS NOT BLANK IS UPPERCASE IS UPPER CASE IS UPPER IS NOT UPPERCASE IS NOT UPPER CASE IS NOT UPPER IS LOWERCASE IS LOWER CASE IS LOWER IS NOT LOWERCASE IS NOT LOWER CASE IS NOT LOWER IS WORD / IS NOT WORD Speziale Operatoren: 5

7 BETWEEN / NOT BETWEEN IN / NOT IN NOT Bsp: width between 10 and 90 length(name) between minlength and maxlength Funktionen : Funktion Syntax ist wie folgend; function ::= <function_name> "(" ( <literal> <bean_property> <function> ) ( "," ( <literal> <bean_property> <function> ) )* ")" Es gibt auch vordefinierte Funktionen : Length, size, count Match, matchs Upper,lower : die ergeben die Länge ein Objekt : vergleicht zwei Objekte : konvertiert die Strings nach groß bzw. Klein Buchstaben Unterstütze Mathematische Operatoren: + - * / div % mod 3 2 OpenArchitectureWare, xtext und xpand 3 alle beispiele sind aus der Seite 6

8 Einleitung Nachdem wir im letzten Kapitel den Valang Validator von Spring dargestellt haben und die Valang Syntax im letzten Abschnitt vorgestellt haben, führen wir in diesem Kapitel ein ganz anderes Thema ein, und zwar das Tool, dass wir nutzen werden, um ein Text-Editor für die Valang-Sprache zu erstellen. In Diesem Kapitel werden wir mit einer groben Definition des MDSD Begriffs anfangen, gefolgt von der Vorstellung des OpenArchitectureWare Projekts und seine Hauptkomponente, danach werden wir die xtext und xpand Frameworks und ihre Grammatiken und Strukturen detaillierter besprechen. 2.1 Model Driven Software Development (MDSD) Modell Ein Modell ist allgemein eine auf bestimmte Zwecke ausgerichtete vereinfachende Beschreibung der Wirklichkeit. In der wissenschaftlichen Theoriebildung ist ein Modell das Ergebnis einer abstrahierenden und Relationen hervorhebenden Darstellung des behandelten Phänomens. Ein Modell entsteht, wenn Elemente aus dem Phänomen abstrahiert und zueinander in Beziehung gesetzt werden. Die Funktion des Modells besteht darin, aus den dargestellten Zusammenhängen Bedingungen und Prognosen bezüglich des Phänomens (oder Problems) ableiten zu können. (Wikipedia) Metamodell Das Metamodell ist ein auf höhere Abstraktionsschicht liegende Modell. Dieses beschreibt die Struktur der Domäne formal und hilft bei der Festlegung welche Elemente im Modell vorkommen dürfen und wie sie zueinander in Beziehung stehen. Diese formale Beschreibung ermöglicht erst die spätere Automatisierung der Outputgenerierung MDSD-Definition Modellgetriebene Softwareentwicklung (Model Driven Software Development, MDSD) ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen. (Stahl/Völter 2007, S.11) Formale Modelle: Sind die Modelle, die klare eindeutige Aussagen über einen Aspekt der zu entwickelnden Software ermitteln. Lauffähige Software erzeugen: Ziel eines MDSD ist eine lauffähige Software zu erzeugen. Wenn die formale Modelle nur die Dokumentation dienen, heißt das nicht, dass wir uns mit einem MDSD Project beschäftigen, da in diesem Fall keine Erzeugung stattfindet. Zwei Methoden zur Erzeugung lauffähige Software aus Modelle sind bekannt, Generatoren und Interpreter, wobei Generator aus einem Modell Quelltext einer andere Programmiersprache erzeugt und wird als Bestandteil des Build-Prozesses betrachtet, ein Interpreter, auf der anderen Seite, ist dazu verantwortlich, ein Modell zur Laufzeit einliest und abhängig von seinem Inhalt verschiedene Aktionen ausführt. Automatisch: Das bedeutet, dass es mindestens ein Teil der Software Automatisch durch Eingabe des Modells erzeugt wird. Hier wird noch mal betönt, dass das Modell nicht nur zur Dokumentation zur Verfügung steht, sondern ist ein wichtiger Teil bei der Erzeugung der Software. Das bedeutet, dass die Modelle als Quelletexte betrachtet werden, auf denen Änderungen vorgenommen werden, diese Änderungen werden später bei der Generierung reflektiert. 7

9 2.2 OpenArchitectureWare OpenArchitectureWare (OAW) openarchitectureware ist ein Generator Framework für die Modell getriebene Softwareentwicklung (MDSD) bzw. Modell getriebene Architecture (MDA), OAW Baut auf Eclipse-Plugins des "Eclipse Modeling Project" auf, z.b. EMF, GMF, UML2. es ist ein Opensource Projekt und seit der Version 4 ist ein Subprojekt bei Eclipse geworden. OAW unterstützt den Entwicklungsprozess eines MDSD Projekt von Erstellung und Überprüfung des Eingabemodells, Erstellung des Metamodells bis zur Codegenerierung in verschiedene Formen (Java, XML..) OpenArchitectureWare Komponente OAW besteht aus einer Vielzahl von Einzelkomponenten: Workflow: Workflow ermöglicht ein flexibel konfigurierbares Genratorprozess. Check-Framework: Modellvalidierung mit OCL-basierten Templates. xpand Framework: zur Erzeugung beliebiger Ausgabedateien, Modell zu Text Transformation (M2T). Extend Framework: Modell zu Modell (M2M) Transformation. xtext Framework: Modellerstellung durch Parsen von Text-Dateien. Expression-Framework: Es besteht aus einem Typsystem (engl. Type System) und einer Expression-Sprache. Dieses Framework kommt sowohl innerhalb von xpand als auch in Check-Language zum Einsatz. Es bietet die Möglichkeit auf unterschiedliche Metamodelle immer mit der gleichen Syntax zuzugreifen Vor- und Nachteile OAW stellet ein umfangreiches flexibles Framework für MDSD Entwicklung und hat viele Vorteile, von denen: Sehr gut in Eclipse Integriert und können Java Erweiterung zugefügt werden. Es lassen sich beliebige Metamodelle verwendet, hat keine Einschränkung auf UML Modelle Auch in der Ausgabe hat sich erwiesen, dass OAW flexible ist. Es können beliebige Textdateien generiert werden Das xtext-framework stellt für den Projektstart ein gutes Werkzeug zur Erzeugung von Metamodell und Modelleditor mit zahlreichen Erweiterungsoptionen wie Codevervollständigung und Syntaxhighlighting. Neben den Vorteilen gibt es einige Aspekte, die als Nachteile betrachtet werden können. Der Installationsvorgang ist ziemlich komplex, es werden nicht nur OAW Plugins installiert sondern auch zusätzliche Plugins wie EMF, GMF, UML etc. Das Verstehen von den verschiedenen Komponenten und ihrer Beziehung zueinander am Anfang ist nötig Die Dokumentation von OAW ist teilweise veraltet oder nicht vollständig 2.3 xtext-framework Für die Erstellung eines eigenen Metamodells bringt OAW das xtext-framework mit. Mit xtext kann man eigene textuelle DSLs erstellen. Daraus erzeugt xtext ein Metamodell, einen Parser für das Modell und ein Editor-Plugin mit Codevervollständigung und Syntaxhighlighting für Eclipse. Die Grammatik der Metasprache und des Modells wird mit einer an die erweiterte Backus-Naur-Form (EBNF) angelehnten Sprache beschrieben. 8

10 2.3.1 Architecture Bei Erstellung eines xtext-projekt werden drei Subprojekte automatisch erstellt (doch nicht die vollständige Inhalte) Language-Projekt, Editor-Projekt und Generator-Projekt. Wie wird der ganze Ablauf aussehen? zuerst kommt das DSL (.xtxt Datei) ins Spiel, nachdem die Grammatik in der xtxt Datei definiert wird und der Generator Eigenschafen eingestellt sind, kann der Generator ausgeführt werden. Wenn diese Ausführung Fehlerfrei erfolgt, werden das Metamodell, den Parser und den Editor-Projekt-Inhalt erstellt, dann können die optionale Bereiche manuell ergänzt werden(siehe Abbildung 2.1, 2.2,2.3). Abbildung Language Projekt in Details Hier ist ein Überblick auf die wichtigen Dateien im Language Projekt 9

11 Language Project Checkdatei, hier können Semantik-Constrains zur Sprache zugefügt werden. Enthält die Metamodell - Extensions. Workflow Datei für den xtext Generator. Generator-Properties Die Grammatik, die das DSL beschreibt. Generierte Basis Dateien Von der Grammatik Generiertes Metamodell Generierte xtext Regeln Datei Generierte Antlr Parserartefakt (Abbildung 2.2) Editor Projekt in Details 10

12 Editor Projekt Vervollständigung anpassen Outline-Ansicht anpassen. find Reference und go to Definition anpassen. Outline Labels und Icons anpassen Enthält die wichtige DSLspezifische Informationen, Änderungen sind durchführbar in Unterklassen, in diesem Fall soll die MydslEditorPlugin.java Datei entsprechend angepasst werden. Generierte Basis Dateien Outline Icons (Abbildung 2.3) Generator Projekt wie früher erwähnt, OAW unterstützt die MDSD-Projekt bis zur Erzeugung von Ausgabedateien in verschiedenen Formaten wie XML, Java etc. dies erfolgt mit Hilfe der xpand-templates (und Plattform-Spezifische Extend Dateien). Diese Dateien befinden sich im Generator Projekt. die xpand-templates werden wir im Letzten Abschnitt dieses Kaptitels näher besprechen xtext Grammatik 11

13 xtext Grammatik basiert sich auf das extended Backus Naur form (EBNF) und besteht aus einer Sammlung von Regeln, eine Regel muss einen Name haben, gefolgt von : und endet mit ; dazwischen befindet sich die Beschreibung der Regel. Die Regeln können in 4 Kategorien eingeteilt werden: String Regel: um selbstdefinierte Zeichensequenz zu definiert. String JavaIdentifier : ID ("." ID)*; Enum Regel: geeignet für Aufzählungstypen, die in einem endlichen Wertebereich liegen. Enum Farbe: green= GRÜN blue= BLAU red= ROT ; Native Regel: um lexerregeln zu definieren, die nicht mit den normalen xtext-syntax ausdrückbar sind. Z.B. um Float Ausdruck zu definieren, kann die Folgende Regel hilfreich sein. Native FLOAT: ( - )?( )+. ( )+ ; Type Regel: ist im DSL Grammatik am meisten zu sehen, sie beginnt mit einem Name, dieser Name wird im Metamodell als EClass abgebildet, gefolgt von : dann kommt die Relgelbeschreibung, die Beschreibung ist eine Sammlung von Token, die Token sind Keywords (String),Properties, andere selbstdefinierte Typen oder Instanzen von den sogenannten Built-in Lexer. ein Beispiel wird dies anschaulicher machen aber vorher stellen wir die Build-in Lexer vor: ID: Identifier, erlaubt den folgenden Sequenz ( a-za-z_ ( a-za-z_0-9 )*) STRING: erlaubt einen Zeichenkettenausdruck. INT: erlaubt einen Integerausdruck (kein Float). LINE: Manchmal will man keinen Text innerhalb von Terminals einschließen, sondern will alles zwischen eine Charakterreihenfolge und das Ende der Zeile bekommen. z.b. ein Kommentar der mit # beginnt und endet mit dem Zeilenende wird in der folgenden Regel beschrieben. Attribute : (comment=line("#"))? type=datatype name=id; Mit dieser Regel können wir die folgende Syntax ausdrücken entity Customer { string name; #should include the street number, too. string street; int age; bool ispremiumcustomer; } 12

14 Einfaches Beispiel: Entity : entity name=id { (features+=feature)* } ; Unsere Typregel hat den Name Entity, dieser Name wird auch so im Metamodell als EClass abgebildet. die Beschreibung besteht aus einem name als ID, den Keywords entity und die geschtreifte Klammern und einem Ausdruck (features+=feature)* mit dem Property += und dem *. Dieser Ausdruck besagt, dass ein Entity Type kann beliebig viele Instanzen von dem Typ Feature enthalten und wird im Metamodell als EAttribute Abgebildet. Ein Feature Beschreibung kann so aussehen: Feature : type=id name=id ; ; Was kann man mit dieser Grammatik ausdrücken? entity Customer { String name; String street; Integer age; Boolean ispremiumcustomer; } Es sind drei Mögliche Properties mit vier möglichen Kardinalitäten: = : Gleichheitszuweisung += : Additionszuweisung?= : Boolean-Zuweisung * : Beliebig viele (0..n) + : Mindestens Eins (1..n)? : Optional (0 oder 1) Nichts: Eins zu Eins Abbildung (1..1) 13

15 2.4 xpand Framework xpand ist eine Sprache des OAW und wird in die Templates genutzt, um die generierte Ausgabe zu kontrollieren, mit Hilfe der xpand-templates können verschiedene Modell-zu- Text Transformationen durchgeführt werden, z.b. Java, XML oder selbstdefinierte Textausgaben. Das Haupttemplate befindet sich in dem Generator Projekt unter den Name main.xpt. Wir werden in den folgenden Abschnitt die Struktur und kurz die vorliegende Befehle vorstellen Struktur Ein xpand Template besteht aus den Befehlen der xpand-sprache und normalem Text, xpand Befehle werden zwischen einem öffnenden und schließenden Guillemot geschrieben «XPand/Befehl». Mit Hilfe der xpand-befehle können die verschiedene Elemente und ihre Eigenschaften aufgerufen werden. Generelle Template-Struktur: «IMPORT meta::model» «EXTENSION my::extensionfile» «DEFINE javaclass FOR Entity» «FILE filename()» package «javapackage()»; public class «name» { // implementation } «ENDFILE» «ENDDEFINE» Ein Template-Datei enthält beliebig viele Importbefehle, beliebig viele Extenstionsbefehle gefolgt von einem oder mehreren Definitonsblöcken Wichtige Befehle in Überblick IMPORT: IMPORT Befehl ermöglicht es, ein namespace einzubinden, ähnlich wie die Import Befehl in java, «IMPORT meta::model» = import meta.model.*;, Unterscheidet sich nur daran, dass in xpand nur komplette Pakete importiert werden können. EXTENSION: Bindet die Extend-Datei ein, die die nötigen Extensions enthält. «EXTENSION my::extensionfile» DEFINE: Das DEFINE-Block ist das eigentliche Template, enthält einen Name als Referenz, der von der Workflow-Datei oder andere Templates genutzt werden kann, gefolgt von FOR gefolgt von der Elementtyp des Metamodells, für das das Template definiert ist. Der DEFINE-Block endet mit einem «ENDDEFINE» Befehl. FILE: Enthält einen Name, einen Outletname und beliebig viele Befehle, diese Befehle werden ausgewertet und in der generierten Zieldatei reflektiert. «FILE expression [outletname]» a sequence of statements «ENDFILE» 14

16 EXPAND: Um ein anderes Define-Block innerhalb ein expand-template hinzufügen. «EXPAND definitionname [(parameterlist)] [FOR expression FOREACH expression [SEPARATOR expression] ]» FOR: bezeichnet den Elementtyp, zu dem das/der Define-Block/Expand-Befehl ausgeführt wird. FOREACH: Um Befehle auf eine Menge von Elemente durchzuführen. «FOREACH expression AS variablename [ITERATOR itername] [SEPARATOR expression]» a sequence of statements using variablename to access the current element of the iteration «ENDFOREACH» IF: Unterstützt bedingte Anfragen, endet mit ENDIF Befehl «IF expression» a sequence of statements [ «ELSEIF expression» ] a sequence of statements ] [ «ELSE» a sequence of statements ] «ENDIF» LET: um lokale Variablen zu spezifizieren «LET expression AS variablename» a sequence of statements «ENDLET» ERROR: bricht die Auswertung des Templates mit einer xpand-exception ab. «ERROR expression» Comments: Kommentare können mit Hilfe des REM Befehls eingefügt werden «REM» text comment «ENDREM» 15

17 3 Die Eclipse Rich Client Plattform Auf serverbasierten Systemen und mobilen Endgeräten ist die Java-Technologie weit verbreitet und erfolgreich im Einsatz. Bei vielen Unternehmen hat sich die Java EE als Standard für die Entwicklung von Geschäftsanwendungen etabliert. Die Benutzerschnittstelle sofern innerhalb der Java-Anwendung überhaupt vorhanden wird vorrangig auf Basis von Web-Technologie entwickelt, der clientseitige Zugriff für den Anwender erfolgt demnach mit einem Web-Browser als Thin-Client. Thin-Client (z.b. Web-Anwendungen) werden zentral betrieben und bieten deshalb Vorteile bei Roll-Out, Verwaltung und Pflege. Clientseitig müssen nur Grundvoraussetzungen erfüllt werden, beispielsweise das Vorhandensein eines Browsers. Anforderungen wie z.b. die Nutzung des lokalen Dateisystems bzw. anderer lokaler Ressourcen oder etwa Offline- Funktionalität mit anschließender Datensynchronisierung ließen sich mit Web-Clients, wenn überhaupt, nur unter größten Schwierigkeiten umsetzen. Auf dem Desktop hingegen war die Akzeptanz von Java bis zuletzt sehr gering. Erst seit kurzer Zeit kann Java auch in diesem Bereich ein stetiges Wachstum an Popularität verzeichnen. Dieser Trend ist eng mit dem Begriff des Rich-Clients verbunden. Ein Framework zur Entwicklung von Rich-Clients bietet allerdings nicht nur ein vorgefertigtes, umfangreiches Set an Oberflächenkomponenten, sondern bringt üblicherweise eine modulare Grundstruktur und ein einheitliches Modell zur Entwicklung von eigenen Komponenten mit. 3.1 Eclipse Plattform für Rich-Clients Das Anforderungsprofil für Rich-Clients ist umfangreich und der Einsatz eines umfassenden Applikation Frameworks für die verschiedensten Problemstellungen ist damit ein kritischer Erfolgsfaktor für Realisierungsprojekte. In diesem Umfeld hat sich die "Rich Client Plattform" von Eclipse (Eclipse RCP) etabliert und zeigt momentan eindrucksvoll wie erfolgreich Java-basierte Anwendungen auf dem Desktop entwickelt werden können. Die Eclipse RCP selbst ist im Wesentlichen in zwei Bereiche gegliedert: Einerseits Equinox, die Laufzeitumgebung für Komponenten, den so genannten Plug-In, und andererseits die "Workbench" als eine Art Baukastensystem für Benutzeroberflächen. Equinox basiert auf der Spezifikation der Open Services Gateway initiative (OSGi), und ermöglicht die Steuerung des Lebenszyklus der Plug-In. So können beispielsweise Plug-In während der Laufzeit installiert, ausgeschaltet oder ausgetauscht werden. Equinox verwaltet dabei die Abhängigkeiten zwischen den einzelnen Plug-In und bildet das Fundament der Eclipse RCP. 16

18 Abbildung 3.1 Architektur von Eclipse RCP Die Workbench bietet eine erweiterbare Infrastruktur für die Darstellung von Oberflächenkomponenten wie Dialoge, Menüs oder Toolbars und koordiniert ihr Zusammenspiel in den verschiedenen Fenstern einer Anwendung. Wichtige Kernbestandteile der Workbench sind das bereits erwähnte SWT und das darauf aufbauende JFace-Toolkit. JFace standardisiert einige Anforderungen mit denen Entwickler häufig konfrontiert werden: Damit sind beispielsweise die Entwicklung von Wizards, die Verwaltung von Ressourcen für die Benutzeroberfläche oder die saubere Trennung zwischen den Komponenten und den dahinter liegenden Aktionen gemeint. Auf dieser Basis hält Eclipse RCP noch viele weitere, optionale Komponenten, wie ein Hilfesystem, einen Update-Manager, Reporting-Tools und Frameworks für Text- oder graphische Editoren bereit. Auch das individuelle "Branding" des Richt-Clients an einen gewünschten Styleguide ist möglich. Die Eclipse RCP ermöglicht es dem Entwickler sich größtenteils auf die Entwicklung der eigentlichen Anwendungskomponenten und deren Integration in die Plattform zu konzentrieren. Der Ansatz der Rich-Clients, insbesondere in der Ausprägung der Eclipse RCP, hat sich in der Praxis als sehr geeignete Plattform erwiesen, um auch in Java performante und den üblichen Standards und Gewohnheiten entsprechende Desktop-Applikationen im Enterprise-Umfeld zu entwickeln. 3.2 Die Eclipse RCP für das Projekt Oberfläche für Editor Views sind bei Eclipse kleine Fenster, welche Aufgabenbereiche unter verschiedenen Sichtweisen anzeigen. Diese Fenster können durch Drag und Drop beliebig angeordnet werden, in Form von Tabs, die durch Klick auf den Reiter aktiviert werden, in Form von dauerhaft sichtbaren Fenstern oder in Form von fast Views, die als Symbole in einer weitgehend frei positionierbaren Leiste angeordnet sind und die nur bei Klick auf das Symbol 17

19 eingeblendet werden. Beispiele für Views sind der Klassenexplorer, der baumartig strukturiert Symbole für die Klassen, Funktionen und Eigenschaften eines geöffneten Quelltextes anzeigt oder das Suchfenster, das die Ergebnisse einer Suche auflistet. Editoren sind die Sichtfenster, die meist den Quelltext mit Syntaxhervorhebung anzeigen, wobei es meist für jede unterstützte Programmiersprache einen eigenen Editor gibt (zum Beispiel für DSL). Genauso gibt es aber auch visuelle Editoren oder die Baumstrukturen anzeigen. Mehrere geöffnete Quelltexte werden als Reiter geöffnet, die über Tabs am oberen Rand in den Vordergrund gebracht werden können, weiterhin können Tabs fixiert werden, so dass der zugehörige Quelltext nicht versehentlich geschlossen wird. Auch Editoren können weitgehend frei per Drag und Drop angeordnet werden. Eine Datei kann in mehreren Editoren gleichzeitig geöffnet werden. Menü und Tools-bar sind Schnellzugriff auf bestimmte, häufig verwendete Funktion ermöglicht, z.b. Öffnen, Speichern Integration von Plug-In DSL-Module wird als ein Plug-In in Editor integriert, so dass Quelltexte von DSL unterstützt werden Erstellung einer Applikation Nach der Integration von DSL-Module werden die Programme als eine Standalone - Applikation exportiert. 18

20 4. Implementierung 4.1 OpenArchitectureWare (Implementierung) Aufgabenstellung: Erstellung eines Editors für eine textuelle DSL zur Definition von Validierungsregeln mit entsprechender Generierung von Regeln in XML/VALANG. Gefordert ist ein Editor, der einen Modellierer bei der Formulierung der Regeln unterstützt (z.b. mit Syntaxhighlighting, Syntax-Prüfung und Vervollständigung) Domain Spezifische Sprache (DSL) für Valang xtext bietet die Möglichkeit, Eigene DSLs anhand der erweiterten Backus-Naur-Form (EBNF) zu erstellen. xtext hat vier Buuild-in Lexer (ID, INT, STRING, LINE), weiterhin gibt es vier mögliche Regeln (Typregel, String-Regel, Enum-Regel, Nativ-Regel) um die Grammatik zu definieren. Unsere Grammatik soll die häufig verwendeten Funktionen und Attributtypen, die bei Formular-Validierung verkommen, unterstützen. Die behandelten Attributtypen: Integer = NUMBER Float = GLEITKOMMAZAHL String = TEXT Boolaen = BOOLEAN Date = DATUM Und Objekte, die Kombinationen von den genannten Attributtypen bilden Die verfügbaren Funktionen Länge Funktionen o Laenge o Minimale Laenge o Maximale Laenge o Wertebereich (für Integer) Match Funktionen o Match o Match mit case o Match ohne case Numerische Funktionen o ist grosser als o ist kleiner als o ist grosser gleich o ist kleiner gleich o ist gleich o ist nicht gleich Boolean Funktionen o ist True o ist False Datum Funktionen o vor o nach o ist den 19

21 o zwischen Pruefe Syntax Funktionen o Nur Ziffern o Nur Buchstaben o Nur Kleinbuchstaben o Nur Grossbuchstaben o o Beginnt mit o Endet mit Da Datum Syntax und Float nicht von den Build-in Lexer, haben wir die in Nativregeln definiert. DSL Definition in xtext: Modell: (entitaet+=entitaet)*; Entitaet: "Entitaet" entitaetname=entitaetname "{" attblock=attributeblock regelnblock=regelnblock "}" ; EntitaetName: entname=id; AttributeBlock: "Attribute" "{" (attribute+=attribute)* "}" ; //selbstdefinierterattrtyp: gedacht für Instanzen der definierten Entitaeten Attribute: (vordefinierterattrtyp=vordefinierterattrtyp selbstdefinierterattrtyp=selbstdefinierterattrtyp) name=id; SelbstdefinierterAttrTyp: sdattrtyp=id; Enum VordefinierterAttrTyp: text="text" number="number" datum="datum" boolean="boolean" gleitkommazahl="gleitkommazahl";//... RegelnBlock: "Regeln" "{" (regel+=regel)* "}" ; Regel: attrname=id (verketteteattribute+=verketteteattribute)* ":" ausdrueck=ausdrueck ':' message=string (':'regexp=regexp)? ; VerketteteAttribute : '.'attrname=id; Ausdrueck: (vordefiniertefunk=vordefiniertefunk selbstdefiniertefunk=selbstdefiniertef unk); SelbstdefinierteFunk: funkname=id ('()' '('(arg=argument)(',' args+=argument)*')') ; Argument: (idarg=id zeichen=string number=int); VordefinierteFunk: (lengthfunkname=lengthfunkname '('lengtharg=lengtharg')' matchfunkname=matchfunkname '('matcharg=matcharg')' numfunkname=numfunkname (numwert=numwert float=float) boolfunkname=boolfunkname datumfunkname=datumfunkname datumvariante=datumvariante 'zwischen' komplexdatumvariante=komplexdatumvariante) ; 20

22 Enum LengthFunkName: laenge="laenge" wertebereich="wertebereich" minlaenge="minimale Laenge" maxlaenge="maximale Laenge"; //... Enum MatchFunkName: match="match" matchmitcase="match mit Case" matchohnecase="match ohne Case"; Enum BoolFunkName: isttrue="ist True" istfalse="ist False"; Enum NumFunkName: istgroesserals="ist groesser als" istkleinerals="ist kleiner als" istgroessegleich="ist groessergleich" istkleinergleich="ist Kleinergleich" istgleich="ist gleich" istnichtgleich="ist nicht gleich"; Enum DatumFunkName: vor="vor" nach="nach" ist="ist den"; LengthArg: (Nmin=INT'-'Nmax=INT) numwert=numwert ; NumWert: wert =INT; //Argument für Match Funktionen, entweder String oder ein anderes Attribute MatchArg: st=string id=id; RegExp: pruefe="pruefe Syntax" (exp1=exp complexexp1=complexexp) ((and="und" or="oder") (exp2=exp complexexp2=complexexp))? (':' message2=string)?; Enum Exp: nurziffern="nur Ziffern" nurbuchstaben="nur Buchstaben" nurkleinbuchstaben="nur Kleinbuchstaben" nurgrossbuchstaben="nur Grossbuchstaben" =" " url="url"; ComplexExp: complexexpname=complexexpname "("exparg=string")" ; Enum ComplexExpName: beginntmit="beginnt mit" endetmit="endet mit"; DatumVariante: (date=date time=time dateundtime=dateundtime) ; KomplexDatumVariante: date1=date "and" date2=date time1=time "and" time2=time dut1=dateundtime "and" dut2=dateundtime; Date:"Datum" '('datum=datum')' ; Time: "Zeit" '('zeit=zeit')' ; DateUndTime: datumundzeit="datum&zeit"'('ddatum=datum ',' ttime=zeit ')'; Native Datum: "'['(('0''1'..'9') ('1'..'2''0'..'9') ('3''0'..'1'))'.'(('0''1'..'9') ('1'' 0'..'2'))'.'('1'..'2''0'..'9''0'..'9''0'..'9')']'"; Native Zeit: "'['(('0'..'1''0'..'9') ('2''0'..'3'))':'('0'..'5''0'..'9')':'('0'..'5''0'..'9')']'"; Native Float: "('-')?('0'..'9')+'.'('0'..'9')+"; 21

23 Für bessere Übersicht haben wir den folgenden Graph erstellt: 22

24 (Abbildung 4.1.1, Graphische Darstellung der DSL) Constraints Constraints werden verwendet, um die von dem DSL erhaltene Grammatik zu verfeinern und zusätzliche Einschränkungen hinzufügen. In Xtext werden Constraints in der Check-Datei in ähnlicher Sprache als das Object Constraint Language (OCL) erstellt. Weiterhin können weitere Erweiterungen (Extensions), die als Hilfsmethoden betrachtet werden können, in der Extensions-Datei implementiert. Constraints haben die folgende Syntax: context ECore-Objekt ( ERROR WARNING ) Message : OCL-Statement ; Die behandelte Constraints (Inhalt der Check.chk Datei): import beanvalidationdsl; extension org::openarchitectureware::util::stdlib::naming ; extension org::example::dsl::extensions ; //untersucht ob eine andere Entitaet derselbe Name als der aktuelle Entitaetname hat context EntitaetName ERROR " Duplizierter Entitaetname " + '"'+ entname+'"': allelements().typeselect(entitaet).select(e e.entitaetname.entname == entname).size == 1 ; //see Extensions context EntitaetName WARNING "Entitaet soll mit Grossbuchstaben anfangen!" : firstletter(); //see Extensions context EntitaetName ERROR "Der Entitaetname "+ '"' +entname + '"' +" ist verboten" : verboteneschluesselwoerter(); //untersucht Duplikate im AttributeBlock context Attribute ERROR "Duplizierter Attributname " + '"' + name +'"' : getattrblock().attribute.select(e e.name == name).size == 1 ; //see Extensions context Attribute WARNING "Attributname soll mit Kleinbuchstaben anfangen!": firstlettersmall(); //untersucht ob es Attribute gibt, die derselbe Name als Entitaet haben context Attribute ERROR "Attributname ist gleich Entitaetname!" : allelements().typeselect(entitaet).notexists(e e.entitaetname.entname == name); //untersucht ob es selbstdefinierte Attribute gibt, die keine entsprechende Entitaet haben context Attribute if(selbstdefinierterattrtyp!= null ) ERROR "Entitaet " + '"' + selbstdefinierterattrtyp.sdattrtyp + '"' + "ist nicht definiert": allelements().typeselect(entitaet).select(e e.entitaetname.entname == selbstdefinierterattrtyp.sdattrtyp).size!= 0 ; 23

25 //untersucht ob es Attribute in Regelnblock gibt, die nicht im Attributblock zu finden context Regel ERROR "Attributname " + '"' + attrname +'"'+ " wuerde nicht im Attributeblock gefunden!" : getregelnblock().getentr().attblock.attribute.select(e e.name == attrname).size!= 0 ; //untersucht ob es verkettete Attribute in Regelnblock gibt, die sich nicht in den entsprechenden Entitaeten befinden context Regel if(!verketteteattribute.isempty) ERROR '"' + verketteteattribute.first().attrname +'"'+ " koennte nicht im Entitaet "+ '"'+ step1().first().selbstdefinierterattrtyp.sdattrtyp + '"' + " gefunden!" : step4(step(),verketteteattribute).size == 1; /*untersucht ob es verkettete Attribute in Regelnblock gibt, die sich nicht in den entsprechenden Entitaeten befinden*/ //höhere Verkettungsgrad context Regel if(verketteteattribute.size > 1) ERROR "ein der verketteten Attribute wuerde nicht gefunden!": stepa(step1(),verketteteattribute,{}).forall(e e == true); //untersucht ob die minimale Grenze kleiner als die maximale Grenze context Regel ERROR "Die minimale Grenze ist groesser als die maximale Grenze!" : ausdrueck.vordefiniertefunk.lengtharg.nmin <= ausdrueck.vordefiniertefunk.lengtharg.nmax ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istboolfunk()) ERROR "Attribut " +'"'+ getattr()+ '"'+ " muss vom Typ 'BOOLEAN' sein!": getstep1().first().vordefinierterattrtyp.tostring() == "boolean" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istboolfunk2()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'BOOLEAN' sein!" : stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring()== "boolean"; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istnumfunk()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'NUMBER' sein!": getstep1().first().vordefinierterattrtyp.tostring() =="number" getstep1().first().vordefinierterattrtyp.tostring() =="gleitkommazahl"; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istnumfunk2()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'NUMBER' sein!" : stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring() == "number" stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring() == "gleitkommazahl" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istfloatfunk()) ERROR "Der zugewiesene Wert ist fuer GLEITKOMMAZAHL geeignet nicht fuer NUMBER!" : getstep1().first().vordefinierterattrtyp.tostring() =="gleitkommazahl"; 24

26 //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istfloatfunk2()) ERROR "Der zugewiesene Wert ist fuer GLEITKOMMAZAHL geeignet nicht fuer NUMBER!" : stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring() == "gleitkommazahl" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istmatchfunk()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'TEXT' sein!" : getstep1().first().vordefinierterattrtyp.tostring() == "text" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istmatchfunk2()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'TEXT' sein!" : stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring() == "text" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istlengthfunk()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'TEXT' sein!" : getstep1().first().vordefinierterattrtyp.tostring() == "text" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istlengthfunk2()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'TEXT' sein!" : stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring() == "text" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istdatumfunk()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'DATUM' sein!" : getstep1().first().vordefinierterattrtyp.tostring() == "datum" ; //untersucht ob die verwendete Funktion das verwendete Attribut passt context VordefinierteFunk if(istdatumfunk2()) ERROR "Attribut " +'"'+ getattr() + '"'+ " muss vom Typ 'DATUM' sein!" : stepb(getstep1(),va()).first().vordefinierterattrtyp.tostring() == "datum" ; //untersucht ob die Funktion "Wertebereich" minimale und maximale Grenze hat context VordefinierteFunk if( lengthfunkname.tostring() == "wertebereich" && lengtharg.nmax == 0) ERROR "Wertebereichfunktion braucht eine minimale und maximale Grenze": false ; //untersucht ob es eine gueltige Kombination mit "oder" Verknuepfung ist context RegExp if((or=="oder")&&((complexexp1==null)&&(complexexp2==null))) ERROR "Ungueltige Kombination " + '"'+ exp1.tostring()+ " oder " + exp2.tostring()+'"!' : exp1.tostring()!=exp2.tostring(); //untersucht ob es eine gueltige Kombination mit "und" Verknuepfung ist context RegExp if(and=="und") ERROR "Ungueltige Kombination!" : exp1.tostring()!=exp2.tostring() complexexp1.complexexpname!=complexexp2.complexexpname ; //untersucht ob es eine gueltige Kombination mit "und" Verknuepfung ist context RegExp if((and=="und")&&((complexexp1==null)&&(complexexp2==null))) ERROR "Ungueltige Kombination " + '"' + exp1.tostring()+ " und " + 25

27 false; exp2.tostring()+'"!' : //untersucht ob RegExp fuer Zeichenkette verwendet ist context RegExp ERROR "Pruefe Syntax ist nur fuer Zeichenketten geeignet!" : getregel().ausdrueck.vordefiniertefunk.lengthfunkname.tostring()!= "wertebereich" ; //untersucht ob RegExp fuer Zeichenkette verwendet ist context RegExp ERROR "Pruefe Syntax ist nur fuer Zeichenketten geeignet!" : (getregel().ausdrueck.vordefiniertefunk.lengtharg!= null getregel().ausdrueck.vordefiniertefunk.matcharg!= null); Extentions Extentions (Erweiterungen) sind Hilfsmethoden sowohl für die Constraints in der Check- Datei als auch für die XPand-Templates. Extensions haben die folgende Syntax: RückgabeTyp MethodenName ( Parameter-1,, Parameter-n ) : OCL-Statement ; Die zugehörige Extensions für die Check-Datei: import beanvalidationdsl; extension org::example::dsl::genextensions reexport; //Get-Container methoden AttributeBlock getattrblock(attribute this): econtainer ; RegelnBlock getregelnblock(regel this): econtainer ; Entitaet getentr(regelnblock this): econtainer ; Entitaet getenta(attributeblock this): econtainer ; Modell getmodell(entitaet this): econtainer; RegExp getregexp (ComplexExp this): econtainer ; Attribute getattribute(selbstdefinierterattrtyp this): econtainer; Regel getregel(regexp this): econtainer; Ausdrueck getausdrueckv (VordefinierteFunk this) : econtainer; Regel getregela ( Ausdrueck this): econtainer ; //Liefert True zurueck, wenn der Entitaetname mit Grossbuchstabe anfaengt Boolean firstletter(entitaetname this): let list ={'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O', 'P','Q','R','S','T','U','V','W','X','Y','Z'}: list.select(e e == entname.substring(0,1)).size == 1 ; 26

28 //Liefert True zurueck, wenn der Attributename mit kleinbuchstabe anfaengt Boolean firstlettersmall(attribute this): let list = {'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z'}: list.select(e e.tolowercase() == name.substring(0,1)).size == 1; //Liefert True zurueck, wenn der Entitaetname nicht in der Liste ist Boolean verboteneschluesselwoerter(entitaetname this): let list = {"class","interface","abstract","final","throw","throws", "static","public","protected","private","package"}://.. list.select(e e == entname).size == 0 ; //Liefert True zurueck, wenn boolean Funktion verwendet ist und es keine verkettete Attribute gibt Boolean istboolfunk(vordefiniertefunk this): boolfunkname.tostring()!= "NULL" && getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn boolean Funktion verwendet ist und es verkettete Attribute gibt Boolean istboolfunk2 (VordefinierteFunk this): boolfunkname.tostring()!= "NULL" &&!getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn match Funktion verwendet ist und es keine verkettete Attribute gibt Boolean istmatchfunk (VordefinierteFunk this): matchfunkname.tostring()!= "NULL" && getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn match Funktion verwendet ist und es verkettete Attribute gibt Boolean istmatchfunk2 (VordefinierteFunk this): matchfunkname.tostring()!= "NULL" &&!getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn length Funktion verwendet ist und es keine verkettete Attribute gibt. Boolean istlengthfunk (VordefinierteFunk this): lengthfunkname.tostring()!= "NULL" && lengthfunkname.tostring()!= "wertebereich" && getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn length Funktion verwendet ist und es verkettete Attribute gibt. Boolean istlengthfunk2 (VordefinierteFunk this): lengthfunkname.tostring()!= "NULL" && lengthfunkname.tostring()!= "wertebereich" &&!getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn datum Funktion verwendet ist und es keine verkettete Attribute gibt. Boolean istdatumfunk (VordefinierteFunk this): (datumfunkname.tostring()!= "NULL" komplexdatumvariante!= null )&& getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn datum Funktion verwendet ist und es verkettete Attribute gibt. Boolean istdatumfunk2 (VordefinierteFunk this): (datumfunkname.tostring()!= "NULL" komplexdatumvariante!= null )&& 27

29 !getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn Number Funktion verwendet ist und es keine verkettete Attribute gibt. Boolean istnumfunk(vordefiniertefunk this): (numfunkname.tostring()!= "NULL" lengthfunkname.tostring() == "wertebereich")&& getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn Number Funktion verwendet ist und es verkettete Attribute gibt. Boolean istnumfunk2(vordefiniertefunk this): (numfunkname.tostring()!= "NULL" lengthfunkname.tostring() == "wertebereich") &&!getausdrueckv().getregela().verketteteattribute.isempty; //Liefert True zurueck, wenn Float Funktion verwendet ist und es keine verkettete Attribute gibt. Boolean istfloatfunk(vordefiniertefunk this): float!= null && getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert True zurueck, wenn Float Funktion verwendet ist und es verkettete Attribute gibt. Boolean istfloatfunk2(vordefiniertefunk this): float!= null &&!getausdrueckv().getregela().verketteteattribute.isempty ; //Liefert Attributename zurueck wenn es keine verkettete Attribute gibs, //sonst der letzte Atrributname in der verketteten Attribute String getattr (VordefinierteFunk this): getausdrueckv().getregela().verketteteattribute.isempty? getausdrueckv().getregela().attrname : getausdrueckv().getregela().verketteteattribute.last().attrname; //Hilfsmethoden um den Aufruf in den Checkdatei zu verkürzen List[VerketteteAttribute] va(vordefiniertefunk this): getausdrueckv().getregela().verketteteattribute; List[Attribute] getstep1(vordefiniertefunk this): getausdrueckv().getregela().step1(); Verkettete Attribute: Zwischen den Attributnamen im Attributeblock und Regelnblock gibt es eine Beziehung und zwar: es können keine Regeln für Attribute definiert, die nicht vorhanden sind. Wenn es keine verketteten Attribute vorhanden sind, ist die Untersuchung sehr leicht, einfach prüft man ob der Attributname im Regelnblock auch im AttributeBlock vorhanden ist. Entitaet Firma { Attribute { TEXT name Regeln { NUMBER anzahlderangestellter Angestellter angestellter1 } Entitaet Adresse { Attribute { TEXT strasse TEXT hausnr BOOLEAN eigeneshaus NUMBER plz } 28

30 } name : minimale Laenge ( 2 ) : "Laenge Fehler" : Pruefe Syntax nur Buchstaben anzahlderangestellter : ist groesser als 10 : "Number Fehler" angestellter1.name : Laenge ( 2-22 ) : "Laenge Fehler" angestellter1.adresse.plz : Wertebereich ( ) : "Wertebereich Fehler" } (Abbildung 4.1.2) } Regeln { } Entitaet Angestellter { Attribute { TEXT name TEXT vorname Adresse adresse } Regeln {} } Ein verkettetes Attribut: Wie man in Abbildung # sieht, der Vorgang ist etwas komplexer geworden, das Attribut angestellter1 muss im AttributeBlock geprüft werden und das verkettete Attribut name muss im zugehörigen Entität auch geprüft werden. Entitaet Firma { Attribute { TEXT name Regeln { } NUMBER anzahlderangestellter Angestellter angestellter1 } Step2 Step1 Step3 name : minimale Laenge ( 2 ) : "Laenge Fehler" : Pruefe Syntax nur Buchstaben anzahlderangestellter : ist groesser als 10 : "Number Fehler" angestellter1.name : Laenge ( 2-22 ) : "Laenge Fehler" angestellter1.adresse.plz : Wertebereich ( ) : "Wertebereich Fehler" } Entitaet Angestellter { Attribute { TEXT name } TEXT vorname Adresse adresse } Regeln {} Entitaet Adresse { Attribute { TEXT strasse } Step4 TEXT hausnr BOOLEAN eigeneshaus NUMBER plz } Regeln { } (Abbildung 4.1.3: Ein verkettetes Attribut) //Liefert das Attribut zurück, das der Attributname im Regelnblock entspricht. List[Attribute] step1(regel r): getregelnblock(r).getentr().attblock.attribute.select(e e.name == r.attrname); 29