Archivi tag: UML

Metodologie di progettazione del software Object-Oriented

Introduzione
In questo articolo faccio delle considerazioni personali sul modo in cui le metodologie di progettazione del software object-oriented più largamente utilizzate dovrebbero essere impiegate al fine di realizzare del software valido in tempi ragionevoli.
Queste considerazioni sono nate dagli studi che ho condotto nel campo della ingegneria del software e dagli anni che ho trascorso sviluppando sistemi informativi distribuiti in contesti lavorativi diversi.

L’esigenza di esprimere queste considerazioni deriva dal raggiungimento della consapevolezza di quanto sia complesso applicare efficacemente suddette metodologie e constatando di persona che spesso nelle aziende produttrici di software a causa dei tempi ristretti e delle esigenze di budget si passi molto velocemente alla fase di sviluppo del codice dedicando pochissimo tempo alle fasi di analisi e progettazione.

Per realizzare un software valido è necessario raggiungere il giusto compromesso tra la teoria fornita dalle metodologie e la pratica acquisita sul campo di lavoro, nei prossimi paragrafi descrivo il mio modo di procedere e fornisco delle utili linee guida cui far riferimento durante il processo di progettazione del software.

Il quadro generale

Il ciclo di vita del software è costituito da una serie di fasi iterative di raffinamento del codice:
1. Analisi dei requisiti utente e del dominio dati
2. Progettazione
3. Implementazione
4. Testing
5. Manutenzione

Per ottenere un buon risultato sono fondamentali le prime due fasi. Purtroppo nella maggior parte dei contesti lavorativi sono il tempo ed il budget a farla da padroni e per realizzare il software nei tempi previsti (insufficienti) e con i costi stimati (troppo bassi) si dedica poco tempo alle fasi di analisi e progettazione (circa il 30% del tempo totale) e si dedica il tempo restante alla implementazione (circa il 70% del totale).
Se si è fortunati si riesce a dedicare qualche giorno al testing e alla documentazione.

Si ottiene cosi un software che soddisfa solo in parte le esigenze del cliente, pieno di bachi e poco robusto.
In questo contesto risulta necessario mettere delle “toppe” al codice prodotto e a volte si giunge alla conclusione che al cliente non resta altro che accontentarsi del software realizzato perche non è possibile modellare il prodotto esistente per adattarlo ai requisiti utente.
Ho fatto un quadro abbastanza realistico di come vanno le cose, la realtà è che si cerca di educare allo sviluppo del software introducendo delle metodologie di progettazione ma viviamo in un mondo informatico costituito da analisti programmatori inventati, ignoranti e smanettoni e da società il cui obiettivo è fare un utile in tempi brevi e con il massimo profitto.

Il paradosso è che si fa informatica senza conoscere l’informatica.
Questo traguardo è possibile perchè negli ultimi decenni l’informatica ha fatto passi da gigante grazie all’operato di poche menti illustri. Adesso chiunque può scrivere del codice. Provo a fare una metafora mettendo in relazione l’arte della programmazione con il gioco degli scacchi.

Ci vogliono dieci minuti per imparare le regole del gioco degli scacchi, cosi come ci vuole poco tempo per smanettare un linguaggio di programmazione. Nel mondo degli scacchi ci muoviamo dentro una scacchiera, nel mondo della programmazione ci muoviamo all’interno di un IDE (Integrated Development Enviroment) di sviluppo. Apprese le regole del gioco degli scacchi possiamo cominciare a fare qualche partita cosi come appresi i concetti elementari della programmazione (assegnazione,condizione,iterazione) possiamo cominciare a scrivere i primi algoritmi in un linguaggio di programmazione.

Riflettiamo, però, sui risultati che raggiungiamo.
Nel gioco degli scacchi muovere i pezzi limitandoci a rispettare le regole non ci porta molto lontani cosi scrivere delle istruzioni che soddisfano le regole sintattiche del linguaggio e le regole semantiche dell’algoritmo non ci permette di raggiungere un grande traguardo. Ciò che manca in entrambi i casi è l’uso di una strategia, la differenza per vincere a scacchi o per sviluppare un buon software sta nell’uso di una strategia vincente.

Nel gioco degli scacchi la strategia vincente deriva da anni di studio e di applicazione nel gioco, cosi come nella programmazione la strategia vincente deriva dallo studio delle metodologie di progettazione del software e dal loro impiego nel tempo.
Concludo questa metafora ribadendo il concetto che conoscere il gioco degli scacchi non ci rende dei maestri e che conoscere i costrutti dell’informatica e i linguaggi di programmazione non fa di noi dei buoni progettisti di software.

In entrambi i casi serve molto studio e applicazione sul campo, possiamo studiarci dieci libri sugli scacchi ma se non facciamo mai una partita abbiamo solo assimilato tante nozioni che sono nascoste da qualche parte nel nostro cervello; allo stesso modo possiamo studiare per anni le metodologie di progettazione del software ma se non realizziamo mai un progetto/sistema informativo restano solo teoria non applicata.

Il grande fisico tedesco Albert Einstein sintetizzò questo concetto cosi:

