Sisteme informatice financiar-bancare Sisteme informatice de gestiune

Autori: Prof. Univ. Dr. Mioara Udrica Lector. Univ. Dr. Martinov Dan

CUPRINS
CAPITOLUL I - SISTEMUL INFORMATIC AL FIRMEI ........................................... 3

1.1 Sistem informaional ............................................................................ 3 1.2 Sistem informatic ................................................................................. 6

1.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 ...................................................................................... 60
2.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 ................................................. 83

3.3.1 Descrierea limbajului .......................................................................................... 83 3.3.2 Definirea limbajului ............................................................................................ 85

3.4 Diagrame UML .................................................................................. 86

3.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

CAPITOLUL I - SISTEMUL INFORMATIC AL FIRMEI

Etapa 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.

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

1.2 Sistem informatic

Sistemul 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.

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 I
SISTEME 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 informatice

n 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 de
8

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.

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 imagine
10

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 informatic

1.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 informatice

Ansamblul 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 problemele
14

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 FINALE
1 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 SISTEMICE

Dintre 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 descriere

n 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 prelucrri

Pentru 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 datelor

n 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

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 CodClient
DenumireClient AdresaClient

1,n

1,1 corespun d

DOSAR CREDIT NrDosar

DatDosar TermenFinal SumCredit DobndCredit

1,1 1,1
are

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 NrFactura
Data

0,n

conin cantitate
pre

0,n

MATERIALE CodMaterial
Denumire

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: CONTRIBUABIL

CodContribuabil Nume Adres 1,n pltete 1,1

DOC PLAT
NrDoc 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 datelor

Modelarea 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 unui
anumit 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 Nume

Localitate

1,n

furnizeaz

1,1

MATERIIPRIME CodMatPrime Cantitate

Pre

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 Prelucrrilor

Modelul 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 unei
48

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 de
49

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 responsabilitate

DA

Suma < 100 000 000

NU

Dosar intocmit

Dosar respins

fig.2.4
51

Dosar de credit intocmit

01

Avizare conducere Semnarea dosarului de ctre conducere

DA
Dosar avizat

NU
Dosar neavizat

02

Avizare client Semnarea dosarului de ctre client

DA
Dosar semnat

NU
Dosar 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

Da
Penaliti calculate

Nu

Actualizare fia credit Inscriere penaliti Inscriere doband

Da
Fi credit actualizat

Nu
fig.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 a
54

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

01
Cerere credit Timp real Documen taie

Preluare
02 Calcul Timp real coeficienti

D document

Cerere inregistrata Coeficienti calculati

03 Cuantificare
Timp

real NU
Cerere 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.8
57

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 prelucrrilor

La 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 de
59

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 FINALE
1 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,1
NrDocIncas FelDocIncas

1,1 primeste 1,n

CLIENT
CodClient

DenClient AdresaClient nt

DataDocIncas SumaIncas

Care este Modelului Logic al datelor corespunztor ? a) Produs = (CodProdus, DenProdus, cantitate, pret_vinzare) ; Factura = (NrFactura, DataFactura, CodClient, CodProdus, cantitate, pret_vinzare) ; Client = (CodClient, DenClient, AdresaClient, NrDocIncas) ; DocIncas = ( NrDocIncas, FelDocIncas, DataDocIncas, SumaIncas, CodClient) ; ProdusFacturat = ( CodProdus, NrFactura, cantitate, pret_vinzare). b) Produs = (CodProdus, DenProdus) ; Factura = (Nrfactura, DataFactura, CodClient) ; Client = (CodClient, DenClient, AdresaClient) ; DocIncas = ( NrDocIncas, FelDocIncas, DataDocIncas, SumaIncas, CodClient, NrFactura) ; ProdusFacturat = ( CodProdus, NrFactura, cantitate, pret_vinzare).
64

c)

Produs = (CodProdus, DenProdus, pret_vinzare) ; Factura = (Nrfactura, DataFactura, CodClient, NrDocIncas, FelDocIncas) ; Client = (CodClient, DenClient, AdresaClient) ; DocIncas = ( NrDocIncas, FelDocIncas, DataDocIncas, SumaIncas, NrFactura) ; ProdusFacturat = ( CodProdus, NrFactura, cantitate). 15 Pentru proiectarea sistemului informatic privind vnzarea produselor se cunosc urmtoarele: .. produsele sunt identificate printr-un cod; .. facturile sunt identificate prin numr i dat; .. pe o factur pot fi nregistrate mai multe produse; pentru fiecare produs se consemneaz cantitatea i preul de vnzare; .. un produs se regsete pe mai multe facturi ; .. unui client i pot fi destinate una sau mai multe facturi. Care din variantele urmtoare reprezint Modelul Conceptual al Datelor ? a) PRODUS FACTURA 0,n NrFactura DataFactura Cantitate Pret_vnzare 1,1 1,n Clieni CodClient DenClient Adres 1,n destinata

CodPr 1,1 odus

1,n

produs_facturat

65

b) Produs CodProdus Pre_vnzare 1,n produs_facturat cantitate 1,n Factura 1,1 NrFactura DataFactura 1,1 Clieni
CodClient

1,n destinata

DenClient Adres

c) PRODUS CodProdus 1,n produs_facturat cantitate pret_vinzare Factura 1,n NrFactura DataFactura 1,1 Clieni CodClient DenClient Adres 1,n destinata

16 Care din afirmaiile urmtoare nu este adevrat ? a) Prelucrrile surprind parte dinamic, modificrile n timp ale unui sistem informatic. b) Prelucrrile traduc regulile de gestiune ale firmei. c) Prelucrrile sunt constituite dintr-o submulime de activitii independente de structura organizatoric a firmei, care au puncte de intrare i de ieire stabile.
66

17 Care din afirmaiile urmtoare nu este adevrat ? a) Modelul Organizaional al Prelucrrilor permite descrierea activitilor din sistemul real prin descompunerea unui proces n operaii. b) Modelul Conceptual al Prelucrrilor permite descrierea activitilor din sistemul real prin descompunerea unui proces n operaii. c) Modelul Conceptual al Prelucrrilor permite reprezentarea nlnuirii operaiilor i precizarea condiiilor declanrii acestora. 18 Care din afirmaiile urmtoare este adevrat ? a) Evenimentul este o circumstan, un semnal adus la cunotina sistemului i la care acesta trebuie s rspund. b) Un semnal c ceva s-a ntmplat n sistem este considrat eveniment chiar dac el nu este declanatorul posibil al unei activiti. c) Evenimentele externe provin din interiorul sistemului studiat i declaneaz n exteriorul lui executarea unor activiti. 19 Care din afirmaiile urmtoare este adevrat ? a) Evenimentele externe pot fi controlate, asupra lor putndu-se interveni din sistem. b) Exemple de evenimente externe: modificarea cursului leului, modificarea procentului de TVA, modificarea procentului n cazul impozitului pe salarii. c) Exemple de evenimente externe: modificarea cursului leului, ordinul de plat completat, modificarea procentului n cazul impozitului pe salarii. 20 Care din afirmaiile urmtoare este adevrat ? a) Evenimentele intermediare survin la ncheierea unei operaii din cadrul sistemului studiat i se grupeaz n evenimente rezultat i evenimente externe. b) Evenimentele externe sunt rezultate din executarea unor operaii i sunt destinate mediului extern. c) Evenimentele externe declaneaz operaii n cadrul sistemului. 21 Care din afirmaiile urmtoare este adevrat ? a) Exemplu de evenimente intermediare: ntocmirea Notei de Receptie i Constatare de Diferene n urma recepionrii mrfurilor, factura ntocmit remis clientului.

67

b) Evenimentele rezultat, reprezentate de ieiri ale prelucrrii n cadrul sistemului informatic proiectat, sunt destinate mediului extern al sistemului. c) Exemple de evenimente interne: ordinul de plat ntocmit i depus la banc, declaraia de TVA ntocmit i depus la organul fiscal, modificarea procentului de TVA. 22 Care din afirmaiile urmtoare nu este adevrat ? a) Operaia reprezint o secven continu de activiti productoare de evenimente. b) Operaia constituie un bloc de prelucrare, o succesiune de activiti elementare care se execut nentrerupt din momentul declanrii. c) Operaiile sunt declanate n funcie de respectarea unor anumite condiii, numite reguli de emisie. 23 Care din afirmaiile urmtoare este adevrat ? a) Operaiile conduc la producerea de evenimente intermediare sau externe, n funcie de respectarea unor anumite condiii, numite reguli de emisie. b) Operaiile sunt declanate de evenimente externe sau de evenimente intermediare c) O operaie declaneaz n anumite condiii evenimente numite evenimente contributive. 24 Care din afirmaiile urmtoare este adevrat ? a) Modelul Organizaional al Prelucrrilor prezint mulimea operaiilor lund n calcul structura organizatoric a firmei. b) Postul de lucru este reprezentat de echipamentele de prelucrare automat a datelor dintr-un compartiment funcional. c) n cadrul Modelului Organizaional al Prelucrrilor descompunerea procedurilor n faze se face lund n considerai o anume soluie informatic de implementare. 25 Care din afirmaiile urmtoare este adevrat ? a) La ora actual exist un formalism unanim recunoscut pentru descrierea prelucrrilor la nivel logic i operaional: Modelul Relaional.

68

b) Fiecrei proceduri din Modelul Conceptual al Prelucrrilor i corespund una sau mai multe procese productoare de rezultat n Modelul Organizaional al Prelucrrilor. c) Pentru fiecare operaie din Modelul Conceptual al Prelucrrilor, n Modelul Organizaional al Prelucrrilor corespund una sau mai multe faze. 26 Se consider urmtorul fragment din sistemul informatic pentru acordarea unui credit. Cerere credit admis S3 O2 Deschid fi credit 3 Deschiderea fiei de eviden operativ a creditului DA NU Fi credit Termen scaden Ordin de plat

S4 Operaii legate de scaden 4 NU Credit restant Urmrirea ncasrii ratei scadente DA Fia actualizat

Care din urmatoarele afirmatii este adevrat ? a) Evenimentul Termen scaden este eveniment rezultat b) Evenimentul Termen scaden este eveniment extern
69

3.Chiar dac operaiile legate de scaden nu se pot efectua, fia de credit este actualizat 27 n cadrul sistemului informatic privind acordarea unui credit, analiza dosarului de credit este o operaie declanat de nregistrarea unei cereri de creditare i a unei documentaii corespunztoare. Analiza dosarului de credit presupune cuantificarea riscului creditului. Dac exist un coeficient de risc ridicat, nu se acord creditul i dosarul este respins. Care din urmtoarele variante este secvena corect a modelului conceptual al prelucrrilor construit pentru secventa de activitate descrisa mai sus. a) Cerere credit

2 Analiz dosar credit Cuantificarea riscului creditului Coef. de risc ridicat Credit posibil de acordat

Cerere credit respins

Dosar nchis

Cerere credit admis

b)

Cerere credit S1
70

2 Analiz dosar credit Cuantificarea riscului creditului coef. de risc ridicat Credit posibil de acordat

Cerere credit respins c) Documentaie

Cerere credit admis

Cerere nregistrat S1

2 Analiz dosar credit Cuantificarea riscului creditului coef. de risc ridicat Credit posibil de acordat

Cerere credit respins

Dosar nchis

Cerere credit admis

Rezolvare teste 1-b 2-a 10-b 11-b 19-b 20-c

3-a 4-c 12b 13-a 21-b 22-c

5-c 14-b 23-b

6-b 15-c 24-a

7-c 16-c 25-c

8-a 17-a 26-b

9-a 18-a 27-c

71

CAPITOLUL III - METODE ORIENTATE OBIECT 3.1 Metodologia orientat obiect.

Dezvoltarea sistemelor orientate obiect cuprinde ntregul ciclul de via al sistemului, mprit n trei faze: analiz, proiectare, implementare. n aceste faze se ntlnesc, n planuri conceptuale diferite, elemente orientate obiect, notaii din domeniul aplicaiei i al computerelor. Metodologia orientat obiect presupune construirea unui model al unui domeniu de aplicaie i adugarea detaliilor de implementare n timpul proiectrii. n faza de analiz se construiete un model pentru abstractizarea aspectelor eseniale din domeniul aplicaiei. Modelul nu cuprinde detalii de implementare. Pentru a descrie i optimiza implementarea, acestea sunt adugate n etapa de proiectare.

analiza
n faza de analiz, metodologia orientat obiect cere construirea unui model precis, concis i inteligibil al lumii reale, construirea unui model complet al aplicaiei. Analistul descrie ce trebuie s fac sistemul i nu cum o face, urmrete definirea a ceea ce urmeaz s realizeze, i nu a algoritmilor care vor fi folosii. Obiectele sunt concepte din domeniul aplicaiei, i nu din domeniul programrii. Atenia este ndreptat asupra conceptelor care vor forma nucleul unei soluii ce utilizeaz tehnici orientate obiect. Analiza este selectiv, neacordndu-se aceeai importan tuturor componentelor i nsuirilor. Lumea real se descompune n entiti distincte, se stabilesc legturile dintre ele i funciile ndeplinite. Sunt examinate cerinele, analizate implicaiile, reinute doar aspectele eseniale. Rezultatul este un model cu clase i asocieri eficient prezentate, folosirea acestora fcndu-se n partea de proiectare i implementare.

72

