Oggi le 3domande sono per Marco di Natale, Professore alla Scuola Superiore S. Anna di Pisa e Senior Member dell'Institute of Electrical and Electronic Engineers (IEEE).
Marco: Sono Professore alla Scuola Superiore S. Anna di Pisa (una istituzione universitaria malgrado il nome "scuola"). Non mi occupo in realtà di elettronica (se non in modo marginale), anche se tanti anni fa ho conseguito la Laurea in Ingegneria Elettronica, ma di software per embedded, sopratutto di modelli e architetture software. In aggiunta, non ho neanche una mission (un uomo di pochi principi?), ma ho bisogno di trovare una attività che sia allo stesso tempo originale e creativa (e qui la ricerca offre opportunità) e che mi consenta anche di arrivare alla fine della giornata e sentire che quello che ho fatto ha avuto un impatto sui sistemi e le persone del mondo reale. Da qui, la ricerca di collaborazioni con l'industria e l'interesse per la didattica.
Se al posto di "mission" (parola che non mi entusiasma) parliamo di quelli che sento essere i bisogni più impellenti per il mondo dei sistemi (software) embedded, allora è molto semplice, bisogna riportare lo sviluppo del software ad essere scienza ed ingegneria e rimuovere il mito che la programmazione sia un "arte" (semplicemente non ci sono abbastanza "artisti" in giro).
Questa affermazione è molto meno condivisa di quanto si potrebbe pensare. La conseguenza immediata è che lo sviluppatore debba essere "confinato" per quanto possibile nell'uso di linguaggi e metodi ed accettare che l'arricchimento e la qualità professionale non significhino (necessariamente) scrivere le venti righe di codice più belle (o furbe) del mondo, ma saper spaziare come competenze dallo sviluppo di codice, alle architetture, alle equazioni che regolano i sistemi di controllo, ai metodi formali di verifica. Il messaggio sembra molto poco liberale ed è difficile da digerire.
La buona notizia è che la domanda di soluzioni embedded "migliori" e di metodi per aumentare la produttività e la correttezza dei sistemi software è in continua crescita. Che la mia analisi sia giusta o sbagliata, almeno ho la certezza che ha luogo in un contesto in cui vale decisamente la pena essere.
Marco: Nessun problema di rovinare la sorpresa (non è un thriller). Inoltre, anche se so di deludere molti, l'accento è su Model-based design piuttosto che su Open Source. L'uso di modelli può portare rigore, metodo e possibilità di verifica nello sviluppo di software embedded. Se poi le tecnologie Open Source riescono ad abbassare la soglia di accesso a linguaggi, metodi e strumenti di modellazione e verifica, allora tanto di guadagnato (e ci sono ottime opportunità a riguardo, sopratutto --ma non solo-- dall'ambiente Eclipse EMF).
Nel mondo accademico è ora di moda la buzzword CPS (Cyber-Physical Systems). Se il termine CPS ha un merito sicuro, è quello di ricordare agli sviluppatori embedded che l'hardware e il software interagiscono con il mondo fisico. Da ingegneri o scienziati, interagire non può che significare cercare di prevedere i risultati di questa interazione, sviluppando modelli della parte hardware e software così come dei sistemi fisici controllati e cercando di valutare gli effetti di questa interazione mediante simulazioni o metodi formali.
Marco: Non ho minimamente le credenziali per affrontare il discorso come merita nei suoi mille aspetti (organizzativi, legali, commerciali e tecnici). Per quel che può valere fornisco i miei 5 centesimi sull'argomento. Di natura sono pragmatico e non riesco a parlare di "spirito" Open. Anzi, credo che chiunque si faccia illusioni ideologiche a riguardo abbia la certezza di uscirne deluso. Cosa significa "tutelare coloro che aderiscono ai principi Open"? Sono sicuro che il concetto di "tutela" differisca (e di molto) tra gli stessi entusiasti del principio di fornire soluzioni Open. Lo stesso dicasi per "sostentamento" e "riconoscimento" (o paternità). La paternità di un progetto di successo è quasi invariabilmente destinata a essere diffusa e difficile da identificare. Open Source raramente significa un sistema perfettamente democratico, collaborativo, aperto e solidale (sarebbe ora di sfatare il mito della startup che origina in un garage...). I progetti di cui mi interesso (e a cui di fatto contribuisco solo in modo marginale) hanno avuto una origine tutt'altro che Open o liberamente collaborativa (Eclipse nasce da un consorzio di Ericsson, HP, IBM, Intel e altri ...) o hanno dato luogo a faide di "riconoscimento" e "proprietà" e la prevedibile "balcanizzazione" del progetto (l'ambiente Scicos) o sono molto poco collaborativi (l'ambiente Papyrus). Ciononostante, possono essere molto utili per costruire soluzioni.
Parafrasando, un progetto Open nasce e poi va in giro con le sue gambe, spesso senza alcun riguardo per i suoi "genitori". Nessuno è tenuto a regalare nulla, se è forte sopravvive, altrimenti languisce o muore. E qui mi fermo, ci sarebbe molto da dire a riguardo, ma in poche righe avrei la quasi certezza di essere frainteso o banalizzare e dire sciocchezze.
L’IEEE si riconferma pieno di menti davvero strabilianti.
Un confronto illuminante.
Finalmente posso sbizzarrirmi in un bel commento corposo…nel mio campo! =)
Innanzitutto vorrei fare qualche considerazione a riguardo dei due argomenti (forse disconnessi?) affrontati da Marco di Natale:
1) per quanto riguarda lo sviluppo model-based, attualmente la ricerca ancora è poco matura per proporre metodologie stabili e standardizzate che possano “convincere” le aziende che l’approccio possa essere fruttuoso (a livello di costo e marketing della compagnia). I motivi sono molti:
– la model-driven engineering, e in particolar modo il model-to-code ha vari problemi, tra cui: a che livello di dettaglio vanno prodotti i modelli per la generazione di codice efficiente? Che tipo di linguaggio permette una migliore generazione (general-purpose come UML oppure domain-specific)? Un esempio lampante di vantaggio in termini di costi e di produzione è rappresentato dal progetto IFML che attualmente (dopo dieci anni di lavoro!!!!) è stato standardizzato dalla OMG. Provate a farvi un giro sul sito http://www.acer.it e ditemi cosa ne pensate.. quello che vedete è codice generato automaticamente da modelli, sviluppati con il linguaggio IFML, e il costo della produzione del sito è stato 3 volte minore di quello prodotto con la programmazione tradizionale! Ma purtroppo il processo di standardizzazione di queste nuove tecnologie di sviluppo va a rilento, ed è ancora relativamente immaturo… (si pensi che la MDE ha preso piede solo dal 2002 circa…). Sono ancora poche, di conseguenza, le aziende che vogliono affidarsi ad un approccio model-based per la produzione dei loro software. In generale, attualmente, questo tipo di sviluppo viene principalmente usato per applicazioni lato web, o per lo sviluppo di interfacce grafiche. Inoltre alcuni tipi di sistemi è difficile immaginare possano essere sviluppati in questo modo, quindi si continua a prediligere gli approcci tradizionali di programmazione (si pensi ai safety-critical systems, come gli avionici sviluppati da SAAB, che richiedono procedure lunghissime per l’apposizione della certificazione delle autorità competenti..). Quindi è ancora troppo immatura l’ottica per poter applicare questa metodologia a tutti i tipi di software… Anche se, negli ultimi anni, sono stati proposti sviluppi MDE applicati a Multi Mobile-Robot Systems.
– un altro problema da superare è il costo di training perché purtroppo, almeno in Italia, l’università forma poco riguardo questa branca della software engineering, a volte non forma affatto…continuando ad inculcare metodologie di programmazione tradizionali ( a oggetti o, addirittura, procedurale). Tutto questo porta ad un allontanamento dell’informatico verso la MDE, che invece è una materia che richiede alta astrazione e ingegno.
Riguardo l’Open Source? Marco ha ragione sicuramente nel dire che esiste una sorta di “deep web” dietro la bella faccia dell’Open, perché, diciamocelo chiaramente, chi accetterebbe di lavorare gratuitamente sempre? Senza alcun riconoscimento? Certamente è improponibile richiedere una “legge” che tuteli l’Open, perché ciò va contro il principio stesso dell’Open, ovvero: condividere e migliorare, senza alcun scopo di lucro. Se, quindi, non si ha alcun scopo di lucro, e si decide di regalare la propria idea alla comunità, perché mai si dovrebbe richiedere un riconoscimento per la propria opera? Nonostante tutto, la condivisione della conoscenza è sempre il primo passo per il miglioramento e per l’evoluzione. Ma quando qualcuno decide di CONDIVIDERE la propria idea senza nulla in cambio, egli stesso, intrinsecamente, accetta che quell’idea diventi di comune proprietà, e di conseguenza non necessita di tutela alcuna.