Re: [Jmove-devel] Umgang mit inneren Typen...

[Michael <mj...@we...>]

Hi,

ich habe es nur kurz =C3=BCberflogen, aber es sieht erstmal okay aus! Wobei=
=20
Ich zugeben muss, dass ich noch nicht =C3=BCber die Auswirkungen=20
nachgedacht habe ("Dies macht auf der einen Seite einige Analysef=C3=A4lle=
=20
komplizierter ....").=20

Gru=C3=9F
Michael


Am Mittwoch, 28. Dezember 2005 14:01 schrieb ax...@sp...:
> Hallo,
>
> ich habe die letzten Tage etwas =C3=BCber die Handhabung von 'Inner
> Types' in jmove gegr=C3=BCbelt. Ursache der Gr=C3=BCbelei waren die
> Unit-Tests, die ich f=C3=BCr den Test der Loader geschrieben habe, durch
> die definiert werden soll, wie innere Typen in einem jmove-Modell
> repr=C3=A4sentiert werden sollen. Je nach Betrachtungswinkel kann man da
> zu unterschiedlichen Auffassungen kommen. Bei dem Beispiel der
> anonymen Klassen sind die folgenden beiden Argumentationen durchaus
> berechtigt:
>
> 1. Man mu=C3=9F anonyme Klassen nicht in das Modell aufnehmen, da sie
> nur ein Implementierungsdetail einer Methode darstellen und ihre
> Abh=C3=A4ngigkeiten zu anderen Klassen k=C3=B6nnen auf die umgebende Klas=
se
> =C3=BCbertragen werden.
>
> 2. Eine anonyme Klasse implementiert immer ein oder mehrere
> Interfaces oder erbt von einer Klassen. Die Information =C3=BCber die
> Vererbungsbeziehung ist wichtig, da sie zum erkennen der Rollen von
> Instanzen in verschiedenen Entwurfsmustern dienen kann (z.B.
> Delegate-Interface).
>
> Evtl. gibt es schon bez=C3=BCglich der anonymen Klassen noch weitere
> Argumentationsm=C3=B6glichkeiten. Bei 'Nested Types' und vor allem
> Member-Klassen gibt es noch mehr Varianten wie man sie in ein
> Modell abbilden k=C3=B6nnte und f=C3=BCr alle Varianten gibt es jeweils g=
ute
> Gr=C3=BCnde. Leider wiedersprechen sich viele Anforderungen und ich habe
> lange dar=C3=BCber nachgedacht alles unter einen Hut zu bringen und bin
> zu keinem zufriedenstellenden Ergebnis gekommen. Ich glaube, da=C3=9F
> dies nicht sinnvoll und wahrscheinlich auch nicht m=C3=B6glich ist.
>
> Die Ursache f=C3=BCr die Widerspr=C3=BCche liegt meiner Meinung nach dari=
n,
> da=C3=9F ein Modell einfach unterschiedlichen Zwecken dienen kann. Und
> der Zweck definiert die ben=C3=B6tigten Informationen und die passendste
> Struktur. Offensichtlich ist dies, wenn man die Analyse von
> Package-Abh=C3=A4ngigkeiten der Analyse von Typ-Abh=C3=A4ngigkeiten
> gegen=C3=BCberstellt. Es sind jeweils unterschiedliche Modellelemente
> und Informationen (z.B. Metriken) relevant. Au=C3=9Ferdem handelt es
> sich bei den Package-Abh=C3=A4ngigkeiten um 'abgeleitete' Informationen,
> die aus den Typ-Abh=C3=A4ngigkeiten berechnet werden. Es handelt sich
> also um eine Vereinfachung.
>
> Wir haben keine gro=C3=9Fen Probleme bei der Koexistenz von Package- und
> Typ-Abh=C3=A4ngigkeiten da sie in dem Modell leicht unterscheidbar sind.
> Bei genauerer Betrachtung arbeitet man aber mit zwei
> unterschiedlichen Modellen, da Menge der jeweils relevanten
> Modellelemente weitgehend disjunkt sind. Sind die
> Package-Abh=C3=A4ngigkeiten einmal bekannt, dann werden im Prinzip die
> Informationen =C3=BCber die Typ-Abh=C3=A4ngigkeiten nicht mehr ben=C3=B6t=
igt und
> umgekehrt ben=C3=B6tigt man die Package-Abh=C3=A4ngigkeiten nicht zur Ana=
lyse
> der Typ-Abh=C3=A4ngigkeiten.
>
> Bei den Typ-Abh=C3=A4ngigkeiten vermischen wir momentan jedoch
> abgeleitete und 'native' Abh=C3=A4ngigkeiten. So wird die Abh=C3=A4ngigke=
it
> eines inneren Typen grunds=C3=A4tzlich auf den umgebenden Typ
> =C3=BCbertragen. Es werden also abgeleitete Abh=C3=A4ngigkeiten hinzugef=
=C3=BCgt.
> Hingegen werden einige 'native' Abh=C3=A4ngigkeiten nicht
> ber=C3=BCcksichtigt. Die Typabh=C3=A4ngigkeiten sind also momentan unter =
der
> Perspektive eines bestimmten Analysezwecks umgesetzt.
>
> Nun kann man folgendes beobachten:
>
> 1. Bei einer detaillierteren Betrachtung der verschiedenen inneren
> Typen m=C3=BC=C3=9Fte man die Abbildung auf das jmove-Modell differenzier=
ter
> umsetzen.
>
> 2. Man kann mit einem Modell nicht allen Analysezwecken gerecht
> werden.
>
> 3. Man kann/sollte jmove nicht auf einen einzelnen Analysezweck
> festlegen.
>
> 4. Eine Vereinfachung des Abh=C3=A4ngigkeits-Modells (z.B. Ersetzen von
> nativen Abh=C3=A4ngigkeiten durch abgeleitete) f=C3=BChrt zu einem
> Informationsverlust, der die Verwendbarkeit eines Modell f=C3=BCr einen
> Zweck der die Informationen ben=C3=B6tigt ausschlie=C3=9Ft.
>
> 5. Die Ableitung von Informationen ist immer auf eine spezielle
> Zweckklasse ausgerichtet. Unterschiedliche Zwecke k=C3=B6nnen
> unterschiedliche Ableitungen erfordern.
>
>
> Daher denke ich, da=C3=9F eine Vermischung von abgeleiteten und nativen
> Abh=C3=A4ngigkeiten keine gute Idee ist und da=C3=9F man unterschiedliche
> Modelle f=C3=BCr unterschiedliche Zwecke ben=C3=B6tigt. Diesen Schlu=C3=
=9F kann
> auch bei der Diskussion einer Fragestellung gezogen werden =C3=BCber die
> wir schon h=C3=A4ufiger gesprochen haben:
>
> 	Welche Packages/Typen geh=C3=B6ren zu meinem Modell und welche nicht?
>
> Eigentlich m=C3=BC=C3=9Fte die Frage lauten:
>
> 	Welche Packages/Typen sind f=C3=BCr einen speziellen Zweck relevant?
>
>
> Zur=C3=BCck zu den inneren Typen - diese kann man als Idiome betrachten,
> die eine stark vereinfachte Definition von verschiedenen
> Implementierungsmustern erm=C3=B6glichen. Auch bei inneren Typen handelt
> es sich nur um Java-Typen, die zus=C3=A4tzlichen Constraints bez=C3=BCgli=
ch
> Abh=C3=A4ngigkeiten und Sichtbarkeit unterliegen. Daher schlage ich
> folgenden Umgang f=C3=BCr das n=C3=A4chste Release vor:
>
> - Innere Typen werden in das Modell aufgenommen.
> - Es existiert eine Containment-Beziehung zwischen innerem und
> umschlie=C3=9Fenden Typ. - Die 'nativen' Abh=C3=A4ngigkeiten zwischen inn=
erem
> und umschlie=C3=9Fendem Typ werden so in das Modell aufgenommen, wie sie
> auch zur Laufzeit existieren. Es werden keine 'nativen'
> Abh=C3=A4ngigkeiten weggelassen. - Es werden KEINE abgeleiteten
> Typ-Abh=C3=A4ngigkeiten in das Modell aufgenommen.
>
> Dieses Modell enth=C3=A4lt also keine Vereinfachungen auf Typ-Ebene.
> Dies macht auf der einen Seite einige Analysef=C3=A4lle komplizierter,
> erlaubt auf der anderen Seite aber eine differenziertere
> Betrachtung. In dem n=C3=A4chsten Release (2.0) sollte dann eine
> Unterst=C3=BCtzung f=C3=BCr abgeleitete Modelle existieren und durchg=C3=
=A4ngig
> genutzt werden. So sollten auch die abgeleiteten
> Package-Abh=C3=A4ngigkeiten in ein eigenes Modell existieren.
>
>
> Was haltet ihr davon?
>
>
> Gru=C3=9F,
>
> Axel
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files for problems?  Stop!  Download the new AJAX search engine
> that makes searching your log files as easy as surfing the  web.=20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3DClick
> _______________________________________________
> Jmove-devel mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmove-devel