Progettazione del software – parte III



Processi di sviluppo

Prima di distinguere i diversi processi di gestione dello sviluppo bisogna suddividerli in due grosse categorie che sono pianificazione predittiva e pianificazione adattiva. La prima tenta di creare dei piani dettagliati e quindi prevedere l’evolversi del software in maniera più precisa possibile. L’altra tecnica si basa sul fatto che la predicibilità dell’evolversi sullo sviluppo del software e bisogna quindi basarsi sul mutamento sull’imprevisto e sulla modifica dinamica del progetto. Per poter utilizzare le pianificazioni adattive sono nate diverse tecniche di supporto quali i test di regressione automatizzati (quali le unit test) che permettono di testare il software in contro verificando subito gli eventuali errori che una modifica può causare, poi è nato il refactoring una tecnica per modificare il codice di un programma in maniera disciplinata e infine l’integrazione continua ovvero rendere il più agevole possibile l’integrazione delle modifiche dei diversi programmatori, sono un esempio quei tool come i server CVS o SVN.
A questo punto possiamo suddividere i vari processi di sviluppo in:

Processo a cascata

Lo stile a cascata prevede di suddividere il progetto direttamente in base alle attività da svolgere (analisi, progettazione e realizzazione) tenendo in considerazione anche le sotto-attività (quali stesura del codice e testing). Ad esempio se si prevede che il progetto richiederà un anno si danno 2 mesi di analisi 4 di progettazione 3 mesi stesura codice e 3 mesi testing.

Processo iterativo

Questo stile suddivide il progetto in sottoinsiemi funzionali, sulle quali si itereranno le citate fasi di sviluppo. In pratica una volta diviso il progetto in più funzionalità indipendenti per ognuna di esse si eseguirà un intero ciclo di analisi, progettazione e realizzazione in modo tale da avere man mano un programma che porta a termine sempre più funzionalità.

Processi ibridi

Ovviamente nella pratica sono nati stili ibridi che mescolano più processi di sviluppo come lo stile a consegne programmate col quale si parte da un’analisi generica e poi si passa a una fase iterativamente.

Processi agili

Altre sì sono nati anche processi di sviluppo che cercano di ridurre al minimo la formalità di progettazione degli stili più comuni. Essi sono detti processi agili, e rientrano in quei metodi di progettazione adattivi citati prima.

Si definiscono processi agili quei processi che rispettano Il Manifesto dello Sviluppo Agile del Software e sono ad esempio la XP (eXtream Programming), la FDD (Feature Driven Development) la DSDM (Dynamic System Development Method).

Essi si basano molto sulle persone impiegate nel processo di sviluppo, sul loro talento e la loro passione, sono tecniche meno formali e forse meno professionali dal mero punto di vista aziendale, ma permettono di sfruttare al meglio le potenzialità e la creatività di ogni individuo.

È chiaro che questo richiede che tutti i componenti del team di sviluppo abbiano grandi predisposizioni ad una pianificazione fortemente adattiva.



Design pattern

Il concetto di pattern nasce in architettura, nel ’77, grazie all’architetto Christopher Alexander.

Per pattern intendeva lo schema di una soluzione con determinate regole per progettare case e città, si può quindi definire un pattern uno schema progettuale che risolve un determinato problema generale e ricorrente.

Poco tempo dopo questo concetto è stato ripreso anche in informatica, con l’intento di creare una collezione di schemi di soluzioni da applicare a problemi ricorrenti nella progettazione del software.

Ovviamente i pattern sono sempre applicati nella programmazione a oggetti, e sono caratterizzati da un breve nome, dalla descrizione del contesto, dalla descrizione dettagliata del problema e l’indicazione della soluzione; ila soluzione è anche rappresentata da un diagramma (rappresentato dal linguaggio grafico di modellazione UML visto in precedenza) che indica con maggiore immediatezza e precisione, e da un punto di vista più pratico, le classi da realizzare e le relazioni da creare fra di loro.

A secondo del genere di problema che risolvono i pattern si dividono in:

Creazionali:

Sono relativi alla creazione di oggetti, un esempio piuttosto ricorrente è il pattern singleton che rappresenta la soluzione ideale per creare una classe che possa generare uno ed un solo oggetto alla volta (quindi fino a quanto l’oggetto appena creato non viene distrutto dal programma in quanto non viene più usato, non se ne possono creare altri).

Strutturali:

Permettono di riutilizzare oggetti già esistenti da oggetti nuovi adattando l’interfaccia dei vecchi.

Quello più tipico è il pattern adapter, che fa appunto da adattatore.

Comportamentali:

I pattern di questo tipo forniscono le soluzioni migliori per determinate interazioni fra più oggetti, il pattern più noto di questa categoria è probabilmente quello chiamato observer, che permette a oggetti diversi di osservare, come lascia intendere il nome, lo stato di un determinato oggetto in modo tale che ad ogni cambiamento delle sue informazioni venga notificato a tutti quegli oggetti che ne hanno fatto richiesta.

Architetturali:

I pattern architetturali mirano a risolvere problemi di veduta molto più ambia dei pattern visti fino ad ora. Infatti è scopo del pattern architetturale impostare uno schema di base valido per l’intero progetto.

L’esempio sicuramente più famoso è il pattern MVC(Model View Controller) che consiste nel separare i componenti software che implementano il modello delle funzionalità di business (model), dai componenti che implementano la logica di presentazione (view) e da quelli di controllo che tali funzionalità utilizzano (controller).

Concorrenziali:

Essi si applicano in quelle situazioni in cui il processo utilizza attività concorrenti (chiamati Thread) e servono a mantenere sincronizzato lo stato dei dati.

Gli anti-pattern

Così come esistono i pattern che sono le cose da fare in determinate situazioni esistono anche le cosa da evitare assolutamente durante lo sviluppo del software, essi sono detti anti-pattern.

Gli anti-pattern sono forse anche più numerosi dei pattern, e rappresentano in genere situazioni che nascono nel progetto che rendono inutilmente complesse le relazioni o creano dipendenze inutili fra oggetti che danneggiano la manutenibilità del progetto e il proseguimento dello sviluppo.

Dal punto di vista tecnico un esempio di anti-pattern è l’azione a distanza, esso si verifica quando un determinato oggetto modifica in maniera drastica, improvviso e invisibile lo stato di un oggetto lontano, violando la così detta legge di Demetra. Essa dice che dice che un oggetto deve interagire solo con gli oggetti vicino a lui, e nei casi in cui sia strettamente richiesta un’operazione a distanza il messaggio deve passare per tutti gli oggetti vicini fino ad arrivare all’oggetto da modificare.

Per concludere l’anti-pattern che si cerca di evitare più in assoluto è il reinventing the wheel (reinventare la ruota), quindi evitare di ricreare da zero determinate parti di progetto che sono già state progettate, realizzate e ben collaudate; durante lo sviluppo software è quindi fondamentale la filosofia dell’ “evitare di rendere difficili le cose facili mediante l’uso dell’inutile”.

Bibliografia:

*

Progettazione del software e design pattern in Java – Cay S. Horstmann – Apogeo
*

UML Distilled, Guida rapida al linguaggio di modellazione standard – Martin Fowler – Pearson
*

C++ fondamenti di programmazione – H. M. e P.J. Deitel – Apogeo
*

C++ tecniche avanzate di programmazione – H. M. e P.J. Deitel – Apogeo
*

La guida completa C++ – Herbert Schildt – McGrawHill
*

Fondamenti di programmazione Java 2 – Herbert Schildt – McGrawHill
*

La guida completa Java 2 – Herbert Schildt – McGrawHill
*

Microsoft Visual C# 2005 Passo per Passo – John Sharp – Mondadori
*

Python 2.1 Tutto e Oltre – David Brueck e Stephe Tanner – Apogeo

Annunci sponsorizzati:
Condividi su Facebook Condividi su Twitter!
Pinterest