Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Licenta

Descărcați ca doc, pdf sau txt
Descărcați ca doc, pdf sau txt
Sunteți pe pagina 1din 58

CUPRINS

Întroducere.................................................................................................9
1 Analiza domeniului de cercetare.........................................................11
1.1 Determinarea sarcinii pentru proiectul de diplomă..............................................................11
1.1.1 Componentele sistemului informațional..........................................................................13
1.1.2 Clasificarea sistemelor informațional..............................................................................15
1.1.3 Ciclul de viaţă a unui sistem informațional.....................................................................17
1.1.4 Ciclul prelucrării datelor pentru sistemul informatic.......................................................18
1.1.5 Sistemele informatice de gestiune....................................................................................19
1.2 Caracteristici ale sistemului informaţional..........................................................................20
1.3 Obiective ale sistemului informaţional................................................................................21
1.4 Funcţiile sistemului informaţional.......................................................................................23
1.5 Metodologii de realizare a sistemelor informatice..............................................................24
1.6 Analiza sistemului existent şi definirea cerinţelor noului sistem........................................26
1.6.1 Studiul sistemului informaţional existent........................................................................27
1.6.2 Determinarea cerinţelor sistemului..................................................................................28
2 Modelarea sistemului informaţional de evidență a cazării în cămin ...30
2.1 Nuanţele specifice în vederea eficienţii modelării produselor soft..........................................30
2.3 Diagrama de interacțiune.........................................................................................................37
2.4 Diagramele de activitate a sistemului......................................................................................40
2.5 Diagramele de clase a sistemului............................................................................................42
2.6 Diagrama componentelor.........................................................................................................44
3 Documentarea produsului realizat......................................................45
3.1 Platforma .Net Framework.......................................................................................................45
3.2 Limbajul C#.............................................................................................................................46
3.2 Descrierea aplicaţiei.................................................................................................................48
4 Argumentarea economică a proiectului..............................................52
4.1 Descrierea SI............................................................................................................................52
4.2 Plan calendaristic.....................................................................................................................52
4.3 Determinarea costului proiectului............................................................................................54
Bibliografia...............................................................................................60
Anexa A.....................................................................................................61
Codul sursă................................................................................................61

8
Întroducere

Astăzi, activitatea omului nici nu poate fi imaginată fără de utilizarea calculatorului, iar
introducerea sistemelor informaţionale în diferite domenii de activitate a oamenilor se examinează ca o
direcţie prioritară a progresului tehnic, cu scopul de a susţine şi de a intensifica procesul de activitate a
oamenilor. Actual sistemele informaţionale sunt parte componentă a instituţiilor de administrare,
producere, realizare, cercetări ştiinţifice, etc.
Folosirea calculatorului la rezolvarea unui grup omogen de lucrări sau probleme ale beneficiarului,
constituie o aplicaţie informatică, cu observaţia că un sistem informatic poate cuprinde mai multe aplicaţii
informatice. Sfera de cuprindere a unei aplicaţii, este determinată de omogenitatea funcţională a
prelucrărilor realizate şi de delimitarea dintre procesele formalizabile şi neformalizabile.
La nivelul unei firme sistemul informaţional asigură legătura între sistemul decizional şi sistemul
operaţional, în acest scop presupune desfăşurarea unor activităţi. Iar dacă pentru desfăşurarea acestor
activităţi se utilizează cu preponderenţă calculatorul, sistemul informaţional devine sistem informatic.
Preocupări referitoare la operativitatea deciziei manageriale şi, în acest context, perfecţionarea
sistemelor informatice nu este o noutate. Ca urmare a creşterii mărimii întreprinderilor şi a complexităţii
proceselor de conducere, a apărut necesitatea îmbunătăţirii, raţionalizării şi perfecţionării sistemelor
informatice, în acest context, ideea care s-a degajat a fost aceea că un sistem informatic, fără a fi
exhaustiv, trebuie sa răspundă cerinţei de raţionalizare a informaţiei în vederea creşterii calităţii
procesului decizional. În condiţiile în care, managerii întreprinderilor comerciale se află permanent în faţa
situaţiei de a lua decizii în condiţii de risc, se pun în faţă proiectanţii de sisteme informaţionale care au
obligaţia de a satisface două condiţii de bază:
 asigurarea unei prelucrări corecte a informaţiei din domeniile care ţin de certitudine (cele
referitoare la organizarea proceselor interne de stocare, transport si comercializare);
 oferirea unor estimaţii cât mai apropiate de evoluţia reală pentru fenomenele care se găsesc sub
incidenţa riscului (dinamica pieţei, cote de piaţă, evoluţia proceselor inflaţioniste, etc.).
Într-un sistem informatic pot intra: calculatoare, sisteme de transmisie a datelor, alte componente
hardware, software-ul, datele prelucrate, personalul ce exploatează tehnica de calcul, teoriile ce stau la
baza algoritmilor de prelucrare, etc.
În lucrarea de faţă este proiectat un sistem informaţional pentru gestiunea serviciilor hoteliere. De
asemenea s-a creat o bază de date şi un instrument eficient de gestionare a ei. Pe parcursul elaborării s-a
ţinut cont de metodele moderne de analiză şi proiectare.
Astăzi teoria bazelor de date relaţionale este un fundament real pentru construirea sistemelor
informatice eficiente. Modelul relaţional este caracterizat printr-un mare avantaj, şi anume: „utilizatorii
9
sunt protejaţi de cunoaşterea reprezentării interne a datelor. Activităţile utilizatorilor la terminale şi
majoritatea aplicaţiilor trebuie să rămână intacte, dacă reprezentarea internă este modificată...”[1]. Din
această cauză, în lucrare, la proiectarea bazei de date s-a utilizat modelul relaţional şi baza de date
proiectată este relaţională.
Dintre mulţimea sistemelor de gestiune a bazelor de date relaţionale elaborate pentru calculatoarele
personale s-a utilizat MS Access, iar ca limbaj de programare C# şi tehnologiile .Net.

10
1 Analiza domeniului de cercetare

Sistemele informatice de gestiune reprezintă ansamblul informaţiilor utilizate în cadrul


organizaţiilor, a mijloacelor şi procedurilor de identificare, culegere, stocare şi prelucrare a informaţiilor.
Sistemele informatice de gestiune (SIG) presupun definirea: domeniilor de gestiune, datelor,
modelelor, regulilor de gestiune.
Domeniile de gestiune corespund activităţilor de cercetare-dezvoltare, comercială, de producţie, de
resurse umane, financiar-contabile luând în considerare interacţiunile dintre ele.
Abordarea acestor domenii se realizează într-o viziune ierarhică conducând la identificarea nivelului
tranzacţional, operaţional, tactic si strategic. Iar modelele de gestiune regrupează practicile caracteristice
unor domenii cum ar fi cel al marketingului, al producţiei, comercial sau financiar-contabil.
Regulile de gestiune permit prelucrarea datelor şi utilizarea informaţiilor în conformitate cu
obiectivele sistemului.
Exemple de reguli:
 aprovizionarea se realizează când stocul efectiv scade sub stocul normat;
 gestiunea stocurilor se realizează conform metodei FIFO (first in first out) sau LIFO (last
in first out);
 pentru produsele de calitatea a doua se acordă o reducere de 10%.

Sistemul informatic de gestiune asigură obţinerea şi furnizarea informaţiei solicitate de utilizator,


folosind mijloacele tehnologiei informaţionale, pentru fundamentarea deciziilor privind un anumit
domeniu din cadrul firmei. Se caracterizează prin aplicarea principiului introducerii unice a datelor şi
prelucrării multiple a acestora în concordanţă cu nevoile informaţionale specifice fiecărui utilizator [1].

1.1 Determinarea sarcinii pentru proiectul de diplomă

Un sistem reprezintă un ansamblu de elemente (componente) interdependente între care se stabileşte


o interacţiune dinamică, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv [2].
Conform teoriei sistemelor orice organism economic este un sistem.
În orice organizaţie se disting trei componente:
 sistemul de conducere sau de decizie;
 sistemul informaţional;
 sistemul operaţional.

11
Sistemul informaţional cuprinde ansamblul informaţiilor interne şi externe utilizate în cadrul
organizaţiei precum şi datele care au stat la baza obţinerii lor, procedurile şi tehnicile de obţinere a
informaţiilor (plecând de la datele primare) şi de difuzare a informaţiilor, precum şi personalul implicat în
culegerea, transmiterea, stocarea şi prelucrarea datelor.
Sistemul informaţional are două componente:
 componenta pentru stocarea (memorarea informaţiilor);
 componenta pentru prelucrarea informaţiilor.

Orice organizaţie interacţionează cu alte organizaţii externe ei primind informaţii din exterior şi
furnizând informaţii către lumea exterioară.
Funcţiile unui sistem informaţional sunt:
 să colecteze informaţii din sistemele operaţional şi decizional precum şi informaţiile ce
provin din mediul extern;
 să memoreze aceste informaţii precum şi informaţii rezultate din prelucrarea lor;
 să asigure accesul la memorie în vederea comunicării informaţiilor stocate;
 să prelucreze informaţiile la cererea sistemului operaţional şi a sistemului de conducere.

Noţiunea de sistem informatic este legată de informatizarea activităţii organizaţiei, deci folosirea
echipamentelor hardware şi a produselor software pentru organizarea şi administrarea informaţiilor.
Utilizarea calculatoarelor în cadrul sistemului informaţional (SI) al unei organizaţii conduce la definirea
componentei Sistem Informaţional Automatizat (SIA) – care cuprinde numai lucrările realizate cu ajutorul
calculatoarelor. Relaţia SI – SIA [2] este reprezentată în figura 1.1

Sistem manual Om Fişiere manuale Reguli şi


proceduri scrise

Sistem Calculator Fişiere Programe şi


automatizat informatice structuri de date
informatice

Figura 1.1 – Relaţia SI-SIA

Definiţie. Un sistem informatic este un sistem utilizator-calculator integrat, care furnizează


informaţii pentru a sprijini activităţile de la nivel operaţional şi activităţile de management într-o
organizaţie, utilizând echipamente hardware şi produse software, proceduri manuale, o bază de date şi
modele matematice pentru analiză, planificare, control şi luarea deciziilor [2].
12
Elaborarea sistemelor informatice impune modelarea sistemului informaţional al organizaţiei cu
ajutorul unui formalism prin care să poată fi reprezentată cât mai sugestiv şi fidel realitatea din cadrul
sistemului informaţional.
Sistemele informatice complexe pot fi descompuse în subsisteme, care la rândul lor pot fi
descompuse în aplicaţii destinate unor categorii de utilizatori, aplicaţii care la rândul lor pot fi constituite
din unul sau mai multe programe scrise în diverse limbaje a sistemului informatic reprezentată în fig. 1.2
Sistem Informatic

Subsistem 1 Subsistem 2 … Subsistem n

Aplicaţia 2.1 … Aplicaţia 2.m

Program 2.m.1 … Program 2.m.k

Figura 1.2 – Sistem informatic, subsisteme, aplicaţii, programe

Pentru organizaţii de complexitate mică, informatizarea poate însemna realizarea unei singure
aplicaţii informatice referită de asemenea ca sistem informatic. Sistemele, subsistemele şi aplicaţiile
informatice sunt produse informatice numite şi produse software.
Un produs informatic este constituit din programe care accesează baza de date şi din documentaţia
necesară pentru utilizarea şi întreţinerea programelor. Acestea se realizează în baza unor metodologii şi
necesită parcurgerea unor etape începând cu specificarea cerinţelor şi terminând cu implementarea,
exploatarea şi întreţinerea lor.
Sistemul informatic economic este un ansamblu structurat de elemente intercorelate funcţional
pentru automatizarea procesului de obţinere a informaţiilor şi pentru fundamentarea deciziilor. Sistemul
informatic este inclus în sfera sistemului informaţional atâta vreme cât în cadrul sistemului informaţional
vor exista o serie de activităţi care nu vor putea fi automatizate [3].

1.1.1 Componentele sistemului informațional

Un sistem informatic este compus din mai multe elemente care interacţionează între ele.
Aceste elemente sunt:
 baza informaţională;
 baza tehnică;
13
 sistemul de programe;
 baza ştiinţifică şi metodologică;
 factorul uman (resursele umane);
 cadrul organizatoric.

Baza informaţională cuprinde:


 datele supuse prelucrării;
 fluxurile informaţionale;
 sistemele şi nomenclatoarele de coduri.

Baza tehnică este constituită din totalitatea mijloacelor tehnice de culegere, transmitere, stocare şi
prelucrare a datelor, locul central revenind calculatoarelor electronice. Sistemul de programe cuprinde
totalitatea programelor utilizate pentru funcţionarea sistemului informatic în concordanţă cu funcţiunile şi
obiectivele stabilite. Sunt avute în vedere atât programele de bază (software de bază) cât şi programele
aplicative (software de aplicaţie).
Baza ştiinţifică şi metodologică este constituită din:
 algoritmi;
 formule;
 modele;
 tehnici de realizare a sistemelor informatice.

Resursele umane constau din:


 personalul de specialitate: analişti, programatori, ingineri de sistem, analişti-programatori
ajutori, operatori, etc.;
 beneficiarii sistemului.

Cadrul organizatoric este cel specificat în regulamentul de organizare şi funcţionare (ROF) al


unităţii în care va fi utilizat sistemul informatic.
La realizarea şi utilizarea unui sistem informatic trebuie avute în vedere reţelele, echipamentele,
produsele software de bază, produsele software de aplicaţie.
Reţelele:
a) după aria de întindere geografică:
1) locale – LAN (Local Area Network), la nivelul unei organizaţii;
2) metropolitane – MAN (Metropolitan Area Network), la nivel de oraş, localitate;

14
3) de mare întindere – WAN (World Area Network), la nivel de Ţară sau Judeţ.
b) după accesibilitate:
1) internet (reţeaua Web) – o colecţie mondială de reţele interconectate;
2) intranet – un sit Web sau un grup de sit-uri care aparţin unei organizaţii, accesibil numai
pentru membrii acesteia;
3) extranet – o reţea intranet care este parţial accesibilă utilizatorilor externi autorizaţi.

