P. 1
Progetto e sviluppo di un motore di inferenze in ambiente Python

Progetto e sviluppo di un motore di inferenze in ambiente Python

|Views: 469|Likes:

Lavoro di tesi sulla realizzazione di un motore inferenziale compatibile con CLIPS utilizzando Python come linguaggio di riferimento. Il testo offre una vista generale sull'architettura di sistema e una documentazione sommaria delle classi e strutture dati adottate nella realizzazione, così come una valutazione funzionale e prestazionale del prototipo realizzato.

Lavoro di tesi sulla realizzazione di un motore inferenziale compatibile con CLIPS utilizzando Python come linguaggio di riferimento. Il testo offre una vista generale sull'architettura di sistema e una documentazione sommaria delle classi e strutture dati adottate nella realizzazione, così come una valutazione funzionale e prestazionale del prototipo realizzato.

More info:

Categories:Types, Research
Published by: Arturo Sigillatore del Futuro on Jan 26, 2013
Copyright:Attribution Non-commercial No-derivs
List Price: $0.99 Buy Now

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
See more
See less

09/18/2014

$0.99

USD

UNIVERSITA’ DEGLI STUDI DI BARI ALDO MORO

FACOLTA’ DI SCIENZE MATEMATICHE, FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA TESI DI LAUREA IN

INGEGNERIA DELLA CONOSCENZA E SISTEMI ESPERTI

PROGETTO E SVILUPPO DI UN MOTORE DI INFERENZE IN AMBIENTE PYTHON

RELATORI: Chiar.ma Prof.ssa Floriana ESPOSITO Chiar.mo Prof. Stefano FERILLI LAUREANDO: Francesco CAPOZZO

ANNO ACCADEMICO 2011/2012

Dedicato a tutti quelli che hanno creduto in me, anche quando neanch’io ci credevo pi`. u

Ringraziamenti
Un grazie doveroso e sincero al mio Relatore, la Professoressa Floriana Esposito, per avermi concesso di lavorare a questo interessante progetto di ricerca, ma soprattutto per essere riuscita a farmi amare profondamente questa materia e avermi spinto, con le sue parole, oltre la mia fatica. Desidero ringraziare altrettanto sinceramente il mio Relatore, Professor Stefano Ferilli, per avermi accompagnato durante questo lavoro di tesi come costante punto di riferimento in questi mesi di studio. Intendo porre i miei ringraziamenti a tutti i Professori che ho incrociato durante i miei studi, per avermi insegnato quello che so e aver reso possibile questo traguardo. Ringrazio il personale della Biblioteca del Dipartimento di Informatica per avermi fornito dati e testi, anche oltre i vincoli del dovere, senza i quali questo lavoro sarebbe stato decisamente pi` povero. u Grazie ai miei compagni di corso, in particolare Domenico e Giuseppeper-gli-amici-Ciccio, per la pazienza che mi hanno dimostrato in questi mesi, rispondendo alle mie richieste e ascoltando i miei dubbi, e per avermi concesso di condividere con loro questo mio percorso di crescita. Grazie a Donato e Virginia, per essere stati un porto franco in cui spegnere il cervello e per tutte le volte che hanno atteso l’esito delle missioni della CIA, iv

credendo in me e scherzandoci su. Grazie ad Enea, la piccola Claudia, Flora, Nicola, Giovanni e tutti gli amici sempre presenti e pronti a ridere con me e rendere meno pesanti questi mesi. In particolare ringrazio Anna Maria per non essersela presa per la mia diserzione in una data importante. Approfitto di queste pagine per dire un grazie enorme ai miei Genitori, per il sostegno che mi hanno dimostrato e per la grande pazienza che hanno avuto nell’attesa di questo momento... e non solo. Grazie ad Annalisa, per aver combattuto al mio fianco anche quando sembrava una partita persa. Per essermi rimasta vicino e aver pazientemente ascoltato i miei sfoghi, in questo turbine di caos. Scusami se in questi mesi ti ho un po’ trascurato! Grazie anche te, Samuel, per esserti offerto come correttore del mio farneticare sacrificando il tuo sonno, ma ancor di pi` per essere stato un catau lizzatore degli eventi alla base di questo traguardo. Ad ogni modo, Antani non ce lo metto! Grazie alla miglior sorella che possa esistere, Donata, per essere stata nella mia vita, e ancora di pi` negli ultimi mesi, un supporto, un punto di u riferimento, uno stimolo ed un’ancora! Ti ringrazio davvero, tutto questo ` e anche merito tuo! Un grazie anche a tutti voi che state leggendo questi ringraziamenti: se siete qui oggi e leggete queste mie parole significa che avete avuto un ruolo in questo grande momento e di questo vi ringrazio di cuore.

v

Prefazione
L’emulazione del ragionamento umano, al punto da ricreare una sorta di auto coscienza, ` tra le sfide pi` affascinanti e ardue dell’Intelligenza Artificiale, e u area di ricerca delle Scienze Informatiche e punto d’incontro ideale fra logica, filosofia, ingegneria e informatica. Nella realt` scientifica, l’I.A. si pone come a obiettivo primario l’approfondimento di tutte le tematiche di progettazione e realizzazione di sistemi in grado di emulare le abilit` cognitive proprie a dell’uomo, in modo che esibiscano comportamenti che verrebbero definiti intelligenti se fossero osservati negli esseri umani [FFA95]. L’ingegneria della conoscenza, o knowledge engineering, nasce come ramo applicativo dell’intelligenza artificiale: si occupa della realizzazione e del mantenimento dei sistemi basati su conoscenza e di una loro particolare espressione, i sistemi esperti, che rappresentano e ”ragionano” con conoscenza di qualche ambito specialistico al fine di risolvere problemi specifici. Gli strumenti di sviluppo per sistemi esperti hanno vissuto un periodo di grande fermento durante gli anni ’80 [Men03]. L’introduzione di nuove tecniche algoritmiche, che permettessero la distribuzione e l’utilizzo dei sistemi prodotti su hardware di comune reperibilit`, ha traghettato i sistemi basati a su conoscenza dall’essere strumenti orientati alla ricerca anche verso ambiti vi

con implicazioni pi` pratiche. Il grande passo avanti compiuto con la creau zione di environment in linguaggi diffusi ed efficienti come il C ha offerto la possibilit` di adottare queste tecnologie anche in situazioni dove le risorse a disponibili, sia economiche che computazionali, risultavano relativamente limitate. D’altra parte, il nuovo boom tecnologico catalizzato dall’avvento di Internet sta portando ad un cambiamento radicale nel modo di concepire il software ed i meccanismi di distribuzione delle loro funzionalit`. Il fenomeno a sta portando alla luce molti dei limiti dei prodotti concepiti e realizzati prima dell’avvento del Web. Valori come le prestazioni e l’efficienza nella gestione delle risorse, pur rimanendo fattori importanti, sono sempre pi` spesso messi u in secondo piano rispetto a criteri di scelta legati alla rapidit` ed alla facilit` a a di sviluppo. La propriet` di un sistema di poter essere adattato pi` facilmena u te e pi` velocemente al repentino cambiamento delle necessit` ` diventato un u ae elemento chiave in qualsiasi scelta di sviluppo software. Lo scopo di questo lavoro di tesi, realizzato presso il laboratorio LACAM del dipartimento di Informatica dell’Universit` degli Studi di Bari, ` quello a e proporre un Expert System environment, ossia un ambiente di sviluppo per sistemi esperti, che renda agevole l’attivit` di integrazione dei sistemi esperti a in altri software ad approccio tradizionale, ed in particolare anche nei contesti che richiedano l’utilizzo di tecnologie per la distribuzione dei servizi tramite il Web. Nel primo capitolo si fornir` una panoramica sui sistemi esperti, il loro a ambito di utilizzo e il processo di sviluppo. Si descriveranno le modalit` di a rappresentazione della conoscenza e si introdurranno le principali tecniche coinvolte per la realizzazione dell’inferenza e del ragionamento basato su vii

regole, focalizzandosi sulla descrizione del problema del confronto fra stato del sistema e base di conoscenza. Verr` quindi effettuata una panoramica a sugli strumenti di supporto allo sviluppo dei sistemi esperti fornendone una classificazione in base alle funzionalit` e caratteristiche. a Nel secondo capitolo si approfondiranno le problematiche relative alla realizzazione di un environment per sistemi esperti, analizzandone le componenti chiave e fornendo una descrizione delle tecniche utilizzate e delle capacit` richieste al prototipo realizzato in questo lavoro di tesi. a Nel terzo capitolo si affronteranno le tematiche relative alla progettazione ed all’implementazione del sistema seguendo i vincoli evidenziati nel secondo capitolo. Verr` fornita una descrizione sommaria delle componenti che reaa lizzano il sistema e degli algoritmi utilizzati dallo stesso. Si passer` quindi a ad una sperimentazione del prototipo, necessaria per valutarne la correttezza e le prestazioni, offrendo un confronto con una soluzione di riferimento nel campo degli environment, quale ` CLIPS. e

viii

Indice
Ringraziamenti Prefazione Indice ed Elenchi 1 Environment per Sistemi Esperti 1.1 Sistemi Esperti . . . . . . . . . . . . . . . . . . . . 1.1.1 Le componenti di un sistema esperto . . . . 1.1.2 Il processo di sviluppo di un sistema esperto 1.1.3 Rappresentazione della conoscenza . . . . . 1.1.4 Ragionamento basato su regole . . . . . . . 1.1.5 RETE: matching fra regole e stato . . . . . 1.2 Strumenti di sviluppo . . . . . . . . . . . . . . . . . 1.2.1 L’evoluzione degli strumenti di sviluppo . . 1.2.2 Skeletal Shell . . . . . . . . . . . . . . . . . 1.2.3 Expert System Environment . . . . . . . . . 1.2.4 Il problema dell’integrazione . . . . . . . . . 1.3 Obiettivi di questa tesi . . . . . . . . . . . . . . . . Bibliografia capitolo 1 2 Analisi 2.1 Scopo del sistema . . . . . . . 2.2 Capacit` . . . . . . . . . . . . a 2.2.1 Linguaggio di specifica 2.2.2 Parser . . . . . . . . . 2.2.3 Motore inferenziale . . 2.2.4 Terminale . . . . . . . 2.2.5 Modulo Server . . . . . 2.3 Vincoli di sistema . . . . . . . iv vi ix 1 1 5 6 9 17 22 29 30 34 35 40 42 43 51 51 52 54 61 61 69 70 72

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

ix

INDICE 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 Attori 2.4.1 2.4.2 Vincoli di interfaccia . . . . . Vincoli operativi . . . . . . . Vincoli prestazionali . . . . . Vincoli di progetto . . . . . . Stabilit` dei vincoli . . . . . . a e Casi d’uso . . . . . . . . . . Attori . . . . . . . . . . . . . Organizzazione dei Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 73 74 74 74 75 75 77 133 135 . 135 . 137 . 163 . 169 . 170 . 170 . 172 . 176 . 179 . 179 . 181 . 185 189 193 198

2.4

Bibliografia capitolo 2 3 Sviluppo 3.1 Progettazione . . . . . . . . . . . . . 3.1.1 Core . . . . . . . . . . . . . . 3.1.2 Server . . . . . . . . . . . . . 3.1.3 Terminale . . . . . . . . . . . 3.2 Implementazione . . . . . . . . . . . 3.2.1 Scelta del linguaggio: Python 3.2.2 Protocollo: XML-RPC . . . . 3.2.3 Tecnologie utilizzate . . . . . 3.3 Valutazione . . . . . . . . . . . . . . 3.3.1 Correttezza . . . . . . . . . . 3.3.2 Prestazioni . . . . . . . . . . 3.3.3 Osservazioni . . . . . . . . . . Conclusioni e sviluppi futuri Bibliografia capitolo 3 Bibliografia generale

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

Appendici 210 Artefatti per la valutazione del sistema . . . . . . . . . . . . . . . . 210 Specifica BNF della linguaggio accettato . . . . . . . . . . . . . . . 239

x

Elenco delle figure
1.1 1.2 1.3 1.4 1.5 1.6 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 3.1 Architettura semplificata di un generico Sistema Esperto . . Le fasi di estrazione della conoscenza e sviluppo di un Sistema Esperto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asserzione di un nuovo elemento della working memory e valutazione tramite algoritmo RETE . . . . . . . . . . . . . . Grafo esplicito di RETE per una regola . . . . . . . . . . . . Classificazione degli strumenti di sviluppo per sistemi esperti Il logo di LOOPS . . . . . . . . . . . . . . . . . . . . . . . . RETE come una black-box . . . . . . . . . . . . . Applicazione delle propriet` dei connettivi logici . a Riduzione dei connettivi or adiacenti . . . . . . . Architettura Client-Server . . . . . . . . . . . . . Gerarchia degli attori . . . . . . . . . . . . . . . . Vista generale dei casi d’uso principali . . . . . . Diagramma dei casi d’uso UCC-1 . . . . . . . . . Diagramma dei casi d’uso UCD-1 . . . . . . . . . Diagramma dei casi d’uso UCD-1.2 . . . . . . . . Diagramma dei casi d’uso UCD-1.3 . . . . . . . . Diagramma dei casi d’uso UCD-1.4 . . . . . . . . Diagramma dei casi d’uso UCD-2 . . . . . . . . . Diagramma dei casi d’uso UCD-2.1 . . . . . . . . Diagramma dei casi d’uso UCE-1 . . . . . . . . . Diagramma dei casi d’uso UCE-2 . . . . . . . . . Diagramma dei casi d’uso UCE-3 . . . . . . . . . Diagramma dei casi d’uso UCE-4 . . . . . . . . . Diagramma dei casi d’uso UCA-3 . . . . . . . . . Diagramma dei casi d’uso UCS-1 . . . . . . . . . Diagramma dei casi d’uso UCR-1, UCR-2, UCR-3 Vista generale dell’architettura di sistema xi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7 25 27 32 33 63 65 66 71 76 78 80 86 88 91 95 101 102 105 110 112 114 118 121 125

. . . . . . . . . . . 136

ELENCO DELLE FIGURE 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 Vista generale dell’architettura locale di sistema . . . . . . . . 136 Package myclips: vista dei package che compongono il core . . 137 Package myclips.parser : vista delle classi relative al Parser . . 138 Package myclips.parser.types: vista di classi e interfacce per gli elementi atomici . . . . . . . . . . . . . . . . . . . . . . . . 138 Package myclips.parser.types: vista di classi e interfacce per i costrutti principali . . . . . . . . . . . . . . . . . . . . . . . . 139 Package myclips.parser.types: vista delle classi e interfacce relative al costrutto defrule . . . . . . . . . . . . . . . . . . . . . 140 Package myclips: vista degli elementi che collaborano per la realizzazione dei servizi dell’IE . . . . . . . . . . . . . . . . . 141 Package myclips: vista delle classi per la gestione dei moduli . 142 Diagramma di sequenza import/export delle definizioni . . . . 143 Diagramma di sequenza import/export tramite l’uso di promesse 144 Vista delle classi manager di definizioni . . . . . . . . . . . . . 145 Package myclips: vista della classe Network . . . . . . . . . . . 146 Package myclips: vista delle classi e interfacce relative ad Agenda e Strategie (CRS) . . . . . . . . . . . . . . . . . . . . . . . 147 Package myclips.rete: vista delle classi utility per la conversione delle regole in strutture di RETE . . . . . . . . . . . . . . 148 Package myclips.rete: vista delle interfacce di base usate dai nodi per l’implementazione di RETE . . . . . . . . . . . . . . 153 Package myclips.rete.nodes: vista dei nodi della pozione alpha 154 Package myclips.rete.nodes: vista dei nodi della pozione beta . 154 Package myclips.rete.nodes: vista dei nodi della pozione beta (nodi Ncc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Package myclips.rete.tests: vista dei test eseguiti nella porzione alpha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Package myclips.rete.tests: vista dei test eseguiti nella porzione beta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Package myclips.rete.shell : vista della classe Interpreter . . . . 159 Package myclips.rete.listeners: vista della classi per la gestione degli eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Package myclips.rete.functions: vista della classi per la gestione delle funzioni di sistema . . . . . . . . . . . . . . . . . . . . 162 Vista generale dell’architettura server . . . . . . . . . . . . . . 163 Package myclips server : vista delle classi e interfacce relative al Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio Sessions . . . . . . . . . . . . . . . 165

xii

ELENCO DELLE FIGURE 3.28 Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio Registry . . . . . . . . . . . . . . . 3.29 Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio ClientIO . . . . . . . . . . . . . . . 3.30 Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio RemoteShell . . . . . . . . . . . . . 3.31 Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio Engine . . . . . . . . . . . . . . . . 3.32 Package myclips.shell : vista delle classi relative al Terminale . 3.33 Comparazione fra Python e altri linguaggi di programmazione 3.34 Comunicazione tramite XML-RPC . . . . . . . . . . . . . . . 3.35 Integrazione di PyParsing nel modulo Parser . . . . . . . . . . 3.36 Confronto fra l’implementazione di vettori fornita da BList e di default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.37 Esempio d’uso della libreria NetworkX . . . . . . . . . . . . . 3.38 Profilazione dell’esecuzione del benchmark Sudoku . . . . . . . 3.39 Python 3 vs C: esecuzione della benchmark suite [CLB12] . . 3.40 Grafici dei rapporti prestazionali fra MyCLIPS e CLIPS . . .

166 167 168 169 170 171 173 177 177 178 183 187 188

xiii

Elenco delle tabelle
2.1 3.1 3.2 3.3 Matrice di stabilit` dei vincoli . . . . . . . . . . . . . . . . . . 74 a Tempi d’esecuzione del benchmark Manners variando il numero di ospiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Tempi d’esecuzione del benchmark Sudoku per i dataset grid3x3p13 e grid3x3-p15 . . . . . . . . . . . . . . . . . . . . . . . . . 184 Tempi d’esecuzione del benchmark Monkey . . . . . . . . . . . 185

xiv

Elenco dei blocchi di codice
2.1 2.2 2.3 2.4 2.5 2.6 3.1 3.2 Specifica BNF del costrutto defmodule . . . . . . . . . . . . Specifica BNF del costrutto deffunction . . . . . . . . . . . Esempio di scambio di una definizione fra moduli . . . . . . Specifica BNF del costrutto defrule . . . . . . . . . . . . . . Specifica BNF del costrutto deffacts . . . . . . . . . . . . . Specifica BNF del costrutto deftemplate . . . . . . . . . . . Esempio di chiamata ad una procedura remota usando XMLRPC over HTTP . . . . . . . . . . . . . . . . . . . . . . . . Esempio di messaggi inviato a risposta di una chiamata a procedura remota usando XML-RPC over HTTP . . . . . . . . . . . . 55 56 56 57 58 60

. 174 . 175

xv

Elenco degli Algoritmi
3.1 3.2 3.3 3.4 Compilazione di una regola . . . . . . Creazione di un circuito α . . . . . . Creazione di un circuito β per il Join Esempio di metodo factory per i nodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 152 152 152

xvi

Capitolo 1 Environment per Sistemi Esperti
”Un esperto ` una persona alla quale, per motivi professionali e o per una acquisita competenza ed esperienza su una data materia, viene richiesto di fornire pareri scientifici su argomenti di dettaglio.” (Wikipedia) Sembra ragionevole la scelta di attribuire l’aggettivo di esperto a una persona in possesso di qualit` e caratteristiche che ne attestino una conoscenza a in uno specifico ambito di dominio e che sia in grado di risolvere direttamente problemi o fornire possibili soluzioni in seguito ad una attivit` di ragionaa mento. Realizzando un parallelismo, ` possibile considerare l’assegnazione e dell’attributo di esperto ad un sistema in grado di esibire un comportamento paragonabile a quello di un esperto umano all’interno di un ambito di dominio focalizzato. La definizione fornita in [Jac99] spiega il sistema esperto come un’applicazione che rappresenta e ragiona con conoscenza di tipo spe1

1.1. SISTEMI ESPERTI cialistico con l’obiettivo di risolvere problematiche o fornire consigli su come risolverle. L’obiettivo di utilizzo di un sistema esperto pu` essere quello di sostituire o completamente l’intervento umano durante lo svolgimento di un’attivit` o a di fornire supporto ad un esperto durante l’atto di prendere una decisione, giocando un ruolo di assistenza. Altre possibili applicazioni possono riguardare la formazione o il perfezionamento della conoscenza posseduta da un esperto tramite l’interazione diretta con il sistema a titolo di confronto o consultazione. I sistemi esperti sono applicazioni progettate per rendere disponibili alcune abilit` di esperti di un dominio anche a utenti non esperti. Siccome questo a genere di programmi tentano di emulare gli schemi mentali e i modi di pensare di un esperto, ` naturale che le prime ricerche in questo ambito siano state e effettuate nel campo dell’intelligenza artificiale: una branca delle Scienze Informatiche correlate con la progettazione e la realizzazione di applicazioni in grado di emulare le abilit` cognitive umane nel campo della soluzione di a problemi, la percezione e la comprensione del linguaggio [BCF81]. Ci` che differenzia un’applicazione convenzionale da un sistema esperto o pu` essere sintetizzato in tre caratteristiche fondamentali: perch´ ragiona; su o e cosa ragiona; come ragiona. L’obiettivo di un sistema esperto ` quello di simulare un ragionamento e umano nell’ambito di un dominio, piuttosto che simulare il dominio stesso. Le applicazioni convenzionali lavorano attraverso la realizzazione di un modello matematico al fine simulare le abilit` dell’esperto nella soluzione a del problema. I sistemi esperti invece focalizzano l’attenzione sull’emulazione 2

1.1. SISTEMI ESPERTI degli schemi di ragionamento che l’esperto adotta per ottenere delle soluzioni e tentano di emulare il processo di ragionamento e non semplicemente il risultato allo specifico problema. Un altro fattore discriminante riguarda il tipo di informazioni sulle quali i due sistemi lavorano: le applicazioni tradizionali utilizzano modelli per rappresentare il problema, applicano algoritmi per la manipolazione dei dati ed infine calcolano soluzioni. Nei sistemi esperti, invece, l’intero processo di ragionamento viene eseguito lavorando su rappresentazioni della conoscenza umana. Queste rappresentazioni vengono codificate utilizzando linguaggi specificamente sviluppati e che permettono di separare la rappresentazione della conoscenza di dominio dalle porzioni del sistema che invece rappresentano le dinamiche di ragionamento. Queste due porzioni dei sistemi esperti vengono definite con i nomi di base di conoscenza e motore inferenziale. Le meccaniche di soluzione rappresentano l’ultimo fattore di differenza: se le applicazioni tradizionali risolvono problematiche offrendo soluzioni algoritmiche a problemi per i quali ` stato individuato un modello, i sistemi espere ti ottengono soluzioni applicando metodi approssimati o euristiche 1 spesso utilizzando conoscenza incerta o incompleta. Proprio a causa della natura dinamica e incerta del ragionamento alla base dei sistemi esperti, a questa classe di sistemi viene richiesta la capacit` a di interagire con l’utente (sia esso un esperto o no) in modo da: • illustrare e spiegare il ragionamento adottato per ottenere delle soluL’euristica ` una strategia cognitiva, una scorciatoia di pensiero, una tecnica basata e su esperienze, che permette pi` rapidamente di elaborare giudizi, ricavare inferenze dal u contesto, attribuire significato alle situazioni e prendere decisioni a fronte di problemi complessi o di informazioni incomplete [TK73] [KST82].
1

3

1.1. SISTEMI ESPERTI zioni e giustificare in questo modo il suo operato; • interagire con il mondo esterno tramite specifici protocolli, in modo da rendere possibile il reperimento di informazioni aggiuntive, qualora queste risultassero necessarie, durante il processo di ragionamento. ”La vera intelligenza richiede l’abilit` di imparare, di ragionaa re sull’esperienza, d’agire d’istinto2 , di usare conoscenza generale, di fare inferenza usando intuizioni viscerali. I sistemi esperti non fanno niente di tutto ci`, Non migliorano i risultati sulla base o dell’esperienza. Loro [i sistemi esperti] sanno soltanto spostarsi da una regola if/then all’altra.” [SC84] La capacit` di apprendimento, che per Schank [SC84] ` uno dei fattori dea e terminanti per poter associare al ragionamento dei sistemi esperti l’attributo di intelligente, rappresenta un’ulteriore componente chiave nella definizione di sistemi esperti. Alcune tecniche basate sull’aggiunta di nuovi elementi nella base di conoscenza o sull’aggiunta di nuove euristiche hanno permesso di integrare meccanismi di apprendimento automatico all’interno dei sistemi esperti [Sil88]. Dalla met` degli anni ’60 ad oggi sono stati creati un gran numero di a sistemi esperti con ambiti di utilizzo molto differenti fra loro. Per fare alcuni esempi ` possibile citare quello aerospaziale (ad esempio per agevolare e alcune operazioni in orbita), quello sanitario (ad esempio nell’assistenza al
L’espressione originale usava la forma gergale ”to shoot from the hip” la cui traduzione letterale rimanda al movimento dei cowboy di sparare velocemente dal fianco senza mirare con precisione.
2

4

1.1. SISTEMI ESPERTI monitoraggio dei parametri dei pazienti nelle unit` di terapia intensiva o nella a diagnosi di malattie) o quello finanziario [Jac99]. Il primi sistemi esperti prodotti furono Dendral (1965), con lo scopo di determinare la struttura molecolare partendo da dati provenienti da uno spettrometro di massa, R1 (1978), usato per configurare sistemi informatici e MYCIN (1976), per assistere nella diagnosi di infezioni da batteri e proporre piani terapeutici per il trattamento delle stesse.

1.1.1

Le componenti di un sistema esperto

Utente

Interfaccia Utente

Modulo di spiegazione

Modulo di aggiornamento della conoscenza

Base di conoscenza

Motore Inferenziale

Figura 1.1: Architettura semplificata di un generico Sistema Esperto La struttura di un sistema esperto pu` essere sinteticamente descritta o come composta da quattro moduli principali (Figura 1.1): • La base di conoscenza: raccoglie tutta la conoscenza di dominio acquisita. La fonte principale d’informazione ` rappresentata dall’esperto che, e interrogato da un ingegnere della conoscenza, fornisce in maniera pi` u o meno completa la conoscenza di cui dispone.

5

1.1. SISTEMI ESPERTI • Il motore inferenziale: raccoglie i processi di ragionamento sulla base dei quali il sistema, usando congiuntamente la base di conoscenza e ulteriori (ed eventuali) informazioni ottenute dall’interazione diretta con l’utente, ` in grado di dedurre nuove conoscenza. e • L’interfaccia utente: permette l’interazione fra l’utente e il sistema. L’interazione pu` essere orientata verso la spiegazione del processo loo gico alla base di una soluzione o una scelta (attivit` svolta dal modulo di a spiegazione), oppure per ottenere ulteriori informazioni e far proseguire il ragionamento. • Modulo di aggiornamento della conoscenza: permette di modificare ed integrare quanto presente nella base di conoscenza tramite processi automatici o che richiedono l’intervento di un esperto.

1.1.2

Il processo di sviluppo di un sistema esperto

Come il processo di sviluppo di software tradizionale pu` essere scandito in o fasi e rappresentato all’interno dei vari modelli di sviluppo, anche la produzione di sistemi esperti pu` essere semplificata attraverso un modello suddiviso o in step successivi. Sebbene il confronto fra lo sviluppo di software tradizionale e quello di sistemi basati su conoscenza possa mostrare punti di contatto, le somiglianze sono solamente superficiali ed un’analisi approfondita rivelerebbe profonde differenze dettate dalle specifiche caratteristiche del tipo di artefatto in produzione [Esp12].

6

1.1. SISTEMI ESPERTI

Identificazione delle caratteristiche del problema

IDENTIFICAZIONE

Individuazione dei concetti e delle relazioni

CONCETTUALIZZAZIONE

Progettazione delle strutture di rappresentazione della conoscenza
Riformulazione Riprogettazione Raffinamento

FORMALIZZAZIONE

Concretizzazione del prodotto

IMPLEMENTAZIONE

Validazione e valutazione del prodotto

TESTING

Figura 1.2: Le fasi di estrazione della conoscenza e sviluppo di un Sistema Esperto Alla figura gi` descritta dell’esperto di dominio viene affiancata quella a dell’ingegnere della conoscenza: un esperto informatico addetto alla compilazione di una base di conoscenza. Come mostrato in Figura 1.2 e suggerito in [BD83], il processo pu` essere o diviso in cinque fasi: • Identificazione: ` orientata all’identificazione della classe di problemi e che il sistema dovr` risolvere, dei dati con i quali il sistema dovr` a a lavorare e dei criteri che le soluzioni dovranno soddisfare. • Concettualizzazione: ha la finalit` di scoprire i concetti chiave e le rea lazioni che intercorrono fra loro. Questa fase dovrebbe includere la caratterizzazione delle varie tipologie di dati, il flusso delle informazioni e la delineazione delle strutture del dominio del problema. • Formalizzazione: le conoscenze e le relazioni fra le entit` individuate ed a 7

1.1. SISTEMI ESPERTI organizzate nelle fasi precedenti vengono concretizzate tramite l’uso di un formalismo concordato dai membri appartenenti al team di sviluppo del sistema. In questa fase vengono eseguite le scelte relative alla tipologia di rappresentazione della conoscenza da adottare e gli strumenti da adoperare. • Implementazione: gli elementi ottenuti nei passi precedenti vengono convertiti in un artefatto completo. • Testing: l’artefatto viene sottoposto alla valutazione dell’esperto di dominio. Ne vengono valutate l’utilit` e le prestazioni e verificata la cora rispondenza con i requisiti fissati nelle fasi precedenti. In questa fase viene infine valutata la possibilit` apportare modifiche, correggere dia fetti o integrare nuovi elementi nella strategia di controllo o nella base di conoscenza. Il processo di acquisizione della conoscenza e sviluppo del sistema, sebbene possa sembrare rigoroso, non ` affatto un processo lineare. Ad ogni e fase viene associata un’attivit` di verifica e raffinamento eseguita tramite la a consultazione dell’esperto di dominio. L’attivit` di estrazione della conoscenza eseguita nelle fasi iniziali dello a sviluppo non ` un processo accurato o esente da errori: durante le intervie ste condotte dagli ingegneri della conoscenza, spesso, elementi importanti nell’ambito del dominio del problema vengono trasferiti dall’esperto in maniera imprecisa, errata o non esplicitati affatto (pi` o meno consapevolmenu te) [Jac99] [SC84] [BD83].

8

1.1. SISTEMI ESPERTI Inoltre, la natura stessa del sistema (un prodotto nel quale il ragionamento, chiave del funzionamento, viene portato avanti tramite euristiche e l’approssimazione dei modelli di ragionamento umani) lo rende un artefatto perennemente incompiuto: sar` sempre possibile integrare nuova conoscenza a proveniente dall’esperto nella forma di nuovi concetti, relazioni o nuove dinamiche di controllo, modificare componenti del sistema per incrementare le prestazioni o incrementare l’affidabilit` del sistema, aggiungendo nuove euria stiche in grado di comprendere situazioni particolari che generavano risultati errati in versioni precedenti.

1.1.3

Rappresentazione della conoscenza

La conoscenza umana pu` essere raggruppata genericamente in conoscenza o dichiarativa, una forma di conoscenza esplicita rappresentante fatti, eventi ed esperienze consolidate nella forma di elementi memorizzabili, e conoscenza procedurale. La seconda rappresenta l’insieme di abilit` e conoscenze nell’ua tilizzo della conoscenza dichiarativa per lo svolgimento di una attivit` di a qualche genere. Nell’ambito dell’ingegneria della conoscenza e dei sistemi esperti, con l’espressione Rappresentazione della conoscenza si ` soliti riferirsi alle modalit` e a con le quali grandi quantit` di informazioni utili possono essere descritte a formalmente con la finalit` di essere sottoposte ad un qualche genere di a manipolazione simbolica [Jac99]. La descrizione formale impone l’uso di un linguaggio o una notazione non ambigua dotata di:

9

1.1. SISTEMI ESPERTI • una sintassi ben definita che governa le forme di espressione; • una semantica ben definita che riveli il significato delle espressioni in virt` della forma sintattica con la quale sono codificate. u Il processo di elaborazione di simboli e strutture simboliche rappresentanti concetti e relazioni fra gli stessi ` definito computazione simbolica. e Fra le modalit` di codifica della conoscenza suggerite negli anni sono a annoverabili Regole di produzione [DK75], Reti semantiche [Ric56], Frame [Min74] e Oggetti [HJW94a] [HJW94b]. Ognuna di queste tecniche presenta vantaggi e svantaggi: alcune permettono una estrema facilit` di modifica e a comprensione dei sistemi, mentre altre consentono un’alta efficienza nell’uso della memoria. Un approccio ideale allo sviluppo di un sistema esperto dovrebbe prevedere la possibilit` di utilizzare il maggior numero possibile di queste tecniche a di rappresentazione [Tsa+93], per offrire una pi` ampia possibilit` di scelta u a agli sviluppatori durante le fasi di design.

1.1.3.1

Regole di produzione

La pi` nota forma di rappresentazione della conoscenza ` quella basata su u e ` regole. E probabilmente un assioma dell’intelligenza artificiale, e della moderna psicologia, che comportamenti ritenuti intelligenti siano governati da regole. Anche nel mondo, le persone tendono ad associare intelligenza con coerenza nei comportamenti, e spesso il concetto di comportamento viene spiegato facendo riferimento a quello di regolarit` [Jac99]. Inoltre, un forte a gruppo di esponenti di spicco nell’ambito delle scienze cognitive ha postulato 10

1.1. SISTEMI ESPERTI la possibilit` di rappresentare grande parte del ragionamento umano stesso a nella forma di regole [And93]. Questi presupposti hanno reso le regole una delle tecniche di maggiore interesse nell’ambito dello sviluppo dei sistemi. Le regole di produzione sono un formalismo utilizzato, in origine, nello studio delle macchine astratte, delle grammatiche formali e nella progettazione dei linguaggi di programmazione. Successivamente il loro utilizzo ` e approdato all’ambito dei sistemi esperti e dell’intelligenza artificiale. Nella letteratura tecnica sono anche identificate come Regole condizione-azione o Regole situazione-azione. Questa nomenclatura risulta appropriata in quanto le regole sono spesso utilizzate per rappresentare, in forma codificata, associazioni fra pattern 3 di dati presenti nel sistema e sequenze di azioni che il sistema stesso dovrebbe eseguire come conseguenza di un riscontro. La funzione delle regole ` precisamente quella di specificare un comportamento: forniti e insiemi di dati (astraendo dalla particolare interpretazione), determinano i risultati da concretizzare. Le produzioni sono regole per la manipolazione di stringhe di simboli, chiamate spesso ”regole di riscrittura”. Post [Pos43] ha studiato le propriet` a dei sistemi basati su produzioni, chiamandoli Sistemi Canonici. Questi ultimi sono definiti come un tipo di sistemi formali basato su: • un alfabeto A per la creazione di stringhe • un insieme di stringhe considerate come assiomi
3

Schemi di caratteristiche individuate su un insieme di elementi

11

1.1. SISTEMI ESPERTI • un insieme di produzioni nella forma:

α1 $1 . . . αm $m → β1 $1 . . . βn $n

