Sunteți pe pagina 1din 210

Nicolae Morariu

Sorin Vlad

PROIECTAREA SISTEMELOR INFORMATICE


Metode, modele, tehnici i instrumente utilizate

2008

Referent tiinific: Prof. univ. dr. ing. Doru E. Tiliue Universitatea tefan cel Mare Suceava

Descrierea CIP a Bibliotecii Naionale a Romniei MORARIU, NICOLAE Proiectarea sistemelor informatice Metode, modele, tehnici i instrumente utilizate/ Nicolae Morariu, Sorin Vlad - Bucureti: Editura InfoData, 2008 Bibliogr. ISBN 973-30-1042-1

004.65

Copyright 2008. Editura InfoData.

CUPRINS
Introducere......................................................................................................................................6 Capitolul 1. Sisteme Informatice...................................................................................................8
1.1. Sistem, Sistem informaional, Sistem informatic.................................................................................................8 1.1.1. Componentele sistemului informatic...........................................................................................................10 1.1.2. Clasificarea sistemelor informatice..............................................................................................................11 1.1.3. Ciclul de via a unui sistem informatic.....................................................................................................13 1.1.4. Coninutul bazei informaionale a unei ntreprinderi...................................................................................14 1.1.5. Ciclul prelucrrii datelor pentru sistemul informatic...................................................................................14 1.1.6. Sisteme informatice de gestiune..................................................................................................................16 1.2. Metodologii de realizare a sistemelor informatice..............................................................................................17 1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice.................................................................18 1.2.2. Metode i tehnici de realizare a sistemelor informatice...............................................................................18 Teste rezolvate...........................................................................................................................................................21 ntrebri......................................................................................................................................................................23

Capitolul 2. Iniierea i planificarea realizrii unui sistem informatic...................................25


2.1. Identificarea, selecia, iniierea i planificarea proiectelor.................................................................................25 2.2. Studii de fezabilitate...........................................................................................................................................27 2.3. Tehnici de reprezentare a planurilor i programarea calendaristic...................................................................28 Teste rezolvate...........................................................................................................................................................29

Capitolul 3. Analiza sistemului existent i definirea cerinelor noului sistem........................31


3.1. Studiul sistemului informaional existent...........................................................................................................31 3.2. Determinarea cerinelor sistemului.....................................................................................................................32 3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului..........................................33 3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului.............................................................34 3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor.................................................35 3.3.1. Diagramele fluxurilor de date (DFD)..........................................................................................................35 3.3.2. Descompunerea funcional i rafinarea DFD ............................................................................................37 3.3.3. Modelarea sistemului curent........................................................................................................................40 3.3.4. Modelarea logicii proceselor........................................................................................................................42 3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER)..............................................................44 3.4.1. Modelul Entitate/Relaie (E/R)....................................................................................................................46 Teste rezolvate...........................................................................................................................................................57 ntrebri......................................................................................................................................................................60

Capitolul 4. Proiectarea logic a sistemelor informatice..........................................................61


4.1. Proiectarea formularelor/formatelor i a rapoartelor..........................................................................................61 4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor)................................................................................61 4.1.2. Proiectarea codurilor....................................................................................................................................64 4.1.3. Proiectarea intrrilor n sistemul informatic................................................................................................65 4.2. Proiectarea interfeelor i a dialogurilor.............................................................................................................67 4.3. Proiectarea logic a bazelor de date....................................................................................................................69 4.3.1. Normalizarea relaiilor - Forme normale.....................................................................................................73 4.3.2. Simplificarea structurii datelor prin normalizare.........................................................................................78 4.3.3. Transformarea diagramelor entitate-relaie n relaii...................................................................................80 Teste rezolvate...........................................................................................................................................................81

Capitolul 5. Proiectarea fizic a sistemelor informatice...........................................................84

5.1. Proiectarea fizic a bazelor de date i a fiierelor...............................................................................................84 5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:........................................................................85 5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)........................................................................................86 5.1.3. Administratorul bazei de date......................................................................................................................86 5.1.4. Proiectarea securitii bazelor de date i a fiierelor....................................................................................87 5.1.5. Limbajul SQL - Crearea, Administrarea i Interogarea bazelor de date relaionale....................................88 5.2. Proiectarea programelor i a procedurilor.........................................................................................................103 5.2.1. Atributele modulelor..................................................................................................................................105 5.2.2. Structurile de control ale programelor.......................................................................................................106 5.2.3. Proiectarea i realizarea programelor ........................................................................................................110 5.3. Proiectarea sistemelor distribuite......................................................................................................................111 Teste rezolvate.........................................................................................................................................................114 ntrebri i rspunsuri..............................................................................................................................................116

Capitolul 6. Instrumente CASE................................................................................................118


6.1. Funciile CASE.................................................................................................................................................119 6.2. Trsturi definitorii ale CASE-ului...................................................................................................................120 6.3. Tipuri de instrumente CASE [72].....................................................................................................................121 6.4. Exemple de instrumente CASE........................................................................................................................122 6.4.1. Erwin Data Modeler...................................................................................................................................123 6.4.2. Microsoft Visio 2007.................................................................................................................................128 6.4.3. Toad data modeler......................................................................................................................................130 6.4.4. Embarcadero ER/Studio [70].....................................................................................................................134 6.4.5. Oracle Designer.........................................................................................................................................136 Teste rezolvate.........................................................................................................................................................138 ntrebri i rspunsuri..............................................................................................................................................139

Capitolul 7. Tendine actuale i de perspectiv n evoluia sistemelor informatice.............141


7.1. Concepia sistemic n economie......................................................................................................................141 7.2. Categorii de sisteme inteligente........................................................................................................................145 7.2.1. Sisteme expert bazate pe reguli..................................................................................................................146 7.2.2. Sisteme bazate pe reele neuronale (sisteme conexioniste).......................................................................146 7.2.3. Sisteme multi-agent. Definiie, clasificare, arhitecturi..............................................................................147 7.2.4. Sisteme inteligente hibride.........................................................................................................................148

Capitolul 8. Studii de caz - Arhitecturi de sisteme informatice.............................................150


8.1. Model de date georelaional n cadrul unui sistem informatic geografic distribuit cu aplicaii n domeniul cadastrului................................................................................................................................................................150 8.2. Sistem informatic geografic distribuit pentru reprezentarea digital i monitorizarea zonelor expuse inundaiilor...............................................................................................................................................................156 8.3. Sistem bazat pe cunotine destinat documentrii i cercetrii asistate n genetica vegetal..........................167 8.3.1. Organizarea datelor n cadrul sistemului informatic..................................................................................167 8.3.2. Arhitectura unui sistem bazat pe cunotine n genetica vegetal..............................................................172 8.3.3. Probleme specifice cercetrii.....................................................................................................................181 8.4. Sistem telematic pentru managementul on-line al zonelor intravilane degradate datorit depozitrii necontrolate a deeurilor..........................................................................................................................................187 8.4.1. Introducere.................................................................................................................................................187 8.4.2. Definirea arhitecturii generale a sistemului...............................................................................................188 8.4.3. Proiectarea bazei de date a sistemului.......................................................................................................190 8.4.4. Dezvoltarea unei aplicaii specifice pentru reprezentarea i monitorizarea unor zone intravilane din judeul Suceava supuse degradrii datorit depozitrii necontrolate a deeurilor...............................................195 Concluzii..................................................................................................................................................................205

BIBLIOGRAFIE........................................................................................................................206

Introducere
Scopul lucrrii este de a familiariza studenii facultilor cu profil economic cu principalele concepte, metode tehnici i instrumente utilizate n proiectarea sistemelor informatice. Sunt prezentate i exemplificate principalele etape i activiti de parcurs pentru ntreg ciclul de via a unui sistem informatic. n ultima parte a lucrrii sunt prezentate tendine actuale i de perspectiv n evoluia sistemelor informatice precum i arhitecturi de sisteme informatice realizate pentru diverse domenii de activitate. Pentru a asigura parcurgerea i nsuirea problematicii propuse, lucrarea de fa cuprinde opt capitole i anume: 1 Sisteme informatice, 2 Iniierea i planificarea realizrii unui sistem informatic, 3 Analiza sistemului existent i definirea cerinelor noului sistem, 4 Proiectarea logic a sistemelor informatice, 5 Proiectarea fizic a sistemelor informatice, 6 Instrumente CASE, 7 Tendine actuale i de perspectiv n evoluia sistemelor informatice, 8 Studii de caz - Arhitecturi de sisteme informatice. n capitolul 1 sunt prezentate conceptele sistem, sistem informaional, sistem informatic, sunt definite componentele sistemului informatic, sunt redate clasificri ale sistemelor informatice dup diverse criterii, este definit ciclul de via a unui sistem informatic i sunt prezentate etapele ciclului de via n cadrul modelului cascad. Este prezentat coninutul bazei informaionale a unei intreprinderi i este definit sistemul informatic de gestiune i ciclul prelucrrii datelor pentru sistemul informatic. Este definit conceptul de metodologie de realizare a unui sistem informatic i sunt prezentate sumar principalele metode utilizate. n capitolul 2 sunt prezentate o serie de aspecte privind primele activiti desfurate n vederea realizrii sistemelor informatice, activiti definite n literatura de specialitate sub numele de microanaliza sistemelor, component preluat din managementul proiectelor i care are n vedere modalitile de identificare a proiectelor de dezvoltare a sistemelor informaionale, precum i modul n care au loc iniierea i planificarea realizrii acestora, n strns legtur cu planul strategic organizaional. Este definit studiul de fezabilitate, iar ca tehnic de reprezentare grafic a planurilor de programare calendaristic este definit i exemplificat diagrama Gantt. n cadrul capitolului 3 este prezentat prima etap a ciclului de via al sistemelor informatice, etap prin care se determin modul n care funcioneaz sistemul informaional curent i se evalueaz ceea ce ar dori utilizatorii s realizeze noul sistem. Astfel, sunt prezentate o serie de aspecte privind: studiul sistemului existent; determinarea cerinelor noului sistem; metodele tradiionale utilizate n analiza i determinarea cerinelor sistemulu (interviul i chestionarul); metode moderne de analiz i determinare a cerinelor sistemului (JAD, prototipizarea); structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor (diagramele fluxurilor de date DFD); modelarea conceptual a datelor (diagramele entitate relaie, DER).
6

n capitolul 4 al lucrrii este tratat etapa de proiectare logic a sistemului informatic cunoscut i sub denumirea proiectare general sau proiectare de ansamblu. Proiectarea de ansamblu a sistemului are n vedere prezentarea noului sistem prin prezentarea tuturor intrrilor sistemului, a ieirilor, precum i a interfeelor i dialogurilor. Avnd n vedere intrrile i ieirile sisemului, este prezentat proiectarea logic a bazei de date, activitate prin care se urmrete transformarea diagramelor entitate-relaie n relaii. Aceste elemente definitorii ale noului sistem se construiesc pe baza a ceea ce s-a identificat n etapele anterioare, dar inndu-se cont i de cerinele identificate n timpul desfurrii activitilor din etapa de proiectare logic. Documentaia realizat n cadrul acestei etape constituie proiectul tehnic de ansamblu al sistemului. Capitolul 5 trateaz proiectarea fizic a sistemului informatic, cunoscut i sub numele de proiectare de detaliu, care urmeaz proiectrii logice i care nseamn o abordare detaliat a sistemului. Dac n etapa de proiectare logic se acumuleaz informaiile ce sintetizeaz cerinele utilizatorilor noului sistem, operaiune prestat de analitii de sistem, n cadrul proiectrii fizice se prezint punctele de vedere ale specialitilor, cum ar fi cei din domeniul bazelor de date, securitii sistemelor, reelelor de calculatoare, programrii, etc. Proiectarea fizic a sistemului informatic cuprinde: Proiectarea fizic a bazelor de date i a fiierelor. O astfel de activitate nseamn descrierea modului n care vor fi stocate datele i cum se va asigura controlul lor pentru a se oferi o securitate maxim; Proiectarea structurii sistemului i a programelor. Se descriu programele sau modulele acestora care s fie n strns concordan cu diagramele fluxurilor de date i cu celelalte piese ale documentaiei realizate n etapele anterioare; Proiectarea strategiilor de prelucrare distribuit. Se vor prezenta modalitile n care utilizatorul poate s dispun de date i facilitile de prelucrare oferite de reele de calculatoare. n capitolul 6 sunt definite instrumentele CASE i sunt prezentate tipuri de instrumente CASE avnd n vedere cele dou metodologii de proiectare: metodologia structurat i metodologia orientat obiect. n finalul capitolului sunt prezentate facilitile oferite i modul de utilizare a urmtoarelor produse CASE: Erwin Data Modeler, Microsoft Visio 2007, Toad Data Modeler, Embarcadero ER/Studio, Oracle Designer. Capitolul 7 trateaz o serie de aspecte privind noua concepie sistemic n economie, dezvoltarea i utilizarea sistemelor inteligente n cadrul unei organizaii, reprezentarea i procesarea datelor i cunoaterii n cadrul conceptului de sistem informaional inteligent. Sunt prezentate sumar principalele categorii de sisteme inteligente: sisteme expert, sisteme conexioniste, sisteme multiagent, sisteme inteligente hibride. n capitolul 8 sunt prezentate exemple de sisteme informatice pentru diverse domenii de activitate, realizate cu participarea autorilor n cadrul unor proiecte de cercetare.

Capitolul 1. Sisteme Informatice


1.1. Sistem, Sistem informaional, Sistem informatic

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 [60]. Conform teoriei sistemelor orice organism economic este un sistem. n cadrul acestei lucrri prin organizaie se va referi o intreprindere, instituie, societate comercial. n orice organizaie se disting 3 componente: sistemul de conducere sau de decizie; sistemul informaional; sistemul operaional. Sistemul informaional cuprinde ansamblul informaiilor interne i externe utilizate n cadrul organizaiei precum i datele care au stat la baza obinerii lor, procedurile i tehnicile de obinere a informaiilor (plecnd de la datele primare) i de difuzare a informaiilor, precum i personalul implicat n culegerea, transmiterea, stocarea i prelucrarea datelor. Sistemul informaional are dou componente: componenta pentru stocarea (memorarea informaiilor); componenta pentru prelucrarea informaiilor. Orice organizaie interacioneaz cu alte organizaii externe ei primind informaii din exterior i furniznd informaii ctre lumea exterioar. Funciile unui sistem informaional sunt: s colecteze informaii din sistemele operaional i decizional precum i informaiile ce provin din mediul extern; s memoreze aceste informaii precum i informaii rezultate din prelucrarea lor; s asigure accesul la memorie n vederea comunicrii informaiilor stocate; s prelucreze informaiile la cererea sistemului operaional i a sistemului de conducere. Noiunea de sistem informatic este legat de informatizarea activitii organizaiei, deci folosirea echipamentelor hardware i a produselor software pentru organizarea i administrarea informaiilor. Utilizarea calculatoarelor n cadrul sistemului informaional (SI) al unei organizaii conduce la definirea componentei Sistem Informaional Automatizat (SIA) care cuprinde numai lucrrile realizate cu ajutorul calculatoarelor. Relaia SI SIA este reprezentat n figura 1.1.

Fig. 1.1. Relaia SI SIA (Sursa: [10]) Definiie. Un sistem informatic este un sistem utilizator-calculator integrat, care furnizeaz informaii pentru a sprijini activitile de la nivel operaional i activitile de management ntr-o organizaie, utiliznd echipamente hardware i produse software, proceduri manuale, o baz de date i modele matematice pentru analiz, planificare, control i luarea deciziilor [8]. Obiectivul principal urmrit prin introducerea unui sistem informatic l constituie asigurarea conducerii cu informaii reale i n timp util, necesare fundamentrii i elaborrii operative a deciziilor [11]. Elaborarea sistemelor informatice impune modelarea sistemului informaional al organizaiei cu ajutorul unui formalism prin care s poat fi reprezentat ct mai sugestiv i fidel realitatea din cadrul sistemului informaional. Sistemele informatice complexe pot fi descompuse n subsisteme, care la rndul lor pot fi descompuse n aplicaii destinate unor categorii de utilizatori, aplicaii care la rndul lor pot fi constituite din unul sau mai multe programe scrise n diverse limbaje de programare dup cum este ilustrat n figura 1.2.

Fig.1.2. Sistem informatic, subsisteme, aplicaii, programe

Pentru organizaii de complexitate mic, informatizarea poate nsemna realizarea unei singure aplicaii informatice referit de asemenea ca sistem informatic. Sistemele, subsistemele i aplicaiile informatice sunt produse informatice numite i produse software. Un produs informatic este constituit din programe care acceseaz baza de date i din documentaia necesar pentru utilizarea i ntreinerea programelor. Acestea se realizeaz n baza unor metodologii i necesit parcurgerea unor etape ncepnd cu specificarea cerinelor i terminnd cu implementarea, exploatarea i ntreinerea lor. Sistemul informatic economic este un ansamblu structurat de elemente intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i pentru fundamentarea deciziilor. Sistemul informatic este inclus n sfera sistemului informaional atta vreme ct n cadrul sistemului informaional vor exista o serie de activiti care nu vor putea fi automatizate [11]. 1.1.1. Componentele sistemului informatic Un sistem informatic este compus din [11]: baza informaional; baza tehnic; sistemul de programe; baza tiinific i metodologic; factorul uman (resursele umane); cadrul organizatoric. Baza informaional cuprinde: datele supuse prelucrrii; fluxurile informaionale; sistemele i nomenclatoarele de coduri. Baza tehnic este constituit din totalitatea mijloacelor tehnice de culegere, transmitere, stocare i prelucrare a datelor, locul central revenind calculatoarelor electronice. Sistemul de programe cuprinde totalitatea programelor utilizate pentru funcionarea sistemului informatic n concordan cu funciunile i obiectivele stabilite. Sunt avute n vedere att programele de baz (software de baz) ct i programele aplicative (software de aplicaie). Baza tiinific i metodologic este constituit din: algoritmi; formule; modele; tehnici de realizare a sistemelor informatice. Resursele umane constau din:

10

personalul de specialitate: analiti, programatori, ingineri de sistem, analitiprogramatori ajutori, operatori, etc.; beneficiarii sistemului. Cadrul organizatoric este cel specificat n regulamentul de organizare i funcionare (ROF) al unitii n care va fi utilizat sistemul informatic. La realizarea i utilizarea unui sistem informatic trebuie avute n vedere urmtoarele componente hard i soft: reele, echipamente, produse software de baz, produse software de aplicaie. Reele clasificare dup aria de ntindere geografic: Locale =LAN (Local Area Network) la nivelul unei organizaii; Metropolitane MAN (Metropolitan Area Network) la nivel de ora, localitate; De mare ntindere -WAN (World Area Network) (ex. Jude, ar). clasificare dup accesibilitate: Internet (reeaua Web) o colecie mondial de reele interconectate; Intranet un sit Web sau un grup de sit-uri care aparin unei organizaii, accesibil numai pentru membrii acesteia; Extranet o reea intranet care este parial accesibil utilizatorilor externi autorizai. Echipamente Echipamente de calcul : calculatoare, staii grafice, pentru servere de reea, servere de baze de date, staii de lucru (clieni, utilizatori), UPS-uri; Echipamente de comunicaie : router-e, hub-uri, modem-uri, switch-uri. Produse software Produse software de baz: Sisteme de operare pentru serverul de reea (UNIX, Windows NT server, Windows Server 2003, Novell) i pentru staiile de lucru sau clieni (Windows 98, Windows NT work station, Windows XP, Windows Vista); Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft, MySQL, ACCESS, FoxPro etc.); Sisteme GIS (Geographical Information System) utilizate pentru realizarea aplicaiilor pentru stocarea i prelucrarea datelor spaiale; Limbaje (medii) de programare utilizate pentru realizare software de aplicaie. Produse software de aplicaie produse program ce constituie aplicaiile i subsistemele sistemului informatic. 1.1.2. Clasificarea sistemelor informatice Sistemele informatice se clasific dup mai multe criterii [46].
1. n funcie de domeniul de utilizare, sistemele informatice pot fi pentru :

conducerea activitilor economico-sociale

11

conducerea proceselor tehnologice cercetare tiinific i proiectare tehnologic activiti speciale. 2. n funcie de elementul supus analizei: sisteme informatice orientate spre funcii; sisteme informatice orientate spre proces; sisteme informatice orientate spre date; sisteme informatice orientate spre obiecte; sisteme informatice orientate spre cunotine. 3. Dup modul de organizare a datelor: sisteme bazate pe fiiere; sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaionale, orientateobiect; sisteme mixte. 4. Dup metoda folosit n analiza i proiectarea sistemelor: sisteme dezvoltate dup metoda sistemelor; sisteme dezvoltate dup metoda clasic a ciclului de via; sisteme dezvoltate dup metoda structurat; sisteme dezvoltate dup metoda orientat-obiect; sisteme dezvoltate dup metoda rapid(RAD); sisteme dezvoltate dup metoda echipelor mixte(JAD); sisteme dezvoltate dup metoda prototipurilor. 5. Dup gradul de centralizare: sisteme centralizate; sisteme descentralizate; 6. Dup gradul de dispersie a resurselor sistemului informatic: sisteme informatice locale (bazate pe reea local, staii de lucru): sisteme informatice distribuite (date distribuite). 7. Dup gradul de automatizare a activitilor de analiz i proiectare a sistemelor informatice: sisteme informatice dezvoltate pe baza analizei i proiectrii clasice; sisteme informatice analizate cu instrumente automate i proiectate clasic; sisteme informatice bazate pe instrumente diverse de automatizare a analizei i proiectrii; sisteme informatice dezvoltate cu instrumente de tip CASE. n funcie de nivelul ierarhic ocupat de sistemul economic n structura organizatoric a societii, exist sisteme informatice [11]: pentru conducerea activitii la nivelul unitilor economice;

12

pentru conducerea activitii la nivelul organizaiilor economico-sociale cu structur de grup; sisteme informatice teritoriale; pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei naionale; sisteme informatice funcionale generale. 1.1.3. Ciclul de via a unui sistem informatic Sistemele informatice (SI) se caracterizeaz printr-un ciclu de via care ncepe cu decizia realizrii unui nou SI care s corespund mai bine noilor cerine ale utilizatorilor i se ncheie cu decizia de nlocuire a SI existent cu unul nou, mai performant. Ciclul de via se desfoar pe etape n cadrul fiecreia fiind definite faze i activiti specifice. nc de la nceput facem meniunea c, indiferent de etapa istoric sau metodologic, sistemele sunt abordate prin prisma ciclului lor de via. Ele apar se dezvolt, descresc i pier, sau printr-un nou ciclu, se perfecioneaz, dnd natere unei alte versiuni sau chiar unui nou sistem. Mutaiile din domeniul tehnologiei informaionale i al metodelor de abordare a sistemelor s-au reflectat i n ciclul de via al dezvoltrii sistemelor, fie prin schimbarea etapelor acestuia, fie prin modificarea opticii de parcurgere a lor. Spre exemplu, odat cu abordarea orientat-obiect a sistemelor, s-au lansat i noi modele ale ciclului de via [60]. Prin parcurgerea materialelor de specialitate, se poate constata c numrul fazelor/etapelor variaz de la trei (de exemplu analiza, proiectarea, implementarea) la peste douzeci. Exist mai multe modele ale ciclului de via, multe dintre ele cunoscnd o evoluie n timp. Spre exemplu, modelul cascad (figura 1.3) prevede parcurgerea mai multor etape ale ciclului de via care se deruleaz secvenial fiind ns permis la nevoie revenirea la etapa parcurs anterior n vederea ndeprtrii neajunsurilor identificate n etapele superioare ale ciclului de via. Etapele ciclului de via a unui sistem informatic n modelul cascad ([8]) sunt: 1. Analiza i definirea cerinelor sunt definite scopurile, serviciile i restriciile pe care trebuie s le ndeplineasc sistemul informatic, prezentate ntr-o manier nct s poat fi nelese att de ctre utilizatorii sistemului ct i de personalul de proiectare. 2. Proiectarea sistemului i a software-ului satabilirea cerinelor pentru hardware i software i elaborarea arhitecturii generale a sistemului. Funciile sistemului informaional vor fi reprezentate astfel nct s poat fi tranformate n unul sau mai multe programe executabile. 3. Implementarea i testarea unitilor de program proiectarea software-ului din etapa anterioar este transpus ntr-o mulime de programe sau module program i verificarea faptului c fiecare program sau modul satisface specificaia sa. 4. Integrarea i testarea sistemului integrarea i testarea programelor i modulelor program ca un sistem complet pentru a ne asigura c cerinele informaionale sunt satisfcute. Dup testare sistemul este livrat beneficiarului. 5. Exploatarea i ntreinerea sistemului este faza n care sistemul informatic este efectiv utilizat de ctre beneficiar i n care sunt descoperite i rezolvate eventuale erori de proiectare i programare i omisiuni n cerinele informaionale iniiale.
13

Fig. 1.3. Etapele ciclului de via a unui sistem informatic n modelul cascad ([8]) 1.1.4. Coninutul bazei informaionale a unei ntreprinderi Pentru o ntreprindere entitile bazei informaionale pot fi grupate dup cum urmeaz: consumuri de materiale, contracte cu furnizorii, programe de aprovizionare; pentru activitatea de producie: tehnologii i reete de fabricaie, program de lucru, norme de munc i consumuri de manoper; pentru activitatea de desfacere: stocuri de produse, contracte cu clienii, realizri contracte; pentru activitatea de marketing: evoluia cererii i a ofertei, dinamica preurilor, elasticitatea cererii i a produciei; pentru activitatea financiar-contabil: solduri i rulaje contabile, calculaia costurilor, bugete de venituri i cheltuieli, contabilitatea analitic i sintetic; pentru activitatea de personal: evidena personalului, salarizri, dotri socialculturale i gestiunea lor; pentru activitatea de cercetare-dezvoltare: studii tehnico-economice, proiecte tehnice, investiii, etc. 1.1.5. Ciclul prelucrrii datelor pentru sistemul informatic Operaiunile care se execut asupra datelor, din momentul apariiei lor, pentru a genera informaii semnificative i relevante sunt referite la un loc prin noiunea de ciclul prelucrrii datelor, care cuprinde cinci faze [46]: culegerea datelor, pregtirea datelor, prelucrarea datelor, ntreinerea fiierelor i obinerea informaiilor de ieire.
pentru activitatea de aprovizionare: stocuri de materiale, intrri materiale,

14

Faza de culegere a datelor cuprinde dou activiti fundamentale : observarea mediului care genereaz datele, fie printr-un observator uman, fie prin diverse echipamente; nregistrarea datelor, fie prin scrierea lor n documentele surs, fie prin captarea lor sub diferite forme cu ajutorul unor echipamente speciale. Faza de pregtire a datelor const ntr-un numr de operaii executate asupra datelor pentru a facilita prelucrarea lor ulterioar i anume: clasificarea datelor, care implic atribuirea de coduri de identificare (simbol cont, cod secie, etc.), astfel nct datele s fie incluse n submulimile corespunztoare; gruparea datelor, adic acumularea intrrilor similare, pentru a fi prelucrate n grup; verificarea datelor cuprinde o mare varietate de proceduri pentru controlul corectitudinii datelor, nainte ca ele s fie prelucrate; sortarea datelor, prin care grupurile de date sunt aranjate n loturi de nregistrri, dup criterii de ordonare numeric, alfabetic, alfanumeric sau de timp; cuplarea a dou sau mai multe loturi de nregistrri ntr-unul singur; transmiterea datelor de la un punct la altul; transcrierea datelor dintr-o form n alta, astfel nct s se efectueze trecerea de la scrierea de mn la cea tipizat sau de la documentele scrise la mediile specifice. Faza de prelucrare a datelor, poate s includ activiti, cum sunt: calculaiile cuprind unele forme de tratare matematic a datelor; compararea supune unei examinri simultane dou sau mai multe tipuri de date ntre care exist o legtur logic (ex. soldul final i cel final); sintetizarea este o activitate important prin care se comaseaz informaiile; filtrarea este o alt operaiune prin care se extrag datele ce vor fi supuse prelucrrilor urmtoare; restaurarea, prin care sunt aduse datele din memorie ntr-o form accesibil omului, pentru prelucrarea uman n continuare, sau ntr-o form prelucrabil tot pe calculator. n faza de ntreinere a fiierelor exist mai multe activiti, dintre care amintim: memorarea (stocarea) datelor n vederea utilizrii lor viitoare; actualizarea datelor memorate astfel nct s surprind cele mai recente evenimente; indexarea datelor pentru a nlesni o uoar regsire a lor; protecia datelor memorate, care cuprinde o mare varietate de proceduri i tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat. Ultima faz a ciclului de prelucrare a datelor este obinerea informaiilor de ieire. Informaiile de ieire pot fi regsite n una din urmtoarele trei forme: documente,
15

rapoarte, rspunsuri la ntrebri. De cele mai multe ori, datele nu parcurg toate activitile, iar unele dintre ele pot s nu treac prin toate cele cinci faze. Fazele ciclului prelucrrii datelor sunt ilustrate n figura 1.4.

Fig. 1.4 Ciclul prelucrrii datelor 1.1.6. Sisteme informatice de gestiune Sistemele informatice de gestiune sunt sisteme integrate care creaz i actualizeaz o baz de date unic din documentele primare, care va fi ulterior prelucrat pentru obinerea situaiilor specifice fiecrui utilizator . Sistemul informatic de gestiune implic urmtoarele patru componente interdependente [60]: domeniile de gestiune, datele, modelele, regulile de gestiune. Domeniile de gestiune corespund activitilor desfurate n cadrul firmei: activitatea de personal, activitatea de producie, activitatea comercial, activitatea financiar-contabil, activitatea de cercetare-dezvoltare. Datele reprezint materia prim ce urmeaz a fi prelucrat n cadrul sistemului informatic pentru obinerea informaiilor necesare lurii deciziilor la toate nivelurile manageriale:operaional, tactic, strategic. Modelele de gestiune grupeaz procedurile specifice unui domeniu, iar regulile de gestiune definesc prelucrrile ce se efectueaz asupra datelor i modul de utilizare a informaiilor conform obiectivelor sistemului. Sistemul informatic de gestiune reunete subsisteme informatice specializate pe domenii ntre care se manifest interaciuni specifice. Fiecare subsistem definit grupeaz procese informaionale omogene, specifice unui anumit domeniu.

16

La nivelul fiecrui subsistem vor fi definite aplicaii distincte corespunztoare acestor activiti. La rndul lor aplicaiile sunt formate din proceduri descompunndu-se n module reprezentnd secvene de cod prin care se realizeaz o funcie independent din cadrul procedurii. Exemplu. O procedur pentru operaia de actualizare se va descompune n urmtoarele module: 1. modulul coordonator al funciei de actualizare; 2. modulul pentru realizarea funciei de adugare de nregistrri; 3. modulul pentru funcia de tergere nregistrri; 4. modulul pentru funcia de modificare a nregistrrilor din baza de date.

n figura 1.5. este reprezentat schema de principiu pentru sistemul integrat al contabilitii incluznd contabilitatea de gestiune i contabilitatea financiar.

Fig.1.5. Sistem informatic de gestiune integrat al contabilitii (adaptare dup [60]) 1.2. Metodologii de realizare a sistemelor informatice Realizarea sistemelor informatice reprezint o aciune complex, care mbin un numr mare de activiti: analiz, proiectare, implementare, exploatare [11]. n plus, reclam resurse umane, materiale i financiare nsemnate, pe o perioad considerabil de timp. Folosirea eficient a acestor resurse, n scopul obinerii unui sistem informatic performant a impus ordonarea acestui proces complex, ntr-o succesiune bine stabilit de etape i subetape i utilizarea unor metode i tehnici adecvate. Aceste observaii au condus la conturarea unor metodologii de realizare a sistemelor informatice. ntre diversele etape de realizare a sistemelor informatice exist o legtur indestructibil, legtur reflectat i de faptul c n mod logic i practic calitatea realizrii unor activiti din etapele i fazele precedente influeneaz n mod decisiv calitatea activitilor din etapa care urmeaz.

17

1.2.1. Coninutul metodologiilor de realizare a sistemelor informatice Metodologiile de realizare a sistemelor informatice cuprind [11]: modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre variaiile sistemului i dinamismul su; regulile de formalizare a datelor i proceselor de prelucrare; instrumentele pentru concepia, realizarea i elaborarea documentaiei; modalitatea de derulare a proiectului i aciunile specifice fiecrei etape (ciclul de viat); definirea modului de lucru, rolului analitilor i proiectanilor i a raportului dintre ei; modalitile de administrare a proiectului (planificare, programare, urmrire). Totodat, metodologiile au rolul de a indica modul de desfurare a acestui proces, stabilind [11]: componentele procesului de realizare a sistemului informatic (etape, subetape, activiti, operaii) i coninutul lor; fluxul parcurgerii (executrii) componentelor; metodele, tehnicile, procedeele, instrumentele, normele si standardele utilizate. n funcie de modul de abordare i domeniul de aplicabilitate, metodologiile utilizate sunt: metodologii din domeniul gestiunii: AXIAL (firma IBM), MERISE (Ministerul industriei-Franta), IE (James Martin), SSADM (Marea Britanie); metodologii orientate obiect: OMT (General Electric -SUA), OOD (Michael Jackson); metodologii pentru conducerea proiectelor de sisteme informatice: SDM / S, METHOD/ 1 Arthur Andersen, NAVIGATOR (Ernst & Young - James Martin). 1.2.2. Metode i tehnici de realizare a sistemelor informatice La realizarea sistemelor informatice se utilizeaz : metode, tehnici, instrumente, procedee de lucru [11]. Metodele utilizate n proiectarea sistemelor informatice reprezint modul unitar sau maniera comun n care analitii de sisteme, programatorii i alte categorii de persoane implicate, realizeaz procesul de analiz a sistemului informaional-decizional existent, proiectarea i introducerea sistemului informatic. Deci, metoda are un caracter general, n cadrul ei aplicndu-se anumite tehnici de lucru. Tehnicile de lucru utilizate n proiectarea sistemelor informatice reprezint felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea diferitelor probleme ce apar n procesul de proiectare. Prin aceste tehnici se mbin armonios cunotinele despre metode cu miestria personal a celor chemai s aplice metodele si s utilizeze instrumentele adecvate [11].

18

Utilizarea acestor metode, tehnici, instrumente, procedee de lucru n proiectarea sistemelor informatice se face n conformitate cu o serie de principii i n limita unor metodologii de lucru care se adopt n funcie de situaia real la care se refer. n abordrile incipiente se lucra cu probleme izolate i ulterior s-a efectuat trecerea la abordarea sistemic (modular), odat cu abordarea funcional sau, mai bine zis, cu analiza i descompunerea funcional (n fiecare modul exist cte o funcie) i ulterior abordarea orientat-obiect [11]. Pe parcurs s-au impus dou strategii de abordare i anume: strategia top down (de sus n jos); strategia bottom up evolutiv (de jos n sus). n strategia top down abordarea general este divizat n uniti componente prin rafinri repetate, metoda de proiectare putnd fi descris sub forma unei diagrame ierarhice cu module de control pe nivele superioare i cu module detaliate pe nivelele inferioare. Structura organizatoric a unei uniti economico-sociale numit organigrama unitii poate fi reprezentat printr-o astfel de diagram ierarhic. Pentru uniti economice productive n organigram se disting urmtoarele patru nivele de reprezentare [8]: nivelul conducerii strategice, reprezentat de directorul general i consiliul de administraie; nivelul conducerii tactice (directori pe funciuni); nivelul compartimentelor funcionale (servicii i posturi de lucru) i de proiectare, cercetare (laboratoare) care asigur conducerea operativ a sistemului prin efii lor; nivelul compartimentelor de producie (secii, ateliere) care realizeaz funcia de producie a sistemului economic. n strategia bottom up evolutiv, se pornete de la o tratare minimal care se extinde treptat pe msura naintrii n realizarea sistemului. n practic, de cele mai multe ori se utilizeaz o combinare a celor dou strategii. Metodele de abordare a sistemelor informatice ar putea fi grupate prin prisma celor mai muli autori astfel [46]: metode orientate spre funcii, numite i metode ale descompunerii funcionale; metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece diagramele fluxurilor de date se ntrebuineaz pentru descrierea proceselor; metode orientate spre informaie sau date, orientate-informaii, aprute ca urmare a popularizrii puternice a ingineriei informaiei a lui JAMES MARTIN, dar i a diagramelor entitate-relaie ale lui CHEN [12]; metode orientate-obiect. Caracteristici eseniale ale principalelor metode 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 [46].

19

Datele sunt reprezentate sub form de atribute (avnd n vedere structura lor), nseamn ceea ce este stocat i reflect structura static a sistemului. Funciile scot n eviden n mod limitat ceea ce face sistemul. El poate fi vzut i ca un proces, ntruct elementele sistemului despre care se pstreaz datele de rigoare sunt supuse unor transformrii funcionale, prin intermediul proceselor. Comportamentul este invocat pentru a reda o alt modalitate de percepie a sistemului, influena evenimentele i proprietilor sistemului, i sugereaz dinamica lui. Metoda descompunerii funcionale (orientate funcii) Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe civa cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl, Marco&Gowan. Descompunerea funcional este cea care anun apariia proiectrii structurate i analizei structurate. Fiecare funcie este descompus n subfuncii, pn se obin structuri uor de transpus n instruciunile limbajelor de programare. Metodele fluxurilor de date (orientate-proces) Prin aceast metod analitii efectueaz reprezentarea lumii reale prin simboluri care reprezint fluxul datelor, transformrile datelor, stocarea datelor, entiti externe, etc. Metoda orientat spre procese are nc un mare grad de asemnare cu descompunerea funcional. Metode orientate spre informaii (orientate-date) Dou realizri importante n domeniu au dat tonul unei orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen (1976) i ingineria informaiei, n viziunea lui James Martin. Metoda orientat-obiect Metodele OO constituie o categorie particular a metodelor de dezvoltare software, care privesc construirea sistemelor pentru care clasa reprezint unitatea arhitectural fundamental. Clasa este o grupare logic a obiectelor care au aceeai structur i un comportament similar. O clas poate fi divizat n subclase cu proprietatea c subclasele motenesc proprietile clasei i n plus pot avea proprieti suplimentare. Un sistem informatic este gndit ca un ansamblu de obiecte autonome astfel nct datele i prelucrrile (metodele) sunt definite n cadrul aceleiai structuri i anume obiectul.

20

Teste rezolvate 1. Care definiie este corect: a) 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; b) Un sistem este un ansamblu structurat de elemente intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i pentru fundamentarea deciziilor.. Rspuns: a,b 2. Sistemul informaional cuprinde: a) Ansamblul informaiilor interne i externe, formale sau informale utilizate n cadrul firmei precum i datele care au stat la baza obinerii lor; b) Procedurile i tehnicile de obinere(pe baza datelor primare) i de difuzare a informaiilor; c) Platforma necesar prelucrrii i disiprii informaiilor; d) Personalul specializat n culegerea, transmiterea, stocarea i prelucrarea datelor. Rspuns: a,b,c,d 3. Un sistem informatic este: a) un sistem destinat conducerii unei organizaii, b) un sistem utilizator-calculator integrat, care furnizeaz informaii pentru a sprijini activitile de la nivel operaional i activitile de management ntr-o organizaie, utiliznd echipamente hardware i produse software, proceduri manuale, o baz de date i modele matematice pentru analiz, planificare, control i luarea deciziilor, c) un ansamblu structurat de elemente intercorelate funcional pentru automatizarea procesului de obinere a informaiilor i pentru fundamentarea deciziilor. Rspuns: b,c 4. Identificai afirmaia fals: a) Sistemul informaional este subordonat sistemului de conducere. b) Sistemul informaional face legtura ntre sistemul condus i sistemul de conducere. c) Sistemul informatic este inclus n sistemul informaional. d) Sistemul condus este subordonat sistemului informaional. Rspuns: d 5. Sunt componente principale ale unui sistem informatic: a) Baza informaional; b) Manager general; c) Baza tehnic; d) Baza tiinific metodologic; e) Sistemul de programe. Rspuns: a,c,d,e 6. Obiectivul principal urmrit prin introducerea unui sistem informatic l constituie:

21

a) asigurarea conducerii cu informaii reale i n timp util necesare fundamentrii i elaborrii operative a deciziilor; b) asigurarea funcionrii normale si optime a activitilor; c) creterea productivitii muncii; d) creterea profitului; e) mbuntirea imaginii unitii economice. Rspuns: a 7. Dup domeniul de utilizare, sistemele informatice se clasific n: a) Sisteme informatice pentru conducerea activitilor economico-sociale; b) Sisteme informatice pentru conducerea proceselor tehnice; c) Sisteme informatice i expert; d) Sisteme informatice pentru activiti speciale. Rspuns: a,b,d 8. Dup modul de organizare a datelor, Sistemele informatice economice pot fi mprite n: a) sisteme imagine; b) sisteme bazate pe tehnica bazelor de date (ierarhice, reea, relaionale, orienatateobiect); c) sisteme bazate pe algoritmi fundamentali; d) sisteme bazate pe fiiere. Rspuns: b,d 9. Ciclul prelucrrii datelor pentru sistemul informatic cuprinde urmtoarele faze: a) culegerea datelor; b) pregtirea datelor; c) prelucrarea datelor; d) tergerea datelor. Rspuns: a,b,c 10. n faza de ntreinere a fiierelor exist mai multe activiti, dintre care amintim: a) memorarea(stocarea) datelor n vederea utilizrii lor viitoare; b) actualizarea datelor memorate astfel nct s surprind cele mai recente evenimente; c) crearea datelor; d) indexarea datelor pentru a nlesni o uoar regsire a lor; e) protecia datelor memorate, care cuprinde o mare varietate de proceduri i tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat. Rspuns: a,b,d,e 11. Metodologiile de realizare a sistemelor informatice cuprind: a) reguli de formalizare a datelor; b) instrumente pentru concepia, realizarea i elaborarea documentaiei; c) modalitile de administrare a proiectului; d) instruciuni pentru luarea deciziilor; e) modalitatea de abordare a sistemelor. Rspuns: a,b,c,e
22

12. Reprezint modul unitar sau maniera comun n care analitii de sisteme, programatorii i alte categorii de persoane implicate realizeaz procesul de analiz a sistemului informaional-decizional existent, proiectarea i introducerea sistemului informatic: a) metodele utilizate n proiectarea sistemelor informatice; b) procedurile utilizate n proiectarea sistemelor informatice; c) tehnicile de lucru utilizate n proiectarea sistemelor informatice; d) instrumentele utilizate n proiectarea sistemelor informatice. Rspuns: a 13. Care din afirmaiile urmtoare sunt corecte: a) Metoda top-down are ca obiectiv principal realizarea modularizrii sistemului de sus n jos. b) Metoda top-down const n agregarea modulelor de jos n sus. c) Metoda top-down nu are la baz principiul abordrii sistemice. Rspuns: a 14. Nu sunt faze ale ciclului de via al dezvoltrii sistemelor: a) microanaliza; b) analiza; c) colectarea; d) proiectarea logic; e) proiectarea fizic; f) implementarea; g) ntreinerea. Rspuns: c

ntrebri 1. Enumerai principalele activiti din cadrul unei intreprinderi n vederea identificrii entitilor bazei informaionale. 2. Definii tipurile de reele de calculatoare dup aria de ntindere geografic. 3. Definii tipurile de reele de calculatoare dup accesibilitate. 4. Prezentai tipurile de echipamente care pot fi utilizate n cadrul unui sistem informatic. 5. Enumerai produsele software de baz care pot fi utilizate pentru realizarea unui sistem informatic. 6. Definii ciclul de via a unui sistem informatic. 7. Enumerai etapele ciclului de via a unui sistem informatic n modelul cascad.

23

Enumerai metodologiile utilizate n funcie de modul de abordare i domeniul de aplicabilitate 9. Enumerai cele 4 nivele care pot fi identificate n organigrama unei uniti economice Productive.
8.

24

Capitolul 2. Iniierea i planificarea realizrii unui sistem informatic


2.1. Identificarea, selecia, iniierea i planificarea proiectelor Identificarea i selecia proiectelor de dezvoltare a sistemelor informatice reprezint prima etap din ciclul de via a dezvoltrii sistemelor care, mpreun cu iniierea i planificarea proiectelor, constituie microanaliza, component preluat din managementul proiectelor. Evidenierea acestor activiti n cadrul modelului cascad de derulare a fazelor sau etapelor ciclului de via a sistemului este reprezentat n figura 4.1 [46].

Figura 2.1 Ciclul de via al dezvoltrii sistemelor [46]\ Fiecare etap sau faz de realizare a unui sistem informatic se descompune n activiti. Astfel pentru identificarea i selecia proiectelor se parcurg activitile: identificarea potenialelor proiecte de dezvoltare; clasificarea i ierarhizarea lor; selecia proiectului. Identificarea potenialelor proiecte de dezvoltare Problema esenial a activitii de identificare a potenialelor proiecte de dezvoltare a sistemului const n nominalizarea celor ce pot fi abilitai s fac propuneri pertinente. Acetia pot fi: top-managerii, comitetul de iniiativ, departamentul utilizatorilor, grupul de dezvoltare. Caracteristicile eseniale ale variantelor de proiecte propuse n cele patru situaii sunt prezentate tabelul 2.1. Tabel 2.1 Variante de proiecte [46]

25

Propuneri

De sus n jos

Metoda de selecie a proiectului Top-managerii Comitetul de iniiativ Departamentul utilizatorilor

Caracteristicile proiectului orientare puternic spre strategie; cele mai mari dimensiuni ale proiectului; cele mai de durat proiecte. orientare mixt (a diferiilor reprezentani); vizeaz schimbrile organizaionale cele mai mari; analiz formal a costurilor i avantajelor proiectelor; proiecte mai mari i mai riscante. limitat, neorientat strategic; realizare mai rapid; civa utilizatori reprezint niveluri ale conducerii, precum i funciile ntreprinderii. integrare n sistemul existent; puine ntrzieri n realizarea proiectului; mai puin interesat de analizele cost avantaje.

De jos n sus

Grupul de dezvoltare

Selecia proiectelor de dezvoltare a sistemelor informaionale Datorit efectelor diferite i a amplitudinii lor, se recomand evidenierea distinct a proiectelor pe termen lung i a celor pe termen scurt. Dintre ele se selecteaz cele ce ating obiectivele organizaiei. De asemenea, se va urmri modul n care proiectele se aliniaz dinamicii unitii. Iniierea i planificarea proiectelor Pentru realizarea acestei faze este nevoie de comunicarea efectiv dintre prile implicate( analiti, clieni - manageri, utilizator). Iniierea proiectului Din momentul seleciei lui, proiectul trece n faza de iniiere, ceea ce presupune desfurarea unei activiti laborioase, prestat de un responsabil, cunoscut n practic sub numele de manager de proiect, care rspunde de [46]: Elaborarea unor studii de fezabilitate general; Elaborarea planurilor detaliate ale proiectelor; Gsirea celor mai buni membri ai echipei proiectului. Managerul de proiect trebuie s dea dovad de multe caliti pentru a putea jongla cu elemente cum sunt: Schimbrile tehnologice; Ciclul de via al sistemelor; Contractori i furnizori; Managementul resurselor umane;

26

Metodologie i instrumente de lucru diferite; Restricii de timp i resurse; Documentare i comunicare; Ateptrile managerilor i clienilor. Activitile efectuate n faza iniierii proiectului sunt: 1. stabilirea echipei de iniiere a proiectului; 2. stabilirea bunelor relaii cu beneficiarii; 3. stabilirea planului iniierii proiectului; 4. stabilirea procedurilor manageriale; 5. stabilirea cadrului de desfurare a proiectului. Planificarea proiectului Planificarea proiectului va cuprinde o evaluare a cerinelor informaionale ale sistemului la nivelul ntregii organizaii. Planificarea proiectului este procesul prin care are loc definirea clar a activitilor i a eforturilor necesare nfptuirii lor n cadrul fiecrui proiect. Tipurile activitilor executate n cadrul planificrii proiectului cuprind [46]: 1. Descrierea ariei de ntindere, a variantelor i fezabilitii proiectului; 2. Descompunerea proiectului n activiti uor executabile i controlabile; 3. Estimarea resurselor i crearea unui plan al resurselor; 4. Realizarea unei prime planificri calendaristice; 5. Realizarea unui plan al comunicrilor; 6. Determinarea standardelor i procedurilor proiectului; 7. Identificarea i evaluarea riscului; 8. Crearea unui buget preliminar; 9. ntocmirea rapoartelor de activitate; 10. Definitivarea planului de baz al proiectului. 2.2. Studii de fezabilitate Elaborarea unui sistem informatic poate costa milioane de dolari i se poate realiza pe parcursul a trei pn la ase ani pentru a fi complet. Din aceste motive, este normal ca factorii de conducere s demareze proiectarea unui nou sistem dup ce se efectueaz studii de fezabilitate. Un studiu de fezabilitate are rolul de a asigura informaiile obiective necesare pentru a cunoate dac un proiect poate fi demarat sau nu, sau dac un proiect deja nceput mai poate fi continuat. Proporiile i durata studiilor de fezabilitate variaz, n funcie de mrimea i natura sistemului implementat. n cazul sistemelor bazate pe calculatoare mari, studiul are cu totul alte dimensiuni fa de varianta utilizrii microcalculatoarelor [46]. Fezabilitatea proiectului poate fi studiat n orice faz a elaborrii lui, dar studiile, de regul, se efectueaz n momente certe. Cnd este propus un proiect, se efectueaz un
27

studiu preliminar de fezabilitate pentru a se stabili dac proiectul atinge obiectivele propuse de unitate. Analiza, n prima ei faz, poate fi orict de subiectiv, ntruct proiectul nu este reprezentat cu lux de amnunte. ns, ndat ce se obine o situaie mai clar despre sistem, despre natura problemei de rezolvat, precum i despre doleanele utilizatorilor, msurarea preliminar a fezabilitii poate fi determinat odat cu faza de analiz a sistemului. Cnd proiectanii ofer dou sau trei variante de elaborare a sistemului, numai studiile de fezabilitate determina varianta optim. Dup ce a avut loc proiectarea primar a sistemului, pot fi determinate n detaliu elementele de cost ale proiectrii, implementrii i exploatrii. Este ultima posibilitate de a renuna la sistem, naintea implementrii lui. Pe parcurs, odat cu progresul nregistrat n dezvoltarea sistemului informatic, se obin informaii din ce n ce mai certe, oferindu-se posibilitatea unor analize de fezabilitate mult mai concludente, ceea ce atrage studierea fezabilitii n diverse faze ale ciclului de via al sistemelor. De fiecare dat, studiile de fezabilitate trebuie s aib la baz o foarte bun documentaie. Aceasta va conine [46]: Definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce-i propune el s realizeze); Descrierea cerinelor sistemului; Descrierea soluiilor sistemului propus; Explicaia critic a motivrii studiului ntreprins; Cuantificarea tuturor costurilor materiale i beneficiilor aferente; O list a costurilor i beneficiilor necuantificabile. 2.3. Tehnici de reprezentare a planurilor i programarea calendaristic Managerul proiectului dispune de o mare varietate de tehnici pentru reprezentarea i descrierea planurilor proiectelor. Documentaia planificrii poate fi alctuit din: rapoarte grafice - cele mai folosite (fig. 2.2 ) rapoarte sub form de text. O diagrama Gantt este o modalitate de reprezentare grafic a proiectului. Cu ajutorul barelor orizontale sunt prezentate activitile planificate. Lungimea barelor este proporional cu timpul alocat activitilor reprezentate. Se pot folosi diferite culori, umbre sau forme pentru a scoate n relief anumite activiti. Ceea ce s-a planificat i realizat, de asemenea, pot fi evideniate prin bare paralele de culori, forme sau umbre diferite. Diagramele Gantt nu indic ordinea activitilor (precedena lor), ci indic data nceperii i pe cea a finalizrii. Se recomand pentru descrierea proiectelor simple sau a unor componente ale proiectelor mari, sau a activitilor prestate doar de o singur persoan, precum i pentru monitorizarea modului n care se efectueaz activitile n comparaie cu cele planificate (ca dat). Evidena promovrii vnzrilor (EPV)

28

Nr. Crt . 1. 2. 3. 4. 5. 6. 7. 8. 9.

Nume activitate Colectarea cerinelor Proiectare ecrane Proiectare rapoarte Proiectare baze de date Documentaie utilizator Programare Testare Instalare edina de analiz

Aprilie Mai 2005 2005

Iunie 2005

Iulie 2005

August Septembrie 2005 2005

Proiect: EPV Data: Analist:

Critic: Necritic:

n lucru: Punct de reper:

Sintez: Derulat:

Figura 2.2. Diagrama Gantt pentru descrierea planului proiectului [46]

Teste rezolvate 1. Propunerile pentru identificarea proiectelor de dezvoltare sunt fcute de: a) top-manageri; b) personalul auxiliar; c) muncitori; d) departamentul utilizatorilor. Rspuns: a, d 2. Selecia proiectelor de dezvoltare a sistemelor informaionale, urmrete: a) atingerea obiectivelor organizaiei; b) bunul mers a informaiei; c) creterea duratei de implementare. Rspuns: a
29

3. Care nu sunt activitile efectuate n faza iniierii proiectului: a) stabilirea echipei de iniiere a proiectului; b) stabilirea bunelor relaii cu beneficiarii; c) stabilirea planului iniierii proiectului; d) stabilirea procedurilor manageriale; e) stabilirea cerinelor sistemului. Rspuns: e 4. Tipurile activitilor executate n cadrul planificrii proiectului cuprind: a) Descrierea ariei de ntindere, a variantelor i fezabilitii proiectului; b) Descompunerea proiectului n activiti uor executabile i controlabile; c) Crearea bazei de date; d) Crearea unui buget preliminar; e) Implementarea proiectului. Rspuns: a, b, d 5. Urmtoarele afirmaii sunt corecte: a) Un studiu de fezabilitate are rolul de a asigura informaiile obiective necesare pentru a cunoate dac un proiect poate fi demarat sau nu, sau dac un proiect deja nceput mai poate fi continuat; b) Studiul de fezabilitate face parte din etapa de ntreinere a sistemelor; c) Diagrama Gantt este o modalitate de reprezentare grafic a proiectului. Rspuns: a, c 6. Studiile de fezabilitate trebuie s conin: a) Definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce-i propune el s realizeze); b) Descrierea cerinelor sistemului; c) Explicaia critic a motivrii studiului ntreprins; d) Cuantificarea tuturor costurilor materiale i beneficiilor aferente. Rspuns: a, b, c, d 7. Diagramele Gantt se utilizeaz pentru: a) reprezentarea ordinii activitilor desfurate pentru realizarea proiectului; b) reprezentarea grafic a proiectului; c) descrierea proiectelor simple sau a unor componente ale proiectelor mari; d) monitorizarea stadiului realizrii activitilor planificate. Rspuns: b, c, d

30

Capitolul 3. Analiza sistemului existent i definirea cerinelor noului sistem


3.1. Studiul sistemului informaional existent Prin sistem existent se nelege realitatea obiectiv din organizaia pentru care urmeaz a se realiza sistemul informatic solicitat printr-o comand numit cererea beneficiarului. Analiza sistemului existent i definirea cerinelor noului sistem este prima etap din ciclul de via al dezvoltrii sistemelor informatice, etap prin care se determin modul n care funcioneaz sistemul informaional curent i se evalueaz ceea ce ar dori utilizatorii s realizeze noul sistem. Studiul i analiza sistemului existent are ca obiectiv principal stabilirea cerinelor informaionale ale conducerii n vederea realizrii unui sistem informatic. Studiul sistemului existent cuprinde un grup de activiti care urmresc cunoaterea performantelor tehnico-funcionale ale sistemului informaional, att n ansamblul su, ct i pentru elementele de structur ale acestuia, a cerinelor informaionale ale conducerii, cunoaterea lipsurilor i restriciilor pe care le prezint sistemul existent fa de aceste cerine. De modul de realizare a acestor activiti depinde ntregul proces de realizare a sistemului informatic. Studiul sistemului existent const n [11]: definirea caracteristicilor generale ale sistemului economic; studiul activitilor de baz desfurate n sistem; studiul sistemului de conducere; studiul sistemului informaional; identificarea metodelor i mijloacelor tehnice. Definirea caracteristicilor generale ale sistemului economic implic : cunoaterea profilului, obiectivelor agentului economic; cunoaterea locului n sfera serviciilor si sfera produciei; cunoaterea relaiilor de cooperare cu ali ageni economici; cunoaterea specificului activitii de baz ( producie, servicii); cunoaterea nivelului tehnic; cunoaterea principalilor indicatori economici i evoluia lor; dezvoltarea, modernizarea etc. Studiul activitilor desfurate n sistemul economic, modul de realizare a funciunilor unitii economice se face prin: 1. Pe baza statutului de funcionare a societii se studiaz:
activitile i sarcinile din cadrul acestor funciuni;

- atribuiile ce revin compartimentelor; - modul de realizare a activitilor funcionale din cadrul unitii economice. 2. n cazul activitii de producie se prezint: fluxul de producie, amplasarea locurilor de munc, depozitelor etc.; tipurile de produse, structura lor, ciclurile de realizare;

31

modul de organizare a produciei, stocarea produciei, transporturile interne, controlul de calitate; resursele existente: capaciti; asigurarea tehnic / proiectarea de produse noi; norme tehnice; asigurarea cu materiale necesare; sistemul existent de programare a produciei. Studiul sistemului de conducere se refer la: identificarea caracteristicilor sistemului de conducere existent; sistemul de indicatori cantitativi i valorici; organizarea conducerii; caracteristicile rezultate din statutul de funcionare a societii, tipuri de decizii, modul de lucru a deciziilor. Studiul sistemului informaional presupune: elaborarea schemei fluxului informaional global (cu punerea n eviden a principalelor activiti i a legturilor statice i dinamice dintre acestea); estimarea cantitativ i calitativ a informaiilor de intrare-ieire, modul de culegere i prelucrare; identificarea principalilor algoritmi, regulilor de calcul i a punctelor si regulilor de control; cunoaterea principalelor restricii ale sistemului informaional; situaia raionalizrii fluxurilor i a documentelor din unitatea economica, studii elaborate, stadiul lor de implementare; sistemul de codificare utilizat, restricii; performanele i limitele sistemului informaional existent. Identificarea metodelor i mijloacelor tehnice utilizate pentru prelucrarea datelor n cadrul sistemului informaional existent se face evideniind: mijloacele tehnice existente n dotarea unitii economice ( modul de utilizare, cheltuielile de exploatare, personalul implicat, performante); existena unor aplicaii proiectate i/sau implementate. 3.2. Determinarea cerinelor sistemului Determinarea cerinelor sistemului este activitate esenial n aflarea situaiei existente i a ceea ce se dorete n viitor. Rezultatul activitii de determinare a cerinelor sistemului se concretizeaz n diferite forme ale informaiilor colectate, cum sunt copii ale interviurilor, nsemnri efectuate n timpul observrii i analizei documentelor, interpretri ale rspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru .a., precum i rezultate ale prelucrrilor efectuate de calculator, cum ar fi prototipurile [46]. Rezultatele prezentate dup aceast activitate pot fi rezumate astfel: 1. Informaii obinute n urma conversaiilor cu utilizatorii sau prin observarea activitilor prestate de acetia: copii sau sinteze ale interviurilor, rspunsurile la

32

chestionare sau interpretri ale acestora, nsemnri i rezultate din observarea activitilor, procese verbale ale edinelor ce au avut loc n acest scop; 2. Informaii scrise care exist n unitate: misiunea i strategia afacerii, exemplare ale formularelor, rapoartelor i machetelor de ecrane, manuale ale procedurilor, descrieri ale posturilor de lucru, manuale de instruire, scheme de sisteme i documentaia sistemului existent, rapoartele consultanilor; 3. Informaii obinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fiierelor sesiunilor grupului de sprijinire a sistemului, coninutul depozitelor i rapoartele existente n CASE, ecrane i rapoarte rezultate din prototipurile sistemului, .a. 3.2.1. Metodele tradiionale utilizate n analiza i determinarea cerinelor sistemului Metodele utilizate frecvent n analiza sistemului existent sunt: Interviul; Chestionarul. Interviul este o metod foarte rspndit pentru culegerea informaiilor din sistemul informaional. Utilizatorii acestei metode sunt n general analitii care nu sunt familiarizai cu unitatea studiat i cu problemele ei. Prezint avantajul c las foarte mult libertate creativ analistului n construirea i desfurarea lui. n alegerea persoanelor de intervievat trebuie avute n vedere urmtoarele constatri [8]: persoanele care ocup poziii medii n ierarhia structurii organizatorice furnizeaz informaiile cele mai apropiate de realitate; colectarea de informaii corecte necesit intervievarea att a personalului de conducere, ct i a celui de execuie; n prealabil trebuie verificat competena subiecilor intervievai; lipsa unei atitudini critice poate s denote reineri n exprimarea ideilor. Se vor efectua interviuri la nivelul conducerii i interviuri la nivelul posturilor de lucru. Rezultatul interviului este consemnat n raportul de interviu care trebuie semnat de ctre persoanele intervievate. Chestionarul poate fi utilizat att de ctre analitii nceptori, ct i de ctre cei avansai, familiarizai sau nu cu problemele informaionale-decizionale ale unitii. Prin utilizarea lui dispare filtrul de informaii care este analistul iar cel care furnizeaz informaii are posibilitatea s se concentreze mai bine asupra rspunsurilor. Utiliznd aceast metod, particip un numr mare de furnizori de informaii. Limitele chestionarului constau n faptul c este o metod de verificare a unor cunotine prealabile, fapt ce implic cunoaterea prealabil a domeniului. Aceast metod necesit timp relativ ndelungat pentru ntocmirea chestionarului precum i de culegere i prelucrare a rspunsurilor. Chestionarul nu are o arie larg de utilizare.

33

3.2.2. Metode moderne de analiz i determinare a cerinelor sistemului Ca efect al tendinelor de mrire a timpului de analiz a sistemelor existente, n ultimii ani, s-a efectuat trecerea spre analiza mai puin pronunat a sistemelor ce urmeaz a se realiza. Tehnicile moderne, JAD i prototipizarea, preiau tot mai puine elemente din sistemele existente, ca urmare a analizei efectuate. Altele mai radicale renun aproape total la analiza sistemului existent, este cazul proceselor controlate prin RAD, care apeleaz la JAD, prototipizare i alte instrumente de tip CASE [46]. Joint Application Design(JAD) Spre sfritul anilor 1970, specialitii n realizarea de sisteme de la IBM au elaborat un nou proces de culegere a cerinelor informaionale ale sistemelor i de revizuire a proiectelor sistemelor, numindu-se JAD. Ideea principal a proiectrii JAD o constituie punerea laolalt a tuturor forelor interesate n dezvoltarea sistemelor: utilizatori-cheie, managerii i analitii de sistem implicai n analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totui n sesiunea JAD se urmrete o anumit secven de derulare a activitilor, pe baza unor roluri bine stabilite.

Prototipizarea i determinarea cerinelor sistemelor Prototipizarea este un proces interactiv prin care analitii i utilizatorii pun n discuie o versiune rudimentar a unui sistem informaional, care va fi ntr-o continu schimbare, n funcie de reacia utilizatorilor. Prototipizarea renun la ciclul de via al dezvoltrii sistemelor sau la creterea rolului su [46]. Pentru culegerea informaiilor despre cerinele utilizatorilor nc se apeleaz la interviuri, dar prin prototipizare, operaiunea va fi mai simpl i va solicita un timp mai scurt. Prototipul este vzut i testat de utilizator, avnd posibilitatea s precizeze ce ar mai dori, dar i s-i genereze aceast form nou, cu ajutorul specialitilor. Prototipizarea este facilitat de cteva limbaje sau produse program, inclusiv instrumentele de tip CASE. Prototipizarea este foarte util n determinarea cerinelor sistemului atunci cnd [46]: cerinele utilizatorului nu sunt prea clar formulate sau bine nelese; unul sau mai muli utilizatori sau susintori sunt implicai n sistem; se utilizeaz anumite mijloace de lucru (formulare i rapoarte predefinite). Prototipizarea genereaz i deficiene, cum ar fi: tendina de evitare a unui cadru formal de elaborare a documentaiei privind cerinele sistemului, ceea ce va ngreuna n viitor orice control; fiind conceput de un numr mic de utilizatori va fi probabil respins de viitorii utilizatori; fiind conceput izolat este puin probabil ca el s fie integrat n sistemul existent;

34

nerespectndu-se etapele ciclului de via al dezvoltrii sistemelor pot fi omise aspecte eseniale, cum ar fi securitatea, controlul datelor introduse i standardizarea la nivel de sistem. Paii prototipizrii sunt [46]: Identificarea cerinelor principale ale sistemului; Realizarea prototipului iniial; Proces iterativ de adaptare a sistemului la cerinele utilizatorului; Folosirea sistemului aprobat de utilizatori. Dup determinarea cerinelor sistemului urmeaz structurarea acestora prin utilizarea unor instrumente specifice de modelare logic. 3.3. Structurarea cerinelor sistemului - modelarea logic a datelor i prelucrrilor Indiferent de metodologiile folosite n realizarea unui sistem/aplicaie, toate apeleaz la operaiunea de modelare logic a datelor i prelucrrilor sub form de diagrame, diferenele constnd doar n folosirea mai pronunat a diagramelor pentru descrierea sistemului, ncadrndu-le n diagrame de context, diagrame ale fluxurilor de date fizice i diagrame ale fluxului de date logice. Altele apeleaz la combinaii de diagrame, tabele i forme descriptive [46]. Diagrama de context scoate n eviden aria de ntindere a sistemului analizat, prin specificarea elementelor din interiorul organizaiei i a celor externe, sub denumirea de entiti externe sistemului analizat. 3.3.1. Diagramele fluxurilor de date (DFD) Diagrama fluxului de date ale nivelului logic curent, independent de tehnologie, reliefeaz funciile de prelucrare a datelor executate de ctre sistemul informaional curent. Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor i cerinele funcionale ale noului sistem. Descrieri ale obiectelor DFD se regsesc n aa-zisele dicionare ale proiectelor sau depozitele CASE (repository) [46]. Diagramele fluxului de date DFD au ca obiectiv urmrirea modului de transfer al datelor ntre procesele de prelucrare a lor, astfel de diagrame se mai numesc i modele ale proceselor de prelucrare, iar operaiunea se numete modelarea proceselor. DFD reprezint doar una din tehnicile de analiz structurat. Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a cptat noi accepiuni prin ncorporarea ei n instrumentele de analiz i proiectare cu ajutorul calculatorului, adic n instrumente CASE. Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru construirea DFD n analiza sistemelor se folosesc frecvent reprezentrile grafice, de exemplu diagramele. n continuare vom folosi tehnica reprezentrii grafice a fluxului

35

informaional. Proiectarea fluxului informaional reprezint circulaia informaiei n sistem, transformrile suferite, stocarea informaiei precum i scurgerile de informaie n afara sistemului. Scopul diagramelor de date DFD pentru o anumit component organizatoric sau funcional la care se refer (secie, birou, compartiment, ntreaga unitate, o anumit activitate vnzri, cumprri, ncasri, pli, .a) este de a scoate n relief, ntr-o manier ct mai sugestiv, urmtoarele aspecte [46]: sursa datelor de prelucrare; operaiunile de prelucrare prin care trec datele; destinaia datelor prelucrate; legtura existent ntre prelucrri i activitatea de stocare a datelor. ntocmirea diagramelor de flux de date (DFD) DFD este o reprezentare grafic a transformrii datelor de intrare n date de ieire folosind un set de simboluri de reprezentare i un set de reguli de completare i validare. Simboluri folosite n diagramele realizate cu SSADM proces (transformare): Procesele sunt etichetate cu text ce sugereaz modul de transformare a datelor i sunt identificate printr-un numr(descriere a funciei procesului de prelucrare, ncepnd cu un verb, urmat de o descriere a obiectului funciei de prelucrare). n DFD fizic pentru sistemul existent, se va preciza i locaia (compartiment / persoan) procesului. flux de date: este constituit din datele transmise ntre dou procese. Fluxul de date este etichetat printr-un substantiv ce sugereaz informaia sau pachetul de informaii transmise. entitate extern (terminator): surs / receptor de date. Poate fi un alt sistem (organizaie, compartiment). stoc de date: un depozit temporar sau permanent de date. Poate fi: manual: registre, dosare, arhiv de documente pe suport magnetic: fiiere. Convenii folosite n diagramele de reprezentare a fluxurilor de date DFD: procesele i stocurile de date sunt numerotate secvenial, pentru a putea fi identificate. Numerele asociate proceselor nu semnific ordinea de execuie a acestora;

36

pentru a evita fluxurile de date ntretiate i aspectul de pienjeni al diagramei, entitile externe i stocurile de date pot fi duplicate. O entitate extern duplicat se reprezint prin trasarea unei linii oblice, iar un stoc duplicat printr-o linie suplimentar vertical n partea stng a cutiei; pentru a face diagramele mai lizibile, entitile externe sunt plasate, pe ct posibil, n jurul diagramei iar stocurile de date, n partea central a diagramei; fluxurile de date de la - ctre stocurile de date sunt unidirecionale (fie de adugare, fie de consultare) i nu sunt etichetate. 3.3.2. Descompunerea funcional i rafinarea DFD Dac sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil s realizm de la nceput o DFD detaliat. Pentru a putea descrie n detaliu sistemele complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o descompunere funcional a sistemului, care este realizat prin rafinarea succesiv a proceselor. Primul nivel (nivelul 0) l constituie DIAGRAMA CONTEXTUAL, care definete graniele ntre sistemul analizat si mediu. Nivelele urmtoare se obin prin rafinarea proceselor complexe ntr-o diagram de nivel inferior. Pentru aplicaia DECONTRI au rezultat urmtoarele diagrame [46]:

Figura 3.1. Diagrama contextual pentru aplicaia Decontri

37

Figura 3.2. Diagrama fluxului de date de nivel 1 pentru aplicaia Decontri

38

Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaia Decontri Definirea direciilor de perfecionare a actualului sistem Pe baza activitilor de evaluare i analiz critic se identific neajunsurile actualului sistem i se propun soluii de nlturare a acestora se formuleaz variante de soluii, iar n cadrul acestora se definesc cerinele i restriciile de realizare a sistemului informatic. Definirea direciilor de perfecionare presupune: 1. specificarea obiectivelor i a performantelor sistemului informatic; 2. stabilirea domeniilor de probleme i a principalelor funciuni ale sistemului informatic; 3. definirea cerinelor si restriciilor informaionale pe domenii de probleme i funciuni care const n: definirea principalelor intrri/ ieiri; definirea soluiei de organizare a datelor; definirea variantelor tehnologice de prelucrare; definirea restriciilor informaionale i de control.
39

4. formularea condiiilor pentru realizarea sistemului informatic, care const n: specificarea termenelor i duratelor solicitate; precizarea prioritilor n realizarea obiectivelor sistemului informatic; specificarea cerinelor speciale privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare al sistemului. Pentru fiecare variant de soluie informatic se procedeaz la: evaluarea resurselor necesare (costurile de sistem); evaluarea efectelor economice directe si indirecte; calculul indicatorilor de eficient economic. 3.3.3. Modelarea sistemului curent Indiferent de tipul sistemului analizat, manual sau informatizat, acesta va fi nlocuit de un nou sistem. Orict de ineficient, vechiul sistem trebuie s transfere celui nou o serie de elemente, cum sunt datele folosite, procedurile existente. Deci sistemul fizic actual efectueaz n parte sau n ntregime ceea ce-i propune s fac noul sistem fizic, dar la alt nivel de performan. Necesitatea trecerii de la vechiul la noul sistem ne oblig s decidem asupra celor dou elemente specificate anterior, date i proceduri, ceea ce conduce la obligativitatea constituirii unui model logic al sistemului propus, care s conin una sau mai multe DFD, un model de date i logica procesului de prelucrare. O modalitate de abordare const n prezentarea detaliat a sistemului fizic curent, dup care s se realizeze construirea modelului logic curent, prin abstractizarea celui fizic existent. Se va continua cu scoaterea n relief a ceea ce trebuie neaprat schimbat din sistemul curent i ceea ce trebuie s se realizeze n cel nou. Pornind de la modelul fizic, se deriv modelul logic n cadrul cruia se realizeaz: pune n eviden ce face sistemul, eliminnd detaliile referitoare la modul cum funcioneaz sistemul n implementarea actual; pune n eviden funciunile de baz ale sistemului; permite identificarea i eliminarea problemelor legate de redundana datelor i duplicarea proceselor de prelucrare; permite stabilirea cu o mai mare precizie a granielor sistemului prin eliminarea proceselor manuale care nu pot fi automatizate complet. Derivarea modelului logic al sistemului existent Construirea modelului logic presupune transformarea diagramei de flux a datelor fizice n diagrama de flux a datelor logice. Procesul de derivare a diagramei logice va ncepe de la ultimul nivel de descompunere alctuit de la procesele frunz i va continua prin agregarea proceselor ctre nivelurile superioare. Se parcurg urmtorii pai [46]: 1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin gruparea ntr-un stoc logic de date a entitilor nrudite sau utilizate frecvent. Dup identificarea stocurilor logice de date se construiesc: diagrama de coresponden ntre stocuri logice i entitile din modelul logic; diagrama de coresponden ntre stocuri fizice i stocuri logice de date.

40

2. nlturarea dependenelor fizice i temporale din denumirea proceselor i a fluxurilor de date: din DFD la nivel fizic (se observ c nu exist referine fizice i temporale n aplicaia decontri). 3. Derivarea proceselor logice: scoaterea n afara granielor sistemului a proceselor manuale care nu pot fi automatizate (deciziile); nlocuirea proceselor care nu realizeaz nici o transformare asupra fluxurilor de date cu fluxurile propriu-zise; combinarea proceselor care realizeaz prelucrri asemntoare sau multiple care se execut mpreun sau n secven; nlturarea proceselor care in de implementarea actual i a proceselor redundante. n cazul aplicaiei prezente: se combin procesele nregistrare ncasri n numerar i nregistrare ncasri prin virament deoarece realizeaz prelucrri asemntoare; se nltur procesele redundante nregistrare ncasri n jurnal si nregistrare plti n jurnal. 4. Derivarea fluxurilor logice care presupune nlocuirea numelui de document numai cu fluxul de informaii utilizate efectiv de proces. 5. Gruparea proceselor elementare i transformarea diagramei fizice n diagram logic, aplicnd cei 5 pai. Relaia existent ntre DFD i modelul datelor Dup cum reiese din prezentrile anterioare, fiecare sgeat din DFD reprezint un flux al datelor, n sensul unui traseu pe care structurile datelor elementare sau grupate se vor deplasa n sistem. De exemplu, Facturi desfacere este o dat grupat. Cnd numele ei se plaseaz pe un flux de prelucrare trebuie s vedem i obligativitatea ca acel flux s fie descris prin prisma structurii datelor respective, deci, trebuie prezentate rubricile documentului. Similar va fi abordat i simbolul pentru stocare. La prima vedere, el reprezint locul unde se realizeaz operaiunea, dar foarte important este s prezentm structura datelor pstrate. Firesc, i n cazul fluxului de date, i n cel al stocrii lor nu trebuie uitat descrierea semnificaiei economice. Structura datelor trebuie s fie redus la a treia form normalizat, iar coninutul locurilor de stocare a datelor s fie prezentat prin reduceri la unul sau mai multe tabele relaionale n forma a treia normalizat [46]. n cazul aplicaiei DECONTRI, se obine nivelul elementar al DFD a sistemului logic pentru Decontri cu beneficiarii reprezentat n figura 3.4. Nivelele superioare ale DFD a sistemului logic sunt identice. Tabel 3.1 aplicaia Decontri Sursa Destinaia 1.1. nregistrare D2 FACTURI facturi DESFACERE

Nume flux desfaceri

Continutul fluxului CODCLIENT, DENCLIENT, ADRESAC, CONTC,

41

desfacere D2 FACTURI 1.3. Analiza situaie client DESFACERE desfaceri

BANCA_C, DATAFACTD, NRFACTD, TOTALFACTD CODCLIENT, DENCLIENT, ADRESAC, CONTC, BANCA_C, NRFACTD, TOTALFACTD

Figura 3.4. Diagrama fluxului de date 3.3.4. Modelarea logicii proceselor Dup ce au fost descrise procesele de conversie a datelor n informaii, prin intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefeaz i logica intern a proceselor, orict ar fi de detaliate, chiar i la nivelul proceselor primare, se impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie astfel descrise nct s poat fi convertite n programe prin intermediul limbajelor de programare.

42

n faza de analiz, modelarea logicii proceselor se va derula ct mai detaliat i complet posibil, dar operaiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza ntr-o etap ulterioar i anume proiectarea. Modelarea logicii proceselor ca i diagramele fluxurilor de date fac parte din etapa de analiz a sistemului. n analiza structurat, rezultatele obinute n urma modelrii proceselor sunt descrieri i diagrame structurate care vor prezenta logica fiecrui proces, precum i diagrame care vor evidenia dimensiunea temporal a sistemelor, cnd apar procesele sau evenimentele i modul n care aceste evenimente schimb starea sistemului. Pe scurt se poate spune c modelarea logic a proceselor se va concretiza n urmtoarele elemente ale documentaiei [46]: reprezentarea n engleza structurat; reprezentarea logicii proceselor prin tabele de decizie; reprezentarea logicii proceselor prin arbori de decizie; tabelul sau diagrama strilor de tranziie. Reprezentarea logicii proceselor prin engleza structurat Engleza structurat este o form mult simplificat i modificat a limbii engleze, folosit pentru descrierea coninutului casetelor care marcheaz procesele (prelucrrile) din diagrama fluxului de date. Cuvintele folosite sunt n strns legtur cu logica folosit n conceperea procedurilor componente ale sistemelor informatice [46]. Se folosesc verbe pentru cuvintele cheie i substantive pentru descrierea structurii datelor. Nu exist o form standard de englez structurat, fiecare analist ar putea apela la o form proprie, dar scopul este de a nlesni accesul mai multor persoane la rezultatele analizei nglobate n documentaie. Utilizarea englezei structurate pentru procesul Analiza situaie client din decontri cu beneficiarii este reprezentat mai jos. Analiza situaie client WRITE CLIENTI,FACTURI_DESF, NCASRI READ (FACTURI_DESF) cod = FACTURI_DESF.codclient; den = FACTURI_DESF.denclient; adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca = FACTURI_DESF.bancac; while (not eof (FACTURI_DESF)) { if (cod!=FACTURI_DESF.codclient) { CLIENTI.codclient = cod; CLIENTI.denclient = den; CLIENTI.adresac = adr; CLIENTI.contc = cont;

43

CLIENTI.banca_c = banca; CLIENTI.sold = sold; cod = FACTURI_DESF.codclient; den = FACTURI_DESF.denclient; adr = FACTURI_DESF.adresac; cont = FACTURI_DESF.contc; banca = FACTURI_DESF.bancac; } else { READ(NCASRI); vb=0; vb1=0; while (not eof (NCASRI) AND vb=0) { if (cod=NCASRI.client AND FACTURI_DESF.nrfactd=NCASRI.nrfactd AND FACTURI_DESF.datafactd =NCASRI.datafactd) { if (FACTURI_DESF.totalfactd !=NCASRI.sumaincasata) { sold = sold+ FACTURI_DESF.totalfactd NCASRI.sumaincasata} vb1=1; } else if (vb1=1) vb=1 READ (NCASRI) } MOVE FIRST LINE NCASRI READ (FACTURI_DESF) } CLOSE (FACTURI_DESF, NCASRI, CLIENTI) 3.4. Modelarea conceptual a datelor (diagramele entitate relaie, DER) n cadrul modelrii conceptuale a datelor se va renuna la abordarea proceselor i se va trece la abordarea sistemelor prin prisma datelor. La fel ca i n cazul modelrii proceselor i modelrii logicii proceselor elementele eseniale vor fi diagramele. James Martin i Carma McClure, atunci cnd reliefeaz importana tehnicilor structurate prin obiectivele ce i le propun, consider c o parte a acestora au legtur i cu datele, i anume [46]: S se realizeze o administrare riguroas a datelor. Administrarea datelor se refer la structurarea corect a datelor, la uniformitatea modalitilor de definire i proiectare a datelor la nivel de ntreprindere i nu a sistemului. Corect efectuate, acestea accelereaz procesele de analiz i proiectare i permit s se utilizeze n comun componentele eseniale ale sistemelor: resursele.

44

problemele de structurare a lor i conduc la structuri stabile ale acestora, concretizate prin costuri reduse ale realizrii sistemelor. Dac baza de date a unitii este deosebit de important, atunci pe analiza datelor trebuie s se pun un accent aparte, ea fiind ntotdeauna realizat naintea proiectrii programelor. Firesc, dac tim care sunt cerinele unui sistem (ieirile), imediat ne vom pune ntrebarea din ce se obin acestea (intrrile) i apoi vom urmri cum se pot obine ieirile (procesele). Obiectivul principal al ingineriei informaiei este crearea unui set de metodologii care s poat fi folosite n cele mai diverse medii de lucru, astfel nct s se construiasc modele ale datelor la nivel de ntreprindere, iar sistemele proiectate izolat s se integreze n aceste modele. Datele trebuie s fie unice. Asupra lor, la nivel de ntreprindere, pot fi vzute dou categorii mari de operaiuni: asigurarea datelor (creare, actualizare); utilizarea datelor (obinere de documente, de diverse rapoarte, analize WhatIf, sprijin decizional, diferite cutri de informaii, control i auditare ntreprindere). Modelul conceptual al datelor nseamn o modalitate de reprezentare a datelor organizaiei. Rolul su este de a scoate n relief toate regulile privind identitatea i legturile existente ntre date. Cea mai cunoscut form utilizat pentru modelarea datelor este diagrama entitaterelaie (DER). O modalitate aproape identic este folosit i n analiza i proiectarea orietat-obiect. Modelarea datelor prin DER prezint caracteristicile i structura datelor independent de modul n care acestea sunt memorate n calculator. Modelul se creeaz iterativ. De cele mai multe ori, operaiunea are loc la nivel de ntreprindere, prin apelarea la o categorie foarte larg de date neglijndu-se detaliile exagerate. Doar n etapele urmtoare, n spe cnd se trece la definirea proiectului, are loc construirea unui model anume entitate-relaie prin care s fie scoas n eviden aria de ntindere a proiectului. n timpul structurrii cerinelor, un model entiatate-relaie reprezint cerinele conceptuale de date pentru sistemul luat n discuie. Dup ce sunt descrise complet intrrile i ieirile sistemului n cadrul proiectrii logice, modelul conceptual al datelor, redat sub forma entitate-relaie, este rafinat nainte de a fi trecut ntr-un format logic (de regul, un model relaional al datelor) din care se definesc bazele de date i are loc proiectarea fizic a acestora. Se consider c, n timpul modelrii conceptuale a datelor, se produc i se analizeaz cel puin patru diagrame entitate-relaie [46]: 1. DER care s acopere datele necesare aplicaiei proiectului. Ea va permite stabilirea necesarului de date ale aplicaiei proiectului, fr s se in seama de constrngerile sau confuziile generate de detaliile care nu sunt nc necesare.

S se efectueze o analiz sntoas a datelor. Analizele datelor clarific

45

2. DER pentru aplicaia ce va fi nlocuit. Diferenele dintre aceste diagrame arat ce

schimbri trebuie ntreprinse pentru convertirea bazei de date n noua aplicaie. Nu se aplic n cazul sistemelor complet noi. 3. DER care s scoat n relief ntreaga baz de date din care noua aplicaie i va extrage datele. Ct timp mai multe aplicaii pot folosi aceeai baz de date, aceast diagram i prima evideniaz modul n care noua aplicaie apeleaz la coninutul unor baze de date mult mai extinse. 4. DER pentru ntreaga baz de date din care aplicaia curent i extrage datele necesare. Ea este discutat doar pentru sistemele care exist i pentru care se urmrete mbuntirea. Metodele de determinare a cerinelor trebuie s fie orientate, prin ntrebrile puse, prin anchetele efectuate, i asupra datelor, nu numai asupra proceselor i logicii lor. La nceput, chiar fr utilizarea unei terminologii de specialitate, analistul va fi preocupat de modul n care va afla ct mai multe informaii despre datele necesare viitorului sistem pentru a funciona la parametrii proiectai. ntrebrile vor fi astfel formulate nct s se realizeze o bun nelegere a regulilor dup care vor fi folosite datele n noul sistem, ce politici vor fi utilizate. Nu trebuie, nc, s se intre n detalii de genul: cnd i cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor. Modelarea datelor se realizeaz printr-o combinaie a punctelor de vedere [46]. Un prim punct de vedere, formulat n literatur sub numele de metoda top-down, va scoate n eviden regulile derulrii activitii firmei, printr-o nelegere foarte clar a naturii afacerii, i nu se va opri asupra detaliilor privind modul n care ecranele, rapoartele sau documentele sunt folosite n organizaie. n afara metodei top-down, informaiile necesare construirii modelului datelor se pot obine i prin urmrirea documentaiei firmei, ecrane, rapoarte, formulare, din interiorul sistemului. Acest proces este cunoscut n literatura de specialitate sub numele de metoda bottom-up. Elementele rezultate vor figura n diagramele fluxurilor de date prin care vor fi evideniate datele prelucrate n sistem i de aici va rezulta necesarul de date meninute n baza de date a sistemului. 3.4.1. Modelul Entitate/Relaie (E/R) Cercetrile efectuate pentru definirea unui model de date care s permit reprezentarea ct mai fidel a realitii au condus la definirea conceptului de model semantic nc din 1976 cnd Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astzi o tehnic larg acceptat pentru proiectarea bazelor de date. Modelul E/R permite proiectantului bazei de date s elaboreze un model conceptual de nivel nalt, fr a ine seama de anumite constrngeri impuse de utilizarea unui anumit SGBD, de o anumit platform hardware, sau de anumite considerente de eficien privind exploatarea bazei de date, ceea ce permite o reprezentare mai fidel a realitii avute n vedere, constituind astfel o etap intermediar n proiectarea unei baze de date, fiind din acest punct de vedere asemntor pseudocodului utilizat n activitatea de programare.
46

Modelul Entitate/Relaie (E/R) permite reprezentarea schematic a realitii avute n vedere cu ajutorul unei diagrame E/R definit plecnd de la conceptele de baz: tip de entitate, tip de relaie (legtur, corelaie), atribut. Tipuri de entiti, entiti Tipul de entitate reprezint o clas de obiecte sau un concept cu o existen de sine stttoare, este identificat printr-un nume i este definit de un set de proprieti numite atribute. O entitate este un obiect particular al clasei de obiecte, reprezint o instan a tipului de entitate i este definit de valori corespunztoare ale atributelor ce definesc tipul de entitate. Entitile sunt obiecte sau evenimente (fenomene sau procese economice, n cazul nostru). Obiectele se caracterizeaz printr-o existen de-a lungul timpului, iar evenimentele i fac simit prezena la un moment dat. La rndul lor, obiectelor li se pot asocia cel puin dou evenimente: apariia i dispariia lor. Exemple: ncheierea i ncetarea contractului de munc; predarea produselor la secia expediie i desfacerea lor la beneficiari .a. Evenimentelor le corespund asocieri ntre dou sau mai multe obiecte. Exemplu: CLIENT COMAND PRODUS. Raportat la o anumit organizaie, o entitate este o persoan, un loc, un obiect, eveniment sau concept din domeniul de activitate a utilizatorului despre care organizaia dorete s pstreze anumite date. Se cuvine precizat diferena dintre tipurile entitilor (entity types) i cazurile/instanele entitii (entity instances) [46]. Tipul entitii, cunoscut i sub numele de clasa entitii, este o colecie de entiti care au proprieti sau caracteristici comune. Referirea general la elementele ce pot fi catalogate ca entiti se va realiza printr-un substantiv denumit cu litere majuscule, plasate n interiorul dreptunghiului corespunztor entitii. O instaniere a entitii sau instan, denumit n continuare, caz al entitii sau caz, este o manifestare singular a unui tip de entitate. Un tip de entitate se descrie o singur dat prin modelul datelor, n timp ce mai multe cazuri ale acelui tip de entitate pot fi reprezentate prin datele stocate n bazele de date. De exemplu, exist o singur entitate CLIENT, dar ea poate s aib sute sau mii de cazuri/instane ale acestei entiti stocate n baza de date. Atribute Fiecare tip de entitate are un set de atribute asociate lui. Un atribut este o proprietate sau o caracteristic a unei entiti care prezint interes pentru organizaie. La rndul lor, i relaiile pot avea propriile lor atribute. Exemplu de entitate pentru aplicaia DECONTRI i unele dintre atributele posibile: CLIENT : CodClient, DenClient, AdresaClient Ca i numele tipurilor entitilor, numele atributelor sunt substantive scrise cu majuscule (eventual + minuscule), plasate n interiorul elipselor, legate de entitatea creia i se asociaz. De multe ori ns, chiar i n cazul folosirii produselor CASE, pentru a nu se ncrca o diagram entitate-relaie, se evit prezentarea atributelor. Operaiunea se face, n schimb, n repository, depozitul de informaii despre proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.

47

Cheie candidat i cheie primar Fiecare tip de entitate trebuie s aib un atribut sau un set de atribute prin care s se efectueze diferenierea fiecrui caz de acelai tip. Un set de atribute ale cror valori identific n mod unic instanele unui tip de entitate, constituie o cheie candidat pentru acel tip de entitate. Avnd n vedere faptul c pentru un tip de entitate pot exista mai multe chei candidat, una dintre chei se va desemna drept cheie primar. O cheie-primar este o cheie-candidat care a fost selectat pentru a servi ca identificator de cazuri n cadrul unui tip de entitate [46]. n reprezentrile din DER, n elipsa sau elipsele aferente atributului sau atributelor ce formeaz cheia primar, numele respective se subliniaz (vezi CodClient din entitatea CLIENT ). Un tip de relaie reprezint o asociere ntre dou sau mai multe tipuri de entiti i definete legtura care exist ntre tipurile respective de entiti. Fiecare tip de relaie este identificat printr-un nume care descrie funcia sa i poate conine atribute. O relaie sau o instan a unui tip de relaie este o legtur ntre instane ale tipurilor de entiti asociate n cadrul tipului de relaie corespunztor. Dac R este un tip de relaie definit pe tipurile de entiti E1, E2,,En, atunci R este funcional fa de Ei (1 i n) dac orice instan a tipului de entitate Ei este determinat univoc de instane ale tipurilor de entiti E1,,Ei1,Ei+1,,En prin relaia R. Un tip de relaie R definit pe tipurile de entiti E 1, E2,,En, poate fi funcional sau nu fa de fiecare din tipurile de entiti Ei (1 i n). Un atribut definete o proprietate a unui tip de entitate sau a unui tip de relaie i poate fi: atribut simplu sau elementar, atribut compus (format din mai multe componente, fiecare avnd o existen independent), atribut derivat (valorile sale se obin plecnd de la valorile altor atribute). Pentru reprezentarea unor probleme complexe de tip baz de date, aprute ncepnd din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultnd astfel modelul entitate relaie extins EER. n acest sens la conceptele de baz au fost adugate conceptele suplimentare de superclas, subclas i motenire. O superclas reprezint un tip de entitate care conine subclase distincte care trebuie s fie reprezentate n cadrul modelului, iar o subclas este un membru al unei superclase. O subclas, fiind un tip de entitate distinct, poate avea la rndul su subclase, astfel nct se pot construi ierarhii de clase. O subclas motenete toate atributele superclasei, putnd avea n plus i alte atribute. n diagrama EER, pentru subclase se vor reprezenta numai atributele specifice subclasei. Pentru elaborarea unei diagrame EER, se utilizeaz [14], [20] o serie de simboluri reprezentate n figura 3.5.

48

<nume tip entitate>

Reprezentare tip entitate cu numele <nume tip entitate>

<nume atribut>

Reprezentare atribut cu numele <nume atribut>

<nume atribut>

Reprezentare atribut cheie cu numele <nume atribut>

<nume atribut>

Reprezentare atribut derivat cu numele <nume atribut>

<atribut1>

<atribut2>

Reprezentare atribut compus <nume atribut> format din componentele <atribut1>, <atribut2>

<nume atribut>

<nume tip entitate>

Apartenena atributului <nume atribut> la tipul de entitate <nume tip entitate>

<nume atribut>

<nume tip relaie>

Reprezentare tip de relaie cu numele <nume tip relaie>

Relaia R funcional fa de tipul de entitate E Relaia R nefuncional fa de tipul de entitate E

Superclasa

Apartenena subclasei la superclas

Subclasa

Fig. 3.5. Simboluri utilizate n reprezentarea unei diagrame EER


49

Un exemplu de reprezentare a unui tip de entitate prin diagram este ilustrat n figura 3.6.
DenClient

CodClient

CLIENT

AdresaClient

Figura 3.6. Model de reprezentare a atributelor prin DER

Relaiile entitilor O relaie este o asociere ntre cazurile/instanele uneia sau mai multor tipuri de entiti care prezint interes pentru organizaie. Ele se reprezint printr-un romb ca n exemplul din figura 3.7.

FURNIZORI

Oferte

PRODUSE

Cardinalitatea relaiilor Presupunem c exist dou tipuri de entiti, A i B, ntre care exist o linie de Figura 3.7. Reprezentare relaie Oferte ntre entitile FURNIZORI, PRODUSE legtur pentru a marca relaia. Cardinalitatea unei relaii este dat de un numr al cazurilor/instanelor entitii B care pot sau care ar putea s fie asociate cu fiecare caz al entitii A. Cardinalitatea este sugerat prin 0 (zero), 1, M (multe), cu meniunea c ele pot avea prezen obligatorie sau opional. Cardinalitatea se poate reprezenta n moduri diferite, n funcie de notaia folosit. De exemplu, ea poate fi notat cu semne (0, 1, M, N) sau prin simboluri (linie cu vrf simplu de sgeat pentru 1, linie cu vrf dublu de sgeat pentru M. Alteori, 1 se reprezint prin linie simpl i M prin vrf de sgeat). n multe materiale, inclusiv produse CASE, se folosete notaia model-date, cunoscut mai mult sub numele laba-gtei, conform creia cardinalitatea se reprezint prin urmtoarele simboluri [46]: obligatoriu 1 opional 0 sau 1 n obligatoriu multe (n, unde n ia valori de la 1 la M)

opional 1 sau multe (n, unde n ia valori de la 1 la M) n sau asociative (gerundive) Entiti compuse

50

Atributele pot fi asociate cu o relaie multe-la-multe sau cu o entitate. Un exemplu, din lumea cursurilor-credit, transferabile n cadrul unei perioade. Un student poate urma mai multe cursuri dintr-o list, dar finalizarea cu not se poate efectua n momente (la date) diferite. Prezentm, mai jos, cteva dintre datele concrete [46]: MATRICOLA STUDENT 1111 1177 1155 1111 NUME CURS Informatic Informatic Informatic Drept comercial DATA PROMOVRII Iulie 1999 Septembrie 1999 Septembrie 1999 Ianuarie 2000

Din analiza cazurilor rezult c atributul DATA_PROMOVRII nu este o proprietate a entitii STUDENT, ct timp examenele pot fi date la momente diferite. Dar nu este nici o proprietate a entitii CURS, ct timp acelai curs poate fi susinut la date diferite. n schimb, DATA_PROMOVRII este o proprietate a relaiei dintre STUDENT i CURS. Atributul se asociaz relaiei i se prezint sub form de diagram, ca n fig. 3.8.

Data promovrii

STUDENT

Promovare

CURS

De aici rezult un caz aparte de entitate, numit gerundiv sau compus sau asociativ care, de fapt, este o relaie folosit de analist n model ca un tip de entitate. n Figura 3.8. Asocierea unui atribut la cu romb n interior, n care se astfel de cazuri, se folosete un simbol special: dreptunghi o relaie [46] scrie numele entitii (fig. 3.9) [46].
Data promovrii

STUDENT

Promovare

CURS

Figura 3.9. Redarea unei entiti gerundive (asociative) [46]

51

Scopul diagramelor entitate-relaie este de a surprinde cele mai complete sensuri posibile ale datelor necesare sistemului informaional din organizaie. Tipuri de relaii Din cele prezentate mai sus, rezult c ntre entitile descrise, luate dou cte dou, se pot identifica trei tipuri de relaii (legturi): unu-la-unu, unu-la-multe, multe-lamulte. n diagrame, descrierea relaiilor se face de-a lungul liniilor care leag cele dou entiti. Simbolul vrf-de-sgeat este cunoscut ca indicator al cardinalitii (cardinality indicator). n cele ce urmeaz sunt prezentate exemple de tipuri de relaii [46]. 1.
BIROU

Relaia unu-la-unu (1:1)


este condus de conduce MANAGER

Figura 3.10. Descrierea relaiei 1:1 Fiecare BIROU este condus de un, i numai un, MANAGER Fiecare MANAGER conduce un, i numai un, BIROU. 2. Relaia unu-la-multe (1:M)
VNZARE implic face parte din ARTICOL VNDUT

Figura 3.11. Descrierea relaiei 1:M Fiecare VNZARE implic unul sau mai multe ATRICOL(e)_VNDUT(e) Fiecare ATRICOL_VNDUT face parte din numai o VNZARE 3. Relaia multe-la-multe
livreaz FURNIZOR este livrat de PRODUS

Figura 3.12. Descrierea relaiei M:N Fiecare FURNIZOR livreaz unul sau mai multe PRODUS(e) Fiecare PRODUS este livrat de unul sau mai muli FURNIZOR(i) n anumite cazuri, ntre dou entiti pot exista mai multe relaii. De exemplu, s-ar putea spune c FURNIZOR ofer PRODUS, dar i PRODUS ofer este cumprat de la FURNIZOR, ceea ce s-ar putea reprezenta ca n fig. 3.13.
PRODUS
52

FURNIZOR

este cumprat de la Figura 3.13. Descrierea relaiilor multiple ntre dou entiti

4. Relaii opionale i obligatorii Este posibil ca relaiile dintre entiti s nu fie prezente n toate situaiile. Spre exemplu n cazul proiectelor la care lucreaz diverse persoane, o persoan poate s lucreze la un singur proiect sau la cteva, sau la niciunul i, invers, un proiect poate fi realizat de o persoan, de mai multe sau de nici una. n astfel de situaii, se apeleaz la urmtoarea form de reprezentare (fig. 3.14).
lucreaz la este realizat de

PERSOANA

PROIECT

Figura 3.14. Exemplu de relaie opional

Cercul suprapus pe latura entitii indic poziia 0 (valoarea minim poate fi i zero), conferind relaiei caracterul opional. Un alt aspect se refer la caracterul obligatoriu al relaiilor. S lum exemplul vnzrilor. n relaia 1:M, dintre VNZARE i ARTICOL_VNDUT. Ar fi total eronat ca o entitate s existe fr cealalt: nu poate fi o vnzare fr cel puin un articol vndut i, invers, un articol nu poate fi vndut fr o vnzare. Simbolul folosit pt a marca relaiile obligatorii este un cerc haurat (Figura 3.15).
VNZARE ARTICOL VNDUT Figura 3.15. Exemplu de relaie obligatorie

5. Relaia unei entiti cu ea nsi n practic, apar i situaii n care o entitate se afl n relaie cu ea nsi. Spre exemplul n cadrul entitii ANGAJAT, unii dintre ei sunt coordonatori ai activitii celorlali, situaii situaii care pot fi reprezentate printr-o diagram de forma celei din fig.3.16.

ANGAJAT

coordonator al

raporteaz la Figura 3.16. Redarea relaiei Reprezentarea anterioar se citete astfel: unei entiti cu ea nsi Un angajat poate fi coordonatorul unuia sau mai multor angajai Oricare angajat ntotdeauna raporteaz altui angajat

53

Relaii alternative (sau/sau) Uneori se ivesc situaii cnd relaiile posibile se redau alternativ: fie o variant este de urmat, fie cealalt. De exemplu, o marf destinat vnzrii poate fi realizat de unitatea care o vinde sau poate fi procurat din afar. n ambele cazuri, obiectul comercializat, MARFA, care este o entitate, va fi pus n legtur cu cele dou surse posibile, PRODUCIA_ALTORA i PRODUCIA_PROPRIE, printr-un punct comun, aa cum este prezentat n figura 3.17.
6.

PRODUCIA ALTORA MARFA PRODUCIA PROPRIE

Semnificaia diagramei este urmtoarea: O marf seFigura asociaExemplu de diagram din afar, sau cu producia unitii poate 3.17. sau cu un productor pentru relaiile alternative Un productor din afar poate livra mai multe mrfuri O linie proprie de producie poate livra mai multe mrfuri. Dei diagramele entitate-relaie sunt bine cunoscute i utilizate n domeniul bazelor de date, ele constituie unul din conceptele eseniale ale analizei i proiectrii structurate. Scopul acestor diagrame este de a evidenia entitile de date (obiectele despre care se solicit pstrarea datelor) i relaiile ce exist ntre ele. De remarcat diferena dintre diagrama fluxului de date i diagrama entitate-relaie. n timp ce diagrama fluxurilor de date indic att procesele de prelucrare, ct i entitile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER trateaz doar entitile de date. Din aceast cauz, DER poate fi considerat i ca diagrama modelului datelor sau diagrama conceptual a datelor. n sistemul analizat pentru descrierea DER se apeleaz la simbolul dreptunghi, pentru fiecare entitate. Se recomand ca numele entitii s fie redat printr-un substantiv ct mai sugestiv (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, NCASRI). Dup ce se identific entitile se continu cu mperecherea lor, fiecare cu fiecare, pentru a descrie relaiile dintre ele. Pentru aplicaia Decontri se obine astfel diagrama din figura 3.18

54

Figura 3.18. DER pentru aplicaia Decontri [46] Aplicaie practic Folosind modelul entitate - relaie s se reprezinte diagrama E/R de ansamblu pentru un sistem informatic simplificat al unei firme care desfoar activitate de comer fiind avute n vedere subsistemele: aprovizionare (evidena furnizorilor); desfacere (situaia vnzrilor); urmrirea stocurilor.

Cod furnizor

Cod produs

FURNIZORI

Oferte

PRODUSE

Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaiei de tip m-n Oferte

Cod produs

Cod client

PRODUSE

Vnzri VANZARI 55

CLIENTI

Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaiei de tip m-n Vnzri

Cod produs 1

Aprovizionare Intrri
n

Cod Produs+Depozit+Pre

PRODUSE
1

STOCURI Ieiri Desfacere


n

Fig. 3.21. Subsistemul Urmrirea stocurilor. Reprezentarea relaiilor de tip 1-n Intrri, Ieiri, pentru actualizarea stocurilor

Cod produs

Denumire produs

Descriere produs

PRODUSE Fig. 3.22. Reprezentarea entitii PRODUSE

Cod produs

Unitate de msur
produs

Pre unitar produs

Cod furnizor

Oferte 56 Fig. 3.23. Reprezentarea relaiei Oferte

Localitate

Strad

Numr

Cod furnizor

Denumire furnizor

Adresa furnizor

FURNIZORI Fig. 3.23. Reprezentarea entitii FURNIZORI

Oferta

Teste rezolvate 1. Studiul sistemului existent const n: a) studiul activitilor de baz desfurate de sistem; b) identificarea metodelor si mijloacelor tehnice; c) definirea caracteristicilor generale ale sistemului; d) definirea direciilor de perfecionare ale actualului sistem; e) studiul sistemului de conducere. Rspuns: a, b, c, e 2. Activitatea de determinare a cerinelor sistemului se concretizeaz n diferite forme ale informaiilor colectate, cum sunt: a) copii ale interviurilor; b) realizarea programului; c) implementarea sistemului;
57

d) interpretri ale rspunsurilor la chestionare. Rspuns: a, d 3. Definirea caracteristicilor generale ale sistemului economic implic: a) cunoaterea profilului, obiectivelor agentului economic; b) cunoaterea locului n sfera serviciilor i sfera produciei; c) cunoaterea relaiilor de cooperare cu ali ageni economici; d) cunoaterea specificului activitii de baz ( producie, servicii). Rspuns: a, b, c, d 4. Studiul sistemului de conducere se refer la identificarea: a) caracteristicilor rezultate din statutul de funcionare a societii, tipuri de decizii, modul de luare a deciziilor; b) principalilor algoritmi, reguli de calcul i de control; c) mijloacelor tehnice existente n dotarea unitii economice; d) modului de organizare a produciei. Rspuns: a 5. Metodele tradiionale de determinare a cerinelor sistemelor sunt: a) interviul; b) prototipizarea; c) Joint Application Design (JAD); d) chestionarul. Rspuns: a, d 6. Paii prototipizrii sunt: a) Identificarea cerinelor principale ale sistemului; b) Realizarea prototipului iniial; c) Proces iterativ de adaptare a sistemului la cerinele utilizatorului; d) Folosirea sistemului aprobat de utilizatori. Rspuns: a, b, c, d 7. Scopul diagramelor de date DFD este de a scoate n relief, ntr-o manier ct mai sugestiv, urmtoarele aspecte: a) sursa datelor de prelucrare; b) macheta datelor de prelucrare; c) destinaia datelor prelucrate; d) legtura existent ntre prelucrri i activitatea de stocare a datelor. Rspuns: a, c, d 8. Identificai afirmaia fals: a) Diagrama de context scoate n eviden aria de ntindere a sistemului analizat; b) Diagrama fluxului de date ale nivelului logic curent, independent de tehnologie, reliefeaz funciile de prelucrare a datelor executate de ctre sistemul informaional curent;
58

c) Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor,

structura lor i cerinele funcionale ale noului sistem; d) Diagrama fluxului de date prezint modelarea conceptual a datelor. Rspuns: d 9. Simbolul folosit n diagramele DFD realizate cu SSADM (Structured Systems Analysis and Design Methodology), pentru reprezentarea fluxului de date sunt: a) sgeat; a) elips; b) cerc. Rspuns: a 10. Cte entiti externe conine diagrama de context pentru aplicaia Decontri:

a) patru entiti;

b) cinci entiti;

c) nici o entitate. Rspuns: b

11 Raportul detaliat al cerinelor sistemului conine urmtoarele elemente: a) refacerea analizelor pentru ntregul sistem; b) descrierea i prezentarea unui exemplar al tuturor intrrilor n sistem, inclusiv numele fiecrei intrri, sursa, cine l completeaz, ce date va conine i cum vor fi culese datele; c) o descriere i un model de exemplar pentru fiecare ieire din sistem (rapoarte, documente). Rspuns: b, c 12. Principalele elemente ale documentaiei elaborate pentru modelarea logicii proceselor sunt: a) reprezentarea n engleza structurat; b) reprezentarea logicii proceselor prin tabele de decizie;
59

c) reprezentarea prin diagrame entitate-relaie; d) reprezentarea logicii proceselor prin arbori de decizie; e) tabelul sau diagrama strilor de tranziie. Rspuns: a, b, d, e 13. Cea mai cunoscut form utilizat pentru modelarea conceptual a datelor este: a) diagrama entitate-relaie (DER); b) diagrama fluxului de date (DFD); c) diagrama strilor de tranziie. Rspuns: a 14. n DER pentru fiecare entitate reprezentat se apeleaz la simbolul: a) cerc; b) sgeat; c) romb; d) dreptunghi. Rspuns: d 15. Nu sunt tipuri de relaii: a) relaia unu-la-unu; b) relaia unu-la-multe; c) relaia absolut; d) relaia unei entiti cu ea nsi. Rspuns: c 16. Care din afirmaiile urmtoare sunt adevrate: a) O cheie-primar este o cheie-candidat care a fost selectat pentru a servi ca identificator de cazuri n cadrul unui tip de entitate. b) Entitile sunt obiecte sau evenimente (fenomene sau procese economice, n cazul nostru). c) Un atribut este o proprietate sau o caracteristic a unei entiti care prezint interes pentru organizaie. Rspuns: a, b, c ntrebri 1. Enumerai metode moderne de analiz i determinarea cerinelor sistemului. 2. Descriei tipurile de legturi care pot exista ntre dou mulimi de entiti. 3. Definii cheia unei relaii.

60

Capitolul 4. Proiectarea logic a sistemelor informatice


Dac n primele etape, au fost identificate i structurate cerinele sistemului, n faza de proiectare logic se efectueaz deplasarea ateniei de la prezentarea a ceea ce exist i ce se intenioneaz la descrierea a ceea ce va nsemna noul sistem i cum va funciona. Prezentarea noului sistem const n prezentarea tuturor intrrilor sistemului, a ieirilor, precum i a interfeelor i dialogurilor. 4.1. Proiectarea formularelor/formatelor i a rapoartelor n cadrul etapei de analiz a sistemului informatic, intrrile i ieirile au fost identificate i prezentate, exprimnd cerinele informaionale la nivelul fiecrui subsistem/ aplicaie informatic. n acel moment nu s-au prezentat toate detaliile privind formularele/formatele, rapoartele i procesul de modelare a datelor, insistndu-se mai mult pe identificarea i descrierea lor. Fiecare format/formular de intrare va fi asociat unui flux al datelor de intrare ntrun proces al DFD, iar rapoartele se pot regsi ntr-un flux al datelor generate de un proces al DFD. Un formular/format poate fi un document primar sau o machet de ecran care conine unele date predefinite, crora li se adaug altele ce urmeaz a fi completate n rubrici speciale. Un raport este un document economic n care sunt incluse doar date predefinite, ceea ce nseamn c poate fi numit i document pasiv, folosit pentru a citi i vizualiza informaia. n faza de proiectatre logic se reprezint doar o ciorn a formularelor/formatelor, rapoartelor sau ecranelor, ele fiind privite doar ca structur i machet, pot fi realizate cu ajutorul unui editor de texte sau un produs program orientat spre grafic sub forma unui prototip. 4.1.1. Proiectarea situaiilor cu rezultate finale (rapoartelor) Obiectivul prezentrii detaliate a ieirilor este i acela de a determina formatul i coninutul tuturor rapoartelor imprimate i ale documentelor i ecranelor furnizate de sistem. Proiectarea ieirilor se va face astfel nct s serveasc pentru [11]: transmiterea rezultatelor prelucrrii pe calculator utilizatorului, ntr-o form pe care acesta s o neleag i n care s-i regseasc cerinele sale; transmiterea proiectului situaiilor finale programatorului, fr ambiguiti, pentru a-i permite acestuia trecerea la ntocmirea programelor necesare editrii sau vizualizrii. n proiectarea ieirilor, analistul trebuie s elaboreze un model demonstrativ al raportului sau ecranului i s ntrebe utilizatorul dac informaiile din raport i formatul acestuia sunt accesibile. Dac ieirile nu corespund cerinelor utilizatorului, analistul

61

trebuie s le modifice. Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator l constituie macheta imprimantei. Macheta imprimantei este reprezentarea de detaliu a situaiei de ieire, cuprinznd: antet; titlu; date de identificare; cap de tabel; date elementare ce se imprima rnd de rnd; totalurile. detalii i indicaii tehnice de realizare care se refer la: volumul datelor de ieire; frecven; numr de copii i destinaia fiecreia; grad de precizie al calculelor; condiii speciale de editare; criterii de control, validare i interpretare a datelor de ieire. Specificaiile de ieire vor cuprinde, pentru utilizator, macheta situaiei iar pentru programator macheta situaiei i o serie de indicaii tehnice de realizare. Pe baza specificaiilor de ieire se trece la proiectarea fizic prin care se alege suportul informaiilor de ieire, se realizeaz definitivarea formei i formatului de editare a situaiilor (aezarea n pagina / ecran, spaierea ntre coloane i rnduri, etc.) i se definitiveaz procedurile de utilizare i interpretare a ieirilor. Alegerea tipului de suport fizic de ieire (imprimanta, display, disc fix, floppy disc, banda magnetic etc.) se face n funcie de: timpul de rspuns solicitat, amplasarea utilizatorului fa de calculator, hard-ul i soft-ul existent, costul suportului, msura n care rspunde necesitailor de redare a coninutului informaional al situaiei finale. Cnd se pregtesc ieirile, este bine s se ia n calcul ce se urmrete prin ele, astfel nct apelarea la categoriile de date de mai sus s se efectueze n cunotin de cauz. n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s inem seama de o serie de considerente practice cum ar fi [11]: Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale; Restricii tehnice; Elemente de eficien; Lizibilitate spaiere; Utilizarea formularelor pretiprite; Utilizarea monitoarelor sau terminalelor video; Utilizarea generatoarelor de rapoarte. Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale O serie de cerine ale conducerii privind macheta situaiei finale oblig proiectantul la o anumit structurare i machetare a situaiilor finale. Informaiile se pot mprii n

62

dou grupe prin prisma sistemelor informatice interne i externe. Informaiile interne reprezint acele informaii culese, generate sau folosite n interiorul organizaiei. Informaiile externe se refer la cele colectate sau create de la sau pentru parteneri strini (facturi, rapoarte anuale, etc). n funcie de informaiile care pot fi vzute din punct de vedere al echipei manageriale distingem: informaii curente, de atenionare, indicatori de baz, etc. Restricii tehnice n proiectarea situaiilor finale intervin o serie de restricii datorate caracteristicilor i performanelor tehnice ale echipamentelor periferice i anume: numrul maxim de caractere pe linie; numrul maxim de linii pe pagina / ecran; facilitile de imprimare etc. Pe pia se afla o gam variat de echipamente de redare a rezultatelor. Exist mai multe tipuri de imprimante, console i terminale video, ceea ce creeaz posibilitatea unei alegeri adecvate a perifericelor destinate obinerii diverselor tipuri de situaii finale. Elemente de eficien n proiectarea situaiilor finale nu trebuie sa scape ateniei i aspectele de eficient economic privind: reducerea timpului calculator consumat cu editarea propriu-zisa a situaiilor; economie de hrtie de imprimant. Abilitatea i experiena proprie a programatorilor joac n acest sens un rol important. n vederea optimizrii obinerii situaiilor finale pe imprimant se pot folosi de la caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeai pagin de imprimant; editarea unei situaii imprimnd fa/verso pe aceeai coal; Pentru a nu irosi timp cu editarea unor situaii finale voluminoase se recomand mai nti rularea unor programe scurte care s verifice cheile de control aplicate. Numai dac aceste chei sunt corecte, eventual verificate i de utilizator, se poate lansa editarea analitica a situaiilor finale. Programele care editeaz situaii finale voluminoase trebuie prevzute cu posibilitatea de ntrerupere (respectiv de reluare a editrii n cazul unor incidente ivite n timpul rulrii) sau editarea lor sub forma unui fiier ASCII sau text pe hard disc sau floppy disc, urmnd imprimarea ulterioara a acestui fiier, total sau parial. Lizibilitate spaiere Parcurgerea unei situaii finale trebuie s fie ct mai uoara, citirea unei situaii nu trebuie s dea natere la ambiguiti. Este necesar ca situaia sa fie autoexplicativ. Pentru aceasta, antetul va conine informaii i coduri ce vor indica sursa de emitere a raportului, exprimnd clar, sintetic, coninutul raportului i perioada la care se refer. Capul de tabel, mpreuna cu titlul i antetul, se afieaz pe urmtoarele pagini numai dac au intervenit schimbri n cadrul caracteristicilor de grupare fa de prima pagin, altfel se imprim doar numerotarea coloanelor de tabel. Informaiile importante pot fi subliniate. Totalurile se separ de informaiile analitice. Informaiile care se repet pe linii succesive se imprim o singur dat. Utilizarea formularelor pretiprite Aceasta implica utilizarea unei hrtii de imprimanta ce cuprinde elemente fixe ale situaiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta
63

conduce la o cretere a vitezei de editare i o diminuare a uzurii imprimantelor, riboanelor etc. Totodat situaiile obinute sunt mai estetice i sunt uor de parcurs de utilizatori. Utilizarea monitoarelor sau terminalelor video Prin intermediul unui soft adecvat, monitoarele sau terminalele video ofer posibilitatea afirii situaiilor finale, att n regim alfanumeric, ct i n regim grafic, alegerea modului de lucru fcndu-se prin intermediul unor comenzi sau comutatori. Ecranul unui terminal video n regim alfanumeric este alctuit din linii i coloane iar n regim grafic ecranul este privit ca o matrice de puncte denumite pixeli. Reprezentarea informaiilor de ieire sub forma grafic reprezint un pas nainte fa de editarea sub forma de text a rapoartelor. Aceast form de afiare se recomand factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare a informaiilor de ieire i volumul redus al rapoartelor. Pe lng problemele legate de aezarea informaiilor pe ecran, la proiectarea ecranelor de ieire se iau n considerare i facilitile oferite de monitoare sau terminalele video i anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afiare (normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonor (normal, semnal sonor dup afiarea unui cmp etc.). Utilizarea generatoarelor de rapoarte ( REPORT WRITER ) Multe limbaje de programare, pachete de programe i sisteme de gestiune a bazelor de date dispun de module specializate n editarea de rapoarte, ceea ce conduce la reducerea considerabila a eforturilor programatorilor. De obicei, aceste generatoare solicit precizarea titlului, antetului de coloan, coninutul unui rnd de date (de detaliu), gradele de total i maniera lor de afiare, la nceputul sau la sfritul grupului de date, al paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane, pagini, spaierea dintre linii, coloane, afiarea datelor privind momentul listrii, statistici etc. Astfel de module specializate exist n pachete de programe pentru gestionarea bazelor de date cum ar fi: ACCESS, dBASE, ORACLE, FOXPRO, PARADOX, etc. 4.1.2. Proiectarea codurilor n proiectarea sistemului de coduri trebuie s avem n vedere dou aspecte importante i anume [11]: influena tipului i structurii codului asupra performanelor sistemului informatic; implicaiile utilizrii codurilor n operaiile de culegere a datelor i interpretarea rezultatelor finale de ctre utilizatorii neinformaticieni. Primul aspect ridic probleme de ordin tehnic n realizarea nomenclatorului de coduri i are n vedere facilitarea operaiilor de prelucrare, ocuparea unui spaiu de memorie intern i extern ct mai mic etc. Celui de-al doilea aspect trebuie s i se acorde o atenie mai mare n vederea uurrii activitilor de culegere, verificare a datelor i interpretarea rezultatelor din situaiile finale. Avnd n vedere aceste considerente, se impune ca la proiectarea unui sistem de coduri s se respecte o serie de cerine. Activitile parcurse n realizarea unui sistem de coduri sunt:
64

analiza elementelor ce urmeaz a fi codificate; precizarea i uniformizarea tehnologiei, a denumirilor; stabilirea caracteristicilor i a relaiilor dintre elementele de codificat; alegerea tipurilor de coduri; estimarea capacitii, lungimii i formatului codurilor; atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri); ntreinerea nomenclatoarelor de coduri. Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la nivelul economiei naionale (CAEN, SIRUES, SIRUTA, CNP, etc). 4.1.3. Proiectarea intrrilor n sistemul informatic Datele de intrare parcurg o succesiune de etape pn la utilizarea efectiv n cadrul sistemului informatic. Aceste etape intermediare sunt: nregistrarea datelor pe documentul de intrare; conversia datelor ntr-o form acceptata de sistemul de calcul / transpunere pe suportul tehnic; verificarea sintactic i semantic a datelor de intrare; corecia datelor eronate etc. La proiectarea intrrilor este necesar s se realizeze, n principal urmtoarele activiti: alegerea suportului tehnic pentru culegerea datelor; proiectarea machetelor documentelor de intrare, stabilirea instruciunilor de culegere; stabilirea regulilor de control i validare a datelor; proiectarea formularelor (videoformatului) de intrare. Alegerea suportului tehnic al datelor de intrare se face n funcie de cerinele aplicaiei informatice. Datele introduse de la terminalul video, fie intr imediat n circuitul de prelucrare-actualizare a unei baze de date, fie sunt stocate pe un suport magnetic sau sunt stocate n vederea prelucrrii ulterioare. La proiectarea machetei documentelor de intrare (indiferent de metodele de prelucrare a datelor folosite ulterior) sunt respectate cteva reguli care s nlesneasc completarea i apoi utilizarea documentului att pentru prelucrarea automat a datelor ct mai ales pentru necesitile curente ale salariailor societii economice. Nu este recomandabil s dublm documentele primare, prin proiectarea unor documente destinate exclusiv prelurii datelor pentru necesitile prelucrrii automate. Macheta documentului primar trebuie s conin: antetulce reprezint denumirea unitii i/sau a serviciului care-l emite; denumirea documentului; coduri de identificare, data documentului; rubrici /casete/ rnduri pentru denumirea informaiilor cantitativ-valorice i coduri; rubrici /casete /spaii pentru semnturi i tampile;
65

text explicativ, eventual indicaii de completare i verificare. n ordonarea informaiilor pe document, deci n rubricarea documentului se va ine seama de cteva reguli: antetul se plaseaz n stnga sus; codurile i alte informaii de identificare se plaseaz n dreapta sus; sensul natural de parcurgere este de sus n jos i de la stnga la dreapta; zonele de document ce se completeaz de compartimente/ persoane diferite se marcheaz / grupeaz distinct; mrimea i spaierea documentului, distana dintre rnduri, dimensiunea rubricilor, depind de locul i modalitatea de completare (manual, dactilo, automat) precum i de nivelul de calificare a personalului ce completeaz documentul. Aezarea rubricilor pe document trebuie s respecte ordinea fireasc de folosire a documentului i nu ordinea de utilizare a datelor n programe. Ordinea de culegere a datelor este suficient a fi precizat prin numerotarea rubricilor sau simpla lor ncadrare n chenar sau utilizarea de litere ngroate n denumirea rubricilor implicate n dialogul operator-calculator. Atunci cnd documentul exist ntr-o form pe hrtie, n varianta pe calculator se va urmri pstrarea n mare msur a structurii existente, dar cu adaptri specifice noului mediu. Regulile de control i procedurile de validare a datelor de intrare trebuie s cuprind [11]: reguli de verificare a volumului, secvenei documentelor i a cifrelor de control (dac este cazul) pe pachetele de documente primare; reguli pentru controlul sintactic i semantic a datelor din documentele primare. Aceste reguli se refer la: ncadrarea indicatorilor numerici (n limitele de verosimilitate), corelaii logice (ntre indicatorii nscrii n acelai document, sau cu ali indicatori din baza de date), prezena unor informaii obligatorii (apartenena codurilor la nomenclatoarele de coduri specifice aplicaiei informatice) etc. Aceste reguli sunt necesare pentru scrierea programelor de verificare logic a datelor de intrare. Proiectarea formularelor(videoformatelor) de intrare pentru introducerea datelor de intrare se face n funcie de modul concret de desfurare a dialogului operatorcalculator. Acest dialog se poate desfura sub urmtoarele forme: ntrebare-rspuns cu defilarea liniilor ecranului; afiare pe ecran a machetei de introducere a datelor de intrare. n prima variant, mai uor de realizat practic, operatorul introduce succesiv, ca rspuns la ntrebrile afiate pe ecran, date de intrare. La proiectarea formelor de intrare este necesar ca proiectantul s aib n vedere o serie de aspecte cum ar fi: afiarea la un moment dat a unui volum redus de informaii; afiarea la un moment dat a unei cereri de rspuns ce se refer la o singur informaie; scurtarea rspunsului operatorului prin folosirea mnemonicelor i codificrilor; utilizarea unor formate clare i precise pentru afiare;

66

evitarea cuvintelor i caracterelor dificil de citit sau neles; existenta unor rutine speciale de tipul HELP; preluarea asistat a unor coduri (ex. utilizare tehnici de tip Lookup wizard n ACCESS) n varianta a doua cursorul marcheaz de fiecare dat cmpul curent care se introduce. Ecranul display-ului trebuie s reproduc integral sau simplificat macheta documentului, respectnd aceeai ordine a rubricilor. Mesajele de eroare se pot afia ntro zona prestabilita a ecranului, nsoit de avertizare sonora sau luminoasa. Dac este cazul, pentru unele cmpuri (rubrici) de date se pot prelua valori implicite, atunci cnd nu sunt completate. Aceste valori se preiau din nomenclatorul de coduri, fiierele bazei de date sau tabele special memorate pentru valorile asumate prin lipsa sau prin aplicarea unui algoritm. Pentru o mai uoar operare este necesar s folosim toate facilitile de afiare i de combinare a culorilor oferite de terminalul video (figura 4.1).

Figura 4.1. Formularul(macheta) de intrare pentru facturi n proiectarea formularelor de intrare pot fi utilizate componente specializate n acest sens din sistemele de gestiune a bazelor de date cum ar fi ACCESS, dBASE, ORACLE, PARADOX precum i programe scrise n diverse limbaje de programare. 4.2. Proiectarea interfeelor i a dialogurilor Interfaa cu utilizatorul reprezint o parte a aplicaiei software care permite utilizatorilor s-si exprime inteniile de operare asupra calculatorului i s interpreteze rezultatele aciunilor efectuate de main. Prin proiectarea dialogurilor i a interfeelor se definesc modalitile prin care oamenii i calculatoarele schimb informaii [46]. Metode i echipamente folosite n dialogul om-main Interfaa om main definete modalitatea prin care utilizatorul interacioneaz cu un sistem informatic. Interfeele sunt destul de variate, conform descrierilor, ns toate
67

trebuie s dispun de un stil sau de o metod prin care s se foloseasc anumite echipamente n msur s faciliteze o astfel de interaciune. Metode de interaciune Metodele cele mai utilizate sunt: interaciunea prin limbaj-comand (n acest tip de interaciune utilizatorul transmite calculatorului comenzile sub forma unui ir de caractere); interaciunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin intermediul unui sistem de meniuri i opiuni de meniu sau folosind scurtturi sub form de combinaii de taste); interaciunea bazat pe obiecte icons(comunicarea se face prin intermediul desenelor. Imaginile folosite funcioneaz ca butoanele, la apsarea lor se activeaz o anumit funcie sau comand); interaciunea prin limbaj natural(comenzile se transmit folosind vocea i sintetizatoarele de voce pentru redarea rezultatelor). Echipamentelor necesare interaciunii cu sistemul Cele mai folosite echipamente sunt: keyboard tastatura este format dintr-un set de butoane (taste) Prin intermediul ei se introduc date, comenzi; mouse; joystick; touch screen atingerea ecranului constituie modalitatea prin care are loc selecia; light pen stiloul optic, efectueaz selecia prin apsarea pe ecran; voice vocea constituie modalitatea de transmitere a textelor i comenzilor ctre calculator. Proiectarea dialogurilor Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenele folosite de utilizator pentru a comunica cu un sistem informatic. Rolul proiectantului este de a selecta cele mai potrivite metode i echipamente, precum i de a prezenta condiiile n care se pot afia informaiile sau se pot obine de la utilizator. Pentru a obine rezultate bune trebuie s se in seama de regulile de baz la conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uurina n lucru, controlul, operaiunea invers (refacerea unui element ters), rezolvarea erorilor, etc. O modalitate de prezentare a secvenei dialogurilor este cea care apeleaz la tehnica diagramelor prin care se reprezint meniurile componente ale aplicaiei.

68

Figura 4.2. Exemplu de diagram de apelare a meniurilor Pentru proiectarea interfeelor i dialogurilor se poate apela la ajutorul oferit de produsele CASE sau la mediile de dezvoltare grafic ACCESS, Visual Basic, etc. Pentru a se putea proiecta n condiii optime mediile GUI (Graphical User Interface) trebuie s se cunoasc aceste medii. n mediile grafice informaiile se plaseaz n ferestre. Acestea au trsturi specifice ca: redimensionarea, maximizarea, disponibilitatea la deplasare, meniu sistem, etc. 4.3. Proiectarea logic a bazelor de date Proiectarea logic a bazelor de date este n strns legtur cu modelarea conceptual a datelor, aceasta nsemnnd reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date. Procesul de modelare logic a datelor se deruleaz n paralel cu celelalte activiti ale proiectrii logice: proiectarea formularelor i a rapoartelor i proiectarea dialogurilor i interfeelor. Modelarea logic a datelor se realizeaz nu numai pe baza diagramei entitate-relaie, ci i pe baza machetelor formularelor i a rapoartelor. Se efectueaz analiza datelor elementare din intrrile i ieirile sistemului pentru a se desprinde legturile dintre ele. Prin modelarea logic a datelor se urmrete: structurarea performant a datelor prin procesul de normalizare; obinerea unui model logic al datelor din care s se poat realiza proiectul bazei de date fizice funcie de tipul de SGBD utilizat: relaional cel mai utilizat n prezent, reea, ierarhic, sau orientate-obiect; realizarea unui model al datelor care s rspund cerinelor actuale de date regsite n formulare i rapoarte. Modelarea logic este un proces ascendent (bottom-up, de jos n sus) de obinere a relaiilor din formulare i rapoarte prin transformarea modelului entitate-relaie ntr-o form relaional.

69

Modelarea logic a datelor descrie datele cu ajutorul unei notaii speciale, care corespunde unui mod de organizare a acestora de ctre un sistem de gestiune a bazelor de date. Procesul de modelare a datelor este complex. n fiecare etap a ciclului de via se regsete cte o activitate specific datelor dup cum urmeaz [46]: Analiza Modelele conceptuale ale datelor, prezentarea DER; Proiectarea logic Modelul logic al datelor (relaional); Proiectarea fizic Proiectarea fizic a bazelor de date i a fiierelor (organizarea fiierelor); Implementarea Descrierea fiierelor i a bazelor de date. Dup cum prezint profesorul Oprea D. n Analiza i proiectarea sistemelor informaionale economice n procesul de modelare logic exist patru pai eseniali: 1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare i rapoarte) privind aplicaia, folosindu-se principiile normalizrii; 2. Contopirea tuturor perspectivelor normalizate ale utilizatorilor ntr-un model logic consolidat (centralizat) al datelor, numit i integrarea perspectivelor; 3. Transformarea modelului conceptual al datelor (entitate-relaie), realizat fr s se in cont de perspectiva utilizatorului, ntr-un set de relaii normalizate; 4. Compararea modelului logic consolidat al datelor cu modelul transformat al entitiirelaie i realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicaiei. Rezultatele obinute prin parcurgerea celor patru pai pot fi ilustrate prin intermediul unor exemple oferite n literatura de specialitate de McFadden i Hoffer. Primul pas al modelrii logice se poate explica prin dou rapoarte solicitate de utilizatori, reprezentnd perspectiva utilitii sistemului din punctul lor de vedere: cel mai bun client al produsului X(ecran); situaia comenzilor n curs. Ecranul Cel mai bun client al produsului X, prin percepia utilizatorului, are urmtorul format: Cel mai bun client al produsului Introducei codul produsului: P1122 Data de nceput: 10/10/99 Data de sfrit: 31/12/99 ---------------- -------- ------COD CLIENT: 1111 NUME CLIENT: S.C. ALPHA S.R.L. VOLUM: 1000 Figura 4.3 Model de ecran solicitat de utilizatori [46] Din analiza ecranului se pot desprinde relaiile: CLIENT(COD_CLIENT, NUME) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA)
70

PRODUS(COD_PRODUS) LINIE_COMANDA(NR_COMANDA,COD_PRODUS,CANTITATE_COMANDATA) Raportul Situaia comenzilor n curs are urmtorul format: Pagina 1 Situaia comenzilor n curs 31/03/1998 COD PRODUS CANTITI_DE_LIVRAT A1111 0 A2222 0 B1111 150 Y9999 100 Figura 4.4. Model de raport solicitat de utilizatori [46] Realizarea raportului este posibil prin folosirea urmtoarelor entiti: PRODUS(COD_PRODUS) COMANDA(NR_COMANDA, DATA_COMANDA) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA) FACTURA(NR_FACTURA, DATA_FACTURA) Pasul al doilea presupune comasarea perspectivelor utilizatorilor i crearea unui set integrat al relaiilor, rezultnd urmtoarele relaii: CLIENT(COD_CLIENT, NUME) PRODUS(COD_PRODUS) FACTURA(NR_FACTURA, DATA_FACTURA) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) LIVRARE(COD_PRODUS, NR_FACTURA, CANTITATE_LIVRATA) Pasul al treilea const n transformarea modelului conceptual al datelor (diagramaentitate-relaie) din aplicaie fr s se in cont de punctul de vedere al utilizatorului, ntrun set de relaii normalizate. Din analiza diagramei din figura 4.5 se desprind urmtoarele relaii: CLIENT(COD_CLIENT, NUME, ADRESA) PRODUS(COD_PRODUS, DENUMIRE)

71

FACTURA(NR_FACTURA, NR_COMANDA) COMANDA(NR_COMANDA, COD_CLIENT) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA) Pasul al patrulea compar modelul obinut din pasul doi cu cel din pasul trei i integreaz perspectivele utilizatorilor n vederea obinerii unui model logic final, dup cum urmeaz: CLIENT(COD_CLIENT, NUME, ADRESA) PRODUS(COD_PRODUS, DENUMIRE) FACTURA(NR_FACTURA, NR_COMANDA, DATA_FACTURA) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA) LINIE_COMANDA(NR_COMANDA, COD_PRODUS, CANTITATE_COMANDATA) NUME_CLIENT ADRESA COD_CLIENT NR_FACTURA LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA) Rezultatul modelrii logice a datelor l constituie relaiile normalizate rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza n FACTURA CLIENT actualizarea depozitului (repository) sau a dicionarului proiectului. Diferena major ntre modelarea conceptual i cea logic este c dup modelarea logic a datelor cerinele structurate de date se concretizeaz n relaii, i nu n entiti. Din cauza normalizrii nu este necesar o coresponden unu-la-unu ntre entiti i relaii [46].
Lanseaz Facturare
CANTITATE_LIV

NR_COMANDA

COMANDA

Livrare

Linie_comand

PRODUS

CANTITATE_ COMANDATA

COD_PRODUS

DENUMIRE

72

Figura 4.5. Diagrama entitate-relaie pentru gestiunea clienilor [46]

4.3.1. Normalizarea relaiilor - Forme normale ntre atributele unei relaii sau ntre atribute din relaii diferite pot exista anumite legturi logice (dependene), care influeneaz proprietile schemelor de relaie n raport cu operaiile curente care intervin n timpul exploatrii bazei de date: adugare, tergere, actualizare. Aceste legturi logice, cunoscute n literatura de specialitate sub denumirile de dependenele funcionale, dependenele multivalorice i dependene de cuplare, au implicaii majore asupra criteriilor de proiectare a schemelor relaionale. Alegerea unui model conceptual convenabil pentru o baz de date relaional poate necesita realizarea
73

unor descompuneri pentru anumite scheme de relaie date, descompuneri care s izoleze dependenele existente i prin aceasta s elimine anomaliile care se datoreaz acestor dependene. Dependene funcionale Penru definirea acestui tip de dependene se consider schema de relaie Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare) definit pentru urmrirea serviciilor prestate de o firm pentru diveri clieni. Atributul Adresa este dependent de atributul Nume_client (presupunnd c fiecare client are o singur adres, rezult c fiecare valoare a atributului Nume_client determin n mod unic valoarea corespunztoare a atributului Adresa). Analiznd schema de relaie de mai sus, se constat o redundan relativ la atributul Adresa a crei valoare este repetat pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariia urmtoarelor anomalii: Anomalia la adugare: adresa unui client poate fi preluat numai dup ce pentru acesta se presteaz cel puin un serviciu. Anomalia la tergere: dac se terg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client. Anomalia la actualizare: datorit redundanei relativ la atributul Adresa, dac se schimb adresa unui client este necesar parcurgerea ntregii relaii pentru a identifica i actualiza toate apariiile acestui client, n caz contrar baza de date devine inconsistent (acelai client poate apare la adrese diferite). Aceste anomalii pot fi eliminate, dac schema de relaie Prestari_Servicii se nlocuiete prin urmtoarele dou scheme de relaie: Clienti(Cod, Nume_client, Adresa) Servicii(Cod, Serviciu_prestat, Valoare). Relaia Clienti conine codul, numele i adresa fiecrui client, fr nici un fel de redundan, iar relaia Servicii conine serviciile prestate pentru fiecare client i valorile acestor servicii. Un dezavantaj al descompunerii relaiei iniiale n cele dou relaii este acela c pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu este necesar efectuarea unei operaii de cuplare a relaiilor Clienti i Servicii. Se consider o schem de relaie R i A,B dou atribute simple sau compuse ale schemei de relaie R. Atributul A determin funcional atributul B sau B depinde funcional de A, dac i numai dac oricrei valori a atributului A i corespunde o singur valoare a atributului B (se noteaz A->B). Dependena funcional A->B este total dac nu exist nici un subset C al atributului A (CcA) astfel nct C->B i este parial n caz contrar. n relaia Prestari_Servicii, una din dependenele funcionale care poate fi pus n eviden este Nume_client->Adresa. Deoarece ntr-o relaie orice cheie identific n mod unic fiecare tupl a relaiei, deci determin n mod univoc valorile atributelor tuplei, rezult c n orice relaie atributele sunt dependente funcional fa de cheile acesteia.
74

Se pot face, pn n acest moment, urmtoarele precizri: Eliminarea dependenelor funcionale din schemele de relaie i a consecinelor negative (redundana datelor; anomaliile de adugare, tergere, actualizare) se realizeaz prin descompunerea schemei date ntr-o colecie de scheme mai simple n care sunt evitate neajunsurile mai sus menionate. Reconstituirea relaiei iniiale se poate face prin operaia de cuplare (uniune). Pentru ca descompunerea schemei de relaie s fie echivalent cu relaia iniial, trebuie s fie ndeplinite condiiile: cuplare fr pierdere de informaie; conservarea dependenelor (dependenele funcionale din relaia iniial trebuie s se regseasc n relaiile rezultate prin descompunere). Formele normale sunt scheme de relaie echivalente obinute prin descompunerea unor scheme de relaie n vederea eliminrii redundanei datelor i anomaliilor la adugare, actualizare, tergere nregistrri n baza de date. Descompunerile schemelor de relaii n scheme de relaii echivalente avnd n vedere dependenele funcionale conduc la definirea primelor 4 nivele de forme normale i anume: prima form normal (FN1), a doua form normal (FN2), a treia form normal (FN3) i forma normal BoyceCodd (FNBC). A patra form normal (FN4) este definit avnd n vedere dependenele multivalorice, iar a cincea form normal (FN5) este definit avnd n vedere dependenele de cuplare. ncepnd de la prima form normal i pn la forma normal FN5 se impun condiii din ce n ce mai restrictive asupra relaiilor. Astfel o relaie aflat pe un anumit nivel de normalizare (FN5) satisface toate restriciile cerute de nivele inferioare de normalizare (FN1, FN2, FN3, FNBC, FN4). n cele ce urmeaz sunt date definiiile formelor normale avnd n vedere dependenele funcionale. O relaie R este n prima form normal (FN1) dac i numai dac toate atributele sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul Adresa ar putea fi considerat un atribut neatomic dac n cadrul adresei ne-ar interesa localitatea, strada etc., caz n care trebuie descompus n atribute atomice. O relaie R este n a doua form normal (FN2) dac este n FN1 i orice atribut neprim este total dependent fa de orice cheie a relaiei (atributele prime sunt atribute care fac parte dintr-o cheie a relaiei i cele neprime sunt atributele care nu aparin nici unei chei a relaiei). O relaie R este n a treia form normal (FN3) dac este n FN2 i nici un atribut neprim nu este funcional dependent fa de un alt atribut neprim al relaiei. O relaie R se afl n forma normal Boyce-Codd (FNBC) dac singurele dependene funcionale admise sunt cele n care o cheie determin un alt atribut (nici un atribut prim sau neprim nu poate fi dependent funcional fa de un alt atribut dac acesta nu este sau nu conine o cheie). Dependene multivalorice Pentru ilustrarea acestui tip de dependene se ia n considerare urmtoarea schem de relaie: Clase(Clasa, Discipline, Elevi)

75

ce conine clasele dintr-o instituie de nvmnt, iar pentru fiecare clas sunt nregistrate disciplinele ce se predau i elevii nmatriculai n clasa respectiv. Se poate constata c relaia Clase poate rezulta prin operaia de cuplare dup atributul Clasa a urmtoarelor dou relaii: CD(Clasa, Discipline) CE(Clasa, Elevi) n relaia Clase, presupunnd c pentru o clas dat, fiecare elev frecventeaz toate disciplinele nregistrate pentru acea clas, exist dependenele multivalorice: Clasa ->> Discipline Clasa ->> Elevi. Ca i n cazul dependenelor funcionale, existena dependenelor multivalorice prezint aceleai neajunsuri privind redundana datelor i anomalii la efectuarea operaiilor de adugare, actualizare i tergere nregistrri n baza de date. O relaie R este n a patra form normal dac singurele dependene multivalorice admise sunt cele determinate de un alt atribut care este o cheie sau care conine o cheie a relaiei. ntruct orice dependen funcional este un caz particular de dependen multivaloric, rezult c orice relaie care se afl n forma normal FN4, se afl i n forma normal FNBC. Transformarea unei relaii ntr-o colecie de relaii care s se afle n FN4 este similar cu trecerea n FNBC, ns trebuie avut n vedere att eliminarea dependenelor funcionale ct i a dependenelor multivalorice. n concluzie, putem afirma c n cazul formelor normale de la FN1 la FN4, trecerea de la o form normal la alta s-a fcut prin descompunerea unei relaii n altele dou, urmrindu-se eliminarea dependenelor funcionale i multivalorice. O relaie aflat n forma normal FN4 nu mai poate fi descompus n continuare pe baza acestei metode. Exist situaii cnd relaii aflate n FN4 conin redundane i prezint anomalii la operaiile de adugare, tergere i actualizare. Aceste anomalii sunt cauzate de existena dependenelor de cuplare i pot fi eliminate prin descompunerea relaiei n 3 sau mai multe relaii a cror cuplare are ca rezultat relaia iniial. Dependene de cuplare Se consider schema de relaie: SDS (Specializari, Discipline, Studenti) care conine disciplinele care se predau la diverse specializri i studenii care le frecventeaz, cu precizarea c pot exista discipline opionale care nu sunt frecventate de toi studenii de la specializarea respectiv. n aceste condiii n cadrul schemei de relaie SDS nu au loc dependenele multivalorice: Specializari ->> Discipline Specializari->> Studenti ceea ce nseamn c relaia SDS este n FN4. Dei este n FN4, relaia SDS conine mai multe redundane care pot conduce la anomalii de actualizare. Pe de alt parte, relaia SDS nu poate fi descompus n dou componente din a cror cuplare s rezulte relaia iniial cu conservarea informaiei. Se constat ns c relaia SDS poate fi descompus n urmtoarele 3 relaii:
76

SD(Specializari, Discipline) SS(Specializari, Studenti) DS(Discipline, Studenti) i relaia SDS este rezultatul cuplrii relaiilor: SD, SS i DS fr pierdere de informaie. SDS = SDSSDS. n acest caz spunem c n relaia SDS exist o dependen de cuplare. Dependenele multivalorice sunt cazuri particulare de dependene de cuplare. A cincea form normal este o generalizare a formei normale patru, trecerea unei relaii n FN5 presupunnd eliminarea dependenelor de cuplare existente n cadrul relaiei, mpreun cu anomaliile pe care acestea le creeaz. n cadrul unei relaii pot exista dependene de cuplare care nu conduc la redundan n memorarea datelor i nu produc anomalii la operaiile efectuate asupra nregistrrilor bazei de date (acestea sunt dependenele de cuplare implicate de o cheie a relaiei). O relaie este n forma normal cinci (FN5) dac i numai dac toate dependenele de cuplare existente n relaie sunt implicate de o cheie a acesteia. Relaia SDS se poate descompune, cu conservarea coninutului de informaie, n cele 3 componente ale sale: SD, SS i DS care sunt n FN5. Avnd n vedere similaritatea ce exist ntre definiiile pentru FNBC, FN4 i FN5, acestea pot fi unificate n urmtoarea definiie [20]: O relaie R este n FNBC, FN4, FN5 dac i numai dac singurele dependene funcionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaiei R. n concluzie, prin procesul de normalizare se realizeaz eliminarea din schemele de relaie a dependenelor (funcionale, multivalorice i de cuplare) cu scopul de a obine o schem relaional mai bun din punctul de vedere al redundanei datelor i al anomaliilor ce pot apare la operaiile de adugare, tergere i actualizare nregistrri n baza de date. Normalizarea unei scheme de relaie R nseamn nlocuirea acesteia cu o mulime de proiecii R1,...,Rn astfel nct R s fie echivalent cu uniunea proieciilor R1,...,Rn. Dei normalizarea este o operaie util n proiectarea bazelor de date, aceasta nu ofer ntotdeauna reete pentru obinerea celor mai bune modele i de aceea este la latitudinea proiectantului decizia de a aplica sau nu o anumit etap de normalizare dup o analiz temeinic a avantajelor i dezavantajelor modelului obinut. n unele cazuri normalizarea complet, pn la FN5, s-ar putea s fie dezavantajoas. Avnd n vedere constatrile de mai sus se poate afirma c dei normalizarea nu reprezint o soluie general valabil n orice situaie, totui dac pentru proiectarea bazei de date se aplic corect o metodologie de proiectare descendent, modelul rezultat va fi de la sine normalizat. Cercetrile n acest domeniu continu, fiind definite i alte forme normale printre care FN6 pentru baze de date temporale. O baz de date temporal, pe lng datele curente, conine i date istorice, iar factorul (atributul) timp are un rol esenial (exemple concludente de astfel de baze de date sunt depozitele de date). Astfel, n proiectarea unei baze de date temporale trebuie avute n vedere i alte operaii de descompunere a schemelor de relaie i anume: descompunerea orizontal pentru separarea datelor curente de datele istorice;

77

descompunerea vertical pentru separarea atributelor aceleiai entiti avnd n vedere valorile lor raportate la atributul temporal. n proiectarea unei baze de date nu este exclus nici operaia invers normalizrii numit denormalizare [16], prin care se urmrete nlocuirea unei colecii de scheme de relaie cu o schem de relaie echivalent n vederea eliminrii necesitii efecturii unor operaii de cuplare care pot fi costisitoare. Dac n cazul normalizrii tendina este de a ajunge la nivele ct mai nalte (FN5), pentru denormalizare nu exist criterii clare putnd fi avute n vedere doar aspecte legate de performanele anumitor aplicaii. Un alt principiu care se urmrete n proiectarea unei baze de date este principiul proiectrii ortogonale conform cruia n cadrul unei baze de date dou scheme de relaie reale (variabile de relaie de baz) nu trebuie s aib semnificaii suprapuse. n timp ce prin normalizare se urmrete reducerea redundanei din cadrul unei scheme de relaie, prin proiectarea ortogonal se urmrete reducerea redundanei dintre schemele de relaie. 4.3.2. Simplificarea structurii datelor prin normalizare Problema de baz a proiectrii logice a bazelor de date este cum ar trebui combinate datele elementare pentru a forma relaii(sau tipuri de nregistrri) care s descrie entitile i relaiile dintre entiti. n limbajul bazelor de date, cuvntul relaie nseamn un tabel de date, ceea ce duce la concluzia c bazele de date relaionale (modelul relaional) sunt cldite pe un grup de tabele legate ntre ele [46]. Modelul relaional a fost dezvoltat de ctre Codd. Este un model conceptual de organizare a datelor, destinat reprezentrii legturilor dintre date. El este bazat pe teoria matematic a relaiilor i este definit cu o deosebit rigoare matematic [Popescu I., 1996]. n cadrul modelului relaional datele sunt structurate sub forma de relaii (de aici i denumirea). Cea mai directa i intuitiva modalitate de reprezentare a datelor n cadrul acestui model este sub forma de tabele. Fiecrei relaii i se poate asocia un tabel care are attea coloane cte mulimi leag relaia i are attea linii cte tuple conine relaia. Prezentarea structurii relaionale a datelor impune definirea noiunilor de: domeniu, relaie, atribut i schem a unei relaii. Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de baz ale organizrii datelor sunt prezentate n tabelul urmtor: Tabel 4.1. Concepte utilizate n bazele de date relaionale Formal Uzual Relaie Tablou Tuplu Linie Atribut Coloan Domeniu Tip de dat Fizic Fiier(tabel) nregistrare Cmp Tip de dat

Definirea domeniului Un domeniu este o mulime de valori caracterizat printr-un nume. Un domeniu se poate defini explicit prin enumerarea tuturor valorilor aparinnd acestuia sau definind o

78

proprietate distinctiv a domeniului valorilor, de cele mai multe ori limita superioar i limita inferioar [54]. De exemplu: D1: {F,M} -definire explicit D2: {x| xN, x [0,100]} -definire implicit D3: {s|s=ir de caractere} -definire implicit Pentru un ansamblu de domenii D1,D2,,Dn produsul cartezian al acestora reprezint ansamblul tuplurilor (elemente ale unei relaii) <v 1,v2,,vk> unde vi este un element care aparine domeniului Di. De exemplu, tuplurile <Maria,F,50 >,< Vasile,M,60> aparin produsului cartezian D3xD1xD2. Definirea relaiei O relaie R pe mulimile D1,D2,,Dn este o submulime a produsului cartezian D1xD2xxDn, deci o mulime de tupluri [54]. Considernd c nu se cunosc dect dou persoane, relaia R se definete prin tuplurile care descriu aceste persoane, i anume: R: {<Maria,F,50>,<Vasile,M,60>} O relaie poate fi reprezentat printr-un tabel bidimensional n care fiecare linie corespunde unui tuplu i fiecare coloan corespunde unui domeniu. R: D3 D1 D2 Maria F 50 Vasile M 60 Reprezentarea tabelar este preferat adesea altor forme de reprezentare a relaiilor, deoarece este uor de neles i de utilizat. n prezentarea conceptului de relaie se poate recurge la analogii cu alte concepte cum ar fi cel de fiier. Relaia poate avea semnificaia unui fiier, tuplul poate fi considerat o nregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale cmpurilor de nregistrare. Definirea atributului n timp ce tuplurile dintr-o relaie trebuie s fie unice, un domeniu poate apare de mai multe ori n produsul cartezian pe baza cruia este definit relaia [Popescu I, 1996]. PERS D3 D1 D2 D3 Maria F 50 Vasile Vasile M 60 Maria Relaia PERS reprezint un subansamblu al produsului cartezian D3xD1xD2xD3. Atributul reprezint coloana unei tabele de date, caracterizat printr-un nume. Numele coloanei (atributului) exprim, de obicei, semnificaia valorilor din cadrul coloanei respective. Semnificaia valorilor din cadrul unui tuplu se stabilete n acest caz nu numai pe baza domeniului de care aparin valorile ci i funcie de poziia ocupat n cadrul tuplului. Dependena fa de ordinea datelor nseamn o reducere a flexibilitii organizrii datelor.
79

ntr-o organizare eficient, flexibil, ordinea liniilor i a coloanelor nu trebuie s prezinte nici o importan. Pentru a diferenia coloanele care conin valori ale aceluiai domeniu, i a elimina astfel dependena de poziie n cadrul tabelei se introduce tocmai conceptul de atribut. Fiecare relaie are asociat un nume sau un identificator propriu. Schema unei relaii este format din ansamblul elementelor definitorii sau din nivelul relaiei urmat de lista atributelor specifice. n mulimile matematice nu este permis ca un obiect s apar de mai multe ori. Ct timp o relaie este o mulime de tupluri, teoretic nici o linie a unei relaii nu poate fi duplicatul altei linii. Dup cum reiese din prezentrile anterioare, dac o coloan sau o combinaie de coloane nu poate s identifice n mod unic o linie, atunci trebuie inventat o coloan-cheie special. O tehnica de proiectare a modelului conceptual al bazei de date ntr-o abordare bottom-up este tehnica celor cinci forme normale. Conform acestei tehnici, atributele entitilor definite se organizeaz ntr-o singur tabel sau n mai multe i se urmrete descompunerea acestor tabele n altele, fr pierdere de informaii n scopul eliminrii anomaliilor de ordin logic i fizic. Acest lucru se realizeaz prin parcurgerea a o serie de etape, de normalizare, prin care se trece de la o forma normal la alta. Se apreciaz posibilitatea existentei a cinci forme normale (FN). Prin parcurgerea acestor etape, se ajunge n mod succesiv s se amelioreze structura bazei de date, nlturndu-se treptat o serie de neajunsuri i asigurnd faciliti sporite n privina ncrcrii, actualizrii i exploatrii bazei de date. O relaie nenormalizat conine unul sau mai multe grupuri care se repet. Necesitatea normalizrii progresive este dat de faptul c anumite relaii pot genera o serie de situaii nedorite, aa-numitele anomalii de actualizare, cum sunt: anomalia de tergere, anomalia de adugare, anomalia de modificare [11]. 4.3.3. Transformarea diagramelor entitate-relaie n relaii Pentru a se putea compara rezultatele obinute n etapa de proiectare logic a datelor, adic a relaiilor normalizate, cu diagrama entitate-relaie, rezultat al proiectrii conceptuale, aceasta din urm trebuie s fie convertit n relaii, de asemenea, normalizate. ntregul proces se desfoar n patru pai, astfel: [46] Reprezentarea entitilor. Fiecare tip de entitate din diagrama entitate-relaie este reprezentat ca o relaie n modulul relaional al datelor. Identificatorul tipului de entitate devine cheie primar a relaiei, iar celelalte atribute ale tipului entitii devin atribute non-cheie ale relaiei. Reprezentarea legturilor. Fiecare legtur din diagrama entitate-relaie trebuie s fie reprezentat n modelul relaional al datelor. Reprezentarea legturii se efectueaz n funcie de natura ei. De exemplu, uneori se poate constitui o relaie prin includerea cheii primare a unei relaii ca o cheie strin n alt relaie. Astfel, se poate crea o relaie separat pentru reprezentarea legturii.

80

Normalizarea relaiilor. Relaiile create n paii 1 i 2 pot conine redundane nedorite i vor constitui surse de nregistrare a anomaliilor n timpul actualizrii. Normalizarea va conduce la o bun structurare a relaiilor. Fuziunea relaiilor. n timpul modelrii logice a datelor s-au creat diferite relaii, att pe baza normalizrii ascendente a perspectivelor utilizatorilor, ct i a transformrii uneia sau a mai multor diagrame entitate-relaie n seturi de relaii. n structura acestor seturi de relaii pot exista unele relaii redundante, cum ar fi existena a dou sau mai multe relaii care descriu acelai tip de entitate, ce ar trebui s fuzioneze i s se renormalizeze pentru extragerea eventualelor redundane. Teste rezolvate 1. Afirmaiile urmtoare nu sunt corecte: a) Fiecare Format/formular de intrare va fi asociat unui flux al datelor de intrare ntr-un proces al DFD; b) Un proces al DFD va fi asociat cu o macheta de ecran; c) Rapoartele se pot regsi ntr-un flux al datelor generate de un proces al DFD. Rspuns: b 2. Prezentarea informaiile din formulare/formate i rapoarte pot fi oferite: a) sub form de text; b) sub form de sfaturi; c) sub form de grafice; d) sub form de tabele. Rspuns: a, c, d 3. Macheta imprimantei cuprinde: a) antet; b) titlu; c) date elementare ce se imprima rnd de rnd; d) totalurile. Rspuns: a, b, c, d 4. Detaliile i indicaiile tehnice de realizare a machetei imprimantei se refer la: a) volumul datelor de ieire; b) intensitatea datelor; c) contrast. Rspuns: a 5. Alegerea tipului de suport fizic de ieire (imprimanta, display, etc.) se face n funcie de: a) sursa de energie; b) calitatea datelor; c) costul suportului. Rspuns: c 6. n definitivarea formei i formatului de prezentare a situaiilor finale trebuie s inem seama de o serie de considerente practice cum ar fi: a) Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale;
81

b) Restricii tehnice; c) Utilizarea formularelor pretiprite; d) Utilizarea generatoarelor de rapoarte. Rspuns: a, b, c, d 7. Activitile parcurse la realizarea unui sistem de coduri sunt: a) analiza elementelor care urmeaz a fi codificate; b) analiza sistemului decizional; c) uniformizarea datelor de intrare; d) alegerea tipurilor de coduri. Rspuns: a, d 8. La proiectarea intrrilor este necesar s se realizeze, n principal urmtoarele activiti: a) alegerea coleciilor de date; b) proiectarea machetelor documentelor de intrare; c) alegerea regulilor de control i validare a datelor; d) proiectarea formularelor (videoformatului) de intrare. Rspuns: b, c, d 9. Macheta documentului de intrare conine: a) antetul documentului; b) diagrama fluxului de date; c) denumirea documentului. Rspuns: a, c 10. Nu sunt metode de interaciune om main: a) interaciunea permanent, b) interaciunea prin meniuri, c) interaciunea bazat pe obiecte icons, d) interaciunea prin limbaj natural. Rspuns: a 11. Echipamentele necesare interaciunii cu sistemul sunt: a) eyescreen; b) keyboard; c) mouse. Rspuns: b, c 12. Construirea prototipului secvenei de derulare a dialogurilor se poate face cu ajutorul: a) instruciunilor repetitive; b) produselor CASE; c) mediile de dezvoltare grafic. Rspuns: b, c 13. n procesul de modelare logic a datelor sunt pai eseniali: a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare i rapoarte) privind aplicaia, folosindu-se principiile normalizri; b) Implementarea modelului logic al datelor. c) Transformarea modelului conceptual al datelor (entitate-relaie), realizat fr s se in cont de perspectiva utilizatorului, ntr-un set de relaii normalizate; Rspuns: a, c 14. Nu sunt elemente de baz ale structurii relaionale a datelor:
82

a) b) c) d) e)

Relaia; Atributul; Fiierul; Domeniul; Tuplul.

Rspuns: c 15. Paii parcuri n procesul de transformare a diagramelor entitate-relaie n relaii sunt: a) Reprezentarea entitilor; b) Reprezentarea legturilor; c) Normalizarea relaiilor. Rspuns: a, b, c 16. Modelul conceptual pune n eviden: a) modul de stocare a datelor pe suportul de memorare; b) reprezentarea logic, detaliat a entitilor, asocierilor (legturilor) i datelor elementare ale unei organizaii; c) structura global de organizare a datelor. Rspuns: b), c) 17. Normalizarea unei relaii const n: a) Descrierea relaiei n limbajul de descriere a datelor; b) Identificarea dependenelor ntre atributele relaiei; c) Descompunerea relaiei n relaii echivalente urmrind eliminarea redundanei datelor i anomaliilor la efectuarea operaiilor de adaugare, actualizare i tergere n baza de date. Rspuns: c)

83

Capitolul 5. Proiectarea fizic a sistemelor informatice


Proiectarea fizic cunoscut i sub numele de proiectare de detaliu, urmeaz proiectrii logice ntlnit i sub numele de proiectare general sau proiectare de ansamblu. n timpul proiectrii logice se prezint o imagine de ansamblu (general) a sistemului, n timp ce proiectarea fizic nseamn o abordare detaliat a sistemului. Cu alte cuvinte, n etapa de proiectare logic se acumuleaz informaiile de natur s sintetizeze cerinele utilizatorilor noului sistem, operaiune prestat de analitii de sistem, iar n timpul proiectrii fizice se prezint punctele de vedere ale specialitilor, cum ar fi cei din domeniul bazelor de date, securitii sistemelor, reelelor de calculatoare, programrii, etc. Proiectarea fizic implic parcurgerea urmtorilor pai [46]: 1. Proiectarea fizic a bazelor de date i a fiierelor. O astfel de activitate nseamn descrierea modului n care vor fi stocate datele i cum se va asigura controlul lor pentru a se oferi o securitate maxim; 2. Proiectarea structurii sistemului i a programelor. Se descriu programele sau modulele acestora care s fie n strns concordan cu diagramele fluxurilor de date i cu celelalte piese ale documentaiei realizate n etapele anterioare; 3. Proiectarea strategiilor de prelucrare distribuit. Se vor prezenta modalitile n care utilizatorul poate s dispun de date i facilitile de prelucrare oferite de reele de calculatoare. 5.1. Proiectarea fizic a bazelor de date i a fiierelor Modelul conceptual surprinde structura global de organizare a datelor, asigurndu-se independena total fa de orice sistem de gestiune a bazelor de date. Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaie(DER), motiv pentru care este cunoscut i sub numele de modelul entitate-relaie al datelor. El scoate n eviden reprezentarea logic, detaliat a entitilor, asocierilor (legturilor) i datelor elementare ale unei organizaii sau ale unei pri din ea. Modelul se realizeaz n faza de analiz. Modelul logic al datelor nseamn descrierea datelor n concordan cu modelul de organizare a acestora de ctre sistemele de gestiune a bazelor de date. n acest material s-a ales modelul relaional. Conform cu acest model datele sunt reprezentate n baza de date sub forma tabelelor sau relaiilor create din diagrama entitate-relaie obinut n etapa anterioar. O baz de date poate fi definit ca un ansamblu de date elementare sau structurate, accesibile unei comuniti de utilizatori. Mai concret, la nivel fizic, o baz de date este un ansamblu de fiiere intercorelate, care conine nucleul de date necesare unui sistem informatic (aplicaie informatic). Un fiier este un ansamblu de nregistrri fizice, omogene din punct de vedere al coninutului i al prelucrrii. O nregistrare fizic este unitatea de transfer ntre memoria intern i cea extern a calculatorului. nregistrarea fizic este format din una sau mai multe nregistrri logice. O nregistrare logic este

84

unitatea de prelucrare din punct de vedere al programului utilizator. Aceasta este format dintr-un ansamblu de cmpuri, care descriu o anumit entitate. Modul de stocare a datelor pe suportul fizic de memorare este funcie de sistemul de gestiune a bazelor de date utilizat. Proiectarea fizic a bazelor de date i a fiierelor i propune s asigure trecerea de la descrierea logic a datelor la una tehnic, de stocare a datelor. O problem de importan major n cadrul acestei etape o constituie alegerea Sistemului de Gestiune a Bazelor de Date adecvat soluionrii optime a problemelor formulate n etapele anterioare ale realizrii sistemului informatic. 5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt: Centralizarea datelor permite: suprimarea redundanei, asigurarea unicitii nregistrrii i controlul centralizat (asupra datelor). n prelucrarea clasic n care fiierele sunt dedicate aplicaiilor, aceleai date apar nregistrate n mai multe fiiere i n formate diferite. Acest lucru implic o utilizare ineficient a spaiului de memorie extern, actualizarea dificil a acestor date i lizibilitate redus ca urmare a formatelor diferite. Independena ntre date i prelucrri. Baza de date, ca imagine a unei anumite realiti, trebuie actualizat permanent. Acest lucru nu trebuie s afecteze programele de prelucrare. Pentru aceasta trebuie ca fiecare program s aib o viziune proprie asupra BD Realizarea de legturi ntre entitile de date, care sunt indispensabile pentru exploatarea eficient a sistemului informatic. Spre exemplu, n cadrul gestiunii aprovizionrii, trebuie asociat un furnizor la lista de produse pe care le vinde i invers, un produs la lista de furnizori, preciznd condiiile de vnzare pentru un furnizor i un produs. Integritatea datelor asigur fiabilitatea i coerena bazei de date (BD). Pentru aceasta trebuie definite restricii de integritate cum ar fi: apartenena la o list de valori sau interval; apartenena la un anumit format; reguli de coeren cu alte date. Securitatea datelor. Baza de date trebuie s fie protejat mpotriva unei distrugeri logice (anomalie de actualizare) sau fizice. Pentru aceasta exist instrumente care permit: crearea unor puncte de repriz; altfel spus, salvarea din timp n timp a unor copii coerente ale bazei de date; gestiunea unui jurnal de tranzacii; lista operaiilor realizate asupra bazei de date dup ultimul punct de repriz. Confidenialitatea datelor este asigurat prin proceduri de: identificare a utilizatorilor prin nume sau cod; autentificarea prin parole; autorizarea accesului difereniat prin drepturi de creare, consultare modificare sau tergere pentru anumite segmente de date.

85

Partajarea datelor permite nlnuirea tranzaciilor solicitate simultan pe aceeai nregistrare din baza de date, prin blocarea cererilor n ateptare i deservirea ulterioar a acestora. 5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD) Sistemul de gestiune a bazelor de date referit prescurtat SGBD sau DBMS (Data Base Management System) este un sistem de programe care permite definirea, crearea i ntreinerea bazei de date, precum i accesul controlat la baza de date. Un SGBD ofer urmtoarele faciliti pentru crearea i exploatarea bazelor de date: faciliti de descriere a datelor, prin intermediul unui limbaj de descriere a datelor DDL (Data Description Language) care permite utilizatorului s descrie structurile de date ce vor fi memorate n baza de date; faciliti de manipulare a datelor, prin intermediul unui limbaj de manipulare a datelor DML (Data Manipulation Language) care permite utilizatorului s insereze, actualizeze, tearg, s prelucreze i s extrag date din baza de date; controlul accesului la baza de date prin intermediul unui limbaj de control DCL (Data Control Language) care asigur: - sistem de securitate, previne accesarea bazei de date de ctre utilizatori neautorizai; - sistem de integritate, menine concordana datelor stocate n baza de date; - sistem de control al concurenei, permite accesul partajat la baza de date; - sistem de control al refacerii, permite recuperarea bazei de date n urma unor defeciuni hard sau soft; mecanism de vizualizare, prin care un utilizator poate vedea acea parte a bazei de date care l intereseaz. n majoritatea produselor comerciale de baze de date , cele trei limbaje se regsesc reunite n cadrul unui singur limbaj (spre exemplu limbajul SQL). 5.1.3. Administratorul bazei de date Administratorul bazei de date referit prescurtat DBA (Data Base Administrator), este o persoan sau un grup de persoane care coordoneaz i rspunde de ansamblul activitilor privind baza de date, ncepnd din faza de proiectare i continund cu celelalte etape pe ntreaga perioad de via a bazei de date. Astfel, n faza de proiectare a bazei de date, administratorul stabilete SGBD-ul ce va fi utilizat, echipamentele necesare, structurile de date plecnd de la necesitile de informaie ale tuturor utilizatorilor bazei de date, drepturile de acces la date ale fiecrui utilizator. Rezultatul fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema general a bazei de date), modelului extern (subschema proprie fiecrui utilizator) i stabilirea modalitilor de reprezentare a structurilor de date la nivel fizic pe suporturile de memorare externe utilizate. Drepturile de acces la baza de date pot fi definite [ORA92] fie pentru fiecare utilizator n parte, fie pentru grupuri de utilizatori (denumite Role), fiecare utilizator fiind apoi asignat unui grup. Dup proiectarea bazei de date,
86

administratorul va menine permanent legtura cu utilizatorii acesteia pentru rezolvarea cerinelor utilizatorilor i impunerea unei discipline n vederea alinierii la standardele existente. Administratorul va realiza, ori de cte ori se impune, reorganizarea structurii fizice a datelor n vederea optimizrii parametrilor de funcionare a ntregului sistem i va stabili proceduri de arhivare a datelor i proceduri de recuperare a bazei de date la avarii i defecte. Pentru a preveni accesul neautorizat la date, n cadrul sistemului de securitate pot fi prevzute [16] i alte mecanisme i anume: evidena de auditare, criptarea datelor. Evidena de auditare const dintr-un fiier n care sistemul nregistreaz automat toate operaiile efectuate asupra datelor, fiier ce va putea fi consultat de ctre persoane autorizate pentru a verifica efectuarea unor operaii neautorizate. O nregistrare din evidena de auditare va conine urmtoarele informaii: textul surs al operaiei executate, terminalul de la care a fost lansat operaia, utilizatorul care a lansat operaia, data i ora operrii, obiectele bazei de date afectate, imaginile datelor afectate nainte de efectuarea operaiei, imaginile datelor afectate dup efectuarea operaiei. Pentru a preveni accesul unor intrui la baza de date, care ncearc s ocoleasc sistemul, se utilizeaz criptarea datelor, mecanism ce const n stocarea i transmiterea datelor pe cile de comunicaie sub form cifrat. Criptarea se realizeaz cu ajutorul unor algoritmi de criptare printre care cel mai recent este standardul american de criptare avansat AES (Advanced Encryption Standard). 5.1.4. Proiectarea securitii bazelor de date i a fiierelor Securitatea este abordat din mai multe puncte de vedere, dar cea referitoare la baze de date i la fiiere presupune luarea unor msuri pentru reconstituirea datelor pierdute sau preluate eronat, precum i pentru accesul neautorizat sau incomodarea pn la a face imposibil citirea datelor, prin criptare, atunci cnd ele sunt accesate ilegal. Aadar dou aspecte vor fi relevante: reconstituirea datelor i criptarea lor [46]. Reconstituirea datelor este des asociat cu existena fiierelor de tip back-up, ns n practic este posibil i reconstituirea fr apelarea la acest tip de fiiere. n vederea controlrii corectitudinii datelor tranzacionate se apeleaz la fiiere cu rol special, care conin un istoric, n ordine cronologic, al schimbrilor i accesrilor efectuate asupra fiierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fiierele distruse, dar i la verificarea corectitudinii operaiunilor de actualizare. Securitatea prin criptografiere se refer la asigurarea transformrii datelor de comunicat ntr-o form neinteligibil pentru toi ceilali receptori, exceptndu-l pe cel autorizat. Criptarea a devenit una dintre cele mai puternice modaliti de asigurare a securitii datelor. Ea poate fi realizat prin sistemul de operare sau prin SGBD, dar i prin rutine create de ctre specialiti. n cele ce urmeaz sunt prezentate criteriile avute n vedere n alegerea tipului de SGBD [11]. a) Portabilitatea SGBD-ului. Prin aceasta nelegem posibilitatea de a utiliza un SGBD de pe un sistem de calcul pe un altul. Portabilitatea cuprinde dou aspecte i anume: portabilitatea programelor propriu-zise i portabilitatea datelor. Pentru realizarea unor programe portabile este necesar ca: programele s conin ct mai
87

puine elemente legate de echipament. Portabilitatea sistemului de gestiune privit prin prisma portabilitaii datelor se refer la posibilitatea de a folosi o serie de date utilizate n cadrul unui sistem informatic de ctre un alt sistem informatic, deci posibilitatea integrrii fiierelor deja existente n cadrul unui alt sistem. b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a unitii centrale; costului de ntreinere i dezvoltare; resurselor hard imobilizate; costului de adaptare i trecere pe un nou sistem de calcul; costul documentaiei etc. c) Facilitile de implementare, ntreinere i exploatare a bazei de date. Acestea sunt reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare i regsire a datelor, care s permit un acces ct mai rapid la orice informaie; timpul ct mai redus pentru actualizare, cutare i rspuns la cererile de informare; editarea operativ a celor mai variate tipuri de situaii solicitate de ctre utilizator; posibilitatea de inserie a unor programe de aplicaie, programe de validare de date, de actualizare, rutine statistice, rutine de sortare, rutine de prezentare grafic a ieirilor etc. d) Posibilitatea gestionarii structurilor complexe de date. e) Multitudinea metodelor de acces. In funcie de cerinele proprii aplicaiei, sistemul va trebui s suporte interogri sau actualizri n timp real avnd proceduri de tip conversaional. f) Protecia i securitatea datelor din baz. g) Specificul aplicaiei. Este cunoscut faptul c programele sunt orientate pe aplicaii, cum ar fi: programarea produciei, aprovizionare-desfacere, optimizri, prognoze etc. Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari cum ar fi: mentenana sistemului, facilitile ce le ofer administratorului bazei de date, calitatea documentaiei oferite de furnizori, asisten n implementarea sistemului i n pregtirea utilizatorilor etc. Toi aceti factori alturi de criteriile enunate pot s influeneze succesul n implementarea SGBD-ului i eficiena economic pe ansamblul sistemului informatic. n cele ce urmeaz se vor prezenta o serie de aspecte privind utilizarea limbajului SQL pentru crearea bazei de date, definirea utilizatorilor i acordarea drepturilor de acces, definirea interogrilor bazei de date, precum i exemple practice sub SGBD ORACLE. 5.1.5. Limbajul SQL - Crearea, Administrarea i Interogarea bazelor de date relaionale Limbajul SQL (Structured Query Language) a fost realizat n cadrul firmei IBM ca limbaj de interogare al SGBD System R i ulterior a devenit unul din cele mai rspndite limbaje pentru SGBD-urile relaionale. Limbajul SQL, ca limbaj de interogare a bazelor de date relaionale, este construit pe baza a dou formalisme abstracte enunate n cele ce urmeaz. 1. Algebra relaional prin care interogrile sunt exprimate prin aplicarea unor operatori unari sau binari care constituie primitive ce acioneaz asupra relaiilor, rezultatul interogrilor fiind tot relaii, ceea ce permite asocierea i imbricarea
88

acestor operatori pentru a forma interogri complexe. Operatorii algebrei relaionale se mpart n dou grupe i anume: - operaii pe mulimi (Reuniunea, Intersecia, Diferena, Produsul cartezian); - operatori relaionali speciali (Selecia, Proiecia, Cuplarea (JOIN), Diviziunea). 2. Calculul relaional prin care interogrile descriu mulimea tuplelor rezultat prin specificarea unui predicat (condiie) care trebuie satisfcut de aceste tuple. ncepnd din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de interogare ale bazelor de date relaionale fiind utilizat att n cadrul unor SGBD-uri complexe cum ar fi SGBD ORACLE (liderul mondial n domeniul bazelor de date), ct i n cadrul unor SGBD-uri de complexitate redus cum ar fi cele din familia xBase (Dbase IV, FoxPro). Standardul SQL utilizat pn la nceputul anului 2000 este cel realizat n 1992 i cunoscut sub numele de SQL92 sau SQL2. Noul standard SQL3 lansat n 1999 are n vedere o serie de extensii fa de SQL2 dup cum urmeaz: faciliti orientate obiect posibilitatea de definire de ctre utilizator a tipurilor abstracte de date care s permit descrierea de metode, identitatea obiectelor, subtipuri i motenire, polimorfism etc.; structuri de control pentru a conferi limbajului completitudine de calcul (IF, FOR, WHILE, etc.) pentru a deveni un limbaj de sine stttor a crui putere de expresie s nu mai fie limitat la nivelul limbajelor relaionale; faciliti pentru exprimarea prelucrrilor recursive; faciliti de comunicare n reea; faciliti de prelucrare distribuit (mecanisme pentru crearea, memorarea i execuia procedurilor la nivelul serverelor de date stored procedures); faciliti multimedia; faciliti pentru tratarea timpului n bazele de date. Comenzi pentru crearea/actualizarea schemei bazei de date Crearea unui utilizator se realizeaz cu comanda CREATE USER <nume utilizator> IDENTIFIED BY <parola> Adugarea relaiilor ntr-o baz de date comanda CREATE TABLE are sintaxa: CREATE TABLE <nume relaie>[(<nume atribut> <tip dat>,)] Exemplu -crearea tabelei Persoane n SQL Oracle se realizeaz cu comanda: CREATE TABLE Persoane (Nrcrt NUMBER UNIQUE NOT NULL,Nume CHAR(15),Prenume CHAR(15),Datan DATE,Sexul CHAR,Adresa VARCHAR2(50)); O nou relaie poate fi creat i ca rezultat al unei operaii de interogare astfel: CREATE TABLE <nume relaie> (<nume atribut> <tip dat>,) AS <subinterogare> Adugarea/modificarea de atribute pentru o relaie existent se realizeaz cu comanda: ALTER TABLE <nume relaie> ADD|MODIFY (< nume atribut> <tip dat>,)

89

tergerea unei relaii se realizeaz cu comanda: DROP TABLE <nume relaie> Comenzi pentru optimizarea interogrilor Una din principalele ci de optimizare a timpilor de interogare a unei baze de date este indexarea. Un index poate fi privit ca o relaie cu dou atribute i anume: primul atribut conine valorile atributelor relaiei dup care se creaz indexul; al doilea atribut conine un pointer (adresa) la locaia tuplelor corespunztoare. Crearea unui index se realizeaz cu comanda: CREATE [UNIQUE] INDEX <nume index> ON <nume relaie>(<nume atribut>[ASC|DESC],) Dac pentru atributele utilizate n clauza WHERE a unor instruciuni SQL au fost creai indeci, atunci acetia vor fi utilizai n vederea optimizrii timpului de prelucrare. Decizia de utilizare sau nu a unui index este luat de limbajul SQL i nu de utilizator. Pentru aceasta fiecare model de limbaj SQL dispune de o component numit optimizator, care examineaz interogarea i decide care este modul optim de obinere a rezultatului. O alt tehnic de optimizare a interogrilor este tehnica clustering disponibil n ORACLE i care const n gruparea tuplelor din mai multe relaii i stocarea lor n aceeai zon pe disc. Controlul datelor (comenzi DCL) Vederi O vedere este o relaie virtual, definit plecnd de la alte relaii din baza de date i care nu conine date i deci nu ocup spaiu fizic pe disc. Vederile se definesc n dou scopuri i anume: pentru a simplifica accesul utilizatorilor la date; pentru a asigura protecia i securitatea datelor fiecrui utilizator fiindu-i permis acces la o poriune a bazei de date i putnd efectua doar anumite operaii (conform drepturilor de acces specificate cu comenzile GRANT/REVOKE). Asupra unei vederi se pot efectua aceleai operaii ca i asupra unei relaii cu deosebirea c vederile nu conin date i c orice modificri efectuate asupra datelor sunt reflectate i n vederi. Astfel, asupra unei vederi se pot realiza operaiile: creare vedere (CREATE VIEW); creare sinonim pentru vedere (CREATE SYNONIM); tergere vedere (DROP VIEW); interogare vedere (SELECT); actualizare date din vedere (UPDATE); tergere date din vedere (DELETE); adugare date (INSERT). Crearea unei vederi se realizeaz cu comanda CREATE VIEW care are sintaxa: CREATE VIEW <nume vedere> [<lista atribute>] AS <fraza SELECT> [WITH CHECK OPTION]

90

Exemplu: CREATE VIEW StocuriD1(Codp,Denp,Ump,Cant,Pret,Valoare) AS SELECT Stocuri.Codp, Denp,Ump,Cant,Pret,Cant*Pret FROM Produse,StocuriWHERE Produse.codp=Stocuri.Codp AND CodDep = D1 Interogarea vederii se va realiza cu comanda SELECT * FROM StocuriD1 Utilizarea opiunii WITH CHECK OPTION asigur faptul c nici o tupl nu va fi adaugat sau actualizat cu instruciunile INSERT, UPDATE, dac nu sunt respectate condiiile specificate n clauza WHERE a instruciunii SELECT din definiia vederii. Pentru acordarea sau retragerea drepturilor de acces la baza de date prin intermediul vizualizrilor se vor folosi comenzi de forma: GRANT [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere> TO <nume utilizator> sau REVOKE [ALL|SELECT|INSERT|UPDATE|DELETE] ON <nume vedere> FROM <nume utilizator> Asigurarea securitii datelor presupune definirea drepturilor de acces ale utilizatorilor i protecia sistemului la accesul neautorizat. n acest sens asigurarea securitii se realizeaz pe dou niveluri i anume: nivelul 1 acordarea dreptului de acces la sistem; nivelul 2 acordarea dreptului de acces la nivel de relaii. Pentru conectarea utilizatorilor la sistem n majoritatea versiunilor de SQL se utilizeaz un nume de utilizator i o parol. Referitor la drepturile de acces la nivel de relaie n sistemele multi-user trebuie precizat utilizatorul care a creat relaia (proprietarul relaiei). Fiecare utilizator are drepturi doar asupra propriilor relaii, iar drepturi asupra unor relaii create de ali utilizatori pot fi acordate prin comanda GRANT i pot fi retrase prin comanda REVOKE. Datele privind definirea bazei de date, utilizatorii i drepturile de acces sunt stocate n dicionarul de date i sunt gestionate de ctre sistemul de gestiune a bazei de date (SGBDR). n cele ce urmeaz se va prezenta modul de realizare a celor dou nivele de securitate n cadrul sistemului ORACLE. Nivelul 1 de securitate a datelor se realizeaz cu comanda: GRANT <autorizare,> TO <nume utilizator> [IDENTIFIED BY <parola>] unde <autorizare> poate fi: DBA confer utilizatorului dreptul de efectuare a oricrei operaii asupra oricrei relaii din baza de date; CONNECT confer utilizatorului dreptul de a a face interogri (SELECT) i actualizri (INSERT, UPDATE, DELETE) asupra relaiilor create de ali utilizatori, ns nu permite utilizatorului s creeze relaii (CREATE) sau s tearg relaii create de ali utilizatori (DROP);

91

RESOURCE confer utilizatorului drepturile ce rezult din autorizarea CONNECT i n plus dreptul de a crea relaii (CREATE) i de a terge relaii ce i aparin (DROP). Unui utilizator i pot fi acordate mai multe tipuri de autorizri n cadrul unei singure comenzi GRANT. Parola stabilit pentru un utilizator poate fi modificat printr-o comand GRANT ulterioar spre exemplu astfel: GRANT RESOURCE TO <nume utilizator> IDENTIFIED BY <noua parol> Unui utilizator cruia i s-a acordat un tip de autorizare i pot fi acordate i alte tipuri de autorizare prin comenzi GRANT ulterioare. Retragerea autorizrilor acordate unui utilizator se realizeaz cu comanda: REVOKE <autorizare,> FROM <nume utilizator> Nivelul 2 de securitate a datelor Pentru acordarea respectiv retragerea drepturilor de acces la relaii se utilizeaz comenzile GRANT respectiv REVOKE cu urmtoarea sintax: GRANT ALL|<drept de acces>, ON <nume relaie> TO <nume utilizator>|PUBLIC [WITH GRANT OPTION] respectiv REVOKE ALL|<drept de acces>, ON <nume relaie> FROM <nume utilizator>|PUBLIC Privilegiile (drepturile de acces) pot fi acordate sau retrase de urmtoarele categorii de utilizatori: utilizatorii cu nivel de autorizare DBA; proprietarii relaiilor; utilizatorii autorizai cu opiunea WITH GRANT OPTION. Prin specificarea PUBLIC acordarea respectiv retragerea drepturilor de acces se aplic tuturor utilizatorilor. Prin specificarea WITH GRANT OPTION, utilizatorul respectiv poate la rndul su s acorde aceleai drepturi sau mai puine altor utilizatori. n ORACLE pot fi acordate urmtoarele drepturi de access asupra relaiilor: SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele i indeci. Drepturile de acces pot fi acordate asupra ntregii relaii, sau doar asupra anumitor atribute ale relaiei. Exemple: Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra relaiei Persoane care aparine utilizatorului Vasilescu se realizeaz prin comanda: GRANT ALL ON Vasilescu.Persoane TO Ionescu,Popescu Acordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra relaiei Produse aparinnd utilizatorului Ionescu se realizeaz cu comanda: GRANT SELECT,INSERT,UPDATE ON Ionescu.Produse TO PUBLIC Acordarea privilegiilor SELECT,UPDATE numai asupra atributelor CodP, Denp din relaia Produse aparinnd utilizatorului Ionescu, utilizatorului Popescu cu condiia ca

92

acesta la rndul su s poat acorda oricrui alt utilizator aceleai drepturi sau mai puine, se realizeaz cu comanda: GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire) TO Popescu WITH GRANT OPTION Retragerea drepturilor de acces INSERT,DELETE asupra relaiei Persoane aparinnd utilizatorului Vasilescu, utilizatorului Ionescu se realizeaz cu comanda: REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM Ionescu Instruciuni pentru inserarea i actualizarea datelor n tabele Inserarea datelor comanda INSERT are urmtoarea sintax: INSERT INTO <nume relatie>|<nume vedere> [(<nume atribut>)] [VALUES] <lista valori>|<subinterogare> Exemple: Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa) INSERT INTO Persoane VALUES (1,Ionescu,Ion,05/23/82,M,Suceava) (adaug o nregistrare n tabela Persoane completnd toate atributele) INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,Ionescu,Ana) (adaug o nregistrare n Persoane completnd numai atributele Nrcrt,Nume, Prenume) Pentru a insera n tabela PersF(Nrcrt,Nume,Prenume) toate nregistrrile din tabela Persoane pentru care Sexul=F se scrie comanda: INSERT INTO PersF(Nrcrt,Nume,Prenume) SELECT Nrcrt,Nume,Prenume FROM Persoane WHERE Sexul = F Actualizarea datelor comanda UPDATE are sintaxa: UPDATE <nume relaie>|<nume vedere> SET <nume atribut> = <expresie>,[WHERE <condiie>] Condiia din clauza WHERE definete tuplele care vor face obiectul actualizrii. Clauza WHERE poate conine i o subinterogare. Exemple: UPDATE Persoane SET Nume = Popescu, Prenume = Ana Maria WHERE Nume = Ionescu AND Prenume = Ana (actualizeaz numele i prenumele persoanei Ionescu Ana cu valorile Popescu respectiv Ana Maria). UPDATE Vanzari SET Pret = Pret*1.2 WHERE CodP IN (SELECT CodP FROM Facturi WHERE Numar = 120 AND Vanzari.Codc=Facturi.Codc ) (realizeaz majorarea preului cu 20% pentru produsele vndute cu factura 120). Dac n comanda UPDATE clauza WHERE este omis, actualizarea se va efectua asupra tuturor tuplelor relaiei. tergerea datelor comanda DELETE are sintaxa: DELETE FROM <nume relaie>|<nume vedere> [WHERE <condiie>] unde <condiie> poate fi o condiie simpl, o expresie sau o subinterogare. Exemple: DELETE FROM Stocuri WHERE Cant = 0 (terge toate nregistrrile din tabela Stocuri pentru care cmpul Cant are valoarea 0).
93

DELETE Oferte (terge toate nregistrrile din tabela Oferte). Comenzi pentru gestiunea tranzaciilor Tranzacia este o succesiune de instruciuni SQL grupate ntr-un bloc de instruciuni utilizate pentru actualizarea i/sau interogarea datelor din baza de date. O tranzacie se consider ncheiat dup realizarea tuturor operaiilor pe care le conine. Operaiile coninute ntr-o tranzacie pot fi realizate efectiv n baza de date sau nu, fie automat de ctre sistem dup fiecare operaie, fie printr-o comand explicit dat dup o succesiune de operaii. Astfel salvarea automat de ctre sistem a modificrilor este realizat prin comanda SET AUTOCOMMIT ON Dac iniial a fost specificat comanda SET AUTOCOMMIT OFF, salvarea modificrilor efectuate asupra datelor se realizeaz prin comanda COMMIT, iar abandonarea modificrilor se realizeaz prin comanda ROLLBACK. Blocul de operaii ce definesc o tranzacie poate fi delimitat de instruciunile : BEGIN TRANSACTION END TRANSACTION Problem rezolvat Se lanseaz n execuie SQL Plus Oracle sub utilizatorul system (figura 5.1). n baza de date ORCL sub S.G.B.D. Oracle se creaz utilizatorul U1 identificat prin parola PW1 i i se acord privilegiile CONNECT, RESOURCE (figura 5.2). Se nchide sesiunea de lucru SQL Plus a utilizatorului system (cu instruciunea EXIT) i se deschide o nou sesiune de lucru SQL Plus pentru utilizatorul U1 (figura 5.3). Se creaz tabela Produse i se insereaz dou nregistrri (figura 5.4).

ORCL

94

Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system

Figura 5.2. Creare utilizator U1 i acordare privilegii CONNECT, RESOURCE

ORCL 95

Figura 5.3. Lansare SQL Plus ORACLE pentru utilizatorul U1

Limbajul SQL - Interogarea bazelor de date - Fraza SELECT Interogarea bazelor de date n limbajul SQL se realizeaz cu ajutorul unei singure instruciuni i anume instruciunea SELECT avnd urmtoarea sintax: SELECT [DISTINCT] <lista atribute>|* Figura 5.4. Creare tabel Produse i inserare dou nregistrri FROM <lista relaii> [WHERE <condiie>] [GROUP BY <lista atribute de grupare>] [HAVING <condiie>] [ORDER BY <atribut1 de ordonare> [ASC]|DESC,] [UNION <fraz SELECT>] <lista atribute> este o list ce conine nume de atribute (cmpuri) sau expresii construite utiliznd atribute, separate prin caracterul , i care fac parte din relaiile (tabele, vederi) enumerate n <lista relaii> din clauza FROM. Numele fiecrui atribut sau expresii din <lista atribute> va fi afiat n capul de tabel ce reprezint rezultatul interogrii, fiecare atribut sau expresie putnd primi un alias folosind specificarea AS <alias>. Caracterul * specific faptul c se extrag toate atributele tabelei precizate n clauza FROM. Clauza DISTINCT precizeaz faptul c n relaia rezultat nu pot aprea duplicate (tuple identice). Clauza WHERE precizeaz condiiile de interogare (condiii care trebuie s fie satisfcute de tuplele interogate, condiii de cuplare relaii (JOIN, relaii ntre tabele). n clauza WHERE pot fi utilizai operatori logici (AND, NOT, OR), predicate (IN, LIKE, BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a operaiilor, operatorilor, funcii i alte subinterogri SELECT, pentru construirea de expresii pe care trebuie s le ndeplineasc tuplele ce constituie rezultatul interogrii. Predicatul IN permite specificarea unei liste pentru domeniul de cutare pentru un atribut, iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de cutare a valorilor unui atribut, fiind echivalent cu o condiie de forma: <atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval>

96

Exemple: Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa) Selectarea tuturor nregistrrilor din tabela Persoane pentru care primele 7 caractere din cmpul Adresa sunt Suceava sau Rdui se realizeaz cu comanda: SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (Suceava,Rdui) Interogarea de mai sus este echivalent cu interogarea: SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) = Suceava OR SUBSTR(Adresa,1,7) = Rdui Selectarea tuturor nregistrrilor din tabela Persoane pentru care data naterii este cuprins ntre 01/01/72 i 01/01/82 se realizeaz astfel: SELECT * FROM Persoane WHERE Datan BETWEEN {01/01/72} AND {01/01/82} Interogarea de mai sus este echivalent cu interogarea: SELECT * FROM Persoane WHERE Datan >= {01/01/72} AND Datan <= {01/01/82} Predicatul LIKE permite selecia irurilor de caractere care conin anumite caractere specificate prin intermediul unei mti definite cu ajutorul unor caractere speciale (%, _ n dBASE IV, FoxPro, ORACLE, sau *, ? n INFORMIX) Exemple: SELECT * FROM Persoane WHERE Nume LIKE %a (selecteaz toate nregistrrile din tabela Persoane pentru care valorile atributului Nume se termin cu litera a). SELECT Nume,Prenume,Datan FROM Persoane WHERE Nume LIKE A%u (selecteaz valorile atributelor Nume, Prenume, Datan pentru toate nregistrrile din tabela Persoane pentru care prima liter din Nume este A iar ultima liter este u). SELECT Nume FROM Persoane WHERE Nume LIKE _o% (selecteaz valorile atributului Nume pentru toate nregistrrile din tabela Persoane pentru care prima liter din Nume este orice liter, a doua liter din Nume este litera o i ncepnd din poziia a treia numele poate conine orice litere.) Predicatele ALL, ANY, EXISTS se utilizeaz pentru interogri ce conin subinterogri, n vederea verificrii anumitor condiii ce trebuie ndeplinite ntre rezultatele interogrii i rezultatele subinterogrii. Clauza GROUP BY realizeaz gruparea tuplelor unei relaii pe baza valorilor unui atribut sau grup de atribute i genereaz o singur tupl pentru fiecare grup de tuple avnd aceeai valoare pentru atributele care definesc grupul. Atributele care definesc grupul trebuie obligatoriu s se regseasc n lista atributelor interogate <lista atribute>. De asemenea asupra unor atribute pot fi aplicate funcii agregat: AVG(<atribut>) media valorilor atributului specificat ca parametru, pe grup; SUM(<atribut>) suma valorilor atributului specificat ca parametru, pe grup; MAX(<atribut>) maximum valorilor atributului specificat ca parametru, pe grup; MIN(<atribut>) minimum valorilor atributului specificat ca parametru, pe grup; COUNT(<atribut>) numrul nregistrrilor pe grupare dup <atribut>.

97

Observaie. <atribut> poate fi fie un atribut, fie o expresie definit utiliznd atribute ale tabelei. Clauza HAVING, opiune a clauzei GROUP BY, este o form special a clauzei WHERE ntruct se aplic unor grupuri de tuple (i nu unor tuple) definite de clauza GROUP BY. Exemple: Fie tabela Stocuri(CodDep,CodP,UmP,Cant,Pret) SELECT CodDep,SUM(Cant*Pret) AS Valoare,COUNT(CodDep) AS Contor FROM Stocuri GROUP BY CodDep (Calculeaz suma produselor Cant*Pret pentru toate tuplele avnd aceeai valoare n cmpul CodDep i numrul nregistrrilor din fiecare grup definit de cmpul CodDep i afiseaz rezultatele sub form de tabel avnd coloanele CodDep, Valoare, Contor) SELECT CodDep,CodP,MAX(Pret) FROM Stocuri GROUP BY CodP HAVING MAX(Pret) < 150000 (selecteaz pentru fiecare grup de nregistrri avnd aceeai valoare n cmpul CodP, nregistrarea cu preul maxim mai mic dect 150000) Clauza ORDER BY permite precizarea ordinii de afiare a datelor astfel: ORDER BY <nume atribut 1> [ASC]|DESC,<nume atribut 2>[ASC]|DESC, Exemplu: SELECT * FROM Persoane ORDER BY Datan DESC,Nume (afieaz toate nregistrrile din tabela Persoane n ordine descresctoare dup data naterii i n cadrul aceleiai date a naterii cresctor dup Nume) Clauza UNION permite obinerea rezultatului a dou sau mai multe interogri printr-o singur instruciune SELECT. Exemplu: SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE CodDep = Dep01 UNION SELECT CodDep,CodP,Cant FROM Stoc_Prod WHERE Cant >= 100 (selecteaz tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate nregistrrile pentru care CodDep = Dep01, la care adaug tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate nregistrrile pentru care Cant >= 100). Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL. Pentru a schimba ordinea de afiare a tuplelor extrase se poate utiliza clauza ORDER BY aplicat doar relaiei finale i nu asupra fiecrei fraze SELECT. Regsirea datelor din dou sau mai multe relaii Interogarea datelor din dou sau mai multe tabele (relaii) presupune existena unor cmpuri comune pentru realizarea operaiei de cuplare (operatorul JOIN). n fraza SELECT operaia de cuplare este definit n clauza WHERE sub forma: <nume tabela1>.<cheie1> = <nume tabela2>.<cheie2> (unde <cheie1>, <cheie2> reprezint cmpurile ce identific nregistrrile corespondente n cele dou tabele).

98

Pentru exemplificare pe lng tabela Stocuri mai considerm tabela Produse(CodP, DenP, DesP). SELECT Produse.CodP,DenP,UmP,Cant,Pret FROM Produse,Stocuri WHERE Produse.CodP = Stocuri.CodP (extrage toate tuplele (CodP,DenP,UmP,Cant,Pret) pentru care valoarea atributului CodP din tabela Produse este egal cu valoarea atributului CodP din tabela Stocuri ). n lipsa clauzei WHERE se vor extrage toate combinaiile posibile ntre tuplele celor dou tabele (produsul cartezian). Fiecrei tabele i se poate atribui un alias astfel nct fraza de mai sus este echivalent cu fraza: SELECT A.CodP,DenP,UmP,Cant,Pret FROM Produse A,Stocuri B WHERE A.CodP = B.CodP n anumite situaii poate fi necesar corelarea (cuplarea) unei relaii (tabele) cu ea nsi. Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm urmtoarea interogare: SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP) Pentru rezolvarea unor astfel de probleme s-au utilizat instruciuni SELECT imbricate care vor fi prezentate n detaliu n cele ce urmeaz. Instruciuni SELECT imbricate Limbajul SQL ofer posibilitatea construirii unor interogri complexe prin includerea n clauza WHERE a unei instruciuni SELECT, a altei instruciuni SELECT (numit sub-interogare sau inner) astfel: SELECT <lista atribute> FROM <lista relaii> WHERE <condiie> (<sub-interogare>) La rndul ei sub-interogarea poate conine n clauza WHERE o alt instruciune SELECT obinnd astfel o interogare complex constituit din instruciuni SELECT imbricate pe un numr oarecare de nivele. Instruciunea SELECT interioar genereaz valori pentru condiia de cutare a instruciunii SELECT exterioare care o conine (numit i outer). O sub-interogare poate returna o singur valoare, sau poate returna mai multe valori. n ce privete ordinea de evaluare a interogrilor pot exista : sub-interogri simple - n care interogarea interioar este evaluat prima, independent de interogarea exterioar, iar rezultatul interogrii interioare este utilizat de interogarea exterioar; sub-interogri corelate - n care interogarea exterioar transmite repetat cte o valoare pentru interogarea interioar, care n baza valorii primite, parcurge tuplele relaiei i transmite interogrii exterioare rezultatul obinut. Astfel de interogri realizeaz corelarea unei relaii cu ea nsi i sunt cele mai performante.

99

Spre exemplu dac presupunem c n tabela Stocuri unele produse pot apare de mai multe ori cu preuri diferite i ne intereseaz poziiile cu preul minim, formulm urmtoarea interogare: SELECT A.CodP,A.Cant,A.Pret FROM Stocuri A WHERE A.Pret = (SELECT MIN(B.Pret) FROM Stocuri B WHERE A.CodP = B.CodP) Sub-interogri simple care returneaz o singur valoare - pot fi utilizate n interogri imbricate avnd sintaxa: SELECT <lista atribute> FROM <lista relaii> WHERE <atribut> = < > <= >= != (<sub-interogare>) [ORDER BY <atribut[ASC]|DESC,] Exemplu: SELECT CodDep,CodP,Cant FROM Stocuri WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep (afieaz produsele pentru care exist stocuri peste medie, ordonate pe depozite). Sub-interogari simple care returneaza mai multe valori pot fi utilizate n interogri imbricate care utilizeaz n clauza WHERE condiii care genereaz o mulime de valori folosind unul din predicatele: (NOT)IN, (NOT)ANY, (NOT)ALL, (NOT)EXISTS. Exemplu: SELECT * FROM Produse WHERE CodP IN (SELECT CodP FROM Facturi WHERE Numar IN (SELECT Numar FROM Beneficiari,Comenzi WHERE Beneficiari.Nume=Ionescu AND Beneficiari.Cod_B=Comenzi.Cod_B)) Predicatul ANY poate fi utilizat n combinaie cu oricare din operatorii <, >, =, <=, >=, != i permite verificarea dac valoarea unui atribut satisface condiia precizat pentru orice valoare din lista rezultat din subinterogare. SELECT CodP FROM Stocuri WHERE Cant > ANY (SELECT Cant FROM Stocuri WHERE CodDep = D1) Predicatul ALL returneaz toate tuplele pentru care valorile atributului din clauza WHERE sunt <, >, <=, >= dect toate valorile generate de interogarea interioar (acest predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal n care toate interogrile din list sunt egale). Exemplu: SELECT * FROM Stocuri WHERE Cant < ALL (SELECT Cant FROM Stocuri WHERE CodDep = D1) Predicatul EXISTS verific dac pentru fiecare tupl a relaiei exist tuple care satisfac condiia din interogarea interioar (deci EXISTS permite specificarea mai multor atribute n interogarea interioar). Astfel spre exemplu instruciunea:
100

SELECT * FROM Produse A WHERE NOT EXISTS (SELECT * FROM Stocuri B WHERE B.CodP=A.CodP) va returna o list de produse care nu au nici o nregistrare n Stocuri. Aplicaie practic Se consider baza de date Furnizori_Clieni_Stocuri care conine urmtoarele tabele (n ACCESS): PRODUSE (catalog de produse) Cmp Semnificaie Tip dat Dimensiune Observaii Codp Cod produs Number, Integer 4 Cheie primar Denp Denumire produs Text 20 Desp Descriere produs Hyperlink Refer document corespunztor STOCURI (stocurile de produse pe depozite) Cmp Semnificaie Tip dat Codp Cod produs Number, Integer Lookup Wizard CodDep Cod depozit Text Ump Unitate de Lookup Wizard msur produs Cant Cantitate Number, Integer Pret Pre unitar Number, LongInteger FURNIZORI (catalog de furnizori) Cmp Semnificaie Tip dat Codf Cod furnizor Number, Integer Denf Denumire Text furnizor Adresaf Adresa furnizor Text CLIENTI (catalog de clieni) Cmp Semnificaie Codc Cod client Denc Denumire client Adresac Adresa client Tip dat Number, Integer Text Text Dimensiune Observaii 4 Lookup Wizard cu tabela PRODUSE 2 8 Creare i utilizare list de valori 4 8

Dimensiune Observaii 4 Cheie primar 30 25 Dimensiune Observaii 4 Cheie primar 30 25 Dimensiune Observaii 4 Lookup Wizard cu tabela FURNIZORI 4 Lookup Wizard cu

OFERTE (oferte de produse de la furnizori) Cmp Semnificaie Tip dat Codf Cod furnizor Number, Integer Lookup Wizard Codp Cod produs Number, Integer

101

Ump Pret Datao Oferta

Unitate de msur produs Pre unitar Data ofertei Oferta furnizor

Lookup Wizard Lookup Wizard Number, LongInteger Date Hyperlink

8 8 8

tabela PRODUSE Creare i utilizare list de valori

Refer document corespunztor Dimensiune Observaii 4 Lookup Wizard cu tabela CLIENTI 4 Lookup Wizard cu tabela PRODU,03SE 8 Creare i utilizare list de valori 4 8

VANZARI (vnzrile de produse pe clieni) Cmp Semnificaie Tip dat Codc Cod furnizor Number, Integer Lookup Wizard Codp Cod produs Number, Integer Lookup Wizard Ump Cant Pret Unitate de msur produs Cantitate Pre unitar Lookup Wizard Number, Integer Number, LongInteger

S se scrie comenzile SQL pentru realizarea interogrilor de mai jos: a) Situaia stocurilor Cmp CodDep Codp Denp Ump Cant Pret Valoare Tabela Stocuri Stocuri Produse Stocuri Stocuri Stocuri Cant*Pret b) Situaia ofertelor Cmp Tabel a Codf Denf Adresaf Codp Denp Ump Furnizori Furnizori Furnizori Produse Produse Oferte Pret Oferte Datao Oferte

c) Situaia vnzrilor
Cmp Tabel a Codc Clienti Denc Clienti Adresac Clienti Codp Produse Denp Produse Ump Vanzar i Cant Vanzar i Pret Vanzar i Valoare Cant*Pret Datav Vanzari

d) Lista produselor pentru care nu exist oferte Cmp Tabel a Codp Denp Produse Produse

102

Lista produselor pentru care nu s-au fcut vnzri n perioada [Data1,Data2] Cmp Codp Denp Tabela Produse Produse Rspuns: a) SELECT CodDep, Stocuri.Codp, Denp, Ump, Cant, Pret, Cant*Pret AS Valoare FROM Stocuri, Produse WHERE Stocuri.Codp = Produse.Codp b) SELECT Oferte.Codf, Denf, Adresaf, Oferte.Codp, Denp, Ump, Pret, Datao FROM Oferte, Produse,Furnizori WHERE Oferte.Codp = Produse.Codp AND Oferte.Codf = Furizori.Codf c) SELECT Vanzari.Codc, Denc, Adresac, Vanzari.Codp, Denp, Ump,Cant, Pret, Cant*Pret AS Valoare, Datav FROM Vanzari, Produse,Clienti WHERE Vanzari.Codp = Produse.Codp AND Vanzari.Codc = Clienti.Codc d) SELECT * FROM Produse WHERE NOT EXISTS (SELECT * FROM Oferte WHERE Produse.Codp=Oferte.Codp) e) SELECT * FROM Produse WHERE NOT EXISTS (SELECT * FROM Vanzari WHERE Produse.Codp=Vanzari.Codp AND Datav BETWEEN Data1 AND Data2) 5.2. Proiectarea programelor i a procedurilor Proiectantul de soft are ca principal misiune definirea i structurarea componentelor care vor forma un tot unitar, astfel nct prin acestea s se obin un proiect soft operaional. Proiectantul va grupa funciile ce trebuie s fie interconectate i va descrie modalitile de realizare a legturilor. Dup proiectanii de soft vor interveni programatorii, pentru transpunerea n realitate a proiectului. Ei vor controla intrrile, prelucrrile i ieirile din sistem prin intermediul programelor. Softul are dou componente de baz instruciunile i modulele. Instruciunile sunt operaiuni elementare executate de calculator prin gruparea i selecia controlat a acestora pentru atingerea obiectivelor funciilor de prelucrare orientate pe probleme. Instruciunile constituie cel mai jos nivel al operaiunilor ce pot fi executate de ctre un limbaj de programare. Blocurile de instruciuni sunt astfel grupate nct s constituie anumite structuri executabile de calculator. De modul n care sunt grupate instruciunile pentru a da natere unor structuri standard ale programelor, de relaiile dintre instruciuni, de aranjamentul acestora depinde calitatea softului proiectat. Modulul este o colecie sau o form grupat de instruciuni de programe surs. Modulele se pot grupa pentru a forma programele.

103

Programul, n concepia diverilor autori, are semnificaii diferite. El este definit ca: un set de instruciuni cu ajutorul crora se efectueaz prelucrri specifice; o entitate ce poate fi executat pe calculator; un mijloc de comunicare cu calculatorul pentru rezolvarea unor probleme; o descriere a unui algoritm i a datelor asociate n vederea execuiei pe calculator, deci o reprezentare a acestora (algoritmi i date) innd cont de restriciile impuse de calculator; o realizare a unei funcii f care, dat fiind o mulime de date x, specific valoarea y=f(x); Prin algoritm se nelege o metod de soluionare a unei clase de probleme, reprezentat de o succesiune finit de operaii bine definite, numite instruciuni. Prin prisma complexitii lor programele se pot clasifica n [46]: programe simple (1000 de linii) programe de complexitate medie(10 000 de linii) programe complexe (peste 100 000 de linii) au numeroase module cu legturi complexe. Pentru ca programele s fie caracterizate prin eficien, fiabilitate, flexibilitate, inteligibilitate, n procesul elaborrii lor trebuie s se respecte anumite principii [46]: principiul conformrii, potrivit cruia programele trebuie s fie elaborate n conformitate cu cerinele utilizatorului; principiul completitudinii const n realizarea descrierilor complete ale obiectivelor programului pe toate nivelurile ierarhice de descompunere; principiul abstractizrii se refer la elaborarea funciei programului, innd cont de elementele eseniale, fcndu-se abstracie de detaliile nesemnificative; principiul modularizrii const n descompunerea programelor n subdiviziuni logice (module), care vor fi analizate n procesul de concepere i elaborare a programelor. n timp s-au conturat mai multe metode sau tehnici de programare prezentate sumar n cele ce urmeaz.. Metoda programrii clasice are la baz construirea monolitic a logicii programului, fr intenii de structurare. Programul este privit n totalitatea lui i analizat direct la nivelul operaiilor elementare pe care le implic executarea lucrrii care se elaboreaz . Programarea modular const n descompunerea programului, chiar din faza de proiectare, n module uor de ntrebuinat. Fiecare modul este apoi analizat ca un program distinct i rezolvat ca atare [46]. Metoda programrii structurate const n faptul c ofer o rezolvare standardizat i structurat, n mod unitar, a programelor, reprezentnd o ridicare a activitii de programare la nivelul activitii industriale, fundamentat pe o metodologie tiinific. Programarea structurat este caracteristic dezvoltrii sistemelor pe baza diagramelor
104

fluxului de date i utilizeaz limbaje structurate. Ea presupune o separare ntre structurile de date i codul funciilor care le prelucreaz. Metoda programrii orientate-obiect - const n abordarea natural a lumii reale, folosind componente modularizate i eliminnd restriciile impuse de mediul de programare. Se definesc concepte noi de tip, clas, motenire, etc [Udric M., 2000]. 5.2.1. Atributele modulelor La nivelul softului proiectat, componenta de baz este modulul. El este o colecie sau o form grupat de instruciuni ale programului surs. La rndul lor, modulele se pot grupa pentru a forma programe. Modulele programelor au urmtoarele caracteristici [46]: Un modul este format dintr-un grup de instruciuni care sunt contigue din punct de vedere fizic i sunt executate ca o unitate distinct; Grupurile de instruciuni care formeaz un modul au nceputuri i sfrituri bine definite; n majoritatea cazurilor, grupul de instruciuni are doar un punct de intrare i unul de ieire; Un modul poate fi un program sau un subprogram distinct compilat sau o procedur intern a unui program. Un modul are trei componente de baz: funcia, logica i interfeele. Funcia unui modul const n transformarea datelor prin procesul de execuie a acestuia. Funcia este tratat n regimul cutiilor negre, ea fiind vzut la nivel de modul doar prin ceea ce se percepe n exteriorul lui, nu privindu-i componentele interne sau, altfel spus, rolul acestora. Interes prezint doar intrrile i ieirile modulului respectiv [46]. La nivelul softului, referirea la un modul este n acelai timp o referire la funcia lui. La nivelul cel mai de sus, modulele au funcii orientate spre problema de rezolvat, n timp ce modulele aflate pe nivelurile mai de jos au funcii orientate spre prelucrrile pe care le realizeaz. n diagrama de structur, folosit pentru reprezentarea grafic a proiectelor soft, un modul este reprezentat printr-o caset (dreptunghi) ce poart denumirea funciei ndeplinite. La atribuirea numelui unui modul trebuie s se in cont de faptul c acesta trebuie s surprind att funcia proprie, ct i pe cele ale subcomponentelor de ordin inferior. Se recomand [46] evitarea conjunciilor din structura numelor, deoarece ele ar sugera necesitatea folosirii mai multor module. Logica modulului descrie prelucrrile care au loc n interiorul acestuia [46]. La nivelul programrii, preocuparea este, n esen, legat de logica modulului, algoritmii de prelucrare, redai sub diverse forme scheme logice, pseudocod, tabele de decizie, arbori de decizie sau combinaii ale acestora sunt concepui pentru prezentarea modului de transformare a intrrilor n ieiri. Paii algoritmilor se vor transforma n instruciuni ale limbajelor de programare.

105

Interfeele sunt conexiuni sau cuplaje ntre module. Interfeele modulelor sunt utilizate pentru stabilirea cilor prin care s se transfere controlul de la un modul la altul [46]. Conexiunile dintre module se nregistreaz pe dou planuri: al transferrii controlului de la un modul la altul; al transmiterii datelor de la un modul la altul. n concluzie, se poate spune c eficiena proiectelor soft depinde n mare msur de eficiena cu care se transfer controlul ntre module, precum i de metoda folosit pentru transmiterea datelor ntre module. 5.2.2. Structurile de control ale programelor Proiectul soft trebuie s fie vzut [46] din dou puncte de vedere: logic i fizic. Din punct de vedere logic, modalitatea n care intr n funciune modulele este redat prin structura ierarhic a lor. Din punct de vedere fizic, dup ce s-a stabilit structura logic, se va pune problema adaptrii prelucrrii lor pe calculator, moment n care se va avea n vedere structura execuiei instruciunilor, adic a secvenelor dup care se declaneaz operaiunile din interiorul modulelor. Structurile de control al logicii cunoscute i sub numele de structuri de control fundamentale, reprezint un set minim, dar i necesar, de reguli prin care s se controleze procesul de activare a componentelor de prelucrare dintr-un program sau ntre modulele acestuia. Structurile sunt: secvena, selecia, iteraia sau repetiia. Ele mai sunt cunoscute i sub numele de structur secvenial, structur alternativ (simpl i generalizat i structur repetitiv (condiionat anterior sau la nceput i condiionat posterior sau la sfrit ). Secvena asigur parcurgerea instruciunilor n ordinea n care apar. Selecia definete alegerea unui grup de instruciuni din dou sau mai multe posibile. Iteraia ofer posibilitatea execuiei repetate a unui grup de instruciuni. n elaborarea programelor structurate este necesar s se respecte o serie de restricii, i anume [46]: fiecare element (secvena, selecia, iteraia) are un punct de intrare; fiecare element are un punct de ieire unic; elementul de iteraie permite i o execuie cu factor de repetiie zero, adic excluderea elementului respectiv din execuie. Fiecare element din cele enunate (secvena, selecia, iteraia) care respect restriciile de mai sus definete un bloc standard i sunt reprezentate n continuare [46]. Structura secvenial (liniar) se prezint astfel:

106

Figura 5.5. Structura secvenial Selecia (structura de tip IF-THEN-ELSE) sau structura alternativ are urmtoarea form de prezentare:

Figura 5.6. Structura alternativ Dac se ndeplinete condiia C, se execut operaiile din Bloc-1, altfel se execut operaiile din Bloc-2. Dup execuia blocului, se continu cu instruciunea urmtoare. Structura alternativ generalizat (de tip CASE-OF) este o generalizare a seleciei. Ea permite alegerea unei variante din mai multe posibile (figura 5.7).

107

Bloc - 1

Bloc - 2

Bloc - n

Figura 5.7. Structura alternativ generalizat Iteraia sau structura repetitiv definete execuia repetat a unei operaii sau grup de operaii, funcie de rezultatul evalurii unei condiii. Evaluarea condiiei se face fie nainte, fie dup executarea operaiilor. Structura repetitiv condiionat anterior (de tip WHILE-DO) este reprezentat n figura 5.8

Bloc - 1

Structura repetitiv condiionat posterior C tip DO UNTIL) are forma din figura 5.9. (de
DA NU

Figura 5.8. Structura repetitiv1condiionat anterior Bloc -

C NU 108

DA

Figura 5.9. Structura condiionat posterior

O form particular de structur repetitiv condiionat posterior este structura repetitiv cu numr definit de pai (de tip DO FOR). Numrul de repetiii este controlat de o variabil, numit variabil de control. n reprezentarea grafic urmtoare, V este variabila de control, Vi este valoarea iniial a variabilei de control, iar R este raia (incrementul). O astfel de structur este redat n figura 5.10.

V=Vi

Bloc - 1

V=Vi+R

V>Vf DA

NU

Figura 5.10. Structura repetitiv cu numr definit de pai n literatura de specialitate, se consider c structura secvenial, structura alternativ de tip IF-THEN-ELSE i structura repetitiv condiionat anterior sunt suficiente pentru a defini structura de control a oricrui program. Din acest motiv, cele trei structuri de control, enumerate mai sus, sunt numite structuri de control fundamentale sau structuri de baz.

109

5.2.3. Proiectarea i realizarea programelor Ideea de baz n proiectarea programelor const n faptul c acesta trebuie s respecte ntocmai structurile diagramelor fluxurilor de date, prin nivelurile arhitecturale de tip program. Pentru proiectarea programelor, programatorii vor respecta sistemul de cerine i restricii impus de etapele parcurse anterior pentru realizarea sistemului informatic. Urmnd principiile programrii structurate, realizarea programelor se face n urmtoarele faze [11]: definirea problemei de programat; descompunerea problemei de programat; realizarea modular a produselor program; testarea top-down a produselor program; definirea programului testat i a documentaiei aferente; dezvoltarea versiunii calitative a produsului program. Specificaiile elaborate n etapele precedente permit definirea problemei de programat prin care se formuleaz elementele specifice i se analizeaz relaiile dintre aceste elemente, din punct de vedere dinamic sau static. Descompunerea aplicaiei se poate face dup criteriul funcionalitii, motiv pentru care elementele rezultate se mai numesc i module funcionale. Din punct de vedere al fluxului datelor pot fi [11]: module de intrare, care manipuleaz datele de intrare; modulele de ieire, care furnizeaz rezultate ale prelucrrilor; module de prelucrare, care efectueaz diverse operaii asupra datelor. Pe baza unor funciuni identificate sau a altor raiuni de programare, modulele pot fi divizate n continuare. Scopul acestei structurri funcionale pn la nivel elementar este de a identifica funciunile sistemului i de a le separa, eventual, n funciuni generale i cu caracter specific aplicaiei. Modulele funcionale pot fi descompuse apoi dup criteriul omogenitii, rezultnd modulele operaionale. Realizarea modular a produselor program presupune urmtoarele aciuni [11]: Examinarea modulelor i specificarea succesiunii operaiilor de prelucrare descrise n acestea. Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere ntreaga cazuistic a sistemului informaional i s testeze toate ramurile programului. Precizarea elementelor de comunicaie ntre module, respectiv stabilirea parametrilor de intrare/iesire n/din fiecare modul. elaborarea algoritmii de prelucrare specifici fiecrui modul i structura programelor. transcrierea algoritmilor ntr-un limbaj de programare. scrierea codului surs i obinerea fiierelor executabile. Prin compararea rezultatelor propuse a fi obinute cu cele efectiv furnizate de aplicaia informatic, sunt verificate sintactic i funcional module din program. Dac se realizeaz identitatea ntre cele doua categorii de rezultate, operaia de testare se consider ncheiat.

110

O atenie deosebit trebuie acordat ntocmirii documentaiei programului cu observaia c n acest sens este recomandat autodocumentarea la nivel de modul. 5.3. Proiectarea sistemelor distribuite Un sistem de prelucrare distribuit a datelor presupune existena a dou sau mai multor sisteme independente de prelucrare a datelor, numire noduri, interconectate ntr-o configuraie de reea. Ele folosesc faciliti de comunicare pentru schimbul de informaii i i coordoneaz activitile pentru realizarea unui anumit scop. Un sistem de prelucrare distribuit a datelor permite realizarea activitii de prelucrare automat a datelor n cadrul unei reele de calculatoare. ntr-un astfel de mediu, coopereaz trei componente tehnologice distincte: prelucrarea datelor, comunicarea datelor i reeaua de calculatoare. Scopul lor este de a colabora fiecare cu fiecare, astfel nct s se realizeze obiectivele comune ale organizaiei [46].
Legtur/canal NOD NOD

Figura 5.11. Model de baz al unui sistem de prelucrare distribuit a datelor. Sistemele de prelucrare distribuit a datelor trebuie s permit: posibilitatea de prelucrare independent; o configuraie de reea; o posibilitate de transfer a datelor folosind faciliti de partajare a datelor; un obiectiv comun de realizat. La proiectarea unui sistem nou trebuie s se defineasc clar obiectivele pe care trebuie s le ndeplineasc noul sistem. Aceste obiective pot fi clasificate n financiare i funcionale. Din punct de vedere financiar se urmrete maxim de profit cu minimum de cheltuieli, iar din punct de vedere funcional se urmrete realizarea unui sistem performant. Costul sistemului se regsete n costurile iniiale pe procesoare, periferice (imprimant, scanner, etc), cablri, soft-uri, i costuri funcionale (operaionale) cu distribuirea datelor, cu personalul, ntreinerea sistemului, etc. Performana sistemului este apreciat prin prisma productivitii i a eficienei lui. Ea se determin n funcie de cerinele operaionale ale unui sistem de calcul. Se consider c performana este o funcie a [46]: timpului de rspuns(intervalul de timp dintre momentul formulrii unei cereri de la un terminal de comunicaie-date i obinerea rspunsului n acelai loc); randamentului(cantitatea de date ce poate fi prelucrat de ctre un sistem de calcul ntr-o perioad de timp); calitii serviciilor oferite utilizatorilor(siguran, fidelitate, integrare, control i acceptabilitate);

111

nivelul serviciilor. Sistemul propus trebuie s fie fezabil, din punct de vedere tehnic, i eficient, prin prisma costurilor prelucrrii automate a datelor i a comunicaiilor din sistem. Performanele sistemului sunt influenate de mai muli factori, cum ar fi timpul de rspuns, randamentul, disponibilitatea, sigurana(securitatea sistemului). La proiectarea sistemelor distribuite trebuie avute n vedere dou componente majore: Proiectarea nodurilor; Proiectarea reelei de comunicaii. Ordinea de proiectare nu este strict rmnnd la latitudinea echipei de proiectare.

Figura 5.12. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor Modele de sisteme distribuite Calculatoarele personale i staiile de lucru pot fi utilizate fie ca sisteme de-sinestttoare pentru execuia diferitelor aplicaii informatice, fie ntr-o configuraie de reea. O reea local se bazeaz pe un set de calculatoare personale, fiecare cu propria memorie, astfel nct s poat folosi n comun toate echipamentele i software-ul din reea. Dintre toate calculatoarele, exist unul sau unele mai puternice pe care se vor afla aplicaii folosite n comun de celelalte calculatoare ale reelei. Cea mai utilizat arhitectur este arhitectura client/server. Arhitectura client/server Modelul Client /Server ofer date distribuite, portabilitate ntre platforme i un acces standardizat la resurse. Termenul de Client /Server provine de la metoda tradiional de accesare a unui computer central numit server de ctre computere aflate la distan sau clieni ntr-o infrastructur de reea. Modelul Client /Server implic o entitate software (clientul) care efectueaz cereri, acestea fiind ndeplinite de o alt entitate software(serverul) . Clientul este cel care

112

transmite o cerere severului, acesta o interpreteaz i apoi o efectueaz. Pentru a putea ndeplini cererea, serverul poate referi o surs de informaie (baze de date), s efectueze procesri asupra datelor, s controleze periferice sau s efectueze cereri adiionale altor servere. Un client poate face cereri la multiple servere i un server poate deservi mai muli clieni. Cerere Surs de informaie (Baz de date) Procesare (Logic i Aritmetic) Server Dispozitive (Imprimant, Servicii(Cereri adiionale altor

Client periferice partajate) Rezultatul servere) ndeplinirii cererii

Figura 5.13. O tranzacie Client /Server. Se poate afirma c tehnologia client / server mparte o aplicaie n trei componente de baz: un client, un server i o reea care conecteaz clientul la server. Att clientul ct i serverul sunt calculatoare cu grade variate de putere de calcul, ce colaboreaz la ndeplinirea sarcinilor. Calculatorul server este responsabil cu administrarea accesului la baza de date, precum i cu alte sarcini care-i revin direct serverului. Cnd se alege un server pentru mediul de lucru client / server trebuie avute n vedere: scalabilitatea posibilitatea de cretere a capacitii serverului, n limite rezonabile; tolerana la erori posibilitatea de recuperare a contextului calculatorului server dup producerea unei disfuncionaliti hardware; service i asisten tehnic. Calculatoarele server au utilizri variate n sistemele client / server (exist servere de fiiere care asigur spaiul de disc centralizat care poate fi folosit conform necesitilor calculatoarelor client din reea; servere de tiprire care colecteaz informaiile ce urmeaz a fi trimise ctre imprimant de ctre calculatoarele client i le asigur tiprirea ntr-o anumit ordine; servere de baze de date calculatoare care ruleaz un sistem de gestiune a bazelor de date (DBMS), bazat pe SQL; serverele de aplicaii calculatoare server care ruleaz programe de aplicaii). Sistemele client-server au aprut ca urmare a descentralizrii activitii din diverse domenii, ceea ce presupune o repartizare a realizrii sarcinilor pe cele dou nivele: client, server. De obicei clienii reprezint utilizatorii finali care vor comunica cu serverul bazei de date n cadrul unei reele de calculatoare. Dup rolul pe care l are fiecare din componentele client, server, se pot distinge trei arhitecturi de baz pentru un sistem client-server (Loomis 1992) i anume: arhitectura de tip server de obiecte n care se distribuie prelucrarea ntre cele dou componente (server, client). Serverul este responsabil de administrarea memoriei i zvoarelor, efectuarea operaiilor n memoria secundar, securitatea, integritatea i recuperarea bazei de date, executarea procedurilor

113

stocate i optimizarea interogrilor. Clientul este responsabil de administrarea tranzaciilor i realizarea interfeei cu limbajul de programare; arhitectura de tip server de pagini cea mai mare parte a prelucrrilor este realizat de ctre client. Serverul este responsabil de memoria secundar i furnizeaz paginile corespunztor cererilor formulate de client; arhitectura de tip server de baz de date cea mai mare parte din prelucrrile bazei de date este efectuat de ctre server. Clientul transmite cererea serverului, primete rezultatele i le transmite aplicaiei. Este modul utilizat frecvent de ctre sistemele relaionale. n fiecare dintre cele trei cazuri serverul se gsete pe aceeai main ca i baza de date fizic. Clientul se poate afla pe aceeai main sau pe una diferit. n cazul bazelor de date distribuite pe mai multe maini, clientul va comunica cu cte un server de pe fiecare main. De asemenea mai muli clieni pot comunica concomitent cu acelai server (accesul concurent). Arhitectura tradiional a sistemelor client-server este o arhitectur pe dou nivele (etaje), n care la primul nivel (clientul) se realizeaz interfaa cu utilizatorul i logica principal a aplicaiei, iar la al doilea nivel (serverul) se realizeaz validarea datelor i accesul la baza de date. Necesitatea rezolvrii unor probleme complexe care presupun accesul la baza de date a unui numr mare de utilizatori, utilizarea unor platforme hardsoft diferite, precum i integrarea bazelor de date n mediul Web, au impus definirea unei noi arhitecturi client-server n care sunt definite trei nivele i anume: nivelul client, la care se realizeaz interfaa cu utilizatorul aplicaiei; nivelul server de aplicaie, la care se realizeaz logica aplicaiei i prelucrrii datelor; nivelul server de baze de date, la care se realizeaz validarea datelor i accesul la baza de date. Un server de aplicaie poate servi mai muli clieni, fiind conectat fizic att la nivelul client ct i la nivelul server de baze de date. Spre exemplu n mediul Web, clientul poate fi un browser Web, iar serverul de aplicaie poate fi un server Web. Teste rezolvate 1. Proiectarea fizic a sistemelor informatice nseamn: a) o abordare detaliat a sistemului; b) o abordare de ansamblu a sistemului; c) o abordare general a sistemului; Rspuns : a 2. Proiectarea fizic a sistemelor informatice implic: a) proiectarea fizic a bazelor de date i a fiierelor. b) proiectarea structurii sistemului i a programelor. c) proiectarea documentaiei sistemului analizat. d) proiectarea strategiilor de prelucrare distribuit. Rspuns : a, b, d
114

3. Proiectarea fizic a bazelor de date i a fiierelor i propune s asigure: a) trecerea de la descrierea logic a datelor la una tehnic, de stocare a datelor; b) structura global de organizare a datelor; c) descrierea logic a datelor. Rspuns : a 4. Sunt structuri de control fundamentale n realizarea programelor: a) structura secvenial; b) structur funcional; c) structura alternativ; d) structura organizaional: e) structura repetitiv. Rspuns : a, c, e 5. Structura repetitiv de baz condiionat anterior este: a) de tip WHILE-DO; b) de tip DO UNTIL; c) de tip DO FOR. Rspuns : a 6. Nu sunt metode de programare: a) metoda programrii clasice; b) metoda programrii structurate; c) metoda programrii orientate-obiect; d) metoda programrii iterative. Rspuns : d 7. Un modul are componente de baz: a) funcia; b) schema; c) logica; d) interfeele. Rspuns : a, c, d 8. Funcia unui modul const n: a) transformarea datelor prin procesul de execuie a acestuia. b) descrierea prelucrrilor care au loc n interiorul acestuia. c) legtura cu alte module. Rspuns : a 9. Realizarea modular a programelor corespunde principiilor: a) programrii clasice; b) programrii structurate; c) bazelor de cunotine; Rspuns : b 10. Principalele module de proiectare a sistemelor de prelucrare distribuit a datelor sunt: a) proiectarea nodurilor; b) proiectarea diagramelor; c) proiectarea reelei de comunicaii.
115

Rspuns : a, c 11. Nu sunt componente de baz ale tehnologiei client/server: a) clientul; b) administratorul de sistem; c) serverul; d) reeaua care conecteaz clientul la server. Rspuns : b 12. Care dintre urmtoarele instruciuni nu sunt decizionale ? a) WHILE ... WEND ; b) IF...END IF; c) IF...ELSE...END IF; d) IF...THEN...ELSE IF... ... ...END IF ; e) SELECT CASE...CASE... ... ...END SELECT. Rspuns : a 13. Care dintre urmtoarele instruciuni repetitive sunt condiionate posterior ? a) FOR...NEXT ; b) WHILE...WEND ; c) DO WHILE...LOOP; d) DO UNTIL...LOOP; e) DO...LOOP WHILE. Rspuns : e 14. Proiectarea fizic a bazei de date are n vedere: a) modul de stocare a datelor pe suportul de memorare; b) trecerea de la descrierea logic a datelor la una tehnic, de stocare a datelor; c) structura global de organizare a datelor. Rspuns: a), b) 15. Sistemul de Gestiune a Bazelor de Date este: a) un sistem de programe care permite definirea, crearea i ntreinerea bazei de date precum i accesul controlat la baza de date; b) un sistem de programe pentru interogarea bazei de date. Rspuns: a) ntrebri i rspunsuri Enumerai arhitecturile de baz pentru un sistem client-server dup rolul pecare l au componentele client i server; Rspuns: arhitectura de tip server de obiecte; arhitectura de tip server de pagini; arhitectura de tip server de baz de date.
1.

2. Enumerai cele 3 nivele ale noii arhitecturi client-server definite ca urmare a utilizrii a unor platforme hard-soft diferite, precum i integrrii bazelor de date n mediul Web:

116

Rspuns: nivelul client, la care se realizeaz interfaa cu utilizatorul aplicaiei; nivelul server de aplicaie, la care se realizeaz logica aplicaiei i prelucrrii datelor; nivelul server de baze de date, la care se realizeaz validarea datelor i accesul la baza de date.

117

Capitolul 6. Instrumente CASE


n general, un instrument CASE (Computer Aided Systems/Software Engineering) este un pachet software care ofer suport n proiectarea i implementarea sistemelor informatice. Prin integrarea numeroaselor tehnici utilizate n pregtirea proiectrii unui sistem, incluznd aici dicionarul datelor, fluxul de date, relaiile ntre entiti, un software de tip CASE poate determina o cretere a gradului de corectitudine cu care se realizeaz proiectarea unei baze de date. Altfel spus, termenul CASE se refer la totalitatea instrumentelor i metodelor destinate ingineriei software asistat de calculator. Aceste produse software asigur suport n etapa de analiz i de proiectare facilitnd reprezentarea grafic n cadrul acestor etape. Dei instrumentele CASE sunt numite uneori generic instrumente de modelare ER ceea ce ar nsemna c pot doar s creeze modelul logic, n realitate un instrument de tip CASE are mult mai multe faciliti. Un instrument CASE realizeaz n primul rnd legtura ntre modelul utilizator i modelul logic ce formalizeaz modelul utilizator folosind un mod de reprezentare comun att acestuia ct i proiectantului bazei de date. Un instrument de tip CASE nu elimin ns posibilitatea ca modelul final obinut s fie proiectat greit. n scopul evitrii acestei situaii este necesar o pregtire de durat a utilizatorului. Dac acesta are experien n lucrul cu instrumente CASE, utilizarea unui produs nou este facil deoarece toate instrumentele de modelare se bazeaz pe aceleai principii i au relativ aceleai faciliti. Dac ns utilizatorul este nou n domeniu, trebuie luat n considerare timpul necesar realizrii unui model i timpul necesar verificrii acestuia de ctre o persoan cu experien. Problema CASE-ului (Proiectarea Sistemelor/Programelor asistat de calculator sau cu Ajutorul Calculatorului Computer Aided Systems/Software Engineering) a devenit foarte important la mijlocul anilor 1980, cnd hardul sa extins prin seria PCurilor, iar reelele au devenit mai puternice, constituindu-se sistemele distribuite. Obiectivul principal al CASE-ului l constituie punerea n practic a produselor-program de proiectare i realizare a softului cu ajutorul calculatorului. Instrumentele oferite de CASE sunt utilizabile din faza de definire a cerinelor pn la ntreinerea fizic a produsului informatic. Totui, analiza i proiectarea, bazate pe conceptele i metodele structurate, reprezint elementele forte ale instrumentelor CASE, iar n ultimii ani CASE a acordat atenia cuvenit analizei, proiectrii i programrii orientate pe obiecte [46]. Majoritatea produselor soft au fost construite n mod artizanal, fr posibilitatea testrii complete a lor, fiind nsoite de o documentaie destul de slab. Instrumentele CASE implic utilizarea calculatorului ca un mijloc de susinere a activitilor de planificare, definire, proiectare i realizare a softului. Ele se bazeaz pe logica structural, pe descompunerea funcional i reprezentarea prin diagrame a fluxurilor de date ale aplicaiilor. Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a ncuraja abordarea logicii structurate i pentru folosirea calculatorului ca un mod de tezaurizare a lucrrilor i ca o planet de desen, pe care pot fi plasate reprezentrile structurate ale
118

sistemelor sau aplicaiilor. Pe msura evoluiei lor, sistemele CASE au devenit mult mai complexe, permind ca procesele de proiectare i realizare a aplicaiilor s se desfoare ntr-un mediu informatic interactiv, oferind utilizatorilor un ntreg arsenal de instrumente i proceduri, prin care pot proiecta, realiza, testa, documenta, ntreine/actualiza i exploata sistemul. Utilizarea produselor de tip CASE a fost determinat de [46]: calitatea ndoielnic a aplicaiilor realizate n mod tradiional; frustrarea utilizatorilor n ncercarea lor de a participa la procesul de proiectare i realizare a aplicaiilor, datorit nivelului ridicat de cunotine informatice solicitate de metodele tradiionale; costuri deosebit de mari pe care le presupun ntreinerea i actualizarea softului funcional; imposibilitatea rezolvrii tuturor cerinelor utilizatorilor; limitarea posibilitii de reprezentare grafic a schemelor de realizare a noilor proiecte. Folosirea sistemelor CASE este motivat i de urmtoarele avantaje: reducerea complexitii logicii de descriere a sistemului; posibilitatea de a alege dintre mai multe variante de proiectare; creterea vitezei de realizare a sistemelor; realizarea succesiv a componentelor unui sistem; creterea integrrii; consolidarea disciplinei de proiectare; oferirea unei interfee de proiectare; folosirea depozitelor modularizate; salvarea i refolosirea unor componente din diagramele realizate; simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor. Utilizarea sistemelor CASE a nceput cu introducerea diagramelor fluxurilor de date, care fac posibil realizarea unui model al derulrii proceselor sistemului/aplicaiei care se proiecteaz. A urmat folosirea dicionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaia. Au aprut ecranele predefinite pentru a prezenta ce poate s obin utilizatorul prin exploatarea sistemului. S-a apelat la facilitile grafice, care pot folosi simbolurile logicii structurate i care permit proiectantului s realizeze o diagram coerent a fluxurilor de date. 6.1. Funciile CASE Primele sisteme CASE erau un set de aplicaii neintegrate, cu funcii distincte, fr a fi interconectate. Aceste limite au fost eliminate, n cea mai mare parte, prin generaiile actuale, care ncearc s realizeze o integrare complet i uoar a tuturor elementelor, integrarea reprezentnd, de fapt, factorul cel mai important al metodologiei CASE. CASE se bazeaz pe dou funcii fundamentale [46].

119

Prima funcie const n posibilitatea descompunerii de sus n jos (top-down) a sistemului informatic n procese i module distincte, fiecare avnd definite responsabilitile funcionale i/sau operaionale. Cea de-a doua funcie se refer la faptul c sistemele informaionale pot fi reprezentate ntr-o form grafic concis, folosind cteva simboluri de baz. Importana acestor dou funcii rezid n posibilitatea utilizrii modularitii aplicaiilor, a diagramelor, obinerea unei documentaii privind realizarea, evaluarea arhitecturii i utilizarea sistemului. Pentru definirea i construirea sistemelor, produsele CASE presupun stabilirea i respectarea unei anumite discipline. Metodologia ofer o interfa ntre crearea i verificarea/validarea proiectului logic, dezvoltarea unei biblioteci cu documentaii, care include i integreaz caracteristicile proceselor i paii de parcurs, pentru descrierea modului de lucru; ofer un model al produsului final, ce poate fi folosit n realizarea operaiilor de exploatare i ntreinere a sistemului/aplicaiei, i ofer o interfa pentru pstrarea evoluiei proiectului. Folosirea reprezentrilor grafice n logica CASE ofer posibilitatea descompunerii aplicaiei n mai multe componente logice. Prin ataarea unei baze de date la elementele grafice, se va obine un depozit ce va conine paii i funciile reprezentate n diagramele construite. Dac aceste elemente sunt corect stabilite, ele vor sta la baza descrierii proceselor, ce vor constitui procedurile de prelucrare ale sistemului/aplicaiei. Modelarea grafic n sistemele CASE prezint o interactivitate ridicat, permind construirea diagramelor, deplasarea de la o diagram la alta, modificarea, extinderea, copierea, evaluarea i descrierea elementelor unei aplicaii. Modelele grafice permit conectarea fluxurilor logice ntre activitile i funciile specifice aplicaiei, relaii care pot fi testate i validate n mod automat. 6.2. Trsturi definitorii ale CASE-ului Evoluia instrumentelor CASE a determinat apariia I-CASE (Integrated CASE) care se refer la toate aspectele integrrii, chiar dac sistemele sunt deschise sau nu. Caracteristicile mediilor moderne de tip CASE [46]: un set de instrumente specifice pentru realizarea sistemelor; diversitatea modurilor de interaciune; semnificaia reprezentrilor grafice; elemente de tip verificare i validare (V&V); natura bidirecional, deplasri pe vertical n structura sistemului; deschidere pentru interconectarea instrumentelor CASE; sprijin pentru lucrul cu utilizatori multipli; descompunerea; performane de deplasare, pe orizontal, de la un instrument la altul; grade diferite de automatizare; integrarea.

120

CASE-ul nu este un proces independent. El constituie un set integrat de metodologii, care urmresc realizarea ciclului de via al unui sistem. La sfritul fiecrei faze a ciclului de via, rezultatele obinute trebuie supuse unei analize i verificri, iar utilizatorii trebuie informai asupra modului de gestionare a procedurilor de lucru. Ei sunt cei care trebuie s dea avizul de continuare a parcurgerii fazelor urmtoare, pe baza a ceea ce li s-a prezentat. Este, de fapt, un proces de revalidare a conceptelor folosite n proiectarea sistemului i a modelului proiectat pe msura desfurrii operaiunilor, din faza de proiectare pn la predarea produsului final. CASE poate sprijini aceste proceduri prin punerea la dispoziie a unei documentaii a modelului proiectat. Pe acest fond, pot fi fcute evaluri, critici sau modificri asupra elementelor din modelul proiectat. Rezultatele obinute n urma proiectrii unui anumit model de sistem constau n documentaia oferit, care acoper ntregul ciclul de via al sistemului, cu toate operaiile i procedurile pe care le presupune. n plus, CASE ofer posibilitatea de a analiza ieirile obinute i de a le modifica pentru a reflecta schimbrile intervenite n sistem, modulele definite i depozitul de date. 6.3. Tipuri de instrumente CASE [72] n literatura de specialitate, instrumentele CASE sunt clasificate i dup un alt criteriu dect cel al activitilor din ciclul de via al sistemelor pe care le sprijin. Acest criteriu se refer la metodologia pe care o ncorporeaz pentru realizarea sistemelor. Astfel, se ntlnesc urmtoarele trei categorii: instrumente CASE bazate pe metodologia structurat; instrumente hibride, ce conin elemente specifice orientrii-obiect, dar care nu permit realizarea sistemelor orientate-obiect; instrumente pur orientate-obiect. n cele ce urmeaz se vor prezenta cteva exemple de CASE folosite de cele mai utilizate metodologii de analiz i proiectare, respectiv metodologia structurat i cea orientat pe obiecte. A) Metodologia structurat Westmount I-CASE Yourdon ofer suport complet pentru realizarea sistemelor informatice. Avnd la baza metoda structurat propus de Yourdon, acest instrument CASE integrat ofer posibilitatea lucrului n echip, posibilitatea de generare i reutilizare a codului i generarea automat a documentaiei de realizare a sistemului informatic. Repository este componenta central a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaional: Informix, Ingres sau Oracle. Analyst, este componenta ce ofer suport pentru analiza structurat. Metoda este implementat de Yourdon i De Marco. Westmount I-CASE Yourdon ofer suport pentru un set extins de instrumente i anume editoare pentru diagrame de flux a datelor, diagrame entitate asociere, diagrame de structur a datelor editoarele matriciale pentru matricea listei de evenimente. Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de ansamblu).
121

Designer este componenta ce ofer suport pentru proiectarea de detaliu a sistemului informatic. Proiectarea de detaliu a aplicaiei este strns legat de proiectarea bazei de date. Pentru modelarea datelor se utilizeaz diagrama entitate asociere. Programmer este mediul de programare care ofer suport pentru generarea codului surs, compilare, lansare n execuie i testarea aplicaiei. Generatorul de cod translateaz specificaiile de proiectare n cod surs. Astfel, pe baza diagramei entitate asociere se genereaz codul DDL (n SQL) ce definete structura fizic a bazei de date. Codul poate fi completat pentru a defini restriciile de integritate i modul fizic de stocare a bazei de date. Este prezentat i facilitatea de inginerie inversat care translateaz definirile asociate bazei de date existente ntr-o diagram entitate asociere. Codului aplicaiei este generat n limbajul C mbogit cu instruciuni SQL pornind de la specificaiile din schemele de structur. Docwriter este componenta care permite generarea documentaiei pentru fiecare etap de realizare a sistemului. Utilizarea produsului Westmount I-CASEY Yourdon mbuntete productivitatea realizrii sistemelor informatice i ofer garanii pentru calitatea sistemelor obinute. B) Metodologia orientat-obiect Expresia pur orientate-obiect" se refer la faptul c pe de o parte, instrumentele CASE conin numai elemente specifice abordrii orientate-obiect a sistemelor, iar pe de alt parte la faptul c se bazeaz pe metodele i tehnicile de analiz i proiectare orientateobiect. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de via al sistemelor, pot fi grupate ca i cele convenionale, astfel: - Upper CASE orientat-obiect pentru analiza i proiectarea sistemelor; - Lower CASE orientat-obiect pentru generarea codului-surs al aplicaiilor; - I-CASE orientat-obiect care acoper ntregul ciclu de via. Tendina de utilizare mai accentuat a tehnologiilor informaionale orientate-obiect a condus la apariia a numeroase produse CASE orientate-obiect sau la reorientarea firmelor productoare de instrumente convenionale spre nglobarea n produsele lor a elementelor specifice abordrii obiectuale. 6.4. Exemple de instrumente CASE Un posibil dezavantaj al utilizrii instrumentelor CASE l reprezint costul acestora. O licen pentru All Fusion ERwin Data Modeler cost n jur de 3000$. La momentul actual nu se poate indica exact un anumit produs software ca fiind cel mai bun de pe pia. n final nu conteaz ce produs a fost utilizat att timp ct modelul obinut este correct i poate fi ntreinut cu uurin. Se consider c un instrument CASE este performant dac permite forward engineering (capacitatea de a crea baza de date din modelul proiectat), ingineria invers (crearea modelului avnd la dispoziie modelul) i capturarea metadatelor (posibilitatea de definire a datelor). Se va demonstra aceast afirmaie exemplificnd cu ajutorul mai multor instrumente, dintre care cel mai performant, conform opiniei generale, este AllFusion Erwin Data Modeler.

122

6.4.1. Erwin Data Modeler Unul dintre programele intens utilizate n proiectarea CASE a bazelor de date este Erwin care este un instrument de modelare vizual care permite att modelarea logic ct i modelarea fizic. Cteva dintre avantajele utilizrii acestui program [17]: - mediu de modelare simplu de utilizat; - este posibil partajarea i reutilizarea modelelor odat create; - utilizarea Erwin reduce timpul de proiectare datorit crerii automate a modelului fizic; - mbuntete exactitatea modelului datorit posibilitii de sincronizare a modelului cu baza de date fizic; - ERwin pune la dispoziia utilizatorului o facilitate important numit forward engineering care permite conversia diagramei ER n cod SQL corespunztor bazei de date modelate; - reverse engineering facilitate care permite crearea unui model pe baza schemei unei baze de date existente n prealabil. Erwin Data Modeler permite utilizarea modelelor complexe prin mprirea lor n submodele mai uor de gestionat. Modelele realizate pot fi vizualizate, modificate i tiprite la imprimant n multiple moduri. RPTwin este o component nglobat n Erwin care permite realizarea de rapoarte i conine un set de rapoarte predefinite i de asemenea ofer posibilitatea realizrii unor rapoarte personalizate. Fereastra principal Erwin Data Modeler este prezentat n figura 6.1.

123

Figura 6.1. Fereastra ERwin Data Modeler. n partea superioar a interfeei utilizator ERwin sunt plasate bara de meniuri i bara de instrumente (toolbar) care permit selectarea unor opiuni din meniuri, respectiv accesarea mai rapid a unora dintre aceste opiuni prin apsarea butoanelor corespunztoare. Fereastra de explorare a modelului (Model Explorer Pane) permite, prin intermediul unor elemente grafice, construirea modelului prin inserarea de entiti, domenii, relaii, reguli de validare, etc. AllFusion Erwin Data Modeler suport trei tipuri de modele pentru proiectarea bazelor de date: Logic: Model conceptual (global) care include entiti, relaii i atribute, eseniale obinerii unui model Entitate Relaie. Fizic: Model detaliat care implic specificarea tabelelor, atributelor i a tipului de date asociat. Logic/Fizic: Un model care nglobeaz att modelul fizic ct i modelul logic. Pentru a crea un model, se alege opiunea New din meniul File. Fereastra Create Model este prezentat n figura 6.2.

124

Figura 6.2. Fereastra de creare a unui nou model Aceast fereastr de dialog permite alegerea tipului modelului (butoanele radio din partea superioar) i formatul bazei de date n care va fi exportat modelul creat n Erwin. Se poate alege de asemenea i un eventual ablon (Template) pentru crearea unui anumit tip de model prin apsarea butonului Browse File System i alegerea fiierului respectiv. Formatul bazei de date se alege din seciunea Target Database. n figura de mai sus s-a ales formatul Acces. Noul model va fi denumit implicit Model_n. Pentru a-l redenumi se execut click dreapta pe numele modelului din fereastra Model Explorer i se alege opiunea Properties. Redenumirea se realizeaz prin introducerea noului nume n cmpul Name, figura 6.3.

Figura 6.3. Redenumirea modelului Crearea modelului continu cu inserarea atributelor. Din fereastra Diagram Windows se execut dublu click pe entitatea care se va popula cu atribute i se alege opiunea New. Se va afia fereastra din figura 6.4. Se apas butonul New, apoi se introduce numele atributului i se selecteaz tipul acestuia.

125

Figura 6.4. Fereastra introducere a atributelor. ERwin suport trei tipuri de relaii: cu identificare, fr identificare i many to many. ERwin clasific entitatea copil ntr-o relaie cu identificare slab (weak). Pentru adugarea unei relaii se execut click dreapta pe elementul Relationship din Model Explorer i se alege opiunea New. Se va afia fereastra din figura 6.5.

Figura 6.5. Adugarea unei relaii noi O relaie cu identificare semnific faptul c una dintre entitile relaiei este entitate dependent, adic una dintre entiti este, pentru a se identifica, cel puin parial dependent de cealalt entitate. Entitatea copil nu se poate identifica fr a se utiliza cel puin cheia primar a entitii printe. ntr-o relaie fr identificare, entitatea copil nu are nevoie pentru identificare de cheia primar a entitii printe. Entitatea copil trebuie s

126

conin ns obligatoriu cheia primar a entitii printe. O relaie de tip fr identificare este simbolizat prin linie punctat. Dup alegerea celor dou entiti aflate n relaie i apsarea butonului OK, noua relaie este adugat i este figurat grafic printr-o linie (punctat sau continu, corespunztoare tipului relaiei) ce unete cele dou entiti. O relaiei many to many este simbolizat printr-o linie continu cu dou puncte negre la ambele capete. Dup crearea relaiei, utilizatorul poate aduga o descriere a acesteia prin executarea unui click dreapta pe relaie i accesarea opiunii Properties. n final, dup realizarea tuturor operaiilor se obine un model fizic ce poate fi ulterior folosit pentru forward engineering, figura 6.6. Erwin permite, prin intermediul opiunii Forward Engineering, convertirea diagramei entitate relaie n cod SQL, generndu-se astfel schema bazei de date. Scriptul SQL din figura 6.7 este obinut pentru modelul StocProd de gestionare a depozitrii i vnzrii produselor n cazul unui hipermarket.

Figura 6.6. Model fizic al unei baze de date.

127

Figura 6.7. Script SQL generat prin forward engineering

6.4.2. Microsoft Visio 2007 Microsoft Visio permite crearea unui mare numr de tipuri de diagrame bazate pe abloane predefinite, dar ofer i instrumente CASE pentru proiectarea bazelor de date. Este disponibil n dou variante, Standard i Professional, varianta profesional avnd capaciti avansate de Inginerie invers i un mai mare numr de abloane predefinite. De asemenea, varianta Professional permite elaborarea de diagrame specifice limbajului de programare vizual UML i transformarea bazelor de date n format UML (Universal Modeling Language) [71]. Fereastra Microsoft Visio Professional este prezentat n figura 6.8.

128

Figura 6.8. Interfaa Microsoft Visio 2007. abloanele sunt grupate pe categorii i afiate n banda din partea stng a ferestrei aplicaiei. Procesul de creare a modelului unei baze de date poate ncepe prin selectarea ablonului corespunztor din categoria Database Model Diagram sau cu importarea unui model deja creat n Erwin Data Modeler, figura 6.9. Opiunea Reverse Engineering din meniul Database permite importul bazelor de date Oracle, DB2, SQL, Access i generarea modelului Visio corespunztor. Un program automatizat (wizard) ghideaz utilizatorul pentru o preluare mai facil a bazelor de date deja existente n alte formate i pentru conectarea la diverse surse de baze de date. Proiectarea unei baze de date cu ajutorul Visio presupune parcurgerea urmtoarelor etape: a) Crearea modelului ORM (Object Role Model) care permite crearea unui model intuitiv al bazei de date (stabilirea entitilor, a atributelor acestora, evidenierea relaiilor dintre entiti). b) Generarea automat a modelului logic pe baza modelului ORM c) Generarea modelului fizic pe baza modelului logic obinut anterior Interfaa de creare a tabelelor (entitilor) este similar cu aceeai interfa din programul Microsoft Access cu deosebirea c, n cazul Visio, tabelele pot fi portabile independent de sistemul de gestionare a bazelor de date.

129

. Figura 6.9. Opiunile meniului Database. Este posibil importul modelelor realizate cu alte instrumente CASE. Ca etap intermediar ntre generarea modelului logic i generarea modelului fizic este necesar validarea modelului (Database->Model-> Error Check). n acest caz este posibil apariia unor erori care vor fi afiate n fereastra de afiare a rezultatelor. Cele mai comune tipuri de erori pot aprea n urmtoarele dou situaii: - dou sau mai multe relaii au acelai nume; - coloanele cu aceeai denumire din tabele diferite sunt diferite din punct de vedere al tipului datelor. Pentru a genera baza de date se selecteaz din meniul Database opiunea Generate. Se va lansa automat validarea modelului i se poate opta pentru generarea unui script DDL ce conine comenzile SQL corespunztoare generrii fiecrei tabele i relaii din baza de date. Este util selectarea opiunii Store current database image in model pentru ca modificrile ulterioare aduse bazei de date s determine doar o adugare a acestora i nu crearea de la zero a bazei de date modificate. n final Visio va genera entitile, indecii i relaiile bazei de date. Rezultatul acestei cod va fi afiat n fereastra de afiare a rezultatelor. Ca ultim etap, se recomand o verificare a codului respectiv, ntruct pot aprea erori. Visio 2007 permite salvarea sub form de pagin Web a modelelor realizate. Diagramele ER se pot salva n diverse formate grafice cu scopul utilizrii ulterioare n documentaiile diverselor proiecte. 6.4.3. Toad data modeler Toad Data Modeler export diagramele ER n format HTML, RTF sau n format imagine (.jpg sau .bmp). Atuurile acestui program sunt urmtoarele [69]:

130

posibilitatea de a creea diagrame ER pentru diverse sisteme de gestionare a bazelor de date; ingineria invers; adugarea de date suplimentare n diagramele ER pentru a mbunti descrierea bazei de date; posibilitatea de a verifica modelul i de a genera erorile ntr-o form explicit; generarea automat de cod SQL pentru baza de date creat; monitorizarea modificrilor cu ajutorul Version Manager-ului; posibilitatea de creare a unei liste de sarcini privind modelul generat (To Do list). Pentru a creea un nou model n Toad Data Modeler se alege din meniul File opiunea New. n continuare se alege formatul bazei de date int, pentru care va fi generat scriptul SQL. Pentru Access 2000 nu se genereaz script SQL, ns se genereaz cod VBA (Visual Basic for Applications). Codul surs poate fi executat ca i Modul n fereastra editorului Visual Basic din Access 2000. Mai nti va trebui creat o baz de date vid i inserat un modul Visual Basic. n modulul respectiv se copie codul generat de programul Toad. n continuare, din fereastra editorului Visual Basic se alege opiunea Reference din meniul Tools i se selecteaz DAO 3.6 libraries for MS Access 2000 i se lanseaz n execuie modulul din opiunea Run. Din meniul Model, opiunea Insert se insereaz toate elementele grafice ale modelului: entiti, atribute i diverse tipuri de relaii. Dac se dorete modificarea tipului unei relaii create n prealabil, se execut click dreapta pe relaia respectiv i se alege opiunea Edit Relationship. Se va afia fereastra din figura 6.10.

131

Figura 6.10. Modificarea unei relaii. Este posibil astfel redenumirea relaiei, modificarea tipului acesteia, inserarea unei scurte descrieri, etc. Pentru a obine o imagine de ansamblu asupra bazei de date, se va accesa opiunea Project Explorer din meniul Model. Se va afia structurat lista cu entitile existente, atributele, relaiile i indecii utilizai, figura 6.10. n final se valideaz modelul i se remediaz eventualele erori selectnd opiunea Model Verification. Procesul de inginerie invers va extrage toate elementele bazei de date din formatul original i va genera modelul Toad al bazei de date respective. Pentru a asigura comunicarea cu diversele formate de baze de date, Toad folosete diverse metode de comunicaie printre care, atunci cnd este posibil i comunicaia nativ. Opiunea Reverse Engineering din meniul File va demara procesul. Utilizatorul va trebui s specifice formatul original al bazei de date, tipul acesteia i numele utilizator i parola de conectare dac este cazul, figura 6.11.

132

Figura 6.11. Afiarea structurat a modelului. Fereastra Model Explorer

133

Figura 6.11. Opiunea Reverse Engineering. 6.4.4. Embarcadero ER/Studio [70] Programul suport diverse tipuri de baze de date: Oracle, MS SQL Server, IBM DB2 i Sybase ASE. Programul poate fi rulat n dou moduri: client independent (standalone) sau ca i client conectat la un depozit central. Depozitul permite crearea unei baze de date centralizate care va memora modelele create i permite de asemenea aplicarea unor restricii de securitate referitoare la accesul la modelul respectiv. Nu este permis accesul la un submodel fr ca, n prealabil, accesul la modelul principal s fie permis. Opiunea New din meniul File determin activarea ferestrei din figura 6.12.

134

Figura 6.12. Opiunile disponibile pentru crearea unui nou model n ER/Studio Dup cum se constat din figura 6.12, sunt posibile trei variante de creare a modelului: crearea unui model nou, posibilitatea de a importa un model din fiiere SQL, ERX sau dintr-un format extern de descriere a datelor. Facilitatea inginerie invers utilizeaz conexiunea direct cu o mare varietate de tipuri de baze de date. Odat cu accesarea acestei opiuni se lanseaz un wizard care va afia o list cu tipurile de baze de date compatibile i care vor fi ulterior transformate n modele logice sau fizice. Obiectele asupra crora se poate aplica procesul inginerie invers sunt: tabelele i vederile, tabelele definite de utilizator, procedurile i funciile memorate. Se detecteaz de asemenea automat integritatea n cazul n care nu este declarat explicit n baza de date. ER/Studio va mpri elementele capturate dintr-o baz de date n dou categorii, corespunztoare modelului logic i modelului fizic. Prin vizualizarea modelului logic, utilizatorul poate vizualiza proprietile asociate unei tabele, cum ar fi atributele, relaiile i eventualele restricii. Programul nu elimin restriciile legate de cheia strin declarate explicit ci va semnala o cheie strin prin afiarea simbolului FK lng aceasta. ER/Studio permite crearea diagramelor entitate relaie n totalitate pornind de la zero sau obinerea acestora cu ajutorul facilitii inginerie invers. Produsul scaneaz bazele de date i ajut utilizatorii n eliminarea redundanelor prin extragerea metadatelor.

135

Figura 6.13. Interfaa utilizator ER/Studio 6.4.5. Oracle Designer Setul de instrumente Designer/2000 este parte integrant din portofoliul de instrumente de dezvoltare oferit de Oracle i reprezint o soluie integrat pentru dezvoltarea de sisteme client/server din generaia a doua sau de sisteme Intranet bazate pe Web. Designer/2000 acoper toate fazele ciclului de dezvoltare a aplicaiilor software, pornind de la modelarea sistemului informatic (business modelling) pn la exploatare. Abordarea Designer/2000 bazat pe un Repository permite ca anumite componente sau toate componentele s fie folosite pentru dezvoltarea rapid de aplicaii scalabile, multiplatform, distribuite [72]. Oracle Designer ofer instrumente de modelare i de dezvoltare care permit utilizatorilor s urmreasc anumite metode de proiectare. Astfel, Oracle Designer permite utilizatorilor s utilizeze metodologia SLDC (System Development Life Cycle) sau metode iterative gen SSADM (Structured System Analysis and Design Methodology).

136

Figura 6.14. Oracle Designer 2000. n cele ce urmeaz se vor prezenta caracteristicile generale ale acestui produs software. Produsele software ofer instrumente de modelare pentru crearea diagramei de flux de date, a diagramelor entitate relaie, a diagramelor ierarhiei funcionale i a modelelor de proces. Oracle Designer poate transforma un model logic n model fizic ce poate fi apoi transformat n baz de date. Oracle Designer conine instrumente de transformare a procedurilor n cod i poate de asemenea genera o interfa grafic utilizator (GUI) prin utilizarea Oracle Form i Report. Oracle Designer ofer un depozit centralizat n care se stocheaz toate informaiile ce pot fi accesate de ctre ali utilizatori. Acest fapt permite proiectanilor s lucreze simultan la aceeai aplicaie i toate modelele sunt imediat disponibile celorlaltor utilizatori. Un alt avantaj al acestei centralizri este cel generat de faptul c toat informaia este memorat unitar, micorndu-se riscul pierderii sau alterrii acesteia. Depozitul care stocheaz toat informaia pentru instrumentul CASE furnizeaz un volum mare de documentaie format din detalii referitoare la model (Diagrama ER, de flux de date) i de comentarii memorate n aplicaii sub diverse forme (tabele, vederi sau module SQL). Oracle Designer permite generarea unor rapoarte utile din depozitul de date. Codul PL/SQL este stocat ntr-o form modular, grupat pe funcii, proceduri sau triggere. Modulele sunt incluse n alte module PL/SQL ca uniti de subprogram. Cnd aceste module sunt generate pe baza depozitului, toate subprogramele sunt incluse pentru a forma codul surs al modulului.

137

Un alt avantaj al instrumentelor CASE este faptul c scurteaz timpul necesar obinerii unui model valid. Instrumentele CASE permit proiectarea sistemului i prin utilizarea unor instrumente de modelare este posibil transformarea acestuia n elemente palpabile (tabele, chei strine). Deoarece informaia utilizat de instrumentul CASE este memorat centralizat ntreinerea sistemului este mai facil. Din punct de vedere al mentenabilitii, apar urmtoarele avantaje: - modelele proiectate pot fi actualizate imediat; - modificrile aplicate asupra modelului pot fi implementate n aplicaie cu ajutorul instrumentelor specifice ceea ce reduce posibilitatea apariiei unor erori; - codul generat poate reflecta doar eventualele modificri aduse asupra tabelelor; - codul generat este stocat modular astfel nct este posibil modificarea doar a unui modul i regenerarea modulului modificat.

Teste rezolvate 1. Obiectivul principal al instrumentelor CASE este: a) Punerea n practic a produselor-program de proiectare i realizare a softului cu ajutorul calculatorului. b) Simplificarea activitilor de proiectare i realizare a sistemelor/ aplicaiilor. c) Folosirea depozitelor modularizate. Rspuns: a 2. Avantajele sistemelor CASE sunt: a) exploatarea sistemului; b) creterea vitezei de realizare a sistemelor; c) realizarea succesiv a componentelor unui sistem; d) simplificarea activitilor de proiectare i realizare a sistemelor/aplicaiilor. Rspuns: b, c, d 3. Instrumentele CASE se bazeaz pe: a) o funcie fundamental; b) dou funcii fundamentale; c) mai multe funcii fundamentale. Rspuns: b 4. Caracteristicile mediilor moderne de tip CASE sunt: a) integrarea;

138

b) aranjarea; c) descompunerea; d) exploatarea. Rspuns: a, c 5. Domeniile ctre care se orienteaz Upper CASE-ul, sunt: a) analiza cerinelor sistemului; b) proiectarea i modelarea funcional i procedural; c) modelarea datelor i proiectarea bazei de date; d) generarea codurilor. Rspuns: a, b, c, d 6. Nu sunt corecte urmtoarele afirmaii: a) CASE reprezint Proiectarea Sistemelor Asistat de Calculator; b) Instrumentele CASE implic utilizarea calculatorului ca un mijloc de susinere a activitilor de planificare, definire, proiectare i realizare a softului. c) CASE reprezint Proiectarea Sistemelor cu Ajutorul Calculatorului; d) CASE reprezint Componente Asamblate ale Sistemelor Economice. Rspuns: d ntrebri i rspunsuri 1. Enumerai tipurile de instrumente CASE dup metodologia pe care o ncorporeaz pentru realizarea sistemelor. Rspuns: instrumente CASE bazate pe metodologia structurat; instrumente hibride, ce conin elemente specifice orientrii-obiect, dar care nu permit realizarea sistemelor orientate-obiect; instrumente pur orientate-obiect. 2. Enumerai componentele produsului Westmount I-CASE Yourdon. Rspuns: Repository este componenta central a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaional: Informix, Ingres sau Oracle. Analyst, este componenta ce ofer suport pentru analiza structurat i anume: editoare pentru diagrame de flux a datelor, diagrame entitate asociere, diagrame de structur a datelor editoarele matriciale pentru matricea listei de evenimente. Arhitect este componenta ce permite definirea arhitecturii sistemului (proiectarea de ansamblu). Designer este componenta ce ofer suport pentru proiectarea de detaliu a sistemului informatic. Proiectarea de detaliu a aplicaiei este strns legat de proiectarea bazei de date. Pentru modelarea datelor se utilizeaz diagrama entitate asociere. Programmer este mediul de programare care ofer suport pentru generarea codului surs, compilare, lansare n execuie i testarea aplicaiei. Generatorul de cod genereaz codul
139

DDL (n SQL) ce definete structura fizic a bazei de date i codul aplicaiei n limbajul C mbogit cu instruciuni SQL pornind de la specificaiile din schemele de structur. Docwriter este componenta care permite generarea documentaiei pentru fiecare etap de realizare a sistemului. 3. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de via al sistemelor, pot fi grupate n instrumente: Rspuns: Upper CASE orientat-obiect pentru analiza i proiectarea sistemelor; Lower CASE orientat-obiect pentru generarea codului-surs al aplicaiilor; I-CASE orientat-obiect care acoper ntregul ciclu de via.

140

Capitolul 7. Tendine actuale i de perspectiv n evoluia sistemelor informatice


7.1. Concepia sistemic n economie ncepnd din anii 80, n teoria general a sistemelor apare i se dezvolt o nou concepie i anume concepia holonic asupra sistemelor. Aproximativ n aceeai perioad se dezvolt sistemele inteligente, ca structur de baz n domeniul inteligenei artificiale. Un sistem holonic este [61], [BURA99] un sistem de referin deschis n cadrul cruia funcioneaz alte sisteme autonome, fiind posibil desprinderea i ataarea de sisteme autonome att n plan abstract ct i n plan real, iar optimizarea vizeaz att sistemele componente ct i sistemul de referin. n acest context, dou sau mai multe sisteme autonome pot fi integrate n baza unor criterii i pentru atingerea unor obiective, formnd astfel un nou sistem de referin, respectiv sistemul holonic care are rolul de integrator i care optimizeaz funcionarea i rezultatele obinute de sistemele ncorporate. Arhitectura general a unui sistem holonic este reprezentat n figura 7.1 [61], [BURA99].
S1

INPUTS

SI

S2 . . . Sn

OUTPUTS

FEEDBACK

Fig 7.1. Arhitectura general a unui sistem holonic Sistemul activitii umane este un tip particular de holon la care se raporteaz optimizarea tuturor celorlalte sisteme holonice. Realizarea i funcionarea unui sistem integrator este de neconceput fr utilizarea masiv a tehnologiei informatice. Concepia holonic asupra sistemelor ofer noi perspective n cercetarea tiinific i n procesul cunoaterii cu aplicabilitate n diverse domenii, inclusiv n economie, ns rezultate spectaculoase sunt ateptate n domeniul inteligenei artificiale [61], [BURA99]. Avnd n vedere aceast concepie precum i impactul utilizrii tehnologiilor informatice (mai recent a inteligenei artificiale) n management, n domeniul economic este definit firma holonic [61], [BURA99] i ntreprinderea inteligent [1].

141

O firm holonic se obine prin integrarea a dou sau mai multor companii autonome ntr-o reea, avnd n vedere cerinele prezente i viitoare impuse de clienii comuni i standardul produselor/serviciilor realizate de fiecare firm autonom. Concepia holonic asupra sistemelor poate fi avut n vedere i n cadrul altor organizaii, un exemplu n acest sens fiind organizaiile administraiei publice locale la nivel teritorial (consiliul judeean, prefectura, primriile din cadrul judeului). Schimbrile tehnologice care au avut loc n ultimii ani au condus la o nou gndire privind ntreprinderea i activitatea sa, cu implicaii majore la nivel organizaional i n ceea ce privete managementul. Dezvoltarea i utilizarea sistemelor inteligente n cadrul unei organizaii permite managerilor s foloseasc cunoaterea depozitat pentru rezolvarea problemelor complexe din cadrul organizaiei i pentru luarea deciziilor strategice. Existena reelelor Internet, Intranet, Extranet i a altor reele de telecomunicaii permite interconectivitatea global i deci manifestarea organizaiilor la nivel planetar. n condiiile globalizrii, ntreprinderea modern trebuie s satisfac necesitile globale de afaceri ntr-o societate informaional global astfel nct aplicaii din orice punct de pe glob s poat accesa i prelucra datele i cunotinele necesare desfurrii activitii muncitorului cunoaterii. Utilizarea sistemelor inteligente care sunt permanente, nu fac grev, nu solicit concediu, pot memora, consulta i prelucra volume considerabile de date i cunotine i pot funciona 24 de ore din 24, asigur o independen a managementului de salariai i pune la dispoziia managerilor toate cunotinele acumulate asistndu-i n soluionarea problemelor complexe i luarea deciziilor. Sistemele inteligente ofer posibilitatea exploatrii cunoaterii prin combinarea potenialului tehnologiei bazelor de date cu tehnologia bazelor de cunotine i a sistemelor expert, remarcndu-se n acest sens tehnologia bazelor de date inteligente [3]. Avnd n vedere aceste aspecte s-a definit ntreprinderea inteligent, ntreprinderea expert, ntreprinderea bazat pe cunotine [1], ca fiind acea organizaie n care se utilizeaz n mod curent sistemele inteligente pentru soluionarea tuturor problemelor dificile, organizaia care lucreaz inteligent este organizaia care capteaz cunoaterea de la experii umani, o depoziteaz ntr-o form acceptat de ctre calculator i o folosete cu ajutorul unor programe specializate la soluionarea problemelor. ntreprinderile viitorului denumite de McHugh & all [61] firme virtuale, vor fi propulsate spre succes de o viziune comun, iar managementul se va realiza att prin procese i tehnici intuitive ct i prin metodele logice i raionale utilizate la ora actual. Societatea modern este caracterizat de schimbri rapide i inovare permanent n toate domeniile cunoaterii. nc din anii 70, n lucrarea ocul Viitorului, Alvin Toffler atrgea atenia asupra accelerrii schimbrii n toate domeniile cunoaterii, schimbare determinat n principal de revoluia informatic. Perioada 1950-1990 definete Al Treilea Val al progresului i este perioada n care are loc revoluia informatic prin utilizarea mainilor inteligente i n care accentul este pus pe resursa individ, iar relaiile interorganizaionale au la baz deviza cooperm. Dup 1990 are loc naterea i rspndirea celui de-Al Patru-lea Val
142

determinat de revoluia cunoaterii cu accent pe cunoaterea incontient deci cunoaterea bazat pe intuiie, imaginaie i capacitatea creativ a individului. Este perioada ce va fi caracterizat de realizarea i utilizarea de maini care gndesc destinate pe domenii (ex. Economia), n care managementul este privit ca instituie central cu difuzarea sa fr frontiere ntr-o societate informaional global i n care cunoaterea este exploatat ca resurs economic sub deviza crem mpreun. Datorit facilitilor de comunicare dincolo de granie, spaiu i timp oferite de reeaua Internet, economia noului mileniu poate fi privit [73] ca o scen digital n care noile afaceri devin e-bussines (afaceri electronice), comerul devine e-commerce (comer electronic), apar noi servicii electronice (e-services) i se nasc noi comuniti de tip virtual (e-communities). n noua scen cu calculatoare interconectate n reele Internet, Intranet i Extranet suntem inundai de informaie, dar flmnzi dup cunotine [73] (John Naisbitt Megatrends. Ten New Directions Transforming Our Lives), viziunea lui Alvin Toffler n ocul viitorului fiind mult mai sumbr, el avertiznd asupra iminenei unui nou potop, de aceast dat nu de ap, ci de informaii. Apare deci i se dezvolt, n cadrul economiei digitale, o nou pia i anume piaa digital sau piaa electronic n care trebuie acordat o importan tot mai mare noii resurse strategice care este informaia, cunotina. Principalii actori (componente) ai economiei digitale, n viziunea anumitor specialisti (Turban, s.a., 1999) [73] sunt: cumprtorii/consumatorii - milioane de internaui care navigheaz pe Web -poteniali cumprtori ai bunurilor i serviciilor oferite sau promovate pe Internet; vnztorii - sute de mii de magazine digitale care i prezint milioane de produse pe Net; produsele i serviciile digitale - digitalizarea software-ului, a muzicii, a crilor, ziarelor i revistelor, a filmelor .a., digitalizarea a nenumrate alte produse i servicii; companiile creatoare ale infrastructurii digitale - mii de firme implicate n asigurarea hardware-ului i software-ului necesar realizrii infrastructurii specifice economiei digitale, care s permit dezvoltarea comerului electronic; intermediarii (agenii)- un nou tip de actori care i ofer serviciile pe Web, rolul lor diferind de cel al intermediarilor obinuii prin aceea c sunt implicai n crearea i susinerea pieei on-line, ei ajutnd consumatorii i/sau vnztorii n derularea tranzaciilor electronice; serviciile de suport - sute de astfel de servicii sunt disponibile, pornind de la cele care asigur securitatea pn la cele care furnizeaz cunotine; creatorii de coninut - sute de companii de tip multimedia orientate pe crearea i actualizarea continu a propriilor pagini Web, precum i a unor site-uri pentru diverse alte firme. Fiecare din componentele economiei digitale prezentate mai sus are un rol bine definit n cadrul pieei digitale / spaiului electronic (marketspace) n care au loc tranzaciile.
143

Din prezentarea de mai sus se constat apariia unui nou tip de actor pe scena digital i anume intermediarul sau agentul. Se impune astfel distribuirea inteligenei artificiale n vederea realizrii sistemelor de ageni inteligeni sau sistemelor multiagent care pot lua decizii ntr-o societate populat de ageni inteligeni artificiali sau umani care au propriile lor scopuri. Distribuirea inteligenei artificiale este justificat din urmtoarele motive: n mod natural activitile i cunotinele sunt distribuite spaial; extinderea cooperrii om-main prin rezolvarea distribuit a problemelor; descompunerea sistemelor complexe i a bazelor de cunotine aferente n subsisteme cooperative asigurnd astfel modularitate i flexibilitate sistemului precum i timp de rspuns optim; necesitatea integrrii aplicaiilor de inteligen artificial deja existente, att ntre ele ct i cu componente de prelucrare clasic i sisteme de gestiune a bazelor de date distribuite; n modelarea comportamentului uman n cadrul aplicaiilor de inteligen artificial trebuie avut n vedere faptul c comportamentul uman este un comportament social. Astfel, apare i se dezvolt o nou tehnologie n realizarea programelor i anume programarea orientat agent AOP (Agent-Oriented Programming), care constituie o modalitate de abordare n construcia sistemelor multi-agent. Programarea orientat pe ageni introdus de Yoav Shoham odat cu definirea limbajului AGENT0, reprezint o specializare a programrii orientate pe obiecte i n care coleciei de obiecte definite de stri i care comunic ntre ele prin transmitere de mesaje i corespunde o mulime de ageni caracterizai de stri mentale compuse din noiuni mentale (convingeri, intenii, obligaii, angajamente, decizii, etc.). Comunicarea ntre ageni se realizeaz prin intermediul unui limbaj specializat cum ar fi de exemplu limbajul KQML (Knowledge Querry and Manipulation Language) propus de ARPA (Advanced Research Projects Agency) n 1992, cu ultima versiune standardizat aprut la nceputul anului 1997 (ARPA a realizat i standardul MIF -Module Interconnect Framework ce conine metodele standard de construire a megaprogramelor multimodul). KQML folosete limbajul KIF (Knowledge Interchange Format) pentru a descrie coninutul informaional al mesajului i este o reprezentare ASCII a logicii cu predicate de ordinul nti, ntr-o sintax apropriat de cea a limbajului LISP. Limbajul KQML i KIF (cu succesorul lui SIF - Simple Knowledge Interchange Format) tind s devin la ora actual un standard al comunicrii n Sistemele Multi Agent cognitive. Pentru realizarea activitilor dintr-un domeniu ntr-o manier inteligent, n cadrul procesului decizional, decidentul este pus permanent n situaia de a evalua i alege ntre dou sau mai multe alternative n cadrul unor activiti inteligente. Materia prim de baz prelucrat n cadrul activitilor inteligente este cunoaterea, care reprezint conceptul fundamental pentru dezvoltarea sistemelor inteligente. Reprezentarea i procesarea datelor i cunoaterii reprezint obiectul apariiei i dezvoltrii a dou tehnologii de importan major n informatic [1]:
144

Tehnologia bazelor de date; Tehnologia sistemelor inteligente. n timp ce tehnologia bazelor de date are n vedere memorarea, ntreinerea i accesarea unor volume mari de date, tehnologia sistemelor inteligente este axat pe rezolvarea unor probleme complexe n diverse domenii care necesit expertiz uman, fiind ns restricionat de domenii bine delimitate i ineficient pentru procesri numerice i gestiunea unor volume mari de date. Cele dou tehnologii la ora actual distincte, tind s evolueze convergent n cadrul conceptului de sistem informaional inteligent care presupune elaborarea unui model unificat date-cunotine. n acest sens, sistemele de baze de date au n vedere exprimarea semanticii n schemele lor conceptuale i capacitatea de infereniere (baze de date deductive), iar sistemele bazate pe cunotine tind s rezolve probleme care reclam baze de cunotine (fapte i reguli) din ce n ce mai mari. Pentru exploatarea maxim a celor dou resurse informaionale, bazele de date i bazele de cunotine, nu este suficient doar cuplarea sistemelor de gestiune a bazelor de date cu sistemele expert prin intermediul unor interfee n cadrul aplicaiilor, fiind necesar proiectarea fiecreia din cele dou componente ca o extensie natural a celeilalte astfel nct mpreun s conduc la realizarea unui sistem integrat. n acest sens cercetrile sunt ndreptate n urmtoarele direcii: dotarea SGBD cu instrumente suplimentare de structurare i manipulare avnd n vedere semantica datelor (un pas important n aceast direcie l constituie bazele de date deductive); dotarea sistemelor expert cu instrumente care s permit accesarea i manipularea eficient a informaiei stocate n bazele de date; valorificarea informaiei din bazele i depozitele de date prin tehnici de analiz multidimensional i data mining. 7.2. Categorii de sisteme inteligente n realizarea sistemelor inteligente s-au conturat urmtoarele abordri principale: sisteme expert bazate pe reguli, n care cunotinele sunt reprezentate prin reguli de producie; sisteme bazate pe reele neuronale, n care baza de cunotine este creat automat de un algoritm de nvare plecnd de la o mulime de exemple de nvare, baza de cunotine este implicit reprezentat de ponderile conexiunilor dintre neuroni i nu exist o baz de cunotine explicit ca n abordarea bazat pe reguli; sisteme multiagent care sunt sisteme distribuite formate dintr-o colecie de ageni autonomi care interacioneaz ntr-un mediu comun. Avantajele i dezavantajele fiecreia dintre abordri sunt complementare i de aceea s-au definit modele mixte (hibride) care combin avantajele celor trei tipuri de sisteme.

145

7.2.1. Sisteme expert bazate pe reguli Sistemele expert sunt sisteme informatice care stocheaz cunotinele dintr-un domeniu bine precizat i au capacitatea de a realiza expertize de o calitate apropiat de a celor realizate de experii umani. ntr-un sistem expert bazat pe reguli pot fi evideniate urmtoarele componente: o baz de cunotine explicit constituit din o baz de fapte i o baz de reguli; motorul de inferene; interfaa utilizator. O categorie aparte de sisteme expert bazate pe reguli o reprezint sistemele expert generalizabile sau generatoarele de sisteme expert care sunt acele sisteme expert care conin motorul de inferene, sistemul de gestiune al bazei de cunotine, interfaa de comunicaie cu utilizatorul, dar a cror baz de cunotine este vid. Generatoarele de sisteme expert [53], [27], [22] sunt sisteme bazate pe reguli de producie, capabile de a stoca diverse cunotine reprezentate prin reguli i de a deduce cu ajutorul acestora i a valorilor unor fapte precizate de utilizator, noi cunotine. 7.2.2. Sisteme bazate pe reele neuronale (sisteme conexioniste) Un sistem conexionist const dintr-o reea de elemente de tip neuron interconectate, care realizeaz anumite funcii logice simple. ntr-un astfel de sistem informaia este memorat difuz n toat reeaua, fiind reprezentat de ponderile conexiunilor sinaptice dintre neuronii reelei. O caracteristic important a reelelor neuronale este capacitatea de a nva din exemple i de a construi algoritmul de rezolvare a unei probleme pornind de la mulimea de exemple de instruire i regula de modificare a ponderilor interneuronale. Prelucrarea informaiei n sistemele neuronale const n efectuarea unor calcule numerice (calcul matriceal) prin care n faza de nvare se urmrete descoperirea relaiilor existente ntre intrrile i ieirile unui set de exemple de instruire, relaii ce vor fi ulterior utilizate pentru prelucrarea unor seturi noi de date de intrare n vederea clasificrii lor. Pot fi astfel analizate seturi mari de date, din care unele pot fi incerte sau incomplete, pentru a identifica caracteristicile i gruparea lor n clase fr a cunoate apriori regulile de aplicat, reguli ce vor fi deduse de sistem n faza de instruire prin procesarea numeric a datelor. Instruirea reelei poate fi reactualizat prin utilizarea unor noi seturi de date de instruire. Un inconvenient al acestor sisteme este faptul c procesul de raionament nu poate fi explicat iar cunotinele nu sunt reprezentate explicit. Pentru soluionarea unor probleme complexe , reelele neuronale pot fi combinate, n cadrul unui sistem integrat, cu alte tehnologii printre care: baze de date, sisteme expert, data mining, etc. n cadrul aplicaiilor de tip data mining, reelele neuronale pot fi utilizate pentru identificarea corelaiilor din bazele de date n vederea descoperirii unor "abloane" (patterns) semnificative n structura datelor i extragerea informaiilor predictive ascunse din bazele mari de date. n ultimii ani, reelele neuronale artificiale sunt utilizate cu succes pentru rezolvarea unor probleme complexe printre care: procesarea limbajului natural, robotica, vederea artificial i procesarea semnalelor, recunoaterea scrisului de mn, sisteme de sprijinire a deciziei.

146

7.2.3. Sisteme multi-agent. Definiie, clasificare, arhitecturi. Un sistem multi-agent (SMA) este [SIMA98] un sistem distribuit format dintr-o colecie de ageni autonomi care interacioneaz ntr-un mediu comun, fiecare agent avnd cunotine, capaciti de aciune i scopuri proprii. Funcie de tipurile de ageni utilizai se pot identifica dou categorii de sisteme multi-agent inteligente i anume: SMA cu ageni cognitivi, numite i sisteme multi-agent cognitive; SMA cu ageni reactivi, numite i sisteme multi-agent reactive. Sistemele multi-agent cognitive urmresc s simuleze aspecte ale comportamentului uman prin tratarea noiunilor de scop, cooperare, competiie, organizare n structuri sociale i stabilirea relaiilor de dependen n aceste structuri, capacitate de nvare i auto-perfecionare. Un sistem multi-agent cognitiv reprezint un sistem particular bazat pe cunotine ce conine o reprezentare simbolic a cunotinelor despre lumea n care evolueaz fiind capabil s ia decizii prin intermediul unui proces inferenial de raionament. ns, spre deosebire de un sistem bazat pe cunotine clasic, n cadrul unui sistem multi-agent, un agent reprezint simbolic lumea att prin convingeri, care sunt preri despre lume, eventual incomplete sau eronate, ct i prin cunotine care reprezint fapte adevrate despre acea lume. De asemenea, un agent trebuie s fie capabil s raioneze att despre propriile lui convingeri i cunotine ct i despre cele ale celorlali ageni cu care interacioneaz ntr-un anumit mediu. Abordarea cognitiv a agenilor, ridic o serie de probleme critice n special referitor la complexitatea de calcul i dificultatea algoritmilor necesari prelucrrilor simbolice. Un sistem multi-agent reactiv este un sistem n care agenii sunt uniti simple de prelucrare, capabile s reacioneze la schimbrile de mediu i s execute aciuni simple corespunztor acestor schimbri. Un astfel de sistem este inspirat din organizarea i activitatea comunitilor biologice de insecte. Astfel, o albin nu poate fi considerat inteligent ns comportamentul stupului n ansamblu i modul de organizare a albinelor, executnd aciuni comune i coordonate n vederea realizrii scopului, prezint elemente de inteligen. Adepii sistemelor multi-agent reactive, criticnd abordarea cognitiv, consider c inteligena este situat n lumea exterioar i nu la nivelul componentelor de prelucrare individuale, respectiv agenii, comportarea inteligent fiind un rezultat al interaciunii dintre ageni i mediu, iar inteligena este o proprietate a sistemului ca ntreg. n acest sens, au fost propuse sisteme cu arhitecturi care modeleaz structura i comportamentul colectivitilor de insecte, sisteme care ar putea fi realizate ntr-o abordare subsimbolic utiliznd reele neuronale sau algoritmi genetici. O alt direcie de cercetare o constituie abordarea mixt cognitiv-reactiv avnd n vedere avantajele i dezavantajele fiecreia dintre cele dou categorii de sisteme multiagent. Arhitecturi pentru sisteme multi-agent Arhitectura BDI (Belief, Desire, Intention) este arhitectura unui sistem multi-agent care conine o reprezentare explicit a convingerilor, dorinelor i inteniilor agentului. Convingerile reprezint informaiile pe care un agent le are despre mediul n care evolueaz sau despre ceilali ageni din sistem i acestea pot fi adevrate sau false. Dorinele sunt lucrurile pe care agentul ar dori s le realizeze, ns nu trebuie neaprat s
147

acioneze pentru ndeplinirea tuturor dorinelor sale. Inteniile sunt lucrurile pe care agentul le are n vedere spre realizare sau s-a angajat s le realizeze. O arhitectur a unui sistem multi-agent se numete deliberativ dac se bazeaz pe reprezentarea explicit a unui model simbolic i pe manipularea de simboluri. Astfel de arhitecturi corespund de obicei sistemelor multi-agent cognitive. O arhitectur reactiv este arhitectura unui sistem multi-agent n care nu se folosete un model simbolic pentru reprezentarea cunotinelor i nu exist raionament simbolic. ntr-o astfel de arhitectur, agenii sunt reprezentai prin uniti de prelucrare simple iar inteligena sistemului este emergent din interaciunea unitilor de prelucrare cu mediul. 7.2.4. Sisteme inteligente hibride Pentru definirea conceptului de sistem inteligent hibrid, reamintim pentru nceput c n domeniul inteligenei artificiale au aprut i se dezvolt o serie de tehnologii de vrf enumerate n cele ce urmeaz: sisteme expert bazate pe reprezentarea simbolic a cunotinelor (sisteme expert bazate pe reguli); reele neuronale artificiale (sisteme conexioniste); sisteme fuzzy; algoritmi genetici; strategii de evoluie i programarea evolutiv (algoritmi evolutivi); ageni inteligeni; sisteme multiagent (inteligena artificial distribuit). Sistemele inteligente n care sunt integrate cel puin dou din tehnologiile menionate mai sus sunt cunoscute sub denumirea de sisteme inteligente hibride, iar tehnologia utilizat n vederea integrrii este denumit tehnologia fuziunii. Fiecare din tehnologiile dezvoltate n domeniul inteligenei artificiale prezint avantaje i dezavantaje i nu pot fi utilizate singular pentru rezolvarea unor probleme complexe care se pun astzi n tiin, tehnic, economie i societate. Aceast afirmaie este susinut i de faptul c n procesarea uman a informaiei i cunoaterii sunt implicate diverse reprezentri arhitecturale, creierul avnd pe de o parte o structur neuronal, iar pe de alt parte capacitatea de a opera cu simboluri i de a efectua raionamente simbolice, de a prelucra date imprecise sau incomplete. Un domeniu de mare interes n care agenii se vor impune spectaculos este Internet-ul, care permite astzi accesul direct a milioane de oameni pe autostrada informaional ( Internet Society estimeaz c exist peste 30 de milioane de utilizatori care acceseaz zilnic reeaua Internet), care pot fi att consumatori ct i poteniali furnizori de informaie. Cutarea informaiei despre un anumit subiect necesit identificarea i investigarea unui numr mare de documente de pe Web, operaii mari consumatoare de timp i care pot fi realizate de ageni competeni numii ageni Internet. Pentru a asigura accesul tuturor categoriilor de utilizatori, indiferent de calificare i cunotinele de care dispun, la resursele informaionale imense de pe Internet, viitoarea generaie de ageni Internet va fi o combinaie de modele cognitive i reactive, avnd ca

148

scop att satisfacerea necesitii de informare a utilizatorului ct i transparena total a autostrzii informaionale. Dei reeaua Internet reprezint un mare succes n unificarea resurselor informaionale, structura sa actual n care pot fi identificate dou straturi i anume: utilizatorii (consumatorii) de informaie i productorii (furnizorii) de informaie, nu este adecvat pentru activitatea de informare care presupune prelucrarea complex a informaiilor din multiple documente de pe Web independent de utilizator. Pentru rezolvarea acestei probleme, una din cele mai promitoare propuneri este modelul n care activitile desfurate pe Internet sunt mprite pe trei straturi, denumit [73] modelul celor 3 straturi i anume: 1. un strat pentru utilizatorii de informaie (clienii informaionali) definete cererea de informaie; 2. un strat pentru furnizorii (productorii) de informaie definete oferta de informaie; 3. un nou strat aflat ntre primele dou, denumit stratul de mijloc sau stratul intermediarilor, care s permit conectarea primelor dou straturi prin cele mai bune ci sau modaliti. n cadrul acestui model, agenii au un rol important difereniat pe straturi dup cum urmeaz: sarcinile agenilor n cadrul primului strat sunt de a afla ce informaii caut utilizatorii, dac au anumite preferine n legtur cu informaia de care au nevoie, etc.; n cadrul celui de-al doilea strat sarcinile agenilor sunt de a face un inventar al serviciilor i informaiilor oferite de ctre furnizori, de a ine evidena noilor informaii adugate n reea, etc.; agenii din stratul de mijloc au rolul de intermediari informaionali ntre utilizatorii informaionali (umani sau electronici) i furnizorii de informaii, sarcina lor fiind de mediere ntre agenii celorlalte dou straturi. Agenii utilizai ntr-un astfel de model vor trebui concepui n baza unor standarde general acceptate, astfel nct s rspund i s reacioneze n acelai mod prin utilizarea unui set standardizat de coduri suficient de flexibil pentru a permite construirea unor ageni pentru sarcini neateptate sau imprevizibile n prezent. Referitor la domeniile de utilizare a tehnologiei agenilor n viitor, cercettori n domeniu cred [73] c agenii autonomi vor deveni n urmtorii 10 ani parte integrant a celor mai multe sisteme de afaceri. Astfel, cei de la IBM prevd o vast utilizare a agenilor software n e-commerce: Crem o nou categorie economic (a new economic species), parial asemntoare nou ca imagine, dar semnificativ diferit de oameni, Agenii software vor deveni actori n economie, afirm Jeff Kephart, managerul grupului care se ocup de fenomenul agenilor.

149

Capitolul 8. Studii de caz - Arhitecturi de sisteme informatice


8.1. Model de date georelaional n cadrul unui sistem informatic geografic distribuit cu aplicaii n domeniul cadastrului Modele de date utilizate n sistemele informatice geografice (GIS) Dac pn nu demult, tehnologiile GIS s-au dezvoltat independent de tehnologia bazelor de date, structurile de date fiind tratate exclusiv prin instrumente proprii fiecrui produs GIS, n ultimii ani se impune integrarea celor dou tehnologii astfel nct un sistem GIS s poat beneficia de rezultatele obinute n domeniul bazelor de date. n acest sens, n prezent pe piaa sistemelor GIS sunt utilizate [78] urmtoarele modele de date: modelul hibrid, modelul integrat, modelul orientat obiect. Modelul hibrid (model georelaional) utilizeaz un set de fiiere pentru stocarea coordonatelor i a informaiei topologice i un sistem SGBD (Oracle, Informix, Ingres, Sybase, Access) pentru stocarea datelor descriptive n tabele. Schema unui astfel de model este reprezentat n figura 8.1.

Fiiere de date spaiale: coordonate puncte descriere topologie

Identificator de legtur

Baza de date relaional: - tabele de date descriptive

Sisteme care se bazeaz 8.1.acest model printre care: ARC/INFO al firmei ESRI, Figura pe Model de date georelaional IDGS i GEOMEDIA ale firmei INTERGRAPH, MGE al firmei Bentley MicroStation, sunt reprezentative n domeniu, impunndu-se pe piaa utilizatorilor de sisteme GIS. Sistemul prezentat n acest capitol al lucrrii este realizat pe baza acestui model. Modelul de date integrat este bazat pe reprezentarea i procesarea datelor grafice i descriptive n cadrul unui SGBD relaional. Acest mod de tratare prezint limitri privind tipurile de date, ns are n vedere posibilitatea extinderii SGBD-ului cu noi tipuri de date i cu noi faciliti de interogare SQL. n acest sens, firme importante n domeniul bazelor de date, printre care Oracle, au dezvoltat n cadrul produselor lor SGBD componente specializate pentru reprezentarea i accesarea datelor spaiale. Schema modelului de date integrat este reprezentat n figura 8.2. BAZA DE DATE RELAIONAL

Tabele de date grafice

Tabele de date descriptive

Concatenare relaional

Figura 8.2. Model de date integrat

150

ntr-un astfel de model apar probleme de normalizare la asocierea perechilor de coordonate cu elementele grafice corespunztoare. odelul de date orientat obiect se bazeaz pe tehnologia orientat obiect, ns prezint dezavantaje ntruct nu exist un limbaj de interogare standard iar sistemele orientate obiect sunt nc n stadiu incipient. Model de date georelaional n domeniul cadastrului Registrul cadastrului conine 3 categorii de informaii: informaii tehnice, informaii juridice, informaii economice. Raportat la modul de prelucrare, informaiile se grupeaz n: date descriptive (textuale) i date grafice (spaiale). Organizarea, descrierea i prelucrarea datelor cadastrale necesit utilizarea unui produs de tip GIS (Geographical Information System) care s ofere: un nucleu grafic pentru reprezentarea i prelucrarea datelor grafice, un sistem de gestiune a bazelor de date, comunicarea ntre cele dou componente ale sistemului. Potrivit legii cadastrului general i publicitii imobiliare, cadastrul general se organizeaz la nivelul fiecrui teritoriu administrativ comunal, orenesc, municipal, judeean i la nivel naional. Documentele tehnice principale ale cadastrului general, ce se vor ntocmi la nivelul comunelor, oraelor i municipiilor sunt: registre cadastrale (parcele, proprietari, corpuri de proprietate) planuri cadastrale i hri topografice. Datele din registrele cadastrale privind terenurile i construciile vor fi reprezentate grafic n planuri cadastrale i hri topografice.

Figura 8.3. Schema general a modelului georelaional La nivel de jude se vor organiza i vor funciona bazele de date ale cadastrului general interconectate, iar la nivel naional banca de date a cadastrului general. n cadrul modelului sunt avute n vedere entitile de baz, nivelele de abordare, categoriile de date, dup cum este ilustrat n figura 8.3. n cele ce urmeaz sunt descrise structurile de date definite n cadrul modelului
151

georelaional. Date descriptive PARCELE (descriere parcele): CODJ cod jude, CODL cod localitate, CODP cod parcel (perimetru, parcela), DENP denumire parcel, ADRESA adresa parcelei (strada, nr.), CATF cod categorie de folosin, TIPP tip proprietate, PCADP partida cadastral a parcelei, SUPP suprafaa parcelei, DOTARI dotarea edilitar a parcelei (A-ap, C-canal, G-gaze, E-electricitate), VALE valoare economic. CATFOL (definire dicionar categorii de folosin): CATF cod categorie de folosin, DENCF denumire categorie de folosin. TIPPROP (definire dicionar tipuri de proprietate): TIPP cod tip proprietate, DENTP denumire tip proprietate. SUBPARC (descriere subparcele): CODJ cod jude, CODL cod localitate, CODP cod parcel, CODSP , cod (numr) subparcel, CATF cod subcategorie de folosin, SUPSP suprafaa subparcelei. ISTORIAP (istoric parcele): CODJ cod jude, CODL cod localitate, CODP cod parcel (perimetru, parcela), DENP denumire parcel, ADRESA adresa parcelei (strada, nr.), CATF cod categorie de folosin, TIPP tip proprietate, PCADP partida cadastral a parcelei, SUPP suprafaa parcelei. PART_CADP (relaia PARCELE-PROPRIETARI): PCADP partida cadastral a parcelei, CODPROP cod proprietar, CODDET cod deintor, COTA cota indiviz (%). CONSTRUCTII (descriere corpuri cldire): CODJ cod jude, CODL cod localitate, CODP cod parcel de amplasare a construciei, IDCORP identificator corp cldire, DENCORP denumire corp cldire, PCADC partida cadastral a construciei, TIPP tip proprietate, DEST destinaia cldirii, FOL folosina cldirii, SUPS suprafaa la sol, NRNIV numr nivele, SUPD suprafaa desfurat, DOTARI dotarea edilitare (A-ap, Ccanal, G-gaze, T-telefon, E-electricitate), FUNDAT fundaie, PERETI perei, ANCON anul construirii, SEISM grad de rezisten la seisme. PART_CADC (relaia CONSTRUCTII-PROPRIETARI): PCADC partida cadastral, CODPROP cod proprietar, CODDET cod deintor, COTA cota indiviz (%). JUDETE (lista judee): CODJ cod jude, DENJ denumire jude. LOCALITATI (lista localiti): CODJ cod jude, CODL cod localitate, DENL denumire localitate. ARTERE (artere, strzi): CODJ cod jude, CODL cod localitate, CODA cod arter

152

(strad), DENA denumire arter (strad). POSESORI (PERSOANE, AGENTI - persoane sau ageni economici i sociali, proprietari sau deintori de terenuri i construcii): CODPOS cod posesor, DENPOS nume posesor, Adresa de domiciliu (CODJ cod jude, CODL cod localitate, CODA cod strad, NR numr potal, BLOC blocul, SCARA scara, ETAJ etajul, AP apartamentul ). Date grafice (spaiale) COORDONATE (fiier .xyz pentru descriere puncte msurate n teren): CODP cod parcel de amplasare a construciei, IDCORP identificator corp cldire sau spaii pentru parcele, NRP numr punct, X abscisa punctului, Y ordonata punctului, Z cota punctului. CONTUR (fiier .con pentru descriere entiti grafice): CODP cod parcel de amplasare a construciei, IDCORP identificator corp cldire sau spaii pentru parcele, TIPC tip contur (0-deschis, 1-nchis), LAYER strat sau cod culoare umplere contur, NRP1 NRP2 NRP10 identificare puncte consecutive pe contur. O alt categorie de date este constituit din imagini raster reprezentnd fiiere imagine obinute prin scanare planuri cadastrale i hri topografice, care pot constitui surse de date grafice obinute prin operaia de vectorizare. Date de sintez Pentru realizarea unor situaii de sintez n baza de date se definesc vederi ca spre exemplu: TSPCF total suprafee pe categorii de folosin CREATE VIEW TSPCF(CATF,TSUP) AS SELECT CATF, SUM(SUPP) FROM PARCELE GROUP BY CATF TSPLCF total suprafee pe localiti defalcat pe categorii de folosin CREATE VIEW TSPLCF(CODL,CATF,TSUP) AS SELECT CODL, CATF, SUM(SUPP) FROM PARCELE GROUP BY CODL, CATF TSPJ total suprafee pe judee CREATE VIEW TSPJ(CODJ,TSUP) AS SELECT CODJ, SUM(SUPP) FROM PARCELE GROUP BY CODJ TSPJL total suprafee pe judee defalcat pe localiti CREATE VIEW TSPJL(CODJ,CODL,TSUP) AS SELECT CODJ, CODL, SUM(SUPP) FROM PARCELE GROUP BY CODJ,CODL TSPTP total suprafee pe tipuri de proprietate CREATE VIEW TSPTP(TIPP,TSUP) AS SELECT TIPP, SUM(SUPP)
153

FROM PARCELE GROUP BY TIPP TSPJCON total suprafa construcii pe judee CREATE VIEW TSPJCON(CODJ,SUPS,SUPD) AS SELECT CODJ,SUM(SUPS),SUM(SUPD) FROM CONSTRUCTII GROUP BY CODJ Interconectarea bazelor de date n baza de date a cadastrului sunt utilizate o serie de informaii proprii altor sisteme de eviden i anume: sistemul de eviden a populaiei, sistemul de eviden a unitilor teritorial administrative, sistemul de eviden a agenilor economici i sociali. Comunicarea ntre aceste sisteme informaionale este reprezentat n schema din figura 8.4.

POPULAIE
proprietate

CADASTRU
- Parcele - Construcii
localizare

UNITI TERITORIAL ADMINISTRATIVE


- judee - localiti - strzi (artere)

AGENI ECONOMICI I SOCIALI

- Proprietari/deintori

Figura 8.4. Schema de comunicare ntre sistemele de eviden Distribuirea datelor este o caracteristic comun fiecruia din cele patru sisteme de eviden. Datele proprii altor sisteme i utilizate n sistemul cadastrului vor trebui, fie reproduse, fie utilizat o alt metod de accesare a acestora. n cele ce urmeaz este prezentat o astfel de metod de accesare a unor date stocate n baze de date diferite, proprie sistemului de gestiune a bazelor de date ORACLE i anume crearea i utilizarea referinelor dblink [ORA92]. n figura 8.5 este reprezentat schema de comunicare ntre bazele de date aferente sistemelor de eviden utilizate. B.D. POPULATIE
LEGCP

B.D. AGENTI
LEGCA

B.D. COMUNITATI
LEGCC

B.D. CADASTRU 154 Figura 8.5. Schema de comunicare ntre bazele de date ale sistemelor de eviden

Referirea, n baza de date CADASTRU, a unor date din bazele de date POPULATIE, AGENTI, COMUNITATI aflate pe servere diferite eventual la distan fa de baza de date solicitant (CADASTRU), se poate reliza prin elementele dblink denumite LEGCP, LEGCA, LEGCC care se creaz cu comenzi avnd sintaxa: CREATE DATABASE LINK <nume dblink> CONNECT TO <nume utilizator> IDENTIFIED BY <parola utilizator> USING <server B.D. Oracle> unde <nume utilizator>, <parola utilizator>, <server B.D. Oracle> sunt date de identificare pentru bazele de date referite (POPULATIE, AGENTI, COMUNITATI). Accesul la date din bazele de date referite se realizeaz prin instruciuni SELECT astfel: SELECT <lista cmpuri> FROM <nume tabel>@<nume dblink> WHERE <condiie>. Astfel, dac se presupune c din structurile de date definite mai sus, tabela PERSOANE este definit n baza de date POPULATIE, tabela AGENTI este definit n baza de date AGENTI, tabelele JUDETE, LOCALITATI, ARTERE sunt definite n baza de date COMUNITATI, iar celelalte tabele sunt definite n baza de date CADASTRU, pentru a obine lista tuturor proprietarilor (persoane fizice) de terenuri pe suprafee i categorii de folosin din localitatea SUCEAVA (CODJ = 33, CODL = 5800) i adresele de domiciliu ale acestora plecnd de la baza de date CADASTRU i interconectarea acesteia cu bazele de date POPULATIE i COMUNITATI, se va utiliza schema de interogare reprezentat n figura 8.6. Comanda SQL pentru realizarea interogrii reprezentat n schem este: SELECTA.Codp,A.Catf,A.Supp,C.Denpos,D.Denj,E.Denl,F.Dena,C.Nr,C.Bloc, C.Scara,C.Etaj,C.Ap FROM PARCELE A, PART_CADP B, PERSOANE@LEGCP C, JUDETE@LEGCC D, LOCALITATI@LEGCC E, ARTERE@LEGCC F WHERE PART_CADP A.Codj PARCELE AND A.Codl = 5800 AND A.Pcadp = B.Pcadp AND B.Codpos = = 33 = Pcadp Pcadp C.Codprop AND C.Codj = Codj = 33 AND C.Codl = E.Codl AND C.Coda = F.Coda D.Codj Codj Codprop Codl = 5800 ORDERCodl C.Denpos BY
Codprop = Codpos

==

PERSOANE Codpos Codj Codl Coda


=

JUDETE - Codj

LOCALITATI - Codl 155

ARTERE - Coda

Figura 8.6. Schem de interogare a bazelor de date interconectate 8.2. Sistem informatic geografic distribuit pentru reprezentarea digital i monitorizarea zonelor expuse inundaiilor Introducere Lucrarea prezint un sistem GIS, pentru reprezentarea digital, monitorizarea i evaluarea computerizat a efectelor asupra zonelor expuse inundaiilor datorate revrsrii apelor curgtoare sau accidentelor la construciile hidrotehnice. Lucrarea este destinat proteciei civile la nivelul unui jude (Inspectoratul pentru Situaii de Urgen) sau a unui bazin hidrografic i dispeceratului S.G.A. corespunztor (judeean sau bazinal), pentru monitorizarea zonelor expuse, elaborarea planurilor de aprare i a variantelor de aciune n lupta mpotriva inundaiilor, fenomenelor meteorologice periculoase i a accidentelor la construciile hidrotehnice. Zonele expuse inundaiilor vor putea fi descrise prin reprezentri sub form de rapoarte (tabele, situaii) i prin reprezentri grafice constnd din planuri, hri, schie, hidrografe, imagini, la diverse nivele: ap curgtoare, amenajare hidrotehnic, localitate, bazin hidrografic, jude. Pentru realizarea reprezentrii digitale sunt preluate i prelucrate date descriptive (alfanumerice) i date grafice. Datele sistemului Datele descriptive sunt organizate ntr-o baz de date relaional ce poate fi creat i administrat utiliznd, la alegere, un SGBD relaional, ca de exemplu FoxPro sau Oracle, funcie de performanele sistemului de calcul i a sistemului de operare utilizat. Structura bazei de date se definete prin ncrcarea tabelelor dicionar ceea ce confer flexibilitate referitor la datele utilizate n sistem. Baza de date alfanumerice este un ansamblu de tabele ce conin date privind: apele curgtoare; bazinele hidrografice; localitile expuse inundaiilor; staiile hidrologice i staiile hidrometrice; cote zonale de aprare; staiile meteorologice i posturile pluviometrice; amenajrile (construciile) hidrotehnice; obiectivele periclitate; comisiile de aprare mpotriva inundaiilor; stocurile de materiale i mijloace de aprare existente;

156

suprafeele de teren, pe categorii de folosin, din cadrul localitilor; niveluri, debite, temperaturi, precipitaii msurate i arhivate n istoric. La structura definit pot fi adugate noi tabele i cmpuri n tabelele deja existente prin simpla redefinire a tabelelor dicionar. Datele grafice sunt organizate astfel: fiiere imagine pentru reprezentare imagini, reprezentri raster rezultate prin scanare; fiiere de contur i fiiere de coordonate asociate pentru reprezentri de tip vector. O reprezentare grafic (desen) este constituit n acest caz dintr-un ansamblu de entiti grafice i este coninut ntr-un fiier .con i fiierul de coordonate .xyz asociat. Entitile grafice sunt grupate pe straturi (layere) care pot fi redate n ansamblu sau selectiv. Corespondena ntre fiierele de date grafice i reprezentrile aferente este definit n catalogul reprezentrilor care conine i denumirea explicit a acestora. Dac la preluarea datelor se stabilesc legturi ntre informaia grafic i informaia alfanumeric, modulul de reprezentare grafic permite accesarea informaiei corespunztoare din baza de date alfanumerice la selectarea fiecrui obiect grafic din desen. Reprezentri Sistemul realizat este orientat pe documente (reprezentri), fiecare dintre ele avnd asociat cte o nregistrare din catalogul de reprezentri aferent aplicaiei. ntr-o intrare din acest catalog sunt memorate informaii caracteristice respectivei reprezentri, i anume: nume, list de produse cu care se poate prelucra/vizualiza i fiierul/fiierele specifice ei (cu precizarea cii de acces la fiier(e)). Pentru fiecare dintre produsele folosite pentru a prelucra/vizualiza diversele reprezentri aferente sistemului, exist cte o intrare asociat ntr-un catalog de produse, ce conine informaii specifice produsului, i anume: numele i comanda de lansare n execuie (eventual cu parametri). Acest mod de tratare deschis a reprezentrilor, orientat pe documente i nu pe produse, asigur o mare flexibilitate i permite o extindere uoar, prin posibilitatea introducerii de reprezentri recunoscute de produse ce nu fac parte din sistem. n cele ce urmeaz sunt formulate exemple de reprezentri ce pot fi realizate: Reprezentarea hrii sistemului informaional hidro-meteorologic i operativ la nivelul unui bazin hidrografic sau a unui jude (fig. 8.7). Reprezentarea reelei hidrografice prin planuri i hri la scara precizat de utilizator cu posibilitatea de redare pe ecran, la imprimant, la plotter; Elaborare reprezentri la nivel de bazin hidrografic avnd n vedere rul principal i afluenii, localitile i categoriile de teren traversate, delimitarea zonelor inundabile, amenajrile i construciile hidrotehnice, posturile hidrometeorologice, comisiile de aprare mpotriva inundaiilor etc (fig. 8.8); Realizarea planurilor de situaie a luncilor inundabile;
157

Reprezentarea planei coninnd comandamentele, comisiile locale i staiile hidrometrice aferente, pentru aprarea mpotriva inundaiilor, la nivelul unui bazin hidrografic sau a unui jude; Reprezentarea, la nivelul unui bazin hidrografic sau a unui jude, a zonelor n care se ating sau se depesc pragurile critice de aprare mpotriva inundaiilor; Reprezentarea 3D a zonelor expuse calamitilor, la nivelul unui bazin hidrografic sau a unui jude, cu evidenierea reelei hidrografice, formelor de relief, cilor de acces, zonelor inundate funcie de cotele apelor; Reprezentri grafice prin planuri, hri, schie, imagini pentru fiecare construcie hidrotehnic; Reprezentare profile transversale n planuri de situaie; Reprezentarea hidrografelor undelor de viitur; Realizare planuri tematice la nivel de ap curgtoare, bazin hidrografic, jude; Realizare planuri la scar precizat cu localizarea obiectivelor, delimitarea zonelor inundabile, dispozitivele hidro-meteorologice folosite pentru stabilirea valorilor caracteristice locale de aprare i indicarea zonelor de evacuare. Dintre reprezentrile formulate anterior, harta sistemului informaional hidrometeorologic i operativ este documentul grafic care definete sistemul informaional hidro-meteorologic, la scara unui ntreg bazin hidrografic sau jude. n cadrul sistemului anumite informaii sunt constante n timp sau n flux lent (reeaua hidrografic, staiile hidro-meteorologice, amenajrile hidrotehnice etc.), iar altele sunt variabile sau n flux rapid (niveluri, debite, temperaturi etc.), acestea din urm neputnd fi reprezentate n cadrul hrii. Spre deosebire de harta clasic, reprezentarea digital ofer posibilitatea reprezentrii n timp real a sistemului hidro-meteorologic, evideniind modificrile ce au loc privind datele n flux rapid, date a cror cunoatere, prelucrare i interpretare n timp util prezint o importan hotrtoare n lupta mpotriva inundaiilor, fenomenelor meteorologice periculoase i accidentelor la construciile hidrotehnice. Avnd n vedere volumul i diversitatea informaiilor necesare pentru reprezentarea digital, entitile grafice sunt grupate pe straturi, ce vor putea fi reprezentate independent sau combinat, la scar precizat, raportate la suprafaa unui ntreg jude sau bazin hidrografic, sau parial, pe zone selectate. Un exemplu de astfel de grupare n reprezentarea sistemului informaional hidro-meteorologic i operativ este prezentat n cele ce urmeaz: reeaua hidrografic ce traverseaz suprafaa bazinului sau judeului; amenajrile hidrotehnice (baraje, lacuri de acumulare, amenajri piscicole, aduciuni, consolidri maluri, regularizri i ndiguiri); localiti; bazine hidrografice; ci de comunicaie (drumuri, strzi, ci ferate, poduri); reele tehnico edilitare (reele electrice, reele de alimentare cu ap, reele de canalizare, reele telefonice, reele de gaze etc.);
158

terenuri pe categorii de folosin; curbe de nivel; staii hidro-meteorologice; comisii locale de aprare; lunci inundabile.

Fig. 8.7. Reprezentarea hrii sistemului informaional hidro-meteorologic i operativ

159

Fig. 8.8. Reprezentare localiti, staii hidrometrice, cote, debite

160

Structura produsului software Produsul software realizat pentru reprezentarea digital i monitorizarea zonelor expuse inundaiilor este constituit din dou componente realizate n tehnologie GIS i anume: componenta GEO-MAP; componenta HIDRO-MAP. Componenta GEO-MAP Componenta GEO-MAP trateaz reprezentarea informaiei grafice vectoriale ataat informaiei alfanumerice i interogarea acesteia prin planuri i hri i a informaiei raster rezultat prin scanare precum i reprezentarea de informaie vector suprapus peste informaie raster. Din punct de vedere structural aceast component este constituit din urmtoarele module: Modulul de administrare a bazei de date, dezvoltare proiecte; Modulul CAD; Modulul de interogare a bazei de date; Modulul de interfaare cu tipul de SGBD utilizat. Modulul de administrare a bazei de date i de dezvoltare proiecte creeaz suportul pentru funcionarea ntregului sistem, toate celelalte module ale componentei GEO-MAP utiliznd informaiile coninute n fiierele create n cadrul acestui modul. n cadrul acestui modul este definit proiectul, sunt completate cataloagele cu informaii despre tabelele utilizate, este definit structura tabelelor, relaiile dintre tabele, cheile de acces, view-urile, regulile pentru legtura cu obiectele grafice corespondente. Modulul CAD realizeaz urmtoarele funcii: afiarea grafic a desenului; ncadrarea obiectelor grafice n fereastra utilizator; umplerea cu culoare a obiectelor grafice; afiarea desenului conform setrii straturilor; reprezentare simboluri; asigurare interfee I/O. n cadrul modulului CAD utilizatorul i stabilete fereastra activ, scara, straturile, poziia i dimensiunile ferestrei n care va fi reprezentat informaia grafic. Modulul CAD realizeaz reprezentarea simbolisticii n cadrul planurilor sau hrilor precum i interfeele cu plottere, imprimante, fiiere .DXF, digitizoare etc. Modulul de interogare a bazei de date preia i trimite comenzi de interogare de tip SQL ctre modulul de interfaare cu tipul de SGBD utiliznd structurile definite n cadrul modulului de administrare a bazei de date (cataloage, tabele, relaii, reguli) i ctre modulul CAD pentru accesarea informaiei grafice. Legtura dintre obiectele grafice i nregistrrile asociate din baza de date se realizeaz utiliznd textul ce reprezint numele obiectului grafic i asigur comunicarea ntre modulul de interogare a bazei de date i

161

modulul CAD. Textele reprezentnd numele obiectelor grafice pot fi constituite din valori ale unuia sau mai multor cmpuri din tabele corespunztoare n baza de date i sunt compuse sau descompuse automat n baza regulilor definite de utilizator n tabelele dicionar ce descriu baza de date. Astfel la o interogare dinspre modulul de interogare a bazei de date. regula corespunztoare va permite concatenarea informaiei dispersate n mai multe cmpuri, crend un ir de caractere ce va fi utilizat n modulul CAD pentru identificarea obiectului grafic corespunztor. La o interogare dinspre modulul CAD o astfel de regul permite mprirea irului de caractere, reprezentnd numele obiectului grafic, n cmpuri pentru a completa cheia de acces la nregistrarea bazei de date. n cazul interogrii pe criterii se aplic aceeai regul, ns vor fi baleiate toate nregistrrile a bazei de date i toate obiectele grafice pentru a fi evideniate prin colorare acele obiecte grafice care au ndeplinit criteriile precizate n cererea SQL de interogare formulat de utilizator. Produsul pune la dispoziia utilizatorului un mediu asistat pentru formularea cererilor de interogare facilitnd astfel comunicarea ntre modulul de interogare a bazei de date i modulul de interfaare cu tipul de SGBD. n abordarea acestei problematici s-au avut n vedere dou variante de SGBD-uri: xBase i client/server. Abordrile au fost difereniate datorit inexistenei pseudotabelelor de tip vedere (view) n cadrul bazei de date xBase. Componenta de tip vedere este o component practic indispensabil n cadrul sistemelor GIS i din acest motiv a trebuit creat prin software i simulat, lund n considerare elementele ce definesc tabela de acest tip. Modulul de interfaare cu tipul de SGBD face independent aplicaia GIS de SGBD-ul utilizat. Utilizarea unui anumit SGBD presupune existena unui modul program specific pentru citirea i interpretarea dicionarelor definite n cadrul modulului de administrare a bazei de date. n acest sens sunt realizate module program pentru SGBD-uri de tip xBase (dBASE, FoxPro etc.). Prin realizarea unor proceduri similare pentru alte tipuri de SGBDuri ca de exemplu Oracle, SQL Server etc. produsul devine independent de SGBD-ul utilizat. S-a adoptat aceast soluie pentru a putea beneficia de tehnici oferite de diverse SGBD-uri privind: optimizarea accesului; tehnologii client / server; administrarea distribuit; metode de protecie a datelor. Fiecare modul comunic cu celelalte module prin comenzi i mesaje de rspuns sau coduri de eroare, avnd ca referin fiierele ASCII create prin modulul de administrare a bazei de date. i dezvoltare de proiecte. Valorile de cmpuri pentru relaii, irurile de caractere pentru identificare obiecte precum i secvena SQL de interogare sunt generate automat prin selecie din meniuri popup i selecie de obiecte grafice cu mouse-ul.

162

Componenta HIDRO MAP Componenta HIDRO-MAP realizeaz: monitorizarea zonelor expuse inundaiilor la nivel de: jude, bazin hidrografic, zon; determinarea i reprezentarea zonei inundate funcie de cotele apelor msurate n dou staii consecutive: simularea zonelor inundate la formarea i propagarea viiturilor; elaborarea de planuri de protejare, recuperare i evaluare. Monitorizarea zonelor expuse inundaiilor const din: reprezentarea hrii vectoriale a sistemului informaional hidro-meteorologic; reprezentarea informaiei n flux rapid prin evidenierea zonelor n care se ating sau depesc pragurile critice (cote de avertizare, cote de inundare, cote de pericol etc. ); reprezentare hidrografe pentru cote sau debite la un punct de msurare (staie) selectat. Componenta folosete ca instrument de lucru harta sistemului informaional hidrometeorologic i operativ, scanat i digitizat n cadrul componentei GEO-MAP, asupra creia se pot realiza operaii de scalare, deplasare, interogare punctual, utiliznd principiile i funciile definite n cadrul componentei GEO-MAP. Reprezentarea variaiei anumitor parametri (cote, debite, precipitaii etc.) este realizat n cadrul hrii sistemului, asigurnd astfel localizarea zonelor monitorizate. Semnalizarea punctelor n care se ating sau se depesc pragurile critice se realizeaz sonor i prin colorarea elementului grafic corespunztor. Achiziia datelor hidro-meteorologice n flux rapid, de la posturile i staiile de observaie i msurare, rspndite pe teritoriul judeului sau a bazinului hidrografic, este realizat n cadrul unui modul ce funcioneaz independent de celelalte module din cadrul componentei HIDRO-MAP. Pentru achiziia datelor n flux rapid (cote, debite, temperaturi, precipitaii etc.) sunt avute n vedere urmtoarele abordri: transmiterea datelor de la punctele (staiile) de msurare la dispeceratul judeean sau bazinal (SGA), prin reeaua de comunicaie (T, RT), unde sunt preluate n baza de date prin tastare; transmiterea datelor on-line pe interfaa serial, prin microcontrolere amplasate n punctele de transmisie (staii hidrologice, staii hidrometrice, staii meteorologice i posturi pluviometrice); utilizarea unor staii automate pentru achiziia i transmiterea datelor. n versiunea actual sunt tratate primele dou modaliti de achiziie i transmitere a datelor, urmnd ca n perspectiv, n msura dotrii cu echipamente specializate, s fie tratat i cea de-a treia modalitate.
163

Pentru fiecare staie selectat, se poate solicita reprezentarea hidrografului, care evideniaz variaia unui anumit parametru (cot, debit etc.) pe o perioad de timp precizat sau pentru un numr de msurtori, putndu-se totodat vizualiza ultimele valori achiziionate pentru parametrul reprezentat. Sistemul hidro-meteorologic i operativ este reprezentat la nivelul hrii digitale ncrcate la startarea componentei HIDRO-MAP. Fa de harta obinuit (instrumentul de lucru al SGA-urilor), aceast reprezentare conine i o component dinamic, prin faptul c asigur o imagine n timp real a situaiei hidro-meteorologice pentru zona aflat sub observaie. n cadrul fiecrei reprezentri, obiectele grafice sunt grupate pe straturi (layere) putnd fi redate n totalitate sau parial (cele activate) pentru ntreaga reprezentare sau pentru o zon selectat cu posibilitatea de mrire, micorare i redactare la scar precizat.

Determinarea i reprezentarea zonei inundate funcie de cotele apei msurate n dou staii hidrometrice consecutive Modelul elaborat n acest sens se bazeaz pe utilizarea de profile transversale realizate prin msurtori sau generate asistat n diverse puncte de pe traseul cursului de ap. Implementarea modelului propune parcurgerea a dou faze i anume: generarea asistat de profile transversale; determinarea i reprezentarea zonei inundate. Generarea asistat de profile transversale pe traseul cursului de ap se realizeaz prin modelarea digital a terenului utiliznd curbele de nivel i (eventual) puncte intermediare de cot cunoscut reprezentate n planul utilizat ca document de intrare, plan care a fost n prealabil digitizat prin componenta GEO-MAP. Exist posibilitatea trasrii de noi curbe de nivel prin interpolare numeric. Generarea unui profil transversal printr-un punct P prin modelarea digital a terenului este ilustrat n figura 8.9.

164

Fig. 8.9. Generarea unui profil transversal

n exemplul ilustrat se constat c numrul punctelor PDi, PSi determinate pentru profilul transversal prin P este mult superior n cazul existentei unor puncte de cote cunoscute (marcate cu x n exemplul dat) fa de cazul cnd s-ar utiliza doar curbe de nivel. Cotele punctelor P pe cursul apei se determin prin interpolare numeric. Punctele ce definesc profilele transversale generate asistat i cele realizate prin msurtori se vor memora urmnd a fi utilizate ori de cte ori se cere determinarea i trasarea zonei inundate. Pentru determinarea zonei inundate cunoscnd cotele apei n dou staii succesive din amonte spre aval se determin cotele apei n punctele de generare profile transversale prin metoda interpolrii numerice presupunnd panta uniform ntre cele dou puncte de msurare. Pentru fiecare punct P se determin punctul din stnga i cel din dreapta de cot egal cu cota punctului P. Zona inundat este definit de banda rezultat prin unirea punctelor stnga ntre ele i unirea punctelor dreapta determinate. Peste zona astfel determinat i reprezentat ca obiect grafic (culoare albastru) se vor suprapune i alte straturi reprezentnd obiective inundate, ci de acces etc. (vezi figura 8.10). Cele trei zone aferente cotei de atenie, inundare, evacuare pot fi marcate distinct n cadrul aceleai reprezentri.

165

Fig. 8.10. Determinarea zonei inundate utiliznd profile transversale i cotele apei msurate n staia amonte i staia aval Elaborarea de planuri de protejare, recuperare i evaluare Aplicaia de elaborare de planuri de protejare, recuperare i reabilitare a zonelor afectate de calamiti este lansat n momentul cnd se recepioneaz un semnal de pericol de inundaii de la calculatorul ce monitorizeaz staiile de culegere automat a datelor meteorologice i hidrologice. Odat lansat, aplicaia afieaz pe ecran i/sau tiprete la imprimant: list cu persoanele cu putere de decizie n coordonarea aciunilor de salvare i modul cum pot fi contactate; numrul de persoane ce trebuie evacuate; reprezentarea zonelor de evacuare i a traseelor de evacuare; listele cu unitile i formaiunile de protecie civil ce trebuie s intervin i modul cum pot fi contactai membrii acestora; depozitele de materiale i locul de parcare a mijloacelor de transport cu care se va interveni n operaiunile de salvare, tipul i capacitile acestora. Dup ce comisiile abilitate n evaluarea pagubelor au cules date suficiente pentru a putea ntocmi rapoarte statistice se pot afia i/sau tipri rapoarte privind: numrul familiilor i persoanelor fr adpost; numrul familiilor i persoanelor cu locuine avariate; suprafaa inundat; suprafaa de cultur distrus i/sau compromis; distrugerile n obiective industriale; kilometri de drumuri i ci ferate avariate; reelele distruse, valoarea pagubelor total i pe seciuni. Produsul software realizat poate fi un instrument util pentru protecia civil (ISU) la nivelul unui jude sau a unui bazin hidrografic i a dispeceratului S.G.A. corespunztor, pentru monitorizarea zonelor expuse inundaiilor, elaborarea planurilor de aprare i a
166

variantelor de aciune n lupta mpotriva inundaiilor, fenomenelor meteorologice periculoase i a accidentelor la construciile hidrotehnice. n perspectiv, pe msura dotrii cu echipamente adecvate, vor putea fi avute n vedere: utilizarea unor staii automate pentru achiziia i transmiterea datelor; transmiterea i recepia datelor n cadrul unor reele de calculatoare; utilizarea unor instrumente de prognoz i simulare asistat elaborate de institutele de profil din ar; elaborarea asistat a variantelor de aciune pentru protecia civil. 8.3. Sistem bazat pe cunotine destinat documentrii i cercetrii asistate n genetica vegetal Resursele genetice vegetale reprezint toate formele de via din domeniul vegetal: plantele slbatice, formele vechi cultivate, soiurile i populaiile locale, buruienile, formele ameliorate, etc. Asigurarea securitii alimentare n condiiile exploziei demografice impune pstrarea resurselor genetice vegetale, n mod deosebit a celor ameninate cu dispariia i identificarea de noi specii dintre cele slbatice, susceptibile s devin noi plante de cultur. Se impune astfel colectarea, evaluarea i conservarea resurselor genetice vegetale, n acest scop fiind create o serie de instituii i organisme naionale i internaionale: Bnci de gene, Institutul Internaional de Resurse Genetice Vegetale (IPGRI) cu sediul la Roma, Comitetul Naional de Resurse Genetice Vegetale etc. Conservarea resurselor genetice vegetale se face pe de o parte prin pstrarea lor n habitatele n care s-au format i au evoluat (conservare in situ), iar pe de alt parte prin pstrarea n instituii special create n acest sens i anume: bnci de gene i grdini botanice (conservare ex situ). Cea mai evoluat form de conservare a resurselor genetice vegetale se realizeaz n bncile de gene care sunt instituii dotate cu instalaii ce asigur temperatura de conservare i cu laboratoare, echipamente i aparatur necesare caracterizrii i evalurii materialului genetic conservat. n acest sens n 1990 a fost nfiinat Banca de Resurse Genetice Vegetale Suceava care are n componen o cldire ce ocup o suprafa de 3550 metri ptrai pentru laboratoare, birouri, oficiul de calcul, un compartiment pentru uscarea seminelor, o camer de cretere a culturilor in vitro, staia frigorific i depozitul pentru conservarea probelor. Cmpul experimental al bncii are o suprafa de 1,250 ha din care 1 ha teren arabil i 0,250 ha ocupate de 7 sere nenclzite. Activitatea de colectare a resurselor genetice vegetale i n special a populaiilor de porumb la Suceava dateaz nc din anii 50, ns adevrata activitate tiinific a nceput din 1987 odat cu fondarea Bncii de Gene Suceava. Principalele obiective ale Bncii de gene Suceava sunt explorarea i colectarea, evaluarea i conservarea resurselor genetice vegetale. 8.3.1. Organizarea datelor n cadrul sistemului informatic Datele privind materialul genetic conservat n Banca de Resurse Genetice Vegetale Suceava sunt stocate ntr-o baz de date care descrie intrrile, reprezentnd soiuri,

167

populaii, linii, hibrizi, obinute din culturi, flora spontan, donaii, schimb etc. Intrrile (probele) stocate n banca de gene aparin unor specii de plante, fiecare specie fiind descris de un numr de atribute (descriptori). Datele descriptive pot fi nsoite de imagini reprezentnd planta, smna, frunza, etc., sau alte imagini obinute prin analize microscopice. Corespunztor activitilor de colectare, evaluare i depozitare (conservare) probe (intrri) n banca de gene se vor obine date de paaport, date de evaluare i date de conservare. Datele de paaport i datele de conservare (fia de depozit) sunt comune tuturor speciilor, iar caracterizarea i evaluarea difer de la o specie la alta i rezult din prelucrri statistice efectuate asupra datelor obinute din msurtori experimentale i analize de laborator efectuate asupra unui numr de probe. Cu alte cuvinte activitile de colectare i depozitare probe sunt descrise de aceleai atribute pentru toate speciile, iar caracterizarea i evaluarea sunt descrise de atribute diferite de la o specie la alta. Pentru fiecare din cele trei tipuri de date sunt prezentate, n cele ce urmeaz, cteva exemple cu meniunea c n definirea structurii datelor trebuie avut n vedere posibilitatea adugrii de noi descrieri (structur evolutiv). Date de paaport: Nr.intrare, Denumire intrare, Clasificare taxonomic (Genul, Specia, Subspecia, Varietatea), Originea (Localitatea, Judeul (zona), ara), Data colectrii, Sursa colectrii, Date geografice (Altitudine, Latitudine, Longitudine) Date de de conservare: Cod depozit, Numr prob, Germinaia, Stoc de semine, Umiditatea, Masa a 1000 boabe Date de evaluare (ex. pentru specia zea mays): Locul evalurii (ara, Instituia de cercetare, Persoana care a fcut evaluarea), Date despre plant (nlimea total a plantei, Diametrul mediu al tulpinii, Numrul total de frunze), Msurtori la tiulete (Lungimea, Diametrul la baz, Diametrul la vrf, Numrul de rnduri de boabe, Greutatea tiuletelui, ). Fiecare soi din cadrul unei specii va fi definit de valori corespunztoare ale atributelor ce definesc specia respectiv. Din exemplele prezentate se poate constata c descrierea materialului genetic conservat n banca de gene reprezint preponderent cunotine a cror prelucrare se poate realiza n cadrul unui sistem bazat pe cunotine, care s conin componente de interfa cu limbaje de programare de nivel nalt, sisteme de gestiune a bazelor de date, i anumite aplicaii de inteligen artificial. n modelul de date relaional o structur extensibil a bazei de date este definit de urmtoarele scheme de relaie (tabele): SPECII (Cod_s, Denumire_s) -catalogul speciilor de plante DESCRIPTORI (Cod_d, Denumire_d, Tip_d) lista atrib unde: Tip_d = 1 colectare, 2 evaluare, 3 - conservare D_SPECII (Cod_s, Cod_d) definire specii INTRARI (Cod_s, Cod_i, Denumire_i) lista intrrilor (soiurilor) pe specii D_INTRARI (Cod_i, Cod_d, Val_d) definire intrri A_GEN (Cod_fiu, Cod_parinte) genealogii intrri (arbori genealogici) n aceast reprezentare, definirea entitilor n baza de date se realizeaz prin ncrcarea tabelelor de mai sus, deci structura bazei de date este o structur evolutiv cu

168

un grad ridicat de generalitate, care se extinde dinamic prin simpla ncrcare a tabelelor bazei de date.

SPECII SPEC_SOI SOI_GEN GEN_SOI GENEALOGIE SPEC_DES

SOIURI

DESCRIPTORI

SOI_VAL

n figura 8.12. sunt ilustrate activitile de colectare, evaluare i depozitare intrri Fig. 8.11. Diagrama structurii datelor n Banca de gene i nregistrarea datelor rezultate n registre i n baza de date .

VALORI

DES_VAL

169

Colectare, evaluare i depozitare probe


Culturi SPECII INTRRI (probe) din: Flora spontan Donaii Schimb Linii Populaii Soiuri Hibrizi

nregistrare date

Gru Porumb

Fasole Orz .

Colectare probe

Date de paaport Registre

Laboratoare Evaluare probe

Date experimentale

nregistrare date Culturi in vitro Date de evaluare


Prelucrri statistice

Depozit Conservare probe Ierbar

Baza de date
Date de conservare

Fig. 8.12. Activiti desfurate n Banca de Resurse Genetice Vegetale Suceava

170

Pentru documentare privind materialul genetic conservat n banca de gene se pot formula urmtoarele cereri de interogare a bazei de date: catalogul speciilor de plante, descriere specie precizat, lista intrrilor aparinnd unei specii, raport documentar intrare (descriere intrare) precizat, genealogie intrare (arborele genealogic), lista intrrilor ce satisfac condiii precizate n momentul interogrii. Arborele genealogic poate fi reprezentat, fie printr-o descriere de forma: Intrarea i provine din: - i1 - i2 i2 provine din: - i21 - i22 i21 provine din: - i211 - i212 , fie grafic printr-o structur arborescent ilustrat n figura 8.13. Astfel de descrieri pot fi realizate prin interogri ale bazei de date cu ajutorul unor proceduri de tip recursiv.
Intrare i

i1

i2

i21

i22

Descriptorii utilizai pentru datele de conservare sunt specifici Bncii de gene i211 i212 Suceava i definesc urmtoarele date: numrul de intrare, codul de depozit, genul, specia, subtaxa, ara de origine, luna depozitrii, anul depozitrii, anul ultimei renmuliri, anul Fig. 8.13. Reprezentare grafic arbore genealogic numrul de ultimei germinaii, stocul, umiditatea, masa a 1000 semine, (genealogie renmuliri; intrare) Descriptorii ce definesc datele de paaport sunt cei recomandai de Institutul Internaional de Resurse Genetice Vegetale IPGRI cu sediul la Roma, sunt preluai n

171

baza de date n limba englez i exist posibilitatea accesrii datelor de paaport privind materialul genetic conservat n banca de gene, prin reeaua Internet [74]. 8.3.2. Arhitectura unui sistem bazat pe cunotine n genetica vegetal Mediile de dezvoltare ale sistemelor bazate pe cunotine existente la ora actual au componente de interfa cu limbaje de programare de nivel nalt, orientate pe obiecte, sisteme de gestiune a bazelor de date, etc., iar anumite aplicaii de inteligen artificial sunt dezvoltate n limbaje cum ar fi C, Prolog, ADA, etc. n acest context, componentele principale ale unui sistem bazat pe cunotine n genetica vegetal sunt: Crearea i administrarea bazei de date, Interogarea bazei de date, Prelucrarea statistic a datelor, Aplicaii de inteligen artificial. Datele i cunotinele ce urmeaz a fi memorate i prelucrate n cadrul unui sistem n domeniul geneticii vegetale refer soiuri aparinnd unor specii de plante de cultur i din flora spontan care sunt supuse fenomenului de eroziune genetic i agresiunii factorilor patogeni (fitopatologia) i factorilor de mediu. Descrierea plantelor i experimentele efectuate n domeniul vegetal genereaz dou categorii de date i anume: 1. date descriptive, 2. date experimentale. Datele ce descriu materialul genetic (datele descriptive) sunt preponderent cunotine care vor fi reprezentate n baza de date n cadrul unei structuri evolutive de date de tip universal. Aceste date pot fi nsoite de imagini (plant, frunz, rdcin, smn, etc.). n studiul organismelor vii se impune a se face deosebire ntre caracteristicile observabile (ceea ce se vede) i ceea ce determin (cauzeaz) aceste caracteristici deoarece s-a constatat c dou organisme ce rezult din acelai printe, deci care au aceeai ereditate, pot avea aspecte morfofiziologice diferite dac condiiile de via sunt diferite. n acest sens, pentru a defini deosebirile existente ntre organisme cu aceeai origine i cu aceeai ereditate dar deosebite n ceea ce privete aspectul corpului, n 1909 genetistul danez W.Johannsen a definit conceptele de genotip i fenotip astfel [15]: genotipul reprezint totalitatea genelor i plasmagenelor (suma total a informaiei genetice) dintr-un organism; fenotipul reprezint totalitatea caracteristicilor (proprietilor) unui organism la un moment dat (dimensiuni, comportare, form, culoare, funcii fiziologice, compoziie chimic, structur intern sau extern, microscopic sau macroscopic, etc.) rezultate prin interaciunea dintre genotip i mediul n care se dezvolt organismul respectiv. Fiecare caracteristic a unui organism este determinat de anumite gene i n timp ce fenotipul se modific pe parcursul vieii organismului respectiv, genotipul este relativ constant (un organism are aceleai gene pe tot parcursul vieii). Corespunztor celor dou concepte, n structura bazei de date a sistemului bazat pe cunotine n genetica vegetal, se va descrie genotipologia respectiv fenotipologia. Avnd n vedere faptul c fiecare specie este caracterizat de un anumit numr de cromozomi, genele sunt particule materiale ce ocup poziii stabile n cromozomi fiind aranjate n ordine liniar de-a lungul cromozomului ca mrgelele ntr-un irag, s-a reuit s se ntocmeasc hri ale cromozomilor la diverse specii. Un exemplu de reprezentare a unei hri genetice este
172

ilustrat n figura 8.14 care red harta genetic pentru specia Orz, realizat n cadrul modelului virtual al orzului, de H.Buck-Sorlin (1999-2002) utiliznd vlab (laborator virtual n botanic) care a fost realizat de Przemyslaw Prusinkiewicz bazat pe L-systems (o parte a unui limbaj de rescriere propus de biologul olandez Aristid Lindenmayer n1968). Tabelul T.8.3.1. conine toate genele care afecteaz lungimea tulpinii i alte aspecte ale morfologiei plantei. Pentru fiecare gen este prezentat simbolul, descrierea i ncadrarea sa n una din cele apte grupe de cromozomi (7H, 2H, 3H, 4H, 1H, 6H, 5H) [76].

a)

b)

Fig. 8.14. Reprezentare hart genetic pentru specia Orz [EVAM99] a) reprezentare grupe de cromozomi; b) reprezentare gene T8.3.1. Identificare gene [76]
Symbol brh1 brh2 clh cud 2 cud1 hcm lzd min nld sdw1 sdw2 Description Brachytic 1 Brachytic 2 Curled leaf dwarf (s.a. leaf mutants and curly mutants) Curly dwarf 2 (s.a. leaf mutants and curly mutants) Curly dwarf 1 (s.a. leaf mutants and curly mutants) Short culm Lazy dwarf Semi-minute dwarf 1 Narrow leafed dwarf (s.a. leaf mutants) Semidwarf 1 Semidwarf 2 Chr 7H 4H 1H 1H 5H 2H 3H 4H 5H 3H 3H

173

sid sld sld 2 uzu wnd Zeo1

Single internode dwarf slender dwarf 1 Slender dwarf 2 Uzu or semi brachytic Winding dwarf (s.a. curly mutants) Zeocriton 1

4H 3H 2H 3H 7H 2H

174

O alt categorie de informaii care poate fi prevzut n baza de date i cunotine a sistemului o reprezint descrierea codului genetic avnd n vedere compoziia fiecrei gene. n cele ce urmeaz este definit o reprezentare simbolic a codului genetic conform [15]. Dup cum afirma E. Schrdinger nc din 1956 Filamentul cromozomic cuprinde, cifrat ntr-un fel de cod miniatural, ntreaga devenire a organismului, ntreaga sa dezvoltare i funcionare Structurile cromozomice dein, de asemenea, mijloacele de a executa acest program.. n segmentul de ADN i ARN viral corespunztor fiecrei gene, mesajul este nregistrat prin combinarea unor simboluri asemntor alfabetului Morse, fiind utilizate n acest sens urmtoarele 4 simboluri chimice corespunztoare celor 4 baze azotate: A(adenina), G(guanina), C(citozina) si T(timina) sau U(uracilul) la ribovirusuri, care intr n constituia macromoleculei de ADN (A,G,C,T) sau a macromoleculei de ARN (A,G,C,U). Cele patru simboluri formeaz alfabetul. Din combinarea simbolurilor aa cum n sistemul Morse se obin cuvintele, n sistemul genetic se formeaz codonii, iar din asocierea cuvintelor aa cum n sistemul Morse rezult frazele, n sistemul genetic din asocierea codonilor rezult genele. Codul genetic reprezint corespondena dintre grupele de nucleotizi din moleculele de acizi nucleici din gene i aminoacizii inclui n proteinele sintetizate de ctre acestea. Toat informaia genetic a unui organism este coninut ntr-un grup linkage (un cromozom la bacterii i virui) sau n dou sau mai multe grupe linkage (doi sau mai muli cromozomi) la celelalte organisme. Avnd n vedere faptul c exist 20 aminoacizi care intr n compoziia proteinelor, rezult c o secven de 3 simboluri (din cele patru) poate realiza codificarea celor 20 de aminoacizi (un simbol poate codifica doar 4 aminoacizi, o secven de dou simboluri poate codifica 42=16 aminoacizi, iar numrul total de secvene de 3 simboluri este 43=64 combinaii posibile). Din cei 64 codoni, 61 reprezint codoni cu sens (semnific un anumit aminoacid) iar trei reprezint codoni nonsens. Din cei 61 codoni cu sens, 2 se numesc codoni de iniiere (AUG, GUG) i se afl la nceputul fiecrui mesaj genetic. Codonii nonsens sunt UAA, UAG, UGA i au rolul de a indica separarea genelor, fiind numii din acest motiv i codoni stop. Cercetrile complexe efectuate de F. H. C. Crick i colaboratorii si nc din anii 60 au condus la urmtoarea concluzie: codul genetic este reprezentat prin codoni (triplete formate plecnd de la cele 4 simboluri) cu meniunea c doi codoni succesivi nu se suprapun (nu au nici un nucleotid comun), ntre codoni nu exist semne speciale care s marcheze nceputul sau sfritul codonului (nu exist virgule biochimice), iar o gen este o secven de codoni care ncepe i se sfrete cu semne speciale, citirea genei fcndu-se liniar de la nceputul spre sfritul ei. Dup cum afirma J. D. Watson (1974), o gen de dimensiune medie conine 900 perechi de nucleotizi (obinuit ntre 600 i 1800) mprit n 300 de codoni (triplei de baze, fiecare triplet codificnd un aminoacid), deci mrimea medie a unei proteine este de 300 aminoacizi.(obinuit ntre 200 i 600). Avnd n vedere aspectele prezentate mai sus, precum i rezultate obinute la nivel mondial se poate concluziona c o reprezentare ct mai complet a informaiilor privind
175

genomul la nivel de specie poate fi realizat n cadrul unui SGBD cu faciliti de orientare spre obiecte. n contextul problemelor prezentate, arhitectura general a unui sistem bazat pe cunotine pentru documentare i cercetare asistat n genetica vegetal este reprezentat n schemele din figurile 8.15, 8.16.

176

Fig 8.15. Schema general a unui sistem bazat pe cunotine n genetica vegetal

178

179

Fig 8.16. Schema bazei de date

180

8.3.3. Probleme specifice cercetrii Probleme specifice cercetrii, tratate n cele ce urmeaz, n cadrul sistemului bazat pe cunotine n genetica vegetal sunt: recunoaterea populaiilor i clasificarea lor; diagnosticarea rezistenei plantelor la boli. Recunoaterea populaiilor i clasificarea lor n activitatea de conservare a resurselor genetice vegetale n banca de gene, o atenie deosebit este acordat populaiilor locale deoarece acestea constituie un important material iniial de ameliorare. n acest sens, cercetrile n domeniu vizeaz: recunoaterea populaiilor i clasificarea lor; determinarea relaiei dintre mrimea populaiei de reproducere i particularitile genetice ale descendenilor la anumite specii (exemplu porumb); determinarea corelaiilor dintre caracteristici i valorile optime ale unor parametri pentru obinerea unor soiuri cu anumite caracteristici prestabilite. Problemele de clasificare i recunoatere pot fi soluionate prin metode specifice domeniului inteligenei artificiale (recunoatere forme, baze de cunotine i sisteme expert, reele neuronale), iar problemele de optimizare, prin definirea i utilizarea unor modele regresionale. Clasificarea i recunoaterea populaiilor de porumb Avnd n vedere diversitatea porumbului i lipsa unor criterii clare de demarcare ntre formele existente n cadrul genului Zea mays pentru care polenizarea este ncruciat i deci exist un schimb genic continuu ntre populaii, au existat numeroase ncercri de clasificare nc din perioada introducerii porumbului n Europa. Sistemele de clasificare cele mai rspndite aparin lui Sturtevant (1899) reprezentant de frunte al clasificrii artificiale i lui Anderson i Cutler (1942) reprezentani ai sistemului natural de clasificare. Deoarece clasificarea artificial a lui Sturtevant se bazeaz pe puine informaii, nefiind oglindite relaiile filogenetice, exist posibilitatea ca unele forme diferite filogenetic s fie incluse n aceeai grup sau forme asemntoare filogenetic s fie incluse n grupe diferite. Clasificarea natural a lui Anderson i Cutler se bazeaz pe ntreaga constituie genetic, pe studii genetice, citologice, fiziologice, agronomice i arheologice, fiind mult mai elastic i mai complex, oferind posibilitatea includerii ntregii varieti a porumbului, ns mult mai greu de abordat avnd n vedere volumul mare de informaii ce trebuie luat n considerare. n clasificarea natural a porumbului se utilizeaz noiunea de ras ca unitate taxonomic de baz. Din punct de vedere genetic, rasa poate fi considerat ca un grup de indivizi care au un numr semnificativ de gene n comun. Rasele majore au un numr mai mare de gene n comun dect subrasele. La nivel superior rasei se situeaz complexul rasial care poate fi definit ca un grup de rase cu caracteristici distinctive

comune: morfologice, biologice i de areal. La nivel inferior rasei se afl populaiile locale care sunt grupuri de indivizi, care se deosebesc de indivizii celorlalte populaii ce compun rasa, prin una sau mai multe nsuiri de detaliu. Folosirea conceptului de ras n clasificarea natural a porumbului trebuie s porneasc de la faptul c rasele trebuie considerate ca grupuri mari i orice analiz a elementelor rasiale trebuie s fie n primul rnd o analiz a grupurilor i nu a unor indivizi izolai. Avnd n vedere faptul c la porumb fa de alte plante de cultur, polenizarea este ncruciat i deci procesul de eroziune genetic este mai accentuat, n perioada 19751985 la Staiunea de Cercetri Agricole Suceava s-au efectuat experimente i evaluri pentru soiurile de porumb Hngnesc, Cincantin, Suceava 1, din care a rezultat un important fond de date reprezentnd valorile msurate pentru 30 de descriptori (date de evaluare) pentru fiecare variant de nmulire. n cadrul experimentelor efectuate s-au utilizat 20 de variante de nmulire, fiecare variant fiind particularizat de numrul de mame i numrul de tai folosii la nmulire. Dintre caracteristicile ce definesc soiurile de porumb, s-au luat n considerare acele caracteristici (descriptori) care difer de la o variant la alta (30 parametri) i anume: Msurtori la plant: nlimea total a plantei Numrul total de frunze .. Msurtori la tiulete: Lungimea tiuletelui Greutatea tiuletelui Diametrul tiuletelui la baz .. Msurtori la bob Lungime bob Lime bob Grosime bob .. Prelucrarea acestor date viza soluionarea urmtoarelor probleme: 1. determinarea variantei de nmulire cea mai apropiat de soiul martor; 2. determinarea variantei optime de nmulire pentru pstrarea caracterelor soiului martor. ntruct prin prelucrri statistice nu s-au obinut rspunsuri satisfctoare la ntrebrile puse, s-a optat pentru utilizarea unor instrumente ale inteligenei artificiale. Problemele de clasificare i recunoatere sunt rezolvate prin tehnici specifice recunoaterii formelor. n cadrul Subsistemului de Recunoaterea formelor, fiecare intrare n banca de gene reprezint o form iar mulimea descriptorilor ce descriu specia respectiv, sau o

182

submulime a lor (datele de evaluare) prin valorile ce definesc intrarea respectiv reprezint mulimea caracteristicilor formei. De asemenea fiecare din variantele de nmulire utilizate n cadrul experimentelor efectuate reprezint o form. Pentru clasificarea i recunoaterea formelor se utilizeaz programul REFORME realizat de autori. Prin utilizarea tehnicilor de recunoaterea formelor se obin ieiri n diverse reprezentri printre care: liste, grafice, ce descriu apartenena la o clas, gruparea n clase. n cele ce urmeaz sunt prezentate rezultate obinute prin utilizarea subsistemului de Recunoaterea formelor pentru experimentele cu soiul Hngnesc. Fiecare form este reprezentat pe un rnd n foaia de calcul Excel dup cum este ilustrat n figura 8.17. Descrierea soiului martor este redat n figura 8.18. Datele de intrare sunt normalizate prin metoda ajustrii domeniului (figura 8.19). Dup efectuarea unei clasificri nesupervizate utiliznd algoritmul de prag cu distana euclidian, pentru valoare prag = 1.5, se obine rezultatul ilustrat n figura 8.20. Se poate constata c cele 100 forme au fost grupate n 4 clase, 85% din forme fiind repartizate n clasa 0.1. La determinarea clasei cele mai apropiate de soiul martor prin regula celui mai apropiat vecin se obine clasa 0.1. i varianta la distana minim fa de soiul martor prezentat descriptiv n figura 8.21. n figura 8.22 sunt reprezentate soiul martor i varianta la distana minim de martor raportat la valorile celor 30 de descriptori.

Fig. 8.17. Date iniiale (1 martor, 100 variante de nmulire)

183

Fig. 8.18. Valorile caracteristicilor pentru soiul martor

Fig. 8.19. Date184 iniiale normalizate

Fig. 8.20. Clasificare nesupervizat prin algoritmul de prag cu distan euclidian

Fig. 8.21. Varianta la distana minim de martor

185

Fig. 8.22. Reprezentarea soiului martor i a variantei cele mai apropiate de soiul martor

186

8.4. Sistem telematic pentru managementul on-line al zonelor intravilane degradate datorit depozitrii necontrolate a deeurilor 8.4.1. Introducere Lucrarea prezint realizri n cadrul proiectului de cercetare CEEX Sistem telematic pentru managementul on-line al zonelor intravilane degradate ZoneMAP n cadrul programului INFOSOC n perioada 15.09.2006 30.08.2008. Obiectivul general al proiectului ZoneMAP const n realizarea unui sistem telematic pentru managementul i monitorizarea on-line a zonelor intravilane degradate datorit depozitrii necontrolate a deeurilor, prin elaborarea unui sistem electronic de poziionare geografic GPS/GIS. Autorii lucrrii au participat la realizarea urmtoarelor componente ale sistemului: definirea arhitecturii generale a sistemului; proiectarea bazei de date a sistemului. Lucrarea se nscrie n aria tematic Tehnologii informaionale i de comunicaii, care reprezint una din temele prioritare n cadrul programului de cercetare i dezvoltare tehnologic PC 7 pentru anii 2007-2013. Programul de localizare geografic a zonelor afectate din punct de vedere ecologic, utiliznd tehnologiile GPS / GIS st la baza sistemului integrat de asistare electronic a deciziilor n domeniul proteciei zonelor intravilane. Drept criteriu de selecie a metadatelor s-a ales riscul antropic asupra spaiului intravilan, risc generat de depozitarea necontrolat a deeurilor urbane. Lucrarea de fa ofer suportul pentru controlul localizrii i monitorizrii depozitelor ilegale de deeuri i poate fi utilizat ca tehnologie multimedia pentru furnizarea de informaii referitoare la zonele afectate de poluarea antropic. Lucrarea prezint soluiile tehnice, metodologice i tehnologice pentru implementarea modelelor de producii economic eficiente i sntoase pentru mediu, promovate prin managementul integrat al deeurilor. Se vizeaz dezvoltarea nivelului de educaie i contientizare a cetenilor n domeniul conservrii resurselor i managementului deeurilor pentru protecia mediului intravilan prin generarea de alternative civic atractive n spiritul dezvoltrii durabile i accesarea unor module de informare. Obiectivul principal al lucrrii const n monitorizarea zonelor afectate de depozitarea necontrolat a deeurilor prin utilizarea celor mai noi tehnologii informaionale i de comunicaii prin elaborarea unui sistem electronic de poziionare geografic GPS/GIS. Gestionarea deeurilor, component important a oricrei strategii de mediu, se refer la activitile de colectare, transport, tratare, valorificare i eliminare a acestora. Datele privind gestionarea deeurilor n Romnia fac distincie ntre dou categorii importante de deeuri: deeuri municipale i asimilabile din comer, industrie i instituii, deeuri din construcii i demolri i nmoluri de la staiile de epurare oreneti; deeuri de producie Prin culegerea automat a datelor de mediu, meteorologice i ecologice, se urmrete realizarea unui sistem de monitoring, dotat cu senzori i/sau traductori, capabili

187

s msoare i s traduc (n semnale electrice) mrimi cu caracter meteorologic (cum sunt: intensitatea radiaiei solare, temperatura, umiditatea, .a.), dar i mrimi de stare ale sistemului ecologic (ex. concentraii de nutrieni n ap i sol, poluani n aer, ap si sol, pH, biomase). Mrimile astfel achiziionate sunt convertite n valori numerice ce vor fi stocate n baza de date a sistemului. Avnd n vedere faptul c datele de mediu sunt achiziionate periodic (la diverse intervale de timp), baza de date a sistemului este o baz de date temporal, ceea ce nseamn c pe lng datele curente, baza de date conine i date istorice, iar factorul (atributul) timp are un rol esenial. n cadrul sistemului telematic pentru managementul on-line al zonelor intravilane degradate sunt definite urmtoarele categorii de date: date privind gestionarea deeurilor (zone intravilane monitorizate, deeuri, surse de poluare, depozite deeuri, staii de prelucrare deeuri ; date privind protecia mediului (parametri calitate mediu: ap, aer, sol); date spaiale (hri tematice). Baza de date a sistemului este o baz de date distribuit pe urmtoarele nivele: serverul central de baze de date (SQL server Microsoft); serverele locale de baze de date (Microsoft ACCESS). Organizarea, descrierea i prelucrarea datelor spaiale necesit utilizarea unui produs de tip GIS. Sunt disponibile pe pia mai multe soluii printre care: ArcINFO de la ESRI, AutoCAD Map de la Autodesk, GEOMEDIA de la INTERGRAPH, care sunt produse realizate n S.U.A. i au un pre relativ ridicat. Exist ns i soluii realizate n Romnia (de exemplu, NetSET de la Data Invest i MapSys de la Geotop) al cror pre este mai accesibil. Este avut n vedere pachetul NetSET, care ofer un foarte bun raport ntre pre, performane i faciliti oferite, acoperind practic toate aspectele dezvoltrii aplicaiilor GIS. n plus, lucreaz cu hri vectoriale n format shape, compatibil la nivel internaional cu alte pachete de programe similare. 8.4.2. Definirea arhitecturii generale a sistemului Sistemul este compus din mai multe (sub)sisteme telematice, denumite staii locale, legate att ntre ele ct i cu staia central. Sistemul automat de monitorizare a depozitului central de deeuri al municipiului Suceava se compune din dou subsisteme: 1. Subsistem LOCAL, 2. Subsistem DISPECER. Subsistemul local se compune din: a) Traductoare, sensori, detectoare etc., b) Echipament local. Subsistemul DISPECER se compune din: Echipament dispecer , Calculator tip PC, Imprimanta, UPS. Dispecerul este prevazut n exterior cu o anten tip GSM/GPRS. Echipamentul dispecer se compune dintr-o cutie Automatica tip CA13 n interiorul creia se afl staia de recepie GSM / GPRS tip Metrilog T707. Arhitectura general a sistemului este reprezentat n figura 8.23. Metrilog T707 este o staie de transmitere date bazat pe standardele de protocoale deschise. Sistemul de comunicaii folosete reelele GSM, transmisia de date fcndu-se
188

folosind standardul GSM/GPRS (General Packet Radio Service). n cazul folosirii strict a protocolului GPRS se menioneaz faptul c nu mai este necesar i staia de recepie de la dispecerat deoarece recepionarea datelor din teren se poate face prin reeaua Internet (staia GPRS de pe teren transmite datele ctre un server al operatorului local de telefonie mobil care ofer serviciul de GPRS, iar preluarea datelor de pe acest server se va face cu ajutorul unui program de achiziie realizat n cadrul activitilor de implementare a proiectului ZoneMAP de ctre IPA SA, partener n echipa proiectului). Staia T707 folosete conceptul de BUS, astfel nct se accept cuplarea simultan a unui numr mare de traductoare: actuala staie poate eantiona un numar de max. 50 de traductoare.
Sistemul Central de prelucrare a informaiilor (Server Baze de Date) + Imprimant

Dispecer central

Sistem de comunicaie GSM

nivel comunicaie (datalogger, radio/GSM modem)

Puncte pluviometrice i staii achiziie din puuri de foraj Senzori + Traductori

Aria monitorizat

nivel local (traductoare)

Figura 8.23. Arhitectura general a sistemului

Staii de achiziie date n funcie de complexitatea i numrul de parametrii achiziionai din fiecare punct de msur, n cadrul sistemului se definesc urmtoarele tipuri de staii: staii de achiziie hidrometrice (achiziioneaz nivelul n apele de suprafa, temperatura atmosferic, calitatea apelor de suprafa i din pnza freatic);

189

staii pluviometrice (achiziioneaz parametrii n funcie de configuraia staiei: nivel, temperatur i precipitaii); staii de achiziie din puurile de foraj (achiziioneaz date referitoare la variaia nivelului pnzei freatice n forajele de urmrire i de exploatare, precum i calitatea apelor); staii portabile pentru achiziia datelor de la puurile de foraj i transferul lor n baza de date la dispecerul zonal. 8.4.3. Proiectarea bazei de date a sistemului Baza de date a sistemului este o baz de date distribuit pe urmtoarele nivele: serverul central de baze de date (SQL server Microsoft); serverele locale de baze de date (Microsoft ACCESS). Arhitectura general a bazei de date este reprezentat n figura 8.24.

Central Server user p+1


. . . . . . . . .

user 1
. . . . . . ..

Internet

GSM

user p

user p+t

Local Server 1

Local Server n

Local Server n+1

Local Server n+m

Figura 8.24. Arhitectura bazei de date a sistemului Schema conceptual a bazei de date Datele privind gestionarea deeurilor sunt grupate n urmtoarele dou categorii: date privind deeurile municipale i asimilabile din comer, industrie i instituii, deeuri din construcii i demolri i nmoluri de la staiile de epurare oreneti; date privind deeurile de producie n cadrul sistemului telematic pentru managementul on-line al zonelor intravilane degradate sunt definite urmtoarele categorii de date:

190

date privind gestionarea deeurilor (zone intravilane monitorizate, deeuri, surse de poluare, depozite deeuri, staii de prelucrare deeuri ; date privind protecia mediului (parametri calitate mediu: ap, aer, sol); date spaiale (hri tematice). Pentru modelarea logic a datelor se pleac de la diagrama entitate-relaie de ansamblu a sistemului reprezentat n figura 8.26. n diagrama entitate-relaie sunt reprezentate tipurile de entiti: zone intravilane monitorizate, deeuri, surse de poluare, depozite deeuri, parametri calitate mediu, hri tematice. Date privind gestionarea deeurilor Avnd n vedere entitile reprezentate n schema conceptual a bazei de date, se definesc, n cele ce urmeaz, schemele de relaie (tabelele) bazei de date pentru sistemul de monitorizare, precum i exemple de completare. Tabelul 8.4.1.Tipuri deeuri
Grupa 1 1.1 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 1.8. 2 2.1 2.2 3 3.1 3.2 Tipuri principale de deeuri Deeuri municipale i asimilabile din comert, industrie, institutii, din care: Deeuri menajere colectate in amestec de la populatie Deeuri asimilabile colectate in amestec din comert, industrie, institutii Deeuri municipale i asimilabile colectate separat (exclusiv deeuri din constructii i demolari), din care: * Deeuri voluminoase Deeuri din gradini i parcuri Deeuri din piete Deeuri stradale Deeuri generate i necolectate ** Nmoluri de la statii de epurare oreneti, din care: Cantitate valorificat (s.u.) Cantitate depozitat (s.u.) Deeuri din constructii i demolri, din care: Deeuri inerte Deeuri n amestec Cod deeu 20 15 01 20 03 01 20 03 01 20 01 15 01 20 03 07 20 02 20 03 02 20 03 03 20 01 15 01 19 08 05 19 08 05 19 08 05 17 17.05.03 17.05.02 Unitate de msur Tone Tone Tone Tone Tone Tone Tone Tone Tone Tone Tone Tone Tone Tone Tone

Tabelul 8.4.2.Zone monitorizate


Cod zon 30 30.1 Denumire zon / localitate Judeul Suceava Municipiul Suceava
191

Populaia total 705555 108076

Reprezentri GIS Hyperlink Hyperlink

30.2 30.3 30.4

Municipiul Flticeni Municipiul Rdui Municipiul Cmpulung Moldovenesc

30800 29417 20572

Hyperlink Hyperlink Hyperlink

Tabelul 8.4.3.Deeuri generate


Grupa 1 1.1 1 1.1 Cod deeu 20 15 01 20 03 01 20 15 01 20 03 01 Anul 2002 2002 2003 2003 Cantitate 183363 103485 149448 75956 Cod zona 30 30 30 30

Tabelul 8.4.4.Staii prelucrare deeuri


Cod staie 30.1 30.2 30.3 30.4 30.5 30.6 30.7 30.8 Denumire staie / localitate SC DIASIL SERVICE SRL Suceava, str. Grigore Al Ghica, nr.18 SC AMBRO SA Suceava, Calea Unirii, nr.24 SC OMT METAL SRL Gura Humorului, str. Grii Pltinoasa, fn SC COREMAT IS SRL Flticeni, str. Topitoriei, fn SC COM REMAT SRL Iai, punct de lucru Suceava, Calea Unirii, nr.14 SC COMREMAT SRL Vatra Dornei, str. Bistriei, nr.2A SC SIMOTAB SRL Suceava, Gara Suceava Vest SC NICOTEX SRL Suceava, str. Mirui, nr.19

Tabelul 8.4.5. Deeuri prelucrate


Grupa 1 1.1 1 1.1 Cod deeu 20 15 01 20 03 01 20 15 01 20 03 01 Anul 2002 2002 2003 2003 Cantitate 52 80 113 164 Cod staie prelucrare 30.1 30.2 30.1 30.2

Tabelul 8.4.6.Depozite deeuri


Cod depozit 30.1 30.2 30.3 30.4 30.5 30.6 30.7 Denumire depozit / localitate Suceava / Suceava Rdui / Rdui Antileti / Flticeni Buliceni / Vatra Dornei Hurghi / Cmpulung Gura Humorului / Gura Humorului Siret / Siret Capacitate disponibil (mc) 90000 50300 79400 3000 34300 10000 67500

Tabelul 8.4.7. Deeuri depozitate


192

Cod depozit 30.1 30.2 30.3 30.4 30.5 30.6 30.7 30.1 30.2 30.3 30.4 30.5 30.6 30.7

Anul 2002 2002 2002 2002 2002 2002 2002 2003 2003 2003 2003 2003 2003 2003

Cantitate (mc) 88529 19047 9528 7523 7686 3755 5964 66795 15457 8400 4070 6975 3370 5606

Date privind protecia mediului Datele de mediu sunt reprezentate n diagrama E-R prin entitatea PARAMETRI Parametri calitate mediu CALITATE MEDIU care este descris n figura 8.25 ca o structur ierarhic de date, avnd n vedere principiile proiectrii bazelor de date temporale. Cele dou categorii de date (date privind gestionarea deeurilor, date privind protecia mediului) sunt astfel descrise n cadrul unei structuri flexibile i extensibile de 2. Parametri meteorologici 1. Parametri ecologici date.
1.1. Sol Cod 2.1. Cod 1.3.1. 1.3.2 ........................... Denumire 2.2 .............................. Denumire

1.2. Apa

1.3. Aer

Cod 1.1.1. 1.1.2

Denumire

Cod 1.2.1. 1.2.2

Denumire

...........................

...........................

Cod parametruValoare parametruData msurrii1.1.1 1.2.11.3.12.1

DATE ISTORICE 193

Figura 8.25. Date privind protecia mediului

Date spaiale Raportat la modul de prelucrare, datele spaiale se grupeaz n: date descriptive (textuale) i date grafice. Datele descriptive sunt organizate n tabele, iar datele grafice definesc imagini vector prin puncte definite de coordonate i descrieri de contururi. Datelele spaiale sunt reprezentate i pot fi redate pe straturi. O alt categorie de date este constituit din imagini raster reprezentnd fiiere imagine obinute prin scanare planuri cadastrale i hri topografice, care pot constitui surse de date grafice obinute prin operaia de vectorizare. Organizarea, descrierea i prelucrarea datelor cadastrale necesit utilizarea unui produs de tip GIS (Geographical Information System) care s ofere: un nucleu grafic pentru reprezentarea i prelucrarea datelor grafice, un sistem de gestiune a bazelor de date, comunicarea ntre cele dou componente ale sistemului. Este avut n vedere pachetul NetSET, care ofer un foarte bun raport ntre pre, performane i faciliti oferite, acoperind practic toate aspectele dezvoltrii aplicaiilor GIS. n plus, lucreaz cu hri vectoriale n format shape, compatibil la nivel internaional cu alte pachete de programe similare.

Fig.8. 26. Schema conceptual a bazei de date


194

8.4.4. Dezvoltarea unei aplicaii specifice pentru reprezentarea i monitorizarea unor zone intravilane din judeul Suceava supuse degradrii datorit depozitrii necontrolate a deeurilor. n cadrul acestei seciuni sunt prezentate: proiectarea i realizarea modelului de poziionare geografic n sistem GPS / GIS a zonelor intravilane degradate; realizarea modelului experimental al sistemului telematic pentru managementul on-line al zonelor intravilane degradate prin depozitarea necontrolat a deeurilor. Componentele software dezvoltate pentru realizarea aplicaiei sunt: Componenta care asigur importul hrii vectoriale a municipiului Suceava, indiferent de sursa acesteia i mpreun cu informaiile de georefereniere. Componenta care asigur navigarea, funciunile de mrire-micorare, de afiare sau nu a straturilor, de suprapunere a straturilor ntr-o anumit ordine etc. Componenta care asigur gestiunea bazelor de date ataate fiecrui strat i legtura dintre aceste baze i obiectele grafice de pe straturi. Componenta care asigur citirea perimetrelor ridicate cu ajutorul dispozitivelor mobile GPS i creare de noi straturi cu aceste informaii. Componenta software care asigur citirea locaiilor dispozitivelor automate de msurarea a parametrilor de mediu amplasai n zonele degradate ale zonei intravilan a Municipiului Suceava. Componenta care asigur recepionarea informaiilor despre parametrii de mediu transmise prin GPRS/GPS/TCP/IP de ctre dispozitivele automate de msurare plasate n punctele cheie ale zonei intravilane a Municipiului Suceava. Pentru realizarea sistemului s-a colaborat cu instituii pe plan local (Primria Municipiului Suceava, Agenia pentru Protecie a Mediului Suceava, Garda de Mediu Suceava) pentru a realiza ridicri de coordonate geografice pentru zonele propuse pentru monitorizare, care au furnizat studii tehnice i valori istorice pentru analize chimice, n vederea determinrii punctelor critice din punctul de vedere al polurii datorate depozitrii necontrolate a deeurilor urbane, precum i n vederea identificrii necesitilor de monitorizare. Au fost realizate activiti de urmrire periodic a evoluiei perimetrale a depozitelor, prin poziionare geografic a limitelor amplasamentelor obiectivelor identificate n cazul fazei anterioare, i anume: depozitul de deeuri municipale Suceava, depozitele neamenajate de pe malurile praielor Vtafu i cheia i din cartierul Obcine. Aceste obiective au fost monitorizate prin inspecii periodice i ridicri de coordonate ale limitelor perimetrale la data inspeciei. n obiectivele monitorizate, s-au ridicat probe de sol / ap, pentru evaluarea nivelului de poluare indus i definirea strii de calitate ca nivel de referin. Pentru identificarea efectelor induse asupra apelor de suprafa s-au continuat investigaiile asupra rului Suceava, praielor Vtafu i cheia, prin recoltarea de probe

195

amonte i aval de amplasamentul depozitelor de deeuri i determinarea indicatorilor de calitate pentru probele prelevate din levigatul deversat. S-a realizat harta vectorial georefereniat a municipiului Suceava i s-au introdus punctele care constituie perimetrele zonelor degradate identificate pn n prezent, msurate ca poziie geografic cu ajutorul dispozitivelor GPS. Pentru pozitionarea geografic a amplasamentelor Depozitului central de deseuri al municipiului Suceava, a depozitelor neamenajate de deseuri de pe malul paraurilor afluente raului Suceava si a depozitelor neamenajate din zonele rezidentiale monitorizate n cadrul fazelor anterioare ale implementrii proiectului, s-a recurs la utilizarea tehnicii de pozitionare prin intermediul satelitilor GPS (Global Positioning System). A fost utilizat un receptor GPS performant, portabil, care ofer posibilitatea masurrii perimetrelor depozitelor de deeuri, calculrii suprafeelor acestora, precum i poziionrii cu o precizie mare pe hart, a punctelor de prelevare probe de ap si sol. Receptorul GPS utilizat este model GPSMAP 60CSx produs de firma GARMIN, receptor care are ncorporat harta digital a Romaniei (ROAD 2006, cu licena nr.931). Acest receptor GPS folosete un sistem de poziionare geografic de tip WAAS (Wide Area Augmentation System) cu o precizie mare de localizare, i anume de 3 m. Receptorul GPS are port de comunicare, astfel nct se poate conecta prin port USB cu un calculator i, cu ajutorul aplicaiei software MapSource, livrat mpreun cu receptorul, datele ridicate n teren (puncte de poziionare i masurrile de perimetre) stocate n memoria receptorului GPS pot fi transferate, vizualizate pe hart i apoi listate la un printer. n continuare sunt prezentate imagini care reprezint zonele monitorizate precum i alte rezultate obinute n cadrul aplicaiei de monitorizare.

Depozitul Suceava Perimetru: 1,3 km; Suprafata: 78667 mp

196

Figura 8.27. Incadrarea in zon a depozitului central de deeuri al municipiului Suceava

Rezultatele masurtorilor cu GPS efectuate n luna septembrie 2007 pentru Depozitul de deseuri al municipiului Suceava sunt urmatoarele: lungimea perimetrului depozitului 1.3 km, suprafata: 78 667 mp. Comparativ cu masurrile efectuate in luna aprilie 2007 se constat c suprafata depozitului a crescut cu aproximativ 10 % (de la 71 559 mp la 78 667 mp). Trebuie evideniat faptul c pe o portiune de aproximativ 150 m lungime depozitul de deseuri se gseste la mai putin de 2 m de albia raului Suceava (latura de N), iar eroziunea lateral a raului Suceava este foarte activ in aceast zon existnd posibilitatea ca o parte din deseurile depozitate s ajung n ru (detaliu in Figura 8.28).

Raul Suceava

Depozitul Suceava

Figura 8.28. sunt active in depozitului fa de meteorice Suceava Procesele de iroire Amplasamentulaceast zon, apele albia ruluicare percoleaz depozitul se scurg in rul Suceava (detalii in Figura 8.29) antrennd prin solubilizare si nu numai materiale din masa depozitului.

197

SIROIRE

Scurgeri ape de siroire spre raul Suceava

Figura 8.29. Procese de iroire i scurgeri ape de iroire n rul Suceava- detalii S-a constatat faptul ca extinderea depozitului s-a realizat pe laturile de E si NE cu mentiunea c deseurile se gsesc la o distant mic de raul Suceava (detaliu in Figura 8.30.).
Bascularea deseurilor din remorca

Figura 8.30. Depunere deseuri pe latura de Est detaliu

Starea parametrilor de calitate a mediului n zonele selectate Componenta de mediu SOL Investigaiile realizate, pentru componenta de mediu SOL, in zona depozitelor de deeuri urbane monitorizate n cadrul Fazelor 2 i 3 de implementare a proiectului, au

198

urmrit evaluarea nivelului de poluare indus de depozitarea neamenajata a deseurilor n zona de amplasament o obiectivelor analizate, la limita perimetrelor acestora. Pentru evaluarea gradului de poluare a solului au fost recoltate de ctre reprezentantii INCD ECOIND, n luna septembrie 2007, 7 probe de sol dup cum urmeaz: 4 probe pentru Depozitul de deeuri central al municipiului Suceava; 1 proba de sol pentru depozitul neamenajat de pe paraul Vatafu; 1 proba de sol pentru depozitul neamenajat de pe raul Scheia; 1 proba de sol martor din zona Scheia. Pentru prelevarea probelor de sol s-a utilizat sonda de prelevare pedologic, marca Buerkle, pungi de plastic i etichete autoadezive, iar poziionarea punctelor de prelevare s-a fcut cu ajutorul GPS Garmin din dotare. Probele au fost recoltate la adncimile 0-10 cm i 30-40 cm. Amplasarea probelor de sol pentru depozitul Suceava este prezentat n Tabelul 8.4.8 i este detaliat pe hart n figura 8.31. Tabelul 8.4.8 Amplasarea probelor de sol prelevate la Depozitul central Suceava Nr. crt Simbol prob Adncime 0-10 cm 1 S01 30-40 cm 0-10 cm 2 S02 30-40 cm 0-10 cm 30-40 cm 0-10 cm 30-40 cm N 470 39,033 E 0260 17,375 N 470 38,895 E 0260 17,422 N 470 38,936 E 0260 17,259 N 470 39,052 E 0260 17,229 Coordonate geografice ridicate cu GPS Amplasare - in vecinatea albiei minore a raului Suceava, latura de NV a depoziului - in vecinatea albiei minore a raului Suceava, latura de NE a depoziului - latura de SE a depozitului, padure de foioase - latura de SV a depozitului, padure de foioase

3 4

S03 S03

Descrierea morfologic a probelor de sol prelevate de la Depozitul central Suceava este prezentata n Tabelul 8.4.9. Tabelul 8.4.9. Descrierea morfologic a probelor de sol, Depozitul Suceava Nr Simbol . Adncime Structur Textur Observaii prob crt 1 S01 0-10 cm astructurat nisipoas lipsa radacini
199

2 3 4

S02 S03 S04

30-40 cm 0-10 cm 30-40 cm 0-10 cm 30-40 cm 0-10 cm 30-40 cm

astructurat astructurat astructurat poliedrica astructurat grauntoasa grauntoasa

nisipoas nisipos lutonisipoasa lutonisipoasa nisipoasa lutoargiloasa lutoargiloasa

radacini ierboase urme de radacini fine ierboase radacini lignificate -

Analiza morfologic a probelor de sol de la Depozitul central de deeuri al municipiului Suceava relev predominarea texturii nisipoase care confer apelor meteorice posibiliti de infiltrare rapid n sol, dar, n acelai timp o capacitate redus de reinere a apei n sol.

Proba Sol Vatafu

S01 S02 S04 S03

Figura 8.31. Amplasarea probelor de sol n zona Depozitului Suceava prului Vatafu Componenta de mediu APA DE SUPRAFA

Depozitele de deeuri neamenajate amplasate n vecintatea apelor de suprafa sunt surse potenial generatoare de afectare a calitii acestora. Scurgerile de levigat de pe versanii depozitelor contribuie la poluarea cu substane organice i suspensii a apelor de suprafa efectul putnd fi resimit pe distane mari. mprtierea deeurilor pe malurile apelor de suprafa conduce la apariia riscului de blocare a cursurilor n condiii de precipitaii extreme. n general prin levigarea de ctre apele meteorice a deeurilor depozitate neamenajat se induce o contaminare cu ncarcare organic, compui ai azotului i n funcie de compoziia deeului i alte substane toxice (metale grele). Pentru identificarea efectelor induse asupra calitii apelor de suprafa s-au efectuat investigaii asupra calitii apelor: rului Suceava, prului Vtafu, prului cheia. S-au recoltat probe de ap amonte i aval de amplasarea depozitelor de deeuri i s-au efectuat determinri ale indicatorilor de calitate. Metodele de ncercare utilizate pentru determinarea indicatorilor de calitate sunt prezentate n Tabelul nr. 8.4.10. Tabel nr. 8.4.10 Indicatori de calitate ape de suprafa i metode de ncercare
200

Nr. crt. 1 2 3 4 5 6 7 8 9 10 11 12

Indicator de calitate

Metode de incecare

pH SR ISO 10523/97 Conductivitate SR EN 27888/97 Turbiditate SR EN ISO 7027-01 Cloruri SR ISO 9297/01 CCOCr SR ISO 6060/96 CBO5 SR EN 1899/2-02 Amoniu SR ISO 7150/2-01 Azot amoniacal(N-NH4) Azot total SR ISO 10048/01 Azotati SR ISO 7890/2-00 Sulfati STAS 8601/70 Substante extractibile cu solventi SR 7587/96 organici

Probele prelevate au fost supuse determinrilor analitice i analiznd valorile indicatorilor de calitate determinate pentru proba de ap prelevat din levigat, comparativ cu valorile limit admise prin NTPA-001/2005 s-a constatat c indicatorii de calitate CBO5, CCOCr i Azot total depesc valorile admise inducnd o poluare semnificativ. Monitorizarea on-line a calitii apelor de suprafa n zonele imediat nvecinate depozitelor neamenajate de deeuri va reflecta efectele induse de aceste depozite. Numai o parte din indicatorii de calitate determinai vor putea fi monitorizai on-line, ceilali vor fi determinai n continuare prin ncercri de laborator asupra probelor de ap prelevate din ru i praie. Monitorizarea zonelor degradate din municipiul Suceava utiliznd platforma GIS NetSET Ca model pentru harta municipiului Suceava a fost aleas o hart simplificat (vezi Figura 8.32.), care ofer avantajul c este foarte cunoscut de locuitorii oraului, aceast hart fiind utilizat pentru orientare n municipiu (n mijloacele de transport n comun, n cadrul afiajului stradal etc.).

201

Figura 8.32. Harta model pentru harta vectorial georefereniat a municipiului Suceava

Pachetul de programe NetSET dispune de un modul de georefereniere care permite, pe baza punctelor de control de coordonate cunoscute, transformarea imaginii unei hri ntr-o imagine georefereniat, pregtit pentru a fi referina unei hri vectoriale georefereniate ( st la baza desenrii straturilor vectoriale). n continuare sunt reprezentate imagini ce ilustreaz reprezentarea unor straturi vectoriale pe harta georefereniat pentru a evidenia n final evoluia extinderii zonelor degradate.

Figura 8.33. Strat vectorial limit intravilan realizat pe platforma GIS NetSET

Figura 8.34. Strat vectorial limite administrative cartiere realizat pe platforma GIS
NetSET

202

Figura 8.35. Harta vectorial complet a zonei intravilan a municipiului Suceava realizat pe platforma GIS NetSET

Figura 8.36. Reprezentare zon degradat msurat n aprilie 2007(stnga) i septembrie 2007 (dreapta) pentru zona degradat Depozitul central Suceava

203

Din Figura nr. 8.36. se poate observa c perimetrul zonei degradate luat n considerare a evoluat n timp, fapt mai bine pus n eviden n figura 8.37.

Figura 8.37. Evoluia extinderii zonei degradate Depozitul central Suceava din aprilie pn n septembrie 2007

204

Concluzii Aceast tehnologie poate oferi suportul pentru controlul localizrii i monitorizrii depozitelor ilegale de deeuri i poate fi utilizat ca tehnologie multimedia pentru informarea autoritilor i populaiei asupra zonelor afectate de poluare antropic. Realizarea unui sistem de asemenea complexitate, impune captarea informaiei strict instaniate, n timp real, dar i a datelor rezultate n urma unor analize de laborator, care se introduc de ctre operatorul uman. n mod concret, soluia adoptat este realizarea unui sistem integrat de management i monitorizare, bazat pe senzori, ce poate fi uor upgradat la nivel de sistem de management funcional i arhitectural, pentru a se putea realiza o monitorizare centralizat pe baza unor programe i aplicaii specializate. Rolul sistemului implementat este de prentmpinare i de prealarmare asupra stabilitii, supravegherea ncadrrii n limite i evidenierea necesitii reducerii depozitrii necontrolate a deeurilor, informarea factorilor de decizie.

205

BIBLIOGRAFIE
[1] Ioan I.Andone, Robert J.Mockler, Dorothy G.Dologite, Alexandru Al.ugui, Dezvoltarea sistemelor inteligente n economie. Metodologie i studii de caz., Editura Economic, Bucureti, 2001. [2] Ioan Andone, Sisteme inteligente hibride. Teorie. Studii de caz pentru aplicaii economice. Ghidul dezvoltatorului, Editura Economic, Bucureti, 2002. [3] Andone I., ugui Al., Baze de date inteligente n managementul firmei, Ed, Dosoftei, Iai, 1997. [4] Balan D., Balan G. Sistemul informaional n gestionarea ntreprinderilor, Ed. Junimea, Iai, 1998 [5] Balteanu D. et al., Sistem informational geografic (GIS) pentru studiul dezastrelor naturale, Academia Romna, Institutul de Geografie, Bucuresti [6] Tudorel Baicu, Tatiana Eugenia esan, Fitopatologie Agricol, Ed.Ceres, Bucureti, 1996. [7] .Banca de Resurse Genetice Vegetale Suceava, editat la Banca de gene Suceava, 1997. [8] Brnzei R. Sisteme informatice, Ed. Universitii Al. I. Cuza, Iai, 1995 [9] .Octavian Bsc,.Baze de date, Ed. ALL, 1997. [10] Ion Capanu, Constantin Anghelache, INDICATORI ECONOMICI pentru managementul micro i macroeconomic. Calcul. Prezentare. Analiz., Editura Economic, Bucureti, 2000. [11] Chindea M. E. Proiectarea sistemelor informatice economice, Bucureti, 1999 [12] Chen, P.P. Entity-Relationship Approach to Systems Analysis and Design, Amsterdam, North Holland, 1980 [13] Thomas M. Connoly, Carolyn E. Begg, Database Solutions A step by- step approach to building databases, Second Edition, Pearson Education Limited, 2004 [14] Thomas Connolly, Carolyn Begg, Anne Strachan Database Systems A Practical Approach to Design, Implementation and Management Second Edition (trad. Ed. Teora: Baze de date Proiectare . Implementare . Gestionare, Bucureti 2001). [15] T. Crciun, I. Tomozei, N. Cole, Galia Butnaru, GENETIC VEGETAL Ed. Didactic i Pedagogic, Bucureti, 1991. [16] C. J. Date, An Introduction to Database Systems, 8th Edition, published by Pearson Education, Inc. Adison Wesley Higher Education, 2004. [17] Carla M. DeAngelis, Modeling Data with Erwin, SAMS, 2000 [18] Delahaye, J.P. Systemes experte: organisation et programmation des bases de connaissances en calcul propositionnel, Laboratoire d'Informatique Fondamentale de Lille, Universit des Sciences et Technologies de Lille, 1986. [19] Dimitriu G., Sisteme informatice geografice GIS, Editura Albastra, Cluj-Napoca, 1998 [20] Robert Dollinger-Baze de date i gestiunea tranzaciilor, Cluj Napoca, 1998.

206

[21] Doina Fusaru, Arhitectura bazelor de date Mediul SQL, Univ.Spiru Haret, Ed.Fundatiei Romnia de mine, Buc.2002. [22] GURU Tutor On-line System Documentation, Micro Data Base Systems Inc., Lafayette Indiana, 1987. [23] Jan R. Harrington, Relational Database Design Clearly Explained, Academic Press, 2002 [24] John E. Harmon and Steven J. Anderson, The Design and Implementation of Geographic Information Systems, John Wiley & Sons, 2003 [25] Michael J. Hernandez, Proiectarea Bazelor de date, trad. Ed. Teora, Bucureti, 2003. [26] W. Daniel Hillis, Maina care gndete. Cum funcioneaz calculatoarele. (trad. Mihai Cipu, Ed. Humanitas, Bucureti, 2001). [27] Mathieu, Ph. La ralisation d'un gnrateur de Systemes expertes, Course imprim, Laboratoire d'Informatique Fondamentale de Lille, Universit des Sciences et Technologies de Lille, 1992. [28] Ion Sainiuc, Carmen Antonovici, Radu Ungureanu, Nicolae Morariu, GEOGRAPH Sistem Informatic Geografic utilizat n realizarea cadastrului general finanat de Banca Mondial, Analele tiinifice ale Universitii Alexandru Ioan Cuza din Iai Tom XLII-XLIII, 1996-1997, pag. 51-54. [29] Nicolae Morariu, Sorin Vlad , Consideraii privind dezvoltarea sistemelor inteligente n economie, Economia romneasc prezent i perspective. Sesiunea tiinific naional cu participare internaional, Ed.Univ. Suceava, ISBN 973666-035-4, 2003, pag.566-577. [30] Nicolae Morariu, Dumitru Ostafe, Sorin Vlad , Consideraii privind utilizarea unor instrumente ale inteligenei artificiale n cercetarea aplicativ, Economia romneasc prezent i perspective, Sesiunea tiinific naional cu participare internaional, Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag.615-622. [31] t.Gh.Pentiuc, Nicolae Morariu, .a., Intelligent System for Prognosis and Estimation of Economic Decisions at Districtual Level, Advances in Electrical and Computer Engineering, Faculty of Electrical Engineering Stefan cel Mare University of Suceava, vol.1(8), nb.1(15), 2001, pp. 44-47. [32] mat.Nicolae Morariu, prof.dr.ing.Nicolae Popovici, ing.Radu Ungureanu, ing.Ion Sainiuc, ing.Traian Teodorescu, fiz.Ctlin Zamfirescu; Sistem informaional geografic (SIG) pentru monitorizarea zonelor expuse inundaiilor, Produse software pentru reprezentarea digital i monitorizare, Revista Hidrotehnica vol. 42 Nr. 10-12 1997, pag. 43-46. [33] N. Morariu, N. Popovici, R. Ungureanu, T. Teodorescu, I. Sainiuc, C. Zamfirescu; Sistem de reprezentare digital a zonelor expuse inundaiilor, Simpozion tiinific jubiliar 65 ani ai Universitii Agrare de Stat din Moldova, vol. 2, 7-9 octombrie 1998 Chiinu, pag. 186-188. [34] Nicolae Morariu,t.Gh.Pentiuc,Gh.Sandu,B.Tanasiciuc .a., Sistem expert destinat monitorizrii impactului msurilor economice asupra zonelor defavorizate referin Judeul Suceava, Sesiunea tiinific naional cu participare
207

internaional Economia romneasc prezent i perspective, Univ. tefan cel Mare Suceava, iunie 2002, pag.586-598. [35] . Nicolae Morariu, Aspecte privind distribuirea datelor n cadrul unui sistem informatic pentru integrarea registrelor permanente, Tehnologii informaionale, Editura Universitii Suceava, ISBN 973-666-059-1, 2003 , pag.60-69. [36] Nicolae Morariu, Integrarea tehnologiei bazelor de date cu tehnologia sistemelor inteligente, Economia romneasc prezent i perspective. Sesiunea tiinific naional cu participare internaional, Ed.Universitii Suceava, ISBN 973-666035-4, 2003, pag.553-565. [37] Nicolae Morariu, Utilizarea unor instrumente ale inteligenei artificiale pentru diagnosticare i predicie n economie, Simpozionul Internaional al Tinerilor Cercettori Ediia II - a, Academia de Studii Economice din Moldova, 29 30 aprilie 2004, Departamentul Editorial-Poligrafic al A.S.E.M. Chiinu, ISBN 9975-75-239-x, Vol.I pag.14-16. [38] Nicolae Morariu, REFORME A software product for pattern clasification and recognition by joint use of pattern recognition techniques and multi-layer perceptron, The Proceedings of the Central and East European Conference in Business Information Systems, Cluj-Napoca, may 2004, Ed. Risoprint, ISBN 973656-648-X, pag.100-105. [39] Nicolae Morariu, Artificial Inteligence Techniques in an Evaluation and Decision System for Economic Activity, SACI 2004, Budapest Polytechnic Nepszinhaz, Budapest, Hungary, Timioara, 2004. [40] [MOR404]. Nicolae Morariu, Sorin Vlad, Online documentation and assisted research knowledge based system for vegetal genetics resources, Proceedings of the Forth International Conference Internet Education Science IES-2004, Baku State University Azerbaijan,Vinnytsia National Technical University Ukraine, St. Cyril and St. Methodius University of Veliko Turnovo Bulgaria, oct. 2004 Vinnytsia Ukraine, ISBN 966-641-104-0, Tom 2, pag. 513-516. [41] Nicolae Morariu, Baze de date. ndrumar de laborator, ISBN 973-666-159-8, Editura Univ. tefan cel Mare Suceava, 88 p, Suceava, 2005. [42] Andrew J. Oppel, Databases Demystified, McGraw-Hill, 2004 [43] Dumitru Oprea, Gabriela Meni, Florin Dumitriu, Analiza sistemelor informaionale, Editura Universitii Alexandru Ioan Cuza Iai, 2005 [44] Dumitru Oprea, Florin Dumitriu, Gabriela Meni, Proiectarea sistemelor informaionale, Editura Universitii Alexandru Ioan Cuza Iai, 2006 [45] Dumitru Oprea, Dinu Airinei, Marin Fotache, Sisteme informaionale pentru afaceri, Editura POLIROM Iai, 2002 [46] Oprea D. Analiza i proiectarea sistemelor informaionale economice, Ed. POLIROM, Iai, 1999 [47] Introduction to ORACLE SQL, SQL* Plus and PL/SQL Course Notes, Glenn Maslen, Published by Oracle Corporation UK Ltd. 1992. [48] Totul despre SQL Interogarea bazelor de date, Corina Pascu, Adrian Pascu, Ed. Tehnic Buc. 1994.
208

[49] Pigford D. V., Baur G., Expert Systems for Business. Concepts and Applications. Featuring VP-Expert, Boyd & Fraser Pub, Boston, 1990. [50] Elemente de teoria i proiectarea bazelor de date. Note de curs, Stefan Gh. Pentiuc, Jean Michel Duthilleul, Univ. tefan cel Mare Suceava 1995. [51] Pentiuc, t. Gh. An Algorithm for the Generation of Symbolic Classifiers for Pattern Recognition Systems. Analele Universitii "tefan cel Mare" Suceava, nr.1, 1994. [52] tefan-Gheorghe Pentiuc, Aplicaii ale recunoaterii formelor n diagnosticul automat, 158 p. ISBN 973-31-1096-5, Editura Tehnic, Bucureti, 1997. [53] [PENT00]. t. Gh. PENTIUC, Generatoare de sisteme expert - Editura Hipparion, Cluj-Napoca, 2000, ISBN 973-9448-48-8, 112 pagini. [54] Popescu I. Baze de date relaionale: proiectare i implementare, Ed. Universitii din Bucureti, Bucureti, 1996 [55] Rojanschi, V., Bran Florina, Diaconu Gheorghia, Protecia i ingineria mediului, Ed. Economic, Bucureti, 2002 [56] Roger J. - Utilizare ACCESS 95, Ed. Teora, Bucureti, 1995 [57] Rusu A, Bo N., Kiss A., Topografie-Geodezie EDP Bucureti, 1982. [58] Khoshafian Setrag Object Oriented Databasses, pub. John Whiley 1994, UK. [59] Prof. dr. Victoria Stanciu, .a. Proiectarea sistemelor informatice, Ed. Dual Tech, 2004. [60] Stanciu V. Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureti 2000 [61] Alecsandru Puiu Tacu, Romul Vancea, tefan Holban, Aurel Burciu, Inteligena Artificial. Teorie i aplicaii n economie., Editura Economic, Bucureti, 1998. [62] Udric M. Modelarea orientat obiect, Ed. Cison, Bucureti, 2000 [63] Vasilescu P., Dunca V. Proiectarea sistemelor informatice, Ed. Tehnic, Bucureti, 1979 [64] Marian Zaharia, Claudia Crstea, Liana Slgean, Inteligena artificial i sistemele expert n asistarea deciziilor economice, ISBN 973-590-870-0, Ed. Economic, Bucureti, 2003. [65] Mark Whitherhorn, Bill Marklyn, Insisde Relational Databases with Examples in Access, Springer 2007 [66] *** Anuar privind calitatea mediului n judeul Suceava, (1991-2003), Agenia de Protecia Mediului, Suceava [67] *** Sistem telematic pentru managementul on-line al zonelor intravilane degradate, acronim ZoneMAP, cod 509, contract nr.123CEEX/15.09.2006, programul CEEX - competitia ianuarie 2006, Raport tehnic faza 2, faza 3. [68] ***http://www.ca.com/us/products/product.aspx?id=260 [69] ***http://www.quest.com/Toad-Data-Modeler/ [70] ***http://www.embarcadero.com/products/erstudio/ [71] ***http://office.microsoft.com/en-us/visio/default.aspx [72] ***http://www.oracle.com/technology/software/products/designer/htdocs/winsoft .html
209

[73] *** www.feea.uaic.ro. [74] Suceava Genebank Romania, [75] *** Inteligent

Databases, http://www.svgenebank.ro Database Systems, www.cms.dmu.ac.uk/~jennyc/Intell_db_notes.htm [76] Evaluation and Conservation of Barley Genetic Resource to Improve Their Accessibility to Breeders in Europe. Evaluation methods 1999, EU Project GENRES CT98-104, Genbank, IPK, Gatersleben, Germany, http//barley.ipkgatersleben.de [77] UMBC KQML Web. KQML Papers and presentations, http:www.cs.umbc.edu/kqml/papers/ [78] Ing. Laurentiu-Virgil RUSAN, Consideratii privind structurile de date specifice sistemelor informationale geografice,www.revistaie.ase.ro/content/13/rusan.pdf [79] Data mining, o nou er n informatic tefan I.Nitchi i Rodica Avram-Nitchi, http:www.byte.ro/byte97-02/18tend.html. [80] Dicionar modern de informatic, Sisteme multiageni, Universitatea Politehnica Bucureti, www.cs.pub.ro/~dict/sisteme_multiagenti/ sisteme_multiagenti.html

210