Echipamente:
 echipamente de calcul: calculatoare, staţii grafice, pentru servere de reţea, servere de baze
de date, staţii de lucru (clienţi, utilizatori), UPS-uri;
 echipamente de comunicaţie: router-e, hub-uri, modem-uri, switch-uri.

Produse software:
 sisteme de operare pentru serverul de reţea (UNIX, Windows NT server, Windows 2000,
Novell) şi pentru staţiile de lucru sau clienţi (Windows 95, Windows 98, Windows NT
work station, Windows 2000);
 sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft, MySQL,
ACCESS, FoxPro etc.);
 sisteme GIS (Geographical Information System) – utilizate pentru realizarea aplicaţiilor
din domeniul cadastrului (stocarea şi prelucrarea datelor spaţiale );
 limbaje (medii) de programare – utilizate pentru realizare software de aplicaţie;
 produse program ce constituie aplicaţiile şi subsistemele sistemului informatic.

1.1.2 Clasificarea sistemelor informațional


Sistemele informatice se clasifică după mai multe criterii:
a) în funcţie de domeniul de utilizare, sistemele informatice pot fi pentru:
1) conducerea activităţilor economico-sociale;
2) conducerea proceselor tehnologice;
3) cercetare ştiinţifică şi proiectare tehnologică;
4) activităţi speciale;
b) în funcţie de nivelul ierarhic ocupat de sistemul economic în structura organizatorică a
societăţii, conform căruia există sisteme informatice:
1) pentru conducerea activităţii la nivelul unităţilor economice;
2) pentru conducerea activităţii la nivelul organizaţiilor economico-sociale cu structură;

15
3) de grup;
4) sisteme informatice teritoriale;
5) pentru conducerea ramurilor, subramurilor şi activităţilor la nivelul economiei;
6) naţionale;
7) sisteme informatice funcţionale generale;
c) în funcţie de elementul supus analizei:
1) sisteme informatice orientate spre funcţii;
2) sisteme informatice orientate spre proces;
3) sisteme informatice orientate spre date;
4) sisteme informatice orientate spre obiecte;
5) sisteme informatice orientate spre cunoştinţe;
d) după modul de organizare a datelor:
1) sisteme bazate pe fişiere;
2) sisteme bazate pe tehnica bazelor de date: ierarhice, reţea, relaţionale, orientate-obiect;
3) sisteme mixte;
e) după metoda folosită în analiza şi proiectarea sistemelor [4]:
1) sisteme dezvoltate după metoda sistemelor;
2) sisteme dezvoltate după metoda clasică a ciclului de viaţă;
3) sisteme dezvoltate după metoda structurată;
4) sisteme dezvoltate după metoda orientată-obiect;
5) sisteme dezvoltate după metoda rapidă(RAD);
6) sisteme dezvoltate după metoda echipelor mixte(JAD);
7) sisteme dezvoltate după metoda prototipurilor;
f) după gradul de centralizare:
1) sisteme centralizate;
2) sisteme descentralizate;
g) după gradul de dispersie a resurselor sistemului informatic:
1) sisteme informatice locale (bazate pe reţea locală, staţii de lucru);
2) sisteme informatice distribuite (date distribuite);
h) după gradul de automatizare a activităţilor de analiză şi proiectare [4]:
1) sisteme informatice dezvoltate pe baza analizei şi proiectării clasice;
2) sisteme informatice analizate cu instrumente automate şi proiectate clasic;
3) sisteme informatice bazate pe instrumente diverse de automatizare a analizei şi
proiectării;
4) sisteme informatice dezvoltate cu instrumente de tip CASE;

16
1.1.3 Ciclul de viaţă a unui sistem informațional

Sistemele informatice (SI) se caracterizează printr-un ciclu de viaţă care începe cu decizia realizării
unui nou SI care să corespundă mai bine noilor cerinţe ale utilizatorilor şi se încheie cu decizia de
înlocuire a SI existent cu unul nou, mai performant. Ciclul de viaţă se desfăşoară pe etape în cadrul
fiecăreia fiind definite faze şi activităţi specifice [2].
Încă de la început facem menţiunea că, indiferent de etapa istorică sau metodologică, sistemele sunt
abordate prin prisma ciclului lor de viaţă. Ele apar se dezvoltă, descresc şi pier, sau printr-un nou ciclu, se
perfecţionează, dând naştere unei alte versiuni sau chiar unui nou sistem. Mutaţiile din domeniul
tehnologiei informaţionale şi al metodelor de abordare a sistemelor s-au reflectat şi în ciclul de viaţă al
dezvoltării sistemelor, fie prin schimbarea etapelor acestuia, fie prin modificarea opticii de parcurgere a
lor. Spre exemplu, odată cu abordarea orientată-obiect a sistemelor, s-au lansat şi noi modele ale ciclului
de viaţă .
Prin parcurgerea materialelor de specialitate, se poate constata că numărul fazelor/etapelor variază
de la trei (de exemplu analiza, proiectarea, implementarea) la peste douăzeci.
Există mai multe modele ale ciclului de viaţă, multe dintre ele cunoscând o evoluţie în timp. Spre
exemplu, modelul cascadă, conform figurii 1.3, prevede parcurgerea mai multor etape ale ciclului de viaţă
care se derulează secvenţial fiind însă permisă la nevoie revenirea la etapa parcursă anterior în vederea
îndepărtării neajunsurilor identificate în etapele superioare ale ciclului de viaţă.
Analiza şi definirea cerinţelor

Analiza şi definirea cerinţelor

Analiza şi definirea cerinţelor

Analiza şi definirea cerinţelor

Analiza şi definirea cerinţelor

Figura 1.3 – Etapele ciclului de viaţă a unui sistem informatic în modelul cascadă.

Analiza şi definirea cerinţelor. Sunt definite scopurile, serviciile şi restricţiile pe care trebuie să le
îndeplinească sistemul informatic, prezentate într-o manieră încât să poată fi înţelese atât de către
utilizatorii sistemului cât şi de personalul de proiectare.
Proiectarea sistemului şi software-ului. Stabilirea cerinţelor pentru hardware şi software şi
elaborarea arhitecturii generale a sistemului. Funcţiile sistemului informaţional vor fi reprezentate astfel
încât să poată fi transformate în unul sau mai multe programe executabile.

17
Implementarea şi testarea unităţilor de program. Proiectarea software-ului din etapa anterioară
este transpusă într-o mulţime de programe sau module program şi verificarea faptului că fiecare program
sau modul satisface specificaţia sa.
Integrarea şi testarea sistemului. Integrarea şi testarea programelor şi modulelor program ca un
sistem complet pentru a ne asigura că cerinţele informaţionale sunt satisfăcute. După testare sistemul este
livrat beneficiarului.
Exploatarea şi întreţinerea sistemului. Este faza în care sistemul informatic este efectiv utilizat de
către beneficiar şi în care sunt descoperite şi rezolvate eventuale erori de proiectare şi programare şi
omisiuni în cerinţele informaţionale iniţiale.

1.1.4 Ciclul prelucrării datelor pentru sistemul informatic

Operaţiunile care se execută asupra datelor, din momentul apariţiei lor, pentru a genera informaţii
semnificative şi relevante sunt referite la un loc prin noţiunea de ciclul prelucrării datelor. Ciclul cuprinde
cinci faze: culegerea datelor, pregătirea datelor, prelucrarea datelor, întreţinerea fişierelor şi obţinerea
informaţiilor de ieşire.
Faza de culegere a datelor cuprinde două activităţi fundamentale:
 observarea mediului care generează datele, fie printr-un observator uman, fie prin diverse
echipamente;
 înregistrarea datelor, fie prin scrierea lor în documentele sursă, fie prin captarea lor sub
diferite forme cu ajutorul unor echipamente speciale.

Pregătirea datelor constă într-un număr de operaţii executate asupra datelor pentru a facilita
prelucrarea lor ulterioară. Ele sunt:
 clasificarea datelor, care implică atribuirea de coduri de identificare (simbol cont, cod
secţie, etc.), astfel încât datele să fie incluse în submulţimile corespunzătoare;
 gruparea datelor, adică acumularea intrărilor similare, pentru a fi prelucrate în grup;
 verificarea datelor cuprinde o mare varietate de proceduri pentru controlul corectitudinii
datelor, înainte ca ele să fie prelucrate;
 sortarea datelor, prin care grupurile de date sunt aranjate în loturi de înregistrări, după
criterii de ordonare numerică, alfabetică, alfanumerică sau de timp;
 cuplarea a două sau mai multe loturi de înregistrări într-unul singur;
 transmiterea datelor de la un punct la altul;

18
 transcrierea datelor dintr-o formă în alta, astfel încât să se efectueze trecerea de la scrierea
de mână la cea tipizată sau de la documentele scrise la mediile specifice.

Prelucrarea datelor, poate să includă activităţi, cum sunt:


 calculaţiile cuprind unele forme de tratare matematică a datelor;
 compararea supune unei examinări simultane două sau mai multe tipuri de date între care
există o legătură logică (ex. soldul final şi cel final);
 sintetizarea este o activitate importantă prin care se comasează informaţiile;
 filtrarea este o altă operaţiune prin care se extrag datele ce vor fi supuse prelucrărilor
următoare;
 restaurarea, prin care sunt aduse datele din memorie într-o formă accesibilă omului, pentru
prelucrarea umană în continuare, sau într-o formă prelucrabilă tot pe calculator.

Faza de întreţinere a fişierelor conţine activităţile:


 memorarea (stocarea) datelor în vederea utilizării lor viitoare;
 actualizarea datelor memorate astfel încât să surprindă cele mai recente evenimente;
 indexarea datelor pentru a înlesni o uşoară regăsire a lor;
 protecţia datelor memorate, care cuprinde o mare varietate de proceduri şi tehnici pentru
prevenirea distrugerii lor sau a accesului neautorizat.

Obţinerea informaţiilor de ieşire este ultima fază a ciclului de prelucrare a datelor, acestea pot fi
regăsite în una din formele următoare:
 documente;
 rapoarte;
 răspunsuri la întrebări.

1.1.5 Sistemele informatice de gestiune

Sistemul informatic de gestiune implică următoarele patru componente interdependente: domeniile


de gestiune, datele, modelele, regulile de gestiune [2].
Sistemul informatic de gestiune asigură obţinerea informaţiei solicitate de utilizator, folosind
mijloacele tehnologiei informaţiei (TI).

19
Sistemele informatice de gestiune sunt sisteme integrate. Se caracterizează printr-o introducere
unică a datelor, preluate din documentele primare care actualizează o bază de date unică a contabilităţii
care va fi ulterior prelucrată pentru obţinerea situaţiilor specifice fiecărui utilizator [2].
Sistemul informatic de gestiune reuneşte subsisteme informatice specializate pe domenii între care
se manifestă interacţiuni specifice. Fiecare subsistem definit grupează procese informaţionale omogene,
specifice unei anumite arii de interes.
La nivelul fiecărui subsistem vor fi definite aplicaţii distincte corespunzătoare acestor activităţi. La
rândul lor aplicaţiile sunt formate din proceduri descompunându-se în module reprezentând secvenţe de
cod prin care se realizează o funcţie independentă din cadrul procedurii.

1.2 Caracteristici ale sistemului informaţional

Orice sistem informaţional intelectual are unele caracteristici principale, care se bazează pe
particularităţile de interacţiune comunicativă a omului cu sistemul, şi anume:
- accesibilitatea se determină în dependenţă de numărul de utilizatori de diferite tipuri;
universalitatea sistemului, gradul de deservire concomitentă a sistemului;
- comoditatea utilizatorilor în activitatea cu sistemul informaţional (interpelări, analiză, control)
care se determină de gradul de îndestulare a necesităţilor în procesul de comunicare cu
mijloacele tehnice, programice şi alte tehnologii informaţionale; minimizarea timpului de reacţie
a sistemului la comunicarea utilizatorului; reacţia prietenoasă a sistemului la acţiunile nereuşite
ale utilizatorului;
- calitatea funcţionării sistemului informaţional se determină ca înţelegerea corectă şi realizarea
scopului utilizatorului în procesul activităţii;
- operativitatea sistemului informaţional, care se determină în dependenţă de timpul sumar,
consumat în procesul interacţiunii, pregătire şi finisare a lui;
- adaptabilitatea sistemului informaţional se determină de posibilităţile de a schimba structura
internă a sistemului, adaptarea lui la posibilităţile omului-utilizator, precum şi schimbarea
caracteristicilor sistemului care sunt determinate de domeniul pentru care a fost preconizat;
- siguranţa sistemului în urma interacţiunii cu utilizatorii este una din caracteristicile importante,
care se apreciază ţinând cont de dezvoltarea procesului informaţional la diferite etape: pregătirea
de interacţiune; transmiterea şi sesizarea informaţiei; interpretarea, realizarea diferitor acţiuni,
înţelegerea şi interpretarea de către utilizator a acţiunilor sistemului intelectual;
- securitatea sistemului informaţional se caracterizează de gradul de apărare a sistemului de accesul
nesancţionat a utilizatorului la diferite categorii şi niveluri de informaţii.

20
1.3 Obiective ale sistemului informaţional

