Sisteme In Format Ice de Gestiune. Cristescu M.

UNIVERSITATEA ”LUCIAN BLAGA” DIN SIBIU FACULTATEA DE ȘTIINȘE ECONOMICE

SISTEME INFORMATICE DE GESTIUNE

- Note de curs - (Format ID)

SIBIU - 2009

1

CUPRINS Capitolul 1 Sisteme informatice………………………………………………………………..…….….. 3 1.1. Sistem, Sistem informaŃional, Sistem informatic……………………………………. 3 1.1.1. Componentele sistemului informatic…………………………………………… 5 1.1.2. Clasificarea sistemelor informatice………………. …………………………… 6 1.1.3. Obiectivele sistemelor informatice....................................................................... 7 1.1.4. Ciclul de viaŃă a unui sistem informatic.....…………………………………….. 7 1.1.5. ConŃinutul bazei informaŃionale a unei întreprinderi ………………………...… 9 1.1.6. Ciclul prelucrării datelor pentru sistemul informatic………………………….... 9 1.1.7. Sistemele informatice de gestiune ……………………...……………………… 10 1.2. Metodologii de realizare a sistemelor informatice…………….……...……………... 11 1.2.1. ConŃinutul metodologiilor de realizare a sistemelor informatice...…….………. 11 1.2.2. Metode şi tehnici de realizare a sistemelor informatice ..……….……………... 12 1.3. Instrumente CASE........................................................................................................ 14 1.3.1. FuncŃiile CASE ……………………………….................................................... 15 1.3.2. Trăsături definitorii ale CASE-ului....................................................................... 15 1.3.3. Exemple de instrumente CASE .........................……………..………………… 16 Capitolul 2 IniŃierea şi planificarea realizării unui sistem informatic...…………………….…………… 18 2.1. Identificarea, selecŃia, iniŃierea şi planificarea proiectelor..…………………………. 18 2.2. Analizele de fezabilitate……….…………. …………………………………….. ..... 20 2.3. Tehnici de reprezentare a planurilor şi programarea calendaristică............................. 21 Capitolul 3 Analiza sistemului existent şi definirea cerinŃelor noului sistem........……………................ 23 3.1. Studiul sistemului informaŃional existent………………...……………………….…. 23 3.2. Determinarea cerinŃelor sistemului ……………..…………………………................ 24 3.2.1. Metodele tradiŃionale utilizate în analiza şi determinarea cerinŃelor

sistemului..

25

3.2.2. Metode moderne de analiză şi determinare a cerinŃelor sistemului…………….. 25 3.3. Structurarea cerinŃelor sistemului - modelarea logică a datelor şi prelucrărilor……... 26 3.3.1. Diagramele fluxurilor de date (DFD)……………..…………………………… 27 3.3.2. Descompunerea funcŃională şi rafinarea DFD………………………………….. 28 3.3.3. Modelarea sistemului current………………………………………………….... 31 3.3.4. Modelarea logicii proceselor………………………………………………….... 33

Sisteme informatice

2

3.4. Modelarea conceptuală a datelor (diagramele entitate – relaŃie, DER)........................ 35 3.4.1. Modelul Entitate/RelaŃie (E/R)............................................................................. 43 3.5. Selectarea celei mai bune variante strategice de proiectare …………..…………….. 47 Capitolul 4 Proiectarea logică a sistemelor informatice.......................................................................................... 48 4.1. Proiectarea formularelor/formatelor şi a rapoartelor................................................................ 48 4.1.1. Proiectarea situaŃiilor cu rezultate finale (rapoartelor)………………............................. 48 4.1.2. Proiectarea codurilor………… …………………….………………………….….……. 51 4.1.3. Proiectarea intrărilor în sistemul informatic....................................…….………….…... 52 4.2. Proiectarea interfeŃelor şi a dialogurilor ………….………...…………..…………….…….. 54 4.3. Proiectarea logică a bazelor de date………………….……………………………………… 55 4.3.1. Normalizarea relaŃiilor - Forme normale.............................................................. 59 4.3.2. Simplificarea structurii datelor prin normalizare……………………………….. 63

4.3.3. Transformarea diagramelor entitate-relaŃie în relaŃii…………………………… 65 Capitolul 5 Proiectarea fizică a sistemelor informatice…………….……….......................................................... 66 5.1. Proiectarea fizică a bazelor de date şi a fişierelor..................................................................... 66 5.1.1. Obiectivele fundamentale ale unei baze de date................................................... 67 5.1.2. Sistemul de Gestiune a Bazelor de Date (SGBD)…..………………………….. 67

5.1.3. Administratorul bazei de date…………………………………………………... 68 5.1.4. Proiectarea securităŃii bazelor de date şi a fişierelor……………………..…….. 69

5.1.5. Limbajul SQL – crearea, administrarea, interogarea bazelor de date

relaŃionale.

70

5.2. Proiectarea programelor şi a procedurilor………………………………..….……….............. 81 5.2.1. Atributele modulelor......................................................................................................... 82

5.2.2. Structurile de control ale programelor.............................................................................. 83

5.2.3.Proiectarea şi realizarea programelor............................................................................... 87

5.3. Proiectarea sistemelor distribuite............................................................................................. 87

Teste 2009............................................................................................................................... 93 Bibliografie.............................................................................................................................. 107

3

CAPITOLUL 1. SISTEME INFORMATICE

1.1. Sistem, Sistem informaŃional, Sistem informatic

Un sistem reprezintă un ansamblu de elemente (componente) interdependente între care se stabileşte o interacŃiune dinamică, pe baza unor reguli prestabilite, cu scopul atingerii unui anumit obiectiv [4]. Conform teoriei sistemelor orice organism economic este un sistem.

OrganizaŃie – o intreprindere, instituŃie, societate comercială. În orice organizaŃie se disting 3 componente: - sistemul de conducere sau de decizie; - sistemul informaŃional; - sistemul operaŃional. Sistemul informaŃional cuprinde ansamblul informaŃiilor interne şi externe

utilizate în cadrul organizaŃiei precum şi datele care au stat la baza obŃinerii lor, procedurile şi tehnicile de obŃinere a informaŃiilor (plecând de la datele primare) şi de difuzare a informaŃiilor, precum şi personalul implicat în culegerea, transmiterea, stocarea şi prelucrarea datelor.

Sistemul informaŃional are două componente: - componenta pentru stocarea (memorarea informaŃiilor); - componenta pentru prelucrarea informaŃiilor. Orice organizaŃie interacŃionează cu alte organizaŃii externe ei primind informaŃii

din exterior şi furnizând informaŃii către lumea exterioară. FuncŃiile unui sistem informaŃional sunt: - să colecteze informaŃii din sistemele operaŃional şi decizional precum şi

informaŃiile ce provin din mediul extern; - să memoreze aceste informaŃii precum şi informaŃii rezultate din prelucrarea

lor; - să asigure accesul la memorie în vederea comunicării informaŃiilor stocate; - să prelucreze informaŃiile la cererea sistemului operaŃional şi a sistemului de

conducere. NoŃiunea de sistem informatic este legată de informatizarea activităŃii

organizaŃiei, deci folosirea echipamentelor hardware şi a produselor software pentru organizarea şi administrarea informaŃiilor. Utilizarea calculatoarelor în cadrul sistemului informaŃional (SI) al unei organizaŃii conduce la definirea componentei Sistem InformaŃional Automatizat (SIA) – care cuprinde numai lucrările realizate cu ajutorul calculatoarelor. RelaŃia SI – SIA este reprezentată în figura 1.1.

Sisteme informatice

4

Sistem informatizat Procesor de informaŃii InformaŃie Reguli Fig. 1.1. RelaŃia SI – SIA (Sursa: [10]) DefiniŃie. Un sistem informatic este un sistem utilizator-calculator integrat, care furnizează informaŃii pentru a sprijini activităŃile de la nivel operaŃional şi activităŃile de management într-o organizaŃie, utilizând echipamente hardware şi produse software, proceduri manuale, o bază de date şi modele matematice pentru analiză, planificare, control şi luarea deciziilor [10]. Elaborarea sistemelor informatice impune modelarea sistemului informaŃional al organizaŃiei cu ajutorul unui formalism prin care să poată fi reprezentată cât mai sugestiv şi fidel realitatea din cadrul sistemului informaŃional. Sistemele informatice complexe pot fi descompuse în subsisteme, care la rândul lor pot fi descompuse în aplicaŃii destinate unor categorii de utilizatori, aplicaŃii care la rândul 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, aplicaŃii, programe

Sistem manual

Sistem automatizat

Om

Calculator

Fişiere manuale

Fişiere informatice

Reguli şi proceduri scrise

Programe şi Structuri de date

Sistem Informatic

Subsistem 1 Subsistem 2 ……

Subsistem n

Aplicatia 2.1 Aplicatia 2.k …

Program 2.k.1 …

Program 2.k.s

5

Pentru organizaŃii de complexitate mică, informatizarea poate însemna realizarea unei singure aplicaŃii informatice referită de asemenea ca sistem informatic. Sistemele, subsistemele şi aplicaŃiile informatice sunt produse informatice numite şi produse software. Un produs informatic este constituit din programe care accesează baza de date şi din documentaŃia necesară pentru utilizarea şi întreŃinerea programelor. Acestea se realizează în baza unor metodologii şi necesită parcurgerea unor etape începând cu specificarea cerinŃelor şi terminând cu implementarea, exploatarea şi întreŃinerea lor. Sistemul informatic economic este un ansamblu structurat de elemente intercorelate funcŃional pentru automatizarea procesului de obŃinere a informaŃiilor şi pentru fundamentarea deciziilor. Sistemul informatic este inclus în sfera sistemului informaŃional atâta vreme cât în cadrul sistemului informaŃional vor exista o serie de activităŃi care nu vor putea fi automatizate [2]. 1.1.1. Componentele sistemului informatic

Un sistem informatic este compus din [2]: - baza informaŃională; - baza tehnică; - sistemul de programe; - baza ştiinŃifică şi metodologică; - factorul uman (resursele umane); - cadrul organizatoric.

Baza informaŃională cuprinde: - datele supuse prelucrării; - fluxurile informaŃionale; - 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 funcŃionarea sistemului informatic în concordanŃă cu funcŃiunile şi obiectivele stabilite. Sunt avute în vedere atât programele de bază (software de bază) cât şi programele aplicative (software de aplicaŃie). Baza ştiinŃifică şi metodologică este constituită din:

- algoritmi; - formule; - modele; - tehnici de realizare a sistemelor informatice.

Resursele umane constau din: - personalul de specialitate: analişti, programatori, ingineri de sistem, analişti-

programatori ajutori, operatori, etc.; - beneficiarii sistemului.

Cadrul organizatoric este cel specificat în regulamentul de organizare şi funcŃionare (ROF) al unităŃii în care va fi utilizat sistemul informatic.

Sisteme informatice

6

La realizarea şi utilizarea unui sistem informatic trebuie avute în vedere reŃele, echipamente, produse software de bază, produse software de aplicaŃie.

ReŃele - după aria de întindere geografică:

- Locale =LAN (Local Area Network) – la nivelul unei organizaŃii; - Metropolitane –MAN (Metropolitan Area Network) – la nivel de oraş, localitate; - De mare întindere -WAN (World Area Network) (ex. JudeŃ, łară).

- după accesibilitate: - Internet (reŃeaua Web) – o colecŃie mondială de reŃele interconectate; - Intranet – un sit Web sau un grup de sit-uri care aparŃin unei organizaŃii, accesibil numai pentru membrii acesteia; - Extranet – o reŃea intranet care este parŃial accesibilă utilizatorilor externi autorizaŃi. Echipamente - Echipamente de calcul : calculatoare, staŃii grafice, pentru servere de reŃea, servere de baze de date, staŃii de lucru (clienŃi, utilizatori), UPS-uri. - Echipamente de comunicaŃie : router-e, hub-uri, modem-uri, switch-uri. Produse software

Produse software de bază: - Sisteme de operare pentru serverul de reŃea (UNIX, Windows NT server, Windows 2000, Novell) şi pentru staŃiile de lucru sau clienŃi (Windows 95, Windows 98, Windows NT work station, Windows 2000); - Sisteme de Gestiune a Bazelor de Date (ORACLE, SQL Server Microsoft, MySQL, ACCESS, FoxPro etc.);

- Sisteme GIS (Geographical Information System) – utilizate pentru realizarea aplicaŃiilor din domeniul cadastrului (stocarea şi prelucrarea datelor spaŃiale );

- Limbaje (medii) de programare – utilizate pentru realizare software de aplicaŃie.

Produse software de aplicaŃie – produse program ce constituie aplicaŃiile şi subsistemele sistemului informatic.

1.1.2. Clasificarea sistemelor informatice

Sistemele informatice se clasifică după mai multe criterii.

1. În funcŃie de domeniul de utilizare, sistemele informatice pot fi pentru : - conducerea activităŃilor economico-sociale - conducerea proceselor tehnologice - cercetare ştiinŃifică şi proiectare tehnologică - activităŃi speciale.

2. În funcŃie de nivelul ierarhic ocupat de sistemul economic în structura organizatorică a societăŃii, conform căruia există sisteme informatice [2]: - pentru conducerea activităŃii la nivelul unităŃilor economice

7

- pentru conducerea activităŃii la nivelul organizaŃiilor economico-sociale cu structură de grup

- sisteme informatice teritoriale - pentru conducerea ramurilor, subramurilor şi activităŃilor la nivelul economiei

naŃionale - sisteme informatice funcŃionale generale .

3. În funcŃie de elementul supus analizei [Oprea D., 1999]: - sisteme informatice orientate spre funcŃii; - sisteme informatice orientate spre proces; - sisteme informatice orientate spre date; - sisteme informatice orientate spre obiecte; - sisteme informatice orientate spre cunoştinŃe.

4. După modul de organizare a datelor [[1] D., 1999]: - sisteme bazate pe fişiere; - sisteme bazate pe tehnica bazelor de date: ierarhice, reŃea, relaŃionale, orientate-

obiect; - sisteme mixte.

5. După metoda folosită în analiza şi proiectarea sistemelor [1]: - 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.

6. După gradul de centralizare [1]: - sisteme centralizate; - sisteme descentralizate;

7. După gradul de dispersie a resurselor sistemului informatic: - sisteme informatice locale (bazate pe reŃea locală, staŃii de lucru): - sisteme informatice distribuite (date distribuite).

8. După gradul de automatizare a activităŃilor de analiză şi proiectare a sistemelor informatice [1]: - sisteme informatice dezvoltate pe baza analizei şi proiectării clasice; - sisteme informatice analizate cu instrumente automate şi proiectate clasic; - sisteme informatice bazate pe instrumente diverse de automatizare a analizei şi

proiectării; - sisteme informatice dezvoltate cu instrumente de tip CASE.

Sisteme informatice

8

1.1.3. Obiectivele sistemelor informatice

Plecând de la ideea că sistemul informatic este subordonat procesului decizional, al cărui rol este de a asigura funcŃionarea normală şi optimă a întregii activităŃi şi de a reduce la minimum pierderile în caz de funcŃionare anormală, rezultă că obiectivul oricărui sistem informatic trebuie să fie subordonat obiectivului propriu-zis al unităŃii economico-sociale. În acest context, obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie asigurarea conducerii cu informaŃii reale şi în timp util, necesare fundamentării şi elaborării operative a deciziilor [2]. 1.1.4. Ciclul de viaŃă a unui sistem informatic

Sistemele informatice (SI) se caracterizează printr-un ciclu de viaŃă care începe cu decizia realizării unui nou SI care să corespundă mai bine noilor cerinŃe ale utilizatorilor şi se încheie cu decizia de înlocuire a SI existent cu unul nou, mai performant. Ciclul de viaŃă se desfăşoară pe etape în cadrul fiecăreia fiind definite faze şi activităŃi specifice [4].

Încă de la început facem menŃiunea 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 perfecŃionează, dând naştere unei alte versiuni sau chiar unui nou sistem. MutaŃiile din domeniul tehnologiei informaŃionale şi al metodelor de abordare a sistemelor s-au reflectat şi în ciclul de viaŃă al dezvoltării 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Ńă [4].

Prin parcurgerea materialelor de specialitate, se poate constata că numărul fazelor/etapelor variază de la trei (de exemplu analiza, proiectarea, implementarea) la peste douăzeci.

Există mai multe modele ale ciclului de viaŃă, multe dintre ele cunoscând o evoluŃie în timp. Spre exemplu, modelul cascadă (figura 1.3) prevede parcurgerea mai multor etape ale ciclului de viaŃă care se derulează secvenŃial fiind însă permisă la nevoie revenirea la etapa parcursă anterior în vederea îndepărtării neajunsurilor identificate în etapele superioare ale ciclului de viaŃă [4]. Etape ale ciclului de viaŃă a unui sistem informatic în modelul cascadă ([10])

1. Analiza şi definirea cerinŃelor – sunt definite scopurile, serviciile şi restricŃiile pe care trebuie să le îndeplinească sistemul informatic, prezentate într-o manieră încât să poată fi înŃelese atât de către utilizatorii sistemului cât şi de personalul de proiectare.

2. Proiectarea sistemului şi software-ului – satabilirea cerinŃelor pentru hardware şi software şi elaborarea arhitecturii generale a sistemului. FuncŃiile sistemului informaŃional vor fi reprezentate astfel încât să poată fi tranformate în unul sau mai multe programe executabile.

3. Implementarea şi testarea unităŃilor de program – proiectarea software-ului din etapa anterioară este transpusă într-o mulŃime de programe sau module programşi verificarea faptului că fiecare program sau modul satisface specificaŃia sa.

9

4. Integrarea şi testarea sistemului – integrarea şi testarea programelor şi modulelor program ca un sistem complet pentru a ne asigura că cerinŃele informaŃionale sunt satisfăcute. După testare sistemul este livrat beneficiarului.

5. Exploatarea şi întreŃinerea sistemului – este faza în care sistemul informatic este efectiv utilizat de către beneficiar şi în care sunt descoperite şi rezolvate eventuale erori de proiectare şi programare şi omisiuni în cerinŃele informaŃionale iniŃiale.

Fig. 1.3. Etapele ciclului de viaŃă a unui sistem informatic în modelul cascadă ([10])

Proiectarea sistemului şi a software-ului

Analiza şi definirea cerinŃelor

Implementarea şi testarea unităŃilor de program

Integrarea şi testarea sistemului

Exploatarea şi întreŃinerea sistemului

Sisteme informatice

10

1.1.5. ConŃinutul bazei informaŃionale a unei întreprinderi

Prin analiza critică sunt identificate entităŃile bazei informaŃionale. În principal, pentru o întreprindere acestea pot fi grupate după cum urmează:

- pentru activitatea de aprovizionare: stocuri de materiale, intrări materiale, consumuri de materiale, contracte cu furnizorii, programe de aprovizionare;

- pentru activitatea de producŃie: tehnologii şi reŃete de fabricaŃie, program de lucru, norme de muncă şi consumuri de manopere;

- pentru activitatea de desfacere: stocuri de produse, contracte cu clienŃii, realizări contracte;

- pentru activitatea de marketing: evoluŃia cererii şi a ofertei, dinamica preŃurilor, elasticitatea cererii şi a producŃiei;

- pentru activitatea financiar-contabilă: solduri şi rulaje contabile, calculaŃia costurilor, bugete de venituri şi cheltuieli, contabilitatea analitică şi sintetică;

- pentru activitatea de personal: evidenŃa personalului, salarizări, dotări social-culturale şi gestiunea lor;

- pentru activitatea de cercetare-dezvoltare: studii tehnico-economice, proiecte tehnice, investiŃii, etc.

1.1.6. Ciclul prelucrării datelor pentru sistemul informatic

OperaŃiunile care se execută asupra datelor, din momentul apariŃiei lor, pentru a genera informaŃii semnificative şi relevante sunt referite la un loc prin noŃiunea de ciclul prelucrării datelor. Ciclul cuprinde cinci faze: culegerea datelor, pregătirea datelor, prelucrarea datelor, întreŃinerea fişierelor şi obŃinerea informaŃiilor de ieşire.

Faza de culegere a datelor cuprinde două activităŃi fundamentale [1]:

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

Pregătirea datelor constă într-un număr de operaŃii executate asupra datelor pentru a facilita prelucrarea lor ulterioară. Ele sunt [1]:

- clasificarea datelor, care implică atribuirea de coduri de identificare (simbol cont, cod secŃie, etc.), astfel încât datele să fie incluse în submulŃimile corespunzătoare;

- gruparea datelor, adică acumularea intrărilor 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 înregistrări, după

criterii de ordonare numerică, alfabetică, alfanumerică sau de timp; - cuplarea a două sau mai multe loturi de înregistrări într-unul singur; - transmiterea datelor de la un punct la altul; - transcrierea datelor dintr-o formă în alta, astfel încât să se efectueze trecerea de la

scrierea de mână la cea tipizată sau de la documentele scrise la mediile specifice.

11

Pregătirea datelor este o activitate realizată în toate tipurile de sisteme informaŃionale, dar capătă o semnificaŃie deosebită în sistemele de prelucrare automată a datelor; partea informatizată a acestora fiind cunoscută ca sistem/subsistem informatic.

Fig. 1.4 Ciclul prelucrării datelor [1]

Prelucrarea datelor, poate să includă activităŃi, cum sunt [1]:

- calculaŃiile cuprind unele forme de tratare matematică a datelor; - compararea supune unei examinări simultane două sau mai multe tipuri de date între

care există o legătură logică (ex. soldul final şi cel final); - sintetizarea este o activitate importantă prin care se comasează informaŃiile; - filtrarea este o altă operaŃiune prin care se extrag datele ce vor fi supuse prelucrărilor

următoare; - 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 întreŃinere a fişierelor există mai multe activităŃi, dintre care amintim: - memorarea (stocarea) datelor în vederea utilizării lor viitoare; - actualizarea datelor memorate astfel încât să surprindă cele mai recente evenimente; - indexarea datelor pentru a înlesni o uşoară regăsire a lor; - protecŃia 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 obŃinerea informaŃiilor de ieşire.

InformaŃiile de ieşire pot fi regăsite în una din următoarele trei forme: documente, rapoarte ori răspunsuri la întrebări. Termenul ieşiri le cuprinde pe toate [1].

De cele mai multe ori, datele nu parcurg toate activităŃile, iar unele dintre ele pot chiar să nu treacă prin cele cinci faze.

Culegerea datelor

Pregătirea datelor

ÎntreŃinere fişiere

InformaŃii de ieşire

Prelucrarea datelor

Sisteme informatice

12

1.1.7. Sistemele informatice de gestiune

Sistemul informatic de gestiune implică următoarele patru componente interdependente: domeniile de gestiune, datele, modelele, regulile de gestiune [4].

Sistemul informatic de gestiune asigură obŃinerea informaŃiei solicitate de utilizator, folosind mijloacele tehnologiei informaŃiei (TI).

Sistemele informatice de gestiune sunt sisteme integrate. Se caracterizează printr-o introducere unică a datelor, preluate din documentele primare care actualizează o bază de date unică a contabilităŃii care va fi ulterior prelucrată pentru obŃinerea situaŃiilor specifice fiecărui utilizator [4].

Fig. 1.5. Sistem informatic de gestiune integrat al contabilităŃii [4]

Sistemul informatic de gestiune reuneşte subsisteme informatice specializate pe

domenii între care se manifestă interacŃiuni specifice. Fiecare subsistem definit grupează procese informaŃionale omogene, specifice unei anumite arii de interes [4].

La nivelul fiecărui subsistem vor fi definite aplicaŃii distincte corespunzătoare acestor activităŃi. La rândul lor aplicaŃiile sunt formate din proceduri descompunându-se în module reprezentând secvenŃe de cod prin care se realizează o funcŃie independentă din cadrul procedurii. Exemplu. O procedură pentru operaŃia de actualizare se va descompune în următoarele module:

1. modulul coordonator al funcŃiei de actualizare; 2. modulul pentru realizarea funcŃiei de adăugare de înregistrări; 3. modulul pentru funcŃia de ştergere înregistrări; 4. modulul pentru funcŃia de modificare a înregistrărilor din baza de date.

1.2. Metodologii de realizare a sistemelor informatice

Realizarea sistemelor informatice reprezintă o acŃiune complexă, care îmbină un număr mare de activităŃi: analiză, proiectare, implementare, exploatare [2]. În plus, reclamă resurse umane, materiale şi financiare însemnate, pe o perioadă considerabilă de

Actualizare

BD

Consultare 1

Consultare 2

BalanŃa de verificare Registrul jurnal Casa Banca

SituaŃia costurilor pe comenzi

Documente facturi ordin de plată bon de consum

13

timp. Folosirea eficientă a acestor resurse, în scopul obŃinerii 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. Acest lucru a dus deci, la conturarea unor metodologii de realizare a sistemelor informatice.

Între diversele etape de realizare a sistemelor informatice există o legătură indestructibilă, legătură reflectată şi de faptul că în mod logic şi practic calitatea realizării unor activităŃi din etapele şi fazele precedente influenŃează în mod decisiv calitatea activităŃilor din etapa ce îi urmează [2].

1.2.1. ConŃinutul metodologiilor de realizare a sistemelor informatice

Metodologiile de realizare a sistemelor informatice cuprind [2]: - modalitatea de abordare a sistemelor, pentru elucidarea raportului dintre variaŃiile

sistemului şi dinamismul său; - regulile de formalizare a datelor şi proceselor de prelucrare; - instrumentele pentru concepŃia, realizarea şi elaborarea documentaŃiei; - modalitatea de derulare a proiectului şi acŃiunile specifice fiecărei etape (ciclul de

viată); - definirea modului de lucru, rolului analiştilor şi proiectanŃilor şi a raportului dintre ei; - modalităŃile de administrare a proiectului (planificare, programare, urmărire).

Totodată, metodologiile au rolul de a indica modul de desfăşurare a acestui proces, stabilind [2]: - componentele procesului de realizare a sistemului informatic (etape, subetape,

activităŃi, operaŃii) şi conŃinutul lor; - fluxul parcurgerii (executării) componentelor; metodele, tehnicile, procedeele,

instrumentele, normele si standardele utilizate. În funcŃie 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 [2].

Metodele utilizate în proiectarea sistemelor informatice reprezintă modul unitar sau maniera comună în care analiştii de sisteme, programatorii şi alte categorii de persoane implicate, realizează procesul de analiză a sistemului informaŃional-decizional existent, proiectarea şi introducerea sistemului informatic. Deci, metoda are un caracter general, în cadrul ei aplicându-se anumite tehnici de lucru [2].

Tehnicile de lucru utilizate în proiectarea sistemelor informatice reprezintă felul în care se acŃionează eficient şi rapid, în cadrul unei metode, pentru soluŃionarea

Sisteme informatice

14

diferitelor probleme ce apar în procesul de proiectare. Prin aceste tehnici se îmbină armonios cunoştinŃele despre metode cu măiestria personală a celor chemaŃi să aplice metodele si să utilizeze instrumentele adecvate [2].

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 funcŃie de situaŃia reală la care se referă.

În abordările incipiente se lucra cu probleme izolate şi ulterior s-a efectuat trecerea la abordarea sistemică (modulară), odată cu abordarea funcŃională sau, mai bine zis, cu analiza şi descompunerea funcŃională (în fiecare modul există câte o funcŃie) şi ulterior abordarea orientată-obiect [2]. 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 unităŃi componente prin rafinări repetate, metoda de proiectare putând 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 unităŃi economico-sociale numită organigrama unităŃii poate fi reprezentată printr-o astfel de diagramă ierarhică. Pentru unităŃi economice productive în organigramă se disting următoarele patru nivele de reprezentare [10]: - nivelul conducerii strategice, reprezentat de directorul general şi consiliul de

administraŃie; - nivelul conducerii tactice (directori pe funcŃiuni); - nivelul compartimentelor funcŃionale (servicii şi posturi de lucru) şi de proiectare,

cercetare (laboratoare) care asigură conducerea operativă a sistemului prin şefii lor; - nivelul compartimentelor de producŃie (secŃii, ateliere) care realizează funcŃia de

producŃie a sistemului economic. În strategia bottom – up evolutivă, se porneşte de la o tratare minimală care se

extinde treptat pe măsura înaintării î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 mulŃi autori astfel [1]: - metode orientate spre funcŃii, numite şi metode ale descompunerii funcŃionale; - metode orientate spre fluxuri date, deci metode orientate spre procese, deoarece

diagramele fluxurilor de date se întrebuinŃează pentru descrierea proceselor; - metode orientate spre informaŃie sau date, orientate-informaŃii, apărute ca urmare a

popularizării puternice a ingineriei informaŃiei a lui JAMES MARTIN, dar şi a diagramelor entitate-relaŃie ale lui CHEN [3];

- metode orientate-obiect. Caracteristici esenŃiale ale principalelor metode

InformaŃia este văzută de DeMarco în 1982, ca fiind posibil de abordat prin trei perspective specifice sistemelor informaŃionale sau prin trei dimensiuni: date, funcŃii, comportament.

15

Datele sunt surprinse din prisma structurii lor sub formă de atribute şi înseamnă de fapt, ceea ce are stocat, şi reflectă structura statică [1].

FuncŃiile scot în evidenŃă în mod limitat ceea ce face sistemul. El poate fi văzut şi ca un proces, întrucât elementele sistemului despre care se păstrează datele de rigoare sunt supuse unor transformării funcŃionale, prin intermediul proceselor [1].

