vai al contenuto principale

Panoramica di Livebase

In questa panoramica vediamo i concetti chiave che ruotano attorno al modello, alle Cloudlet Livebase e al ciclo modellazione-generazione-manutenzione.

Livebase è una piattaforma di sviluppo low-code che offre potenti strumenti di modellazione, generazione di codice e lifecycle management per realizzare da zero applicazioni database gestionali in modo semplice, veloce e sicuro.

Il modello #

Sviluppare un’applicazione con Livebase vuol dire realizzare un diagramma delle classi UML “speciale”, che prende il nome di modello. Esso è un diagramma concettuale che descrive la business logic dell’applicazione su diversi livelli di astrazione, e che viene tradotto da Livebase non solo in un database, ma anche in tutta la logica applicativa coinvolta nelle letture e scritture dei dati rappresentati.

Example diagram

Un modello Livebase.

Nel modello, tutto ruota intorno ai dati: classi, attributi e relazioni definiscono la struttura del dato, mentre altri aspetti - come le form - definiscono la rappresentazione del dato, e altri ancora definiscono i permessi sul dato. PoichÊ sarebbe complicato rappresentare tutte queste informazioni contemporaneamente, il modello è dotato di diverse viste trasparenti, dette schema;

ogni schema consente al modellatore di concentrarsi su uno specifico aspetto dell’applicazione, senza mai perdere di vista il diagramma delle classi.

Gli schema #

Gli schema piĂš importanti sono di tre tipi: Database Schema , Application Schema e Profile Schema .

Schemas gif

La rappresentazione a “livelli trasparenti”, migliora la leggibilità del modello, favorisce la separazione degli interessi e permette allo sviluppatore di navigare la gerarchia di informazioni con la sensazione di guardare fondamentalmente sempre lo stesso diagramma.

Partizionamento: Database Schema

Il Database Schema è il cuore del modello. Istruisce Livebase su come generare il database relazionale, descrivendone la struttura concettuale in termini di classi, attributi, relazioni, vincoli d’integrità e restrizioni dei domini dei dati. Il Database Schema è unico e da esso dipendono tutti gli altri livelli della gerarchia.

Partizionamento: Application Schema

Gli Application Schema consentono di realizzare il partizionamento del database. Ciascuno di essi gestisce un sotto-dominio del modello, ovvero una selezione di classi, attributi e relazioni; nella vista applicativa che ne risulta, il resto del modello è completamente oscurato e inaccessibile, come se non esistesse. È inoltre possibile definire dei filtri per escludere certi oggetti dalla vista e restringere ulteriormente la porzione di database gestita. Gli Application Schema descrivono anche l’aspetto dell’interfaccia utente e la rappresentazione dei dati.

Partizionamento: Profile Schema

I Profile Schema descrivono i grant (diritti) che gli utenti con quel profilo hanno nel sistema. Un profilo può essere abilitato o meno ad accedere a un insieme di viste applicative, e per ciascuna vista/Application schema è possibile specificare i diritti di lettura e modifica sugli oggetti resi accessibili dalla vista. Lo schema che consente di configurare questi diritti per la coppia profilo-vista applicativa è detta Permission Schema . Un profilo può inoltre essere abilitato per aspetti generali, come la configurazione del sistema o la gestione degli utenti.

Di default, nei nuovi modelli sono definiti un solo Application Schema (Application) con tutte le classi abilitate, e due Profile Schema: Member e Guest; non essendoci alcun partizionamento, gli utenti hanno accesso a tutto il modello con pieni diritti di lettura e scrittura.

Altri schema che non trattiamo nel tutorial sono i seguenti:

  • Localization Schema : definisce le stringhe di localizzazione di tutti gli elementi del modello rispetto a una lingua supportata. Al momento le lingue supportate sono italiano e inglese .
  • Report Schema : definisce un template per generare report di vario tipo (tabellare, a campi incrociati, etc.) sui dati del modello.

Il Designer #

Il Designer è l’ambiente di modellazione di Livebase; lo useremo per realizzare classi e relazioni e navigare la gerarchia degli schema.

Designer Livebase

Il Designer Livebase.

In ogni momento, il Designer controlla ogni modifica che il modellatore effettua e valuta le loro ripercussioni nella gerarchia degli schema; è pertanto virtualmente impossibile disegnare modelli inconsistenti. Questo aspetto è molto importante soprattutto nella manutenzione di modelli pre-esistenti.

Il Designer è uno strumento incluso nella Dashboard, che vediamo a breve. Alla fine del corso avremo esplorato gran parte dei suoi strumenti e funzioni.

L’applicazione generata e la Cloudlet #

A partire dal modello, Livebase genera automaticamente tutto lo stack applicativo necessario al corretto funzionamento del sistema, senza richiedere ulteriore configurazione. Nel dettaglio, il risultato della modellazione è:

  • un database relazionale (MariaDB), opportunamente normalizzato e ottimizzato;
  • un engine applicativo (in linguaggio Java) corredato di servizi di lettura e scrittura sul database, autenticazione, gestione degli utenti e della concorrenza, viste applicative, logging, etc.;
  • un client web (basato sul framework GWT) pre-configurato con le personalizzazioni dell’interfaccia definite nel modello;
  • una API REST tradizionale e una API GraphQL mappate sugli elementi del modello;
  • una libreria di interfacce di sviluppo Java mappate sugli elementi del modello per realizzare Plugin.

Tutto questo stack - database incluso - risiede in un server virtuale autonomo che prende il nome di Cloudlet. Una Cloudlet è un sistema multi-utente con un indirizzo URL, che consente di accedere al client e alle interfacce; la maggior parte di queste risorse è protetto e richiede autenticazione.

