SISTEME INFORMATICE DE GESTIUNE LECT UNIV DR ROTARU SIMONA

1.INFORMATIZAREA PROCESELOR ECONOMICE CERIN A MANAGEMENTULUI MODERN

LOCUL I ROLUL SISTEMULUI INFORMAIONAL N CONDUCEREA ORGANIZAIILOR ECONOMICE n condiiile societii informatizate conducerea unei organizaii trebuie s dispun de informaii n timp real, att din interior, ct i din exteriorul su. Sarcina de colectare, prelucrare, stocare i furnizare ale informaiilor i cunotinelor revine sistemului informaional al organizaiei. Evoluia culminant a tehnologiei informaionale din ultima perioad de timp a creat o egalitate, n planul practicii, ntre noiunile de sistem informaional i sistem informatic. Cu toate acestea teoretic se poate face distincie. Prin sistem informaional nelegem ansamblul de resurse materiale i financiare care utilizeaz tehnologiile informaionale pentru a culege, prelucra, stoca, regsi, transmite i vizualiza informaiile utilizate n procesele ce au loc n perimetrul unei ntreprinderi. Pe de alt parte, n literatura de specialitate informatic, i mai ales economic, nu s-a ajuns n ara noastr la un consens, purtndu-se nc discuii dac sistemul utilizat pentru a oferi informaiile necesare celor vizai s se numeasc sistem informaional sau sistem informatic. Dac studiem literatura anglo american, ntlnim termenii de information system, ceea ce nseamn sistem informaional i computer based information system, adic ceea ce noi considerm sistem informatic. Dup cum se arat ntr-o recent lucrare recent autohton, lucrurile stau n felul urmtor: datorit nivelului tehnologic la care s-a ajuns n aceste ri, toi autorii dup ce fac delimitarea menionat, folosesc termenul de information system, motivnd gradul ridicat de automatizare a activitilor implicate n culegerea, prelucrarea i diseminarea informaiilor. Acest mod de abordare este normal dac inem cont c n rile dezvoltate s-a trecut de o bun bucat de vreme la abordarea sistemelor n contextul fenomenelor de globalizare, existnd preocupri legate de reele metropolitane, naionale i internaionale. Trebuie s inem seama de faptul c n ara noastr informatizarea nu a atins nivelul rilor dezvoltate, partea de prelucrare uman continu s aib o pondere important i, deci, nu ne aflm n aceeai situaie. Pe parcursul acestei lucrri, ns, ne vom referi la sistemele informaionale bazate pe mijloacele automatizate de prelucrare a datelor.

Pentru nelegerea sistemelor informaionale este necesar s amintim i alte caracteristici importante ale acestora. Astfel, un sistem exist i funcioneaz ntr-un mediu ce conine alte sisteme. Dac un sistem constituie una dintre componentele unui sistem mai mare, atunci reprezint un subsistem, iar sistemul mai mare este mediul lui. ntreprinderile sunt sistemele organizaionale n care resursele (intrri) sunt transformate prin diferite procese specifice (prelucrri) n bunuri i servicii (ieiri) (Fig.1)
control

Sistem decizional
comunicare

feed-back

Sistem informaional
comunicare

Resurse economice oameni bani materiale utilaje Sistem operaional energie

Procese organizaionale realizare de produse i servicii marketing desfacere alte procese

Produse i servicii
produse servicii pli informaii alte rezultate

Fig. 1 Sistemul organizaional

Aadar, putem considera ansamblul activitilor din cadrul unei ntreprinderi ca fiind rezultatul aciunii conjugate a trei subsisteme (pe care pentru simplificare le vom numi sisteme, interschimbabilitatea noiunilor fiind admis): sistemul de conducere (de management sau decizional), ce are rolul de a conduce activitile ce se desfoar n cadrul ntreprinderii pentru realizarea obiectivelor stabilite, constituind regulatorul ntregului sistem; sistemul operaional (condus sau de execuie), ce are menirea de a executa operaiunile din cadrul activitii declanate ca urmare a unei decizii, folosind resursele stabilite conform obiectivelor; sistemul informaional (de legtur), ce asigur legtura n ambele sensuri ntre cele dou sisteme. Relatia existenta intre sistemul informational si sistemul decizional, precum si legatura stabilita intre sistemul informational si sistemul condus este scos in evidenta de abordarea sistemica

Sistemul informaional ofer elemente pentru cunoaterea modului de desfurare a fenomenelor i proceselor de natur economic i social dintr-o organizaie. Atunci cnd apare o problem care trebuie rezolvat, n domeniul produciei, al vnzrilor, al personalului, sistemul informaional ajut la evaluarea situaiei existente, la depistarea cauzelor care o provoac. El reprezint un sprijin pentru managerii de la orice nivel ierarhic i asigur o intervenie operativ i competent n organizarea i dirijarea activitilor, o exercitare corespunztoare a controlului aplicrii deciziilor luate. Informatiile de programare, planificare si previziune au un caracter relativ sintetic, dar sunt obtinute de cele mai multe ori pe baza calculelor analitice

Un sistem informaional modern trebuie s asigure: informarea la toate nivelele; operativitatea informrii; selectarea informaiilor; adaptabilitatea la modificri (modificarea cererilor de informaii, modificarea datelor de intrare, modificarea structurii organizatorice, modificarea metodelor de prelucrare a datelor); precizia i exactitatea informaiilor. COMPONENTELE I RESURSELE SISTEMULUI INFORMATIC Schematic, prin prisma activitilor, un sistem informatic poate fi reprezentat prin triada: intrri prelucrri ieiri (Fig.2).
Intrri date informaii operaiuni Prelucrri hardware software resurse umane

Ieiri
lista/raport grafice indicatori

alte ieiri

Control analize decizii

Feed - back

Fig. 2 Structura unui sistem

informatic Din reprezentarea grafic se observ componentele de baz ale oricrui sistem informatic, i anume: resursele umane, resursele hardware, resursele software, resursele de date i resursele de reele. 3

Resursele hardware cuprind totalitatea mijloacelor tehnice de culegere, transmitere, stocare i prelucrare a datelor. Resursele software includ totalitatea programelor pentru funcionarea sistemului informatic, n concordan cu funciunile i obiectivele ce i-au fost stabilite. Se au n vedere att programele de baz (SOFTWARE-ul de sistem), ct i programele aplicative (SOFTWARE-ul aplicativ). Resursele umane reprezint toate categoriile de utilizatori care au acces la baza de date n diverse faze ale ciclului de via al acesteia. CLASIFICAREA SISTEMELOR INFORMATICE Este evident c ntr-o organizaie, i n general n organizaiile mari, funcioneaz n paralel i n interdependena mai multe subsisteme informaionale n funcie de activitile ce se desfoar n ntreprindere, de angajaii care particip la aceste activiti, de compartimentele funcionale implicate. Din cauza interdependenei acestor subsisteme, este dificil ca ele s fie delimitate, mrimea i structura lor fiind diferite de la ntreprindere la ntreprindere. Muli autori au ncercat totui s stabileasc diverse tipuri de sisteme informaionale ns prerile acestora difer. James A. Senn a fcut o astfel de determinare n lucrarea sa Informating Sistems n Management i a stabilit c exist patru tipuri de sisteme informaionale: 1 Sistemul de procesare a tranzaciilor care presupune prelucrarea datelor referitoare la tranzacii. Operaiile la care sunt supuse aceste date sunt nregistrarea, clasificarea, sortarea, calculaia, totalizarea, stocarea i listarea rezultatelor; 2. Sistemul informaional pentru management (sistemul rapoartelor manageriale) furnizeaz informaii pentru fundamentarea deciziei unde informaiile necesare pot fi identificate n avans. Deciziile fundamentate prin acest sistem se repet frecvent; 3. Sistemul de fundamentare a deciziei (sistemul suport) care asist managerii n luarea unor decizii unice i nerepetabile care sunt relativ nestructurate. O parte a procesului decizional este s se determine care factori sunt luai n considerare i ce informaie este necesar; 4. Sistemul informaional al de birou (office sistem) care combin procesarea datelor, telecomunicaii i procesarea pe calculator a informaiilor de birou redactate manual. n general acest sistem informaional este o reproducere n miniatur a sistemului informaional de la nivelul organizaiei. Un alt criteriu de clasificare al sistemelor informatice este n funcie de nivelul ierarhic ocupat de sistemul economic n structura organizatoric a organizaiei: Sisteme informatice pentru conducerea activitii la nivelul organizaiilor economice. Acestea pot fi descompuse n subsisteme informatice asociate funciunilor organizaiilor economico-sociale sau chiar unor activiti. Sisteme informatice pentru conducerea activitii la nivelul organizaiilor economico4

sociale cu structur de grup. Sunt incluse sistemele informatice la nivelul regiilor autonome. Sisteme informatice teritoriale. Sunt constituite la nivelul unitilor administrativ-teritoriale i servesc la fundamentarea deciziilor adoptate de ctre organele locale de conducere. Sisteme informatice pentru conducerea ramurilor, subramurilor i activitilor la nivelul economiei naionale. Se constituie la nivelul ramurilor, subramurilor i activitilor individualizate n virtutea diviziunii sociale a muncii i specificate n clasificarea ramurilor economiei naionale. Clasificarea sistemelor informatice dup scopul urmrit: Automatizarea activitilor de rutin; Sprijinirea proceselor de comunicare; Sprijinirea procesului decizional; Sprijinirea top-managerilor. Clasificarea sistemelor informatice dup elementul supus analizei: Sisteme informaionale orientate spre funcii; Sisteme informaionale orientate spre procese; Sisteme informaionale orientate spre date; Sisteme informaionale orientate spre obiecte; Sisteme informaionale orientate spre mesaje /comunicri; Sisteme informaionale orientate spre informaii tiinifice. Clasificarea sistemelor informatice dup modul de organizare a datelor: Sisteme bazate pe fiiere clasice; Sisteme bazate pe tehnica bazelor de date: ierarhice, reea, relaional, orientate-obiect, neuronale; Sisteme mixte. Clasificarea sistemelor informatice dup metoda folosit n analiza i proiectarea sistemelor: Sisteme dezvoltate dup metoda sistemelor; Sisteme dezvoltate dup metoda clasic a ciclului de via a sistemelor; Sisteme dezvoltate dup metoda structurat; Sisteme dezvoltate dup metoda orientat obiect; Sisteme dezvoltate dup metoda de realizare rapid (RAD Rapid Application Development); Sisteme dezvoltate dup metoda echipelor mixte (JAD Join Application Design); Sisteme dezvoltate dup metoda participativ; Sisteme dezvoltate dup metoda prototipurilor. 2. METODOLOGII DE REALIZARE A SISTEMELOR INFORMATICE 2.1METODE DE ABORDARE A SISTEMELOR INFORMATICE Elaborarea unui produs informatic constituie o activitate deosebit de complex. O

asemenea activitate nu se poate desfura dect pe baze metodologice riguroase, generatoare de eficienta i eficacitate n management i n plan economic. Etapele de realizare a unui sistem informatic: analiz, proiectare, implementare sunt unanim recunoscute de toi realizatorii de sisteme informatice. Nu se pune n discuie denumirea etapelor sau succesiunea lor, ci modul de grupare a activitilor necesare procesului de elaborare a unui sistem informatic. Din aceste considerente etapele de realizare a unui sistem informatic sunt tratate n detaliu sau mai superficial, n functie de contextul n care au aparut i n functie de modul concret de realizare a unui sistem informatic. Un aspect comun pentru aceste etape i activiti este faptul c trecerea de la o etap la alta se face numai dup o analiz de fond a modului de realizare a sarcinilor, etapelor parcurse i avizrii de ctre factorii de rspundere ai beneficiarului a rezultatelor obinute. De asemenea, orice etap, parcurs deja, se finalizeaz cu activiti de pregtire a etapei urmtoare, prin elaborarea sau actualizarea planului de lucru. Se desprinde concluzia, c realizarea unui sistem informatic impune folosirea unor resurse materiale, umane i financiare, iar utilizarea eficient a acestora nu se poate realiza dect apelnd la cele mai performante i moderne metodologii de realizare a sistemelor informatice. Putem defini metodologia de realizare a unui sistem informatic ca o implementare fizica a ciclului de viata a sistemelor care include: activiti pas cu pas pentru fiecare etap de lucru; regulile individuale i de grup pentru fiecare activitate; standardele de calitate n fiecare activitate; instrumentele i tehnicile utilizate n fiecare activitate. O metodologie de realizare a unui sistem informatic este o mulime de concepte fundamentale, reguli de notaie, ce sunt utilizate mpreun cu mulimea proceselor i a regulilor empirice recomandate pentru construirea modelelor i implementarea lor. Altfel spus, o metodologie este o expresie a ciclului de viata considerat ca fiind cel mai adecvat pentru dezvoltarea unui sistem dat. Din aceste definitii, constatam c o metodologie de realizare a unui sistem informatic trebuie s cuprind: modul de abordare a sistemelor informatice; modaliti de derulare a ciclului de viata a sistemelor informatice; metode i tehnici de realizare a sistemelor informatice; modaliti de conducere a proiectului (planificare, organizare, urmrire). Caracteristicile eseniale ale principalelor metode de abordare a sistemelor Dup prezentarea principalelor opinii exprimate n literatura de specialitate cu privire la evoluia i clasificarea metodelor de abordare a sistemelor informaionale, vom face o scurt prezentare a principalelor abordri n dezvoltarea sistemelor informaionale. n acest sens, vom

urma gruparea prezentat n finalul paragrafului anterior i care se regsete de altfel, n mod explicit sau implicit, n majoritatea opiniilor exprimate n literatura de specialitate. Metoda descompunerii funcionale (orientate-funcii) Dintre autorii remarcabili care au abordat descompunerea funcional i enumerm pe civa, cum ar fi DeMarco, Yourdon i Constantine, Jackson, Page-Jones, Warnier-Orr, Dahl, Marco & Mc Gowan. Descompunerea funcional este cea care anun apariia proiectrii structurate i analizei structurate. Ea a fost conceput cu scopul controlrii complexitii prin operaiuni de tipul devide et impera. Fiecare funcie este descompus n subfuncii .a.m.d., pn cnd se obin forme uor de transpus n instruciunile limbajelor de programare. i n cazul descompunerii funcionale conceptele specifice au fost introduse mai nti n programarea structurat (Dahl, 1972) i apoi n proiectare, urmat de analiz. Aceeai situaie este ntlnit i n varianta orientrii - obiect. Descompunerea funcional (DF) este vzut ca o sum de funcii, subfuncii i interfee funcionale, sub forma unei ecuaii: DF=Funcii +Subfuncii +Interfee funcionale. Printr-o astfel de reprezentare se ilustreaz modul n care recunoatem o descompunere funcional. Obiectul l constituie prelucrrile necesare n noul sistem. Analistul va specifica prelucrrile i interfeele funcionale. Metoda are ceva puncte tari: simplitate - fiind o cale natural de rezolvare a unei probleme; obinerea destul de lejer a cerinelor utilizatorului; generarea de soluii pe diferite niveluri de abstractizare (sistem, subsistem, funcie, subfuncie). Ca puncte slabe sunt descrise: concentrarea eforturilor spre funcii conduce la culegerea multor date redundante; inexistena unor reguli precise de descompunere; evidenierea anevoioas a interaciunilor non-ierarhice din sistemele complexe. Disfuncionalitile metodei au fost mult anihilate prin soluii ingenioase de tipul coeziunii i cuplrii, introduse spre sfritul anilor 80 de Page & Jones i Yourdon/Constantine. Metoda fluxului de date O alt metod i n acelai timp o alt modalitate de reprezentare a domeniului problemei i responsabilitilor sistemului printr-o specificaie tehnic este metoda orientat spre procese, deseori descris ca ,,analiza structurat. 7

Ecuaia metodei este: Metoda fluxului de date = Fluxul (i controlul) datelor + Transformrile (i controlul) datelor + Stocarea (i controlul) datelor + Terminatori + Specificaii de proces + Dicionarul datelor. Prin aceast metod, analitii efectueaz reprezentarea lumii reale prin linii ale fluxurilor n analiza structurat. Se vorbete despre o metod ,,veche, cu reprezentanii De Marco - 1978 i Gane & Sarson - 1977, i despre o metod ,,modern de analiz structurat, lansat n dezbateri la nivelul anului 1982 i prin materiale editate n 1984 - reprezentative fiind lucrrile autorilor McMenamin & Palmer, din 1984, i a lui Yourdon, Analiza modern structurat, din 1989. n ultima variant sunt definite cu claritate evenimentele din lumea real la care sistemul trebuie s rspund, o form embrionar a actualelor interaciuni dintre utilizator i sistem, bazate pe mesaje. De asemenea, printr-o documentaie suplimentar, sunt incluse fluxurile datelor i transformrilor la nivel inferior prin intermediul dicionarului de date, respectiv al specificaiilor proceselor. Cum metoda orientat pe procese are nc un mare grad de asemnare cu descompunerea funcional, criticile metodei descrise anterior se raporteaz i n cazul de fa. Oricum, dup cum se va vedea ulterior, multe elemente ale acestei metode sunt preluate de ctre metodele orientate-obiect. Metode orientate spre informaii (orientate-date) Dou realizri remarcabile n domeniu au dat tonul unei noi orientri n abordarea sistemelor: modelarea datelor cu ajutorul diagramelor entitate-relaie, de ctre Peter P. Chen (1976) i ingineria informaiei, n viziunea lui James Martin. Acestora li s-au adugat alte reuite de esen. Termenul ,,obiect este lansat la mijlocul anilor 70 ntr-o form ,,original, nestandard, dac ne gndim fie la semnificaiile anterioare ale lui , fie la cele curente , firesc , din domeniul abordrii sistemelor. Aa cum este el folosit de Chen , de cei ce se ocup cu modelarea informaiilor (cum ar fi Flavin, n 1981) sau de cei ce trateaz modelarea semantic a datelor (Shlaer & Mellor, n 1988), obiectul este un simbol prin care se reprezint una sau mai multe ,,ocurene (cazuri) ale ,,entitilor lumii reale. Metoda este identificat prin urmtoarea ecuaie: Modelarea informaiilor = Obiecte +Atribute +Relaii +Supertipuri/Subtipuri

+Obiecte asociative Coad i Yourdon spun c i n acest caz se poate vorbi despre existena a dou strategii. Strategia veche se bazeaz pe conceperea listei atributelor gruparea lor n obiecte, stabilirea de relaii ntre ,,ocurene (cazuri), folosirea supertipurilor/subtipurilor pentru extragerea atributelor comune i definirea obiectelor asociative pentru reliefarea relaiilor sigure. Noua strategie este destul de apropiat de precedenta, cu excepia primului pas, care i propune mai nti s identifice obiectele lumii reale i apoi urmeaz descrierea lor cu ajutorul atributelor. Specialitii apreciaz salturile nregistrate, ns , n acelai timp fac inventarul conceptelor inexistente, cum ar fi: servicii,motenire,structur. Metode orientate-obiect ntruct acest subiect necesit multe descrieri preliminare, deocamdat nu vom face dect o foarte sumar prezentare. Sintagma ,,orientat - obiect este destul de greu de definit din cauza accepiunilor diferite ce i-au fost date de diversele discipline. Numai n domeniul informaticii exist vreo trei variante: una folosit n modelarea informaiilor , alta n programare i a treia, cea de fa, utilizat n analiza i proiectarea sistemelor, de cele mai multe ori identic semnificaiei din programare. Fiind un domeniu relativ nou, este normal s existe o mare diversitate de opinii pn i asupra termenului ,,obiect. Pentru a continua regula prezentrii ecuaiei ce caracterizeaz metoda, o vom reda n cele ce urmeaz: Orientat-Obiect = Clase i Obiecte + Motenire + Comunicaii prin mesaje. Conceptele de obiect i clas sunt independente: un obiect aparine unei clase (este o instan a clasei), iar o clas este o grupare logic a obiectelor care au aceeai structur i un comportament similar. Un obiect este o abstractizare a datelor elementare i poate fi descris astfel: Obiect = Identitate + Comportament + Stare. Identitatea obiectului se realizeaz printr-un identificator al obiectului, care este un atribut invariabil ce permite ca obiectul s fie referit independente de celelalte obiecte. Identificatorul este generat de sistem la crearea obiectului. Starea obiectului este o valoare care poate fi simpl (de exemplu, un literal) sau structur(de exemplu, o list). n ultimul caz, ea poate fi compus din valori simple, referine la alte obiecte sau valori care sunt structurate ele nsele.

Comportamentul unui obiect este definit printr-un set de operaiuni ce-i pot fi aplicate i este descris n clasa creia i aparine obiectul. n concluzie, obiectul este o abstractizare a datelor elementare, caracterizat printr-un identificator unic, invariabil, o clas creia i aparine i o stare reprezentat printr-o valoare simpl sau structur. 2.2MODELE ALE CICLULUI DE VIA A SISTEMULUI INFORMATIC Mutaiile din domeniul tehnologiilor informaionale i al metodelor de abordare a sistemelor s-au reflectat i n ciclul de via al dezvoltrii sistemelor, fie prin schimbrile etapelor acestuia, fie prin modificarea ordinii de parcurgere a lor. Indiferent de numele i de numrul etapelor ciclului de via al dezvoltrii sistemelor, o problem mult mai important este aceea a ordinii i felului cum se parcurg etapele respective, ceea ce n literatura de specialitate se trateaz sub numele de modele ale ciclului de viaa a sistemului informatic. n practic se regsesc urmtoarele tipuri de modele: model cascad; model V; model incremental; model spiral; model evolutiv; model tridimensional; model X; model fntn artezian; model pinball; model minge de baseball; model piramid. Modelul cascad este unul de referin asigurnd trecerea de la o etap la alta n ordinea secvenial a posibilitii revenirii la etapele anterioare sau parcurgerii n paralel a mai multor etape. (Fig 2.1)

Definirea cerinelor

Analiz

Proiectare Implementare Testare Utilizare i ntreinere

10

Fig.2.1 Utilizare i ntreinere Avantaje: controleaz toate fazele n sensul ca ele au o ordine strict i aria lor de ntindere e clar; modelul este uor de nsuit de membrii echipei de proiectare; fiecare etap este nsoit de documentaie. Dezavantaje: sistemul informatic se pred dup parcurgerea tuturor etapelor ceea ce nseamn un interval mare de timp, n care preteniile utilizatorului se pot schimba; modelul nu corespunde unei abordri dinamice; nu este deschis schimbrilor. Modelul V este o variant a celui cascad prin care se introduc conceptele de componente, subsisteme, aplicndu-se teste explicite la nivel ierarhic pentru creterea controlului asupra modului n care se desfoar etapele, obinnd n felul acesta o latur a literei V. (Fig 2.2) Prima latur se parcurge descendent i conine etapele propriu-zise ale unui sistem informatic, iar a II-a se parcurge ascendent i cuprinde toate etapele de verificare i validare.
Definirea Validare

Proiectare sisteme

Testare sisteme

Proiectare subsistemelor (componente)

Testare subsisteme

Fig 2.2

Codificare/Asamblare componente

Modelul incremental este o alt form a modelului cascad: pn la etapa de proiectare 11