dove – ogni elemento αi e βi rappresenta una stringa – gli elementi α1 e αm sono spesso nulli – alcuni o addirittura tutti gli elementi αi o βi possono essere nulli – ogni $i rappresenta una stringa variabile (che pu` essere la stringa o nulla) – ogni elemento $i ` sostituito da uno $i . e Nell’ambito pi` specifico dei sistemi a produzione, le regole determinano u come le strutture simboliche che rappresentano lo stato corrente del sistema debbano essere manipolate per avvicinare la rappresentazione stessa dello stato ad una soluzione. L’attivazione progressiva delle regole produce una catena di inferenza. Il concetto di regole utilizzato all’interno dei sistemi esperti differisce da quello generico di regole di riscrittura sotto aspetti superficiali, ma mantene gli stessi principi fondamentali e le stesse propriet` formali. Se da una parte a nelle regole di riscrittura l’interesse ` focalizzato sulla grammatica in s´, nele e l’uso delle regole come mezzi di rappresentazione della conoscenza all’interno di sistemi esperti l’interesse ` concentrato sul processo di trasformazione di e una istanza del problema originale in un forma che ne rappresenti una soluzione. Conseguentemente l’alfabeto dei sistemi canonici ` rimpiazzato da e 12

1.1. SISTEMI ESPERTI un vocabolario di simboli o atomi e da una grammatica relativamente semplice per la generazione di strutture simboliche. Normalmente il vocabolario consiste di tre insiemi: • un insieme N di nomi di oggetti del dominio • un insieme P di nomi di propriet` che specificano attributi di un oggetto a • un insieme V di valori che questi attributi possono assumere. Generalmente la grammatica utilizzata prevede la specifica di triple oggettoattributo-valore, ma questo assunto non lede la possibilit` di specifiche pi` a u espressive [Jac99]. Una volta descritti un vocabolario di simboli e una grammatica per la generazione di strutture simboliche, ` possibile generare una codifica della e descrizione di uno stato iniziale di un problema di interesse. Questa descrizione corrisponder` esattamente agli assiomi previsti nella definizione di sia stema canonico. La descrizione originale del problema verr` progressivamente a riscritta tramite una serie di applicazioni. Un sistema a produzioni consiste di un rules-set (spesso anche definito come memoria delle produzioni), un rules-interpreter che verifica l’applicabilit` a delle regole e una memoria di lavoro. Il ruolo di quest’ultima componente ` e quella di memorizzare la descrizione iniziale del sistema, la descrizione finale attesa e gli stati intermedi prodotti durante la fase di elaborazione. La possibilit` di attivazione delle regole ` governata dall’interprete, il quale confronta a e la descrizione intermedia del sistema con l’insieme di regole e decide quale applicare. L’applicazione stessa delle regole (in un processo analogo a quello 13

1.1. SISTEMI ESPERTI descritto per la riscrittura simbolica) modifica ulteriormente la descrizione del sistema presente nella working memory. Schematicamente questo processo pu` essere descritto nella forma geneo rale C1 , . . . , Cn → A1 , . . . , An interpretabile come: [if ] le condizioni C1 e . . . e Cn sono vere, [then] esegui le azioni A1 e . . . e An . Con i termini left-hand side e right-hand side si ` soliti indicare rispettie vamente la porzione di condizione e quella di azione di una regola.

1.1.3.2

Reti semantiche

Un’altra tecnica di rappresentazione della conoscenza usa strutture chiamate reti semantiche. I nodi di queste reti sono costituiti da eventi, oggetti o concetti, che possono essere relazionati fra loro, tramite l’uso di archi di varia natura, per stabilire strutture gerarchiche fra i concetti stessi [Tsa+93]. Due esempi di relazioni molto comuni in questo tipo di rappresentazione sono quelle is-a e has-part. L’utilizzo di questa forma di rappresentazione associandola alle relazione is-a permette una memorizzazione efficiente delle propriet` dei concetti: data la natura gerarchica implicitamente indotta dalle a relazioni di ereditariet`, i nodi posti al pi` basso livello della rete eviteranno a u la ridefinizione di propriet` gi` deducibili dai concetti ai quali questi ultimi a a sono relazionati.

14

1.1. SISTEMI ESPERTI La definizione offerta da R. H. Richens, ideatore delle reti semantiche, spiega le stesse come ”una interlingua nella quale tutte le peculiarit` strutturali del a linguaggio di base sono rimosse e siamo lasciati con solo quello che io chiamo una rete semantica di idee spoglie. In questa rete gli elementi rappresentano cose, qualit` o relazioni . . . [ o] punti a di collegamento fra cose verso le proprie qualit` o relazioni, o da a qualit` e relazioni verso un’ulteriore qualificazione.” [Ric56] a

1.1.3.3

Frame

Il concetto di ereditariet` introdotto dalle reti semantiche viene ulteriormente a esteso dal concetto di Frame. ”Un frame ` una struttura dati per la rappresentazione di situae zioni stereotipate. [. . . ] Diverse tipologie di informazioni vengono collegate a ciascun frame. Alcune di queste informazioni riguardano l’utilizzo dello stesso. Altre sono a proposito di quello che ci si pu` attendere. Altre riguardano cosa fare se queste attese non o sono confermate.” [Min74] La struttura dei frame pu` essere immaginata come una rete di nodi e o relazioni. I nodi principali, posti alla testa della gerarchia, sono fissi e rappresentano concetti ed informazioni che sono assiomaticamente veri in una situazione. A questi nodi vengono collegati, nei livelli via via pi` bassi, diveru si terminali. Questi ultimi rappresentano slot che devono essere riempiti da

15

1.1. SISTEMI ESPERTI specifiche istanze o dati. Ogni terminale ha la possibilit` di specificare cona dizioni che devono risultare verificate per permettere la modifica o l’accesso ai dati contenuti negli slot. Le forme pi` semplici di condizioni possono richiedere l’intervento dell’uu tente per fornire dati da assegnare a specifici slot, condizioni pi` complesse u possono invece essere utilizzate per collegare fra loro informazioni disponibili in diversi altri terminali. Il contenuto degli slot pu` essere un’informazione atomica o un’ulteriore o sotto-struttura frame. L’utilizzo di strutture nidificate permette la creazione di ulteriori livelli gerarchici con estrema facilit` [Min74]. a

1.1.3.4

Oggetti

Nell’approccio object-oriented alla rappresentazione della conoscenza, gli oggetti descrivono una strategia di rappresentazione derivata da quella dei frame. Da quest’ultima strategia, essi ereditano i concetti di relazione, slot e l’organizzazione gerarchica fra gli elementi stessi [HJW94a]. L’innovazione introdotta dall’approccio basato su oggetti ` quella di consentire la comue nicazione fra gli oggetti stessi attraverso un protocollo basato sullo scambio di messaggi: in seguito alla ricezione di un messaggio, un oggetto attiva una procedura appropriata e valuta se propagare o meno ad altri oggetti, con cui lo stesso ` in relazione, il segnale originale o una sua versione e modificata [Tsa+93]. Il paradigma basato su oggetti realizza una modalit` generale di rapprea sentazione e di manipolazione della conoscenza. La sua importanza ` data e sia dalla capacit` di caratterizzazione della conoscenza, sia dalla variet` di a a 16

1.1. SISTEMI ESPERTI tecniche che questo tipo di formalismo consente di integrare all’interno di ogni genere di sistema [HJW94a].

1.1.4
1.1.4.1

Ragionamento basato su regole
L’inferenza e il motore inferenziale

L’inferenza ` un processo logico che consente di derivare da premesse, accolte e come vere, ulteriori proposizioni la cui veridicit` ` dedotta dalle prime. ae Il processo di inferenza viene regolato da meccanismi logici detti regole di inferenza. Un esempio classico ` quello offerto dalla regola di inferenza nota e con il nome di modus ponens riassumibile con: Se p implica q ` una proposizione vera e anche la premessa p ` e e vera, allora la conseguenza q ` vera. e Il motore inferenziale rappresenta il nucleo centrale di ogni sistema esperto: ` il componente con il compito di contenere e gestire l’ordine di applicae zione della conoscenza procedurale al fine del raggiungimento dell’obiettivo che il sistema ` progettato per perseguire. Il nome attribuito a questo come ponente deriva proprio dal fatto che il suo obiettivo ` quello di simulare il e ragionamento umano attraverso l’applicazione di regole di inferenza e derivare risposte dalla base di conoscenza. Le sue attivit` sono in realt` una sintesi del lavoro svolto da due coma a ponenti distinte che esso comprende al suo interno: l’interprete e lo scheduler [Tsa+93].

17

1.1. SISTEMI ESPERTI Interprete Il ruolo dell’interprete pu` essere riassunto nei termini del ciclo o recognize-act, un processo iterato suddiviso in tre fasi consecutive ed eseguito con l’obiettivo di manipolare la descrizione del problema contenuta nella memoria di lavoro. Le fasi che costituiscono il ciclo recognize-act sono: (1) Confrontare la descrizione dello stato presente nella memoria di lavoro (la descrizione parziale dello stato del problema) con l’insieme di premesse disponibili. (2) Valutare l’elenco delle regole le cui premesse risultano completamente soddisfatte e selezionarne una4 da applicare. (3) Applicare la regola: l’applicazione consiste nell’esecuzione di ognuna delle azioni contenute nella porzione RHS della regola La fase (2) dell’interprete ` delegata alle funzioni dello Scheduler. e

Scheduler Le funzioni svolte dallo Scheduler sono quelle di decidere l’ordine di applicazione di porzioni di conoscenza di dominio [Tsa+93]. Facendo riferimento ad un ipotetico motore inferenziale che utilizza una strategia di controllo basata su regole, questo componente utilizza una serie di criteri eseguendo una selezione fra le attivazioni disponibili. Le euristiche utilizzate per la selezione possono essere incluse in origine nell’ambiente di sviluppo o richiedere l’intervento dello sviluppatore per essere specificate. ´ E questo elemento a costituire la differenza fra logiche di controllo globali e locali.
La restrizione di selezione di una singola regola fra quelle applicabili pu` anche essere o sostituita da strategie di gestione dei conflitti che prevedono la selezione di un gruppo di regole fra le applicabili, come mostrato da [Doo95]
4

18

1.1. SISTEMI ESPERTI Logiche globali Rappresentano un gruppo di strategie indipendenti dal dominio applicativo, normalmente incluse in origine nel motore inferenziale, e che non richiedono l’intervento dello sviluppatore per essere specificate. L’unica possibilit` offerta ` quella di scegliere una fra le diverse strategie a e fornita dal sistema. La personalizzazione della sequenza di esecuzione viene quindi delegata ad apposite strategie di controllo basate su rappresentazioni specifiche dei dati nella working memory. Spesso le strategie di controllo della catena di inferenza sono il sunto della combinazione di differenti meccanismi di base, ognuno dei quali si basa su differenti propriet`. Le buone prestazioni di un sistema esperto spesso a dipendono da propriet` chiave di questi regimi di controllo [Jac99], come la a sensibilit` o la stabilit`. a a ”Un sistema che dimostri reattivit` alle necessit` del suo ambiente a a si pu` affermare che dimostri sensibilit`. Uno che ` capace di o a e mantenere una continuit` nei suoi comportamenti, si pu` dire a o che mostri stabilit`.” [MF77] a La prima indica la capacit` di una logica di adattarsi con rapidit` a modifiche a a dell’ambiente che si riflettono nelle descrizioni nella memoria di lavoro, la seconda indica il grado di coerenza nella linea di ragionamento [Jac99]. Nonostante i meccanismi di risoluzione dei conflitti variino molto da sistema a sistema, la popolarit` di alcune caratteristiche presenti in molti di a essi richiede un approfondimento: • Refrattariet` : propriet` che non consente ad una attivazione di essea a re eseguita pi` di una volta sullo stesso gruppo di dati. Se vengono u 19

1.1. SISTEMI ESPERTI riscontrate pi` attivazioni con i medesimi dati, sono semplicemente u ignorate. • Attualit` : agli elementi all’interno della memoria di lavoro vengono apa plicate delle etichette temporali. L’inferenza verr` quindi sviluppata a tenendo conto dell’attualit` degli elementi. a • Specificit` : le attivazioni vengono selezionate in base a criteri legati alla a specificit` dei pattern che trovano riscontro con la descrizione presente a nella memoria di lavoro.

Logiche locali Le strategie di controllo locali offrono un pi` alto grado u di personalizzazione allo sviluppatore, ma con esso anche maggiori responsabilit`. E infatti onere dei progettista quello di specificare un apposito insieme a ` di meta-regole che consentano la discriminazione delle attivazioni e l’individuazione della pi` opportuna da attivare in base allo stato del sistema. u La selezione viene eseguita basandosi sulla conoscenza di dominio inserita all’interno delle meta-regole.

1.1.4.2

Sistemi basati su regole di produzione

La specifica appena proposta di motore inferenziale pu` essere ulteriormente o dettagliata focalizzando la descrizione all’interno dell’ambito di sistemi basati su regole di produzione. I sistemi basati su regole di produzione rappresentano la prima, e probabilmente la pi` semplice, modalit` di sviluppo di sistemi inferenziali. La u a

20

1.1. SISTEMI ESPERTI rappresentazione della conoscenza all’interno di questa classe di sistemi viene affidata al formalismo basato su regole di produzione. I regimi di controllo dell’inferenza in questa categoria di sistemi si basano spesso su algoritmi come il Forward Chaining e il Backward Chaining.

Forward chaining Il forward chaining pu` essere descritto come applio cazione ripetuta del modus ponens. Partendo da una serie di condizioni la cui validit` ` assiomatica o appurata, il sistema crea una catena di inferenza ae estraendo nuova conoscenza da quella disponibile fino a quando non viene individuata una descrizione della soluzione, non ` stato raggiunto un obiettivo e o non ` possibile effettuare ulteriore inferenza. e Nei motori inferenziali che utilizzano questa strategia di controllo, il rulesset viene scandito alla ricerca di regole la cui parte condizione (LHS ) risulti verificata dalla descrizione dello stato disponibile nella memoria di lavoro. Una volta identificato almeno un riscontro, ` possibile logicamente concludere e che la parte conseguente (RHS ) risulter` anch’essa verificata nella descrizione a dello stato. L’applicazione della parte azione produrr` una modifica della a descrizione dello stato5 . La concatenazione in avanti ` un esempio del concetto generale di rae gionamento guidato dai dati, in cui l’attenzione parte dai fatti conosciuti. Ogni volta che viene aggiunta nuova informazione, una certa quantit` di raa gionamento viene generato e guidato dai dati aggiunti. Il maggior pericolo derivante da questo tipo di inferenza ` che un enorme numero di conseguenze e
La modifica dello stato avviene solitamente attraverso l’asserzione o la ritrattazione di fatti nella working memory.
5

21

1.1. SISTEMI ESPERTI irrilevanti possa distogliere l’attenzione da un numero ridotto di conseguenze rilevanti e indispensabili per giungere ad una soluzione del problema [RN09].

Backward chaining L’algoritmo di concatenazione all’indietro, o backward chaining, parte da una conclusione desiderata (un obiettivo, una descrizione della soluzione di un problema) e lavora a ritroso scandendo tutta la base di conoscenza alla ricerca di implicazioni che verifichino la conclusione desiderata: qualora tutte le precondizioni dell’implicazione individuata risultino vere allora anche la conclusione risulter` vera, in caso contraa rio il processo di ricerca a ritroso verr` ripetuto per le precondizioni non a soddisfatte. La concatenazione all’indietro ` una forma di ragionamento basato sugli e obiettivi. Spesso il costo dell’utilizzo di questa strategia di inferenza ` infee riore rispetto a quello dell’utilizzo del forward chaining in quanto il processo coinvolge solo i fatti rilevanti [RN09].

1.1.5

RETE: matching fra regole e stato

Il 90% dello sforzo elaborativo svolto da un sistema esperto basato su regole di produzione ` concentrato nelle attivit` svolte dall’interprete [For82]. Vee a rificare quali regole siano applicabili e per quali descrizioni ` una operazione e di grande impatto in quanto obbliga a confrontare spesso grandi quantit` di a conoscenza con un grande numero di elementi presenti nella working memory. L’algoritmo di forward chaining rappresenta una modalit` di controla lo dell’inferenza progettata per risultare di facile comprensione ed utilizzo. Porta con s´, per`, tre criticit` di grande rilevanza [RN09]: e o a 22

1.1. SISTEMI ESPERTI • il ciclo interno dell’algoritmo prevede la ricerca di tutti i matcher tali che le premesse di una regola possano trovare riscontro con un insieme adeguato di dati presenti nella working memory. Questa operazione ` e definita unificazione. • per ogni iterazione, la ricerca nel rules-set deve essere ripetuta completamente anche nei casi in cui le modifiche alla working memory siano di piccola entit`. a • l’impostazione stessa dell’algoritmo comporta il rischio di generazione di un grande numero di dati irrilevanti per il raggiungimento dell’obiettivo. Prendendo in esame un’ipotetica configurazione di una regola in cui la precondizione sia costituita da un singolo pattern, la verifica dell’applicabilit` a della regola prevede la ricerca all’interno della working memory di un singolo elemento in grado di verificare la condizione. L’operazione, se eseguita in una base di conoscenza opportunamente indicizzata, pu` essere completata o in tempo costante per ogni fatto [RN09]. Aumentando il numero di pattern presenti all’interno della porzione LHS di una regola, il confronto deve essere eseguito per ogni pattern individualmente. In seguito, qualora sia necessario eseguire dei test di coerenza cui matcher comuni a pi` pattern, l’operazione u di confronto va ripetuta per ogni possibile combinazione dei fatti individuati dalle singole condizioni. L’algoritmo RETE si propone come una soluzione efficiente per il problema di pattern matching. Proposto per la prima volta nel 1979 dal C. L. Forgy [For79] [For82], l’algoritmo affronta il problema partendo da una sem23

1.1. SISTEMI ESPERTI plice considerazione: l’applicazione di una regola genera piccoli cambiamenti nello stato del sistema e spesso questi cambiamenti minimi non richiedono una valutazione completa dell’intero rules-set. Le criticit` principali di una a formulazione na¨ di un algoritmo di matching derivano proprio dalla neıve cessit` di eseguire una scansione completa dell’intera base di conoscenza e a dell’intera memoria di lavoro per ogni cambiamento dello stato del sistema. La soluzione propone i miglioramenti sintetizzandoli in due cambiamenti principali: • evitare di scandire l’intera working memory per trovare nuovi riscontri per i singoli pattern; • evitare di scandire l’intero rules-set per trovare nuove attivazioni. La scansione dell’intera working memory viene evitata memorizzando, in unit` di memoria dedicate per ogni pattern, la lista di elementi che risultano a coerenti con il pattern stesso. Queste unit` di memoria vengono aggiornate a in linea con i cambiamenti della working memory. Quando un nuovo elemento viene asserito (Figura 1.3), e quindi entra a far parte della descrizione dello stato fornita dalla working memory, l’algoritmo esegue una valutazione di ogni pattern singolarmente per il nuovo elemento aggiunto, e solo in caso di verifica positiva l’elemento stesso viene inserito all’interno dell’unit` di memoria locale [For82]. a Quando un elemento fuoriesce dalla working memory, lo stesso viene rimosso da tutte le unit` di memoria locali dei pattern in cui l’elemento ` a e memorizzato. Il processo di ricerca pu` avvenire ripetendo nuovamente le o verifiche per i singoli pattern [For82] oppure, pi` efficientemente, tenendo in u 24

1.1. SISTEMI ESPERTI

Aggiunto WME: <A, B, C>

Pattern-1 wme[1] = A AND wme[3] = C

Pattern-2 wme[1] = G

...

X
Alpha-Memory-1 […, <A,B,C>,…] Alpha-Memory-2

Figura 1.3: Asserzione di un nuovo elemento della working memory e valutazione tramite algoritmo RETE una porzione di memoria separata una lista di collegamenti fra elementi e le memorie in cui essi sono contenuti [Doo95]. La scansione dell’intero rules-set viene evitata attraverso l’utilizzo di una struttura a grafo per la rappresentazione delle regole. In seguito ad una fase di compilazione (Figura 1.4), la porzione LHS delle regole viene scomposta nei singoli pattern. Per ognuno di essi viene realizzata, qualora non fosse possibile condividere una struttura analoga creata precedentemente, un circuito di nodi in grado di eseguire dei test su singoli elementi della working memory. Come ultimo elemento del circuito viene aggiunta un’unit` di memoria a locale, denominata Alpha-Memory, la quale accoglier` l’insieme di elementi a che, singolarmente, hanno verificato l’elenco di condizioni che il circuito de-

25

1.1. SISTEMI ESPERTI scrive [Doo95]. L’insieme di circuiti derivanti dalla compilazione dei singoli pattern prende il nome di Alpha-Network. Una seconda porzione della rete ` quella nota con il nome di Betae Network. In questa sezione vengono eseguiti i test di coerenza sul binding delle variabili fra le condizioni. Durante la fase di compilazione, una volta create le porzioni alpha di ogni singolo pattern, quelli appartenenti alla stessa LSH vengono collegati fra loro attraverso l’uso di speciali nodi, chiamati Join-Node. Questi nodi, oltre a riunire singoli pattern in una catena che rappresenti l’intera LHS, hanno il compito di eseguire l’insieme di test necessari alle verifiche di coerenza sul valore delle variabili, dove necessario. Qualora i test eseguiti in questi nodi a due input risultassero positivi, verrebbe creata una struttura contenente i due elementi della memoria di lavoro che sono risultati coerenti e la stessa memorizzata all’interno di una unit` di memoa ria agganciata direttamente al Join-Node. La struttura prende il nome di Token 6 . L’utilizzo di un ulteriore tipo di memoria nella Beta-Network, chiamata Beta-Memory, consente di memorizzare attivazioni parziali che risultano valide solo per una porzione della regola, in attesa, che tramite l’asserzione di ulteriori fatti, l’intera regola risulti attivabile. Il processo di trasformazione delle regole porta a due benefici sostanziali: • la compilazione dei singoli pattern eseguita per la formazione dell’alphaNella formulazione dell’algoritmo proposto originariamente in [For79] e [For82] con il termine Token si faceva riferimento a una descrizione di un cambiamento nella working memory, notificato ai nodi componenti la rete tramite l’uso di tag. La formulazione proposta in [Doo95] utilizza l’appellativo per indicare una sequenza di working memory elements che abbiano verificato una porzione della beta-network. Il concetto di tag, usati nella prima formulazione per indicare il tipo di modifica che il token rappresentava, nella seconda formulazione ` completamente assente e
6

26

1.1. SISTEMI ESPERTI

RETE per Regola
IF: A <x> C /* Pattern-1 */ C <x> A /* Pattern-2 */ THEN: ….. Root Node Working Memory Elements

Alpha-test per Pattern-1 ALPHA-NETWORK Alpha-Memory Pattern-1

Alpha-test per Pattern-2

Alpha-Memory Pattern-2

Join: P1 AND P2 BETA-NETWORK Beta-Memory P1 AND P2

Regola [RHS]

Figura 1.4: Rappresentazione esplicita del grafo ottenuto dalla compilazione di una regola: vengono creati circuiti alpha per ogni pattern e in seguito congiunti valutando la coerenza del valore della variabile x fra i riscontri.

27

1.1. SISTEMI ESPERTI network consente di partizionare la working-memory in frammenti di minori dimensioni. Questo si traduce in un minor numero di confronti durante i test di coerenza. Inoltre, pattern simili presenti in pi` regole u vengono accorpati e rappresentati da un unico circuito alpha. La fase di valutazione verr` eseguita soltanto una volta per tipo di pattern. a • gruppi di pattern simili, analogamente a quanto descritto nel punto precedente, vengono accorpati in un solo circuito beta, riducendo ulteriormente i costi delle verifiche per i test di coerenza. Il processo di creazione della rete pu` avvenire attraverso un reale proo cesso di compilazione [For82] che prevede la conversione dell’intero rules-set in una sequenza di istruzioni ed espressioni che rappresentino le varie condizioni (implementazione compilata), oppure attraverso un processo di creazione di una rappresentazione esplicita di grafo nelle modalit` citate poc’anzi a (implementazione interpretata). Il vantaggio della prima variante ` la maggiore velocit`, che contrasta e a tuttavia con un maggior consumo di memoria e maggiore difficolt` di ima plementare procedure che, attraverso l’aggiunta o la rimozione di produzioni durante l’esecuzione, siano in grado di alterare la struttura della rete [Doo95]. La seconda variante rende pi` semplice l’implementazione di procedure di u manipolazione della rete e risulta globalmente di pi` facile implementazione u e comprensione. Purtroppo questi vantaggi prevedono uno scambio di tipo prestazionale [Doo95].

28

1.2. STRUMENTI DI SVILUPPO

1.2

Strumenti di sviluppo

Tutti gli strumenti di sviluppo per sistemi esperti sono orientati a supportare la creazione di prototipi. Un prototipo rappresenta un modello funzionante le cui funzionalit` sono equivalenti ad una porzione ridotta di quelle del prodota to finale [Jac99]. L’idea ` quella di sviluppare, nelle prime fasi del progetto, e dei ”proof of concept” che possano essere valutati e criticati da esperti e utenti e che siano in grado di risolvere parti del problema. Questa attivit` ` ae utilizzata soprattutto come un’opportunit` per definire meglio requisiti e ina dividuare criticit`, verificando inoltre l’effettiva trattabilit` di problematiche a a prima di effettuare investimenti eccessivi. Una possibilit` ` che gli artefatti prodotti vengano quindi scartati al terae mine delle valutazioni, ma gli approcci verificati con la produzione dei prototipi stessi vengono conservati e riapplicati durante la fare di sviluppo reale del prodotto. Altre modalit` prevedono l’accorpamento e sviluppo incremena tale delle funzionalit` del prodotto finale tramite fasi reiterate di produzione a di protitipi e valutazione. Il numero di ambienti di sviluppo per sistemi esperti ` cresciuto negli e anni e con esso il numero e la tipologia di funzionalit` offerte. L’evoluzione a di questi sistemi ` stata motivata con il tempo e la quantit` di sforzo richiesto e a per la costruzione di sistemi esperti. Lo sviluppo si ` focalizzato in molte aree di interesse, spaziando dale l’ambito delle modalit` di rappresentazione della conoscenza a quello dei a meccanismi di inferenza, dallo sviluppo di regimi di controllo alla ricerca nell’ambito dei linguaggi di specifica. Indipendentemente dalle modalit` con le a

29

1.2. STRUMENTI DI SVILUPPO quali ` stato tentato il miglioramento, lo slancio evolutivo era ad ogni modo e focalizzato nell’ambito di: • ridurre tempi e costi di sviluppo dei sistemi esperti • migliorare l’affidabilit` e la qualit` generale dei sistemi prodotti a a • focalizzare le attivit` delle varie figure professionali interessate nello a sviluppo negli ambiti di propria competenza. • separare le attivit` di analisi della conoscenza da quelle legate allo a sviluppo del prodotto. • fornire strumenti per velocizzare e migliorare le attivit` di acquisizione a e aggiornamento della conoscenza. I miglioramenti hanno incrementato in questo modo le possibilit` di suca cesso nello sviluppo di sistemi esperti. Come ulteriore effetto, il ridursi della complessit` generale delle operazioni di realizzazione ha consentito di gestire a e produrre soluzioni di sempre maggiore complessit`. a

1.2.1

L’evoluzione degli strumenti di sviluppo

Tornando indietro agli albori della produzione di sistemi esperti, i meccanismi di inferenza e le basi di conoscenza erano accoppiati fra loro. La prima generazione di sistemi non erano altro che grandi applicazioni scritte in linguaggi come LISP [Wan+93]. Nonostante tutti i linguaggi di programmazione potessero essere utilizzati per la produzione di sistemi esperti, alcuni di essi offrivano caratteristiche che 30

1.2. STRUMENTI DI SVILUPPO rendevano tale attivit` pi` agevole. Rientrano in questa categoria linguaggi a u largamente utilizzati nelle prime fasi come il LISP e Prolog. Purtroppo, la quantit` di tempo e sforzo richiesto per la produzione usando queste tipoa logie di linguaggi diventava rapidamente insostenibile con l’aumentare della complessit`. Inoltre, l’accoppiamento fra le funzionalit` necessarie all’infea a renza e quelle per la rappresentazione e la gestione della conoscenza non permetteva una distinzione di ruoli fra gli ingegneri di sistema e quelli della conoscenza [Tsa+93]. Questo approccio alla lavorazione venne superato nella successiva generazione. Durante la creazione di sistemi di seconda generazione come MYCIN, i ricercatori si accorsero dell’importanza di implementare i sistemi in modo che fosse possibile una separazione fra la base di conoscenza e i meccanismi che realizzavano il ragionamento. Rimuovendo la conoscenza di dominio da questi sistemi vennero realizzati i primi sistemi di tipo Skeletal Shell : utilizzando gli strumenti sviluppati nel progetto originale e inserendo nuova conoscenza di dominio era possibile creare una grande verit` di nuovi sistemi esperti con un sforzo relativamente a ridotto. I sistemi di seconda generazione di maggior successo hanno dato vita a Shell per lo sviluppo di sistemi esperti. Ne sono esempi EMYCIN, KAS e EXPERT: rispettivamente prodotti rimuovendo le conoscenze di dominio da MYCIN, PROSPECTOR e CASNET. Sebbene l’utilizzo di questi strumenti velocizzasse la produzione di nuovi sistemi di diversi ordini di grandezza, la necessit` di attenersi alle strategie utilizzate nei sistemi originali rappresena tava un limite alla flessibilit` del sistema ed ai possibili ambiti di utilizzo a (Figura 1.5). 31

1.2. STRUMENTI DI SVILUPPO

Linguaggi
PROLOG, LISP, C, C++, ...

Environment
OPS5, OPS83, CLIPS, JESS, ...

Exp. Sys. Shell
EMYCIN, KAS, EXPERT, ...

FLESSIBILITÀ TEMPI DI SVILUPPO FACILITÀ D’USO

Figura 1.5: Classificazione degli strumenti di sviluppo per sistemi esperti Il successivo passo evolutivo fu compiuto con l’introduzione di linguaggi di alto livello orientati alla realizzazione di sistemi esperti e gli ambienti di programmazione multi-paradigmatici. I primi, introdotti nella seconda met` a degli anni ’70, consentivano grande flessibilit` e permettevano di svolgere a attivit` di prototipazione rapida. Queste caratteristiche si traducevano nella a possibilit` di sperimentare e valutare soluzioni progettuali con costi e tema pi relativamente contenuti. Inoltre, per la natura stessa degli strumenti, il codice prodotto poteva essere testato in maniera incrementale durante la scrittura (possibilit` offerta dal fatto che le interfacce runtime e buildtime a erano prossime fra loro) [Jac99]. Spesso, questo tipo di shell limitava la propria offerta ad un particolare tipo di formalismo per la rappresentazione della conoscenza oppure un particolare regime di controllo. La flessibilit` offerta dai linguaggi di alto livello a risiedeva proprio nella possibilit`, per il progettista, di accedere ad approcci a differenti e in questo modo spaziare fra meccanismi multipli. Gli ambienti di programmazione multi-paradigmatici o Expert System Environment accoppiavano la filosofia alla base dei linguaggi di alto livello 32

1.2. STRUMENTI DI SVILUPPO con la possibilit` di usufruire di differenti modalit` di rappresentazione dela a la conoscenza, regimi di controllo e paradigmi di programmazione in base alle esigenze. Questo genere di strumenti permetteva ai programmatori di selezionare e combinare differenti moduli software. In assenza di un singolo linguaggio di rappresentazione della conoscenza che fosse valido per ogni applicazione, la soluzione era quella di fornire e rendere disponibile pi` di uno u schema contemporaneamente. ”Sebbene non ci sia una teoria ben articolata sui sistemi basati su approccio ibrido, l’esperienza con schemi di rappresentazione e inferenza differenti ha mostrato che ognuno ha le sue debolezze; quindi la strategia di miscelare gli schemi tenta di giocare il pi` u possibile con i loro punti di forza.” [Jac99]

Figura 1.6: Il logo di LOOPS: illustra i differenti paradigmi disponibili nell’environment. Immagine originale tratta da [Ste+83]. Il primo esempio di ambiente multi-paradigmatico a quattro schemi fu LOOPS (1983, Figura 1.6): fondeva insieme quattro paradigmi di programmazione (procedurale, basata su regole, orientata agli oggetti, orientata ai dati) all’interno di un’architettura basata sullo scambio di messaggi [Ste+83]. 33

1.2. STRUMENTI DI SVILUPPO

1.2.2

Skeletal Shell

Le Shell avevano l’obiettivo di consentire, anche a persone senza una esperienza specifica di programmazione tradizionale, di utilizzare gli sforzi compiuti da altri nell’ambito della soluzione di problematiche simili. Fu chiaro per` o che l’applicabilit` dell’architettura di base non era di tipo universale, seba bene consentisse di realizzare sistemi in ambiti simili a quelli per il quale il progetto era concepito. ”EMYCIN ` progettato per aiutare la costruzione e l’esecue zione di programmi che forniscono consigli. [. . . ] EMYCIN non ` progettato per essere un linguaggio di rape ` presentazione general-purpose. E completamente inadatto per alcuni problemi. Le limitazioni derivano in gran parte dal fatto che EMYCIN ha scelto un solo metodo per rappresentazione della conoscenza che fosse basilare, semplice da leggere e interpretare: regole di produzione applicate tramite un regime di controllo basato sul backward-chaining [. . . ]” [Aik+82] Un esempio risiede in EMYCIN: sebbene consentisse di utilizzare l’architettura alla base di MYCIN e applicarla anche ad altri domini specifici nell’ambito medico (PUFF [Aik+82]) o in altri ambiti (SACON [BE79]), la sua architettura non era abbastanza generalizzata per essere definita generalpurpose [BSM84]. Era tuttavia valido per sviluppare sistemi basati sull’uso di un approccio deduttivo a problemi diagnostici, dove ` disponibile una grane de quantit` di conoscenza ed ` possibile individuare e definire le categorie a e diagnostiche in anticipo. 34

1.2. STRUMENTI DI SVILUPPO A discapito dei vantaggi in termini di semplicit` nella rappresentazione a della conoscenza e della specifica del sistema offerti dai tool di tipo Skeletal Shell, le pi` grandi critiche a questa classe di sistemi risiedono in tre punti u principali [Aik83]: (1) Il formalismo basato solo su regole, che la grande maggioranza di questa classe di sistemi offriva, rendeva difficile la distinzione fra conoscenza di tipo euristico, quella di controllo e quella adibita alla valutazione dei parametri richiesti. Questa limitazione rendeva difficile la comprensione dei sistemi. (2) L’aggiornamento e l’aggiunta di nuova conoscenza in questi sistemi rendeva difficile effettuare previsioni sull’impatto che le modifiche avrebbero avuto sul sistema nella sua interezza. (3) La scelta di un preciso regime di controllo spesso si adattava bene ad alcune attivit`, mentre rendeva difficoltoso lo sviluppo di componenti a differenti dello stesso sistema (ad esempio, il regime basato su backwardchaining offerto da EMYCIN rendeva da una parte agevole il processo di diagnosi, ma dall’altra ardua la realizzazione delle dinamiche di spiegazione).

1.2.3

Expert System Environment

Le Shell di tipo general-purpose offrono un maggiore controllo e flessibilit` a rispetto alle Skeletal Shell rimuovendo diversi vincoli, ma questa ritrovata flessibilit` viene pagata con maggiori oneri a carico dei progettisti. a

35

1.2. STRUMENTI DI SVILUPPO Strumenti dotati di maggiore flessibilit` offrivano solo meccanismi di rapa presentazione e problem-solving basilari. Questo li rendeva adatti a qualsiasi ambito e problematica, ma il basso livello di sofisticazione obbligava gli ingegneri della conoscenza a specificare personalmente parte dei meccanismi di ragionamento e di rappresentazione. Esempi di questa sottoclasse di strumenti sono ROSIE, OPS5 e Prolog7 . Maggiore semplicit` era quella offerta invece dai sistemi come BLOBS, G2 a o CubiCal [Tsa+93]. Il loro ambito di utilizzo veniva ridotto, ma il maggiore livello di sofisticazione nelle forme ragionamento, unito alla disponibilit` a di paradigmi multipli per la rappresentazione della conoscenza, rendeva pi` u agevole lo sviluppo di sistemi esperti. Inoltre agli ingegneri della conoscenza era richiesta una minore conoscenza delle dinamiche del sistema di base. La modifica dei meccanismi di ragionamento era ancora possibile, anche se non obbligatoria. Gli strumenti posti al pi` alto grado di sofisticazione nella categoria degli u environment erano progettati per affrontare pi` aree di problemi. Offrivano u paradigmi multipli per la specifica della conoscenza e del ragionamento, uniti a caratteristiche e utilit` orientate allo sviluppo dei sistemi esperti ed alla a riduzione dei tempi di iterazione nei processi di prototipazione. La presenza di interpreti gi` integrati e di paradigmi multipli di rapa presentazione rendevano estremamente ridotto il carico degli ingegneri della conoscenza nella definizione dei nuovi sistemi. Nonostante tutto, la scelta di
Sebbene il Prolog sia un linguaggio di programmazione logica general-purpose, la disponibilit` di meccanismi di ragionamento basilari basati su un regime di tipo backwarda chaining e la forma dichiarativa del linguaggio che rende agevole la rappresentazione della conoscenza lo rendono ascrivibile anche alla categoria delle General-Purpose Shell
7

36