proiectarea
Scopul principal al proiectrii orientate obiect este s maximizeze posibilitatea reutilizrii claselor n proiecte ulterioare, s identifice n relaiile de motenire superclasele care faciliteaz reutilizarea n cadrul aceluiai proiect. n Object-Oriented Modeling and Design ([R*96]), autorii consider c proiectarea se efectueaz n dou etape: proiectarea sistemului i proiectarea obiectelor. Proiectarea sistemului implic mprirea sa n subsisteme, i alocarea resurselor hardware i software. Proiectarea obiectelor continu strategia aleas n etapa de proiectare a sistemului i rafineaz detaliile. Se pstreaz structura claselor stabilit n partea de analiz, lund n consideraie minimizarea timpului de execuie i folosirea raional a memoriei. Operaiile identificate n etapa de analiz sunt exprimate algoritmic, cele complexe sunt descompuse n operaii interne simple. Atributele i asocierile sunt prezentate ntr-o form ce permite ulterior implementare ca structuri de date specifice. Clasele sunt rearanjate prin evidenierea unor relaii de agregare sau de generalizare, sunt completate cu noi operaii i noi atribute, rezultate din abstractizarea comportamentului comun. Modelul claselor poate fi rafinat prin introducerea de noi clase, care pstreaz rezultate intermediare de calcul. Considernd clasele ca nite ,,cutii negre a cror interfa extern este public, dar ale cror detalii interne sunt ascunse, proiectantul decide atributele care sunt vizibile din exterior. Ascunderea informaiei interne permite ca implementarea unei clase s fie modificat, fr a cere clienilor clasei s-i modifice codul. Este necesar o nou documentare a claselor, pe baza celei din partea de analiz, care s conin i modificrile care au aprut n faza de proiectare. ntr-o ultim faz a proiectrii, clasele i asocierile se regrupeaz n module.

73

implementarea
n timp ce primele dou etape sunt independente de mediul de programare, n aceast etap trebuie aleas soluia informatic pentru realizarea efectiv a sistemului. Clasele i relaiile sunt translatate ntr-un limbaj de programare, de regul orientat obiect. n cele mai multe cazuri, scrierea secvenelor de cod ntr-un limbaj orientat obiect se face aproape automat, pe baza deciziilor luate n fazele anterioare. Spre deosebire de limbajele procedurale pentru care un program cuprindea o serie de proceduri care se apelau reciproc, procedura reprezentnd unitatea de calcul ce transmite valori pentru date sau actualizeaz parametrii de intrare, pentru limbajele orintate obiect exist obiecte capabile s trimit mesaje de la unul la cellalt, s proceseze cereri recunoscute ca mesaje, s rspund unei colecii predefinite de mesaje care formeaz interfaa obiectului. Noiunea de mesaj este o abstracie, care poate fi implementat ca apel de procedur, eveniment discret, ntrerupere. Caracteristicile eseniale ale limbajelor de programare orientate obiect au fost definite n anii 70-80 de coala Smalltalk i apoi de limbajul C++. n acelai timp, noiunea de entitate din modelele semantice a fost preluat n modelele orientate obiect, punnd ns accentul pe comportamentul datelor, ncapsulnd n conceptul de obiect att datele, ct i operaiile posibile asupra lor. Primele limbaje orientate obiect au fost limbajele folosite pentru rezolvarea problemelor de simulare i au definit noiunea de clas, ce regrupeaz o structur de date i procedurile necesare pentru manipularea ei. Rnd pe rnd au fost reluate i amplificate tendinele de uniformizare ale mediului de programare, unde totul se reduce la obiect, au aprut limbaje care ofer funcionaliti ale programrii orientate obiect, conservnd structurile de control clasice ale limbajelor imperative. Obinnd o nsumare a avantajelor sistemelor de gestiune a bazelor de date, care interogheaz eficient datele, i a limbajelor procedurale care permit calcule complexe, programarea orientat obiect permite abordarea natural a lumii reale, folosind componente modularizate i eliminnd restriciile impuse de mediul de programare.

74

3.2 Modelul obiect

Modelul obiect s-a dezvoltat pe baza principiilor preluate din programarea orientat obiect nc de la sfritul anilor 60. Implicarea unor date complexe (documente electronice, date n format multimedia), necesitatea definirii unor tipuri de date-utilizator i reutilizarea componentelor existente, sunt doar cteva din realitile care au impus n proiectarea sistemelor informatice modelele obiect. Elementul central al modelului l constituie obiectul. 3.2.1 Obiecte Un obiect este o abstracie, un concept, folosit pentru reprezentarea lumii reale i furnizarea unei baze practice pentru implementarea cu ajutorul tehnicii de calcul. Descompunerea sistemului real n obiecte depinde de modelator i de natura concret a problemei. Exemple: persoana IONESCU, produsul CALCULATOR, factura AS-1234 din 12/03/04 sunt obiecte din lumea real, ce se regsesc n sistemul informatic privind personalul angajat, gestiunii resurselor i respectiv vnzrii de produse. Caracteristicile unui obiect sunt: identitate, stare, comportament. i astfel, modelul orientat obiect este o reprezentare direct a realitii cu ajutorul unor componente elementare cu identitate proprie i caracterizate prin stare i comportament. Identitatea unui obiect este acea proprietate a obiectului care l distinge de alte obiecte. Obiectul este definit de un identificator intern unic, independent de valoarea sau de adresa de memorie a obiectului. Identificatorul nu este controlat direct de programator i nu se confund cu diferitele nume utilizate de programator pentru a-l numi. Identitatea organizeaz obiectele ntr-un spaiu manipulat de limbajele orientate obiect. Spaiul obiectelor se construiete pornind de la obiecte de baz. Ca entiti complexe, obiectele sunt
75

constituite din alte obiecte i/sau din valori. Ele sunt create de utilizatori, prin derivare din tipuri de obiecte create anterior, sau printr-o operaie explicit de creare. Starea este o abstracie a valorilor atributelor i a legturilor unui obiect. Starea obiectului reprezint mulimea valorilor tuturor atributelor i legturilor sale la un moment dat. Starea este adesea asociat cu valoarea unui obiect satisfcnd anumite condiii. Exemple: persoana IONESCU aparinnd unui sistem informatic de eviden a personalului poate fi n starea angajat cu carte de munc sau pensionar, n funcie de valorile atributului vrst. Prin raportare la o firm, poate fi n starea angajat sau omer. factura AS-1234 din 12/03/04 poate fi n starea achitat sau neachitat, stare determinat de factori externi, reprezentai prin ncasarea sau nu a contravalorii sale.

Com portam entul este determinat de ansamblul operaiilor pe care obiectul le poate executa. Exprim modul n care un obiect
acioneaz i reacioneaz.

Exemple:
pentru persoana IONESCU, operaia afieaz permite calcularea i afiarea pe ecran valorii atributului vechime n munc. Prin operaia valoare, se pot calcula reinerile din salariu sau sporurile. pentru factura AS-1234 din 12/03/04, cu ajutorul operaiilor definite se pot afia datele de identificare ale furnizorului sau se poate calcula valoarea total n funcie de articolele facturate i de cota tva.

Comportamentul este cel care altereaz starea unui obiect, determin schimbarea strii sale. Corespunztoare comportamentului global al obiectului, mulimea valorilor grupate ntr-o stare, specific rspunsul obiectului la evenimentul primit.

76

3.2.2 Instrumente ale modelului orientat obiect Pornind de la componentele elementare (obiecte), modelul obiect al sistemului real se obine folosind instrumente specifice tehnicilor orientate obiect. Acestea sunt: abstractizarea, ncapsularea i ierarhizarea. 3.2.2.1 Abstractizare Abstractizarea este o operaie a gndirii prin care se desprind i se rein caracteristicile i relaiile eseniale ale obiectului cercetat [DEX]. n cazul sistemelor reale complexe, prin abstractizare se poate ajunge la modele inteligibile, uor de studiat, ce permit simularea desfurrii activitii folosind tehnica de calcul electronic. Caracteristicile selectate difer n funcie de scopul urmrit. Pot astfel exista mai multe abstractizri pentru acelai sistem real. n cazul tehnicilor orientate obiect, prin abstractizare se evideniaz caracteristicile eseniale ale unui obiect, cele care-l disting de alte obiecte. Practic, problema se abstractizeaz prin gruparea obiectele n clase. Abstractizarea d putere modelrii i capacitate de generalizare de la cteva cazuri particulare la cazuri similare. Definiiile comune (numele atributelor) sunt memorate o singur dat pentru clas, n loc s fie memorate pentru fiecare instan. Operaiile pot fi scrise o singur dat i toate obiectele beneficiaz de codul reutilizat.

clase i obiecte
O clas de obiecte descrie o mulime de obiecte cu aceleai proprieti (atribute), acelai comportament (operaii) i relaii similare fa de alte obiecte. Fiecare obiect se mai numete instan a clasei. n termeni implementaionali, fiecare obiect conine un pointer la clasa din care provine, deci are acces la toate caracteristicile clasei sale. Clasa servete la definirea i manipularea mulimii instanelor, similar relaiilor din bazele de date relaionale, i amintete noiunea de

77

clas de la modelele semantice, care descrie ns doar structura, nu i comportamentul instanelor. Spre deosebire de bazele de date relaionale, n cazul modelrii orientate obiect nu exist o teorie matematic ce asigur un set standard de operatori. Acetia sunt reprezentai de operaiile definite la nivelul claselor, i pot fi grupai n patru categorii: constructori, destructori, modificatori i selectori. O clas este definit prin: numele clasei atributele, expresie a valorilor diferitelor stri ale instanelor de clas operaiile pentru manipularea instanelor de clase, numite metode. Specificarea metodei poart numele de semntur, iar codul care implementeaz operaiile constituie corpul metodei. Noiunea de clas este mai mult utilizat de faza de execuie, presupunnd dou aspecte: generarea de obiecte i stocarea setului de obiecte care reprezint instanele claselor. Cu ajutorul clasei se descriu obiectele. Obiectul posed propriile lui valori, lista atributelor i metodele fiind gestionate de clas.

3.2.2.2 ncapsulare ncapsularea este un proces de grupare a elementelor unei clase n elemente accesibile din exterior i elemente proprii. Permite separarea aspectului extern, accesibil altor obiecte, de implementarea intern. Ofer posibilitatea de a masca atributele proprii ale unui obiect, precum i modul n care se execut operaiile. Implementarea poate fi astfel schimbat fr a afecta aplicaia. Fiecrei clase i este asociat o mulime de operaii, care constituie interfaa cu utilizatorul, i prin care obiectele acesteia pot fi manipulate. Corespunztor, obiectul este divizat n dou: coninut i interfa. Coninutul, dat de structura i modul de aciune al operaiilor este cunoscut numai de obiectul nsui, neputnd fi accesibil din afar. Interfaa, mulime a

78

atributelor i operaiilor vizibile din exterior, permite schimbul de mesaje ntre obiecte, asigur funcionalitatea modelului. n Conception orientee objets et application [BG94], autorul definete ncapsularea ca fiind procesul de compartimentare a elementelor unei abstracii, afirmnd chiar c prin ncapsulare se separ interfaa contractual a unei abstracii de implementarea sa. n timp ce interfaa privete numai aspectul extern, abstractizare a comportamentului comun al tuturor instanelor clasei, implementarea privete reprezentarea abstraciei i mecanismul ce realizeaz comportamentul dorit, detaliile pe care utilizatorul nu trebuie s le cunoasc. Separarea ntre coninut i interfa permite claselor s ascund detaliile de realizare. Datele ncapsulate sunt protejate de accese nedorite, garantndu-se astfel integritatea lor. Un obiect poate evolua n timp fr a afecta restul sistemului. ncapsularea constituie astfel una din premisele de baz ale reutilizrii. Abordnd construirea modelului din diferite puncte de vedere, Grady Booch afirm c abstractizarea i ncapsularea sunt complementare, prima concentrndu-se asupra aspectului extern, cealalt mpiedicnd s se vad interiorul, acolo unde comportamentul abstractizrii este implementat. Abstractizare evideniaz caracteristicile eseniale ale unui obiect, ncapsularea servete la separarea comportamentului esenial al unui obiect de implementarea sa. Abstractizarea pune bariere explicite ntre diferite abstracii, ncapsularea ascunde toate detaliile unui obiect care nu particip la stabilirea legturilor cu alte obiecte. 3.2.2.3 Ierarhizare Ierarhizarea este o operaia de ordonare a abstraciilor. Ajut la identificarea relaiilor ntr-o ierarhie, la clarificarea i buna nelegere a problemei. Agregarea este o relaie de tip parte-ntreg, n care obiecte care reprezint componente ale unui ntreg, sunt asociate cu ntregul. Agregarea este o form de asociere n care exist un obiect agregat, format din componentele sale, componentele fiind vzute ca parte a
79

agregatului. O aceeai parte poate aparine mai multor agregri. Semantic agregatul este vzut ca un obiect, tratat ca o unitate n multe operaii, dei fizic este format din mai multe obiecte. Agregarea nu este un concept independent, ci o form special de asociere. Adaug conotaii semantice unor anumite cazuri particulare: . Dac dou obiecte sunt legate prin relaia parte-ntreg, avem agregare. . Dac obiectele sunt independente, avem asociere. Generalizarea este o relaie dintre o clas de baz i una sau mai multe clase derivate ale ei. Atributele i operaiile comune sunt grupate n superclas, fiind motenite de clase. n timp ce n cazul agregrii una din clase are un rol predominant n raport cu celelalte, n cazul generalizrii clasele sunt integral coerente, subclasa aducnd eventuale informaii adiionale, specifice. Agregarea implic dou clase, una fiind parte a celeilalte. Generalizarea este un mijloc de structurare a descrierilor pentru o clas. Superclasa i clasa specific proprietile unui obiect, obiectul fiind instan a superclasei i instan a clasei. Amndou dau natere la arbori prin tranzitivitate. Un arbore al agregrii este compus din instane obiect, toate parte al unui obiect compus. Arborele generalizrii este compus din clase care descriu un obiect. Privite amndou drept cazuri speciale de asocieri, agregarea este numit i-relaie, iar generalizarea este numit sau-relaie.

