CAPITOL

METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC

2.1. Cerine generale n utilizarea unei metode de proiectare a sistemului informatic

Evoluia tehnologic presupune o anumit infrastructur care trebuie s cuprind pe lng hardware, produse i sisteme informatice bazate pe noi sisteme de gestiune a bazelor de date sau pe noiunea de teletransmisie materializat prin reele naionale de date cu rate de transfer ct mai mari; posturi de lucru la toate nivelele operaionale dintr-o unitate (sisteme interactive ommain). Mediile economice trebuie s se adapteze rapid la aceste tehnologii care presupun costuri relativ ridicate ocazionate de elaborarea i ntreinerea produsului informatic, dar i dificultilor crescnde de meninere la anumite standarde a nevoilor utilizatorilor. Necesitatea adaptrii devine stringent n mediul financiarcontabil care privete schimbrile ntr-un orizont de timp ca pe o protecie a investiiei. Continua dezvoltare a domeniului tehnologiei informaiei impune elaborarea de noi metodologii pentru realizarea sistemelor de aplicaii informatice, cristalizndu-se n analiz i proiectare dou tipuri de metode utilizate: tradiionale (structurate, orientate pe funcii/date, metode sistemice) i metode orientate obiect.

34

Aportul fiecrei metode concretizat printr-un limbaj comun utilizatorinformatician este manifestat pe parcursul ntregului proces de studiu prin apariia i existena punctelor de validare. Metoda, produs al reflexiei permanente, constituie un demers raional i empiric, deductiv i inductiv. Conform unor specialiti, metoda reprezint un ansamblu de mijloace industriale puse n practic pentru organizarea unei fabricaii sau un ansamblu de reguli, principii normative care corespund nvmntului, practicii i artei 14 . Ea se aplic tuturor conceptelor create de tehnologie, care observ i analizeaz practica cotidian din organizaii. Retrospectiv se constat c evoluia tehnologiei informatice15 are un impact important asupra metodelor de producere a sistemelor informatice. Un alt aspect care trebuie remarcat este faptul c o metod nu poate servi scopuri fundamentale divergente. Marea varietate de soft-uri disponibile (sisteme logice, sisteme de gestiune n timp real) i dezvoltarea activitii de producie software, m conduc la ideea c n informatic o metod universal nu este posibil. Orice metod de concepie a unui sistem informatic trebuie s ia n considerare factorii de natur tehnic i socio-economic. n domeniul tehnic trebuie s permit derularea activitilor n timp real, utilizarea bazelor de date, a instrumentelor mini i micro-informatice pe fondul resurselor materiale, umane existente sau atrase. n domeniul social i economic metoda trebuie s integreze obiectivele unor categorii de ageni care urmresc descentralizarea deciziilor operative; simplificarea sarcinilor i ameliorarea ergomiei postului de lucru; securitate i confidenialitate; dezvoltarea proceselor de gestiune prin creterea posibilitii de supervizare la diverse nivele; suplee tehnic i comercial sau structural strict necesar n situaii de fuziune, extindere. Metoda vizeaz asocierea eficient a aspectelor organizaionale i informatice; creterea calitii relaiilor utilizatoriinformaticieni, reprezentnd un mijloc comun de studiu, concepie, dialog, formalizare a deciziilor i de control preventiv. Cu alte
14 15

Le Nouveau Petit Le Robert, Edition 1993 OBrien J. - Systmes dinformation de gestion, De Boeck Universit

35

cuvinte, metoda n cadrul unui organism economic trebuie s fie un mijloc precis, eficace, suplu dar nu rigid.

2.1.1. Parametrii specifici de performan pentru sistemele informatice

Calitatea informaiilor determin n mare msur performanele compartimentului financiar-contabil, atingerea obiectivelor pe care firma i le-a propus. Exist dou abordri ale performanei: una ce dezvolt o situaie stabil a sistemului i o alta care pune n valoare dinamismul, noutatea n domeniul considerat. n cazul unor schimbri apare problema determinrii valorii informaiei noi; definit prin efectul deciziei posibile de adoptat. Existena stabilitii mediului informaional induce aprecierea global a sumei atuurilor sistemului informatic financiar-contabil (S.I.F.C.). Pentru un control eficient al modului de realizare al sarcinilor stabilite apreciez c exist dou soluii: funcionarea controlului intern de gestiune; reconsiderarea rolul tabloului de bord i a bugetelor. n acest context propun abordarea compartimentului financiar-contabil n trei ipostaze (figura 2.1.):

Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiiei

36

a) centru de costuri unde utilizatorii decideni i managerul i asum responsabiliti sporite n gestionarea a costurilor, iar performanele vor fi judecate prin capacitatea de a micora ecarturile raportate la costurile previzionale, de a sporii productivitatea i de a propune soluii (aciuni) generatoare de profit. b) centru de profit scoate n relief faptul c dei profitul obinut de contabilitatea informatizat nu este autentificabil n sine, trebuie s considerm c ea este un prestator de servicii ce se adreseaz unor beneficiari bine identificai. Opinia mea este c profitul mediului contabil este indus de beneficiile obinute de celelalte segmente ale firmei sau de aceasta ca urmare a folosirii produselor informatice. Rezultatele obinute pot fi apreciate, extrem de clar prin relaia: numr de lucrri (aspect cantitativ), timp coninut lucrare (aspect calitativ). c) centru de investiie vizeaz contabilitatea informatizat care trebuie s ctige autonomie n efectuarea investiiilor (informatice) i apoi se impune s le justifice. Pentru zona contabil informatizat putem vorbi de reliefarea unor plusuri cantitative (economice) i calitative (politice). n legtur cu primul aspect consider c viteza de circulaie a informaiei, dar i capacitatea ei de adaptare se pot constitui n resurse importante. Remarc dou faete ale acestui tip de performan: Ctigurile directe de productivitate permit executarea unei aceleiai

atribuii (decizii), cu mijloace reduse. De exemplu: o suprafa ocupat mai mic, utilizatorii decideni mai puini, costuri ale hardului, softului sau reelei mult diminuate. Creterea volumul activitilor financiar-contabile, unde informaia

suplimentar poate avea un impact pozitiv asupra domeniului contabil informatizat, dar numai n msura n care are desfacerea asigurat. Performanele politice (calitative) sunt mult mai greu de evideniat sau mai ales de comensurat. Consider c cele mai importante obiective ale unei metode sunt: flexibilitatea sistemului;

37

 satisfacia utilizatorilor; calitatea produselor financiar-contabile. Flexibilitatea reprezint capacitatea de adaptare a structurii contabilitii informatizate la mediu. Un sistem deschis, cu numeroase puncte de ascultare i cu o grij deosebit pentru comunicaie (oral, scris sau electronic) va reaciona rapid la oportuniti i va putea s in cont de restricii. Flexibilitatea se va aprecia prin raportarea la un anumit obiectiv, fixat n cadrul unei evoluii istorice. Sistemul deschis va avea n vedere i practicile agenilor economici16. Satisfacia utilizatorilor decideni reprezint criteriul de apreciere a performanei sociale stabilit de actorii participani la procesul productiv creativ. Calitatea produselor financiarcontabile este apreciat subiectiv de diferiii beneficiari: clieni, banc, manageri etc., dar i obiectiv - prin deducerea deeurilor informaionale, a erorilor etc. Depinde foarte mult de ateptrile diverilor consumatori (din interiorul sau exteriorul firmei), dar i de sistemul de producie financiar contabil n ansamblu (inclusiv modalitile de control). n continuare voi prezenta cteva criterii de apreciere a performanelor zonei contabile informatizate pe care, dup prerea mea, le consider eseniale: a) criteriile de natur tehnic au n vedere coninutul sistemului, capacitatea acestuia de a ndeplini funcii specifice. Vor fi luate n considerare att aspectele legate de producerea de informaii utile, ct i cele ce privesc gestiunea sistemului i a firmei. b) criteriile organizaionale reduc incertitudinile sistemului informatic financiarcontabil i permit grefarea pe structura acestuia. Creterea capacitii lui de prelucrare ori gradul su de deschidere va determina modificri structurale ce se impun a fi pe deplin stpnite. Apreciez c fiind necesar analiza evoluiei i a adaptrilor prin prisma urmtoarelor stri ale structurii: - specializare - gradul n care activitile financiar-contabile sunt divizate pe roluri" specializate, n funcie de pregtirea utilizatorilor decideni.

38

- standardizare - msura n care sunt stabilite reguli i proceduri generale pentru a defini sarcinile de executat i a controla aplicarea lor. Informatizarea contabilitii duce la crearea de noi proceduri, le elimin pe cele redundante sau neutilizate. - formalizarea - nu este legat implicit de noile tehnologii, depinznd uneori de gradul de pregtire al utilizatorilor decideni. - centralizarea - vizeaz importana acordat lurii deciziilor de ctre manager, urmrindu-se s nu se accentueze fenomenul birocratic. n categoria criteriilor organizaionale de apreciere a performanelor segmentului financiarcontabil informatizat cred c se impune a fi inclus i msurarea gradului de schimbare. n acelai timp este important i cunoaterea atitudinii utilizatorilor decideni, n vederea anticiprii unei eventuale reacii de respingere (putndu-se folosi n acest sens metodologia CRIG). c) criteriile economice - utilizarea lor are n vedere tipul proiectului i etapa procesului de decizie. Dup prerea mea exist dou mari categorii de repere n stabilirea dimensiunii contabilitii informatizate: unele ce i propun s urmreasc costurile i avantajele (metode a posteriori) i altele care doresc s efectueze demersuri pentru o analiz complex n vederea alegerii investiiei (metode a priori). Consider c, pentru zona contabilitii informatizate, putem pune n eviden mai multe praguri i msurri ale eficienei: (Keg): Keg = (Ec + As) / (Chi + Che) unde: Ec - economii rezultate prin introducerea tehnologiilor informatice i de comunicaie. As - acumulrile suplimentare; Chi - cheltuieli de implementare; coeficientul eficienei globale a sistemului informatic financiar-contabil

16

Transition from the data/processing, www.softeam.com/conseil_modelisation

39

Che cheltuieli de exploatare a sistemului. Calea principal de cretere a eficienei sistemelor informatice este reducerea cheltuielilor prin: utilizarea de elemente standardizate i tipizate; elaborarea bugetului informatic i controlul realizrii indicatorilor prevzui; mbuntirea parametrilor de exploatare a aplicaiilor informatice. Cu ct durata de recuperare a cheltuielilor cu caracter informatic (ce privesc echipamentele, programele, reelele) este mai mic, cu att standardele vor fi mai mari i se vor nregistra acumulri suplimentare (implicit profit net). durata de recuperare a cheltuielilor este invers proporional fa de

coeficientul eficienei globale.(Dr): Dr = 1/Keg Se va avea n vedere totalitatea cheltuielilor (de investiie, de exploatare) iar sistemul informatic se va aprecia ca fiind eficient dac Keg >1, iar Dr <5. Performanele sunt direct legate i de dimensionarea optim a sistemului informatic financiar contabil aa cum este prezentat mai jos: Caracteristicile sistemului
Abordare orientat client

Efectele economice

Efect de anvergur (eficiena partajrii resurselor i eficacitatea utilizatorilor decideni) Baz comun a prelucrrilor i Efect de anvergur (cost al sistemului integrat < comunicaiei costurile a dou neintegrate) Evoluie progresiv Reducerea efectului de complexitate Portabilitate Efect de anvergur (partajarea aplicaiilor pe platforme mai eficiente) Convivialitate Efecte de nvare i experien (reducerea costului de pregtire) Performana sistemului: Efect de anvergur (diminuarea costului de prelucrare i transmitere) - optimizarea prelucrrilor - optimizare traficului