1.2. STRUMENTI DI SVILUPPO utilizzare alcune di queste funzionalit` portava ad influenzare fortemente il a design nei casi in cui i paradigmi offerti non corrispondessero perfettamente ai requisiti [Tsa+93].

1.2.3.1

ART (Automated Reasoning Tool)

ART ` uno dei primi strumenti di sviluppo per sistemi esperti scritti in LISP. e Offriva strutture come oggetti, regole di produzione, meccanismi per il mantenimento della catena di verit` ed integrava un paradigma di programmazione a orientato agli oggetti [Cha98].

1.2.3.2

ART-IM (ART for Information Management)

ART-IM ` una re-implementazione del sistema ART in linguaggio C, basato e su una versione proprietaria dell’algoritmo RETE per la realizzazione di un regime di tipo forward-chaining e un meccanismo di mantenimento della verit` (gi` presente in ART). a a Nonostante l’implementazione fosse fortemente incentrata sul motore inferenziale di tipo forward, il sistema permetteva anche ragionamento basato sulla concatenazione all’indietro. L’utilizzo del regime alternativo era per` o sottoposto alla necessit` di una specifica esplicita di strutture di controllo, a alla definizione di priorit` e obiettivi. a Una caratteristica importante introdotta nella re-implementazione in C era la possibilit` di integrare funzionalit` aggiuntive tramite lo sviluppo di a a funzioni separate, sempre in linguaggio C, ed integrabili durante la compilazione del sistema.

37

1.2. STRUMENTI DI SVILUPPO L’utilizzo di questa caratteristica ha permesso la realizzazione di ulteriori varianti (come ART-Ada [LA90], per l’utilizzo nella specifica dei sistemi tramite linguaggio ADA), rese disponibili in seguito. La grande variet` di funzionalit` e le potenzialit` offerte dal sistema nella a a a sua interezza lo rendevano per` uno strumento non adatto a progettisti alle o prime armi: era richiesta conoscenza dei linguaggi C e LISP oltre che del paradigma di sviluppo orientato agli oggetti [Tsa+93].

1.2.3.3

CLIPS (C Language Integrated Production System)

CLIPS ` un environment sviluppato al NASA Johnson Space Center nella e met` del 1980. Prende spunto da tool come OPS5 e ART, supportandone a le caratteristiche di maggior importanza e introducendone di nuove come le funzionalit` relative alla programmazione procedurale. a La sintassi utilizzata per lo sviluppo dei sistemi esperti ` simile a quella e del linguaggio LISP. Lo sviluppo inizi` in un contesto in cui erano emergenti, ma ancora costoo se, soluzioni di environment basati su linguaggio C. Il risultato ` il sistema e meno costoso e di maggiore reperibilit` al mondo, non meno efficiente di soa luzioni commerciali. La prima versione non integrava funzionalit` chiave ina trodotte solo successivamente, come il linguaggio procedurale e il paradigma di programmazione ad oggetti [Jac99]. Il sistema ` liberamente utilizzabile per uso personale ed accademico, e mentre l’uso commerciale ` soggetto all’acquisto di una licenza personale e una tantum.

38

1.2. STRUMENTI DI SVILUPPO Lo sviluppo del progetto, attualmente affidato ad una sola persona, ` e ancora in atto. Il codice sorgente ` disponibile pubblicamente, cosi come le e versioni compilate. Le prime versioni di CLIPS (poco pi` che prototipi, implementazioni u clean-room di caratteristiche di ART) [Cli92], utilizzavano un motore basato su una implementazione dell’algoritmo RETE con regime forward-chaining e specifica nella forma di regole di produzione. Il successo del progetto prima come training-tool, poi come reale ambiente di sviluppo e distribuzione di sistemi esperti, ha giustificato lo sviluppo di versioni successive. Il progetto ` stato esteso con l’integrazione del paradigma e procedurale e ad oggetti (COOL). Il successo di CLIPS ` attestato dal grande numero utilizzatori: una stima e realizzata nel 1992 indicava che fosse superiore a 3000, senza contare l’adozione all’interno del laboratori NASA, l’utilizzo in ambito militare, governativo, accademico e commerciale8 [Cli92]. Negli anni sono state derivate dal progetto originale diverse varianti che espandevano specifiche categorie di caratteristiche. Alcuni esempi sono ECLiPSe [Hal91], eCLIPS [HT99] e FuzzyCLIPS [Orc04].

1.2.3.4

JESS (Java Expert System Shell)

Nato originariamente come un clone di CLIPS, JESS ` un environment come pletamente scritto in Java con l’obiettivo di integrare le funzionalit` offerte a da CLIPS con tecnologie per il web basate su Java. Le prime versioni ofIl numero di download del sistema dalla piattaforma di distribuzione ufficiale negli ultimi 4 anni ha superato quota 200.000. Non sono presenti misurazioni nel periodo precedente al Gennaio 2008.
8

39

1.2. STRUMENTI DI SVILUPPO frivano il supporto ad un set limitato delle caratteristiche di CLIPS. Con il tempo lo sviluppo si ` diretto verso l’aggiunta di funzionalit` originali in e a maniera indipendente dal progetto padre, separando in questo modo i due progetti [Van99] [Jess08b] [Jess08a]. Sebbene JESS non integri un linguaggio di specifica di tipo object-oriented, la forte integrazione con il linguaggio Java con cui ` implementato consente e di utilizzare particolari notazioni, gli shadow-fact, per collegare elementi nella working-memory con istanze di classi specificate in linguaggio Java.

1.2.4

Il problema dell’integrazione

Molti degli strumenti originariamente progettati per lo sviluppo di sistemi esperti stand-alone non supportavano l’integrazione con altri componenti software di utilizzo comune come database o fogli di calcolo. A volte i linguaggi, o le piattaforme, scelti per l’implementazione di questi sistemi erano un freno alle possibilit` di integrazione. I primi strumenti basati sul lina guaggio LISP richiedevano apparecchiature appositamente sviluppate (LISPmachines) e grandi quantitativi di memoria. Questo si traduceva, oltre che nella richiesta di grandi investimenti, anche in architetture fortemente specializzate. Il grande costo di queste apparecchiature limitava anche le possibilit` a di diffusione e successo dei prodotti sviluppati con questi tool [Tsa+93]. Questi strumenti basati su LISP introducevano anche grossi problemi in termini di portabilit` degli artefatti prodotti [Cli92]. a Per superare questi ostacoli, molti dei tool originariamente sviluppati in LISP vennero con il tempo riscritti per essere utilizzati su piattaforme

40

1.2. STRUMENTI DI SVILUPPO emergenti di pi` grande diffusione (come le workstation e le piattaforme conu venzionali che utilizzavano Unix come sistema operativo prima, o i Personal Computer poi). Durante questo processo di conversione, la scelta di molti ricadde verso il linguaggio C, molto diffuso e supportato da tutte le piattaforme. L’adozione del C port` ad un incremento prestazionale dei sistemi o oltre ad offrire nuovi scenari in cui sperimentare l’integrazione fra il software disponibile sulle nuove piattaforme e gli strumenti di sviluppo per sistemi esperti. Prendendo in esame CLIPS, il sistema poteva essere integrato all’interno di qualsiasi applicazione che fosse in grado di interfacciarsi direttamente con librerie scritte in linguaggio C. JESS estende ulteriormente queste possibilit` tramite l’utilizzo di Java, linguaggio emergente negli ultimi anni sia a in ambiente coorporate che nei prodotti di largo consumo. Studi effettuati negli ultimi anni hanno analizzato l’efficienza, la facilit` a e le possibilit` offerte dallo sviluppo di software con vari linguaggi di proa grammazione [Nai99] [Zei95] [Pre00] [PVS08]. Sebbene questi studi abbiamo mostrato, come prevedibile, che le caratteristiche di particolari linguaggi si adattino meglio ad alcuni ambiti di utilizzo rispetto che ad altri, un elemento comune emerso riguarda l’impatto che la scelta del linguaggio ha sui costi di sviluppo e l’affidabilit` degli artefatti prodotti. Nonostante la grande flessia bilit` offerta dal linguaggio C, i costi affrontati per lo sviluppo, il testing e la a manutenzione degli artefatti prodotti erano superiori rispetto a quelli imposti da altri linguaggi come Ada [Zei95], Java [PVS08] o a linguaggi interpretati come Perl o Python [Pre00].

41

1.3. OBIETTIVI DI QUESTA TESI

1.3

Obiettivi di questa tesi

Negli ultimi anni Internet, e pi` specificamente il World Wide Web, sta evolu vendo da un medium per lo scambio di informazioni verso una piattaforma onnipresente per la distribuzione di qualsiasi genere di servizi come Web banking, E-Commerce, E-Government, etc. La ragione alla base di questa rapida evoluzione del Web ` il grande numero di possibilit` che questa forma di e a distribuzione offre, unito al grande successo che questo genere di soluzioni sta riscontrando verso l’utenza. L’orientamento verso il calcolo distribuito, lo stoccaggio di dati personali tramite servizi cloud-based, la conversione del consumo classico verso declinazioni digitali, sono tutti frammenti di questa evoluzione. In questo ambito, la possibilit` di integrazione delle tecnologie classiche a per la realizzazione di sistemi esperti con strumenti di nuova generazione orientati allo sviluppo per il web offre molti spunti per la ricerca nell’ambito degli expert system environment. L’approfondimento delle tematiche relative allo sviluppo di nuove soluzioni rappresenta uno spunto per capire in maniera pi` intima le dinamiche alla base del funzionamento dei sistemi esperti e degli u strumenti che ne consentono la creazione e la distribuzione. Lo scenario di riferimento descritto nell’arco di questo capitolo, unito alle problematiche emergenti dallo sviluppo orientato al Web, ` la base su cui si e vuole proporre un environment per sistemi esperti flessibile e che consenta un’integrazione rapida con tecnologie esistenti orientate al web. Gli obiettivi perseguiti nell’ambito di questa tesi sono riassumibili come segue:

42

1.3. OBIETTIVI DI QUESTA TESI • fornire un expert system environment dotato di una architettura flessibile in grado di permettere l’aggiunta di nuove caratteristiche; • estendere il sistema prodotto con funzionalit` che consentano la distria buzione dei servizi offerti dall’environment anche attraverso un modello d’architettura di tipo client-server, che agevoli la creazione di soluzioni basate su calcolo distribuito.

43

Bibliografia capitolo 1
[Wan+93] H. Wang, J. Mylopoulos, A. Kushniruk, B. Kramer e M. Stanley. “KNOWBEL: New Tools for Expert System Development”. In: N. G. Bourbakis. Knowledge Engineering Shells: Systems and Techniques. World Scientific, 1993. Cap. 7, pp. 189–258. [Tsa+93] J. J. P. Tsai, S. J. H. Yang, N. Waheed e T. Moher. “Development of Expert System Shell”. In: N. G. Bourbakis. Knowledge Engineering Shells: Systems and Techniques. World Scientific, 1993. Cap. 5, pp. 123–152. [Jac99] P. Jackson. Introduction to expert systems. International computer science series. Addison-Wesley, 1999. isbn: 9780201876864. url: http://books.google.it/books?id=9rJQAAAAMAAJ. [Ric56] R. H. Richens. “Preprogramming for Mechanical Translation”. In: Mechanical Translation 3.1 (lug. 1956). A cura di Massachussets Institute of Technology, pp. 20–25. url: http://www.mtarchive.info/MT-1956-Richens.pdf.

44

BIBLIOGRAFIA CAPITOLO 1 [Min74] M. Minsky. A Framework for Representing Knowledge. Rapp. tecn. Cambridge, MA, USA, 1974. url: http://hdl.handle. net/1721.1/6089. [HJW94b] C. W. Holsapple, V. S. Jacob e A. B. Whinston. Operations Research and Artificial Intelligence. Operations Research and Artificial Intelligence. Ablex Publishing Corporation, 1994. isbn: 9781567500363. url: http://books.google.it/books?id= OKn2v\_\_x-OwC. [HJW94a] C. W. Holsapple, V. S. Jacob e A. B. Whinston. “Object-Oriented Knowledge Representation”. In: Operations Research and Artificial Intelligence. 1994. Cap. 4, pp. 58–70. [Doo95] R. B. Doorenbos. “Production Matching for Large Learning Systems”. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Science Department, gen. 1995. 208 pp. [RN09] S. J. Russell e P. Norvig. Artificial Intelligence: a Modern Approach. A cura di Prentice Hall. 3a ed. 2 voll. Prentice Hall Series in Artificial Intelligence 1. 2009. 1132 pp. isbn: 0136042597, 9780136042594. [MF77] J. McDermott e C. L. Forgy. “Production system conflict resolution strategies”. In: SIGART Bull. 63 (1977), pp. 37–37. issn: 0163-5719. doi: 10 . 1145 / 1045343 . 1045364. url: http : //doi.acm.org/10.1145/1045343.1045364. [For82] C. L. Forgy. “Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”. In: Artificial Intelligence 45

BIBLIOGRAFIA CAPITOLO 1 19.1 (1982), pp. 17–37. issn: 0004-3702. doi: 10.1016/00043702(82)90020-0. [For79] C. L. Forgy. “On the Efficient Implementation of Production Systems”. AAI7919143. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Sience Department, 1979. [Van99] K. Van Laerhoven. Project report for Industrial Applications of AI. Research Notes. Lancaster University, 1999. url: http : / / www . comp . lancs . ac . uk / ~kristof / research / notes / clipsvsjess/index.html. [And93] J. R. Anderson. Rules of the Mind. A cura di Routledge. Taylor & Francis, 1993. 336 pp. isbn: 9780805812008. url: http:// books.google.it/books?id=xYvLraxYTZoC. [SC84] R. C. Schank e P. G. Childers. The Congitive Computer: on Language, Learning and Artificial Intelligence. New York: Pearson Addison-Wesley, 1984. 268 pp. isbn: 020106443X. [Sil88] W. Siler. FLOPS: A parallell-rule-firing fuzzy expert system shell. English. NASA Technical Documents. NASA. 1988. url: http: //archive.org/details/nasa_techdoc_19910073809. [Esp12] F. Esposito. Ingegneria delle Conoscenza e Sistemi Esperti. Materiale a supporto. Bari: Universit` degli Studi di Bari, 2012. a [BD83] B. G. Buchanan e R. O. Duda. “Principle of Rule-Based Expert Systems”. In: M.C. Yovits. Advances in Computers. Vol. 22. Advances in Computers. Academic Press, 1983. isbn: 9780120121229. url: http://books.google.it/books?id=UhFOZTCt4bcC. 46

BIBLIOGRAFIA CAPITOLO 1 [BCF81] A. Barr, P .R. Cohen e E. A. Feigenbaum. The Handbook of Artificial Intelligence. A cura di W. Kaufman. Vol. 1. AddisonWesley, 1981. 409 pp. isbn: 0-86576-005-5. [DK75] R. Davis e J. King. An Overview of Production Systems. technical report. Stanford University, ott. 1975. 38 pp. isrn: STANCS-75-524. url: http://www.dtic.mil/cgi-bin/GetTRDoc? AD=ADA019702. [Pos43] E. Post. “Formal Reductions of the General Combinatorial Decision Problem”. In: American Journal of Mathematics 65.2 (1943), pp. 197–215. [Ste+83] M. Stefik, D. G. Bobrow, S. Mittal e L. Conway. “Knowledge programming in LOOPS. Report on an Experimental Course”. In: The AI Magazine 4.3 (1983), pp. 3–13. url: http://www. aaai.org/ojs/index.php/aimagazine/article/view/400/ 336. [Aik+82] J. S. Aikins, J. C. Kunz, E. H. Shortliffe e R. J. Fallat. PUFF: An Expert Sstem for Interpretation of Pulmonary Function Data. technical repor HPP-82-I3. Stanford, CA 94305: Departments of Medicine e Computer Science, Stanfor University, set. 1982. 22 pp. isrn: STAN-CS-82-931. url: ftp://reports.stanford. edu/pub/cstr/reports/cs/tr/82/931/CS-TR-82-931.pdf. [BSM84] B. G. Buchanan, E. H. Shortliffe e W. van Melle. “EMYCIN: A Knowledge Engineer’s Tool for Constructing Rule-Based Expert Systems”. In: B. G. Buchanan e E. H. Shortliffe. Rule-based ex47

BIBLIOGRAFIA CAPITOLO 1 pert systems. The MYCIN experiments of the Stanford Heuristic Programming Project. Addison-Wesley, 1984. Cap. 15, pp. 303– 313. isbn: 0201101726. url: http://people.dbmi.columbia. edu/~ehs7001/Buchanan-Shortliffe-1984/Chapter-15.pdf. [BE79] J. S. Bennett e S. Engelmore R. “SACON: a knowledge-based consultant for structural analysis”. In: Proceedings of the 6th international joint conference on Artificial intelligence. Vol. 1. IJCAI’79. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1979, pp. 47–49. isbn: 0-934613-47-8. url: http : //dl.acm.org/citation.cfm?id=1624861.1624873. [Aik83] J. S. Aikins. “Prototypical knowledge for expert systems”. In: Artificial Intelligence 20.2 (1983), pp. 163–210. issn: 0004-3702. doi: 10.1016/0004-3702(83)90017-6. [Cha98] R. Chatterjee. “KBMS-based evolutionary prototyping of objectoriented software systems”. PhD thesis. University of Florida, 1998. 131 pp. [LA90] S. D. Lee e B. P. Allen. ART-Ada: An Ada-Based Expert System Tool. Research Report. NASA, 1990. 12 pp. isrn: NASA-CR188930. [Cli92] CLIPS. Architecture Manual. CLIPS Version 5.1. 1992. url: http://clipsrules.sourceforge.net/documentation/other/ arch5-1.pdf.

48

BIBLIOGRAFIA CAPITOLO 1 [Hal91] P. Haley. “Data-driven backward chaining”. In: Proceedings of the Second Annual CLIPS Conference. NASA Johnson Space Center. Houston TX, set. 1991. [HT99] P. V. Homeier e C. L. Thach. ECLIPS: An Extended CLIPS for Backward Chaining and Goal-Directed Reasoning. paper. The Aerospace Corporation. 199-. 11 pp. url: ftp://cobase.cs. ucla.edu/pub/homeier/papers/eclips.pdf. [Orc04] B Orchard. FuzzyCLIPS Version 6.10d. User’s Guide. National Research Council Canada. 2004. [Jess08b] The Jess FAQ. Sandia National Laboratories. 2008. url: http: //www.jessrules.com/jess/FAQ.shtml. [Jess08a] JESS 7.1 on-line Manual. 2008. url: http://www.jessrules. com/jess/docs/71/. [Nai99] D. Naiditch. “Selecting a programming language for your project”. In: Aerospace and Electronic Systems Magazine, IEEE 14 (9 set. 1999), pp. 11–14. issn: 0885-8985. doi: 10 . 1109 / 62 . 793447. [Zei95] S. F. Zeigler. Comparing Development Costs of C and Ada. Rapp. tecn. Rational Software Corporation, mar. 1995. [Pre00] L. Prechelt. “An Empirical Comparison of Seven Programming Languages”. In: Computer 33 (2000), pp. 23–29. issn: 0018-9162. doi: http : / / doi . ieeecomputersociety . org / 10 . 1109 / 2 . 876288.

49

BIBLIOGRAFIA CAPITOLO 1 [PVS08] K. Prashant, S. Vaibhav e N. Shashi. Programming Languages: A Comparative Study. Rapp. tecn. Mag. 2008. [TK73] A. Tversky e D. Kahneman. “Availability: A Heuristic for Judging Frequency and Probability”. In: Cognitive Psychology 5.5 (2 1973). A cura di Inc. Academic Press, pp. 207–232. issn: 0010-0285. doi: 10.1016/0010-0285(73)90033-9. [KST82] D. Kahneman, P. Slovic e A. Tversky. Judgment under Uncertainty: Heuristics and Biases. Cambridge University Press, 1982. isbn: 9780521284141. url: http://books.google.it/books? id=\_0H8gwj4a1MC.

50

Capitolo 2 Analisi
Lo scopo di questo capitolo ` quello di fornire un’analisi del sistema da proe porre. Verr` specificato il contesto nel quale l’artefatto dovr` operare, meta a tendo in evidenzia l’insieme dei requisiti che dovranno risultare soddisfatti.

2.1

Scopo del sistema

Il progetto MyCLIPS si prefigge lo scopo di sviluppare un software di tipo Expert System Environment, mediante la realizzazione di un ambiente multiparadigmatico che unisca al classico modello dichiarativo basato su regole, meccanismi di supporto alla programmazione procedurale. Affiancato al sistema principale, verr` inoltre progettato un modulo aga giuntivo che consenta la distribuzione dei servizi offerti dal software principale tramite un modello d’architettura client-server. L’artefatto derivante dal progetto, inteso come unione del software principale e del modulo server aggiuntivo, non sar` un prodotto con fini commera

51

` 2.2. CAPACITA ciali, ma piuttosto uno strumento con finalit` didattiche, di supporto alla a ricerca nell’ambito degli environment per sistemi esperti e all’integrazione degli stessi con tecnologie orientate al Web. Nel campo degli environment, il software CLIPS rappresenta un punto di riferimento sia nell’ambito dell’efficienza, che del numero di funzionalit` a offerte. La gratuit` e la facile reperibilit` del sistema ha garantito una larga a a adozione in ambito accademico. Il confronto fra il sistema proposto nell’ambito di questo progetto e il software CLIPS rappresenta una metrica per la valutazione del prototipo stesso. Un buon grado di compatibilit` fra i due a sistemi consentirebbe l’accesso ad un grande bacino di artefatti gi` prodotti a per il sistema CLIPS.

2.2

Capacit` a

Il tipo di software che il progetto MyCLIPS punta a realizzare ` un environe ment multi-paradigmatico per sistemi esperti. In quanto tale deve offrire strumenti per la realizzazione di sistemi esperti, associando all’uso delle regole di produzione come metodo di rappresentazione della conoscenza, la possibilit` a di specifica di strutture di controllo tramite un paradigma procedurale. Si riassumono schematicamente le funzionalit` principali richieste al sia stema, offrendo anche un riferimento al paragrafo nel quale la capacit` viene a approfondita e analizzata nel dettaglio: 1. l’uso di un linguaggio di specifica che consenta: (a) la definizione di regole di produzione (2.2.1.3)

52

` 2.2. CAPACITA (b) l’utilizzo di un paradigma procedurale (2.2.1.2) (c) la specifica di funzioni utente (2.2.1.2) (d) la specifica di moduli (2.2.1.1) (e) definizione di template di fatti (2.2.1.5) (f) la specifica della conoscenza fattuale tramite: i. fatti in notazione Ordered-Fact (2.2.1.4) ii. fatti in notazione Template-Fact (2.2.1.4) 2. la possibilit` di aggiungere strategie di risoluzione dei conflitti (2.2.3.2) a 3. la possibilit` di integrare nuove funzioni di sistema (2.2.3) a 4. compatibilit` con i sistemi sviluppati per CLIPS: a (a) compatibilit` del linguaggio di specifica (2.2.1) a (b) compatibilit` delle strategie di risoluzione dei conflitti (2.2.3.2) a (c) compatibilit` con un sub-set delle funzioni di sistema a 5. l’utilizzo dell’algoritmo RETE per le operazioni di Pattern-Matching (2.2.3.1) 6. la possibilit` di accedere alle funzionalit` del sistema tramite un tera a minale (2.2.4) 7. la distribuzione delle funzionalit` del software tramite un modulo sera ver (2.2.5)

53

` 2.2. CAPACITA

2.2.1

Linguaggio di specifica

La compatibilit` fra l’environment prodotto e il sistema CLIPS rappresenta a una delle capacit` desiderate. Per realizzarla ` necessario consentire l’utilizzo a e degli artefatti precedentemente prodotti utilizzando il linguaggio di specifica fornito da CLIPS. La restrizione delle capacit` richieste alla sola fornitura a delle meccaniche di definizione delle regole di produzione e delle strutture di controllo procedurali, consente di restringere l’insieme dei costrutti che ` e necessario definire escludendo i formalismi di specifica relativi al paradigma di sviluppo orientato agli oggetti concentrati nel sotto-sistema COOL di CLIPS. Il linguaggio utilizzato deve risultare compatibile sia a livello semantico che a livello sintattico con quello fornito da CLIPS, offrendo in questo modo il massimo livello di portabilit` degli artefatti. a

2.2.1.1

Moduli

Il formalismo previsto da CLIPS e che dovr` essere supportato dal software a prodotto, consente la definizione di moduli attraverso l’utilizzo del costrutto defmodule. Il modulo ` un’unit` di programma che racchiude e organizza e a la definizione di ulteriori costrutti. Lo scambio delle definizioni fra moduli differenti ` previsto attraverso un protocollo di import/export. e La sintassi prevede di associare un nome univoco ad ogni modulo, oltre alla possibilit` di specificare un elenco di costrutti da rendere disponibili a all’esterno del modulo stesso (tramite l’attributo export), oppure un elenco di definizioni da importare da un modulo precedentemente creato (tramite l’attributo import).

54

` 2.2. CAPACITA

<defmodule> ::= (defmodule <module-name> [comment] <port-spec>*) <port-spec> ::= (export <port-item>) | (import <module-name> <port-item>) <port-item> ::= ?ALL | ?NONE | <port-construct> ?ALL | <port-construct> ?NONE | <port-construct> <construct-name>+ <port-construct> ::= deftemplate | defglobal | deffunction Codice 2.1: Specifica BNF del costrutto defmodule 2.2.1.2 Funzioni utente

All’utente, in maniera alternativa all’integrazione di funzioni scritte in linguaggio nativo, deve essere offerta la possibilit` di aggiungere funzioni pera sonalizzate all’interno del sistema utilizzando il costrutto deffunction (Codice 2.2). La definizione di funzioni consente di specificare strutture di controllo procedurali che eseguano sequenze di operazioni guidate dai parametri di chiamata. Le funzioni cosi integrate potranno essere utilizzate nelle stesse modalit` a previste dalle altre funzioni di sistema, con l’eccezione relativa ai vincoli di visibilit` fra moduli. a Le definizioni di funzioni devono essere esportate dal modulo in cui sono definite e successivamente importate da quello che intende utilizzarle (Codice 2.3).

55

` 2.2. CAPACITA

<deffunction-construct> ::= (deffunction [<module-name>::]<name> [<comment>] (<regular-param>* [<wildcard-param>]) <action>* ) <regular-param> ::= <single-field-variable> <wildcard-param> ::= <multi-field-variable>

Codice 2.2: Specifica BNF del costrutto deffunction

(defmodule A (export deffunction Funzione_Di_Prova)) (deffunction A::Funzione_Di_Prova () ) (defmodule B (import A deffunction Funzione_Di_Prova)) Codice 2.3: Esempio di scambio di una definizione fra moduli

56

` 2.2. CAPACITA 2.2.1.3 Regole

La specifica di regole deve essere resa disponibile tramite l’utilizzo del costrutto defrule (Codice 2.4). <defrule-construct> ::= (defrule [<module-name>::]<rule-name> [<comment>] [<declaration>] <conditional-element>* => <action>* ) <declaration> ::= (declare <rule-property>+) <rule-property> ::= (salience <integer-expression>) | (auto-focus <boolean-symbol>) <boolean-symbol> ::= TRUE | FALSE <conditional-element> ::= <pattern-CE> | <assigned-pattern-CE> | <not-CE> | <and-CE> | <or-CE> | <test-CE> | <exists-CE> Codice 2.4: Specifica BNF del costrutto defrule La porzione LHS e RHS della regola sono separati dal simbolo =>. I pattern della LHS sono definiti con riferimento ai formalismi utilizzati per la specifica di Ordered-Fact e Template-Fact. Le variabili vengono specificate attraverso l’uso di wildcard, identificate dalla presenza del simbolo ”?” come primo carattere. I pattern possono essere ulteriormente specificati tramite 57

` 2.2. CAPACITA l’utilizzo di connettivi logici come not, or e and, oppure espressioni logiche come exists o test. La porzione RHS contiene chiamate a procedure di sistema o definite dall’utente tramite il costrutto deffunction.

2.2.1.4

Fatti

I fatti costituiscono il contenuto della working memory. Il linguaggio fornito deve prevedere, parallelamente a quanto previsto da CLIPS, la definizione dei fatti attraverso la notazione Ordered-Fact e Template-Fact. <deffacts-construct> ::= (deffacts [<module-name>::]<deffacts-name> [<comment>] <RHS-pattern>* ) <RHS-pattern> ::= <ordered-RHS-pattern> | <template-RHS-pattern> <ordered-RHS-pattern> ::= (<symbol> <RHS-field>+) <template-RHS-pattern> ::= (<deftemplate-name> <RHS-slot>*) <RHS-slot> ::= <single-field-RHS-slot> | <multifield-RHS-slot> <single-field-RHS-slot> ::= (<slot-name> <RHS-field>) <multifield-RHS-slot> ::= (<slot-name> <RHS-field>*) <RHS-field> ::= <variable> | <constant> | <function-call>

Codice 2.5: Specifica BNF del costrutto deffacts

58

` 2.2. CAPACITA La specifica dei fatti deve essere riunita all’interno di costrutti deffacts (Codice 2.5). Questo consente di inserire un elenco di definizioni che verranno automaticamente asserite durante la fase di inizializzazione del sistema esperto. Il primo formato di specifica dei fatti, chiamato Ordered-Fact, prevede la definizione degli stessi come vettori di elementi simbolici o numerici di lunghezza arbitraria. Il formato del primo elemento ` richiesto che sia di tipo e SYMBOL1 , il formato dei successivi elementi ` arbitrario. e La seconda modalit` di specifica, denominata Template-Fact, prevede la a definizione dei fatti tramite l’utilizzo di un template e una sequenza di slot. Gli slot rappresentano delle caratteristiche definite nella specifica del template. La definizione del fatto pu` prevedere l’avvaloramento di tutti o solo una o porzione degli slot previsti dal template. I valori inseribili negli slot possono essere singoli elementi o multipli. Nel secondo caso si far` riferimento allo a slot con il nome di multi-slot.

2.2.1.5

Template

La specifica dei fatti in formato Template-Fact prevede la definizione preventiva di un template che definisca una ”tipologia” di fatti, indicata con un nome univoco e una sequenza di caratteristiche: slot e multi-slot (Codice 2.6). La specifica prevede la definizione di valori di default, da attribuire nei casi in cui non venga fornito un valore durante l’asserzione, oppure di restrizioni sul tipo di valori utilizzabili nello slot.
SYMBOL rappresenta un tipo elementare presente in CLIPS. Appartengono a questo tipo tutte le sequenze alfanumeriche non delimitate da apici e che abbiano come primo elemento un carattere alfabetico
1

59

` 2.2. CAPACITA

<deftemplate-construct> ::= (deftemplate [<module-name>::]<deftemplate-name> [<comment>] <slot-definition>* ) <slot-definition> ::= <single-slot-def> | <multi-slot-def> <single-slot-def> ::= (slot <slot-name> <template-attribute>*) <multi-slot-def> ::= (multislot <slot-name> <template-attribute>*) <template-attribute> ::= <default-attribute> | <constraint-attribute> <default-attribute> ::= (default ?DERIVE | ?NONE | <expression>* ) <contraint-attr> ::= (type <type-spec>) <type-spec> ::= SYMBOL | STRING | LEXEME | INTEGER | FLOAT | NUMBER | FACT-ADDRESS Codice 2.6: Specifica BNF del costrutto deftemplate

60

` 2.2. CAPACITA

2.2.2

Parser

Le funzionalit` di analisi ed interpretazione dei costrutti specificati tramite a il linguaggio di definizione sono racchiuse all’interno del parser. Utilizzando una serie di regole sintattiche, questo componente ` in grado di leggere e le definizioni dei costrutti previsti dal linguaggio e convertirle in elementi computabili dal motore inferenziale. Ad ogni costrutto definito dal linguaggio vengono associate una serie di regole sintattiche che descrivono i vincoli di validit` e come convertire le a varie definizioni, una volta individuate. Le regole vengono specificate attraverso l’alternanza di sequenze simboliche predefinite e campi variabili, che rappresentano le propriet` dei singoli costrutti. a Le regole vengono organizzate in strutture nidificate. Il riconoscimento di determinate sequenze simboliche relative ad una regola principale, spesso delimitate da parole chiave, attiva la possibilit` di utilizzare sotto-regole a associate a quella principale. Il linguaggio di definizione prevede la possibilit` di definire elementi in a grado di alterare le regole sintattiche utilizzate dal parser, come template o funzioni. Questo comporta la necessit` di strutturare il processo di conversioa ne come un’alternanza di fasi di analisi ed interpretazione, eseguite su singoli costrutti individualmente.

2.2.3

Motore inferenziale

Il motore inferenziale controlla il processo di ragionamento alla base di un sistema esperto. Il ragionamento ` strutturato attraverso meccanismi di ine

61

` 2.2. CAPACITA ferenza, che in questo sistema vengono esplicitati nella forma di regole di produzione. L’utilizzo del motore inferenziale ` regolato da quattro fasi: e 1. l’inizializzazione, caricando conoscenza procedurale e fattuale. Il caricamento avviene attraverso la definizione di regole e gruppi di fatti iniziali. Le modalit` con le quali gli elementi vengono specificati possoa no essere legate all’utilizzo del linguaggio di definizione o alla specifica diretta dei costrutti in una forma direttamente utilizzabile dal motore inferenziale. Nel primo caso sar` necessaria una fase di conversione a delle definizioni, onere del parser. 2. la preparazione, nella quale il motore inferenziale organizza gli elementi ottenuti nella fase precedente all’interno di strutture specifiche che agevolino le elaborazioni successive. 3. l’esecuzione, nella quale viene eseguito il ciclo recognize-act. 4. la valutazione, una fase nella quale pu` essere analizzato lo stato finale o nel quale ha avuto termine l’elaborazione. La realizzazione del ciclo di controllo recognize-act prevede il confronto fra le condizioni espresse nelle porzioni LHS delle regole e l’insieme di fatti memorizzato all’interno della memoria di lavoro. La verifica dell’applicabilit` delle regole deve essere ripetuta come conseguenza di ogni modifia ca, anche minima, della memoria di lavoro. Per ridurre lo sforzo elaborativo richiesto dalle operazioni di confronto ` possibile utilizzare l’algoritmo e RETE [For79] [For82] [Doo95]. 62

` 2.2. CAPACITA 2.2.3.1 Algoritmo RETE

Figura 2.1: RETE come una black-box : immagine originale tratta da [Doo95]. L’algoritmo di pattern-matching RETE consente un confronto efficiente fra il rules-set e lo stato della working-memory. Le attivit` svolte dall’ala goritmo sono assimilabili a quelle di una black-box (Figura 2.1) alla quale vengono sottoposte due categorie di eventi: l’aggiunta o rimozione di regole e la modifica della working-memory, intesa come asserzioni e ritrattazioni di fatti. Il risultato ` in ogni caso un delta delle attivazioni, un insieme di e attivazioni da aggiungere o rimuovere dal conflict-set [Doo95]. Le attivit` legate alla modifica del rules-set vengono normalmente svolte a nelle fasi di preparazione del motore inferenziale, anche se questa assunzione non lede minimamente le possibilit` di modifica del network durante l’esea cuzione. Le attivit` di valutazione delle modifiche alla working-memory sono a svolte sia nelle fasi di preparazione, valutando l’insieme di fatti iniziali, che di esecuzione, valutando asserzioni e ritrattazioni eseguite durante il ciclo recognize-act.

63

` 2.2. CAPACITA Compilazione delle regole Il processo di compilazione di una regola prevede la conversione dei pattern presenti nella porzione LHS delle regole in un grafo di valutazione. Ad ogni singolo pattern deve essere fatto corrispondere un circuito che valuti le componenti statiche del pattern e che non richiedono un confronto con altri elementi della LHS. Questo genere di confronti si definisce intra-element. Le espressioni variabili vengono ignorate nell’esecuzione di questa classe di valutazioni. I singoli circuiti vengono riuniti attraverso strutture che consentano di verificare la coerenza dei valori associati alle parti variabili, qualora queste ultime siano presenti in pi` di un pattern. Questa classe di confronti viene u definita inter-element. Il tipo di strutture che ` possibile utilizzare durante il processo di cone versione delle regole determina il tipo di confronti e operazioni che verranno effettuati durante fase di valutazione delle modifiche. Il processo di conversione pu` essere realizzato tramite la creazione di espressioni statiche, eseguite o in sequenza per valutare le modifiche della working-memory [For79] [For82] realizzando in questo modo una rappresentazione implicita di un grafo di valutazione. Questa forma di implementazione prende il nome di formulazione compilata. Una variante alternativa [Doo95] prevede la generazione esplicita del grafo attraverso la realizzazione di strutture che rappresentino i nodi, prendendo il nome di formulazione interpretata. Il linguaggio di specifica (Codice 2.4) permette di esplicitare sia pattern che verifichino l’esistenza diretta di fatti nella working-memory (Template-Pattern-CE, Ordered-Pattern-CE e Assigned-Pattern-CE), che utilizzare connettivi logici per alterare il significato delle pattern. I connettivi vengono 64

` 2.2. CAPACITA esplicitati tramite Not-CE (negazione), And-CE (congiunzione), Or-CE (disgiunzione inclusiva). Queste condizioni possono essere valutate realizzando strutture apposite che eseguano i test tenendo conto del contesto offerto dal connettivo logico nel quale sono valutati. La formulazione proposta in [Doo95] copre questi casi. L’unica eccezione riguarda la disgiunzione inclusiva, la quale richiede invece una valutazione pi` approfondita per poter essere u supportata dall’algoritmo [Sch+86] [GP91].

Compilazione di disgiunzioni inclusive La struttura della LHS ` e implicitamente inclusa all’interno di un elemento condizionale and che verifichi la validit` contemporanea di tutti i pattern. La topologia dell’algoritmo a RETE base [For79] [For82] [Doo95] per` non consente la combinazione di o elementi condizionali and e or. Per risolvere questo problema, garantendo l’utilizzo degli elementi or-CE nella specifica della LHS, ` possibile generare e regole multiple per le quali sia garantita la conformit` alla topologia di REa TE da una singola regola contenente l’elemento or [Cli92]. L’operazione di compilazione deve essere preceduta da tre fasi: trasformazione, riduzione e scomposizione.
( and ( or <CE1 > <CE2 >) ( or <CE3 > <CE4 >) ) ( or ( or ( and ( and ( or ( and ( and

<CE1 > <CE3 >) <CE1 > <CE4 >) ) <CE2 > <CE3 >) <CE2 > <CE4 >) ) )

