Windows Phone

Diverse2

Windows Phone

Byadmin ianuarie 1, 2024

LUCRARE DE LICENȚĂ

Sistem suport de decizie dezvoltat pe „Windows Phone”

Cuprins

Introducere

Capitolul 1. Sistemele expert

Ce sunt sistemele expert și de ce este nevoie de ele

Structura generală a unui sistem expert

Achiziția de cunoștințe din domeniul de expertiză

Alegerea strategiilor de căutare

Sisteme expert cunoscute

Capitolul 2. Diagnoza și modul în care se execută

Ce este diagnoza

Moduri de abordare a unei probleme de diagnoză

Tipuri de cunoștințe folosite în sistemele de diagnoză

Asemănarea cu diagnosticul uman

Capitolul 3. Mediul Microsoft Visual Studio Express for

Windows Phone și implementarea sistemului expert

de diagnoză a calculatorului personal

Mediul de programare Microsoft Visual Expres for Windows Phone

Reprezentarea cunoștințelor în mediul Microsoft Visual Studio Expres For Windows Phone

Descrierea aplicației generalizată, arborele de decizie

Descrierea fișierelor .xaml

Structura generală a sistemului expert

Proiectarea bazei de date

Scenarii de utilizare a sistemului expert

Capitolul 4. Concluzii, recomandări și direcții de dezvoltare

Anexe:

Anexa nr.1 Pagina de start a aplicației

Anexa nr.2 Imprimantă.xaml

Anexa nr.3 Problema 1 aferentă componentei Imprimantă

Anexa nr.4 Interiorul butonului Afișează

Bibliografie

Introducere

fera de aplicare a inteligenței artificiale este fară îndoială

din ce în ce mai vastă. Un loc foarte impotant în această

sferă a fost și este ocupat de sistemele expert. Pentru a întelege exact noțiunea de sistem expert să consideram diferența dintre reprezentarea unui specialist și cea a unui nespecialist asupra unui lucru sau fenomen. Diferența constă în principal în gradul de complexitate a sistemului și în felul în care sunt sistematizate cunoștițele privitoare la acesta.

Pentru un specialist, cunoștințele despre un fenomen sunt organizate, precise, punctuale și sistematizate. Antitetic, cunoștințele unui nespecialist despre același fapt sunt globale și nestructurate. Acest lucru se întamplă deoarece pe măsura ce se aprofundează un domeniu, conceptele specifice se rafinează iar conexiunile care se stabilesc între acestea devin mai specifice.

Mai mereu în activitatea pe care o desfășurăm se ivește să întâmpinăm probleme de tot felul și pentru rezolvarea cărora să fie nevoie de un expert uman. Aici intervine o problemă și aceea că expertul uman nu este și nu va putea niciodată să fie prezent de fiecare dată când se ivește o problemă.

Pentru a evita aceste situații în care este nevoie de ajutor și nimeni dintre aceia care îl pot da nu este disponibil, în ajutor au venit sistemele expert. Un sistem expert cu o bază mare de cunoștințe poate în multe situații egala sau chiar depași performanțele unui expert uman.

Niciodată nu s-a încearct găsirea unui calculator să gândească exact ca omul ci într-un context și un mediu bine definit comportamentul său sa fie analog cu cel al omului.

Consider ca majoritatea dintre noi întâmpinăm probleme cu calculatorul, de aceea crearea unei astfel de aplicții pe o platformă mobilă este bine venită, aceasta putând beneficia de un set de probleme și răspunsuri predefinite iar având conexiune la internet numărul problemelor și răspunsurilor fiind mai mare considerabil. Astfel, întâmpinând o problemă cu o anumită componentă și ne având conexiune la internet, dar beneficiind de un dispozitiv mobil cu aplicația instalată, putem găsi raspunsuri la multe probleme.

Sistemul de diagnoză a unui calculator dezvoltat pe platforma Microsoft Visual Studio Express for Windows Phone are în vedere diagnosticarea unor probleme pe care le întâmpinăm zi de zi a anumitor componente si anume: unitate centrală, tastatură, mouse, imprimantă și monitor, care încearcă să le rezolve cât se poate de bine.

Problemele calculatoarelor nu se lasă asteptate și apar când ne asteptăm mai puțin, iar mulți dintre noi nu știm să rezolvăm problema, această aplicație este bine venită deoarece vrea sa acopere o gamă cât mai mare de probleme. Populată cu cât mai multe informații, utilizatorii pot găsi raspuns la întrebarile pe care le au în legătură cu problema respectivă.

Lucrarea este structurată astfel: capitolul 1 îl reprezintă sistemele expert, cu informații referitoare la structura generală, achiziția de cunoștințe, alegerea strategiilor de căutare și unele sisteme expert celebre.

Capitolul 2 este alcătuit din tipurile de cunoștințe folosite în sistemele de diagnoză, modurile de abordare unei probleme și asemănarea cu diagnosticul uman.

Capitolul 3 fiind format din mediul de programare Microsoft Visual Studio Express for Windows Phone, reprezentarea cunoștințelor, explicarea arborelui de decizie și explicarea pe larg a sistemului expert de diagnoză a calculatorului.

Sistemele expert

Sistemele expert sunt produse ale inteligenței artificiale, ramură a științei calculatoarelor ce urmărește dezvoltarea de programe inteligente. Ceea ce este remarcabil pentru sistemele expert, este aria de aplicabilitate ce a cuprins multe domenii de activitate de la arhitectură, arheologie, bănci, comerț, educație, până la ingineria sistemelor și medicină (CÂRSTOIU 1997, 6).

Într-o definițtie tradițională, un program este reprezentat sub forma următoarei ecuații:

program = algoritm + structură de date

În cazul unui sistem expert, definiția se modifică astfel:

sistem expert= cunoștințe + motor de inferență

Încercând să imite expertul uman, sistemul expert se caracterizează prin:

noțiunile sunt independente de mecanismul de raționament – nu depind unele de altele, iar modificarea unui element nu influențează raționamentul;

sistemul expert se caracterizează printr-o abordare declarativă în care se specifică cunostințele, care vor fi exploatate în mod separat față de mecanismul de raționament;

sistemul expert trebuie să fie apt să explice raționamentele făcute și să argumenteze rezultatele obținute într-o manieră asemănătoare expertului uman , dându-i voie astfel utilizatorului să studieze rezultatul și eventual să îl controleze;

cunoștințele manipulate de sistemele expert sunt în principal de natură simbolică spre deosebire de programele clasice care utilizeaza majoritar date numerice;

sistemul expert trebuie să poată gestiona baze de cunoștințe de volum mare și să trateze soluții și cunoștințe inexacte și incomplete;

sistemul expert utilizează metode empirice (pozitive), care se bazează strict pe experiență și care conduc la soluțiile cele mai bune;

sistemul expert este specializat într-un întreg domeniu și nu în rezolvarea unei singure probleme;

Un sistem expert trebuie să îndeplinească anumite cerințe:

înaltă performanță – sistemul trebuie să fie la un nivel egal sau mai bun decât un expert în domeniu;