După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea, transmiterea,
stocarea şi prelucrarea automată a datelor cu ajutorul mijloacelor electronice de calcul, în scopul
satisfacerii diferitelor nivele de conducere cu informaţii necesare luării deciziilor, în condiţii de eficienţă
economică sporită.
În aceste condiţii, necesitatea acută de informare trebuie satisfăcută ţinând seama de o serie de
cerinţe prin care să se asigure: minimizarea costului procesului de prelucrare a datelor; creşterea vitezei
de răspuns la întrebările solicitate de utilizatori; adaptarea facilă a sistemului informatic la evoluţia în
timp a sistemului informaţional din care face parte; posibilitatea răspunsului la anumite întrebări
neanticipate de către proiectanţii de sistem; posibilitatea folosirii sistemului de informare dispunând de un
minim de cunoştinţe despre modul de organizare a lui în general şi informatică în special, integritatea şi
securitatea datelor etc. [3].
În acest context, nu poate fi proiectat şi creat un sistem informaţional fără a ţine cont de obiectivele
creării sistemului cum sunt:
- analiza datelor, presupune analiza domeniului în care va fi creată şi utilizată baza de date;
specificarea caracterului şi volumului informaţiei care se va conţine în baza de date şi modul ei
de utilizare; care vor fi (în linii mai) datele de ieşire; posibilitatea reprezentării datelor sub
diferite aspecte;
- asigurarea independenţei datelor - o aplicaţie, în general, este dependentă de date în sensul că
modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează şi
aplicaţia, îndependenţa datelor faţă de aplicaţie este totuşi necesară cel puţin din următoarele
considerente: diferite aplicaţii au nevoie de viziuni diferite ale aceloraşi date; administratorul
bazei de date trebuie să aibă libertatea de a schimba structura de memorare sau strategia de
acces, ca răspuns la cerinţe, fără a modifica aplicaţiile existente, baza de date existentă, precum
şi programele de exploatare a ei, care au fost folosite o perioadă de timp, reprezintă o investiţie
majoră la care nu trebuie să se renunţe prea uşor.
De aceea, se impune ca atunci când apar noi cerinţe în cadrul sistemului informaţional, sistemele
informatice să poată funcţiona cu programele şi procedurile existente, iar datele existente să poată fi
convertite. Deci, modificările care se fac la nivel de structură de date nu trebuie să modifice programele
de aplicaţie.
Independenţa datelor trebuie privită din două puncte de vedere: independenţa fizică şi independenţa
logică a datelor. Independenţa fizică a datelor face ca memorarea datelor şi tehnicile fizice de memorare
să poată fi modificate fără a determina rescrierea programelor de aplicaţie. Independenţa logică a datelor
se referă la posibilitatea adăugării de noi articole de date sau extinderea structurii conceptuale, fără ca

21
aceasta să impună rescrierea programelor existente.
Asigurarea unei redundanţe minime şi controlate a datelor. Spre deosebire de sistemele clasice de
prelucrare automată a datelor, stocarea datelor în cazul bazelor de date se face astfel încât fiecare dată să
apară o singură dată. Totuşi, nu sunt excluse nici cazurile în care, pentru a realiza performanţe sporite,
referitoare la timpul de acces la date şi răspuns la solicitările utilizatorilor, să se accepte o anumită
redundanţă a datelor, însă în acest caz se va institui un control automat asupra ei în vederea asigurării
coerenţei datelor în bază.
Asigurarea unor facilităţi sporite de utilizare a datelor. Aceasta presupune: folosirea datelor de
către mai mulţi utilizatori în diferite scopuri (aplicaţii); accesul cât mai simplu al utilizatorilor la date, fără
ca aceştia să fie nevoiţi să cunoască structura întregii baze de date, acest lucru rămânând în sarcina
administratorului bazei de date; existenţa unor limbaje performante de regăsire a datelor, care permit
exprimarea sub forma unei conversaţii, a unor criterii de selecţie a datelor şi indicarea unor reguli cât mai
generale pentru editarea informaţiilor solicitate; spre deosebire de sistemul clasic de prelucrare pe fişiere,
unde exista un singur criteriu de adresare, în cazul bazelor de date sistemul trebuie să ofere posibilitatea
unui acces multicriterial, fără sortări suplimentare, în timp ce modificarea criteriului la fişierele clasice
implică şi reorganizarea lor; utilizarea unui limbaj cât mai aproape de limbajul natural, cu posibilitatea
exploatării bazei de date în regim conversaţional. Aceasta ar oferi posibilitatea exploatării în mod facil a
bazei de date şi de către utilizatorii neinformaticieni.
Asigurarea integrităţii informaţiei împotriva unor ştergeri intenţionate sau neintenţionate, prin
intermediul unor proceduri de validare, a unor protocoale de control concurent şi a unor proceduri de
refacere a bazei de date după incidente.
Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. În condiţiile
bazelor de date, administratorul bazei de date poate prevedea ca accesul la baza de date să se facă numai
prin canale corespunzătoare şi poate, totodată, defini, verificări de autorizare realizate oricând se încearcă
accesul la anumite date.
Asigurarea partajabilităţii datelor. Partajabilitatea datelor trebuie înţeleasă nu numai sub aspectul
asigurării mai multor utilizatori la aceleaşi date, ci şi acela al extinderii şi modificării bazei de date cu
eforturi minime, al posibilităţii dezvoltării unor aplicaţii fără a se modifica structura bazei de date.

Din obiectivele descrise mai sus, rezultă că un sistem informatic este un set de programe, care
facilitează şi supraveghează introducerea de informaţii în baza de date, actualizarea şi extragerea datelor
din bază, controlul şi autorizarea accesului la date.

22
1.4 Funcţiile sistemului informaţional

Pentru realizarea obiectivelor enumerate mai sus, sistemele informatice dispun de o serie de
componente ce permit efectuarea numeroaselor operaţii. În funcţie de natura lor şi scopul urmărit,
operaţiile pot fi gripate pe activităţi. Activităţile acceptă şi ele o grupare pe funcţii.
Ţinând seama de multitudinea sarcinilor ce revin unui sistem şi grupând aceste sarcini pe activităţi
şi apoi pe funcţii, se deduc, în final, funcţiile sistemului informatic. Ţinând seama de complexitatea
sistemului, de facilităţile propuse a fi oferite de acesta, de limbajele utilizate şi tipul bazei de date ce
urmează a fi gestionată, gruparea activităţilor pe funcţii are un caracter relativ, depinzând de sistemul
informatic concret.
Funcţiile pe care un sistem informaţional generalizat trebuie să fie capabil să le îndeplinească, sunt:
Funcţia de descriere a datelor, care rezidă în definirea structurii datelor, a relaţiilor dintre acestea şi
a condiţiilor de acces la informaţiile conţinute în baza de date. La nivelul acestei funcţii se descriu
multitudinea atributelor (câmpurilor) din cadrul structurii bazei de date, legăturile dintre entităţile bazei
de date sau dintre atributele aceleeaşi entităţi, se definesc eventualele criterii de validare a datelor,
metodele de acces la date, aspectele referitoare la asigurarea integrităţii şi confidenţialităţii datelor etc.
Rezultatul acestei funcţii se va concretiza în schema bazei de date, memorarea în cod intern.
Funcţia de manipulare a datelor este cea mai complexă funcţie şi realizează următoarele activităţi:
crearea (încărcarea) bazei de date; actualizarea bazei de date, care presupune înserarea, adăugarea de noi
înregistrări, tupluri, suprimarea unor înregistrări şi redactarea informaţiei, adică modificarea valorilor
corespunzătoare unor câmpuri; interogarea bazei de date, care permite obţinerea diferitor informaţii din
baza de date conform unor criterii de căutare, sortarea şi editarea parţială sau totală a unei înregistrări
virtuale; obţinerea datelor noi, care constă în prelucrarea informaţiei iniţiale în scopul obţinerii unor
totaluri, medii etc.
Funcţia de utilizare asigură mulţimea interfeţelor necesare pentru comunicarea tuturor utilizatorilor
cu baza de date. În cadrul realizării acestei funcţii, apar mai multe categorii de utilizatori: utilizatori liberi
sau convenţionali, care reprezintă categoria beneficiarilor de informaţii care utilizează limbajele de
interogare a bazei de date într-o formă simplistă. Ei apar ca utilizatori neinformaticieni; utilizatori
programatori, care utilizează limbajele de manipulare, realizând proceduri complexe de exploatare a
bazei de date; administratorul bazei de date apare ca un utilizator special şi are rolul hăotărâtor ăîn ceea
ce priveşte funcţionarea optimă a întregului ansamblu.
Funcţia de întreţinere, administrare a bazei de date, care constă în crearea copiilor de rezervă,
compactarea bazei de date şi repararea ei în cazul deteriorării. Este o funcţie complexă şi este de
competenţa administratorului bazei de date.
De securitate a datelor, care rezidă în protejarea bazei de date împotriva accesului neautorizat şi
atribuirea drepturilor de acces pentru utilizatori în cazul utilizării bazei de date într-o reţea.
23
1.5 Metodologii de realizare a sistemelor informatice
Realizarea sistemelor informatice reprezintă o acţiune complexă, care îmbină un număr mare de
activităţi: analiză, proiectare, implementare, exploatare [3]. În plus, reclamă resurse umane, materiale şi
financiare însemnate, pe o perioadă considerabilă de timp. Folosirea eficientă a acestor resurse, în scopul
obţinerii unui sistem informatic performant a impus ordonarea acestui proces complex, într-o succesiune
bine stabilită de etape şi subetape şi utilizarea unor metode şi tehnici adecvate. Acest lucru a dus deci, la
conturarea unor metodologii de realizare a sistemelor informatice.
Între diversele etape de realizare a sistemelor informatice există o legătură indestructibilă, legătură
reflectată şi de faptul că în mod logic şi practic calitatea realizării unor activităţi din etapele şi fazele
precedente influenţează în mod decisiv calitatea activităţilor din etapa ce îi urmează.

Conţinutul metodologiilor de realizare a sistemelor informatice


Metodologiile de realizare a sistemelor informatice cuprind:
 modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre variaţiile
sistemului şi dinamismul său;
 regulile de formalizare a datelor şi proceselor de prelucrare;
 instrumentele pentru concepţia, realizarea şi elaborarea documentaţiei;
 modalitatea de derulare a proiectului şi acţiunile specifice fiecărei etape (ciclul de viată);
 definirea modului de lucru, rolului analiştilor şi proiectanţilor şi a raportului dintre ei;
 modalităţile de administrare a proiectului (planificare, programare, urmărire).

Totodată, metodologiile au rolul de a indica modul de desfăşurare a acestui proces, stabilind:


 componentele procesului de realizare a sistemului informatic (etape, subetape, activităţi,
operaţii) şi conţinutul lor;
 fluxul parcurgerii (executării) componentelor: metodele, tehnicile, procedeele,
instrumentele, normele si standardele utilizate.

La realizarea sistemelor informatice se utilizează: metode, tehnici, instrumente, procedee de lucru.


Metodele utilizate în proiectarea sistemelor informatice reprezintă modul unitar sau maniera
comună în care analiştii de sisteme, programatorii şi alte categorii de persoane implicate, realizează
procesul de analiză a sistemului informaţional-decizional existent, proiectarea şi introducerea sistemului
informatic. Deci, metoda are un caracter general, în cadrul ei aplicându-se anumite tehnici de lucru.
Tehnicile de lucru utilizate în proiectarea sistemelor informatice reprezintă felul în care se
acţionează eficient şi rapid, în cadrul unei metode, pentru soluţionarea diferitelor probleme ce apar în

24
procesul de proiectare. Prin aceste tehnici se îmbină armonios cunoştinţele despre metode cu măiestria
personală a celor chemaţi să aplice metodele si să utilizeze instrumentele adecvate.
Utilizarea acestor metode, tehnici, instrumente, procedee de lucru în proiectarea sistemelor
informatice se face în conformitate cu o serie de principii şi în limita unor metodologii de lucru care se
adoptă în funcţie de situaţia reală la care se referă.
În abordările incipiente se lucra cu probleme izolate şi ulterior s-a efectuat trecerea la abordarea
sistemică (modulară), odată cu abordarea funcţională sau, mai bine zis, cu analiza şi descompunerea
funcţională (în fiecare modul există câte o funcţie) şi ulterior abordarea orientată-obiect. Pe parcurs s-au
impus două strategii de abordare şi anume:
 strategia top-down (de sus în jos);
 strategia bottom-up evolutivă (de jos în sus).

În strategia top-down abordarea generală este divizată în unităţi componente prin rafinări repetate,
metoda de proiectare putând fi descrisă sub forma unei diagrame ierarhice cu module de control pe nivele
superioare şi cu module detaliate pe nivelele inferioare. Structura organizatorică a unei unităţi economico-
sociale numită organigrama unităţii poate fi reprezentată printr-o astfel de diagramă ierarhică. Pentru
unităţi economice productive în organigramă se disting următoarele patru nivele de reprezentare [2]:
 nivelul conducerii strategice, reprezentat de directorul general şi consiliul de administraţie;
 nivelul conducerii tactice (directori pe funcţiuni);
 nivelul compartimentelor funcţionale (servicii şi posturi de lucru) şi de proiectare,
cercetare (laboratoare) care asigură conducerea operativă a sistemului prin şefii lor;
 nivelul compartimentelor de producţie (secţii, ateliere) care realizează funcţia de producţie
a sistemului economic.

În strategia bottom-up evolutivă, se porneşte de la o tratare minimală care se extinde treptat pe


măsura înaintării în realizarea sistemului. În practică, de cele mai multe ori se utilizează o combinare a
celor două strategii.
Metodele de abordare a sistemelor informatice ar putea fi grupate prin prisma celor mai mulţi autori
astfel:
 metode orientate spre funcţii, numite şi metode ale descompunerii funcţionale;
 metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece diagramele
fluxurilor de date se întrebuinţează pentru descrierea proceselor;
 metode orientate spre informaţie sau date, orientate-informaţii, apărute ca urmare a
popularizării puternice a ingineriei informaţiei a lui JAMES MARTIN, dar şi a diagramelor
entitate-relaţie ale lui CHEN [5];

25
 metode orientate-obiect.
