Sistem DE Supraveghere Utilizand Camere Web
SISTEM DE SUPRAVEGHERE UTILIZÂND CAMERE WEB
1. TEMA PROIECTULUI :
Să se proiecteze o aplicație care să implementeze o soluție de supraveghere a unor locații prin conectarea unei camere web la un calculator, transmiterea numai de imagini „relevante”, în care se detectează mișcare, într-o bază de date și vizualizarea rezultatelor pe Internet.
2. CONȚINUTUL PROIECTULUI :
Introducere; Fundamentare teoretică; Descrierea aplicației; Testarea aplicației; Concluzii; Bibliografie; Anexe.
TEMA : SISTEM DE SUPRAVEGHERE UTILIZÂND CAMERE WEB
Cuprins
Capitol 1. Introducere ………………………………………………………………………………………………. 1
Tema lucrării …………………………………………………………………………………………… 1
Conținutul lucrării ……………………………………………………………………………………. 4
Documentare bibliografică………………………………………………………………………… 5
Capitol 2. Fundamentare teoretică ……………………………………………………………………………… 6
2.1. Tehnologii actuale de supraveghere ……………………………………………………………. 6
2.2. Limbaje de programare utilizate ……………………………………………………………….12
2.2.1. Limbajul C# – scurtă prezentare …………………………………………………….. 12
2.2.2. Platforma .NET …………………………………………………………………………… 15
2.2.3. Baze de date ……………………………………………………………………………….. 28
Capitolul 3 . Descrierea aplicației …………………………………………………………………………….. 36
3.1. Descrierea hadware ………………………………………………………………………. 36
3.2. Descrierea software ……………………………………………………………………… 53
3.2.1. Algoritm de detecție a mișcării …………………………………………… 61
3.2.2. Protocoale de comunicație …………………………………………………. 64
3.3. Descrierea interfeței ……………………………………………………………………… 70
Capitolul 4. Testarea aplicației ……………………………………………………………………………….. 77
Capitolul 5. Concluzii ……………………………………………………………………………………………. 88
Bibliografie …………………………………………………………………………………………………………….. 90
ANEXE
CAPITOLUL 1
INTRODUCERE
Tema lucrării
Pentru orice obiectiv economic, indiferent de dimensiunea acestuia, securitatea este de multe ori o problema vitală. Firmele sunt nevoite să investească sume considerabile pentru crearea unor infrastructuri care să le permită supravegherea spațiilor în care își desfășoară activitatea.
Având în vedere că aproape orice firmă, indiferent de domeniul de activitate, număr de salariați sau cifra de afaceri are cel puțin un calculator, iar în majoritatea cazurilor acesta nu este singurul, se pune problema creării rețelelor de calculatoare. Astfel două, douăzeci, două sute sau chiar mai multe calculatoare formează rețele în care angajații firmei își distribuie datele beneficiind de rate de transfer din ce în ce mai ridicate și de un nivel deosebit de securitate al acestora.
Proiectul de față propune o nouă soluție în ceea ce privește supravegherea video a spațiilor în care firmele își desfașoară activitatea : conectarea la un calculator a unei camere web și transmiterea numai de imagini „relevante" într-o bază de date. Existența unor calculatoare și de cele mai multe ori a rețelelor de calculatoare implică costuri net inferioare dotării cu sisteme independente de supraveghere video, metoda propusă presupunând achiziția doar a unei camere web pentru o locație care se dorește a fi supravegheată. Se elimină astfel dezavantajul achiziționării unui sistem convențional de supraveghere, în componența acestuia intrând și alte elemente, dintre care pot fi enumerate plăci de captură sau DVR-uri (Digital Video Recorder), surse de alimentare precum și personalul care să supravegheze funcționarea acestora. Punctul forte al sistemului propus constă în faptul că reține doar imaginile „relevante" adică acele cadre în care a fost detectată „mișcare" și nu stochează informație redundantă, precum și faptul că această informație poate fi accesată prin Internet de persoane autorizate.
Lucrarea de față are ca obiectiv dezvoltarea unei aplicații client-server de supraveghere a mai multor locații. Prima parte este reprezentată de fundamantarea teoretică ce cuprinde informațiile necesare definirii domeniului abordat. Astfel sunt descrise câteva tehnologii actuale de supraveghere precum și domeniile în care pot fi ele utilizate, tehnologiile și uneltele software utilizate la implementarea propriu-zisă a aplicației, care face obiectul celei de-a doua părți a materialului.
Obiectivul principal al acestei aplicații este acela de a permite supravegherea unei locații cu ajutorul unei camere web instalată pe un calculator din acea locație și vizualizarea rezultatelor pe Internet. Aplicația are o largă arie de utilizabilitate, pe lângă supravegherea unor spații comerciale, a unor birouri sau a unor puncte importante din cadrul unor societăți, aceasta putând fi utilizată în realizarea așa numitelor „vizite virtuale”. Astfel bunicii pot vedea ce face nepotul lor, un medic poate vedea ce face pacientul lui, un părinte aflat la serviciu poate vedea ce face copilul lui acasa ș.a.m.d.
Fig. 1.1. Structura sistemului de supraveghere
În sistemul propus fiecare cameră din fiecare locație supravegheată trimite cadre „relevante” în baza de date, acestea putând fi vizualizate pe pagina de Internet creată. Este un sistem eficient și foarte ușor de folosit. Un utilizator poate vizualiza rezultatele unei operațiuni de monitorizare a unei locații numai dacă are drepturile necesare pentru aceasta, de oriunde din rețea. Necesită resurse hardware minime, este ușor de utilizat fiind prevăzută cu o interfață grafică prietenoasă.
Implementarea software este realizată în limbajul de programare C#, iar baza de date în SQL SERVER 2005 și are două mari părți:
Aplicația server – care reprezintă baza de date și serviciul web care trimite cadrele „relevante” în această bază de date. Aceasta stochează informații despre fiecare utilizator al aplicației, despre camerele web din locațiile care sunt supravegheate, despre drepturile de vizualizare ale utilizatorilor și despre cadrele primite de la o anumită locație. Tot aici se verifică autenticitatea operațiilor pe care utilizatorii le efectuează, semnalându-se eventuale fraude.
Aplicația client – gestionează camera web instalată pe un anumit calculator dintr-o anumită locație.
Avantajele folosirii unui astfel de sistem sunt:
Ușurință în utilizare;
Ușurință la instalare;
Extensibilitate;
Flexibilitate;
Utilizare minimă de spațiu de stocare;
Resurse hardware minime.
Conținutul lucrării
Lucrarea este structurată pe 5 capitole, având o anexă cu detalii software.
Capitolul 1 „Introducere” prezintă informații despre tema proiectului împreună cu o scurtă descriere a acestuia, obiectivul aplicației, amintind pe scurt limbajul de programare utilizat la dezvoltarea aplicației.
Capitolul 2 „Fundamentarea teoretică” prezintă la debut informații generale despre tehnologiile actuale de supraveghere, continuând cu o comparație între un sistem care folosește o tehnologie actuală de supraveghere și unul care folosește aplicația dezvoltată în acest proiect. În ultima parte a fundamentării teoretice sunt detaliate uneltele software ce vor fi utilizate pentru dezvoltarea aplicativă care face obiectul capitolului 3. Aici sunt prezentate informații generale despre limbajul de programare C#, platforma .NET cu două componente foarte importante ale sale, ADO.NET și ASP.NET utilizate și o scurtă prezentare a limbajului SQL.
Capitolul 3 „Descrierea aplicației” prezintă în detaliu etapele parcuse pentru dezvoltarea finală a aplicației. În partea de început a acestui capitol este redată organizarea aplicației cu organigrama acesteia atât din punct de vedere a structurii software cât și a structurii hardware. Cele două mari părți componente ale dezvoltării, aplicația server și aplicația client, sunt descrise în detaliu aici.
Capitolul 4 „Testarea aplicației” demonstrează că aplicația este funcțională și prezintă toate valențele acesteia pentru a fi ușor de manipulat de către un alt utilizator.
Capitolul 5 „Concluzii” cuprinde ideile cele mai importante desprinse în urma realizării acestei lucrări, precum si precizarea eventualelor tendințe de dezvoltare a acestei realizări software.
Documentare bibliografică
Pentru prima parte a acestui proiect au fost parcurse o serie de lucrări din domeniul supravegherii video și a documentației tehnologiilor software utilizate. Dintre acestea, pot fi amintite:
Melnic Vladimir : „Sisteme electronice de supraveghere”, București, Ed. Teora, 2001;
Popescu Laurențiu, Tuleș Viorel : „Sisteme de detecție, supraveghere video și de monitorizare control acces și comunicații”, București, Ed. Polirom, 2008;
Petzold Charles: „Programare Windows cu C#”, București, Ed. Teora, 2005;
Richter Jeffrey : „Microsoft .NET Framework”, București, Ed. Teora, 2007;
Dollinger Robert, Andron Luciana : „Utilizarea sistemului SQL Server”, București, Ed. Albastră, 2005;
Henderson Ken : „Transact-SQL”, București, Ed. Teora, 2006.
CAPITOLUL 2
FUNDAMENTARE TEORETICĂ
Tehnologii actuale de supraveghere
În cadrul sistemelor de supraveghere un loc tot mai important îl ocupă sistemele de supraveghere video. Acest tip de aparatură se folosește în cadrul unor obiective cu nivel de siguranță mai mare. Urmărirea se realizează folosind camere video care sunt monitorizate de la un centru de supraveghere local sau de la centre de dispecerizare aflate la distanță, de unde se coordonează echipele de intervenție. Există și soluții de folosire combinată a sistemelor de efracție cu senzori de mișcare, cu sisteme de supraveghere cu camere video, caz în care monitorizarea camerelor se face numai la declanșarea sistemului de alarmă ceea ce permite economisirea spațiului de memorare a imaginilor și totodată dă posibilitatea identificării eventualelor persoane care ar pătrunde prin efracție, precum și localizarea lor pentru a susține logistic acțiunea echipelor de intervenție. Prin această combinație de sisteme se elimină și deplasarea inutilă a mașinilor de intervenție în cazul unor alarme false.
Aparatura folosită în supravegherea video este formată dintr-un număr de camere video a căror semnale se centralizează în dispozitive de prelucrare și înregistrare. Rezultatul prelucrării se înregistrează pe dispozitive de stocare sau se afișează pe monitoare ori se transmite în formă comprimată la dispeceratele de supraveghere.
Majoritatea camerelor video sunt realizate cu matrici de CCD-uri (Charged Coupled Devices) de rezoluție medie, alb-negru sau color, unele dintre ele având și o cale de sunet încorporată în ele. Semnalul furnizat de camere se transmite pe cabluri coaxiale, dar există și varianta cu transmisie radio, caz în care sunt necesare echipamente suplimentare. Diferențele de preț ale camerelor video se reflectă în calitatea sistemelor, la numărul de pixeli afișați, numărul de linii pe cadru, tipul și calitatea lentilelor folosite precum și distanța f „Sisteme electronice de supraveghere”, București, Ed. Teora, 2001;
Popescu Laurențiu, Tuleș Viorel : „Sisteme de detecție, supraveghere video și de monitorizare control acces și comunicații”, București, Ed. Polirom, 2008;
Petzold Charles: „Programare Windows cu C#”, București, Ed. Teora, 2005;
Richter Jeffrey : „Microsoft .NET Framework”, București, Ed. Teora, 2007;
Dollinger Robert, Andron Luciana : „Utilizarea sistemului SQL Server”, București, Ed. Albastră, 2005;
Henderson Ken : „Transact-SQL”, București, Ed. Teora, 2006.
CAPITOLUL 2
FUNDAMENTARE TEORETICĂ
Tehnologii actuale de supraveghere
În cadrul sistemelor de supraveghere un loc tot mai important îl ocupă sistemele de supraveghere video. Acest tip de aparatură se folosește în cadrul unor obiective cu nivel de siguranță mai mare. Urmărirea se realizează folosind camere video care sunt monitorizate de la un centru de supraveghere local sau de la centre de dispecerizare aflate la distanță, de unde se coordonează echipele de intervenție. Există și soluții de folosire combinată a sistemelor de efracție cu senzori de mișcare, cu sisteme de supraveghere cu camere video, caz în care monitorizarea camerelor se face numai la declanșarea sistemului de alarmă ceea ce permite economisirea spațiului de memorare a imaginilor și totodată dă posibilitatea identificării eventualelor persoane care ar pătrunde prin efracție, precum și localizarea lor pentru a susține logistic acțiunea echipelor de intervenție. Prin această combinație de sisteme se elimină și deplasarea inutilă a mașinilor de intervenție în cazul unor alarme false.
Aparatura folosită în supravegherea video este formată dintr-un număr de camere video a căror semnale se centralizează în dispozitive de prelucrare și înregistrare. Rezultatul prelucrării se înregistrează pe dispozitive de stocare sau se afișează pe monitoare ori se transmite în formă comprimată la dispeceratele de supraveghere.
Majoritatea camerelor video sunt realizate cu matrici de CCD-uri (Charged Coupled Devices) de rezoluție medie, alb-negru sau color, unele dintre ele având și o cale de sunet încorporată în ele. Semnalul furnizat de camere se transmite pe cabluri coaxiale, dar există și varianta cu transmisie radio, caz în care sunt necesare echipamente suplimentare. Diferențele de preț ale camerelor video se reflectă în calitatea sistemelor, la numărul de pixeli afișați, numărul de linii pe cadru, tipul și calitatea lentilelor folosite precum și distanța focală a obiectivelor, raportul semnal-zgomot, iluminarea minimă necesară, tensiunea de alimentare, dimensiuni mecanice, greutate, consumul mediu, temperaturi de funcționare și stocare.
Dintotdeauna oamenii au vrut să se simtă protejați , să știe că cineva veghează la siguranța lor și la bunul mers al lucrurilor atât acasă, la locurile lor de muncă, cât și în zonele unde își petrec timpul liber. În zilele noastre supravegherea a devenit necesară.
Datorită societății și vremurilor în care trăim aș putea spune că supravegherea locurilor publice, a mijloacelor de transport, a locuințelor, a spitalelor este imperios necesară pentru că nimeni nu mai este în siguranță nicăieri.
De aceea specialiștii în domeniu caută în fiecare zi tehnologii cât mai avansate și moderne de supraveghere.
Una dintre cele mai noi tehnologii de supraveghere este cea bazată pe IP. Aceasta oferă soluții de calitate superioară pentru securitate și monitorizare de la distanță, prin simpla conectare la o rețea de Internet sau wireless. Aceste soluții au aplicabilitate în diferite domenii:
Domeniul bancar
Sistemele de supraveghere bazate pe IP oferă funcționalitatea și siguranța necesare protejării angajațiilor și bunurilor, verificarea tranzacțiilor și evitarea alarmelor false. Datorită imaginilor de calitate superioară care fac posibilă identificarea persoanelor, urmărirea tranzacțiilor la ATM-uri și a casierului, se reduce atât riscul fraudelor cauzate de hoți cât și de angajați. Camerele legate în rețea cu detector de mișcare trimit imagini prin e-mail sau MMS poliției sau personalului de la supraveghere în cazul unei spargeri. Pentru organizațiile cu sucursale disperse, imaginile se pot transmite la sediul central prin LAN sau Internet. Sistemul de supraveghere poate consta în oricâte camere și poate fi extins ușor prin adăugarea de camere.
Datorită unor sisteme de securizare a rețelelor, firewall și parole, datele obținute cu ajutorul camerelor de supraveghere pot fi transmise fără ca acestea să fie afectate. Sistemele de supravegere pot fi utilizate și pentru a strânge informații despre clienții și utilizatorii de ATM-uri, iar în cazul unor tentative de fraudare aceste imagini pot fi folosite.
Educație
Profesorii, părinții și elevii doresc securitate în cadrul instituțiilor de învățământ. Prezența camerelor de supraveghere în școli reduce riscul unor atacuri sau hărțuiri asupra elevilor sau a angajațiilor. Camerele pot fi montate atât în interiorul clădirilor cât și în exterior, oferindu-se siguranță pe tot perimetrul școlii. În afara orelor de curs același sistem poate fi folosit pentru supravegherea proprietății și eliminarea șanselor de deteriorare a bunurilor. Cu ajutorul unui sistem care detectează mișcarea se pot transmite automat imagini persoanelor responsabile de securitate sau poliției.
O inovație în domeniu ar fi transmiterea în direct a cursurilor, elevilor care nu pot participa personal la prelegere prin intermediul unui calculator legat la internet.
Transport
Pentru îmbunătățirea condițiilor în mijloacele de transport, monitorizarea traficului și vizualizarea stării drumurilor în timp real se pot folosi camere de supraveghere bazate pe transmitere la distanță prin IP. Imaginile de calitate superioară, funcționarea în orice condiții de temperatură sau alarma automată la mișcarea camerei duc la creerea unui mediu sigur. Aeroporturile, stațiile de metrou sau tren trebuie monitorizate pentru evitarea posibilelor amenințări sau reducerea accidentelor.
Monitorizarea aeroporturilor
Aeroporturile se confruntă cu atacuri teroriste, reguli stricte, iar personalul trebuie să opereze foarte rapid, ceea ce nu lasă loc greșelilor. Sistemele de supraveghere ajută la creșterea siguranței în incinta aeroporturilor. Oferă monitorizare în timp real în diferite secții, iar imaginile se pot accesa de pe calculatoare separate. Stocarea imaginilor se face digital, ceea ce oferă posibilitatea arhivării de cantități nelimitate și vizualizarea lor se poate face de pe orice calculator cu acces la Internet.
b. Monitorizarea autobuzelor
În autobuze, unde singura persoană responsabilă de siguranța pasagerilor este șoferul este greu să se mențină un nivel ridicat de securitate. Folosite pentru abaterea activitățiilor criminale și a comportamentului inadecvat, camerele oferă pasagerilor și șoferilor mai multa siguranță.
c. Monitorizarea traficului
Plasate de-a lungul drumurilor sau a intersecțiilor aglomerate de pe drumurile naționale, sistemele de monitorizare a traficului sunt foarte populare. Imaginile în timp real oferă informații actualizate despre trafic, iar în cazul acidentelor sau devierii circulației buletinele informative despre trafic le pot oferi prin intermediul radio sau TV. Poziționarea vizibilă a camerelor descurajează șoferii să încalce regulamentul.
Sănătate
În spitale sau alte locuri care oferă îngrijire medicală, camerele de supraveghere nu sunt folosite doar pentru creșterea siguranței, prevenirea violenței sau intrării prin efracție ci și pentru monitorizarea vizitatorilor. Prezența camerelor poate îmbunătăți comunicarea între secțiile spitalelor și reducerea plângerilor nejustificate. Facilitățile oferite de acest sistem de supraveghere sunt: rezolvarea disputelor între angajați, monitorizarea în timp real a secțiilor și accesul la aceste imagini de pe orice calculator cu acces la rețea, imaginile pot fi folosite ca probă pentru investigații în cazul unei crime. Acestea folosesc servere unde sunt ținute date despre pacienți, documentație și date obținute în urma cercetărilor. Una din utilitățile oferite de sistemele de supraveghere este fapul că permite vizualizarea de imagini a ceea ce se petrece în camera serverelor și pot avertiza în cazul în care este detectată mișcare neautorizată.
Nu este de neglijat nici soluția convențională de supraveghere cu camere video și transmiterea informațiilor prin cablu coaxial către placa de captură sau DVR (Digital Video Recorder). Aceasta este folosită cu succes în diverse domenii, dar totuși are anumite dezavantaje față de tehnologiile noi inventate în domeniul supravegherii.
În continuare este prezentată o comparație între un sistem clasic de supraveghere și un sistem care utilizează aplicația dezvoltată în acest proiect.
Sistem clasic de supraveghere
Pentru un sistem clasic , convențional de supraveghere al unei incinte avem nevoie de următoarele componente ׃
un calculator ;
o placă de captură și soft-ul aferent ;
o cameră video ;
cablu coaxial pentru conectarea camerei video la unitatea de stocare date , respectiv placa de captură a unui PC sau DVR (Digital Video Recorder – dispozitiv specializat pentru stocarea de imagini). În cazul în care distanța dintre camera video și unitatea de stocare este mai mare de 100 de metri se folosește cablu UTP (Unshielded Twisted Pair – cablu cu perechi răsucite neecranat).
video – baloon : dispozitiv de conversie între cablul UTP și coaxial (doar în cazul în care se folosește cablu UTP) ;
o mufă BNC și una F;
o sursă de alimentare de 12 V pentru alimentarea camerei video cu posibilitate de atașare a unui acumulator de 12 V/7 Ah pentru cazurile în care este oprită tensiunea de la rețea ;
un UPS (Unninteruptible Power Supply) – pentru unitatea de stocare a datelor (DVR sau PC) în cazul în care este oprită tensiunea de la rețea.
Sistem de supraveghere care folosește aplicația dezvoltată în acest proiect, denumită WebEye
Pentru un sistem de supraveghere care folosește aplicația WebEye avem nevoie de următoarele componente :
un calculator;
o cameră web ;
un UPS – pentru PC-ul la care se vor conecta camerele ;
aplicația WebEye instalată pe PC.
Din punct de vedere al costului de implementare, varianta sistemului de supraveghere care utilizează aplicația WebEye este mai avantajoasă decât cealaltă varianta. Acesta nu ar fi însă principalul avantaj al utilizării acestei metode de supraveghere în defavoarea unei alteia deja consacrată.
Un alt avantaj ar fi acela al extensibilității rapide pe alte calculatoare datorită ușurinței la instalare. Instalarea driver-ului unei camere web este la îndemâna oricărui utilizator, iar dezarhivarea aplicației client pe calculatorul din locația care se dorește a fi supravegheată este o operațiune simplă. Comparând cu modalitatea de instalare a unui sistem de supraveghere clasic, putem spune că acest sistem de supraveghere care folosește aplicația WebEye este mai avantajos.
Pe lângă acestea, flexibilitatea acestui sistem de supraveghere îi oferă un mare plus față de orice altă variantă. Un utilizator poate oricând să orienteze camera web către alte puncte importante din cadrul locației de supravegheat, pe când la sistemele clasice, odată ce camera video este amplasată într-un punct, orice schimbare a poziției acesteia este mai dificil de realizat.
Principalul avantaj și marea problemă pe care acest sistem reușește să o rezolve este aceea a spațiului de stocare a datelor. Datorită faptului că se salvează doar acele cadre „relevante” pentru monitorizare, adică acele cadre în care se detectează mișcare, el elimină problema des întâlnită la sistemele de supraveghere clasice, care stochează toată informația inclusiv cea redundantă, inutilă. La monitorizarea unei incinte într-un interval de timp dat cu sistemul clasic de supraveghere se ocupă o cantitate mai mare de spațiu cu stocarea datelor, decât la monitorizarea în același interval de timp, în aceleași condiții cu sistemul propus în acest proiect.
Deci datorită avantajelor pe care acest sistem le oferă, sunt de părere că este o soluție viabilă pentru supravegherea oricărei locații.
2.2. Limbaje de programare utilizate
Limbajul C# – scurtă prezentare
Principalul tip obiectual întâlnit în majoritatea mediilor de dezvoltare (Visual Basic, Delphi, C++, Java, C#) poartă numele de clasă (class). Există și alte tipuri obiectuale (struct , object). O instanță a unui tip obiectual poartă numele de obiect.
La implementare, datele și metodele asociate trebuie să fie complet și corect definite, astfel încât utilizatorul să nu fie nevoit să țină cont de detalii ale acestei implementări. El va accesa datele, prin intermediul proprietăților și va efectua operațiile, prin intermediul metodelor puse la dispoziție de tipul obiectual definit. Spunem că tipurile de date obiectuale respectă principiul încapsulării.
Un tip de date abstract (ADT – abstract data type) este o entitate caracterizată printr-o structură de date și un ansamblu de operații aplicabile acestor date.
Permițând extensia tipurilor de date abstracte, clasele pot avea la implementare:
• date și metode caracterisitice fiecărui obiect din clasă (membri de tip instanță),
• date și metode specifice clasei (membri de tip clasă).
Modificatorul static plasat la definirea unui membru al clasei face ca acela să fie un membru de clasă, nu unul de tip instanță. Dacă în cazul membrilor nestatici, există câte un exemplar al membrului respectiv pentru fiecare instanță a clasei, membrii statici sunt unici , fiind accesați în comun de toate instanțele clasei. Mai mult, membrii statici pot fi referiți fără a crea vreo instanță a clasei respective.
Pentru tipurile de date obiectuale class este posibilă o operație de extindere sau specializare a comportamentului unei clase existente prin definirea unei clase noi ce moștenește datele și metodele clasei de bază, cu această ocazie putând fi redefiniți unii membri existenți sau adăugați unii membri noi. Operația mai poartă numele de derivare.
Clasa din care se moșteneștea se mai numește clasă de bază sau superclasă. Clasa care moștenește se numește subclasă, clasă derivată sau clasă descendentă.
Ca și în Java, în C# o subclasă poate moșteni de la o singură superclasă, adică avem de-a face cu moștenire simplă; aceeași superclasă însă poate fi derivată în mai multe subclase distincte. O subclasă, la rândul ei, poate fi superclasă pentru o altă clasă derivată. O clasă de bază împreună cu toate clasele descendente (direct sau indirect) formează o ierarhie de clase. În C#, toate clasele moștenesc de la clasa de bază Object.
În contextul mecanismelor de moștenire trebuie amintiți modificatorii „abstract” și „sealed” aplicați unei clase, modificatori ce obligă la și respectiv se opun procesului de derivare. Astfel, o clasă abstractă trebuie obligatoriu derivată, deoarece direct din ea nu se pot obține obiecte prin operația de instanțiere, în timp ce o clasă sigilată (sealed) nu mai poate fi derivată (e un fel de terminal în ierarhia claselor). O metodă abstractă este o metodă pentru care nu este definită o implementare, aceasta urmând a fi realizată în clasele derivate din clasa curentă (care trebuie să fie și ea abstractă). O metodă sigilată nu mai poate fi redefinită în clasele derivate din clasa curentă.
Folosind o extensie a sensului etimologic, un obiect polimorfic este cel capabil să ia diferite forme, să se afle în diferite stări, să aibă comportamente diferite. Polimorfismul obiectual se manifestă în lucrul cu obiecte din clase aparținând unei ierarhii de clase, unde , prin redefinirea unor date sau metode, se obțin membri diferiți având însă același nume. Astfel, în cazul unei referiri obiectuale, se pune problema stabilirii datei sau metodei referite. Comportamentul polimorfic este un element de flexibilitate care permite stabilirea contextuală, în mod dinamic, a membrului referit.
Pentru a permite acest mecanism , metodele care necesită o decizie contextuală (în momentul apelului), se declară ca metode virtuale (cu modificatorul „virtual”). În mod curent, în C# modificatorului „virtual” al funcției din clasa de bază, îi corespunde un specificator „override” al funcției din clasa derivată ce redefinește funcția din clasa de bază.
O metodă ne-virtuală nu este polimorfică și, indiferent de clasa căreia îi aparține obiectul, va fi invocată metoda din clasa de bază.
Limbajul C# fost dezvoltat de o echipă restrânsă de ingineri de la Microsoft, echipă din care s-a evidențiat Anders Hejlsberg (autorul limbajului Turbo Pascal și membru al echipei care a proiectat Borland Delphi).
C# este un limbaj simplu, cu circa 80 de cuvinte cheie, și 12 tipuri de date predefinite.
El permite programarea structurată, modulară și orientată obiectual, conform perceptelor moderne ale programării profesioniste.
Principiile de bază ale programării pe obiecte (ÎNCAPSULARE, MOȘTENIRE, POLIMORFISM) sunt elemente fundamentale ale programării C#. În mare, limbajul moștenește sintaxa și principiile de programare din C++. Sunt o serie de tipuri noi de date sau funcțiuni diferite ale datelor din C++, iar în spiritul realizării unor secvențe de cod sigure, unele funcțiuni au fost adăugate, diversificate (tipul struct), modificate (tipul string) sau chiar eliminate (moștenirea multiplă și pointerii către funcții). Unele funcțiuni (cum ar fi accesul direct la memorie folosind pointeri) au fost păstrate, dar secvențele de cod corespunzătoare se consideră „nesigure”.
C# permite utilizarea programării orientate pe obiecte (POO) respectând toate principiile enunțate anterior.
Toate componentele limbajului sunt într-un fel sau altul, asociate noțiunii de clasă.
Programul însuși este o clasă având metoda statică Main() ca punct de intrare, clasă ce nu se instanțiază. Chiar și tipurile predefinite byte, int sau bool sunt clase sigilate derivate din clasa ValueType din spațiul System.
O aplicatie C# este formată din una sau mai multe clase, grupate în spații de nume (namespaces). Un spațiu de nume cuprinde mai multe clase cu nume diferite având funcționalități înrudite. Două clase pot avea același nume cu condiția ca ele să fie definite în spații de nume diferite. În cadrul aceluiași spațiu de nume poate apărea definiția unui alt spațiu de nume, caz în care avem de-a face cu spații de nume imbricate. O clasă poate fi identificată prin numele complet (nume precedat de numele spațiului sau spațiilor de nume din care face parte clasa respectivă, cu separatorul punct).
O clasă este formată din date și metode (funcții). Apelarea unei metode în cadrul clasei în care a fost definită aceasta presupune specificarea numelui metodei. Apelul unei metode definite în interiorul unei clase poate fi invocată și din interiorul altei clase, caz în care este necesară specificarea clasei și apoi a metodei separate prin punct. Dacă în plus, clasa aparține unui spațiu de nume neinclus în fișierul curent, atunci este necesară precizarea tuturor componentelor numelui: spațiu.clasă.metodă sau spațiu.spațiu.clasă.metodă etc.
Pentru a facilita cooperarea mai multor programatori la realizarea unei aplicații complexe, există posibilitatea de a segmenta aplicația în mai multe fișiere numite assemblies. Într-un assembly se pot implementa mai multe spații de nume, iar părți ale unui același spațiu de nume se pot regăsi în mai multe assembly-uri. Pentru o aplicație consolă , ca și pentru o aplicație Windows de altfel, este obligatoriu ca una (și numai una) dintre clasele aplicației să conțină un „punct de intrare” (entry point), și anume metoda (funcția) Main.
Platforma .NET
.NET este un cadru (framework) de dezvoltare software unitară care permite realizarea, distribuirea și rularea aplicațiilor-desktop Windows și aplicațiilor WEB.
Tehnologia .NET pune laolaltă mai multe tehnologii (ASP, XML, OOP, SOAP etc.) și limbaje de programare (VB, C++, C#, J#) asigurând totodată atât portabilitatea codului compilat între diferite calculatoare cu sistem Windows, cât și reutilizarea codului în programe, indiferent de limbajul de programare utilizat.
.NET Framework este o componentă livrată înpreună cu sistemul de operare Windows. De fapt, .NET 2.0 vine cu Windows Server 2003 și Windows XP SP2 și se poate instala pe versiunile anterioare, până la Windows 98 inclusiv; .NET 3.0 vine instalat pe Windows Vista și poate fi instalat pe versiunile Windows XP cu SP2 și Windows Server 2003 cu minimum SP1.
Microsoft .NET este o platformă de dezvoltare software, care are menirea de a oferi programatorilor un mediu în care sunt puse la dispoziție diverse servicii cum sunt: managementul firelor de execuție, managementul duratei de viață a obiectelor, tratarea excepțiilor, etc. și care determină o viteză mult mai mare a dezvoltării aplicațiilor decât direct pe platforma Win32, adică direct pe sistemul de operare Windows.
Inovația adusă de Microsoft, constă în dezvoltarea unei platforme comune pentru mai multe limbaje de programare, platformă care permite dezvoltarea unei aplicații în orice limbaj dorește programatorul. Acest lucru este posibil prin dezvoltarea unui interpretor – Common Language Runtime (CLR)– care transformă codul de program dintr-un limbaj oarecare, compatibil cu platforma .NET, în limbajul Microsoft Intermediate Language. Codul rezultat în limbajul Microsoft Intermediate Language, se poate apoi compila pentru orice sistem de operare care are instalat .NET Framework.
Pentru a dezvolta aplicatii pe platforma .NET este bine sa avem 3 componente esențiale:
• un set de limbaje (C#, Visual Basic .NET, J#, Managed C++, Lisp, Pascal etc);
• un set de medii de dezvoltare (Visual Studio .NET);
• și o bibliotecă de clase pentru crearea serviciilor Web, aplicațiilor Web și aplicațiilor
desktop Windows.
Când dezvoltăm aplicații .NET, putem utiliza:
• Servere specializate – un set de servere Enterprise .NET (din familia SQL Server 2000, Exchange 2000 etc.), care pun la dispoziție funcții de stocare a bazelor de date, email, aplicații B2B (Bussiness to Bussiness – comerț electronic între partenerii unei afaceri);
• Servicii Web (în special comerciale), utile în aplicații care necesită identificarea utilizatorilor (de exemplu, .NET Passport – un mod de autentificare folosind un singur nume și o parolă pentru toate site-urile vizitate);
• Servicii incluse pentru dispozitive non-PC (Pocket PC Phone Edition, Smartphone,
XBox, etc.)
Componenta .NET Framework care stă la baza tehnologiei .NET, este ultima interfață între aplicațiile .NET și sistemul de operare și actualmente conține:
• Limbajele C#, VB.NET, C++ și J#. Pentru a fi integrate în platforma .NET toate aceste limbaje respectă niște specificații POO numite Common Type System (CTS). Ele au ca elemente de bază: clase, interfețe, delegări, tipuri valoare și referință, iar ca
mecanisme moștenirea, polimorfismul și tratarea excepțiilor.
• Platforma comună de executare a programelor numită Common Language Runtime
(CLR), utilizată de toate cele 4 limbaje.
• Ansamblul de biblioteci necesare în realizarea aplicațiilor desktop sau Web numit Framework Class Library (FCL).
Componenta .NET Framework este formată din compilatoare, biblioteci și alte executabile utile în rularea aplicațiilor .NET. Fișierele corespunzătoare se află, în general , în directorul WINDOWS\Microsoft.NET\Framework\V2.0….(corespunzător versiunii instalate).
Fig. 2.1. Arhitectura .NET Framework
Caracteristicile principale ale platformei .NET, sunt:
• Permite integrarea ușoară a aplicațiilor Windows cu cele de WEB;
• Facilitează interoperabilitatea între aplicații, indiferent de platforma pentru care sunt create;
• Asigură serializarea/deserializarea obiectelor;
• Asigură un mediu stabil de programare obiectuală;
• Instalare simplificată, fără conflicte între versiuni;
• Execuția securizată a codurilor;
• Utilizează standardele existente pentru comunicare;
• Înlocuirea mediului script cu cel compilat, în cazul aplicațiilor ASP;
• Codul de program al unei aplicații, scris într-un anumit limbaj de programare, poate fi integrat fără probleme în altă aplicație, scrisă în alt limbaj de programare, etc.
Un program scris îıntr-unul dintre limbajele .NET conform Common Language Specification (CLS) este compilat în Microsoft Intermediate Language (MSIL sau IL). Codul astfel obținut are extensia .exe, dar nu este direct executabil, ci respectă formatul unic MSIL.
CLR include o mașină virtuală asemănătoare cu o mașină Java, ce execută instrucțiunile IL rezultate în urma compilării. Mașina folosește un compilator special JIT (Just In Time). Compilatorul JIT analizează codul IL corespunzător apelului unei metode și produce codul mașină adecvat și eficient. El recunoaște secvențele de cod pentru care s-a obținut deja codul mașină adecvat permițând reutilizarea acestuia fără recompilare, ceea ce face ca, pe parcursul rulării, aplicațiile .NET să fie din ce în ce mai rapide.
Faptul că programul IL produs de diferitele limbaje este foarte asemănător are ca rezultat interoperabilitatea între aceste limbaje. Astfel, clasele și obiectele create într-un limbaj specific .NET pot fi utilizate cu succes într-un program scris în alt limbaj.
În plus, CLR se ocupă de gestionarea automată a memoriei (un mecanism implementat în platforma .NET fiind acela de eliberare automată a zonelor de memorie asociate unor date devenite inutile – Garbage Collection).
Aplicații orientate pe date
Construirea unei aplicații ce gestionează un volum mare de date necesită o atenție particulară privind organizarea acestor date. Sursele de date trebuie și ele integrate corespunzător într-o aplicație POO. Dacă datele trebuie exportate către alte aplicații, atunci se pune problema formatului în care vor fi salvate. Pentru colecțiile consistente de date care suferă prelucrări ample și frecvente se pune problema suportului de memorare astfel încât să suporte tehnici de acces rapide etc.
Colecția, în general, reprezintă un ansamblu bine structurat de componente de același tip, ansamblu ce permite identificarea rapidă a oricărei componente din colecție. Definiția este aplicabilă și colecțiilor de date. Uneori, cloecțiile de date sunt percepute ca date externe (aflate pe harddisc sau alte suporturi de memorare), dar asta nu exclude posibilitatea organizării datelor interne sub forma unor colecții. În C#, colecțiile sunt clase specializate aparținând spațiului System.Collection.
Atributul „generic” se referă la proprietatea de a referi o întreagă categorie de obiecte. Clasele, structurile, metodele, interfețele, delegații pot fi generice, adică pot fi concepute astfel încât să depindă de unul sau mai multe tipuri de date pe care acestea le memorează sau manipulează.
C# introduce, începând de la versiunea 2.0, parametrizarea tipurilor, adică posibilitatea declarării unor clase, metode etc. în care tipul datelor manevrate nu este cunoscut decât la apel. Acest tip de date constituie un parametru al clasei, metodei etc.
Dintre clasele generice „predefinite”, cele mai des utilizate sunt colecțiile generice.
Astfel, clasele și interfețele din spațiul System.Collection.Generic permit organizarea datelor proprii, indiferent de tipul acestora, în structuri specifice cum ar fi: liste (List), liste dublu înlănțuite (LinkedList), stive (Stack), cozi (Queue), dicționare (Dictionary) etc.
De exemplu, dorim să gestionăm un ansamblu de ferestre asemănătoare, instanțiate dintr-o aceeași clasă MyForm derivată din System.Windows.Forms.Form.
Putem memora în program sau ca element static al clasei MyForm o structură de tip listă:
List<MyForm> fer=new List<MyForm>()
La crearea oricărei ferestre f de tipul MyForm (MyForm f=new MyForm(); f.Show();) se adaugă referința ferestrei în lista fer (fer.Add(f)). Analog, la închiderea ferestrei, se va elimina referința acesteia din listă (fer.Remove(f)).
ADO.NET
ADO.NET (ActiveX Data Objects) reprezintă o parte componentă a nucleului .NET Framework ce permite accesarea și manipularea datelor. O sursă de date poate fi: un fișier text, un fișier Excel sau XML, o bază de date Access, SQL etc. Lucrul cu o sursă de date se poate face fie conectat, fie deconectat de la sursa de date. ADO.NET implementează clase ce oferă servicii atât pentru lucrul în stil deconectat cât și conectat , oferă instrumentele de utilizare și reprezentare XML, de combinare a datelor din diferite surse și de diferite tipuri (pe bază mecanismelor de reprezentare comună implementate de .NET. Maniera de lucru deconectată recomandă metoda ca fiind mai eficientă în proiectarea aplicațiilor pentru Internet decât alte tehnologii.
Deoarece există mai multe tipuri de baze de date e nevoie de câte o bibliotecă specializată de clase și interfețe care să implementeze un „protocol” specific pentru fiecare. ADO.NET este componenta din .NET Framework care se ocupă cu accesul la baze de date ; este standardizată în sensul că se pot folosi aceleași obiecte pentru accesarea diferitelor tipuri de baze de date : Access, MS SQL Server, Oracle, etc. Sunt necesare la referințe două spații de nume (namespaces) : System.Data și System.Data.SqlClient pentru MS SQL sau System.Data.OleDb pentru Access.
Mecanismul accesării bazelor de date în ADO.NET este urmatorul: un obiect Connection stabilește o conexiune între aplicație și baza de date. Această conexiune poate fi accesată direct de un obiect Command sau de un obiect DataAdapter. Obiectul Command execută o comanda asupra bazei de date. Dacă se returnează valori multiple, se utilizează un obiect DataReader care va conține datele returnate. Aceste date pot fi procesate direct de aplicație. Alternativ, se poate utiliza un DataAdapter pentru a popula un obiect DataSet.
Modificările asupra bazei de date se pot efectua prin intermediul unui obiect Command sau unui obiect DataAdapter.
Connection reprezintă conexiunea curentă la baza de date.
Tipuri de conexiuni:
• SqlConnection – pentru conectarea la SQL Server ;
• OleDbConnection – conexiuni la diverse tipuri de baze de date;
• ODBCConnection;
• OracleConnection.
Un obiect Connection conține toate informațiile necesare deschiderii unui canal de comunicație cu baza de date în cadrul proprietății ConnectionString. Sunt încorporate, de asemenea, metode pentru facilitarea tranzacțiilor.
Command este reprezentat de doua clase: SqlCommand și OleDbCommand. Utilizat pentru a efectua apeluri de proceduri stocate sau de comenzi SQL asupra bazei de date sau pentru a returna tabele.
Metode:
• ExecuteNonQuery – execută comenzi care nu returnează înregistrari – INSERT, UPDATE, DELETE;
• ExecuteScalar – returnează o singură valoare dintr-o interogare;
• ExecuteReader – returnează o mulțime rezultat, sub forma unui obiect DataReader;
• obiectele DataReader nu pot fi instanțiate direct, sunt returnate ca rezultat al metodei ExecuteReader a unui obiect Command;
• o singură linie din recordset este în memorie la un moment dat, deci se folosește un minim de resurse, dar este necesară menținerea activă a unui obiect Connection pe durata de viață a obiectului DataReader.
DataAdapter este clasa din nucleul tehnologiei ADO.NET, bazată pe mecanismul non-conexiune.
• facilitează comunicarea între baza de date și DataSet;
• populează obiectele DataTable sau DataSet ori de câte ori se apelează metoda Fill;
• metoda Update înregistrează modificările, efectuate local, în baza de date;
La apelul metodei Update, se copiază modificările din DataSet în baza de date, executându-se una din comenzile reprezentate de InsertCommand, DeleteCommand sau UpdateCommand.
Există controale folosite la afișare de date: Labels, TextBoxes – informații unicate; dar în mod curent se folosesc și unele pentru afișarea unor colecții de informații, cum ar fi : ListBoxes, DropDownLists și GridViews. Acestea din urmă se folosesc foarte mult în aplicații de management al informațiilor.
Obiectele ADO.Net
SqlConnection
Un obiect SqlConnection este la fel ca orice alt obiect C#. De cele mai multe ori declararea și instanțierea se face în același timp.
Obiectul SqlConnection este instanțiat folosind un constructor care primește ca parametru un string. Acest argument este stringul de conectare.
Scopul instanțierii unui obiect de tip SqlConnection este ca alte obiecte ADO.Net să poată lucra cu baza de date. Alte obiecte, cum ar fi SqlDataAdapter și SqlCommand, au constructori care primesc obiectul conexiune ca parametru. Atunci când se lucrează cu o bază de date trebuie urmați următorii pași:
Instanțierea unui obiect SqlConnection;
Deschiderea conexiunii;
Trimiterea conexiunii ca parametru altor obiecte ADO.Net;
Realizarea operațiunilor asupra bazei de date;
Închiderea conexiunii.
SqlCommand
Obiectele de tipul SqlCommand permit specificarea tipului de acțiune asupra bazei de date. De exemplu, se poate face o interogare, inserare, modificare sau ștergere.
Atunci când se realizează o interogare în baza de date, se obține un tabel rezultat care trebuie să poata fi vizualizat. Pentru a obține acest lucru folosind obiecte SqlCommand este folosită metoda ExecuteReader care întoarce un obiect de tipul SqlDataReader.
Pentru a insera valori într-o bază de date trebuie apelată funcția ExecuteNonQuery pe un obiect SqlCommand.
Modificarea și ștergerea datelor dintr-o bază de date se face la fel ca și inserarea, doar că punem primul parametru al constructorului SqlCommand pe valoarea corespunzătoare.
Uneori avem nevoie dintr-o bază de date doar de o singura valoare, care poate fi suma, media, etc. înregistrărilor dintr-un tabel. Apelând ExecuteReader și apoi calculând acea valoare în program nu este cea mai eficientă metodă de a ajunge la rezultat. Cea mai bună metodă este să lăsăm baza de date să facă ceea ce este necesar și să întoarcă o singură valoare. Acest lucru îl face metoda ExecuteScalar.
SqlDataReader
Tipul SqlDataReader este folosit pentru a citi date în cea mai eficientă metodă posibilă. Nu poate fi folosit pentru scriere. Odată citită , o informație nu mai poate fi citită încă o dată. SqlDataReader citește secvențial date.
Datorită faptului că citește doar înainte (forward-only) permite acestui tip de date să fie foarte rapid în citire. Dacă într-o aplicație este nevoie doar de informații care vor fi citite o singură dată, sau rezultatul unei interogări este prea mare ca să fie reținut în memorie SqlDataReader este soluția cea mai bună.
Obținerea unei instanțe de tipul SqlDataReader este puțin diferită de instanțierea normală – trebuie apelată metoda ExecuteDataReader. Dacă pentru instanțiere este folosit operatorul new vom obține un obiect cu care nu putem face nimic pentru ca nu are o conexiune și o comandă atașate.
SqlDataReader obține datele într-un stream secvențial. Pentru a citi aceste informații trebuie apelată metoda Read; aceasta citește un singur rând din tabelul rezultat. Metoda clasică de a citi informația dintr-un SqlDataReader este de a itera într-o buclă „while”.
Metoda Read întoarce „true” cât timp mai este ceva de citit din stream.
Caracteristici ale ASP și ASP.NET
ASP (Active Server Pages) reprezintă o tehnologie creată de Microsoft pentru a crea pagini web dinamice, ce are la bază stocarea si execuția script-urilor pe serverul Web.
Serverele Web care suportă tehnologia ASP sunt în număr de două:
• PWS – Personal Web Server (Windows 98, Me) și
• IIS – Internet Information Server (Windows NT, 2000 și ulterior).
Principalele caracteristici ale tehnologiei ASP sunt:
• Permite accesarea si actualizarea ușoară a bazelor de date;
• Viteză mare de execuție;
• Securitate ridicată, datorită faptului că script-ul nu poate fi vizualizat în browser;
• Generarea dinamică a răspunsurilor către clienții WEB, etc.
Paginile web dinamice create cu ajutorul ASP pot îngloba mai multe tipuri de tehnologii Web existente. De asemenea, scripturile din fișierele ASP pot fi și ele de mai multe tipuri : vbscript, javascript, active server.
ASP .NET reprezintă o evoluție a ASP bazată pe o nouă tehnologie dezvoltată de Microsoft, și anume platforma .NET Framework. Tehnologia ASP .NET, aduce îmbunătățiri semnificative față de ASP, cele mai evidente fiind următoarele:
• Execuția este mai rapidă;
• Este independent de programul de navigare pe Internet;
• Codul aplicației este compilat și executat de server; acesta, în cazul ASP, este interpretat pe măsura parcurgerii script-urilor;
• Utilizează noțiunea de code behind, adică separă partea de prezentare de partea de execuție a unei aplicații WEB;
• Favorizează reutilizarea codului, ceea ce în cazul ASP simplu, era o problemă, singura „reutilizare” care se făcea în ASP, fiind aceea de copiere a codului;
• Serializarea/deserializarea cu usurință a obiectelor;
• Asigură interoperabilitatea între aplicații WEB, între aplicații WEB si alte categorii de aplicații;
• Securitate crescută;
Datorită platformei .NET, pot fi înglobate cu usurință în aplicațiile WEB toate componentele care erau până acum caracteristice doar mediului Windows.
Microsoft ASP .NET este următoarea generație a tehnologiei de dezvoltare a aplicațiilor Web. Ea preia tot ce este mai bun de la Active Server Pages (ASP) la fel ca și serviciile bogate și facilitățile oferite de Common Language Runtime (CLR) și multe alte facilități noi. Rezultatul este o nouă modalitate de dezvoltare web rapidă, scalabilă și robustă care permite o mare flexibilitate cu foarte puține linii de cod scrise. Web Forms reprezintă partea centrală pe care se bazează ASP .NET. Acestea reprezintă elementele de interfață cu utilizatorul care dau aplicațiilor web aspectul și comportamentul dorit. Formularele Web sunt similare formularelor Windows prin faptul că oferă proprietăți, metode si evenimente controalelor plasate pe ele. Totuși, aceste elemente de interfață sunt afișate prin intermediul limbajului HTML, iar în cazul utilizării Microsoft Visual Studio .NET poate fi folosită interfața familiară de tip drag-and-drop pentru crearea aspectului formularelor Web. Formularele Web sunt constituite din două componente: partea vizuală (fisierul .ASPX) și codul din spatele formularului, care este stocat în fișiere separate.
Pentru a crea aplicații web cu ASP.NET avem nevoie de următoarele instrumente software:
a. Microsoft Internet Information Services (IIS) este server-ul de aplicații web al Microsoft. El este o componentă a Windows XP : Add/Remove Programs -> Add/Remove Windows Components;
b. Visual WebDeveloper 2005 Express Edition – este un mediu integrat de dezvoltare, care cuprinde inclusiv unelte de design al Form-urilor web;
c. Colecția de namespaces System.Web. Acestea sunt parte integrantă a .NET Framework și include clase predefinite care se ocupă de chestiuni specifice aplicațiilor web.
d. Controalele HTML și server sunt componente ale interfeței cu utilizatorul care sunt folosite pentru a afișa, respectiv, colecta informații către / dinspre utilizatori.
e. Limbajul de programare C#.
f. ADO.NET – sunt clase predefinite care se ocupă de managementul datelor – accesul la date în baze de date ODBC și Microsoft SQL Server.
La conceperea unui proiect ASP.NET se creează automat de către mediul de dezvoltare următoarele fișiere:
• Un Form care este de fapt un fișier Default.aspx, ce poate fi vizualizat în două moduri: Design și HTML. Acesta conține cod HTML și aici pot fi așezate prin design controalele care ruleaza la nivel de server.
• Fiecare fișier .aspx are asociat unul de tip .cs, unde este codul din spatele Form-ului, adică acel cod care este executat la nivel de server. Se poate ajunge la acel fișier cu click dreapta pe Form și View Code. Acest fișier are atașate automat câteva namespaces (folosind cuvântul cheie din limbajul C# using), printre care se pot observa și cele din familia System.Web.
• Web.config – acesta este un fișier XML în care se pot seta mai multe informații de configurare a aplicației web. În general, el este folosit pentru securitate (autentificare), dar și pentru stocarea unor informații gen constante care să poată fi regăsite din codul executabil. Avantajele stocării unor astfel de constante în web.config sunt : modificările în acest fișier nu atrag după sine necesitatea de recompilare a aplicației, respectiv informațiile sunt într-un singur loc și pot fi modificate cu ușurință.
În general, se recomandă ca designul aplicațiilor (din punct de vedere al ingineriei software și nu vizual) să respecte anumite criterii. Astfel, dacă ne gândim la modelul arhitectural pe mai multe nivele:
• User Interface Layer – Form-uri web, în care se fac afișări și de unde se preiau informații de la utilizator.
• Business Layer – clase în care se efectuează operațiile specifice aplicației.
• Data Access Layer – clase care se ocupă cu accesul la baza de date și trimiterea informațiilor în nivelele superioare.
ASP.NET vine cu câteva controale predefinite, în plus față de cele HTML, numite și controale server, numite așa deoarece tratarea evenimentelor la care acestea răspund se execută pe server. Visual Studio .NET 2005 are o interfață care permite manipularea facilă a acestora din Toolbox.
ASP.NET 2.0 vine cu peste 50 de noi astfel de controale. Toolbox-ul este alcătuit din tab-urile Standard, Data, Validation, Navigation, Login, WebParts, HTML și General. Fiecare tab conține controale specifice.
În ASP.NET 2.0, majoritatea controalelor dispun de Smart Tasks (sau Common Tasks). Acestea, în funcție de controlul în cauză, permit formatarea controalelor cu stiluri predefinite, atașarea de date, setarea modului de vizualizare etc.
Se observă că atunci când se introduc controale într-un Form web, în codul „din spatele acestuia" , adică în fișierul .cs asociat , se produc niște modificări: se creează un nou obiect, în funcție de ce anume s-a adăugat, ca instanță a uneia dintre clasele din spațiul de nume System.Web.UI.WebControls.
Există controale folosite la afișare de date: Labels, TextBoxes , dar în mod curent se folosesc și unele pentru afișarea unor colecții de informații, cum ar fi : ListBoxes, DropDownLists si GridViews. Acestea din urmă se folosesc foarte mult în aplicații de management al informațiilor.
Controalele sunt caracterizate prin:
• Proprietați (ID-ul controlului, Text, Font, Activare etc.)
• Evenimente predefinite la care știu să raspundă (de exemplu, butoanele au Click, textbox-urile au TextChanged, etc.)
În momentul în care doriți să tratați un eveniment, să spunem apăsarea unui buton de către utilizator, trebuie să asociați un handler evenimentului predefinit Click al butonului respectiv. Un handler nu este altceva decât o funcție, iar asocierea respectivă se poate face foarte ușor din Visual Studio.
Pentru cazul anterior, este suficient dublu-click pe buton, pentru a se creea automat o metodă de tipul :
protected void ButtonX_Click(object sender, EventArgs e){}
Pentru a prezenta informații în navigatorul clientului folosim formularele Web ASP.NET care oferă o abstractizare în modelul de programare, un model orientat obiect și bazat pe evenimente. Acest mediu de lucru beneficiază de toate facilitațile oferite de platforma .NET (siguranța tipurilor, mediu de execuție controlat, moștenire) și reprezintă o înlocuire a clasicelor formulare HTML.
Componenta vizuală este reprezentată de un fișier cu extensia .aspx – acționând ca un container pentru HTML , text static și controale server care pot fi afișate în browser , iar logica aplicației este reprezentată de un fișier cu extensia .cs (pentru limbajul Visual C#) sau .vb (pentru Visual Basic.NET). Fișierele .aspx mai sunt referite ca pagini ASP.NET. Această tehnică de separare a codului de partea de prezentare este numită „code-behind programming".
Formularele Web și ASP .NET au fost create pentru a depăși câteva dintre limitările ASP. Principalele facilități noi sunt redate în continuare:
• Separarea interfeței HTML de logica aplicației;
• Un set bogat de controale pentru server ce detectează tipul browser-ului și generează limbaj HTML corespunzător acestuia;
• Mai puțin cod de scris din cauza modului în care sunt construite noile controale server;
• Model de programare bazat pe evenimente;
• Cod compilat și suport pentru mai multe limbaje de programare, față de ASP care era interpretat ori ca VBScript ori ca Jscript;
• Permite crearea de controale de către terți care să aducă noi funcționalități.
Logica aplicației reprezintă în fapt o clasă care extinde funcționalitatea clasei System.Web.UI.Page. Această clasă conține metode care tratează diferite evenimente ce apar în timpul execuției formularului Web la server (de exemplu, dacă metoda Page_Load este conectată la evenimentul Load al clasei de bază Page, atunci aceasta este apelată la fiecare acces al unui formular Web), proprietăți (de exemplu, prin proprietatea IsPostBack putem afla dacă o pagină Web este la primul acces sau la accesări ulterioare), atribute corespunzătoare unor controale din pagina WebForms și alte date membre necesare implementării aplicației.
O pagină WebForms, la procesarea pe serverul Web, poate fi privită ca un program executabil pentru care ieșirea standard o reprezintă browserul sau dispozitivul client. În acest model, pagina trece printr-o serie de stagii de procesare: inițializare, procesare și eliberare.
În ordinea apariției, acestea sunt:
• Init, eveniment care inițializează pagina și în care proprietățile controalelor sunt actualizate. Aici este corect să inițializăm controale care se adaugă dinamic la pagină sau variabile necesare înainte de inițializarea paginii;
• Load poate fi numit locul în care utilizatorul își inițializează codul. Evenimentul este generat de fiecare dată când pagina este încarcată după ce controalele au fost inițializate la pasul anterior;
• Tratarea evenimentelor utilizator, reprezintă stagiul în care sunt tratate evenimentele generate de client cum ar fi: schimbarea unui text într-un control, apăsarea unui buton etc. Trebuie reținut că aceste evenimente nu sunt tratate într-o anumită ordine pe server, iar tratarea lor are loc după apariția unui eveniment Click care trimite formularul la server (a unui submit);
• PreRender, eveniment care poate fi folosit pentru a face ultimele actualizări asupra paginii Web înainte ca aceasta să fie generată la client;
• Render, eveniment care generează la client reprezentarea HTML a paginii Web ASP.NET încărcată la server;
• Unload este ultimul eveniment care se execută înainte ca pagina să fie eliberată. Evenimentul este util de folosit atunci când dorim să efectuăm ultimele operații de eliberare a resurselor: închiderea fișierelor, a conexiunilor la baza de date și eliberarea obiectelor din memorie.
Controale în ASP.NET
Există două tipuri de bază în care pot fi împărțite controalele:
• HTML Controls, reprezintă elemente HTML care pot fi programate la nivelul serverului și expun un model obiectual restricționat la capabilitățile elementelor HTML pe care le afisează;
• Web Controls, aduc facilități superioare controalelor HTML incluzând controale mult mai complexe, cum ar fi controlul calendar, iar modelul obiect nu reflectă neaparat sintaxa HTML.
Controalele HTML sunt asemenea elementelor HTML folosite cu ajutorul Frontpage sau al oricărui alt editor HTML. Pot fi folosite și elementele standard HTML într-un Formular Web, de exemplu pentru a crea o casetă de text :
<input type="text" id=txtFirstName size=25>
Orice element poate fi însă marcat să ruleze ca și un control HTML atunci când formularul este procesat de server prin adăugarea textului "runat=server" în interiorul tag-ului.
<input type="text" id=txtFirstName size=25 runat=server>
În cazul folosirii Visual Studio .NET , adăugarea acestui text ce permite procesarea controlului de către server se poate face foarte simplu dând clic dreapta pe elementul HTML în Design View și selectând Run as Server Control din meniul contextual.
Controalele HTML permit de asemenea tratarea evenimentelor asociate cu tagul HTML (clic pe un buton, de exemplu) și manipularea în mod programatic a tagului prin codul din Formularul Web. În momentul în care controlul este afișat în browser, tagul este afișat exact așa cum a fost salvat ca și cum a fost salvat pe Formularul Web, mai puțin textul „runat=server”, ceea ce oferă un control foarte precis a ceea ce va fi trimis către browser.
ASP.NET definește un al doilea tip de controale – Web Controls. Numite și controale inteligente, ele pot fi caracterizate prin:
• oferă un bogat și consistent model obiectual de programare;
• detectează automat tipul navigatorului , iar afișarea la client va fi optimizată în
funcție de capabilitățile acestuia;
• pentru unele controale se pot defini șabloane (template-uri) de afișare;
• posibilitatea de a controla generarea evenimentelor pe server;
• posibilitatea de a trimite evenimente unui container din interiorul acestuia (de exemplu, un control de tip buton în interiorul unui tabel);
• legarea la surse de date a tuturor proprietăților controalelor pentru a influența afișarea la execuție.
Sunt definite în spațiul de nume System.Web.UI.WebControls și moștenesc, direct sau indirect, clasa de baza WebControl.
2.2.3. Baze de date
SQL – scurtă prezentare
Structured Query Language (SQL) este un limbaj universal care poate fi utilizat pentru a defini, interoga, reactualiza și gestiona baze de date relaționale. SQL este accesibil utilizatorilor începători, dar în același timp poate oferi programatorilor experimentați facilități deosebite. SQL este un limbaj non-procedural, adică se specifică ce informație este solicitată, dar nu modul cum se obține această informație. SQL poate fi utilizat autonom sau prin inserarea comenzilor sale într-un limbaj de programare.
În SQL se disting trei familii de comenzi:
• Comenzi pentru definirea datelor, care permit descrierea (definirea) obiectelor ce modelează sistemul studiat. Aceste comenzi definesc limbajul de definire a datelor (LDD).
• Comenzi pentru manipularea datelor, care permit consultarea, reactualizarea, suprimarea sau inserarea datelor. Aceste comenzi definesc limbajul de manipulare a datelor (LMD).
• Comenzi pentru controlul datelor, care permit asigurarea confidențialității și integrității datelor, salvarea informației, realizarea fizică a modificărilor în baza de date, rezolvarea unor probleme de concurență. Aceste comenzi definesc limbajul de control al datelor (LCD).
Limbajul de definire a datelor constă din acele instrucțiuni SQL (CREATE, ALTER, DROP) care permit crearea, modificarea și distrugerea obiectelor bazelor de date.
SQL furnizează comenzi ce permit consultarea (SELECT) și actualizarea (INSERT, UPDATE, DELETE) conținutului bazei de date. Aceste comenzi definesc limbajul de manipulare a datelor (LMD).
În funcție de momentul în care se dorește realizarea actualizărilor asupra bazei de date, utilizatorul poate folosi una din următoarele comenzi:
• SET AUTOCOMMIT ON – schimbările se efectuează imediat;
• SET AUTOCOMMIT OFF – schimbările sunt păstrate într-un buffer până la execuția uneia din comenzile:
– COMMIT, care are rolul de a permanentiza schimbările efectuate;
– ROLLBACK, care determină renunțarea la schimbările realizate.
Sistemul de gestiune trebuie:
• să pună la dispoziția unui număr mare de utilizatori o mulțime coerentă de date;
• să garanteze coerența datelor în cazul manipulării simultane de către diferiți utilizatori.
Coerența este asigurată cu ajutorul conceptului de tranzacție. Tranzacția este unitatea logică de lucru constând din una sau mai multe instrucțiuni SQL, care trebuie să fie executate atomic (ori se execută toate, ori nu se execută nici una), asigurând astfel trecerea bazei de date dintr-o stare coerentă în altă stare coerentă.
Dacă toate operațiile ce constituie tranzacția sunt executate și devin efective, spunem că tranzacția este validată, iar modificările aduse de tranzacție devin definitive.
Dacă dintr-un motiv sau altul (neverificarea condițiilor, accesul imposibil) o operație a tranzacției nu a fost executată spunem că tranzacția a fost anulată. Modificările aduse de toate operațiile tranzacției anulate sunt și ele anulate și se revine la starea bazei de date de dinaintea tranzacției anulate.
Este posibil ca o tranzacție să fie descompusă în subtranzacții, astfel încât dacă este necesar, să se anuleze doar parțial unele operații.
Fiecare tranzacție se poate termina:
• „normal” (commit);
• „anormal” (rollback).
Controlul tranzacțiilor constă în:
• definirea începutului și sfârșitului unei tranzacții,
• validarea sau anularea acesteia,
• eventuală descompunere în subtranzacții.
Limbajul pentru controlul datelor (LCD) permite salvarea informației, realizarea fizică a modificărilor în baza de date, rezolvarea unor probleme de concurență. Limbajul conține următoarele instrucțiuni:
• COMMIT – folosită pentru permanentizarea modificărilor executate asupra bazei de date (modificările sunt înregistrate și sunt vizibile tuturor utilizatorilor);
• ROLLBACK – folosită pentru refacerea stării anterioare a bazei de date (sunt anulate toate reactualizările efectuate de la începutul tranzacției);
• SAVEPOINT – folosită în conjuncție cu instrucțiunea ROLLBACK, pentru definirea unor puncte de salvare în fluxul programului.
După ce se termină o tranzacție, prima instrucțiune SQL executabilă va genera automat începutul unei noi tranzacții.
Un „commit” apare automat când este executată o comandă LDD, sau o comandă LCD. Un rollback apare automat după o ieșire „anormală“ din SQL sau o cădere de sistem.
Din momentul în care s-a executat instrucțiunea „commit”, baza de date s-a modificat (permanent) în conformitate cu instrucțiunile SQL executate în cadrul tranzacției care tocmai s-a terminat. Din acest punct începe o nouă tranzacție.
Comanda „rollback” permite restaurarea unei stări anterioare a bazei.
ROLLBACK [TO [SAVEPOINT] savepoint];
Dacă nu se specifică niciun savepoint, toate modificările făcute în tranzacția curentă sunt anulate, iar dacă se specifică un anumit savepoint, atunci doar modificările de la acel savepoint până în momentul respectiv sunt anulate. Executarea unei instrucțiuni „rollback” presupune terminarea tranzacției curente și începerea unei noi tranzacții.
Punctele de salvare pot fi considerate ca niște etichete care referă o submulțime a schimbărilor dintr-o tranzacție, marcând efectiv un punct de salvare pentru tranzacția curentă. Dacă este creat un punct de salvare având același nume cu unul creat anterior, cel definit anterior este șters automat.
SAVEPOINT savepoint;
Execuția unei comenzi „commit” implică anumite modificări:
• Toate schimbările (INSERT, DELETE, UPDATE) din baza de date făcute după anterioara comandă „commit” sau „rollback” sunt definitive. Comanda se referă numai la schimbările făcute de utilizatorul care dă comanda „commit”.
• Toate punctele de salvare vor fi șterse.
• Starea anterioară a datelor este pierdută definitiv.
• Toți utilizatorii pot vizualiza rezultatele.
• Blocările asupra liniilor afectate sunt eliberate; liniile pot fi folosite de alți utilizatori pentru a face schimbări în date.
Execuția unei comenzi „rollback” implică anumite modificări:
• Anulează tranzacția în curs și toate modificările de date făcute după ultima comandă „commit”.
• Sunt eliberate blocările liniilor implicate.
• Nu șterge un tabel creat prin CREATE TABLE. Eliminarea tabelului se poate realiza doar prin comanda DROP TABLE.
Metode de acces la baze de date SQL Server
Înainte de orice operație cu o sursă de date externă, trebuie realizată o conexiune (legătură) cu acea sursă. Clasele din categoria Connection (SQLConnection, OleDbConnection etc.) conțin date referitoare la sursa de date (locația, numele și parola contului de acces, etc.), metode pentru deschiderea/închiderea conexiunii, pornirea unei tranzacții etc. Aceste clase se găsesc în subspații (SqlClient, OleDb etc.) ale spațiului System.Data. În plus, ele implementează interfața IDbConnection.
Pentru deschiderea unei conexiuni prin program se poate instanția un obiect de tip conexiune, precizându-i ca parametru un șir de caractere conținând date despre conexiune.
Proprietățile unei conexiuni
ConnectionString (String): conține un string cu o succesiune de parametri de forma parametru = valoare, despărțiți prin „;”. Parametrii pot fi:
• provider : specifică furnizorul de date pentru conectarea la sursa de date. Acest furnizor trebuie precizat doar dacă se folosește OLE DB .NET Data Provider, și nu se specifică pentru conectare la SQL Server ;
• Data Source : se specifică numele server-ului de baze de date sau numele fișierului de date ;
• Initial Catalog (Database) : specifică numele bazei de date. Baza de date trebuie să se găsească pe serverul dat în Data Source ;
• User ID : specifică un nume de cont de utilizator care are acces de logare la server ;
• Password: specifică parola contului de mai sus.
• ConnectionTimeout (int): specifică numărul de secunde pentru care un obiect de
conexiune poate să aștepte pentru realizarea conectării la server înainte de a se genera o excepție (implicit 15). Se poate specifica o valoare diferită de 15 în ConnectionString folosind parametrul Connect Timeout. Valoarea Timeout=0 specifică așteptare nelimitată.
Database (string): returnează numele bazei de date la care s-a făcut conectarea. Este necesară pentru a arăta unui utilizator care este baza de date pe care se face operarea.
Provider (string): returnează furnizorul.
ServerVersion (string): returnează versiunea de server la care s-a făcut conectarea.
State (enumerare de componente ConnectionState): returnează starea curentă a conexiunii.
Metodele unei conexiuni :
• Open() : deschide o conexiune la baza de date;
• Close() și Dispose() : închid conexiunea și eliberează toate resursele alocate pentru ea;
• BeginTransaction(): pentru executarea unei tranzacții pe baza de date; la sfârșit se
apelează Commit() sau Rollback();
• ChangeDatabase(): se modifică baza de date la care se vor face conexiunile. Noua bază de date trebuie să existe pe același server ca și precedenta;
• CreateCommand(): creează o comandă (un obiect de tip Command) validă asociată
conexiunii curente.
Executarea unei comenzi SQL
Clasele din categoria Command (SQLCommand, OleDbCommand etc.) conțin date referitoare la o comandă SQL (SELECT, INSERT, DELETE, UPDATE) și metode pentru executarea unei comenzi sau a unor proceduri stocate. Aceste clase implementează interfața IDbCommand. Ca urmare a interogării unei baze de date se obțin obiecte din categoriile DataReader sau DataSet. O comandă se poate executa numai după ce s-a stabilit o conexiune cu baza de date corespunzătoare.
Proprietățile unei comenzi :
• CommandText (String): conține comanda SQL sau numele procedurii stocate care se execută pe sursa de date;
• CommandTimeout (int): reprezintă numărul de secunde care trebuie să fie așteptat pentru executarea comenzii. Dacă se depășeste acest timp, atunci se generează o excepție;
• CommandType (enumerare de componente de tip CommandType) : reprezintă tipul de comandă care se execută pe sursa de date. Valorile pot fi: StoredProcedure (apel de procedură stocată), Text (comandă SQL obișnuită);
• Parameters (System.Data.[Provider].PrefixParameterCollection): returnează o colecție de parametri care s-au transmis comenzii;
• Transaction (System.Data.[Provider].PrefixTransaction): permite accesul la obiectul de tip tranzacție care se cere a fi executat pe sursa de date.
Metodele unei comenzi :
• Constructori: SqlCommand() sau SqlCommand(string CommandText) sau SqlCommand(string CommandText, SqlConnection con ) sau SqlCommand(string CommandText, SqlConnection con, SqlTransaction trans);
• Cancel() oprește o comandă aflată în executare;
• Dispose() distruge obiectul comandă;
• ExecuteNonQuery() execută o comandă care nu returnează un set de date din baza de date; dacă comanda a fost de tip INSERT, UPDATE, DELETE, se returnează numărul de înregistrări afectate.
• ExecuteReader() execută comanda și returnează un obiect de tip DataReader
• ExecuteScalar() execută comanda și returnează valoarea primei coloane de pe primul rând a setului de date rezultat; este folosit pentru obținerea unor rezultate statistice.
Seturi de date
Datele pot fi explorate în mod conectat (cu ajutorul unor obiecte din categoria DataReader), sau pot fi preluate de la sursă (dintr-un obiect din categoria DataAdapter) și înglobate în aplicația curentă (sub forma unui obiect din categoria DataSet).
Clasele DataReader permit parcurgerea într-un singur sens a sursei de date, fără posibilitate de modificare a datelor la sursă. Dacă se dorește modificarea datelor la sursă, se va utiliza ansamblul DataAdapter și DataSet.
Un obiect DataReader nu are constructor, ci se obține cu ajutorul unui obiect de tip Command și prin apelul metodei ExecuteReader(). Evident, pe toată durata lucrului cu un obiect de tip DataReader, conexiunea trebuie să fie activă. Toate clasele DataReader (SqlDataReader, OleDbDataReader etc.) implementează interfața IDataReader.
Metode:
• Close() închiderea obiectului și eliberarea resurselor; trebuie să preceadă închiderea conexiunii;
• GetBoolean(), GetByte(), GetChar(), GetDateTime(), GetDecimal(), GetDouble(), GetFloat(), GetValue(), GetString() returnează valoarea unui câmp specificat, din înregistrarea curentă;
• GetBytes(), GetChars() citirea unor octeți/caractere dintr-un câmp de date binary;
• GetDataTypeName(), GetName() returnează tipul/numele câmpului specificat;
• IsDBNull() returnează true dacă în câmpul specificat prin index este o valoare NULL;
• NextResult() determină trecerea la următorul rezultat stocat în obiect;
• Read() determină trecerea la următoarea înregistrare, returnând false numai dacă aceasta nu există; de reținut că inițial poziția curentă este înaintea primei înregistrări.
Folosirea combinată a obiectelor DataAdapter și DataSet permite operații de selectare , ștergere, modificare și adăugare la baza de date. Clasele DataAdapter generează obiecte care funcționează ca o interfață între sursa de date și obiectele DataSet interne aplicației, permițând prelucrări pe baza de date. Ele gestionează automat conexiunea cu baza de date astfel încât conexiunea să se facă numai atunci când este imperios necesar.
Un obiect DataSet este de fapt un set de tabele relaționate. Folosește serviciile unui obiect DataAdapter pentru a-și procura datele și trimite modificările înapoi către baza de date. Datele sunt stocate de un DataSet în format XML, același folosit și pentru transferul datelor.
Proprietățile unui DataAdapter
• DeleteCommand, InsertCommand, SelectCommand, UpdateCommand (Command) – conțin comenzile ce se execută pentru selectarea sau modificarea datelor în sursa de date;
Metodele unui DataAdapter
• Constructorul: SqlDataAdapter() sau SqlDataAdapter(obiect_comanda) sau SqlDataAdapter(string_comanda, conexiune);
• Fill() permite umplerea unei tabele dintr–un obiect DataSet cu date. Permite specificarea obiectului DataSet în care se depun datele, eventual a numelui tabelei din acest DataSet, numărul de înregistrare cu care să se înceapă popularea (prima având indicele 0) și numărul de înregistrări care urmează a fi aduse;
• Update() permite transmiterea modificărilor efectuate într–un DataSet către baza de date.
Structura unui DataSet
Un DataSet este format din Tables (colecție formată din obiecte de tip DataTable; DataTable este compus la rândul lui dintr-o colecție de DataRow și DataColumn), Relations (colecție de obiecte de tip DataRelation pentru memorarea legăturilor părinte–copil) și ExtendedProperties ce conține proprietăți definite de utilizator.
Scenariul uzual de lucru cu datele dintr-o tabelă conține următoarele etape:
• popularea succesivă a unui DataSet prin intermediul unuia sau mai multor obiecte DataAdapter, apelând metoda Fill;
• procesarea datelor din DataSet folosind numele tabelelor stabilite la umplere,
ds.Tables["camere"], sau indexarea acestora, ds.Tables[0], ds.Tables[1]
• actualizarea datelor prin obiecte comandă corespunzătoare operațiilor INSERT,
UPDATE și DELETE. Un obiect CommandBuilder poate construi automat o combinație de comenzi ce reflectă modificările efectuate.
CAPITOLUL 3
DESCRIEREA APLICAȚIEI
3.1. Descrierea hardware
Acest proiect își propune monitorizarea, prin detecția mișcărilor, a mai multor locații aflate la distanță și salvarea imaginilor într-o bază de date aflată pe un server. Prin această metodă se evită salvarea de informație redundantă, inutilă, în baza de date salvându-se doar acele cadre în care s-a detectat mișcare.
În realizarea acestui proiect am folosit aplicația Hamachi pentru a creea o rețea între server-ul cu baza de date și calculatoarele aflate în locații diferite, care urmează a fi supravegheate.
Hamachi este o aplicație shareware folosită la crearea de rețele virtuale private, capabilă să stabilească legături directe între calculatoare care sunt după un firewall; în alte cuvinte, el stabilește o conexiune prin Internet care simulează o rețea LAN (Local Area Network). Programul este disponibil pentru Microsoft Windows și, beta, pentru MAC OS X și Linux.
Un VPN (Virtual Private Network), este o rețea de comunicații folosită de obicei în cadrul unei companii, organizații, sau al mai multor companii, bazată pe o rețea publică și de aceea nesigură, dar care totuși poate asigura confidențialitatea comunicărilor. Expresia înseamnă pe românește „o rețea aproape particulară". Mesajele din traficul VPN pot fi deci transmise prin intermediul infrastructurii unei rețele publice de date (exemplu : Internet) folosind protocoalele standard.
VPN este o modalitate eficientă din punct de vedere al costurilor pentru ca diferite companii să poată asigura accesul la rețeaua companiei pentru angajații și colaboratorii aflați la distanță de sediul central, și pentru a permite confidențialitatea datelor schimbate între punctele de lucru aflate la distanță.
Inițial am instalat aplicația Hamachi pe server, aceasta generând pentru acel calculator un IP, cu ajutorul căruia el va fi recunoscut ulterior în rețea. De exemplu IP-ul generat de Hamachi pentru server este 5.103.51.125.
Apoi am făcut această operațiune pentru fiecare dintre calculatoarele aflate în locațiile care se doresc a fi supravegheate, aplicația Hamachi generând pentru fiecare câte un IP.
Din opțiunile aplicației Hamachi, pe server am creat o nouă rețea virtuală protejată prin parolă, denumită WebEye. La această rețea am adăugat pe rând fiecare dintre calculatoarele din locațiile de supravegheat.
Structura rețelei create este prezentată în figura de mai jos:
Fig. 3.1. Structura aplicației din punct de vedere hardware
În fiecare dintre cele trei locații care se doresc a fi supravegheate avem nevoie de următoarele:
• o cameră web și driver-ul aferent;
• aplicația Hamachi instalată și setată corespunzător atât pe server cât și pe client;
• pachetul Microsoft .NET Framework 3.5 instalat;
• aplicația client dezarhivată.
Comunicarea dintre un anumit calculator și o cameră web se realizează pe USB. Dacă pe acel calculator driver-ul camerei web a fost instalat corect, la pornirea camerei, imaginile recepționate de cameră vor ajunge la calculator unde vor fi procesate, prin procesare înțelegând eșantionarea și compararea imaginilor consecutive.
În continuare este prezentată modalitate de comunicare a fiecărei camere cu calculatorul la care este conectată pe USB.
Comunicația pe USB (Universal Serial Bus)
Pe lângă avantajul că sunt accesibile oricui, fiind la îndemâna oricărui utilizator, camerele web cu conectare pe USB mai au un mare avantaj, și anume că sunt foarte ușor de instalat și configurat. Analizând aceste avantaje am decis să apelez la camerele web pentru realizarea acestui proiect.
Capacitatea de configurare automată a dispozitivelor („plug-and-play”) a USB-ului este unul din marile avantaje față de alte „bus”-uri seriale. Această capacitate permite detectarea automată a unui nou dispozitiv care este introdus în sistem, o configurare automată a sa de către gazdă și o detectare automată a decuplării de la sistem. Cuplarea și decuplarea ușoară a dispozitivelor la și din sistem permit mobilitatea pe „bus” și asigurarea sistemului la noile dispozitive fără a fi nevoie să repornim întregul sistem de fiecare dată când un nou dispozitiv este detectat.
Fig. 3.2. Sistemul USB dintr-o locație de supravegheat
Un sistem tipic USB constă în :
O gazdă (host) – nu există decât o singura gazdă în sistemul USB, care este responsabilă cu întregul protocol complex (astfel se simplifică proiectarea perifericelor USB). Gazda controlează accesul la mediul de transmisie – nimeni nu poate accesa magistrala de date dacă nu a primit aprobarea de la host. În cazul nostru gazda este reprezentată de calculatorul din locația de supravegheat;
Hub-ul, are rol asemănător „hub”-urilor folosite în rețelele de calculatoare. Hub-ul asigură un punct de interconectare care permite mai multor dispozitive să fie conectate la un singur port USB. Topologia logică a USB-ului are o structură stelară, iar toate dispozitivele sunt conectate (logic) direct la gazdă. „Hub”-ul este conectat între gazdă și dispozitivul USB (datele „curg” în jos de la gazdă la dispozitiv). Responsabilitatea principală a „hub”-urilor este aceea de a detecta conectarea sau deconectarea dispozitivelor, având grijă de managementul energiei pentru dispozitivele care sunt alimentate de la „bus” (obțin energie de la bus). Un alt rol important al „hub”-ului este acela de a coordona atât dispozitivele de viteză mică sau la viteză maximă. Când un dispozitiv este conectat la sistem, „hub”-ul determină viteza la care operează acesta și pe toata durata comunicării prin „bus” previne trecerea de la viteza mare la viteza mică și vice-versa. Datorită faptului că o singură cameră web va fi conectată la un calculator, în cazul nostru nici nu este nevoie de un hub.
Dispozitivul – orice mecanism în sistemul USB, care este o gazdă, este un dispozitiv. Un dispozitiv asigură una sau mai multe funcții ale USB. Majoritatea dispozitivelor asigură doar o funcție, dar pot fi unele care asigură mai multe funcții și care se numesc dispozitive complexe(compuse). Există două tipuri de dispozitive – cele care au alimentare proprie sau cele care sunt alimentate de magistrala USB. Un dispozitiv care își ia energie de la magistrala USB se numește „bus powered”, iar un dispozitiv care își asigură singur energia este „self powered”. Camera web reprezintă dispozitivul conectat în sistemul USB și este de tip „bus powered” deoarece se alimentează de la USB.
Avem de-a face cu trei tipuri de dispozitive :
cele care operează la 400Mbps(Hi-speed) USB 2.0
cele care operează la 12Mbps(Full-speed) USB 1.1
cele care operează la 1.5Mbps(Low-speed) USB 1.0
USB folosește mai multe tipuri de conectori:
(a) (b)
Fig. 3.3. Conector de tip A (conectat la calculator) și conector de tip B (conectat la dispozitivul periferic).
Un periferic USB, precum mouse-ul sau tastatura, are nevoie de numai 1.5Mbps pentru a funcționa. Vitezele mai mari sunt necesare pentru transferul de informații cu unitățile de stocare a datelor: HDD, memory card, camere video USB, etc.
Fluxul de comunicare USB
Comunicarea logică între soft-ul client pe gazdă și funcția dispozitivului se face prin „conducte” – pipe. Un pipe este o asociere între un anumit endpoint al dispozitivului și soft-ul adecvat de pe gazdă.
Endpoint-ul este sursa sau destinația datelor transmise prin canalul USB. O interfață este compusă din punctele finale grupate într-un set bine determinat. Soft-ul client dorește să transmită datele între buffer-ii din gazdă și endpoint-urile din dispozitive și astfel se realizează respectiva interfață (care este asociată anumitor endpoint-uri).
Fluxul informațional pe magistrală poate fi realizat în doua direcții :
– OUT (afară) – datele sunt transferate dinspre gazdă spre dispozitiv;
– IN (înăuntru) – datele sunt transferate de la dispozitiv către gazdă.
Nivelul fizic
Semnalizarea pe magistrală
Nivelul fizic este o interfață fizică pentru cablul USB. Principala sarcină a nivelului fizic este aceea de a transmite și recepționa 0 și 1 logic drept nivele de tensiune corespunzătoare.
Cablul USB este format din 4 fire, iar semnalizarea pe bus este pe două fire. Există un fir D+ și un fir D-, astfel încât dacă vrem să transmitem „0” de pe bus vom menține D+ jos și D- sus și invers dacă vrem să transmitem „1”. Celelalte două cabluri sunt Vbus(+5V) și GND(-5V) care asigură curent dispozitivului. Biții sunt transmiși pe magistrală începând cu LSB(Least Signifiant Byte-bitul cel mai puțin semnificativ).
Fig. 3.4. Cablu USB
Fig. 3.5. Structura constructivă a cabului USB
Există câteva tipuri unice de semnalizare pe „bus”:
Reset signaling : gazda poate reseta dispozitivul. Acest lucru este posibil prin trimiterea SE0 (Single Ended Zero – adică liniile D+ si D- sunt ținute în starea low) mai mult de 2.5 µsec. Când dispozitivul recunoaște asemenea semnătură pe portul superior al magistralei, îl tratează ca pe un semnal RESET.
Suspend signaling : gazda poate introduce dispozitivul într-un modul de suspendare, astfel încât dispozitivul nu va răspunde la traficul USB. Un dispozitiv va începe tranziția către modul „suspend” oricând va sesiza o stare de inactivitate pe „bus” mai mare de 3ms, dispozitivul va fi suspendat, dar nu pentru mai mult de 10 ms de inactivitate pe magistrală. Recunoașterea semnalului pe porturile superioare va scoate dispozitivul din starea de suspendare.
Resume signaling : un dispozitiv care în modul suspendat își va relua operațiunile oricând va recunoaște un semnal K pe magistrală („0” diferențial pentru dispozitivele de mare viteză și „1” pentru dispozitivele de mică viteză). De fiecare dată când gazda vrea să „trezească” dispozitivul trimite semnalul RESUME pentru cel puțin 20ms. Aceasta permite dispozitivului aflat în modul suspendat să înceapă transmiterea semnalului K pe „bus” și să-și reia activitatea proprie.
SIE – Serial Interface Engine
SIE este parte atât a nivelului fizic al gazdei, cât și al dispozitivului. Datele sunt transmise pe magistrală ca un șir de biți în serial. SIE este responsabil pentru serializarea și deserializarea (convertirea fluxului de date într-unul paralel) a transmisiilor USB. SIE este responsabil și de operațiile de codare și decodare. SIE este responsabil și de generarea CRC pentru datele de ieșire și verifică CRC pentru datele de intrare. SIE detectează de asemenea PID-ul (ID-ul pachetului ), precum și semnalizările SOP, EOP, RESET și RESUME pe „bus”.
HC – Host Controller (Control gazdă)
Gazda este cel mai „deștept” element al sistemului USB și joacă un rol unic în sistem. Gazda inițiază toate operațiunile, controlează accesul media și este motorul principal al fluxului protocolului, așa cum vom vedea mai târziu. Iată de ce controlerul gazdă, un element în plus hardware, este necesar pentru a se asigura că tot ce este transmis pe „bus” este corect și corespunde specificațiilor.
Controlerul gazdă deservește atât gazdă, cât și USB-ul și are aceeași funcționalitate în fiecare sistem USB. Iată câteva din funcțiile HC:
Frame generation (Generarea cadrelor, frame-urilor) – Controlerul este responsabil cu partiționarea timpului USB-ului în unități de timp astfel încât numim „frame” (cadru) fiecare măsură de timp egală cu 1 ms (după transmiterea SOF-ului, HC poate lucra cu oricare altă tranzacție din restul cadrului). SOF conține numărul curent al cadrului (sau „frame”-ului) care este menținut de către HC.
Data processing (Procesare date) – HC răspunde cererilor de date către și dinspre gazdă.
Protocol engine (Motor de protocol) – Se ocupă de interfața nivelurilor de protocol ale USB-ului.
Error handing (Situații de eroare) – HC se ocupă de erori cum ar fi:
Timeout – funcția dispozitivului nu răspunde comenzilor;
CRC error (eroare CRC);
O neașteptată supraîncărcare a datelor.
Remote wakeup – HC este capabil să inducă USB-ului o stare de suspendare (așteptare, oprire) și să detecteze un semnal de „deșteptare” pe bus.
Sistemul USB SW
Sistemul USB alocă lungimile de bandă și controlează alimentarea cu energie a „bus”-ului, permițând astfel accesul dispozitivului la magistrală.
Sistemul USB SW este compus din software gazdă și două interfețe de soft adiționale:
Drivere USB (USBD): soft-ul client (adică nivelul superior al nivelului de comunicare) solicită date de la USBD sub forma IRPs (I/O Request packets – pachete de solicitări – „in și out”) care presupune solicitarea de transmitere/primire a datelor printr-o filieră anume. USBD-ul „se ocupă” de aceste solicitări. Un alt rol important al USBD-ului este acela de a oferi soft-ului client o descriere generală a dispozitivului cu care softul este pe cale să interacționeze. USBD-ul trebuie să aibă grijă de procesul de enumerare (un proces care este activat în momentul în care dispozitivul este atașat magistralei, iar în final este configurat complet, dispozitivul este parte integrantă a sistemului USB și poate răspunde fluxului de pe magistrală), analizează diversele configurații ale dispozitivului și oferă aceste „cunoștințe” softului client. Drept parte a acestei sarcini, USBD-ul deține pipe-ul implicit (cel corespunzător endpoint-ului 0) – deoarece atunci când un dispozitiv este introdus în sistem, singurul mod de a comunica cu acesta este prin această rută implicită.
Dispozitivul USB logic este compus dintr-o colecție de „puncte finale” (end-points) independente. Fiecare punct are o adresă unică (număr) pe un timp stabilit, iar dispozitivul logic USB este adresat în mod unic la finalul procesului de enumerare. Un end-point este unidirecțional (cu excepția numărului zero). Toate dispozitivele USB trebuie să susțină comunicarea prin pipe-ul implicit. Aceasta joacă un rol important în procesul de enumerare și este singurul canal de comunicare cu dispozitivul la momentul atașării. Este asociat acestui pipe endpoint-ul zero (iată de ce numărul zero ca end-point trebuie să fie inclus în dispozitiv și să fie de tip control). Endpoint-ul număr zero este de fapt format din două endpoint-uri (unul IN și altul OUT) care împart însă același număr și referirea la ele se face ca la unul singur.
Dispozitivele cu viteză mică pot susține două endpoint-uri adiționale (în afara celui cu număr zero) care pot fi de tip control sau de tip întrerupere. Dispozitivele cu viteză mare, pe de altă parte, pot susține până la maxim 15 „puncte finale” de tip IN și 15 de tip OUT. Punctele adiționale pot fi folosite doar după configurarea completă a dispozitivului.
Nivelul de aplicație
Acesta apare ca soft client în gazdă și ca funcție în dispozitiv. Funcția din dispozitiv este compusă din mai multe interfețe și controlează funcționarea dispozitivului. Softul client orientează interfața nimerită prin transferul de date din bufferii proprii către endpoint-urile asociate interfeței corespunzătoare. Softul client lucrează cu o funcție specifică a dispozitivului independent de alte funcții ale dispozitivului din sistem.
Protocolul USB
Gazda USB controlează majoritatea complexității protocolului USB, ceea ce duce la costuri reduse și o structură simplă pentru echipamentele periferice. Fluxul de date poate fi direcționat de la gazdă la dispozitiv și invers. Transferurile USB se fac prin pachete. Fiecare tranzacție este compusă, de obicei, din 3 faze:
Token Phase : gazda inițializează simbolurile indicând tipul viitoarei tranzacții;
Data phase : datele sunt transmise în pachete. Direcția datelor coincide cu direcția indicată de simbolul transmis anterior;
Handshake phase : (opțional) – pachetul „handshake” este transmis, indicând succesul sau eșecul tranzacției.
USB-ul folosește un protocol de tip interogare – „polling”. De fiecare dată când gazda vrea să primească date de la dispozitiv emite un simbol– semnal adresat unui dispozitiv anume. Dacă sunt date de transmis, se transmit după primirea semnalului, iar gazda nu răspunde cu pachetul „handshake” (dacă faza de handshake este inclusă în transfer). Dacă dispozitivul nu are nimic de transmis, gazda emite semnalul către dispozitivul următor. Dacă, pe de altă parte, gazda dorește să trimită date către dispozitiv, va transmite semnalul potrivit și datele care-i urmează.
Dispozitivul va răspunde printr-un pachet „handshake” (dacă faza handshake este inclusă). Din momentul în care gazda termină de transmis datele către dispozitiv va emite un nou semnal către următorul dispozitiv. Când vorbim despre protocolul USB nu-i putem trece cu vederea robustețea. Protocolul include mecanismul de tip handshake, regulile „time-out” (pentru prevenirea blocării sistemului), mecanisme de control și o rată a erorilor foarte joasă. Fiecare pachet transmis pe „bus” include biți de control și protecție CRC.
Există 4 tipuri de transfer USB:
Transfer BULK (la grămadă) : transferul BULK este o cantitate mare de date și este folosit de dispozitive precum imprimante, scanere, etc. Lățimea de bandă alocată în fiecare tranzacție a transferului variază în funcție de resursele „bus”-ului la momentul respectiv. Transferurile BULK sunt sigure, atenția la apariția erorilor fiind foarte mare.
Transfer ISOCHRONOUS (sincron) : acest transfer este folosit pentru dispozitive multimedia (audio, video). O caracteristică importantă a transferului este că lățimea de bandă este garantată – banda necesară este rezervată pentru dispozitivele care folosesc acest tip de transfer. Aici se pune mai puțin accent pe succesul transferului (dacă toate datele ajung sau nu la timp), de vreme ce există o toleranță ridicată față de erori.
Transfer INTERRUPT : acest tip de transfer este cu latență limitată și e folosit pentru dispozitive precum mouse-ul, joystick-ul – care trebuie să răspundă la notificări, caracteristici și coordonate apărute „din scurt”. Un dispozitiv care lucrează cu acest tip de transfer definește intervalul de timp de care are nevoie pentru a trimite sau primi informația (element caracteristic configurației sale).
Transfer CONTROL : este folosit pentru configurarea unui dispozitiv. Configurarea se realizează în timpul procesului de enumerare dar poate fi făcută, de asemenea, în orice moment al procesului de comunicare. Când un dispozitiv nou este atașat la sistem, gazda are nevoie de date pentru a-l configura – totul prin transferul de tip CONTROL.
Dispozitivele de viteză mică suportă transferul de tip CONTROL și INTERRUPT, în timp ce dispozitivele de mare viteză suportă toate cele 4 tipuri de transfer descrise mai sus.
Câmpurile din pachetele folosite de protocolul USB sunt :
• Câmpul SYNC : apare la începutul fiecărui pachet. Apare pe „bus” în așteptare. Câmpul SYNC (sincronizare) permite echipamentelor periferice să-și sincronizeze ceasul intern la datele de intrare. Câmpul apare ca o serie de trei tranziții 1/0 urmatã de o marcã cu lãțimea a douã impulsuri.
• Câmpul PID : câmpul de identificarea al pachetului – conține datele de identitate ale pachetului. Deoarece sunt multe tipuri de pachete trebuie să indicăm începutul pachetului. Câmpul PID este compus din 8 biți : primii 4 biți se folosesc pentru a notifica identitatea pachetului, iar ceilalți 4 pentru control (complementari primilor 4 biți) și depistarea erorilor.
Fig. 3.6. Structura câmpului PID
Primii patru biți responsabili cu definirea tipului pachetului sunt folosiți în două etape. Cei mai semnificativi doi biți specifică tipul pachetului , iar ceilalți doi biți împart pachetele în categorii. Tabelul următor redă regula de interpretare a informației din PID.
Fig. 3.7. Semnificația biților din câmpul PID pentru stabilirea tipului de pachet
Tipurile PID sunt împărțite în patru mari grupe:
Simboluri (semnale) – care pot fi OUT, IN, SOF și SETUP:
OUT – indică faptul că datele următoare vor fi transmise de la gazdă la dispozitive;
IN – datele vor fi transmise de la dispozitiv la gazdă;
SOF (Start Of Frame)– început frame (secvență);
SETUP – pachetul va fi transmis de la gazdă la dispozitiv și va conține comenzi de setare (folosite la configurare).
Date : PID-ul „data” apare în pachetele de date. Poate apărea fie sub forma DATA0, fie DATA1, PID-ul diferit fiind folosit pentru ghidarea sincronizării.
Handshake – acest PID e folosit în pachetele handshake pentru a semnala succesul sau eșecul transferului. Poate fi fie ACK, fie NAK sau STALL.
ACK – receptorul primește pachetul fără erori;
NAK – receptorul nu poate primi datele din cauza unor probleme ivite sau transmițătorul nu poate trimite datele (probleme de flux);
STALL – end-point specific care este izolat sau comanda specifică SETUP nu poate fi menținută.
• Câmpul adresă (Address Field)
Este împărțit în două câmpuri:
a. Câmpul ADDRESS (ADDR) : acesta conține adresa funcției (de obicei a dispozitivului) atribuită la procesul de enumerare. Fiecare funcție din sistem are o adresă unică și pot exista într-un sistem până la 127 adrese diferite (adresa zero este rezervată și folosită ca adresă inițială a unei funcții, de aceea nu este permisă folosirea adresei zero ca adresă permanentă).
Fig. 3.8. Câmpul ADDRESS
b. Câmpul „ENDPOINT” (ENDP) : câmpul respectiv conține numărul referințelor la punctele de final. Fiecare punct într-o funcție specifică este unic și se identifică printr-un număr. La dispozitivele cu viteză redusă pot fi două puncte adiționale (în afară de zero). Câmpul este folosit în simbolurile OUT, IN, SETUP.
Fig. 3.9. Câmpul ENDPOINT
• Câmpul de numărare de cadre (Frame Number Field) – numărul segmentelor ce constituie câmpul sunt compuse din 11 biți care indică secvența curentă. Câmpul este conținut doar de simbolul SOF care indică începutul unei secvențe.
• Câmpul de date (Data Field) – câmpul datelor conține date transmise în operațiuni. Acest câmp poate conține până la 10223 bytes.
• Câmpul CRC (CRC Field) – CRC (verificare ciclică redundantă) este folosit pentru protejarea tuturor câmpurilor dintr-un pachet (cu excepția câmpului PID) și protejează datele din pachetele de date. Câmpul CRC într-un pachet este compus din 5 biți, în timp ce un câmp de date este compus din 16 biți.
Tipurile de pachete folosite de USB sunt:
• Pachet de semnalizare (TOKEN PACKET) – fiecare tranzacție (operație) începe prin emiterea unui semnal de către gazdă. Câmpurile ADDR și ENDP definesc în mod unic endpoint-ul care va primi datele în operațiunile SETUP sau OUT și specifică și endpoint-ul care este pe cale să transmită datele în operațiunile de tip IN.
Fig. 3.10. Structura pachetului de semnalizare
Fig. 3.11. Semnificația PID pentru stabilirea categoriei pachetului de semnalizare
Pachetul de ieșire (OUT) poartă datele de la gazdă la dispozitiv.
Pachetul de intrare (IN) poartă datele de la dispozitiv la gazdă.
Pachetul de comandă (SETUP) vizează un anume nod (Endpoint).
Pachetul de început de cadru (SOF – Start Of Frame) este difuzat tuturor dispozitivelor.
Pentru pachetele IN , OUT și SETUP , următorii 7 biți după PID sunt interpretați ca și câmp de adresă pentru a identifica dispozitivul pe care gazda vrea să îl apeleze pentru comandă sau transfer de date. Următorii 4 biți furnizează un număr de nod.
Ultimul câmp , de 5 biți , este folosit pentru verificări CRC , asigurând astfel integritatea transferului pachetului de date. În suma de control sunt incluse toate câmpurile în afară de PID , care este protejat prin structura sa.
• Pachet de început de cadru (START OF FRAME PACKET) – gazda emite un pachet SOF la fiecare milisecundă, plus sau minus 0,0005 ms. Pachetul conține câmpul secvențelor sincronic de tip OUT.
Fig. 3.12. Structura pachetului de început de cadru
Câmpul de 11 biți conține numărul cadrului care este atribuit de gazdă în mod crescător de la 0 la 7FFH (2047) , după care începe din nou de la 0. Câmpul este folosit ca informație de sincronizare pe magistrala USB.
• Pachet de date (DATA PACKET) – este compus din PID (ceea ce indică faptul că pachetul este un pachet de date), câmpul de date care conține datele ce trebuie transmise și CRC 16b pentru protejarea câmpului de date.
Fig. 3.13. Structura pachetului de date
Fig. 3.14. Semnificația PID pentru stabilirea categoriei pachetului de date
Din punct de vedere funcțional, cele două categorii de pachete de date formează între emițător și receptor un sistem adițional de verificare a erorilor. Emițătorul oscilează între DATA0 și DATA1 pentru a indica faptul că a recepționat o confirmare validă a recepției pachetului precedent.
Exemplu :
Emițătorul trimite un pachet DATA0. Dacă receptorul a preluat cu succes datele, emite un pachet handshake (de dialog) prin care confirmă emițătorului că a preluat corect datele. În urma interpretării pachetului handshake , emițătorul trimite următorul pachet de tip DATA1 , ceea ce indică receptorului că mesajul său de confirmare (ACK) a fost interpretat corect de emițător.
• Pachet handshake (HANDSHAKE PACKET) – este compus din SYNC și PID și indică rezultatele etapei anterioare.
Fig. 3.15. Structura pachetului handshake
Fig. 3.16. Semnificația PID pentru stabilirea categoriei pachetului handshake
ACK care arată că pachetul a fost trimis fără CRC sau erori, poate fi folosit în faza „handshake” a transferurilor de tip SETUP sau OUT (trimise de dispozitiv) sau în transferuri de tip IN (trimise de către gazdă).
NAK – folosit în controlul fluxului informațional poate fi transmis în faza „handshake” pentru transferul de tip OUT și IN. Indică faptul că o funcție nu a fost capabilă să recepționeze date de la gazdă.
STALL – care indică unele probleme de transfer (scurt circuit între puncte sau nemenținerea comenzii de control) – nu este permisă a fi folosită de către gazde.
Pentru cazul conectării unei camere web la un calculator tranferul informației între cele două poartă numele de transfer sincron. Este compus din una sau două faze operaționale. Nu există faza handshake în transferurile sincron. Gazda lansează fie un semnal IN pentru a primi date de la dispozitiv, fie OUT pentru a transmite date. În faza următoare datele sunt transmise în sensul cerut de semnalul gazdei emis mai înainte.
Fig. 3.17. Exemplu de transfer sincron
Tipuri de senzori. CMOS VS. CCD
Fiecare dintre camerele web folosite în dezvoltarea acestui proiect folosește un anumit tip de senzor pentru a capta imaginea. În continuare sunt descrise două tipuri de senzori ai camerelor și o comparație între ei.
Senzorul unei camere de supraveghere este componenta care preia informația luminoasa focalizată de obiectivul camerei și o transformă în impulsuri electrice. Un mod simplificat de a privi structura unui senzor este să ne gândim la el ca la o matrice bidimensională cu câteva milioane de celule fotosensibile. Fiecare celulă preia un pixel de informație luminoasă.
Aparatele foto clasice folosesc filmul fotografic pentru a capta imaginea. Camerele foto digitale însă folosesc un așa numit „senzor de imagine". Aceste cipuri de silicon conțin milioane de diode fotosenzitive, numite puncte fotografice. În momentul scurt în care obiectivul se deschide, fiecare punct înregistrează intensitatea luminii care îl atinge, acumulând o sarcină; cu cât lumina este mai intensă, cu atât sarcina acumulată este mai mare. Apoi intensitatea luminii înregistrată de fiecare punct este memorată ca o serie de numere, pentru a putea reda ulterior imaginea capturată.
Fotografiile digitale sunt compuse din sute de mii sau milioane de pixeli, care sunt de fapt niște pătrățele foarte mici. Fiecare pixel este capturat de un singur punct fotografic de pe senzorul de imagine și astfel se formează imaginea pe care o vedem pe ecranul aparatului foto, al calculatorului sau tipărită pe hârtie.
Senzorul CCD este primul senzor de acest tip apărut pe piață. Evident mai scump decât mai recentul CMOS (Complementary Metal Oxide Semiconductor) acesta este produs în lume doar de câțiva mari producatori (Sony, Sharp, LG, Interline) întrucât procesul tehnologic de construcție este foarte costisitor. Caracteristica acestui senzor este că informația luminoasă transformată în impulsuri electrice este transferată pe suprafața senzorului și citită la colțul cel mai apropiat. Un dispozitiv ADC (analog to digital converter) transformă apoi informația analoagă a fiecarui pixel într-o valoare digitală prin măsurarea intensității sarcinii. Rezultatul acestui proces este o imagine foarte precisă cu un nivel scăzut de zgomot (noise) și o rezoluție mare care crește direct proporțional cu mărimea senzorului. Un alt avantaj al senzorilor CCD ar fi vechimea în „branșă” , ceea ce le conferă o maturitate mai mare față de omologul său CMOS.
Până recent, senzorii CCD erau singurii senzori folosiți în camerele digitale. Senzorii CCD au cunoscut o dezvoltare foarte amplă prin folosirea lor în multe domenii importante, printre care se numără medicina și astronomia, prin folosirea lor în scannere, camere video și alte aparate de acest gen.
Problema cu cipurile CCD nu este calitatea, care e foarte bună, ci costurile de producție destul de ridicate. CCD-urile sunt fabricate cu aparate care sunt folosite doar pentru construcția acestui tip de senzor.
Senzorul CMOS este o alternativă la cipurile CCD. Cipurile CMOS pot fi fabricate cu aceeași tehnologie cu care se produc procesoarele și memoriile pentru calculatoare. De aici, costurile de producție a acestor senzori de imagine scad enorm de mult. De fapt, termenul CMOS se referă la felul în care un senzor este fabricat și nu la o tehnologie de senzori de imagine anume.
Senzorul CMOS este mai nou apărut decât CCD. Dacă la început el s-a dorit doar ca o variantă de reducere a costurilor și a însemnat și o reducere calitativă a imaginii, ulterior el a devenit un concurent serios predecesorului lui. Spre deosebire de acesta, CMOS-ul are pentru fiecare pixel (fotodioda) câțiva tranzistori miniaturizați care amplifică și convertesc semnalul din analog în digital și transferă informația prin legături mult mai convenționale (conductori). Semnalul generat de senzorul CMOS este digital deci nu are nevoie de dispozitive ADC. Marele dezavantaj vine din faptul că fotonii din care este alcatuită lumina care bombardează senzorul lovesc nu doar fotodiodele, ci și tranzistorii încorporați, fapt ce scade sensibilitatea luminoasă a senzorului. Un avantaj al senzorului CMOS ar fi că are un consum de energie cam de 100 de ori mai mic decât al unui senzor CCD ceea ce îl face ideal pentru camerele foto digitale.
O întrebare de genul care tip de senzor este mai bun nu își poate găsi un raspuns clar. Există prea multe variabile de luat în calcul de la producătorul și modelul senzorului până la camera în care acesta este încorporat.
CCD VS CMOS
• Calitatea imaginii produse de senzori CMOS egalează cea produsă de CCD în aria produselor din clasele de jos și de mijloc. Senzorii cei mai performanți din clasele cele mai sofisticate rămân senzorii CCD, cel puțin în momentul de față.
• Senzorii CMOS pot schimba instantaneu starea din capturarea imaginilor la înregistrarea de filme. Totuși, înregistrările video ocupă un spațiu imens, dacă depășesc câteva secunde.
• Senzorii CMOS sunt excelenți pentru capturarea de imagini în natură și în condiții bune de luminozitate, însă au de suferit în condiții proaste de iluminare, situații în care un bliț este indispensabil. Acest lucru se datorează faptului că pe fiecare punct fotografic al senzorului CMOS există și o parte de circuite, care este opacă, și astfel punctul respectiv primește mai puțină lumină. Procentul dintr-un pixel care captează efectiv lumina se numește „factor de umplere". Cu cât acest factor este mai mare, cu atât punctele fotografice primesc mai multă lumină și astfel senzorul este mai sensibil. Senzorii CCD au un factor de umplere de 100%.
• Senzorii CMOS au un nivel al zgomotului imaginii mai ridicat decât CCD-urile, așa că timpul de procesare al imaginilor crește.
• Senzorul CCD este mai sensibil decât senzorul CMOS ( creează o imagine mai bună în condiții de iluminare mai scăzute).
• Senzorul CCD creează o imagine cu mult mai puțin zgomot (noise) față de senzorul CMOS.
• Senzorul CMOS consumă de 100 de ori mai puțină energie decât un senzor CCD.
• Senzorul CMOS costă mult mai puțin în comparație cu senzorul CCD deoarece poate fi produs în masă.
• Ambii senzori pot avea rezoluții foarte mari.
3.2. Descrierea software
În ingineria software, arhitecturile multistrat sunt arhitecturi client-server în care prezentarea , procesarea informațiilor și managementul datelor sunt procese separate logic. De exemplu, o aplicație care este folosită pentru schimbul de informații între un utilizator și o bază de date folosește o arhitectură multistrat.
În domeniul programării se observă tendința programării pe module deoarece în felul acesta nivelele din soluție devin piese schimbabile. Acesta ar fi marele avantaj al modularizării programării. Pe lângă acesta ar mai fi și eleganța, scalabilitatea, extensibilitatea și claritatea codului.
Modulele rezultate pot fi oricând folosite în alte proiecte, pot fi de asemenea îmbunătățite fără prea mari eforturi, iar aplicația poate fi extinsă și decorată cu noi funcționalități fără să afecteze cu nimic codul actual.
Tocmai de aceea am decis să construiesc o aplicație care să respecte aceste principii.
Fig. 3.18. Arhitectura multistrat a aplicației
În aplicația dezvoltată am propus un model de arhitectură multistrat, această arhitectură cuprinzând cinci straturi și anume :
stratul DB (DATABASE) – baza de date folosită
Fig. 3.19. Baza de date folosită în acest proiect
Baza de date este o bază SQL SERVER 2005 EXPRESS EDITION foarte simplă, la care autentificarea se face pe bază de parolă, care este cunoscută doar de administrator. Baza de date are patru tabele și anume:
a. tabela USER în care sunt stocate date despre fiecare utilizator, cu următoarele câmpuri:
câmpul ID_USER, de tip int, cheia primară a tabelei USER, în care se reține un identificator unic pentru fiecare utilizator. Este de tip IDENTITY, adică la fiecare adăugare a unui nou utilizator se incrementează automat. Acest câmp este de asemenea cheie străină deoarece administratorul are drepturi de modificare sau ștergere chiar și asupra lui;
câmpul NUME, de tip nvarchar(100), în care se reține numele utilizatorului;
câmpul NUME_USER, de tip nvarchar(50), în care se reține numele contului unui anumit utilizator;
câmpul PASSWORD, de tip nvarchar(50), în care se reține parola de la un anumit cont al unui utilizator;
câmpul IS_ADMIN, de tip bit, în care se reține dacă un utilizator este sau nu administrator;
câmpul EMAIL, de tip nvarchar(50), în care se reține adresa de e-mail a utilizatorului;
câmpul CREATED_DATE, de tip datetime în care se reține data și ora la care a fost creat un cont;
câmpul MODIFIED_DATE, de tip datetime în care se reține data și ora la care un anumit cont a fost modificat;
câmpul MODIFIED_BY, de tip int, în care se reține identificatorul utilizatorului care a modificat acel cont;
câmpul CREATED_BY, de tip int, în care se reține identificatorul utilizatorului care a creat acel cont.
Fig. 3.20. Tabela USER
b. tabela CAMERA în care sunt stocate date despre fiecare cameră web în parte și care conține următoarele câmpuri:
– câmpul ID_CAMERA, de tip int, cheia primară a tabelei CAMERA, în care se reține un identificator unic pentru fiecare cameră adăugată. Este de tip IDENTITY, adică la fiecare adăugare a unei noi camere într-o altă locație, se incrementează automat;
– câmpul HASH_CAMERA, de tip varchar(50), în care se reține un identificator unic (un GUID- Global Unique Identifier, care este defapt un set de 36 de caractere aleatoare generat pentru recunoașterea unei camere pe un calculator);
– câmpul INST_DATE, de tip datetime, în care se reține data și ora instalării unei camere pe un calculator;
– câmpul NUME, de tip varchar(50), în care se reține numele unei camere instalate pe un calculator.
Fig. 3.21. Tabela CAMERA
Între tabelele CAMERA și USER există relația n la n, deoarece un utilizator poate vizualiza mai multe camere, iar o cameră poate fi vizualizată de mai mulți utilizatori. De aceea între aceste două tabele am introdus tabela asociativă USER_RIGHT.
c. tabela USER_RIGHT în care sunt reținute drepturile de vizualizare ale unui utilizator asupra anumitor camere și care conține următoarele câmpuri:
– câmpul ID_USER_RIGHT, de tip int, cheia primară a tabelei USER_RIGHT, în care se reține un identificator unic pentru fiecare drept de vizualizare a unei camere. Este de tip IDENTITY, adică la fiecare adăugare a unui nou drept de vizualizare, se incrementează automat;
– câmpul ID_USER, de tip int, cheie străină în tabela USER_RIGHT, în care se reține identificatorul unic al utilizatorului care are dreptul de vizualizare dat de ID_USER_RIGHT;
– câmpul ID_CAMERA, de tip int, cheie străină în tabela USER_RIGHT, în care se reține identificatorul unic al camerei care poate fi vizualizată în baza dreptului de vizualizare dat de ID_USER_RIGHT de utilizatorul care are identificatorul ID_USER;
– câmpul CREATED_DATE, de tip datetime, în care se reține data și ora la care a fost creat acel drept de vizualizare.
Fig. 3.22. Tabela USER_RIGHT
Între tabela USER și tabela USER_RIGHT avem o relație 1 la n, ca și între tabelele CAMERA și USER_RIGHT.
d. tabela MOVEMENT, în care sunt reținute date despre cadrele în care a fost detectată mișcare și care conține următoarele câmpuri:
– câmpul ID_MOVEMENT, de tip int, cheia primară a tabelei MOVEMENT, în care se reține un identificator unic pentru un cadru în care a fost detectată mișcare. Este de tip IDENTITY, adică la fiecare adăugare a unui nou cadru în care a fost detectată mișcare, se incrementează automat;
– câmpul ID_CAMERA, de tip int, cheie străină în tabela MOVEMENT, în care se reține identificatorul unic al camerei de la care a apărut acel cadru în care a fost detectată mișcarea;
– câmpul BINARY_DATA, de tip image, în care se reține codificarea în binar (formatul UTF-8) al cadrului în care s-a detectat mișcare;
– câmpul CREATED_DATE, de tip datetime, în care se reține data și ora la care a fost detectată acea mișcare.
Standardul ASCII (American Standard Code for Information Interchange) stă la baza seturilor de caractere folosite în toate sistemele de operare moderne. Conform ASCII, caracterele limbii engleze sunt mapate în numere întregi pe 8 biți. Această mapare acoperă 256 de caractere literare și de control diferite. Bineînțeles, 256 de caractere nu acoperă toate limbile globului, așadar în decursul timpului alte forme de mapare au fost definite. După o serie de iterații s-a ajuns la Unicode.
Adoptat de către ISO (International Organization for Standardization) în 1996 devine astfel standard internațional sub numele de ISO-10646.
Standardul Unicode prevede un cod numeric unic pentru fiecare caracter, pe orice platformă hardware, în orice program software, și în orice limbă. Unicode este compatibil cu standardul ASCII astfel încât un document tipărit în ASCII poate fi interpretat corect în Unicode, dar nu și invers.
UTF8 (Unicode Transformation Format-8) este în esență o metodă de serializare a codurilor de caractere Unicode pe mai mulți octeți.
UTF-8 este o modalitate de codare pe octet (8 biți) al caracterelor Unicode. Acest format codează fiecare caracter Unicode ca un număr variabil de 1 până la 4 octeți, unde numărul de octeți depinde de valoarea întreagă asignată caracterului Unicode. Este o metodă eficientă de codare a documentelor Unicode care folosesc cel mai mult caracterele US-ASCII pentru că reprezintă fiecare caracter în limitele U+0000 până la U+007F ca un singur octet.
Fig. 3.23. Tabela MOVEMENT
Pentru fiecare dintre tabelele de mai sus am creat procedurile stocate CRUD (CREATE, READ, UPDATE, DELETE) pe care le-am folosit ulterior în dezvoltarea aplicației. De asemenea am mai creat proceduri stocate pentru returnarea ultimului cadru capturat de o anumită cameră, pentru returnarea istoricului imaginilor primite de la o anumită cameră la care un utilizator are acces, pentru returnarea unei entități (câmpurilor dintr-un tabel) care îndeplinesc o anumită condiție și pentru verificarea apariției unui cadru nou în baza de date.
Datele din baza de date au fost salvate în clase cu numele identic cu al tabelelor din baza de date, iar câmpurile tabelelor sunt salvate ca proprietăți ale claselor.
B. stratul DAL (DATA ACCESS LAYER) – reprezintă un cadru (framework) dezvoltat pentru a separa codul SQL de logica aplicației (BL). Acest strat se află între DB și BL cu rolul clar de translator între mediul .NET (un mediu în care obiectele, referințele,clasele și memoria joacă cel mai important rol) și mediul SQL în care limbajul T-SQL este cel mai important. Cele două nu au nimic în comun, în schimb prin acest strat se face legătura între ele.
C. stratul BL (BUSINESS LOGIC) – este stratul în care se creează efectiv cererile, în care se definesc și se orchestrează comenzile către baza de date (DB) din punct de vedere logic. Așadar BL va spune ce dorește de la baza de date, utilizând limbajul .NET, iar DAL-ul va traduce cererea în comandă SQL. Exemplu : stocarea unei imagini, verificarea de drepturi etc.
D. stratul FCD (FACADE) – acest strat joacă rol de punct de intrare către BL. Este de asemenea locul în care se țin informații despre utilizatorul logat la un moment dat. Orice parametri indiferent de cerere sunt preparați în acest strat. În fațadă se verifică autentificarea și se ține informația despre server-ul de date (locație, prin ce utilizator se conectează etc.). Așadar orice comandă către server-ul de date trece prin FCD, niciodată direct prin BL.
E. stratul FE (FRONT-END) – deasupra fațadei poate sta orice client al aplicației, prin client înțelegând orice aplicație care consumă baza de date, aici fiind vorba despre serviciul web care este consumat de aplicația care lucrează cu camera web și de aplicația web numită WebEye. Aplicația care lucrează cu camera web trimite informații către serviciul web care trimite datele pe server în baza de date.
Fig. 3.24. Structura FE (FRONT-END-ului)
Aplicația WebCam este partea din acest proiect care se ocupă de lucrul cu camera web instalată pe un anumit calculator. Această aplicație nu face decât să se conecteze la camera web, pe baza codului unic al camerei (acel HASH_CAMERA descris anterior) și din informația pe care o primește de la aceasta să facă o eșantionare la un interval de jumătate de secundă (500 ms). Primul cadru scos din fluxul de informație recepționat de la camera va fi considerat cadru inițial (Cadru_Vechi) aceasta urmând a fi comparat, cu ajutorul algoritmului de comparare a doua imagini descris anterior, cu următorul cadru care va fi scos la intervalul precizat (Cadru_Curent). Dacă între Cadru_Vechi și Cadru_Curent există diferențe, adică dacă există un număr de pixeli diferiți mai mare decât marja de eroare impusă, care este de 10% din totalitatea pixelilor, atunci aplicația va trimite prin intermediul serviciului web cadrul în care a fost detectată mișcarea (Cadru_Curent) pe server. Apoi Cadru_Vechi devine Cadru_Curent (din algoritmul de comparare a două imagini) și se reiau pașii descriși mai sus.
3.2.1. Algoritm de detecție a mișcării
Pentru detecția mișcării am folosit un algoritm simplu care compară două cadre succesive, eșantionate la un interval de jumătate de secundă. Am ales această soluție pentru că este foarte eficientă în condițiile în care tot acest proces trebuie să se deruleze foarte repede.
Tot din motive de eficiență am ales ca cele două cadre comparate să fie de tip Bitmap (BMP) pentru că din punct de vedere al calității imaginii este cea mai bună soluție.
În procedura de comparare am folosit două variabile de tip Color (currentbm1Color și currentbm2Color) pentru a reține pixelii din cele 2 cadre și trei variabile int pentru a reține diferența dintre cele două cadre, numărul total de pixeli și numărul total de pixeli diferiți (difference, totalPixeli respectiv totalDiferiti).
Având în vedere că toate cadrele sunt egale ca dimensiuni, având rezoluția de 640×480 (640 pixeli lățime și 480 pixeli înălțime), în două for-uri am parcurs lățimea și înălțimea unui cadru din cinci în cinci pixeli și am salvat pixelul curent (i,j) în currentbm1Color respectiv în currentbm2Color. Apoi în două variabile de tip int (argb1 și argb2) am reținut numărul de pixeli roșii, numărul de pixeli verzi și numărul de pixeli albaștrii.
Apoi am verificat dacă argb1 este mai mare sau egal decât argb2 atunci diferența dintre ele (difference) este:
argb2-argb1,
altfel este
argb1-argb2.
Dacă această diferență este mai mare decât 100 atunci se incrementează numărul de pixeli diferiți, iar numărul total de pixeli se incrementează oricum.
Se calculează apoi un procent, care reprezintă procentul de pixeli diferiți din numărul total de pixeli, cu formula:
percent=*100
Dacă acest procent este mai mare decât 10% din numărul total de pixeli (această cifră reprezentând marja de eroare acceptată), atunci înseamnă că a fost detectată mișcare.
Din motive de salvare a spațiului de stocare, cadrele în care a fost detectată mișcare vor fi salvate în formatul JPEG (Joint Photographic Experts Goup).
Am făcut această alegere deoarece formatul JPEG comprimă imaginile aducându-le la o dimensiune rezonabilă, în comparație cu BMP în care informația nu este comprimată și deci spațiul ocupat pentru stocare este mult mai mare, ajungând chiar până la de 4 ori mai mare decât dimensiunile unui JPEG. Deci la compararea imaginilor am folosit BMP datorită calității, iar la salvarea imaginilor am folosit JPEG datorită economisirii de spațiu.
Fig. 3.25. Algoritm de detecție a mișcării prin compararea a două cadre succesive
Codul sursă al algoritmului de detecție a mișcării:
using System;
using System.Drawing;
using System.Drawing.Imaging;
namespace ImgProcessing
{
/// <summary>
/// algoritm de comparare a doua cadre
/// </summary>
public class MovementCore
{
public static void Compare(Bitmap bm1, Bitmap bm2, out int percent)
{
Color currentbm1Color;
Color currentbm2Color;
int difference;
int totalPixeli = 0;
int totalDiferiti = 0;
for (int i = 0; i < bm1.Width; i+=5) {
for (int j = 0; j < bm1.Height; j+=5) { currentbm1Color = bm1.GetPixel(i, j);
currentbm2Color = bm2.GetPixel(i, j);
int argb1 = currentbm1Color.R + currentbm1Color.G + currentbm1Color.B;
int argb2 = currentbm2Color.R + currentbm2Color.G + currentbm2Color.B;
if (argb2 >= argb1)
{
difference = argb2 – argb1;
}
else
{
difference = argb1 – argb2;
}
if (difference > 100)
{
totalDiferiti++;
}
totalPixeli++;
}
}
percent = (int)(((float)totalDiferiti / (float)totalPixeli) * 100);
}
}
}
3.2.2. Protocoale de comunicație
Serviciul web de pe server, cel care se ocupă de trimiterea cadrelor în care s-a detectat mișcare de la o cameră web în baza de date, comunică prin protocolul SOAP cu calculatorul din acea locație.
SOAP este un protocol de comunicare între aplicații sau și mai simplu, este un protocol de acces la servicii WEB. El reprezintă un format pentru trimiterea mesajelor via Internet. SOAP este independent de platformă și limbaj, bazat pe XML și respectă recomandarile W3C (World Wide Web Consortium). SOAP vine să înlocuiască modul de comunicare RPC (Remote Procedure Calls) între aplicații cu un alt tip de comunicare tip HTTP. HTTP comunică via TCP/IP.
După cum sugerează și numele, XML (eXtensible Markup Language) este un sistem extensibil de marcare, adică, mai pe înțelesul tuturor, este un sistem de marcare similar cu HTML, doar că este mult mai bun și mai dinamic, diferența esențială fiind că tag-urile nu sunt definite, programatorul fiind liber să experimenteze.
Meta-limbajul XML a fost proiectat în scopul transferului de date între aplicații pe Internet.
XML este acum și un model de stocare a datelor nestructurate și semi-structurate în cadrul bazelor de date native XML. Datele XML pot fi utilizate în limbajul HTML , permit o identificare rapida a documentelor cu ajutorul motoarelor de căutare. Cu ajutorul codurilor javascript, php, etc. fișierele XML pot fi înglobate în paginile de Internet.
Avantaje:
extensibilitate (se pot defini noi indicatori dacă este nevoie);
validitate (se verifică corectitudinea structurală a datelor );
oferă utilizatorilor posibilitatea de a-și reprezenta datele într-un mod independent de aplicație;
XML este simplu și accesibil (sunt fișiere text create pentru a structura, stoca și a transporta informația);
poate fi editat, modificat foarte ușor (necesită doar un editor text simplu precum notepad, wordpad, etc. ).
HTTP (Hyper Text Transfer Protocol) este un protocol ce asigură transferul unor fișiere text în care conținutul a fost scris folosind limbajul HTML (Hyper Text Markup Language). Acest limbaj permite integrarea textului cu imaginile, cu alte elemente multimedia și cu elemente active. Acest limbaj a evoluat și a integrat tot mai multe elemente. În prezent se poate integra în corpul fișierelor HTML cod care se va executa pe server sau pe calculatorul client. De asemenea în paginile HTML se pot integra și programe precompilate în limbaje independente de platforma (cum ar fi JAVA), programe care se numesc „Applet” și care sunt rulate pe calculatorul clientului.
TCP (Transmission Control Protocol) și IP (Internet Protocol) sunt două protocoale separate care lucrează împreună, execută acțiuni care dirijează și ghidează deplasarea generală prin Internet a pachetelor de date. Ambele protocoale folosesc anteturi speciale care definesc conținutul fiecărui pachet și, dacă sunt mai multe, câte pachete urmează. TCP se ocupă de stabilirea conexiunilor între calculatoarele gazdă aflate la distanță; IP se ocupă cu adresarea și dirijarea pachetelor astfel încât acestea să ajungă la destinația dorită.
TCP este responsabil cu:
– Stabilirea conexiunii (handshaking);
– Dirijarea pachetelor;
– Controlul fluxului;
– Detecția și tratarea erorilor.
SOAP este un protocol bazat pe XML care presupune 3 parți:
un înveliș care definește un cadru (framework) pentru descrierea conținutului unui mesaj și cum se procesează acesta ;
un set de reguli de codificare pentru instanțe ale unor expresii din aplicații – tipuri de date definite ;
o convenție pentru reprezentarea apelurilor și răspunsurilor procedurilor apelate la distanță.
SOAP poate fi utilizat în combinație cu o varietate de alte protocoale, în special în combinație cu HTTP. SOAP folosește protocolul HTTP, conexiunile HTTP, majoritatea companiilor au serverele Web configurate pe portul standard 80 pentru conexiunile HTTP, deci protocolul poate sa fie folosit fără schimbări complexe în firewall-urile rețelelor, schimbări care pentru multe alte protocoale ar fi necesare.
Fig. 3.26. Cadru serviciu web
Aplicația client, care este singurul consumator al serviciului web, este reprezentată de partea de conectare la camera web dintr-o locație și compararea cadrelor succesive eșantionate la intervalul de jumătate de secundă. La detectarea unei mișcări la una dintre locațiile supravegheate aplicația client trimite către serviciul web un mesaj SOAP care conține acel cadru detectat codat în binar. Deci mesajul SOAP este doar un cadru care transportă cu ajutorul Internetului, și mai precis a protocolului de transport HTTP, codificarea în binar a cadrului către server, unde este instalat serviciul web. Apoi informația din mesajul SOAP este salvată cu ajutorul mecanismului de apelare al bazei de date în tabela MOVEMENT din baza de date, iar aplicația client primește un răspuns SOAP de confirmare a primirii.
Există câteva tipuri diferite ale modelelor de mesaje în SOAP, dar pe departe cel mai comun este modelul Apel de Procedura la Distanta (Remote Procedure Call – RPC), în care un nod de rețea (clientul) trimite un mesaj cerere către alt nod (server-ul), și server-ul imediat trimite un mesaj răspuns clientului. SOAP este succesorul XML-RPC, de aceea împrumută transportul și neutralitatea interacțiunii. Aplicațiile din ziua de astăzi comunică utilizând “Apelurile de Procedura la Distanta” (RPC – Remote Procedure Calls) dintre obiecte, dar HTTP nu a fost creat pentru acest lucru. RPC reprezintă o problemă de compatibilitate și securitate; firewall-urile și serverele proxy blochează în mod normal acest tip de trafic.O cale mai bună de comunicație între aplicații este prin HTTP, deoarece HTTP este suportat de toate browserele și serverele Internet. SOAP a fost creat să îndeplinească acest aspect.
Mesajele SOAP sunt codificate în documente XML care sunt alcătuite dintr-un înfășurător (SOAP envelope, obligatoriu), un header (SOAP header, opțional) și un body (SOAP body, obligatoriu).
Obligatoriu primul element dintr-un mesaj SOAP este envelope-ul (asemănător cu plicul unei scrisori). Conține informații despre sursa mesajului, recipientul mesajului și detalii despre mesaj în sine. De exemplu, header-ul envelope-ului poate specifica exact cum mesajul trebuie să fie procesat. Asta înseamnă că, înainte ca aplicația să proceseze mesajul poate afla informații despre mesaj, chiar și dacă aplicatia trebuie să proceseze mesajul sau nu. Diferit de apeluri RPC standard, unde mesajul trebuie să fie prelucrat total ca să aflăm dacă el trebuie procesat de noi sau numai trimis mai departe, header-ul SOAP poate indică dacă mesajul trebuie procesat sau trimis mai departe. Corpul mesajului conține numele metodei accesate și parametrii metodei.
Un client HTTP se conectează la un server HTTP folosind TCP. După stabilirea conexiunii, clientul poate trimite un mesaj către server:
POST / item HTTP/1.1
HOST: 189.123.345.239
Content-Type: text/plain
Content-Length: 200
Serverul proceseaza cererea si returneaza 200 (codul de succes pentru HTTP):
200 OK
Content-Type: text/plain
Content-Length: 200
sau cod 400 (nu a putut coda cererea)
400 Bad Request
Content-Length: 0
Iată un exemplu preluat de la W3Schools :
O cerere GetStockPrice este trimisă către server. Cererea are un parametru StockName, iar răspunsul un parametru Price. Funcția este definită în http://www.example.org/stock.
Cererea SOAP:
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
Răspunsul SOAP :
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
SOAP furnizează o cale de comunicație între aplicații care rulează pe diferite sisteme de operare, cu tehnologii și limbaje de programare diferite.
Avantaje :
Utilizând SOAP cu HTTP este permisă comunicația mai bună în spatele unui proxy sau firewall decât presupunea precedenta tehnologie de apel la distanță.
SOAP este destul de versatil pentru a permite utilizarea protocoalelor de transport diferite. Stiva standard utilizează HTTP ca protocol de transport, dar alte protocoale sunt de asemenea utilizabile.
Dezavantaje :
Din cauza lungimii formatului XML, SOAP poate fi destul de lent în comparație cu alte tehnologii. Aceasta poate să nu fie o problemă când se trimit numai mesaje scurte.
Când ne bazăm pe HTTP ca protocol de transport, rolurile părților care interacționează sunt stabilite. Doar o parte (clientul) poate utiliza serviciile altuia. Multe implementări SOAP limitează cantitatea de date care poate fi trimisă.
Fig. 3.27. Modelul serviciului Web
Analizînd modelul din figură, se observă, că apelurile SOAP sunt apeluri de funcții la distanță, care invocă execuțiile unor metode de cod asupra componentelor serviciilor Web. Rezultatul acestor metode este transformat în XML și retrimis utilizatorului. Consumatorii de servicii Web pot invoca cu ușurință metodele obiectelor aflate la distanță, utilizând SOAP și HTTP, iar datele vor fi returnate prin intermediul limbajului XML.
Termenul de serviciu web face referire la o componentă software care poate fi folosită de la distanță. Prin „servicii web", programatorii de obicei fac referire la serviciile web bazate pe XML.
Serviciile web sunt invocate de la distanță folosing protocoalele SOAP sau HTTP-GET și HTTP-POST. Serviciile web sunt bazate pe XML și întorc clientului un răspuns în format XML. Printre avantajele principale ale serviciilor web se numără:
Independența de limbaj și platformă: Serviciile web pot fi create și consumate pe orice sistem de operare, atâta vreme cât acesta suportă XML și protocolul SOAP.
Actualizări automate: Spre deosebire de componente, dacă un serviciu web necesită o actualizare, aceasta se propagă instant la toate aplicațiile ce consumă acest serviciu. Acest lucru se datorează faptului că metodele și proprietățile expuse de serviciul web funcționează ca și „black box-uri", adică utilizatorii nu sunt interesați de modul de funcționare al serviciului dacă acesta întoarce răspunsul așteptat.
. Descrierea interfeței
Aplicația client are o interfață grafică prietenoasă, simplă și foarte ușor de utilizat. Această aplicație nu face altceva decât să pornească monitorizarea, prin apăsarea butonului Start.
Butonul Stop oprește monitorizarea, iar Închide iese practic din aplicația client WebEye.
În meniul Ajutor se găsesc câteva informații despre aplicație și informații de contact și suport.
Fig. 3.28. Interfața grafică a aplicației client
La apăsarea butonului Start, din meniul Aplicație, se deschide o altă fereastră în care se cere autentificarea utilizatorului prin introducerea numelui utilizatorului și a parolei atribuite acestuia. Pornirea monitorizării este protejată prin parolă pentru a evita eventualele porniri ale monitorizării de către persoane neautorizate.
Fig. 3.29. Fereastra de autentificare
La apăsarea butonului Autentifică, dacă datele coincid cu cele din baza de date de pe server, se trece mai departe la fereastra CameraNameRequest. Dacă nu, atunci va apărea o eroare. La apăsarea butonului Închide se revine la meniul anterior.
Această fereastră (CameraNameRequest) apare numai la prima rulare și atribuie camerei de pe calculatorul respectiv un GUID – Global Unique Identifier (cod unic de 36 de caractere aleatoare) , care nu se poate modifica, și un nume pentru acea cameră ales de utilizator.
La apăsarea tastei Acceptă, în regiștrii, mai exact în directorul Software se creează un director webeye în care se scriu două variabile: CAMERA_NAME (numele ales de utilizator) și UNIQUE_ID (codul unic generat). Aceste date se vor adăuga și în baza de date de pe server.
Din acest moment orice altă rulare a aplicației client WebEye va detecta că o cameră a fost deja instalată pe acel calculator, citind regiștrii, și nu va mai fi nevoie de o altă atribuire de nume și cod.
Fig. 3.30. Meniul de atribuire a unui nume camerei conectate la calculator
Dacă totul decurge fără erori va apărea o fereastră în care scrie Success, acest lucru indicând faptul că totul a decurs perfect și marcând începutul monitorizării. Se va inițializa camera de pe calculatorul respectiv și dacă în urma comparării cadrelor succesive se găsesc diferențe, cadrele vor fi trimise pe server în baza de date.
Pentru vizualizarea eventualelor cadre capturate de la anumite camere, din anumite locații, utilizatorul se poate conecta la www.webeye.com/Licenta/Login.aspx.
Accesul la acest site este securizat prin parolă. În cazul în care un utilizator încearcă să intre pe site cu orice altceva decât un nume de utilizator și o parolă din baza de date primește un mesaj de eroare.
După logarea pe site în prima fereastră Login.aspx un utilizator poate vizualiza toate mișcările detectate de la camerele asupra cărora are drepturi de vizualizare.
Fig. 3.31. Logare în aplicația WebEye
Dacă utilizatorul a fost autentificat atunci se trece la următoarea pagină, Home.aspx, de unde utilizatorul poate accesa istoricul monitorizărilor, apăsînd butonul Istoric, poate citi câteva informații despre aplicație, apăsând butonul Despre sau poate ieși din aplicație apăsând butonul Ieșire.
Fig. 3.32. Meniul aplicației din pagina Home.aspx
De asemenea, tot aici administratorul poate gestiona conturile utilizatorilor, el fiind singurul care poate accesa pagina de Gestiune Utilizatori. Un alt utilizator care încearcă să acceseze acea pagină va primi un mesaj de avertizare, ca în figură.
Fig. 3.33. Mesaj de avertizare
La apăsarea butonului Gestiune Utilizatori, în cadrul aflat sub meniul aplicației apare un tabel care conține anumite informații despre conturile existente în baza de date, iar deasupra lui un buton Adaugă prin care administratorul poate creea conturi noi.
La apăsarea butonului Adaugă, tabelul cu datele utilizatorilor curenți devine inactiv, iar în dreapta acestuia apar mai multe câmpuri necompletate pentru definirea unui cont nou (numele utilizatorului, numele contului, parola, un check-box care îi atribuie viitorului utilizator drepturi de administrator sau nu, adresa de e-mail și o listă de check-box-uri cu toate camerele existente în baza de date, pentru atribuirea de drepturi de vizualizare). După ce administratorul a completat toate câmpurile și a dat drepturi de vizualizare noului utilizator el trebuie să apese butonul Salvează și datele vor apărea în tabelul cu utilizatori, acestea fiind automat salvate și în baza de date. Butonul Renunță iese din acest meniu și revine la tabelul cu utilizatori.
Butonul Editează din dreptul unui utilizator permite administratorului să facă modificări asupra unui cont. La apăsarea lui tabelul cu utilizatori devine inactiv, iar în dreapta lui apar aceleași câmpuri descrise anterior, numai că acum acestea sunt completate cu informațiile despre acel cont. Administratorul poate schimba numele utilizatorului, numele contului, parola, adresa de e-mail și poate da sau lua drepturi de vizualizare de pe anumite camere.
La apăsarea butonului Șterge din dreptul unui utilizator, contul acestuia va fi șters permanent din baza de date.
Fig. 3.34. Adăugarea unui cont nou din meniul Gestiune Utilizatori
La apăsarea butonului Istoric, în cadrul aflat sub meniu va apărea un calendar setat cu data curentă. Dacă în acea zi au fost detectate mișcări în diverse locații, iar utilizatorul logat are drepturi de vizualizare asupra acelor locații, atunci în dreapta calendarului va apărea un tabel în care sunt redate toate cadrele cu mișcare. Pe prima coloană a tabelului apare camera de la care au fost capturate acele cadre, pe a doua apare ora, minutul și secunda când au fost capturate cadrele, iar în a treia coloană apare un buton Descarcă. La apăsarea acestuia, în funcție de preferințele utilizatorului, acel cadru poate fi deschis pentru vizualizare (butonul Open) sau salvat pe un dispozitiv de stocare (butonul Save). Butonul Cancel revine la meniul anterior.
În cazul în care au apărut erori de orice fel, la apăsarea butonului Descarcă va fi descărcat de pe server un fișier text, denumit error.txt, în care este salvată eroarea survenită.
Fig. 3.35. Pagina de istoric
Dacă în ziua selectată nu au fost detectate mișcări în nicio locație sau utilizatorul logat nu are drepturi de vizualizare asupra acelor camere de la care s-a detectat mișcare, atunci apare un mesaj de avertizare ca în figură.
Fig. 3.36. Mesaj de avertizare
La apăsarea butonului Despre va apărea o fereastră cu câteva informații despre aplicație și informații de suport și contact.
Fig. 3.37. Meniul Despre
La apăsarea butonului Ieșire va apărea o fereastră ca în figura de mai jos și se va ieși din aplicație, utilizatorul fiind redirecționat către pagina de început (Login.aspx).
Fig. 3.38. Fereastra de închidere a aplicației
CAPITOLUL 4
TESTAREA APLICAȚIEI
Pentru testarea aplicației pe calculatorul care se află în locația care se dorește a fi supravegheată avem nevoie de următoarele :
• o cameră web și driver-ul aferent;
• aplicația Hamachi instalată și setată corespunzător atât pe server cât și pe client;
• pachetul Microsoft .NET Framework 3.5 instalat;
• aplicația client dezarhivată.
Instalarea unei camere web pe un calculator :
La introducerea cd-ului cu driverul camerei web instalarea pornește automat, iar din meniul de instalare trebuie selectată opțiunea Driver.
Fig. 4.1. Meniul de instalare al camerei web
Se cere apoi selectarea limbii de instalare. Dintr-o listă utilizatorul urmează să își aleagă limba în care se va desfășura în continuare instalarea. După selectarea limbii utilizatorul va trebui să apese butonul Next.
Fig. 4.2. Meniul de selecție al limbii de instalare
Dacă instalarea se încheie cu succes va apărea următoarea fereastră care indică acest lucru, iar din acest moment când utilizatorul conectează camera web pe USB calculatorul o va detecta, camera fiind funcțională.
Fig. 4.3. Terminarea instalării camerei web pe un calculator
Instalarea aplicației Hamachi:
În continuare, pentru a instala aplicația Hamachi, rulăm HamachiSetup-1.0.3.0-en.exe. Pentru a continua instalarea se cere apăsarea butonului Next.
Fig. 4.4. Instalarea aplicației Hamachi
Deși este o aplicație shareware (termenul se referă la un software comercial care este supus regulilor dreptului de autor, dar care poate fi copiat cu scopul de a fi încercat), utilizatorul trebuie să accepte condițiile de utilizare. Utilizatorul va apăsa butonul Next.
Fig. 4.5. Acceptarea condițiilor de instalare a aplicației Hamachi
În continuare utilizatorul trebuie să selecteze directorul de instalare și dacă dorește poate selecta opțiunea de creare a unei scurtături pe desktop și de pornire automată a aplicației o dată cu pornirea sistemului de operare.
Fig. 4.6. Selectarea directorului de instalare
În următoarea fereastră se cere selectarea modului de utilizare a aplicației Hamachi. Utilizatorul poate alege dintre mai multe opțiuni (de utilizare cu licență ne-comercială, de evaluare a produsului sau de utilizare cu licență comercială), după care va trebui să apese butonul Next.
Fig. 4.7. Selectarea modului de utilizare a aplicației Hamachi
Dacă instalarea a decurs fără probleme va apărea următoarea fereastra care indică acest lucru, iar utilizatorul va trebui să apese butonul Finish.
Fig. 4.8. Terminarea instalării aplicației Hamachi
Aplicația Hamachi trebuie instalată atât pe server-ul cu baza de date cât și pe fiecare calculator aflat în locațiile de supravegheat. Imediat după terminarea instalării aplicației pe un calculator, aplicația atribuie acelui calculator un IP (exemplu: 5.103.51.125 IP-ul server-ului și 5.129.52.40 IP-ul unui calculator din rețea ) care va fi adresa calculatorului în rețeaua VPN creată.
Pe server am creat rețeaua virtuală WebEye, rețea protejată printr-o parolă, la care ulterior am adăugat fiecare dintre calculatoarele din locațiile de supravegheat.
Fig. 4.9. Crearea pe server a unei rețele noi (WebEye) și adăugarea în rețea de calculatoare
Pentru adăugarea unui calculator în rețeaua WebEye un utilizator nu trebuie decât să selecteze din meniul Networking Menu, opțiunea Join an existing network și să completeze numele rețelei și parola setată de administrator pentru acea rețea.
Fig. 4.10. Adăugarea unui calculator în rețeaua WebEye
În continuare pe calculatorul aflat în locația care se dorește a fi supravegheată se dezarhivează arhiva client.rar și în fișierul text configuration.txt se face următoarea modificare: în loc de http://localhost/WebEyeService/Service.asmx trebuie scris http://5.103.51.125/WebEyeService/Service.asmx (IP-ul server-ului unde se află serviciul web Service care se ocupă de transmiterea cadrelor în care s-a detectat mișcare de la calculatoarele client către baza de date de pe server).
Pentru pornirea efectivă a monitorizării se face dublu click pe CameraDriver.exe, aceasta pornind aplicația client WebEye.
Fig. 4.11. Meniul aplicației client WebEye
La apăsarea butonului Start, din meniul Aplicație se deschide o altă fereastră în care se cere autentificarea utilizatorului prin introducerea numelui utilizatorului și a parolei atribuite acestuia. Butonul Stop întrerupe monitozarea, iar butonul Închide iese practic din aplicație.
În meniul Ajutor sunt câteva detalii despre aplicația WebEye.
Fig. 4.12. Fereastra de autentificare a utilizatorului
La apăsarea butonului Autentifică, dacă datele coincid cu cele din baza de date de pe server, se trece mai departe la fereastra CameraNameRequest. Dacă nu, atunci va apărea o eroare. La apăsarea butonului Închide se revine la meniul anterior.
Această fereastră (CameraNameRequest) apare numai la prima rulare și atribuie camerei de pe calculatorul respectiv un GUID – Global Unique Identifier (cod unic de 36 de caractere aleatoare) , care nu se poate modifica și un nume pentru acea cameră ales de utilizator.
La apăsarea tastei Acceptă, în regiștrii, mai exact în directorul Software se creează un director webeye în care se scriu două variabile: CAMERA_NAME (numele ales de utilizator-Dormitor) și UNIQUE_ID (codul unic generat: 3054c8f0-f31b-42de-946f-9fe5b63833da). Aceste date se vor adauga și în baza de date de pe server.
Din acest moment orice altă rulare a aplicației client WebEye va detecta că o cameră a fost deja instalată pe acel calculator, citind regiștrii, și nu va mai fi nevoie de o altă atribuire de nume și cod.
Fig. 4.13. Meniul de atribuire a unui nume camerei conectate la calculator
Fig. 4.14. Regiștrii cu cele două variabile
Dacă totul decurge fără erori va apărea o fereastră în care scrie Success, acest lucru indicând faptul că totul a decurs perfect și marcând începutul monitorizării. Se va inițializa camera de pe calculatorul respectiv și dacă în urma comparării cadrelor succesive se găsesc diferențe, cadrele vor fi trimise pe server în baza de date.
Pentru vizualizarea eventualelor cadre capturate de la anumite camere, din anumite locații utilizatorul se poate conecta la www.webeye.com/Licenta/Login.aspx, după ce în prealabil efectuează următoarea modificare: în C:\WINDOWS\system32\drivers\etc există un fișier hosts care trebuie deschis cu utilitarul Notepad și adăugat pe ultima linie 5.103.51.125 www.webeye.com.
Accesul la acest site este securizat prin parolă. În cazul în care un utilizator încearcă să intre pe site cu orice altceva decât un nume de utilizator și o parolă din baza de date primește un mesaj de eroare.
După adăugarea unei camere noi administratorul va trebui să se logheze pe site și să dea drepturi de vizualizare oricărui utilizator consideră el că e îndreptățit să le primească. Această atribuire de drepturi se face din meniul Gestiune Utilizatori, prin apăsarea butonului Editează la utilizatorii aleși și prin bifarea camerei nou adăugate. Această operațiune trebuie făcută și pentru administrator în cazul în care dorește să vizualizeze imagini de pe acea cameră.
Fig. 4.15. Atribuirea de drepturi de vizualizare
După instalarea și setarea tuturor componentelor necesare pentru testarea aplicației pe un anumit calculator (urmând toți pașii descriși anterior în fig. 4.1.-4.15.), în data de 24.06.2009 s-a pornit monitorizarea la locația denumită generic Dormitor în aplicație (fig. 4.13.).
După un anumit interval de timp, pe un alt calculator, denumit generic Acasă, pe care deja au fost făcuți toți pașii de instalare și setare, se pornește monitorizarea. În figura de mai jos se poate vedea informația din regiștrii de pe calculatorul din locația denumită Acasă.
Fig. 4.16. Regiștrii cu informații despre numele camerei și codul unic din locația Acasă
Pentru vizualizarea rezultatelor, utilizatorul se va loga pe site cu numele de utilizator și parola atribuite lui, iar dacă are drepturi de vizualizare pe cele două camere, în meniul Istoric, el va putea observa toate imaginile în care s-a detectat mișcare de la cele două locații.
Fig. 4.17. Logare în aplicația WebEye
Având în vedere că logarea s-a făcut cu numele de utilizator și parola administratorului, iar acesta și-a atribuit drepturi de vizualizare pe toate camerele, în fereastra Istoric apar toate cadrele în care s-a detectat mișcare din cele două locații.
Data setată implicit pentru calendar este cea actuală. Selectând din calendar data la care s-a făcut testul (24 iunie 2009), în dreapta calendarului, într-un tabel cu 3 coloane, vor apărea cadrele. Pe prima coloană este reținut numele camerei de la care a fost trimis cadrul, pe a doua este ora, minutul și secunda la care a fost detectată acea mișcare, iar în a treia coloană apare un buton Descarcă, în dreptul fiecărui cadru. La apăsarea acestuia, în funcție de preferințele utilizatorului, acel cadru poate fi deschis pentru vizualizare (butonul Open) sau salvat pe un dispozitiv de stocare (butonul Save). Butonul Cancel revine la meniul anterior.
În cazul în care au apărut erori de orice fel, la apăsarea butonului Descarcă va fi descărcat de pe server un fișier text, denumit error.txt, în care este salvată eroarea survenită.
Fig. 4.18. Pagina de istoric
CAPITOLUL 5
CONCLUZII
Datorită societății și vremurilor în care trăim aș putea spune că supravegherea locuințelor, a sediului unor firme, a spitalelor și în general a punctelor de interes pentru un individ este imperios necesară pentru că nimeni nu mai este în siguranță nicăieri. De aceea specialiștii în domeniu caută în fiecare zi tehnologii cât mai avansate și moderne de supraveghere.
Pentru orice obiectiv economic, indiferent de dimensiunea acestuia, securitatea este de multe ori o problema vitală. Firmele sunt nevoite să investească sume considerabile pentru crearea unor infrastructuri care să le permită supravegherea spațiilor în care își desfășoară activitatea.
Proiectul de față propune o nouă soluție în ceea ce privește supravegherea spațiilor în care firmele își desfașoară activitatea : conectarea la un calculator a unei camere web și transmiterea numai de imagini "relevante" într-o bază de date.
Aplicația dezvoltată în acest proiect își propune să ofere o alternativă pentru sistemele de supraveghere clasice, fiind o modalitate eficientă de monitorizare a unor locații. Eliminarea stocării informațiilor redundante este una dintre problemele majore pe care o rezolvă.
Aplicația are o largă arie de utilizabilitate, pe lângă supravegherea unor spații comerciale, a unor birouri sau a unor puncte importante din cadrul unor societăți, aceasta putând fi utilizată în realizarea așa numitelor „vizite virtuale”. Astfel bunicii pot vedea ce face nepotul lor, un medic poate vedea ce face pacientul lui, un părinte aflat la serviciu poate vedea ce face copilul lui acasa ș.a.m.d.
Datorită structurii aplicației, modulele rezultate pot fi oricând folosite în alte proiecte, pot fi de asemenea îmbunătățite fără prea mari eforturi, iar aplicația poate fi extinsă și decorată cu noi funcționalități fără să afecteze cu nimic codul actual.
Principalul avantaj al acestei aplicații este acela că utilizează resurse hardware minime, prin transmiterea în baza de date doar a acelor cadre relevante. Pe lângă acest avantaj ar mai fi și extensibilitatea aplicației pe alte calculatoare din alte locații cu efort minim, datorită ușurinței la instalare.
După cum am menționat, aplicația poate fi oricând îmbunătățită prin adăugarea unor noi module cu diverse funcționalități. Ca și perspectivă de viitor, pentru a îmbunătăți aplicația m-am gândit la implementarea unui modul care să alerteze un utilizator atunci când se produce un eveniment într-o locație asupra căruia acel utilizator are drepturi de vizualizare. Prin eveniment se poate înțelege detectarea unei mișcări în acea locație. Alertarea poate fi făcută fie prin e-mail, fie prin SMS, adăugarea acestui modul neafectând în niciun fel codul actual.
Bibliografie
Charles Petzold : „Programare Windows cu C#”, București, Ed. Teora, 2005;
Pappas Chris H., Murray William H., Trad. Caranda Bogdan, Raica Razvan : „C# pentru programarea web”, București, Ed. ALL, 2006;
Grimes Richard : „Dezvoltarea aplicațiilor cu Visual Studio .NET”, București, Ed. Teora, 2006;
Martin Joe, Tomson Brett : „Introducere în ASP.NET“, București, Ed.Teora, 2006 ;
Richter Jeffrey : „Microsoft .NET Framework”, București, Ed. Teora, 2007;
Esposito Dino : „Soluții Web cu ASP.NET și ADO.NET“, București, Ed. Teora, 2003;
Dollinger Robert, Andron Luciana : „Utilizarea sistemului SQL Server”, București, Ed. Albastră, 2005;
Henderson Ken : „Transact-SQL”, București, Ed. Teora, 2006;
Melnic Vladimir : „Sisteme electronice de supraveghere”, București, Ed. Teora, 2001;
Popescu Laurențiu, Tuleș Viorel : „Sisteme de detecție, supraveghere video și de monitorizare control acces și comunicații”, București, Ed. Polirom, 2008;
http://en.wikipedia.org/wiki/Three-tier_(computing);
http://www.w3schools.com/aspnet/default.asp;
http://www.w3schools.com/ado/default.asp;
http://www.w3schools.com/sql/default.asp;
http://www.w3schools.com/soap/default.asp.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Sistem DE Supraveghere Utilizand Camere Web (ID: 149344)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
