Generative Programming: Domain Engineering

Secondo appuntamento con la programmazione generativa già discussa in precedenza in questo articolo sempre sulle pagine di DevMe. Ci eravamo lasciati parlando delle opportunità e delle comodità di cui gode la programmazione generativa, ovvero la creazione di programmi detti generatori capaci di creare, software specifici sulla base di una configurazione data in input. Il generatore è un programma in grado di generare una famiglia di altri programmi; la scelta del componente della famiglia è a carico della configurazione, ovvero del mezzo che discrimina un determinato componente da un altro. La configurazione può essere fornita in diversi modi: un file XML, un insieme di tabelle di un database, etc.
Quello di cui volevo parlare ora riguarda il Domain Engineering. Cos’è ? Partiamo dalla definizione: 
il Domain Engineering è l’attività di recuperare, organizzare e memorizzare l’esperienza maturata durante la costruzione di sistemi software o parti di sistemi di un particolare dominio, in modo tale che possa essere definita una forma di prodotto riutilizzabile, oltre a fornire un mezzo adeguato che descriva come fare a riutilizzare questi prodotti durante la costruzione di nuovi sistemi.
Ecco non spaventatevi….sebbene questa definizione possa sembrare incomprensibile, vedrete che analizzandola ci accorgeremo che è più semplice di quanto sembri.
I sistemi software che conosciamo possono essere classificati secondo la loro area di business, commercio elettronico, sistemi medicali, sistemi di prenotazione aerea, e così via. Chiamiamo queste aree Domini Verticali. Allo stesso modo possiamo classificare le parti di questi software sulla base della loro funzionalità, ad esempio i database, i sistemi di workflow, le librerie, etc. Chiamiamo queste parti di sistemi Domini Orizzontali.
Naturalmente questi sistemi o componenti all’interno di uno stesso dominio, condividono molte caratteristiche tra loro, e quando un’azienda che ha già lavorato ad applicazioni appartenenti ad uno stesso dominio, si trova a dover sviluppare di nuovo parti o sistemi dello stesso dominio, può trarre vantaggio da quanto già fatto riutilizzando il lavoro svolto. Qual è la parte difficile ? Ovviamente, cercare di trarre dalla conoscenza acquisita dal lavoro svolto, una forma che possa rendere quanto prodotto riutilizzabile, così da rimettere in campo componenti già sviluppati, e quindi già pronti. In questo modo l’azienda potrà produrre nuovi prodotti in minor tempo, a basso costo e di altà qualità.
Il Domain Engineering comprende:

• Domain Analysis
• Domain Design
• Domain Implementation

Il Domain Analysis consiste nel definire il focus del dominio, analizzarne le caratteristiche annotando quelle comuni, quelle variabili e le dipendenze all’interno della famiglia dei sistemi.
Il Domani Design consiste nel progettare il design di un’architettura comune costituita da un insieme di componenti elementari e altro, e del loro meccanismo automatico che permette di assemblarli.
Infine il Domain Implementation permette di implementare i componenti, definire la specifica e quindi il generatore.
Introduciamo ora quello che sarà l’esempio del prossimo articolo, ovvero un piccolo progettino che dimostra ancora una volta le potenzialità della programmazione generativa. Nell’ambito del mio lavoro, mi trovo spesso a sviluppare applicazione web in Java, tutti basata su Spring, ormai famoso framework di sviluppo, con il supporto di Spring Web Flow sottoprogetto di Spring utilizzato per lo sviluppo di Internet Rich Applications.
Prima osservazione: la struttura di un progetto Spring, almeno per quanto mi riguarda oramai è nota, o meglio detto in termini di Domain Engiinering, ha molte parti che accomunano i diversi progetti. Seconda osservazione: molti dei task implementati nell’ambito di applicazioni web, hanno in comune alcune funzionalità. Ad esempio, nell’ambito dello sviluppo di un RIA, classica di gestione clienti e fornitori, per ciascuna delle due entità dovremo fornire sempre le funzionaltià di inserimento, modifica e cancellazione. Bene, sulla base di queste osservazioni costruiremo una versione alpha del nostro generatore, che andremo via via migliorando. Al momento esiste già una versione alpha di questo generatore, non sono ancora riuscito a portarla a termine visto che il tempo che ho disposizione non è molto. Vedremo infine come la specifica di configurazione viene fornita mediante database, per la quale in futuro potrebbe essere sviluppata una piccola applicazione ad-hoc che permette di definirla in modo semplice.
Stay tuned !

Generative Programming: yes !!

Oggi volevo parlare di un argomento che mi appassiona molto, ovvero della Generative Programming (Programmazione Generativa).
Mi piacerebbe molto dedicarmi a tempo pieno, ma ahimé il tempo è quello che è ! Cerchiamo di capire di cosa stiamo parlando, o meglio proviamoci.

