You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(19) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(8) |
2005 |
Jan
(7) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Anton H. <an...@we...> - 2005-05-12 17:54:46
|
Hallo, die korrigierte lauffähige Version von ServiceRunner von heute habe ich nun commitet, sowie einige weiteren Klassen etwas von unübersichtlichen Debug-Ausgaben auf die Konsole gesäubert. Auch PipeService.jar mit einer frischen Class-Datei ist jetzt drin. Anton. |
From: Matthias L. <Mat...@gm...> - 2005-05-08 06:04:13
|
2. Versuch diese Mail zu schicken, letzter am Samstag, 7. Mai 2005 18:19 > Hallo! > > Ich habe eben die am Donnerstag vorgestellten Änderungen komplettiert und > nun z.B. den EnvironmentSerializer erstellt, der die Serialisierung von > Environment übernimmt. Dieser bekommt ein TypFacade zum Wiederaufbau des > Environments. Soweit funktioniert das ohne Fehler. > > Allerdings gibt es noch ein Problem (wie sollte es anders sein): Zum > Beispiel im EvaluationAnalyser wird das Environment so benutzt, dass ein > Node übergeben wird, damit wird ein neuer NodeIdentifier erstellt, und es > wird geschaut, ob der im Environment ist. Bei einem wiederaufgebauten > (deserialisierten) Environment schlägt das fehl. Das liegt daran, dass die > Gleichheit von NodeIdentifiers so überprüft wird: nodeIdentifier1.node == > nodeIdentifier2.node. > Da aber jede Klasse, die auf irgendeinen Node verweist, selbst > verantwortlich ist, den Teilbaum zu (de-)serialisieren, geht das schief. > Gleiche Teilbäume, die an unterschiedlichen Stellen abgelegt sind, sind > nach > dem Wiederaufbau verschieden (Objektidentitäten unterscheiden sich). > > Mir fallen zwei Lösungen ein: > - 1) NodeSerialisierung bei der EnvironmentSerialisierung zu > zentralisieren, > und nicht verschiedene NodeReader bzw. NodeWriter benutzen. > - 2) Gleichheit über Objektidentität entfernen > > 1) ist wahrscheinlich "konsequenzfreier", weil eher klar ist, wo etwas zu > ändern ist, und welche Auswirkungen das hat. > Das Problem ist nun behoben - ich habe den ersten Lösungsweg benutzt. D.h. die Nodeserialisierung ist nun zentralisiert über den NodeSerializationManager bzw. NodeDeserializationManager. Der NSM serialisiert zunächst den gesamten Baum (mittels des NodeWriter's), danach übergeben die Klassen, die eine Node-Klasse serialisieren wollen, die Node-Referenz und erhalten vom NSM eine ID (ein int), dass sie nur noch in den Stream schreiben brauchen. Beim der Deserialisierung, also dem Wiederaufbauen, erstellt der NodeDeserializationManager zunächst den gesamten AST und benutzt danach die übergebenen IDs zum Aufbau von einzelnen Node-Referenzen in den einzelnen Klassen. Dabei wird sichergestellt, dass gleiche Nodes auch nach der Objektidentität gleich sind. Denn vorher war es so, dass durch unabhängiges Wiederaufbauen von Teilbäumen die Objektidentität nicht mehr gewährleistet war. Da der NSM und NDM im Verlaufe des (De-)Serialisierungsprozesses gebraucht wird, geht das wieder über die manuelle Externalisierung (Klasse: ManualExternalization). Dieser Mechanismus ist nun auch ausführlich dokumentiert. Der EnvironmentSerializer, der die manuelle Externalisierung des Environments startet, funktioniert nun. Beim Wiederaufbau ist nur zu beachten, dass der AST von dieser Klasse benutzt werden muss, sonst ist die Objektidentität z.B. für den EvaluationAnalyzer nicht gegeben. Als nächstes wird die Serialisierung des Environments in den Inferenz-Prozess integriert. Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2005-05-08 05:46:14
|
> Hallo! > > Ich habe eben die am Donnerstag vorgestellten Änderungen komplettiert und > nun z.B. den EnvironmentSerializer erstellt, der die Serialisierung von > Environment übernimmt. Dieser bekommt ein TypFacade zum Wiederaufbau des > Environments. Soweit funktioniert das ohne Fehler. > > Allerdings gibt es noch ein Problem (wie sollte es anders sein): Zum > Beispiel im EvaluationAnalyser wird das Environment so benutzt, dass ein > Node übergeben wird, damit wird ein neuer NodeIdentifier erstellt, und es > wird geschaut, ob der im Environment ist. Bei einem wiederaufgebauten > (deserialisierten) Environment schlägt das fehl. Das liegt daran, dass die > Gleichheit von NodeIdentifiers so überprüft wird: nodeIdentifier1.node == > nodeIdentifier2.node. > Da aber jede Klasse, die auf irgendeinen Node verweist, selbst > verantwortlich ist, den Teilbaum zu (de-)serialisieren, geht das schief. > Gleiche Teilbäume, die an unterschiedlichen Stellen abgelegt sind, sind > nach > dem Wiederaufbau verschieden (Objektidentitäten unterscheiden sich). > > Mir fallen zwei Lösungen ein: > - 1) NodeSerialisierung bei der EnvironmentSerialisierung zu > zentralisieren, > und nicht verschiedene NodeReader bzw. NodeWriter benutzen. > - 2) Gleichheit über Objektidentität entfernen > > 1) ist wahrscheinlich "konsequenzfreier", weil eher klar ist, wo etwas zu > ändern ist, und welche Auswirkungen das hat. > Das Problem ist nun behoben - ich habe den ersten Lösungsweg benutzt. D.h. die Nodeserialisierung ist nun zentralisiert über den NodeSerializationManager bzw. NodeDeserializationManager. Der NSM serialisiert zunächst den gesamten Baum (mittels des NodeWriter's), danach übergeben die Klassen, die eine Node-Klasse serialisieren wollen, die Node-Referenz und erhalten vom NSM eine ID (ein int), dass sie nur noch in den Stream schreiben brauchen. Beim der Deserialisierung, also dem Wiederaufbauen, erstellt der NodeDeserializationManager zunächst den gesamten AST und benutzt danach die übergebenen IDs zum Aufbau von einzelnen Node-Referenzen in den einzelnen Klassen. Dabei wird sichergestellt, dass gleiche Nodes auch nach der Objektidentität gleich sind. Denn vorher war es so, dass durch unabhängiges Wiederaufbauen von Teilbäumen die Objektidentität nicht mehr gewährleistet war. Da der NSM und NDM im Verlaufe des (De-)Serialisierungsprozesses gebraucht wird, geht das wieder über die manuelle Externalisierung (Klasse: ManualExternalization). Dieser Mechanismus ist nun auch ausführlich dokumentiert. Der EnvironmentSerializer, der die manuelle Externalisierung des Environments startet, funktioniert nun. Beim Wiederaufbau ist nur zu beachten, dass der AST von dieser Klasse benutzt werden muss, sonst ist die Objektidentität z.B. für den EvaluationAnalyzer nicht gegeben. Als nächstes wird die Serialisierung des Environments in den Inferenz-Prozess integriert. Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2005-04-21 23:57:54
|
Hallo! Ich habe eben die am Donnerstag vorgestellten Änderungen komplettiert und nun z.B. den EnvironmentSerializer erstellt, der die Serialisierung von Environment übernimmt. Dieser bekommt ein TypFacade zum Wiederaufbau des Environments. Soweit funktioniert das ohne Fehler. Allerdings gibt es noch ein Problem (wie sollte es anders sein): Zum Beispiel im EvaluationAnalyser wird das Environment so benutzt, dass ein Node übergeben wird, damit wird ein neuer NodeIdentifier erstellt, und es wird geschaut, ob der im Environment ist. Bei einem wiederaufgebauten (deserialisierten) Environment schlägt das fehl. Das liegt daran, dass die Gleichheit von NodeIdentifiers so überprüft wird: nodeIdentifier1.node == nodeIdentifier2.node. Da aber jede Klasse, die auf irgendeinen Node verweist, selbst verantwortlich ist, den Teilbaum zu (de-)serialisieren, geht das schief. Gleiche Teilbäume, die an unterschiedlichen Stellen abgelegt sind, sind nach dem Wiederaufbau verschieden (Objektidentitäten unterscheiden sich). Mir fallen zwei Lösungen ein: - 1) NodeSerialisierung bei der EnvironmentSerialisierung zu zentralisieren, und nicht verschiedene NodeReader bzw. NodeWriter benutzen. - 2) Gleichheit über Objektidentität entfernen 1) ist wahrscheinlich "konsequenzfreier", weil eher klar ist, wo etwas zu ändern ist, und welche Auswirkungen das hat. Ich habe, wie schon gesagt, ersteinmal viel zu tun, und werde das nicht vor der ersten Mai-Woche angehen können. Alle bisherigen Änderungen sind nun im CVS. Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2005-04-20 19:16:37
|
Hallo! Wir haben heute nachmittag einen Test geschrieben, der genau das macht. Er ist jetzt im CVS unter ocl.parser.node.externalization.test.TestExternalization bzw. in der TestSuite ocl.test.AllTests verfügbar. Gruß, Matthias ----- Original Message ----- From: "Jörn Guy Süß" <joe...@we...> To: "'Matthias Liebig'" <Mat...@gm...> Sent: Saturday, April 16, 2005 11:59 AM Subject: AW: [Ciseve-devel] mocl: Node Serialisierung Der Test sollte nicht zu schwierig sein: Vorher: Teilbaum identifizieren, zugehörigen Textabschnitt in einen String stopfen Test durchführen: Teilbaum serialisieren, wieder deserialisieren Prüfen: Resultat wieder in einen String umwandeln, vergleichen. Wenn der Alg. Alles korrekt restauriert, sollten auch die Strings gleich sein. Dipl.-Inform. Jörn Guy Süß | CIS - Sekr. EN7 phone / fax : +49(30) 314-23553/21601 | TU Berlin, FB Informatik phone (secretary) : +49(30) 314-23555 | Einsteinufer 17 email: jg...@cs... | D-10587 BERLIN / GERMANY -----Ursprüngliche Nachricht----- Von: cis...@li... [mailto:cis...@li...] Im Auftrag von Matthias Liebig Gesendet: Samstag, 16. April 2005 00:54 An: cis...@li... Betreff: [Ciseve-devel] mocl: Node Serialisierung Hallo! Die besprochenen Klassen zum Serialisieren der Node-Klassen von SableCC sind fertig. Sie befinden sich in ocl.parser.node.externalization . - Der NodeStorer speichert einen einzelnen Knoten und ersetzt alle Pointer zu anderen Knoten durch IDs. - Der NodeReader erstellt aus einem AST ein Vector aus NodeStorer's, der serialisierbar ist. - Der NodeWriter geht den umgekehrten Weg und nimmt den Vector aus NodeStorer's und erstellt wieder den AST. Das funktioniert auch für Teilbäume des AST, allerdings geht dann der "parent"-Link zu dem eigentlichen Baum verloren. Aber das sollte meiner Meinung nach kein Problem darstellen. Getestet haben wir das ganze exemplarisch, d.h. mal den Baum zerlegt und wieder zusammengesetzt und dann mit dem TreeDisplayer anzeigen lassen, bzw. den ContextAnalyser danach laufen lassen. Hat funktioniert. Wie man das allerdings exakt mit JUnit testet, ist noch unklar. Der nächste Schritt für uns ist jetzt alle Klassen, die Environment benutzt und die Klasse selbst, Externalizable zu machen und den NodeReader bzw. -Writer zu benutzen (relativ geringer Aufwand). Gruß; Matthias |
From: Matthias L. <Mat...@gm...> - 2005-04-16 00:57:17
|
Hallo nochmal! Ich hab doch schon angefangen, die Klassen, auf die Environment zugreift, Serializable bzw. Externalizable zu machen. Das waren unter anderem: Identifiers, Bindings, Scope, Type, Classifier (Type), Properties und Teile von model.check Die Klasse ModelType stellt allerdings ein Problem dar. Sie verweist auf die mofbridge über ClassifierDescriptor. Ok, ClassifierDescriptor ist kein Problem, allerdings verweisen die Instanzen z.B. auf javax.jmi.model.MofClass$Impl. Und die JMI Klassen sind natürlich nicht serialisierbar. Ich bekommen die Fehlermeldung, wenn ich die HashMap namesToIdentifiers in Environment auf public setze, und den ocl.env.test.SerializableTest (kein JUnit Test, nur main Methode) mit einer Beispiel ocl-Datei ausführe. Der SerializableTest holt alle Identifier aus der Map und versucht sie, zu serialisieren. Wie könnte man an das Problem herangehen oder besser noch umgehen? Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2005-04-15 22:54:37
|
Hallo! Die besprochenen Klassen zum Serialisieren der Node-Klassen von SableCC sind fertig. Sie befinden sich in ocl.parser.node.externalization . - Der NodeStorer speichert einen einzelnen Knoten und ersetzt alle Pointer zu anderen Knoten durch IDs. - Der NodeReader erstellt aus einem AST ein Vector aus NodeStorer's, der serialisierbar ist. - Der NodeWriter geht den umgekehrten Weg und nimmt den Vector aus NodeStorer's und erstellt wieder den AST. Das funktioniert auch für Teilbäume des AST, allerdings geht dann der "parent"-Link zu dem eigentlichen Baum verloren. Aber das sollte meiner Meinung nach kein Problem darstellen. Getestet haben wir das ganze exemplarisch, d.h. mal den Baum zerlegt und wieder zusammengesetzt und dann mit dem TreeDisplayer anzeigen lassen, bzw. den ContextAnalyser danach laufen lassen. Hat funktioniert. Wie man das allerdings exakt mit JUnit testet, ist noch unklar. Der nächste Schritt für uns ist jetzt alle Klassen, die Environment benutzt und die Klasse selbst, Externalizable zu machen und den NodeReader bzw. -Writer zu benutzen (relativ geringer Aufwand). Gruß; Matthias |
From: <joe...@we...> - 2005-02-15 19:32:51
|
Hi! =20 Die Factory z=FCndet nicht, weil sie als Namen folgenden String = erwartet: eve://ciseve.sf.net/service/PipeService/ =20 Sie bekommt aber: eve://ciseve.sf.net/service/PipeService/09d5487d-6250-363c-8533-da1fb1ee8= 669 =20 also Name + Jini UUID =20 Siehe unten =20 junit.framework.AssertionFailedError: PipeService failed: = RemoteException in server thread; nested exception is:=20 java.rmi.RemoteException: Failed to invoke service.; nested exception is:=20 de.tuberlin.cs.cis.eve.core.EveException: service eve://ciseve.sf.net/service/PipeService/09d5487d-6250-363c-8533-da1fb1ee8= 669 could not be found. at junit.framework.Assert.fail(Assert.java:47) at de.tuberlin.cs.cis.eve.net.jini.test.PipeServiceTest.testPipe(PipeService= Tes t.java:132) =20 das f=FChrt dazu, da=DF sie, wenn sie die Jars in /components = durchsucht, nix findet. =20 Um zu diagnostizieren, wo es klemmt, habe ich folgende Zeile: =20 System.out.println("Transmitted URI is:" + sd.getURI().toASCIIString()); =20 In JiniService.java eingebaut.=20 =20 Sie gibt: =20 Transmitted URI is:eve://ciseve.sf.net/service/PipeService/09d5487d-6250-363c-8533-da1fb1= ee8 669 =20 Die Daten sind also schon falsch, bevor sie zur Factory kommen. =20 Daher habe ich dasselbe in den PipeTest eingebaut. =20 Transmitted URI from test is:eve://ciseve.sf.net/service/PipeService/09d5487d-6250-363c-8533-da1fb1= ee8 669 =20 d.h. Sie ist schon hier verkehrt. =20 Das liegt daran, da=DF ServiceDescription() benutzt wird, die gibt = diesen ad-hoc String raus. (ServiceDescription Zeile 151) Der Ad-Hoc-String ist nat=FCrlich = unbrauchbar. Die ServiceDescriptions m=FCssen von einem Lookup kommen=85 =20 Leider macht die ServiceFactory trotzdem nicht, was sie soll. Ich habe = da drin sehr guten Debug-Code. Aber der l=E4uft nicht, weil der Code in = einer anderen VM remote ausgef=FChrt wird, und der Logger auf default und = nicht auf Level.FINEST steht. Ich m=FC=DFte hierzu den Logger in dem anderen = Java-Proze=DF einschalten. Das geht mit System-Properties =20 http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/ =20 genauer =20 http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html#1.8 =20 man mu=DF eine System-Property setzen, die=20 java.util.logging.config.file hei=DFt =20 und den Pfad zu einem File enth=E4lt. =20 darin mu=DF der Loglevel konfiguriert werden: =20 Ich habe das noch nie gemacht=85 =20 http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/LogManager.html= =20 de.tuberlin.cs.cis.eve.service.level =3D Level.ALL java.util.logging.ConsoleHandler.level =3D Level.ALL =20 Vielleicht k=F6nnen wir das am Donnerstag miteinander ausprobieren??? =20 Wir werden ohnehin was f=FCr=92s remote-debugging brauchen. =20 Also: Ein Teil des Problems liegt in=20 =20 =20 =20 =20 =20 =20 =20 =20 |
From: <joe...@we...> - 2005-02-15 17:21:14
|
Hallo! =20 Ich habe den gew=FCnschten =84Baumverk=FCrzer=93 geschrieben. Er ist = unter =84Environment-Displayer=93 zu haben. Er arbeitet mit einer Klasse =84AbbreviationNode=93, die eine Liste enth=E4lt, in der alle entfernten = Inhalte aufgerollt werden sollen. Das ist allerdings noch nicht eingebaut. Ganz fertig ist er also noch nicht, aber der =96ausf=FChrbare- Anfang ist = gemacht. Heute abend werde ich noch eine Runde an Jini arbeiten. Die Sitzung = morgen mu=DF leider ausfallen, weil ich f=FCr meinen neuen Chef zu einer = Sitzung nach Potsdam mu=DF. =20 Lieber Gru=DF, =20 J=F6rn Guy |
From: Matthias L. <Mat...@gm...> - 2005-01-27 22:40:14
|
Hallo! Ich habe eben die immer noch vorläufige Version des inference.TypeAnalyzer ins CVS gestellt, an der wir vorhin gearbeitet haben. Für das folgende Beispiel werden die richtigen Typgleichungen erstellt: package Foundation_Core context BehavioralFeature def: let testdef : Integer = if (testdef < 10) then testdef - 1 else testdef endif endpackage Für analoge Ausdrücke natürlich auch. (Es ist nur für die vorkommenden Operationen eine Fallbetrachtung vorgenommen worden.) Der nächste Schritt ist es, nun den Unifikator zu schreiben. Danach kann der TypeAnalyzer allgemeiner implementiert werden. Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2005-01-17 21:11:18
|
Hallo! Zum Type-Inference-Problem bei OCL. Es geht um z.B. folgendes Konstrukt: package Foundation_Core context BehavioralFeature def: let testdef : Integer = if (testdef < 10) then testdef - 1 else testdef endif endpackage Das funktioniert soweit von der Typanalyse her. Es ist nur nicht möglich die Typ-Angabe hinter dem 1. testdef wegzulassen, da momentan ein Verfahren fehlt, den Typ auszurechnen. Analog zu dem Typkalkül was in Programmiersprachen und -systeme gelehrt wird, würde ich folgende Überlegungen für einen Algorithmus ansetzen: Man definiert zunächst Typgleichungen für alle Sprachkonstrukte, die in einer Expression vorkommen können. - Die Anwendung eines Identifiers hat den Typ des für ihn in der Umgebung eingetragenen Typs. Also für Ide: t0 gilt t0 = t falls Ide.name(): t in Env. - Eine Funktionsapplikation F(A) hat folgende Repräsentation: apply(F: t1, A: t2): t0. Und die Typgleichung ist: t1 = (t2 -> t0). Bei Funktionsaufrufen mit mehr als einen Parameter geschieht das ganze analog: apply(F: t1, A: t2, B: t3): t0. Hier ist die Typgleichung t1 = (t2 ** t3 -> t0). - Bei der Fallunterscheidung if B then T else E endif ist die Baumdarstellung: cond(B: t1, T: t2, E: t3): t0. Hier gelten zwei Gleichungen: t1 = boolean t0 = t2 = t3 - Let-Konstrukte muss man glaube ich nicht betrachten, da diese nicht schachtelbar sind (so sah es zumindest laut Grammatik aus). Nun kann man für das konkrete OCL-Constraint viele Gleichungen aufstellen, die aufgrund dieser Regeln recht einfach zu erstellen sind. Wichtig ist hierbei, dass für gleiche Funktionsapplikationen oder gleiche Identifier unterschiedliche Typvariablen verwendet werden. Also das testdef bei (testdef < 10) erhält z.B. t4 und das testdef bei (testdef - 1) bekommt t8 als Typvariable. Diese Gleichungen kann man per Unifikation lösen. Voraussetzung hierfür ist, dass keine Gleichungen der Form t1 = (t1 -> t2) auftauchen (Occurs check). Dies passiert aber bei dem Beispiel vom Anfang nicht. Eine weitere Bedingung ist, dass die Funktionen wie Addition oder Relationen wohl definiert sind. Also dass bekannt ist, welche Typen erwartet werden. Bei OCL gibt es da eine kleine Schwierigkeit, da Integer ein Subtyp von Real ist, und man an manchen Stellen nicht entscheiden kann, welches von beiden es ist. Hier sollte man es wahrscheinlich offen lassen und beides einfach akzeptieren und im Notfall Konversion durchführen. Bei dem Beispiel von oben wäre Integer auch austauschbar durch Real - eindeutig kann das nicht bestimmt werden. Falls es aber von einer anderen Funktion aufgerufen wird, die einen bestimmten Typ erwartet, kann es ja konvertiert werden. Nun zur Unifikation: Diese ist nicht sonderlich schwer - in PSS haben wir dafür ein Beispiel-Programm in OPAL, was aber auch recht einfach in Java umsetzbar wäre: http://uebb.cs.tu-berlin.de/lehre/2004WVpss/files/unification.tar.gz Dabei wird eine Liste von einfachen Gleichungen (keine Multigleichungen) verarbeitet. In den Gleichungen können Typvariablen, Funktionen und Sorten vorkommen. Sorten sind in dem Fall schon konkrete Typen wie Boolean, Integer. Und nun muss man die Fälle die jeweils links und rechts auf einer Seite vorkommen können betrachten. Zum Beispiel wenn man die Gleichung (t1 -> t2) = (t3 -> t4) hat, muss man daraus zwei neue machen: t1 = t3 und t2 = t4. Oder trifft man auf eine Gleichung Integer = Boolean muss man einen Fehler liefern. Ich denke, dass der Ansatz recht effizient ist und zumindest in der Überlegung nicht allzu schwierig wirkt. Diese vereinfachte Variante des Lambda-Kalküls bzw. des ML-Typinferenzsystems eignet sich gut für funktionale bzw. formelle Sprachen und OCL gehört ja auch dazu. Gruß, Matthias Liebig |
From: Matthias L. <Mat...@gm...> - 2005-01-13 16:33:23
|
Hallo! Wir haben so eben die Transaction-Änderungen im eve-Modul in den Branch "eve_txn" ausgelagert. eve ist nun wieder auf dem Stand vom 11.01. und sollte mit den verbundenen Projekten ohne die Jini jar-Dateien funktionieren. Wer mit dem Branch arbeiten will: Am besten eve in einem neuen Ordner auschecken: cvs co -r eve_txn eve Oder in WinCVS: Checkout module -> Checkout options -> By revision/tag/branch: eve_txn Gruß, Matthias -- +++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben |
From: <joe...@we...> - 2005-01-09 14:40:01
|
Hallo! =20 Habe einen =E4rgerlichen Fehler im MOCL behoben, so da=DF der forward-declaration type check jetzt funktioniert. Ursache war die = Methode getClassifier() auf Classifier. Die hatte folgendes h=E4=DFliche Loch: =20 Eine ganze Horde von Typen sind durch Classifier realisiert: =20 /** The metatype OclType as defined in OCL 1.5 (6.8.1.1) */ public static Classifier OclType =3D new Classifier(); =20 /** The predefined type OclAny as defined in OCL 1.5 (6.8.1.2) */ public static Classifier OclAny =3D new Classifier(Type.AnOclAny); =20 /** The predefined type OclState as defined in OCL 1.5 (6.8.1.5) */ public static Classifier OclState =3D new = Classifier(Type.AnOclState); =20 /** The predefined type Real as defined in OCL 1.5 (6.8.1.7) */ public static Classifier Real =3D new Classifier(Type.AReal); =20 /** The predefined type Integer as defined in OCL 1.5 (6.8.1.8) */ public static Classifier Integer =3D new Classifier(Type.AnInteger); =20 /** The predefined type String as defined in OCL 1.5 (6.8.1.9) */ public static Classifier String =3D new Classifier(Type.AString); =20 /** The predefined type Boolean as defined in OCL 1.5 (6.8.1.10) */ public static Classifier Boolean =3D new Classifier(Type.ABoolean); =20 /** The predefined type Enumeration as defined in OCL 1.5 (6.8.1.11) = */ public static Classifier Enumeration =3D new Classifier(Type.AnEnumeration); =20 Classifier ist gleichzeitig die =93MetaEbene=94 von diesen ganzen = Dingern. Wenn man allerdings bereits einen Classifier hat (also einen Zeiger auf ein Element der Meta-Ebene) und man ruft getClassifier() darauf auf, bekommt = man einen Classifier von einem Classifier. Das ist nat=FCrlich Unsinn, weil = diese Meta-Ebene nirgends beschrieben ist. Also habe ich die Methode = =FCberschrieben und das Loch gestopft. Der Typcheck funktioniert jetzt. =20 Die gegenw=E4rtige L=F6sung mu=DF allerdings dringend refactored werden, = macht immer noch keinen Kollisionscheck mit existierenden Eigenschaften und so weiter. =20 Naja, ich mache mal ein wenig refactoring=85 =20 Gru=DF JGS |
From: Enrico H. <enr...@gm...> - 2005-01-07 18:23:12
|
Hi Jörn, war dieses problem eigentlich gelöst? Ich hab grad deinen neuen MBMService zum Testen als Service zusammengebastelt und hab beim Testen (MBMServiceTest) wieder den selben Fehler erhalten. Gruß Enrico Jörn Guy Süß schrieb: > Das ist die von mir so gefürchtete Classpath-Exception. Sie entsteht (so > nehme ich an), wenn die Eve-Klassen und damit das Repository durch einen > anderen Classloader geladen werden, als das Programm, das diese benutzt. > > Sieht wohl so aus: > > > Haupt-CL-+---EVE Lib CL------Dynamisch generierte Klassen von MDR > | > +---MBM CL------Aufrufende Klasse > > Der Haupt-CL sieht die Bibliothek, aber kommt irgendwie nicht an die > Instanzen ran. Ich habe den Debugger schon mal an der entsprechenden Stelle > angehalten. Die Instanzen waren dar, hat das Programm aber nicht > gekümmert... > > Versuche, dahinter zu kommen. > > Gruß JG > > > -----Ursprüngliche Nachricht----- > Von: cis...@li... > [mailto:cis...@li...]Im Auftrag von Enrico > Hartung > Gesendet: Mittwoch, 1. Dezember 2004 00:19 > An: cis...@li... > Betreff: [Ciseve-devel] Object with MOFID xxx no longer exists. > > > Hallo, > > um mir langes Suchen zu ersparen und mal die Mailingliste zu testen: > Was sagt mir "IOException: Object with MOFID .:0000000000000626 no > longer exists. > " > > mfG > Enrico > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Ciseve-devel mailing list > Cis...@li... > https://lists.sourceforge.net/lists/listinfo/ciseve-devel > > |
From: Enrico H. <enr...@gm...> - 2005-01-07 15:52:33
|
Hallo, ich hoffe, ihr habt alle das Diagramm bekommen. Wenn ihr Anmerkungen habt, dann ist dies das thread dafür. Mir stellt sich z.B. noch die Frage wie man die TransactionID an die Services übergibt. Gruß Enrico |
From: Enrico H. <enr...@gm...> - 2005-01-06 22:12:40
|
Hallo, ich hab jetzt mal das heute (06.01.2005) Besprochene abgebildet, ihr könnt es euch ja mal anschauen, vielleicht fällt euch noch was auf. Mir stellt sich z.B. noch die Frage wie man die TransactionID an die Services übergibt. Gruß Enrico |
From: <joe...@we...> - 2004-12-11 15:06:51
|
Das klingt sehr gut. Ich habe mir die entsprechenden Stellen angesehen und teile Eure Ansicht, das man die verwaltung doch besser mit den Scopes macht. Gruß & Dank JGS -----Ursprüngliche Nachricht----- Von: cis...@li... [mailto:cis...@li...]Im Auftrag von Matthias Liebig Gesendet: Samstag, 11. Dezember 2004 15:54 An: cis...@li... Betreff: [Ciseve-devel] mocl: Test für def's 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 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Ciseve-devel mailing list Cis...@li... https://lists.sourceforge.net/lists/listinfo/ciseve-devel |
From: Matthias L. <Mat...@gm...> - 2004-12-11 14:54:18
|
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 |
From: Joern G. S. <jg...@cs...> - 2004-12-09 16:56:10
|
Hi! 0) Status of def: MOCL can evaluate DEFs within ONE CONTEXT. Which is NOT what Jiri needs. There are two students working on this currently, specifically on this topic. Their goal is to evaluate the UML 1.4 WFRs on M1 instances. So this MATCHES what Jiri needs. Time scale is February, which is likely too late for Jiri, unless there is some other boost. 1) What you see at the MOCL page is the private application my student developed. We have split over some administrative issues, so I cannot speak for him on anything. Also, he has indicated that he does not have any time left to rework anything major, explizitly the DEF problem. In terms of usability his version uses a very hard-coded repository initialization and does not include a build script or real unit tests. It was primarily developed to achieve a good thesis grade, not to be an application tool. Our version of the validator uses facilities of EVE and is maintained within that project. I had to move out, because my student never wanted to combine his work with EVE. 2) Another way out for Jiri might be the Pampero eclipse plugin developed by claudia pons at Lifia, Argentina. If I am not mistaken, it does defs, but it is based on a hard-coded UML1.X and cannot eval other MMs. I believe Jiri needs to bite the bullet, either with OCLE or MOCL. With MOCL I know three people that want it to be finished and put work into it. We would be four, if Jiri joins. With OCLE I am not sure. I think he should get a beta or source, to check it out. If that's less work, go for it. BTW, some similar work was presented at UML04 by a german team from Stuttgart. They are also using JMI, state machines and OCL. I do not have the reference at hand, though. Maybe worth investigating for Jiri. I cc: this email to Fadi Chabarek, the original developer of MOCL for reference. Hope everything will turn out ok. Regards JGS Am Donnerstag 09 Dezember 2004 16:00 schrieben Sie: > Hi Joern, > > we have discussed with Jiri the possibility of switching to MOCL. > > We have looked at the MOCL sourceforge pages and it looks like that > there is a really big lot of work to be done. > > What is the current status of "def:" ? > > What Jiri needs is a def: implementation that can evaluate recursive > expressions. He can contribute in developing the interface to utilize > the functionality provided by the MOCL core, but I guess it would take > him really a lot of time to get familiar with the MOCL implementation > to effectively move the def: implementation forward. > > From what we see on the pages, it looks like a project for 4-5 students > for a year... (actually, something that is in our curriculum). > > Jiri needs to get started writing OCL to finish his thesis reasonably soon. > > Well, this may be rather hard without an working OCL evaluator. But, > deciding to first implement one would inflate the scope of his thesis > (and the time needed) to a dissertation.... :-) > > > If the status of the def: (re-implementation) is close to being > completed (with respect to the bugs "def vs. let" posted on sourceforge, > Jiri can start developing an interface to evaluate expressions at the > meta-level he needs (M2 expressions on M1 instances) - and possible also > report/fix-where-possible bugs in the MOCL core as he discovers them. > > > > As for the UML 2.0 in XMI 1.3 document: the only version I have here > includes also my Port State Machine extensions. > > Jiri has a pure UML 2.0 file on his computer, he will send it to you in > the evening. > > Best regards, > Vladimir + Jiri |
From: <joe...@we...> - 2004-12-07 15:26:41
|
Hallo! Ich habe einige kleine Änderungen machen müssen, um den Dienst zum Laufen zu bekommen. Diese betreffen an der Oberfläche das ILookup-System. Dieser Teil von Eve ist dazu da, brauchbare Beschreibungen für Dienste zu erstellen. Teil davon ist auch die Ladeadresse (URL) der Quell- und Metamodelle. Wenn die für den Dienst NICHT STIMMEN, gibt es Nullpointer und ClasscastExes. Ich habe einen lokalen Puffer eingebaut, der die Sache für alle lokal eingebauten Metamodelle (alle UML1 Varianten, CWM und XML) in Ordnung bringt. Den Mechanismus muß eine Lookup-Implementation allerdings aktiv aufrufen. Er ist in die Lookup-Oberklasse AbstractLookup als Methode getOfflineMetamodel eingebaut. Der LocalLookup ist so implementiert, daß er lokale Metamodelle vorzieht. Später muß man das vielleicht noch über Properties oder Flags regeln, aber ich denke, daß das schon von der Geschwindigkeit des Netzes abhängt, daß man nutzt. Lieber Gruß, JGS |
From: Matthias L. <Mat...@gm...> - 2004-12-02 02:00:53
|
Hallo nochmal! Ich habe jetzt einen einfachen Präprozessor zum mocl-Projekt (def_handling) hinzugefügt. Im Moment werden mehrzeilige Kommentare wie aus Java und C bekannt ( /* ... */ ) aus den OCL-Dateien entfernt, ohne die Position der folgenden Zeilen zu ändern. Der Präprozessor ist konfigurierbar und natürlich auch erweiterbar. Eventuell können wir ihn für das Problem mit den Rauten bei Enumerations einsetzen. Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2004-12-01 22:37:27
|
Hallo! Für das mocl-Projekt (Branch def_handling) gibt es nun unter de.tuberlin.cs.cis.ocl.tools den TreeDisplayer, der den AST mit Hilfe von Swing anzeigt. Als Parameter wird eine OCL-Datei erwartet, die dann nur durch den eigentlichen Parser geht - der Context-Checker wird noch nicht aufgerufen. Gruß, Matthias |
From: Matthias L. <Mat...@gm...> - 2004-12-01 21:30:18
|
Hallo! Ich habe eben die build.xml in den Projekten eve, net_jini und service_mocl (def_handling) geändert: "ant quality" ruft nun nicht mehr Clover auf, da es in Findbugs und bei JUnit-Tests zu Seiteneffekten kommen kann. Bei "quality" wird JUnit noch mal ohne Clover aufgerufen. Bei Findbugs wird die Zahl der Warnungen dadurch erheblich gesenkt. Die empfohlene Reihenfolge ist nun: "ant coverage quality" ("quality" löscht nicht die Ausgabe für Clover). Gruß, Matthias |
From: <joe...@we...> - 2004-12-01 09:14:30
|
-----Ursprüngliche Nachricht----- Von: Matthias Liebig [mailto:gu...@cs...] Gesendet: Mittwoch, 1. Dezember 2004 00:59 An: jg...@cs... Betreff: mocl Parser Hallo Jörn! Wir hatten beim Testen des mocl Parsers bisher ein paar Probleme mit den Beispiel-Dateien von ocle. 1. Die Grammatik kennt das Zeichen '#' nicht. In UML kann man ja Attribute als Enumerations definieren: z.B. type : {plastic, metal) und in OCL kann man auf diese konkreten Werte dann mit der Raute zugreifen: strings->forAll(type = #metal) Ist das beim mocl Parser generell nicht erlaubt, oder gibt es da einen Workaround / andere Syntax? (Wir hatten ein Beispiel verwendet, wo z.B. #public enthalten war.) Eigentlich sollte er das können. Die Arbeit sagt (CHAPTER 3. ACCESSING THE OCL CONTEXT 14): Enumeration As a special classifier an enumeration can be directly addressed in an OCL context [OCL03, cha. 4.2]. An enumeration type must therefore be further refined through the specification of its labels (s. Listing 3.2). A label can then be used to resolve a specific enumeration from its enumeration type. The label is used in both the type checking and the evaluation process. The type checker must assert that each enumeration and enumeration type is defined. The evaluator uses the label to build a specific instance. For further information see chapter 5 and 6. 1 public interface Enumeration extends Classifier { 2 String[] getLabels(); 3 } Listing 3.2: Java interface describing an enumeration type In der Grammatik finde ich: * 2) The productions 'enumLiteral' and 'pathName' are not distiguishable * for an button up parser (except pathName = name). IMHO for a rather * intuitive understanding: the production 'enumLiteral' as a spezialistion * of 'pathName' will be replaced by the production 'qualifiedName'. * So there will be only a 'name' and a 'qualifiedName'-based 'pathName'. * 6) Like in 5) there is another non determinism in the grammar. Looking * at the production 'primaryExpression' we easily notice that one can't * conclude which productions right hand side should be choosen if the * input is a string of the form name(::name)+. Is it a 'enumLiteral' * or a 'propertyCall'? While the language produced by these * productions is the same our parser definitly gets puzzled. >* There is no chance that I'm aware of to solve this ambiguousity (without >* completely rewriting the grammar of course), so the production 'literal' >* will be ripped of the choice 'enumLiteral'. >* Thus the parser has to solve the problem context based or have to >* delegate it to a point a decision can be made. A parsed 'enumLiteral' >* will be wrapped in a 'propertyCall' anyway. Scheint auch implementiert zu sein: Man findet 'enum' in: ContextAnalyser.java - service_mocl/src/de/tuberlin/cs/cis/ocl/check (19 matches) EnumerationInstance.java - service_mocl/src/de/tuberlin/cs/cis/ocl/eval/instance (2 matches) EnumerationTypeDescriptor.java - service_mocl/src/de/tuberlin/cs/cis/ocl/model/check (7 matches) EvaluationAnalyzer.java - service_mocl/src/de/tuberlin/cs/cis/ocl/eval (10 matches) ExampleEnumDesc.java - service_mocl/src/de/tuberlin/cs/cis/ocl/example/check (9 matches) ExampleInstanceModel.java - service_mocl/src/de/tuberlin/cs/cis/ocl/example/eval InstanceDescriptor.java - service_mocl/src/de/tuberlin/cs/cis/ocl/model/eval (4 matches) MofEnumerationType.java - service_mocl/src/de/tuberlin/cs/cis/ocl/model/mofbridge (6 matches) MofFacade.java - service_mocl/src/de/tuberlin/cs/cis/ocl/model/mofbridge (6 matches) Sex.java - service_mocl/src/de/tuberlin/cs/cis/ocl/example/eval (2 matches) TestModelType.java - service_mocl/src/de/tuberlin/cs/cis/ocl/type/test (3 matches) TestMofFacade.java - service_mocl/src/de/tuberlin/cs/cis/ocl/model/mofbridge/test TestOclExampleCheck.java - service_mocl/src/de/tuberlin/cs/cis/ocl/example/check/test TestOclExampleEvaluation.java - service_mocl/src/de/tuberlin/cs/cis/ocl/example/eval/test Type.java - service_mocl/src/de/tuberlin/cs/cis/ocl/type (2 matches) TypeFacade.java - service_mocl/src/de/tuberlin/cs/cis/ocl/model/check Scheint einen Workaround zu geben. Hier ein Beispiel mit Sex ;) : -- [OCL1.5] examples of paragraph 6.4.2: Enumeration Types package ExampleModel context Person inv: sex = Sex::male endpackage Die entsprechende Klasse sieht also so aus: /* * OCL validator framework for models and MOF compliant metamodels. * Copyright (C) 2004 Fadi Chabarek <fad...@we...> * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ package de.tuberlin.cs.cis.ocl.example.eval; /** * Represents a Sex Enumeration contained in the Example Class Diagram * of the OCL standard. * * @author fchabar * * @see OCL1.5 chapter 6.2.2 */ public class Sex { /** Represents the enumeration male */ public static Sex male = new Sex(0); /** Represents the enumeration female */ public static Sex female = new Sex(1); /** Differs a male from a female */ private int sex; /** * Constructs a Sex Enumeration. */ public Sex(int sex) { this.sex = sex; } /* * (non-Javadoc) * @see java.lang.Object#equals(java.lang.Object) */ public boolean equals(Object o) { return o instanceof Sex && ((Sex)o).sex == this.sex; } /* * (non-Javadoc) * @see java.lang.Object#toString() */ public String toString() { return this.equals(male) ? "male" : "female"; } } Hmmm. In der Gramatik im Standard findet sich der Hash "#" nur in: inhibitedChar := " " | "\"" | "#" | "\'" | "(" | ")" | "*" | "+" | "," | "-" | "." | "/" | ":" | ";" | "<" | "=" | ">" | "@" | "[" | "\\" | "]" | "{" | "|" | "}" Die Stelle mit dem enumLiteral sieht so aus: literal:= string | number | enumLiteral enumLiteral:= name "::" name ( "::" name )* ZUSAMMENFASSUNG Ich denke, daß das eine Inkonsistenz zwischen UML-Notation und OCL ist. Für das angegebene Beispiel ist der Workaround wahrscheinlich: Type : {plastic, metal) strings->forAll(Type = Type::metal) Ich habe keine Ahnung, wie kompliziert es ist, diese Konvertierung "on the fly zu machen", aber ich schätze, das es mit einfachem gramatischen rewrite möglich ist, der sowas ja nur für die Ops gleich und ungleich vorkommen. In jedem Fall eins für die Feature-Liste. 2. Kommentare wie in Java/C mit /* */ sind nicht möglich. Sollen wir das noch mit einbauen (dazu muss nur die Grammatik geändert werden...die Implementierung ändert sich dadurch nicht)? Die Grammatik im Standard kennt sie nicht. Sollte man vielleicht mit einem prä-proz realisieren, der die Sachen übersetzt so wie Problem 1. auch. Dann kann man immer zur vollen Kompatibilitär zurückkehren. Sonst fangen wir an, Dialekt zu schreiben. 3. Die Beispieldateien von ocle sind für ein Metamodel für UML 1.5 geschrieben, welches ein wenig anders aussieht, als das für 1.4 (rein von der Struktur her). Wir werden noch weiterversuchen, entweder die Beispieldateien zu ändern, oder das andere Metamodel miteinzubinden. Das 1.5 MM bekommt man, wenn man in | public class EveRepository implements MofRepository | den Knstruktor verändert: /** * Constructor for InstantiateModelsTest. * * @throws EveException DOCUMENT ME! */ public EveRepository() throws EveException { this("uml14"); } Hoffe, daß das hilft! Wegen der Mailing-Liste: Ich habe jetzt auch noch mal den anderen geschrieben, dass sie sich bitte dort anmelden. Ich sag dann bescheid, wenn das geschehen ist. Gruß und Danke, Matthias |
From: Enrico H. <enr...@gm...> - 2004-11-30 23:46:26
|
Hallo, um mir langes Suchen zu ersparen und mal die Mailingliste zu testen: Was sagt mir "IOException: Object with MOFID .:0000000000000626 no longer exists. " mfG Enrico |