Analisi, cioè scomposizione

Il termine analisi viene dal greco antico. “Ana” è ciò che sta sopra.
“Lisi” è lo scioglimento, la scomposizione. La scomposizione di ciò che
sta sopra.

“Ciò che sta sopra” è il problema da risolvere, oppure l’oggetto da
esaminare. Considerato, in partenza, nella sua globalità, come un
tutt’uno. Una scatola nera.

Compito dell’analisi è capire le caratteristiche dell’oggetto esaminato,
trasformarlo da opaco (la scatola nera) in trasparente, rivelando gli
elementi da cui è composto. Ad esempio, se esaminiamo un processo,
individuando le attività che lo costituiscono. Se esaminiamo un sistema,
individuandone le parti. Scomponendo.

L’analisi scompone il proprio oggetto in elementi più semplici. E se gli
elementi individuati sono ancora troppo complessi, troppo a “grana
grossa”, si può analizzarli a loro volta, scomponendoli, fino a
individuare elementi a “grana fine”, semplici quanto basta. Un sistema
viene scomposto in sottosistemi, un sottosistema in componenti, un
componente in moduli, e così via, fino al punto in cui riteniamo che non
valga la pena di scomporre ulteriormente.

Quando usiamo la lingua inglese, chiamiamo questo procedimento
“top-down”. Di nuovo, come in greco antico, “scomposizione di ciò che è
sopra”.

Ma come bisogna scomporre? O meglio, esiste un modo giusto, corretto,
per effettuare la scomposizione (l’analisi)? Un unico modo?

No. Ogni oggetto da analizzare può, anzi deve essere esaminato da
diversi punti di vista. Secondo diverse tecniche.

Ad esempio, in linguistica, una frase può essere sottoposta ad analisi
grammaticale, analisi logica, analisi del periodo.

Analizzando una specifica dei requisiti per la progettazione di un
sistema, possiamo valutare il livello di coerenza, di completezza, di
precisione, eventuali aree di ambiguità.

Nelle architetture software, l’analisi può affrontare gli aspetti
strutturali (la strutturazione del sistema in parti), gli aspetti
dinamici (come le parti interagiscono tra loro), le dimensioni di
qualità (ad esempio gli aspetti di sicurezza, di prestazioni, di
affidabilità, di usabilità).

Gli approcci più maturi e più utili a disposizione degli architetti
software, come quello delle viste architetturali “4+1” di Philippe
Krutchen, e quello del gruppo di “Documenting Software Architectures”
del Software Engineering Institute, evidenziano che l’analisi di sistemi
complessi – come quelli software – va affrontata da diversi punti di
vista, non da uno soltanto.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *