Tecnologia e ontologia di Sme.UP: la genesi degli oggetti

Premessa storica:

Alla fine degli anni 80, la fase pionieristica dei sistemi informativi aziendali era terminata e ci si rendeva conto di quanto fosse faticoso e frustrante per l'impresa essere costretta a sostituire una soluzione adeguata alle proprie esigenze, perché le innovazioni tecnologiche oppure le mutate condizioni del mercato lo rendevano inevitabile: un patrimonio di abitudini e di modelli operativi che veniva azzerato ogni volta, con costi e disservizi notevoli prima che la soluzione successiva potesse essere applicata.

Spazio da occupare:

I sistemi MRP della fine degli anni 80 non coprivano adeguatamente molte aree applicative; ne restavano escluse alcune particolari, ad esempio la gestione della qualità, la schedulazione a capacità finita, la manutenzione impianti, etc. In questo spazio si sono posizionati i primi moduli di Sme.UP. Essi dovevano vivere in ambienti diversi , ma non potevano essere sviluppati in "versioni " diverse in quanto il laboratorio di Sme.UP a quel tempo non aveva le risorse (giorni e quindi soldi) per sviluppare versioni diverse del modulo qualità, una per ogni ambiente gestionale diverso con cui conferire informazioni.

Il trucco:

Data la difficoltà, si è trovata la soluzione. I programmi di Sme.UP dovevano leggere informazioni da sistemi gestionali diversi, dovevano quindi essere pensati come separati rispetto al contenitore delle informazioni, e doveva esserci una struttura specifica, astratta ed estendibile , che provvedeva al recupero delle informazioni in ambienti diversi.

L'oggetto e le sue interfacce:

A questo punto è stato "concettualizzato" l'oggetto applicativo, ossia l'entità informatica proprietaria delle informazioni ed a cui accedono i programmi Sme.UP tramite dei servizi di interfaccia. I primi oggetti interfacciati sono stati gli articoli, poi i fornitori, i clienti etc.... Un programmatore di Sme.UP che scrive un programma che necessita informazioni di un articolo si limita a chiamare una interfaccia (API) che è configurata in funzione del contesto, e quindi recupera dal giusto archivio le informazioni dell'articolo. Anche l'origine del dato è in discussione: l'interfaccia non solo permette di leggere il dato fisico definito altrove, ma potrebbe anche calcolarlo, ossia rendere il dato dinamico (per esempio la anzianità di un dipendente non è scritta da nessuna parte, c'è un programma che la calcola)

Vantaggi:

Per il laboratorio di sviluppo significa gestire un programma invece di N programmi, quindi con un numero di risorse di sviluppo minori, quindi con maggior competenza media (chi ha provato a gestire laboratori di sviluppo sa che competenza media e numerosità sono inversamente proporzionali..) . Per il Cliente significa poter cambiare il proprio sistema gestionale non preoccupandosi dei programmi satellite che leggono dati dal gestionale, perché basta ridefinire le interfacce da usare ed il sistema continua a funzionare, così come quando cambio la stampante non sono obbligato a cambiare il PC perché c'è una interfaccia che li collega.

Salto culturale e bottega di sviluppo:

Negli anni dal 92 al 97 la concettualizzazione degli oggetti applicativi ha rivoluzionato il modo di scrivere software e disegnare soluzioni degli sviluppatori Sme.UP. Essi si sono trovati di fronte i vantaggi dell' Object Oriented che gli permettevano di fare in poco tempo cose grandiose. Si è creata una comunità di sviluppo che ha disciplinato un proprio modo di costruire il software applicativo, utilizzando i propri strumenti che giorno dopo giorno mostravano vantaggi inaspettati.
Il tutto avveniva con l'RPG e sull'AS400, un linguaggio ed un server "bistrattati" dai cultori dell'informatica "OO" , quella dei mondi "open". A causa di questa bassa considerazione recepita, chi scriveva la documentazione di Sme.UP nel 95 non utilizzava riferimenti all' "Object Oriented" , perché non era accettato come accostabile all'RPG! Ora invece non si vergogna affatto di parlare di "oggetti Applicativi" contrapposti pragmaticamente ai linguaggi "object oriented"

L' oggetto ed i suoi attributi:

in questo cammino sono stati sviluppati anche strumenti che permettono di espandere gli attributi di un oggetto, ossia le sue informazioni, chiamate OAV (oggetto attributo valore). Questo ha permesso a Sme.UP di superare la mancanza di informazioni gestite dai sistemi conferenti, integrandole con una propria struttura di attributi. Ad esempio, se si vuole definire per l'oggetto articolo il parametro "diametro" , oppure "contenuto di carbonio", si può utilizzare questa informazione per riepilogare il fatturato per "diametro" o "contenuto di carbonio".
Attributi di un oggetto