Remarc anumite forelor motrice care ajut la formarea rezultatului sistemului informatic financiarcontabil: producia informaional i modalitile de

40

valorificare a acesteia; preurile de aprovizionare cu diferite materiale; evoluia salariilor utilizatorilor decideni i/sau a managementului; costul de ntreinere i reparare al reelei sau echipamentelor etc. Contribuia fiecrui factor asupra evoluiei profitului se determin utiliznd procedeul substituiilor n lan care permite msurarea influenelor sau a alternativelor.

2.1.2. Necesitatea i structura procesului de evaluare a contabilitii informatizate

Liniile de for ale evalurii contabilitii informatizate se bazeaz pe dou puncte eseniale: eficacitatea i eficiena. Exist o raportare permanent a contabilitii informatizate la un sistem de referin (referenial) i o legtur direct cu actul deciziei, fapt ilustrat n figura 2.2.

Figura 2.2 Legturile aferente actului decizie

Operaia de evaluare n cadrul sistemului informatic financiar-contabil va ine cont de trei elemente fundamentale: resursa uman; raporturile de putere; referenialul.
41

Pentru o evaluare corect i complet a contabilitii informatizate consider c se impune s se cunoasc foarte bine contextul, practicile existente, dar i cultura" sau istoricul. Dup prerea mea soluia apelrii la experii din exterior nu este ntotdeauna cea mai bun deoarece ei se intereseaz mai mult de analiza disfuncionalitilor dect de efectele declanate de comportamentul sistemului. Procesul de evaluare a unui sistem presupune parcurgerea urmtoarelor faze: selecia, interpretarea i decizia. A. Faza de selecie permite obinerea unei imagini sistemic a situaiei i pentru a nu lua decizii cu consecine negative se stabilesc foarte clar factorii de tip selectiv. Acetia pot fi de natur economic, tehnic, organizaional, politic sau sociologic i se refer la aspecte cantitative i calitative ntre care apare o vie concuren. n acest fel se va evita creterea sarcinilor administrative i a efectelor, accentuarea complexitii cutrii i seleciei datelor, depirea unui nivel al costurilor dificil de suportat. Managerul trebuie s obin maxim de informaii pentru a reduce incertitudinea n faa creia se afl, ns n unele situaii consum foarte mult timp cu aceast preocupare i nu-i mai rmne dect foarte puin pentru activitile de decizie efective (mai ales de tip strategic). J.C. Emery i G.A. Miller arat c n mod normal capacitile cognitive ale unui om nu pot nelege simultan mai mult de 5-9 informaii noi - chunks17. Faza de selecie presupune nelegerea comportamentului sistemului informatic financiar-contabil, plecnd de la tendinele existente n cadrul lui, precum i de la liniile sale de for. Apare evident evaluarea strategic fa de cea operaional. Consider c informatica, inteligena artificial (n special sistemele expert) pot aduce un ajutor substanial n faza de selecie, prin consultarea bazelor de cunotine mbogite cu experiena trit, utiliznd i facilitile procesoarelor de tabele. B. Faza de interpretare. n cadrul acesteia n procesul de evaluare a

contabilitii informatizate pot apare probleme legate de: puterea simbolurilor, fluiditatea catartic", dinamica actului de evaluare.
17

Associations Links, www.macs.hw.ac.uk/ism/ug4

42

Puterea simbolurilor reprezint pentru muli utilizatori decideni sinonim cu descentralizarea, autonomia i creterea productivitii muncii. Ei i construiesc diverse agregate simbolice legate de atuurile folosirii calculatorului pe propriul birou. Fiecare agregat va poseda un coninut catartic specific, astfel pentru unii indivizi reelele de telecomunicaie vor constitui puni spre o nou er a comunicaiei, n schimb pentru alii vor fi doar surse a numeroase pericole. Orice metodologie de utilizare a unei anumite situaii din cadrul contabilitii informatizate, inclusiv stabilirea unui diagnostic corespunztor va implica un demers riguros cu trei laturi: evaluarea criteriilor ce determin parametrii obiectivi ai unei anumite reprezentri (de tip cantitativ); evaluarea criteriilor care duc la stabilirea ordinii congruenelor n gndirea contabilului ef i a utilizatorilor decideni; valorizarea soluiilor prin implicarea noilor restricii pentru sistem.
Paradigm

Evaluare criterii cantitative

Evaluare criterii calitative

Valorizare soluii decideni

Parametrii obiectivi

Gndire decideni

Restricii

Figura 2.3 Criteriile de analiz a unei situaii

Fluiditatea catartic este o noiune care a fost pus n eviden de cercettorul Bruno Lussato i se refer la mobilitatea mai mult sau mai puin important a transferului de rezonan a unei reprezentri R spre o reprezentare RI, ignorat pn
43

atunci". Fluiditatea parametrilor de interpretare a elementelor structurale ale contabilitii informatizate va fi influenat de faptul c, interpretarea nu poate avea valoare dect ntr-un spaiu temporal definit prealabil. Fluiditatea determin stabilirea unei anumite ponderi pentru fiecare criteriu evaluat la un moment dat. Vom putea distinge n zona contabil informatizat trei tipuri de criterii: primordiale (exemple: mrimea intervalelor de timp, compatibilitatea resurselor); importante (exemple: posibilitile de adaptare la nou, capacitatea de a evita hipertrofierea configuraiilor informatice, inclusiv alinierea acestora la obiectivele urmrite); eliminate din evaluare (exemple: compatibilitatea mrcilor de echipamente, posibilitatea de autoformare a utilizatorilor decideni). Dinamica actului de evaluare reliefeaz cultura sistemului mai ales slbiciunile vizibile sau ascunse. Uneori aceste minusuri pot fi imaginare, fiind vorba de fapt de lacune ale criteriilor, o greit definire (structurare), o percepie eronat, o varietate (incoeren) exagerat. C. Faza de decizie apare ca rezultat al unei cooperri i a unui limbaj comun ntre diferiii actori din sistemul informatic financiarcontabil. Unele decizii admise n trecut nu mai puteau fi nelese la un moment dat, datorit modificrii punctelor de vedere i a mediului, putnd dobndi caracter ireversibil. Apreciez c evaluarea elementelor componente ale compartimentului financiarcontabil prin metoda scenariilor va avea n vedere, de fiecare dat trei mari etape: stabilirea scenariilor i evaluarea efectelor previzibile; valorizarea acestora; alegerea soluiei care este considerat ca fiind cea mai bun. n figura 2.4 am redat aplicarea metodei scenariilor asupra elementului structural financiar-contabil. A imagina un scenariu presupune construirea de structuri, de sisteme decizionale i repartizarea pe roluri (stabilirea responsabilitilor). Uneori decizia final este sinteza rezultatelor diferitelor decizii intermediare luate. Valorizarea scenariilor va avea un caracter relativ dac se oprete doar la aspectul pur informatic i dac nu va urmri i noiunea de utilitate. Aceasta din urm este dificil de stabilit, deoarece fiecare utilizator decident, plasat n faa unei aceleiai situaii, va avea obiective i scopuri diferite.
44

Figura 2.4 Evaluarea compartimentului financiarcontabil prin metoda scenariilor

Valorizarea va ine cont de natura informaiei (operaional, tactic, strategic) i va impune exprimarea utilitii produciei i difuzrii acesteia. Optimul soluiei nu este obligatoriu cel mai bun raport performan/pre (o sum la nivel operaional nu va avea aceeai valoare cu cea de la nivelul strategic). Apreciez c, nu exist alegeri bune sau rele, totul depinde de sistemul de referin (referenialul) ales, dac aceasta se schimb rezultatele evalurii se vor modifica.

2.2. Metodele de concepie i de realizare a unui sistem informatic

Metodele de concepie se pot clasifica n trei mari categorii: metode structurate; metode sistemice; metode orientate obiect. Metodele structurate folosesc descompunerea progresiv descendent top-down; ele fiind n fapt carteziene. Concepia const n crearea, pornind de la specificaiile, unui ansamblu unitar n interaciune avnd fiecare o funcie clar definit. Diagramele de fluxuri de date descriu prelucrrile logice ale datelor i arat maniera n care datele intrate sunt modificate printr-o suit de transformri funcionale pentru a ajunge la datele de ieire. Cele mai cunoscute metode aparinnd acestei prime generaii sunt: SADT (Structured Analisys and Design Technique), JSD
45

(Jackson System Development), Yourdon etc. Toate au la baz analiza funcional a ntreprinderii. Diagramele de structur permit vizualizarea structurii ierarhice, descrierea programului sau a unui modul fiind stabilite pe mai multe niveluri, prin rafinri succesive. Metoda SADT propune un ansamblu de diagrame ordonate ierarhic n care fiecare poate fi considerat fie ca o diagram printe (sintez a diagramelor sale fiu), sau ca o diagram fiu (dezvoltare a unei pri a celei printe). n cazul metodei SADT, datele i prelucrrile sunt examinate mpreun definindu-se actigrame (sau diagrama activitilor) i datagrame (diagrama datelor).

Figura 2.5 Diagrama fluxurilor de date pentru Clieni

Avantajele metodelor ierarhice constau n simplitate i o bun adaptare la cerinele formulate de utilizator. Dezavantajele pornesc de la conceperea sistemelor informatice conform cerinelor analizei funcionale, ceea ce determin concentrarea efortului de analiz i proiectare asupra prelucrrilor n condiiile n care acestea sunt cele mai supuse modificri n timp, modelarea datelor cznd pe un plan secund. Proliferarea aplicaiilor creeaz propriile lor fiiere ducnd la redundane i mai ales incoeren a datelor n sistemele de informare a organizaiilor. Metodele structurate au fost integrate n S.G.B.D. prin limbajul de descriere a datelor.

46

Metodele sistemice permit vizualizarea i nelegerea organizrii datelor. Aceste metode se compun din abstractizri care prezint lumea real ca pe o colecie de entiti i de legturi, stabilite ntre acestea. Majoritatea permite definirea de restricii descriind aspectele statice, dinamice sau chiar temporare ale entitilor. n aceast calitate ele constituie formalisme lizibile n cadrul specificaiilor de nevoi. Dou metode constituie referina de reprezentare semantic: metoda individual18 care va fi integrat Merise i metoda entitaterelaie19. Amintesc printre metodele sistemice pe cele de concepie n timp real care asigur funcionarea corect n funcie de rezultatele produse prin sistem i de momentul la care ele sunt produse. Acestea reprezint oarecum un sistem de stimuli/rspuns; stimulii fiind generai de captatori sau de acionari. Atunci cnd stimulii sunt aperiodici se poate concepe un sistem ca un ansamblu de procese paralele care coopereaz de o manier n care transfer controlul componentei apropiate, de la recepia unui stimul. Se disting dou clase active n timp real: sistemele de urmrire-control; sistemele de cumulare de date. Sistemele de urmrire i control cerceteaz n permanen numrul de captatori, i n funcie de valoarea lor, declaneaz aciuni care eficientizeaz acionarii (de exemplu sistemele de alarm antifurt din imobile). Sistemele de cumulare de date culeg datele captate pentru procesare i analiz. Perioadele procesului de achiziie i cele ale procesului de procesare nu sunt n armonie. Astfel apar diferene de vitez dictate de recurgerea la un mijloc de stocare (tampon). Sistemul este organizat dup modelul productorconsumator cu mecanisme de excludere mutual, pentru a evita cazul unde productorul i consumatorul de date acced, n acelai timp, la elementul tampon. Aceste metode recurg la diverse formalisme, de remarcat fiind cele din reele Petri pentru aspectul dinamic care au fost dezvoltate de formalizri specifice.

Tardieu H. i col. - The individual model, International WorkShop on Data Structure Models for Informations Systems 19 Chen P.- The entity-relationship model, ALM transaction of database systems, 1, 1, mars 1976

18

47

Metodele sistemice cuprind de o manier global sistemul informaional i reprezint a doua generaie a metodelor de proiectare. Reprezentative sunt metodele Information Engeneering, MERISE, AXIAL etc. Apropierea se realizeaz la nivel conceptual20 i se disting patru nivele de abstractizare. 1. Nivelul conceptual exprim opiunile de gestiune; formulnd ntrebarea: Ce facem? 2. Nivelul organizaional exprim alegerile ntreprinderii legate de resurse umane i materiale. Se integreaz la acest nivel noiunile de timp, loc de actori i se pun urmtoarele ntrebri: cine, unde, cnd i cum? 3. Nivelul logic permite alegerea mijloacelor i a resurselor informatice fcnd abstracie de caracteristicile lor tehnice precizate. 4. Nivelul fizic este reprezentat prin alegerile tehnice urmrind specificitatea lor. La fiecare nivel de abstractizare sistemul de informare este reprezentat prin trei modele: datele, prelucrrile, comunicrile. Ceea ce este specific acestor metode este utilizarea teoriei sistemelor n analiza ntreprinderii. Sistemul informatic este abordat sub dou aspecte complementare, datele i prelucrrile analizate-modelate independent cu reunirea lor ct mai trziu posibil. Spre deosebire de metodele ierarhice, metodele sistemice acord prioritate datelor fa de prelucrri i respect cele trei nivele de abstractizare introduse de raportul ANSI/SPARC: conceptual, logic i fizic21. Avantajele metodelor sistemice apar din promovarea tehnologiei bazelor de date. Dezavantajele sunt datorate deficienelor care pot aprea n modelarea prelucrrilor i a discordanelor posibile ntre modelele datelor i prelucrrilor. Metoda orientat obiect este caracterizat prin atenia deosebit acordat concomitent structurii datelor i structurii funcionale. Aceast viziune permite construirea unei baze stabile n procesul de dezvoltare a modelului i utilizarea conceptului obiect, unitar de-a lungul ntregului ciclu de via. Toate celelalte concepte: funcii, asocieri, evenimente graviteaz n jurul obiectelor, astfel nct nu este necesar trecerea la alte notaii sau interpretri de semantic n diferite etape de dezvoltare. Metoda orientat obiect se caracterizeaz prin definirea a trei modele:
20 21

Nanci D. i col. - Ingnierie des systmes dinformation avec Merise, Sybex Stanciu V. i col. - Proiectarea sistemelor informatice, Editura Dual Tech, Bucureti

48

Modelul obiectelor are rolul de a descrie obiectele care intervin n problema de rezolvat i relaiile dintre ele. Modelul obiectual 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, deoarece orice obiect are un ciclu de via cu un punct de pornire i unul de sfrit. Modelul dinamic descrie acest ciclu de via, ce se ntmpl de-a lungul su i cum este influenat obiectul.

Modelul funcional are rolul de a descrie prelucrrile i fluxurile de date. Modelul funcional prezint transformrile valorilor datelor preciznd sursa i destinaia lor.

Avantajele oferite de metoda OMT sunt valorificate pe deplin n proiectarea i realizarea de sisteme informatice care trebuie s rspund unor noi cerine i anume: Reprezentarea complex a realitii (firm, clieni, produse, servicii, etc.); Informaia gestionat n cadrul unui sistem informatic are tendina de cretere n complexitate, iar manipularea ei trebuie s fie ntr-o form uor de perceput de ctre utilizatorul final; Sistemele informatice realizate trebuie s fie flexibile n raport cu modificarea structurilor de date i trebuie s evolueze natural n timp, urmnd astfel evoluia organismului economic, bancar, financiar pe care l deservete; Sistemele informatice evolueaz spre abordri multimedia care combin text cu foi de calcul, grafice, animaie i voce. Majoritatea metodelor orientate obiect utilizeaz reguli sau operaii semantice: generalizarea/specializarea, agregarea/descompunerea, combinate cu motenirea i ncapsularea.

49

2.2.1. Caracterizarea metodei Merise

Metoda MERISE asigur proiectarea de sisteme de gestiune ambiioase permind dualitatea ntre tratamentul evenimentelor trecute i furnizarea elementelor de previziune aplicabile centrelor de responsabilitate. Ea dispune de toate instrumentele care s permit realizarea etapizat a unui sistem informatic cu grad mare de integrabilitate, pornind de la localizarea unui subansamblu reprezentativ. Numele metodei este abrevierea de la Methode dEtude et de Realisation Informatique par le Sous Ensemble representatif. Utilizarea metodei MERISE trebuie s fac posibil descompunerea problemelor de organizare a muncii. Practica n acest domeniu a evoluat considerabil traversnd un curent de gndire numit sistemic sau, ceea ce alt dat, se numea teoria sistemelor. Din raiuni didactice, pe parcursul nsuirii metodelor sistemice se poate asocia figurativ enunul urmtor: a se ridica pentru a vedea mai bine...a nelege...pentru a aciona mai bine. Acest curent de gndire care a cuprins i alte discipline de cercetare, a oferit garania stabilitii i evoluiei metodei, fiind baza filosofiei MERISE22 iar toate conceptele operatorilor sistemici pentru tiina organizrii sunt asimilai i n cadrul acestei metode. A nelege nu este suficient pentru a aciona, trebuie i s...decizi constituie al doilea suport al filosofiei MERISE. Pot fi consecine importante legate de acest demers, pentru c, de cele mai multe ori, n ultim instan soluia pentru informatizarea unui domeniu dat este n realitate o problem de luare a unei decizii adecvate. Fundamentul metodei const n utilizarea mijloacelor de reprezentare cumulativ a structurii organismelor economice corelat cu domeniile de activitate proprii. Consider necesar corelaia fluxurilor de intrare-ieire cu sistemul de pilotaj al agenilor economici fapt materializat prin aciunea n timp real a sistemului informaional. n figura 2.5 prezint implicarea sistemului de management i a sistemului informaional.

22

Merise Method Standard, http://nextojects.sourceforge.net

50

Figura 2.6 Reprezentarea domeniilor unui organism economic

Apare evident activitatea de pilotaj cu sarcini de coordonare i decizie corelat cu obiectivele fixate. Se va avea n vedere faptul c vor fi necesare mutaii la nivelul cerinelor ca reacii la fluxurile de intrare-ieire n i din sistem. Elementul nodal - sistemul informaional - permite alctuirea unor magistrale de circulaie prioritar cu scopuri de actualizare a deciziei i de dezagregare pe centre de responsabilitate. Sistemul operant urmrete producerea rezultate pe baza intrrilor din mediul extern adaptndu-i activitatea n funcie de deciziile specifice primite. n acest context apare evident implicarea metodei MERISE n fixarea descrierii activitii sistemului operant i a implicrii sistemului informatic. Este evident descrierea activitii sistemului operant orientat pe baza regulilor de funcionare, stabilite prin sistemul de management, aplicate asupra intrrilor pentru a produce ieirile dorite. Ansamblul activitilor sistemului operant formeaz imaginea dinamic de nivel aciune. Implicarea sistemului informaional apare evident prin necesitatea de fuziune a datelor exprimat de pilotaj i execuia operaiunilor productive. n cadrul proiectrii unui sistem informatic, datele i prelucrrile sunt studiate i modelate mpreun. Corelnd elementele prezentate anterior constat invariaia funciilor sistemului operant care determin activiti bine delimitate.

51

Figura 2.7 Funcii i activiti ntr-un sistem operant

n figura 2.7 am disociat ansamblul activitilor sistemului operant fa de mulimea funciilor sale. Subansamblu reprezentativ n cadrul unui sistem operant este format din reuniunea de funcii care pune n eviden cel mai bine comportamentul ntregului sistem operant. Identificarea acestui ansamblu reprezentativ este unul dintre paii de baz pentru utilizarea metodei Merise. Responsabilitatea conducerii, coordonrii unui proiect de informatizare ntr-un organism, ne situeaz n faa realitii urmtoare: termenele cuprinse n studiul de proiect trebuie respectate; decelarea problemelor legate de organizare i informatizare necesit o anumit filozofie; existena mijloacelor care s permit localizarea i rezolvarea problemelor. MERISE este o metod cu ajutorul creia se poate defini, analiza, concepe i realiza un proiect care acoper activitatea unui domeniu bine definit. Ea are la baz o filosofie proprie a derulrii ntregului proiect, urmrind detalierea fiecrei etap de studiu i aplicarea unor instrumente specifice. Proiectarea i realizarea unui sistem informatic sunt operaiuni dificile pentru c oblig la luarea n considerare a tuturor factorilor sistemului ommain. Dac acceptm ideile c sunt mai multe modaliti de delimitare a domeniilor de studiu, c sunt nenumrate mijloace de documentare, c exist multe metode de concepie i punere n exploatare curent rezult c cele mai multe dintre ele se pot folosi n mod combinat sau complementar.
52

Reamintesc n acest context dou mari viziuni de concepie a sistemelor informatice: abordarea ascendent cunoscut mai simplu sub numele de bottom-up i abordarea descendent sau topdown. Abordarea ascendent 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 sistem informatic care poate atinge nivelul punctul extrem al piramidei. Este deci o consolidare a unui proiect care ne permite s avem n faza final, 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.23 Abordarea descendent const n a cobor, pe scara piramidei ierarhice, pn la baz i realiznd totodat i o analiz. Aceast viziune consider c un anumit domeniu este compus din pri corelate ntre ele i cu legturi cu exteriorul, caracteristic pentru toate sistemele informaionale. Este mai bine s se creeze i s se realizeze din start un sistem informatic care s in cont de obiectivele planificate, abordate ntr-o maniere global, dect s se ncerce a se integra a posteriori, subsisteme informatice independente. MERISE este o metod de concepie de sisteme informatice care se poate nscrie n aceast abordare descendent. n esen, filosofia MERISE se poate constitui sub forma unui ghid de abordare a unui sistem informatic pus n eviden sub forma sintetic utiliznd o semantic bazat pe cuvinte cheie ct mai sugestive. MERISE poate realiza sisteme informatice din mai multe perspective: MERISE perspectiv sistemic. n aceast privin intereseaz totalitatea problemelor nainte de a da o soluia global, astfel spus ntregul este altceva dect suma prilor.

23

Marciniak R. i col. Systmes dInformation dynamique et organisation, Editura Economica, Paris

