Diss.-ETH 12317 Diss.-ETH 12317 Diss.-ETH 12317 Diss.-E Eine ...

3.1. DOMÄNENANALYSE 43
über alle
Zweige
in Richtung
M Z1H
g ij , b ij
M K1A
Dimension i
g ij , b ij
i j
M K1E
über alle
Zweige
in Richtung
i j
Zweig Knoten Knoten
ij i j
M Z1T
g ij , b ij
M K1A
ij b Dimension i
g , ij
Diss.-ETH 12317 Diss.-ETH 12317 Diss.-ETH 12317 Diss.-E
M K1E
Abbildung 3.7: 1. Lösungsansatz zum Aufbau der Nebendiagonalblöcke
Übergabeparameter jemals ändern, so sind die Schnittstellen des Knotentypen
anzupassen.
In der zweiten Lösung wird eine Fallunterscheidung im Programmcode
der Aktion MZ2H bzw. MZ2T der Zweige benutzt. Diese Fallunterscheidung
hängt, wie in Tabelle 3.4 ersichtlich und nachfolgend diskutiert wird,
von der Vielfalt der Knotentypen ab. Obwohl der zweite Lösungsansatz
nur drei Aktionen MZ2H, MZ2T und MK2 und einen Übergabeparameter für
den Knotentypen benötigt, gibt es ebenfalls Wartungsprobleme, wenn z.B.
die Vielfalt der Knotentypen ändert. In diesem Fall wäre der Programmcode
in der Aktion MZ2H bzw. MZ2T der Zweig-Entität anzupassen.
Modellierung mit Ntor-Ansatz
In Tabelle 3.4 ist ersichtlich, dass bei der Knoten-Zweig-basierten Modellierung
für den Aufbau eines Nebendiagonalblocks Aij Informationen von
drei Entitäten benötigt werden. Ferner zeigt sich, dass der Nebendiagonalblock
Aij gleichzeitig die Information enthält, ob zwischen den Knoten
i und j eine Verbindung besteht und welche Parameter des Zweiges zwischen
diesen Knoten massgebend sind.
Wie in Kapitel 3.1.5 gezeigt wurde, ist diese Vermischung von gleichzeitig
auszuwertender Information für einen objekt-orientierten Design ungünstig.
Es treten Wartungsprobleme der Software auf, wie z.B. die in
Programmen verstreute Auswirkungen bei Änderung von Datentypen oder
A ij
A ji
Zeit