CAPITOLUL I

SISTEME EXPERT

10
1.1. Sisteme expert.

Sistemele expert reprezint o ramur a inteligenlei artificiale. Un

sistem expert reprezint un program care urmrete cunotintele,
rationeaz pentru obtnerea rezultatelor ntr-o activitate dificil ntreprins
uzual doar de expertii umani.
Din punct de vedere functional, un sistem expert poate fi definit ca
fiind un program care urmrete un grup de cunotinte pentru oblinerea n
acelai mod ca i expertii umani a rezultatelor despre activitti dificil de
examinat.
Aadar, sistemele expert sunt destinate rezolvrii unor probleme care n
mod normal ar necesita prezenta unui expert uman. Conceperea i
realizarea unui sistem expert implic extragerea cunoaterii de la expertul
uman. Deseori, cunoaterea este de natur euristic, oblinerea i
transpunerea ei intr-o form utilizabil pe calculator este adesea o
problem dificil de realizat. Inginerul de cunotinte are misiunea de a
obtine cunoaterea i de a construi sistemul bazat pe cunoatere.
Sistemele expert au fost dezvoltate intr-o multitudine de domenii
cum ar fi: agricultur, chimie, inginerie, geologie, afaceri, matematic,
medicin, meteorologie, tiinta militar, tehnologie spatial, etc.
Un sistem expert este bazat pe dou componente disticte:
- noi tehnologii de programare
- metodologii pentru manipularea cunotintelor.
Cele mai cunoscute exemple de sisteme expert din cteva domenii
majore de activitate sunt urmtoarele:

Chimie:
CRYSTALIS (deduce structura 3D a unei proteine dintr-o
hart de
densitate electronic),
DENDRAL (deduce structura topologic a compuilor
organici),
CLONER

tiinla calculatoarelor:
PTRANS (ajut la organizarea i distributia sistemelor
DEC),
BDS (ajut la localizarea modulelor defecte ntr-o retea mare
de comutare de semnale),
DART (diagnosticarea defectelor ntr-un sistem hardware),
11
 XCON (configurarea calculatoarelor VAX

Electronic:
ACE (diagnosticarea defectelor n retelele teleforuce),
EURISKO (proiectarea dispozitivelor electronice 3D),
REDESIGN (proiectarea circuitelor digitale pentru a
corespunde
noilor specificalii), etc.
DELTA (identificarea i corectarea erorilor de functionare la
locomotive),
SACON (gsirea strategiilor de analiz pentru probleme de
analiz
structural)
Geologie: PROSPECTOR (evaluarea potentialului
mineralogic),
LITHO (analiza petrolului),
HsRO (utilizarea unui program de simulare a existentei apei
n dierite condipi)
Medicin: AI/REHUM (diagnosticarea bolilor legate de
reumatism),
CADUCEOS (diagnosticarea bolilor interne),
BLUE BOX (diagnosticarea i tratarea depresiilor clinice),
ATTENDING (nvtarea metodelor de anesteziere)

Armata:
ASTA (identificarea tipurilor de sisteme radar),
HASP / SIAP (detectarea datelor provenite de la senzori
sonori),
I&W (predictia momentului i locului aparitiei potentiale a
unuiconflict militar),
KNOBS (planificarea misiunilor de lupt).

12
1.2. Arhitecturi de sisteme expert. Componentele unui sistem expert

Structura unui sistem expert poate fi grupat n jurul a trei module

distincte:
1. Baza de cunotinte
2. Mecanismul de inferent
3. Baza de fapte

1. Baza de cunotinte este reprezentat ca o structur de date ce contine

ansamblul cunotintelor specializate introduse n sistem de ctre expertul
uman. Cunotintele stocate n baza de cunotinte reprezint descriptii de
obiecte n conjunctie cu relatiile dintre acestea. Baza de cunotinte face
parte din sistemul cognitiv al sistemului expert i este memorat ntr-un
spatiu special organizat.

2. Mecanismul de inferenta realizeaz o serie de obiective majore dup

preluarea cunotintelor din baza de cunotinte i anume:
alege strategia de control n fimctie de problemele de rezolvat,
elaboreaz planul de rezolvare a problemei,
execut comutarea de la o strategie de control la alta,
execut atliunile prevzute n planul de rezolvare,
constituie informatiile de control pentru mecanismele fundamentale
ale mecanismului de inferent.
Mecarusmul de inferenl este constituit dintr-un ansamblu de proceduri .

3. Baza de fapte este reprezentat de o memorie auxiliar ce contine toate

datele utilizatorului (faptele iniliale ce descriu enuntul problemei) i
rezultatele intermediare produse n cursul procedurii de deductie.
Pe lng aceste module, un sistem expert mai contine o serie de module
ce asigur comunicarea cu operatorul i cu expertul uman.

Modulul de comunicatii este destinat furnizrii interfetelor specifice

pentru utilizatorii sistemului expert ct i pentru achizitia cunotinlelor.
Modulul de comunicare are urmtoarea componenta:
limbaje de comunicare cu utilizatorul,
limbaje pentru achizitia cunostiintelor,
procesoare pentru comunicarea intern ntre sistemul expert i
echipamentele suxiliare pentru stocarea cunoaterii,
procesoare speciale pentru intrri - ieiri grafice,
achizitia senzorial i instrumental a cunoaterii si

13
 comanda elementelor de executie.

Interfata utilizator este partea componet a sistemului expert care

asigur dialogul ntre utilizator i sistem n limbaj cvasinatural prin
translatarea limbajului intern i comunic mecanismului de inferent
cererile utilizatorului. Interfata utilizator mai asigur achizitia enuntului
problemei initiale i comunicarea rezultatului.
Modulul de achizitie a cunotintelor este partea component ce
preia cunotinlele specializate furnizate de expertul uman sau de inginerul
de cunotinte ntr-o form ce nu este specific reprezentrii interne. O
serie de cunotinte pot fi furnizate prin fiiere specifice bazelor de date
sau alte programe externe. Acest modul receptioneaz cunotintele,
verific validitatea acestora i n final genereaz o baz de cunotinte
coerent.
Modulul de explicatii permite trasarea drumului urmat n rationare
de ctre sistemul rezolutiv i emiterea justificrilor pentru soluliile
obtinute, fiind scoase n evidenl cauza greelilor sau motivul eecului.
Prin aprofundarea elementelor componente i introducerea termenului de
infrastructur, sistemele expert au trei tipuri de infrastructuri:

1. Infrastructura conceptual sau general care contine elementele

fundamentale i virtuale ale sistemului expert.

2. Infrastructura logic sau organizational care contine elementele

concrete necesare realizrii unui sistem expert

3. Infrastructura operational sau tehnic care contine elementele

particulare ale sistemului.

Elementele fundamentale ale infrastructurii conceptuale a unui sistem

expert sunt urmtoarele (fig.1.1):
domeniul de activitate,
expertul uman,
inginerul de cunotinte (cogniticianul),
modulul de transformare a cunotintelor (MTC),
baza de cunotinte (BC),
baza de fapte (BF),
baza de reguli (BR),
motorol de inferente (MI),
modulul de verificare-explicare (MVE) si
interfata cu utilizatorul (IU).

14
 Initierea sistemului esential

Inginer Modul de Baza Motor Inter- Utili-

Domeniul de transfor- de de fata zator
de cunos- mare a re- infe- utili-
utilizare tinte cunostin- guli renta zator
telor

Baza Modul
de de
fapte veri-
ficare Utilizarea
Expertul expli- cunostinte-
care lor
Baza
de
Furnizarea cunostintelor
cunos-
tinte Preluc-
rarea
cunos-
tintelor

Reglare feed-back

Fig. 1.1. Infrastructura general a unui sistem expert

15
Infrastructura logico-organizajional a sistemelor expert are urmtoarele
elemente fundamentale (fig.1.2):
editorul,

baza de cunotinte,

motorul de inferent,

trasorul,

modulul de nvtare,

module auxiliare i

interfala utilizator.

Editorul este componenta care realiozeaz urmtoarele functii:

introducerea regulilor i faptelor,

interfata de dialog pentru schimbul de cunotinte,

verificarea coerctitudinii regulilor nscrise,

detectarea incoerentelor pentru acele reguli,

gestioneaz lista complet a obiectelor,

asigur compilarea erorilor si

asigur confidenlialitatea acceselor la baza date.

16
 Dictionar de
fapte ,reguli,
obiecte si
frame-uri

PROTECTIA SI
EDITOR COMPILATOR REGULI CONFIDENTIALITATEA
Accesul la baza de date

INVATARE Baza de fapte MODULE

AUXILIARE

Baza de reguli
TRASOR

Baza de cunostinte

Motorul de inferenta

INTERFATA UTOLIZATORULUI UTILIZATOR

Fig.1. 2 Infrastructura logico-organizalional a unui sistem expert

Trasorul urmareste rationamentele desfasurate de motorul de

inferente. Modul de invatare este componenta care asigur achizitia de
noi reguli i reperarea euristicilor performante.
Modulele auxiliare contin functiile Help de orientare a
utilizatorului. Interfala utilizator asigur aspectul fundamental, facilitnd
dezvoltarea de ecrane i ferestre, sisteme de meniuri, ecrane tactile etc.

17
1.3.1. Metode de reprezentare a cunoaterii.
Reprezentarea cunoaterii are ca scop descrierea universului n care
sistemul efectueaztra~ionamente sub form de entitti corespunztoare
indivizilor i sub form de simboluri pentru relatiile dintre acestea.
Deoarece cunoaterea se modific n timp, o reprezentare declarativ a
strii initiale nu este posibil i se pune problema nregistrii enumerative
a succesiunilor de stare(fig.1.3).

Nivel Analiza cerinte

extern

Nivel conceptual Schema conceptuala

Nivel intern Schema interna

Stocare

Fig. 1.3 Structura unei arhitecturi de reprezentare a cunostintelor

Nivelul intern este constituit din schema intem ce descrie structura

de stocare fizic a cunotinlelor n baza de cunotinte. La acest nivel se
descriu detaliile complete ale stocrii i modul de acces la cunotinte.
18
 Nivelul conceptual descrie structura ntregii baze de cunotinte
pentru o comunitate de utilizatori. La acest nivel se face o descriere
complet a bazei de cunotinte, fiind pus accentul pe descrierea
entittiilor, tipurilor de date, relatiilor dintre ele, restrictiilor asociate.
Nivelul extern sau nivelul vizual sau nivelul utilizator include o
colectie de scheme externe ce descrie baza de cunotinte prin prisma
diferitilor utilizatori.
O entitate este un obiect al lumii reale cu o existent independent.
Orice entitate are o serie de proprietti denumite atribute ce
particularizeaz entitatea respectiv. Valorile acestor atribute au ca scop
identificarea entitlii.
Unele atribute pot fi mprtite n prti mai mici cu semnificatie
independent. Un astfel de atribut se numete atribut complex. Atributele
care nu sunt compuse poart denumirea de atribute atomice. Valoarea
atributelor compuse se formeaz prin compunerea valorilor atributelor
atomice.
Multe atribute au valoarea unic pentru o entitate particular i sunt
numite atribute cu o singur valoare. Exist atribute ce pot lua mai multe
valori, acestea fiind atribute cu mai multe valori.
Atributele derivate sunt atributele ce se pot determina din reltiile ce
exist ntre ele. Descrierea atributelor entittii este numit schema
entittii i se specific o structur comun fixat a entittilor de acelai
tip. Setul instantelor entittilor individuale la un anumit moment este
numit extensie a entittii.
Fiecare atribut al unei entitti tip are asociat un set de valori numit i
domeniu, ce specific valorile posibile ce le poate lua . Matematic,
atributul A al unei entitti de tip E poate fi defntit ca o functie de la E la
setul valorilor posibile ale lui V, sau la toate subseturile lui V.
A:E P(V)
Valoarea atributului A pentru entitatea e, se va nota ca A(e). Pentru
un atribut simplu A(e) este o valoare cu un singur element, un atribut null
nu are valoare sau are valoarea null. Pentru un atribut compus A , setul de
valori este format ca produsul cartezian din P(Vl) P(Vz),..., P(Vn) unde
V,,Vz,...,Vn reprezint setul valorilor unui simplu component al lui A.
Deci V=P(V1) x P(V2) x ... x P(Vn)
ntre entitli se pot stabili o serie de relatii ce pot avea la rndul lor
atribute ce le caracterizeaz. Dac valoarea unui atribut este determinat
prin combinarea entitplor participante intr-o relatie instant i nu prin
entitti singure, atunci atributul se va specifica ca un atribut relatie.

19
 1.3.2. Reprezentarea cunoaterii n limbajul calculului cu predicate
de ordinul nti
n acest mod de reprezentare, piesele de cunoatere sunt descrise
prin expresii ale cror componente sunt formule ale limbajului. Metoda
de reprezentare are ca avantaj introducerea pieselor de cunoatere direct
n sistemul rezolutiv dac acesta este conceput pe baza unor mecanisme
definite n calculul cu predicate de ordinul nti. Baza reprezentrii este
dat de caracteristica de functie propozitional a predicatului. O pies de
cunoatere exprimentat n limbaj natural este descompus n propozitii
elementare adecvate numite asertiuni. Asertiunile specific fapte,
proprietti, relatii legate de piesa de cunoatere. O propozitie elementar
este generat de un predicat cu un numr finit de locuri n care se
specific variabile formale sau obiecte n multimea suport.
Modul de reprezentare a cunoaterii n limbajul calculului cu
predicate de ordinul nti este constituit din dou etape:
Reprezentarea propozitional este reprezentarea in care piesele de
cunoatere sunt descompuse n asertiuni legate prin conectivele logice
specifice calculului propoziponal.
Reprezentarea predicativ n care fiecare asertiune este descompus
n componentele sale, predicate sau obiecte.
Inferentele n calculul propozilional rezult din structura
formulrii. 0 propozitie atomic este cea mai scurt propozitie cu nteles.
Calculul cu predicate este o extensie a calculului propozitional i const
n faptul c extinde forma propozitional.

1.3.3. Metode procedurale de reprezentare a cunoaterii

Metodele procedurale se bazeaz pe aspectele dinamice ale

cunoaterii asupra modului de folosire a pieselor de cunoatere pentru
efectuarea inferentelor, asupra determinrii de noi fapte prin executarea
unor operatii asupra pieselor de cunoatere. Metodele procedurale
presupun utilizarea unor simboluri prin care se identific proceduri ce
sunt evaluate de procesoarele interpretative ale limbajelor de nivel nalt.
Un exemplu de acest tip este limbajul LISP.
Reprezentarea procedural este realizat n termenii unor simboluri
prin care cunoaterea este utilizat n rezolvarea problemelor.
Reprezentarea procedural este dependent de tipul problemei ce se
rezolv cu piesele de cunoatere reprezentate. n msura n care
cunoaterea devine tot mai complex, piesele de cunoatere devin tot mai

20
numeroase. Metodele procedurale au ca principal avantaj uurinta
aplicrii regulilor existente, specifice domeniului de competent
aplicativ.. Cunoaterea astfel reprezentat duce la performante de timp
bune, dar are ca dezavantaj flexibilitatea sczut n utilizarea pieselor de
cunoatere.

1.3.4. Reprezentarea cunoaterii prin retele de productie

Reprezentarea prin retele de productie este cel mai utilizat mod de

reprezentare n sistemele expert. Metoda se bazeaz pe separarea
componentelor obinuite ale calculului n scopul manipulrii mai uoare.
Un sistem de productii este compus dintr-o baz de date i un set de
reguli. Conditile unei reguli pot fi vzute similare cu o baz de date care
ntoarce un indicator de succes sau de eroare. Concluzia unei reguli este o
actiune ce manipuleaz baza de date i n plus un control va determina
secventa regulilor utilizate. Baza de date contine cuvinte construite cu
simboluri din V (set finit de simboluri denumit alfabet total). n concluzie
un sistem de productie R poate fi considerat un dublet R = (D,P) n care
D = o baz de date P = set finit de reguli
Baza de date este constituit dintr-un set de termeni, iar o regul
are forma general
IF c THEN t unde c este conditia format din mai multi termeni,
iar t este actiunea format dintr-un singur termen.
Structura general a unei reguli de productie este:
<Partea conditie> < partea actiune>
avnd interpretarea
IF<partea conditie> este ndeplinit THEN se execut
< partea actiune>
Sau n form mai general:
IF<partea conditie> este ndeplinit THEN se execut
< partea actiune 1 > ELSE se execut < partea actiune 2>

Mecanismul interpretativ al regulilor de productie contine urmtorii

pai:
Selectarea tuturor regulilor ce contin piese de cunoatere ce
satisfac
partea de conditie numit i corespondent. Multimea acestor
reguli constituie mullimea candidat, denumirea exprim c
elementele acestei multimi intr n competitie n urma creia
se decide care regul este efectiv aplicat.

Rezolvarea conflictelor prin care din multimea regulilor aplicabile

21
 se elimin mai nti regulile ce duc la aceleai rezultate, dup care
n conjunctie cu mecanismul de asertare a priorittii pentru
problema respectiv se selecteaz regula ce va fi efectiv aplicat.
Executia prtii actiune a regulii cu cea mai mare prioritate, n
situatia n care sunt aplicabile productii.
n urma aplicrii regulilor anterioare, se reia ciclul ncepnd cu
faza de corespondenl, atta timp ct ciclul produce acliuni materializate
prin modificarea contextului.
Problemele crora trebuie s li se acorde o atentie deosebit n
cadrul regulilor de productie sunt:

analiza conditiei,

rezolvarea contlictelor i

transmiterea actiunii.

22
1.3.5. Reprezentarea cunoaterii prin retele semantice

Modul de reprezentare prin retele semantice a aprut ca o consecint

a modului de surprindere a structurilor relationale de mare
complexitate(fig.3.4). Elementele constitutive ale retelei semantice sunt
nodurile (abstractizri structurale pentru concepte, evenimente, stri) i
arcele sau legturile (abstractizri ale relapilor propriu-zise). Primitivele
de acest fel sunt utilizate n limbajele de nivel inalt ce folosesc pentru
reprezentarea structurilor de date spatii de memorie numite i celule,
legate ntre ele prin pointeri (ex. LISP).

CONCEPT X
Instantiere
(extensiune) Conceptualizare
(intensiune)

INSTANTA W

Fig.1. 4. Relatia concept-instant

23
 Descrierea cunoaterii n retelele semantice este realizat prin
obiecte formale intensionale denumite i concepte i prin obiecte
extensionale denumite instanje. Relatia dintre obiecte i instante poart
denumirea de instantiere iar relatia ntre instante i concepte este
denumit i conceptuatizare i are un caracter intensional.

1.3.6. Reprezentarea cunoaterii cu ajutorul cadrelor

Marvin Minsky introduce teoria cadrelor care ncearc s reuneasc
o parte din conceptele de baz ale metodelor de reprezentare procedural,
sisteme de productii i retele semantice. Un cadru este reprezentat printr-
o structur stereotip ce utilizeaz urmtoarele categorii sintactice:
identificator are asignat un nume care asociat cu alte descrieri
specific
structura cadrului la care este ataat,
forma - categorii de caracteristici la care se asigneaz simboluri,
relationale specifice conceptului si
fateta - categorii reprezentate de perechi simbol-valoare cu care se
descriu
obiectele din relatiile specificate de formele reprezentrii.
Un formalism metalingvistic de reprezentare a cadrelor are urmtoarea
structur:

<cadru>= (<identificator cadru><descriere-forma>)

<descriere-forma>= (<identificator-forma><descriere-fateta>),
(<identificator cadru><descriere-forma>))
<descriere-fateta>= ((<identificator-fateta><descriere data>),
(<identificator~fateta><descriere data>)).
<descriere data>= (<valoare>)(< <descriere data><valoare>)
<valoare>=(<date><date><etichete><mesaje><comentariu>).

O facilitate puternic este cea a introducerii n cadre a reprezentrii

regulilor. Transpunerea unei reguli n cadre pornete de la obiectivele:
-regula conpne dou actiuni distincte deci dou forme
procedurale diferite;
-forma de evaluare (prima form) a condiuilor are ca efect
autorizarea executiei celei de a doua forme procedurale sau
ieirea din regul la eec,a doua form determin corpul
propriu-zis al actiunii ce se execut cnd conditia este
ndeplinit si
-contextul operational este reprezentat de celelalte forma cu
caracter declarativ.

24
 1.4. Sisteme rezolutive

Un sistem rezolutiv este format din totalitatea componentelor unui

sistem de inteligenl artificial ce are ca obiectiv rezolvarea unei
probleme. Prin problem se ntelege o notiune fundamental de
psihologie a gndirii ce se refer la dificultatea de natur cognitiv ce se
constituie ca moment intial al activittilor inteligente.
Mecanismul de inferenl reprezint inima unui sistem expert.
Mecanismul de inferent alimentat de baza de cunotinte construiete
rationamenul n mod dinamic deciznd ce reguli sunt declanate i n ce
ordine. Ciclul de baz al unui mecanism de inferent cuprinde patru faze
i anume(fig.3.5):
-Faza de selectie a unui subansamblu al bazei de fapte i reguli ce
prezint un interes ridicat fat de restul bazei. Selectia ofer o
economie de timp pentro fazele urmtoare.

- Faza de filtrare care are ca efect compararea ntre partea de

premis a regulii considerate i faptele bazei de fapte pentru
determinarea regulilor aplicabile. Aceast faz reduce
substantial ansamblul regulilor ce sunt filtrate cu elementele
din baza de fapte.

-Faza de rezolvare a conflictelor are ca obiectiv alegerea acelor

reguli care sunt efectiv aplicate.

-Faza de executie const n aplicarea reguGlor alese mai nainte,

actiunea constnd n general n adugarea de noi fapte n baza
de fapte.

Faza de Faza de Faza de eliminare Faza de

selectie filtrare conflicte Executie
subansamblu efectiva

Fig. 1.5. Fazele procesului rezolutiv

25
1.5. Strategii de control in mecanismele inferentiale

Strategia de control nainte

Strategia de control nainte are urmtoarea form:

Context de stare initial

Regula 1(operatorul 1)
Context de stale succesiv 1
Regula 2(operatorul 2)
Context de stare succesiv2
Regula 3(operatorul 3)
.
.
.
Regula n(operatorul n)
<Context de stare final> = <obiectivul problem>

Aplicarea regulilor determin date i fapte noi. Se pot obtine astfel

derivri valabile rezultate ca urmare a aplicrii mai multor reguli, dar
numai una este valabil n sensul c apartine lantului ce conduce la
solutie. La un anumit moment nu se cunoate regula ce duce la solutie i
ca urmare se vor aplica toate regulile ce sunt posibil aplicabile obtinnd o
multime de stri caracterizate prin date i fapte. Succesiunea genereaz
un arbore ale crui noduri sunt stri n spatiul strilor, solutia problemei
fiind dat printr-o procedur de cutare n spatiul strilor. Datorit
caracteristicilor metodei, aceasta se mai numete i metoda productiv,
iar strategia se numete strategie de cutare dirijat prin date sau de jos n
sus. Procesul continu pn cnd multimea regulilor aplicabile
devine vid.
Strategia de control napoi
Structura general a inferentierii utiliznd metode de control napoi este
urmtoarea:

26
 Obiectivul problemei = Context de stare final
Regula 1
Context de stare precedent 1
Regula 2
Context de stare precedent 2
Regula 3
.
.
.
Regula n
Context de stare precedent n = Contextul de stare initial

Modul de control specificat mai poart denumirea de control dirijat

prin obiectivul problemei sau de control de sus n jos. Datorit
caracteristicilor sale, aceast metod se mai numete i metod reductiv.
n aceast metod, rationarea pornete de l scop selectnd acele reguli ce
au partea dreapt n corespondenl cu obiectivul problemei. Conditiile
necunoscute (partea stng) devin n acest mod subscopuri ce se vor
demonstra. Procesul continu pn cnd toate subscopurile se verific.

27
 1.6 Sisteme expert n condiii de timp real

Problemele n care evenimente externe trebuiesc tratate de un

sistem expert snt frecvente. Ceea ce intereseaz ntr-o astfel de realizare
snt cel puin urmtoarele aspecte:
-apar evenimente externe la momente de timp oarecare;
-un eveniment extern trebuie procesat n general imediat, dac el nu
este la concuren cu alte resurse ale sistemului;
-timpul este un element important;
Pentru ca un sistem expert care conduce un proces ce funcioneaz n
condiii de timp real s poat fi testat trebuie construit pentru el un
simulator. Situaia este explicat n Fig. 1.6:

SIMULATORUL
PROCESUL REAL
DE PROCES

SE pentru SE pentru
conducerea procesului conducerea procesului

a. Funcionarea n condiii reale b. Funcionarea n condiii simulate

Fig. 1.6: SE n interaciune cu procese

Simulatorul trebuie s reproduc ct mai fidel posibil evenimentele

externe, n timp ce SE pentru conducerea procesului trebuie s fac
sistemul s funcioneze.
n proiectarea aplicaiei este important s punem n capitole separate
prile care in de conducerea procesului de cele care in de buctria
simulrii. Dac procedm n acest mod, n momentul n care simularea a
reuit, vom putea ndeprta fr nici o problem codul simulatorului,
pentru a rmne cu partea care suport funcionarea sistemului, ce
urmeaz a fi apoi cuplat la procesul real.
Snt de asemenea cazuri n care doar simularea conteaz, sistemul expert
este construit numai pentru a studia pe el comportamentul unui sistem

28
real, ceea ce se urmrete fiind aici cunoaterea mai bun a procesului n
sine.
Pentru realizarea unui SE care s lucreze n condiii de timp real, ne
preocup deci s gsim rspuns la urmtoarele ntrebri:
-Ce caracteristici ar trebui s aib un sistem expert capabil a ine
cont de evenimente externe?
-Cum construim un simulator care s reproduc ct mai fidel
evenimente externe?
- Cum procedm atunci cnd una din componentele sistemului este
timpul. Cum simulm ceasul?
Exemplul urmtor descrie un context ce ofer ntreaga gam de trsturi
enunate.

29
Simularea punerii pieselor pe o banda

Consideram o banda transportoare deservita de un robot. Rolul

robotului este de a lua piesele pa banda. Sistemul e format din piese si un
robot care pune piesele pe transportor. Pentru a lua o piesa robotul
consum o cuant de timp, ntotdeauna aceeai. Apariia pieselor pe
transportor se face la momente aleatoare de timp.Prima data se ia prima
piesa aparuta .

Snt dou tipuri de evenimente externe n aceast problem:

-intrarea pe transportor i
-tactul ceasului de timp real corespunzator timpului de lucru al
robotului.

S numim evenimentele din prima categorie evenimente piesa i pe

cele din a doua evenimente ceas. Apariia evenimentelor piesa e
aleatoare n timp, iar apariia evenimentelor ceas se face ntotdeauna dup
acelai interval de timp, cuanta de timp pe care o considerm propice
problemei noastre. Pentru simularea activitii , secunda e o cuant de
timp prea fin iar ora prea grosier. Cea care convine e minutul.
ntr-o prim variant, vom simula apariia evenimentelor piesa de o
manier static, adic memornd n fapte apariia acestor evenimente.
Dimpotriv vom lsa pe seama unei reguli simularea evenimentelor ceas.

30
(deffactsevenimente
(ceas0)
(piesa0)
(piesa1)
(piesa2)
(piesa3)
)

(deffactsparametri
(timpservire3)
)

(deffactsdate
(sirpiese)
(robot)
(trsc0)
)

Grupul de fapte evenimente memoreaz faptele ce descriu evenimentele

externe: ceasul n formatul (ceas <minut>) i apariia pieselor n formatul
(piesa <nume> <momentul de timp>). Ceasul este iniializat la momentul 0.
Grupul parametri memoreaz parametrii simulrii n cazul de fa numai
timpul de luare a unei piese.
Grupul date conine alte fapte ce ajut la simulare: transportor cu piese
iniial goal, un indicator care ine starea robotului (liber ori ocupat) i un
contor al timpului rmas pentru luarea piesei.
(defrulevinepiesa
(ceas?t)
?cl<(piesa?nume?t)
?co<(sirpiese$?sirpiese)
=>
(retract?cl?co)
(assert(sirpiese$?sirpiese?nume))
(printoutt"vinepiesa"
?nume"lamomentul"?tcrlf)
)

Regula de apariie a piesei pe transportor: se activeaz dac ceasul ajunge la

momentul n care o piesa trebuie luata in considerarea ca aparitie pe banda.
Aciunile efectuate snt retragera faptului ce memoreaz apariia piesei
consumat i introducerea numelui piesei n partea dreapt a sirului de
piese.

(defruleincpunerepiesa
?vanz<(robotliber)
(sirdepiese?prima$?rest)
(timppunere?ts)
(ceas?t)
?tr<(trsc?)
=>
(retract?robot?tr)
(assert(robotocupat?prima)

31
(trsc?ts))
(printoutt"incepeluareapiesei
"?prima"la
momentul"?tcrlf)
)

Regula ce marcheaz nceperea punerii piesei: dac daca robotul este liber i
pe transportor se gsete cel puin o piesa atunci robotul devine ocupat cu
luarea primei pise aflat la rnd.
S notm c dintre cele 5 condiii ale prii stngi a regului, doar primele
dou snt restrictive (ele testnd respectiv robotul liber i existena cel puin a
unei nume n sir). Celelalte trei condiii au ca scop preluarea unor valori din
faptele respective: timpul de luare alocat unei piese i ceasul pentru a putea
fi modificat. Faptul (trsc ...) este iniializat la valoarea cuantei de timp
alocate piesei.

(defruleterminluarepiesa
?robot<(robotocupat?nume)
?co<(sir?nume$?rest)
?tr<(trsc0)
(ceas?t)
=>
(retract?robot?co)
(assert(robotliber)
(sirpiese$?rest))
(printoutt"terminluareapisei"?nume"lamomentul"?tcrlf)
)

Regula de terminare a luarii unei piese: dac robotul este ocupat cu luarea
piesei aflat n faa sirului i timpul de luare a acesteia a expirat, atunci
robotul devine liber i piesaiese din sir.
(defruletactceas
(declare(salience100))
?ce<(ceas?t)
?tr<(trsc?v)
=>
(retract?ce?tr)
(bind?t(+?t1))
(assert(ceas?t)
(trsc=(?v1)))
(printoutt"minutul:"?tcrlf)
)

Aceasta este regula care simuleaz ceasul: faptele care pstreaz timpul i
numrul de minute rmase pentru luareapiesei aflate n fa snt actualizate
primul incrementat, al doilea decrementat. S observm c prioritatea acestei
reguli este cea mai mic dintre toate regulile simulrii. Cum condiiile ei de
aplicare snt satisfcute la orice pas al simulrii (existena faptelor ceas i

32
trsc), doar declaraia de salience cu prioritate minim face ca regula s se
activeze numai n cazul n care nici o alt regul nu mai poate fi aplicat.
(defruleoprire
(declare(salience100))
(sirdepiese)
(not(robot$?))
?ce<(ceas?)
=>
(retract?ce)
)

Oprirea simulrii se face cnd sirul este vid i nici un fapt piesa nu a mai
rmas n baz. Maniera de oprire aleas aici a fost prin retragerea unui fapt
care este folosit n absolut toate regulile: cel coninnd ceasul.

Rezultatele rulrii acestui program sunt:

CLIPS>(load"sirpiese.clp")
TRUE
CLIPS>(reset)
CLIPS>(run)
vinepiesaolamomentul0
incepeluareapiesei0lamomentul0
minutul:1
vinepiesa1lamomentul1
minutul:2
minutul:3
terminluareapiesei0lamomentul3
incepeluareapiesi1lamomentul3
minutul:4
vinepiesa2lamomentul4
minutul:5
minutul:6
terminluareapiesei1lamomentul6
incepeluareapiesei2lamomentul6
minutul:7
minutul:8
minutul:9
terminluareapiesei2lamomentul9
minutul:10
minutul:11
vinepiesa3lamomentul11
incepeluareapiesei3lamomentul11
minutul:12
minutul:13
minutul:14
terminluareapiesei3lamomentul14
CLIPS>

33
 1.7 Realizarea Sistemelor EXPERT

1.7.1 Consideraii generale

Realizarea sistemelor expert impune utilizarea unor metodologii de

lucru specifice, care s in cont de particularitile acestor sisteme
inteligente, n raport de sistemele software convenionale i anume:

construirea unui sistem inteligent presupune considerarea problemei

de rezolvat n sens mult mai larg dect simpla rezolvare a acesteia. Acest
lucru se explic prin faptul c definirea problemei i a posibilitilor de
rezolvare sunt mai greu de realizat dect n cazul sistemelor
convenionale.

la realizarea unui sistem expert schemele de rezolvare

convenionale trebuie s fie incluse n mulimea posibilitilor de
rezolvare a problemelor, alturi de cele specifice inteligenei artificiale.

Ceea ce caracterizeaz, n ansamblul lor metodologiile de realizare a

sistemelor expert este faptul c ele se bazeaz pe paradigma realizrii
evolutive a sistemelor software (figura 1), care difer de modelul liniar, al
trecerii o singur dat printr-o serie de etape, faze, activiti etc. Coninutul
diferitelor etape i modul n care este dirijat reluarea acestora reprezint
elementele specifice fiecrei metodologii n parte.

34
 Realizarea sistemelor expert impune desfurarea urmtoarelor tipuri
de activiti:

investigare , n scopul cunoaterii ct mai detaliate a domeniului pentru

care se realizeaz sistemul;
analiz, n principal pentru identificarea i formalizarea cunotinelor;
proiectare, de ansamblu i de detaliu a sistemului expert;
programare a componentelor de sistem;
evaluare a sistemului expert i/sau componentelor acestuia;
activiti de punere n funciune, exploatare i ntreinere a sistemului
expert.

Specific metodologiilor de realizare a sistemelor expert este mbinarea

acestor tipuri de activiti, pe parcursul ntregului ciclu de realizare.
Concomitent cu investigarea se realizeaz att analiza, ct i proiectarea
preliminar a sistemului. Pentru fazele ulterioare, proiectarea se mbin cu
analiza i cu programarea. n acest fel, nu se pot pune n eviden etape
orientate n exclusivitate pe un singur tip de activitate.

Definire Proiectare
specificatii

III

II Codificare
(programare)
I

Validare

Implementare

Integrare module

Fig.1.7 Realizarea evolutiv a sistemelor software

35
Paradigma realizrii evolutive a sistemelor s-a impus n domeniul sistemelor
inteligente ntruct, pe de o parte reprezint o metod mai ieftin, iar pe de
alt parte, de multe ori este singura abordare care permite tratarea cerinelor
nestructurate ale utilizatorilor finali, precum i depirea dificultilor legate
de achiziionarea cunotinelor.
S-a constatat c n cazul sistemelor software complexe este, n
principiu mai ieftin , n termenii unor consumuri mai mici de resurse s se
nceap cu o soluie aproximativ, care s fie apoi treptat mbuntit dect
s se urmreasc obinerea, nc de la nceput a soluiei perfecte.
Realizarea evolutiv a sistemelor asigur posibilitatea lucrului cu
cerinte prost definite. Atunci cnd domeniul este prost structurat i extrem de
dinamic, utilizatorii ntmpin frecvent dificulti n definirea cerinelor fa
de sistemul ce trebuie realizat. Abordarea evolutiv, n iteraii succesive
asigur un grad ridicat de interactivitate ntre utilizatorii i realizatorii
sistemului, fiind posibil astfel formularea cerinelor ntr-un mod gradat.
Utilizatorii nva s-i formuleze cerinele, i mbuntesc posibilitile de
comunicare cu echipa de realizare a sistemului. Prin realizarea unor versiuni
succesive ale sistemului, modalitatea de satisfacere a cerinelor de ctre
sistem se poate valida naintea finalizrii activitii de realizare a acestuia,
ceea ce face posibil ameliorarea funcionalitii lui, precum i creterea
gradului de acceptare a sistemului de ctre utilizatori, concomitent cu
reducerea costurilor de realizare.
Realizarea evolutiv a sistemelor software a determinat definirea
modelului n spiral al ciclului de via al sistemelor expert.
n ceea ce privete achiziionarea cunotinelor, prin realizarea
evolutiv a sistemelor este posibil o dezvoltare incremental a bazei de
cunotine, proces favorizat i de caracterul declarativ al majoritii
schemelor de reprezentare a cunotinelor. Versiunile succesive ale
sistemului sunt considerate drept cel mai important instrument de
achiziionare a cunotinelor de care dispun analitii. S-a constatat c ritmul
de achiziionare a cunotinelor se accelereaz dup construirea primei
versiuni a sistemului. O variant operaional, chiar imperfect a sistemului
produce o mbuntire a mediului de lucru n procesul achiziionrii
cunotinelor, mediu care devine mai structurat i stimuleaz astfel procesele
de exprimare, formalizare a cunotinelor.

1.7.2 Metodologii de realizare a sistemelor expert

Metodologia ORSA

36
 ORSA (Operational Research and Systems Analysis) reprezint o
metodologie care pornete de la obiectivele generale ale unitii n care
urmeaz s funcioneze sistemul, ncercnd s realizeze transformarea
acestora n cerine pentru realizarea sistemului. Activitile principale de
realizare a unui sistem inteligent, aa cum sunt ele susinute de ctre
metodologia ORSA sunt prezentate n figura 2.
Principalele etape de realizare a unui sistem inteligent, conform
metodologiei ORSA sunt:

definirea problemei (iniial, o definire nestructurat);

investigarea problemei;
dezvoltarea definiiei /definiiilor rdcinii sistemului;
utilizarea modelelor conceptuale n crearea sistemului abstract;
compararea modelului abstract cu cel real;
identificarea modificrilor desirabile i posibile;
iniierea rezolvrii problemei sau, cel puin mbuntirea definirii
problemei.

Primele dou etape au ca obiectiv formularea unei/unor descrieri

detaliate a problemei. Aceast descriere este de cele mai multe ori o schem
(diagram)care poate fi construit gradat, rafinat dac este necesar. Se
recomand ca aceast descriere s includ att elemente de structur, ct i
procese, dinamice, ca s se poat forma un punct de vedere despre cum se
manifest acestea ntr-un caz sau altul.
Etapa a treia esenial avnd drept scop elaborarea (fundamentarea)
rdcinii sistemului. Definiia rdcinii reprezint o declaraie n legtur cu
ce este sistemul sau mai exact cu ceea ce trebuie s realizeze sistemul prin
perspectiva viziunii asupra lumii considerate.

Problema Aciune
Lumea
reala 1 7

Structurare Comparare Modificri

problem model-sistem posibile
real
6
5
2

Sistem
Definire
rdcin Creare model ideal
sistem conceptual
37
4
3
 Fig. 1.8. - Schema general de lucru n cadrul metodologiei
ORSA

Pentru a facilita analiza corectitudinii definiiei rdcinii, Checkland

P. a creat mnemonica CATWOE.

C (Customer) Ce este utilizatorul, pentru cine acioneaz sistemul?

A (Actors) Cine ndeplinete principalele aciuni din sistem?
T (Transformation) Care este activitatea fundamental desfurat n
sistem?
W (Wetanschaung) Care este perspectiva care face aceast definiie s
fie
fundamental?
O (Owners) Care sunt persoanele care decid asupra existenei
sistemului?
E (Environment) Care sunt limitele sistemului?

Obiectivul etapei a patra este obinerea modelului conceptual al sistemului.

Pentru aceasta se expandeaz definiia rdcinii, obinndu-se un set de
activiti minim necesare pe care sistemul trebuie s le efectueze. n etapele
urmtoare, modelul conceptual este comparat, din punct de vedere al
performanei cu sistemul real. Se verific pe de o parte corectitudinea
modelului, i concomitent se ncearc identificarea schimbrilor de structur
care s amelioreze sistemul.
n ultima etap sunt puse n aplicare, n mod efectiv modificrile
considerate ca desirabile i realizabile. Aceste modificri se efectueaz pe
baza unui plan de implementare adecvat. Dup efectuarea modificrilor se
testeaz comportamentul sistemului, n scopul determinrii efectelor acestor
modificri, procesul de realizare a sistemului putndu-se relua sau opri.

Metodologia RUDE

38
 Metodologia RUDE (Run-Understand-Debug-Edit) este elaborat de
D.Partridge, pe baza analizei comparative a sistemelor inteligente i a celor
convenionale. Conform lui Partridge, sistemele inteligente nu pot fi
realizate pe baza modelului problemei complet formulate, ca n cazul
ingineriei software convenionale. Schematic, metodologia RUDE este
prezentat n figura 1.9.

Versiunea N

R Execuie
EXPERT

Versiunea N

U nelegere

Versiunea N
ANALIST
D Depanare

Versiunea N
E Editare

Versiunea N+1
N N+1

Fig. 1.9. Ciclul RUDE

Patridge subliniaz necesitatea mbuntirii acestei metodologii, prin

crearea unor derivate metodologice riguros fundamentate i robuste, care s
poat fi utilizate n realizarea de sisteme inteligente comerciale. RUDE
reprezint o perspectiv exploratorie n construirea de sisteme inteligente.
Este necesar ns o metod de construire a unui sistem iniial, de la care s
se porneasc aplicarea ciclului RUDE. De asemenea sunt necesare forme de
control a procesului iterativ, precum i ncorporarea acestora ntr-un mediu
de lucru structurat.

Metodologia POLITE

39
Metodologia POLITE (Produce Objective-Logical/Physical Design
Implement-Test-Edit) a fost definit pe baza metodologiei RUDE. Figura 4.
prezint principalele etape din cadrul POLITE. De remarcat faptul c atunci
cnd este cazul, fiecare etap este prezentat att din punctul de vedere al
realizrii de componente software convenionale (stnga), ct i din punct de
vedere al realizrii de sisteme inteligente (dreapta). Acest lucru permite
utilizarea metodologiei n ambele domenii de realizare software.

1.7.3 Instrumente de realizare a sistemelor expert

Realizarea sistemelor expert presupune, n primul rnd achiziionarea

cunotinelor. Activitatea de achiziionare a cunotinelor se desfoar pe
parcursul ntregului proces de realizare a unui sistem bazat pe cunotine,
ncepnd din etapa studiului de fezabilitate i pn n etapa punerii n
funciune a sistemului.
Procesul de achiziionare a cunotinelor este realizat de ctre
informaticieni special pregtii pentru aplicarea diferitelor metode i tehnici
de reprezentare i utilizare a cunotinelor. n ncercarea de reducere a
pierderilor de informaii care nsoesc procesele de explicitare a
cunotinelor, se poate recurge la realizarea on-line a proceselor de inducere
a cunotinelor, cu ajutorul unor instrumente de achiziionare automat a
cunotinelor, precum sistemele de nvare automat, procesoare inteligente
de cuvinte, instrumente pentru proiectarea arborilor decizionali etc.
Diferitele instrumente de achiziionare automat a cunotinelor sunt
de regul realizate ca instrumente aplicabile unei game largi de sisteme
bazate pe cunotine. Realizatorii acestor sisteme pot adapta instrumentele
propriilor cerine, integrndu-se n cadrul unui model de achiziionare
automat a cunotinelor, parte component a sistemului bazat pe cunotine.

40
 FEZABILITATE
R
COSTURI/ BENEFICII U
D
E
ANALIZA
R ACHIZITIONARE
DATE U
D
SARCINI
E

PROIECTARE

FISIERE PROCEDURI R REPREZENTARE

U
LOGICA CUNOASTERE D
PROD.FIZICE E
MEDIU
FIZICA
IMPLEMENTARE

PROGRAME BAZA DE R
U
CUNOSTINTE D EXECUTIE
FISIERE INFERENTE E E

TESTARE
R
U
ACCEPTARE VALOARE D
E

INTRETINERE

R
GENERALIZARE ACTUALIZARE BAZA U
CUNOSTINTE D
DEZVOLTARE
E

EXTINDEREA ARIEI

Fig. 1.10 - Etape de realizare n cadrul metodologiei POLITE

n cadrul activitii de realizare a sistemului expert se pot utiliza

numeroase tipuri de instrumente software de codificare, ncrcare, utilizare
i actualizare a cunotinelor, precum:

a) medii de programare convenionale precum: C, FORTRAN,

