Un argomento molto dibattuto in questi mesi è lo sviluppo di software a partire dalla definizione di modelli astratti. Un tentativo di portare il processo di sviluppo software verso un livello più alto eliminando quasi completamente la scrittura di codice e forse la figura del programmatore così come la conosciamo oggi. Questa corrente di pensiero ha portato alla definizione di diverse metodologie tra cui MDSD e MDA.
Parlando di Model Driven Software Development (MDSD) cito Martin Fowler:

Model Driven Software Development (MDSD) is a style of software development that considers itself as an alternative to the traditional style of programming. The approach centers itself on building models of a software system. These models are typically made manifest through diagrammatic design notations – the UML is one option. The idea is that you use these diagrams, to specify your system to a modeling tool and then you generate code in a conventional programming language.

L’idea di fondo è quella di definire un modello software attraverso diagrammi astratti dai quali poter ottenere completamente o parzialmente il codice sorgente tramite tool o sistemi di generazione automatica.
Tale filosofia è condivisa da MDA (Model Driven Architecture) che differisce sostanzialmente da MDSD per il fatto che considera il modello del tutto astratto ed indipendente sia dalla piattaforma di sviluppo che dal linguaggio che si vuole utilizzare.
Per avere un’idea più precisa dello stato dell’arte vi consiglio di dare una occhiata ad iQgen uno dei tool più diffusi attualmente scritto 100% in Java.
Purtroppo questi tool hanno ed impongono ancora parecchi limiti tra i quali:

  • Il tempo dedicato al mantenimento e allo sviluppo dell’architettura e di gran lunga maggiore rispetto al tempo risparmiato con la generazione del codice.
  • I diagrammi che definiscono il modello software, essendo astratti rispetto al codice prodotto, complicano il debugging ed il versioning dell’applicazione.
  • Le modifiche al codice sono possibili, ma devono essere poi riportate nel diagramma con la difficoltà di riconoscere dove intervenire.
  • La necessità di definire dei template di generazione del codice complica notevolmente (se non impedisce) l’utilizzo di codice sorgente esistente come ad esempio framework open source quali Hibernate, Spring, etc.
  • Lo sviluppo rischia di diventare dipendente dal tool di disegno utilizzato per i diagrammi di modello.

In conclusione possiamo tirare un sospiro di sollievo e rimandare per ora il momento in cui i programmi manderanno in pensione il programmatore. 😉