Figura 2.2: Applicazione delle propriet` dei connettivi logici per eseguire a una normalizzazione dei pattern. A sinistra la forma iniziale, a destra quella convertita

65

` 2.2. CAPACITA La fase di trasformazione consiste nello sfruttare le propriet` dei conneta tivi logici per eseguire una conversione dei pattern della LHS (Figura 2.2) fino ad ottenere una forma normalizzata che assicuri l’eventuale presenza di elementi or solo come elementi radice o contenuti in ulteriori or.
( or ( or ( and ( and ( or ( and ( and ( or ( and ( and ( and ( and <CE1 > <CE1 > <CE2 > <CE2 > <CE3 >) <CE4 >) <CE3 >) <CE4 >) )

<CE1 > <CE3 >) <CE1 > <CE4 >) ) <CE2 > <CE3 >) <CE2 > <CE4 >) ) )

Figura 2.3: Riduzione dei connettivi or adiacenti. A sinistra la forma iniziale, a destra quella ridotta La fase di riduzione consente di eliminare connettivi logici ridondanti, riducendo connettivi or e and adiacenti (Figura 2.3). Come ultima fase, quella della scomposizione, i singoli and-CE contenuti all’interno della clausola or vengono scomposti come fossero regole differenti. Ad ognuna di esse verr` associato la medesima porzione RHS. Le regole scoma poste verranno collegate alla regola principale e rimosse contemporaneamente come fossero una singola istanza. Valutazione delle modifiche Durante la fase di esecuzione del ciclo recognizeact ha invece luogo la seconda attivit` prevista dall’algoritmo RETE: la vaa lutazione delle modifiche della working-memory. L’aggiunta o la rimozione di elementi dalla memoria di lavoro viene valutata tramite l’attraversamento del grafo di valutazione generato nella fase di preparazione. Gli elementi WME verranno riuniti durante l’attraverso della regione beta di valutazione all’interno di strutture complesse, i Token. Le attivazioni parziali di pattern 66

` 2.2. CAPACITA singoli vengono memorizzati in memorie locali poste come terminali della regione alpha, realizzando una frontiera. Le attivazioni parziali di sequenze di pattern vengono riunite nei Token e stoccate in memorie locali poste come conseguente della struttura che ha eseguito Join fra i pattern. L’output offerto dalla valutazione, ottenuto dai nodi terminali, consiste nell’elenco di attivazioni da aggiungere o rimuovere dall’agenda delle attivazioni.

2.2.3.2

Risoluzione dei conflitti

La selezione dell’attivazione da eseguire viene effettuata utilizzando una serie di criteri. L’entit` che racchiude questi criteri e li organizza prende il a nome di strategia di risoluzione dei conflitti (CRS) [MF77]. La CRS organizza l’elenco di attivazioni disponibili per ogni stato del sistema in base ad un ordinamento specifico. L’aggiunta o la rimozione di un fatto pu` determinare o l’aggiornamento dell’intera sequenza. Per ogni iterazione del ciclo recognizeact possono essere aggiunte o rimosse un numero arbitrario di attivazioni determinate dalla modifica allo stato del sistema eseguita nella fase act. All’inizio di ogni ciclo, l’attivazione con priorit` maggiore (sempre determinata a in base ai criteri della CRS in uso) viene selezionata, rimossa dalla sequenza e quindi eseguita. Il software deve fornire diverse strategie di risoluzione di conflitti: Depth: ad attivazioni pi` recenti viene associata una priorit` maggiore. u a Breadth: le nuove attivazioni vengono inserite nella sequenza con priorit` a inferiore a quelle gi` esistenti. a

67

` 2.2. CAPACITA Simplicity: viene utilizzato come criterio per determinarne la priorit` un a indice di generalit` della regola [Cli92]. A quelle con un minor grado di a specializzazione verr` attribuita una priorit` maggiore. Il coefficiente a a di complessit` di ogni regola viene determinato prendendo in esame il a numero di pattern presenti nella LHS, il numero di variabili utilizzate in ogni pattern ed il numero di connettivi ed espressioni logiche presenti. Il coefficiente, espresso tramite un valore numerico intero, viene quindi computato sommando le singoli componenti. Complexity: la specificit` della regola a cui fa riferimento l’attivazione dea termina la priorit` di attivazione [Cli92]. Il coefficiente di complessit` a a viene calcolato in maniera analoga a quanto fatto per la CRS Simplicity, ma valori di complessit` maggiori determineranno una maggiore a priorit`. a Lex: la priorit` di attivazione viene calcolata come segue [For81]: a • ad ogni fatto viene attribuita un’etichetta temporale per determinare una relazione d’ordine. • i fatti relativi ad ogni attivazione vengono quindi riordinati in modo decrescente. • le attivazioni vengono confrontate prendendo in esame le sequenze ordinate di etichette temporali e assegnando priorit` maggiore alle a attivazioni con sequenze pi` recenti. u Mea: la priorit` di attivazione viene calcolata come segue [For81]: a

68

` 2.2. CAPACITA • ad ogni fatto componente l’attivazione viene attribuita un’etichetta temporale per determinare una relazione d’ordine fra i fatti nella working-memory. • per ogni attivazione viene identificata l’etichetta temporale pi` u recente • le etichette vengono confrontate assegnando priorit` maggiore ala l’attivazione con etichetta pi` recente. u Random: le attivazioni vengono ordinate in modo casuale. Un ulteriore criterio discriminante comune a tutte le CRS ` quello basato e sulla valutazione della salience. Ad ogni regola pu` essere associato un vao lore numerico intero per determinare esplicitamente una relazione d’ordine. Qualora questo valore non venga indicato durante la definizione, ne verr` a attribuito uno di default. La valutazione della salience ` il primo elemento e discriminante per il computo della priorit`. Per le attivazioni relative a regole a con la stessa salience viene utilizzata la strategia di risoluzione dei conflitti per effettuare l’ordinamento. In aggiunta alle CRS fornite con il software, deve essere fornita la possibilit` di integrare ulteriori strategie di risoluzione di conflitti. a

2.2.4

Terminale

Il terminale ` la forma di utilizzo del sistema pi` immediata prevista. Permete u te ad un utente di inizializzare il motore inferenziale ed eseguire elaborazioni, rendendo il software un’applicazione a s´. e

69

` 2.2. CAPACITA Alla base del funzionamento del terminale ci sono le funzionalit` offera te dal parser. L’utilizzo del linguaggio di definizione permette di caricare o definire i sistemi esperti o, pi` genericamente, impartire una sequenza di u comandi al software. Un comando non ` altro che una funzione di sistema oppure una funzione e utente definita attraverso il costrutto deffunction. La chiamata di una procedura viene eseguita fornendo un nome univoco che rimandi alla funzione, la quale pu` essere accompagnata da un insieme di parametri che ne specifichio no i dati di ingresso. Il numero ed il tipo dei parametri che ` possibile fornire e ` definito dalla firma della funzione. Questa ` una struttura che definisce la e e funzione stessa indicando un nome univoco, il numero ed il tipo di parametri ammissibili come dati d’ingresso e il tipo dell’output fornito dalla funzione.

2.2.5

Modulo Server

Il software deve essere accompagnato da un componente in grado di rendere fruibili le funzionalit` offerte attraverso un modello di architettura distribuita a client-server. Un sistema distribuito consiste di una collezione di componenti, suddivisi su diversi terminali (anche chiamati host) connessi fra loro attraverso un canale di comunicazione. Questi componenti interagiscono fra loro al fine di scambiare dati od accedere reciprocamente a servizi disponibili [MCE02]. La realizzazione di un sistema distribuito ` soggetta alla predisposizione di un e sistema di comunicazione fra i processi collocati nei vari host. Il modello di architettura Client-Server si basa sul partizionamento del-

70

` 2.2. CAPACITA
(a) HOST-1 HOST-2
Client-1

(b) HOST SERVER
Client-1

Client-2

HOST-3
Client-2

HOST-n
Client-n Client-n

Figura 2.4: Architettura Client-Server : in (a) ` mostrata una distribuzione e su host multipli, in (b) una distribuzione in processi multipli le attivit`, risorse e responsabilit` del sistema in due classi di componenti: a a Server e Client. I componenti possono essere posizionati su host fisicamente differenti, cos` come possono essere collocati in processi separati residenti ı sulla stessa macchina, in modo tale che non condividano direttamente risorse (Figura 2.4). Lo scambio di informazioni avviene attraverso un protocollo noto ad entrambi i componenti. Il modulo server deve garantire la fruizione dei servizi offerti dall’envi` ronment a client multipli contemporaneamente. E quindi necessario che i risultati intermedi di elaborazione, cos` le informazioni relative all’engine e ı all’artefatto caricato, siano disponibili ed utilizzabili solo dal client che ha eseguito il caricamento e le precedenti elaborazioni. Per supportare questo modello d’utilizzo, il server deve essere in grado di associare un contesto univoco ad ogni richiesta che preveda l’utilizzo di risorse allocate in richieste precedenti. L’inizializzazione del contesto deve essere richiesta dal client: il server 71

...

SERVER

2.3. VINCOLI DI SISTEMA provveder` all’allocazione delle risorse ed alla generazione di un identificativo a di sessione univoco che verr` quindi fornito al client e utilizzato dallo stesso a per associare richieste successive al contesto inizializzato. Il server utilizza la sessione per memorizzare risultati parziali fra richieste successive, parametri di configurazione della comunicazione con il client e, pi` genericamente, u qualsiasi genere di informazione che possa essere ritenuta utile nel proseguo dell’elaborazione. Ogni sessione deve essere associata ad un tempo massimo di inattivit` oltre il quale la stessa venga rimossa automaticamente per cona sentire il recupero delle risorse allocate. Il tempo di inattivit` associato alla a sessione deve essere calcolato tenendo presente l’ultima richiesta effettuata che abbia fornito l’identificativo come parametro di contesto. La rimozione della sessione pu` anche essere arbitrariamente richiesta dal client che l’ha o generata, nel momento in cui la stessa non sia ritenuta pi` necessaria. u

2.3
2.3.1

Vincoli di sistema
Vincoli di interfaccia

Si esplicitano i seguenti vincoli d’interfaccia. Vincolo-1: Hardware L’utente si interfaccia al sistema inserendo appositi comandi tramite tastiera. Inoltre acquisisce i risultati dell’elaborazione dei comandi attraverso il monitor. La tastiera viene inoltre utilizzata per l’inserimento di dati, qualora necessario.

72

2.3. VINCOLI DI SISTEMA Vincolo-2: Utente L’interazione con il sistema avviene attraverso un’interfaccia testuale composta da una linea di comando, nella quale l’utente esplicita i comandi e attende i risultati dell’elaborazione. Anche i risultati vengono presentati nella medesima interfaccia testuale. Vincolo-3: Software L’utilizzo del sistema attraverso l’integrazione in applicazioni di terze parti prevede l’utilizzo di applicazioni per la scrittura di software o ambienti di sviluppo integrati (IDE). Vincolo-4: Software Il sistema prevede la possibilit` di utilizzare applicazioni di text-editing a per la creazione dei sistemi esperti.

2.3.2

Vincoli operativi

Vincolo-5: Hardware Per l’utilizzo in modalit` Server : a • 1GB di memoria RAM; • Interfaccia di rete. Vincolo-6: Software ` E previsto l’utilizzo del sistema su piattaforma PC con sistemi operativi • Microsoft Windows XP, Vista, 7 • Ubuntu 12.04 73

2.3. VINCOLI DI SISTEMA

2.3.3

Vincoli prestazionali

Vincolo-7: le prestazioni complessive del sistema devono permettere il completamento dei test di una benchmark-suite in tempo ragionevole.

2.3.4

Vincoli di progetto

Vincolo-8: il sistema deve permettere l’esecuzione di artefatti realizzati tramite CLIPS (escludendo quelli che utilizzano le estensioni del linguaggio COOL), richiedendo soltanto modifiche di lieve entit`. a Vincolo-9: il sistema deve prevedere la possibilit` di integrare nuove funa zionalit` a

2.3.5

Stabilit` dei vincoli a
Tabella 2.1: Matrice di stabilit` dei vincoli a

# Vincolo-1

Stabile

Instabile

Motivazione Nuove tecnologie potrebbero far migrare il sistema verso nuove forme di interazione

Vincolo-2 Vincolo-3 Vincolo-4

74

2.4. ATTORI E CASI D’USO

# Vincolo-5

Stabile

Instabile

Motivazione Lo sviluppo tecnologico potrebbe portare a richieste hardware differenti come conseguenza di un ampliamento delle richieste software

Vincolo-6 Vincolo-7 Lo sviluppo del sistema potrebbe portare all’introduzione di vincoli prestazionali Vincolo-8 Lo sviluppo del sistema potrebbe portare all’ampliamento della compatibilit` o a modifiche del linguaggio che a riducano la portabilit` degli artefatti a Vincolo-9

2.4
2.4.1

Attori e Casi d’uso
Attori

In seguito ad un’analisi preliminare, sono state individuate sette classi di attori principali e relative relazioni di specializzazione (Figura 2.5). ES Consumer: rappresenta un attore generalizzato in grado di utilizzare i servizi principali offerti dall’environment per caricare, eseguire ed interagire con un artefatto precedentemente creato tramite i protocolli offerti dall’environment stesso. 75

2.4. ATTORI E CASI D’USO

Figura 2.5: Gerarchia degli attori ES Developer: servendosi del linguaggio di specifica fornito dall’environment realizza artefatti eseguibili. Tramite l’utilizzo di apposite interfacce ` e anche in grado di testare l’artefatto prodotto analizzando rappresentazioni grafiche delle strutture interpretate e registri d’attivit` dell’esea cuzione dell’artefatto. Utente Umano Standalone Application: utilizza i servizi offerti dall’environment all’interno di applicazioni stand-alone. Esegue artefatti e valuta i risultati dell’esecuzione analizzando eventi e lo stato finale del sistema.

76

2.4. ATTORI E CASI D’USO Remote Application: esegue attivit` analoghe a quelle di Standalone Apa plication, ma utilizzando i servizi tramite appositi protocolli di comunicazione. Per supportare questi protocolli l’attore pu` creare, configurare o o distruggere sessioni. Environment Developer: utilizzando la documentazione di sistema e le apposite API fornite, estende le funzionalit` dell’environment aggiuna gendo nuove funzioni di sistema, strategie di risoluzione dei conflitti o event-listener. Utilizzando un framework per l’esecuzione di test d’unit`, pu` verificare il funzionamento delle funzioni integrate. a o Server Administrator: configura e gestisce un’istanza server dell’environment.

2.4.2

Organizzazione dei Casi d’uso

I casi d’uso vengono organizzati in quattro gruppi (Figura 2.6). Il gruppo di appartenenza di ognuno, indicato dal prefisso inserito nel nome, viene associato tenendo conto dell’attore principale al quale l’use case fa riferimento. Il formato del nome di ogni caso d’uso seguir` quindi questa convenzione: a UC[Attore]-[Sezione].[Gruppo].[SottoGruppo]: [Descrizione breve] dove: Attore indica l’attore principale relazionato con il caso d’uso: E per Environment Developer, A per Server Administrator, S per Standalone Application, R per Remote Application, D per ES Developer e C per

77

2.4. ATTORI E CASI D’USO

Figura 2.6: Vista generale dei casi d’uso principali

78

2.4. ATTORI E CASI D’USO ES Consumer. Non ` presente nessuno codice per l’attore Utente umae no in quanto non esiste alcun caso d’uso relativo esclusivamente ad esso. Sezione indica una delle sezioni principali presenti nella vista generale fornita in Figura 2.6. Gruppo e SottoGruppo esplicitano un’organizzazione gerarchica dei casi d’uso.

79

2.4. ATTORI E CASI D’USO

Figura 2.7: Diagramma dei casi d’uso UCC-1 2.4.2.1 UCC-1: Utilizzo artefatto

• Attori: ES Consumer • Scopo e descrizione: un ES Consumer deve poter utilizzare un artefatto precedentemente creato, caricandolo e successivamente eseguendolo. • Pre-condizioni: il software ` correttamente configurato nel sistema e • Post-condizioni: il software ha eseguito tutte le operazioni desiderate • Flusso principale degli eventi:

80

2.4. ATTORI E CASI D’USO 1. l’ES Consumer richiede al software di effettuare il caricamento di un artefatto (si veda caso d’uso UCC-1.1 ). 2. l’ES Consumer richiede al software di eseguire un artefatto (si veda caso d’uso UCC-1.2 ).

UCC-1.1: Caricamento artefatto La descrizione comprende quelle dei casi d’uso UCC-1.1.1 e UCC-1.1.2 in quanto identici, a meno del formato con il quale l’artefatto viene fornito. • Attori: ES Consumer • Scopo e descrizione: un ES Consumer deve avere la possibilit` di a caricare nel sistema un artefatto formalizzato in codice sorgente nativo o codice sorgente CLIPS • Pre-condizioni: il software ` correttamente configurato nel sistema e • Post-condizioni: il software ha eseguito le operazioni di caricamento ed il suo stato rispecchia quello descritto nell’artefatto • Flusso principale degli eventi: 1. l’ES Consumer richiede al software di caricare un artefatto – l’ES Consumer pu` fornire un artefatto in formato nativo o – l’ES Consumer pu` fornire un artefatto in formatto CLIPS o 2. Il software analizza l’artefatto 3. Il software esegue il caricamento dei costrutti contenuti nell’artefatto 81

2.4. ATTORI E CASI D’USO • Flusso alternativo: 3. se l’ES Consumer ha fornito un artefatto in formato non valido, il software notifica l’errore fornendo la motivazione e la posizione del problema

UCC-1.2: Esecuzione artefatto • Attori: ES Consumer • Scopo e descrizione: l’ES Consumer deve poter eseguire un artefatto caricato nel sistema. Se l’interazione lo richiede, l’ES Consumer deve essere in grado di fornire informazioni aggiuntive, osservare l’accadimento di un evento e osservare l’output fornito dal sistema • Pre-condizioni: il software ha correttamente caricato un artefatto ed attende istruzioni. • Post-condizioni: il software ha correttamente eseguito le operazioni previste dall’artefatto. • Flusso principale degli eventi: 1. l’ES Consumer richiede l’esecuzione di un artefatto 2. il sistema esegue le operazioni previste dall’artefatto (si vedano i casi d’uso UCC-1.2.1, UCC-1.2.3 ) 3. il sistema fornisce all’ES Consumer i risultati dell’esecuzione • Flusso alternativo:

82

2.4. ATTORI E CASI D’USO 2. se un’operazione specificata nell’artefatto genera errori, il sistema notifica l’errore all’ES Consumer fornendo informazioni sulla natura del problema. 3. il sistema ritorna nello stato iniziale

UCC-1.2.1: Fornisce input • Attori: ES Consumer • Scopo e descrizione: l’ES Consumer fornisce informazioni aggiuntive • Pre-condizioni: il sistema richiede informazioni aggiuntive per completare l’esecuzione di un artefatto • Post-condizioni: il sistema prosegue l’esecuzione • Flusso principale degli eventi: 1. il sistema richiede informazioni aggiuntive 2. l’ES Consumer fornisce le informazioni nelle forme previste dall’artefatto 3. il sistema valuta le informazioni fornite 4. il sistema elabora le informazioni fornite • Flusso alternativo: 3. il sistema notifica l’invalidit` delle informazioni fornite a 4. lo scenario riprende dal punto 1 del flusso principale

83

2.4. ATTORI E CASI D’USO UCC-1.2.2: Visualizza output • Attori: ES Consumer • Scopo e descrizione: l’ES Consumer deve essere in grado di valutare l’output fornito dal sistema al termine di un’operazione • Pre-condizioni: il sistema ` pronto ad esegue un’operazione e • Post-condizioni: il sistema ` pronto ad eseguire una nuova operazione e • Flusso principale degli eventi: 1. il sistema esegue un’operazione 2. il sistema fornisce una visualizzazione del risultato 3. l’ES Consumer valuta il risultato

UCC-1.2.3: Osserva evento • Attori: ES Consumer • Scopo e descrizione: l’ES Consumer deve essere in grado di ricevere notifica del verificarsi di un evento • Pre-condizioni: il sistema ` pronto ad eseguire un’operazione e • Post-condizioni: il sistema ` pronto ad eseguire un’operazione e • Flusso principale degli eventi: 1. l’ES Consumer richiede al sistema di eseguire un’operazione 2. il sistema esegue un’operazione 84

2.4. ATTORI E CASI D’USO 3. il sistema notifica all’ES Consumer il verificarsi di un evento 4. l’ES Consumer valuta l’evento

85

2.4. ATTORI E CASI D’USO

Figura 2.8: Diagramma dei casi d’uso UCD-1 2.4.2.2 UCD-1: Creazione artefatto

• Attori: ES Developer • Scopo e descrizione: un ES Developer deve essere in grado di definire i costrutti necessari alla realizzazione di un artefatto. • Pre-condizioni: il software fornisce almeno un linguaggio di specifica • Post-condizioni: un artefatto ` stato serializzato tramite il linguaggio e di specifica • Flusso principale degli eventi:

86

2.4. ATTORI E CASI D’USO 1. l’ES Developer definisce una serie di costrutti (si vedano i casi d’uso UCD-1.1, UCD-1.2, UCD-1.3, UCD-1.4, UCD-1.5, UCD1.6 ). – l’ES Developer pu` formalizzarlo in formato nativo o – l’ES Developer pu` formalizzarlo in formatto CLIPS o 2. l’ES Developer verifica la correttezza dell’artefatto (si veda il caso d’uso UCC-1.1 ) UCD-1.1: Definizione regola • Attori: ES Developer • Scopo e descrizione: un ES Developer deve essere in grado di definire una regola tramite un linguaggio di specifica fornito dal sistema. • Pre-condizioni: il software fornisce almeno un linguaggio di specifica • Post-condizioni: la definizione di una regola ` stata aggiunta ad un e artefatto • Flusso principale degli eventi: 1. l’ES Developer definisce una regola – l’ES Developer pu` formalizzarli in formato nativo o – l’ES Developer pu` formalizzarli in formatto CLIPS o • Flusso alternativo: 1. se l’ES Developer ha definito precedentemente un modulo, l’ES Developer pu` definire una regola come componente del modulo. o 87

2.4. ATTORI E CASI D’USO

Figura 2.9: Diagramma dei casi d’uso UCD-1.2 UCD-1.2: Definizione template • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire un template di fatti tramite un linguaggio di specifica fornito dal sistema. • Pre-condizioni: il software fornisce almeno un linguaggio di specifica. • Post-condizioni: la definizione di un template di fatti ` stato aggiunta e ad un artefatto • Flusso principale degli eventi: 1. l’ES Developer definisce un template di fatti

88

2.4. ATTORI E CASI D’USO 2. l’ES Developer indica una serie di slot relativi al template di fatti (si vedano i casi d’uso UCD-1.2.1, UCD-1.2.2 ) • Flusso alternativo: 1. se l’ES Developer ha definito precedentemente un modulo, l’ES Developer pu` definire un template di fatti come componente di o un modulo UCD-1.2.1: Definizione slot • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire il formato di uno slot appartenente ad un template di fatti • Pre-condizioni: il software fornisce un linguaggio di specifica, l’ES developer ha definito un template di fatti • Post-condizioni: il formato dello slot ` stato aggiunto alla definizione e di template di fatti • Flusso principale degli eventi: 1. l’ES Developer definisce un template 2. l’ES Developer definisce un nuovo slot fornendo il nome (stringa alfanumerica) da attribuire allo stesso (a) l’ES Developer pu` definire una restrizione di tipo al conteo nuto dello slot (b) l’ES Developer pu` definire un valore di default per lo slot o 89

2.4. ATTORI E CASI D’USO • Flusso alternativo: 2. se l’ES Developer ha fornito un nome gi` usato da un altro slot o a multi-slot presente, il sistema rifiuta la definizione notificando un errore. UCD-1.2.2: Definizione multi-slot • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire il formato di un multi-slot appartenente ad un template di fatti • Pre-condizioni: il software fornisce un linguaggio di specifica, l’ES Developer ha definito un template di fatti • Post-condizioni: il formato del multi-slot ` stato aggiunto alla defie nizione di template di fatti • Flusso principale degli eventi: 1. l’ES Developer definisce un template 2. l’ES Developer definisce un nuovo multi-slot fornendo il nome (stringa alfanumerica) da attribuire allo stesso (a) l’ES Developer pu` definire delle restrizioni di tipo al conteo nuto dello slot (b) l’ES Developer pu` definire dei valori di default per il multio slot • Flusso alternativo: 90

2.4. ATTORI E CASI D’USO 2. se l’ES Developer ha fornito un nome gi` usato da un altro slot o a multi-slot presente, il sistema rifiuta la definizione notificando un errore.

Figura 2.10: Diagramma dei casi d’uso UCD-1.3

UCD-1.3: Definizione modulo • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire un modulo tramite un linguaggio di specifica fornito dal sistema. • Pre-condizioni: il software fornisce almeno un linguaggio di specifica. • Post-condizioni: la definizione di un modulo ` stata aggiunta ad un e artefatto. • Flusso principale degli eventi: 91

2.4. ATTORI E CASI D’USO 1. l’ES Developer definisce un modulo specificandone il nome 2. l’ES Developer definisce una serie di costrutti da esportare (si veda il caso d’uso UCD-1.3.1 ) 3. l’ES Developer definisce una serie di costrutti da importare da un altro modulo (si veda il caso d’uso UCD-1.3.2 ) • Flusso alternativo: 1. se l’ES Developer fornisce un nome gi` utilizzato da un altro a modulo, il sistema rifiuta la definizione e notifica l’errore. 2. il sistema ritorna nello stato iniziale.

UCD-1.3.1: Esporta costrutti • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di specificare l’esportazione di un costrutto relativo al modulo tramite un linguaggio di specifica fornito dal sistema • Pre-condizioni: il sistema fornisce un linguaggio di specifica, l’ES Developer ha definito un modulo • Post-condizioni: il sistema aggiunge il nome del costrutto esportato in un insieme di elementi importabili da altri moduli • Flusso principale degli eventi: 1. l’ES Developer definisce un modulo

92

2.4. ATTORI E CASI D’USO 2. l’ES Developer definisce un costrutto appartenente al modulo come esportabile – l’ES Developer pu` specificare il nome ed il tipo del costrutto o – l’ES Developer pu` specificare il tipo dei costrutti e un valore o speciale per definire l’esportazione di tutti i costrutti del tipo indicato – l’ES Developer pu` specificare un valore speciale per definire o l’esportazione di tutti i costrutti di ogni tipo – l’ES Developer pu` specificare il tipo ed un valore speciale o per definire l’esclusione dei costrutti del tipo specificato dalla lista degli elementi esportati UCD-1.3.2: Importa costrutti • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di specificare l’importazione di un costrutto esportato da un modulo tramite un linguaggio di specifica fornito dal sistema • Pre-condizioni: il sistema fornisce un linguaggio di specifica, l’ES Developer ha definito un modulo che esporta un costrutto, l’ES Developer ha definito un modulo • Post-condizioni: il sistema aggiunge la definizione importata all’insieme di definizione del modulo. • Flusso principale degli eventi: 93

2.4. ATTORI E CASI D’USO 1. l’ES Developer definisce un modulo 2. l’ES Developer definisce un costrutto appartenente ad un secondo modulo come importabile. – l’ES Developer pu` specificare il modulo, il nome ed il tipo o del costrutto da importare – l’ES Developer pu` specificare il modulo, il tipo ed un valore o speciale per definite l’importazione di tutti i costrutti del tipo indicato dal modulo indicato – l’ES Developer pu` specificare il modulo ed un valore speciao le per definire l’importazione di tutti i costrutti dal modulo indicato – l’ES Developer pu` specificare il modulo, il tipo ed un vao lore speciale per definire l’esclusione di tutti i costrutti del tipo indicato del modulo indicato dall’insieme di costrutti importati • Flusso alternativo #1: 2. se l’ES Developer esegue un’importazione da un modulo non esistente, il sistema rifiuta la definizione e notifica l’errore. 3. il sistema ritorna nello stato iniziale. • Flusso alternativo #2: 2. se l’ES Developer esegue un’importazione di un costrutto non ancora definito da un modulo che lo esporta preventivamente, il sistema rifiuta la definizione e notifica l’errore. 94

2.4. ATTORI E CASI D’USO

Figura 2.11: Diagramma dei casi d’uso UCD-1.4 3. il sistema ritorna nello stato iniziale.

UCD-1.4: Definizione fatti • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire un gruppo di fatti iniziali tramite un linguaggio di specifica fornito dal sistema • Pre-condizioni: il software fornisce almeno un linguaggio di specifica • Post-condizioni: la definizione del gruppo di fatti ` stata aggiunta ad e un artefatto • Flusso principale degli eventi: 95

2.4. ATTORI E CASI D’USO 1. l’ES Developer definisce un gruppo di fatti specificando il nome 2. l’ES Developer definisce una serie di fatti da associare al gruppo (si vedano i casi d’uso UCD-1.4.1 e UCD-1.4.2 ) • Flusso alternativo: 1. se l’ES Developer ha definito precedentemente un modulo, l’ES Developer pu` definire il gruppo di fatti come componente del o modulo. 2. lo scenario prosegue dal punto 2 del flusso principale UCD-1.4.1: Definizione ordered-fact • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire un fatto in notazione ordered-fact tramite un linguaggio di specifica fornito dal sistema • Pre-condizioni: il software fornisce almeno un linguaggio di specifica, l’ES Developer ha definito un gruppo di fatti iniziali • Post-condizioni: il fatto in notazione ordered-fact ` aggiunto al grupe po di fatti iniziali • Flusso principale degli eventi: 1. l’ES Developer definisce un gruppo di fatti iniziali 2. l’ES Developer definisce un fatto in notazione ordered-fact specificando l’elenco di componenti in sequenza 96

2.4. ATTORI E CASI D’USO – l’ES Developer pu` specificare una sequenza di componenti di o lunghezza arbitraria – l’ES Developer pu` specificare una sequenza di componenti di o tipo non omogeneo • Flusso alternativo: 2. l’ES Developer definisce un fatto in notazione ordered-fact con componenti identiche a quelle di un fatto specificato in precedenza 3. il sistema ignora la definizione UCD-1.4.2: Definizione template-fact • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire un fatto in notazione template-fact tramite un linguaggio di specifica fornito dal sistema • Pre-condizioni: il software fornisce almeno un linguaggio di specifica, l’ES Developer ha definito un gruppo di fatti iniziali • Post-condizioni: il fatto in notazione template-fact ` aggiunto al grupe po di fatti iniziali • Flusso principale degli eventi: 1. l’ES Developer definisce un gruppo di fatti iniziali 2. l’ES Developer definisce un fatto in notazione template-fact specificando il nome del template di riferimento 97

2.4. ATTORI E CASI D’USO 3. l’ES Developer definisce i valori degli slot (risp. multi-slot) – l’ES Developer pu` specificare una sequenza di componenti di o lunghezza arbitraria per i multi-slot – l’ES Developer pu` specificare un elemento per gli slot o 4. il sistema completa la definizione del fatto associando i valori di default agli slot (risp. multi-slot) non definiti. • Flusso alternativo #1: 2. l’ES Developer fornisce un nome di template non valido 3. il sistema rifiuta la definizione e notifica l’errore 4. il sistema torna allo stato iniziale • Flusso alternativo #2: 3. l’ES Developer assegna un valore ad uno slot (risp. multi-slot) non definito nella definizione del template. 4. il sistema rifiuta la definizione e notifica l’errore 5. il sistema torna allo stato iniziale

UCD-1.5: Definizione variabile globale • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire una variabile globale tramite un linguaggio di specifica. • Pre-condizioni: il software fornisce almeno un linguaggio di specifica 98

2.4. ATTORI E CASI D’USO • Post-condizioni: la definizione della variabile globale ` stata aggiunta e ad un artefatto • Flusso principale degli eventi: 1. l’ES Developer definisce una variabile globale, indicando nome e valore iniziale 2. il sistema valuta la definizione • Flusso alternativo #1: 2. se l’ES Developer ha indicato come nome per la variabile globale uno gi` utilizzato, il valore iniziale fornito viene sostituito a quello a della definizione precedente 3. lo scenario prosegue dal punto 2 del flusso principale • Flusso alternativo #2: 1. se l’ES Developer ha definito precedentemente un modulo, l’ES Developer pu` definire la variabile globale come componente del o modulo. 2. lo scenario prosegue dal punto 2 del flusso principale

UCD-1.6: Definizione funzione • Attori: ES Developer • Scopo e descrizione: l’ES Developer deve essere in grado di definire una funzione tramite un linguaggio di specifica

99

2.4. ATTORI E CASI D’USO • Pre-condizioni: il software fornisce almeno un linguaggio di specifica • Post-condizioni: la definizione della funzione ` stata aggiunta ad un e artefatto • Flusso principale degli eventi: 1. l’ES Developer definisce una funzione utente, indicando nome, parametri e corpo della funzione 2. il sistema valuta il nome della funzione • Flusso alternativo #1: 2. se il nome fornito dall’ES Developer ` gi` utilizzato da una dee a finizione di funzione (di sistema o utente), il sistema rifiuta la definizione e notifica l’errore 3. il sistema ritorna allo stato iniziale • Flusso alternativo #2: 1. se l’ES Developer ha definito precedentemente un modulo, l’ES Developer pu` definire la funzione utente come componente del o modulo 2. lo scenario procede dal punto 2 del flusso principale

100

2.4. ATTORI E CASI D’USO

Figura 2.12: Diagramma dei casi d’uso UCD-2 2.4.2.3 UCD-2: Testa artefatto

• Attori: ES Developer • Scopo e descrizione: un ES Developer deve essere in grado di testare l’artefatto prodotto valutando un registro del funzionamento dello stesso e le modalit` con le quali le definizioni appartenenti all’artefatto a vengono interpretate. • Pre-condizioni: l’ES Developer ha realizzato un artefatto, l’artefatto ` stato caricato nel sistema. Il sistema attende istruzioni e • Post-condizioni: il funzionamento dell’artefatto ` stato valutato e • Flusso principale degli eventi: 1. l’ES Developer richiede al sistema informazioni per valutare l’artefatto.

101

2.4. ATTORI E CASI D’USO

Figura 2.13: Diagramma dei casi d’uso UCD-2.1 – l’ES Developer pu` richiedere informazioni sull’attivit` del o a sistema (si veda caso d’uso UCD-2.1 ) – l’ES Developer pu` richiedere informazioni su come l’artefatto o viene interpretato (si veda caso d’uso UCD-2.2 ). 2. il sistema fornisce le informazioni richieste.

UCD-2.1: Attiva/Disattiva tracciamento La descrizione comprende quella dei casi d’uso UCD-2.1.1, UCD-2.1.2, UCD-2.1.3 in quanto identici, a meno del tipo di informazioni che vengono tracciate. • Attori: ES Developer • Scopo e descrizione: un ES Developer deve essere in grado di modificare le impostazioni riguardo al tracciamento di regole, attivazioni e modifiche alla working-memory.

102

