Discussione:Progettazione top-down e bottom-up

	Questa voce rientra tra gli argomenti trattati dal progetto tematico sottoindicato. Puoi consultare le discussioni in corso, aprirne una nuova o segnalarne una avviata qui.
Neuroscienze bar di progetto monitoraggio voci

	La voce non è stata ancora monitorata, fallo ora!
nc Nessuna informazione sull'accuratezza dei contenuti. (che significa?) nc Nessuna informazione sulla scrittura. (che significa?) nc Nessuna informazione sulla presenza di fonti. (che significa?) nc Nessuna informazione sulla presenza di immagini o altri supporti grafici. (che significa?)

Cronologia Top down e bottom up

Il 26/02/2008 la voce Top down e bottom up è stata integrata in Progettazione top-down e bottom-up. Precedente cronologia della voce Top down e bottom up:

    * (corr) (prec)  11:56, 26 feb 2008 Mess (discussione | contributi) (48 byte) (informazioni integrate, trasformo in redirect) (annulla)
    * (corr) (prec) 19:38, 7 dic 2007 Bultro (discussione | contributi) (3.176 byte) (U) (annulla)
    * (corr) (prec) 13:57, 1 dic 2007 Toobazbot (discussione | contributi) m (3.109 byte) (Inserimento automatico del portale matematica) (annulla)
    * (corr) (prec) 09:51, 27 nov 2007 Twice25 (discussione | contributi) m (3.085 byte) (+cat) (annulla)
    * (corr) (prec) 09:43, 27 nov 2007 Twice25 (discussione | contributi) (3.056 byte) (wikific.) (annulla)
    * (corr) (prec) 17:59, 29 giu 2007 87.8.187.181 (discussione) (2.963 byte) (annulla)
    * (corr) (prec) 17:58, 29 giu 2007 87.8.187.181 (discussione) (2.962 byte) (annulla)
    * (corr) (prec) 17:42, 29 giu 2007 87.8.187.181 (discussione) (2.956 byte) (annulla)
    * (corr) (prec) 17:41, 29 giu 2007 87.8.187.181 (discussione) (2.958 byte) (annulla)
    * (corr) (prec) 17:40, 29 giu 2007 87.8.187.181 (discussione) (2.958 byte) (annulla)
    * (corr) (prec) 14:46, 4 mar 2007 Biopresto (discussione | contributi) m (ha spostato Top down a Top down e bottom up) (annulla)
    * (corr) (prec) 14:46, 4 mar 2007 Biopresto (discussione | contributi) m (annulla)
    * (corr) (prec) 22:31, 1 feb 2007 Snowdog (discussione | contributi) m (+Wikificare) (annulla)
    * (corr) (prec) 22:30, 1 feb 2007 84.221.105.70 (discussione) (top down e bottom up)

Bottom-Up e OOP?

Ciao. Leggevo che si fa riferimento a Java e C++ per l'approccio Bottom-Up. La frase e' anche un po' ambigua

"Eventualmente, i componenti sono specificati quanto basta per la codifica ed il programma viene anche scritto. Questo è l'esatto opposto della programmazione bottom-up che è comune nei linguaggi orientati agli oggetti come C++ o Java."

Da questa frase non e' chiarissimo se si intenda che i linguaggi OO comunemente usano o meno l'approccio bottom-up, o l'opposto.

Se si intende che i linguaggi OO siano per natura orientati al design bottom-up non sono molto d'accordo. Gli IDE recenti permettono di scrivere all'interno di un metodo una chiamata ad una variabile/campo/metodo/classe che ancora non esistono, quindi di fare un "Quick Fix" cioe' lasciare all'IDE il compito di definire il metodo/classe/variabile/campo. Vedi: http://www.vogella.de/articles/Eclipse/article.html#tips_quickfix . Questo e' esattamente l'approccio top-down: definisco il chiamante prima del chiamato, e poi mi concentro sul dettaglio. Ed e' questo l'approccio corretto anche in OO: partire dall'astratto per arrivare al dettaglio. Un esempio di ciò in OOA sono sequence diagrams UML: si parte sempre dal disegnare l'attore, che quindi interagisce con i sottosistemi che vengono aggiunti successivamente e collegati con frecce che ne rappresentano le interazioni.

Sulla testabilita' di questo approccio, oggi esistono strumenti che permetto di testare unitariamente (e in isolazione) classi che fanno uso di codice non ancora pronto (dipendenze ancora non definite). Utilizzando IoC e mock ( http://mockito.org/ ) e' possibile passare, per esempio ad una business class che esegue la procedura di login un "mock" del database che simula cioe' il comportamento che ci attendiamo dal database. Quindi si puo' tranquillamente partire dal design dell'interfaccia grafica, collegarla con la business logic, quindi testare che alla pressione di un dato bottone la logica di business venga chiamata. Quindi testare le interazioni tra i sottosistemi che compongono la business logic, verificando che le iterazioni avvengano secondo le aspettative. Fatto questo, si scende di dettaglio in dettaglio fino ad arrivare ad esempio, in ultimo stadio all'accesso al database; quindi testare che chiamando i metodi ultimi della business logic si ottenga il risultato voluto sulla base dati. Infine quando il cerchio viene chiuso si fa un test completo di integrazione che comprende il caso d'uso completo, simulando l'interazione di un utente sulla interfaccia grafica e arrivando fino alla base dati o ai sistemi esterni, verificando che il comportamento end-to-end aderisca ai requisiti e al comportamento atteso.