53

 MERISE perspectiv paralel dateprelucrri. Fa de alte metode care trateaz n mod privilegiat datele sau prelucrrile, MERISE ine cont n aceeai msur de date i de prelucrri. Datele sunt elementele stabile ntr-o organizaie fiind luate n calcul ntr-o optic static iar prelucrrile sunt ntotdeauna dinamice i sunt reprezentate n MERISE prin instrumentele de sincronizare. MERISE perspectiv orientat pe nivele. Exist n cadrul metodei nivele de abstracie care corespund domeniilor de preocupare i care, la rndul lor, determin viziuni descriptive. Nivelele de abstracie sunt ierarhizate pornind de la situaia conceptual sau fizic pn la cea organizaional sau logic. Aceast viziune permite fixarea opiunii gestiunii la nivel conceptual, opiunii organizaionale la nivel logic i a celei tehnice la nivel fizic. MERISE viziune global asupra unui subansamblu reprezentativ. n majoritatea cazurilor vederea de ansamblu poate considera un domeniu ca fiind cel mai important. Grija de a nu lungi prea mult studiul domeniul respectiv i pretenia acestui studiu de fi exhaustiv, sunt deseori contradictorii. Subansamblu reprezentativ (SREP) este soluia oferit de metoda MERISE pentru a concilia aceste dou nuane contradictorii. Subansamblu reprezentativ presupune cu necesitate un studiu prealabil. MERISE din perspectiva extern. Abordare dateprelucrri se simte la moment dat de la debutul proiectului evideniind obligaia verificri coerenei dintre date i prelucrri. Aceast reconciliere dintre date i prelucrri se face prin intermediul modelelor externe24. Demersul metodei este n concordan cu definiia acestui cuvnt din zona de provenien a metodei (LarousseFrana) care semnific: O manier de a conduce un raionament, de a progresa spre un scop25. n cadrul metodei MERISE, exist o descompunere n etape precum: studiul prealabil, studiu detaliat, realizarea i punerea n lucru. O etap poate fi la rndul ei descompus n subetape fiecare terminndu-se cu luarea unei decizii aprnd vizibil o selecie a posibilitilor.
24 25

Reix R. Systemes dinformation et management des organisations, Editura Vuilbert, Paris Merise Method and knowledge, www.cmi.univ-mrs.fr

54

Demersul metodei se poate reprezenta sintetic astfel: Ce trebuie fcut? Cum se face? Etape Subetape (Legturi, Reguli) (Participani) Cu cine se face? -

n figura 2.8 am reprezentat cerinele la care rspunde metoda MERISE constatnd interdependenele externe, interne i fundamentale.

Figura 2.8 MERISE Ce-cum-cu cine se realizeaz?

Realizarea studiului prealabil i a celui de detaliu nu presupun neaprat crearea de elemente noi, singurele eforturi fiind acelea de a adapta metodele de realizare deja folosite la etapele propuse. Sub form tabelar prezint etapele acestei metodei sintetiznd rezultatele fiecrui stadiu.
STUDIU Studiu prealabil Studiu FUNCIUNI Studiu situaiei actuale REZULTAT DECIZIA dup studiu o

Dosar de opiuni coninnd Decizia Degajarea unui mijloacele de punere n pentru soluie lucru subansamblu reprezentativ Studierea detaliat a Specificaii 55 funcionale Acordul

STUDIU detaliat Realizarea

FUNCIUNI

REZULTAT generale

diferitelor domenii pentru externe soluia reinut detaliate Studiul tehnic Realizarea programelor

DECIZIA dup studiu i utilizatorilor

Sistem de criterii de pia Recepia privind jocul de prob al provizorie utilizatorilor Sistem implantat n Recepia ambientul real i definitiv funcionnd n regim normal.

Punerea n Studiul de ansamblu al lucru problemelor legate de utilizarea noilor funciuni automate

n momentul descompunerii subansamblul reprezentativ (SREP) pe subproiecte apare evident soluia chiar nainte de a se studia adecvarea specificaiilor funcionale pentru nevoile utilizatorilor cu compatibilitatea ntregului alctuit din specificaii funcionale, tehnice i restricii financiare definite nainte de studiul prealabil. n figura 2.9 reprezint iniierea i derularea pailor care privesc studiul prealabil.

Figura 2.9 Studiu prealabil n cadrul metodei Merise

Metoda MERISE n contextul unei uniti bancare pentru un subansamblu reprezentativ pune n eviden unul sau mai multe subproiecte care vor intra sub incidena studiului prealabil. n cadrul studiului prealabil se pot distinge mai multe subetape26:

iniializare;

26

Euromethod, www.unl.ac.uk/simt/im251/eumeths.html

56

studiul existent; concepia; organizarea punerii n lucru; bilanul cantitativ i calitativ; concluziile studiului prealabil.

Metoda se utilizeaz pentru toate proiectele de organizare a unui domeniu de activitate chiar dac nu conin elemente de informatizare, situaie n care nu apare contextul informatic. Se poate constitui ntr-un instrument al metodei orice mijloc care permite s se execute un lucru: o munc, o operaie (Larousse). n metoda MERISE se regsesc instrumente generale (interviul, ancheta) ct i proprii (formalizri individuale i ale prelucrrilor). Instrumentele specifice MERISE sunt utilizate pentru reprezentarea sistemelor informaionale i a diferitelor nivele de modele de date i prelucrri dup cum se deduce din sinteza supus ateniei n continuare: Alegere
Ce se GESTIUNE dorete s se fac n fond

Obiect descris
Date

Nivel de abstracie
CONCEPTUAL

Exemplu de modele
MODELUL CONCEPTUAL AL DATELOR

Cine face Cu ce i Cnd

Relaii Reguli de gestiune nlnuiri de prelucrri ORGANIZAIONAL Oameni Maini Reele diferite Repartiie geografic Entiti Programe Proceduri

(invariant static)
MODELUL CONCEPTUAL AL PRELUCRRILOR

(invariant dinamic)
LOGIC SAU ORGANIZAIONAL MODELUL LOGIC DE DATE MODELUL LOGIC DE PRELUCRARE

Cum face

se TEHNIC

FIZIC SAU OPERAIONAL

MODELUL FIZIC AL DATELOR MODELUL FIZIC AL PRELUCRRILOR

Pot concluziona c la ntrebarea cum se face? din punct de vedere tehnic prin modelul fizic al datelor, modelul fizic al prelucrrilor pot rspunde prin entiti programe proceduri. La ntrebarea cine, cu ce i cnd? din punct de vedere
57

organizaional rspunde modelul logic al datelor i cel al prelucrrilor. La interogarea ce se dorete a se realiza? datele, relaiile, regulile de gestiune, nlnuirile de prelucrri apar ca rspuns dedus din modelul conceptual al datelor i al prelucrrilor. n continuare supun ateniei sintetiza nivelelor de abstractizare corelate cu ansamblul date-prelucrri.
DATE CONCEPTUAL Modelul conceptual al datelor MCD - Concepte fundamentale - Relaii semantice LOGIC Modelul logic de date MLD Integrarea organizare entitate relaie instan (realizare) FIZIC Modelul fizic al datelor MFD Descrierea bazelor de date Noiuni de nregistrare Modelul fizic al prelucrrilor MFP Descrierea programelor Descrierea procedurilor restriciilor MCP - Descrierea macroscopic (noiunea de proces) Modelul logic al prelucrrilor MLP de - Integrarea alegerii opiunii - Repartiia om - main - Timp real timp diferit Desfacerea proceselor Faze sarcini proceduri PRELUCRRI Modelul conceptual al prelucrrilor

- Traducerea n SGBD

Corelnd figura 2.8 referitoare la Merise Ce-cum-cu cine se realizeaz?, nivelurile de abstracie, modelele rezultate, deduc i prezint urmtoarele expresii:
Viziunea exterioar: model extern=o vedere a unui utilizator = Ansamblul informaiilor operaionale pentru o prelucrare FORMALISM = Model individual

Conceptele adecvate pentru fiecare nivel al modelrii datelor i prelucrrilor sunt caracterizate printr-un grad mare de generalitate, dar n acelai timp i de relevan surprinznd aspecte semnificative din realitatea supus modelrii.

58

Modelul conceptual al datelor este un ansamblu de concepte i reguli de combinare care permit reprezentarea realitii circumscrise domeniului supus informatizrii. Pentru definirea modelului conceptual al datelor se apeleaz la modele intermediare care sunt folosite ca suport al unei metodologii de proiectare. Modelul conceptual utilizeaz o abstractizare prin relaie, recunoscut de ISO fiind o apropiere de modelul entitate-relaie. Mai multe concepte de baz caracterizeaz acest model: - proprietatea este o modelare a informaiei elementare, de exemplu funcia exercitat de un salariat: vnztor, contabil, informatician etc. - identificatorul permite modelarea unui ansamblu de obiecte concrete sau abstracte, percepute ca fiind pertinente pentru sistemul informatic studiat, de exemplu identificatorul salariatului sau identificatorul produsului. Elementele din acest ansamblu sunt ocurente, de exemplu n cazul salariatului ocurena este exprimat astfel: Georgescu, 28 ani, manager. Regulile de pertinen, de identificare, de evideniere, de verificare i omogenitate conduc la modelizarea termenilor identificrii. - relaia ntre mai muli indivizi este un ansamblu de produse carteziene de ocuren a acestora. De exemplu produsul cartezian vnztor * client reprezentat prin toate cuplurile vnztor/client, va fi modelat prin ansamblul de legturi care exprim aceeai natur ntre mai muli indivizi. Bineneles, aceste relaii trebuie s fie pertinente n raport de sistemul informatic studiat. - cardinalitatea reprezint cuplul entitaterelaie. n spatele cardinalitilor se gsesc reguli de gestiune reale. Inspirat din reelele Petri, modelul conceptual al prelucrrilor (MCP) are menirea ca n funcie de domeniul investigat s rspund la ntrebarea: Ce prelucrri se realizeaz? Fluxurile, receptorii (stimulii) i emitorii (reacii) prin domeniu sunt modelri ale evenimentelor i rezultatelor. Evenimentele i rezultatele pot fi externe sau interne. Cele externe provin sau sunt destinate unui actor extern, iar cele interne rmn n

59

domeniu pentru a asigura continuitatea procesului, urmrind satisfacerea sistemului de pilotaj. Operaia descrie comportamentul domeniului la declanarea produs prin mai multe evenimente. Ea este o secven continu de aciuni elementare productoare de evenimente care se execut nentrerupt din momentul declanrii acesteia de ctre unul sau mai multe evenimente. Operaia constituie un bloc de prelucrare cuprinznd aciuni elementare generatoare de evenimente interne, nlturnd posibilitatea de generare a evenimentelor intermediare ntre aciunile ce aparin operaiei. Operaia emite, n retur rezultate n funcie de condiiile traduse prin expresii logice. Prelucrrile reprezint partea dinamic a sistemului informaional. Ele descriu aciunile exercitate asupra datelor cu scopul obinerii informaiilor dorite, reprezentnd materializarea sub form de aciuni a regulilor de gestiune specifice activitii ntreprinderii. MCP urmrete reprezentarea nlnuirii operaiilor cu definirea condiiilor necesare pentru declanare dar i consecinele derulrii operaiilor respective. n reprezentarea acestei nlnuiri de operaii i evenimente declanatoare n cadrul modelului, se impune respectarea unor cerine determinate de regulile de gestiune. Asocierea MCP eveniment indic faptul c ceva anume s-a ntmplat i n consecin sistemul trebuie s reacioneze. - sincronizarea reprezint o condiie prealabil a unui flux de operaii n care mai multe evenimente particip la declanare. Sincronizarea se traduce prin expresii logice. Regulile de sintax i de funcionare permit verificarea coerenei MCP. Modelul conceptual de comunicaie (MCC) are drept scop reprezentarea fluxurilor de informaii sau mesaje ntre diferitele subsisteme omogene ale ntreprinderii, numite domenii. Domeniile privesc marile funciuni sau procese majore din ntreprindere. Un mesaj este trecerea de informaii ntre domenii sau ntre un partener (factorul extern) al ntreprinderii i un domeniu. Mesajul este emis de o parte (partener sau domeniu, emitor) i recepionat de alt element structural (receptorul).

