GReQLJavaChecker - Versionsgeschichte

Striewe am 25. August 2023 um 08:06 Uhr

2023-08-25T08:06:46Z

← Nächstältere Version		Version vom 25. August 2023, 10:06 Uhr
Zeile 31:		Zeile 31:

	Die obere Regel ist vom Typ "absence", d.h. sie definiert einen Codestruktur, die nicht in der untersuchten Lösung vorkommen soll. Als Abfrage wird eine Struktur aus Elementen des Syntaxbaums definiert. Als Meldung wird ein String definiert, der zur Fehlerliste hinzugefügt wird, wenn die in der Abfrage definierte Struktur gefunden wird. Dabei dienen {name} und {line} als Platzhalter für Werte, die in der Abfrage in der report-Klausel ausgegeben wurden. Die zweite Regel ist vom Typ "presence" und definiert folglich eine Codestruktur, die in der untersuchten Lösung vorkommen soll. D.h., in diesem Fall wird die definierte Fehlermeldung ausgegeben, wenn die in der Abfrage definierte Struktur nicht auftritt. Folglich können in dieser Regel auch keine Platzhalter in der Ausgabe verwendet werden.		Die obere Regel ist vom Typ "absence", d.h. sie definiert einen Codestruktur, die nicht in der untersuchten Lösung vorkommen soll. Als Abfrage wird eine Struktur aus Elementen des Syntaxbaums definiert. Als Meldung wird ein String definiert, der zur Fehlerliste hinzugefügt wird, wenn die in der Abfrage definierte Struktur gefunden wird. Dabei dienen {name} und {line} als Platzhalter für Werte, die in der Abfrage in der report-Klausel ausgegeben wurden. Die zweite Regel ist vom Typ "presence" und definiert folglich eine Codestruktur, die in der untersuchten Lösung vorkommen soll. D.h., in diesem Fall wird die definierte Fehlermeldung ausgegeben, wenn die in der Abfrage definierte Struktur nicht auftritt. Folglich können in dieser Regel auch keine Platzhalter in der Ausgabe verwendet werden.

			''→ Details zu den verwendeten GReQL-Bezeichnern:'' [[GReQL-Typegraph für Java]]

	Die Funktion <code>hasSignature</code> ist eine spezielle, von JACK bereitgestellte Erweiterung der GReQL-Syntax, die eine bequeme Überprüfung von Methodensignaturen ermöglicht. Wie im Beispiel dargestellt, braucht die übergebene Zeichenkette keine vollständige Methodensignatur zu sein, sondern es reicht die Angabe der zu überprüfenden Bestandteile. D.h., Namen der Methodenparameter können ebenso entfallen wie Modifier oder der Rückgabetyp. Es ist allerdings nicht möglich, nur Modifier anzugeben und keinen Rückgabetyp.		Die Funktion <code>hasSignature</code> ist eine spezielle, von JACK bereitgestellte Erweiterung der GReQL-Syntax, die eine bequeme Überprüfung von Methodensignaturen ermöglicht. Wie im Beispiel dargestellt, braucht die übergebene Zeichenkette keine vollständige Methodensignatur zu sein, sondern es reicht die Angabe der zu überprüfenden Bestandteile. D.h., Namen der Methodenparameter können ebenso entfallen wie Modifier oder der Rückgabetyp. Es ist allerdings nicht möglich, nur Modifier anzugeben und keinen Rückgabetyp.

RSchypula am 24. August 2023 um 14:08 Uhr

2023-08-24T14:08:40Z

← Nächstältere Version		Version vom 24. August 2023, 16:08 Uhr
Zeile 2:		Zeile 2:

	=== Beispiele und Eigenschaften von Regeln ===		=== Beispiele und Eigenschaften von Regeln ===
	Als erstes Element im XML Dokument muss <checkerrules> stehen, entsprechend muss </checkerrules> als letztes Element in dem ~~XMl~~ Dokument sein.		Als erstes Element im XML Dokument muss <checkerrules> stehen, entsprechend muss </checkerrules> als letztes Element in dem XML Dokument sein.

	Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:		Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:

RSchypula: Kleine Ergänzung das checkerrules Element am Anfang stehen muss

2023-08-24T14:08:14Z

Kleine Ergänzung das checkerrules Element am Anfang stehen muss

← Nächstältere Version		Version vom 24. August 2023, 16:08 Uhr
Zeile 2:		Zeile 2:

	=== Beispiele und Eigenschaften von Regeln ===		=== Beispiele und Eigenschaften von Regeln ===
			Als erstes Element im XML Dokument muss <checkerrules> stehen, entsprechend muss </checkerrules> als letztes Element in dem XMl Dokument sein.

	Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:		Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:

