Re: Re: [Jmove-devel] ModelSerialization

[<ax...@sp...>]

Hi Michael,

>grunds=C3=A4tzlich teile ich deine Pr=C3=A4ferenzen f=C3=BCr B und D. Aufg=
rund=20
>unserer Planungen w=C3=BCrde ich allerdings das aufwand=C3=A4rmere D=20
>bevorzugen. Die Idee "Projektdatei" finde ich klasse, denn dadurch=20
>wird nichts vorgegaukelt. Mein Vorschlag f=C3=BCr die konkrete Benennung:
>* load/save module compilation
>* load/save module set

"load/save project" ?

>Wir sollten unser Men=C3=BCstruktur daf=C3=BCr weiter standardisieren. Wie=
 w=C3=A4re=20
>es mit=20

ja - sollten wir tun...

>
>Model
>=09New
>=09Add module
>=09-----------------
>=09Load module compilation
>=09Save module compilation
>=09-----------------
>=09Export XMI
>=09-----------------
>=09Quit
>
>View
>=09Search types
>=09//Create diagram
>=09//Create report

ich finde die IntelliJ/IDEA Men=C3=BCstruktur ganz sch=C3=B6n (- ja ich bin=
 schon ziemlich stark gepr=C3=A4gt... ).  Speziell das "Go to" Men=C3=BC.  =
Denn das "Search types" entspricht eigentlich sehr dem "Go to/Class". Man k=
ann dann noch andere Navigations-Aktionen dort eintragen:
   =20
    - Go to
        - Class
=09- Package
        - Alarms
        - Package Overview
        ---------------
        - Contaner
        - Details
        ---------------
        - Next
        - Previous
        ....

>Help
>=09Contents
>=09About
>
>
>Bzgl. der mittelfristigen Variante B w=C3=BCrde ich in der Tat ein=20
>textbasierte Format (gerne XML) verwenden, dann sind Fehler leichter=20
>nachvollziehbar und mit entsprechender Komprimierung sollte auch=20
>Speicherplatz weniger ein Problem sein.=20

Ok - wenn das effizienter wird als Byte-Code laden, dann ist mir das recht =
;-).=20

>Prinzipiell halte ich XMI f=C3=BCr=20
>zu =C3=BCberfrachtet, unser schmales Kernmodell bietet sicherlich eine=20
>effizientere Serialisierungsm=C3=B6glichkeit. Allerdings wenn wir auch=20
>Diagramme ablegen wollen...

Ich weiss nicht genau wie Diagramme in XMI dargestellt  werden. Ich vermute=
 aber mal, dass es da um UML-Diagramme geht. Unsere Diagramme kann man wohl=
 nur begrenzt als UML-Diagramme auffassen.

>
>Apropos Diagramme: Es w=C3=A4re super, wenn man Diagramme selbst best=C3=
=BCcken=20
>k=C3=B6nnte: neues Diagramm anlegen, Packages in das Diagramm ziehen,=20
>Abh=C3=A4ngigkeiten werden eingetragen, das Diagramm kann gedruckt=20
>werden....megacool! ;-)