60

Construcia modelelor organizaionale 27 reprezint o etap delicat i deseori complex datorit varietii i interaciunii parametrilor de luat n consideraie: organizarea intrrilor, varietatea soluiilor organizaionale posibile, criterii de evaluare (economice, sociale, ergonomice, tehnice). Totodat poate fi considerat ca o etap accesibil, deoarece nu apar dificulti induse de abstractizare. n figura 2.10 v supun ateniei reprezentarea cumulat a MOP-MOD-MOC care ncearc s evidenieze circuitul sarcini-prelucrri, date i mesaje.

Figura 2.10 Traseul sarcini-prelucrri, date, mesaje

Problematica modelului organizaional este sintetizat n tabelul urmtor:

Problematica MOP - Repartizarea prelucrrilor pe centre, uniti i posturi de lucru - Caracterizarea sarcinilor: posturile raportate, gradul de automatizare, termenul de rspuns, modul de funcionare, regulile i procedurile aplicabile, frecvena, durata, capacitatea Problematica MOC - Repartizarea datelor: - Schimburile de pe centre, uniti i mesaje ntre centre posturi de lucru - Volumetrie - Istoric - Securitate Problematica MOD

Modelarea privete sistemul de informaii organizaional care se finalizeaz prin confruntarea modelelor; aplicnd urmtoarele tehnici: abordarea participativ, abordarea printr-o gril de coeren MCD MOP MOD, machetare i validarea MCD modele externe. Modelele externe28 privesc datele drept mesajele legate la evenimenterezultate. Continuarea studiului presupune modelarea sistemului i se
27 28

Nextobjects is based on the Merise Method, www.nextobjects.sourceforge.net Information Systems Group UG2, www.cee.hw.ac.uk/ism/ug2/ass3

61

surprind n acest moment delimitrile de modele care apar utiliznd percepia de gestionare (modele organizaionale) i viziunea specialistului informatic (modelele logice i fizice). n cele ce urmeaz supun ateniei sinteza reunirii modelelor logice i fizice ale datelor, prelucrrilor, comunicaiei.
Problematica MLP i al MFP Problematica MLD i al MFD - Repartizarea prelucrrilor informatizate: centre, uniti logice de prelucrare. - Modularizare Problematica MLC i al MFC

- Transformare MOD - Mesaje ntre centre prin magistrale dup tipul SGBD informatice - Dimensiunea MLD - Optimizarea

Concluzionnd ideile prezentate pe parcursul acestui subcapitol, afirm c utilizarea metodei MERISE n contextul cadrului metodologic al conducerii proiectelor informatice este oportun deoarece: determin limitele nivelelor de preocupare (conceptual, logic, fizic); permite exprimarea unor concepte complementare legate de conducerea studiilor detaliate; propune un plan de lucru detaliat pentru derularea fiecrei etape pentru a facilita conducerea proiectelor n concepia sistemelor informatice; furnizeaz documentele tip ISO pentru constituirea documentaiei aferente fiecrei etape. Se poate afirma c este o metod deschis, susceptibil s se integreze ntr-un cadru metodologic mai larg.

2.2.2. Metoda OMT de proiectare a sistemelor informatice

OMT Object Modeling Tehnique este bazat pe modele ca abstracii ale problemelor din lumea real, care urmresc focalizarea aspectelor importante ale
62

problemei i omisiunea celor irelevante. Aceast metod a fost creat de James Rumbaugh i este cea mai cunoscut i utilizat metod de proiectare orientat obiect (POO). Un sistem informatic este privit ca un ansamblu de obiecte care coopereaz ntre ele i trateaz obiectele ca instane ale unei clase n interiorul unei ierarhii. Noiunea de obiect 29 este dependent de implementarea metodei n limbajele de nivel nalt cum ar fi: ADA, MODULA, SMALLTALK, C++, CLOS (Common Lisp Object System). Aceast metod are n vedere trei aspecte importante: abstractizarea realitii, ceea ce nseamn c pentru aceeai problem se pot crea mai multe modele care s focalizeze diferite aspecte; scopul modelului este s se focalizeze ceva cunoscut; comunicarea ntre membrii echipei de analiz-proiectare i ntre utilizatori.

Metodele orientate obiect propun modelarea concomitent a datelor i a funciilor obinnd ierarhii de clase de obiecte care nglobeaz att datele ct i comportamentul, spre deosebire de modelarea datelor separat de a funciilor, element structural al metodelor tradiionale. Comparativ cu metodele tradiionale, abordarea orientat-obiect mut centrul de greutate al soluionrii problemei n faza de analiz, fapt compensat printr-un minim de efort necesar a fi depus n faza de implementare. O bun nelegere a cerinelor problemei reale va conduce la construirea unui model fiabil, adaptabil, care suport uor modificrile ulterioare. Metodele obiect integreaz modelarea de structur cu cea comportament30. Obiectul reprezint o entitate (real sau abstract) a lumii supuse modelrii, caracterizat prin identitate, stare i comportament. n fapt, obiectul reprezint un element identificabil, concret sau abstract, caracterizat prin structur, atributele i metode proprii.

29 30

Rational whitepaper, www.rational.com Ayache R. N. - The management control function, Boston: the Harvard Business School Press

63

Corespunztor metodologiei31 se parcurg urmtorii pai: definirea problemei; elaborarea unei modaliti informale de identificare a datelor i a funciilor relevante corespunztoare problemei; formalizarea strategiei prin identificarea obiectelor i atributelor, operaiilor asupra obiectelor, stabilirea instanelor i implementarea operaiilor. Metoda OMT, folosit pentru proiectarea software-lui conteaz pe mijloacele de reprezentare: diagrama de flux de date pentru surprinderea comportamentului dinamic i diagrama modular (arhitectura produsului) pentru surprinderea comportamentului static. Aceast metod de proiectare susine strategia prototipizri de structurare a procesului de realizare a produselor informatice. Supun ateniei cteva dintre avantajele acestei abordri: software-ul este asamblat (construit) din componente care au o calitate probat n implementrile anterioare; obiectele individuale pot fi modificate fr a le afecta pe celelalte, rezultnd c software-ul construit modular poate fi modificat i dezvoltat cu eforturi minime; reutilizarea componentelor soft existente, tehnologie care asigur realizarea de aplicaii ntr-un timp scurt i la costuri reduse. OMT propune trei tipuri de modele, obiect, dinamic i funcional pentru scopuri i descrieri diferite de obiecte, interaciuni, transformri. Cele trei tipuri de modele sunt de fapt proiecii ale unei singure informaii, fiecare prezentnd un anumit specific. Existena i necesitatea acestor modele solicit i realizeaz o strns conexiune ntre ele. Fiecare model n OMT poate fi reprezentat prin diagrame distincte32:

Rumbaugh's Method, www.iconixsw.com/Rumbaugh.html Castellani X. - Mthodologie gnrale danalyse et de conception des systmes dobjects. 1. Lingnierie des besoins, Masson
32

31

64

pentru modelul de obiecte CAD (Class Association Diagram sau DAC Diagrama de Asociere a Claselor);

pentru modelul dinamic ETD (Event Trace Diagram sau DTE Diagrama de Trasare a Evenimentelor), precum i STD (State Transition Diagram) sau DTS (Diagrama de Tranziie a Strilor);

pentru modelul funcional se apeleaz la DFD (Diagrama de Flux de Date Data Flow Diagram); DCC (Diagrama de Comunicare a Claselor, CCD Class Comunication Diagram); DGM (Diagrama de Generalizare a Mesajelor - MGD Message Generalization Diagram).

n reprezentarea ciclului de via al unui proiect se utilizeaz mai multe modele, dar flexibilitatea metodelor orientate-obiect permite lucrul ntr-un ciclu de via spiral. Ciclul de via spiral sau modelul spiral, spre deosebire de modelul n cascad, specific metodelor structurate, presupune faptul c doar o parte a modelului trebuie s fie finalizat nainte de a trece la faza urmtoare. Aceasta nseamn c versiunii pariale ale sistemului pot fi livrate n timp scurt, evaluate i validate de ctre utilizator, proiectantul realiznd extrem de rapid analiza pentru completarea modelelor. Feed-back-ul permite gsirea de soluii convenabile, iar flexibilitatea modelelor orientateobiect permite armonizarea cerinelor utilizatorului cu soluiile propuse de echipa de realizatori. Modelul n cascad, chiar n varianta care cuprinde iterarea fazelor, permite detectarea i corectarea erorilor nainte de trecerea la faza urmtoare i impune ca n fiecare faz s se produc un document i produse valide. Corectarea erorilor n fazele urmtoare celei n care s-au produs este foarte costisitoare (timp, efort), aducnd importante prejudicii prin faptul c utilizatorul trebuie s atepte pn la sfritul implementrii pentru a vedea dac sistemul corespunde necesitilor exprimate.

65

2.2.2.1. Etapele ciclului de realizare a unui proiect n abordarea orientatobiect

Etapele ciclului de realizare n abordarea orientat obiect sunt n mare parte comune cu viziunea Merise, dar apar i elemente specifice. Analiza are drept obiectiv modelarea problemei din lumea real sau definirea Domeniului Aplicaiei (Application Domain). Proiectantul creeaz modele de obiecte i funcii fr a lua n considerare aspectele de implementare. n figura 2.11 am reprezentat o secven a activiti analizei i modelrii evenimentului studiat.

Figura 2. 11 Circuitul analiz-modelare evenimente

Modelul de analiz trebuie neles i validat de utilizator. Aceast etap are ca rezultat formularea problemei, modelul obiectual, modelul dinamic i cel funcional. Analiza este util clarificrii cerinelor, realizrii conexiunii beneficiar-productor bazat pe nelegere, reprezentnd n acelai timp cadrul pentru proiectarea ulterioar i implementare. Finalizarea etapei analiz-modelare (figura 2.12) se materializeaz prin definirea unui model precis, concis, inteligent i corect al viitorului sistem.

66

Figura 2. 12 Obinerea modelului de analiz

O reprezentare sintetic a activitilor i rezultatelor este supus ateniei n tabelul urmtor:

Faze i activiti Mod de reprezentare Descriere Declaraia problemei (de ctre client sau elaborator) Scenarii de evenimente pentru evenimentele complexe ale aplicaiei Diagrama de Comunicare ntre Clase cu mesaje i interaciunile dintre clase Diagrama de Generalizare a Mesajelor specific interaciunii ntre clase A.1. Analiza i modelarea evenimentelor Scrierea declaraiei Text liber problemei (formularea problemei) Analiza evenimentelor Diagrama de Trasare a problemei Evenimentelor (DTE) Modelarea Diagrama de Comunicare evenimentelor ntre Clase (DCC) Diagrama de Generalizare a Mesajelor (DGM)

A.2. Construirea modelului de analiz Definirea modelului Diagrama de Asociere a Model de obiecte cu clasele obiectual Claselor (DAC) aplicaiei atributele, operaiile i asocierile lor. Definirea modelului Diagrama de Tranziie a Modelul dinamic (DTS) pentru clase dinamic Strilor (DTS) importante i modelul de obiecte care ncorporeaz rezultate din DTS Definirea modelului Diagrama de Flux de Modelul funcional cu funcional Date (DFD) funcionalitatea operaiilor complexe i completarea lor n DAC Reiterarea i Verificri Se completeaz modelul de obiecte verificarea din celelalte iteraii i se verific consistena