motenire
Partajarea atributelor i operaiilor de-a lungul unei ierarhii ntre clase i subclase este evideniat cu ajutorul conceptului de motenire. Motenirea permite constituirea de noi tipuri de obiecte i clase, evitnd rescrierea i recodificarea. Noua clas poate moteni att operaii (metode), ct i variabile de instan (atribute). n primul caz se poate vorbi de partajarea codului ntre metode (code sharing), iar n al doilea caz, de partajarea structurii ntre atribute (structure sharing). mpreun furnizeaz o puternic strategie de modelare, un mecanism natural de organizare a informaiei, care prezint clasele ntr-un graf de motenire ce permite vizualizarea legturilor dintre ele.
80

Conceperea unei aplicaii const n a grupa informaiile generale n clase care sunt apoi specializate din aproape n aproape n subclase cu comportament particular. n faza de implementare, subclasa este autorizat s redefineasc implementarea. Exemplu: n sistemul informatic privind contractarea i vnzarea produselor, documentele pe cere se consemneaz activitile desfurate sunt contractul i factura de vnzare. Prin generalizare se poate defini o clas DOCUMENT, care are drept atribute NumrDocument i DatDocument. Operaiile sunt: CautDat(NrDoc) i StergeDocument(NrDoc). Clasele CONTRACT i FACTUR motenesc atributele i operaiile clasei DOCUMENT. n plus, clasa CONTRACT are atributele TermenContract i ValoareContract, iar clasa FACTUR are n plus atributul StareFactur.
DOCUMENT NumrDocument DatDocument CautDat(NrDoc) tergeDocument(NrDoc

CONTRACT TermenContract Valoarecontract

FACTUR StareFactur

Motenirea ntre clase poate fi privit sub dou aspecte: structural, cnd o clas are atribute motenite de la superclas. Instanele unei clase trebuie s rein acelai tip de informaie ca instanele de la supraclasa sa. Metodele din clas pot manipula variabilele de instan (atributele) din superclas fr restricii. n cazul n care o clas are mai multe superclase, atributele unei clase sunt reuniunea atributelor superclaselor sale, plus cele specifice ei. comportamental, cnd o clas are metode motenite de la superclas. Comportamentul este specificat n metodele superclasei i n metodele
81

specifice ei.. Metodele sunt operaii care pot regsi sau actualiza starea unui obiect. Sunt parte a interfeei ce manipuleaz instanele clasei. Similar cu aspectul structural, n cazul existenei mai multor superclase, colecia de metode aplicabile instanelor unei clase este reuniunea metodelor definite n superclase, plus cele specifice ei. Motenirea poate fi implementat static sau dinamic. Motenirea static presupune adugarea cmpurilor motenite. n timp ce execuia este rapid neimplicnd parcurgerea legturilor de motenire, redefinirea unei clase este dificil, implicnd actualizarea tuturor subclaselor. Motenirea dinamic se realizeaz fr copierea cmpurilor motenite, i presupune parcurgerea legturilor de motenire. Actualizarea este mai uoar, dar execuia este mai puin eficient. Generalizarea i motenirea sunt abstracii puternice folosite pentru transmiterea similaritilor de la o clas la alta, pstrnd totui diferenele dintre acestea. Sunt tranzitive, traversnd un numr arbitrar de nivele. Subclasele motenesc trsturile superclasei, dar pot avea propriile lor atribute i operaii. n timp ce generalizarea se refer la relaia dintre aceeai clas i subclasele sale, motenirea se refer la mecanismul de a transmite atribute i operaii de-a lungul unei relaii de generalizare. n implementare, motenirea este sinonim cu noiunea de reutilizare a codului. Trsturile reutilizabile sunt grupate n superclase. Fiecare programator ncearc gruparea claselor cu trsturi comune i folosirea secvenelor de cod comune, implementnd subclase proprii specifice aplicaiei.

polim orfism
n strns legtur cu motenirea, polimorfismul definete caracteristica unei operaii de a se comporta n mod diferit n funcie de clasa de obiecte creia i aparine. Polimorfismul permite invocarea pentru obiecte de diferite tipuri a operaiilor cu acelai nume (semntur), dar semantic i implementare diferit. La primirea mesajului, stabilirea metodei care se aplic se face n mod dinamic, n funcie de clasa obiectului n cauz. Instane ale unor clase diferite pot fi adresate uniform, primind aceleai mesaje, dar manifest comportamente diferite.
82

3.3 UML limbaj standard de modelare

3.3.1 Descrierea limbajului Unified Modeling Language (UML) este succesorul unui val de metode de analiz i proiectare orientate obiect, aprute la sfritul anilor 80 i nceputul anilor 90. Este un limbaj unificat de modelare, rezultatul unui proces de introducere a standardizrii n analiza i proiectarea orientate obiect. Este punctul de pornire n dezvoltarea viitoarelor limbaje grafice. Contribuii eseniale n definirea limbajului unificat de modelare au avut Grady Booch, Jim Rumbaugh i Ivar Jacobson. Grady Booch, cercettor tiintific la Rational Software Corporation a construit numeroase exemple pentru dezvoltarea sistemului Ada. A definit o metod de analiz i proiectare a sistemelor orientate obiect Object Oriented Design (OOD). Jim Rumbaugh a condus o echip de cercetare n laboratorul General Electric, punnd bazele metodei Object Modeling Technique (OMT). Ivar Jacobson, n urma experienei dobndite n domeniul telefoniei, a introdus pentru prima dat diagramele de utilizare, n lucrarea ObjectOriented Software Engineerig - A Use Case Driven Approach. Metodele existente n acea perioad erau similare, dar conceptele de baz apreau cu mici diferene de notaii ce ddeau natere la confuzii ntre utilizatori. La OOPSLA95 Grady Booch i Jim Rumbaugh au prezentat public versiunea 0.8 a documentaiei pentru o metod standard de modelare, Unified Method (UM). Metoda consta ntr-un limbaj de modelare i un proces. Limbajul de modelare era (n special cel grafic) notaia folosit de metod. Procesul exprima paii fcui. Studiul acestei metode i-au determinat s considere c partea de proces a metodei este nesemnificativ, c nu e nevoie i de un proces standard, dei armonizri n vocabular sunt necesare. n acelai timp, au considerat c un limbaj de modelare standard este necesar i important. i

83

astfel, ncepnd cu 1966, cei doi mpreun cu Ivar Jacobson, au lucrat pentru un limbaj de modelare standard, Unified Modeling Language (UML). La 17 noiembrie 1997, Object Management Group (OMG) a anunat adoptarea specificaiei UML ca limbaj standard de modelare. Afirmnd c UML este experien, experiment i adoptare gradat a standardului care dezvluie adevratul potenial al sistemului i permite realizarea beneficiilor, au definit UML ca un limbaj de modelare pentru a specifica, vizualiza, construi i documenta componentele unui sistem dinamic, n care o metod este aplicat ca un proces pentru a defini i dezvolta sistemul. Mai mult, au demonstrat c UML: este limbaj folosit pentru comunicare, mijloc de a prezenta cunotine (semantic) despre sistemul studiat i de a exprima cunotinele (sintactic) privind sistemul studiat n scopul comunicrii. este limbaj de modelare ce accentueaz nelegerea sistemului prin definirea unui model al su i al contextului n care se dezvolt. mbin teoria sistemele informatice i practica domeniilor de activitate concrete; specific cerinele sistemului i modul n care pot fi ele realizate. aplicat n prezentare, poate fi folosit pentru vizualizarea sistemului nainte de a fi realizat. aplicat n construirea sistemului, poate fi folosit ca ghid n realizarea unui sistem similar modelului. aplicat n documentarea sistemului poate fi folosit pentru includerea cunotinelor despre sistem n timpul ciclului de via. Pentru a demonstra c UML nu privete doar sistemele orientate obiect, putnd fi aplicat sistemelor n general, n The Visual Modeling of Software Architecture for the Enterprise[BG99], Grady Booch a artat c modelarea este partea central a activitii care conduce la proiectarea eficient a oricrui sistem informatic. Indiferent de domeniu, pentru rezolvarea problemelor din sistemele reale se construiesc modele pentru o mai bun nelegere a sistemului, pentru vizualizarea i controlul arhitecturii sistemului. Vizualizarea, specificarea, construirea i documentarea permit ca el s fie vzut din diferite perspective. Analiza, dezvoltarea, interogrile i testele refer sistemul n diferite etape. UML ajut programatorii s

84

nglobeze deciziile semnificative luate la nivel de sistem i proiectanii s controleze dezvoltarea iterativ a sistemului n ciclul su de via. 3.3.2 Definirea limbajului Pentru definirea limbajului sunt folosite trei documente: UML Semantics, UML Notation Guide i UML Extetions. a) UML Semantics este un model logic, cuprinznd semantica declarativ fr detaliile de implementare, este documentul principal care descrie limbajul n trei seciuni: Sintaxa abstract (Abstract syntax), n care diagramele claselor UML sunt folosite pentru a defini metamodelul UML, conceptele sale (metaclase), relaiile i restriciile. Sunt incluse i definiiile conceptelor. Metamodelul, modelul elementelor modelate, este prezentat ca un limbaj pentru specificarea modelului obiect. Scopul metamodelului UML este s furnizeze un singur, comun i definitiv sens al sintacticii i semanticii elementelor UML. Regulile de corectitudine (Well-formedness rules), n care sunt definite regulile i restriciile modelului. Object Constraint Language (OCL) este un limbaj specific care folosete logica simpl pentru specificarea proprietilor invariante ale sistemului i relaiile. Este prima contribuie IBM la UML, dezvoltat n cadrul limbajului de modelare pentru sistemele informatice din mediile de afaceri. Furnizeaz faciliti pentru formalizarea semanticii limbajului, pentru exprimarea structurii modelului i a restriciilor. Semantica (Semantics), n care semnificaia modelului i cerinele suplimentare, non-funcionale, sunt specificate ca cerine textuale. n descrierea semanticii sunt folosite tehnici formale, definiiile sunt prezentate riguros matematic i fr ambiguiti, folosind elemente de calculul predicatelor. Totui valoarea acestor definiii nu are neles universal. Chiar dac se pot demonstra specificaiile matematice, nu exist ci de a proba aceste specificaii n contact cu cerinele reale din sistem. b) Notaia este partea grafic vzut n model, este sintaxa limbajului de modelare. Notaia din diagrama claselor definete modul n care sunt reprezentate conceptele de clas, asociere i multiplicitate.
85

UML Notation Guide este un document utilizat practic n toate metodele de analiz i proiectare. Este structurat n conformitate cu documentele principale (diagramele) ce pot fi construite n procesul de aplicare a metodei. UML Notation Guide descrie notaiile UML i furnizeaz exemple. Face sumarul semanticii UML, definiiile fiind ns n UML Semantics. Este o reprezentare la nivelul modelului utilizatorului, care e semantic o instan a metamodelului UML. c) UML Extensions cuprinde definirea extensiilor UML care sunt posibile prin folosirea stereotipurilor (Stereotypes), valorilor etichetate (Tagged values) i restriciilor (Constraints). Sunt definite dou extensii: UML Extension for the Objectory Process for Software Engineeering i UML Extension for Business Modeling. Se apeleaz la extensii doar cnd este necesar introducerea de noi notaii i terminologii. Extensiile nu sunt universal acceptate, nelese i suportate. Chiar fr extensii, UML este complet aplicabil pentru multe tipuri de sisteme, domenii, metode sau procese. Definete un set de concepte pentru dobndirea, partajarea i utilizarea cunotinelor mpreun cu mecanismele de extensibilitate. Ca limbaj de modelare standardizat este deschis la extensibilitate pe scar larg, permite mbuntirea tacticii i strategiei pentru creterea valorii prin calitate i reducere de cost. Permite practicienilor creterea eficienei avnd consisten, standardizare i instrumente suportate de limbaj de modelare.

3.4 Diagrame UML

Diagramele UML sunt mijloacele de reprezentare i vizualizare a elementelor de modelare. n acest subcapitol diagramele UML sunt construite cu OBJECTEERING, aflat pe Internet la adresa www.objecteering.com.

86

In funcie de rolul lor n specificarea aplicaiilor, diagramele UML se pot clasifica n: Statice (structur) Diagrame de cazuri de utilizare Diagrame de clase Diagrame de obiecte Diagrame de componente Diagrame de implementare Dinamice (comportament) Diagrame de colaborare Diagrame de secvene Diagrame de stare/tranziie Diagrame de activiti

3.4.1 Diagrama cazurilor de utilizare Funcionalitatea complet a sistemului este dat de diagrama cazurilor de utilizare, care include actorii i cazurile de utilizare. Fiecare diagram conine un set complet de evenimente iniiate de unul sau mai muli actori i specific interaciunea care are loc ntre actori i sistem. Cazurilor de utilizare descriu comportamentul unui sistem din punctul de vedere al utilizatorului, care poate astfel s-i structureze cerinele, s defineasc modul n care va interaciona cu sistemul pentru a obine rezultatul dorit. Precizeaz limitele sistemului, relaiile dintre sistem i mediu, ceea ce face parte din sistemul de dezvoltat i ceea ce nu face parte din el. Pentru descrierea unui caz de utilizare, trebuie prezentate variantele de execuie posibile pentru secvena de aciuni corespunztoare acestui caz, aa zisele scenarii. Un scenariu este deci o instan a unui caz de utilizare, un flux de evenimente. Un scenariu este creat de fiecare dat cnd un actor declaneaz un caz de utilizare : acest scenariu va urma un drum particular n descrierea unui caz de utilizare. Un scenariu nu conine ramuri de tipul dac condiia X este ndeplinit, atunci , pentru c n timpul execuiei condiia este sau adevrat sau fals, dar ntotdeauna va avea o valoare.

87

