ITTO20130133A1 - Metodo per la realizzazione di specificazioni di sistemi software, in particolare di tipo oltp-app, e relativo dispositivo - Google Patents

Description

“METODO PER LA REALIZZAZIONE DI SPECIFICAZIONI DI SISTEMI SOFTWARE, IN PARTICOLARE DI TIPO OLTP-APP, E RELATIVO DISPOSITIVOâ€

DESCRIZIONE

La presente invenzione si riferisce ad un metodo nel campo della definizione e della realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App (“On Line Transaction Processing-Application†), senza limitazione alcuna del campo potenziale di espressività logica, e dunque applicabile a qualunque dominio semantico e a qualunque requisito funzionale, per quanto estesi e complessi essi possano risultare.

È noto che l’obiettivo di definire un formato sintattico completo e universale per la specificazione di un sistema software, che consenta di automatizzare la successiva fase di programmazione senza ulteriore necessità di intervento umano, à ̈ perseguito da tempo, sia dall’accademia che dall’industria, con aspettative teoriche di efficienza e di produttività di volta in volta tanto più elevate, quanto più deludenti si sono rivelati fino ad ora gli esiti conseguiti in campo pratico. Sono stati finora utilizzati due distinti approcci al problema. Il primo approccio à ̈ quello dei generatori di codice (comunemente detti “Code Generators†, ad esempio Telon di CA Technologies) che persegue una “approssimazione verticale†, privilegiando l’obiettivo di automatizzare completamente la scrittura del codice-sorgente finale, ma limitando l’ampiezza del campo espressivo ad una biblioteca preconfezionata di moduli logici, selezionati in base al loro indice statistico di ricorrenza. La pratica ha dimostrato che un requisito reale non à ̈ però mai totalmente riconducibile alla parametrazione e all’assemblaggio di moduli logici standardizzati, per quanto ampia e aggiornata sia la biblioteca a disposizione. Dunque, nei sistemi sviluppati con i generatori di codice, à ̈ necessario integrare il codice prodotto automaticamente con codice prodotto manualmente, con elevati oneri di integrazione, bassa consistenza logica e proliferazione incontrollata del numero di righe di codice.

Il secondo approccio à ̈ quello degli strumenti automatici di supporto alla progettazione (comunemente detti “CASE Tools†, ad esempio StP di Atego), che perseguono invece una “approssimazione orizzontale†, privilegiando l’obiettivo di garantire universalità espressiva, ma sacrificando la profondità di dettaglio della specificazione. La pratica ha dimostrato che la programmazione manuale della logica di dettaglio, che si rende necessaria per completare quella di alto livello, à ̈ però altamente “time-consuming†, e dunque la produzione di sistemi specificati con tale approccio non costa meno di quella di sistemi specificati tradizionalmente per la programmazione totalmente manuale.

Inoltre, sia il primo sia il secondo approccio appena descritti, non sono adeguati per minimizzare il numero di righe di codice, proprio perché la codifica manuale, necessaria in entrambi i casi, non à ̈ supportata da un deposito centralizzato e normalizzato di “moduli logici atomici†(ad esempio i cosiddetti “code-repository†), da intendersi come unità ultime e indivisibili di comportamento dell'applicazione: alla progressiva insorgenza di requisiti si risponde con la creazione di un blocco di codice “ad hoc†, senza alcuno strumento formale che garantisca intrinsecamente la nonduplicazione di codice già scritto: l'indisponibilità di un code-repository impedisce di ottimizzare il tasso di riuso del codice già scritto, e la quantità totale di codice (per convenzione definita “numero di righe di codice†) non risulta intrinsecamente minimizzata.

È noto che tutti i sistemi software necessitano di un controllo di versione (comunemente detto “versioning†), di natura sia cronologica (evoluzione nel tempo dello stato del codice) che geografica (compresenza di diversi stati del codice in funzione dei diversi utenti, a parità di versione cronologica).

Allo stato dell’arte, peraltro, la nozione di 'variazione' (ossia di insorgenza di una 'nuova versione') à ̈ aleatoria e discrezionale: ciò dipende dal fatto che non esiste alcuna definizione di 'unità di misura di variazione' formale, metrica e universale, sulla base della quale, a fronte di una qualunque modifica del codice, si possa effettuare una 'misura metrica della quantità di variazione' introdotta, definendo oggettivamente e insindacabilmente se sia o no insorta una 'nuova versione', a seconda che la quantità di variazione introdotta superi o no una prefissata 'soglia di variazione', ovviamente anch'essa espressa in 'unità di misura di variazione'.

Le metriche software note nell’arte si fondano sulla definizione del cosiddetto puntofunzione (anche detto “UFP†o “Unadjusted function point†), inteso quale 'unità di misura di peso' del software. Tali punti-funzione hanno l’obiettivo di misurare le funzionalità che l'utente riceve e richiede, misurare i risultati dello sviluppo e/o la manutenzione del software indipendentemente dalla tecnologia utilizzata e fornire una misura che sia coerente tra progetti e produttori differenti. Gli attuali metodi di misurazione della dimensione funzionale riconosciuti come standard internazionali sono legati alla rilevazione e pesatura dei "movimenti di dati" e degli "archivi logici" ed escludono ogni valutazione della complessità e numero di algoritmi, ovvero di componenti di manipolazione dei dati. Inoltre, in alcuni casi, sono gli stessi programmatori/tecnici a calcolare manualmente i punti-funzione di un software, aumentando considerevolmente i costi di gestione dello stesso.

Un ultimo aspetto importante da considerare à ̈ la realizzazione del piano di test funzionale del software. Attualmente sono previsti alcuni standard di test, ad esempio lo standard IEEE 829-2008, i quali richiedono tutti un pesante intervento manuale per la redazione del piano di test.

Scopo della presente invenzione à ̈ pertanto quello di indicare un metodo e un dispositivo universalmente e completamente espressivi per la realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, che permetta di minimizzare il numero di righe di codice, e di renderne possibile la produzione in modalità totalmente automatica.

Un secondo scopo della presente invenzione à ̈ inoltre quello di indicare un metodo e un dispositivo universalmente e completamente espressivi per la realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, che permetta di automatizzare il controllo di versione, sia cronologico sia geografico.

Un terzo scopo della presente invenzione à ̈ quello di indicare un metodo e un dispositivo universalmente e completamente espressivi per la realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, che permetta di automatizzare il calcolo dei punti-funzione del codice.

Un ulteriore scopo della presente invenzione à ̈ quello di indicare un metodo e un dispositivo universalmente e completamente espressivi per la realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, che permetta di ottenere in modo automatico, logicamente completo e operativamente esaustivo il piano di test funzionale.

Questi ed altri scopi dell’invenzione vengono ottenuti con un metodo ed un dispositivo per la realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, come rivendicati nelle unite rivendicazioni che costituiscono parte integrante della presente descrizione.

In sintesi, viene descritto un metodo e un dispositivo per la realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, detto metodo prevedendo che un flusso di processo dichiarativo permetta di decomporre e di ridurre una specificazione complessiva di una qualunque OLTP-app in unità informative atomiche, rappresentabili sotto forma di t-uple di valori di tabelle di uno schema di relazione in Terza Forma Normale, o di qualunque altro schema di relazione ad esso semanticamente equivalente, sempreché aderente alla Terza Forma Normale.

Gli scopi suddetti risulteranno maggiormente chiari dalla descrizione dettagliata di un metodo per la realizzazione di OLTP-App, secondo la presente invenzione, con particolare riferimento alle Figure allegate in cui:

- la Figura 1a illustra un esempio di forma di realizzazione di un dispositivo secondo la presente invenzione;

- la Figura 1b illustra una possibile forma della sintassi topologica e di notazione relativa ai grafi delle figure successive;

- la Figura 2 mostra un flusso di processo del metodo secondo la presente invenzione; - le Figure 3a, 3b, 3c, 3d e 3e illustrano un esempio di schema di relazione in sintassi ERD (“Entity Relationship Diagram†);

- la Figura 4 mostra una corrispondenza fra alcune frasi dichiarative ammesse e le corrispondenti tabelle alimentate;

- le Figure 5a e 5b illustrano ulteriori flussi di processo del metodo secondo la presente invenzione;

- la Figura 6 mostra una ulteriore corrispondenza fra frasi dichiarative ammesse e le corrispondenti tabelle alimentate;

- la Figura 7 illustra un ulteriore flusso di processo del metodo secondo la presente invenzione;

- la Figura 8 mostra una ulteriore corrispondenza fra frasi dichiarative ammesse e le corrispondenti tabelle alimentate;

- la Figura 9 illustra una matrice di ammissibilità di tipi di frase logica in funzione dei tipi di connessione semantica di invocazione.

Un esempio di documento di specificazione, o requisito, espresso in formato linguistico libero può essere il seguente:

“La società utente à ̈ un soggetto giuridico a capitale diffuso (circa 2.000.000 di soci), ed à ̈ tenuta alla compilazione e alla tenuta di un Libro Sociale, eventualmente anche in formato elettronico, riportante gli ingressi e le uscite dei soggetti che acquisiscono o perdono la qualità sociale; a ogni ingresso / uscita di un soggetto deve corrispondere una scrittura separata e individuale; nella stessa giornata non può aversi più di una scrittura, di ingresso o di uscita, in capo allo stesso soggetto. I soggetti possono essere sia persone fisiche PF che persone giuridiche PG, e per ciascun ingresso e ciascuna uscita di ciascuno di essi vanno riportati nella scrittura un codice sociale univoco del soggetto entrante / uscente, l’identificativo fiscale (Codice Fiscale per le PF, Partita Iva per le PG), la data di origine (data di nascita per le PF, data di costituzione per le PG), le generalità onomastiche (nome e cognome per le PF, ragione sociale per le PG), la data di ingresso / uscita dalla compagine sociale. Gli ingressi e le uscite sono generati da movimenti azionari di trasferimento di azioni fra soggetti diversi, univocamente identificati dall’anno della loro inizializzazione e da un progressivo univoco a parità di anno (il numero di movimenti / anno à ̈ dell’ordine di 150.000): tale univoca identificazione deve essere riportata nelle scritture del Libro Sociale. La data di ingresso / uscita deve essere assunta eguale alla data di regolamento del movimento generante. Alcuni tipi di movimento possono generare l’ingresso e/o l’uscita contestuale di più soggetti, fino a un massimo di 5 ingressi e 5 uscite: altri tipi di movimento non generano alcun ingresso né alcuna uscita. PF minorenni non possono accedere alla compagine sociale. Le PF socie escono automaticamente dalla compagine sociale nella data del loro eventuale decesso, le PG socie nella data del loro eventuale scioglimento.â€

Si supponga quindi che un analista abbia pienamente acquisito detto requisito di una OLTP-App, e abbia formalizzato tale conoscenza in tale documento.

Con riferimento alla Fig. 1a, detto documento, attraverso un processo dichiarativo, viene riscritto in un secondo documento (chiamato nel seguito anche SPECIFICAZIONE-REM) comprendente un linguaggio formale atto a essere riconosciuto da dispositivi di lettura automatica 200 che implementano il metodo secondo l’invenzione.

Il dispositivo di lettura e scrittura automatica 200 potrebbe essere, ad esempio un “parser†evoluto, il quale comprende un prodotto software che provvede all’interpretazione preliminare di una SPECIFICAZIONE-REM (lettura e interpretazione), alla sua verifica sintattica (correzione e validazione), e in caso di esito positivo della verifica sintattica, alla sua definitiva trasformazione automatica in codice-sorgente equivalente (scrittura del codice-sorgente).

Il dispositivo di lettura e scrittura automatica 200 opera attraverso il processo dichiarativo che prevede una fase di STATICA (anche detta “layer persistente†, o FONDAZIONE ONTOLOGICA), e una fase di configurazione antropologica, la quale procede poi con lo sviluppo in parallelo di una sotto-fase di DINAMICA (anche detta “layer conversazionale†, o conversazione uomo-macchina), e di una sotto-fase di LOGICA (anche detta “layer logico†, o predicazione logica).

Detto dispositivo di lettura e scrittura automatica 200 comprende mezzi di lettura sintattica 201 atti ad interpretare la SPECIFICAZIONE-REM , un elaboratore 203 atto a controllare ed elaborare tutte le operazioni necessarie alla lettura e scrittura automatica. Detto dispositivo di lettura e scrittura automatica 200 comprende inoltre mezzi di memoria 205 atti a memorizzare i dati derivanti dalla lettura della SPECIFICAZIONE-REM . Tali mezzi di memoria 205 possono comprendere il “layer persistente†del dispositivo, ad esempio un database relazionale.

Infine, il dispositivo di lettura e scrittura automatica 200 comprende ulteriormente un generatore di codice-sorgente 207 atto a porre in uscita un codice-sorgente che implementa la SPECIFICAZIONE-REM del requisito di una OLTP-App.

Per “layer persistente†si intende un insieme di componenti strutturali persistenti di una OLTP-App, che risultano indipendenti dai programmi, e che possono essere programmate con esclusivo ricorso alla sintassi della programmazione di database relazionali, in particolare il linguaggio SQL (“Structured Query Language†) ASCII (“American Standard Code for Information Interchange†) standard.

Per “FONDAZIONE ONTOLOGICA†si intende che la SPECIFICAZIONE-REM del “layer persistente†di una OLTP-App à ̈ ottenuta applicando iterativamente il TEOREMA DI FONDAZIONE ONTOLOGICA e la REGOLA DI RIDUZIONE ONTOLOGICA.

Il TEOREMA DI FONDAZIONE ONTOLOGICA prevede che una categoria predicativa à ̈ ontologicamente fondata se e soltanto se esiste almeno un EVENTO di creazione, appartenente al CAMPO DI PERCEZIONE, i cui ACCADIMENTI siano rappresentabili a mezzo della creazione di una ed una sola t-upla della relazione che la rappresenta (ad esempio, l’inserimento di uno ed un solo record in una tabella), e che tale relazione (la tabella) aderisca alla “Terza Forma Normale†o 3NF. Di conseguenza tutte le categorie predicative rappresentate nel “layer persistente†di una OLTP-App debbono essere ontologicamente fondate, ovvero gli ELEMENTI di una categoria logica priva di FONDAZIONE ONTOLOGICA risulterebbero privi di un processo di misurazione atto ad individuarli e a qualificarli singolarmente senza interazione con ELEMENTI di altre categorie logiche, e dunque non potrebbero rappresentare stati di realtà.

Per CAMPO DI PERCEZIONE si intende l’insieme degli ACCADIMENTI che l’utente ritiene utile notificare al “layer persistente†, a fini di futura memoria certa, reperibile e asseverata. Il CAMPO DI PERCEZIONE à ̈ definito a discrezione di un utente, sulla base di un criterio di utilità, ed à ̈ parte integrante del requisito. Una OLTP-App può pertanto essere omologata ad un organismo artificiale dotato di un “sistema sensoriale†selettivamente ed esclusivamente finalizzato allo scopo della sua stessa esistenza: i “sensi†di una OLTP-App sono i programmi per mezzo dei quali gli ACCADIMENTI di interesse sono “percepiti†(dichiarati conversazionalmente) e “memorizzati†(registrati su database).

Per REGOLA DI RIDUZIONE ONTOLOGICA si intende che qualunque tipologia di ACCADIMENTO del CAMPO DI PERCEZIONE, che non goda del requisito di EVENTO, Ã ̈ riducibile ad una successione di EVENTI che affliggono solo ENTI ontologicamente fondati, ad esempio rappresentabile da una rete di Petri condizionata di peso 1, detta CASCATA.