nu exist diferene. Dup aceea se efectueaz descompunerea proiectului n subproiecte. Fa de modelul V, ofer posibilitatea atingerii scopului final n dou variante: sistemul global livrat la sfrit sau componente livrate distinct. Avantaje: perioade de realizare scurte pentru c livrarea se face pe componente; lucrul n echip ofer posibilitate de realizare a mai multor proiecte. Dezavantaje: imposibilitatea aplicrii modelului n orice condiii, uneori neexistnd posibilitatea descompunerii n componente; costurile de asamblare sunt mult mai mari prin realizarea testelor multiple. Modelul spiral (Fig 2.3 se bazeaz pe dou convingeri: natura iterativ a dezvoltrii i nevoia de planificare i evaluare a riscurilor fiecrei iteraii. deficiena nregistrrilor la modelul V n care validarea se efectueaz prea trziu.

Prototip Prototip Prototip Fig 2.3 Avantaje: posibilitatea evalurii riscurilor n diferite momente ale proiectului; simplificarea etapei de evaluare n ceea ce este necesar n etapa (prototipul) urmtoare, inclusiv prin prisma costurilor. Dezavantaje: echipa de realizare trebuie s aib un nalt nivel de profesionalism; 12 Prototip

flexibilitate n aciune. Modelul evolutiv const n descompunerea proiectului n pri, fiecare cu o valoare deosebit pentru client. Aceste pri sunt realizate i livrate n mod iterativ i contribuie la sporirea performanelor sistemului. (Fig 2.4 Prile obinute pentru completare nu sunt foarte detaliate tocmai n vederea adaptrilor i modificrilor ulterioare. Oricare din aceste segmente luate n studiu trece prin toate etapele de dezvoltare a sistemului. Reuita modelului const n crearea unei arhitecturi deschise elaborrii prin participarea tuturor utilizatorilor. Studiul iniial Descompune re n

Segment 1
Def. cerine Implementare Analiz Testare Proiectare Utilizare

Segment n
Def. cerine Implementare Analiz Testare Proiectare Utilizare

Fig 2.4 Modelul 3D red dezvoltarea sistemului printr-o reprezentare grafic n spaiu. Pe o ax avem ciclul de via al sistemului (CVS), pe a IIa ciclul de via al proiectului (CVP) i pe ultima ciclul abstractizrii (CA). Ciclul de via al sistemului principalele perioade dup care se fac schimbri majore, creterea volumului de date, modificri tehnologice, modificri structurale. Modelul X i propune s extind performanele obinute prin modelul cascad i prin modelul V. Acesta introduce noiunea de model al livrrii, fiecare proces sau etap a dezvoltrii sistemelor poate fi privit i urmrit ca o iteraie sau evoluie spre soluia acceptat. Modelele livrrii sunt independente. Din punct de vedere tehnic. Acest lucru a fcut posibil exprimarea n partea superioar a X-lui a responsabilitilor softului curent i n cea inferioar a componentelor fizice ale softului. Modelul X exprim dou categorii de cicluri de activitate: una derulant nainte care sintetizeaz sistemul nou i una napoi pentru dobndirea sistemului i a componentelor sale pentru o posibil reutilizare. Modelul fntn artezian i are originea n cel cascad, dar reprezint o variant mbuntit n sensul c perioada de timp pentru finalizare e mai scurt i componentele sale pot fi reutilizate n modele similare. 13

Modelul pinball const n deplasarea aleatoare a unei bile n mediul orientat obiect redat sugestiv sub forma unui teren de pinball. Modelul minge de baseball (Fig 2.5) sau dezvoltare concurent: principiul lui este acela al proiectrii n paralel a activitilor: analiz orientat obiect, proiectare i programare orientat obiect. Pentru ca modelul s dea rezultate echipa trebuie s fie format din experi n domeniul analizei, administrrii datelor, cel al interaciunii umane i medii i limbaje de programare.

00

00

00P Fig 2.5 Modelul piramid (Fig 2.6) se aplic n exclusivitate mediilor orientate obiect. Arat c etapele unui ciclu de via nseamn trecerea spre mai multe detalii, pornindu-se de la nivelul superior al planificrii spre analiza domeniului, proiectarea i construirea lui.
Planificarea ntreprinderii Analiza domeniului ntreprinderii

Proiectare sistem

Construcia componentelor obiectului

Fig. 2.6

14

2.3 METODE I TEHNICI DE REALIZARE A SISTEMELOR INFORMATICE Metodele utilizate n proiectarea sistemelor informatice reprezint modul unitar sau maniera n care analitii de sistem, programatorii realizeaz procesul de analiz a sistemului informaional - decizional existent, proiectarea i introducerea sistemului informatic. Metoda are un caracter general, n cadrul ei aplicndu-se anumite tehnici de lucru. Tehnicile de lucru utilizate n proiectarea sistemelor informatice reprezint felul n care se acioneaz eficient i rapid, n cadrul unei metode, pentru soluionarea diferitelor probleme ce apar n procesul de proiectare. n activitatea de realizare a sistemelor informatice unele dintre metode i tehnici sunt specifice activitii de analiz, proiectare sau programare,altele sunt generale i pot fi utilizate n toate etapele de realizare a sistemelor informatice. Dintre metodele i tehnicile utilizate n realizarea sistemelor informatice enumerm: Metoda descendent (Top-Down); Metoda ascendent (Bottom-Up); Metoda LCS/LCP (Logical Construction of System / Programs) Tehnica concordanei intrri-ieiri Tehnica HIPO; Metoda descendent (Top-Down) Metoda const n descompunerea unui sistem complex pe niveluri ierarhice, succesiv, pn la module elementare, simple i relativ independente care sunt controlate de module coordonatoare. Metoda are ca cerin de aplicare modularizarea sistemului, obiectivul principal fiind realizarea modularizrii de sus n jos, rezultnd i obiectivele specifice: crearea posibilitii de realizare n paralel a componentelor sistemului informatic i eliminarea din sistem a redundanelor. Rezultatul realizrii modularizrii este modulul. Modulul terminal este cel care nu mai poate fi descompus. Orice modul se poate integra cu un alt modul formnd noi module i poate fi integrat mediului din care provine. Procesul de descompunere se repet pn cnd toate modulele sunt considerate terminale. Descompunerea are la baz urmtoarele reguli: Nivelul zero de descompunere sau punctul iniial de pornire l reprezint modul neterminal sau coordonator; Pentru toate modulele neterminate ale unui nivel se aplic descompuneri succesive n pai de sus n jos; Descompunerea este terminat cnd modulele ultimului nivel sunt terminale. Aceast metod prezint avantajul c ofer n orice moment o imagine de ansamblu asupra problemei de rezolvat i nu este necesar cunoaterea apriorii a domeniului problemei, aceasta realizndu-se pe parcurs.

15

Prezint dezavantajul unei analize complexe, laborioase, care antreneaz un personal numeros i conduce la prelungirea timpului de realizare a sistemului iar strecurarea unor erori sau imprecizii n definirea structurii i a relaiilor dintre componentele sistemului afectnd activitatea pn n momentul respectiv.

Metoda ascendent (Bottom-Up) Metoda const n agregarea modulelor de jos n sus punnd n eviden legturile dintre ele pn se ajunge la un singur modul. Modularea i abordarea sistemic sunt conceptele care stau la baza acestei metode, aceleai ca la metoda de abordare descendent. Regulile care stau la baza metodei sunt: Nivelul de agregare iniial este nivelul la care se afl modulele terminale; Agregarea se face succesiv de jos n sus; Cnd se obine un nivel de agregare se realizeaz integrarea modulelor de nivel inferior n module de nivel superior; Agregarea este terminat cnd la un nivel de agregare se obine un singur modul. Avantajul folosirii acestei metode ar fi acela c sistemul informatic se dezvolt treptat, n corelaie cu cerinele beneficiarului. Beneficiarul beneficiaz de rezultatele prelucrrii automate a datelor mai repede, se familiarizeaz cu noul sistem gradat. Se reduce riscul realizrii unui sistem neoperaional n momentul punerii n aplicaie. Dezavantajul acestei metode rezult din gradul de integrare redus al modulelor datorit lipsei unei concepii iniiale de ansamblu, ceea ce face necesar reproiectarea unor componente. Metoda LCS/LCP (Logical Construction of System / Programs) Aceast metod este cunoscut i sub denumirea de metoda Warnier sau Legi de concepere/construire a sistemelor/programelor, aceast metod are la baz un ansamblu de principii de structurare a modulelor n funcie de structura datelor de ieire. Ea permite specificarea condiiei de executare i a numrului de efecturi ale procedurilor care sunt structurate pn la nivelul elementar. Tehnica concordanei intrri-ieiri este o tehnic ce se utilizeaz att la analiz, ct i la proiectare. Plecnd de la informaiile necesare fundamentrii deciziilor se determin mulimea informaiilor primare ale sistemului respectiv. Pe baza sistemului de decizii identificat se determin n continuare informaiile de ieire din sistemul informaional, necesare fundamentrii acestor decizii. Aceast metod de determinare a informaiilor de intrare pe baza celor de ieire este util n cazul sistemelor complexe, cu multe informaii. Abordarea analizei poate fi fcut i plecnd de la intrri i ajungnd la ieirile sistemului 16

informaional. Metoda prezint dezavantajul c nu este posibil punerea n eviden a tuturor legturilor dintre datele primare existente n sistem. Tehnica HIPO este conceput pentru abordarea ierarhizat a sistemului informaional urmrind descrierea fluxului INTRRI PRELUCRRI IEIRI. Aceast tehnic se concretizeaz n elaborarea unei documentaii care este alctuit din: HIPO general; HIPO de detaliu; HIPO de ntreinere. HIPO general prezint structura funcional a sistemului i st la baza proiectrii i a comunicrii n cadrul echipei de proiectare a sistemului. HIPO de detaliu prezint o descriere general i de detaliu a structurii tuturor fiierelor/entitilor/relaiilor folosite. HIPO de ntreinere prezint documentaia corectat i completat dup testarea i implementarea sistemului informatic. Fiecare documentaie n parte trebuie s conin: Tabela de coninut care conine structura funcional ierarhic cu legturi ntre componente. Descompunerea ierarhic trebuie s respecte concepia de baz a acestei tehnici (INTRRI PRELUCRRI IEIRI) i s permit asocierea, pentru fiecare nivel descompus, a cel puin o diagram general. Diagrama general prezint funciile importante ale sistemului coninnd reprezentarea grafic a fluxului INTRRI PRELUCRRI IEIRI cu detalierea acestor funcii. Diagrama de detaliu prezint descrierea analitic a fiecrei funcii majore din diagrama general, prin descompunerea acestora pn la ultimul nivel de obinere a tuturor informaiilor privind fluxurile INTRRI PRELUCRRI IEIRI i ultimele relaii de flux de pe ultimul nivel de detaliere. 2.4 ELABORAREA PLANULUI DE REALIZARE A SISTEMELOR INFORMATICE Organizarea i conducerea proiectelor (managementul proiectelor) Organizarea i conducerea proiectelor, cunoscut n literatura de specialitate sub titulatura de Managementul proiectelor (n limba englez Project Management), se ocup de planificarea, coordonarea i controlul activitilor complexe i diverse din cadrul proiectelor. Majoritatea proiectelor au o caracteristic comun, i anume, prezena n pregtirea i realizarea lor a elementelor de risc i incertitudine. Funcia acestei tehnici este de a prognoza ct mai multe obstacole i probleme ce pot aprea i de a planifica, organiza i controla activitile astfel nct proiectul s fie realizat cu succes n ciuda tuturor riscurilor. Scopul managerului proiectelor este de a contribui la realizarea proiectelor n perioada de timp stabilit i la ncadrarea resurselor folosite n bugetul stabilit iniial.

17

Managerul de proiect Planificarea i coordonarea ntregii activiti privind realizarea proiectului informatic revine managerului de proiect. Acesta reprezint persoana cea mai autorizat s decid care este cea mai bun strategie pentru realizarea proiectului, care este cea mai bun organizare a echipei, prin poziionarea membrilor acesteia n posturile adecvate pentru a-i indeplini sarcinile ct mai bine i mai eficient. Pentru dobndirea unui ct mai mare succes, managerul de proiect trebuie s dea dovad de o serie de caliti deosebite. Calitatea primordial a managerului trebuie s fie abilitatea de a motiva oamenii cu care lucreaz, indiferent de mijloacele folosite pentru a realiza acest deziderat. Personalul care particip la proiect va aprecia managerul care dovedeste competen, ia decizii clare, d instruciuni clare, tie s asculte i accept sfaturile bune, care este entuziast i ncreztor, care impune respectul celorlalti prin propriul exemplu de conduit. Rolul managerului este s planifice, s organizeze, s coordoneze, s controleze i s conduc. Aceste sarcini pot fi grupate n cinci categorii, evideniate n figura 2.12
Analiza cost-beneficiu Prezentare rapoarte Planificare timp Planificare resurse Inregistrare actiuni
Managerul proiectului

Evaluare economica

Planificare

Controlul progreselor

Control realizari Raportare progrese Selectie si pregatire Conducere si coordonare

Conducere personal

Planificare cu implicarea clientilor Relatii cu clientii Raportare progrese Rezolvare probleme curente FIGURA 2.12 SARCINILE MANAGERULUI DE PROIECT

Se are n atenie modelarea noului sistem n aa fel nct acesta s satisfac cerinele utilizatorilor. Aceasta nseamn nu numai livrarea proiectului n stare de funcionare, la timp, cu costuri minime, dar mai ales ca acesta s satisfac preteniile pentru care a fost creat i care l 18

vor folosi n viitor. De aceea se va pune mare accent pe importana implicrii utilizatorilor n timpul studiului, analizei, proiectrii i implementrii sistemului informatic, precum i pe ncurajarea participrii n realizarea efectiv a acestuia prin idei furnizate conductorului de proiect. Planificarea proiectelor informatice Planificarea are drept scop ndeplinirera obiectivelor proiectelor, obiective precizate mai jos: Performan i calitate. Rezultatul final trebuie s corespunda scopului. n acest sens, standardele de calitate joac un rol important. ncadrarea n bugetul alocat. Nencadrarea n buget poate conduce la reduceri ale profitului i la rate de eficien mai scazut ale investiiei. ncadrarea n durata de realizare. Trebuie urmrit ca toate etapele proiectului s se ncheie la momentul prevzut, pentru a permite ncheierea proiectului la sau naintea datei prestabilite. Dac se depete durata de realizare pot aprea dou aspecte negative: se depete, cu mare probabilitate bugetul alocat i se afecteaz planificarea resurselor pentru urmtoarele proiecte. Obiectivele sunt corelate ntre ele ca n fig. 2.12 Performana

Cost

Timp (durata)

Figura 2.12 Triunghiul obiectivelor proiectelor Triunghiul arat corelatia dintre cele trei obiective. n unele situaii, anumite prioriti pot face ca unul sau altul din aceste obiective s capete o importan mai mare dect celelalte. Principalii pai n planificarea proiectelor n tabelul 2.13 se prezint aceti pai i metodele de realizare a lor Tabelul 2.13 Pasul 1. Definirea obiectivelor tehnice: financiare de programare n timp Metoda de realizare Studiu de fezabilitate avnd ca rezultat o specificaie tehnic Estimarea costurilor pentru soluia tehnic propus, avnd ca rezultat un buget al proiectului Evidenierea derulrii programului

19

pe o diagram. Duratele activitilor se pot determina din experiena unor proiecte trecute 2.Impartirea proiectului Pregatirea listei activitilor n pri ce pot fi necesare i a departamentelor sau organizate i conduse organizaiilor responsabile 3. Decizia, la nivel de Folosirea diagramelor tip bara detaliu, privind ceea ce pentru proiectele simple sau a trebuie fcut i n ce analizelor tip reea pentru succesiune proiectele capitale sau complexe 4. Estimarea duratelor Considerarea timpului necesar fiecrei activiti derulrii unei anumite activiti. Nu se iau n considerare resursele, la nivelul acestui pas 5. Utilizarea duratelor activitilor pentru estimarea duratei proiectului i a importanei fiecrei activiti pentru obiectivele proiectului legate de timp Utilizarea diagramelor tip bar pentru proiectele simple i a analizelor tip reea pentru proiectele complexe. Dac rezultatele nu sunt acceptabile, se pot face modificri n estimri sau n obiectivele legate de durate.

6. Punerea de acord a Alocarea resurselor avnd n programului cu vedere diagramele tip bar, pentru resursele ce pot fi proiectele mici, i analizele tip procurate reea pentru proiectele capitale sau complexe.

7. Atribuirea sarcinilor Este necesar cunoaterea participanilor la proiect individual a fiecrui participant la proiect din punct de vedere al competenei tehnice, al vitezei de lucru, al calitii muncii pe care o depune i al altor caliti speciale Desfurarea n timp a proiectului Pentru ca managementul unui proiect s fie ct mai eficient, elementele planului de

20

realizare a proiectului trebuie estimate ct mai corect i aranjate ntr-o secven logic de derulare ct mai coerent i logic. n prima faz se procedeaz la inventarierea i ntocmirea listei de activiti care trebuie executate. Lista de activiti trebuie s fie ct mai cuprinztoare i pentru elaborarea ei se poate recurge la o sesiune de braistorming cu ali conductori de proiecte i cu conducerea firmei beneficiare. Cu aceast ocazie se va urmri n mod deosebit menionarea activitilor, nu i succesiunea acestora. n faza urmtoare, activitile inventariate vor fi descompuse n subactiviti stabilind succesiunea logic a lor i apoi planificate n timp. Pe baza normativelor existente, dar mai ales a experienei acumulate, se trece la stabilirea duratei activitilor din list. Durata fiecrei activiti depinde de etapa de realizare n care ne gsim. Unitatea de exprimare a duratei este, de regul, ziua sau sptmna i este recomandat ca durata unei activiti s fie multiplu de acea unitate. n cazul proiectelor foarte simple, este posibil ca durata acestora sa fie egal cu suma duratelor activitilor componente. Aceasta se poate ntmpla cnd o singur persoan se ocupa de analiz, proiectare, programare i implementare. Situaia normal ns este cnd lucreaz o echip format din mai multe persoane i fiecare are cte o sarcin distinct. Durata general depinde de intercondiionrile dintre aceste sarcini i de ordinea n care sunt realizate. Numrul de activiti care se pot realiza n paralel depinde de numrul de membri care sunt n echip i de faza n care se gsete proiectul. Dup estimarea duratei activitilor, lista activitilor se poate completa cu duratele corespunztoare i apoi se face cunoscut tuturor membrilor echipei astfel nct distribuirea sarcinilor s fie pe ct posibil echitabil. Pentru planificarea n timp a proiectului se utilizeaz mai multe metode, tehnici i instrumente, avnd un caracter general de aplicabilitate, nu numai pentru proiectele informatice. Cele mai utilizate sunt diagramele tip bar derivate din mai cunoscutele diagrame Gantt, numite astfel dupa inginerul american Henry Gantt(1861-1919) sau analizele tip retea. A. Diagrame Gantt (tip bar) Diagramele de planificare tip bar sunt uor de realizat i interpretat i, de asemenea, se adapteaz uor la diversele cerine de planificare. Limitrile acestuia sunt legate de numrul de activiti care pot fi desenate fizic pe o foaie de hrtie i de numrul de interaciuni i dependene ntre aceste activiti. Fiecare activitate este reprezentat de o linie proporional cu durata ei. Odat ce au fost listate toate activitile i reprezentate duratele lor prin linii proporionale se poate vedea durata total a proiectului sau a unei faze a acestuia. O limitare important a acestor diagrame const n dificultatea de a aloca resurse activitilor cu meninerea interdependentelor i fr suprancarcarea personalului.

21

Atunci cnd proiectele sunt foarte mari i necesit replanificri de operatii, se reprezint doar activitile de nalt nivel i separat se fac diagrame pentru descompunerea fiecarei activiti de nivel inalt. n figura 2.14 se prezint graful Gantt pentru un proiect de realizare a unui sistem informatic. Datorit numrului mare de activiti i a dependenelor dintre acestea, s-a recurs numai la reprezentarea activitilor de nalt nivel.
Septembrie 2005

Proiectarea sistemelor informatice

Aprilie 2005

Mai 2005

Iunie 2005

Iulie 2005

August 2005

1. Investigarea activitilor 2. Determinarea cerinelor 3. Modelarea datelor i 4. Proiectarea logic 5. Proiectarea fizic 6. Implementarea

Nume activitate

Fig. 2.14 Graful Gantt Analize tip reea Aceste metode de planificare a timpului permit punerea n eviden a interdependenelor dintre diferitele operaii n cadrul proiectelor complexe. Cele mai cunoscute metode sunt:

7. Livrarea sistemului

22

B1 analiza drumului critic (DC); B2 programul de evaluare i revizuire tehnic (PERT Programme Evaluation and Review Tehnique, n limba engleza). Utilizarea lor pe scar larg a aprut n anii 50, la acea vreme fiind utilizate cu succes n proiectele de aprare ale forelor armate ale S.U.A. n general, pentru realizarea acestor reele se folosesc dou grupe de sisteme de notare i reprezentare. o Sistemul activitatilor notate pe sgei (Figura2.15). Sistemul se foloseste pentru ambele metode (DC i PERT). activitate

Figura 2.15 Sistemul activitilor notate pe sgei 1 i 2 sunt dou evenimente din cadrul proiectului Pe sgeat se trece activitatea(operaia) necesar a se derula pentru a trece de la evenimentul 1 la 2. o Sistemul activitilor notate n noduri. n continuare, pentru exemplificare, vom folosi primul sistem de reprezentare.

B1. Analiza drumului critic (DC) Const din realizarea unei diagrame tip reea. Deosebiri fa de diagramele tip bar: nu sunt proiectate pentru a oferi orizontul de timp; doresc s ofere informaii clare asupra relaiei i interdependenei fiecrei activiti cu celelalte activiti ale proiectului. Figura 2.16 prezint cea mai simpl diagram tip reea. Fiecare cerc reprezint un eveniment n cadrul proiectului. Sgeata care leag evenimentele 4 i 5 reprezint activitatea care trebuie s aib loc nainte ca evenimentul 5 s se declare ca fiind realizat.

1 2 4 5

3 Figura 2.16 Diagrama tip reea 23

Diagrama din figura 2.16 arat, de asemenea, c activitatea ce conduce la evenimentul 5 nu poate ncepe pn ce toate activitile ce preced evenimentul 4 nu au fost realizate. Deasupra sgeilor se poate scrie i durata activitii respective. n figura 2.17 se prezint activitile i evenimentele unui proiect mai complex. n acest exemplu exist mai multe posibiliti de realizare a proiectului (evenimentul 6), fapt uzual n majoritatea proiectelor. Avem trei ci posibile de realizare a proiectului, unele dintre ele trecnd printr-o activitate fictiv, 4 3. Activitile fictive nu reprezint o operaie efectiv i au ntotdeauna durata 0. Ele reprezint o restricie sau o linie de dependen dintre diferite activiti. 1 1 2 3 2 5 3 5

1 0 1 0 5

4 9 6 2 9

5 4 5

6 5 7

Figura 2.17 Drumul critic n exemplul nostru, nceputul activitii 3 6 depinde att de realizarea activitii 2 3, ct i de realizarea activitii 1 4. Altfel spus, activitatea 3 6 nu poate ncepe pn nu au avut loc evenimentele 3 i 4. Deasupra sgeilor reprezentnd activitile, s-au trecut i duratele lor de realizare, estimate n zile. Durata proiectului reprezint suma duratelor activitilor pentru fiecare din cele trei drumuri posibile i depinde de drumul ales. Evenimentul 3 poate avea loc cel mai devreme dup 3 zile (1+2=3), dac se consider drumul 1 2 3. Dar ncheierea evenimentului 3 nu poate avea loc nainte de ziua a 5-a datorit drumului mai lung ce trece i prin activitatea fictiv 4 3. Prin nsumarea, de la stnga la dreapta, a duratelor activitilor precedente, pe drumul cel mai lung, se determin durata minim de realizare a fiecrui eveniment (notat deasupra fiecrui cerc reprezentnd un eveniment). Urmnd aceast procedur n reeaua noastra, rezult c durata minim de realizare a proiectului este de 9 zile. S considerm drumul ce trece prin evenimentul 5. Durata cea mai scurt de realizare a lui este ziua a 6-a, cu trei zile nainte de cea mai scurt durat de ncheiere a proiectului. Este

24

evident c nceputul activitii 5 6 se poate amna cu o zi, ea durnd dou zile, fr a se mri durata de realizare a proiectului. Rezult c realizarea evenimentului 5 poate avea loc cel mai devreme n ziua a 6-a i cel mai trziu n ziua a 7-a. Acest lucru este indicat n figura 2.17 prin scrierea sub cercul evenimentului a datei celei mai trzii de realizare a sa. Acest rezultat se poate obine i prin scderea perioadelor de realizare a evenimentelor pornind de la dreapta spre stnga. Concluzia este c, pornind de la dreapta spre stnga n reeaua noastr de evenimente i activiti, putem obine cel mai trziu moment la care trebuie realizate diferite evenimente. Pentru activitatea care ne conduce de la evenimentul 5 la 6 avem: durata: 2 zile; cea mai devreme dat pentru ncepere: ziua a 6-a; cel mai devreme posibil sfrit: ziua a 8-a (6+2); cel mai trziu posibil sfrit: ziua a 9-a; marja de timp posibil: 1 zi. n momentul n care pe diagram au fost indicate duratele cele mai mici i cele mai mari pentru realizarea unui eveniment, se poate gsi cel puin un lan de evenimente pentru care durata de realizare cea mai scurt corespunde cu durata de realizare cea mai lung a proiectului. Acest drum cu marja de timp zero, legnd aceste evenimente, se numete drum critic i este reprezentat cu sgei ngroate n figura 2.17. Evenimentele prin care trece drumul critic se numesc evenimente critice. Chiar dac toate activitile sunt importante, activitilor critice trebuie s li se acorde prioritate n ceea ce privete alocarea resurselor i atenia managerilor. B2. Metoda PERT Metoda PERT este similar metodei DC. Reeaua de evenimente i activiti se construiete identic. Diferena apare atunci cnd se ia n considerare factorul timp. Metoda PERT ia n considerare trei durate pentru fiecare activitate: durata optimist; durata cea mai probabil; durata pesimist. Cu ajutorul acestora se determin o valoare ateptat pentru durata de realizare a fiecarei activiti. Metoda PERT ofer o durat de realizare a proiectului i o probabilitate de atingere a acestuia. Planificarea resurselor Analizele utilizate pentru planificarea timpului nu pot pune n eviden i volumul resurselor necesare la un moment dat pentru derularea proiectului. n general exist ase categorii de resurse care trebuie evaluate i planificate de ctre 25

managerul de proiect, i anume: resursele umane; echipamentele i materialele; serviciile; transportul; instalaiile necesare pentru realizarea proiectului; resursele financiare. Unele proiecte pot necesita numai o parte din aceste resurse, altele pot necesita toate cele ase categorii de resurse .a.m.d. Resursele umane, echipamentele i materialele sunt de mare importan pentru performanele oricui proiect. 3. Planificarea resurselor umane Din acest punct de vedere, sunt de interes aspectele referitoare la categoria, numrul i organizarea oamenilor, elaboreaza grafice de personal (figura 2.18). n aceste grafice se reprezint necesarul de personal n funcie de timp, pentru o anumit activitate.
Numr de persoane Numr mediu de persoane

Timp

Figura 2.18 Grafice teoretice de personal Graficul, de exemplu de form trapezoidal n mod teoretic, se poate realiza estimnd necesarul de personal pentru fiecare zi i aa mai departe, pn la sfritul activitii respective. Prin mprirea numrului total de ore necesare pentru lucru la durata lucrtoare, se poate obine numrul mediu de persoane. n practic, graficele de personal pot avea alura unui clopot, a unei curbe n forma literei s etc., n funcie de categoria de personal avut n vedere. O metod convenabil de extindere a personalului necesar pentru un proiect este consultarea unor subcontractani sau consultani. Aceast soluie este deseori folosit n practic. Se mai utilizeaz soluia de a angaja persoane numai pentru acel proiect. a) Planificarea resurselor materiale Elementul de baz al acestei planificri este planul de achiziii al proiectului. Printre datele eseniale pentru elaborarea acestui plan amintim: sondaje asupra situaiei pieei, trenduri privind preurile, disponibilitatea materialelor. Planificarea serviciilor i a unor sisteme de control (al derulrii n timp a costurilor 26

proiectului etc.) este indispensabil n cazul achiziiei de calculatoare i a softului necesar. Serviciile pot implica pregtirea spaiilor unde va lucra echipa de proiectare sau instalaiile necesare pentru amplasamentul proiectului. b) Planificarea resurselor financiare Managerul de proiect are autoritatea de a aproba toate cheltuielile necesare pentru realizarea proiectului. Planificarea greit a resurselor financiare poate stopa execuia noului sistem informatic. Planificarea riguroas i profund a resurselor constituie baza a tot ceea ce urmeaz n derularea unui proiect. Managerul de proiect trebuie s se pregteasc asiduu pentru a putea planifica toate aspectele proiectului i activitile de zi cu zi aferente. Controlul proiectelor Prin controlul proiectelor trebuie s se urmreasc progresele realizate n dezvoltarea proiectelor, n raport de obiectivele stabilite. Trebuie s ne asigurm c proiectul va fi finalizat la data prevzut n contract, c se ncadreaz n bugetul specificat i c furnizeaz ce s-a stabilit, la o calitate ridicat. Controlul const din dou pri: urmrirea; luarea msurilor. Urmrirea proiectelor Este cunoscut faptul c niciodat lucrurile nu evolueaz aa cum sunt planificate. Factorii care produc modificri n derularea proiectelor pot fi urmtorii: estimrile fcute la planificarea proiectului pot fi greite; cerinele se pot schimba; termenul final se poate schimba (de obicei, mutndu-se mai devreme); bugetul se poate micora; prioritatea proiectului se poate schimba; rezistena la schimbri; greelile oamenilor. Gradul de complexitate a proiectelor sunt factori care determin metoda de control i raportare. Din acest punct de vedere distingem mai multe situaii posibile: proiecte simple, proiecte de dimensiune medie i proiecte complexe 3. ANALIZA SISTEMELOR INFORMATICE 3.1 PRINCIPALELE ETAPE ALE ACTIVITII DE ANALIZ Complexitatea i multitudinea sistemelor informatice impune efectuarea unor analize prin care se determin principalele disfuncionaliti informaionale i consecinele lor manageriale, economice i umane.

27

Concomitent se evideniaz i aspectele pozitive ale sistemului informaional curent i se evalueaz problemele pe care trebuie s le rezolve viitorul sistem. n analiza sistemului informaional trebuie s regsim aspectele: aria de ntinderea a sistemului informaional care va deveni sistemul obiect pentru conceperea i realizarea unui sistem informatic; reflectarea activitilor i operaiilor economice specifice sistemului informaional; surprinderea modificrilor ce se impun n organizarea i funcionarea unui sistem informatic; fundamentarea unei soluii de principiu care s precizeze activitatea i operaiile ce urmeaz a fi informatizate, costul antecalculat al sistemului. Etapa de analiz trebuie s urmreasc: Identificarea problemelor de soluionat i determinarea cerinelor sistemului; Structurarea cerinelor noului sistem; Evaluarea sistemelor informatice; Generarea i alegerea variantelor de proiectare. 3.2 IDENTIFICAREA PROBLEMELOR DE SOLUIONAT I DETERMINAREA CERINELOR Identificarea problemelor de soluionat ncepe cu activitatea de culegerea i nregistrarea de date i informaii referitoare la componentele sistemului informaional. La analiza i interpretarea acestora au n vedere c fiecare din componentele sistemului informaional au anumite caracteristici: datele se caracterizeaz, n principal, prin: o forma de reprezentare letric sau cifric; o natura domeniului la care se refer (fenomene, procese, rezultate, aciuni). informaiile sunt valoroase i utile cnd li se cunoate: o proveniena; o destinaia; o frecvena de generare i utilizare; o direcia vehiculrii; o gradul de prelucrare; o natura proceselor reflectate. circuitele informaionale sunt condiionate de: o scopul informaiei (documentare n vederea fundamentrii unei decizii, avertizri asupra modificrii unei anumite stri, sau sunt date istorice); o poziia n structura i natura relaiilor dintre factorii emitori i receptori (ascendente sau descendente, relaii funcionale sau relaii de reprezentare); o viteza de prelucrare a informaiilor i capacitatea canalelor de comunicaie (echipamente de prelucrare, resurse umane); o structura organizatoric a sistemului de conducere. 28

fluxul informaional caracterizat prin: o configuraia i lungimea traseului informaional; o prin viteza de deplasare a informaiilor; o prin volumul informaional; o Calitate; o Fiabilitate; o cost. proceduri informaionale tratate prin aspectele: o suporii tehnici utilizai; o succesiunea operaiilor tratate; o metode i procedee de culegere, nregistrare, transmitere i prelucrare a informaiei; o complexitatea operaiilor implicate; o formalizarea atributelor. mijloacele de tratare a informaiilor abordate ca sistem tehnic al sistemului informaional sunt caracterizate prin: o costuri; o tipuri sau categorii; o performane tehnico funcionale; o numr; o structur. Pentru identificarea problemelor de soluionat este necesar un studiu al sistemului existent i care se realizeaz prin: A. Definirea caracteristicilor generale ale unitii: Profilul i obiectivele organizaiei; Locul ocupat n sfera serviciilor i sfera produciei; Specificul activitii de baz; Principalii indicatori economici i evoluia lor; Proiecte de modernizare, dezvoltare; Structura organizatoric. Exemplu: Denumire: S.C. DAEWOO AUTOMOBILE ROMANIA S.A. Domeniu de activitate: Producerea i comercializarea de autoturisme i accesorii pentru acestea, prestarea unor servicii i acordarea de asisten tehnic de specialitate. Sediul central: Craiova, strada Caracal km 3 Forma juridic: Societate mixt pe aciuni Gama de produse oferite: autoturisme Relaii cu furnizorii: Prin specificul produselor i fabricaiei, firma ntreine excelente relaii de colaborare cu peste 300 de furnizori interni i externi, selectai dup criterii deosebit de exigente. 29

Structura organizatoric este prezentat n fig. 3.1 PREEDINTE VICEPREEDINTE Oficiul

Director economic Director comercial

Director vnzri

Director producie

Director centru de calcul Vnzri Financiar Contabilitate Depozit Aprovizionare

Director personal Sector tehnic

Salarizare Reclamaii clieni

Sector fabricaie Administrativ

Fig. 3.1 B. Identificarea activitilor desfurate Documentele de baz pot fi: Regulamentul de organizarea funcional (ROF); Regulamentul de ordine interioar (ROI); Statutul de funcionare al organizaiei. Din aceste documente rezult informaii despre funciile, activitile i modul de realizare a lor, relaiile funcionale dintre compartimente, sarcina ce revine fiecrui compartiment. C. Depistarea deficienelor informaionale. Studiile efectuate asupra sistemelor informaionale din cadrul firmelor au reliefat existena unor deficiene tipice, relativ frecvente, reflectare a unor erori n conceperea i implementarea lor, a cror cunoatere i prentmpinare este esenial. Distorsiunea prima dintre deficienele tipice, const n modificarea parial neintenionat a coninutului, a mesajului unei informaii pe parcursul culegerii, prelucrrii i transmiterii de la emitor la receptor. Dintre cauzele multiple care genereaz distorsiunea menionm ca foarte frecvente: diferenele n pregtirea persoanelor implicate n vehicularea informaiei, folosirea de supori informaionali necorespunztori pentru nregistrarea informaiilor, manipularea neglijent a suporilor de informaii n procesul transmiterii lor beneficiarilor, utilizarea de mijloace necorespunztoare pentru nregistrarea i transmiterea informaiilor etc. Filtrajul, a doua deficien informaional major, se deosebete de distorsiune prin aceea c modificarea parial sau total a mesajului sau coninutului informaiilor are loc n mod intenionat. Cauza filtrajului este una singur: intervenia pe parcursul nregistrrii, transmiterii i prelucrrii informaiilor a unor persoane, care au interesul ca beneficiarul informaiei s

30

primeasc un mesaj schimbat. Aceast deficien cronic a sistemului informaional se manifest n special cnd unii manageri sunt incoreci sau nu-i exercit integral atribuiile de control. Efectul negativ att al distorsiunii, ct i al filtrajului este dezinformarea parial sau integral a beneficiarului de informaii. Cnd dezinformarea se produce la nivelul managerilor, aceasta se reflect n diminuarea calitii deciziilor. Cnd dezinformarea se produce la nivelul executanilor, efectele imediate se resimt pe planul realizrii proceselor cu caracter operaional, impietnd asupra cantitii, calitii i perioadei de obinere i furnizare a produselor i serviciilor. n ambele situaii, efectele pe termen lung sunt scderea eficienei, concomitent cu deteriorarea ntr-o anumit msur a climatului de munc, a relaiilor dintre personalul implicat .a. Redundana este o alt deficien major tipic a sistemului informaional, care const n nregistrarea, transmiterea i prelucrarea repetat a unor informaii. Cauza major a acestei disfuncionaliti informaionale o reprezint absena coordonrii sau coordonarea defectuoas a anumitor segmente ale sistemului managerial. Redundana se produce mai ales cnd nu se respect principiul unitii de decizie i aciune, cnd mai muli manageri se adreseaz nemijlocit cu cereri de informaii unor compartimente, fr ca personalul managerial responsabil nemijlocit de activitatea lor s fie informat i s intervin. Efectele redundanei, care se manifest adesea sub forma cererii acelorai informaii de ctre diferii beneficiari, dar sub alte forme, constau ntro apreciabil risip de timp i adesea de mijloace materiale din partea celor implicai. n categoria deficienelor majore se nscrie i suprancrcarea circuitelor informaionale cu informaii, prin care desemnm vehicularea prin ele a unei cantiti de informaii ce-i depete capacitatea de transport, ceea ce duce la blocarea i/sau ntrzierea ajungerii unei pri din informaii la adresant. Printre cauzele care o genereaz menionm n afara redundanei nerespectarea caracterului piramidal al sistemului informaional. Prin caracter piramidal al sistemului informaional nelegem transmiterea i agregarea selectiv a informaiilor pe verticala sistemului de management corespunztor sferei obiectivelor, competenelor i responsabilitilor circumscrise subdiviziunilor organizatorice. La originea acestei situaii se afl proiectarea defectuoas a sistemului informaional, insuficienta pregtire a unor manageri i executani, tendina unora de a-i umfla realizrile, de a-i populariza excesiv aciunile etc. Fr ndoial c elementele menionate nu epuizeaz gama deficienelor cronice ale sistemului informaional, dar constituie, de regul, maladiile cele mai frecvente, a cror cunoatere, identificare i eliminare constituie o component de baz a raionalizrii sistemului informaional al organizaiilor. D. Identificarea resurselor existente. Resursele necesare se mpart n 4 categorii: Resurse materiale consumabile, toner, calculatoare, cablaje, prize electrice, scanere, imprimante, mobilier. 31

Resurse umane personal de conducere i execuie implicat, consultanii n management, informaticienii, prestatorii de servicii specializate; Resurse informaionale metodologii, instruciuni, cri, studii, documentaii; Resurse financiare necesare plii onorariilor realizatorilor studiului, achiziionrii de echipamente electronice i consumabile. Este foarte important analiza atent a cerinelor, deoarece ele pot fi incomplet exprimate sau pot fi exprimate ca opinii, sugernd soluia tehnic, fr s descrie cerinele efective ale problemei . Cerinele se pot mpri n: Cerine funcionale se refer la activitile pe care trebuie s le realizeze noul sistem (cerine referitoare la stocarea, modificarea datelor; cerine privind modul de obinere a rapoartelor); Cerine nefuncionale se refer la modul n care sistemul realizeaz activitile prevzute (cerine privind securitatea datelor; cerine privind refacerea datelor pierdute; cerine de arhivare; cerine determinate de trecerea de la prelucrarea manual la prelucrarea automat). Determinarea cerinelor sistemului este o activitate esenial n aflarea situaiei existente i a ceea ce se dorete n viitor. Culegerea informaiilor este posibil prin metode tradiionale sau moderne. Metodele tradiionale de colectare a cerinelor sistemului sunt: interviuri individuale; anchete realizate prin chestionare; intervievarea grupurilor de oameni cu interese comune; observarea personalului in momente bine definite pentru a vedea modul n care sunt folosite informaiile pentru exercitarea sarcinilor de serviciu; studierea documentaiei firmei pentru a se cunoate coninutul rapoartelor, al politicilor spre care se ndreapt prelucrarea datelor; Metodele moderne mai des utilizate sunt: sesiunile JAD (Joint Application Design) ; sistemele de sprijinire a grupurilor de lucru; prototipizarea; RAD (Rapid Application Development) ; Intervievarea Interviul este procesul comunicrii directe de stabilire a unei relaii cu o finalitate precisa, predeterminata, proces conceput pe alternanta rolurilor si care implica formulri de ntrebri si obinerea de rspunsuri. Cuvntul proces semnific dinamism, interaciune continu cu multe variabile de lucru, cu aciune nlnuit, dup un anumit sistem de derulare.

32

Cuvntul diadic, pornind de la diad, scoate n relief faptul c interviul este o interaciune persoan-cu-persoan ntre dou pri sau dou componente, evitndu-se astfel faptul c la interviu pot participa mai multe persoane, dar niciodat mai mult de dou pri: cea care ia interviul i cea intervievat. Cuvntul relaii sugereaz o legtura interpersonal ntre prile interviului. Finalitate precis, predeterminat nseamn c cel puin o persoan vine la interviu cu un anumit scop i vrea s abordeze un anumit subiect. Alternana rolurilor are conotaia mprtirii gndurilor, a simmintelor i informaiilor printr-o schimbare continu a rolurilor. Dac numai una dintre pri vorbete si cealalt ascult se poate vorbi despre un discurs (speech), si nu despre interviu. Se consider c aproximativ 70% din timpul total al interviului aparine intervievatului i 30% celui ce ia interviul (anchetator). Sunt i tipuri de interviuri in care se pot inversa rolurile, cum ar fi cazul interviurilor pentru oferirea de informaii sau promovarea unei vnzri. Formularea de ntrebri i obinerea rspunsurilor constituie procesele eseniale ale interviului. Puine sunt interviurile care s nu necesite o structurare prealabil a ntrebrilor. Chestionarele Spre deosebire de interviuri, chestionarele sunt mai puin costisitoare i ntr-un timp relativ scurt, pot oferi un volum mare de informaii necesare analizei sistemului. Deoarece conceperea chestionarului este mai mult o arta dect o tiin, specialitii s-au strduit s-i prezinte experiena sub forma unor reguli, recomandate ndeosebi nceptorilor, cei cu state vechi le pot utiliza drept elemente de comparaie pentru a-i evalua paii ntregii proceduri. Din aceste motive se consider de bun augur descrierea pailor parcuri pentru conceperea unui chestionar : pasul 1 : Ce informaii vor fi cutate ? n primul pas al chestionarului se stabilesc informaiile care trebuie s fie obinute, operaie declanat n faza embrionar a cercetrii de ntreprins. Neglijena manifestata n aceast etap va conduce la obinerea unor informaii nerelevante. pasul 2 : Stabilirea tipului de chestionar i a metodei de administrare Dup identificarea informaiilor de cutat, cel ce concepe chestionarul trebuie s specifice modul n care le va obine. Decizia se va referi la structura si modul de formulare a ntrebrii, dup care se va pune problema administrrii chestionarului. : prin pot, telefonic sau cu operator(o persoan special desemnat pentru aceast operaiune). pasul 3 : Determinarea coninutului fiecrei ntrebri pasul 4 : Stabilirea modului de redactare a rspunsului pentru fiecare ntrebare Dac se merge pe o variant fix, proiectantul trebuie s decid dac va folosi ntrebri nchise sau dac va merge pe varianta opiuni multiple, dou opiuni sau a scalei de valori. pasul 5 : Formularea ntrebrilor

