1) Definire il concetto di processo di sviluppo “Code & fix”
Il processo di sviluppo “Code & Fix” è l'approccio più antico secondo cui si scrive il codice e lo si aggiusta per eliminare gli errori che sono stati scoperti, per migliorare le funzionalità esistenti e/o aggiungere nuove caratteristiche. Questo approccio è ingestibile ed è impossibile fare previsioni.
È un modello di processo di sviluppo di un sistema software che non prevede la fase di progettazione: viene scritto direttamente tutto il codice che poi, alla fine, dovrà essere interamente corretto.
Data la mancanza della fase di progettazione, richiede grossi costi di manutenzione del codice.
2) Definire il concetto di progettazione difensiva
La progettazione difensiva consente un approccio in cui si anticipano i rischi di fallimento di un modulo (parte di un sistema software che fornisce un insieme di servizi ad altri moduli) e si decide se evitarle o tollerarli tramite le eccezioni (eventi attraverso cui il modulo servente, prima di terminare la sua esecuzione, segnala al modulo cliente che non è riuscito a completare correttamente il servizio richiesto nel rispetto della postcondizioni). Il modulo cliente risponde gestendo opportunamente l'eccezione.
La progettazione difensiva si basa sulla previsione dei rischi di fallimento dovuti al mancato soddisfacimento di un’asserzione. Si passano sostanzialmente in rassegna le precondizioni e postcondizioni per valutare cosa accade se un’asserzione non viene verificata e per comprendere la gravità delle possibili conseguenze.
3) Definire il concetto di progettazione per contratto
Il sistema software viene progettato a seguito di un accordo comune tra cliente e contraente.
Vengono usati tre tipi di asserzioni (espressioni booleane che possono risultare false solo in presenza di errori di programmazione). Ogni precondizione e postcondizione è associata specificatamente a un singolo metodo e, in generale, sono diverse per ogni metodo mentre ogni invariante è associata specificatamente ad una singola classe e, in generale, sono diverse per ogni classe.
Si tratta di un tipo di progettazione sviluppato nel 1992 ed è basata sul concetto di “contratto”, inteso come accordo fra un cliente e un contraente. È particolarmente adatto alla programmazione OO dove si fa riferimento a classe cliente, classe contraente, interfaccia della classe contraente (contratto). In particolare entrambe le classi hanno obblighi e benefici. La progettazione per contratto è basata sulle precondizioni e sulle postcondizioni, ossia gli obblighi che, rispettivamente, devono essere rispettati dalla classe cliente (metodo cliente) e classe contraente (metodo contraente). Gli obblighi del cliente sono le precondizioni, ossia delle condizioni sullo stato dell’oggetto su cui il metodo è invocato e sui parametri in ingresso. Gli obblighi del contraente sono le postcondizioni, ossia condizioni sui parametri di uscita e devono essere vere al termine dell’esecuzione del metodo.
4) Definire il concetto di correttezza di un sistema software
Il software è corretto se soddisfa le specifiche funzionali. Se le specifiche funzionali sono formali la correttezza può essere provata formalmente, oppure tramite controesempi.
Un sistema software è corretto se soddisfa le specifiche dei requisiti funzionali. È sufficiente anche un solo episodio in cui non vengono rispettati per determinare la non correttezza del software. La correttezza del software viene verificata tramite l’attività di testing. Affinché possa essere verificata è necessario che i requisiti siano espressi in maniera chiara e rappresentando le vere esigenze del cliente.
5) Fornire brevemente alcune valide ragioni per cui utilizzare UML
Perché
- È un linguaggio visuale di modellazione che supporta tutte le fasi della progettazione e dello sviluppo del software a oggetti
- Cons