Il dominio dei database

by Giuseppe Lanzi on 13 aprile 2012

Qualche giorno fa ho letto un articolo dal titolo particolare: “Tutto quello che usi è un’applicazione basata su database”.

Non ci avevo mai pensato in questi termini, ma in effetti praticamente tutte le applicazioni che usiamo online si basano sull’uso di database. La coppia applicazione-database è qualcosa che ormai diamo per scontato.

Quel che mi ha fatto decidere di condividere con voi l’articolo è un’affermazione fatta verso la fine del testo, quando parlando di applicazioni web si legge: “la predominanza del database ha limitato il nostro modo di pensare nuovi prodotti: ci preoccupiamo di creare applicazioni che leggono e scrivono dati, piuttosto che applicazioni che ci mettono in contatto in tempo reale”.

Uno spunto di riflessione interessante e niente affatto scontato. Quante volte ci è capitato di vedere, o magari di realizzare, applicazioni la cui interazione con l’utente è stata dettata dalla struttura del database? Mentre invece l’interfaccia applicativa dovrebbe essere disegnata in base al processo, e non modellata sulla struttura dei dati.

E voi? Cosa pensate che debba guidare il progetto di una buona applicazione?

{ 8 comments… read them below or add one }

1 Matteo 13 aprile 2012 alle 18:13

Condivido, anche se bisogna convertirsi ad un nuovo modo di pensare, e forse questo è quello più difficile.

Vi suggerisco questo video
http://vimeo.com/31739391

2 Giuseppe 13 aprile 2012 alle 18:25

Quello che scrivi è proprio vero!
In questi ultimi anni stiamo facendo un grosso sforzo per superare i limiti di qualità delle applicazioni che sviluppiamo conseguenti all’utilizzo del paradigma database driven.

Un modo che troviamo efficace è quello di partire progettando le interfacce utente e solo dopo il DB.
In questo percorso evolutivo INDE (che propone decisamente il paradigma database driven) non è che aiuti molto …

Noi prototipizziamo le interfacce con Balsamiq Mockups, ve lo consiglio.

3 Giuseppe Lanzi 13 aprile 2012 alle 18:58

In.de propone un approccio dal database per vari motivi, tra cui la sua stessa storia e la maggior familiarità con il paradigma. Ma non è l’unico disponibile.
Un annetto fa ho aiutato un cliente a seguire un metodo simile al vostro tramite Document Orientation.

In pratica abbiamo disegnato prima le classi documentali e le schermate (abbozzando anche la presenza di procedure e funzioni), per poi modellare e collegare la struttura del database in una seconda fase.

Non voglio dire che con In.de si fa tutto, non abbiamo la pretesa di risolvere ogni possibile circostanza, ma credo che più che l’approccio dello strumento, si debba lavorare sull’approccio del programmatore. Come state facendo voi.

4 Andrea Maioli 14 aprile 2012 alle 10:37

Io credo che l’analisi dei processi e la relativa modellizzazione, anche a livello di usabilità, siano parte del processo creativo dei professionisti dell’informatica. Forse la parte migliore, che non mi ha mai stancato.

Usando Instant Developer, che mi aiuta ad essere veloce e sicuro nella parte realizzativa, a me succede di avere tanto tempo in più per pensare meglio a come fare un’applicazione semplice da usare. E poi se voglio cambiare idea e provare in modo diverso, cambiare le cose con In.de è semplice e veloce.

Concordo con Giuseppe col fatto che In.de non impone un modello database-driven. Certo che con gli automatismi che ha si fa molto presto, ma se poi non si va oltre agli automatismi, quando invece si dovrebbe, è forse un problema di pigrizia.

5 Mauro Marini 17 aprile 2012 alle 02:09