La Programmazione Generativa è un paradigma di programmazione basato sulla modellazione di famiglie di sistemi software tali che, data una particolare specifica dei requisiti, è possibile generare su richiesta (on-demand) una versione definitiva del software personalizzata in modo automatico.
La programmazione generativa si concentra sulle famiglie di sistemi software piuttosto che su un tipo specifico di sistema. I singoli software appartenenti a famiglie di sistemi, possono essere generati a partire da un modello di dominio generativo (generative domain model), ovvero un modello di una famiglia di sistemi che ha 3 elementi:

1. un mezzo per la specifica dei singoli software
2. un insieme di implementations components capaci di costruire, assemblandoli, i singoli software
3. una specifica di configurazione, che mappa la specifica di un membro con la sua implementazione finale

Un’analogia la si ha quando si ordina un’automobile. C’è un sistema per ordinare l’automobile, ci sono i componenti con i quali si provvede ad assemblare (costruire) l’automobile ed infine c’è una specifica configurazione che indica come assemblare l’automobile secondo l’ordinazione richiesta.
Riepilogando, l’idea è generare in modo automatico singoli sistemi a partire da modelli di famiglie di sistemi. I componenti e la specifica di configurazione vengono riutilizzati per ogni membro generato, riducendo così il costo dello sviluppo per ogni singolo membro.
Esiste realmente un potenziale di riduzione dei costi di realizzazione di singoli software, perchè piuttosto che dover sviluppare da zero l’intero sistema, spesso basta aggiungere solo qualche funzionalità al modello generativo esistente. In sintesi è possibile praticare economie di scala utilizzando la programmazione generativa, riducendo sia i tempi che i costi dello sviluppo di un singolo software.
Non voglio annoiare con troppa teoria, quindi passiamo a vedere un esempio pratico che illustra le potenzialità della generazione automatica del codice, non prima di aver precisato che, prima di avventurarsi alla scrittura di un generatore è necessario effettuare una attenta analisi per determinare quali sono le caratteristiche comuni della famiglia dei software con cui si vuole operare. Questa analisi ha un nome preciso e si chiama: Domain Engineering.
Nell’ultimo post pubblicato su devme, abbiamo visto come rendere più chiara l’organizzazione dei custom fields di wordpress raggruppandoli semanticamente all’interno di un riquadro. L’articolo illustra il codice da scrivere per realizzare il raggruppamento, in particolare analizzando il codice generato si nota come alcune parti di esso sono statiche, o meglio non cambiano nelle varie implementazione; altre invece sono dinamiche, cioè cambiano sulla base di ciò che si sta creando. Vediamo più nel dettaglio. 
La prima parte di codice costituisce la definizione della struttura dati che mappa i custom fields che si vogliono raggruppare con il riquadro. Si definisce il nome del custom fields ed il titolo che comparirà in corrispondenza del campo all’interno del riquadro. La seconda parte consiste nella creazione di funzioni che riferiscono quanto dichiarato nella prima parte e creano il riquadro che verrà visualizzato, in termini di codice HTML, la logica che permette il salvataggio dei dati in fase di inserimento e modifica di un post. Infine si procede con la registrazione all’interno del framework del codice scritto.
Non mi soffermerò molto sul codice dal momento che l’articolo è esaustivo, piuttosto rendo disponibile il codice che realizza il generatore qui ampiamente commentato e la versione demo qui.
Nelle prossime puntate vedremo cosa vuol dire e come si realizza il Domain Engineering passaggio chiave per la realizzazione di software generatori.
Stay tuned.
 

Symbian – Autostart di un applicazione su serie 9

Tempo fa in questo post ho scritto come realizzare un programma starter per Symbian serie 8, cioè un launcher di un’applicazione al boot del cellulare. Oggi invece volevo farvi vedere l’analogo su serie 9, la nuova serie di Symbian installata su molti dei cellulari Nokia attualmente in commercio. Premesso che al momento del post precedente la documentazione sull’argomento non era molta, oggi invece esistono molti siti dove è possibile trovare informazioni sull’argomenti, a partire dallo wiki della nokia dove c’è praticamente tutto, per finire sulla pagine di google .
Ma siccome le risorse in italiano non sono mai abbastanza allora volevo illustrare comunque la soluzione

A differenza della precedente versione con Symbian 9 è possibile realizzare l’autostart di un’applicazione usando il meccanismo dello "Startup Management List API" consultabile qui. L’idea di base di questa gestione consiste nel definire un file di risorse attribuendogli come nome l’UID del package che contiene l’applicazione. Tale file conterrà al suo interno alcuni dati di configurazione al fine di poter eseguire l’applicazione indicata all’avvio del programma. Vediamo in cosa consistono questi dati di configurazione:
 

1
2
3
4
5
6

#include <startupitem.rh> 
RESOURCE STARTUP_ITEM_INFO devme 
{ 
    executable_name = "!:\\sys\\bin\\devme.exe"; 
    recovery = EStartupItemExPolicyNone; 
}

