modellazionegraficanellosviluppoagile

Summary Alcune considerazioni sulla modellazione UML in un ambito di metodologie di sviluppo software agile

Pubblicato nella Rubriki Numero 0 - 30 Nov 2005 da Roberto Messora

Sviluppo agile e modellazione grafica

Personalmente credo fermamente che qualsiasi metodologia consolidata, debba necessariamente passare attraverso una fase di adattamento nel momento in cui un team di sviluppo sw ne abbraccia i principi. Potrebbe essere una frase questa del tutto banale, ma a mio avviso non fa male ripeterla all’infinito.

Nel caso in oggetto mi riferisco al complesso delle metodologie agili di cui si fa un gran parlare da qualche anno a questa parte: non c’è dubbio, almeno dal mio punto di vista, che nessuna altra metodologia debba essere “digerita” quanto quelle che in un modo o nell’altro si rifanno al movimento agile.

Per parlare chiaro io credo che l’ambiente e le variabili esogeni al team di sviluppo, cioè tutto ciò che non è sotto il suo controllo, molto poco si adattano ad una qualsiasi delle metodologie agili oggi proposte. È soprattutto un motivo di cultura di base, soprattutto di coloro che commissionano la realizzazione del sw, volgarmente i clienti, e ci vorrà necessariamente del tempo (io credo molto) prima che l’approccio agile alla realizzazione di soluzioni sw diventi accettato come standard di mercato fra gli altri standard.

D’altra parte però esistono anche l’ambiente e le variabili endogene al team di sviluppo, cioè tutto ciò che è sotto il suo diretto controllo. In questo ambito io credo si possa effettivamente applicare, se non tutti, molti dei principi delle metodologie agili, sia in termini di approccio “filosofico” all’attività di sviluppo, sia in termini di pratiche quotidiane.

Il mio intento è quello di offrire alcuni spunti circa una delle pratiche che si innestano nel processo di sviluppo che oserei definire “snello”, nel senso che non lo posso considerare pienamente agile in quanto, se da una parte internamente il team in cui lavoro si sta sforzando di pensare agile, dall’altra la gestione del cliente è tutto tranne che agile, ed anzi, spesso ci impone la produzione di dettagliati (?!?) diagrammi MS Project sin da subito.

La pratica di cui parlo è quella che riguarda l’attività di design, che non chiamerò ovviamente “fase” nel momento in cui si parla di metodologie agili. Va oltre lo scopo di questo testo quello di proporre un ripasso di cosa significhi esattamente una metodologia di sviluppo agile, quindi parto dal presupposto che in qualche modo chi legge abbia idea di come si innesta l’attività di design all’interno di tali metodologie.

Il design secondo la mia esperienza è un’attività che viene affrontata in modo molto personale da ogni sviluppatore. Tutti i giorni, coscientemente o meno, facciamo design: a partire dai grandi architetti che tratteggiano i massimi sistemi e le architetture complesse, fino allo sviluppatore junior che deve implementare un’operazione CRUD su un’unica tabella legacy. Arrivo addirittura a dire che non esisterebbe l’attività di scrittura di codice senza quella di design, in qualunque ambiente questa venga svolta (agile o waterfall che sia).

Ebbene, un modo fra i tanti (che può quindi piacere o non piacere) di fare design, è quello di modellare graficamente i componenti, i processi, i servizi, il flusso di messaggi e dati, e quanto altro sia coinvolto in una soluzione sw.

Parlare di design “grafico” significa soprattutto UML, non è certo una verità scritta nella pietra, ma credo che il livello di maturità raggiunto da UML (arrivato alla sua formulazione 2.x) sia tale da annoverarlo quale framework principe della modellazione sw.

Nel mio piccolo team sono l’unico che ne fa uso, mi sono interrogato sul perchè di questa mia preferenza non condivisa dagli altri e la risposta che mi sono dato riguarda l’inclinazione personale verso la rappresentazione pittorica di un concetto. Io sono una di quelle persone che pensa per diagrammi, anche mentalmente sono propenso a schematizzare, quindi trovo grande supporto da una rappresentazione grafica standardizzata come UML. Questa mia inclinazione però mi ha portato ad alcuni eccessi ed inefficienze che ho dovuto correggere nel tempo.

Non dobbiamo mai dimenticare che il nostro lavoro è quello di produrre soluzioni applicative funzionali ed efficienti, in ultima analisi righe di codice se vogliamo banalizzare. Il nostro lavoro non è produrre diagrammi, questi possono aiutare la stesura del codice, ma qui si devono fermare.

