analisi-disegno.com
Si può usare il cacciavite come se fosse un martello, per piantare chiodi. Oppure al posto di una pinza, per togliere quelli già piantati. Il cacciavite può anche servire per tagliare il formaggio, volendo. Ma non è fatto per quello, ed esistono strumenti migliori per tagliare il formaggio.
Per i casi d'uso è lo stesso. Vengono usati in tutti i modi possibili, e anche impossibili, come se fossero un coltellino svizzero milleusi. Ma non conviene, perché funzionano bene solo quando vengono usati per quello che sono.
Ho già scritto anni fa sui principali errori nell'uso dei casi d'uso. E sul fatto che sono più adatti a descrivere certi tipi di sistema, e meno adatti per altri tipi di sistema. Ma i casi d'uso si prestano ad utilizzi sempre più creativi, e quindi è il caso di riaffrontare il tema.
Per molti, i casi d'uso sono diagrammi. Per alcuni, il diagramma dei casi d'uso è _IL_ diagramma UML (Unified Modeling Language). "Conosci UML?" . "Sì, ho fatto dei diagrammi dei casi d'uso".
I casi d'uso, invece, non sono diagrammi, sono descrizioni testuali delle modalità d'uso di un sistema. Come quelle che si possono trovare nei manuali utente scritti bene. I casi d'uso servono a chiarire i requisiti, a definire gli scenari di interazione tra utenti e sistema, e come punto di partenza per la progettazione del software e la definizione dei test.
Certo, c'è anche il diagramma dei casi d'uso. Che è il diagramma UML più povero, in termini semantici e sintattici. Il più semplice tra tutti i diagrammi. Perché vuole essere solo una mappa dei modi in cui il sistema può essere usato, e di quali sistemi esterni sono coinvolti in ogni modalità d'uso. Punto. Il diagramma dei casi d'uso non serve a chiarire requisiti, non serve a definire scenari di interazione, non serve a progettare software e test. È solo una mappa, e per ogni caso d'uso definisce solo il titolo.
Un diagramma povero. Ma anche un povero diagramma. Perché poi, in certe situazioni, viene usato come il cacciavite per piantare chiodi o per tagliare il formaggio, nei modi più creativi possibili. Ad esempio, i seguenti:
La creatività è indubbiamente un valore, e spesso citiamo come un aspetto positivo l'arte di arrangiarsi con ciò che si ha a disposizione. Ad esempio, martellare con un cacciavite può essere utile, quando non si ha un martello.
Per ciascuno degli usi creativi che ho citato, però, esistono in UML altri strumenti, cioè altri diagrammi più adeguati, che funzionano meglio e con i quali ci si fa meno male. Consiglio di dare un'occhiata alle mie linee guida su casi d'uso e modelli architetturali, e magari anche al manuale ufficiale UML. E di non maltrattare troppo i poveri casi d'uso.
*** Il software design come fatto sociale ***
Richard Gabriel è uno dei leader storici della comunità dei software design pattern.
Ha pubblicato da poco uno scritto interessante, Designed as Designer, in cui affronta la tesi romantica della creazione di un design (di un'architettura) come espressione totalmente autonoma di un'individualità. Non è certo il primo a smontare la creatività romantica, ma la sua argomentazione è supportata da esempi illuminanti.
Gabriel evidenzia come ogni design (di un edificio, di una poesia, di un software) sia il frutto di due relazioni:
Il design non è la semplice implementazione nella materia di una creazione già avvenuta nella testa del progettista, ma un graduale e progressivo processo di lavoro in cui le due relazioni (con la materia, e con le opinioni e i prodotti di altre persone) prendono forma.
*** Product Owner ***
Il Product Owner è uno dei ruoli principali di Scrum, uno dei processi agili più diffusi.
In italiano, lo si può tradurre come "proprietario del prodotto", o "responsabile del prodotto".
Dal punto di vista di chi sviluppa software, corrisponde in linea di massima al ruolo di "committente", cioè di chi ha la responsabilità di decidere i requisiti da soddisfare, le priorità di realizzazione, l'accettabilità dei risultati forniti dagli sviluppatori.
Certamente è il ruolo più importante per il successo di un prodotto, di un sistema. Ma è arduo da svolgere, perché non esiste un percorso formativo per diventare Product Owner, e può capitare che il ruolo non sia riconosciuto in termini di autorità e responsabilità all'interno delle organizzazioni.
Sul ruolo di Product Owner, uno scritto interessante di Jeff Patton.
*** 24-Hour Knowledge Factory ***
Tre turni: uno in Africa o Europa, uno in Asia, uno in America.
Tutti lavorano di giorno, alla luce del sole (anche con benefici per la salute, dato che lavorare di notte aumenta i rischi di cancro al seno e alla prostata).
L'articolo è di Amar Gupta, su IEEE Computer di gennaio 2009.
*** Libro su SysML ***
Tim Weilkiens: Systems Engineering with SysML/UML: Modeling, Analysis, Design (The OMG Press) - Morgan Kaufmann 2008
SysML è l'adattamento di UML per la rappresentazione di sistemi complessi, di cui il software costituisce solo una tra le componenti. Come UML, è uno standard OMG.
Il libro è una guida eccellente a SysML. La strutturazione è efficace, con una chiara distinzione tra gli aspetti essenziali e le sottigliezze della notazione, comunque con una trattazione graduale e approfondita di tutti gli aspetti del linguaggio. Ciò rende il testo utile sia per chi non sa nulla che per i progettisti esperti, e in ogni caso molto più chiaro della specifica ufficiale dell'OMG, anche per la qualità degli esempi usati.
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.