PROIECTAREA SISTEMELOR INFORMATICE

1. Managementul afacerii i tehnologia informaiei

n desfurarea oricrei activiti economice, financiare sau bancare nu se poate imagina fr utilizarea unui puternic suport informaional care s asigure avantajul concurenial n raport cu ceilali competitori de pe pia. A dobndi cunoatere prin informaia obinut este rolul tehnologiei informaiei (TI). De aceea o atenie sporit se acord astzi problemelor legate de managementul sistemului informatic care se ocup cu planificarea dezvoltrii sistemului informatic la nivel de firm, i folosirea TI cu scopul susinerii personalului specializat n prelucrarea datelor n vederea obinerii informaiilor necesare lurii deciziilor . Plecnd de la exemplul unei firme vom constata c modul de desfurare a afacerii se schimb ca urmare a aciunii conjugate a urmtorilor factori: globalizare, competiie de nivel nalt, informaia devenit resurs cheie a oricrei firme, spaiul virtual de munc i chiar derularea activitii n condiiile companiei virtuale, comer electronic, existena n cadrul firmei a personalului specializat n procesarea datelor i analiz (knowledge workei), un nou tip de relaie cu banca prin care se obin servicii i produse noi ca urmare a promovrii noilor soluii TI etc Funcionarea firmei n condiii optime a condus la structurarea unui model sistemic al ntreprinderii format din trei componente: subsistemul decizional, subsistemul informaional i subsistemul operaional.

Subsistemul decizional pune n valoare informaiile obinute de la subsistemul informaional i le folosete n derularea actului decizional. La nivelul subsistemului decizional se restructureaz modul de pregtire, adoptare, aplicare i evaluare a deciziilor, astfel nct fiecare manager, dup implementarea sistemului de management al calitii, tie cu mai multa claritate care este poziia lui in cadrul subsistemului decizional al organizaie. Subsistemul informaional are un dublu rol: asigur tot suportul informaional necesar lurii oricror decizii la toate nivelurile (conducere, control) flux ascendent asigur cile de comunicare ntre subsistemul operaional i subsistemul decizional flux descendent La nivelul subsistemului informaional se produc schimbri in modul de colectare a datelor si de structurare a informaiilor necesare pentru luarea deciziilor si pentru desfurarea activitii, apar modificri ale circuitelor si fluxurilor informaionale astfel nct sa creasc viteza de luare a unor decizii precum si capacitatea de rspuns a organizaiei la diverii factori care influeneaz profitabilitatea organizaiei; Subsistemul operaional este locul unde practic se culeg datele (din activitile economice specifice fiecrui agent economic) ce sunt transmise (ascendent) subsistemului informaional. Subsistemul organizatoric al organizaiei consta in ansamblul elementelor de natura organizatorica ce asigura cadrul, divizarea, combinarea si funcionalitatea proceselor de munca in vederea realizrii obiectivelor previzionate.

Exemplu organizarea procesual a unei instituii

Exemplu: Noua relaie cu banca: n ultimii ani se constat efortul constant al bncilor de a ridica la un nou standard relaia client-banc. Internetul a devenit un important canal de distribuie permind diversificarea produselor i serviciilor oferite clienilor. Utilizarea noilor tehnologii asigur posibilitatea realizrii transferurilor electronice de fonduri, asistarea deciziilor clienilor n gestiunea portofoliului, mai buna cunoatere a clienilor i adaptarea ofertei n funcie de nevoile acestora, confidenialitatea informaiei gestionate, prevenirea i blocarea tranzaciilor ilegale, etc.Sunt utilizate astzi servicii de tipul: home banking, internet-banking, mobilebanking.

2. Sistem informaional, sistem informatic, sistem informatic integrat

Putem defini informatica tiina prelucrrii automate a datelor, instrument al conducerii. Conceptele de baz cu care opereaz informatica sunt: informaia (cunotina = informaia, dup momentul aflrii ei) este reflectarea n contiina noastr a elementelor lumii reale, nconjurtoare; informaia este sursa de date supuse prelucrrilor, pe de o parte i interpretarea rezultatelor obinute prin prelucrarea datelor, pe de alt parte. informaia de tip dat = data este informaia (cunotina) nregistrat, respectiv reprezentarea scris sau grafic a informaiei obinut din lumea

nconjurtoare; este materia prim din care se obine, prin prelucrarea i interpretarea rezultatelor acesteia, alt informaie. Prelucrarea datelor reprezint procesul de transformare a datelor n alte date care, prin interpretare, devin informaii care stau la baza deciziilor. Prelucrarea datelor folosind tehnica de calcul este cunoscut sub numele de prelucrarea automat a datelor. Un sistem reprezint un ansamblu de elemente (componente) interdependente, ntre care se stabilete o interaciune dinamic, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv.

Sistemul informaional economic poale fi definit ca un sistem integrat de oameni de specialitate, mijloace si procedee adecvate, privind culegerea i nregistrarea datelor tehnico-economice si financiare, care privesc patrimoniul unitilor i economiei raionale n ansamblul acestora, prelucrarea i analiza acestora, obinerea de informaii utile in vederea conducerii si gestionarii eficiente a acestuia, stocarea si pstrarea datelor si a informaiilor pentru documentari si controale ulterioare. Sistemul informatic este un ansamblu structurat si corelat de proceduri si echipamente electronice de calcul, care permit culegerea, transmiterea si prelucrarea datelor, obinerea de informaii. Datele i informaiile proprii circuitului economic al patrimoniului sunt consemnate in documente. n raport de modul de ntocmire i rolul lor n cadrul sistemului informational, documentele pot fi justificative, de evidenta contabila sau de sinteza si raportare. Documentele justificative asigura datele de intrare in sistemul informaional contabil, consemneaz operaiile economice i financiare n momentul efecturii lor, cu scopul de a servi ca dovada a nfptuirii lor i ca instrument de fundamentare a nregistrrii contabile Prin registrele contabile se formeaz i materializeaz nregistrrile proprii sistemului de conturi. n condiiile folosirii unor tehnici de prelucrare diferite, ceea ce difereniaz un registru de altul este forma de prezentare a informaiei, coninutul rmnnd acelai. Principalele registre ce se folosesc n contabilitate sunt: registrul jurnal, registrul inventar i cartea mare.

Documentele de sintez i raportare reprezint un sistem de indicatori economicofinanciari, ce caracterizeaz situaia patrimoniului i rezultatele obinute. Se compun din: bilanul contabil, contul de rezultate, anexa la bilan i raportul de gestiune Interfaa ntre documentele contabile se realizeaz prin forma de contabilitate, reprezentat printr-un sistem de formulare, corelate ntre ele, care servesc la nregistrarea i prelucrarea, dup anumite reguli, a datelor privind starea i micarea elementelor patrimoniale. Legislaia i literatura de specialitate economico-financiar este necesar s fie bine cunoscute nainte de programarea i desfurarea fiecrei activiti. Programarea (planificarea) i previziunea diferitelor activiti se bazeaz att pe cunoaterea legislaiei i literaturii economico-financiare, ct i pe informaiile obinute din evidena economic. Cele mai importante programe la nivel de ntreprindere sunt urmtoarele: programe de investiii, programe de aprovizionare i vnzare de bunuri, servicii i de marketing, programe de cercetare-dezvoltare, programe de producie i costuri, programe de salarizare i personal, programe de impozite, taxe i alte sume cuvenite bugetului statului i celui de asigurri sociale,bugetul de venituri i cheltuieli al unitii programe de cretere sau descretere a capitalurilor proprii, programe de ncasri i pli, de credite obinute i acordate, etc Pentru aplicaiile de proiectare exist o legtur direct ntre obiectele lumii reale i entitile definite, datele sunt ierarhizate, manipulndu-se legturile ntre obiect i componentele sale. Mijloacele de prelucrare a datelor economice reprezint ansamblul de tehnici i echipamente de culegere, prelucrare i transmitere a informaiilor. Metodele i procedurile de prelucrare refer partea logic a prelucrrii datelor n vederea obinerii informaiilor. Evoluia tehnicii de calcul a adus o varietate de procedee pentru obinerea i prelucrarea datelor, n vederea utilizrii lor n gestionarea unei uniti economice. Mai mult, se poate asigura simularea evoluiei diverilor indicatori sub aciunea factorilor de influen.

Studiul mediului concurenial demareaz prin stabilirea firmelor concurente, incluznd organizaiile care intenioneaz s ptrund pe pia i productorii de produse substitute. Analiza intern a organizaiei, prin implicarea funciei birotice de prelucrare i comand-control, permite managerului s cunoasc punctele forte, dar i cele slabe ale firmei, elemente care influeneaz puterea competitiv a organizaiei.

3. Sistemul informatic
Sistemul Informatic are funcia de prelucrare automat a datelor pentru obinerea informaiilor necesare procesului de conducere i pentru informare. Pornind de la funcia sa, sistemul informatic are urmtoarea structur general: INTRRI: totalitatea datelor supuse prelucrrilor; PRELUCRRI: totalitatea operaiilor efectuate asupra datelor pentru obinerea informaiilor care stau la baza deciziilor; IEIRI: rezultatele prelucrrilor efectuate asupra datelor, prin interpretarea crora se obin informaiile care fundamenteaz deciziile. Ca arhitectur (model constructiv), sistemul informatic este alctuit din: HARDWARE: Sistemul de calcul (calculator i echipamente periferice); SOFTWARE: Sistemul de Operare (SO): Windows (98,ME,2000,XP), Apple MAC,. - programe pentru dezvoltarea de aplicaii: Sisteme de Gestiune a Bazelor de Date SGBD-uri (Access, Fox, etc.) etc. - limbaje de programare (Visual Basic, C++ etc.); - programe sau aplicaii de utilizator (salarii, contabilitate, secretariat, conturi clieni, valut etc.) COLECII ORGANIZATE DE DATE: Baze de Date BD; SISTEM DE COMUNICAII: intranet, internet, telecomunicaii etc.; RESURSE UMANE: personal tehnic, personal de exploatare, utilizatori etc.; CADRU ORGANIZATORIC.

4. Principii utilizate in proiectarea sistemelor informatice

Desfasurarea unei activitati riguroase si performante de proiectare si realizare de sisteme informatice de financiar bancare impune respectarea unor principii: Abordarea globala a problemei de rezolvat. Fiind vorba de reali-

zarea unui sistem informatic al firmei se impune definirea mai intai a unei solutii globale de informatizare ceea ce va conduce la realizarea unei solutii informatice integrate, stabilirea unei structuri flexibile a sistemului informatic, precizarea prioritatilor in realizarea

componentelor sistemului informatic; Utilizarea unei metodologii unitare in proiectarea si realizarea sistemului informatic; Aplicarea celor mai moderne soiutii si metode de proiectare si realizare a sistemului informatic; Structurarea sistemului informatic relativ independent de structura organizatorica din cadrul firmei. Acest lucru va asigura pe de o parte o buna functionare a sistemului. Daca insa exista particula-ritati deosebite privitoare la modul de organizare a activitatii si acest lucru se repercuteaza asupra fluxuiui informational si procesului de prelucrare a datelor sistemul informatic va trebui sa raspunda acestor particularitati; Participarea nemijlocita a viitorului beneficiar la activitatile de analiza, proiectare si implementare a sistemului informatic. O astfel de participare asigura formularea clara a specificatiilor necesare proiectarii si validarea esalonata a solutiilor propuse de proiectant toate acestea asigurand in final un produs care sa corespunda

