d1k23kd




APLICATIE PENTRU EVIDENTA CHELTUIELILOR LUNARE ALE ASOCIATIILOR DE PROPRIETARI


1. CONTINUTUL PROIECTULUI: a. Piese scrise: Specificatii de Definitie, Introducere, Memoriu Tehnic, Memoriu Justificativ, Caiet de Sarcini, Manual de Operare, Bibliografie. b. Piese desenate: diagrame c. Anexe: Listing program.
2. LOCUL DOCUMENTATIEI:
3. CONSULTANTI:
4. DATA EMITERII TEMEI:
5. TERMEN DE PREDARE:

Cuprins

1. INTRODUCERE 1
1.1 Aplicabilitate 1
1.2 Specificatii de definitie 2
1.3 Reguli de calcul 4
2. MEMORIU TEHNIC 8
2.1 Aplicatii cu baze de date 8
2.2 Metodica de proiectare a aplicatiei 10
2.3 Etapa analiza. Entitati si Atribute 13
2.4 Etapa analiza. Evenimente si Functii 17
2.5 Etapa proiectare. Diagrama Entitate-Relatie 18
2.6 Etapa proiectare. Diagrama Functionala 22
2.7 Etapa proiectare. Arhitectura aplicatiei 25
2.8 Etapa implementare 27
3. MEMORIU JUSTIFICATIV 29
3.1 Proiectarea si implementarea bazei de date 29
3.2 Proiectarea interfetei utilizator 32
Meniul aplicatiei 32
Formulare 35
3.3 Implementare 40
Functii publice 41
Functia de calcul a cheltuielilor 42
Raportul cheltuielilor 44
3.4 Documentare 45
3.5 Testare 46
3.6 Pachet de instalare 46
4. CAIET DE SARCINI 47
5. MANUAL DE OPERARE 48
Instructiuni pentru instalarea aplicatiei 48
Instructiuni de utilizare 50
6. CONCLUZII 51
Aprecieri 51
Posibilitati de dezvoltare ulterioara 52
BIBLIOGRAFIE 53
ANEXE 54
Anexa 1. Listing Program 54

1. INTRODUCERE

In partea introductiva a lucrarii vom prezenta scopul aplicatiei, posibilitatile de utilizare practica, precum si notiunile de baza utilizate de catre administratorii de imobile, notiuni utilizate la implementarea aplicatiei sub forma elementelor de proiectare.
De asemenea, din partea introductiva va rezulta si necesitatea dezvoltarii unei astfel de aplicatii si implicatiile pe care le are utilizarea acesteia in cadrul activitatii de calcul si evidenta a cheltuielilor asociatiilor de proprietari .

1.1 Aplicabilitate

Aplicatia este destinata asociatiilor de proprietari respectiv administratorilor de imobile, prin caracterul sau general acesta putandu-se aplica in orice asociatie de proprietari sau imobil din Romania, respectand prevederile legale de calcul si evidenta aflate in vigoare.
Se urmareste automatizarea procesului de calcul si evidenta a cheltuielilor pe care le au de achitat lunar locatarii / proprietarii unui imobil. Calculele pe care administratorul blocului le face manual sunt greoaie si predispuse erorilor, in orice moment exista posibilitatea ca acesta sa introduca erori de calcul sau de evidenta, deci o aplicatie care sa-i usureze si sa ii sistematizeze activitatea este un ajutor binevenit.
In principiu, aplicatia trebuie sa permita introducerea informatiilor necesare calculului cumulativ, sa execute acest calcul pe baza informatiilor introduse sau deja existente intr-o forma de evidenta si sa genereze o lista pe care administratorul o va afisa pe panou. De asemenea aplicatia trebuie sa permita introducerea si memorarea platilor pe care le efectueaza locatarii / proprietarii lunar.
Pentru faza de documentare si testare, s-au folosit informatii puse la dispozitie de catre administratorul imobilului aflat pe strada Prof. Ciortea nr.7.

1.2 Specificatii de definitie

In urma discutiilor purtate cu administratorul de imobil precum si in urma studierii unor prevederi legale(legi, ordonante) referitoare la asociatiile de proprietari si la administrarea imobilelor, au rezultat o serie de notiuni specifice acestui domeniu, care vor fi utilizate la faza de implementare sub forma unor elemente de proiectare. Prezentam in continuare aceste notiuni si semnificatia lor.
Notiunea de asociatie de proprietari reprezinta asocierea tuturor proprietarilor sau locatarilor care locuiesc respectiv detin unul sau mai multe apartamente intr-un imobil de locuinte intr-o forma cu personalitate juridica, numita Asociatie de Proprietari in vederea gestionarii in comun a resurselor legate de serviciile furnizate de catre regiile autonome si a altor probleme legate de gestionarea in comun a unor resurse, fonduri, spatii.
Astfel, cererea pentru dobandirea personalitatii juridice a asociatiei, statutul, acordul de asociere si procesul-verbal al adunarii constitutive se inregistreaza la organul financiar pe a carui raza se afla cladirea. Asociatia dobandeste personalitate juridica in baza incheierii actului de catre judecatorul delegat la organul financiar local de presedintele judecatoriei in a carei circumscriptie teritoriala se afla imobilul.a1i
Forma de organizare a asociatiei de proprietari nu face subiectul acestei lucrari, deci vom insista doar pe partea de calcul si evidenta a cheltuielilor lunare.
In cazul de fata, la proiectarea aplicatiei ne vom referi in special la notiunea de imobil care reprezinta totalitatea apartamentelor aflate intr-o cladire cu locuinte. Acesta este caracterizat prin denumire, adresa, localitatea si judetul unde se este situat imobilul.
Prin notiunea de apartament se intelege locuinta separata, indivizibila aflata intr-un imobil. Un imobil contine unul sau mai multe apartamente si un apartament apartine unui singur imobil. In cadrul imobilului, apartamentul este identificat prin numar de apartament. De asemenea apartamentul este caracterizat prin proprietar, numar de camere, suprafata totala si numarul de persoane care locuiesc in apartament. Aceste caracteristici pot fi variabile in sensul modificarii lor de la o luna la alta.
Notiunea de furnizor reprezinta o societate comerciala, o regie autonoma, o persoana fizica sau o persoana juridica care furnizeaza servicii asociatiei de proprietari. Furnizorul este caracterizat prin denumire, cod fiscal si adresa. Contravaloarea acestor servicii fac obiectul unei facturi emise de furnizor catre asociatia de proprietari.
Astfel introducem notiunea de factura ca si documentul care contine cuantumul de consum al serviciului oferit si contravaloarea acestuia, exprimat in lei. Factura este caracterizata prin numar de document, furnizorul, tipul de serviciu furnizat, consumul, luna pentru care se face facturarea si suma care reprezinta contravaloarea serviciului. Factura se emite de catre furnizor pentru luna precedenta. Prin notiunea de luna intelegem intervalul de timp echivalent cu o luna calendaristica pentru care furnizorul a efectuat facturarea si in consecinta proprietarul apartamentului trebuie sa achite cota parte din aceasta factura care ii revine conform normelor de calcul in vigoare.a2i Luna se caracterizeaza prin indexul sau denumirea acesteia(ianuarie - decembrie) si prin anul din care aceasta face parte.
Aplicatia va utiliza astfel notiunea de luna ca si termen de referinta pentru efectuarea calculelor. Pentru o luna se pot emite una sau mai multe facturi.
Pentru ca un furnizor poate sa emita facturi pentru unul sau mai multe tipuri de consum, vom trata separat notiunea de tip de consum, care reprezinta tipul de consum pentru factura emisa de catre furnizor. Tipul de consum este caracterizat de furnizor, unitate de masura si tip de calcul. Unui tip de consum ii pot reveni astfel una sau mai multe facturi.
Notiunea tip de calcul reprezinta modalitatea in care se face calcul cuantumului aferent fiecarui apartament din imobil pentru un anumit tip de consum. Astfel, acesta poate sa fie la nivel de apartament, la nivel de numar de persoane care locuiesc in apartament in luna respectiva sau la nivel de suprafata a apartamentului.a2i Un tip de calcul este determinant pentru unul sau mai multe tipuri de consum.
Prin notiunea de incasare se intelege actiunea prin care administratorul imobilului primeste de la proprietarul apartamentului o suma de bani aferenta cuantumului rezultat in urma cheltuielilor lunare. De obicei proprietarul achita suma exacta rezultata dar poate sa achite si o parte din aceasta suma, sau chiar sa nu achite deloc suma datorata, astfel suma devenind restanta. In urma achitarii unei sume, administratorul emite o chitanta, care este dovada ca proprietarul a achitat suma respectiva. Incasarea este caracterizata de numar chitanta, data la care a fost efectuata plata si suma incasata. Astfel, pentru un apartament se pot efectua una sau mai multe incasari.

1.3 Reguli de calcul

Cuantumul cheltuielilor aferente fiecarui apartament din imobil se calculeaza pe baza facturilor lunare pe care administratorul imobilului le primeste de la furnizorii de servicii(societatile comerciale care asigura livrarea apei reci si calde menajere, furnizarea agentului termic, curentului electric, gazului metan, serviciile de salubrizare, etc.) precum si din informatiile specifice fiecarui apartament(numar de persoane, suprafata, numar de camere, etc.)
Calcul se face pe baza prevederilor legale in vigoare.
Prezentam in continuare formulele de calcul defalcate pentru cele 3 tipuri de calcul: a. Calcul la nivel de suprafata
Acest tip de calcul se face in special in cazul energiei termice.
Cheltuielile pentru incalzirea locuintelor/apartamentelor, indiferent de modul de inregistrare a consumului de energie termica si de sursa de agent termic, se repartizeaza proportional cu suprafata utila inscrisa in actul de proprietate, iar pentru incalzirea spatiilor aflate in folosinta comuna intr-o cladire (casa scarii, culoare, spalatorii, uscatorii, holuri si altele asemenea) se repartizeaza proportional cu cota-parte indiviza care ii revine fiecarui proprietar din proprietatea comuna, astfel cum aceasta este inscrisa in actul de proprietate.a7i
Consumul se calculeaza cu urmatoarea formula:

unde cas -; consumul la nivel de suprafata, pe apartament sa -; suprafata apartament cis -; consumul la nivel de suprafata, total pe imobil cics-; consumul la nivel de suprafata, contorizat total pe imobil si -; suprafata totala a tuturor apartamentelor din imobil sic -; suprafata totala a tuturor apartamentelor contorizate din imobil
Apartamentele contorizate sunt cele care au contoare separate pentru tipul de consum in discutie si care platesc separat, in functie de consumul inregistrat de aceste contoare.
In cazul energiei termice se va obtine consumul aferent unui apartament necontorizat, exprimat in m3. Cu urmatoarea formula se obtine valoarea aferenta acestui consum, exprimata in Lei, adica suma pe care o are de platit un apartament necontorizat pentru serviciul respectiv.

unde vas -; valoarea consumului la nivel de suprafata, pe apartament cas -; consumul la nivel de suprafata, pe apartament vis -; valoarea totala a serviciului facturat, la nivel de suprafata cis -; consumul la nivel de suprafata, total pe imobil

b. Calcul la nivel de numar de persoane
Acest tip de calcul se face in cazul consumului de apa curenta menajera(apa rece, apa calda, canalizare), consumului de gaze naturale, etc.

Consumul se calculeaza cu urmatoarea formula:

unde cap -; consumul la nivel de numar persoane, pe apartament pa -; numarul de persoane care locuiesc in apartament cip -; consumul la nivel de numar persoane, total pe imobil cicp -; consumul la nivel de numar persoane, contorizat total pe imobil pi -; numarul total de persoane care locuiesc in imobil pic -; numarul total de persoane care locuiesc in imobil dar la care apartamentele in care locuiesc exista contoare pentru serviciul respectiv
De exemplu, in cazul consumului de gaze naturale se va obtine consumul aferent unui apartament necontorizat, exprimat in m3. Pentru obtinerea valorii aferente acestui consum, exprimata in Lei, adica suma pe care o are de platit un apartament necontorizat pentru serviciul respectiv, se foloseste formula:

unde vap -; valoarea consumului la nivel de numar persoane, pe apartament cip -; consumul la nivel de numar persoane, total pe imobil cap -; consumul la nivel de numar persoane, pe apartament vip -; valoarea totala a serviciului facturat, la nivel de numar persoane

c. Calcul la nivel de apartament
Acest tip de calcul se face in cazul retributiilor sub forma de salarizare ale administratorului, persoanei care face curatenie in imobil, etc.
Consumul se calculeaza cu urmatoarea formula:

unde caa -; consumul la nivel de apartament, pe apartament cia -; consumul la nivel de apartament, total pe imobil cica -; consumul la nivel de apartament, contorizat total pe imobil ai -; numarul total de apartamente din imobil aic -; numarul total de apartamente din imobil in care locuiesc exista contoare pentru serviciul respectiv
De exemplu, in cazul salariului administratorului, avand in vedere ca nu exista apartamente cu regim de contorizare, cic si aic vor fi zero, deci fiecare apartament va plati aceeasi suma, egala cu salariul administratorului impartit la numarul de apartamente din imobil.

Pentru obtinerea valorii aferente acestui consum, exprimata in Lei, adica suma pe care o are de platit un apartament necontorizat pentru serviciul respectiv, se foloseste formula:

unde vaa -; valoarea consumului la nivel de apartament, pe apartament caa -; consumul la nivel de apartament, pe apartament via -; valoarea totala a serviciului facturat, la nivel de apartament cia -; consumul la nivel de apartament, total pe imobil

Dupa calcularea valorilor pentru fiecare tip de consum in parte, obtinem totalul de plata pentru fiecare apartament, dupa formula:

unde vt -; valoarea totala de plata pentru apartament, pentru luna curenta vas -; valoarea consumului la nivel de suprafata, pe apartament vap -; valoarea consumului la nivel de numar persoane, pe apartament vaa -; valoarea consumului la nivel de apartament, pe apartament ns -; numarul de servicii dependente de suprafata np -; numarul de servicii dependente de numarul de persoane na -; numarul de servicii dependente de apartament
Aceste formule de calcul se aplica pentru fiecare apartament din imobil iar valorile obtinute vt, constituie lista de cheltuieli lunare, scopul principal al dezvoltarii acestei aplicatii. Eventual, ca si optiune, se pot afisa si unele dintre consumurile vs, vp sau va, de obicei cele mai importante din punct de vedere valoric, cum ar fi energia termica sau apa curenta menajera.

2. MEMORIU TEHNIC

2.1 Aplicatii cu baze de date

O aplicatie este in principiu o colectie software consolidata cu scopul de a rezolva un set dat de probleme. Rezolvarea problemelor prin punerea in practica a software-ului se numeste software engineering. Tot asa cum in alte proiecte ingineresti cum ar fi constructia unei cladiri sau a unui aparat de zbor este depus un efort considerabil inaintea punerii primei caramizi in constructia cladirii sau inainte de conceperea primei piese a aparatului de zbor. In timpul fazei initiale (numita faza de proiectare) o serie de elemente vor intra in contact unele cu altele pentru a da forma proiectului de aplicatie. Unele din elemente sunt ne-negociabile sau resurse limitate cum ar fi timpul, banii, sau mana de lucru. Altele, cum ar fi tehnologiile disponibile, cunostintele, sau indemanarea sunt resurse dinamice si variaza pe parcursul ciclului de viata al sistemului "business".a9i
Notiunea de baza de date este strans legata de notiunea de date, care refera „fapte culese din lumea reala” a11i. Baza de date se refera la un volum mare de date, care sunt stocate pe suport fizic; ea reprezinta, in cazul sistemului computerizat, echivalentul arhivei din viata reala. Mai poate fi inteleasa ca o colectie de fisiere de date intr-un sistem de calcul a12i.
Pentru o baza de date cel mai important lucru este manipularea datelor continute in acea baza de date. Aceasta „manipulare” refera operatiile care se pot efectua asupra datelor: operatii de adaugare a unor date noi, operatii de regasire, de modificare, de stergere a datelor existente a12i.
Programarea bazelor de date constituie, de fapt, procesul de stocare -; folosind o modalitate standard -; a unei varietati de informatii, astfel incat sa fie posibila o accesare si o intretinere facila a datelor. Informatiile stocate intr-o baza de date, spre deosebire de un document creat cu un procesor de texte, respecta de obicei un format standard.a10i
Pentru aplicatia ceruta, utilizarea unei aplicatii cu baze de date in detrimentul altor metode de rezolvare a problemei date, cum ar fi calculul tabelar sau o aplicatie standard, fara baze de date, rezolva o serie de probleme si neajunsuri. Din acest punct de vedere, unele avantaje ale proiectarii aplicatiei cu baze de date au constituit un factor important de decizie atunci cand am ales modalitatea de rezolvare a problemei date, cum ar fi:
- posibilitatea stocarii unui volum relativ mare de informatii, precum si accesul ulterior la aceste informatii;
- remanenta informatiei, care in cazul unei aplicatii standard, fara baze de date, era incerta. Astfel, utilizatorul aplicatiei va avea posibilitatea sa verifice la un moment dat situatia locatarilor sau a cheltuielilor pentru luna precedenta sau chiar pentru anul trecut, existand posibilitatea intocmirii unor statistici evolutive a situatiei locatarilor, a cheltuielilor, etc.;

- simplificarea procesului de calcul, care in cazul calculului tabelar ar fi avut o complexitate ridicata, fara a avea un control real asupra fluxului de informatie gestionat;
- transparenta totala a implementarii, utilizatorul aplicatiei nu trebuie sa cunoasca modalitatile efective de implementare, modul de stocare a datelor, verificarile de corectitudine a informatiilor introduse. Utilizatorul nu trebuie sa cunoasca ce se intampla cu o informatie introdusa in sistem, dar in acelasi timp acesta trebuie sa aiba acces la informatia respectiva;
- fiind vorba de sume de bani, securitatea metodelor de calcul trebuie sa fie ridicata, trebuie sa fie eliminata pe cat posibil posibilitatea introducerii de erori in rezultatul final, iar o aplicatie care utilizeaza baze de date reuseste sa atinga acest obiectiv. In acest sens sunt necesare o serie de verificari la introducerea de informatii in sistem, care sa evite aceste erori(cum ar fi de exemplu verificarea ca la introducerea unui consum sau a unei sume, sa nu poata fi introduse valori negative).
Concluzionand, baza de date va trebui sa contina toate informatiile necesare calculului si a evidentei cheltuielilor lunare ale imobilelor. Aceste informatii vor fi introduse de catre utilizatorul sistemului, adica de catre administratorul imobilului, prin intermediul interfetei puse la dispozitie de aplicatie.
Avand in vedere ca in general administratorii de imobil nu sunt persoane cu pregatire informatica sau cunostinte de operare, cei mai multi dintre acestia nefiind familiarizati cu tehnica de calcul, aplicatia trebuie sa fie cat mai intuitiva, cat mai usor de utilizat si sa nu contina elemente care ar putea sa genereze situatii de ambiguitate. Este de asemenea important ca interfata aplicatiei sa fie realizata in intregime cu termeni in limba romana, iar termenii utilizati pentru denumirea elementelor constitutive ale interfetei sa reprezinte cat mai bine termenii corespondenti din limbajul specific al acestui domeniu, mai exact termeni gasiti si in legislatia referitoare la asociatiilor de proprietari.
Automatizarea procesului de calcul prin intermediul aplicatiei trebuie sa fie de asemenea transparent, fazele in care se obtin valori intermediare nu au importanta practica pentru administrator.

2.2 Metodica de proiectare a aplicatiei

Dezvoltarea unui sistem este o activitate laborioasa ce cuprinde o multitudine de sub-activitati("tasks") desfasurate intr-o maniera metodica. Aceste sub-activitati pot fi grupate in etape importante. Fiecare etapa are definite clar elementele livrate (adica ce produse finale sunt obtinute la incheierea etapei) etapelor ulterioare.
In cadrul fiecarei etape (stadiu) sub-activitatile tind sa fie de scurta durata si pot fi estimate cu usurinta. Fiecare sub-activitate este divizata in mai multe sub-sub-activitati. O anumita sub-sub-activitate se poate repeta de un numar de ori din diferite motive.
Vom discuta despre dezvoltarea pe baza modelului CASE(Computer-Aided Szstems Engineering).
Prezentam in mare etapele importante de dezvoltare, conform acestui model, fara a insista cu detalii asupra metodelor si sub-activitatilor corespunzatoare fiecarei etape :
- etapa de strategie -; obiectivul este de a produce un set de modele de business, un set de recomandari si un plan agreat pentru dezvoltarea sistemelor de informatii ce vor servi nevoilor curente si viitoare ale organizatiei, tinand cont de constrangerile financiare si tehnice ale organizatiei.a9i Este analizata problema care trebuie rezolvata, pe baza specificatiilor de definitie. Aceste specificatii sunt obtinute in urma discutiilor avute cu beneficiarul aplicatiei, studierea unor documentatii legate de domeniul de activitate respectiv, in acest caz este vorba de studierea legislatiei asociatiilor de proprietari si discutiile avute cu administratorul de imobil;
- etapa de analiza -; Preia si verifica lucrurile obtinute in etapa strategie si le expandeaza in detaliu suficient pentru a asigura acuratetea de business, fezabilitatea si un fundament sanatos pentru proiectare, in cadrul domeniului organizatiei si avand in minte sisteme existente;a9i
- etapa de proiectare -; pe baza etapei de analiza, se realizeaza proiectarea aplicatiei, in urma careia rezulta directive concrete pentru etapa de implementarea9i, de exemplu se realizeaza proiectarea schemei bazei de date, stabilirea functiilor de business necesare in sistem, etc.;
- etapa de implementare -; realizarea efectiva a aplicatiei, scrierea codului, realizarea bazei de date, compilarea aplicatiei sub forma unui program executabil;
- etapa de testare -; produsul software este testat in conditii normale de utilizare si se rezolva eventualele probleme;
- etapa de documentare -; se scrie documentatia aplicatiei(sub forma tiparita si/sau online), se face instruirea viitorilor utilizatori ai aplicatiei.

Figura 1. Ciclul de viata al unui sistem informatica9i

Rezultatul stadiilor strategie si analiza trebuie sa fie complet independente de orice tehnica de implementare specifica, pentru a da proiectantului oportunitatea maxima de a folosi tehnologia potrivita si pentru a proiecta in coexistenta cu sisteme curente. Metoda CASE trebuie sa fie doar scheletul, ea trebuie completata cu ideile proprii si inovatia contribuie la calitatea produsului final.
Business-urile sunt in continua miscare. In linii mari se schimba nu CE este facut ci CINE si CUM face. Modelele folosite pentru a defini cerintele business-ului trebuie sa permita modificari rezonabile in structura organizatiei. Modelele trebuie sa fie de asemenea independente de toate solutiile cunoscute.
Sistemul trebuie sa continue sa functioneze eficient cand, de exemplu, sunt adoptate proceduri noi de fabricatie, vanzare, administrare.
Cerintele ar trebui modelate si definite intr-o maniera generica. Cerintele functionale ar trebui sa defineasca ce este facut, nu cum sau de catre cine. Structura datelor trebuie sa permita modificari: in structura organizatiei, pentru exceptii si pentru limite curente si observabile.a9i

