Questo articolo è da considerarsi unito e di spiegazione dell’immagine allegata. Tale immagine riprende una vecchissima rappresentazione dell’architettura di Sme.UP che descriveva scomposizione e indipendenza attraverso il concetto di Service Layer.

Anche la singola funzione applicativa interna a Sme.UP poi applica la logica dei componenti per cui ad esempio le fonti di pianificazione possono indirizzare “microservizi” resi disponibili da altri fornitori di servizi. Qui vediamo la scomposizione dal punto di vista dell’interfaccia utente.

L’architettura di Sme.UP è da sempre orientata alla soluzione di esigenze applicative. L’esigenza di un utente è quella di fruire di una informazione su un device che ha a disposizione.

Avremo ad esempio

  • Video in modalità carattere
  • Smartphone
  • Tablet
  • PDF o stampe in genere
  • Una pagina WEB
  • Un personal computer
  • Un qualsiasi device fisico (attuatore ecc.)

Per comprensione d’ora in avanti ci riferiremo ad uno smartphone su cui vogliamo utilizzare Trip Advisor

Si presenterà una pagina (scelta funzione, ricerca o dettaglio di un ristorante) divisa in sezioni.

In una sezione avrò:

  • Una forma, adeguata al tipo di informazione che voglio vedere
    • Una lista di località o di ristoranti
    • L’immagine di un piatto
    • La sintesi grafica dei giudizi
    • L’elenco delle funzioni disponibili (chiama, ecc)
    • Un blog di commenti dei clienti
  • Dei dati
    • Il numero dei giudizi per giudizio
    • Il testo di un utente
    • Le località o i ristoranti

Sme.UP mette a disposizione:

  • Numerosi componenti grafici comuni o specifici per ogni device e che possono comporre una struttura di interazione
  • Un contenitore di componenti (componente a sua volta) che ne permette sia la disposizione che l’interazione
Web.UP - Sme.UP Componenti
Web.UP – Sme.UP Componenti

Ogni componente riceve i dati mediante il richiamo di una funzione

In Sme.UP sono particolarmente rilevanti le seguenti caratteristiche della funzione di richiesta dei dati

  • La possibilità di indirizzare la lettura su diversi fornitori di servizi.
    • Forniti da Smeup stesso
    • Di altri fornitori di servizi
  • Che il dato ricevuto ha un contenuto semantico in se stesso. Ciò che in Sme.UP chiamiamo “Oggetto applicativo”. Tutti i componenti grafici sono pensati per comprendere l’oggetto e trattarlo di conseguenza, sia come modo di rappresentazione (una immagine, un numero, una provincia) che come azioni implicitamente disponibili

Sme.UP fornisce il provider ma anche l’insieme delle funzioni generali (rappresentate nell’immagine dalla barra rossa alla base di ogni server). Tali funzioni (la documentazione, l’interfaccia agli oggetti, le autorizzazioni applicative, i layout di presentazione) sono prive di contenuto applicativo specifico ma si occupano di capire e indirizzare le domande. Un sistema di applicazioni potrà a sua volta inserirsi nell’architettura mediante un modulo specifico che trasforma le domande ricevute in domande comprensibili in tale contesto.

Proviamo a spiegarci con un esempio

  1. Voglio vedere in una matrice tutti i files sul mio desktop. I dati mi sono forniti da un servizio di Sme.UP che legge i dati mediante API di Windows. I dati si presentano in una matrice
  2. Una delle colonne è la data di ultima modifica
  3. Poiché la data è un oggetto riconosciuto chiedo la persona addetta all’Help Desk per quella data.
  4. Alcune persone hanno una matricola come dipendenti
  5. Chiedo ad un server che gestisce i cedolini le ore di ferie residue per ogni persona. Filtro i soli dipendenti, trasformo la matrice in un file XLS e invio la mail a un referente.
  6. Accedo al dettaglio della persona, chiedo l’indirizzo, e chiedo di presentare la mappa di Google del luogo dove risiede

Ho letto dati su server diversi, utilizzando servizi scritti in linguaggi diversi, presentando i dati in forma diversa.

Tutto ciò fornisce alcuni vantaggi (a coloro che sono consapevoli della complessità delle esigenze):

  • Sostituibilità di un componente
  • Riutilizzo di funzioni e/o dati esistenti
  • Disegno dell’interfaccia che si adegua alle esigenze e ai device e può cambiare nel tempo

Una volta dicevamo che Sme.UP è ecologico.

  • Si può sostituire un pezzo senza buttare il tutto
  • Si possono aggiungere pezzi ad un sistema funzionante
  • Si possono riutilizzare i pezzi già esistenti