GBuilder è l’innovativa suite per progettare, sviluppare e distribuire robuste applicazioni multi-tier sfruttando il codice e le capacità in ambiente Embarcadero Delphi ed Adobe Flex, che guida il team di sviluppo verso le più recenti tecnologie Web e lo standard SOAP e consente la creazione di applicazini basate sull'architettura 2G.

E' la prima soluzione basata sul concetto di modellazione globale, dove la virtualizzazione dei dati, le regole di business di base e le caratteristiche dell’interfaccia utente sono registrate come informazioni all’interno di un unico repository, consentendo la costruzione di affidabili servizi di business e Rich Internet Applications di livello Enterprise, pronte per il rilascio, e dotate delle più avanzate funzionalità di configurazione ed amministrazione. Le applicazioni realizzate con 2G implementano il Modello multi-tier SOA, basato su Web services (SOAP) in http/https, con WSDL e XSD pubblicati dinamicamente. Caratteristiche esclusive del modellatore e del framework sono la presenza di un Repository comprendente le definizioni degli oggetti di business e le specifiche di interfaccia, direttamente impiegato sul sistema utente che le classi a run-time interpretano dinamicamente, e l’evoluta interfaccia utente multi-finestra Web 2.0 delle applicazioni prodotte, che sfrutta l’altissima interattività dell’ambiente Adobe Flex ed è compatibile con tutti i più diffusi browser internet. 

Modellazione

GBuilder è lo strumento per la modellazione delle applicazioni 2G. Un modello comprende la definizione degli oggetti di business, le loro proprietà e relazioni, le specifiche di interfaccia utente, i messaggi, i parametri, le regole e tutto il necessario per realizzare l'infrastruttura di base server e client. Tutte le informazioni di progetto sono registrate nel database di produzione; GBuilder consente di aggiornare il database di produzione tramite i dati del modello. Il database viene utilizzato dalle classi 2G per esporre i servizi web e gli oggetti di business , nonché per generare dinamicamente le definizioni di interfaccia che l'applicazione Flex è in grado di leggere e interpretare. Se gli oggetti di business non richiedono logica applicativa specialistica, le classi standard 2G sono in grado di esporre tutti i servizi richiesti dal lato client per gestire e manipolare i dati e interfacce , senza scrivere una sola riga di codice . Tuttavia, gli elementi che richiedono un trattamento speciale, come ad esempio l'aggiornamento di più entità secondo specifiche logiche applicative, possono essere implementate personalizzando il codice Delphi e/o Flex , ereditando le classi standard creati dal framework. Le classi di interfaccia standard includono : menu ribbon; griglie avanzate e di base; griglie modificabili; viste ad albero, form , nonché una serie completa di strumenti di configurazione e amministrazione.

Elementi del Modello

Un modello 2G si basa su elementi elementari chiamati VirtualSet. Un Virtualset rappresenta un oggetto di business quando si basa su dati persistenti (una o più entità di database o il risultato di una query parametrica), una serie di parametri quando si parla di un descriptor.
Un VirtualSet relativo a database può essere utilizzato allo stesso modo di un set di dati , la definizione include un elenco di campi, chiamati VirtualFields, ognuno con le proprie caratteristiche, le regole di gestione e l'aspetto visivo, e una o più definizioni di interfaccia, per visualizzare e manipolare i dati sul lato client. Un descriptor non si basa su dati, esso può essere utilizzato per raccogliere i parametri di un modulo per eseguire operazioni lato server, quali un report o una procedura remota . Il framework 2G è responsabile della pubblicazione dei metodi per l'inserimento, modifica e cancellazione dei dati nei virtualset, unitamente ai metodi per istruire il client nella progettazione delle form di gestione.
Un'interfaccia, griglia o form, può includere in tutto o in parte gli strumenti standard di gestione e/o controlli specifici, chiamati Action; una Action può chiamare altre interfacce o procedure remote, denominati processor, passando uno o più parametri. Un processor è una classe Delphi hard coded e compilata all'interno di un'applicazione lato server; 2G espone processor di inserimento/aggiornamento automatico standard del virtualset modellato, basato sulla logica di business predefinita da modello, ma nuovi processor o processor custom possono essere scritto in Delphi per implementare procedure personalizzate o logiche complesse.   Gli elementi che compongono un modello 2g sono i seguenti :

