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

[<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, di=
e ich f=C3=BCr den Test der Loader geschrieben habe, durch die definiert we=
rden soll, wie innere Typen in einem jmove-Modell repr=C3=A4sentiert werden=
 sollen. Je nach Betrachtungswinkel kann man da zu unterschiedlichen Auffas=
sungen kommen. Bei dem Beispiel der anonymen Klassen sind die folgenden bei=
den Argumentationen durchaus berechtigt:

1. Man mu=C3=9F anonyme Klassen nicht in das Modell aufnehmen, da sie nur e=
in Implementierungsdetail einer Methode darstellen und ihre Abh=C3=A4ngigke=
iten zu anderen Klassen k=C3=B6nnen auf die umgebende Klasse =C3=BCbertrage=
n 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 Argume=
ntationsm=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 gute Gr=C3=BCnde. Leider wiede=
rsprechen sich viele Anforderungen und ich habe lange dar=C3=BCber nachgeda=
cht alles unter einen Hut zu bringen und bin zu keinem zufriedenstellenden =
Ergebnis gekommen. Ich glaube, da=C3=9F dies nicht sinnvoll und wahrscheinl=
ich auch nicht m=C3=B6glich ist. =20

Die Ursache f=C3=BCr die Widerspr=C3=BCche liegt meiner Meinung nach darin,=
 da=C3=9F ein Modell einfach unterschiedlichen Zwecken dienen kann. Und der=
 Zweck definiert die ben=C3=B6tigten Informationen und die passendste Struk=
tur. Offensichtlich ist dies, wenn man die Analyse von Package-Abh=C3=A4ngi=
gkeiten der Analyse von Typ-Abh=C3=A4ngigkeiten gegen=C3=BCberstellt. Es si=
nd jeweils unterschiedliche Modellelemente und Informationen (z.B. Metriken=
) relevant. Au=C3=9Ferdem handelt es sich bei den Package-Abh=C3=A4ngigkeit=
en um 'abgeleitete' Informationen, die aus den Typ-Abh=C3=A4ngigkeiten bere=
chnet werden. Es handelt sich also um eine Vereinfachung.=20

Wir haben keine gro=C3=9Fen Probleme bei der Koexistenz von Package- und Ty=
p-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=
=B6tigt und umgekehrt ben=C3=B6tigt man die Package-Abh=C3=A4ngigkeiten nic=
ht zur Analyse 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=A4ngigkeit eines inner=
en Typen grunds=C3=A4tzlich auf den umgebenden Typ =C3=BCbertragen. Es werd=
en also abgeleitete Abh=C3=A4ngigkeiten hinzugef=C3=BCgt. Hingegen werden e=
inige 'native' Abh=C3=A4ngigkeiten nicht ber=C3=BCcksichtigt. Die Typabh=C3=
=A4ngigkeiten sind also momentan unter der Perspektive eines bestimmten Ana=
lysezwecks umgesetzt.=20

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 differenzierter umset=
zen.

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 nat=
iven Abh=C3=A4ngigkeiten durch abgeleitete) f=C3=BChrt zu einem Information=
sverlust, 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 Ableitu=
ngen 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 Mode=
lle f=C3=BCr unterschiedliche Zwecke ben=C3=B6tigt. Diesen Schlu=C3=9F kann=
 auch bei der Diskussion einer Fragestellung gezogen werden =C3=BCber die w=
ir schon h=C3=A4ufiger gesprochen haben:=20

=09Welche Packages/Typen geh=C3=B6ren zu meinem Modell und welche nicht?=20

Eigentlich m=C3=BC=C3=9Fte die Frage lauten: =20
=09
=09Welche Packages/Typen sind f=C3=BCr einen speziellen Zweck relevant?
=09

Zur=C3=BCck zu den inneren Typen - diese kann man als Idiome betrachten, di=
e eine stark vereinfachte Definition von verschiedenen Implementierungsmust=
ern erm=C3=B6glichen. Auch bei inneren Typen handelt es sich nur um Java-Ty=
pen, die zus=C3=A4tzlichen Constraints bez=C3=BCglich Abh=C3=A4ngigkeiten u=
nd Sichtbarkeit unterliegen. Daher schlage ich folgenden Umgang f=C3=BCr da=
s 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 innerem und umschlie=C3=9Fende=
m Typ werden so in das Modell aufgenommen, wie sie auch zur Laufzeit existi=
eren. Es werden keine 'nativen' Abh=C3=A4ngigkeiten weggelassen.
- Es werden KEINE abgeleiteten Typ-Abh=C3=A4ngigkeiten in das Modell aufgen=
ommen.

Dieses Modell enth=C3=A4lt also keine Vereinfachungen auf Typ-Ebene. Dies m=
acht auf der einen Seite einige Analysef=C3=A4lle komplizierter, erlaubt au=
f der anderen Seite aber eine differenziertere Betrachtung. In dem n=C3=A4c=
hsten Release (2.0) sollte dann eine Unterst=C3=BCtzung f=C3=BCr abgeleitet=
e Modelle existieren und durchg=C3=A4ngig genutzt werden. So sollten auch d=
ie abgeleiteten Package-Abh=C3=A4ngigkeiten in ein eigenes Modell existiere=
n.


Was haltet ihr davon?


Gru=C3=9F,

Axel