Comportamentul este invocat pentru a reda o altă modalitate de percepŃie a sistemului, influenŃa evenimentele şi proprietăŃilor sistemului, şi sugerează dinamica lui [1].

Metoda descompunerii funcŃionale (orientate funcŃii) [1]. Dintre autorii remarcabili care au abordat descompunerea funcŃională îi enumerăm

pe câŃiva cum ar fi DeMarco, Yourdon şi Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl, Marco&Gowan. Descompunerea funcŃională este cea care anunŃă apariŃia proiectării structurate şi analizei structurate. Fiecare funcŃie este descompusă în subfuncŃii, până se obŃin structuri uşor de transpus în instrucŃiunile limbajelor de programare.

Metodele fluxurilor de date (orientate-proces) [1]. Prin această metodă analiştii efectuează reprezentarea lumii reale prin simboluri

care reprezintă fluxul datelor, transformările datelor, stocarea datelor, entităŃi externe, etc. Metoda orientată spre procese are încă un mare grad de asemănare cu descompunerea funcŃională.

Metode orientate spre informaŃii (orientate-date) [1] Două realizări importante în domeniu au dat tonul unei orientări în abordarea

sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaŃie, de către Peter P. Chen (1976) şi ingineria informaŃiei, în viziunea lui James Martin.

Metoda orientată-obiect [1] 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 aceeaşi structură şi un comportament similar.

1.3. INSTRUMENTE CASE

Problema CASE-ului (Proiectarea Sistemelor/Programelor asistată de calculator sau cu Ajutorul Calculatorului – Computer Aided Systems Engineering) a devenit foarte importantă la mijlocul anilor 1980, când hardul sa extins prin seria PC-urilor, iar reŃelele 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 cerinŃelor până la întreŃinerea fizică a produsului informatic. Totuşi, analiza şi proiectarea, bazate pe conceptele şi metodele structurate, reprezintă elementele forte ale instrumentelor CASE, iar în ultimii ani CASE a acordat atenŃia cuvenită analizei, proiectării şi programării orientate pe obiecte [1].

Sisteme informatice

16

Majoritatea produselor soft au fost construite în mod artizanal, fără posibilitatea testării complete a lor, fiind însoŃite de o documentaŃie destul de slabă. Instrumentele CASE implică utilizarea calculatorului ca un mijloc de susŃinere a activităŃilor de planificare, definire, proiectare şi realizare a softului. Ele se bazează pe logica structurală, pe descompunerea funcŃională şi reprezentarea prin diagrame a fluxurilor de date ale aplicaŃiilor.

Potrivit principiilor conceptuale, sistemele CASE au fost realizate pentru a încuraja abordarea logicii structurate şi pentru folosirea calculatorului ca un mod de tezaurizare a lucrărilor şi ca o planşetă de desen, pe care pot fi plasate reprezentările structurate ale sistemelor sau aplicaŃiilor. Pe măsura evoluŃiei lor, sistemele CASE au devenit mult mai complexe, permiŃând ca procesele de proiectare şi realizare a aplicaŃiilor să se desfăşoare într-un mediu informatic interactiv, oferind utilizatorilor un întreg arsenal de instrumente şi proceduri, prin care pot proiecta, realiza, testa, documenta, întreŃine/actualiza şi exploata sistemul.

Utilizarea produselor de tip CASE a fost determinată de [1]: - calitatea îndoielnică a aplicaŃiilor realizate în mod tradiŃional; - frustrarea utilizatorilor în încercarea lor de a participa la procesul de proiectare şi

realizare a aplicaŃiilor, datorită nivelului ridicat de cunoştinŃe informatice solicitate de metodele tradiŃionale;

- costuri deosebit de mari pe care le presupun întreŃinerea şi actualizarea softului funcŃional;

- imposibilitatea rezolvării tuturor cerinŃelor utilizatorilor; - limitarea posibilităŃii de reprezentare grafică a schemelor de realizare a noilor

proiecte. - Folosirea sistemelor CASE este motivată şi de următoarele avantaje: - reducerea complexităŃii logicii de descriere a sistemului; - posibilitatea de a alege dintre mai multe variante de proiectare; - creşterea vitezei de realizare a sistemelor; - realizarea succesivă a componentelor unui sistem; - creşterea integrării; - consolidarea disciplinei de proiectare; - oferirea unei interfeŃe de proiectare; - folosirea depozitelor modularizate; - salvarea şi refolosirea unor componente din diagramele realizate; - simplificarea activităŃilor de proiectare şi realizare a sistemelor/aplicaŃiilor.

Utilizarea sistemelor CASE a început cu introducerea diagramelor fluxurilor de

date, care fac posibilă realizarea unui model al derulării proceselor sistemului/aplicaŃiei care se proiectează. A urmat folosirea dicŃionarului de date ca un depozit al tuturor datelor privind sistemul sau aplicaŃia. Au apărut ecranele predefinite pentru a prezenta ce poate să obŃină utilizatorul prin exploatarea sistemului. S-a apelat la facilităŃile grafice, care pot folosi simbolurile logicii structurate şi care permit proiectantului să realizeze o diagramă coerentă a fluxurilor de date [1].

17

1.3.1. FuncŃiile CASE

Primele sisteme CASE erau un set de aplicaŃii neintegrate, cu funcŃii distincte, fără a fi interconectate. Aceste limite au fost eliminate, în cea mai mare parte, prin generaŃiile actuale, care încearcă să realizeze o integrare completă şi uşoară a tuturor elementelor, integrarea reprezentând, de fapt, factorul cel mai important al metodologiei CASE [1].

CASE se bazează pe două funcŃii fundamentale [1]. Prima funcŃie constă în posibilitatea descompunerii de sus în jos (top-down) a

sistemului informatic în procese şi module distincte, fiecare având definite responsabilităŃile funcŃionale şi/sau operaŃionale.

Cea de-a doua funcŃie se referă la faptul că sistemele informaŃionale pot fi reprezentate într-o formă grafică concisă, folosind câteva simboluri de bază. ImportanŃa acestor două funcŃii rezidă în posibilitatea utilizării modularităŃii aplicaŃiilor, a diagramelor, obŃinerea unei documentaŃii 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 documentaŃii, care include şi integrează caracteristicile proceselor şi paşii de parcurs, pentru descrierea modului de lucru; oferă un model al produsului final, ce poate fi folosit în realizarea operaŃiilor de exploatare şi întreŃinere a sistemului/aplicaŃiei, şi oferă o interfaŃă pentru păstrarea evoluŃiei proiectului.

Folosirea reprezentărilor grafice în logica CASE oferă posibilitatea descompunerii aplicaŃiei în mai multe componente logice. Prin ataşarea unei baze de date la elementele grafice, se va obŃine un depozit ce va conŃine paşii şi funcŃiile 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/aplicaŃiei. Modelarea grafică în sistemele CASE prezintă o interactivitate ridicată, permiŃând construirea diagramelor, deplasarea de la o diagramă la alta, modificarea, extinderea, copierea, evaluarea şi descrierea elementelor unei aplicaŃii [1].

Modelele grafice permit conectarea fluxurilor logice între activităŃile şi funcŃiile specifice aplicaŃiei, relaŃii care pot fi testate şi validate în mod automat.

1.3.2. Trăsături definitorii ale CASE-ului

EvoluŃia CASE-ului, a determinat apariŃia I-CASE-ului. Integrated CASE se referă la toate aspectele integrării, chiar dacă sistemele sunt deschise sau nu [1].

Caracteristicile mediilor moderne de tip CASE [1]: - un set de instrumente specifice pentru realizarea sistemelor; - diversitatea modurilor de interacŃiune; - semnificaŃia reprezentărilor grafice; - elemente de tip verificare şi validare (V&V); - natura bidirecŃională, deplasări pe verticală în structura sistemului; - deschidere pentru interconectarea instrumentelor CASE; - sprijin pentru lucrul cu utilizatori multipli;

Sisteme informatice

18

- descompunerea; - performanŃe de deplasare, pe orizontală, de la un instrument la altul; - grade diferite de automatizare; - INTEGRAREA.

CASE-ul nu este un proces independent. El constituie un set integrat de metodologii, care urmăresc realizarea ciclului de viaŃă al unui sistem. La sfârşitul fiecărei faze a ciclului de viaŃă, rezultatele obŃinute trebuie supuse unei analize şi verificări, iar utilizatorii trebuie informaŃi asupra modului de gestionare a procedurilor de lucru. Ei sunt cei care trebuie să dea avizul de continuare a parcurgerii fazelor următoare, 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 măsura desfăşurării operaŃiunilor, din faza de proiectare până la predarea produsului final. CASE poate sprijini aceste proceduri prin punerea la dispoziŃie a unei documentaŃii, critici sau modificări asupra elementelor din modelul proiectat. Pe acest fond, pot fi făcute evaluări, critici sau modificări asupra elementelor din modelul proiectat. Rezultatele obŃinute în urma proiectării unui anumit model de sistem constau în documentaŃia oferită, care acoperă întregul ciclul de viaŃă al sistemului, cu toate operaŃiile şi procedurile pe care le presupune. Datele din documentaŃia modelului sunt, de obicei, înlocuite cu cele reale şi se parcurg paşii de implementare a sistemului pentru a obŃine un model funcŃional. În plus, CASE oferă posibilitatea de a analiza ieşirile obŃinute şi de a le modifica pentru a reflectă schimbările intervenite în sistem, modulele definite şi depozitul de date [1]. 1.3.3. Exemple de instrumente CASE (ConferinŃa NaŃională de ÎnvăŃământ Virtual, ediŃia a III-a, 2005)

În literatura de specialitate, instrumentele CASE sunt clasificate şi după un alt criteriu decât cel al activităŃilor 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 întâlnesc următoarele trei categorii:

- instrumente CASE bazate pe metodologia structurată; - instrumente hibride, ce conŃin elemente specifice orientării-obiect, dar care nu

permit realizarea sistemelor orientate-obiect; - instrumente pur orientate-obiect.

În cele ce urmează se vor prezenta câteva 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. Având 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 documentaŃiei de realizare a sistemului informatic. Repository este componenta centrală a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaŃional: Informix, Ingres sau Oracle.

19

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). Editorul Designer este componenta ce oferă suport pentru proiectarea de detaliu a sistemului informatic. Proiectarea de detaliu a aplicaŃiei este strâns 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 execuŃie şi testarea aplicaŃiei. Generatorul de cod translatează specificaŃiile de proiectare în cod sursă. Astfel, pe baza diagramei entitate asociere se generează codul DDL (în SQL) ce defineşte structura fizică a bazei de date. Codul poate fi completat pentru a defini restricŃiile 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 aplicaŃiei este generat în limbajul C îmbogăŃit cu instrucŃiuni SQL pornind de la specificaŃiile din schemele de structură. Docwriter este componenta care permite generarea documentaŃiei pentru fiecare etapă de realizare a sistemului. Utilizarea produsului Westmount I-CASEY Yourdon îmbunătăŃeşte productivitatea realizării sistemelor informatice şi oferă garanŃii pentru calitatea sistemelor obŃinute. B) Metodologia orientată-obiect

Expresia „pur orientate-obiect" se referă la faptul că pe de o parte, instrumentele CASE conŃin numai elemente specifice abordării orientate-obiect a sistemelor, iar pe de altă parte la faptul că se bazează pe metodele şi tehnicile de analiză şi proiectare orientate-obiect. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de viaŃă al sistemelor, pot fi grupate ca şi cele convenŃionale, astfel:

- Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor; - Lower CASE orientat-obiect pentru generarea codului-sursă al aplicaŃiilor; - I-CASE orientat-obiect care acoperă întregul ciclu de viaŃă.

Deoarece tendinŃa se îndreaptă tot mai mult spre tehnologiile informaŃionale orientate-obiect, nici domeniul instrumentelor ce sprijină realizarea sistemelor nu poate să nu se adapteze la această orientare, lucru ce a dus la apariŃia a numeroase produse CASE orientate-obiect sau la reorientarea firmelor producătoare de instrumente convenŃionale spre înglobarea în produsele lor a elementelor specifice abordării obiectuale.

Designer/2000

Setul de instrumente Designer/2000 este parte integrantă din portofoliul de

instrumente de dezvoltare oferit de Oracle şi reprezintă o soluŃie integrată pentru

Sisteme informatice

20

dezvoltarea de sisteme client/server din generaŃia a doua sau de sisteme Intranet bazate

pe Web. Designer/2000 acoperă toate fazele ciclului de dezvoltare a aplicaŃiilor software,

pornind de la modelarea sistemului informatic (business modelling) până la exploatare.

Abordarea Designer/2000 bazată pe un Repository permite ca anumite componente sau

toate componentele să fie folosite pentru dezvoltarea rapidă de aplicaŃii scalabile, multi-

platformă, distribuite.

21

Capitolul 2 IniŃierea şi planificarea realizării unui sistem informatic

În cadrul acestui capitol vor fi prezentate o serie de aspecte privind primele

activităŃi desfăşurate în vederea realizării sistemelor informatice, activităŃi definite în literatura de specialitate sub numele de microanaliza sistemelor, componentă preluată din managementul proiectelor şi care are în vedere modalităŃile de identificare a proiectelor de dezvoltare a sistemelor informaŃionale, precum şi modul în care au loc iniŃierea şi planificarea acestora, în strânsă legătură cu planul strategic organizaŃional. 2.1. Identificarea, selecŃia, iniŃierea şi planificarea proiectelor

Identificarea şi selecŃia proiectelor de dezvoltare a sistemelor informaŃionale reprezintă prima etapă din ciclul de viaŃă a dezvoltării sistemelor care, împreună cu iniŃierea şi planificarea proiectelor, constituie microanaliza, componentă preluată din managementul proiectelor. EvidenŃierea acestor activităŃi în cadrul modelului cascadă de derulare a fazelor sau etapelor ciclului de viaŃă a sistemului este reprezentată în figura 4.1 [1].

A. identificarea şi selectarea proiectului

B. iniŃierea şi planificarea proiectului

C. analiza

D. proiectarea logică

E. proiectarea fizică

F. implementarea

G. întreŃinerea

Figura 2.1 Ciclul de viaŃă al dezvoltării sistemelor [1]

Din modelul prezentat rezultă că orice etapă se descompune în activităŃi, ceea ce

pentru identificarea şi selecŃia proiectelor înseamnă [1]:

microanaliza Fazele ciclului de viaŃă

al dezvoltării sistemului

Sisteme informatice

22

- identificarea potenŃialelor proiecte de dezvoltare; - clasificarea şi ierarhizarea lor; - selecŃia. Identificarea potenŃialelor proiecte de dezvoltare

Problema esenŃială a activităŃii de identificare a potenŃialelor proiecte de dezvoltare a sistemului constă în nominalizarea celor ce pot fi abilitaŃi să facă propuneri pertinente. Aceştia pot fi: top-managerii, comitetul de iniŃiativă, departamentul utilizatorilor, grupul de dezvoltare. Caracteristicile esenŃiale ale variantelor de proiecte propuse în cele patru situaŃii sunt prezentate tabelul 2.1.

Tabel 2.1-variante de proiecte [1]

Propuneri Metoda de selecŃie a proiectului

Caracteristicile proiectului

Top-managerii • orientare puternică spre strategie; • cele mai mari dimensiuni ale proiectului; • cele mai de durată proiecte.

De sus în jos Comitetul de iniŃiativă • orientare mixtă (a diferiŃilor reprezentanŃi); • vizează schimbările organizaŃionale cele mai mari; • analiză formală a costurilor şi avantajelor proiectelor; • proiecte mai mari şi mai riscante.

Departamentul utilizatorilor

• limitat, neorientat strategic; • realizare mai rapidă; • câŃiva utilizatori reprezintă niveluri ale conducerii,

precum şi funcŃiile întreprinderii.

De jos în sus

Grupul de dezvoltare • integrare în sistemul existent; • puŃine întârzieri în realizarea proiectului; • mai puŃin interesat de analizele cost – avantaje.

SelecŃia proiectelor de dezvoltare a sistemelor informaŃionale

Datorită efectelor diferite şi a amplitudinii lor, se recomandă evidenŃierea distinctă a proiectelor pe termen lung şi a celor pe termen scurt. Dintre ele se selectează cele ce ating obiectivele organizaŃiei. De asemenea, se va urmări modul în care proiectele se aliniază dinamicii unităŃii.

IniŃierea şi planificarea proiectelor

Pentru realizarea acestei faze este nevoie de comunicarea efectivă dintre părŃile implicate( analişti, clienŃi - manageri, utilizator).

23

IniŃierea proiectului

Din momentul selecŃiei lui, proiectul trece în faza de iniŃiere, ceea ce presupune desfăşurarea unei activităŃi laborioase, prestată de un responsabil, cunoscut în practică sub numele de manager de proiect, care răspunde de [1]: - Elaborarea unor studii de fezabilitate generală; - Elaborarea planurilor detaliate ale proiectelor; - Găsirea celor mai buni membri ai echipei proiectului.

Managerul de proiect trebuie să dea dovadă de multe calităŃi pentru a putea jongla cu elemente cum sunt: - Schimbările tehnologice; - Ciclul de viaŃă al sistemelor; - Contractori şi furnizori; - Managementul resurselor umane; - Metodologie şi instrumente de lucru diferite; - RestricŃii de timp şi resurse; - Documentare şi comunicare; - Aşteptările managerilor şi clienŃilor.

ActivităŃile efectuate în faza iniŃierii proiectului sunt: 1. stabilirea echipei de iniŃiere a proiectului; 2. stabilirea bunelor relaŃii cu beneficiarii; 3. stabilirea planului iniŃierii proiectului; 4. stabilirea procedurilor manageriale; 5. stabilirea cadrului de desfăşurare a proiectului şi a manualului de operare al

acestuia.

Planificarea proiectului

Planificarea proiectului va cuprinde o evaluare a cerinŃelor informaŃionale ale sistemului la nivelul întregii organizaŃii.

Planificarea proiectului este procesul prin care are loc definirea clară a activităŃilor şi a eforturilor necesare înfăptuirii lor în cadrul fiecărui proiect.

Tipurile activităŃilor executate în cadrul planificării proiectului cuprind [1]: 1. Descrierea ariei de întindere, a variantelor şi fezabilităŃii proiectului 2. Descompunerea proiectului în activităŃi uşor executabile şi controlabile 3. Estimarea resurselor şi crearea unui plan al resurselor 4. Realizarea unei prime planificări calendaristice 5. Realizarea unui plan al comunicărilor 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

Sisteme informatice

24

2.2. Analizele de fezabilitate

Elaborarea unui sistem informatic poate costa milioane de dolari şi se poate realiza pe parcursul a trei până 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 informaŃiile obiective necesare pentru a cunoaşte dacă un proiect poate fi demarat sau nu, sau dacă un proiect deja început mai poate fi continuat. ProporŃiile şi durata studiilor de fezabilitate variază, în funcŃie de mărimea şi natura sistemului implementat. În cazul sistemelor bazate pe calculatoare mari, studiul are cu totul alte dimensiuni faŃă de varianta utilizării microcalculatoarelor [1].

Totuşi, fezabilitatea proiectului poate fi studiată în orice fază a elaborării lui, dar studiile, de regulă, se efectuează în momente certe. Când este propus un proiect, se efectuează un studiu preliminar de fezabilitate pentru a se stabili dacă proiectul atinge obiectivele propuse de unitate. Analiza, în prima ei fază, poate fi oricât de subiectivă, întrucât proiectul nu este reprezentat cu lux de amănunte. Însă, îndată ce se obŃine o situaŃie mai clară despre sistem, despre natura problemei de rezolvat, precum şi despre doleanŃele utilizatorilor, măsurarea preliminară a fezabilităŃii poate fi determinată odată cu faza de analiză a sistemului. Când proiectanŃii oferă două sau trei variante de elaborare a sistemului, numai studiile de fezabilitate o pot scoate în relief pe cea optimă.

După ce a avut loc proiectarea primară a sistemului, pot fi determinate în detaliu elementele de cost ale proiectării, implementării şi exploatării. Este ultima şansă a unităŃilor de a mai putea renunŃa la sistem, înaintea implementării lui.

Pe parcurs, odată cu progresul înregistrat în dezvoltarea sistemului informatic, se obŃin informaŃii din ce în ce mai certe, oferindu-se posibilitatea unor analize de fezabilitate mult mai concludente, ceea ce atrage studierea fezabilităŃii în diverse faze ale ciclului de viaŃă al sistemelor. De fiecare dată, studiile de fezabilitate trebuie să aibă la bază o foarte bună documentaŃie. Aceasta va conŃine [1]: - Definirea problemei ( o scurtă descriere a proiectului şi explicarea a ceea ce-şi

propune el să realizeze); - Descrierea cerinŃelor sistemului; - Descrierea soluŃiilor sistemului propus; - ExplicaŃia critică a motivării 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.

DocumentaŃia planificării poate fi alcătuită 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 activităŃile planificate. Lungimea barelor este

25

proporŃională cu timpul alocat activităŃilor reprezentate. Se pot folosi diferite culori, umbre sau forme pentru a scoate în relief anumite activităŃi. Ceea ce s-a planificat şi realizat, de asemenea, pot fi evidenŃiate prin bare paralele de culori, forme sau umbre diferite.

Diagramele Gantt nu indică ordinea activităŃilor (precedenŃa lor), ci indică data începerii şi pe cea a finalizării.

Se recomandă pentru descrierea proiectelor simple sau a unor componente ale proiectelor mari, sau a activităŃilor prestate doar de o singură persoană, precum şi pentru monitorizarea modului în care se efectuează activităŃile în comparaŃie cu cele planificate (ca dată) .

Sisteme informatice

26

EvidenŃa promovării vânzărilor (EPV)

Aprilie 2005

Mai 2005 Iunie 2005

Iulie 2005

August 2005

Septem-brie 2005

Nr. Crt.

Nume activitate

1. Colectarea

cerinŃelor

2. Proiectare ecrane

3. Proiectare rapoarte

4. Proiectare baze de date

5. DocumentaŃie utilizator

6. Programare 7. Testare 8. Instalare 9. ŞedinŃa de

analiză

Proiect: EPV Data: Analist:

Critic: În lucru: Sinteză: Necritic: Punct de reper: Derulat:

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

27

Capitolul 3 Analiza sistemului existent şi definirea cerinŃelor noului sistem

În cadrul acestui capitol este prezentată prima etapă a ciclului de viaŃă al

sistemelor informatice, etapă prin care se determină modul în care funcŃionează sistemul informaŃional curent şi se evaluează ceea ce ar dori utilizatorii să realizeze noul system .Astfel, sunt prezentate o serie de aspecte privind: - determinarea cerinŃelor sistemului; - metodele tradiŃionale utilizate în analiza şi determinarea cerinŃelor sistemulu

(interviul şi chestionarul); - metode moderne de analiză şi determinare a cerinŃelor sistemului (JAD,

prototipizarea); - structurarea cerinŃelor sistemului - modelarea logică a datelor şi prelucrărilor

(diagramele fluxurilor de date DFD); - modelarea conceptuală a datelor (diagramele entitate – relaŃie, DER). 3.1. Studiul sistemului informaŃional existent

Prin sistem existent se înŃelege realitatea obiectivă din organizaŃia pentru care urmează a se realiza sistemul informatic solicitat printr-o comandă numită cererea beneficiarului.

Analiza sistemului existent şi definirea cerinŃelor noului sistem este prima etapă din ciclul de viaŃă al dezvoltării sistemelor informatice, etapă prin care se determină modul în care funcŃionează sistemul informaŃional curent şi se evaluează ceea ce ar dori utilizatorii să realizeze noul sistem. Studiul şi analiza sistemului existent are ca obiectiv principal stabilirea cerinŃelor informaŃionale ale conducerii în vederea realizării unui sistem informatic.

Studiul sistemului existent cuprinde un grup de activităŃi care urmăresc cunoaşterea performantelor tehnico-funcŃionale ale sistemului informaŃional, atât în ansamblul său, cât şi pentru elementele de structura ale acestuia, a cerinŃelor informaŃionale ale conducerii, cunoaşterea lipsurilor şi restricŃiilor pe care le prezintă sistemul existent faŃă de aceste cerinŃe. De modul de realizare a acestor activităŃi depinde întregul proces de realizare a sistemului informatic [2].

Studiul sistemului existent constă în [2]: - definirea caracteristicilor generale ale sistemului economic; - studiul activităŃilor de bază desfăşurate în sistem; - studiul sistemului de conducere; - studiul sistemului informaŃional; - identificarea metodelor şi mijloacelor tehnice.

Definirea caracteristicilor generale ale sistemului economic implică : - cunoaşterea profilului, obiectivelor agentului economic; - cunoaşterea locului în sfera serviciilor si sfera producŃiei; - cunoaşterea relaŃiilor de cooperare cu alŃi agenŃi economici; - cunoaşterea specificului activităŃii de bază ( producŃie, servicii);

Sisteme informatice

28

- cunoaşterea nivelului tehnic; - cunoaşterea principalilor indicatori economici şi evoluŃia lor; - dezvoltarea, modernizarea etc.

Studiul activităŃilor desfăşurate în sistemul economic, modul de realizare a funcŃiunilor unităŃii economice se face prin [2]: 1. Pe baza statutului de funcŃionare a societăŃii se studiază:

- activităŃile şi sarcinile din cadrul acestor funcŃiuni; - atribuŃiile ce revin compartimentelor; - modul de realizare a activităŃilor funcŃionale din cadrul unităŃii economice.

2, În cazul activităŃii de producŃie se prezintă: - fluxul de producŃie, amplasarea locurilor de muncă, depozitelor etc.; - tipurile de produse, structura lor, ciclurile de realizare; - modul de organizare a producŃiei, stocarea producŃiei, transporturile interne,

controlul de calitate; - resursele existente:

- capacităŃi; - asigurarea tehnică / proiectarea de produse noi; - norme tehnice;

- asigurarea cu materiale necesare; - sistemul existent de programare a producŃiei.

Studiul sistemului de conducere se referă la [2]: - identificarea caracteristicilor sistemului de conducere existent; - sistemul de indicatori cantitativi şi valorici; - organizarea conducerii; - caracteristicile rezultate din statutul de funcŃionare a societăŃii, tipuri de decizii,

modul de lucru a deciziilor.

Studiul sistemului informaŃional presupune [2]: - elaborarea schemei fluxului informaŃional global (cu punerea în evidenŃă a

principalelor activităŃi şi a legăturilor statice şi dinamice dintre acestea); - estimarea cantitativă şi calitativă a informaŃiilor de intrare-ieşire, modul de

culegere şi prelucrare; - identificarea principalilor algoritmi, regulilor de calcul şi a punctelor si regulilor

de control; - cunoaşterea principalelor restricŃii ale sistemului informaŃional; - situaŃia raŃionalizării fluxurilor şi a documentelor din unitatea economica, studii

elaborate, stadiul lor de implementare; - sistemul de codificare utilizat, restricŃii; - performanŃele şi limitele sistemului informaŃional existent.

Identificarea metodelor şi mijloacelor tehnice utilizate pentru prelucrarea datelor în cadrul sistemului informaŃional existent se face evidenŃiind: mijloacele tehnice existente în dotarea unităŃii economice ( modul de utilizare, cheltuielile de exploatare, personalul implicat, performante); existenŃa unor aplicaŃii proiectate şi/sau implementate [2].

29

3.2. Determinarea cerinŃelor sistemului

Determinarea cerinŃelor sistemului este activitate esenŃială în aflarea situaŃiei existente şi a ceea ce se doreşte în viitor. Rezultatul activităŃii de determinare a cerinŃelor sistemului se concretizează în diferite forme ale informaŃiilor colectate, cum sunt copii ale interviurilor, însemnări efectuate în timpul observării şi analizei documentelor, interpretări ale răspunsurilor la chestionare, seturi de formulare, rapoarte, descrieri ale posturilor de lucru ş.a., precum şi rezultate ale prelucrărilor efectuate de calculator, cum ar fi prototipurile [1].

Rezultatele prezentate după această activitate pot fi rezumate astfel: 1. InformaŃii obŃinute în urma conversaŃiilor cu utilizatorii sau prin observarea

activităŃilor prestate de aceştia: copii sau sinteze ale interviurilor, răspunsurile la chestionare sau interpretări ale acestora, însemnări şi rezultate din observarea activităŃilor, procese verbale ale şedinŃelor ce au avut loc în acest scop;

2. InformaŃii 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 documentaŃia sistemului existent, rapoartele consultanŃilor [1];

3. InformaŃii obŃinute cu ajutorul calculatorului: rezultate ale sesiunilor JAD, copii ale fişierelor sesiunilor grupului de sprijinire a sistemului, conŃinutul depozitelor şi rapoartele existente în CASE, ecrane şi rapoarte rezultate din prototipurile sistemului, ş.a [1].

3.2.1. Metodele tradiŃionale utilizate în analiza şi determinarea cerinŃelor sistemului

Analiza sistemului informaŃional-decizional fiind, în general, axată pe sistemul obiect, metodele utilizate sunt în general comune cu cele ale analizei economice [2].

Metodele utilizate frecvent în analiza sistemului existent sunt: - Interviul; - Chestionarul.

Interviul este o metodă foarte răspândită pentru culegerea informaŃiilor din sistemul informaŃional. Utilizatorii acestei metode sunt în general analiştii care nu sunt familiarizaŃi cu unitatea studiată şi cu problemele ei. Prezintă avantajul că lasă foarte multă libertate creativa analistului în construirea şi desfăşurarea lui [2]. În alegerea persoanelor de intervievat trebuie avute în vedere următoarele constatări [10]: - persoanele care ocupă poziŃii medii în ierarhia structurii organizatorice furnizează