Personalmente non trovo corretto associare l'approccio bottom-up a Java o ad altri linguaggi OO. L'approccio top down non e' necessariamente una complicazione alla scrittura dei test, tant'e' che i test si dovrebbero scrivere *prima* del codice da testare secondo la pratica "Test Driven Development", che quindi e' gia' di-per-se un approccio Top-Down. Sono d'accordo con quanti sostengono che TDD deve partire dalle user stories/test funzionali e finire con test di dettaglio ( http://exceedhl.wordpress.com/2007/08/02/tdd/ ).

Un ultimo appunto sulla pagina in discussione: La sezione pro/contro non si capisce con chiarezza a chi e' riferita (top-down o bottom-up?), essendo il titolo della pagina "progettazione top-down e bottom-up".

Scusate se commento qui, non sono un wikipediano consumato, e non conosco bene i protocolli per modificare/aggiornare le cose. Ma trovo che purtroppo molti programmatori lavorano bottom-up perche' e' istintivamente l'approccio piu' "ovvio". Poi puntualmente i pezzi non si incastrano perche' nella foga di disegnare dettagli sopra dettagli hanno anche over-ingegnerizzato il codice aggiungendo passaggi e layer inutili, quindi ogni minima modifica necessaria al completamento risulta di una complessita' proibitiva. Inoltre il codice cosi' strutturato e' sempre un gran casino da capire e gestire, e questo e' il motivo per cui gran parte del software e' scadente.

Saluti.

Luigi R. Viggiano

Bottom-Up e TopDown

Ciao ,sono Matteo Bonicolini,sono iscritto da poco e volevo inserirmi nel discorso di Luigi.Ho corretto la voce perchè a mio avviso screditava l'approccio bottomup(in particolare il riferimento al fatto che è adatto per problemi lineari di natura semplice).Quello che dice sopra luigi riguardo OOP e TDD è ,a mio avviso, assolutamente vero.Bisogna però ricordare quanto segue: per usare una progettazione "full topdown" è necessario conoscere a fondo il problema e le sue eventuali soluzioni.Se non si conosce a fondo il problema è difficile prevedere le possibili soluzioni e di conseguenza e la progettazione topdown risulta di difficile applicazione.Allo stesso modo è vero che la progettazione topdown ti permette di astrarre dal particolare e quindi fornisce una visione generale del problema aiutandone la comprensione.A mio avviso se si parla di settori sperimentali,l'approccio bottomup è plausibile e remunerativo poichè permette di capire nell'intimo il problema con i suoi dettagli.Parlando a titolo esclusivamente personale: è difficile capire come funzionano le cose se prima non si prova a risolverle.Tendenzialmente ,sempre a titolo personale,quando sviluppo sw particolari ,fatte le specifiche generali e una bozza di design,parto con un approccio bottomup.Finito lo sviluppo, ho una visione chiara del problema, lo rianalizzo in chiave TopDown e sviluppo il sw definitivo tenendo conto dei concetti di design,riusabilità ed estensione del sw nel futuro. Il rischio grosso del bottomup ,come dice Luigi,è quello di crollare sotto il peso del problema. Il topdown da parte sua produce organizzazione,e standardizzazione(comprendendone sia il senso positivo che negativo). Si adatta bene quindi a realtà industriali o a realtà dove ci sono molte persone a lavorare al solito progetto. Quindi ,pur ricordando che l'approccio TopDown è quello prevalente nell'industria ed è quello insegnato all'Università,ed è quello maggiromente apprezzato dai professsionisti del settore,propongo la riscrittura della pagina in chiave neutra magari anche elencando una serie di lavori prodotti con i due approcci.Molti sottovalutano gli aspetti positivi del bottomup(la stessa wikipedia è scritta con questo approccio).Spero comunque che la discussione continui perchè ha evidenziato aspetti interessanti.

http://portal.acm.org/citation.cfm?id=182389
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.950

Matteo Bonicolini aka BlackBonko

Collegamenti esterni interrotti

Una procedura automatica ha modificato uno o più collegamenti esterni ritenuti interrotti:

• Aggiunta del link all'archivio https://archive.is/20120709151610/http://erg4146.casaccia.enea.it/wwwerg26701/Gad-toga.htm per http://erg4146.casaccia.enea.it/wwwerg26701/Gad-toga.htm

In caso di problemi vedere le FAQ.—InternetArchiveBot (Segnala un errore) 06:57, 13 dic 2022 (CET)