analisi-disegno.com
Il software è fatto di astrazioni. Ogni mattoncino (modulo, classe) di un'applicazione software è un'astrazione che svolge una o più funzioni, tratta delle variabili, ha un ruolo e delle responsabilità. Quali astrazioni scegliere? Come definirle in modo adeguato per il sistema che si vuole realizzare?
Bisogna partire dall'analisi del dominio applicativo. Cioè dalla definizione dei concetti rilevanti per il nostro sistema. Se siamo nell'ambito della telefonia, saranno ad esempio concetti come "chiamata", "apparecchio chiamante", "apparecchio ricevente", "piano tariffario"; in banca, concetti come "conto corrente", "movimento", "bonifico".
Individuati i concetti, bisogna poi esaminarli per definirne le proprietà caratteristiche, le relazioni che li collegano, il ruolo che dovranno svolgere nelle funzionalità del sistema.
Per questo esame, servono due cose: la prima è la padronanza della materia trattata, del dominio. Dominio, dal latino "dominium", che significa proprio padronanza, è la sfera delle conoscenze che riguardano una materia specifica, necessaria per chi vuole operare efficacemente in tale ambito. La conoscenza del dominio della materia è propria di chi ha studiato ed ha esperienza in quel settore specifico. Chi fa analisi la può acquisire solo attraverso il dialogo con gli stakeholder (committente, utenti, altre parti in causa), che porta a chiarire i requisiti del sistema.
L'altro elemento necessario è la padronanza della tecnica di analisi, che è invece indipendente dalla materia specifica e può quindi essere applicata in ogni ambito di dominio. La tecnica tradizionale per la modellazione dei concetti è l'Entity-Relationship (ER), ideata nel 1976 da Peter Chen per la progettazione degli schemi dati a livello concettuale, che continua ad essere anche oggi una tecnica fondamentale e molto usata.
A seguito dell'affermarsi dell'approccio object oriented, per la modellazione dei concetti di dominio è anche comune l'uso del diagramma delle classi, che nella notazione UML dimostra una diretta derivazione dall'ER. L'uso del diagramma delle classi per modellare i concetti del dominio è sostanzialmente affine a quello svolto tradizionalmente con l'ER, anche se può comprendere una definizione iniziale delle responsabilità che le singole classi assumeranno nell'ambito del sistema.
*** Architettura e agile ***
Un numero di IEEE Software, March/April 2010, con articoli incentrati sul rapporto tra "agilità" e architettura.
Rilevante un testo di Roland Faber, "Architect as Service Providers", secondo cui gli architetti software devono assumere la responsabilità di soddisfare i requisiti non funzionali, mentre ai progettisti / sviluppatori compete quella di soddisfare i requisiti funzionali.
*** Giochi per la formazione IT ***
L'uso dei giochi per la formazione IT sta crescendo: "Puzzle-Based learning for Engineering and Computer Science", su IEEE Computer, April 2010. (In inglese, i puzzle non sono solo i giochi in cui si incastrano le tesserine, ma anche tutti i giochi logici, linguistici, enigmistici, matematici.)
*** Ostacoli all'agilità ***
Articolo breve e succoso di Johanna Rothman: "Barriers to Agility". Argomenti:
"Se non avete la possibilità di creare un piccolo gruppo di lavoro multifunzionale, che lavori su un unico progetto, non avete l'ambiente organizzativo giusto per iniziare a operare in modo agile."
L'articolo è apparso su PragPub, una rivista online mensile pubblicata dai Pragmatic Programmers.
*** Nuove versioni di UML e SysML ***
Revisioni minori, nulla di sostanziale:
*** Tecno austerità ***
"Meno è meglio".
"I tecnologi si stanno risvegliando ai vantaggi del minimalismo, per due motivi: il fastidio per l'eccessivo numero di funzionalità dei prodotti da parte dei clienti che vogliono solo che le cose funzionino, e una forte richiesta da parte di clienti meno ricchi provenienti dai paesi in via di sviluppo."
The Economist, 12 giugno 2010.
*** 10 regole per prodotti di successo ***
Video di un intervento di Donald Norman alla conferenza Better Software 2009.
Norman è uno tra i massimi esperti di usabilità, famoso soprattutto per il libro "The Design of Everyday Things", tradotto e pubblicato da Giunti con il triste titolo all'italiana "La caffettiera del masochista. Psicopatologia degli oggetti quotidiani".
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita e regolare.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.