deplin cerintelor utilizatorului; Respectarea devine firmei, cadrului obligatorie calcularea legislativ. si Fiind vorba de sisteme in de informatice cadrul sinteza in

realizarea

evidentelor lucrarilor

indicatorilor

intocmirea

conformitate cu reglementarile aflate in vigoare.

5. Arhitectura sistemelor informatice

Arhitectura sistemului informatic reprezinta solutia generica privitoare la procesele de prelucrare a datelor ce trebuie sa se realizeze si modul de integrare a datelor si prelucrarilor. In definirea arhitecturii sistemului informatic s-au cristalizat in timp trei strategii Strategia descendenta Strategia ascendenta Stategia mixta Strategia descendenta numita top-down pleaca de la principiul descompunerii sistemului informatic complex in componente prezentand o complexitate mai redusa parcurgandu-se succesiv mai multe nivele de detaliere in cadrul fiecarei componente definite

Strategia ascendenta numita si bottom up promoveaza initiativa la nivelul fiecarui domeniu. Strategia ascendent (botton-up) este opus metodei top-down avnd la baz principiul agregrii i const n identificarea de jos n sus a componentelor unui sistem i

asamblarea succesiv a modulelor definite pe diferite nivele ierarhice i a relaiilor dintre acestea astfel nct se ajunge la un singur modul corespunztor sistemului. Combinat cu metoda ascendent a condus la strategia mixtcare mbin elemente de la ambele promoveaz iniiativa la nivelul fiecrui domeniu de gestiune. Aceast strategie presupune identificarea problemelor organizaiei i a posibilitilor oferite pentru definirea proiectelor. Se dezvolt soluii informatice la nivelul fiecrui domeniu de gestiune (contabilitate, comercial, producie etc.) fr a exista o soluie cadru i o arhitectur definit pentru sistemul informatic global la nivel de organizaie. Sistemele de gestiune se realizeaz i exploateaz independent pe msura finalizrii lor, rspunznd cerinelor de gestiune ale domeniilor pentru care au fost realizate, urmnd ca ulterior s se treac la integrarea acestora n cadrul sistemului informatic global al organizaiei. Metoda cere un timp mai scurt i este mai ieftin, avnd avantajul de a se ti cu exactitate problemele cu care se confrunt unitatea. Datorit lipsei unei strategii unitare n plan hardware i software, a unei soluii unitare de proiectare i realizare exist riscul unui grad redus de integrare a subsistemelor de gestiune cuprinse n cadrul sistemului informatic al organizaiei. Ca dezavantaj se consider lipsa unui punct de vedere de ansamblu, la nivel de unitate. Stategia mixta reprezinta o combinare a celor doua strategii, descendenta si ascendenta, retinandu-se punctele lor forte. n aceast abordare se opteaz pentru o definire a componentelor sistemului informatic n conformitate cu cerinele strategiei descendente, urmnd ca proiectarea, realizarea i integrarea acestor componente s se realizeze urmnd cerinele strategiei ascendente. 6. Strategii de dezvoltare a sistemelor informatice Considerm c dac s-ar porni de la conceptul filosofic de Existen Fundamental, ceea ce DeMarco numea forma solidului" - cu trimitere la obiectele palpabile - ajungem la Substan, Energie, Informaie. Informaia este vzut de DeMarco, n 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor informaionale sau prin trei dimensiuni: date, funcii, comportament. Datele sunt surprinse prin prisma structurii lor sub form de atribute i nseamn, de fapt, ceea ce sistemul are stocat i-i poate reaminti" oricnd despre fenomenele sau procesele studiate. Ele reflect structura static a sistemului informaional. 9

Funciile scot n eviden, n mod limitat, ceea ce face sistemul. Ele pot fi vzute i ca procese, ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt supuse unor transformri funcionale, prin intermediul proceselor. Comportamentul este invocat pentru a reda o alt modalitate de percepie a sistemului, tot limitat, pentru surprinderea strilor comportamentale prin care acesta ar trece, reliefndu-se influena evenimentelor, ceea ce ar sugera dinamica lui. Pornind de la aspectul tridimensional al sistemelor informaionale, se poate afirma c acestea pot fi axate pe una, dou sau toate cele trei dimensiuni, ceea ce ndreptete pe Whitmire25 s spun c, atunci cnd aplicaiile sunt net dominate de una dintre cele trei dimensiuni, ele sunt data-strong, function-strong sau control-strong. Tot el adaug c, atunci cnd dimensiunea dominant, nu este clar, ele pot fi considerate aplicaii hibride. Prelund comportamentul hologramelor, la care ns nu face nici o referire, reine c obiectele luate individual pstreaz caracteristicile ntregii aplicaii.

Strategia descompunerii funcionale (orientate-funcii) Strategia descompunerii funcionale a sistemelor informatice, care este orientat pe funcii, nu poate s conduc la conceperea unor sisteme suficient de stabile. Totui, pe lng problema complexitii, stabilitatea arhitecturii programelor este una din principalele mize ale acestei abordri. n acest sens, trebuie amintit conceptul de independen funcional care st la baza proiectrii arhitecturale a programelor. Descompunerea funcional este cea care anun apariia proiectrii structurate i analizei structurate. Fiecare funcie este descompus n subfuncii etc., pn cnd se obin forme uor de transpus n instruciunile limbajelor de programare. Descompunerea funcional (DF) este vzut ca o sum de funcii, subfuncii i interfee funcionale, sub forma unei ecuaii: DF = Funcii+ Subfuncii + Interfee funcionale. Metoda are ca puncte tari simplitatea, obinerea destul de uoar a cerinelor utilizatorului i generarea de soluii pe diferite niveluri de abstractizare (sistem, subsistem, funcie, subfuncie). Ca puncte slabe putem considera concentrarea eforturilor spre funcii (ceea ce conduce la culegerea multor date redundante), inexistena unor reguli precise de

10

descompunere i evidenierea anevoioas a interaciunilor non-ierarhice din sistemele complexe. Strategia fluxurilor de date (orientate-proces) O alt metod i n acelai timp o alt modalitate de reprezentare a domeniului problemei i responsabilitilor sistemului printr-o specificaie tehnic este metoda orientat spre procese, deseori descris ca analiza structurat". Ecuaia metodei este: Metoda fluxului de date = Fluxul (i controlul) datelor + Transformrile (i controlul)datelor + Stocarea (i controlul) datelor + Terminatori + Specificaii de proces + Dicionarul datelor. Prin aceast metod, analitii efectueaz reprezentarea lumii reale prin linii ale fluxurilor de date i cerculee pentru procese. n timp, s-au conturat dou strategii n analiza structurat. Se vorbete despre o metod veche" i despre o metod modern" de analiz structurat, lansat n dezbateri la nivelul anului 1982 i prin materialele editate n 1984 - reprezentative fiind lucrrile autorilor McMenamin&Palmer, din 1984, i a lui Yourdon, Analiza modern structurat din 1989. n ultima variant sunt definite cu claritate evenimentele din lumea real la care sistemul trebuie s rspund, o form embrionar a actualelor interaciuni dintre utilizator i sistem, bazate pe mesaje. Sunt incluse de asemenea, fluxurile datelor i transformrile la nivel inferior prin intermediul dicionarului de date, respectiv al specificaiilor proceselor. Cum metoda orientat pe procese are nc un mare grad de asemnare cu descompunerea funcional, criticile metodei descrise anterior se reporteaz i n cazul de fa. Oricum, dup cum se va vedea ulterior, multe elemente ale acestei metode sunt preluate de ctre metodele orientate-obiect. Strategii orientate spre informaii (orientate-date) Majoritatea specialitilor consider ca se poate obine un plus de stabilitate dac structura propriu-zis a sistemului informatic se limiteaz la descrierea datelor i a bazei de date, presupunndu-se c tipurile de date utilizate n cadrul organizaiei sunt supuse mai puin schimbrii dect prelucrrile din sistem. Aceast orientare a dus la apariia strategiei orientate pe date. Chiar dac valoarea datelor se schimb n mod constant, structura datelor nu presupune modificri

11

eseniale, dac ea a fost bine proiectat de la nceput. De regul, clasele de entiti n legtur cu care se vor memora datele n sistem nu se schimb, rareori fiind necesar introducerea unei noi clase de entiti, caz n care structura nu sufer transformri eseniale, ci presupune doar adugarea noii clase la structura existent. Termenul obiect", folosit n modelarea informaiilor sau modelarea semantic a datelor, este un simbol prin care se reprezint una sau mai multe ocurene" (cazuri) ale entitilor" lumii reale. Metoda este identificat prin urmtoarea ecuaie28: Modelarea informaiilor = Obiecte + Atribute + Relaii + Supertipuri/Subtipuri +Obiecte asociative. Coad i Yourdon spun c i n acest caz se poate vorbi despre existena a dou strategii. Strategia veche se bazeaz pe conceperea listei atributelor, gruparea lor n obiecte, stabilirea de relaii ntre ocurene" (cazuri), folosirea supertipurilor/subtipurilor pentru extragerea atributelor comune i definirea obiectelor asociative pentru reliefarea relaiilor sigure. Noua strategie este destul de apropiat de precedenta, cu excepia primului pas, care i propune mai nti s identifice obiectele lumii reale i apoi urmeaz descrierea lor cu ajutorul atributelor. Specialitii apreciaz salturile nregistrate ns, n acelai timp, fac inventarul conceptelor inexistente, cum ar fi: servicii, mesaje, motenire, structur. Strategii orientate-obiect Strategia orientat-obiect pune n centrul ateniei noiunea de obiect, considerat drept o entitate care se poate distinge dintre alte entiti i care are o semnificaie n contextul aplicaiei modelate. Obiectul asociaz datele i prelucrrile n cadrul aceleiai entiti, rmnnd vizibil doar interfaa obiectului. Un obiect comport un aspect static, reprezentat prin intermediul unor variabile de stare numite atribute i un aspect dinamic, reprezentat de comportamentul obiectului. Aspectul static este ascuns de aspectul dinamic. Sintagma orientat-obiect" este destul de greu de definit din cauza accepiunilor diferite care i s-au atribuit de diverse discipline. Numai n domeniul informaticii exist vreo trei variante: una folosit n modelarea informaiilor, alta n programare i a treia este cea de fa, utilizat n analiza i proiectarea sistemelor. Fiind un domeniu relativ

12

nou, este normal s existe o mare diversitate de opinii pn i asupra termenului obiect". Ecuaia ce caracterizeaz metoda, o redm n cele ce urmeaz29: Orientat-Obiect = Clase i Obiecte + Motenire + Comunicaii prin mesaje. Conceptele de obiect i clas sunt interdependente: un obiect aparine unei clase (este o instan a clasei), iar o clas este o grupare logic a obiectelor care au aceeai structur i un comportament similar. Un obiect este o abstractizare a datelor elementare i poate fi descris astfel30: Obiect = Identitate + Comportament + Stare. Identitatea obiectului se realizeaz printr-un identificator al obiectului, care este un atribut invariabil ce permite ca obiectul s fie referit independent de celelalte obiecte. Identificatorul este generat de sistem la crearea obiectului. Starea obiectului este o valoare care poate fi simpl (de exemplu, un literal) sau structurat (de exemplu, o list). In ultimul caz, ea poate fi compus din valori simple, referine la alte obiecte sau valori care ele nsi sunt structurate. Comportamentul unui obiect este definit printr-un set de operaiuni ce-i pot fi aplicate i este descris n clasa creia i aparine obiectul. Concluzionnd, putem afirma c obiectul este o abstractizare a datelor elementare, caracterizat printr-un identificator unic, invariabil, o clas creia i aparine i o stare reprezentat printr-o valoare simpl sau structurat. Deschiderea catre utilizarea tehnologiilor moderne este urmarea intelegerii necesitatilor bancare: Regandirea relatiei cu clientii Reorganizarea interna a activitatii privind procesele legate de exploatarea si limitarea restrictiilor spatio-temporale in raport cu clientii Capitalizarea si difuzarea cunostintelor in cadrul bancii Schimbarea planului managementului bancar Cresterea operativitatii, sigurantei si eficientizarii tranzactiilor intra si interbancare Alinierea la standardele europene si mondiale privind efectuarea tranzactiilor bancare si a schimbului de informatii

13

Arhitectura noilor sisteme informatice bancare are la baza o noua abordare caracterizata prin orientarea pe client, nu pe conturi sau produse si vizeaza in principal obiectivele bancii: introducerea la timp a noilor produse si servicii specificate in strategia de dezvoltare, posibila datorita parametrizarii si flexibilitatii deosebite ale solutiei standardizarea produselor oferite prin intermediul tuturor canalelor de distributie, posibila datorita modului de lucru centralizat automatizarea tranzactiilor complexe, posibila prin caracteristica de STP a solutiei posibilitatea de a raspunde la cerinte unicat venite din partea clientilor individuali sau corporate, utilizarea de valori specifice pentru parametrii definiti la nivel de client, contract sau chiar operatiune minimizarea riscurilor operationale, prin utilizarea politicilor multiple de securitate si a urmaririi modificarilor din sistem capacitatea de procesare a volumelor mari de tranzactii, prin scalabilitatea dovedita a solutiei oferirea de servicii bancare non-stop, prin posibilitatea de a genera tranzactii in regim 24x7 integrarea tuturor proceselor bancare intr-un singur sistem, prin functionalitatea extinsa, end-to-end a solutiei. OPERATIUNI Conturi curente Home banking Decontari electronice Depozite Certificate de depozit Carduri Casa Alte operatii (decontari facturi, incasari facturi etc) CLIENTI, subsistem ce permite actualizarea permanenta a datelor privind clientii bancii, prin gestiunea unica a clientilor CREDITE, asigurand gestiunea contractelor de credite cu doua module Gestiunea riscului Gestiunea propriu-zisa JURIDIC, dezvoltat pe doua module Legislativ Gestiunea creditelor litigioase

14

CONTABILITATE, cu urmatoarele functiuni de baza: Actualizarea planului de conturi Definirea conditiilor de dobanda la nivelul conturilor sintetice si analitice Definirea monografiei de operatiuni bancare Deschiderea si inchiderea conturilor interne Calculul, inregistrarea si plata/incasarea dobanzilor Situatii contabile de sinteza si raportare PERSONAL, asigurand gestiunea personalului si calculul salariilor MARKETING, oferind informatii specifice activitatii de conducere MANAGEMENT BANCAR, subsistem specializat in determinarea si

monitorizarea indicatorilor de rating bancar

7. Ciclul de via a unui sistem informatic Sistemul informatic (SI) ca orice entitate a lumii reale prezint propriul su ciclu de via. Ciclul de via presupune parcurgerea unor etape, descompunerea la rndul lor n faze, care asigur: conceperea, realizarea, implementarea, exploatarea i ntreinerea sistemului. Diferitele abordri au condus la precizarea unor faze comune ale ciclului de via: 1. Definirea cerinelor utilizatorului 2. Specificaia cerinelor sistemului 3. Specificaia cerinelor software 4. Proiectarea general 5. Proiectarea de detaliu 6. Realizarea componentelor SI 7. Testarea componentelor 8. Integrarea componentelor 9. Implementarea i testarea produsului 10. Exploatarea i ntreinerea sistemului 11. Dezvoltarea SI

15

8. Strategii de parcurgere a etapelor din ciclul de via n realizarea sistemelor informatice Pornind de la ciclul de via al sistemelor spre cel al obiectelor, surprindem o sintagm esenial n activitatea de analiz i proiectare a sistemelor, respectiv ciclul de via al dezvoltrii sistemelor (CVDS) sau ciclul dezvoltrii sistemelor (CDS). Ciclul de via al dezvoltrii sistemelor este o metodologie comun de dezvoltare a sistemelor din multe organizaii, caracterizat prin cteva faze care marcheaz evoluia eforturilor de analiz i proiectare a sistemelor". Prin parcurgerea materialelor de specialitate, am putut constata c numrul fazelor/etapelor variaz de la trei (de exemplu: analiz, proiectare, implementare) la peste douzeci. Firesc, n cel de-al doilea caz, nici simpla enumerare a lor nu este edificatoare. Totui, s-ar putea formula o concluzie: n fazele incipiente de abordare a sistemelor, numrul etapelor se situa la aproximativ ase. Ele erau descompuse pe activiti, subactiviti, operaiune fireasc, apreciem noi, datorit influenei gndirii bazate pe descompunerea funcional, care era la mod. Prin trecerea la orientarea-procese i orientarea-date, considerm c s-au nregistrat dou fenomene: diversificarea etapelor; revizuirea modelului sub care se manifest ciclicitatea. Datorit marii diversiti a opiniilor, considerm binevenit o descriere sumar a mai multor modele, cu att mai mult cu ct n literatura noastr subiectului de fa nu i se acord importana cuvenit. Modelul cascad este unul de referin, asigurnd trecerea de la o etap la alta, ce-i drept mai mult teoretic, n ordine secvenial. Realitatea a demonstrat c parcurgerea etapelor/fazelor ntr-o astfel de ordine nu este o regul, ntruct, de cele mai multe ori, se nregistreaz reveniri la etapele anterioare sau parcurgerea n paralel a unora dintre ele.

16

Modelul V este o variant a modelului cascad, prin care se introduc conceptele de sistem i componente (subsisteme), aplicndu-se teste explicite la un sistem ierarhic pentru creterea controlului asupra modului n care se desfoar etapele. Tocmai aceast nlesnire constituie o latur a literei V. Prima este latura din stnga, parcurs descendent, i conine treptele propriu-zise, iar cea de-a doua latur, din dreapta, se parcurge ascendent, pe ea realizndu-se verificrile i validrile elementelor create anterior. Acest model puncteaz cu mai mult claritate separrile dintre ceea ce implic participarea utilizatorului, modelul arhitectural i cel al implementrii. Utilizatorul este implicat doar n fazele din partea superioar a V-ului.

Modelul incremental, este o alt variant a modelului cascad care promoveaz ideea proiectrii i realizrii independente a componentelor dup definirea arhitecturii globale a SI. Proiectarea i realizarea SI se face astfel n conformitate cu principiile metodelor top17

down. Sistemul va putea fi livrat beneficiarului i etapizat pe msura realizrii componentelor (n funcie de prioritile formulate de beneficiar) dar, ntr-o astfel de abordare pot aprea dificulti legate de integrarea componentelor n sistemul final.

Modelul spiral este lansat de unul dintre specialitii cu preocupri mai vechi legate de ciclul de via, B.W. Boehm. Acesta s-a ocupat de aa-zisele modele tradiionale nc din anul 1981, iar n 1986 anun modelul spiral i public rezultatele cercetrii sale n 1988. El se bazeaz pe dou convingeri: natura iterativ a dezvoltrii i nevoia de planificare i evaluare a riscurilor fiecrei iteraii; deficiena nregistrat la modelul V, n care validarea se efectueaz prea trziu, l face s propun, dimpotriv, realizarea acesteia ct mai devreme posibil, de ct mai multe ori, prin construirea prototipurilor, conform modelului simplificat din figura de mai jos:

In principiu, modelul evolutiv const n efectuarea unei investigaii iniiale, elaborarea unei strategii pentru descompunerea proiectului n pri/segmente, fiecare cu o valoare deosebit pentru client. Ele sunt realizate i livrate n mod iterativ i contribuie la sporirea treptat a performanelor sistemului. Formele obinute pentru prile componente nu sunt foarte puternic detaliate, lsndu-se loc pentru adaptri i modificri ulterioare.

18

Modelul tridimensional a fost lansat n Frana i susinut de adepii acestei coli. El a fost introdus odat cu metoda Merise. Susintori ai modelului (Bouzeghoub, Gardarin, Valduriez) acetia consider c este singurul model care ine cont de aspectele impuse de bazele de date, prin ncorporarea clar a nivelurilor ANSI/SPARC. Modelul surprinde dezvoltarea sistemelor printr-o redare grafic bazat pe trei axe, descriind ciclul de via al sistemului, ciclul de via al proiectului i ciclul de via al abstractizrii .

19

Modelul X i propune s extind aria performanelor obinute prin modelele cascad i V, ambele fiind considerate ca exemple de modele ale procesului de dezvoltare care, la rndul lui, ar fi parte integrant a unui proces mai larg, al livrrii sistemelor, pentru care Hodgson, n 1991, propune un model special. Modelul X exprim dou mari categorii de cicluri de activiti: una derulat nainte (forward activity), care sintetizeaz sistemul nou (sau modificat) i o activitate derulat napoi (reverse activity) pentru dobndirea sistemelor i a componentelor lor, pentru catalogarea diverselor modele, arhitecturi i componente ale activitii finalizate pentru o posibil reutilizare. Ingineria preventiv (forward engineering) de la nivelul fiecrui stadiu al procesului ncearc s reutilizeze prin selecie, adaptare, rafinare - acumulrile anterioare care se regsesc n bibliotecile sistemelor. Schematic, modelul X este prezentat n figura de mai jos.

20

Modelul fntn artezian i are originea n modelul spiral i n altele care au reprezentat mbuntiri ale acestuia. Ne referim la modelul spiral ierarhic i vrtej de ap.

21

Tema - exemplu Etape de proiectare n ciclul de via al unui SI. 1. Proiectarea general (conceptual) a SI n conceperea i realizarea SI, proiectarea general (PG) deine o pondere deosebit, deoarece aceasta definete structura i funcionalitatea noului sistem n raport cu obiectivele i cerinele beneficiar. Etapa de PG a unui SI are ca obiectiv elaborarea concepiei logice a SI, adic definete SI att structural, ct i funcional. Cu alte cuvinte, proiectarea general asigur modelarea conceptual a noului sistem, inclusiv stabilirea componentelor de sistem (subsisteme i uniti funcionale), a legturilor dintre acestea i a funcionalitii structurii sale n aa fel, nct ntregul sistem s acioneze ca un tot unitar. Astfel, la etapa de proiectare general sunt definite obiectivele noului SI, se determin structura bazei informaionale, se asigur formalizarea atributelor de intrare i se proiecteaz organigrama noului sistem. Organizarea i conducerea proiectrii generale presupune stabilirea unui colectiv pentru realizarea proiectrii generale i elaborarea unui plan de realizare a acestei etape. Managerul de proiect asigur planificarea, organizarea, coordonarea i urmrirea ntregii activiti, elaboreaz graficul de desfurare a fazelor proiectrii generale, stabilete, pentru fiecare faz, termenul de realizare, obiectivele specifice i personalul implicat. PG presupune folosirea unor variante de abordare, utilizate n funcie de urmtorii factori: Complexitatea obiectivelor stabilite; Aria de cuprindere a noului SI; Posibilitile de modificare a ieirilor solicitate de unitatea beneficiar (UB). Aceste variante sunt bazate pe aplicarea anumitor principii, i anume: IEIRI INTRRI; INTRRI IEIRI; MIXT. solicitate de ctre