Nu este posibil s descriem un caz de utilizare scriind toate scenariile ; se descriu cele reprezentative i mai ales cele care comport un risc. In practica modelrii exist dou nivele de descriere : 1 descrierea general a unui caz de utilizare evideniind diferite drumuri ce pot fi reunite n acelai caz 2 descrierea celor mai semnificative scenarii Ca abstracii ale dialogului ntre actori i sistem, cazurile de utilizare descriu interaciuni poteniale fr a intra n detaliile fiecrui scenariu. Specific doar cine declaneaz evenimentele i ce aciuni determin, fr a cuprinde detalii funcionale. Un caz de utilizare este iniiat ntotdeauna de un actor i exprim o funcie a sistemului, declanat ca rspuns. Actorii sunt elementele din sistem care genereaz sau primesc evenimente. Se determin dintre utilizatorii direci ai sistemului, dintre cei care-l interogheaz sau exploateaz. Alturi de utilizatori, pot fi actori alte sisteme sau chiar un eveniment. Reprezentare: Actor participare caz de utilizare Livrare marf Furnizor Aceeai persoan poate juca rolul mai multor actori, iniiind mai multe cazuri de utilizare. Exemplu: gestionarul unui depozit recepioneaz marfa i o nregistreaz n fia de magazie: Receptioneaz marfa Gestionar Inregistreaz marfa

88

Un caz de utilizare poate avea mai muli actori, fiecare cu rolul su Exemplu: la ncheierea unui contract pentru livrarea mrfurilor particip clientul i inginerul de vnzri. Client Incheiere contract UML recunoate patru categorii de actori: actori principali, persoane care utilizeaz funciile principale ale sistemului; actori secundari, persoane care efectueaz sarcini administrative sau de ntreinere; echipamente externe, echipamentele care fac parte din domeniul aplicaiei i care trebuie s fie utilizate; celelalte sisteme, categorie care grupeaz sistemele cu care viitorul sistem trebuie s interacioneze. Dup definirea actorilor i a cazurilor de utilizare este util restructurarea mulimii cazurilor de utilizare prin evidenierea comportamentului partajat, a cazurile particulare i a relaiei de generalizare. UML definete trei tipuri de relaii ntre actori i cazurile de utilizare: Relaia de comunicare: actorul particip direct la cazul de utilizare; Exemple: clientul achit, funcionarul comercial recepioneaz marfa Relaia de incluziune: o instan a cazului de utilizare surs include i comportamentul descris de un alt caz de utilizare. Acest tip de relaie se folosete pentru simplificarea diagramei cazurilor de utilizare n situaii complexe. Exemple: n diagrama cazurilor de utilizare corespunztoare aprovizionrii cu mrfuri (fig 2.1), cazul de utilizare Incheie contract - include i cazul de utilizare - Semneaza contract cazul de utilizare Livrare marfa - include i cazul de utilizare Receptioneaza marfa
89

Inginer de vnzri

cazul de utilizare Intocmeste Nir- este inclus n cazul de utilizare Receptioneaza marfa cazul de utilizare ncheiere contract- definit n sistemul informatic privind aprovizionarea cu mrfuri include i cazul de utilizare -Semnare contract- din acelai sistem informatic. Relaia de extensie: cazul de utilizare surs poate fi extins cu comportamentul unui alt caz de utilizare destinaie. Prin relaia de extensie, care specific o posibilitate, o opiune, poate fi introdus, sub forma unui caz de utilizare distinct, un nou caz de utilizare. Exemplu: n diagrama cazurilor de utilizare corespunztoare aprovizionrii cu mrfuri (fig 2.1 ), cazul de utilizare Receptioneaza marfa poate fi extins cu cazul de utilizare Returneaza marfaDescrierea unui caz de utilizare const n unul sau mai multe scenarii, numite instane ale cazului de utilizare.

Aprovizionare Incheie cont ract <<include>>

Semneaza cont ract Furnizor Livreaza marfa <<include>>

Receptioneaza marfa <<extend>> <<include>> Returneaza marfqa

Gestionar

Intocmeste NIR

Fig 3.1

90

n majoritatea lucrrilor din literatura de specialitate, autorii propun ca descrierea cazurilor de utilizare s cuprind: denumire sau titlu scop actori punct iniial punct final descriere derulare rezultat msurabil Exemplu: Considerm cazul de utilizare Analiza documentaiei depuse din activitatea de acordare a unui credit pentru o firm, prezentat n 2.3.1.2.

PCredit

Analiza documentatiei depuse Inspector de credit

Fig.3.2 Descrierea cazului de utilizare -Analiza documentaiei depuse- este: Denumire : Analiza documentaiei depuse Scop : Calcularea coeficientului de risc Actori: Inspectorul de credite Punct iniial: Inspectorul de credite solicit documentaia depus de firm
91

Punct final: Obinerea valorii coeficientului de risc Descriere derulare: inspectorul de credite solicit documentaia depus de firm; dac firma este un client al bncii se verific informaiile existente despre client; dac nu, baza de date este actualizat cu datele generale ale clientului; din documentaie se selecteaz informaia care contribuie la calcularea coeficientului de risc; n cazul unui coeficient de risc ridicat, cererea este respins; se analizeaz suma cerut de firm prin comparaie cu posibilitile bncii de a acorda creditul solicitat; dac rezultatul este favorabil (nivel de responsabilitate < 100.000.000) cererea de credit este admis i nregistrat; Rezultat msurabil: Cererea de credit este admis i nregistrat, sau respins Dup prezentarea scenariului anterior, cazul de utilizare Analiza documentaiei depuse poate fi delaliat ca n figura 3.2.1

Fig. 3.2.1 Obiectele i interaciunile dintre ele sunt prezentate n diagrama de secvene (fig. 3.3), despre care vom vorbi mai trziu.
92

Insp ector: solicita situatie financiara

Client :

dep une situatie financiara

Fig.

verifica

calculeaza

analizeaza

[conditii indep linite]cerere admisa

[nivel resp onsabilitate < 100.000.000]cerere resp insa

Fig 3.3 3.4.2 Diagrama claselor i diagrama obiectelor Clasa corespunde semantic entitilor din sistemul real. O clas desemneaz un grup de obiecte care au proprieti similare (atribute), un comportament comun (operaii), relaii comune cu alte obiecte i o aceeai semantic. Obiectele sunt considerate instane ale clasei, fiind construite pornind de la clase, printr-un proces de instaniere. Un obiect are o identitate ce-l distinge de celelalte obiecte i este caracterizat printr-un ansamblu de atribute i un anumit comportament. Structura sistemului este reprezentat cu ajutorul a dou tipuri de diagrame: diagrama claselor i diagrama obiectelor. Diagrama claselor prezint structura static a sistemului, privit ca ansamblu al claselor de obiecte i al relaiilor dintre clase. n strns legtur cu ea, diagrama obiectelor evideniaz obiectele i legturile

93

dintre ele. Diagramele obiectelor prezint cazuri particulare, faciliteaz nelegerea structurilor de date complexe. Reprezentarea unei clase presupune specificarea atributelor ce-i definesc structura, a operaiilor ce-i definesc comportamentul i a relaiilor cu celelalte clase. n UML, o clas este reprezentat printr-un dreptunghi n care se specific numele clasei, atributele i operaiile.

Nume clas Atribute Operaii

Furnizori cod nume CitesteCod ScrieNume

Desemnarea obiectelor se face prin nume individuale sau prin nume generice n locul numelor individuale; numele obiectului este subliniat. 401_furnizor : Furnizori

Fiecare atribut poate lua o valoare dintr-un domeniu de definiie specificat n reprezentarea clasei. Implicit, atributele sunt ncapsulate n obiecte, interaciunile avnd loc numai prin intermediul operaiilor. Nivelul de vizibilitate al fiecrui atribut (privat, protejat i public) se precizeaz n reprezentrile grafice ale claselor cu ajutorul caracterelor -, #, respectiv +. Operaiile sunt reprezentate mpreun cu numrul, ordinea i tipul argumentelor necesare definirii aciunii lor. n cazul cnd operaia este o funcie, se specific i tipul valorii returnate. Asocierea este o conexiune semantic bidirecional ntre clase. Ea este reprezentat printr-o linie continu ntre clasele implicate, de-a lungul creia se scrie numele asocierii. Dac sensul de transmitere a mesajelor este unic, acesta se evideniaz printr-o sgeat de la emitor la receptor.

94

Dac ntre dou clase exist o singur asociere, numele asocierii este suficient pentru a preciza relaia. Atunci cnd ntre dou clase exist mai multe asocieri, se folosete noiunea de rol, care exprim felul n care o clas vede o alt clas n cadrul unei asocieri. Fiecare rol al unei asocieri evideniaz ordinul de multiplicitate care arat cte obiecte ale unei clase pot fi legate unui obiect al celeilalte clase. Dintre proprietile unei asocieri, multiplicitatea este cel mai des ntlnit n diagramele de structur. Este determinat de context i evideniaz numrul instanelor unei clase ce se pot asocia cu o singur instan a altei clase. Multiplicitatea restrnge numrul de obiecte ce se afl n legtur, de aceea, cnd mai multe instane ale unei clase sunt legate la o instan a clasei asociate se folosete cazul general (n). n aplicaii cea mai important distincie se face ntre multiplicitatea zero i multiplicitatea mai muli. n diagrama claselor, multiplicitatea se specific printr-o cifr urmat eventual de semnul +, printr-un interval sau printr-o succesiune de cifre. Astfel, 1 nseamn c o instan a unei clasei este legat la o singur instan a clasei asociate; 1+ nseamn c una sau mai multe instane ale unei clase sunt legate cu o instan a clasei asociate; 2-5 nseamn c dou pn la cinci instane ale unei clase sunt legate cu o instan a clasei asociate; 1,2,3 nseamn c una, dou sau trei instane ale unei clase sunt legate cu o instan a clasei asociate. Asocierile pot fi caracterizate prin atribute i pot avea propriile lor operaii. n acest caz se reprezint ca o clas, ce are acelai nume cu asocierea i se conecteaz printr-o linie ntrerupt de asociere. Exemplu: n cazul n care ntr-o societate comercial se contracteaz produse, preul unitar i cantitatea depind de produs dar i de condiiile specificate la ncheierea contractului, sunt deci atribute ale asocierii. Reprezentarea clasei asociere este:

95

contracteaz Produse contracteaz cantitate pre unitar AfisPret() Exemplu: Diagrama claselor n cazul sistemului informatic pentru contractarea i aprovizionarea cu mrfuri, activitate descris n capitolul anterior, este: Contracte

Fig. 3.4

96

Agregarea i generalizarea, ca forme de asociere prezente n procesul de ierarhizare a claselor, sunt reprezentate n diagramele de structur cu simboluri specifice. Agregarea, ca relaie de tip parte-ntreg, evideniaz o asociere ntre o clas cu rol predominant (clasa agregat) i componentele sale (agregate). Relaia de agregare este o relaie ntre clasa ntregului i clasa unei componente. Unui ntreg cu mai multe componente i corespund mai multe relaii de agregare. Definind apartenena componentei la ntreg se poate specifica i multiplicitatea fiecrei componente fa de ntreg. Acest mod de a defini agregarea i confer statutul de form special a asocierii. Agregarea este reprezentat printr-un romb plasat la captul de asociere al clasei agregat. Exemplu: n figura 3.4: ntre clasa CContract i clasa MarfaContract este o relaie de agregare ntre clasa CFactura i clasa MarfaFactura este o relaie de agregare Generalizarea, ca relaie ntre o clas i subclasele sale, este prezent ori de cte ori se semnaleaz de-a lungul unei ierarhii proprieti comune sau operaii ce evideniaz comportament comun. Este reprezentat printr-un triunghi ce puncteaz spre superclas. Exemplu: se consider clasele: Factura, cu: atribute: numr factur, data facturii, cota Tva operaii: IncarcaDate, AfiseazaData, ValoareFactura Nir, cu : atribute:numr Nir, data Nir, cod gestiune operaii:IncarcaDate,AfiseazaData, AfisezGestionar Se observ c cele dou clase au atribute i metode comune. Se poate astfel construi o superclas, Documente, care s conin atributele si metodele comune, motenite de subclasele Factura i Contract. (fig. 3.5)

97

Fig.3.5 n finalul acestui subcapitol prezentm n figura 3.4 bis diagrama claselor n cazul sistemului informatic privind aprovizionarea cu mrfuri
CContract NrContract : integer DataCont ract : integer TermenContract : integer IncarcaContract() ConsultaContract() ValoareContract()

contracteaza CFurnizor * FDenumire : string FLocalitate : string AdaugaFurnizor() AfiseazaLocalitate() M odificaFurnizor()

contineC 1..* MarfaContract CantContract : integer PretContractttribute : integer ValM arfaContract() corespundeC CMarfa

corespunde * livreaza CFactura * NrFactura : integer DataFactura : string TvaFactura() ValFactura()

DenumireM arfa : string UM M arfa : string M odificaDenumire()

corspundeF contineF * 1..* MarfaFactura CantFactura : real Pretfactura : real ValM arfaFactura()

fig 3.4 bis

98

3.4.3 Diagrama de colaborare Diagrama de colaborare prezint un grup de obiecte i interaciunile dintre ele. Obiectele i legturile dintre ele sunt reprezentate ca n diagramele obiect. Mesajele schimbate ntre obiecte sunt reprezentate de-a lungul legturilor. Ordinea de trimitere a diferitelor mesaje este indicat printr-un numr amplasat la nceputul mesajului. Numele mesajului corespunde unei operaii definite n clasa obiectului destinatar al mesajului, argumentele sale corespunznd parametrilor actuali ai operaiei. Argumentele mesajelor sunt reprezentate n diagrame fie n pseudocod fie n sintaxa limbajului de programare. De exemplu (fig.3.6), diagrama de colaborare definit pentru a evidenia aprovizionarea cu materiale i pstrarea lor n gestiune este:
1:se primete factura Materiale 2: depozitare (NRCD) Furnizor 3: transfer(BPTR) Gestiune