2.3 Etapa analiza. Entitati si Atribute
Pentru a ajunge la realizarea structurii bazei de date, am utilizat specificatiile de definitie(prezentate in subcapitolul 1.2). Pe baza acestor specificatii extragem entitatile si atributele care constituie puncte de plecare la proiectarea bazei de date.
NOTIUNE CALITATE(entitate sau atribut) imobil Entitate denumire imobil Atribut adresa imobil Atribut localitate Atribut judet Atribut nume administrator Atribut apartament Entitate numar apartament Atribut proprietar Atribut numar de camere Atribut numar de persoane Atribut suprafata Atribut furnizor Entitate denumire furnizor Atribut cod fiscal Atribut adresa furnizor Atribut factura Entitate numar document Atribut consum Atribut suma Atribut
incasare Entitate numar chitanta Atribut data emiterii Atribut suma Atribut luna Entitate anul Atribut tip calcul Entitate tip consum Entitate denumire consum Atribut unitate de masura Atribut consum Entitate valoare Atribut
Tabel 1. Lista cu entitati si atribute

In tabelul 2 prezentam entitatile cu tipul acestora precum si cu legaturile dintre ele.
ENTITATE TIP ENTITATE ENTITATI CU CARE ARE LEGATURA imobil entitate de baza apartament entitate de baza • luna
• incasare
• consum furnizor entitate de baza • tip consum factura entitate de baza • luna
• tip consum
incasare entitate de baza • apartament luna entitate de baza • apartament
• factura tip calcul entitate de baza • tip consum consum entitate de legatura • apartament
• tip consum tip consum entitate de baza • consum
• factura
• furnizor
• tip calcul

Tabel 2. Entitatile si legaturile dintre ele

Aceste legaturi le-am stabilit pe baza textului care constituie specificatiile de definitie si sunt piesele de baza la proiectarea structurii bazei de date. Pentru inceput, entitatile si atributele acestora sunt elementele de baza pentru alcatuirea diagramei entitate-relatie.
Modelarea ER a fost inventata la mijlocul anilor '70 de Peter Chen si ramane in continuare principala abordare pentru modelarea datelor.a9i Prin aceasta reprezentare schematica sub forma unei diagrame se reprezinta entitatile, atributele si relatiile dintre entitati precum si tipul acestor relatii.

In tabelul 3 sunt enumerate atributele, pentru fiecare dintre acestea am stabilit tipul de date pe care il vor avea la realizarea bazei de date, in vederea reprezentarii corecte si complete a informatiei. Coloana a 2-a reprezinta numele efectiv utilizat pentru implementare, astfel am dorit sa evit folosirea caracterului spatiu in structura bazei de date.
ATRIBUT NUME UTILIZAT IN BD TIP DE DATE LUNGIME ENTITATEA DE CARE APARTINE denumire imobil denumire sir de caractere 50 imobil adresa imobil adresa sir de caractere 50 imobil localitate localitate sir de caractere 50 imobil judet judet sir de caractere 50 imobil nume administrator numeAdministrator sir de caractere 50 imobil numar apartament nrApartament numeric long integer apartament proprietar proprietar sir de caractere 50 apartament numar de camere nrCamere numeric long integer apartament numar de persoane nrPersoane numeric long integer apartament suprafata suprafata numeric long integer apartament denumire furnizor denumireFurnizor sir de caractere 50 furnizor cod fiscal CF sir de caractere 50 furnizor adresa furnizor adresa sir de caractere 50 furnizor numar document nrDocument sir de caractere 50 factura consum consum numeric long integer factura suma suma numeric long integer factura numar chitanta nrChitanta sir de caractere 50 incasare data emiterii data data calendaristica incasare suma suma numeric double incasare luna luna numeric long integer luna anul anul numeric long integer luna tip calcul tipCalcul sir de caractere 50 tip calcul denumire consum denumireConsum sir de caractere 50 tip consum unitate de masura UM sir de caractere 50 tip consum valoare valoare sir de caractere 50 consum

Tabel 3. Atributele cu tipurile de date corespunzatoare si entitatile de care apartin
Pe langa aceste atribute, vom folosi si unele atribute aditionale, cum ar fi atributul „observatii” la entitatile apartament si furnizor, utile in cazul in care utilizatorul doreste sa isi noteze anumite observatii despre apartamentul sau furnizorul respectiv.

Continuand analiza specificatiilor de definitie, extragem relatiile dintre entitati, care pot sa fie dintre urmatoarele tipuri:
- 1:N (one to many) - la o instanta a unei entitati ii corespunde una sau mai multe din cea de-a doua entitate
- 1:1 (one to one) - la o instanta a unei entitati ii corespunde o instanta a celei de-a doua entitatati
- N:N (many to many) - la o instanta a unei entitati ii corespunde una sau mai multe din cea de-a doua entitate si reciproc, acesteia din urma ii corespund una sau mai multe instante ale primei entitati. In acest caz trebuie introdusa o entitate de legatura pentru implementarea relatiei.

Astfel, relatiile pentru cazul de fata vor fi:
TEXT SPECIFICATIE ENTITATE 1 ENTITATE 2 TIP DE RELATIE un imobil contine unul sau mai multe apartamente imobil apartament 1:N pentru o luna se pot emite una sau mai multe facturi luna factura 1:N unui tip de consum ii pot reveni astfel una sau mai multe facturi tip consum factura 1:N un tip de calcul poate fi determinant pentru unul sau mai multe tipuri de consum tip calcul tip consum 1:N pentru un apartament se pot efectua una sau mai multe incasari apartament incasare 1:N un apartament poate sa aiba unul sau mai multe consumuri apartament consum 1:N un tip de consum este determinant pentru unul sau mai multe consumuri tip consum consum 1:N* un furnizor poate fi determinant pentru unul sau mai multe tipuri de consum furnizor tip consum 1:N
intr-o luna exista unul sau mai multe apartamente luna apartament 1:N*

Tabel 4. Relatiile dintre entitati
Relatiile notate cu * sunt obligatorii.
2.4 Etapa analiza. Evenimente si Functii

Instantierea entitatilor se face numai in momentul aparitiei unor evenimente sau functii de business. Principala functie de business pe care trebuie sa o rezolve aceasta aplicatie ar fi calculul cheltuielilor lunare. Prezentam in continuare o lista a acestor functii.
EVENIMENT FUNCTIE ATASATA EVENIMENTULUI EXPLICATIE CU DETALII
Trecerea la o luna curenta noua Generarea unei luni de prelucrare noi - stabilirea noii luni de prelucrare
- actualizarea datelor despre apartamente (in special numarul de persoane, proprietarul)
Primirea facturilor lunare de la furnizorii de servicii Introducerea facturilor - stabilirea lunii curente de prelucrare
- stabilirea unui furnizor de servicii, cu datele de identificare ale acestuia (denumire, cod fiscal, adresa)
- stabilirea unui tip de consum, cu specificarea tipului de calcul aferent, denumirea tipului de consum si unitatea de masura utilizata
- introducerea facturii, cu stabilirea tipului de consum, specificarea numarului de document, consumul pentru serviciul respectiv si contravaloarea acestuia
Citirea contoarelor din apartamente Introducerea consumurilor - stabilirea lunii curente de prelucrare
- introducerea consumurilor citite de la contoarele de apartament cu specificarea tipului de consum si a numarului de apartament
Atingerea datei de afisare a cheltuielilor Calculul cheltuielilor lunare - stabilirea lunii curente de prelucrare
- verificare daca toate datele necesare pentru calculul cheltuielilor au fost introduse in sistem, inclusiv consumurile contorizate
- calcularea cheltuielilor lunare
- afisarea listei de cheltuieli
Proprietarul unui apartament achita contravaloarea cheltuielilor lunare Incasare - stabilirea lunii curente de prelucrare
- verificarea sumei datorate de proprietar, pe baza calculelor efectuate si a situatiei platilor pentru apartamentul respectiv pana in momentul dat
- introducerea sumei incasate
- emiterea unei chitante