22

Varianta IEIRI INTRRI ncepe cu precizarea obiectivelor noului SI, n raport cu cerinele UB. Obiectivele sunt concretizate n ieirile sistemului ale cror atribute formeaz baza informaional (BI) de ieire care este analizat n raport de modul de obinere a atributelor de ieire, n scopul definirii BI de intrare. Prin urmare, aceast variant presupune parcurgerea urmtoarelor faze: Definirea obiectivelor SI; Definirea ieirilor SI; Definirea BI; Formalizarea atributelor, care include: o Codificarea atributelor; o Adaptarea documentelor de intrare. Definirea structurii funcionale a SI; Elaborarea documentaiei PG. Avantajul acestei variante se explic prin furnizarea unui coninut complet al BI de intrare, determinat strict pe baza ieirilor solicitate. Dezavantajul imposibilitatea obinerii de noi rapoarte sau indicatori. n cazul schimbrii coninutului i setului de ieiri

informaionale de ctre UB, este necesar o reexaminare a coninutului BI de intrare. Varianta INTRRI IEIRI pornete de la determinarea

obiectivelor, iar apoi se determin mulimea intrrilor necesare, structurate sub forma BI de intrare, care este analizat n vederea BI de ieire. Adic, aceast variant include urmtoarele faze: Definirea obiectivelor SI; Inventarierea tuturor atributelor de intrare i a legturilor sau

corespondenelor dintre acestea pe baza documentelor de intrare utilizate; Definirea BI de intrare; Formalizarea atributelor, care include: o Codificarea atributelor; o Adaptarea documentelor de intrare. Definirea ieirilor SI; 23

Definirea structurii funcionale a SI; Elaborarea documentaiei PG.

Avantajul acestei variante flexibilitatea coninutului BI de intrare n condiiile apariiei de modificri ale ieirilor informaionale. Dezavantajul BI este supradimensionat, ceea ce implic timp mare de realizare , costuri ridicate de proiectare, realizare i o sporire a complexitii prelucrrilor SI. Varianta MIXT are n vedere definirea modelului conceptual al SI folosind avantajele celor dou variante prezentate. Varianta include urmtoarele faze: Definirea obiectivelor SI; Definirea iniial a BI; Formalizarea atributelor de intrare i ieire, care include: o Codificarea atributelor; o Adaptarea documentelor de intrare; o Definirea BI de ieire i stabilirea ieirilor prezente i previzibile; Redefinirea BI iniiale i stabilirea structurii finale a acesteia; Definirea structurii funcionale a SI; Elaborarea documentaiei PG. Analiznd variantele prezentate rezult c, fazele PG sunt comune tuturor variantelor de abordare, dar succesiunea lor este difereniat de la o variant la alta. n general, se opteaz pentru una dintre variante, avnd n vedere: Obiectivele SI; Dimensiunea SI; Volumul atributelor BI; Costurile i termenul de realizare a SI, etc.

n concluzie, buna desfurare a etapei de proiectare conceptual oblig conducerea unitii beneficiare s analizeze pe parcurs stadiul lucrrilor, s sintetizeze toate cerinele utilizatorului ntr-un mod ct mai eficient, s evalueze toate variantele, s selecteze i s avizeze cea mai bun cale de obinere a informaiilor necesare. 24

2. Proiectarea de detaliu a sistemului informatic. Obiectivul proiectrii de detaliu (PD) presupune transformarea modelului conceptual al noului sistem ntr-un model operaional (tehnic, de detaliu), n concordan cu un sistem de gestiune a datelor i un sistem electronic de calcul. Proiectarea de detaliu este una din cele mai dificile etape a ciclului de via al sistemului informatic, de aceea necesit un deosebit efort managerial privind organizarea, urmrirea i controlul activitilor vizate. Acesta presupune organizarea colectivelor de specialiti i repartizarea sarcinilor, atribuiilor i responsabilitilor, supravegherea activitilor de proiectare de detaliu a unitilor funcionale i unitilor de prelucrare, supravegherea termenelor, respectrii metodologiilor de elaborare,

evaluarea soluiei optime de gestiune a datelor i a sistemului electronic de calcul, validarea rezultatelor obinute n raport cu cerinele, normativele i standardele prestabilite. Astfel, printre activitile etapei de PD pot fi enumerate urmtoarele: Proiectarea ieirilor i intrrilor SI; Proiectarea BI; Definirea sistemului de fiiere i / sau bazei de date; Realizarea programelor; Organizarea procesului tehnologic de prelucrare a datelor.

Not: Caracteristica detaliat a acestor activiti, va fi prezentat n tema ce va urma.

9. Implementarea i exploatarea sistemului

informatic.

n literatura de specialitate se menioneaz c etapa de implementare este piatra de ncercare a sistemului informatic. Obiectivul implementrii presupune testarea (verificarea) sistemului proiectat i realizat fizic n condiiile reale din unitatea beneficiar i aducerea la stadiul de funcionare i exploatare efectiv. 25

Aceast etap include multe aspecte specifice care impun deosebite activiti manageriale, materializate prin planificarea implementrii i prin asigurarea condiiilor organizatorice, financiare, materiale, informaionale i informatice necesare implementrii, inclusiv asigurarea operativitii, calitii i acurateei datelor de intrare. De asemenea, aceste activiti includ i verificarea performanelor sistemului informatic proiectat. Elaborarea planului de implementare asigur repartizarea n timp a lucrrilor, resurselor i sarcinilor personalului care realizeaz punerea n funciune a sistemului proiectat. De asemenea, se stabilete succesiunea procedurilor i activitilor presupunnd realizarea implementrii i conversiei n condiii de maxim eficien i minime de timp. Exploatarea curent i meninerea n funciune a sistemului informatic include activitile viznd utilizarea propriu-zis a sistemului informatic din unitatea beneficiar i activitile de perfecionare i meninere n stare funcional i operaional a acestuia, pn la nlocuirea sa cu un alt sistem informatic mai performant, adic pn la finele ciclului de via al sistemului.

Exemplu Concepia i optimizarea sistemelor informatice financiar bancare Concepia i optimizarea sistemelor informatice financiar bancare trebuie s se realizeze pe 3 niveluri: decizional datawarehouse & reporting front office back office

1. Decizional (nivelul conducerii) Prioritile sunt reprezentate de flexibilitatea structurilor de date, serverele puternice, prelucrrile au ca scop actualizarea permanent a datelor. 2. Datawarehouse & reporting (nivelul conducerii) Datawarehouse depozite de date (baze de date multidimensionale)

26

- permite prin instrumentele sale specifice (analiza multidimensional) explorarea informaiilor stocate i crearea legturilor dintre datele actuale i cele istorice. - structurile de date ofer o interogare performant a cererilor multiple. Exemplu: Orice banc dispune de o colecie mare de date despre clienii si, dar este gestionat dispersat. 3. Front office / Back office Front office relaia clientului cu banca (telefon, suport de hrtie, e-mail, web) - interfaa utilizatorului pentru operaiuni de cont curent, gestionarea portofoliului, asisten Middle office permite circulaia datelor n dublu sens reinndu-le prin dou imagini separate ale datelor rolul de baz este informaiilor b) asigurarea managementului calitii c) asigurarea distribuiei informaiei i a) colectarea, agregarea i consolidarea

raportarea Back office stocarea i prelucrarea datelor locul unde se execut procesele tranzacionale aici se gsesc aplicaiile i bazele de date locul de unde i i-a informaia Front office-ul

10. Definiia i coninutul metodologiilor Metodele i conceptele fundamentale de realizare a sistemelor informatice financiar bancare au la baz termenii de metod i metodologie asociai direct domeniului financiar bancar. Aceti termeni se definesc innd cont de: specificul domeniului financiar bancar evoluia cadrului legislativ dinamica activitii de informatic i tendinele fundamentale de evoluie a sistemelor financiar bancare. 27

Metoda reprezint totalitatea conceptelor, modelelor, nivelelor, etapelor i tehnicilor specifice de formalizare necesare pentru definiiile, listele, comunicaiile, datele i prelucrrile specifice unui sistem informatic financiar bancar. Metodologia reprezint setul finit particular definitoriu al unei metode prin intermediul unui sistem coerent de formulare i/sau de procese informatice prin care se modeleaz i formalizeaz unu sistem informatic financiar bancar. Metodele de proiectare se pot clasifica n trei mari categorii: metode structurate, metode sistemice i metode orientate obiect. Metodele structurate sau ierarhice folosesc descompunerea progresiv descendent top-down. Concepia const n crearea unui ansamblu unitar n interaciune, avnd fiecare o funcie clar definit. Avantajele acestor metode constau n simplitatea i buna adaptare la cerinele utilizatorului. Dezavantajele pornesc de la conceperea sistemelor informatice conform cerinelor analizei funcionale, ceea ce determin un efort de analiz i proiectare mai mare asupra prelucrrilor n condiiile n care acestea sunt cele mai supuse modificri n timp, iar modelarea datelor este trecut n planul secund. Cea mai reprezentativ dintre metode este SADT (Structured Analisys and Design Tehnique). Metodele sistemice permit vizualizarea i nelegerea organizrii datelor. Specific acestor metode este utilizarea teoriei sistemelor n abordarea ntreprinderii. Sistemul informatic este abordat sub dou aspecte complementare datele i prelucrrile analizate i modelate independent, reuniunea lor fcndu-se ct mai trziu posibil. Metodele sistemice acord o mai mare importan datelor care trebuie s respecte urmtoarele niveluri de abstractizare: Nivelul conceptual Nivelul logic Nivelul fizic.

Nivelul conceptual are ca obiectiv identificarea regulilor de gestiune i definirea modelului conceptual al datelor i prelucrrilor. 28

Nivelul logic

urmrete validarea modelului conceptual al datelor i

evidenierea particularitilor organizatorice. Nivelul fizic fixeaz reguli de ordin tehnic privitoare la sistemul informatic, definitiveaz soluia de implementare a modelului datelor i definirea procedurilor.

MCD modelul conceptual al datelor

DATELOR

MLD modelul logic al datelor

MFD modelul fizic al datelor MODELUL

MCP modelul conceptual al prelucrrilor

PRELUCRRILOR

MLP modelul logic al prelucrrilor

MFP modelul fizic al prelucrrilor

Metodele obiectuale a treia generaie de metode de proiectare. Primele concepte aprute n 1980 privea tehnologia OO (orientate obiect). Caracteristic acestor metode este faptul c sistemul informatic este gndit ca un ansamblu de obiecte autonome care se organizeaz i coopereaz ntre ele. Datele i prelucrrile (metodele) se gsesc ncapsulate (inaccesibile celorlalte obiecte) n cadrul aceleiai structuri obiectul.

29

