Kappa PC
16/3/99
Marco Meluccio
1
Introduzione
Il sistema di sviluppo Kappa-PC permette di scrivere
applicazioni in un ambiente grafico di alto livello.
I componenti di base del sistema sono rappresentati da
strutture chiamate oggetti: questi possono essere o classi o
istanze. Le relazioni tra gli oggetti in un modello possono
essere rappresentate dai collegamenti in una struttura
chiamata gerarchia.
Usando gli strumenti della programmazione ad oggetti si
possono definire metodi e caratteristiche di un oggetto.
Usando le regole si può poi definire come questi oggetti si
comportano.
16/3/99
Marco Meluccio
2
Esempio di gerarchia
16/3/99
Marco Meluccio
3
Programmazione orientata agli oggetti
Gli oggetti in Kappa PC sono definiti o come classi o come
istanze: le prime rappresentano oggetti più generali, mentre
le seconde oggetti più specifici.
Ogni oggetto possiede un certo numero di slot: ognuno di
questi descrive una caratteristica dell’oggetto in esame. Per
specificare la caratteristica, si assegna un valore allo slot.
Ogni azione che un oggetto può eseguire è rappresentata da
un metodo. Il processo di attivazione di un metodo è
chiamato sending a message. Quando un oggetto riceve un
messaggio che corrisponde ad uno dei suoi metodi, quel
metodo è attivato.
16/3/99
Marco Meluccio
4
Programmazione orientata agli oggetti
L’oggetto esegue qualunque procedura sia specificata nel
metodo attivato dal messaggio.
La programmazione orientata agli oggetti ha due
caratteristiche che la rendono particolarmente adatta allo
sviluppo di applicazioni:
 gli oggetti ereditano allo stesso modo metodi e slot;
 oggetti diversi possono rispondere allo stesso messaggio
con metodi diversi: questo significa che le differenze
procedurali sono nascoste.
Altri benefici della programmazione ad oggetti sono una
rappresentazione normale, la modularità e la possibilità di
riutilizzo (riusability).
16/3/99
Marco Meluccio
5
Metodi
Per creare i metodi ci sono due vie possibili:
 con l’interprete del linguaggio KAL utilizzare funzioni
come MakeMethod e RenameMethod;
 usare l’editor dei metodi (si clicca su edit tools, su classi o
istanze, su edit, sulla classe a cui si vuole aggiungere il
metodo, si sceglie new nel menù metodi)
Un metodo può essere una qualunque funzione KAL o una
sequenza di funzioni. Ci sono tre argomenti di default: Self,
TheParent, TheOwner. Il valore della variabile Self è
l’oggetto che riceve il messaggio, TheParent la classe da
cui è derivato l’oggetto, TheOwner la classe in cui è
definito il metodo.
16/3/99
Marco Meluccio
6
Class editor
16/3/99
Marco Meluccio
7
Metodi
I metodi eseguono diversi tipi di azioni:
 cambiano
lo stato dell’applicazione, generalmente
cambiando i valori degli slot in un oggetto;
 mandano messaggi o allo stesso oggetto o ad altri oggetti;
mandare messaggi permette agli oggetti di cooperare tra
loro per produrre risultati globali: un modo di pensare ad
un programma orientato agli oggetti è una collezione di
semplici computer (esempio nel linguaggio KAL:
SendMessage(MarysCar, INIT) attiva il metodo INIT);
 attivano altre attrezzature del sistema Kappa PC, come il
ragionamento basato sulle regole o come l’accesso a dati.
16/3/99
Marco Meluccio
8
Ereditarietà
L’ereditarietà dei metodi è simile all’ereditarietà dei valori
degli slot; come per questi ultimi infatti i metodi possono
essere:
 ereditati (se un oggetto contiene un metodo, tutti gli oggetti
derivati, che non contengono un metodo con lo stesso
nome, ereditano il metodo non cambiato);
 resi locali (un metodo può essere ridefinito in una classe:
tutti gli oggetti a livelli più bassi nella gerarchia
erediteranno il nuovo metodo; per rendere locale un
metodo bisogna scegliere dal menu Methods l’opzione
MakeLocal nell’editor di classi o istanze e poi editare il
metodo; l’asterisco indica un metodo ereditato).
16/3/99
Marco Meluccio
9
Monitor
Monitor: metodi che sono legati agli slot e che sono attivati o
dai cambiamenti nel valore dello slot o dalla richiesta di un
valore non noto. Ci sono quattro tipi di monitor:
 if needed (questo monitor è attivato se c’è bisogno di un
valore di uno slot, ma non è conosciuto);
 when accessed (è attivato quando si accede allo slot
indipendentemente dal fatto che ci sia o no il valore dello
slot);
 before change (è attivato prima che il valore dello slot sia
cambiato)
 after change (è attivato dopo che lo slot è cambiato).
16/3/99
Marco Meluccio
10
Gli slot
Gli slot servono per descrivere le caratteristiche di un oggetto.
Come succede per i metodi, possono essere ereditati o resi
locali introducendo nuovi valori.
Gli slot hanno una struttura interna composta di opzioni.
Kappa PC fornisce un insieme di opzioni standard per
controllare il tipo e il numero dei valori. Si può:
 specificare il numero di valori;
 controllare i tipi dei valori;
 descrivere un insieme di valori permessi;
 specificare altre istanze come valori.
16/3/99
Marco Meluccio
11
Gli slot: ereditarietà
Una volta che un slot è reso locale e ne viene cambiato il
valore, tutte le classi e le istanze che ereditano lo slot
ottengono il nuovo valore: il risultato è una specie di
shadowing effect. E’ possibile anche cambiare il valore di
uno slot senza rendere quest’ultimo locale: in tal caso, il
nuovo valore viene cambiato nello slot e in quelli al di
sotto nella gerarchia, ma non cambia lo schema
dell’ereditarietà (le opzioni dello slot continuano ad essere
ereditate come prima).
Quando si crea la base di conoscenza, si deve trovare il giusto
posto per gli slot: questi devono essere messi più in alto
possibile nella gerarchia.
16/3/99
Marco Meluccio
12
Gli slot: base di conoscenza
La struttura della conoscenza tende ad evolvere con
l’aumento della conoscenza stessa: per esempio, se classi o
istanze con degli slot in comune non hanno un genitore in
comune, questo può essere un segnale che si potrebbe dare
a loro un genitore comune. Espandendo la base di
conoscenza, è possibile che sia necessario aggiungere delle
classi da qualche parte all’interno della gerarchia: questo
può provocare un movimento degli slot verso l’alto.
Per muovere degli oggetti all’interno della gerarchia, si
possono utilizzare le funzioni MoveInstance e
MoveHierarchy.
16/3/99
Marco Meluccio
13
Gli slot: opzioni
Usare le opzioni degli slot permette di fornire informazioni
più dettagliate sugli oggetti e quindi creare applicazioni più
accurate.
Le opzioni descrivono gli slot nello stesso modo in cui gli slot
descrivono le istanze. Una opzione è un contenitore, un
posto per mettere ulteriore informazione sullo slot.
Il Kappa PC fornisce automaticamente un insieme di opzioni
a ciascuno slot. Quest’ultimo può avere molte opzioni, ma
non avere un valore: in questo caso Kappa PC gli assegna
il valore NULL.
16/3/99
Marco Meluccio
14
Gli slot: opzioni
I tipi di opzioni degli slot sono:
 cardinalità;
 valori permessi;
 tipo di valore;
 ereditarietà dello slot;
 i monitor: if needed, when accessed, before change e after
change;
 linea di prompt.
16/3/99
Marco Meluccio
15
Slot editor
16/3/99
Marco Meluccio
16
Gli slot: monitor
I monitor sono metodi che sono attivati quando si accede alla
coppia oggetto:slot.
 if needed (questa opzione contiene il nome di un metodo
nell’oggetto. Il metodo è automaticamente eseguito quando
il valore dello slot è richiesto e non c’è un valore. Il
metodo prende il nome dello slot come argomento
opzionale e restituisce il valore da essere usato al posto di
NULL nell’espressione di KAL che si riferisce allo slot);
 when accessed (a differenza del monitor if needed viene
chiamato anche quando il valore dello slot è conosciuto);
 before change e after change (chiamati prima e dopo il
cambiamento del valore nello slot).
16/3/99
Marco Meluccio
17
Gli slot: tipi di valori
I tipi di valori possibili per uno slot sono i seguenti:
 text (tipo di default): i limiti di valori per questo tipo si
possono fissare nella campo allowable values;
 number (intero o floating point): è possibile definire un
massimo e un minimo;
 boolean (True o False);
 object (può essere il nome di una classe o di una istanza).
Con la linea di prompt è possibile specificare la domanda che
si vuole porre all’utente.
La cardinalità può essere singola o multipla.
16/3/99
Marco Meluccio
18
Il linguaggio KAL
Il KAL è un linguaggio simile nella sua sintassi al C e si
comporta come il Lisp. E’ un linguaggio interpretato che
può essere compilato nel C.
La sintassi del linguaggio KAL può essere divisa in sei tipi
principali:


16/3/99
gli atomi (una singola parola o un gruppo di parole tra virgolette; ad
esempio: MarysCar o “red white blue”);
gli slot pairs (nome di un oggetto, due punti, nome di uno slot; ad
esempio:
MarysCar:Color,
Autos:NumberOfDoors
oppure
TomsCar:Owner:Age, dove TomsCar assume il valore Tom e Tom:Age
45, quindi si ottiene 45);
Marco Meluccio
19
Il linguaggio KAL




gli operatori infissi (=, +=, -=; aritmetici: +, -, *, / , ^, di confronto: <,
>, <=, >=, ==, !=, ~=; su stringhe: # unisce due stringhe, confronto #=,
#<, #>; logici: And, Or, Xor; altri operatori: +, -, Not);
le espressioni speciali (While, For, ForAll, If, Let);
i blocchi di espressioni unite da parentesi;
le funzioni permettono di






creare e modificare gli elementi della conoscenza;
valutare espressioni logiche, matematiche e su stringhe;
controllare blocchi di espressioni;
manipolare liste, file, database e fogli elettronici;
controllare il processo di conoscenza;
controllare l’interfaccia grafica.
sintassi: NomeFunzione(argomento1, argomento2,…)
16/3/99
Marco Meluccio
20
Ragionamento basato sulle regole
KappaPC fornisce un ambiente di sviluppo che permette di
scegliere diversi modi per sviluppare un’applicazione:
programmazione orientata agli oggetti, ragionamento
basato su regole, programmazione classica.
Una regola è simile ad una frase condizionale in un
programma convenzionale: if this, then that.
Un motivo per cui usare le regole è l’inference engine, uno
speciale programma per trattare le regole. Inoltre le regole
possono rappresentare un modo efficiente per codificare
l’informazione.
16/3/99
Marco Meluccio
21
Ragionamento basato sulle regole
Si possono evidenziare due tipi di ragionamento:
 ragionamento in avanti (simulare dei processi: per esempio
modellare gli effetti della condizione della batteria su
un’operazione della macchina);
 ragionamento all’indietro (diagnosticare dei problemi: per
esempio scoprire perché una macchina non vuole partire).
Il primo procede dalle premesse alle conclusioni. Il secondo
dalle conclusioni cerca di verificare se un certo fatto può
essere stabilito ed è anche detto ragionamento guidato
dall’obiettivo.
16/3/99
Marco Meluccio
22
Esempio di ragionamento basato su regole
GoodElecSys
IF the SparkPlugCondition is Good
and the Timing is In Synch
and the Battery is Charged
THEN the ElectricalSystem is Good
BadElecSys
IF the SparkPlugCondition is Bad
Or the Timing is Out OfSynch
Or the Battery is Low
THEN the ElectricalSystem is Bad
16/3/99
Marco Meluccio
23
Esempio di ragionamento basato su regole
Supponendo “SparkPlugCondition good” e “Timing In Synch”, cosa
succede se il valore dello slot della batteria è posto a “charged”? In
questo modo si asserisce un nuovo fatto: il motore d’inferenza scopre
che una premessa della regola combacia con questo nuovo fatto.
Continua poi a controllare se le altre due premesse sono verificate.
Nel ragionamento all’indietro invece non si comincia asserendo, ma
ponendo una domanda:
Qual è lo stato del sistema elettrico?
Il ragionamento all’indietro procede dalle conclusioni alle premesse e
quando il motore d’inferenza raggiunge un valore che non può essere
accertato, questo verrà chiesto all’utente. In questo caso verrà chiesto il
valore della batteria. Se questo sarà “low”, il ragionamento all’indietro
porterà alla conclusione che il sistema elettrico è “bad”, se sarà
“charged”, si otterrà che il sistema elettrico è “good”.
16/3/99
Marco Meluccio
24
Scegliere il ragionamento basato su regole
E’ necessario:


16/3/99
scegliere tra il ragionamento in avanti e il ragionamento all’indietro: il
primo è più appropriato quando si inseriscono nuovi fatti e si vogliono
trovare le conclusioni (spesso vero in una simulazione: cambia il
valore della batteria e si vogliono trovare le conseguenze), il secondo è
più utilizzato per ragioni diagnostiche (ad esempio: La macchina ha la
batteria guasta?).
determinare quando si devono utilizzare le regole: se un processo
richiede poche condizioni ed è composto da serie di passi
predeterminati, le regole sono inefficienti. Le regole sono utili se le
condizioni possono essere spezzate in tante piccole regole e se il
controllo fornito dal motore d’inferenza (ragionamento all’indietro e in
avanti) è appropriato.
Marco Meluccio
25
Ragionamento basato su regole: sintassi
Specificare premesse e conclusioni
Una premessa o una conclusione di una regola in KAL
tipicamente contiene nomi degli oggetti, i loro slot e i loro
valori. Un esempio è il seguente:
MarysCar:SparkPlugCondition #= Good
Questa espressione chiede se l’oggetto MarysCar contiene
uno slot SparkPlugCondition con un valore Good.
L’operatore #= testa se due stringhe sono uguali (da non
confondere con l’operatore = che assegna un valore o con
== che confronta due numeri).
16/3/99
Marco Meluccio
26
Ragionamento basato su regole: sintassi
Usare regole con variabili
Regole come quella fornita come esempio nella pagina
precedente possono essere applicate solo ad una istanza in
particolare. Per rendere più generale una regola si possono
utilizzare delle variabili.
Variabili nelle regole sono chiamate patterns in Kappa PC.
Un esempio:
GoodElecSys [car|Autos]
If car:SparkPlugCondition #= Good And
car:Timing #= InSynch And
car:Battery #= Charged;
Then car:ElectricalSystem = Good;
16/3/99
Marco Meluccio
27
Ragionamento basato su regole: sintassi
Nell’esempio precedente prendiamo in considerazione
l’espressione tra parentesi [car|Autos]: la parola o l’atomo
prima della barra verticale è la variabile da usare
all’interno della regola, mentre la parola dopo la barra
indica la classe le cui istanze saranno legate alla variabile.
Priorità delle regole
Fissare la priorità di una regola permette di determinare
l’ordine di precedenza nel ragionamento quando sono
applicate più di una regola. La priorità va da -32000 a
+32000, mentre il valore di default è 0. Per cambiare la
priorità si può usare o il Rule Editor o la funzione
SetRulePriority.
16/3/99
Marco Meluccio
28
Regole in Kappa PC
Ci sono alcune considerazioni importanti nello scrivere le
regole:
 quali regole si vogliono rilevanti, in quale momento e in
quale tempo è segnato nella Rule List;
 nella lista Agenda si trovano le coppie object:slot
nell’ordine con cui sono processati dal motore d’inferenza
in avanti;
 si può creare un insieme più ristretto di regole per rendere
più efficiente il ragionamento in avanti (Rule Set);
 per bloccare il ragionamento in qualche punto si possono
usare dei Break Point;
16/3/99
Marco Meluccio
29
Regole in Kappa PC

se si usa un ragionamento in avanti, si possono scegliere
quattro modi di ragionamento:
–
–
–
–


16/3/99
selective (default);
depth-first;
breadth-first;
best-first;
se due regole sono in conflitto, si deve decidere quale
applicare fissando le priorità;
se si usa il ragionamento all’indietro, è necessario fissare
gli obiettivi (goal).
Marco Meluccio
30
Ragionamento in avanti
Il ragionamento in avanti comincia quando una coppia
oggetto:slot è rimossa dall’Agenda. La corrente coppia è
messa a confronto con ogni regola nell’insieme di regole
fornite con la funzione ForwardChain. Una regola
nell’insieme è considerata se almeno una delle sue
premesse si riferisce alla coppia in esame. Per ciascuna
regola vengono esaminate tutte le rimanenti regole. Una
regola in cui tutte le regole sono verificate è detta
applicabile, è tolta dalla Rule List e sono valutate le sue
conseguenze.
16/3/99
Marco Meluccio
31
Ragionamento in avanti
Se le conclusioni rispondono alla domanda posta in
partenza (goal), il ragionamento si ferma.
 Altrimenti
