3.

Managementul proiectelor informatice

3.1. Aspecte definitorii i organizatorice
Managementul proiectelor1 este o strategie managerial aplicat mai ales n informatizri i investiii de alt natur. Ea presupune constituirea unor echipe de specialiti n analiza, proiectarea i implementarea de aplicaii informatice i implicarea de specialiti din diferite compartimente funcionale, mai ales de contabilitate, comercial i de management a resurselor umane. Echipele de proiect au ca obiectiv lansarea i realizarea proiectului cu respectarea specificaiilor tehnice, a termenelor de execuie i a bugetului de cheltuieli. Existena i funcionarea unor astfel de echipe implic dou probleme organizatorice importante: integrarea echipei de proiect n structura organizatoric a firmei (de investiii) i crearea unei structuri organizatorice pentru proiectul n sine . n structura organizatoric funcional a societilor comerciale integrarea acestei metode de management se realizaz prin integrarea proiectului n organizarea funcional a firmei. Managementul proiectului este subordonat compartimentului funcional, de regul, de contabilitate, care poate avea rolul cel mai important n implementarea lui. Pe baza celor menionate, sinteza avantajelor i a dezavantajelor managementului prin proiecte este redat n tabelul 3.1. Aa cum am menionat la analiza structurilor manageriale i de control, managementul prin proiecte confer multiple atuuri de finalizare eficient a unor obiective importante ale societilor comerciale, cum este cel al informatizrilor, dar implic i capcane, cum este cea a perturbrii sistemului de reglare existent nainte de implementarea noii structuri. Fa de organizarea funcional clasic, organigrama unei societi comerciale n care se implementeaz managementul prin proiecte se poate prezenta ca n figura 3.1, care reflect organizarea pe proiecte pur. n cadrul fiecrui proiect (de analize conjucturale, oferta de produse, tehnologii de producie , de informatizare etc.), managerul are autoritate i responsabilitate deplin. Un proiect constituie o entitate autonom distinctiv n cadrul structurii firmei, cu propriul su personal tehnic, propria administraie, relaionat de organizarea de ansamblu (doar) prin rapoartele periodice pe care managerul de proiect trebuie s le prezinte conducerii strategico-tactice. Unele societi comerciale prevd proceduri foarte detaliate n ceea ce privete administrarea, finanele, personalul i controlul n cadrul proiectului, n timp ce altele acord o libertate mai mare sau mai redus n
1

www.ase.ro/teza_capitol.pdf

97

acest sens. n ultima instan, combinaia clasic - modern este dependent de mrimea i perspectivele organizaiei, de cerinele i posibilitile existente. AVANTAJE 1. Centralizarea resurselor similare. 2. Disponibilitatea forei de munc. 3. Stabilitate mare. 4. Standarde profesionale nalte. 5. Asigur o flexibilitate maxim n utilizarea personalului. Experii pot fi implicai temporar n proiect, apoi retrimii la munca lor obinuit. 6. Experii pot fi utilizai n cadrul mai multor proiecte. 7. Specialitii implicai n cadrul proiectului pot apela la colegii lor din cadrul compartimentului funcional din care provin pentru a face schimburi de cunotine i experien, ceea ce poate constitui o surs de soluii creative i sinergice pentru problemele proiectului. 8. Posibilitatea asimilrii unor noi tehnologii performante. 9. Permite utilizarea n cadrul proiectului a acelorai proceduri tehnice i manageriale folosite i la nivelul firmei. 10. Specializare n cadrul funciilor. 11. Menine parcursurile normale de evoluie n carier din cadrul organizaiei. DEZAVANTAJE 1. Numr mare de niveluri ierarhice. 2. Lipsa unei vederi de ansamblu a proiectului pentru majoritatea personalului implicat. 3. Clientul nu este n centrul preocuprilor. Unitatea funcional creia i este subordonat proiectul are propriile sale sarcini de realizat i acestea prevaleaz de obicei fa de cele ale proiectului. 4. Unitatea funcional tinde s fie orientat ctre realizarea i controlul activitilor tehnice i nu ctre problemele globale ale proiectului. 5. Nu i se acord unei singure persoane ntreaga responsabilitate pentru proiect. 6. Motivaia echipei de proiect este slab deoarece proiectul este perceput ca un aspect marginal n cadrul activitii firmei. 7. Poate favoriza apariia rivalitii i competiiei neloiale ntre echipele de proiect n lupta acestora pentru acces la resursele organizaiei. 8. Succesul este totdeauna nsuit, iar eecul nu aparine nimnui. 9. Rezisten n faa schimbrii. 10. Proces lent de luare a deciziei.

Tabelul 3.1.- Implicaiile managementului prin proiecte

98

Figura 3.1- Organigrama pentru managementul prin proiecte

ntro concepie modern, aplicabil n ntreprinderi inteligente, racordate la internet, managementul prin proiecte este asociabil cu organizarea matricial, reprezentat n figura 3.2. Nodurile structurii pot reprezenta centre de decizie, formate din specialitii antrenai n rezolvarea problematicii aflate la intersecia linie (manager proiect) coloan (specialiti de marketing, ingineri, contabili etc.).

Fig. 3.2- Organigrama ntreprinderii matriceale 99

Avnd n vedere avantajele i dezavantajele specifice fiecrei forme de organizare, se poate opta pentru o combinaie de structuri, avnd n vedere condiiile specifice fiecrei firme. Managementul i marketingul informatizate se realizeaz prin integrarea orizontal (funcional) i vertical (ierarhic) de aplicaii, ca proiecte finale executabile, menite a facilita exercitarea funciilor ntreprinderii i ale conducerii. Rezult sisteme informatice de gestiune i de asistare a deciziilor de tratare i folosire optimal a informaiei economico-financiare i cu caracter social. Datele i cunotinele din colecii pot fi organizate n fiiere independente (relative la o anumit problem), n fiiere integrate, n baze de date centralizate sau distribuite (n reele de calculatoare). Corespunztor modului de organizare a datelor, aplicaiile informatice pot fi: independente; integrate care comunic direct (online, n timp real) sau indirect (off-line) n soluionarea problemelor complexe. Exploatarea unui sistem (aplicaii) informatic(e) se poate face centralizat sau cu distribuire parial sau total, n funcie de posibilitile sistemelor de calcul disponibile i concepia de ansamblu prestabilit. n esen, managementul prin proiecte presupune numirea unui manager general al proiectului de finalizare a unui obiectiv important (automatizare, proiectarea i lansarea de produse noi, realizarea unor retehnologizri etc.) care devine rspunztor de organizarea i desfurarea aciunilor din faza de lansare a proiectului i pn la finalizarea lui. Managerul i alege echipa (subordonaii) i colaboratorii n funcie de condiiile specifice ale organizaiei sau ale organizaiilor n care urmeaz s fie realizat finalizarea aciunilor de implementare a proiectului.

3.2. Metodologii de management prin proiecte privind informatizrile 3.2.1. Strategia clasic
Principalele etape de lucru i specificaii de realizare ale unui proiect informatic, n concepia clasic, dedus din experiena specialitilor n analiza i conceperea de sisteme informatice, sunt: 1. - elaborarea temei de realizare cu specificarea cerinelor i a restriciilor sistemului, ca potenial baz juridic de reglementare a raporturilor proiectantbeneficiar (utilizator); 2. - proiectarea de ansamblu care, n general, este similar aciunilor de elaborare ale unui studiu tehnico-economic pentru investiii de natur industrial. Ea const n a stabili, pe coordonatele unui proiect director de informatizare, concepia global a sistemului informatic, structura acestuia, prioritile de
100

realizare, necesitile i posibilitile economico-financiare ale utilizatorului, eficiena scontat. Importana etapei deriv din faptul c este ultima n care analiza vizeaz ansamblul aciunilor de prefigurare nu numai a viitorului sistem informaional-decizional, ci i conexiunile acestuia; 3. - proiectarea de detaliu sau tehnic a fiecrei componente de tip subsistem sau aplicaie, prin conceperea, ntro manier analitic, a tehnologiei tratrii informaiei pe traseul intrri- prelucrri- ieiri, prin elaborarea algoritmilor de programare i a specificaiilor de programare i exploatare viitoare a procedurilor tehnologiei. Un proiect tehnic rezultat trebuie s aib caracteristicile unui proiect elaborat pentru produse de natur industrial n care desenele de execuie (specificaiile de realizare) i fiele tehnologice (arborii de programare) definesc tehnologiile i reetele de fabricaie; 4. - programarea fiecrei componente prin scrierea programelor ntr-un mediu adecvat, testarea i integrarea lor n mediul pentru care au fost concepute; 5. - testarea procedurilor cu date reale n vederea omologrii i acceptrii lor de ctre beneficiar, implementarea lor n cadrul sistemului informatic (informaional); 6. - exploatarea i ntreinerea produsului informatic rezultat, urmrind prin aceasta, mbuntirea performanelor acestuia. n fiecare etap se elaboreaz documentaii specifice, iar spre final, se completeaz i definitiveaz documentaia de prezentare, operare i ntreinere a produselor informatice nou create. Studierea realizrilor practice ale informaticii aplicate scot n eviden faptul c, n scopul asigurrii unei independene relative, un sistem informatic se structureaz (n general) funcional, urmrind asigurarea condiiilor pentru exercitarea funciilor sistemului de reglare. Astfel, ntr-o ntreprindere, subsistemele informatice sunt: de marketing, de cercetare- dezvoltare, de producie, comercial, financiar- contabil i de personal. Pe domenii de activiti sau compartimente, un subsistem se detaliaz n aplicaii (uniti funcionale), iar o aplicaie n proceduri automate i de interfa, ca uniti de prelucrare prin care managerii i executanii s poat obine informaiile dorite. De pild, subsistemul de producie al unei societi comerciale de tip productiv se constituie din aplicaii de programare, lansare, urmrire i control a fabricaiei; n funcie de necesiti, fiecare aplicaie este conceput ca un program sau ansamblu de proceduri de tratare a informaiei, n concordan cu tehnologia necesar obinerii informai ilor finale, avnd ca punct de plecare documentele primare i centralizatoare privind derularea fenomenelor i a proceselor de producie. n general, tipologia procedurilor pentru aplicaii de gestiune i de asistare a deciziilor cuprinde: - proceduri de culegere (i pregtire) a datelor din documentele primare (fie, facturi, chitane etc.) n documente (borderouri) de control centralizatoare
101

prin proiectarea de formulare de culegere i modificare a datelor . n prezent, culegerea datelor se face, tot mai frecvent, direct din documente primare sau centralizatoare. Adeseori, nsi documentele primare (facturi, chitane, fie de eviden etc.) sunt emise la calculator ; - proceduri de validare (control) al modului de preluare a datelor n procesul de tratare automat prin: verificarea corectitudinii codurilor utilizate; controlul ncadrrii coninutului unor cmpuri n liste sau cataloage de valori admise; verificarea denumirilor, a unitilor de msur i a coninutului altor cmpuri care au un caracter permanent n descrierile de date etc. n noile medii de programare (Microsoft Access, Visual FoxPro, Visual Basic) validarea datelor se poate face prin precizarea condiiilor de validare (opiunea Valid) la descrierea cmpurilor sau prin ncapsularea procedurii de validare la descrierea structurii bazelor (tabelelor) de date; - proceduri pentru sortarea i indexarea coleciilor de date n funcie de cerinele de prelucrare i informare. Dat fiind importana indexrilor pentru regsirea informaiilor n acces direct, cmpurile (atributele) de tip cheie pentru indexri se pot preciza la crearea structurii tabelelelor care constituie o baz de date astfel nct relaiile dintre tabele s se realizeze cu uurin, iar regsirea informaiilor s se poat face rapid. Mai mult, primul cmp al unui tabel, n mediul de programare Access, trebuie s fie de tip cheie primar care ia valori diferite (cum sunt numerele matricole, codurile pentru mrfuri, numerele de inventar pentru imobilizri corporale etc.); n cazul n care programatorul nu- i definete cheia primar, sistemul atribuie automat un numr de identificare unic pentru fiecare nregistrare inclus ntrun tabel; - proceduri relative la popularea structurilor de fiiere (tabele i baze de date) cu date prin definirea formularelor de culegere a datelor n cadrul prelucrrilor curente; - proceduri care asigur gestionarea coleciilor de date prin consultarea, actualizarea sau exploatarea fiierelor; - proceduri prin care se realizeaz conceperea i gestionarea modelelor prin care se elaboreaz i fundamenteaz deciziile; - proceduri privind protecia i securitatea datelor, n special prin folosirea facilitilor oferite de sistemele de operare etc. ntro aplicaie informatic, procedurile sunt grupate n funcie de momentele execuiei lor, astfel: proceduri de iniializare a sesiunii de lucru (privind datele de identificare a utilizatorului i a perioadei de operare, precum i pentru ncrcarea fiierelor de lucru necesare acordnd drepturi de acces la date persoanelor autorizate), proceduri curente de culegere a datelor noi i de prelucrri i consultri ale fiierelor la cererea utilizatorilor i proceduri finale de nchidere a

102

sesiunii de lucru (pentru obinerea situaiilor i a rapoartelor necesare i de s alvare a fiierelor aplicaiei). Integrarea prelucrrilor se face prin comenzi specifice limbajelor de programare sau meniuri i butoane structurate, astfel nct, la un moment dat, utilizatorul s poat selecta procedurile i aplicaile de care are nevoie. Strategia clasic este rezultanta experienei dobndite n crearea i exploatarea de sisteme informatice funcionale de gestiune economico - financiar n deceniile 6-8 ale secolului XX. Aplicarea ei se face i n prezent n multe societi comerciale i vizeaz ansamblul unei organizii (societi comerciale) sau / i domenii de activiti prin parcurgerea etapelor de lucru menionate. Activitile i rezultatele specifice au fost prezentate, pe larg, n literatura de specialitate2. Printre avantajele utilizrii strategiei clasice se menioneaz3: - planificarea i urmrirea riguroas a activitilor; - proiectarea complet i consistent a produselor informatice cu specificaii riguros elaborate; - integrarea uoar a componentelor ca urmare a proiectrii riguroase a interfeelor interne i a celor cu alte componente .a. n deceniul 8, concomitent cu apariia calculatoarelor profesionale i a mediilor de programare de generaia a IV-a, ideea crerii de sisteme informatice integrate la nivel de organizaii i domenii de activiti a fost, treptat, abandonat datorit unor incoveniente, cum sunt: - utilizatorii evalueaz facilitile produsului informatic abia dup testarea i integrarea lui n mediul real cnd eventualele incompletitudini necesit eforturi nsemnate de revizuire a ntregului produs; - proiectanii nu pot stabili concret performanele i eficiena produsului final (sistemului informatic) dect n etapele de experimentare i implementare a lui; - presupun cheltuieli ridicate de ntreinere a programelor; - costurile i duratele de realizare sunt mari; - durat de folosin relativ mic ca urmare a uzurii morale generat de evoluiile din tehnologiile de automatizri i din mediile de programare care implic frecvente conversii ntre medii de realizare i exploatare, precum i reconsiderri a ntregului sistem informatic. n demersul automatizrii unor activiti i lucrri economico -sociale, aplicarea strategiei clasice a impus concepte i metode specifice teoriei sistemelor, ca de pild:
2 3