Tabel 5. Evenimente si functii

2.5 Etapa proiectare. Diagrama Entitate-Relatie

In etapa de proiectare vom utiliza informatiile obtinute la faza de analiza pentru a realiza diagrama Entitate-Relatie, pe baza listelor cu entitati, atribute si relatii dintre acestea, precum si diagrama de functii, pe baza listei de evenimente si functii.
Diagrama Entitate-Relatie este o forma generalizata si abstractizata a listei de entitati si atribute, si este utilizata apoi pentru realizarea schemei bazei de date. Aceasta diagrama este independenta de sistemul de gestiune a bazelor de date utilizat in etapa de implementare.
Pentru generarea diagramei Entitate-Relatie, se pot utiliza unelte CASE, care permit editarea acesteia in mod vizual si care apoi pe baza diagramei astfel realizate pot sa genereze in mod automat structura bazei de date. Am utilizat in acest scop aplicatia AllFusion ERwin Data Modeler 4.1, dar pentru ca utiliza elemente de reprezentare a diagramei diferite de cele studiate, am decis sa realizez aceasta diagrama manual.

Prezentam in continuare cateva elemente de notatie ale diagramei Entitate-Relatie.

pentru entitati, exista urmatoarele notatii:
Dreptunghiul cu colturile rotunjite reprezinta entitatea, in care cu litere mari se noteaza denumirea entitatii, si cu litere mici se noteaza atributele.
Linia dintre entitati indica existenta unei relatii intre acestea. Astfel, linia continua indica o relatie obligatorie, linia intrerupta(punctata) reprezinta o relatie obligatorie iar „furca” reprezinta o relatie la N in partea respectiva, in cazul reprezentarii de mai sus relatia fiind de 1:N. pentru specificarea atributelor, exista 3 simboluri distincte:
# (diez) indica faptul ca atributul respectiv este un element de identificare a entitatii, numit si cheie, sau ID.
* (asterisc) indica faptul ca atributul este unul obligatoriu.
? (grad) indica faptul ca atributul este optional.

Citirea diagramei Entitate-Relatie:
Cuvintele din apropierea liniilor sunt cuvinte cheie care definesc relatia si se citesc astfel:
<ENTITATE 1> <cuvant cheie><ENTITATE 2>
Cuvintele cheie care sunt deasupra liniei sunt pentru citirea in directia de la stanga la dreapta, iar cele care sunt sub linie pentru citirea in sens invers, de la dreapta la stanga.
Exemplu: apartament are un consum consum pentru apartament luand in considerare si relatia de 1:N neobligatorie, vom citi: un apartament poate sa aiba unul sau mai multe consumuri un consum trebuie sa fie pentru un apartament
Aceasta metoda de citire a diagramei se foloseste pentru toate entitatile si toate relatiile dintre acestea.
Se poate observa in diagrama Entitate-Relatie existenta unor atribute de identificare, , identificatori unici sau de tip cheie, acestea sunt necesare pentru stabilirea legaturilor dintre entitati in faza de implementare a schemei bazei de date. In continuare vom enumera aceste atribute:

ATRIBUT ENTITATEA DE CARE APARTINE TIP ATRIBUT lunaID luna cheie primara apartamentID apartament cheie primara incasareID incasare cheie primara consumID consum cheie primara tipConsumID tipConsum cheie primara furnizorID furnizor cheie primara tipCalculID tipCalcul cheie primara facturaID factura cheie primara

Tabel 6. Atribute de identificare
Bara verticala perpendiculara pe o linie de legatura la capatul dinspre N ne indica faptul ca identificatorul unic(cheia) al entitatii respective se propaga, pe baza relatiei de legatura, si in entitatea care are aceasta bara. Acest fapt este utilizat la constructia structurii bazei de date pentru realizarea efectiva a relatiilor dintre entitati.

Am exclus entitatea imobil din diagrama Entitate-Relatie pentru ca legatura acesteia cu alte entitati a fost ignorata din considerente bine intemeiate. Astfel, in loc sa consideram ca fiind utila relatia dintre entitatile imobil si apartament, am preferat sa cream o legatura artificiala intre entitatile luna si apartament, care va fi mult mai utila la realizarea acestei aplicatii, deoarece intre aceste doua entitati exista o relatie de 1:N, adica la fiecare instanta de tip luna ii vor corespunde toate apartamentele din imobil, cu specificatia ca acestea vor avea structura(din punct de vedere al numarului de persoane, al proprietarului, al suprafetei si a numarului de camere) valabila numai pentru luna curenta de prelucrare. Astfel obtinem o flexibilitate sporita la trecerea de la o luna la alta, pentru ca modificarea unei caracteristici a unui apartament nu va influenta situatia din lunile anterioare.

2.6 Etapa proiectare. Diagrama Functionala

Figura 3. Diagrama functionala

2.7 Etapa proiectare. Arhitectura aplicatiei

Pentru dezvoltarea aplicatiilor cu baze de date, in functie de necesitatile de utilizare ale aplicatiei, se pot utiliza 3 tipuri de arhitectura, pe care le vom prezenta in continuare. a. Arhitectura Desktop
Arhitectura desktop este caracterizata de coexistenta aplicatiei si a bazei de date pe aceeasi masina fizica(pe acelasi calculator)

Figura 4. Arhitectura Desktop

Acest tip de arhitectura se utilizeaza in cazul aplicatiilor de complexitate redusa, cand baza de date este utilizata de o singura aplicatie si eventual de un singur utilizator. Accesul la baza de date se face fie direct de catre aplicatie(de exemplu in cazul unei aplicatii realizate in Visual Fox) sau prin intermediul unui motor de baze de date.

b. Arhitectura Client-Server
In cazul arhitecturii client-server, baza de date si aplicatia nu se gasesc neaparat pe acelasi calculator. Aplicatia ruleaza pe un sistem de calcul numit client, iar baza de date se gaseste pe un alt sistem de calcul, numit server, si este gestionata de un server de baze de date(de exemplu SQL Server, MySQL, etc.) Comunicarea dintre client si server se face prin intermediul unui canal de comunicatie, care este de obicei o retea locala LAN(Local Area Network) sau o retea WAN(Wide Area Network).
Acest tip de arhitectura permite accesul la baza de date de la distanta prin conectarea directa a clientului la serverul de baze de date, de exemplu printr-o conexiune de tip peer-to-peer.

Figura 5. Arhitectura Client-Server

c. Arhitectura Multistrat
Arhitectura multistrat este cea mai moderna dintre cele 3, si este caracterizata prin existenta a cel putin 3 sisteme de calcul, in mod generic. Aplicatia ruleaza pe sistemul client, pe care eventual ruleaza si un browser de web, prin intermediul caruia aplicatia poate sa emita cereri serverului de aplicatii, care poate fi de asemenea si un server de web. Serverul de aplicatii contine regulile de business ale aplicatiei, si este controlat de un administrator care cunoaste foarte bine intregul sistem si se ocupa cu eventualele actualizari ale sistemului. Un al treilea sistem este serverul de baze de date, unde se gaseste si baza de date. Serverul de aplicatii functioneaza ca un intermediar(gestionar) intre client si serverul de baze de date.
In aplicatiile prin intermediul internetului, de multe ori pe calculatorul client nu ruleaza o aplicatie specializata, ci doar serverul de web, iar utilizatorul are acces la baza de date prin accesarea unei pagini de internet.

Figura 6. Arhitectura Multistrat

