Quickfixes und Validatoren für eJSL

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Kurs
Kursname Modellgetriebene Softwareentwicklung in der Praxis SS 15
Kurstyp Praktikum
Dozent Priefer
Semester SS 15
Studiengang Master
Link http://homepages.thm.de/~dprf53


MDD Projekt von Matthias Bollen und Max Steinwachs zu Modellgetriebene Softwareentwicklung in der Praxis SS15

Team

Unser Team besteht aus zwei Teammitgliedern:

  • Max Steinwachs
  • Matthias Bollen

Aufgabestellung

Usere Aufgabe besteht darin Sinnvolle Quickfixes in das bestehende eJSL-Projekt zu implementieren. Dazu sollen auch die Validatoren überprüft und gegebenfalls angepasst werden. Zusätzlich wurde uns die Aufgabe zuteil, den Formatter zu überprüfen und eine geeignete Formatierung zu erstellen.

Projektablauf

Für das Projekt haben wir uns so organisiert, dass jedes der beiden Teammitglieder sich mit den Aufgaben (Validator, Quickfix, Formatter) auseinander setzen kann. Den Ablauf unseres Projekts zeigen wir nachfolgend an den Tagen, die wir benötigt haben, auf.

Tag 1 (10.08.15)

Zunächst kleinere einleitende Arbeiten erledigen

Zu aller mussten wir unsere Laptops technisch vorbereiten und uns in die Dokumentation von XText einarbeiten:

  1. Einrichtung des GitLabs
  2. Wiki erstellen und erste einträge Verfassen
  3. Projekt clonen
  4. Einrichtung in Eclipse
  5. Erste Einarbeitung in den ausgecheckten Code
    1. Analyse der Projektstruktur
    2. Einarbeitung in Quick Fixes mit XText

Erste Quickfixes selbst schreiben (Testen)

Erster Quickfix

Schon am ersten Tag haben wir uns an die Quickfixes herangetastet und schon drei entwickelt:

  • Doppelten Entity-Namen ändern
  • URL-Quickfix
  • Löschen eines doppelten Language-Keys

Validatoren: erste Ideen

Zuletzt haben wir am ersten Tag Brainstorming betrieben, um zu schauen welche Validatoren man noch zusätzlich zu den schon bestehenden schreiben kann.

  • Validieren, ob es ein “Primary Attribute” gibt
  • Referenz zum Attribut muss ein Primary Attribut sein
  • Indexpage müssen mit einer Entity verbunden sein
  • in "table columns" keine doppelten einträge zulassen
  • bei "table columns" nur die vorher angegebene *Entities zulassen

Tag 2 (11.08.15)

Am zweiten Tag haben wir die Arbeit vom ersten Tag zunächst comittet und daraus resultierende Konflikte gelöst. Danach haben wir uns Zeit für die Evaluation des Kurses genommen. Darauf hin wurden nachfolgende Validatoren und Quickfixes umgesetzt.

Erste Ansätze von Validatoren

Als ersten Ansatz eines Validatoren haben wir einen Validator zur Prüfung von Primärattributen umgesetzt.

Umgesetzte Quickfixes

  1. MISSING_PRIMARY_ATTRIBUTE: Hinzufügen eines Primärattibutes (zum obigen Validator).
  2. INVALID_AUTHOR_URL: Es kann per Quickfix http:// oder https:// hinzugefügt werden.
  3. AMBIGUOUS_ENTITY: Es wird _ID_X an die Entity am ende hinzugefügt.
  4. AMBIGUOUS_LANGUAGE: Die Sprache wird gelöscht
  5. AMBIGUOUS_DATATYPE: Es wird _ID_X an den Datatype am ende hinzugefügt, oder es wird nach wahl der eintrag gelöscht.

Tag 3 (12.08.15)

  • Wegen eines Vorstellungsgespräches hat Matthias von zu Hause aus gearbeitet (HomeOffice). Kommunikation und Absprache erfolgte über Skype und Messanger.
  • Des weiteren wurden nachfolgende Validatoren und Quickfixes umgesetzt

Umgesetzte Validatoren

  1. Validator zur Prüfung, ob ein referenziertes Attribut ein Primärattribut ist
  2. Validator für Attribute. Der Name darf nicht "id" sein (Fehler) und keine anderen voreingestellten SQL Attribute (warning) wie z.B. für "created_by"
  3. Warnungen von gültigen Mail/URL angaben verbessert. Jetzt mit Beispiel Format