.a se vedea,printre altele, Tribuna economic,numerele: 5,6,9,51-52/1998; 1/1999,20,22/2000. .Institutul de Tehnic de Calcul i Informatic - Indicaii metodologice pentru realizarea sistemelor informatice i a produselor program, vol. II, pag. 91-95, uz intern, Bucureti, 1987. 103

 - abordarea global (sistemic) de la general la particular (top down) sau / i de la particular spre general (bottom up); - structurarea i modularizarea sistemelor; - accentuarea rolului conexiunilor directe i inverse ntre componente; - reglarea i autoreglarea funcionrii sistemelor informatice; - modelarea i algoritmizarea proceselor informaional- decizionale; - aplicarea conceptelor de sistem deschis i de programe glisante (scenarii) .a. Eforturile analitilor / proiectanilor de sistem s-au concentrat, adeseori, spre creterea gradului de organizare i raionalizare a sistemelor informaionale din societi comerciale, cu toate c multe realizri s-au concentrat mai mult asupra transpunerii unor proceduri i lucrri manuale n proceduri automatizate. Ineficiena unor sisteme sau programe informatice s-a datorat, de multe ori, nu proiectanilor, ci modului n care beneficiarii de informaii au colaborat n organizarea aciunilor i i-au ajutat pe informaticieni s defineasc corect cerinele i restriciile tratrii informaiei.

3.2.2. Strategia prototipizrii

Existena unor probleme similare pentru uniti economico -sociale cu acelai profil al activitilor, prioritatea automatizrii unor funcii vitale ale unor organizaii, au stat la baza prototipizrii realizrilor informatice. Scopul vizat prin aplicarea strategiei prototipizrii este structurarea procesului de realizare a unui produs informatic necesar automatizrii funciilor critice ale unei societi comerciale (cum ar fi funcia de producie / managementul execuiei) sau standardizarea i tipizarea sistemelor informatice pe tipuri de organizaii . Spre exemplu, n preajma anului 1980, un colectiv al Institului Central de Conducere i Informatic din Bucureti a realizat o tehnologie informatic sub forma unui set de elemente tipizate adaptabil pe tipuri de ntreprinderi printr-o abordare de la general la particular, de la un sistem obiect reprezentativ (standard) la un sistem informatic specific mediului de implementare. n aplicarea strategiei prototipizrii, principiile de lucru sunt: - realizarea unui produs informatic prin construirea unuia sau a mai multor prototipuri pariale ale acestuia, ca modele reprezentative pentru funcii critice sau pentru facilitile care pot contribui esenial la buna funcionare a unei organizaii; - experimentarea i / sau dezvoltarea prototipurilor pariale n crearea produsului (prototipului) final; - definitivarea produsului informatic pe baza unui prototip al su. Un prototip este un model al comportrii produsului dorit care se realizeaz relativ repede cu cheltuieli mici i timp scurt de finalizare. Folosind prototipul,
104

utilizatorul poate aprecia soluiile preconizate de proiectant prin prisma realismului i a completitudinii lor. n acest mod, utilizatorii si clarific cerinele informaional- decizionale proprii filtrndu-le i selectnd soluiile de produs informatic cele mai eficace n desfurarea activitilor specifice. Pe baza experienei dobndite, prototipurile pariale se convertesc n produs final prin mbuntirea funciilor lor. Metamorfoza se realizeaz prin dezvoltarea iterativ a prototipului mai reprezentativ (pilot) adugnd noi caracteristici funcionale produsului care rspund cerinelor de informare, performane i calitate ale realizrilor informatice. ntrun context mai larg, n ideea proiectrii asistate la calculator, folosind instrumente de genul CASE- Computer Aide Systems Engineering, s-au creat sisteme informatice prototip pe tipuri de organizaii. Prin analiza i formalizarea analizei sistemului informaional existent, pe baza unui limbaj de descriere a sistemelor, se constituie colecii de date de descriere a sistemului exi stent (obiect). Cu ajutorul unui program-analizor, din compararea sistemului prototip cu sistemul obiect rezult liste cu diferenele semnalate. ntr-un proces iterativ, se adapteaz prototipul i se reconsider sistemul obiect rezultnd, n final, modelul noului sistem informatic. O astfel de concepie se apropie de condiiile proiect rii produselor i a tehnologiilor industriale prin care se asigur nu numai tratarea informaiei pentru gestiunea economico- financiar a societilor comerciale, ci i asistarea procesului de luare a deciziilor aplicnd politici manageriale moderne, cum sunt: managementul prin obiective, managementul prin excepii, managementul prin rezultate .a. Printre avantajele prototipizrii se remarc: - identificarea i analiza cerinelor informaional- decizionale ntr-un context mbuntit i cu participarea "consumatorilor" de informaii; - colaborarea eficient proiectant- utilizatori; - rezolvarea oportun i operativ a unor situaii de risc; - flexibilitatea i adaptabilitatea programelor create pe baz de prototipuri; - corectitudinea i completitudinea programelor rezultate i pe baza verificrilor fcute de utilizatori; - interfee om-calculator mai eficente i mai atractive; - uurina ntreinerii programelor (softului aplicativ) rezultate cu costuri reduse; - sensibilizarea, familiarizarea i transformarea managerilor i ale unor administratori n utilizatori nemijlocii de produse informatice etc. Cu toate atuurile menionate, aplicarea strategiei prototipizrii are unele neajunsuri, cum sunt: - incoerena i incompletitudinea proiectrii cnd abordrile sunt orientate pe activiti sau probleme legate de exercitarea funciilor critice ale organizaiei;

105

 - integrarea greoaie a componentelor funcionale prin lipsa unor specificaii de realizare complete privind conexiunile sistemului; - ineficiena prototipizrii n cazul aplicrii ei pentru rezolvarea de probleme clar definite sau cunoscute de proiectant. Pe baza celor semnalate, se poate aprecia c, pentru crearea de produse informatice de complexitate medie i ridicat, este mai eficient aplicarea une i strategii mixte prin concepia de ansamblu aplicnd metodologia clasic i prin programarea i integrarea programelor pe baz de prototipuri . Pentru soluionarea de probleme mai particulare cu caracter autonom, aplicarea strategiei prototipizrii garanteaz obinerea de soluii de calitate cu efecte benefice asupra eficienei sistemelor informaional- manageriale din societi comerciale. De altfel, prototipizarea st la baza noului mod de utilizare a mediilor de programare vizuale, bazat pe asisteni specializai care ofer instrumente de lucru complexe i pe vrjitori care predefinesc structurile de date i paii de lucru n gestionarea informaiilor.

3.2.3. Strategii orientate obiect

Cerinele stocrii unor cantiti tot mai mari de informaii, dezvoltarea mediilor de programare care pot surprinde i dinamica unei organizaii , orientarea automatizrilor spre realizri multimedia de integrri texte- imagini- sunete n convergena sistemelor informatice spre sisteme expert de inginerie a cunoaterii au dus la apariia i dezvoltarea strategiilor orientate obiect. Printre premisele i obiectivele acestor noi metodologii sunt relevate4: - posibiliti deductive i inductive superioare n argumentarea rezultatelor prin reprezentri directe ale entitilor lumii reale n mediul informatic; - creterea puterii de modelare a datelor asociind medii de programare bogate, cum este limbajul C++ dezvoltat dup anul 1983; - ameliorarea interfeelor cu utilizatorii prin accesul la produse vizuale de comunicare de mare calitate; - faciliti de prototipizare rapid a aplicaiilor; - luarea n considerare i a aspectelor dinamice, integrarea descrierilor structurale i comportamentale etc. n modelarea specific acestei strategii, un obiect al lumi reale are o tripl abordare: este "vzut" ca actor autonom ce rspunde la mesaje ceea ce permite simularea de procese paralele; n rolul de concept specific, obiectul asigur modelarea cunotinelor nglobnd, pe lng date, semnificaii ale datelor (semantica informaiei, cunotine i fapte asupra unor metodologii i activiti); ca
4

.Lungu I. .a.- Baze de date, Ed. All Educational, Bucureti, 1995, pag. 219-220. 106

i "cutie neagr" modelul asigur condiii de acionare asupra lui modularizat i s fie exploatat prin dialoguri sugestive. Aceste abordri creaz condiii ca un obiect s aib o tripl reprezentare: structural, ca o realizare (instaniere) a unui tip de dat, caracterizat printr-o structur ascuns prin operaii; conceptual pentru entitile lumii reale care pot fi specializate i dinamic pentru actori la care obiectul este autonom i activ rspunznd la mesaje. Esena abordrii orientat- obiect este definirea caracteristicilor obiectelor dintr-o aplicaie i realizarea interaciunii lor prin schimbul de mesaje . Xavier Castellani consider c metodologia i concepia orientate obiect introduc5: conceptul de serviciu n loc de operaie; noiunea de cunotin i conceptul de transmutaie privind transformrile obiectului. Aplicarea metodologiei presupune: metode de analiz i concepie a sistemului de obiecte (date/prelucrri independente i modele asociate de tip entitate-atribut-relaie); modelul conceptual al utilizatorului rspunznd la ntrebri de genul "ce?", "cnd?"; modelul detaliat (operaional) optimizat; nivelul logico-organizatoric de rspuns la cerine de tipul "unde?", "cu ce?", "cnd?"; nivelul fizic de rspuns la ntrebarea "cum se rezolv problemele?". n abordarea Orientat Obiect (OO), un program devine un ansamblu de obiecte care schimb mesaje generatoare de operaii sau metode de transformare a strii lor interne i de restituire a valorii unor parametrii. O baz de date- obiect conine obiectele programelor de aplicaii. Un obiect oarecare este persistent prin aceea c durata sa de via este superioar programului care la creat. Prin proiectarea unui obiect, acestuia i se asociaz o structur (atribute, cmpuri aparintoare) i funcionalitatea sa redat prin proceduri i funcii proprii clasei de obiecte. n acest fel, obiectele nglobeaz structuri de date i comportamente (operaii, metode). Strategia OO opereaz cu concepte specifice, cum sunt: - identitatea discret prin carea se distinge dintre alte identiti; - clasificarea: obiectele cu aceleai atribute i operaii se grupeaz n clase; fiecare obiect se poate considera ca o instan a unei clase; - polimorfism: aceai operaie, cu acelai nume poate s aib comportament diferit n clase diferite; implementarea concret a unei operaii ntro anumit clas poart denumirea de metod; - motenire: atributele i operaiile se transmit de-a lungul clasei bazate pe o relaie ierarhic; - abstractizarea: focalizarea pe aspectele eseniale ale unei entiti; pentru un obiect accentul se pune pe ce este acesta i ce trebuie s fac, naintea stabilirii
5

.Xavier C.-Methodologie generale d'analyse et de conception de systemes d'objets, Mason, Paris, 1993. 107

detaliilor de implementare ceea ce face s creasc importana analiz ei (analistul trebuie s deduc utilitile informaiei); - ncapsularea sau ascunderea informaiei presupune separarea aspectelor externe ale unui obiect care sunt accesibile altor obiecte de aspectele interne ale obiectului care sunt ascunse altor obiecte. Utilizatorul obiectului poate accesa anumite atribute i operaii ale obiectului, denumite publice, n timp ce alte atribute i operaii i sunt inaccesibile, avnd un caracter privat. Prin ncapsulare se mpiedic modificarea tuturor caracteristicilor unui obiect cnd se perfecioneaz algoritmi sau se elimin erori ceea ce face ca aplicaiile ce utilizeaz obiectul s nu fie afectate; - mpachetarea datelor i a comportamentului n acelai obiect astfel nct un obiect s conin structuri de date i operaii ce definesc clasa creia i aparine o anumit metod, chiar dac sunt mai multe operaii cu aceai denumire n clase diferite; - partajarea prin transmiterea acelorai structuri de date i operaii n clase din ierarhii de clase .a. n abordarea clasic descompunerea unui sistem este funcional, procedural; pentru abordarea OO devine esenial nelegerea sistemului prin prisma descompunerii lui n entiti- obiecte i al stabilirii relaiilor ntre obiecte devenind esenial diagrama sau diagramele obiectului prin care se rspunde la ntrebri de tipul "cine face?", "care sunt relaiile ntre cei ce fac?", "ce este sistemul?". O clas de obiecte poate fi considerat, la rndul ei, un obiect. Caracterizarea unui grup de clase se face prin conceptele de metaclas i ierarhie de clase. Activarea unui obiect se face prin mesaj de solicitare ca obiectul s efectueze o aciune sau s aplice una din metodele sale. Ansamblul mesajelor la care reacioneaz un obiect definete interfaa obiectului, modul cum obiectul este vzut din exterior. Obiectele comunic ntre ele prin mesaje. Transmiterea i primirea de mesaje stau la baza operaiilor din modelul OO. Comportamentul polimorfic necesit selectarea metodei adecvate clasei obiectului sau superclasei. Metodele pot fi actualizate. Operaiile de creare, modificare i tergere a definirilor de clas se pot implementa ca mesaje. O consecin a structurrii modelului i a operaiilor OO sunt regulile de integritate, ca de exemplu: - toate obiectele trebuie s respecte protocolul specificat prin definirea de clas. Ca urmare, un obiect poate rspunde doar la mesajele permise de clasa la care aparine; - ncapsularea obiectelor implic accesul limitat prin folosirea numai a protocolului de mesaje definit pentru clasa obiectului; - identificatorul unui obiect asigur , integritatea referitoare la acel obiect.

108

Comparativ cu modelul de date relaional, gestionat prin medii de programare de genul FoxPro, modelul OO prezint nouti importante6, cum sunt: din punct de vedere structural: - n locul schemei bazei de date intervine ierarhia de clase; - definiia tabelei este nlocuit cu definiia de clas; - nregistrarea sau tuplu din reprezentarea relaional se exprim prin instaniere de clas n reprezentarea OO; - n loc de cmp sau coloan apare variabila de instan; - conceptul de cheie primar este nlocuit cu cel de identificator obiect; - motenirea de clas nu are echivalent n modelul relaional; mutaii operaionale: - definirea, tergerea sau modificarea unei relaii de cmp este nlocuit cu definirea, tergerea sau modificarea unei clase sau variabile de instan; - adugarea unei linii sau nregistrri ntr-o tabel este echivalat cu crearea unei instane de clas sau a unui obiect individual; - definirea, modificarea sau tergerea unei metode din modelul OO nu au corespondent n modelul relaional; - selecia, jonciunea i proiecia din modelul relaional nu se regsesc n modelul OO; ca reguli de integritate: - integritatea identitii este reflectat prin identificatorul de obiect; - protocolul de obiect i ncapsularea din modelul OO nu au corespondene n modelul relaional. n aplicarea strategiei OO, un rol esenial l au conceperea de diagrame de reprezentare a strilor i a mutaiilor care au loc. Astfel de diagrame sunt: - diagramele de flux de date de descriere a modificrilor din sistem. n modelul funcional tranzaciile se pot reprezenta sub form de grafuri orientate n care nodurile sunt procese , iar arcele sunt fluxurile de date; - diagramele de stare, de caracterizare a evoluiilor n timp surpriznd "cnd se modific sistemul"; n cadrul modelului dinamic, se reprezint prin grafuri n care nodurile sunt stri, iar arcele sunt tranziii ntre stri, cauzate de evenimente externe. Se mai pot reprezenta sub form de reele PERT; - diagramele obiectelor descriu structura static a obiectelor din sistem i relaiile dintre ele rednd "ce se modific n sistem" sub form de grafuri cu noduri- obiecte i arce- relaii dintre obiecte. nc n 1978 un grup de cercettori francezi a elaborat metodologia Merise7 prin care se analizau sisteme pe baz de modele de date asociative entitate 6 7

.idem 1,pag. 228-230 .Collongus A., Hugues J., Laroche B.- Merise, Bordas, Paris 1989 109

atribute- relaii, completat ulterior cu celelalte tipuri de modele specifice abordrii OO i folosit cu succes i de specialiti romni8. Principalele activiti de analiz i proiectare OO sunt: - identificarea obiectelor i a claselor de obiecte; - elaborarea dicionarului (grilei) de date; - identificarea relaiilor dintre obiecte; - identificarea atributelor obiectelor i a legturilor dintre atribute; - organizarea claselor bazate pe motenire; - iterarea i rafinarea modelului grupnd i regrupnd clasele identificate i selectnd metodele de rspund la cerinele de informare; - organizarea ierarhizat a sistemului ca n cazul aplicrii strategiei clasice cu stabilirea prioritilor; - alocarea pe subsisteme a procesoarelor i a programelor de gestionare a structurilor de memorare a datelor i a resurselor globale; - alegerea implementrii programelor de control. Pentru societi comerciale, obiectele pot fi considerate entitile care definesc patrimoniul propiu: materii prime i materiale (stocuri pentru producie), costuri, mrfuri (stocuri de produse), imobilizri, angajai, furnizori, clieni, capita l propriu, capital mprumutat .a. Tot n categoria obiectelor se pot considera rezultatele unor activiti de cercetare, ca de pild: tehnologii de fabricaie (operaii de flux), reete de producie (norme de consum), cerea i oferta pieei, programe de lucru etc. Mai pot fi considerate obiecte entitile de tip administrativ: compartimente, centre de profit, centre de producie .a. Relaiile dintre obiecte sunt generate de procesele i tranzaciile care au loc n cadrul organizaiei, dar i cele privind legturile cu mediul exterior. n abordarea obiectelor ca actori, relaiile sunt reflectate de fluxurile care au loc ntre actori, iar prelucrarea i manipularea informaiei definesc procesele de transformare a fluxurilor. Suportul tehnic al prelucrrilor sunt bazele da obiecte (date, cunotine, fapte), iar rspunsurile la mesaje n procesele informaional- decizionale sunt rezultate prin inferenieri (inducii, deducii, abducii- ca deducii n funcie de scop). Eficiena prelucrrilor depinde decisiv de experii- umani care contribuie n echipele de analiz i proiectare la acumularea de cunotine bine formulate, conforme cu cerinele administrrii i ale managementului, exercitate tiinific. Indiferent de strategia aplicat, pentru conceperea i exploatarea de produse informatice performante un factor esenial al reuitei aciunilor l reprezint strnsa colaborare proiectant- utilizatori prin instrumente de lucru simple i sugestive. Un astfel de instrument l poate constitui tehnica diagramelor aplicat n succesiunea: diagrame orizontale de flux informaional- decizional pentru cunoaterea situaiei
8

.Davidescu N.- Sisteme informatice financiar-bancare, Ed. AllEducational, Bucureti,1998 110

existente i prefigurarea noului sistem n perspectiva informatizrii stabilind: modificrile de flux i necesarul de fiiere permanente i tranzacionale; scheme (organigrame) de sistem de reprezentare a principalelor proceduri de creare i gestionare a fiierelor; arbori de programare pentru meniurile de integrare a prelucrrilor; arbori de programare pentru procedurile meniului de prelucrare a fiierelor i de rspuns la cererile de informare.

3.3. Organizarea echipelor de analiz i proiectare a activitilor

Din experiena practic a realizrii tehnologiilor informaionale, bazate pe automatizri, s-au desprins, ca tehnici organizatorice9: (1) echipa programatoruluief; (2) echipa programatorului- ef revizuit; (3) echipa chirurgical; (4) organizarea democratic a programrii, (5) echipe organizaionale. 1). Echipa proiectantului / programatorului-ef. Scopurile urmrite n definirea, organizarea i desfurarea aciunilor sunt: - structurarea procesului de realizare a sistemului informaional decizional automatizat n vederea diversificrii activitilor realizate de specialiti; - asigurarea unui mediu de lucru care s favorizeze utilizarea eficient a instrumentelor proiectrii asistate de calculator de tipul generatoarelor (de formulare, de rapoarte, pentru ecranri .a.), a asistenilor specializai (pentru folosirea butoanelor, a listelor, a casetelor de dialog etc.) i a scurtturilor sau a vrgitorilor pentru folosirea unor componente predefinite prin macrocomenzi ale mediilor de programare; - asigurarea "vizibilitii" proiectului, a produsului informatic pe ntreg ciclul de realizare fie ca prototip, fie ca o versiune intermediar de dialog cu utilizatorii ; - prevederea unor modaliti de instruire a echipei dezvoltnd metode i tehnici noi de lucru, cum sunt instrumentele proiectrii asistate i de analize directe (on-line) ale proceselor de finalizare a aciunilor; - cunoaterea foarte bun a evoluiei proceselor tehnologice de ctre cel puin doi membri ai echipei. n ndeplinirea scopurilor, regulile de constituire i funcionare a echipei sunt: - definirea clar a funciei fiecrui component al echipei i a relaiilor dintre membrii ei;
9

D.Oprean,M.R.Abdel- TI&C: Proiectarea de tehnologii informaional-decizionale, Ed. Risoprint, Cluj-Napoca, 2001, pag. 17-19 111

- existena unui conductor tehnic permanent, ca ef de proiect, n persoana proiectantului sau a programatorului- ef; - facilitarea controlului administrativ, inclusiv privind consumurile i cheltuielile angajate n finalizarea proiectului; - simplificarea comunicrii cu echipele externe i alegerea unui limbaj adecvat de comunicare (cum ar fi, spre exemplu, diagramele de flux informaional, descrierile n pseudo- cod sau tabelele de decizii i organigramele); - evitarea situaiilor de impas n luarea deciziilor; - repartizarea sarcinilor pentru fiecare membru al echipei pe baza definirii riguroase a responsabilitilor; - informarea periodic asupra stadiului de realizare a produsului informatic; - evaluarea lejer a efortului depus de membri; -disciplina riguroas n proiectarea, programarea i implementarea proiectului. Echipa este alctuit , n principal, din proiectantul (programatorul) - ef, proiectantul / programatorul - verificator (lociitor), secretar i proiectani / programatori. Ea este direct rspunztoare pentru realizarea proiectrii tehnice (de detaliu), a programrii i a integrrii proiectelor / produselor informatice. 2). Echipa proiectantului / programatorului-ef revizuit. mprumutnd avantajele altor tehnici, principalele obiective vizate n echipa proiectantului / programatorului-ef revizuit sunt: - disciplinarea muncii ca i n cazul echipei proiectantului/programatorului ef; - specializarea pe funcii, cum se procedeaz n cadrul echipelor chirurgicale; - partajarea sarcinilor ntre membrii echipei, ca i n cazul organizrii democratice a programrii. Aceste obiective fac ca tehnica s aib un caracter integrator al celorlalte tehnici organizaionale ceea ce implic necesitatea ca managerul de proiect s aib responsabilitate i autoritate n conducerea echipei, fr ca aceasta s impun neaparat i posedarea unor caliti de super- specialist (programator), aa cum impune tehnica proiectantului / programatorului- ef. Aplicarea acestei tehnici presupune: - formalizarea organizrii procesului de realizare prin definirea clar i coerent a sarcinilor de execuie tehnologic pe membri ai echipei; - stabilirea legturilor de comunicare dintre echipa de conducere - utilizatori i echipa de integrare i ntreinere a proiectului/produsului informatic; - crearea unui mediu de lucru deschis n procesul aplicrii tehnologiei informaionale i de comunicare;

112

- verificarea produselor intermediare i accentuarea controlului pe stadii de realizare; - evitarea dependenei procesului de realizare a produsului n ansamblul su de realizrile individuale. Echipa este constituit din managerul de proiect, lociitor, persoana care asigur legtura cu utilizatorii, administratorul proiectului i proiectani / programatori. Opional, din echip face parte i un editor specializat n elaborarea de documentaii. Echipa se poate diviza n colective pentru proiectarea de tehnologii i produse informatice i pentru codificare a- testarea de produse, astfel nct s se furnizeze soluia organizatoric la nivelul ntregului ciclu de realizare a sistemului. Prin modul de definire i de aplicare, tehnica echipei proiectantului / programatorului-ef revizuit mbin conducerea administrativ cu cea tehnologic. 3). Echipa chirurgical. Echipa este alctuit din specialiti de nalt clas, sprijinii n munca lor de un administrator, un editor i unul sau doi secretari. Fiecare specialist are un nume n concordan cu funcia deinut n echip: instrumentist, grafician, cpitan, testator, specialist n limbaj, specialist n comunicaii etc. Tehnica si propune: - definirea clar a responsabilitilor profesionale pe componeni ai echipei; - recunoaterea fiecrui membru al echipei ca un expert n domeniu; -recunoaterea importanei legturilor de comunicare n echip i specializarea lor complet i consistent; - asigurarea comunicrii cu alte echipe printr-un membru, desemnat ca i copilot; - asigurarea unei documentaii de calitate (prin co-pilot). Tehnica echipei chirurgicale se aplic n etapele de proiectare tehnic si programare. Ea mbin armonios sarcinile conducerii administrative cu cele de realizare a produsului, crend un climat de responsabilitate a membrilor, o disciplin i o manier de lucru unitare. 4). Organizarea democratic a proiectrii / programrii. n aplicarea tehnicii, principiile de lucru sunt: - colaborarea democratic, de pe poziii de egalitate, ntre toi membrii echipei; - verificarea specificaiilor de realizare a fiecrui pri de proiect / produsprogram de ctre un membru al echipei, diferit de cel care le-a elaborat, nainte de codificarea (programarea) produsului; - partajarea efortului de programare ntre toi membrii echipei, n vederea depistrii la timp a eventualelor erori; - folosirea unor metode de lucru unitare care s faciliteze comunicarea;
113

- ridicarea continu a nivelului de pregtire a echipei prin nvarea de noi metode, tehnici i algoritmi de soluionare a problematicii; - rotaia membrilor la conducerea echipei. Echipa este alctuit dintr-un numr restrns de membri. Tehnica se aplic la proiectarea, codificarea i testarea programelor, necesare finalizrii proiectelor. Ca dezavantaj, se remarc dificultatea de a defini clar sarcinile fiecrui membru n cadrul echipei; de asemenea, n aplicarea tehnicii apar dificulti n comunicarea cu alte echipe i pot interveni controverse ntre membrii echipei datorit lipsei unui responsabil permanent. 5). Echipe organizaionale10. Dup anul 1990 s-au dezvoltat aplicaii n reele de calculatoare care permit echipelor de lucru multidisciplinare manageri- personal responsabil de gestionarea resurselor umane- informaticieni s realizeze un model organizaional nou de informare i comunicare utiliznd instrumente de lucru, cum sunt: mesageria electronic, editri multiutilizator, discuii de grup, conferine electronice .a. Echipele organizaionale i propun: - noi dimensiuni tehnico-economice ale comunicrii, cum sunt: eliminarea barierelor de comunicare temporale i spaiale, practici flexibile de munc, sporirea productivitii capitalurilor investite, n special a celui uman prin managementul bazat pe cunotine, creterea responsabilitilor bazate pe competen i autoritate, mbuntirea controlului execuiei sarcinilor, flexibilitatea structurilor i a tehnologiilor aplicate .a. - sporirea culturii ntreprinderii prin: identificare om - organizaie, cooperare+solidaritate+colaborare, crearea unui climat de ncredere i implicare, interes sporit n cunnoaterea i promovarea obiectivelor organizaiei, creterea valorii muncii depuse de fiecare, a randamentului capitalului imaterial etc.; - asigurarea unui nou climat social prin: creterea satisfaciei n munc, creterea salariilor, reducerea izolrii, posibiliti de instruire continu, sntate i siguran n munc mai bune, aplicarea principiilor ergonomice n munc, utilizarea mai eficient a (sub)echipelor de lucru etc. Realizarea dezideratelor de genul celor menionate presupune valori ficarea strategiilor i a tacticilor organizaiei n contextul proiectrii i a reproiectrii tehnologiilor de informare i comunicare informatizate. Ca i consecine ale utilizrii echipelor de lucru, se remarc: valorificarea strategiilor organizaionale prin reproiectarea structurilor organizatorice (re-engineering), formarea de echipe autonome de lucru i acces imediat la informaii cu caracter critic asupra
10

