Modelarea logic a prelucrrilor. Modelul logic de prelucrare. are ca scop definirea soluiei informatice pentru lucrrile de informatizat, precizate n cursul modelrii conceptuale urmrete s ajung la st ructuri care faciliteaz programarea i implementarea, prin descompunerea n ULP/PL/PL corespunztor posturilor de lucru din MCP, modelarea logic trebuie s asigure distribuirea prelucrrilor pe echipamentele aferente nu mai poate menine acelai grad de independen a datelor fa de prelucrri. Cum scopul urmrit const n definirea unei soluii informatice implementabile, n care interaciunea date-prelucrri este fundamental, conceperea prelucrrilor nu mai poate face, n aceeai msur ca pe nivelele precedente, abstracie de date.

1 2 33.1 3.2 3.3 3.43.4.1Unitile logice de prelucrareUnitatea logic de prelucrare(ULP/PL/PL) este o subdiviziune a lucrrii informatizabile definit n cursul modelrii conceptuale i, n acest context, izoleaz o parte din funcionalitatea acesteia. Decuparea lucrrilor n ULP/PL prezint mai multe avantaje: reducerea complexitii i izolarea efectelor modificrilor sau coreciilor aduse ulterior; cuprinderea detaliilor cerute de implementare este mult mai uoar la nivelul fiecrei ULP/PL; erorile sesizate n timpul testrilor vor putea fi mult mai uor localizate i corectate; schimbrile n regulile de funcionare vor opera numai n spaiul unei (sau unor) ULP/PL, restul sistemului rmnnd neschimbat.

1.1.1Decuparea n ULP/PLLa decuparea ULP/PL particip simultan dou criterii: unul provenind din structura datelor i cel de al doilea din structura prelucrrilor. 1.Structura datelor intervine n dou planuri: sub aspectul conservrii "obiectelor utilizator" i sub acela al tratrii tranzacionale a actualizrilor.

Obiectul utilizator desemneaz structura sau conceptul cu care utilizatorul lucreaz n activitatea curent. Nevoia definirii sale provine din faptul c reprezentarea informatic coincide n puine cazuri cu aceast structur. Spre exemplu, o comand adresat unui furnizor este, pentru utilizator, un "obiect" unitar i coerent; reprezentarea sa informatic se face ns prin patru entiti i trei asocieri diferite (figura 4.11), respectiv cinci tabele n BD.

Figura 4.11 Obiectul utilizator comand

Consecina este aceea c ULP/PL trebuie s respecte i s conserve aceast structur, asigurnd consultarea i actualizarea sa n concordan cu imaginea cu care este familiarizat utilizatorul. Corespondenele i prelucrrile aferente modului real de reprezentare informatic sunt efectuate "n culise", ascunse de ceea ce utilizatorul percepe ca aciune a sistemului. Tratarea tranzacional vizeaz cerina meninerii strii de coeren a datelor la ncheierea oricrei actualizri. Spre exemplu, memorarea unei comenzi trebuie s includ att adugarea unei nregistrri n tabela COMENZI ct i a nregistrrilor (una, dou sau mai multe) aferente din BUNURI_COMANDATE. Dac dup inserarea nregistrrii din COMENZI se produce un incident care mpiedic adugarea, parial sau integral, a nregistrrii sau nregistrrilor corespunztoare n BUNURI_COMANDATE, trebuie anulat i nregistrarea deja memorat n COMENZI. n ali termeni, memorarea unei comenzi se poate considera ncheiat numai atunci cnd s-au adugat, corect, nregistrrile corespunztoare n ambele tabele. n consecin, toate prelucrrile necesare asigurrii consistenei unei tranzacii trebuie s fac parte din aceeai ULP/PL. 2.structura prelucrrilor: Din punct de vedere al prelucrrilor, ULP/PL este o subdiviziune a lucrrii, care asigur o finalitate sau o funcionalitate perceptibil ca atare pentru utilizator. Regul: MED din MCP devine OBIECT UTILIZATOR n MLP Criterii generale privind structurarea n ULP/PL: Frecvena de prelucrare a ULP/PL; Grupurile/categoriile de utilizatori ale ULP/PL Omogenitatea ;i similaritatea prelucrrilor cerine de securitate similare. Criterii specifice privind structurarea n ULP/PL: Finalitatea lucrrii informatizabile conservarea obiectelor utilizator respectarea caracterului tranzacional al prelucrrilor prin intermediul RIR(restric iilor de integritate referenial).

1.1.1Compoziia ULP/PLPrin excelen, SIG se caracterizeaz prin exploatarea uneia sau mai multor baze de date. n consecin, prelucrrile ce compun lucrrile solicitate de ctre utilizatori trebuie traduse n aciuni de consultare i actualizare a unor seturi de nregistrri aflate n diverse tabele. "Semnificaia acestor seturi este cuprins n cerine; expresia lor informatic depinde de structura de tabele, cmpuri, chei primare i externe definite n cursul proiectrii logice a datelor. Regul: MED din MCP devine OBIECT UTILIZATOR n MLP 1.ULP/PL conine structuri responsabile cu prezentarea Marea majoritate a lucrrilor efectueaz un schimb de date cu exteriorul, fie prin preluarea de date noi, care nu sunt nc memorate (sau nu fac parte dintre cele pe care sistemul le memoreaz) fie prin furnizarea de rapoarte, afiate sau imprimate. Prelucrrile specifice acestei comunicaii compun o a treia structur, responsabil cu prezentarea fa de partenerul uman cu care are loc. Exist, n acest cadru, aspecte legate de forma prezentrii, desemnate prin termenul generic de interfa i comenzi, reguli i restricii legate de coninutul prezentrii, care dirijeaz comunicarea cu utilizatorul (sau logica dialogului). Modelul logic al prelucrrilor efectuate de fiecare ULP/PL se articuleaz, n consecin, pe aceste trei straturi: prezentarea, logica problemei i gestiunea datelor. Cum prima i a treia sunt n postura de a oferi serviciile necesare efecturii prelucrrilor ce compun finalitatea ULP/PL, este firesc s se nceap cu aceasta. 1.ULP/PL conine structuri responsabile cu gestiunea datelor memorate n BD PL trebuie s "tie" cum se exprim conceptele i termenii specifici cerinelor n raport cu tablele existente i s lanseze prelucrrile de consultare sau actualizare adugare, modificare, tergere aferente. 3.ULP/PL conine structuri responsabile cu logica problemei(specificul de business) Lucrarea, aa cum este formulat n cadrul cerinelor, are o anumit finalitate spre exemplu, emiterea unei comenzi de cumprare i preconizeaz, pentru atingerea acesteia, o suit de pai, "logici" pentru utilizator. Ordinea i regulile dup care se fac acetia depind de natura lucrrii sau sunt fixate de ctre utilizator. Apare, prin urmare, o a doua structur, responsabil cu logica de business a lucrrii sau, mai general, cu logica problemei. Aceste trei structuri se articuleaz ca nivele ale arhitecturii ULP/PL (Figura 4.12).

Figura 4.12 Arhitectura general a ULP/PL

Prezentarea cuprinde: schimbul de date cu utilizatorul, definit sub forma unor machete de ecran sau de rapoarte, n care figureaz setul de date introduse sau afiate i articularea structural a acestora; comenzile pentru utilizator, definite prin efectele pe care le au i prin regulile i restriciile de utilizare.

Logica problemei caracteristic fiecrei ULP/PL este definit informatic sub forma unor aciuni sau acte considerate valide i, n consecin, acceptate i executate - i a regulilor care definesc aceast validitate. Pe acest nivel se regsesc, de asemenea: regulile de gestiune restriciile de integritate relaiile de calcul cuprinse n cerinele sistemului Gestiunea datelor cuprinde schemele externe sau subschemele necesare ULP/PL pentru obinerea datelor necesare sau pentru efectuarea actualizrilor de care este responsabil. Acestea se pot defini grafic sau direct sub form de interogri SQL.

1.1.1Procedura logicProcedura logic desemneaz nlnuirea de ULP/PL necesare pentru executarea unei lucrri informatizabile (vezi studiul de caz, pentru exemplificare).

1.1.2Confruntarea cu BD (validarea modelelor)Dup definirea fiecrei ULP/PL, se confrunt schema/schemele sale externe cu BD pentru a identifica i corecta: absena din tabele a unor cmpuri necesare prelucrrii; imposibilitatea de a face asocierile necesare ntre datele aflate n table diferite. Dup ce au fost proiectate toate ULP/PL din sistem, se identific i se elimin eventualele cmpuri de date care nu sunt folosite n nici o prelucrare.

MLP EXEMPLUL 1: GESTIUNEA si DECONTAREA PRODUSELOR FINITE

Actori externi

PbcBanca EXC

Actori externi

PfExemplu 2 GESTIUNEA CREDITELOR BANCARE( c o ntinuarea

MCP )

ex din cursul

3.2.MLP Restricii de Integritate Referenial: RIR1 CLI.cnp = CO.cnp RIR2 CO.nrco = CH.nrco RIR3 /RATE. nrco = CO.nrco RIR4 CH.nrchit = /RATE.nrchit

OBIECTUL UTILIZATOR 1(OB_1) este CLICO/RATE provenit din MED1 care va fi activat prin PL1 OBIECTUL UTILIZATOR 2(OB_2) este COCHITANTE/RATE provenit din MED2 care va fi activat prin PL2

Desfacere F

Actori externi

P PL2Exemplu 3 GESTIUNEA BUNURILOR(autor

prof. Dr. D. Zaharie)

Modelarea logic a datelor

Transpunerea modelului conceptual al datelor n modelul logic relaionalAplicarea regulilor de transpunere a modelului conceptual al datelor (entitate-asociere) n modelul logic relaional conduce la urmtoarele tabele, cmpuri, chei primare i chei externe: FURNIZORI (Cod fiscal, Cod reg com, Denumire fz, Adres fz, Banca fz, IBAN fz) BUNURI (Cod bun, Denumire bun, Caracteristici,UM bun, Pre prestabilit) ANGAJAI (Cod intern ang, Nume ang, Prenume ang, Funcie, Loc munc, Statut ang) GESTIUNI (Nr gestiune, Denumire gestiune, Amplasare)

Serv CON