Umgesetzte Quickfixes

  1. NOT_PRIMARY_REFERENCE: Ändern eines referenzierten Nicht-Primär-Attributes in ein Primärattribut der gleichen Entität
  2. ID generator hinzugefügt. Schlägt nun _ID_"Zeile des Fehlers" vor als Quickfix
  3. AMBIGUOUS_LOCALPARAMETER: Eine einzigartige ID wird erstellt und dem Parameter angefügt.
  4. ENTITY_USED_MULTIPLE_TIMES: Die Entity wird gelöscht.
  5. EXTPACKAGE_CONTAINS_EXTPACKAGE: Das Expackage wird gelöscht.
  6. PAGE_USED_MULTIPLE_TIMES: Die zweite Page wird gelöscht.
  7. AMBIGUOUS_PAGE: Eine einzigartige ID wird erstellt und der Page angefügt.
  8. AMBIGUOUS_AUTHOR: Der doppelte Author wird gelöscht
  9. AMBIGUOUS_LANGUAGE: Das Löschen wurde verbessert und löscht jetzt nicht nur den Fehlerhaften String.

Tag 4 (13.08.15)

  • Ein Problem wurde gelöst sodass nun auch die vorstehenden Zeichen bei einem Quickfix gelöscht werden. Beispiel: Eine Liste wird durch ein Komma (,) getrennt. Dieses wird nun mit entfernt.
  • GitLab der THM nicht erreichbar. Weder über Oberfläche noch über Push/Pull. Ab ca. 13:50 bis ca. 14:10.

Umgesetzte Validatoren

  1. In einer Page wird nun zu jedem Filter geprüft ob es eine passende *Entity gibt. Falls dies nicht der Fall ist, wird der Filter als Error makiert.
  2. In einer Page wird nun zu jedem table columns geprüft ob es eine passende *Entity gibt. Falls dies nicht der Fall ist, wird die table column als Error makiert.
  3. Falsches Email Format erzeugt nun einen Fehler (Vorher nur Warning)
  4. Doppelte Filter werden erkannt. (Fehler: Es wird bisher immer der Erste eintrag als Fehler makiert)
  5. Doppelte Table Coulmns werden erkannt. (Fehler: Es wird bisher immer der Erste eintrag als Fehler makiert)

Umgesetzte Quickfixes

  1. MORE_THAN_ONE_BACKEND: Das doppelte Backend wird komplett gelöscht.
  2. MORE_THAN_ONE_FRONTEND: Das doppelte Backend wird komplett gelöscht.
  3. AMBIGUOUS_GLOBALPARAMETER: Eine einzigartige ID wird erstellt und dem Parameter angefügt.
  4. AMBIGUOUS_CLASS: Eine einzigartige ID wird erstellt und der Classe angefügt.
  5. AMBIGUOUS_EXTENSION: Eine einzigartige ID wird erstellt und der Extenstion angefügt.
  6. AMBIGUOUS_KEY: Der Forhandene Schlüssel wird gelöscht. Eine einzigartige ID erstellt und eingefügt.
  7. AMBIGUOUS_METHOD: Eine einzigartige ID wird erstellt und der Methode angefügt.
  8. COLUMNS_USED_MULTIPLE_TIMES: Löscht den Doppelten Wert
  9. FILTER_USED_MULTIPLE_TIMES: Löscht den doppelten Wert

Tag 5 (14.08.15)

Am letzten Projekttag haben wir uns dem Formatter und den noch zu ändernden Quickfixes und Validatoren zugewandt.

  1. Formatter für unsere Ansprüche verbessert
    1. Bei jedem Keyword wird nun eine neue Zeile angefangen
    2. Leere Zeilen werden gelöscht
    3. Wenn der komplette Text in einer Zeile geschrieben wurde kann der Text mit nur einmaligem ausführen des Formatter wieder schön Formatiert werden
  2. Validatorproblem gelöst
    1. Anstatt das erste Attribut von Filters und Table Columns wird nun die ganze Page unterstrichen
  3. Quickfixes für das Validatorproblem erstellt
  4. Termin absprache für die Abschlusspräsentation (11.09.15). Uhrzeit muss noch vereinbart werden
  5. Angefangen die Präsentation zu erstellen (Durchschnittszeit von 30 min)
  6. Letzte kleine Änderungen an Validatoren und Quickfixes

Nacharbeiten (15.08.15 bis spätestens 11.09.15)

Die üblichen Arbeiten nach dem Projekt sollten hier nicht unberücksichtigt bleiben:

  1. Wiki aufarbeiten
    1. Codebeispiele
    2. Bilder
    3. Dokumentation
    4. Letzte kleinen Änderungen
  2. Dokumentation im Wiki erstellen
  3. Im Quellcode Kommentare hinzufügen. Wurde vorher nicht berücksichtigt, da auch nur wenige Kommentare vorhanden waren.
  4. Präsentation Fertigstellen

Dokumentation

In der kleinen nachfolgenden Dokumentation wird deutlich gemacht, wie Validatoren, Quickfixes und Formatierungsregeln erstellt werden und wozu diese benötigt werden. Dies kann nachfolgenden Kommolitonen helfen, dies schneller zu verstehen.

Validatoren