67

Proiectarea de sistem mparte modelul de analiz n pri mai mici, uor de neles i construiete arhitectura sistemului prin identificarea subsistemelor i transpunerea lor pe hardware-ul disponibil. Proiectarea de sistem pornete de la domeniul aplicaiei i ia n considerare conceptele de implementare adic optimizarea, rafinarea i extinderea celor trei modele pn la nivelul de detaliu care s permit implementarea. Se poate spune c, analiza descrie problema iar proiectarea de sistem descrie soluia. Rezultatul acestei etape este realizarea arhitecturii de baz a sistemului i adoptarea deciziilor privind strategia la nivel global. Scopul acestei etape este transpunerea declaraiei problemei aa cum a fost definit n etapa de analiz ntr-o arhitectur adecvat, bazat pe divizarea n subsisteme precum i decizii de implementare la nivel global. Rezultatul este un concept de implementare care rafineaz, optimizeaz i extinde cele trei modele preluate din etapa de analiz, pn la etapa de proiectare obiectual care s permit implementarea propriu-zis. Proiectarea de sistem presupune dou mari faze i anume: construirea arhitecturii sistemului; modelarea detaliilor subsistemelor. n faza de construire a arhitecturii sistemului se dezvolt aa numitele clase de baz, pe seama crora se studiaz funcionalitatea sistemului i se decide privitor la configuraia sistemului hardware-software; sistemul de gestiune al bazelor de date; interfaa grafic de conexiune cu utilizatorul. Soluia de sistem proiectat va include pe lng clasele de baz i clasele de interfee grafice, clasele de acces la bazele de date. Suma acestora reprezint soluia general de organizare. n a doua faz se modeleaz n detaliu fiecare sistem individual, accentul pus pe diferitele modele fiind diferit de la un tip de sistem la altul. Se creeaz aa numitele clase container organizate pe sistem. Sintetizarea fazelor i activitilor etapei de proiectare de sistem este relevat de tabelul de mai jos:

68

Modaliti de reprezentare 1. Construirea arhitecturii sistemului 1.1. Organizarea sistemului n subsisteme a) Importul sistemului DCC claselor de baz DAC b) Alegerea unei arhitecturi Text DCC la c) Crearea unui Model de Comunicare ntre Clase de nivel de proiect Nivel de Proiect d) Crearea sistemelor pentru fiecare subiect 1.2. Definirea interfeelor Text DGM DCC

Faze i activiti

Descriere

Se utilizeaz din etapa de analiz DCC i DAC Se stabilete arhitectura sistemului n DAC din etapa de analiz, actorii vor fi nlocuii cu subieci, clasele de baz vor fi grupate, se adaug i se conecteaz subiectul Clase de Interfa Fiecare subiect din diagram va fi descompus ntr-un sistem cu acelai nume. Completarea modelului de comunicare a claselor la nivel de proiect cu mesajele compuse nou definite Identificarea obiectelor care sunt active n acelai timp i a celor care au un comportament exclusiv Se aloc subsistemele la procesoare, astfel nct s asigure satisfacerea cerinelor de performan i minimizarea comunicrii Se aleg structurile de date, fiierele sau bazele de date corespunztoare Identific resursele globale i determin mecanismele pentru controlarea accesului

1.3. Identificarea obiectelor Text active concurente i exclusive 1.4. Alocarea Text subsistemelor pe procesoare i task-uri Text 1.5. Alegerea strategiei de baz pentru implementarea datelor memorate 1.6 Identificarea resurselor Text globale i determinarea mecanismelor pentru asigurarea accesului la date. 1.7. Alegerea variantei de Text implementare a controlului 1.8. Stabilirea condiiilor Text limit 1.9. Stabilire prioriti 2. Modelarea detaliilor de subsistem 2.1 Definirea modelului de DCC comunicare a claselor 2.2. Detalierea modelului obiect DAC

Definirea modelului de comunicare ntre clase la nivel de sistem din modelul de comunicare la nivel de proiect Detalierea modelului obiectual din faza de analiz

Proiectarea obiectual are drept scop alegerea modului de implementare pentru fiecare clas, proiectndu-se algoritmi i implementndu-se asocierile. Se realizeaz
69

gruparea claselor n superclase pentru uurarea implementrii i pentru mbuntirea performanelor. n urma acestei etape se obin: modelul obiectual detaliat, modelul dinamic detaliat i modelul funcional detaliat. Scopul etapei este de a aduga la modelul obiectual rezultat al etapelor de analiz i proiectare de sistem, detaliile de implementare necesare fie pentru generarea automat de cod, fie pentru dezvoltarea ulterior fr generare automat. Cnd se trece la etapa de implementare prin generare automat de cod, atunci modelul obiect este singurul utilizat, una din activitile etapei de proiectare obiectual Plecnd de la aceste obiective n etapa de proiectare obiectual operaiile identificate n etapa de analiz sunt transpuse n algoritmi iar clasele, atributele i asocierile sunt implementate n structuri de date specifice. Modelele utilizate sunt identice cu cele din etapa de analiz, diferena constnd n faptul c acum clasele sunt descrise din punct de vedere al implementrii33. Astfel: modelul obiectelor determinat n etapa de analiz va fi acum rafinat prin

introducerea de noi clase (care pstreaz rezultatele intermediare ale calculului), operaii (descoperite abia acum) i atribute. modelul funcional va descrie operaiile pe care proiectantul trebuie s le

implementeze. n timpul proiectrii acesta va alege algoritmii de implementare a unei operaii i va descompune operaiile mai complexe n operaii mai simple. modelul dinamic descrie felul n care sistemul rspunde stimulilor externi.

Structura de control a programului deriv din acest model. Fluxul de control din cadrul unui program trebuie realizat fie explicit (printr-un planificator intern, care recunoate evenimentele i le transform n apeluri de proceduri), fie implicit (alegnd algoritmii care realizeaz operaiile n ordinea specificat de modelul dinamic). Rezultatul final al acestei etape l constituie modelul obiectual, modelul dinamic i modelul funcional rafinate i detaliate. Deciziile de proiectare luate trebuie susinute de o documentaie adecvat care alctuiete o extensie a cerinelor de documentaie realizate n etapa de analiz.
33

Object-Oriented Development Interactive Systems, http://citeseer.nj.nec.com/aalto94objectoriented.htm

70

Se poate concluziona c deciziile de proiectare trebuie documentate pornind de la modelul de analiz, prin adugarea de detalii modelelor obiectual, dinamic i funcional. n acest scop se vor folosi construcii specifice de implementare: pointeri (pentru modelul obiectual) pseudocod structurat (pentru modelul dinamic) i expresii funcionale (pentru modelul funcional). 2.2.2.2. Modelul obiect n metodologia OMT Cele trei tipuri de modele recomandate de OMT sunt utilizate ncepnd din etapa de analiz cnd se realizeaz o prima versiune a acestora, apoi n etapa de proiectare (de sistem obiectual) cnd sunt detaliate i completate i pn la implementarea de cod. Simbolul utilizat n metodologia OMT pentru reprezentarea unei clase de obiecte este:
Nume_Clas Atribute Operaii

Numele clasei trebuie s fie sugestiv n contextul aplicaiei i s identifice clasa n mod unic. De exemplu, pentru o aplicaie de eviden a facturilor pentru fiecare document utilizat se definete un obiect care conine caracteristicile facturii relevante pentru aplicaia informatic. n OMT atributele sunt reprezentate sub numele clasei, fiind menionat numele atributului i opional tipul su i o valoare implicit.
Nume_Clas NumeAtribut[:tip=valoare_implicit]

Obiectele se difereniaz ntre ele prin valorile atributelor la un moment dat, care constituie starea obiectului n acel moment. O categorie special de atribute sunt cele ale clasei. Un atribut al clasei, simbolizat prin $ are o valoare comun clasei de obiecte i nu unei instane specifice.
NumeClasa /Nume atribut $Nume_atribut

....

71

Atributul unei clase va descrie o proprietate comun a tuturor obiectelor din clas i nu proprietatea unei clase instane. El apare ca atribut al obiectelor din clas avnd pentru fiecare aceeai valoare. O categorie aparte de atribute sunt cele derivate a cror valoare se calculeaz, reprezentate prin caracterul / plasat n faa numelui. Reprezentarea operaiilor unei clase se face prin specificarea numelui operaiei, urmat opional de parametrii i de tipul rezultatului returnat. Toate aceste elemente sunt trecute n partea inferioar a simbolului clasei, sub partea destinat atributelor.
NumeClas ... NumeOperaie(lista_argumente):tip_rezultat $Numeoperaie

O operaie este o funcie sau o transformare aplicat obiectelor unei clase. O modificare a unui obiect al unei clase acioneaz asupra strii obiectului prin transformarea/consultarea acesteia, asupra altui obiect aparintor clasei sau asupra obiectelor incluse altei clase. Implementarea operaiilor unei clase se numete metod. O aceeai operaie poate fi implementat n mod variat n clase diferite. Aceast proprietate se numete polimorfism. De exemplu clasa Comand_marf are operaia Emite, care va fi implementat n mod diferit fa aceeai operaie care aparine clasei Factur. Fiecare operaie care se aplic unui anumit obiect devine parametru implicit. O operaie este recunoscut dup semntura sa (numele, lista de argumente i tipul returnat). Dac operaia poate fi accesat din afara clasei semntura acesteia este public spre deosebire de implementare care nu are acest caracter. Operaia clasei utilizeaz simbolul $ n faa numelui i are forma general:
NumeClas NumeAtribut_1:tip_1=valoare_implicit_1 NumeAtribut_2:tip_2=valoare_implicit_2 ... NumeAtribut_m:tip_m=valoare_implicit_m NumeOperaie_1(lista_argumente_1):tip_rezultat_1 NumeOperaie_2(lista_argumente_2):tip_rezultat_2 ... NumeOperaie_n(lista_argumente_n):tip_rezultat_n

72

Conform metodologiei OMT pentru reprezentarea grafic a unei clase se utilizeaz o form dreptunghiular avnd una sau trei regiuni. n cazul n care se apeleaz la reprezentarea cu trei regiuni se menioneaz numele clasei, atributele i operaiile clasei. Reprezentarea cu o singur regiune conine doar numele clasei. Deoarece obiectele sunt abstractizate n clase atunci legturile vor consta n asocieri. Este indicat s se modeleze asocierile dintre clase i nu legturile dintre obiectele acestora, motivat prin faptul c obiectele reprezint instane ale asocierii claselor. Asocierea claselor se realizeaz printr-un verb nscris deasupra liniei de conectare. Spre exemplificare clasele Factur i Furnizor vor fi conectate prin intermediul asocierii Emis_de care indic i sensul acesteia:
Factur Emis_de Furnizor

Multiplicitatea - caracteristic a asocierii- reprezint numrul de instane ale unei clase care poate avea legturi cu o instana a altei clase asociat. Multiplicitatea poate fi: unu la unu, unu la zero sau mai muli, unu la zero sau unu, unu la unu sau mai muli. Corespunztor unei asocieri apare o valoare ataat fiecrei legturii. Exist situaii n care este necesar ca o asociere s fie modelat drept clas, identificat prin reprezentarea:

Figura 2. 13 Forma general de reprezentare a unei asocieri modelate ca o clas

Atunci cnd legturile devin subieci ai unor operaii apare asocierea modelat ca o clas. n cazul n care se realizeaz asocierea ntre Client-Banc apare evident asocierea mprumut modelat ca o clas avnd n structur atributele Nume_banc, Nume_client preluate. n figura 2.14 care exemplific asocierea modelat ca o clas, apare Suma_mprumutat care nu aparine clasei Client i nici Banc.
73

