Sisteme informatice financiar-bancare Sisteme informatice de gestiuneAutori: Prof. Univ. Dr. Mioara Udrica Lector. Univ. Dr. Martinov Dan

CUPRINSCAPITOLUL I - SISTEMUL INFORMATIC AL FIRMEI ........................................... 3

1.1 Sistem informaional ............................................................................ 3 1.2 Sistem informatic ................................................................................. 61.2.1 Structura general a unui sistem informatic .......................................................... 7

1.3 Proiectarea sistemelor informatice ....................................................... 8 1.4 Ciclul de via al unui sistem informatic ........................................... 11 1.5 Metode de proiectare a sistemelor informatice .................................. 14 TESTE FINALE ...................................................................................... 17

1.3.1 Principiile proiectrii i realizrii sistemelor informaionale ................................ 9 1.3.2 Strategii de proiectare a sistemelor informatice .................................................. 10 1.4.1 Caracteristici ....................................................................................................... 11 1.4.2 Modele ale ciclului de via ................................................................................ 13 1.5.1 Clasificri............................................................................................................ 14

CAPITOLUL II - METODE SISTEMICE ..................................................................... 20

2.1 Nivele de descriere ............................................................................. 20 2.2 Modele pentru date i prelucrri ........................................................ 21 2.3 Modelarea conceptual i organizaional a datelor .......................... 22 2.4 Modelarea logic i fizic a datelor ................................................... 42 2.5 Modelarea Conceptual a Prelucrrilor.............................................. 46 2.6 Modelul Organizaional al Prelucrrilor ............................................ 53 2.7 Descrierea logic i operaional a prelucrrilor................................ 59 TESTE FINALE ...................................................................................... 602.3.1 Modelul Entitate-Asociere .................................................................................. 23 2.4.1 Trecerea de la modelul Entitate-Asociere la Modelul Relaional ....................... 44 2.5.1 Caracteristici ....................................................................................................... 46 2.5.2 Construirea Modelului Conceptual al Prelucrrilor ............................................ 49 2.6.1 Caracteristici ....................................................................................................... 54 2.6.2 Construirea Modelului Organizaional al Prelucrrilor....................................... 54

CAPITOLUL III - METODE ORIENTATE OBIECT .................................................. 72

3.1 Metodologia orientat obiect. ............................................................ 72 3.2 Modelul obiect ................................................................................... 75

3.2.1 Obiecte ................................................................................................................ 75 3.2.2 Instrumente ale modelului orientat obiect ........................................................... 77 1

3.3 UML limbaj standard de modelare ................................................. 833.3.1 Descrierea limbajului .......................................................................................... 83 3.3.2 Definirea limbajului ............................................................................................ 85

3.4 Diagrame UML .................................................................................. 863.4.1 Diagrama cazurilor de utilizare ........................................................................... 87 Un scenariu este deci o instan a unui caz de utilizare, un flux de evenimente. ......... 87 3.4.2 Diagrama claselor i diagrama obiectelor ........................................................... 93 3.4.3 Diagrama de colaborare ...................................................................................... 99 3.4.4 Diagrama de secvene ....................................................................................... 101 3.4.5 Diagrama de stri .............................................................................................. 102 3.4.6 Diagrama de activiti ....................................................................................... 104

CAPITOLUL IV - O COMPARAIE NTRE METODELE ORIENTATE OBIECT I METODELE SISTEMICE ........................................................................................ 119 EXEMPLU FINAL 1 UTILIZAREA METODELOR SISTEMICE IN DEZVOLTAREA SISTEMELOR INFORMATICE - SISTEM INFORMATIC PRIVIND CONTRACTAREA SI APROVIZIONAREA CU MARFURI ................. 126 EXEMPLU FINAL 2 - UTILIZAREA UML IN DEZVOLTAREA SISTEMELOR INFORMATICE SISTEM INFORMATIC PENTRU CORELAREA ACTIVITATII DE ASAMBLARE CU COMENZILE CLIENTILOR ............................................... 141 BIBLIOGRAFIE ............................................................................................................. 145

3.5 Modelul sistemului real i diagramele UML ................................... 106 TESTE FINALE .................................................................................... 111

2

CAPITOLUL I - SISTEMUL INFORMATIC AL FIRMEIEtapa actual este etapa n care economia mondial trece de la societatea predominant industrial la societatea informaional, guvernat de un set nou de reguli, n care tehnologiile digitale permite accesarea, procesarea, stocarea i transmiterea informaiilor. Complexitatea activitilor desfurate la nivelul firmelor reclam o viziune sistemic, n care fiecare component este parte a unui ntreg. Utilizat n toate domeniile de activitate, conceptul de sistem nu are o definiie unanim acceptat. La nceput a fost definit ca mulime de elemente aflate n interaciune. Mai trziu, observnd c aceast definiie nu cuprinde sistemele logice formalizate, S. Cleen a definit sistemul ca o mulime pentru care sunt definite relaii. Generaliznd, o mulime formeaz un sistem dac pe ea se realizeaz o relaie dat, cu proprieti fixate. Sistemele astfel definite pot fi clasificate n funcie de caracterul proprietilor i al relaiilor. W. Ashby a observat c definiia este mult prea larg, dat fiind faptul c n orice mulime pot fi definite mai multe tipuri de relaii i a propus definirea sistemului pornind de la comportamentul su. A afirmat c sistemul se reprezint ca posibilitate de construcie n sens larg, cu presupunerea c exist capacitatea de a se da o anumit apreciere rezultatelor construciei. Dificultile cognitive aprute n studiul obiectelor complexe din sfera cunoaterii tiinifice moderne, au determinat n timp constituirea teoriei generale a sistemelor, disciplin tiinific care elaboreaz principiile metodologice de investigare a sistemelor, care asigur o baz formal metodologic unitar de cercetare.

n cadrul teoriei sistemelor, un loc important l ocup sistemele deschise, sisteme ce pot realiza o stare de echilibru dinamic cu mediul exterior. Principalele caracteristici structurale rmn constante, n timp ce sistemul realizeaz un schimb continuu de informaii cu mediul. Sistemele economice sunt considerate cazuri particulare ale sistemelor deschise.

1.1 Sistem informaional

Privit ca sistem, o firm poate fi structurat la rndul ei n trei mari subsisteme: subsistemul operaional (condus), subsistemul decizional (de conducere) i subsistemul informaional (de legtur). Fiecare din aceste subsisteme poate fi considerat ca un sistem de sine stttor ( fig. 1.1.a). SISTEM DECIZIONAL Informaii Decizii MEDIUL EXTERIOR

SISTEM INFORMAIONAL Date Decizii SISTEM OPERAIONAL fig. 1.1a

Sistemul informaional este reprezentat de totalitatea metodelor, procedurilor i mijloacelor folosite n procesul informaional. El poate fi definit ca un ansamblu organizat i integrat de operaii de culegere, transmitere, prelucrare, sistematizare, analiz i pstrare, difuzare i valorificare a informaiilor. Permind actualizarea datelor de intrare i legarea informaiilor din toate domeniile de activitate, sistemul informaional trebuie s fie capabil s furnizeze rapoarte periodice privind desfurarea activitii, dar i rapoarte la cerere, determinate de semnalarea unor situaii neobinuite. Ele fundamenteaz activitatea de analiz i prognoz, permit luarea rapid i eficient a msurilor ce se impun. Rolul determinant al informaiilor n procesul conducerii a impus definirea unei noi noiuni, decizia, ca fiind o informaie de comand pentru sistemul operaional. Eficiena deciziilor luate depinde de calitatea informaiilor furnizate. mpreun cu datele ce exprim nregistrarea fenomenelor i proceselor la momentul producerii lor, informaiile i deciziile realizeaz legtura ntre sistemul operaional i cel de conducere.

4

Scopul principal al sistemului informaional este de a furniza fiecrui utilizator toate informaiile necesare. Prelund datele de la sistemul operaional, sistemul informaional asigur pe de o parte informaiile necesare fundamentrii deciziilor, primete i transmite deciziile formulate de sistemul de conducere, iar pe de alt parte asigur legtura dintre mediul intern al firmei i cel exterior ei. Noua economie, specific societii informaionale, transform informaia digital n valoare economic i social, creeaz noi industrii modificndu-le pe cele existente, afectnd profund viaa cetenilor. Informaiile traduse ntr-un limbaj universal (computerizat) sunt privite ca o materie prim strategic, fundamental dezvoltrii economice i sociale. Cuplat cu reelele de calculatoare, informaia digitizat circul n timp real. Schimb procesele de producie, metodele de cercetare, organizarea muncii i obiceiurile consumatorilor. n aceste condiii, locul sistemul informaional tradiional este preluat de reelele Intranet. Intranet-ul este o reea local cu arhitectur bazat pe tehnologia Internet, care permite comunicarea ntr-un grup nchis de utilizatori care se raporteaz i construiesc o baz comun de informaii. Schimbul de informaii cu mediul exterior este preluat de Extranet, o aplicaie special care permite altor organizaii i persoane accesul la informaia difuzat pe Intranet. Cu aceste consideraii, subsistemele dintr-o firm pot fi reprezentate ca n figura 1.b. SISTEM DECIZIONAL Informaii INTRANET Date Decizii SISTEM OPERAIONAL fig. 1.1b Decizii EXTRANET

5

1.2 Sistem informaticSistemul informatic este un ansamblu structurat i corelat de proceduri i echipamente electronice de calcul care permit culegerea, transmiterea i prelucrarea datelor, obinerea de informaii. Sistemul informatic lrgete cmpul de aciune al sistemului informaional, i poteneaz valenele, mbuntindu-l sub aspect calitativ. Odat cu evoluia sistemelor electronice de calcul, sistemul informatic tinde s se suprapun sistemului informaional ca sfer de cuprindere. Mai mult, dac se include n sfera sistemul informatic activitatea de conducere a proceselor tehnologice cu ajutorul calculatoarelor de proces, sfera sistemelor informatice depete sfera sistemelor informaionale. n activitatea economic, sistemele informatice privesc obinerea informaiilor pe baza unor date de intrare i a unor normative, procedeele de prelucrare fiind considerate elemente intercondiionate i inseparabile ale procesului de conducere. Sunt sisteme informatice integrate, caracterizate prin aplicarea principiului introducerii unice a datelor i prelucrrii multiple a acestora n concordan cu cerinele informaionale specifice fiecrui utilizator. Utilizate n managementul firmei, sistemele informatice integrate (fig. 1.2) au la baz sistemele tranzacionale, concepute s eficientizeze i s automatizeze prelucrarea, s pstreze nregistrrile i s raporteze tranzaciile. Acestea sunt n permanent interdependen cu sistemele de birotic i comunicaii, utilizate pentru automatizarea muncii de birou. mpreun contribuie la definirea depozitelor de date, structuri pe care se bazeaz sistemele informatice de analiz.

6

SISTEME DE ANALIZ

DEPOZITE DE DATE

SISTEME

I N T E R N E T I N T R A N E T E X T R A N E T

DE

BIROTIC ISISTEME TRANZACIONALE

COMUNICA II BAZE DE DATE BAZE DE DATE

fig. 1.2 1.2.1 Structura general a unui sistem informatic Evidenierea structurii generale a unui sistem informatic se obine pornind de la funcia acestuia de a prelucra datele n vederea obinerii informaiilor necesare unei desfurri normale a activitilor ntr-o firm. Principalele componente sunt: intrri, prelucrri, ieiri. Intrrile sunt reprezentate de mulimea datelor ncrcate, gestionate i prelucrate n cadrul sistemului. Prelucrrile reprezint un ansamblu omogen de proceduri automate cu funcie de: creare i actualizare a bazei de date;7