informaŃiile cele mai apropiate de realitate; - colectarea de informaŃii corecte necesită intervievarea atât a personalului de

conducere, cât şi a celui de execuŃie; - în prealabil trebuie verificată competenŃa subiecŃilor intervievaŃi; - lipsa unei atitudini critice poate să denote reŃineri î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 către persoanele intervievate.

Sisteme informatice

30

Chestionarul poate fi utilizat atât de către analiştii începători, cât şi de către cei avansaŃi, familiarizaŃi sau nu cu problemele informaŃionale-decizionale ale unităŃii. Prin utilizarea lui dispare “filtrul de informaŃii” care este analistul iar cel care furnizează informaŃii are posibilitatea să se concentreze mai bine asupra răspunsurilor. Utilizând această metodă, participă un număr mare de “furnizori de informaŃii”. Limitele chestionarului constau în faptul că este o metodă de verificare a unor cunoştinŃe prealabile, fapt ce implică cunoaşterea prealabilă a domeniului.

Această metodă necesită timp relativ îndelungat pentru întocmirea chestionarului precum şi de culegere şi prelucrare a răspunsurilor. Chestionarul nu are o arie largă de utilizare [2].

3.2.2. Metode moderne de analiză şi determinare a cerinŃelor sistemului

Ca efect al tendinŃelor de mărire a timpului de analiză a sistemelor existente, în ultimii ani, s-a efectuat trecerea spre analiza mai puŃin pronunŃată a sistemelor ce urmează a se realiza. Tehnicile moderne, JAD şi prototipizarea, preiau tot mai puŃine 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 [1].

Joint Application Design(JAD) Spre sfârşitul anilor 1970, specialiştii în realizarea de sisteme de la IBM au elaborat

un nou proces de culegere a cerinŃelor informaŃionale ale sistemelor şi de revizuire a proiectelor sistemelor, numindu-se JAD [1].

Ideea principală a lui JAD o constituie punerea laolaltă a tuturor forŃelor interesate în dezvoltarea sistemelor: utilizatori-cheie, managerii şi analiştii de sistem implicaŃi în analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totuşi în sesiunea JAD se urmăreşte o anumită secvenŃă de derulare a activităŃilor, pe baza unor roluri bine stabilite.

Prototipizarea şi determinarea cerinŃelor sistemelor Prototipizarea este un proces interactiv prin care analiştii şi utilizatorii pun în

discuŃie o versiune rudimentară a unui sistem informaŃional, care va fi într-o continuă schimbare, în funcŃie de reacŃia utilizatorilor. Prototipizarea renunŃă la ciclul de viaŃă al dezvoltării sistemelor sau la creşterea rolului său [1].

Pentru culegerea informaŃiilor despre cerinŃele utilizatorilor încă se apelează la interviuri, dar prin prototipizare, operaŃiunea va fi mai simplă şi va solicita un timp mai scurt. Prototipul este văzut şi testat de utilizator, având posibilitatea să precizeze ce ar mai dori, dar şi să-şi genereze această formă nouă, cu ajutorul specialiştilor [1].

Prototipizarea este facilitată de câteva limbaje sau produse program, inclusiv instrumentele de tip CASE.

Prototipizarea este foarte utilă în determinarea cerinŃelor sistemului când [1]: - cerinŃele utilizatorului nu sunt prea clar formulate sau bine înŃelese; - unul sau mai mulŃi utilizatori sau susŃinători sunt implicaŃi în sistem; - anumite mijloace de lucru (formulare şi rapoarte predefinite).

Prototipizarea generează şi deficienŃe, cum ar fi:

31

- tendinŃa de evitare a unui cadru formal de elaborare a documentaŃiei privind cerinŃele sistemului, ceea ce va îngreuna în viitor orice control;

- fiind conceput de un număr mic de utilizatori va fi probabil respins de viitorii utilizatori;

- fiind conceput izolat este puŃin probabil ca el să fie integrat în sistemul existent; - nerespectându-se etapele ciclului de viaŃă al dezvoltării sistemelor pot fi omise

aspecte esenŃiale, cum ar fi securitatea, controlul datelor introduse şi standardizarea la nivel de sistem.

Paşii prototipizării sunt [1]: - Identificarea cerinŃelor principale ale sistemului; - Realizarea prototipului iniŃial; - Proces iterativ de adaptare a sistemului la cerinŃele utilizatorului; - Folosirea sistemului aprobat de utilizatori.

După determinarea cerinŃelor sistemului urmează structurarea acestora prin utilizarea unor instrumente specifice de modelare logică. 3.3. Structurarea cerinŃelor sistemului - modelarea logică a datelor şi prelucrărilor

Indiferent de metodologiile folosite în realizarea unui sistem/aplicaŃie, toate

apelează la operaŃiunea de modelare logică a datelor şi prelucrărilor sub formă de

diagrame, diferenŃele constând doar în folosirea mai pronunŃată a diagramelor pentru

descrierea sistemului, încadrându-le în diagrame de context, diagrame ale fluxurilor de

date fizice şi diagrame ale fluxului de date logice. Altele apelează la combinaŃii de

diagrame, tabele şi forme descriptive [1].

Diagrama de context scoate în evidenŃă aria de întindere a sistemului analizat, prin specificarea elementelor din interiorul organizaŃiei şi a celor externe, sub denumirea de entităŃi externe sistemului analizat.

3.3.1. Diagramele fluxurilor de date (DFD)

Diagrama fluxului de date ale nivelului logic curent, independentă de tehnologie, reliefează funcŃiile de prelucrare a datelor executate de către sistemul informaŃional curent.

Diagrama de flux de date ale sistemului logic nou va prezenta circuitul datelor, structura lor şi cerinŃele funcŃionale ale noului sistem.

Descrieri ale obiectelor DFD se regăsesc în aşa-zisele dicŃionare ale proiectelor sau depozitele CASE (repository) [1].

Diagramele fluxului de date DFD au ca obiectiv urmărirea modului de transfer al datelor între procesele de prelucrare a lor, astfel de diagrame se mai numesc şi modele ale proceselor de prelucrare, iar operaŃiunea se numeşte modelarea proceselor.

DFD reprezintă doar una din tehnicile de analiză structurată.

Sisteme informatice

32

Tehnica de redare a proceselor de prelucrare prin intermediul diagramelor fluxurilor de date a căpătat noi accepŃiuni prin încorporarea ei în instrumentele de analiză şi proiectare cu ajutorul calculatorului, adică în instrumente CASE [1]. Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru

construirea DFD

Când analizăm sistemele folosim frecvent reprezentările grafice, de exemplu diagramele. În continuare vom folosi tehnica reprezentării grafice a fluxului informaŃional. Proiectarea fluxului informaŃional reprezintă circulaŃia informaŃiei în sistem, transformările suferite de acesta, stocarea informaŃiei precum şi scurgerile de informaŃie în afara sistemului.

Scopul diagramelor de date DFD pentru o anumită componentă organizatorică sau funcŃională la care se referă (secŃie, birou, compartiment, întreaga unitate, o anumită activitate – vânzări, cumpărări, încasări, plăŃi, ş.a) este de a scoate în relief, într-o manieră cât mai sugestivă, următoarele aspecte [1]:

- sursa datelor de prelucrare; - operaŃiunile de prelucrare prin care trec datele; - destinaŃia datelor prelucrate; - legătura existentă între prelucrări şi activitatea de stocare a datelor.

Întocmirea diagramelor de flux de date (DFD)

DFD este o reprezentare grafică a transformării datelor de intrare în date de ieşire folosind un set de simboluri de reprezentare şi un set de reguli de completare şi validare.

33

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 număr(descriere a funcŃiei procesului de prelucrare, începând cu un verb, urmat de o descriere a obiectului funcŃiei de prelucrare). În DFD fizică pentru sistemul existent, se va preciza şi locaŃia (compartiment / persoană) procesului.

flux de date: este constituit din datele transmise între două procese.

Fluxul de date este etichetat printr-un substantiv ce sugerează informaŃia sau pachetul de informaŃii transmise.

entitate externă (terminator): sursă / receptor de date. Poate fi un alt

sistem (organizaŃie, compartiment).

stoc de date: un depozit temporar sau permanent de date.

Poate fi: - manual: registre, dosare, arhivă de documente - pe suport magnetic: fişiere.

ConvenŃii folosite în diagramele de reprezentare a DFD: - procesele şi stocurile de date sunt numerotate secvenŃial, pentru a putea fi

identificate. Numerele asociate proceselor nu semnifică ordinea de execuŃie a acestora;

- pentru a evita fluxurile de date întretăiate şi aspectul de “păienjeniş” al diagramei, entităŃile 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 stângă a cutiei;

- pentru a face diagramele mai lizibile, entităŃile externe sunt plasate, pe cât posibil, în jurul diagramei iar stocurile de date, în partea centrală a diagramei;

- fluxurile de date de la - către stocurile de date sunt unidirecŃionale (fie de adăugare, fie de consultare) si nu sunt etichetate.

3.3.2. Descompunerea funcŃională şi rafinarea DFD

Dacă sistemul pe care-l descriem cu ajutorul DFD este complex, va fi dificil să realizăm de la început o DFD detaliată. Pentru a putea descrie în detaliu sistemele complexe, metodele structurate propun o abordare TOP-DOWN, respectiv o

Sisteme informatice

34

descompunere funcŃională a sistemului, care este realizată prin rafinarea succesivă a proceselor.

Primul nivel (nivelul 0) îl constituie DIAGRAMA CONTEXTUALĂ, care defineşte graniŃele între sistemul analizat si mediu.

Nivelele următoare se obŃin prin rafinarea proceselor complexe într-o diagramă de nivel inferior.

În cazul aplicaŃiei Decontări, au rezultat următoarele diagrame:

Figura 3.1. Diagrama contextuală pentru aplicaŃia Decontări

35

Figura 3.2. Diagrama fluxului de date de nivel 1 pentru aplicaŃia Decontări

Sisteme informatice

36

Figura 3.3. Diagrama fluxului de date de nivel 2 pentru aplicaŃia Decontări

Definirea direcŃiilor de perfecŃionare a actualului sistem Pe baza activităŃilor de evaluare şi analiză critică se identifică neajunsurile

actualului sistem şi se propun soluŃii de înlăturare a acestora se formulează variante de soluŃii, iar în cadrul acestora se definesc cerinŃele şi restricŃiile de realizare a sistemului informatic.

Definirea direcŃiilor de perfecŃionare presupune: 1. specificarea obiectivelor şi a performantelor sistemului informatic; 2. stabilirea domeniilor de probleme şi a principalelor funcŃiuni ale sistemului

informatic; 3. definirea cerinŃelor si restricŃiilor informaŃionale pe domenii de probleme şi funcŃiuni

care constă în: - definirea principalelor intrări/ ieşiri; - definirea soluŃiei de organizare a datelor; - definirea variantelor tehnologice de prelucrare; - definirea restricŃiilor informaŃionale şi de control.

4. formularea condiŃiilor pentru realizarea sistemului informatic, care constă în: - specificarea termenelor şi duratelor solicitate; - precizarea priorităŃilor în realizarea obiectivelor sistemului informatic;

37

- specificarea cerinŃelor speciale privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare al sistemului.

Pentru fiecare variantă de soluŃie 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, o problemă este comună: el va fi înlocuit de un nou sistem. Oricât 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Ńă. Tocmai 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ă conŃină una sau mai multe DFD, un model de date şi logica procesului de prelucrare. Problema comună ar consta în identificarea unei căi de realizare a modelului logic al sistemului propus [1].

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 neapărat schimbat din sistemul curent şi ceea ce trebuie să se realizeze în cel nou. Deci, modelul logic propus poate fi conceput pe baza modelului logic curent.

Pornind de la modelul fizic, se derivă modelul logic în cadrul căruia se realizează: - pune în evidenŃă ce face sistemul, eliminând detaliile referitoare la modul cum

funcŃionează sistemul în implementarea actuală; - pune în evidenŃă funcŃiunile de bază ale sistemului; - permite identificarea şi eliminarea problemelor legate de redundanŃa datelor şi

duplicarea proceselor de prelucrare; - permite stabilirea cu o mai mare precizie a graniŃelor 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 alcătuit de la procesele “frunză” şi va continua prin agregarea proceselor către nivelurile superioare.

Se parcurg următorii paşi: 1. Identificarea stocurilor logice de date - se face pe modelul logic al datelor prin gruparea într-un stoc logic de date a entităŃilor înrudite sau utilizate frecvent.

După identificarea stocurilor logice de date se construiesc: - diagrama de corespondenŃă între stocuri logice şi entităŃile din modelul logic; - diagrama de corespondenŃă între stocuri fizice şi stocuri logice de date.

Sisteme informatice

38

2. Înlăturarea dependenŃelor fizice şi temporale din denumirea proceselor şi a fluxurilor de date: din DFD la nivel fizic (se observă că nu există referinŃe fizice şi temporale în aplicaŃia decontări). 3. Derivarea proceselor logice: - scoaterea în afara graniŃelor 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ă prelucrări asemănătoare sau multiple care se

execută împreună sau în secvenŃă; - înlăturarea proceselor care Ńin de implementarea actuală şi a proceselor redundante. - În cazul aplicaŃiei prezente: - se combină procesele “Înregistrare încasări în numerar” şi “Înregistrare încasări prin

virament” deoarece realizează prelucrări asemănătoare; - se înlătură procesele redundante “Înregistrare încasări în jurnal” si “Înregistrare plăti

în jurnal”. 4. Derivarea fluxurilor logice care presupune înlocuirea numelui de document numai cu fluxul de informaŃii utilizate efectiv de proces. 5. Gruparea proceselor elementare şi transformarea diagramei fizice în diagramă

logică, aplicând cei 5 paşi.

RelaŃia existentă între DFD şi modelul datelor După cum reiese din prezentările anterioare, fiecare săgeată 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ă. Când 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ă operaŃiunea, dar foarte important este să prezentăm structura datelor păstrate. Firesc, şi în cazul fluxului de date, şi în cel al stocării lor nu trebuie uitată descrierea semnificaŃiei economice. Structura datelor trebuie să fie redusă la a treia formă normalizată, iar conŃinutul locurilor de stocare a datelor să fie prezentat prin reduceri la unul sau mai multe tabele relaŃionale în forma a treia normalizată [1].

În cazul aplicaŃiei decontări, se obŃine următoarea DFD a sistemului logic. Decontări cu beneficiarii .Nivelul elementar al DFD a sistemului logic. Nivelele superioare ale DFD a sistemului logic sunt identice.

39

Figura 3.4. Diagrama fluxului de date Tabel 3.1 aplicaŃia Decontări

Sursa DestinaŃia Nume flux Continutul fluxului 1.1. Înregistrare facturi desfacere

D2 FACTURI DESFACERE

desfaceri CODCLIENT DENCLIENT ADRESAC CONTC BANCA_C DATAFACTD NRFACTD TOTALFACTD

D2 FACTURI DESFACERE

1.3. Analiza situaŃie client desfaceri CODCLIENT DENCLIENT ADRESAC CONTC BANCA_C NRFACTD TOTALFACTD

Sisteme informatice

40

3.3.4. Modelarea logicii proceselor

După ce au fost descrise procesele de conversie a datelor în informaŃii, prin intermediul diagramelor fluxurilor de date DFD, deoarece ele nu reliefează şi logica internă a proceselor, oricât ar fi de detaliate, chiar şi la nivelul proceselor primare, se impune apelarea la alte tehnici pentru descrierea logicii proceselor. Procesele trebuie astfel descrise încât să poată fi convertite în programe prin intermediul limbajelor de programare [1].

În faza de analiză modelarea logicii proceselor se va derula cât mai detaliat şi complet posibil, dar operaŃiunea nu va respecta structura sau sintaxa unui anumit limbaj de programare: aceasta se va realiza într-o etapă ulterioară proiectarea. Modelarea logicii proceselor ca şi diagramele fluxurilor de date face parte din etapa de analiză a sistemului.

În analiza structurată, rezultatele obŃinute în urma modelării proceselor sunt descrieri şi diagrame structurate care vor prezenta logica fiecărui proces, precum şi diagrame care vor evidenŃia dimensiunea temporală a sistemelor, când apar procesele sau evenimentele şi modul în care aceste evenimente schimbă starea sistemului [1].

Pe scurt se poate spune că modelarea logică a proceselor se va concretiza în următoarele elemente ale documentaŃiei [1]:

- reprezentarea în engleza structurată; - reprezentarea logicii proceselor prin tabele de decizie; - reprezentarea logicii proceselor prin arbori de decizie; - tabelul sau diagrama stărilor de tranziŃie.

Reprezentarea logicii proceselor prin engleza structurată

Engleza structurată este o formă mult simplificată şi modificată a limbii engleze, folosită pentru descrierea conŃinutului casetelor care marchează procesele (prelucrările) din diagrama fluxului de date. Cuvintele folosite sunt în strânsă legătură cu logica folosită în conceperea procedurilor componente ale sistemelor informatice [1].

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 documentaŃie. Utilizarea englezei structurate pentru procesul “Analiza situaŃie client” din decontări cu beneficiarii este reprezentată mai jos.

Analiza situaŃie client WRITE CLIENTI,FACTURI_DESF, ÎNCASĂRI 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)) {

41

if (cod!=FACTURI_DESF.codclient) { CLIENTI.codclient = cod; CLIENTI.denclient = den; CLIENTI.adresac = adr; CLIENTI.contc = cont; 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(ÎNCASĂRI); vb=0; vb1=0; while (not eof (ÎNCASĂRI) AND vb=0) { if (cod=ÎNCASĂRI.client AND FACTURI_DESF.nrfactd=ÎNCASĂRI.nrfactd AND FACTURI_DESF.datafactd =ÎNCASĂRI.datafactd) { if (FACTURI_DESF.totalfactd !=ÎNCASĂRI.sumaincasata) { sold = sold+ FACTURI_DESF.totalfactd - ÎNCASĂRI.sumaincasata} vb1=1; } else if (vb1=1) vb=1 READ (ÎNCASĂRI) } MOVE FIRST LINE ÎNCASĂRI READ (FACTURI_DESF) } CLOSE (FACTURI_DESF, ÎNCASĂRI, CLIENTI) 3.4. Modelarea conceptuală a datelor (diagramele entitate – relaŃie, DER)

În cadrul modelării conceptuale a datelor se va renunŃa la abordarea proceselor şi

se va trece la abordarea sistemelor prin prisma datelor. La fel ca şi în cazul modelării

proceselor şi modelării logicii proceselor elementele esenŃiale vor fi diagramele.

James Martin şi Carma McClure, atunci când reliefează importanŃa tehnicilor structurate prin obiectivele ce şi le propun, consideră că o parte a acestora au legătură şi cu datele, şi anume [1]:

Sisteme informatice

42

- Să se realizeze o administrare riguroasă a datelor. Administrarea datelor se referă la structurarea corectă a datelor, la uniformitatea modalităŃilor 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 esenŃiale ale sistemelor: resursele.

- Să se efectueze o analiză sănătoasă a datelor. Analizele datelor clarifică problemele de structurare a lor şi conduc la structuri stabile ale acestora, concretizate prin costuri reduse ale realizării sistemelor. Dacă baza de date a unităŃii este deosebit de importantă, atunci pe analiza datelor trebuie să se pună un accent aparte, ea fiind întotdeauna realizată înaintea proiectării programelor. Firesc, dacă ştim care sunt cerinŃele unui sistem (ieşirile), imediat ne vom pune întrebarea din ce se obŃin acestea (intrările) şi apoi vom urmări cum se pot obŃine ieşirile (procesele).

Obiectivul principal al ingineriei informaŃiei este crearea unui set de metodologii care să poată fi folosite în cele mai diverse medii de lucru, astfel încât să se construiască modele ale datelor la nivele 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 văzute două categorii mari de operaŃiuni:

- asigurarea datelor (creare, actualizare); - utilizarea datelor (obŃinere de documente, de diverse rapoarte, analize „What-If”,

sprijin decizional, diferite căutări de informaŃii, control şi auditare întreprindere). Modelul conceptual al datelor înseamnă o modalitate de reprezentare a datelor

organizaŃiei. Rolul său este de a scoate în relief toate regulile privind identitatea şi legăturile existente între date [1].

Cea mai cunoscută formă utilizată pentru modelarea datelor este diagrama entitate-relaŃie (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, operaŃiunea are loc la nivel de întreprindere, prin apelarea la o categorie foarte largă de date neglijându-se detaliile exagerate. Doar în etapele următoare, în speŃă când se trece la definirea proiectului, are loc construirea unui model anume entitate-relaŃie prin care să fie scoasă în evidenŃă aria de întindere a proiectului. În timpul structurării cerinŃelor, un model entiatate-relaŃie reprezintă cerinŃele conceptuale de date pentru sistemul luat în discuŃie. După ce sunt descrise complet intrările şi ieşirile sistemului în cadrul proiectării logice, modelul conceptual al datelor, redat sub forma entitate-relaŃie, este rafinat înainte de a fi trecut într-un format logic (de regulă, un model relaŃional al datelor) din care se definesc bazele de date şi are loc proiectarea fizică a acestora [1].

DER joacă un rol deosebit de important în formarea profesională a veritabililor analişti.

Se consideră că, în timpul modelării conceptuale a datelor, se produc şi se analizează cel puŃin patru diagrame entitate-relaŃie [1]:

43

1. DER care să acopere datele necesare aplicaŃiei proiectului. Ea va permite stabilirea necesarului de date ale aplicaŃiei proiectului, fără să se Ńină seama de constrângerile sau confuziile generate de detaliile care nu sunt încă necesare.

2. DER pentru aplicaŃia ce va fi înlocuită. DiferenŃele dintre aceste diagrame arată ce schimbări trebuie întreprinse pentru convertirea bazei de date în noua aplicaŃie. Nu se aplică în cazul sistemelor complet noi.

3. DER care să scoată în relief întreaga bază de date din care noua aplicaŃie îşi va extrage datele. Cât timp mai multe aplicaŃii pot folosi aceeaşi bază de date, această diagramă şi prima evidenŃiază modul în care noua aplicaŃie apelează la conŃinutul unor baze de date mult mai extinse.

4. DER pentru întreaga bază de date din care aplicaŃia curentă îşi extrage datele necesare. Ea este discutată doar pentru sistemele care există şi pentru care se urmăreşte îmbunătăŃirea. Din nou, diferenŃele dintre diagrama precedentă şi cea de faŃă vor indica modificările majore de efectuat pentru a se putea influenŃa noua aplicaŃie.

Metodele de determinare a cerinŃelor trebuie să fie orientate, prin întrebările puse, prin anchetele efectuate, şi asupra datelor, nu numai asupra proceselor şi logicii lor. La început, chiar fără utilizarea unei terminologii de specialitate, analistul va fi preocupat de modul în care va afla cât mai multe informaŃii despre datele necesare viitorului sistem pentru a funcŃiona la parametrii proiectaŃi. Întrebările vor fi astfel formulate încât să se realizeze o bună înŃelegere 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: când şi cum sunt prelucrate sau folosite datele, pentru a se realiza modelarea datelor [1].

Modelarea datelor se realizează printr-o combinaŃie a punctelor de vedere. Un prim punct de vedere, formulat în literatură sub numele de metoda top-down, va

scoate în evidenŃă regulile derulării activităŃii firmei, printr-o înŃelegere foarte clară a naturii afacerii, şi nu se va opri asupra detaliilor privind modul în care ecranele, rapoartele sau documentele sunt folosite în organizaŃie [1].

În afara metodei top-down, informaŃiile necesare construirii modelului datelor se pot obŃine şi prin urmărirea documentaŃiei firmei, ecrane, rapoarte, formulare, din interiorul sistemului. Acest proces este cunoscut în literatura de specialitate sub numele de metoda bottom-up [1].

Elementele rezultate vor figura în diagramele fluxurilor de date prin care vor fi evidenŃiate datele prelucrate în sistem şi de aici va rezulta necesarul de date menŃinute în baza de date a sistemului.

Definirea conceptului de entitate

EntităŃile 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 simŃită prezenŃa la un moment dat [1].

La rândul lor, obiectelor li se pot asocia cel puŃin două evenimente: apariŃia şi dispariŃia lor. Exemple: încheierea şi încetarea contractului de muncă; predarea produselor la secŃia expediŃie şi desfacerea lor la beneficiari ş.a.

Sisteme informatice

44

La fel putem spune şi despre evenimente. Ele reprezintă asocieri între două sau mai multe obiecte. Exemplu: CLIENT COMANDĂ PRODUS.

EntităŃile conŃin în structura lor atributele prin care ele sunt descrise. O entitate este o persoană, un loc, un obiect, eveniment sau concept din domeniul

de activitate a utilizatorului despre care organizaŃia doreşte să păstreze anumite date. Se cuvine precizată diferenŃa dintre tipurile entităŃilor (entity types) şi cazurile/instanŃele entităŃii (entity instances) [1].

Tipul entităŃii, cunoscut şi sub numele de clasa entităŃii, este o colecŃie de entităŃi care au proprietăŃi sau caracteristici comune. Fiecărui tip de entitate i se atribuie un nume. Cât timp numele reprezintă o clasă sau un set de cazuri, el este singular. Şi încă o convenŃie. Cum referirea generală la elementele ce pot fi catalogate ca entităŃi se poate face prin noŃiunea de obiect (deşi sensul lui poate fi altul în contextul analizei şi proiectării orientate obiect), referirea la acesta se va realiza printr-un substantiv la singular. Se vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzător entităŃii.

O instanŃiere a entităŃii sau instanŃă, denumită de noi în continuare, caz al entităŃii 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/instanŃe ale acestei entităŃi 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 entităŃi care prezintă interes

pentru organizaŃie. La rândul lor, şi relaŃiile pot avea propriile lor atribute. Exemplu de entitate pentru aplicaŃia DECONTĂRI şi unele dintre atributele

posibile: CLIENT : CodClient, DenClient, AdresaC Ca şi numele tipurilor entităŃilor, numele atributelor sunt substantive scrise cu

majuscule, plasate în interiorul elipselor, legate de entitatea căreia i se asociază. De multe ori însă, chiar şi în cazul folosirii produselor CASE, pentru a nu se încărca o diagramă entitate-relaŃie, se evită prezentarea atributelor. OperaŃiunea se face, în schimb, în repository, depozitul de informaŃii despre proiect. Aici orice atribut se descrie separat, ca orice obiect distinct.

Unul dintre exemplele anterioare poate fi reprezentat în diagramă conform fig. 3.5.

Figura 3.5. Model de reprezentare a atributelor DER

CLIENT

DenClien

AdresaC CodClient

45

Cheie candidat şi cheie primară Fiecare tip de entitate trebuie să aibă un atribut sau un set de atribute prin care să se

efectueze diferenŃierea unui caz de acelaşi tip. O cheie candidat aste un atribut sau o combinaŃie de atribute prin care se poate

identifica în mod unic un caz (o instanŃă) al tipului entităŃii respective. Sunt entităŃi care pot avea două sau mai multe chei-candidat. În exemplul nostru,

pot fi chei-candidat CodClient, NumeClient, AdresaC (presupunând că ele identifică în mod unic un angajat). Atunci când sunt mai multe chei-candidat, proiectantul trebuie să decidă care din ele va fi folosită 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 [1].

În reprezentările din DER, în elipsa sau elipsele aferente atributului sau atributelor ce formează cheia primară, numele respective se subliniază (vezi CodClient din entitatea CLIENT ).

RelaŃiile entităŃilor

RelaŃiile reprezintă legăturile între componentele unei diagrame entitate-relaŃie. O relaŃie este o asociere între cazurile/instanŃele uneia sau mai multor tipuri de entităŃi care prezintă interes pentru organizaŃie. Ele se pot simboliza printr-un romb. De regulă, relaŃiile sunt redate prin verbe. Cardinalitatea relaŃiilor

Presupunem că există două tipuri de entităŃi, A şi B, între care există o linie de legătură pentru a marca relaŃia. Cardinalitatea unei relaŃii este dată de un număr al cazurilor/instanŃelor entităŃii B care pot sau care ar putea să fie asociate cu fiecare caz al entităŃii A. Cardinalitatea este sugerată prin 0 (zero), 1, M (“multe”), cu menŃiunea că ele pot avea prezenŃă obligatorie sau opŃională. Trimiterea la cardinalitate se face în moduri destul de diferite, în funcŃie de notaŃia folosită. Recomandăm citirea cu atenŃie a diagramelor şi descifrarea elementelor strict necesare înŃelegerii, îndeosebi pentru reflectarea cardinalităŃii. De exemplu, ea poate fi notată cu semne (0, 1, M, N) sau prin simboluri (linie cu vârf simplu de săgeată pentru 1, linie cu vârf dublu de săgeată pentru M. Alteori, 1 se reprezintă prin linie simplă şi M prin vârf de săgeată). În multe materiale, inclusiv produse CASE, se foloseşte notaŃia model-date, cunoscută mai mult sub numele laba-gâştei, conform cârei cardinalitatea se reprezintă prin următoarele simboluri [1]:

obligatoriu 1

opŃional 0 sau 1

n obligatoriu multe (n, unde n ia valori de la 1 la M)

n opŃional 1 sau multe (n, unde n ia valori de la 1 la M)

CURS_CREDIT STUDENT

Înscris pentru

Figura 3.6. Tip RelaŃie

Sisteme informatice

46

EntităŃi compuse sau asociative (gerundive) Atributele pot fi asociate cu o relaŃie multe-la-multe sau cu o entitate. Un exemplu,

din lumea cursurilor-credit, transferabile în cadrul unei perioade. Un student poate lua mai multe cursuri dintr-o listă, dar finalizarea cu notă se poate efectua în momente (la date) diferite. Prezentăm, mai jos, câteva dintre datele concrete [1]:

MATRICOLA STUDENT NUME CURS DATA PROMOVĂRII 1111 Informatică Iulie 1999 1177 Informatică Septembrie 1999 1155 Informatică Septembrie 1999 1111 Drept comercial Ianuarie 2000

Din analiza cazurilor rezultă că atributul DATA_PROMOVĂRII nu este o proprietate a entităŃii STUDENT, cât timp examenele pot fi date la momente diferite. Dar nu este nici o proprietate a entităŃii CURS, cât timp acelaşi curs poate fi susŃinut la date diferite. În schimb, DATA_PROMOVĂRII este o proprietate a relaŃiei dintre STUDENT şi CURS. Atributul se asociază relaŃiei şi se prezintă sub formă de diagramă, ca în fig. 3.7.

Figura 3.7. Asocierea unui atribut la o relaŃie [1]

De aici rezultă un caz aparte de entitate, numită gerundivă sau compusă sau asociativă care, de fapt, este o relaŃie folosită de analist în model ca un tip de entitate. În astfel de cazuri, se foloseşte un simbol special: dreptunghi cu romb în interior, în care se scrie numele entităŃii (fig. 3.8) [1].

STUDENT Promovare CURS

DATA PROMOVĂRII

STUDENT Promovare CURS

DATA PROMOVĂRII

47

Figura 3.8. Redarea unei entităŃi gerundive (asociative) [1]

Nu trebuie confundată această situaŃie cu relaŃiile transformate în entităŃi

nepurtătoare de informaŃii, descrise anterior. Scopul diagramelor entitate-relaŃie este de a surprinde cele mai complete sensuri

posibile ale datelor necesare sistemului informaŃional din organizaŃie.

Tipuri de relaŃii Din cele prezentate mai sus, rezultă că între entităŃile descrise, luate două câte

două, se pot identifica trei tipuri de relaŃii: unu-la-unu, unu-la-multe, multe-la-multe. În diagrame, descrierea relaŃiilor se face de-a lungul liniilor care leagă cele două entităŃi. Simbolul vârf-de-săgeată este cunoscut ca indicator al cardinalităŃii (cardinality indicator).

În cele ce urmează sunt prezentate exemple de tipuri de relaŃii [1]. 1. RelaŃia unu-la-unu (1:1)

Figura 3.9. Descrierea relaŃiei 1:1

„Fiecare BIROU este condus de un, şi numai un, MANAGER” „Fiecare MANAGER conduce un, şi numai un, BIROU”.

2. RelaŃia unu-la-multe (1:M)

Figura 3.10. Descrierea relaŃiei 1:M „Fiecare VÂNZARE implică unul sau mai multe ATRICOL(e)_VÂNDUT(e) “ „Fiecare ATRICOL_VÂNDUT face parte din numai o VÂNZARE”

3. RelaŃia multe-la-multe

Figura 3.11. Descrierea relaŃiei M:N

“Fiecare FURNIZOR livrează unul sau mai multe PRODUS(e)” “Fiecare PRODUS este livrat de unul sau mai mulŃi FURNIZOR(i)”

BIROU MANAGER este condus de

conduce

implică VÂNZARE ARTICOL VÂNDUT face parte din

livrează FURNIZOR PRODUS este livrat de

Sisteme informatice

48

În anumite cazuri, între două entităŃi pot exista mai multe relaŃii. De exemplu, s-ar putea spune că “FURNIZOR oferă PRODUS”, dar şi “PRODUS

este cumpărat de la FURNIZOR”, ceea ce s-ar putea reprezenta ca în fig. 3.12.

Figura 3. 12. Descrierea relaŃiilor multiple între două entităŃi

4. RelaŃii opŃionale şi obligatorii Alteori, relaŃiile dintre entităŃi nu-şi fac simŃită prezenŃa în toate situaŃiile. Chiar

cazul cu studiile la care lucrează diverse persoane este destul de elocvent; o persoană poate să lucreze la un singur studiu sau la câteva, sau la niciunul şi, invers, un studiu poate fi efectuat de o persoană, de mai multe sau de nici una. În astfel de situaŃii, se apelează la următoarea formă de reprezentare. (fig. 3.13)

Figura 3.13. Exemplu de relaŃie opŃională Cercul suprapus pe latura entităŃii indică, de fapt, poziŃia 0 (valoarea minimă poate

fi şi zero), conferind relaŃiei caracterul opŃional. Un alt aspect se referă la caracterul obligatoriu al relaŃiilor. Cu alte cuvinte, o

entitate poate exista fără cealaltă? Să luăm exemplul vânzărilor. În relaŃia 1:M, dintre VÂNZARE şi

ARTICOL_VÂNDUT. Ar fi total eronat ca o entitate să existe fără cealaltă: nu poate fi o vânzare fără cel puŃin un articol vândut şi, invers, un articol nu poate fi vândut fără o vânzare (operaŃiunea nu ar avea sens). Simbolul folosit pt a marca relaŃiile obligatorii este acelaşi cerc, cu deosebirea că este haşurat.

Figura 3.14. Exemplu de relaŃie obligatorie

5. RelaŃia unei entităŃi cu ea însăşi În practică, apar şi situaŃii în care o entitate este pusă în relaŃie cu ea însăşi.

PRODUS FURNIZOR

oferă

este cumpărat de la

PERSOANA STUDIU este realizat de

lucrează la

VÂNZARE ARTICOL VÂNDUT

49

Ne oprim la exemplul entităŃii ANGAJAT. Unii dintre ei dobândesc statutul de coordonatori ai activităŃii celorlalŃi, situaŃii în care se poate apela la o diagramă de genul celei din fig.3.15.

Figura 3.15. Redarea relaŃiei unei entităŃi cu ea însăşi Reprezentarea anterioară se citeşte astfel: “Un angajat poate fi coordonatorul unuia sau mai multor angajaŃi” “Oricare angajat întotdeauna raportează altui angajat”

6. RelaŃii alternative (sau/sau) Uneori se ivesc situaŃii când relaŃiile posibile se redau alternativ: fie o variantă este

de urmat, fie cealaltă. De exemplu, o marfă destinată vânzării 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 legătură cu cele două surse posibile, PRODUCłIA_ALTORA şi PRODUCłIA_PROPRIE, printr-un punct comun, dar nu cu linii de relaŃii distincte, aşa cum este prezentat în figura 3.16.

Figura 3.16. Exemplu de diagramă pentru relaŃiile alternative Citirea diagramei este: “O marfă se poate asocia sau cu un producător din afară, sau cu producŃia unităŃii” “Un producător din afară poate livra mai multe mărfuri” “O linie proprie de producŃie poate livra mai multe mărfuri”

Deşi diagramele entitate-relaŃie se cunosc de către mulŃi specialişti din lumea bazelor de

date, ele constituie unul din conceptele esenŃiale ale analizei şi proiectării structurate şi,

ca atare, provin din acest domeniu [1].

După cum reiese şi din citirea cu atenŃie a numelui diagramei, scopul ei este de a evidenŃia entităŃile de date (obiectele despre care se solicită păstrarea datelor) şi relaŃiile ce există între ele.

MARFA

PRODUCłIA PROPRIE

PRODUCłIA ALTORA

coordonator al ANGAJAT

raportează la

Sisteme informatice

50

De remarcat diferenŃa dintre diagrama fluxului de date şi diagrama entitate-relaŃie. În timp ce diagrama fluxurilor de date indică atât procesele de prelucrare, cât şi entităŃile de date (redate fie sub forma fluxurilor de date, fie a locurilor de stocare), DER tratează doar entităŃile de date. Din această cauză, DER poate fi considerată şi ca diagrama modelului datelor sau diagrama conceptuală a datelor [1].

În sistemul analizat pentru descrierea DER se apelează la simbolul dreptunghi, pentru fiecare entitate. Se recomandă ca numele entităŃii să fie redat printr-un substantiv la singular (CLIENT, PRODUS, SALARIAT, FACTURA_DESFACERE, ÎNCASĂRI).

După ce se identifică entităŃile se continuă cu împerecherea lor, fiecare cu fiecare, pentru a descrie relaŃiile dintre ele.

Figura 3.17. DER pentru aplicaŃia Decontări

51

3.4.1. Modelul Entitate/RelaŃie (E/R) Cercetările efectuate pentru definirea unui model de date care să permită

reprezentarea cât mai fidelă a realităŃii au condus la definirea conceptului de model semantic încă din 1976 când Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astăzi 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, fără a Ńine seama de anumite constrângeri 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 realităŃii avute în vedere, constituind astfel o etapă intermediară în proiectarea unei baze de date, fiind din acest punct de vedere asemănător pseudocodului utilizat în activitatea de programare.

Modelul Entitate/RelaŃie (E/R) permite reprezentarea schematică a realităŃii avute în vedere cu ajutorul unei diagrame E/R definită plecând de la conceptele de bază: tip de entitate, tip de relaŃie (legătură, corelaŃie), atribut.

Pentru reprezentarea unor probleme complexe de tip bază de date, apărute începând din anii 80, modelul de date semantic a fost extins cu noi concepte semantice, rezultând astfel modelul entitate relaŃie extins EER. În acest sens la conceptele de bază au fost adăugate conceptele suplimentare de superclasă, subclasă şi moştenire.

O superclasă reprezintă un tip de entitate care conŃine 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 rândul său subclase, astfel încât se pot construi ierarhii de clase. O subclasă moşteneşte toate atributele superclasei, putând 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ă [11], [13] o serie de simboluri reprezentate în figura 3.18.

Sisteme informatice

52

Reprezentare tip entitate cu numele <nume tip entitate>

Reprezentare atribut cheie cu numele <nume atribut>

<nume tip entitate>

<nume atribut>

Reprezentare atribut cu numele <nume atribut>

<nume atribut>

<nume tip relaŃie>

Reprezentare tip de relaŃie cu numele <nume tip relaŃie>

RELAłIA R FUNCłIONALĂ FAłĂ DE TIPUL

RELAłIA R NEFUNCłIONALĂ FAłĂ DE TIPUL

E R

E R

Superclasa

Subclasa

APARTENENłA SUBCLASEI LA

<nume tip entitate>

<nume atribut>

ApartenenŃa atributului <nume atribut> la tipul de entitate <nume tip entitate>

<nume atribut>

Reprezentare atribut derivat cu numele <nume atribut>

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

<nume atribut>

<atribut1>

<atribut2>

FIG. 3.18. SIMBOLURI UTILIZATE ÎN REPREZENTAREA UNEI

DIAGRAME EER

53

Problemă rezolvată

Folosind modelul entitate - relaŃie să se reprezinte diagrama E/R pentru un

sistem informatic simplificat al unei firme care desfăşoară activitate de comerŃ fiind

avute în vedere subsistemele;

- aprovizionare (evidenŃa furnizorilor); - desfacere (situaŃia vânzărilor); - urmărirea stocurilor.

FURNIZORI Oferte

PRODUSE

m n

Cod furnizor

Cod produs

Fig. 3.19. Subsistemul Aprovizionare. Reprezentarea relaŃiei de tip m-n Oferte

PRODUSE Vânzări

CLIENTI

m n

Cod produs

Cod client

Fig. 3.20. Subsistemul Desfacere. Reprezentarea relaŃiei de tip m-n Vânzări

Desfacere

PRODUSE

STOCURI

Intrări

Ieşiri

1 n

1 n

Aprovizionare Cod produs Cod Produs+Depozit+PreŃ

Fig. 3.21. Subsistemul Urmărirea stocurilor. Reprezentarea relaŃiilor de tip 1-n Intrări, Ieşiri, pentru actualizarea stocurilor

Sisteme informatice

54

PRODUSE

Cod produs Denumire produs

Descriere produs

Fig. 3.22. Reprezentarea entităŃii PRODUSE

PRODUSE

Cod furnizor Denumire furnizor

Adresa furnizor

Fig. 3.23. Reprezentarea entităŃii FURNIZORI

Stradă Număr

Oferta

Oferte

Cod produs Unitate de măsură

PreŃ unitar produs

Fig. 3.24. Reprezentarea relaŃiei Oferte

Cod furnizor

55

3.5. Selectarea celei mai bune variante strategice de proiectare

Întregul efort depus până în momentul de faŃă s-a concretizat într-o bogată acumulare de informaŃii despre cerinŃele sistemului, structurate sub diverse forme, precum şi despre modul în care am dori să fie conceput noul sistem sau ce corecŃii să i se aducă celui vechi.

Ne aflăm în aşa-zisa fază a strategiei proiectului. În afara certitudinilor concretizate în specificaŃiile elaborate până acum, asupra

variantei noului sistem planează şi o seamă de incertitudini, generate de nehotărârea sau, încă, needificarea asupra formei finale dorite. Un cuvânt greu au utilizatorii şi finanŃatorii proiectului. Pentru a-i ajuta să ajungă la o concluzie finală comună, trebuie pornit de la cerinŃele structurate şi se vor prezenta câteva strategii concurente de proiectare, dintre care doar una va fi continuată în pasul următor al ciclului de viaŃă al sistemului, faza de proiectare, în funcŃie de performanŃele ei şi de încadrarea în resursele disponibile [1].

Rezultatul final al studiului de identificare a cerinŃelor de informaŃii se concretizează într-un raport detaliat al cerinŃelor sistemului, în care vor fi prezentate informaŃiile necesare noului sistem. Raportul cuprinde tot ceea ce trebuie să fie produs de către sistem. El va lăsa fazei de proiectare o imagine clară a modului în care se vor obŃine cerinŃele sistemului.

Raportul conŃine următoarele elemente [1]: - descrierea funcŃiilor principale executate în noul sistem, inclusiv ce trebuie făcut şi de

cine, cum se realizează interfaŃa funcŃiilor cu întregul sistem şi cum funcŃiile noi vor afecta utilizatorii;

- descrierea tuturor datelor necesare sistemului, inclusiv nume, mărimea, format, sursă, importanŃă, precum şi o listă a regulilor pentru a se asigura securitatea şi controlul datelor;

- o structură preliminară a datelor, prin care se va arăta cum datele vor fi organizate în înregistrări logice şi care este legătura dintre date;

- descrierea modului de funcŃionare a noului sistem şi a subsistemelor componente, precum şi a modului în care vor fi atinse obiectivele de către întregul organism;

- descrierea şi prezentarea unui exemplar al tuturor intrărilor în sistem, inclusiv numele fiecărei intrări, sursa, cine îl completează, ce date va conŃine şi cum vor fi culese datele din el;

- o descriere şi un model de exemplar pentru fiecare ieşire din sistem (rapoarte, documente);

- descrierea unor norme interne de conduită privind raportările, programarea activităŃilor, securitatea şi protecŃia, personalul implicat şi zona de acces pe categorii ale acestuia;

- prezentarea restricŃiilor existente în sistem, cum ar fi statutele şi regulamentele de organizare.

Sisteme informatice

56

CAPITOLUL 4

PROIECTAREA LOGICĂ A SISTEMELOR INFORMATICE

În cadrul acestui capitol este realizată prezentarea noului sistem prin prezentarea

tuturor intrărilor sistemului, a ieşirilor, precum şi a interfeŃelor şi dialogurilor. Având în vedere intrările şi ieşirile sisemului este prezentată proiectarea logică a bazei de date, activitate prin care se urmăreşte transformarea diagramelor entitate-relaŃie în relaŃii.

Dacă în primele etape, au fost identificate şi structurate cerinŃele sistemului, în faza de proiectare logică se efectuează deplasarea atenŃiei de la prezentarea a ceea ce există şi ce se intenŃionează la descrierea a ceea ce va însemna noul sistem, cum va funcŃiona.

Modul de percepere a noului sistem se va reda prin prezentarea tuturor intrărilor sistemului, a ieşirilor, precum şi a interfeŃelor şi dialogurile. Ele se construiesc pe baza a ceea ce s-a identificat în etapele anterioare, dar Ńinându-se cont şi de cerinŃele identificate în timpul desfăşurării activităŃilor din etapa de proiectare logică [1].

Toate intrările şi ieşirile sistemului, în faza de proiectare logică, vor fi prezentate ca fluxuri ale datelor între un proces manual şi altul automat sau între o sursă/ destinaŃie şi un proces automat din diagramele fluxurilor de date. De regulă se poate proiecta câte un formular sau raport pentru fiecare flux de date dintre utilizator şi sistem.

DocumentaŃia realizată în cadrul acestei etape constituie proiectul tehnic de ansamblu al sistemului.

4.1. Proiectarea formularelor/formatelor şi a rapoartelor

În cadrul etapei de analiză a sistemului informatic, intrările şi ieşirile au fost identificate şi prezentate, exprimând cerinŃele informaŃionale la nivelul fiecărui subsistem/ aplicaŃie informatică. În acel moment nu s-au prezentat toate detaliile privind formularele/formatele, rapoartele şi procesul de modelare a datelor, insistându-se mai mult pe identificarea şi descrierea lor. Fiecare format/formular de intrare va fi asociat unui flux al datelor de intrare într-un proces al DFD, iar rapoartele se pot regăsi î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 conŃine unele date predefinite, cărora 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 informaŃia.

În faza de proiectatre logică se reprezintă doar o ciornă a formularelor/formatelor, rapoartelor sau ecranelor, ele fiind privite doar ca structură şi machetă. Ceea ce ne propunem în cadrul proiectării logice poate fi realizat cu ajutorul unui editor de texte sau un produs program orientat spre grafică, sub forma unui prototip [1].

57

4.1.1. Proiectarea situaŃiilor cu rezultate finale (rapoartelor)

Obiectivul prezentării detaliate a ieşirilor este şi acela de a determina formatul şi conŃinutul tuturor rapoartelor imprimate şi ale documentelor şi ecranelor furnizate de sistem.

Proiectarea ieşirilor se va face astfel încât să servească pentru [2]: - transmiterea rezultatelor prelucrării pe calculator utilizatorului, într-o formă pe

care acesta să o înŃeleagă şi în care să-şi regăsească cerinŃele sale; - transmiterea proiectului situaŃiilor finale programatorului, fără ambiguităŃi, pentru

a-i permite acestuia trecerea la întocmirea programelor necesare editării sau vizualizării.

În proiectarea ieşirilor, analistul trebuie să elaboreze un model demonstrativ al raportului sau ecranului şi să întrebe utilizatorul dacă informaŃiile din raport şi formatul acestuia sunt accesibile. Dacă ieşirile sunt inacceptabile, analistul trebuie să le modifice [1].

Un instrument util pentru formatul rapoartelor sau ecranelor realizate pe calculator îl constituie macheta imprimantei [2].

Macheta imprimantei este reprezentarea de detaliu a situaŃiei de ieşire, cuprinzând: - antet; - titlu; - date de identificare; - cap de tabel; - date elementare ce se imprima rând de rând; - totalurile. - detalii şi indicaŃii tehnice de realizare care se referă la:

- volumul datelor de ieşire; - frecvenŃă; - număr de copii şi destinaŃia fiecăreia; - grad de precizie al calculelor; - condiŃii speciale de editare; - criterii de control, validare şi interpretare a datelor de ieşire.

SpecificaŃiile de ieşire vor cuprinde, pentru utilizator, macheta situaŃiei iar pentru programator macheta situaŃiei şi o serie de indicaŃii tehnice de realizare.

Pe baza specificaŃiilor de ieşire se trece la proiectarea fizică prin care se alege suportul informaŃiilor de ieşire, se realizează definitivarea formei şi formatului de editare a situaŃiilor (aşezarea în pagina / ecran, spaŃierea între coloane şi rânduri, etc.) şi se definitivează procedurile de utilizare şi interpretare a ieşirilor [2].

Alegerea tipului de suport fizic de ieşire (imprimanta, display, disc fix, floppy disc, banda magnetica etc.) se face în funcŃie de: timpul de răspuns solicitat, amplasarea utilizatorului faŃă de calculator, hard-ul şi soft-ul existent, costul suportului, măsura în care răspunde necesitaŃilor de redare a conŃinutului informaŃional al situaŃiei finale [2].

Când se pregătesc ieşirile, este bine să se ia în calcul ce se urmăreşte prin ele, astfel încât apelarea la categoriile de date de mai sus să se efectueze în cunoştinŃă de cauză.

Sisteme informatice

58

În definitivarea formei şi formatului de prezentare a situaŃiilor finale trebuie să Ńinem seama de o serie de considerente practice cum ar fi [2]:

- Respectarea unor cerinŃe ale factorilor de decizie privind macheta situaŃiei

finale; - RestricŃii tehnice; - Elemente de eficienŃă; - Lizibilitate – spaŃiere; - Utilizarea formularelor pretipărite; - Utilizarea monitoarelor sau terminalelor video; - Utilizarea generatoarelor de rapoarte.

Respectarea unor cerinŃe ale factorilor de decizie privind macheta situaŃiei finale

O serie de cerinŃe ale conducerii privind macheta situaŃiei finale obligă proiectantul la o anumită structurare şi machetare a situaŃiilor finale. InformaŃiile se pot împărŃii în două grupe prin prisma sistemelor informatice interne şi externe. InformaŃiile interne reprezintă acele informaŃii culese, generate sau folosite în interiorul organizaŃiei. InformaŃiile externe se referă la cele colectate sau create de la sau pentru parteneri străini (facturi, rapoarte anuale, etc) [2].

În funcŃie de informaŃiile care pot fi văzute din punct de vedere al echipei manageriale distingem: informaŃii curente, de atenŃionare, indicatori de bază, etc. RestricŃii tehnice

În proiectarea situaŃiilor finale intervin o serie de restricŃii datorate caracteristicilor şi performanŃelor tehnice ale echipamentelor periferice şi anume: numărul maxim de caractere pe linie; numărul maxim de linii pe pagina / ecran; facilităŃile 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 obŃinerii diverselor tipuri de situaŃii finale [2]. Elemente de eficienŃă

În proiectarea situaŃiilor finale nu trebuie sa scape atenŃiei şi aspectele de eficientă economică privind: reducerea timpului calculator consumat cu editarea propriu-zisa a situaŃiilor; economie de hârtie de imprimantă. Abilitatea şi experienŃa proprie a programatorilor joacă în acest sens un rol important.

În vederea optimizării obŃinerii situaŃiilor finale pe imprimantă se pot folosi de la caz la caz, diverse tehnici cum ar fi: editarea mai multor tabele pe aceeaşi pagină de imprimantă; editarea unei situaŃii imprimând faŃă/verso pe aceeaşi coală;

Pentru a nu irosi timp cu editarea unor situaŃii finale voluminoase se recomandă mai întâi 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 situaŃiilor finale. Programele care editează situaŃii finale voluminoase trebuie prevăzute cu posibilitatea de întrerupere (respectiv de reluare a editării în cazul unor incidente ivite în timpul rulării) sau editarea lor sub forma unui fişier ASCII sau text pe hard disc sau floppy disc, urmând imprimarea ulterioara a acestui fişier, total sau parŃial [2].

59

Lizibilitate – spaŃiere Parcurgerea unei situaŃii finale trebuie să fie cât mai uşoara, “citirea” unei situaŃii

nu trebuie să dea naştere la ambiguităŃi. Este necesar ca situaŃia sa fie autoexplicativă. Pentru aceasta, antetul va conŃine informaŃii şi coduri ce vor indica sursa de emitere a raportului, exprimând clar, sintetic, conŃinutul raportului şi perioada la care se referă.

Capul de tabel, împreuna cu titlul şi antetul, se afişează pe următoarele pagini numai dacă au intervenit schimbări în cadrul caracteristicilor de grupare faŃă de prima pagină, altfel se imprimă doar numerotarea coloanelor de tabel.

InformaŃiile importante pot fi subliniate. Totalurile se separă de informaŃiile analitice. InformaŃiile care se repetă pe linii succesive se imprimă o singură dată [2]. Utilizarea formularelor pretipărite

Aceasta implica utilizarea unei hârtii de imprimanta ce cuprinde elemente fixe ale situaŃiei finale, cum ar fi antetul, titlul, capul de tabel, textul explicativ etc. Aceasta conduce la o creştere a vitezei de editare şi o diminuare a uzurii imprimantelor, riboanelor etc. Totodată situaŃiile obŃinute sunt mai estetice şi sunt uşor de parcurs de utilizatori [2]. Utilizarea monitoarelor sau terminalelor video

Prin intermediul unui soft adecvat, monitoarele sau terminalele video oferă posibilitatea afişării situaŃiilor finale, atât în regim alfanumeric, cât şi în regim grafic, alegerea modului de lucru făcându-se prin intermediul unor comenzi sau comutatori.

Ecranul unui terminal video în regim alfanumeric este alcătuit din linii şi coloane iar în regim grafic ecranul este privit ca o matrice de puncte denumite “pixeli”.

Reprezentarea informaŃiilor de ieşire sub forma grafică reprezintă un pas înainte faŃă de editarea sub forma de text a rapoartelor. Această formă de afişare se recomandă factorilor de decizie de pe nivelele de conducere superioare, dat fiind gradul de sintetizare a informaŃiilor de ieşire şi volumul redus al rapoartelor.

Pe lângă problemele legate de aşezarea informaŃiilor pe ecran, la proiectarea ecranelor de ieşire se iau în considerare şi facilităŃile oferite de monitoare sau terminalele video şi anume: regimul de lucru (defilare ecran, pagina sau linie); regimul de afişare (normal, mai luminos, cu intermitente, invers video); regimul de semnalizare sonoră (normal, semnal sonor după afişarea unui câmp etc.) [2]. 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ă, conŃinutul unui rând de date (de detaliu), gradele de total şi maniera lor de afişare, la începutul sau la sfârşitul grupului de date, al paginii sau raportului. De asemenea, se pot selecta dimensiunea unei linii, coloane, pagini, spaŃierea dintre linii, coloane, afişarea datelor privind momentul listării, statistici etc.

Astfel de module specializate există în pachete de programe pentru gestionarea bazelor de date cum ar fi: ACCESS, d’BASE, ORACLE, FOXPRO, PARADOX, etc.

Sisteme informatice

60

4.1.2. Proiectarea codurilor

În proiectarea sistemului de coduri trebuie să avem în vedere două aspecte importante şi anume [2]: - influenŃa tipului şi structurii codului asupra performanŃelor sistemului informatic; - implicaŃiile utilizării codurilor în operaŃiile de culegere a datelor şi interpretarea

rezultatelor finale de către utilizatorii neinformaticieni. Primul aspect ridică probleme de ordin tehnic în realizarea nomenclatorului de

coduri şi are în vedere facilitarea operaŃiilor de prelucrare, ocuparea unui spaŃiu de memorie internă şi externă cât mai mic etc.

Celui de-al doilea aspect trebuie să i se acorde o atenŃie mai mare în vederea uşurării activităŃilor de culegere, verificare a datelor şi interpretarea rezultatelor din situaŃiile finale. Având în vedere aceste considerente, se impune ca la proiectarea unui sistem de coduri să se respecte o serie de cerinŃe.

De exemplu, codul persoanei poate fi format din următoarele coduri elementare:

X X X XX XXX XXXX XX IniŃiala nume

IniŃiala prenume

Sex Ziua naşterii Luna naşterii Anul naşterii

Grupa sanguină

ActivităŃile parcurse în realizarea unui sistem de coduri sunt: [2] - analiza elementelor ce urmează a fi codificate; - precizarea şi uniformizarea tehnologiei, a denumirilor; - stabilirea caracteristicilor şi a relaŃiilor dintre elementele de codificat; - alegerea tipurilor de coduri; estimarea capacităŃii, lungimii şi formatului codurilor; - atribuirea codurilor elementelor de codificat (crearea nomenclatoarelor de coduri); - întreŃinerea nomenclatoarelor de coduri.

Este indicat a se utiliza, acolo unde este cazul, sistemele de codificare existente la nivelul economiei naŃionale (CAEN, SIRUES, SIRUTA, CNP, etc). 4.1.3. Proiectarea intrărilor în sistemul informatic

Datele de intrare parcurg o succesiune de etape până 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; corecŃia datelor eronate etc.

La proiectarea intrărilor este necesar să se realizeze, în principal următoarele activităŃi: - alegerea suportului tehnic pentru culegerea datelor - proiectarea machetelor documentelor de intrare, stabilirea instrucŃiunilor 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 funcŃie de cerinŃele aplicaŃiei 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 prelucrării ulterioare. [2]

61

La proiectarea machetei documentelor de intrare (indiferent de metodele de prelucrare a datelor folosite ulterior) sunt respectate câteva reguli care să înlesnească completarea şi apoi utilizarea documentului atât pentru prelucrarea automată a datelor cât mai ales pentru necesităŃile curente ale salariaŃilor societăŃii economice. Nu este recomandabil să dublăm documentele primare, prin proiectarea unor documente destinate exclusiv preluării datelor pentru necesităŃile prelucrării automate [2].

Macheta documentului primar trebuie să conŃină: - antetul–ce reprezintă denumirea unităŃii şi/sau a serviciului care-l emite; - denumirea documentului; - coduri de identificare, - data documentului; - rubrici /casete/ rânduri pentru denumirea informaŃiilor cantitativ-valorice şi coduri; - rubrici /casete /spaŃii pentru semnături şi ştampile; - text explicativ, eventual indicaŃii de completare şi verificare.

În ordonarea informaŃiilor pe document, deci în rubricarea documentului se va Ńine seama de câteva reguli: antetul se plasează în stânga sus; codurile şi alte informaŃii de identificare se plasează în dreapta sus; sensul natural de parcurgere este de sus în jos şi de la stânga la dreapta; zonele de document ce se completează de compartimente/ persoane diferite se marchează / grupează distinct; mărimea şi spaŃierea documentului, distanŃa dintre rânduri, dimensiunea rubricilor, depind de locul şi modalitatea de completare (manual, dactilo, automat) precum şi de nivelul de calificare a personalului ce completează documentul.

Aşezarea 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 îngroşate în denumirea rubricilor implicate în dialogul operator-calculator.

Atunci când documentul există într-o formă pe hârtie, în varianta pe calculator se va urmări păstrarea în mare măsură a structurii existente, dar cu adaptări specifice noului mediu.

Regulile de control şi procedurile de validare a datelor de intrare trebuie să cuprindă [2]: - reguli de verificare a volumului, secvenŃei 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), corelaŃii logice (între indicatorii înscrişi în acelaşi document, sau cu alŃi indicatori din baza de date), prezenŃa unor informaŃii obligatorii (apartenenŃa codurilor la nomenclatoarele de coduri specifice aplicaŃiei 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 funcŃie de modul concret de desfăşurare a dialogului operator-calculator. Acest dialog se poate desfăşura sub formă de [2]:

Sisteme informatice

62

- întrebare-răspuns cu defilarea liniilor ecranului; - afişare pe ecran a machetei de introducere a datelor de intrare.

În prima variantă, mai uşor de realizat practic, operatorul introduce succesiv, ca răspuns la întrebările afişate 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: - afişarea la un moment dat a unui volum redus de informaŃii; - afişarea la un moment dat a unei cereri de răspuns ce se referă la o singură informaŃie; - scurtarea răspunsului operatorului prin folosirea mnemonicelor şi codificărilor; - utilizarea unor formate clare şi precise pentru afişare; - evitarea cuvintelor şi caracterelor dificil de citit sau înŃeles; - existenta unor rutine speciale de tipul HELP; - preluarea asistată a unor coduri (ex. utilizare tehnici de tip Lookup wizard în

ACCESS) In varianta a doua cursorul marchează de fiecare dată câmpul curent care se

introduce. Ecranul display-ului trebuie să reproducă integral sau simplificat macheta documentului, respectând aceeaşi ordine a rubricilor. Mesajele de eroare se pot afişa într-o zona prestabilita a ecranului, însoŃită de avertizare sonora sau luminoasa.

Dacă este cazul, pentru unele câmpuri (rubrici) de date se pot prelua valori implicite, atunci când nu sunt completate. Aceste valori se preiau din nomenclatorul de coduri, fişierele bazei de date sau tabele special memorate pentru valorile asumate prin lipsa sau prin aplicarea unui algoritm. Pentru o mai uşoară operare este necesar să folosim toate facilităŃile de afişare ş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 interfeŃelor şi a dialogurilor

63

InterfaŃa cu utilizatorul - reprezintă o parte a aplicaŃiei software care permite utilizatorilor să-si exprime intenŃiile de operare asupra calculatorului şi să interpreteze rezultatele acŃiunilor efectuate de maşină.

Prin proiectarea dialogurilor şi a interfeŃelor se definesc modalităŃile prin care oamenii şi calculatoarele schimbă informaŃii [1]. Metode şi echipamente folosite în dialogul om-maşină

InterfaŃa om – maşină defineşte modalitatea prin care utilizatorul interacŃionează cu un sistem informatic. InterfeŃele sunt destul de variate, conform descrierilor, însă toate trebuie să dispună de un stil sau de o metodă prin care să se folosească anumite echipamente în măsură să faciliteze o astfel de interacŃiune [1]. Metode de interacŃiune

Metodele cele mai utilizate sunt [1]: - interacŃiunea prin limbaj-comandă (în acest tip de interacŃiune utilizatorul transmite

calculatorului comenzile sub forma unui şir de caractere) - interacŃiunea prin meniuri(utilizatorul transmite comenzile sale calculatorului prin

intermediul unui sistem de meniuri şi opŃiuni de meniu sau folosind scurtături sub formă de combinaŃii de taste).

- interacŃiunea bazată pe obiecte icons(comunicarea se face prin intermediul desenelor. Imaginile folosite funcŃionează ca butoanele, la apăsarea lor se activează o anumită funcŃie sau comandă)

- interacŃiunea prin limbaj natural(comenzile se transmit folosind vocea şi sintetizatoarele de voce pentru redarea rezultatelor)

Echipamentelor necesare interacŃiunii cu sistemul

Cele mai folosite echipamente sunt [1]: - keyboard – tastatura este formată dintr-un set de butoane (taste) Prin intermediul ei

se introduc date, comenzo. - Mouse. - Joystick. - Touch Screen – atingerea ecranului constituie modalitatea prin care are loc selecŃia. - Light Pen – Stiloul optic efectuează selecŃia prin apăsarea pe ecran. - Voice – Vocea constituie modalitatea de transmitere a textelor şi comenzilor către

calculator.

Proiectarea dialogurilor

Proiectarea dialogurilor este procesul prin care sunt proiectate toate secvenŃele 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 condiŃiile în care se pot afişa informaŃiile sau se pot obŃine de la utilizator.

Pentru a obŃine rezultate bune trebuie să se Ńină seama de regulile de bază la conceperea dialogurilor cum ar fi: uniformitate, comenzi scurte, uşurinŃa în lucru, controlul, operaŃiunea inversă (refacerea unui element şters), rezolvarea erorilor, etc.

Sisteme informatice

64

O modalitate de prezentare a secvenŃei dialogurilor este cea care apelează la tehnica diagramelor. Ea va face trimitere la meniurile componente ale aplicaŃiei.

Figura 4.2. Structura unei diagrame de apelare a meniurilor [1].

Pentru proiectarea interfeŃelor ş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 condiŃii optime mediile GUI (Graphical User Interface) trebuie să se cunoască aceste medii.

În mediile grafice informaŃiile se plasează în ferestre. Acestea au trăsături 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 strânsă legătură cu modelarea conceptuală a datelor, aceasta însemnând reprezentarea modului de organizare a datelor, independent de tehnologiile specifice de prelucrare a bazelor de date, fără să se înregistreze o preocupare anume referitoare la calitatea modelelor datelor. Ultimului aspect i se va acorda atenŃia cuvenită abia acum, odată cu modelarea logică a datelor, descriindu-se structurile datelor din bază.

Procesul de modelare logică a datelor se derulează în paralel cu celelalte activităŃi ale proiectării logice: proiectarea formularelor şi a rapoartelor şi proiectarea dialogurilor şi interfeŃelor. Modelarea logică a datelor se realizează nu numai pe baza diagramei entitate-relaŃie, ci şi pe baza machetelor formularelor şi a rapoartelor. Se efectuează

PO2

ADĂUGARE

PO1

ŞTERGERE

MENIU_PRINCIPAL

MO1

MENIU_INTEROGARE

MO2

PO4

I_DUPĂ_AN

PO3

I_DUPĂ_NUME

PROCES MENIU

65

analiza datelor elementare din intrările şi ieşirile sistemului pentru a se desprinde legăturile dintre ele.

Prin modelarea logică a datelor se urmăreşte: - structurarea performantă a datelor prin procesul de normalizare - obŃinerea unui model logic al datelor din care să se poată realiza proiectul bazei de

date fizice, adică modelul relaŃional – cel mai utilizat în prezent, deşi se pot obŃine şi modelele reŃea, ierarhic sau orientate-obiect;

- realizarea unui model al datelor care să răspundă cerinŃelor actuale de date regăsite în formulare şi rapoarte. Modelarea logică este un proces ascendent (bottom-up, de jos în sus) de obŃinere a relaŃiilor din formulare şi rapoarte prin transformarea modelului entitate-relaŃie într-o formă relaŃională.

Modelarea logică a datelor descrie datele cu ajutorul unei notaŃii speciale, care corespunde unui mod de organizare a acestora de către un sistem de gestiune a bazelor de date.

Procesul de modelare a datelor este complex. În fiecare etapă a ciclului de viaŃă se regăseşte câte o activitate specifică datelor după cum urmează [1]: - Analiza – Modelele conceptuale ale datelor, prezentarea DER; - Proiectarea logică – Modelul logic al datelor(relaŃional); - Proiectarea fizică – Proiectarea fizică a bazelor de date şi a fişierelor (organizarea

fişierelor); - Implementarea – Descrierea fişierelor şi a bazelor de date.

După cum prezintă profesorul Oprea D. În “Analiza şi proiectarea sistemelor informaŃionale economice” în procesul de modelare logică există patru paşi esenŃiali: 1. Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare şi

rapoarte) privind aplicaŃia, folosindu-se principiile normalizării; 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-relaŃie), realizat fără să se

