Professional Documents
Culture Documents
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).
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
E’ necessario:
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.
BadElecSys: GoodEngSys:
IF car:SparkPlusCondition #= Bad Or IF car:IgnitionKey #= On And
car:Timing #= OutOfSynch Or car:GasSystem #= Ok And
car:Battery #= Low; car:ElectricalSystem #= Ok;
THEN car:ElectricalSystem = Bad; THEN car:Status = Running;
GoodElecSys: BrighLights:
IF car:SparkPlugCondition #= Ok And IF car:LightSwitch #= On And
car:Timing #= InSynch And car:Battery #= Charged;
car:Battery #= Charged; THEN car:LightsAppearance = Bright;
THEN car:ElectricalSystem = Ok; DimLights:
BadEngineSys: IF car:LightSwitch #= On And
IF car:IgnitionKey #= Off Or car:Battery #= Low;
car:GasSystem #= Bad Or THEN car:LightsAppearance = Dim;
car:ElectricalSystem #= Bad;
THEN car:Status = Stopped;
BriskTurnover: SluggishTurnover:
IF car:IgnitionKey #= On And IF car:IgnitionKey #= On And
car:ElectricalSystem #= Low; car:ElectricalSystem #= Bad;
THEN car:EngineTurnover = Brisk; THEN car:EngineTurnover = Sluggish;
MyCar:ElectricalSystem empty
MyCar:LightsAppearance
MyCar:ElectricalSystem DimLights
MyCarElectricalSystem empty
MyCar:LightsAppearance
MyCar:LightsAppearance GoodEngSys, BadEngineSys,
BriskTurnover, SluggishTurnover
empty empty
Si ottiene:
MyCar:ElectricalSystem = Bad; MyCar:Status = Stopped;
MyCar:LighsAppearance = Dim; MyCar:EngineTurnover = Sluggish;
MyCar:EngineTurnover empty
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).