Dintre cele trei arhitecturi prezentate, vom utiliza pentru dezvoltarea aplicatiei arhitectura desktop, pentru ca deocamdata nu se justifica utilizarea unei conexiuni la distanta sau prin intermediul internetului. Intr-o etapa de dezvoltare ulterioara a aplicatiei, se pot lua in considerare si celelalte tipuri de arhitectura. Aceasta problema este dezbatuta pe larg in capitolul Dezvoltari ulterioare.

2.8 Etapa implementare

Pentru implementarea aplicatiei am ales mediul de programare Visual Basic 6.

Mediul de programare Microsoft? Visual Basic este unul dintre cele mai utilizate medii de programare pentru realizarea aplicatiilor cu baze date, pentru ca acest mediu are o serie de facilitati pentru utilizarea bazelor de date.
Visual Basic 6 contine un motor complet de baze de date, care reprezinta, in esenta, o aplicatie de baze de date cu autocontinere. Spre deosebire de un procesor de texte sau alte aplicatii dotate cu interfete utilizator, o baza de date lucreaza, de regula, „in fundal”. Orice interfata vizibila de catre utilizator este cel mai adesea construita pentru o anumita aplicatie. Functionalitatea bazei de date este asigurata de un program denumit motorul bazei de date. Visul Basic simplifica programarea conectivitatii la o baza de date sau utilizarea controalelor grafice pentru configurarea modului de afisare si transformare a datelor.a10i
Prin notiunea de conectare la o baza de date intelegem stabilirea unui protocol de comunicatie intre aplicatie si motorul care gestioneaza baza de date.
Am ales acest mediu de programare pentru ca este o unealta cu un suport puternic in ceea ce priveste lucrul cu baze de date. Visual Basic permite conectarea nativa la numeroase tipuri de baze de date, cum ar fi: Acces, DBASE III, dBASE IV, dBASE 5.0, FoxPro 2.0, 3.0, Paradox 3.x-5.x, ODBC, etc.
De asemenea, acest mediu de programare contine elemente puternice de dezvoltare a interfetelor utilizator, precum si de utilizare a controalelor ActiveX.
ActiveX este o tehnologie Microsoft care permite utilizarea in cadrul unei aplicatii sau a unor unelte de dezvoltare a unor obiecte dezvoltate de catre o alta aplicatie. Aceste aplicatii sau unelte de dezvoltare se numesc formal OLE Automation Servers.a11i
Pentru conectarea la baza de date vom utiliza un control Microsoft ADO -; ActiveX Data Objects.
ActiveX Data Objects este o tehnologie dezvoltata de Microsoft pentru accesul la baze de date care implementeaza obiecte de tip data connection, data command, recordset si colectii ale acestor obiecte. Aceasta tehnologie permite si realizarea de aplicatii de tip client-server, aplicatii cu baze de date avand la baza tehnologii web sau internet.a11i

Pentru implementarea bazei de date am ales o tehnologia dezvoltata de Microsoft Acces, tehnologie care foloseste acelasi motor de baze de date ca si Visual Basic. Astfel, cu ajutorul Microsoft Acces, specializat pe lucrul cu baze de date, am creat structura bazei de date, iar ca rezultat fizic, baza de date este continuta intr-un singur fisier, cu extensia .mdb.
Aplicatia este centrata pe un formular(engleza form) de tip MDI, Multiple-Document Interface, care este un formular de tip container, mentine mai multe formulare in interiorul sau. Aceste formulare, numite si formulare child, pot sa fie deschise simultan in interiorul containerului, fiecare intr-o fereastra proprie si cu functionalitate proprie.
De asemenea, am utilizat doua controale de tip ActiveX:
VideoSoft VSFlexGrid, care este un control de tip grid, cu o functionalitate foarte bine pusa la punct, si care permite inclusiv legarea grid-ului de o sursa de date prin intermediul ADO, OLEDB sau DAO.
Data Dynamics ActiveReports este un control specializat pe generarea de rapoarte dintr-o sursa de date. Acesta prezinta multiple facilitati, cum ar fi tiparirea raportului la imprimanta, functii de marire-micsorare, exportul raportului in diferite formate.
Din punct de vedere al accesului la baza de date, acesta se face prin intermediul unor interogari SQL care au ca rezultat un recordset(set de inregistrari) sau prin comenzi directe ale instantei unui obiect de tip Connection.
Implementarea efectiva a aplicatiei, este descrisa amanuntit in capitolul 3, Memoriu Justificativ.

3. MEMORIU JUSTIFICATIV

3.1 Proiectarea si implementarea bazei de date

Proiectarea bazei de date am facut-o pe baza etapelor studiate in capitolul anterior, iar implementarea cu ajutorul produsului Microsoft Acces.
Baza de date va fi sub forma unui fisier de tip mdb, si fiecare astfel de fisier va reprezenta un imobil(sau o asociatie de proprietari), la un moment dat pot sa existe mai multe baze de date ale mai multor imobile, iar la rularea aplicatiei utilizatorul va putea sa aleaga imobilul(asociatia de locatari), si implicit baza de date curenta. Am ales aceasta metoda pentru a obtine o mai buna portabilitate a bazei de date.
In urma etapelor de analiza si de proiectare prezentate in capitolul anterior, am realizat structura bazei de date cu ajutorul produsului Microsoft Acces. Astfel, baza de date contine un numar de 11 tabele, 9 sunt cele corespunzatoare entitatilor prezentate in tabelul 1 din subcapitolul 2.3:
- apartament
- consum
- factura
- furnizor
- imobil
- incasare
- luna
- tipCalcul
- tipConsum
Celelalte 2 sunt tabele auxiliare, care nu rezulta in urma analizei, ci au fost introduse ca elemente ajutatoare pentru simplificarea codului. Acestea sunt:
- deIncasat -; se memoreaza temporar rezultate ale calculelor efectuate
- listaRap -; se stocheaza temporar diverse informatii necesare generarii de rapoarte
In figura urmatoare, prezentam structura bazei de date, cu tabelele si legaturile dintre ele. Observam ca fata de atributele prezente in diagrama entitate-relatie, sunt prezente si atributele de identificare de tip chei straine, care se propaga in momentul realizarii legaturilor dintre tabele. De exemplu, in tabela apartament, atributul LunaID, este cheie straina propagata din tabela luna, pentru a se face legatura dintre cele 2 tabele.

Figura 7. Structura bazei de date

In general, am denumit atributele de identificare cu postfixul ID(de la identificator sau index).
Mentionez ca in momentul implementarii bazei de date, prin definirea unei legaturi intre 2 tabele, am stabilit reguli de fortare a integritatii referentiale, adica motorul de baze de date nu va permite stergerea unei inregistrari din baza de date daca aceasta inregistrare are legatura cu o alta inregistrare din tabela cu care se afla in relatie. Aceasta regula se defineste in sensul de la 1 la N, adica nu pot sa sterg inregistrarea de la capatul 1 daca la capatul N exista cel putin o inregistrare care are referinta la aceasta.
Stabilirea acestei reguli se face prin bifarea optiunii „Enforce Referetial Integrity” la editarea unei relatii.
Fiecare fisier de tip mdb aflat in directorul aplicatiei va contine baza de date corespunzatoare unei asociatii de proprietari, exceptie face fisierul template.mdb, care se livreaza o data cu aplicatia, si care contine structura generica a bazei de date, fara a contine date despre o anumita asociatie. Acest fisier este folosit ca si model in momentul in care utilizatorul creeaza prima baza de date a unei asociatii de proprietari sau atunci cand creeaza o asociatie noua. Fiecare fisier nou creat va avea forma: mdb<nume_asociatie>.mdb exemplu: mdbCiortea7.mdb va contine baza de date pentru asociatia de proprietari denumita de catre utilizator Ciortea7
La initializarea aplicatiei, se apeleaza o functie care cauta toate fisierele care incep cu mdb si au extensia mdb din directorul curent si le pune la dispozitia utilizatorului, pentru ca acesta sa poata sa aleaga baza de date cu care va lucra. In acest mod am asigurat o buna portabilitate a informatiei, necesara de exemplu in cazul in care utilizatorul foloseste doua calculatoare pe care are instalata aplicatia, transportul informatiei intre cele 2 puncte de lucru se face prin simpla copiere a fisierului respectiv din directorul aplicatiei.
Numele ultimei baze de date utilizate se memoreaza la iesirea din aplicatie intr-un fisier de configurare, astfel ca utilizatorul nu va trebui sa aleaga de fiecare data cand intra in aplicatie baza de date curenta.