COMENZI (Nr comand, Data emiterii, Adresa livrare, Cod fiscal furnizor, Cod angajat responsabil) FACTURI (Nr factur, Data facturii, Data intrrii, Statut acceptare, Cod fiscal emitent, Nr gestiune, Nr comanda) NRCD (Nr nrcd, Data nrcd, Cod fiscal furnizor, Nr factur, Nr gestiune primitoare) ORDINE-PLAT (Nr op, Data op, Suma, Cod intern ang autorizare, Cod fiscal furnizor, Nr factur achitat) BUNURI-COMANDATE (Cod bun, Nr comand, Cantitate comandat, UM comand, Termen livrare, Pre convenit) BUNURI-FACTURATE ( Cod bun, Cod fiscal furnizor, Nr factur, Cant facturat, UM facturare, Pre facturare) BUNURI-RECEPIONATE (Cod bun, Nr nrcd, Cantitate cf doc, Cantitate intrat, Pret achizitie, UM cf doc, Statut recepie) C OMENTARII Deoarece pentru factur a fost menionat n MCD o restricie structural (restricia 7), cheia primar a tabelei respective este compus din cmpul Numr factur i din cheia extern Cod fiscal emitent, care exprim rolul entitii FURNIZOR n asocierea Emitent. n consecin, toate cheile externe privitoare la factur sunt compuse din aceste dou cmpuri (spre exemplu, BUNURIFACTURATE are cheia primar compus din cmpurile Cod bun, cheie extern n raport cu tabela BUNURI mpreun cu Nr factur i Cod fiscal emitent, cheie extern n raport cu tabela FACTURI). Modelul conceptual al prelucrrilor aduce o serie de elemente suplimentare n modelul logic al datelor. Sincronizarea lucrrilor presupune punerea n ateptare a evenimentelor survenite, pn n momentul n care condiia de sincronizare este verificat. Din consultarea modelului se constat c evenimentele ce particip la sincronizri sunt NRCD, Facturi, Facturi nesosite, Facturi refuzate, Facturi acceptate integral sau parial. Pentru a marca faptul c sunt n ateptare, pentru primele dou s-a adugat, fa de MCD, cte un atribut care s precizeze statutul acestora. n cazul NRCD, atributul statut recepie este plasat n tabela BUNURI_RECEPIONATE, pentru a putea reprezenta, n mod independent, starea fiecruia dintre bunurile consemnate n document i poate primi urmtoarele valori: n (netratat), a (acceptat), c (custodie - intrat dar neacceptat). n cazul facturii, atributul statut acceptare se afl n tabela FACTURI i poate lua una dintre valorile: n (netratat), a (acceptat), r (refuzat). n ambele cazuri, valoarea n indic starea de ateptare un nrcd a fost introdus i memorat, dar prelucrarea poate continua numai dup apariia facturii i, simetric, factura a fost introdus i memorat, dar se ateapt i nrcd corespunztoare. Restul evenimentelor sincronizatoare sunt stri generate prin prelucrri efectuate n sistem iar reprezentarea lor se face n raport cu tabelele existente. Facturile acceptate, spre exemplu, sunt acelea pentru care atributul Statut acceptare are valoarea a. Modelarea logic este de asemenea momentul n care trebuie s se decid n privina reprezentrii atributelor derivate: prin memorare sau prin recalculare la fiecare consultare. n studiul de caz prezent s-a optat pentru recalculare, ceea ce face ca aceste atribute s nu mai apar n tabele dar s solicite, n compensaie, redactarea de interogri pentru obinerea lor. Valoarea acceptat, spre exemplu, se obine nsumnd valoarea bunurilor intrate (bazat deci pe cantitile intrate i acceptate) din toate nrcd (unul sau mai multe) corespunztoare facturii respective sau nsumnd valorile bunurilor calculate pe baza cantitilor facturate, atunci cnd nu s-a ntocmit nrcd (n termeni de structur a BD, factura are cmpul Nr gestiune completat i implicit, verificat prin RI 8, nu exist nici un nrcd care se refer la ea).

Transpunerea relaionalNumrul RI 1 2 3 4 5

restriciilor

de

integritate

n

modelul

logic

6 7 8 9 10 11 12

Tabele i cmpuri implicate BUNURI.UM bun BUNURI_FACTURATE.Pret facturare BUNURI_COMANDATE.Pret convenit BUNURI_COMANDATE.UM comanda BUNURI.UM bun BUNURI_FACTURATE.UM facturare COMENZI.Data emiterii BUNURI_COMANDATE.Termen livrare ORDINE_PLATA.Suma BUNURI_RECEPTIONATE.Cantitate intrata, BUNURI_RECEPTIONATE.Statut receptie BUNURI_FACTURATE.Pret facturare FACTURI.Statut acceptare ANGAJATI.Statut ang FACTURI.cheia primar FACTURI.Nr gestiune NRCD.Nr gestiune primitoare BUNURI_COMANDATE.Cantitate comandata BUNURI_FACTURATE.Cantitate facturata BUNURI_RECEPTIONATE. Cantitate intrata BUNURI. Pret prestabilit BUNURI_COMANDATE.Pret livrare BUNURI_FACTURATE.Pret facturare COMENZI. Data emiterii BUNURI_COMANDATE.Termen livrare FACTURI.Data facturii FACTURI.Data intrarii COMENZI.Data emiterii NRCD.Data nrcd

Tabelul 41Tabelele i cmpurile implicate n restriciile de integritate definite la modelarea conceptual a datelor

1.1.1Modelarea logic a prelucrrilorVarianta de desfurarea a prelucrrilor folosind viitorul sistem informatic definit n cadrul modelrii conceptuale include urmtoarele 7 lucrri ce urmeaz a fi executate cu mijloace informatice: emitere comenzi, emitere nrcd, nregistrare intrri fr factur, acceptare factur, nregistrare intrare bunuri, nregistrare bunuri necomandate, plat facturi. Toate acestea fac obiectul modelrii logice a prelucrrilor. Pentru exemplificare, a fost aleas lucrarea Emitere nrcd.

Emiterea nrcdDin perspectiva utilizatorului, lucrarea servete pentru generarea nrcd pe baza rezultatelor recepiei i imprimarea pe hrtie a documentului aferent. Aceste dou funcionaliti conduc la definirea a dou ULP/PL (ULP/PL), care compun, mpreun, procedura logic aferent emiterii nrcd (Figura 4.13). Pentru fiecare ULP/PL structurarea continu pe cele trei nivele de arhitectur: prezentare, logica problemei i gestiunea datelor, n care logica problemei are rolul determinant.

Figura 4.13 Procedura logic EMITERE NRCD

ULP/PL pentru generarea nrcd

a. Logica problemeiGenerarea nrcd presupune: introducerea codului fiscal al furnizorului; introducerea numrului gestiunii primitoare; introducerea numrului facturii furnizorului (posibil compus dintr-o serie i un numr), dac acesta este cunoscut; atribuirea automat a numrului i datei documentului (implicit data curent); specificarea bunurilor recepionate, unul cte unul; memorarea n BD. Pentru fiecare bun recepionat, specificarea presupune: introducerea codului bunului; introducerea unitii de msur, cantitii i preului unitar (preul de achiziie) din documentul nsoitor; verificarea unitii de msur: dac aceasta nu coincide sau nu este un multiplu al unitii de referin din tabelul BUNURI, se emite un mesaj de avertisment; introducerea cantitii intrate n gestiunea respectiv (recepionate) i calcularea valorii intrrii.

Avnd n vedere c intrrile de bunuri se bazeaz pe comenzi prealabile, furnizorii i bunurile ar trebui s fie deja prezente n BD. Cum n practic nu sunt excluse anumite situaii particulare, este necesar s se prevad posibilitatea de a insera un furnizor nou (dac este prima cumprare de la acesta) i de a aduga bunuri noi, cu toate elementele corespunztoare: cod bun, denumire, caracteristici, um, pre prestabilit. Deoarece acestea conduc la adugarea de nregistrri n tabelele FURNIZORI i BUNURI, este necesar asigurarea accesului la ULP/PL aferente pe parcursul prelucrrilor pentru generarea nrcd.

a. PrezentareaNivelul de prezentare vizeaz setul de date afiate i amplasarea lor n ferestra de ecran prin care utilizatorul interacioneaz cu sistemul, setul de comenzi prin care utilizatorul poate interveni i dirija prelucarea de la tastatur sau mouse i logica dialogului, determinat, pe de o parte, de logica problemei i, pe de alt parte, de adaptarea strii comenzilor la starea curent a prelucrii. Schia ferestrei de ecran specifice acestei lucrri este prezentat n figura 4.14.

Figura 4.14 Schia ferestrei de ecran pentru introducerea nrcd

Comenzile disponibile pentru utilizator sunt urmtoarele: memoreaz nrcd, continu, nchide, anuleaz, furnizor nou, articol nou, imprim nrcd. Ultimele trei comenzi apeleaz ULP/PL aferente prelucrilor la care se refer, dup care se revine automat la prelucrarea n curs. n contextul ferestrei de ecran preconizate i a comenzilor menionate, logica dialogului este urmtoarea: 1. Ferestra de ecran se deschide pentru un nrcd nou. 2. Utilizatorul tasteaz sau selecteaz din list, furnizorul i gestiunea primitoare. Dac bunurile au venit nsoite de factur, se tasteaz numrul acesteia. 3. Pentru fiecare dintre bunurile primite: a. se tasteaz sau se selecteaz din list codul bunului i unitatea de msur menionat n documentul care a nsoit bunurile de la furnizor. Sistemul rspunde afind denumirea bunului corespunztor codului menionat i verificnd unitatea de msur. Dac aceasta nu este identic sau nu este un multiplu al unitii de msur memorate n sistem pentru bunul respectiv, se emite un mesaj de avertisment, dar prelucrarea poate continua

b. se tasteaz cantitatea i preul unitar din documentul nsoitor i cantitatea intrat, dup care sistemul calculeaz i afieaz valoarea intrrii. 4. Dup introducerea tuturor bunurilor, se cere memorarea nrcd. Sistemul emite un mesaj prin care confirm memorarea, blocheaz aceast comand pentru a evita acionarea repetat i face activabil comanda de imprimare. 5. Utilizatorul poate opta pentru comanda de continuare cu un nou nrcd sau pentru oprire. n orice moment, pn la lansarea imprimrii, utilizatorul poate abandona tratarea nrcd n curs prin comanda anuleaz, care terge toate datele introduse i revine la starea iniial. Dinamica activrii-dezactivrii comenzilor pe msura desfurrii prelucrrilor este sintetizat n tabelul urmtor. Stare prelucrare La iniierea unui nrcd La tastarea primului caracter Dup introducerea codului, um, cantitii i preului primului bun Dup acionarea comenzii de memorare Dup acionarea comenzii de imprimare Memor eaz Impri m Contin u Anulea z nchi de

Tabelul 42 Comenzi activabile n cursul generrii unui nrcd.

a. Gestiunea datelorTabelele al cror coninut este consultat sau actualizat pentru emiterea nrcd sunt urmtoarele (Figura 4.15): NRCD, n care se adaug o nregistrare pentru noul nrcd; BUNURI_RECEPIONATE, n care se adaug cte o nregistrare pentru fiecare bun intrat; FURNIZORI, GESTIUNI, BUNURI, din care sunt obinute, prin consultare, datele necesare i cu care sunt corelate, prin chei externe, nregistrrile nou introduse din NRCD i BUNURI_RECEPIONATE; Opional, tabelul FACTURI poate oferi referina privitoare la numrul facturii creia i corespunde recepia, n msura n care aceasta a fost deja memorat n sistem.

Figura 4.15 Subschema datelor pentru emiterea NRCD

ULP/PL pentru imprimarea NRCD

a. Logica problemeiNRCD este un document tipizat, care are un coninut minimal obligatoriu, din care se regsete doar o parte n setul de date memorate n sistem. Elementele care lipsesc, dar care trebuie s figureze n document, sunt urmtoarele: numele i prenumele membrilor comisiei

de recepie, numele i prenumele gestionarului care preia bunurile, tipul i numrul documentelor nsoitoare, mijlocul de transport i datele de identificare ale delegatului. n consecin, logica problemei, aici extrem de simpl, presupune introducerea acestor date (care nu se memoreaz, ci servesc doar pentru imprimare) urmat de imprimarea nrcd curent (tratat n ULP/PL anterioar). Imprimarea nu poate fi declanat dac nu s-au completat datele minimale obligatorii, respectiv membrii comisiei de recepie, numele gestionarului, documentul sau documentele nsoitoare, mijlocul de transport i delegatul.

Figura 4.16 Schia ferestrei de ecran pentru introducerea datelor suplimentare necesare imprimrii nrcd

b. PrezentareaPrezentarea cuprinde dou ferestre de ecran: prima, prin intermediul creia se introduc datele adiionale menionate anterior i cea de a doua, care afieaz imaginea nrcd n forma imprimabil (modelul de document tipizat, cod 14-3-1A). Comenzile oferite utilizatorului sunt: imprim, pentru declanarea propriu-zis a imprimrii, vizualizeaz/completeaz, pentru comutarea ntre cele dou ferestre de ecran, anuleaz, continu, nchide, comune cu cele de la ULP/PL precedent. La demararea ULP/PL, este activ implicit fereastra de completare a datelor. Comenzile vizualizeaz i imprim sunt independente dar continuarea cu un nou nrcd sau nchiderea sunt posibile numai dup ce documentul curent a fost imprimat (Tabelul 43). Anuleaz suprim toate datele introduse i reface starea iniial a acestei ULP/PL; continu i nchide sunt, aa cum s-a menionat, identice ca aciune cu cele specificate la generarea nrcd. Stare prelucrare La tastarea primului caracter Dup ce comisia de recepie, gestionarul, mijlocul de transport i delegatul sunt completate sau modificate Dup acionarea comenzii de vizualizare Dup acionarea comenzii de imprimare Vizualize az Impri m Contin u Anulea z nchi de