A parità di CAMPO DI PERCEZIONE, tale area di specificazione à ̈ indipendente dall’ambiente storico, economico, sociale, culturale, organizzativo, regolamentare, operativo, o psicologico, dell’utente, in quanto esclusivamente rappresentativo degli ACCADIMENTI degli EVENTI appartenenti al CAMPO DI PERCEZIONE stesso. Con riferimento alla Fig. 1b, viene illustrata una possibile forma della sintassi topologica e di notazione relativa ai grafi delle figure successive.

Le fasi e le sotto-fasi del processo dichiarativo comprendono una dichiarazione di frasi, la cui struttura sintattica à ̈ tipizzata e la cui successione à ̈ normata e controllata da un flusso di processo; i tipi di frase dichiarativa ammessa, e per ciascuno di essi il formato sintattico e le norme di scrittura, sono censiti e dettagliati nel seguito.

La fase di STATICA consiste nell’individuazione di EVENTI appartenenti al CAMPO DI PERCEZIONE di una OLTP-App, e nella valorizzazione di attributi e di relazioni che li connotano. Tale identificazione e qualificazione degli EVENTI definisce pienamente e univocamente il “layer persistente†della OLTP-App, ossia, ad esempio, una base di dati (“DB†, o Schema di Relazione).

Le dichiarazioni di specificazione relative alla fase di STATICA devono procedere attraverso il grafo del flusso di processo rappresentato in Fig.2.

Con riferimento alle Figg. 3a, 3b, 3c, 3d e 3e, viene illustrato un diagramma ERD (“Entity-Relationship Diagram†) diviso in cinque fogli collegati attraverso la numerazione di riferimento che comprende le seguenti relazioni di connessione:

'1_Ã ̈_affetto_da' dal foglio 3a al foglio 3c;

'7_contiene' dal foglio 3a al foglio 3b;

'8_appartiene_a' dal foglio 3a al foglio 3b;

'9_ammette_il_valore' dal foglio 3a al foglio 3b;

'10_Ã ̈_discriminata_da' dal foglio 3a al foglio 3b;

'13_Ã ̈_aggiornata_da' dal foglio 3a al foglio 3c;

'18_condiziona_in_ingresso' dal foglio 3e al foglio 3c;

'19_condiziona_in_uscita' dal foglio 3e al foglio 3c;

'22_condiziona_in_lancio' dal foglio 3e al foglio 3c;

'23_Ã ̈_in_corso_di_conversazione' dal foglio 3c al foglio 3d;

'24_Ã ̈_in_corso_di_aggiornamento' dal foglio 3c al foglio 3d;

'25_condiziona_obbligatorietà' dal foglio 3e al foglio 3d;

'26_condiziona_automaticità' dal foglio 3e al foglio 3d;

'27_condiziona_persistenza' dal foglio 3e al foglio 3d;

'28_calcola_valore' dal foglio 3e al foglio 3d;

'29_calcola_default' dal foglio 3e al foglio 3d;

'32_subisce_il_vincolo_di_aggiornamento' dal foglio 3c al foglio 3d;

'34_Ã ̈_profilato_da' dal foglio 3a al foglio 3b;

'36_Ã ̈_filtro_di_selezione_in' dal foglio 3a al foglio 3b;

'37_definisce_navigazione_di_selezione' dal foglio 3e al foglio 3b;

'39_Ã ̈_visualizzata_in' dal foglio 3a al foglio 3b;

'40_definisce_navigazione_di_visualizzazione' dal foglio 3e al foglio 3b.

È chiaro che il diagramma ERD illustrato nelle Figg. 3a, 3b, 3c, 3d e 3e rappresenta solo un esempio; infatti, à ̈ possibile riferirsi a qualunque altro schema ERD che risulti ad esso semanticamente equivalente.

In particolare, le Figg. 3a, 3b e 3c raffigurano, ad esempio, le seguenti tabelle che si riferiscono alla fase di STATICA:

1_EVENTI;

2_ENTI;

3_PROPRIETÀ;

4_RELAZIONI;

5_CHIAVI;

6_PROPRIETÀ_DI_CHIAVE;

7_PROPRIETÀ_A_DOMINIO_CHIUSO;

8_VALORI_DISCRIMINANTI;

10_PROPRIETÀ_AGGIORNATE.

La corrispondenza fra ciascuna frase dichiarativa ammessa (e dunque mappata nel grafo di Fig.2), e la corrispondente tabella alimentata, Ã ̈ espressa in Fig.4.

Nuovamente con riferimento alla Fig.2, ogni ciclo di esecuzione del grafo ha inizio al passo 101 relativo al CENSIMENTO EVENTO.

Per EVENTO si intende una specifica tipologia di ACCADIMENTO del CAMPO DI PERCEZIONE, intensivamente definita dall’insieme di PROPRIETÀ che subiscono valorizzazione secondo protocolli di misurazione predefiniti e stabili, rappresentabile a mezzo della creazione (EVENTO di creazione), o della modificazione (EVENTO di aggiornamento) di una ed una sola t-upla in uno ed un solo ENTE, detto “ENTE afflitto dall’EVENTO†, e pertanto implementabile in modo informatico facendo esclusivo ricorso all’inserimento (“insert†) o all’aggiornamento (“update†) di uno ed un solo record (“row†) in una ed una sola tabella (“table†).

Per PROPRIETÀ si intende un attributo logico di identificazione e/o qualificazione di un ENTE, rappresentabile a mezzo di una colonna di relazione, e pertanto implementabile in modo informatico sotto forma di attributo (“column†).

Il formato sintattico della frase dichiarativa CENSIMENTO EVENTO, di cardinalità singola “1†, à ̈, ad esempio:

“Appartiene al CAMPO DI PERCEZIONE l’EVENTO <1_1_nome_evento>, consistente nel / nella <1_2_definizione_evento>,

il quale crea [<1_3_tipo_evento> =†̃C’],

oppure

il quale aggiorna [<1_3_tipo_evento> = †̃A’]

ELEMENTI dell’ENTE <1_4_ente_affetto>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO EVENTO sono espresse nel seguito:

- <1_1_nome_evento> Ã ̈ chiave primaria (sint);

- <1_2_definizione_evento> Ã ̈ attributo obbligatorio (sint);

- <1_2_definizione_evento> deve essere una definizione vocabolariale di una generica istanza dell’EVENTO (sem);

- <1_3_tipo_evento> à ̈ attributo obbligatorio, che ammette i valori [†̃C’(†̃creazione’), †̃A’(†̃aggiornamento’)] (sint);

- <1_4_ente_affetto> Ã ̈ attributo obbligatorio, referenziato da <1_Ã ̈_affetto_da> (sint);

- L’EVENTO <1_1_nome_evento> deve referenziare, attraverso <12_aggiorna>, almeno una PROPRIETÀ dell’ENTE affetto <1_4_ente_affetto> che subisce valorizzazione per effetto delle sue istanze (sint);

- Tutte le PROPRIETÀ referenziate attraverso <12_aggiorna> dall’EVENTO <1_1_nome_evento> devono appartenere all’ENTE affetto <1_4_ente_affetto> (sint);

- L’EVENTO <1_1_nome_evento> deve referenziare, attraverso <15_à ̈_nodo_di> almeno una CASCATA nella quale ricorre quale nodo (sint). Una norma di scrittura à ̈ “sintattica†(sint) se si riferisce alla correttezza formale della specificazione (accuratezza); à ̈ “semantica†(sem) se si riferisce invece all’aderenza della specificazione allo stato di realtà rappresentato (adeguatezza). Una specificazione può essere verificata e validata per mezzo di un analizzatore automatico sotto il profilo sintattico. Per contro, le norme di scrittura semantica sono ininfluenti ai fini della trasformazione automatica di una SPECIFICAZIONE-REM in codicesorgente, effettuata da un dispositivo di tipo “parser†.

L’obbligatorietà di dichiarare l’ENTE affetto dall’EVENTO impone che, laddove l’EVENTO sotto censimento risulti il primo EVENTO di creazione dell’ENTE affetto dichiarato, si debba procedere alla contestuale dichiarazione seguente.

Al passo 103, il formato sintattico della frase dichiarativa CENSIMENTO ENTE, di cardinalità singola “1†, à ̈:

“L’ENTE <2_1_nome_ente> rappresenta <2_2_definizione_ente>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO ENTE sono espresse nel seguito:

- <2_1_nome_ente> Ã ̈ chiave primaria (sint);

- <2_2_definizione_ente> Ã ̈ attributo obbligatorio (sint);

- <2_2_definizione_ente> deve essere una definizione vocabolariale del generico ELEMENTO dell’ENTE (sem).

Per ELEMENTO si intende un elemento logico appartenente ad un ENTE, rappresentabile a mezzo di una t-upla di relazione, e pertanto implementabile in modo informatico sotto forma di record (“row†di una tabella);

- L’ENTE <2_1_nome_ente> deve referenziare, attraverso <1_à ̈_affetto_da>, almeno un EVENTO di creazione che lo affligge (sint);

- L’ENTE <2_1_nome_ente> deve referenziare, attraverso <2_contiene>, almeno una PROPRIETÀ che gli appartiene (sint);

- L’ENTE <2_1_nome_ente> deve referenziare, attraverso <6_à ̈_identificato_da>, la chiave primaria di univoca identificazione dei suoi ELEMENTI (sint);

Se l’EVENTO fonda nell’ENTE PROPRIETÀ primitive, allora al passo 105 viene eseguito il CENSIMENTO PROPRIETÀ PRIMITIVE. Il formato sintattico della frase dichiarativa CENSIMENTO PROPRIETÀ PRIMITIVE, di cardinalità molteplice “j†, à ̈:

“La PROPRIETÀ <3_1_nome_proprietà> primitiva [<3_3_flag_primitiva_migrata> = †̃P’] dell’ENTE <3_2_ente_di_appartenenza> misura <3_4_definizione_proprietà>, ammette al più <3_5_dimensione> caratteri,

à ̈ obbligatoria [<3_6_flag_ammissibilità_valore_nullo> = †̃NOT NULL’],

oppure

à ̈ facoltativa [<3_6_flag_ammissibilità_valore_nullo> = †̃NULL’],

à ̈ riempita a destra [<3_7_flag_riempimento_zeri_a_destra> = †̃S’],

oppure

non à ̈ riempita a destra [<3_7_flag_riempimento_zeri_a_destra> = †̃N’],

à ̈ riempita a sinistra [<3_8_flag_riempimento_zeri_a_sinistra> = †̃S’],

oppure

non à ̈ riempita a sinistra [<3_8_flag_riempimento_zeri_a_sinistra> = †̃N’],

à ̈ confrontabile [<3_9_flag_computabile_confrontabile> = †̃C’],

a dominio aperto [<3_16_flag_dominio_aperto_chiuso> = †̃A’],

con espressione regolare <3_18_espressione_regolare>,

oppure

a dominio chiuso [<3_16_flag_dominio_aperto_chiuso> = †̃C’],

a valori tutti non discriminanti [<3_17_flag_ruolo_di_discriminazione> = †̃N’], oppure

a dominio chiuso [<3_16_flag_dominio_aperto_chiuso> = †̃C’],

con valori discriminanti [<3_17_flag_ruolo_di_discriminazione> = †̃S’],

oppure

à ̈ computabile [<3_9_flag_computabile_confrontabile> = †̃N’],

ha precisione <3_10_precisione>,

ha equazione dimensionale <3_11_dimensionalità>,

ammette valori negativi [<3_12_flag_ammissibilità_valori_negativi> = †̃S’], oppure

non ammette valori negativi [<3_12_flag_ammissibilità_valori_negativi> = †̃N’], à ̈ assoluta [<3_13_flag_valori_assoluti_differenziali> = †̃A’],

oppure

à ̈ differenziale a base costante [<3_13_flag_valori_assoluti_differenziali> = †̃D’], oppure

à ̈ differenziale di tipo †̃data’ [<3_13_flag_valori_assoluti_differenziali> = †̃D’ e <3_14_flag_tipo_data> = †̃S’],

oppure

à ̈ differenziale di tipo †̃coordinata’ [<3_13_flag_valori_assoluti_differenziali> = †̃D’ e <3_15_flag_tipo_coordinata> = †̃S’]†.

Le norme di scrittura della frase dichiarativa CENSIMENTO PROPRIETÀ PRIMITIVE sono espresse nel seguito:

- <3_1_nome_proprietà> à ̈ chiave primaria (sint);

- <3_2_ente_di_appartenenza> Ã ̈ attributo obbligatorio, referenziato da <2_contiene> (sint);

- <3_3_flag_primitiva_migrata> à ̈ attributo obbligatorio, che ammette i valori [†̃P’, †̃M’] (sint);

- <3_3_flag_primitiva_migrata> determina se la PROPRIETÀ <3_1_nome_proprietà> sia nativa dell’ENTE di appartenenza <3_2_ente_di_appartenenza> (valore †̃P’), o sia migrata nell’ENTE di appartenenza <3_2_ente_di_appartenenza> da una relazione (valore †̃M’) (sem);

- <3_4_definizione_proprietà> à ̈ attributo obbligatorio (sint);

- <3_4_definizione_proprietà> deve essere una definizione vocabolariale dell’attributo semantico di identificazione e/o qualificazione degli ELEMENTI dell’ENTE di appartenenza <3_2_ente_di_appartenenza> (sem);

- <3_5_dimensione> Ã ̈ attributo obbligatorio a valori interi numerici (sint);

- <3_5_dimensione> determina il numero massimo di caratteri significativi disponibili per i valori della PROPRIETÀ <3_1_nome_proprietà> (sem);

- <3_6_flag_ammissibilità_valore_nullo> à ̈ attributo obbligatorio, che ammette i valori [†̃NULL’, †̃NOT NULL’] (sint);

- <3_6_flag_ammissibilità_valore_nullo> determina se il valore della PROPRIETÀ <3_1_nome_proprietà> possa risultare non noto alla creazione dell’ELEMENTO (valore †̃NULL’), o se debba essere obbligatoriamente valorizzato (valore †̃NOT NULL’) (sem);

- <3_7_flag_riempimento_zeri_a_destra> e <3_8_flag_riempimento_zeri_a_sinistra> sono entrambi attributi obbligatori, che ammettono i valori [†̃S’, †̃N’] (sint);

- <3_7_flag_riempimento_zeri_a_destra> e <3_8_flag_riempimento_zeri_a_sinistra> determinano se i valori della PROPRIETÀ <3_1_nome_proprietà> debbano essere esposti in conversazione con riempimento a zero a destra e/o a sinistra dei caratteri non significativi (valore †̃S’), o limitati ai caratteri significativi (valore †̃N’) (sem);

- <3_9_flag_computabile_confrontabile> à ̈ attributo obbligatorio, che ammette i valori [†̃N’, †̃C’] (sint);

- <3_9_flag_computabile_confrontabile> determina se la PROPRIETÀ <3_1_nome_proprietà> risulti computabile (valore †̃N’), o soltanto confrontabile (valore †̃C’); una PROPRIETÀ à ̈ computabile se e solo se l’insieme dei suoi valori ammissibili à ̈ un campo ordinato, e cioà ̈ se su di esso à ̈ definita una algebra chiusa di somma e prodotto (tipicamente, ma non esclusivamente, un insieme numerico) (sem);

- <3_10_precisione> à ̈ attributo a valori interi numerici: esso à ̈ obbligatorio se <3_9_flag_computabile_confrontabile> = †̃N’; in caso contrario non à ̈ valorizzato (sint);

