Wieder paar tolle Begriffe.

Beschreiben Topdown und Bottom up 2 Verfahren wie man Projekte angehen kann?

Sind das nur wieder andere Begriffe für "fangen wir von oben an" und "fangen wir doch unten/hinten an"?

Ist mir im Zusammenhang mit ner Zwischenprüfung für Informatikkaufmänner erschienen. Da ging es um ein Projekt zur softwareerstellung. Kann man die Verfahren auch für andere Projekte verwenden?

Top-Down-Methode:

Abstraktion nach unten, ein Gesamtproblem wird in kleine Teile zerlegt. Anwendung bei der Entwicklung eines einzelnen Programms.

Bottom-Up-Methode:

Abstraktion nach oben, z. B. wenn die Aufgabenstellung nicht exakt beschrieben ist oder noch Änderungen zu erwarten sind. Anwendung bei grossen Programmsystemen.

Die Up-Down-Methode gibt es auch noch. ;-)

Was meinst du mit "Abstraktion"? Kann ich jetzt hier nicht ganz zuordnen!

Original geschrieben von b-r-e

Was meinst du mit "Abstraktion"? Kann ich jetzt hier nicht ganz zuordnen!

Abstrakt heisst theoretisch.

Es gibt verschiedenen Prinzipien und Methoden des Software-Entwurfs, z. B. das Modularitäts- und Abstraktionsprizip.

Abstraktion heisst auch, die blosse Form vom Gehalt gesondert aufstellen.

was besagt dann die up-down Methode?

Kann man dann meinen Ansatz auch "gelten" lassen: je nach dem von oben, oder unten anfangen?

Original geschrieben von b-r-e

was besagt dann die up-down Methode?

Up-Down-Methode:

auch Middle-Out, Gegenstromverfahren.

Bei dieser Strukturierungsmethode wird die Gesamtaufgabe durch "top-down"-Methoden verfeinert und werden Teilaufgaben "bottom-up" abstrahiert. Auf diese Weise können kritische Teilaufgaben zuerst getestet werden.

Kann man dann meinen Ansatz auch "gelten" lassen: je nach dem von oben, oder unten anfangen?

Kommt auf die Definition von "unten" und "oben" an. Ist also nicht ganz klar ausgedrückt.

unten = das eigentliche programm was die ARbeit macht

oben = Module, die nur zur "hilfe" dienen

Original geschrieben von b-r-e

unten = das eigentliche programm was die ARbeit macht

oben = Module, die nur zur "hilfe" dienen

Nö, dann wäre Dein Satz schlicht falsch.

Es geht um eine Gesamtaufgabe und Teilaufgaben aus dem Gesamten.

Die Methoden sind Strukturierungsmethoden zur Softwareentwicklung.

"oben" und "unten" bei einer Software, das ist natuerlich woertlich gesehen kompletter Quatsch. Es ergibt aber Sinn, wenn man es als Metapher sieht. Wie bei einem Gebaeude die oberen Stockwerke ohne die unteren einstuerzen wuerden, so beruht auch die Funktion eines Programms oft auf Unterfunktionen ohne die die hoeheren Funktionen nicht laufen koennen, umgekehrt aber schon.

Beispiel: Du willst das Ergebnis eines Algorithmus graphisch aufbereitet darstellen. Dazu brauchst Du

a) eine Graphikroutine

eine Berechnungsfunktion

kann ihren Job auch ohne a) erledigen, was umgekehrt nicht zutrifft, und das Programm laeuft nur im Sinne der Vorgabe, wenn beide vorhanden sind. Genau genommen liegt eine AND-Verknuepfung vor (laeuft einer nicht, laeuft alles nicht), aber jede Komponente fuer sich genommen ist in Form von Wenn-Dann-Relationen an ihre Nachbarn geknuepft, ausgenommen solche Funktionen, die aus sich selbst heraus funktionieren wie ein Treiber oder eine Berechnung. Mathematisch gesagt ist das Vorhandensein eines Ergebnisses die notwendige Bedingung fuer seine graphische Darstellung, waehrend das Vorhandensein des graphisch dargestellten Ergebnisses eine hinreichende Bedingung fuer die Existenz des Ergebnisses ist.

Als Programmierer bist Du nun in einem Dilemma, weil Du die beiden Komponenten sequentiell erstellen musst. Platt gesagt, muss man ja irgendwo anfangen, auch wenn der Rest noch nicht laeuft, weil man nicht zwei Sachen zugleich programmieren kann.

Bei der Top-Down-Methode schreibst Du zuerst a) bis sie testweise irgendetwas dem Berechnungsergebnis Aehnliches befriedigend darstellt. Dieses "irgendetwas" ist ein Platzhalter fuer die , die in diesem Augenblick noch abstrakt ist, aber vielleicht schon mit dem gleichen Funktionsnamen aufgerufen wird; sie existiert also nur als Schablone. Die Abstraktion verharrt dann laenger am Bottom als am Top.

Umgekehrt kannst Du aber auch zuerst schreiben, d. h. mit k o n k r e t e m Inhalt fuellen (dann ist sie nicht mehr abstrakt). Ihr Ergebnis steht vielleicht nur in einem Consolenfenster oder einer Datei, kann aber bereits an eine abstrakte Schablone fuer die spaeter zu erstellende Graphikroutine uebergeben werden. Also befindet sich nun die Abstraktion zu Beginn der Entwicklung am Top.

Ich weiss nicht, ob das den "wahren Lehren" des Softwaredesigns entspricht, aber so hab ich mir das immer erklaert. ;-)

hmm, hab das mal auf mich wirken lassen.

Ist dann in dem Beispiel a, die Graphikroutine Top

und die Berechnungsroutinge Bottom?

Kann man dann immer sagen, dass das Element, dass alleine "stehen" kann, bottom ist?

=> der Rest wäre dann Top (ist vom bottom abhängig)

Original geschrieben von b-r-e

>Ist dann in dem Beispiel a, die Graphikroutine Top

und die Berechnungsroutinge Bottom?

Wuerde ich sagen, ja.

>Kann man dann immer sagen, dass das Element, dass alleine "stehen" kann, bottom ist?

Noe, das kann zugleich auch Top sein. "Bungalow" gewissermassen. Top und Bottom definieren sich aus dem Verhaeltnis von mindestens zwei Elementen.

>der Rest wäre dann Top (ist vom bottom abhängig)

Gewissermassen. Einfach gesagt, baut Top auf Bottom auf.

Man sollte vielleicht noch erwaehnen, dass die Zusammenhaenge sich in der Realitaet nicht immer auf so einfache Zusammenhaenge vereinfachen lassen.

Original geschrieben von gajUli

Original geschrieben von b-r-e

Man sollte vielleicht noch erwaehnen, dass die Zusammenhaenge sich in der Realitaet nicht immer auf so einfache Zusammenhaenge vereinfachen lassen.

Tja, bei solchen "Gedankenmodellen" scheint mir das sehr oft der Fall zu sein.