Caracteristici esenţiale ale principalelor metode. Informaţia este văzută de DeMarco în 1982, ca
fiind posibil de abordat prin trei perspective specifice sistemelor informaţionale sau prin trei dimensiuni:
date, funcţii, comportament [4].
Datele sunt surprinse din prisma structurii lor sub formă de atribute şi înseamnă de fapt, ceea ce are
stocat, şi reflectă structura statică.
Funcţiile scot în evidenţă în mod limitat ceea ce face sistemul. El poate fi văzut şi ca un proces,
întrucât elementele sistemului despre care se păstrează datele de rigoare sunt supuse unor transformării
funcţionale, prin intermediul proceselor.
Comportamentul este invocat pentru a reda o altă modalitate de percepţie a sistemului, influenţa
evenimentele şi proprietăţilor sistemului, şi sugerează dinamica lui.
Metoda descompunerii funcţionale (orientate funcţii). Dintre autorii remarcabili care au abordat
descompunerea funcţională îi enumerăm pe câţiva cum ar fi DeMarco, Yourdon şi Constantine, Jackson,
Page-Jones, Warnier-Orr, Dahl, Marco&Gowan. Descompunerea funcţională este cea care anunţă apariţia
proiectării structurate şi analizei structurate. Fiecare funcţie este descompusă în subfuncţii, până se obţin
structuri uşor de transpus în instrucţiunile limbajelor de programare.
Metodele fluxurilor de date (orientate-proces). Prin această metodă analiştii efectuează
reprezentarea lumii reale prin simboluri care reprezintă fluxul datelor, transformările datelor, stocarea
datelor, entităţi externe, etc. Metoda orientată spre procese are încă un mare grad de asemănare cu
descompunerea funcţională.
Metode orientate spre informaţii (orientate-date). Două realizări importante în domeniu au dat tonul
unei orientări în abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaţie, de către
Peter P. Chen (1976) şi ingineria informaţiei, în viziunea lui James Martin.
Metoda orientată-obiect. Metodele OO constituie o categorie particulară a metodelor de dezvoltare
software, care privesc construirea sistemelor pentru care clasa reprezintă unitatea arhitecturală
fundamentală. Clasa este o grupare logică a obiectelor care au aceeaşi structură şi un comportament
similar.

1.6 Analiza sistemului existent şi definirea cerinţelor noului sistem

În cadrul acestui capitol este prezentată prima etapă a ciclului de viaţă al sistemelor informatice,
etapă prin care se determină modul în care funcţionează sistemul informaţional curent şi se evaluează
ceea ce ar dori utilizatorii să realizeze noul sistem.
Astfel, sunt prezentate o serie de aspecte privind:

26
 determinarea cerinţelor sistemului;
 metodele tradiţionale utilizate în analiza şi determinarea cerinţelor sistemului (interviul şi
chestionarul);
 metode moderne de analiză şi determinare a cerinţelor sistemului (JAD, prototipizarea);
 structurarea cerinţelor sistemului – modelarea logică a datelor şi prelucrărilor (diagramele
fluxurilor de date DFD);
 modelarea conceptuală a datelor (diagramele entitate – relaţie, DER).

1.6.1 Studiul sistemului informaţional existent

Prin sistem existent se înţelege realitatea obiectivă din organizaţia pentru care urmează a se realiza
sistemul informatic solicitat printr-o comandă numită cererea beneficiarului.
Analiza sistemului existent şi definirea cerinţelor noului sistem este prima etapă din ciclul de viaţă
al dezvoltării sistemelor informatice, etapă prin care se determină modul în care funcţionează sistemul
informaţional curent şi se evaluează ceea ce ar dori utilizatorii să realizeze noul sistem. Studiul şi analiza
sistemului existent are ca obiectiv principal stabilirea cerinţelor informaţionale ale conducerii în vederea
realizării unui sistem informatic.
Studiul sistemului existent cuprinde un grup de activităţi care urmăresc cunoaşterea performantelor
tehnico-funcţionale ale sistemului informaţional, atât în ansamblul său, cât şi pentru elementele de
structura ale acestuia, a cerinţelor informaţionale ale conducerii, cunoaşterea lipsurilor şi restricţiilor pe
care le prezintă sistemul existent faţă de aceste cerinţe. De modul de realizare a acestor activităţi depinde
întregul proces de realizare a sistemului informatic [3].
Studiul sistemului existent constă în:
 definirea caracteristicilor generale ale sistemului;
 studiul activităţilor de bază desfăşurate în sistem;
 studiul sistemului de conducere;
 studiul sistemului informaţional;
 identificarea metodelor şi mijloacelor tehnice.

Definirea caracteristicilor generale ale sistemului implică:


 cunoaşterea profilului, obiectivelor;
 cunoaşterea locului în sfera serviciilor;
 cunoaşterea relaţiilor de cooperare cu alte instituţii;
 cunoaşterea specificului activităţii de bază (prestarea serviciilor);
27
 dezvoltarea, modernizarea etc.
Studiul sistemului de conducere se referă la:
 identificarea caracteristicilor sistemului de conducere existent;
 sistemul de indicatori cantitativi;
 organizarea conducerii (administrarea).

Studiul sistemului informaţional presupune:


 elaborarea schemei fluxului informaţional global (cu punerea în evidenţă a principalelor
activităţi şi a legăturilor statice şi dinamice dintre acestea);
 estimarea cantitativă şi calitativă a informaţiilor de intrare-ieşire, modul de culegere şi
prelucrare;
 identificarea principalilor algoritmi, regulilor de calcul şi a punctelor si regulilor de
control;
 cunoaşterea principalelor restricţii ale sistemului informaţional;
 situaţia raţionalizării fluxurilor şi a documentelor, studii elaborate, stadiul lor de
implementare;
 sistemul de codificare utilizat, restricţii;
 performanţele şi limitele sistemului informaţional existent.

Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea datelor în cadrul


sistemului informaţional existent se face evidenţiind:
 mijloacele tehnice existente în dotarea unităţii (modul de utilizare, cheltuielile de
exploatare, personalul implicat, performante);
 existenţa unor aplicaţii proiectate şi/sau implementate.

1.6.2 Determinarea cerinţelor sistemului

Determinarea cerinţelor sistemului este activitate esenţială în aflarea situaţiei existente şi a ceea ce
se doreşte în viitor. Rezultatul activităţii de determinare a cerinţelor sistemului se concretizează în diferite
forme ale informaţiilor colectate, cum sunt copii ale interviurilor, însemnări efectuate în timpul observării
şi analizei documentelor, interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte,
descrieri ale posturilor de lucru ş.a., precum şi rezultate ale prelucrărilor efectuate de calculator, cum ar fi
prototipurile [4].

28
Rezultatele prezentate după această activitate pot fi rezumate astfel:
informaţii obţinute în urma conversaţiilor cu utilizatorii sau prin observarea activităţilor prestate de
aceştia: copii sau sinteze ale interviurilor, răspunsurile la chestionare sau interpretări ale acestora,
însemnări şi rezultate din observarea activităţilor, procese verbale ale şedinţelor ce au avut loc în
acest scop;
informaţii scrise care există în unitate: misiunea şi strategia afacerii, exemplare ale formularelor,
rapoartelor şi machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru,
manuale de instruire, scheme de sisteme şi documentaţia sistemului existent, rapoartele
consultanţilor;
informaţii obţinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fişierelor
sesiunilor grupului de sprijinire a sistemului, conţinutul depozitelor şi rapoartele existente în CASE,
ecrane şi rapoarte rezultate din prototipurile sistemului, ş.a.

29
2 Modelarea sistemului informaţional de evidență a cazării în cămin.

2.1 Nuanţele specifice în vederea eficienţii modelării produselor soft

Model – este reprezentarea unui lucru într-un mediu (care poate să coincidă cu mediul entităţii
reprezentate). Ea reflectă aspectele cele mai importante din punctul de vedere a entităţii modelate, iar
altele le reprezintă în forma simplificată sau le omite complet.
Modelul trebuie să fie creat într-un mediu de proiectare comod pentru lucru. Modelul unui produs
soft poate fi elaborat cu ajutorul limbajului de modelare UML. Modelul poate fi prezentat în mai multe
forme (text sau desen).
Modelul este necesar pentru:
- descrierea concretă a cerinţelor faţă de sistem şi a cunoştinţelor despre domeniul de interes, pentru
că toţi participanţi ai proiectului să fie în stare să le înţeleagă şi să ajungă la o înţelegere; diferite
modele a produselor soft pot conţine cerinţele faţă de sistem şi de domeniu de interes,
modalităţile de lucru a utilizatorilor cu sistem, decompoziţia sistemului în module, în acest caz
persoanele implicate în proiect sunt: arhitecturi, analişti, programatori, conducători de proiect,
clienţii, organizaţii şi persoanele care finanţează proiectul, utilizatori fînali;
- elaborarea planului sistemului - cu ajutorul modelului produsului soft elaboratorii pot cerceta mai
multe soluţii arhitecturale sau de proiect înainte scrierii codului de program; un limbaj bun de
modelare permite crearea arhitecturii sistemului înainte începerii procesului de proiectare
detaliată a sistemului soft;
- reprezentarea soluţiilor de proiect de natură diferită - într-un model este specificat comportamentul
vizibil al produsului soft şi conceptele lumii reale utilizate de el, în alt model sunt reflectate
clasele şi metodele interne care realizează comportamentul sistemului şi există o mulţime de
modalităţi de a realiza acest comportament;
- crearea variantelor intermediare a produsului - modelul produsului soft poate fi utilizat pentru
crearea claselor, procedurilor, interfeţelor cu utilizator, bazelor de date, scenariilor de utilizare a
sistemului, scenariilor de configurare;
- obţinere, filtrarea, organizarea, cercetarea şi redactarea informaţiei despre sistemele mari
complexe.

Modelul produsului soft organizează informaţia conform următoarelor parametri: structura statică,
automate finite, interacţiuni, cerinţe, ş.a.m.d. Aşa o secţiune conţine informaţia despre sistem numai dintr-
un anumit punct de vedere. Modelarea produselor soft nu este posibilă fără instrumentele respective de

30
redactare a modelului. Redactorul modelului permite să reprezinte informaţia despre model în formate
diferite, să ascundă datele care nu sunt necesare la momentul dat şi să le arate la necesitate, să grupeze
operaţiile legate, să modifice elementele modelului, să facă schimbări în grupele diferite a elementelor cu
o singură comandă şi etc.
Cercetarea economică a soluţiilor posibile. La modelarea unui produs soft mare se poate de cercetat
mai multe variante de proiectare. De sigur, modelul nu este în stare să cuprindă toate detaliile sistemului,
dar chiar cu ajutorul unui model aproximativ pot fi soluţionate multe probleme care pot să apară în
proiectul final. Mai mult ca atât, după cercetarea a câtorva soluţii posibile se poate de ales varianta cea
mai optimală pentru proiectul dat.
Realizarea elaborări sistemelor mari complexe. Modelul unui produs soft mare micşorează
complexitatea, care nu poate fi depăşită cu ajutorul altor metode. Modelul reduce sistemul până la nivelul
accesibil intelectului uman în aşa fel ca această persoană să nu se piardă în detaliile sistemului. Cercetând
modelul se poate de apreciat rezultatul modificărilor sistemului, aceasta este comod când este necesar de
efectuat restructurarea arhitecturii acestui sistem.
Modelele se creează pentru scopuri diferite, de aceea ele pot să aibă forme diferite la nivele diferite
a abstracţiei. Gradul de detaliere a modelului depinde de scopul cu care el este creat.
Scopurile creării modelului: Dirijarea procesului de gândire - modelele nivelului superior, care sunt
create la începutul proiectului, servesc pentru dirijarea procesului de gândire a persoanelor implicate în
proiect şi pentru determinarea funcţiilor sistemului. Acest tip de model se bazează pe cerinţele de bază
faţa de sistem şi este primul pas în proiectarea lui. La nivelul superior al modelului autorii proiectului pot
cerceta parametrii sistemului aparte, înaintea adunării lor într-un concept. În timpul dezvoltării sistemului
modelele nivelului superior sunt înlocuite cu alte modele mai concrete şi detaliate. Scopul principal al
primelor modele este elaborarea ideilor, ele nu necesită aşa detaliere ca modele de realizare. Modelele
nivelului superior folosesc o submulţime limitată de construcţii a limbajului UML;
Descoperirea abstracţiilor structurii de bază a sistemului - La etapa de proiectare preliminară
modelul se construieşte în jurul conceptelor şi mecanismelor de bază a sistemului final. Într-o măsură
oarecare modelul corespunde sistemului final, dar multe detalii pur şi simplu lipsesc. Ele sunt adăugate
mai târziu în procesul de proiectare. Scopul modelelor abstracte constă în determinarea corectă a
aspectelor de bază a sistemului înaintea introducerii unor detalii specifice. Modelul primar trebuie să se
dezvolte treptat în modelul fînal al sistemului, această este necesar pentru ca elaboratorii să nu omită din
vedere nici o cerinţă de bază, specificată la începutul proiectului. Trasarea procesului dezvoltare a
modelului o să garanteze ca toate caracteristicile de bază prezente în primele modele să fi realizate în
versiunea fînală a sistemului. Modelele nivelului superior se concertează numai asupra semanticii şi nu au
nevoie de setul complet de posibilităţi pentru realizarea sistemului. Pe de altă parte modele nivelului
inferior iau în consideraţie aşa aspecte ca productivitatea şi uneori ele sunt mai importante decât unele

