Il termine tecnica viene dal greco, dove téchne significa arte. Le tecniche costituiscono dei “ferri del mestiere”, che si possono apprendere a livello teorico oppure con l’esperienza. Meglio, se possibile, sia in teoria che in pratica.
Le tecniche di analisi e progettazione software servono a farsi delle domande, utili per affrontare un problema e avvicinarsi alla soluzione.
Entity-Relationship
La tecnica Entity-Relationship, ideata per la modellazione dati, verte su alcune domande fondamentali:
- quali sono i concetti principali del dominio applicativo (del problema) che stiamo affrontando? (in linguaggio tecnico: quali entità, quali attributi?)
- come sono legati tra loro questi concetti? (in linguaggio tecnico: quali relazioni?)
Queste domande, che lo sviluppatore (o l’analista, se si tratta di una figura distinta) si pone di fronte ad un problema che conosce poco, possono essere indirizzate agli esperti (committenti, utenti) per chiarire i requisiti. Ciò può avvenire in qualsiasi ambito applicativo, in qualsiasi dominio, dalle telecomunicazioni al militare al creditizio. Le domande possono costituire il punto di partenza per la definizione del modello di dominio, che costituirà l’ossatura del sistema.
Analisi strutturata
La tecnica di analisi strutturata, caratterizzata dall’utilizzo di diagrammi quali i Data Flow Diagram o SADT, è oggi meno utilizzata di un tempo. Ma le domande fondamentali su cui verte restano assolutamente necessarie e vitali:
- quali sono i confini del sistema? cosa è compreso, cosa è escluso? con quali sistemi esterni interagisce? (in linguaggio tecnico: qual è il contesto?)
- dato un processo (o un sistema) complesso, quali sono le sue parti costitutive? come sono collegate tra loro? (in linguaggio tecnico: come si scompone?)
Si tratta di domande diverse rispetto a quelle dell’Entity-Relationship.
Ma sono anche queste applicabili in ogni ambito applicativo, ed è utile che lo sviluppatore (o l’analista) se le ponga, nell’affrontare un nuovo problema. E le indirizzi ai suoi interlocutori per chiarire i requisiti.
Casi d’uso
Anche i casi d’uso, in quanto tecnica di analisi, sono basati su alcune domande
fondamentali:
- chi deve usare o interagire con il sistema? (in linguaggio tecnico: quali sono gli attori?)
- che cosa ci deve fare? (in linguaggio tecnico: quali sono i casi d’uso)
Di nuovo, si tratta di domande diverse rispetto a quelle delle tecniche citate in precedenza. Anche queste, però, applicabili in modo generalizzato, ed utili per chiarire i requisiti e come punto di partenza per la progettazione del sistema.
Analisi e progettazione
Object Oriented
L’analisi e la progettazione object oriented recuperano e inglobano concetti tipici degli approcci precedenti, in particolare di quello strutturato. Aggiungono però alcune nuove domande fondamentali per la progettazione del sistema:
- quali responsabilità vanno assegnate alle diverse parti del sistema?
- come devono collaborare le parti? qual è il modo migliore per collegarle tra loro?
- come posso renderle il più possibile stabili?
Conoscere le tecniche significa avere a disposizione dei ferri del mestiere, per usarli quando ci servono. Nello sviluppo software, significa acquisire la capacità di porsi le domande necessarie per chiarire i requisiti, e per progettare il sistema.
Le diverse tecniche di analisi e progettazione sono complementari: non si sostituiscono l’una all’altra.
Ogni nuova tecnica che entra a far parte del nostro bagaglio professionale lo arricchisce,
e ci dà la possibilità di affrontare i problemi in un modo efficace. In alcune situazioni, la nuova tecnica risulterà particolarmente adatta. In altre situazioni invece sarà meno utile, e risulteranno più adatte altre tecniche.
La formazione sulle tecniche di analisi
Il mio sito di formazione sulle tecniche di analisi, con corsi in auto-istruzione, workshop di pratica guidata e corsi completi di teoria + pratica.