Specifica e verifica di protocolli nel progetto Massive

1. Specifica e verifica di protocolli nel progetto Massive Marco Alberti, Fedrico Chesani, Anna Ciampolini, Paola Mello, Marco Montali, Sergio Storari, Paolo Torroni DEIS, Universita` di Bologna ENDIF, Universita` di Ferrara

2. Protocollo Def.Insieme delle regole che governano un'attività di scambio di informazioni fra due o piu` entità. • protocolli per la trasmissione di dati tra computer • protocolli di interazione tra agenti • protocolli di negoziazione nel commercio eletrronico • protocolli medici (linee guida) • ... • concetto generale applicabile a sistemi complessi e distribuiti: necessita` di strumenti per: • specificare i protocolli • verificare i protocolli

3. Obiettivi • Individuare formalismi basati su logica per la descrizione di protocolli di interazione per agenti in società aperte: • specifica formale • verifica di proprietà • implementazione • Sperimentazione in casi reali: • linee guida cliniche • e-commerce (protocolli per aste e transazioni commerciali) • e-learning (by doing) • protocolli internet (TCP/IP) • ... • Sinergia con il progetto europeo

4. SOCS: societa` aperte di agenti basate su logica computazionale • agenti eterogenei: non e` possibile fare assunzioni sulla struttura interna degli agenti, ma e` possibile osservare il comportamento sociale degli agenti (interazioni) • Gli agenti e la societa` hanno conoscenza incompleta dell'ambiente in cui operano. • Applicazione di forme di ragionamento abduttivo per modellare sia le interazioni tra agenti logici, che il comportamento del singolo agente. • Definizione di un linguaggio di programmazione logica (opportunamento esteso) per descrivere le societa` • Definizione di procedure di dimostrazione come supporto operazionale: • verifica automatica delle interazioni • verifica di proprieta` del protocollo

5. Verifica delle interazioni Infrastruttura Sociale Agenti Protocols Protocolli? Fulfillment Social Behaviour Reasoning and verification module Violation

6. Modello della Societa`:<SOKB, SEKB, ICs, Goals> • SEKB: conoscenza dinamica associata alla societa`: • History (HAP): insieme di eventi sociali accaduti nella societa`, ognuno rappresentato da fatti ground del tipo: H(Event [,Time] ). • EXP: aspettative(positive o negative) sul comportamento (sociale) dei membri, ognuna modellata mediante un abducibile: [¬ ] E( Event [, Time ] ) / [¬ ] EN( Event [, Time ] ) • ICs: descrizione dei protocolli mediante vincoli sociali di integrita` • SOKB: conoscenza statica associata alla societa` (roles and rules) • LP clauses with expectations • Goals: la societa` puo` essere goal-directed (LP Goals)

7. Eventi e Aspettative • ICs formalizzano i protocolli in termini di: • Eventi accaduti (H(..)) • Aspettative relative al comportamento degli agenti al fine di seguire I protocolli (E(..), EN(..))

8. Aspettative YES Verify Compliance NO Social infrastructure Fulfillment Reasoning Eventi Violation • verifica on-the flydella conformita` • ai protocolli