33

De chestionarului.

modul

care

sunt

formulate

ntrebrile,

practic

depinde

succesul

pasul 6 : Stabilirea secvenei ntrebrilor pasul7: Validarea caracteristicilor tehnice ale chestionarului pasul 8: Reevaluarea pailor 1-7 i revizuirea lor (dac este cazul). Pasul 9: Efectuarea pretestului i revizuirea final (dac este cazul). De regul, chestionarele sunt administrate pe hrtie, dar ele pot fi efectuate cu sau fr operator uman, direct, prin telefon, sau chiar pe dischet, sau prin intermediul serviciilor oferite de calculatoare. Chestionarele, n cea mai mare parte, se bazeaz pe ntrebri cu schem fix de rspuns, iar atunci cnd conin ntrebri cu o formulare vag au ca scop aflarea prerilor celor chestionai, pentru a putea fi surprinse ct mau multe cazuri. Eantionarea ntruct colectivitile depesc ntotdeauna numrul celor ce sunt chestionai, o problema esenial o constituie stabilirea eantionului chestionat. De regula, se folosesc urmtoarele 4 metode sau combinaii ale lor : cei adecvai eantionului : ei pot fi oameni care i desfoar activitatea ntr-un anumit loc, cei care sunt motivai s dea rspunsuri sau cei care vor s dea rspunsuri sau cei care vor s fie intervievai. un grup aleator : dac exista o list a utilizatorilor unui sistem simplu, se selecteaz fiecare a n-a persoana, n care n este o raie de selecie. O alt modalitate const n selecia persoanelor pe baz ordonrii lor dup a 2-a, a 3-a liter a numelui sau a prenumelui sau prin generarea aleatoare a numerelor cu ajutorul calculatorului. un eantion precizat: pot fi numai persoanele care ndeplinesc anumite criterii. un eantion stratificat: dac sunt mai multe categorii de persoane, din fiecare, dup criterii aleatoare, vor fi selectai cei eantionai. De exemplu: dintre utilizatori, conductori, informaticieni. Observarea direct a utilizatorilor Nu ntotdeauna consultarea persoanelor conduce la obinerea celor mai bune rezultate, chiar si atunci cnd acestea afirm ca ofer cele mai sigure informaii sau au impresia ca dein adevrul absolut asupra sistemului analizat. Prerile sunt subiective. Desfurarea operaiunii de observare directa depinde si de acceptul sau bunele intenii ale organizaiei supuse analizei. Uneori, chiar daca exista un astfel de accept, prezenta analitilor printre angajai ii determina pe acetia din urma sa manifeste un comportament anormal, cu scopul de a crea o anumita impresie. Astfel pot fi emoionai, stresai, se pot fora s efectueze lucrrile mai repede, s simuleze ocuparea complet a timpului de munc. Alteori, dac au un alt obiectiv ei pot lucra mai ncet, pot bruia noul sistem s.a. Aadar, observarea presupune pentru analiti selecia unei palete foarte largi de 34

probleme. Analiza procedurilor de lucru i a altor documente Documentele ce pot fi studiate sunt de o mare diversitate. Dintre documentele mai des solicitate fac parte : declararea misiunii i strategiei organizaiei, cunoaterea obiectivelor acesteia, a planurilor de afaceri, a studiilor de fezabilitate, a structurii organizatorice (organigrama), a regulamentelor de organizare si funcionare, a celor de ordine interioara, a normelor interne de fabricaie, a standardelor folosite, a fiselor posturilor, a corespondentei interne si externe, a rapoartelor de analiza rezultate din studii anterioare s.a. Un prim tip de documente se refera la procedurile de lucru pentru activitile individuale sau ale grupurilor. Prin ele se descrie modul in care se exercita o anumita activitate, prezentndu-se si datele si/sau informaiile pe care le solicita sau le genereaz. Un al doilea tip de documente ce este studiat de analitii de sistem l constituie formularele utilizate de ctre unitate pentru toate tranzaciile interne si externe care au loc. Al treilea tip l constituie rapoartele generate de sistemul actual. Al patrulea tip se regsete numai in sistemele de prelucrare automata a datelor si se refera la documentaia folosit in sistemul informatic. Ca efect al tendinelor de mrire a timpului de analiz a sistemelor existente, n ultimii ani s-a efectuat trecerea spre tehnicile moderne, unele dintre ele care preiau din ce n ce mai puine elemente ale sistemelor existente. Sesiunile JAD pun laolalt toate forele interesate n dezvoltarea sistemelor: utilizatorii cheie, managerii i analitii de sistem implicai n analiza sistemului curent. Din acest punct de vedere JAD este similar interviului la nivel de grup. Totui, n sesiunile JAD ce urmeaz o anumit secven de derulare a activitilor pe baza unor roluri bine definite. Prototipizarea este un proces iterativ prin care analitii i utilizatorii pun n discuie o versiune rudimentar a unui sistem informaional, care va fi ntr-o continu schimbare, n funcie de reacia utilizatorului. Prototipul este vzut i testat de utilizator, avnd posibilitatea s precizeze ce ar mai dori, dar i s-i genereze aceast form nou, firesc, cu ajutorul specialitilor din preajm. RAD este o metodologie de realizare a sistemelor informaionale care promite sisteme mai bune, mai ieftine i realizate mai rapid. O prim explicaie const n celor mai buni proiectani de sisteme i a celor mai reprezentativi utilizatori , care, mpreun, n timp real, lucreaz la realizarea sistemului. Diferena major a RAD fa de JAD const n faptul c prototipul devine elementul fundamental al noului sistem - ecranele afiate n timpul prototipizrii devin ecrane ale sistemului, i nu modele ale unui posibil sistem. Plecnd de la aceste obiective, suportul hardware i software al noului sistem informatic trebuie s ndeplineasc urmtoarele cerine:

35

o Asigurarea suportului informaional prin crearea i ntreinerea unei baze de date sigure i complete: crearea i actualizarea n timp real a imaginii procesului n memoria intern i accesul transparent pentru utilizatori i aplicaii la aceast imagine; crearea i actualizarea n timp real a bazei de date cu evoluia n timp a procesului precum i accesul distribuit la datele nregistrate; completarea n timp real a bazei de date cu evenimentele din sistem i accesul distribuit la informaii; arhivarea i ntreinerea arhivelor cu istoricul procesului i evenimentelor precum i accesul distribuit la datele din arhiv. o Asigurarea unui flux informaional coerent: circulaia selectiv a informaiilor existente n imaginea intern a procesului ctre utilizatori, n funcie de specificul activitilor; gestiunea automat a fluxului de date pe orizontal i pe vertical (n interiorul i ntre nivelele ierarhice) n vederea ntreinerii bazelor de date; gestiunea dinamic a nregistrrilor n baza de date innd cont de durata de viaa impus pentru acestea. o Prezentarea informaiilor ctre utilizatori Prin intermediul staiilor de lucru, utilizatorul poate avea acces la informaiile din sistem n concordan cu sarcinile pe care acesta la are n ierarhia de funcii. Accesul la sistem se face numai prin identificarea utilizatorului dup nume i parola de protecie, numai pentru funciile specifice postului su. o Comunicarea transparent pentru utilizatori ntre echipamentele din sistem Suportul de comunicaie trebuie astfel conceput nct pentru orice utilizator echipamentele interconectate s fie vzute ca un singur calculator uria. o Integrarea cu alte aplicaii existente sistemului informaional Utilizarea unor legturi de comunicaie dedicate, pentru activitile de conducere operativ. Accesul la informaii, utiliznd serviciile intranet. o Disponibilitatea i funcionarea degradat n cazul cderii unor componente i sigurana pstrrii informaiilor Posibilitatea de intervenie pentru ntreinere sau depanare asupra unor componente ale sistemului fr afectarea funcionrii de ansamblu. Funcionarea n regim de rezervare activ a componentelor vitale ale sistemului: canale de comunicaie dublate, servere de baze de date cu mai multe procesoare i memorii externe RAID. Replicarea componentelor vitale ale bazei de date n locaii diferite, pentru a evita pierderea datelor n caz de defect. Accesul la funciile specifice de la orice staie de lucru n cazul indisponibilitii celor

36

destinate implicit pentru funciile respective. o Configurabilitatea i posibilitatea de extindere Abordarea realizrii sistemului n etape succesive impune existena unor funcii de baz care s permit: 1. Extinderea sistemului prin adugarea de noi componente fizice i logice. 2. Modificarea interactiv a bazelor de date care descriu componentele logice din sistem 3. Adugarea de noi aplicaii care au acces la informaiile din sistem.

3.3STRUCTURAREA CERINELOR SISTEMULUI n structurarea unui sistem informatic se utilizeaz mai multe criterii de descompunere a acestuia n subsisteme i module componente: Funciunile sistemului. - Sistemul informaional este alctuit din mai multe subsisteme funcionale: producie, comercial, financiar-contabil, personal, cercetare-dezvoltare; Activitile sistemului O serie de activiti se desfoar n cadrul unui agent economic, care respect anumite proceduri bine stabilite n vederea realizrii obiectivelor. Activitile variaz ca tip i numr de la o unitate la alta sau n timp. Organizarea sistemului n fiecare agent economic se cunosc departamentele, localizarea i rolul lor. Natura componentelor din cadrul sistemelor subsistemele care pot fi identificate potrivit acestui criteriu au n vedere componente de tipul: materii prime, materiale, echipamente, resurse umane, produse finite, resurse financiare. Orizontul de conducere se identific subsistemele: strategic, tactic, operativ. Se are n vedere structurarea sistemului i n subsistemul decizional, subsistemul condus i subsistemul informaional. Indiferent de criteriul utilizat putem spune c structurarea cerinelor sistemului e etapa cea mai complex din cadrul analizei i se bazeaz pe 2 activiti (Fig. 3.2 ): modelarea proceselor; modelarea datelor.

37

Sisteme subsisteme informationale/proceduri informationale

Documentare i analiza

Informatii i legturi dintre ele

Proceduri i reguli de gestiune

Modelare

Modelul conceptual al datelor

Modelul conceptual al prelucrarilor

Fig. 3.2 Activitile etapei de analiz Activitatea de analiz pentru modelarea conceptual se poate realiza sub trei aspecte: structural, dinamic i funcional. Analiza structural evideniaz, la nivel conceptual, modul de structurare a datelor i a legturilor dintre ele. Cea mai utilizat tehnic este entitate-asociere. Aceasta conine: o Identificarea entitilor: fenomene, procese, obiecte concrete sau abstracte (substantivele din prezentarea activitii descrise) (exemple de entiti: Persoane, Produse, Beneficiari). o Identificarea asocierilor dintre entiti ca fiind legturile semnificative de un anumit tip (verbele din prezentarea activitii descrise). o Identificarea atributelor ce caracterizeaz fiecare entitate n parte (exemple de atribute: Marca, Nume, Adres). o Stabilirea atributelor de identificare unic a realizrilor entitii, drept chei. Rezultatul analizei structurale este modelul static (structural), numit i diagram entitateasociere. Analiza dinamic evideniaz comportamentul elementelor sistemului la anumite evenimente. Una dintre tehnicile utilizate este diagrama stare-tranziie. 38

Aceasta presupune: o Identificarea strilor n care se pot afla componentele sistemului. o Identificarea evenimentelor care determin trecerea unei componente dintr-o stare n alta. o Stabilirea tranziiilor admise ntre stri o Construirea diagramei stare-tranziie Rezultatul analizei dinamice: modelul dinamic. Analiza funcional evideniaz modul de asigurare a cerinelor informaionale (fluxul prelucrrilor) din cadrul sistemului, prin care intrrile sunt transformate n ieiri. Cea mai utilizat tehnic este diagrama de flux a datelor. Conform acestei tehnici se delimiteaz: o Aria de cuprindere a sistemului. o Se identific sursele de date. o Se identific modul de circulaie i prelucrare a datelor. o Se identific apoi rezultatele obinute. Rezultatul analizei funcionale: modelul funcional. Urmare a operaiunii de culegere a cerinelor sistemului este activitatea de structurare a cerinelor prin metode specifice: modelarea proceselor, modelarea logicii proceselor i modelarea conceptual a datelor. Indiferent de metodologiile folosite n realizarea unui sistem, toate apeleaz la operaiunea de modelare logic a datelor i prelucrrilor sub form de diagrame. Exist mai multe tipuri de diagrame, utilizabile n diverse etape ale ciclului de via al sistemului sau pentru anumite activiti. n practic, cele mai multe produse apeleaz la dou tehnici de redare a diagramelor fluxurilor de date: Gane & Sarson i Yourdon & DeMarco. Prin analiza diagramelor fluxurilor de date se pot reliefa urmtoarele aspecte: fluxuri de date redundante, aprute, de regul, prin apelarea la nume diferite pentru acelai tip de date; date care intr n prelucrri dar nu sunt folosite; datele ce sunt actualizate identic n mai multe locuri. 3.4EVALUAREA SISTEMELOR INFORMATICE Evaluarea sistemului existent se realizeaz sub dou aspecte: Evaluarea performanelor i limitelor sistemului existent se face innd cont de urmtoarele criterii: o Msura n care sistemul informaional asigur realizarea obiectivelor, ndeplinirea sarcinilor de baz ale unitii i exercitarea atributelor de conducere; o Operativitatea n culegerea i trasmiterea informaiilor i datelor, ceea ce caracterizeaz timpul de rspuns al sistemului infomaional; o Calitatea i sigurana legturilor informaionale, a fluxurilor informaionale; 39

o Posibiliti de control i de efectuare a coreciilor. Evaluarea gradului de pregtire a unitii economice pentru proiectarea i implementarea sistemului informatic presupune: o Stabilirea nivelului de pregtire a personalului i a experienei dobndite n prelucrarea automat a datelor; o Existena unei discipline tehnologice; o Existena fondului de date necesar pentru realizarea sistemului informatic. 3.5GENERAREA I ALEGEREA VARIANTELOR DE PROIECTARE Concluziile la care ajunge echipa de analiti dup parcurgerea celor 2 etape, de determinare i structurare a cerinelor, se vor regsi n cel puin 2 i maxim 6 variante de soluii pentru problema analizat. n practic, numrul de soluii propuse de specialiti este de 3, ntrucit prin el pot fi surprinse soluii extreme, dar i de mijloc. Varianta 1 este cea mai simpl i se caracterizeaz astfel: e cea mai conservatoare n privina costurilor, efortului depus i tehnologiilor implicate; e puternic orientata spre realizarea pe hrtie a fluxului informaional sau spre eliminarea redundantelor din procesele curente; ofer soluii pentru tot ce a solicitat utilizatorul implicand modificari putine n sistemul informational existent; Varianta 2, cea mai complexa, ofera multiple solutii pentru problema studiata i se caracterizeaza prin: ofera cele mai performante sisteme, bazate pe cele mai moderne tehnologii; sunt orientate spre funcionalitate; resursele umane i financiare sunt ncadrate n anumite limite; utilizatorul primete toate soluiile posibile pentru rezolvarea problemelor dar nu ntotdeauna poate opta pentru o astfel de variant datorit resurselor limitate; sistemul implementat va fi un sistem deschis. Varianta 3 este cea de compromis ntre cele 2: obiectivul central l constituie funcionalitatea de nalt nivel; restriciile legate de costuri dispar. n generarea acestor variante se ine cont de condiiile eseniale ale activitii: atingerea funciilor obligatorii ale noului sistem; respectarea restriciilor impuse; dar i de unele aspecte practice ca: o dac sistemul poate fi realizat cu fore proprii o dac selecia pentru implementarea sistemului e optim selecia softului i hardului limitele organizaiei. 40

Fiecare variant va conine: A. prezentarea generala a proiectului din care sa rezulte aria de cuprindere a proiectului, gradul de distributie a sistemului, nivelul lui de automatizare, necesarul de resurse, planificarea calendaristic. B. descrierea sistemului vizeaz configuraia sistemului determinat de realizarea cerinelor i de restriciile impuse. n ceea ce privete cerinele, acestea pot fi de 2 feluri: funcionale i nefuncionale Cerinele funcionale se refer la funciunile pe care sistemul informatic trebuie s le implementeze, cu precizarea c, n proportie de 80-90%, se vor implementa funciunile sistemului actual, la care se vor aduga funciuni cerute de beneficiar sau analist pentru asigurarea performanelor dorite. Cerinele nefuncionale in de caracteristicile tehnice ale sistemului informatic, cum ar fi: tehnologiile de prelucrare, performantele i securitatea sistemului, sigurana i arhivarea datelor. n vederea asigurrii acestor cerine, descrierea sistemului va conine urmtoarele elemente: specificarea obiectivelor n funcie de performanele urmrite; stabilirea funciilor obligatorii ale noului sistem i a restriciilor impuse; stabilirea minimului necesar de informaii solicitate de noul sistem concretizate n: o definirea principalelor intrari/iesiri; o definirea solutiilor de organizare a datelor, definirea variantelor tehnologice de prelucrare; o definirea restrictiilor informaionale si de control; prezentarea problemelor legate de realizarea sistemului informatic, cum ar fi: precizarea modalitilor de realizare a sistemului informatic (dac sistemul va fi realizat cu fore proprii), precizarea prioritilor n realizarea obiectivelor sistemului informatic, specificarea cerinelor speciale privind flexibilitatea, compatibilitatea cu alte sisteme, gradul de generalizare a sistemului. C. analiza cost beneficiu presupune estimarea duratei de realizare, a resurselor necesare i efectelor economice directe i indirecte care se vor obine din exploatarea sistemului. n functie de aceast analiza se calculeaza indicatorii de eficiena economic i se apreciaz dac este profitabil proiectarea noului sistem informatic. D. analiza impactului introducerii sistemului prezint aspecte ale oportunitii implementrii noului sistem. Se realizeaz o analiz a modificrilor pe care le aduce n structura organizatoric, deoarece eliminarea unor funciuni ale sistemului actual implic desfiinarea unor posturi de lucru, birouri, servicii, departamente, iar introducerea de noi funciuni duce la nfiinarea de noi posturi. Tot aici este analizat comportamentul organizatoric dac sistemul implementat poate fi utilizat de persoanele crora le este adresat.

41

3.6 ANALIZE DE FEZABILITATE Elaborarea unui sistem poate costa milioane de dolari i se poate realiza pe parcursul a trei pn la ase ani pentru a fi complet. Din aceste motive, este normal ca factorii de conducere s demareze proiectarea unui sistem dup ce se efectueaz studii de fezabilitate. Un studiu de fezabilitate are rolul de a asigura informaiile obiective necesare pentru a cunoate dac un proiect poate fi demarat sau nu, sau dac un proiect deja nceput mai poate fi continuat. Proporiile i durata studiilor de fezabilitate variaz, n funcie de mrimea i natura sistemului de implementat. Echipele de studiu trebuie s includ att persoane cu nalte cunotine tehnice, ct i persoane cu bogate cunotine i experien n activitile unitii studiate. Dac unitatea nu dispune de personalul adecvat pentru partea tehnic a studiului, atunci va putea angaja din afar specialiti. De asemenea, echipele trebuie s aib n structur att reprezentani ai conducerii, ct i ai echipelor de control intern sau revizie intern. Nu n ultimul rnd, trebuie ca din echip s fac parte reprezentanii utilizatorilor. Cnd 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 orict de subiectiv, ntruct proiectul nu este prezentat cu lux de amnunte. ns, ndat ce se obine o situaie mai clar despre sistem, despre natura problemei de rezolvat, precum i despre doleanele utilizatorilor, msurarea preliminar a fezabilitii poate fi determinat odat cu faza de analiz a sistemului. Cnd proiectanii ofer dou sau trei variante de elaborare a sistemului, numai studiile de fezabilitate 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 al proiectrii, implementrii i exploatrii. Este ultima ans a unitilor de a mai putea renuna la sistem, naintea implementrii. De fiecare dat, studiile de fezabilitate trebuie s aib la baz o documentaie complet. Aceasta va conine: definirea problemei (o scurt descriere a proiectului i explicarea a ceea ce i propune el s realizeze); descrierea cerinelor sistemului; descrierea soluiilor sistemului propus; explicaia critic a motivrii studiului ntreprins; cuantificarea tuturor costurilor materialelor i beneficiile aferente; list a costurilor i beneficiilor necuantificabile. Tipurile analizelor de fezabilitate Se contureaz cteva dimensiuni ale fezabilitii, care trebuie s fie evaluate prin studiul de fezabilitate ntreprins, incluznd fezabilitatea tehnic, economic, de exploatare(operaional), a legalitii i a programrii n timp. Fezabilitatea tehnic. Problema fundamental este: poate fi implementat sistemul

42

planificat n organizaia respectiv folosind tehnologia existent? Ofer unitatea condiii persoanelor care vor proiecta, implementa i exploata sistemul propus? Fezabilitatea economic trebuie s rspunde la dou ntrebri. Prima: justific sistemul propus banii, alte resurse i costurile necesare pentru a fi implementat? A doua: are unitatea fondurile necesare pentru elaborarea i implementarea sistemului, date fiind cerinele de capital i pentru alte proiecte existente? Pentru a rspunde la aceste ntrebri, trebuie s fie estimate i analizate diverse costuri i beneficii asociate fiecrei variante. Fezabilitatea exploatrii pornete de la o prim ntrebare, i anume: este posibil ca noul sistem s fie utilizat de ctre persoanele crora le este adresat. Rspunsul poate fi dat doar n condiiile din ntreprindere, de ceea ce se ntmpl cu persoanele din sistem nainte de implementarea celui nou, n sensul participrii efective, motivate de realizarea lui, precum i de dorina lor de transformare. Tot aici intr o multitudine de factori comportamentali. Fezabilitatea legalitii urmrete s determine dac se pot nregistra conflicte ntre sistemul propus i posibilitatea organizaiei n care se face implementarea de a nu avea conflicte fa de obligaiile legale. De asemenea, sistemul trebuie s respecte toate statule, deciziile, regulamentele, legile i alte acte normative i juridice, att n profil teritorial, ct i naional i internaional. Fezabilitatea programrii rspunde n primul rnd la ntrebarea: poate fi proiectat i implementat sistemul n timpul alocat? Dac rspunsul este nu, sistemul trebuie s fie modificat sau va fi luat n studiu o alt variant, sau data implementrii va fi schimba.

4. MODELAREA NOULUI SISTEM INFORMATIC

Activitatea de modelare a unui sistem informatic se regsete n pricipalele activiti de realizare a sistemului: analiz, proiectare, implementare, dar cel mai pregnant se manifest n crearea sistemului de baz de date. Din acest motiv, dintre toate metodologiile utilizate pentru modelarea sistemelor informatice ne vom referi, n cele ce urmeaz, la cele folosite pentru realizarea unui sistem de baz de date. 4.1 ORGANIZAREA DATELOR N CADRUL SISTEMELOR INFORMATICE Datele sunt stocate i structurate n cadrul sistemelor de calcul, att n memoria intern, ct i n memoria extern. Prin caracteristicile de volum i complexitate, datele prezint aspecte specifice de organizare n memoria extern. Organizarea datelor este procesul de definire i structurare a datelor n colecii, precum i stabilirea legturilor ntre elementele unei colecii i ntre colecii. Organizarea datelor a evoluat n paralel cu creterea volumului de date prelucrat, precum i a gradului de complexitate a problemelor rezolvate cu ajutorul calculatorului. Evoluia organizrii datelor a pornit de la fiiere simple, au urmat fiierele complexe i, n final, s-a ajuns la cea mai performant form de organizare a datelor bazele de date.

43

Toate aceste forme de organizare a datelor se bazeaz pe noiunea de colecie de date. Colecia de date reprezint un ansamblu de date organizat dup anumite criterii i format din urmtoarele componente: familie de caracteristici compus din mai multe proprieti (atribute) care definesc aspecte ale obiectelor din lumea real prin valori; un predicat aplicat asupra familiei de proprieti, care conduce la o submulime ce definete o relaie de ordine ntre caracteristici, cu un anumit scop; alte componente care iau n considerare timpul i legturile. Investigare pleac de la o viziune de ansamblu a structurii logice a datelor. Datele sunt grupate n colecii de date, dup diverse criterii pentru fiecare subsistem sau la nivelul ntregului sistem Principalele criterii pe baza crora se poate efectua gruparea fondului de date sunt: Sfera de cunoatere; Domeniul de activitate; Stabilitatea coninutului datelor; Rolul datelor n procesul prelucrrii. Dup sfera de cunoatere se pot contura patru tipuri de colecii mari de date cu valori de ntrebuinare diferite, cu grad de agregare i sintetizare difereniat, care pot constitui obiectul stocrii i prelucrrii automate: Date primare; Indicatori tehnico-economici cu caracter operativ; Indicatori tehnico-economici cu centralizare medie; Indicatori sintetici. Dup domeniul de activitate, la nivelul unei uniti productive, datele pot fi grupate n colecii ce reflect entiti, fenomene i procese economice. Din punct de vedere al stabilitii datelor, putem delimita: colecii de date convenional constante i colecii de date variabile. Coleciile da date convenional constante sunt cu caracter normative, cu caracter descriptive, cu caracter de translatare sau de legtur. Principalele colecii de date cu caracter normativ sunt: Normative de fabricaie; Normative tehnologice; Normative de munc; Normative materiale. Din punct de vedere al prelucrrii datelor, coleciile de date se clasific n: Colecii de date de baz au un coninut omogen format din date primare care reflect stri, caracteristici, evenimente, fapte preluate din unul mai multe documente primare. Se poate aprecia c datele i pstreaz valabilitatea, relevana, autenticitatea, au o utilitate pe o perioad de existen a obiectelor pe care le reprezint, le descrie, le reflect; Coleciile de date pentru tranzacii - au un caracter temporar i un coninut format din

44

totalitatea modificrilor care pot interveni pe parcursul unui interval de timp asupra coninutului informaional din coleciile de date de baz; Coleciile de date intermediare sunt obinute pe baza unor operaii de sortare, fuziune, selectare din una sau mai multe colecii obiect potrivit unor cerine furnizate de utilizator; Coleciile de date statistice au un rol de orientare, de previziune, de fundamentare a unor decizii strategice; Colecii de date istorice au un rol de arhivare a coninutului unor colecii obiect, de tranzacii sau statistice i reflect o stare trecut a fenomenelor i proceselor economice. Structura de date constituie o colecie de date ntre care s-au stabilit o serie de legturi, care conduc la un anumit mod de identificare i de selectare a componentelor. Baza de date poate fi definit ca fiind mai multe colecii de date omogene, cu legturi ntre ele, stocate pe un suport de memorie extern i care formeaz un ansamblu: organizat ( pe niveluri de organizare a datelor); coerent (prin respectarea restriciilor de integritate i asigurarea proteciei datelor mpotriva incidentelor); structurat (datele i legturile dintre acestea sunt definite i descrise conform unui model de date); cu redundan minim i controlat a datelor; accesibil mai multor utilizatori n timp util. Apariia bazelor de date, ca mod de organizare a datelor n memoria extern, a determinat i modificarea software-ului aferent stocrii i prelucrrii datelor. Datele memorate n fiiere sunt prelucrate de programe scrise n diferite limbaje de programare universale, n timp ce datele memorate n baze de date sunt gestionate prin programe de aplicaie scrise ntr-un sistem de gestiune a bazelor de date (SGBD) ca software specializat. Aadar, realizarea bazei de date i a programelor de aplicaie aferente (pentru descrierea i manipularea datelor) sunt practic inseparabile, mpreun contribuind la realizarea unui sistem de baz de date. Un sistem de baz de date este format din urmtoarele componente: baza/bazele de date, care reprezint componenta de tip date a sistemului; sistemul de gestiune al bazei/bazelor de date, care constituie ansamblul de programe prin care se asigur gestionarea i prelucrarea complex a datelor i care reprezint componenta software a sistemului de baze de date; alte componente, precum: proceduri manuale i automate, inclusiv reglementri administrative, destinate bunei funcionri a sistemului, dicionarul bazei de date (conine informaii despre date, structura acestora, elemente de descriere a semanticii, statistici, documentaii), mijloace hardware utilizate, personalul implicat, reprezentat de diferite categorii de utilizatori finali i personal de specialitate (administrator, analiti, programatori, operatori). Aplicaiile de baze de date se caracterizeaz n primul rnd prin faptul c majoritatea

45

prelucrrilor care se fac sunt cele de memorare i regsire a datelor, efectuate asupra unor volume mari de date. n general operaiile de prelucrare snt destul de simple, spre deosebire de alte domenii ale informaticii - cum este de exemplu domeniul tehnic unde predomin operaiile de calcul care au o complexitate destul de ridicat. Cea mai frecvent operaie care apare ntr-o aplicaie de baze de date este aceea de consultare a datelor: ntr-adevr, pentru ce crem o baz de date dac nu o folosim? Alte operaii care apar pe lng cea de consultare: introducerea unor noi date, modificarea unor date existente, tergerea unor date perimate. Prin organizarea datelor n baze de date se asigur centralizarea acestora, fapt care conduce la o serie de avantaje: Reducerea redundanei datelor. Dac fiecare aplicaie lucreaz cu fiiere proprii, este posibil ca aceleai date s apar de mai multe ori n fiiere diferite. n cazul centralizrii datelor administratorul bazei de date poate organiza datele n aa fel nct toate aplicaiile s foloseasc aceleai fiiere. Astfel se obine o economie important a spaiului de memorie, i nu numai att. Evitarea inconsistenei datelor. Duplicarea datelor n fiiere diferite poate crea probleme la actualizare: este posibil ca prin actualizri pariale (din omisiune sau datorit unor accidente neprevzute) s avem valori diferite pentru una i aceeai entitate (de exemplu, un client poate avea mai multe nume: nu mai tim care este cel real). Posibilitatea partajrii datelor. Aceasta se refer la posibilitatea utilizrii datelor n comun de mai muli utilizatori i la posibilitatea dezvoltrii de noi aplicaii folosind datele deja existente. ncurajarea utilizrii unor standarde. Administratorul bazei de date poate impune alinierea la anumite standarde, fapt care permite ulterior un transfer rapid al datelor de pe o platform (hardware sau software) pe alta. Posibilitatea protejrii datelor. Administratorul bazei de date, avnd un control centralizat al datelor, poate introduce restricii diferite de acces la date pentru fiecare categorie de utilizatori. Meninerea integritii datelor. Baza de date trebuie s conin n permanen date corecte; aceasta presupune date coerente i plauzibile, fapt care poate fi garantat de procedurile de validare utilizate. Independena datelor. ntr-o aplicaie scris ntr-un limbaj clasic de programare, cunotinele despre structura datelor i tehnicile de accesare a acestora sunt "zidite" n programe. Orice schimbare n modul de reprezentare sau accesare face imposibil utilizarea aplicaiei: toate programele care refer aceste date trebuie rescrise. Independena datelor, garantat de utilizarea bazelor de date, presupune independena aplicaiei de modul de reprezentare a datelor i de tehnicile de acces utilizate. Trebuie s facem o precizare: simplul fapt de a utiliza un SGBD n vog la un moment dat nu ne garanteaz automat obinerea acestor avantaje! Administratorul bazei de date trebuie s aib o viziune de ansamblu asupra problemei care trebuie rezolvat, s cunoasc toate datele problemei (ce se d, ce se cere, cum se prelucreaz) i s cunoasc facilitile oferite de SGBDul folosit pentru a putea beneficia de avantajele de mai sus. i n primul rnd trebuie s aib cunotine serioase despre proiectarea aplicaiilor de baze de date. 46

4.2 NIVELURI DE ORGANIZARE A DATELOR NTR-O BAZ DE DATE Bazele de date sunt concepute pentru a prelucra un volum mare de informaii. Gestiunea acestora impune nu numai o structurare riguroasa a datelor, dar i o raionalizare a procedurilor de acces i prelucrare. Pentru atingerea acestui obiectiv este necesar o abstractizare a datelor memorate n baza de date. Astfel s-a ajuns ca astzi s existe trei niveluri de reprezentare i percepie a unei baze de date(figura 4.1) : extern, conceptual i intern. Nivelul fizic (sau intern). Structura datelor este descris foarte detaliat, fiind accesibil numai specialitilor (ingineri de sistem, programatori in limbaje asamblare sau alte limbaje apropiate de main. Cele doua pri principale ale bazei la acest nivel sunt (1) un set de programe care interacioneaz cu sistemul de operare pentru mbuntirea managementului bazei de date i (2) fiierele stocate in memoria externa a calculatorului. Fiierele ce conin datele propriu-zise sunt alctuite din articole sau nregistrri cu format comun. La acest nivel, structura BD se concretizeaz n schema intern. Nivelul conceptual (sau global). Este nivelul imediat superior celui fizic, datele fiind privite prin prisma semanticii lor, intereseaz coninutul lor efectiv, ca i relaiile care le leag de alte date. Reprezint primul nivel de abstractizare a lumii reale observate. Obiectivul acestui nivel l constituie modelarea realitii considerate, asigurndu-se independena bazei fa de orice restricie tehnologic sau echipament anume. ntreaga baz este descris prin intermediul unui numr restrns de structuri. Toi utilizatorii i exprim nevoile de date la nivel conceptual, prezentndu-le administratorului bazei de date, acesta fiind cel care are o viziune globala necesara satisfacerii tuturor cerinelor informaionale. La acest nivel, structura BD se concretizeaz n schema conceptual. Nivelul extern. Este ultimul nivel de abstractizare la care poate fi descris o baz de date .Dac la nivel conceptual baza de date este abordat n ansamblul ei, n practica un utilizator sau un grup de utilizatori lucreaz numai cu o poriune specifica a frazei n funcie de departamentul in care i desfoar activitatea i de atribuiile sale. Simplificarea interaciunii utilizatori - baz, precum i creterea securitii bazei sunt considerate ale unui nivel superior de abstractizare, care este nivelul extern. Astfel, structura se prezint sub diferite machete, referite uneori i ca sub-scheme, scheme externe sau imagini, n funcie de nevoile fiecrui utilizator sau grup de utilizatori.

47

Aplicaia 1.1

Aplicaia 1.2

Aplicaia 1.3

Aplicaia n.1

Aplicaia n.2 Nivel extern

Schema extern 1 INTERFA

Schema extern n

SGBD

SCHEMA CONCEPTUAL

Nivel conceptual

INTERFAA

BAZA DE DATE MEMORAT PE DISC

Nivel intern

Fig. 4.1. Niveluri de reprezentare a datelor

4.3MODELE DE DATE PENTRU BAZE DE DATE Dup cum s-a artat deja datele prin ele nsele nu constituie informaie. Informaia care poate fi obinut dintr-o colecie de date depinde de modul de organizare i structurare a acestor date precum i de modul n care aceste date snt utilizate. Pentru a decela coninutul de informaie al unei colecii de date este nevoie de o interpretare adecvat a acesteia. Un model de date este un instrument teoretic care permite obinerea unei asemenea interpretri. Un model de date este de fapt un instrument de abstractizare care ne ajut s identificm coninutul de informaie al unei colecii de date prin contrast cu valorile individuale ale datelor. Modelele de date se pot mpri n dou grupuri: modele de date strict tipizate, sunt cele n care fiecare dat trebuie s aparin unei categorii. Datele care nu se ncadreaz n mod natural ntr-o categorie vor trebui s fie forate ntr-una din categoriile modelului n caz contrar aceste date nu pot fi tratate n cadrul modelului considerat. De asemenea, pentru unele dintre aceste modele se presupune c gama categoriilor disponibile este predefinit i nu poate evolua dinamic. modele de date slab tipizate, sunt cele care nu fac nici o presupunere referitor la categorii. Categoriile sunt permise numai n msura n care se dovedesc utile. Datele individuale pot exista prin ele nsele i pot fi legate de alte date. Informaiile referitoare la categorii, dac exist, snt tratate n acelai mod ca i informaiile despre date. Modelele de date strict tipizate au dezavantajul lipsei de flexibilitate, ceea ce face dificil reprezentarea deosebirilor semantice mai subtile. S considerm de exemplu datele despre categoria ANGAJAT. Intr-un model strict tipizat aceast categorie trebuie s fie omogen, adic toate obiectele acestei categorii trebuie s aib aceleai proprieti, aceeai structur .a.m.d. Totui, angajaii cstorii au proprieti diferite fa de cei necstorii, dup cum este cazul i cu angajaii temporari fa de cei permaneni i exemplele ar putea continua. n ciuda acestor dificulti, modelele de date strict tipizate au marele avantaj c proprietile datelor pot fi abstractizate i cercetate n termenii categoriilor crora le aparin. Altfel 48

spus, bazat pe aceste categorii se poate formula o teorie care cuprinde proprietile datelor. Deoarece unele dintre proprietile categoriilor snt motenite de ctre datele care fac parte din ele, a demonstra un anumit lucru despre o categorie constituie o demonstraie i pentru datele din aceast categorie. Un alt avantaj al modelelor de date strict tipizate este faptul c fiecare dat este ncadrat, ntr-un fel sau altul, ntr-o categorie. Datorit acestui fapt, posibilele inconsistene pot fi evitate deoarece date apropiate din punct de vedere semantic vor fi apropiate i n cadrul modelului de date, mai precis vor fi n aceeai categorie. Majoritatea modelelor de date folosite n prelucrarea datelor prin calculator snt strict tipizate. Modelele de date care vor fi tratate n continuare fac i ele parte din acest grup. Structura de organizare a datelor nu furnizeaz o interpretare complet a semnificaiei acestora. Semnificaia datelor depinde i de modul n care acestea snt utilizate. De aceea este necesar s se specifice i operaiile permise asupra datelor. De exemplu, o list de obiecte poate fi o stiv sau o coad funcie de tipul operaiilor permise asupra obiectelor listei. Natura general a operaiilor care snt permise asupra datelor snt precizate tot n cadrul modelului de date i este dependent de structurile de date corespunztoare acestui model. In concluzie putem defini un model de date ca fiind un ansamblu de reguli pentru organizarea datelor, mpreun cu un set de operaii permise asupra acestor date. Orice model de date constituie un model al lumii nconjurtoare i ncearc s cuprind proprietile acesteia. Aceste proprieti se mpart n dou clase: statice i dinamice. Proprietile statice snt cele care nu se modific deci snt invariante n timp. Proprietile dinamice ncearc s surprind natura evolutiv a lumii nconjurtoare. Un model de date, notat M, poate fi definit ca fiind compus din dou pri: un set de reguli de structurare a datelor, numite i reguli generatoare, notate G. Aceste reguli exprim proprietile statice ale modelului de date i snt materializate n cadrul unui SGBD prin limbajul de descriere a datelor (LDD); un set de operaii permise asupra datelor, notate O. Aceste operaii exprim proprietile dinamice ale modelului de date i snt materializate n cadrul unui SGBD prin limbajul de manipulare a datelor (LMD). Limbajul de descriere date se folosete pentru descrierea structurilor de date permise n cadrul unui model de date M. Structurile permise pot fi specificate n dou moduri complementare: 1) Prin specificarea obiectelor permise i a relaiilor permise dintre ele folosind reguli generice de definire. 2) Prin specificarea obiectelor i relaiilor nepermise care snt excluse prin definirea unor restricii numite constrngeri. Iat de ce unele modele de date partiioneaz regulile generatoare G n dou pri: partea de specificare a structurii, Gs, i partea de specificarea constrngerilor, Gc. Regulile generatoare Gs genereaz structura unei scheme, iar regulile generatoare Gc genereaz constrngerile 49

asociate schemei. n consecin o schem S va consta din dou pri: o parte de structur Ss i o parte de constrngeri Sc care cuprinde o list explicit de constrngeri care trebuie respectate. Pe lng constrngerile explicite un model de date introduce i unele constrngeri implicite inerente modelului care snt ncorporate n partea de structur Ss. Altfel spus structura nsi, prin definiia sa, poate exclude anumite obiecte sau poate limita anumite relaii ntre obiecte. De exemplu n cazul modelului ierarhic relaiile dintre obiecte sunt restricionate la cele care corespund unei structuri de arbore. Limbajul de manipulare date cuprinde operaii care produc o schimbare n starea bazei de date. Starea unei baze de date este specificat prin totalitatea valorilor datelor din baz la un moment dat, la care se adaug valorile indicatorilor de poziie curent folosii pentru regsirea datelor. Starea unei baze de date reflect aspectul dinamic al unui model de date prin aceea c se schimb ca urmare a unei operaii asupra bazei de date. Aceast schimbare poate afecta fie datele din baz (n cazul operaiilor de adugare, tergere, actualizare), fie valoarea indicatorilor de poziie curent (n cazul operaiilor de localizare a unei date, operaii de tipul "get next" .a.). Este important de remarcat faptul c operaiile din cadrul LMD nu pot afecta structura bazei de date, deci aceste operaii conserv modelul conceptual al bazei de date asupra creia acioneaz. LDD i LMD constituie principalele faciliti ale oricrui SGBD. Pe de alt parte LDD i LMD snt materializri ale celor dou pri componente G i O ale oricrui model de date M. De aceea orice SGBD are la baz un anumit model de date care constituie fundamentul teoretic al construirii acestuia. Deci, n principiu, orice SGBD va putea fi caracterizat pe baza modelului de date asociat. De exemplu SGBD System R are la baz modelul de date relaional i este cunoscut ca un sistem relaional care gestioneaz baze de date relaionale. De-a lungul timpului s-au manifestat mai multe generaii de modele ale datelor, dar n gestiunea bazelor de date cele mai utilizate modele au fost: ierarhic, reea, relaional i obiectual modelul ierarhic, modelul reea, modelul relaional. Modelul ierarhic Acest model are la baz structura arborescent(baza de date poate fi asimilat unei mulimi de arbori). Exist un tip de nregistrare definit ca rdcin i, la orice alt nivel, mai multe tipuri de nregistrri subordonate (legtura ntre dou nivele succesive fiind de unul la muli n jos i unu la unu n sus). Accesul la date se face numai prin vrful ierarhiei (rdcin). Reprezentarea modelului ierarhic se realizeaz prin intermediul diagramelor de structur formate din dou elemente: o dreptunghiuri corespunztoare tipurilor de nregistrri; o linii corespunztoare legturilor. O nregistrare reprezint o colecie de cmpuri, fiecare cmp coninnd o singur valoare, iar legtura reprezint o asociere ntre dou nregistrri. Fiecrui tip de nregistrare din diagrama 50

de structur i corespunde, n baza de date, un anumit numr de nregistrri (realizri). Modelul ierarhic sufer de o serie de anomalii legate de operaiile de adugare, tergere i actualizare date. Anomalia de adugare - nu pot fi adugate date referitoare la un student pn cnd nu se cunoate cel puin un profesor al acestuia. Anomalia de tergere - Dac se terge nregistrarea referitoare la un anumit cadru didactic, atunci datele referitoare la acei studeni care l au pe acesta ca singurul lor profesor vor fi pierdute (snt copii unice) ntruct tergerea oricrui nod implic tergerea tuturor descendenilor si. Pe de alt parte verificarea posibilitii ca fenomenul menionat s apar este dificil de verificat. Anomalia de actualizare - atunci cnd se pune problema modificrii unui atribut al unui student (de exemplu devine bursier) este necesar explorarea ntregii baze de date pentru a depista toate apariiile studentului n cauz. n caz contrar apare pericolul de a introduce o inconsisten n baza de date ca urmare a faptului c acelai student va apare ca bursier n unele din nregistrri i nebursier n altele. n concluzie modelul ierarhic nu prezint o flexibilitate prea mare n structurarea datelor, fiind adecvat modelrii doar a relaiilor simple de tip 1:N. De asemenea modelul ierarhic prin natura sa limiteaz sever gama interogrilor care pot fi adresate bazei de date. Principalul avantaj al acestui model este posibilitatea realizrii de implementri eficiente chiar i n condiiile folosirii unor suporturi de memorare cu acces strict secvenial (benzi magnetice). La aceasta se adaug relativa simplitate a modelului, posibilitatea de a fi uor neles i un numr de operatori de manipulare date mai redus dect n cazul modelului de tip reea. Modelul reea Modelul reea este similar cu modelul ierarhic. Datele sunt reprezentate ca ntr-o mulime de ierarhii, n care un subordonat poate avea orici superiori. La un subordonat se poate ajunge pe mai multe ci. Structura de baz este format tot dintr-un set de nregistrri care sunt interconectate prin intermediul unor legturi. Reprezentarea bazei de date se poate asimila unui graf direcionat (noduri i arce). Cel mai mare dezavantaj al modelului reea este acela c are o structur prea apropiat de structura de memorare. Astfel legturile ntre entiti snt explicite, realizate prin pointeri a cror gestiune i manipulare este sarcina utilizatorului. ntreaga structur de lanuri care se ntretaie n cele mai diverse moduri este vizibil utilizatorului. Baza de date are tendina de a cpta o structur complex, structur care trebuie cunoscut i manipulat de ctre utilizator. Reprezentarea relaiilor ntre 3 sau mai multe mulimi de entiti produce structuri deosebit de complicate. n consecin aplicaiile devin i ele deosebit de complexe, ntruct operaiile de acces la date presupun abilitatea de a naviga prin structura de lanuri a bazei de date. Acest fapt

51

contrazice n mod flagrant principiul independenei datelor. Gama interogrilor posibile pentru o baz de date de tip reea este dat n principal de legturile explicite dintre mulimile de entiti, deci de structura bazei de date. Aceast structur limiteaz deci gama interogrilor, iar apariia de noi interogri presupune de obicei modificarea structurii bazei de date prin adugarea de noi legturi i / sau modificarea celor existente. Modelul relaional Modelul relaional are la baz teoria matematic a relaiilor (algebra relaional = colecie de operatori ce au ca operanzi relaii) permind utilizatorului s vad baza de date ca o colecie de tabele (relaii). Modelul relaional a fost introdus n 1970 de cercettorul american E. F. Codd i se fundamenteaz pe conceptul de structur relaional i algebr relaional. Prezentm n continuare o coresponden ntre termenii formali (definii mai sus) i termenii informali (cei folosii n mod curent n exploatarea bazelor de date relaionale): Relaie Tabel Tuplu Linie / nregistrare Cardinalitate Numr de linii Atribut Coloan / Cmp Grad Numr de coloane Domeniu Mulime de valori valide Corespondena nu trebuie considerat ca o echivalen, deoarece exist cteva deosebiri de care trebuie s inem seama (este de altfel una dintre diferenele pe care le sesizm ntre teorie i practic): noiunea de relaie este o noiune teoretic, pe cnd o tabel este un obiect concret, care are o anumit reprezentare n calculator - sub forma unui tablou bidimensional; ntr-o relaie ordinea atributelor i a tuplelor nu este semnificativ; ntr-o tabel exist o ordonare att a coloanelor dat de ordinea acestora la crearea tabelei, ct i a liniilor - dat de ordinea n care acestea au fost introduse, sau de ordinea unei chei care induce o anumit ordonare a liniilor n cadrul tabelei; o relaie este format ntotdeauna din tuple distincte; n multe cazuri o tabel poate avea linii duplicate.

4.4 MODELUL CONCEPTUAL AL DATELOR Modelul conceptual al datelor este o metod abstract de reprezentare a tipurilor de date, a legturilor dintre acestea, a dinamicii acestor legturi i a restriciilor (constrngerilor aferente). Pe baza unei analize detaliate i complete a intrrilor i a unor notaii i simboluri standardizate se va construi modelul conceptual al datelor.

52

Fundamentul teoretic al cestui model este c structura datelor dintr-o organizaie poate fi modelat folosind doar trei tipuri de obiecte: entiti, atribute, asocieri. Entitate O entitate este un model de obiect sau eveniment care are o existen de sine stttoare i poate fi identificat, n raport cu celelalte obiecte de acelai tip, prin caracteristici sau proprieti specifice. Exemplu: Produs, Furnizor, Intrri, Ieiri, Beneficiar, Comand, Factur. Modul de reprezentare a unei entiti este un dreptunghi n care se nscrie numele entitii. Realizare a unei entiti se numete mulimea format din cte o valoare a fiecrui atribut al entitii. Fiecare entitate va fi identificat prin proprietile care o caracterizeaz, numite atribute. Atributul Un atribut se definete ca fiind o proprietate a unei entiti sau a unei corespondene, caracterizat printr-un nume i un tip. Fiecare atribut care a fost selecionat la denumirea coninutului unei entiti este o caracteristic semnificativ pentru domeniul studiat. Un atribut poate fi : simplu: atunci cnd pentru o entitate sau o asociere poate lua o singur valoare; repetitiv: dac pentru o entitate sau o asociere poate lua mai multe valori. Reguli privitoare la atribute: fiecare atribut poate aprea ntr-o singur entitate (principiul nonredundanei ); un atribut poate avea mai multe valori elementare. n reprezentarea grafic, identificatorul entitii se subliniaz. Un domeniu este o mulime de valori scalare (atomice - care nu pot fi descompuse) de acelai tip. Exemple: mulimea codurilor personale, mulimea numelor de clieni, mulimea numelor de localiti .a. Din punct de vedere al rolului pe care il indeplineste atributul: poate fi: numeric, alfanumeric, sir de caractere Cu aceste valori se pot efectua mai multe operaii: cu majoritatea acestor valori se pot face comparaii; cu unele valori se pot face i alte operaii: o cantitate poate fi nmulit cu un pre (rezultnd o valoare), un pre poate fi nmulit cu o valoare (n cazul unei reaezri) .a.m.d. Asocierea O asociere reprezint legtura sau corespondena existent ntre dou sau mai multe realizri ale entitii. O asociere nu are o existen de sine stttoare, depinznd de existena realizrilor entitilor pe care le leag, n consecin nu are identificatori specifici. O asociere poate avea atribute proprii. 53

Mulimea care particip la asociere formeaz colecia acesteia; numrul acestora d gradul sau dimensiunea asocierii. ntre realizrile atributelor din entiti i cele ale proprietilor din asocieri (corespondene) se stabilesc cardinaliti sau conectiviti. Putem vorbi de o conectivitate minim (0 sau 1) i una maxim (1 sau n) S clasificm n continuare legturile binare dup cardinalitatea acestora (cte entiti din fiecare clas intr n cadrul legturii): legturi de tip 1:1 (one-to-one); observm o astfel de legtur n cazul unei evidene a personalului, care indic faptul c un departament este condus de un ef (un departament nu poate fi condus de mai muli efi, o persoan nu poate conduce mai multe departamente); legturi de tip 1:n (one-to-many); n evidena personalului remarcm o astfel de legtur ntre angajaii unui departament i departamentul n cauz (la un departament lucreaz mai muli angajai, un angajat nu poate lucra n cadrul mai multor departamente); la evidena facturilor remarcm o legtur ntre Facturi i Clieni (unui client i se pot ntocmi mai multe facturi; nu se poate ntocmi o aceeai factur pentru mai muli clieni); legturi de tip m:n (many-to-many); o astfel de legtur exist ntre Clieni i Produse: un client poate cumpra mai multe produse, i n acelai timp mai muli clieni pot cumpra un acelai sortiment de produse. Dup ce vor fi prezentate fundamentele modelului relaional, vom prezenta i tehnici de implementare a acestor tipuri de legturi. Exemplu de construire a modelului conceptual al datelor: Prezentarea activitii de gestiune a materialelor Se dorete ca n cadrul acestui sistem s se evidenieze furnizorii, facturile, magaziile, tipurile de materiale i bonurile de consum. Pentru a micora gradul de dificultate a aplicaiei se consider c toate materialele cuprinse pe o factur sunt trimise unei singure magazii. Materialele sunt recepionate de o magazie pe baza facturii i sunt eliberate seciilor de producie pe baza bonurilor de consum. Presupunem c materialele au un pre unitar de achiziie fix, care nu depinde de furnizor. Pe baza intrrilor (facturi) i a ieirilor (bonuri de consum) se dorete determinarea nivelului stocurilor de materiale. Intrrile i ieirile se opereaz zilnic n fia de magazie. Modelul conceptual al datelor (Fig. 4.2) n urma analizei problemei rezult entitile: Furnizor, Factura, Material, Magazie i Bon de consum. Identificarea corespondenelor: Furnizor - Factur Un furnizor poate emite de la 1 la n facturi, de unde rezult o coresponden EMITE. Factur - Material 54

ntr-o factur sunt cuprinse de la 1 la n materiale n diferite cantiti, de unde rezult o coresponden LINIE FACTUR. Factur - Magazie O magazie poate primi de la 1 la n facturi, de unde rezult o coresponden PRIMETE. Bon de consum - Material ntr-un bon de consum sunt cuprinse de la 1 la n materiale n diferite cantiti, de unde corespondena LINIE BON DE CONSUM. Bon de consum - Magazie O magazie emite de la 1 la n bonuri de consum, de unde rezult corespondena REALIZEAZ. Factur - Factur O factur poate fi stornat de 0 sau n facturi de stornare, de unde rezult corespondena SE STORNEAZ. Stabilirea cardinalitilor: Corespondena EMITE dinspre entitatea Furnizor (1, n) o un furnizor emite cel puin o factur (cardinalitate minim 1); o un furnizor poate emite mai multe facturi (cardinalitate maxim n). dinspre entitatea Factur (1, 1) o factura este emis de cel puin i de cel mult un furnizor (cardinalitate 1, 1). Corespondena PRIMETE dinspre entitatea Magazie (1, n) o o magazie primete cel puin o factur (cardinalitate minim 1); o o magazie poate primi mai multe facturi (cardinalitate maxim n); dinspre entitatea Factur (1, 1) o factura este trimis la cel mult i la cel puin o magazie (cardinalitate 1, 1). Corespondena LINIE FACTUR dinspre entitatea Factur (1, n) o o factur conine cel puin un material (cardinalitate minim 1); o o factur poate conine mai multe materiale (cardinalitate maxim n); dinspre entitatea Material (1, n) o un material este inclus n cel puin o factur (cardinalitate minim 1); o un material poate fi inclus n mai multe facturi (cardinalitate maxim 1); Corespondena LINIE BON DE CONSUM dinspre entitatea Material (0, n) o un material poate s nu fie inclus n nici un bon de consum (cardinalitate minim 0); o un material poate fi inclus n mai multe bonuri de consum (cardinalitate maxim n); dinspre entitatea Bon de consum (1, n) o un bon de consum conine cel puin un material (cardinalitate minim 1); 55

o un bon de consum poate conine mai multe materiale (cardinalitate maxim n). Corespondena DESTINAT dinspre entitatea Bon de consum (1, 1) o un bon de consum este destinat cel puin i cel mult unei magazii (cardinalitate 1, 1) dinspre entitatea Magazie (1, n) o unei magazii i este destinat cel puin un bon de consum (cardinalitate minim 1); o unei magazii i sunt destinate mai multe bonuri de consum (cardinalitate maxim n).
FURNIZOR Cod furnizor 1,n Adresa Banca Cont FACTURA Nr factura Data factura

emite

1,1

0,n

se storneaza 1,1

1,1

1,n LINIE FACTURA cant fact pret fact 1,n MATERIAL Cod material Den mat Unitate mas

MAGAZIE Cod magazie Denumire magazie Gestionar

primeste

1,n

1,1

destinat

1, 1

BON DE CONSUM Nr bon consum 1,n Data Den sectie

0,n Linie bon de comand Cantitatea ieit

Fig. 4.2 Modelul conceptual al datelor Dup realizarea modelului conceptual este necesar s se stabileasc i regulile pe care datele trebuie s le respecte pe tot parcursul prelucrrii. Acestea se numesc restricii de integritate (RI). Ele pot fi structurale i semantice, iar dup momentul n care acioneaz, restriciile de integritate sunt statice i dinamice. Restriciile de integritate structurale sunt inerente conceptelor folosite la modelarea datelor, n timp ce restriciile de integritate semantice sunt introduse de utilizator pentru a reflecta corect realitatea i sunt expresia regulilor de gestiune aplicate n organizaie, fiind o consecin a reglementrilor legislative i normative n vigoare, ct i a reglementrilor i normelor interne. Restriciile de integritate statice vizeaz starea sistemului informatic, independent de timp, iar restriciile de integritate dinamice privesc evoluia n timp a datelor. Restriciile de integritate de domeniu sunt condiii impuse asupra ansamblului de valori

56

acceptate pentru un atribut n cadrul tipului sau domeniului i pot viza: coninutul unui atribut al aceleiai realizri; corelaii ntre valorile mai multor atribute ale aceleiai realizri; corelaii ntre atributele realizrilor mai multor entiti diferite; corelaii ntre realizri distincte ale aceleiai entiti. Exemple de RI: valorile atributelor cu rol de identificator trebuie s fie unice i nenule; existena unei asocieri este condiionat de existena entitilor participante (este vorba de integritatea referenial); cardinalitile minime i maxime se stabilesc pe baza regulilor de desfurare a activitilor n sectorul vizat; Exemplu: Furnizori 0,n emit 1,1 Facturi

cardinalitate minim 0: un furnizor poate exista, chiar dac ntr-o anumit perioad nu a emis nici o factur; cardinalitate maxim 1: orice factur este emis de un furnizor; respectarea unor restricii de domeniu, cum ar fi: data facturii s nu fie anterioar datei curente; greutatea materialelor s fie cuprins n intervalul [0-500] corelaii ntre atributele mai multor entiti sau asocieri diferite, obinute pe baza unor operaii de sintetizare (numrare, nsumare, medie etc.): cantitate facturat<=cantitate_n_stoc +10 Incluziunea de roluri: dac o entitate E joac un rol r1 ntr-o asociere, atunci trebuie s joace i rolul r2 ntr-o a doua asociere. Simbol: r1 r2

Exemplu: Un client poate primi materiale solicitate numai dac a trimis furnizorului respectiv nota contabil. (Fig. 4.3)

57

Client
primete trimite

se trimit

Incluziune de roluri

se primesc

Se trimite Se primete

Materiale

Not comand

Fig. 4.3 Excluziunea de roluri apare n situaia n care rolurile ale aceleiai entiti se exclud reciproc. Simbol: r1 r2
#

Exemplu: O agenie imobiliar are ca obiect de activitate vnzarea - nchirierea de apartamente. Pentru evidena vnzrilor i nchirierilor trebuie s se in seama de faptul c un apartament nu poate fi vndut i nchiriat n acelai timp, deci cele dou roluri ale entitii Apartament se exclud reciproc. (Fig. 4.4)

Apartament
Se vinde Se nchiriaz

#
Conine Nr apart inchiriate Tarif inchirieri Excluziune de roluri Cuprinde Nr apart vndute Pret vnzare

Se ncaseaz

Document ncasare

Se ncaseaz

Fig. 4.4

58

Egalitatea de roluri nseamn o resticie de incluziune reciproc ntre dou roluri ale aceleiai entiti. = Simbol: r1 r2 Exemplu: Un pensionar cu venituri mici pltete intreinerea pentru apartamentul n care locuiete dar n acelai timp primete o subvenie din partea statului pe timp de iarn. Exist egalitate ntre roluri pe care entitatea Pensionar venituri mici le are n cadrul celor dou corespondene.(Fig. 4.5) Pensionar venituri mici
pltete primete

=
pltete
egalitate de roluri

primete

Se reine

Se acord

ntreinerea

Subvenii

Fig. 4.5 Asemntor se stabilesc i restriciile de incluziune, excluziune i egalitatea de asocieri dac exist care vizeaz att asocierea (toate rolurile dintr-o asociere), ct i toate entitile participante. Dependene funcionale Presupunem c am proiectat o relaie cu urmtoarea structur: CLFACTURI(Nrf, Codc, Numec, Adresa, Dataf) Observm dependena atributelor Numec i Adresa fa de atributul Codc, i de aici rezult c fiecare valoare a atributului Codc determin n mod univoc valoarea corespunztoare a celorlalte dou atribute. Aceast structur (schem de relaie) introduce o redundan relativ la atributele Numec i Adresa, ale cror valori se repet pentru fiecare factur a aceluiai client. Aceast redundan conduce la urmtoarele anomalii: la adugare: nu se poate nregistra un potenial client dect dup ce se emite o factur pentru acesta; la tergere: dac se terg toate facturile emise pentru un anumit client se pierd toate informaiile despre acesta; ulterior, dac acesta cumpr nite produse, informaiile pe care tocmai le-am ters trebuie introduse din nou; la modificare: dac se modific o informaie despre un anumit client (numele, adresa), este necesar parcurgerea ntregii relaii pentru a actualiza toate apariiile acestui client; n

59

caz contrar apare pericolul introducerii unei inconsistene n baza de date datorit faptului c pentru acelai client snt nregistrate informaii diferite. Aceste anomalii pot fi evitate dac se descompune relaia CLFACTURI n dou relaii: CLIENTI i FACTURI, avnd structurile: CLIENTI(Codc, Numec, Adresa) FACTURI(Nrf, Codc, Dataf) Un "dezavantaj" al descompunerii efectuate este acela c pentru a obine informaiile despre un client pentru care am emis o factur este necesar efectuarea unei operaii de cuplare a celor dou relaii. Operaia de cuplare (realizat printr-o instruciune Select care extrage informaii din cele dou tabele) nu este att de costisitoare pe ct ar putea prea la prima vedere, dac se aleg n mod corespunztor cheile primare i modalitile de indexare. Dup cum rezult din exemplul de mai sus problema alegerii unui model conceptual corect pentru o baz de date relaional este, de cele mai multe ori, formulat n termenii determinrii unor descompuneri pentru scheme de relaii date, descompuneri care s izoleze dependenele existente i prin aceasta s se evite anomaliile care decurg din ele. Definiia 1. Fie R(A1, A2,..., An) o relaie, X i Y dou atribute (simple sau compuse) submulimi ale mulimii de atribute (A1, A2,..., An). Atributul X determin atributul Y (sau Y depinde funcional de X) i notm XY dac i numai dac orice valoare a atributului X determin n mod unic valoarea atributului Y. Observaii: dac XY atunci pentru orice ZY avem XZ; dac XY atunci pentru orice VX avem VY. Definiia 2. Fie XY o dependen funcional; spunem c avem dependen total dac nici o submulime VX nu induce o dependen funcional VY; n caz contrar, dac exist o submulime VX care induce o dependen funcional VY, spunem c avem dependen parial. Existena n cadrul relaiilor a dependenelor funcionale este un fapt natural. n orice relaie exist o dependen funcional a oricrui atribut fa de atributul cheie (sau setul de atribute care formeaz cheia primar): tim c atributul cheie identific n mod unic fiecare tuplu. Dependenele funcionale existente n cadrul unei relaii se datoreaz semanticii segmentului din lumea real care se modeleaz prin aceast schem i reprezint restricii referitoare la realitatea modelat. Aceste restricii constituie informaii asociate relaiei i care nu pot fi nglobate n reprezentarea relaiei, dei se reflect indirect n aceast reprezentare prin valorile concrete pe care le iau atributele relaiei. Singura cale de a determina dependenele funcionale din cadrul unei scheme de relaie este aceea de a lua n considerare semnificaia tuturor atributelor componente. ntr-o dependenta functionala atributele din partea stanga a sagetii poarta denumirea de atribute determinante iar cele din dreapta sagetii poarta denumirea de atribute determinate.

60

4.5 MODELAREA LOGIC A DATELOR Proiectarea unei baze de date presupune realizarea modelelor conceptual, logic i fizic, prin trecerea succesiv de la un model la altul. Trecere de la MCD, care este un model universal, spre o soluie informatic se face gradat, lund n considerare un anumit tip de soluie i apoi, n cadrul tipului respectiv, o soluie direct implementabil. Expresia MCD n termenii unui anumit tip de soluie informatic constituie modelul logic al datelor (MLD) MLD are asociate principii generale pentru gestionarea, respectiv definirea (structurarea) datelor, manipularea i asigurarea integritii datelor, fr s reflecte modul de reprezentare a acestor date pe suportul de memorare. MLD a cunoscut de-a lungul timpului mai multe generaii, aa cum se poate observa n figura de mai jos (Fig. 4.6):
Fiier

Ierarhizate Reea Relaionale Orientate

MLD
Baze de date SGBD

Fig. 4.6 Fcnd o analiz a modelelor nerelaionale comparativ cu modelul relaional rezult urmtoarele avantaje n favoarea celui din urm: modelul relaional este un model simplu care permite utilizatorului s vad baza de date ca o colecie de tabele (relaii) o reprezentare mental larg accesibil att informaticienilor ct i neinformaticienilor; asigur independena fizic i logic a programelor de prelucrare fa de structura datelor, eliminnd din schema conceptual i shemele externe toate detaliile privind structura de memorare i strategiile de acces; operaia de normalizare introdus de modelul relaional asigur gsirea structurii optime a datelor prin nlturarea anomaliilor de actualizare i diminuare a redundanei. prin introducerea noiunilor de dependen funcional, dependen multivaloare i dependen jonciune modelul relaional depete stadiul limitat al reprezentrii datelor n calculator, avansnd spre formalizarea elementelor de semantic ce guverneaz domeniul informaiilor; suplee n comunicare prin intermediul limbajelor neprocedurale de nivel nalt.

61

MLD se obine aplicnd urmtoarele regulile de trecere de la MCD la MLD: Fiecare entitate devine o relaie. Identificatorul entitii devine cheia primar a relaiei. Atributele entitii devin atribute ale relaiei. Asocierea non-ierarhic devine o relaie. Atributele proprii ale asocierii (dac exist) devin atribute ale relaiei. Identificatorul asocierii.devine cheia primar a relaiei, iar identificatorii entitilor participante la asociere devin chei externe. n cazul n care asocierea nu are atribute, cheia primar se constituie prin concatenarea identificatorilor entitilor participante la asociere. Asocierea ierarhic devine o legtur ntre relaii. Concret, relaia provenind din entitatea pentru care cardinalitile sunt 1,1 absoarbe identificatorul celeilalte entiti, care se transform n cheie extern. Dac se ntmpl ca asocierea s aib proprietate specific, atributul respectiv este transferat i devine cmp al relaiei care provine din entitatea cu cardinalitate maxim 1. Modelul logic al datelor se poate prezenta astfel: scriind numele relaiei, urmat de atributele sale ntre paranteze; cheia primar se subliniaz cu linie continu, iar cheia extern cu linie punctat. Exemplu: Furnizor(Cod furnizor, Denumire furnizor, Adres furnizor, Cod fiscal, Banca,Cont) sau Factur(Numar factur, Data factur; Cod furnizor, Cod magazie) grafic, utiliznd pentru relaie simbolul din MCD pentru entitate, iar pentru evidena legturilor linii orientate; cheile primare i externe se subliniaz la fel ca la punctul a).

Furnizor Cod furnizor Denumire furnizor Adres furnizor Cod fiscal Banca Cont

Factur Numr factur Dat factur Cod furnizor Cod magazie

Exemplu de aplicare a regulilor de trecere de la MCD la MLD S considerm modelul conceptual prezentat n subcapitolul 4.5 Relaiile obinute din entiti sunt: Factur, Furnizor, Magazie, Material, Bon de consum Asocierile non-ierarhice Linie factur, Linie bon de consum se transform n relaii. Relaia

62

Linie factur va avea cheia primar format din concatenarea identificatorilor entitilor participante la relaie (Numr factur, Cod material) i proprietatea specific asocierii Linie factur (Cantitate intrat) care devine atribut al relaiei. La fel se procedeaz i n cazul asocierii Linie bon de consum. Asocierile ierarhice Emite, Primete, Destinat se transform n legturi i transfer cheile primare ctre relaiile provenite din entiti pentru care cardinalitile sunt 1,1. Astfel, asocierea Emite transfer din relaia Furnizor cheia primar Cod furnizor n relaia Factur pe post de cheie extern. Modelul logic se va prezenta astfel: Furnizor (Cod furnizor, Denumire furnizor, Adres furnizor, Cod fiscal, Banca,Cont) Factur (Numar factur, Data factur, Cod furnizor, Cod magazie) Magazie (Cod magazie, Denumire magazie, Gestionar) Linie factur (Numar factur, Cod material, Cantitate intrat) Material (Cod material, Denumire ) Linie bon de consum (Nr bon de consum, Cod material, Cantitate ieit) Bon de consum (Nr bon de consum, Data bon de consum, Denumire secie, Cod magazie)

5. PROIECTAREA SISTEMELOR INFORMATICE

Principii de fundamentare a sistemelor informatice Proiectarea sistemelor informatice se fundamenteaz pe un ansamblu de principii menite s asigure ndeplinirea funciilor sistemului informatic cu maximum de eficien economic i managerial. Aceste principii sunt: 1. Abordarea global modular n cadrul proiectrii unui sistem informatic pentru un anumit domeniu, trebuie studiate i legturile acestuia cu lumea exterioar, nglobarea sa ntr-un domeniu mai larg, aceasta n vederea unei dezvoltri ulterioare, a compatibilitii cu alte sisteme pentru domeniile conexe, ncluderea ntr-un sistem mai complex etc. Nu este bine s se proiecteze sisteme izolate, de aceea trebuie studiat sistemul n ansamblul su (de exemplu unitatea economic) chiar dac se informatizeaz numai anumite activiti din domeniul respectiv. Chiar i n interiorul sistemului respectiv trebuie mprite activitile pe subdomenii, n vederea realizrii prioritare a unora dintre acestea. 2. Criteriul eficienei economice Este principalul criteriu care trebuie s stea la baza deciziei de realizare a unui sistem informatic, mai precis costurile de realizare a sistemului informatic nu trebuie s depeasc 63

rezultatele, directe sau ndirecte, ale implementrii i funcionrii sistemului informatic respective. Costurile trebuie considerate n sens general: costul de realizare, de implementare i de exploatare a sistemului. Primele dou dintre acestea sunt calculate doar o singur dat, iar cellalt este un cost periodic (calculat lunar, annual, etc.). De asemenea trebuie luate n considerare nu numai rezultatele imediate sau cele directe. De exemplu, mbuntirea calitii informaiilor primite de conducerea unitii economice, n vederea alegerii deciziilor cele mai avantajoase, poate s nu se regseasc imediat n rezultatele economice (producie mai mare, costuri de producie mai mici, profit mai mare etc.). Rezultatele pot fi de asemenea ca i costurile fixe, obinute o singur dat, sau periodice (lunar, anual etc.). Exist o durat de amortizare a investiiei (un sistem informatic este o investiie), dat de momentul n care totalul rezultatelor depete totalul costurilor. Dei aceast evaluare are n fazele iniiale un caracter estimativ, putnd fi defnitivat numai dup introducerea n exploatare efectiv, aceasta este deosebit de important, deoarece, nu pot fi acceptate dect acele sisteme informatice care au eficien economic cert, iar elementele de eficien constituie un criteriu de baz n selectarea soluiilor aplicate. 3. Corelarea strns a sistemului informaional cu sistemul informatic decizional i cu organizarea structural a organizaiei. Continuarea fireasc a precedentului, acest principiu exprim necesitatea armonizrii structurale i funcionale a sistemului informatic informaional cu celelalte componente majore ale sistemului informatic de management. Pe plan constructiv sistemul informaional trebuie corelat n special cu structura organizatoric, avndu-se n vedere mai ales utilizarea subdiviziunilor organizatorice ale organizaiei, ndeosebi posturile i relaiile organizatorice, pentru culegerea, nregistrarea, transmiterea i prelucrarea informaiilor. Practica firmelor moderne relev, att a unei structuri organizatorice, ct i a unui sistemului informatic raional, impune conceperea sau perfecionarea lor concomitent. n proiectarea structurii este necesar s se in seama c fiecare post reprezint i un emitor i receptor de informaii, c relaiile organizatorice sunt concomitent i circuite informaionale etc. Din punct de vedere funcional, sistemului informatic este necesar s se armonizeze ndeosebi cu sistemului informatic decizional, astfel nct coninutul informaiilor i caracteristicile dimensionale ale fluxurilor informaionale s reflecte necesitile specifice adoptrii de decizii raionale de ctre fiecare manager. Necesitatea armonizrii componentelor sistemului informatic informaional cu componentele sistemului informatic decizional decurge din funcia decizional a informaiilor. 4. Realizarea unitii metodologice a tratrii informaiilor. n vederea asigurrii compatibilitii ntre toate componentele sistemului informatic, a crerii premiselor integrrii depline a informaiilor pe verticala sistemului informatic de management este necesar ca modul de culegere i prelucrare a informaiilor s fie unitar din

64

punct de vedere metodologic. O asemenea abordare confer sistemului informatic informaional un plus de rigurozitate, faciliteaz schimbrile n structura i funcionalitatea sa, precum i controlul managementului asupra funcionrii sale. Un alt avantaj sensibil al unitii metodologice a tratrii informaiilor l reprezint uurarea trecerii la prelucrarea automat a datelor, iar, n cazul existenei sale, faciliteaz extinderea folosirii computerelor i a aplicaiilor informatice. De reinut c implementarea acestui principiu implic apelarea la serviciile unor informaticieni pe tot parcursul procesului de concepere sau perfecionare a sistemului informatic informaional. 5. Obinerea de maximum de informaii finale din fondul de informaii primare. Informaiile primare, al cror volum este de regul limitat, sunt folosite nemijlocit pentru evidena i controlul desfurrii proceselor, ca i pentru luarea unor decizii, cu caracter local, operativ, de ctre ealoanele inferioare ale managementului. Cele mai importante decizii i aciuni ale managementului se fundamenteaz ns pe informaii finale. De aici decurge i necesitatea ca fondul de informaii primare nregistrat ntr-o firm s fie valorificate la maximum, n vederea obinerii celor mai pertinente informaii finale. n vederea satisfacerii acestei necesiti se trece la aplicarea de proceduri informaionale ct mai rafinate, stabilite i selectate n funcie de cerinele proceselor manageriale, astfel nct informaiile finale obinute s asigure o evaluare multilateral a proceselor organizaiei i, concomitent, un temeinic fundament pentru deciziile strategice, tactice i curente. 6. Antrenarea beneficiarului la realizarea sistemului Acest principiu decurge tot din orientarea spre utilizator. Conform lui, viitorul beneficiar trebuie cooptat n activitatea de proiectare i realizarea sistemului informatic (pentru c el decide ce vrea s obin), n felul acesta, pot fi eliminate o serie de neajunsuri nc de la nceput, scutind timp i efort. De exemplu ce s-ar ntmpla dac utilizatorul dorete s ias din ferestre cu tasta ESC, iar noi am implementat n tot sistemul tasta F1 ca tast pentru ieire. Modificrile necesare ar fi majore, la fel i costurile suplimentare. Respectarea acestui principiu aduce i beneficiarului o serie de avantaje: el se familiarizeaz mai repede cu sistemul informatic, cu modul su de lucru, se reduce perioada i costurile de implementare (implementare n paralel). Soluia de informatizare adoptat nu trebuie (pe ct posibil) s fie dependent de structura actual a sistemului supus informatizrii, deoarece la o eventual schimbare a sistemului informatic nu mai este funcional, costurile de reproiectare putnd fi foarte mari. n cazul sistemelor informatice de gestiune economic acest lucru s-ar reduce la independena sistemului n cadrul organizatoric al unitii economice. Ce se ntmpl dac sistemul furnizeaz rezultate de ieire doar la o anumit staie, pentru c doar directorul general poate avea acces la date, iar acesta decide s dea voie i contabilului ef s aib acces la datele respective? Schimbm sistemul? O soluie n acest sens ar putea fi aceea a lsrii configurrii sistemului la ndemna

65

utilizatorului (cu ct mai multe opiuni cu att mai bine), dar aceasta presupune o programare general parametrizabil din exterior. 7. Posibilitatea de dezvoltare ulterioar Lumea este n micare i deci un sistem care nu poate fi dezvoltat risc s moar foarte repede. Dezvoltarea poate implica modificri majore, care este bine a fi prevzute pe ct posibil. De exemplu, se pot lsa lungimi mai mari pentru diferite date, chiar dac momentan se face risip dar n viitor se prevede c datele respective vor fi mai mari. Pe lng principiile descrise mai sus mai exist i altele, poate la fel de importante. O parte decurg din cele deja prezentate iar altele sunt ndependente, rmnnd la latitudinea fiecruia s le aplice pe cele care i se par mai potrivite, mai importante ntr-un anumit context. De exemplu n unele cazuri ar putea fi foarte important portabilitatea, adic facilitatea unui sistem de calcul de a funciona fr modificri pe un alt sistem de calcul. Principiile prezentate, care, firete, c nu sunt exhaustive, se refer la principalele aspecte implicate att de conceperea subsistemelor informaionale pentru ntreprinderile noi, ct i de raionalizarea subsistemelor informaionale ale organizaiilor n funciune. Esenial este ca acestea s fie utilizate concomitent, lund n considerare ansamblul cerinelor implicate n interdependena lor, evitnd supra sau subevaluarea unora dintre acestea. Activitile proiectrii sistemelor informatice Proiectarea sistemelor informatice se bazeaz pe rezultatele obinute din analiza i interpretarea modelelor noului sistem informatic. Analitii evalueaz i revizuiesc modelele pentru a obine specificaiile logice de sistem, specificaii care descriu n detaliu funciile sistemului informatic i care vor sta la baza soluiilor tehnice alese de proiectant. n funcie de strategia de proiectare aleas: proiectare structurat, proiectare orientat obiect, prototipizarea, JAD (Join application development), RAD (Rapid application development), activitile de proiectare difer de la o metodologie la alta. Astfel, conform metodologiei MERISE, proiectarea sistemului informatic se face pe subansambluri ale domeniilor ce urmeaz a fi informatizate, pentru fiecare subansamblu realizndu-se un studiu detaliat i un studiu tehnic. Studiul detaliat se bazeaz pe rezultatele investigrii i presupune obinerea specificaiilor funcionale generale detaliate ale noului sistem. Specificaiile cuprind: Schema organizatoric; Prezentarea activitilor, proceselor din cadrul unitii economice; Prezentarea procedurilor utilizate pentru realizarea procedurilor; Prezentarea sarcinilor manuale, total sau parial automatizate; Lista resurselor umane i materiale implicate cu alocarea pe sarcini; Prezentarea situaiilor de ieire; Lista echipamentelor utilizate.

66

Studiul tehnic presupune proiectarea logic i tehnic a bazei de date, descrierea arhitecturii prelucrrii datelor, descrierea arhitecturii produsului program. Metodologia OMT, care utilizeaz un set de concepte orientate pe obiecte i care este i cea mai utilizat metodologie orientat obiect, realizeaz o proiectare a sistemului informatic i o proiectare a obiectelor. Proiectarea sistemului informatic presupune realizarea urmtoarelor activiti: Descompunerea n subsisteme informatice. Subsistemele informatice obinute sunt formate dintr-un ansamblu de operaii, evenimente, asocieri, mesaje, avnd o interfa fix cu restul sistemelor. Identificarea subsistemelor informatice concurente. Subsistemele informatice concurente sunt identificate n scopul optimizrii implementrii prin utilizarea aceleai platforme hardware. Stabilirea necesarului de resurse i a modului de implementare hardware i software pentru fiecare subsistem. Alegerea modului de organizare a datelor i a tipurilor de acces la date. Stabilirea controlului intern i extern pe fluxul evenimentelor sau pe fluxul prelucrrilor. Stabilirea condiiilor limit, care se refer la iniializri, terminarea normal sau anormal, prioriti. Rezultatul proiectrii sistemului informatic const n realizarea arhitecturii de baz a sistemului informatic i elaborarea unor decizii la nivel global. Proiectarea obiectelor rafineaz modelele obinute n faza de analiz, prin adugarea detaliilor de implementare. n cadrul acestei etape se desfoar urmtoarele activiti: identificarea operaiilor; proiectarea algoritmilor; rafinarea, restructurarea modelului datelor; implementarea controlului; implementarea asocierilor; gruparea datelor i asocierilor n module. Rezultatul acestei etape este detalierea celor trei modele: modelul obiectelor, modelul dinamic i funcional. Se poate observa c, indiferent de strategia de proiectare adoptat, activitile principale pentru proiectarea unui sistem informatic sunt: stabilirea arhitecturii sistemului informatic /subsistemului informatic; proiectarea listelor / situaiilor de ieire; proiectarea bazei informaionale; proiectarea interfeei cu utilizatorii; proiectarea programelor. n literatura de specialitate, aceste activiti sunt grupate, conform gradului de detaliere, n dou categorii , care reprezint de fapt, etapele proiectrii sistemelor informatice: proiectarea de ansamblu / general / logic i proiectarea de detaliu / fizic.

67

n cadrul proiectrii de ansamblu / generale / logice se elaboreaz modelul de ansamblu a sistemului informatic, adic se stabilete ce trebuie sa se construiasc i care sunt specificaiile logice ale sistemului informatic. Proiectarea de detaliu / fizic detaliaz componentele sistemului informatic, arat cum trebuie s fie construite i cum s funcioneze n mediul real, n funcie de resursele disponibile. 5.2 Proiectarea arhitecturii sistemului informatic Arhitectura sistemului informatic definete tehnologiile folosite, ansamblului de date, procese, interfee i componente de reea folosite. cu specificarea

Necesitatea utilizrii mai multor baze de date n acelai timp, accesul la programe i baze de date de la distan, necesitatea interconectrii sistemelor informatice de la nivel de concern cu cele de la firmele filiale, comunicarea prin pota electronic, ntlnirile virtuale (videoconferine) a dus la apariia sistemelor distribuite. Putem defini un sistem distribuit ca fiind un ansamblu de resurse fizice i logice de calcul autonome, interconectate, care coopereaz n mod transparent pentru realizarea funciunilor de control i prelucrare. Proiectarea arhitecturii sistemului informatic distribuit ncepe cu alegerea tipului reelei i a protocolului de comunicaii, urmat de proiectarea distribuirii aplicaiilor, datelor i a catalogului de date. Alegerea tipului reelei de calculatoare Bazele de date distribuite au ca suport fizic reelele de calculatoare, deoarece datele se afl n locuri diferite (pe servere sau staii diferite), iar pentru exploatarea lor este nevoie de legturi fizice (cabluri, antene, satelii etc.). Sistemul informatic distribuit este un caz particular de reea de calculatoare, al crui software ofer un nivel ridicat de coeren i transparen. Astfel, un sistem informatic distribuit este perceput de utilizator ca un procesor virtual, fr a ti c, din punct de vedere fizic, exist mai multe procesoare. Alocarea procesoarelor, ncrcarea fiierelor pe discuri, mutarea fiierelor ntre locul de stocare i cel de utilizare etc. se execut n mod automat. n cazul unei reele, utilizatorul trebuie s lanseze cerinele n mod explicit (pe care main, ce fiier). Arhitectura Client / Server Arhitectura client/server se constituie ca o infrastructur versatil, bazat pe mesaje i modular, ce s-a nscut din intenia mbuntirii utilizabilitii, flexibilitii, interoperabilitii i scalabilitii aplicaiilor software. Clientul este definit ca un solicitant de servicii, iar server-ul este definit ca un furnizor de servicii innd seama de faptul c una i aceeai staie poate fi i client, i server n funcie de configuraia software. Clientul i server-ul comunic prin schimb de mesaje. Istoric vorbind, evoluia tehnologic de la sisteme centralizate spre client/server a trecut 68

printr-o etap intermediar numit arhitectura file/server. La originea lor, reelele de PC uri se bazau pe descrcarea pe staia de lucru a fiierelor de pe server i efectuarea tuturor prelucrrilor locale. Problema de baz a unei asemenea arhitecturi era incapacitatea deservirii simultane a mai mult de 12 utilizatori. Ca rspuns la limitrile conceptului file /server a aprut arhitectura client / server iar server-ul de fiiere a fost nlocuit de un server de baze de date ce are la baza un SGBD dotat cu un proces suplimentar care ascult cererile clienilor i le rspunde n mod direct (fig. 5.1)
Servere de fiiere

Fiiere de date i executabile

Fiiere Index

Cerere
Aplicaie client

Rspuns

Fiiere de date i executabile Fiiere Index

Server BD

Fig. 5.1 Arhitectura file/server i client/server

n general, clienii sunt calculatoare personale (PC-uri) utilizate pentru activiti de gestionare a datelor. Dup inha, un post client se caracterizeaz prin faptul c : prezint o interfa utilizator, care e, de obicei, grafica (GUI); formuleaz interogri (cereri, consultri) sau comenzi pe care le nainteaz serverului; transmite interogrile / comenzile respective server-ului prin intermediul unei tehnologii de comunicaie; analizeaz datele din rezultatele interogrilor / comenzilor primite de la server; iar un server prin faptul c: furnizeaz un serviciu clientului; rspunde la interogrile / comenzile clientului; ascunde detaliile sistemului informatic client /server, fcnd transparent dialogul dintre client i server. Serverele pot fi calculatoare personale sau sisteme de calcul specializate (minicalculatoare, mainframe-uri) n vederea asigurrii legturii dintre clieni i bazele de date din care se extrag informaiile dorite. Scopul principal este autonomia informatic a fiecrui angajat, n limita unor atribuii delegate, angajat care poate astfel consulta i prelucra datele din orice loc aflat in interiorul sau n exteriorul ntreprinderii. Arhitectura client / server are la baza patru elemente.

69

Delimitarea net dintre serviciile de prezentare i cele de manipulare a informaiilor. Flexibilitate, n ceea ce privete dezvoltrile ulterioare implementrii. Punerea n funcie a unui mecanism de asigurare a securitii i integritii pentru datele rezidente pe servere. Arhitectura deschis n sensul federalizrii unei multitudini de platforme (mainframe, mini, micro - calculatoare) i de produse (echipamente i aplicaii - program) ale diferiilor actori de pe piaa tehnologiei informaionale. Orice sistem client/server este alctuit din minimum trei componente principale: interfaa cu utilizatorul (sistemul de operare mediu / grafic) aplicaia (prelucrrile sau procesele) sistemul de gestiune a bazelor de date Alegerea protocolului de comunicaii. n cazul unei aplicaii distribuite comunicaia se realizeaz n jurul unei triunghi informatic (fig. 5.2), n care utilizatorul dispune de o staie de lucru, iar aplicaiile fac apel la servere de prelucrare i la servere de date.

Fig. 5.2 Triunghiul informatic. Pentru evitarea multiplicrii soluiilor de interconectare a sistemelor care au la baz arhitecturi eterogene, ISO (International Standards Organization) a dezvoltat modelul de referin OSI. Acest model permite interconectarea sistemelor de origini diferite, dar care respect reguli standard care sunt formalizate prin protocoale. Protocoalele se refer la modul n care trebuie s se efectueze comunicaiile. Sistemele care rspund cerinelor modelului OSI sunt considerate sisteme deschise. Modelul de referin OSI nu se refer la arhitectura intern a sistemelor i are apte niveluri, i anume: nivelul fizic - realizeaz funciile legate de gestiunea i exploatarea suporturilor fizice de comunicaie: interfee mecanice i electrice, proceduri de recepie i emisie sistemului informatice a informaiei binare, adaptarea semnalelor la suport etc.; nivelul legtura de date - genereaz cadrele ce vor fi transmise prin nivelul fizic i asigur detecia i corecia erorilor de transmise; nivelul reea a sistemului informatic asigur direcionarea (rutarea) informaiei n traversarea reelei realiznd funcii de stabilire i ntrerupere a comunicaiilor; 70

 nivelul transport a sistemului informatic asigur controlul transferului de date punct la punct n traversarea reelei; nivelul sesiune - realizeaz funciile care sunt necesare ca suport al dialogului dintre procese, cum ar fi iniializarea, sincronizarea i terminarea dialogului; nivelul prezentare - definete semantica i sintaxa datelor care se vor schimba; nivelul aplicaie - ofer utilizatorului mijloacele necesare de acces la mediul OSI, preocuparea sa major fiind legat de semantica aplicaiei. Acest nivel definete mecanisme i protocoale specifice (pot electronic, transferul fiierelor etc.). Arhitectura TCP/lP a fost anterioar modelului de referin OSI/ISO, fiind denumit astfel dup numele celor mai importante dou protocoale: TCP (Transmission Control Protocol) i IP (Internet Protocol). n general, descrierile pentru TCP/IP definesc o arhitectur de protocoale care comport de la trei la cinci niveluri funcionale. Reprezentarea prin patru niveluri funcionale (Nivelul Aplicaie, Nivelul Transport, Nivelul Internet, Nivelul Acces Reea), relativ independente, constituie modelul cel mai utilizat. Motivul principal al proiectrii arhitecturii TCPlP a fost realizarea unei interconexiuni de reele care s ofere servicii de comunicaie universale. Dup adoptarea TCP/IP ca standard, n anul 1983, termenul de lnternet s-a impus treptat in limbajul curent. Transmisia n reele poate fi fcut fie prin suporturi fizice (dispozitive magnetice, cablul torsadat, cablul coaxial n band sau fibr optic), fie fr un suport material (unde radio, microunde, raze infraroii, raze laser)

5.3 Proiectarea de ansamblu / general / logic Proiectarea de ansamblu i propune s defineasc sistemul informatic din punct de vedere funcional i structural. Aceasta nseamn c se identific componentele, dup care se vor descrie att din punct de vedere structural, ct i funcional. Structura de ansamblu a unui sistem informatic e format din intrri, ieiri i prelucrri. (fig. 5.3)
Intrari

PRELUCRRI Proceduri SGBD

Iesiri

Documente justificative

Rapoarte

Proceduri
Fig. 5.3

Intrrile sunt reprezentate de:

71

 tranzacii externe care redau dinamica operatiilor economice, provin din exteriorul sistemului informatic electronic de calcul i sunt furnizate de proceduri automate. Exemplu: nregistrarea unei operaii de aprovizionare cu marf; tranzacii interne care redau modificrile structurale din cadrul bazei de date; sunt asigurate exclusiv n cadrul sistemului informatic prin intermediul procedeului de exploatare sau de actualizare a bazei de date. Exemplu: totalul facturilor primite de la un furnizor care actualizeaz soldul furnizorului respectiv. Prelucrrile sunt asigurate de un ansamblu de proceduri automate care realizeaz actualizarea i exploatarea coleciilor de date ca urmare a tranzaciilor interne i externe n vederea obinerii rapoartelor, listelor, situaiilor de ieire ale sistemului informatic. Ieirile sistemului informatic sunt rezultatul prelucrrii bazei de date i sunt redate n funcie de coninutul lor i de structura lor sub form de indicatori sintetici, rapoarte, liste, situaii de ieire, grafice, stocare pe suporturi. Schema structural a unui sistem informatic pune n eviden triada intrri prelucrri ieiri. Pentru determinarea necesarului de date de intrare se utilizeaz mai multe metodologii care determin anumite variante de abordare a proiectrii de ansamblu. Astfel, n funcie de complexitatea obiectivelor stabilite, de aria de cuprindere a noului sistem informatic, de posibilitile de modificare a ieirilor, de costurile i termenele de realizare a sistemului informatic, se folosesc urmtoarelor variante de abordare a proiectrii de ansamblu: Prima varianta de abordare, pe baza principiului ieiri-intrri asigur determinarea coninutului bazei informaionale n funcie de obiectivele stabilite de unitatea beneficiar. n aceast variant ieirile sunt reflectate de obiectivele informaionale solicitate, n timp ce intrrile sunt reflectate de coninutul bazei informaionale. Avantajul acestei metode const n furnizarea unui coninut complet al bazei informaionale determinat iniial i pe baza stabilirii listelor de ieire. Dezavantajul este legat de imposibilitatea emiterii de noi situaii de ieire, deoarece varianta nu poate genera la ieire dect coninutul bazei informaionale De asemenea, nu poate genera ali indicatori rezultai ca urmare a aplicrii unui algoritm de calcul asupra coninutului bazei informaionale. A doua variant, pe baza principiului intrri - ieiri determin coninutul bazei informaionale independent de ieirile solicitate urmnd s se asigure att cerinele imediate ct de perspectiv. Avantajul const n determinarea unei baze informaionale complete, cu meniunea ns c unele atribute nu vor fi poate niciodat utilizate n prelucrrile sistemului informatic. Dezavantajul rezid din cheltuielile mari de realizare a bazei informaionale, cheltuieli determinate de studierea tuturor activitilor desfurate i de supradimensionarea acesteia. A treia variant, mixt mbin avantajele celor dou variante prezentate i le minimizeaz dezavantajele.

72

n practica economic, datorit vehiculrii unui numr foarte mare de documente de intrare, la proiectarea sistemelor informatice se folosete varianta de abordare pe baza principiului ieiri - intrri Activitile desfurate n cadrul proiectrii de ansamblu sunt: stabilirea obiectivelor noului sistem informatic. proiectarea rapoartelor, listelor, situaiilor de ieire proiectarea bazei informaionale. Stabilirea obiectivelor sistemului informatic Obiectivele sistemului informatic reprezint scopuri imediate i de perspectiv care vor determina structura, funcionalitatea i conexiunile noului sistem informatic i care vor asigura minimizarea perturbaiilor aprute n desfurarea activitilor, contribuind astfel la maximizarea eficienei economice i a rentabilitii unitii beneficiare. Determinarea obiectivelor noului sistem are la baz ideea potrivit creia acest sistem este dedicat procesului decizional, deoarece numai cu un management performant se pot obine efecte economice ridicate, cu eforturi ct mai reduse. Din acest motiv, obiectivele unui sistem informatic pot fi grupate n dou categorii: Obiective generale ce trebuie s asigure cunoaterea exact i operativ a activitii desfurate de unitatea economic; Obiective specifice care vor sigura condiiile necesare realizrii obiectivelor generale. Obiective generale Obiectivele generale ale unui sistem informatic urmresc generarea i furnizarea operativ i selectiv, ctre toate nivelele de conducere, a unor date cu caracter strategic, tactic, operativ i funcional, pentru asigurarea atributelor conducerii i ale funciilor unitilor economice. n raport de aceste aspecte, obiective generale pot fi: de conducere (manageriale); funcionale. Obiectivele de conducere vizeaz probleme cu caracter global i structural, de conducere ale unitii economice i se axeaz pe: realizarea n condiii de maxim eficien a ntregii activiti; realizarea global i structural a indicatorilor economico-financiari (cifra de afaceri, valoarea adugat, profitul brut i net, capitalul propriu, capacitatea de plat, rata rentabilitii, eficiena utilizrii fondurilor fixe etc.), calculul i planificarea rezultatelor, planificarea financiar a investiiilor, previzionarea activelor circulante i a surselor de finanare, previzionarea activitii de trezorerie, inclusiv utilizarea bugetului general al unitii economice; perfecionarea structurilor i a activitii de producie n vederea asigurrii unui optim global; asigurarea unui fundament informaional superior pentru fundamentarea i implementarea strategiilor i politicilor unitii economice; 73

 realizarea unei funcionaliti superioare de ansamblu a sistemului decizional; facilitarea introducerii i utilizrii anumitor tehnici, metode i sisteme manageriale; degrevarea conducerii de procesele decizionale de rutin, formalizarea prin noul sistem a informaiilor sintetice necesare derulrii relaiilor informaionale cu organismele de stat i cu alte regii autonome sau societi comerciale; creterea operativitii i gradului de fundamentare i adoptare a deciziilor. Obiectivele funcionale au n vedere informatizarea activitilor eseniale i specifice ale unitii economice n vederea asigurrii funciilor sale fundamentale: cercetare-dezvoltare, comercial, producie sau exploatare, financiar- contabilitate, personal. 1. Activitatea de cercetare-dezvoltare vizeaz strategiile de dezvoltare a produselor i tehnologiilor precum i cele de dezvoltare a unitii economice n ansamblul su. Informatizarea acestor activiti presupune informatizarea urmtoarelor subactiviti: proiectare produselor; proiectarea n domeniul tehnologiilor i echipamentelor; determinarea capacitii de producie i utilizare eficient a acesteia; elaborarea normativelor i normelor de consum pentru resurse materiale i energetice; elaborarea normativelor i normelor de munc i a consumurilor specifice de manoper. 2. Activitatea de producie desfurat n cadrul unor compartimente are n vedere elementele specifice fiecrei subactiviti, din punct de vedere informatic, dup cum urmeaz: definirea ingredientelor i proceselor ce sunt utilizate n producia continu; definirea seciilor, operaiilor i ordonarea lor, care intervin n fabricarea unui produs; definirea materialelor i (sub)ansamblelor folosite pentru fabricarea unui produs; gestiunea calitii; previziunea produselor; program de producie; planificarea cerinelor materiale; planificarea cerinelor capacitii; planificarea cerinelor de manoper; planificare resurse. 3. Activitatea comercial este reprezentat prin trei subactiviti: aprovizionare, desfacere, marketing. Sistemul informatic va trebui sa soluioneze optim urmtoarele aspecte specifice: Subactivitatea de aprovizionare determinarea necesarului de resurse materiale i energetice; contractarea necesarului de aprovizionat. Subactivitatea de desfacere situaia necesarului de livrat conform contractelor; situaia cantitativ i valoric a livrrilor ; urmrirea ritmicitii livrrilor n scopul onorrii contractelor. Subactivitatea de marketing

74

 studierea caracteristicilor tehnico-economice, inclusiv a tehnicilor de comercializare a produselor concurente, furnizate de alte societi comerciale din tar sau strintate; evoluia pieelor de desfacere n vederea realizrii relaiilor valutar-financiar i de distribuire a produselor proprii; cooperarea cu alte societii comerciale din ar sau strintate n vederea promovrii produselor pe tere piee 4. Activitatea financiar-contabil desfurat n cadrul compartimentelor specifice presupune rezolvarea din punct de vedere informatic a unor elemente specifice dup cum urmeaz: Subactivitatea financiar elaborarea bugetului general al unitii economice pe an financiar, i desfacere pe subuniti. gestiunea creditului clieni pune n eviden sumele datorate de clieni, ce rezult din datele generate de cumprrile i plile acestuia; gestiunea numerarului colecteaz informaii privind toate intrrile i ieirile de numerar din organizaie, n mod periodic sau chiar n timp real. gestiunea portofoliului (titlurilor) de plasament evideniaz surplusul de numerar investit n hrtii de valoare pe termen scurt (fie cu un grad de risc sczut-bonuri de tezaur, certificate de trezorerie, fie cu un grad de risc mai ridicat dar i cu posibiliti mai mari de ctig), astfel nct sumele rezultate s poat fi disponibile atunci cnd sunt necesare fonduri. Subactivitatea contabil se desfoar n dou circuite: Contabilitatea financiar (sintetic), reflect starea patrimonial a unitii economice prin intermediul activului, datoriile (obligaiile), capitalul propriu i rezultatele nete obinute pe parcursul unei perioade de gestiune. Contabilitatea de gestiune (analitic), ofer informaii care reflect cheltuielile i veniturile pe purttori de valoare i resursele repartizate spre gestionarea la nivelul fiecrei structuri organizatorice. Subactivitatea de control financiar, la nivelul unitii economice urmrete analiza i controlul gestiunii patrimoniului regiei automate sau societii comercial prin instrumente proprii, n scopul prevenirii i sesizrii nclcrii normelor legale de utilizare a resurselor umane, materiale i bneti. 5. Activitatea de personal acoper ntreaga gam de activitii legate de evidena personalului, salarizarea, perfecionarea calificrii personalului i presupune rezolvarea sub aspect informatic a urmtoarelor sarcini: Subactivitatea de eviden a personalului trebuie s asigure: evidena personalului pe meserii, n funcie de vechime, pe locuri de munc, pe diferite intervale de timp; verificarea ncadrrii personalului pe meserii, funcii i locuri de munc; evidena micrii de personal (angajrii, promovri, transferri, pensionari, concedii)

75

Subactivitatea de salarizare asigur: nregistrarea orelor lucrate pe baza fielor de partaj sau a foilor colective de prezen, prin care se determin numrul orelor care va fi luat n calcul la stabilirea salariilor pentru o lun. Poate s apar situaia n care se vor folosi fiele de manoper; calculul drepturilor salariale se particularizeaz n funcie de modul de plat al fiecrei organizaii; -evidenierea obligaiilor de plat ale salariailor, fie sub forma impozitelor i contribuiilor fie sub forma reinerilor datorate ctre firme sau bnci. Subactivitatea de perfecionare a calificrii personalului se particularizeaz de la o firm la alta, n funcie de specificul obiectivului de activitate i de criteriile de evaluare stabilite la nivelul politicii de personal i urmrete: performanele salariailor, pe faza unor criterii de evaluare stabilite n funcie de specificitatea activitii desfurate. Pe baza evalurilor de performane conducerea poate stabili nivelul salariului pentru fiecare angajat, posibilitatea de promovare, necesitile de instruire .a. nregistrarea pregtirilor profesionale i a instruirilor la care au participat salariaii, urmrindu-se prelucrarea datelor necesare elaborrii programului de mbuntire a aptitudinilor i performanelor profesionale ale salariailor; stabilirea prioritilor n angajarea a noi categorii de salariai, astfel nct activitatea unitii economice s se desfoare, la cel mai nalt grad de tehnicitate. Obiectivele specifice Obiectivele specifice asigur condiiile realizrii obiectivelor generale i trebuie s in seama de aspectele concrete din realitatea unitii economice studiate, cum ar fii: mrimea unitii economice; structura sa organizatoric; ponderea acesteia ntr-o ramur de activitate; gradul de participare al unitii economice la derularea operaiunii de export-import, cooperarea internaional; alte elemente ce pot conduce la alte tipuri de obiective cu o nuanare specific. Proiectarea rapoartelor/listelor/situaiilor de ieire Datele de ieire sunt informaii livrate de sistemele de prelucrare autonom a datelor utilizatorului sub forma unor mesaje, rapoarte, grafice etc. Ieirile noului sistem informatic sunt stabilite de ctre conducerea unitii economice, n colaborare cu echipa de realizare a sistemului, ca urmare a analizei obiectivelor sistemului proiectat, n proiectarea lor inndu-se seama de urmtoarele aspecte: 1) Destinaia situaiei i momentul cnd se estimeaz, se poate obine nivelul de detaliere al informaiei, respectiv informaii mai analitice pentru nivele de baz i mai sintetice la nivelele

76

superioare. 2) Existena n situaie a tuturor informaiilor necesare, avndu-se n vedere n acelai timp, ca pe ct posibil, o informaie s nu apar inutil n mai multe situaii. Structura informaional i formatul ieirii sunt determinate, n principiu, de urmtoarele reguli: respectarea specificaiilor cadrului legislativ n vigoare proiectarea se va face n concordan cu activitile specifice obiectivelor sistemului; coninutul va fi redat sintetic sau analitic i cu o frecven precizat n legislaie; Formatul de afiare, dispozitivul periferic folosit i beneficiile ieirilor sistemului informatic sunt stabilite n raport cu solicitrile sistemului de management, sistemului operant, sistemelor informatice externe. Criteriile utilizate pentru determinarea formatului, coninutului, dispozitivului periferic i beneficiarilor ieirilor noului sistem, au impus structurarea acestora n urmtoarele categorii: A. Rapoartele/listele/situaiile de ieire conin indicatori sintetici i analitici, al cror coninut reflect starea, dinamica i tendina fenomenelor i proceselor economice ce fac obiectul procesului de prelucrare a datelor din sistemul proiectat. Reprezentarea datelor se face, de regul , n format de tabel. Anumite rapoarte au formatul stabilit prin respectivul cadru legal. B. Indicatorii sintetici redau fenomene i procese economico-financiare prin intermediul unor date succinte utilizate n special informrii operative i demersului decizional. C. Graficele redau sub form sinoptic starea i evoluia unui fenomen economicofinanciar n scopul informrii conducerii sau compartimentelor unitii economice, adoptrii unor decizii operative, prin care s asigure fenomenul de feed back al activitii economicofinanciare analizate. D. Ieirile ctre alte sisteme sunt de fapt transmisii de date on-line, prin intermediul unei reele locale de calculatoare, sau off-line, prin intermediul suporturilor magnetice(disc flexibil, disc magnetic, band magnetic). 3 Proiectarea bazei informaionale Baza informaional conine nucleul informaional format din totalitatea atributelor necesare prelucrrilor specifice sistemului informatic i structura informaional reprezentat de entiti ntre care se stabilesc corespondene i legturi. Proiectarea bazei informaionale presupune: A. Determinarea coninutului bazei informaionale i a algoritmilor utilizai; B. Determinarea structurii bazei informaionale. C. Normalizarea relaiilor

A. Determinarea coninutului bazei informaionale i a algoritmilor utilizai 77

Coninutul bazei informaionale se determin n funcie de variantele de abordare a proiectrii generale alese. n varianta ieiri-intrri coninutul bazei informaionale se determin n funcie de obiectivele propuse concretizate n situaiile de ieire. Baza informaional se va constitui pe baza ieirilor solicitate i va fi modificat pe tot parcursul exploatrii sistemului n concordan cu dinamica fenomenelor i proceselor din unitatea beneficiar. Aceast variant se aplic n cazul realizrii sistemelor informatice mari i mijlocii caracterizate printr-o complexitate ridicat a ieirilor informaionale i implicit a obiectivelor avute n vedere. n varianta intrri-ieiri coninutul bazei informaionale presupune cunoaterea datelor de intrare i dinamismul ieirilor solicitate. Se aplic n cazul realizrii sistemelor informatice de dimensiuni mici. Sistemele informatice din domeniul economic presupun realizarea unor obiective delimitate i fundamentate n strns legtur cu cadrul legislativ-normativ care impune natura ieirilor informaionale, motiv pentru care n majoritatea cazurilor determinarea coninutului i structurii bazei informaionale se face pe varianta ieiri-intrri. Determinarea coninutului bazei informaionale prin varianta ieiri-intrri presupune studierea mulimii atributelor din situaiile de ieire n funcie de modul de obinere n urma prelucrrii automate. Atributul este o proprietate a unei entiti, a unui grup de entiti sau a unei corespondene dintre acestea. Prin intermediul atributelor, entitatea poate fi descris din punct de vedere informaional - ca o component distinct a structurrii bazei informaionale de intrare. n aceast viziune, atributul poate fi considerat ca o variabil, creia i se poate asocia o mulime de valori prin intermediul unui indicator comun. Atributele sunt reflectate printr-un coninut concret denumit valoare, care red nivelul real al fenomenelor i proceselor economice cuantificate prin intermediul entitii. Atributele bazei informaionale de intrare pot fi privite din punct de vedere structural i al stabilitii n timp. a) Din punct de vedere structural atributele pot fi elementare i compuse. Atributele elementare sunt componente informaionale deductibile ce nu mai pot fi descompuse n alte atribute (de exemplu.: cod-mat, den-mat, pre, stoc-init). Atributele compuse sunt componente informaionale reductibile ce pot fi descompuse n atribute elementare (de exemplu.: atributul data-stoc poate fi descompus n atributele elementare zi-stoc, luna-stoc, an-stoc). b) Din punct de vedere al stabilitii n timp atributele pot fi constante, variabile i de stare. Atributele constante i menin valoarea neschimbat o perioad determinat fiind invariabile n timp, n raport de semantica atributului din baza informaional de intrare (de exemplu: cod-furn, nr-contr, cod-prod, cod-um,preul etc). 78

Atributele variabile i schimb valoarea pe parcursul existenei bazei informaionale de intrare fiind variabile n timp n funcie de semantica atributului (de exemplu.: nr-doc, data-doc etc,). Atributele de stare i schimb valoarea numai la anumite intervale de timp, ale existenei bazei informaionale de intrare prin modificarea atributelor constante, variabile sau chiar de stare (de exemplu stoc-init, stoc - final, sold - db, sold - cr etc). ). Pentru proiectarea corect a coninutului bazei informaionale este necesar ndeplinirea concomitent a urmtoarelor condiii: mulimea atributelor de ieire este format din submulimea atributelor preluate reunit cu submulimea atributelor calculate; submulimea operanzilor primari intersectat cu submulimea atributelor preluate corespunde atributelor comune ce se gsesc n ambele submulimi; submulimea atributelor de intrare este reprezentat corect de nucleul informaional ce constituie coninutul bazei informaionale. B. Determinarea structurii bazei informaionale Structura bazei informaionale de intrare reprezint gruparea coninutului acestuia (atributele de intrare ntr-un ansamblu de entiti inclusiv corespondenele (legturile) dintre acestea). Structura bazei informaionale de intrare este efectuat prin intermediul unui model de reprezentare care asigur independena logic i fizic a prelucrrilor fa de coleciile de date n care va fi transpus baza informaional. Aceast proprietate asigur implicit independena relativ a proiectrii generale fa de soluiile tehnice adoptat n cadrul proiectrii de detaliu. n mod concret, gruparea atributelor de intrare n entiti informaionale i reflectarea corespondenelor (legturilor) dintre acestea se realizeaz gradat printr-un proces de modelare ce permite definirea riguroas a structurii bazei informaionale. Acest proces de modelare are la baz modelul de reprezentare entitate atribut coresponden. Acest model consider baza informaional de intrare ca un ansamblu finit de entiti informaionale, caracterizate n mod unic, printr-o mulime specific de atribute i un ansamblu de corespondene (legturi) stabilite ntre entiti sau chiar n interiorul acestora. n acest context corespondenele pot fi definite ca asocieri ntre realizrile aceleiai entiti sau realizrile entitilor diferite. C. Normalizarea relaiilor Procesul de normalizare a relaiilor este util n activitatea de proiectare a structurii logice i a bazei de date relaionale i const n eliminarea neajunsurilor ce apar n exploatarea efectiv a bazei de date, neajunsuri introduse de dependente incorecte, existente ntre datele relaionale. Din punctul de vedere al influenei asupra performanelor n exploatare a bazei de date, normalizarea afecteaz negativ eficiena cu care snt rezolvate interogrile. Aceasta pentru c informaiile care ntr-o baz de date nenormalizat ar putea fi regsite ntr-o singur relaie, n cazul unei baze normalizate necesit, de cele mai multe ori, cuplarea a dou sau mai multe

79

relaii. De aceea normalizarea este considerat necesar i util doar n ipoteza c operaiile de adugare, tergere i actualizare snt frecvent utilizate. Aadar normalizarea mbuntete integritatea datelor prin reducerea redundanei i a inconsistenei n detrimentul eficienei unor operaii de regsire a datelor. E. F. Codd a artat ca ntr-o anumit form relaiile posed proprieti nedorite pe care lea numit anomalii de actualizare i le-a structurat astfel: anomalii de tergere se refer la faptul c tergnd un tuplu dintr-o tabel, pe lng datele ce trebuie eliminate se terg i cele necesare. anomalii de adugare constau n faptul c anumite date noi care trebuie introduse ntr-o tabel fac parte din tupluri incomplete, motiv pentru care nu pot fi introduse. anomalii de modificare semnific faptul ca e dificil de schimbat o valoare a unui atribut cnd ea apare n mai multe tupluri ale relaiei. Pentru a elimina aceste anomalii Codd a stabilit trei forme normale pentru relaii i a introdus noiuni de normalizare care se bazeaz pe dependena funcional ntre atributele unei relaii. Ulterior, ali cercettori au mai completat formele normale Codificarea atributelor Activitatea de codificare trebuie s realizeze corelaia ntre specificul activitii unitii beneficiare i particularitile sistemului informatic proiectat. Necesitatea de codificare este impus de cerinele de grupare si ierarhizare a atributelor care oferea multiple soluii (posibiliti de prelucrare a datelor) regsite in coleciile de date care constituie baza informaional. Codificarea atributelor const n atribuirea, manual sau automat, ntr-o form sistematizat, de coduri fiecrui element din sistemul informatic proiectat. Prin codificarea atributelor se asigur urmtoarele avantaje: folosirea intensiv a memoriei externe prin nlocuirea atributelor cu coduri numerice, alfabetice sau alfanumerice; realizarea unei ierarhizri a atributelor n funcie de criteriile specifice prelucrrii prin care se poate obine o ordonare a acestora n raport cu cerinele de selectare a atributelor din baza informaional sau de obinere a gradelor de total sau subtotal pentru situaiile de ieire; reducerea erorilor prin folosirea codului care simplific scrierea n comparaie cu folosirea denumirilor explicite ale atributelor. utilizarea intensiva a suporturilor direct admisibile a memoriei interne, ceea ce permite optimizarea accesului de diverse valori a atributelor concomitent cu minimizarea timpului de prelucrare a viitoarelor colecii de date. confidenialitatea datelor, precum si integritatea acestora, ceea ce ofer bazei de date(B.D) o securitate si o protecie in timpul prelucrrii Pentru ca un sistem de codificare s fie eficient n procesul de prelucrare a datelor, se urmresc urmtoarele:

80

1) Cerinele si funciile codificrii. 2) Tipurile de coduri utilizate intr-un sistem informatic 3) Realizarea codificrii propriu-zise 1) Cerinele si funciile codificrii Cerintele codificrii sunt redate de proprietile eseniale ale unui cod pentru ca acesta s asigure un sistem de codificare eficient i viabil. Schematic codificarea atributelor se realizeaz conform fig. 1.14 Cele mai importante proprieti sunt: unicitatea codului, presupune existenta unui singur simbol pentru un atribut al bazei informationale si pentru atribuirea unei valori unice a fiecarui atribut,proprietate care trebuie asigurata la nivelul intregului sistem informatic stabilitate si suplete in timp, exprima necesitatea utilizarii unui tip de cod pe toata perioada de utilizarii bazei de date (B.D) inclusiv posibilitatea extinderii expresiilor valorice in functie de dinamica valorilor bazei informationale. comoditatea utilizrii codului-se refera la facilitatea operaiilor de codificare i de detectare a erorilor, precum i corectare a acestora. Atribuirea codurilor trebuie s fie uor de neles i aplicat astfel nct personalul unitii beneficiare sa asimileze intr-un timp foarte scurt noul sistem de coduri concizia codului se refera la necesitatea unui numr redus de caractere pentru reprezentarea elementelor codificate, astfel nct s se asigure o vitez mare de prelucrare i o reducere a procentelor de erori n procedurile manuale de introducere a datelor. Funciile codificrii Trebuie s permit caracterizarea direct a fiecrui atribut ce va fi supus codificrii, identificarea formal a acestora, controlul valorilor posibile atribuite, posibilitatea de manipulare a atributelor codificate. Funcia de caracterizare, exprim intr-o form concis, unic i stabila n timp coninutul semantic al fiecrui atribut, prin intermediul codurilor asociate(exemplu: n loc de Facultatea de Management Financiar Contabil se poate utiliza codul FMFC). Funcia de identificare, ofer posibilitatea regsirii mai rapide a atributelor, dect prin folosirea complex a semanticii atributului. Aceasta funcie creaz posibilitatea ulterioara de selectare a anumitor atribute prin intermediul crora se vor identifica in mod unic atributele solicitate prin intermediul cheilor primare si externe. Funcia de control asigur existena unui caracter care ataeaz n ultim poziie din dreapta structurii codului pe baza cruia prin metode matematice (aritmetica si geometrica) au algoritmi specifici ,se poate verifica integral corectitudinea simbolurilor care intr n componenta codurilor. Funcia de manipulare a atributelor codificate, faciliteaz introducerea eficient a codurilor in memorie, reduce timpul de prelucrare a acestora, faciliteaz uurina folosirii atributelor de ctre toate compartimentele funcionale implicate in realizarea sistemului informatic respectiv. 2) Tipologia codurilor

81

Diversitatea i complexitatea coninutului bazei informaionale de intrare, precum i multitudinea proceselor de prelucrare a atributelor componente, au condus la apariia unei game variate de coduri, grupate n mai multe categorii, n funcie de urmtoarele criterii de clasificare: a) Natura caracterelor; b) Controlul erorilor; c) Structura simbolului; d) Lungime; e) Modul de elaborare(atribuire). a) Natura caracterelor ce intr n componena codului determin urmtoarele coduri: numerice: formate numai din cifre; alfabetice: formate numai din litere: alfanumerice: formate din cifre, litere i eventual caractere speciale. b) Controlul erorilor se realizeaz prin intermediul unui caracter de control, cifr sau liter, situat la dreapta structurii codului. Acest caracter de control face parte din structura codului i va avea aceeai valoare atta timp ct valorile atributelor componente nu se modific. De asemenea, caracterul de control asigur fie detectarea automat a erorilor introduse (coduri autodetectoare de erori), fie i corectarea automat a acestora (coduri autocorectoare de erori). Codurile autodetectoare de erori se bazeaz pe existena caracterului de control care asigur detectarea automat a erorilor introduse prin compararea caracterului de control care nsoete codul respectiv cu caracterul de control determinat de calculator atunci cnd respectivul cod este utilizat. Pentru calculul caracterului de control se folosesc mai multe metode, dintre care cele mai cunoscute sunt: metoda aritmetic; metoda geometric; metoda literei de control.
Structura codurilor Elementar Coduri secveniale Coduri pe grupe Coduri cu semnificaie Coduri numerice Coduri cu semnificaie descriptiv Complex Coduri ierarhizate: liniar simplu zecimal Coduri juxtapuse Coduri combinate

Coduri secveniale se formeaz prin atribuirea unui ir de caractere fiecrui element al mulimii stabilind o coresponden (in ordine cresctoare) ntre elementele acestora i mulimea numerelor naturale. Fiecrui element supus codificrii i se asociaz un cod cresctor, imediat 82

disponibil. De exemplu: unei persoane angajate i se atribuie marca 123, este precedat de marca 122 i succedat de marca 124. Codul de semnificatie mnemonica se formeaz prin utilizarea unor simboluri recunoscute de standardele n vigoare sau prin atribuirea unor consoane rezultate din abrevierea elementului respectiv (de exemplu OL pentru oel laminat). Codul de semnificaie descriptiv se formeaz prin combinarea iniialelor desemnate pentru denumirea elementului respectiv cu particularitile tehnico-constructive ale acestuia. Acest tip de coduri este utilizat in special in nomenclatoarele de coduri speciale cu posibilitile de extindere pentru particularitile tehnice semnificative (de exemplu: Codurile complexe conin atribute ce aparin unor mulimi distincte, dar sunt folosite n comun n viitoarele prelucrri. n aceast categorie se include codurile ierarhizate juxtapuse. Codurile de ierarhizare redau numrul maxim de operaii, al fiecrui tip de atribut n cadrul treptelor de ierarhizare. Codurile juxtapuse se realizeaz prin concatenarea codurilor ierarhice sau secveniale in vederea utilizrii grupate sau utilizrii individuale a atributelor codificate in raport de cerinele statice sau dinamice de prelucrare. Exemplu: codificarea personalului unei uniti economice poate avea un cod juxtapus, rezultat din concatenare valorilor distincte ale atributelor (atelier de producie, secie de producie, marc) d) Lungimea codurilor este dat de numrul maxim de caractere folosite de un cod. Asfel avem: coduri de lungime fix: cu aceiai lungime efectiv pentru toate valorile atributelor codificate (exemplu: Codul rilor RO, DL, SW). coduri de lungime variabil: au lungimi diferitepentru anumite valori efective ale atributelor (exemplu: Acronimul folosit pentru codurile societilor comerciale cu lungimea maxim de caractere). e) Modul de atribuire a codului se refer la modalitatea n care se realizeaz practic codificarea: manual sau automat. Codificarea manual este utilizat pentru orice tip de cod i se realizeaz de operatori umani prin scrierea codurilor pe documentele primare. Codificarea automat este utilizat numai pentru acele tipuri de coduri pentru care se poate defini un algoritm de codificare programabil. De asemenea , aceast modalitate de codificare solicit standardizarea denumirii atributelor codificate i eventual redactarea unor programe sau rutine de recunoatere. 3) Realizarea codificrii Activitatea de codificare se realizeaz prin parcurgerea urmtoarelor faze: pregtirea activitilor de codificare; codificarea atributelor bazei informaionale; 83

 ntocmirea nomenclatoarelor de coduri; ntreinerea nomenclatoarelor de coduri. Pregtirea activitilor de codificare presupune urmtoarele operaii: analizarea coninutului i structurii bazei informaionale n vederea stabilirii acestor atribute ca sunt sau ar trebui codificate; studierea volumului atributelor codificabile, a tipului de cod utilizat, inclusiv a modului de realizare a codificrii. n cazul unei codificrii fr pregtire prealabil, activitatea se reduce la o analiz sumar asupra volumului de atribute. Dac se opteaz pentru codificare cu pregtire prealabil este necesar ordonarea atributelor codificabile, analiza particularitilor coninutului bazei informaionale i alegerea codului: ordonarea atributelor codificabile se poate realiza prin sortarea identificatorilor atributelor, ceea ce presupune clasificarea atributelor pe nivele ierarhice n scopul definirii grupelor de codificare precum i reguli precise de introducere a acestora n baza informaional; analiza particularitilor coninutului bazei informaionale, presupune determinarea dimensiunii mulimii de codificat i estimarea evoluiei ulterioare. Pentru aceasta este necesar s se precizeze responsabilitile de gestionare a bazei informaionale, modul de utilizare concret a codurilor n documente de intrare i ieire, frecvena de utilizarea, precum i gradul de acomodare a utilizatorilor cu sistemul de coduri propus; alegerea codului se face n coresponden cu valorile efective poteniale ale atributelor, metoda de introducere i validare a codurilor, metode de codificare, costul i timpul de realizare a activitii de codificare; codificarea este subordonat cerinelor i restriciilor sistemului informatic, deoarece acesta va stabili cerinele de informare pe nivele ierarhice, elemente ce determin fundamental tipul, aria de utilizare i gradul de generalitate al codului proiectat; costul i timpul de realizare a activitii de codificare determin soluia acelor tipuri de coduri care implic cheltuieli reduse i un timp minim de realizare a nomenclatoarelor de coduri; examinarea posibilitii prelurii n noul sistem informaie a codurilor deja folosite, dat fiind obinuina folosirii acestor tipuri de coduri, dar i scurtarea perioadei de implementare experimentare a sistemului informatic proiectat.

5.4 Proiectarea de detaliu/fizic Proiectarea fizic a sistemelor informatice este concretizat ntr-un ansamblu de baze de date, proceduri de pregtire i introducere a datelor, actualizare i obinere a rezultatelor, precum i reguli tehnice de utilizare i exploatare a ntregului sistem. Proiectarea fizic a sistemelor informatice este caracterizat printr-o serie de trsturi specifice:

84

Alegerea sistemului optim de gestiune a datelor i a sistemului de calcul care vor asigura realizarea funcionalitii sistemului informatic definit n proiectarea logic; Transformarea entitilor din baza informaional defnite n proiectarea logic, n colecii de date ce urmeaz a fi organizate n baze de date; Proiectarea structural i funcional a datelor organizate n baze de date la nivelul aplicaiilor; Elaborarea strategiei de definire a procedurilor de actualizare i exploatare-listare a bazelor de date, precum i specificarea msurilor de securitate i protecie. Proiectarea fizic a sistemelor informatice are un caracter preponderent tehnic i solicit un volum mare de munc, iar activitile desfurate sunt influenate direct de soluia aleas de gestiune a coleciilor de date, sistemul electronic de calcul i sistemul de operare. Proiectarea fizic implic parcurgerea urmtorilor pai: Proiectarea fiierelor fizice i a bazelor de date - descrierea modului n care vor fi stocate i accesate datele n/din memoriile secundare i cum se va asigura controlul lor pentru a oferi o securitate maxim. Proiectarea structurii sistemelor i a programelor - se descriu programele sau modulele acestora care s fie n strns concordan cu diagramele fluxurilor de date i cu celelalte piese ale documentaiei realizate n etapele anterioare. Proiectarea strategiilor de prelucrare distribuit - se vor prezenta modalitile n care utilizatorul poate s dispun de datele i facilitile de prelucrare oferite de reelele de calculatoare. Proiectarea fiierelor fizice i a bazelor de date i propune s asigure trecerea de la descrierea logic a datelor la una tehnic, de stocare a datelor. Totui, proiectarea fizic se concretizeaz n specificaii folosite ulterior de programatori i ali specialiti implicai n construirea sistemului (n timpul implementrii), prin crearea fiierelor, defnirea modurilor de organizare a acestora, precum i a bazelor de date. Proiectarea fizic a fiierelor i bazelor de date are dou obiective: 1. Transpunerea relaiilor dintr-un model de reprezentare logic a datelor ntr-un proiect tehnic. Un astfel de proiect va conine formatele sub care vor fi reprezentate atributele, modul de grupare a acestora din una sau mai multe relaii n una sau mai multe nregistrri fizice, alegerea modului de organizare a fiecrui fiier cu nregistrri fizice, precum i proiuectarea metodelor de accesare a datelor din unul sau mai multe fiiere. 2. Selectarea tehnologiilor folosite pentru stocarea datelor Tehnologiile nclud diverse funcii ale sistemelor de operare, numite metode de acces i sisteme de gestiune a bazelor de date. Fiecare tehnologie va fi specific unei anumite arhitecturi a sistemului. Concret activitile din cadrul proiectrii fizice sunt 1. Alegerea tipului de suport i modalitilor de prezentare a ieirilor informaionale; 2. Proiectarea machetelor de editare/vizualizare a ieirilor;

85

3. Proiectarea procedurilor i a programelor. Alegerea Sistemului de Gestiune a Bazei de Date Un sistem de Gestiune a Bazelor de Date (SGBD) este acel sistem de programe care faciliteaz i supervizeaz introducerea de informaii n baza de date, actualizarea i extragerea datelor din baz, controlul i autorizarea accesului la date, precum i asigurarea unei independente ntre structura bazei de date i programele de aplicaii. Funciile mai importante ale unui Sistem de Gestiune a Bazelor de Date sunt: 1. Funcia de descriere a datelor permite definirea structurii bazei de date cu ajutorul limbajului de definire. Definirea datelor poate fi realizat la nivel logic, conceptual i fizic. La nivelul acestei funcii se descrie multitudinea atributelor (cmpurilor) din cadrul structurii bazei de date, legturile dintre entitile bazei de date sau dintre atributele aceleiai entiti se definesc eventualele criterii de validare a datelor, metodele de acces la date, aspectele referitoare la asigurarea integritii i confidenialitii datelor. Rezultatele acestei funcii se vor concretiza n schema bazei de date , memorate n cod intern. 2. Funcia de manipulare a datelor este cea mai complex funcie i realizeaz urmtoarele activiti: Crearea (ncrcarea) bazei de date; Adugarea de noi nregistrri (tupluri); Suprimarea unor nregistrri; Modificarea valorilor corespunztoare unor cmpuri; Cutarea, sortarea i editarea parial sau total a unei nregistrri virtuale. Funcia de manipulare se realizeaz prin intermediul limbajului de manipulare a datelor. 3. Funcia de utilizare asigur mulimea interfeelor necesare pentru comunicarea tuturor utilizatorilor cu baza de date. n cadrul realizrii acestei funcii, apar mai multe categorii de utilizatori: Utilizatori ,,liberi sau conversaionali, numii i utilizatori finali, constituii din beneficiarii de informaii care folosesc limbajele de interogare a bazei de date ntr-o form simplist, sunt neinformaticienii. Utilizatori programatori, care utilizeaz limbajele de manipulare, realiznd complexe de exploatare a bazei de date. Administratorul bazei de date apare ca un utilizator special i are rol hotrtor n ceea ce privete funcionarea optim a ntregului ansamblu. 4. Funcia de administrare a bazei de date apare ca o funcie complex i este de competena administratorului bazei de date. Esenial este faptul ca utilizatorii au acces rapid, eventual, simultan la date Pornind de la modelele realizate prin activitatea de analiz, se poate proiecta structura BD, parcurgnd dou subactiviti: alegerea SGBD-ului, proiectarea funciilor BD. a). Alegerea SGBD-ului se face innd cont de dou aspecte: cerinele aplicaiei (utilizatorului) i performanele tehnice ale SGBD-ului.

86

Cerinele aplicaiei se refer la: volumul de date estimat a fi memorat i prelucrat n BD; complexitatea problemei de rezolvat; ponderea i frecvena operaiilor de intrare/ieire; condiii privind protecia datelor; operaii necesare pe baza de date (ncrcare/validare, actualizare, regsire etc.) particulariti ale activitii pentru care se realizeaz baza de date. performanele tehnice ala SGBD-ului se refer la: modelul de date pe care-l implementeaz; ponderea utilizrii SGBD-ului pe pia i tendina; configuraia de calcul minim cerut, limbajele de programare din SGBD; faciliti de utilizare oferite pentru diferite categorii de utilizatori; limitele SGBD-ului; optimizri realizate de SGBD; faciliti tehnice; lucrul cu mediul distribuit i concurena de date; elemente de multimedia; elemente de CASE; interfee de comunicare; autodocumentarea; instrumente specifice oferite. b) Proiectarea funciilor BD se realizeaz prin: proiectarea schemelor BD, proiectarea modulelor funcionale specializate. Proiectarea coleciilor de date Se realizeaz pornind de la rezultatele modelrii conceptuale (analiza de sistem) i innd cont de modelul de date implementat de SGBD-ul ales. Se vor proiecta schemele: conceptual, extern intern. Proiectarea schemei structurale pornete de la identificarea setului de date necesar sistemului. Aceste date sunt apoi integrate i structurate ntr-o schem (exemplu: pentru BD relaionale cea mai utilizat tehnic este normalizarea). Proiectarea schemei externe are rolul de a specifica viziunea fiecrui utilizator asupra BD. Pentru acest lucru, din schema conceptual se identific datele necesare fiecrei viziuni. Datele obinute se structureaz logic n subscheme innd cont de facilitile de utilizare i de cerinele utilizatorului. Schema extern devine operaional prin construirea unor viziuni (view) cu SGBDul i acordarea drepturilor de acces. Datele ntr-o viziune pot proveni din una sau mai multe colecii i nu ocup spaiul fizic. Proiectarea schemei interne presupune stabilirea structurilor de memorare fizic a datelor i definirea cilor de acces la date. Acestea sunt specifice fie SGBD-ului (scheme de alocare), fie

87

sistemului de operare. Proiectarea schemei interne nseamn realizarea operaiilor: estimarea spaiului fizic pentru BD i definirea unui model fizic de alocare (a se vedea dac SGBD-ul permite explicit acest lucru); definirea unor indeci pentru accesul direct, dup cheie, la date;

Proiectarea machetelor de editare/vizualizare a ieirilor La proiectare trebuie s se in seama de o serie de consideraii practice, cum ar fi: Respectarea unor cerine ale factorilor de decizie privind macheta situaiei finale. O serie de cerine ale conducerii finale oblig proiectantul la o anumit structurare i machetare a situaiilor finale. Totodat, se are n vedere faptul c unele situaii finale sunt destinate raporturilor externe ale unitii cu alte organizaii economico-sociale. Restricii tehnice. n proiectarea situaiilor finale intervin o serie de restricii datorate caracteristicilor i performanelor tehnice ale echipamentelor periferice, i anume: o numrul maxim de caractere pe linie; o numrul maxim de linii pe pagin/ecran; o facilitile de imprimare. Elemente de eficien. n proiectarea situaiilor finale nu trebuie s scape ateniei i aspectele de eficien economic privind: reducerea tipului calculator consumat cu editarea propriu-zis a situaiilor, economie de hrtie de imprimant. Pentru a nu irosi timp de calculator cu editarea unor situaii finale voluminoase se recomand mai nti rularea unor programe scurte care s verifice cheile de control aplicate. Numai dac aceste chei sunt corecte, eventual verificate i de utilizator,se poate lansa editarea analitic a situaiilor finale. Programele care editeaz situaii finale voluminoase trebuie prevzute cu posibilitatea de ntrerupere sau editarea lor sub forma unui fiier ASCII sau text pe hard-disk, urmnd imprimarea ulterioar a acestui fiier, total sau parial. Lizibilitate - spaiere. Este necesar ca situaia s fie autoexplicativ. Pentru aceasta antetul va conine informaii i coduri ce vor indica sursa de emitere a raportului, exprimnd clar, sintetic, coninutul raportului i perioada la care se refer. Capul de tabel, mpreun cu titlul i antetul, se afieaz pe urmtoarele pagini numai dac au intervenit schimbri n cadrul caracteristicilor de grupare fa de prima pagin, astfel se imprim doar numerotarea coloanelor de tabel. Totalurile se separ de informaiile care se repet pe linii succesive se imprim o singur dat. Utilizarea formularelor pretiprite. Aceasta implic utilizarea unei hrtii de imprimant ce cuprinde elemente fixe ale situaiei finale, cum ar fi antetul, titlul, capul de tabel,o diminuare a uzurii imprimantelor, devenind mai estetice i mai uor de parcurs de utilizatori. Utilizarea monitoarelor. Monitoarele ofer posibilitatea afirii situaiilor finale, att n regim alfanumeric, ct i n regim grafic, alegerea modului de lucru facndu-se prin intermediul unor comenzi sau comutatori. Reprezentarea informaiilor de ieire sub form

88

grafic este preferat de factorii de decizie de pe nivelurile de conducere superioare, dat fiind gradul de sintetizare a informaiilor pe ecran, la proiectarea videoformatelor de ieire se iau n considerare i facilitile oferite de monitoare, i anume: Regimul de lucru (defilare ecran, pagin sau linie); Regimul de afiare (normal, mai luminos, cu intermitene, invers video); Regimul de semnalizare sonor (normal, semnal sonor dup afiarea unui cmp). Proiectarea procedurilor i a programelor Se ine cont de concepia general a BD, precum i de schemele proictate anterior. n acest sens, se proiecteaz: fluxul informaional; modulele de ncrcare i manipulare a datelor; interfeele specializate; integrarea elementelor proiectate cu organizarea i funcionarea BD. Procedurile de utilizare i interpretare sunt absolut necesare utilizatorilor finali. Ele conin instruciuni, pai, criterii de control care uureaz utilizarea i interpretarea informaiilor. De obicei el nsoesc situaiile finale. Proiectarea programelor Cu etapa de proiectare a programelor se ncheie procesul de construire a sistemului. urmnd apoi implementarea practic a acestuia. n cadrul analizei au fost identificate procesele elementare i ulterior funciile sistemului informatic. n cadrul proiectrii, acestea se detaliaz, cu tranziia ctre codul surs, aceasta realizndu-se dup alegere limbajului de programare pentru implementarea sistemului. Pe baza cerinelor din activitile precedente se poate stabili necesarul de progran pentru sistemul informatic. Pentru acest lucru se determin categoriile de programe lista programelor necesare n sistemul informatic. Activiti de proiectare a programelor A. Definirea problemei de rezolvat Se are n vedere: cerinele informaionale ale conducerii cerinele legate de evoluie sistemului informatic. B. Descompunerea problemei n operaii Dup cum se tie, o problem este o expresie logic de forma: dndu-se o serie de condiii iniiale, s se determine scopul. n cazul nostru este vorba de o problem economic n care se d o mulime de factori economici, o mulime de operatori de transformare, care acioneaz conform unor criterii pentru scopul de a atinge anumite obiective. Pe de alt parte, orice problem este un proces ce se poate reprezenta sub forma unei secvene de subprobleme, ce trebuie rezolvate. n cazul sistemelor informatice se realizeaz o

89

descompunere de la vrf spre baz (metoda top-down) pn se ajunge la operaii elementare, folosind tehnica modularizrii. Se obine astfel, aplicnd diferite criterii de descompunere, un arbore de componente. Criteriul principal care se realizeaz descompunerea este cel al funcionalitii

6. IMPLEMENTAREA SISTEMELOR INFORMATICE Implementarea sistemelor informatice este o etap a ciclului de via al dezvoltrii sistemelor informatice care se regsete n toate metodologiile de realizare a sistemelor informatice. Implementarea sistemului informatic este acea etap n care se realizeaz efectiv trecerea de la vechiul sistem de lucru la cel nou. Este o etap foarte dificil, deoarece necesit conlucrarea strns dintre realizatorii sistemului informatic i beneficiarii acestuia. Este etapa n care sistemul este supus la cea mai dificil testare, cea a condiiilor reale de funcionare. Acum pot aprea cazuri care nu au fost prevzute de proiectani, la care sistemul nu este protejat. Implementarea sistemului const n punerea n practic a specificaiilor logice i are n vedere: corelarea modulelor din punct de vedere al funciilor logice realizate (invocri, utilizri); crearea interferenei dintre module conform standardelor de intrare/ieire; ordinea n care modulele sunt codificate, testate i implementate; calitatea datelor i destinaia rapoartelor; cerinele fiierelor i ale bazei de date (numr, coninut, tipuri de date, tipuri de acces, tipuri de nregistrri, etc.); ordonana activitilor de implementarea, instalarea i de instruire specifice sistemului considerat. n cadrul acestei etape se testeaz, se verific i se asimileaz de ctre beneficiar toate soluiile stabilite n etapele anterioare i se valideaz rezultatele obinute. Mai nti este necesar o pregtire a mediului n care va fi implementat sistemul informatic, ceea ce poate nsemna: instruirea personalului care urmeaz s exploateze sistemul, asigurarea condiiilor organizatorice necesare funcionrii sistemului, asigurarea resurselor hardware necesare, asigurarea fondului informaional. Implementarea ncepe n momentul n care toate componentele au fost testate individual i permit asamblarea fiecrei aplicaii i a ntregului sistem informatic. Aceste componente nglobeaz, pe de o parte, procedurile manuale folosite pentru pregtirea i testarea documentelor n vederea prelucrrii, efectuarea coreciilor, interpretarea i utilizarea rezultatelor, iar, pe de alt parte, procedurile prin intermediul crora are loc realizarea efectiv a funcionalitii sistemului informatic. n timpul implementrii, numeroase activiti vor fi executate simultan. De aceea, ele trebuie s fie planificate i programate de ctre o echip de implementare format din utilizatori,

90

manageri i specialiti n proiectarea sistemelor. Planificarea implementrii, firesc, ncepe anterior demarrii unei astfel de aciuni. De fapt, problemele implementrii sunt abordate chiar la nceputul proiectului, iar aspectele conceptuale i strategiile implementrii i conversiei sistemelor trebuie luate n discuie n fiecare stadiu al ciclului de via al sistemelor. Totui, planurile detaliate de implementare nu pot fi finalizate pn cnd conducerea nu aprob proiectul noului sistem. Un plan de implementare evideniaz toate activitile necesare, ajutnd pe cei ce-l ntocmesc s fie siguri c totul a fost prezentat corect. Prin el se vor consemna toate activitile de efectuat, precum i timpul alocat. Responsabilitile de execuie trebuie s fie foarte clare. De asemenea, trebuie estimate costurile fiecrei activiti astfel nct s poat fi elaborat un buget special. n acelai timp trebuie determinate reperele de execuie n timp, pentru a se putea exercita controlul. Mai dificil este de estimat momentul cnd se va finaliza implementarea. De fiecare dat utilizatorii sunt cei care i dau acceptul final, iar procesul, teoretic, poate fi considerat ca desfurndu-se pe o perioad nedefinit. Fazele procesului de implementare a sistemelor sunt redate n figura de mai jos :

Planificarea implementarii

Realizarea i testarea programelor

Pregtirea locurilor de munc; instalarea i testarea

Selectarea i instruirea personalului

Finalizarea documenta iei

Testarea sistemului

Conversia de la vechiul la noul sistem

Fig.2.1 Fazele procesului de implementare a sistemelor

91

6.1 Realizarea si testarea programelor Realizarea programelor a fost descris n capitolul anterior, motiv pentru care nu vom descrie dect modul de testare a programelor Etapa de testare a sistemului are ca scop eliminarea (pe ct posibil) a erorilor i neajunsurilor sistemului informatic. Ea se aplic att programelor individuale ale sistemului, ct i sistemului n ansamblul su (pentru testarea legturilor ntre module). Metodele de testare depind att de nivelul la care se aplic, ct i de tipul erorilor cutate. ntr-un sistem informatic se pot distinge urmtoarele tipuri de erori: Erori de sintax, sunt acele tipuri de erori ce sunt detectate n faza de compilare i sunt datorate construciei greite a unei instruciuni (lipsa unei paranteze, scrierea greit a numelui unei funcii etc.); Erori de rulare (de execuie) care sunt detectate la rularea programului i sunt datorate folosirii incorecte a comenzilor i funciilor limbajului (chiar scrise corect din punct de vedere sintactic). Exemple de asemenea erori sunt: folosirea unei variabile neiniializate, ncercarea de a scrie ntr-o fereastr la coordonate mai mari dect dimensiunea acesteia etc.; Erori de algoritm programul nu genereaz erori nici la compilare, nici la rulare, dar rezultatele obinute nu sunt cele ateptate, corecte; Erori de utilizare sistemul funcioneaz corect, dar utilizatorul l folosete greit. Erorile cel mai simplu de detectat, sunt cele de compilare, ele fiind sesizate automat la compilarea unui fiier surs, urmeaz apoi erorile de rulare, care sunt de asemenea detectate i sesizate automat, dar la execuia programului n cauz. La detectarea unei astfel de erori compilatorul furnizeaz un mesaj de eroare care ne indic natura i eventual cauza erorii respective, ct i linia din fiierul surs n care apare. Nu ntotdeauna mesajul oferit de compilator este unul explicit. De multe ori ni se indic un mesaj de eroare, oarecum incorect, genernd confuzie i ngreunnd depana-rea. Acest lucru se datoreaz unor erori care sunt consecine ale altor erori nedetectate anterior. Erorile de algoritm sunt mai greu de detectat dect celelalte dou tipuri prezentate anterior, datorit faptului c sistemul nu mai ofer nici un fel de mesaje de avertizare. Din punctul de vedere al SGBD-ului, programul funcioneaz corect, utilizatorul, fiind cel nemulumit de rezultatele obinute. Erorile de utilizare sunt acele erori datorate folosirii incorecte a sistemului, chiar dac el este corect conceput. Sistemul informatic trebuie s fie ct maibine protejat contra unor astfel de erori, adic: s nu permit utilizatorului introducerea unor date greite, lucru posibil prin implementarea unor proceduri de validare ct mai performante, mai compete; s pun la dispoziia utilizatorului numai acele opiunicare au sens la un moment dat (celelalte s fie dezactivate);

92

 s avertizeze utilizatorul n cazul detectrii inteniei de execuie a unor operaii suspecte a fi greite (cele despre care avem certitudinea c sunt greite s nu fie permise deloc); s ofere ct mai multe informaii de ajutor prin intermediul unul subsistem de ajutor permanent; s posede o documentaiect mai clar, explicit, complet, la nivelul celui mai slab pregtit utilizator etc. Testarea este efectuat, de regul, de personal specializat, care coordoneaz ntreaga activitate. La testare un rol important revine efului echipei de programare care trebuie s integreze fiecare modul testat separat i apoi s testeze ntregul program. ntotdeauna testarea va produce mai multe versiuni de module i de produse program, ultima fiind cea acceptat. La fiecare versiune se face o evaluare i se opereaz corecia. Testarea nu se ncheie dect atunci cnd se efectueaz lansarea prelucrrii de ctre ntreaga aplicaie informatic cu un set complet de date. Acest set va include toate datele posibile, corecte i eronate pentru a urmri reacia ntregului pachet de programe. n aceast testare global se urmrete: validarea datelor de intrare i a rezultatelor, dialogul din sistemul informatic, modul de operare la execuie. Se urmresc att aspectele formale ct i cele de fond. n literatura de specialitate sunt enumerate apte categorii de teste ale softului. Acestea se difereniaz n funcie de modul n care acestea angajeaz tehnici dinamice sau statice, precum i n funcie de modul de efectuare, automat sau manual. Testarea static nseamn verificarea programelor surs fr ca acestea s fie executate, iar cea dinamic nseamn i execuia programului surs. Testarea automat este efectuat sub controlul calculatorului, n timp ce testarea manual se desfoar sub controlul omului. Sintetic, cele apte categorii de teste sunt redate n tabelul de mai jos:

Tip testare

Manual

Automat Validarea sintactic Testarea pe componente Testarea integritii Testarea sistemului

Static Dinamic

Examinri Execuia de prob Verificare de birou

Examinrile sunt activiti prestate de grupuri de persoane cu scopul depistrii manuale a apariiei unor erori binecunoscute n codurile programelor surs. Prin urmrirea atent a instruciunilor programelor surs se depisteaz ntre 60 i 90% dintre erorile ce pot aprea n acestea.

93

Execuia de prob, spre deosebire de examinarea liniilor programelor surs, care nu urmrete i efectul fiecrei instruciuni, i propune s descopere erorile regsite n fiecare cod al programului surs. Execuia de prob trebuie efectuat ct mai des, pe parcursul finalizrii unor pri din lucrare(program). Rolul execuiei de prob este de a depista, i nu de a corecta erori. Verificarea de birou este un proces informal, prin care programatorul sau o alt persoan care nelege logica programului l parcurge, linie cu linie, cu un creion i o foaie de hrtie. Verificarea nu presupune neaparat i execuia pe calculator, ci programatorul urmreste cu atenie efectul fiecrei instruciuni a programului. Validarea sintactic este singura tehnic de verificare automat static executat, de regul, de ctre compilatoare. Rolul acestora este de a scoate la iveal erorile programului surs fr ns a-l executa. Toate celelalte tehnici automate presupun i execuia codului instruciunilor. Testarea pe componente este, deseori, cunoscut i ca testarea modulelor, deoarece fiecare modul este testat de sine stttor. Testarea integritii este o continuare a celei descrise anterior, ntruct ea se efectueaz cu scopul verificrii modului n care se intercondiioneaz modulele, cu alte cuvinte se testeaz un grup de module. Testarea integritii este gradual. n primul rnd, se testeaz modulul coordonator, adic modulul-rdcina dintr-o structur arborescent, i doar unul dintre modulele subordonate. Dup ce sunt testate modulele subordonate aflate pe acelai nivel, se efectueaz trecerea la alt nivel, inferior celui anterior. n final, se testeaz tot programul. n mod similar se va proceda cu ntregul sistem. Testarea sistemului difer de cele descrise anterior prin faptul c n locul modulelor se testeaz programele. Operaiunea este efectuat de personalul specializat n sisteme informatice, sub coordonarea efului de proiect, sau de ctre utilizatori, sub controlul specialitilor n informatic. Dup ce testele sistemului au fost ncununate cu succes, sistemul este supus testrii de acceptare, ntr-un mediu similar celui n care va fi pus n funciune i de ctre persoanele care l vor ntrebuina. Un test complet de acceptare const n efectuarea testrii alfa i a testrii beta. Testarea alfa utilizeaz date reprezentative, dar nereale, iar testarea beta se bazeaz pe date reale i se execut n mediul curent, concret de lucru al utilizatorului. Testarea alfa, cuprinde cteva teste edificatoare, dupa cum urmeaz : testarea regenerrii sau refacerii foreaza execuia softului astfel nct s nregistreze eecuri pentru a se verifica modul n care sistemul revine la normal ; testarea securitii verific dac mecanismele de protecie aflate n sistem acioneaz corespunzator mpotriva posibilelor atacuri ; testarea la suprasolicitri determin modul n care sistemul execut operaiunile n condiii de lucru diferite (cu configuraii de echipamente variate, cu anumite reele, sisteme de operare .a.). Testarea beta se deruleaz cu exerciii proprii utilizatorilor i cu datele concrete ale acestora. Ea este un fel de repetiie general naintea instalrii. 94

Posibilele erori ale softului se pot datora : incorectei contorizri a numrului de execuii ale unor bucle ; introducerii incomplete a datelor ; realizrii unor interfee eronate ntre module; depirii dimensiunilor unor tablouri(masive) de date .a. Pentru aprecierea calitii softului s-au propus mai muli indicatori :

rata defectelor pe or, zi, sptamn sau lun ; rata defectelor pe echipamentele de baz ale softului; timpul mediu ntre dou defeciuni; mrimea zonei afectate de defecte; numrul compilrilor sau al execuiilor unor componente ale sistemului care funcioneaz corect din prima ncercare ; defecte cumulate pe versiune; oportunitatea rspunsului la defecte sau a timpului afectat ndeprtrii lor ; satisfacia beneficiarului privind calitatea interveniei pentru remedierea defectelor soft. 6.2Instalarea sistemului Aceast faz asigur verificarea funcionalitii sistemului cu date reale, motiv pentru care se pot folosi anumite tactici i strategii n funcie de succesiunea de implementare a componentelor noului sistem. Strategiile de implementare presupun compararea vechiului sistem cu cel proiectat sau cu un alt sistem informatic luat drept etalon. n funcie de aceste elemente funcionarea experimental poate funciona n cinci variante. 1) Implementarea direct cu date curente a sistemului proiectat, presupune renunarea la vechiul sistem brusc, n vederea reducerii termenului i a minimizrii cheltuielilor cu implementarea. Avantajele acestei metode sunt costul mai sczut i o certitudine a implementrii, n schimb riscurile sunt mai mari, datorit faptului c activitatea sistemului economic se bazeaz acum pe sistemul informatic, iar o defeciune n acesta din urm putnd duce la blocarea activitii. De aceea aceast strategie nu se recomand n cazul activitilor critice, n flux continuu, care nu suport ntrzieri. 2) Implementarea paralel se face cu date curente sau anterioare pentru a se realiza o comparaie ntre sistemul vechi fa de cel nou, sau ntre noul sistem i sistemul etalon. Aceast strategie asigur un risc minim pentru beneficiar. 3) Implementarea pilotat urmrete lansarea n experimentare a sistemului proiectat ncepnd cu acele subsisteme ce au frecven maxim de utilizare, folosindu-se date din perioade anterioare i curente. Sistemul informatic se instaleaz pe o unitate pilot, mai mic dect cea real, dar care are caracteristicile definitorii ale acesteia. Aceast strategie se ncadreaz ntre cele dou anterioare, att din punctul de vedere al costurilor, ct i al riscurilor. 4) Implementarea compartimental este utilizabil n unitile economice n care structurile

95

organizatorice prezint autonomie prin prisma fluxurilor informaionale. n aceast variant condiia esenial o constituie realizarea anterioar a proiectrii de ansamblu i a celei de detaliu pe compartimente, caz n care rezultatele implementrii pot fi comensurate direct pe structurile organizatorice implicate. 5) Implementarea combinat poate fi abordat datorit avantajelor pe care le prezint celelalte variante prin folosirea implementrii paralele cu cea pilotat. Alegerea strategiei de implementare depinde de natura activitii desfurate n sistemul informatizat, de disponibilitaile materiale ale beneficiarului, de riscurile ce pot i se accept a fi asumate de beneficiar etc. 6.3 Verificarea performanelor sistemului informatic proiectat Aceast faz presupune exploatarea efectiv a sistemului cu date reale n vederea ndeplinirii parametrilor proiectai, a termenelor de execuie i duratei de exploatare. n finalul acestei faze se face evaluarea sistemului i validarea rezultatelor obinute, pentru a verifica n ce msur sunt satisfcute obiectivele propuse i dac rezultatele noului sistem justific cheltuielile fcute cu introducerea i realizarea lui. Funcionarea sistemului depinde de specificaiile logice, care evideniaz anumite aspecte de natur logic ale funciilor sistemului (legturi ntre intrri i ieiri, consideraii asupra volumului de date i a frexvenei lor, decizii de actualizare i de ntreinere, modul de operare), precum i de specificaiile fizice care n mod cert sunt mai importante pentru operatori. Interpretarea i transpunerea corect a specificaiilor logice pot s conduc la ndeplinirea ateptrilor scontate pentru viitor, n ciclul de via al noului sistem, referitoare la ntreinere, noile interfae lae sistemului, realocarea de funcii n cadrul firmei etc, soite de reorganizarea corespunztoare de personal calificat. Evaluarea sistemului se face pe baza specificaiilor logice i fizice. Specificaiile fizice au n vedere volumul, frecvena, acurateea, i eroarea informaiilor. Specificaiile logice conin rareori indicatori necesari pentru evaluarea sistemului, ns arat modul n care sunt corelate elementele resursei de informare i evideniaz unde i cnd funcioneaz aceste legturi. De exemplu, dac specificaiile logice arat c prelucrarea poate s nceap numai dup ce s-a strns un numr suficient de mare de facturi, acest fapt ne ajut s observm ct de bine este satisfcut acest criteriu i cnd este rezonabil testarea pentru prelucrarea facturilor. De asemenea, detaliile legturilor logice, cum ar fi succesiunea de intrri-ieiri sau de invocri de module, ne ajut s descoperim de unde provine ineficiena. Pe baza datelor provenite din exploaterea sistemului informatic, se determin eficiena economic i se cuantific raportul ntre performan i cost. Indicatorii eficienei economice se calculeaz n toate etapele de realizare a sistemului informatic, acordndu-se o atenie deosebit la sfritul primului an de exploatare efectiv.

96

n etapa de implementare se corecteaz indicatorii eficienei economice estimai, n timp ce n etapa de exploatare efectiv se calculeaz eficiena economic real pe baza rezultatelor obinute de unitatea beneficiar 6.4 Elaborarea documentaiei de utilizare a sistemului informatic proiectat. n funcie de modul de implementare a sistemului, pot apare anumite modificri n concepia acestuia, ca urmare a unor neajunsuri semnalate. Aceste modificri trebuie operate n structura sistemului proiectat i n documentaia acestuia pentru a evita eventualele dificulti n exploatarea i ntreinerea ulterioar. La terminarea fiecrei faze de dezvoltare a proiectului, liderul de proiect redacteaz un raport care detaliaz activitile, constatrile i rezultatele acelei faze, precum i planurile pentru fazele urmtoare, document ce va fi supus spre avizare de ctre beneficiar. Documentaia se elaboreaz la momente specifice n timpul realizrii proiectului, fie ca urmare a directivelor utilizate, care n general sunt proceduri bazate pe documentaie. Definitivarea ntregii documentaii de utilizare i exploatare a sistemului se concretizeaz n ntocmirea manualului de prezentare, utilizare i operare. Manualul de prezentare cuprinde concepia general a sistemului i o prezentare succint a aplicaiilor componente, fcndu-se precizri n legtur cu restriciile i limitele sistemului sau aplicaiilor, inclusiv performanele i posibilitile de extindere a acestora. Manualul de utilizare este ntocmit pentru fiecare aplicaie, i asigur descrierea general a aplicaiei, datele de intrare, condiiile de validare, restriciile i erorile ce pot apare, condiiile de reluare, i se adreseaz personalului implicat n utilizarea noului sistem. Manualul de operare conine informaii referitoare la exploatarea efectiv a sistemului proiectat prin intermediul sistemului de calcul. 7. EXPLOATAREA I NTREINEREA SISTEMULUI INFORMATIC 7.1 Exploatarea sistemului informatic Dup ce implementarea a luat sfrit, ncepe etapa de exploatare i ntreinere a sistemului informatic. Acum sistemul informatic funcioneaz la parametri normali prevzui de proiectani. Activitatea de exploatare se reduce la execuia curent a operaiilor de culegere a datelor, transmitere, validare i prelucrare a acestora, construirea i consultarea situaiilor de informare-raportare. Exploatarea curent i meninerea n funciune a sistemului informatic presupun punerea n stare operaional a calculatorului i a perifericelor, dup care se continu cu urmtoarele operaii: restaurarea bibliotecilor de programe i a bazei de date specifice noului sistem de pe copiile de siguran obinute la prelucrarea precedent; lansarea n execuie a programelor pentru crearea i actualizarea bazelor de date, obinerea listelor de control i eliminarea erorilor;

97

 exploatarea bazei de date n vederea obinerii situaiilor de ieire; verificarea corectitudinii rezultatelor obinute prin control de verosimilitate sau sondaj; stocarea pe dischete a ultimei versiuni a bazei de date n vederea conservrii acestora pn la prelucrarea urmtoare. n funcie de experiena dobndit n perioada exploatrii noului sistem i de rezultatele obinute ca urmare a informatizrii activitii unitii beneficiare se pot efectua reorganizri n structura serviciilor funcionale, prin trecerea anumitor activiti dintr-un compartiment ntr-altul, reconsiderarea unor centre de decizie etc. Exploatarea curent i meninerea n funciune a sistemelor informatice, asigur funcionarea acestuia pe toat durata lui de execuie. Ea nceteaz n situaia n care se renun la sistemul existent n funciune pentru a se trece la utilizarea altui sistem mai evoluat i eficient. 7.2 Procesul de ntreinere a sistemelor informatice Din totalul cheltuielilor generate de sistemele informaionale ale unitilor, cea mai mare parte revine etapei de ntreinere, i ca atare, personalul antrenat n ntreinere este cel mai numeros. ntreinerea ncepe odat cu instalarea sistemului i se refer nu numai la echipamente, ci i la software i la procedurile economice utilizate pe timpul exploatrii aplicaiilor din sistem. ntreinerea sistemului informatic const n totalul activitilor desfurate pentru asigurarea funcionrii sistemului la parametri normali, corectarea, eliminarea tuturor erorilor care apar pe parcurs, dar i introducerea n sistem a unor mbuntiri, perfecionri, modernizri etc., menite s creasc nivelul parametrilor de funcionare ai sistemului economic. Un aspect important se refer la durata etapei de ntreinere, dup unele preri ar fi de 5 ani, dup altele 10 sau mai muli. Rspunsul poate varia de la un caz la altul, tendina fiind de cretere a perioadei de ntreinere i implicit a costurilor aferente. Pe timpul ntreinerii un grup de persoane se va ocupa de colectarea cererilor de ntreinere lansate de utilizatori sau de alte pri implicate n exploatarea sistemului sau verificarea modului n care acesta funcioneaz.Activitile implicate de ntreinerea sistemului sunt: obinerea cererilor de ntreinere; transformarea cererilor n propuneri de schimbri; proiectarea schimbrilor; implementarea schimbrilor. Perfecionarea sistemului informatic presupune: folosirea de tehnic de calcul care s permit nregistrarea direct a datelor de intrare la locul i-n momentul producerii lor; perfecionarea sistemului de operare prin optimizarea programelor i a tehnicii de operare; optimizarea i parametrizarea programelor care s asigure portabilitatea acestora;

98

 utilizarea reelelor de calculatoare pentru realizarea obiectivelor din unitatea economic beneficiar. ntruct cheltuielile de ntreinere au o pondere substanial n structura costurilor totale ale sistemelor, considerm relevant prezentarea tipurilor de ntreinere: corectiv, adaptativ, perfectiv, conform fig. 2.2.

12% 8%

5%

Adaptiva Perfectiva Preventiva Corectiva

75% Fig. 2.2 Ponderile tipurilor de activitate de ntreinere n totalul activitii dentreinere a sistemelor aferente

ntreinerea corectiv const n efectuarea unor lucrri de reparaii pentru ndeprtarea unor defecte produse n timpul proiectrii, scrierii programelor sau implementrii sistemului. n majoritatea cazurilor, ntreinerea corectiv intervine imediat ce se pune n funciune noul sistem sau o component a acestuia. Ct timp o astfel de ntreinere i propune doar s ndeprteze defecte, ea nu adaug valoare dect ntr-o pondere derizorie, n pofida celor 75 de procente alocate ntreinerilor corective din totalul activittilor de ntreinere a sistemului. ntreinerea adaptativ presupune efectuarea unor schimbri n sistem, condiionate de: intenia de mbuntire a performanelor funcionale; adaptarea la schimbrile organizaionale; deplasarea sferei de activitate a unitii n alt mediu. Dac ntreinerea corectiv presupune o intervenie ct mai urgent n urma sesizrilor venite din sistem, cea adaptiv nu este la fel de presant, ntruct factorii care o condiioneaz nu au apariii spontane. O alt diferen const n faptul c ntreinerea adaptiv, spre deosebire de cea corectiv, adaug valoare organizaiei. ntreinerea perfectiv are ca scop efectuarea unor schimbri pentru mbuntirea diverselor prelucrri, modificarea cu scopul folosirii mai uoare a interfeelor sau pentru a i se aduga noi elemente, care ns nu sunt strict necesare. O astfel de operaiune de ntreinere constituie mai curnd o dezvoltare a sistemului i face parte din categoria activitilor care adaug valoare organizaiei. ntreinerea preventiv se efectueaz cu scopul diminurii substaniale a posibilitilor de defectare a sistemului, adaug valoare organizaiei. Costurile mentenanei unui sistem sunt influenate de cteva elemente principale: 99

 n fazele de evaluare / proiectare nu pot fi luate n considerare toate scenariile privind funcionarea sistemului; un sistem mare este proiectat i implementat de ctre mai multe echipe, n perioade diferite, ceea ce implic o bun coordonare a activitii lor i poate conduce la generarea unor soluii a cror integrare ridic uneori probleme n timpul exploatrii; dezvoltarea unui sistem informatic este un proces de durat i pe parcursul proiectrii i implementrii pot s apar modificri majore n ceea ce privete: legislaia, performanele echipamentelor i produselor programului, orientarea activitii organizaiei, forma de proprietate, strategia managerial; personalul care deservete sistemul, ctig experien i nelege din ce n ce mai bine ce ar trebui s fac, uneori n opoziie cu ce face. Activitatea de mentenan trebuie evaluat pentru a observa dac, la un moment dat, cheltuielile implicate nu depesc limitele acceptabile. Dac la un moment dat se constat c beneficiarele sunt puternic afectate de cheltuielile cu mentenana, se poate concluziona c sistemul nu mai rspunde necesitilor i este necesar nlocuirea sa parial sau total. n felul acesta se reia ciclul de via al dezvoltrii sistemului. 7.3 Documentaia necesar exploatrii i ntreinerii sistemului informatic Exploatarea noului sistem informatic se va realiza conform instruciunilor de exploatare prevzute n manualul de utilizare. Aceste instruciuni se adreseaz n principal utilizatorilor finali, adic beneficiarilor propriu-zii ai sistemului informatic i pot fi completate cu procedurile de autodocumentare cuprinse n produsul program. Manualul de utilizare i exploatare cuprinde urmtoarele instruciuni de utilizare i exploatare: Instruciuni de utilizare - proceduri de codificare a datelor prin care se dau instruciuni despre modul de ntocmire a codurilor. Aici se explic sistemul de codificare utilizat i structura codurilor. De asemenea se precizeaz criteriile de validare pentru fiecare cod i eventualele codificri automate pe care le face sistemul; - proceduri de ncrcare/validare date, prin care se dau instruciuni despre popularea coleciilor de date. Aici se precizeaz documentele primare din care se preiau datelor i modul de completare al acestora. Prin comparaie se prezint machetele de intrare i videoformatele aferente documentelor primare. Se precizeaz i corelaiile care trebuie s eyxiste ntre diferitele date ncrcate. Toate aceste instruciuni sunt utile utilizatorului pentru actualizarea datelor din coleciile de date. Pentru alegerea coleciei de date pe care se va lucra, precum i a operaiei care se va efectua, utilizare a sistemului de meniuri oferit de produsul program; - proceduri de obinere a situaiilor de ieire, prin care se dau instruciuni despre modul de afiare i interpretare a rapoartelor, listelor etc. Se prezint pentru fiecare situaie de ieire macheta, coninutul, periodicitatea de obinere i se dau exemple. Instruiunile vizeaz nu numai

100

modul de obinere a situaiilor de ieire, dar i interpretarea acestora. Se precizeaz semnificaia datelor coninute n situaia de ieire i eventualele corelaii dintre date i cheile de control.. n final se indic modul de difuzare i arhivare a situaiilor de ieire; - alte proceduri speciale prin care se dau instruciuni despre eventualel conversii, interfee, comunicaii cerute de produsul program. Instruciuni de exploatare - ealonarea n timp a procedurilor utilizate. Rezultatul este un grafic de exploatare a procedurilor care trebuie s semene ct mai mult cu sistemul de meniuri al produsului program. Ambele trebuie s ghideze utilizatorul n exploatarea produsului program: ordines operaiilor, succesiunea lor n timp, semnificaia lor etc. - proceduri privind datele de intrare. Se dau instruciuni privind primirea, controlul, restituirea i pstrarea documentelor din care se preiau datele de intrare. De asemenea, se indic modul de pregtire a datelor de intrare pentru ncrcare: reguli de ncrcare, de validare, de verificare. Proceduri de asamblare lucrri. Se d o list a procedurilor automate i se dau legturile dintre acestea. Se ajunge astfel la o schem funcional a procedurilor. Schema va oferi variante de prelucrare i va indica faciliti i restricii de exploatare a produsului program. Proceduri de operare. Se dau instruciuni privind pregtirea rulrii i apelului produsului program (mod de apel i ieire, parol de acces, fiiere necesare etc). Se indic o list a mesajelor aprute la exploatare, precum i modul de aciune al utilizatorului(rspunsuri, reluri etc). Se dau indicaii privind operarea cu sistemul de meniuri, cu videoformatele i ferestrele produsului program. Proceduri privind situaiile de ieire. Se dau instruciuni privind obinerea rezultatului i controlul de form i fond. Se indic numrul de exemplare necesare i suportul tehnic de informaie pe care se va obine fiecare situaie de ieire. Se specific destinaia i modul de arhivare a rapoartelor. ntreinerea sistemului informatic va avea la baz documentaia ntocmit n fiecare faz de realizare a acestuia. Documentaia astfel realizat va constitui, pe de o parte, un mijloc de comunicare ntre diferitele categorii de personal de specialitate n informatic antrenate n realizarea diferitelor etape de proiectare a sistemului, iar pe de alt parte, dup implementarea acestuia va constitui suportul necesar ntreinerii sistemului de la specificaia de cerine pn la planul de test i testarea final a acestuia, dintre care amintim: Specificaiile de cerine ale sistemului; Arhitectura general a sistemului cu evidenierea intrrilor, procedurilor de control i validare a datelor, coleciile de date, procedurile de editare a situaiilor de informare/raportare, ieirile sistemului, resursele hardware/software folosite etc.; Arhitectura programelor i schemelor logice de realizare a fiecrui program; Videoformatele de intrare/ieire;

101

Programele surs, listate i comentate; Specificaiile de validare a datelor care descriu cum fiecare program e validat i cum se leag informaiile de validare cu cerinele informaionale ale utilizatorilor; Un ghid de ntreinere de sistem care descrie care pri din sistem depind de hardware i care de software. 8. PROIECTAREA ORIENTAT OBIECT A SISTEMELOR INFORMATICE 8.1 Concepte utilizate n abordarea obiectuala proiectrii sistemelor informatice Dintre conceptele care stau la baza modelrii orientat obiect cele mai importante sunt: obiectul; ncapsularea; persistena; tipul; clasa; motenirea; polimorfismul; identitatea. Obiectul Obiectul este o abstractizare a entitii lumii reale i se caracterizeaz prin: stare; comportament. Starea unui obiect este definit de valorile atributelor sale. Un atribut este definit printr-un nume i poate lua valori elementare (numeric, alfanumeric, etc.) sau complexe (structuri de multiple referine spre alte obiecte, tipuri utilizatori etc.). Comportamentul unui obiect este definit de setul de operaii i metode aplicabile obiectului respectiv. Fiecare obiect are un nume care coincide, de obicei, cu numele entitii reprezentate. Metodele i atributele nu sunt vizibile din exteriorul obiectului. Un obiect rspunde la mesaje. Mesajul este unitatea de comunicaie dintre obiecte. Mesajele cuprind: numele mesajului, numele obiectului int i argumentele necesare, dac exist. Cnd un obiect primete un mesaj una din procedurile sale este apelat. Procedura realizeaz apoi o operaie care poate returna un rezultat. Mesajele sunt implementate prin intermediul metodelor. ncapsularea ncapsularea const n capacitatea obiectelor de a conine la un loc att date ct i operaii dintre care numai o parte sunt vizibile din exterior. Un obiect este compus din dou pri: 102

 interfaa permite unui utilizator extern s solicite obiectului executarea unei aciuni; o parte ascuns, de implementare reprezentat de starea intern i de metodele obiectului. ncapsularea ascunde utilizatorului complexitatea unui obiect, oferind o imagine simplificat care i permite s rezolve mai uor problemele complexe. Persistena Persistena este proprietatea obiectelor care determin existena mai ndelungat a acestora fa de procesul care le-a creat; este proprietatea prin care starea bazei de date asigur execuia unui proces pentru a fi refolosit ulterior n alt proces. Tipul Tipul sintetizeaz elementele comune ale unui set de obiecte cu aceleai caracteristici. Tipul abstract de date are dou componente: interfaa este vizibil utilizatorului i const ntr-o list de operaii implementarea presupune descrierea structurii interne a datelor obiectului i realizarea procedurilor de implementare a operaiilor interfeei. Clasa Noiunea de clas are aceeai semnificaie cu cea de tip, ns este deosebit de aceasta, prin faptul c este asociat cu faza de execuie. O clas este un tip abstract de date care definete att structura obiectelor din clasa respectiv, ct i mulimea metodelor existente pentru aceste obiecte. Obiectele din aceeai clas au aceleai atribute i aceleai metode i rspund la acelai mesaj. Clasele sunt organizate ierarhic. Orice subclas motenete metodele i structura clasei din care face parte. Motenirea Motenirea este procesul prin care toate atributele i metodele unei clase sunt preluate de o alt clas nrudit, numit subclas. Clasa de la care atributele i metodele sunt motenite se numete supraclas. Prin intermediul motenirii se pot exprima relaii deosebit de utile ntre clase: clasificarea, generalizare, specializare. Motenirea poate fi implementat: static presupune concatenarea cmpurilor motenite n clasele respective; dinamic presupune parcurgerea legturilor de motenire i se realizeaz fr recopierea cmpurilor motenite. Polimorfism Polimorfismul semnific posibilitatea unui obiect, instan a unei clase, s rspund diferit la primirea aceluiai mesaj.

103

Polimorfismul se poate asigura prin dou ci: redefinirea metodelor motenite n clasele derivate; crearea unor metode cu acelai nume dar cu parametrii deferii. Identitatea Identitatea unui obiect este proprietatea acestuia care l distinge de alte obiecte. Astfel, spre deosebire de modelul relaional n care datele sunt identificate prin valori ale cheii primare desemnate de utilizator, n modelul orientat obiect identificarea obiectelor este asigurat automat de sistem i este transparent utilizatorului. Dou obiecte a i b sunt identice dac au acelai identificator, adic egalitatea obiectelor este de fapt o egalitate de pointeri (se scrie a = b). Dou obiecte sunt egale dac au aceleai valori (a = b). Aadar a = = b implic a = b, reciproca este fals 8.2 Nivele de modelare n proiectarea orientat obiect Un model orientat obiect are la baz obiecte. Un obiect ncapsuleaz att date ct i comportament, ceea ce nseamn c analistul poate folosi abordarea orientat obiect att pentru modelarea datelor, ct i pentru modelarea proceselor. Pentru c permite analistului de sistem s surprind ambele aspecte ntr-o singur reprezentare i pentru c ofer i alte beneficii, cum ar fi mecanismul motenirii i reutilizarea codului, modelarea orientat obiect ofer un mediu puternic pentru dezvoltarea sistemelor complexe. Teoria obiectelor, ncapsularea, motenirea i polimorfismul stau la baza dezvoltrii obiectuale a sistemelor. Referitor la consistena modelelor, n alte abordri - cum ar fi analiza i proiectarea -, structurat - modelele care se dezvolt nu folosesc notaii comune i sunt slab conectate ntre ele, tranziia de la un model la altul fcndu-se n mod abrupt. Abordarea orientat obiect ofer continuitate n ceea ce privete tranziia ntre modelele analizei, proiectrii i ale implementrii. De exemplu, trecerea de la analiza orientat obiect la proiectarea orientat obiect presupune mbogirea modelului de analiz cu detalii referitoare implementare i nu dezvoltarea unui nou model. Modelarea domeniului (mediului) - Domain Model Pentru a aprofunda nelegerea contextului n care va funciona sistemul se utilizeaz modelul mediului (domeniului). Acest model cuprinde cele mai importante clase ntlnite n domeniul economic pentru care se realizeaz sistemul informatic i are un caracter de generalitate. Clasele se identific fie din cerinele exprimate de beneficiar, fie din intervievarea unor experi n domeniu. Este unul dintre primele modele utilizate n analiza orientat obiect i are menirea de a sistematiza expertiza din domeniul analizat i a o transmite sistemului informatic ce urmeaz a fi proiectat. Sunt trei tipuri de clase care pot fi puse n eviden n acest model:

104

 clase ce modeleaz obiecte sau concepte utilizate n cadrul sistemului informaional analizat, cum ar fi comand, contract, factur; obiecte sau concepte din lumea real pe care sistemul trebuie s le nregistreze i s in cont de ele, cum ar fi cursul de schimb al monedei de referin; evenimente ce intervin i afecteaz starea sistemului, cum ar fi plasarea unei comenzi, plata unei facturi. Pentru descrierea acestui model vom utiliza preponderent diagrama claselor, dintre instrumentele puse la dispoziie de UML. Scopul principal al acestui model este nelegerea contextului sistemului. De aceea la realizarea modelului mediului (domeniului) este de preferat si participe att specialiti n modelare, ct i experi din domeniul analizat. Din acest punct de vedere se remarc asemnarea cu etapa de analiz specific metodologiilor structurate Aa cum tim deja, conform unui vechi principiu al analizei sistemelor, n acest proces este de preferat s fie implicai cei mai buni specialiti n domeniu (experii). Modelul mediului va conine cele mai importante clase ale domeniului. Odat cu ntocmirea diagramei claselor se ntocmete i un dicionar al claselor n care se va preciza semnificaia fiecrei clase pentru a se folosi o terminologie unitar. Se prefer aceast formul pentru a se evita obinerea unui model prea mare i greu de utilizat. Modelul mediului, format din diagrama claselor domeniului i dicionarul de termeni, poate fi utilizat att la dezvoltarea modelului cazurilor de utilizare, ct i la identificarea claselor sistemului n etapa de analiz. Modelarea proceselor afacerii (prelucrrilor) - Business Model Aceasta este o tehnic de modelare utilizat pentru a aprofunda nelegerea proceselor specifice unei organizaii. Utiliznd UML, modelarea afacerii se poate face din dou perspective: fie prin modelul cazurilor de utilizare, fie prin modelul obiectelor. n cadrul modelrii cazurilor de utilizare (business use-case model) se surprinde funcionarea sistemului din perspectiva utilizatorilor acestuia. Modelul obiectelor (business-object model) surprinde prelucrrile din interiorul sistemului. Descrie n detaliu cum este tratat fiecare caz de utilizare. Realizarea cazurilor de utilizare se poate evidenia cu ajutorul diagramelor de interaciune (diagrama de secven, diagrama de colaborare) sau al diagramei de activitate. O entitate a sistemului existent (a afacerii) reprezint un lucru pe care utilizatori, acceseaz, consult, manipuleaz, realizeaz sau utilizeaz n cadrul unui caz de utilizri. O unitate de lucru este un set de astfel de entiti care formeaz un ntreg pentru utilizatorul final. Entitile i unitile de lucru sunt utilizate pentru a reprezenta aceleai concepte ca i clasele din modelul mediului (comand, produs, factur, cont). Fiecare utilizator, entitate sau unitate de lucru poate participa la realizarea mai multor cazuri de utilizare. Un astfel de model se dezvolt n doi pai: Realizarea modelului cazurilor de utilizare 105

 Detalierea modelului prin specificarea utilizatorilor, entitilor i a unitilor lucru, dar i a regulilor care guverneaz anumite procese sau obiecte. Scopul este crearea unor utilizatori, entiti i uniti de lucru care s rezolve problema evideniat de cazul de utilizare, eficient - bine, rapid i la cel mai sczut cost posibil. Modelarea mediului i modelarea afacerii par ntructva asemntoare, mai ale dac ne gndim c entitile i unitile de lucru corespund claselor din modelul mediu. Cele dou abordri difer n primul rnd prin modul de documentare. Una se bazeaz pe cunotinele unui expert n domeniu sau pe cunotinele despre sisteme similare, n timp ce a doua are n vedere cerinele beneficiarului. Orice clas a modelului domeniului i regsete originea n experiena cunosctorilor domeniului. Orice element al modelului afacerii (entitate sau unitate de lucru) i regsete originea ntr-o cerin a beneficiarului. Acesta este i motivul principal pentru care utiliznd cele dou abordri, n mod normal, se obin clase, atribute, metode i asocieri diferite. O alt deosebire ar fi c pornind de la analiza domeniului vom obine mai multe informaii despre atributele claselor i mai puine despre comportamentul acestora Evident, n cazul modelrii afacerii se vor identifica att entitile i unitile de lucru (clasele), ct i utilizatorii (i operaiile pe care acetia le ntreprind). i nu n cele din urm, modelul afacerii fiind mult mai detaliat, va fi mai bine valorificat n etapele ce vor urma. Se pot identifica mai bine actorii i cazurile de utilizare ale sistemului proiectat, i fiecare dintre acestea va putea fi mai bine pus n coresponden cu cerinele sistemului. Dac modelul mediului abordeaz cu precdere funcionarea sistemului n contextul acestuia, modelul afacerii i focalizeaz atenia asupra utilizatorilor i a modului cum sistemul i deservete. Modelarea cazurilor de utilizare Un model al cazurilor de utilizare este format din actori i cazuri de utilizare Un actor este o entitate extern ce interacioneaz cu sistemul (similar unei entiti externe dintr-o diagram de flux a datelor). Actorul este ceva sau cineva care schimb informaie cu sistemul. Un actor nu este obligatoriu s fie un utilizator uman. El poate fi i un alt sistem sau un dispozitiv hardware (exemplu, monitorul) cu care sistemul nostru interacioneaz sau schimb informaii. Un caz de utilizare este o secven de aciuni iniiate de un actor, surprinznd un anumit mod de a folosi sistemul. Nu trebuie fcut confuzie ntre actor al sistemului i utilizator al sistemului. Un utilizator este oricine folosete sistemul. Un actor este un rol pe care utilizatorul l poate juca. Numele actorului trebuie s indice acest rol. Un actor este un tip sau o clas de utilizator. Acelai utilizator poate juca mai multe roluri. Actorii, fiind entiti externe sistemului, nu pot fi descrii n detaliu. Identificarea actorilor ajut la identificarea cazurilor de utilizare - ntruct un caz de utilizare este iniiat de un actor.

106

Iat cteva ntrebri la care analistul de sistem trebuie s rspund pentru a identifica cazurile de utilizare: Care sunt principalele aciuni executate de fiecare actor? Actorul va citi sau va actualiza informaia din sistem? Actorul va informa sistemul despre modificrile petrecute n afara acestuia? Actorul va fi informat de modificrile din sistem? S considerm cazul unui sistem de nregistrare a studenilor la cursurile oferite de un centru de instruire. Entitile externe sistemului sunt studentul care se nscrie la curs, secretara care face nscrierea studenilor la cursuri, casiera care ncaseaz contravaloarea cursurilor i instructorul care pred cursurile Un caz de utilizare este iniiat ntotdeauna de un actor i poate interaciona i cu ali actori, nu numai cu cel care 1-a iniiat. Cazul de utilizare trebuie s redea o funcionalitate complet i nu numai o anumit aciune a unei funcionaliti. Transmiterea unui formular de nscriere la un curs este parte a procesului de nregistrare la curs, deci va fi inclus n cazul de utilizare nregistrare la curs" i nu se va construi un caz separat pentru aciunea transmitere formular de nscriere. Diagrama cazurilor de utilizare arat care sunt toate cazurile de utilizare din sistem. dar nu indic modul n care acestea sunt realizate de ctre actori. Modelul cazurilor de utilizare este completat de o descriere textual a fiecrui caz de utilizare, accentul punndu-se pe interaciunea cu ali actori i mai puin pe modul n care este executat n cadrul sistemului. Modelarea cazurilor de utilizare permite analiza cerinelor funcionale ale sistemului, insistnd asupra a CE trebuie s fac un sistem existent sau un nou sistem, fr s considere i CUM o s fac. Modelul cazurilor de utilizare este dezvoltat n faza de analiz a ciclului de via al sistemelor orientate obiect, avnd rolul de a ajuta dezvoltatorii s neleag cerinele funcionale ale sistemului. Procesul este iterativ iar, stabilirea cerinelor se face n urma discuiilor cu beneficiarul sistemului. Cazurile de utilizare controleaz toate celelalte modele. Dac cerinele utilizatorului se modific n timpul dezvoltrii, aceste modificri sunt vizibile mai nti n modelul cazurilor de utilizare. Modificrile n cazurile de utilizare implic modificri i n celelalte modele. i reciproca este valabil, adic n momentul n care se fac modificri n modele, acestea trebuie s se reflecte i la nivelul cazurilor de utilizare. Modelarea structurii statice (diagrama claselor, diagrama obiectelor) Diagrama claselor documenteaz structura static a sistemului; mai exact precizeaz clasele care exist i relaiile dintre acestea, nu i modul n care interacioneaz pentru a asigura un anumit comportament. Diagrama claselor poate, de asemenea, evidenia i alte aspecte ale structurii statice, cum ar fi pachetele. Construirea diagramei claselor presupune n primul rnd identificarea claselor din sistem, acest proces reprezint o parte esenial a proiectrii sistemelor orientate obiect, de succesul acestuia depinznd n mare parte succesul proiectului.

107

Criteriile de apreciere a unui model al claselor sunt: obiectele claselor din model trebuie s poat furniza ntregul comportament cerut sistemului; un bun model al claselor conine (pe ct posibil) clase stabile din domeniul obiectual, care nu depind de funcionalitatea particular cerut la momentul proiectrii. Poate fi utilizat orice tehnic de obinere a claselor atta timp ct modelul obinut respect criteriile enunate. Implicit, dac modelul obinut nu respect criteriile, nu va fi nimeni interesat de tehnica utilizat, orict de profesionist ar fi aceasta. n literatura de specialitate se propun dou metode: modelarea orientat pe date (data driven design); modelarea orientat pe funciuni (responsibility driven design). Primul tip de metode presupune identificarea tuturor datelor din sistem i mprirea Ior pe clase, nainte de a considera funciunile acestor clase. Tehnica identificrii substantivelor este cea mai utilizat astfel de metod. Al doilea tip de metode, orientate pe funciuni, presupune identificarea tuturor funciunilor sistemului i mprirea lor pe clase, nainte de a considera datele acestor clase. Tehnica identificrii substantivelor presupune dou etape: Identificarea claselor candidate, selectnd din specificarea cerinelor sistemului toate substantivele i frazele substantivale (se consider substantivele la singular i nu se aleg fraze ce conin sau" ca unici candidai). Se elimin candidaii considerai nepotrivii din diverse motive i se redenumesc clasele rmase dac este necesar. Unele dintre motivele pentru care o clas candidat ar putea fi considerat nepotrivit sunt: Redundana - o clas e prezent sub mai multe denumiri. Este important s ne amintim ns c obiecte similare pot s nu fie identice. Proiectantul decide dac lucrurile sunt suficient de diferite pentru a merita clase diferite. De exemplu, dac a fost selectat o pereche de genul mprumut" i mprumut pe termen scurt", acestea sunt diferite, dar numai la nivelul valorii atributelor. Se recomand n acest caz alegerea unui nume care s desemneze ntreg coninutul clasei. Imprecizia - cnd nu se poate spune precis care e realitatea descris de substantivul respectiv. Desigur, trebuie ndeprtat ambiguitatea nainte de a putea spune dac substantivul reprezint o clas. Eveniment sau operaie - cnd substantivul se refer la ceva ce este fcut de sistem. Uneori aceast situaie este bine modelat de o clas, dar nu este acesta cazul obinuit. Metalimbaj - unde substantivul face parte din modul de definire a cerinelor. Vom utiliza substantive ca cerine" sau sistem" ca parte a limbajului de modelare i nu pentru a reprezenta obiecte din domeniul problemei. Extern sistemului - atunci cnd substantivul este relevant pentru a descrie funcionarea

108

sistemului, dar nu se refer la ceva din interiorul su. Atribut - atunci cnd este clar c substantivul desemneaz o realitate simpl, fr un comportament interesant, care este de fapt un atribut al altei clase. Diagrama obiectelor Diagramele obiectuale conin obiecte i legturi. Ca i celelalte diagrame, pot conine note i restricii. Mai pot conine anumite pachete sau subsisteme, fiecare fiind folosite pentru a grupa elementele modelului. Aceste diagrame se folosesc pentru modelarea static a unui sistem, ca diagramele de clase, dar din perspectiva unor instane reale sau prototip. Crearea unei diagrame conceptuale se face ntr-un singur mod, modelnd structura obiectelor. Modelarea structurii obiectelor implic fotografierea obiectelor din sistem la un anumit moment. Modelarea dinamicii sistemului Pentru modelarea dinamicii sistemului, UML furnizeaz dou tipuri de diagrame i anume, diagramele de interaciune (diagrama de secven i diagrama de colaborare) i diagramele de comportament (diagrama de stare i diagrama de activitate). Principala menire a acestor diagrame este de a arata cum realizeaz sistemul un caz de utilizare sau un scenariu particular dintr-un caz de utilizare. Pentru fiecare caz de utilizare se pot realiza mai multe scenarii (din descrierea cazului de utilizare). Pentru fiecare astfel de scenariu se pot ntocmi, nu este obligatoriu, o diagram de secven sau o diagram de colaborare (unele dintre instrumentele CASE pot obine o diagram din alta). Acest tip de diagrame nlesnete nelegerea cazurilor de utilizare mai dificile. Ele pot, de asemenea, susine comunicarea n cadrul echipei de proiectare, n cazul n care de o aceeai interaciune se ocup mai multe persoane sau grupuri de persoane. Nu e de ateptat s se dezvolte astfel de diagrame pentru fiecare caz de utilizare sau pentru fiecare operaie, doar dac beneficiile depesc costurile. n cazul n care se dispune de un CASE ce poate utiliza aceste diagrame la generarea de cod, atunci devine profitabil s dezvoltm diagrame de interaciune i diagrame de comportament. Diagramele de secven descriu modul n care obiectele interacioneaz i comunic ntre ele. Aceste diagrame permit focalizarea ateniei asupra secvenelor de mesaje, mai precis asupra mesajelor care sunt trimise i recepionate de ctre obiecte. Avantajul major al diagramelor de secven, fa de diagramele de colaborare, este posibilitatea de a reprezenta grafic trecerea timpului, fiind deci indispensabile n czul proiectrii de sisteme n timp real. Diagramele de colaborare permit evidenierea att a interaciunilor, ct i a legturilor dintre un set de obiecte care colaboreaz. Att diagramele de secven, ct i cele de colaborare vizualizeaz interaciunile, dar diagrama de secven ia n considerare timpul, pe cnd cea de colaborare, spaiul.

109

Ca i diagramele de secven, diagramele de colaborare pot fi utilizate pentru nscrierea execuiei unei operaii, a unui caz de utilizare sau a unui scenariu de interaciune n cadrul sistemului. n acest tip de diagram nu pot fi descrise mesajele concurente i asincrone. Pn acum nu am amintit nimic despre modelarea deciziei" unui obiect despre ceea ce s fac la primirea unui mesaj. Diagramele de interaciune pot reprezenta obiecte diferite ale aceleiai clase care primesc acelai mesaj, dar rspund diferit. Acest comportament este rezonabil de cele mai multe ori, ntruct comportamentul unui obiect poate fi afectat i de valorile atributelor sale. Pentru a putea implementa, ntreine sau testa o clas este necesar s nelegem relaiile de dependen care exist ntre starea unui anumi: obiect i reaciile sale la mesajele primite sau la alte evenimente. Diagramele de stare sunt acelea care nregistreaz aceste dependene. Pornind de aici, se pot folosi aproximativ aceleai notaii pentru a descrie activit complexe. Se consider c trecerea de la o activitate la alta atunci cnd prima activitate s-a ncheiat este similar cu trecerea unui obiect dintr-o stare ntr-alta, semnificativ diferit de prima, atunci cnd acesta primete un mesaj. Diagramele de activitate sunt o variaiune a diagramelor de stare, adaptate pentru a evidenia conexiunile i dependenele dintre activiti. Ele sunt extrem de folositoare atunci cnd se apreciaz c o activitate trebuie s execute o serie de taskuri diferite i dorim s modelm dependenele eseniale dintre acestea, nainte de a decide n ce ordine s se execute. Diagramele de stare au rolul de a captura ciclul de via al obiectelor, subsistemelor i sistemelor, prin specificarea strilor n care se poate gsi un obiect i a evenimentelor (mesaje primite, erori, condiii care devin adevrate) care-i afecteaz starea de-a lungul execuiei. O diagram de stare poate fi ataat oricrei clase care are stri clar identificabile i un comportament complex. O diagram de activitate constituie o variant a diagramei de stare, cu un scop puin diferit, acela de a evidenia aciuni i rezultate ale acestor aciuni. De fapt, diagramele de activitate constituie o cale alternativ de descriere a interaciunilor. Diagramele de activitate pot fi utilizate i pentru a descrie cum se desfoar cazuri de utilizare individuale i cum depind de alte cazuri de utilizare. Diagramele de activitate pot fi folosite n mai multe scopuri, i anume: Ilustrarea aciunilor care vor fi realizate atunci cnd este executat o operaie. Acesta este i cel mai comun caz de utilizare a acestui tip de diagram. Prezentarea activitii interne a unui obiect. Identificarea aciunilor care pot fi realizate n mod legat i stabilirea modului n care aceste seturi de aciuni afecteaz obiectele din jur. Ilustrarea modului n care instana unui caz de utilizare poate fi realizat n termenii aciunilor sau modificrilor intervenite n starea obiectului. Ilustrarea modului n care este organizat munca actorilor, care este organizarea i obiectele folosite.

110

8.3 Dezvoltarea sistemelor informatice folosind procesul unificat (UML) Proiectarea orientat obiect i gsete justificarea n cerina imperioas de a face fa i a oferi soluii superioare calitativ n special sistemelor informatice de mari dimensiuni i nivel ridicat de complexitate. Interesul manifestat fa de abordarea obiectual, n programare mai nti i, prin fora lucrurilor, n proiectare i apoi n analiz au condus, odat cu acumularea de suficient experien practic, la definirea de metode de dezvoltare orientate obiect. Printre acestea, cele care s-au bucurat de cele mai bune aprecieri din partea utilizatorilor au fost OMT(Object Modeling Tehnique), OOSE(Object-Oriented Software Engineering), UML(Unified Modeling Language). UML este rezultatul unui efort de unificare la care au contribuit elemente dezvoltate de numeroase cercetri i metode. De altfel, documentul oficial definete UML drept o colecie a celor mai bune practici aplicate n modelarea sistemelor informatice de mari dimensiuni i complexitate. UML a fost definit pornind de la rolul esenial pe care-l joac modelarea n conceperea i realizarea de sisteme software. Un model este formulat ntr-un limbaj de modelare. Limbajul de modelare include un ansamblu de concepte i semantici fundamentale, o notaie i un set de reguli de utilizare. Pentru un plus de rigoare i claritate a definirii, conceptele de baz sunt, la rndul lor modelate n UML. Aceast definire recursiv este denumit metamodelare. Metamodelele ofer o descriere formal a tipurilor de elemente care pot participa la modelare (sau din care pot fi compuse modelele) numite simplu elemente de modelare mpreun cu sintaxa i semantica notaiei prin care sunt referite i folosite acestea. n ali termeni, fiecare metamodel definete elementele de modelare i regulile dup care se compun acestea n modele. Notaia folosit este format din simboluri grafice. Aceasta conduce la utilizarea sintagmei de modelare vizual pentru UML i justific declararea sa drept limbaj de vizualizare. Paradigma obiectual, printre altele, avantajul c ofer un set de concepte ce pot fi aplicate uniform pe toate nivelele de abstractizare, ncepnd cu viziunea schematic iniial i pn la viziunea terminal, suficient de detaliat pentru a oferi toate amnuntele necesare traducerii directe n program surs. Aplicate n acest context, rigoarea i consistena cu care sunt definite conceptele sale au fcut din UML baza mai multor instrumente CASE, aa cum este Rational Rose. Acestea nu numai c asist analiza i proiectarea prin mijloace specifice, dar sunt capabile i de generarea automat a unei pri din codul surs, n mai multe limbaje la alegere. Exist, prin urmare, posibilitatea, demonstrat practic, de a defini reguli i euristici de trecere de la structurile UML la construciile specifice unui limbaj de programare sau altul. Diversele metode obiectuale, inclusiv cele care ua stat la originea UML, preconizeaz diferite procese de dezvoltare a sistemelor. Procesul este cel care prescrie activitile i ordinea n care trebuie realizate, rezultatele de obinut din fiecare activitate, criteriile de evaluare a

111

calitii i de msurare i control a progresului proiectului etc. Dincolo de specificitatea oferit de o metod sau alta, procesul trebuie adaptat de asemenea, la natura problemei de rezolvat, la cultura managerial a utilizatorului, la caracteristicile echipei implicate n realizare .a.m.d. UML nu este o metod de dezvoltare obiectual. Poate accepta i poate fi ns folosit n diverse metode, chiar dac acestea aplic procese diferite. A fost astfel definit i un proces de aplicare a UML n dezvoltarea de sisteme informatice, denumit, la rndul su, unificat. Procesul unificat poate fi caracterizat prin urmtoarele trsturi cheie: este iterativ i incremental; este dirijat de cazurile de utilizare; este centrat pe arhitectur; este pilotat de riscuri. Conform primei trsturi, dezvoltarea are loc prin mai multe iteraii succesive, n fiecare dintre acestea abordndu-se doar o poriune a sistemului su doar anumite aspecte ale proiectri i realizrii. n felul acesta se renun la ideea de a defini n totalitate detaliile aferente unei anumite etape nainte de a trece la urmtoarea. De aceast dat, se accept o definire parial, pe baza creia se construiete un produs la care se revine, ntr-o nou iteraie, cu modificri sau cu noi detalii sau funcii aspectul incremental pn la obinerea sistemului final. Progresul proiectului poate fi mai bine controlat, iar experiena acumulat n cursul unei iteraii poate fi utilizat n cele care urmeaz. Cazurile de utilizare constituie punctul central al edificiului: n stadiul iniial, ele definesc utilizatorii i cerinele acestora sub forma actorilor i a interaciunilor dorite ale acestora cu sistemul. Aceleai cazuri de utilizare vor constitui punctul iniial n definirea cerinelor i referina pentru proiectare i realizare, iar setul de teste prin care este verificat sistemul se va defini tot pe baza lor. Prin posibilitatea de a regsi permanent legtura cu cazul de utilizare n cursul ntregului ciclu de dezvoltare, se rspunde i cerinei de asigurare a trasabilitii.
Diagrame de colaborare Cazuri de utilizare Diagrame de secvene Diagrame de clase Diagrame de activitate

nlnuirea diagramelor UML Arhitectura se refer aici la structura de ansamblu a sistemului sub aspectul organizrii sale n subsisteme, a interaciunii dintre acestea, a celor mai semnificative cazuri de utilizare etc. Pe baza arhitecturii este posibil planificarea i lucrul n paralel a mai multor echipe diferite. Existena este indispensabil pentru a putea aplica dezvoltarea iterativ. Riscul desemneaz n contextul de fa, tot ceea ce ar putea mpiedica realizarea sistemului. Pot fi evideniate dou categorii primare de risc: tehnice i funcionale. Sintagma 112

pilotat de riscuri exprim faptul concret c definirea i ordonarea iteraiilor se face astfel nct riscurile identificate s fie abordate i elimanate ct mai devreme n cadrul ciclului de dezvoltare, ncepnd cu cele mai grave. Balize de evaluare

Studiul preliminar

Elaborarea

Construcia

Tranziia

Fazele ciclului de dezvoltare Ciclul de dezvoltare Ciclul de dezvoltare este compus din patru faze. Fiecare faz produce un anumit set de rezultate care sunt elemente de intrare pentru urmtoarea, ceea ce confer ansamblului un caracter de confidenialitate. Pentru fiecare faz, anumite rezultate sunt folosite drept balize de evaluare i servesc pentru a msura progresul nregistrat de proiect. Fazele ciclului de dezvoltare sunt urmtoarele: studiul preliminar, elaborarea, construcia, i tranziia. Studiul preliminar (inception n terminologia de origine) urmrete definirea amplasrii viitorului sistem n cadrul activitii organizaiei. Aceasta include delimitarea ariei de cuprindere, stabilirea obiectivelor, studiul fezabilitii n contextul unuia sau mai multor modele de afaceri. Rezultatul cheie al fazei este viziunea sistemului, care conine o descriere foarte sintetic n care se precizeaz ce este sistemul, cine l va utiliza, ce faciliti trebuie s asigure i la ce restricii trebuie s rspund. Viziunea constituie i principala baliz de evaluare a studiului preliminar. Elaborarea asigur colectarea i precizarea cerinelor funcionale i nefuncionale ale viitorului sistem. Cum utilizatorii sistemului i cerinele acestora sunt specificate prin intermediul cazurilor de utilizare, modelul detaliat al acestora constituie unul dintre artefactele de baz i, n acelai timp, baliz de evaluare a fazei. Un alt rezultat esenial, strns legat de precedentul i inclus n balizele de evaluare de baz, este reprezentat de arhitectura sistemului. Construcia asigur obinerea sistemului, incluznd deci analiza, proiectarea, programarea i testarea. Rezultatele ce servesc drept principale balize de evaluare cuprind ntregul set de modele de analiz i proiectare, mpreun cu totalitatea programelor elaborate. Tranziia asigur introducerea n exploatare a sistemului la utilizator. Aici se regsesc configurarea, instalarea, furnizarea documentaiei, instruirea i eventual formarea personalului. Principala baliz de evaluare este versiunea final a sistemului. Sistemul informatic obinut n urma parcurgerii celor patru faze poate solicita modificri ulterioare pentru asigurarea evoluiei sale. Pentru referirea la asemenea stadii evolutive, se folosete termenul de generaie. n consecin, la terminarea primului ciclu de dezvoltare, rezult

113

generaia 1 a produsului software respectiv. Obinerea unei noi generaii presupune reluarea ciclului, cu parcurgerea celor patru faze. Activiti i iteraii Structurarea n cele patru faze ale ciclului de dezvoltare corespunde perspectivei manageriale asupra procesului, n care atenia este concentrat asupra aspectelor financiare, strategice, de personal. Aspectele tehnice legate de conceperea i realizarea sistemului sunt proprii unei alte perspective a aceluiai proces, structur n activiti i iteraii. O activitate se realizeaz prin combinarea mai multor pai. Pasul este componenta elementar i folosete anumite elemente de intrare pe care le modific sau pe baza crora realizeaz alte elemente noi. Aceste intrri i ieiri sunt produse intermediare constnd din documente, modele, programe etc. Exist cinci activiti de baz: definirea cerinelor, analiza, proiectarea, implementarea i testarea. Definirea cerinelor se concentreaz asupra identificrii cerinelor funcionale i nefuncionale ale sistemului. Aceast etap furnizeaz imaginea exterioar a sistemului, adic imaginea perceput de ctre utilizatorii si. Analiza urmrete obinerea unui model al problemei de rezolvat, aa cum apare aceasta la nivelul activitii reale de afaceri. Modelul este ns formulat n termeni informatici, prin clase de obiecte, operaii, interaciuni etc. i ignor orice detaliu tehnic sau de implementare. Proiectarea extinde sau adapteaz modelul anterior pentru a rspunde cerinelor tehnice i restriciilor configuraiei de calcul n care va funciona sistemul. Este etapa n care sunt luate n considerare i rezolvate problemele de persisten, de intefa, de comunicare etc. pstrnd ns neschimbat structura i comportamentul definite anterior, care exprim logica domeniului. Implementarea const n scrierea, compilarea i documentarea programelor pentru proiectul definit n etapa precedent. Testarea asigur verificarea programelor realizate n etapa anterioar pentru a stabili msura n care acestea corespund cerinelor funcionale i nefuncionale, sunt sigure n funcionare. Activitile enumerate se bucur de o accepiune aproape unanim. Cu toate acestea numeroi autori le combin sau le completeaz. Fiind vorba despre acelai proces privit din perspective diferite, exist o suprapunere a fazelor i activitilor. Deosebit de semnificativ este faptul c activitile se pot regsi n totalitate, chiar dac n proporii diferite, n fiecare din cele patru faze. Spre exemplu, sunt posibile activiti de implementare i testare chiar i n faza de studiu preliminar, pentru care metoda recomand, de altfel, recurgerea la prototipaj, ceea ce indivizualizeaz suficient de clar demersul aplicat.

114