Avantajele metodelor obiectuale sunt reutilizarea componentelor de program i posibilitatea utilizrii obiectelor complexe. Dezavantajele acestor metode decurg din aspectul c nu totdeauna realitatea poate fi reprezentat prin obiecte. 11. MODELAREA CONCEPTUAL A DATELOR Modelul Entitate-Asociere (EA) Modelul conceptual al datelor este un ansamblu de concepte i reguli de combinare a acestora permind reprezentarea realitii. Modelul Entitate-Asociere (EA) urmrete obinerea unei reprezentri fidele a realitii. Conceptele de baz utilizate de ctre modelul EA ENTITATEA reprezint un obiect al realitii modelate, caracterizat de o existen proprie, cu o identitate proprie i o mulime de caracteristici care exprim proprietile acestuia. Ex. n gestiunea produselor finite putem defini entiti ca: un produs, un bon de comand, , o comand. n activitatea de modelare interesul se focalizeaz pe definirea tipului de entiti aparinnd problemei de rezolvat i nu pe entiti care reprezint realizrile tipurilor de entiti. TIP DE ENTITATE reprezint un concept generic desemnnd mulimea tuturor entitilor prezentnd aceleai caracteristici constructive. Ex contract, depozit bancar, ordin de tranzacionare. ATRIBUTUL definete o proprietate distinct a unei entiti. Fiecare atribut are un domeniu, adic un set de valori posibile admise. Clasificarea atributelor. a) dup complexitate - elementare (simple) ale cror realizri nu mai pot fi descompuse Ex. unitate monetar, numrul de cont - decompozabile (complexe) Ex data calendaristic se descompune n zi, lun, an b) dup realizri - obligatorii: s prezinte obligatoriu o valoare NOT NULL - opionale: pot s nu aib nici-o realizare Ex telefon, e-mail - monovaloare: are o singur valoare n cadrul entitii Ex. CNP, nr cont 30

- multivaloare: prezint mai multe realizri n cadrul aceleiai entiti Ex conturi la bnci

Din punct de vedere al rolului pe care l ndeplinete acel atribut n cadrul modelului distingem atribute cu rol de: a. chei candidate sunt acele atribute care prin natura lor sunt susceptibile de a juca rolul de cheie primar sau de identificator n cadrul unui tip de entitate; b. cheie primar sau identificator reprezint acel atribut sau grup de atribute, care n cadrul tipului de entitate reuete, prin valorile pe care le ia, s scoat n eviden o anumit entitate din mulimea entitilor care prezint acelai comportament. Rezult c o cerin esenial pentru valorile pe care le poate lua acest gen de atribut, este ca acestea s fie unice n toat mulimea valorilor pe care le poate lua acel atribut. Ex: atributul cod numeric personal, prin valorile pe care le poate lua poate conduce la identificarea n mod unic a entitii Georgescu din mulimea entitilor care formeaz tipul de entitate Client; c. cheie extern reprezint un atribut sau o multime de atribute

definite pe aceiasi multime de valori ca i cheia primar, rolul su fiind acela de a putea stabili o asociere ntre dou sau mai multe tipuri de entiti care n realitatea modelat, interacioneaz ntre ele. Atributul este perceput ca o variabil care poate lua valori ntr-un anumit domeniu. Putem spune c domeniul reprezint mulimea tuturor valorilor posibile pe care le poate lua un atribut ntr-o anumit perioad de timp. Cteva precizri cu privire la cheile candidate i cheile primare sunt prezentate n cele ce urmeaz. S considerm c n realitatea modelat putem identifica un tip de entitate numit Societi comerciale. Mulimea atributelor care definesc acest tip de entitate sunt Codul unic de nregistrare, Numrul de nregistrare, Cod IBAN, Numele societii, Adresa societii. Modul de reprezentare a acestui tip de entitate

Societi comerciale Cod unic de nregistrare Numrul de nregistrare 31 Cod IBAN Numele societii Adresa societii

MCD-ul care se realizeaz folosind conceptele prezentate reprezint, n mod grafic-schematic, modelul semantic, abstract, al domeniului de informatizat: organismul economic sau compartimentul specializat al acestuia pentru care seproiecteaz sistemul informatic de gestiune. Prin urmare, la realizarea acestuia se folosesc simbolurile grafice ale conceptelor de baz, rolul fundamental n construirea acestuia revenind cuplului ET AST. Dou cupluri ET - AST, formate din dou ET diferite care particip la aceeai AST, definesc un bloc conceptual elementar, care se noteaz sub forma ET - AST - ET. MCD-ul construit pentru un domeniu de gestiune al unui organism economic este practic format dintr-o succesiune de blocuri conceptuale elementare. Figura 5.2 prezint schema unui bloc conceptual elementar dintr-un MCD.

ET (entitate tip)

soc

ET (entitate tip)

AST (asqcierc tip)

Nume AST (verb)
Nunie F.T

1
X,Y
(cardinalitate)

X,Y

Nunie ET , (substantiv) Nume AT {atribute tip) r (substantiv)

Nume AT-*
jt i i hut tip) en rol de identificator Nume AT (a tribute tip (substantiv)

X (cardinalirate
.: in ii I

{cardinalitate)

Nunie AT (atribute tip) (substantiv)

X (cardinalitate mini mala)

Nume AT (atribute tip) cu rol dc idcntificator

Y (cardinalimtc mini mala)

RolA

roluri ETAsiBtnASTR

RolB

32

n modelul EA obiectelor le corespund entiti. Obiectele sunt de mai multe feluri: obiecte simple crora le corespund un tip de entitate obiecte compozite cu atribute multivaloare obiecte compuse ce sunt decompozabile dar au in structura lor tot atribute simple

Asocierea dintre entiti arat legtura dintre acestea i rolul entitii participante la legtur. 33

Tipul de asociere reprezint ansamblul legturilor cu aceeai semnificaie dintre entitile aparinnd la dou sau mai multe tipuri de entiti .

11. Relaii sau asocieri ntre date

Prin natura a ceea ce reprezint atributele interactioneaz, relaioneaz ntre ele formnd un tot unitar numit entitate. Conceptul care descrie aceast relaie ntre atribute poart denumirea de dependen functional. Dependena funcional reprezint o proprietate a semnificaiei sau a semanticii atributelor, indicnd modul n care sunt legate atributele unele de altele. Numim dependen funcional simpl o legtur stabilit ntre dou atribute notate A i B apartinand unei relatii R, pentru fiecare valoare cunoscut a atributului A se antreneaz n mod sistematic asocierea aceleiai valori pentru atributul B. Reprezentarea grafic pentru o astfel de dependen funcional este simbolizat printr-o sgeat avnd o orientare de la atributul A ctre atributul B.

Un tip aparte de dependenta functionala o reprezinta dependenta functionala multivaloare. Fie atributele A, B, si C aflate intr-o relatie R, exista o dependenta functionala multivaloare atunci cand pentru fiecare valoare a atributului A exista o multime de valori pentru atributul B si o multime de valori pentru atributul C. Totusi, multimile de valori ale atributelor B si C sunt independente unele de altele. Vom reprezenta o dependenta functionala multivaloare printr-o sgeata dubla de la determinant catre determinat

Legturile sau asocierile care se stabilesc ntre mai multe tipuri de entiti. ntr-o baz de date relaionl, datele sunt stocate n mai multe tabele, deci este importnt ca sistemul s poat reuni corect informaiile ntre care exist legturi. Astfel relaiile se constituie prin precizarea unei legturi ntre un cmp sau o combinaie de cmpuri ale unui tabel i cmpurile corespunztoare din alt tabel.

34

Tipologia asocierilor 1.Relaia unu-la-unu (one-to-one), se mai numete i biunivoc. Dou tabele unite printr-o relaie unu la unu sunt similare, n practic, cu un tabel care cuprinde toate cmpurile celor dou tabele. 2. Relaia unu-la-muli (one-to-many). n practic acest tip de asociere este cel mai des ntlnit. ntr-o asociere de tipul unu-la-muli o nregistrare din tabelul A i corespunde mai multe nregistrri din tabelul B, iar unei nregisrri din tabelul B i corespunde cel mult o nregistrare din tabela A. 3. Relaia muli-la-muli (many-to-many). Acest tip de relaie are un caracter mai general, unei nregistrri din tabelul A i pot corespunde mai multe nregisrri din tabelul B, iar unei nregistrri din tabelul B i pot corespunde, de asemenea, mai multe nregistrri din tabelul A. n mod uzual reprezentarea grafic a unei asocieri ntre dou tipuri de entiti se simbolizeaz printr-o elips n care se trece numele asocierii. A a d b c Asociere 1:1 B x y e z A a b c d e Asociere 1:n B x y z t w A a b c d e Asociere m:n B x y z t w

Strns legat de asocieri l reprezint conceptul de cardinalitate. Putem defini cardinalitatea ca fiind un cuplu de numere ntregi de forma (x,y), care exprim numrul

35

minim (x) i numarul maxim (y) de realizri ale unei instane (realizri) ale tipului de entitate care participa la o asociere. X se numete cardinalitate minimal, desemnnd obligativitatea unei realizri de a participa la o asociere, iar Y se numete cardinalitate maximal fiind perceput ca volumul participrii la asociere.

12. CARDINALITATEA Cardinalilatea unui cuplu entitate-asociere se definete ca fiind cuplul de valori ntregi (x,y), astfel nct: x reprezint cardinalitatea minimal i exprim numrul minim de realizri ale legturii (asocierii) ce exist pentru o entitate. y reprezint cardinalitatea maximal i exprim numrul maxim de apariii ale corespondenei ce pot exista pentru o entitate. Valorile uzuale sunt: a) Cardinalitatea minimal 0, va putea exista n cazul n care exist entiti care s nu participe la nici-o asociere. Exemplu exist poteniali clieni ai unei firme crora nc nu li s-a ncheiat polie de asigurare, deci cardinalitate minimal 0.

b) Cardinalitate minimal 1, va putea exista n cazul n care toate realizrile tipului de entitate trebuie s participe la o realizare a tipului de asociere. Exemplu orice contribuabil aflat n evidena administraiei financiare are deschis un rol i numai unul singur.

36

c) Cardinalitate maximal 1, arat faptul c toate entitile particip la o asociere i numai la una. Exemplu numrul de roluri deschis unui contribuabil nu poate fi mai mare de 1. d) Cardinalitate maximal n, indic faptul c mai multe entiti de un anumit tip particip la o ascociere. Un client emite unul sau mai multe ordine de plat.

Furnizori 1,n

1,n

Furnizeaz

0, n

Mat_prime 0,n

Clieni

Cumpr Cantit_cumprat

Produse

37

13. Reguli de verificare a Modelului Conceptual al Datelor:

1. Unicitatea numelor se aplic tuturor elementelor ce particip la definirea MCD: ET, AST, AT, roluri: se elimin din model omonimele i sinonimele. Ex.: un atribut tip i o entitate tip nu pot avea acelai nume Produs, entitatea tip o vom numi Produs iar atrib Nume_produs 2. Unicitatea atributelor (neredondana) AT trebuie s def o sg ET sau AST 3. Unicitatea asocierilor fiecrei asocieri i corespunde o sg. entitate a ET participante la AST; o asociere nu poate exista decat o sg data intre aceleasi entitati; 4.Atributul tip al unei asocieri tip este atributul determinat de mai muli determinani, ID ai ET def de acetia (caracterizeaz AST creat ntre ET definite de determinanii si) 5. Evitarea includerii n MCD a atributelor rezultate din calcule- prez ac tipuri de atribute se justific numai dac sunt relevante i frecvent utiliz; Ex: la app salarii e util def unei entit tip ( Salarii) care are ca atrib tip calculate Salariul brut, Baza de calcul, Baza de impozitare, Deduceri personale, necesare pt realiz lunar a stetelor de sal, a unor rap statistice, ntocmirea fielor fiscale, elib de adeverine, etc. 6.Atributele decompozabile se pot menine n MCD dac prelucrrile nu impun desc lor pe componente; Ex: atrib tip Adersa ntr-un Si pt. Administraia Financiar se desc pe componente deoarece contribuabilii sunt adesea select pe sect, strzi i nr; n cazul unui Si pt. secretariatul unei Fac ac atrib nu se desc pt c nu intereseaz componentele lui. 7. Identificatorii ET trebuie s fie formai din nr. min de atribute, trebuie sa aiba val unice si nenule 8. Val NULL (NULL nseamn nici o valoare/realizare/nregistrare, e dif de zero sau spaiu): - AT cu rol de ID sunt obligatorii ( trebuie s aib val/realizri); - exist ET care au AT opionale ( tel, eMail); n cadrul tipului de entit se pot def subtipuri de entit care cuprind doar atrib tip specifice acelei submulimi de entit;

14. Restricii de integritate

Restriciile de integritate definesc cerinele pe care datele trebuie s le respecte pentru a fi corecte i coerente n raport cu realitatea de modelat. Restriciile de integritate surprind urmtoarele aspecte: valorile atributelor entitii i asocierile valorile identificatorilor entitilor rolurile entitilor n asocieri asocierile stabilite ntre entiti 38

Restriciile de integritate pot fi statice (se verific permanent) dinamice (privesc evoluia n timp a datelor)

Exemple de restricii:

restricii de domeniu (condiiile valorile admise ale atributelor n cadrul domeniului)

Exemplu Unitatea Msura KG, BUC

restricii structurale ( implica dou aspecte a)identificarea entitilor, b) tipul de

entitate prezent

restricii de integritate de roluri restricii de integritate de asocieri

15. MODELAREA CONCEPTUAL A PRELUCRRILOR (MCP)

Prelucrrile reprezint partea dinamic a sistemului informaional. Pentru modelarea conceptual, abstract, a prelucrrilor se folosete un model semantic de reprezentare a prelucrrilor. Acest model se bazeaz pe semnificaia acestora n lumea real. ntrebarea la care trebuie s rspund sistemul informatic economic este CE ? prelucrri au loc pentru a descrie corect i complet ceea ce face sistemul vis-a-vis de obiectivul economic propus. Modelul conceptual al prelucrrilor prezint: - activitile desfurate de sistemul economic pentru realizarea obiectivului propus - evenimentele i succesiunea lor de declanare a acestora - operaiile pe care le presupune fiecare dintre activitile desfurate i nlnuirea lor n timp - sincronizarea timpului cu legislaia i regulile n vigoare - rezultatele obinute n urma execuiei operaiilor

Cerere de credit

Modelul conceptual al prelucrarilor este modelul "eveniment-rezultat" al metodei Merise, ce repune in discutie procedurile (elementele) abordate de MCD formuland pentru fiecare element intrebari de forma: - acest element este indispensabil si ce se intampla daca il suprimam; - exista posibilitatea de a-l suprima (atentie la normele juridice si reglemantarile legale; - cat costa mentinerea acestui elemet in procedura sau ce avantaje se obtin din mentinerea lui. Modelul conceptual al prelucrarilor, vede intreaga prelucarare ca o succesiune ordonata si logica de proceduri inlantiute, toate in concordanta stricta cu

Operati a
Reguli de emisiune

Credit acordat

39

A si B

legislatia in vigoare (este vorba de un demers tipic de analiza a valorilor). Nu se poate trece cu vederea impactul utilizarii instrumentului informatic (SGBD) asupra MCP. Astfel, anumite validari pot fi efectuate inca de la culegerea datelor, in loc sa se constate ulterior ca datele sunt complete sau eronate, deci anumite operatii din MCP pot fi eliminate. Concepte de baza Ca si n cazul modelului conceptual al datelor, formalismul modelelor de prelucrare se bazeaza pe construirea unei diagrame avnd trei elemente de baza: a) evenimentul declansator, reprezentat grafic printr-o elipsa, de la care pleaca o sageata de legatura pentru simplificare, daca este necesar, elipsa poate fi omisa b) operatia, reprezentata grafic printr-un dreptunghi ; c) rezultatul (evenimentul emis), reprezentat tot printr-o elipsa d) sincronizarea, reprezentata grafic printr-un triunghi orientat catre operatie. Evenimentul declansator Desemneaza un fapt a carui aparitie declanseaza o reactie n cadrul organizatiei; aparitia unui eveniment va antrena derularea de activitati, de operatii, reprezentnd motorul unei actiuni, al unei operatii ( de ex. sosirea unui document). Pentru ca MCP sa fie ct mai stabil, el trebuie sa fie independent de aspectele organizatorice si tehnologice, chiar geografice. De ex. Sosirea unei comenzi de la un client este un eveniment declansator, de natura extern. A satisface aceasta cerere nseamna a o transforma ntr-o livrare de produse. Descrierea continutului prelucrarilor necesare trebuie sa fie independenta de: aspectele tehnologice (se utilizeaza calculatorul sau nu ?) aspectele geografice (comanda este prelucrata la depozit sau n alta parte ?) aspecte organizatorice (livrarea este facuta de X la serviciul comercial sau de Y la magazie ?) aspecte temporale (livrarea se face dimineata sau seara ?). Tip eveniment Este un concept generic descriind toate aparitiile evenimentelor de aceeasi natura. Capacitatea sistemului de a percepe aceste aparitii este exprimata de doi parametri : capacitatea : indica numarul maxim de aparitii ale acestui tip de eveniment care pot fi percepute de sistem si frecventa : indica legea de manifestare a acestor aparitii. Categorii de evenimente Un eveniment poate fi : extern (receptionat din exterior) : primirea unui CEC, a unui aviz de plata, solicitarea unui credit, etc.

40

intern (generat de activitatea sistemului ntreprindere) : pana unei masini, gasirea unei solutii, etc. Pentru a avea un eveniment trebuie sa coexiste anumite conditii: - sa se ntmple ceva (n afara sau n interiorul ntreprinderii) - acest ceva trebuie sa fie perceput de sistem (care trebuie sa fie dotat cu mijloace capabile sa l perceapa) - ntreprinderea sa fie interesata, vaznd n el un posibil eveniment declansator al activitatii sale. Operatia Se numeste operatie orice actiune (sau secventa continua de actiuni), producatoare de evenimente rezultat, care se executa fara ntrerupere, ca reactie la un eveniment declansator (sau a mai multor evenimente declansatoare sincrone). O operatie constituie un bloc nentrerupt (nu trebuie sa apara rezultate intermediare n interiorul unei operatii). Tip de operatie

O categorie de operatii ce prezinta aceleasi caracteristici. Un anumit numar de parametri caracteristici permit specificarea unui anumit tip de operatie: - desemnarea operatiei nsasi; - durata exprimata n unitati de timp - actiunile elementare constitutive - evenimentele emise si conditiile de emitere. O operatie se finalizeaza ntotdeauna prin emiterea de evenimente functie de situatiile identificate pe parcurs si de conditiile exprimate de aceste situatii (asa-numitele reguli de emisiune). Remarca. O operatie se desfasoara n timp, avnd o anumita durata. La un moment dat ea poate fi : - n asteptarea executiei; - n curs de executie si - terminata.

41

Denumire cod operatie operatie Actiune ( Actiuni) Reguli de emisiune

Rvenimente emise - rezultate

Rezultatul (evenimentul emis) .

Numim rezultat produsul executarii unei operatii. ntotdeauna trebuie respectata urmatoarea regula: o operatie produce unul sau mai multe rezultate. Descompunerea unei operatii n mai multe operatii distincte implica aparitia unor rezultate intermediare. Un eveniment emis poate fi n acelasi timp un eveniment declansator pentru o alta operatie ( sau alte operatii). De aceea se si utilizeaza acelasi formalism. Reguli de obtinere a rezultatului

n MCP toate operatiile trebuie sa aiba rezultat. n anumite cazuri obtinerea unuia sau mai multor rezultate poate fi supusa ndeplinirii anumitor conditii. n aceasta situatie este necesar sa fie definite, formulate asa numitele reguli de emisiune sau reguli de actiune. (vezi fig. de mai sus). Exemple : - Relatia date-rezultate este supusa anumitor conditii logice : daca valoarea facturata este mai mare de 1 milion, atunci se acorda o remiza de 1o%, daca nu, se acorda un scont de 2%. - Lansarea unei livrari poate fi diferita daca stocul este insuficient. n acest caz comanda este plasata n asteptare (nu se ntocmeste dispozitie de livrare). Conditia stoc suficient defineste o regula de emisiune a rezultatului cu doua cazuri diferite (stoc suficint; stoc insuficient). Reprezentarea regulilor de emisiune Conform figurii de mai jos, diferitele reguli de emisiune n partea inferioara a dreptunghiului ce descrie operatia. Reprezentarea este analoga unei formulari de genul : Daca regula de emisiune 1 atunci Rezultat A si Rezultat B altfel (regula de emisiune 2) Rezultat B si Rezultat C sunt reprezentate

42

Operatie
Regula de emisiune 1 Regula de emisiune 2

A
Sincronizarea

n anumite cazuri, declansarea unei operatii poate solicita producerea simultana a mai multor evenimente. Cu alte cuvinte, o anumita operatie nu poate avea loc dect daca sunt ndeplinite anumite conditii privind manifestarea evenimentelor ce concura la declansarea operatiei respective. Expresia acestor conditii se numeste sincronizare. Principiul sincronizarii Sincronizarea exprima sub forma unei propozitii logice faptul ca operatia poate fi declansata sau nu. Ea se exprima printr-o expresie booleana ce leaga evenimentele ce declanseaza operatia. Modul de functionare Daca E1, E2 si E3 sunt evenimente declansatoare pentru operatia Oi si daca a, b, c sunt aparitii corespunzatoare evenimentelor E1, E2 sI respectiv E3, atunci sincronizarea : a si ( b sau c) , adica a ( b c) indica faptul ca operatia Oi este declansata daca o aparitie a evenimentului E1 exista simultan cu una din aparitiile evenimentelor E2 sau E3. Sincronizarea se exprima deci sub forma unei propozitii logice care trebuie sa respecte anumite reguli, dintre care cele mai importante sunt: - conditia trebuie pusa pe evenimentele participative - trebuie sa existe situatii care permit declansarea. conjugate si

Conceptul de sincronizare exprima o logica si o dinamica a prelucrarilor. La un moment dat, propozitia logica poate fi verificata. Atunci sincronizarea este activa si operatia este declansata. La un alt moment este posibil ca un singur eveniment declansator sa fie realizat; n acest caz sincronizarea este n asteptarea realizarii altor evenimente care sa declanseze operatia. Daca nici un eveniment nu are loc, sincronizarea este inactiva.

43

Evenimentul A

Evenimentul B

Sfarsit operatie Timp

t1 Sincronizare in asteptare

t2 Sincronizare activa (operatie declansata)

t3

Sincronizare inactiva
Exemplu

Sincronizare inactiva

Vom considera ca exemplificare procedura de acordare a unui credit. Utiliznd formalismul de mai sus vom defini modelul din figura 1. Schema din figura din dreapta constituie un model conceptual al prelucrarilor tipic; el descrie ceea ce se face, fara a preciza nici cine face si nici cu ce instrument.

44

Cerere de credit