• Entities. Sono le entità fisiche (tabelle) o logiche (viste aggiornabili o non) contenute nel database applicativo, che entrano in gioco nella definizione dei VirtualSet (oggetti di business, vedi sotto).
• VirtualSets. Sono gli oggetti di business veri e propri, che contengono le informazioni trattate dal sistema. Possono essere basati su dati persistenti (entities aggiornabili), dei quali definiscono relazioni e proprietà (campi), su dati non persistenti (viste non aggiornabili o selezioni definite dall’utente), su definizioni di struttura (descriptor) utili alla sola raccolta dati da interfaccia. I virtualset definiscono le caratteristiche fondamentali delle singole informazioni, denominate VirtualFields, relativamente alle proprietà elementari (nome, formato, tipo, regole di aggiornamento), quelle di interfaccia (modalità di rappresentazione/input) e comportamento specifico (progressività, nullabilità …).
• Interfaces. Sono le interfacce relative ai singoli VirtualSets, che definiscono i modi con i quali l’utente interagisce con i dati. In 2G esistono classi predefinite per la rappresentazione in griglie lineari (a diversi livelli di complessità), in griglie gerarchiche ed in form. Le interfacce sono richiamabili da menu o da altre interfacce;
• Layouts. I layouts sono relazionati alle interfacce e definiscono quali VirtualFields sono accessibili all’interfaccia specifica e con quali caratteristiche.
• Actions. Le Action rappresentano gli elementi di collegamento tra i diversi elementi del modello 2G, tramite I/O Rules, dal punto di vista del Client. In particolare le Action permettono di collegare : Interfacce ad altre interfacce, Interfacce a Provider/Processor, VirtualFields a specifiche interfacce/provider di lookup, Voci di menu a Interfacce, Voci di menu a Processor.
• Menu. Le voci di menu costituenti una applicazione sono elementi separati rispetto ai VirtualSet ed agli altri elementi del modello. La struttura delle voci è definita nell'ambito di una struttura ad albero. Ciascuna Voce di Menu è associata ad una Action, la quale può lanciare una interfaccia o eseguire un processor.
• Report. I Report sono elementi indipendenti nell'ambito del modello, definiti in uno specifico repository, anche se il loro impiego avviene nell'ambito delle interfacce. In particolare i report vengono eseguiti attraverso Form appartenenti ad una specifica classe (generalmente basate su VirtualSet di tipo Descriptor) che includono nelle definizioni l'elenco dei Report ottenibili.
• Modificatori. I modificatori non sono elementi autonomi, ma informazioni aggiuntive rispetto agli altri elementi del modello, quali i VirtualSet, i VirtualFields, i Report, i Menu, i Processor, le interfacce, le Action. Lo scopo dei modificatori è alterare il funzionamento degli oggetti, a run-time, in funzione di diversi possibili aspetti, quali ad esempio la presenza/assenza di certificati di licenza (extensions), il valore di parametri applicativi, il contenuto di variabili di sessione e via discorrendo.
• Provider. I provider non sono elementi del modello propriamente detti, ma rappresentano i servizi messi a disposizione del server per la lettura di dati (metodo GetRecordList). Nel modello non esiste pertanto un repository dei provider, che vengono esposti automaticamente per i VirtualSet abilitati alla lettura. Esistono inoltre provider che non derivano da VirtualSet presenti nel modello, ma sono esposti dal sistema automaticamente, per consentire la lettura di informazioni legate alle funzionalità built-in (ad esempio gli Utenti e le Sessioni per le funzioni di amministrazione).
• Processor. Con il termine processor si individua una classe applicativa esposta dal server sotto forma di servizio. I processor eseguono generalmente operazioni sui dati, quali ad esempio l'inserimento/modifica di record in un VirtualSet, e possono appartenere a due categorie principali :
  • Processor Dinamici. Vengono pubblicati dal servizio in modo automatico, sulla base delle definizioni dei VirtualSet, per consentire l'inserimento/modifica/cancellazione dei record in essi contenuti;
  • Processor Custom. Sono realizzati manualmente a fini applicativi, generalmente eseguono controlli o calcoli che necessitano di logica server;
  • Processor di Sistema. Sono pubblicati dal servizio in riferimento a specifiche funzioni built-in, che il sistema gestisce in modo nativo.

Gli elementi sopra descritti vengono definiti all’interno del modellatore, 2G Builder, e conservati nel repository che, portato sul sito utilizzatore, è letto dal motore 2G Framework per dare luogo all’applicazione vera e propria. L’interfaccia, scaricata sul browser degli utenti sotto forma di agent run-time, dialoga automaticamente con gli application server sulla base del modello in uso.

La modellazione e le funzioni standard riguardano sia il lato servizi che il lato interfacce, nel senso che 2G Framework fornisce di base una soluzione “completa” direttamente utilizzabile dall’utente finale e dotata di tutti gli strumenti di amministrazione necessari nelle applicazioni di livello enterprise, limitando gli interventi di codice alle sole regole evolute di business (se presenti nell’applicazione), senza necessariamente conoscere i protocolli impiegati e i problemi di integrazione nei servizi. Questo aspetto, unico nel panorama degli attuali sistemi CASE per architetture SOA, è fondamentale perché l’impiego di 2G Builder non necessita di conoscenze specifiche in ambito SOA/RIA e consente di produrre applicazioni complesse tipo in tempi rapidi e senza criticità, acquisendo il know-how su tali nuove tecnologie in modo graduale, guidato e strutturato. Una infrastruttura assolutamente innovativa anche perché la modellazione pressoché completa anche del lato interfacce potrebbe consentire il cambiamento quasi indolore delle tecnologie utilizzate sul client, in funzione delle evoluzioni future del mercato e delle aspettative degli utenti, conservando la logica e le informazioni del livello astratto.

Interfacce nel Modello