consultare a bazei de date; reorganizare a bazei de date; salvare/restaurare a bazei de date. Ieirile sistemului informatic sunt reprezentate de rezultatele prelucrrilor desfurate. Ieirile pot fi obinute n urma unor operaii de transfer a datelor, sau pot fi obinute n urma operaiilor de calcul ce au la baz algoritmi prestabilii. n funcie de coninutul i forma lor de reprezentare, ieirile pot fi clasificate astfel: indicatori sintetici, regsii n tablourile de bord oferite managerilor (cifra de afaceri, profitul brut, profitul net). rapoarte, situaii ce regrupeaz diferii indicatori sintetici sau analitici (balana de verificare, bilanul contabil, statul de plat). grafice, ce permit reprezentarea ntr-o form sugestiv a dinamicii indicatorilor sintetici i analitici, a modificrilor de structur. foi de calcul electronice, generate cu ajutorul procesoarelor de tabele (Excel). Rezultatul obinut poate fi furnizat direct utilizatorilor, sau poate fi obiectul importului/exportului ctre sisteme de gestiune a bazelor de date. ieiri destinate altor sisteme, reprezentate de fiiere transmise online sau off-line n vederea prelucrrilor ulterioare n cadrul altor sisteme informatice.

1.3 Proiectarea sistemelor informaticen general proiectarea sistemelor informatice desemneaz activitatea complex de dezvoltare de sisteme informatice. Indiferent de metodologie, proiectarea urmrete ntregul ciclu de via al sistemului informatic. n etape distincte, pe diferite nivele de abstractizare, sunt construite modele ce evideniaz cele trei dimensiuni: static, dinamic i funcional. n sens restrns, proiectarea sistemelor informatice este una din etapele n care sunt grupate activitile desfurate pentru realizarea unui sistem informatic. Urmnd analizei i precednd implementarea, proiectarea extinde sau adapteaz modelele definit n faza de analiz, innd cont de8

restriciile impuse de mediul n care va funciona sistemul. Introduce elemente noi necesare trecerii la implementare. La ora actual, tendina de standardizare n conceperea sistemelor informatice determin o diminuare a fazei de proiectare, prioritate avnd modalitile de implementare i identificarea efectele pe care noul sistem le poate avea asupra unitii beneficiare. Faza de proiectare se reduce la elaborarea unor specificaii tehnice de implementare. 1.3.1 Principiile proiectrii i realizrii sistemelor informaionale Principiile ce trebuie respectate n activitatea de proiectare i realizare a sistemelor informatice sunt [SV03]: 1 Abordarea global a problemei de rezolvat. 2 Utilizarea unei metodologii unitare n proiectarea i realizarea sistemului informatic 3 Aplicarea celor mai moderne soluii i tehnici de proiectare i realizare a sistemului informatic 4 Structurarea sistemului informatic independent de structura organizatoric a firmei. 5 Participarea nemijlocit a viitorului beneficiar la activitile de analiz, proiectare i implementare a sistemului informatic. 6 Respectarea cadrului legislativ. 7 Realizarea unor sisteme informatice n concordan cu resursele disponibile la utilizator. 8 Anticiparea i controlarea permanent a schimbrilor survenite. 9 Explicitarea i documentarea compromisurilor inerente n dezvoltarea de software. Conform acestor principii, se definete nti o soluie global de informatizare, se stabilete structura flexibil a sistemului i se precizeaz prioritile n realizarea componentelor sale. Asigurnd implicarea beneficiarului pe tot parcursul realizrii sistemului informatic, se iau n calcul particularitile privitoare la modul de organizare a activitii, cadrul legislativ general i reglementrile interne aflate n vigoare.

9

1.3.2 Strategii de proiectare a sistemelor informatice n funcie de modalitatea de abordare a sistemelor informatice, strategiile de proiectare a sistemelor informatice pot fi grupate n trei mari clase: strategii descendente, strategii ascendente i strategii mixte. Strategia descendent (top-down) pornete de la principiul descompunerii sistemului informatic complex n componente mai simple prin parcurgerea unor nivele succesive de detaliere. Se definete astfel o structur ierarhic-modular n care fiecare component ndeplinete o anumit funcie. Strategia descendent se aplic n cazul sistemelor informatice complexe (sistemul informatic al unei bnci, sistemul informatic al Ministerului de Finane). Iniial se realizeaz o soluie global la nivelul ntregului sistem. Componentele se proiecteaz i se realizeaz independent, ntr-o ordine de prioritate stabilit de cerinele sistemului ca un tot unitar i n funcie de cerinele beneficiarului. Integrarea se realizeaz din treapt n treapt pornindu-se de la componentele elementare. Practic, strategia descendent const n: identificarea entitilor, componente relevante, interesante prin structura i comportarea lor; entitile trebuie s aib cel puin o realizare i cel puin un atribut; identificarea asocierilor dintre entiti; identificarea asocierilor de tipul generalizare/specializare i parte/ntreg. Dup realizarea generalizrilor/specializrilor se reactualizeaz lista entitilor care urmeaz s fie incluse n modelul datelor. Specializarea este necesar cnd o serie de asocieri ntre entiti au sens doar la nivelul unei specializri i cnd nu toate atributele sunt valabile pentru toate realizrile de entitate. Generalizarea se impune cnd entiti diferite prezint atribute similare sau asocieri analoage cu alte entiti. identificarea proprietilor de entitate i stabilirea cheilor; identificarea proprietilor de asociere; construirea modelului; verificarea modelului. Strategia ascendente (bottom-up) presupune proiectarea i realizarea componentelor viitorului sistem informatic, fr a avea o imagine10

de ansamblu asupra ntregului sistem informaional. Se trateaz separat fiecare component a sistemului, stabilirea corelaiilor ntre componente i integrarea lor n sistemul privit ca un tot unitar urmnd a se face ulterior. Lipsa unei strategii unitare aduce dup sine riscul unui grad redus de integrare a componentelor n sistem. Practic, strategia ascendent const n: identificarea proprietilor ; construirea grafului dependenelor funcionale; n cadrul dependenelor funcionale, arcele terminale obinute plecnd de la proprietile elementare definesc entitile. Originile arcelor constituie identificatorii de entitate. Arcele care rmn pun n eviden asocierile. Proprietile nerezolvate ce rmn sunt atribuite asocierilor. Proprietile izolate vor defini entitile izolate. determinarea structurilor teoretice de acces la date; construirea modelului; verificarea modelului. Strategia mixt reprezint o combinare a strategiei descendente cu strategia ascendent, mprumutnd de la fiecare avantajele. Practic se folosete strategia descendent pentru definirea sistemului ca un tot unitar i a componentelor lui, urmndu-se strategia ascendent n proiectarea i realizarea fiecrei componente.

1.4 Ciclul de via al unui sistem informatic1.4.1 Caracteristici Definirea unui sistem informatic este o decizie determinat de avantajele tehnologiilor informaionale aduse mediului de afaceri. mprirea n subsisteme, specificarea unor prioriti sau schimbarea condiiilor concrete de lucru, se regsesc att n cerinele legate de funciile sistemului (fundamentarea deciziilor imediate, urmrirea produciei) ct i n cele nefuncionale, ce refer proprietile calitative ale sistemului( flexibilitate, portabilitate). Gruparea activitilor pe etape, faze i activiti specifice se face n funcie de complexitatea modelului real, de cerinele utilizatorului sau de abilitile echipei de realizare a sistemului informatic.

11

n Proiectarea obiectual a sistemelor informatice ([ZR02]) autorii definesc ciclul de via al unui sistem informatic ca fiind perioada de timp cuprins ntre momentul iniierii acestuia i momentul scoaterii din funciune. Aceast perioad este mprit n dou etape fundamentale: dezvoltarea i exploatarea. 1. Dezvoltarea include perioada de timp necesar obinerii sistemului, trecerea la realizarea planului nsemnnd nceputul perioadei de dezvoltare. n timp ce proiectarea informaional vizeaz modul de funcionare a sistemului din punctul de vedere al utilizatorilor, modul n care se va derula activitatea la intrarea n funciune a sistemului, proiectarea informatic vizeaz arhitectura logic i fizic, mediul de dezvoltare sau de programare, programe, baze de date. 2. Exploatarea cuprinde perioada de timp n care sistemul este folosit n mod curent. n Sisteme informatice de gestiune([SV03]), autoarea afirm c ciclul de via al unui sistem informatic este perioada de timp cuprins ntre decizia de realizare a unui nou sistem informatic mai performant i decizia de nlocuire a sistemului existent cu unul nou. Pentru a asigura conceperea, realizarea, implementarea, exploatarea i ntreinerea sistemului sunt parcurse mai multe etape descompuse la rndul lor n faze. Acestea sunt: 1. Definirea cerinelor utilizatorilor, cnd se precizeaz obiectivele noului sistem, criteriile de eficien, securitatea, performanele. 2. Specificaia cerinelor sistemului, prezentarea detaliat a rezultatelor pe care sistemul informatic le va asigura. 3. Specificaia cerinelor software, lund n calcul restriciile sub care funcionalitatea sistemului urmeaz s fie asigurat. 4. Proiectarea general, cnd se definete soluia cadru, conceptual. 5. Proiectarea de detaliu, faz n care se rafineaz soluia cadru i se definete soluia final. 6. Realizarea componentelor sistemului informatic rezultate din elaborarea arhitecturii. 7. Testarea componentelor, cnd se verific modul de funcionare, modul de ndeplinire a cerinelor i fiabilitatea n functionare.

12

8. Integrarea componentelor i testarea final a sistemului, faz ce presupune realizarea produsului final i verificarea funcionalitii lui. 9. Implementarea i testarea produsului la beneficiar. 10. Exploatarea i ntreinerea sistemului. 11. Dezvoltarea sistemului, ce implic realizarea i integrarea de noi componente. Etapele ciclului de via se pot derula strict secvenial, sau pot determina reveniri la etapa anterioar (chiar la prima etap), n funcie de rezultatul validrilor intermediare. n funcie de complexitatea sistemelor reale, schimbrile din domeniul tehnologiei informaiilor se reflect fie n schimbarea etapelor, fie n modificarea opticii de parcurgere a lor. Ordinea i felul n care se parcurg etapele se regsete n literatura de specialitate sub numele de modele ale ciclului de via al dezvoltrii sistemelor. 1.4.2 Modele ale ciclului de via Dintre modelele ciclului de via care au ocupat un loc important n teoria sistemelor la vremea cnd au fost definite, i ale cror avantaje au fost preluate chiar i de cele mai actuale modele, se pot meniona modelul cascad i modelul spiral. Modelul cascad (Waterfall) a fost elaborat la nceputul anilor 1970, de ctre W.W. Royce. Ciclul de via este descompus n faze secveniale, structurate n activiti i subactiviti. Trecerea la etapa urmtoare presupune parcurgerea n ntregime a celei curente. Avantaje: fiecare etap este nsoit de documentare i se ncheie cu verificarea soluiei oferite; prin ordonarea i delimitarea clar a fazelor, se obine un control total al fazelor; este uor de nsuit de ctre membrii echipelor de analiz i proiectare. Dezavantaje: respectarea ordinii secveniale a etapelor nu este ntotdeauna conform cu realitatea;13