Ńină cont de perspectiva utilizatorului, într-un set de relaŃii normalizate; 4. Compararea modelului logic consolidat al datelor cu modelul transformat al entităŃii-

relaŃie şi realizarea, prin integrarea perspectivelor, a unui model logic final al datelor aplicaŃiei.

Rezultatele obŃinute prin parcurgerea celor patru paşi pot fi ilustrate prin intermediul unor exemple oferite în literatura de specialitate de McFadden şi Hoffer [1].

Primul pas al modelării logice se poate explica prin două rapoarte solicitate de utilizatori, reprezentând perspectiva utilităŃii sistemului din punctul lor de vedere: - cel mai bun client al produsului X(ecran); - situaŃia comenzilor în curs;

Ecranul “Cel mai bun client al produsului X”, prin percepŃia utilizatorului, are următorul format:

Cel mai bun client al produsului IntroduceŃi codul produsului: P1122 Data de început: 10/10/99 Data de sfârşit: 31/12/99 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - COD CLIENT: 1111 NUME CLIENT: S.C. ALPHA S.R.L. VOLUM: 1000

Sisteme informatice

66

Figura 4.3 Model de ecran solicitat de utilizatori [1]

Din analiza ecran ului se pot desprinde relaŃiile:

CLIENT(COD_CLIENT, NUME) COMANDA(NR_COMANDA, COD_CLIENT, DATA_COMANDA) PRODUS(COD_PRODUS) LINIE_COMANDA(NR_COMANDA,COD_PRODUS,CANTITATE_COMANDATA)

Raportul “SituaŃia comenzilor în curs” are următorul format:

Figura 4.4. Model de raport solicitat de utilizatori [1] Realizarea raportului este posibilă prin folosirea următoarelor entităŃi: 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)

Pagina 1 SituaŃia comenzilor în curs 31/03/1998 COD PRODUS CANTITĂłI_DE_LIVRAT A1111 0 A2222 0 B1111 150 Y9999 100

67

Pasul al doilea presupune comasarea perspectivelor utilizatorilor şi crearea unui set integrat al relaŃiilor, rezultând următoarele relaŃii: 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 (diagrama-entitate-relaŃie) din aplicaŃie fără să se Ńină cont de punctul de vedere al utilizatorului, într-un set de relaŃii normalizate. Din analiza diagramei din figura 6.5 se desprind următoarele relaŃii:

NUME_CLIENT COD_CLIENT ADRESA NR_FACTURA

CLIENT FACTURA

Facturare Lansează

COMANDA

Linie_comandă PRODUS

COD_PRODUS DENUMIRE

NR_COMANDA

CANTITATE_LIV

Livrar

Sisteme informatice

68

Figura 4.5. Diagrama entitate-relaŃie pentru gestiunea clienŃilor [1]

Din analiza diagramei se desprind următoarele relaŃii:

CLIENT(COD_CLIENT, NUME, ADRESA) PRODUS(COD_PRODUS, DENUMIRE) 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 obŃinut din pasul doi cu cel din pasul trei şi

integrează perspectivele utilizatorilor în vederea obŃinerii 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) LIVRARE(NR_FACTURA, COD_PRODUS, CANTITATE_LIVRATA)

Aşadar, rezultatul modelării logice a datelor îl constituie relaŃiile normalizate

rezultate din cel de-al patrulea pas al procesului. De asemenea, alt rezultat se va concretiza în actualizarea depozitului (repository) sau a dicŃionarului proiectului. DiferenŃa majoră între modelarea conceptuală şi cea logică este că după modelarea logică a datelor cerinŃele structurate de date se concretizează în relaŃii, şi nu în entităŃi. Din

69

cauza normalizării nu este necesară o corespondenŃă unu-la-unu între entităŃi şi relaŃii [1]. 4.3.1. Normalizarea relaŃiilor - Forme normale

Între atributele unei relaŃii sau între atribute din relaŃii diferite pot exista anumite legături logice (dependenŃe), care influenŃează proprietăŃile schemelor de relaŃie în raport cu operaŃiile curente care intervin în timpul exploatării bazei de date: adăugare, ştergere, actualizare. Aceste legături logice, cunoscute în literatura de specialitate sub denumirile de dependenŃele funcŃionale, dependenŃele multivalorice şi dependenŃe de cuplare, au implicaŃii majore asupra criteriilor de proiectare a schemelor relaŃionale. Alegerea unui model conceptual convenabil pentru o bază de date relaŃională poate necesita realizarea unor descompuneri pentru anumite scheme de relaŃie date, descompuneri care să izoleze dependenŃele existente şi prin aceasta să elimine anomaliile care se datorează acestor dependenŃe.

DependenŃe funcŃionale Penru definirea acestui tip de dependenŃe se consideră schema de relaŃie

Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare) definită pentru urmărirea serviciilor prestate de o firmă pentru diverşi clienŃi. Atributul Adresa este dependent de atributul Nume_client (presupunând că fiecare client are o singură adresă, rezultă că fiecare valoare a atributului Nume_client determină în mod unic valoarea corespunzătoare a atributului Adresa). Analizând schema de relaŃie de mai sus, se constată o redundanŃă relativ la atributul Adresa a cărei valoare este repetată pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariŃia următoarelor anomalii:

- Anomalia la adăugare: adresa unui client poate fi preluată numai după ce pentru acesta se prestează cel puŃin un serviciu.

- Anomalia la ştergere: dacă se şterg toate serviciile prestate pentru un anumit client, se pierde adresa acestui client.

- Anomalia la actualizare: datorită redundanŃei relativ la atributul Adresa, dacă se schimbă adresa unui client este necesară parcurgerea întregii relaŃii pentru a identifica şi actualiza toate apariŃiile acestui client, în caz contrar baza de date devine inconsistentă (acelaşi client poate apare la adrese diferite).

Aceste anomalii pot fi eliminate, dacă schema de relaŃie Prestari_Servicii se înlocuieşte prin următoarele două scheme de relaŃie:

Clienti(Cod, Nume_client, Adresa)

Servicii(Cod, Serviciu_prestat, Valoare).

RelaŃia Clienti conŃine codul, numele şi adresa fiecărui client, fără nici un fel de redundanŃă, iar relaŃia Servicii conŃine serviciile prestate pentru fiecare client şi valorile acestor servicii. Un dezavantaj al descompunerii relaŃiei iniŃiale în cele două relaŃii este

Sisteme informatice

70

acela că pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu este necesară efectuarea unei operaŃii de cuplare a relaŃiilor Clienti şi Servicii. Se consideră o schemă de relaŃie R şi A,B două atribute simple sau compuse ale schemei de relaŃie R. Atributul A determină funcŃional atributul B sau B depinde funcŃional de A, dacă şi numai dacă oricărei valori a atributului A îi corespunde o singură valoare a atributului B (se notează A->B).

DependenŃa funcŃională A->B este totală dacă nu există nici un subset C al atributului A (CcA) astfel încât C->B şi este parŃială în caz contrar. În relaŃia Prestari_Servicii, una din dependenŃele funcŃionale care poate fi pusă în evidenŃă este Nume_client->Adresa.

Deoarece într-o relaŃie orice cheie identifică în mod unic fiecare tuplă a relaŃiei, deci determină în mod univoc valorile atributelor tuplei, rezultă că în orice relaŃie atributele sunt dependente funcŃional faŃă de cheile acesteia. Se pot face, până în acest moment, următoarele precizări:

Eliminarea dependenŃelor funcŃionale din schemele de relaŃie şi a consecinŃelor negative (redundanŃa datelor; anomaliile de adăugare, ştergere, actualizare) se realizează prin descompunerea schemei date într-o colecŃie de scheme mai simple în care sunt evitate neajunsurile mai sus menŃionate. Reconstituirea relaŃiei iniŃiale se poate face prin operaŃia de cuplare (uniune). Pentru ca descompunerea schemei de relaŃie să fie echivalentă cu relaŃia iniŃială, trebuie să fie îndeplinite condiŃiile:

- cuplare fără pierdere de informaŃie; - conservarea dependenŃelor (dependenŃele funcŃionale din relaŃia iniŃială trebuie să

se regăsească în relaŃiile rezultate prin descompunere). Formele normale sunt scheme de relaŃie echivalente obŃinute prin descompunerea unor scheme de relaŃie în vederea eliminării redundanŃei datelor şi anomaliilor la adăugare, actualizare, ştergere înregistrări în baza de date. Descompunerile schemelor de relaŃii în scheme de relaŃii echivalente având în vedere dependenŃele funcŃionale 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ă Boyce-Codd (FNBC).

A patra formă normală (FN4) este definită având în vedere dependenŃele multivalorice, iar a cincea formă normală (FN5) este definită având în vedere dependenŃele de cuplare. Începând de la prima formă normală şi până la forma normală FN5 se impun condiŃii din ce în ce mai restrictive asupra relaŃiilor. Astfel o relaŃie aflată pe un anumit nivel de normalizare (FN5) satisface toate restricŃiile cerute de nivele inferioare de normalizare (FN1, FN2, FN3, FNBC, FN4). În cele ce urmează sunt date definiŃiile formelor normale având în vedere dependenŃele funcŃionale.

O relaŃie 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 relaŃie R este în a doua formă normală (FN2) dacă este în FN1 şi orice atribut neprim este total dependent faŃă de orice cheie a relaŃiei (atributele prime sunt atribute care

71

fac parte dintr-o cheie a relaŃiei şi cele neprime sunt atributele care nu aparŃin nici unei chei a relaŃiei).

O relaŃie R este în a treia formă normală (FN3) dacă este în FN2 şi nici un atribut neprim nu este funcŃional dependent faŃă de un alt atribut neprim al relaŃiei.

O relaŃie R se află în forma normală Boyce-Codd (FNBC) dacă singurele dependenŃe funcŃionale admise sunt cele în care o cheie determină un alt atribut (nici un atribut prim sau neprim nu poate fi dependent funcŃional faŃă de un alt atribut dacă acesta nu este sau nu conŃine o cheie). DependenŃe multivalorice

Pentru ilustrarea acestui tip de dependenŃe se ia în considerare următoarea schemă de relaŃie:

Clase(Clasa, Discipline, Elevi) ce conŃine clasele dintr-o instituŃie de învăŃământ, iar pentru fiecare clasă sunt înregistrate disciplinele ce se predau şi elevii înmatriculaŃi în clasa respectivă. Se poate constata că relaŃia Clase poate rezulta prin operaŃia de cuplare după atributul Clasa a următoarelor două relaŃii:

CD(Clasa, Discipline) CE(Clasa, Elevi)

În relaŃia Clase, presupunând că pentru o clasă dată, fiecare elev frecventează toate disciplinele înregistrate pentru acea clasă, există dependenŃele multivalorice:

Clasa ->> Discipline Clasa ->> Elevi.

Ca şi în cazul dependenŃelor funcŃionale, existenŃa dependenŃelor multivalorice prezintă aceleaşi neajunsuri privind redundanŃa datelor şi anomalii la efectuarea operaŃiilor de adăugare, actualizare şi ştergere înregistrări în baza de date.

O relaŃie R este în a patra formă normală dacă singurele dependenŃe multivalorice admise sunt cele determinate de un alt atribut care este o cheie sau care conŃine o cheie a relaŃiei. Întrucât orice dependenŃă funcŃională este un caz particular de dependenŃă multivalorică, rezultă că orice relaŃie care se află în forma normală FN4, se află şi în forma normală FNBC. Transformarea unei relaŃii într-o colecŃie de relaŃii care să se afle în FN4 este similară cu trecerea în FNBC, însă trebuie avută în vedere atât eliminarea dependenŃelor funcŃionale cât şi a dependenŃelor 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 făcut prin descompunerea unei relaŃii în altele două, urmărindu-se eliminarea dependenŃelor funcŃionale şi multivalorice. O relaŃie aflată în forma normală FN4 nu mai poate fi descompusă în continuare pe baza acestei metode. Există situaŃii când relaŃii aflate în FN4 conŃin redundanŃe şi prezintă anomalii la operaŃiile de adăugare, ştergere şi actualizare. Aceste anomalii sunt cauzate de existenŃa dependenŃelor de cuplare şi pot fi eliminate prin descompunerea relaŃiei în 3 sau mai multe relaŃii a căror cuplare are ca rezultat relaŃia iniŃială. DependenŃe de cuplare

Sisteme informatice

72

Se consideră schema de relaŃie: SDS (Specializari, Discipline, Studenti)

care conŃine disciplinele care se predau la diverse specializări şi studenŃii care le frecventează, cu precizarea că pot exista discipline opŃionale care nu sunt frecventate de toŃi studenŃii de la specializarea respectivă. În aceste condiŃii în cadrul schemei de relaŃie SDS nu au loc dependenŃele multivalorice:

Specializari ->> Discipline Specializari->> Studenti

ceea ce înseamnă că relaŃia SDS este în FN4. Deşi este în FN4, relaŃia SDS conŃine mai multe redundanŃe care pot conduce la anomalii de actualizare. Pe de altă parte, relaŃia SDS nu poate fi descompusă în două componente din a căror cuplare să rezulte relaŃia iniŃială cu conservarea informaŃiei. Se constată însă că relaŃia SDS poate fi descompusă în următoarele 3 relaŃii:

SD(Specializari, Discipline) SS(Specializari, Studenti) DS(Discipline, Studenti)

şi relaŃia SDS este rezultatul cuplării relaŃiilor: SD, SS şi DS fără pierdere de informaŃie. SDS = SD►◄SS►◄DS.

În acest caz spunem că în relaŃia SDS există o dependenŃă de cuplare. DependenŃele multivalorice sunt cazuri particulare de dependenŃe de cuplare.

A cincea formă normală este o generalizare a formei normale patru, trecerea unei relaŃii în FN5 presupunând eliminarea dependenŃelor de cuplare existente în cadrul relaŃiei, împreună cu anomaliile pe care acestea le creează. În cadrul unei relaŃii pot exista dependenŃe de cuplare care nu conduc la redundanŃă în memorarea datelor şi nu produc anomalii la operaŃiile efectuate asupra înregistrărilor bazei de date (acestea sunt dependenŃele de cuplare implicate de o cheie a relaŃiei).

O relaŃie este în forma normală cinci (FN5) dacă şi numai dacă toate dependenŃele de cuplare existente în relaŃie sunt implicate de o cheie a acesteia. RelaŃia SDS se poate descompune, cu conservarea conŃinutului de informaŃie, în cele 3 componente ale sale: SD, SS şi DS care sunt în FN5.

Având în vedere similaritatea ce există între definiŃiile pentru FNBC, FN4 şi FN5, acestea pot fi unificate în următoarea definiŃie [13]:

O relaŃie R este în FNBC, FN4, FN5 dacă şi numai dacă singurele dependenŃe funcŃionale, multivalorice, de cuplare existente sunt cele implicate de o cheie a relaŃiei R.

În concluzie, prin procesul de normalizare se realizează eliminarea din schemele de relaŃie a dependenŃelor (funcŃionale, multivalorice şi de cuplare) cu scopul de a obŃine o schemă relaŃională mai bună din punctul de vedere al redundanŃei datelor şi al anomaliilor ce pot apare la operaŃiile de adăugare, ştergere şi actualizare înregistrări în baza de date. Normalizarea unei scheme de relaŃie R înseamnă înlocuirea acesteia cu o mulŃime de proiecŃii R1,...,Rn astfel încât R să fie echivalentă cu uniunea proiecŃiilor R1,...,Rn. Deşi normalizarea este o operaŃie utilă în proiectarea bazelor de date, aceasta nu oferă întotdeauna reŃete pentru obŃinerea 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 obŃinut. În unele cazuri

73