- <3_10_precisione> determina, in base 10 (dieci), la caratteristica dei valori della PROPRIETÀ <3_1_nome_proprietà> (numero di cifre significative dopo la virgola) (sem);

- <3_10_precisione> non può essere maggiore di [<3_5_dimensione> - 1] (sint);

- <3_11_dimensionalità> à ̈ attributo obbligatorio se <3_9_flag_computabile_confrontabile> = †̃N’; in caso contrario non à ̈ valorizzato (sint);

- <3_11_dimensionalità> determina l’equazione dimensionale della PROPRIETÀ <3_1_nome_proprietà>, espressa in Sistema Internazionale MKSA$ (Metro-Kilo-Secondo-Ampà ̈re-Dollaro) (sem);

- <3_12_flag_ammissibilità_valori_negativi> à ̈ attributo che ammette i valori [†̃S’,†̃N’]: esso à ̈ obbligatorio se <3_9_flag_computabile_confrontabile> = †̃N’, in caso contrario non à ̈ valorizzato (sint);

- <3_12_flag_ammissibilità_valori_negativi> determina se la PROPRIETÀ <3_1_nome_proprietà> ammette valori negativi (valore †̃S’), o soltanto valori positivi o nulli (valore †̃N’) (sem);

- <3_13_flag_valori_assoluti_differenziali> à ̈ attributo che ammette i valori [†̃A’,†̃D’]: esso à ̈ obbligatorio se <3_9_flag_computabile_confrontabile> = †̃N’, in caso contrario non à ̈ valorizzato (sint);

- <3_13_flag_valori_assoluti_differenziali> determina se i valori di misurazione della PROPRIETÀ <3_1_nome_proprietà> sono assoluti (valore †̃A’), o differenziali (valore †̃D’) (sem);

È importante specificare che una PROPRIETÀ à ̈ differenziale se i suoi valori sono misurati con riferimento ad una origine dei valori assunta convenzionalmente eguale a 0, come tipicamente, ma non esclusivamente, per le date (intervalli temporali fra l’istante misurato e un istante-origine convenzionale, assunto eguale a 0), o per le localizzazioni (intervalli spaziali fra il punto misurato e un punto-origine convenzionale, assunto eguale a 0).

- <3_14_flag_tipo_data> e <3_15_flag_tipo_coordinata> sono attributi che ammettono i valori [†̃S’,’N’]: essi sono obbligatori se <3_9_flag_computabile_confrontabile> = †̃N’ e se <3_13_flag_valori_assoluti_differenziali> = †̃D’ (sint);

- <3_14_flag_tipo_data> e <3_15_flag_tipo_coordinata> determinano rispettivamente se la PROPRIETÀ a valori differenziali risulti una data (valori rispettivi: †̃S’, †̃N’), o risulti una coordinata geografica (valori rispettivi: †̃N’, †̃S’), o nessuna delle due (valori rispettivi: †̃N’, †̃N’) (sem);

- Una PROPRIETÀ <3_1_nome_proprietà> a valori differenziali non può essere contemporaneamente una data e una coordinata geografica (sint);

- <3_16_flag_dominio_aperto_chiuso> à ̈ attributo che ammette i valori [†̃A’,†̃C’]: esso à ̈ obbligatorio se <3_9_flag_computabile_confrontabile> = †̃C’; in caso contrario non à ̈ valorizzato (sint);

- <3_16_flag_dominio_aperto_chiuso> determina se il dominio valoriale della PROPRIETÀ <3_1_nome_proprietà> à ̈ libero (valore †̃A’), o se la PROPRIETÀ <3_1_nome_proprietà> ammette soltanto un insieme di valori previamente noti, e non modificabili lungo tutto il ciclo di vita della OLTP-App (valore †̃C’) (sem);

- <3_17_flag_ruolo_di_discriminazione> à ̈ attributo che ammette i valori [†̃S’,†̃N’]: esso à ̈ obbligatorio se <3_9_flag_computabile_confrontabile> = †̃C’ e se <3_16_flag_dominio_aperto_chiuso> = †̃C’, in caso contrario non à ̈ valorizzato (sint);

- <3_17_flag_ruolo_di_discriminazione> determina se uno o più dei valori ammessi per una PROPRIETÀ a dominio chiuso <3_1_nome_proprietà> giocano il ruolo di valori discriminanti (valore †̃S’), o se ciò non avviene (valore †̃N’) (sem);

- <3_18_espressione_regolare> à ̈ attributo obbligatorio se <3_9_flag_computabile_confrontabile> = †̃C’ e se <3_16_flag_dominio_aperto_chiuso> = †̃A’; in caso contrario non à ̈ valorizzato (sint);

- <3_18_espressione_regolare> determina i caratteri ammessi per ciascuna delle posizioni di notificazione dei valori della PROPRIETÀ <3_1_nome_proprietà>, e cioà ̈ la cosiddetta †̃espressione regolare’ dell’attributo informatico che implementa la PROPRIETÀ <3_1_nome_proprietà> (sem);

- a fissato ENTE <3_2_ente_di_appartenenza>, deve esistere almeno una PROPRIETÀ <3_1_nome_proprietà>, primitiva o migrata, la quale, attraverso <8_appartiene_a>, appartenga alla chiave primaria (Primary Key o “PK†) (sint);

- per tutte le PROPRIETÀ <3_1_nome_proprietà> che, attraverso <8_appartiene_a>, appartengono alla chiave primaria (“PK†), o ad almeno una chiave alternativa (Alternate Key o “AK†), deve risultare <3_6_flag_ammissibilità_valore_nullo> = †̃NOT NULL’ (sint);

- tutte le PROPRIETÀ che presentano <3_16_flag_dominio_aperto_chiuso> = †̃C’ devono referenziare, attraverso <9_ammette_il_valore>, almeno due valori ammessi (sint);

- tutte le PROPRIETÀ <3_1_nome_proprietà> che presentano <3_16_flag_dominio_aperto_chiuso> = †̃C’ e <3_17_flag_ruolo_di_discriminazione> = †̃S’ devono referenziare, attraverso [<9_ammette_il_valore> → <11_discrimina>], almeno una relazione di discriminazione (sint);

- la PROPRIETÀ <3_1_nome_proprietà> deve risultare aggiornabile, attraverso <13_à ̈_aggiornata_da>, da almeno un EVENTO (sint);

- tutte le PROPRIETÀ <3_1_nome_proprietà> che non appartengono alla chiave primaria (“PK†) né ad alcuna chiave alternativa (“AK†) debbono aderire alla Terza Forma Normale (“3NF†) (sem).

È importante specificare che una PROPRIETÀ (elementare) à ̈ in “3NF†se e solo se dipende funzionalmente dalla chiave primaria (“PK†) e da tutte le chiavi alternative (“AK†) in modo completo e non-transitivo.

Al passo 107, viene eseguito il CENSIMENTO VALORI DI DOMINIO CHIUSO se esistono PROPRIETÀ primitive a dominio chiuso.

Per 'PROPRIETÀ a dominio chiuso' si intende una PROPRIETÀ primitiva il cui insieme dei valori ammessi à ̈ noto a priori, e certamente non cambierà per tutto il ciclo di vita dell'applicazione: a titolo di esempio, la PROPRIETÀ anagrafica 'sesso' di un individuo umano potrà assumere sempre e soltanto il valore 'M' (maschio) o 'F' (femmina).

Il formato sintattico della frase dichiarativa CENSIMENTO VALORI DI DOMINIO CHIUSO, di cardinalità molteplice “v†, à ̈:

“La PROPRIETÀ primitiva confrontabile a dominio chiuso <7_1_proprietà_valorizzata> ammette il valore <7_2_valore_ammesso> con il significato di <7_3_semantica_valore_ammesso>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO VALORI DI DOMINIO CHIUSO sono espresse nel seguito:

- <7_1_proprietà_valorizzata> appartiene alla chiave primaria, ed à ̈ referenziata da <9_ammette_il_valore> (sint);

- <7_2_valore_ammesso> appartiene alla chiave primaria (sint);

- <7_3_semantica_valore_ammesso> Ã ̈ attributo obbligatorio (sint);

- <7_3_semantica_valore_ammesso> deve essere una definizione vocabolariale del significato specifico del valore ammesso <7_2_valore_ammesso> (sem); - La PROPRIETÀ <7_1_proprietà_valorizzata> deve risultare primitiva a dominio chiuso (sint);

- Il valore ammesso <7_2_valore_ammesso> deve risultare conforme al formato della PROPRIETÀ <7_1_proprietà_valorizzata>, con riferimento a dimensione e espressione regolare (sint).

Se invece l’EVENTO fonda nell’ENTE almeno una PROPRIETÀ migrata, allora al passo 109 viene eseguito il CENSIMENTO RELAZIONI. Il formato sintattico della frase dichiarativa CENSIMENTO RELAZIONI, di cardinalità molteplice “x†, à ̈:

“La relazione à ̈

identificante [<4_5_flag_tipo_relazione> = †̃I’],

oppure

elementare [<4_5_flag_tipo_relazione> = †̃E’],

oppure

di discriminazione [<4_5_flag_tipo_relazione> = †̃D’],

<4_1_nome_relazione> connette

obbligatoriamente [<4_6_flag_ammissibilità_assenza_referenziamento> = †̃NOT NULL’],

oppure

facoltativamente [<4_6_flag_ammissibilità_assenza_referenziamento> = †̃NULL’] l’ENTE referenziante <4_2_ente_referenziante> all’ENTE referenziato <4_3_ente_referenziato> nel ruolo semantico di <4_4_definizione_relazione> senza limiti di numerosità [<4_7_numerosità> = NULL],

oppure

con numerosità massima <4_7_numerosità>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO RELAZIONI sono espresse nel seguito:

- <4_1_nome_relazione> Ã ̈ chiave primaria (sint);

- <4_2_ente_referenziante> Ã ̈ attributo obbligatorio, referenziato da <3_referenzia> (sint);

- <4_3_ente_referenziato> Ã ̈ attributo obbligatorio, referenziato da <4_Ã ̈_referenziato> (sint);

- <4_4_definizione_relazione> Ã ̈ attributo obbligatorio (sint);

- <4_4_definizione_relazione> deve essere una definizione vocabolariale della connessione semantica istituita dalla relazione fra l’ENTE referenziante <4_2_ente_referenziante> e l’ENTE referenziato <4_3_ente_referenziato> (sem);

- <4_5_flag_tipo_relazione> à ̈ attributo obbligatorio, che ammette i valori [†̃I’, †̃E’, †̃D’] (sint);

- <4_5_flag_tipo_relazione> determina se la relazione <4_1_nome_relazione> à ̈ identificante (valore †̃I’: le PROPRIETÀ di chiave primaria (“PK†) dell’ENTE referenziante <4_2_ente_referenziante>, migrate dalla relazione <4_1_nome_relazione>, sono un sottoinsieme proprio delle PROPRIETÀ di chiave primaria (“PK†) dell’ENTE referenziato <4_3_ente_referenziato>), o à ̈ elementare (valore †̃E’: nessuna delle PROPRIETÀ di chiave primaria (“PK†) dell’ENTE referenziante <4_2_ente_referenziante>, migrate dalla relazione <4_1_nome_relazione>, fa parte della chiave primaria (“PK†) e/o delle chiavi alternative (“AK†) dell’ENTE referenziato <4_3_ente_referenziato>), o à ̈ di discriminazione (valore †̃D’: la chiave primaria (“PK†) dell’ENTE referenziato <4_3_ente_referenziato> à ̈ costituita da tutte e sole le PROPRIETÀ di chiave primaria (“PK†) dell’ENTE referenziante <4_2_ente_referenziante>, migrate dalla relazione <4_1_nome_relazione>) (sint);

- <4_6_flag_ammissibilità_assenza_referenziamento> à ̈ attributo obbligatorio, che ammette i valori [†̃NULL’, †̃NOT NULL’] (sint);

- <4_6_flag_ammissibilità_assenza_referenziamento> determina se l’ELEMENTO migrato dalla relazione <4_1_nome_relazione> può risultare non noto alla creazione dell’ELEMENTO nell’ENTE referenziato <4_3_ente_referenziato>) (valore †̃NULL’), o se deve essere obbligatoriamente valorizzato (valore †̃NOT NULL’) (sem);

- <4_7_numerosità> à ̈ attributo facoltativo: laddove valorizzato, determina il numero massimo di ELEMENTI ammessi nell’ENTE referenziato <4_3_ente_referenziato>, a parità di ELEMENTO migrato dalla relazione <4_1_nome_relazione> (sem);

- l’ENTE referenziante <4_2_ente_referenziante> e l’ENTE referenziato <4_3_ente_referenziato> devono essere distinti (sint);

- Se <4_5_flag_tipo_relazione> = †̃I’ o †̃D’, allora <4_6_flag_ammissibilità_assenza_referenziamento> = †̃NOT NULL’ (sint); - Se <4_5_flag_tipo_relazione> = †̃D’, allora <4_7_numerosità> = 1 (sint);

- Se <4_5_flag_tipo_relazione> = †̃D’, allora deve esistere almeno un valore discriminante attribuito alla relazione <4_1_nome_relazione> (sint);

- Se <4_5_flag_tipo_relazione> <> †̃D’, la chiave primaria (“PK†) e tutte le chiavi alternative (“AK†) dell’ENTE referenziante <4_2_ente_referenziante> devono differire dalla chiave primaria (“PK†) e da ciascuna delle chiavi alternative (“AK†) dell’ENTE referenziato <4_3_ente_referenziato> (sint); - Se <4_5_flag_tipo_relazione> = †̃D’, la chiave primaria (“PK†) dell’ENTE referenziato <4_3_ente_referenziato> deve coincidere con la chiave primaria (“PK†) dell’ENTE referenziante <4_2_ente_referenziante> (sint);

- a fissato ENTE, il numero delle relazioni che lo referenziano deve essere minore o eguale al numero di PROPRIETÀ migrate ad esso appartenenti (sint).

Successivamente al CENSIMENTO RELAZIONI avviene il CENSIMENTO PROPRIETÀ MIGRATE al passo 111. Il formato sintattico della frase dichiarativa CENSIMENTO PROPRIETÀ MIGRATE, di cardinalità molteplice “y†, à ̈:

“La PROPRIETÀ <3_1_nome_proprietà> dell’ENTE <3_2_ente_di_appartenenza> migra [<3_3_flag_primitiva_migrata> = †̃M’] a mezzo della relazione <3_19_relazione_di_migrazione> nel ruolo semantico di <3_20_ruolo_di_migrazione>â€

Le norme di scrittura della frase dichiarativa CENSIMENTO PROPRIETÀ MIGRATE sono espresse nel seguito:

- <3_1_nome_proprietà> à ̈ chiave primaria (sint);

- <3_2_ente_di_appartenenza> Ã ̈ attributo obbligatorio, referenziato da <2_contiene> (sint);

- <3_3_flag_primitiva_migrata> à ̈ attributo obbligatorio, che ammette i valori [†̃P’, †̃M’] (sint);

- <3_3_flag_primitiva_migrata> determina se la PROPRIETÀ <3_1_nome_proprietà> sia nativa dell’ENTE di appartenenza <3_2_ente_di_appartenenza> (valore †̃P’), o sia migrata nell’ENTE di appartenenza <3_2_ente_di_appartenenza> da una relazione (valore †̃M’) (sem);