Tabelul 43 Comenzi activabile la imprimarea nrcd.

c. Datele

Gestionarul i membrii comisiei de recepie sunt angajai ai organizaiei: n consecin, numele i prenumele acestora se obin din tabelul ANGAJAI. Toate celelalte date suplimentare sunt temporare: se stocheaz n variabile locale doar pn la acionarea comenzilor continu, nchide sau anuleaz, dup caz. Implicit, la toate acestea se adaug ntreaga subschem de date a ULP/PL de generare a nrcd.

1.1 Probleme propusea. Elaborai modelul logic al prelucrrilor pentru lucrarea care asigur actualizarea nomenclatorului de bunuri, prin adugarea de bunuri noi, modificarea unor date ale bunurilor existente sau suprimarea unora dintre acestea (lucrare solicitat n problemele propuse pentru modelarea conceptual): structurarea n ULP/PL , logica problemei, prezentarea i datele aferente fiecreia dintre ele. b. Asigurarea prelucrrilor de la punctul anterior folosind o unic fereastr de ecran pentru prezentare modific structura i numrul de ULP/PL ? c. Elaborai modelul logic al prelucrrilor pentru lucrarea nregistrare intrare bunuri. Ce schimbri constatai fa de lucrrile executate interactiv, unitar i imediat ? d. Redactai interogarea SQL care afieaz bunurile preluate n custodie. e. Redactai interogarea SQL care calculeaz diferenele, n plus sau n minus, dintre valoarea intrrilor de bunuri la preuri de facturare i la preuri prestabilite, ntr-un anumit interval de timp. f. Redactai interogarea SQL care afieaz diferenele la recepie (nu uitai c, n afara diferenelor cantitative, pot aprea i situaii n care anumite bunuri care figureaz n documente nu sunt primite deloc sau s fie primite bunuri care nu figureaz n documente). g. Definii structura procedurii logice aferente lucrrii acceptare factur. h. Redactai interogarea SQL care calculeaz suma acceptat aferent unei anumite facturi (nlocuind spaiile din interiorul numelor de cmpuri cu cratime). i. Elaborai modelul logic al prelucrrilor pentru lucrarea plat facturi.

1.1 Sinteza noiunilor studiateRelaia este o submulime a produsului cartezian de N domenii, care se prezint sub form bidimensional (tabelar) pe linii i coloane, fiind numit i tabel; Tuplul reprezint o linie n cadrul tabelului, fiind numit i nregistrare (n englez record); Domeniul reprezint un set de valori pe care le poate lua o un atribut. Atributul reprezint o caracteristic care poate lua valori ntr-un domeniu, fiecrei caracteristici fiindu-i rezervat o coloan n cadrul relaiei. Cheia primar - reprezint un atribut sau un grup minimal de atribute ale crui realizri pot permite identificarea unic a unui tuplu ntr-o tabel. Cheia candidat - reprezint un atribut sau un grup de atribute care pot, prin realizrile lor, s identifice un tuplu. Cheia extern - este un atribut din schema unei tabele, care joac rol de cheie primar ntr-o alt tabel i respect cerinele de integritate referenial. Schema unei relaii reprezint lista atributelor aparinnd relaiei, cu domeniile lor. Gradul relaiei reprezint numrul de coloane (atribute) ale relaiei. Cardinalitatea relaiei reprezint numrul de rnduri ale acesteia. Unitatea logic de prelucrare (ULP/PL) este o subdiviziune a lucrrii informatizabile definit n cursul modelrii conceptuale i, n acest context, izoleaz o parte din funcionalitatea acesteia.

Logica problemei caracteristic fiecrei ULP/PL, este definit informatic sub forma unor aciuni sau acte considerate valide, precum i a regulilor care definesc aceast validitate. Prezentarea cuprinde schimbul de date cu utilizatorul, definit sub forma unor machete de ecran sau de rapoarte, n care figureaz setul de date introduse sau afiate i articularea structural a acestora. Gestiunea datelor cuprinde schemele externe sau subschemele necesare ULP/PL pentru obinerea datelor necesare sau pentru efectuarea actualizrilor de care este responsabil. Procedura logic desemneaz nlnuirea de ULP/PL necesare pentru executarea unei lucrri informatizabile.

1.2 Teste de autoevaluare1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea comenzilor primite de o societate comercial:CLIENT CodClient NumeClient AdresaClient TelefonClientTRANSMITE

COMANDA 0,n NrComanda 1,1 DataComanda

1,nCONTINE Cantitate Pret

GRUPA PRODUS CodGrupa DenumireGrupa 0,n

APARTINE

1,1nlocuit

0,n PRODUS CodProdus DenumireProdus UMProdusNLOCUIESTEnlocuitor

0,n

0,n

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) CLIENT(CodClient, NumeClient, AdresaClient, TelefonClient) b) NLOCUIETE(CodProdusnlocuit, CodProdusnlocuitor) c) PRODUS(CodProdus, DenumireProdus, UMProdus, CodGrupa) d) COMANDA(NrComand, DataComand, CodClient, CodProdus) e) CONINE(CodProdus, NrComanda, Cantitate, Pre) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea resurselor umane:ANGAJAT Marca Nume Prenume Adresa DataAngajarii 0,nPONTEAZA NrOre SalariuOrar LUCREAZA

COMPARTIMENT 1,n CodCompartiment DenumireCompartiment

1,1CONDUCE

0,1 0,n 0,nPRIMESTE

1,1

PLATESTE

1,n FISA PONTAJ NrFisa DataFisa Luna Anul 0,n SPOR CodSpor DenumireSpor ValoareSpor 0,n RETINERE CodRetinere DenumireRetinere ValoareRetinere

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) ANGAJAT(Marca, Nume, Prenume, Adresa, DataAngajrii, CodCompartiment) b) COMPARTIMENT(CodCompartiment, DenumireCompartiment, Marca) c) FISAPONTAJ(NrFia, DataFia, Luna, Anul, Marca) d) PONTEAZ(Marca, NrFia, NrOre, SalariuOrar) e) SPOR(CodSpor, DenumireSpor, ValoareSpor) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea unei biblioteci:TITLU CodISBN Denumire NrPagini TipCoperta 0,nAPARTINE

EDITURA 1,1APARUT LA AnAparitie

CodEditura 0,n DenumireEditura AdresaEditura

1,nSCRIE

1,1 EXEMPLAR NrInventar DataIntrare Disponibilitate

0,n AUTOR CodAutor NumeAutor DataNasterii Nationalitate

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) EDITURA(CodEditura, DenumireEditura, AdresaEditura) b) APARUTLA(CodISBN, CodEditura, AnAparitie) c) EXEMPLAR(NrInventar, DataIntrare, Disponibilitate, CodISBN) d) AUTOR(CodAutor, NumeAutor, DataNasterii, Naionalitate) e) TITLU(CodISBN, Denumire, Nrpagini, TipCoperta, CodEditura, NrInventar) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea conturilor bancare:CONT 0,n NrCont DataDeschidere TipCont 0,nCREDITEAZA SumaCreditoare DEBITEAZA SumaDebitoare

OPERATIE 1,n CodOperatie DataOperatie 1,n TipOperatie Explicatie 1,1 1,1PE BAZA

1,1DESCHIDE SOLICITA

1,n CLIENT CodClient NumeClient AdresaClient TelefonClient 0,n

1,n DOCUMENT CodDocument DataDocument TipDocument

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) OPERATIE(CodOperaie, DataOperaie, TipOperaie, Explicaie, CodDocument, Cod Client, NrContDebitor, NrContCreditor) b) CREDITEAZA(NrCont, CodOperaie, SumaCreditoare) c) CLIENT(CodClient, NumeClient, AdresaClient, TelefonClient) d) DEBITEAZA(NrCont, CodOperaie, SumaDebitoare)

e) DOCUMENT(CodDocument, DataDocument, TipDocument) 1. Se consider urmtorul fragment de model conceptual al datelor referitor la gestiunea unei case de schimb valutar:CLIENT CodClient NumeClient NumarActDeIdentitate TipActDeIdentitate 1,nSOLICITA

CURS CodCotatie DataCotatie CursVnzare CursCumparare 1,1COTEAZA

1,1BULETIN DE SCHIMB VALUTAR

VINDE SumaVnduta

0,n 0,n VALUTA SimbolValuta DenumireValuta TaraOrigine

NumarBSV DataBSV

1,1

1,1

CUMPARA SumaCumparata

0,n

Care dintre relaiile incluse n fragmentul de model logic corespunztor acestui MCD este eronat: a) CLIENT(CodClient, NumeClient, NumarActDeIdentitate, TipActdeIdentitate) b) CUMPARA(NumarBSV, SimbolValuta, SumaCumprat) c) BULETINDESCHIMBVALUTAR(NumarBSV, DataBSV, CodClient, SimbolValutaVndut, SimbolValutCumprat, SumaVndut, SumaCumprat) d) CURS(CodCotaie, DataCotaie, CursVnzare, CursCumprare) e) VINDE(NumarBSV, SimbolValut, SumaVndut)

1.1 BibliografieRspunsuri grile: 1-d 2-c 3-e 4-a 5-d

Unitatea de nvare 5MODELAREA FIZIC(CONSTRUIREA I TESTAREA SISTEMULUI)..........CURSURILE 11,12,13.

4. Construirea i testarea sistemului

Construirea sistemului are dou obiective: Adaptarea soluiei logice la specificul platformei pentru care va fi dezvoltat i pe care va funciona sistemul. Implementarea propriu-zis. n consecin, construirea are ntotdeauna asociat o platform, care, n cazul de fa, este Microsoft Access 2007.

1 2 3 4 55.1 Obiectivea) Aspecte generale privitoare la implementarea sistemului folosind Access 2007. b) Crearea BD: proprietile principale ale cmpurilor, crearea tabelelor, implementarea restriciilor de integritate pe domeniu, definirea cheilor primare i a indecilor, integritatea referenial i definirea cheilor externe. c) Aspecte generale privitoare la crearea aplicaiei. d) Crearea aplicaiei: formulare pentru dirijarea prelucrrilor, formulare pentru prelucrri, rapoarte i macrocomenzi. e) Testare aplicaiei: aspecte generale, costuri, modelul de proces pentru testarea sistemelor informatice, abordri privitoare la definirea scenariilor de test, abordri privitoare la execuia scenariilor de test.

1.1 Arhitectura general1.1.1Separarea datelor de aplicaieDezvoltarea de sisteme informatice de gestiune folosind Access 2007 urmeaz un model axat pe o baz de date unic, exploatat concurent de ctre posturile de lucru. n consecin, stilul arhitectural optim const n separarea sistemului n dou pri: prima, n care se regsesc numai tablele cu date i cea de a doua, care cuprinde restul elementelor, respectiv interogrile, formularele, rapoartele, macro-urile i modulelele de cod. Fizic, fiecare dintre acestea apare pe disc sub forma unui fiier baz de date (fiier ACCDB). Se ajunge astfel la o baz de date i o baz de proceduri(aplicativ). Dac se are n vedere o funcionare multitulizator, baza aplicativ se instaleaz pe fiecare post de lucru. BD se va afla pe un calculator distinct, accesibil prin reea de la toate posturile de lucru.

1.1.2"Obiectele" sistemuluiConstruirea sistemului se realizeaz n Access folosind cele ase tipuri de "obiecte" oferite de ctre acesta: tabele, interogri, formulare, rapoarte, macro-uri i module de cod-program. Tablele1 Tables - se separ, conform recomandrii anterioare, de restul obiectelor. Fac excepie tablele temporare i tablele statice, a cror amplasare n spaiul aplicaiei permite reducerea traficului de date ntre cele dou structuri. Tablele temporare sunt tablele folosite din considerente locale ale lucrrilor, fr a face parte din modelul logic al sistemului1 Table sau tabele

Formularele Forms - sunt obiecte prin care utilizatorul interacioneaz cu sistemul. Din punctul acestuia de vedere, formularele sunt cele care asigur introducerea de date de la tastatur, activarea comenzilor disponibile n sistem prin intermediul tastaturii i al mouse-ului i consultarea pe ecran a informaiilor provenite din BD sau a mesajelor emise n cursul funcionrii. Din punct de vedere al BD, formularele ar trebui s fie modalitatea unic de actualizare a tablelor, deoarece, pe lng elementele de grafic i ergonomie pe care le ofer, dau posibilitatea verificrii tuturor restriciilor de integritate (mai complet dect restriciile care pot declarate la nivelul tablelor) i permit actualizarea corelat a mai multor table (ntr-un mod transparent pentru utilizator). Din punct de vedere al aplicaiei, formularele sunt cele care activeaz i coordoneaz execuia diverselor prelucrri, fiind, din acest punct de vedere, obiecte pereche unitilor de prelucrare. Interogrile Queries sunt cereri (instruciuni) SQL de consultare i actualizare a BD folosite n funcionarea sistemului. n mod uzual, interogrile servesc drept surse de date pentru formulare, rapoarte sau componente ale acestora. Din perspectiva sistemului, pot fi memorate ca uniti distincte (stored query), primind aadar un nume sau pot fi ncorporate anonim n structurile care le folosesc (embedded query). Interogrile se obin fie prin interfaa QBE (Query By Example) fie prin redactare direct n limbajul SQL. Indiferent de modul de creare, execuia lor este oprimizat intern, ceea ce le recomand ca soluie prioritar n efectuarea oricrei consultri sau actualizri. Rapoartele Reports - constituie categoria de obiecte specializate n furnizarea de informaii n format imprimabil. Aceasta face ca, alturi de funcionalitile de grupare, structurare i calcul axate pe coninutul datelor prezentate, s existe i funcionaliti de gestionare a formei i de punere n pagin a rezultatului. Sursele de date ale rapoartelor sunt, ca i n cazul formularelor, tablele i interogrile, memorate sau ncorporate. ??????????????????P aici am citit pt cursul an III CIG Macrocomenzile, denumite pentru simplitate macro-uri Macros sunt structuri care permit, ntr-o manier simpl i transparent, automatizarea prelucrrilor aferente formularelor i rapoartelor. Un macro este un grup de aciuni memorate mpreun n scopul execuiei lor automate, ca un tot unitar. Aciunile corespund, cu cteva excepii, comenzilor i interveniilor pe care utilizatorul le poate declana sau ntreprinde prin intermediul tastaturii sau al mouse-ului. Pentru a rspunde ct mai complet funciei de automatizare, macro-urile includ mecanisme de execuie condiionat i iterativ i de apelare a altor tipuri de obiecte active, inclusiv alte macro-uri. Funcionalitile oferite sunt suficient de bogate pentru a permite practic realizarea unei pri nsemnate din prelucrrile necesare sistemului fr a recurge la programare. Ca i interogrile, macro-urile pot fi memorate distinct, cu nume proprii sau pot rmne anonime, ncorporate n formularele sau rapoartele n care sunt utilizate. Modulele Modules stocheaz unitile de program (proceduri, funcii, clase de obiecte) dezvoltate pentru realizarea sistemului. Programarea d acces la cea mai larg gam posibil de prelucrri i permite un control mai complet i mai nuanat comparativ cu macro-urile. Redactarea programelor se face n limbajul VBA (Visual Basic for Applications). Exist dou tipuri de module: clas i standard. Ca regul general, aplicaia se construiete n jurul formularelor. Acestea extrag i actualizeaz datele direct din table sau prin intermediul interogrilor. Tot formularele sunt cele care reacioneaz la evenimentele survenite n cursul lucrului, prin declanarea execuiei macro-urilor i a unitilor de program (subrutine i funcii) stocate n module. Rapoartele sunt o alt categorie de obiecte care reunesc table, interogri, macro-uri i uniti de program. Spre deosebire de formulare, acestea sunt pasive, n sensul c nu efectueaz dect consultri de date, ceea ce le face, n raport cu formularele, mai simple i mai limitate.

1.2 Crearea BDPunctul de pornire n crearea BD este reprezentat de structura definit n cursul proiectrii logice. Pe nivelul fizic se fac adaptrile necesare la platforma folosit i se definesc toate detaliile necesare constituirii sale. Elementele implicate aici sunt tablele i legturile dintre ele iar n cadrul fiecrei table, cmpurile componente, cheile primare, restriciile de integritate i indexrile cerute de optimizare.

1.2.1Particulariti n definirea cmpurilorn raport cu standardul SQL ANSI folosit n cursul proiectrii logice, particularitile vizeaz regulile de formare a numelor de cmpuri i tipurile acestora. n Access, sunt acceptate diacriticele i spaiile n componena numelor de elemente. n aceste condiii, numele trebuie delimitate prin ncadrarea ntre paranteze drepte. Gama tipurilor de date existente n Access este diferit dect cea specificat n standardul menionat iar pentru unele dintre tipurile similare, se folosesc denumiri (cuvinte cheie) diferite. Avnd n vedere aceste deosebiri, este fireasc revederea definirii cmpurilor din proiectarea logic. Tabelul urmtor prezint cteva dintre caracteristicile cmpurilor i a tipurilor de date specifice Access.

Proprietate Field Name

Rol denumirea cmpului tipul campului

Data Type

Explicaii - lungimea maxim 64 caractere alfanumerice, majuscule/minuscule - se poate utiliza caracterul underline (ex:NR_DOC) - nu poate conine caracterele .,!,[,] - ex: CIF, Nr contract, Data_factura -tipul Text este alfanumeric pe maxim 255 caractere, lungimea implict fiind de 50 caractere;ex: den_client,Text,50 -tipul Number permite declararea atribute lor de tip numeric, prediferite pe diferite inter vale admisibile de valori i zone de memorie de diferite lungimi; -poate asigura descrierea urmtoarelor subtipuri: integer, long integer, single, double, byte (acestea sunt prezente n proprietatea Field size) -Field Size asigur modificarea lungimii atributului pentru a respecta descrierea exact a acestuia n raport de semantica i valorile sale reale. -specifica]iile fundamentale sunt descrise n continuare: Subtip interval de valori numeric Integer [-2768,32767], pe lungime de 2 octei Long -2147483648, 2147483647] Integer Single [-1,401298*10-45, 3,402823*1038] pentru numere pozitive [-3,402823*1038,-1,401298*10-45] pentru numere negative Double [4,94065645841 247*10-324,-1,797 69313486231*10308] pentru numere pozitive i [-1,797 69313486231*10308,4,9406564584 1247*10-324] pen tru numere negative Decimal [-1028-1,1028-1] i permite precizia de 28 poziii prin activarea proprietii Precision; n memorie sunt utilizai 12 bytes Byte [0, 255 pe lungime de 1 byte;tipul este preluat din DA , -tipul AutoNumber poate fi utilizat pentru campurile ale cror valori sunt incrementabile; AutoNumber poate genera automat o valoare numeric corespunztor subtipului number-integer, incrementat cu valoarea 1 (Increment) sau prin intermediul unei generri automate (Random) -n tabelul urmtor sunt prezenta te specificaiile tipului AutoNumber : Subtip Interval de valori

AutoNumber -valorile atribuite pot fi secveniale, prin proprietatea New Values= Increment sau aleatoare prin proprietatea New Values=Random -atributul ocup 4 bytes, cu precizarea c atributele de tip AutoNumber sunt neactualizabi le

Number

Description

Field Size Format

Input Mask

-tipul este utilizat pentru campuri care iau valori de tip GUID, avnd o dimensiune de 16 octei -tipul Currency permite declararea campurilor de tip numeric, cu ablonul implicit de 9(15).9(4) avnd dimensiunea de 8 octei. Acest tip poate stoca o valoare numeric, ntr-un format fix cu maxim 4 zecimale, cu posibilitatea utilizrii erorilor de rotunjire. Valoarea va avea ataat simbolul valutar. -tipul Date/Time permite declararea cmpurilor lor de tip dat calendaristic. -tipul Yes/No permite declararea cmurilor de tip logic vnd urmtoarele posibile valori: adevrat(valoarea 1) sau fals(valoarea 0). o descriere a -aceast descriere a cmpului este opional i prezint importan rolului pe numai pentru proiectant i pentru verificri ulterioare. care l are campul respectiv dimensiunea -permite definirea dimensiunii maxime pentru tipurile de date Number, cmpului AutoNumber, Text; formatul de -permite definirea formatului de afiare a datelor specifice unui afiare atribut,separat pe tipuri de atribute, astfel: Cmpuri numerice: General Number, Currency, Fixed, Standard, Percent, Scientific Cmp tip dat calendaristic: General Date, Long Date, Medium Date, Short Date, Long Time, Medium Time, Short Time - pentru definirea abloanele InputMask pot fi utilizate formatul urmtoarele caractere: pentru Mod utilizare introducerea Caracter datelor A -litere i coninut incomplet & -orice caracter, spaiu, dar nu este permis un coninut incomplet C -orice caracter, spaiu, este permis un coninut incomplet 0 -cifre 0-9, fr semn, nu este per mis un coninut incom plet L -litere A-Z, nu este permis un con inut incom plet 9 -cifre 0-9, spaiu, este permis un coninut incom plet # -cifre 0-9, semn, spaiu, este per mis un coninut incom plet < -setul de caractere introduse este convertit n minuscule Replication ID

> . sau , : sau ; Default Value Validation Rule Validation Text Required

-setul de caractere introduse este convertit n majuscule -separator pentru mii sau zecimale -separator pentru date calendaris tice

-se poate utiliza atunci cnd sunt utilizabile valori predefinite Valoarea pentru cmpul curent implicit reguli de -proprietatea Validation Rule implementeaz restriciile relative la validare domeniul cmpurilor prin intermediul unor expresii Access

mesaj eroare

de - Access poate detecta situaiile n care regulile de validare nu sunt ndeplinite, moment n care afieaz mesajul de eroare definit la nivelul proprietii Validation Text obligativitate dac valorile ale unui cmp sunt obligatorii de introdus atunci de va definirii unei specifica opiunea Yes valori

1.2.2Crearea tabelelor Crearea fiecrui tabel presupune definirea cmpurilor i a cheii primare. Fiecare cmp posed o serie de proprieti, prin a cror setare se precizeaz caracteristicile dorite ale datelor memorate n spaiul acestuia. Unele dintre acestea proprieti sunt omniprezente, n timp ce altele depind de tipul datelor. Figura 5.1 prezint, pentru exemplificare, proprietile cmpului Data nrcd din tabelul NRCD.

Figura 5.1 Lista de proprieti a cmpului Data nrcd din tabelul NRCD

1.2.3Restriciile de integritate de domeniuSGBD Access admite, n mod implicit, declararea de restricii de integritate doar n cadrul fiecrui tabel. n acest scop, se utilizeaz proprietatea Validation Rule, care este prezent la nivelul fiecrui cmp i la nivelul tabelului. n consecin, restriciile care vizeaz strict coninutul unui cmp se declar n lista sa de proprieti iar restriciile care introduc corelaii ntre cmpurile din tabel, n lista de proprieti a tabelului. Proprietile Required i Allow zero length pot fi utile de asemenea n declararea unor restricii de integritate. Dac se dorete

definirea restriciilor de integritate pe domeniu ntre tabele singura soluie este oferit de limbajul SQL prin intermediul clauzei CREATE/ALTER TABLE ... CHECK (restricie). Restriciile de integritate a cror aciune include coninutul mai multor tabele diferite, cu excepia restriciilor de integritate referenial, pot fi declarate numai prin module de cod sau macrocomenzi n formularele de introducere a datelor, ataate la proprietatea de tip eveniment Before Update a structurii vizate- zon de tip Text Box, Combo Box .a.m.d. (control) sau a nregistrrii (form). Tabelul 51 trece n revist toate restriciile de integritate cuprinse n modelul logic al datelor din studiul de caz care pot fi implementate n cadrul tabelelor. Pentru exemplificare, figura 5.2 prezint maniera de declarare a restriciei 12 din studiul de caz i a restriciei privitoare la cmpul Statut acceptare, adugat prin modelul logic. Numru l RI 1 6 7 9 Tabele i cmpuri implicate BUNURI.[UM bun] ANGAJATI.[Statut ang] FACTURI BUNURI_COMANDATE. [Cantitate comandata] BUNURI_FACTURATE. [Cantitate facturata] BUNURI_RECEPTIONATE. [Cantitate intrata] BUNURI.[Pret prestabilit] BUNURI_COMANDATE.[Pret livrare] BUNURI_FACTURATE.[Pret facturare] Soluia de implementare n tabele proprietatea Validation Rule a cmpului proprietatea Validation rule a cmpului Cheie primar compus din dou cmpuri: Cod fiscal emitent i Nr factura proprietatea Validation rule a cmpului proprietatea cmpului proprietatea cmpului proprietatea cmpului proprietatea cmpului Validation Validation Validation Validation rule rule rule rule a a a a

10 11

12

proprietatea Validation rule a cmpului FACTURI.[Data facturii]- proprietatea Validation rule a tablei FACTURI.[Data intrarii] FACTURITabelul 51 Restriciile de integritate implementabile direct la nivelul tabelelor Access

Figura 5.2 Declararea restriciilor de integritate prin proprietile Validation Rule

1.2.4Chei primare i indeciIdentificarea nregistrrilor unei table se face pe baza cheii primare. Cum cutrile cele mai frecvente se bazeaz pe aceasta, este normal crearea unui index care, n conformitate cu cerinele modelului relaional, accept numai valori unice i nenule. Acest lucru se realizeaz n Access n mod automat. Varianta cea mai avantajoas este, din acest punct de vedere, utilizarea cheilor primare de tip AutoNumber. Indexarea constituie o modalitate de optimizare important i se poate aplica nu numai pentru cheile primare, ci i pentru alte cmpuri dup care se fac cutri frecvente. Prin difereniere de indexul cheii primare, acestea poart denumirea de chei de indexare, respectiv indeci secundari.

Figura 5.3 Relaiile dintre tablele ce compun BD, relaii prin care sunt definite restriciile de integritate referenial aferente cheilor externe

1.2.5Chei externe i restricii de integritate referenialO cheie extern se definete n Access prin crearea unei legturi (Relationships) ctre cheia primar corespunztoare, legtur pentru care trebuie activat verificarea integritii refereniale. Tipul de compunere ales la definirea cheii externe ar trebui s fie cel bazat pe corespondena reciproc (INNER JOIN), pentru a asigura un maxim de coeren. Verificarea restriciei de integritate referenial este realizat automat de ctre sistem. De asemenea, sistemul poate efectua automat i actualizrile antrenate de modificrile survenite n valorile cheilor primare implicate, prin activarea opiunilor Cascade Update Related Fields, Cascade Delete Related Fields. Aciunea lor este urmtoarea: la schimbarea valorii cheii primare dintr-o nregistrare, este ajustat automat i coninutul cheilor externe din nregistrrile care erau legate de aceasta i, respectiv, la suprimarea unei nregistrri, sunt terse automat i nregistrrile din alte tabele, legate prin chei externe de cheia primar a nregistrrii disprute. Acest mecanism funcioneaz "n cascad", pe ntregul lan de tabele legate ntre ele doar dac sunt activate opiunile amintite anterior. Figura 5.3 prezint tabelele ce compun BD din studiul de caz i cheile externe dintre acestea. Se pot observa chei externe compuse din dou cmpuri, necesare pentru referinele la factur, a crei cheie primar este format din codul fiscal al emitentului i din numrul facturii emise.

1.3 Crearea aplicaieiPartea aplicativ a sistemului cuprinde ansamblul prelucrrilor pe care utilizatorii le realizeaz prin intermediul su. Din perspectiva fiecrui utilizator, aceasta nseamn setul de lucrri executabile informatic. Din perspectiva intern a sistemului, toate acestea apar drept ULP/PL ce graviteaz n jurul BD actualizri, consultri, copieri de siguran i restaurri declanate de comenzile transmise de utilizator, de datele introduse de acesta, de structurile i configurrile rapoartelor furnizate i nu n ultimul rnd, de regulile de protecie i securitate. n termenii tipurilor de obiecte oferite de Access, aceasta nseamn formulare i rapoarte: primele pentru interaciunea cu utilizatorii i intervenia activ asupra BD, cele din urm,

pentru actele pasive de extragere i afiare, n structuri mai mult sau mai puin complexe, a coninutului memorat.

1.3.1Conectarea la BDAmplasarea datelor i aplicaiilor n locuri diferite impune instituirea unui mod de funcionare prin care fiecare post de lucru s aib acces, prin intermediul reelei, la datele necesare, fie pentru consultare, fie pentru actualizare. Una dintre alternativele propuse n acest scop de ctre mediul Access este conectarea (linking) la sursa sau la sursele externe de date. Stabilind o asemenea legtur, coninutul tablelor respective poate fi folosit n interogri, formulare i rapoarte ca i cnd acestea ar fi prezente local. Conectarea se poate face prin intermediul interfeei grafice sau prin subrutine VBA. Figura 5.4 prezint rezultatul legrii, pentru aplicaia aferent primului tip de post de lucru din studiul de caz. Tablele legate sunt figurate n panoul de navigare nsoite de o mic sgeat. Deoarece nu particip la nici una dintre lucrrile/procedurile logice ce sunt executate de la acest tip de post de lucru, ORDINE_PLAT nu figureaz printre tabelele accesibile.

1.3.2Structurarea aplicaieiDezvoltarea prii aplicative a sistemului graviteaz n jurul formularelor. Din aceast perspectiv, se pot evidenia trei tipuri de formulare: de prezentare a aplicaiei, de dirijare i de prelucrare. Primul dintre cele menionate este opional, dar confer o not de elegan i profesionalism, care are importana sa. Formularele de dirijare au menirea de a permite utilizatorului s aleag, s declaneze i, eventual, s intervin n derularea prelucrrilor dorite. Ultimul dintre tipurile menionate asigur efectuarea lucrrilor sau ale unor pri ale acestora.

Figura 5.4 Panoul de navigare n care figureaz tabelele legate din baza unic de date

Una dintre modalitile de structurare a aplicaiei const n alocarea unui formular distinct pentru fiecare lucrare informatizat. Paii (ULP/PL) pe care-i presupune lucrarea n cauz apar ca structuri distincte n cadrul formularului respectiv (aa cum se va vedea n paragrafele urmtoare). Formularele se grupeaz pe posturi de lucru tip, n funcie de lucrrile asociate acestuia i sunt coordonate de un formular de dirijare specific. Acesta din urm identific utilizatorul din postul de lucru din care este apelat i-i permite selectarea i activarea lucrrii pe care dorete s-o efectueze, n limita drepturilor care i-au fost atribuite. Formularul de identificare a aplicaiei, dac exist, este afiat pe o durat de cteva secunde, la deschiderea fiecrei sesiuni de lucru. Gruparea pe tipuri de posturi de lucru corespunde structurii de instalare i exploatare a sistemului. Un asemenea grup formeaz o structur aplicativ distinct, care se instaleaz pe fiecare post de lucru individual aparinnd tipului respectiv. Sistemul este compus fizic, n aceste condiii, dintr-o baz de date i una sau mai multe baze aplicative. Figura 5.5 prezint, pentru exemplificare, structura sistemului aferent studiului de caz. BD comun este exploatat de posturile de lucru din departamentul de aprovizionare, pentru emiterea comenzilor, a nrcd i pentru verificarea i formularea acceptului de plat pentru facturi, din zona contabilitii, pentru nregistrarea cumprrilor, a bunurilor neacceptate, preluate n custodie i din zona financiar, pentru achitarea facturilor. Pentru fiecare dintre tipurile menionate, pot exista mai multe posturi de lucru fizice: mai muli angajai care urmresc comenzile i realizarea aprovizionrilor, eventual specializai pe grupe de bunuri, mai muli salariai din contabilitate, respectiv din financiar, intervenind n sistem. Pe calculatorul aflat pe biroul fiecruia, trebuie s fie instalate programele ce permit executarea lucrrilor respective.

Figura 5.5 Sistemul informatic structurat n BD i aplicaii

1.3.3Formulare de dirijare a prelucrrilorDirijarea prelucrrilor se poate realiza, n Access 2007, prin intermediul formularelor sau prin particularizarea benzilor (ribbons) de comand. Un formular de dirijare este un formular obinuit, care conine doar butoane de comand. Acestea corespund lucrrilor ce pot fi executate i la acionare deschid automat formularele corespunztoare, prin intermediul unei subrutine sau unui macro ataate proprietii (On Click).

1.3.4Formulare de prelucrareSchema arhitectural avansat anterior prevede ca pentru fiecare lucrare (task) informatizat s se creeze cte un formular distinct. Acest formular asigur: a) preluarea de la tastatur a datelor specifice; b) efectuarea fiecruia dintre paii ce compun lucrarea respectiv; c) controlul derulrii lucrrii sub aspectul succesiunii i coerenei pailor executai. Pentru a rspunde cerinelor menionate la punctul a, formularul va include casete-text sau de alte tipuri, corespunztor datelor introduse, independente sau grupate, inclusiv n structuri de tip sub-formular dac este cazul. Funcionalitile menionate la punctul b pot fi asigurate structural n mai multe moduri: printr-un formular multi-pagin, prin sub-formulare sau prin formulare etichetate (tabbed). Pentru punctul c, soluia cea mai simpl const n introducerea unor butoane de comand, care devin active sau inactive n funcie de stadiul curent al prelucrrii. Un formular multi-pagin este un formular ale crui spaiu este mprit pe vertical n mai multe pagini virtuale prin inserarea de marcaje separatoare (Page break). Se evit astfel derulrile repetate prin barele de deplasare vertical iar imaginea prezentat utilizatorului poate fi structurat n grupuri logice de date. Un sub-formular este, n termeni foarte simpli, un formular obinuit, "gzduit" n spaiul unui alt formular. n aceast relaie, formularul primitor este numit principal. Gzduirea poate fi pur grafic, cnd coninutul celor dou formulare este independent sau funcional, cnd coninutul afiat de sub-formular este corelat (sau sincronizat) cu coninutul formularului principal, prin intermediul unei perechi de cmpuri sau de grupuri de cmpuri (Link Child Fields, Link Master Fields). Un formular principal poate conine mai multe sub-formulare diferite iar fiecare sub-formular poate include, la rndul su, alte sub-formulare. Sub-formularele reprezint soluia tip pentru a trata situaiile n care ntre nregistrrile prelucrate exist un raport 1 n. n acest context, unei nregistrri n formularul principal i se pot asocia mai multe nregistrri n sub-formular. Formularele etichetate (tabbed) sunt sub-formulare care partajeaz acelai spaiu de afiare pe ecran. n orice moment, doar unul singur dintre acestea este vizibil, celelalalte fiind ascunse. Trecerea de la un sub-formular la altul se face prin selectarea etichetelor respective. Este o modalitate foarte bun de afiare a structurilor complexe, fr a ncrca excesiv ecranul. Zonele n care se plaseaz sub-formularele sunt casete pagin (page controls) ale formularului principal. Alturi de cele prezentate, se poate recurge la soluia foarte simpl de a folosi mai multe formulare independente, deschise simultan, pentru diverii pai de efectuat, deoarece n Access acestea pot comunica date ntre ele. Pentru a evita incoerenele sau erorile, nchiderea acestor formulare trebuie controlat atent, prin program. Butoanele de comand sunt casete (controls) care au comportamentul grafic al unui buton uzual. Acionarea butonului este sesizat prin proprietatea On click, la care se poate ataa o subrutin sau o macro-comand care s execute prelucrrile aferente. Activarea sau dezactivarea butonului se obine prin setarea programat a proprietii Enabled, n funcie de starea curent a lucrrii.

1.1 Testarea sistemuluiTestarea este etapa care realizeaz validarea implementrii sistemului proiectat i are un scop dublu: pe de o parte se valideaz cerinele sistemului informatic iar pe de alt parte permite descoperirea erorilor. Pentru a se realiza testarea, aceasta trebuie conceput n prealabil n strict corelaie cu modul n care s-a proiectat funcionarea sistemului, de la nivelul cel mai general pn la cel mai detaliat. Ordinea activitilor de testare este ns invers, parcurgnd urmtoarele trei nivele: Pe unitai, De integrare, De sistem. Testarea pe uniti verific funcionarea separat a fiecrei uniti logice de program.

Testele de integrare vizeaz funcionarea unitilor de program n interaciune, respectiv n cadrul fiecrei proceduri logice. Testele de sistem se concentreaz asupra funcionrii ansamblului, n calitatea de software aplicativ coerent i unitar. Identificarea sursei erorilor i disfuncionalitilor i nlturarea lor presupune revenirea la oricare dintre nivelele de proiectare, inclusiv la programele surs i implic un efort creator, care conduce la ajustarea, la amelioarea proiectului. Este important ca identificarea problemelor/erorilor s se realizeze ntr-o faz ct mai apropiat de etapa identificrii cerinelor sistemului informatic deoarece costurile legate de eliminarea respectivelor probleme/erori cresc cu fiecare nou faz parcurs din cadrul dezvoltrii sistemului informatic: Faza 1. Cerine 2. Proiectare 3. Programare 4. Testare pe integrare 5. Testare de sistem 6. Exploatare Cost relativ la faza 1 1 3-6 10 uniti/de 15-40 30-70 40-1000

Tabelul 52: Costuri aproximative cu eliminarea defectelor n funcie de faza dezvoltrii sistemului informatic (IBM, GTE, et. al)

Spre exemplu, dac o anumit problem este identificat n momentul exploatrii sistemului informatic atunci costurile privitoare la rezolvarea respectivei probleme pot fi de zeci de ori mai mari dect costul identificrii problemei n faza de stabilire a cerinelor sistemului. La modul general, indiferent de tipul procesului de testare utilizat de ctre echipa de dezvoltare, pentru testare este necesar un ansamblu de date ce permite realizarea diferitelor scenarii pentru sistemul informatic dezvoltat. n corelaie cu aceste date, se stabilesc urmtoarele elemente: definirea scenariului de test: obiectul testului, punctele critice, rezultatele de obinut; valorile de test: datele de intrare n procedurile de actualizare, datele memorate nainte i dup execuia procedurilor, datele de ieire. Ian Sommerville prezint urmtorul model al unui proces pentru testarea sistemelor informatice:

Figura 5.1: Model de proces pentru testarea sistemelor informatice; adaptare Sommerville (2007, 539)

Conform acestui model, un scenariu de test2 specific datele de intrare, funcionalitile supuse testului i datele care trebuiesc obinute. Datele de test reprezint datele de intrare utilizate pentru execuia scenariilor de test. La final datele rezultate ca urmare a execuiei scenariilor de test se compar cu rezultele specificate de ctre scenariul de test. Dac rezultatele sunt identice se consider c testul a fost realizat cu succes. Un posibil eec al unui scenariu de test poate indica prezena uneia sau a mai multor erori n cadrul modulelor sistemului informatic, module utilizate pentru respectivul scenariu de test. Testarea riguroas a sistemului informatic nu se poate realiz fr definirea/proiectarea n prealabil a scenariilor de test. Literatura de specialitate (Sommerville 2007) a identificat trei abordri utilizate pentru definirea scenariilor de test: abordarea orientat ctre cerine abordarea orientat ctre partiionare abordarea structural Abordarea orientat ctre cerine presupune utilizarea cerinelor sistemului informatic pentru definirea scenariilor de test i are dou scopuri principale: validarea cerinelor (din punct de vedere al corectitudinii, completitudinii i omogenitii acestora) plus definirea unui set complet de scenarii de test care acoper toate cerinele(Bender 2009). Abordarea orientat ctre partiionare presupune definirea scenariilor de test n funcie de datele de intrare. Datele de intrare sunt divizate n submulimi disjunctive, operaie care se numete partiionare, scopul fiind acela de a construi scenarii de test care s utilizeze date de intrare reprezentative pentru fiecare submulime (Weyuker and Jeng, 1991). Abordarea structural permite definirea scenariilor de test avnd n vedere aspectele privitoare la structura codului surs. n funcie de modul n care se execut scenariile de test putem identifica dou tipuri de testare: testare manual i testare automat. n ambele cazuri, execuia scenariilor pentru testarea sistemului informatic de gestiune implic utilizarea unei(unor) baze de date de test. Testarea manual presupune implicarea unor persoane specializate3 care pentru fiecare scenariu de test pe care l parcurge joac rolul utilizatorilor finali. n anumite situaii, rolul acesta poate fi preluat chiar de ctre utilizatorii finali. Testarea automat presupune utilizarea, n mod uzual, a unor sisteme informatice specializat pentru execuia scenariilor de test. Dac pentru testarea manual este suficient realizarea unei documentaii care prezint procedura de testare pentru fiecare scenariu de test, n cazul testrii automate scenariile de test sunt definite la rndul lor sub forma unor proceduri sau funcii fapt care implic efort de programare.

2 En. test case 3 Numit i tester

Figura 5.6: Testare automat pe uniti realizat folosind cadrul de lucru NUnit

Dup ce sistemul a fost construit, testat i corectat (pus la punct), se genereaz formatul executabil final, ce se livreaz alturi de documentaia de utilizare a sistemului. Dincolo de toate aspectele privitoare la testarea sistemelor informatice este important urmtorul fapt: testarea sistemului are drept scop identificarea erorilor dar nu poate garanta lipsa total a acestora.

1.1 Studiul de caz1.1.1 Structurarea aplicaieiDezvoltarea aplicaiilor interactive graviteaz, n MS Access, n jurul formularelor. Din aceast perspectiv, pentru primul tip de post de lucru sunt necesare trei formulare de prelucrare i un formular de dirijare (Tabelul 53). Pe acest nivel, formularul de prelucrare este punctul de intrare n procedura logic aferent. n funcie de coninutul i particularitile acesteia, formularul poate avea o structur mai simpl sau mai complex i poate antrena activarea altor formularea, emiterea de rapoarte .a.m.d.

Lucrri Emitere comenzi Emitere nrcd Acceptare facturi Dirijare prelucrri ...

Formulare frmComenzi frmNrcd frmAcceptare frmAproviz1 ...

Tabelul 53 Formularele Access n jurul crora se structureaz aplicaia

1.1.2Emiterea nrcdn corelaie cu precizrile din proiectarea logic a prelucrrilor, a fost reinut aici procedura logic pentru emiterea notelor de recepie i constatare de diferene. Formularul de prelucrare prin care se intr n aceast procedur este cel corespunztor primei ULP/PL, respectiv generarea nrcd. Din interiorul acestuia, va fi activat formularul prin care este implementat a doua ULP/PL care va comanda, la rndul su, imprimarea nrcd ; documentul imprimat este, din perspectiva tipurilor de obiecte Access, un raport (Figura 5.6).

Figura 5.6 Suita de formulare i raportul prin care se implementeaz procedura logic aferent lucrrii Emitere NRCD

1.1.2.1ULP/PL pentru generarea nrcdImplementarea ULP/PL se poate face parcurgnd, n termeni generali, paii urmtori: se definete structura sursei de date i se creaz formularul, conform schiei din proiectarea logic a prelucrrilor se introduc facilitilor de culegere a datelor i de asistare a utilizatorului

se implementeaz restriciile de integritate nedefinite la nivelul tabelelor se introduc comenzile pentru utilizator se testeaz formularul i se efectueaz coreciile necesare.

Sursa de dateSubschema de date aferent acestei ULP/PL (similar celei definite la modelarea logic a prelucrrilor) este prezentat n figura 5.7. ntre cele dou tabele care asigur memorarea nrcd NRCD i BUNURI_RECEPIONATE- exist o relaie de 1 n, expresie a faptului c un nrcd conine unul sau mai multe bunuri. n toate situaiile n care apare o asemenea relaie, este recomandabil utilizarea unei structuri formular-subformular. n raport cu linia trasat n schem, parte din stnga formeaz astfel sursa de date (record source) a formularului (principal) iar partea din dreapta, sursa de date a subformularului.

Crearea formularuluin modul cel mai simplu de lucru, se creaz cte o interogare (query) care reunete tabelele respective i, pe baza fiecreia, se genereaz cte un formular cu structura i forma adecvate (figura 5.8). Cel de al doilea formular se plaseaz n spaiul celui dinti n postura de subformular i se stabilete legtura dintre coninutul afiat de ele prin perechea de proprieti Link Master Fields, Link Child Fields.

Figura 5.7 Subschemele datelor i paii n crearea formularelor aferente ULP/PL pentru generare nrcd : notaiile A i C indic tabelele actualizate prin adugare de nregistrri, respectiv consultate.

Faciliti la introducerea datelor i asistarea utilizatoruluiFormularul cuprinde trei zone de control de tip Combo Box (list de valori modificabil): codul fiscal al emitentului, pentru selectarea furnizorilor, numrul gestiunii, pentru precizarea gestiunii primitoare i codul bunului, pentru selectarea bunului recepionat. Pentru toate aceste zone de control, sursa de valori afiate (Row Source) este tabelul corespunztor (FURNIZORI, GESTIUNI, BUNURI); este activat cutarea parial (Auto Expand) i nu se admit alte valori dect cele existente n tabelele respective (Limit To List). Figura 5.9 prezint, pentru ilustrare, lista de proprieti a zonei Cod fiscal emitent.

Figura 5.8 Distribuirea datelor ntre formularul principal frmNrcd i subformularul BUNURI_RECEPIONATE. Legtura secionat prin linia punctat este preluat de perechea de proprieti Link Master Fields, Link Child Fields.

n momentul specificrii valorii pentru fiecare dintre aceste zone de control, sistemul afieaz automat, prin structura interogrii surs de date, datele aferente furnizorului (denumire i adres), datele aferente gestiunii (denumire i amplasare) i, respectiv, datele aferente bunului (denumire i caracteristici). Suplimentar, interogarea surs reine unitatea de msur memorat n tabelul BUNURI, pe care nu-l afieaz dar l folosete pentru a verifica unitatea de msur tastat.

Figura 5.9 Grupul de proprieti Data a zonei de control Cod fiscal emitent: ilustreaz utilizarea proprietilor Row Source, Limit To List i Auto Expand.

Figura 5.10 Grupul de proprieti Data a zonei de control ValoareIntrat: ilustreaz modul de calcul al valorii i utilizarea proprietilor Enabled i Locked pentru inhibarea accesului utilizatorului la acesta.