normalizarea completă, până la FN5, s-ar putea să fie dezavantajoasă. Având în vedere constatările de mai sus se poate afirma că deşi normalizarea nu reprezintă o soluŃie general valabilă în orice situaŃie, totuşi dacă pentru proiectarea bazei de date se aplică corect o metodologie de proiectare descendentă, modelul rezultat va fi de la sine normalizat. Cercetările în acest domeniu continuă, fiind definite şi alte forme normale printre care FN6 pentru baze de date temporale. O bază de date temporală, pe lângă datele curente, conŃine şi date istorice, iar factorul (atributul) timp are un rol esenŃial (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 operaŃii de descompunere a schemelor de relaŃie şi anume: - descompunerea orizontală – pentru separarea datelor curente de datele istorice; - descompunerea verticală – pentru separarea atributelor aceleiaşi entităŃi având în vedere

valorile lor raportate la atributul temporal. În proiectarea unei baze de date nu este exclusă nici operaŃia inversă normalizării

numită denormalizare [12], prin care se urmăreşte înlocuirea unei colecŃii de scheme de relaŃie cu o schemă de relaŃie echivalentă în vederea eliminării necesităŃii efectuării unor operaŃii de cuplare care pot fi costisitoare. Dacă în cazul normalizării tendinŃa este de a ajunge la nivele cât mai înalte (FN5), pentru denormalizare nu există criterii clare putând fi avute în vedere doar aspecte legate de performanŃele anumitor aplicaŃii.

Un alt principiu care se urmăreşte în proiectarea unei baze de date este principiul proiectării ortogonale conform căruia în cadrul unei baze de date două scheme de relaŃie reale (variabile de relaŃie de bază) nu trebuie să aibă semnificaŃii suprapuse. În timp ce prin normalizare se urmăreşte reducerea redundanŃei din cadrul unei scheme de relaŃie, prin proiectarea ortogonală se urmăreşte reducerea redundanŃei dintre schemele de relaŃie.

4.3.2. Simplificarea structurii datelor prin normalizare

Problema de bază a proiectării logice a bazelor de date este cum ar trebui combinate datele elementare pentru a forma relaŃii(sau tipuri de înregistrări) care să descrie entităŃile şi relaŃiile dintre entităŃi. În limbajul bazelor de date, cuvântul relaŃie înseamnă un tabel de date, ceea ce duce la concluzia că bazele de date relaŃionale (modelul relaŃional) sunt clădite pe un grup de tabele legate între ele [1].

Modelul relaŃional a fost dezvoltat de către Codd. Este un model conceptual de organizare a datelor, destinat reprezentării legăturilor dintre date. El este bazat pe teoria matematică a relaŃiilor şi este definit cu o deosebită rigoare matematică [Popescu I., 1996].

În cadrul modelului relaŃional datele sunt structurate sub forma de relaŃii (de aici şi denumirea). Cea mai directa şi intuitiva modalitate de reprezentare a datelor în cadrul acestui model este sub forma de tabele. Fiecărei relaŃii i se poate asocia un tabel care are atâtea coloane câte mulŃimi leagă relaŃia şi are atâtea linii câte tuple conŃine relaŃia.

Prezentarea structurii relaŃionale a datelor impune definirea noŃiunilor de: domeniu, relaŃie, atribut şi schemă a unei relaŃii. Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de bază ale organizării datelor sunt prezentate în tabelul următor:

Formal Uzual Fizic

Sisteme informatice

74

RelaŃie Tablou Fişier(tabel) Tuplu Linie Înregistrare Atribut Coloană Câmp Domeniu Tip de dată Tip de dată

Definirea domeniului

Un domeniu este o mulŃime de valori caracterizată printr-un nume. Un domeniu se poate defini explicit prin enumerarea tuturor valorilor aparŃinând acestuia sau definind o proprietate distinctivă a domeniului valorilor, de cele mai multe ori limita superioară şi limita inferioară [Popescu I, 1996]. De exemplu: D1: {“F”,”M”} -definire explicită D2: {x| x∈N, 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 relaŃii) <v1,v2,…,vk> unde vi este un element care aparŃine domeniului Di. De exemplu, tuplurile <“Maria”,”F”,”50” >,< “Vasile”,”M”,”60”> aparŃin produsului cartezian D3xD1xD2. Definirea relaŃiei

O relaŃie R pe mulŃimile D1,D2,…,Dn este o submulŃime a produsului cartezian D1xD2x…xDn, deci o mulŃime de tupluri [Popescu I, 1996].

Considerând că nu se cunosc decât două persoane, relaŃia R se defineşte prin tuplurile care descriu aceste persoane, şi anume:

R: {<“Maria”,”F”,”50”>,<“Vasile”,”M”,”60”>} O relaŃie 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 relaŃiilor,

deoarece este uşor de înŃeles şi de utilizat. În prezentarea conceptului de relaŃie se poate recurge la analogii cu alte concepte

cum ar fi cel de fişier. RelaŃia poate avea semnificaŃia unui fişier, tuplul poate fi considerat o înregistrare, iar valorile din cadrul tuplului pot fi interpretate drept valori ale câmpurilor de înregistrare.

Definirea atributului

În timp ce tuplurile dintr-o relaŃie trebuie să fie unice, un domeniu poate apare de mai multe ori în produsul cartezian pe baza căruia este definită relaŃia [Popescu I, 1996].

75

PERS D3 D1 D2 D3 “Maria” “F” 50 “Vasile” “Vasile” “M” 60 “Maria”

RelaŃia 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, semnificaŃia valorilor din cadrul coloanei respective.

SemnificaŃia valorilor din cadrul unui tuplu se stabileşte în acest caz nu numai pe baza domeniului de care aparŃin valorile ci şi funcŃie de poziŃia ocupată în cadrul tuplului. DependenŃa faŃă de ordinea datelor înseamnă o reducere a flexibilităŃii organizării datelor. Într-o organizare eficientă, flexibilă, ordinea liniilor şi a coloanelor nu trebuie să prezinte nici o importanŃă. Pentru a diferenŃia coloanele care conŃin valori ale aceluiaşi domeniu, şi a elimina astfel dependenŃa de poziŃie în cadrul tabelei se introduce tocmai conceptul de atribut. Fiecare relaŃie are asociat un nume sau un identificator propriu.

Schema unei relaŃii este formată din ansamblul elementelor definitorii sau din nivelul relaŃiei urmat de lista atributelor specifice.

În mulŃimile matematice nu este permis ca un obiect să apară de mai multe ori. Cât timp o relaŃie este o mulŃime de tupluri, teoretic nici o linie a unei relaŃii nu poate fi duplicatul altei linii. După cum reiese din prezentările anterioare, dacă o coloană sau o combinaŃie 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 entităŃilor definite se organizează într-o singură tabelă sau în mai multe şi se urmăreşte descompunerea acestor tabele în altele, fără pierdere de informaŃii în scopul eliminării 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, înlăturându-se treptat o serie de neajunsuri şi asigurând facilităŃi sporite în privinŃa încărcării, actualizării şi exploatării bazei de date. O relaŃie nenormalizată conŃine unul sau mai multe grupuri care se repetă.

Necesitatea normalizării progresive este dată de faptul că anumite relaŃii pot genera o serie de situaŃii nedorite, aşa-numitele “anomalii de actualizare”, cum sunt: anomalia de ştergere, anomalia de adăugare, anomalia de modificare [2].

4.3.3. Transformarea diagramelor entitate-relaŃie în relaŃii

Pentru a se putea compara rezultatele obŃinute în etapa de proiectare logică a datelor, adică a relaŃiilor normalizate, cu diagrama entitate-relaŃie, rezultat al proiectării conceptuale, aceasta din urmă trebuie să fie convertită în relaŃii, de asemenea, normalizate.

Întregul proces se desfăşoară în patru paşi, astfel: [1]

Sisteme informatice

76

- Reprezentarea entităŃilor. Fiecare tip de entitate din diagrama entitate-relaŃie este reprezentată ca o relaŃie în modulul relaŃional al datelor. Identificatorul tipului de entitate devine cheie primară a relaŃiei, iar celelalte atribute ale tipului entităŃii devin atribute non-cheie ale relaŃiei.

- Reprezentarea legăturilor. Fiecare legătură din diagrama entitate-relaŃie trebuie să fie reprezentată în modelul relaŃional al datelor. Reprezentarea legăturii se efectuează în funcŃie de natura ei. De exemplu, uneori se poate constitui o relaŃie prin includerea cheii primare a unei relaŃii ca o cheie străină în altă relaŃie. Astfel, se poate crea o relaŃie separată pentru reprezentarea legăturii.

- Normalizarea relaŃiilor. RelaŃiile create în paşii 1 şi 2 pot conŃine redundanŃe nedorite şi vor constitui surse de înregistrare a anomaliilor în timpul actualizării. Normalizarea va conduce la o bună structurare a relaŃiilor.

- Fuziunea relaŃiilor. În timpul modelării logice a datelor s-au creat diferite relaŃii, atât pe baza normalizării ascendente a perspectivelor utilizatorilor, cât şi a transformării uneia sau a mai multor diagrame entitate-relaŃie în seturi de relaŃii. În structura acestor seturi de relaŃii pot exista unele relaŃii redundante, cum ar fi existenŃa a două sau mai multe relaŃii care descriu acelaşi tip de entitate, ce ar trebui să fuzioneze şi să se renormalizeze pentru extragerea eventualelor redundanŃe.

77

CAPITOLUL 5

PROIECTAREA FIZICĂ A SISTEMELOR INFORMATICE

Proiectarea fizică cunoscută şi sub numele de proiectare de detaliu, urmează

proiectării logice. Proiectarea logică întâlnită şi sub numele de proiectare generală, o altă variantă de definire a proiectării logice. De fapt, printr-o astfel de referire se scoate în relief faptul că în timpul proiectării 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ă informaŃiile de natură să sintetizeze cerinŃele utilizatorilor noului sistem, operaŃiune prestată de analiştii de sistem, iar în timpul proiectării fizice se prezintă punctele de vedere ale specialiştilor, cum ar fi cei din domeniul bazelor de date, securităŃii sistemelor, reŃelelor de calculatoare, programării, etc.

Proiectarea fizică implică parcurgerea următorilor paşi [1]: 1. Proiectarea fizică a bazelor de date şi a fişierelor. 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 strânsă concordanŃă cu diagramele fluxurilor de date şi cu celelalte piese ale documentaŃiei realizate în etapele anterioare;

3. Proiectarea strategiilor de prelucrare distribuită. Se vor prezenta modalităŃile în care utilizatorul poate să dispună de date şi facilităŃile de prelucrare oferite de reŃele de calculatoare.

5.1. Proiectarea fizică a bazelor de date şi a fişierelor

Modelul conceptual surprinde structura globală de organizare a datelor, asigurându-se independenŃa totală faŃă de orice sistem de gestiune a bazelor de date. Modelul conceptual este prezentat prin intermediul diagramelor entitate-relaŃie(DER), motiv pentru care este cunoscut şi sub numele de modelul entitate-relaŃie al datelor. El scoate în evidenŃă reprezentarea logică, detaliată a entităŃilor, asocierilor (legăturilor) şi datelor elementare ale unei organizaŃii sau ale unei părŃi din ea. Modelul se realizează în faza de analiză [1].

Modelul logic al datelor înseamnă descrierea datelor în concordanŃă cu modelul de organizare a acestora de către sistemele de gestiune a bazelor de date. În acest material s-a ales modelul relaŃional. Conform cu acest model datele sunt reprezentate în baza de date sub forma tabelelor sau relaŃiilor create din diagrama entitate-relaŃie obŃinută în etapa anterioară.

O bază de date poate fi definită ca un ansamblu de date elementare sau structurate, accesibile unei comunităŃi de utilizatori. Mai concret, o bază de date este un ansamblu de fişiere intercorelate, care conŃine nucleul de date necesare unui sistem informatic (aplicaŃie informatică). Un fişier este un ansamblu de înregistrări fizice, omogene din

Sisteme informatice

78

punct de vedere al conŃinutului şi al prelucrării. O înregistrare fizică este unitatea de transfer între memoria internă şi cea externă a calculatorului. Aceasta este formată din una sau mai multe înregistrări logice. O înregistrare logică este unitatea de prelucrare din punct de vedere al programului utilizator. Aceasta este formată dintr-un ansamblu de câmpuri, care descriu o anumită entitate.

Modul de stocare a datelor pe suportul fizic de memorare este funcŃie de sistemul de gestiune a bazelor de date utilizat.

Proiectarea fizică a bazelor de date şi a fişierelor îş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 soluŃionării optime a problemelor formulate în etapele anterioare ale realizării sistemului informatic. 5.1.1. Obiectivele fundamentale ale unei baze de date (BD) sunt:

Centralizarea datelor permite: suprimarea redundanŃei, asigurarea unicităŃii înregistrării şi controlul centralizat (asupra datelor). În prelucrarea clasică în care fişierele sunt dedicate aplicaŃiilor, aceleaşi date apar înregistrate în mai multe fişiere şi în formate diferite. Acest lucru implică o utilizare ineficientă a spaŃiului de memorie externă, actualizarea dificilă a acestor date şi lizibilitate redusă ca urmare a formatelor diferite.

IndependenŃa între date şi prelucrări. Baza de date, ca imagine a unei anumite realităŃi, 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 legături între entităŃile de date, care sunt indispensabile pentru exploatarea eficientă a sistemului informatic. Spre exemplu, în cadrul gestiunii aprovizionării, trebuie asociat un furnizor la lista de produse pe care le vinde şi invers, un produs la lista de furnizori, precizând condiŃiile de vânzare pentru un furnizor şi un produs.

Integritatea datelor asigură fiabilitatea şi coerenŃa bazei de date (BD). Pentru aceasta trebuie definite restricŃii de integritate cum ar fi: - apartenenŃa la o listă de valori sau interval; - apartenenŃa 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 tranzacŃii; lista operaŃiilor realizate asupra bazei de date după

ultimul punct de repriză. ConfidenŃialitatea datelor este asigurată prin proceduri de:

- identificare a utilizatorilor prin nume sau cod; - autentificarea prin parole; - autorizarea accesului diferenŃiat prin drepturi de creare, consultare modificare sau

ştergere pentru anumite segmente de date.

79

Partajarea datelor permite înlănŃuirea tranzacŃiilor solicitate simultan pe aceeaşi înregistrare din baza de date, prin blocarea cererilor în aşteptare ş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 întreŃinerea bazei de date, precum şi accesul controlat la baza de date. Un SGBD oferă următoarele facilităŃi pentru crearea şi exploatarea bazelor de date: - facilităŃi 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;

- facilităŃi 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 către utilizatori neautorizaŃi; - sistem de integritate, menŃine concordanŃa datelor stocate în baza de date; - sistem de control al concurenŃei, permite accesul partajat la baza de date; - sistem de control al refacerii, permite recuperarea bazei de date în urma

unor defecŃiuni 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 regăsesc 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 răspunde de ansamblul activităŃilor privind baza de date, începând din faza de proiectare şi continuând cu celelalte etape pe întreaga perioadă de viaŃă a bazei de date. Astfel, în faza de proiectare a bazei de date, administratorul stabileşte SGBD-ul ce va fi utilizat, echipamentele necesare, structurile de date plecând de la necesităŃile de informaŃie ale tuturor utilizatorilor bazei de date, drepturile de acces la date ale fiecărui utilizator. Rezultatul fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema generală a bazei de date), modelului extern (subschema proprie fiecărui utilizator) şi stabilirea modalităŃilor 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,

Sisteme informatice

80

administratorul va menŃine permanent legătura cu utilizatorii acesteia pentru rezolvarea cerinŃelor utilizatorilor şi impunerea unei discipline în vederea alinierii la standardele existente. Administratorul va realiza, ori de câte ori se impune, reorganizarea structurii fizice a datelor în vederea optimizării parametrilor de funcŃionare 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 prevăzute [12] şi alte mecanisme şi anume: evidenŃa de auditare, criptarea datelor.

EvidenŃa de auditare constă dintr-un fişier în care sistemul înregistrează automat toate operaŃiile efectuate asupra datelor, fişier ce va putea fi consultat de către persoane autorizate pentru a verifica efectuarea unor operaŃii neautorizate. O înregistrare din evidenŃa de auditare va conŃine următoarele informaŃii: textul sursă al operaŃiei neautorizate, terminalul de la care a fost lansată operaŃia, utilizatorul care a lansat operaŃia, data şi ora operării, obiectele bazei de date afectate, imaginile datelor afectate înainte de efectuarea operaŃiei, imaginile datelor afectate după efectuarea operaŃiei.

Pentru a preveni accesul unor intruşi la baza de date, care încearcă să ocolească sistemul, se utilizează criptarea datelor, mecanism ce constă în stocarea şi transmiterea datelor pe căile de comunicaŃie 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 securităŃii bazelor de date şi a fişierelor

Securitatea este abordată din mai multe puncte de vedere, dar cea referitoare la baze de date şi la fişiere presupune luarea unor măsuri pentru reconstituirea datelor pierdute sau preluate eronat, precum şi pentru accesul neautorizat sau incomodarea până la a face imposibilă citirea datelor, prin criptare, atunci când ele sunt accesate ilegal. Aşadar două aspecte vor fi relevante: reconstituirea datelor şi criptarea lor [1].

Reconstituirea datelor este des asociată cu existenŃa fişierelor de tip back-up, însă în practică este posibilă şi reconstituirea fără apelarea la acest tip de fişiere. În vederea controlării corectitudinii datelor tranzacŃionate se apelează la fişiere cu rol special, care conŃin un istoric, în ordine cronologică, al schimbărilor şi accesărilor efectuate asupra fişierelor sau bazelor de date. Cu ajutorul lor se pot reconstitui fişierele distruse, dar şi la verificarea corectitudinii operaŃiunilor de actualizare [1].

Securitatea prin criptografiere se referă la asigurarea transformării datelor de comunicat într-o formă neinteligibilă pentru toŃi ceilalŃi receptori, exceptându-l pe cel autorizat. Criptarea a devenit una dintre cele mai puternice modalităŃi de asigurare a securităŃii datelor. Ea poate fi realizată prin sistemul de operare sau prin SGBD, dar şi prin rutine create de către specialişti [1].

Având în vedere aspectele prezentate mai sus, criteriile avute în vedere în alegerea unui anumit tip de SGBD sunt [2]:

a) Portabilitatea SGBD-ului. Prin aceasta înŃelegem 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ă conŃină cât mai puŃine elemente legate de echipament;

81

Portabilitatea sistemului de gestiune privit prin prisma portabilitaŃii datelor se referă la posibilitatea de a folosi o serie de date utilizate în cadrul unui sistem informatic de către un alt sistem informatic, deci posibilitatea integrării fişierelor deja existente în cadrul unui alt sistem.

b) Costul sistemului. Acest criteriu trebuie privit prin prisma: timpului de ocupare a unităŃii centrale; costului de întreŃinere şi dezvoltare; resurselor hard imobilizate; costului de adaptare şi trecere pe un nou sistem de calcul; costul documentaŃiei etc.

c) FacilităŃile de implementare, întreŃinere şi exploatare a bazei de date. Acestea sunt reflectate prin: modalitatea de descriere a datelor; tehnicile de organizare şi regăsire a datelor, care să permită un acces cât mai rapid la orice informaŃie; timpul cât mai redus pentru actualizare, căutare şi răspuns la cererile de informare; editarea operativă a celor mai variate tipuri de situaŃii solicitate de către utilizator; posibilitatea de inserŃie a unor programe de aplicaŃie, programe de validare de date, de actualizare, rutine statistice, rutine de sortare, rutine de prezentare grafică a ieşirilor etc.

d) Posibilitatea gestionarii structurilor complexe de date. e) Multitudinea metodelor de acces. In funcŃie de cerinŃele proprii aplicaŃiei,

sistemul va trebui să suporte interogări sau actualizări în timp real având proceduri de tip conversaŃional.

f) ProtecŃia şi securitatea datelor din bază. g) Specificul aplicaŃiei. Este cunoscut faptul că programele sunt orientate pe

aplicaŃii, cum ar fi: programarea producŃiei, aprovizionare-desfacere, optimizări, prognoze etc.

Toate aceste criterii de alegere pot fi corelate cu o serie de factori complementari cum ar fi: mentenanŃa sistemului, facilităŃile ce le oferă administratorului bazei de date, calitatea documentaŃiei oferite de furnizori, asistenŃă în implementarea sistemului şi în pregătirea utilizatorilor etc.

ToŃi aceşti factori alături de criteriile enunŃate pot să influenŃeze succesul în implementarea SGBD-ului şi eficienŃa 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 interogărilor bazei de date, precum şi exemple practice sub SGBD ORACLE.

5.1.5. Limbajul SQL - Crearea, Administrarea şi Interogarea bazelor de date

relaŃionale

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 răspândite limbaje pentru SGBD-urile relaŃionale. Limbajul SQL, ca limbaj de interogare a bazelor de date relaŃionale, este construit pe baza a două formalisme abstracte enunŃate în cele ce urmează. 1. Algebra relaŃională – prin care interogările sunt exprimate prin aplicarea unor operatori unari sau binari care constituie primitive ce acŃionează asupra relaŃiilor, rezultatul interogărilor fiind tot relaŃii, ceea ce permite asocierea şi imbricarea acestor

Sisteme informatice

82

operatori pentru a forma interogări complexe. Operatorii algebrei relaŃionale se împart în două grupe şi anume: - operaŃii pe mulŃimi (Reuniunea, IntersecŃia, DiferenŃa, Produsul cartezian); - operatori relaŃionali speciali (SelecŃia, ProiecŃia, Cuplarea (JOIN), Diviziunea). 2. Calculul relaŃional – prin care interogările descriu mulŃimea tuplelor rezultat prin specificarea unui predicat (condiŃie) care trebuie satisfăcut de aceste tuple. Începând din 1986 limbajul SQL a devenit standard ANSI pentru limbajele de interogare ale bazelor de date relaŃionale fiind utilizat atât în cadrul unor SGBD-uri complexe cum ar fi SGBD ORACLE (liderul mondial în domeniul bazelor de date), cât şi în cadrul unor SGBD-uri de complexitate redusă cum ar fi cele din familia xBase (Dbase IV, FoxPro). Standardul SQL utilizat pînă la începutul anului 2000 este cel realizat în 1992 şi cunoscut sub numele de SQL’92 sau SQL2. Noul standard SQL3 lansat în 1999 are în vedere o serie de extensii faŃă de SQL2 după cum urmează: - facilităŃi orientate obiect – posibilitatea de definire de către utilizator a tipurilor

abstracte de date care să permită descrierea de metode, identitatea obiectelor, subtipuri şi moştenire, polimorfism etc.;

- structuri de control – pentru a conferi limbajului completitudine de calcul (IF, FOR, WHILE, etc.) pentru a deveni un limbaj de sine stătător a cărui putere de expresie să nu mai fie limitată la nivelul limbajelor relaŃionale;

- facilităŃi pentru exprimarea prelucrărilor recursive; - facilităŃi de comunicare în reŃea; - facilităŃi de prelucrare distribuită (mecanisme pentru crearea, memorarea şi execuŃia

procedurilor la nivelul serverelor de date –stored procedures); - facilităŃi multimedia; - facilităŃi 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> Adăugarea relaŃiilor într-o bază de date –comanda CREATE TABLE are sintaxa:

CREATE TABLE <nume relaŃie>[(<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ă relaŃie poate fi creată şi ca rezultat al unei operaŃii de interogare astfel: CREATE TABLE <nume relaŃie> (<nume atribut> <tip dată>,…) AS <subinterogare>

Adăugarea/modificarea de atribute pentru o relaŃie existentă se realizează cu comanda: ALTER TABLE <nume relaŃie> ADD|MODIFY (< nume atribut> <tip dată>,…)

Ştergerea unei relaŃii se realizează cu comanda: DROP TABLE <nume relaŃie>

83

Comenzi pentru optimizarea interogărilor Una din principalele căi de optimizare a timpilor de interogare a unei baze de

date este indexarea. Un index poate fi privit ca o relaŃie cu două atribute şi anume: - primul atribut conŃine valorile atributelor relaŃiei după care se crează indexul; - al doilea atribut conŃine un pointer (adresa) la locaŃia tuplelor

corespunzătoare. Crearea unui index se realizează cu comanda:

CREATE [UNIQUE] INDEX <nume index> ON <nume relaŃie>(<nume atribut>[ASC|DESC],…)

Dacă pentru atributele utilizate în clauza WHERE a unor instrucŃiuni SQL au fost creaŃi indecşi, atunci aceştia vor fi utilizaŃi în vederea optimizării 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 obŃinere a rezultatului.

O altă tehnică de optimizare a interogărilor este tehnica “clustering” disponibilă în ORACLE şi care constă în gruparea tuplelor din mai multe relaŃii şi stocarea lor în aceeaşi zonă pe disc. Controlul datelor (comenzi DCL) Vederi

O vedere este o relaŃie virtuală, definită plecând de la alte relaŃii din baza de date şi care nu conŃine date şi deci nu ocupă spaŃiu fizic pe disc. Vederile se definesc în două scopuri şi anume: - pentru a simplifica accesul utilizatorilor la date; - pentru a asigura protecŃia şi securitatea datelor –fiecărui utilizator fiindu-i permis

acces la o porŃiune a bazei de date şi putând efectua doar anumite operaŃii (conform drepturilor de acces specificate cu comenzile GRANT/REVOKE).

Asupra unei vederi se pot efectua aceleaşi operaŃii ca şi asupra unei relaŃii cu deosebirea că vederile nu conŃin date şi că orice modificări efectuate asupra datelor sunt reflectate şi în vederi. Astfel, asupra unei vederi se pot realiza operaŃiile:

- 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); - adăugare 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]

Exemplu: CREATE VIEW StocuriD1(Codp,Denp,Ump,Cant,Pret,Valoare)

AS SELECT Stocuri.Codp, Denp,Ump,Cant,Pret,Cant*Pret FROM Produse,Stocuri

Sisteme informatice

84

WHERE Produse.codp=Stocuri.Codp AND CodDep = ”D1” Interogarea vederii se va realiza cu comanda

SELECT * FROM StocuriD1 Utilizarea opŃiunii WITH CHECK OPTION asigură faptul că nici o tuplă nu va fi

adaugată sau actualizată cu instrucŃiunile INSERT, UPDATE, dacă nu sunt respectate condiŃiile specificate în clauza WHERE a instrucŃiunii SELECT din definiŃia vederii.

Pentru acordarea sau retragerea drepturilor de acces la baza de date prin intermediul vizualizărilor 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 securităŃii datelor presupune definirea drepturilor de acces ale

utilizatorilor şi protecŃia sistemului la accesul neautorizat. În acest sens asigurarea securităŃii se realizează pe două niveluri şi anume:

- nivelul 1 – acordarea dreptului de acces la sistem; - nivelul 2 – acordarea dreptului de acces la nivel de relaŃii. 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 relaŃie în sistemele multi-user trebuie

precizat utilizatorul care a creat relaŃia (proprietarul relaŃiei). Fiecare utilizator are drepturi doar asupra propriilor relaŃii, iar drepturi asupra unor relaŃii create de alŃi 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 dicŃionarul de date şi sunt gestionate de către 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 oricărei operaŃii asupra oricărei relaŃii din baza de date;

- CONNECT – conferă utilizatorului dreptul de a a face interogări (SELECT) şi actualizări (INSERT, UPDATE, DELETE) asupra relaŃiilor create de alŃi utilizatori, însă nu permite utilizatorului să creeze relaŃii (CREATE) sau să şteargă relaŃii create de alŃi utilizatori (DROP);

- RESOURCE – conferă utilizatorului drepturile ce rezultă din autorizarea CONNECT şi în plus dreptul de a crea relaŃii (CREATE) şi de a şterge relaŃii ce îi aparŃin (DROP).

Unui utilizator îi pot fi acordate mai multe tipuri de autorizări în cadrul unei singure comenzi GRANT.

85

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 căruia i s-a acordat un tip de autorizare îi pot fi acordate şi alte tipuri de autorizare prin comenzi GRANT ulterioare.

Retragerea autorizărilor 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 relaŃii se utilizează

comenzile GRANT respectiv REVOKE cu următoarea sintaxă: GRANT ALL|<drept de acces>,… ON <nume relaŃie> TO <nume utilizator>|PUBLIC [WITH GRANT OPTION]

respectiv REVOKE ALL|<drept de acces>,… ON <nume relaŃie> FROM <nume utilizator>|PUBLIC Privilegiile (drepturile de acces) pot fi acordate sau retrase de următoarele categorii de utilizatori:

- utilizatorii cu nivel de autorizare DBA; - proprietarii relaŃiilor; - utilizatorii autorizaŃi cu opŃiunea 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 rândul

său să acorde aceleaşi drepturi sau mai puŃine altor utilizatori. În ORACLE pot fi acordate următoarele drepturi de access asupra relaŃiilor:

SELECT, INSERT, DELETE, ALTER, UPDATE, CREATE,DROP pentru tabele şi indecşi. Drepturile de acces pot fi acordate asupra întregii relaŃii, sau doar asupra

anumitor atribute ale relaŃiei. Exemple:

Acordarea tuturor drepturilor de acces utilizatorilor Ionescu, Popescu, asupra relaŃiei Persoane care aparŃine utilizatorului Vasilescu se realizează prin comanda:

GRANT ALL ON Vasilescu.Persoane TO Ionescu,Popescu Acordarea tuturor utilizatorilor, drepturile SLECT,INSERT,UPDATE asupra

relaŃiei Produse aparŃinând 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 relaŃia Produse aparŃinând utilizatorului Ionescu, utilizatorului Popescu cu condiŃia ca acesta la rândul său să poată acorda oricărui alt utilizator aceleaşi drepturi sau mai puŃine, se realizează cu comanda:

GRANT SELECT,UPDATE ON Ionescu.Produse(CodProdus,Denumire) TO Popescu WITH GRANT OPTION

Retragerea drepturilor de acces INSERT,DELETE asupra relaŃiei Persoane aparŃinând utilizatorului Vasilescu, utilizatorului Ionescu se realizează cu comanda:

REVOKE INSERT,DELETE ON Vasilescu.Persoane FROM Ionescu

Sisteme informatice

86

InstrucŃiuni pentru inserarea şi actualizarea datelor în tabele Inserarea datelor – comanda INSERT are următoarea 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 completând toate atributele)

INSERT INTO Persoane(Nrcrt,Nume,Prenume) VALUES (2,’Ionescu’,’Ana’) (adaugă o înregistrare în Persoane completând numai atributele Nrcrt,Nume, Prenume) Pentru a insera în tabela PersF(Nrcrt,Nume,Prenume) toate înregistrările 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 relaŃie>|<nume vedere> SET <nume atribut> = <expresie>,…[WHERE <condiŃie>]

CondiŃia din clauza WHERE defineşte tuplele care vor face obiectul actualizării. Clauza WHERE poate conŃine ş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 preŃului cu 20% pentru produsele vândute cu factura 120). Dacă în comanda UPDATE clauza WHERE este omisă, actualizarea se va efectua asupra tuturor tuplelor relaŃiei.

Ştergerea datelor – comanda DELETE are sintaxa: DELETE FROM <nume relaŃie>|<nume vedere> [WHERE <condiŃie>]

unde <condiŃie> poate fi o condiŃie simplă, o expresie sau o subinterogare. Exemple:

DELETE FROM Stocuri WHERE Cant = 0 (şterge toate înregistrările din tabela Stocuri pentru care câmpul Cant are valoarea 0).

DELETE Oferte (şterge toate înregistrările din tabela Oferte). Comenzi pentru gestiunea tranzacŃiilor

TranzacŃia este o succesiune de instrucŃiuni SQL grupate într-un bloc de instrucŃiuni utilizate pentru actualizarea şi/sau interogarea datelor din baza de date. O tranzacŃie se consideră încheiată după realizarea tuturor operaŃiilor pe care le conŃine. OperaŃiile conŃinute într-o tranzacŃie pot fi realizate efectiv în baza de date sau nu, fie

87

automat de către sistem după fiecare operaŃie, fie printr-o comandă explicită dată după o succesiune de operaŃii. Astfel salvarea automată de către sistem a modificărilor este realizată prin comanda

SET AUTOCOMMIT ON Dacă iniŃial a fost specificată comanda SET AUTOCOMMIT OFF, salvarea modificărilor efectuate asupra datelor se realizează prin comanda COMMIT, iar abandonarea modificărilor se realizează prin comanda ROLLBACK.

Blocul de operaŃii ce definesc o tranzacŃie poate fi delimitat de instrucŃiunile : BEGIN TRANSACTION END TRANSACTION

Problemă rezolvată

Se lansează în execuŃie 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 instrucŃiunea 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ă înregistrări (figura 5.4).

Figura 5.1. Lansare SQL Plus ORACLE pentru utilizatorul system

ORCL

Sisteme informatice

88

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

ORC

89

Limbajul SQL - Interogarea bazelor de date - Fraza SELECT Interogarea bazelor de date în limbajul SQL se realizează cu ajutorul unei singure

instrucŃiuni şi anume instrucŃiunea SELECT având următoarea sintaxă: SELECT [DISTINCT] <lista atribute>|* FROM <lista relaŃii> [WHERE <condiŃie>] [GROUP BY <lista atribute de grupare>]

Figura 5.4. Creare tabelă Produse şi inserare două înregistrări

Sisteme informatice

90

[HAVING <condiŃie>] [ORDER BY <atribut1 de ordonare> [ASC]|DESC,…] [UNION <frază SELECT>]

<lista atribute> este o listă ce conŃine nume de atribute (câmpuri) sau expresii construite utilizând atribute, separate prin caracterul “,” şi care fac parte din relaŃiile (tabele, vederi) enumerate în <lista relaŃii> din clauza FROM. Numele fiecărui atribut sau expresii din <lista atribute> va fi afişat în capul de tabel ce reprezintă rezultatul interogării, fiecare atribut sau expresie putând 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 relaŃia rezultat nu pot apărea duplicate (tuple identice).