le conclusioni trovate vengono poste
nell’Agenda.
In questo modo si termina un ciclo di ragionamento in avanti.
Se non è raggiunto il goal, viene presa la successiva coppia
object:slot nell’Agenda e il ciclo ricomincia.
Se non è specificato alcun goal, il ragionamento termina
quando non c’è più nulla da esaminare, ovvero quando
l’Agenda è vuota.

16/3/99
Marco Meluccio
32
Tre passi per il ragionamento in avanti
Sono necessari tre passi per il ragionamento in avanti:
 cambiare il valore di uno slot
ObjName:SlotName = NewValue;

comunicare al motore d’inferenza che è stato cambiato un
valore di uno slot con il comando Assert (si può omettere
utilizzando l’opzione [NOASSERT])
Assert(ObjName, SlotName);

iniziare il ragionamento in avanti
ForwardChain(GoalName, RuleSet);
Al posto di GoalName può essere passato il valore NULL.
Il goal è invece obbligatorio nel ragionamento all’indietro.
16/3/99
Marco Meluccio
33
Strategie del ragionamento in avanti
BadElecSys:
IF car:SparkPlusCondition #= Bad Or
car:Timing #= OutOfSynch Or
car:Battery #= Low;
THEN car:ElectricalSystem = Bad;
GoodElecSys:
IF car:SparkPlugCondition #= Ok And
car:Timing #= InSynch And
car:Battery #= Charged;
THEN car:ElectricalSystem = Ok;
BadEngineSys:
IF car:IgnitionKey #= Off Or
car:GasSystem #= Bad Or
car:ElectricalSystem #= Bad;
THEN car:Status = Stopped;
16/3/99
GoodEngSys:
IF car:IgnitionKey #= On And
car:GasSystem #= Ok And
car:ElectricalSystem #= Ok;
THEN car:Status = Running;
BrighLights:
IF car:LightSwitch #= On And
car:Battery #= Charged;
THEN car:LightsAppearance = Bright;
DimLights:
IF car:LightSwitch #= On And
car:Battery #= Low;
THEN car:LightsAppearance = Dim;
Marco Meluccio
34
Strategie del ragionamento in avanti
BriskTurnover:
IF car:IgnitionKey #= On And
car:ElectricalSystem #= Low;
THEN car:EngineTurnover = Brisk;
SluggishTurnover:
IF car:IgnitionKey #= On And
car:ElectricalSystem #= Bad;
THEN car:EngineTurnover = Sluggish;
All’inizio del processo i valori iniziali sono i seguenti:
Battery
NULL
ElectricalSystem
NULL
EngineTurnover
NULL
IgnitionKey
On
LightsAppearance
NULL
LightSwitch
On
Status
NULL
16/3/99
Marco Meluccio
35
Strategia selective
E’ la strategia di default: è la più efficiente, perché segue un solo passo di
ragionamento, ma non è una strategia esaustiva. Se si cambia strategia,
si può tornare a questa con SetForwardChainMode(SELECTIVE).
Durante il ragionamento nuove regole sono aggiunte alla rule list secondo
la loro priorità. Appena una regola è TRUE, le rimanenti regole sono
cancellate. L’Agenda deve essere vuota prima che sia testata la
successiva regola nella lista. Il processo è iniziato dalla seguente lista
di comandi:
–
–
–
MyCar:Battery = Low;
Assert(MyCar, Battery);
ForwardChain(NULL, ruleset);
Si ottiene:
–
–
16/3/99
MyCar:ElectricalStatus = Bad;
MyCar:Status = Stopped;
Marco Meluccio
36
Strategia selective
Agenda
Active Rule List
MyCar:Battery
empty
empty
empty
GoodElecSys, BadElecSys, BrighLights,
DimLights
BadElecSys, BrighLights, DimLights
MyCar:ElectricalSystem
empty
empty
GoodEngSys, BadEngineSys,
BriskTurnover, SluggishTurnover
BadEngineSys, BriskTurnover,
SluggishTurnover
empty
empty
MyCar:Status
16/3/99
Marco Meluccio
37
Strategia depth-first
E’ una ricerca esaustiva: scopre tutte le possibili implicazioni, ma è meno
efficiente. Differisce dalla strategia selective nel fatto che non viene
azzerata la rule list dopo ogni applicazione con successo di una regola.
Durante il processo di ragionamento nuove regole sono aggiunte all’inizio
della rule list. Se ci sono più item nell’Agenda e nella rule list, la
priorità è data al successivo item nell’Agenda. Si inizia con i seguenti
comandi:
–
–
–
–
SetForwardChainMode(DEPTHFIRST);
MyCar:Battery = Low;
Assert(MyCar, Battery);
ForwardChain(NULL, ruleset);
Si ottiene:
MyCar:ElectricalStatus = Bad; MyCar:Status = Stopped;
MyCar:EngineTurnover = Sluggish; MyCar:LighsAppearance = Dim;
16/3/99
Marco Meluccio
38
Strategia depth-first
Agenda
Active Rule List
MyCar:Battery
empty
empty
GoodElecSys, BadElecSys,
BrightLights, DimLights
MyCar:ElectricalSystem
BrightLights, DimLights
empty
GoodEngSys, BadEngineTurnover,
BriskEngineTurnover,
SluggishTurnover, BrightLights,
DimLights
BadEngineSys, BriskTurnover,
SluggishTurnover, BrightLights,
DimLights
empty
16/3/99
Marco Meluccio
39
Strategia depth-first
MyCar:Status
BriskTurnover, SluggishTurnover,
BrightLights, DimLights
empty
BriskTurnover, SluggishTurnover,
BrightLights, DimLights
empty
SluggishTurnover, BrightLights,
DimLights
MyCar:EngineTurnover
BrightLights, DimLights
empty
BrightLights, DimLights
MyCar:LightsAppearance
16/3/99
Marco Meluccio
40
Strategia breadth-first
Come la strategia depth-first, è una strategia esaustiva che scopre tutte le
possibili implicazioni. Anche questa è meno efficiente della strategia
selective. Durante il processo di ragionamento le nuove regole
vengono aggiunte in fondo alla rule list. Se ci sono più item
nell’Agenda e nella rule list, la priorità è data alla successiva regola
nella rule list. Si inizia con i seguenti comandi:
–
–
–
–
SetForwardChainMode(BREADTHFIRST);
MyCar:Battery = Low;
Assert(MyCar, Battery);
ForwardChain(NULL, ruleset);
Si ottiene:
MyCar:ElectricalSystem = Bad; MyCar:LighsAppearance = Dim;
MyCar:Status = Stopped; MyCar:EngineTurnover = Sluggish;
16/3/99
Marco Meluccio
41
Strategia breadth-first
Agenda
Active Rule List
MyCar:Battery
empty
empty
MyCar:ElectricalSystem
GoodElecSys, BadElecSys,
BrightLights, DimLights
BrighLights, DimLights
MyCar:ElectricalSystem
DimLights
MyCarElectricalSystem
MyCar:LightsAppearance
MyCar:LightsAppearance
empty
16/3/99
GoodEngSys, BadEngineSys,
BriskTurnover, SluggishTurnover
Marco Meluccio
42
Strategia breadth-first
MyCar:LightsAppearance
MyCar:LightsAppearance
MyCar:Status
MyCar:LightsAppearance
MyCar:Status
MyCar:LightsAppearance
MyCar:Status
MyCar:EngineTurnover
MyCar:Status
MyCar:EngineTurnover
MyCar:EngineTurnover
empty
16/3/99
BadEngineSys, BriskTurnover,
SluggishTurnover
BriskTurnover
SluggishTurnover
SluggishTurnover
empty
empty
empty
empty
Marco Meluccio
43
Strategia best-first
Questa strategia è simile a quella depth-first, è esaustiva e scopre tutte le
implicazioni possibili. Le nuove regole vengono aggiunte alla lista, ma
l’ordine è dato dalla priorità. Se ci sono più item nell’Agenda e nella
rule list, la priorità è data al successivo item nell’Agenda. Per esempio
possiamo assumere le seguenti priorità: BadElecSys 8, BadEngineSys 7,
BrightLights 6, BriskTurnover 5, DimLights 4, GoodElecSys 3, GoodEngSys
2, SluggishTurnover 1. Il processo è iniziato dai comandi:
– SetForwardChainMode(BESTFIRST);
– MyCar:Battery = Low;
– Assert(MyCar, Battery);
– ForwardChain(NULL, ruleset);
Si ottiene:
MyCar:ElectricalSystem = Bad; MyCar:Status = Stopped;
MyCar:LighsAppearance = Dim; MyCar:EngineTurnover = Sluggish;
16/3/99
Marco Meluccio
44
Strategia best-first
Agenda
Active Rule List
empty
BadElecSys (8), BrightLights(6),
DimLights(4), GoodElecSys(3)
MyCar:ElectricalSystem
BrightLights(6), DimLights(4),
GoodElecSys(3)
empty
BadEngineSys (7), BrightLights (6),
BriskTurnover (5), DimLights (4),
GoodElecSys (3), GoodEngSys (2),
SluggishTurnover (1)
BrightLights(6), BriskTurnover (5),
DimLights (4), GoodElecSys (3),
GoodEngSys (2), SluggishTurnover (1)
BrightLights (6), BriskTurnover (5),
DimLights (4), GoodElecSys (3),
GoodEngSys (2), SluggishTurnover (1)
MyCar:Status
empty
16/3/99
Marco Meluccio
45
Strategia best-first
empty
empty
BriskTurnover (5), DimLights (4),
GoodElecSys (3), GoodEngSys (2),
SluggishTurnover (1)
DimLights (4), GoodElecSys (3),
GoodEngSys (2), SluggishTurnover (1)
GoodElecSys (3), GoodEngSys (2),
SluggishTurnover (1)
GoodElecSys (3), GoodEngSys (2),
SluggishTurnover (1)
GoodEngSys (2), SluggishTurnover (1)
empty
SluggishTurnover (1)
MyCar:EngineTurnover
empty
empty
MyCar:LightsAppearance
empty
16/3/99
Marco Meluccio
46
Ragionamento all’indietro
Nel ragionamento all’indietro o ragionamento guidato dall’obiettivo, il
motore d’inferenza tenta di verificare un fatto cercando regole che
provano il fatto stesso e poi cercando di verificare le loro premesse. Le
premesse a loro volta diventano nuovi fatti da verificare con altre
regole e così via. Ci sono tre fasi di questo tipo di ragionamento:
 espansione:
il motore d’inferenza cerca di verificare le premesse delle regole o le coppie
object:slot al fine di cercare di soddisfare l’obiettivo;

collapsing:
il motore d’inferenza cerca di verificare se il goal è stato soddisfatto;

richiesta:
quando il motore d’inferenza non riesce a trovare il valore di uno slot, lo
richiede all’utente. Può essere utilizzata questa strategia per chiedere
all’utente informazioni in particolari momenti. Questa fase è opzionale e
si può eliminare con l’opzione [NOASK].
16/3/99
Marco Meluccio
47
Ragionamento all’indietro
Si può attivare il processo all’indietro da una delle tre finestre del sistema
Kappa PC:
 l’interprete KAL (usando la funzione BackwardChain);
 la finestra Rule Trace (usando l’opzione BackwardChain nel menu
Control);
 l’Inference Browser (usando l’opzione Step Mode dal menu Options).
Il ragionamento all’indietro può essere attivato anche da espressioni KAL
in un metodo, in una funzione, in una regola…
Ci sono tre elementi importanti da tenere in considerazione:
 la variabile opzionale [NOASK];
 il goal sempre richiesto;
 l’opzionale insieme di regole (rule set).
16/3/99
Marco Meluccio
48
Strumenti di sviluppo
16/3/99
Marco Meluccio
49
Kappa PC’s main window
La finestra principale del sistema Kappa PC serve come
interfaccia per gestire lo sviluppo di una applicazione.
Questa finestra permette di:
 salvare e recuperare file e applicazioni;
 gestire tutte le finestre dell’ambiente di sviluppo Kappa