necesitatea parcurgerii integrale a etapelor anterioare duce la prelungirea timpului de realizare al sistemului; nu ia n calcul eventualele schimbri intervenite pe parcurs . Datorit acestor dezavantaje, n timp au fost propuse variante mbuntite, acceptnd reluarea pasului anterior ( waterfall model with back flow) sau reluarea de la faza iniial ( Da Capo waterfall model), permind astfel corectarea erorilor ivite pe parcurs. Modelul spiral a fost elaborat de B. W. Boehm, n 1988. Dezvoltarea sistemului se face n spiral. Pentru fiecare nivel se face analiza riscului i se construiesc prototipuri succesive. La fiecare iteraie sunt reluate fazele de dezvoltare, ce includ simularea i testarea prototipului, determinarea i validarea cerinelor rezultate din testare, planificarea ciclului urmtor, regsindu-se modelul cascad. Dup efectuarea studiilor de fezabilitate, sistemul se realizeaz, se integreaz i se instaleaz n varianta modelului cascad. Condiionat de profesionalismul echipei de dezvoltare, avantajul acestui model const n faptul c ofer posibilitatea evalurii riscurilor n diferite momente.

1.5 Metode de proiectare a sistemelor informaticeAnsamblul modelelor pentru un sistem informatic este elaborat conform unei metode, definit printr-un proces, o notaie i un set de instrumente informatice [ZR02]. Metoda, cunoscut sub numele de metod de proiectare, specific activitile ce trebuie efectuate pentru conceperea sistemului, ordinea n care se execut i modul lor de corelare. Pentru fiecare activitate sunt definite intrrile, ieirile i sunt formulate instruciunile de realizare. 1.5.1 Clasificri ntr-o prim clasificare, metodele de proiectare pot fi grupate n metode hard i metode soft. Metodele hard pun accentul pe abordarea tiinific i consider c realitatea, independent de oameni, poate fi modelat, neleas i transformat n funcie de dorinele acestora. Consider c toate problemele14

pot fi formalizate pe baze matematico-logice i acord proiritate datelor, funciilor i proceselor. Metodele soft, dintre care cea mai cunoscut este metoda SSM (Soft System Methodology) introdus de P Checkland n 1981, ncearc s rezolve probleme legate de aspectele sociale ale dezvoltrii sistemelor, de cerinele utilizatorilor. Din punctul lor de vedere, analistul se confrunt cu situaii problem i nu cu probleme clar definite i gata de rezolvare. Msurile luate ntr-o situaie sunt rezultatul schimbrii organizaionale, analistul de sistem fiind vzut nu ca un expert n domeniu ci ca un agent al schimbrii, capabil s-i stimuleze pe ceilali n obinerea unor noi percepii asupra contextului problemei. O alt clasificare, recunoscut mai ales n literatura francez, mparte metodele n funcie de modalitatea n care este perceput sistemul. Exist astfel metode de analiz i descompunere ierarhice (funcionale), metode de analiz i reprezentare orientate-sistemic i metode de analiz i proiectare orientate-obiect. Metodele ierarhice iau n calcul fiecare funcie i subfuncie a sistemului. Se definete o ierarhie pn se ajunge la componente suficient de mici astfel nct s fie programate cu uurin (fig.2.2). F1

F11

F12

F13

F111

F112

F121 fig. 2.2

F123

Caracterizate prin simplitate i o bun adaptare la cerinele utilizatorului, aceste metode prezint dezavantajul c orice schimbare de funcie a sistemului presupune reconsiderarea aplicaiilor. n plus, efortul este centrat asupra funciilor de prelucrare, neglijndu-se coerena datelor.15

Cele mai cunoscute metode ierarhice sunt: SADT (Structurated Analysis and Design Technique), JSD (Jackson System Development, Yourdon. Metodele sistemice reprezint cea de-a doua generaie a metodelor de analiz i proiectare a sistemelor informatice. Bazndu-se pe teoria general a sistemelor, n cadrul acestor metode datele i prelucrrile asupra datelor sunt modelate i studiate independent. mpreun formeaz un sistem. Axndu-se pe conceptul de baz de date, care ofer coeren i elimin redundanele, metodele sistemice acord prioritate datelor fa de prelucrri. Dezavantajele acestor metode rezult din existena deficienelor n modelarea prelucrrilor, n prezena unor discordane ntre modelele datelor i cele ale prelucrrilor. Metodele sistemice respect cele trei nivele de abstractizare introduse prin metodologia ANSI/SPARC: conceptual, logic i fizic. Principalele metode sistemice sunt: MERISE, AXIAL, Information Engineering. Metodele orientate obiect reprezint cea de-a treia generaie, utilizate astzi n cazul sistemelor cu comportament dinamic, dependent de timp. Se definesc entiti de sine stttoare, n care sunt ncapsulate date (proprieti) i prelucrri (operaii). Avantajul acestor metode rezult din faptul c ofer posibilitatea reutilizrii componentelor. Existnd o integrare mult mai bun a datelor cu prelucrrile, aduc o rezolvare coerent a aspectelor dinamice. Dezavantajul este ns c nu ntotdeauna modelarea corespunde realitii reprezentate. Cele mai utilizate metode sunt: Object Modeling Technologie (OMT), Object Oriented Design (OOD). Succesul utilizrii metodelor orientate obiect a determinat definirea unui limbaj standard de modelare, Unified Modeling Language.

16

TESTE FINALE1 Care din afirmaiile urmtoare este adevrat ? a) Sistemul informaional este reprezentat de totalitatea metodelor, procedurilor i mijloacelor folosite n procesul informaional. b) Sistemul informatic se definete ca un ansamblu organizat i integrat de operaii de culegere, transmitere, prelucrare, sistematizare, analiz i pstrare,difuzare i valorificare a informaiilor. c) Decizia este o informaie de comand pentru sistemul de conducere. 2 Care din afirmaiile urmtoare este adevrat ? a) Internet-ul este o reea local care permite comunicarea ntr-un grup nchis de utilizatori care se raporteaz i construiesc o baz comun de informaii. b) Intranet-ul este o reea local care permite comunicarea ntr-un grup nchis de utilizatori care se raporteaz i construiesc o baz comun de informaii. c) Intranet-ul este o aplicaie special care permite altor organizaii i persoane accesul la informaia difuzat pe Intranet. 3 Care din afirmaiile urmtoare este adevrat ? a) Sistemul informatic integrat este un ansamblu structurat i corelat de proceduri i echipamente electronice de calcul care permit culegerea, transmiterea i prelucrarea datelor, obinerea de informaii. b) Sistemele informaionale sunt caracterizate prin aplicarea principiului introducerii unice a datelor i prelucrrii multiple a acestora n concordan cu cerinele informaionale specifice fiecrui utilizator. c) Funcia unui sistem informatic este de a prelucra datele n vederea obinerii informaiilor necesare unei desfurri normale a activitilor ntr-o firm. 4 Care din afirmaiile urmtoare nu este adevrat ? a) Strategia descendent pornete de la principiul descompunerii sistemului informatic complex n componente mai simple prin parcurgerea unor nivele succesive de detaliere.

17

b) Strategia ascendent pornete de la principiul descompunerii sistemului informatic complex n componente mai simple prin parcurgerea unor nivele succesive de detaliere. c) n cadrul strategiei descendente se definete o structur ierarhic-modular n care fiecare component ndeplinete o anumit funcie. 5 Care din afirmaiile urmtoare nu este adevrat ? a) Strategia ascendent presupune proiectarea i realizarea componentelor viitorului sistem informaional, fr a avea o imagine de ansamblu asupra ntregului sistem informaional. b) n cadrul strategiilor ascendente se trateaz separat fiecare component a sistemului, stabilirea corelaiilor ntre componente i integrarea lor n sistemul privit ca un tot unitar urmnd a se face ulterior. c) Strategia descendent presupune proiectarea i realizarea componentelor viitorului sistem informaional, fr a avea o imagine de ansamblu asupra ntregului sistem informaional. 6 Care din afirmaiile urmtoare nu este adevrat ? a) Ciclul de via al unui sistem informatic se definete ca fiind perioada de timp cuprins ntre momentul iniierii acestuia i momentul scoaterii lui din funciune. b) Ordinea i felul n care se parcurg etapele ciclului de via se regsete n literatura de specialitate sub numele de modele ale ciclului de via al dezvoltrii sistemelor. c) Un model al ciclului de via specific activitile ce trebuie efectuate pentru conceperea sistemului. 7 Care din afirmaiile urmtoare este adevrat ? a) n cazul metodelor ierarhice se definete o ierarhie a funciilor pn se ajunge la componente suficient de mici astfel nct s fie programate cu uurin. b) Metode orientate-obiect acord prioritate datelor n raport cu prelucrrile. c) n cazul metodelor orientate-date sistemele reale sunt mprite n entiti de sine stttoare, care nglobeaz proprieti i comportament.

18

8 Care din afirmaiile urmtoare este adevrat ? a) n cadrul metodelor sistemice datele i prelucrrile asupra datelor sunt modelate i studiate independent. b) Dezavantajele metodelor ierarhice rezult din existena deficienelor n modelarea prelucrrilor, n prezena unor discordane ntre modelele datelor i cele ale prelucrrilor. c) Metodele sistemice sunt utilizate n cazul sistemelor cu comportament dinamic, dependent de timp. 9 Care din afirmaiile urmtoare este adevrat ? a) Avantajul metodelor sistemice rezult din faptul c ofer posibilitatea reutilizrii componentelor. b) Avantajul metodelor orientate-obiect rezult din faptul c ofer posibilitatea reutilizrii componentelor c) Dezavantajele metodelor orientate-obiect rezult din existena deficienelor n modelarea prelucrrilor. 10 Care din afirmaiile urmtoare este adevrat ? a) Proiectarea sistemelor informatice desemneaz activitatea complex de dezvoltare de sisteme informatice i nu una din etapele n care sunt grupate activitile desfurate pentru realizarea unui sistem informatic. b) Modelul ciclului de via al unui sistem informatic specific activitile ce trebuie efectuate pentru conceperea sistemului, ordinea n care se execut i modul lor de corelare. c) Metoda de proiectare a unui sistem informatic specific activitile ce trebuie efectuate pentru conceperea sistemului, ordinea n care se execut i modul lor de corelare. Rezolvare 1-a 2-b 7-a 8-a

3-c 9-b

4-b 10-c

5-c

6-c

19

CAPITOLUL II - METODE SISTEMICEDintre metodele sistemice, cea mai reprezentativ este metoda Merise, aplicat pentru prima dat n 1979 n Frana. Perfecionat continuu, este utilizat i astzi cu prioritate n informatica de gestiune. Este motivul pentru care, n lucrarea de fa, principalele particulariti ale metodelor sistemice sunt prezentate prin prisma acestei metode.

2.1 Nivele de descrieren Merise vers OMT et UML ([GJ99]), prezentnd descrierea sistemului de la abstract la concret, autorii grupeaz nivelele de abstractizare n dou mari clase. ntr-o prim clas, nivelul conceptual i nivelul organizaional, corespund descrierii sistemului informatic independent de soluia informatic. Nivelul logic i nivelul fizic constituie a doua clas, n care este luat n calcul soluia informatic aleas. Nivelul conceptual urmrete obinerea unei reprezentri fidele a realitii, fcnd abstracie de restriciile informatice sau organizatorice. Surprinde cu ajutorul unor abstracii aspectul static i dinamica n timp a activitii desfurate. Nivelul organizaional leag funcionalitatea sistemului de organizarea firmei i de postul de lucru. Executate n timp real sau nu, procedurile manipuleaz date din diferite compartimente funcionale. La acest nivel, procedurile sunt descompuse n faze executate pe posturi de lucru. Nivelul logic vizeaz alegerea soluiei informatice pentru culegerea datelor i furnizarea informaiei. Procedurile sunt detaliate la nivel de module, a cror descriere logic implic i datele incluse ntr-un sistem relaional. Nivelul fizic este nivelul concret la care sunt definite mijloacele tehnice de realizare efectiv a sistemului.

20

Cele patru nivele presupun construirea unor modele separate pentru date i prelucrri, constituind mpreun ciclul de abstractizare al sistemului informatic.

2.2 Modele pentru date i prelucrriPentru fiecare nivel exist un model al datelor i un model al prelucrrilor. Nivelului conceptual i sunt asociate modele rezultate din analiza sistemului real. Se regsesc n documentele redactate n urma proiectrii generale. Modelul Conceptual al Datelor (MCP) definete structura global de organizare a datelor, asigurnd independen total fa de orice sistem de gestiune a bazelor de date. Acordnd prioritate datelor, pentru reprezentarea lor folosete un formalism precis, normalizat pe plan internaional de ISO (International Standard Organization) sub numele de model Entitate Asociere. Este realizat cu ajutorul conceptelor de entitate (obiect), relaie, proprieti, proprii formalismului Entitate-Asociere. Modelul Conceptual al Prelucrrilor (MCP) descrie latura dinamic a sistemului, evideniind nlnuirea operaiilor i condiiile declanrii acestora. Utilizeaz conceptele de proces, operaie i eveniment. La nivel organizaional modelele definite apropie concepia de ansamblu a sistemului de structura organizatoric. Utiliznd un formalism identic cu cel al modelelor conceptuale, se definesc modele separate pentru date i prelucrri. Modelul Organizaional al Datelor se construiete n cazul sistemelor informatice complexe, n care datele sunt distribuite pe diferite nivele organizatorice. El prezint mulimea datelor grupate pe uniti organizatorice. Existena tehnologiilor client-server au crescut importana distinciei ntre datele culese i valorificate la nivelul staiilor de lucru i datele gestionate de server. Modelul Organizaional al Prelucrrilor (MOP) se construiete n situaiile n care operaiile definite la nivel conceptual sunt executate n

21

diferite compartimente funcionale. Prezint procedurile descompuse n faze i sarcini corespunztoare posturilor de lucru. Modelele logice fixeaz o soluie direct implementabil, stabilesc realizarea efectiv a sistemului informatic cu o baz de date relational i un sistem de gestiune a bazelor de date corespunztor, sau cu ajutorul fiierelor de date exploatate cu limbaje procedurale. n cazul informaticii de gestiune, demersul metodologic conduce la implementare cu ajutorul bazelor de date relaionale, datele fiind nmagazinate n structuri stabile (tabele) i manipulate cu un Sistem de Gestiune a Bazelor de Date performant. Modelul Logic al Datelor (MLD) se obine conform standardelor Modelului Relaional al Datelor. n cazul prelucrrilor, pentru c nu exist o normalizare a descrierii logice a prelucrrilor, nu exist un Modelul Logic al Prelucrrilor ci o Descriere Logic a Prelucrrilor (DLP). La nivel fizic sunt specificate efectiv modalitile de realizare a soluiei informatice alese. Ne existnd un standard pentru definirea modelelor fizice de date i prelucrri, acest nivel este reflectat n Descrierea Fizic a Datelor (DFD) i respectiv n Descrierea Fizic a Prelucrrilor (DFP). Descrierea fizic a datelor este legat de sistemul de gestiune al bazelor de date ales pentru crearea bazei de date. Evideniaz modul n care datele vor fi stocate i accesate la nivelul memoriei externe, sistemele care asigur securitatea pstrrii i regsirii datelor. Descrierea fizic a prelucrrilor presupune realizarea soluiei stabilite n cadrul modelului logic al prelucrrilor, apelnd la un anumit sistem de gestiune a bazelor de date.

2.3 Modelarea conceptual i organizaional a datelorn aceast etap, cnd nu se pune problema unei soluii informatice, conceptele sunt abstracii ce reprezint lumea real ca o colecie de entiti i de legturi ntre acestea.

22

Construirea Modelului Conceptual al Datelor este primul pas n reprezentarea sistemelor reale n care se vehiculeaz un volum mare de date. Modelul Conceptual al Datelor este un mijloc de comunicare ntre modelator (proiectantul sistemului informatic) i viitorul utilizator al sistemului. mpreun stabilesc obiectele lumii reale i propriettile lor, mpreun cuantific restriciile impuse de condiiile concrete ale desfsurrii activittii sub forma simpl a unor reguli de gestiune. n cazul n care exist mai multe compartimente funcionale, cnd datele sunt culese, prelucrate sau utilizate n posturi de lucru diferite, Modelul Conceptual al Datelor se detaliaz conform structurii organizatorice. Se obine astfel Modelul Organizaional al Datelor. La ora actual, cnd majoritate firmelor beneficiaz de tehnic de calcul performant, de reele Intranet, construirea modelului organizaional al datelor presupune: repartizarea datelor pe compartimente funcionale; asigurarea vizibilitii datelor pe diferite nivele organizatorice; stabilirea drepturilor de acces la date conform unui protocol determinat de arhitectura sau de topologia reelei existente; stabilirea volumului de date active, a volumului i a condiiilor de arhivare pentru datele pasive.

2.3.1 Modelul Entitate-Asociere Aa cum am mai afirmat, modelarea conceptual i organizaional a datelor se face pe baza formalismului modelului EntitateAsociere. Principalele concepte sunt: entitate, asociere, atribut. Modelul Entitate-Asociere prezint lumea real ca o colecie de clase i de legturi de diferite tipuri ntre ele. Fiind reprezentarea unui sistem real, n model trebuie evideniate i modul n care realizrile fiecrei entiti sunt implicate ntr-o asociere, numrul entitilor care particip la o asociere. Vorbim astfel de cardinalitatea cuplului Entitate-Asociere, de tipul de asociere i de dimensiunea unei asocieri.

23

2.3.1.2 Caracteristici entitate ENTITATEA (E) este o reprezentare conceptual a unui obiect sau fenomen din sistemul real. Are existen proprie i este conform cu regulile de gestiune ale firmei. n activitatea de modelare nu intereseaz obiectele individuale, ci clasele n care ele pot fi grupate n funcie de caracteristici comune. Existena unei entiti este subordonat apartenenei la o clas, numele clasei fiind folosit pentru a referi elementele unei clase. Componentele individuale sunt numite instane (realizri) ale claselor. ntre instan i clasa sa se stabilete astfel, prin grupul verbal ,,este membru n, o relaie. Exemple: FURNIZORI, este o clas ce definete mulimea persoanelor fizice/juridice de la care s-a cumprat sau s-a comandat cel puin un articol. 4011-Remex este membru n clasa ,, FURNIZOR CLIENI, este o clas ce definete mulimea persoanelor fizice/juridice care au comandat sau au cumprat cel puin un produs. 4112-Amis este membru n clasa CLIENI PRODUSE, este o clas ce definete mulimea bunurilor materiale cuprinse n catalogul de vnzri al firmei. calculator este membru n clasa PRODUSE Prin abuz de limbaj, n multe din lucrrile ce vizeaz modelarea conceptual se folosete termenul de entitate n locul celui de clas de entiti. Convenim ca i n lucrarea de fa s acceptm c o entitate este o clas generic de obiecte avnd aceleai caracteristici pentru un modelator plasat ntr-un context dat. n toate aceste situaii, entitatea este reprezentat cu ajutorul unui dreptunghi n care este scris numele entitii i proprietile ei. asociere ASOCIEREA (A) ntre entiti exprim o legtur existent sau posibil ntre obiecte individuale. Clasele de asocieri sunt asocieri ntre clasele de obiecte individuale.24

Respectnd convenia stabilit la definirea entitii, vom spune c o asociere este o clas generic de legturi recunoscute sau posibile ntre obiecte aparinnd entitilor din sistem. n cadrul modelului conceptual al datelor, asocierea este reprezentat printr-o elips care face legtura ntre entitile participante la asociere.

Exemple:

FURNIZORI

furnizeaz

MATERII PRIME

atribut ATRIBUTUL definete o proprietate distinct a unei entiti sau a unei asocieri. Un atribut este considerat o mulime de valori posibile. Identitatea unei entiti este exprimat printr-un atribut sau un grup minimal de atribute care permit identificarea unic a realizrilor ei. Altfel spus, fiecare entitate posed un identificator, sau o cheie a entitii. Pentru o entitate pot exista mai multe atribute care s serveasc drept cheie. Acestea se numesc chei candidate. Selectarea se face n funcie de necesitile impuse de context, cheia principal putnd fi format din unul sau mai multe atribute. Atributele cheie se marcheaz prin subliniere sau printr-o sgeat spre entitatea creia i aparin i ale cror instane le identific. Celelalte atribute, care exprim caracteristicile entitii sunt i ele specificate n cadrul entitii. Fiecare realizare a unei entiti posed valori proprii pentru atribute. Exemplu: Pentru entitatea Furnizor, codul fiscal sau denumirea pot fi considerate chei candidate. De cele mai multe ori, codul fiscal este ales cheie primar.

25

Entitatea FURNIZORI are ca atribute: CodFurnizor, Nume, Localitate; se reprezint astfel: FURNIZORI CodFurnizor Nume Localitate O asociere poate avea atribute proprii. Atributele asocierii se specific n elipsa ce cuprinde numele asocierii (CantitateCumprat). CLIENI cumpr CantitateCumprat PRODUSE

Atributele pot fi clasificate n funcie de mai multe criterii: 1. dup realizrile pe care le pot prezenta atribute cu realizri obligatorii, pentru care la momentul definirii se specific NOT NULL. Exemplu: CodFurnizor, MaracSalariat. atribute opionale, care pot s nu prezinte realizri n cazul unor entiti. Exemplu: adresa_e-mail a furnizorului, nr_telefon pentru angajai. atribute monovaloare, care prezint o singur valoare n cadrul unei entiti. Exemplu: NumeClient, CantitateLivrat. atribute multivaloare, care prezint mai multe valori n cadrul aceleiai entiti. Exemplu: n cazul n care o persoan cunoate mai multe limbi strine ce trebuie evideniate, atributul LimbStrin este un atribut multivaloare; atributul numele autorului este atribut multivaloare n cazul n care o carte are mai muli autori. 2. dup complexitatea atributelor atribute elementare, cu realizri atomice. Exemplu: MarcSalariat, NumrMatricol, PreUnitar.

26

