[Ciseve-devel] =?iso-8859-1?Q?mocl:_Test_f=FCr_def's?=

[Matthias L. <Mat...@gm...>]

Hallo!

Ich habe nun den Test, den wir vorhin fertiggestellt haben, für den
standalone.Parser eingecheckt - inklusive der ocl-Dateien, die größtenteils
nicht gehen, weil sie das Problem mit den def's enthalten. Sie sollten also
gehen, wenn unserer Teil abgeschlossen ist und funktioniert.

Der Test ist unter ocl.standalone.test.ParserTest zu finden. Für Clover gibt
es extra einen Ant-Task, der nur diesen Test ausführt: simple_coverage.

Ansonsten haben wir herausgefunden, dass bei der test_02.ocl, der Fehler
entsteht, wenn im ContextAnalyser in der Methode resolveProperty(Type,
PPropertyCall), Zeile 2632, geschaut wird, ob die Eigenschaft im Environment
eingetragen ist. Bei der Prüfung stellt sich heraus, dass "testdef" und
"testdef2" auch im neuen Context noch im Environment stehen (in der HashMap
names). Allerdings stimmt der Scope nicht überein, obwohl der Context sich
auf die selbe Klasse bezieht. Die Scopeprüfung wird auch ganz simpel mit
einem beginnenden Token und einem schließendem Token vorgenommen - das
funktioniert natürlich für defs nicht.

Da also der Environment-Lookup fehlschlägt, wird in Zeile 2644 des
ContextAnalyser versucht, den Namen über type.getStructuralFeature
aufzulösen.

Es ist sicherlich besser, am Environment anzusetzen, da dort die Referenz
schon vorhanden ist. Wir müssen dafür als nächstes die Organisation der
Scopes verstehen (wie sind die Scopes an Klassennamen gebunden, sind Scopes
hierarisch oder parallel/exklusiv aufgebaut). Das werden wir als nächstes
angehen. Eventuell ist es (zumindest für den Typcheck) möglich den Scope zu
erweitern, um damit das Problem zu lösen.

Gruß,
Matthias