Fotache D.- Groupware-Metode, tehnici i tehnologii pentru grupuri de lucru,Ed. Polirom, Iai, 2003 114

sistemului; reducerea costurilor interne i a timpilor de lucru, ameliorarea i diversificarea serviciilor ctre clieni .a. Din continua preocupare pentru specializare i performane, rezult ageni inteligeni, ca utilizatori eficieni ai inteligenei artificiale cu caracteristicile: i adapteaz comportamentul n funcie de caracteristicile mediului n care funcioneaz, memoreaz experiena dobndit, se comport ca un subsistem capabil de nelegere, mbogete sistemul n care funcioneaz, utiliznd funcii automatizate privind tratarea informaiei etc. Astfel de ageni pot fi: sociabili care nva gusturile utilizatorilor, de cutare a informaiei dorite, pentru navigri n baza informaional dup criterii utilitare, ghizi .a. Pentru programarea, organizarea i controlul derulrii lucrrilor de analiz, proiectare, programare i integrare a unui proiect sunt uzuale tehnicile i metodele de coordonare activitilor menionate (tehnica Gantt; metoda drumului critic; metoda PERT .a.). Indiferent de metodele i / sau tehnicile folosite, managementul prin proiecte poate fi mijlocul de iniiere i finalizare a unor proiecte viabile, eficace care s asigure realizarea unor performae superioare, benefice pentru proiectani i beneficiari.

3.3. Elaborarea i integrarea aplicaiilor informatice

n aciunile de informatizare a societilor comerciale, managementul prin proiecte11 presupune ca, dup stabilirea echipei de lucru, a aciunilor principale de exercitat i a calendarului (programului) de ealonare a utilizrii resurselor, s se realizeze proiectarea i programarea aplicaiilor informatice necesare automatizrii proceselor informaional-decizionale. De altfel, prin modul de concepere, un program informatic rezultat poate fi asimilat unui produs de natur industrial a crei concepere i lansare n fabricaie trebuie precedate de proiectarea n detaliu a produsului i a tehnologiei specifice de realizare i pregtirea condiiilor de producie. Prin urmare, a realiza un proiect informatic nseamn, n esen, elaborarea specificaiilor de proiectare tehnic a produsuluii informatic pe baza crora urmeaz finalizarea acestuia prin aciunile de scriere, testare i integrare a programelor. Bazat pe rezultatele analizei contextului informatizrii i a proiectrii conceptuale de ansamblu, proiectarea tehnic presupune delimitarea i agoritmizarea prelucrrilor, n concordan cu cerinele de informare i de decizie. Un algoritm, ca numr finit de operaii necesare realizrii unei funcii, activiti sau lucrri ale tehnologiei
11

Oprean V., Oprean D., IT&C: Managementul prin proiecte,n Tribuna economic,nr. 47/2004, pag. 20-22 115

informaional- decizionale poate fi descris prin arbori de programare (scheme logice), n pseudo- cod sau cu ajutorul tabelelor de decizii12.

3.3.1. Algoritmizri i activiti de proiectare procedurale