Acest fisier se numeste administrator.ini, se gaseste in directorul aplicatiei si are urmatoarul continut:

Afiseaza Dialog Selectie Asociatie = False
Ultima Asociatie Utilizata = Dorobantilor109

Prima optiune se refera la afisarea formularului de selectie a asociatiei curente la lansarea in executie a aplicatiei si poate sa aiba valorile True(adica afiseaza) sau False(adica nu afiseaza).

3.2 Proiectarea interfetei utilizator

Meniul aplicatiei
Meniul aplicatiei este implementat in formularul container MDI, care se numeste frmMDIPrincipal. si are urmatoarea structura arborescenta:

Figura 8. Structura arborescenta a meniului
Tabelul urmator contine categoriile, subcategoriile meniului precum si functionalitatea acestora.
CATEGORIE SUBCATEGORIE FUNCTIONALITATE
General Alege Luna Curenta Alegerea, schimbarea lunii curente de prelucrare
Alege Asociatie Alegerea, schimbarea asociatiei de proprietari curente
Optiuni Optiuni ale aplicatiei
Iesire Iesire din aplicatie
Actualizari Facturi Lunare Introducerea, modificarea si vizualizarea facturilor lunare de la furnizorii de servicii
Consumuri pe Apartament Introducerea, modificarea si vizualizarea consumurilor lunare pe apartament(apartamentele contorizate)
Incasari Locatari Introducerea, modificarea si vizualizarea incasarilor de la proprietarii de apartamente(locatari)
Afisari Lista Cheltuieli Generarea, vizualizarea si tiparirea listei lunare de cheltuieli cu suma totala de plata si restante
Lista Cheltuieli Defalcate Generarea, vizualizarea si tiparirea listei lunare de cheltuieli cu suma totala de plata, restante si sumele defalcate pe consumuri.
Situatie Apartament Vizualizarea situatiei incasarilor pentru un apartament
Nomenclatoare Apartamente Introducerea, modificarea si vizualizarea datelor despre apartamente
Date Asociatie Introducerea, modificarea si vizualizarea datelor despre asociatia de proprietari(imobil)
Tip Consum Introducerea, modificarea si vizualizarea tipurilor de consum(tipuri de servicii)
Furnizori Introducerea, modificarea si vizualizarea listei de furnizori de servicii
Ajutor Asistenta Documentatia online(help-ul) a aplicatiei
Despre Informatii despre aplicatie

Tabel 7. Structura meniului

In general, functionalitatea meniului, si implicit a aplicatiei, este legata de luna curenta de prelucrare, care se poate modifica din meniul General. Exceptie de la aceasta regula fac subcategoriile aflate in categoria General, subcategoria Situatie Apartament din categoria Afisari, precum si Date Asociatie din categoria Nomenclatoare. Luna curenta de prelucrare este afisata permanent pe bara de titlu a aplicatiei(Title Bar). Prin schimbarea lunii curente de prelucrare folosind subcategoria Alege Luna Curenta, se actualizeaza toate informatiile dependente de luna de prelucrare, inclusiv nomenclatorul de apartamente, furnizori sau tipuri de consum.
In figura 9 este prezentata o mostra referitoare la organizarea meniului. Caracterele care sunt subliniate sunt shortcut-uri pentru utilizarea cu ajutorul tastaturii.

Figura 9. Forma meniului

Pe bara de titlu a aplicatiei este afisata permanent asociatia de proprietari curenta(in figura 9 este Dorobantilor 109), luna curenta si anul curent de prelucrare(in figura 9 este vorba de iunie 2004).
Fiecare subcategorie din meniu, cu exceptia celei de Iesire, are atasat un formular, care se initializeaza si se afiseaza la activarea optiunii respective. Subcategoriile Lista Cheltuieli si Lista Cheltuieli Defalcate au atasat acelasi formular, dar la initializarea acestuia se stabileste intr-o variabila specifica care dintre optiuni a facut apelul.
Toate formularele apartin containerului MDI, cu exceptia subcategoriei Asistenta, care se deschide separat fata de aplicatie.
Mentionez ca am urmarit sa realizez interfata utilizator intr-un mod cat mai simplu si intuitiv, folosind elemente de interfata standard de Windows, astfel incat utilizatorul sa fie deja familiarizat cu o mare parte din aceste elemente.

Formulare

FORMULAR TIP FORMULAR SUBCATEGORIE sau FORMULAR FUNCTIONALITATE frmSelectieLuna dialog modal Alege Luna Curenta Alegerea, schimbarea lunii curente de prelucrare frmAlegeAsociatie dialog modal Alege Asociatie Alegerea, schimbarea asociatiei de proprietari curente frmOptiuni dialog Optiuni Optiuni ale aplicatiei frmMsgBoxRom dialog modal Utilizat pentru rezolvarea unor optiuni de tip DA/NU frmFacturi MDI child Facturi Lunare Introducerea, modificarea si vizualizarea facturilor lunare de la furnizorii de servicii frmConsum MDI child Consumuri pe Apartament Introducerea, modificarea si vizualizarea consumurilor lunare pe apartament(ap. contorizate) frmIncasare MDI child Incasari Locatari Introducerea, modificarea si vizualizarea incasarilor de la proprietarii de apartamente(locatari) frmListaCheltuieli MDI child Lista Cheltuieli
Lista Cheltuieli Defalcate Generarea, vizualizarea si tiparirea listei lunare de cheltuieli cu suma totala de plata, restante si sumele defalcate pe consumuri. frmSituatieAp MDI child Situatie Apartament Vizualizarea situatiei incasarilor pentru un apartament frmApartamente MDI child Apartamente Introducerea, modificarea si vizualizarea datelor despre apartamente frmDateAsociatie MDI child Date Asociatie Introducerea, modificarea si vizualizarea datelor despre asociatia de proprietari frmTipConsum MDI child Tip Consum Introducerea, modificarea si vizualizarea tipurilor de consum(tipuri de servicii) frmFurnizori MDI child Furnizori Introducerea, modificarea si vizualizarea listei de furnizori de servicii frmSelectieData dialog modal frmIncasare Selectarea datei frmRECSelection dialog modal frmSituatieAp Alegerea unui anumit apartament dintr-o lista frmDespre dialog Despre Informatii despre aplicatie

Tabel 8. Lista Formularelor
Formularele de tip dialog modal sunt formulare care odata afisate, vor ramane afisate peste toate formularele(ferestrele) deschise deja, interzicand accesul la acestea pana la rezolvarea dialogului, de cele mai multe ori apasarea pe un buton de pe formularul dialog.
Observam in tabelul 8 ca unele formulare, cum ar fi frmSelectieData sau frmMsgBoxRom nu sunt direct afisabile dintr-o subcategorie a meniului. Aceste formulare sunt utilizate de catre alte formulare sau sunt afisate direct, fara a avea un formular parent.
Formulare cu regim special sunt frmAlegeAsociatie, si frmSelectieLuna, ambele sunt de tipul dialog modal.
Formularul frmAlegeAsociatie este afisat la prima intrare in aplicatie sau daca este bifata optiunea respectiva, se ocupa cu selectarea asociatiei de proprietari curente