Accesul n zonele de control care afieaz datele extrase din tabele denumirea i adresa furnizorului, denumirea i amplasarea gestiunii primitoare, denumirea i caracteristicile bunurilor, la numrul nrcd(atribuit automat) i la valoarea intrat (calculat) este prohibit prin setarea adecvat a proprietilor Enabled i Locked (a se vedea, pentru ilustrare, figura 5.10). Selectarea documentului nsoitor este asistat de dou butoane de opiuni. Prin activarea acestora, se deblocheaz zonele de control n care se tasteaz numrul facturii furnizorului, numrul avizului de expediie sau ambele. S-a recurs la aceast soluie, n primul rnd, n sprijinul imprimrii nrcd. Inhibarea afirii barelor de deplasare i a selectorilor de nregistrri este util pentru a conferi mai mult naturalee i pentru evita anumite manevre ale utilizatorului, care ar putea periclita corectitudinea derulrii prelucrrilor. n acest scop, se seteaz adecvat proprietile aferente la nivelul formularului, respectiv Navigation Buttons i Record Selectors. Proprietatea Status Bar Text permite ataarea la fiecare zon de control a unui text de ghidare, text ce se afieaz automat n bara de stare n momentul n care devine activ. Este

posibil de asemenea, ataarea unei descrieri concise a semnificaiei zonei, afiate atunci cnd cursorul rmne cteva secunde deasupra zonei de control respective, prin proprietatea ControlTip Text.

Comenzile pentru utilizatorForma n care s-au implementat comenzile memoreaz nrcd, continu, nchide, anuleaz, imprim nrcd este cea a butoanelor de comand. Comenzile sunt determinate s devin activabile sau inerte prin setarea adecvat a proprietii Enabled. Spre exemplu, la iniierea unui nrcd, toate comenzile, cu excepia celei care permite nchiderea ULP/PL, sunt inactive (conform tabelului din proiectarea logic a acestei ULP/PL). Macrocomanda care le dezactiveaz, prin setarea proprietii menionate la valoarea False, este prezentat mai jos. Execuia acestei macrocomenzi este declanat prin proprietatea eveniment OnCurrent a formularului frmNrcd.

Figura 5.11 Blocarea butoanelor de comand printr-o macrocomand: ilustreaz utilizarea evenimentului On Current a formularului pentru a reaciona la deplasarea de la o nregistrare la alta.

Comanda Anuleaz devine activabil dup prima tastare sau selecie n list n oricare dintre zonele de control accesibile utilizatorului n formularul NRCD. Producerea acestui fapt este sesizat de proprietatea eveniment On Dirty. Pentru a evita multiplicarea macrocomenzii n toate zonele de control vizate, aceasta n-a mai rmas anonim, ci a primit numele deblAnulare. n felul acesta, poate fi apelat din toate punctele n care este necesar.

Figura 5.12 Macrocomanda comun deblAnulare, invocat n proprietatea On Dirty a mai multor zone de control ( data nrcd, cod fiscal emitent, nr gestiune, factura, aviz nsoire): ilustreaz utilizarea macrocomenzilor identificabile prin nume.

n mod similar, comanda Memoreaz este activat printr-o macrocomand ataat proprietii eveniment After Update a formularului BUNURI_RECEPTIONATE. Evenimentul aferent este declanat dup fiecare nregistrare pe disc a unei nregistrri (dup ce s-a introdus, deci, cel puin un bun intrat). Efectul comenzilor se obine prin execuia macrocomenzilor ataate proprietii eveniment On Click. n figura urmtoare este prezentat, pentru ilustrare, coninutul macrocomenzii ataate butonului de comand Continu: prin aciunea GoToRecord, aceasta realizeaz deplasarea la o nregistrare nou (adugat) n sursa de date a formularului NRCD i poziioneaz apoi, prin aciunea GoToControl, cursorul la Data nrcd. Deplasarea la o nou nregistrare prin GoToRecord determin ns producerea evenimentului Current n formularul NRCD, ceea ce declaneaz macrocomanda ataat proprietii acestuia (Figura 5.11 Blocarea butoanelor de comand printr-o macrocomand: ilustreaz utilizarea evenimentului On Current a formularului pentru a reaciona la deplasarea de la o nregistrare la alta.). Execuia acestei macrocomenzi are loc, aadar, dup aciunea GoToRecord dar naintea aciunii GoToControl. Activarea unei alte ULP/PL, aa cum este cazul pentru imprimarea nrcd, pentru adugarea unui furnizor sau a unui produs nou, se realizeaz deschiznd, printr-o macrocomand adecvat, formularului corespunztor. Formularul curent, din care s-a cerut prelucrarea, rmne deschis iar la ncheiere, se revine automat n spaiul i sub controlul su. Pentru imprimarea nrcd, s-a prevzut un buton de comand, conform structurii definite n cursul modelrii logice, la a crei proprietate eveniment On Click s-a ataat o macrocomand ce efectueaz deschiderea formularului frmImprNrcd (vezi i figura 5.15) prin aciunea OpenForm. Pentru comenzile furnizor nou i articol nou n-au fost inserate butoane de comand distincte, activarea lor fcndu-se prin dublu click pe zonele Combo Box ce le sunt afectate. Singura diferen fa de cele prezentate anterior este aceea c macrocomenzile sunt ataate acum proprietii On Dbl Click a zonelor respective.

Figura 5.13 Macrocomanda ataat proprietii eveniment On Click a butonului de comand Continu: ilustreaz modul de declanare a prelucrrilor specifice unei comenzi pentru utilizator

1.1.1.1ULP/PL pentru imprimarea nrcdRolul acestei ULP/PL este acela de a prelua datele care trebuie s figureze n documentul imprimat (impuse prin reglementrile n vigoare privitoare la nrcd) dar nu sunt memorate n tabelele NRCD i BUNURI_RECEPTIONATE i s declaneze generarea raportului prin care se obine forma imprimabil a documentului.

Sursa de date

O parte dintre datele suplimentare necesare membrii comisiei de recepie i gestionarul primitor provin din tabelul ANGAJAI. Deoarece comisia de recepie poate varia din punct de vedere al componenei i numrului de persoane, s-a optat pentru o soluie foarte simpl: utilizarea unui tabel temporar (care nu mai este amplasat pe server-ul de date) care s conin numele i prenumele respective (Figura 5.14). Toate celelalte date documente nsoitoare, mijloc de transport, delegat etc. - sunt pur i simplu introduse i folosite pentru generarea documentului, fr a mai fi memorate pe disc. nregistrrile din tabelul temporar MembriComisie sunt terse la acionarea comenzii de imprimare din formularul frmNrcd (Figura 5.15).

Figura 5.14 Structura tabelului temporar MembriComisie

Figura 5.15 Macrocomanda declanat la acionarea butonului btnImprima din frmNRCD: ilustreaz execuia unei interogri SQL, al crui text face parte din macrocomand.

Crearea formularuluiStructura formularului, n formatul Design, este prezentat n figura 5.16. Controlul NrNRCDImpr preia numrul documentului din frmNRCD, prin macrocomanda ataat proprietii On Current a formularului (Figura 5.17). Componena comisiei de recepie este introdus ntr-o structur de tip subformular, creat pe baza tabelului MembriComisie.

Figura 5.16 Structura formularului frmImprNRCD n formatul Design

Faciliti la introducerea datelorFacilitile de introducere a datelor vizeaz gestionarul i membrii comisiei de recepie, preluai, prin selecie, din tabelul ANGAJAI. n cazul gestionarului, s-a folosit o zon de control de tip Combo Box, care are drept surs de valori (Row Source) rezultatul unei interogri (query) care asociaz, ntr-un cmp unic, numele i prenumele angajailor i le afieaz n ordine alfabetic (Figura 5.18).

Figura 5.17 Macrocomanda prin care se preia numrul nrcd din formularul frmNRCD

Figura 5.18 Proprietile zonei Combo Box Gestionar: ilustreaz utilizarea interogrilor SQL pentru generarea unei surse de valori (Row Source) diferite de coninutul tabelului sau tabelelor din care se extrag datele.

Soluia aplicat pentru formularul ComisieRecepie (utilizat ca subformular n frmImprNRCD) este puin diferit (Figura 5.19). Zona NumeMComisie, de tip Combo Box, are o surs de valori (Row Source) cu dou coloane, fapt specificat prin proprietatea Column Count. Sursa datelor afiate este, ca i n cazul anterior, o interogare SQL. Coninutul primei coloane este atribuit zonei respective (NumeMComisie) prin proprietatea Bound Column. Coninutul celei de a doua coloane este plasat automat n zona Prenume de tip Text Box, printr-o macrocomand activat la producerea evenimentului After Update (produs dup reinerea valorii selectate din list). Specificarea unei coloane din sursa de valori a Combo Box se face prin proprietatea Column(i), unde indicele i precizeaz poziia coloanei dorite. Cum indicele primei coloane este zero, referirea la coloana a doua, n care se afl prenumele, se face prin expresia NumeMComisie.Column(1). Datele introduse n acest mod n cele dou zone sunt implicit stocate n tabelul temporar MembriComisie (care este sursa de date - Record Source a formularului), pentru a fi disponibile la imprimarea nrcd.

Figura 5.19 Structura formularului ComisieReceptie: ilustreaz folosirea proprietilor Column Count i Bound Column a zonelor de tip Combo Box i a proprietii Column(i) n cadrul unei macrocomenzi.

Comenzile pentru utilizatorButoanele de comand oferite utilizatorului sunt vizibile n figura 5.16 i corespund specificaiilor din modelarea logic a prelucrrilor. Din tablelul elaborat la modelarea conceptual a prelucrrilor rezult c la deschiderea formularului, toate comenzile sunt inactive. Deblocarea butonului de anulare se realizeaz n maniera prezentat la ULP/PL anterioar. Butoanele de comand pentru vizualizare i imprimare se deblocheaz dup completarea datelor minimale obligatorii din nrcd. n acest scop, s-a folosit o macrocomand comun, numit VerifComplDate, care este apelat din proprietatea After Update ale fiecruia dintre zonele Gestionar, MijlTransport i Delegat i din proprietatea On Exit a subformularului MembriComisie. Figura 5.20 prezint aceast macrocomand, n care se remarc expresia condiional prin care se verific dac zonele menionate au fost completate i dac exist cel puin doi membri pentru comisia de recepie.

Documentul imprimatFigura 5.21 prezint un nrcd, n forma n care este vizualizat i imprimat. Structura i coninutul respect modelul de document tipizat, cod 14-3-1A. Obinerea acestui document s-a realizat cu generatorul de rapoarte din MS Access. Structura raportului, n format Design, este prezentat n figura 5.22.

Figura 5.20 Macrocomanda VerifComplDate care deblocheaz butoanele de comand btnVizualizare i btnImprimare: ilustreaz execuia condiionat a aciunilor din macrocomand.

Figura 5.21 Modelul nrcd la imprimare

Sursa de date (Record Source) a raportului este o interogare n care se face compunerea tabelelor NRCD, FURNIZORI i GESTIUNI pentru nrcd cu numrul menionat n frmImprNRCD (preluat la rndul su din frmNRCD, unde s-a generat documentul). Textul acestei interogri este urmtorul:SELECT NRCD.[Nr nrcd], NRCD.[Data nrcd], FURNIZORI.[Denumire fz], FURNIZORI.[Adresa fz], GESTIUNI.[Denumire gestiune] FROM GESTIUNI INNER JOIN (FURNIZORI INNER JOIN NRCD ON FURNIZORI.[Cod fiscal] = NRCD.[Cod fiscal furnizor]) ON GESTIUNI.[Nr gestiune] = NRCD.[Nr gestiune primitoare] WHERE NRCD.[Nr nrcd]=forms![frmImprNRCD]![NrNRCDImpr];

Datele din zonele Text Box afiate n partea superioar a raportului nr nrcd, data, gestiunea mpreun cu denumirea i adresa furnizorului, provin din aceast interogare. Factura i avizul de nsoire sunt preluate direct din frmNRCD, care a rmas, ca i frmImprNRCD, deschis.

Figura 5.22 Structura raportului rptNRCD n formatul Design