Bene. Subito una piccola precisazione. Come vedete il valore di executable_name coincide con un path, quello di installazione dell’applicazione. Ha all’inizio un punto esclamativo che sta ad indicare la destinazione intesa come unità di installazione. Chi ha installato un’applicazione per symbian sa che ad un certo punto viene chiesto di indicare la destinazione su cui installare il programma, se la memoria del telefono o eventuali memorie esterne. Ecco il ! riferisce quella destinazione. Se si vuole, ad esempio, imporre l’installazione sulla memoria del telefono il ! verrà sostituito con C. 
Come vedete i dati di configurazione sono pochi e il commento viene da se.

Prossimo step consiste nell’aggiungere il riferimento del file appena creato all’interno del file di configurazione .mmp.

1
2

START RESOURCE ..\DATA\APP_UID.rss
END

Ed infine aggiungere le informazioni di configurazione nel file .pkg.

1

"$(EPOCROOT)Epoc32\data\z\private\101f875a\import\apps\APP_UID.rsc" -"c:\private\101f875a\import\[APP_UID].rsc"

Dove la prima parte della riga di configurazione indica il percorso delle SDK che si stanno utilizzando per la build corrente. Nel mio caso siccome sto usando Carbide come IDE posso utilizzare le variabili d’ambiente che mette a disposizione. Da notare che, mentre per un qualunque altro programma posso usare il ! per indicare la destinazione, per quanto riguarda l’autostart su serie 9 devo indicare C come destinazione…non solo, in aggiunta l’intero percorso dove vengono memorizzati questi tipi di file "C:\private\101f875a\import\".
Stay tuned, a presto.

Overloading del costruttore – REVIEWED -

Eh sì, devo proprio dirlo. Ho sbagliato !!! Non che non mi capiti mai, ma questa volta l’ho anche scritto sul mio blog, quindi DEVO riparare e salvare quello che ancora rimane della mia reputazione. L’errore è stato nel post in cui si parlava dell’overloading del costruttore, rimetto di seguito il giochino che avevo pubblicato:

1
2
3
4
5
6
7
8

public class OverloadResolver {
    public OverloadResolver(Object param) {
        System.out.println("Construttore con parametro Object");
    }
    public OverloadResolver(Object[] param) {
        System.out.println("Costruttore con parametro Object[]");
    }
}

La domanda era: "Qualcuno sa cosa succede se faccio questa chiamata:"

1
2
3
4
5

......
public static void main(String[] args) {
    OverloadResolver or = new OverloadResolver(null);
}
......

Ingenuamente mi son fidato. Nel senso che ho considerato buona la risposta che ho trovato nell’articolo che ho letto in internet, (in realtà volevo anche rispondere ora che so la risposta corretta, ma non riesco più a trovarlo, poi vi dico se lo trovo) e quindi non mi sono posto il problema di testarlo. Quando ieri, un caro vecchio amico, mi ha fatto gentilmente notare, e per gentilmente intendo a modo suo, che la risposta da me data non era quella giusta, in quanto diffidando dalla risposta ha testato l’esempio, e il risultato non era quello che avevo dato. Quindi, eseguendo l’esempio, il risultato è che viene richiamata la funzione:

1
2
3

public OverloadResolver(Object[] param) {
    System.out.println("Costruttore con parametro Object[]");
}

Perchè ? Il motivo lo incollo, così come l’ho trovato in internet, ovviamente sul sito della sun:

So the third rule is to choose the most "specific" method. The rule is: if any method still under consideration has parameter types that are assignable to another method that’s also still in play, then the other method is removed from consideration. This process is repeated until no other method can be eliminated. If the result is a single "most specific" method, then that method is called. If there’s more than one method left, the call is ambiguous. Suppose that you have the methods: f(float) f(double) In this case, the parameter types for the first method are assignable to the parameter types of the second method, that is, it’s legal to say: double = float through a widening primitive conversion. By contrast, saying: float = double is not valid without a cast. Based on this third rule, f(double) is removed from the set of possible methods to call, and therefore f(float) is called.

Morale della favola? La prossima volta non fidatevi degli articoli trovati in rete senza prima averli provato. Ciauu

Overloading del costruttore

1
2
3
4
5
6
7
8

public class OverloadResolver {
public OverloadResolver(Object param) {
System.out.println("Construttore con parametro Object");
}
public OverloadResolver(Object[] param) {
System.out.println("Costruttore con parametro Object[]");
}
}

Qualcuno sa cosa succede se faccio questa chiamata:

1
2
3
4
5

......
public static void main(String[] args) {
OverloadResolver or = new OverloadResolver(null);
}
......

Cioè se richiamo quel costruttore con parametro null, cosa viene richiamato nella classe di sopra ? Dai dai dai che lo sapete……e ditelo !!!!!! (magari qualcuno commenterà….chi lo sa!!!)