OP 1 Instruire formala c1 Scrisoare de refuz c2 Dosar deschiz c3 Informatii suplimentare

OP 2 c4 Credit refuzat
Comentarii la figura 1

Analiza solvabilitatii c5 Credit acordat

O data cu primirea cererii de credit (eveniment) , are loc o operatie de instruire formala a deschiderii unui dosar de creditare care se finalizeaza dupa caz (functie de regulile de emisiune care au valorile c1 si respectiv c2 si c3) printr-un refuz (cerere nerezolvabila), prin deschiderea efectiva a unui dosar de creditare si n sfrsit, printr-o cerere de informare suplimentara. c1 : nu exista plafon de credite c2 : exista plafon de credite pe termen scurt c3 : exista plafon de credite pe termen lung Acest dosar face sistematic obiectul unei operatii de instruire, care, functie de solvabilitatea clientului (c4 - client nesolvabil sau C5 - client solvabil) se finalizeaza printr-o respingere sau acceptare a dosarului. Notiunea de Proces 45

Un proces descrie dinamica prelucrarilor dintr-o activitate determinata. El este format din operatii executate ca reactie la evenimente si producnd rezultate. Un proces este: - omogen : operatiile si rezultatele concura la o finalitate comuna. - limitat : are granite marcate de evenimentele de origine si de rezultatele terminale. Etapele elaborarii unui proces. Procesul este MCP ce corespunde unui domeniu de activitate. El este construit printr-un demers metodologic de modelare (analiza, abstractizare, conceptie), ce cuprinde urmatoarele etape: 1. Delimitarea obiectului de activitate n cadrul acestei etape trebuie precizate granitele domeniului de care sunt legate activitatile care intereseaza. 2. Identificarea principalelor evenimente. Aici trebuie revazute principalele evenimente externe si interne ale procesului; acestea sunt elemente cheie n realizarea modelului. 3. Construirea tabelului evenimente-rezultate. Acest tablou permite definirea continutului procesului , preciznd pe coloane, evenimentele, actiunile induse si rezultatele. 4. Identificarea si descrierea operatiilor. Tabloul evenimente-rezultate, n coloana centrala, permite deja identificare actiunilor induse de evenimentele declansatoare. O analiza mai complecta a contextului permite relevarea regulilor de gestiune, care sunt adesea elemente ale operatiilor. 5. Reperarea sincronizarilor. Aparent, mai multe evenimente distincte pot sa declanseze aceeasi operatie. O data stabilite aceste elemente se poate construi schema de baza pentru fiecare operatie. Aceasta schema se numeste bloc operatie. 6. Precizarea conditiilor de obtinere a rezultatelor. Se cauta, printre regulile de gestiune, acelea care definesc conditii de obtinere a rezultatelor. Se completeaza apoi schema de baza cu elementele respective. 7. Ordonarea blocurilor-operatie. Structura generala a procesului decurge din cronologia evenimentelor. Deci evenimentele trebuie ordonate cronologic. Acest fapt permite ordonarea diferitelor blocuri-operatie si legarea lor conform principiului : un rezultat ( al operatiei n-1) declanseaza operatia urmatoare (operatia n). 8. Verificarea si validarea modelului. Se verifica daca: - orice operatie duce la cel putin un rezultat; - orice operatie este declansata de cel putin un eveniment; - toate blocurile sunt legate. Validarea modelului se face de catre persoanele implicate n proces. Numai ele pot judeca pertinenta modelului propus.

46

Exemplu. Etapa 1. Domeniul care ne intereseaza este gestiunea clientilor privind comenzile pentru produse de panificatie (figura 2). Deci nu vor fi luate n considerare nici actualizarea stocurilor, nici activitatile contabile, ntruct nu apartin strict de gestiunea clientilor. Etapa 2. Pot fi identificate n principal: trei evenimente externe : 1. Sosirea unei comenzi de la un client. 2. Existenta unui mijloc de transport disponibil n care sa se ncarce marfa. 3. Sfrsitul zilei; trei evenimente interne: 1. Acceptarea comenzii. 2. Decizia de livrare. 3. Sfrsitul activitatii de livrare. Etapa 3. Tabloul evenimente -rezultate

Evenimente 1. Sosirea comenzii de la client 2. Existenta unui mijloc de transport disponibil 3. Sfrsitul zilei 1.Acceptarea comenzii 2.Decizie de livrare 3. Sfrsitul activitatii de livrare 4. Comanda n asteptare

Actiuni induse Rezultate Controleaza identitatea Comanda acceptata si pretul sau nu Efectueaza livrarea Livrare efectuata

Examineaza comenzile n asteptare Consultarea stocurilor de produse Pregatirea livrarii Expedierea marfii si pregatirea facturii

Comanda de fabricatie Comanda livrabila sau nu Marfa gata de plecare Livrare expediata Factura

Examinarea Comanda de comenzilor n asteptare fabricatie

47

Etapa 4. Se regasesc 6 operatii si anume: OP 1 - Controleaza identitate client si pret; OP 2 -Examineaza stoc OP 3 - Pregateste livrarea OP 4 - Factureaza OP 5 - Expediaza marfa OP 6 - Examineaza comenzile n asteptare Obs. Au fost retinute doar aspectele conceptuale, eliminndu-se operatiile de tip organizational sau tehnic. Sosirea comenzii OP1 Controlea za identitate N D

Coman da Op

Comand a Examineaza Insufucue Sfarsitul zilei a b A si B OP Examinea za comenzi

Sufucue Comand a OP Pregatir ea Livrar e c OP Factura C si Mijloc de d

Comanda in

OP Expediaza Factu
Livrare efectuata

Comanda de Catre alt proces

48

Etapa 5 Vom exemplifica lucrul din aceasta etapa doar pentru un singur bloc operatie, si anume cel corespunzator operatiei 2 (efectueaza livrarea).

Livrare pregatita a

Mijloc de transport

b A si b

OP 5

Efectueaza livrarea

Livrare efectuata

Etapa 6. Putem avea de ex. urmatoarele reguli de gestiune: a) daca comanda este acceptata. Aceasta regula defineste controlul de identitate si pret si conditioneaza rezultatul (comanda acceptata , respectiv refuzata); b) daca stocul este suficient, regula asemanatoare referitoare la marimea stocurilor. Etapa 7. Schema procesului este prezentata n figura 2. Etapa 8. Se constata n figura de mai sus ca sunt ndeplinite regulile de modelare n sensul ca orice operatie este declansata de cel putin un eveniment sI fiecare operatie are cel putin un rezultat (eveniment emis) Descrierea detaliata a procesului Schema procesului prezentata n figura 3 permite o perceptie rapida a ansamblului prelucrarilor. Daca se doreste nsa o prezentare mai detaliata atunci este recomandat ca aceasta detaliere sa se faca la nivel de bloc operatie, fara sa mai urmeze o nlantuire a blocurilor detaliate, ntruct o schema detaliata a procesului ar fi greu de urmarit, de perceput. n acest caz se utilizeaza pentru eveniment urmatorul formalism. Descrierea detaliata a blocului corespunzator operatiei examinarea comenzilor n asteptare este prezentata n continuare : 49

Nume eveniment Nr max de Termen aparitii limita

Aceasta maniera de abordare aduce complemente asupra restrictiilor de timp si volum. Schema poate fi completata cu descrierea continutului operatiei, dar de aceasta data sub forma de fisa a operatiei, al carei continut este prezentat n continuare

Comanda in asteptare 20 1 zi a a si b OP 6 Examinarea comenzilor in asteptare Sfarsitul zilei b

Cerere de fabricatie 30 1 zi

Descrierea operatiei

Denumire: Examinarea comenzilor n asteptare Numar : 6 50

Proces : Gestiunea clientilor ________________________________________________________________ Mod de sincronizare - la sfrsitul zilei (ora 17) - pentru toate comenzile n asteptare ________________________________________________________________ Descrierea regulilor de gestiune R1. Pentru fiecare produs: - daca totalul cerut este mai mic dect cantitatea din stoc solicitati livrarea; - daca nu, cereti fabricarea. R2. Comenzile de fabricatie sunt emise cel mai trziu a doua zi dupa examinarea comenzilor. ________________________________________________________ Descrierea regulilor de emisiune R1. Starea cererilor de fabricatie Astfel de scheme trebuie elaborate pentru fiecare operatie. Se aplica aici principiul cunoscut al ierarhizarii, mergnd de la general (schema procesului) catre particular (descrierea operatiei). Revenind la reprezentarea grafica de mai sus putem afirma ca parametri exprimnd dinamica procesului puneau restrictii doar la nivelul nodurilor si anume: - la nivelul sincronizarii (propozitia logica, durata limita) si - la nivelul operatiilor pentru emisiunea de rezultate (reguli orienteaza fluxurile catre o cale sau alta).

de emisiune care

Acesti parametri pot fi completati cu altii plasati pe sagetile de legatura, n amonte si n aval de operatie. Astfel vom avea ca parametri suplimentari: - participarea si durata limita (pe sageata eveniment --> sincronizare) si - cardinalitatea (pe arcul operatie --> rezultat) Participare si durata limita (reglarea n amonte) Uneori sincronizarea, pentru a fi activata, are nevoie de existenta unui lot de aparitii ale evenimentului declansator. Acest numar constituie participarea tipului de eveniment la tipul de sincronizare. Timpul de activabilitate a acestui lot se numeste durata limita. Cardinalitatea evenimentelor (reglarea n aval) Operatiile emit rezultate (evenimente emise). Uneori este posibil ca acestea sa fie emise n mai multe exemplare identice. Numarul de exemplare exprima cardinalitatea tipului de eveniment rezultat al operatiei.

51

16. Validarea modelelor

Modelele externe ale datelor Fiecare prelucrare are propriul/propriile sale modele externe (subscheme) de date MCD construit prin prisma unei singure prelucrari. MED se construieste independent de MCD.

prel Realitate modelare MCD prel

MED1

MED2

O prelucrare are ME distincte pentru fiecare consultare si pentru fiecare actualizare. Att pentru consultare ct si pentru actualizare, ME se construiesc pe baza blocurilor logice de date corespunzatoare. Loturi logice de date: fluxurile de date vehiculate de o anumita prelucare. Evenimentele care activeaza o sincronizare si care nu constituie o cerere de consultare constituie un BLD. Combinatia de evenimente produse printr-o regula de emitere a rezultatelor constituie un BLD.

e1

e2

BLD

E1

E2

e3

e4

BLD

E3

E4

Reguli pentru construirea ME 1) Un ME pentru fiecare consultare sau actulaizare efectuata de o prelucrare. 2) Fiecare ME se construieste pe baza BLD folosind formalismul EA. 3) Entitatile din ME pot sa nu aiba identificatori.

52

4) Atributele, entitatile si asocierile externe pot sa nu fie atribute, entitati sau asocieri conceptuale. 5) Atributele externe echivalente atributelor conceptuale trebuie sa aiba acelasi nume. Ex: modele externe pentru OP1 consultare : verificare identitate client

NUME DenClient 1,n CORESP 1,1 CLIENT CodClient AdresaClient Cod fiscal Star e
actualizare: acceptare comanda de la client

53

COMANDA Nr Data c-da comanda De clien Adresan t Vallivr totala 1,n CUPRIND E 1,1
LINIE-COMANDA

Cod Den produs UM produs Cantitate c-data Pret vnz Valoar e