31
aspecte logice ale sistemului.
Specificarea completă a versiunii finale a sistemului - Modelul de realizare conţine informaţii
destule pentru construirea sistemului întreg. În acest model intră nu numai semantica sistemului şi
algoritmii, structuri de date şi mecanisme, care asigură funcţionarea corectă a sistemului, dar şi soluţiile
organizatorice referitoare la artefacte, necesare pentru lucru în comun a persoanelor şi instrumentelor de
prelucrare a datelor. Acest tip de modele deja conţîn mijloacele de împărţire a modelului în pachete, ceea
ce o face mai accesibilă pentru oameni şi mai comodă pentru prelucrarea cu calculator.
Exemplele sistemelor tipice sau posibile. Exemplele bine puse la punct pot să ajute oamenilor să
înţeleagă mai bine sistemul construit. În situaţii dificile exemplele structurilor de date, secvenţelor de
interacţiuni sau istoria obiectelor sunt în stare să uşureze esenţial lucrul elaboratorului. Desigur, este greu
de ales din mulţimea de exemple acele care o să corespundă necesităţilor concrete. Această se datorează
faptului că dintr-un număr mare de exemple este imposibil de dedus o regulă generală. Dar dacă modele-
exemple conţin instanţele concrete şi nu regulile generale ele sunt cu mult mai uşor înţelese de oameni. În
ele de regulă nu se folosesc toate construcţiile limbajului UML, se folosesc numai acele care sunt
necesare pentru reprezentarea exemplarelor concrete;
Descrierea parţială sau completă a sistemului. Modelul poate să descrie sistemul în întregime, fără
legături externe. Dar mai des modelul este organizat ca un set de blocuri distincte, care pot fi folosite
îndependent unul de altul. Aceste blocuri au “capete libere”, cu ajutorul cărora aceste blocuri se leagă
unul cu altul, astfel formând modelul. Blocuri pot fi legate în moduri diferite, astfel obţînând sisteme
diferite. Această permite reutilizarea blocurilor, ceea ce corespunde unuia din cele mai importante scopuri
a modelării. Cu timpul modelele se schimbă – din modele abstracte se obţin modele cu detaliere mai
mare. Din ele, la rândul lor, şi încă mai detaliate. În aşa fel, modelul primar reprezintă sistemul construit,
format din descrieri concise a câtorva servicii de bază. Treptat, elaboratorii adaugă la acest model variante
şi caracteristici suplimentare. De la început modelul este construit reieşind din interesele utilizatorului şi
problemelor de construire a interfeţelor externe a sistemului. De aceea accentul este pus pe partea
aplicativă sistemului, adică pe realizarea fizică. Cu timpul elaboratorii înţeleg sistemul tot mai bine şi de
aceea modelul este modificat iterativ la toate nivelele. Elaborare iterativă ajută proiectanţilor să fixseze
treptat tot ce este nou. Este practic imposibil de a înţelege un sistem complex într-o singură trecere, de
aceea nu poate exista o altă cale de creare a sistemelor soft complexe fără construirea modelelor [2],

2.2 Diagrama cazurilor de utilizare

Diagramele cazurilor de utilizare sunt folosite pentru a specifica modul de funcţionare a entităţi
(sistem, subsistem sau clasificator) aşa cum se manifestă din punct de vedere al interacţiunilor cu mediul
exterior.

32
În dezvoltarea sistemelor software (ingineria software) specificarea cerinţelor şi a modului de
utilizare al unui sistem sunt deosebit de importante, chiar dacă multă vreme nu s-a conştientizat acest
aspect al proiectării şi nu s-au folosit mijloace adecvate de reprezentare.
În proiectarea UML se stipulează în mod clar că, înainte de a realiza un sistem, trebuie să fie
specificat clar modul de comportare al sistemului din punctul de vedere al utilizatorilor săi. Această
specificare se face prin diagrame de utilizare.
O diagramă use case este un graf compus din actori, cazuri de utilizare şi legăturile dintre acestea.
Diagramele de utilizare UML se referă numai la funcţionarea (comportarea) unui sistem şi nu la
implementarea acestuia. Este foarte important ca înainte de a găsi soluţii pentru realizarea unui sistem să
fie foarte bine cunoscute şi înţelese cerinţele de funcţionare şi utilizarea acestuia.
În figura 2.1 este prezentată diagrama cazurilor de utilizare a procesului de logare în sistem.

uc Tipuri de utilizatori

Introduc e login

Oper ator
«include»

Logare in si stem

Administrator

«include»

Utili zator Introduc e parola

Figura 2.1 – Diagrama use case a procesului de logare în sistem

Pentru a efectua o logare în sistemul informațional de evidență a cazării în cămin, utilizatorul


trebuie să introducă loginul și parola de acces. Prin diagramă se observă că avem două tipuri de
utilizatori: administratorul și operatorul.
În figura 2.2 este prezentată diagrama cazurilor de utilizare a funcționalității administratorului.

33
uc Functionalitatile administratorului

Adaugare camin
Adminis trare
utilizatori

Adaugare sectie

Adminis trator

Adaugare odaie

Vizualizare raport
persoane cazate

Vizualizare raport
camine

Figura 2.2 – Diagrama Use-Case a operațiilor administratorului

Prin diagrama cazurilor de utilizare se observă funcționalitățile sistemului efectuate de


administrator. Cele mai importante funcționalități sunt: administrarea utilizatorilor, adăugarea căminelor
(de care dispune instituția) în sistem, adăugarea secțiilor căminelor, adăugarea odăilor și vizualizarea
raportelor pe cămine și persoane cazate.
În figura 2.3 este prezentată diagrama cazurilor de utilizare a procesului de înregistrare sau
adaugare cămin în baza de date a sstemului. Pentru a efectua această oerație este necesar de a introduce:
Id-ul, denumirea căminului (sau numărul), adresa unde se află acesta, numărul de telefon și introducerea
persoanei responsabile pe cămin (administratorul de cămin).
uc Adaugare camin

Introduce ID

Introduce denumire

«include»

«include»

Adaugare camin
Introduce adresa
«include»

«include»

«include»
Introduce numar
telefon

Indi ca nume
administrator camin

Figura 2.3 – Diagrama Use-Case a procesului de adaugare cămin

34
După ce s-a adăugat un cămin în baza de date a sistemului, are loc procedura de adăugare a
secțiilor, figura 2.4.
uc Adaugare sectie

Introduce ID

«include»
Introduce denumire

«include»

Adaugare sectie

«include»

«include» Selecteaza c amin

Indi ca nume
administra tor camin

Figura 2.4 – Diagrama Use-Case. Adaugare secție


Pentru adăugarea secțiilor se selectează căminul, se introduce Id-ul, denumirea secției (sau numărul)
și indicarea administratorului căminului.
După adăugarea secției se selectează odăile în dependență cîte odăi sunt în secția respectivă, fig.2.5.
uc Adaugare Odaie

Introduce ID

Selecte aza numar de


«include» loc uri

«include»

Adaugare odaie

«include»

Indica numar odaie

«include» «include»

Selecteaza c amin
Selecteaza s ectie

Figura 2.5 – Diagrama cazurilor de utilizare a procesului de adaugare odăi

35
Pentru adăugarea odăii la fel se selectează căminul, secția, se indică numărul odăii și numărul de
locuri.
După ce s-au efectuat procesul de monitorizare a căminului, a secțiilor și odăilor, operatorul sau
utilizatorul va avea acces la cazarea persoanelor în cămin.
În figura 2.6 se prezintă diagrama cazurilor de utilizare a administrării utilizatorilor.

uc Administrare utilizatori

Introduce l ogin

Modifica date
utilizator Intr oduce
Nume/P renume

«include»

«include»

Introduce num ar de
«extend»
telefon
Adauga utilizator «include»

«extend»

Adminis trare «include»


utilizatori

«include»
Introduc e parola

«extend»

Seteaza niv e l de
acces

Sterge date util izatori

Figura 2.6 – Diagrama Use-Case a procesului de administrare utilizatori

Pentru a efectua această operație, administratorul va introduce date despre utilizator ca: login,
nume, prenume, număr de telefon, adresă de e-mail, parola de acces și nivel de acces. La fel
administratorul are posibilitate de a modifica datele și șterge date utilizator.
După procesul de administrare a aplicației, utilizatorul simplu sau operatorul înregistrat de
administrator în sistem va putea efectua operațiile prezentate în figura 2.7.
Operația de cazare a unei persoane în cămin prin sistemul informațional de cazare în cămin se face
în felul următor (prezentat în figura 2.7); se adaugă datele persoanei, se selectează căminul unde va locui,
secția și odaia.

36
uc Functii operator

Introduce prenume Introduc e adresa

Selecteaza data
nasterii
Introduce nume
«include» «include»

«include»
«include»

Adauga persoana

«include» Introduce date


bule tin

«include»

Cazare persoana
«include» Selecteaza c amin
Ope rator

«include»

«include»

Selecteaza s ectia
Selecteaza numar
odaie

Figura 2.7 – Diagrama Use-Case a procesului de cazare persoana cămin

2.3 Diagrama de interacțiune

Diagramele de interacțiune sunt prezentate prin doua tipuri de diagrame: de secvență și de


colaborare și execut aceeași operația de a arăta fluxul de mesaje care are loc între obiecte. În această
lucrare, pentru proiectarea sistemului se va folosi numai diagrama de secvență
Diagrama de secvență pune accentul pe ordinea temporală a mesajelor schimbate între obiecte, ceea
ce oferă o bună înţelegere a comportării sistemului.
În diagramă a secvenţelor pe axa verticală se reprezintă timpul, cu valori crescătoare în josul
paginii, iar pe axa orizontală se reprezintă o listă de obiecte între care au loc transferuri de mesaje. Fiecare
obiect din lista de obiecte ale diagramei marchează o linie verticală de timp de viaţă (, până la care ajung
mesajele destinate obiectului respectiv, în figura 2.8 este prezentat procesul de lucru al sistemului
informațional de evidență a cazării în cămin.

37
sd Proces de administrare camin

Interfata sistem Modul de BD


procesare
Administrator

Cerere de logare() Logare in sistem ()

Proceseaza logare()
Extrage date()

Executa()
Date extrase()
Returnare date()
Afisare ()

Cerere adaugare camin ()

Adaugare camin ()

Procesare date()
Salvare date()

Executa salvare()
Date camin salvat()

Returnare date()

Afisare date camin ()

Cerere adaugare sectie ()


Aaugare sectie ()

Procesare date ()
Salvare date sectie()

Executa salvare date sectie()


Date sectie salvate()

Returnare date()

Afisare date sectie()

Cerere adaugare odaie()

Adaugare odaie()

Procesare date()

Salvare date odaie()

Executa salvare date odaie()


Date salvate odaie()

Returnare date ()

Afisare date odaie()

(from Use Case Model)

Figura 2.3 – Diagrama de secvență a procesului de lucru a sistemului

Prin diagramă se observă cum are loc execuția în timp al mesajelor, utilizatorul lansează aplicația,
prin interfața sistemului, interfața va recepționa cererea către sistem și acesta va afișa interfața de lucru
utilizatorului pentru a efectua operațiile prezentate în figură.

38
În figura 2.9 este prezentată diagrama de secvență a procesului de administrare utilizator.

Figura 2.9 – Diagrama de secvență a procesului de administrare a utilizatorului

Pentru a înregistra un utilizator în baza de date a sistemului este necesar de a introduce loginul,
parola, numele/prenumele, numărul de telefon și selectarea privelegiului de administrare. Datele se
transmit modulului de activitate spre procesare după care sunt salvate în baza de date a sistemului.
În figura 2.10 este prezentată diagrama de secvență a procesului de cazare a persoanelor.
Prin această diagramă la fel se vede scenariul procesului cazării în cămin a persoanelor. Cum am
menționat și în use-case, se înregistrează date persoană se alege căminul, secția și odaia.

39
sd Business Process Model

Interfata sistem Modul de BD


procesare
Operator

Cerere logare in sistem ()

Logare in sistem ()

Procesare date ()

Extrage date ()

Executa ()
Date extrase()

Returnare raspuns()

Afisare ()

Cerere cazare persoana camin ()

Inregistreaza date persoana ()

Selecteaza numar camin ()

Selecteeaza numar sectie ()


Selecteaza odaia ()

Cazare persoana()

Proceseaza date()

Salvare date ()

Executa salvare date()


Date salvate()
Returnare date()

Afisare date persoana cazata()

(from Use Case Model)

Figura 2.10 – Diagrama de secvențe a procesului de cazare persoana

2.4 Diagramele de activitate a sistemului

Diagramele de activitate sunt variante ale diagramelor de stare care reprezintă fluxul de lucru al
unei activităţi executate de un obiect. Elementele folosite sunt: stări de acţiune - reprezintă o acţiune
executată de un obiect, tranziţii: treceri de la o acţiune la alta, puncte de ramificare de decizie și unificare
după decizii.

40
În figura 2.11 este prezentată diagrama de activitate a funcționalității sistemului.
act Administrare camin

Start

Logare in sistem

Adaugare camin

Adaugare sectie

Adaugare odaie

Fin al

Figura 2.11 – Diagrama de activitate a sistemului

După lansarea sistemului se va adauga numarul caminului în baza de datee al sistemului, apoi se va
aduga secția și odăile respective aa acestuia.
În figura 2.12 este prezentată diagrama de activitate a procesului de cazare a persoanelor în cămin.

41
act Cazare persoana

Start

Logare in sistem
Cazare persoana

Alege numar camin Alege sectie Alege odaie


Modificare date

[occu ped] Salv are dare

[o k]

Per soa na
cazata

Fin al

Figura2.12 – Diagrama de activitate a procesului de cazare în cămin

După cum s-a menționat mai sus pentru cazarea persoanelor în camin, se adaugă datele despre
persoane și li se oferă o odaie în cămin. În caz dacă se necesită schimbări în cazarea persoanelor.

2.5 Diagramele de clase a sistemului


Un rol important în APOO îl ocupă elaborarea modelului logic al unui sistem în forma diagramei de
clase. Notaţia claselor în limbajul UML este simplă şi clară pentru toţi. O notaţie asemănătoare se
utilizează şi pentru obiecte – care sunt exemplare ale clasei, unica diferenţă este în aceea că la numele
clasei se adaugă numele obiectului şi toată înregistrarea se subliniază.
Notaţia limbajului UML oferă multe posibilităţi pentru reflectarea informaţiei suplimentare (operaţii
abstracte sau clase, stereotipuri, metode comune şi particulare, interfeţe detaliate, clase parametrizate).
Totodată este posibilă utilizarea reprezentării grafice pentru asocieri şi proprietăţile lor specifice, astfel
cum sunt relaţiile de agregare, cînd ca părţi componente ale clasei pot fi alte clase.
Diagrama de clase (class diagram) se utilizează pentru reprezentarea structurii statice a unui model
de sistem în terminologia claselor programării OO. Diagrama de clase poate reflecta diferite legături între
entităţile domeniului de obiecte (obiecte şi subsisteme) şi descrie structura lor internă şi tipurile de relaţii.

42
În această diagramă nu este menţionată informaţia despre aspectele temporare ale funcţionării sistemului.
Din acest punct de vedere diagrama de clase este dezvoltarea ulterioară a modelului conceptual al
sistemului proiectat.
În figura 2.13 urmează a fi prezentată diagrama de clase a sitemului. Prin această diagramă am
prezentat clasele principale ale sistemului cît și atributele și operațiile de bază.
class Class Model

Form
Genera lForm

- current: string = ""


- currentBloc: Bloc
- currentBlocId: int
- currentCame ra: Camera
- currentCameraId: int
- currentCam in: Camin
- currentCaminId: int
- parent: MainForm

- adaugaBloc_Click(obje ct, EventArgs) : voi d


- adaugaCamera_Click(obj ect, EventArgs) : voi d
- adaugaCamin_Cli ck(obje ct, EventArgs) : void
- adaugaPersoanaExistenta_Click(obj ect, EventArgs) : void
- editBloc_Click(objec t, EventArgs) : void
- editCamera_Click(obje ct, EventArgs) : void
- elimina_Click(object , EventArgs) : void
+ GeneralForm()
+ GeneralForm(MainForm)
- GetBlocEdi t() : void
- GetBlocForm() : void
- GetCameraEd it() : void
- GetCameraFo rm() : void
- GetCaminEdi t() : voi d
- GetCaminForm() : void
- LoadCurrentNode() : void
- LoadNode(Tree Node) : void
- PopulateBlocG rid() : void
- PopulateCamera Grid() : void
- PopulatePersoan eGrid() : void
- PopulateTreeV iew() : void
- resetareCamera_Click(ob ject, EventArgs) : void
- TreeDo(TreeNode) : void Form
- Visualisation() : void
About

+ About()
- btnClose_Click(object, EventArgs) : void

Form -about
Use rs -parent

Form
- datalogic: BLL = new BLL()
- frmAdd: AddUser MainForm
+ ID_USER_LOG: int
- about: About
+ ACCESSUSER: bool = fal se
- btnAdd_Click(object, EventArgs) : voi d
+ id_user: int = 0
- btnDel_Click(object, EventArgs) : void -usersFrm
+ NAME_USER: string = ""
- btnEdit_Click(object, EventArgs) : voi d
- usersFrm: Users
- dg_CurrentCellChanged(ob ject, EventArgs) : void
- EnableDi sabl eButton(bool) : void
- aboutToolStripMenuItem_Click(object, EventArgs) : void
+ Fi llDG() : void
- camereToolStripMenuItem_Click(obj ect, EventArgs) : void
+ Users(int)
- customi zeToolStripMenuItem_Cl ick(object, EventArgs) : void
-parent - exitToolStri pMenuItem_Cli ck(object, EventArgs) : void
- HelpOpen() : void
- helpToolStripButton_Click(object, EventArgs) : void
- keepOutToolStripMenuItem_Click(object, EventArgs) : voi d
-frmAdd + MainForm()
- MainForm_Load_1(objec t, EventArgs) : void
Form + SetAccessForUser(int, bool, string) : voi d
AddUser - toolStripButton1_Click(object, EventArgs) : void
- toolStripButton2_Click(object, EventArgs) : void
- access: int = 0 - toolStripButton3_Click(object, EventArgs) : void
- acti ons: string - toolStripButton4_Click(object, EventArgs) : void
- dataLogic: BLL = new BLL()
- id: i nt = 0 -parent
- parent: Users

+ AddUser(Users, string, int, string, string, string, int)


- AddUser_FormClosed(object, FormClosedEventArgs) : void Form
- btnCancel_Click(object, EventArgs) : void
LogForm
- btnOk_Click(object, EventArgs) : void
- btnOK_Click_1(object, EventArgs) : voi d - access: bo ol = false
- cbAll_CheckedChanged(ob ject, EventArgs) : void - datalogic: BLL = new BLL()
- cbChange_CheckedChanged(o bject, EventArgs) : void - id: i nt = 0
- CheckContro l s() : bool - parent: MainForm

- btnok_Cli ck(object, EventArgs) : void


- CheckContro l s() : bool
+ LogForm(Mai nForm)
- LogForm_FormCl osed(object, FormClosedEventArgs) : void

Figura 2.13 – Diagrama de clase a sistemului

Clasele de baza a sistemului informațional de evidență a cazării în cămine. Aici se arată clasele de
administrare a utilizatorilor.
În figura 2.14 este prezentată diagrama de clase a subsistemului de cazare în camin.

43
class Alte clase

Camin

Bl oc + Administrator: string
+ Adresa: string
+ Administrator: string + Denumire: string
+ Camin: Camin + Id: int
+ Denumire: string
+Camin + Telefon: string
+ Id: int
+ Add() : void
+ Add() : void + Camin()
+ Bloc() + Camin(int)
Form + Bloc(int) + Delete() : void
CameraForm + Delete() : void -currentCamin + GetAll() : List<Camin>
+ GetAll() : List<Bloc> + Load() : void
+ Camera: Camera + GetAllByCamin(in t) : List<Bloc> + Update() : void
+ GetAllByCaminDt(int) : DataTable
- button1_Click(object , EventArgs) : void + Load() : void +Camin
+ CameraForm() + Update() : void
# OnShown(Event Args) : void
+Bloc -currentBloc

+Camera

Camera
Form
+ Bloc: Bloc
+ Id: int Genera lForm
+ Locuri: int
+ Numar: int
-currentCamera
+ Add() : void
+ Camera()
+ Camera(int) Form
+ Delete() : void CaminForm
+ GetAll() : L ist<Camera> +Camera
+ GetAllByBloc(int ) : List<Camera> + Camin: Camin
+ GetAllByBlocDt(i nt) : DataTable
+ Load() : void - button1_Click(object , EventArgs) : void
+ Update() : void + CaminForm()
+Camera - CaminForm_Load(object, EventArgs) : void
Form # OnShown(Event Args) : void
Persoa naForm

+ Camera: Camera
+ Persoana: Persoana = new Persoana()

Form - button1_Click(object , EventArgs) : void


# OnShown(Event Args) : void
AddPersonaCamera
+ PersoanaForm()
+ Camera: Camera
+ Chooselast: bool = false
+ Persoana: Persoana
+Persoana
+ AddPersonaCamera()
- AddPersonaCamera_Load(object, EventArgs) : void Pers oana
- button1_Click_1(object, EventArgs) : void
+ Adresa: string
# OnShown(Event Args) : void
+ BuletinNuma r: string
- PopulateGrd() : void
+ BuletinSeri a: string
- toolStripButton1_Click(object, EventArgs) : void +Persoana + DataNasterii: DateTime = DateTime.Now
- toolStripComboBox1_Click(object, EventArgs) : void
+ Id: int
- toolStripComboBox2_Click(object, EventArgs) : void
+ Nume: string
+ Prenume: string

+ Add() : void
+ Delete() : void
+ GetAll() : List<Camin>
+ Load() : void
+ Persoana()
+ Persoana(int)
+ Update() : void

Figura 1.14 - Diagrama claselor a funcționalității sitemului de cazare în cămin

2.6 Diagrama componentelor

44
Diagramă a componentelor arată structura codului în termenii componentelor de cod la nivel fizic
și realizează o discifrare de la nivelul logic la nevulul componentelor. O componentă poate să conţină un
cod sursă, date binare sau executabile. În cadrul diagramei vor fi ilustrate şi dependenţele dintre
componente, ceea ce permite o vizualizare simplă a componentelor care vor fi afectate de modificarea
uneia dintre ele.
În figura 2.15 este prezentată diagrama componentelor ce vor fi folosite pentru implimentarea
sistemului.

cmp Component Model

LogForm.cs
DataLa yer.cs

Persoana Form.cs

GeneralForm.cs

AddPersonaCamera.cs

Users.cs
AddUser.cs

CaminForm.cs
BlocForm.cs

CameraForm.cs

Figura 2.15 – Diagrama componetelor sistemului

În figura 2.15 am prezentat documentele cele mai importante ale sistemului, din ele fac parte
LogForm.cs, DataLayer.cs, AddPersoanăCamera.cs, CaminForm.cs, Users.cs, AddUser.cs, .BlocForms.cs,
GenerareForm.cs, PersoanaForm.cs etc.

45
3 Documentarea produsului realizat

3.1 Platforma .Net Framework


Microsoft .NET Framework este o colecţie cuprinzătoare de clase, care furnizează programatorilor
aproape tot ce le trebuie pentru a scrie aplicaţii pentru Internet, Web şi Windows. Cele mai importante
caracteristici esenţiale ale acestei platforme sunt următoarele:
a) compilarea mai multor limbaje într-un limbaj intermediar comun (MSIL);
b) MSIL executat pe maşina virtuală:
1) VM similară cu maşina virtuală JAVA în multe privinţe;
2) model de securitate mult mai elaborat;
3) JIT – standard, în locul interpretorului;
c) permite interoperabilitate între:
1) Cod managed – provenit de pe platforma .NET;
2) Cod unmanaged - provenit de pe alte surse;
d) orientat spre realizarea serviciilor WEB;
e) accent pe securitate şi trust. Permite construirea şi livrarea aplicaţiilor cu diverse grade de
securitate şi trust;
f) componente principale, Common Language Runtime (CLR) şi .NET Framework Class
library;
g) pot fi dezvoltate o varietate largă de aplicaţii, de la programe Desktop pâna la aplicaţii
pentru dispozitive mobile, aplicaţii şi servicii web sau servicii Windows, de la programe
izolate şi pînă la sisteme distribuite de dimensiuni enorme;
h) mediul de execuţie este strict controlat de un motor de execuţie, care oferă o serie de
facilităţi ce ridică mult nivelul de calitate al aplicaţiilor (managementul automat al
memoriei şi securitatea fiind primele două care ies în evidenţă).

Printre limbajele puse la dispoziţie de Microsoft se numără C# , un limbaj dezvoltat într-un mod cât
se poate de concret, unul pentru altul. cu platforma .NET şi situat undeva între Java si C++ ca sintaxă, dar
cu câteva inovaţii semnificative. Librăriile de clase grupate în .NET Framework, împreună cu extensiile
care le pot fi aduse şi posibilitatea de a le utiliza pe toate dintr-un mediu unitar, ca de exemplu Visual
Studio, permite crearea de aplicaţii într-o manieră consistentă, indiferent de natura proiectului dezvoltat.
Coborând puţin mai jos şi vedem care sunt categoriile de aplicaţii care pot fi construite cu ajutorul .NET
Framework. La apariţia lor, primele servere web răspundeau cererilor clienţilor cu conţinut static - fişiere
HTML, imagini şi alte tipuri de informaţii luate de pe disc. Pe lângă aplicaţii şi servicii Web, .NET
Framework oferă posibilitatea dezvoltării de aplicaţii Windows, folosind cadrul Windows Forms. Fără a

46
intra în prea multe detalii, merită menţionat ca dezvoltarea aplicaţiilor Windows se face foarte similar cu
cea a aplicaţiilor web. De asemenea, .NET Framework oferă suport pentru dezvoltarea serviciilor
Windows, aplicaţii care rulează în fundal, fără interacţiune directă cu utilizatorul şi care pun diverse
funcţii la dispoziţia altor aplicaţii de pe acelaşi calculator sau din reţeaua locală. Platforma .NET face
posibile două scenarii foarte importante pentru dezvoltatori: programarea orientată pe componente şi
arhitecturile orientate pe servicii. Programarea orientată pe componente duce noţiunea de programare pe
obiecte (OOP) cu un pas mai departe. Pentru toate componentele utilizate, fie ele vizuale sau non-vizuale,
şi indiferent de tipul aplicaţiei în care sunt folosite, modul de dezvoltare este de obicei acelaşi - funcţiile
unor componente mai simple sunt folosite pentru a dezvolta componente şi sisteme mai complexe.
Aceasta consistenţă se traduce de obicei în viteza mai mare de dezvoltare, în reutilizarea eficientă a
codului şi în calitatea sporită a aplicaţiilor. Arhitecturile orientate pe servicii sunt un concept apărut relativ
nou şi tind să facă o paralelă între modul în care evoluează sistemele software în prezent şi modul în care
au evoluat alte sisteme în trecut. Toate aplicaţiile dezvoltate pe .NET rulează într-un mediu de execuţie
controlat (managed execution environment), furnizat de Common Language Runtime (CLR). Acest mediu
de execuţie furnizează un set complex de servicii care au rolul de a face mai usoară viaţa dezvoltatorilor,
încercând în acelaşi timp să menţină un nivel de performanţă şi fiabilitate cât mai ridicată. Platforma oferă
suport pentru securizarea aplicaţiilor, în aşa fel încât aplicaţiile bine proiectate şi implementate să
primească doar privilegiile de care au nevoie pentru a rula corect, iar administratorii de sistem să poată
controla politicile de acordare a privilegiilor. Acest lucru se realizează prin Code Access Security (CAS).
Alte mecanisme de securitate folosite pe scară largă în .NET sunt Role-based Security, autentificarea şi
autorizarea, ca şi diverse tehnici criptografice. Prin mecanismele de suport al versiunilor, .NET permite
execuţia componentelor side-by-side. Acest lucru înseamnă că, daca o aplicaţie a fost construită cu o
anumită versiune a unei componente oarecare, iar o alta aplicaţie foloseste o versiune diferită a acelei
componente, cele două versiuni pot coexista paşnic pe acelaşi calculator. Fiecare aplicaţie va folosi
versiunea componentei cu care a fost construită şi testată, fară a ţine cont de cealalta versiune.

3.2 Limbajul C#
Tehnologia orientată pe obiecte şi-a demonstrat valoarea într-o multitudine de aplicaţii din cele mai
diverse domenii: electronica medicală, tranzacţii de valori mobiliare, sisteme de gestiune a informaţiilor
din întreprinderi, controlul traficului aerian, producţia de semiconductor, jocurile video interactive, reţele
de telecomunicaţii, cercetări în astronomie etc. La ora actuală există deja o bogata experienţă acumulată
în cadrul proiectelor care au adoptat tehnologia orientată pe obiecte - atât proiecte reuşite, cat şi proiecte
eşuate. In ambele cazuri, experienţa rezultată a constituit un ghid preţios pentru proiectele viitoare şi a
condus la o concluzie foarte importantă, anume ca modelul obiectual poate avea un impact benefic asupra