- <3_19_relazione_di_migrazione> Ã ̈ attributo obbligatorio, referenziato da <5_trasporta> (sint);

- <3_20_ruolo_di_migrazione> Ã ̈ attributo obbligatorio (sint);

- <3_20_ruolo_di_migrazione> deve essere una definizione vocabolariale del ruolo semantico acquisito nell’ENTE di appartenenza <3_2_ente_di_appartenenza> (ENTE referenziato) dall’ELEMENTO dell’ENTE da cui migra (ENTE referenziante), a mezzo della relazione di migrazione <3_19_relazione_di_migrazione>; esemplificativamente, la †̃provincia di residenza’ di un soggetto, la cui esclusiva identità di provincia dell’ENTE referenziante †̃PROVINCE’ acquisisce il ruolo semantico di †̃residenza’ del soggetto al quale à ̈ attribuita nell’ENTE referenziato †̃SOGGETTI’) (sem);

- a fissato ENTE <3_2_ente_di_appartenenza>, deve esistere almeno una PROPRIETÀ <3_1_nome_proprietà>, primitiva o migrata, la quale, attraverso <8_appartiene_a>, appartenga alla chiave primaria (“PK†) (sint);

- la PROPRIETÀ <3_1_nome_proprietà> deve risultare aggiornabile, attraverso <13_à ̈_aggiornata_da>, da almeno un EVENTO (sint);

- a fissata relazione di migrazione <3_19_relazione_di_migrazione> deve esistere un numero di PROPRIETÀ migrate <3_1_nome_proprietà> pari al numero di PROPRIETÀ di chiave primaria (“PK†) dell’ENTE referenziante (sint);

- se la relazione di migrazione <3_19_relazione_di_migrazione> à ̈ identificante, tutte le PROPRIETÀ <3_1_nome_proprietà> migrate per mezzo di essa debbono far parte della chiave primaria (“PK†) dell’ENTE di appartenenza <3_2_ente_di_appartenenza> (sint);

- se la relazione di migrazione <3_19_relazione_di_migrazione> à ̈ elementare, nessuna delle PROPRIETÀ <3_1_nome_proprietà> migrate per mezzo di essa deve far parte della chiave primaria (“PK†) e/o di alcuna chiave alternativa (“AK†) dell’ENTE di appartenenza <3_2_ente_di_appartenenza> (sint);

- se la relazione di migrazione <3_19_relazione_di_migrazione> à ̈ di discriminazione, la chiave primaria (“PK†) dell’ENTE di appartenenza <3_2_ente_di_appartenenza> deve costituirsi di tutte e sole le PROPRIETÀ migrate per mezzo di essa (sint);

- tutte le PROPRIETÀ <3_1_nome_proprietà> che non appartengono alla chiave primaria (“PK†) né ad alcuna chiave alternativa (“AK†) debbono aderire alla “Terza Forma Normale†(“3NF†) (sem).

Se esiste almeno una relazione di discriminazione fra quelle censite, allora si procede con il passo 113 del CENSIMENTO VALORI DISCRIMINANTI. Il formato sintattico della frase dichiarativa CENSIMENTO VALORI DISCRIMINANTI, di cardinalità molteplice “o†, à ̈:

“Il valore <8_3_valore_discriminante> della PROPRIETÀ primitiva confrontabile a dominio chiuso <8_2_proprietà_discriminante> à ̈ valore discriminante della relazione di discriminazione <8_1_relazione_di_discriminazione>â€

Le norme di scrittura della frase dichiarativa CENSIMENTO VALORI DISCRIMINANTI sono espresse nel seguito:

- <8_1_relazione_di_discriminazione> appartiene alla chiave primaria, ed à ̈ referenziata da <10_à ̈_discriminata_da> (sint);

- <8_1_relazione_di_discriminazione> determina la relazione di discriminazione corrispondente alle specifiche 2-ple discriminanti [<8_2_proprietà_discriminante> <8_3_valore_discriminante>] (sem);

- <8_2_proprietà_discriminante> appartiene alla chiave primaria, ed à ̈ referenziata da <11_discrimina> (sint);

- <8_3_valore_discriminante> appartiene alla chiave primaria, ed à ̈ referenziata da <11_discrimina> (sint);

- la PROPRIETÀ discriminante <8_2_proprietà_discriminante> deve risultare primitiva, a dominio chiuso, e con ruolo di discriminazione (sint);

- i valori <8_3_valore_discriminante> determinano, a fissata PROPRIETÀ <8_2_proprietà_discriminante>, i valori discriminanti della relazione di discriminazione <8_1_relazione_di_discriminazione> (sem);

- l’ENTE di appartenenza della PROPRIETÀ discriminante <8_2_proprietà_discriminante> deve coincidere con l’ENTE referenziante della relazione di discriminazione <8_1_relazione_di_discriminazione> (sint); - la relazione di discriminazione <8_1_relazione_di_discriminazione> deve essere di tipo di discriminazione (sint).

Successivamente al passo 113 viene eseguito il passo 115 del CENSIMENTO CHIAVI. Il formato sintattico della frase dichiarativa CENSIMENTO CHIAVI, di cardinalità molteplice “s†, à ̈:

“<5_1_nome_chiave> à ̈ chiave

primaria [<5_3_tipo_chiave> = †̃PK’],

oppure

alternativa [<5_3_tipo_chiave> = †̃AK’],

oppure

a valori nulli ammissibili, con valori non nulli persistenti [<5_3_tipo_chiave> = †̃NK’],

oppure

a valori nulli ammissibili, con valori non nulli modificabili [<5_3_tipo_chiave> = †̃MK’]

dell’ENTE <5_2_ente_di_appartenenza>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO CHIAVI sono espresse nel seguito:

- <5_1_nome_chiave> Ã ̈ chiave primaria (sint);

- <5_2_ente_di_appartenenza> Ã ̈ attributo obbligatorio, referenziato da <6_Ã ̈_identificato_da> (sint);

- <5_3_tipo_chiave> à ̈ attributo obbligatorio, che ammette i valori [†̃PK’, †̃AK’, †̃NK’, †̃MK’] (sint);

- <5_3_tipo_chiave> determina se la chiave à ̈ primaria (valore †̃PK’: la chiave gode dei requisiti di piena valorizzazione alla creazione dell’ELEMENTO, di persistenza e di univocità, ed à ̈ utilizzata in modo implementativo per instaurare il vincolo di integrità referenziale nelle relazioni in cui l’ENTE <5_2_ente_di_appartenenza> à ̈ referenziante), o à ̈ alternativa (valore †̃AK’: la chiave gode dei requisiti di piena valorizzazione alla creazione dell’ELEMENTO, di persistenza e di univocità), o à ̈ a valori nulli ammissibili, con valori non nulli persistenti (valore †̃NK’: la chiave, laddove non nulla, gode dei requisiti di persistenza e di univocità), o à ̈ a valori nulli ammissibili, con valori non nulli modificabili (valore †̃MK’: la chiave, laddove non nulla, gode del requisito di univocità) (sem);

- ogni chiave <5_1_nome_chiave> deve contenere almeno una PROPRIETÀ (sint);

- tutte le PROPRIETÀ della chiave <5_1_nome_chiave> debbono appartenere all’ENTE <5_2_ente_di_appartenenza> cui appartiene la chiave stessa (sint); - A fissato ENTE di appartenenza <5_2_ente_di_appartenenza>, tutte le chiavi <5_1_nome_chiave>, indipendentemente dal loro tipo <5_3_tipo_chiave>, debbono risultare distinte fra loro (sint);

- per tutte le PROPRIETÀ della chiave <5_1_nome_chiave> migrate, l’ENTE referenziato dalla relazione di migrazione deve coincidere con l’ENTE <5_2_ente_di_appartenenza> cui appartiene la chiave (sint).

Successivamente al passo 115 viene eseguito il passo 117 della CONNESSIONE PROPRIETÀ DI CHIAVE.

Il formato sintattico della frase dichiarativa CONNESSIONE PROPRIETÀ DI CHIAVE, di cardinalità molteplice “t†, à ̈:

“La PROPRIETÀ <6_2_proprietà_di_chiave> appartiene alla chiave <6_1_chiave_di_appartenenza>†.

Le norme di scrittura della frase dichiarativa CONNESSIONE PROPRIETÀ DI CHIAVE sono espresse nel seguito:

- <6_1_chiave_di_appartenenza> appartiene alla chiave primaria, ed à ̈ referenziato da <7_contiene> (sint);

- <6_2_proprietà_di_chiave> appartiene alla chiave primaria, ed à ̈ referenziato da <8_appartiene_a> (sint);

- ogni chiave <5_1_nome_chiave> deve contenere almeno una PROPRIETÀ <6_2_proprietà_di_chiave> (sint).

Successivamente al passo 117 viene eseguito il passo 119 della CONNESSIONE PROPRIETÀ AGGIORNATE.

Il formato sintattico della frase dichiarativa CONNESSIONE PROPRIETÀ AGGIORNATE, di cardinalità molteplice “m†, à ̈:

“L’EVENTO <10_1_evento_di_aggiornamento> valorizza la PROPRIETÀ <10_2_proprietà_aggiornata> secondo il protocollo di misurazione <10_4_protocollo_di_valorizzazione>; il valore così misurato à ̈ notificato al posto <10_3_indice_di_ordinamento_conversazionale> (ovvero all’i-esimo posto della conversazione di EVENTO), etichettato in conversazione da <10_5_label_di_esposizione>†.

Le norme di scrittura della frase dichiarativa CONNESSIONE PROPRIETÀ AGGIORNATE sono espresse nel seguito:

- <10_1_evento_di_aggiornamento> appartiene alla chiave primaria, ed à ̈ referenziato da <12_aggiorna> (sint);

- <10_2_proprietà_aggiornata> appartiene alla chiave primaria, ed à ̈ referenziato da <13_à ̈_aggiornata_da> (sint);

- <10_3_indice_di_ordinamento_conversazionale> Ã ̈ attributo obbligatorio (sint);

- <10_3_indice_di_ordinamento_conversazionale> à ̈ un numero intero progressivo che determina la posizione occupata dalla PROPRIETÀ aggiornata <10_2_proprietà_aggiornata>, nella successione conversazionale di notificazione delle istanze dell’EVENTO <10_1_evento_di_aggiornamento> (sem);

- <10_4_protocollo_di_valorizzazione> deve essere una definizione vocabolariale del protocollo di misurazione organizzativo/operativo utilizzato per la misurazione dei valori della PROPRIETÀ aggiornata <10_2_proprietà_aggiornata> (la stessa PROPRIETÀ può infatti essere aggiornata da diversi EVENTI di aggiornamento <10_1_evento_di_aggiornamento>, con diversi protocolli di misurazione) (sem);

- <10_5_label_di_esposizione> Ã ̈ attributo obbligatorio (sint);

- <10_5_label_di_esposizione> à ̈ una etichetta esposta a beneficio dell’utente, che identifica semanticamente la PROPRIETÀ sotto aggiornamento <10_2_proprietà_aggiornata> (sem);

- tutte le PROPRIETÀ aggiornate <10_2_proprietà_aggiornata> dall’EVENTO <10_1_evento_di_aggiornamento> devono appartenere all’ENTE affetto dall’EVENTO stesso (sint);

- se l’EVENTO <10_1_evento_di_aggiornamento> à ̈ di creazione, esso deve aggiornare tutte le PROPRIETÀ <10_2_proprietà_aggiornata> appartenenti alla chiave primaria (“PK†), e/o alle chiavi alternative (“AK†), dell’ENTE affetto dall’EVENTO <10_1_evento_di_aggiornamento> stesso (sint);

- se l’EVENTO <10_1_evento_di_aggiornamento> à ̈ di aggiornamento, esso non può aggiornare nessuna delle PROPRIETÀ <10_2_proprietà_aggiornata> appartenenti alla chiave primaria (“PK†) e/o alle chiavi alternative (“AK†) dell’ENTE affetto dall’EVENTO stesso (sint).

La sotto-fase di DINAMICA consiste nella individuazione di CASCATE costituenti le modalità di notificazione al “layer persistente†, degli EVENTI appartenenti al CAMPO DI PERCEZIONE di una OLTP-App, e nella valorizzazione degli attributi e delle relazioni che le connotano. Tale identificazione e qualificazione delle CASCATE definisce pienamente e univocamente il “layer conversazionale†e il “layer logico†della OLTP-App.

Per “layer conversazionale†si intende l’insieme delle componenti di esposizione dei programmi di una OLTP-App, finalizzate a governare le conversazioni interattive fra un utente e un sistema software (ad esempio, i programmi di un’interfaccia grafica). Per CASCATA si intende un albero finito non vuoto, i cui nodi sono occupati da EVENTI. Può essere, ad esempio, assimilabile ad una rete di Petri di peso condizionato 0/1/∞, completamente eseguibile in modalità sincrona, e pertanto implementabile in modo informatico con una unica transazione effettuata su un “layer persistente†.

Con riferimento alla fase di configurazione antropologica, la seguente sezione tratta la sotto-fase di DINAMICA (anche detta “layer conversazionale†, o conversazione uomo-macchina).

Le dichiarazioni di specificazione relative alla sotto-fase di DINAMICA (di configurazione antropologica) procedono attraverso il flusso rappresentato dai due grafi connessi di conversazione uomo-macchina, ovvero i grafi delle Figure 5a e 5b. In particolare, le Fig. 3b, 3c e 3d raffigurano, ad esempio, le seguenti tabelle, che si riferiscono alla sotto-fase di DINAMICA:

9_CASCATE;

11_RAMI_DI_CASCATA;

19_PROFILI;

20_PROPRIETÀ_SELEZIONABILI;

21_PROPRIETÀ_VISUALIZZATE;

15_CICLI_DI_CASCATA;

16_REGOLE_DI_AGGIORNAMENTO;

17_AGGIORNAMENTI_PER_PERSISTENZA;

18_VINCOLI_DI_AGGIORNAMENTO_IN_CICLI_NON_PRIMI.

La corrispondenza fra ciascuna frase dichiarativa ammessa (e dunque mappata in uno dei due grafi delle Figure 5a e 5b), e la corrispondente tabella alimentata à ̈ espressa, ad esempio, in Fig.6.

Nuovamente con riferimento alle Figg. 5a e 5b, ogni ciclo di esecuzione del grafo ha inizio al passo 121 con il CENSIMENTO CASCATA. Il formato sintattico della frase dichiarativa CENSIMENTO CASCATA, di cardinalità singola “1†, à ̈:

“È disponibile alla conversazione uomo-macchina la CASCATA <9_1_nome_cascata> finalizzata a notificare il/la <9_2_definizione_cascata>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO CASCATA sono espresse nel seguito:

- <9_1_nome_cascata> Ã ̈ chiave primaria (sint);

- <9_2_definizione_cascata> Ã ̈ attributo obbligatorio (sint);

- <9_2_definizione_cascata> deve essere una definizione vocabolariale di una generica notificazione al “layer persistente†del gruppo di EVENTI costituenti la CASCATA, effettuata dall’utente nel rispetto della successione e della logica di controllo che qualificano la CASCATA stessa (sem).

- Non può sussistere alcuna CASCATA <9_1_nome_cascata>, nella quale non ricorra almeno un EVENTO (sint).

Successivamente al passo 121 viene eseguito il passo 123 relativo a CONNESSIONE EVENTI. Il formato sintattico della frase dichiarativa CONNESSIONE EVENTI, di cardinalità molteplice “n†, à ̈:

“Nella CASCATA <11_1_cascata_del_ramo> il posto univocamente localizzato da <11_2_localizzazione_del_nodo> à ̈ occupato dall’EVENTO <11_3_evento_nel_nodo>†.

Le norme di scrittura della frase dichiarativa CONNESSIONE EVENTI sono espresse nel seguito:

- <11_1_cascata_del_ramo> appartiene alla chiave primaria, ed à ̈ referenziato da <14_à ̈_mappata_da> (sint);

- <11_2_localizzazione_del_nodo> appartiene alla chiave primaria (sint);

- <11_2_localizzazione_del_nodo> deve essere una etichetta del nodo occupato dall’EVENTO <11_3_evento_nel_nodo>, nell’albero che rappresenta la CASCATA <11_1_cascata_del_ramo> (sem);

- <11_3_evento_nel_nodo> à ̈ attributo obbligatorio, ed à ̈ referenziato da <15_à ̈_nodo_di> (sint);

- in ogni CASCATA deve ricorrere uno ed un solo nodo-radice (deve esistere uno ed un solo nodo di livello 1). In altri termini, l’EVENTO di ingresso in CASCATA deve essere univoco (sint);

- Un EVENTO non può ricorrere più di una volta in un RAMO DI CASCATA, può peraltro ricorrere più volte nella stessa CASCATA, in RAMI DI CASCATA diversi (sint). Per RAMO DI CASCATA si intende una successione di (n+1) nodi di CASCATA di cui fa parte un nodo per ogni altezza i da 0 (nodo-radice) a n, tale per cui, per ogni i da 0 a (n-1), il nodo di altezza i à ̈ topologicamente connesso al nodo di altezza (i+1), e il nodo di altezza n à ̈ nodo terminale (non à ̈ topologicamente connesso ad alcun nodo di altezza superiore) (sint);

- Fissata una OLTP-App, il censimento delle CASCATE può ritenersi completato se e soltanto se ogni EVENTO ricorre in almeno una CASCATA (sint).

Laddove nella CASCATA sotto dichiarazione ricorra almeno un EVENTO di aggiornamento che richiede selezione manuale dell’ELEMENTO da aggiornare, e/o laddove ricorra almeno un EVENTO che richieda valorizzazione manuale di almeno una PROPRIETÀ migrata, à ̈ necessario verificare, per gli ENTI affetti dagli EVENTI di aggiornamento a selezione manuale, e/o per gli ENTI referenzianti le PROPRIETÀ migrate a valorizzazione manuale, se risultino già disponibili tutti i profili di ricerca e selezione richiesti dall’utente. Laddove siano richiesti profili non già disponibili (in quanto mai censiti in alcuna delle CASCATE già dichiarate), à ̈ necessario procedere al loro censimento a mezzo della frase dichiarativa CENSIMENTO PROFILO al passo 125 di Fig. 5b, di cardinalità singola “1†, il cui formato sintattico à ̈, ad esempio, il seguente:

“Per l’ENTE <19_3_ente_profilato> à ̈ disponibile il profilo di ricerca e selezione <19_1_nome_profilo>, che consiste nel/nella <19_2_descrizione_profilo>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO PROFILO sono espresse nel seguito:

- <19_1_nome_profilo> Ã ̈ chiave primaria (sint);

- <19_2_descrizione_profilo> Ã ̈ attributo obbligatorio (sint);

- <19_2_descrizione_profilo> deve essere una definizione vocabolariale della strategia di selezione e reperimento di ELEMENTI dell’ENTE <19_3_ente_profilato> che connota il profilo <19_1_nome_profilo> (sem); - <19_3_ente_profilato> à ̈ attributo obbligatorio, referenziato da <34_à ̈_profilato_da> (sint);

- Il profilo <19_1_nome_profilo> deve referenziare, attraverso <35_consente_selezione_per>, almeno una PROPRIETÀ “selezionabile†, e cioà ̈ una PROPRIETÀ sulla quale l’utente possa definire filtri valoriali di selezione (sint);

- Il profilo <19_1_nome_profilo> deve referenziare, attraverso <38_visualizza>, almeno una PROPRIETÀ “visualizzata†, e cioà ̈ una PROPRIETÀ il cui stato valoriale, relativamente a tutti gli ELEMENTI che soddisfano i filtri valoriali di selezione definiti, viene esposto nel corso della conversazione (sint);

- Ogni ENTE che risulti affetto da almeno un EVENTO di aggiornamento e/o che risulti ENTE referenziante di almeno una relazione, deve ricorrere in ruolo di <19_3_ente_profilato> in almeno un profilo <19_1_nome_profilo> (sint). Se esistono già tutti i percorsi relazionali di raggiungimento delle PROPRIETÀ di selezione, allora, successivamente al passo 125 viene eseguito il passo 127 relativo alla CONNESSIONE PROPRIETÀ SELEZIONABILI.

Il formato sintattico della frase dichiarativa CONNESSIONE PROPRIETÀ SELEZIONABILI, di cardinalità molteplice “d†, à ̈:

“La PROPRIETÀ <20_2_proprietà_di_selezione>, esposta sotto l’etichetta <20_4_messaggio_esplicativo_di_selezione>, e semanticamente connessa all’ENTE <19_3_ente_profilato> profilato da <20_1_profilo_selezionabile> a mezzo del cammino relazionale <20_3_percorso_relazionale_di_selezione>, à ̈ utilizzabile quale filtro di selezione del profilo <20_1_profilo_selezionabile>â€

Le norme di scrittura della frase dichiarativa CONNESSIONE PROPRIETÀ SELEZIONABILI sono espresse nel seguito:

- <20_1_profilo_selezionabile> appartiene alla chiave primaria, ed à ̈ referenziato da <35_consente_selezione_per> (sint);

- <20_2_proprietà_di_selezione> appartiene alla chiave primaria, ed à ̈ referenziato da <36_à ̈_filtro_di_selezione_in> (sint);

- <20_2_proprietà_di_selezione> à ̈ una PROPRIETÀ sulla quale l’utente può definire filtri valoriali di selezione (sem);

- <20_3_percorso_relazionale_di_selezione> appartiene alla chiave primaria, ed à ̈ referenziato da <37_definisce_navigazione_di_selezione> (sint);

- <20_3_percorso_relazionale_di_selezione> à ̈ la frase logica che connette in modo relazionale l’ENTE di appartenenza della PROPRIETÀ di selezione <20_2_proprietà_di_selezione> all’ENTE profilato <19_3_ente_profilato>. Laddove i due ENTI coincidano, e dunque non sussista connessione relazionale, per ottemperare al vincolo di non-nullità della chiave primaria à ̈ utilizzata la frase logica convenzionale di percorso relazionale nullo (sem); - <20_4_messaggio_esplicativo_di_selezione> à ̈ attributo obbligatorio (sint); - <20_4_messaggio_esplicativo_di_selezione> à ̈ una didascalia esposta a beneficio dell’utente, che esplica la semantica della PROPRIETÀ di selezione <20_2_proprietà_di_selezione> (sem).

Se esistono già tutti i percorsi relazionali di raggiungimento delle PROPRIETÀ di visualizzazione, allora si procede con il passo 129 inerente la CONNESSIONE PROPRIETÀ VISUALIZZATE.

Il formato sintattico della frase dichiarativa CONNESSIONE PROPRIETÀ VISUALIZZATE, di cardinalità molteplice “p†, à ̈:

“La PROPRIETÀ <21_2_proprietà_di_visualizzazione>, esposta sotto l’etichetta <21_4_label_di_visualizzazione>, e semanticamente connessa all’ENTE <19_3_ente_profilato> profilato da <21_1_profilo_visualizzabile> a mezzo del cammino relazionale <21_3_percorso_relazionale_di_visualizzazione>, à ̈ esposta in visualizzazione dal profilo <21_1_profilo_visualizzabile>†.

Le norme di scrittura della frase dichiarativa CONNESSIONE PROPRIETÀ VISUALIZZATE sono espresse nel seguito:

- <21_1_profilo_visualizzabile> appartiene alla chiave primaria, ed à ̈ referenziato da <38_visualizza> (sint);

- <21_2_proprietà_di_visualizzazione> appartiene alla chiave primaria, ed à ̈ referenziato da <39_à ̈_visualizzata_in> (sint);

- <21_2_proprietà_di_visualizzazione> à ̈ una PROPRIETÀ esposta in visualizzazione all’utente (sem);

- <21_3_percorso_relazionale_di_visualizzazione> appartiene alla chiave primaria, ed à ̈ referenziato da <40_definisce_navigazione_di_visualizzazione> (sint);

- <21_3_percorso_relazionale_di_visualizzazione> à ̈ la frase logica che connette in modo relazionale l’ENTE di appartenenza della PROPRIETÀ di visualizzazione <21_2_proprietà_di_visualizzazione> all’ENTE profilato <19_3_ente_profilato>. Laddove i due ENTI coincidano, e dunque non sussista connessione relazionale, per ottemperare al vincolo di non-nullità della chiave primaria à ̈ utilizzata la frase logica convenzionale di percorso relazionale nullo (sem);

- <21_4_label_di_visualizzazione> Ã ̈ attributo obbligatorio (sint);

- <21_4_label_di_visualizzazione> à ̈ una etichetta esposta a beneficio dell’utente, che identifica la PROPRIETÀ di visualizzazione <21_2_proprietà_di_visualizzazione> (sem);

Ritornando al grafo di Fig.5a, dopo il passo 123 viene verificato se esistono già tutti i profili di ricerca e selezione necessari e se esistono già tutte le guardie di ingresso/uscita. Qualora queste due condizioni sono verificate allora si procede con il passo 131 relativo all’ATTRIBUZIONE GUARDIE DI INGRESSO/USCITA.

Il formato sintattico della frase dichiarativa ATTRIBUZIONE GUARDIE DI INGRESSO/USCITA, di cardinalità molteplice “q†, à ̈:

“L’ingresso nell’EVENTO <11_3_evento_nel_nodo>, che ricorre nella CASCATA <11_1_cascata_del_ramo> al nodo localizzato in <11_2_localizzazione_del_nodo>, à ̈ possibile se e solo se la condizione <11_4_guardia_di_ingresso> à ̈ verificata†, e/o

“L’uscita dall’EVENTO <11_3_evento_nel_nodo>, che ricorre nella CASCATA <11_1_cascata_del_ramo> al nodo localizzato in <11_2_localizzazione_del_nodo>, à ̈ possibile se e solo se la condizione <11_5_guardia_di_uscita> à ̈ verificata†.

Le norme di scrittura della frase dichiarativa ATTRIBUZIONE GUARDIE DI INGRESSO/USCITA sono espresse nel seguito:

- la 2-pla [<11_1_cascata_del_ramo> <11_2_localizzazione_del_nodo>] identifica una delle frasi espresse precedentemente al posto dichiarativo CONNESSIONE EVENTI (sint);

- <11_4_guardia_di_ingresso> à ̈ attributo facoltativo, ed à ̈ referenziato da <18_condiziona_in_ingresso> (sint);

- <11_4_guardia_di_ingresso> à ̈ la frase logica al cui valore di verità à ̈ subordinato l’ingresso nell’EVENTO <11_3_evento_nel_nodo>, che ricorre nella CASCATA <11_1_cascata_del_ramo> al nodo localizzato in <11_2_localizzazione_del_nodo> (sem);

- in ogni CASCATA l’ingresso al nodo-radice non può essere subordinato ad alcuna frase logica. Pertanto, la massima cardinalità possibile <qing> di guardie di ingresso à ̈ (<n>-1) (sint);

- <11_5_guardia_di_uscita> à ̈ attributo facoltativo, ed à ̈ referenziato da <19_condiziona_in_uscita> (sint);

- <11_5_guardia_di_uscita> à ̈ la frase logica al cui valore di verità à ̈ subordinata l’uscita dall’EVENTO <11_3_evento_nel_nodo>, che ricorre nella CASCATA <11_1_cascata_del_ramo> al nodo localizzato in <11_2_localizzazione_del_nodo> (sem);

- la massima cardinalità possibile <qusc> di guardie di uscita à ̈ <n>, e pertanto la massima cardinalità possibile <q> = (<qing> <qusc>) di guardie di ingresso/uscita à ̈ (2*<n>-1) (sint);

- laddove l’EVENTO <11_3_evento_nel_nodo>, che ricorre nella CASCATA <11_1_cascata_del_ramo> al nodo localizzato in <11_2_localizzazione_del_nodo>, preveda sia guardia di ingresso <11_4_guardia_di_ingresso> che guardia di uscita <11_5_guardia_di_uscita>, queste devono risultare distinte (sint).

Successivamente, se esistono cicli nella CASCATA, si procede con il passo 133 relativo al CENSIMENTO CICLI. Il formato sintattico della frase dichiarativa CENSIMENTO CICLI, di cardinalità molteplice “f†, à ̈:

“La CASCATA <15_1_cascata_del_ciclo> ammette un ciclo di rientro al nodo localizzato da <15_3_nodo_di_rientro>, lanciabile dal nodo <15_2_nodo_di_lancio>†Le norme di scrittura della frase dichiarativa CENSIMENTO CICLI sono espresse nel seguito:

- <15_1_cascata_del_ciclo> appartiene alla chiave primaria, ed à ̈ identicamente referenziato sia da <20_lancia> che da <21_chiude> (sint);

- <15_2_nodo_di_lancio> appartiene alla chiave primaria, ed à ̈ referenziato da <20_lancia> (sint);

- <15_3_nodo_di_rientro> appartiene alla chiave primaria, ed à ̈ referenziato da <21_chiude> (sint);

- il livello del nodo di lancio <15_2_nodo_di_lancio> deve essere maggiore o eguale al livello del nodo di rientro <15_3_nodo_di_rientro>. Sono pertanto permessi “auto-cicli†, e cioà ̈ cicli per i quali <15_2_nodo_di_lancio> = <15_3_nodo_di_rientro> (sint);

- il nodo di rientro <15_3_nodo_di_rientro> deve appartenere allo stesso RAMO DI CASCATA di cui fa parte il nodo di lancio <15_2_nodo_di_lancio> (sint); - a fissato RAMO DI CASCATA M, che comprende m nodi, il numero massimo di cicli ammissibili <fM> per M Ã ̈ data da (m!-1) (sint);

Se esistono già tutte le guardie di lancio necessarie, allora si procede con il passo 135 relativo all’ATTRIBUZIONE GUARDIE DI LANCIO.

Il formato sintattico della frase dichiarativa ATTRIBUZIONE GUARDIE DI LANCIO, di cardinalità molteplice “g†, à ̈:

“L’ingresso nel ciclo di rientro al nodo localizzato da <15_3_nodo_di_rientro> della CASCATA <15_1_cascata_del_ciclo>, lanciabile dal nodo <15_2_nodo_di_lancio>, à ̈ possibile se e solo se la condizione <15_4_guardia_di_lancio> à ̈ verificata†.

Le norme di scrittura della frase dichiarativa ATTRIBUZIONE GUARDIE DI LANCIO sono espresse nel seguito:

- la 3-pla [<15_1_cascata_del_ciclo> <15_2_nodo_di_lancio> <15_3_nodo_di_rientro>] identifica una delle frasi espresse precedentemente al posto dichiarativo CENSIMENTO CICLI (sint);

- <15_4_guardia_di_lancio> à ̈ attributo facoltativo, ed à ̈ referenziato da <22_condiziona_in_lancio> (sint);