9. Social Integrity Constraints (ICs) • permettono la descrizione dei protocolli mediante una sintassi logica basata su regole forward, che possono contenere vincoli CLP sulle variabili. Esempio: negoziazione di beni Se io ti faccio un'offerta, mi aspetto che tu mi risponda accettando o rifiutando l'offerta, entro il tempo massimo d H(tell(Me,You,offer(Item,Price),T) E(tell(You,Me,accept(Item,Price),T’) ^ T’<=T+d∨ E(tell(You,Me,refuse(Item,Price), T’) ^ T’<=T+d’ Se tu accetti la mia offerta, mi aspetto che tu, successivamente, non la rifiuti H(tell(You,Me,accept(Item,Price), T) EN(tell(You,Me,refuse(Item,Price), Tr) ^ Tr>=T

10. yves thomas Example (fulfillment) H(tell(yves,thomas,offer(scooter,10$),1) E(tell(thomas,yves,accept(scooter,10$),T’), T’ < 7 ∨ E(tell(thomas,yves,refuse(scooter,10$),T’), T’ < 7 H(tell(thomas,yves,accept(scooter,10$),5) fulfillment!

11. yves thomas Esempio di violazione H(tell(yves,thomas,offer(scooter,10$),1) H(tell(thomas,yves,accept(scooter,10$),5) H(tell(thomas,yves,accept(Item,Price), T)v EN(tell(thomas,yves,refuse(Item,Price), Tr), Tr>=T H(tell(thomas,yves,refuse(scooter,10$),8) violazione!

12. Istanza di Societa` = Abductive Logic Program • L'istanza di una Societa` (SHAP) e` modellata mediante un programma logico abduttivo <P,Ab,IC>: • P = SOKB  HAP • Ab = {E, EN, ¬ E, ¬ EN} • IC = ICS • Consistenza: • ICS-Consistency • E-Consistency • ¬-Consistency • Fulfillment

13. Def: Consistenza, fulfillment e violazione Data una societa` ed un set HAPdi eventi: • un insieme EXP di aspettative e` ICs-consistentiff SOKB  HAP  EXP ⊨ICs • un insieme EXP di aspettative e` E-consistentiff { E(p), EN(p) } ⊈ EXP • un insieme EXP di aspettative e` ¬-consistent iff { E(p), E(p) } ⊈ EXP { EN(p), EN(p) } ⊈ EXP • un insieme EXP di aspettative (ICs,E,¬) consistent e` fulfilled iff HAP  EXP {E(p) → H(p)}  {EN(p) →H(p)} ╞ • se non esiste un insieme di aspettative fulfilled, HAP produce una violazionenella societa`.

14. Society Constraint Proof Procedure (wrt IFF) Dato l'insieme HAP di una societa` (history), la proof procedure abduttiva SCIFF (Society Constraint IFF) genera le aspettative corrispondenti agli eventi, ne verifica la consistenza, identificando situazioni di fulfillment o di violazione. La SCIFF estende la IFF [Fung, Kowalski, 97] Estensioni (rispetto a IFF): • Meccanismo incrementale: accetta nuovi eventi man mano che accadono • Genera le aspettative E, not E, EN, not EN in base al comportamento osservato degli agenti e agli ICs. • Verifica la corrispondenza tra gli eventi accaduti e le aspettative (fulfillment) • Identifica situazioni di violazione e/o inconsistenza • Vincoli CLP • Gli atomi abdotti possono avere variabili quantificate esistenzialmente e universalmente

15. Implementazione dell'infrastruttura sociale: SOCS-SI User Defined Protocols • Implementa la SCIFF proof procedure • Interfaccia utente • Gestione/visualizzazione della societa`: membri, protocolli, history, aspettative • Monitor degli eventi sociali  verifica di conformita` Society Infrastructure Society GUI Module User Society Module Medium Layer File System Prompt >

16. Un caso applicativo: specifica e verifica di linee guida in campo medico • Linee guida: raccomandazioni di comportamento clinico prodotte allo scopo di assistere medici e pazienti nella decisione delle modalità assistenziali più appropriate in determinate situazioni cliniche. • Distribuzione e Complessita`: molti attori, eterogeneita`, concorrenza, necessita` di sincronizzazione • Importanza di specifica e verifica • Specifica mediante ICs: H(misura_temp(Med,Paz,T)) ^T>=38 E(somministra(Inf,Paz,paracetamolo)) ^ E(registra(Inf2,Paz,T)). Necessita` di formalismi piu` intuitivi  GOSPEL

17. GOSPEL • Guideline prOcess SPEcification Language • Linguaggio grafico, basato sul paradigma dei flow-chart, per • Specificare un processo • Verificare se i partecipanti si comportano secondo specifica • La verifica è possibile grazie alla traduzione di un diagramma GOSPEL in un insieme di vincoli sociali di integrità

18. Livello epistemologico • Graficamente, GOSPEL permette di esprimere i concetti fondamentali per la modellazione di un processo • Elementi: • Attività atomiche e complesse • Punti di decisione • Sezioni di concorrenza • Relazioni binarie fra elementi: • D’ordine (eventualmente associate a guardie logiche) • Temporali (vincoli sulle attività)

19. Attività complesse • Tipico approccio top-down utilizzando i macroblocchi • Visti al livello in cui vengono inseriti come attività atomiche • Incapsulano la definizione di un nuovo (sotto)processo • I macroblocchi dicono anche quali sono le modalità di esecuzione del sottoprocesso • Azione complessaesecuzione lineare • Iterationesecuzione ciclica tipo for • Whileesecuzione ciclica tipo do…while • GOSPEL pone particolare attenzione alla riusabilità dei macroblocchi • I processi modellati possono essere riutilizzati per costruirne di nuovi

20. Livello ontologico • Tramite un’ontologia di dominio specifichiamo l’interpretazione di un diagramma GOSPEL nel dominio di interesse • GOSPEL non definisce un’ontologia a priori: • Linguaggio general purpose • L’ontologia diventa un parametro del modello • Di volta in volta ci si può calare su differenti domini applicativi • Due grandi tassonomie: attività e entità (partecipanti)

21. un’infermiera registra il valore Entity Action se la temperatura è superiore a 38 gradi Temperatura un’infermiera somministra paracetamolo il medico misura la temperatura del paziente il paziente va trattenuto altrimenti STOP Paziente il medico decide che... Medico misura_temp il paziente va rilasciato Un esempio

22. GOSPEL procedura di traduzione Integrity Constraints (ICs)

23. metti lo start del processo nella frontiera estrai un elemento dalla frontiera visita il diagramma individuando la prossima finestra genera le regole per la finestra aggiorna la frontiera Procedura di traduzione

24. Finestre

25. \/ E(e2) \/ E(e3) E(e4) /\ E(e5) E(e6) Traduzione di una finestra  H(e1) H(e1) ---> E(e2) \/E(e3) \/E(e4) \/E(e5)/\E(e6)

26. Un esempio H(misura_temp(Med,Paz,T)) /\T>=38 ---> E(somministra(Inf,Paz,paracetamolo)) /\ E(registra(Inf2,Paz,T)). T38 H(misura_temp(Med,Paz,T)) /\T<38 ---> E(trattieni(Med,Paz)) \/ E(rilascia(Med,Paz)) T<38

27. Work in progress • Lato specifica: editor (in via di sviluppo) • Progettazione grafica • Controlli di consistenza • Integrazione con Protégé per le ontologie • Lato verifica: • Verifica statica di proprietà (esiste una history conforme al modello?) • Verifica di conformità in tempo reale • Traduzione • Esecuzione…

28. translation Legacy Applications configuration Database Layer Compliance Verification layer Integrazione GOSPEL model triggers