Questo discorso è tanto più vero quando si lavora con metodologie agili. La pratica del design spesso dura lo spazio di una manciata di minuti, magari possiamo arrivare alla mezz’ora, prima di mettere mano al listato per farne refactoring o per aggiungere nuove funzionalità. Il processo è iterativo, quindi ci si troverà spesso nella condizione di fare design. Risulta quindi davvero molto importante non eccedere, avere ben presente perché si fa che cosa e in che termini.

Una mente visuale è molto aiutata da un grafico, ma il vero problema sta nel quanto la creazione del grafico stesso impegni le risorse di chi lo realizza. Ebbene, questo aspetto è quello più delicato. Ci sono molti modi per creare un diagramma UML: lo si può tratteggiare su carta, oppure alla lavagna magnetica, o ancora con un tool sw visuale, o per essere davvero tecno-maniaco su un bel tablet magari collegato ad un proiettore. Si può davvero esagerare: se fate un rapido giro su internet troverete una pletora di tool sw visuali che promettono una gestione completa ed efficiente dei vostri diagrammi UML.

Una sola parola diffidate.

Produrre codice in modo agile significa essere e pensare agili. Questa frase l’ho mutuata tale e quale da uno splendido libro che ho letto questa estate e che porto sempre con me (per davvero). Un libro che fra l’altro mi ha spinto a scrivere questo pezzo, sulla stessa falsariga di alcune sue pagine. Il libro è “The Object Primer: Agile Model-driven Development with UML 2.0” di Scott Ambler, molto conosciuto anche per un altro ottimo libro sulle tecniche agili di ideazione e realizzazione dei database.

UML è molto esteso, ha in pratica un tipo di diagramma per qualsiasi cosa sia coinvolto nell’informatica (forse manca effettivamente quello per la modellazione delle GUI), ma questo non significa che necessariamente debbano essere utilizzati tutti e soprattutto in maniera particolareggiata. Personalmente credo che sia un’impresa impossibile creare un buon sw senza partire da uno schema del domain model e del deploy finale dei componenti. Ma questo non significa che d’altra parte sia necessario illustrare il workflow di un metodo di una classe prima di scriverne il codice. Soprattutto se vengono utilizzate anche tecniche di code inspection per la verifica dell’aderenza agli standard, non ha senso arrivare ad un tale dettaglio quando il codice stesso indica già che cosa fa.

Ma c’è anche un altro aspetto fondamentale: l’aspetto iterativo delle metodologia agile impone il viaggiare leggeri: come sarebbe possibile mantenere decine di diagrammi UML durante il procedere dello sviluppo? Già a metà dell’impresa si alzerebbe bandiera bianca, non ho mai provato, ma spesso ho fatto fatica lavorando su una quindicina di diagrammi di alto livello.

Insomma ci vuole calma e sangue freddo… In genere quello che a me capita è di lavorare sin da subito sul domain model, quindi su due-tre class diagram (sto parlando di progetti medi di circa 6-8 mesi uomo), gli use case invece sono trattati in genere in maniera del tutto testuale o tabellare, trovo scomodo onestamente disegnarli. Altri diagrammi UML vengono fuori da questo brodo primordiale quando abbiamo bisogno di confrontarci, perché non c’è niente di meglio che una lavagna magnetica, un paio di pennarelli, un cancellino e un sano vociare durante un design collettivo. A volte ho trovato molto utile anche usare UML per implementare macchine a stati complesse, ma in questo caso la specificità del settore in cui lavoro mi ha fornito questo spunto.

Il mio supporto preferito? Carta e lapis… i tool sw ad oggi mi hanno molto deluso, certo che la manutenzione dei diagrammi diventa poi un po’ problematica (anche se ridisegnare costringe a pensare lentamente e spesso ad una seconda lettura a freddo emergono errori concettuali o domande fondamentali per la vita del progetto).

Insomma, ripeto ancora, viaggiare leggeri, soprattutto in team, però non disdegnare mai un bel diagramma, quando un disegno vale più di mille parole.

Feedback

Pensi che gli strumenti (ClassDesigner, ApplicationDesigner, SystemsDesigner, etc...) di Visual Studio 2005 riescano a sopperire almeno in parte alle lacune di UML, essendo direttamente legati al codice e non soggetti alla sindrome del Forward<->Reverse? -- LorenzoBarbieri [2006-05-14]

Pubblicato nella Rubriki Numero 0 - 30 Nov 2005 da Roberto Messora

Sviluppo agile e modellazione grafica

Feedback

UGIdotNETWiki