In SMEUP tutto è oggetto. Ci sono gli oggetti più classici e semplici (Articolo, pagamento, matricola, stringa, ecc.) e oggetti particolari che eseguono azioni (di rappresentazione o relazione o modifica del contenuto degli altri oggetti). Diciamo che li chiamiamo “processi”.  Per capirci pensiamo ad una normalissima riga di un menù di azioni.

La loro caratteristica dei processi è quella di “fare“, rispetto a quella degli oggetti, la cui caratteristica è di “essere“.

In SMEUP il “processo” è implementato da una funzione che è a sua volta un oggetto. Non solo è un oggetto ma è un oggetto importante. Sono funzioni ad esempio

  • Creare un nuovo ordine di vendita
  • Modificare i dati di un collaboratore
  • Visualizzare una scheda
  • Inviare una mail ad un indirizzo
  • Analizzare una serie numerica data

Un buon programmatore (diciamo per la verità uno che si vanta di essere almeno medio) che deve gestire ordini di vendita e ordini di acquisto, scrive un solo programma che gestisce gli ordini. Il programma ricevendo “vendita” legge tutte le caratteristiche di “vendita” e adegua il suo comportamento. Diciamo che ha caricato una “configurazione” che contiene tutte le opzioni variabili di comportamento. Ciò consente lasciare all’utente il maggior grado di libertà possibile. Abbiamo questo risultato quando gestiamo i documenti (vendita, offerta, contratto, bolla, richiesta di acquisto ecc.) ma anche quando visualizziamo un form all’utente (diciamo scheda per capirci) o quando poniamo delle richieste video all’utente su come vuole filtrare una stampa. Nel diversi casi, leggiamo una tabella, uno script o un formato video ma non cambia nulla. Leggiamo una “CONFIGURAZIONE” e ogni configurazione è guidata da un configuratore.

Possiamo dire che una funzione ha associato un configuratore (l’insieme delle domande o dei gruppi di domande). Per agire deve conoscere la configurazione (ovvero l’insieme delle risposte alle domande che definiscono la volontà dell’utilizzatore e quindi condizionano l’esecuzione). Io posso passare direttamente le risposte oppure molto meglio il nome con cui ho salvato quella combinazione di risposte.

Concentriamoci sull’oggetto funzione. (E’ così importante che la sua “scheda oggetto” dovrebbe essere quella più utilizzata!)

Come ogni oggetto anche la funzione ha delle proprietà. Proviamo a scomporre le principali

  • Cosa
    • Quale servizio (per semplicità possiamo dire programma)
    • Se il servizio svolge più funzioni dovremo dire quale funzione e se ogni funzione si scompone in metodi diremo quale metodo
    • Esempi:
      • Analisi di magazzino, giacenza media
      • Creare un nuovo documento
    • Come
      • Insieme delle risposte ad un questionario
      • Esempio
        • Quale magazzino, articolo, quale insieme di causali considerare, ecc)
        • Che tipo documento
      • Forma di rappresentazione dei dati (componente)
        • Una lista tabellare
        • Un elenco
        • Una gaussiana
        • Una immagine
        • Una stampa

Abbiamo alcune considerazioni particolare nel trattamento della configurazione:

  • Chiedo all’utente di scegliere la configurazione
  • Fornisco la configurazione ma voglio che l’utente la veda ed eventualmente modifichi qualche risposta

Se vogliamo andare più in dettaglio possiamo dire che

  • Smeup fissa alcune proprietà della funzione ed esse stesse sono una configurazione (Server che fornirà la risposta, oggetti base, ecc. Sopra chiamavo configurazione le risposte alle domande specifiche di quella funzione)
  • la funzione può trattare anche altre configurazioni che non sono passate ma implicite. Ad esempio cambio il mio comportamento in base alla “configurazione” dell’utente (chi, con che ruolo, con che autorizzazione, ecc) o al dove sto operando (mobile, web, )

La funzione in quanto oggetto può avere applicato funzioni tipiche di quell’oggetto. (oltre a quelle generiche tipo conoscerne gli OAV ecc)

  • Simularne il risultato (vedo l’XML)
  • Verificarne le prestazioni
  • Mascherare i dati (ad esempio per uso demo/documentazione)
  • Salvarla con un nome (ad esempio in un database di azioni) che poi potrò usare per costruire strutture di “preferiti” che come insieme descriveranno uno specifico processo.

Il centro di questo articolo è la funzione ma abbiamo parlato molto di configuratore/configurazione. Voglio qui approfondire questo concetto con particolare riguardo a coloro che conoscono le strutture parametriche di SMEUP

Definiamo come configuratore un insieme di gruppi di domande (caso particolare è quello di un solo gruppo) e configurazione una “compilazione” delle risposte alle domande di un configuratore. Spesso il configuratore comprende regole che pongono in relazione fra loro le risposte ma qui non ci concentriamo su questo.

Esempi di configuratori in SMEUP (Per i tecnici vedi la COPY £IR1)

  • Un file di video (con più formati, contenenti campi di richiesta). La sua configurazione è un MDV di salvataggio delle risposte
  • Un settore di una tabella (un solo gruppo). La configurazione è un elemento di tabella
  • Un editor di script (Lo script SCP_xyz sarà definito nel membro EDT_xyz del file SCP_CFG). La configurazione è un membro di script
  • Un configuratore è a sua volta un insieme di domande pertanto le domande potrebbero essere definite in un configuratore. In effetti un membro di SCP_CFG è la configurazione del configuratore EDT_CFG)
  • La categoria (C£E) dei parametri di un articolo. La configurazione è l’insieme delle risposte per uno specifico articolo
  • Un file (che definisce i campi). La configurazione è un record di quel file

Forse possiamo spingerci a dire che ogni informazione in SMEUP è la risposta che appartiene ad un configuratore ed è un attributo di un oggetto. Questa affermazione vale ovviamente per ogni sistema in quanto è una rappresentazione della realtà stessa. Il plus di Smeup è definire che quella risposta è un oggetto (in Smeup) e questo porta implicite tutte le proprietà dell’oggetto

Ritornando più in dettaglio al concetto di funzione possiamo dire che quando in SMEUP vedo una informazione, essa è la risposta ad una domanda che appartiene ad un insieme di domande definite in un configuratore. Essa è mostrata da una funzione che contiene i dati del servizio (e da qui posso passare facilmente all’oggetto servizio, alla sua documentazione ed eventualmente al suo programma (che sarà un oggetto), alla sua classe di autorizzazione, ma anche la configurazione e da questa potrò passare al configuratore. Se sono su una scheda potrò arrivare alla configurazione (ovvero lo script della scheda). Una configurazione sarà implementata da un configuratore (ad esempio l’editor della scheda) che conterrà domande ecc. ecc.

Tutto è uguale, tutto è oggetto.

E’ per questo che le cose scritte sopra sono così semplici.  E’ possibile che per risultare semplici vadano lette due o tre volte. Ovviamente se qualcuno è capace di descrivere in modo più semplice avrà la mia gratitudine.