OCL-Constraint bei Link-Mapping (GMF)

Status
Nicht offen für weitere Antworten.
G

Guest

Gast
Kann mir jemand sagen warum, meine Constraints nicht gehen? Ich sitze schon seit heute morgen (+ 2 oder 3 h gestern) an dem selben beschissenen Constraint, und verstehe nicht, warum das nicht geht. Also in meinem GMF-Diagramm werden einzelne Elemente (hier NodeObject) über gerichtete Graphen (Connection) verbunden. Jede Verbindung soll nur ein mal vorkommen können. Das heisst also, es dürfen keine 2 Verbindungen vorkommen, in denen sourceNodeObject und targetNodeObject gleich sind.
Die Ecore-Struktur sieht so aus (relevanter Auszug):

-NodeObject (ist abstrakt, hat 2 mögliche Realisierungen)
--NodeObjectConnections: Connection

-Connection
--sourceNodeObject: NodeObject
--targetNodeObject: NodeObject

Von der Logik her ist mir völlig klar, wie das funktionieren soll. Aber irgendwie krieg ich´s nicht in OCL gebacken. Ich habe im Mapping-Modell einen Constraint-Knoten (als Kind von Link Mapping <Connection...>) erstellt. Dort habe ich schon verschiedene OCL-Befehle ausprobiert. Das Problem ist, dass wenn ich mir nun eine Connection erstellen will und die mir von einem NodeObject auf das andere ziehe, nach dem Loslassen der Maustaste nichts passiert. Der Mauscursor zeigt zwar an, dass alles in Ordnung ist, aber die Connection verschwindet beim Loslassen der Maustaste. Folgende OCL-Befehle waren bisher am erfolgreichsten (bei den anderen hat der Mauscursor gleich gesagt, dass es nicht geht):

Code:
Connection.allInstances->forAll(c1, c2 | if (c1 <> c2
and
c1.sourceNodeObject = c2.sourceNodeObject) then
c1.targetNodeObject <> c2.targetNodeObject)
endif

und

Code:
Connection.allInstances->forAll(c1, c2 | (c1 <> c2 and c1.sourceNodeObject = c2.sourceNodeObject)
implies
c1.targetNodeObject <> c2.targetNodeObject)

Ich kapiere nicht, wieso das nicht geht. Hilfe!
 

Wildcard

Top Contributor
Ich bin leider (noch) kein OCL Weltmeister, auch wenn ich das bei Gelegenheit nachholen möchte, aber kannst du das Verhalten nicht zur Not in der entsprechenden EditPolicy, oder einem Advisor unterbringen? Klar, wenn du den OCL Ansatz gewählt hast, ist es schöner auch dabei zu bleiben, aber dazu kann ich dir leider nicht viel sagen.
 
G

Guest

Gast
Ich habe nen Verdacht, woran es liegen könnte. Wahrscheinlich ist die Rückgabe meiner OCL-Statements nicht false, sondern undefined. Denn wenn ich zum ersten mal eine Connection anlege, ist Connection.allInstances ja leer bzw. hat nur ein Element - je nachdem ob die Connection, die ich gerade erzeuge schon als Instanz gilt oder nicht. In dem Fall wäre die Rückgabe ja auch undefined, da ich meine forAll-Schleife ja so gebastelt habe, dass 2 Elemente unterschieden werden. Ich schau mal wie ich den undefined-Zustand am besten abfangen kann. Sobald ich ne Lösung habe, poste ich sie hier rein. Ansonsten freue ich mich natürlich über jede Hilfe.
 

HolGore

Neues Mitglied
Nach unzähligen Versuchen und ausschließlich frustrierenden Ergebnissen, habe ich mich dazu entschieden, wie von Wildcard empfohlen die EditPolicy umzuprogrammieren. Keine Ahnung was da bei ocl falsch läuft. Folgenden Code habe ich in der entsprechenden Methode implementiert:

Code:
EList<Transformation> transformations = container
						.getSchemaTransformations();
				for (int i = 0; i < transformations.size(); i++) {
					Transformation trafo = transformations.get(i);
					if (source == trafo.getTransformationSourceSchema() &&
					target == trafo.getTransformationTargetSchema())
							return false;
					}
 
Status
Nicht offen für weitere Antworten.

Neue Themen


Oben