Acquisizione del sorgente e filtraggio delle informazioni

Per quanto riguarda i requisiti del primo punto, questi sono soddisfatti per mezzo della classe Main.java(fig. 4.2) definita. Questa, rappresentante

l’entry point del transpiler (esportato come file .jar), consente all’utente

l’utilizzo di Snap2ino tramite terminale (ed eventualmente l’integrazione in altri sistemi), accettando come argomento il file .xml rappresentante il Mi-

cromondo della Matrice esportato e da convertire. A partire dal file passato, una volta verificato che il formato sia quello atteso (.xml), vengono eliminate

le informazioni (i tag xml) superflue e non previste/gestite dalla grammati- ca, in modo da ottenere un contenuto conforme alla sintassi del DSL atteso. Tale operazione avviene mediante l’uso delle RegEx (Regular Expressions), attraverso le quali poter rimuovere il contenuto testuale compreso: dall’ini- zio del documento al tag <variables>, dalla chiusura del tag </variables>

alla definizione del primo script (<script>) e, infine, dalla chiusura di tale

tag (</script>) alla fine del documento. Oltre a queste, vengono rimosse

anche eventuali altre informazioni (attributi) superflue rimanenti a seguito della prima fase di filtraggio. Il risultato che si ottiene è un contenuto te- stuale costituito dalle sole sezioni descritte in precedenza (4.2.2) e conformi al DSL Snap2ino. A partire da tale contenuto è poi generato il relativo file in formato .snap2ino, utile sia per l’analisi dell’organizzazione del micro-

4.3. PROGETTAZIONE 77

mondo passato, sia come punto di partenza per la successive fasi di: lettura, comprensione, conversione e generazione dell’output.

4.3.3 Lettura e comprensione delle informazioni filtrate

Una volta generato, a partire dal Micromondo della Matrice esportato, il file.snap2ino, conforme all’organizzazione descritta in fase di analisi dell’in-

put (4.2.2), per poterlo convertire in uno sketch Wiring è prima necessario riuscire a leggerlo e capirlo. Come in precedenza accennato, per poter fa- re ciò si è ricorso alla definizione di un’apposito Domain-Specific Language (Snap2ino), per mezzo del framework Xtext, rappresentante il linguaggio composto dalle informazioni filtrate. In particolare, grazie al supporto offer- to da Xtext (generazione automatica delle classi Java rappresentanti i nodi dell’AST, delle regole per la creazione di questo, del lexer e del parser ) si è reso necessario definire esclusivamente la grammatica per questo DSL. A partire da questa, e dal metamodello EMF da essa inferito, è poi possibile ispezionare la rappresentazione in memoria dei sorgenti .snap2inoin modo

da generare, nell’ultima fase, le controparti C/C++ dei i vari costrutti in essi definiti.

Definizione della grammatica

Avendo come riferimento l’organizzazione dei tag xml definita durante la fase di analisi dell’input (fig. 4.1), si è proceduto alla realizzazione della grammatica necessaria (fig. 4.2, Snap2ino.xtext), attraverso il DSL Xtext,

in maniera incrementale e aggiungendo, man mano, costrutti in grado di rendere il metamodello EMF (fig. 4.2, modello Snap2ino.ecore), inferibile

dalle regole definite, sempre più simile al modello UML per l’organizzaizone dei tag significativi realizzato durante la fase di analisi. In particolare, si è partiti dalla definizione di una semplice grammatica, composta dalla sola sezione delle variabili, di tipo intero, e dallo script, composto da blocchi base e blocchi custom senza argomenti. Successivamente è stato esteso il supporto al tipo delle variabili, definendo ConstValue (rappresentante valori costanti, ossia interi e float, con e senza segno, e stringhe - considerandoli come se- quenze alfanumeriche XmlString) e BoolValue, e integrato il supporto agli argomenti in input per i blocchi (partendo dagli appena definiti ConstValue e BoolValue, includendo poi anche valori Option, altri blocchi e, infine, gli Script).

Una volta raggiunto il grado di similarità cercato, tra il metamodello EMF inferito e il modello dei tag significativi, la grammatica completa per il primo prototipo risulta essere la seguente:

XMLModel: variables = Variables script = Script ; Variables: {Variables} ’<variables>’ variables += Variable* ’</variables>’ ; Variable:

’<variable’ ’name=’ name = STRING ’>’ innerContent = Literal ’</variable>’ ; Script: {Script} ’<script>’ blocks += Block* ’</script>’ ; Block:

VariableBlock | BasicBlock | CustomBlock ;

VariableBlock:

’<block’ ’var=’ variable = STRING ’>’’</block>’ ;

BasicBlock:

’<block’ ’s=’ name = STRING ’>’ args += (Argument)*

’</block>’ ;

CustomBlock:

’<custom-block’ ’s=’ name = STRING ’>’ args += (Argument)*

’</custom-block>’ ;

Argument:

Script | Block | Option | Literal ;

Option: ’<l>’

4.3. PROGETTAZIONE 79

’<option>’ value = XmlString’</option>’ ’</l>’ ; Literal: BoolValue | ConstValue ; BoolValue: {BoolValue} ’<l>’? ((value ?= ’<bool>true</bool>’) | ’<bool>false</bool>’) ’</l>’? ;

// Includes strings (i.e. chars sequence without double quotes) // and signed integers/floating point numbers.

ConstValue: ’<l>’ value = XmlString ’</l>’ ; XmlString: ID XmlString? ; /*

* Custom ID defined to include both signed integer and signed * floating values.

* NB: < and > symbols are excluded due to avoid ambiguity * with the xml syntax.

*/

@Override terminal ID:

( ’\\’ . | !(’\\’|’"’|’\’’|’ ’|’\t’|’\r’|’\n’|’<’|’>’) )+ ;

Le due principali differenze evidenziabili rispetto al modello definito in fase di analisi riguardano essenzialmente:

• l’inclusione del tag<l></l>direttamente nel costrutto Option e Literal,

eliminando quindi le classi L e Value;

• il collasso della classe ParametricBlock nei rispettivi BasicBlock e Cu- stomBlock.

Inoltre si evidenzia come, analogamente al modello definito per i tag xml (fig. 4.1), anche la grammatica realizzata non prenda in considerazione gli specifici blocchi forniti dal linguaggio Snap!, o il numero/tipo degli argo- menti che questi possono, o meno, richiedere. Infatti, si è voluto rendere la

grammatica la più generica possibile per avere, da una parte, una definizione della stessa più semplice e concisa, dall’altra, una maggiore flessibilità circa la gestione dei possibili blocchi utilizzabili nel micromondo da processare. In più, è bene notare come la definizione di regole specifiche per i singoli blocchi possibili sia pressoché inutile, dal momento che si presuppone che il sorgente da processare non sia realizzato a mano ma derivante direttamente dall’e- sportazione del Micromondo della Matrice validato dall’ambiente Snap!, e quindi privo di errori.

4.3.4 Conversione delle informazioni filtrate e generazione