Striewe: /* Versionsunterschiede */

2021-10-12T07:32:20Z

Versionsunterschiede

← Nächstältere Version		Version vom 12. Oktober 2021, 09:32 Uhr
Zeile 49:		Zeile 49:
	\|-		\|-
	\| Geänderter Kantentyp \|\| <code>ParameterizedTypeTypeArguments1</code><br><code>ParameterizedTypeTypeArguments2</code> \|\| <code>ParameterizedTypeTypeArguments</code>		\| Geänderter Kantentyp \|\| <code>ParameterizedTypeTypeArguments1</code><br><code>ParameterizedTypeTypeArguments2</code> \|\| <code>ParameterizedTypeTypeArguments</code>
			\|-
			\| Geänderter Kantentyp \|\| <code>TypeDeclarationSuperInterfaceTypes1</code><br><code>TypeDeclarationSuperInterfaceTypes2</code> \|\| <code>TypeDeclarationSuperInterfaceTypes</code>
	\|-		\|-
	\| Erweiterte Funktion \|\| Die Funktion <code>hasSignature</code> kann nicht auf geworfene Exceptions prüfen \|\| Die Prüfung ist möglich		\| Erweiterte Funktion \|\| Die Funktion <code>hasSignature</code> kann nicht auf geworfene Exceptions prüfen \|\| Die Prüfung ist möglich

Striewe: /* Versionsunterschiede */

2021-10-12T07:24:23Z

Versionsunterschiede

← Nächstältere Version		Version vom 12. Oktober 2021, 09:24 Uhr
Zeile 47:		Zeile 47:
	\|-		\|-
	\| Geänderter Kantentyp \|\| <code>TypeDeclarationSuperclassType2</code> \|\| <code>TypeDeclarationSuperclassType</code>		\| Geänderter Kantentyp \|\| <code>TypeDeclarationSuperclassType2</code> \|\| <code>TypeDeclarationSuperclassType</code>
			\|-
			\| Geänderter Kantentyp \|\| <code>ParameterizedTypeTypeArguments1</code><br><code>ParameterizedTypeTypeArguments2</code> \|\| <code>ParameterizedTypeTypeArguments</code>
	\|-		\|-
	\| Erweiterte Funktion \|\| Die Funktion <code>hasSignature</code> kann nicht auf geworfene Exceptions prüfen \|\| Die Prüfung ist möglich		\| Erweiterte Funktion \|\| Die Funktion <code>hasSignature</code> kann nicht auf geworfene Exceptions prüfen \|\| Die Prüfung ist möglich

Striewe am 26. August 2021 um 08:13 Uhr

2021-08-26T08:13:45Z

@@ Zeile 36: / Zeile 36: @@
 === Auswertung eines Regelsatzes ===
 Bei der Durchführung des statischen Checks wird zunächst der abstrakte Syntaxgraph der abgegebenen Lösung erzeugt und anschließend alle Regeln angewendet. Alle erzeugten Fehlernachrichten werden als Ausgabe des statischen Tests gesammelt. Die vergebene Punktzahl ergibt sich aus den Punkten der einzelnen Regeln, wobei die Gesamtsumme der Punkte in der Regeldatei stets auf 100 normiert wird. D.h., im oben gezeigten Beispiel erhält eine korrekte Lösung 100 Punkte, während eine Lösung, die die erste Regel verletzt, nur 67 Punkte erhält. Tritt während des Checks ein technischer Fehler auf, wird der Check abgebrochen und die Lösung mit einem "internal error" als fehlerhaft markiert.
 ==Tools==

Swolff: Kategirie Checker hinzugefügt

2018-10-23T10:35:54Z

Kategirie Checker hinzugefügt

← Nächstältere Version		Version vom 23. Oktober 2018, 12:35 Uhr
Zeile 39:		Zeile 39:
	==Tools==		==Tools==
	[[Media:GReQL-Referencecard.pdf\|GReQL-Referencecard]]		[[Media:GReQL-Referencecard.pdf\|GReQL-Referencecard]]

			[[category:Checker]]

Swolff: GReQL-Referencecard als Tool Hinzugefügt

2018-10-02T08:56:00Z

GReQL-Referencecard als Tool Hinzugefügt