atribute decompozabile, ale cror realizri sunt formate dintr-un grup de valori de tipuri diferite, care pot fi descompuse n realizri atomice. Exemplu: atributele ce definesc Adresa sau DataCalendaristic. Dintre atributele ce caracterizeaz entitile definite n modelele sistemelor informatice economice, o atenie deosebit trebuie acordat factorului timp, care apare sub forma datei calendaristice. Raportate la acest atribut, entitile pot fi grupate n entiti permanente (CLIENI, PRODUSE, CREDITE) i entiti eveniment, ce evideniaz schimbri, modificri, produse la un moment dat (COMENZI, FACTURI, PLI). Acestea din urm, pe lng atributele ce le identific unic, posed un atribut care specific data producerii lor (DataComenzii, DataFacturii, DataPlii.). cardinalitate Cardinalitatea d informaii despre numrul minim i numrul maxim de apariii ale unei asocieri A ntre o entitate E1 i o alta E2. Referind entitatea, (mulimea legat prin aplicaie), i asocierea, (aplicaia mulimii n alt mulime), se vorbete de cardinalitatea cuplului Entitate-Asociere (EA). Se definete ca un cuplu de ntregi (x,y), unde: x reprezint numrul minim de legturi ce pot exista pentru o realizare dat a entitii. y reprezint numrul maxim de legturi ce pot exista pentru o realizare dat a entitii . Pentru cardinaliti, valorile semnificative utilizate n activitatea de modelare sunt fie 0 i 1 pentru cardinalitatea minimal, fie 1 i n pentru cardinalitatea maximal. Se evit astfel schimbarea modelului pe msura ce se dezvolt relaia ntre dou entiti: Dac la momentul modelrii potenial exist o legtur ntre realizrile a dou entiti, aceasta este reprezentat prin valoarea 0 a cardinalitii minimale. Situaiile n care pot exista mai multe legturi pentru o realizare dat a unei entiti sunt reprezentate de la nceput prin valoarea n a cardinalitii maximale. Se evit astfel schimbarea modelului pe msura ce se dezvolt relaia ntre dou entiti.

27

Cardinalitatea minimal 0 precizeaz realizri de entiti care nu particip efectiv la asociere. Exemplu: Produsele obinute n activitatea de producie pot fi stocate n depozit sau pot face obiectul vnzrii, fiind nscrise pe dispoziii de livrare. Altfel spus, un produs se poate afla sau nu pe o dispoziie de livrare (cardinalitatea minimal 0).

DISPOZIIE LIVRARE

se ntocmete

0,n

PRODUS

Cardinalitate minimal 1 este n cazul n care toate realizrile entitii particip la o realizare a asocierii; Cardinalitatea maximal 1 definete situaia n care realizrile entitii care particip la asociere nu se pot modifica, n care legtura exprimat de asociere nu se poate modifica; Exemplu: n activitatea de aprovizionare cu mrfuri, factura care nsoete marfa conine datele furnizorului. Nu exist factur care s nu aib un emitent (cardinalitate minimal 1). n acelai timp, pentru o factura nu pot exista mai muli furnizori cardinalitatea maximal 1). FACTUR 1,1 corespunde FURNIZOR

cardinalitate maximal n se declar dac numrul maxim de apariii ale unei asocieri nu este restricionat de condiii suplimentare, cnd o simpl descriere de stare poate deveni restricie de cardinalitate. Exemplu: n aprovizionarea cu mrfuri, de la un furnizor se pot primi mai multe facturi. Numrul lor fiind nedefinit, se consider cardinalitatea maximal n.

28

FACTUR

corespunde

1,n

FURNIZOR

tip de asociere O asociere poate lega ntre ele dou sau mai multe entiti. Tipul de asociere este cuplul determinat de numrul de instane de entiti care pot fi asociate de o parte i de cealalt a asocierii. Pentru asocierile binare, tipurile de asociere se stabilesc pornind de la cardinaliti, pe baza urmtoarei reguli. Fie A o asociere binar legnd dou entiti E1 i E2. Fie (x1,y1) i respectiv (x2,y2) cardinalitile cuplului (E1,A) i (E2,A). dac y1=y2=1, atunci A este de tip 1:1 dac y1>1 i y2=1 sau y1=1 i y2>1 atunci A este de tip 1:n dac y1>1 i y2>1 atunci A este de tip n:m Exist trei tipuri de asocieri. Asocierea de tip ,,unu la unu este asocierea n care unei realizri a entitii E1 poate s-i corespund prin asocierea A cel mult o realizare a entitii E2, i reciproc, unei realizri din E2 nu poate s-i corespund dect cel mult o realizare din entitatea E1. Asocierea de tip ,,unu la muli este asocierea n care unei realizri a entitii E1 pot s-i corespund prin asocierea A mai multe realizri ale entitii E2, dar unei realizri din E2 i corespunde cel mult o realizare din E1. Acest tip de asociere se mai numete i asociere de ierarhizare, subordonarea prin ierarhie putnd fi reprezentat grafic printr-o arborescent. Asocierea de tip ,,muli la muli este asocierea n care unei realizri a entitii E1 pot s-i corespund prin asocierea A mai multe realizri din E2, i reciproc. n practic, aceast asociere se descompune n asocieri de tipul ,,unu la multi, prin introducerea unei entiti intermediare.

29

dimensiune Numrul de entiti care particip la o asociere formeaz dimensiunea (gradul) acesteia. Asocierile pot fi unare (fig. 2.1.a), binare (fig. 2.1.b) i ternare (fig. 2.1.c) PRODUS CodProdus DenProdus Gabarit DataOmologrii

0,1

0,1

este_format NrComponente fig. 2.1. a

FURNIZOR

furnizeaz

MATERII PRIME

fig. 2.1.b CONTRIBUABIL CodCntribuabil Nume DOCPLAT NrDoc DataDocument

pltete

TAXE TipTax sum fig. 2.1.c

30

2.3.1.2 Construirea modelului conceptual al datelor Modelarea este un proces complex i subiectiv, astfel c soluia aleas este ntotdeauna o variant perfectibil, imaginea modului n care modelatorul nelege realitatea. Metoda Merise propune n definirea modelului conceptual al datelor dou tehnici pentru definirea entitilor i a relaiilor: modelarea prin entiti (modelarea direct) i modelarea prin atribute. Entitile i asocierile sunt principalele componente ale modelului conceptual al datelor. Dup stabilirea lor conform uneia din tehnicile de modelare aleas, modelul este completat cu restriciile ce-i asigur corectitudinea n raport cu sistemul real. 1 modelare prin entiti n cadrul acestei tehnici, entitile i relaiile sunt identificate direct din rezultatele etapei de proiectare general, exprimate ntr-un limbaj simplu, comun modelatorilor (Univers du discours). Pentru fiecare entitate se determin identificatorul i celelalte atribute. Cardinalitile i restriciile se deduc n continuare din context. PRACTIC, sunt formulate n limbaj simplu, comun, faptele i evenimentele aprute. Substantivele vor da natere la entiti i verbele la relaii. Exemplu : n cadrul activitii de aprovizionare, facturile sunt emise de furnizori. Facturile conin mrfuri. Entitile i asocierile sunt:

emise

FACTURI

conin cantitate

MRFURI

FURNIZORI

31

2 modelarea prin atribute n cadrul acestei tehnici se examineaz atributele (proprieti exprimate prin valori) din documentele primare ce conin datele de intrare n sistem, se identific dependenele funcionale dintre ele i se decide cea mai bun cale de a le combina. Din descrierea activitii desfurate se stabilesc asocieri ntre entiti, se evideniaz modul de implicare al entitilor n asocieri. PRACTIC se parcurg mai multe etape, pe care le prezentm n continuare nsoite de exemple din sistemul informatic privind acordarea unui credit pentru o firm: 1 se structureaz sub forma simpl a unor reguli de gestiune rezultatele fazei de proiectare general. Exemplu: pentru a obine un credit, o firm trebuie s depun la banc o informare privind situaia ei financiar. Aceast situaie conine, printre altele, valoarea capitalului social i profitul ultimului an. decizia de acordare a creditului este urmat de ntocmirea unui dosar de credit, care conine informaii privind suma acordat, termenul i dobnda corespunztoare creditului. O firm, devenit client al bancii, are pentru fiecare credit acordat un dosar de credit. pentru creditul acordat, se deschide i se actualizeaz la fiecare rat pltit de client, o fi de credit. ratele sunt pltite cu documente care, pe lng propriile date de identificare, conin suma pltit 2 se alctuiete un tabel al atributelor coninute n documentele primare . Exemplu: DOSAR CEDIT : Numr dosar, Data ntocmirii dosarului, Termenul final al creditului, Suma acordat, Dobnda calculat FIA CREDIT : Numr fi, Suma total ncasat, Dobnda, Penaliti

32

DOCUMENT PLAT : Tip document, Numr document, Data document, Suma pltit 3 se construiete dicionarul atributelor, prin eliminarea atributelor calculate i a atributelor sinonime. Se adaug atribute necesare codificrii interne a firmei. Exemplu: Nr.Crt 1 2 3 4 5 6 7 8 9 ATRIBUT CodClient DenumireClient AdresaClient CapitalSocial ProfitUltimulAn TipDocument NumrDocument DataDocument SumaDocument Nr.Crt 10 11 12 13 14 15 16 17 18 ATRIBUT NumarDosar DataDosar TermenFinal SumaCredit DobindaCredit NumrFi Sumancasat Dobnda Penaliti

4 se stabilesc dependenele funcionale ntre atribute i se construiete matricea simplificat a dependenelor funcionale n care: . liniile sunt reprezentate de determinanii dependenelor funcionale . n coloane se nscriu atributele determinate (celelalte atribute din dicionarul atributelor) . n matrice se nscrie cifra 0 la intersecia determinantului (linie) cu atributul determinat (coloan) Exemplu: 1 2 13 14 15 6+7 9 10 11 10 12 10 13 15 16 1517 15 18

6+7 1014

8

33

Matricea simplificat a dependentelor funcionale este: 2 0 3 0 4 0 5 0 8 0 9 0 0 0 0 0 0 0 0 11 12 13 14 16 17 18

1 6+7 10 15

5 se creaz entiti distincte ce conin cte un determinant i atributele determinate de el. n entiti nu se includ atributele care au doi determinani (atributele cu dou cifre 0 pe coloan). Atributele determinant constituie cheile entitilor construite. 6 se stabilesc asocierile i cardinalitile pe baza regulilor de gestiune i a dicionarului atributelor. Atributele care au doi determinani, sunt atribute ale asocierii dintre entitile ale cror identificatori sunt detrminanii respectivi. Entitile, asocierile i cardinalitile sunt cele din figura 2.2.

34

CLIENT CodClientDenumireClient AdresaClient

1,n

1,1 corespun d

DOSAR CREDIT NrDosarDatDosar TermenFinal SumCredit DobndCredit

1,1 1,1are

aparine 1,1 1,1 FI CREDIT NrFi Sumancasat Dobnd Penaliti

SITUAIE FINANCIAR CodClient CapitalSocial ProfitUltimAn

1,n actualizeaz 1,1 RATE TipDocument NrDocument DataDocument SumaPCredit SumaPDobnda

fig.2.2

35

Observaii: 1 Am optat pentru entiti distincte CLIENT i SITUATIE FINANCIARA, pentru faptul c atributele grupate n a doua entitate sunt analizate mpreun n perspectiva acordrii unui credit. 2 Entitatea FISA CREDIT conine cmpuri calculate: Suma Incasat, Dobnda, Penaliti, ceea ce contravine cerinei conform creia n Modelul Conceptual de Date nu sunt incluse cmpuri calculate. S-a optat totui pentru aceast soluie, deoarece fia creditului deschis imediat dup aprobarea creditului se utilizeaz permanent n urmrirea rambursrii creditului, i e preferabil s consultm un tebel cu datele actualizate la zi n locul execuiei repetate a procedurilor ce calculeaz valoarea acestor cmpuri. n baza de date se creaz un tabel corespunztor entitii FISA CREDIT, cu valoarea 0 n aceste cmpuri. Valorile corespunztoare sumelor ncasate, dobnzii i penalitilor nu se ncarc de ctre operatori, ci se actualizeaz pin proceduri scrise special. 2.3.1.3 Verificare. Normalizare. Descompunere Indiferent de tehnica de modelare, asupra modelului se aplic operaiile de verificare, normalizare i descompunere: verificarea presupune asigurarea c:

1. numele elementelor ce apar n modelul conceptual al datelor sunt unice. 2. identificatorii compui dintr-un grup de atribute trebuie s nu conin un subgrup n interiorul acestora care s poat fi folosit ca identificator. 3. o asociere nu poate exista dect o singur dat ntre aceleai entiti. Dac apar mai multe asocieri, soluia este transformarea asocierii ntr-o nou entitate. 4. atributele derivate, cele ale cror valori se obin din calcule, nu apar n modelul conceptual al datelor. (excepie fac situaiile n care acestea prezint o semnificaie particular pentru problema studiat, fcnd parte din restricii de integritate).36

normalizarea este un proces care asigur: eliminarea redundanelor fr pierdere de informaie; eliminarea anomaliilor n procesul de actualizare. n cazul entitilor, normalizarea permite asigurarea c nu exist atribute repetitive sau compuse ntr-o entitate. Exemplu: n sistemul informatic privind aprovizionarea cu mrfuri, pentru fiecare furnizor exist un atribut care conine informaii despre obiectul aprovizionrii (tipul de marf, denumirea, cantitatea aprovizionat) FURNIZOR CodFiscal Nume Marfa

Normalizarea impune definirea unei noi entiti, MARFA, i a unei asocieri aduce , cu atributul cantAprov (canitate aprovizionat) FURNIZOR CodFurnizor 1,n Nume aduce cantAprov MARFA 0,n CodMarfa DenMarfa

n cazul asocierilor, normalizarea permite asigurarea c atributele unei asocieri depind n totalitate de identificatorii entitilor participante. Exemplu: FACTURI NrFacturaData

0,n

conin cantitatepre

0,n

MATERIALE CodMaterialDenumire

De asemenea n exemplul anterior, cantAprov este atribut care depinde de ambele entiti. El apare ca atribut al asocierii.

37

descompunerea permite definirea, fr pierdere de informaie, a mai multor relaii de dimensiune doi dintr-o relaie de dimensiune mai mare. Descompunerea se bazeaz pe dependene funcionale i este posibil n urmtoarele condiii: exist cel puin o dependen funcional ntre roluri; exist o cardinalitatea 0,1 sau 1,1, toate celelalte fiind 0,n sau 1,n. Descompunerea se face n dou asocieri, una exprimnd raportul determinant -- determinat, iar cealalt prelund restul asocierii iniiale. Exemplu: n cazul: CONTRIBUABIL CodContribuabil 1,n Nume Adres DOC PLAT 1,1 NrDoc DataDocument

pltete 0,n TAXE TipTax Sum

descompunerea este: CONTRIBUABILCodContribuabil Nume Adres 1,n pltete 1,1

DOC PLATNrDoc DataDocument

1,1 TAXE TipTax Sum

1,n

corespund

38

2.3.1.4 Restricii Pe lng definirea entitilor i asocierilor, n modelul EntitateAsociere trebuie luate n calcul cerine ce asigur corectitudine i coeren n raport de realitatea pe care modelul o reflect. n general sunt restricii ce privesc domeniul de definiie al atributelor sau evoluia lor n timp. Restriciile de integritate sunt reguli suplimentare, nereprezentate direct n modelul conceptual al datelor, dar care trebuie respectate permanent de date. ntr-o prim clasificare, restriciile de integritate se mpart n dou mari grupe: restrictii statice (se verific permanent), i restricii dinamice (privesc evoluia n timp a datelor). Exemple : restricii statice: . DataOmologrii unui produs obinut n seciile de producie proprii este ntotdeauna anterioar datei documentului cu care produsul este vndut (DataDoc) . cota_tva=19% . restricii dinamice: . o persoan poate s-i completeze studiile i implicit s-i schimbe ocupaia. Dac n entitatea PERSOANE se specific atributul Ocupaie, acesta poate lua n timp diferite valori . pentru entitatea CITITOR, dac specificm atributul CategorieCititor, acesta poate lua valorile: student, cadru didactic, doctorand. Intr-o alt clasificare, restriciile pot fi grupate n restrictii structurale i restricii semantice. Restriciile de integritate structurale se refer la: integritatea entitilor, viznd faptul c fiecare entitate trebuie identificat n mod unic; integritatea referenial, viznd faptul c pentru orice realizare a unei asocieri este obligatoriu s existe realizri pentru entitile participante; cardinaliti, viznd respectarea condiiilor n cazul cardinalitilor minimale i maximale.39

Restriciile de integritate semantice sunt introduse de utilizator pentru a reflecta corect realitatea. Sunt expresia regulilor de gestiune aplicate n firm, consecin a reglementrilor legislative i normative n vigoare, a regulamentelor i normelor interne. Aceste restricii nu apar explicit n modelul conceptual al datelor, fiind implementate n procesul crerii relaiilor aparinnd bazei de date. Ele pot implica: 1 valorile pe care le pot lua atributele entitilor i asocierilor; Domeniul, ca mulime de valori pentru atribute, poate fi definit printr-o proprietate sau prin enumerarea valorilor posibile. Restriciile de domeniu sunt condiii care privesc ansamblul de valori acceptate pentru un atribut n cadrul tipului sau domeniului su. Ele pot viza: coninutul unui singur atribut al unei entiti sau asocieri Exemplu( fig.2.3) : um = {kg,buc,m} cota_tva = 19% produsul cel mai vechi din catalog a fost omologat n 12.12.96; corelaii ntre valorile mai multor atribute ale aceleiai entiti sau asocieri Exemplu (fig.2.3) : n codificare, gestiunea poate lua valori n mulimea M, unde M={ 01,12,22}. n gestiunea cu codul 01, se stocheaz doar produsele care au codurile specificate n mulimea {1000,1001,1104} corelaii ntre atributele mai multor entiti sau asocieri diferite Exemplu(fig.2.3) : n cazul unui produs obinut n seciile proprii de producie i depozitat ntr-o gestiune, data stoc > data omologrii n cazul nregistrrii oricrui document primar, data_document trebuie s fie anterioar datei curente corelaii cu valori obinute pe baza unor operaii de sintetizare (nsumare,medie) a unui ansamblu de entiti Exemplu(fig.2.3) :40

suma cantitii livrate pentru un produs nu poate depi stocul de la o anumit dat. DISPLIVRARE PRODUS NrDoc privete CodProdus DataDoc 1,n cant_livrat 0,n DenProdus NrContr DataOmologarii CotaTva 1,n 1,1 modific stabilesc 1,n data_stoc STOC 1,1 CodGestiune Stoc

fig. 2.3

asocierile stabilite ntre entiti. Restriciile de integritate ce vizeaz asocierile dintre entiti, pot determina relaii de incluziune, egalitate sau excluziune ntre asocieri. Incluziunea relaiilor Exemplu: Pentru a fi livrat, orice marf trebuie s fie facturat. Acest fapt determin o relaie de incluziune ntre asocierile facturare i livrare. 2 livrare dataL 1,1 I 0,1 facturare d ataF 1,1 0,n

MARF CodMarf

CLIENT CodClient

41

Excluziunea relaiilor Exemplu: Avnd n vedere c un acelai produs nu poate fi vndut i donat n acelai timp, ntre asocierile vnzare i donare exist o relaie de excluziune. 0,n PRODUS CodProd Denumire 0,n vndut # donat obinut donare 1,1 vnzare 1,1 cumprat

CLIENT CodClient Nume Adres

Egalitatea relaiilor Exemplu: Admitnd c depozitarea n gestiune se face concomitent cu nscrierea n fia de magazie, ntre asocierile depozitare i nscriereFm exist o relaie de egalitate.

depozitare MATERIAL CodMat Nume 1,n = 1,n nscriereFm 1,n 1,n GESTIUNE CodGest Nume

2.4 Modelarea logic i fizic a datelorModelarea logic depinde de particularitile datelor vehiculate i de posibilitile oferite de tehnica de calcul a momentului. n [GJ99] se afirm chiar c expresia Modelului Conceptual al Datelor n termenii unuianumit tip de soluie informatic constituie Modelul Logic al Datelor.42

Prin modelarea logic se urmresc trei obiective[OD99]: 1. structurarea performant a datelor prin procesul de normalizare. 2. realizarea unui model al datelor care rspunde cerinelor impuse de formularele i documentele prin care se preiau datele de la utilizator (perspectiva sistemului prin prisma utilizatorului). 3. obinerea unui model logic al datelor din care s se poat realiza proiectul bazei de date fizice. n cazul sistemelor informatice ce vizeaz activitatea economic, volumul mare de date cu care se vehiculeaz este caraterizat printr-o organizare uniform, constituit din tipuri de nregistrri cu caracteristici asemntoare, determinate de structura documentelor primare. Operaiile de prelucrare automat au un caracter repetitiv i o frecven mare de executare. Operatorii sunt simplii i execut n majoritatea cazurilor prelucrri succesive asupra caracteristicilor de acelai tip. Aceste observaii au condus la alegerea sistemelor relaionale drept soluie direct implementabil . Fa de metodele tradiionale care utilizau fiiere strict dependente de aplicaii, bazele de date relaionale i sistemele de gestiune corespunztoare prezint cteva avantaje care le-au impus n aplicaiile de gestiune. Dintre acestea amintim: redundan minim i controlat a datelor; integritate i accesibilitate deosebit la ele; posibilitatea introducerii standardelor la nivelul bazelor de date; posibilitatea partajrii ntre diveri utilizatori. Modelarea fizic a datelor presupune trecerea de la descrierea logic a datelor la una tehnic, de stocare a datelor. Rezultatele modelrii fizice se concretizeaz ntr-un set de specificaii tehnice folosite ulterior de programatorii bazelor de date pentru definirea formatului i structurii datelor stocate n memoria secundar. Studiul tehnic conine formatele sub care vor fi reprezentate atributele, modul de gruparea al acestora din una sau mai multe relaii, n una sau mai multe nregistrri fizice, precum i metodele de accesare a datelor.

43

Selectarea tehnologiilor folosite pentru stocarea datelor se face innd cont c fiecare tehnologie este specific unei anumite arhitecturi a sistemului. Descrierea fizic a datelor este legat de sistemul de gestiune al bazelor de date ales pentru crearea bazei de date. Vizeaz modul n care datele vor fi stocate i accesate la nivelul memoriei externe, sistemele care asigur securitatea pstrrii i regsirii datelor. 2.4.1 Trecerea de la modelul Entitate-Asociere la Modelul Relaional Dup cum am mai afirmat, la nivel logic exist un standard pentru descrierea datelor: Modelul Relaional al Datelor. Mai mult exist reguli stricte de obinere a Modelului Relaional al Datelor pornind de la modelul Entitate-Asociere. Respectnd aceste standarde, din punctul de vedere al datelor, proiectarea sistemelor informatice se reduce la parcurgerea unor etape clar definite, cu respectarea unor formalisme unanim recunoscute. Este un pas important spre automatizarea trecerii de la concepie la realizare.