Una delle più interessanti caratteristiche di GBuilder è la capacità di progettare e distribuire un'applicazione completa , client e server side , senza scrivere una sola rigadi codice . Menu utente , griglie e form possono essere facilmente definite all'interno del modellatore , le loro proprietà visuali sono memorizzate all'interno del repository , e gestite utilizzando gli strumenti della suite . Nessuna riga di codice è necessaria per produrre una nuova voce di menu o un modulo di gestione di dati , non sono necessarie procedure Flex ; 2Gframework Flex legge , interpreta e gestisce dinamicamente le specifiche della form definite lato server , usando i servizi web . Gli strumenti di progettazione interattivi sono così flessibiliche gli sviluppatori possono semplicemente ignorare le tecniche di programmazione Flex , essendo 2g in grado di produrre form applicative robuste e affidabili in brevissimo tempo.

Il Repository

Un altro grande vantaggio di 2g è che la maggior parte delle strutture dell’applicazione, le specifiche e le sue caratteristiche sono memorizzati all'interno di un database. Questo permette ai programmatori di cercare, analizzare e operare sugli oggetti applicativi attraverso gli strumenti di SQL , anche in modalità massiva , e consente agli analisti di navigare velocemente le funzionalità dell'applicazione . Ad esempio i programmatori possono decidere di estrarre ogni form comprendente uno specifico campo, per modificarne l’apparenza o il comportamento, applicando tutti i cambiamenti con una sola operazione. Inoltre un repository astratto rende possibile la futura migrazione tecnologica del client e/o del lato server : poiché gli oggetti di business e le loro relazioni sono memorizzate separatamente dal codice, un diverso framework server e/o client scritto in altre tecnologie, altre lingue o piattaforme, può consentire la migrazione di un'intera applicazione con interventi minimi o nulli, permettendo anche la coesistenza dello stesso modello su diverse piattaforme.
Il repository di moldello include i report e le definizione delle procedure remote, permettendo la centralizzazione completa degli elementi applicativi e la capacità di produrre documentazione automatica, per uso interno o esterno. Le classi Delphi possono essere automaticamente lette dai codici sorgenti e memorizzati nel repository, facilmente associate ai processor di 2g, migliorando drasticamente la documentazione di sistema e le capacità di manutenzione .
Form e messaggi dell'applicazione, così come le etichette, sono memorizzati nello stesso modo, permettendo una traduzione facile per produrre applicazioni in lingua.
E’ inoltre disponibile uno strumento interno alla suite per il controllo delle versioni, che traccia le modifiche alle definizioni nel modello; anche la correzione ad una etichetta può essere tracciata e utilizzata per predisporre la documentazione di aggiornamento della versione. 

Strumenti per gli sviluppatori

2G Builder Suite rappresenta ad oggi l’unico strumento CASE integrato, in grado di accogliere logica di business in formato Delphi e di consentire la produzione guidata di una soluzione completa, lato client e lato servizi, a partire da una applicazione già esistente. Infatti GBuilder, ma lo stesso GBuilder mette a disposizione numerosi tool per agevolare la conversione di applicazioni e la scrittura delle classi, attualmente sulla base di sorgenti Delphi o Adobe Flex ma facilmente estendibile ad altri ambienti di sviluppo. A tale scopo sono presenti le seguenti funzionalità : 

• Indipendenza dalla base dati. E' la capacità di sviluppare applicazioni 2G basate su database che non nascono a tale scopo o che non sono agevolmente ristrutturabili (nell’ottica che chiunque possa impiegare 2G anche su basi dati di proprie applicazioni). Riguarda la possibilità di conservare il repository del modello su un database indipendente dal database dati, come pure separare il database degli allegati elettronici e limitare al minimo le variazioni da apportare alle strutture dati. In questo modo le informazioni di modello risultano separate ed indipendenti dal database applicativo e indipendendenti dall'applicazione.

• Produzione guidata di logica/parametri server. Si tratta di funzioni integrate al tool per la lettura automatica di sorgenti esterni, attualmente strutturato per Delphi, in modo da agevolare la loro introduzione nel sistema di modellazione e consentire la gestione dei processor tramite repository di classificazione.

• Internazionalizzazione. In GBuilder sono presenti gli strumenti per consentire la produzione agevole di software in lingua, sia con riferimento ai messaggi che alle etichette standard impiegate da 2G, per la costruzione dell’interfaccia rivolta all’utente finale. Ciò consente la realizzazione di applicazioni in lingua diversa da quella italiana. Attualmente è presente la predisposizione dei testi per lingua italiana ed inglese, ma eventuali altre lingue possono essere aggiunte agevolmente anche da terze parti, tramite un repository di termini tradotti.

Il progetto 2G Builder ha ricevuto un contributo da parte della regione Lazio nell'ambito dell'avviso Pubblico "Progetti di innovazione delle micro e piccole imprese" - POR FESR Lazio 2007/2013 Asse I - Attività 2 - Codice CUP (Codice Unico di Progetto) F87I12002230007 - Innovazione di Prodotto 2G Builder Suite.