răspuns de timp adecvat – sistemul trebuie să ia o decizie într-un timp destul de echilibrat, comparabil sau mai bun decât timpul necesar expertului uman pentru a lua decizia;

siguranța – sistemul trebuie să fie sigur, să nu determine erori în funcționare;

flexibilitate – pentru că sistemul conține o cantitate mare de informații este important să se implementeze un mecanism eficient pentru adăugare, modificare și ștergere a cunoștințelor;

Sistemele expert au fost construite pentru a mări capabilitățile umane în

rezolvarea anumitor probleme cum ar fi:

informația nu se pierde și nu se uită niciodată să se aplice sursele de cunoaștere internă nici când lipsesc datele problemei furnizate de lumea exterioară;

sunt mult mai rapide în raspunsuri decât experții umani atunci când răspunsul trebuie să fie în timp real, sau când se vrea răspunsul la mai multe soluții în același timp;

sunt competente să proceseze simultan o vastă arie de informații și găsesc o soluție optimă și foarte rapidă, în timp ce experții umani se pierd în detalii;

nu se repetă greșeala sistemului, dacă eroarea este urmarită și depistată la timp de responsabilul sistemului, atunci ea este corectată imediat. Se mai întâmplă uneori când sistemele greșesc datorită cunoașterii umane incomplete sau expertizelor eronate introduse în baza de cunoștințe a sistemului;

sunt capabile să urmeze un lanț lung și complicat de raționament, în care în mod obișnuit un om ar eșua;

1.2 Structura generală a unui sistem expert

În componența oricărui sistem expert intră o bază de cunoștințe, un modul rezolutiv și o interfața cu utilizatorul.

Reprezentarea generală a unui sistem expert este cea din figura 1.2.1

fapte

expertiză

Figura 1.2.1. Reprezentarea generală a unui sistem expert

Un sistem expert trebuie să conțină obligatoriu trei module principale, care formează așa numitul sistem expert, și anume: baza de cunoștințe, motorul de inferență și baza de fapte.

Baza de cunoștințe este constituită din ansamblul de cunoștințe specializate într-un anumit domeniu preluate de inginerul de cunoștințe (specilistul care va face legatura între expert și sistemul expert). Cunoștințele stocate aici sunt în principal descrierile obiectelor și ale relațiilor dintre acestea. Baza de cunoștințe face parte din sistemul cognitiv, cunoașterea fiind memorată într-un spațiu special organizat. Forma de stocare trebuie să asigure căutarea pieselor de cunoaștere specificate direct prin simboluri identificatoare sau indirect, prin inferențe care pornesc de la alte piese de cunoaștere;

Motorul (mecanismul) de inferențe este elementul efectiv de prelucrare în sistemele expert, care, pornind de la fapte (datele de intrare a problemei), activează cunoștințele din baza de cunoștințe, construind raționamente care conduc astfel la noi fapte (de iesire). Deși mecanismul de inferență este constituit dintr-un ansamblu de proceduri în sensul obișnuit al termenului, modul în care utilizează cunoștințele nu este prevăzut prin program, ci depinde de cunoștințele pe care le are la dispoziție.

Baza de fapte mai este denumită și memoria de lucru a sistemului. Reprezintă o memorie auxiliară care conține toate datele utilizatorului (faptele inițiale care descriu enunțul problemei de rezolvat). În unele publicații baza de fapte este inclusă în baza de cunoștințe, totuși, trebuie facută distincție între cunoștințele care descriu rezolvarea unei probleme și fapte, care descriu afirmații de instanțiere a unei probleme din clasa respectivă.

În funcție de domeniul în care se utilizează și de condițiile de exploatare, faptele pot fi introduse în sistemul expert prin urmatoarele căi:

Prin tastare la terminal, înaintea declanșării procesului de raționament;

În cursul procesului de raționament, prin chestionarea utilizatorului;

Prin consultarea unei baze de date proprii;

Prin preluarea directă de la diverși senzori;

Un sistem expert conține și o serie de module ce asigură comunicarea cu operatorul și expertul uman, prezentate în figura urmatoare:

Achizitia de Reprezentarea Tratarea Utilizarea

cunoștințe cunoștințelor cunoștințelor cunoștințelor

Figura 1.2.2. Comunicarea cu operatorul și operatorul uman

Modulul de achiziție a cunoștințelor are rolul de a transforma cunoștințele din forma în care le exprimă inginerul de cunoștințe în forma internă de memorare suport. Asigură și interfața de comunicare cu baza de date și alte sisteme, verifică validitatea lor (a cunoștințelor) și generează în final o bază de cunoștințe coerentă.

Interfața cu utilizatorul este dată de dialogul sistemului expert cu utilizatorul, în sensul specificării “problemelor” și furnizării “rezultatelor”.

Interfața între utilizator și sistemul expert trebuie sa îndeplinescă urmatoarele funcții [GUGA, 98]:

să ofere diverse opțiuni prin meniuri;

să ofere un limbaj adecvat utilizatorului prin întrebări, comenzi și comentarii;

să poată afișa rapid grafice, animații, etc;

să permită intervenția rapidă și facilă a utilizatorului în orice etapă;

limbajul de comunicare să fie cât mai apropiat de cel uman;

să țină cont de erorile umane, sa prevină și să afișeze cât mai multe mesaje de eroare;

formatarea ecranulu, prezentate în figura urmatoare:

Achizitia de Reprezentarea Tratarea Utilizarea

cunoștințe cunoștințelor cunoștințelor cunoștințelor

Figura 1.2.2. Comunicarea cu operatorul și operatorul uman

Modulul de achiziție a cunoștințelor are rolul de a transforma cunoștințele din forma în care le exprimă inginerul de cunoștințe în forma internă de memorare suport. Asigură și interfața de comunicare cu baza de date și alte sisteme, verifică validitatea lor (a cunoștințelor) și generează în final o bază de cunoștințe coerentă.

Interfața cu utilizatorul este dată de dialogul sistemului expert cu utilizatorul, în sensul specificării “problemelor” și furnizării “rezultatelor”.

Interfața între utilizator și sistemul expert trebuie sa îndeplinescă urmatoarele funcții [GUGA, 98]:

să ofere diverse opțiuni prin meniuri;

să ofere un limbaj adecvat utilizatorului prin întrebări, comenzi și comentarii;

să poată afișa rapid grafice, animații, etc;

să permită intervenția rapidă și facilă a utilizatorului în orice etapă;

limbajul de comunicare să fie cât mai apropiat de cel uman;

să țină cont de erorile umane, sa prevină și să afișeze cât mai multe mesaje de eroare;

formatarea ecranului să fie cât mai convenabilă utilizatorului;

Modulul de explicare are rolul de a prezenta un limbaj natural, justificarea raționamentelor efectuate de motorul de infereță și totodată întrebările la care trebuie să raspundă utilizatorul. El ajută expertul să verifice consistența bazei de cunoștințe.

În funcție de aplicția pentru care este construit, structura efectivă a unui sistem expert poate fi diferită de structura standard. De exemplu faptele inițiale pot fi achiziționate atât de utilizator cât și de la un echipament de conducere automatizat.

Sunt trei probleme de bază și complicate pe care proiectantul unui sistem expert trebuie să le rezolve:

Achiziția cunoștințelor – etapa prin care se evidențiază principalele idei de cunoaștere din domeniul expertizei. Ideile trebuie să provină de la experți umani, din rapoarte tehnice, științifice, studii de caz, etc;

Arhitectura sistemului – acesta trebuie să reflecte caracteristicile clasei de probleme pe care sistemul expert trebuie să o rezolve;

Interfața cu sistemul – sistemul inteligent trebuie să manifeste o comportare inteligentă față de utilizatori, nu numai furnizandu-le informații ci oferind și explicații și argumentări.

Figura 1.2.3. Schema completă a unui sistem expert

Componentele unui sistem expert constituie subsisteme care pot fi tratate și elaborate separat după aceleași principii de proiectare dar care trebuie să lucreze împreună.

Arhitectura de reprezentare a cunoștințelor poate fi considerată ca fiind structură pe trei nivele:

Nivelu intern este alcătuit din schema internă ce descrie structura de stocare fizică a cunoștințelor în baza de cunoștințe. Aici sunt dscrise detaliile complete ale stocării, precum și modul de acces la cunoștințe;

Nivelul conceptual descrie în întregime structura întregii baze de cunoștințe, ascunzând detaliile legate de stocarea fizică. Aici descrierea bazei de cunoștințe se concentrează asupra descrierii entităților, tipurilor de date, relațiilor dintre ele și restricțiilor asociate;

Nivelul extern sau cel utilizator include o colecție de scheme externe ce descriu baza de cunoșțințe prin prisma diferiților utilizatori, fiecare descriind baza de cunoștințe prin prisma propriilor interese;

1.3. Achiziția de cunoștințe din domeniul de expertiză

Achiziționarea cunoașterii de la experții umani se face ca în figura următoare:

Cunoaștere structurata

și organizată

date cunoaștere

probleme concepte

întrebari soluții

Figura 1.3.1. Achiziționarea „cunoașterii” de la experți

Ca un sistem expert să funcționeze corect trebuie să respecte două reguli de baza:

Să nu fii propriul expert;

Să nu crezi tot ce spune expertul;

Performanța sistemului expert creat ar putea fi limitată de capacitatea hardware și software a calculatorului pe care este implementat și produsul final este strict dependent de talentul celui ce dezvoltă sistemul expert.

Adunarea cunoștințelor din domeniul de expertiză este reprezentată în următoarea figură:

Figura 1.3.2. Captarea cunoștințelor din domeniul de expertiză

Procesul de achiziționare a cunoștințelor are trei etape:

Explicare;

Capturare;

Organizare;

Explicațiile expertului uman reies din interviu, ce este cea mai indicată formă de achiziție a cunoașterii.

Stadiul de capturare se referă la procesul de documentare a obiectelor, relațiilor și acțiunilor care vor face parte din baza de cunoștințe.

Organizarea se referă la procesul de ordonare a cunoștințelor într-o formă în care să poată fi puse apoi în baza de cunoștințe.

Procesul de achiziție se poate desfășura după un model de explicare a cunoașterii propus de K.Panderson (1989). El este este compus din 3 părți:

Generarea ideilor de explicare;

Testarea ideilor;

Revizuirea și rafinarea ideilor;

Modelul este reprezentat in figura 1.3.3.

Problema analizată

Se definește un nou subiect

NU

DA

NU DA

Figura 1.3.3. Schema logică pentru achiziția de cunoștințe destinate unui sistem expert

Etapele achiziționării cunoștințelor sunt reprezentate în figura următoare:

Reformulare

Reproiectare

Ajustare

Iden- Conceptualizare Formalizare Implementare Validare

tificare

Cerințe Concepte Structură Piese de cunoaștere

Figura 1.3.4. Etapele achiziștiei de cunoștințe

1.4 Alegerea strategiilor de căutare

Alegerea modului de reprezentare a cunoștințelor în domeniul de expertiză este una dintre cele mai importante decizii pe care trebuie luate atunci când se dezvoltă un sistem expert.

Proiectarea dacă se face cu un generator de sisteme expert bazat pe reguli atunci se vor alege regulile ca primă modalitate de reprezentare a cunoașterii.

Raționamentul inductiv (backward) – motorul de inferențe pleacă de la un scop (problema de rezolvat, o soluție ipotetică, etc) care este descompus succesiv în sub-scopuri și sub-sub-scopuri, pâna se ajunge la primitive dovedite sau interogabile. Se pleacă de la o regulă ce are în partea dreaptă (concluzia), scopul urmărit și premisele acestei concluzii devin sub-scopuri ce urmează a fi dovedite în aceiași manieră.

Raționamentul deductiv (forward) – motorul de inferențe pornește de la faptele existente în baza de fapte și caută să dovedească un anumit scop.

În tabelul următor sunt prezentate principalele întrebări la care trebuie să se raspundă pentru o alegere corectă a raționamentului.

Raționamentul deductiv (înainte – forward chaining), în care se pleacă de la fapte și se caută un anumit scop sau obiectiv. Se spune că raționamentul deductive este dirijat de fapte.

Raționamentul inductiv (înapoi – backward chaining), în care se pornește de la un scop care este descompus succesiv în sub-scopuri până se ajunge la dovedirea lui. Acest tip de raționament este dirijat de scop.

Raționamentul mixt – în acest caz se fixează un scop, se determină toate faptele deductibile, se precizează faptele interogabile, apoi se aplică raționametul inductiv.

1.5 Sisteme expert celebre

Primul sistem expert a fost creat în 1965 numindu-se Dendral, fiind destinat analizei chimice spectroscopice a structurii moleculare. Sistemul a fost controlat de Edward Feigenbaum și laureatul premiului Nobel, geneticianul Joshua Lederberg.

În același an, 1965 Lotfi Zahed (natal din Azerbaidjan) pune bazele logicii fuzzy, care contrazice principiul terțului exclus, teoria a fost întâmpinată cu scepticism și ospitalitate, însă succesul aplicațiilor sale ulterioare a fost de necontestat. Joseph Weizenbaum și Kenneth Colby creează programul Eliza (psihologul computerizat) în 1966, care se dovedește a fi unul dintre cele mai celebre programe de inteligență artificială create vreodată. Programul conversează în limbaj natural, analizează frazele interlocutorului pentru a extrage cuvintele cheie și apoi afișează o replică selectată dintr-o mulțime de variante predefinite.

În 1970 a fost creat limbajul Prolog, ca rezultat al cercetărilor lui Alain Colmerauer, de la Universitatea din Marsilia, legate de formalizarea logică, ca bază a unui limbaj pentru prelucrarea limbajului natural, Prolog este cel mai utilizat limbaj de programare logică și declarativă și este intens utilizat pentru dezvolatarea aplicțiilor de inteligență artificială, fiind foarte util pentru dezvoltarea sistemelor expert.

Tot în 1970 Edward Shortlife propune la Universitatea din Standford sistemul Mycin, unul din cele mai renumite sisteme expert. Acesta era construit pentru a sugera diagnostice medicale, însa mulți medici nu erau siguri de exactitatea lui. De accea s-a adăugat modul Teiresias, care, răspunzând la comanda why?, putea justifica răspunsul prin afișarea regulilor, urmate și de concluzii.

În 1980 apare XCON, Expert Configurer devenit primul sistem expert utilizat pe scară largă din punct de vedere comercial. Scopul său era de a asista utilizatorii de calculatoare VAX în configurarea acestora, adică să determine ce schimbări erau necesare față de configurația standard de 50-100 de componente, astfel încât sistemul să fie complet și adecvat nevoilor utilizatorilor.

Se presupune ca în viitor, în jurul anilor 2030, calculatoarele vor egala din punct de vedere al complexității și puterii de procesare capacitățile omului.

Vise si temeri:

Case inteligente;

Roboți de familie conectați la internet;

Automobile autonome;

Educație personalizată;

Interfețe neuronale:

Nemurirea artificială;

Degradarea relațiilor social umane;

Diagnoza și modul în care se execută

2.1Ce este diagnoza?

Cuvântul “diagnoză” își găsește originea în grecescul diagnostokos și exprimă identificarea unui fenomen pe baza descrierii stării sale prezentate. Un exemplu poate fi: descrierea sumară a unei plante care o deosebește de alta. În termeni foarte generali, se consideră că diagnoza constă în a determina ceea ce nu este corect într-un sistem, adică identificarea cauzelor primare ale anomaliilor observate. Altfel spus diagnoza definește o metodă de identificare a naturii unei situații, prin interpretarea observațiilor exterioare.

Primul sistem expert dezvoltat cu succes a fost MYCIN a lui Shortlife în 1976, fiind unul de diagnoză. Domeniile sistemelor de diagnoză sunt foarte variate pornind de la cele industriale (determinarea defectelor circuitelor, diagnoza sistemelor mecanice, diagnoza sistemelor de automatizare, etc.) până la aplicații din domeniul medical, biologic, informatic etc.

Se pot distinge o serie de probleme comune pe care modelele de diagnoză trebuie să le rezolve:

Gândirea și interpretarea entităților problemei de diagnoză;

Existența unui defect unic sau unor defecte multiple;

Imprecizia măsurătorilor, incompletitudinea informației, incertitudinea relațiilor cauzale etc.

Rezolvarea problemelor amintite anterior a fost realizată prin dezvoltarea unor formalisme de reprezentare și de rezolvare, mai mult sau mai puțin generale. Se poate spune că metodele de abordare a problemelor de diagnoză au cunoscut o evoluție foarte interesantă. Pornind de la realizarea unor modele pur euristice, denumite și modele ad boc, care rezolvau probleme punctuale, concrete, tehnicile au evoluat până la dezvoltarea unor modele bine fundamentate teoretic, al căror nivel de generalitate permite adaptarea lor relativ ușoară la rezolvarea unor clase de probleme de diagnoză.

2.2. Moduri de abordarae a unei probleme de diagnoză

În prezent este cunoscută existența a două abordări distincte unei probleme de diagnoză:

Primul curent este cel a lui Reiter (1987) fiind de diagnoză bazat pe model. Acest curent a fost cunoscut sub numele de “diagnoză pornind de la primul principiu”. Denumirea sa este dată de faptul că metoda de diagnoză folosită este bazată pe modele de structură și comportament al sistemului, dezvoltate anterior de Davis și Genesreth în 1984. În această abordare modelul sistemului este cel de comportament nominal, exprimat prin formule ale logicii predicatelor de ordinul I. Extins apoi de Console în 1989 pentru a putea reprezenta modele cauzale profunde, care descriu funcționarea sistemului.

Cel de-al doilea curent corespunde unei altfel de abordări și anume abordare abductivă, în care modelul sistemului este unul defect. Reprezentarea modelelor se poate face prin formulele logicii predicatelor de ordinul I sau prin metode relaționale bazate pe teoria mulțimilor. Opusul abordării bazate pe coerență, abordarea abductivă tratează doar generarea explicațiilor. Ea exploatează relațiile cauzale dintre defect și constă în detectarea cauzelor, care acoperă observațiile curente

Tehnicile de raționament ale celor două abordări sunt următoarele:

Diagnoza bazată pe model folosește o tehnică bazată pe logică, al cărui obictiv este de a găsi mulțimea minimă de anomalii, astfel încât observațiile să fie logice cu o funcționare corectă și normală a celorlalte componente.

Abordarea abductivă are ca obiectiv găsirea mulțimii minimale de ipoteze care sunt asociate cunoștințelor sistemului și care determină apariția observațiilor.

Deznodând cunoștințele de acum, se poate spune că o problemă de diagnostic este o problemă în care se dă un set de probleme și manifestări sau simptome și se cere să se explice prezența acestora, utilizând propriile cunoștințe despre domeniul problemei.

2.3. Tipuri de cunoștințe folosite în sisteme de diagnoză

Într-un sistem expert de diagnoză se folosesc cel puțin două tipuri de cunoștințe:

Cunoșințe probabilistice;

Cunoștințe structurale;

Cunoștințele probabilistice sunt prezentate în formă numerică și reflectă incertitudinea implicată în asociațiile simbolice, specificând tăria acestor asociații și probabilitațile de prioritate ale entităților individuale. Alte tipuri de probabilistici exprimate în formă numerică sunt cele care reflectă tot diferite tipuri de imperfecțiuni ale informației specifice diagnozei, dar care nu sunt normal exprimate prin probabilități. Tipurile de inperfecțiuni sunt modelate folosind teoria posibilității, factori de incertitudine, relații fuzzy etc. Cunoștințele numerice sunt exprimate în general prin reguli de producție și grafuri cauzale.

Cunoștințele structurale, de obicei prezentate în formă simbolică, specifică entitățile și tipurile de asociații care există între acestea. Dintre tipurile de asociații, cele mai folosite în cazul problemelor de diagnoză sunt relațiile “cauză-efect”. Reprezentarea cunoștințeleor structurale folosesc fie logica propozițiilor sau a predicatelor fie reguli de producție, fie reprezentări prin grafuri cauzale.

În concluzie cele mai bune metode de rezolvare a problemelor de diagnostic s-au dovedit a fi cele care combină ambele tipuri de cunoștințe, și cele structurale și cele procedurale. Exemple de astfel de sisteme expert sunt: MYCIN, teoria Dempster-Shaffer pentru ordonarea ipotezelor competitive, diferite aplicații ale teoriei fuzzy, combinarea teoriei Bayesiene a deciziei cu deducția bazată pe reguli în PROSPECTOR.

Chiar dacă avem aceste metode, ele nu au fost complet adecvate pentru a putea fi utilizate în rezolvarea unei probleme generale de diagnoză.

2.4 Asemănarea cu diagnosticul uman

Diagnoza constă în găsirea ne-regulilor care au rezultat manifestările observate. Principiul cauzalității spune că: “Fiecare efect are o cauză; aceleași cauze, în aceleași condiții produc aceleași efecte”. Dacă ținem cont de acest principiu al cauzalității, se poate spune că manifestările observate la un sistem oarecare sunt efecte ale apariției dezordinii de care sunt cauzate și problema de diagnoză constă în găsirea cauzelor acestor efecte.

Ani la rândul studiindu-se procesul de gândire al unui diagnostic uman s-a constatat că acesta este un proces secvențial și constructiv de generare și tratare a ipotezelor, denumit și “proces ipotetico-deductiv” sau “ipoteză și testare”.

Acest proces ipotetico-deductiv, logic tipului de gândire al diagnosticianului uman, a fost descompus în două fraze după va urma:

Formarea ipotezelor prin enunțarea dezordinilor, ce este un proces de regăsire din memoria permanentă sau baza de cunoștințe a dezordinilor cauzative, pornind de la manifestările cunoscute. Această fază a gândirii are la bază inferența abductivă. Inferența abductivă înseamnă orice proces de gândire care oferă cea mai bună explicație pentru multitudinea de atribute ale problemei.

Aceste atribute pentru problemele de diagnoză sunt uzual simptome măsurabile sau manifestări, iar explicațiile sunt ipoteze care cuprind dezordinile cauzative.

Testarea ipotezelor sunt formate din întrebări despre starea sistemului, răspunsul fiind pentru a verifica ipotezele existente.

Evaluare acestor ipoteze implică încorporarea noilor cauze posibile (dezordini în ipoteze), sau confirmarea anumitor entități deja existente în ipoteză, sau eliminarea unora dintre ele.

Concluzia este că diagnosticianul uman realizează aranjarea ipotezelor, luându-le în considerare întâi pe cele promițătoare, celelalte intervenind ulterior în procesul de diagnoză doar dacă în cazul procesului de testare apar informații neașteptate cu privire la ele.

Formarea ipotezelor este un proces care trebuie să rezolve două aspecte contradictorii, Peng și Regia (1990), ele fiind:

unul acoperitor – acela de explicare a tuturor manifestărilor prezente;

unul redus – cel ce minimizează complexitatea explicațiilor;

Sunt cinci criterii principale pe care literatura de specialitate le consemnează și care pot fi utilizate pentru a caracteriza măsura în care o ipoteză de dezordine se poate constitui efectiv într-o explicație a observațiilor:

o explicație trebuie să fie logică cu cunoștințele existente privind funcționarea sistemului, cu starea sa curentă și cu observațiile;

de preferat o explicație care acoperă în mare parte sau toate observțiile curente;

de preferat o explicație compusă care are un număr minimal de dezordini;

o ipoteză a fost confirmată ca soluție, atunci când toate celelate ipoteze au fost eliminate.

Pe lângă aceste cinci criterii, un aspect important în evaluarea ipotezelor este cel de ordonare a dezordinilor competitive. Acest termen se referă la ipotezele alternative care pot apărea pentru aceleași manifestări sau manifestări similare. Le spune competitive deoarece concurează unele cu altele în oferirea explicațiilor.

Sistemele expert de diagnoză au avut un succes foarte mare datorită capabilității lor de a rezolva probleme ce implicau un volum mare de informație dar au prezentat limite în ceea ce privește încorporarea incertitudinii și definirea unui formalism independent de problemă. Dar totuși rezultatele ce au fost obținute au făcut ca acet domeniu să rămână încă un domeniu activ de cercetare.

În ultima perioadă cercetătorii au dat o mai mare atenție raționamentului abductiv, care chiar dacă pare natural este greu de utilizat în sistemele de inteligență artificială.

Astfel încât abducția este:

Considerată ca fiind o parte a logici, care poate fi comparată cu deducția sau inducția.

Capturează în mod natural incertitudinea, aceasta făcând parte din acest tip de raționament;

Este posibil ca frecvent să apară mai multe explicații în timpul inferenței abductive, fiind necesar un proces drastic între explicațiile alternative.

Mediul Microsoft Visual Studio Express for Windows Phone

și implemetarea sistemului expert de diagnoză a calculatorului personal

3.1Mediul de programare Microsoft Visual Studio Express for Windows Phone

C# este un limbaj de programare orientat-obiect conceput de Microsoft la sfarșitul anilor 90. A fost conceput ca un concurent și rival al limbajului Java. Ca și acesta C# este un derivat al limbajului de programare C++.

Limbajul C# este destinat a fi un limbaj simplu și modern.

Microsoft Visual Studio Express for Windows Phone este un instrument al mediului C#. Pentru a putea folosi acest mediu va trebui download-at și instalat Windows Phone Developer Tools, care include și Visual Studio Express for Windows Phone, XNA Game Studio 4.0 și un emulator pentru a putea testa programele create în lipsa unui gadget mobil.

Puteți instala aceste instrumente și din partea de sus a programului Visual Studio 2010, pentru dezvoltarea aplicațiilor mobile WP.

Pentru programatori, Windows Phone este deasemenea foarte interesant deoarece suportă două platforme populare si moderne: Silverlight și XNA

Silverlight – bazat pe WPF ( Windows Presentation Foundation), a dat deja programatorilor web putere fară precedent pentru a dezvolta interfețe utilizator sofisticate, cu un amestec de control tradițional, text de înaltă calitate, grafică vectoială, animații și date cu caracter obligatoriu care pot rula pe mai multe platforme si browsere.

XNA – nu este un acronim, este platforma de joc Microsoft ce suportă 2D și 3D cu o arhitectură de joc-buclă tradițională.

Deși pe emulatorul oferit de Microsoft puteți rula orice aplicație creați la un moment dat o să doriți ca aplicațiile create să ruleze pe un dispozitiv real. Pentru asta vă puteți înregistra ca dezvoltator de aplicații mobile la: http://developer.windowsphone.com și o sa aveți capacitatatea de a vă debloca telefonul și a putea implementa propriiele programe din Visual Studio.

Windows Phone 7 suportă multi-touch (multi-tactil-atingere multiplă a ecranului), care este o componentă importantă pentru telefon. Când folosiți Windows Phone Emulator , mouse-ul și click-ul mouse-ului, poate imita atingerea pe emulator, dar pentru un singur deget. Puteți testa multi-touch-ul în emulator dacă aveți monitor cu multi-touch care să ruleze în Windows 7.

3.2 Reprezentare cunoștințelor in Windows Phone

Toate programele pentru Windows Phone sunt scrise în cod .NET. Platformele amintite mai sus, Silverlight si XNA au în comun unele biblioteci, astfel puteți utiliza unele biblioteci din XNA în Silverlight și vice-versa, dar nu se poate crea un program care să poată îmbina cele două platforma în întregime (poate pe viitor va fi posibil, dar nu acum). Înainte de a vă crea propriul proiect Visual Studio trebuie să vă decideți dacă ideea dumneavoastră de milioane de dolari este o aplicație de XNA sau Silverlight.