- <11_4_guardia_di_lancio> à ̈ la frase logica al cui valore di verità à ̈ subordinato l’ingresso nel ciclo identificato dalla 3-pla [<15_1_cascata_del_ciclo> <15_2_nodo_di_lancio> <15_3_nodo_di_rientro>] (sem);

- la massima cardinalità possibile <g> à ̈ eguale a <f> (caso in cui tutti i cicli della CASCATA presentano ingresso condizionato) (sint);

- laddove <15_2_nodo_di_lancio> sia nodo di ingresso di n cicli, e laddove le (n+1) guardie di uscita dal nodo e/o di ingresso negli n cicli non risultino mutuamente esclusive, l’utente sceglierà il percorso di prosecuzione fra quelli che, sulla base dello stato valoriale formatosi fino all’attraversamento dell’EVENTO sito in <15_2_nodo_di_lancio>, verificano le loro rispettive guardie (sem).

Successivamente, si procede al passo 137 relativo all’ELENCO PROPRIETÀ DA AGGIORNARE. Il formato sintattico della frase dichiarativa ELENCO PROPRIETÀ DA AGGIORNARE, di cardinalità molteplice “m†, à ̈:

“Il valore della PROPRIETÀ <16_4_proprietà_sotto_aggiornamento>, rilevato nelle istanze dell’EVENTO <16_3_evento_sotto_conversazione>, à ̈ notificato nella CASCATA <16_1_ramo_sotto_conversazione> al nodo localizzato da <16_2_localizzazione_sotto_conversazione>†.

La frase dichiarativa ELENCO PROPRIETÀ DA AGGIORNARE non soggiace ad alcuna norma di scrittura, poiché à ̈ completamente deducibile sulla base delle frasi espresse ai precedenti passi dichiarativi CONNESSIONE EVENTI e CONNESSIONE PROPRIETÀ AGGIORNATE, secondo i seguenti automatismi logici:

- <16_1_ramo_sotto_conversazione> appartiene alla chiave primaria: à ̈ la <9_1_nome_cascata> sotto dichiarazione, referenziata da [<23_à ̈_in_corso_di_conversazione> → <14_à ̈_mappata_da>] (sint);

- <16_2_localizzazione_sotto_conversazione> appartiene alla chiave primaria:

sono i <11_2_localizzazione_del_nodo> corrispondenti a <16_1_ramo_sotto_conversazione>, referenziati da <23_Ã ̈_in_corso_di_conversazione> (sint);

- <16_3_evento_sotto_conversazione> appartiene alla chiave primaria: sono i <1_1_nome_evento> referenziati da [<24_à ̈_in_corso_di_aggiornamento> → <12_aggiorna>], per <1_1_nome_evento> = <11_3_evento_del_nodo> corrispondenti alle 2-ple [<16_1_ramo_sotto_conversazione> <16_2_localizzazione_sotto_conversazione>] (sint);

- <16_4_proprietà_sotto_aggiornamento> appartiene alla chiave primaria: sono le <3_1_nome_proprietà> referenziate da [<24_à ̈_in_corso_di_aggiornamento> → <13_à ̈_aggiornata_da>], per <3_1_nome_proprietà> = <10_2_proprietà_aggiornata> corrispondenti a <10_1_evento_di_aggiornamento> = <11_3_evento_del_nodo> (sint);

- Detto miil numero di PROPRIETÀ aggiornate dall’EVENTO i-esimo, e detto qiil numero di ricorrenze dell’EVENTO i-esimo nella CASCATA, la cardinalità <m> risulta identicamente Σ<n>

i=1(qi*mi) (sint).

Se esistono già tutte le regole di aggiornamento necessarie, allora viene eseguito il passo 139 dell’ATTRIBUZIONE REGOLE DI AGGIORNAMENTO.

Il formato sintattico della frase dichiarativa ATTRIBUZIONE REGOLE DI AGGIORNAMENTO, di cardinalità molteplice “m†, à ̈:

“La valorizzazione della PROPRIETÀ <16_4_proprietà_sotto_aggiornamento>, rilevata nelle istanze dell’EVENTO <16_3_evento_sotto_conversazione> e notificabile nella CASCATA <16_1_ramo_sotto_conversazione> al nodo localizzato da <16_2_localizzazione_sotto_conversazione> risulta

sempre obbligatoria [<16_5_guardia_di_valorizzazione_obbligatoria> = SEMPRE], oppure

risulta sempre facoltativa [<16_5_guardia_di_valorizzazione_obbligatoria> = MAI], oppure

risulta obbligatoria sotto la condizione <16_5_guardia_di_valorizzazione_obbligatoria>; il valore rilevato viene notificato in modalità automatica nel caso in cui <16_6_guardia_di_valorizzazione_automatica> a mezzo dell’algoritmo di valorizzazione automatica <16_8_algoritmo_di_valorizzazione_automatica>, viene invece notificato in modalità persistente nel caso in cui <16_7_guardia_di_valorizzazione_persistente>, e viene infine notificato in modalità manuale nel caso logico complementare composto [⌠(<16_6_guardia_di_valorizzazione_automatica>)⌠(<16_7_guardia_di_valorizzazi one_persistente>)] proponendo in conversazione il valore di default <16_9_algoritmo_di_valorizzazione_default>; la notifica del valore occupa il posto conversazionale naturale oppure occupa il posto conversazionale variato <16_10_variazione_di_cascata_dell_ordinamento_conversazionale>.

Le norme di scrittura della frase dichiarativa ATTRIBUZIONE REGOLE DI AGGIORNAMENTO sono espresse nel seguito:

- La 4-pla [<16_1_ramo_sotto_conversazione> <16_2_localizzazione_sotto_conversazione> <16_3_evento_sotto_conversazione> <16_4_proprietà_sotto_aggiornamento>] identifica uno degli aggiornamenti precedentemente elencati al posto dichiarativo ELENCO PROPRIETÀ DA AGGIORNARE (sint);

- <16_5_guardia_di_valorizzazione_obbligatoria> à ̈ attributo obbligatorio, ed à ̈ referenziato da <25_condiziona_obbligatorietà> (sint);

- <16_5_guardia_di_valorizzazione_obbligatoria> Ã ̈ la frase logica che determina la condizione valoriale sotto la quale la valorizzazione risulta obbligatoria (sem);

- per tutte le PROPRIETÀ appartenenti alla chiave primaria e/o a chiavi alternative dell’ENTE di appartenenza deve risultare, per qualunque EVENTO e in qualunque CASCATA esse ricorrano: <16_5_guardia_di_valorizzazione_obbligatoria> = †̃SEMPRE’ (sint);

- <16_6_guardia_di_valorizzazione_automatica> à ̈ attributo obbligatorio, ed à ̈ referenziato da <26_condiziona_automaticità> (sint);

- <16_6_guardia_di_valorizzazione_automatica> à ̈ la frase logica che determina la condizione valoriale sotto la quale la valorizzazione risulta automatizzabile a mezzo di un algoritmo; laddove la valorizzazione risulti automatizzabile in qualunque/nessuna condizione valoriale, risulta: <16_6_guardia_di_valorizzazione_automatica> = †̃SEMPRE/MAI’ (sem); - <16_7_guardia_di_valorizzazione_persistente> à ̈ attributo obbligatorio, ed à ̈ referenziato da <27_condiziona_persistenza> (sint);

- <16_7_guardia_di_valorizzazione_persistente> à ̈ la frase logica che determina la condizione valoriale sotto la quale la valorizzazione risulta automatizzabile a mezzo di una persistenza; laddove la valorizzazione risulti persistente in qualunque/nessuna condizione valoriale, risulta: <16_7_guardia_di_valorizzazione_persistente> = †̃SEMPRE/MAI’ (sem); - Se <16_2_localizzazione_sotto_conversazione> = 1 (EVENTI primi di CASCATA), deve sempre risultare <16_7_guardia_di_valorizzazione_persistente> = MAI (sint);

- posto che †̃aut’ e †̃per’ annotino i rispettivi campi di verità di <16_6_guardia_di_valorizzazione_automatica> e <16_7_guardia_di_valorizzazione_persistente>, essi devono risultare mutuamente esclusivi: {†̃aut’’per’} = (sint);

- <16_8_algoritmo_di_valorizzazione_automatica> à ̈ attributo obbligatorio, referenziato da <28_calcola_valore>, se <16_6_guardia_di_valorizzazione_automatica> ≠ MAI; in caso contrario non à ̈ valorizzato (sint);

- <16_8_algoritmo_di_valorizzazione_automatica> à ̈ la frase logica, di tipo algoritmo, che fornisce la valorizzazione di <16_4_proprietà_sotto_aggiornamento> (sem);

- <16_9_algoritmo_di_valorizzazione_default> à ̈ attributo facoltativo, referenziato da <29_calcola_default>, nel caso in cui {⌠(†̃aut’)⌠(†̃per’)} ≠ ; in caso contrario non à ̈ valorizzato (sint);

- <16_9_algoritmo_di_valorizzazione_default> à ̈ la frase logica, di tipo algoritmo, che fornisce il valore di default da proporre per <16_4_proprietà_sotto_aggiornamento> (sem);

- <16_10_variazione_di_cascata_dell_ordinamento_conversazionale> à ̈ attributo facoltativo. È un numero intero progressivo che determina la posizione occupata dalla PROPRIETÀ aggiornata <16_4_proprietà_sotto_aggiornamento> nella successione conversazionale di notificazione delle istanze dell’EVENTO <16_3_evento_sotto_conversazione>, nell’ambito della specifica CASCATA <16_1_ramo_sotto_conversazione>, laddove tale posizione risulti diversa da quella naturale (generale) definita da <10_3_indice_di_ordinamento_conversazionale> (sem);

- a fissato i-esimo EVENTO <16_3_evento_sotto_conversazione> di indice i nell’ambito della specifica CASCATA <16_1_ramo_sotto_conversazione>, che prevede l’aggiornamento di miPROPRIETÀ <16_4_proprietà_sotto_aggiornamento>, gli mivalori <16_10_variazione_di_cascata_dell_ordinamento_conversazionale> o risultano tutti nulli, o risultano tutti attribuiti (sint);

- laddove gli mivalori <16_10_variazione_di_cascata_dell_ordinamento_conversazionale> risultino tutti attribuiti, essi debbono costituire i primi minumeri naturali (sint).

Se esistono aggiornamenti per persistenza, allora si procede al passo 141 dell’ATTRIBUZIONE VALORI PERSISTENTI.

Il formato sintattico della frase dichiarativa ATTRIBUZIONE VALORI PERSISTENTI, di cardinalità molteplice “z†, à ̈:

“Nella CASCATA <17_1_ramo_di_persistenza> la PROPRIETÀ <17_4_proprietà_persistente>, rilevata nelle istanze dell’EVENTO <17_3_evento_persistente> al nodo localizzato in <17_2_nodo_persistente> assume lo stesso valore della PROPRIETÀ <17_7_proprietà_persistita>, precedentemente rilevato nelle istanze dell’EVENTO <17_6_evento_persistito> al nodo localizzato in <17_5_nodo_persistito>†.

Le norme di scrittura della frase dichiarativa ATTRIBUZIONE VALORI PERSISTENTI sono espresse nel seguito:

- la 4-pla [<17_1_ramo_di_persistenza> <17_2_nodo_persistente> <17_3_evento_persistente> <17_4_proprietà_persistente>] à ̈ la chiave primaria, referenziata da <30_à ̈_aggiornata_per_persistenza>. Essa identifica un aggiornamento precedentemente elencato al posto dichiarativo ELENCO PROPRIETÀ DA AGGIORNARE, per il quale al successivo posto dichiarativo ATTRIBUZIONE REGOLE DI AGGIORNAMENTO sia risultato <16_7_guardia_di_valorizzazione_persistente> ≠ †̃MAI’ (sint);

- <17_5_nodo_persistito> à ̈ attributo obbligatorio, referenziato da [<31_aggiorna_per_persistenza> → <23_à ̈_in_corso_di_conversazione>] (sint);

- <17_5_nodo_persistito> à ̈, nell’ambito della CASCATA <17_1_ramo_di_persistenza>, la localizzazione del nodo dal quale viene assunto il valore persistente ( sem);

- <17_6_evento_persistito> à ̈ attributo obbligatorio, referenziato da [<31_aggiorna_per_persistenza> → <24_à ̈_in_corso_di_aggiornamento> → <12_aggiorna>] (sint);

- <17_6_evento_persistito> à ̈, nell’ambito della CASCATA <17_1_ramo_di_persistenza>, l’EVENTO dal quale viene assunto il valore persistente (sem);

- <17_7_proprietà_persistita> à ̈ attributo obbligatorio, referenziato da [<31_aggiorna_per_persistenza> → <24_à ̈_in_corso_di_aggiornamento> → <13_à ̈_aggiornata_da>] (sint);

- <17_7_proprietà_persistita> à ̈, nell’ambito della CASCATA <17_1_ramo_di_persistenza>, la PROPRIETÀ che fornisce il valore persistente (sem);

- la PROPRIETÀ <17_4_proprietà_persistente> valorizzata per persistenza deve risultare, nel percorso dichiarativo di CASCATA <17_1_ramo_di_persistenza>, successiva alla PROPRIETÀ <17_7_proprietà_persistita> che fornisce il valore di persistenza (sint);

- detto m1il numero di PROPRIETÀ aggiornate dall’EVENTO che occupa il nodo-radice di una CASCATA di n nodi, poiché in ogni EVENTO non localizzato nel nodo-radice deve sussistere almeno una PROPRIETÀ non valorizzabile per persistenza, la massima cardinalità possibile <z> risulta: [m -m1-(n-1)] = m-m1-n+1 (sint).

Successivamente, se esistono vincoli di valorizzazione ciclici si procede al passo 143 con il CENSIMENTO VINCOLI DI VALORIZZAZIONE CICLICI.

Il formato sintattico della frase dichiarativa CENSIMENTO VINCOLI DI VALORIZZAZIONE CICLICI, di cardinalità molteplice “a†, à ̈:

“Nella i-esima esecuzione non prima del ciclo di rientro identificato dalla 3-pla [<18_1_ciclo_vincolato> <18_2_nodo_di_lancio_vincolato> <18_3_nodo_di_rientro_vincolato>] il valore della PROPRIETÀ <18_6_proprietà_vincolata> aggiornata nell’EVENTO <18_5_evento_vincolato> localizzato nel nodo <18_4_nodo_vincolato> deve essere uguale a quello assunto nella prima esecuzione del ciclo [<18_7_flag_persistenza_esclusione> = †̃P’], oppure

deve essere diverso da tutti quelli assunti nelle precedenti (i-1) esecuzioni del ciclo [<18_7_flag_persistenza_esclusione> = †̃E’]†.

Le norme di scrittura della frase dichiarativa CENSIMENTO VINCOLI DI VALORIZZAZIONE CICLICI sono espresse nel seguito:

- la 3-pla [<18_1_ciclo_vincolato> <18_2_nodo_di_lancio_vincolato> <18_3_nodo_di_rientro_vincolato>], referenziata da <32_subisce_il_vincolo_di_aggiornamento>, appartiene alla chiave primaria. Essa identifica un ciclo di rientro precedentemente censito al posto dichiarativo CENSIMENTO CICLI (sint);

- <18_4_nodo_vincolato> appartiene alla chiave primaria, ed à ̈ referenziato da [<33_à ̈_limitata_da> → <23_à ̈_in_corso_di_conversazione>] (sint);

