Performanta Energentica
C U P R I N S
INTRODUCERE
CAPITOLUL I – ASPECTE TEORETICE
1.1. Performanța energetică a clădirii
1.2. Certificatul de Performanță Energetică
1.3. Auditarea energetică
1.4. Raportul de Audit Energetic
1.5. Clasificarea clădirilor din punct de vedere al aplicării metodoclogiei MC001
1.7. Scheme logice generale de aplicare a metodologiei de calcul a performanței energetice a clădirilor
1.8. Elaborarea Certificatului de performanță energetică
CAPITOLUL II – PROIECTAREA APLCAȚIEI INFORMATICE
2.1. Definirea obiectivelor aplicației informatice
2.2. Fluxul general de prelucrare a datelor
2.3. Specificațiile de control și securitate a datelor
2.4. Arhitectura aplicației informatice
2.5. Proiectarea bazei de date
2.6. Proiectarea logică a aplicației informatice
2.7. Proiectarea interfeței grafice a aplicației
CAPITOLUL III – TEHNOLOGII UTILIZATE ÎN PROGRAMAREA APLICAȚIEI WINDOWS
3.1. Alegerea limbajului de programare
3.1.1. Platforma .NET și componentele acesteia
3.1.2. Limbajul de programare C Sharp (#)
3.2. Alegerea modalitatii de stocare a datelor
3.2.1. SQL Server 2008
3.3. Alegerea mediului de dezvoltare a aplicației.
CAPITOLUL IV – DEZVOLTARE ȘI IMPLEMENTAREA APLICAȚIEI INFORMATICE
4.1. Etapele dezvoltării aplicației TermoExpert
4.2. Crearea și organizara fișierelor aplicației în Visual Studio 2010
4.3. Dezvoltarea etapei de logică a aplicației (Business Logic Layer)
4.3.1. Crearea claselor unui proiect de audit
4.3.2. Proprietăți automat-implementate
4.3.3. Alegerea tipurilor de date
4.3.4. Inițializarea datelor
4.4. Construirea interfeței cu utilizatorul (Presentation layer)
4.3.1. Fereastra principală
4.3.2. Fereastra Caracteristici geometrice
4.3.2. Legătura între un obiect și proprietatea unui control
4.3.3. Generice și moștenirea vizuală
4.3.4. Constuirea rapoartelor cu Microsoft Reports
4.4. Realizarea accesului la date cu Ado.Net (Data Access Layer)
4.4.1. Entity Framework
4.4.2. Entity Framework – Code first
4.4.3. Code-First – Automatic Migration
4.5. Construirea bazei de date TermoExpert folosind EntityFramework
4.6. Securizarea aplicației
4.7. Implementarea aplicației
4.8. Testare și experimentare
4.9. Utilizare și întreținere
CONCLUZII
BIBLIOGRAFIE
ANEXE
Lista figurilor
Figura 1 – Schema logică generală pentru certificarea energetică a clădirilor existente (MC001 – p26) 8
Figura 2 – Fluxul general de prelucrare a datelor unui proiect de calcul a performanței energetice a clădirilor 18
Figura 3 – Subnivelurile arhitecturii client server 20
Figura 4 – Relatiile dintre clase 28
Figura 5 – Relația dintre componentele platformei .Net 31
Figura 6 – Base Class Libraries 32
Figura 7 – Funcționalitățile SQL Server 2008 35
Figura 8 – Modelul arhitecturii aplicației TermoExpert 37
Figura 9 – Organizarea claselor în cadrul proiectului 38
Figura 10 – Relați între clasele unui proiect 39
Figura 11 – Definirea proprietăților în .Net 4.0 42
Figura 12 – Tipuri de date în .Net 4.0 43
Figura 13 – Tipuri valoare, tipuri referinta 44
Figura 14 – Meniul principal al aplicației TermoExpert 45
Figura 15 – Accesarea caracteristicilor geometrice din meniul aplicației 46
Figura 16 – Fereastra “Caracteristici geometrice” 46
Figura 17 – Microsoft Report 52
Figura 18 – Legătura dintre obiect și baza de date prin intermediul Data Adapteru-ului 53
Figura 19 – Relatiile dintre componentele Entity Framework, baza de date și obiectele din aplicație 55
Figura 20 – Model tabele Entity Freamework 55
Figura 21 – Generator cheie securitate TermoExpert 63
Figura 22 – Rezultat dupa executia testelor – Unit Testing 64
INTRODUCERE
Certificarea energetică a unei clădiri este un proces ce implică analizarea din punct de vedere termic și energetic o clădire în urma căruia rezultă eficiența energetică a acesteia. În urma certificării energetice proprietarii de clădiri vor putea beneficia de documente tehnice prin care sunt reflectate performanțele energetice ale clădirilor pe care le dețin. Aceste documente tehnice sunt întocmite doar de către persoane autorizate numite “Auditori Energetici” iar datele acestora sunt stabilite pe baza unui algoritm de calcul coerent elaborat în reglementarea tehnică numită “Metodologia de calcul al performanței energetice a clădirilor”.
Scopul lucrării este de a prezenta elaborarea unei aplicații informatice de calculare a performanței energetice a clădirilor. Aplicația va suporta: introducerea datelor, calcularea datelor, raportarea datelor intermediare și finale, imprimarea datelor, salvarea datelor.
Cerința de bază care a condus la dezvoltarea aplicației a fost data de faptul că în România “Certificatul de performanță energetică” reprezintă o exigență a Uniunii Europene ce trebuia pusă în practică din 2007, de la aderare. Începând cu anul 2011, certificatul a devenit obligatoriu și în România, la vânzarea sau închirierea unui imobil.
Aplicația informatică este destinată Auditorilor Energetici atestați de către Ministerul Dezvoltării Regionale și Turismului iar principalul său avantaj îl constituie creșterea operativității acestora. Prin creșterea operativității se înțelege în general optimizarea timpilor de procesare a datelor, a timpilor de execuție a diferitelor operații de calcul specifice și reducerea resurselor umane alocate.
Rezultatul aplicației informatice este compus din rapoarte ce au utilitate în:
certificarea și clasificarea energetică a clădirilor;
stabilirea masurilor de reabilitare energetică pentru indeplinirea·exigentelor impuse de normele în vigoare;
intocmirea studiilor de fezabilitate și a proiectelor de executie;
intocmirea documentatiei pentru obtinerea avizelor de executie;
intocmirea documentatiilor pentru obtinerea imprumuturilor bancare;
intocmirea documentatiilor pentru a accede programele de·finantare a reabilitarii ·energetice a clădirilor și a instalatiilor.
CAPITOLUL I – ASPECTE TEORETICE
1.1. Performanța energetică a clădirii
Performanța energetică a clădirii (PEC) reprezinta energia efectiv consumată sau estimată pentru a răspunde necesităților legate de utilizarea normală a clădirii, necesități care includ în principal: încălzirea, prepararea apei calde de consum, răcirea, ventilareași iluminatul.
Performanța energetică a clădirii se determină conform unei metodologii de calcul și se exprimă prin unul sau mai mulți indicatori numerici care se calculează luându-se în considerare izolația termică, caracteristicile tehnice ale clădirii și instalațiilor, proiectarea și amplasarea clădirii în raport cu factorii climatici exteriori, expunerea la soare și influența clădirilor învecinate, sursele proprii deproducere a energieiși alți factori, inclusiv climatul interior al clădirii, care influențează necesarul de energie.
(Indicativ MC 001/1 -2006, Partea I – Anvelopa cladirii, p. 5)
1.2. Certificatul de Performanță Energetică
Evaluarea performanțelor energetice ale unei clădiri existente se referă la determinarea nivelului de protecție termică al clădirii și a eficienței energetice a instalației de încălzire interioară și de preparare a apei calde de consum și vizează în principal: investigarea preliminară a clădirii și a instalațiilor aferente analiza documentației care a stat la baza execuției clădirii și instalațiilor termice aferente, analiza stării actuale a construcției și instalațiilor aferente acesteia (analiza elementelor caracteristice privind amplasarea clădirii în mediul construit, analiza vizuală a stării clădirii, efectuarea de măsurări , prelevarea de probe fizice etc.) întocmirea fișei de expertiză a clădirii, care este Anexa la CPE determinarea performanțelor energetice ale construcției și ale instalațiilor termice aferente acesteia, precum și a consumului anual normal de căldură al clădirii pentru încălzirea spațiilor și prepararea apei calde de consum, determinarea rezistențelor termice corectate ale elementelor de construcție din componența anvelopei clădirii, determinarea parametrilor termodinamici intensivi caracteristici spațiilor încălzite și neîncălzite ale clădirii, determinarea consumului anual normal de căldură, total și specific (prin raportare la suprafața utilă a spațiilor încălzite), pentru încălzirea spațiilor, la nivelul sursei de căldură a clădirii, determinarea consumului anual normal de căldură, total și specific, pentru prepararea apei calde de consum, la nivelul sursei de căldură a clădirii.
(Indicativ MC 001/3 -2006,
Partea III – Auditul și certificatul de performnanta al cladirii, p. 20-21)
1.3. Auditarea energetică
Auditarea energetică a unei clădiri existente și a instalatiilor sale, presupune analizarea termică și energetică a constructiei , determinarea consumurilor anuale de energie și stabilirea, din punct de vedere tehnic și economic, a soluțiilor de reabilitare sau modernizare termică și energetică a construcției și a instalațiilor aferente acesteia. Auditul energetic al unei clădiri urmărește stabilirea performantele reale ale construcției și ale instalațiilor aferente.
Prin auditare se identifică soluțiile tehnice de reabilitare sau modernizare energetică. Aceste soluții se prezinta beneficiarului, împreună cu calculele economice privind costul investiției și durata de amortizare realizată pe baza cuantificării economiilor obținute prin aplicarea fiecăreia dintre măsuri.
Scopul principal al auditării și aplicării măsurilor identificate îl constituie scăderea consumurilor de energie necesare pentru încălzirea spațiilor, ventilare/climatizare, apă caldă de consum, iluminat , în condițiile asigurării unui microclimat confortabil.
Activitatea de auditare energetică se materializează prin întocmirea unui dosar de audit energetic care cuprinde Raportul de Audit Energetic și reprezintă, în cazul unei clădiri sau a unui apartament , studierea modului de utilizare a tuturor formelor de energie consumate sau operațiunea prin care se identifică principalele caracteristici termice și energetice ale construcției și ale instalațiilor aferente acesteia și se determină consumurile anuale de energie pentru încălzirea spațiilor, ventilare/climatizare, apă caldă de consum și iluminat.
În conformitate cu legislația românească în domeniu – Metodologia de calcul a performanței energetice a clădirilor Mc-001 partile 1,2,3 aparute în 2006 și partile 4 și 5 apărute în 2009 – expertiza energetică se referă la clădiri existente , în cadrul cărora se desfașoară activitați care necesită asigurarea unui grad de confort termic corespunzator reglementarilor actuale.
Expertiza energetică trebuie sa evidențieze starea clădirii și a instalațiilor, menționând acele elemente care influențează negativ comportamentul clădirii și eficiența utilizării energiei.
(Indicativ MC 001/3 -2006,
Partea III – Auditul și certificatul de performnanta al cladirii, p. 19-20)
1.4. Raportul de Audit Energetic
Întocmirea Raportului de Audit Energetic este un element esențial al procedurii de realizare a auditului energetic și reprezintă o prezentare a modului în care a fost efectuat auditul, a principalelor caracteristici energetice ale clădirii, a măsurilor propuse de modernizare energetică a clădirii și instalațiilor aferente acesteia, precum și a concluziilor referitoare la măsurile eficiente din punct de vedere economic.
Această prezentare trebuie adaptată de fiecare dată funcție de beneficiarul potențial al raportului, ținând seama de faptul că în final, acesta va fi cel care va decide în privința modernizării energetice a clădirii.
Forma în care este întocmit Raportul de Audit Energetic, prezentarea acestuia, modul de redactare, claritatea și ușurința de interpretare a conținutului acestuia sunt esențiale pentru beneficiarul raportului. Raportul de Audit Energetic al unei clădiri trebuie să cuprindă următoarele elemente: date de identificare a clădirii supuse auditului energetic și a proprietarului/administratorului acesteia, numele și prenumele proprietarului (în cazul uază prin întocmirea unui dosar de audit energetic care cuprinde Raportul de Audit Energetic și reprezintă, în cazul unei clădiri sau a unui apartament , studierea modului de utilizare a tuturor formelor de energie consumate sau operațiunea prin care se identifică principalele caracteristici termice și energetice ale construcției și ale instalațiilor aferente acesteia și se determină consumurile anuale de energie pentru încălzirea spațiilor, ventilare/climatizare, apă caldă de consum și iluminat.
În conformitate cu legislația românească în domeniu – Metodologia de calcul a performanței energetice a clădirilor Mc-001 partile 1,2,3 aparute în 2006 și partile 4 și 5 apărute în 2009 – expertiza energetică se referă la clădiri existente , în cadrul cărora se desfașoară activitați care necesită asigurarea unui grad de confort termic corespunzator reglementarilor actuale.
Expertiza energetică trebuie sa evidențieze starea clădirii și a instalațiilor, menționând acele elemente care influențează negativ comportamentul clădirii și eficiența utilizării energiei.
(Indicativ MC 001/3 -2006,
Partea III – Auditul și certificatul de performnanta al cladirii, p. 19-20)
1.4. Raportul de Audit Energetic
Întocmirea Raportului de Audit Energetic este un element esențial al procedurii de realizare a auditului energetic și reprezintă o prezentare a modului în care a fost efectuat auditul, a principalelor caracteristici energetice ale clădirii, a măsurilor propuse de modernizare energetică a clădirii și instalațiilor aferente acesteia, precum și a concluziilor referitoare la măsurile eficiente din punct de vedere economic.
Această prezentare trebuie adaptată de fiecare dată funcție de beneficiarul potențial al raportului, ținând seama de faptul că în final, acesta va fi cel care va decide în privința modernizării energetice a clădirii.
Forma în care este întocmit Raportul de Audit Energetic, prezentarea acestuia, modul de redactare, claritatea și ușurința de interpretare a conținutului acestuia sunt esențiale pentru beneficiarul raportului. Raportul de Audit Energetic al unei clădiri trebuie să cuprindă următoarele elemente: date de identificare a clădirii supuse auditului energetic și a proprietarului/administratorului acesteia, numele și prenumele proprietarului (în cazul unui singur proprietar) sau denumirea asociației de proprietari (în cazul mai multor proprietari) și numele administratorului clădirii, adresa clădirii: stradă, număr, oraș și județ/sector, cod poștal, numărul de telefon al proprietarului sau al administratorului clădirii (responsabil), date de identificare a auditorului energetic pentru clădiri sau a biroului de consultanță energetică care a efectuat analiza termică și energetică și auditul energetic al clădirii, numele auditorului energetic pentru clădiri, adresă, nr. telefon, nr. certificat de atestare, data efectuării analizei termice și energetice.
(Indicativ MC 001/3 -2006,
Partea III – Auditul și certificatul de performnanta al cladirii, p. 19-20)
1.5. Clasificarea clădirilor din punct de vedere al aplicării metodoclogiei MC001
Pentru aplicarea corectă a Metodologiei de calcul al performanței energetice a clădirilor Mc001-2007 (denumită în continuare Metodologia Mc001) este necesară încadrarea clădirii analizate (construcție+instalațiile aferente) într-una din următoarele situații de calcul:
Clădire existentă sau clădire nouă (în faza de proiectare sau având mai puțin de 2 ani de funcționare, în garanție);
Clădire rezidențială (individuală sau colectivă) sau clădire din domeniul terțiar (școli, spitale, săli de spectacol, spații comerciale, birouri, bănci sau alte tipuri);
Clădire monozonă sau multizonă;
Clădire cu ocupare continuă sau discontinuă (instalațiile au funcționare continuă sau intermitentă);
Clădire de categoria I (clădirile cu “ocupare continuă” și clădirile cu “ocupare discontinuă” de clasă de inerție termică mare) sau clădire de categoria II (clădirile cu “ocupare discontinuă” și clasă de inerție medie sau mică);
Clădire prevăzută cu instalații de:
– încălzire + iluminat;
– încălzire + iluminat + a.c.c.;
– încălzire + iluminat + a.c.c. + ventilare (naturală sau mecanică);
– încălzire + iluminat + a.c.c. + răcire (splituri, CTA, ventilo-convectoare etc.);
– încălzire + iluminat + a.c.c. + climatizare;
– alte combinații de instalații;
(Brviar de calcul al performanței energetice a clădirilor, p. 8)
1.7. Scheme logice generale de aplicare a metodologiei de calcul a performanței energetice a clădirilor
Modul general de abordare pentru determinarea performanței energetice a clădirilor, pentru certificarea energetică și pentru propunerea măsurilor de reabilitare energetică este descris de schemele logice generale din figura 1.
Din schema logica prezentate în figura 1 rezultă că etapele generale aferente certificării de performanță energetică sunt următoarele:
analiza energetică a clădirii și instalațiilor aferente acesteia;
întocmirea certificatului de performanță energetică (CPE) și completarea anexelor care însoțesc certificatul de performanță energetică.
Analiza energetică presupune ca pe baza informațiilor privind:
– zona climatică în care este amplasată clădirea, inclusiv vecinătățile;
– tipul clădirii conform clasificării din capitolul I al Breviarului de calcul;
– caracteristicile termo-tehnice ale elementelor de construcție care alcătuiesc anvelopa clădirii, starea și configurația acestora;
– tipurile instalațiilor interioare existente și starea acestora, caracteristicile tehnice și regimul lor de funcționare, precum și starea acestora, să se calculeze estimativ și în condiții normale de funcționare, toate consumurile energetice anuale globale (MWh/an) și specifice (kWh/m2,an) ale sistemelor de instalații cu care clădirea este echipată. Toate informațiile necesare calculelor de consumuri energetice vor fi culese atât direct pe teren cât și din documentația tehnică existentă (Cartea Tehnică a Construcției). Formulele aplicabile fiecărui caz în parte sunt prezentate detaliat în Metodologia Mc001, părțile P I și P II.
Certificarea energetică presupune ca pe baza datelor obținute prin aplicarea formulelor de calcul din Metodologia Mc001-PI și PII, să se încadreze clădirea într-una din clasele de performanță energetică (A…G), să se acorde o notă energetică clădirii (20…100) și să se compare clădirea reală cu o clădire virtuală, denumită “clădire de referință”. Se estimează de asemenea consumurile de energie primară și emisiile de CO2 astfel ca datele obținute pe baza aplicării Metodologiei Mc001 să fie utilizate ulterior la întocmirea Documentației Tehnice de Avizare a lucrărilor de reabilitare.
(Brviar de calcul al performanței energetice a clădirilor, p. 9-15)
Figura 1 – Schema logică generală pentru certificarea energetică a clădirilor existente (MC001 – p26)
1.8. Elaborarea Certificatului de performanță energetică
Elaborarea certificatului de performanță energetică a unei clădiri presupune parcurgerea următoarelor etape:
1. Determinarea consumurilor anuale specifice ale clădirii certificate reale, pentru fiecare tip de instalație în parte (incalzire, apa calda de consum, climatizare, ventilare, iluminat)
2. Definirea clădirii de referință asociată clădirii reale și evaluarea performanței energetice a acesteia
3. Încadrarea în clasele de performanță și de mediu folosind referențialele energetice adecvate categoriei de clădire (locuință individuală, bloc de apartamente, clădire de birouri, spital, centru comercial, hotel, clădire de învățământ etc.);
4.Notarea energetică a clădirilor reală și de referință folosind formula III.4.1 din Mc001, adică
5. Completarea certificatului de performanță energetică al clădirii (CPE) (ANEXA 1);
6. Completarea anexelor la certificatul de performanță energetică al clădirii (anexa la CPE ș.a.) ANEXA 2.
Aceste etape sunt descrise de către schema logică de certificare energetică din figura 1. Notele de calcul privind consumurile anuale și specifice de energie împreună cu calculul notelor energetice pentru clădirea reală și cea de referință se înscriu în Raportul de Analiză și Certificare Energetică a clădirii.
1.9. Procedura de calcul a consumurilor anuale specifice
Informații generale ale clădirii
Informații privind construcția
Caracteristici geometrice și termotehnice ale anvelopei: lungime, lățime, înălțime
Tâmplărie exterioară : orientare, suprafata, rezistenta termica
Pereti exteriori opaci: orientare, suprafata, rezistenta termica corectata (m2K/W)
Regimul de ocupare pentru astfel de clădiri este fie continuu (cu furnizare continuă de energie pentru încălzire), fie intermitent (cu furnizare intermitentă de energie pentru încălzire). Modelul de calcul este simplificat în regim permanent, metoda de calcul aplicându-se pe întreaga perioada de încălzire.
(Brviar de calcul al performanței energetice a clădirilor, p. 18)
Caracteristici geometrice
În cadrul caracteristicilor geometrice se disting lungimi și înălțimi ale elementelor ce compun anvelopa, înălțimi de nivel, volumul clădirii conform Mc001/2007. Toate aceste arii și volume se determină fie din planurile de arhitectură (dacă acestea există) fie din măsurători efectuate în situ, respectând convențiile stabilite în Mc001-PI.
(Brviar de calcul al performanței energetice a clădirilor, p. 19)
Caracteristici termice
Parametrii de performanță caracteristici elementelor de anvelopă, necesari pentru evaluarea performanței energetice a clădirilor sunt :
– rezistențe termice unidirecționale (R) în [m2K/W], respectiv transmitanțe termice unidirecționale (U) în [W/ m2K];
– rezistențe termice corectate (R’) în [m2K/W], respectiv transmitanțe termice corectate (U’) în [W/ m2K] cu efectul punților termice; raportul dintre rezistența termică corectată și rezistența termică unidirecțională (r);
– rezistențe termice corectate, medii, pentru fiecare tip de element de construcție perimetral, pe ansamblul clădirii (R’m) în [m2K/W];
– rezistență termică corectată, medie, a anvelopei clădirii (R’M); respectiv transmitanță termică corectată, medie, a anvelopei clădirii (U’clădire) în [W/ m2K].
Valorile mărimilor menționate mai sus se determină conform părții I a Metodologiei Mc001.
(Brviar de calcul al performanței energetice a clădirilor, p. 19)
Parametrii climatici (θe, Ij); perioada de încălzire
Pentru clădiri rezidențiale/terțiare valorile de calcul ale temperaturii exterioare și intensității radiației solare se obțin prin medierea valorilor lunare pentru întreaga perioadă de încălzire. Perioada de încălzire se stabilește în funcție de temperatura de echilibru conform Mc001/2007.
(Brviar de calcul al performanței energetice a clădirilor, p. 19)
Temperaturi de calcul (θi, θiad)
Temperaturile interioare ale încăperilor încălzite (θi)
Se consideră conform reglementărilor tehnice în vigoare (Mc001/2007).
Dacă într-o clădire încăperile au temperaturi de calcul diferite (în limita a ±4oC), dar există o temperatură predominantă, în calcule se consideră această temperatură. Pentru clădirile de locuit se consideră θi = +20oC.
Dacă nu există o temperatură predominantă, temperatura interioară convențională de calcul se poate considera temperatura medie ponderată a tuturor încăperilor încălzite:
în care:
Aj este aria încăperii j în m2, având temperatura interioară θij în [°C] .
Temperatura interioară corectată θiad (în cazul clădirilor terțiare cu energie furnizată intermitent) pe perioada de încălzire
Acest parametru are o valoare constantă care conduce la aceleași pierderi termice ca și în cazul încălzirii cu intermitență pe perioada considerată. Pentru fiecare perioadă de încălzire redusă temperatura interioară corectată se calculează utilizând procedura definită în Mc001/2007.
Determinarea programului de funcționare (t)
În cazul utilizării încălzirii cu intermitență, programul de funcționare se împarte în intervale de încălzire normală alternând cu intervale de încălzire redusă (de exemplu nopți, sfârșituri de săptămână și vacanțe).
Pentru intervalele de încălzire normală se stabilește temperatura interioară convențională de calcul constantă.
Pentru perioadele de încălzire redusă pot fi programe de funcționare diferite. În acest caz consumurile de energie se vor calcula pentru fiecare tip de perioadă de încălzire.
Calculul pierderilor de energie ale clădirii (QL)
Pierderile de căldură, QL, ale unei clădiri mono-zonă, încălzită la o temperatură interioară uniformă, pentru o perioadă de calcul dată, sunt :
în care :
θi este temperatura interioară de calcul, conform indicațiilor de la paragraful III.1.3.4 în [°C];
θe – temperatura exterioară medie pe perioada de calcul conform indicațiilor de la paragraful
(Brviar de calcul al performanței energetice a clădirilor, p. 20)
t – durata perioadei de calcul în [h];
H – coeficientul de pierderi termice al clădirii în [W/K];
ΦL – fluxul termic pierdut de clădire, în [W].
Coeficientul de pierderi termice H, se calculează cu relația:
Coeficientul de pierderi termice prin transmisie HT:
unde:
L este coeficientul de cuplaj termic prin anvelopa clădirii, definit prin relația
L= ΣUjAj + Σψklk + Σχj , în [W/K] unde Uj este transmitanța termică e elementului de construcție j în [W/m2K], Aj este aria elementului de construcție j în [m2], ψk este coeficientul punților termice liniare k, lk este lungimea punții termice liniare k în [m] iar χj este coeficientul punților termice punctuale ale elementului de construcție j (conform Mc001/2007-PI);
Ls este coeficientul de cuplaj termic prin sol, (conform Mc001/2007-PI, în [W/K];
Hu este coeficientul de pierderi termice prin spații neîncălzite (conform Mc001/2007-PI,), în [W/K];
Hv este coeficientul de pierderi termice aferente debitului de aer pătruns în clădire, în [W/K].
Calculul aporturilor de căldură (Qg)
Aporturile totale de căldură ale unei clădiri sau încăperi/zone, Qg, reprezintă suma degajărilor interioare de căldură și aporturilor radiației solare:
Φg fiind fluxul termic al aporturilor totale de căldură, exprimat în [W].
Aporturile interioare de căldură, Qi, cuprind toată cantitatea de căldură generată în spațiul încălzit de sursele interioare, altele decât instalația de încălzire, ca de exemplu :
– degajări metabolice care provin de la ocupanți;
– degajări de căldură de la aparate și instalația de iluminat.
Necesarul de energie pentru încălzire (Qh)
Se detremină pentru fiecare perioadă de calcul/sezon cu relația:
Qh=QL – ηQg [kWh] (III.1.22)
unde pierderile termice, QL, și aporturile de căldură, Qg, se calculează de asemenea pentru fiecare perioadă de calcul/sezon.
(Brviar de calcul al performanței energetice a clădirilor, p. 21-22)
Pierderile de căldură ale instalației de încălzire (Qth)
Pierderile de energie ale instalației de încălzire țin cont de pierderile de energie ale sistemului de transmisie al căldurii Qem și de pierderile de energie ale sistemului de distribuție al căldurii:
Căldura recuperată de la instalația de încălzire (Qrhh)
Căldura recuperată de la instalația de încălzire este o parte a termenului Qth și se determină cu relația:
unde:
Qd,recuperat este căldura recuperată din pierderile sistemului de distribuție a agentului termic, calculată conform paragrafului III.1.3.11 pentru tronsoanele de conducte aflate în spații încălzite, în [kWh];
(Brviar de calcul al performanței energetice a clădirilor, p. 24)
Căldura recuperată de la instalația de apă caldă de consum (Qrhw)
Căldura recuperată de la instalația de apă caldă de consum se determină cu relația:
unde:
Qd,recuperat a.c.c. este căldura recuperată din pierderile sistemului de distribuție a apei calde de consum, calculată conform paragrafului III.3.3.4 pentru tronsoanele de conducte aflate în spații încălzite, în [kWh];
Consumul total de energie pentru încălzire clădirilor (Qfh)
Consumul total de energie pentru încălzire se obține din însumarea termenilor prezentați în paragrafele anterioare, respectiv:
Calculul consumurilor de energie pentru instalațiile de ventilare mecanică
mărimi de intrare :
(Brviar de calcul al performanței energetice a clădirilor, p. 26)
relatii de calcul :
mărimi de iesire :
(Brviar de calcul al performanței energetice a clădirilor, p. 32)
Procedura de calcul a consumului de energie pentru apă caldă pentru clădiri
(Brviar de calcul al performanței energetice a clădirilor, p. 62)
Instalații de iluminat
Pentru clădirile de locuit, se va opta pentru stabilirea unui consum mediu de energie electrică‚ în funcție de tipul apartamentului, conform tabel 4 din anexa II.4.A1 din Metodologia Mc001-PII.4.
Metoda de determinare a consumului de energie electrică pentru clădiri terțiare presupune calcule estimative și constă în aplicarea următoarelor relații de calcul:
iar
Pn- puterea instalată
td – timpul de utilizare al luminii de zi în funcție de tipul clădirii (anexa II.4.A1 din Metodologia Mc001-PII.4)
tn – timpul în care nu este utilizată lumina naturală (anexa II.4.A1 din Metodologia Mc001-PII.4)
Fd- factorul de dependență de lumina de zi (anexa II.4.A1 din Metodologia Mc001-PII.4) care depinde de sistemul de control al iluminatului din clădire și de tipul de clădire.
Fo – factorul de dependență de durata de utilizare (anexa II.4.A1 din Metodologia Mc001-PII.4)
A – aria totală a pardoselii folosite din clădire [m2].
(Brviar de calcul al performanței energetice a clădirilor, p. 73)
Calculul emisiilor de CO2
Emisia de CO2 se calculează similar cu energia primară utilizând un factor de transformare corespunzător:
ECO2 = Σ (Qf,i x f CO2,i+ ΣWh·x f CO2,i) – Σ(Qex,i x f CO2ex,i) [kg/an] (III.6.1)
unde fCO2, reprezintă factorul de emisie stabilit conform tabelelor I.1.13 și I.1.14 din Metodologia Mc001-PI.1.
(Brviar de calcul al performanței energetice a clădirilor, p. 74-46)
CAPITOLUL II – PROIECTAREA APLCAȚIEI INFORMATICE
2.1. Definirea obiectivelor aplicației informatice
Din punct de vedere al aplicării Metodologiei de calcul privind performanța energetică a clădirilor Mc001–2006 aplicația informatică va oferi posibilitațile:
calculul indicatorilor de performanță energetică a clădirilor;
calculul consumurilor de energie aferente tipurilor de instalații interioare care asigură confortul sau condițiile interioare de muncă;
întocmirea certificatului energetic al clădirilor, auditul energetic și analiza eficienței economice a soluțiilor de creștere a performanței energetice a clădirilor existente și instalațiilor aferente.
Pentru creșterea eficienței de calculare a performanței energetice a clpdirii aplicația ce urmează a fi proiectată și dezvoltată trebuie sa permită:
Încarcarea datelor de intrare cu privire la clădirea ce se dorește a fi certificată;
Regasirea datelor predefinite (temperaturi ale locației, factori, rezistențe termice ale materialelor) prezente în normativul de calcul MC001;
Configurare a listelor de materiale și coeficienții specifici auditării energetice;
Calcularea și afișarea consumurilor energetice specifice și totale;
Crearea “Certificatului de performanță energetică” și a anexelor aferente;
Crearea “Raportului de audit energetic”;
Imprimarea documentelor raportate;
Salvarea și regăsirea datelor introduse;
2.2. Fluxul general de prelucrare a datelor
Pentru a realiza un proiect de calcul sau audit a performanței energetice a clădirilor utilizatorul va trebui sa fie constrâns unei anumite ordini de introducere a datelor pentru ca acestea sa ofere un rezultat final corect. Dupa ce rezultatele au fost produse utilizatorul va avea posibilitatea de raportare a acestora și salvare în baza de date. Intregul flux de parcurgere a unui proiect se regăsește în figura 2.
Figura 2 – Fluxul general de prelucrare a datelor unui proiect de calcul a performanței energetice a clădirilor
2.3. Specificațiile de control și securitate a datelor
Controlul datelor de intrare
– Validarea datelor de tip numeric introduse de către utilizator;
– Validarea datelor necesare calculării datelor de ieșire;
– Stabilirea separatorului decimal;
Controlul rezultatelor
– Proceduri de calcul al volumurilor clădirii, rezistențelor termice;
– Proceduri de calcul al consumurilor energetice totale și specifice;
– Proceduri de calcul și incadrare a clasei energetice în funcție de consumurile energetice;
Protecția aplicației și a bazei de date
– Restricționarea posibilității de modificare a datelor “standard” furnizate de normativ MC001;
– Restricționarea accesului aplicației utilizatorilor ce nu fac parte din categoria “Auditori Energetici”;
2.4. Arhitectura aplicației informatice
Pentru îndeplinirea obiectivelor și a cerințelor aplicației informatice am stabilit ca aceasta se pretează cel mai bine unei arhitecturi fizicee “client – server” în care unitatea de calcul sa reprezinte ambele componente. Această arhitectură fizică se împarte la rândul ei în niveluri logice (figura 3) după cum urmează:
Client
– Nivelul de prezentare al aplicației: cuprinde interfața grafică cu utilizatorul prin intermediul careia datele sunt afisate, validate și acceptate;
– Nivelul de logică al aplicației: reprezintă componenta ce impune reguli de logică a aplicației, controlează fluxul aplicației, impune restricții asupra datelor pentru a le păstra consisența;
Server
– Nivelul de date: este componenta responsabilă de stocarea și interogarea datelor asupra SGBD și totodată cuprinde componente ce intermediază legatura cu nivelurile “Client” prin translatarea datelor;
Figura 3 – Subnivelurile arhitecturii client server
Vom structura proiectarea aplicației în trei etape:
Proiectarea bazei de date: crearea tabelelor necesare și a relașiilor dintre acestea; impunerea restricșiilor asupra anumitor tipuri de date; alegerea tehnologiei de acces la date;
Proiectarea logică: crearea claselor, obiectelor și a relașiilor dintre acestea ținând cont de schema bazei de date proiectate la punctul anterior;
Proiectarea interfeței grafice: crearea ferestrelor și a controalelor prin care utilizatorul va putea introduce datele în mod corect corespunzător tipurilor din definiția lor; crearea ferestrelor și a controalelor de afișare a datelor și rapoartelor; crearea componentelor de imprimare a datelor;
2.5. Proiectarea bazei de date
Baza de date în care se vor stoca informațiile din aplicația informatică va cuprinde doua categorii de tabele:
tabele de tip proiect – se vor regasi doar datele specifice fiecărui proiect, respectiv clădiri pentru care se analizează performanța energetică;
tabele de tip standard – se vor regăsi doar date predefinite furnizate de normativul de calcul MC001 și care sunt necesare în calcularea datelor de iesire;
Tabelul Proiect
Tabelul Judete
Tabelul Localitati
Tabelul DateGenerale
Tabelul CaracteristiciGeometrice
Tabelul CaracteristiciCladire
Tabelul Auditori
Tabelele Pereti, Plansee
Tabelele MaterialePereti, MaterialePlansee
Tabelele AnvelopaPereti, AnvelopaPlansee, AnvelopaFerestre
Tabelul Izolatii
Tabelul ConducteAcc
Tabele cu date standard:
Tabelul FactoriEmisieCO2
Tabelul StratAer
Tabelul TipuriFerestre
Tabelul ValoriNormateDeltaTiMax
Tabelul RezistenteMinime
Tabelul MaterialePredefinite
2.6. Proiectarea logică a aplicației informatice
În această etapă a proiectării se vor defini entitățile cu care se opereaza în calculul performanței energetice a clădirii. Aceste entități vor conține în mod special datele de intrare și metode de calcul a datelor de iesire. Entitățile și relațiile dintre acestea (figura 4) vor trebui proiectate corect respectând schema și tipurile de date cu care sunt asociate în baza de date.
Entitățile unui proiect de audit:
Entitati generale – configurabile:
Materiale pereți (denumire, rezistență termică, coeficient depreciere);
Materiale planșee (denumire, rezistență termică, coeficient depreciere);
Termo-izolații (denumire, rezistență termică);
Elemente vitrate predefinite (denumire, rezistență termică);
Definire pereți (denumire, materiale componente, grosime);
Definire planșee (denumire, materiale componente, grosime);
Definire elemente vitrate (denumire, materiale componente, grosime);
Definire soluții de izolații (denumire, materiale componente, grosime);
Caracteristici amplasament (judet, localitate, temperaturi anuale, indici radiație solară);
Definire prețuri combustibili (gaz natural, energie termică, energie electrică);
Auditori (nume, prenume, grad, specializare, serie și nr identificare);
Entitatea Proiect:
Această entitate este una globală alcatuită din subentități ce vor conține date specifice fiecărei componente din fluxul de reazliare a unui proiect de calcul.
Aceste subentităti sunt:
Date identificare proiect;
– date intrare/ieșire: denumire proiect, date contact, tip certificat, amplasament;
Caracteristici generale ale clădirii;
– date intrare/ieșire: anul construirii, temperatura medie interioară, tip clădire, număr apartamente, scop elaborare certificat, număr schimburi aer, coeficient acc referință, număr de utilizatori;
Caracteristici geometrice ale clădirii;
– date intrare: lungime, lățime, înălțime, înălțime nivel, suprafața locuită, suprafața încălzită, suprafața utilă;
– date ieșire: volumul clădirii, volumul încălzit;
Factori de penalizare;
– date intrare: penalizări acordate clădirilor;
– date ieșire: p0 = coeficient general de penalizare;
Factori conversie energie primară și emisie CO2;
– date intrare: factori conversie energie primară și emisii CO2 pentru încălizire, apă caldă menajeră, iluminat;
– date ieșire: calcul consumuri totale energie primară și emisii totale CO2;
Pachet anvelopa existentă;
– date intrare: definire pereți , plansee, elemente vitrate din care este alcătuită clădirea (suprafață, tip materiale folosite, orientare, Rsi, Rse, rezistența termiăa corectată, factor de temperatură);
– date iesire: rezistența termică totală, rezistența termică corectată totală;
Instalații iluminat;
– date intrare: tip camere, numar camere, suprafata;
– date iesire: suprafata iluminata, consumul total energie iluminare, consum energie iluminare specific;
Instalatii climatizare și ventilare;
– date intrare: tip echipament, putere, nr. echipamente, durata și perioada de funcționare;
– date ieșire: consumul total energie ventilare și climatizare, consum energie ventilare și climatizare specific;
Instalatie incalzire și apa calda menajera;
– date intrare: temperatură apă caldă, temperatură apă rece, număr utilizatori, stare instalație, perioadă de funcționare, caracteristicile conductelor de transport a agentului termic (lungime, diametru, rezistență termică, este caldura recuperată);
– date ieșire: temperatura medie de funcționare, consumul total de energie, consumul de energie recuperat, consumul de energie specific;
Pachet combinatii de soulutii;
– date intrare: solutii de izolatii;
– date iesire: rezistenta termica totala în urma aplicarii solutiilor;
Figura 4 – Relatiile dintre clase
Pe langă subentitățile componente, entitatea globală “Proiect” va conține și o serie de metode prin care se vor extratge rezultatele din subentități și se vor calcula datele de ieșire globale necesare în realizarea documentării proiectului de stabilire a performanței energetice.
Metode globale:
– calcul consum anual specific de energie: este alcătuit din suma consumurilor anuale specifice ale subentităților componente (încălzire, apă caldă de consum, iluminat, ventilare, climatizare);
– notarea energetică: se va face pe baza consumului anual specific;
– calcularea economiei de consumuri: diferența dintre consumurile după aplicarea soluțiilor de izolații și cele anterioare aplicării lor;
– indicatori economici orientativi: se va face pe baza economiei de consumuri, a prețurilor combustibililor și a materialelor;
2.7. Proiectarea interfeței grafice a aplicației
Dacă în nivelul logic al aplicației are loc transferul de date între nivelul de date și nivelul logic, nivelul de prezentare presupune expunerea acestora utilizatorului.
În această etapă se vor proiecta interfețele grafice cu utilizatorul ce vor permite atât introducerea datelor de intrare cât și afișarea celor calculate.
Aplicația va conține o fereastra principala de start (parinte) ce va compusa din doua zone:
zona de navigare – va conține butoane de tip meniu prin care se vor accesa celelalte componente vizuale ale aplicației; această zona de navigare va fi de asemena structurată pe cinci segmente:
zona manipulare proiect – butoane ce vor apela metodele de deschidere, salvare, ștergere, import și export al proiectelor;
zona date intrare:
– date proiect: date indentificare proiect, tip certificat, auditor;
– date clădire: caracteristici generale clădire, caracteristici geometrice, conversie energie primară și CO2, penalizări acordate clădirii;
– definire clădire: caracteristici anvelopă existentă, instalație incălzire și apă caldă de consum, instalație climatizare și ventilare, instalație de iluminat;
– definire izolații: definire soluții de izolații, combinații de soluții;
c. zona date ieșire:
– consumuri: calcul perioada de incalzire, calcul caracteristici termice combinat, aporturi energetice pentru incalzire, consumuri pentru incalzire/racire, consumuri pentru climatizare/ventilare, consumuri pentru iluminat, economie consumuri, indicatori economici;
– rapoarte: certificatul de performanta energetică; anexa la certificatul de performanta energetică, anexa recomanari, breviar de calcul, raport de audit energetic, memoriu calcul “G”;
d. zona de configurare a datelor “standard”:
– configurare amplasament, punți termice, note și observatii;
– pereți, planșee, elemente vitrate: definire materiale pereți, planșee, elemente vitrate;
e. zona de informații și schimbare a modului de afișare a interfeței
zona de lucru – spațiul în care se vor afișa ferestrele (copil) de editare a datelor pentru fiecare subcategorie a unui proiect, respectiv de afișare a rezultatului;
CAPITOLUL III – TEHNOLOGII UTILIZATE ÎN PROGRAMAREA APLICAȚIEI WINDOWS
3.1. Alegerea limbajului de programare
3.1.1. Platforma .NET și componentele acesteia
.NET este un cadru (Framework) de dezvoltare software unitar care permite realizarea, distribuirea și rularea aplicașiilor desktop Windows și aplicatiilor WEB.
Tehnologia .NET conține un pachet de mai multe tehnologii (ASP, XML, OOP, SOAP, WDSL, UDDI) ș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ă impreună cu sistemul de operare Windows. De fapt, .NET 2.0 vine cu Windows Server 2003, se poate instala pe versiunile anterioare, pana la Windows 98 inclusiv; .NET 3.0 vine instalat pe Windows Vista și poate fi instalat pe versiunile Windows XP cu SP2 și Windows Sever 2003 cu minimm SP1.
Pentru a dezvolta aplicații pe platforma .NET este bine să avem 3 componente esențiale:
– un set de limbaje (C#, Visual Basic, .NET, J#, Managed C++, Smaltalk, Perl, Fortran, Cobol, Lisp, Pascal, etc) ;
– un set de medii de dezvoltare (Visual Studio .NET, Visio);
– o biblioteca de clase pentru crearea serviciilor Web, aplicatiilor Web și aplicațiilor desktop Windows.
Tipul de aplicații ce pot fi realizate cu această platformă:
Console application (aplicații consola)
Windows forms application (aplicații windows)
ASP.NET applications (aplicații web)
XML web services (servicii web XML)
Windows services (servicii Windows)
SQL Server applications (aplicații baze de date SQL)
Small device applications (aplicații mobile)
(.NET Framework Essentials 2nd Edition, P7-8)
Legatura între platforma .NET și sistemul de operare este data de trei entități: CLR, CTS și CLS:
CLR – Common Language Runtime
Rolul principal al CLR-ului este de a localiza, încarca și gestiona tipurile de date .NET precum și a controla memoria, incarcarea assembly-urilor, verificări de securitate, sincronizarea firelor de execuție (Threads), tratarea excepțiilor. CLR-ul stă la baza tuturor programelor din .Net iar acesta nu “cunoaște” natura limbajului de programare folosit de programator în codul sursa. Se poate folosi orice limbaj de programare în scrierea codului atat timp cât compilarea acestuia este recunoscut de CLR.
CTS – Common Type System
Pentru a fi integrate în platforma .NET limbajele C#, VB.NET, C++ și J# trebuie să aibă în comun reguli de definire, expunere de tipuri și interacțiune între acestea pentru a putea fi corect interpretate de compilator. Toate aceste reguli reprezinta un “nomenclator” pentru clase, interfete, delegari, tipuri valoare și referință și sunt date de CTS (Common Type System). CTS-ul ne arata cum se definește un membru, o proprietate, un eveniment, o metodă. De asemenea CTS-ul specifică reguli de expunere a diferitelor tipuri (privat, public, internal, sealed). CTS este inclus în CLR.
CLS – Common Language Specification
Dacă în alte platforme este permisă comunicarea între obiecte scrise în limbaje de programare diferite în CLR s-a dorit integrarea mai multor limbaje de programare și tratarea codului scris într-un limbaj în mod egal cu cel scris în alt limbaj. Acest lucru este posibil prin CLS deoarece acesta conține un subset de tipuri comune și tipare de construcție ce pot fi recunoscute de restul limbajelor din CLR (figura 5). Pentru a ne asigura ca un cod scris într-ul limbaj este recunoscut de altul trebuie sa avem grija ca acel cod este CLS-compilant, altfel putem avea probleme la conversie.
Figura 5 – Relația dintre componentele platformei .Net
Rolul Base Class Library
Alaturi de cele trei entități (CLR, CTS, CLS) platforma .Net ne oferă și o librarie de clase de baza ce poate fi folosită de toate limbajele (figura 6). Aceasta conține numeroase componente pentru accesarea fișierelor I/O, consturirea thread-urilor, randarea sistemului grafic, legatura cu componente hardware, construirea de servicii WEB.
Figura 6 – Base Class Libraries
Compilarea programelor
Un program scris într-unul dintre limbajele .NET conform Common Language Specification (CLS) este compilat în Microsoft Intermediate Language (MSIL sau IL). Codul astfel obtinut are extensia "exe", dar nu este direct executabil, ci respecta formatul unic MSIL.
CLR include o mașina virtuală asemănătoare cu o masina 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șina adecvat și eficient. El recunoaște secvențele de cod pentru care s-a obținut deja codul masină adecvat, permițând reutilizarea acestuia făra recompilare, ceea ce face ca, pe parcursul rularii, aplicațiile .NET sa fie din ce în ce mai rapide.
Faptul ca programul IL produs de diferite 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 în altul. In plus, CLR se ocupă de gestionarea automată a memoriei (un mecanism implementat în platforma .NET cu scop de eliberare automata a zonelor de memorie asociate unor date devenite inutile – Garbage Collection).
Ca un element de portabilitate, trebuie spus ca .NET Framework este implementarea uni standard numit Common Language Infrastructure (http:://www.ecma-international.org/publications/standards/Ecma-335.htm), ceea ce permite rularea aplicațiilor .NET, în afara de Windows, și pe unele tipuri de Unix, Linux, Solaris, Mac OS X și alte sisteme de operare (http://www.mono-project.com/Main Page).
(CLR via C# 3rd Edition, p31-60)
3.1.2. Limbajul de programare C Sharp (#)
Deoarece platforma .NET vine ca o abatere radicală pentru tehnologiile anterioare Microsoft a creat un limbaj specific acestei platforme, C#. Limbajul C# a fost dezvoltat de o echipă restransă 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 asemanator din punct de vedere al sintaxei cu limbajul Java. C# este practic un hibrid între mai multe limbaje de programare. C# permite ca și Visual Basic definirea proprietăților făra metodele tradiționale ‘getter’ și ‘setter’, permite ca metodele sa primească un numar variabil de argumente (params) precum și ca C++ posibilitatea de a supraîncărca operatori, crearea de structuri, enumerări, funcții de tip “callback”. C# de asemenea ofera funcționalități întâlnite în limbajele LISP sau Haskell cum ar fi expresiile lambda (=>) sau tipurile anonime. Intr-un final componenta ce face din C# un limbaj unic este LINQ (Language Integrated Query).
În ciuda faptului ca C# este un hibrid, rezultatul este un limbaj de programare cu o sintaxa lizibilă ca a limbajului Java, este simplu ca Visual Basic, puternic și flexibil ca C++.
Trăsături ce diferențiază C# de restul limbajelor:
Nu neceistă pointeri. C# nu are nevoie de a manipula tipurile referință prin pointeri;
Automatic memory management prin intermediul componentei “Garbage collector”. C# nu suporta cuvantul cheie “delete”;
Mod mai simplu de a supraîncărca operatori
Sintaxa formală în definirea claselor, interfetelor, structurilor, enumerărilor și delegaților
(Pro C# 2010 and the .NET 4 Platform 5th Edition, p9-10);
.Net 2.0 (2005)
Abilitatea de a construi tipuri și membri generici. Utilizarea genericelor permite constuirea unor tipuri eficiente în condiții de siguranță (type-safe);
Suport pentru metode anonime (anonymous methods) ce permite definirea “locala” a unei metode ce ține sa înlocuiască un delegat;
Posibilitatea de a defini un singur tip de dată scris în fișiere de cod diferite (prin intermediul cuvântului cheie “partial”);
Numeroase simplificări în definirea de delegați/evenimente precum și introducerea de concepte precum covarianța și contravarianța;
.Net 3.5 (2008)
Operatorul lambda (=>) ce simplifică drastic lucrul cu tipurile de tip delegate;
LINQ – Language Integrater Query folosit pentru a opera cu diferite tipuri de date în mod asemanator limbajului SQL;
Extension methods permite extinderea funcționalității unui tip existent fară a modifica din codul clasei ce-l definește.
.Net 4.0 (2010)
Posibilitatea crearii de metode cu parametri optionali;
Posibilitatea definirii unei variabile de tip dynamic ce poate primi un sir de obiecte diferit ca tipuri;
.Net 4.5 (2012)
Suport pentru array-uri mai mari de 2Gb pentru platformele pe 64 bit;
Îmbunătățirea performanței garbage collector-ului; acesta va lucra în “background” pentru a elimina obiectele din memorie;
Îmbunătățirea compresiei ZIP;
Optimizarea metodelor asincrone prin cuvintele cheie async și await;
Abilitatea de a defini o cultură implicită pentru un AppDomain;
3.2. Alegerea modalitatii de stocare a datelor
Deseori aplicatiile Windows trebuie sa permita stocarea și regasirea datelor pe hard disk pentru a putea fi folosite ulterior astfel ca programatorul are de ales intre a stoca datele fie într-un fisier de date neorganizate sub un format specific (binar, xml) fie într-un mod structurat, tabelar unde datele sunt organizate iar controlul asupra lor este net superior. Evident, pentru stocarea datelor din aplicație, se va alege o baza de date și anume SQL Server.
Sql Server are ca și concurenta atat produse din aceeasi companie cum ar fi Microsoft Access sau Microsoft Visual FoxPro cat și din alte companii competitoare cum ar fi Oracle, Sybase, DB2 și Informix. Microsoft Access este cel mai des intalnit pe calculatoarele Windows deoarece acesta vine impreuna cu pachetul Office. Acesta se preteaza aplicatiilor ce lucreaza cu dimensiuni mici de date. Din pacate acesta este limitat atunci cand vine vorba de scalabilitate, viteza și flexibilitate astfel ca nu este recomandat a fi folosit în aplicatii cu cerinte mari în functionalitatea bazei de date de accea Microsoft Acces nu reprezinta o amenintare.
Competitia serioasa este data de Oracle și Sybase. Oracle este vazut ca și lider de piata în baze de date. Nu este negat faptul ca Oracle vine cu o puternica baza de date insa instalarea și administrarea este una mult mai complexa decat ale SQL Server. Oracle se preteaza foarte bine atunci cand se cere scalabilitate, performanta și flexibilitate deoarece acesta permite alegerea insturmentelor în functie de necesitati. De exemplu SQL Server 2008 forteaza a fi instalat .NET Framework pe server chiar daca nu se foloseste componenta .NET. Totodata Oracle nu este user friendly din punct de vedere a unui dezvoltator cand vine vorba de operatii cu XML și functionalitati Web.
Sybase este mult mai asemanator SQL Server-ului insa are dezavantajul major de a nu avea un GUI (Graphic User Interface) astfel ca programatorul trebuie sa detina puternice cunostinte de a opera datele folosid cod. Sybase este des inalnit impreuna cu sitemele Unix.
Asadar SQL Server este alegerea potrivita datorita numeroaselor facilitati cand vine vorba de analiza și raportarea datelor de catre utilizator sau marile companii. Este usor de instalat și intretinut, nu costa la fel de mult ca Oracle sau Sybase și are abilitati de manipulare a datelor de dimensiuni mari (terabytes).
3.2.1. SQL Server 2008
SQL (Structured Query Language) este un libaj standard specific destinat crearii și manipularii bazelor de date. Exista diferite tipuri și libaje de baze de date, fiecare adoptand conceptul propriu. SQL a fost initial dezvoltat pentru a opera cu baze de date relationale. Mai mult de atat, de curand, SQL este capabil sa opereze baze de date relationale-obiect.
SQL Server 2008 reprezinta o multi-componenta relationala ce are la baza limbajul SQL al carui motor de gestiune al bazelor de date are o performanta ridicata (figura 7). SQL Server opereaza cu mari cantitati de date și peste limbarjul de gestiune el cuprinde o serie de instrumente apropiate utilizatorului ce usureaza proiectarea și mentenanta bazei de date. Se pot crea și edita tabele prin intermediul unei interfete Windows, nu tip consola, se pot genera rapoarte, grafice, export-import de date, salvare-restaurare date periodic, etc. Deoarece SQL Server este un program de tip client-server, pentru functionare acesta trebuie instalat atat pe calculatorul unde se regasesc datele cat și pe cel care le acceseaza.
(Beginning SQL Server 2008 for Developers, p2-10)
Figura 7 – Funcționalitățile SQL Server 2008
3.3. Alegerea mediului de dezvoltare a aplicației.
Deoarece s-a ales ca limbaj de programare C# iar ca stocare a datelor SQL Server 2008 cel mai potrivit IDE (Integrated Development Environment) este Visual Studio 2010.
Visual Studio 2010 este un mediu integrat de dezvoltare (IDE) ce oferă unelte avansate de implementare, facilități de depanare, ușurință în lucrul cu bazele de date și o mulțime de resurse pentru realizarea rapidă de aplicații inovatoare Windows, Web și peste platforma .NET.
Visual Studio 2010 impresionează cu o interfața bazată pe WPF (Windows Presentation Foundation), așadar user-friendly și foarte atractivă vizual, utilizând culori dominante și un background distinctiv pentru a focaliza atenția asupra unei anumite ferestre de lucru.
Compatibilitate cu noile trenduri în materie de dezvoltare de aplicații
Multi-core development: Scrierea de cod optimizat rulează pe mai mult de un procesor, datorită lui Visual Studio IDE support for parallel development, precum și lui Native C++ libraries and compiler support for parallel applications.
Cloud development: Ne îndreptăm spre o mutare a conținutului și a programelor din offline spre online, iar VS2010 ne pune la dispoziție în acest sens Windows Azure Tools, realizând transferul aplicațiilor către „nor” prin intermediul Live Developer Portal.
Facilitățile oferite de Visual Studio 2010
WPF:
Visual Studio suportă dockingul documentelor pe mai multe monitoare (multi-monitor support). O altă facilitate este TDD (Test-Driven Development), un mecanism de testare prin care se pot depista mai ușor și sigur erorile în cod. Document Map Margin oferă o vizualizare grafică a fișierului sursă, cu informații despre cod.
Call Hierarchy reprezintă un browser de apeluri îmbunătățit, care afișează ce funcții sunt apelate dîntr-o funcție, respectiv din ce funcții e apelată o funcție, permițând în același timp o navigare ușoară între funcțiile apelate și apelante.
C++ development:
Biblioteca MFC oferă suport pentru facilități specifice Windows începând cu Vista: Task Dialog, Restart Manager sau Parallel Pattern Library.
Web development:
Un nou set de unelte ASP.NET (versiunea 4.0) ajută programatorii să folosească TDD pentru a dezvolta situri bazate pe patternul MVC (Model-View-Controller). Sunt incluse Project Templates and Solutions „out of the box” pentru un site MVC, generare automată de proiecte-test, wizards pentru taskuri uzuale precum creare de view-uri pornind de la controller etc. Prezintă suport pentru JavaScript și jQuery, unelte pentru Silverlight 2 și multe altele.
CAPITOLUL IV – DEZVOLTARE ȘI IMPLEMENTAREA APLICAȚIEI INFORMATICE
4.1. Etapele dezvoltării aplicației TermoExpert
Pentru a începe dezvoltarea aplicației TermoExpert bazată pe arhitectura pe trei nivele vom respecta următoarea ordine:
Business Logic Layer – această componentă implementează funcționalitatea aplicației. În această etapă vom defini conceptele asupra proceselor aplicației, entități și interfețe;
Presentation Layer sau Interfața cu utilizatorul – GDI (Graphic User Interface) –aceasta cuprinde o serie de componente vizuale prin intermediul cărora utilizatorul interacționează cu datele din aplicație;
Data Access Layer – această componentă este responsabilă de expunerea datelor din baza de date catre “Layer-ul de Bussines” și invers. Practic această componentă este responsabilă de transferul datelor între aplicație și baza de date.
Relația între aceste componente este afișată in figura 8.
Figura 8 – Modelul arhitecturii aplicației TermoExpert
4.2. Crearea și organizara fișierelor aplicației în Visual Studio 2010
Pentru o bună organizare a fișierelor ce conțin diferite tipuri de obiecte se vor crea documente (foldere) destinate fiecărei componente cu rol de a separa între ele fișierele în care sunt definite clasele entităților, interfețele grafice, accesul la baza de date, enumerările (figura 9). Acest lucru este foarte avantajos din punct de vedere al organizării datelor. Trebuie avut grijă ca odata cu adaugarea/mutarea unor clase într-un anumit folder sa fie schimbat și namespace-ul clasei, alfel ea este referintă tot în locul în care se afla anterior mutării.
Figura 9 – Organizarea claselor în cadrul proiectului
4.3. Dezvoltarea etapei de logică a aplicației (Business Logic Layer)
Pentru ca datele stocate în baza de date se fie accesibile utilizatorului într-un timp scurt acestea vor trebui mai intai preluate și încarcate în memoria sistemului de calcul. Acest lucru se poate realiza folosind clase și obiecte. Pentru popularea, ulterioara, corecta a instanțelor entităților (claselor) trebuie ca acestea sa fie proiectate respectând schema structurii datelor și a relațiilor dintre acestea din baza de date (figura 10).
Figura 10 – Relați între clasele unui proiect
Pe langă construirea entităților și a relațiilor dintre acestea, nivelul de logică al aplicației va trebui sa conțină și o serie de metode de prelucrare și transfer a datelor.
Se vor construi metode pentru:
încarcarea /salvarea datelor în/ din aplicație în/din baza de date;
calculare a datelor de ieșire, care la randul lor pot fi:
– private: calcule la nivel de entitate copil (ex: calcularea perimetrului, volumului clădirii, volumului încălzit se vor calcula la nivelul entității “CaracteristiciGeometrice”);
– globale: calcule la nivel de entitate parinte (ex: rezistența anvelopei clădirii este alcatuită din suma raporturilor arie/rezistență din fiecare entitate “Perete”, “Planseu”, “Element vitrat”);
restricții asupra accesului în aplicație;
verificarea îndeplinirii cerințelor de pornire a aplicației;
metode pentru transferul datelor intre memorie și interfața cu utilizatorul;
4.3.1. Crearea claselor unui proiect de audit
În acest punct vom exemplifica crearea unor entități din cadrul unui proiect:
Date identificare proiect
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace TermoExpert.ProjectClasses
{
public class DateIdentificareProiect
{
public string Cod { get; set; }
public string Denumire { get; set; }
public string Adresa { get; set; }
public string NumeBeneficiar { get; set; }
public string AdresaBeneficiar { get; set; }
public string TelefonBeneficiar { get; set; }
public string FaxBeneficiar { get; set; }
public string EmailBeneficiar { get; set; }
public string ProiectantGeneral { get; set; }
public string ProiectantSpecialitate { get; set; }
}
}
Caracteristici geometrice
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace TermoExpert.ProjectClasses
{
public class CaracteristiciGeometrice
{
//date intrare
public decimal Lungime { get; set; }
public decimal Latime { get; set; }
public decimal Inaltime { get; set; }
public decimal InaltimeNivel { get; set; }
public string RegimInaltime { get; set; }
public decimal SuprafataConstruita { get; set; }
public decimal SuprafataDesfasurata { get; set; }
public decimal SuprafataLocuita { get; set; }
public decimal SuprafataIncalzita { get; set; }
public decimal SuprafataUtila { get; set; } }
//date iesire
public decimal VolumulCladirii
{
get
{
return this.Lungime * this.Latime * this.Inaltime;
}
}
public decimal VolumulIncalzit
{
get
{
return this.InaltimeNivel * this.SuprafataIncalzita;
}
}
}
Clasa proiect
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace TermoExpert.ProjectClasses
{
public class Project
{
//1-Cladire, 2-Apartament
//date intrare
public int TipCertificat { get; set; }
public DateIdentificareProiect DateProiect { get; set; }
public CaracteristiciGeometrice CaracteristiciGeometrice { get; set; }
public AnvelopaPerete[] AnvelopaPereti { get; set; }
public AnvelopaPlanseuSuperior[] AnvelopaPlanseeSuperioare { get; set; }
public AnvelopaPlanseuInferior[] AnvelopaPlanseeInferioare { get; set; }
public AnvelopaFereastra[] AnvelopaFerestre { get; set; }
public FactoriEmisie[] FactoriEmisie { get; set; }
….
//constructor
public Project()
{
this.TipCertificat = 1;
this.DateProiect = new DateIdentificareProiect();
this.CaracteristiciGeometrice = new CaracteristiciGeometrice();
}
//date iesire
public decimal GetRezistentaTotala()
{
decimal sum = 0;
if (this.AnvelopaPereti != null)
{
sum += this.AnvelopaPereti.Select(p => p.R).Sum();
}
if (this.AnvelopaPlanseeSuperioare != null)
{
sum += this.AnvelopaPlanseeSuperioare.Select(p => p.R).Sum();
}
if (this.AnvelopaPlanseeInferioare != null)
{
sum += this.AnvelopaPlanseeInferioare.Select(p => p.R).Sum();
}
if (this.AnvelopaFerestre != null)
{
sum += this.AnvelopaFerestre.Select(p => p.R).Sum();
}
return sum;
}
}
…..
}
4.3.2. Proprietăți automat-implementate
Începand cu C# 3.0 s-a introdus o noua posibilitate de a defini proprietățile din catrul unei clase și anume se pot introduce fara a mai implementa explicit metodele getter și setter. Implementarea metodelor get/set vor fi facute automat de către compilator (figura 11). Personal consider această facilitate foarte utilă atunci când folosim proprietăți simple ce nu necesită logică la citire sau scriere și pentru a avea o clasa cu un cod mai “curat” din punct de vedere sintactic.
Figura 11 – Definirea proprietăților în .Net 4.0
4.3.3. Alegerea tipurilor de date
Pentru definirea membilor unei entități trebuie să analizăm dacă acestea vor fi suportate ulterior de către baza de date în care acestea vor fi stocate. De exemplu trebuie sa hotărâm cum vom stoca elementele unei enumerări, fie sub forma de caractere, fie sub forma unui numar de tip int ce reprezintă poziția elementului în enumerare.
Un alt aspect important este alegerea tipului de dată pentru numerele decimale (float sau decimal). Principalul avantaj al tipului de date decimal este acuratețea, astfel încât dacă avem de efectuat calcule precise acesta trebuie sa fie tipul de data ales. Tipul float are atuu-ul de a fi rapid (chiar de 20 de ori mai rapid) acesta pretându-se cel mai bine calculelor unde se dorește răspuns rapid.
În dezvoltarea aplicației TermoExpert s-au folosit patru tipuri de date principale:
– int – pentru numere întregi;
– string – pentru șiruri de caractere;
– decimal – pentru numere decimale;
– bool – pentru valori binare (0,1), respectiv (false, true);
În figura 12 se regăsesc principalele tipuri de date oferite de limbajul de programare C#.
Figura 12 – Tipuri de date în .Net 4.0
4.3.4. Inițializarea datelor
Exista două categorii de date definite în CLR (figura 13):
– value types – alocate pe stiva de execuție (thread stack)
– reference types – alocate în managed heap, referință către acestea find data de operatorul new.
În cadrul unei clase membri de tip value types sunt automat inițializate cu valori implicite astfel: int = 0, bool = false, decimal = 0;
Toți membri din categoria reference types (string, object) nu vor fi automat inițializați astfel că în cazul unui apel asupra lor se va lansa exceptie de tip NullReferenceException.
Deoarece toate clasele (tipurile) deriva din System.Object și anume:
public class CaracteristiciGeometrice { } este acelasi lucru cu
public class CaracteristiciGeometrice : System.Object { }.
Pentru a nu intampina probleme în accesarea tipului CaracteristiciGeometrice în cadrul clasei Proiect aceasta trebuie inițializată.
Inițializarea unui tip de date se poate face în mai multe feluri: în locul unde este definit sau în constructorul clase.
Figura 13 – Tipuri valoare, tipuri referinta
public Project()
{
this.TipCertificat = 1;
this.DateProiect = new DateIdentificareProiect();
this.CaracteristiciGeometrice = new CaracteristiciGeometrice();
}
4.4. Construirea interfeței cu utilizatorul (Presentation layer)
Încă de la apariția platformei .Net librăria cu clase de bază include un API (Application Programming Interface) numit Windows Forms. Acesta se regăsește în assembly-ul System.Windows.Forms.dll și conține o multitudine de tipuri (clase) cu ajutorur cărora pot fi create și controlate interfețe grafice (GUI) (tabele, casete text, butoane, etc.). În paralel cu acestea API-ul .Net cuprinde și assembly-ul System.Drawing.dll numit și GDI+. Cu ajutorul acestuia utilizatorul poate crea grafice 2D, imagini.
De la aparitia .Net 3.0 cei de la Microsoft se pot lăuda cu un nou pachet de controale pentru GDI denumit WPF(Windows Presentation Foundation) cu ajutorul căruia se pot crea interfețe grafice ce pot conține efecte de culoare, animații, etc. Multe dintre controalele oferite de Microsoft nu au satisfacut cerințele piețelor acestea având posibilități limitate de folosire în anumite scenarii. Pentru un pachet mult mai complex de controale (WinForms, Asp.Net, etc.) se pot accesa o serie de librării oferite de DevExpress.
Aplicația TermoExpert nu trebuie să impresioneze din punct de vedere grafic, ci trebuie să ofere rezultate corecte în urma calculelor astfel că în proiectarea intefeței se va folosi componenta implicita a Visual Studio 2010, Windows Forms.
4.3.1. Fereastra principală
Fereastra principală în aplicația TermoExpert este alcatuită dîntr-o clasă de tip Form și care a fost impărțită în trei zone: zona meniu, zona de lucru, zona de status.
zona meniu – cuprinde două controale de tip menu strip și tool strip cu ajutorul cărora se pot accesa celelalte ferestre ale aplicației (figura 14);
Zona meniu conține:
Gestiune a proiectelor: nou, deschide, ștergere, ștergere multiplă, import-export,exit;
Date proiect: date identificare proiect, alegerea auditorului și a tipului de certificat;
Data cladire: caracteristici geometrice, date generale clădire, factori penalizare, coeficienți energie primară și emisie CO2;
Materiale: liste de materiale, izolații, elemente vitrate;
Elemente de anvelopă: liste cu pereți alcatuiti din materialele de la sectiunea “Materiale”;
Definire clădire: caracteristica anvelopei existente, date intrare acc, încălzire, iluminat, ventilare, climatizare;
Soluții izolații: construire și alegere a soluțiilor de izolații ce se doresc a se aplica clădirii existente;
Consumuri: toatlitatea datelor de ieșire din proiect;
Rapoarte: previzualizare și printare CE, breviar de calcul, raport de auditș
Date standard: modificare date coeficenți depreciere, localități, punți termice;
Vizualizare: afișare/ascundere bară de instrumente;
Ferestre: modul în care sunt vizualizate form-urile deschise;
Ajutor: informații ajutătoare pentru folosirea programului;
zona de lucru – cuprinde un control de tip panel unde se vor afisa ferestrele din cadrul aplicației și se vor putea efectua diferite feluri de aranjamente ale acestora;
zona de status – cuprinde doua controale de tip status strip și group box ce vor contine informatii legate de starea proiectului
Figura 14 – Meniul principal al aplicației TermoExpert
4.3.2. Fereastra Caracteristici geometrice
Ce se află în față
Lansarea ferestrei se va face din forma principală din categoria Date cladire -> Caracteristici geometrice (figura 15). În urma lansării se va afișa forma din figura 16.
Figura 15 – Accesarea caracteristicilor geometrice din meniul aplicației
Figura 16 – Fereastra “Caracteristici geometrice”
Ce se află în spate
Inițializarea și afișarea formei “Caracteristici geometrice” se va face în forma principală atunci când va fi lansat evenimentul “Click” asupra butonului din meniu.
private void caracteristiciGeometriceToolStripMenuItem_Click(object sender, EventArgs e)
{
this.MainPresenter.ShowCaracteristiciGeometriceForm();
}
public class MainPresenter
{
public void ShowCaracteristiciGeometriceForm()
{
using (CaracteristiciGeometriceForm frm = new CaracteristiciGeometriceForm())
{
frm.Caracteristici = this.Proiect.CaracteristiciGeometrice;
if (frm.ShowDialog() == DialogResult.OK)
{
this.Proiect.CaracteristiciGeometrice = frm.Caracteristici;
};
Deoarece eliberarea memoriei este non-deterministică aceasta avand loc oricând CLR-ul va decinde să colecteze prin “GarbageCollector” este recomandabil ca resursele limitate (memoria) să fie eliberate cât mai repede posibil. Acest lucru se poate realiza folosind declarația “using” și astfel ne asigurăm ca după executarea codului din corpul acesteia memoria ocupată de controlul definit va fi eliberată obligatoriu, însă doar dacă acel obiect definiția “using” implementează metoda dată de interfața “IDisposable” în care este definit felul cu care memoria se eliberează. În cazul nostru tipul ”Form” are la bază tipul “Control” iar acesta conține implementarea interfeței IDisposable.
public class Control : Component, IDropTarget, ISynchronizeInvoke, IWin32Window, IBindableComponent, IComponent, IDisposable
Afișarea unei forme se poate face prin metodele Show() sau ShowDialog(). Diferența între acestea constă în faptul că metoda ShowDialog() oprește execuția codului pe stivă și asteaptă răspuns det tip DialogResult din partea formei care o afișează. Dacă am fi afișat forma prin metoda Show() codul de pe stivă și totodată din corpul metodei declarației using nu ar fi fost oprit din execuție iar forma ar fi fost “distrusă” imediat după afișare iar utilizatorul nu ar fi perceput afișarea acesteia.
Pe langă afișarea formei de ”Caracteristici geometrice” trebuie trimise și colectate date către și din aceasta. Acest lucru se va face prin definirea proprietății Caracteristici. Practic forma principala va intermedia legatura dintre Proiect și forma de ”Caracteristici”. Afișarea și preluarea datelor către și din controalele formei se va face prin intermediul metodelor PushToUI() care primeste ca parametru o entitate de tip ”CaracteristiciGeometrice” și va afișa fiecare membru în controlul corespunzător, respectiv PullFromUI() care va returna o nouă entitate de tip ”CaracteristiciGeometrice” a căror membri vori fi inițializați cu valori colectate din controalele aflate pe interfață.
Deoarece tipurile de date folosite în calculul ”Caracteristicilor geometrice” sunt de tip decimal am folosit controale de tip NumericUpDown astfel asigurându-mă ca utilizatorul nu va introduce caractere invalide (litere, simboluri) sau caractere ce țin de cultura aplicației cum ar fi separatorului decimal sau separatorul de “mii”, acesta fiind diferit interpretate de fiecare CultureInfo (cultura aplicației).
namespace TermoExpert.Views.DateCladire
{
public partial class CaracteristiciGeometriceForm : Form, IOperations<CaracteristiciGeometrice>
{
public CaracteristiciGeometrice Caracteristici
{
get { return this.PullFromUI(); }
set { this.PushToUI(value); }
}
public CaracteristiciGeometriceForm()
{
this.InitializeComponent();
}
public void PushToUI(CaracteristiciGeometrice item)
{
this.lungimeNumericUpDown.Value = item.Lungime;
this.latimeNumericUpDown.Value = item.Latime;
this.inaltimeNumericUpDown.Value = item.Inaltime;
this.inaltimeNivelNumericUpDown.Value = item.InaltimeNivel;
this.regimInaltimeTextBox.Text = item.RegimInaltime;
this.suprafataConstrtuitaNumericUpDown.Value = item.SuprafataConstruita;
this.suprafataDesfasurataNumericUpDown.Value = item.SuprafataDesfasurata;
this.suprafataLocuitaNumericUpDown.Value = item.SuprafataLocuita;
this.suprafataIncalzitaNumericUpDown.Value = item.SuprafataIncalzita;
this.suprafataUtilaNumericUpDown.Value = item.SuprafataUtila;
}
public CaracteristiciGeometrice PullFromUI()
{
return new CaracteristiciGeometrice()
{
Lungime = this.lungimeNumericUpDown.Value,
Latime = this.latimeNumericUpDown.Value,
Inaltime = this.inaltimeNumericUpDown.Value,
InaltimeNivel = this.inaltimeNivelNumericUpDown.Value,
RegimInaltime = this.regimInaltimeTextBox.Text,
SuprafataConstruita = this.suprafataConstrtuitaNumericUpDown.Value,
SuprafataDesfasurata = this.suprafataDesfasurataNumericUpDown.Value,
SuprafataLocuita = this.suprafataLocuitaNumericUpDown.Value,
SuprafataIncalzita = this.suprafataIncalzitaNumericUpDown.Value,
SuprafataUtila = this.suprafataUtilaNumericUpDown.Value
};
}
private void okButton_Click(object sender, EventArgs e)
{
this.DialogResult = System.Windows.Forms.DialogResult.OK;
}
private void cancelButton_Click(object sender, EventArgs e)
{
this.DialogResult = System.Windows.Forms.DialogResult.Cancel;
}
4.3.2. Legătura între un obiect și proprietatea unui control
Dacă se dorește ca proprietatea un anumit control să se schimbe în funcție de o valoare, respectiv valoarea să se schimbe în funcție de proprietatea unui control libraria .Net conține o componentă numita ”DataBinding”. Prin intermediul acesteia se poate crea o legatură automat-sincronizată între Presenation Layer (UI) și Business Layer în condițiile în care proprietatea controlului de pe UI este de acelasi tip cu sursa de date pe care o refera.
Exemplu de DataBinding cu un control de tip CheckBox:
this.checkBox1.DataBindings.Add("Checked", this.Caracteristici, "IsAuto");
Astfel la acționarea bifei de pe controlul CheckBox automat proprietatea Checked va fi modificată prin urmare și valoarea membrului IsAuto (bool) din clasa CaracteristiciGeometrice va fi schimbat în acceași valoare. Altfel acest lucru ar fi fost posibil prin scriere de cod atât la afișarea formei pentru a determina starea membrului IsAuto cât și prin implementarea event-ului CheckedChanged din controlul de tip CheckBox care anunță că starea acestuia a fost schimbată.
4.3.3. Generice și moștenirea vizuală
Deoarece în aplicație TermoExpert înalnim mai multe interfețe grafice (forme) care implementează aceleași funcționalități (afișează, adaugă, modifică, șterge) diferind doar prin tipul de entitate cu care ele operează s-a construit o forma de tip “șablon” ce va sta la baza formelor cu aceste funcționalități similare. Astfel codul scris va fi redus semnificativ, ferestrele grafice derivate din acest șablon conținând doar câteva metode personalizate de afișare și extragere a datelor.
Crearea formei sablon:
namespace TermoExpert.Templates
{
public partial class SingleEntityTemplateForm<T> : Form where T : class, ICopy<T>
{
public List<T> Items { get; set; }
public bool IsNew { get; set; }
public SplitContainer SplitContainer { get; set; }
public DataGridView GenericDataGridView { get; set; }
public BindingSource GenericBindingSource { get; set; }
public EventHandler LoadForm { get; set; }
public EventHandler AddClick { get; set; }
public EventHandler EditClick { get; set; }
public EventHandler DeleteClick { get; set; }
…
public SingleEntityTemplateForm()
{
InitializeComponent();
this.SetEvents();
}
private void DefaultControlsProperties()
{
if (this.GenericDataGridView != null)
{
this.GenericDataGridView.AllowUserToAddRows = false;
this.GenericDataGridView.AllowUserToDeleteRows = false;
this.GenericDataGridView.SelectionMode = DataGridViewSelectionMode.FullRowSelect;
}
}
private void SetEvents()
{
this.LoadForm += new EventHandler(Template_Load);
this.AddClick += new EventHandler(this.Add_Click);
this.EditClick += new EventHandler(this.Modify_Click);
this.DeleteClick += new EventHandler(this.Delete_Click);
…
}
public virtual T PullFromUI() { throw new NotImplementedException(); }
public virtual T GetNewItem() { throw new NotImplementedException(); }
public virtual T GetSelectedItem() { throw new NotImplementedException(); }
public virtual void PushToUI(T item) { throw new NotImplementedException(); }
private void AddOrUpdate()
{
this.ShowEditorControls();
if (this.IsNew)
{
var item = this.GetNewItem();
if (item != null)
{
this.PushToUI(item);
}
}
else
{
var selectedItem = this.GetSelectedItem();
if (selectedItem != null)
{
this.PushToUI(selectedItem);
}
}
}
….
Genericele reprezintă o funcționalitate oferită de CLR și limbajul de programare prin care utilizatorului i se permite reutilizarea codului. Practic utilizatorul își poate crea un algoritm de sortare, comparare, etc. care poate fi aplicat în mod general pentru mai multe tipuri de date ce respectă anumite criterii, nu doar asupra unuia specific.
În cazul nostru se dorește aplicarea unui algoritm de afșsare, adăugare, modificare, ștergere în mod identic indiferent de tipul de data cu care se oparează (material, termo-izolație, element vitrat). Încă din definiția clasei de baza forțăm ca entitatea de tip <T> cu care se operează sa fie de tip class și interfață ICopy , a carei implementare tratează modul in care sunt copiați membri intre două clase de același tip.
public partial class SingleEntityTemplateForm<T> : Form where T : class, ICopy<T>
Definirea evenimentelor principale:
public EventHandler LoadForm { get; set; }
public EventHandler AddClick { get; set; }
public EventHandler EditClick { get; set; }
public EventHandler DeleteClick { get; set; }
public EventHandler AcceptClick { get; set; }
public EventHandler CancelAddClick { get; set; }
public EventHandler OkClick { get; set; }
public EventHandler CancelClick { get; set; }
Evenimentele operațiilor vor fi referite de către formele derivate, acestea din urma nemaifiind nevoite sa implementeze metode corespunzătoare acțiunii pe care utilizatorul o alege.
Metode virtuale:
public virtual T PullFromUI() { throw new NotImplementedException(); }
public virtual T GetNewItem() { throw new NotImplementedException(); }
public virtual T GetSelectedItem() { throw new NotImplementedException(); }
public virtual void PushToUI(T item) { throw new NotImplementedException(); }
Deoarece în forma șablon funcționalitățile de afișare, adăugare, modificare și ștergere vor trebui sa funcționeze indiferent de tipul de entitate acestea necesită metode prin care se va face schimbul de informații cu formele derivate. Aceste informații vor fi furnizate de formele derivate prin supradefinirea metodelor de mai sus.
Exemplu din forma de “Materiale”:
public override void PushToUI(MaterialDefinit item)
{
this.denumireTextBox.Text = item.Denumire;
this.valoareNumericUpDown.Value = item.Valoare;
}
public override MaterialDefinit PullFromUI()
{
return new MaterialDefinit()
{
Denumire = this.denumireTextBox.Text,
Valoare = this.valoareNumericUpDown.Value
};
}
Exemplu de adăugare/modificare element generic:
public void AcceptItem()
{
if (this.IsNew == false)
{
this.PullFromUI().CopyTo(this.GetSelectedItem());
}
else
{
var item = this.PullFromUI();
this.Items.Add(item);
}
this.HideEditorControls();
this.RefreshBinding();
}
Se observă că în clasa șablon se operează cu metodele virtuale a căror implementare lipseste deoarece ea se află in formularul derivat. Daca în formele derivate nu ar fi fost supradefinite aceste metode atunci am fi întalnit excepții de tip NotImplementedException. Operatiile de mai sus sunt posibile deoarece this.Items reprezinta o lista (List<T>) cu obiecte de tip <T> iar metoda PullFromUI() returneaza în implementarea ei tot o entitate de tip <T>.
4.3.4. Constuirea rapoartelor cu Microsoft Reports
Microsoft Report este un generator de rapoarte inclus în Framework-ul .NET. El poate funcționa și ca aplicație de sine stătătoare. Pentru adăugarea unui raport de tip Microsoft Reports (figura 17) se optează pentru Add/ New Item din fereastra Solution Explorer iar din meniul Reporting se alege raportul dorit. Acest tip de rapoarte poate fi proiectat să afișeze atât date “statice” cât și “dinamice” prin crearea de legături cu seturi de date sau transmise ca parametru într-un șablon definit. Microsoft Reports deține o gamă largă de modele de afișare prin schimbarea aranjamentului și culorilor, si totodată avantajul particularizării pentru fiecare pagina a Header-ului, Conținutului și Subsolului.
Figura 17 – Microsoft Report
4.4. Realizarea accesului la date cu Ado.Net (Data Access Layer)
ADO.NET este o componentă a Framework-ului .NET ce face conexiunea între aplicație și sursele de date permițânt extragerea și salvarea datelor. ADO .NET suportă diferite tipuri de surse de date incluzând și cele bazate pe un moedel relațional cum ar fi: Microsoft SQL Server, Oracle, MS Access, MS Excel, Outlook și fișierele text.
Bibliotecile Ado.Net pot fi utilizate în trei maniere conceptuale unice: ConnectedLayer, DisconnectedLayer și EntityFramework.
Prima categorie denumita ConnectedLayer are mai multe componente majore ce au rol de a accesa și comunica cu baza de date:
Connection – sesiune unică cu date referitoare la autentificare, tipul de baza de date, adresa bazei de date, denumirea serverului;
Command – conține comanda ce se dorește a fi executată în baza de date;
DataReader – execută operații de citire din baza de date în funcție de comanda;
DataAdapter – are rolul unei punți ce extrage date din baza de date și le încarcă în setul de date al aplicației (DisconnectedLayer); conexiunea este automat deschisă și închisă (figura 18);
Parameter – are rol de a transmite parametri unei interogări în baza de date;
Transaction – permite operații asupra bazei de date în conditii de siguranță;în cazul apariției unei erori la execuție toate operațiile vor fi readuse la starea anterioară;
Dacă prima cateogie este reprezentată de componentele ce operează cu baza de date o a doua categorie denumită DisconnectedLayer cuprinde componente ce operează cu aplicația sau mai bine zis ce intermediaza operațiile între aplicație și ConnectedLayer.
Componentele Disconnected Layer:
DataSet – un set, o colectie de date stocate în memorie extrase dîntr-o bază de date;
DataTable – un singur tabel dîntr-o colecție de date ale unui DataSet;
DataRow – un rînd al unui DataTable;
DataView – un mod de a vizualiza, sorta, manipula datele unui DataTable;
DataColumn – o coloană dîntr-un DataTable;
Figura 18 – Legătura dintre obiect și baza de date prin intermediul Data Adapteru-ului
4.4.1. Entity Framework
În punctul anterior am vazut modelele fundamentale ce compun Ado.Net și cu care programatorii au putut interacționa cu modele de date relaționale încă de la apariția platformei .Net. Începând cu .Net 3.5 Microsoft a introdus în API-ului Ado.Net o nouă componentă numită Entity Framework.
Scopul componentei EntityFramework este de a interacționa cu baza de date pornind de la un model obiect (object model), astfel nu va mai fi nevoie de intreținerea unor colecții de rânduri și coloane intermediare. Cand se foloșeste Ado.Net, atat Connected cat și Disconnected layer, programatorul trebuie sa fie conștient de ce se află în spatele bazei de date, schema fiecarui tabel, relațiile dintre acestea date de chei primare și străine, view-uri, proceduri stocate. În timp aceste baze de date pot crește ca și complexitate iar odată cu aceasta și codul C# pentru a putea accesa datele stocate. Utiliziând Entity Framework programatorul, dacă dorește, poate interacționa cu baza de date fară a vedea o linie de cod SQL deoarece prin aplelul LINQ to Entities motorul Entity Framework generează automat codul SQL solicitat de către apel.
(MCTS Exam 70-536 Microsoft .NET Framework – Application Development Foundation Self Paced Training Kit, p.263-268)
Exemplu: “Select * from dbo.Proiecte where Id = 143” în EntityFramework se traduce în “this.Context .Proiecte.Where(p=>p.Id == 143)”
Componente EntityFramework (figura 19):
Entities (EDM – Entity Data Model) – reprezintă un model conceptual al unei baze de date prin care o serie de obiecte (clase) C# se pot traduce ca și tabele în SQL;
Object Services – Rolul acestei componente este de a urmări și înregistra modificările aduse asupra unei entități (ex. Schimbarea denumirii unui proiect) și a găsi modalități de salvare a acestora în baza de date;
Entity Client – este o componentă majoră ce are rol de a traduce codul scris în forma LINQ to Entities în cod SQL. Aceasta componentă este responsabilă de deschiderea conexiunii SQL, apeluri asupra bazei de date prin comenzi SQL, citirea datelor prin DataReader, închiderea conexiunii SQL;
Fisierul *.edmx – pentru a crea o legatură între proprietățile unei entități și coloanele tablelului din baza de date căruia îi este asociată entitatea legătura entitate <–> tabel și traducerea proprietăților entității în coloanele tabelului se face prin definirea unui model de asociere logic (mapping logic). Acest model care este definit în fișierul .edm cuprinde trei componente principale modele:
Modelul conceptual (conceptual model) – definește entitățile și relațiile dintre acestea;
Modelul logic (logical model) – asociază modelul conceptual (entitățile, relațiile dintre acestea) cu tabelele din baza de date;
Modelul fizic (physical model) – cuprinde informații ce țin de motorul bazei de date: indexări, partiționări, scheme de tabel, detalii de stocare.
La compilare din fisierul *.edmx vor fi generate trei fisiere XML separate pentru fiecare model: *.csdl – modelul conceptual, *.msl – modelul logic, *.ssdl – modelul fizic.
Clasele ObjectContext și ObjectSet<T> – după construirea entităților EntityFramework va genera automat clasele și proprietățile cu care vor fi asociate în baza de date tabelele, respectiv coloanele. Toate aceste entități vor fi stocate într-un obiect de tip ObjectSet<T>. Aceste entități definesc împreuna și au ca parinte un “Context”. Acest context este definit prîntr-o clasă derivata din ObjectContext și furnizează functionalități de adăugare, modificare, ștergere, salvare, etc. entităților din ObjectSet<T> definite în cadrul acestuia.
Figura 19 – Relatiile dintre componentele Entity Framework, baza de date și obiectele din aplicație
Exemplu Entitate proiectat în Visual Studio:
Add -> New Item -> Entity Data Model
Se adaugă entitățile, proprietățile și relațiile dintre acestea (asemănător proiectării componentelor DataTable dîntr-un DataSet)(figura 20)
Figura 20 – Model tabele Entity Freamework
Click dreapta -> Generate database from Model. Se va genera codul complet de construire al tabelelor.
– –––––––––––––––––
– Entity Designer DDL Script for SQL Server 2005, 2008, and Azure
– –––––––––––––––––
– Generated from EDMX file: D:\IdealProiect\TermoExpert\Model1.edmx
– –––––––––––––––––
SET QUOTED_IDENTIFIER OFF;
GO
USE [Test];
GO
IF SCHEMA_ID(N'dbo') IS NULL EXECUTE(N'CREATE SCHEMA [dbo]');
GO
– –––––––––––––––––
– Dropping existing FOREIGN KEY constraints
– –––––––––––––––––
– –––––––––––––––––
– Dropping existing tables
– –––––––––––––––––
– –––––––––––––––––
– Creating all tables
– –––––––––––––––––
– Creating table 'Peretes'
CREATE TABLE [dbo].[Peretes] (
[Id] int IDENTITY(1,1) NOT NULL,
[Denumire] nvarchar(max) NOT NULL,
[Wmk] nvarchar(max) NOT NULL,
[Orientare] nvarchar(max) NOT NULL
);
GO
– Creating table 'Materials'
CREATE TABLE [dbo].[Materials] (
[Id] int IDENTITY(1,1) NOT NULL,
[Denumire] nvarchar(max) NOT NULL,
[R] nvarchar(max) NOT NULL,
[PereteId] int NOT NULL
);
GO
– –––––––––––––––––
– Creating all PRIMARY KEY constraints
– –––––––––––––––––
– Creating primary key on [Id] în table 'Peretes'
ALTER TABLE [dbo].[Peretes]
ADD CONSTRAINT [PK_Peretes]
PRIMARY KEY CLUSTERED ([Id] ASC);
GO
– Creating primary key on [Id] în table 'Materials'
ALTER TABLE [dbo].[Materials]
ADD CONSTRAINT [PK_Materials]
PRIMARY KEY CLUSTERED ([Id] ASC);
GO
– –––––––––––––––––
– Creating all FOREIGN KEY constraints
– –––––––––––––––––
– Creating foreign key on [PereteId] în table 'Materials'
ALTER TABLE [dbo].[Materials]
ADD CONSTRAINT [FK_PereteMaterial]
FOREIGN KEY ([PereteId])
REFERENCES [dbo].[Peretes]
([Id])
ON DELETE NO ACTION ON UPDATE NO ACTION;
– Creating non-clustered index for FOREIGN KEY 'FK_PereteMaterial'
CREATE INDEX [IX_FK_PereteMaterial]
ON [dbo].[Materials]
([PereteId]);
GO
Clasele ObjectContext și ObjectSet<T>
public partial class ProiecteContainer : ObjectContext
{
#region Constructors
/// <summary>
/// Initializes a new Model1Container object using the connection string found în the 'Model1Container' section of the application configuration file.
/// </summary>
public ProiecteContainer() : base("name=Model1Container", " ProiecteContainer ")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
/// <summary>
/// Initialize a new Model1Container object.
/// </summary>
public ProiecteContainer (string connectionString) : base(connectionString, "ProiecteContainer")
{
this.ContextOptions.LazyLoadingEnabled = true;
OnContextCreated();
}
/// Materials
public ObjectSet<Material> Materials
{
get
{
if ((_Materials == null))
{
_Materials = base.CreateObjectSet<Material>("Materials");
}
return _Materials;
}
}
private ObjectSet<Material> _Materials;
////
,,,
public partial class Material : EntityObject
{
#region Factory Method
/// <summary>
/// Create a new Material object.
/// </summary>
public static Material CreateMaterial(global::System.Int32 id, global::System.String denumire, global::System.String r, global::System.Int32 pereteId)
{
Material material = new Material();
material.Id = id;
material.Denumire = denumire;
material.R = r;
material.PereteId = pereteId;
return material;
}
#endregion
#region Primitive Properties
/// <summary>
/// No Metadata Documentation available.
/// </summary>
[EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]
[DataMemberAttribute()]
public global::System.Int32 Id
{
get
{
return _Id;
}
set
{
if (_Id != value)
{
OnIdChanging(value);
ReportPropertyChanging("Id");
_Id = StructuralObject.SetValidValue(value);
ReportPropertyChanged("Id");
OnIdChanged();
}
}
…
Exemplu adăugare și salvare date cu EntityFramework:
PereteContainer context = new PereteContainer();
var material1 = new Material() { Id = 1, Denumire = "Material 1", R = 10.3 };
var material2 = new Material() { Id = 1, Denumire = "Material 1", R = 10.3 };
context.AddToPeretes(new Perete() { Id = 1,
Denumire = "Perete 1 ",
Materials = new Material[] { material1, material2 } });
context.SaveChanges();
Cod SQL executat în urma salvării contextului:
exec sp_executesql N'insert [dbo].[Peretes]([Denumire], [Wmk], [Orientare])
values (@0, @1, @2)
select [Id]
from [dbo].[Peretes]
where @@ROWCOUNT > 0 and [Id] = scope_identity()',N'@0 nvarchar(max) ,@1 nvarchar(max) ,@2 nvarchar(max) ',@0=N'Perete 1 ',@1=N'23',@2=N'N'
exec sp_executesql N'insert [dbo].[Materials]([Denumire], [R], [PereteId])
values (@0, @1, @2)
select [Id]
from [dbo].[Materials]
where @@ROWCOUNT > 0 and [Id] = scope_identity()',N'@0 nvarchar(max) ,@1 nvarchar(max) ,@2 int',@0=N'Material 1',@1=N'10.3',@2=3
exec sp_executesql N'insert [dbo].[Materials]([Denumire], [R], [PereteId])
values (@0, @1, @2)
select [Id]
from [dbo].[Materials]
where @@ROWCOUNT > 0 and [Id] = scope_identity()',N'@0 nvarchar(max) ,@1 nvarchar(max) ,@2 int',@0=N'Material 1',@1=N'10.3',@2=3
Entity Framework – Code first
Dacă în secțiunile anterioare am discutat despre proiectarea tabelelor dîntr-o bază de date și a claselor cu care acestea sunt asociate plecând de la model EntityFramework sau proiectarea modelului plecând de la tabelele bazei de date în această parte a lucrarii vom discuta despre proiectarea tabelelor din baza de date și a modelului pornind de la codul scris de programator (clase). Această tehnică poartă denumirea de ”Code First” și vine ca o alternativă tehnicilor ”Database First” sau ”Model First”. Acest model vine impreună cu EntityFramework 4.1.
Proiectarea modelului folosind Code first:
[Table("PeretiDefiniti")]
public class PereteDefinit
{
[Key]
public int Id { get; set; }
public string Denumire { get; set; }
public ICollection<MaterialPerete> Materiale { get; set; }
}
[Table("MaterialePereti")]
public class MaterialPerete : BaseMaterial
{
public int Id { get; set; }
public decimal Grosime { get; set; }
public decimal Depreciere { get; set; }
}
Crearea contextului:
using System.Data.Entity;
public class Context : DbContext
{
public IDbSet<MaterialDefinit> MaterialeDefinite { get; set; }
public IDbSet<PereteDefinit> PeretiDefiniti { get; set; }
public Context()
: base("TermoExpertConnectionString")
{
}
}
Generarea tabelelor în baza de date plecand de la model:
Următoarea line de cod este folosită pentru a inițializa baza de date plecând de la contextul definit, respectiv reface baza de date în cazul în care modelul a fost schimbat față de cel inițial.
Database.SetInitializer<Context>(new DropCreateDatabaseIfModelChanges<Context>());
Citirea, scrierea și salvarea datelor:
this.Context = new Context();
var pereteDeModificat = this.Context.PeretiDefiniti.Where(p => p.Id == 23).FirstOrDefault();
if (pereteDeModificat != null)
{
pereteDeModificat.Denumire = "Perete nou";
}
this.Context.PeretiDefiniti.AddUpdateOrDelete(pereteDeModificat);
this.Context.SaveChanges();
Folosirea adnotărilor:
În modelul de mai sus se observă folosirea adnotarii [Key] peste proprietatea care se dorește a fi Id. Acest lucru este necesar pentru EntityFramework în a recunoaște proprietatea Id ca fiind PrimaryKey-ul din tabel.
Lista adnotărilor din EntityFramework:
KeyAttribute – cheie primară;
StringLengthAttribute – definire explicită a lungimii unui string (ulterior varchar(n));
MaxLengthAttribute – definire explicită a lungimii unei proprietăți;
ConcurrencyCheckAttribute ;
RequiredAttribute – indică faptul că proprietatea este obligatorie;
TimestampAttribute;
ComplexTypeAttribute – tip complex;
ColumnAttribute –definirie explicită a proprietăților unei coloane asociată de proprietate (denumire, ordine);
TableAttribute – definirie explicita a proprietăților unui tabel asociat de clasa (denumire, schema);
InversePropertyAttribute ;
ForeignKeyAttribute – marchează o proprietate ca fiind cheie straină unei alte proprietăți;
DatabaseGeneratedAttribute – marchează faptul ca o proprietate este generată de către baza de date;
NotMappedAttribute – indică faptul că proprietatea nu se dorește a fi inclusă în model;
Code-First – Automatic Migration
Începând cu versiunea EntityFramework 4.3.1 cei de la Microsoft au creat o nouă posibilitate de a genera și modifica baza de date prin intermediul ”EntityFramework-Code first” în funcție de model și de versiunea instalată a aplicației. Astfel dacă în viitoarea aplicație se vor mai adauga proprietăți unor entități baza de date va fi automat refacută astfel încat să se potrivească noului model. Acest lucru este posibli prin intermediul fișierului de configurări asociat ”Contextului EntityFramework”.
internal sealed class Configuration : DbMigrationsConfiguration<Context>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
}
…
Exemplu: Presupunem că în modelul “Perete definit” de la punctul anterior dorim să adaugăm proprietatea int “TipPerete”. EntityFramework va genera cod pentru actualizarea tabelului din baza de date atât pentru noua versiune a aplicației cât și pentru revenirea la vechea versiune a acesteia:
namespace TermoExpert.Migrations
{
using System.Data.Entity.Migrations;
public partial class Migration1 : DbMigration
{
public override void Up()
{
AddColumn("PereteDefinit", "TipPerete", c => c.Int(nullable: false, defaultValue: 1));
}
public override void Down()
{
DropColumn("PereteDefinit ", " TipPerete ");
}
}
}
Construirea bazei de date TermoExpert folosind EntityFramework
Pentru a proiecta baza de date vom folosi EntityFramework prin metoda “Code first – Automatic migration”.
În cadrul programului TermoExpert avem doua categorii de date:
standard (nemodificabile ce conțin tabele de valori date de metodologia de calcul MC001 cum ar fi: coeficientul ce ține seama de schimbul de aer, indicii de ocupare al locuinței, valori normate maxime, etc);
date proiect (modificabile de către utilizator pentru fiecare proiect individual: date de amplasament, numărul de pereți, numărul de conducte de apă, tipuri de izolatii, etc.).
Pentru a crea baza de date cu tabele trebuie sa intervenim asupra claselor deja construite în aplicație în secțiunea Business Layer și a le face compatibile cu EntityFramework. Pentru a realiza aceasta compatibilitate vom îndeplini următoarele:
– adăugarea în fiecare clasă proprietatea Id de tip ”int” cu adnotarea [Key] pentru a fi asociată în tabel ca index– PrimaryKey;
– adăugarea adnotării [Table] pentru fiecare clasa – pentru a crea o denumire unică și cunoscută de către programator tabelului din baza de date și nu una generată de EntittiFramework implicit cu denumirea clasei;
– crearea unor relații logice între clase în urma cărora se vor genera relațiile dintre entitățile EF și implicit dintre tabelele SQL;
– înlocuirea definițiilor obiectelor de tip copil din array ”T[]” în ”ICollection<T>”;
– crearea contextului EntityFramework;
– crearea configurării EntityFramework;
Contextul final:
public class Context : DbContext
{
public IDbSet<Project> Projects { get; set; }
//Date predefinite
public IDbSet<Judet> Judete { get; set; }
public IDbSet<Localitate> Localitati { get; set; }
public IDbSet<CategoriePenalizari> CategoriiPenalizari { get; set; }
public IDbSet<FactoriEmisie> FactoriEmisie { get; set; }
public IDbSet<MaterialPredefinit> MaterialePredefinite { get; set; }
public IDbSet<ElementVitratPredefinit> ElementeVitratePredefinite { get; set; }
public IDbSet<TermoIzolatiePredefinita> TermoIzolatiiPredefinite { get; set; }
//Date definitie
public IDbSet<Auditor> Auditori { get; set; }
public IDbSet<MaterialDefinit> MaterialeDefinite { get; set; }
public IDbSet<ElementVitratDefinit> ElementeVitrateDefinite { get; set; }
public IDbSet<TipElementVitrat> TipuriFerestre { get; set; }
public IDbSet<TermoIzolatieDefinita> TermoIzolatiiDefinite { get; set; }
public IDbSet<TermoIzolatieTeviDefinita> TermoIzolatiiTeviDefinite { get; set; }
public IDbSet<PereteDefinit> PeretiDefiniti { get; set; }
public IDbSet<PlanseuDefinit> PlanseuDefinit { get; set; }
…
public Context()
: base("TermoExpertConnectionString")
{
}
}
Securizarea aplicației
Pentru a restricționa accesul asupra aplicației TermoExpert trebuie ca aceasta să implementeze o modalitate prin care va putea fi deschisă doar daca anumite condiții sunt satisfăcute.
Aplicația se va distribui în trei forme: demonstrativ (gratuit – maxim 15 utilizari), licenta unică (poate fi utilizată doar pe un singur calculator), licenta multipla (poate fi utilizată pe mai multe calculatoare).
În cazul în care utilizatorul dorește să utilizeze aplicația în scop demonstrativ acesta va avea la dispozitie 15 încercări și va fi limitat în facilități (cum ar fi tipărirea rapoartelor). Toate aceste încercări vor fi stocate într-un fișier de pe harddisk și vor fi incrementate cu fiecare utilizare până la epuizare.
Pentru distribuirea aplicației cu licență unica sau multipla s-a folosit un algoritm de criptare simetric RijndaelManaged. Acest algoritm va avea ca date de intrare anumite caracteristici ale sistemului de calcul pe care aplicația se utilizează. Astfel datele de ieșire furnizate de algoritm vor fi comparate cu datele furnizate odată cu aplicația. În urma acestei comparații va rezulta dacă aplicația este validă și astfel se permite sau nu utilizarea ei. Datele de comparație (cheia furnizată) va fi stocata în fisierul XML “key.xml”.
4.7. Implementarea aplicației
Etapa de implementare implică integrarea aplicației informatice în sistemul de calcul al utilizatorului. Pentru ca aplicația TermoExpert să funcționeze pe un anumit sistem de calcul există două cerințe de sistem: regăsirea librariilor .Net Framework 4.0 precum și motorul de baze de date SQL Server 2008 Express. Aceste două componente sunt incluse în pachetul ce conține aplicația TermoExpert dar pot fi descărcate și pe site-ul coporatiei Microsoft.
Dupa ce au fost instalate componentele de mai sus, pentru pornirea aplicației TermoExpert trebuie configurată conexiunea de conectare la serverul SQL. Acest lucru se realizează prin modificarea liniei de cod “connectionstring” din fișierul “TermoExpert.exe.config” care se regăsește alături de executabilul “TermoExpert.exe”. De exemplu daca utilizatorul a instalat o instanță SQL cu denumirea SQLExpress iar modul de autentificare asupra serverului este unul de tip WindowsAuthentication conexiunea va arăta în felul urmator: connectionString="Data Source=.\SQLEXPRESS;Initial Catalog = TermoExpert; Integrated Security=True".
Următorul pas în configurarea aplicației reprezintă încarcarea licenței de utilizare în funcție de opțiune (licenta unică/multiplă). Această licență este generată de o aplicație C# separataă numită “TermoExpertKeyGenerator” (figura 21). Datele de intrare pentru generarea licenței vor fi furnizate de către utilizator iar rezultatul va fi un fișier xml “key.xml” ce conține cheia criptată prin care aplicația se face validă.
Figura 21 – Generator cheie securitate TermoExpert
4.8. Testare și experimentare
În această etapă a realizării unei aplicații software putem trece la o serie de teste prin care comparăm utilitatea acestui sistem în funcție de o serie de indici aleși de comun acord cu clientul de la început (viteza de operare, ușurință, rezultate optime).
Pentru testarea aplicației utilizatorii vor urmări: funcționalitatea corectă a interfețelor grafice, corectitudinea calculelor, integritatea datelor după salvarea proiectelor, etc.
Dacă în prezent omul este înlocuit deseori de mașinărie de ce nu ar fi înlocuit și în cazul testării aplicațiilor de către o altă aplicație ? O nouă metoda de testare a unei aplicații informatice este UnitTesting-ul. UnitTesting-ul presupune crearea unui nou proiect C# care va avea ca baza assembly-ul generat de aplicația TermoExpert. Acest assembly numit și “Fake” (TermoExpertFake.dll) va conține toate clasele, proprietățile, metodele aplicației TermoExpert. Având la dispozitie o copie fiedelă a aplicației vom crea metode cu atributele [TestMethod] ce vor testa în mod automat anumite funcționalități ale aplicației.
Exemplu metoda de testare a calculului volumului:
/// <summary>
///A test for VolumulCladirii
///</summary>
[TestMethod()]
public void VolumulCladiriiTest()
{
CaracteristiciGeometrice target = new CaracteristiciGeometrice(); // TODO: Initialize to an appropriate value
target.Lungime = 30;
target.Latime = 15;
target.Inaltime = 10;
var volum = 30 * 15 * 10;
var result = target.VolumulCladirii;
Assert.AreEqual(volum, result);
}
După executarea tuturor metodelor de test se va genera o listă prin care programatorul este informat care metode au intors rezultat corect și care au întors rezultat gresit (figura 22).
Figura 22 – Rezultat dupa executia testelor – Unit Testing
Aplicația poate fi distribuită după ce a fost asigurată o versiune stabilă prin finalizarea etapei de testare și corectarea așa numitelor “bug-uri”.
4.9. Utilizare și întreținere
Punerea în funcțiune constă, în principal din urmatoarele activități: instalarea aplicației pe suportul clientului împreună cu programele auxiliare necesare funcționării, configurare aplicație, instruire personal, măsuri organizatorice și proceduri tehnice, instruirea unei persoane cheie de legatură între producătorul software și firma beneficiară a aplicației.
Utilizatorii programului de calcul TermoExpert vor avea rol atat de beneficiari ai rezultatelor produse de acesta cat și de consultanți în vederea îmbunătățirii precum și în corectarea problemelor.
CONCLUZII
Certificatul energetic este un document foarte important în ceea ce privește reflectarea performanței energetice a unei clădiri precum și emisiile de CO2. Datorită normelor de protecție a mediului în prezent sunt multe bănci care oferă credite ipotecare doar dacă sunt satisfăcute anumite condiții de performanță termică a clădirii. De asemenea întâlnim țări unde impozitarea locuinței se face pe baza emisiei de CO2.
După cum s-a arătat în capitolele introductive, pentru aflarea rezultatului privind consumul de energie și emisie de CO2 se parcurg o serie de etape conform metodologiei de calcul MC001 iar fiecare etapă la rândul ei din alte proceduri așa că un program de calcul cu o interfață grafică și o parcurgere ușor de ințeles de către utilizator este potrivit acestei nevoi. Principalele alternative în realizarea Certificatului energetic sunt: parcurgea, pe hârtie, al algoritmului de calcul dar acest lucru presupune cunoașterea în întregime și îndetaliată a metodologiei de calcul sau realizarea CE în aplicația tabelar ă Microsoft Excel, însă acest lucru implică o cunoaștere bună a aplicației de către utilizator deoarece se pot pierde date cu ușurință și astfel erori de calcul dacă documentul Excel nu este manevrat corespunzător. Ambele metode ”tradiționale” duc la mult timp pierdut pentru repararea greșelilor. Astfel, prin realizarea aplicației TermoExpert, am reușit sa reduc timpul de realizare al unui certificat de la ore la câteva minute și totodată oferirea unei accesibilități incomparabile. Înca de la început, la parcurgerea prezentărilor video și consultarea manualului de utilizare, utilizatorul va înțelege funcționarea programului.
Ca și direcții de dezvotare pentru această aplicație software urmăresc crearea posibilității de stocare automată a datelor din aplicație într-un registru online precum și posibilitatea creării de rapoarte personalizate de către utilizatorul însăși prin utilizarea funcțiilor de Drag-And-Drop. Deoarece în prezent a apărut o nouă “modă” în domeniul calculatoarelor portabile cu ecran tactil, iar multe dintre acestea folosesc un alt sistem de operare decât cel în care a fost realizat TermoExpert, o nouă idee de dezvoltare ar putea fi realizarea unei versiuni compatibile cu aceste sisteme și astfel se vor putea realiza proiectele de calcul chiar de la amplasament.
În final trebuie sa mă indepărtez de domeniul tehnic al lucrarii și aș putea spune ca o altă concluzie la care am ajuns este accesibilitatea de care toate tehnologiile acestui timp sunt caracterizate, iar dacă îmbinăm această accesibilitate cu un raționament logic putem crea soluții ce oferă rezultate fară un foarte mare volum de muncă.
BIBLIOGRAFIE
[1] Performanța energetică a clădirilor. Ediția I – partea a III – a – Auditul și certificatul energetic al clădirilor, Besti Publishing, ianuarie 2009
[2] Performanța energetică a clădirilor. Editia I – partea I – Anvelopa clădirii, , Besti Publishing, ianuarie 2009
[3] Prof.univ.dr.ing. Octavia Cocora , Conf.univ.dr.ing. Cătălin Lungu, Brviar de calcul al performanței energetice a clădirilor, VitaStal Consulting, iulie 2009;
[3] Jeffrey Richter, CLR via C# 3rd Edition, Ed. Wintellect, 2010;
[4] Andrew Troelsen, Pro C# 2010 and the .NET 4 Platform 5th Edition, Ed. Apress, 2010;
[5] Tony Northrup, MCTS Exam 70-536 Microsoft .NET Framework – Application Development Foundation Self Paced Training Kit, Microsoft Press, 2008;
[6] Thuan L.Tai and Hoang Lam, .NET Framework Essentials 2nd Edition, Ed. O’Reilly, 2002;
[7] Robin Dewson, Beginning SQL Server 2008 for Developers, Ed. Apress, 2008;
[9] Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, Morgan Skinner, C# 4.0 and .NET 4, Ed. Wiley Publishing, Inc., 2010;
[9] Connolly, T., Begg, C., Database solutions, Ed. Addison-Wesley, 2000;
BIBLIOGRAFIE
[1] Performanța energetică a clădirilor. Ediția I – partea a III – a – Auditul și certificatul energetic al clădirilor, Besti Publishing, ianuarie 2009
[2] Performanța energetică a clădirilor. Editia I – partea I – Anvelopa clădirii, , Besti Publishing, ianuarie 2009
[3] Prof.univ.dr.ing. Octavia Cocora , Conf.univ.dr.ing. Cătălin Lungu, Brviar de calcul al performanței energetice a clădirilor, VitaStal Consulting, iulie 2009;
[3] Jeffrey Richter, CLR via C# 3rd Edition, Ed. Wintellect, 2010;
[4] Andrew Troelsen, Pro C# 2010 and the .NET 4 Platform 5th Edition, Ed. Apress, 2010;
[5] Tony Northrup, MCTS Exam 70-536 Microsoft .NET Framework – Application Development Foundation Self Paced Training Kit, Microsoft Press, 2008;
[6] Thuan L.Tai and Hoang Lam, .NET Framework Essentials 2nd Edition, Ed. O’Reilly, 2002;
[7] Robin Dewson, Beginning SQL Server 2008 for Developers, Ed. Apress, 2008;
[9] Christian Nagel, Bill Evjen, Jay Glynn, Karli Watson, Morgan Skinner, C# 4.0 and .NET 4, Ed. Wiley Publishing, Inc., 2010;
[9] Connolly, T., Begg, C., Database solutions, Ed. Addison-Wesley, 2000;
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: Performanta Energentica (ID: 144070)
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.