Dokument_1.pdf (2548 KB) - KLUEDO - Universität Kaiserslautern

2.4 Top-Down- und Bottom-Up-Strategie
Die Vorgehensweise der Modellerstellung
In der Literatur findet man zwei prinzipiell unterschiedliche Vorgehensweisen (Abb. 8) zur
Systemanalyse. Die Darstellung der grundlegenden Prinzipien folgt Litz ([Lit-01a]). Während
das Top-Down-Verfahren auf einer Zerlegung und zunehmenden Granularität der Modellbeschreibung
basiert, wird das Bottom-Up-Verfahren durch Verknüpfung elementarer Bausteine
charakterisiert.
Trotzdem ist ein rein bausteinorientierter Ansatz zunächst methodisch nicht ausreichend zur
Realisierung der Vereinfachungen bzw. Detaillierungen der Bottom-Up- bzw. Top-Down-Strategie.
Erst durch das Klassenkonzept (siehe Abschnitt 3.1.2) der objektorientierten mathematischen
Modellbildung lassen sich die Konzepte realisieren.
zunehmende Granularität
Bottom-up-Verfahren
Abbildung 8: Bottom-up- und Top-down-Verfahren
2.4.1 Top-Down-Strategie
Top-Down-Verfahren
Die Top-Down-Strategie startet mit einem möglichst einfachen Modell. Dieses ist durch die
Zerlegung in Teilsysteme zu strukturieren und zu detaillieren.
Ausgehend von nur wenigen miteinander verschalteten Komponenten geringer Komplexität
(Abb. 8) wird die Granularität der Modellbeschreibung stetig erhöht. Aus der Analyse der
erhaltenen Simulationsergebnisse entscheidet man sich zur Detaillierung des Modells an
bestimmten Stellen und geht im Entwurfsprozess an die entsprechende Stelle zurück.
Die Vorteile der Top-Down-Strategie liegen in einer hohen Entwurfseffizienz. Man hat sehr
früh ein nutzbares Gesamtmodell zur Verfügung. Seine Komplexität ist verfahrensbedingt so
niedrig wie möglich. Man erkennt durch die iterative Detaillierung sehr schnell Einfluss und
Wirkung der hinzukommenden Größen.
Die nachträglichen Detaillierungen der Top-Down-Strategie erfordert allerdings neben der
Hinzufügung von Bausteinen des Gesamtmodells häufig die Modifikation des vorhandenen
Baustein-Repertoires.
Man kann diese Problematik durch Bibliotheksstrukturen lösen, welche Komponenten gleicher
Funktionalität in unterschiedlichen Detaillierungsgraden vorhalten. Aus methodischer
Sicht ist dies keine gute Lösung. Aus den Mehrfachimplementierungen folgt ein hoher Erstellungsaufwand
sowie eine schwierige Modellpflege. Erkennt man, dass die gemeinsame Funktionalität
von mehrfach implementierten, in unterschiedlichen Detaillierungsgraden
beschriebenen Modellen zu ändern ist, so kann dies nicht in einem Schritt erfolgen.
17