Credo sia capitato a tutti almeno una volta nella vita di trovare gente coi paraocchi. Bene, oggi mi sono imbatutto in persone del genere ma in un posto che non mi sarei mai aspettato: un gruppo utenti linux. Non vorrei che qualcuno si offendesse, quindi non citerò i nomi, e vorrei comunque far sapere che non è un attacco, ma semplicemente una mia considerazione personale.
Il discorso iniziava riguardo al fatto che all’università gran parte dei corsi utilizzano i diagrammi ER (Entity-Relationship) per la progettazione di database relazionali (Access, MySQL, PostgreSQL…), mentre io sono stato abituato dal mio professore ad usare UML.
Non puoi progettare un database relazionale con UML, devi usare ER
Perché mi domando io, ma nessuna risposta diversa da ‘non puoi’… continuo a dire che ci si riesce, lo faccio, e mi paragonano a qualcuno che scrive un OS in Perl….. a parte che non ha significato, Perl richiede un interprete, non ci si può scrivere un OS, continuo a domandare se c’hanno mai provato, e niente.
Ora vorrei chiarificare una cosa innanzitutto: UML è nato come metodo di rappresentazione completo, non legato a nessun linguaggio particolare, né ad alcun uso particolare, ed è validissimo anche per la progettazione di database relazionali, usando il solo class diagram. Ovviamente usare un qualsiasi altro diagramma per un database relazionale perde di significato, ma il class è perfetto, ad esclusione della visibilità dei membri e la presenza delle funzioni. Queste però non sono obbligatorie, quindi non c’è nessunissimo problema a mio avviso.
Anzi giusto per dire quanto può essere valido UML per progettare dei database relazionali, esistono le classi di associazione, che rendono molto semplice gestire dei legami molti a molti con attributi aggiuntivi.
UML è troppo ad alto livello
Non capisco come si possa parlare di basso livello riferito a progettazioni concettuali… certo, ad ognuno il suo, come dicevo precedentemente, non voglio costringere nessuno ad usare UML, ma non voglio neanche che si costringa me, tra l’altro adducendo a motivazioni quali c’è qualcuno che ne sa più di te e ha deciso. Io voglio decidere cosa usare. Ho provato anche ER, e continuo a pensare che in UML venga fuori meglio. Se non posso usare UML voglio delle motivazioni reali! Voglio un maledettissimo motivo per il quale UML manca di qualcosa per cui non può essere usato.
Come sopra il Perl: non può essere usato per scrivere un OS perché è interpretato, non compilato. Per lo stesso motivo tendo a scoraggiare l’uso di Visual Basic: appena si vuole qualcosa di più complicato di una base si finisce col dover usare ocx esterni scritti in C++, quindi manca di qualcosa.
Sarò di coccio, ma penso che bisogna guardare di buon occhio alle novità, anche se ci costringono ad ammettere che parte della nostra vita ad imparare altro è da buttare. Io lo sto forse capendo con PHP e JSP, so che è dura, ma so anche che nella società di oggi non bastano più il diploma o la laurea, bisogna anche essere competenti in ciò che gli studi non possono dare da soli: conosco gente all’università che si ritrova a fare ‘finto’ C++ in cui i boolean non esistono, perché l’insegnante è fermo al C in cui per fare il bool bisognava usare un intero; conosco gente che impara il FORTRAN perché questo insegnano. Ma una ditta, seria, in cui non ci sono problemi relativi a raccomandazioni o gente ‘inamovibile’ per qualsiasi motivo (anche lecito), credo penserà bene, se ha un’applicazione scritta, chessò, in COBOL, se conviene cercare gente competente in COBOL per mantenerla in un formato di 20 anni fa, o cercare gente competente sia in COBOL che in qualche altro linguaggio buono per riprogettarla in modo da avere comunque compatibilità col passato.
Perlomeno, io lo farei.
