Sunteți pe pagina 1din 15

Cap.

II METODE I TEHNICI DE REALIZARE A SISTEMELOR INFORMATICE


1) Structura sistemelor informatice 2) Concepia logic de principiu a sistemului informatic 3) Metode de abordare a sistemelor informatice 4) Ciclul de via i ciclul de dezvoltare a sistemelor informatice 5) Metode de proiectare a sistemelor informatice

STRUCTURA SISTEMELOR INFORMATICE


n conformitate cu abordarea funcional, sistemele informatice sunt organizate pe subsisteme, aplicaii i uniti funcionale (proceduri logice). Pentru programatori mai sunt relevante nc dou niveluri, inferioare unitii funcionale i anume , unitatea de prelucrare (procedura automat) i modulul program . Subsistemul vizeaz o funcie a unitii beneficiare sau un domeniu de activitate din unitatea n care este conceput sistemul. Aplicaia vizeaz o activitate, iar unitatea funcional (procedura logica) o subactivitate sau sarcin . Aplicaia este un pachet de programe ce servete la automatizarea prelucrrii datelor aferente unei activiti distincte din cadrul unui domeniu de activitate (de exemplu poate exista o aplicaie pentru elaborarea statelor de plat, denumit pe scurt aplicaia salarizare). ntr-o aplicaie pot fi implicate mai multe elemente de structur organizatoric. De exemplu n elaborarea statelor de plat este implicat nu numai biroul financiar, care este titular pentru aceast activitate, ci i serviciul personal, sau dac sistemul de plat presupune pontaj, va fi implicat dispeceratul, secretariatul, etc.. mplicarea mai multor elemente de structur organizatoric ntr-o aplicaie complic schema funcional a aplicaiei, dar de cele mai multe ori, prezena mai multor elemente este inevitabil. De regul aplicaiile se deruleaz ciclic i pentru a fi mai uor trecute pe calculator, ciclul lor de via se descompune n subactiviti cum ar fi preluarea datelor i actualizarea bazei de date, sau cea de elaborare liste de ieire sau rapoarte, sau etapa de elaborare informaii pentru alte aplicaii, etc. Procedura logic (denumit i unitatea funcional) este corespondentul subactivitii din cadrul unei aplicaii din domeniul informatizrii. Numai la acest nivel se poate face uor, trecerea direct de la structura logic a aplicaiei la programe, ceea ce nseamn c unei proceduri logice (uniti funcionale) i se pot asocia din softul aplicaiei, una sau mai multe proceduri automate (uniti de prelucrare). Ultima situaie este necesar mai ales atunci cnd i n cadrul unei uniti de prelucrare, sunt implicate mai multe elemente de structur organizatoric.

n contextul unitilor funcionale, elementele de structur organizatoric folosesc calculatorul n sesiuni de lucru la calculator cnd, de cele mai multe ori, nu se ruleaz un singur program, ci una sau mai multe proceduri automate. Procedura automat (unitatea de prelucrare) este o secven bine definit de programe (module program), care odat lansat n execuie, se ruleaz dup o schem logic, fr ntrerupere, pn la sfrit. De exemplu preluarea pe calculator, validarea i stocarea fielor de pontaj pentru salarii poate constitui o procedur n cadrul aplicaiei numit salarii. Faptul c procedura se ruleaz ntotdeauna pn la sfrsit, nu nseamn c programele care fac parte din procedur se vor rula toate de fiecare dat; rostul schemei logice care st la baza procedurii, este tocmai acela de a decide n funcie de parametrii introdui de utilizator i de felul cum decurge rularea, care program s se ruleze i care s fie srit, astfel nct procedura s nfptuiasc un act coerent, raional, s permit utilizatorului s controleze situaia, mai precis s nfptuiasc o etap sau mcar acea parte dintr-o etap din ciclul de via al unei aplicaii, care-i revine biroului sau seciei din care face parte utilizatorul respectiv. Exist i proceduri manuale care dei nu fac obiectul programrii, ele pregtesc prelucrarea automat a datelor, sau dup caz, finalizeaz aceast aciune. Proiectantul sistemului informatic, trebuie s in seama de procedurile manuale i s fac referiri la ele n cadrul etapei de proiectare logic i fizic precum i ulterior n cadrul manualelor de utilizare i respectiv de exploatare, pentru c abia mpreun cu aceste proceduri sistemul informatic este complet. Structura sistemului informatic trebuie s fie ct mai puin dependent de structura organizatoric a intreprinderii/instituiei pentru care s-a conceput sistemul. Acest lucru asigur sistemelor informatice o via mai lung, fcndu-le s nu depind de frecventele schimbri de structur organizatoric, care au loc de obicei n seciunile sociale unde sunt implementate i care, dac sistemul s-ar baza pe ele, ar face ca acesta s trebuiasc s fie actualizat, pentru fiecare modificare de structur.

CONCEPIA LOGIC DE PRINCIPIU A SISTEMULUI INFORMATIC


S-a specificat c sistemele informatice sunt structurate pe subsisteme, aplicaii, uniti funcionale, uniti de prelucrare sau proceduri i module program. Merit remarcat c, indiferent de nivelul su, orice component a sistemului informatic presupune intrri, prelucrri i ieiri, iar relaiile dintre componente se realizeaz prin intermediul unei baze informaionale, care exist i n sistemul informaional, dar n condiiile informatizrii, va fi reflectat n colecii omogene de date ce pot fi organizate n baze de fiiere sau date n funcie de sistemul specific de gestiune a datelor (SGF sau SGBD).

Concepia logic concret a unui sistem informatic dat se elaboreaz n etapa de proiectare logic, dar este bine s tim nc de pe acum ce este o concepie logic de principiu a sistemului informatic. Un asemenea model cuprinde: a) Intrrile n sistemul informatic: sunt acele modificri ale sistemului informaional care produc schimbri n coleciile de date, adic tranzaciile externe. Adeseori, modificrile pe care tranzaciile externe le produc direct coleciilor de date induc i un al doilea val de modificri ale acestora, sub forma tranzaciilor interne. Astfel o factur ce nsoete o tran de materiale venite de la furnizor este o tranzacie extern, pentru c modific soldul materialelor cuprinse n factur, dar ea induce i o modificare a soldului furnizorului respectiv, ceea ce este o tranzacie intern. Tranzaciile externe provin din exteriorul sistemului electronic de calcul, n timp ce tranzaciile interne sunt produse de procedurile de actualizare i exploatare a coleciilor de date. Este de datoria analistului de sisteme informatice s identifice nc din etapa de proiectare logic efectele secundare ale intrrilor n sistem i s consemneze necesitatea procedurilor care vor materializa aceste efecte asupra coleciilor de date, adic vor efectua tranzaciile interne ce se impun logic. b) Prelucrrile sistemului informatic: sunt efectuate de procedurile sistemului informatic i prin ele se urmrete s se realizeze actualizarea i exploatarea coleciilor de date. Dac baza informaional este format din ansamblul entitilor informaionale i a atributelor pe care acestea le au, coleciile de date preiau numai mulimea atributelor entitilor din baza informaional, aa numitul nucleu de informaii. Legturile dintre entiti apar atunci cnd ele au atribute comune. Mulimea entitilor informaionale din baza informaional trebuie s fie unic i neredundant. Ea trebuie s asigure un fond centralizat de informaii care s asigure obinerea ieirilor solicitate de beneficiarul sistemului informatic. c) Ieirile sistemului informatic: sunt grupate n patru categorii: c1) indicatori sintetici (ex. cifra de afaceri, profitul brut, fondul de rulment, capitalul propriu, rata rentabilitii, etc.); c2) liste sau situaii de ieire, care grupeaz indicatori sintetici sau analitici sub form de tabel; c3) grafice care redau dinamica indicatorilor sintetici sau analitici; c4) indicatori sintetici i analitici stocai pe suporturi magnetice care urmeaz a fi transmii altor sisteme informatice. Dat fiind complexitatea actului de elaborare a unui sistem informatic, de-a lungul timpului n acest domeniu s-au aplicat diferite paradigme i metodologii.

BAZA INFORMAIONAL NUCLEU DE INFORMAII PRELUCRRI SGBD sau SGF


COLECII DE DATE ORGANIZATE IN FIIERE SAU BAZE DE DATE
TRANZACII INTERNE

IEIRI
LISTE SITUAII DE IEIRE OBINUTE DE SISTEMUL INFORMATIC

INTRRI
TRANZACII EXTERNE

DOCUMENTE DE INTRARE IN SISTEMUL INFORMATIC

CREARE EXPLOATARE ACTUALIZARE LISTARE

PROCEDURI

MODIFICRI

LISTE DE ERORI

REGLAREA FENOMENELOR I PROCESELOR ECONOMICE DIN UNITATEA BENEFICIAR.

Reprezentarea schematic a concepiei logice de principiu a sistemului informatic

METODE DE ABORDARE A SISTEMELOR INFORMATICE


Nu este greu de neles c realizarea unui sistem informatic, sau doar a unei aplicaii, presupune modelarea situaiei reale i utilizarea modelului creat, n realitatea cu care opereaz calculatorul. Modelarea este reprezentarea ntr-un mediu controlat, a proprietilor i/sau fenomenelor i proceselor care caracterizeaz un obiect sau un sistem real. Cu alte cuvinte n modelare nu exist adevr absolut; modelarea presupune abstracie i aducerea n atenie numai a unor aspecte ale realitii studiate i anume acele aspecte care prezint interes pentru modelator. Unul din mediile controlate n care se poate reproduce realitatea, deci unul n care se pot face modele, este calculatorul. Pe calculator se realizeaz modele informaionale. Modelul informaional este o abstracie a unei entiti i aceast abstracie poate fi fcut fie pentru a crea un model general ( de referin) care s fie apoi folosit pentru a crea exemple concrete de sisteme informatice (cazul arhitecturilor de referin), fie pentru a crea modelul informatic al unei entiti anume, deci un model de transpunere. n cele ce urmeaz ne vom referi exclusiv la modele de transpunere. La crearea modelului intervine viziunea analistului despre realitatea pe care o studiaz, adic paradigma. Paradigma reprezint "ochelarii" prin care analistul vede sistemul informaional real, acela pe care vrea s-l modeleze, dar nu toate viziunile sau concepiile analitilor ajung s fie considerate paradigme. La nceputurile existenei sistemelor informatice, atenia analitilor a fost concentrat spre latura funcional a activitii umane studiate i cum o funcie a unui birou sau secie nu putea fi analizat i nici prelucrat n bloc, ea a fost descompus n activiti (rezultnd aplicaiile informatice), activitile au fost descompuse n subactiviti (rezultnd procedurile), care la rndul lor au fost descompuse n operaii, crora n calculator le corespondeau modulele program. S-a dezvoltat n aceste condiii o abordare funcional a sistemelor informaionale. n informatica industrial funciei i corespunde procesul, ceea ce a dus la abordarea orientat spre proces. Ulterior, locul fiierelor a fost luat de bazele de date i corespunztor, locul sistemelor de gestiune a fiierelor a fost luat de sistemele de gestiune a bazelor de date (SGBD). Pe parcursul perfecionrii SGBD-urilor, s-a trecut la baze de date relaionale , crendu-se impresia c elementul principal pe baza cruia trebuie perfecionate SGBDurile l reprezint structura datelor. Avem astfel de a face cu o abordare orientat spre date. Cnd s-a pus problema aplicaiilor n timp real, factorul cel mai important se prea a fi evenimentul. A aprut astfel abordarea orientat spre evenimente. Structurarea programelor a evoluat i ea odat cu metodele de analiz, dar era din ce n ce mai greu de inut pasul cu metoda de analiz, mai exact cu orientarea abordrii sistemelor informatice. Preocuprile analitilor-programatori pentru a pune n

concordan structura programelor cu metoda de analiz a sugerat o nou abordare i anume legarea evenimentelor de obiect i a programelor (numite de ast dat metode) de evenimente. A aprut astfel abordarea orientat pe obiecte, numai c spre deosebire de celelalte abordri, ea se extinde i n alte domenii de activitate, devenind un mod de a concepe realitatea, adic o paradigm. Dintr-un alt punct de vedere, exist dou mari viziuni de concepie a sistemelor informatice: abordarea ascendent (bottom-up) i abordarea descendent (top-down). Abordarea ascendent (bottom-up) are ca punct de plecare nivelul operaional (aflat la baza piramidei ierarhice) i, prin realizarea informatizrii la fiecare nivel n parte, se ajunge la un SI care poate atinge nivelul superior al piramidei. n acest caz n faza final ajungem s avem informatizarea complet a unui sistem informaionalorganizaional, specific unui organism economic supus analizei. Aprtorii acestei abordri avanseaz argumentul c este mai bine s acionezi progresiv, dect s mizezi pe ipoteza nerealist c un proiect global poate fi inut permanent la zi. Abordarea descendent (top-down) const n a cobor, pe scara piramidei ierarhice pn la baz, realiznd totodat i o analiz. Aceast viziune consider c un anumit domeniu este compus din pri corelate ntre ele i cu legturi cu exteriorul, fiind caracteristic pentru toate sistemele informaionale. Adepii acestei abordri consider c este mai bine s se creeze i s se realizeze din start un SI care s in cont de obiectivele planificate, abordat ntr-o manier global, dect s se ncerce a se integra a posteriori subsisteme informatice independente. Dat fiind complexitatea sistemelor informatice ele nu se pot obine dintr-odat i nici nu se pot realiza dup cum crede fiecare programator. Desigur la nceput aa a fost, dar pe msur ce s-a acumulat experien, ea a fost materializat n metodologii. Metodologia elaborrii sistemelor informatice a fost conceput iniial ca un ansamblu de principii i indicaii, tehnici i metode grupate i ordonate ca s duc la realizarea sistemului informatic. Cuvntul metod folosit n aceast definiie nu are nimic de a face cu metoda-program asociat evenimentelor unui obiect i nici cu metoda de abordare a sistemelor informaionale. Aici prin metod se nelege un set de reguli aplicabile unui domeniu restrns din cadrul unei metodologii. In prezent metodologia este vzut ca setul finit, particular definitoriu al unei metode (metod de abordare a sistemelor informatice), prin intermediul unui sistem coerent de formulare i/sau procese informatice, necesare pentru modelarea i formalizarea total a unui sistem informatic. Metodologiile evolueaz odat cu tehnologia informaiei, dar o metodologie de realizare a sistemelor informatice trebuie s cuprind: - etapele/procesele de realizare a unui sistem informatic structurate n subetape , activiti sarcini precum i coninutul lor; - fluxul realizrii acestor etape sau procese, subetape i activiti; - modalitatea de derulare a ciclului de via a sistemului informatic; - modul de abordare a sistemului; - strategiile de lucru/metodele de realizare; - regulile de formalizare a componentelor sistemului informatic;

- tehnicile, procedurile, instrumentele, normele i standardele utilizate; - modalitile de conducere a proiectului (planificare, programare, urmrire) i modul de utilizare a resurselor financiare, umane i materiale.

CICLUL DE VIA I CICLUL DE DEZVOLTARE A SISTEMELOR INFORMATICE


n legtur cu sistemele informatice sunt des folosite urmtoarele dou noiuni: ciclul de dezvoltare a sistemului informatic i ciclul de via al sistemelor informatice. Ciclul de via al sistemelor informatice (CVSI) se extinde pe intervalul de timp cuprins ntre decizia de elaborare a sistemului informatic i decizia de abandonare sau de nlocuire cu alt sistem informatic. Ciclul de dezvoltare a sistemului informatic (CDSI) se extinde de la decizia de elaborare a sistemului informatic pn la momentul intrrii sistemului n exploatare. Ciclul de dezvoltare a SI este inclus n ciclul de via al SI. n tabelul de mai jos sunt prezentate trei exemple de metodologii i de etapizare ale ciclului de dezvoltare. Aceste etape, sau altele (depinde de paradigma prin care vedem sistemul informaional i de modelul ales pentru CVSI ), trebuie respectate la o scar corespunztoare i n cazul aplicaiilor. De altfel, este recomandabil ca i atunci cnd ne propunem s realizm doar o aplicaie, s facem mai nti o analiz a ntregului sistem informatic, (evident " spnd" doar att de adnc ct este necesar pentru ca aplicaia noastr s fie compatibil cu aplicaiile existente i cu cele care vor fi realizate n viitor) i apoi s continum doar cu aplicaia ce ne intereseaz. Metoda SSADM (1982) - studiul de fezabilitate; - analiza cerinelor; - specificarea cerinelor; - specificarea logic; - proiectare fizic (inclusiv programarea); Metoda MERISE - studiul de evaluare; - modelarea global; - modelarea conceptual; - modelarea organizaional; - logic; - fizic; - implementarea (inclusiv programarea). Metoda ICI din Romania - elaborarea temei de realizare; - proiectarea de ansamblu; - proiectarea de detaliu; - elaborarea programelor; - implementarea sistemului.

Etapizarea ciclului de dezvoltare a SI (CDSI)

Modele reprezentative ale ciclurilor de via ale sistemelor informatice


1) Modelul cascad. Asigur trecerea de la o etap la alta, n ordine secvenial.
Definirea cerinelor Analiza

Proiectarea

Implementarea

Testarea

Utilizarea i ntreinerea

Fazele sunt structurate pe activiti i subactiviti. Punctul su slab este c se aplic la nivel sistem i nu se poate trece la etapa urmtoare pn ce nu au fost aduse la zi toate aplicaiile; n practic se solicit decalaje ntre aplicaii. 2) Modelul V. Braul stng al diagramei, parcurs descendent, reunete fazele n cadrul crora se realizeaz, pas cu pas, proiectarea i realizarea sistemului informatic. Detalierea activitilor de proiectare, codificare i asamblare a componentelor se realizeaz gradual. Braul drept al diagramei cuprinde reprezentarea fazelor asigurnd asamblarea progresiv a componentelor sistemului pe msura testrii lor individuale (aici se realizeaz verificrile i validrile), pn la obinerea sistemului global i acceptarea acestuia de ctre beneficiar. Braul drept se parcurge ascendent.
Definirea cerinelor Validare

Proiectare sistem

Testare sistem

Proiectare subsistem (component)

Testare subsistem (component)

Codificare asamblare componente

n cadrul modelului se remarc realizarea distinciei dintre verificare i validare. Verificarea se refer la testarea sistemului n diversele stadii pe care le parcurge, iar validarea urmrete s identifice n ce msur sistemul corespunde cerinelor iniiale, ceea ce constituie un punct slab al modelului datorit ntrzierii cu care se produce aceasta validare. 3) Modelul W. Acest model reia ideea modelului n V pe care l dezvolt i perfecioneaz prin integrarea activitilor de validare la nivelul fazelor de proiectare.

4) Modelul incremental. Permite livrarea sistemului pe componente, dar i global. Definirea cerinelor i analiza se execut totui la nivelul ntregului sistem. Este o metod de tip top-down, ceea ce implic cunoaterea i formularea cerinelor pentru ntregul sistem nc din faza incipient de abordare a sistemului, chiar dac ulterior se vor rezolva doar pri din el. De regul adugarea unei pri presupune testarea a tot ce este realizat pn n acel moment, ceea ce poate duce la modificri multiple ale componentelor realizate printre primele.

Definirea cerinelor Analiz

Proiectare componenta-1 Implementare componenta-1

Instalare componenta-1 ntreinere componenta-1

Arhitectura sistemului

--Proiectare componenta-n Implementare componenta-n

--Instalare componenta-n ntreinere componenta-n

5) Modelul spiral. Modelul presupune construirea mai multor prototipuri succesive n condiiile realizrii unei analize a riscului pe fiecare nivel. Fazele de dezvoltare sunt reluate la fiecare iteraie n aceeai succesiune i presupun: Analiza riscurilor Realizarea unui prototip Simularea i testarea prototipului Determinarea cerinelor n urma rezultatelor testrii Validarea cerinelor Planificarea ciclului urmtor Modelul presupune proiectarea sistemului, realizarea primului prototip funcional, verificarea msurii n care rspunde cererilor formulate de utilizator i rafinarea acestei prime soluii, prin dezvoltri viitoare care adaug noi funcionaliti pn la obinerea variantei finale a sistemului.

6) Modelul evolutiv. Necesit efectuarea unei investigaii iniiale pe baza creia s se poat elabora o strategie de descompunere a proiectului n pri/segmente, fiecare cu o valoare deosebit pentru client. Acestea sunt realizate i livrate n mod iterativ i contribuie la sporirea treptat a performanelor sistemului. Se are n vedere posibilitatea aplicrii unor adaptri sau modificri ulterioare.
Studiul iniial Descompunere n segmente Integrare segmente

Segment-1 Definire cerine Implementare Analiz Testare Proiectare Utilizare

Segment-2 Definire cerine Implementare Analiz Testare Proiectare Utilizare

Metoda are succes deoarece se bazeaz pe o arhitectur deschis, flexibil, elaborat prin participarea tuturor prilor interesate, inclusiv a utilizatorilor i a unor specialiti profesioniti. 7) Modelul X. n partea de sus a X-ului este aplicat modelul cascad i V, iar n partea de jos sunt avute n vedere aciuni de valorificare a softului creat anterior. Aceast preocupare este din ce n ce mai extins pe plan mondial i pare foarte raional deoarece softul prezint o mare suplee n ce privete adaptarea de la o problem la alta. De fapt nu conteaz dect asemnarea structurilor, semnificaia variabilelor fiind la libera alegere a celui care folosete softul. n partea de sus, modelul ia n consideraie utilizarea unor specificaii de sistem, a proiectului arhitectural i de detaliu , codificarea, testarea pe componente, integrarea i testarea sistemului. Parte inferioar a X-ului este un V ntors, pentru a sugera noiunea de gestiune patrimonial a depozitelor reutilizabile la nivel component, structur, domeniu i chiar aplicaie. Avnd n vedere c partea inferioar a modelului se aplic practic doar n fazele de proiectare fizic, modelul - ca i modelul tridimensional al autorilor metodei Merise, nu este prea popular. Dealtfel metoda Merise mai prezint un model n dou dimensiuni n care pe abscis este trecut sistemul actual i cel viitor, iar pe ordonat sunt trecute nivelele global, conceptual, organi-zaional, logic, fizic i de exploatare, dar dup cum s-a putut vedea, din cele prezentate n seciu-nea 1 a acestui capitol, metoda Merise este aplicat de fapt pe un model n dou dimensiuni, sub form de matrice care este foarte riguros i se preteaz la exigenele ingineriei softului. 8) Modelul tridimensional. Modelul tridimensional promovat de metoda de proiectare MERISE se caracterizeaz prin reprezentarea grafic pe trei axe, fiecare dintre acestea corespunznd ciclului de via al sistemului, ciclul de decizie i respectiv ciclului abstractizrii.

METODE DE PROIECTARE A SISTEMELOR INFORMATICE


1) Metode structurate
- prima generaie, anii '70 - sistemul informaional/informatic este structurat pe baza funciilor sale; - centrate pe analiza funcional: fiecare funcie identificat se subdivide ierarhic n subfuncii, continund n aceast manier pn se ajunge la componente suficient de mici astfel nct acestea s poat fi programate cu uurin. F1

F11

F12

F111

F112

F121

F122

F123

Exemple: SADT (Structured Analysis and Design Technique), JSD (Jackson System Development), Yourdon. Avantaje: Simplitate, bun adaptare la definirea cerinelor utilizatorului; Dezavantaje: Concentreaz efortul de analiz asupra funciilor (de prelucrare) neglijnd coerena datelor (a cror structur este totui mult mai stabil dect a prelucrrilor); volatilitatea cerinelor utilizatorilor (funciilor) face ca aplicaiile s fie ntr-o aproape continu reconsiderare.

2) Metode sistemice
- generaia a doua, anii '80; - se bazeaz pe aplicarea teoriei sistemelor n analiza ntreprinderii; - sistemul informatic este abordat sub dou aspecte complementare: datele i prelucrrile,
care sunt studiate i modelate independent i reunite ct mai trziu cu putin;

- acord prioritate datelor fa de prelucrri; - respect cele trei niveluri de concepie introduse prin raportul ANSI/SPARC: conceptual, logic i fizic;

- se disting patru niveluri de abstractizare : Nivelul conceptual exprim opiunile de gestiune, formulnd ntrebarea : Ce facem? Nivelul organizaional exprim alegerile ntreprinderii legate de resurse umane i materiale. Se pun urmtoarele ntrebri : Cine ? Unde ? Cnd ? Cum ? Nivelul logic permite alegerea mijloacelor i a resurselor informatice, fcnd abstracie de caracteristicile lor tehnice precizate. Nivelul fizic este reprezentat prin alegerile tehnice, urmrind specificitatea lor. La fiecare nivel de abstractizare, SI este reprezentat prin trei modele : datele, prelucrrile, comunicrile. - exemple : MERISE, AXIAL, Information Engineering (J. Martin). Avantaje: sistemele se axeaz pe conceptul de baz de date, care ofer mai mult coeren, stabilitate i elimin redundanele. Dezavantaje: deficiene n modelarea prelucrrilor, posibilitatea apariiei de discordane ntre modelele datelor i ale prelucrrilor.

3) Metode orientate obiect (obiectuale) - generaia a treia, anii '90;


- se acord acord atenie deosebit att structurii datelor, ct i structurii funcionale; - sistemul informaional/informatic este perceput ca o structur de obiecte autonome, ce se organizeaz i coopereaz ntre ele; - un obiect are un anumit comportament, definit prin ansamblul operaiilor (serviciilor) pe care le poate efectua; datele i prelucrrile prin care este implementat acest comportament sunt ncapsulate (mascate) i sunt inaccesibile celorlalte obiecte; - fiecare obiect poate participa la compunerea altor obiecte mai complexe; - fiecare obiect poate interveni n mai multe funcii sau scenarii funcionale diferite. Exemple: OOD (Booch), OMT (Rumbaugh), OOA/OOD (Coad), OOM (Rochfeld).

O1

O3

O5 O7

O2

O4

O6

Metodele orientate obiect se caracterizeaz prin definirea a trei modele : Modelul obiectelor are rolul de a descrie obiectele care intervin n problema de rezolvat i relaiile dintre ele. Modelul obiectelor reprezint descrierea structurii statice a obiectelor, claselor de obiecte, a operaiilor i atributelor, precum i a legturilor i a relaiilor dintre ele. Modelul dinamic are rolul de a descrie strile pe care le poate avea un obiect i evenimentele la trecerea dintr-o structur n alta. Modelul dinamic descrie interaciunea dintre obiecte i este focalizat pe aspecte ce se schimb n timp. Modelul funcional are rolul de a descrie prelucrrile i fluxurile de date. Modelul funcional prezint transformrile valorilor datelor, preciznd sursa i destinaia lor. Avantaje: permite reutilizarea componentelor de program, favorizeaz modelarea i utilizarea de obiecte complexe. Dezavantaje: percepia i reprezentarea monolitic de tipul "totul este obiect" nu corespunde ntotdeauna realitii reprezentate.

S-ar putea să vă placă și