- <18_4_nodo_vincolato> à ̈, nell’ambito della CASCATA <18_1_ciclo_vincolato>, la localizzazione del nodo occupato dall’EVENTO di aggiornamento della PROPRIETÀ la cui valorizzazione soggiace al vincolo ciclico (sem);

- <18_5_evento_vincolato> appartiene alla chiave primaria, ed à ̈ referenziato da [<33_à ̈_limitata_da> → <24_à ̈_in_corso_di_aggiornamento> → <12_aggiorna>] (sint);

- <18_5_evento_vincolato> à ̈, nell’ambito della CASCATA <18_1_ciclo_vincolato>, l’EVENTO di aggiornamento della PROPRIETÀ la cui valorizzazione soggiace al vincolo ciclico (sem);

- <18_6_proprietà_vincolata> appartiene alla chiave primaria, ed à ̈ referenziata da [<33_à ̈_limitata_da> → <24_à ̈_in_corso_di_aggiornamento> → <13_à ̈_aggiornata_da>] (sint);

- <18_6_proprietà_vincolata> à ̈, nell’ambito della CASCATA <18_1_ciclo_vincolato>, la PROPRIETÀ la cui valorizzazione soggiace al vincolo ciclico (sem);

- <18_7_flag_persistenza_esclusione> à ̈ attributo obbligatorio che ammette i valori [†̃P’, †̃E’] (sint);

- <18_7_flag_persistenza_esclusione> determina se il valore della PROPRIETÀ <18_6_proprietà_vincolata> debba essere eguale a quello assunto nella prima esecuzione del ciclo (valore †̃P’), o se debba essere diverso da tutti quelli assunti nelle precedenti (i-1) esecuzioni del ciclo (valore †̃E’) (sem).

Con riferimento alla fase di configurazione antropologica, la presente sezione tratta la sotto-fase di LOGICA (anche detta “layer logico†, o predicazione logica).

Per “layer logico†si intende un insieme di componenti di accesso, computazione e aggiornamento dei programmi di una OLTP-App, finalizzate a garantire che, per effetto di ogni esecuzione di ogni programma, lo stato persistente rilasciato dall’esecuzione risulti diverso da quello iniziale e logicamente ammesso (ad esempio un “commit†), o che, alternativamente, l’esecuzione del programma non produca modificazione dello stato persistente iniziale (ad esempio un “rollback†).

Il “layer logico†specifica la componente sintattica †̃frasificata’ della SPECIFICAZIONE-REM relativa ad una OLTP-App. Al contrario degli altri due layer “persistente†e “conversazionale†, che censiscono le componenti di specificazione della OLTP-App in formato †̃modellato’ (ossia, li rappresentano a mezzo di ELEMENTI di ENTI di uno Schema di Relazione), il “layer logico†necessita di un linguaggio †̃frasificato’, per mezzo del quale vengono specificati i vincoli di integrità non-relazionale che insistono sul “layer persistente†della OLTP-App, e i vincoli logici che regolano il “layer conversazionale†della stessa OLTP-App. Il “layer logico†può essere equivalentemente specificato in formato linguistico libero, o ricorrendo ad uno specifico linguaggio logico-formale, ad esempio il linguaggio “Siriaco†.

La traducibilità della SPECIFICAZIONE-REM in un qualunque linguaggio-sorgente con ricorso a trasformazioni automatiche, à ̈ subordinata all’utilizzo di un linguaggio logico-formale, come ad esempio il “Siriaco†.

Il “Siriaco†à ̈ una specifica declinazione pseudo-quantificata della più generale Logica dei Predicati (“First-Order Logic†), finalizzata ed ottimizzata per la predicazione logica applicata a “layer persistenti†e a “layer conversazionali†di OLTP-App previamente specificati nel linguaggio formale della SPECIFICAZIONE-REM .

Il “Siriaco†ottempera al requisito di “Completezza relazionale†(“Relational Completeness†), e risulta quindi equivalente al linguaggio SQL (“Structured Query Language†). Esso à ̈ pertanto utilizzabile sia in modalità imperativa (allo scopo di aggiornamento) che in modalità dichiarativa (allo scopo di controllo).

In particolare, la Fig. 3e raffigura, ad esempio, le seguenti tabelle nelle quali à ̈ depositata centralmente la collezione delle frasi logiche che costituiscono il “layer logico†:

13_FRASI_LOGICHE;

12_FORMULE_ATOMICHE;

14_MATRICE_DI_COMPOSIZIONE_DELLE_FRASI_LOGICHE.

Esse costituiscono un sotto-schema di relazione che non dipende da alcuna delle altre tabelle alimentate dalla specificazione del “layer persistente†e/o del “layer conversazionale†.

Tale sotto-schema di relazione à ̈ relazionato al resto della SPECIFICAZIONE-REM a mezzo delle connessioni semantiche documentate nella precedente sezione relativa al “layer conversazionale†, che risultano, ad esempio, le seguenti:

<37_definisce_navigazione_di_selezione>;

<40_definisce_navigazione_di_visualizzazione>;

<18_condiziona_in_ingresso>;

<19_condiziona_in_uscita>;

<22_condiziona_in_lancio>;

<25_condiziona_obbligatorietà>;

<26_condiziona_automaticità>;

<27_condiziona_persistenza>;

<28_calcola_valore>;

<29_calcola_default> .

Il contesto di utilizzo di una frase logica à ̈ ad essa trasferito dalla connessione semantica che la invoca. La frase logica preesiste a qualsivoglia invocazione, ed à ̈ dunque indipendente dagli specifici contesti di invocazione (in altri termini, il testo della frase logica non à ̈ affetto da “side-effects†).

I “side-effects†della frase logica sono pertanto completamente iniettati in essa dalla connessione semantica di invocazione; in particolare, la connessione semantica di invocazione definisce univocamente il campo di istanziazione (campo di assegnazione delle variabili libere della frase logica, sul quale la frase logica effettua il calcolo di verità), e il tipo di utilizzo della frase logica (vincolo, o condizione, o algoritmo, o selezione).

Alle variabili libere della frase logica viene assegnato lo stato valoriale corrente al momento della sua invocazione, nel corso della conversazione transazionale.

Poiché in qualunque momento (stato di attraversamento) della conversazione, risulta sotto aggiornamento uno ed un solo ELEMENTO di uno ed un solo ENTE (l’ENTE affetto dall’EVENTO che occupa il nodo di CASCATA sotto attraversamento), le variabili libere assumono valorizzazione dall’ELEMENTO sotto aggiornamento e/o dagli ELEMENTI aggiornati in sede di precedente attraversamento (EVENTI localizzati nei nodi del RAMO DI CASCATA già attraversati); nel caso di attraversamento multiplo per effetto di cicli di rientro, le variabili libere assumono valorizzazione dagli ELEMENTI aggiornati nell’ultimo ciclo di rientro attraversato. Le dichiarazioni di specificazione relative alla sotto-fase LOGICA di configurazione antropologica devono procedere attraverso il flusso rappresentato dal grafo del flusso di processo di predicazione logica illustrato in Fig.7.

Con riferimento alla Fig. 8, viene illustrata una tabella di esempio che rappresenta la corrispondenza fra ciascuna frase dichiarativa ammessa (e dunque mappata nel grafo di predicazione logica di Fig.7), e la corrispondente tabella alimentata.

Ogni ciclo di esecuzione del grafo di predicazione logica ha inizio al passo 145 di CENSIMENTO FRASE LOGICA. Il formato sintattico della frase dichiarativa CENSIMENTO FRASE LOGICA, di cardinalità singola “1†, à ̈:

“È disponibile all’invocazione la frase logica che asserisce in formato linguistico libero: <13_1_testo_naturale_frase_logica>, la cui espressione formale siriaca à ̈ <13_2_predicato_siriaco_frase_logica>†.

(Tale frase à ̈ di tipo †̃V’, ossia costituisce un vincolo universale permanente istituito sullo stato dei dati, ovvero

[<13_3_flag_ruolo_logico_di_vincolo> = †̃S’ e <13_4_flag_ruolo_logico_di_condizione> = †̃S’ e <13_5_flag_ruolo_logico_di_algoritmo> = †̃N’ e <13_6_flag_ruolo_logico_di_selezione> = †̃N’].

e/o tale frase à ̈ di tipo †̃C’, ossia può essere utilizzata quale condizione di controllo di conversazioni, ovvero

[<13_3_flag_ruolo_logico_di_vincolo> = †̃N’ e <13_4_flag_ruolo_logico_di_condizione> = †̃S’ e <13_5_flag_ruolo_logico_di_algoritmo> = †̃N’ e <13_6_flag_ruolo_logico_di_selezione> = †̃N’],)

Oppure,

tale frase à ̈ di tipo †̃A’, ossia può essere utilizzata per effettuare valorizzazioni automatiche, ovvero

[<13_3_flag_ruolo_logico_di_vincolo> = †̃N’ e <13_4_flag_ruolo_logico_di_condizione> = †̃N’ e <13_5_flag_ruolo_logico_di_algoritmo> = †̃S’ e <13_6_flag_ruolo_logico_di_selezione> = †̃N’],

Oppure

tale frase à ̈ di tipo †̃S’, ossia può essere utilizzata per definire campi di assegnazione [<13_3_flag_ruolo_logico_di_vincolo> = †̃N’ e <13_4_flag_ruolo_logico_di_condizione> = †̃N’ e <13_5_flag_ruolo_logico_di_algoritmo> = †̃N’ e <13_6_flag_ruolo_logico_di_selezione> = †̃S’].

La matrice di ammissibilità dei tipi di frase logica, in funzione dei tipi di connessione semantica di invocazione, à ̈ espressa in Fig.9.

Le norme di scrittura della frase dichiarativa CENSIMENTO FRASE LOGICA sono espresse nel seguito:

- <13_1_sintesi_predicato_frase_logica> Ã ̈ chiave primaria (sint);

- <13_1_sintesi_predicato_frase_logica> Ã ̈ un'espressione sintetica, formulata in linguaggio naturale, del contenuto e/o della funzione del predicato logico espresso dalla frase (sem);

- <13_2_testo_naturale_frase_logica> à ̈ AK (“Alternative Key†) o chiave alternativa (sint);

- <13_2_testo_naturale_frase_logica> deve essere una formulazione libera, formulata in linguaggio naturale, del predicato logico espresso dalla frase (sem);

- <13_3_predicato_siriaco_frase_logica> à ̈ chiave a valori nulli ammissibili, con valori non nulli persistenti (“Nullable Key†o “NK†) (sint); laddove la chiave à ̈ non nulla, gode dei requisiti di persistenza e di univocità, ma può permanere al valore NULL alla creazione del record.

- <13_3_predicato_siriaco_frase_logica> deve essere il predicato logico espresso dalla frase, formulato in Siriaco o in un altro linguaggio logico-formale (sem); - <13_4_flag_ruolo_logico_di_vincolo> à ̈ attributo obbligatorio, che ammette i valori [†̃S’, †̃N’] (sint);

- <13_4_flag_ruolo_logico_di_vincolo> assume il valore †̃S’ laddove il predicato logico espresso dalla frase ha natura dichiarativa e costituisce un vincolo universale permanente istituito sullo stato dei dati; assume il valore †̃N’ negli altri casi (sem);

- <13_5_flag_ruolo_logico_di_condizione> à ̈ attributo obbligatorio, che ammette i valori [†̃S’, †̃N’] (sint);

- <13_5_flag_ruolo_logico_di_condizione> assume il valore †̃S’ laddove il predicato logico espresso dalla frase ha natura dichiarativa e costituisce un vincolo universale permanente istituito sullo stato dei dati o una condizione di controllo di conversazioni; assume il valore †̃N’ negli altri casi (sem);

- <13_6_flag_ruolo_logico_di_algoritmo> à ̈ attributo obbligatorio, che ammette i valori [†̃S’, †̃N’] (sint);

- <13_6_flag_ruolo_logico_di_algoritmo> assume il valore †̃S’ laddove il predicato logico espresso dalla frase ha modalità imperativa e può essere utilizzato per effettuare valorizzazioni automatiche; assume il valore †̃N’ negli altri casi (sem);

- <13_7_flag_ruolo_logico_di_selezione> à ̈ attributo obbligatorio, che ammette i valori [†̃S’, †̃N’] (sint);

- <13_7_flag_ruolo_logico_di_selezione> assume il valore †̃S’ laddove il predicato logico espresso dalla frase ha modalità imperativa e può essere utilizzato per definire campi di assegnazione; assume il valore †̃N’ negli altri casi (sem).

Se le formule atomiche invocate nella frase logica non sono già state tutte censite, allora si procede al passo 147 relativo al CENSIMENTO FORMULE ATOMICHE. Il formato sintattico della frase dichiarativa CENSIMENTO FORMULE ATOMICHE, di cardinalità molteplice “β†, à ̈:

“È disponibile per la ricorrenza in frasi logiche la formula atomica che asserisce in formato linguistico libero: <12_2_testo_naturale_formula_atomica>, la cui espressione formale siriaca à ̈ <12_3_predicato_siriaco_formula_atomica>.

Tale formula à ̈ annotata nelle frasi logiche in cui ricorre con il simbolo univoco: <12_1_identificativo_simbolico>.

Laddove la frase in cui ricorre à ̈ utilizzata quale vincolo universale (tipo †̃V’) e/o quale condizione di controllo di conversazione (tipo †̃C’), e laddove in conversazione risulti falsificata, espone il messaggio conversazionale: <12_4_testo_naturale_messaggio_di_errore>†.

Le norme di scrittura della frase dichiarativa CENSIMENTO FORMULE ATOMICHE sono espresse nel seguito:

- <12_1_identificativo_simbolico> Ã ̈ chiave primaria (sint);

- <12_1_identificativo_simbolico> deve essere un’espressione simbolica sintetica univoca, utilizzata nelle frasi logiche in cui ricorre la formula atomica <12_2_testo_naturale_formula_atomica> (sem);

- <12_2_testo_naturale_formula_atomica> à ̈ AK (“Alternative Key†) o chiave alternativa (sint);

- <12_2_testo_naturale_formula_atomica> deve essere una formulazione libera, formulata in linguaggio naturale, del predicato di confronto espresso dalla formula atomica (sem);

- <12_3_predicato_siriaco_formula_atomica> à ̈ chiave a valori nulli ammissibili, con valori non nulli persistenti (“Nullable Key†o “NK†) (sint); - <12_3_predicato_siriaco_formula_atomica> deve essere l’espressione in Siriaco, o in un altro linguaggio logico-formale, della formula atomica (sem); - <12_4_testo_naturale_messaggio_di_errore> à ̈ chiave a valori nulli ammissibili, con valori non nulli persistenti (“Nullable Key†o “NK†) (sint); - <12_4_testo_naturale_messaggio_di_errore> à ̈ attributo obbligatorio se le frasi <13_1_testo_naturale_frase_logica> in cui ricorre sono utilizzate quale vincolo universale (tipo †̃V’) e/o quale condizione di controllo di conversazione (tipo †̃C’); in caso contrario non à ̈ valorizzato (sem).

Altrimenti, se le formule atomiche invocate nella frase logica sono già state tutte censite oppure à ̈ stato eseguito il passo 147, allora si procede al passo 149 relativo alla CONNESSIONE FORMULE ATOMICHE.

Il formato sintattico della frase dichiarativa CONNESSIONE FORMULE ATOMICHE, di cardinalità molteplice “α†, à ̈:

“La formula atomica univocamente identificata dal simbolo <14_1_formula_atomica_invocata> ricorre nella frase logica <14_2_frase_logica_invocante>†.