PASCAL;
b) medii de programare specializate, precum: LISP, PROLOG;
c) toolkit-uri, precum: KEE ART;
d) generatoare de sisteme expert (shell-uri), precum: GURU, EXSYS,
H-EXPERT;
e) instrumente software specializate.

Dac instrumentele preferate la sfritul anilor '70 erau mediile de

programare specializate, i n principal LISP-ul, n anii '80 i mai ales n
prezent instrumentele software cel mai mult utilizate sunt generatoarele de

41
sisteme expert, dup cum reiese i din figura 5, n care este prezentat
distribuia utilizrii instrumentelor software n realizarea sistemelor expert la
sfritul anilor '80. Literele a-e din cadrul figurii semnific grupa de
instrumente, din enumerarea realizat anterior.
Selectarea unui anumit instrument software se realizeaz n cadrul
proiectelor de sisteme expert n funcie de numeroi factori, precum:
- disponibilitatea instrumentelor;
- abilitatea n utilizare anumitor instrumente;
- dimensiunea sistemului expert care trebuie realizat;
- tipul de sistem expert care urmeaz a fi realizat (de clasificare, de
configurare etc.);
- destinaia sistemului expert (asistent inteligent, expert etc.);
- modul de utilizare preconizat pentru sistemul expert (individual,
interconectat, integrat);
- tipul utilizatorilor sistemului expert i deci, intefeei utilizator care
trebuie asigurat (grafic, animaie, etc.);
- metoda de reprezentare a cunotinelor pe care trebuie s le suporte
sistemul expert;
- metodele de raionament pe care trebuie s le asigure sistemul
expert;
- performanele pe care trebuie s le prezinte sistemul n exploatare
(de
exemplu, funcionare n timp real);
-nivelul resurselor disponibile pentru realizarea sistemului expert sau
posibil de mobilizat, etc.

56%

23%

11% 10%
<1%

a b c d e

Fig. 1.11 Utilizarea instrumentelor software n proiectele de sisteme expert

42
1.7.3 Generatoare de sisteme expert
Generatoarele de sisteme expert constituie clasa de instrumente
software cu cea mai larg utilizare. Acestea reprezint sisteme software care
ofer realizatorilor de sisteme expert:

un cadru (un schelet) de sistem expert (de tipul unui sistem expert
generalizabil), n sensul c sunt puse la dispoziia realizatorilor, n form
generalizat toate componentele unui sistem expert, mai puin baza de
cunotine;
faciliti de realizare a sistemelor expert pe msur, personalizate,
pe baz componentelor preprogramate. Aceste faciliti se refer la:

-limbaj de comand pentru construirea bazei de cunotine;

-instrumente de control a raionamentelor;
-instrumente de personalizare a interfeelor sistemului, etc.

Generatorul de sisteme expert GURU.

Este realizat de Micro Data Base Systems Incorporation. Acest
generator de sisteme expert permite realizarea, testarea i implementarea
aplicaiilor de tip sistem expert de dimensiuni medii i mici. Pentru
asigurarea unui numr mare de faciliti, generatorul GURU ofer:
-un limbaj specializat pentru specificarea elementelor necesare
aplicaiilor
(schema de reprezentare a cunotinelor, stilul de realizare a
interaciunii
cu utilizatorul);
-editor pentru modificare elementelor aplicaiei;
-servicii (utilitare) pentru realizarea interfeei utilizator i a interfeei
cu
alte sisteme software, ntreinerea aplicaiilor, etc;
De asemenea, acest mediu de dezvoltare a sistemelor expert conine
mecanismul (motorul) de inferen, constructorul bazei de cunotine precum
i un program de consultare a aplicaiei, cu generare de explicaii att n

43
timpul consultrii aplicaiei ct i la terminarea consultrii. Generatorul
GURU mai dispune i de o serie de componente ce permit funcii de
prelucrare convenionale, respectiv:
- stocarea, gestionarea i prelucrarea eficient a datelor prin tabele de
calcul (spreadsheet) baze de date;
- generarea de grafice;
- comunicarea la distan prin modem;
- interpretare limbaj natural;
- execuia unor comenzi ale sistemului de operare fr a prsi mediul.
GURU reprezint deci un generator de sisteme expert ce reunete
avantajele instrumentelor software clasice (spreadsheet, baze de date, editor,
interpretor, etc.) oferind numeroase faciliti pentru dezvoltarea unor sisteme
expert eficiente cu un efort acceptabil i ntr-un timp relativ scurt.

Generatorul de sisteme expert H - EXPERT. Reprezint un instrument

dezvoltat n C, deci cu o bun portabilitate pe diferite tipuri de maini i
destinat realizrii de sisteme expert de dimensiuni mari:
Generatorul integreaz concepte ale programrii orientate obiect,
utiliznd conceptele de clas, obiecte, motenire multipl, demoni, etc.
Asigur o reprezentare ierarhic a bazei de cunotine, ceea ce face posibil
optimizarea timpilor de rspuns i o reprezentare a cunotinelor prin reguli.
Asigur interfee cu baze de date, spreadsheet-uri, limbaje generale.

Generatorul GOLDWORKS
Este un mediu de realizare a sistemelor expert care integreaz tehnici
de realizare a sistemelor ce depesc pe cele ale mediilor convenionale de
dezvoltare se sisteme.
Productorul generatorului este Gold Hill, Inc. Platforma hardware
este constituit din staii PC, cu minim 8 MB RAM. Toolkit-urile grafice
reclam i o serie de faciliti grafice, pentru a putea utiliza diferitele tipuri
de obiecte grafice. Platforma software este reprezentat de sistemul de
operare WINDOWS . Platforma limbaj de programare este GCLISP, cu
puterea limbajului COMMON LISP.

1.7.4 Realizarea sistemelor expert prin prototipizare

Realizarea unui sistem expert prin prototipizare presupune

parcurgerea urmtoarele etape:
studiul de fezabilitate;
proiectarea sistemului;

44
 realizarea versiunilor de prototip ale sistemului;
punerea n funciune a sistemului;
exploatarea i ntreinerea sistemului.
Se vor analiza pe rnd aceste etape, cu referire la coninutul i la
modul de desfurare a diferitelor activiti.

Studiul de fezabilitate

Studiul de fezabilitate se realizeaz n general n dou faze i anume:

studiul preliminar de fezabilitate;
studiul propriu-zis de fezabilitate.
Separarea n cele dou faze este util, ntruct prin utilizarea unor euristici
se poate realiza estimare a gradului de fezabilitate a sistemului, cu un efort
relativ sczut de investigare i analiz a domeniului. Numai n situaia n
care concluziile primei faze sunt ncurajatoare se va depune efortul
sistematic de investigare i de analiz a domeniul vizat, n scopul stabilirii
precise a condiiilor de fezabilitate tehnic, economic i operaional a
sistemului.

Organizarea procesului de iniiere a proiectului

Presupune n principal formarea echipei de realizare a sistemului,

precum i identificarea principalelor categorii de personal implicat n
derularea proiectului.
Echipa de realizare este format, de regul dintr-un numr redus de
persoane (5-6), pentru asigurarea omogenitii stilului de lucru, coordonrii
eficient a activitii, concomitent cu schimbul util de idei. n cadrul echipei
sunt inclui eful proiectului, analiti de cunotine, precum i programatori.
Din echip este necesar s fac parte un reprezentant al conducerii instituiei
beneficiare, care s aib rolul de a susine proiectul, n mod competent i n
cunotin de cauz, n cadrul diferitelor sisteme de decizie local sau din
exteriorul instituiei.
Studiul preliminar de fezabilitate (fig.1.12)
Are drept scop determinarea, cu ajutorul unor criterii simple a
fezabilitii sistemelui expert. Criteriile de apreciere a fezabilitii sistemelor
expert se pot grupa n:
criterii de ordin tehnic, precum:
- existena unor soluii algoritmice clasice;
- buna delimitare a domeniului;
- tipul de expertiz;

45
 - timpul afectat realizrii sistemelor;
- volumul i complexitatea cunotinelor;
- disponibilitatea expertizei;
- caracteristicile de interfa impuse.
criterii de ordin economic:
- disponibilitatea resurselor;
- costurile estimate;
- efectele scontate.
criterii de ordin cultural, privind nivelul de receptivitate i de acceptare
a
noii tehnologii.
Toate aceste criterii sunt utilizate cu ajutorul unei tehnici de scoring, care
realizeaz combinarea lor n raport de importana acordat fiecrui criteriu n
parte, ntr-un calificativ unic.

Studiul propriu-zis de fezabilitate

O estimare riguroas a fezabilitii tehnice, economice i operaionale
nu se poate realiza n afara unei imagini, chiar i aproximative a soluiei de
realizare a sistemului. Soluia de realizare nu poate fi formulat fr a se
cunoate bine domeniul vizat. Se recomand formularea unor soluii
alternative, dintre care printr-o schem de selectare, s se aleag o soluie de
realizare a sistemului.

1.7.5 Proiectarea sistemului expert

Modul de desfurare a activitii de proiectare a unui sistem expert
este prezentat n figura 1.13.
Aspectele avute n vedere la proiectare sunt:
- sursele i tipurile cunotinelor;
- modul de reprezentare i de utilizare a cunotinelor;
- interfeele necesare;
- alegerea instrumentelor hardware i software.
Realizarea acestor activiti presupune continuarea i adncirea
analizei ncepute n etapa studiului de fezabilitate. Pe msur ce domeniul
este mai bine delimitat i cunoscut, analistul de cunotine mpreun cu
expertul n domeniu ncep s transfere expertiza ctre sistemul inteligent.
Transferul de cunotine este mai mult o art a implementrii bazelor de
cunotine (knowledge-base crafting), dect o tehnic. Acest transfer se
realizeaz prin identificarea i reinerea cunotinelor din domeniu. Aceste

46
cunotine, care pot fi fapte, ipoteze sau reguli. Nu exist reete fixe pentru
identificarea cunotinelor, acest proces fiind incremental, existnd reveniri
frecvente i schimburi de informaii. Analistul posed cunotine referitoare
la metode, tehnici, instrumente folosite n construirea de sisteme inteligente,
iar expertul uman posed cunotine n domeniu, din experiena sa, din
pregtirea sa i de aceea este strict necesar ca cei doi s lucreze mpreun.

Fig. 6. Studiul de fezabilitate

47
 Organizarea procesului
de initiere a proiectului

Studiul preliminar
de fezabilitate
Evaluarea de ansamblu a oportunitatii
si a posibilitatilor de realizare a
sistemului expert

este oportuna Nu
si posibila realizarea
sistemelor
Raport de fezabilitate
cu propunerea opririi
Da proiectului

Studiul propriu-zis
de fezabilitate Investigarea si analiza
domeniului
domeniului

Determinarea cerintelor utilizatorilor

Determinarea limitelor si restrictiilor de realizare

Definirea unor solutii alternative

Selectarea solutiei de realizare

Realizarea unui proiect preliminar

pe baza solutiei adoptate

Estimarea fezabilitatii tehnice , economice

si opeationale a solutiei de realizare

Nu solutia
este fezabila

Da

Raport de fezabilitate
Raport de fezabilitate
cu propunerea de
cu propunerea opririi
continuare a
proiectului
proiectului

inaintarea raportului
de fezabilitate

48
 Fig.1.12 Studiu de fezabilitate a sistemelor EXPERT

Deoarece sistemul este proiectat destul de devreme n ciclul de dezvoltare,