Versiunile inițiale ale sistemului Windows Phone 7 vor avea dimenisunile ecranului destul de consistente. O a doua dimensiune a ecranului este așteptată în viitor.

Partea din fața a telefonului constă într-un ecran multi-tactil și trei butoane hardware general, poziționate cu un rând mai jos de ecran. De la stânga la dreapta numindu-se astfel: Înapoi, Start și Search

Back – Programele pot folosi acest buton pentru nevoile lor de navigare proprii, la fel ca și un buton Back de pe un browser web. Din pagina de pornire a unui program, butonul face programul pentru a termina “acțiunea”.

Start – Acest buton duce utilizatorul la ecranul de pornire al telefonului, dar este inaccesibil pentru programele care rulează pe telefon.

Înapoi – Sistemul de operare folosește acest buton pentru a iniția o funcție de căutare.

Primele versiuni de dispozitive ce au în folosința sistemul Windows Phone 7, au o dimensiune de afișare de 480×800 pixeli. În viitor sunt asteptate și ecrane de 320×480 pixeli, alte opțiuni de ecran pentru versiunea 7 nu există, acestea două fiind singurele.

În următoarele imagini voi face referire la acele 2 dimensiuni de ecran amintite mai sus, denumite ca și ecran „mare” și ecran „mic”. Cel mai mare numitor comun a dimensiunilor verticale și orizontale ale ambelor ecrane este de 160, astfel ecranele pot fi vizualizate ca multipli de patrate de 160 pixeli.

480

320

800 480

Explic aceste ecrane în portret deoarece asa sunt proiectate smartphone-urile.

Reprezentarea cunoștințelor in mediul Microsoft Visual Studio Express for Windows Phone se face prin intermediul a două reguli principale: if, then.

Regulile sunt folosite pentru a reprezenta cunoștințe asigurând realizarea unui set de acțiuni în condițiile date. Dezvoltarea unui sistem expert constă în definirea unui set de reguli care vor duce la rezolvarea ei, astfel:

Dacă ne regăsim defecțiunea printre problemele care se află în aplicație trecem mai departe, altfel se iese din aplicație.

Dacă raspunsul găsit este bun, am rezolvat problema.

3.3Descrierea aplicției generalizată

Arborele de decizie

Arborele de decizie a sistemului expert este format din nodul rădăcină, ramuri și noduri de decizie (frunzele). În cazul aplicației prezentate fiind problemele și rezolvarea lor, după cum urmează și în schema următoare:

3.4Descrierea componentelor (fișier.xaml)

Imprimantă.xaml

Fișierul Imprimantă.xaml prezentat în clasa Windows Phone, folder-ul Partea1 conține problemele aferente componentei „imprimantă” aflate în folder-ul „Imprimantă”. Problemele prezentate aici sunt legate strict de unele defecțiuni pe care le întâmpinăm cu componenta calculatorului: imprimanta.

Figura 3.4.1 Arborele de decizie aferent componentei Imprimantă

Tastatură.xaml

Fișierul Tastatură.xaml prezentat în clasa Windows Phone, folder-ul Partea1 conține problemele aferente componentei „tastatură” aflate în folder-ul „Tastatură”. Problemele prezentate aici sunt legate strict de unele defecțiuni pe care le întâmpinăm cu componenta calculatorului: tastatură.

Figura 3.4.2 Arborele de decizie aferent componentei Tastatură

Monitor.xaml

Fișierul Monitor.xaml prezentat în clasa Windows Phone, folder-ul Partea1 conține problemele aferente componentei „monitor” aflate în folder-ul „Monitor”. Problemele prezentate aici sunt legate strict de unele defecțiuni pe care le întâmpinăm cu componenta calculatorului: monitor.

Figura 3.4.2 Arborele de decizie aferent componentei Monitor

Mouse.xaml

Fișierul Mouse.xaml prezentat în clasa Windows Phone, folder-ul Partea1 conține problemele aferente componentei „monitor” aflate în folder-ul „Mouse”. Problemele prezentate aici sunt legate strict de unele defecțiuni pe care le întâmpinăm cu componenta calculatorului: mouse.

Figura 3.4.2 Arborele de decizie aferent componentei Mouse

Unitate.xaml

Fișierul Unitate.xaml prezentat în clasa Windows Phone, folder-ul Partea1 conține problemele aferente componentei „monitor” aflate în folder-ul „Monitor”. Problemele prezentate aici sunt legate strict de unele defecțiuni pe care le întâmpinăm cu componenta calculatorului: unitatea centrală.

Figura 3.4.2 Arborele de decizie aferent componentei Unitate

3.5Structura generală a sistemului expert de diagnoză a calculatorului personal

Sistemul expert de diagnoză a calculatorului personal se dezvoltă pe 5 direcții principale încercând cât mai mult să acopere câteva din cele mai frecvent întâlnite probleme ce pot apărea în activitatea zilnică a unui calculator personal.

Cele 5 direcții pe care se dezvoltă sistemul expert de diagnosticare a calculatorului sunt următoarele:

Imprimantă

Monitor

Mouse

Tastatură

Unitate

Imaginea următoare explică cum va arata aplicația în momentul deschiderii în emulatorul Windows Phone.

Figura 3.5.1 Imaginea de început a aplicației

Sistemul expert implementat în Windows Phone este structurat pe 5 fișiere principale introduce în Folder-ul “Partea1”, după cum urmează:

Imprimanta.xaml – fișier .xaml ce conține problem ele pentru componenta „Imprimantă”.

Monitor.xaml – fișier .xaml ce conține problemele pentru componenta „Monitor”.

Mouse.xaml – fișier .xaml ce conține problemele pentru componenta „Mouse”.

Tastatură.xaml – fișier .xaml ce conține problemele pentru componenta „Tastatură”.

Unitate.xaml – fișier .xaml ce conține problemele pentru componenta „Unitate”.

Butonul „Help!” – ne duce pe o platformă web cu o bază de date în spate ce ne oferă mai multe “probleme și răspunsuri” necesare nouă.

Fiecare din cele 5 componente, de exemplu Imprimantă.xaml va avea în principiu 5 probleme cu răspunsuri la ele, acestea fiind introduse în foldere denumite dupa fiecare componentă pentru o mai bună organizare, aratând astfel:

Figura 3.5.2 Problemele fișierului Imprimantă.xaml

O frunză a arborelui de decizie, adică răspunsul unei probleme a Imprimantei, va arata astfel:

Figura 3.5.3 Răspunsul unei probleme din secțiunea Imprimanta.xaml

Astfet vor arăta toate problemele aferente componentelor calculatorului, problema imprimantei a fost doar un exemplu cum se va desfășura aplicația.

3.6Proiectarea bazei de date

O etapă fundamentală în cadrul ciclului de viață a unui sistem informatic este proiectarea sistemelor informatice. U na dintre metodele proiectării sistemelor indormatice este metoda Merise.