“La teoria è quando si sa tutto ma non funziona niente. La pratica è quando funziona tutto ma non si sa il perchè. In ogni caso si finisce sempre con il coniugare la teoria con la pratica: non funziona niente e non si sa il perchè.”
Albert Einstein

Applicazione delle metodologie di progettazione OO
Nel corso degli anni sono state sviluppate diverse metodologie di progettazione del software, le tre piu comuni sono la progettazione imperativa quella funzionale e quella orientata agli oggetti.
Si rimanda ad altri testi per approfondimenti sul paradigma imperativo e quello funzionale, qui ci concentreremo su quello ad oggetti visto che è oramai il più diffuso e utilizzato.
Forniamo delle linee guida che ci indicano quando e come usare le metodologie Object Oriented per la realizzazione di un software.

Guide line1: Usare una metodologia OO quando il progetto da realizzare è complesso.
Commento: Se dobbiamo realizzare progetti semplici si può dedicare poco tempo alle fasi di analisi e progettazione e cominciare subito a sviluppare il codice. Quando un progetto è di bassa complessità le fasi di analisi e progettazione richiedono un basso sforzo mentale e possono essere realizzate scrivendo appunti e considerazioni su carta e andando direttamente a sviluppare.

Guide line 2: Usare la metodologia OO per progettare solo gli aspetti complessi del sistema da realizzare.
Commento: Una metodologia di progettazione ha lo scopo di aiutare il progettista a rappresentare in maniera chiara, comprensibile ed efficace il sistema che deve realizzare.
E’ sbagliato descrivere scrupolosamente ogni dettaglio del sistema perche ciò inevitabilmente aumenta i tempi di progettazione e la difficoltà di comprensione del progetto realizzato. Ci si deve, invece, concentrare sugli aspetti chiave del sistema e descriverli fino ad un livello di dettaglio sufficiente per uno sviluppo adeguato dello stesso.

Guide line 3: Non perdere mai di vista l’obiettivo primario
Commento: L’obiettivo di un progettista deve essere quello di rappresentare il sistema da realizzare in maniera chiara, semplice ed efficace al fine di consentire uno sviluppo efficiente dello stesso.

Ogni metodologia introduce delle notazioni, dei concetti, dei costrutti sintattici e semantici propri attraverso i quali permette al progettista di rappresentare il sistema da realizzare facendo uso di astrazioni. Quello che a volte succede è che il progettista nel tentativo di astrarre il sistema finisca con il perdere il suo obiettivo primario che è rappresentare un aspetto del sistema in maniera semplice e utile e cominci a soffermarsi su aspetti legati alla metodologia.

In altre parole il progettista viene distolto dallo studio del sistema e si ritrova a ragionare su aspetti legati all’astrazione del sistema che sta realizzando incorrendo nell’errore di realizzare una astrazione stupenda dal punto di vista della completezza e dell’uso dei costrutti ma talmente complessa che è di difficile interpretazione sia per lui che per gli altri progettisti che lavorano al progetto.

Una metodologia OO
Una buona metodologia di progettazione dovrebbe essere di facile comprensione e dovrebbe permettere una rappresentazione dei sistemi da realizzare adatta, utile ed efficace per e esigenze del progettista.
Essendo appassionato di ingegneria del software ho studiato diverse metodologie OO e quella che ho trovato più utile è la OMT (Object Modeling Technique).

La metodologia OMT è stata ideata da James Rumbaugh negli anni novanta.
Rumbaugh, assieme a Booch e a Jacobson, ha ideato l’UML (Unified Modeling Language), uno strumento che consente la rappresentazione visiva di modelli ad oggetti.

Personalmente trovo che la metodologia OMT corredata dalla rappresentazione degli oggetti attraverso diagrammi UML sia un valido strumento di progettazione del software orientata agli oggetti.
Uso abitualmente tale metodologia con piena soddisfazione e con buoni risultati.

Per un approfondimento della metodologia OMT rimando al libro di Rumbaugh Object-Oriented Modeling and Design
.

Creative Commons LicenseMetodologie di progettazione del software Object-Oriented by Simone Moretti is licensed under a Creative Commons Attribuzione-Condividi allo stesso modo 2.5 Italia License.

Simone Moretti è l’autore della collana “Guida al Self-Publishing”.

La collana “Guida al Self-Publishing” è composta dai seguenti cinque volumi:
VOL.1: Creiamo un eBook con Kindle Direct Publishing
VOL.2: Creiamo un libro cartaceo con CreateSpace
VOL.3: Creiamo libri cartacei ed ebook con Lulu
VOL.4: Promuovere un libro con il social media marketing
VOL.5: Self-Publishing: Guida Completa

Creiamo un eBook con Kindle Direct Publishing

Creiamo un eBook con Kindle Direct Publishing

Creiamo un libro cartaceo con CreateSpace

Creiamo un libro cartaceo con CreateSpace

Creiamo libri cartacei ed ebook con Lulu

Creiamo libri cartacei ed ebook con Lulu

Promuovere un libro con il social media marketing

Promuovere un libro con il social media marketing

Self-Publishing: Guida Completa

Self-Publishing: Guida Completa

Annunci