47
dezvoltării software, dar că un proiect necesită mult mai mult decât simpla venerare a acestei tehnologii.
Din perspectiva proiectanţilor de software lucrurile se văd cam în felul următor: la ora actuală chiar şi în
spatele celor mai obişnuite activităţi dintr-o societate industrializată (telefonie, tranzacţii de acţiuni,
conducerea automobilelor, examinări medicale) se află programe sofisticate; software-ul s-a infiltrat tot
mai adânc în societatea umană, ceea ce creează o cerere tot mai mare de specialişti.
După mai mulţi ani de inactivitate pe piaţa compilatoarelor, Microsoft apare cu o tehnologie
nouă, .Net (dot net), încercând sa reducă cît de cît popularitatea crescândă a platformei Java pentru
soluţiile Enterprise. Noutatea introdusa este C# având o sintaxa asemănătoare cu cea din C++ si Java. În
platforma .NET putem avea clase, interfeţe, tablouri, delegări, structuri şi enumerări. Totuşi, eu cred că nu
este corect să compari direct C# (un limbaj de programare) cu Java. Java nu e o tehnologie unitară, e o
platformă care cuprinde un set de tehnologii: atât un limbaj de programare cât şi un mediu de execuţie,
librării standard, protocoale de comunicaţie gen RMI.
C# e un limbaj la fel de simplu ca Java, ca sintaxa, însă e mai evoluat, sau cel puţin mai bine gândit
decât Java.
De fapt asemănarea dintre C# şi Java e doar de suprafaţă, în realitate C# e mult mai apropiat de
C/C++ decât de Java. Tehnologii .NET Frameworks are o serie de avantaje: suportă limbaje gen C/C++,
Perl, VB, Python, etc. Spre deosebire, platforma Java suportă doar limbajul Java (mă refer la mediile de
dezvoltare comerciale şi nu la limbaje de interes academic). Există de asemenea avantaje de performanţă
ale platformei .NET legată de viteza de execuţie a codului .NET, foarte apropiată de performanţa codului
nativ x86, sau avantaje ţinând de suportul nativ pentru servicii Web. Însă .NET la origine nu a fost gândit
ca un concurent al lui Java ci mai mult ca un mediu de execuţie care să ofere suport foarte simplu pentru
componente şi servicii Web din diverse limbaje. Deci .NET e mai degrabă o reincarnare a tehnologiei
COM. Din acest punct de vedere, .NET îşi propune rezolvarea problemei interoperabilităţii: cum fac să
comunic două aplicaţii X şi Y extrem de diferite, scrise în limbaje diferite? Răspunsul .NET este: prin
componentizare, la nivel de intranet sau prin servicii web (XML/SOAP/WSDL) la nivel de Internet. .NET
are suport foarte bun pentru reutilizarea codului existent fără a fi necesara rescrierea acestuia. Mediul
.NET Frameworks de la Microsoft este destinat doar platformelor Windows. Însă, cel puţin în teorie,
.NET este independent şi el de platforma şi sistemul de operare; oricine poate scrie un echivalent al lui
.NET în Linux de exemplu, dat fiind că formatul binar al executabilelor .NET este independent de maşină
iar setul de clase standard expuse de .NET nu depinde de API-ul Windows. Există standarde deschise
privitor la limbajul C#, formatul binar al executabilelor .NET cât şi al setului principal de biblioteci .NET.
În .NET, aceste neajunsuri sunt eliminate într-o măsură însemnata datorita sistemului standard de
tipuri - CLS. Până în prezent, implementarea colecţiilor, de exemplu, se făcea pe baza faptului ca, în CLS,
toate tipurile sunt derivate din Object.
Codul generic preia ca argumente si tipurile de date cu care lucrează. Între codul generic din C++ si

48
cel din C# exista câteva diferenţe importante. Cea mai semnificativa consta în faptul ca, spre deosebire de
C++, unde codul este instanţiat la compilare, în .NET, codul generic din C# are un corespondent direct în
limbajul intermediar si este instanţiat la rulare, prin compilare Just in Time (JIT). În anumite condiţii,
codul poate fi instanţiat şi la instalare, prin NGEN.
În .NET, după cum spuneam, codul generic din C# este transformat în limbaj intermediar (IL)
generic. De exemplu, daca scriem un algoritm de sortare, putem sa îl facem generic, astfel încât sa poată
opera fără probleme pentru tipuri întregi, în virgula mobila sau pentru şiruri, si putem distribui cod binar
care conţine doar instrucţiunile generice.La rulare, acestea sunt transformate în cod propriu-zis, după
câteva reguli simple: în cazul în care o clasa/functie generica este instantiata cu tipuri referinţă, va exista
o singura copie a codului pentru toate instantele care folosesc exclusiv tipuri referinţă. În cazul în care la
instantierea tipurilor generice se folosesc tipuri valoare, va fi creata câte o copie a codului, specializata
pentru fiecare dintre aceste tipuriÎn condiţiile în care importanta codului managed creste de la o zi la alta,
aceasta caracteristica a cărei lipsa a fost reproşata până acum creatorilor .NET se integrează în ansamblul
de instrumente ce alcătuiesc noua generaţie de instrumente de dezvoltare pentru Windows.

3.2 Descrierea aplicaţiei


În figura 3.1 este prezentată interfaţa sistemului informaţional de gestiune a serviciilor de cazare
într-un camin. Pentru a accesa sistemul, utilizatorul trebuie să se autentifice. Toate drepturile sunt dirijate
de administrator.

Figura 3.1 – Interfaţa sistemului informaţional


49
În figura 3.2 sunt indicați utilizatorii sistemului informațional. La necesitate, datele destre utilizatori
pot fi modificate, adică există posibilitatea de a adăuga sau șterge utilizatori.

Figura 3.2 – Utilizatorii sistemului

Odată logaţi fiecare utilizator poate gestiona datele sistemului informaţional, adică poate vizualiza
datele, modifica datele. În figura 3.3 este prezentată fereastra de dialog pentru gestionarea locatarilor
căminului. Sunt posibile următoarele operaţiuni:

a) vizualizarea datelor;
b) adăugarea datelor;
c) modificarea datelor;
d) ştergerea datelor;
e) căutarea datelor.

Figura 4.3 – Gestionarea locatarilor


50
În caz că locatarul este cazat, atunci există necesitatea de a completa fişa personală a locatarului. În
figura 3.4 este prezentată fereastra de dialog pentru înregistrare.

Figura 3.4 – Înregistrarea datelor personale

De asemenea, există posibilitatea de a vizualiza toate camerele căminului. La necesitate datele pot fi
sortate după un criteriu anumit: camere rezervate, libere sau toate. În figura 3.5 este reprezentată opţiunea
de vizualizare a camerelor.

Figura 3.5 – Vizualizarea camerelor

51
Sistemul este proiectat dinamic, de aceea la necesitate se poate de modificat numărul de camere.
Spre exemplu, din anumite motive o parte din camere nu erau întrebate şi administrarea decide de a
îmbunătăţi condiţiile de cazare – deci ele nu erau vacante. În urma modificărilor, ele pot fi incluse din nou
în circuit, deci apare necesitatea de a introduce datele în BD. În figura 3.6 este prezentată fereastra de
dialog la introducerea camerei şi serviciilor incluse în ea.

Figura 3.6 - Adăugarea camerei

În cazul necesităţii generării dărilor de seamă cu privire la gradul de completare a camerelor cu


locatari se poate de imprimat raportul cu privire la aceste date.
În figura 3.7 este prezentat modelul raportului.

Figura 4.7 – Generarea raportului

Prezentul SI permite salvarea, exportarea datelor in diferite formate, cum ar fi .doc, .xls, .pdf, etc. în
conformitate cu cerinţele înaintate acestui raport.
52
4 Argumentarea economică a proiectului

4.1 Descrierea SI

În prezent produsele soft se implementează foarte rapid, din cauza dezvoltării enorme a
tehnologiilor informaţionale, acumulării cunoştinţelor şi bibliotecilor de date, creării reţelelor pentru
comunicare şi schimb de informaţii.
Produsul dat constă în monitorizarea procesului de cazare în cămin, precum şi vizualizarea
informaţiei despre gradul de ocupare a lui.
Sistemul pe care l-am proiectat este destinat acumulării şi sistematizării informaţiei referitor la
datele proceselor de lucru, precum şi a utilizatorilor ce sunt restricţionaţi în drepturi de a accesa anumite
procese.
Sistemul informaţional (SI) prevede următoarele funcţii:
- adăugarea, editarea, vizualizarea datelor despre cămine;

- adăugarea, editarea, vizualizarea datelor despre camere;

- vizualizarea şi generarea rapoartelor privind gradul de ocupare a căminului.

Pentru realizarea proiectului vom folosi instrumentul de proiectare Enterprise Architect. Interfaţa
sistemului informaţional de gestionare a bazei de date este elaborată în limbajul de programare C#.

4.2 Plan calendaristic

În continuare voi prezenta planul calendaristic elaborat în procesul desfăşurării proiectului:


- determinarea obiectivelor;

- evaluarea volumului de lucru;

- determinarea timpului necesar pentru realizarea proiectului.

Pentru realizarea obiectivelor, determinate la etapa iniţială este necesar de planificat resursele de
timp disponibile (necesare):
- - pentru pregătirea efectuării lucrării vor fi necesare două săptămâni, în acest timp se va studia
cerinţele utilizatorului, tehnologiile asemănătoare de prelucrare a informaţiei, vor fi instalate
sistemele necesare efectuării lucrării;
- - elaborarea va durat trei luni. Pe acest parcurs se va mai lucra cu utilizatorii numai la finisarea
unei părţi a sistemului, pentru a verifica dacă corespunde cerinţelor şi nu necesită schimbări;

53
- întocmirea planului calendaristic.
Tabelul 4.1 - Planul calendaristic
Nr. Persoane Perioada
Denumirea acţiunii Note
crt. implicate (zile)
Man. 3
1 A fost alcătuită sarcina de lucru. P.1 4 Sarcina a fost primită.
P.2 4
Man. 3 Analiza sarcinii,
2 Acceptarea sarcinii. P.1 3 culegerea şi studierea
P.2 3 literaturii.
Man. 1
A fost efectuată analiza sarcinii şi Alegerea metodei de
3 P.1 3
selectarea literaturii soluţionarea a sarcinii.
P.2 4
Au fost elaborate diagramele Use
P.1 5 Alegerea metodei după
4 Case şi de Interacţiune pe baza
P.2 5 diagrama de interacţiune.
funcţiilor sistemului
Man. 1 Au fost instalate limbaje
5 A fost selectat soft-ul P.1 1 de programare de nivel
P.2 1 înalt
Man. 2 Pentru fiecare sarcină au
A fost aleasă metoda de
6 P.1 1 fost definite metode de
soluţionare a sarcinii soluţionare a lor.
P.2 1
S-a elaborat structura P.1 15 Au fost schiţate ferestre şi
7
programului P.2 15 funcţiile lor.
Man. 1 Studierea literaturii de
A fost studiată literatura pentru
8 P.1 3 prelucrare a documentelor
crearea programului
P.2 3 electronice
1
Au fost create interfeţele Man.
9 2 Studierea literaturii
principale ale sistemului P.1
Man. 1
Sau alcătuit procedurile de
10 P.1 2 Alcătuirea codului
lucru
P.2 2
Man. 1
Testarea funcţiilor
11 A fost verificat programul. P.1 3
sistemului
P.2 2
Continuare tabel 4.1
Au fost efectuate ultimele P.1 1 Testarea funcţiilor
12
schimbări P.2 1 sistemului

54
Programul este gata pentru Man. 1
13
exploatare P.2 1
Total 46

În Tabelul 4.1 am prezentat planul calendaristic care include informaţia referitoare la executarea în
timp a acţiunilor planificate
Pentru realizarea obiectivelor, determinate la etapa iniţială este necesar de planificat resursele de
timp disponibile (necesare).
Din acest tabel se poate de determinat planul calendaristic al sistemului, care include informaţia
referitoare la executarea în timp a acţiunilor planificate, denumirea acţiunilor, resursele utilizate şi unele
notiţe la acţiuni. La sistem v-or lucra 3 persoane şi rezolvarea sarcinilor va dura:
Managerul de proiect proiectului are lucrate 15 zile,
Programatorul nr. 1 care se va ocupa de alcătuirea interfeţelor principale ale sistemului are lucrate
43 zile.
Programatorul nr. 2 care se va ocupa de alcătuirea bazei de date are lucrate 42 zile.

4.3 Determinarea costului proiectului

Pentru evaluarea economică a proiectului, trebuie să determinăm eficienţa utilizării rezultatelor de


realizare a programului.
Compartimentul acesta serveşte drept bază pentru concluzia dacă proiectul este eficient din punct de
vedere economic.
Argumentarea economică constă din determinarea următoarelor caracteristici:
- preţul de cost – costul produsului final (1 copie );

- preţ de realizare – preţul de realizare a unei copii a produsului;

- indicatori financiari – tabelul de indicatori financiari al proiectului.


Toate calculele sunt efectuate în lei moldoveneşti (MDL). Preţurile materialelor, precum şi plăţile
salariale sunt actuale. Calcularea bugetului reprezintă determinarea sumei de bani şi cuantumului de
active materiale şi nemateriale necesare pentru realizarea proiectului.

Cheltuieli materiale directe. Pentru evaluarea eficienţei economice, calculăm cheltuielile de la


efectuarea programului, tabelul 4.2.
Tabelul 4.2 – Cheltuielile materiale directe
55
Nr. crt. Denumirea Preţul,(lei) Cantitatea Suma, (lei)
1 Compact Disk 5 3 15
2 Pixuri 1,50 2 3
3 Caiet pentru note 2 1 2
4 Flash Memorie 250 1 250
Total 270

Suma a fost obţinută prin înmulţirea preţului materialului la cantitatea procurată. Totalul a fost
obţinut prin sumarea sumelor. În tabelul consumurilor materiale directe s-au efectuat calcule pentru
materialele care au fost folosite în elaborarea sistemului.
Retribuirea muncii. Consumurile salariale directe se vor calcula în baza manoperei directe a
executantului proiectului. Contribuţiile sociale constituie 23%, iar asistenţa medicală 3,5% din suma
consumurilor salariale directe. Rezultatele se vor înscrie în tabelul numărul 4.3.