2.4. ATTORI E CASI D’USO • Pre-condizioni: ES Developer ha caricato un artefatto nel sistema. Il sistema attende istruzioni • Post-condizioni: le impostazioni di tracciamento risultano modificate • Flusso principale degli eventi: 1. l’ES Developer modifica le impostazioni riguardanti il tracciamento – l’ES Developer pu` attivare (risp. disattivare) il tracciamento o delle regole eseguite – l’ES Developer pu` attivare (risp. disattivare) il tracciamento o delle attivazioni disponibili – l’ES Developer pu` attivare (risp. disattivare) il tracciamento o delle modifiche alla working-memory 2. il sistema modifica le impostazioni di tracciamento dell’elemento indicato • Flusso alternativo: 1. l’ES Developer richiede l’attivazione (risp. disattivazione) di un tracciamento gi` attivo (risp. non attivo). a 2. il sistema ignora la richiesta

UCD-2.2: Visualizzazione grafico regole • Attori: ES Developer

103

2.4. ATTORI E CASI D’USO • Scopo e descrizione: un ES Developer deve essere in grado di richiedere informazioni riguardanti le modalit` con le quali il sistema a interpreta una regola. • Pre-condizioni: ES Developer ha caricato un artefatto nel sistema. Il sistema attende istruzioni • Post-condizioni: Il sistema attende istruzioni • Flusso principale degli eventi: 1. l’ES Developer richiede informazioni riguardanti l’interpretazione di una regola – l’ES Developer pu` indicare una regola specificandone il nome o – l’ES Developer pu` indicare un insieme di regole specificano done i nomi 2. il sistema fornisce le informazioni richieste • Flusso alternativo #1: 1. l’ES Developer specifica un nome di regola non valido 2. il sistema ignora la richiesta, notificando l’errore • Flusso alternativo #2: 1. l’ES Developer inserisce un nome non valido specificando un insieme di regole 2. il sistema ignora la richiesta, notificando l’errore

104

2.4. ATTORI E CASI D’USO

Figura 2.14: Diagramma dei casi d’uso UCE-1 2.4.2.4 UCE-1: Modifica funzioni di sistema

Nel proseguo dei paragrafi relativi ai casi d’uso UCE, il nome dell’attore Environment Developer verr` abbreviato con la sigla ED. a • Attori: Environment Developer (ED) • Scopo e descrizione: l’ED deve essere in grado di modificare il set di funzioni di sistema incluse nel software • Pre-condizioni: il software fornisce meccanismi per estendere il set di funzioni di sistema 105

2.4. ATTORI E CASI D’USO • Post-condizioni: il set di funzioni di sistema risulta modificato • Flusso principale degli eventi: 1. l’ED esegue una modifica al set di funzioni di sistema. – l’ED pu` rimuovere la definizione di una funzione esistente (si o veda caso d’uso UCE-1.2 ) – l’ED pu` aggiungere una nuova definizione di funzione di o sistema (si veda caso d’uso UCE-1.1 ). 2. il sistema carica il set modificato di funzioni sistema.

UCE-1.1: Aggiunge funzione La descrizione comprende quella del caso d’uso UCE-1.1.1 • Attori: ED • Scopo e descrizione: un ED deve essere in grado di aggiungere una nuova funzione al set di funzioni di sistema. • Pre-condizioni: il sistema ` stato configurato correttamente. Il sistee ma non ` attivo e • Post-condizioni: il sistema ` attivo e una nuova funzione ` disponibile e e nel set di funzioni di sistema • Flusso principale degli eventi: 1. l’ED definisce il corpo di una nuova funzione di sistema (UCE1.1.1 )

106

2.4. ATTORI E CASI D’USO 2. l’ED definisce la firma di una nuova funzione di sistema – l’ED specifica un nome di funzione – l’ED specifica un numero di parametri accettati (minimi, massimi, esatti) – l’ED specifica il tipo dei parametri accettati – l’ED specifica il tipo dei risultati 3. l’ED avvia il software 4. l’ED richiede al software il caricamento della nuova funzione – l’ED indica il file contenente il corpo della funzione – l’ED indica la posizione della firma della funzione 5. la richiesta ` valutata dal sistema e 6. la nuova definizione viene resa disponibile • Flusso alternativo #1: 5. se l’ED ha specificato un nome di funzione gi` utilizzato, il sistema a ignora la nuova definizione, notificando l’errore • Flusso alternativo #2: 2. l’ED definisce la firma della nuova funzione indicando solo il nome e il tipo dei risultati della funzione 3. analogo al punto 3 del flusso principale 4. analogo al punto 4 del flusso principale 5. analogo al punto 5 del flusso principale 107

2.4. ATTORI E CASI D’USO 6. la firma viene integrata automaticamente dal sistema in modo che la funzione accetti un numero ed un tipo arbitrario di valori 7. lo scenario prosegue con il punto 6 del flusso principale

UCE-1.1.2: Modifica manifesto funzioni • Attori: ED • Scopo e descrizione: ED deve essere in grado di apportare una modifica permanente al set di funzioni di sistema modificando un registro contenente l’elenco di funzioni di sistema • Pre-condizioni: l’ED vuole rendere permanente l’aggiunta o la rimozione di una funzione di sistema. Il software non ` attivo. e • Post-condizioni: il software ` attivo, la modifica apportata al registro e viene evidenziata nel set di funzioni di sistema disponibili • Flusso principale degli eventi: 1. l’ED modifica il registro contenente l’elenco delle funzioni di sistema – l’ED pu` aggiungere una nuova funzione all’elenco specificano do il file contenente il corpo e la posizione della firma della funzione – l’ED pu` rimuovere una funzione eliminandone le informazioni o dall’elenco 2. l’ED salva le modifiche al registro 108

2.4. ATTORI E CASI D’USO 3. l’ED avvia il sistema 4. le modifiche vengono valutate dal sistema 5. il set di funzioni disponibili viene modificato 6. l’inizializzazione del software prosegue • Flusso alternativo: 5. se l’ED ha apportato modifiche non valide al registro delle funzioni di sistema, il software notifica l’errore 6. l’inizializzazione del software viene arrestata UCE-1.2: Rimuove funzione • Attori: ED • Scopo e descrizione: ED deve essere in grado di rimuovere una funzione di sistema da quelle disponibili. • Pre-condizioni: il software ` configurato correttamente, il software e non ` attivo. e • Post-condizioni: Il software ` attivo, la funzione di sistema non ` e e presente fra quelle disponibili • Flusso principale degli eventi: 1. l’ED modifica il manifesto delle funzioni di sistema rimuovendo le informazioni riguardanti la funzione (si guardi caso il d’uso UCE1.1.2 )

109

2.4. ATTORI E CASI D’USO

Figura 2.15: Diagramma dei casi d’uso UCE-2 2.4.2.5 UCE-2: Monitorizza evento

• Attori: ED • Scopo e descrizione: l’ED deve essere in grado di specificare un nuovo evento e definire un comportamento da associare al verificarsi dell’evento • Pre-condizioni: il software fornisce meccanismi per la definizione e la notifica di un evento • Post-condizioni: il comportamento specificato dall’ED viene eseguito al verificarsi dell’evento atteso • Flusso principale degli eventi: 1. l’ED specifica un nuovo evento 110

2.4. ATTORI E CASI D’USO 2. l’ED specifica un listener che realizzi un comportamento al verificarsi di un evento (si guardi il caso d’uso UCE-2.1 ) 3. l’ED avvia il sistema 4. l’ED avvia un’elaborazione 5. il verificarsi dell’evento provoca l’esecuzione del comportamento definito

UCE-2.1: Definisce listener • Attori: ED • Scopo e descrizione: un ED deve essere in grado di specificare un comportamento da eseguire al verificarsi di un evento • Pre-condizioni: il sistema ` stato configurato correttamente. Il sistee ma non ` attivo e • Post-condizioni: il sistema ` attivo e un comportamento ` associato e e all’accadere di un evento • Flusso principale degli eventi: 1. l’ED definisce un comportamento nella forma di un entit` listener a 2. l’ED registra il listener nel sistema

111

2.4. ATTORI E CASI D’USO

Figura 2.16: Diagramma dei casi d’uso UCE-3 2.4.2.6 UCE-3: Aggiunge CRS

• Attori: ED • Scopo e descrizione: l’ED deve essere in grado di definire ed aggiungere una nuova strategia di risoluzione dei conflitti (CRS) • Pre-condizioni: il software fornisce meccanismi per la definizione e l’aggiunta di CRS, il sistema non ` attivo e • Post-condizioni: il sistema ` attivo e la una nuova CRS ` disponibile e e • Flusso principale degli eventi: 1. l’ED definisce una nuova CRS attraverso i meccanismi previsti dal sistema (si guardi il caso d’uso UCE-3.1 ) 2. l’ED aggiunge la nuova CRS al sistema 112

2.4. ATTORI E CASI D’USO 3. l’ED avvia il sistema

UCE-3.1: Definisce CRS • Attori: ED • Scopo e descrizione: l’ED deve essere in grado di definire una nuova CRS • Pre-condizioni: il sistema ` stato configurato correttamente. Il sistee ma non ` attivo. Il sistema offre meccanismi per la definizione di una e nuova CRS. • Post-condizioni: una nuova CRS ` disponibile per l’integrazione al e sistema • Flusso principale degli eventi: 1. l’ED definisce una nuova CRS 2. l’ED realizza la CRS in una unit` di elaborazione separata e a raggiungibile al software

113

2.4. ATTORI E CASI D’USO

Figura 2.17: Diagramma dei casi d’uso UCE-4 2.4.2.7 UCE-4: Testa environment

La descrizione comprende quella del caso d’uso UCE-4.1. • Attori: ED • Scopo e descrizione: l’ED deve essere in grado di verificare il funzionamento dell’environment utilizzando dei test d’unit`. L’ED deve avere a la possibilit` di realizzare dei test d’unit` per le funzionalit` aggiunte a a a • Pre-condizioni: il software fornisce meccanismi per l’esecuzione di test d’unit` in grado di verificare il comportamento dei componenti di a sistema. Il software fornisce un framework per la definizione di nuovi test d’unit` per le funzionalit` introdotte a a • Post-condizioni: l’ED ottiene dal software un riepilogo sul funzionamento delle componenti • Flusso principale degli eventi:

114

2.4. ATTORI E CASI D’USO 1. l’ED avvia l’esecuzione dei test d’unit` (UCE-4.1 ) a 2. l’ED ottiene un riepilogo dei risultati dei test – il riepilogo indica eventuali test falliti – il riepilogo indica il motivo del fallimento dei test

UCE-4.1: Creazione unittest • Attori: ED • Scopo e descrizione: l’ED deve avere la possibilit` di definire ed a eseguire test d’unit` in grado di verificare il corretto funzionamento a delle caratteristiche aggiunte • Pre-condizioni: il sistema ` stato configurato correttamente. Il softe ware offre meccanismi per l’integrazione di nuovi test d’unit` a quelli a forniti con il sistema • Post-condizioni: un nuovo test d’unit` ` integrato con quelli forniti ae dal sistema • Flusso principale degli eventi: 1. l’ED realizza un nuovo test d’unit` a 2. l’ED registra il nuovo test d’unit` insieme a quelli forniti dal a software

115

2.4. ATTORI E CASI D’USO 2.4.2.8 UCA-1: Avvia Server

• Attori: Server Administrator • Scopo e descrizione: il Server Administrator deve essere in inizializzare un’istanza server del software • Pre-condizioni: il sistema ` correttamente configurato. Il software ` e e correttamente configurato • Post-condizioni: un’istanza server del software ` attiva e attende e connessioni • Flusso principale degli eventi: 1. il Server Administrator avvia un’istanza del software 2. la configurazione del software viene valutata (si guardi caso d’uso UCA-3 ) • Flusso alternativo #1: 2. se una specifica di configurazione non ` disponibile, il software e notifica l’errore 3. vengono utilizzati dei parametri di default • Flusso alternativo #2: 2. se la specifica di configurazione non ` valida, il software notifica e l’errore 3. l’esecuzione viene terminata

116

2.4. ATTORI E CASI D’USO 2.4.2.9 UCA-2: Arresta Server

• Attori: Server Administrator • Scopo e descrizione: il Server Administrator deve essere in grado di terminare l’esecuzione di un’istanza del software • Pre-condizioni: un’istanza del software ` attiva e • Post-condizioni: l’istanza del software non ` pi` attiva e u • Flusso principale degli eventi: 1. il Server Administrator richiede l’arresto del software 2. tutte le sessioni vengono chiuse 3. il software viene arrestato • Flusso alternativo: 2. se si verifica un errore durante la chiusura di una sessione (o un tempo limite per l’operazione viene superato), la sessione viene distrutta forzatamente 3. lo scenario prosegue dal punto 3 del flusso principale

117

2.4. ATTORI E CASI D’USO

Figura 2.18: Diagramma dei casi d’uso UCA-3 2.4.2.10 UCA-3: Configura Server

• Attori: Server Administrator • Scopo e descrizione: il Server Administrator deve avere la possibilit` di configurare le funzioni del software MyCLIPS utilizzabili dai a client, i servizi offerti dal server e i parametri di base del modulo server attraverso un file di configurazione • Pre-condizioni: il sistema offre un formato di specifica delle configurazioni e un meccanismo di caricamento delle stesse • Post-condizioni: il funzionamento del software rispecchia i parametri definiti del file di configurazione • Flusso principale degli eventi: 118

2.4. ATTORI E CASI D’USO 1. il Server Administrator apre il file di configurazione attraverso un programma di text-editing 2. il Server Administrator modifica i parametri di configurazione del server – il Server Administrator modifica le funzioni di MyCLIPS utilizzabili dai client (si guardi il caso d’uso UCA-3.3 ) – il Server Administrator modifica i servizi attivi offerti dal server (si guardi il caso d’uso UCA-3.2 ) – il Server Administrator modifica i parametri di base del server (si guardi il caso d’uso UCA-3.1 ) 3. il Server Administrator salva le modifiche

UCA-3.1: Configurazione parametri server • Attori: Server Administrator • Scopo e descrizione: il Server Administrator deve avere la possibilit` a di modificare i parametri di configurazione di base del server • Pre-condizioni: nessuna • Post-condizioni: i parametri di configurazione risultano modificati secondo le aspettative del Server Administrator • Flusso principale degli eventi: 1. il Server Administrator modifica i parametri di base del server. Pu` configurare: o 119

2.4. ATTORI E CASI D’USO – l’indirizzo di ascolto (bind-address) – la porta di ascolto (bind-port) – la creazione di un registro delle richieste (log-requests) – il livello di dettaglio del registro delle richieste (log-level ) UCA-3.2: Definizione servizi La descrizione comprende anche quella del caso d’uso UCA-3.2.1. • Attori: Server Administrator • Scopo e descrizione: il Server Administrator deve avere la possibilit` a di definire i servizi attivi offerti dal server e configurare i parametri di funzionamento dei servizi • Pre-condizioni: nessuna • Post-condizioni: i parametri di configurazione risultano modificati secondo le aspettative del Server Administrator • Flusso principale degli eventi: 1. il Server Administrator modifica i servizi attivi offerti dal server specificando: – l’interfaccia offerta dal servizio – un’implementazione del servizio 2. il Server Administrator specifica i parametri relativi ai servizi attivi (UCA-3.2.1): il formato, il tipo e i valori delle configurazioni sono definite dalla specifica implementazione del servizio

120

2.4. ATTORI E CASI D’USO

Figura 2.19: Diagramma dei casi d’uso UCS-1 2.4.2.11 UCS-1: Analisi dei risultati

• Attori: Standalone Application • Scopo e descrizione: la Standalone Application deve avere la possibilit` di accedere alle informazioni riguardanti lo stato finale di un’ea laborazione eseguita dal software e ricevere notifica del verificarsi di eventi durante l’elaborazione • Pre-condizioni: la Standalone Application ha eseguito con successo il caso d’uso UCC-1.2 • Post-condizioni: la Standalone Application ha ottenuto le informazioni necessarie • Flusso principale degli eventi: 1. la Standalone Application richiede informazioni sullo stato terminale di elaborazione del software

121

2.4. ATTORI E CASI D’USO – la Standalone Application richiede informazioni sullo stato della working-memory (si guardi il caso d’uso UCS-1.1 ) – la Standalone Application richiede informazioni sullo stato delle attivazioni ancora presenti (si guardi il caso d’uso UCS1.2 ) – la Standalone Application valuta il verificarsi di un evento (si guardi il caso d’uso UCS-1.3 ) 2. la Standalone Application ottiene le informazioni richieste

UCS-1.1: Analisi della Working-Memory • Attori: Standalone Application • Scopo e descrizione: la Standalone Application deve avere accesso alle informazioni presenti nella Working Memory • Pre-condizioni: la Standalone Application ha eseguito con successo il caso d’uso UCC-1.2 • Post-condizioni: la Standalone Application ottiene le informazioni sui fatti presenti nella Working Memory • Flusso principale degli eventi: 1. la Standalone Application richiede una vista dei dati presenti nella Working Memory – la Standalone Application pu` limitare la ricerca solo ai fatti o relativi ad un sottogruppo dei moduli specificati 122

2.4. ATTORI E CASI D’USO – la Standalone Application pu` richiedere tutti i fatti presenti o nella Working Memory 2. la Standalone Application ottiene l’elenco dei fatti richiesti

UCS-1.2: Analisi attivazioni • Attori: Standalone Application • Scopo e descrizione: la Standalone Application deve avere accesso alle informazioni presenti nell’agenda delle attivazioni • Pre-condizioni: la Standalone Application ha eseguito con successo il caso d’uso UCC-1.1 • Post-condizioni: la Standalone Application ottiene l’elenco di attivazioni disponibili nell’agenda delle attivazioni nelle modalit` che ha a indicato • Flusso principale degli eventi: 1. la Standalone Application richiede una vista sulle attivazioni presenti nell’agenda delle attivazioni. – la Standalone Application pu` limitare la ricerca solo alle o attivazioni relative ad un sottogruppo dei moduli specificati – la Standalone Application pu` richiedere l’intera lista delle o attivazioni presenti in agenda 2. la Standalone Application ottiene l’elenco delle attivazioni richieste 123

2.4. ATTORI E CASI D’USO UCS-1.3: Analisi eventi • Attori: Standalone Application • Scopo e descrizione: la Standalone Application deve ricevere notifica del verificarsi di un evento per il quale ha espresso interesse nelle modalit` previste dal software a • Pre-condizioni: la Standalone Application ha eseguito con successo il caso d’uso UCC-1.2.3 • Post-condizioni: la Standalone Application ha eseguito il comportamento associato ad un determinato evento • Flusso principale degli eventi: 1. la Standalone Application esprime interesse relativamente al verificarsi di un evento (si guardi caso d’uso UCC-1.2.3 ) 2. la Standalone Application osserva la notifica del verificarsi di un evento 3. la Standalone Application analizza i parametri relativi all’evento 4. la Standalone Application esegue il comportamento associato all’evento con i parametri forniti

124

2.4. ATTORI E CASI D’USO

Figura 2.20: Diagramma dei casi d’uso UCR-1, UCR-2, UCR-3 2.4.2.12 UCR-1: Inizializza sessione

Nel proseguo dei paragrafi relativi ai casi d’uso UCR, il nome dell’attore Remote Application verr` abbreviato con la sigla RA. a • Attori: Remote Application (RA) • Scopo e descrizione: la RA deve avere la possibilit` di inizializa zare una sessione persistente con il software server che memorizzi le informazioni che devono essere conservate fra richieste differenti • Pre-condizioni: la RA ha conoscenza dei parametri di connessione relativi ad una istanza del software server

125

2.4. ATTORI E CASI D’USO • Post-condizioni: la RA ottiene un codice univoco che identifica la sessione creata • Flusso principale degli eventi: 1. la RA esegue una connessione con il server (si guardi il caso d’uso UCR-1.1 ) 2. la RA richiede l’inizializzazione di una sessione – la RA pu` fornire al server i parametri di connessione di uno o stream (si guardi il caso d’uso UCR-1.2 ) – la RA pu` fornire al server i parametri di connessione di un o listener (si guardi il caso d’uso UCR-1.3 ) 3. la RA memorizza l’identificativo di sessione • Flusso alternativo: 2. se la RA non ottiene l’identificativo di sessione, lo scenario prosegue dal punto 1 del flusso principale

UCR-1.1: Crea connessione • Attori: RA • Scopo e descrizione: la RA deve avere la possibilit` di stabilire una a connessione con il server tramite protocollo XML-RPC • Pre-condizioni: la RA ha conoscenza dei parametri di connessione relativi ad una istanza del software server

126

2.4. ATTORI E CASI D’USO • Post-condizioni: la RA ha stabilito una connessione. Permette l’esecuzione dei casi d’uso UCR-1, UCR-1.2, UCR-1.3, UCR-3 • Flusso principale degli eventi: 1. la RA stabilisce una connessione seguendo le specifiche di un protocollo • Flusso alternativo: 1. se la connessione fallisce, la RA attiva un protocollo di gestione dell’errore (la definizione del protocollo ` materia della RA) e

UCR-1.2: Registra stream • Attori: RA • Scopo e descrizione: la RA deve essere in grado di registrare uno stream remoto utilizzabile dal software server • Pre-condizioni: la RA ha eseguito con successo il caso d’uso UCR-1.1 • Post-condizioni: il software server pu` utilizzare lo stream remoto o come sostituto di uno locale. Permette l’esecuzione dei casi d’uso UCC1.2.1 e UCC-1.2.2 anche per l’attore RA • Flusso principale degli eventi: 1. la RA fornisce al software server i parametri di connessione di uno stream remoto 2. la RA indica: 127

2.4. ATTORI E CASI D’USO (a) indirizzo e porta di connessione dello stream (b) nome dello stream remoto (c) nome dello stream per il software server (d) un codice di controllo 3. la RA riceve un segnale di conferma all’indirizzo indicato usando i parametri forniti 4. lo stream remoto ` indicato come sostituto di uno stream locale e • Flusso alternativo: 3. se la RA non ottiene un segnale di conferma dopo un tempo massimo stabilito, la RA attiva un protocollo di gestione dell’errore (la definizione del protocollo ` materia della RA) e 4. lo stream remoto viene ignorato UCR-1.3: Registra listener • Attori: RA • Scopo e descrizione: la RA deve essere in grado di registrare un listener remoto utilizzabile dal software server • Pre-condizioni: la RA ha eseguito con successo il caso d’uso UCR-1.1 • Post-condizioni: il software server pu` utilizzare il listener remoto o come sostituto di uno locale. Permette l’esecuzione del caso d’uso UCC1.2.3 anche per l’attore RA • Flusso principale degli eventi: 128

2.4. ATTORI E CASI D’USO 1. la RA fornisce al software server i parametri di connessione di un listener remoto 2. la RA indica: (a) indirizzo e porta di connessione del listener (b) nome del listener remoto (c) nome del listener per il software server (d) il nome degli eventi per i quali registrare il listener (e) un codice di controllo 3. la RA riceve un segnale di conferma all’indirizzo indicato usando i parametri forniti 4. il listener remoto ` indicato come sostituto di uno locale e • Flusso alternativo: 3. se la RA non ottiene un segnale di conferma dopo un tempo massimo stabilito, la RA attiva un protocollo di gestione dell’errore (la definizione del protocollo ` materia della RA) e 4. il listener remoto viene ignorato

129

2.4. ATTORI E CASI D’USO 2.4.2.13 UCR-2: Distrugge sessione

Il diagramma relativo al caso d’uso UCR-2, data la natura complessa dello stesso, ` accorpato a quello del caso d’uso UCR-1 fornito in Figura 2.20. e • Attori: RA • Scopo e descrizione: la RA deve avere la possibilit` di terminare e a distruggere una sessione precedentemente inizializzata • Pre-condizioni: la RA ha eseguito il caso d’uso UCR-1 • Post-condizioni: il codice univoco ottenuto dall’esecuzione del caso d’uso UCR-1 non ` pi` valido e u • Flusso principale degli eventi: 1. la RA notifica la volont` di terminare la sessione al software server a 2. la RA riceve notifica di avvenuta chiusura della sessione 3. la RA cancella dalla propria memoria il codice univoco di sessione • Flusso alternativo: 2. se la RA non riceve notifica di avvenuta chiusura della sessione dopo un tempo stabilito, notifica un avviso non invasivo 3. lo scenario prosegue dal punto 3 del flusso principale

130

2.4. ATTORI E CASI D’USO 2.4.2.14 UCR-3: Richiede servizio

Il diagramma relativo al caso d’uso UCR-3, data la natura complessa dello stesso, ` accorpato a quello del caso d’uso UCR-1 fornito in Figura 2.20. e • Attori: RA • Scopo e descrizione: la RA deve avere la possibilit` di richiedere un a servizio al software server • Pre-condizioni: la RA ha eseguito il caso d’uso UCR-1.1. La RA ha eseguito il caso d’uso UCR-1 se il servizio richiesto richiede l’inizializzazione di una sessione • Post-condizioni: la RA ha ottenuto il risultato dell’elaborazione effettuata da un servizio • Flusso principale degli eventi: 1. la RA richiede un servizio al software server – la RA indica il nome del servizio richiesto – la RA indica i parametri di esecuzione del servizio – la RA pu` indicare il codice univoco di una sessione preceo dentemente inizializzata, se necessario 2. la RA attende il completamento dell’elaborazione • Flusso alternativo #1: 1. se la RA richiede un servizio non disponibile, la RA riceve un messaggio d’errore 131