Fig3.6 Pentru a evidenia declanarea interaciunilor de ctre un element extern sistemului, n diagramele de colaborare pot fi cuprini actori. Fr a se intra n detaliile obiectelor de interfa cu utilizatorul, n acest caz primul mesaj de interaciune este trimis de actor. n faza de analiz, diagramele de colaborare urmresc scenarii definite pornind de la cazurile de utilizare. Exemplu: n sistemul informatic privind vnzarea produselor, se poate defini o diagram de colaborare ntre obiectele claselor Clieni, Facturi i Documentencasare, pentru a reprezenta modul n care au fost ncasate facturile emise pentru clieni (fig.3.7 )
99

Clienti DenumireClient : string ContBanca : integer *

Facturi NrFactura : int eger Datafactura : string StareFactura : char ValoareFactura()

* DocIncasare IdDocument : integer Suma : real IdClient : undefined AfiseazaClient () Afiseaza Factura()

Fig 3.7 n faza de proiectare, diagrama de colaborare furnizeaz un punct de vedere complet al dinamicii sistemului, evideniind comportamentul claselor ca rspuns la apariia unor evenimente, noi operaii i clasele crora le aparin. Colaborrile definite pentru a urmrii anumite cerine ale utilizatorilor pot conduce la apariia sau dispariia unor obiecte, la modificarea proprietilor unui obiect, la actualizarea restriciilor de integritate sau la modificarea relaiilor dintre obiecte. n cazul n care obiecte aparinnd aceleiai clase particip la colaborri diferite, n funciile de scenarii diferite ale aceluiai caz de utilizare, se pot specifica mpreun cu mesajele condiii ce aduc detalii suplimentare pentru implementare. .

100

3.4.4 Diagrama de secvene Diagrama de secvene ilustreaz interaciunile dintre obiecte din punct de vedere temporal. Este ntocmit pentru scenarii ale unui caz de utilizare, arat obiectele i interaciunile dintre ele de-a lungul unui scenariu. n diagrama de secvene apar doar obiecte ale cror clase sunt reprezentate n diagrama claselor i ntre care au fost definite relaii. Mesajele corespund operaiilor prin care obiectele comunic. Reprezint apeluri ale operaiilor descrise la nivelul claselor. Pentru fiecare mesaj, n clasa obiectului destinatar trebuie s existe o operaie corespunztoare, reacia obiectului la mesajul primit. Fiecare obiect este reprezentat printr-un dreptunghi n care se nscrie numele. Linia de via a obiectului se specific printr-o bar vertical. Mesajele sunt reprezentate prin sgei orizontale de la emitor la receptor. Convenind c timpul se scurge de sus n jos, ordinea de trimitere este dat de poziia pe axa vertical. mpreun cu diagramele de colaborare, diagramele de secvene alctuiesc aa zisele diagrame de interaciune, ce evideniaz mesajele trimise ntre obiecte. n timp ce o diagram de secvene se construiete pentru un singur scenariu n care pot fi implicate mai multe obiecte, diagramele de colaborare conin un grup restrns de obiecte, ce pot fi implicate n mai multe scenarii. Exemplu: n sistemul informatic privind aprovizionarea cu mrfuri, succesiunea operaiilor de la formularea unei cereri de marf i pn la livrarea efectiv a mrfii poate fi prezentat n diagrama de secvene din figura 3.8

101

Aprovizionare: CereMarfa

Furnizor:

Factura:

Marfa:

Confirma TrimiteFactura

LivreazaMarfa

fig 3.8 3.4.5 Diagrama de stri Diagrama schimbrilor de stare descrie comportamentul obiectelor unei clase prin stri i evenimente. Se construiete doar pentru clasele cu comportament interesant dinamic, completnd descrierea unui caz de utilizare. Diagramele de stri modeleaz ciclul de via al unei singure clase, evideniind i eventualele evenimente trimise de ea la alt clas din sistem. Fiecare obiect este la un moment dat ntr-o stare particular. Starea este definit de valorile atributelor i de legturile sale cu alte obiecte. Este un rspuns la apariia unui eveniment extern. Exemplu: n sistemul informatic privind gestiunea stocurilor, starea curent a unui tip de material poate fi: n aprovizionare, depozitat n gestiune, sau n consum
102

la secie. Este determinat de valoarea atributului document, ce conine numele documentului pe care materialul este consemnat la un moment dat. Dac documentul este Nir, clasa Material este asociat cu clasa Gestiune prin asocierea Depozitat n.

Gestiune

<Depozitat n 1..*

Material document

n diagrama de stare sunt descrise operaiile ce reprezint rspuns la evenimente externe clasei. Corespund unor operaii descrise n diagrama claselor, vizibile din afara clasei (publice). Starea este descris printr-un nume care o identific i o list de aciuni/activiti ce sunt executate la apariia unui eveniment. ntr-o diagrama de stare exist o singur stare iniial i una sau mai multe stri finale, determinate de condiiile de apariie ale evenimentelor. Tranziia de stare reprezint schimbarea strii datorit unui eveniment. Evenimentul corespunde apariiei unei situaii date n domeniul problemei. El nu are durat. Trecerea dintr-o stare n alta este instantanee, sistemul fiind ntotdeauna ntr-o stare cunoscut. Tranziia de stare este reprezentat printr-o sgeat de la starea surs la starea destinaie etichetat cu: numele evenimentului care a generat tranziia condiia de apariie a evenimentului aciunea ce se execut la apariia evenimentului

103

Exemplu: n sistemul informatic privind aprovizionarea, diagrama de stri pentru o factur este cea din figura 3.9: acceptare Sosita Do: ConsultaFz : VerificaFz Inregistrata Do: IncarcaDateFz : IncarcaDateFact [sume OP<ValFact] In curs de achitare Do: CalcValFact :AfisezAchitat : SumePartiale [sume OP=ValFact] Achitat Do: ListaSume : AfiseazaData : SeteazaStare fig 3.9 3.4.6 Diagrama de activiti Diagrama de activiti descrie comportamentul sistemului introducnd elemente de implementare. Ataat unui caz de utilizare, i detaliaz aciunile i procesele corespunztoare. Ataat unei clase cu comportament dinamic semnificativ, descrie tranziia de la o stare la alta sau algoritmul de prelucrare al operaiilor. Folosete urmtoarele elemente: aciune, tranziie, decizie.

livrare

achitare parial

104

Aciunea corespunde unei etape n execuia unui algoritm. Fiecare operaie, privit ca o nlnuire de aciuni, poate fi detaliat n operaii elementare. Pentru simplificarea diagramelor, aciuni omogene pot fi grupate n subactiviti. Tranziia de la o aciune la alta se reprezint printr-o sgeat etichetat eventual cu: numele evenimentului care determin tranziia condiia de apariie a evenimentului Decizia indic ramificarea unei tranziii n funcie de ndeplinirea unei condiii. n faza de analiz, diagramele de activiti completeaz descrierea cazurilor de utilizare. Pentru prezentarea derulrii aciunilor sunt folosii termeni apropiai utilizatorului. Exemplu: diagrama de activiti din figura 3.10 evideniaz activitile desfurate pentru aprovizionarea cu marf i nregistrarea ei n gestiune. Poate folosi pentru completarea descrierii cazurilor de utilizare din sistemul informatic privind aprovizionarea, sau poate nsoi diagrama de secvene din cadrul aceluiai sistem informatic.

se inregistreaza factura

se verifica marfa

marfa inregistrata in Nir

marfa refuzata

se intocmeste OP

factura stornata

Fig 3.10
105

n faza de proiectare, diagramele de activiti apar ataate unei clase i conin elemente de implementare ale operaiilor descrise n clase. Aciunile pot fi descrise n limbaj natural, n pseudocod sau ntr-un limbaj de programare (C++, Visual Basic). Echivalente schemelor logice utilizate n programarea structurat, diagramele de activiti conin structurile fundamentale de programare: liniar, repetitiv sau alternativ. n cazul unei clase cu comportament dinamic semnificativ, pentru cazul n care modificrile de stare au o determinare intern, rezultat din efectuarea sau ncheierea unor operaii, starea este descris printr-o list de aciuni/activiti, ce se execut la apariia unui eveniment. Tranziia de la o stare la alta este determinat de ncheierea acestor aciuni sau subactiviti (tranziii interne). n aceste cazuri, diagramele de activiti nsoesc diagramele de stare.

3.5 Modelul sistemului real i diagramele UML

Fiecare tip de diagram red un anumit aspect al sistemului modelat: structura static, interaciunile ntre obiecte, componentele fizice ale unei aplicaii, interaciunile dintre utilizatori i sistem. mpreun constituie un model al lumii reale, vzut din puncte de vedere diferite i n momente de timp diferite.

diagramele prezint structura i comportamentul sistemului

Structura sistemului este evideniat n diagrama claselor i diagrama obiectelor. Acestea conin clase i relaii dintre ele, sau obiecte i legturile dintre ele, atunci cnd comportamentul obiectelor individuale impun modificri de structur. n acest ultim caz, structura este evideniat n plus prin diagramele de colaborare. Pentru o clas, simularea comportamentului nseamn prezentarea strilor posibile i a evenimentelor care determin tranziia de la o stare la alta. Se realizeaz cu ajutorul diagramei de stri, care cuprinde i eventualele restricii aprute pe parcursul nlnuirii stare-eveniment-stare.

106

n cele mai multe situaii, modificrile de stare sunt determinate de evenimente survenite n afara obiectului i la care acesta reacioneaz. n cazul n care modificrile au o determinare intern, rezultat din efectuarea sau ncheierea unor aciuni proprii unei stri, pentru reprezentarea comportamentului se definesc n plus diagrame de activiti. Pentru sistem, simularea comportamentului nseamn evidenierea interaciunilor dintre clase i obiecte. Se realizeaz cu ajutorul a trei tipuri de diagrame: de colaborare, de secvene i de activiti. Aceste diagrame prezint schimbul direct de mesaje, prin definirea unor asocieri ntre clase. Pentru fiecare mesaj, n clasa destinatar trebuie s existe o operaie corespunztoare, reacia obiectului la mesajul primit. n timp ce diagrama de activiti descrie un caz de utilizare, diagramele de secvene i de colaborare sunt ntocmite pentru scenarii ale unui caz de utilizare, arat clasele i interaciunile dintre ele de-a lungul unui scenariu. Pentru clasele cu comportament dinamic semnificativ, diagrama de stri completeaz descrierea unui caz de utilizare.

diagramele urmresc funcionalitatea sistemului i cerinele utilizatorilor

Definirea cerinelor funcionale ale sistemului sunt evideniate n cazuri de utilizare, ce corespund unor aciuni ntreprinse de o anumit entitate (actor) pentru un grup de utilizatori. Prin evidenierea cazurilor de utilizare se delimiteaz domeniul de studiu, se stabilete o legtur direct ntre utilizatori i analitii de sistem. Funcionalitatea ntregului sistem este dat de mulimea cazurilor de utilizare, grupate ntr-o diagram a cazurilor de utilizare. Diagrama cazurilor de utilizare, reprezentare a legturii ntre actori i cazurile de utilizare corespunztoare, constituie o descriere funcional a cerinelor, structurat n raport cu unul sau mai muli actori. n etapa definirii cazurilor de utilizare nu exist obiecte. Trecerea la o structur obiect se face determinnd obiectele care colaboreaz pentru a obine funcionalitatea descris de diferitele cazuri de utilizare. Pentru aceasta se urmresc diferite scenarii posibile, privite ca instane ale cazurilor de
107

utilizare. Se obin diagrame obiect i diagrame de secvene. Pentru cazurile algoritmilor compleci se definesc diagrame de stare i diagrame de activiti. Abordnd modul n care funcionalitatea sistemului este realizat cu ajutorul diagramelor UML, muli autori consider c exist dou importante diagrame: diagrama cazurilor de utilizare i diagrama claselor. Cerinele utilizatorilor se regsesc n diagrama cazurilor de utilizare. Funcionalitatea sistemului exprimat n aceste cerine este transformat de analitii de sistem ntr-un model alctuit din clase i relaii ntre ele. Celelalte diagrame sunt subordonate diagramei claselor i folosesc elemente i instrumente ale metodologiei orientate obiect pentru a completa modelul claselor: diagramele de activiti i de stri aduc detalii suplimentare privind comportamentul obiectelor din clase. diagramele de colaborri i de secvene detaliaz interaciunea ntre clase. diagramele de activiti cuprind elemente necesare pentru implementarea claselor.

diagramele conduc la modele statice, dinamice i funcionale ale sistemului real

Diagrama cazurilor de utilizare asigur legtura ntre cerinele utilizatorilor i realizarea acestora prin intermediul abstraciilor definite i evideniate n diferite alte diagrame. Aceste alte diagrame definesc mpreun un model al sistemului real sub aspect static, dinamic i funcional. Grupate dup aspectul evideniat, diagramele pot constitui la un moment dat pentru sistem un model static, unul dinamic sau unul funcional. ntre modele exist o strns legtur: modelul dinamic arat succesiunea n care operaiile definite n clasele modelului static sunt executate. Aciunile din modelul funcional corespund operaiilor din modelul static, actorii i cazurile de utilizare prefigureaz obiectele modelului static care sunt legate prin funcii. actorii sunt obiecte explicite din modelul obiectelor, cel care le prezint structura. Fluxurile de date de la sau spre actori reprezint operaii pentru obiecte. Pentru un obiect actor, modelul dinamic arat cnd acioneaz.

108

Modelul dinamic al acestor obiecte este necesar pentru a determina ordinea operaiilor. modelul funcional prezint nelesul operaiilor i al restriciilor din modelul obiect, nelesul aciunilor i activitilor din modelul dinamic Toate cele trei modele sunt supuse unor restricii, ce arat relaiile fie dintre dou obiecte la un acelai moment de timp, fie ntre valori ale aceluiai obiect la momente de timp diferite. Restriciile pot fi asupra obiectelor, caz n care arat dependena parial sau total a unor obiecte de altele, pot fi asupra strilor din modelul dinamic, sau pot specifica restricii asupra operaiilor din modelul funcional. Dimensiunea static vizeaz structura sistemului, componentele i relaiile dintre ele. Este evideniat prin diagrama claselor i diagrama obiectelor. Aceste diagrame sufer modificri de-a lungul ciclului de via al sistemului, conducnd n final la un model al sistemului real, complet implementabil cu ajutorul limbajelor orientate obiect (C++ , Visual Basic). nelegerea unui sistem nu se poate ns limita doar la evidenierea componentelor i a relaiilor dintre ele. Pentru a surprinde partea dinamic, dependent de timp, se definesc noi diagrame: diagrame de colaborare, diagrame de stare i diagrame de secvene. Pentru obiectele care colaboreaz, acestea arat care sunt i cum se modific strile unui obiect, evenimentele care cauzeaz n timp tranziia de la o stare la alta. Evideniaz secvenele de operaii ce apar ca rspuns la stimuli externi, fr a lua n calcul ce face operaia i cum este ea implementat. Dimensiunea dinamic a sistemului este prezentat prin prisma evenimentelor percepute de sistem. Apariia sau dispariia unor obiecte, modificarea proprietilor unui obiect, actualizarea restriciilor de integritate sau schimbarea relaiilor dintre obiecte, sunt doar cteva din modificrilor generate n timp de apariia unor evenimente. Aspectul funcional vizeaz fluxurile de date care circul ntre diferii actori ai sistemului. Descrie ce se ntmpl n sistem i este reprezentat cu ajutorul diagramelor cazurilor de utilizare, al diagramelor de activiti i de componente. n plus, evidenierea aspectului funcional presupune identificarea datelor de intrare i a datelor de ieire din sistem, definirea procedurilor de
109

prelucrare a datelor, identificarea restriciilor i precizarea criteriilor de optimizare.

diagramele urmresc ciclul de via al sistemului pe parcursul etapelor de analiz, proiectare i implementare
Realizarea unui sistem informatic presupune parcurgerea mai multor etape. Rezultatul se regsete de fiecare dat ntr-un model. Legtura ntre modele se pstreaz, pentru c se pornete de la elementele domeniului din sistemul real i se introduc detalii necesare implementrii pe parcursul etapei de proiectare. Sunt reprezentate aceleai elemente, ns din puncte de vedere diferite. Parcurgerea ciclului de via al sistemului nseamn revedere, detaliere, completare a modelelor existente la un moment dat. Confirm faptul c modelele orientate obiect se dezvolt n spiral. Definite pentru sisteme noi, sau pentru a permite evoluia celor existente, diagrama cazurilor de utilizare constituie pe parcursul etapelor de analiz i proiectare cadrul de referin comun. Constituie punctul iniial n stabilirea cerinelor proiectrii i formeaz baz pentru testarea i verificarea sistemului obinut. Modelele obinute n diferite etape sunt reprezentate prin diagrame de diferite tipuri, ntre care exist legturi de moment determinate de context. n faze care se succed, fiecare model aduce o perspectiv diferit asupra sistemului, adaug noi elemente imaginilor precedente, pn n final, cnd se ajunge la o viziune de ansamblu a stadiilor prin care va trece sistemul. Definirea modelelor nu este o activitate liniar, n sensul c diagramele definite ntr-o etap pot fi modificate n alta. nlnuirea i interaciunea modelelor are loc pe tot parcursul definirii sistemului: n faza de definire a cerinelor se stabilesc cerinele funcionale ale sistemului cu ajutorul diagramelor cazurilor de utilizare rezultatele etapei de analiz se concretizeaz ntr-o diagram a claselor i n diagrame de comportament (de secvene i de activiti) n etapa de proiectare sunt definite noi clase, se renun la clase care nu au relevan, sunt evideniate relaii suplimentare ntre clase. Clasele definite pentru mai multe cazuri de utilizare sunt integrate ntr-o structur
110

unic. Se definesc diagrame de stare, se adaug detalii necesare implementrii n modelul claselor. O aceeai diagram poate fi folosit n scopuri diferite pe parcursul ciclului de via: diagrama de activiti este ataat n faza de analiz unui caz de utilizare i servete n faza de implementare la definirea schemelor logice de program, la descrierea detaliat a operaiilor. Componentele se traduc n fraze SQL sau n instruciuni de program i contribuie la definirea structurii claselor. diagramele obiect sunt folosite n etapa de analiz pentru abstractizarea modelului, i n faza de proiectare pentru introducerea detaliilor necesare implementrii.

TESTE FINALE
1. Care din afirmaiile urmtoare nu este adevrat ? a) n faza de proiectare se alege soluia informatic pentru realizarea efectiv a sistemului. b) Un obiect este o abstracie, un concept, folosit pentru reprezentarea lumii reale i furnizarea unei baze practice pentru implementarea cu ajutorul tehnicii de calcul. c) O clas este o abstracie, un concept, folosit pentru reprezentarea lumii reale i furnizarea unei baze practice pentru implementarea cu ajutorul tehnicii de calcul. 2. Care din afirmaiile urmtoare este fals ? a) Identitatea unui obiect este acea proprietate a obiectului care l distinge de alte obiecte. b) Obiectul este definit de un identificator intern unic, independent de valoarea sau de adresa de memorie a obiectului. c) Identificatorul este controlat direct de programator. Se exprim prin diferitele nume utilizate de programator pentru a-l numi. 3. Care din afirmaiile urmtoare este adevrat ?

111

a) Identitatea este o abstracie a valorilor atributelor i a legturilor unui obiect. b) Starea obiectului reprezint mulimea valorilor tuturor atributelor i legturilor sale la un moment dat. c) Identitatea este adesea asociat cu valoarea unui obiect satisfcnd anumite condiii. 4. Care din afirmaiile urmtoare este adevrat ? a) Comportamentul este determinat de ansamblul operaiilor pe care obiectul le poate executa. b) Starea exprim modul n care un obiect acioneaz i reacioneaz. c) n cazul tehnicilor orientate obiect, prin ierarhizare se evideniaz caracteristicile eseniale ale unui obiect, cele care-l disting de alte obiecte. 5. Care din afirmaiile urmtoare este fals ? a) Abstractizeaz nseamn gruparea obiectele n clase. a) Prin abstractizare definiiile comune sunt memorate o singur dat pentru clas, n loc s fie memorate pentru fiecare instan. c) Prin definirea claselor, obiectele nu beneficiaz de codul reutilizat, operaiile fiind rescrise pentru fiecare obiect. 6. Care din afirmaiile urmtoare este adevrat ? a) O clas de obiecte descrie o mulime de obiecte cu aceleai proprieti i acelai comportament. b) O clas conine obiectele cu aceleai operaii i relaii similare fa de alte obiecte. c) O clas de obiecte descrie o mulime de obiecte cu aceleai proprieti, acelai comportament i relaii similare fa de alte obiecte. 7. Care din afirmaiile urmtoare este adevrat ? a) ncapsularea este un proces de grupare a elementelor unei clase n elemente accesibile din exterior i elemente proprii.
112

b) Motenirea permite separarea aspectului extern, accesibil altor obiecte, de implementarea intern. c) Abstractizarea ofer posibilitatea de a masca atributele proprii ale unui obiect, precum i modul n care se execut operaiile. 8. Care din afirmaiile urmtoare este fals ? a) Datorit ncapsulrii, implementarea poate fi schimbat fr a afecta aplicaia. b) ncapsularea constituie una din premisele de baz ale reutilizrii. c) Abstractizarea constituie una din premisele de baz ale reutilizrii. 9. Care din afirmaiile urmtoare este fals ? a) Ierarhizarea este o operaia de ordonare a abstraciilor. b) Agregarea este o relaie de tip parte-ntreg, n care obiecte care reprezint componente ale unui ntreg, sunt asociate cu ntregul. c) Generalizarea este o form de asociere n care exist un obiect format din componentele sale, componentele fiind vzute ca parte a ntregului. 10. Care din afirmaiile urmtoare este adevrat ? a) Semantic agregatul este vzut ca un obiect, tratat ca o unitate n multe operaii, dei fizic este format din mai multe obiecte. b) Prin generalizare, propagarea operaiilor ntregului la pri este automat aplicat componentelor. c) n cazul generalizrii una din clase are un rol predominant n raport cu cealalt. 11. Care din afirmaiile urmtoare este adevrat ? a) Agregarea este o relaie dintre o clas de baz i una sau mai multe clase derivate ale ei. b) Prin agregare, atributele i operaiile comune sunt grupate n superclas, fiind motenite de subclase. c) Generalizarea este o relaie dintre o clas de baz i una sau mai multe clase derivate ale ei.
113

12. Care din afirmaiile urmtoare este adevrat ? a) n cazul agregrii clasele sunt integral coerente, subclasa aducnd eventuale informaii adiionale, specifice. b) Partajarea atributelor i operaiilor ntre clase, de-a lungul unei ierarhii ntre clase i subclase este evideniat cu ajutorul conceptului de generalizare. c) Motenirea permite constituirea de noi tipuri de obiecte i clase, evitnd rescrierea i recodificarea. 13. Care din afirmaiile urmtoare este adevrat ? a) Prin agregare, clasele pot moteni att operaii (metode), ct i variabile de instan (atribute). b) ntre clasele din figura urmtoare exist o relaie de agregare. DOCUMEN

CONTRACT

FACTUR

c)

ntre clasele din figura urmtoare exist o relaie de generalizare DOCUMEN

CONTRACT

FACTUR

14. Care din afirmaiile urmtoare este fals ? a) n timp ce generalizarea se refer la relaia dintre aceeai clas i subclasele sale, motenirea se refer la mecanismul de a transmite atribute i operaii de-a lungul unei relaii de generalizare.
114

b) n timp ce motenirea se refer la relaia dintre aceeai clas i subclasele sale, generalizarea se refer la mecanismul de a transmite atribute i operaii de-a lungul unei relaii de generalizare. c) Polimorfismul definete caracteristica unei operaii de a se comporta n mod diferit n funcie de clasa de obiecte creia i aparine. 15. Care din afirmaiile urmtoare este fals ? a) Un caz de utilizare este iniiat ntotdeauna de un actor i exprim o funcie a sistemului, declanat ca rspuns. b) Funcionalitatea complet a sistemului este dat de diagrama claselor. c) Actorii sunt elementele din sistem care genereaz sau primesc evenimente.

16. Care din afirmaiile urmtoare este adevrat ? a) Diagrama obiectelor prezint un grup de obiecte i interaciunile dintre ele. b) n faza de analiz, diagrama claselor urmrete scenarii definite pornind de la cazurile de utilizare. c) Diagramele de interaciune evideniaz mesajele trimise ntre obiecte 17. Care din afirmaiile urmtoare este fals ? a) mpreun cu diagramele de secvene, diagramele de colaborare alctuiesc aa zisele diagrame de interaciune, ce evideniaz mesajele trimise ntre obiecte. b) n timp ce o diagram de colaborare se construiete pentru un singur scenariu n care pot fi implicate mai multe obiecte, diagramele de secvene conin un grup restrns de obiecte, ce pot fi implicate n mai multe scenarii. c) n faza de proiectare, diagrama de colaborare evideniaz comportamentul claselor ca rspuns la apariia unor evenimente. 18. Care din afirmaiile urmtoare este fals ?

115

a) Diagramele de secvene ilustreaz interaciunile dintre obiecte din punct de vedere temporal. b) Diagramele de secvene arat obiecte i interaciunile dintre ele de-a lungul unui scenariu. c) Pentru fiecare mesaj din diagrama de secvene, n clasa obiectului destinatar trebuie s existe un atribut corespunztoare, reacia obiectului la mesajul primit. 19. Care din afirmaiile urmtoare este fals ? a) Diagramele schimbrilor de stare descriu comportamentul obiectelor unei clase prin stri i evenimente. b) Diagramele schimbrilor de stare se construiesc doar pentru clasele cu comportament interesant dinamic, completnd descrierea unui caz de utilizare. c) Diagramele de stri modeleaz ciclul de via al unei singure clase, fr a evidenia i eventualele evenimente trimise de ea la alt clas din sistem. 20. Care din afirmaiile urmtoare este adevrat ? a) Diagrama de activiti descrie comportamentul sistemului introducnd elemente de implementare. b) Ataat unei clase, diagrama de activiti detaliaz aciunile i procesele unui caz de utilizare c) Ataat unui caz de utilizare, diagrama de activiti descrie tranziia de la o stare la alta sau algoritmul de prelucrare al operaiilor. 21. Care din afirmaiile urmtoare este adevrat ? a) n faza de proiectare diagramele de activiti completeaz descrierea cazurilor de utilizare. b) n faza de analiz diagramele de activiti apar ataate unei clase i conin elemente de implementare a operaiilor descrise n clase. c) mpreun, diagramele UML constituie un model al lumii reale, vzut din puncte de vedere diferite i n momente de timp diferite.

116