Clauza WHERE precizează condiŃiile de interogare (condiŃii care trebuie să fie satisfăcute de tuplele interogate, condiŃii de cuplare relaŃii (JOIN, relaŃii între tabele). În clauza WHERE pot fi utilizaŃi operatori logici (AND, NOT, OR), predicate (IN, LIKE, BETWEEN, EXISTS, ALL, ANY), operatori aritmetici (+, -, **, /, *), operatori de comparare (=, #,<, >, <=, >=, <>), parantezele ( ) pentru schimbarea ordinii de prioritate a operaŃiilor, operatorilor, funcŃii şi alte subinterogări SELECT, pentru construirea de expresii pe care trebuie să le îndeplinească tuplele ce constituie rezultatul interogării. Predicatul IN permite specificarea unei liste pentru domeniul de căutare pentru un atribut, iar predicatul BETWEEN permite specificarea unui interval pentru domeniul de căutare a valorilor unui atribut, fiind echivalent cu o condiŃie de forma: <atribut> >= <limita inf. interval> AND <atribut> <= <limita sup. interval> Exemple: Fie tabela Persoane(Nrcrt,Nume,Prenume, Datan, Sexul, Adresa) Selectarea tuturor înregistrărilor din tabela Persoane pentru care primele 7 caractere din câmpul Adresa sunt ‘Suceava’ sau ‘RădăuŃi’ se realizează cu comanda:

SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) IN (‘Suceava’,‘RădăuŃi’)

Interogarea de mai sus este echivalentă cu interogarea: SELECT * FROM Persoane WHERE SUBSTR(Adresa,1,7) = ‘Suceava’ OR SUBSTR(Adresa,1,7) = ‘RădăuŃi’

Selectarea tuturor înregistrărilor din tabela Persoane pentru care data naşterii 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}

91

Predicatul LIKE permite selecŃia şirurilor de caractere care conŃin anumite caractere specificate prin intermediul unei măşti definite cu ajutorul unor caractere speciale (%, _ în dBASE IV, FoxPro, ORACLE, sau *, ? în INFORMIX) Exemple:

SELECT * FROM Persoane WHERE Nume LIKE ‘%a’

(selectează toate înregistrările 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 înregistrările 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 înregistrările din tabela Persoane pentru care prima literă din Nume este orice literă, a doua literă din Nume este litera ‘o’ şi începând din poziŃia a treia numele poate conŃine orice litere.) Predicatele ALL, ANY, EXISTS se utilizează pentru interogări ce conŃin subinterogări, în vederea verificării anumitor condiŃii ce trebuie îndeplinite între rezultatele interogării şi rezultatele subinterogării.

Clauza GROUP BY – realizează gruparea tuplelor unei relaŃii pe baza valorilor unui atribut sau grup de atribute şi generează o singură tuplă pentru fiecare grup de tuple având aceeaşi valoare pentru atributele care definesc grupul. Atributele care definesc grupul trebuie obligatoriu să se regăsească în lista atributelor interogate <lista atribute>. De asemenea asupra unor atribute pot fi aplicate funcŃii 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>) – numărul înregistrărilor pe grupare după <atribut>.

ObservaŃie. <atribut> poate fi fie un atribut, fie o expresie definită utilizând atribute ale tabelei.

Clauza HAVING, opŃiune a clauzei GROUP BY, este o formă specială a clauzei WHERE întrucât 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 având aceeaşi valoare în câmpul CodDep şi numărul înregistrărilor din fiecare grup definit de câmpul CodDep şi afisează rezultatele sub formă de tabel având coloanele CodDep, Valoare, Contor)

Sisteme informatice

92

SELECT CodDep,CodP,MAX(Pret) FROM Stocuri

GROUP BY CodP HAVING MAX(Pret) < 150000

(selectează pentru fiecare grupă de înregistrări având aceeaşi valoare în câmpul CodP, înregistrarea cu preŃul maxim mai mic decât 150000)

CLAUZA ORDER BY – PERMITE PRECIZAREA ORDINII DE AFIŞARE A

DATELOR ASTFEL:

ORDER BY <nume atribut 1> [ASC]|DESC,<nume atribut 2>[ASC]|DESC,…

Exemplu: SELECT * FROM Persoane ORDER BY Datan DESC,Nume

(afişează toate înregistrările din tabela Persoane în ordine descrescătoare după data naşterii şi în cadrul aceleiaşi date a naşterii crescător după Nume)

Clauza UNION – permite obŃinerea rezultatului a două sau mai multe interogări printr-o singură instrucŃiune 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 înregistrările pentru care CodDep = ‘Dep01’, la care adaugă tuplele (CodDep,CodProd,Cant) din tabela Stoc_Prod pentru toate înregistrările pentru care Cant >= 100). Pentru a nu se elimina tuplele duplicat trebuie specificat UNION ALL. Pentru a schimba ordinea de afişare a tuplelor extrase se poate utiliza clauza ORDER BY aplicată doar relaŃiei finale şi nu asupra fiecărei fraze SELECT. Regăsirea datelor din două sau mai multe relaŃii

Interogarea datelor din două sau mai multe tabele (relaŃii) presupune existenŃa unor câmpuri comune pentru realizarea operaŃiei de cuplare (operatorul JOIN). În fraza SELECT operaŃia de cuplare este definită în clauza WHERE sub forma:

<nume tabela1>.<cheie1> = <nume tabela2>.<cheie2> (unde <cheie1>, <cheie2> reprezintă câmpurile ce identifică înregistrările corespondente în cele două tabele). Pentru exemplificare pe lângă tabela Stocuri mai considerăm 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 combinaŃiile posibile între tuplele celor două tabele (produsul cartezian).

93

Fiecărei tabele i se poate atribui un alias astfel încât 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 situaŃii poate fi necesară corelarea (cuplarea) unei relaŃii (tabele) cu ea însăşi. Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe ori cu preŃuri diferite şi ne interesează poziŃiile cu preŃul minim, formulăm următoarea 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 instrucŃiuni SELECT imbricate care vor fi prezentate în detaliu în cele ce urmează. InstrucŃiuni SELECT imbricate

Limbajul SQL oferă posibilitatea construirii unor interogări complexe prin includerea în clauza WHERE a unei instrucŃiuni SELECT, a altei instrucŃiuni SELECT (numită sub-interogare sau ‘inner’) astfel:

SELECT <lista atribute> FROM <lista relaŃii> WHERE <condiŃie> (<sub-interogare>)

La rândul ei sub-interogarea poate conŃine în clauza WHERE o altă instrucŃiune SELECT obŃinând astfel o interogare complexă constituită din instrucŃiuni SELECT imbricate pe un număr oarecare de nivele. InstrucŃiunea SELECT interioară generează valori pentru condiŃia de căutare a instrucŃiunii SELECT exterioare care o conŃine (numită şi ‘outer’). O sub-interogare poate returna o singură valoare, sau poate returna mai multe valori.

În ce priveşte ordinea de evaluare a interogărilor pot exista : - sub-interogări simple - în care interogarea interioară este evaluată prima, independent

de interogarea exterioară, iar rezultatul interogării interioare este utilizat de interogarea exterioară;

- sub-interogări corelate - în care interogarea exterioară transmite repetat câte o valoare pentru interogarea interioară, care în baza valorii primite, parcurge tuplele relaŃiei şi transmite interogării exterioare rezultatul obŃinut. Astfel de interogări realizează corelarea unei relaŃii cu ea însăşi şi sunt cele mai performante.

Spre exemplu dacă presupunem că în tabela Stocuri unele produse pot apare de mai multe ori cu preŃuri diferite şi ne interesează poziŃiile cu preŃul minim, formulăm următoarea 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-interogări simple care returnează o singură valoare - pot fi utilizate în interogări imbricate având sintaxa:

SELECT <lista atribute> FROM <lista relaŃii> WHERE <atribut> = < >

Sisteme informatice

94

<= >= != (<sub-interogare>) [ORDER BY <atribut[ASC]|DESC,…]

Exemplu: SELECT CodDep,CodP,Cant FROM Stocuri

WHERE Cant > (SELECT AVG(Cant) FROM Stocuri ) ORDER BY CodDep (afişează produsele pentru care există stocuri peste medie, ordonate pe depozite).

Sub-interogari simple care returneaza mai multe valori pot fi utilizate în interogări imbricată care utilizează în clauza WHERE codiŃii care generează o mulŃime 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,ComenziWHERE Beneficiari.Nume=’Ionescu’ AND Beneficiari.Cod_Beneficiar=Comenzi.Cod_Beneficiar))

Predicatul ANY poate fi utilizat în combinaŃie cu oricare din operatorii <, >, =, <=, >=, != şi permite verificarea dacă valoarea unui atribut satisface condiŃia 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 <, >, <=, >= decât toate valorile generate de interogarea interioară (acest predicat nu poate fi utilizat cu operatorul = ce ar corespunde cazului banal în care toate interogările 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 relaŃiei există tuple care satisfac condiŃia din interogarea interioară (deci EXISTS permite specificarea mai multor atribute în interogarea interioară). Astfel spre exemplu instrucŃiunea:

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. 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 încât prin acestea să se obŃină un proiect soft operaŃional. Proiectantul va grupa funcŃiile ce trebuie să fie interconectate şi va descrie modalităŃile de realizare a legăturilor. După proiectanŃii de soft vor interveni

95

programatorii, pentru transpunerea în realitate a proiectului. Ei vor controla intrările, prelucrările şi ieşirile din sistem prin intermediul programelor [1].

Softul are două componente de bază instrucŃiunile şi modulele. InstrucŃiunile sunt operaŃiuni elementare executate de calculator prin gruparea şi selecŃia controlată a acestora pentru atingerea obiectivelor funcŃiilor de prelucrare orientate pe probleme. InstrucŃiunile constituie cel mai jos nivel al operaŃiunilor ce pot fi executate de către un limbaj de programare. Blocurile de instrucŃiuni sunt astfel grupate încât să constituie anumite structuri executabile de calculator. De modul în care sunt grupate instrucŃiunile pentru a da naştere unor structuri standard ale programelor, de relaŃiile dintre instrucŃiuni, de aranjamentul acestora depinde calitatea softului proiectat [1].

Modulul – este o colecŃie sau o formă grupată de instrucŃiuni de programe sursă. Modulele se pot grupa pentru a forma programele.

Programul, în concepŃia diverşilor autori, are semnificaŃii diferite. El este definit ca: - un set de instrucŃiuni cu ajutorul cărora se efectuează prelucrări 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 execuŃiei pe calculator,

deci o reprezentare a acestora (algoritmi şi date) Ńinând cont de restricŃiile impuse de calculator;

- o realizare a unei funcŃii f care, dată fiind o mulŃime de date x, specifică valoarea y=f(x);

Prin algoritm se înŃelege o metodă de soluŃionare a unei clase de probleme, reprezentată de o succesiune finită de operaŃii bine definite, numite instrucŃiuni.

Prin prisma complexităŃii lor programele se pot clasifica [1]: - programe simple (1000 de linii) - programe de complexitate medie(10 000 de linii) - programe complexe (peste 100 000 de linii) au numeroase module cu legături

complexe. Pentru ca programele să fie caracterizate prin eficienŃă, fiabilitate, flexibilitate,

inteligibilitate, în procesul elaborării lor trebuie să se respecte anumite principii [1]: - principiul conformării, potrivit căruia programele trebuie să fie elaborate în

conformitate cu cerinŃele utilizatorului; - principiul completitudinii constă în realizarea descrierilor complete ale obiectivelor

programului pe toate nivelurile ierarhice de descompunere; - principiul abstractizării se referă la elaborarea funcŃiei programului, Ńinând cont de

elementele esenŃiale, făcându-se abstracŃie de detaliile nesemnificative; - principiul modularizării 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 de programare, deşi mai corect ar fi să se

numească tehnici de programare [1]. Metoda programării clasice are la bază construirea monolitică a logicii

programului, fără intenŃii de structurare. Programul este privit în totalitatea lui şi analizat

Sisteme informatice

96

direct la nivelul operaŃiilor elementare pe care le implică executarea lucrării care se elaborează .

Programarea modulară constă în descompunerea programului, chiar din faza de proiectare, în module uşor de întrebuinŃat. Fiecare modul este apoi analizat ca un program distinct şi rezolvat ca atare [1].

Metoda programării structurate constă în faptul că oferă o rezolvare standardizată şi structurată, în mod unitar, a programelor, reprezentând o ridicare a activităŃii de programare la nivelul activităŃii industriale, fundamentată pe o metodologie ştiinŃifică. Programarea structurată este caracteristică dezvoltării sistemelor pe baza diagramelor fluxului de date şi utilizează limbaje structurate. Ea presupune o separare între structurile de date şi codul funcŃiilor care le prelucrează.

Metoda programării orientate-obiect - constă în abordarea naturală a lumii reale, folosind componente modularizate şi eliminând restricŃiile impuse de mediul de programare. Se definesc concepte noi de tip, clasă, moştenire, etc [Udrică M., 2000].

5.2.1. Atributele modulelor

La nivelul softului proiectat, componenta de bază este modulul. El este o colecŃie sau o formă grupată de instrucŃiuni ale programului sursă. La rândul lor, modulele se pot grupa pentru a forma programe.

Modulele programelor au următoarele caracteristici [1]: - Un modul este format dintr-un grup de instrucŃiuni care sunt contigue din punct de

vedere fizic şi sunt executate ca o unitate distinctă; - Grupurile de instrucŃiuni care formează un modul au începuturi şi sfârşituri bine

definite; - În majoritatea cazurilor, grupul de instrucŃiuni are doar un punct de intrare şi unul de

ieşire; - 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ă: funcŃia, logica şi interfeŃele.

FuncŃia unui modul constă în transformarea datelor prin procesul de execuŃie a acestuia. FuncŃia este tratată în regimul cutiilor negre, ea fiind văzută 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 intrările şi ieşirile modulului respectiv [1].

La nivelul softului, referirea la un modul este în acelaşi timp o referire la funcŃia lui. La nivelul cel mai de sus, modulele au funcŃii orientate spre problema de rezolvat, în timp ce modulele aflate pe nivelurile mai de jos au funcŃii orientate spre prelucrările pe care le realizează [1].

În diagrama de structură, folosită pentru reprezentarea grafică a proiectelor soft, un modul este reprezentat printr-o casetă (dreptunghi) ce poartă denumirea funcŃiei îndeplinite.

La atribuirea numelui unui modul trebuie să se Ńină cont de faptul că acesta trebuie să surprindă atât funcŃia proprie, cât şi pe cele ale subcomponentelor de ordin inferior. Se

97

recomandă evitarea conjuncŃiilor din structura numelor, deoarece ele ar sugera necesitatea folosirii mai multor module [1].

Logica modulului descrie prelucrările care au loc în interiorul acestuia [1]. La nivelul programării, preocuparea este, în esenŃă, legată de logica modulului,

algoritmii de prelucrare, redaŃi sub diverse forme – scheme logice, pseudocod, tabele de decizie, arbori de decizie sau combinaŃii ale acestora – sunt concepuŃi pentru prezentarea modului de transformare a intrărilor în ieşiri. Paşii algoritmilor se vor transforma în instrucŃiuni ale limbajelor de programare [1].

InterfeŃele sunt conexiuni sau cuplaje între module. InterfeŃele modulelor sunt utilizate pentru stabilirea căilor prin care să se transfere controlul de la un modul la altul [1].

Conexiunile dintre module se înregistrează pe două planuri: - al transferării controlului de la un modul la altul; - al transmiterii datelor de la un modul la altul.

În concluzie, se poate spune că eficienŃa proiectelor – soft depinde în mare măsură de eficienŃa 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 văzut din două puncte de vedere: logic şi fizic. Din punct de vedere logic, modalitatea în care intră în funcŃiune modulele este

redată prin structura ierarhică a lor [1]. Din punct de vedere fizic, după ce s-a stabilit structura logică, se va pune problema

adaptării prelucrării lor pe calculator, moment în care se va avea în vedere structura execuŃiei instrucŃiunilor, adică a secvenŃelor după care se declanşează operaŃiunile din interiorul modulelor [1].

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: secvenŃa, selecŃia, iteraŃia sau repetiŃia. Ele mai sunt cunoscute şi sub numele de structură secvenŃială, alternativă (simplă şi generalizată), repetitivă (condiŃionată anterior sau la început şi condiŃionată posterior sau la sfârşit ).

SecvenŃa asigură parcurgerea instrucŃiunilor în ordinea în care apar. SelecŃia defineşte alegerea unui grup de instrucŃiuni din două sau mai multe posibile. IteraŃia oferă posibilitatea execuŃiei repetate a unui grup de instrucŃiuni [1].

În elaborarea programelor structurate este necesar să se respecte o serie de restricŃii, şi anume [1]: - fiecare element (secvenŃa, selecŃia, iteraŃia) are un punct de intrare; - fiecare element are un punct de ieşire unic; - elementul de iteraŃie permite şi o execuŃie cu factor de repetiŃie zero, adică excluderea

elementului respectiv din execuŃie. Fiecare element din cele enunŃate (secvenŃa, selecŃia, iteraŃia) care respectă

restricŃiile de mai sus defineşte un bloc standard. Structura secvenŃială (liniară) se prezintă astfel [1]:

Sisteme informatice

98

Figura 5.1. Structura secvenŃială [1] SelecŃia (structura de tip IF-THEN-ELSE) sau structura alternativă are următoarea

formă de prezentare [1]:

Figura 5.2. Structura alternativă [1] Dacă se îndeplineşte condiŃia C, se execută operaŃiile din Bloc-1, altfel se execută

operaŃiile din Bloc-2; după execuŃia blocului, se continuă cu instrucŃiunea următoare. Structura alternativă generalizată (de tip CASE-OF) este o generalizare a selecŃiei.

Ea permite alegerea unei variante din mai multe posibile (figura 5.3).

C

Bloc - 2 Bloc -

NU DA

s1

s2

sn

99

Figura 5.3. Structura alternativă generalizată [1] IteraŃia sau structura repetitivă defineşte execuŃia repetată a unei operaŃii sau grup

de operaŃii, funcŃie de rezultatul evaluării unei condiŃii. Evaluarea condiŃiei se face fie înainte, fie după executarea operaŃiilor.

Structura repetitivă condiŃionată anterior (de tip WHILE-DO) se reprezintă ca în

figura 5.4

Figura 5.4. Structura repetitivă condiŃionată anterior [1] Structura repetitivă condiŃionată posterior (de tip DO UNTIL) are forma dinn

figura 5.5.

C

Bloc - n Bloc - 2 Bloc - 1

C

Bloc -

DN

Sisteme informatice

100

Figura 5.5. Structura condiŃionată posterior [1] O formă particulară de structură repetitivă condiŃionată posterior este structura

repetitivă cu număr definit de paşi (de tip DO FOR). Numărul de repetiŃii este controlat de o variabilă, numită variabilă de control. În reprezentarea grafică următoare, V este variabila de control, Vi este valoarea iniŃială a variabilei de control, iar R este raŃia (incrementul). O astfel de structură este redată în figura 5.6.

C

Bloc - 1

DA NU

V>Vf

V=Vi+

DA

NU

Bloc - 1

V=Vi

101

Figura 5.6. Structura repetitivă cu număr definit de paşi [1] În literatura de specialitate, se consideră că structura secvenŃială, structura

alternativă de tip IF-THEN-ELSE şi structura repetitivă condiŃionată anterior sunt suficiente pentru a defini structura de control a oricărui program. Din acest motiv, cele trei structuri de control, enumerate mai sus, sunt numite structuri fundamentale sau structuri de bază.

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 cerinŃe şi restricŃii impus de etapele parcurse anterior pentru realizarea sistemului informatic. Urmând principiile programării structurate, realizarea programelor se face în următoarele faze: definirea problemei de programat; descompunerea problemei de programat; realizarea modulară a produselor program; testarea “top-down” a produselor program; definirea programului testat şi a documentaŃiei aferente; dezvoltarea versiunii calitative a produsului program [2].

SpecificaŃiile elaborate în etapele precedente permit definirea problemei de programat prin care se formulează elementele specifice şi se analizează relaŃiile dintre aceste elemente, din punct de vedere dinamic sau static.

Descompunerea aplicaŃiei se poate face după criteriul funcŃionalităŃii, motiv pentru care elementele rezultate se mai numesc şi module funcŃionale. Din punct de vedere al fluxului datelor pot fi [2]: - module de intrare, care manipulează datele de intrare; - modulele de ieşire, care furnizează rezultate ale prelucrărilor; - module de prelucrare, care efectuează diverse operaŃii asupra datelor.

Pe baza unor funcŃiuni identificate sau a altor raŃiuni de programare, modulele pot fi divizate în continuare. Scopul acestei structurări funcŃionale până la nivel elementar este de a identifica funcŃiunile sistemului şi de a le separa, eventual, în funcŃiuni generale şi cu caracter specific aplicaŃiei.

Modulele funcŃionale pot fi descompuse apoi după criteriul omogenităŃii, rezultând modulele operaŃionale.

Realizarea modulară a produselor program presupune următoarele acŃiunile [2]: - Examinarea modulelor şi specificarea succesiunii operaŃiilor de prelucrare descrise în

acestea. - Constituirea setului reprezentativ cu date test. Setul de date trebuie sa acopere

întreaga cazuistică a sistemului informaŃional şi să testeze toate ramurile programului. - Precizarea elementelor de comunicaŃie între module, respectiv stabilirea parametrilor

de intrare/iesire în/din fiecare modul. - elaborarea algoritmii de prelucrare specifici fiecărui modul şi structura programelor. - transcrierea algoritmilor într-un limbaj de programare. - scrierea codului sursă şi obŃinerea fişierelor executabile.

Sisteme informatice

102

Prin compararea rezultatelor propuse a fi obŃinute cu cele efectiv furnizate de aplicaŃia informatică, sunt verificate sintactic şi funcŃional module din program. Dacă se realizează identitatea între cele doua categorii de rezultate, operaŃia de testare se consideră încheiată.

O atenŃie deosebită trebuie acordată întocmirii documentaŃiei programului cu observaŃia că în acest sens este recomandată autodocumentarea la nivel de modul.

5.3. Proiectarea sistemelor distribuite

Un sistem de prelucrare distribuită a datelor presupune existenŃa a două sau mai multor sisteme independente de prelucrare a datelor, numire noduri, interconectate într-o configuraŃie de reŃea. Ele folosesc facilităŃi de comunicare pentru schimbul de informaŃii şi îşi coordonează activităŃile pentru realizarea unui anumit scop. Cu alte cuvinte un sistem de prelucrare distribuită a datelor permite realizarea activităŃii de prelucrare automată a datelor într-un mediu de reŃea. Într-un astfel de mediu, cooperează trei componente tehnologice distincte: prelucrarea datelor, comunicarea datelor şi reŃeaua de calculatoare. Scopul lor este de a colabora fiecare cu fiecare, astfel încât să se realizeze obiectivele comune ale organizaŃiei [1].

Figura 5.7. 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 configuraŃie de reŃea; - o posibilitate de transfer a datelor folosind facilităŃi 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 funcŃionale.

Din punct de vedere financiar se urmăreşte maxim de profit cu minimum de cheltuieli. Din punct de vedere funcŃional, scopul este să se realizeze un sistem care să aibă cele mai bune rezultate [1].

Costul sistemului se regăseşte în costurile iniŃiale pe procesoare, perifericelor(imprimantă, scanner, etc), cablări, soft-uri, şi costuri funcŃionale (operaŃionale) cu distribuirea datelor, cu personalul, întreŃinerea sistemului, etc. PerformanŃa sistemului este apreciată prin prisma productivităŃii şi a

eficienŃei lui. Ea se determină în funcŃie de cerinŃele operaŃionale ale unui sistem de

calcul. Se consideră că performanŃa este o funcŃie a [1]:

- timpului de răspuns(intervalul de timp dintre momentul formulării unei cereri de la un terminal de comunicaŃie-date şi obŃinerea răspunsului în acelaşi loc);

NOD NOD Legătură/canal

103

- randamentului(cantitatea de date ce poate fi prelucrată de către un sistem de calcul într-o perioadă de timp);

- calităŃii serviciilor oferite utilizatorilor(siguranŃă, fidelitate, integrare, control şi acceptabilitate);

- nivelul serviciilor. Sistemul propus trebuie să fie fezabil, din punct de vedere tehnic, şi eficient, prin

prisma costurilor prelucrării automate a datelor şi a comunicaŃiilor din sistem. PerformanŃele sistemului sunt influenŃate de mai mulŃi factori, cum ar fi timpul de răspuns, randamentul, disponibilitatea, siguranŃa(securitatea sistemului).

La proiectarea sistemelor distribuite trebuie avute în vedere două componente majore: - Proiectarea nodurilor; - Proiectarea reŃelei de comunicaŃii.

Ordinea de proiectare nu este strictă rămânând la latitudinea echipei de proiectare. Trebuie să se Ńină seama de posibilitatea proiectării, după ce anumite etape au fost îndeplinite [1].

Figura 5.8. Principalele module de proiectare a sistemelor de prelucrare distribuită a

datelor [1]

Modele de sisteme distribuite

Calculatoarele personale şi staŃiile de lucru pot fi utilizate fie ca sisteme de-sine-stătătoare pentru execuŃia diferitelor aplicaŃii informatice, fie într-o configuraŃie de reŃea. O reŃea locală se bazează pe un set de calculatoare personale, fiecare cu propria memorie, astfel încât să poată folosi în comun toate echipamentele şi software-ul din reŃea. Dintre toate calculatoarele, există unul sau unele mai puternice pe care se vor afla aplicaŃii folosite în comun de celelalte calculatoare ale reŃelei. Cea mai utilizată arhitectură este arhitectura client/server. Arhitectura client/server

Sisteme PAD

Proiectare NODURI

Proiectare subsisteme de

Proiectare INTERFEłE

Sisteme informatice

104

Modelul Client /Server oferă date distribuite, portabilitate între platforme şi un acces standardizat la resurse. Termenul de Client /Server provine de la metoda tradiŃională de accesare a unui computer central numit server de către computere aflate la distanŃă sau clienŃi într-o infrastructură de reŃea.

Modelul Client /Server implică o entitate software (clientul) care efectuează cereri, acestea fiind îndeplinite de o altă entitate software(serverul) . Clientul este cel care transmite o cerere severului, acesta o interpretează şi apoi o efectuează. Pentru a putea îndeplini cererea, serverul poate referi o sursă de informaŃie (baze de date), să efectueze procesări asupra datelor, să controleze periferice sau să efectueze cereri adiŃionale altor servere. Un client poate face cereri la multiple servere şi un server poate deservi mai mulŃi clienŃi. Sursă de informaŃie (Bază de date) Cerere Procesare (Logică şi Aritmetică) Client Server Dispozitive (Imprimantă, periferice partajate) Rezultatul Servicii(Cereri adiŃionale altor servere) îndeplinirii cererii

Figura 5.9. O tranzacŃie Client /Server.

Se poate afirma că tehnologia client / server împarte o aplicaŃie în trei componente de bază: un client, un server şi o reŃea care conectează clientul la server. Atât clientul cât ş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. Când se alege un server pentru mediul de lucru client / server trebuie avute în vedere: scalabilitatea – posibilitatea de creştere a capacităŃii serverului, în limite rezonabile; toleranŃa la erori – posibilitatea de recuperare a contextului calculatorului server după producerea unei disfuncŃionalităŃi hardware; service şi asistenŃă tehnică. Calculatoarele server au utilizări variate în sistemele client / server (există servere de fişiere care asigură spaŃiul de disc centralizat care poate fi folosit conform necesităŃilor calculatoarelor client din reŃea; servere de tipărire – care colectează informaŃiile ce urmează a fi trimise către imprimantă de către calculatoarele client şi le asigură tipărirea î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 aplicaŃii – calculatoare server care rulează programe mari de aplicaŃii).

Sistemele client-server au apărut ca urmare a descentralizării activităŃii din diverse domenii, ceea ce presupune o repartizare a realizării sarcinilor pe cele două nivele: client, server. De obicei clienŃii reprezintă utilizatorii finali care vor comunica cu serverul bazei de date în cadrul unei reŃele 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:

105

- arhitectura de tip server de obiecte – în care se distribuie prelucrarea între cele două componente (server, client). Serverul este responsabil de administrarea memoriei şi zăvoarelor, efectuarea operaŃiilor în memoria secundară, securitatea, integritatea şi recuperarea bazei de date, executarea procedurilor stocate şi optimizarea interogărilor. Clientul este responsabil de administrarea tranzacŃiilor şi realizarea interfeŃei cu limbajul de programare;

- arhitectura de tip server de pagini – cea mai mare parte a prelucrărilor este realizată de către client. Serverul este responsabil de memoria secundară şi furnizează paginile corespunzător cererilor formulate de client;

- arhitectura de tip server de bază de date – cea mai mare parte din prelucrările bazei de date este efectuată de către server. Clientul transmite cererea serverului, primeşte rezultatele şi le transmite aplicaŃiei. Este modul utilizat frecvent de către sistemele relaŃionale.

În fiecare dintre cele trei cazuri serverul se găseşte pe aceeaşi maşină ca şi baza de date fizică. Clientul se poate afla pe aceeaşi maşină sau pe una diferită. În cazul bazelor de date distribuite pe mai multe maşini, clientul va comunica cu câte un server de pe fiecare maşină. De asemenea mai mulŃi clienŃi pot comunica concomitent cu acelaşi server (accesul concurent).

Arhitectura tradiŃională a sistemelor client-server este o arhitectură pe două nivele (etaje), în care la primul nivel (clientul) se realizează interfaŃa cu utilizatorul şi logica principală a aplicaŃiei, iar la al doilea nivel (serverul) se realizează validarea datelor şi accesul la baza de date. Necesitatea rezolvării unor probleme complexe care presupun accesul la baza de date a unui număr mare de utilizatori, utilizarea unor platforme hard-soft 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ă interfaŃa cu utilizatorul aplicaŃiei; - nivelul server de aplicaŃie, la care se realizează logica aplicaŃiei şi prelucrării datelor; - nivelul server de baze de date, la care se realizează validarea datelor şi accesul la baza

de date. Un server de aplicaŃie poate servi mai mulŃi clienŃi, fiind conectat fizic atât la nivelul client cât şi la nivelul server de baze de date. Spre exemplu în mediul Web, clientul poate fi un browser Web, iar serverul de aplicaŃie poate fi un server Web. Problemă rezolvată

Se consideră baza de date FurnizoriClienŃi care conŃine următoarele tabele (în

ACCESS):

PRODUSE (catalog de produse)

Sisteme informatice

106

Câmp SemnificaŃie Tip dată Dimensiune ObservaŃii

Codp Cod produs Number, Integer 4 Cheie primară

Denp Denumire produs Text 20

Desp Descriere produs Hyperlink Referă document

corespunzător

STOCURI (stocurile de produse pe depozite)


Codp Cod produs Number, Integer Lookup Wizard

4 Lookup Wizard cu tabela PRODUSE

CodDep Cod depozit Text 2

Ump Unitate de măsură produs

Lookup Wizard 8 Creare şi utilizare listă de valori

Cant Cantitate Number, Integer 4

Pret PreŃ unitar Number, LongInteger

8

FURNIZORI (catalog de furnizori)


Codf Cod furnizor Number, Integer 4 Cheie primară

Denf Denumire furnizor

Text 30

Adresaf Adresa furnizor Text 25

CLIENTI (catalog de clienŃi)

107


Codc Cod client Number, Integer 4 Cheie primară

Denc Denumire client Text 30

Adresac Adresa client Text 25

OFERTE (oferte de produse de la furnizori)


Codf Cod furnizor Number, Integer Lookup Wizard

4 Lookup Wizard cu tabela FURNIZORI

Codp Cod produs Number, Integer

Lookup Wizard 4 Lookup Wizard cu

tabela PRODUSE




8

Datao Data ofertei Date 8

Oferta Oferta furnizor Hyperlink Referă document

corespunzător

VANZARI (vânzările de produse pe clienŃi)


Codc Cod furnizor Number, Integer Lookup Wizard

4 Lookup Wizard cu tabela CLIENTI

Codp Cod produs Number, Integer

Lookup Wizard 4 Lookup Wizard cu

tabela PRODU,03SE



Cant Cantitate Number, Integer 4


8

Să se scrie comenzile SQL pentru realizarea interogărilor de mai jos:

Sisteme informatice

108

a) SituaŃia stocurilor