Figura 10. Formularul frmAlegeAsociatie
Asa cum am precizat deja, acest formular cauta toate fisierele a caror denumire incepe cu mdb si au extensia mdb din directorul aplicatiei si le adauga in controlul de tip lista care se vede si in figura 9. Secventa de cod care face acest lucru este urmatoarea: fisier = Dir(appPath & "\" & "mdb*.mdb")
If fisier <> "" Then comboAsociatie.AddItem (mid(fisier, 4, Len(fisier) - 7))
End If
While fisier <> "" fisier = Dir
If fisier <> "" Then comboAsociatie.AddItem (mid(fisier, 4, Len(fisier) - 7))
End If
Wend

Formularul frmSelectieLuna are de asemenea un regim special, acesta se afiseaza intotdeauna la pornirea aplicatiei precum si la apelarea subcategoriei Alege Luna din meniu. Din punct de vedere functional, acesta se ocupa cu selectarea lunii curente si a anului curent de prelucrare, prin interogarea bazei de date referitor la inregistrarile din tabelul luna.

Figura 11. Formularul de selectie a lunii de prelucrare
Dupa cum se observa in figura de mai sus, formularul incarca intr-un control de tip lista lunile de prelucrare gasite in tabela luna. Utilizatorul are posibilitatea de a selecta una din lunile de prelucrare existente deja sau poate sa creeze o luna de prelucrare noua.
Secventa de cod care ruleaza in momentul adaugarii unei luni noi este urmatoarea: anul = Val(InputBox("Introduceti anul", "Anul", Year(Date)))
If anul < 2000 Or anul > 2100 Then Exit Sub luna = Val(InputBox("Introduceti luna", "Luna", Month(Date)))
If luna < 1 Or luna > 12 Then Exit Sub

If GetFieldFromTable("lunaID", "luna", "anul=" & anul & " and luna=" & luna) = "" Then idLastLuna = GetMaxMinFieldTable("max", "lunaID", "luna") conexiune.Execute "INSERT INTO luna (anul,luna) VALUES ("&anul&","&luna& ")"
If Not IsNull(idLastLuna) Then idLuna = GetDBIdentity
OpenRS rs, "SELECT * FROM apartament WHERE lunaID=" & idLastLuna
If rs.RecordCount <> 0 Then
While Not rs.EOF conexiune.Execute "INSERT INTO apartament " _
&"(lunaID,NrApartament,Proprietar,NrPersoane,NrCamere,Suprafata) " _
&"VALUES("&idLuna&","&rs("NrApartament")&",'"&rs("Proprietar")&"'," _
&rs("NrPersoane")& "," & rs("NrCamere") & "," & rs("Suprafata") & ")" rs.MoveNext
Wend
End If
End If
Else
MsgBox "Aceasta luna este deja existenta in baza de date", vbExclamation
End If

In aceasta secventa de cod, pentru creearea unei luni noi de prelucrare se adauga o inregistrare in tabela luna si apoi se copiaza structura apartamentelor din luna cea mai recenta gasita in aceasta tabela.
Un alt formular cu regim special pe care il vom prezenta este frmRECSelection, care este afisat la apasarea butonului Cauta Ap(Cauta Apartament) din toolbar-ul formularului frmSituatieAp. Este un formular de tip dialog modal.

Figura 12. Formularul frmRECSelection

Acest formular cauta toate inregistrarile din tabela apartament chiar daca nu sunt pentru luna curenta de prelucrare. Dupa selectia unuia dintre apartamente, in formularul frmSituatieAp se vor afisa toate incasarile facute pentru apartamentul selectat.
Proiectarea acestui formular este flexibila in sensul ca i se transmite printr-o variabila un sir care reprezinta o interogare SQL: frmRECSelection.lblQueryMaster = "SELECT apartamentID, nrApartament, " _
& "proprietar FROM apartament WHERE lunaID=" & ID_LUNA& " ORDER BY nrApartament"

Un alt formular folosit de catre frmIncasare este frmSelectieData care este un dialog modal si contine un control de tip Microsoft Acces Calendar Control, utilizat pentru stabilirea datei la care s-a emis chitanta pentru o incasare.

Nu vom discuta separat fiecare formular de tip MDI child, pentru ca din punct de vedere al interfetei utilizator sunt similare, diferentele sunt minore. De aceea, vom exemplifica functionalitatea unui astfel de formular, si anume frmApartamente care se ocupa de evidenta apartamentelor din imobil. Observam in figura 12 ca formularul este centrat pe un control de tip grid, care asa cum am specificat este implementat cu controlul VSFlexGrid.
Editarea se face in interiorul grid-ului, prin scrierea informatiei direct de la tastatura sau in unele cazuri prin selectarea unei celule a gridului se deschide un combobox.
In partea de deasupra gridului exista un toolbar, unde exista butoane pentru functiile de Salvare, Linie Noua si Stergere Linie.

Figura 13. Formularul frmApartamente
Controlul de grid este legat de baza de date direct, prin secventa:
Dim rs As New ADODB.Recordset
OpenRS rs,"SELECT * FROM apartament WHERE LunaID="&ID_LUNA&" ORDER BY nrApartament"
Set grNom.DataSource = rs grNom.DataMode = flexDMBoundBatch unde
OpenRS este o functie care deschide un recordset pe baza unei interogari SQL si grNom este instanta obiectului de grid

Modificarile pe care utilizatorul le face in grid se actualizeaza efectiv in baza de date numai la apasarea butonului Salveaza prin apelarea functiei:
Public Sub DocSave() rs.UpdateBatch adAffectAll trebuieSalvat = False
End Sub

3.3 Implementare

Din punct de vedere al codului, aplicatia este compusa dintr-un modul principal, aflat in fisierul principal.bas. In acest modul se afla declaratiile variabilelor globale, definitiile functiilor publice utilizate precum si rutina Main(), care se executa la rularea aplicatiei.
Functionalitatea fiecarui formular este definita in interiorul formularului, in functii care trateaza evenimentele de interfata ale obiectelor, cum ar fi initializarea formularului(eveniment de tip Form_Load) apasarea unei taste, editarea unei celule a gridului, apasarea unui buton din toolbar, selectarea unui element dintr-un combo, etc.
Din punct de vedere al accesului la baza de date din cod, am utilizat 2 metode: a. operatii directe asupra bazei de date cu ajutorul metodei Execute a instantei numita conexiune a obiectului Connection. exemple: actualizarea unei inregistrari conexiune.Execute "UPDATE imobil SET" _
& " denumire='" & txtDenumire & "'" _
& " ,adresa='" & txtAdresa & "'" _
& " ,localitate='" & txtLocalitate & "'" _
& " ,Judet='" & txtJudet & "'" _
& " ,numeAdministrator='" & txtNumeAdministrator & "'" _
& " WHERE imobilid=" & imobilID & ""

creearea unei tabele: conexiune.Execute "CREATE TABLE listaRap" adaugarea unor campuri intr-o tabela: conexiune.Execute "ALTER TABLE listaRap ADD COLUMN ID LONG" conexiune.Execute "ALTER TABLE listaRap ADD COLUMN Ap TEXT(5)" conexiune.Execute "ALTER TABLE listaRap ADD COLUMN Proprietar TEXT(100)" conexiune.Execute "ALTER TABLE listaRap ADD COLUMN NrPers TEXT(3)" conexiune.Execute "ALTER TABLE listaRap ADD COLUMN Suprafata LONG"

b. interogari SQL ale bazei de date si obtinerea unui recordset cu rezultatul interogarii exemplu:
OpenRS rs,"SELECT Sum(incasare.Suma) FROM apartament INNER JOIN incasare" _
& " ON apartament.apartamentID = incasare.ApartamentID where " _
& " (((apartament.LunaID) < " & idLuna & ")) GROUP BY" _
& " apartament.NrApartame