UMLChecker

Aus JACK Wiki
Wechseln zu: Navigation, Suche

Der UML Checker ermöglicht statische Checks für verschiedene Modelltypen der UML auf Basis von XMI-Dateien und verwendet dazu Abfragen auf dem Syntaxgraphen. Derzeit kann der Checker Klassendiagramme sowohl im XMI1 als auch XMI2-Format verarbeiten und zusätzlich Use-Case-Diagramme in XMI1 sowie Aktivitätsdiagramme und State Charts in XMI2. Leider unterscheiden sich die von verschiedenen Werkzeugen erzeugten Exporte trotz Standardisierung des XMI-Formats zum Teil erheblich voneinander, so dass nicht immer alle Details problemlos verarbeitet werden können.

Um einen statischen Check mit dem Checker durchzuführen, muss die zu untersuchende Datei in der Liste "XMI file" 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:

 1   <rule type="presence" points="5">
 2     <query>from x : V{Class}, y : V{Property}, z : V{PrimitiveType} with
 3               isDefined(x.name) and x.name="Spielgebiet" and
 4               x --> y and
 5               isDefined(y.name) and y.name="name" and
 6               y --> z and
 7               isDefined(z.name) and z.name="String"
 8            report 1 end</query>
 9     <feedback>Ein Spielgebiet soll ein Attribut für seinen Namen bereitstellen.</feedback>
10   </rule>
1   <rule type="absence" points="0">
2     <query>from x,y : V{Class} with
3               x --> V{Property} --> V{Association} <-- V{Property} <-- y and
4              isDefined(x.name) and x.name="Hindernis" and
5              isDefined(y.name) and y.name="Form"
6           report 1 end</query>
7     <feedback prefix="Hinweis">Im Diagramm ist die Form eines Hindernisses als eigene Klasse abgebildet. Dies ist nicht notwendig und mögliche Unterklassen von Form können auch direkt als Unterklassen von Hindernis modelliert werden.</feedback>
8   </rule>

Die obere Regel ist vom Typ "presence", d.h. sie definiert einen Struktur von Modellelementen, die in der untersuchten Lösung vorkommen soll. Als Abfrage werden drei Elemente des Syntaxbaums genannt und ihre gewünschten Eigenschaften und Beziehungen definiert. Als Meldung wird ein String definiert, der zur Fehlerliste hinzugefügt wird, wenn die in der Abfrage definierte Struktur nicht gefunden wird. Die zweite Regel ist vom Typ "absence" und definiert folglich eine Struktur, die in der untersuchten Lösung nicht vorkommen soll. In diesem Fall wird die definierte Fehlermeldung also ausgegeben, wenn die in der Abfrage definierte Struktur auftritt. Die Regel ist mit 0 Punkten gewichtet und das Feedback wird mit einem Prefix versehen, so dass Studierende keinen Punktabzug erhalten, wenn die Regel verletzt wird.

→ 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. 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

GReQL-Referencecard