Pentru trecerea de la modelul Entitate-Asociere la Modelul Relaional s-au stabilit urmtoarele reguli [DL92]: 1.- fiecrei entiti i se asociaz o schem de relaie compus din toate atributele entitii. 2.- dac ntr-o asociere A exist o entitate E pentru care cardinalitatea maximal a cuplului (E,A) este 1, se adaug la schema de relaie R definit pentru E cheia entitii ce particip la asocierea A i atributele asocierii. Exemplu: Presupunnd c un anume tip de materii prime este aprovizionat de la un furnizor, i c un furnizor poate furniza mai multe tipuri de materii prime, modelul conceptual al datelor este :

44

FURNIZORI CodFurnizor NumeLocalitate

1,n

furnizeaz

1,1

MATERIIPRIME CodMatPrime CantitatePre

Aplicnd regula 1 se creaz dou scheme de relaie: R-Furnizori = ( CodFurnizor, Nume, Localitate ) R-MatPrime = ( CodMatPrime, Cantitate, Pret). Cardinalitatea cuplului (MATERIIPRIME, furnizeaz ) este (1,1). Aplicnd regula 2 avem urmtoarele scheme de relaie: R-Furnizori = (CodFurnizor, Nume, Localitate ) R-MatPrime = (CodMatPrime, Cantitate, Pret, CodFurnizor) CodFurnizor de la relaia R-Furnizori este acelai cu CodFurnizor de la relaia R-MatPrime. Aceast restricie se numete restricie de integritate referenial. 3.-dac ntr-o asociere A, pentru ambele entiti cardinalitatea maximal este n, se creaz o nou schem de relaie coninnd cheile entitilor ce particip la asociere i atributele asocierii. Exemplu: Presupunnd c un acelai tip de materii prime este aprovizionat de la mai muli furnizori, i c un furnizor poate furniza mai multe tipuri de materii prime, modelul conceptual al datelor este : FURNIZORI CodFurnizor Nume Localitate 1,n furnizeaz 1,n MATPRIME CodMatPrime Cantitate Pret

Aplicnd regula 1 se creaz dou scheme de relaie: R-Furnizori = ( CodFurnizor, Nume, Localitate) R-MatPrime =(CodMatPrime, Cantitate, Pret) Aplicd regula 3, se creaz o nou schem de relaie, ce cuprinde cheile celor dou entiti i atributul asocierii:45

R-Furnizeaz = ( CodFurnizor, CodMatPrimel) Exemplu : Aplicnd regulile prezentate anterior pentru Modelul Conceptual de Date din figura 2.2, rezult urmtorul Model Logic de Date: R-Client = (CodClient, DenumireClient, AdresaClient) R-DosarCredit=(NrDosar,DataDosar,TermFin,SumCredit,DobCredit, CodClient) R-FisaCredit = (NrFis, SumaIncasat, Dobnd, Penaliti, NrDosar) R-Rate = (TipDoc, NrDoc, DataDoc, SumaPCredit, SumaPDobnd, NrFis)

2.5 Modelarea Conceptual a PrelucrrilorModelul Conceptual al Prelucrrilor permite descrierea activitilor din sistemul real prin descompunerea unui proces n operaii. Permite reprezentarea nlnuirii operaiilor i precizarea condiiilor declanrii acestora. Conceptele de baz sunt: proces, operaie i evenimet. 2.5.1 Caracteristici proces Procesul este constituit dintr-o submulime de activitii independente de structura organizatoric a firmei, care au puncte de intrare i de ieire stabile. Exemple: Cerere de credit Acordarea unui credit Cerere respins Credit acordat

Comanda acceptat Gestiunea facturilor Factur emis Factur ncasat

46

eveniment Evenimentul indic faptul c ceva anume s-a ntmplat i n consecin sistemul trebuie s reacioneze. Este o circumstan, un semnal adus la cunotina sistemului i la care acesta trebuie s rspund. Pentru a fi considerat eveniment, semnalul trebuie s fie perceput de sistem, trebuie s fie declanatorul posibil al unei activiti. Exemplu: ntr-un sistem de eviden a personalului, faptul c pentru un angajat se completeaz foaie de pontaj constituie un eveniment, deaorece el declaneaz activitatea de eviden a salariailor, dar acest fapt nu constituie un eveniment pentru sistemul informatic de gestiune a clienilor. n funcie de poziia fa de sistemul informatic, n cadrul modelului conceptual al prelucrrilor se identific evenimente interne i evenimente externe. Evenimentele externe provin din exteriorul sistemului studiat i declaneaz n interiorul lui executarea unor activiti. Evenimentele externe nu pot fi controlate, asupra lor neputndu-se interveni. Exemplu: modificarea cursului leului, modificarea procentului de TVA, modificarea procentului n cazul impozitului pe salarii. Evenimentele interne survin la ncheierea unei operaii din cadrul sistemului studiat i se grupeaz n evenimente rezultat i evenimente intermediare. Evenimentele rezultat, reprezentate de ieiri ale prelucrrii n cadrul sistemului informatic proiectat, sunt destinate mediului extern al sistemului. Exemple: Evenimentele reprezentate de: factura ntocmit remis clientului, ordinul de plat ntocmit i depus la banc, declaraia de TVA ntocmit i depus la organul fiscal. Evenimentele intermediare sunt pe de o parte rezultate din executarea unor operaii i pe de alt parte declaneaz alte operaii n cadrul sistemului.

47

Exemple: ntocmirea Notei de Receptie i Constatare de Diferene n urma recepionrii mrfurilor, ntocmirea Bonului de Consum, a Bonului de Predare-Primire. Reprezentarea grafic a evenimentelor utilizeaz urmtoarele simboluri:

Ee Eveniment extern

Ei Eveniment intern

E Eveniment rezultat Evenimente emise (de sistem)

Evenimente contributive (declaneaz aciuni n cadrul sistemului)

operaia Operaia reprezint o secven continu de activiti productoare de evenimente. Operaia constituie un bloc de prelucrare, o succesiune de activiti elementare care se execut nentrerupt din momentul declanrii. Operaiile sunt declanate de evenimente externe sau de evenimente intermediare i conduc la producerea de evenimente intermediare sau rezultat, n funcie de respectarea unor anumite condiii, numite reguli de emisie. Condiiile sunt expresia unor situaii determinate de contextul n care are loc derularea operaiei, cunoscute n momentul derulrii operaiei. sincronizare O operaie nu se poate declana dect dac se realizeaz anumite condiii, deci se produc anumite evenimente, numite evenimente contributive. Ansamblul condiiilor care determin declanarea unei48

operaii este cunoscut sub denumirea de sincronizare. ntr-o manier general, sincronizarea se exprim sub forma unei propoziii logice care trebuie s respecte urmtoarele reguli: condiiile trebuie s priveasc evenimentele declanatoare (contributive) condiiile nu trebuie s se refere la informaia din baza de date; trebuie s existe cel puin o situaie care permit declanarea operaiilor. O operaie se reprezint astfel:

E1

E2

Evenimente declanatoare

Propoziia logic numele sincronizrii Nr. Operaia Descrierea operaiei Reguli de emisie

Sincronizare

Operaia

Ei3 Eveniment rezultat

Ei4 Eveniment intern Intermediar

2.5.2 Construirea Modelului Conceptual al Prelucrrilor n construirea Modelului Conceptual al Prelucrrilor se parcurg urmtoarele etape: a delimitarea domeniilor de activitate i a proceselor corespunztoare. n cazul sistemelor complexe, se analizeaz activitile desfurate i se grupeaz ntr-un procese cele care, independent de49

structura organizatoric, sunt determinate de aceleai evenimente externe (au puncte de intrare stabile) i au aceeai finalitate (au puncte de ieire stabile) ; b identificarea evenimentelor interne i identificarea sincronizrii Se specific evenimentele declanatoare i dac este cazul, durata sincronizrii. Se au n vedere condiiile reciproce de determinare a evenimentelor declanatoare, faptul c trebuie s existe cel puin o situaie care s permit declanarea operaiilor. c definirea operaiilor. Se analizeaz aciunile i se precizeaz condiiilor de obinere a rezultatelor, adic se identific regulile de gestiune care conduc la obinerea rezultatelor. Se are n vedere c o operaie este o succesiune nentrerupt de prelucrri, c n interiorul unei operaii nu se admite producerea unui rezultat intermediar care s condiioneze derularea operaiei. Dup parcurgerea acestor etape se poate trece la prezentarea nlnuirii operaiilor din cadrul fiecrui proces. Se are n vedere faptul c o operaie este declanat de cel puin un eveniment i c orice operaie declaneaz la rndul ei cel puin un eveniment. Modelului Conceptual al Prelucrrilor este rezultatul reprezentrii tuturor proceselor identificate n cadrul sistemului real. Exemplu pentru sistemul informatic privind acordarea unui credit: . nlnuirea operaiilor i a evenimentelor declanatoare n cazul procesului de ntocmire a dosarului de credit este prezentat n figura 2.4 .nlnuirea operaiilor i a evenimentelor declanatoare n cazul procesului de avizare a dosarului de credit este prezentat n figura 2.5 .nlnuirea operaiilor i a evenimentelor declanatoare n cazul procesului de urmrire a creditului acordat este prezentat n figura 2.6

50

Cerere credit E1 E1 si E2

Documentaie E2

01

Preluare documente

Incrcare date despre client i situaia lui financiar DA Cerere inregistrat 02 Analiz situaie financiar NU

Calcul coeficieni Cuantificare risc Coeficienti risc ridicat Cerere respins Posibila acordare de credit Cerere admis

03

Analiza nivel de responsabilitateDA

Suma < 100 000 000

NU

Dosar intocmit

Dosar respins

fig.2.451

Dosar de credit intocmit

01

Avizare conducere Semnarea dosarului de ctre conducere

DADosar avizat

NUDosar neavizat

02

Avizare client Semnarea dosarului de ctre client

DADosar semnat

NUDosar nesemnat

03

Deschidere ficredit Deschiderea fiei de eviden operativ a creditului

DA

NU

Fi credit deschis

fig.2.5

52

Document de plat

Fi de credit deschis

Termen scadent

^1 Operaii legate de scadenta Inregistrarea ordinelor de plata Da Nu

Fi de credit actualizata

Credit restant

2 Calcul penaliti Penaliti, intarzieri Calcul dobanda

DaPenaliti calculate

Nu

3

Actualizare fia credit Inscriere penaliti Inscriere doband

DaFi credit actualizat

Nufig.2.6

2.6 Modelul Organizaional al Prelucrrilor

53

Modelul Organizaional al Prelucrrilor prezint mulimea operaiilor lund n calcul structura organizatoric a firmei, posturile de lucru ce reprezint uniti de aciune elementare dotate cu mijloace de execuie. Postul de lucru este reprezentat prin ansamblul format din echipamentele de prelucrare automat a datelor i persoana ce le utilizeaz. Modelarea organizaional prezint prelucrrile din punctul de vedere al utilizatorului, care i desfsoar activitatea n condiiile concrete ale firmei, ale compartimentelor ei funcionale. nlnuirea procedurilor, descompunerea lor n faze se face n concordan cu structura organizatoric a firmei, cu legislaia n viguare, dar fr a considera o anume soluie informatic de implementare. 2.6.1 Caracteristici Principalele concepte sunt: procedur, faz, sarcin. procedura O procedur este constituit dintr-un ansamblu de prelucrri declanate de unul sau mai multe evenimente externe. Producnd unul sau mai multe rezultate, procedura corespunde executrii de ctre firm a unui ansamblu de reguli de gestiune. Exemplu: . procedura de acordare a creditelor ntr-o instituie bancar . procedura de gestionare a facturilor faza Faza este o succesiune nentrerupt de prelucrri, cu aceeai periodicitate, executate ntr-un post de lucru. O succesiune de faze aparinnd aceluiai proces alctuiesc o procedur. sarcina Sarcina este reprezentat de o mulime de prelucrri elementare, executate n interiorul unei faze. 2.6.2 Construirea Modelului Organizaional al Prelucrrilor Modelului Organizaional al Prelucrrilor se obine din Modelul Conceptual al Prelucrrilor, lund n calcul structura organizatoric a54