Il Client #

Il client web in dotazione con le applicazioni Livebase è pensato per essere un back-office aziendale; può essere usato da amministratori e personale interno per gestire i propri dati e/o ottenere informazioni utili su di essi, grazie a potenti strumenti di esplorazione come la Livetable. Nel corso approfondiremo il client e questi strumenti, e li useremo per testare l’effettivo funzionamento dei requisiti modellati.

API e Plugin #

Le API generate dal sistema sono due: REST e GraphQL; entrambe vengono mappate sulle risorse dichiarate nel modello, e consentono (previa autenticazione) di interrogare l’applicazione generata per leggere e scrivere dati, con le stesse politiche modellate nei Profile Schema e usate dal client web. In particolare, la API GraphQL offre un linguaggio di interrogazione fortemente tipato per soddisfare query complesse in modo flessibile.

Cloudlet Stack

Le API della Cloudlet consentono l’accesso all’applicazione senza passare per il client grafico. Questo consente di interfacciare la Cloudlet con altri sistemi esterni all’organizzazione, e rendono possibile realizzare client web custom da includere tra le risorse dell’applicazione Livebase.

I Plugin sono invece estensioni custom della logica applicativa. Gli sviluppatori possono usare le librerie generate per scrivere Plugin e agganciarli all’engine applicativo; queste estensioni vengono richiamate durante l’esecuzione di alcune operazioni note (come durante il salvataggio di un oggetto), e consentono di eseguire codice arbitrario sfruttando il contesto d’esecuzione dell’applicazione (come oggetti in memoria, connessioni aperte al database) o altri servizi offerti dal framework dell’engine applicativo.

La Dashboard #

La Dashboard è l’ambiente di amministrazione di modelli e Cloudlet. Da qui possiamo aprire il Designer per visualizzare, creare o modificare modelli; possiamo inoltre gestire tutto il ciclo di vita delle Cloudlet: creazione, avvio/arresto e demolizione.

Dashboard Livebase

La Dashboard Livebase.

Nella Dashboard, il proprietario di una Cloudlet può:

  • gestire i membri, crearne di nuovi e assegnare loro profili utente per accedere all’applicazione generata;
  • gestire le risorse da assegnare alle sue Cloudlet (dimensione del database o del file storage, larghezza di banda, etc.) dal resource pool disponibile per il suo piano;
  • gestire il database e il modello corrente.

Di default, Livebase effettua automaticamente il deploy delle nuove Cloudlet sul nostro hosting cloud; Cloudlet dispiegate in questo modo hanno già a disposizione un URL pubblico, nel formato <ServerNumber>.fhoster.com/<AccountName>/<CloudletName>, dove <AccountName> è lo username dell’account proprietario della Cloudlet.

Flusso di lavoro Livebase #

Per creare da zero un’applicazione Livebase è sufficiente:

  1. creare un modello in libreria;
  2. creare una Cloudlet;
  3. trascinare il modello sulla Cloudlet per installarlo;
  4. avviare la Cloudlet.

Creazione Cloudlet

Creazione di un’applicazione Livebase.

Livebase genera tutto lo stack applicativo descritto sopra ogni volta la Cloudlet viene avviata con un nuovo modello. Se non è presente un database, anch’esso viene creato da zero. Una volta generato il codice al primo avvio, la Cloudlet può essere arrestata e riavviata più rapidamente.

Ciclo di sviluppo #

In qualunque momento, una Cloudlet in esecuzione può essere arrestata e il suo engine può essere sostituito con un altro modello o aggiornato modificandolo nel Designer. Questa operazione è detta manutenzione evolutiva e rende possibile apportare modifiche a un’applicazione Livebase esistente minimizzando il rischio di perdere i dati memorizzati nel pre-esistente database.

Lo sviluppo di applicazioni Livebase è quindi un ciclo composto di tre fasi: modellazione, allineamento e rigenerazione:

Gestione Cloudlet

Ciclo di sviluppo di un’applicazione Livebase.

  1. Quando un modello/engine installato su una Cloudlet viene aperto e modificato nel Designer, Livebase controlla le modifiche effettuate dall’utente tenendo conto della struttura corrente del database e dei dati memorizzati in esso.

  2. Quando l’utente salva le modifiche, Livebase elabora un piano d’intervento per aggiornare database e applicazione individuando e catalogando eventuali disallineamenti con i dati esistenti e la struttura del database:

    • se si tratta di cambiamenti di basso impatto (low issue), è possibile riavviare la Cloudlet senza problemi;
    • in presenza di disallineamenti che comporterebbero perdite di informazioni (medium issue), Livebase chiede all’utente di rivedere le modifiche e dare conferma esplicita prima di procedere;
    • nel caso di problemi ancora piĂš gravi (high issue) che non sono risolvibili automaticamente e che renderebbero i dati pre-esistenti inconsistenti, Livebase impedisce di avviare la Cloudlet e obbliga l’utente a risolvere manualmente gli errori sul Designer.
  3. Concluso l’allineamento col database, è possibile riavviare la Cloudlet. A questo punto, tutte le parti dell’applicazione coinvolte dalle modifiche vengono rigenerate.

Durante il corso effettueremo numerosi interventi di manutenzione evolutiva e affronteremo tutti i diversi scenari che abbiamo elencato.

Nella prossima lezione… #

Descriviamo i requisiti del sistema gestionale che guiderĂ  la modellazione: Scenario di esempio.