← Nächstältere Version		Version vom 2. Oktober 2018, 10:56 Uhr
Zeile 36:		Zeile 36:
	=== Auswertung eines Regelsatzes ===		=== Auswertung eines Regelsatzes ===
	Bei der Durchführung des statischen Checks wird zunächst der abstrakte Syntaxgraph der abgegebenen Lösung erzeugt und anschließend alle Regeln angewendet. Alle erzeugten Fehlernachrichten werden als Ausgabe des statischen Tests gesammelt. Die vergebene Punktzahl ergibt sich aus den Punkten der einzelnen Regeln, wobei die Gesamtsumme der Punkte in der Regeldatei stets auf 100 normiert wird. D.h., im oben gezeigten Beispiel erhält eine korrekte Lösung 100 Punkte, während eine Lösung, die die erste Regel verletzt, nur 67 Punkte erhält. Tritt während des Checks ein technischer Fehler auf, wird der Check abgebrochen und die Lösung mit einem "internal error" als fehlerhaft markiert.		Bei der Durchführung des statischen Checks wird zunächst der abstrakte Syntaxgraph der abgegebenen Lösung erzeugt und anschließend alle Regeln angewendet. Alle erzeugten Fehlernachrichten werden als Ausgabe des statischen Tests gesammelt. Die vergebene Punktzahl ergibt sich aus den Punkten der einzelnen Regeln, wobei die Gesamtsumme der Punkte in der Regeldatei stets auf 100 normiert wird. D.h., im oben gezeigten Beispiel erhält eine korrekte Lösung 100 Punkte, während eine Lösung, die die erste Regel verletzt, nur 67 Punkte erhält. Tritt während des Checks ein technischer Fehler auf, wird der Check abgebrochen und die Lösung mit einem "internal error" als fehlerhaft markiert.

			==Tools==
			[[Media:GReQL-Referencecard.pdf\|GReQL-Referencecard]]

Mbuttgereit: /* Beispiele und Eigenschaften von Regeln */

2017-04-27T11:54:28Z

Beispiele und Eigenschaften von Regeln

← Nächstältere Version		Version vom 27. April 2017, 13:54 Uhr
Zeile 4:		Zeile 4:
	Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:		Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:

			<syntaxhighlight lang="xml" line='line'>
	<rule type="absence" points="2">		<rule type="absence" points="2">
	<query>from u : V{CompilationUnit}, x : V{WhileStatement} with		<query>from u : V{CompilationUnit}, x : V{WhileStatement} with
Zeile 13:		Zeile 14:
	Abbruchbedingung und ist dadurch sinnlos.</feedback>		Abbruchbedingung und ist dadurch sinnlos.</feedback>
	</rule>		</rule>
			</syntaxhighlight>

			<syntaxhighlight lang="xml" line='line'>
	<rule type="presence" points="4">		<rule type="presence" points="4">
	<query>from t : V{TypeDeclaration}, m : V{MethodDeclaration} with		<query>from t : V{TypeDeclaration}, m : V{MethodDeclaration} with
Zeile 23:		Zeile 26:
	der Klasse "Miniprojekt2" fehlt. Hast du die vorgegebene Methodensignatur veraendert?</feedback>		der Klasse "Miniprojekt2" fehlt. Hast du die vorgegebene Methodensignatur veraendert?</feedback>
	</rule>		</rule>
			</syntaxhighlight>

	Die obere Regel ist vom Typ "absence", d.h. sie definiert einen Codestruktur, die nicht in der untersuchten Lösung vorkommen soll. Als Abfrage wird eine Struktur aus Elementen des Syntaxbaums definiert. Als Meldung wird ein String definiert, der zur Fehlerliste hinzugefügt wird, wenn die in der Abfrage definierte Struktur gefunden wird. Dabei dienen {name} und {line} als Platzhalter für Werte, die in der Abfrage in der report-Klausel ausgegeben wurden. Die zweite Regel ist vom Typ "presence" und definiert folglich eine Codestruktur, die in der untersuchten Lösung vorkommen soll. D.h., in diesem Fall wird die definierte Fehlermeldung ausgegeben, wenn die in der Abfrage definierte Struktur nicht auftritt. Folglich können in dieser Regel auch keine Platzhalter in der Ausgabe verwendet werden.		Die obere Regel ist vom Typ "absence", d.h. sie definiert einen Codestruktur, die nicht in der untersuchten Lösung vorkommen soll. Als Abfrage wird eine Struktur aus Elementen des Syntaxbaums definiert. Als Meldung wird ein String definiert, der zur Fehlerliste hinzugefügt wird, wenn die in der Abfrage definierte Struktur gefunden wird. Dabei dienen {name} und {line} als Platzhalter für Werte, die in der Abfrage in der report-Klausel ausgegeben wurden. Die zweite Regel ist vom Typ "presence" und definiert folglich eine Codestruktur, die in der untersuchten Lösung vorkommen soll. D.h., in diesem Fall wird die definierte Fehlermeldung ausgegeben, wenn die in der Abfrage definierte Struktur nicht auftritt. Folglich können in dieser Regel auch keine Platzhalter in der Ausgabe verwendet werden.