Pe baza analizei de sistem a unei firme sau activiti complexe, echipa de proiect delimiteaz clasele de entiti, ca fiiere / tabele principale i secundare necesare automatizrilor, precum i procedurile i modulele de concretizare a tehnologiei informatice. De pild, pentru activitatea financiar- contabil a unei societi comerciale clasele de entiti distinctive pot fi: planul de conturi propriu (conturile sintetice i desfurarea lor pe analitice, soldurile iniiale i, eventual, sumele precedente debitoare i creditoare), registrele- jurnal pe categorii de operaii (Cumprri, Vnzri, Decontri cu banca, Operaii prin casierie, Operaii diverse .a.) care reflect tranzaciile unei perioade, teri (Furnizori, Clieni, Angajai) cu care firma are relaii economico- financiare, documente i articole contabile uzuale etc.; pentru fiecare fiier aferent trebuie prevzute procedurile i modulele de tratare a informaiei, cum sunt: culegerea i validarea datelor, actualizarea periodic a fiierelor (prin adugri, modificri i tergeri de nregistrri), pentru prelucrri conforme reglementrilor cu caracter normativ i pentru a rspunde la cererile de informare i fundamentare a deciziilor. Corespunztor schemei de sistem (organigramei) a ansamblului prelucrrilor prefigurate, algoritmul de integrare a prelucrrilor unei aplicaii poate fi dat de meniul principal de integrare a procedurirlor care presupune descrierea ecranului, a formularelor de culegere a datelor i a obiectelor necesare (butoane, casete de dialog, liste de opiuni etc.) exploatrii ulterioare a programului aferent meniului. De exemplu, ntr-o abordare simpl, dac la o societate comercial oarecare ne propunem elaborarea specificaiilor pentru procedura de creare i actualizare a fiierului privind Planul de conturi al firmei, atunci definirea algoritmului, aferent procedurii integratoare a principalelor prelucrri, P_meniu, necesar gestionrii fiierului principal F_conturi presupune: -stabilirea procedurilor meniului de gestionare a fiierului, cum ar fi: P_creare pentru crearea structurii fiierului (simbol cont, denumire cont, funcie contabil, sold iniial, sume cumulate) i popularea ei cu datele iniiale din balana contabil a lunii precedente; P_adaug pentru adugarea de noi atribute i date fiierului iniial; P_modific de actualizare a datelor coninute n fiier la un moment dat; P_vizor de vizualizare a unor valori dorite de utilizatori; P_list de extragere la imprimant a unor rezultate (Fie de cont cu solduri i sume la un moment dat, balane de verificare,
12

Vduva I., Programare structurat, Ed. Tehnic, Bucureti, 1986, anexe 116

rulaje etc.); P_intrri pentru actualizarea fiierului F_conturi cu datele privind conturile noi (similar P_ieiri pentru eliminarea nregistrrilor relative la conturi care nu se mai utilizeaz) .a.; -definirea unei variabile de lucru prin care s se asigure identificarea i integrarea opiunilor aplicaiei i ncheierea prelucrrilor. De pild, prin valorile unei variabile condiie-de-sfrit- csf - la ntrebarea adresat utilizaturului Continuai?[D/*], sugernd n parantezele patrate valorile de rspuns posibil (Dda;*-orice alt rspuns nsemnnd nu) se poate da posibilitatea, ca n aceai sesiune de lucru, s se execute mai multe opiuni (adugri, modificri, operare intrri etc.); printr-o variabil, numit Opiune, se poate detecta solicitarea utilizatorului la o prelucrare: dac Opiune = 1 atunci execut P_creare...dac Opiune = 7 atunci execut P_ieiri; -elaborarea algoritmului aferent procedurii P_meniu. n pseudo-cod algoritmul se poate descrie astfel: Start *procedura P_meniu execut (modulul) M_ecran csf=d (iniializare variabil de lucru) Opiune= execut (modulul M_meniu) pn cnd csf=d introducei (selectai o valoare) Opiune Dac Opiune=1 execut P_creare ... Dac Optiune=7 execut P_ieiri n caz contrar (Dac nu este tastat o valoare din cele admise) Afieaz tastai una din valorile meniului Introducei csf Sfrit_execut Afieaz sfrit normal Stop *modulul Mecran Procedur de gestionare a fiierului privind conturile Opiunile meniului sunt: 1. creare fiier,...,7. operare eliminri conturi La ncheierea prelucrrilor tastai orice valoare diferit de d Revenire (n P_meniu) Intr-o variant simpl de programare clasic n mediul FoxPro (avnd n vedere c interpretorul FoxPro recunoate primele patru caractere ale cuvintelor
117

limbajului, urmtoarele fiind facultative i c dup simbolurile && sunt inserate comentarii explicative), procedura aferent algoritmului este urmtoarea: MODI[FY] COMM[AND] P_meniu &&apelare a editorului pentru crearea fiierului cu &&programul-surs(de transpunere a algoritmului &&n comenzi i instruciuni ale limbajului) CLEAR &&iniializare ecran SET TALK OFF &&anulare dialog n timpul execuiei DO M_ecran &&execut modul pentru mesaje pe ecran csf=d Opiune= DO WHILE csf=d @5,15 TO 20,65 DOUBLE &&din linia 5,coloana 15 pn n 20,65 se creaz un chenar cu linie dubl @6,17 Prompt 1 creare fiier &&afiare prompter ecran 1 creare fiier @13,17 Prompt 7 operare eliminri conturi MENU TO Opiune &&plasarea meniuluii descris n variabila Opiune DO CASE CASE Opiune=1 DO P_creare CASE Opiune=7 DO P_ieiri OTHERWISE WAIT tastai una din cifrele de la 1 la 7 TIMEOUT 2 ENDCASE @19,20 SAY Continuati?[d/*] GET csf PICT[URE] x &&descriere variabil csf READ &&citire (tastare valoare) variabil ENDDO ?sfarsit normal &&afiarea mesajului pe rndul urmtor al ecranului RETURN PROC[EDURE] M_ecran &&modul sau subprogram de descriere a ecranului @2,10 SAY Procedur de gestionare a fiierului privind conturile @3,10 SAY Optiunile meniului sunt: 1. Creare fiier conturi
118

@4,10 SAY La ncheierea prelucrrii tastati orice valoare diferit de d RETURN && ntoarcere n modulul principal n ideea programrii structurate, promovat i n concepia limbajelor de programare dup anul 1980, meniul poate fi considerat ca rdcin a arborelui de programare din care se dezvolt tulpina (procedurile meniului) i frunzele (modulele fiecrei proceduri). Fiecare component (tulpin) a meniului se dezvolt n algoritmi afereni prelucrrilor. Orice procedur de prelucrri include trei categorii de module: iniial, de prelucrri propriu- zise i final, nlnuite astfel: Execut (DO) M_iniial Execut (DO) atta timp ct (WHILE) condiie-prelucrare este adevarat Execut (DO) M_prelucrri Sfrit_execuie_prelucrri (ENDDO) Execut (DO) M_final De regul, un modul iniial include: descrieri (formatri) ecrane, creare (CREATE) sau deschidere (OPEN/USE nume_fiier) fiiere, iniializri variabile de lucru, sortri, indexri .a. Modulele de prelucrri nglobeaz: introduceri (INPUT/ACCEPT/READ) i validri (VALID) de date, citiri de nregistrri din fiiere existente (GO TOP/SKIP/READ/DISPLAY etc.), operaii aritmetice, atribuiri i transferuri de rezultate unor alte variabile dect cele folosite n prelucrri, scrieri de nregistrri (REPLACE/WRITE), rescrieri de valori dup modificri (REPLACE/REWRITE), tergeri de date (DELETE, PACK) sau nregistrri cu coninut perimat etc. ntr un modul final sunt nchise (CLOSE/USE) fiierele folosite n prelucrri, se afieaz sau se scriu rezultate finale de genul unor sume, se nchid tabele, liste, situaii, se listeaz fiiere etc. Pentru dezvoltarea (ipotetic a) procedurii P_creare din P_meniu, considerm c atributele fiierului F_conturi, natura lor (N- numeric, C- de tip caracter, D- dat calendaristic etc.), lungimea i condiiile de validare sunt urmtoarele: Simbol_cont,N,6,>100 i <999999 Den[umire],C,20,# (zon nevid, dar care s-ar putea confrunta pentru validare cu valorile dintr-un nomenclator de titluri de conturi); Funcie_contabil,C,1,a[ctiv] sau p [asiv] sau b[ifuncional] Sold_iniial,N,10,>=0 Sume_db,N,10,>0 Sume_cr,N,10,>=0 Condiia de terminare a introducerii datelor n fiier o putem considera similar celei de la meniu (sf#d). Cu aceste determinri, considernd structura fiierului creat cu

119

funcia CREA[TE] F_conturi, procedura P_creare, aferent algoritmului general pentru prelucrri, n limbajul FoxPro, este urmtoarea: MODI COMM P_creare PUBLIC sf,sb1,den1,fc1,sold1,s_db,s_cr&&definire variabile globale procedur DO M_initial DO WHILE sf=d DO M_creare ENDDO DO M_final RETURN PROC M_initial CLEAR SET TALK OFF ? procedur de introducere a datelor, cu validare, n fiierul privind conturile ?datele se introduc astfel: USE F_conturi &&deschide fiier Sb1=0, Den1=, Fc1=, Sold1=0, S_db=0, S_cr=0 &&iniializare variabile de introducere a datelor ntr-o zon (tampon) de lucru distinctiv sf=d RETURN PROC M_creare @5,10 SAY Simbol cont cuprins ntre 100-999999: GET Sb1 PICT ; 999999 VALID (Sb1>100 .AND.Sb1<999999) ERROR Retastai simbolul @6,10 SAY Denumirea (nevid): GET Den1 PICT REPL[ICATE]; (x,20) VALID Den1# ERROR Reintroduceti titlul contului @7,10 SAY Funcie contabil: [a/p/b]: GET Fc1 PICT x; VALID (Fc1=a .OR. Fc1=p.OR.Fc1=b) ERROR atenie: tastai a/p/b @8,10 SAY Sold iniial (nenegativ): GET Sold1 PICT REPL (9,10); VALID Sold1>=0 ERROR Retastai soldul iniial @9,10 SAY Sume debitoare: GET S_db PICT REPL(9,10); VALID S_db>0 ERROR Retastai suma debitoare @10,10 SAY Sume creditoare: GET S_cr PICT REPL(9,10); VALID S_cr>0 ERROR retastai suma creditoare READ APPEND BLANK &&adugare a unei linii vide n fiier REPL[ACE] Simbol_cont WITH Sb1, Den WITH Den1,;

120

Funcie_contabil WITH Fc1, Sold_initial WITH Sold1, Sume_db WITH S_db, ; Sume_cr WITH S_cr &&nlocuire valori cmpuri (vide) din fiier cu cele tastate @12,20 SAY Continuati[d/*]? GET sf PICT x READ RETURN PROC M_final USE [CLOSE ALL] && nchidere fiiere ?revenire n meniu && mesaj final afiat pe ecran RETURN Execuia procedurii P_creare se poate face nu numai la preluarea iniial a datelor din Balana de verificare a ultimei luni dinaintea implementrii procedurii, ci i de fiecare dat cnd se adaug nregistrri noi n fiier (pentru conturi care nu au mai fost utilizate). Noile valori (realizri) ale fiierului F_conturi privind clasa de entiti Plan de conturi pot fi introduse, ntr-o abordare dinamic, ori de cte ori este nevoie prin apelarea procedurii P_creare. O prelucrare frecvent a fiierelor principale este cea de modificare a coninutului unui fiier, ca urmare a unor acte normative (introducerea unor conturi noi, de exemplu) sau a unor decizii proprii (dezvoltarea pe analitice a conturilor sintetice, reevaluri de stocuri, diferene de inventar .a.). Secvena schemei de sistem aferent unei proceduri de modificri a coninutului unui fi ier include, ca intrare, documentul cu modificrile de operat, iar ca intrare - ieire fiierul asupra cruia se opereaz modificrile, ecranul (monitorul) de dialog cu operatorul i, eventual, imprimanta pentru a lista modificrile efectuate n cadrul prelucrrii. Dac pentru fiierul principal F_conturi considerm procedura P_iesiri prin care, pe baza dispoziiei contabilului-ef sau a directorului economic, se elimin conturile care nu se mai folosesc n cadrul societii comerciale prelund de la terminal simbolurile conturilor de eliminat, atunci algoritmul poate consta n urmtoarele: *P_ieiri M_initial Descrie (pe ecran) coninut procedura Deschide F_conturi Indexeaz dup valorile cmpului Simbol_cont Sb1=0, sf=d Execut (M_modific) atta timp ct sf=d Introdu Sb1>100 i Sb1<999999 Caut Sb1 (n F_conturi)
121

Dac exist Sb1 terge nregistrare Dac nu exist Afieaz cont inexistent n fiier Introdu valoare pentru sf M_final Inchide fiiere Afieaz sfrit normal Revenire (n P_meniu) Procedura FoxPro aferent algoritmului este urmtoarea: MODI COMM P_iesiri DO M_iniial DO WHILE sf=d DO M_tergere ENDDO DO M_final RETURN PROC M_initial ?Operare eliminri nregistrri pentru conturi neutilizate ?Introducei datele de la terminal astfel: USE F_conturi INDEX ON Simbol_cont TO Isolduri &&Isolduri-fiier cu rezultatele indexrii (al nregistrrilor dup valorile chei de indexare Simbol - cont) Sb1=0, sf=d RETURN PROC M_tergere @6,10 SAY tastai simbolul cont de eliminat cuprins ntre 100 i 999999 ; GET Sb1 PICT REPL(9,6) VALID (Sb1 > 100 .AND. Sb1<999999) ERROR; Retastai READ SEEK Sb1 &&caut valoarea introdus (prin fiierul de indeci) IF FOUND() &&dac gsete n fiierul prelucrat n zona activ DELETE &&marcare pentru tergere ELSE WAIT Cont de simbol inexistent; tastati o alta valoare ENDIF @10,15 SAY Continuai[d/*]? GET sf PICT x READ
122

RETURN PROC M_final PACK &&instruciune de tergere fizic a nregistrrilor marcate n urma execuiei comenzii DELETE CLOSE ALL &&nchide toate fiierele ?Sfrit normal RETURN 3.3.2. Structuri principale de prelucrrii Indiferent de natura prelucrrilor i mediul de programare folosit, structurarea proceselor de tratare a informaiei n cadrul unei proceduri se face prin expresii condiionale, incluse n structura majoritii limbajelor de programare. Structurile de baz sunt: a). prelucrri secveniale n care operaiile se succed fr reveniri sau alternri condiionale, cum ar fi: a=5 b=7 c=2 x1=(-b-(b*b-4*a*c)**0.5)/2*a x2=(-b+(b*b-4*a*c)**0.5)/2*a ?Rdcinile ecuaiei de gradul 2 sunt: ?x1=,x1,x2=,x2 (** semnific ridicare la putere); b). prelucrri repetitive condiionale de formularea: DO (execut) WHILE (ct timp) condiie (adevrat) comenzi / fraze de comand / instruciuni ENDDO (sfrit execuie) c). prelucrri repetitive cu numr finit de pai: FOR (Pentru) condiie [STEP (pasul) n] Prelucrri ENDFOR De exemplu, dac dorim s calculm suma primelor N numere naturale, atunci secvena de prelucrri (n FoxPro sau Basic) este urmtoarea: INPUT Limita maxim de nsumare= TO N Suma=0 FOR I=1 TO N Suma=Suma+I ENDFOR
123

?Rezultatul nsumrii=,Suma ntr-o prelucrare complex, pot fi imbricate construcii FOR-ENDFOR respectnd logica propoziiilor i corespondenele de nceput i sfrit a fiecrui ciclu. De pild, ntr-o prelucrare de tablou bidimensional (matrice), cutarea numrului de elemente nenegative (Nr) se poate face prin secvena de prelucrri urmtoare: FOR I=1 TO M FOR J=1 TO N IF A(I, J)#0 Nr=Nr+1 ENDIF ENDFOR ENDFOR d). generare a unor prelucrri alternative: IF (dac) condiie THEN (atunci) Execut-comenzi-I [ELSE (altfel) Execut-comenzi-II] ENDIF O astfel de structur poate fi construit i fr clauza ELSE (n general, parantezele patrate semnific, n construciile mediilor de programare, prezena facultativ a coninutului) ; ea admite, ca i n cazul anterior, imbricarea de fraze, respectnd tehnologia aferent algoritmului tratrii datelor. Aceste structuri (condiionale) pot fi incluse n cicluri DO-ENDDO e). structuri alternative multiple: DO CASE (execut caz) CASE condiie1 (variabil=valoare-1) Execut-comenzi-1 ... CASE condiieN (variabil=valoare-n) Execut-comenzi-N [OTHERWISE (n caz contrar) Execut-comenzi-N+1] ENDCASE O astfel de structur este analoag construciei IF-ENDIF pentru variabile binare (logice, cu valoare de adevr-T sau fals-F). Aa cum reiese din exemplificarile precedente, astfel de structurri sunt folosite n construirea meniurilor de lucru pentru nlnuirea procedurilor de prelucrri. Consultrile de fiiere se pot face folosind Limbaje de Manipulare a Datelor (LMD) cu filtre de precizare a condiiilor pentru cutri dorite de utilizatorii de informaie. n FoxPro, Oracle sau Access, astfel de consultri se pot realiza prin
124

comenzile SELECT, CREATE QUERY / VIEW i / sau MODIFY QUERY / VIEW prin care se creaz, interactiv, cererea de informaii. Adeseori, n stabilirea relaiilor dintre clasele de obiecte de genul FurnizorProductor- Client sau Productor- Distribuitor- Client .a. este necesar stabilirea de jonciuni sau viziuni prin intersecia logic dintre fiierele asociate claselor de entiti pentru a obine informaiile necesare lurii deciziilor i operrii n documentele de gestiune a resurselor. Algoritmii afereni unor astfel de prelucrri complexe pot fi concepui fie printro intersecie (direct) a datelor din fiiere, dup cheile de legtur, fie prin pai de lucru succesivi, cu crearea de fiiere intermediare pn la obinerea rezultatelor dorite, solicitate de utilizatori. De pild, dac dintr-un fiier de eviden (cronologic) Fjurnale se dorete obinerea Fielor de cont (de nregistrri contabile sistematice) cu rulajele conturilor i Balana de verificare, atunci succesiunea prelucrrilor poate fi: se sorteaz Fjurnale dup cheia Simbol-cont-debitor, se preiau sumele debitoare cu datele aferente ntr-un fiier intermediar Fdebite; se sorteaz Fjurnale dup Simbol-cont-creditor i se preiau rezultatele n Fcredite; din intersecia fiierelor Fdebite i Fcredite dup simbol_cont se creaz fiierul Fie-cont cu rulajele i explicaiile aferente pe conturi de eviden; se listeaz fiierul Fie-cont; pentru elaborarea balanei de verificare a operaiilor contabile, mai este necesar intersecia logic a fiierului Fie-cont cu un fiier de stare privind soldurile iniiale sau sumele pe perioadele anterioare de gestiune. Pentru a realiza relaii ntre fiiere, mediile de programare actuale conin funcii i comenzi pentru intersecii logice i crearea de viziuni (CREATE / MODIFY VIEW) sau domenii cu informaii solicitate de manageri, administratori i gestionari ai unei societi comerciale.

3.3.3. Proiectarea i programarea asistat la calculator

Noile medii de programare de tip vizual, cum este Visual FoxPro sau Access, conin componente i instrumente de lucru care nlesnesc munca analitilor i a programatorilor. Un astfel de instrument este managerul (constructorul) de proiecte (Project Manager) din Visual FoxPro, ca i generator i gestionar de proiecte informatice. Un proiect este considerat ca fiind un ansamblu de date cu relaii ntre ele (tabele, viziuni), programe (proceduri ncapsulate sau distincte), documente (formulare i rapoarte), interogri .a. care definesc o aplicaie. Pentru organizarea aplicaiei (predefinite prin analiza de sistem), un proiect se elaboreaz pe baza definirii paginilor, coninute n fereastra constructorului. Aceste pagini sunt13 prezentate n figura 3.3 i au urmtorul coninut:
13

Oprean D., Oprean V.B. Managementul prin proiecte: proiectarea i programarea aplicaiilor, 125

Fig. 3.3- Meniul principal Project Manager

Data, ce conine baze de date (Database), tabele libere (Free Tables) i interogri (Queries). La rndul ei, o baz de date (Database) include: - tabele (Tables) principale, numite i tabele printe, caracterizeaaz clasele de entiti cu caracter permanent, cum sunt cele privind patrimoniul unei organizaii, i tabelele subordonate, numite tabele fiu sau copii, referitoare la tranzaciile patrimoniale care au loc n organizaie, ce se repercuteaz asupra coninutului tabelelor- prini. Totodat, baza de date insereaz relaiile dintre cele 2 categorii de tabele. De exemplu, tabela Fconturi asupra datelor de eviden sistematic a entitilor patrimoniale este de tip printe, iar tabela Fjurnale de consemnare cronologic a tranzaciilor cu impact patrimonial este o tabel copil. Relaiile persistente sau permanente dintre cele 2 tabele se pot stabili prin valorile cmpului Simbol_cont, care devine n prelucrri index primar de accesare direct a informaiilor dorite din cele 2 tabele. Orice tabel a bazei de date se poate crea ca o
n vol. Probleme economice n Visual FoxPro, coordonator Goron S., Ed. Risoprint, ClujNapoca, 2006, pag. 5- 11 126

tabel liber i apoi aduga bazei folosind opiunea (butonul) meniului constructorului bazei de date (Database Designer) de adugare Add... sau comanda de lucru aferent operaiei. Eliminarea unei tabele se face prin activarea butonului Remove, iar modificarea relaiilor dintre tabele se realizeaz prin opiunea Modify; - vederi sau viziuni locale (Local View), rezultate din intersecia logic prin asocieri i jonciuni de tabele folosind fraze de interogare Select, pentru a extrage informaii dorite i pstrate n fiiere distincte. Aceste fiiere sunt similare tabelelor, cu deosebirea c modificrile care se opereaz n viziuni se reflect i n sursa valorilor iniiale; - vederi la distan (Remote View) sunt similare vederilor locale, fiind accesibile n reele de calculatoare, pe servere SQL, sau n surse de date de tip ODBC. Pentru accesarea informaiilor din astfel de vederi este necesar definirea componentei de conexiuni (Conections); - proceduri stocate (Stored Procedures) sunt reguli i cerine de integritate a datelor definite de utilizator, cum sunt: condiii de validare a datelor (VALID), mesaje de atenionare a operatorilor, mesaje de erori, . a. Aceste proceduri sunt generate de programul Visual FoxPro, reprezentnd codul de meninere a integritii refereniale a datelor pe baza regulilor fixate. Regulile de gestiune a datelor sunt menite s asigure i respectarea integritii refereniale la actualizarea datelor din tabelele bazei de date. Tabelele libere, din pagina Data, conin informaii utile aplicaiei, dar care nu sunt n relaie direct cu tabelele bazei de date. De pild, astfel de tabele pot fi: de codificare a documentelor de eviden (Cod_document, Denumire_document) acceptate n prelucrri, nomenclatorul clienilor, furnizorilor i angajailor organizaiei, planul de conturi specific folosit, etc. Interogrile sunt fiiere care conin fraze Select (fiiere de extensie .qpr), care, la lansare n execuie, ca o procedur Fox oarecare (DO nume_procedur), redau rspunsuri la solicitrile formulate prin acele fraze. Spre deosebire de vederi, rezultatele modificrii interogrilor nu au efect asupra coninutului bazei de date surs; Documents (Docs) cuprinde toate documentele folosite n cadrul proiectului incluznd: - formulare (Forms) pentru culegerea i vizualizarea datelor sunt elemente importante de interfa operator aplicaie i n condiiile accesrii bazelor de date prin reele Internet sau Intranet; - rapoarte (Reports) de sistematizare i prezentare a rezultatelor cerute de utilizatori sub form de liste, rapoarte i situaii privind patrimoniul organizaiei;
127

- etichete potale (Labels) pentru tiprirea rezultatelor unor interogri sau de listare a unor rezultate ale tratrii informaiei cum sunt: fluturaii de plat a salariilor, fiele de cont, fie de eviden a mijloacelor fixe . a.; Classes conine bibliotecile de clase definite sau adugate aplicaiei sub form de fiiere cu extensia .vcx; Code include codul (fiierele cu programele) surs al programelor i aplicaiile asociate. Un proiect admite un singur program principal, de genul meniului prezentat, marcat n cadrul paginii cu litere boldate. ntr-un proiect pot fi create, adugate sau / i terse fiiere cu programe surs de extensie .prg i aplicaiile asociate, integrate ntr-o concepie unitar; Other stocheaz coduri surs pentru meniuri (fiiere de extensie .mpr) i alte tipuri de fiiere de tip text, cu icon-uri, cu bitmap-uri, etc. care sunt utilizate n proiect; All sintetizeaz coninutul complet al celorlalte 5 pagini. n orice fereastr de lucru a meniului, fiecare obiect are ataat un meniu rapid (contextual) activat prin click cu butonul din dreapta al mouse-ului, n care comenzile utilizabile (active) sunt scrise boldat (apsat), iar cele inactive sunt cu culori estompate. De exemplu, meniul contextual ataat categoriilor din Project Manager, are comenzile active Expand All, Include, Project Info, Builder i Help. Pentru o mai bun organizare a unui proiect este recomandabil gruparea tabelelor, a programelor, a rapoartelor i a celorlalte categorii de obiecte ale unui proiect n subdirectoare (foldere) distinctive. n programul Access, aparintor pachetului Microsoft Office, proiectele sunt organizate dup arhitectura client server, n care clientul este un proiect cu elementele de interfa formulare, rapoarte, pagini de date Web sau module, reprezentate prin cod sau n HTML, iar serverul de date SQL Sever este un calculator din reea sau acelai calculator la care se opereaz i conine (obiectele de date) tabele, interogri i diagrame. Legtura dintre proiect i server se face printrun fiier cu extensia .adp folosind arhitectura OLE DB. Indiferent de metodele i mediile de programare folosite, proiectarea, programarea, integrarea i ntreinerea aplicaiilor informatice necesit o analiz de sistem aprofundat privind tehnologia tratrii informaiei i comunicrii, care s reflecte existena i funcionarea organizaiei n mediul real.

128

3.4. Demararea unui proiect: concepia bazelor de date

Aa cum s-a menionat anterior, un sistem informatic este constituit din subsisteme, aplicaii i proceduri. Un subsistem reflect activitile funcionale concretizate n aciuni; astfel ntr-o ntreprindere subsistemele principale sunt: de marketing, privind cercetarea-dezvoltarea, de producie, comercial, financiar-contabil i de personal. Fiecare subsistem se structureaz pe aplicaii distinctive, autonome privind finalitatea activitilor specifice fiecrei funcii. Pentru o ntreprindere, principalele aplicaii pot fi: - pentru culegerea i prelucrarea datelor privind anchetele sociale, de analiz a cererii pieei; de stabilire a cotei de pia i a poziiei pe pia i, pe aceast baz, determinarea ofertei de produse; de bugetare i control a bugetrii pentru aciuni promoionale i distribuirea produselor . a . n cadrul subsistemului de marketing; - de proiectare produse i tehnologii; de elaborare a fiierelor cu sortimentaia de fabricaie i reetele aferente; privind normarea produciei i a muncii; de realizare a prototipurilor de produs sau a seriei zero etc.; de management a proceselor investiionale etc. pentru subsistemul de cercetare-dezvoltare; - de programare operativ, urmrire i control a fabricaiei; privind lansarea i controlul ordonanrii produciei, de management prin excepii a compartimentelor de producie . a. pentru subsistemul de producie; - privind relaiile contractuale cu furnizorii i clienii; de gestionare a stocurilor i a soldurilor; de management a relaiilor cu terii, privind gestiunea i distribuirea produciei marf etc. pentru subsistemul comercial; - pentru culegerea i tratarea datelor din documente primare sau de management al documentelor; privind contabilitatea financiar i de gestiune, de eviden i gestiune a imobilizrilor; privind trezoreria firmei i relaiile financiare, de management prin costuri i prin rezultate, de analize regresionale privind tendinele consumurilor i a cheltuielilor etc., pentru subsistemul financiar-contabil; - de eviden, urmrire i control a personalului, de eviden i gestiune a salariilor, privind evaluarea i valorificarea capitalului intelectual, relativ la managementul resurselor umane bazat pe cunotine i comportament organizaional etc., pentru subsistemul de personal. Numrul i complexitatea aplicaiilor este n funcie de mrimea i complexitatea organizaiei, de cerinele i posibilitile unui management performant i a unei gestiuni eficiente a resurselor, racordate n cadrul tehnologiilor moderne de informare i comunicare n cadrul reelelor de tip Intranet i Internet. Fiecare aplicaie, la rndul ei, se bazeaz, ca proiect distinctiv, pe componente de date specifice sau particulare i pe proceduri de gestionare i tratare a informaiei cerute de utilizatori.
129

De exemplu, pentru aplicaia de contabilitate financiar, ntro organizaie de dimensiuni mai reduse, baza de date se poate constitui din tabelele privind consemnarea cronologic, pe baz de documente, a tranzaciilor n jurnale, balana contabil de verificare a corectitudinii nregistrrilor dintr-o perioad de timp i planul contabil aplicat la nivelul organizaiei. Fiele de cont, balana, bilanul i alte situaii dorite pot rezulta din procedurile de prelucrare a datelor din jurnale. n orice proiect la nivelul unei aplicaii, esena o constituie baza de date, de eviden, urmrire i control a existenei i a micrilor patrimoniale specifice. Prin urmare, analiza i proiectarea bazelor de date sunt determinante n realizarea de produse informatice, utile managementului i gestiunii oricrei organizaii. n demersul realizrii unei baze de date oarecare se disting trei nivele de percepie14: extern, aferent utilizatorilor care i exprim cerinele informaionaldecizionale ce se poate reprezenta printr-o schem sau subscheme asociate; conceptual, aferent gestionarului / administratorului bazei de date care se concretizeaz ntr-o schem conceptual; intern, corespunztor informaticianului care realizeaz reprezentarea datelor pe suportul fizic de nmagazinare a datelor. La nivel extern, echipele care manipuleaz datele apeleaz la o anumit descriere a lor, conform intereselor fiecrui utilizator. De exemplu, pentru un sortiment de fabricaie schema extern include atributele sortimentului, cum ar fi: denumire, mrime, culoare; pentru o marf facturat schema include codul, cantitatea i preul unitar; clienii unei firme sunt percepui prin atributele caracteristice lor, cum sunt: cod client, denumire, cod fiscal, adres, etc. Prin urmare, numrul schemelor externe este ridicat, ceea ce necesit elaborarea unei scheme conceptuale de ansamblu. Schema extern este definit de membrii echipei de proiect prin prisma cerinelor informaionale ale postului de munc. De pild, aceeai clas de informaii privind stocurile dintr-o ntreprindere este perceput diferit de utilizatori diveri, cum ar fi: contabilul definete schema extern avnd n vedere fiele de cont privind evidena stocurilor, inginerul de la compartimentul de producie are nevoie de informaii la zi privind mrimea i structura stocurilor de materii prime i materiale pe locuri de depozitare / utilizare, meciologul, responsabil cu aprovizionarea, are nevoie de informaii operative privind materiile prime i materialele necesare fabricaiei n flux continuu, etc. Indiferent de schema extern asociat de membrii echipei utilizatoare, fiecare schem extern trebuie s se regseasc n schema conceptual. Structurarea propriu- zis a datelor n ideea prelucrrii lor printr-un sistem de gestiune a bazelor de date se realizeaz la nivel conceptual. La baza modelului
14

Nstase P..a. Baze de date. Microsoft Access 2000, Ed.Teora, Bucureti, 2004, pag. 20 130

conceptual, desprins din analiza schemelor externe, st definirea proprietilor elementare ale obiectelor care constituie patrimoniul organizaiei. Aceste proprieti se caracterizeaz prin atribute sau cmpuri ale elementelor entitilor distinctive. Ele descriu obiectele lumii reale i relaiile dintre ele, cum sunt: nregistrare contabil, conturi, explicaii, sume debitoare, sume creditoare . a. n manipularea datelor aferente trebuie definite reguli de integritate care s asigure culegerea corect a informaiilor. Arhitectura funcional propus de grupul de lucru ANSI/X3/SPARC este de referin n organizarea i proiectarea Sistemelor de Gestiune a Bazelor de Date (SGBD)15. Ea este axat pe dicionarul datelor i cuprinde dou pri: pentru descrierea datelor (compoziia dicionarului datelor) i pentru manipularea datelor (interogarea i reactualizarea bazei). n fiecare parte se regsesc cele trei niveluri: intern, conceptual i extern. Aceste trei niveluri nu sunt neaprat distincte pentru orice SGBD. Interfeele (numerotate n figura 3.4.) care descriu arhitectura de referin a unui SGBD, corespund urmtoarelor transformri: a) limbajul de descriere a datelor conceptuale permite administratorului s defineasc schema conceptual a unei baze de date n format surs; b) limbajul de descriere a datelor conceptuale, format obiect, care rezult din compilarea celui precedent i permite aranjarea schemei obiect n dicionarul datelor; c) limbajul de descriere a datelor conceptuale, format editare ca interfa, permite administratorilor aplicaiilor i a bazelor s consulte schema conceptual pentru a defini reguli de coresponden; d) limbaje de descriere a datelor externe, format surs permit administratorilor aplicaiilor s defineasc scheme externe corespunznd schemei conceptuale. Deoarece sistemele de gestiune pot suporta mai multe modele externe, pot exista mai multe limbaje de descriere a datelor externe; e) limbaje de descriere a datelor externe, format obiect corespund formelor compilate ale celor precedente i permit aranjarea schemelor externe (obiect) n dicionarul datelor; f) limbajul de descriere a datelor interne, format surs permite administratorului bazei de date s defineasc schema intern i regulile de coresponden cu schema conceptual;

15

AMERICAN NATIONAL STANDARD FOR INFORMATION SYSTEMS Database Language SQL, ANSI X3.135 1986, 1986

131

g) limbajul de descriere a datelor interne, format obiect corespunde formei compilate a celui precedent i permite aranjarea schemei interne (obiect) n dicionarul datelor; h) limbaje de manipulare a datelor externe, format surs permit programatorilor de aplicaii sau utilizatorilor neinformaticieni s manipuleze date externe (view-uri); i) limbaje de manipulare a datelor externe, format obiect corespund formelor compilate ale celor precedente; j) limbaj de manipulare a datelor conceptuale, format obiect este produs de procesorul de transformare extern/conceptual pentru a manipula datele externe; k) limbaj de manipulare a datelor interne, format obiect este limbaj unic produs de procesorul de transformare, conceptual/intern pentru a gestiona datele interne; l) limbaj de stocare a datelor, format obiect corespunde interfeei cu sistemul de stocare a datelor; m) interfaa cu memoria secundar asigur efectuarea de intrri-ieiri n/din unitatea de memorie secundar; n) interfaa de acces la dicionarul datelor permite diverselor procesoare de transformare s acceseze scheme obiect i reguli de coresponden. Procesoarele din arhitectura unui SGBD, coninute n fig. 3.4., au urmtoarele funcii: 1. procesorul schemei conceptuale compileaz schema conceptual i, dac nu sunt erori, depune schema compilat n dicionarul datelor; 2. procesorul schemei externe compileaz schemele externe i regulile de coresponden extern i, n cazul c nu sunt erori, aranjeaz schema compilat i regulile de coresponden n dicionarul datelor; 3. procesorul schemei interne are un rol similar pentru schema intern; 4. procesorul de transformare extern/conceptual transform manipulrile externe n manipulri conceptuale i invers; 5. procesorul de transformare conceptual/intern transform manipulrile conceptuale n manipulri interne i invers ; 6. procesorul de transformare intrare / stocare transform manipulrile interne n primitive ale sistemului de stocare i invers, elibereaz datele stocate ntr un format corespunztor schemei interne
administrator ntreprindere

a
132

administratorul bazei de date

procesor schema conceptual

administratorul aplicaiilor

E S C R I E R E

procesor schema intern

dicionarul datelor

procesor schema extern

procesor intern/alocare

procesor conceptual/intern

procesor extern/conceptual

l
sistem de alocare

i
program aplicaii extern

h
programator aplicaie

memorii secundare

utilizatori

M A N I P U L A R E

Fig. 3.4- Arhitectura de referin a unui SGBD

133

Elementele de baz ale unui model de date conceptual16 sunt sintetizate n modelul Entitate- Atribut- Relaie (EAR). Diagrama EAR reprezint un model neformalizat pentru reprezentarea unui sistem din lumea real; ea este utilizat pentru reprezentarea grafic a modelului relaional. n general, pentru modelarea sistemului real considerat se constituie structurile EAR crora li se asociaz modelul relaional i acestuia i se adreaseaz cererile. Astfel, se mbin simplitatea descriptiv a diagramei EAR cu posibilitile limbajului de manipulare a datelor al modelului relaional. Modelul EAR mparte elementele unui sistem real n dou categorii: entiti (cu atribute) i legturi (asocieri) ntre aceste entiti. Nu trebuie confundat conceptul de relaie, n sensul de asociere, care intervine n definirea diagramei EAR, cu conceptul care este specific modelului relaional. Modelul EAR abstractizeaz lumea real sub form de date elementare agregate n entiti care au atribute specifice i ntre care intervin relaii sau corespondene. Un tip de entitate definete elementele cu aceleai atribute, cum sunt: nregistrrile contabile, conturile, angajaii, stocurile i soldurile, mijloacele fixe, etc. Prin urmare, o entitate este un model de obiect, identificat n lumea real sub aspect concret (materii prime i materiale, angajai, furnizori etc.) sau de tip abstract cum sunt evenimentele caracterizate prin nume i proprieti distinctive (aprovizionare, consumuri, cheltuieli, fabricaie, vnzare . a.). Orice atribut se refer la o proprietate a unei entiti sau la o relaie, care se caracterizeaz prin nume (simbol cont, denumire cont, marca angajat, nume prenume etc.) i tip (numeric, caracter, logic, dat calendaristic etc.). Valorile unui atribut devin domeniul aferent acestuia (toate simbolurile de conturi, ansamblul mrcilor pentru angajai etc.). Realizarea unei entiti se definete ca mulimea format din cte o valoare pentru fiecare atribut al entitii (datele privind o nregistrare contabil, informaiile pentru un angajat, datele de caracterizare a unui mijloc fix etc.). ntro exprimare specific informatizrilor, datele complete pentru o entitate se numesc realizare sau instaniere a entitii respective. ntre dou atribute exist o dependen funcional cnd unei valori a unui atribut i corespunde o singur valoare a altui atribut (dependena simbol cont denumire cont, sau marca angajat nume_prenume angajat). Identificatorul unei entiti, cum sunt simbol_cont, marca_angajat, numr_de_inventar a mijloacelor fixe, este atributul sau grupul de atribute a crei realizare caracterizeaz n mod unic o realizare a entitii. De regul, identificatorul (unic) se subliniaz cu o linie continu. Uneori, pentru identificri este nevoie de un grup de atribute, cum cum este cazul identificrii depozitelor bancare pe deponeni sau a salariilor pe angajai.
16

Popescu,I.- Modelarea bazelor de date,Editura Tehnic,Bucureti ,2001, pag. 23-25

134

Legtura logic ntre dou sau mai multe realizri de entiti se realizeaz printro relaie sau coresponden care poate avea ea nsi atribute specifice. Stabilirea relaiilor se face tot cu ajutorul identificatorilor pentru entitile asociate. Ansamblul de entiti care constituie asocierea formeaz colecia sau baza de date aferent. O entitate oarecare poate fi antrenat n mai multe relaii. Pentru exemplificarea modului de aplicare a analizei EAR considerm activitatea de desfacere a mrfurilor unei ntreprinderi productoare de confecii ctre clieni. Cnd se livreaz marfa, la compartimentul de desfacere se emit facturi cu data livrrii, sortimentele de confecii livrate, cantitile i preul unitar aferente, cota TVA perceput i valoarea total a facturii. n acest context, schema EAR include: - entitile principale: sortiment_confecii, factur_livrri; - relaie: procesul de facturare fr identificator; - atribute: - pentru sortiment confecii: cod, denumire, model, mrime; - pentru factur_livrri: numr_factur, dat_factur, cota_TVA; - pentru relaia facturri: cantitate_facturat i pre_de_livrare. Ca identificatori se pot considera cmpul cod pentru sortiment confecii i numr_factur pentru factur livrri. Schematic, rezultatele analizei EAR se pot reprezenta 17 ca n figura 3.5. n acest mod se prefigureaz o baz de date cu cele dou entiti: sortiment_ confecii i factur_livrri, care vor deveni tabele ale aplicaiei comerciale a unei ntreprinderi. Fiecare entitate va avea cel puin o realizare, iar n proiectare a bazei de date trebuie avut n vedere faptul c fiecare cod de sortiment confecii trebuie s se regseasc printre codurile sortimentelor facturate. Acest exemplu denot nu nmai rezultatele imediate ale analizei EAR, ci i fixarea unor reguli de gestiune care s asigure restriciile modelului conceptual privind integritatea, securitatea i coerena datelor. Descrierea semnificaiei datelor se face prin dicionarul de date. Pe baza regulilor de gestiune se determin tipurile de relaii ntre realizrile atributelor din entiti i cele ale proprietilor relaionale, ce caracterizeaz cardinalitatea sau conectivitatea aferent, minimum fiind 0 sau 1, iar maximum fiind 1 sau n. n exemplul considerat, un sortiment de confecii ntro perioad poate avea minimum 0 facturri i maximum n facturri; o factur emis poate conine cantiti i preuri la minimum un sortiment de confecii i maximum n.

17

Adaptare dup Nstase P, .a. Baze de date. Microsoft Access 2000, Ed. Teora, Bucureti, 2004, pag. 24 135

numele entitilor
Sortiment_confecii cod denumire model culoare mrime

coresponden (asociere)
Se_factureaz cantitate_facturat pre_livrare

Factur_livrri nr_factur data_factur cota_TVA

atribute entiti
Fig. 3.5- Model conceptual privind vnzrile

n dezvoltarea modelului conceptual pentru proiectarea bazelor de date relaionale trebuie parcurse mai multe etape de lucru cum ar fi18: identificarea problemei de analizat, studiul specificului domeniului, analiza i proiectarea modelului conceptual, particularizarea modelului pentru un anumit mediu de programare, testarea i integrarea modelului. ntrun exemplu simplificat, fie problema contabilitii financiare la o micro-ntreprindere. n proiectarea bazei de date punctul de plecare l constituie documentele de eviden operativ care reflect tranzaciile i documentele de contabilitate. Astfel19 documentele justificative de eviden, centralizate ntrun document sintetic, sunt contate direct sau prin note contabile, rezultnd articolele contabile. Conform reglementrilor, consemnarea cronologic a articolelor contabile se face n registrul Jurnal, iar consemnarea sistematic se realizeaz n conturi sau registrul Cartea Mare. Pe baza celor dou registre, se ntocmete Balana de verificare a nregistrrilor contabile.
18

ugui Al, Muntenescu M. Medii de programare. Studii de caz, Ed. Junimea, Iai, 2001, pag.47 19 Grama A, Fotache M, ugui Al. Instrumente software pentru afaceri, Ed. Sedcom Libris, Iai, 2006, pag. 115 136

Printre particularitile domeniului analizat se pot remarca: culegerea datelor din documente justificative n baza de date a contabilitii financiare se poate realiza printro machet care reproduce nota contabil; notele contabile , la rndul lor, cu articolele contabile aferente se centralizeaz n Jurnalul de nregistrare, iar pe baza datelor din Jurnal i din Balana de verificare iniial se pot obine, la cerere, fiele de cont (Cartea Mare) i Balana de verificare. Deci, entitile bazei de date de contabilitate financiar sunt: (registrul) Jurnal, Balana i Planul_contabil aplicat la societatea comercial analizat. Pentru analiza i proiectarea modelului aplicativ, documentele contabile de reflectare a existenei i a micrilor patrimoniale, precum i atributele specifice sunt conforme cu regulamentul de aplicare a Legii contabilitii, dup cum urmeaz: - registrul Jurnal are antetul format din atributele: numr curent, data nregistrrii, document, explicaii, simbol cont debitor, simbol cont creditor, sum debitoare, sum creditoare; - o Fi de cont (sintetic), aparintoare Crii Mari, include att pentru debit ct i pentru credit atributele preluate din registrul Jurnal: data, explicaii, numr nota, cont creditor, respectiv, cont debitor, sum debitoare, respectiv, sum creditoare. Fia de cont mai include soldul iniial, rulaje, total sume i soldul final; - Planul de conturi specific organizaiei cuprinde: simbol cont, denumire cont i tip cont; - Balana de verificare cu patru serii de egaliti, la o anumit dat , insereaz: simbol cont, denumire cont, solduri iniiale, rulaje, total sume i solduri finale debitoare i creditoare cu totalizri pe coloane. Modelul conceptual al bazei de date necesit stabilirea relaiilor universale i optimizarea structurii astfel nct s se asigure integritatea referenial a constituirii i a prelucrrii bazei de date. Relaia universal include toate atributele menionate n cele patru documente contabile i o analiz a modului de obinere, ceea ce n proiectare nseamn analiza datelor. Optimizarea structurii bazei se poate face prin normalizare, folosind conceptul de forme normale ntro analiz detaliat a elementelor definitorii. Prima form normal presupune stabilirea lungimii adecvate a unei nregistrri i atomicitatea atributelor constitutive, adic definirea de atribute indivizibile. Dac cerinele primei forme normale sunt ndeplinite, atunci continuarea analizei presupune eliminarea dependenelor n interiorul atributelor de tip cheie primar cu valori unice. Aceasta necesit eliminarea dependenelor pariale n relaionarea atributelor rezultnd forma normal 2. Continuarea analizei necesit eliminarea dependenelor n afara cheii primare, adic forma normal 3 presupune eliminarea dependenelor tranzitive. Rezultatul normalizrii este un numr mare de tabele care asigur, n prelucrri, evitarea unor erori, cum ar fi pierderea de informaie cnd se elimin o nregistrare ntro tabel-printe.
137

n cazul considerat, modelul conceptual rezultat n urma normalizrii include entitile sau tabelele bazei de date Jurnal, Balana i Plan, cu atributele i restriciile urmtoare: Jurnal include atributele: data operaiei (data_op) de tip dat calendaristic, lungime 8 (zz/ll/aa); fel document (fel_doc) de tip caracter, lungime 12; numr document de tip numeric, lungime 8; dat document de tip dat calendaristic, lungime 8; explicaia de tip text; cont debitor de tip numeric, lungime 3, cont creditor, tip numeric, lungime 3, suma de tip numeric, lungime 15 din care 2 zecimale i numr_nota, de tip numeric, lungime 5. Atributele data operaiei, cont debitor, cont creditor i numr nota sunt chei candidate care pot deveni chei primare. Cont debitor i cont creditor sunt chei strine (fa de tabela printe), data operaiei trebuie s fie n anul curent, iar simbolurile de cont trebuie s se ncadreze n intervalul 101 -982; Balana, de atribute: cont (cheie primar, numeric, 3); sold iniial debitor (numeric, 15,2); sold iniial creditor (numeric, 15,2); rulaj debitor (numeric, 15,2); rulaj creditor (numeric, 15,2). Simbolul conturilor trebuie s se situeze n intervalul 101 -982; Plan, de atribute: cont (cheie primar, numeric, 3); denumire (caracter, 35); tip (caracter, 1) care poate fi A (cont de activ), P (de pasiv) sau spaiu (cont bifuncional). Nivelul fizic intern al unei baze de date corespunde structurii n care sunt stocate datele n memoria calculatorului, adic tabelele cu structura aferent i realizrile corespunztoare tranzaciilor precum i relaiile asociate . Astfel, n modelul de rezolvare pentru mediul de programare Access sau FoxPro, nivelul fizic presupune crearea bazei de date de contabilitate financiar, a tabelelor, a cheilor de relaionare, a indecilor i a restriciilor aferente. Indiferent de programul folosit, nivelul fizic al aplicaiei necesit urmtoarele operaii: - crearea bazei de date de contabilitate care s se numeasc, de exemplu, CONTA, ca i structur de container care va ncorpora, n principal, tabelele i relaiile dintre ele. n programul FoxPro baza de date este coninut n pagina DATA i poate fi integrat la un nivel superior, de proiect (de contabilitate financiar), care va ngloba i documente, proceduri, meniuri, etc.; - crearea structurii tabelelor Jurnal, Balana i Plan respectnd descrierile fcute i restriciile impuse. Pentru fiecare cmp se precizeaz: numele cmpului, tipul, lungimea, reguli de validare, textul asociat, indexarea pentru cmpurile subliniate. Tabelele Plan i Balana vor avea, ca i cheie primar (simpl), cmpul Simbol_cont; n cazul tabelei Jurnal, cheia primar sau candidat va fi format din atributele Data_operaiei, Cont_debitor, Cont_creditor i Numr_nota, care vor nlesni prelucrrile necesare obinerii fielor de cont (Cartea Mare) i a Balanei. n

138

FoxPro se recomand ca tabelele s fie create ca tabele libere i s fie adugate, ulterior, n componena bazei de date (cu butonul Add); - stabilirea legturii ntre tabele i a restriciilor de integritate referenial a datelor i a prelucrrilor. n programul Access, cheile pot fi primare i strine; o cheie care nu este primar se consider cheie strin, care face legtura unei tabele copil cu o cheie primar dintro tabel printe. Astfel, n tabela Jurnal sunt declarate cheile strine Cont-debitor i Cont_creditor, iar n tabela Balana este coninut cheia strin Cont. Automat, tabelele cu cheie strin devin tabele copii a tabelei printe, care conine acel atribut pe rol de cheie primar; tabela Plan este printe pentru tabelele Balan i Jurnal. Pentru a stabili legturile se acioneaz butonul de relaionri (Relationships); cu butonul stng apsat, dup poziionare pe cheia primar Cont, prin operaia de tragere sau drag and drop, se deplaseaz sgeata mouse- lui spre cheia strin Cont_debitor din tabela Jurnal. n acest fel se intr n fereastra Edit Relationships, se activeaz opiunea Enforce Referential Integrity i se execut clic pe butonul Create; se revine n fereastra Relationships unde legtura este reprezentat de tipul una la mai multe (one to many). Aceeai procedur se repet i pentru a stabili relaia ntre Plan i Jurnal prin atributele Cont i Cont creditor. Pentru realizarea prelucrrilor ntro tabel Plan1 se realizeaz aceeai structur cu tabela Plan i o relaie prin Cont din Plan1 i Cont _creditor din Jurnal. De asemenea, se stabilesc legturile ntre Balan i Jurnal prin cheia primar Cont din Balan i cheia Cont_debitor din Jurnal, repectiv din Balan1, similar tabelei Balan, i Cont_creditor din Jurnal. Dac se dorete actualizarea sau tergerea nregistrrilor n cascad ( de la prini la copii, concomitent), se activeaz opiunile meniului Relationships aferente, opiunea Create. Structura tabelelor se poate evidenia prin butonul Design. n FoxPro, declararea relaiilor dintre tabele se realizeaz pe baz de index, prin fereastra Constructorului bazei de date (Database Designer) prin operaia de tragere cu mouse-ul ntre numele indexului primar din tabela printe i numele indexului regular (strin) din tabela copil; linia rezultat este simpl la ieirea din tabela printe i trifurcat la intrarea n tabela copil; restriciile refereniale se pot declara prin activarea ferestrei de editare a relaiilor, Edit Relationships i a butonului de integritate, Referential Integrity; - popularea tabelelor cu date, de test sau reale, presupune tastarea coninutului nregistrrilor pentru fiecare entitate definit. Astfel, n tabela Plan se introduc o parte sau toate conturile utilizabile la firm redeschiznd tabela Plan din baza de date Conta; dac se dorete ordonarea nregistrrilor introduse se poate face o sortare sau o indexare dup valorile cmpului Cont, ascendent sau descendent folosind icon-urile A Z sau, respectiv, Z A din submeniul Window. n FoxPro sortarea se poate face cu comanda Sort rezultnd un alt fiier cu rezultatele sortrii care trebuie deschis i vizualizat, iar indexarea se poate realiza folosind comanda Index, rezultnd un fiier simplu sau un fiier compus cu valorile cheii de
139

indexare, ca adrese ce permit accesul direct la nregistrri. De asemenea, n FoxPro popularea cu date se poate face prin modul de lucru imediat Append cu salvare final a rezultatelor. Similar, se va popula cu date i tabela Balana prelund soldurile iniiale. Modificarea unor date se poate face direct prin poziionare pe acestea (n FoxPro modificarea datelor se face n modul de lucru Browse). tergerea de nregistrri este posibil prin fixarea indicatorului mouse-ului pe nregistrarea de ters i apoi acionnd tasta Delete. n FoxPro tergerea fizic de nregistrri mai presupune comanda de eliminare de pe suport prin comanda Pack. Culegerea, modificarea, vizualizarea i tergerea de date se poate realiza folosind Constructorul de formulare i subformulare (Forms Designer); - consemnrile cronologice prin contri se vor prelua n tabela Jurnal, iar stabilirea Balanei de verificare finale se poate realiza prin interogri ale tabelelor Jurnal i Balana pentru a obine completarea celorlalte serii de egaliti, atunci cnd se dorete controlul modului de operare; - prezentarea de rezultate ntro form agreabil se realizeaz folosind Constructorul de rapoarte (Reports Designer). n FoxPro realizarea fielor de cont sub form de fluturai se poate face realiznd selecia datelor necesare prin Constructorul de vederi (View-uri), care au la baz fraze Select de jonciune a informaiilor din tabelele incidentale. Pentru o alt ilustrare a concepiei, fie o societate comercial n care se aplic managementul prin proiecte ; societatea este format din mai multe departamente (servicii) n care lucreaz mai muli angajai, iar salariaii sunt ataai unor proiecte, executnd n cadrul acestora diferite sarcini, aa cum reiese din figura 3.5.

140

DEPARTAME NT
lucreaz_in

SALARIAT DIRECTO R PERSONA L

atasat_la PROIECT apartine_la execut SARCINA

conduce

Fig. 3.5. Structura general a modelului analizat

Elementele semnificative ale modelului analizat i legturile dintre acestea, sunt reprezentate n figura 3.6. Pentru aceast diagram, structurile SALARIAT, DEPARTAMENT, PROIECT, SARCINA reprezint entiti cu urmtoarele particulariti: 1. entitile (scrise cu majuscule), n modelele relaionale, devin tabele; 2. entitile sunt substantive, dar nu orice substantiv este o entitate. Trebuie ignorate substantivele nerelevante; 3. pentru fiecare entitate este obligatoriu s se dea o descriere detaliat; 4. nu pot exista, n aceeai diagram, dou entiti cu acelai nume, sau o aceeai entitate cu nume diferite; 5. cheia primar identific unic o entitate i face distincie ntre valori diferite ale entitii. Aceasta trebuie s fie unic i cunoscut la orice moment. Cheia primar trebuie s fie controlat de administratorul bazei, ca s nu conin informaii descriptive, s fie simpl, fr ambiguiti, s fie stabil, s fie familiar utilizatorului astfel nct acesta s o poat folosi cu uurin. O relaie (asociere) este o comunicare ntre dou sau mai multe entiti. Relaia exprim un raport care exist ntre aceste entiti. O valoare a unei pri este o comunicare ntre valorile entitilor care le leag. Existena unei relaii este subordonat existenei entitilor pe care le pune n coresponden cu precizrile:
141

1. n modelul relaional, relaiile devin tabele speciale sau coloane speciale care se refereniaz prin chei primare; 2. relaiile sunt verbe, dar nu orice verb este o relaie; 3. pentru fiecare relaie este important s se dea o descriere detaliat; 4. n aceeai diagram pot exista relaii diferite cu acelai nume. In acest caz, le difereniaz entitile care sunt asociate prin relaia respectiv; 5. pentru fiecare relaie trebuie stabilit cardinalitatea (maxim i minim) relaiei, adic numrul de tupluri ce aparin relaiei. Un atribut este o proprietate descriptiv a unei entiti sau a unei relaii. De exemplu, codul unui salariat este un atribut al entitii SALARIAT, iar data la care un salariat este ataat unui proiect este un atribut al relaiei ataat_la. Privitor la atribute se remarc urmtoarele: 1. trebuie fcut distincia ntre tipul atributului care uzual devine coloan n modelele relaionale i valoarea acestuia, care devine valoare n co loane; 2. atributele sunt substantive, dar nu orice substantiv este atribut; 3. fiecrui atribut trebuie s i se dea o descriere complet (exemple, contraexemple, caracteristici); 4. pentru fiecare atribut trebuie specificat numele, tipul fizic (ntreg, real, alfanumeric etc.), valori posibile, valori implicite, reguli de validare, tipuri compuse. Pentru proiectarea diagramei entitate-atribut-relaie (fig. 3.6.) au fost stabilite anumite convenii de reprezentare (care nu sunt unice): 1. entitile sunt reprezentate prin dreptunghiuri; 2. relaiile dintre entiti sunt reprezentate prin arce neorientate; 3. atributele care reprezint chei primare trebuie subliniate sau marcate prin simbolul #, plasat la sfritul numelui acestor atribute; 4. cardinalitatea minim este indicat n paranteze, iar cardinalitatea maxim se scrie fr paranteze; 5. nu trebuie specificate toate atributele. n proiectarea i analiza diagramelor EAR, se impun cteva cazuri speciale de entiti, relaii, atribute i modul lor de reprezentare, cum sunt: 1. o entitate dependent nu poate exista n mod independent. De exemplu, SARCINA depinde de PROIECT. Cheia primar a unei entiti dependente include cheia primar a sursei (nr_proiect) i cel puin o descriere a entitii (nr_sarcin). Entitatea dependent se deseneaz prin dreptunghiuri cu linii mai subiri;

142

SALARIAT

PROIECT

cod_salariat
nume prenume sex salariu

M(0)

atasat_la data_iniial funcia

M(0) nr_proiect
descriere buget_alocat

M(0)

1 lucreaz_in

conduce aparine_la 1(0)

DEPARTAMEN Tcod departament nume nr_cladire

SARCINA nr proiect nr sarcina data_nceperii stare

Fig. 3.6. Diagrama EAR pentru organizarea unui proiect

2. o subentitate este o submulime a unei alte entiti, numit superentitate. De exemplu, SALARIAT reprezint o superentitate pentru PROGRAMATOR, iar PROGRAMATOR este o subentitate pentru SALARIAT. Subentitatea se deseneaz prin dreptunghiuri incluse n superentitate. Exist o relaie ntre o subentitate i o superentitate, numit ISA, care are cardinalitatea maxim 1:1 i minim 1:0. Cheile primare, atributele i relaiile unei superentiti sunt valabile pentru orice subentitate. Afirmaia reciproc este fals. De exemplu, un programator poate avea ca atribute limbajele de programare cunoscute i nivelul de cunoatere a acestora, dar aceste atribute nu sunt semnificative pentru un agent teritorial. Cheia primar a subentitii PROGRAMATOR este cod_salariat, care este cheia primar a superentitii SALARIAT; 3. din entiti similare care au mai multe atribute comune se pot crea superentiti. Aceste superentiti conin atributele comune, iar atributele

143

speciale sunt asignate la subentiti. Pentru noile superentiti se introduc chei primare artificiale; 4. dup valorile unor atribute clasificatoare se pot determina clase. Un grup de subentiti reciproc exclusive definete o clas. Clasele se aliniaz n desen vertical. De exemplu, dup valorile atributului job_cod pot fi definite subentitile AGENT TERITORIAL i PROGRAMATOR; 5. ntr-o diagram EAR se pot defini relaii recursive. De exemplu, putem defini relaia SALARIAT_supervizeaza_SALARIU; 6. unele relaii sunt relative la dou entiti i le numim de tip 2, iar dac relaiile implic mai mult de dou entiti, le vom numi de tip 3. Trei relaii de tip 2 sunt diferite de o relaie de tip 3. Rupnd o relaie de tip 3 n trei relaii de tip 2, poate s apar o informaie incorect; 7. trebuie excluse din model relaiile indirecte (de tranzitivitate) pentru c ele pot conduce la redundan (informaie inutil, repetat) n baza de date; 8. atributele derivabile trebuie eliminate i introduse expresii prin care aceste atribute pot fi calculate; 9. uneori apare o incertitudine referitoare la faptul c o anumit informaie poate fi considerat o relaie sau un atribut. O relaie poate fi reprezentat ca un atribut, sau putem folosi relaii n loc de atribute. Dac un atribut al unei entiti reprezint cheia primar a unei alte entiti, atunci el refer o relaie; 10. uneori este greu de stabilit dac informaia analizat reprezint o entitate sau o relaie. Dac exist o incertitudine, se cerceteaz cheia primar. Dac aceast cheie combin cheile primare a dou entiti, atunci se definete o relaie. Cheia primar a relaiei asociat_la combin cod_salariat cu nr_proiect. Prin urmare, SALARIAT_asociat la_PROIECT va defini o relaie i nu o entitate; 11. un atribut indirect este inoportun. El nu descrie real relaia sau entitatea. Prin urmare, atributele indirecte trebuie reasignate. De fapt, un atribut indirect este un caz special de relaie indirect care trebuie eliminat pentru c introduce redundan n date. De exemplu, numrul cldirii n care lucreaz un salariat este un atribut al entitii DEPARTAMENT i nu este o caracteristic a entitii SALARIAT; 12. exist atribute opionale, a cror valoare este uneori necunoscut, alteori neaplicabil. Aceste atribute trebuie introduse la subentiti. De exemplu, comisionul pentru deplasare i zona de lucru sunt atribute specifice unui agent teritorial i trebuie introduse la subentitatea AGENT_TERITOTIAL.

144

Algoritmul pentru proiectarea diagramei entitate- relaie cuprinde urmtoarele etape: 1. identificarea entitilor din cadrul sistemului analizat; 2. identificarea relaiilor (asocierilor) dintre entiti i stabilirea cardinalitii; 3. identificarea atributelor aferente entitilor i asocierilor dintre entiti; 4. stabilirea atributelor de identificare a entitilor, adic stabilirea cheilor. Relaiile reflect legturi naturale care exist ntre componentele sistemului. Aceai realitate poate fi ns perceput diferit, de diveri analiti, pentru un acelai sistem, putnd fi obinute modele structurale distincte. Fluxurile i circuitele informaional-decizionale, strile i dinamica claselor de identiti se reprezint prin diagrame sau scheme care premerg scrierea programelor. n ultimul timp s-a impus limbajul unificat de modelare orientat obiect UML-Unified Modelling Language20. Scopul UML este vizualizarea, specificarea, elaborarea i documentarea reprezentrii unui sistem, care premerge elaborrii programelor. UML este un limbaj de modelare cu o notaie grafic simpl i o succesiune de pai de reprezentare a claselor de entiti i a relaiilor dintre ele. n acest scop se folosesc blocuri constructive de precizare a atributelor, a operaiilor i a responsabilitilor, reguli de combinare a blocurilor i reprezentri ale tranzaciilor dintre clasele de entiti. De exemplu, clasa de entiti este planul de conturi, atributele specifice sunt pentru fiecare element simbol cont, denumire i tip cont, iar relaiile se refer la interconectarea planului de conturi cu clasa Jurnal i clasa Balana n reprezentarea consemnrilor cronologice i sistematice a operaiilor cu impact patrimonial. Avnd n vedere nivelele modelului relaional i reprezentrile UML, proiectarea unei baze de date presupune realizarea modelelor: conceptual, logic i fizic. Corespondena ntre entiti se concretizeaz n restricii de integritate funcional,1 1 sau 1 n, ntre entiti- printe i entiti- copii, presupunnd asocieri ierarhice i respectarea unei ordini de reflectare a tranzaciilor (dac s-ar terge o nregistrare dintro tabel printe care are relaii cu nregistrri din tabele copii, atunci nregistrrile din tabelele copii devin orfane, adic ar crea inconsisten a bazei de date). Modelul logic al datelor de reprezentare a entitilor i a claselor de entiti se obine din modelul conceptual stabilind regulile de trecere cum ar fi21: - o entitate, cum este Jurnal, se reprezint ca o relaie cu nume distinct, iar identificatorul entitii, cum este numrul notei contabile, devine

20 21

Avornicului C, Avornicului M.Sisteme-analiz-proiectare, Ed. Risoprint, 2006, pag.193 Nstase P, .a.- Baze de date.Access 2000, Ed. Teora, Bucureti, 2004, pag.43 145

cheie primar a relaiei. Atributele entitii: data operaiei, fel document, numr document, etc. definesc structura relaiei; - o restricie de integritate funcional devine o legtur ntre relaii . Astfel, orice simbol cont folosit n Jurnal trebuie s se regseasc n planul de conturi; simbolul conturilor dintro not contabil se transform n cheie extern, secundar fa de simbolul din planul de conturi care este cheie primar. ntre simbolul contului din planul de conturi i simbolul contului din Balan, relaia este de 1 1; - n prelucrri pot interveni restricii de integritate multipl prin constituirea de chei candidate, concatennd mai multe cmpuri cum este n cazul tabelei Jurnal, n care cheia candidat este format din cmpurile data operaiei, simbol cont debitor, simbol cont creditor i numrul notei contabile. n acest mod, se pot realiza prelucrrile necesare emiterii fielor de cont i elaborrii Balanei de verificare. Modelul logic al datelor se poate prezenta descriptiv sau grafic. n reprezentarea descriptiv se scrie numele relaiei, cum este Plan_conturi urmat de atributele sale ntre paranteze rotunde n care cheia primar se subliniaz cu linie continu, iar cheia extern cu linie punctat. Mai mult, n limbajul SQL, crearea unei tabele se poate realiza direct prin comanda CREATE TABLE nume_tabel, urmat de descrierea, n paranteze, a atributelor, ca de exemplu: CREATE TABLE PLAN_CONTURI (CONT N,3 PRIMARY KEY, DEN_CONT CHAR,35, TIP_CONT CHAR,1) n reprezentare grafic, modelul logic se poate folosi de conveniile de modelare UML, n care numele entitii i atributele sunt descrise ntr-un dreptunghi, iar legturile se redau prin linii orizontale de la entitatea printe (Plan conturi) spre entitatea sau entitile copii (Jurnal i Balan). Pentru a realiza aceste reprezentri este nevoie s se cunoasc i regulile interne de gestiune a firmei , care se refer la tranzaciile ce au loc n dinamica entitilor patrimoniale prin operaii , cum sunt: emitere comand, facturare, aprovizionare, desfacere .a. Astfel de reprezentri sunt menite s permit raionalizarea circuitelor informaionale eliminnd redundanele i operaiile repetitive sau paralele din gestiunea patrimoniului. n concluzie, n proiectarea unei baze de date, modelul conceptual surprinde semnificaia informaiilor fr restricii tehnice sau economice, modelul organizaional adaug infomaiilor restricii structurale i economice, iar modelul logic presupune descrierea datelor i a relaiilor avnd n vedere condiiile impuse i tehnicile de gestiune ale entitilor patrimoniale. Modelul fizic al datelor rezult din descrierea bazei de date i a tabelelor aferente conform sintaxei mediului de programare (cum este de exemplu sintaxa comenzii CREATE TABLE).

146