EN | IT | ES | DE

Architettura

MySirt è una Execution Engine model-centric basato su un execution meta-model. I sistemi informativi sono derivati da definizioni formali e rimangono strutturalmente allineati a tali definizioni nel tempo. L’architettura è organizzata per mantenere il comportamento deterministico, ispezionabile e rigenerabile, evitando la deriva tipica dell’implementazione funzionalità per funzionalità.

Stratificazione architetturale

Il motore è suddiviso in livelli stabili. Ogni livello ha una singola responsabilità ed espone un comportamento deterministico: modelli equivalenti producono risultati strutturali equivalenti.

DSL (Specifica formale) Entità · Ruoli · Regole · Workflow · Responsabilità Model Interpreter Analizza le definizioni · risolve le dipendenze · valida la struttura System Derivation Layer Deriva strutture eseguibili dal modello Rule Execution Applica decisioni · validazioni · responsabilità Ambiente operativo runtime Strutture dati · viste UI · workflow · comportamento di sicurezza Struttura deterministica: modelli equivalenti producono comportamento operativo equivalente.

DSL come specifica eseguibile

MySirt utilizza una DSL dichiarativa, basata su testo, per definire la struttura del sistema, il comportamento operativo e le regole organizzative. La DSL non è un artefatto documentale: è la specifica autorevole interpretata dal motore. La validità strutturale e i vincoli comportamentali sono valutati rispetto alla definizione del modello, non rispetto a funzionalità implementate manualmente.

Specifica completa della DSL MySirt

La DSL completa di MySirt non viene intenzionalmente divulgata pubblicamente per tutelare la proprietà intellettuale.

La documentazione pubblica spiega i principi architetturali, il modello di esecuzione e le basi concettuali del linguaggio senza esporne la sintassi completa o estratti rappresentativi.

Le specifiche dettagliate del linguaggio sono disponibili solo durante il processo di valutazione tecnologica e, dove opportuno, sotto condizioni di riservatezza.

Rigenerazione strutturale

Le modifiche al modello attivano una rigenerazione coerente delle strutture dipendenti. Il sistema rimane allineato alla definizione per progettazione: le modifiche applicate a livello di modello si propagano in modo deterministico alle strutture generate, preservando coerenza comportamentale e strutturale nel tempo.

Il processo di rigenerazione è strutturale e non cosmetico: preserva l’integrità del contratto del modello e previene derive accidentali tra componenti non correlati.

Punti di estensione (integrazione codice custom)

Comportamenti personalizzati possono essere collegati a punti di estensione definiti senza compromettere la rigenerazione. Componenti generati e manuali possono coesistere entro confini espliciti: il modello rimane la fonte autorevole della struttura, mentre il codice esterno è vincolato a specifici punti di integrazione.

Questa separazione supporta la manutenibilità nel lungo periodo: le strutture rigenerate restano coerenti e le integrazioni esterne rimangono tracciabili e sostituibili.

Traceability Layer

MySirt fornisce tracciabilità nativa a livello di Execution Engine. I sistemi generati possono includere meccanismi integrati per il monitoraggio delle modifiche ai dati e degli accessi al sistema, in base alla configurazione del modello. La tracciabilità non è implementata a livello applicativo ma derivata automaticamente dalla Execution Engine.

Due componenti complementari forniscono questa capacità:

  • Audit Trail — registra le modifiche ai dati delle entità (INSERT, UPDATE, DELETE) insieme all’utente responsabile e al timestamp esatto dell’evento, preservando sia il delta della modifica sia lo snapshot completo del record.
  • Access Log — registra eventi di autenticazione come LOGIN_SUCCESS, LOGIN_FAILED e LOGOUT insieme all’indirizzo IP di origine.

L’audit engine memorizza sia il delta della modifica sia lo snapshot completo del record coinvolto, consentendo la ricostruzione completa dello stato del sistema in qualsiasi momento.

Il comportamento di auditing è configurabile a livello di modello. La definizione del sistema può abilitare l’audit globalmente, mentre le singole entità possono adottare strategie diverse in base alle esigenze operative.

  • Basic auditing — registra che una modifica è avvenuta senza memorizzare i dettagli dei campi.
  • Delta auditing — registra i campi specifici modificati insieme ai valori precedenti e nuovi.
  • No auditing — le entità che non richiedono tracciabilità possono essere escluse.

Questa configurazione a livello di modello consente di bilanciare tracciabilità, costo di storage e performance, applicando auditing dettagliato solo dove necessario.

Audit Trail event list showing entity operations

Audit Trail – Lista eventi: i sistemi generati forniscono una vista ricercabile degli eventi registrati.

Audit Trail event detail showing delta and snapshot

Audit Trail – Dettaglio evento: ogni evento espone metadati operativi e lo snapshot strutturale dell’entità coinvolta.

Access log showing login success, login failed and logout events

Access Log – Eventi di autenticazione: l’attività di accesso è tracciata separatamente dalle modifiche ai dati.

Limiti ingegneristici attuali

  • Layer frontend basato su un framework web precedente, sostituibile senza impattare il core Execution Engine.
  • Libreria proprietaria di accesso al database (documentata), sostituibile al livello di integrazione.
  • Miglioramenti in corso focalizzati sulla formalizzazione e coerenza del contratto del modello.

Questi vincoli non alterano il modello di esecuzione: l’architettura core rimane basata sull’execution meta-model e deterministica.