Figura 2. 14 Asociere mprumut modelat ca o clas

Operaiile efectuate de mprumut sunt de restituire sau amnare. Presupunnd intervenia clasei Investiie, apare evident asocierea ternar mprumut. n figura 2.15 se sintetizeaz acordarea mprumutului de ctre banc unui client pentru anumite investiii.

Figura 2. 15 Asociere Client-Banc-Investiie

Se observ c asocierea mprumut nu poate fi divizat fr pierderi de informaii ntre clase. Nume de rol reprezint un concept prin care se identific capetele unei asocieri. n cazul n care o clas are mai mult de o asociere, cu siguran c va avea roluri diferite fa de fiecare dintre acestea. Spre exemplificare, utilajul achiziionat de o societate reprezint pentru ea un mijloc de producie, dar din punct de vedere al bncii care acord creditul constituie o garanie. Pot exista i asocieri calificate reprezentate sub forma unumuli sau mulimuli la care calificatorul reduce multiplicitatea efectiv. Un calificator distinge seturile de

74

obiecte de la captul muli al unei asocieri. Asocierea calificativ este exprimat sub forma:
Nume_clas1 Calificator Nume_clas2

Generalizarea 34 sub OMT presupune identificarea atributelor i/sau a operaiilor comune claselor i crearea superclase. Opus generalizrii apare specializarea claselor care are ca punct de plecare superclasa adugnd noi atribute relevante numai pentru anumite obiecte din clas, crend astfel subclasele. Avantajele utilizrii generalizrii sunt: reutilizarea claselor create n cadrul altor proiecte; standardizarea reprezentat prin specificarea unic a aspectelor comune i obinerea unei caliti superioare a proiectului deoarece reutilizarea aduce avantajele oferite de testarea anterioar. Motenirea n OMT este un mecanism care d posibilitatea partajrii atributelor i operaiilor utiliznd relaia de generalizare. Se utilizeaz termenul de superclas , clas, subclas cu elementele specifice operaii i atribute. Atributele i operaiile superclasei nu mai apar n cadrul subclaselor ataate, dar aparin acestora prin motenire. n clase se descriu numai atributele i/sau operaiile specifice fiecreia dintre ele. Subclasele i clasele pot fi exprimate prin relaia prini/copii sau strmoi/descendeni. Clasele constituite special pentru a fi motenite se numesc abstracte fiind lipsite de instane i coninnd cel puin o operaie abstract care va fi transmis claselor descendente. n cazul n care o clas este construit pentru a avea instane apare noiunea clas concret. Motenirea poate fi ierarhizat pe mai multe nivele. Influena generalizrii apare evident prin preluarea atributelor i operaiilor elementare intersectate obinndu-se atribute i operaii comune. n figura 2.16 am realizat reprezentarea general a motenirii, observndu-se c intervine i mecanismul de specializare descendent, cu o aciune opus celui de generalizare.

34

Docs submitted to World Scientific, www.geocities.com/siliconvalley/9219/resume.htm

75

Figura 2. 16 Reprezentarea general a motenirii

Reprezentare modelului de obiecte se exprim prin Diagrama de Asociere a Claselor (DAC) ale crei noduri sunt clasele de obiecte iar legturile ntre clasele de obiecte sunt reprezentate prin asocieri. Agregarea este un tip special de asociere ntre clasa ntreg i una sau mai multe clase parte. Pot prezenta spre exemplificare, (figura 2.17) diagrama de asociere ntre clase pentru problema de urmrire a clienilor, comenzilor i stocurilor.

Figura 2. 17 Monitorizarea simultan a clienilor, comenzilor i a stocurilor

Este evident agregarea client_cash client_virament n superclasa client care execut operaia Achit.

76

2.2.2.3. Modelul dinamic n accepiunea metodei OMT

Evidenierea temporal a succesiunii operailor este redat n modelul dinamic. Conceptele utilizate sunt: eveniment, scenariu, stare, tranziie, condiie, operaie. Evenimentul reprezint o situaie de moment care precede sau succede logic unui alt eveniment. Evenimentele similare pot fi grupate n clase de evenimente caracterizate printr-un nume care indic structur i un comportament comun. Dou evenimente care nu au efect unul asupra altuia sunt concurente. Scenariul este secven care include evenimentele care apar n timpul execuiei sistemului. Scenariul identific obiectele emitoare, receptoare specifice fiecrui eveniment. Reprezentarea cumulativ a secvenei de evenimente i obiecte se realizeaz prin Diagrama de Trasare a Evenimentelor (DTE). Rolul diagramei este de a indica actorii, evenimentele, obiectele i reunirea acestora n scenarii. Interpretarea DTE se produce de la baz spre partea superioar i de la stnga la dreapta. Pentru un eveniment al aplicaiei se poate modela un singur scenariu, numit principal, iar dac evenimentul aplicaiei este complex, pe lng acesta se mai pot modela mai multe scenarii alternative. Utiliznd spre exemplificare (figura 2.18) actorul Client i obiectele Comand pn la Element_in_stoc prin evenimentele creeaz comanda, citete client, pn la cost total al comenzii se reprezint DTE aferent aplicaiei Clieni.

Figura 2. 18 DTE a aplicaiei Clieni

77

Se observ c evenimentele sunt trimise de la un obiect emitor la un obiect receptor i c obiectul care starteaz evenimentul este iniiator. Starea este rspunsul unui obiect la un eveniment i n acelai timp abstractizarea valorilor atributelor i a legturilor unui obiect. Unei stri i se asociaz un element valoric al obiectului care satisface o anumit condiie. Tranziia reprezint modificarea strii printr-un eveniment. Condiia este o funcie boolean bazat pe valorile obiectului, validat pe o perioad de timp dac apare evenimentul i dac tranziia este adevrat. Operaia este ataat strii i tranziiei i descrie comportamentul unui obiect ca rspuns la eveniment. Operaiile pot fi de dou feluri: activiti sau aciuni. Activitile reprezint operaii care necesit timp pentru a se executa i sunt asociate unei stri care o controleaz pn cnd un eveniment o ntrerupe i se produce o tranziie a strii. Aciunea este o operaie instantanee, asociat unui eveniment, a crei structur intern nu este interesant (nu este modelat ca o activitate cu eveniment de nceput, de sfrit i eventual eveniment intermediar). Corelnd stare-tranziie-condiie-operaie se obine Diagrama de Tranziie a Strilor (DTS) pentru obiectele din sistem cu comportament dinamic. Diagrama de Tranziie a Strilor este un graf n care nodurile sunt stri, iar arcele sunt tranziii datorate unor evenimente. Toate tranziiile din aceeai stare trebuie s corespund la evenimente diferite. Toate realizrile unei clase partajeaz aceeai DTS, aa cum partajeaz i aceleai caracteristici ale claselor. Diagramele de Tranziie a Strilor pot fi structurate pentru a descrie sisteme complexe. Structurarea se face prin generalizare i agregare. Generalizarea permite aranjarea structurii strilor i evenimentelor ntr-o ierarhie care s permit motenirea structurii i a comportamentului comun, echivalent cu concurena strilor.

78

Figura 2. 19 Forma general a unei DTS

Diagrama de Tranziie a Strilor pentru clasa de obiecte element-n_stoc este reprezentat ca n figura 2.20 n care punctul iniial l reprezint stocul sub nivel minim (este recomandabil a se reaproviziona) iar starea final mesajul cantitate insuficient pentru a onora comanda.

Figura 2. 20 DTS pentru clasa de obiecte Element_n_stoc

Diagrama de Tranziie a Strilor poate fi privit n mod dinamic, descriind structura de control a sistemului i unde strile interacioneaz unele cu altele prin evenimente partajate.

2.2.2.4. Modelul funcional al metodei OMT

Modelul funcional are ca scop descrierea algoritmilor sistemului evideniind modul n care sunt obinute ieirile pe baza intrrilor i a altor valori intermediare. Modalitatea grafic de reprezentare a modelului funcional este Diagrama de Flux a Datelor (DFD). Specific acestui model se folosesc termenii: proces, flux de date, flux de control, actor, depozit de date35.
35

A Survey of OO Methods, http://students.cs.byu.edu/~pbiggs/survey.html

79

Procesul corespunde unei operaii care indic ce date de intrare sunt transformate i ce date de ieire se obin. Fluxul de date permite conectarea proceselor la intrarea unui alt obiect sau proces, putnd fi transmis n mai multe locuri. Fluxul de control apare n diagrama de comunicare printr-un mesaj. Actorul const ntr-un obiect care produce sau consum date, numit terminator ataat intrrii sau ieirii DFD-ului Depozitul de date este materializat ca fiier ce ndeplinete funcia de stocare urmrind o accesare ulterioar. Actorii i depozitele de date au comportament i utilitate diferit. Diagramele de flux de date evideniaz pe lng fluxurile de date dintre terminatori, procesele i depozitele de date (interfaa sistemului modelat cu mediul respectiv) i efectul proceselor asupra datelor care afecteaz execuia unui proces36. Procesele din DFD trebuie implementate ca operaii ale obiectelor. Operaiile se regsesc n: funciile matematice; ecuaiile intrri-ieiri; tabele de coresponden intrri-ieiri; tabele de decizie; pseudocod i limbaj structurat. Modelul funcional este format din DFD-uri, adic din grafuri ale cror noduri sunt procesele, iar arcele fluxurile de date i de control. n concluzie, relaiile ntre cele trei modele sunt: 1. Modelul static descrie structura datelor pe care se va baza modelul dinamic i funcional. Operaiile din modelul obiectual corespund evenimentelor din modelul dinamic i funciilor din modelul funcional. 2. Modelul dinamic descrie structura de control i evideniaz deciziile care determin aciuni, apeleaz funcii i schimb valorile obiectelor. 3. Modelul funcional conecteaz modelul static i dinamic afectnd valorile atributelor din modelul obiect i evideniind restriciile.

36

N. Yoshida, Object-Oriented Extension for Reuse of Models, 6-th Conf. on Asia-Pacific Design Language

80

2.3 Unified Modeling Language cale de reunire a conceptelor orientate-obiect

Arhitectura sistemelor informatice complexe a fost revzut sub incidena unui curent privind formalizarea unui limbaj standard de modelare datorat unor personaliti (Meyer, Rumbaugh, Jacobson, Booch, Coad, Mellor etc.37) care propun structuri ale sistemului n raport cu implementarea acestuia, implementarea fiind privit ca o activitate secundar. Astfel la ntrebarea fundamental Ce este programarea, mai mult o art, sau mai mult o tiin, s-a rspuns prin primordialitatea explicit a arhitecturii sistemului. S-au dezvoltat mecanisme/abloane de proiectare(design patterns) i diferite instrumente CASE (Computer Aided Software Engeneering) de natur s asigure construirea unor modele necesare proiectrii. Aceste considerente au condus la apariia unui Limbaj unificat de modelare denumit UML:Unified Modeling Language caracterizat prin: UML este un limbaj universal dedicat construirii, manipulrii i vizualizarea componentelor sistemului informaional; UML este un limbaj pentru specificarea, vizualizarea, construcia i documentaia sistemelor software, acest limbaj fiind o colecie omogen de practici engineering utilizabile pentru modelarea i realizarea sistemelor complexe. UML asigur nelegerea semanticii sistemului prin materializarea deciziilor; UML nu conine limitri impuse de metodologia/metoda de proiectare, domeniul de activitate unde este utilizat sau mediul utilizat pentru dezvoltare UML realizeaz unificarea conceptelor orientate-obiect sub forma unui standard de proiectare, prin care se asigur definiia semanticii conceptelor utilizate, notaiile asociate acestora i documentaia necesar pentru dezvoltarea unui sistem informatic;