PC.
La barra menu principale contiene quattro menu:
–
–
–
–
16/3/99
file;
edit;
windows;
options.
Marco Meluccio
50
Object Browser
16/3/99
Marco Meluccio
51
Object Browser
L’Object Browser permette di vedere e di modificare gli
oggetti e le loro relazioni nella applicazione. Presenta una
vista grafica della gerarchia degli oggetti.
Ogni oggetto con sottoclassi definite nascoste è mostrato con
un rettangolo intorno, mentre, se sono nascoste solo delle
istanze, l’oggetto è mostrato con un ellisse. Le classi sono
mostrate con una linea continua, mentre le istanze sono
mostrate con una linea tratteggiata e in corsivo.
Si può accedere all’Object Browser anche con le funzioni
(sono descritte nell’Help sotto Object Browser Functions).
16/3/99
Marco Meluccio
52
Esempio finestra sessione
16/3/99
Marco Meluccio
53
Finestre sessioni
La Session Window è la principale interfaccia per l’utente
dell’applicazione. L’ambiente Kappa PC permette allo
sviluppatore dell’applicazione di adattare questa finestra
con la propria scelta grafica, creando un’interfaccia che
semplifica l’interazione tra l’utente e l’applicazione.
La Session Window ma due modalità:
 layout (serve per modificare la presentazione grafica
dell’applicazione);
 runtime (mostra l’applicazione che interagisce con
l’utente).
16/3/99
Marco Meluccio
54
Tool Box
Per creare l’interfaccia grafica dell’applicazione, è possibile utilizzare la Tool Box
mostrata a sinistra.
E’ possibile inserire nella
finestra dell’applicazione ad
esempio:
Button, CheckBoxGroup,
ComboBox,Edit,
SingleListBox, MultipleListBox,
RadioButtonGroup, Slider,
CheckBox
16/3/99
Marco Meluccio
55
Editor
E’ possibile utilizzare questi
editor per modificare classi,
istanze, funzioni, regole,
goal, metodi, slot.
16/3/99
Marco Meluccio
56
La finestra interprete KAL
La finestra KAL permette interpretare le espressioni in
linguaggio KAL. L’interprete serve a due scopi:
 un ambiente di sviluppo alternativo agli editor e all’Object