JA!!! :-)  - aber nicht f=C3=BCr 1.0 :-(=20

>
>
>Gru=C3=9F
>Michael
>
>
>
>
>Am Montag, 30. Mai 2005 11:31 schrieb ax...@sp...:
>> Hi Michael,
>>
>> da bist du aber wieder mal fleissig gewesen :-). Ich habe zumindest
>> etwas Zeit gefunden deine Sachen auszubrobieren. Den Stack-Overflow
>> habe ich allerdings noch nicht gefunden - nun ist es aber doch
>> raus... ;-)
>>
>> >Hi,
>> >
>> >f=C3=BCr das Speichern und Laden von Modellen habe ich im ersten Ansatz
>> > die die Standard-Java-Serialisierung verwendet. Dabei ist mir
>> > Folgendes aufgefallen:
>> >
>> >* Viel "implements Serializable"
>> >* Einige Attribute auf "transient" umgestellt
>> >* StackOverflowError bei Abspeichern des jmove-source-Modells
>> >
>> >Strukturell ist mir aufgefallen, dass unsere abgespeicherten
>> > Modelle nicht transportf=C3=A4hig sind, da assozierte Locations nach
>> > einem Laden nicht an der gleichen Stelle liegen m=C3=BC=C3=9Fen und so=
mit
>> > Funktionalit=C3=A4t wie Source-Code-Edit nicht funktionieren.
>> >
>> >Im Prinzip sehe ich 4 M=C3=B6glichkeiten den Problemen zu begegnen:
>> >
>> >A. StackOverflow beheben: Schwierig, weil die Stelle nicht
>> > verraten wird: ist es einfach die Menge oder erkennt der
>> >Standard-Java-Mechanismus keine Zyklen? Warum funktioniert das
>> >Abspeichern und Laden von Byte-Code-Modellen?
>> >
>> >B. Eigene Implementierung der Serialisierung: aufwendig aber
>> >sicherlich passend
>> >
>> >C: Nutzung von XStream einer Bibliothek (250KB) zur
>> > Serialisierung: einfach zu verwenden, aber erzeugte Datenvolumen
>> > =C3=BCbersteigt wesentlich die Standard-Java-Serialisierung (12MB
>> > statt 150KB f=C3=BCr Junit), gestiegene Memory-Anforderungen durch
>> > DOM-Ansatz
>> >(Jmove-Source-Modell brach mit einer outOfMemory-Excpetion ab)
>> >
>> >D: Pseudo-Serialisierung: Serialisierung der Modulpfade und
>> > erneutes Parsen beim Laden, wenig Aufwand aber schlechte
>> > Performanz
>> >
>> >Was denkt Ihr?
>>
>> Also ich denke B + D oder D + B w=C3=A4re Klasse.  Ich habe ein bisschen
>> hin und her =C3=BCberlegt und stelle mir das ungef=C3=A4hr so vor:
>>
>> - serialisierte Modellinformationen sind immer dann sinnvoll, wenn
>> jemand Zeit sparen m=C3=B6chte und Aktualit=C3=A4t nachrangig ist.  Beis=
piel:
>> jemand untersucht einen Release-Stand oder mit jedem Build wird ein
>> serialisiertes (vorverdautes) Modell erzeugt.
>>
>> - wenn Aktualit=C3=A4t im Vordergrund steht, dann arbeite ich lieber auf
>> dem Source- oder Bytecode.
>>
>> - In einem Modell kann es Teile geben, die sich h=C3=A4ufig =C3=A4ndern =
und
>> Teile die sich seltener =C3=A4ndern. Man ist also mit unterschiedlichen
>> Anforderungen an die Aktualit=C3=A4t konfrontiert.
>>
>> Ausgehend von dieser Betrachtung kann ich mir folgende L=C3=B6sung
>> vorstellen:
>>
>> - Eine Modelldatei enth=C3=A4lt nur die Modulpfade -  also D. Ich w=C3=
=BCrde
>> dies jedoch nicht als Pseudo-Serialisierung bezeichnen. Es ist eher
>> mit einer Projektdatei einer IDE vergleichbar.
>>
>> - ein serialisiertes Modell kann genauso als Modul betrachtet
>> werden wie ein Source-/Bytecode - Jar/Verzeichnis. Es handelt sich
>> also nur um eine andere Modulform  (und w=C3=BCrde evtl. einen eigenen
>> Loader erfordern) .
>>
>> - es gibt Mechanismen um ein beliebiges Modul in ein serialisiertes
>> Modul umzuwandeln.
>>
>> - Source-(Byte-)Code-Modul + serialisiertes Modul +
>> Synchronisierung k=C3=B6nnte ein "cached module" sein.
>>
>> - wie k=C3=B6nnte man "serialisiertes Modul" nur sinnvollerweise
>> nennen?!?
>>
>> Die Beschr=C3=A4nkung auf die Modulebene macht sicherlich die Anwendung
>> von B notwendig, f=C3=BCr das es offensichtlich ja auch noch andere
>> Gr=C3=BCnde gibt. Somit w=C3=BCrde A aussen vor sein. C w=C3=BCrde auch =
nicht so
>> recht in die Betrachtung passen, da meine Annahmen ja davon
>> ausgehen, dass man Zeit und Speicherplatz sparen m=C3=B6chte.
>> Grunds=C3=A4tzlich habe ich nichts gegen textbasierte Formate wenn sie
>> die Anforderung grunds=C3=A4tzlich erf=C3=BCllen. Ein XML-basiertes Form=
at
>> kann einem sicherlich die Implementierung erleichtern, wenn es
>> allerdings dadurch zu geschw=C3=A4tzig wird nutzt uns das auch nichts.
>> Ansonsten k=C3=B6nnten wir keine weiteren grunds=C3=A4tzlichen Vorteile =
aus
>> einem XML-Format ziehen. Speziell ein XMI-Modul w=C3=A4re zwar auch sehr
>> attraktiv, w=C3=BCrde uns aber im Rahmen dieser Diskussion nicht weiter
>> bringen.
>>
>> Ok -  das reicht erst mal. Was meint ihr dazu?
>>
>> Ahoi
>>
>> Axel
>>
>> >Gru=C3=9F
>> >Michael
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >This SF.Net email is sponsored by Yahoo.
>> >Introducing Yahoo! Search Developer Network - Create apps using
>> > Yahoo! Search APIs Find out how you can build Yahoo! directly
>> > into your own Applications - visit
>> > http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005
>> > _______________________________________________
>> >Jmove-devel mailing list
>> >Jmo...@li...
>> >https://lists.sourceforge.net/lists/listinfo/jmove-devel
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Yahoo.
>> Introducing Yahoo! Search Developer Network - Create apps using
>> Yahoo! Search APIs Find out how you can build Yahoo! directly into
>> your own Applications - visit
>> http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22005
>> _______________________________________________
>> Jmove-devel mailing list
>> Jmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/jmove-devel
>
>