Lo spunto di Giuseppe è molto stimolante: “cosa guida il progetto di una buona applicazione? “. La mia risposta: una buona analisi.
Negli ultimi anni, dall’esplosione del web tanto per capirci, ho notato un calo di interesse verso l’informatica come scienza. Un effetto collaterale è la progressiva estinzione degli analisti.
Il video suggerito da Matteo è indicativo. Il relatore è bravo e sa tenere viva la platea, però utilizza mezz’ora per spiegare un concetto banale: se sbagli il modello concettuale avrai un impatto severo su quello logico. Nella seconda mezz’ora non aiuta molto a capire le differenze aggregato e composto, caso d’uso, flusso e transizione di stato, modellazione concettuale, logica e fisica.
Un paio di temi importanti li ha sfiorati. Ad esempio, è stata citata l’invarianza per trasformazioni. E’ un principio che si usa in matematica e fisica da secoli. Einstein ci ha costruito la relatività ristretta (l’invariante è la velocità della luce e le trasformazioni sono quelle di Lorenz). Non c’è che dire: è una buona guida. Peccato gli ha dedicato solo 20 secondi.
Non è però colpa del relatore. Lui espone nel modo più accattivante possibile il verbo di uno dei tanti guru delle metodologie “pragmatiche” ed essere pragmatici aiuta a stare con i piedi per terra. Mi pare però che sull’altare del pragmatismo sia andato bruciato anche l’ultimo secolo di teoria della modellazione concettuale. Il messaggio somiglia, infatti, a quello del personaggio guzzantiano che diceva: “C’è molta crisi. Se ti chiedi: ‘come mai? dove stiamo andando? ‘ la risposta è dentro di te,però è… sbagliata!”.
Tornando al tema “cosa guida la progettazione” non penso si possa trovare un percorso lineare che vada bene per ogni caso. Per i casi più complessi, adotto uno schema che mi guida nei vari aspetti della modellazione: il framework di Zackman. Trattandosi di una matrice, si può iniziare da dove si vuole e completandola si indagano un po’ tutti gli aspetti del problema e della soluzione. E’ un modo come tanti altri, ma almeno non trascura la modellazione motivazionale (il perché di un requisito).
Per casi più semplici, invece, vado in parallelo tra modello concettuale, e prototipazione dell’interfaccia – il vero “modello” che vede il cliente. Molto difficilmente il modello del DB mi condiziona e rifattorizzo senza pietà.
Giuseppe però parte da una domanda più profonda: i database (relazionali) si meritano la diffusione che hanno? Penso di sì e le ragioni sono almeno due:
1) Un ampio spettro di applicazione. Quasi tutte le soluzioni richiedono una memoria a lungo termine e i DBMS sanno fare bene questo mestiere.
2) L’algebra e il calcolo relazionali. Questa è una ragione spesso sottovalutata. L’SQL, a differenza di molti altri paradigmi di programmazione , ha un fondamento matematico solido e completo. Ripenso ad un punto del video sopra citato, nel quale si mostrano dei cardinali in riunione, per rappresentare un sistema con regole troppo rigide. La chiesa sarà pure un sistema rigido, ma sono 2000 anni che funziona!
InDe presenta simili caratteristiche: generalità e un modello “forte” (la programmazione relazionale). Chissà che versione ci sarà tra duemila anni? ;)

6 Andrea Maioli 17 aprile 2012 alle 07:27

@mauro: grazie del contributo. Mi colpiscono due cose:

1) L’estinzione degli analisti: non so se è davvero come dici tu. Però anch’io noto una progressiva mancanza di studio e di analisi prima di partire con i progetti. L’idea è: intanto buttiamo su qualcosa che funzioni, poi vediamo… Quando chiedo: “ma non possiamo prima parlare con gli analisti?”, essi sono sempre troppo impegnati in qualcosa d’altro di più importante. Forse troppo “pragmatismo” fa male!

2) Io non ho nulla contro i database relazionali; anzi per me sono uno dei pilastri che ha più contribuito all’infomatica negli ultimi 20 anni. Però le strutture dati rappresentano un’immagine statica dell’applicazione e non sono quindi sufficienti a descriverla completamente. Occorrerebbe aggiungere (non sostituire) anche il modello dinamico del sistema e quindi l’analisi del processo. Altrimenti l’applicazione viene sbilanciata sulla parte statica e non supporta l’utente secondo il modo con cui lui deve usare tali dati. Secondo me questa seconda parte di analisi non è così tanto presente.

Forse i principi base dell’UML non erano poi così male. Saltarli tutti a piedi pari può risultare in un approccio non lungimirante.

7 Teo 18 aprile 2012 alle 09:01

Bellissimo articolo, e ottime considerazione.
Condivido in pieno.
E’ ora di finirla di pensare alle applicazioni partendo dal database (e ve lo dice un ex dba).
Bisogna prima pensare al processo e all’interfaccia utente e credo che lo sviluppo di applicazioni mobile ci aiuta a cambiare modo di ragionare.

8 Andrea 18 aprile 2012 alle 17:14

I database hanno un proprietà molto interessante, non necessitano di strutture dati particolari per garantire le relazioni tra oggetti del dominio applicativo, che pertanto si prestano a potere essere “visti” in maniera diversa sfruttando appunto le “viste”.

Il paradigma relazionale è matematicamente valido ed ha la sua ragion d’essere inoltre si presta all’indicizzazione, e lo fa automaticamente.

Se si lavora con grandi moli di dati non si può prescindere dal DB ed anche i progetti OOP ne devono tenere conto se vogliono avere prestazioni degne.

La magia nera sta nel tenere ben separato accesso dati e logica applicativa, molti progetti non hanno requirement particolari quindi tanto vale lavorare direttamente sulla base dati con tool tipo INDE o altri.

Dipende dal tipo di progetto.

Leave a Comment

Previous post:

Next post: