Software Modulare
Per poter creare sistemi flessibili, evolutivi e scalabili, dobbiamo avere la modularità, ovvero quella proprietà che permette di creare un sistema bottom-up (dal basso verso l’alto).
Innanzi tutto bisogna avere i moduli, quindi serve un “archivio” di moduli. Essi devono poi essere interscambiabili, ovvero deve essere possibile sostituire un modulo con un altro modulo equivalente, e questo si fa permettendo lo scambio di informazioni tra moduli mediante interfacce definite: l’interazione dei componenti non deve variare col variare dei moduli.
Il software modulare scopre un nuovo paradigma di integrazione tra componenti con lo sviluppo dei mashup (applicazione web ibrida), ovvero creare qualcosa partendo da sorgenti diverse, ad esempio usando delle API create inizialmente per scopi diversi, ma poi combinate per produrre un nuovo prodotto.
Quanto devono essere semplici i moduli in un sistema modulare?
I moduli dovrebbero essere realizzati nel modo più semplice possibile. Ogni azienda può gestire in modo molto diverso le relazioni più complicate (e.g. gestione del personale), ma le funzionalità elementari rimangono le stesse (e.g. payroll). Moduli piccoli consentono maggiore riutilizzo, minor tempo di sviluppo e costante evoluzione (e.g. se si separa l’interfaccia utente, bisogna accertarsi che essa sia coerente, ad esempio bisogna poter utilizzare il copia-incolla indipendentemente dal sistema per cui quella UI viene realizzata).
Il problema che si pone è, chiaramente, su come realizzare l’interazione tra moduli. Un sistema di grosse dimensioni permetteva di avere tante informazioni legate tra loro all’interno del sistema stesso, inoltre permetteva di gestire in modo univoco le informazioni relative
alle autorizzazioni di accesso, mentre con i moduli i dati sono sparsi e i meccanismi di autenticazione possono essere vari.
Questa scomposizione ci dà, allo stesso tempo, molta libertà: i dati possiamo metterli dove vogliamo, distribuendoli a piacimento.
L’integrazione di tutte le componenti, database, moduli e interfacce, non avviene nel vuoto, ma avviene su una piattaforma: è lei che ci permette di effettuare l’integrazione, pertanto è necessario definire bene questa piattaforma.
Cio che permette la creazione di sistemi modulari è innanzi tutto uno standard sul tipo di informazione che viene scambiato dai moduli: deve esserci una corrispondenza nei possibili flussi di comunicazione tra moduli. Possiamo avere più sistemi di scrittura interscambiabili se abbiamo un unico standard per il documento, ma fino ad ora è successo l’esatto opposto: un sistema di scrittura predominante con un numero elevato di formati per i documenti. Questa situazione ha due aspetti negativi:
- se lo standard è associato ad un sistema, quel sistema tende a diventare universale,
- questo tende a favorire la chiusura del mercato, perché c’è uno standard che nessun altro può generare, quindi il più diffuso diviene automaticamente il più forte.
L’agenda è un esempio di applicazione trasversale nei confronti di tutte le altre applicazioni, perché di agenda deve essercene una, pertanto ha senso gestirla a livello di sistema, e non a livello di applicazione. Il sistema è la piattaforma sul quale facciamo girare le applicazioni, mediante il quale le facciamo comunicare. Questo ci permette di separare i dati dalle applicazioni. Cio semplifica molto la creazione del sistema informativo: possiamo unire i dati di due aziende più facilmente o usare applicazioni diverse per accedere agli stessi dati.
Unire sistemi informativi è fondamentale per il processo di fusione delle aziende. Avere moduli semplici, rende più facile lo scambio di informazioni rispetto all’adozione di moduli complessi.
La modularità è spesso già presente secondo un punto di vista esterno: quello dell’utente. Egli, infatti, vede il sistema un pezzo alla volta, ovvero vede solo il pezzo che utilizza e lo percepisce come un modulo separato dal resto. La modularità apparente è il primo passo per procedere verso la modularità reale.
Questo ci consente di creare interazioni e servizi nuovi e tra componenti. L’interfaccia del sistema diventa dipendente dall’ambiente che la circonda dall’utente: il sistema risponde quando l’utente ne ha bisogno, quindi il tempo di attesa diventa essenziale per misurare l’efficacia del sistema.
È importante che l’interfaccia sia progettata a partire dall’utente, da quello che fa: l’utente si abitua ai procedimenti, anche se sono ferraginosi e privi di logica.
Infine, la piattaforma deve essere conscia di essere una piattaforma: non solo deve permettere l’esecuzione dei moduli, ma deve anche contenere tutte quelle funzioni che possono essere trasversali (e.g. agenda, e-mail) alle quali possono accedere con le primitive di sistema (proprio come accade col copia-incolla). Per il sistema, queste potrebbero essere viste come
- applicazioni normali, ma sono fondamentali per poter unire le componenti.
- Piattaforma = sistema + servizi trasversali.
La piattaforma non è il sistema e non lo sostituisce, specialmente in caso si abbiano sistemi diversi (Windows, Linux, Mac…), in cui subentra il middleware, che mostra più sistemi come fossero uno solo.
Quindi, i sistemi modulari devono avere almeno 4 caratteristiche:
- i moduli devono essere semplici;
- i moduli devono essere interscambiabili;
- serve una piattaforma che sia ricca di servizi necessari per l’integrazione;
- l’interfaccia deve essere progettata per soddisfare chi usa l’applicazione.
Tutte queste caratteristiche sono legate all’evoluzione: i moduli permettono di avere evoluzioni separate e permettono l’evoluzione del sistema. La piattaforma e l’interfaccia devono, a loro volta, poter evolvere secondo protocolli e procedure.