Metoda Merise constă în elaborarea de modele la nivel conceptual, organizațional și operațional, fiecare dintre acestea având ca finalitate formularea unor răspunsuri la următoarele întrebări [Georgesscu, 2010, p.87]:

La nivel conceptual: „Ce trebuie făcut și cu ce date?”;

La nivel organizațional: „Cine?”, „Când?”, „Unde?”;

La nivel operațional: „Cum?” (se referă la mijloacele utilizate pentru gestiunea datelor și prelucrărilor);

Modelul conceptual al datelor (MCD)

Modelul conceptual al datelor reprezintă o structură generală și logică a bazei de date. Pentru realizarea modelului este necesară folosirea unei reprezentări sub formă de text așa cum a fost ea înțeleasă de analist.

MCD este prezentat în figura următoare și cuprinde următoarele entități:

Figura 3.6.1 Modelul conceptual al datelor

Imprimantă;

Tastatură;

Monitor;

Mouse;

Unitate;

Fiecare dintre entități cuprinde numele problemei și răspunsul aferent problemei enunțate.

Asociația “Activ” leagă toate entitățile ea, asociațiile fiind 1,n deoarece unei componente din Activ ii corespund mai multe probleme și răspunsuri din entități.

Modelul logic al datelor (MLD)

Modelul logic al datelor se obține plecând de la structura realizată la modelul conceptual al datelor, plus aplicarea regulilor de trecere la MLD scpecifice legăturilor dintre entități și asociație, pe baza cardinalităților specifice asocierii colecțiilor de date.

Modelul logic al datelor este prezentat în figura următoare, asociația Activ devenind coloană, iar identificatorii entităților au devenit chei primare in MLD.

Figura 3.6.2 Modelul logic al datelor

3.7Scenarii de utilizare a sistemului expert

În continuare voi explica cum funcționează sistemul expert și cum este structurat.

Pentru a avea acces la această aplicație este nevoie de un dispozitiv mobil cu sistem de operare Windows Phone 7.

Aplicația propune diagnoza calculatorului personal. La deschiderea programului întâmpinam interfața de început ce are în prim-plan cele 5 componente principale ale calculatorului. Pentru detectarea unei probleme pe care o avem se execută click pe componentă, astfel programul va trece la etapa următoare (ramurile arborelui de decizie) și anume problemele componentei. Dacă problema pe care o avem se regăsește în problemele pe care le deține aplicația trecem la pasul următor facând click pe problemă astfel încât se ajunge la frunzele arborelui, adică rezolvarea “enigmei” care am întâmpinat-o. Dăcă răspunsul nu ne este favorabil executăm Back din butoanele telefonului.

Aplicația vine cu un număr limitat de PROBLEME, ele fiind introduse în clasele programului Microsoft Visual. Se regăsesc doar puține probleme deoarece aplicația este locală, nu este necesară conexiunea la internet, ceea ce include un bonus pentru utilizatori. Pentru întreținerea și upload-ul continuu de informație al dezoltatorului este folosită baza de date din spatele butonului Help!, aici dezvoltatorul aplicației poate introduce informații cu referire la problemele ce apar zi de zi calculatoarelor noastre.

Concluzii, recomandări și direcții de dezvoltare

Ca urmare a faptului că sistemul prezentat în lucrare se înscrie și el prin natura sa printre sistemele expert, va purta ca moștenire și avantajele și dezavantajele acestora. Iată cateva dintre punctele forte ale sistemelor expert:

Mult mai rapide ca experții umani;

Pot fi actualizate cu ușurință dacă sunt flexibile;

Este nevoie de ele în lipsa expertizei umane;

Pot fi mai ieftine și mai eficiente decât experții umani;

Sunt colecții de informații valoroase;

Tratează incertitudinea într-o manieră, iar experților umani poate fi inspectată și verificată

Sistemul expert de față are un avantaj că noutățile sunt foarte ușor de introdus, ceea ce duce la un grad de flexibilitate foarte ridicat al sistemului. Cu alte cuvinte se pot adăuga noi „probleme și rezolvări„ ale unor componente din calculator în care la un moment dat avem o problemă și nu știm, nu o putem rezolva, ceea ce înseamnă că baza de cunoștințe este foarte ușor de actualizat și modificat.

Deopotrivă trebuiesc amintite și cateva limite pe care le au sistemele expert:

Îmbogățirea cunoștințelor nu este automată, pemtru actualizarea lor este nevoie de intervenția umană;

Limitate la un singur domeniu;

Nu pot raționaliza pe baza intuiției sau bunului simț;

Cunoștințele înmagazinate depind foarte mult de expertul uman care le exprimă și articulează.

Mulți dintre noi avem unele probleme la calculator, se defectează ceva, se strică altceva, de aceea diagnoza calculatorului ca aplicație pentru telefonul mobil, mai exact pe sistemul Windows Phone 7 sunt convins că este foarte necesară. Bine pusă la punct, având o iterfață prietenoasa și adaptabila la “gusturile” oamenilor și-ar găsi foarte ușor locul în multe gadget-uri mobile, ale căror utilizatori sunt puși fața în față cu din ce în ce mai multe probleme și nu au posibilitate de a apela la un expert uman și chiar la o rețea de internet.

Anexe

Anexa nr1: Pagina de start a aplicației.

<phone:PhoneApplicationPage

x:Class="LicentaWP.MainPage"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"

FontFamily="{StaticResource PhoneFontFamilyNormal}"

FontSize="{StaticResource PhoneFontSizeNormal}"

Foreground="{StaticResource PhoneForegroundBrush}"

SupportedOrientations="Portrait" Orientation="Portrait"

shell:SystemTray.IsVisible="True">

<!–LayoutRoot is the root grid where all page content is placed–>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<!–TitlePanel contains the name of the application and page title–>

</StackPanel>

<!–ContentPanel – place additional content here–>

<HyperlinkButton.Background>

</HyperlinkButton.Background>

</HyperlinkButton>

<HyperlinkButton.Background>

</HyperlinkButton.Background>

</HyperlinkButton>

<HyperlinkButton.Background>

</HyperlinkButton.Background>

</HyperlinkButton>

<HyperlinkButton.Background>

</HyperlinkButton.Background>

</HyperlinkButton>

<HyperlinkButton.Background>

</HyperlinkButton.Background>

</HyperlinkButton>

</Grid>

</Grid>

<!–Sample code showing usage of ApplicationBar–>

<!–<phone:PhoneApplicationPage.ApplicationBar>

<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">

<shell:ApplicationBarIconButton IconUri="/Images/appbar_button1.png" Text="Button 1"/>

<shell:ApplicationBarIconButton IconUri="/Images/appbar_button2.png" Text="Button 2"/>

<shell:ApplicationBar.MenuItems>

<shell:ApplicationBarMenuItem Text="MenuItem 1"/>

<shell:ApplicationBarMenuItem Text="MenuItem 2"/>

</shell:ApplicationBar.MenuItems>

</shell:ApplicationBar>