b)SituaŃia ofertelor

c) SituaŃia vânzărilor

d) Lista produselor pentru care nu există oferte

e) Lista produselor pentru care nu s-au făcut vânzări în perioada [Data1,Data2]

Răspuns:

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)

Câmp CodDep Codp Denp Ump Cant Pret Valoare Tabela Stocuri Stocuri Produse Stocuri Stocuri Stocuri Cant*Pret

Câmp Codf Denf Adresaf Codp Denp Ump Pret Datao Tabela Furnizori Furnizori Furnizori Produse Produse Oferte Oferte Oferte

Câmp Codc Denc Adresac Codp Denp Ump Cant Pret Valoare Datav Tabela Clienti Clienti Clienti Produse Produse Vanzari Vanzari Vanzari Cant*Pret Vanzari

Câmp Codp Denp Tabela Produse Produse

Câmp Codp Denp Tabela Produse Produse

109

Teste 2009

1. Care definiŃie este corectă:

a) Un sistem reprezintă un ansamblu de elemente (componente) interdependente, între care se stabileşte o interacŃiune dinamică, pe baza unor reguli prestabilite,

cu scopul atingerii unui anumit obiectiv; b) Un sistem reprezintă un ansamblu de identificatori care au rolul sa rezolve

activităŃi specifice.

Răspuns: a

2. Sistemul informaŃional cuprinde:

a) Ansamblul informaŃiilor interne şi externe, formale sau informale utilizate în

cadrul firmei precum şi datele care au stat la baza obŃinerii lor; b) Procedurile şi tehnicile de obŃinere(pe baza datelor primare) şi de difuzare a

informaŃiilor; c) Platforma necesară prelucrării şi disipării informaŃiilor;

d) Personalul specializat în culegerea, transmiterea, stocarea şi prelucrarea

datelor. Răspuns: a,c,d

3. Un sistem informatic este: a) un sistem destinat conducerii unei organizaŃii:

b) un sistem utilizator-calculator integrat, care furnizează informaŃii pentru a sprijini activităŃile de la nivel operaŃional şi activităŃile de management într-o organizaŃie, utilizând 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 funcŃional pentru automatizarea procesului de obŃinere a informaŃiilor şi pentru fundamentarea deciziilor.

Răspuns: b,c

4. IdentificaŃi afirmaŃia falsă:

a) Sistemul informaŃional este subordonat sistemului de conducere.

b) Sistemul informaŃional face legătura între sistemul condus şi sistemul de

conducere. c) Sistemul informatic este inclus în sistemul informaŃional.

d) Sistemul condus este subordonat sistemului informaŃional. Răspuns: d

5. Sunt componente principale ale unui sistem informatic:

a) Baza informaŃională;

Sisteme informatice

110

b) Manager general;

c) Baza tehnică;

d) Baza ştiinŃifică metodologică;

e) Sistemul de programe.

Răspuns: a,c,d,e 6. Obiectivul principal urmărit prin introducerea unui sistem informatic îl constituie:

a) asigurarea conducerii cu informaŃii reale şi în timp util necesare fundamentării şi elaborării operative a deciziilor;

b) asigurarea funcŃionării normale si optime a activităŃilor; c) creşterea productivităŃii muncii;

d) creşterea profitului;

e) îmbunătăŃirea imaginii unităŃii economice.

Răspuns: a

7. După domeniul de utilizare, sistemele informatice se clasifică în: a) Sisteme informatice pentru conducerea activităŃilor economico-sociale;

b) Sisteme informatice pentru conducerea proceselor tehnice;

c) Sisteme informatice şi expert;

d) Sisteme informatice pentru activităŃi speciale.

Răspuns: a,b,d

8. Sistemele informatice economice pot fi împărŃite după modul de organizare a datelor

în:

a) sisteme imagine; b) sisteme bazate pe tehnica bazelor de date (ierarhice, reŃea, relaŃionale,

orienatate-obiect); c) sisteme bazate pe algoritmi fundamentali;

d) sisteme bazate pe fişiere. Răspuns: b,d

9. Ciclul prelucrării datelor pentru sistemul informatic cuprinde următoarele faze:

a) culegerea datelor;

b) pregătirea datelor;

c) prelucrarea datelor;

d) ştergerea datelor. Răspuns: a,b,c

10. În faza de întreŃinere a fişierelor există mai multe activităŃi, dintre care amintim:

a) memorarea(stocarea) datelor în vederea utilizării lor viitoare;

b) actualizarea datelor memorate astfel încât să surprindă cele mai recente

evenimente;

111

c) crearea datelor;

d) indexarea datelor pentru a înlesni o uşoară regăsire a lor;

e) protecŃia datelor memorate, care cuprinde o mare varietate de proceduri şi

tehnici pentru prevenirea distrugerii lor sau a accesului neautorizat.

Răspuns: a,b,d,e 11. Metodologiile de realizare a sistemelor informatice cuprind:

a) reguli de formalizare a datelor; b) instrumente pentru concepŃia, realizarea şi elaborarea documentaŃiei;

c) modalităŃile de administrare a proiectului; d) instrucŃiuni pentru luarea deciziilor;

e) modalitatea de abordare a sistemelor.

Răspuns: a,b,c,e

12. Reprezintă modul unitar sau manieră comună în care analiştii de sisteme, programatorii şi alte categorii de persoane implicate realizează procesul de analiza a

sistemului informaŃional-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. Răspuns: a

13. Care din afirmaŃiile următoare sunt corecte:

a) Metoda top-down are ca obiectiv principal realizarea modularizării 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 abordării sistemice.

Răspuns: a 14. Nu sunt faze ale ciclului de viaŃă al dezvoltării sistemelor:

a) microanaliza;

b) analiza;

c) colectarea;

d) proiectarea logică; e) proiectarea fizică;

f) implementarea; g) întreŃinerea.

Răspuns: c

Sisteme informatice

112

15. Propunerile pentru identificarea proiectelor de dezvoltare sunt făcute de:

a) top-managerii; b) personalul auxiliar;

c) muncitori; d) departamentul utilizatorilor.

Răspuns: a, d

16. SelecŃia proiectelor de dezvoltare a sistemelor informaŃionale, urmăreşte: a) atingerea obiectivelor organizaŃiei;

b) bunul mers a informaŃiei; c) creşterea duratei de implementare.

Răspuns: a 17. Care nu sunt activităŃile efectuate în faza iniŃierii proiectului:

a) stabilirea echipei de iniŃiere a proiectului;

b) stabilirea bunelor relaŃii cu beneficiarii;

c) stabilirea planului iniŃierii proiectului;

d) stabilirea procedurilor manageriale;

e) stabilirea cerinŃelor sistemului. Răspuns: e

18. Tipurile activităŃilor executate în cadrul planificării proiectului cuprind: a) Descrierea ariei de întindere, a variantelor şi fezabilităŃii proiectului;

b) Descompunerea proiectului în activităŃi uşor executabile şi controlabile; c) Crearea bazei de date;

d) Crearea unui buget preliminar;

e) Implementarea proiectului.

Răspuns: a, b, d

19. Următoarele afirmaŃii sunt corecte:

a) Un studiu de fezabilitate are rolul de a asigura informaŃiile obiective necesare

pentru a cunoaşte 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 întreŃinere a sistemelor;

c) Diagrama Gantt este o modalitate de reprezentare grafică a proiectului. Răspuns: a, c

20. Studiile de fezabilitate trebuie să conŃină: a) Definirea problemei (o scurtă descriere a proiectului şi explicarea a ceea ce-şi

propune el să realizeze);

b) Descrierea cerinŃelor sistemului; c) ExplicaŃia critică a motivării studiului întreprins;

d) Cuantificarea tuturor costurilor materiale şi beneficiilor aferente. Răspuns: a, b, c, d

113

21. Diagramele Gantt se utilizează pentru:

a) reprezentarea ordinii activităŃilor desfăşurate pentru realizarea proiectului;

b) reprezentarea grafică a proiectului;

c) descrierea proiectelor simple sau a unor componente ale proiectelor mari;

d) monitorizarea stadiului realizării activităŃilor planificate. Răspuns: b, c, d

22. Studiul sistemului existent constă în: a) studiul activităŃilor de bază desfăşurate de sistem;

b) identificarea metodelor si mijloacelor tehnice; c) definirea caracteristicilor generale ale sistemului;

d) definirea direcŃiilor de perfecŃionare ale actualului sistem;

e) studiul sistemului de conducere.

Răspuns: a, b, c, e

23. Activitatea de determinare a cerinŃelor sistemului se concretizează în diferite forme

ale informaŃiilor colectate, cum sunt: a) copii ale interviurilor;

b) realizarea programului; c) implementarea sistemului;

d) interpretări ale răspunsurilor la chestionare. Răspuns: a, d

24. Definirea caracteristicilor generale ale sistemului economic implică:

a) cunoaşterea profilului, obiectivelor agentului economic;

b) cunoaşterea locului în sfera serviciilor şi sfera producŃiei;

c) cunoaşterea relaŃiilor de cooperare cu alŃi agenŃi economici;

d) cunoaşterea specificului activităŃii de bază ( producŃie, servicii).

Răspuns: a, b, c, d

25. Studiul sistemului de conducere se referă la identificarea: a) caracteristicilor rezultate din statutul de funcŃionare a societăŃii, tipuri de

decizii, modul de luare a deciziilor; b) principalilor algoritmi, reguli de calcul şi de control;

c) mijloacelor tehnice existente în dotarea unităŃii economice; d) modului de organizare a producŃiei.

Răspuns: a

26. Metodele tradiŃionale de determinare a cerinŃelor sistemelor sunt:

a) interviul; b) prototipizarea;

Sisteme informatice

114

c) Joint Application Design (JAD);

d) chestionarul.

Răspuns: a, d

27. Paşii prototipizării sunt:

a) Identificarea cerinŃelor principale ale sistemului; b) Realizarea prototipului iniŃial;

c) Proces iterativ de adaptare a sistemului la cerinŃele utilizatorului; d) Folosirea sistemului aprobat de utilizatori.

Răspuns: a, b, c, d 28. Scopul diagramelor de date DFD este de a scoate în relief, într-o manieră cât mai

sugestivă, următoarele aspecte:

a) sursa datelor de prelucrare;

b) macheta datelor de prelucrare;

c) destinaŃia datelor prelucrate;

d) legătura existentă între prelucrări şi activitatea de stocare a datelor. Răspuns: a, c, d

29. IdentificaŃi afirmaŃia 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ă funcŃiile de prelucrare a datelor executate de către

sistemul informaŃional curent;

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

structura lor şi cerinŃele funcŃionale ale noului sistem;

d) Diagrama fluxului de date prezintă modelarea conceptuală a datelor.

Răspuns: d

30. Simbolul folosit în diagramele DFD realizate cu SSADM (Structured Systems

Analysis and Design Methodology), pentru reprezentarea fluxului de date sunt: a) săgeată;

b) elipsă; c) cerc.

Răspuns: a 31. Câte entităŃi externe conŃine diagrama de context pentru aplicaŃia Decontări:

115

patru entităŃi; b) cinci entităŃi; c) nici o entitate.

Răspuns: b

32 Raportul detaliat al cerinŃelor sistemului conŃine următoarele elemente:

a) refacerea analizelor pentru întregul sistem; b) descrierea şi prezentarea unui exemplar al tuturor intrărilor în sistem, inclusiv

numele fiecărei intrări, sursa, cine îl completează, ce date va conŃine şi cum vor fi culese datele;

c) o descriere şi un model de exemplar pentru fiecare ieşire din sistem (rapoarte, documente).

Răspuns: b, c

33. Principalele elemente ale documentaŃiei elaborate pentru modelarea logicii proceselor sunt:

a) reprezentarea în engleza structurată; b) reprezentarea logicii proceselor prin tabele de decizie; c) reprezentarea prin diagrame entitate-relaŃie; d) reprezentarea logicii proceselor prin arbori de decizie; e) tabelul sau diagrama stărilor de tranziŃie.

Răspuns: a, b, d, e 34. Cea mai cunoscută formă utilizată pentru modelarea conceptuală a datelor este:

a) diagrama entitate-relaŃie (DER); b) diagrama fluxului de date (DFD);

c) diagrama stărilor de tranziŃie.

Răspuns: a 35. În DER pentru fiecare entitate reprezentată se apelează la simbolul:

Sisteme informatice

116

a) cerc;

b) săgeată;

c) romb;

d) dreptunghi.

Răspuns: d 36. Nu sunt tipuri de relaŃii:

a) relaŃia unu-la-unu; b) relaŃia unu-la-multe; c) relaŃia absolută; d) relaŃia unei entităŃi cu ea

însăşi. Răspuns: c

37. Care din afirmaŃiile următoare sunt adevărate:

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) EntităŃile sunt obiecte sau evenimente (fenomene sau procese economice, în

cazul nostru). c) Un atribut este o proprietate sau o caracteristică a unei entităŃi care prezintă

interes pentru organizaŃie. Răspuns: a, b, c

38. AfirmaŃiile următoare 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 regăsi într-un flux al datelor generate de un proces al DFD.

Răspuns: b

39. Prezentarea informaŃiile 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. Răspuns: a, c, d

40. Macheta imprimantei cuprinde: a) antet; b) titlu;

c) date elementare ce se imprima rând de rând; d) totalurile.

Răspuns: a, b, c, d 41. Detaliile şi indicaŃiile tehnice de realizare a machetei imprimantei se referă la:

117

a) volumul datelor de ieşire;

b) intensitatea datelor;

c) contrast.

Răspuns: a

42. Alegerea tipului de suport fizic de ieşire (imprimanta, display, etc.) se face în funcŃie de:

a) sursa de energie; b) calitatea datelor; c) costul suportului. Răspuns: c

43. În definitivarea formei şi formatului de prezentare a situaŃiilor finale trebuie să Ńinem seama de o serie de considerente practice cum ar fi:

a) Respectarea unor cerinŃe ale factorilor de decizie privind macheta situaŃiei

finale;

b) RestricŃii tehnice;

c) Utilizarea formularelor pretipărite;

d) Utilizarea generatoarelor de rapoarte. Răspuns: a, b, c, d

44. ActivităŃile 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.

Răspuns: a, d

45. La proiectarea intrărilor este necesar să se realizeze, în principal următoarele

activităŃi:

a) alegerea colecŃiilor de date;

b) proiectarea machetelor documentelor de intrare;

c) alegerea regulilor de control şi validare a datelor; d) proiectarea formularelor (videoformatului) de intrare.

Răspuns: b, c, d 46. Macheta documentului de intrare conŃine:

a) antetul documentului; b) diagrama fluxului de date; c) denumirea documentului.

Răspuns: a, c

47. Nu sunt metode de interacŃiune om – maşină: a) interacŃiunea permanentă,

Sisteme informatice

118

b) interacŃiunea prin meniuri,

c) interacŃiunea bazată pe obiecte icons,

d) interacŃiunea prin limbaj natural.

Răspuns: a

48. Echipamentele necesare interacŃiunii cu sistemul sunt: a) eyescreen; b) keyboard; c) mouse.

Răspuns: b, c 49. Construirea prototipului secvenŃei de derulare a dialogurilor se poate face cu ajutorul:

a) instrucŃiunilor repetitive; b) produselor CASE; c) mediile de dezvoltare grafică.

Răspuns: b, c

50. În procesul de modelare logică a datelor sunt paşi esenŃiali: a) Realizarea unui model logic al datelor din perspectiva utilizatorului (formulare

şi rapoarte) privind aplicaŃia, folosindu-se principiile normalizări;

b) Implementarea modelului logic al datelor.

c) Transformarea modelului conceptual al datelor (entitate-relaŃie), realizat fără

să se Ńină cont de perspectiva utilizatorului, într-un set de relaŃii normalizate;

Răspuns: a, c

51. Nu sunt elemente de bază ale structurii relaŃionale a datelor:

a) RelaŃia; b) Atributul;

c) Fişierul; d) Domeniul;

e) Tuplul. Răspuns: c

52. Paşii parcurşi în procesul de transformare a diagramelor entitate-relaŃie în relaŃii sunt:

a) Reprezentarea entităŃilor;

b) Reprezentarea legăturilor;

c) Normalizarea relaŃiilor.

Răspuns: a, b, c 53. 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; Răspuns : a

119

54. Proiectarea fizică a sistemelor informatice implică:

a) proiectarea fizică a bazelor de date şi a fişierelor.

b) proiectarea structurii sistemului şi a programelor.

c) proiectarea documentaŃiei sistemului analizat.

d) proiectarea strategiilor de prelucrare distribuită. Răspuns : a, b, d

55. Proiectarea fizică a bazelor de date şi a fişierelor îş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.

Răspuns : a

56. Sunt structuri de control fundamentale în realizarea programelor:

a) structura secvenŃială;

b) structură funcŃională;

c) structura alternativă; d) structura organizaŃională:

e) structura repetitivă. Răspuns : a, c, e

57. Structura repetitivă condiŃionată anterior este: a) de tip WHILE-DO;

b) de tip DO UNTIL;

c) de tip DO FOR.

Răspuns : a

58. Nu sunt metode de programare:

a) metoda programării clasice;

b) metoda programării structurate;

c) metoda programării orientate-obiect; d) metoda programării iterative.

Răspuns : d 59. Un modul are componente de bază:

a) funcŃia;

b) schema;

c) logica;

d) interfeŃele.

Răspuns : a, c, d

60. FuncŃia unui modul constă în: a) transformarea datelor prin procesul de execuŃie a acestuia.

Sisteme informatice

120

b) descrierea prelucrărilor care au loc în interiorul acestuia.

c) legătura cu alte module.

Răspuns : a

61. Realizarea modulară a programelor corespunde principiilor: a) programării clasice;

b) programării structurate;

c) bazelor de cunoştinŃe; Răspuns : b

62. Principalele module de proiectare a sistemelor de prelucrare distribuită a datelor sunt: a) proiectarea nodurilor;

b) proiectarea diagramelor; c) proiectarea reŃelei de comunicaŃii.

Răspuns : a, c

63. Nu sunt componente de bază ale tehnologiei client/server:

a) clientul; b) administratorul de sistem;

c) serverul; d) reŃeaua care conectează clientul la

server.

RĂSPUNS : B

64. Care dintre următoarele instrucŃiuni 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.

Răspuns : a 65. Care dintre următoarele instrucŃiuni repetitive sunt condiŃionate posterior ?

a) FOR...NEXT ; b) WHILE...WEND ; c) DO WHILE...LOOP; d) DO UNTIL...LOOP; e) DO...LOOP WHILE.

Răspuns : e 66. Modelul conceptual pune în evidenŃă:

a) modul de stocare a datelor pe suportul de memorare; b) reprezentarea logică, detaliată a entităŃilor, asocierilor (legăturilor) şi datelor elementare ale unei organizaŃii; c) structura globală de organizare a datelor.

Răspuns: b), c) 67. Normalizarea unei relaŃii constă în:

121

a) Descrierea relaŃiei în limbajul de descriere a datelor; b) Identificarea dependenŃelor între atributele relaŃiei; c) Descompunerea relaŃiei în relaŃii echivalente urmărind eliminarea redundanŃei datelor şi anomaliilor la efectuarea operaŃiilor de adaugare, actualizare şi ştergere în baza de date.

Răspuns: c) 68. 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; b) structura globală de organizare a datelor.

Răspuns: a), b) 69. Sistemul de Gestiune a Bazelor de Date este:

a) un sistem de programe care permite definirea, crearea şi întreŃinerea bazei de date precum şi accesul controlat la baza de date;

b) un sistem de programe pentru interogarea bazei de date. Răspuns: a)

70. Obiectivul principal al instrumentelor CASE este: a) Punerea în practică a produselor-program de proiectare şi realizare a softului

cu ajutorul calculatorului. b) Simplificarea activităŃilor de proiectare şi realizare a sistemelor/ aplicaŃiilor.

c) Aducerea în faŃa analistului a problemelor supuse analizei.

d) Folosirea depozitelor modularizate.

Răspuns: a

71. Avantajele sistemelor CASE sunt:

a) exploatarea sistemului; b) creşterea vitezei de realizare a sistemelor;

c) realizarea succesivă a componentelor unui sistem; d) simplificarea activităŃilor de proiectare şi realizare a sistemelor/aplicaŃiilor.

Răspuns: b, c, d 72. Instrumentele CASE se bazează pe:

a) o funcŃie fundamentală; b) două funcŃii fundamentale;

c) mai multe funcŃii fundamentale.

Răspuns: b

73. Caracteristicile mediilor moderne de tip CASE sunt:

a) integrarea;

b) aranjarea; c) descompunerea;

d) exploatarea.

Sisteme informatice

122

Răspuns: a, c

74. Domeniile către care se orientează Upper CASE-ul, sunt:

a) analiza cerinŃelor sistemului;

b) proiectarea şi modelarea funcŃională şi procedurală;

c) modelarea datelor şi proiectarea bazei de date; d) generarea codurilor.

Răspuns: a, b, c, d 75. Nu sunt corecte următoarele afirmaŃii:

a) CASE reprezintă Proiectarea Sistemelor Asistată de Calculator; b) Instrumentele CASE implică utilizarea calculatorului ca un mijloc de susŃinere

a activităŃilor de planificare, definire, proiectare şi realizare a softului.

c) CASE reprezintă Proiectarea Sistemelor cu Ajutorul Calculatorului;

d) CASE reprezintă Componente Asamblate ale Sistemelor Economice.

Răspuns: d

Întrebări 1. EnumeraŃi principalele activităŃi din cadrul unei intreprinderi în vederea identificării entităŃilor bazei informaŃionale.

2. DefiniŃi tipurile de reŃele de calculatoare după aria de întindere geografică. 3. DefiniŃi tipurile de reŃele de calculatoare după accesibilitate. 4. PrezentaŃi tipurile de echipamente care pot fi utilizate în cadrul unui sistem informatic. 5. EnumeraŃi produsele software de bază care pot fi utilizate pentru realizarea unui

sistem informatic. 6. DefiniŃi ciclul de viaŃă a unui sistem informatic. 7. EnumeraŃi etapele ciclului de viaŃă a unui sistem informatic în modelul cascadă. 8. EnumeraŃi metodologiile utilizate în funcŃie de modul de abordare şi domeniul de aplicabilitate

9. EnumeraŃi cele 4 nivele care pot fi identificate în organigrama unei unităŃi economice Productive.

10. DescrieŃi tipurile de legături care pot exista între două mulŃimi de entităŃi.

123

11. DefiniŃi cheia unei relaŃii.

12. ENUMERAłI METODE MODERNE DE ANALIZĂ ŞI DETERMINAREA CERINłELOR SISTEMULUI.

Răspuns: - JAD (Joint Application Design); - Prototipizarea.

13. ENUMERAłI ARHITECTURILE DE BAZĂ PENTRU UN SISTEM CLIENT-

SERVER DUPĂ ROLUL PECARE ÎL AU

COMPONENTELE CLIENT ŞI SERVER;

RĂSPUNS:

- arhitectura de tip server de obiecte; - arhitectura de tip server de pagini; - arhitectura de tip server de bază de date. 14. EnumeraŃi cele 3 nivele ale noii arhitecturi client-server definite ca urmare a

utilizării a unor platforme hard-soft diferite, precum şi integrării bazelor de date în mediul Web:

Răspuns: - nivelul client, la care se realizează interfaŃa cu utilizatorul aplicaŃiei; - nivelul server de aplicaŃie, la care se realizează logica aplicaŃiei şi prelucrării datelor; - nivelul server de baze de date, la care se realizează validarea datelor şi accesul la baza

de date. 15. EnumeraŃi tipurile de instrumente CASE după metodologia pe care o încorporează pentru realizarea sistemelor. Răspuns:

- instrumente CASE bazate pe metodologia structurată; - instrumente hibride, ce conŃin elemente specifice orientării-obiect, dar care nu

permit realizarea sistemelor orientate-obiect; - instrumente pur orientate-obiect.

16. EnumeraŃi componentele produsului Westmount I-CASE Yourdon. Răspuns: Repository este componenta centrală a arhitecturii Westmount I-CASE Yourdon. Repository este implementat cu ajutorul unui SGBD relaŃional: Informix, Ingres sau Oracle.

Sisteme informatice

124

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 aplicaŃiei este strâns 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 execuŃie şi testarea aplicaŃiei. Generatorul de cod generează codul DDL (în SQL) ce defineşte structura fizică a bazei de date şi codul aplicaŃiei în limbajul C îmbogăŃit cu instrucŃiuni SQL pornind de la specificaŃiile din schemele de structură. Docwriter este componenta care permite generarea documentaŃiei pentru fiecare etapă de realizare a sistemului. 17. Instrumentele CASE orientate-obiect, din punct de vedere al etapelor ciclului de viaŃă al sistemelor, pot fi grupate în instrumente: Răspuns:

- Upper CASE orientat-obiect pentru analiza şi proiectarea sistemelor; - Lower CASE orientat-obiect pentru generarea codului-sursă al aplicaŃiilor; - I-CASE orientat-obiect care acoperă întregul ciclu de viaŃă.

125

BIBLIOGRAFIE [1] Oprea D. – Analiza şi proiectarea sistemelor informaŃionale economice, Ed. POLIROM, Iaşi, 1999 [2] Chindea M. E. – Proiectarea sistemelor informatice economice, Bucureşti, 1999 [3] Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed. Cison, Bucureşti 2000 [4] Vasilescu P., Dunca V. – Proiectarea sistemelor informatice, Ed. Tehnică, Bucureşti, 1979 [5] Popescu I. – Baze de date relaŃionale: proiectare şi implementare, Ed. UniversităŃii din Bucureşti, Bucureşti, 1996 [6] Balan D., Balan G. – Sistemul informaŃional în gestionarea întreprinderilor, Ed. Junimea, Iaşi, 1998 [7] Roger J. - Utilizare ACCESS 95, Ed. Teora, Bucureşti, 1995 [8] Udrică M. – Modelarea orientată obiect, Ed. Cison, Bucureşti, 2000 [9] Brânzei R. – Sisteme informatice, Ed. UniversităŃii “Al. I. Cuza”, Iaşi, 1995 [10] Robert Dollinger-Baze de date şi gestiunea tranzacŃiilor, ClujNapoca, 1998 [11] N. Morariu, V. Lupu, O. Hurjui, Baze de date, ISBN 973-8293-83-9, Editura Univ. “Ştefan cel Mare” Suceava,117 p, Suceava, 2003. [12] N. Morariu, ”Baze de date. Îndrumar de laborator”, ISBN 973-666-159-8, Editura Univ. “Ştefan cel Mare” Suceava, 88 p, Suceava, 2005. [13] M. Cristescu, Baze de date utilizate în mediul economic, Editura ”ALMA MATER”, Sibiu, 2007; [14] M. Cristescu, Baze de date post-relationale, Editura Universității ”Lucian Blaga” din Sibiu, Sibiu, 2008.

Date post:	27-Jun-2015
Category:	Documents
Upload:	vandasofia
View:	125 times
Download:	9 times

Sisteme In Format Ice de Gestiune. Cristescu M.

Documents