22. Care din afirmaiile urmtoare este fals ? a) Structura static sistemului este evideniat n diagrama claselor i diagrama obiectelor. b) Diagrama de stri nu cuprinde restriciile aprute pe parcursul nlnuirii stare-eveniment-stare. c) Comportamentul sistemului se prezint cu ajutorul a trei tipuri de diagrame: de colaborare, de secvene i de activiti. 23. Care din afirmaiile urmtoare este adevrat ? a) Diagramele de secvene i de colaborare sunt ntocmite pentru scenarii ale unui caz de utilizare b) Diagrama de stri arat clasele i interaciunile dintre ele de-a lungul unui scenariu. c) Pentru clasele cu comportament dinamic semnificativ, diagrama de colaborri completeaz descrierea unui caz de utilizare. 24. Care din afirmaiile urmtoare este fals ? a) Prin evidenierea cazurilor de utilizare se delimiteaz domeniul de studiu. b) Prin evidenierea obiectelor din diagrame se stabilete o legtur direct ntre utilizatori i analitii de sistem. c) Cerinele utilizatorilor se regsesc n diagrama cazurilor de utilizare. 25. Care din afirmaiile urmtoare este fals ? a) Diagramele de activiti i de stri aduc detalii suplimentare privind comportamentul obiectelor din clase. b) Diagramele claselor i diagrama obiectelor detaliaz interaciunea ntre clase c) Diagramele de activiti cuprind elemente necesare pentru implementarea claselor. 26. Care din afirmaiile urmtoare este adevrat ? a) Diagrama de stri vizeaz structura sistemului, componentele i relaiile dintre ele. b) Dimensiunea static este evideniat prin diagrama de activiti i diagrama de secvene. c) Diagrama cazurilor de utilizare constituie pe parcursul etapelor de analiz i proiectare cadrul de referin comun.
117

27. Care din afirmaiile urmtoare este fals ? a) Aspectul funcional este reprezentat cu ajutorul diagramelor cazurilor de utilizare i al diagramelor obiect. b) Diagrama cazurilor de utilizare constituie punctul iniial n stabilirea cerinelor proiectrii i formeaz baz pentru testarea i verificarea sistemului obinut. c) O aceeai diagram poate fi folosit n scopuri diferite pe parcursul ciclului de via al unui sistem.

1-c

Rezolvare 2-c 3-b 4-a 5-c 6-c 7-a 11-a 12-c 13-c 14-b 15-b 16-c
20-a 21-c 22-b 23-a 24-b 25-b

8-c
17-b 26-c

9-c
18-c 27-b

10-a
19-c

118

CAPITOLUL IV - O comparaie ntre metodele orientate obiect i metodele sistemice

Att metodele orientate obiect ct i cele sistemice sunt metode utilizate n proiectarea sistemelor informatice, pentru formularea cerinelor, analiza lor n condiiile concrete n care va funciona sistemul i dezvoltarea unei soluii care s rspund cerinelor utilizatorilor. Ambele consider domeniul studiat al sistemului real ca avnd o anumit autonomie n funcionare i interacionnd cu mediul exterior. Folosesc concepte comune sau modaliti asemntoare de reprezentare a modelelor definite. Astfel, claselor din modelele orientate obiect le corespund entitatile din modelele sistemice, atributelelor le corespund proprietile, instanelor de clase realizrile de entitate, multiplicitii cardinalitile, asocierii relaia. Diagrama claselor este o extensie a diagramei Entitate-Asociere, clasele nglobnd n plus comportamentul obiectelor. Ataat unei clase, diagrama de activiti corespunde definiiei unei operaii din modelul conceptual al prelucrrilor. n totalitatea sa, construit pentru a completa descrierea unui caz de utilizare, este echivalent cu modelul conceptual al prelucrrilor, fr a cuprinde ns evenimente externe i sincronizarea care determin declanarea unei operaii. n acest caz, condiiile de decizie au rolul regulilor de emisie ale rezultatului. Diferena ntre tehnicile i instrumentele folosite este accentuat de domeniul n care sunt utilizate, de felul n care se raporteaz la sistemul real. Poate fi observat urmrind modul n care reuesc s ndeplineasc cerinele utilizatorilor, modul de prezentare al ciclului de via al sistemului i al elementelor sale de structur, sub aspect static, dinamic i funcional.

119

avantaje n funcie de domeniul sistemului real

Metodele sistemice sunt folosite n cazul sistemelor informatice care vehiculeaz un volum mare de date, structurate pe tipuri de nregistrri cu caracteristici asemntoare. Tratarea n modele diferite a datelor i prelucrrilor asigur independena logic i fizic a programelor de prelucrare fa de structura informaiilor, eliminnd din schema conceptual i schemele externe detaliile privind structura de memorare i strategiile de acces. Fora modelului relaional adoptat ca soluie informatic la nivel logic aduce avantaje remarcabile n asigurarea persistenei datelor, n oferirea informaiei multidimensionale asupra datelor din baza de date. Interogarea bazei de date i extragerea de informaii se face n funcie de un numr de criterii exprimate cu ajutorul operatorilor algebrici. Este permis controlul accesului la date, accesul concurent al mai multor utilizatori la aceleai date i acordarea de privilegii utilizatorilor. Limitele modelului relaional sunt impuse de faptul c normalizarea implic uneori prea multe tabele i implicit numeroase legturi, c nu este posibil definirea de noi tipuri de date prin compunerea celor existente, c este dificil de reprezentat structuri de date complexe (ierarhice, grafice, colecii). n consecin, modelele sistemice se aplic cu succes n informatica de gestiune, unde se vehiculeaz un volum mare de date i unde prelucrrile nu sunt complexe, unde persistena este integrat n principiile metodei. La nivelul firmei, pentru reprezentarea activitii independent de organizarea sa, metodele sistemice sunt preferate n conceperea sistemelor tranzacionale i a sistemelor de conducere operativ. n timp ce metodele sistemice rmn un standard n domeniul informaticii de gestiune, metodele orientate obiect sunt preferate n gestiunea informaie tehnice i industriale, unde starea i comportamentul obiectelor reale au prioritate. Chiar dac persistena nu este luat n calcul la debutul modelrii, abordarea individualizat prin clase cu date i comportament, precum i prioritatea acordat comportamentului n raport de date, au condus la utilizarea modelelor orientate obiect n analiza i sinteza datelor din firm,
120

n construirea informaiei agregate la momentul interogrii. Aduc avantaje mari n gestionarea informaiei neomogene provenit din medii de programare diferite, n definirea interfeei vizuale cu utilizatorii. Definirea unor clase de acces la date sporesc confidenialitatea i securitatea informaiei, contribuie la fundamentarea deciziei n urmrirea unor procese incluse n funcionalitatea sistemului real. n plus, metodele orientate obiect permit identificare unic pentru fiecare obiect, construirea de obiecte motenind comportamentul i atributele altor obiecte, faciliteaz reutilizarea. Prin introducerea unui limbaj unificat de modelare (UML), a unui standard care a lipsit pn n prezent, dobndesc un real avans n lumea metodelor de analiza i concepere a sistemelor informatice. Viitorul pare s conduc la gsirea unui mijloc de integrare n abordarea obiect a principalelor modele sistemice utilizate n definirea structurilor persistente de date. Definirea unor obiecte de gestionare a persistenei ar putea aduce o alt soluie dect conceperea i implementarea obiect interfaat cu un sistem de gestiune a bazelor de date relaionale.

alegerea unui model al ciclului de via

Definirea unui sistem informatic presupune parcurgerea mai multor etape, ale cror concluzii se concretizeaz n modele ce-i evideniaz structura, comportamentul i legtura cu mediul n care va funciona. Metodele de proiectare urmresc ntregul ciclu de via al sistemului, specific activitile efectuate, ordinea de desfurare i modul lor de corelare. Ordinea i felul n care se parcurg etapele, practic adoptarea unui model al ciclului de via al dezvoltrii sistemului este decizia echipei de proiectare, luat n funcie de scopul propus. Modelele obinute cu metodele sistemice se nscriu n clasa modelelor cascad, n care ciclul de via este descompus n faze secveniale, structurate pe activiti i subactiviti. Acoperirea ntregului ciclu de via al sistemului se face prin modele separate pentru date i prelucrri, definite la nivel conceptual, logic i fizic. Avantajele rezultate din faptul c fiecare etap este nsoit de documentare i se ncheie cu verificarea soluiei oferite i din faptul c ordonarea i delimitarea clar a
121

fazelor conduce la un control total al fazelor, sunt diminuate de dezavantajele semnalate la eventuale modificri sau extinderi ale sistemului. n cazul metodelor orientate obiect, dezvoltarea sistemului se face iterativ i incremental (n spiral), pentru fiecare iteraie existnd un prototip al modelului final, pe care se testeaz i se valideaz cerinele soluiei adoptate. Parcurgnd etape succesive de analiz, proiectare i implementare, se pornete de le elementele sistemul real i se introduc detalii de implementare pe parcursul etapei de proiectare. Urmrind cerinele utilizatorilor i modul cum acestea sunt ndeplinite, folosind modelarea i simularea, se definesc diagrame ce aduc perspective diferite asupra sistemului, adugnd noi elemente imaginilor precedente. Sunt alctuite din aceleai elemente, ce surprind structura static sau dinamica n timp, ce capt semnificaii diferite n raport de funcionalitatea evideniat. Marele avantaj al modelrii cu ajutorul unor componente unice care nglobeaz proprieti i comportament este c permit reutilizarea componentelor existente n definirea unor noi sisteme sau n extinderea celor existente. n metodele sistemice descompunerea proceselor n subprocese este arbitrar, dependent de modelator. Programatorii au tendina s gndeasc n termeni de funcii, pe care se bazeaz modelul conceptual al prelucrrilor. Metodele orientate obiect orienteaz sistemul n jurul obiectelor din lumea real, a obiectelor conceptuale care exist n imaginea utilizatorului asupra lumii. Exist o mai bun integrare a datelor cu programele, construcia modelelor tinznd spre obiecte similare, facilitate de reutilizare. Analiza obiect este echivalent cu nivelul conceptual. Amndou au ca finalitate descrierea sistemului, evidenierea cerinelor formulate de utilizatori i prezentarea descrierii unei soluii independente de consideraiile tehnice, de soluia informatic aleas. Proiectarea obiect, echivalent cu nivelul logic, are ca finalitate prezentarea soluiei de implementare att pentru date ct i pentru prelucrri. Implementarea obiect corespunde nivelului fizic, care se ocup de descrierea fizic i operaional a datelor i prelucrrilor.

122

evidenierea aspectului static dinamic i funcional

Ambele metode construiesc modele statice, dinamice i funcionale. n cazul metodelor sistemice, modelul static este modelul conceptual al datelor, care prezint entitile i asocierile dintre ele. n cazul metodelor orientate obiect, modelul static este dat de diagrama claselor i diagrama obiectelor, ce prezint structura i relaiile entitilor ce nglobeaz proprieti i comportament. Aspectul dinamic al sistemului prin prisma metodelor sistemice este evideniat cu ajutorul modelului conceptual al prelucrrilor. Mai bine corelate cu modelul static, diagramele de secvene, de stri i de colaborri sunt cele care definesc comportamentul dinamic, dependent de timp al unui sistem informatic din punctul de vedere al metodelor orientate obiect. Modelarea funcional este aproape inexistent la metodele sistemice. Superioar prin detalii de comportament descrise ct i prin posibilitatea modelrii elementelor funcionale pe niveluri diferite de abstractizare, n cazul metodelor orientate obiect, modelarea funcional este strns corelat cu cea static, prezentnd nelesul operaiilor definite n clasele modelului static.

abordarea structurii elementelor ce alctuiesc modelul

Metodele sistemice trateaz difereniat datele de prelucrri. Complet separate n faza conceptual, modelele de date i de prelucrri nu au concepte comune, nu au legturi evidente. Exist discordane determinate de faptul c se acord prioritate datelor i asocierilor dintre ele, c modelul prelucrrilor prezint doar succesiunea evenimentelor i a operaiilor, fr a aminti structurile de date implicate. Metodele orientate obiect folosesc pentru modelarea sistemului real entiti ce nglobeaz proprieti i comportament, date i prelucrri. Modelele definite permit o bun integrare a datelor i prelucrrilor, fapt ce implic o rezolvare coerent a aspectului dinamic i funcional. Formalismul Entitate-Asociere, pe baza cruia se face modelarea conceptual i organizaional a datelor, admite doar asocierea ca relaie
123

fundamental ntre entiti. Relaiile ntre entiti sunt bidirecionale, caracterizate prin numrul realizrilor de entiti ce particip la asociere. n cazul modelelor orientate obiect, prin admiterea n plus a relaiilor de agregare i generalizare, se poate defini o ierarhie a claselor, n care atributele unui obiect pot fi n ele nsele obiecte. Este posibil utilizarea motenirii i a polimorfismului pentru a specializa un obiect urmnd o cerin particular, sau pentru a obine o nou clas prin generalizare, pornind de la mai multe clase care au trsturi comune. De-a lungul ierarhiilor, pentru utilizarea modelului obiect se navigheaz de la un obiect la altul, fiind admise i situaii n care doar unul din obiecte poate accesa obiectul corespunztor (asociere unidirecional). Comparaii pot fi fcute i dup adoptarea soluiei informatice, odat cu introducerea unor detalii necesare implementrii. Pentru ambele metode exist structuri de date i operatori utilizai pentru gestionarea lor. Pentru ambele metode, exist restricii impuse de sistemul real. Standardul folosit pentru descrierea datelor la nivel logic n cazul metodelor sistemice este Modelul Relaional, definit ca un ansamblu format din structura relaional a datelor i mulimea operatorilor relaionali. Exist o singur structur de date, relaia. Asocierile dintre relaii sunt exprimate tot prin relaii. Existena unei singure structuri de date a condus la o uniformitate corespunztoare n mulimea operatorilor folosii, permind o interogare eficient a datelor partajate de mai muli utilizatori. Gestionarea datelor se face cu SQL (Standard Query Language), un limbaj de programare neprocedural puternic, concis i normalizat. Acesta permite descrierea, actualizarea i interogarea datelor memorate, efectuarea de operaii algebrice complexe asupra datelor, specificarea restriciilor de integritate, controlul la date al utilizatorilor. Se pot selecta astfel submulimi ale unui tabel sau grupuri de nregistrri din diferite tabele, indicnd criteriul de selecie sub forma unei fraze SQL. Modelele obiect pot reprezenta printr-un obiect date variate i complexe. n plus, operaiile corespunztoare sunt incluse n aceeai entitate. Obiectele sunt legate ntre ele prin mesaje, declanatoare ale
124