</phone:PhoneApplicationPage.ApplicationBar>–>

</phone:PhoneApplicationPage>

Anexa nr.2: Imprimantă.xaml

<phone:PhoneApplicationPage

x:Class="LicentaWP.Partea1.imprimanta"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

FontFamily="{StaticResource PhoneFontFamilyNormal}"

FontSize="{StaticResource PhoneFontSizeNormal}"

Foreground="{StaticResource PhoneForegroundBrush}"

SupportedOrientations="Portrait" Orientation="Portrait"

mc:Ignorable="d" d:DesignHeight="768" d:DesignWidth="480"

shell:SystemTray.IsVisible="True">

<!–LayoutRoot is the root grid where all page content is placed–>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<!–TitlePanel contains the name of the application and page title–>

</StackPanel>

<!–ContentPanel – place additional content here–>

<HyperlinkButton Content="–>" Height="39" HorizontalAlignment="Left" Margin="12,45,0,0" Name="hyperlinkButton1" VerticalAlignment="Top" Width="64" NavigateUri="/LicentaWP;component/Imprimanta/prob1imprimanta.xaml" />

<HyperlinkButton Content="–>" Height="31" HorizontalAlignment="Left" Margin="12,140,0,0" Name="hyperlinkButton2" VerticalAlignment="Top" Width="64" NavigateUri="/LicentaWP;component/Imprimanta/prob2imprimanta.xaml" />

<HyperlinkButton Content="–>" Height="39" HorizontalAlignment="Left" Margin="12,224,0,0" Name="hyperlinkButton3" VerticalAlignment="Top" Width="64" NavigateUri="/LicentaWP;component/Imprimanta/prob3imprimanta.xaml" />

<HyperlinkButton Content="–>" Height="36" HorizontalAlignment="Left" Margin="12,373,0,0" Name="hyperlinkButton4" VerticalAlignment="Top" Width="64" NavigateUri="/LicentaWP;component/Imprimanta/prob4imprimanta.xaml" />

<HyperlinkButton Content="–>" Height="37" HorizontalAlignment="Left" Margin="12,489,0,0" Name="hyperlinkButton5" VerticalAlignment="Top" Width="64" NavigateUri="/LicentaWP;component/Imprimanta/prob5imprimanta.xaml" />

</Grid>

<!–Sample code showing usage of ApplicationBar–>

<!–<phone:PhoneApplicationPage.ApplicationBar>

<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">

<shell:ApplicationBarIconButton IconUri="/Images/appbar_button1.png" Text="Button 1"/>

<shell:ApplicationBarIconButton IconUri="/Images/appbar_button2.png" Text="Button 2"/>

<shell:ApplicationBar.MenuItems>

<shell:ApplicationBarMenuItem Text="MenuItem 1"/>

<shell:ApplicationBarMenuItem Text="MenuItem 2"/>

</shell:ApplicationBar.MenuItems>

</shell:ApplicationBar>

</phone:PhoneApplicationPage.ApplicationBar>–>

</phone:PhoneApplicationPage>

Anexa nr.3: Problma1 aferentă componentei Imprimantă

<phone:PhoneApplicationPage

x:Class="LicentaWP.Imprimanta.prob1imprimanta"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

FontFamily="{StaticResource PhoneFontFamilyNormal}"

FontSize="{StaticResource PhoneFontSizeNormal}"

Foreground="{StaticResource PhoneForegroundBrush}"

SupportedOrientations="Portrait" Orientation="Portrait"

mc:Ignorable="d" d:DesignHeight="768" d:DesignWidth="480"

shell:SystemTray.IsVisible="True">

<!–LayoutRoot is the root grid where all page content is placed–>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<!–TitlePanel contains the name of the application and page title–>

</StackPanel>

<!–ContentPanel – place additional content here–>

</StackPanel>

</ScrollViewer>

</Grid>

<!–Sample code showing usage of ApplicationBar–>

<!–<phone:PhoneApplicationPage.ApplicationBar>

<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">

<shell:ApplicationBarIconButton IconUri="/Images/appbar_button1.png" Text="Button 1"/>

<shell:ApplicationBarIconButton IconUri="/Images/appbar_button2.png" Text="Button 2"/>

<shell:ApplicationBar.MenuItems>

<shell:ApplicationBarMenuItem Text="MenuItem 1"/>

<shell:ApplicationBarMenuItem Text="MenuItem 2"/>

</shell:ApplicationBar.MenuItems>

</shell:ApplicationBar>

</phone:PhoneApplicationPage.ApplicationBar>–>

</phone:PhoneApplicationPage>

Anexa nr.4: Interiorul butonului Afișează!, ce conține răspunsul problemei

using System;

using System.Collections.Generic;

using System.Linq;

using System.Net;

using System.Windows;

using System.Windows.Controls;

using System.Windows.Documents;

using System.Windows.Input;

using System.Windows.Media;

using System.Windows.Media.Animation;

using System.Windows.Shapes;

using Microsoft.Phone.Controls;

namespace LicentaWP.Imprimanta

{

public partial class prob1imprimanta : PhoneApplicationPage

{

public prob1imprimanta()

{

InitializeComponent();

}

private void button1_Click(object sender, RoutedEventArgs e)

{

textBlock1.Text = " Verificați compatibilitatea cartușelor.\n\n Resetați imprimanta.\n\n Curățați contactele cartușelor sau capetele de imprimare.\n\n Curățați contactele electrice din interiorul carului de imprimare.\n\n Înlocuiți cartușul și capătul de imprimare.";

}

Sunt atașate anexele doar pentru o problemă și un răspuns a componentei Imprimantă.

Bibliografie

Novac Cornelia; Cocu Adina – Fundamente de inteligență artificială, Editura Fundației Universitare „Dunărea de Jos” , 2003, Galați.

Novac Cornelia; Palade Vasile – Inteligență artificială și sisteme expert, Editura Tehnică, 2001, București.

[Novac, 2009] Cornelia Novac-Ududec, Sisteme de asistare a deciziilor, Editura didactică și pedagogică, București, 2009.

Segal C. – Sisteme inteligente de diagnoză – Editura Fundației Universitare „Dunărea de Jos” , 2002, Galați.

[Georgescu, 2010] Cristian Georgescu, Modelare relațională, Editura EUROPLUS, Galați, 2010.

[Georgescu, 2005] Cristian Georgescu, Baze de date relaționale și multidimensonale, Editura didactică și pedagogică R.A., București, 2005.

Windows Phone 7 Developer Guide [Dominic Betts, Federico Boerr, Scott Densmore, Jose Gallardo Salazar, Alex Homer], 2010 Microsoft Corporation

Windows Phone 7 [Charles Petzold], published by Microsoft Press A Division of Microsoft Corporation One Microsft Way Redmond, Washington, 2010

http://stud.usv.ro/~stivadar/ri1.pdf

http://www.icbe-ct.com/masterat/sisteme_expert_mfc/sinteza_sisteme_expert.pdf

http://arheologie.ulbsibiu.ro/publicatii/carti/ai/1e.htm