imediat dup studiul de fezabilitate, rezultatele ulterioare vor suferi
schimbri cu o mare probabilitate, innd cont de cerinele ce au stat la baza
proiectrii. De aici rezult c proiectul va fi revzut periodic i adaptat n
pai succesivi.
Un prim rezultat al etapei de proiectare este o machet preliminar
(premacheta) de sistem. Este prima form a proiectului, din care se pot
trage primele concluzii. Aceste concluzii sunt foarte utile pentru dezvoltarea
n continuare a sistemului. n cadrul proiectrii are loc o rafinare a
premachetei. n fapt, aceast rafinare se realizeaz prin actualizarea
faptelor/regulilor (nlturarea unor fapte/reguli care nu corespund,
modificarea unor fapte/reguli existente conform unor noi cerine, adugarea
unor noi fapte/reguli. n etapa de dezvoltare a premachetei se continu, de
fapt partea cea mai important din cadrul procesului de realizare a unui
sistem expert i anume achiziionarea cunotinelor ce vor alctui n final
baza de cunotine a sistemului.

Revederea proiectului
preliminar

Rafinarea
proiectului

Evaluarea
proiectului

Nu
OK

Da

Realizarea
documentatiei
de proiect

Documentatia
de proiect

49
 Fig. 1.13. Proiectarea unui sistem expert

Se ajunge n final la macheta funcional a sistemului respectiv.

Cerinele care genereaz achiziionarea de cunotine i dezvoltarea
machetei sunt:
-cerinele conducerii (legate de costuri, beneficii, utilizare);
-cerinele experilor (limitele domeniului aplicaiei, completitudinea
bazei de cunotine, corectitudinea raionamentelor);
-cerinele utilizatorilor (cum ar dori s se realizeze interfaa cu
sistemul);
-cerinele realizatorilor (utilizarea anumitor instrumente de lucru,
folosirea anumitor metode i tehnici, cunoscute de ctre utilizatori =).
Cerinele sunt evaluate i pe baza lor echipa de realizare dezvolt
machetele de sistem, ce urmeaz la rndul lor s fie testate i evaluate n
cadrul etapei urmtoare.

1.7.6 Realizarea versiunilor de prototip

Coninutul acestei etape este prezentat n figura 1.14.

50
 Pregatirea prototiparii

Realizarea prototipului
initial

Evaluarea prototipului
initial

Realizarea unei noi

versiuni de prototip

Evaluarea versiunii
de prototip

Nu
OK

Da

Realizarea documentatiei
aferente prototipului
final

Documentatia
de prototip

Fig.1.14 Realizarea versiunilor de prototip

Realizarea prototipurilor presupune parcurgerea urmtoarelor etape:

-elaborarea unei versiuni operaionale initiale a sistemului (prototipul
iniial).
Aceast versiune va fi folosit ca instrument de lucru pentru realizarea
versiunilor ulterioare.
-elaborarea unor versiuni intermediare ale sistemului (prototipurile
intermediare) prin rafinri, detalieri succesive. Numrul de versiuni
intermediare este n funcie de complexitatea sistemului.
-elaborarea versiunii finale a sistemului ( prototipul final).
n cadrul fiecrei etape, se realizeaz:
-achiziionarea i codificarea cunotinelor conform modului de reprezentare
i a

51
 structurii stabilite n etapa de proiectare general.
-codificarea (programarea) mecanismelor de raionament (realizarea
motorului
de inferen sau completri la acesta).
-codificarea (programarea) celorlalte componente ale sistemului sau detalieri
ale
acestora.
Coninutul fiecrei etape este stabilit n funcie de strategia de
prototipizare utilizat.
Trecerea de la o etap la alta, practic de la o versiune de prototip la
alta, este condiionat, dirijat de ctre activitatea de evaluare a realizrilor
obinute n cadrul unei anumite etape ( evaluarea versiunilor de prototip ).
n cele ce urmeaz se vor prezenta principalele strategii de
prototipare, precum i problemele pe care le ridic activitatea de evaluare a
versiunilor de prototip.

Strategii de prototipizare
n activitatea de realizare a versiunilor de prototip se pot utiliza
urmtoarele strategii de prototipizare:
-Construirea unor versiuni de prototip care s acopere ntregul sistem.
Aceast
strategie se poate aplica n cazul unor sisteme expert de dimensiuni mici,
pentru care evaluarea, dezvoltarea i rafinarea ulterioar se pot realiza
relative
uor. Trecerea la versiunile succesive de prototip se realizeaz prin
determinarea inconsistenelor, erorilor i omisiunilor care vor fi rezolvate
n
fazele (etapele) urmtoare. Schimbrile sunt efectuate pe rnd, fiind
necesar o
ierarhizare dup prioriti. Fiecare nou versiune de prototip elimin i
adaug
totodat noi cerine de schimbare a prototipului. n funcie de mrimea i
complexitatea sistemului, un prototip acceptabil (care s poat fi
considerat
drept prototip final al sistemului) poate fi obinut dup 4-7 versiuni
intermediare.
-Construirea unui schelet general al sistemului i realizarea n cadrul
versiunii
iniiale de prototip numai a ctorva dintre componentele sistemului.

52
 Transformarea versiunii iniiale de prototip n versiuni ulterioare
(intermediare
i finale) se realizeaz prin completarea treptat a prototipului cu restul
componentelor. Noile componente sunt testate n contextul ntregului
sistem,
dup integrarea lor cu restul componentelor. Aceast strategie de
prototipizare
se uitlizeaz n cazul sistemelor de dimensiuni mari. Scheletul general al
sistemului reprezint structura complet a sistemului, dar far prezena
detaliilor. De exemplu, n cazul reprezentrii cunotinelor prin reguli,
scheletul ar putea cuprinde programele de control pentru selectarea
diferitelor
seturi de reguli, setul de variabile utilizate n cadrul regulilor, principalele
categorii de reguli (fr detalierea acestora).Componentele ulterioare se
pot
realiza serial sau n paralel. Dup obinerea prototipului final sunt necesare
cteva iteraii suplimentare pentru testarea sistemului n ansamblu.
-Construirea de componente de prototip separate, testarea independent a
acestora i integrarea lor ntr-un prototip final. Aceast strategie se
utilizeaz
n special n cazul n care sistemul are la baz surse relativ independente de
cunotine expert, ce acoper domenii tiinifice distincte, separate.
Prototipizarea presupune n acest caz realizarea, testarea i rafinarea
fiecrei
componente n mod separat, ntr-o activitate desfurat n paralel.
Dificultatea
major ntimpinat la utilizarea acestei strategii const n realizarea
integrrii
finale a componentelor. Aceast strategie se preteaz n cazul sistemelor de
dimensiuni mari.

Evaluarea versiunilor de prototip

Evaluarea versiunilor de prototip ale sistemului presupune:
testarea versiunii de prototip, pentru a se stabili dac versiunea
satisface
specificaiile formulate, altfel spus dac realizeaz ceea ce se dorete.
Obiectivele testrii sunt:
verificarea completitudinii variantei de prototip. Se verific
dac versiunea este complet, n sensul c prezint un mecanism

53
 pentru tratarea tuturor valorilor posibile pentru toi parametrii de
intrare.
testarea consistenei i robusteii . Se verific modul n care
sunt integrate diferitele componente ale versiunii de prototip, dac
acestea comunic n mod corespunztor unele cu altele. Totodat,
n legatur cu robusteea prototipului se stabilete msura n care
prototipul este apt s continue s produc ieiri corecte n condiiile
degradrii intrrilor. Cu ct prototipul i menine performanele
mai mult timp, cu att este mai robust.
verificarea independenei fa de ordine a cunotinelor
neprocedurale. De obicei, exist tendina de introducere a
informaiilor de control procedural n cadrul cunotinelor, care n
mod normal ar trebui s fie declarative.

Tehnicile de testare utilizate n cadrul activitii de prototipizare sunt:

utilizarea cazurilor de test;
trasarea execuiei;
utilizarea unor funcii de control a consistenei;
varierea ordinii de activare a regulilor etc.
depanarea versiunii de prototip, care nseamn determinarea
cauzelor pentru care versiunea de prototip nu satisface specificaiile
formulate. Pentru depanare se pot utiliza:
tehnicile clasice de depanare ( de exemplu trasarea
execuiei);
facilitile explicative ale versiunii de prototip.
validarea versiunii de prototip, care presupune stabilirea gradului
n care versiunea de prototip satisface cerinele diferitelor categorii de
persoane implicate n realizarea i utilizarea sistemului. Dei se apropie
ntructva de activitatea de testare a versiunii de prototip, validarea
urmarete n principal aspectele legate de utilizarea sistemului de ctre
utilizatorii finali, deci de performanele n exploatare i mai puin
problemele de ordin tehnic, privind realizarea sistemului. Autoritatea de
validare o dein att realizatorii, ct i utilizatorii finali, experii i
conducerea organizaiei beneficiare.

54
1.7.6 Punerea n funciune a sistemului expert
Activitile din cadrul acestei etape sunt prezentate n figura 1.15.

55
 Analiza bazei de cunostinte
a prototipului final

Realizarea translatarii
prototipului final in mediul
de exploatare

Testarea versiunii de sistem

obtinuta in urma translatarii

OK

Testarea si evaluarea sistemului in

conditii de functionare curenta
(etapa I de experimentare)

OK

Rafinarea
sistemului

Testarea sistemului de catre

utilizatorii reali
(etapa II de experimentare)

OK

Rafinarea
sistemului

Realizarea documentatiei de
sistem si pregatirea conditiilor
pentru trecerea sistemului in
exploatare curenta si
intretinere

Fig. 1.15.Punerea n funciune a sistemului expert

56
 Este etapa n care sistemele sunt tratate ntr-o manier tot mai
dependent de utilizarea lor efectiv. Etapa trebuie s asigure condiiile ca
sistemele s poat rezolva problemele reale ale utilizatorilor, ca utilizatorii
s poat interaciona direct cu sistemul i s fie posibil atingerea
performanelor propuse. Analiza se realizeaz pe un hardware i un software
real, pe cele pe care va funciona sistemul, pe baza unor probleme reale din
cadrul domeniului, cu un personal selectat dintre cei ce au proiectat i cei ce
vor utiliza sistemul inteligent. Observaiile care se desprind n aceast etap,
formulate de beneficiari sau deduse de proiectant, conduc la o evaluare a
sistemului i, implicit la decizia de a se relua etapele anterioare pentru
corectarea erorilor sau de a se da n exploatare sistemul. Dac prototipul s-a
dezvoltat pe staii specializate de inteligen artificial sau pe
microcalculatoare mai puternice dect cele pe care vor lucra utilizatorii,
sistemul se mut pe calculatoarele pe care se va realiza exploatarea.
Versiunea obinut prin translatare se testeaz extensiv, pentru a se
verifica completitudinea i corectitudinea bazei de cunotine i a
raionamentului aferent, realizarea cerinelor beneficiarului, funcionarea n
ansamblu a interfeelor, realizarea scopurilor proiectului. Odat cu punerea
n funciune a sistemului expert se realizeaz:
-documentaiile aferente care se refer la modul de utilizare
(instruciuni, specificaii, cerine etc.), realizarea tehnic (componente de
sistem, caracteristici tehnice, faciliti, limite);
-instruirea personalului asupra modului de utilizare i ntreinere a
sistemului, consultan tehnic pentru exploatare;

1.7.7 Exploatarea curent i ntreinerea sistemelui expert

Este etapa n care sistemul expert este operaional, fiind utilizat n

mod curent de ctre beneficiar. Meninerea sistemului n exploatare
presupune dezvoltarea sistemului cu elemente noi ce apar n domeniu,
adugarea de noi faciliti (de execuie, de utilizare, interfee etc.).

57