Validatoren helfen Fehler im vorhandenen .eJSL Modell zu finden. Sie unterstützen somit die Sprache indem sie zwar mögliche Modelle (laut Sprache) als Falsch makieren, da es später zu Fehlern kommen wird. Es wird zwischen 3 Validatoren unterschieden (Fehler, Warning und Info). Ein Error unterbricht zudem noch die automatische generierung des Codes.

Wie schreibe ich eine Validator

Validatoren werden bei diesem Projekt in die Datei "/de.thm.icampus.ejsl/src/de/thm/icampus/ejsl/validation/EJSLValidator.xtend" geschrieben.

Hier ein Beispiel mit ausführlichen Kommentaren:

1    @Check // Es handelt sich um ein Validator und wird ausgeführt sobald sich das Modell ändert
2    def refToAttributeMustBePrimary(Reference reference){ // Übergabe des Objektes was geprüft werden soll
3        if(!reference.attributerefereced.isprimary){      // prüft ob die Referenz ein Primäres Attribut hat
4            error( // error warning oder info gibt an um was für einen "Fehler" es sich handelt
5                'The referenced attribute has to be a primary attribute.', // Meldung die Ausgegeben wird
6                reference, // Objekt
7                EJSLPackage.Literals.REFERENCE__ATTRIBUTEREFERECED, // gibt an was im Modell makiert wird
8                NOT_PRIMARY_REFERENCE // Unter welchem Namen dieser Validator zu finden ist. Für späteren Quickfix wichtig.
9            )
10        }
11    }

Quickfixes

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Quickfix

Ein Quickfix dient zur Beseitigung und Korrektur von vorhanden Fehlern oder Warnungen. Ein Quickfix kann nur implementiert werden, wenn dieser auf einen vorhandenen Validator referenziert.


Wie schreibe ich eine Quickfix

Quickfixes werden bei diesem Projekt in die Datei "/de.thm.icampus.ejsl.ui/src/de/thm/icampus/ejsl/ui/quickfix/EJSLQuickfixProvider.xtend" geschrieben.

Hier ein Beispiel mit ausführlichen Kommentaren:

1    @Fix(EJSLValidator::AMBIGUOUS_DATATYPE) //Keyword Fix wird benötigt damit die Funktion immer ausgeführt wird wenn sich etwas am Modell ändert.
					     // AMBIGUOUS_DATATYPE gibt an zu welchem Validator der Quickfix geschrieben wird.
2    def addIDtoDatatype(Issue issue, IssueResolutionAcceptor acceptor) {//in issue ist der gefundene Fehler des Validators. (Offset, Zeile, Länge ...)
3        acceptor.accept(issue, 'Add ID to Datatype', 'Change the name.', '') [ context | // Hier wird der Quickfix erstellt mit Namen 'Add ID..., 
									//Kommentar 'Change ...' und dem Icon was einfach leer ist aber dennoch angezeigt wird.
4            val xtextDocument = context.xtextDocument    // im xtextDocument ist der gesamte Inhalt des eJSL Dokuments. 					
5            xtextDocument.replace(issue.offset + issue.length - 1, 1, "_ID_"+ issue.lineNumber.toString +"\" ") // Hier wird im document am ende des Fehlers eine ID angehängt.
6        ]    // Ende des Ersten Qickfixes
7        acceptor.accept(issue, 'Delete Datatype', 'Remove the Datatype.', '') [ context |
8            val xtextDocument = context.xtextDocument
9            val doc = context.xtextDocument
10           xtextDocument.replace(issue.offset, issue.length, "") // Hier wird der Fehler gelöscht
11           deleteUntil(issue.offset,",",doc) // Hier wird der String davor gelöscht bis ein Komma gefunden wird. Dieses wird auch noch gelöscht. 
12       ]
13   }

Formater

Der Formatter formatiert den gesamten Text eines eJSL Modells. Dieser wird aufgerufen mit der Tastenkobination: Strg+Umschalt+F Der Formater ist in der Datei "/de.thm.icampus.ejsl/src/de/thm/icampus/ejsl/formatting/EJSLFormatter.xtend" enthalten


Beispiel:

1    class EJSLFormatter extends AbstractDeclarativeFormatter {
2
3        @Inject extension EJSLGrammarAccess
4        
5        override protected void configureFormatting(FormattingConfig c) {
6            for (Keyword k : findKeywords("table columns")) {
7                c.setLinewrap.before(k)
8            }
9        }
10   }

In diesem Beispiel wird deutlich, dass mit dem Objekt FormattingConfig das Format geändert werden kann. Innerhalb der Methode configureFormatting können alle Regeln für die Formatierung definiert werden. In diesem Fall werden in einer For-Schleife werden alle Keywords vom Typ "table columns" gefunden und auf diesen Keywords wird eine Formatter-Regel angewendet. In diesem Beispiel wird vor jedem gefundenen Keyword ein Zeilenumbruch angewendet.