I modelli concettuali sono l‘aspetto essenziale dell’analisi orientata all’oggetto

Un principio importante nello sviluppo orientato agli oggetti è la progettazione del software in modo che la sua struttura rifletta quella del problema. Un risultato di questo principio è che i modelli prodotti sia dall’analisi che dalla progettazione finiscono per essere deliberatamente simili.

Queste parole non sono mie, sono state scritte diversi anni fa da Martin Fowler nel suo libro [1]. Spesso la differenza tra modelli di analisi e modelli di progettazione è discutibile. Il designer alle prime armi che proveniente da metodologie strutturate è sgomento perché è abituato a sfruttare notazioni diverse per diverse tipi di modelli (qui con “tipi” intendo fare riferimento alla diversa natura di un modello, ossia modelli di analisi vs modelli di progettazione/implementazione). L’uniformità della notazione è invece uno dei capisaldi del paradigma OO. Di nuovo, Fowler precisa:

“La differenza tra analisi e progettazione esiste ancora, anzi sta diventando sempre più importante. Quando si esegue l’analisi si cerca di capire il problema. Non si tratta solo di elencare i requisiti nei casi d’uso. L’analisi implica guardare oltre i requisiti superficiali per elaborare un modello mentale di ciò che sta accadendo nel mondo del problema.

La vera essenza di ogni modello di analisi è il modello concettuale che realizza il modello mentale che meglio spiega il problema in esame. Cosa significa “migliore”? Ancora da [1]:

La scelta del modello influisce sulla flessibilità e sulla riutilizzabilità del sistema risultante. Costruire troppa flessibilità è pericoloso perché può rendere il sistema troppo complesso da comprendere e gestire; questa è cattiva ingegneria. Per creare un software adatto a uno scopo, devi sviluppare un modello concettuale appropriato alle tue esigenze. E per fare questo hai bisogno del modello più semplice con cui puoi farla franca.

Qui c’è un legame tra la semplicità di un modello e la complessità essenziale insita nello spazio dei problemi [2]. È necessario approfondire il problema del dominio per abbracciare tutti gli aspetti essenziali che possono creare i requisiti del sistema. Se ignori alcuni aspetti di questa complessità essenziale, perdi elementi importanti e il tuo modello concettuale sarà troppo semplice per adattarsi allo scopo. Un suggerimento fornito da Martin è quello di coinvolgere esperti di dominio nella modellazione concettuale. Un esperto di dominio non è uno sviluppatore. È un lavoratore a tempo pieno nel dominio. La conoscenza esperta è essenziale per creare un buon modello di analisi. Mancando questa conoscenza, non avrai un vero modello profondo come il paradigma orientato agli oggetti richiederebbe. Mancando l’esperto di dominio, indaghi fino a un certo punto, descrivendo conoscenza che scricchiola.

Trovo questa attenzione ai modelli concettuali nell’analisi OO un percorso attraverso la progettazione guidata dal dominio. Eric Evans spiega la progettazione basata sul dominio come un approccio per costruire modelli profondi, ovvero modelli che “distillano” la conoscenza dal dominio [3].

L’obiettivo [di un modello profondo] è un design che renda il modello ovvio, un modello che esprima semplicemente il dominio. Un modello profondo distilla gli aspetti più essenziali di un dominio in elementi semplici che possono essere combinati per risolvere i problemi importanti dell’applicazione.

La differenza tra modelli di analisi e modelli di progettazione nel paradigma OO è allora tutta intorno alla presenza di modelli concettuali. L’unico obiettivo del modello di analisi è descrivere un modello profondo (essenziale) che meglio si adatti ai requisiti funzionali; l’obiettivo del modello di progettazione è trasformare il modello di analisi per spingerlo oltre, per adattarlo ai requisiti non funzionali.