La differenza tra il modello a cascata e il modello orientato agli oggetti? [chiuso]

-1

Si prega di spiegare la differenza tra il modello a cascata e il modello orientato agli oggetti.

Poiché i libri e i siti web che ho visto non forniscono molte informazioni a riguardo, ho bisogno che qualcuno me lo spieghi.

    
posta Stella Purple 30.06.2013 - 21:16
fonte

2 risposte

14
  • Modello a cascata è un processo di sviluppo software costituito da una sequenza di fasi (requisiti, progettazione, costruzione, test, implementazione, manutenzione), seguite dalla prima all'ultima, senza tornare indietro e senza utilizzare iterazioni (diversamente dai modelli Agile).

    Il modello a cascata aiuta a modellare la gestione del progetto.

  • Modello orientato agli oggetti è una rappresentazione di un pezzo di software come un insieme di oggetti che interagiscono tra loro, con l'obiettivo di ridurre la complessità del sistema e consentire agli sviluppatori di lavorare su uno specifico oggetto, trattando altri oggetti come caselle nere, con l'obbligo di conoscere solo le loro interfacce e non la loro effettiva implementazione.

    Il modello orientato agli oggetti aiuta a modellare l'architettura e il design di un'applicazione.

Come puoi vedere, il modello Waterfall e il modello orientato agli oggetti non possono essere confrontati. Spero che i paragrafi precedenti chiariscano cosa sono questi due modelli. In caso contrario, Wikipedia ha un buon articolo su Modello a cascata (così come la chiusura V-modello ), nonché un articolo dettagliato su OOP .

    
risposta data 30.06.2013 - 21:51
fonte
5

Queste sono creature completamente diverse.

Il modello a cascata è uno dei modi per organizzare il processo di sviluppo del software dividendolo in fasi sequenziali note come Requisiti, Progettazione , Implementazione, verifica, manutenzione. Ad esempio, il tuo capo ti ha detto che devi sviluppare un negozio online. Secondo il modello a cascata è necessario prima analizzare il compito, raccogliere tutte le informazioni possibili, parlare con i clienti, ecc. Per ottenere informazioni complete sui requisiti del progetto. Poi ti siedi e scrivi una specifica tecnica dettagliata del progetto in cui cerchi di tener conto di ogni possibile dettaglio e ogni possibile esigenza del cliente.

Quindi segue la fase di pianificazione in cui progetta il tuo software. È in questa fase che puoi scegliere un design orientato agli oggetti, una programmazione funzionale, un design orientato all'aspetto o qualche altro modello per il tuo software e prendere una serie di altre importanti decisioni su come strutturarlo. Se scegli un paradigma orientato agli oggetti, decomponi tutto in entità di base (Cliente, Magazzino, Transazione, ecc.) Modellato da oggetti, quindi progetti le loro interfacce e strutture di dati utilizzando UML.

E solo dopo tutta questa lunga preparazione per iniziare effettivamente il codice write (fase di implementazione). In questa fase si tenta di seguire le specifiche preparate in fase di progettazione il più vicino possibile. Solo dopo che il processo software è stato completamente scritto, arriva la fase di verifica (in cui i tester testano il software per accertarsi che sia completamente conforme alle specifiche e poi lo stesso venga fatto dal cliente). Dopo che il cliente ha accettato il software, si avvia la fase di manutenzione in cui aggiornare il software e correggere i bug.

Il problema più citato con questo approccio è che la vera scrittura di codice avviene molto tardi. Devi essere effettivamente fatto con una tonnellata di materiale burocratico prima di poter scrivere anche una sola riga di codice. Sulla mano, immagina che il tuo cliente decida di apportare alcune modifiche significative mentre stai scrivendo il soft. Con il modello a cascata, in realtà, significa che devi smettere di scrivere il codice e iniziare da capo l'intero processo fin dall'inizio, cioè raccogliere i requisiti, quindi aggiornare le specifiche e solo successivamente iniziare a cambiare il soft. È a causa della sua rigidità che il modello a cascata che un tempo era il modello predominante nel mondo dello sviluppo software ora è stato oscurato nella maggior parte dei campi da modelli più flessibili.

La programmazione orientata agli oggetti è un paradigma di programmazione. È un modo in cui progetta il tuo software, come ho già detto. È molto adatto per modellare situazioni del mondo reale perché qui tutto è considerato come oggetti. Continuando con l'esempio del negozio online, è possibile utilizzare Cliente, Transazione, Valuta, Magazzino, Prodotto, Categoria prodotto, Carrello acquisti e un sacco di altri oggetti. Nel tuo codice sarebbero quindi codificati come classi. Ogni oggetto qui ha proprietà . Ad esempio, Carrello acquisti può avere il numero di articoli nel carrello come sua proprietà. Anche gli oggetti hanno metodi che sono modi per interagire con altri oggetti. Ad esempio, il carrello può avere aggiungi (per consentire al cliente di aggiungere oggetti al carrello), rimuovere, svuotare e altri metodi.

    
risposta data 30.06.2013 - 22:32
fonte