Brei Geschrieben 26. Dezember 2003 Teilen Geschrieben 26. Dezember 2003 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? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bimei Geschrieben 26. Dezember 2003 Teilen Geschrieben 26. Dezember 2003 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. ;-) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Brei Geschrieben 26. Dezember 2003 Autor Teilen Geschrieben 26. Dezember 2003 Was meinst du mit "Abstraktion"? Kann ich jetzt hier nicht ganz zuordnen! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bimei Geschrieben 26. Dezember 2003 Teilen Geschrieben 26. Dezember 2003 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Brei Geschrieben 26. Dezember 2003 Autor Teilen Geschrieben 26. Dezember 2003 was besagt dann die up-down Methode? Kann man dann meinen Ansatz auch "gelten" lassen: je nach dem von oben, oder unten anfangen? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bimei Geschrieben 26. Dezember 2003 Teilen Geschrieben 26. Dezember 2003 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Brei Geschrieben 26. Dezember 2003 Autor Teilen Geschrieben 26. Dezember 2003 unten = das eigentliche programm was die ARbeit macht oben = Module, die nur zur "hilfe" dienen Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bimei Geschrieben 26. Dezember 2003 Teilen Geschrieben 26. Dezember 2003 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
gajUli Geschrieben 26. Dezember 2003 Teilen Geschrieben 26. Dezember 2003 "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. ;-) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Brei Geschrieben 2. Januar 2004 Autor Teilen Geschrieben 2. Januar 2004 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) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
gajUli Geschrieben 3. Januar 2004 Teilen Geschrieben 3. Januar 2004 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Brei Geschrieben 3. Januar 2004 Autor Teilen Geschrieben 3. Januar 2004 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. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.