Le norme di scrittura della frase dichiarativa CONNESSIONE FORMULE ATOMICHE sono espresse nel seguito:

- <14_1_formula_atomica_invocata> appartiene alla chiave primaria, ed à ̈ referenziata da <16_ricorre_in> (sint);

- <14_2_frase_logica_invocante> appartiene alla chiave primaria, ed à ̈ referenziata da <17_utilizza> (sint).

Pertanto, il metodo secondo la presente invenzione prevede che il flusso di processo dichiarativo (sopra dettagliato a mezzo dei grafi Fig. 2, 5a, 5b e 7) permetta di decomporre e di ridurre la specificazione complessiva di una qualunque OLTP-app in unità informative atomiche, rappresentabili sotto forma di t-uple di valori di tabelle dello schema di relazione in Terza Forma Normale riportato in Fig. 3a-3b-3c-3d-3e, o di qualunque altro schema di relazione ad esso semanticamente equivalente, sempreché aderente alla Terza Forma Normale.

In particolare, nuovamente con riferimento alla Fig. 2, il flusso di processo guida la dichiarazione della componente di FONDAZIONE ONTOLOGICA della OLTP-app: tale componente attiene esclusivamente allo stato di realtà oggettivo del CAMPO DI PERCEZIONE dell'applicazione, e si concretizza tecnologicamente nel disegno della base di dati della OLTP-App.

Invece, nuovamente con riferimento alle Fig. 5a e 5b, i flussi di processo guidano rispettivamente la dichiarazione della componente di Configurazione Antropologica: tale componente dipende invece dall’ambiente storico, economico, sociale, culturale, organizzativo, regolamentare, operativo, o psicologico, dell’utente, e si concretizza tecnologicamente nelle componenti di esposizione e di colloquio uomo-macchina (c.d. 'programmi') di una OLTP-App, finalizzate a governare le conversazioni interattive fra l'utente e l'applicazione. A supporto della fase di Configurazione Antropologica, e in funzione dei 'bisogni logici' via via emergenti, à ̈ progressivamente alimentato, secondo il flusso rappresentato in Fig. 7, un “repository†centralizzato della logica della OLTP-app, e cioà ̈ dell'insieme delle proposizioni logiche che sovrintendono all'accesso, alla computazione, al controllo e all'aggiornamento della base dati dell'applicazione: tale centralizzazione della predicazione logica, anch'essa decomposta e ridotta in t-uple di tabelle di uno schema di relazione in Terza Forma Normale, garantisce intrinsecamente e automaticamente la minimizzazione delle righe di codice (la stessa 'frase logica', anche se utilizzata da molteplici contesti di invocazione, à ̈ specificata una volta sola, senza duplicazione di codice equivalente); tale decomposizione, ovvero riduzione, garantisce anche, laddove si utilizzi per la frasificazione logica un linguaggio logico-formale quale ad esempio il Siriaco, la totale automatizzabilità della scrittura del codice della OLTP-app.

Dunque, il metodo secondo l’invenzione ovvia a entrambi i tipi di approssimazione impliciti sia nei generatori di codice, che negli strumenti automatici di supporto alla progettazione noti nell’arte, poiché elimina ogni bisogno di programmazione manuale “a valle†, pur conservando e garantendo “a monte†espressività universale al massimo livello di dettaglio; per tale ragione il metodo secondo l’invenzione costituisce una novità assoluta nel proprio campo di applicazione.

L’applicabilità industriale del metodo secondo l’invenzione consiste nella possibilità di realizzare dispositivi di lettura e scrittura automatica, ad esempio, un “parser†, il quale comprende un prodotto software che provvede all’interpretazione preliminare di una SPECIFICAZIONE-REM (lettura e interpretazione), alla sua verifica sintattica (correzione e validazione), e in caso di esito positivo della verifica sintattica, alla sua definitiva trasformazione automatica in codice-sorgente equivalente ( scrittura del codice-sorgente), uno per ciascuno “stack tecnologico†ritenuto di interesse, e di mantenerli evolutivamente in coerenza con l’evoluzione dei rispettivi livelli tecnologici di riferimento.

Per “stack tecnologico†(detto anche piattaforma o architettura) si intende un complesso di apparati e di strumenti hardware e/o firmware e/o middleware fra essi interconnessi e cooperanti che, operando in condizioni logistiche e ambientali conformi alle loro rispettive specificazioni d’uso, consentono l’operabilità e la fruibilità di sistemi software da parte di utenti umani e/o elaboratori automatici.

Dalla descrizione effettuata risultano pertanto chiare le caratteristiche della presente invenzione, così come chiari risultano i suoi vantaggi.

Un primo vantaggio del metodo e dispositivo secondo l’invenzione à ̈ la definizione di un formato sintattico e di una norma di scrittura che consentono di rappresentare la specificazione di una OLTP-app in modo tale che il numero di righe di codice da produrre risulti intrinsecamente e automaticamente minimizzato, e che la produzione del codice possa essere integralmente effettuata in modalità automatica, senza dover successivamente ricorrere a integrazioni manuali del codice stesso. Come già detto l'indisponibilità di un “code-repository†impedisce di ottimizzare il tasso di riuso del codice già scritto, e la quantità totale di codice (per convenzione definita 'numero di righe di codice') non risulta intrinsecamente minimizzata. Il metodo secondo la presente invenzione ovvia a tale inefficienza, garantendo intrinsecamente la minimizzazione del numero di righe di codice. Dalla riduzione della specificazione ad una collezione di moduli logici atomici mappati in colonne di tabelle di uno schema di relazione, consegue direttamente che il codice-sorgente dell'applicazione può essere prodotto in modalità totalmente automatica da parte di un dispositivo di lettura e scrittura automatica, opportunamente programmato ad acquisire in ingresso lo schema di relazione mediante mezzi di lettura sintattica (lettura e interpretazione), a verificarne la correttezza e la completezza sintattica a mezzo di un analizzatore logico (correzione e validazione), e a redigerne il codice-sorgente a mezzo di un generatore di codice-sorgente (scrittura del codice-sorgente).

Un secondo vantaggio del metodo e dispositivo secondo l’invenzione à ̈ automatizzare il controllo di versione (anche detto “versioning†), sia cronologico sia geografico. Come già detto nella parte inerente lo stato dell’arte, la nozione di “variazione†(ossia di insorgenza di una 'nuova versione') à ̈ aleatoria e discrezionale. La presente invenzione ovvia a tale aleatorietà, fornendo una definizione formale, metrica e universale di 'unità di misura di variazione', e stabilendo una prefissata 'soglia di variazione', che determina il discrimine fra 'versione variata' e 'versione invariata'. Poiché tale criterio à ̈ di natura formale, metrica e universale (non discrezionale), consegue che la gestione del “versioning†, sia cronologico sia geografico, à ̈ totalmente automatizzabile, senza alcun bisogno di 'discrezionalità umana'.

Un terzo vantaggio del metodo e dispositivo secondo l’invenzione à ̈ automatizzare il calcolo dei punti-funzione del codice (anche detti “Unadjusted function point†), totalmente ed esattamente eseguibile prima di procedere alla produzione del codicesorgente. La presente invenzione ovvia radicalmente ai punti di debolezza della metrica dei punti-funzione o FP. Innanzitutto, poiché la specificazione dell'applicazione à ̈ ricondotta ad uno schema di relazione, il calcolo dei FP si riduce a contare il numero di “records†presenti in alcune tabelle dello schema. Tale calcolo à ̈ totalmente automatizzabile, in quanto esprimibile, ad esempio, in sintassi SQL standard. In secondo luogo, il calcolo à ̈ effettuabile prima che abbia inizio la fase di codifica del software, e ne prescinde, fondandosi esclusivamente sulla specificazione. Infine, poiché i moduli logici dell'applicazione (algoritmi di manipolazione dei dati) sono mappati nello schema di relazione quali combinazioni logico-matematiche di proposizioni elementari tutte di peso logico unitario (dette 'formule atomiche'), anche il 'calcolo di complessità' di ogni modulo logico si riduce a contare il numero delle formule atomiche e il numero di operatori logico-matematici di combinazione invocati nel modulo logico: ovviamente, anche tale calcolo à ̈ totalmente automatizzabile.

Un ulteriore vantaggio del metodo e dispositivo secondo l’invenzione à ̈ ottenere un’automatica disponibilità ed estraibilità del piano di test funzionale. Il metodo secondo la presente invenzione consente di estrarre in modo automatico il piano di test per effetto della riconduzione della specificazione ad uno schema di relazione che modella anche la componente logica atomizzandola in formule atomiche. Anche il censimento di tutti i rami logici possibili si riconduce al calcolo combinatorio di tutte le navigazioni relazionali possibili allo stato corrente dello schema di relazione.

Un ulteriore vantaggio del metodo e dispositivo secondo l’invenzione à ̈ l’automatica disponibilità della documentazione d’uso contestuale (mouse-sensitive) per gli utenti, già incorporata nell’applicazione stessa. A tal fine sono destinate le colonne dello schema di relazione definite di tipo 'semantico', che risultano ininfluenti al fine della validazione sintattica della specificazione.

Numerose sono le varianti possibili al metodo e dispositivo per la definizione e realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, senza per questo uscire dai principi di novità insiti nell’idea inventiva, così come à ̈ chiaro che nella sua attuazione pratica le forme dei dettagli illustrati potranno essere diverse, e gli stessi potranno essere sostituiti con elementi tecnicamente equivalenti.

Ad esempio, la tripartizione del flusso dichiarativo in STATICA, DINAMICA e LOGICA à ̈ meramente convenzionale, ed à ̈ utilizzata esclusivamente per aderire alla convenzione diffusa secondo la quale un'applicazione si costituisce di un layer persistente (“DB†), di un layer logico (“logica†) e di un layer conversazionale (“interfaccia†), ma non risponde ad alcuna segmentazione strutturale, stante che lo schema di relazione à ̈ unico, omogeneo e totalmente connesso.

Inoltre, qualunque schema di relazione in Terza Forma Normale che risulti semanticamente equivalente a quello esemplificato ottiene i vantaggi sopra elencati, anche se introduce modifiche e/o varianti al formato sintattico e alle norme di scrittura delle corrispondenti frasi dichiarative. A titolo meramente esemplificativo, si supponga ad esempio di eliminare la colonna < 11_4_guardia_di_ingresso> dalla tabella 11_RAMI_DI_CASCATA, e di introdurre la nuova tabella XX_RIDUZIONI_PROFILI, nella quale, sotto chiave primaria composta di [(19_PROFILI) x (10_PROPRIETÀ_AGGIORNATE) x (11_RAMI_DI_CASCATA)], à ̈ censita la frase logica che riduce il campo di selezione del profilo invocato, in funzione del contesto di valorizzazione formatosi negli EVENTI di CASCATA che precedono quello invocato. Tale variante à ̈ semanticamente equivalente, poiché la funzione logica della guardia di ingresso ad un EVENTO di aggiornamento, e/o ad un EVENTO che richieda valorizzazione manuale di almeno una PROPRIETÀ migrata, à ̈ quello di ridurre la selezione effettuata dal profilo invocato, ai valori logicamente compatibili con le precedenti valorizzazioni in corso di CASCATA. Ad esempio, se si stanno aggiornando all'EVENTO 2 gli estimi catastali delle unità immobiliari di proprietà di un soggetto di fiscalità italiana, precedentemente selezionato all'EVENTO 1, il profilo di selezione delle unità immobiliari da aggiornare deve escludere quelle al di fuori del territorio nazionale, laddove il profilo invocato, essendo di natura decontestualizzata, le estrarrebbe tutte. Dunque à ̈ facilmente comprensibile che la presente invenzione non à ̈ limitata ad un metodo e dispositivo per la definizione e realizzazione di specificazioni di sistemi software, in particolare di tipo OLTP-App, ma à ̈ passibile di varie modificazioni, perfezionamenti, sostituzioni di parti ed elementi equivalenti senza però allontanarsi dall’idea dell’invenzione, così come à ̈ precisato meglio nelle seguenti rivendicazioni.

* * * * * *

Claims (10)

1. RIVENDICAZIONI 1. Metodo per una realizzazione di specificazioni di sistemi software, in particolare di tipo oltp-app, o “On-Line Transaction Processing-application†, detto metodo comprendendo una fase di statica, una fase di dinamica e una fase di logica atte a costruire uno schema di relazione tramite un dispositivo di lettura e scrittura automatica (200), ed in cui detta fase di statica, detta fase di dinamica e detta fase di logica prevedono di utilizzare frasi dichiarative aventi un formato sintattico e una norma di scrittura basati su un teorema di fondazione ontologica e su una regola di riduzione ontologica.
2. 2. Metodo secondo la rivendicazione 1, in cui detto teorema di fondazione ontologica sussiste se e soltanto se esiste almeno un evento di creazione, appartenente ad un campo di percezione di una applicazione, i cui accadimenti siano rappresentabili a mezzo di una creazione di una ed una sola t-upla di una relazione che la rappresenta, in particolare, un inserimento di uno ed un solo record in una tabella, e che tale relazione, ossia detta tabella, aderisca alla Terza Forma Normale.
3. 3. Metodo secondo la rivendicazione 1, in cui detta regola di riduzione ontologica prevede che qualunque tipologia di accadimento di detto campo di percezione, che non goda del requisito di evento, Ã ̈ riducibile ad una successione di eventi che affliggono solo enti ontologicamente fondati, in particolare rappresentabile da una rete di Petri condizionata di peso 1, detta cascata.
4. 4. Metodo secondo la rivendicazione 1, in cui dette frasi dichiarative intervengono in detta fase di statica attraverso tabelle di un “layer persistente†, in particolare un database presente in mezzi di memoria (205) di detto dispositivo di lettura e scrittura automatica (200).
5. 5. Metodo secondo una o più delle rivendicazioni precedenti, in cui detto evento di detta tabella di evento à ̈ una specifica tipologia di accadimento di detto campo di percezione, definita da un insieme di proprietà che subiscono valorizzazione secondo protocolli di misurazione predefiniti e stabili, rappresentabile a mezzo di una creazione, o di una modificazione di una ed una sola t-upla in uno ed un solo ente, detto ente essendo afflitto da detto evento.
6. 6. Metodo secondo la rivendicazione 5, in cui detta proprietà à ̈ un attributo logico di identificazione e/o qualificazione di detto ente.
7. 7. Dispositivo di lettura e scrittura automatica (200), in cui detto dispositivo (200) comprende mezzi di lettura sintattica (201) atti ad interpretare un requisito, mezzi di memoria (205) atti a memorizzare dati derivanti dalla lettura di detto requisito, un generatore di codice-sorgente (207) atto a generare un codice-sorgente che implementa detto requisito e un elaboratore (203) atto a controllare i suddetti elementi (201,205,207).
8. 8. Dispositivo di lettura e scrittura automatica (200), in cui detto requisito à ̈ un requisito scritto in un linguaggio formale di un sistema software di tipo oltp-app atto ad essere riconosciuto sintatticamente da detto dispositivo di lettura e scrittura automatica (200).
9. 9. Dispositivo di lettura e scrittura automatica (200), in cui detti mezzi di memoria (205) comprendono un “layer persistente†, in particolare un database relazionale.
10. 10. Prodotto informatico caricabile in una memoria (205) di detto dispositivo di lettura e scrittura automatica (200), in particolare un parser evoluto, e comprendente porzioni di codice software atte ad implementare il metodo secondo una o più delle rivendicazioni da 1 a 6.