2.4. ATTORI E CASI D’USO 2. la RA attiva un protocollo di gestione dell’errore (la definizione del protocollo ` materia della RA) e • Flusso alternativo #2: 1. se la RA richiede un servizio disponibile, ma il codice di sessione ` scaduto e 2. la RA esegue il caso d’uso UCR-1 3. lo scenario prosegue dal punto 1 del flusso principale • Flusso alternativo #3: 2. se la RA non riceve risposta entro un tempo limite, la RA attiva un protocollo di gestione dell’errore (la definizione del protocollo ` materia della RA) e

132

Bibliografia capitolo 2
[Doo95] R. B. Doorenbos. “Production Matching for Large Learning Systems”. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Science Department, gen. 1995. 208 pp. [MF77] J. McDermott e C. L. Forgy. “Production system conflict resolution strategies”. In: SIGART Bull. 63 (1977), pp. 37–37. issn: 0163-5719. doi: 10 . 1145 / 1045343 . 1045364. url: http : //doi.acm.org/10.1145/1045343.1045364. [For82] C. L. Forgy. “Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”. In: Artificial Intelligence 19.1 (1982), pp. 17–37. issn: 0004-3702. doi: 10.1016/00043702(82)90020-0. [For79] C. L. Forgy. “On the Efficient Implementation of Production Systems”. AAI7919143. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Sience Department, 1979. [Cli92] CLIPS. Architecture Manual. CLIPS Version 5.1. 1992. url: http://clipsrules.sourceforge.net/documentation/other/ arch5-1.pdf.

133

BIBLIOGRAFIA CAPITOLO 2 [MCE02] C. Mascolo, L. Capra e W. Emmerich. “Mobile computing middleware”. In: Advanced lectures on networking. A cura di E. Gregori, G. Anastasi e S. Basagni. New York, NY, USA: SpringerVerlag New York, Inc., 2002, pp. 20–58. isbn: 3-540-00165-4. url: http://dl.acm.org/citation.cfm?id=770420.770423. [For81] C. L. Forgy. OPS5 user’s manual. Paper 2397. Computer Science Department. Carnegie Mellon University, 1981. 57 pp. url: http://repository.cmu.edu/compsci/2397/. [Sch+86] M. I. Schor, T. Daly, H. S. Lee e B. Tibbitts. “Advances in Rete Pattern Matching”. In: National Conference on Artificial Intelligence. 1986, pp. 225–232. [GP91] D. N. Gordin e A. J. Pasik. “Set-oriented constructs: from Rete rule bases to database systems”. In: Proceedings of the 1991 ACM SIGMOD international conference on Management of data. SIGMOD ’91. Denver, Colorado, United States: ACM, 1991, pp. 60–67. isbn: 0-89791-425-2. doi: 10.1145/115790.115797. url: http://doi.acm.org/10.1145/115790.115797.

134

Capitolo 3 Sviluppo
Lo scopo di questo capitolo ` quello di fornire una soluzione progettuale e al problema mostrato nel capitolo precedente. Verranno quindi trattate le problematiche affrontate durante la fase di trasformazione del progetto in un artefatto eseguibile ed infine offerta una valutazione complessiva del sistema prodotto, illustrando preventivamente le informazioni relative alle metriche di valutazione utilizzate e alla natura dei test condotti.

3.1

Progettazione

Il sistema ` composto da due componenti principali distinte. Una prima, il e core del sistema MyCLIPS, realizza i servizi previsti dall’environment in una serie di API. Una seconda, il modulo server, si pone come tramite fra i servizi offerti dalla prima componente e un gruppo di client, distribuendo le caratteristiche attraverso un modello d’architettura Client-Server (Figura 3.1). Il modulo server ` sia un elemento di sistema che un esempio d’istane

135

3.1. PROGETTAZIONE

Figura 3.1: Vista generale dell’architettura di sistema: i servizi offerti dal modulo principale vengono distribuiti ad una serie di applicazioni remote attraverso l’utilizzo del componente Server

Figura 3.2: Vista generale dell’architettura locale di sistema: i componenti del core vengono utilizzati da componenti esterne (shell, modulo server o applicazioni generiche) za di applicazione generica che utilizza i servizi offerti dal core. Un altro esempio ` quello del componente shell : un elemento distinto che utilizza le e interfacce del core per realizzare un terminale testuale con il quale utilizzare l’environment (Figura 3.2).

136

3.1. PROGETTAZIONE

3.1.1

Core

La componente principale ` quella rappresentata dal core di MyCLIPS: race chiude tutti i package necessari alla realizzazione dei servizi principali del sistema (Figura 3.3).

Figura 3.3: Package myclips: vista dei package che compongono il core

3.1.1.1

Modulo Parser

Il package Parser comprende l’insieme di classi e interfacce che realizzano la funzionalit` di analisi e conversione del linguaggio di specifica in istanze a utilizzabili dal motore inferenziale per il compimento delle proprie attivit`. a L’elemento principale del package ` la classe Parser (Figura 3.4), che e organizza le regole di conversione (rappresentate dall’interfaccia ParserRule) ed effettua le operazioni di conversione del testo in istanze. Le classi utilizzate per la rappresentazione dei costrutti convertiti sono organizzate all’interno del sub-package myclips.parser.types.

137

3.1. PROGETTAZIONE

Figura 3.4: Package myclips.parser : vista delle classi relative al Parser Il sub-package contiene l’insieme di classi relative alla rappresentazione dei tipi atomici di base e dei costrutti compositi.

Figura 3.5: Package myclips.parser.types: vista di classi e interfacce per gli elementi atomici La gerarchia di tipi atomici supportata dal sistema segue le specifiche relative ai tipi proposti da CLIPS. Fanno parte di questa classificazione Lexeme, specializzato da Symbol e String, e Number, specializzato da In138

3.1. PROGETTAZIONE teger e Float. A questi tipi si uniscono quelli per la rappresentazioni delle variabili (Figura 3.5).

Figura 3.6: Package myclips.parser.types: vista di classi e interfacce per i costrutti principali La composizione dei tipi di base realizza un insieme di costrutti complessi principali. Le classi mostrate in Figura 3.6 sono le rappresentazioni corrispondenti ai formalismi defrule, defglobals, deffunction, deftemplate e defmodule, utilizzate dal linguaggio di specifica per la formalizzazione dei sistemi esperti. A titolo d’esempio si propone la struttura della classe DefRuleConstruct (Figura 3.7) insieme ad i relativi sotto-costrutti utilizzati per la conversione e rappresentazione di pozioni di quest’ultima.

139

3.1. PROGETTAZIONE

Figura 3.7: Package myclips.parser.types: vista delle classi e interfacce relative al costrutto defrule 3.1.1.2 Modulo Motore Inferenziale

Il ruolo del modulo Motore Inferenziale (IE) ` quello di offrire i servizi princie pali relativi alla gestione delle definizioni, all’esecuzione del ciclo recognize-act e alla gestione delle transizioni fra gli stati del sistema. A livello logico, le classi che lo realizzano possono essere raggruppate in due sezioni: una prima adibita alla gestione delle definizioni del sistema esperto (Figura 3.8a), una seconda alla interpretazione e esecuzione dei costrutti (Figura 3.8b). Gestione delle definizioni La gestione dei moduli ` affidata alla collaboe razione fra le classi Scope e ModulesManager (Figura 3.9). La classe ModulesManager memorizza l’insieme dei moduli definiti in un sistema esperto e un attributo di stato (currentScope) nel quale viene memorizzato il riferimen140

3.1. PROGETTAZIONE

Figura 3.8: Package myclips: vista degli elementi che collaborano per la realizzazione dei servizi dell’IE to allo Scope rappresentante il contesto corrente di esecuzione del sistema. Le definizioni o le azioni alle quali non ` stato attribuito esplicitamente un e modulo di appartenenza vengono automaticamente relazionate con il modulo corrente. Le istanze di classe Scope rappresentano singoli moduli definiti nel sistema. A differenza dell’entit` modulo intesa come collezione di costrutti e a definizioni definiti nel modulo stesso, quella di Scope raggruppa l’insieme di definizioni disponibili in un preciso contesto d’uso relazionato ad un modulo. Ogni Scope possiede i riferimenti ai manager dei tipi di costrutti definibili e gestisce il protocollo di import/export delle definizioni (Figura 3.10). Lo scambio di definizioni non ancora esplicitate avviene attraverso l’utilizzo delle promesse di import/export. Nel momento in cui un modulo mo-

141

3.1. PROGETTAZIONE

Figura 3.9: Package myclips: vista delle classi per la gestione dei moduli dA definisce tutti i propri costrutti esportabili ed un secondo modulo modB esplicita la volont` di importare tutti i costrutti di modA, si fa uso di una a promessa: il protocollo prevede l’utilizzo di una soluzione basata sul pattern observer-observable per eseguire il trasferimento delle definizioni aggiunte in fasi successive (Figura 3.11). La memorizzazione delle definizioni ` affidata alle classi GlobalsManager, e TemplatesManager e FunctionsManager (Figura 3.12). Ogni manager memorizza un preciso tipo di definizioni che possono essere utilizzate nell’ambito di uno Scope specifico. L’eventuale presenza di promesse di export viene valutata durante l’aggiunta di nuove definizioni nei manager (Figura 3.11).

Gestione dell’inferenza La classe principale per la gestione dell’inferenza ` la classe fa¸ade Network (Figura 3.13): astraendo dalla complessit` delle e c a interfacce offerte dal matcher, offre metodi per la manipolazione del rules-set, dei fatti iniziali e della working-memory. Realizzando il ciclo recognize-act al 142

3.1. PROGETTAZIONE

Figura 3.10: Diagramma di sequenza import/export delle definizioni: le clausule di importazione o esportazione determinano lo scambio di definizioni fra moduli

143

3.1. PROGETTAZIONE

Figura 3.11: Diagramma di sequenza import/export tramite l’uso di promesse: i moduli vengono relazionati e l’aggiunta successiva di definizioni al primo modulo viene automaticamente inoltrata al secondo modulo

144

3.1. PROGETTAZIONE

Figura 3.12: Vista delle classi manager di definizioni suo interno, permette l’utilizzo dei meccanismi di inferenza offerti dal sistema. La classe si affida a due componenti utility per la reale implementazione delle funzionalit` di compilazione e analisi delle regole interfacciandosi con il a modulo matcher, descritto in seguito. La gestione delle attivazioni viene affidata alla classe Agenda e al package myclips.strategies (Figura 3.14). La classe organizza le attivazioni, offrendo servizi per l’aggiunta o la rimozione delle stesse, e gestendo le strategie di risoluzione dei conflitti. La collaborazione fra Agenda e Strategy viene realizzata attraverso l’utilizzo del pattern Factory: la creazione dell’istanza di strategia viene delegata ad una istanza Singleton della classe StrategiesFactory, la quale inizializza un’implementazione dell’interfaccia Strategy fornita basandosi su un id di strategia. L’implementazione dell’Agenda viene realizzata tenendo conto dei metodi forniti dall’interfaccia, astraendo dall’implementa-

145

3.1. PROGETTAZIONE

Figura 3.13: Package myclips: vista della classe Network

146

3.1. PROGETTAZIONE

Figura 3.14: Package myclips: vista delle classi e interfacce relative ad Agenda e Strategie (CRS)

147

3.1. PROGETTAZIONE

Figura 3.15: Package myclips.rete: vista delle classi utility per la conversione delle regole in strutture di RETE zione concreta. Le strutture dati adibite alla memorizzazione delle sequenze di attivazioni vengono inizializzate e concretamente gestite dalla specifica implementazione della Strategy.

3.1.1.3

Modulo Matcher

Lo scopo del modulo matcher ` quello di confrontare lo stato della workinge memory con il rule-set, identificando l’insieme di attivazioni disponibili e inserendole nell’agenda delle attivazioni.

148

3.1. PROGETTAZIONE Il modulo si basa sull’utilizzo di un’implementazione interpretata dell’algoritmo RETE. Attraverso l’uso di due classi utility (Figura 3.15), per l’analisi dei pattern delle regole e per la costruzione del grafo, il rules-set viene convertito nel grafo esplicito di valutazione caratteristico dell’algoritmo RETE. La classe Analyzer viene utilizzata per manipolare la forma dei pattern delle regole nel rules-set, adattandole alla topologia del grafo di RETE, e individuare l’insieme dei test alpha e beta per i pattern, inizializzando le relative istanze delle classi di test organizzate nel package myclips.rete.tests. La classe Builder ha invece il compito di creare l’insieme di nodi necessari alla costituzione del grafo, associandoli dove necessario ai test ottenuti dall’Analyzer. L’utilizzo dei metodi factory per i nodi, come alternativa a normali costruttori, permette di utilizzare istanze condivise dei nodi quando possibile.

Compilazione delle regole L’algoritmo utilizzato per la compilazione delle regole segue quanto proposto in [Doo95], con alcune modifiche per permette l’utilizzo di pattern non previsti in origine come or-CE, exists-CE e test-CE. La procedura principale di compilazione ha inizio all’interno del metodo Network::addRule: utilizzando Analyzer, l’insieme dei pattern della regola vengono trasformati in modo che l’insieme di condizioni sia presentato in una forma normalizzata dove il primo pattern sia un elemento or-CE con al suo interno almeno un elemento and-CE che racchiuda le condizioni originali. Durante la normalizzazione, l’eventuale presenza di condizioni or

149

3.1. PROGETTAZIONE poste all’interno dei pattern viene trasferita nella radice della nuova LHS normalizzata. Ogni gruppo di condizioni and-CE genera un nuovo circuito indipendente. La compilazione del circuito ha luogo all’interno del metodo Builder::makeNetwork (Algoritmo 3.1): viene verificato il tipo di ogni pattern e quindi avviata la procedura di compilazione pi` indicata per lo stesso. u Ad ogni tipo di pattern corrisponde una procedura apposita. Nel caso pi` u comune, un normale Pattern-CE, questo viene prima analizzato per l’identificazione dei test alpha e beta: i primi vengono utilizzati per la generazione di un circuito che filtri gli elementi della working-memory in base ai criteri del pattern (Algoritmo 3.2), mentre quelli beta per la creazione di un nodo Join che riunisca il circuito alpha appena creato con le porzioni beta della regola create in precedenza (Algoritmo 3.3). La procedura di generazione dei nodi (Algoritmo 3.4) controlla prima la possibilit` di condividere un nodo gi` esistente che verifichi condizioni a a analoghe a quelle desiderate, quindi provvede alla creazione di una nuova istanza nel caso la condivisione non sia possibile. La possibilit` di condividere a un nodo precedentemente creato dipende sia dall’esistenza di un nodo di tipo analogo a quello desiderato, sia dall’effettiva corrispondenza fra i test eseguiti dal nodo esistente con quelli che si desidera eseguiti dal nuovo nodo.

Nodi del grafo di RETE Il set di nodi che supportano l’implementazione dell’algoritmo RETE sono realizzazioni di un set di interfacce fondamentali (Figura 3.16) che hanno il compito di formalizzare i metodi usati dai nodi per lo scambio di segnali e rendere possibile l’attraversamento da parte dei

150

3.1. PROGETTAZIONE

Algorithm 3.1 Compilazione di una regola function Builder.makeNetwork(parent: node, conds: list of conditions, prevConds: integer) siano c1 , . . . , ck le componenti di conds for i = 1 → k do if ci is-a Pattern-CE then testsα ← Analysis.analyzePattern(ci , α) memoryα ← Builder.makeAlphaCircuit(testsα ) testsβ ← Analysis.analyzePattern(ci , β) parent ← Builder.makeJoinCircuit(parent, memoryα , testsβ ) else if ci is-a Not-CE then testsα ← Analysis.analyzePattern(ci , α) memoryα ← Builder.makeAlphaCircuit(testsα ) testsβ ← Analysis.analyzePattern(ci , β) parent ← Builder.makeNegativeJoinCircuit(parent, memoryα , testsβ ) else if ci is-a Ncc-CE then siano ncci le componenti negate da ci sia l il numero di componenti in ncci lastN ccN ode ← Builder.makeNetwork(parent, ncci , prevConds) node ← Builder.makeNccCircuit(parent, lastN ccN ode, l) else if ci is-a Test-CE then testsθ ← Analysis.analyzePattern(ci , θ) parent ← Builder.makeTestCircuit(parent, testsθ ) else if ci is-a Exists-CE then testsα ← Analysis.analyzePattern(ci , α) memoryα ← Builder.makeAlphaCircuit(testsα ) testsβ ← Analysis.analyzePattern(ci , β) parent ← Builder.makeExistsCircuit(parent, memoryα , testsβ ) end if prevConds ← prevConds + 1 end for return node end function

151

3.1. PROGETTAZIONE

Algorithm 3.2 Creazione di un circuito α function Builder.makeAlphaCircuit(testsα : list of test) siano t1 , . . . , tk le componenti di testsα sia root il nodo radice del grafo di RETE lastN ode ← root for i = 1 → k do lastN ode ← Builder.factory PropertyTestNode(lastN ode, ti ) end for lastN ode ← Builder.factory AlphaMemory(lastN ode) return lastN ode end function

Algorithm 3.3 Creazione di un circuito β per il Join function Builder.makeBetaJoinCircuit(parent: node, memoryα : node, testsβ : list of test) parent ← Builder.factory BetaMemory(parent) parent ← Builder.factory JoinNode(parent, memoryα , testsβ ) return lastN ode end function

Algorithm 3.4 Esempio di metodo factory per i nodi function Builder.factory(nodeType: un tipo di nodo, parent: node, params: list of parametri di creazione del nodo) siano child1 , . . . , childk i nodi successori di parent for i = 1 → k do siano paramschildi i parametri di creazioni usati per il nodo childi if childi is-a nodeT ype ∧ params = paramschildi then return childi end if end for sia newN ode un nuovo nodo di tipo nodeT ype creato con i parametri params aggiungi newN ode fra i successori di parent imposta parent come padre di newN ode return newN ode end function

152

3.1. PROGETTAZIONE

Figura 3.16: Package myclips.rete: vista delle interfacce di base usate dai nodi per l’implementazione di RETE Token. La classe astratta Node, specializzata da tutti i nodi, rappresenta la struttura di base comune a tutti i tipi: memorizza i riferimenti ai nodi padre (destro per tutti i nodi, sinistro solo per quelli a due input) e i riferimenti ai nodi successori. Le memorie, alpha e beta, ed i nodi che memorizzano attivazioni parziali estendono inoltre la classe Memory. Le ulteriori interfacce presenti in Figura 3.16 formalizzano i metodi relativi all’esecuzione dei test e alla propagazione delle attivazioni parziali. Una classificazione approssimativa dei nodi pu` essere realizzata suddivio dendoli in base alla porzione della RETE che realizzano: alpha (Figura 3.17) o beta (Figura 3.18 e 3.19). Ogni tipo di nodo svolge una specifica funzione, spesso anche in relazione alla tipologia di test che pu` inglobare: o 153

3.1. PROGETTAZIONE

Figura 3.17: Package myclips.rete.nodes: vista dei nodi della pozione alpha

Figura 3.18: Package myclips.rete.nodes: vista dei nodi della pozione beta

154

3.1. PROGETTAZIONE

Figura 3.19: Package myclips.rete.nodes: vista dei nodi della pozione beta (nodi Ncc) RootNode: la radice del grafo radicato orientato che realizza RETE. PropertyTestNode: associabile a test di tipo alpha, pu` effettuare controlli o su elementi costanti di un pattern. AlphaMemory: unit` locale di memoria posta a termine di ogni circuito a alpha. Conserva gli elementi WME che hanno attraversato con successo il circuito a cui il nodo ` collegato. e JoinNode: nodo a due input, viene utilizzato per riunire istanze WME provenienti dai due rami del grafo in Token da propagare se i test collegati al nodo risultano verificati. Questo tipo di nodi viene utilizzato per realizzare i test di coerenza sul valore delle variabili presenti in pattern multipli.

155

3.1. PROGETTAZIONE NegativeJoinNode: specializzazione del nodo JoinNode, propaga un Token solo se tutti i test di coerenza associati al nodo non risultano soddisfatti. TestNode: nodo con input singolo, esegue dei test su un Token (spesso associati all’esecuzioni di funzioni dinamiche) e lo propaga nei casi di esito positivo. ExistsNode: nodo a due input utilizzato per fornire supporto al quantificatore esistenziale (∃) all’interno delle porzioni LHS delle regole. Un’attivazione proveniente dal ramo sinistro (quindi beta) del grafo viene propagato soltanto se esiste almeno un elemento all’interno dell’unit` a di memoria collegata come input destro (quindi alpha). NccNode e NccPartnerNode: i nodi Ncc (Figura 3.19) vengono utilizzati per realizzare negazioni di gruppi di condizioni. Le attivazioni provenienti dal ramo sinistro vengono propagate soltanto quando non viene identificata nessuna attivazione proveniente dal circuito negato associato.

Classi di Test Gli algoritmi utilizzati dai nodi per eseguire le verifiche sulle attivazioni e gli elementi della working-memory sono organizzati all’interno del package myclips.rete.tests. Alla base della strategia di progettazione dei test c’` l’utilizzo del design pattern comportamentale Strategy: allo scopo e di rendere gli algoritmi di test intercambiabili fra loro, vengono fornite due interfacce di base che tutti i test realizzano. La scelta dell’interfaccia da implementare indica la classe di nodi che potranno utilizzare i test: AlphaTest per i test utilizzabili nei nodi Alpha, BetaTest per quelli nei nodi Beta. 156

3.1. PROGETTAZIONE

Figura 3.20: Package myclips.rete.tests: vista dei test eseguiti nella porzione alpha La prima tipologia (Figura 3.20) esegue test su singoli elementi WME, valutando il possibile inserimento all’interno delle memorie locali presenti al termine dei circuiti alpha. Gli algoritmi possono valutare caratteristiche differenti dei singoli elementi come la lunghezza delle sequenze di OrderedFact, la visibilit` relativa ad un determinato Scope, la presenza di un elemento a costante in una determinata coordinata, etc. La seconda tipologia (Figura 3.21) esegue verifiche su gruppi di WME, rappresentati da Token, valutando la coerenza del valore di variabili comuni a pi` pattern, il risultato dell’esecuzione di funzioni o valutando i risultato u di test di tipo alpha eseguiti nella porzione beta del grafo. Al fine di poter eseguire i test di tipo alpha nei nodi di tipo beta ` stata adottata una strategia e facente riferimento al design pattern strutturale Adapter (anche noto con 157

3.1. PROGETTAZIONE

Figura 3.21: Package myclips.rete.tests: vista dei test eseguiti nella porzione beta il nome di Wrapper o Translator ): la classe AlphaInBetaNetworkTest, che realizza l’interfaccia BetaTest, incapsula oggetti con interfaccia AlphaTest al suo interno. Le operazioni di traduzione degli argomenti dei test vengono eseguite all’interno dell’implementazione della classe.

3.1.1.4

Modulo Interprete

Il modulo Interprete, contenuto nel package myclips.shell, consiste di un’unica classe fa¸ade: Interpreter. Lo scopo della classe ` quello semplificare ed c e unificare le operazioni di parsing e valutazione dei costrutti, associandole alle attivit` di inizializzazione del motore inferenziale e all’esecuzione del ciclo a 158

3.1. PROGETTAZIONE

Figura 3.22: Package myclips.rete.shell : vista della classe Interpreter principale (Figura 3.22). L’unica attivit` svolta dall’Interpreter ` quella di inizializzare un’istana e za del Parser, richiedere la valutazione di stringhe rappresentanti singoli costrutti o comandi e, se necessario, avviare l’interpretazione del costrutto dal parte di un’istanza di Network. Nel caso l’elemento valutato dal parser sia un comando (una chiamata a funzione di sistema), l’interprete provvede all’esecuzione dello stesso.

3.1.1.5

Modulo Events Manager

La gestione degli eventi ` affidata alla collaborazione fra la classe Evene tsManager, posta nel package myclips, e i listeners riuniti nel package myclips.listeners (Figura 3.23). Usando come base l’infrastruttura offerta dallo schema Observer/Observable, la classe EventsManager viene utilizzata nel sistema per notificare il verificarsi di eventi. In aggiunta ad una serie di eventi predefiniti raggruppati in STD EVENTS, la classe consente di notificare un qualsiasi evento personalizzato all’insieme di listener registrati.

159

3.1. PROGETTAZIONE

Figura 3.23: Package myclips.rete.listeners: vista della classi per la gestione degli eventi I listener sono classi che estendono la classe astratta EventsManagerListener. Il sistema fornisce un gruppo di definizioni predefinite con le quali intercettare gli eventi pi` comuni. Ogni classe, tramite la propria implemenu tazione, esegue un comportamento differente come risposta ai singoli eventi per i quali si registra. La procedura di registrazione dei listener ` effettuata e all’interno del metodo EventsManagerListener::install, alle super-classi viene offerta la possibilit` di personalizzare la procedura tramite l’implementazione a del metodo EventsManagerListener::installImpl, realizzando in questo modo lo schema previsto dal design pattern comportamentale Template method. 160

3.1. PROGETTAZIONE 3.1.1.6 Modulo Funzioni

Il package myclips.functions gestisce la collezione di funzioni di sistema, cos` ı come l’intera infrastruttura per la manipolazione della stessa (Figura 3.24). Alla base di ogni funzione di sistema c’` la classe astratta Function, e la quale realizza una strategia basata sul design pattern comportamentale Command. Il contesto d’esecuzione delle funzioni viene fornito attraverso un’istanza di classe FunctionEnv, la quale conserva riferimenti al Network, ModulesManager e alle risorse inizializzate dal sistema (l’elenco di stream di input/output). La base per la gestione delle definizioni ` offerta dal SystemFunctione Broker : definisce metodi per l’aggiunta o la rimozione di definizioni a runtime, cosi come implementa il meccanismo automatico di caricamento delle definizioni partendo da un registro conservato su file (tramite il metodo bootstrap). L’elenco di funzioni di sistema ` distribuito all’interno del sub-package e myclips.function. L’organizzazione adottata rispecchia la tipologia di funzioni. Le classi definite nel sub-package myclips.functions.myclips rappresentano funzioni originali del sistema MyCLIPS per la gestione di eventi e la valutazione degli artefatti (sia dal punto di vista prestazionale che di correttezza). Le restanti definizioni realizzano funzioni previste da CLIPS: le sintassi e le semantiche delle definizioni rispecchiano quelle previste dal software CLIPS per consentire la portabilit` degli artefatti fra i sistemi. a

161

3.1. PROGETTAZIONE

Figura 3.24: Package myclips.rete.functions: vista della classi per la gestione delle funzioni di sistema

162

3.1. PROGETTAZIONE

Figura 3.25: Vista generale dell’architettura server

3.1.2

Server

L’architettura del modulo server rispecchia uno schema orientato alla suddivisione delle attivit` svolte in servizi differenti e che realizzano specifiche a tipologie di interfaccia (Figura 3.25). Alla base delle implementazioni dei differenti servizi viene posto il componente software principale MyCLIPS.

3.1.2.1

Broker di servizi

Il componente Broker (Figura 3.26) ha il compito di organizzare i servizi offerti dal modulo server, controllando il flusso di richieste e risposte provenienti dall’infrastruttura addetta alla gestione delle connessioni con i client. La realizzazione dell’interfaccia Service, richiesta ad ogni classe concreta di servizio, garantisce l’implementazione dei metodi necessari alla registrazione della classe nel Broker. L’interfaccia viene ulteriormente estesa da ogni tipologia specifica di servizio. 163

3.1. PROGETTAZIONE

Figura 3.26: Package myclips server : vista delle classi e interfacce relative al Broker La creazione delle istanze concrete dei servizi viene delegata alle funzioni del Service Factory (classe Factory in Figura 3.26)

3.1.2.2

Servizio Sessioni

Il servizio Sessions (Figura 3.27) consente ai client di creare sessioni persistenti fra pi` richieste successive. Ogni sessione viene inizializzata e gestita u dalla classe concreta, che provveder` a memorizzarla fino a quando non vera ranno riscontrate condizioni favorevoli all’eliminazione. Il servizio fornisce sia un’interfaccia rivolta ai client (per la creazione, rimozione e rinnovo delle sessioni), sia ad altri servizi del sistema (per realizzare un meccanismo di stoccaggio persistente delle informazioni).

164

3.1. PROGETTAZIONE

Figura 3.27: Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio Sessions 3.1.2.3 Servizio Registro di tipi

Il servizio Registry (Figura 3.28) consente, a client e altri servizi, di manipolare tipi complessi non previsti da specifiche implementazioni del protocollo di trasmissione dei messaggi fra client e server. Le attivit` svolte dal servizio a sono quelle di organizzare una collezione di classi Skeleton che forniscano i metodi di conversione da classi specifiche a forme di pi` facile trasmissione u e viceversa. Il servizio offre anche la possibilit` ad altre parti del sistema di a registrare tipi di Skeleton personalizzati. L’implementazione concreta dell’interfaccia del servizio, realizzata dalla classe Registry, utilizza una collezione di Skeleton riuniti nel sub-package myclips server.xmlrpc.services.types.myclips skeletons per rappresentare costrutti e tipi utilizzati dal motore inferenziale.

165

3.1. PROGETTAZIONE

Figura 3.28: Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio Registry 3.1.2.4 Servizio Client IO

Il servizio ClientIO (Figura 3.29) permette ai client di fornire i parametri di utilizzo relativi a stream remoti che il server (e i relativi servizi) pu` o utilizzare in sostituzione degli stream locali. L’utilizzo degli stream remoti consente di dirottare tutte le normali operazioni di scrittura e lettura, eseguite all’interno del motore inferenziale, verso le risorse messe a disposizione dal client in maniera trasparente. Al client viene richiesta l’implementazione di un’interfaccia analoga a ClientIOStream.

166

3.1. PROGETTAZIONE

Figura 3.29: Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio ClientIO 3.1.2.5 Servizio Remote Shell

Il servizio RemoteShell (Figura 3.30) viene utilizzato per distribuire i servizi del modulo Interprete del sistema principale: attraverso lo scambio di comandi, trasferiti come stringhe di testo, ` possibile manipolare istanze remote del e motore inferenziale in maniera esattamente analoga a quanto avviene tramite l’utilizzo di un Terminale locale. Il servizio fa uso delle interfacce Sessions (per memorizzare l’istanza Interpreter ), Engine (per l’infrastruttura necessaria all’Interpreter ) e di ClientIO (per l’inoltro dei flussi input/output).

167

3.1. PROGETTAZIONE

Figura 3.30: Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio RemoteShell 3.1.2.6 Servizio Engine

Il servizio che realizza il collegamento fra client e il motore inferenziale prende il nome di Engine (Figura 3.31). Utilizzando i metodi pubblicizzati tramite l’interfaccia di servizio Engine, al client viene data la possibilit` di iniziaa lizzare il motore inferenziale aggiungendo costrutti (opportunamente creati tramite l’utilizzo del servizio Registry), eseguire il ciclo recognize-act e, utilizzando i metodi di ispezione forniti, analizzare lo stato finale del sistema. Tramite l’utilizzo dei servizi ClientIO e ClientEvents, il motore offre la stessa gamma di funzionalit` utilizzabili attraverso un’istanza locale del sistema. La a classe concreta che realizza il servizio si affida all’utilizzo dei metodi offerti dalla classe del core Network.

168

3.1. PROGETTAZIONE

Figura 3.31: Package myclips server.xmlrpc.services: vista delle classi e interfacce relative al servizio Engine

3.1.3

Terminale

L’interfaccia Terminale offerta dal sistema viene implementata tramite la collaborazione di due classi presenti nel package myclips.shell : Shell e Completer (Figura 3.32). La prima realizza il ciclo principale di immissione e valutazione dei comandi testuali forniti dall’utente, utilizzando le funzionalit` di a Interpreter, la seconda valuta il completamento automatico delle immissioni dell’utente, quando richiesto dalla pressione di un tasto speciale.

169

3.2. IMPLEMENTAZIONE

Figura 3.32: Package myclips.shell : vista delle classi relative al Terminale

3.2

Implementazione

La fase di implementazione ha richiesto la conversione delle strutture progettate e mostrate nei paragrafi precedenti tramite l’utilizzo di un linguaggio di programmazione. Inoltre ` stata necessaria la selezione del protocollo da e utilizzare per le comunicazioni client-server.

3.2.1

Scelta del linguaggio: Python

La scelta del linguaggio di programmazione da utilizzare per l’implementazione del sistema ` ricaduta su linguaggio intepretato Python 1 . A supporto e
1

http://www.python.org/

170

3.2. IMPLEMENTAZIONE

Figura 3.33: Comparazione fra Python e altri linguaggi di programmazione mostrando, da sinistra a destra, velocit` di produzione del codice, tempo a totale di produzione e lunghezza degli artefatti [Pre00]. della scelta si propongono le seguenti argomentazioni: Gratuit`: Python ` un linguaggio open-source utilizzabile, modificabile e a e distribuibile gratuitamente. Lo sviluppo del linguaggio ` affidato ad e una organizzazione no-profit (Python Software Foundation) [Pyt12a]. Facilit` di sviluppo: Python ` un linguaggio di programmazione generala e purpose di alto livello. La grande variet` di librerie distribuite insieme a alle implementazioni del linguaggio (con ambiti che variano dalla programmazione asincrona alla gestione degli archivi zip [Pyt12a] [Pyt12b]) o prodotte dalla comunit`2 consente di utilizzare le soluzioni offerte per a velocizzare i processi di sviluppo degli artefatti [Pre00] [PVS08]. Sinteticit` del linguaggio: studi comparativi fra linguaggi di programmaa zione attualmente disponibili (Figura 3.33) hanno evidenziato la propriet` del linguaggio di utilizzare una sintassi concisa senza ridurre le a capacit` espressive [Pre00] [PVS08]. a Meccanismi di riflessione: il linguaggio integra dei meccanismi di riflessione e caricamento a run-time avanzati che rendono agevole la realiz2

http://pypi.python.org/pypi

171

3.2. IMPLEMENTAZIONE zazione dei meccanismi di estensione dell’environment progettato. Le attivit` di inclusione di nuove funzioni di sistema o strategie CRS si a riducono alla semplice serializzazione degli algoritmi, senza la necessit` a di eseguire fasi di compilazione o integrazione complesse. Multi-piattaforma: il supporto al linguaggio ` disponibile per numerose e piattaforme e sistemi operativi [Pyt12a] (compresi quelli richiesti per il soddisfacimento del Vincolo-6 ). Capacit` di integrazione: sono disponibili numerose implementazioni di a Python (con diversi livelli di compatibilit`), realizzate in linguaggi come a Java3 , C#4 , C5 . Ognuna consente un’integrazione diretta con meccanismi propri del linguaggio di implementazione. In aggiunta, le capacit` a offerte dalle librerie permettono di utilizzare meccanismi di integrazione agnostici tra linguaggi eterogenei.

3.2.2

Protocollo: XML-RPC

Remote Procedure Call, o RPC, ` un meccanismo tramite il quale un’applie cazione posizionata su una macchina richiede l’utilizzo di servizi forniti da un’altra applicazione residente su una macchina differente. Con il termine macchina non viene unicamente inteso un host, un’installazione fisicamente separata, ma anche un processo residente in una porzione di memoria indipendente e che rende l’accesso alle risorse del servizio impossibile se non tramite il meccanismo RPC.
3 4

http://www.jython.org/ http://ironpython.net/ 5 Implementazione di riferimento: http://www.python.org/

172

3.2. IMPLEMENTAZIONE Il meccanismo RPC prevede che una prima applicazione possa inviare uno o pi` messaggi ad una applicazione differente per invocare delle prou cedure. L’applicazione ricevente ha la possibilit`, a sua volta, di inviare i a risultati dell’elaborazione tramite un ulteriore messaggio verso applicazione richiedente [MAL06]. RPC descrive un meccanismo generalizzato per l’invocazione di procedure remote, non una concreta implementazione di un protocollo o di tecnologie per lo scambio dei messaggi fra gli host. Partendo dal concetto generale di RPC, nel tempo sono state proposte differenti implementazioni basate su protocolli proprietari o codifiche dei messaggi differenti [Jai04] [Gro97].

Figura 3.34: Comunicazione tramite XML-RPC : immagine presente nella richiesta originale di brevetto [MAL06]. XML-RPC ` una fra le implementazioni proposte per RPC : si propone e come un meccanismo di chiamata a procedura remote semplice e versatile. Il brevetto originale con il quale ` stato proposto descrive sia il meccanismo di e 173

3.2. IMPLEMENTAZIONE chiamata, che un sistema per l’implementazione del metodo [MAL06]. XMLRPC prevede lo scambio di richieste e risposte usando il formato XML, attraverso meccanismi di trasporto multipli. Solitamente, con l’uso del termine XML-RPC si ` soliti per` indicare il protocollo di scambio messaggi in XML e o attraverso un meccanismo di trasporto basato sul protocollo HTTP. POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: betty.userland.com Content-Type: text/xml Content-length: 181

<?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall> Codice 3.1: Esempio di chiamata ad una procedura remota usando XML-RPC over HTTP La codifica dei messaggi viene effettuata incapsulando i parametri di chiamata ed i valori di ritorno all’interno di appositi frammenti del documento XML, i quali hanno il compito di attribuire una semantica alla stringa rappresentante il valore. I tag che contengono il valore ne determinano il tipo. Nell’esempio fornito in Codice 3.1, il valore ”41” (tipo integer ) viene incapsulato nel tag i4. Il tag indica appunto che il tipo del valore, come da specifica, ` un 4 bytes signed e 174

3.2. IMPLEMENTAZIONE HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 17 Jul 1998 19:55:08 GMT Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?> <methodResponse> <params> <param> <value><string>South Dakota</string></value> </param> </params> </methodResponse> Codice 3.2: Esempio di messaggi inviato a risposta di una chiamata a procedura remota usando XML-RPC over HTTP integer. La specifica prevede la possibilit` di utilizzare un set di tipi atomici con a i quali rappresentare tutti i parametri di chiamata a procedura o i valori di ritorno (”integer”, ”string”, ”boolean”, ”double”, ”dateTime.iso8601”, ”base64”) e un gruppo di strutture composte (”struct” per strutture analoghe a dizionari, ”array” per vettori) [Win00]. A supporto della scelta di utilizzare XML-RPC come protocollo RPC si propongono le seguenti argomentazioni: Semplicit`: il protocollo formalizza un metodo di interazione relativamente a semplice se comparato con le alternative disponibili. Il trasferimento delle informazioni avviene nella forma di parametri di input o output di funzioni ed il modello di comunicazione non forza l’utilizzo di modelli di 175

3.2. IMPLEMENTAZIONE sicurezza complessi. La fornitura del servizio non richiede la necessit` di a creare descrizioni formali dello stesso, sebbene l’utilizzo di strumenti di supporto6 permettano la generazione automatica di client per i servizi. Disponibilit`: l’utilizzo del protocollo ` possibile in molti linguaggi di proa e grammazione e piattaforme attraverso le implementazioni fornite da librerie apposite. Una stima approssimativa suggerisce la disponibilit` di a oltre 40 implementazioni differenti per un totale di oltre 25 piattaforme e linguaggi di programmazione [Wik12b].

3.2.3
3.2.3.1

Tecnologie utilizzate
Pyparsing

Pyparsing7,8 ` un modulo completamente scritto in linguaggio Python che e fornisce un insieme di classi per la creazione di parser di espressioni, sia elementari che complesse e che prevedono l’uso di componenti variabili. Le espressioni sono combinate usando gruppi di operatori (come ad esempio ”+” per definire la sequenzialit` o ”|” per le alternative), prevedendo l’utilizzo di a espressioni replicate o ricorsive [McG07]. Il modulo Parser ` stato implementato facendo uso delle classi fornite da e Pyparsing per la definizione delle regole di valutazione. L’interfaccia ParserRule mostrata nella descrizione del modulo Parser ` stata sostituita dall’uso e delle classi fornite da PyParsing. La classe principale Parser ` stata consee guentemente adattata per l’uso delle nuove istanze (Figura 3.35) [McG00].
6 7

XRDL: http://code.google.com/p/xrdl/ http://pyparsing.wikispaces.com/home 8 http://sourceforge.net/projects/pyparsing

176

3.2. IMPLEMENTAZIONE

Figura 3.35: Integrazione di PyParsing nel modulo Parser 3.2.3.2 BList

Figura 3.36: Confronto fra l’implementazione di vettori fornita da BList e quella di default fornita da CPython: prestazioni dell’operazione di inserimento [Stu12b].

La libreria BList9 ` un modulo Python per la sostituzione trasparente e dell’implementazione delle collezioni fornite dal linguaggio [Stu12a]. Fornisce prestazioni superiori rispetto all’implementazione standard dei vettori durante la manipolazione di collezioni di grandi dimensioni e fornisce realizzazioni di liste ordinate (Figura 3.36) [Stu12b]. Le liste ordinate fornite da Blist sono state utilizzate nell’implementazione delle strategie CRS Mea e Lex per l’inserimento ordinato delle attivazioni
9

http://stutzbachenterprises.com/blist/

177

3.2. IMPLEMENTAZIONE

Figura 3.37: Esempio d’uso della libreria NetworkX per la rappresentazione del circuito compilato ottenuto dalla regola controlla input in Codice A.1 nell’agenda.

3.2.3.3

NetworkX

NetworkX10 ` un pacchetto software per il linguaggio Python per la creazione, e manipolazione e lo studio di strutture, dinamiche e funzioni di reti complesse. La libreria viene utilizzata per l’implementazione del Listener NetworkPlotter, usato per offrire una rappresentazione grafica della RETE compilata (Figura 3.37), e per la generazione degli script in formato dot 11 contenenti una serializzazione della rappresentazione di RETE da trasmettere ai client.
10 11

http://networkx.lanl.gov/ http://en.wikipedia.org/wiki/DOT language

178

3.3. VALUTAZIONE

3.3

Valutazione

Al fine di valutare il prototipo di sistema realizzato, sono stati prodotti o adattati una serie di sistemi esperti in modo che risultassero compatibili con l’environment. L’analisi del prototipo si ` concentrata nella valutazione di e due aspetti fondamentali: la correttezza di funzionamento, sia in ambiti di utilizzo locale che tramite modulo server, e le prestazioni, effettuando un confronto con CLIPS. Per la sperimentazione di utilizzo locale si ` fatto uso del modulo Tere minale prodotto e descritto in questa trattazione. Per la sperimentazione di utilizzo remoto, si ` fatto uso di un terminale remoto realizzato in linguaggio e Java che consentisse di replicare le funzionalit` del modulo Terminale locale. a

3.3.1

Correttezza

Il primo gruppo di test effettuati ha come obiettivo quello di valutare la correttezza del funzionamento del prototipo e del motore inferenziale. I test sono stati condotti utilizzando una serie di sistemi esperti, analizzando il comportamento del prototipo alla variazione degli input offerti. Si protone una descrizione sommaria degli artefatti con un riferimento all’implementazione utilizzata: 1. Problema dell’agricoltore, realizzazione 1: ”un agricoltore deve attraversare un fiume portando con s´ un cavolo, una pecora ed un lupo. e La barca che pu` utilizzare per l’operazione ` in grado di trasportare o e non pi` di due attori per volta. Durante l’attraversamento deve prestare u attenzione agli spostamenti da effettuare: ` risaputo che, se lasciati e 179

3.3. VALUTAZIONE soli, la pecora mangia il cavolo e il lupo mangia la pecora”. La prima formulazione proposta per la soluzione del problema prevede l’utilizzo di fatti in notazione Ordered-Fact (Codice A.1). 2. Problema dell’agricoltore, realizzazione 2: la seconda soluzione proposta utilizza soltanto fatti in notazione Template-Fact (Codice A.2). 3. Sistema per la diagnosi medica: si propone la formulazione di un basilare sistema esperto per la diagnosi delle malattie del fegato. La realizzazione prevede l’utilizzo di fatti in notazione Template-Fact, l’utilizzo del costrutto DefFunction, per la realizzazione di funzioni utente di supporto alla richiesta di informazioni e alla validazione degli input forniti, e l’utilizzo del costrutto DefGlobal (Codice A.3). 4. Sistema per la diagnosi meccanica: si propone la formulazione di un basilare sistema esperto per la diagnosi dei malfunzionamenti di un’automobile. La realizzazione12 , distribuita insieme al software CLIPS, valuta i possibili malfunzionamenti interrogando l’utente per ottenere le informazioni necessarie. I risultati delle prove vengono valutati confrontando l’esecuzione dei medesimi artefatti nell’ambiente CLIPS.
12

http://clipsrules.svn.sourceforge.net/viewvc/clipsrules/examples/auto.clp?revision=93

180

3.3. VALUTAZIONE

3.3.2

Prestazioni

Il secondo gruppo di test eseguiti ha come obiettivo quello di valutare il sistema dal punto di vista prestazionale. I test sono stati condotti utilizzando implementazioni delle soluzioni per il problema Manners [Bra+91] [Mir91], per il problema Scimmia e banane [Ril00a] e del gioco del Sudoku [Ril00b]. Le formulazioni utilizzate per la soluzione dei problemi sono quelle distribuite insieme al software CLIPS. Le valutazioni e i confronti fra i due sistemi vengono effettuate osservando i tempi di esecuzioni sulle medesime implementazioni. Per ogni istanza di test sono stati eseguiti dieci run in` dipendenti, riavviando l’environment al termine di ognuno. E stata quindi utilizzata la media dell’esecuzione dei dieci run per i confronti.

3.3.2.1

Manners

Il benchmark Manners fa riferimento al problema di individuare una disposizione dei posti accettabile per un gruppo di invitati ad una cena. La soluzione dovrebbe garantire che ogni ospite sia seduto vicino a qualcuno di sesso opposto che condivida con lui almeno uno dei suoi hobby. Il processo di soluzione ` basato su una ricerca in profondit` fra le solue a zioni al problema per individuare una disposizione accettabile. Il programma Manners pu` essere esteso per gestire differenti criteri di organizzazioo ne dei posti, inoltre rende possibile modificare la complessit` d’esecuzione a controllando la distribuzione degli hobby associati agli invitati. I dati usati per questa valutazione utilizzano una distribuzione uniforme degli hobby, da un minimo di 2 ad un massimo di 5, per ogni invitato. La verifi-

181

3.3. VALUTAZIONE ca ha interessato l’utilizzo di quattro dataset differenti: per 8, 16, 32 e 64 invitati [KDS90] [Bra+91]. Di seguito (Tabella 3.1) sono proposti i risultati dei test effettuati sui sistemi CLIPS, MyCLIPS (localmente, tramite Terminale) e MyCLIPS (in remoto, tramite una RemoteShell). Tabella 3.1: Tempi d’esecuzione del benchmark Manners variando il numero di ospiti Manners Sistema CLIPS (6.24) MyCLIPS (locale) MyCLIPS (server) 8 0.005 0.311 0.327 Ospiti 16 32 0.092 1.321 5.461 149.1 5.642 157.1 64 40.38 4580 4771

3.3.2.2

Sudoku

Il Sudoku ` un gioco di logica nel quale al risolutore viene proposta una griglia e di n2 × n2 celle, ciascuna delle quali pu` contenere un numero compreso nella o sequenza fra 1 e n2 o essere vuota. La griglia ` suddivisa in righe e colonne di e lunghezza n2 e in sotto-griglie, chiamate regioni, di n × n celle contigue. Lo scopo del gioco ` quello di risolvere il puzzle inserendo un numero nelle celle e vuote in modo tale che ogni riga, colonna o regione della scacchiera contenga ognuno dei numeri della sequenza 1 . . . n2 senza ripetizioni [Wik12a]. Il benchmark Sudoku, nell’implementazione distribuita insieme al software CLIPS [Ril00b], consente di valutare le prestazioni dei sistemi stressando i nodi della Beta-Network generando una grande attivit` nei nodi Join a positivi e negativi (Figura 3.38). Le regole utilizzate per la formalizzazione

182

3.3. VALUTAZIONE

Figura 3.38: Profilazione dell’esecuzione del benchmark Sudoku: grafico delle chiamate, dettaglio su VariableBindingTest

183

3.3. VALUTAZIONE delle strategie utilizzano condizioni simili, garantendo un’alta percentuale di condivisione dei nodi alpha [BREB07]. I test sono stati eseguiti utilizzando griglie di dimensioni 9 × 9 (n = 3) e due dataset differenti13,14 . Di seguito (Tabella 3.2) sono proposti i risultati dei test effettuati sui sistemi CLIPS, MyCLIPS (localmente, tramite Terminale) e MyCLIPS (in remoto, tramite una RemoteShell). Tabella 3.2: Tempi d’esecuzione del benchmark Sudoku per i dataset grid3x3p13 e grid3x3-p15 Sudoku Sistema CLIPS (6.24) MyCLIPS (locale) MyCLIPS (server) Puzzle grid3x3-p13 grid3x3-p15 5.315 8.488 712.4 981.2 705.8 974.8

3.3.2.3

Monkey

Il benchmark Monkey fa riferimento ad un problema classico di pianificazione: l’obiettivo del problema ` individuare la sequenza di azioni che consentono e ad una scimmia di mangiare un casco di banane nascosto all’interno di un forziere chiuso a chiave posto in cima ad una pila di oggetti. La chiave che consente l’apertura del forziere ` nascosta all’interno di un secondo forziere, e anch’esso posto su una pila di oggetti. La scimmia ` in grado di spostarsi e nell’ambiente prendere, scaraventare e trasportare oggetti, oltre che utilizzare le chiavi per aprire i forzieri.
grid3x3-p13: http://clipsrules.svn.sourceforge.net/viewvc/clipsrules/examples/sudoku/ puzzles/grid3x3-p13.clp?revision=93 14 grid3x3-p15: http://clipsrules.svn.sourceforge.net/viewvc/clipsrules/examples/sudoku/ puzzles/grid3x3-p15.clp?revision=93
13

184

3.3. VALUTAZIONE L’implementazione utilizzata per la risoluzione ` quella distribuita insiee me al software CLIPS [Ril00a]: durante la risoluzione del problema vengono visualizzate sullo schermo le operazioni svolte dalla scimmia15 . Di seguito (Tabella 3.3) sono proposti i risultati dei test effettuati sui sistemi CLIPS, MyCLIPS (localmente, tramite Terminale) e MyCLIPS (in remoto, tramite una RemoteShell). Tabella 3.3: Tempi d’esecuzione del benchmark Monkey Monkey Sistema CLIPS (6.24) MyCLIPS (locale) MyCLIPS (server) Tempo 0.004 0.111 0.779

3.3.3

Osservazioni

Grazie ai vari test effettuati ` possibile affermare che le capacit` del sistema e a prodotto risultano paragonabili a quelle del software di riferimento CLIPS. I test hanno mostrato un livello di compatibilit` di sistema che va al di l` a a della sola portabilit` degli artefatti: la sequenza delle attivazioni ed i relativi a processi di ragionamento simulati dai sistemi risultano costanti in entrambi gli environment. Sia i risultati che le modalit` con le quali sono stati ottenuti a vengono replicati esattamente dal prototipo realizzato. Sebbene il divario in termini prestazionali sia evidente, l’obiettivo di questo elaborato era quello di realizzare un environment funzionate con finalit` a didattiche e di ricerca, una base per sviluppi futuri. La scelta stessa del linguaggio ` stata effettuata trascurando le problematiche di tipo prestazionale e
15

La soluzione consiste di 42 operazioni consecutive

185

3.3. VALUTAZIONE e privilegiando invece criteri di selezione come la facilit` e rapidit` di svilupa a po e le possibilit` di estensione offerte. Come emerso da diverse comparazioni a effettuate fra linguaggi [PVS08] [Pre00] [Nai99], la valutazione della prestazione pura espressa in termini di tempo non vede Python emergere fra i migliori [CLB12] [PVS08] [Pre00]. Il divario misurato tramite l’utilizzo della benchmark suite in [CLB12] vede il linguaggio C risultare fino a cento volte pi` rapido rispetto a Python (Figura 3.39). Chiaramente si propongono u questi dati consci del fatto che trarre conclusioni semplicemente basandosi su numeri e senza effettuare i dovuti distinguo non rappresenta un approccio efficace ad un problema tanto complesso quanto lo ` la valutazione empirica e delle prestazioni di un linguaggio di programmazione [SW11]. Le ridotte prestazioni offerte dal linguaggio, non sono state ritenute una ragione sufficiente ad invalidare la preferenza espressa, soprattutto tenendo conto dei vantaggi che la soluzione ha offerto durante lo sviluppo del prototipo e che pu` potenzialmente offrire durante l’ulteriore sviluppo del sistema, o principale obiettivo di questa tesi. Il Vincolo-7 non poneva delle limitazioni di rapidit` alla soluzione prodotta se non quella di rendere possibile un cona fronto fra il prototipo e CLIPS utilizzando strumenti gi` fruttati in passato a per questa finalit` [BREB07] [Mir91] [Bra+91]. a Analizzando i risultati in ambito locale, si pu` evidenziare come il protoo tipo risulti fra le 20 e le 130 volte pi` lento rispetto al software di riferimento. u I risultati migliori sono stati ottenuti nel benchmark Monkey, dove la relativa semplicit` del test ha permesso di marcare risultati ben al di sotto della a soglia attesa. Le differenze risultano lievemente al di sotto delle attese anche per i test Manners con 8 e 16 ospiti. Il divario si fa pi` marcato nel momento u 186

3.3. VALUTAZIONE

Figura 3.39: Python 3 vs C: esecuzione della benchmark suite [CLB12] in cui la dimensione del dataset e la complessit` dei test cresce, evidenziando a maggiormente i limiti della soluzione proposta. Quello che invece risulta pi` interessante ` l’analisi dell’andamento del u e gap prestazionale evidenziato dai test differenti (Figura 3.40). Il rapporto fra il prototipo e il software di riferimento ` rimasto pressoch´ costante (come e preso fra le 100 e 130 volte) anche a fronte di un aumento dei tempi reali di esecuzione dell’ordine di 40 volte, dimostrando una corrispondenza di comportamento fra il software di riferimento ed il sistema proposto in rapporto all’aumento della complessit` dei test. a L’analisi dei risultati ottenuti utilizzando il sistema tramite un’istanza server evidenzia una corrispondenza con i risultati ottenuti tramite utilizzo locale. L’unica eccezione risiede nei risultati del benchmark Monkey, dove si riscontra un peggioramento delle prestazioni evidente. Bisogna per` effeto tuare delle valutazioni particolari per comprendere appieno il risultato del singolo test: il benchmark esegue durante il processo 42 operazioni di out187

3.3. VALUTAZIONE
MyCLIPS (locale) ÷ CLIPS 200 MyCLIPS usa (tempo) MyCLIPS usa (tempo) 200 MyCLIPS (server) ÷ CLIPS

150

150

100

100

50

50

m an ne m an rs − n 8 m ers an − 16 n m ers an − 32 ne su rs − do 64 k su u − do p ku 13 − p1 m 5 on ke y

Figura 3.40: Grafici dei rapporti prestazionali fra MyCLIPS e CLIPS: a sinistra il confronto con un’istanza locale di MyCLIPS, a destra con una server put a fronte di un tempo di esecuzione di un decimo di secondo. In questo caso, i tempi richiesti per le operazioni di inoltro dei dati verso lo stream remoto dominano quelli di esecuzione del test in s´. Lo stesso fenomeno non e si presenta durante l’esecuzione del benchmark Sudoku: sebbene, in termini assoluti, il test esegua un maggior numero di operazioni di output su stream (oltre 200), i risultati non risultano influenzati data la maggior durata dello stesso. Si conclude quindi che l’utilizzo remoto del prototipo offra prestazioni e possibilit` in linea con un utilizzo locale. a

188

m an ne m an rs − n 8 m ers an − 16 n m ers an − 32 ne su rs − do 64 k su u − do p k u 13 − p1 m 5 on ke y

Conclusioni e sviluppi futuri
L’integrazione degli strumenti di sviluppo per sistemi esperti con tecnologie orientate alla distribuzione degli stessi in ambito Web ha offerto lo spunto per questo lavoro di tesi. Prendendo come riferimento le funzionalit` offerte da a un environment di larga adozione come CLIPS, ` stata progettata e quindi e realizzata una soluzione compatibile che enfatizzasse le capacit` di estensibia lit` e integrazione dei sistemi sviluppati in software di tipo tradizionale. In a particolare, a tale scopo, ci si ` concentrati, per la realizzazione del prototie po, su un linguaggio di programmazione che offrisse supporto a tali requisiti: Python. Al fine di saggiare la flessibilit` della soluzione proposta ` stata esea e guita l’integrazione della soluzione in un modello d’architettura client-server e quindi ` stato valutato l’impatto che l’adozione di questa tecnologia ha e avuto sulle prestazioni complessive del sistema. Durante questa trattazione ` stata fornita una definizione di sistemi espere ti, approfondendo le tematiche relative al loro processo di sviluppo e all’ambito di utilizzo degli stessi. L’attenzione ` stata quindi focalizzata verso le e tecniche utilizzate per la formalizzazione della conoscenza in strutture adatte al calcolo e si ` quindi offerta una classificazione generale degli strumenti di e sviluppo per sistemi esperti. Sono state poi approfondite le problematiche 189

CONCLUSIONI E SVILUPPI FUTURI relative alla progettazione e alla realizzazione di un prototipo funzionante di environment multi-paradigmatico, successivamente sottoposto ad una valutazione per testarne la correttezza e le prestazioni. Da quanto osservato durante la sperimentazione si pu` affermare che i o risultati ottenuti sono in linea con le attese. Il livello di compatibilit` con il a sistema di riferimento risulta soddisfacente, i costrutti pi` utilizzati e conu siderati indispensabili vengono resi disponibili dal prototipo e i comportamenti riscontrati trovano corrispondenza fra i due sistemi. L’analisi della prestazione ha mostrato un gap a favore dello stato dell’arte, ma il degrado delle prestazioni, superato un valore di soglia, replica esattamente il comportamento riscontrato nella soluzione di riferimento. Una delle cause alla base delle minori prestazioni, ma non l’unica, ` il linguaggio utilizzato per e l’implementazione del prototipo. L’analisi del grafico delle chiamate (Figura 3.38) generato durante la profilazione del benchmark Sudoku ha messo in luce alcune criticit`, che potranno essere oggetto di sviluppi futuri di questo a lavoro: 1. la realizzazione scelta per la rappresentazione dei Token nel sistema utilizza una struttura ad albero per ridurre il consumo di memoria e permettere una condivisione delle informazioni [Doo95]. Questo approccio ha comportato un maggior dispendio di tempo per l’esecuzione delle procedure di matching a causa della forma utilizzata per serializzazione delle regole nello specifico test. Ulteriori lavori potranno approfondire i benefici dell’adozione di una struttura lineare [Doo95] per la memorizzazione dei Token, valutando sia l’impatto prestazionale che il consumo di memoria. 190

CONCLUSIONI E SVILUPPI FUTURI 2. l’implementazione dei pattern Test-CE prevede l’esecuzione di chiamate a funzione senza prevedere alcun sistema di caching dei risultati. Verifiche successive richiedono una nuova esecuzione della funzione anche nei casi in cui gli input siano identici a quelli di valutazioni precedenti. La progettazione di un meccanismo di memorizzazione dei risultati delle valutazioni, indicizzandolo in base ai dati di input, potrebbe ridurre il tempo globale di esecuzione dei sistemi che fanno largo uso di pattern di tipo Test-CE su input costanti. Altri sviluppi potranno interessare l’integrazione del prototipo con l’aggiunta di ulteriori funzionalit` o la valutazione di tecniche algoritmiche ala ternative in sostituzione a componenti forniti dal sistema: • l’integrazione di un regime di controllo alternativo basato sul backwardchaining o su approcci ibridi, garantendo agli ingegneri della conoscenza maggiore flessibilit` durante le fasi di progettazione. L’integrazione a di formalismi originali nel linguaggio di specifica e delle relative strutture per la gestione degli stessi nel motore inferenziale, potr` garantire a il supporto a meccanismi di inferenza differenti [LY95], mantenendo immutata la compatibilit` con gli artefatti CLIPS. a • l’integrazione del paradigma di programmazione basato su oggetti nel linguaggio di specifica. L’aggiunta di un set di costrutti analoghi a quelli proposti nell’estensione COOL del linguaggio CLIPS estenderebbe ulteriormente il livello di compatibilit` dei sistemi e fornirebbe al a prototipo un meccanismo di specifica basato sugli oggetti.

191

CONCLUSIONI E SVILUPPI FUTURI • la sostituzione delle implementazioni dei moduli Builder e Analyzer, potrebbe offrire l’opportunit` di approfondire le tematiche relative ala l’utilizzo di algoritmi di matching differenti da RETE come ad esempio TREAT [Mir87b] [Mir87a] o LEAPS [Bat94]. • aggiungendo nuovi formalismi nel linguaggio di specifica che consentano l’associazione di valori di confidenza a pattern e regole, aggiungendo inoltre nuovi test in grado di eseguire valutazioni basate su valori di soglia, sarebbe possibile integrare nel motore inferenziale degli strumenti per la gestione dell’incertezza e della logica Fuzzy [Orc04].

192

Bibliografia capitolo 3
[LY95] Y. H. Lee e S. I. Yoo. “A Rete-based Integration of Forward and Backward Chaining Inferences”. In: Proceedings of the 1995 IEEE International Symposium on Intelligent Controll. (27 Ago. 1995). Monterey, CA: IEEE, 1995, pp. 611–616. isbn: 2158-9860. doi: http://dx.doi.org/10.1109/ISIC.1995.525122. [Doo95] R. B. Doorenbos. “Production Matching for Large Learning Systems”. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Science Department, gen. 1995. 208 pp. [Orc04] B Orchard. FuzzyCLIPS Version 6.10d. User’s Guide. National Research Council Canada. 2004. [Nai99] D. Naiditch. “Selecting a programming language for your project”. In: Aerospace and Electronic Systems Magazine, IEEE 14 (9 set. 1999), pp. 11–14. issn: 0885-8985. doi: 10 . 1109 / 62 . 793447. [Pre00] L. Prechelt. “An Empirical Comparison of Seven Programming Languages”. In: Computer 33 (2000), pp. 23–29. issn: 0018-9162.

193

BIBLIOGRAFIA CAPITOLO 3 doi: http : / / doi . ieeecomputersociety . org / 10 . 1109 / 2 . 876288. [PVS08] K. Prashant, S. Vaibhav e N. Shashi. Programming Languages: A Comparative Study. Rapp. tecn. Mag. 2008. [MAL06] P. Merrick, S. Allen e J. Lapp. XML remote procedure call (XMLRPC). Patent. US 7028312. 11 Apr. 2006. url: http://www. patentlens.net/patentlens/patent/US_7028312/en/. [Jai04] P. Jairath. Inter-object communication interface bridge. Patent Application. Ver. A1. US 2004/0237092 A1. 25 Nov. 2004. url: http://www.patentlens.net/patentlens/patent/US_2004_ 0237092_A1/en/. [Gro97] The Open Group. DCE 1.1: Remote Procedure Call. CAE Specification (1997) C706. Technical Standard. Berkshire, U.K.: The Open Group, 1997. 737 pp. url: https://www2.opengroup. org / ogsys / jsp / publications / PublicationDetails . jsp ? publicationid=11259. [Win00] D. Winer. XML-RPC Specification. Mag. 2000. url: http:// www.xmlrpc.com/spec. [Pyt12a] Python Frequently Asked Questions. Python Software Foundation. 2012. url: http://docs.python.org/faq/ (visitato il 26/09/2012). [Pyt12b] The Python Standard Library. Python Software Foundation. 2012. url: http://docs.python.org/library/ (visitato il 26/09/2012).

194

BIBLIOGRAFIA CAPITOLO 3 [Wik12b] XML-RPC - Wikipedia, the free encyclopedia. Implementations. Wikipedia Foundation, Inc. 2012. url: http://en.wikipedia. org/wiki/XML-RPC#Implementations (visitato il 26/09/2012). [McG07] P. McGuire. Getting Started with Pyparsing. O’Reilly Short Cuts. Sebastopol, CA: O’Reilly Media, 2007. isbn: 9780596514235. [McG00] P. McGuire. Pyparsing API references. API References. 200-. url: http://packages.python.org/pyparsing/. [Stu12a] D. Stutzbach. blist: an asymptotically faster list-like type for Python. 2012. url: http://stutzbachenterprises.com/blist/. [Stu12b] D. Stutzbach. Performance of the blist. 2012. url: http : / / stutz-bachenterprises.com/performance-blist. [Bra+91] D. A. Brant, T. Grose, B. Lofaso e D. P. Miranker. “Effects of Database Size on Rule System Performance:Five Case Studies”. In: Proceedings of the 17th International Conference on Very Large Data Bases (VLDB). 1991. [Mir91] D. P. Miranker. The University of Texas OPS5 Rule Engine Benchmark Programs and Data Generators. 1991. url: ftp : //ftp.cs.utexas.edu/pub/ops5-benchmark-suite/ (visitato il 15/08/2012). [Ril00b] G. Riley. Sudoku benchmark for CLIPS. 200-. url: http : / / sourceforge.net/apps/trac/clipsrules/browser/examples/ sudoku (visitato il 15/08/2012).

195

BIBLIOGRAFIA CAPITOLO 3 [Ril00a] G. Riley. Monkees and Bananas benchmark for CLIPS. 200-. url: http : / / sourceforge . net / apps / trac / clipsrules / browser/examples/map.clp (visitato il 15/08/2012). [KDS90] G. Kiernan, C. De Maindreville e E. Simon. Making deductive database a practical technology : a step forward. Inglese. Research Report RR-1153. Projet SABRE. INRIA, gen. 1990. url: http: //hal.inria.fr/inria-00075406. [Wik12a] Sudoku - Wikipedia, the free encyclopedia. Wikipedia Foundation, Inc. 2012. url: http://it.wikipedia.org/wiki/Sudoku (visitato il 26/09/2012). [BREB07] Business Rule Engine Benchmarks. Illation, Inc. 2007. url: http: //illation.com/benchmarks/ (visitato il 15/08/2012). [CLB12] The Computer Language Benchmarks Game. 2012. url: http: //shootout.alioth.debian.org/ (visitato il 16/08/2012). [SW11] R. Sedgewick e K. Wayne. Algorithms. 4a ed. Addison-Wesley Professional, 2011. 976 pp. isbn: 978-0-321-57351-3. [Mir87b] D. P. Miranker. TREAT: A Better Match Algorithm for AI Production Systems; Long Version. Rapp. tecn. Austin, TX, USA, 1987. url: http://www.cs.utexas.edu/ftp/AI-Lab/techreports/UT-AI-TR-87-58.pdf. [Mir87a] D. P. Miranker. “TREAT: a better match algorithm for AI production systems”. In: Proceedings of the sixth National conference on Artificial intelligence - Volume 1. AAAI’87. Seattle,

196

BIBLIOGRAFIA CAPITOLO 3 Washington: AAAI Press, 1987, pp. 42–47. isbn: 0-934613-42-7. url: http : / / www . aaai . org / Papers / AAAI / 1987 / AAAI87 008.pdf. [Bat94] D. Batory. The LEAPS Algorithm. Rapp. tecn. Austin, TX, USA, 1994.

197

Bibliografia
[Aik83] J. S. Aikins. “Prototypical knowledge for expert systems”. In: Artificial Intelligence 20.2 (1983), pp. 163–210. issn: 0004-3702. doi: 10.1016/0004-3702(83)90017-6. [Aik+82] J. S. Aikins, J. C. Kunz, E. H. Shortliffe e R. J. Fallat. PUFF: An Expert Sstem for Interpretation of Pulmonary Function Data. technical repor HPP-82-I3. Stanford, CA 94305: Departments of Medicine e Computer Science, Stanfor University, set. 1982. 22 pp. isrn: STAN-CS-82-931. url: ftp://reports.stanford. edu/pub/cstr/reports/cs/tr/82/931/CS-TR-82-931.pdf. [And93] J. R. Anderson. Rules of the Mind. A cura di Routledge. Taylor & Francis, 1993. 336 pp. isbn: 9780805812008. url: http:// books.google.it/books?id=xYvLraxYTZoC. [BCF81] A. Barr, P .R. Cohen e E. A. Feigenbaum. The Handbook of Artificial Intelligence. A cura di W. Kaufman. Vol. 1. AddisonWesley, 1981. 409 pp. isbn: 0-86576-005-5. [Bat94] D. Batory. The LEAPS Algorithm. Rapp. tecn. Austin, TX, USA, 1994.

198

BIBLIOGRAFIA [BE79] J. S. Bennett e S. Engelmore R. “SACON: a knowledge-based consultant for structural analysis”. In: Proceedings of the 6th international joint conference on Artificial intelligence. Vol. 1. IJCAI’79. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1979, pp. 47–49. isbn: 0-934613-47-8. url: http : //dl.acm.org/citation.cfm?id=1624861.1624873. [Boa98] IEEE-SA Standards Board. IEEE Recommended Practice for Software Requirements Specifications. Norm. IEEE 830-1998. 1998. [Bou93] N. G. Bourbakis. Knowledge Engineering Shells: Systems and Techniques. Advanced Series on Artificial Intelligence 2. World Scientific, 1993. isbn: 9789810210564. url: http : / / books . google.it/books?id=q8hJrIowpMsC. [Bra+91] D. A. Brant, T. Grose, B. Lofaso e D. P. Miranker. “Effects of Database Size on Rule System Performance:Five Case Studies”. In: Proceedings of the 17th International Conference on Very Large Data Bases (VLDB). 1991. [Bro85] L. Brownston. Programming expert systems in OPS5: an introduction to rule-based programming. Addison-Wesley series in artificial intelligence. Addison-Wesley, 1985. isbn: 9780201106473. url: http://books.google.it/books?id=7OVQAAAAMAAJ. [BD83] B. G. Buchanan e R. O. Duda. “Principle of Rule-Based Expert Systems”. In: M.C. Yovits. Advances in Computers. Vol. 22. Advances in Computers. Academic Press, 1983. isbn: 9780120121229. url: http://books.google.it/books?id=UhFOZTCt4bcC. 199

BIBLIOGRAFIA [BSM84] B. G. Buchanan, E. H. Shortliffe e W. van Melle. “EMYCIN: A Knowledge Engineer’s Tool for Constructing Rule-Based Expert Systems”. In: B. G. Buchanan e E. H. Shortliffe. Rule-based expert systems. The MYCIN experiments of the Stanford Heuristic Programming Project. Addison-Wesley, 1984. Cap. 15, pp. 303– 313. isbn: 0201101726. url: http://people.dbmi.columbia. edu/~ehs7001/Buchanan-Shortliffe-1984/Chapter-15.pdf. [BREB07] Business Rule Engine Benchmarks. Illation, Inc. 2007. url: http: //illation.com/benchmarks/ (visitato il 15/08/2012). [Cha98] R. Chatterjee. “KBMS-based evolutionary prototyping of objectoriented software systems”. PhD thesis. University of Florida, 1998. 131 pp. [Cli92] CLIPS. Architecture Manual. CLIPS Version 5.1. 1992. url: http://clipsrules.sourceforge.net/documentation/other/ arch5-1.pdf. [DK75] R. Davis e J. King. An Overview of Production Systems. technical report. Stanford University, ott. 1975. 38 pp. isrn: STANCS-75-524. url: http://www.dtic.mil/cgi-bin/GetTRDoc? AD=ADA019702. [Dok05] M. I. Dokas. “Developing Web Sites For Web Based Expert Systems: A Web Engineering Approach”. In: In the Proceedings of the Information Technologies in Environmental Engineering (ITEE’2005). A cura di Otto-von-Guericke-Universitat Magdeburg. 2005, pp. 202–217. 200

BIBLIOGRAFIA [Doo95] R. B. Doorenbos. “Production Matching for Large Learning Systems”. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Science Department, gen. 1995. 208 pp. [Esp12] F. Esposito. Ingegneria delle Conoscenza e Sistemi Esperti. Materiale a supporto. Bari: Universit` degli Studi di Bari, 2012. a [FFA95] E. A. Feigenbaum, J. Feldman e P. Armer. Computers and thought. AAAI Press Series. AAAI Press, 1995. isbn: 9780262560924. [For79] C. L. Forgy. “On the Efficient Implementation of Production Systems”. AAI7919143. PhD thesis. Pittsburgh, PA, USA: Carnegie Mellon University, Computer Sience Department, 1979. [For81] C. L. Forgy. OPS5 user’s manual. Paper 2397. Computer Science Department. Carnegie Mellon University, 1981. 57 pp. url: http://repository.cmu.edu/compsci/2397/. [For82] C. L. Forgy. “Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”. In: Artificial Intelligence 19.1 (1982), pp. 17–37. issn: 0004-3702. doi: 10.1016/00043702(82)90020-0. [GP91] D. N. Gordin e A. J. Pasik. “Set-oriented constructs: from Rete rule bases to database systems”. In: Proceedings of the 1991 ACM SIGMOD international conference on Management of data. SIGMOD ’91. Denver, Colorado, United States: ACM, 1991, pp. 60–67. isbn: 0-89791-425-2. doi: 10.1145/115790.115797. url: http://doi.acm.org/10.1145/115790.115797.

201

BIBLIOGRAFIA [GS05] J. Greene e A. Stellman. Applied software project management. First. O’Reilly, 2005. isbn: 0596009488. [GL89] N. L. Griffin e F. D. Lewis. “A Rule-Based Inference Engine which is Optimal and VLSI Implementable”. In: Tools for Artificial Intelligence. Architectures, Languages and Algorithms. IEEE International Workshop (Fairfax, VA, 1989). 1989, pp. 246–251. isbn: 0-8186-1984-8. doi: 10.1.1.24.4645. [Gro97] The Open Group. DCE 1.1: Remote Procedure Call. CAE Specification (1997) C706. Technical Standard. Berkshire, U.K.: The Open Group, 1997. 737 pp. url: https://www2.opengroup. org / ogsys / jsp / publications / PublicationDetails . jsp ? publicationid=11259. [Hal91] P. Haley. “Data-driven backward chaining”. In: Proceedings of the Second Annual CLIPS Conference. NASA Johnson Space Center. Houston TX, set. 1991. [HJW94a] C. W. Holsapple, V. S. Jacob e A. B. Whinston. “Object-Oriented Knowledge Representation”. In: Operations Research and Artificial Intelligence. 1994. Cap. 4, pp. 58–70. [HJW94b] C. W. Holsapple, V. S. Jacob e A. B. Whinston. Operations Research and Artificial Intelligence. Operations Research and Artificial Intelligence. Ablex Publishing Corporation, 1994. isbn: 9781567500363. url: http://books.google.it/books?id= OKn2v\_\_x-OwC.

202

BIBLIOGRAFIA [HT99] P. V. Homeier e C. L. Thach. ECLIPS: An Extended CLIPS for Backward Chaining and Goal-Directed Reasoning. paper. The Aerospace Corporation. 199-. 11 pp. url: ftp://cobase.cs. ucla.edu/pub/homeier/papers/eclips.pdf. [Jac99] P. Jackson. Introduction to expert systems. International computer science series. Addison-Wesley, 1999. isbn: 9780201876864. url: http://books.google.it/books?id=9rJQAAAAMAAJ. [Jai04] P. Jairath. Inter-object communication interface bridge. Patent Application. Ver. A1. US 2004/0237092 A1. 25 Nov. 2004. url: http://www.patentlens.net/patentlens/patent/US_2004_ 0237092_A1/en/. [Jess08a] JESS 7.1 on-line Manual. 2008. url: http://www.jessrules. com/jess/docs/71/. [Jon00] K. S. Jones. “R.H. Richens: Translation in the NUDE”. In: Early Years in Machine Translation. Memoirs and biographies of pioneers. A cura di W. J. Hutchins. Vol. 12. Studies in the History of the Language Sciences 97. Amsterdam: John Benjamins Publishing Company, 2000, pp. 263–278. isbn: 9789027245861. [KST82] D. Kahneman, P. Slovic e A. Tversky. Judgment under Uncertainty: Heuristics and Biases. Cambridge University Press, 1982. isbn: 9780521284141. url: http://books.google.it/books? id=\_0H8gwj4a1MC. [KDS90] G. Kiernan, C. De Maindreville e E. Simon. Making deductive database a practical technology : a step forward. Inglese. Research 203

BIBLIOGRAFIA Report RR-1153. Projet SABRE. INRIA, gen. 1990. url: http: //hal.inria.fr/inria-00075406. [LA90] S. D. Lee e B. P. Allen. ART-Ada: An Ada-Based Expert System Tool. Research Report. NASA, 1990. 12 pp. isrn: NASA-CR188930. [LY95] Y. H. Lee e S. I. Yoo. “A Rete-based Integration of Forward and Backward Chaining Inferences”. In: Proceedings of the 1995 IEEE International Symposium on Intelligent Controll. (27 Ago. 1995). Monterey, CA: IEEE, 1995, pp. 611–616. isbn: 2158-9860. doi: http://dx.doi.org/10.1109/ISIC.1995.525122. [MCE02] C. Mascolo, L. Capra e W. Emmerich. “Mobile computing middleware”. In: Advanced lectures on networking. A cura di E. Gregori, G. Anastasi e S. Basagni. New York, NY, USA: SpringerVerlag New York, Inc., 2002, pp. 20–58. isbn: 3-540-00165-4. url: http://dl.acm.org/citation.cfm?id=770420.770423. [MF77] J. McDermott e C. L. Forgy. “Production system conflict resolution strategies”. In: SIGART Bull. 63 (1977), pp. 37–37. issn: 0163-5719. doi: 10 . 1145 / 1045343 . 1045364. url: http : //doi.acm.org/10.1145/1045343.1045364. [McG00] P. McGuire. Pyparsing API references. API References. 200-. url: http://packages.python.org/pyparsing/. [McG07] P. McGuire. Getting Started with Pyparsing. O’Reilly Short Cuts. Sebastopol, CA: O’Reilly Media, 2007. isbn: 9780596514235.

204

BIBLIOGRAFIA [Men03] T. Menzier. “Guest Editor’s Introduction: 21st-Century AI: proud, not smug”. In: IEEE Intelligent System 18.3 (mar. 2003). Editoriale, pp. 18–24. issn: 1541-1672. doi: http://doi.ieeecomputersociety. org/10.1109/MIS.2003.1200723. url: http://menzies.us/ pdf/03aipride.pdf. [MAL06] P. Merrick, S. Allen e J. Lapp. XML remote procedure call (XMLRPC). Patent. US 7028312. 11 Apr. 2006. url: http://www. patentlens.net/patentlens/patent/US_7028312/en/. [Min74] M. Minsky. A Framework for Representing Knowledge. Rapp. tecn. Cambridge, MA, USA, 1974. url: http://hdl.handle. net/1721.1/6089. [Mir87a] D. P. Miranker. “TREAT: a better match algorithm for AI production systems”. In: Proceedings of the sixth National conference on Artificial intelligence - Volume 1. AAAI’87. Seattle, Washington: AAAI Press, 1987, pp. 42–47. isbn: 0-934613-42-7. url: http : / / www . aaai . org / Papers / AAAI / 1987 / AAAI87 008.pdf. [Mir87b] D. P. Miranker. TREAT: A Better Match Algorithm for AI Production Systems; Long Version. Rapp. tecn. Austin, TX, USA, 1987. url: http://www.cs.utexas.edu/ftp/AI-Lab/techreports/UT-AI-TR-87-58.pdf. [Mir91] D. P. Miranker. The University of Texas OPS5 Rule Engine Benchmark Programs and Data Generators. 1991. url: ftp :

205

BIBLIOGRAFIA //ftp.cs.utexas.edu/pub/ops5-benchmark-suite/ (visitato il 15/08/2012). [Nai99] D. Naiditch. “Selecting a programming language for your project”. In: Aerospace and Electronic Systems Magazine, IEEE 14 (9 set. 1999), pp. 11–14. issn: 0885-8985. doi: 10 . 1109 / 62 . 793447. [Orc04] B Orchard. FuzzyCLIPS Version 6.10d. User’s Guide. National Research Council Canada. 2004. [Pos43] E. Post. “Formal Reductions of the General Combinatorial Decision Problem”. In: American Journal of Mathematics 65.2 (1943), pp. 197–215. [PVS08] K. Prashant, S. Vaibhav e N. Shashi. Programming Languages: A Comparative Study. Rapp. tecn. Mag. 2008. [Pre00] L. Prechelt. “An Empirical Comparison of Seven Programming Languages”. In: Computer 33 (2000), pp. 23–29. issn: 0018-9162. doi: http : / / doi . ieeecomputersociety . org / 10 . 1109 / 2 . 876288. [Pyt12a] Python Frequently Asked Questions. Python Software Foundation. 2012. url: http://docs.python.org/faq/ (visitato il 26/09/2012). [RS88] C. V. Ramamoorthy e P. C. Sheu. “Object-Oriented Systems”. In: IEEE Expert: Intelligent Systems and Their Applications 3.3 (set. 1988), pp. 9–15. issn: 0885-9000. doi: 10.1109/64.21886. url: http://dx.doi.org/10.1109/64.21886. 206

BIBLIOGRAFIA [Ree00] G. Reese. “Distributed Application Architecture”. In: Database Programming with JDBC and Java. 2a ed. O’Reilly Media, 2000. Cap. 7, pp. 126–145. isbn: 978-1-56592-616-5. [Ric56] R. H. Richens. “Preprogramming for Mechanical Translation”. In: Mechanical Translation 3.1 (lug. 1956). A cura di Massachussets Institute of Technology, pp. 20–25. url: http://www.mtarchive.info/MT-1956-Richens.pdf. [Ril00a] G. Riley. Monkees and Bananas benchmark for CLIPS. 200-. url: http : / / sourceforge . net / apps / trac / clipsrules / browser/examples/map.clp (visitato il 15/08/2012). [Ril00b] G. Riley. Sudoku benchmark for CLIPS. 200-. url: http : / / sourceforge.net/apps/trac/clipsrules/browser/examples/ sudoku (visitato il 15/08/2012). [RN09] S. J. Russell e P. Norvig. Artificial Intelligence: a Modern Approach. A cura di Prentice Hall. 3a ed. 2 voll. Prentice Hall Series in Artificial Intelligence 1. 2009. 1132 pp. isbn: 0136042597, 9780136042594. [SC84] R. C. Schank e P. G. Childers. The Congitive Computer: on Language, Learning and Artificial Intelligence. New York: Pearson Addison-Wesley, 1984. 268 pp. isbn: 020106443X. [Sch+86] M. I. Schor, T. Daly, H. S. Lee e B. Tibbitts. “Advances in Rete Pattern Matching”. In: National Conference on Artificial Intelligence. 1986, pp. 225–232.

207

BIBLIOGRAFIA [SW11] R. Sedgewick e K. Wayne. Algorithms. 4a ed. Addison-Wesley Professional, 2011. 976 pp. isbn: 978-0-321-57351-3. [Sil88] W. Siler. FLOPS: A parallell-rule-firing fuzzy expert system shell. English. NASA Technical Documents. NASA. 1988. url: http: //archive.org/details/nasa_techdoc_19910073809. [Ste+83] M. Stefik, D. G. Bobrow, S. Mittal e L. Conway. “Knowledge programming in LOOPS. Report on an Experimental Course”. In: The AI Magazine 4.3 (1983), pp. 3–13. url: http://www. aaai.org/ojs/index.php/aimagazine/article/view/400/ 336. [Stu12a] D. Stutzbach. blist: an asymptotically faster list-like type for Python. 2012. url: http://stutzbachenterprises.com/blist/. [Stu12b] D. Stutzbach. Performance of the blist. 2012. url: http : / / stutz-bachenterprises.com/performance-blist. [Wik12a] Sudoku - Wikipedia, the free encyclopedia. Wikipedia Foundation, Inc. 2012. url: http://it.wikipedia.org/wiki/Sudoku (visitato il 26/09/2012). [CLB12] The Computer Language Benchmarks Game. 2012. url: http: //shootout.alioth.debian.org/ (visitato il 16/08/2012). [Jess08b] The Jess FAQ. Sandia National Laboratories. 2008. url: http: //www.jessrules.com/jess/FAQ.shtml. [Pyt12b] The Python Standard Library. Python Software Foundation. 2012. url: http://docs.python.org/library/ (visitato il 26/09/2012). 208

BIBLIOGRAFIA [Tsa+93] J. J. P. Tsai, S. J. H. Yang, N. Waheed e T. Moher. “Development of Expert System Shell”. In: N. G. Bourbakis. Knowledge Engineering Shells: Systems and Techniques. World Scientific, 1993. Cap. 5, pp. 123–152. [TK73] A. Tversky e D. Kahneman. “Availability: A Heuristic for Judging Frequency and Probability”. In: Cognitive Psychology 5.5 (2 1973). A cura di Inc. Academic Press, pp. 207–232. issn: 0010-0285. doi: 10.1016/0010-0285(73)90033-9. [Van99] K. Van Laerhoven. Project report for Industrial Applications of AI. Research Notes. Lancaster University, 1999. url: http : / / www . comp . lancs . ac . uk / ~kristof / research / notes / clipsvsjess/index.html. [Wan+93] H. Wang, J. Mylopoulos, A. Kushniruk, B. Kramer e M. Stanley. “KNOWBEL: New Tools for Expert System Development”. In: N. G. Bourbakis. Knowledge Engineering Shells: Systems and Techniques. World Scientific, 1993. Cap. 7, pp. 189–258. [Win00] D. Winer. XML-RPC Specification. Mag. 2000. url: http:// www.xmlrpc.com/spec. [Wik12b] XML-RPC - Wikipedia, the free encyclopedia. Implementations. Wikipedia Foundation, Inc. 2012. url: http://en.wikipedia. org/wiki/XML-RPC#Implementations (visitato il 26/09/2012). [Zei95] S. F. Zeigler. Comparing Development Costs of C and Ada. Rapp. tecn. Rational Software Corporation, mar. 1995.

209

Appendici
Artefatti per la valutazione del sistema
Problema dell’agricoltore, variante 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ( defrule regola1 ? indice_conf1 <( deftemplate inizia " Configurazione iniziale " ( slot config_iniziale ( default ACPL ) ) ) ( type SYMBOL ) ( deftemplate configurazione " Stato del gioco " ( slot agricoltore ( type STRING ) ( default " sulla - riva - vicina ") ) ( slot cavolo ( type STRING )

( default " sulla - riva - vicina ") ) ( slot pecora ( type STRING )

( default " sulla - riva - vicina ") ) ( slot lupo ( type STRING )

( default " sulla - riva - vicina ") ) )

210

APPENDICI
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 ( defrule regola3 ? indice_conf3 <=> ( printout t " Ritorna alla riva vicina " crlf ) ( retract ? indice_conf2 ) ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") ( cavolo ( pecora ( lupo " sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - vicina ") ) ) ) ( defrule regola2 ? indice_conf2 <( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - lontana ") => ( printout t " Trasborda la pecora " crlf ) ( retract ? indice_conf1 ) ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") ( cavolo ( pecora ( lupo " sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - vicina ") ) ) ) ( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - vicina ")

" sulla - riva - vicina ") " sulla - riva - vicina ") " sulla - riva - vicina ") )

" sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - vicina ") )

211

APPENDICI
48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 ( defrule regola5 ? indice_conf5 <( configurazione ( agricoltore " sulla - riva - lontana ") => ( printout t " Trasborda il cavolo " crlf ) ( retract ? indice_conf4 ) ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - lontana ") " sulla - riva - vicina ") ) ) ) ( defrule regola4 ? indice_conf4 <( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - vicina ") => ( printout t " Trasborda il lupo " crlf ) ( retract ? indice_conf3 ) ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") ( cavolo ( pecora ( lupo " sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - lontana ") ) ) ) ( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - vicina ")

" sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - vicina ") )

" sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - vicina ") )

212

APPENDICI
78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 ( defrule regola7 ? indice_conf7 <( configurazione ( agricoltore " sulla - riva - vicina ") => ( printout t " Riporta indietro la pecora " crlf ) ( retract ? indice_conf6 ) ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - vicina ") ) ) ) ( defrule regola6 ? indice_conf6 <( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - lontana ") => ( printout t " Riporta indietro la pecora " crlf ) ( retract ? indice_conf5 ) ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") ( cavolo ( pecora ( lupo " sulla - riva - vicina ") " sulla - riva - vicina ") " sulla - riva - lontana ") ) ) ) ( cavolo ( pecora ( lupo " sulla - riva - vicina ") " sulla - riva - lontana ") " sulla - riva - lontana ") )

" sulla - riva - lontana ") " sulla - riva - lontana ") " sulla - riva - vicina ") )