37

Usige UML-based Framework, www.omg.org/news/meetings/worksshops/presentations

81

 UML este folosit pentru modelarea sistemelor informatice de tip discret; UML permite dezvoltarea ierarhiei de modele, vederi i diagrame asigurnd viaductul modele vederi diagrame fiiere de cod surs date/cazuri de test. Vederile(Views) asigur prezentarea diferitelor aspecte ale sistemului modelat sub forma unor abstractizri ce constau ntr-o secven de diagrame38. UML utilizeaz elemente de modelare vizuale sub forma unor instrumente CASE, care pot asigura urmtoarele funcii: o generarea modelelor de analiz, proiectare i implementare; o generarea vederilor asociate modelelor de mai sus, diagramelor specifice vederilor; o posibilitatea utilizrii unor generatoare de cod implementarea sistemului realizat; o posibilitatea includerii unor generatoare de rapoarte; o posibilitatea prezenei instrumentelor de tip reverse engineering etc. prin care se poate asigura

Figura 2. 21 Ierarhia de modele, vederi i diagrame utilizate de UML

38

Davidescu N. Proiectarea Sistemelor Informatice prin limbajul UML, Editura ALL Back, Bucureti

82

 UML permite dezvoltarea i utilizarea modelrii vizuale asigurnd nelegerea semanticii sistemelor lumii reale cu participarea actorilor (analiti, programatori, experi, design-eri, implementatori etc.); UML utilizeaz termenul de model care realizeaz abstractizri ce descriu problemele complexe specifice. UML folosete n etapa de modelare abordarea obiectual care asigur optimizarea realizrii programelor.

2.3.1 Avantajele oferite de UML

Modelarea prin UML are urmtoarele avantaje permite construirea de modele complexe prin intermediul unui limbaj riguros de modelare standard; acest limbaj este considerat lingua franca pentru modelarea sistemelor informatice; limbajul UML nu asigur n mod automat succesul n realizarea sistemelor informatice ns permite ameliorarea i mbuntirea multor elemente specifice modelrii; acest limbaj de modelare conine elementele modelului (model elements) notaiile modelului i modul de utilizare expresia idiomatic n interiorul tranzaciilor.

2.3.2 Obiectivele fundamentale ale UML

UML are un spectru larg de utilizare putnd fi utilizat n toate fazele de dezvoltare i pentru toate tipurile de sisteme. Modelare optimal a arhitecturii sistemelor prin UML i propune urmtoarele scopuri: asigurarea modelrii sistemelor de orice tip, inclusiv a sistemelor software orientate-obiect;

83

 fundamenteaz explicit binomul conceptual-soluia operaional; asigur definirea unui limbaj de modelare utilizat att de factorul uman ct i de suportul fizic utilizat n realizarea sistemului; descrierea oricrui tip de sistem prin intermediul diagramelor orientate obiect realizeaz specificaii pentru domeniul Business Engineering prin care procesele de afaceri pot fi analizate, mbuntite i implementate prin tehnici adecvate (TQM-Total Quality Management, BPR-Business Process Reengineering) realiznd sisteme informatice la nivel micro, mezo sau macroeconomic. permite definirea unor soluii pentru diferite tipuri de sisteme (sisteme informatice, tehnice, n timp-real, distribuite, software sau de business). Fiecare aspect particular specific sistemului realizat va fi reflectat separat printr-o diagram/schem aferent sistemului construit. Aceste vederi vor asigura legturi cu limbajul de modelare specific UML. Modelarea unui sistem este o sarcin extensiv i de aceea acesta nu poate fi descris printr-un singur graf definit integral, fr ambiguiti, simplu i inteligibil. Se va descrie prin intermediul aspectelor: funcionale care au n vedere structura static, dinamic i interaciunile; nonfuncionale legate de coordonare/sincronizare, fiabilitate, amplasament; organizaionale legate de specificul activitii. Consider c orice sistem poate fi descris printr-un set de vederi, n care fiecare va reprezenta o proiecie complet a descrierii sistemului, inclusiv vederea particular a aspectelor sistemului. Mai mult, fiecare vedere particular va fi descris printr-un numr de diagrame care conin informaii i diferite aspecte particulare ale sistemului. n figura 2.22 am reprezentat vederile specifice cazului de utilizare (Use-Case VIEWS) fiind o descriere generic a utilizrii sistemului prin intermediul funciilor.

84

Figura 2. 22 Proiecia viziunilor cazului Use Case

Vederile au rolul de a descrie sistemul prin intermediul percepiei actorilor externi (client al sistemului, design-eri, dezvoltatori i personal de testare) particularizndu-se prin intermediul diagramelor cazului de utilizare (use-case diagrams) i eventual diagrama activitilor (activity diagrams). Actorul extern intracioneaz cu sistemul fiind un utilizator sau un sistem extern.

2.4. Comparaii ntre metodele de proiectare

Avnd n vedere faptul c structura datelor, aplicaiilor ct i relaiile dintre acestea sunt mult mai puin vulnerabile la schimbarea, comparativ cu funciunile, organizarea sistemului n jurul obiectelor acord o mare stabilitate de-a lungul ntregului ciclu de dezvoltare. Totodat proprietatea de ncapsulare, specific orientrii obiect, ct i interfeele care ascund implementrile interne ale obiectelor, constituie un nalt nivel de protecie oferit sistemului astfel modelat.

85

Un alt avantaj oferit de abordarea orientat obiect l constituie liniaritatea procesului de dezvoltare a sistemului. Deoarece metodologia orientat-obiect definete din primele faze obiectele pe care continu s le foloseasc i s le extind de-a lungul ntregului proces, separarea dintre fazele ciclului de via este mai puin perceptibil. n Object Modeling Technique obiectul modelat n timpul fazei de analiz este utilizat i n fazele de proiectare i implementare, unde este rafinat i extins progresiv 39 . Procesul este liniar pentru c nu exist discontinuiti a notaiilor utilizate pe tot parcursul derulrii activitii. Aceast liniaritate permite reluarea procesului de modelare iterativ, fiecare iteraie adugnd sau clarificnd anumite detalii, obinndu-se n final un model consistent, cu grad redus de eroare. Deosebiri substaniale ntre diversele metodologii orientate-obiect nu exist, majoritatea celor utilizate n prezent fiind mai mult o colecie de tehnici i convenii grafice de reprezentare care au ca obiectiv principal mbuntirea sistemelor complexe40 plecnd de la funcie, comportament, date. O comparaie ntre OMT i unele dintre cele mai rspndite metode orientate obiect, din punct de vedere al conceptelor utilizate, este prezentat n continuare:
Concepte Clas Clas abstract Clas concret Metaclas Clas generic Obiect Obiect activ Obiect pasiv Obiect entitate Obiect de interfa
39 40

OMT41 Rumbaugh * * * * *

OOAD42 Booch * * * * Clas parametrizat * * *

OOSE43 Jacobson Obiect * * * *

* *

Booch method Wikipedia, www.wikipedia.org/wiki/Booch Project management, www.icaen.uiowa.edu/~softeng/SElinks.html 41 OMT Object Modelling Technique 42 OOD Object Oriented Design 43 OOSE- Object-Oriented Software Engineering

86

Concepte Obiect de control Obiect central de interfa

OMT41 Rumbaugh

OOAD42 Booch

OOSE43 Jacobson * *

Cheie/identificator Atribut Atribut derivat Atribut al asocierii Atribut calificator Atribut discriminator Restricii pentru atribut

Cheie candidat * * * * * *

Cheie Cmp * * *

Se poate concluziona c metodologiile orientate-obiect analizate nu se deosebesc substanial, ele prezint de fapt aceleai concepte vzute din puncte de vedere diferite i cu notaii diferite. OMT comparativ cu celelalte metode orientate-obiect prezint avantajul c utilizeaz aceleai notaii pentru modelare n ntregul ciclu de via, astfel nct nu este necesar o trecere brutal la alte notaii sau interpretri ale semanticii n etapele urmtoare ale proiectrii. Principalul dezavantaj este acela c nu ofer o ghidare metodologic nc din etapele timpurii ale procesului de dezvoltare.

87

CAPITOL 2...................................................................................................................... 34 METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC ............................................................................................................................................. 34 2.1. Cerine generale n utilizarea unei metode de proiectare a sistemului informatic.... 34 2.1.1. Parametrii specifici de performan pentru sistemele informatice .................... 36 2.1.2. Necesitatea i structura procesului de evaluare a contabilitii informatizate... 41 2.2. Metodele de concepie i de realizare a unui sistem informatic ............................... 45 2.2.1. Caracterizarea metodei Merise .......................................................................... 50 2.2.2. Metoda OMT de proiectare a sistemelor informatice........................................ 62 2.2.2.1. Etapele ciclului de realizare a unui proiect n abordarea orientatobiect . 66 2.2.2.2. Modelul obiect n metodologia OMT......................................................... 71 2.2.2.3. Modelul dinamic n accepiunea metodei OMT......................................... 77 2.2.2.4. Modelul funcional al metodei OMT.......................................................... 79 2.3 Unified Modeling Language cale de reunire a conceptelor orientate-obiect.......... 81 2.3.1 Avantajele oferite de UML................................................................................. 83 2.3.2 Obiectivele fundamentale ale UML ................................................................... 83 2.4. Comparaii ntre metodele de proiectare .................................................................. 85 Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiiei 36 Figura 2.2 Legturile aferente actului decizie ..................................................................... 41 Figura 2.3 Criteriile de analiz a unei situaii...................................................................... 43 Figura 2.4 Evaluarea compartimentului financiarcontabil prin metoda scenariilor .......... 45 Figura 2.5 Diagrama fluxurilor de date pentru Clieni ........................................................ 46 Figura 2.6 Reprezentarea domeniilor unui organism economic.......................................... 51 Figura 2.7 Funcii i activiti ntr-un sistem operant.......................................................... 52 Figura 2.8 MERISE Ce-cum-cu cine se realizeaz?......................................................... 55 Figura 2.9 Studiu prealabil n cadrul metodei Merise ......................................................... 56 Figura 2.10 Traseul sarcini-prelucrri, date, mesaje................................................... 61 Figura 2. 11 Circuitul analiz-modelare evenimente........................................................... 66 Figura 2. 12 Obinerea modelului de analiz....................................................................... 67 Figura 2. 13 Forma general de reprezentare a unei asocieri modelate ca o clas.............. 73 Figura 2. 14 Asociere mprumut modelat ca o clas...................................................... 74 Figura 2. 15 Asociere Client-Banc-Investiie ......................................................... 74 Figura 2. 16 Reprezentarea general a motenirii............................................................ 76 Figura 2. 17 Monitorizarea simultan a clienilor, comenzilor i a stocurilor..................... 76 Figura 2. 18 DTE a aplicaiei Clieni................................................................................... 77 Figura 2. 19 Forma general a unei DTS............................................................................. 79 Figura 2. 20 DTS pentru clasa de obiecte Element_n_stoc ............................................ 79 Figura 2. 21 Ierarhia de modele, vederi i diagrame utilizate de UML............................... 82 Figura 2. 22 Proiecia viziunilor cazului Use Case ............................................................. 85

88