Generazione model-driven di interfacce utente per dispositivi mobili

Indagine sul prototipo
L’obiettivo della fase iniziale dedicata alla realizzazione del generatore è stato un’indagine molto accurata dell’applicazione prototipo. Nonostante fosse un sistema sul quale ho lavorato in modo fisso per gran parte del tempo passato in azienda e su cui quindi ero molto ferrato, tale attività è stata necessaria e fondamentale per la realizzazione del generatore. L’obiettivo è stato identificare per ogni file scritto quali erano i rapporti che esso aveva con il modello.

Da questa analisi sono emerse delle scelte risultate sbagliate, cioè era stato utilizzato un approccio che non sarebbe andato bene nel caso in cui fosse stato fornito un modello con delle particolari caratteristiche. Un esempio è stato il naming dei componenti relativi alle classi part, essi in un primo momento si basavano sul nome della classe, ma esistendo la possibilità di avere una classe main con più composizioni verso la stessa classe part non ci sarebbe stato modo di distinguerle, è stato quindi utilizzato il nome del ruolo della composizione per discriminare i due casi.

Tale fase ha avuto quindi ripercussioni sulla modifica del prototipo, modifiche relative soltanto al naming di elementi e non alla logica implementata. Per ogni relazione presente con il modello è stata aggiunta una annotazione in cui venivano specificate la parte che variava, l’oggetto del modello da cui prendeva il nome e la caratteristica del modello a cui era dovuta la sua presenza.

Struttura
Il RESTClientProtoBuilder, chiamato da ora in poi generatore, si basa fortemente sull’utilizzo dei template, tecnica introdotta nel paragrafo dedicato agli Strumenti di Sviluppo. Il template engine utilizzato è Apache Velocity, ma si è cercato di non rendere fortemente accoppiata questa tecnologia con il sistema, in modo da permettere successivamente, qualora vi fosse la necessità, una facile migrazione verso l’utilizzo di un diverso motore.

La fase di generazione inizia quando al ProtoBuilder viene richiesto il building dell’applicazione client fornendogli il modello. Il componente provvede ad iterare sulle applicazioni esistenti al suo interno, per ognuna di esse prosegue scandendo le classi da esse gestite e, allo stesso modo, indaga queste ultime riguardo le composizioni. Ad ognuno dei livelli scanditi innesca il processo per generare uno o più file, per ognuno dei quali si fa restituire dal PathMaker la destinazione dove andrà generato. Assieme alla destinazione, passa al corrispondente Coder responsabile di creare il file, gli elementi del modello contenenti le informazioni di cui ha bisogno. Il Coder estrapola le informazioni di interesse e le inserisce in un oggetto contesto dopodiché effettua l’operazione di merge tra questo e il template da lui gestito. Il risultato viene passato ad un oggetto Writer che crea il file nella cartella corrispondente.