Principiul validarii modelelor Fiecare model extern trebuie sa fie deductibil din MCD

Model extern

calcul

echivalenta

Model conceptual

54

CLIENT CodClient DenClient AdresaClient CodFiscal Stare 0,n TRANSMITE

PRODU S Cod produs Den produs U Pret vnz M 0,n PRODUS-CDAT Cantitate c-data COMAND A Nr comanda Data c-da

1,1

1,n

corespondenta directa: Cod produs, Den produs, Cantitate -calcul: Valoare = Cantitate c-data * Pret vnz Val-totala =Valoare -echivalenta: Adresa-livr AdresaClient

c-data ...

17. Reguli de validare n consultare

Atributele externe trebuie sa fie atribute conceptuale. Daca nu: - omisiuni se completeaza MCD; - date calculate se nlocuieste n ME cu atributele conceptuale necesare calcularii sale; daca acestea nu apar n totalitate n MCD, se adauga; - date ce nu trebuie memorate se elimina din ME, urmnd sa fie tastate direct Trebuie sa existe posibilitatea de-a avea acces la date n structura necesara Accesul poate fi facut: - pe baza identificatorului; - prin parcurgerea entitatilor sau asocierilor, una cte una selectie necesare si se compeleteaza se verifica existenta criteriilor de MCD daca este nevoie. Daca se fac consultari pentru care criteriul de acces nu este identificatorul, se adauga n MCD o noua entitate al carei identificator este acest criteriu de acces si asocierea necesara pentru consultare (cai de acces impuse de utilizare si nu de DF). 55

Cardinalitatile asocierilor externe trebuie sa fie incluse n cardinalitatile asocierilor conceptuale ce le corespund semantic.

18. Reguli de validare n actualizare

Orice atribut extern trebuie sa serveasca fie la identificarea elementului conceptual de actualizat fie la obtinerea valorii de adaugat sau de modificat a unui atribut conceptual: -se suprima atributele externe care nu servesc nici unuia din scopurile amintite; -se adauga cele absente. Cardinalitatile asocierilor externe trebuie sa fie incluse n cardinalitatile asocierilor conceptuale ce le corespund semantic. Orice atribut conceptual trebuie sa poata fi inserat (modificat sau sters) prin cel putin un model extern. Daca nu, se adauga modelele externe adecvate. Ex: entitati si asocieri inserate prin ME acceptare comanda de la client PRODU CLIEN S T Cod CodClien produs Den DenClien produs U AdresaClien t M Pret tCodFisca vnz Star l e 0, 0, n n TRANSMITE PRODUS-CDAT Cantitate cdata COMAND A 1, Nr n comanda Data cda Trebuie adaugate MCP si ME corespunzatoare pentru actualizarea produselor si clientilor. 1, 1

56

19. Modelarea logica a datelor

Cadru general Trecerea de la MCD, care este un model universal, spre o solutie informatica se face gradat, lund n considerare un anumit tip de solutie si apoi, n cadrul tipului respectiv, o solutie direct implementabila.

Expresia MCD n termenii unui anumit tip de solutie informatica constituie modelul logic al datelor (MLD). Deoarece aplicatiile informatice de gestiune se caracterizeaza prin stocarea si prelucrarea relativ simpla a unor volume mari sau foarte mari de date, tipurile de solutii luate n considerare vizeaza modalitatile de gestionare a datelor pe suporturile de memorie externa.

COMAND ANr Data comanda

1, n

CUPRINDE

1, 1 0, 1

PROD-CCant comandata 1, 1 SE-REFERA-LA

CORESPUNDE

0, n FACTUR A Nr Data factura factura

1, n

PRODFACTURAT Cantitate Pret facturata unitar

0, n

0, n PRODU S Cod Den produs U produs M

Modelul relational Domeniu: o multime de elemente de tip similar. Exemple:

57

NUME

ZILE

ORARE

Ionescu luni Bucuresti Mateescu marti Timisoara Vasilescu miercuri Arad Popescu joi Paris Bunescu vineri Barcelona Costescu smbata Madrid Dumitrescu duminica Roma

Atribut: - o submultime a unui domeniu careia i s-a atribuit un nume. Numele exprima rolul sau semnificatia atribuite elementelor domeniului respectiv. Ex: - pentru domeniul Orase, pot fi definite atributele aeroport origine, aeroport destinatie, aeroport escala etc

Aeroport origine Bucuresti Bucuresti Paris

Aeroport destinatie Escala Arad Barcelona Bucuresti

Timisoara

Relatie: o multime R = {(a1,a2,..,an):(a1 A1, a2 A2, ...an An) P(a1,a2,...an) = adevarat} unde A1,A2...An sunt domenii. Ex 1: A1: domeniul compozitorilor; A2: domeniul simfoniilor; P(a1,a2) = "a1 est autorul simfoniei a2". P(Beethoven,Eroica)=adevarat; P(Vivaldi,Simfonia fantastica)=fals.

Ex 2: personal(MARCA,NUME,PRENUME,DATA-NASTERII) daca (m,n,p,d) personal atunci o persoana cu marca (m), numele (n), prenumele (p) este nascuta la data (d).

58

Relatiile se reprezinta grafic sub forma de tabele, n care se disting: gradul relatiei: numarul de atribute utilizate cardinalitatea relatiei: numarul de tupluri (linii n tabel). Cardinalitatea unei relatii este variabila n timp datorita operatiilor de actualizare care pot adauga sau sterge tupluri. Pentru o relatie pot exista 3 tipuri de chei: (eventual cheie primara: cel mai mic ansamblu de atribute unul singur) care permite identificarea fara univoc al fiecarui tuplu al unei relatii; atributele care compun cheia primara nu pot avea valori nule. care nu a cheie candidat: o alta posibila cheie primara, fost nsa retinuta ca atare. unul cheie externa: un ansamblu de atribute (eventual singur) care este cheie primara ntr-o alta relatie. Restrictie de integritate referentiala: daca ntre un atribut A si o cheie primara B exista o RIR atunci A nu poate lua dect valori care exista si n B. Prin definitie, cheile externe sunt supuse RIR n raport cu cheile primare corespunzatoare.

Gra d MARC A 12 52 1 83 3 61 4 7 Cardinalitat e NUM PEpesc o u opesc P u o ste C aonesc I u PRENUM E Vasil e drian A ao I n ari M a DATA NAST6 2 2 /1 0 / 8 7 /5 /6 1 5 /1 2 /6 8 3 0 /4 /6 3 4

Atribut e

Tupl u

59

20. Trecerea de la MCD la MLD relational

a. ENTITATI Fiecare entitate devine o relatie. Atributele entitatii devin atribute ale relatiei. Identificatorul entitatii devine cheia primara a relatiei.

E 1 Ae1 Ae1 1 .. 2 . E1 Ae1 ,Ae12, ( 1 ...)

b. ASOCIERI b.1 Cazul general 1) Asocierea devine o relatie. 2) Atributele proprii ale asocierii (daca exista) devin atribute ale relatiei. 3) Cheile primare ale entitatilor participante la asociere devin externe. 4) Identificatorul asocierii devine cheia primara a relatiei. chei

_,n Ae11 Ae12 ...

ASO CA1

_,n Ae21 Ae22 ...

ASOC (

Ae11 ,Ae21

,A1 )

E1( Ae11 ,Ae12, ...) E2( Ae21 ,Ae22, ...)

60

Ex 1 :

STUDENT Nr matricol Nume Prenume

EXAMEN DISCIPLINA 0,n Data examen Cod discipl sustine Nota cursant Nume discipl 1,n

STUDENT(Nr matricol, Nume, Prenume) DISCIPLINA(Cod disciplina, Nume disciplina) EXAMEN(Nr matricol*, Cod disciplina*, Data examen, Nota)

Ex : 2
STRUCTURA FABRICATI E Cantitate nec ARTICO L Cod Den articol Tip articol U articol M

compusdin 0, n

componentin 0, n

ARTICOL(Cod articol, Den articol, Tip articol, UM) STRUCT-FABRICATIE(Cod articol compus*, Cod articol component*, Cantitate necesara) b.2. Asocieri binare avnd cel putin o cardinalitate maximala 1. Se adauga la atributele relatiei corespunzatoare entitatii cu cardinalitatea maximala 1 identificatorul celeilalte entitati (cheia primara a relatiei corespunzatoare acesteia), care devine cheie externa. Daca asocierea are atribute proprii, acestea se adauga la rndul lor relatiei care reprezinta entitatea cu cardinalitate maximala 1.

61

E 1 Ae11 Ae12 ...

_,1

ASO C A1

_,n

E 2 Ae21 Ae22 ...

E1 Ae1 , ( 1 Ae12,...,Ae21,A1) E2 Ae2 ( 1

Ex 1

,Ae22,... )

ANGAJA T Marc Num Prenum e Data e Salariul nasterii lunar

LUCREAZ 1, A 1 lucreaza- Data ncadrrii la

0, loc- n munca

COMPARTIMEN T Cod compartiment Den compartiment

COMPARTIMENT(Cod compartiment, Den compartiment) ANGAJAT(Marca,Nume, Prenume, Data nasterii, Salariul lunar, Cod compartiment*, Data ncadrarii)

62

Ex 2
0,n FILIATIE 1,1

tat a PERSOAN

copil

Cod persoan Num e Prenum e Data nasterii Se x PERSOANA(Cod persoana, Nume, Prenume, Data nasterii, Sex, Cod persoana tata*) c. SUBTIPURI DE ENTITATI (Generalizarea/specializarea) c.1. Reprezentarea simpla a legaturilor dintre tip si subtip Se aplica regulile de la b.2. conform urmatoarei schemei generale:

Entitat e

Entitat e

0, Subti p Subti p 0, 1, Subti p 1, Subti p

c.2. Reprezentarea mostenirii

Reprezentarea mostenirii ca proces de transfer al proprietatilor generice ale tipului spre subtipuri nu beneficiaza de o solutie relationala dedicata. Din aceasta cauza, este necesar sa se recurga la defactorizarea proprietatilor comune. 63

a) se favorizeaza specializarea: tipul de entitate iar atributele sunt adagate la fiecare dintre subtipuri.

generica dispare

proprietat e 1, 1 POSED A 1, proprieta n r CLIEN

BUNIMOBILIAR Nr bun Adres Suprafat # DEVANZARE Pret Star solicitat e DEINCHIRIAT Chirie Avans Durata minimal

T Nr Nume Adresa client No telefon BUN-DE-VANZARE( Nr bun , Adresa, Suprafata, Pret solicitat, Stare, Nr Client) BUN-DE-INCHIRIAT( Nr , Adresa, Suprafata, bun Chirie lunara, Avans minimal, Durata minima, Nr Client)
b) se favorizeaza generalizarea: tipul de entitate generica preia si atributele specializate care, n functie de subtipul reprezentat, primesc valori nule. BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Pret solicitat, Stare, Chirie lunara, Avans minimal, Durata minima, Nr client*) att tipul ct si subtipurile sunt conservate ca atare. BUN-IMOBILIAR(Nr bun, Adresa, Suprafata, Nr client*) BUN-DE-VNZARE(Nr bun vnzare, Pret solicitat, Stare) BUN-DE-NCHIRIAT(Nr bun inchiriat, Chirie lunara, Avans minimal, Durata minima)

Nr bun vnzare si Nr bun inchiriat trebuie sa respecte restrictiile de integritate referentiala n raport cu Nr bun.

64