Browser;
 un meccanismo per testare le espressioni KAL valutandole.
Per esempio si può creare una nuova classe con:
MakeClass(Autos, Root)
oppure creare una nuova regola con:
MakeRule(Rule1, [car|Autos], car:MaxSpeed >= 180,
carType = Racing);
16/3/99
Marco Meluccio
57
KalView Debugger
La finestra KalView Debugger è divisa in tre parti:
 la finestra del codice sorgente mostra la funzione o il
metodo in esame;
 la Value Window mostra il valore di ritorno di ciascuna
espressione, quando si esegue la funzione passo a passo;
mostra anche vari messaggi;
 la Watches Window mostra i valori di varie variabili o slot.
Se questa finestra è ridotta a icona, funge da watchdog per
eventuali errori nelle funzioni e nei metodi. Questo però
rallenta l’esecuzione dell’applicazione.
16/3/99
Marco Meluccio
58
Strumenti del sistema di regole
Questi tre strumenti:
Rule Relations Window
Rule Trace Window
Inference Browser
formano il sistema di regole
del KAPPA PC.
16/3/99
Marco Meluccio
59
Rule Relations Window
Kappa PC fornisce un modo grafico per mostrare le relazioni tra le regole.
Nella finestra si può mostrare quale regola interessa. Altre regole, le cui
conclusioni combaciano con le premesse della regola specificata, sono
mostrate come If Dependencies; altre invece, le cui premesse combaciano
con le conclusioni della regola specificata, sono mostrate come Then
Dependencies.
16/3/99
Marco Meluccio
60
Rule Trace Window
Questa finestra permette di vedere le regole che il motore di
inferenza invoca nella forma scritta. Permette anche di
seguire l’impatto del ragionamento su particolari slot nella
base di conoscenza. Si può vedere come il sistema genera
nuove conclusioni. Se si vuole utilizzare il Rule Trace
durante il ragionamento basato sulle regole bisogna fissare
tracing e breaking su particolari regole prima di iniziare il
processo di ragionamento.
La Rule Trace Window permette di guardare il processo di
ragionamento sia in avanti sia all’indietro.
16/3/99
Marco Meluccio
61
Inference Browser
Questa finestra permette di vedere le regole che il motore di
inferenza invoca in una forma grafica. Nel browser si può
vedere come il sistema arriva alle conclusioni esaminando
linee di ragionamento una volta che il processo di
ragionamento è completo. Si può usare l’Inference
Browser anche per rintracciare gli errori nella base di
conoscenza dell’applicazione.
16/3/99
Marco Meluccio
62