Generarea Si Corectarea Automata a Unor Teste Grila

Acronime

WPF – Windows Presentation Foundation

MVVM – Model – View –ViewModel

QR – Quick Response

PDF – Portable Document Format

BMP – Bitmap

JPG –Joint Experts Group

XAML –Extensible Application Markup Language

XML – Extensible Markup Language

GUI – Graphical User Interface

CUI – Console User Interface

DLL – Dynamic-link library

HTML – HyperText Markup Language

VB – Visual Basic

COM – Component Object Model

CLR – Common Language Runtime

UI – User Interface

CIL – C Intermediate Language

OOP – Object-oriented Programming

SOAP – Simple Object Access Protocol

ASP – Active Server Pages

Capitolul 1.

INTRODUCERE

Contextul lucrării

Una din cele mai importante caracteristici pe care le identificăm la un sistem este eficiența lui iar prin eficiență ne referim la timpul de procesare, corectitudinea în rezolvarea sarcinilor și capacitatea de lucru.

Odată cu avansul tehnologic în ceea ce privește avansul tehnologic implementarea unor sisteme ce ușurează munca omului a devenit o necesitate. Un sistem ce poate să rețină un număr foarte mare de date este extrem de util când vine vorba de procesarea datelor.

Evidența studenților într-o bază de date ne dă posibilitatea de acces rapid la date. Aceste date pot fi filtrate și sortate după diverse criterii. De asemenea, stocarea rezultatelor studenților la examene este un lucru extrem de util iar procesarea testelor într-un timp minim cu introducerea punctajelor în mod automat în sistem este un avantaj real ce a devenit o nevoie a profesorilor de azi.

[Rescriem]

Obiective și specificația proiectului

Prezenta lucrare de licență prezintă elaborarea unor soluții referitoare la generarea și corectarea automată a unor teste grilă. Obiectivul lucrării este realizarea unei aplicații destinată utilizatorilor care doresc să genereze variante de testare în mod automat și să corecteze testele, prin procesare de imagine în timp minim.

Aplicația are următoarele facilități:

Posibilitate de autentificare (administrator/utilizator comun) – există două tipuri de utilizatori ce au acces la aplicație, utilizator de are rol de administrator – poate adăuga, șterge și modifica setul de întrebări, lista de studenți și tipurile de variante, deasemenea un utilizator cu rol de administrator poate să adauge utilizatori noi sau să șteargă utilizatori. Utilizatorul comun are posibilitatea de a genera variante și de a corecta teste, el mai poate viziona lista de studenți, tipurile de variante de examinare și setul de întrebări.

Stocare informații despre studenți – aplicația stochează următoarele infomații despre studenți : nume, prenume, cnp, țară, oraș, stradă, număr, număr de telefon și adresă de e-mail. Avem posibilitatea de a adăuga, șterge sau modifica lista de studenți.

Se rețin în baza de date un numă de întrebări, cu 5 variante de răspuns, variante multiple de răspunsuri corecte. Se pot adăuga, șterge sau modifica întrebări.

Variante de examinare – sunt generate din setul de întrebări, utilizatorul trebuie să denumească tipul de variantă , de exemplu:”A”, și va introduce numărul de întrebări ce îl va conține. Varianta va conține numărul de întrebări pe care l-a introdus utilizatorul de la tastatură, întrebările vor fi selectate în mod aleator din baza de date, cu constrângere de unicitate.

Examene generate – sunt stocate în baza de date numele studentului, varianta primită și data în care s-a generat testul grilă. Utilizatorul poate selecta din lista studenți, stundenții pentru care se vor genera teste. Generarea testelor se salvează în format PDF, într-un fișier Temp, ce va generat pe Desktop. Aceste examinări nu au completat câmpul “punctaj” la generarea lor, ceea ce presupune ca la corectarea examenului grilă, tabelul va fi completat în mod corespunzător, fiecărui student în parte.

Corectarea testelor grilă – se face cu ajutorul unui algoritm de procesare de imagini, ce detectează pătrate de o anumită dimensiune în pixeli. Pin citirea codului QR se va căuta în tabela de examene generate studentul căruia îi corespunde examinarea și i se va completa câmpul “punctaj”.

Lucrarea de diplomă cuprinde șase capitole, fiecare dintre acestea având un rol bine precizat în scopul îndeplinirii obiectivului stabilit.

Capitolul 2.

STUDIU BIBLIOGRAFIC

2.1. Platforma .NET

.NET este un cadru de dezvoltare software care permite realizarea și distribuirea aplicațiilor desktop Windows și aplicațiilor WEB. Platforma .NET este o componentă livrată de către Microsoft cu sistemul de operare Windows.

Tehnologia .NET cuprinde mai multe tehnologii(ASP, XML, OOP, SOAP etc.) și limbaje de programare(VB, C++, C#, J#, F# etc.) asigură atât portabilitatea codului compilat pe diferite calculatoare cu sisteme de operare Windows cât și reutilizarea codului. Platforma comună a limbajelor este CLR(Common Language Runtime). Rularea în limbaj comun este exact ceea ce sugerează denumirea sa: este un mode de rulare ce poate fi utilizat de către diverse limbaje de programare. În momentul executării CLR nu știe ce limaj de programare a folosit cel care a implementat aplicația.Putem dezvolta codul în orice limaj de programare dorim, atâta timp cât compilatorul folosit pentru compilarea codului sursă are în vedere rularea CLR.

2.1 Proces de compilare a fișierelor sursă

După cum se observă în figura 2.1 codul sursă se poate scrie în orice limbaj de programarecare suportă rularea CLR. Se va utiliza compilatorul corespunzător pentru verificarea erorilor de sintaxă și a analizei codului sursă. Se observă că indiferent de compilatorul folosit, rezultatul este un modul administrat. Un modul adminstrat este un fișier executabil Windows standard portabil, care necesită rularea CLR pentru a fi executat.

2.2Arhitectură platformă .NET

Platforma .NET este alcătuită din compilatoare, biblioteci și alte fișiere executabile utile în rularea aplicațiilor.

2.1.2. Limbajul C# și Programarea orientată pe obiecte

C# este un limbaj simplu, cu circa 80 de cuvinte cheie și 20 de tipuri de date predefinite. Permite programare structurală, modulară și orientată pe obiecte, conform perceptelor moderne ale programatorilor profesioniști.Principiile de bază ale programării pe obiecte(încapsulare, moșternire, polimorfism) sunt elemente fundamentale ale programării C#, cel mai comun tip de programare este cel orientat pe obiecte.

Un program scris în C# este supus unei compilări în urma căreia se obține un cod scris într-un limbaj intermediar(CIL). În această formă aplicația este apoi trimisă procesorului virtual (CLR) care realizează traducerea în cod mașină și execută aplicația.

2.3 Tratarea programelor scrise în C#

Precum am menționat sus, în programarea în limbajul C#, de cele mai multe ori, cei ce implementează o aplicație aleg să o facă cu programare orientată pe obiecte.La baza OOP stau clasele și obiectele. Clasa–reprezintă definirea unui tip de date abstracte sau concrete; adică descrierea proprietăților, datelor și a metodelor, a prelucrării posibile a datelor.Este o noțiune abstractă, care definește un anumit tip de obiect.Obiect–reprezintă o mulțime date date care reprezintă un anumit obiect, concret sau abstract, numite și proprietăți iar funțiile de prelucrare a acestora sunt numite metode. Crearea unui obiect presupune specificarea clasei din care face parte, astfel identificându-se proprietățile obiectului și modul în care acestea pot fi folosite și prelucrate.

Cele mai importante 4 principii ale OOP-ului sunt:

Abstractizarea – concentrare asupra esențialului, identificarea similitudinilor între diferite entități, ignorarea detaliilor mai puțin semnificative.

Încapsulare – ascundere de informații, obiectele nu pot schimba starea internă a altor obiecte în mod direct (doar prin metode puse la dispoziția obiectului respectiv).

Moștenire – permite construire unor clase noi, care păstrează caracteristicile și comportarea de la o clasă de bază, fiind posibilă redefinirea sau adăugarea unor date și metode noi. Moștenirea oferă posibilitatea de a reutiliza cod scris, organizează și facilitează polimorfismul și încapsularea.

Polimorfismul –permite ca aceeași operație să se realizele în moduri diferite în clase diferite. Ajută la o mai bună înțelegere și interpretare a codului scris.

Avantajele programării în limbajul C# ar fi următoarele: dezvoltarea rapidă de aplicații, funcționare inter-platforme, acces la resursele caracteristice platformei, suport pentru platformele COM și .NET.

2.2. WPF

WPF – Winows Presentation Foundation este o parte integrată a platfomei .NET folosită pentru crearea interfețelor grafice pentru aplicațiile Windows.În dezvoltarea unei aplicații WPF, o practică obișnuită constă în separarea interfeței grafice de logica aplicației, astfel încat interfața grafică să poată evolua indiferent de logica aplicației și viceversa. Prin realizarea acestei separări, dezvoltatorul interfeței grafice va fi scutit de cunoașterea logicii apicației, astfel putându-se concentra pe deplin doar pe dezvoltarea interfeței grafice. Deasemenea, dezvoltatorul logicii aplicației se va putea concentra doar pe partea de business-logic, ignorând pe deplin elementele grafice. Dezvoltatorul logicii aplicației nu este nevoit sa cunoască tehnologia WPF.

Pentru a putea separa cele două părți, interfața utilizator de partea logică a aplicației, va trebui să eliminăm toate referințele din XAML spre rutine definite în code-behind. Această separare poate fi realizată doar cu ajutorul mecanismului de data binding din WPF, mecanism care permite asocierea de date cu elemente aleinterfeței grafice din WPF. Un element WPF din interfața grafică se poate lega de o sursă de date, astfel încât starea lui se va actualiza automat, odată cu modificarea datelor asociate. Aceste asocieri se pot face atât în XAML cât și în cod C#.

O altă componentă a separării interfeței grafice de logica aplicației o reprezintă conceptul data context. Acest concept permite elementelor WPF să moștenească de la elementele părinte informații depsre sursa de date folosită la data binding. Acest lucru este realizat prin intermediul proprietații DataContext conținuta de toate elementele WPF. Toate subelementele unui element părinte vor moșteni contextul de date al părintelui. Asta nu înseamnă că un subelement nu poate să aibă propriul context de date prin suprascrierea proprietății DataContext.

Pe lângă avantajul de separare a celor 2 componente, WPF permite realizarea unor interfețe grafice spectaculoase deasemenea ea permite customizarea ușoară a numeroaselor controle ce stau la dispoziția implementatorilor. Există posibilități multiple de animație la nivelul controalelor și modelare 3D de bază. Alte avantaje oferite de WPF ar fi: poziționare inteligentă, grafica scalabilă (vectorială), template-uri, binding-ul etc. .

2.2.1. Controle WPF

În WPF există câteva tipuri de controale container. Un astfel de container poate găzdui orice tip de conținut (Content): string, obiect, UIElement etc. Containerele pot fi clasificate în 4 categorii:

ContentControl: poate “gazdui” un singur element copil: Content. Window deriva din ContentControl, ceea ce inseamna ca o fereastra poate gazdui doar un singur element. Elementul gazduit poate fi de orice tip (object, string, UIElement etc).

ContentControl: poate găzdui un singur element copil: Content. Window derivă din ContentControl, ceea ce înseamna că o fereastră poate găzdui doar un singur element. Elementul găzduit poate fi de orice tip (object, string, UIElement etc).

ItemsControl: Acest tip de control poate găzdui multiple obiecte, însa nu ca și Content ci ca ItemsControl. Exemple de astfel de controale: ListBox, ListView etc.

HeaderedItemsControl: Conține o colecție de elemente care au, fiecare, un header distinct. TreeView este un exemplu de element de tip. Alte controale care derivă din HeaderedItems Control sunt:Tool Bar și MenuItem

O clasă foarte importantă de controale în WPF sunt cele de tip Layout Containers. Acestea sunt, așa cum ne putem da seama din nume, containere destinate să găzduiască alte controale/obiecte. Rolul lor este acela de a găzdui, ca și conținut, mai multe elemente, spre deosebire de controalele care pot avea ca și Content un singur obiect. Conținutul este adăugat prin intermediul proprietății Children, care este o proprietate de tip colecție. Layout Containers nu au proprietatea Content. Toate elementele copil sunt adăugate folosind Children.

Layout Containers standard sunt: Panel, Grid, UniformGrid, Canvas, StackPanel, WrapPanel, DockPanel, Border, ScrollViewer, ViewBox, TabControl.

2.2.2. XAML

XAML este un limbaj de programare declarativ folosit în framework-ul .NET pentru a separa design-ul interfeței de funcționalitatea ei. Design-ul este controlat prin cod XAML, în timp ce programarea funcționalităților implementată în C# se realizează în partea de code-behind. Este un limbaj bazat pe XML și HTML, poate fi interpretat sau compilat. Extensia fișierelor ce conțin cod XAML este .xaml. Un element în XAML este o instanță a unui obiect iar atributele reprezintă proprietățile acelui obiect.

Limbajul XAML este cel care ajută la crearea unui sistem modern cu interfață ergonomică și intuitivă. Este nivelul care determină interfața produsului software, utilizatorul interacționând cu aplicația prin intermediul controalelor definite prin XAML.

2.4 Nivele ale aplicației de la interfață la baza de date

2.3. MVVM

2.3.1. Generalități

Scopul fiecărui programator este de a scrie un cod cât mai ordonat și optim. Fiecare echipă își organizează proiectul în așa fel încât acesta să fie cât mai ușor de întreținut și să poată fi înțeles cu ușurință de membrii noi ai echipei. Această practică poate fi datorată și folosirii design pattern-urilor. Știm că există numeroase astfel de reguli de organizare a codului și că odată aleasă una dintre ele, este greu și costisitor ca aceasta să fie schimbată.

MVVM – a fost conceput să folosească data binding în WPF, pentru a facilita separarea de UI, renunțând în marea parte la code behind-ul din View. Avantajele sunt clar vizibile, și ar fi un pattern de urmat în orice aplicație dezvoltată în WPF. Sopul acestui pattern e de a separa Interfața Grafică (fie ea markup sau cod) – View, de logica de business (backend) – Model. ViewModel-ul e responsabil să facă legătura între cele două, expunând datele din Model în așa fel încât să fie consumate de View, descriind în același timp logica.

Ca structură, acesta este alcătuit din trei părți esențiale ce pot fi deduse și din denumirea design pattern-ului: un Model, un View și un ViewModel. Această structură seamană cu cea a MVC-ului, dar oferă în plus ușurința utilizării XAML-ului și a Windows Presentation Foundation, prin cuplarea datelor cât mai aproape de Model folosind XAML, View Model și orice verificare de date a nivelului Business pentru a valida datele înaintea afișării acestora pe interfață.

View-ul comunică doar cu ViewModel-ul, în timp ce ViewModel-ul este privit ca un punct intermediar între View și Model. De asemenea, Modelul este singurul care interacționează cu baza de date. Acest model are sens în practică doar dacă se folosește în combinație cu o bază de date. Alte două funcționalități care fac ca acesta să fie atât de des folosit sunt data template-urile și resursele de sistem. Template-urile aplică View-uri asupra obiectelor unui ViewModel. Programatorii pot să le declare în XAML și să lase resursele de sistem să localizeze în mod automat iar apoi să aplice acele template-uri la runtime.

2.5 Diagrama de comunicare componente MVVM

2.3.2. Model

Model – reține logica ce ține de domeniul aplicației, accesul la date și entități. Obiectul View se leagă (binding) la proprietățile obiectului ViewModel care în schimb expune datele conținute în Model și alte stări specifice View-ului. Clasele View nu știu de existența claselor din Model în timp ce clasele ViewModel și Modelul nu știu de existența claselor View. În acest fel View-ul este pur și simplu un „client” al obiectelor ViewModel, ele putând fi foarte ușor înlocuite cu clase de test pentru ViewModel.

2.3.3. View

View-ul este partea care definește modul în care va arăta aplicația. De asemenea se vor defini două DataTemplate-uri, unul pentru model și unul pentru viewmodel. View-ul trimite comenzi către ViewModel.

2.6 Comanda View – ViewModel

2.3.4. View-Model

ViewModel-ul va conține toată partea de care are nevoie utilizatorul pentru a interacționa cu aplicația. Aici se pot pune sortările, ștergerile din listă sau orice alte operațiuni necesare. Tot aici apare și clasa RelayCommand, care implementează INotifyPropertyChanged, esențială pentru ca MVVM să funcționeze. Aceasta conține o comandă ce va fi executată de alte clase pentru a rula cod în clasa de bază prin invocarea de delegates.

2.7 Binding ViewModel – View

2.4 Librăria Aforge .NET

Aforge .NET este o librărie open-source destinată dezvoltatorilor și cercetătorilor din domeniul inteligenței artificiale – de prelucrare a imaginii, rețele neuronale, algoritmi genetici, logica fuzzy,robotică etc.

Librăria cuprinde codul sursă al claselor ce sunt puse la dispoziție precum și exemple de aplicații ce indică metode de utilizare a librăriei. Aceasta cuprinde suport pentru următoarele:

Procesare de imagini;

Procesare de fișiere video;

Prelucrare de imagini de la camere conectate la USB sau camere IP folosind API-ul Microsoft Direct-Show;

Logica Fuzzy;

Rețele neuronale;

Viziune artificială;

Algoritmi genetici;

Robotică [2]

Librăria este în curs de dezvoltare, aceasta dispune de o documentație foarte bine pusă la punct cu exemple cât mai sugestive pentru dezvoltatori. Documentația se găsește pe site-ul oficial al librăriei http://www.aforgenet.com/framework/documentation.html.

Vom utiliza această librărie pentru următoarele sarcini:

Generare imagine .JPG ce conține testul grilă

Detectare forme geometrice în imaginea capturată – pentru verificarea hașueri

Conectarea aplicației la camera WEB – pentru captare imagine

Capitolul 3.

ANALIZĂ ȘI PROIECTARE

3.1. Analiza și proiectarea sistemului de testare și evaluare automată

Componente hardware

Structura software

Figura 3.1 Arhitectură sistem de testare și evaluare automată

3.1.1 Proiectarea hardware

Proiectarea Sistemului de testare și evaluare automată a fost realizată în două mari etape, proiectarea sistemului hardware și sistemului software. S-a dorit un sistem rapid, eficient și de costuri minime. Din punct de vedere a componentelor hardware, avem nevoie de un calculator personal/laptop care să suporte sistemul de operare Windows 7 și o cameră web cu conexiune USB 2.0, de rezoluție 1280 x 720 pixeli.

În această aplicație, am utilizat Camera Web Microsoft LifeCam HD-300. Este o cameră ce se bazează pe tehnologia TrueColor. Camera permite capturea imaginilor de rezoluție 1280×720 de pixeli.

3.1.2 Proiectarea software

Sistemul este implementat utilizând o arhitectură pe trei nivele (eng. 3-Layer architecture) prin care funcționalitatea sistemului, interfața utilizatorului, și gestionarea datelor sunt module separate. Sistemul va conține următoarele nivele:

Figura 3.2 Shema generală a arhitecturii software

Nivelul Datelor – este nivelul cel mai de jos, responsabilitatea principală al acestui nivel este de a stoca date, oferind siguranță datelor și conexiune rapidă. În acestă aplicație s-au proiectat un număr de 8 tabele, cu relații definite pentru fluiditatea datelor.

Nivelul aplicație – are rol de procesare a datelor din baza de date în funcție de cerințele primite de la interfața utilizatorului. Este nivelul ce are gradul cel mai mare de dificultate din aplicație și este cea mai complexă parte a ei. Nivelul aplicației face schimbul de informații dintre interfața utilizatorului și baza de date. În nivelul aplicației regăsim clasele model din care a fost generată baza de date cu ajutorul unui ORM care este un mod de abordare conceptual de un nivel înalt, utilizat pentru modelarea datelor care descriu domeniul aplicației. Tot la nivelul aplicației se stabilesc nivele de acces pentru aplicație, se generează fișierul PDF cu testele grilă asignate studenților selectați,se procesează imaginea capturată a testului grilă în vederea calculului punctajului și se calculează punctajul, apoi se salvează în baza de date pentru înregistrarea corespunzătoare studentului identificat.

Nivelul prezentare–este nivelul cel mai înalt, cu care interacționează utilizatorul. Funcționalitatea de bază al acestui nivel este gestionarea interacțiunii utilizatorului cu sistemul. Expriența utilizatorului este un aspect foarte important în aplicația realizată.În această aplicație, fiecare parte de “View” a fost construită de la zero, fără a se folosi templaturi pentru design. S-au folosit controale din Ribbon Control Library, pentru realizarea meniului, care au fost customizate atât din punct de vedere al așezării în pagină cât și al design-ului. Pentru fiecare buton în parte s-a ales dintr-o listă de imagini, care a fost inclusă în aplicație.

3.2. Analiza componentei de corectare a testului grilă

Scopul principal al acestei aplicații este genrarea respectiv evaluarea testelor grilă. În vederea evaluării, se vor urma următorii pași:

Capturare imagine

Transformăre imagine capturată, în vederea detecției pătratelor ce corespund variantelor de răspunsuri (grayscale și threshold)

Procesarea imagine rezultată în urma transformării, detecție și verificare căsuțe pline

Detecție cod QR, decodificarea cod, obținere studentul și variantă primită

Validare și salvare punctaj pentru studentul identificat

3.2.1 Prezentare algoritm de determinare a răspunsului hașurat

Pentru determinarea punctajului obținut, un pas esențial, care trebuie gândit cu deosebită atenție este cel de detecție a răspunsurilor hașurate de student. Pentru acest pas, s-au detectat formele geometrice patrulatere din aplicație, cu înălțime și lățime cuprinsă între 10-20 de pixeli. Detecția patrulaterelor s-a realizat cu clasa BlobCounter și metodele aferente, din librăria Aforge.NET.

BlobCounter detectează pătratele din imagine și obține o structură ce conține coordonatele lor. Se parcurg fiecare pătrat pixel cu pixel, începând colțul din stânga, și s-a calculate culoarea medie din interiorul căsuței. Astfel s-a obținut valoarea 1 pentru căsuțele pline și 0 pentru cele goale, necompletate.

Componentele RGB, al unui pixel,respectă următoarele relații:

, ,;

r + g + b = 1;

unde R – roșu, G – verde, B – albastru

Spațiul de culori – reprezentarea fiecărui pixel de pe o coordonată spațială (x,y) din scenă prin culoarea sa, descrie un vector de 3 componente:

U(x,y)=[R(x,y) G(x,y) B(x,y)]T

Figura 3.3 Spațiul culorilor în modelul RGB

În oricare poziție spațială din scenă, avem un punct într-un spațiu 3D al culorilor în spațiul RGB.

Distanța de culoare ∆E* dintre două culori, reprezintă distanța geometrică (Euclidiană) dintre punctele corespunzătoaredin spațiul culorilor

∆E*(x,y) = ;Px și Py – doi pixeli RGB

Determinarea hașurei unui răspuns:

Se localizează răspunsul(pătratul) în imagine

Se determină componentele R,G,B

Se parcurge pătratul pixel cu pixel

Se calculează distanța Euclidiană a fiecărui pixel față de culoarea neagră

Se calculează distanța Euclidiană a fiecărui pixel față de culoarea albă

Se compară cele 2 distanțe, distanța cea mai mică determină culoarea pixelului

Se face media culorilor fiecărui pixel din interiorul pătratului

Răspuns hașurat – culoare medie pixeli din pătrat este alb

3.2.2 Cod QR și Librăria Zxing

Codul QR(Quick Response) este un cod de bare, bidimensional, de tipul matrice. Este o formă rapidă și ușoară de a accesa informații. Un cod QR poate stoca un maxim de 7.089 caractere numerice și 4.296 de caractere alfanumerice.

Folosirea codului QR este esențială în această aplicație pentru detectarea Studentului și a Variantei testului fotografiat. Codul este generat cu ajutorul Librăriei Zxing, care este o librărie open-source destinată dezvoltatorilor de aplicații implementate în C#, VB, Java etc. Acesta are support atât pentru generare cât și pentru decodificarea codului QR.

Codul QR este așezat în colțul drept al testului generat. El conține StudentID, VariantaID și GeneratedTestID.

Exemplu cod, pentru utilizarea Librăriei Zxing:

//Generate QR Code image

BarcodeWriter BW = new BarcodeWriter();

BW.Format = BarcodeFormat.QR_CODE;

//BW.Write -> method parameter is a string, whici are the Student, Variant and //GeneratedeTest IDs

var bitmap = BW.Write(studentID + "/" + variantID + "/" + generatedtestID);

using (Graphics g = Graphics.FromImage(bm))

{

g.DrawImage(bitmap,bm.Width*70/100,bm.Height*3/100); // desenare cod QR

}

3.3. Arhitectura componentei software

Scopul generării și corectării testelor grilă este de a minimiza erori ce apar din cauza umană. Soluția proiectată are două mari responsabilități:

Generează teste din setul de întrebări ce sunt stocate în baza de date, pentru studenții selectați

Corectarea testului, ce a fost fotografiat, cu introducere punctajului în mod automat în tabela din baza de date ce reține ID-ul studentului și ID-ul variantei.

Figura 3.4 Diagrama bloc a modulului de corectare

3.3.1 Schema bazei de date

Baza de date a fost generată cu Entity Framework. Baza de date este SQL Server Express. Este accesibilă din aplicație prin intermediul unui Context ce conține doar entitățile pe care dorim să le expunem pentru modificare. Baza de date conține 9 tabele. Relațiile dintre tabele se observă în figura de mai jos :

Figura 3.5 Schema bazei de date a aplicației

Descrierea tabelelor din baza de date:

Users – stochează informații legate de user cum ar fi numele utilizatorului, parola și rolul acestuia(Admin – Comun). Câmpul Admin este de tipul “bit”, o înregistrare în baza de date a unui utilizator va alea setat Admin pe true, dacă utilizatorul are rolul de Administrator, va fi false dacă utilizatorul va fi unul comun.

Students – stochează informații legate de studenți. Identificatorul unic a tabelei este StudentID ce se regăsește ca și cheie străină în tabela Examen. Informații stocate despre studenți sunt : nume, prenume, vârstă, CNP, Adresa:țara, oraș, stradă, număr și număr de telefon.

Questions – această tabelă are cheia unică de identificare QuestionID, ce este cheie străină în tabela Answers , ea mai conține textul întrebării. O întrebare are 5 variante de răspunsuri ce pot fi răspunsuri corecte multiple, aceste răspunsuri vor conține ID-ul întrebării căruia îi aparțin, și un indicator(bit) true sau false pentru identificarea răspunsurilor corecte.

Answers – conține textul răspunsului cât și indicator true sau false pentru fiecare răspuns în parte, pentru identificarea răspunsului corect. Este legată de tabela Questions prin cheia străina QuestionID. Fiecare răspuns, din baza de date, va avea setat câmpul Correct,de tipul bit, cu true dacă răspunsul este corect, respectiv cu false, dacă răspunsul este incorect. O înregistrare din tabela Answers, va conține și QuestionID pentru a arăta cărei întrebări îi aparține.

Variants – tabela ce reține variantele de testare, are identificatorul unic VariantID, acesta, este cheie străină în tabela GeneratedTests. Legătura dintre o variantă și întrebările ce le conține se realizează prin tabela de legătură VariantQuestion – unde sunt reținute ID-urile variantei și întrebărilor ce îi aparțin.

VariantQuestion – acesta este tabela de legătură între Variante și Întrebări, ea conține cheie străină ce provine din tabela Variants și cheie străină din tabela Questions. Această tabelă permite folosirea aceluiași set de întrebări pentru generarea diferitelor variante de teste.

GeneratedTests – este o tabelă ce conține rezultatul final în urma corectării testelor grilă. Ea conține chei străine din tabela Students, Variants, deasemenea, mai conține data la care s-a generat testul grilă, Date, și câmpul Scor, ce reține punctajul obținut al studentului. Câmpul Score,este completat după ce testul este generat și corectat, în mod automat.

Relațiile dintre tabele GeneratedTests – Variants – Questions – Answers se vor înțelege mai bine după analiza figurii de mai jos:

Figura 3.6 Relație Test Grilă – Întrebări

Capitolul 4.

IMPLEMENTAREA PROBLEMEI. DESCRIEREA PROCESULUI

4.1.Implementarea algoritmului

Aplicația este implementată în limbajul de programare C#. Mediul de dezvoltare a sistemului este Visual Studio 2012. Microsoft Visul Studio este un mediu de dezvoltare integrat (IDE – integrated development environment) de la Microsoft. Acesta poate fi folosit pentru a dezvolta aplicații consolă și aplicații cu interfață grafică pentru toate platformele suportate de Microsoft Windows.

Microsft Visual Studio oferă editor, compilator/debugger și mediu de proiectare (designer) pentru mai multe limbaje de programare. Limbaje de programare incluse : Microsoft Visual C++, Microsoft Visual C#, Microsoft Visual Basic, Microsoft Visual Web Developer, Team Foundation Server.

Pe lângă limbajele amintite anterior, Microsoft Visual Studio oferă suport și pentru alte limbaje, cum ar fi : Python, Ruby. Deasemenea, sprijină XML/XSLT, HTML/XHTML, JavaScript și CSS.

Algoritmul implementat

Algoritmul pentru implementarea aplicației,în vederea generării și corectări automate a testelor grilă, sunt descriși în pseudocod în felul următor:

Stocare date – operații: modificare, ștergere și adăugare

1.1 Studenți

1.2 Set de întrebări

Generare variantă din setul de întrebări(aleator) – operații: ștergere, generare

Generare examen

3.1Selectare listă de studenți din baza de date

3.2 Generare fișier PDF cu varianta asignată fiecărui student

3.2.1 Generare imagine

3.2.2 Desenare căsuțe corespunzător număr de întrebări a variantei

3.2.3 Adăugare antet – generare cod QR ce reține ID-ul studentului și varianta asignată

3.2.4 Adăugarea imaginilor într-un fișier PDF și salvarea fișierului C://Desktop/TesteGenerate/test_datacurentă.pdf

3.3 Salvare entitate exemn în baza de date – nume student, variantă , data curentă

4. Corectare test grilă

4.1 Capturare imagine

4.2 Procesare imagine

4.2.1 Pregătire imagine pentru calcul punctaj(transformări alb-negru, threshold)

4.2.2 Detecție pătrate corespunzătoare răspunsurilor

4.2.3 Verificare hașură

4.2.4 Citire cod OR – detecție student, variantă

4.2.5 Comparare răspunsuri hașurate cu răspunsuri corecte ale variantei detectate

4.2.5 Calcul punctaj obținut

4.3 Completare entitate examen din baza de date cu punctajul obținut

4.1.1. Pașii pentru crearea unui proiect în mediul de dezvoltareVisual Studio 2012

Se deschide mediul de dezvoltare Microsoft Visual Studio 2012. Se alege din meniul

File -> New->Project

Figure 4.1.1

Figure 4.1.2

Se alege WPF Applicationși apoi se completează câmpul Name: cu numele dorit pentru aplicație.

4.1.2 Implementarea design pattern-ului MVVM

Pentru implementare design pattern-ului MVVM, ca și un prim pas este crearea fișierelor ce vor deține clasele pentru fiecare modul în parte.

Figure 4.1.3

Structura fișierelor ce țin de MVVM este prezentată în figura de mai jos:

Figure 4.1.4

4.1.2.1 Generare baza de date din Model(code first)

Folderul Modelconține clasele ce corespund tabelelor din baza de date. Fiecare tabelă este reprezentată printr-o clasă, ce conține proprietăți care reprezintă câmpurile din tabelă.

Adăugarea unei clase se face în felul următor:

Figure 4.1.5

Câmpul Name se completează cu numele clasei. Un exemplu de clasă de tipul Model, este cel din figura de mai jos, ce corespunde setului de întrebări.

Figura 4.1.6

[Key] – este o adnotaret folosită pentru identificarea cheii primare de către Entity Framework.Entity Frameworkmapează clasele din C# , creazătabele SQL Server. Există mai multe tipuri de adnotăricare au fost folosite în implementarea aplicației, de exemplu : [Key](cheie primar), [ForeignKey](cheie străină), [Required](câmp ne-null), [MaxLenght(13)](lungime maximă 13 caractere), [MinLenght(10)](lungime minimă 10 caractere) etc.

4.1.2.2 Crearea View-urilor

Folderul View conține controale de tipul UserControl –este un element alcătuit din 2 fișiere .xaml și un fișier .cs .View-urile, la fel ca și în cazul clasic se referă la partea vizuală care va fi afișată pe interfața grafică, cum ar fi butoanele, ferestrele, graficele și alte controale. Acestea nu conțin partea de logică. Marele avantaj în acest caz este că un designer poate să se ocupe de partea grafică a aplicației lucrând doar cu view-ul, în timp ce logica din spate rămâne neafectată.[1]

Regula principală a MVVM design patternului, este de lega view-ul cu celelalte componente ale aplicației doar prin binging.Datorită acestei implementări, schimbare UI-ului este extrem de simplă, orice modificare poate fi realizată pe view, în xmls, fără ca modificarea view-ului să se reflecte în code-behind. Partea esențială, este de a preciza DataContextul UserControlului, din care View-ul își va lega părție bind-uite.

Figura 4.1.7

Figura 4.1.8

Un exemplu de View implementat este QuestionView.DataContextul QuestionView-ului este:

<UserControl.DataContext>

<local:QuestionViewModel />

</UserControl.DataContext>

Afișarea întrebărilor din baza de date se realizează cu un ListView, care este un control al WPF-ului.

<Grid>

<ListView

ItemsSource="{Binding Path=Questions}"

SelectedItem="{Binding Path=SelectedQuestion}"

ScrollViewer.HorizontalScrollBarVisibility="Auto"

ScrollViewer.VerticalScrollBarVisibility="Auto">

<ListView.View>

<GridView>

<GridViewColumn

Header="Text"

DisplayMemberBinding="{Binding Path=Text}" Width="Auto" />

<GridViewColumn

Header="A"

DisplayMemberBinding="{Binding Path=Answer.Text}" Width="Auto" />

Datele despre Întrebări sunt luate din baza de date prin intermediul DataContextului stabilit, QuestionViewModel, care pregătește datele ce trebuie bind-uite spre afișare. Observăm sintaxa ItemsSource="{Binding Path=Questions}" care leagă ListView-ul de entitatea Questions din baza de date prin intermediul ICollection-ului Questions regăsit în QuestionViewModel. În cele ce urmează, o să vedem implementarea ViewModel.

Figura 4.1.9

4.1.2.3 Crearea ViewModel-urilor

ViewModel-urile reprezintă niște modele pentru View-uri, mai precis acestea se referă la o abstractizare a View-urilor care servesc și la binding-ul datelor între View și Model. ViewModel-urile expun proprietățile publice, comenzile și abstractizările și au fost asemănate cu o stare conceptuală a datelor, spre depsebire de starea reală a datelor din model.[1]

Fișierele ce sunt în folderul ViewModel, sunt fișiere cu extensia .cs. În figurile de mai jos, sunt prezentate creare, și exemple de ViewModel-uri implementate.

Figura 4.1.10

Figura 4.1.11

Fiecare fișier .cs care este salvat în folderul ViewModel, va area ca și denumire sub forma : NumeViewModel.cs; aceeași regulă este respectată și în folderul View, denumirea fișierului arătând în felul următor : NumeView.xaml.

ViewModel-urile conțin cod ce ține de ștergerea, modificarea și salvarea datelor în baza de date. ViewModel-ul sesizează schimbările din View, el implementând interfața INotifyPropertyChanged, ce conține metoda RaisePropertyChanged care notifică View-ul sau ViewModel-ul de moficicările făcute într-una din componente.

protectedvirtualvoid OnPropertyChanged(string propertyName)

{

this.VerifyPropertyName(propertyName);

PropertyChangedEventHandler handler = this.PropertyChanged;

if (handler != null)

{

var e = newPropertyChangedEventArgs(propertyName);

handler(this, e);

}

}

publicICollection<Student> Students

{

get

{

return _students;

}

set

{

_students = value;

OnPropertyChanged("Students");

}

}

În exemplul de sus, avem o proprietate de tipul ICollection<Student> Students , care, în ramura set, apelează metoda OnPropertyChanged("Students");cu numele proprietății Students, care la rândul lui este bind-uit la un control de tipul ListView din StudentView.

ViewModel-ul recepționează comenzile din View-uri. Comanda controalelor din View-uri sunt legate de proprietăți de tipul ICommand în ViewModel-uri, care prin intermediului unui RelayCommand execută o acțiune. Clasa RelayCommand implementează interfața ICommand.

classRelayCommand : ICommand

{

privateAction<object> _execute;

privatePredicate<object> _predicate;

/////

public RelayCommand(Action<object> execute, Predicate<object> predicate)

{

_execute = execute;

_predicate = predicate;

}

///

publicvoid Execute(object parameter)

{

_execute(parameter);

}

}

În NewStudentViewModel avem proprietatea publicICommand SaveCommnad { get; set; } care este legată de comanda butonului Savedin NewStudentView.

SaveCommnad = newRelayCommand(Save, null);// apelează metoda Save

Metoda Save:

publicvoid SaveStudent()

{

_newStudent = newStudent() { Adresa = newAddress() };

_newStudent.FirstName = FirstName;

_newStudent.LastName = LastName;

_newStudent.CNP = CNP;

_newStudent.Age = Int32.Parse(Age);

_newStudent.Adresa.Country = Country;

_newStudent.Adresa.City = City;

_newStudent.Adresa.Street = Street;

_newStudent.Adresa.Number = Int32.Parse(Number);

_newStudent.Adresa.PhoneNumber = PhoneNumber;

Mediator.Instance.AppContext.Students.Add(_newStudent);

Mediator.Instance.AppContext.SaveChanges();

Mediator.Instance.UpdateStudentList();

}

4.1.2.4 Mediator

Mediator-ul este o clasă ce implementeaza Singletone design pattern, acesta este folosit pentru a limita numărul de instanțe ale clasei Mediator la un singur obiect de tipul său.

Figura 4.1.12

Mediator-ul reține toate instanțele de ViewModel și View din aplicație. El este cel ce setează ViewModel-ul curent în funcție de View-ul curent. Prin intermediul Mediator-ului comunică ViewModel-urile, de exmplu, în cazul în care dintr-un View se dorește afișarea informațiilor într-un DetailView, atunci se vor seta datele din DetailViewModel cu obiectul selectat din View-ul principal.

4.2. Descrierea claselor din aplicație

4.3. Componentele aplicației

Primul pas al utilizatorului aplicației este autentificare. Autentificare se realizează pe baza informațiilor stocate în baza de date. Pentru rolul de Administrator, funcționalitatea aplicației este completă. Un utilizator comun se diferențiază de administrator prin restricția la editarea, ștergerea seturilor de întrebări și variante. Utilizatorul comun poate să adauge/șteargă/editeze studenții din baza de date. Poate genera teste pentru studenții selectați și nu în ultimul rând, ei pot să și corecteze testele.

Pagina de autentificare arată în felul următor:

Figura 4.3.1

-pagina de adauga sterge studenti

-adauaga intrebari,

-generare variante + iText pdf generator

-selectia studentilor + pdf generat

-corectare

-stergere adauga utiliyator

Capitolul 5.

TESTE ȘI REZULTATE

Print screen cum e facuta aplicatia

Capitolul 6.

CONCLUZII

Listă de figuri

1.1. Exemplu de sistem de transport multimodal …………………………………………………………….. 6

2.1.2.1 Pașii unui algoritm genetic ………………………………………………………………………………… 11

2.1.3.1 Structura de bază a unui algoritm genetic ……………………………………………………………. 12

2.2.4.1 Exemplu de încrucișare …………………………………………………………………………………….. 16

2.2.4.2 Exemplu de cromozom …………………………………………………………………………………….. 17

2.3.1.1 Reprezentarea relațiilor între cele trei componente ………………………………………………. 20

2.3.2.1 Comportamentul modelului pasiv de MVC …………………………………………………………. 21

3.1.1 Schema generală a arhitecturii sistemului hardware ………………………………………………… 23

3.1.2 Conexiune între două calculatoare printr-un alt calculator, care servește rolul de server proxy ………………………………………………………………………………………………………………………… 24

3.2.1 Schema bloc a sistemului de monitorizare …………………………………………………………….. 25

3.3.1 Schema generală a arhitecturii pe trei nivele ………………………………………………………….. 27

3.4.1 Diagrama bloc a modulului de planificare a rutelor ………………………………………………… 29

3.4.2 Diagrama secvențială a aplicației ………………………………………………………………………….. 30

3.4.3 Diagrama de clase a aplicației ………………………………………………………………………………. 31

3.4.1.1 Exemplu de graf unidirecțional ………………………………………………………………………….. 33

3.4.2.1 Exemplu de rețea de transport multimodal ………………………………………………………….. 35

3.4.2.2 Două rute posibile de la nodul 0 la nodul 5 …………………………………………………………. 36

3.4.2.3 Codificarea cromozomului ……………………………………………………………………………….. 38

3.4.2.4 Una din rutele de la nodul 0 la nodul 4 ………………………………………………………………. 38

4.1.1.1 ………………………………………………………………………………………………………………………. 42

4.1.1.2 Fereastra New Project ……………………………………………………………………………………… 43

4.1.1.3 Butonul Next ………………………………………………………………………………………………….. 44

4.1.1.4 Adăugarea pachetului JGAP ……………………………………………………………………………. 45

4.1.1.5 ………………………………………………….. ………………………………………………………………… 46

4.1.1.6 Adăugarea unei noi clase …………………………………………………………………………………. 47

5.1 Rețeaua de transport multimodal ……………………………………………………………………………. 50

5.2Teste pentru populația = 15, număr de iterații = 20 ………………………………………………….. 54

5.3 Ruta din figura 5.2. ……………………………………………………………………………………………… 54

5.4 Teste pentru populația = 50, număr de iterații = 50 ………………………………………………….. 55

5.5 Ruta din figura 5.4. ……………………………………………………………………………………………… 55

5.6 Teste pentru populația = 75, număr de iterații = 100 ……………………………………………….. 56

5.7 Ruta din figura 5.6. ……………………………………………………………………………………………… 56

5.8 Teste pentru populația = 75, număr de iterații = 100 ………………………………………………… 57

5.9 Ruta din figura 5.8. ……………………………………………………………………………………………… 57

Listă de tabele

3.4.2. 1 Orarul rețelei de transport multimodal din figura 4.3.2. 1 ……………………………………… 37

5.1. Orarul mijloacelor de transport ………………………………………………………………………………. 51

BIBLIOGRAFIE

[1] http://www.todaysoftmag.ro/article/ro/14/Design_pattern-ul_MVVM_483

[2] http://www.aforgenet.com/framework/

BIBLIOGRAFIE

[1] http://www.todaysoftmag.ro/article/ro/14/Design_pattern-ul_MVVM_483

[2] http://www.aforgenet.com/framework/