operaiilor descrise la nivel de clas. Este ns dificil de definit structuri unice de reprezentare a elementelor de modelare. Nu exist un model standard. Exist doar variante de reprezentare a structurilor de date orientate obiect (UML, limbaje de programare orientate obiect) i grupe de operatori (constructori, destructori, selectori). Legtura direct ntre date i prelucrri favorizeaz i ncurajeaz utilizarea pe scar larg a instrumentelor CASE n scopul realizrii aplicaiilor pentru gestionarea obiectelor. Instrumentele CASE pot genera prototipuri funcionale ale aplicaiilor, pe baza elementelor descrise n modelele conceptuale.

125

EXEMPLU FINAL 1 - SISTEM INFORMATIC PRIVIND CONTRACTAREA SI APROVIZIONAREA CU MARFURI

A Nivel CONCEPTUAL

Datele i prelucrrile sunt prezentate n modele separate: Modelul Conceptual al Datelor i Modelul Conceptual al Prelucrrilor A. I. Modelul Conceptual de Date

Pentru construirea Modelului Conceptual de Date se parcurg etapele 1-6 descrise n capitolul III: 1 reguli de gestiune 1. n vederea aprovizionrii, cu un furnizor se ncheie unul sau mai multe contracte; 2. un contract poate fi onorat prin una sau mai multe facturi; 3. contractele ncheiate se refer la unul sau mai multe sortimente de marf; 4. cu o factur pot fi aprovizionate unul sau mai multe sortimente de marf; 5. datoria fa de un furnizor poate fi achitat prin unul sau mai multe documente de plat; 6. cantitatea contractat >= (cantiti aprovizionate) 7. valoare contract = cantitate contractat * pre contractare 8. pre contractare = pre aprovizionare 9. valoare factur = cantitate aprovizionat * pre aprovizionare 2 documente primare i atribute corespunztoare: CONTRACT: numr contract, dat contract, valoare contract, termen contract, date_furnizor, date_marf date_furnizor: nume furnizor, adres date_marf: denumire marf, unitate de msur pentru marf, cantitate contractat,
126

pre contractare FACTURA: numr factur, data factur, date_furnizor, date_marf, valoare factur date_marf: denumire marf, um marf, cantitate aprovizionat, pre aprovizionare, valoare marf DOCUMENTE PLATA: tip document, numr document, dat document, sum de plat, date_furnizor, date_factur

3 Dicionarul atributelor Nr.Crt. 1 2 3 4 5 6 7 8 9 Atribut NrContract DataContract TermenContract NrFactura DataFactura TipDoc NrDoc DataDoc SumPlat Nr.Crt. 10 11 12 13 14 15 16 17 18 Atribut CodMarf DenMarf UM CantContract PretContract CantFactur CodFurnizor DenFurnizor AdresFurnizor

4 Matricea simplificat a dependenelor funcionale 2 0 3 0 5 0 0 0 0 0 0 0 0 0 0 8 9 11 12 13 14 15 17 18 0 0 0

1 4 6+7 10 16

127

5 Entitile rezultate:
CONTRACT NrContract DataContract TermenContract FURNIZOR CodFurnizor DenFurnizor AdresFurnizor

FACTURA NrFactura DataFactura

MARFA CodMarf DenMarf UM

DOC PLAT TipDoc NrDoc DataDoc SumPlat

6 Asocierile rezultate: .. atributul CantContract este determinat de atributele cheie ale entitilor CONTRACT i MARFA.Devine atribut al asocierii conine .. atributul PreContract este determinat de atributele cheie ale entitilor CONTRACT i MARFA. Devine atribut al asocierii conine .. atributul CantFactur este determinat de atributele cheie ale entitilor FACTURA i MARFA. Devine atribut al asocierii vizeaz

128

regula 1 CONTRACT 1,1 regula 2 1,n CONTRACT regula 3 CONTRACT 1,n MarfaContract CantContract PreContract 1,n MARFA Conform 1,1 FACTURI ncheie 1,n FURNIZOR

regula 4 FACTURI 1,n MARFA MarfaFactura CantFactur 1,n

regula 5 DOCPLATA 1,1 Emit 1,n FURNIZOR

DOCPLATA

1,1

Factur pltit

1,n

FACTURI

129

Modelul Conceptual de Date rezultat este cel din figura 5.1

FURNIZOR CodFurnizor DenFurnizor AdresFurnizor CONTRACT 1,n Incheie 1,1
NrContract DatContract TermenContract

1,n MarfaContract 1,n 1,n CantContract PretContract 0,n MARFA Emit Conform
CodMarf DenMarf UM

1,n 1,1 MarfaFactura CantFactura 1,1 1,n DOCPLATA FACTURI 1,n Factur pltit 1,1

NrDoc TipDoc

NumrFactur
DataFactur

DatDoc SumPlat

fig.5.1
130

A. II. Model Conceptual de Prelucrri Prelucrrile pot fi structurate n dou procese: contractarea mrfurilor i aprovizionarea efectiv cu mrfuri. Modelul Conceptual al Prelucrrilor n cazul contractrii mrfurilor este prezentat n figura 5.2
Necesar de aprovizionat Ofert furnizori

01

Alegere furnizor Consultare lista furnizor Analiza oferta furnizor

DA
Furnizor ales

NU

02

Intocmire contract Negociere contract

DA
Contract incheiat

NU

03

Inregistrare contract Verificare concordanta informati

DA

NU

Contract inregistrat

131

fig. 5.2 Modelul Conceptual al Prelucrrilor n cazul aprovizionrii efective cu mrfuri este prezentat n figura 5.3
Factura Sosire marf

04

Recepie marf Recepionare marf

DA
Marf recepionat

NU
Marf refuzat

05

Inregistrare factur Se nregistreaz factura

DA
Factur inregistrat Marf depozitat

NU

06

Se completeaz fia de magazie

DA

NU

Fi magazie completat

fig. 5.3

132

B B.I.

Nivel Organizaional

Model Organizaional de Date Structura organizatoric a firmei nu presupune reorganizri suplimentare de date n raport de compartimentele funcionale. Modelul Entitate-Asociere prezentat nfigura 5.1 poate fi considerat i Model Organizaional de Date. B. II. Modelele Organizaionale de Prelucrri Modelele Organizaionale de Prelucrri corespund proceselor definite anterior (A II) Modelul Organizaional de Prelucrri pentru contractarea mrfurilor este prezentat n fig. 5.4

133

Furnizor
Ofert furnizor

Aprovizionare

Contabilitate Gestiune

Stabilire necesar i i 1 Alegere furnizor

manu al Furnizor ales 2 Intocmire

Contract

ntocmit

manu Contract al Contract incheiat

3 Semnare contract
manual

4 Inregistrare Timp contract real

Contract fig. 5.4

134

Modelul Organizaional de Prelucrri pentru aprovizionarea efectiv cu mrfuri este prezentat n figura 5.5

Furnizori

Aprovizionare

Contabilitate

Gestiune

Trimit e

5 Recepie marfa manu al DA

Factura nregistrat

Trimit e

NU

6 Marf recepionat Timp real

Inregistrare

7
Depozitare marf manual

factur

Marf refuzat

Marf depozitat

9 Stornare Timp factur real

8 Completare fis Timp magazie real

Factur stornat

Marfa evideniat n gestiune

fig. 5.5
135

C.

Nivel logic

La acest nivel datele i prelucrrile pot fi tratare mpreun. Pentru exemplul nostru, datele sunt memorate ntr-o baz de date relaional i sunt manipulate cu un Sistem de Gestiune a Bazelor de Date Relaionale (Access 2000). C. I. Descrierea Logic a Datelor

Aplicnd regulile de trecere de la Modelul Entitate-Asociere (fig.5.1) la Modelul Relaional, obinem urmtoarele scheme de relaie : TFurnizori = ( CodFurnizor, DenFurnizor, AdresaFurnizor) TContract = (NrContract, DataContract, TermenContract, CodFurnizor) TMarfa = (CodMarfa, DenMarfa, UM) TFacturi = (NrFactura, DataFactura, NrContract, TipDoc,NrDoc) TDocPlata = (TipDoc,NrDoc, DataDoc, SumaPlat, CodFurnizor) TMarfaContract = (NrContract,CodMarfa, CantContract, PretContract) TMarfaAprov = (NrFactura,CodMarfa, CantFactura) Aceste scheme de relaie sunt practic tabelele din baza de date (fig.5.6 )

fig.5.6
136

C. II. Descrierea Logic a Prelucrrilor Prelucrrile sunt reprezentate de secvene SQL regsite n definirea tabelelor, n interogri asupra tabelelor din baza de date, sau n rapoarte finale adresate utilizatorilor. Pentru exemplul nostru, interogrile definite penru manipularea bazei de date sunt cele din figura 5.7

fig.

fig.5.7 D. D.I. Nivel fizic Descrierea datelor la nivel fizic

137

n descrierea structurii tabelelor se specific numele cmpului, tipul de dat, eventuale valori implicite i reguli de validare. De exemplu, pentru tabela TmarfaContract, dscrierea structurii este cea din figura 5.8.

fig.5.4

fig.5.4 fig.5.8. D. II. Descrierea prelucrrilor la nivel fizic Interogrile pot fi definite cu fraze SQL sau n mod DESIGN. De exemplu, pentru a obine o list a furnizorilor i a documentelor de plat corespunztoare se specific urmtoarea fraz SQL : SELECT tFurnizori.DenFurnizor, tFurnizori.AdresaFurnizor, tDocPlata.NrDoc, tDocPlata.TipDoc, tDocPlata.DataDoc, tDocPlata.SumaPlata FROM tFurnizori INNER JOIN tDocPlata ON tFurnizori.CodFurnizor = tDocPlata.CodFurnizor.
138

Rezultatul este cel prezentat n figura 5.9

fig.5.9 Pentru obinerea unei liste care evideniaz achitarea furnizorilor n concordan cu facturile primite de la ei, se definete n mod DESIGN o interogare ca n figura 5.10. Pentru evidenierea aceleiai situaii referitoare la un singur furnizor, la anumite facturi sau la anumite documete de plat se pot defini interogti tip Total dup criterii specifice de grupare, sau se pot defini interogri parametrizate. Pornind de la interogarea definit anterior, valoarea documentelor de plat pentru un furnizor al crui nume se cunoate la momentul execuiei se obine cu o interogare definit n mod DESIGN ( fig .5.11)

139

fig.5.10

fig.5.11
140

EXEMPLU FINAL 2 - UTILIZAREA UML IN DEZVOLTAREA SISTEMELOR INFORMATICE SISTEM INFORMATIC PENTRU CORELAREA ACTIVITATII DE ASAMBLARE CU COMENZILE CLIENTILOR
1. Descrierea problemei O societate comercial produce componente pentru calculatoare. Una din cele 4 secii ale societii asambleaz componentele fabricate de celelalte secii sau provenite din aprovizionare, activitate din care rezult produsele finale (calculatoare). Se pune problema de a crea o aplicaie informatic pentru corelarea activitii de asamblare cu comenzile clienilor. Din descrierea activitilor care se regsesc n domeniul analizat, dispunem de urmtoarele informaii privind fluxurile informaionale implicate: Compartimentul vnzri primete zilnic comenzile clienilor. Comenzile cu regim de prioritate pot fi onorate cu o cretere a preului de vnzare cu 10%. Clienii care au mai mult de 10 comenzi sunt tratai automat cu prioritate. Pentru onorarea comenzilor, secia de montaj se aprovizioneaz cu: - componente fabricate n alte secii ale societii; - componente de la tere societi. Comanda final este transmis seciei de montaj, care o finalizeaz dup recepia componentelor aprovizionate. Numrul comenzii finalizate este transmis compartimentului de vnzri. Compartimentul vnzri se ocup i de facturare. Modificri ntr-o comand pot veni i dup nregistrarea comenzii. Ele pot viza: - codul articolelor, (n cazul unor mbuntiri tehnice survenite n timp); - alte caracteristici: ntrzieri, cantitatea comandat, etc.

141

Soluia propus 1. Diagramele cazurilor de utilizare:

142

2. Diagrama claselor pentru cazurile de utilizare descrise mai sus:

143

3. Diagrama de secven pentru descrierea scenariului Tratarea unei comenzi:

144

Bibliografie [GJ99] [OD99] Merise vers OMT et UML. InterEdition, Paris,1999. Oprea D. Analiza i proiectarea sistemelor informationale economice.Ed. Polirom, Iai, 1999. Popa G, Iliescu M, Udric M. Baze de date Access. Culegere de probleme. Ed. Cison, Bucureti, 2004. Stanciu V. Proiectarea sistemelor informatice. Ed. DualTech, Bucureti, 2003. Udrica M, Martinov D. Metode de dezvoltare software. Support curs STI, UTM, 2007 Udric M. Modelare orientat obiect. Ed. Cison, Bucureti, 2000. Udric M. Date i prelucrri n conducerea operativ a firmei. Ed. best publishing, Bucureti, 2003. Udric M. Date i prelucrri n conducerea strategic a firmei. Ed. best publishing, Bucureti, 2004.

[PI02]

[SV03]

[UM07]

[UM00]

[UM03]

[UM04]

145

[ZR02]

Zaharie D, Roca I. Proiectarea obiectual a sistemelor. Ed. DualTech, Bucureti, 2002.

146