firmei. Fiecrui proces din Modelul Conceptual al Prelucrrilor i corespund una sau mai multe proceduri n Modelul Organizaional al Prelucrrilor. Pentru fiecare operaie din Modelul Conceptual al Prelucrrilor, n Modelul Organizaional al Prelucrrilor corespund una sau mai multe faze. Cu aceste consideraii, Modelul Organizaional al Prelucrrilor pentru un sistem informatic este rezultatul reprezentrilor corespunztoare tuturor proceselor din Modelul Conceptual al Prelucrrilor Exemplu In cazul sistemului informatic de acordare a creditelor, se construiete cte un Model Organizaional de Prelucrri pentru fiecare proces delimitat n Modelul Conceptual al Prelucrrilor: .. n figura 2.7 este reprezentat Modelul Organizaional al Prelucrrilor pentru procesul de ntocmire a dosarului de credit .. n figura 2.8 este reprezentat Modelul Organizaional al Prelucrrilor pentru procesul de avizare a creditului .. n figura 2.9 este reprezentat Modelul Organizaional al Prelucrrilor pentru procesul de urmrire a creditului acordat

55

Client

Conducere

Creditare

Calculaie contabilitate

01Cerere credit Timp real Documen taie

Preluare02 Calcul Timp real coeficienti

D document

Cerere inregistrata Coeficienti calculati

03 CuantificareTimp

real NUCerere respinsa Cerere admisa

risc DA

04 Analiza manual r NU Dosar respins fig. 2.7

nivel DA

Dosar intocmit

56

Client

Conducere

Creditare

Calculatie contabilitate

Dosar intocmit 1 Avizare Man ual conduNU DA cere

Dosar neavizat

Dosar avizat Dosar aprobat 2 Semnarea dosarului manu de NU DA 3 Deschidere Timp fisa real credit

Dosar nesemnat Fisa credit deschisa Fig.4.6

fig.2.857

Client

Creditare

Calculatie

Docume nt de plata

01 Timp real

Verificare termen scadent Da Nu

Credit restant Document de plata la 03 Timp real Inregistrarea documentelor de plata Da Nu Calcul penalitati Da Nu

02 Timp real

Penalitati calculate

Docume nt de 04 Timp real Calcul dobanda Da Nu

E1 sau (E2 i E3)

05 Timp real Fig. 2.9

Actualizare fisa credit Da Nu Fisa de credit

Dobanda calculat E3

58

2.7 Descrierea logic i operaional a prelucrrilorLa nivel logic i operaional sunt luate n calcul problemele tehnice i restriciile impuse de mediul de programare existent la nivelul firmei: . tipul de reea utilizat ; . particularitile server-ului i ale posturilor de lucru ; . SDBD-ul utilizat ; . sistemul informatic actual, posibilitile de extindere. Dezvoltarea rapid a tehnologiei informaiei, libertatea de a alege cea mai bun soluie n funcie de context, au limitat definirea unor modele standard de descriere a prelucrrilor la nivel logic i operaional. La ora actual nu exist un formalism unanim recunoscut pentru descrierea prelucrrilor la nivel logic i operaional. Exist ns un principiu general, admis momentan de toi proiectanii de sisteme informatice, conform cruia o faz descris la nivel organizaional se poate descompune n trei tipuri de sarcini, ce vizeaz: 1 prezentarea datelor conform cerinelor utilizatorilor. 2 calcule, actualizri, validri 3 accesul la date Indiferent de tipul de sarcin, la acest nivel prelucrrile sunt prezentate n legtur direct cu datele. Dac n primul caz accentul cade pe modul de afiare a informaiilor, n ultimele dou cazuri prioritar este reprezentarea intern a datelor, n funcie de care se definesc proceduri standard de consultare, actualizare, de citire sau scriere n baza de date. n primul caz un loc important l ocup definirea interfeei cu utilizatorul, inserarea unor obiecte vizuale predefinite care s faciliteze afiarea informaiilor conform unor criterii de selecie stabilite la momentul interogrii. n cazul al doilea, formulele de calcul, expresie a regulilor de gestiune, sunt aplicate mpreun cu proceduri de control privind respectarea restriciilor de integritate. Consultarea sau actualizarea bazei de date este precedat de execuia unor proceduri ce vizeaz drepturile de acces, care sunt determinate de restriciile impuse de mediul de59

programare. Exist proceduri pentru gestionarea drepturilor de acces i proceduri pentru soluionarea eventualelor incidente sau erori aprute la execuie. Pentru toate aceste proceduri, modul concret de implementare depinde de soluia informatic aleas, de performanele tehnicii de calcul existente i de capacitatea proiectanilor de a alege cele mai bune soluii. n cazul sistemele informatice de gestiune, corespunztor sistemul relaional de reprezentare a datelor, pentru manipularea lor se utilizeaz un SGBD relaional. Se poate apela i la un limbaj de programare ce ofer faciliti n definirea interfeei cu utilizatorul, n codificarea regulilor de validare sau n efectuarea unor calcule laborioase.

TESTE FINALE1 Care din afirmaiile urmtoare este adevrat ? a) Nivelul conceptual urmrete obinerea unei reprezentri fidele a realitii, innd cont de restriciile informatice sau organizatorice. b) Nivelul organizaional leag funcionalitatea sistemului de strucura organizatoric a firmei i de postul de lucru. c) Nivelul organizaional urmrete obinerea unei reprezentri fidele a realitii, fcnd abstracie de restriciile informatice sau organizatorice. 2 Care din afirmaiile urmtoare nu este adevrat ? a) Nivelul organizaional leag funcionalitatea sistemului de soluia informatic adoptat b) Nivelul logic vizeaz alegerea soluiei informatice pentru culegerea datelor i furnizarea informaiei. c) Nivelul fizic este nivelul concret la care sunt definite mijloacele tehnice de realizare efectiv a sistemului. 3 Care din afirmaiile urmtoare nu este adevrat ? a) Modelul Conceptual al Datelor surprinde cu ajutorul unor abstracii aspectul static i dinamica n timp a activitii desfurate.

60

b) Modelul Conceptual al Datelor definete structura global de organizare a datelor, asigurnd independen total fa de orice sistem de gestiune a bazelor de date. c) Modelul Conceptual de Date folosete un formalism precis, normalizat pe plan internaional de ISO sub numele de model Entitate Asociere. 4 Care din afirmaiile urmtoare nu este adevrat ? a) Modelul Conceptual al Prelucrrilor descrie latura dinamic a sistemului, evideniind nlnuirea operaiilor i condiiile declanrii acestora. b) Modelul Organizaional al Datelor prezint mulimea datelor grupate pe uniti organizatorice. c) Modelul Conceptual al Prelucrrilor se construiete n situaiile n care operaiile definite la nivel conceptual sunt executate n diferite compartimente funcionale. 5 Care din afirmaiile urmtoare nu este adevrat ? a) Entitatea este o reprezentare conceptual a unui obiect sau fenomen din sistemul real. b) Entitatea are existen proprie i este conform cu regulile de gestiune ale firmei. c) O entitate este considerat o mulime de valori posibile. 6 Care din afirmaiile urmtoare nu este adevrat ? a) Asocierea ntre entiti exprim o legtur existent sau posibil ntre obiecte individuale. b) Identitatea unei entiti este exprimat printr-un atribut care permite consultarea realizarilor de entitate. c) Atributul definete o proprietate distinct a unei entiti sau a unei asocieri. 7 Care din afirmaiile urmtoare este adevrat ?

61

a) Fiecare realizare a unei entiti posed aceleai valori pentru atribute. b) O asociere nu poate avea atribute proprii. c) Cardinalitatea d informaii despre numrul minim i numrul maxim de apariii ale unei asocieri A ntre o entitate E1 i o alta E2. 8 Care din afirmaiile urmtoare nu este adevrat ? a) n construirea Modelului Conceptual al Datelor exist dou tehnici pentru definirea entitilor i a relaiilor: modelarea prin entiti i modelarea modelarea direct. b) Normalizarea este un proces care asigur eliminarea redundanelor fr pierdere de informaie; c) Normalizarea este un proces care asigur eliminarea anomaliilor n procesul de actualizare. 9 Care din afirmaiile urmtoare nu este adevrat ? a) n cazul entitilor, descompunerea permite asigurarea c nu exist atribute repetitive sau compuse ntr-o entitate. b) n cazul asocierilor, normalizarea permite asigurarea c atributele unei asocieri depind n totalitate de identificatorii entitilor participante. c) Descompunerea permite definirea, fr pierdere de informaie, a mai multor relaii de dimensiune doi dintr-o relaie de dimensiune mai mare. 10 Care din afirmaiile urmtoare nu este adevrat ? a) Restrictii de integritate statice sunt restricii care se verific permanent b) Restriciile de integritate sunt reguli suplimentare, reprezentate direct n modelul conceptual al datelor, dar care nu trebuie respectate permanent de date. c) Restrictii de integritate dinamice sunt restricii care privesc evoluia n timp a datelor. 11 Care din afirmaiile urmtoare nu este adevrat ?

62

a) Restriciile de integritate structurale se refer la integritatea entitilor, viznd faptul c fiecare entitate trebuie identificat n mod unic; b) Restriciile de integritate semantice se refer la integritatea referenial, viznd faptul c pentru orice realizare a unei asocieri este obligatoriu s existe realizri pentru entitile participante; c) Restriciile de integritate structurale se refer la cardinaliti, viznd respectarea condiiilor n cazul cardinalitilor minimale i maximale. 12 Se considera urmatorul fragment de model conceptual al datelor: facturare cantitate PRODUS CodProdus Denumire 1,n 1,n livrare cantitate 1,1 FACTURA NrFactura 1,1 Data

Faptul ca livrarea produselor este precedat de facturarea lor constituie : b) c) e) o restrictie de integritate de incluziune intre asocieri ; o restrictie de integritate de excluziune intre asocieri ; o restrictie de integritate de domeniu.

13 Se consider urmtorul fragment de Model Conceptual de Date: PRODUS CodProdus Denumire 0,n produs_facturat cantitate pretVinzare 1,n FACTURA NrFactura DataFactura

Care din urmtoarele afirmaii este adevrat ?63

a) un produs se regsete pe cel puin o factur . b) fiecare factura contine cte un produs . c) cantitate i pretVinzare sunt atribute ce trebuie s apar la entitatea Produs . 14 Se consider urmtorul fragment de Model Conceptual de Date: PRODUS CodProdus Denumire 0,n produs_facturat cantitate pret_vinzare 1,n FACTURA NrFactura DataFactura 1,1 corespunde 1,1 DOCINCAS plateste 1,n 1,1NrDocIncas FelDocIncas

1,1 primeste 1,n

CLIENTCodClient

DenClient AdresaClient nt

DataDocIncas SumaIncas

Care