Striewe: Die Seite wurde neu angelegt: „Der GReQLJavaChecker ermöglicht statische Checks auf Programmcode und verwendet dazu Abfragen auf dem Syntaxgraphen. Um einen statischen Check mit dem Checker…“

2017-04-05T09:51:42Z

Die Seite wurde neu angelegt: „Der GReQLJavaChecker ermöglicht statische Checks auf Programmcode und verwendet dazu Abfragen auf dem Syntaxgraphen. Um einen statischen Check mit dem Checker…“

Neue Seite

Der GReQLJavaChecker ermöglicht statische Checks auf Programmcode und verwendet dazu Abfragen auf dem Syntaxgraphen. Um einen statischen Check mit dem Checker durchzuführen, müssen die zu untersuchenden Dateien in der Liste "Source Files" ausgewählt werden und eine einzelne Datei mit Prüfregeln ("Rule File") angegeben werden. Die Regeln werden in dieser Datei im XML-Format organisiert und verwenden die Sprache GReQL für Abfragen auf dem Syntaxbaum.

=== Beispiele und Eigenschaften von Regeln ===
Zwei beispielhafte Abfragen in dieser Sprache sehen so aus:

<rule type="absence" points="2">
<query>from u : V{CompilationUnit}, x : V{WhileStatement} with
not isEmpty(u -->* x -->{WhileStatementBody}&{EmptyStatement}) or
(not isEmpty(u -->* x -->{WhileStatementBody}&{Block}) and
isEmpty(u -->* x -->{WhileStatementBody}&{Block} -->{Child}))
report u.name as "name", x.line as "line" end</query>
<feedback>In der Datei {name} besteht die while-Schleife in Zeile {line} nur aus einer
Abbruchbedingung und ist dadurch sinnlos.</feedback>
</rule>

<rule type="presence" points="4">
<query>from t : V{TypeDeclaration}, m : V{MethodDeclaration} with
t.name="Miniprojekt2" and
t -->{TypeDeclarationBodyDeclarations2} m and
hasSignature(m, "public static String geometrie1(int)")
report 0 end</query>
<feedback prefix="Signaturcheck">Die Methode "public static String geometrie1(int laenge)" in
der Klasse "Miniprojekt2" fehlt. Hast du die vorgegebene Methodensignatur veraendert?</feedback>
</rule>

Die obere Regel ist vom Typ "absence", d.h. sie definiert einen Codestruktur, die nicht in der untersuchten Lösung vorkommen soll. Als Abfrage wird eine Struktur aus Elementen des Syntaxbaums definiert. Als Meldung wird ein String definiert, der zur Fehlerliste hinzugefügt wird, wenn die in der Abfrage definierte Struktur gefunden wird. Dabei dienen {name} und {line} als Platzhalter für Werte, die in der Abfrage in der report-Klausel ausgegeben wurden. Die zweite Regel ist vom Typ "presence" und definiert folglich eine Codestruktur, die in der untersuchten Lösung vorkommen soll. D.h., in diesem Fall wird die definierte Fehlermeldung ausgegeben, wenn die in der Abfrage definierte Struktur nicht auftritt. Folglich können in dieser Regel auch keine Platzhalter in der Ausgabe verwendet werden.

Die Funktion <code>hasSignature</code> ist eine spezielle, von JACK bereitgestellte Erweiterung der GReQL-Syntax, die eine bequeme Überprüfung von Methodensignaturen ermöglicht. Wie im Beispiel dargestellt, braucht die übergebene Zeichenkette keine vollständige Methodensignatur zu sein, sondern es reicht die Angabe der zu überprüfenden Bestandteile. D.h., Namen der Methodenparameter können ebenso entfallen wie Modifier oder der Rückgabetyp. Es ist allerdings nicht möglich, nur Modifier anzugeben und keinen Rückgabetyp.

''→ Weitere Beispiele:'' [[GReQL Regeln]]

=== Auswertung eines Regelsatzes ===
Bei der Durchführung des statischen Checks wird zunächst der abstrakte Syntaxgraph der abgegebenen Lösung erzeugt und anschließend alle Regeln angewendet. Alle erzeugten Fehlernachrichten werden als Ausgabe des statischen Tests gesammelt. Die vergebene Punktzahl ergibt sich aus den Punkten der einzelnen Regeln, wobei die Gesamtsumme der Punkte in der Regeldatei stets auf 100 normiert wird. D.h., im oben gezeigten Beispiel erhält eine korrekte Lösung 100 Punkte, während eine Lösung, die die erste Regel verletzt, nur 67 Punkte erhält. Tritt während des Checks ein technischer Fehler auf, wird der Check abgebrochen und die Lösung mit einem "internal error" als fehlerhaft markiert.