Textul Subsemnaii, membrii comisiei de recepie ... este generat prin expresia Control Source a zonei respective, fiind obinut prin inserarea, ntre poriunile de text fix, a datelor specifice preluate din formularul frmImprNRCD i din interogarea menionat mai sus (Figura 5.23). Raportul conine dou subrapoarte: pentru afiarea bunurilor recepionate i pentru afiarea membrilor comisiei de recepie. Figura 5.24 prezint structura primului subraport. Sursa de date este o interogare care compune coninutul tabelelor BUNURI_RECEPTIONATE i BUNURI. Tot n aceast interogare se calculeaz i valoarea, aa cum se poate observa n textul su, prezentat mai jos:SELECT BUNURI_RECEPTIONATE.[Cod bun], BUNURI.[Denumire bun], BUNURI_RECEPTIONATE.[UM cf doc], BUNURI_RECEPTIONATE.[Cantitate cf doc], BUNURI_RECEPTIONATE.[Cantitate intrata], BUNURI_RECEPTIONATE.[Pret achizitie], [Cantitate intrata]*[Pret achizitie] AS Valoare, BUNURI_RECEPTIONATE.[Nr nrcd] FROM BUNURI INNER JOIN BUNURI_RECEPTIONATE ON BUNURI.[Cod bun] = BUNURI_RECEPTIONATE.[Cod bun] WHERE (((BUNURI_RECEPTIONATE.[Nr nrcd])=[forms]![frmImprNRCD]![NrNRCDImpr]));

Figura 5.23 Proprietatea Control Source a zonei care afieaz textul aflat deasupra tabelului cu bunurile recepionate: ilustreaz modalitatea de compunere a unui text unitar, folosind date preluate din mai multe surse.

Figura 5.24 Structura (sub)raportului BUNURI_RECEPTIONATE n format Design.

Denumirile coloanelor, n formatul grafic n care se dorete afiarea lor, sunt plasate n antetul raportului (Report Header). Dac ar fi fost plasate n antetul de pagin, care este poziia lor uzual, n-ar fi fost vizibile atunci cnd documentul servete ca subraport. Numrul curent este generat n zona Text Box aferent plasnd, n proprietatea Control Source, expresia =1 i setnd proprietatea Running Sum la valoarea Over All (Figura 5.25). Totalul valoric al intrrilor este calculat n seciunea Report Footer prin expresia Sum([Cantitateintrata]*[Pret achizitie]).

Figura 5.25 Proprietile zonei NrCrt: ilustreaz modalitatea de generare a numerotrii liniilor ntr-un raport.

Subraportul prin care se afieaz membrii comisiei de recepie are o structur extrem de simpl, singura prelucrare pe care o efectueaz fiind aceea de a combina numele i prenumele ntr-un cmp unic, cu eliminarea spaiilor excedentare.

1.2 RezumatUnitatea de nvarea 5 prezint aspectele generale privitoare la implementarea sistemului informatic de gestiune folosind Access 2007. Aspectul fundamental este acela al separrii datelor de aplicaie Se ajunge astfel la o baz de date i o baz aplicativ. n mod uzual, BD conine tabele iar baza aplicativ este constituit din formulare, interogri (QBE i SQL), rapoarte, macrocomenzi i module VBA. Ca regul general, aplicaia se construiete n jurul formularelor. Acestea extrag i actualizeaz datele direct din table sau prin intermediul interogrilor. Tot formularele sunt cele care reacioneaz la evenimentele survenite n cursul lucrului, prin declanarea execuiei macro-urilor i a unitilor de program (subrutine i funcii) stocate n module. Crearea BD presupune crearea tabelelor i a legturilor dintre tabele. Crearea unei tabele Access presupune definirea cmpurilor (proprietile Field Name, Data Type, Required, Default Value, Description, Field Size, Format, Imput Mask, Validation Rule i Validation Text). O atenie deosebit trebuie acordat definirii restriciilor de integritate astfel: chei primare, indeci, chei interne i integritatea referenial, reguli de validare la nivel de cmp sau tabel, restricii SQL (CHECK), macrocomenzi sau subrutine VBA asociate evenimentului Before Update. Baza aplicaiei, partea aplicativ a sistemului, cuprinde ansamblul prelucrrilor pe care utilizatorii le realizeaz prin intermediul su. Din punctul de vedere al tipurilor de obiecte oferite de cre Access, partea aplicativ nseamn formulare (de prezentare, pentru interaciunea cu utilizatorii i intervenia activ asupra BD), interogri, rapoarte (pentru aciuni pasive de afiare a datelor), macrocomenzi i structuri de program scrise n limbajul VBA. Testarea sistemului se poate realiza pe urmtoarele nivele: unitar, de integrare i de sistem. Testarea unitar verific funcionarea separat a fiecrei uniti logice de program. Testarea de integrare vizeaz funcionarea unitilor de program n interaciune, respectiv n cadrul fiecrei proceduri logice. Testarea de sistem se concentreaz asupra funcionrii ansamblului, n calitatea de software aplicativ coerent i unitar. Pentru testare este necesar un ansamblu de date ce permite realizarea diferitelor scenarii de test ale sistemului informatic dezvoltat. n corelaie cu aceste elemente, trebuiesc stabilite urmtoarele: definirea testului (obiectul testului, punctele critice, rezultatele de obinut) i valorile de test (datele de intrare n procedurile de actualizare, datele memorate nainte i dup execuia procedurilor, datele de ieire).

1.3 Probleme propusea. Cum poate fi implementat restricia de integritate (aferent RI 3) privitoare la corelaia dintre unitile de msur din tabelul BUNURI i cele nscrise, pe baza documentelor nsoitoare, n nrcd: amplasare, coninut macrocomand, eveniment declanator. b. Definii implementrile pentru butoanele de comand btnAnuleaz, btnMemoreaz i btnInchide, n toate formularele n care apar. c. Modificai expresia de generare a textului compus din forma imprimat a nrcd, astfel nct, n cazurile n care nu este specificat documentul nsoitor, poriunea fix de text aferent acestuia s nu mai apar. d. Documentul nrcd include, pe verso, o serie de detalii pentru situaiile n care se constat diferene la recepie. Consultai modelul de document tipizat i facei completrile necesare, att n frmIntrNrcd ct i n rptNRCD, pentru a obine la imprimant i partea verso a documentului. Actualizai corespunztor i modelul logic al prelucrrilor. e. Dezvoltai soluia de implementare pentru formularul de dirijare frmAproviz1.

f. Implementai procedura logic aferent lucrrii nregistrare intrare bunuri n conformitate cu soluia formulat pentru problema corespunztoare la modelarea logic a prelucrrilor. g. Implementai procedura logic aferent lucrrii acceptare factur, n conformitate cu soluia formulat pentru problema corespunztoare la modelarea logic a prelucrrilor. h. Implementai procedura logic aferent lucrrii plat facturi, n conformitate cu soluia formulat pentru problema corespunztoare la modelarea logic a prelucrrilor.

SISTEME INFORMATICE DE GESTIUNE

Unitatea de nvare 6

Introducerea n exploatare i

meninerea n funciune

4. Introducerea n exploatare i meninerea n funciuneObiectiveObiectivul acesti uniti de nvare este acela de a prezenta procesele i activitile aferente introducerii n exploatare a sistemelor informatice de gestiune i interveniilor de ntreinere a acestora, operate n cursul exploatrii curente. Studiul unitii permite: cunoaterea etapelor i activitilor parcurse la introducerea n exploatare cunoaterea strategiilor de tranziie de la sistemul actual la noul sistem informatic de gestiune nelegerea tipologiei proceselor de meninere n funciune a sistemelor informatice de gestiune i a activitilor specfice acestora cunoaterea tehnicilor specifice meninerii n funciune

Cuprins4.1. Introducerea n exploatare 4.2. Meninerea n funciune 4.2.1.1. Tipuri de meninere n funciune 4.2.1.2. Procesul de meninere n funciune 4.2.1.3. Tehnici specifice meninerii n funciune

1 2 3 4 5 66.1 Introducerea n exploatareIntroducerea n exploatare este procesul n cursul cruia se realizeaz instalarea noului sistem la organizaia utilizatoare i intrarea n funcionare curent. Efectuarea sa presupune: asigurarea echipamentelor informatice i a cilor de comunicaie necesare; instalarea pe echipamente a programelor aplicative dezvoltate i testate; crearea bazei/bazelor de date i ncrcarea lor cu datele din organizaie; instituirea structurilor i procedurilor organizaionale specifice funcionrii noului sistem. Unele dintre activitile implicate, cum sunt achiziia i amplasarea echipamentelor i a reelelor de comunicaie, instruirea utilizatorilor, elaborarea documentaiei de utilizare, se pot pregti sau realiza, parial sau total, simultan cu proiectarea, construirea i testarea sistemului.

Din punct de vedere al realizrii efective, introducerea n exploatare poate fi structurat n urmtoarele etape (Figura 6.1): planificarea procesului; asigurarea i pregtirea resurselor necesare; instruirea cu privire la funcionarea sistemului; realizarea tranziiei la noul sistem; evaluarea sistemului Planificarea introducerii n exploatare, ca efort de anticipare, ordonare i corelare a aciunilor, stadiilor, termenelor i resurselor, este indispensabil att datorit complexitii procesului i a consecinelor pe care le are asupra acceptrii i punerii n valoare a rezultatelor dezvoltrii sistemului ct i faptului c pot fi luate n considerare mai multe strategii de realizare efectiv. Resursele implicate n introducerea n exploatare sunt cele necesare utilizrii efective a sistemului, adic echipamentele informatice i de comunicaie, software-ul de baz i aplicativ, personalul de utilizare i de administrare, cadrul de funcionare amenajarea spaiilor, procedurile organizaionale etc. n privina echipamentelor i a software-ului, n funcie de contextul concret din organizaie, poate fi necesar achiziia de echipamente noi, extinderea, modernizarea sau reamplasarea celor existente. n mod asemntor, asigurarea personalului poate presupune noi angajri sau redistribuiri ale personalului existent. Stabilirea amplasrii fizice, efectuarea amenajrilor necesare i adoptarea msurilor organizatorice privitoare la procesele de business n contextul noului sistem, la posturile de lucru, sarcinile, lucrrile i responsabilitile acestora, sunt de asemenea indispensabile pentru asigurarea introducerii n funciune. Dei grupate ntr-o singur etap datorit finalitii aceea de a asigura i pregti resursele necesare activitile menionate pot fi decalate n timp, n paralel cu derularea activitilor de dezvoltare a sistemului, cu condiia, evident, de a fi finalizate n acest stadiu.

Figura 6.1 Etapele introducerii n exploatare a sistemului informatic

Instruirea vizeaz asimilarea cunotinelor i abilitilor necesare efecturii lucrrilor i proceselor de business n condiiile funcionrii noului sistem i are n vedere dou categorii de personal: utilizatorii i administratorii de sistem. Instruirea utilizatorilor este de mai multe tipuri, n funcie de caracteristicile sistemului i de nivelul de cunotine al acestora, i poate viza: utilizarea efectiv a sistemului; spre exemplu, cum se face emiterea comenzilor de aprovizionare, cum se introduc bunurile recepionate, cum se corecteaz o factur introdus greit .a.m.d.; conceptele de afaceri i organizaionale folosite sau introduse odat cu sistemul: spre exemplu, care sunt regulile de selecie a ofertelor furnizorilor, cum se trateaz intrrile de bunuri sosite fr documente etc; cunotine informatice generale: utilizarea calculatorului i a sistemului de operare, efectuarea anumitor operaiuni de uz comun, folosirea echipamentelor particulare etc. Utilizarea efectiv este prezentat n ghidul (sau manualul) de utilizare, care face parte din documentaia sistemului. Acesta poate avea mai multe forme: document structurat, imprimat pe hrtie sau pe un suport electronic, material de tip e-learning, asisten instantanee (help) inclus n software-ul aplicativ etc. Indiferent de forma folosit, este necesar organizarea uneia sau mai multor sesiuni de prezentare, nsoite de demonstraii, asigurate de membrii echipei de dezvoltare, care s ofere un prim contact cu viitorul sistem, ce pot fi urmate de aprofundri bazate pe studiul sau