Tabelul 4.3 – Retribuirea muncii


Salariul Fondul de
Nr. crt. Lucrătorul (funcţia) Volumul de lucru pe unitate salariu de baza,
(lei/oră) (lei)
1 Manager 15 100 1500
2 Programator 1 43 75 3225
3 Programator 1 42 70 3024
Totalul fondului de salarii necesar pe proiect, lei 7749
Fondul social (23% din fondul de salarii), lei 1782,27
Prima de asigurare medicală obligatorie (4%), lei 271,16
Totalul cheltuieli privind remunerarea muncii, lei 9842,43

De la salariul obţinut, calculăm contribuţiile la Fondul Social şi contribuţii pentru Asigurarea


Medicală conform regulamentului în vigoare. Se calculează 23% contribuţii la Fondul Social şi 4% la
Asigurarea Medicală de la fondul de retribuire a muncii.
Fondul social =(Sumasalariuluix23%) : 100% (4.1)

Asigurarea medicală = (Sumasalariuluix4%) : 100% (4.2)

În conformitate cu aceste formule s-au efectuat calculele:

Fondul social = (7749 x23%) : 100%= 1782,27 (lei).

56
Asigurarea medicală = (7749 x4%) : 100%= 271,16 (lei).

Total cheltuieli salariale = 7749 + 1782,27 + 271,16 = 9842,43 (lei).

Cheltuielile indirecte. În tabelul 4.4 sunt redate cheltuielile indirecte ce au fost suportate pentru
îndeplinirea proiectului.

Tabelul 4.4 – Cheltuieli indirecte


Unitate
Nr. Cantitate Valoarea totală,
Nomenclatorul de Lei
crt. necesară lei
măsură
1. Energie electrica Kw/h 1.58 178 281,3
2. Servicii Internet abon 175 2 350
abon./lu
3. Servicii Telefon 150 2 300
na
TOTAL 1636

Toate calculele s-au făcut pe perioada executării proiectului luându-se în calcul numărul orelor şi
costul unei unităţi utilizate la urmă obţinând totalul cheltuielilor indirecte suportate.

Calculul Fondului de Amortizare. Amortizarea activelor materiale si nemateriale utilizate in proiect


reprezintă un element al costului de elaborare a proiectului. In acest scop vom aplica următoarea formula
de calculul fondului de amortizare:

FA = (MFi : T ) × T1 (4.3)
unde:
MFi– valoarea iniţiala (de intrare) AMTL;
T – termen de funcţionare utilă a activului;
T1 – durata proiectului.
Vom prezenta informaţia tabelar, tabelul 4.5:

Tabelul 4.5 – FA activelor materiale pe termen lung


Valoa Fond de
Termenul
Nr. rea amortizare AMTL
AMTL supus uzurii de funcţionare
crt. uzurabilă, pe durata
utilă, luni
lei proiectului, lei

57
1. Calculator 7000 36 291,66
2. Imprimanta 1200 24 75
TOTAL 366,66

În tabelul 4.5 sunt reprezentate calculele privind Fondul de amortizarea activelor materiale pe
termen lung. Suma totală a Fondului de amortizare fiind de 366,66 lei.
În tabelul 4.6 sunt reprezentate calculele privind amortizarea softului.
Tabelul 4.6 – Amortizarea softului

Sisteme Costul, T, Amortizare soft pe


T1, luni
Soft lei Luni durata proiectului, lei

Windows XP 2400 24 1,5 150


C# 3600 24 1,5 225
Office 1200 24 1,5 75
Total 450
Suma amortizării fiind de 450 lei.

Preţul de cost. Suma necesară pentru realizarea acestui proiect este arătat în tabelul 4.7.
Tabelul 4.7 – Suma cheltuielilor suportate în etapa de elaborare
Nr. Structura devizului de
Articole de calculaţie Valoarea,lei
crt. cheltuieli, %
1 Consumuri materiale directe 270 2
2 Cheltuieli indirecte 1636 13
3 Fondul de retribuire a muncii 7749 62
4 Fondul Asigurări Sociale 1782,27 14
5 Prime Asigurări Medicale 271,16 2
6 Fondul Amortizare AMTL 816,66 7
TOTAL 12525.09 100
Din acest tabel putem deduce că acest proiect nu este prea scump. Valoarea maximă atingând o cotă
de amortizare a utilajului folosit, deoarece noi am utilizat tehnică foarte avansată suma de amortizare va
creşte însă pentru utilizarea proiectului dat se pot folosi echipamente la un preţ mult mai jos care nu se va
reflecta asupra calităţii sistemului.

Figura 4.10 - Preţul de cost


Rezultatele financiare având la dispoziţie preţul de elaborare al unei copii de produs se poate de

58
determinat preţul de realizare pe piaţă a programului elaborat.
Suma profitului brut va fi calculată în baza ratei profitului care va fi planificată 20%. Deci preţul
de realizare va fi suma preţului de cost şi a profitului.
Deoarece lucrarea a fost elaborata in cadrul unui agent economic persoana juridica non platitoare de
TVA, impozitul dat nu va fi luat în calcule. (impozit pe profit-0%)
PB = 12525.09  0,2 = 2505,02 lei;
PR = PB + PC = 12525.09 + 2505,02 = 15030,11 lei;
PN = PB – IP, (4.4)
unde:
PB – profit brut;
PR – preţ de realizare;
PC – preţ de cost;
PN – profit net;
IP – impozit pe profit.

IP=2505,02×7%=175,35 (lei);
PN= 2505,02 - 175,35=2329,67 (lei);
Analizând toţi indicii calculaţi s-a ajuns la concluzia că acest proiect, din punct de vedere financiar,
dacă toţi ceilalţi factori vor fi evaluaţi corect este eficient şi proiectul poate fi realizat.
În timpul lucrului asupra softului am calculat timpul calendaristic care s-a folosit pentru realizarea
cererii, şi ce cheltuieli s-au obţinut în timpul efectuării acestui soft. Am introdus toţi participanţii care s-au
implicat la elaborarea şi implementarea unui astfel de sistem, pentru a-l lansa pe piaţă. Desigur, pentru a
realiza un aşa tip de sistem mai complex, toţi participanţii ar trebui să aibă studii superioare în domeniile
date, capacitate înaltă de muncă, şi mai ales programatorii şi designerii trebuie să cunoască mai multe
limbaje de programare, pentru a facilita citirea datelor şi aplicarea programului.
Concluzii

În cadrul acestui proiect a fost realizat un sistem informaţional de gestiune căminelor strudenţeşti.
Înainte de a începe lucrul asupra proiectului, au fost analizate metodologiile existente, avantajele şi
dezavantajele specifice lor. Am realizat un model bazat pe principiile POO, metodologii avansate care se
folosesc în modelarea contemporană. Au fost respectate etapele modelării, toţi paşii necesari pentru
obţinerea unui produs de calitate.
La implementarea sistemului a fost utilizat mediul de programare C#, care oferă posibilităţi foarte
largi de construire rapidă a aplicaţiilor, avînd la bază o bibliotecă puternică şi flexibilă.
Rezultatele obţinute la etapa actuală: structura relaţională şi informaţională a bazei de date; formele
electronice de introducere şi vizualizare (registre) a informaţiei; nomenclatoarele; rapoartele electronice

59
pentru afişarea informaţiei din registre ce urmează a fi prezentate.
De asemenea, au fost analizate cheltuielile ce ţin de elaborarea unui astfel de sistem informatic şi
analizate condiţiile de realizare a lui.

60
Bibliografia

1. Chindea M. E., Proiectarea sistemelor informatice economice, Bucureşti. 2003.


2. Dumitru Oprea, Analiza şi proiectarea sistemelor informaţionale economice, Editura POLIROM,
Iaşi 1999.
3. Florescu Vasile Fundamente teoretice si practice. – Bucureşti: Infomega, 2002
4. Т Конноли, К Бегг, А Страчан. Базы данных. Проектирование, реализация и сопровождение.
Теория и практика. М.: 2001. -1139 с.
5. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.:
Финансы и статистика, 1989. – 351 с.
6. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.
7. Sinan Albir, UML in a nutshell, New-York, Editura O’Reilly, 2004, 1, 24-217
8. Code Gear from Borland [resursă electronică]. – Mod de accesare: http://community.borland.com
9. Леоненков А. Самоучитель UML. М.:2003ю -580 с.
10. A Rational Approach to Software Development Using Rational Rose 4.0 [resursă electronică]. –
Regim de access: http://www.rational.com/support/techpapers/ roseapproach/. 1997
11. OMG Unified Modeling Language Specification (draft). Version 1.3R9 [resursă electronică]. –
Regim de access: http://www.rational.com/uml/ 1999.

61
Anexa A

Codul sursă

public partial class MainForm : Form


{
About about;
public int id_user = 0;
public string NAME_USER = "";
public bool ACCESSUSER = false;

Users usersFrm;

public MainForm()
{
InitializeComponent();
}

private void helpToolStripButton_Click(object sender, EventArgs e)


{
HelpOpen();
}

void HelpOpen()
{
if (about == null)
{
about = new About();

}
else
{
about.Dispose();
about = new About();
}
about.MdiParent = this;
about.Show();
}

private void MainForm_Load(object sender, EventArgs e)


{

private void aboutToolStripMenuItem_Click(object sender, EventArgs e)


{
HelpOpen();
}
public void SetAccessForUser(int id, bool access, string name)
{
id_user = id;
NAME_USER = name;
ACCESSUSER = access;
if (access)
{
toolsToolStripMenuItem.Enabled = true;

}
else
{
toolsToolStripMenuItem.Enabled = false;

62
private void MainForm_Load_1(object sender, EventArgs e)
{
//DateTime dt = new DateTime(2008, 09, 01);
//if (DateTime.Now > dt)
//{
// MessageBox.Show("Access dinied. The program can be use", "Error",
MessageBoxButtons.OK, MessageBoxIcon.Error);
// Application.Exit();
//}
//else
{
LogForm logFrm = new LogForm(this);
this.Enabled = false;
logFrm.ShowDialog();

}
}

private void customizeToolStripMenuItem_Click(object sender, EventArgs e)


{
if (usersFrm == null)
{
usersFrm = new Users(id_user);

}
else
{
usersFrm.Dispose();
usersFrm = new Users(id_user);
}
usersFrm.MdiParent = this;
usersFrm.Show();
}

private void exitToolStripMenuItem_Click(object sender, EventArgs e)


{
this.Close();
}

private void keepOutToolStripMenuItem_Click(object sender, EventArgs e)


{
SetAccessForUser(0, false, "");
LogForm logFrm = new LogForm(this);
this.Enabled = false;
logFrm.Show();
}

private void odaieToolStripMenuItem_Click(object sender, EventArgs e)


{
GridviewDesigner grid = new GridviewDesigner("persons",NAME_USER);
grid.ShowDialog();
}

private void acomoditatiToolStripMenuItem_Click(object sender, EventArgs e)


{
GridviewDesigner grid = new GridviewDesigner("Camere",NAME_USER);
grid.ShowDialog();
}

private void floorToolStripMenuItem_Click(object sender, EventArgs e)


{
GridviewDesigner grid = new GridviewDesigner("Rezervarea",NAME_USER);
grid.ShowDialog();
}
private void newToolStripButton_Click(object sender, EventArgs e)
{

AddComenzi comanda = new AddComenzi("Rezervarea", "Add", null, null,


NAME_USER); comanda.ShowDialog();

63
}

private void openToolStripButton_Click(object sender, EventArgs e)


{
GridviewDesigner grid = new GridviewDesigner("Rezervarea",NAME_USER);
grid.ShowDialog();
}

private void toolStripButton1_Click(object sender, EventArgs e)


{
GridviewDesigner grid = new GridviewDesigner("Camere", NAME_USER);
grid.ShowDialog();
}

private void toolStripButton2_Click(object sender, EventArgs e)


{
GridviewDesigner grid = new GridviewDesigner("persons", NAME_USER);
grid.ShowDialog();
}

public partial class Rezervarile : Form


{
string nameClient = "";
public Rezervarile(string condition)
{
InitializeComponent();
nameClient = condition;
FillDG();
this.Text += " " + condition;

private void Rezervarile_Load(object sender, EventArgs e)


{

void FillDG()
{
BLL bll = new BLL();
bll.FillDG1(dataGridView1, nameClient);
}
}

public partial class Add_Personal : Form


{
string TableName;
string action;
BLL logigObj = new BLL();
GridviewDesigner designer;
Dictionary<string, string> columns;
int id;
public Add_Personal(string TableName, string action, GridviewDesigner
designer,Dictionary<string,string> columns)
{
InitializeComponent();
this.TableName = TableName;
this.action = action;
buttonSave.Text = action;
this.Text = action + " " + TableName;
this.designer = designer;
this.columns = columns;
}
private void buttonCacel_Click(object sender, EventArgs e)
{
this.Close();
}
private void buttonSave_Click(object sender, EventArgs e)
{

64
Dictionary<string, string> collection = new Dictionary<string, string>();
TextBox txtbox = new TextBox();
DateTimePicker cb = new DateTimePicker();
RadioButton rb = new RadioButton();
foreach (Control control in this.panel1.Controls)
if (control is TextBox)
{
txtbox = (TextBox)control;
collection.Add(txtbox.Name, txtbox.Text);
}
else if (control is DateTimePicker)
{
cb = (DateTimePicker)control;
collection.Add(cb.Name, cb.Text);
}
else if (control is RadioButton)
{
rb = (RadioButton)control;
if (rb.Checked)
{
collection.Add("Gender", rb.Text);
}
}
logigObj.AddEditRegInNomenclator(TableName, collection, action,id);
designer.FillGridView();
Close();
}

private void Add_Personal_Load(object sender, EventArgs e)


{
if (action == "Edit")
{
foreach (Control control in this.panel1.Controls)
foreach (KeyValuePair<string, string> key in columns)
{
if (control.Name == key.Key)
control.Text = key.Value;

}
id = int.Parse(columns["id"]);
if (columns["Gender"] == "male")
GenderMale.Checked = true;
else
GenderFemale.Checked = true;

}
}
}

65

S-ar putea să vă placă și