213

APPENDICI
108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 ( defrule regola9 ? indice_conf9 <( configurazione ( agricoltore " sulla - riva - lontana ") => ( printout t " Trasborda il lupo " crlf ) ( retract ? indice_conf8 ) ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - lontana ") ) ) ) ( defrule regola8 ? indice_conf8 <( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - vicina ") => ( printout t " Trasborda il cavolo " crlf ) ( retract ? indice_conf7 ) ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - lontana ") ) ) ) ( cavolo ( pecora ( lupo " sulla - riva - vicina ") " sulla - riva - vicina ") " sulla - riva - lontana ") )

" sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - vicina ") )

214

APPENDICI
138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 ( defrule c h i e d i _ c o n f i g u r a z i o n e _ i n i z i a l e ( declare ( salience 10000) ) => => ( printout t " Trasborda la pecora " crlf ) ( retract ? indice_conf10 ) ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - lontana ") " sulla - riva - lontana ") ) ) ) ( defrule regola10 ? indice_conf10 <( configurazione ( cavolo ( pecora ( lupo ( agricoltore " sulla - riva - vicina ") => ( printout t " Ritorna alla riva vicina " crlf ) ( retract ? indice_conf9 ) ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - lontana ") ) ) ) ( cavolo ( pecora ( lupo " sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - lontana ") )

" sulla - riva - lontana ") " sulla - riva - vicina ") " sulla - riva - lontana ") )

215

APPENDICI
168 169 170 171 172 ( printout t crlf " * * * * * * * * * * * * * * * * * * * * * * * * * * " crlf crlf " Inserisci la configurazione iniziale :" crlf crlf ) ( printout t "L ’ agricoltore e ’ sulla riva vicina ? ( S / N ) : ") ( bind ? agric ( read ) ) ( if ( eq ? agric S ) then ( bind ? temp_a A ) else ( bind ? temp_a _ ) ) 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 => ( retract ? indice ? ind ) ( assert ( config esatta ) ) ( if ( eq ? conf_iniz ACPL ) ; controllo definizione di input ( defrule controlla_input ( declare ( salience 9000) ) ? indice <- ( inizia ( config_iniziale ? conf_iniz ) ) ( stato ? conf_iniz ) ? ind <- ( config inesatta ) ( printout t " Il cavolo e ’ sulla riva vicina ? ( bind ? cav ( read ) ) ( if ( eq ? cav S ) then ( bind ? temp_c C ) else ( bind ? temp_c _ ) ) ( printout t " La pecora e ’ sulla riva vicina ? ( bind ? pec ( read ) ) ( if ( eq ? pec S ) then ( bind ? temp_p P ) else ( bind ? temp_p _ ) ) ( printout t " Il lupo e ’ sulla riva vicina ? ( bind ? lup ( read ) ) ( if ( eq ? lup S ) then ( bind ? temp_l L ) else ( bind ? temp_l _ ) ) ( bind ? config ( sym - cat ? temp_a ? temp_c ? temp_p ? temp_l ) ) ( assert ( inizia ( config_iniziale ? config ) ) ) ( assert ( config inesatta ) ) ( printout t crlf crlf ) ) ( S / N ) : ") ( S / N ) : ") ( S / N ) : ")

216

APPENDICI
197 198 199 then ( assert ( configurazione ) ) else ( if ( eq ? conf_iniz ____ ) then ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") 200 201 202 203 204 ( cavolo " sulla - riva - lontana ") ( pecora " sulla - riva - lontana ") ( lupo " sulla - riva - lontana ") ) ) ) else ( if ( eq ? conf_iniz A_P_ ) then ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") 205 206 207 208 209 ( cavolo " sulla - riva - lontana ") ( pecora " sulla - riva - vicina ") ( lupo " sulla - riva - lontana ") ) ) ) else ( if ( eq ? conf_iniz _C_L ) then ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") 210 211 212 213 214 ( cavolo " sulla - riva - vicina ") ( pecora " sulla - riva - lontana ") ( lupo " sulla - riva - vicina ") ) ) ) else ( if ( eq ? conf_iniz A_PL ) then ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") 215 216 217 218 219 ( cavolo " sulla - riva - lontana ") ( pecora " sulla - riva - vicina ") ( lupo " sulla - riva - vicina ") ) ) ) else ( if ( eq ? conf_iniz _C__ ) then ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") 220 221 ( cavolo " sulla - riva - vicina ") ( pecora " sulla - riva - lontana ")

217

APPENDICI
222 223 224 ( lupo " sulla - riva - lontana ") ) ) ) else ( if ( eq ? conf_iniz AC_L ) then ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") 225 226 227 228 229 ( cavolo " sulla - riva - vicina ") ( pecora " sulla - riva - lontana ") ( lupo " sulla - riva - vicina ") ) ) ) else ( if ( eq ? conf_iniz ___L ) then ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") 230 231 232 233 234 ( cavolo " sulla - riva - lontana ") ( pecora " sulla - riva - lontana ") ( lupo " sulla - riva - vicina ") ) ) ) else ( if ( eq ? conf_iniz ACP_ ) then ( assert ( configurazione ( agricoltore " sulla - riva - vicina ") 235 236 237 238 239 ( cavolo " sulla - riva - vicina ") ( pecora " sulla - riva - vicina ") ( lupo " sulla - riva - lontana ") ) ) ) else ( if ( eq ? conf_iniz __P_ ) then ( assert ( configurazione ( agricoltore " sulla - riva - lontana ") 240 241 242 243 244 245 246 247 ) ( printout t " Le mosse dell ’ agricoltore sono : " crlf crlf ) ) ( cavolo " sulla - riva - lontana ") ( pecora " sulla - riva - vicina ") ( lupo " sulla - riva - lontana ") ) ) )

218

APPENDICI
248 ( defrule ritenta " Se la configurazione data in input e ’ errata " 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 ( deffacts stati_legali ( stato ( stato ( stato ACPL ) ____ ) A_P_ ) " Stati validi nel gioco " ( defrule continua_gioco "L ’ utente vuole giocare ancora ?" ( declare ( salience -10000) ) ? indice <- ( config esatta ) => ( retract ? indice ) ( printout t crlf crlf crlf " Vuoi giocare ancora ? ( S / N ) : ") ( bind ? risposta ( read ) ) ( if ( eq ? risposta S ) then ( reset ) else ( printout t crlf " * * * * * * * * * * * * * * * * * * " crlf crlf ) ) ) ( declare ( salience 8500) ) ? indice <- ( config inesatta ) => ( retract ? indice ) ( printout t crlf " La configurazione iniziale data in input risulta illegale !!!" crlf crlf crlf ) ( printout t " Vuoi riprovare ? ( S / N ) : ") ( bind ? risposta ( read ) ) ( if ( eq ? risposta S ) then ( reset ) else ( printout t crlf crlf "**************" crlf crlf ) ) )

219

APPENDICI
277 278 279 280 281 282 283 ( stato ( stato ( stato ( stato ( stato ( stato ( stato _C_L ) A_PL ) _C__ ) AC_L ) ___L ) ACP_ ) __P_ ) )

Codice A.1: Problema dell’agricoltore: variante 1

Problema dell’agricoltore, variante 2
1 2 3 4 5 6 7 8 9 10 11 12 13 ( defrule torna - agricoltore - solo " Sposta l ’ agricoltore dalla sponda lontana a quella vicina " 14 15 16 17 ? agricoltore <- ( su - riva agricoltore lontana ) ( not ( and ( su - riva pecora lontana ) ( su - riva cavolo lontana ) ) => ( printout t " Hai raggiunto il goal !!!" crlf ) ( retract ? f1 ? f2 ? f3 ? f4 ) ( defrule mostra - goal " Mostra il goal " ( declare ( salience 1000) ) ? f1 <- ( su - riva agricoltore lontana ) ? f2 <- ( su - riva pecora lontana ) ? f3 <- ( su - riva lupo lontana ) ? f4 <- ( su - riva cavolo lontana )

220

APPENDICI
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ( defrule torna - agricoltore - con - pecora - se - lupo - lontano " Sposta l ’ agricoltore e la pecora dalla sponda lontana a quella vicina se il lupo e ’ lontano " 34 35 36 37 38 39 40 41 42 43 44 45 ) => ( printout t " Sposto agricoltore e pecora vicino " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore vicina ) ) ( retract ? pecora ) ( assert ( su - riva pecora vicina ) ) ? agricoltore <- ( su - riva agricoltore lontana ) ? pecora <- ( su - riva pecora lontana ) ( su - riva lupo lontana ) ( su - riva ? vicina ) ) => ( printout t " Sposto agricoltore vicino " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore vicina ) ) ) ) ) ( not ( and ( su - riva lupo lontana ) ( su - riva pecora lontana ) ( su - riva cavolo vicina ) ) ( su - riva lupo vicina )

221

APPENDICI
46 47 48 ( defrule torna - agricoltore - con - pecora - se - cavolo - lontano " Sposta l ’ agricoltore e la pecora dalla sponda lontana a quella vicina se il cavolo e ’ lontano " 49 50 51 52 53 54 55 56 57 58 59 60 61 ( defrule manda - pecora - iniziale " Sposta la pecora e l ’ agricoltore dalla sponda vicina a quella lontana ( lasciando lupo e cavolo sulla sponda vicina ) " 62 63 64 65 66 67 68 69 70 71 => ( printout t " Sposto agricoltore e pecora lontano " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore lontana ) ) ( retract ? pecora ) ( assert ( su - riva pecora lontana ) ) ? agricoltore <- ( su - riva agricoltore vicina ) ? pecora <- ( su - riva pecora vicina ) ( su - riva lupo vicina ) ( su - riva cavolo vicina ) ) => ( printout t " Sposto agricoltore e pecora vicino " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore vicina ) ) ( retract ? pecora ) ( assert ( su - riva pecora vicina ) ) ? agricoltore <- ( su - riva agricoltore lontana ) ? pecora <- ( su - riva pecora lontana ) ( su - riva cavolo lontana ) ( su - riva ? vicina )

222

APPENDICI
72 73 74 75 ( defrule manda - lupo " Sposta l ’ agricoltore ed il lupo dalla sponda vicina a quella lontana " 76 77 78 79 80 81 82 83 84 85 86 87 88 ( defrule manda - cavolo " Sposta l ’ agricoltore ed il cavolo dalla sponda vicina a quella lontana " 89 90 91 92 93 94 95 96 97 98 99 ) => ( printout t " Sposto agricoltore e cavolo lontano " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore lontana ) ) ( retract ? cavolo ) ( assert ( su - riva cavolo lontana ) ) ? agricoltore <- ( su - riva agricoltore vicina ) ? cavolo <- ( su - riva cavolo vicina ) ( su - riva lupo lontana ) ) => ( printout t " Sposto agricoltore e lupo lontano " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore lontana ) ) ( retract ? lupo ) ( assert ( su - riva lupo lontana ) ) ? agricoltore <- ( su - riva agricoltore vicina ) ? lupo <- ( su - riva lupo vicina ) ( su - riva pecora lontana ) ( su - riva cavolo vicina ) )

223

APPENDICI
100 101 ( defrule manda - pecora - finale " Sposta l ’ agricoltore e la pecora sulla sponda lontana ( se lupo e cavolo sono sull ’ altra sponda ) " 102 103 104 105 106 107 108 109 110 111 112 113 114 ( defrule manda - agricoltore - solo " Sposta SOLO l ’ agricoltore dalla sponda distante a quella vicina " 115 116 117 118 119 120 121 122 123 124 125 126 ( defrule acquisizione " Acquisisce lo stato da tastiera " ( declare ( salience 1000) ) ? modalita <- ( modalita iniziale ) ) => ( printout t " Sposto agricoltore lontano " crlf ) ( retract ? agricoltore ) ( assert ( su - riva agricoltore lontana ) ) ? agricoltore <- ( su - riva agricoltore vicina ) ( not ( su - riva ~ agricoltore vicina ) ) ) => ( printout t " Sposto agricoltore e pecora lontano " crlf ) ( retract ? agricoltore ) ( retract ? pecora ) ( assert ( su - riva agricoltore lontana ) ) ( assert ( su - riva pecora lontana ) ) ? agricoltore <- ( su - riva agricoltore vicina ) ? pecora <- ( su - riva pecora vicina ) ( su - riva ? op1 lontana ) ( su - riva ~? op1 lontana )

224

APPENDICI
127 128 129 130 131 132 133 134 135 ( defrule acquisizione - elemento " Acquisisce l ’ elemento fino a quando il valore immesso non sara ’ corretto " 136 137 138 139 140 => ( printout t " Indica la posizione di " ? elemento ": ( vicina / lontana ) " crlf ) 141 142 143 144 145 146 147 ( defrule controllo - elemento - acquisito " Se un elemento acquisito e ’ invalido , prepara la riacquisizione " 148 149 150 151 152 => ( printout t " Il valore immesso non e ’ valido : " ? posizione crlf ) ( declare ( salience 901) ) ? assposizione <- ( su - riva ? elemento ? posizione ) ( test ( neq ? posizione lontana vicina ) ) ) ( bind ? risposta ( read ) ) ( assert ( su - riva ? elemento ? risposta ) ) ( retract ? serve ) ( declare ( salience 900) ) ? serve <- ( serve - acquisizione ? elemento ) ( not ( su - riva ? elemento ?) ) ) => ( printout t " - - - Gioco dell ’ agricoltore - - -" crlf ) ( printout t " Immetti lo stato iniziale per cortesia " crlf ) ( retract ? modalita ) ( not ( su - riva ? ?) )

225

APPENDICI
153 154 155 156 157 ( defrule condizione - errata - stato - pecora - mangia - cavolo " Controlla lo stato in cui la pecora mangia il cavolo e resetta il gioco " 158 159 160 161 162 163 164 => ( printout t " Complimenti ... la pecora ha mangiato il cavolo .... ( sono ironico ) " crlf ) 165 166 167 168 169 170 ( defrule condizione - errata - stato - lupo - mangia - pecora " Controlla lo stato in cui la pecora mangia il cavolo e resetta il gioco " 171 172 173 174 175 176 => ( declare ( salience 800) ) ( su - riva pecora ? riva ) ( su - riva lupo ? riva ) ( su - riva agricoltore ~? riva ) ( su - riva cavolo ~? riva ) ) ( printout t " Ricominciamo ..." crlf crlf ) ( assert ( modalita reset ) ) ( declare ( salience 800) ) ( su - riva pecora ? riva1 ) ( su - riva cavolo ? riva1 ) ( su - riva agricoltore ~? riva1 ) ( su - riva lupo ~? riva1 ) ) ( retract ? assposizione ) ( assert ( serve - acquisizione ? elemento ) )

226

APPENDICI
177 ( printout t " Complimenti ... il lupo ha mangiato la pecora .... ( sono ironico ) " crlf ) 178 179 180 181 182 183 ( defrule modalita - reset - pulizia - su - riva " Rimuove tutti gli elementi su - riva durante la modalita ’ reset " 184 185 186 187 188 189 190 191 192 ( defrule modalita - reset - pulizia - acquisizione " Rimuove tutti gli elementi serve - acquisizione durante la modalita ’ reset " 193 194 195 196 197 198 199 200 201 202 ( defrule termina - modalita - reset " Resetta lo stato iniziale " ( declare ( salience 1001) ) ? modalita <- ( modalita reset ) ) => ( retract ? acquisizione ) ( declare ( salience 1002) ) ( modalita reset ) ? acquisizione <- ( serve - acquisizione ?) ) => ( retract ? suriva ) ( declare ( salience 1002) ) ( modalita reset ) ? suriva <- ( su - riva ? ?) ) ( printout t " Ricominciamo ..." crlf crlf ) ( assert ( modalita reset ) )

227

APPENDICI
203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 ) ( deffacts stato - iniziale " Stato iniziale " ( serve - acquisizione agricoltore ) ( serve - acquisizione lupo ) ( serve - acquisizione cavolo ) ( serve - acquisizione pecora ) ( modalita iniziale ) ) ) => ( retract ? modalita ) ( assert ( serve - acquisizione agricoltore ) ( serve - acquisizione lupo ) ( serve - acquisizione cavolo ) ( serve - acquisizione pecora ) ( modalita iniziale ) ( not ( su - riva ? ?) ) ( not ( serve - acquisizione ?) )

Codice A.2: Problema dell’agricoltore: variante 2

Sistema per la diagnosi medica
1 2 3 4 5 ( deffunction Domanda (? testo ? spiegazione $ ? valori_ammessi ) ( format t ? testo ) ( if ( neq ? spiegazione "") then ( format t "(% s perche ) " ( implode$ $ ? valori_ammessi ) ) else ( format t "(% s ) " ( implode$ $ ? valori_ammessi ) ) )

228

APPENDICI
6 7 8 ( format t "? ") ( bind ? risposta ( read ) ) ( if ( lexemep ? risposta ) si e ’ inserita una stringa 9 then ( bind ? risposta ( lowcase ? risposta ) ) ) converte in lettere minuscole 10 11 12 13 14 15 ( if ( eq ? risposta perche ) then ( format t ( str - cat "% n " ? spiegazione "% n ") ) ) ( while ( not ( member$ ? risposta $ ? valori_ammessi ) ) do ( format t ? testo ) ( if ( neq ? spiegazione "") then ( format t "(% s perche ) " ( implode$ $ ? valori_ammessi )) 16 17 18 19 20 21 else ( format t "(% s ) " ( implode$ $ ? valori_ammessi ) ) ) ( format t "? ") ( bind ? risposta ( read ) ) ( if ( lexemep ? risposta ) then ( bind ? risposta ( lowcase ? risposta ) ) ) ) ? risposta Valore restituito dalla funzione Domanda 22 23 24 25 26 27 28 29 30 31 ( defrule Presentazione ( declare ( salience 100) ) ) ( deffunction Spiega (? testo ) ( bind ?* spiegazione * ( str - cat ?* spiegazione * ? testo ) ) ( defglobal ?* spiegazione * = "") ) ; ; ; Se

229

APPENDICI
32 33 34 => ( printout t crlf crlf ) ( printout t " " crlf ) 35 ( printout t " Sistema Esperto per la diagnosi di malattie " crlf ) 36 ( printout t " hardware di un Personal Computer " crlf crlf ) 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 ( defrule V i s u a l i z z a _ s p i e g a z i o n e ( declare ( salience -2000) ) => ( bind ? risposta ( Domanda "% n % nVuoi sapere come sono arrivato a questa malattia ?% n " "" si no ) ) 53 54 55 56 57 ) ) ( if ( eq ? risposta si ) then ( format t ?* spiegazione *) ( printout t crlf ) ) ( defrule V i s ua l i zz a _ Ma l a tt i a ( diagnosi ? malattia ) => ( format t "% n % n % n % nLa malattia e ’:% s " ? malattia ) ) ITTERO

230

APPENDICI
58 59 60 61 62 63 64 65 66 ( defrule S i n dr o m e_ d i _G i l be r t ( sintomo ittero_sclerale si ) ( sintomo febbre no ) ( or ( sintomo stress si ) ( sintomo digiuno si ) ) => ( assert ( diagnosi " Sindrome di Gilbert ") ) ( Spiega "L ’ ittero sclerale e l ’ assenza di febbre fanno pensare che si tratti di Sindrome di Gilbert ") 67 68 69 70 71 72 73 74 ( defrule Domanda_Febbre ( declare ( salience -100) ) ( not ( sintomo febbre ?) ) => ( bind ? risposta ( Domanda " Il paziente ha febbre ?" "" si no ) ) 75 76 77 78 79 80 81 82 83 84 85 ( defrule E p a t i t e _ A c u t a _ V i r a l e ( sintomo ittero_franco si ) ( sintomo febbre si ) ( paziente giovane si ) ( sintomo stanchezza si ) ( sintomo dispepsia si ) ( sintomo aumento_fegato si ) ) ( assert ( sintomo febbre ? risposta ) ) )

231

APPENDICI
86 87 88 => ( assert ( diagnosi " Ep a t i t e _ A c u t a _ V i r a l e ") ) ( Spiega "L ’ ittero franco , la febbre , la stanchezza , la dispepsia , l ’ aumento delle dimensioni fegato e la giovane eta ’ del paziente fanno pensare che si tratti di Epatite acuta virale ") 89 90 91 92 93 94 95 96 97 98 99 ( defrule Colecistite ( sintomo ittero_franco si ) ( sintomo febbre si ) ( paziente giovane no ) ( sintomo dolor i_rico rrenti si ) ( sintomo dolore_coleciste si ) => ( assert ( diagnosi " Colecistite ") ) ( Spiega "L ’ ittero franco , la febbre , i dolori ricorrenti e quelli della coleciste , insieme alla eta ’ media - avanzata del paziente fanno pensare che si tratti di Sindrome di Colecistite ") 100 101 102 103 104 105 106 107 108 109 ( defrule Cirrosi_Alcolica ( sintomo ittero_franco si ) ( sintomo febbre no ) ( paziente giovane no ) ( uso alcool si ) ( sintomo aumento_fegato si ) ( sintomo aumento_milza si ) ) )

232

APPENDICI
110 111 112 => ( assert ( diagnosi " Cirrosi Alcolica ") ) ( Spiega "L ’ ittero franco , l ’ assenza di febbre , l ’ uso di alcool , l ’ eta ’ giovane del paziente , l ’ aumento di dimensioni del fegato e della milza fanno pensare che si tratti di Cirrosi Alcolica ") 113 114 115 116 117 118 119 120 121 ( defrule Ignota ( declare ( salience -1000) ) ( not ( diagnosi ?) ) => ( assert ( diagnosi " Malattia ignota ") ) ( Spiega " Non ci sono abbastanza elementi per effetuare una diagnosi ") ) 122 123 124 125 126 127 128 129 ( defrule S i n t o m o _ I t t e r o _ F r a n c o ( occhi_gialli si ) ( colorito_giallo si ) => ( assert ( sintomo ittero_franco si ) ) ( Spiega " Gli occhi gialli ed il colorito giallo indicano ittero franco ") ) 130 131 132 133 134 ( defrule S i n t o m o _ I t t e r o _ S c l e r a l e ( occhi_gialli si ) ( colorito_giallo no ) )

233

APPENDICI
135 136 137 => ( assert ( sintomo ittero_sclerale si ) ) ( Spiega " Gli occhi gialli ed il colorito normale indicano ittero franco ") ) 138 139 140 141 142 143 144 145 146 ( defrule D o m a n d a _ O c c h i _ G i a l l i ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( occhi_gialli ?) ) => ( bind ? risposta ( Domanda " Il paziente ha gli occhi gialli ?" " Serve per verificare la presenza di ittero " si no ) ) 147 148 149 150 151 152 153 154 155 ( defrule D o m a n d a _ C o l o r i t o _ G i a l l o ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( colorito_giallo ?) ) => ( bind ? risposta ( Domanda " Il paziente ha il colorito giallo ?" " Serve per distinguere l ’ ittero sclerale da quello franco " si no ) ) 156 157 158 159 160 ( defrule D o m a n d a _ S i n t o m o _ S t r e s s ( declare ( salience -100) ) ) ( assert ( colorito_giallo ? risposta ) ) ) ( assert ( occhi_gialli ? risposta ) )

234

APPENDICI
161 162 163 164 ( not ( diagnosi ?) ) ( not ( sintomo stress ?) ) => ( bind ? risposta ( Domanda " Il paziente e ’ stressato ?" " La presenza di stress o digiuno fa propendere per la Sindrome di Gilbert " si no ) ) 165 166 167 168 169 170 171 172 173 ( defrule D o m a n d a _ S i n t o m o _ D i g i u n o ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo digiuno ?) ) => ( bind ? risposta ( Domanda " Il paziente digiuna ?" " La presenza di stress o digiuno fa propendere per la Sindrome di Gilbert " si no ) ) 174 175 176 177 178 179 180 181 182 ( defrule D o m a n d a _ P a z i e n t e _ G i o v a n e ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( paziente giovane ?) ) => ( bind ? risposta ( Domanda " Il paziente e ’ giovane ?" "" si no )) 183 184 185 ) ( assert ( paziente giovane ? risposta ) ) ) ( assert ( sintomo digiuno ? risposta ) ) ) ( assert ( sintomo stress ? risposta ) )

235

APPENDICI
186 187 188 189 190 191 ( defrule D o m a n d a _ S i n t o m o _ S t a n c h e z z a ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo stanchezza ?) ) => ( bind ? risposta ( Domanda " Il paziente e ’ stanco ?" "E ’ indice di epatite acuta virale " si no ) ) 192 193 194 195 196 197 198 199 200 ( defrule D o m a n d a _ S i n t o m o _ D i s p e p s i a ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo dispepsia ?) ) => ( bind ? risposta ( Domanda " Il paziente ha dispepsia ?" " Potrebbe essere indice di epatite acuta virale " si no ) ) 201 202 203 204 205 206 207 208 209 ( defrule D o m a n d a _ S i n t o m o _ A u m e n t o _ F e g a t o ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo aumento_fegato ?) ) => ( bind ? risposta ( Domanda " Il paziente ha aumento del fegato ?" " Aiuta a distinguere epatite e cirrosi da altre malattie " si no ) ) 210 211 ) ( assert ( sintomo aumento_fegato ? risposta ) ) ) ( assert ( sintomo dispepsia ? risposta ) ) ) ( assert ( sintomo stanchezza ? risposta ) )

236

APPENDICI
212 213 214 215 216 217 218 ( defrule D o m a n d a _ S i n t o m o _ D o l o r i _ R i c o r r e n t i ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo dolor i_rico rrenti ?) ) => ( bind ? risposta ( Domanda " Il paziente ha dolori ricorrenti ?" " Potrebbe servire per confermare la colecistite " si no ) ) 219 220 221 222 223 224 225 226 227 ( defrule D o m a n d a _ S i n t o m o _ D o l o r e _ C o l e c i s t e ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo dolore_coleciste ?) ) => ( bind ? risposta ( Domanda " Il paziente ha dolore coleciste ?" " Conforme la colecistite " si no ) ) 228 229 230 231 232 233 234 235 236 237 ( defrule D oma nd a_ Us o_ Al co ol ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( uso alcool ?) ) => ( bind ? risposta ( Domanda " Il paziente fa uso di alcool ?" " Farebbe pensare alla cirrosi " si no ) ) ) ( assert ( sintomo dolore_coleciste ? risposta ) ) ) ( assert ( sintomo dolor i_rico rrenti ? risposta ) )

237

APPENDICI
238 239 240 241 242 243 244 245 246 ( defrule D o m a n d a _ A u m e n t o _ M i l z a ( declare ( salience -100) ) ( not ( diagnosi ?) ) ( not ( sintomo aumento_milza ?) ) => ( bind ? risposta ( Domanda " Il paziente ha aumento milza ?" "E ’ un sintomo tipico di cirrosi " si no ) ) 247 248 ) ( assert ( sintomo aumento_milza ? risposta ) ) ) ( assert ( uso alcool ? risposta ) )

Codice A.3: Sistema per la diagnosi medica

238

APPENDICI

Specifica BNF del linguaggio accettato
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 < expression > ::= < constant > | < variable > < function - call > ::= ( < function - name > < expression >*) < variable > ::= < single - field - variable > | < multifield - variable > | < global - variable > < global - variable > ::= ?* < symbol >* < multifield - variable > ::= $ ? < variable - symbol > < single - field - variable > ::= ? < variable - symbol > <... - name > ::= < symbol > < variable - symbol > ::= < symbol > < comment > ::= < string > < constant > ::= < number > | < lexeme > < lexeme > ::= < symbol > | < string > ;;;;;; ; Tipi di base < number > ::= < float > | < integer >

239

APPENDICI
29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 < single - field - RHS - slot > ::= ( < slot - name > <RHS - field >) <RHS - slot > ::= < single - field - RHS - slot > | < multifield - RHS - slot > < template - RHS - pattern > ::= ( < deftemplate - name > <RHS - slot >*) < ordered - RHS - pattern > ::= ( < symbol > <RHS - field >+) <RHS - pattern > ::= < ordered - RHS - pattern > | < template - RHS - pattern > ) ;;;;;; ; Costrutto DefFacts < deffacts - construct > ::= ( deffacts [ < module - name >::] < deffacts - name > [ < comment >] <RHS - pattern >* < construct > ::= < deffacts - construct > | < defrule - construct > | < defmodule - construct > | < defglobal - construct > | < deffunction - construct > | < deftemplate - construct > < PROGRAM > ::= < construct >* | < function - call >

240

APPENDICI
59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 ;;;;;; ; Costrutto DefModule < defmodule > ::= ( defmodule < module - name > [ comment ] < port - spec >*) 82 83 84 85 86 87 < port - item > ::= ? ALL | ? NONE < port - spec > ::= ( export < port - item >) | ( import < module - name > < port - item >) < wildcard - param > ::= < multi - field - variable > < regular - param > ::= < single - field - variable > ) ;;;;;; ; Costrutto DefFunction < deffunction - construct > ::= ( deffunction [ < module - name >::] < name > [ < comment >] ( < regular - param >* [ < wildcard - param >]) < action >* <RHS - field > ::= < variable > | < constant > | < function - call > < multifield - RHS - slot > ::= ( < slot - name > <RHS - field >*)

241

APPENDICI
88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 < conditional - element > ::= < pattern - CE > | < assigned - pattern - CE > | <not - CE > | <and - CE > < boolean - symbol > ::= TRUE | FALSE < rule - property > ::= ( salience < integer - expression >) | ( auto - focus < boolean - symbol >) < declaration > ::= ( declare < rule - property >+) ) ;;;;;; ; Costrutto DefRule < defrule - construct > ::= ( defrule [ < module - name >::] < rule - name > [ < comment >] [ < declaration >] < conditional - element >* => < action >* < port - construct > ::= deftemplate | defglobal | deffunction | < port - construct > ? ALL | < port - construct > ? NONE | < port - construct > < construct - name >+

242

APPENDICI
118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 < assigned - pattern - CE > ::= < single - field - variable > <- < pattern - CE > 133 134 135 136 137 138 139 140 141 142 143 144 145 146 < multifield - LHS - slot > ::= ( < slot - name > < constraint >*) < single - field - LHS - slot > ::= ( < slot - name > < constraint >) <LHS - slot > ::= < single - field - LHS - slot > | < multifield - LHS - slot > < template - pattern - CE > ::= ( < deftemplate - name > <LHS - slot >*) < ordered - pattern - CE > ::= ( < symbol > < constraint >*) < pattern - CE > ::= < ordered - pattern - CE > | < template - pattern - CE > < exists - CE > ::= ( exists < conditional - element >+) <or - CE > ::= ( or < conditional - element >+) <and - CE > ::= ( and < conditional - element >+) <not - CE > ::= ( not < conditional - element >) < test - CE > ::= ( test < function - call >) | <or - CE > | < test - CE > | < exists - CE >

243

APPENDICI
147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 < single - slot - def > ::= ( slot < slot - name > < template - attribute >*) < slot - definition > ::= < single - slot - def > | < multi - slot - def > ) ;;;;;; ; Costrutto DefTemplate < deftemplate - construct > ::= ( deftemplate [ < module - name >::] < deftemplate - name > [ < comment >] < slot - definition >* < term > ::= < constant > | < single - field - variable > | < multi - field - variable > | = < function - call > < single - constraint > ::= < term > | ~ < term > < connected - constraint > ::= < single - constraint > | < single - constraint > & < connected - constraint > | < single - constraint > | < connected - constraint > < constraint > ::= ? | $ ? | < connected - constraint >

244

APPENDICI
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 < global - assignment > ::= < global - variabl > = < expression > ) ;;;;;; ; Costrutto DefGlobal < defglobal - construct > ::= ( defglobal [ < module - name >] < global - assignment >* < type - spec > ::= SYMBOL | STRING | LEXEME | INTEGER | FLOAT | NUMBER | FACT - ADDRESS < contraint - attr > ::= ( type < type - spec >) < default - attribute > ::= ( default ? DERIVE | ? NONE | < expression >* ) < template - attribute > ::= < default - attribute > | < constraint - attribute > < multi - slot - def > ::= ( multislot < slot - name > < template - attribute >*)

Codice A.4: Specifica BNF del linguaggio accettato

245

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->