La dicotomia delle competenze

Uno dei problemi più frequenti nell’affrontare un progetto software è dato dalla necessità di avere competenze in due aree della conoscenza molto diverse: la materia specifica oggetto del progetto e le tecniche di sviluppo software.

Normalmente, queste diverse conoscenze, sono possedute da persone distinte, spesso anche più di due.

Una delle principali cause di questa situazione è la sempre maggiore complessità delle tecniche di sviluppo software: uno sviluppatore competente e aggiornato per essere tale finisce per concentrarsi totalmente in quest’ambito tralasciando – non rararmente in modo volontario – ogni altra conoscenza.

Anche lo stereotipo che vuole i migliori tecnici avere scarsa attitudine ai rapporti interpersonali, sopratutto verso gli utenti finali, ha probabilmente un fondo di verità: la dedizione che la tecnica pretende richiede personalità con caratteristiche ‘speciali’.

All’estremo opposto, chi meglio conosce la realtà e le problematiche oggetto dei progetti software, che ha una chiara visione delle finalità del progetto e dell’ambiente nel quale sarà calato, e che quindi avrebbe tutti i titoli per condurlo, solitamente non possiede le conoscenze tecniche necessarie.

Questa dicotomia obbliga ad un continuo scambio di informazioni con conseguenti inevitabili incomprensioni, rimpalli di responsabilità, reciproca frustrazione e a volte, fallimento del progetto.

E’ necessario che le tecniche di sviluppo software evolvano in modo tale da non essere più appannaggio di una ‘casta’ di tecno-esperti, ma strumento produttivo nelle mani di chi conosce ed affronta direttamente le problematiche reali.

 

L’Applicazione generalizzata

Generalizzando possiamo affermare che un’applicazione non è altro che la possibilità di interagire con la rappresentazione virtuale di una porzione di realtà di nostro interesse; in concreto è la possibilità di accedere e manipolare dati strutturati e relazionati secondo un modello, più o meno preciso, di quella realtà.

Solitamente, sempre generalizzando, la complessità di un’applicazione si manifesta nella sua ampiezza, cioè nella quantità e nella varietà delle informazioni che rappresenta e gestisce piuttosto che nell’originalità delle manipolazioni che queste informazioni devono subire.

Tali manipolazioni, per quanto varie, comunemente si riducono a poche elementari operazioni: inserimento, visualizzazione, modifica, cancellazione (le cosiddette operazioni CRUD), ordinamento, raggruppamento, ricerca, stampa, importazione ed esportazione.

Oltre a queste esistono altre operazioni più specifiche, legate alla natura dell’applicazione, assimilabili al concetto diprocesso, cioè ad una trasformazione di dati, più o meno controllata dall’utente.

Anche la modalità con la quale l’utente percepisce ed interagisce con le informazioni è riducibile a pochi paradigmi ben definiti: tabella, scheda, campo, azione.

 

Schematizzando un’applicazione generalizzata è composta dai seguenti elementi:

• i dati, le loro relazioni e le loro regole di validità e coerenza: sono il modello della porzione di realtà oggetto dell’applicazione;
• una serie di operazioni comuni di base per la gestione dei dati;
• la possibilità di eseguire interrogazioni sui dati secondo vari criteri predefiniti e liberi;
• una serie di operazioni di processo/trasformazione dei dati;
• un’interfaccia utente in grado di rappresentare i dati, secondo vari paradigmi, che ci consente di operare su di essi;

Vale anche in questo caso la nota regola 80/20, cioè la maggior parte delle applicazioni necessita di poche funzioni comuni, le funzioni particolari servono a relativamente poche applicazioni.

In virtù di queste considerazioni possiamo adottare nei confronti delle applicazioni da realizzare un approccio altrettanto generalizzato.
Naturalmente il risultato in tal modo ottenuto sarà un compromesso.
Questo approccio offre indubbi vantaggi ma ovviamente è portatore anche di alcune limitazioni.
La principale consiste nella mancanza di una libertà completa nella realizzazione dell’applicazione: ciò che è possibile fare deve rientrare in un ventaglio di possibilità previste che per quanto ampio è comunque finito.
L’obbiettivo non è fare tutto, nel migliore dei modi, ma fare molto, in maniera soddisfacente (e con vari altri vantaggi).
Alcune applicazioni, per specificità o singolarità, sono poco adatte a questo approccio e lo sforzo necessario ad ottenere il risultato potrebbe essere superiore ai vantaggi derivanti dall’uso di questo approccio.

 

Il disaccoppiamento

Ai due estremi di un’applicazione software si trovano da una parte i dati e dall’altra gli utenti.
Concretamente essa viene realizzata utilizzando varie tecnologie che la permeano completamente: dal lato dei dati per consentirne l’accesso (driver per database, librerie per web services, ecc.), dal lato dell’utente per la fruizione attraverso i dispositivi (HTML, Client Desktop, Rich Client, ecc.) e nel mezzo per l’implementazione del sistema vero e proprio (Servlet/JSP, ASP, RPC, ecc.).
Con gli approcci tradizionali l’implementazione dei vari componenti, la struttura dei dati, le tecnologie scelte e le specificità dei dispositivi sui quali si opererà sono mescolate assieme dando luogo ad una costruzione intricata e complessa che ha necessità di ampie ed approfondite competenze per la sua realizzazione e il suo mantenimento.
Qualsiasi modifica in uno dei componenti, nei dati o nella tecnologia ha impatto su tutto il resto.

Grazie al disaccoppiamento, cioè facendo in modo che questi elementi siano separati ed indipendenti, si ottiene una notevole riduzione della complessità:

• il modello dei dati è indipendente dall’implementazione: ampie parti di applicazione (le operazioni comuni, le interrogazioni libere, l’interfacca utente) diventano neutre rispetto ai dati e non dovranno essere ogni volta nuovamente sviluppate;
• le tecnologie diventano intercambiabili;
• le competenze necessarie sono nettamente inferiori;

Il disaccoppiamento è il principio sul quale si basano anche i framework applicativi.

Un ulteriore aspetto importante riguarda la definizione del modello.
Nei sistemi tradizionali la definizione è realizzata utilizzando la tecnologia di implementazione stessa cioè il linguaggio di programmazione.
Benchè tale linguaggio il più delle volte sia object-oriented e quindi adatto alla realizzazione di modelli, risulta comunque non ideale a questo scopo e comporta in ogni caso un’implementazione a tutti gli effetti.
Anche in vari sistemi basati sui modelli sebbene il modello di partenza sia espresso con sistemi appositi – dichiarativi e non implementativi – il processo di sviluppo, grazie ad apposite trasformazione, mira ad un modello implementato.
Utilizzare direttamente un modello neutro (non implementato) consente un’ulteriore riduzione di complessità e un ulteriore maggiore disaccoppiamento dalla tecnologia implementativa.

 

Relazione con le attuali tendenze dello sviluppo software

Da un punto di vista metodologico

VISUS appartiene alla categoria dei sistemi MDD (Model-Driven Development) cioè di quei sistemi che mirano a produrre il codice non manualmente ma basandosi su di un modello che descrive ciò che si vuole implementare.
VisusScript ne è il relativo DSL (Domain Specific Language) cioè la particolare notazione utilizzata per definire il modello.
VISUS, a differenza di molti sistemi MDD, non è un generatore di codice ma un interprete di modelli: non genera codice sorgente in modo automatico o assistito ma, interpretando il modello, ‘rende’ l’applicazione.
Grazie a questo approccio il modello astratto diviene un modello concreto, direttamente eseguibile.
Il passaggio dal modello all’applicazione, che di norma prevede diverse trasformazioni, scelte tecnologiche e interventi di codifica manuale, non è più nemmeno un processo ma diventa un unico evento realizzato in tempo reale.
Tutte le correzioni, gli adattamenti le integrazioni vengono effettuati unicamente sul modello.

Da un punto di vista architetturale

La gran parte degli attualmente diffusi framework applicativi si basa sul cosiddetto pattern MVC (Model-View-Controller) nel quale si utilizzano varie tecnologie per realizzare le tre componenti principali del sistema:

Controller: è il nucleo del sistema che riceve le richieste e fornisce le risposte ottenendole dalle altre componenti;

Model: è la logica applicativa realizzata in genere utilizzando un linguaggio ad oggetti e modellando con esso la maggior parte della logica applicativa;

View: è la parte di presentazione realizzata con varie tecniche dipendenti dal dispositivo che si utilizza per eseguire l’applicazione.

Vi è poi un ulteriore componente (DAO) che provvede a leggere e scrivere le informazioni rappresentate dal modello, in modo permanente (persistenza), generalmente in un database.

Le componenti Model e View sono da implementare; l’implementazione è complessa, richiede notevoli conoscenze e capacità tecniche ed è completamente a carico dello sviluppatore.

Le implementazioni sono fortemente legate al framework e alle tecnologie ad esso associate.

Anche VISUS si basa sul medesimo pattern ma le tre componenti sono fuse insieme: il Controller è il nucleo di Visus stesso, il Model e semplicemente definito attraverso VisusScript e non implementato scrivendo codice, la View è generata automaticamente secondo vari paradigmi predefiniti e per vari dispositivi.
Il Model si identifica con il database stesso che per sua natura è già di per sé un modello (il modello relazionale).
Le meta-informazioni fornite dal modello VisusScript sono utilizzate per arricchirlo ulteriormente.
Qualsiasi aggiornamento alle informazioni gestite dall’applicazione e rappresentate dal modello è immediatamente ed implicitamente trasmesso al database.
In questo senso VISUS è completamente Data-driven.

Solo la semplice definizione del Model, non la sua implementazione, è a carico dello sviluppatore.

Non essendoci implementazione non si è legati a nessuna tecnologia.

 

Il contenuto ‘procedurale/implementativo’ delle applicazioni

L’approccio comune alla manipolazione dei dati, che generalmente risiedono su di un Database, prevede l’utilizzo di procedure appositamente implementate e scritte con i vari linguaggi di programmazzione tradizionale (Java, C/C++, Visual Basic, Delphi, ecc.).

Questa pratica porta ad una inevitabile separazione tra i dati e le procedure che li manipolano; tale separazione si manifesta nella necessità di differenti tecnologie, strumenti, competenze.

Diversamente, se le necessarie operazioni di manipolazione dei dati sono realizzate unicamente attraverso il database, utilizzando query SQL ed eventualmente Stored Procedure, si ottengono diversi vantaggi:

• una elevatissima portabilità (naturalmente a patto di non usare caratteristiche specifiche di un database);
• l’utilizzo di un linguaggio – SQL – tutto sommato standardizzato, sul quale le competenze generalmente si possiedono già, è facile trovarne e maturarne delle nuove è comunque un buon investimento;
• la possibilità di sfruttare queste logiche da parte di altri sistemi ed anche manualmente;
• l’utilizzo di uno strumento – il database – ideale per questo tipo di operazioni;
• la gestione di concorrenza, integrità relazionale e transazionale, e di tutte le caratteristiche native che il database offre (sicurezza, scalabilità, ridondanza, federazione, ecc.);
• l’accoppiamento e la ‘vicinanza’ (incapsulamento) tra i dati e le operazioni;