CAPITOL

2

METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC

2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului informatic

Evoluţia tehnologică presupune o anumită infrastructură care trebuie să cuprindă pe lângă hardware, produse şi sisteme informatice bazate pe noi sisteme de gestiune a bazelor de date sau pe noţiunea de teletransmisie materializată prin reţele naţionale de date cu rate de transfer cât mai mari; posturi de lucru la toate nivelele operaţionale dintr-o unitate (sisteme interactive om–maşină). Mediile economice trebuie să se adapteze rapid la aceste tehnologii care presupun costuri relativ ridicate ocazionate de elaborarea şi întreţinerea produsului informatic, dar şi dificultăţilor crescânde de menţinere la anumite standarde a nevoilor utilizatorilor. Necesitatea adaptării devine stringentă în mediul financiar–contabil care priveşte schimbările într-un orizont de timp ca pe o protecţie a investiţiei. Continua dezvoltare a domeniului tehnologiei informaţiei impune elaborarea de noi metodologii pentru realizarea sistemelor de aplicaţii informatice, cristalizându-se în analiză şi proiectare două tipuri de metode utilizate: tradiţionale (structurate, orientate pe funcţii/date, metode sistemice) şi metode orientate obiect.

34

Aportul fiecărei metode concretizat printr-un limbaj comun utilizator–informatician este manifestat pe parcursul întregului proces de studiu prin apariţia şi existenţa punctelor de validare. Metoda, produs al reflexiei permanente, constituie un demers raţional şi empiric, deductiv şi inductiv. Conform unor specialişti, metoda reprezintă un „ansamblu de mijloace industriale puse în practică pentru organizarea unei fabricaţii” sau un „ansamblu de reguli, principii normative care corespund învăţământului, practicii şi artei” 14 . Ea se aplică tuturor conceptelor create de tehnologie, care observă şi analizează practica cotidiană din organizaţii. Retrospectiv se constată că evoluţia 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 activităţii de producţie software, mă conduc la ideea că în informatică o metodă universală nu este posibilă. Orice metodă de concepţie a unui sistem informatic trebuie să ia în considerare factorii de natură tehnică şi socio-economică. În domeniul tehnic trebuie să permită derularea activităţilor î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 agenţi care urmăresc descentralizarea deciziilor operative; simplificarea sarcinilor şi ameliorarea ergomiei postului de lucru; securitate şi confidenţialitate; dezvoltarea proceselor de gestiune prin creşterea posibilităţii de supervizare la diverse nivele; supleţe tehnică şi comercială sau structurală strict necesară în situaţii de fuziune, extindere. Metoda vizează asocierea eficientă a aspectelor organizaţionale şi informatice; creşterea calităţii relaţiilor utilizatori–informaticieni, reprezentând un mijloc comun de studiu, concepţie, dialog, formalizare a deciziilor şi de control preventiv. Cu alte
14 15

Le Nouveau Petit Le Robert, Edition 1993 O’Brien J. - Systèmes d’information 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 informaţiilor determină în mare măsură performanţele compartimentului financiar-contabil, atingerea obiectivelor pe care firma şi le-a propus. Există două abordări ale performanţei: una ce dezvoltă o situaţie stabilă a sistemului şi o alta care pune în valoare dinamismul, noutatea în domeniul considerat. În cazul unor schimbări apare problema determinării valorii informaţiei noi; definită prin efectul deciziei posibile de adoptat. Existenţa stabilităţii mediului informaţional 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ă soluţii: funcţionarea 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, investiţiei

36

a) centru de costuri unde utilizatorii decidenţi şi managerul îşi asumă responsabilităţi sporite în gestionarea a costurilor, iar performanţele vor fi judecate prin capacitatea de a micşora ecarturile raportate la costurile previzionale, de a sporii productivitatea şi de a propune soluţii (acţiuni) generatoare de profit. b) centru de profit scoate în relief faptul că deşi profitul obţinut de contabilitatea informatizată nu este autentificabil în sine, trebuie să considerăm că ea este un prestator de servicii ce se adresează unor beneficiari bine identificaţi. Opinia mea este că profitul mediului contabil este indus de beneficiile obţinute de celelalte segmente ale firmei sau de aceasta ca urmare a folosirii produselor informatice. Rezultatele obţinute pot fi apreciate, extrem de clar prin relaţia: număr de lucrări (aspect cantitativ), « timp » conţinut lucrare (aspect calitativ). c) centru de investiţie vizează contabilitatea informatizată care trebuie să câştige autonomie în efectuarea investiţiilor (informatice) şi apoi se impune să le justifice. Pentru zona contabilă informatizată putem vorbi de reliefarea unor plusuri cantitative (economice) şi calitative (politice). În legătură cu primul aspect consider că viteza de circulaţie a informaţiei, dar şi capacitatea ei de adaptare se pot constitui în resurse importante. Remarc două faţete ale acestui tip de performanţă: ♦ Câştigurile directe de productivitate permit executarea unei aceleiaşi

atribuţii (decizii), cu mijloace reduse. De exemplu: o suprafaţă ocupată mai mică, utilizatorii decidenţi mai puţini, costuri ale hardului, softului sau reţelei mult diminuate. ♦ Creşterea volumul activităţilor financiar-contabile, unde informaţia

suplimentară poate avea un impact pozitiv asupra domeniului contabil informatizat, dar numai în măsura în care are „desfacerea asigurată”. Performanţele politice (calitative) sunt mult mai greu de evidenţiat sau mai ales de comensurat. Consider că cele mai importante obiective ale unei metode sunt: ♦ flexibilitatea sistemului;

37

♦ satisfacţia utilizatorilor; ♦ calitatea produselor financiar-contabile. Flexibilitatea reprezintă capacitatea de adaptare a structurii contabilităţii informatizate la mediu. Un sistem deschis, cu numeroase puncte de „ascultare” şi cu o grijă deosebită pentru comunicaţie (orală, scrisă sau electronică) va reacţiona rapid la oportunităţi şi va putea să ţină cont de restricţii. Flexibilitatea se va aprecia prin raportarea la un anumit obiectiv, fixat în cadrul unei evoluţii „istorice”. Sistemul deschis va avea în vedere şi practicile agenţilor economici16. Satisfacţia utilizatorilor decidenţi reprezintă criteriul de apreciere a performanţei sociale stabilit de „actorii” participanţi la procesul productiv creativ. Calitatea produselor financiar–contabile este apreciată subiectiv de diferiţii beneficiari: clienţi, bancă, manageri etc., dar şi obiectiv - prin deducerea „deşeurilor informaţionale”, a erorilor etc. Depinde foarte mult de aşteptările diverşilor consumatori (din interiorul sau exteriorul firmei), dar şi de sistemul de producţie financiar – contabil în „ansamblu (inclusiv modalităţile de control). În continuare voi prezenta câteva criterii de apreciere a performanţelor zonei contabile informatizate pe care, după părerea mea, le consider esenţiale: a) criteriile de natură tehnică au în vedere conţinutul sistemului, capacitatea acestuia de a îndeplini funcţii specifice. Vor fi luate în considerare atât aspectele legate de producerea de informaţii utile, cât şi cele ce privesc gestiunea sistemului şi a firmei. b) criteriile organizaţionale reduc incertitudinile sistemului informatic financiarcontabil şi permit grefarea pe structura acestuia. Creşterea capacităţii lui de prelucrare ori gradul său de deschidere va determina modificări structurale ce se impun a fi pe deplin stăpânite. Apreciez că fiind necesară analiza evoluţiei şi a adaptărilor prin prisma următoarelor stări ale structurii: - specializare - gradul în care activităţile financiar-contabile sunt divizate pe „roluri" specializate, în funcţie de pregătirea utilizatorilor decidenţi.

38

formalizarea . .vizează importanţa acordată luării deciziilor de către manager.nu este legată implicit de noile tehnologii.acumulările suplimentare.standardizare .softeam.cheltuieli de implementare. Consider că. www.măsura în care sunt stabilite reguli şi proceduri generale pentru a defini sarcinile de executat şi a controla aplicarea lor. c) criteriile economice . în vederea anticipării unei eventuale reacţii de respingere (putându-se folosi în acest sens metodologia CRIG). pentru zona contabilităţii informatizate..centralizarea . În categoria criteriilor organizaţionale de apreciere a performanţelor segmentului financiar–contabil informatizat cred că se impune a fi inclusă şi măsurarea gradului de schimbare. Chi .utilizarea lor are în vedere tipul proiectului şi etapa procesului de decizie. As . depinzând uneori de gradul de pregătire al utilizatorilor decidenţi. urmărindu-se să nu se accentueze fenomenul birocratic. .economii rezultate prin introducerea tehnologiilor informatice şi de comunicaţie.com/conseil_modelisation 39 . În acelaşi timp este importantă şi cunoaşterea atitudinii utilizatorilor decidenţi. După părerea mea există două mari categorii de repere în stabilirea dimensiunii contabilităţii informatizate: unele ce îşi propun să urmărească costurile şi avantajele (metode a posteriori) şi altele care doresc să efectueze demersuri pentru o analiză complexă în vederea alegerii investiţiei (metode a priori). coeficientul eficienţei globale a sistemului informatic financiar-contabil 16 Transition from the „data/processing”. putem pune în evidenţă mai multe praguri şi măsurări ale eficienţei: ♦ (Keg): Keg = (Ec + As) / (Chi + Che) unde: Ec . Informatizarea contabilităţii duce la crearea de noi proceduri. le elimină pe cele redundante sau neutilizate.

• elaborarea bugetului informatic şi controlul realizării indicatorilor prevăzuţi. Calea principală de creştere a eficienţei sistemelor informatice este reducerea cheltuielilor prin: • utilizarea de elemente standardizate şi tipizate. cu atât standardele vor fi mai mari şi se vor înregistra acumulări suplimentare (implicit profit net). Cu cât durata de recuperare a cheltuielilor cu caracter informatic (ce privesc echipamentele.Che – cheltuieli de exploatare a sistemului.(Dr): Dr = 1/Keg Se va avea în vedere totalitatea cheltuielilor (de investiţie.optimizare traficului Remarc anumite „forţelor motrice” care ajută la formarea rezultatului sistemului informatic financiar–contabil: producţia informaţională şi modalităţile de 40 . de exploatare) iar sistemul informatic se va aprecia ca fiind eficient dacă Keg >1. ♦ durata de recuperare a cheltuielilor este invers proporţională faţă de coeficientul eficienţei globale. programele. iar Dr <5.optimizarea prelucrărilor . • îmbunătăţirea parametrilor de exploatare a aplicaţiilor informatice. Performanţele sunt direct legate şi de dimensionarea optimă a sistemului informatic financiar – contabil aşa cum este prezentat mai jos: Caracteristicile sistemului Abordare orientată client Efectele economice Efect de anvergură (eficienţa partajării resurselor şi eficacitatea utilizatorilor decidenţi) Bază comună a prelucrărilor şi Efect de anvergură (cost al sistemului integrat < comunicaţiei costurile a două neintegrate) Evoluţie progresivă Reducerea efectului de complexitate Portabilitate Efect de anvergură (partajarea aplicaţiilor pe platforme mai eficiente) Convivialitate Efecte de învăţare şi experienţă (reducerea costului de pregătire) Performanţa sistemului: Efect de anvergură (diminuarea costului de prelucrare şi transmitere) . reţelele) este mai mică.

preţurile de aprovizionare cu diferite materiale.2. costul de întreţinere şi reparare al reţelei sau echipamentelor etc. • referenţialul. Contribuţia fiecărui factor asupra evoluţiei profitului se determină utilizând procedeul substituţiilor în lanţ care permite măsurarea influenţelor sau a alternativelor. 41 . Figura 2. evoluţia salariilor utilizatorilor decidenţi şi/sau a managementului. • raporturile de putere.1.2. 2.valorificare a acesteia. Necesitatea şi structura procesului de evaluare a contabilităţii informatizate Liniile de forţă ale evaluării contabilităţii informatizate se bazează pe două puncte esenţiale: eficacitatea şi eficienţa. fapt ilustrat în figura 2.2 Legăturile aferente actului decizie Operaţia de evaluare în cadrul sistemului informatic financiar-contabil va ţine cont de trei elemente fundamentale: • resursa umană. Există o raportare permanentă a contabilităţii informatizate la un sistem de referinţă (referenţial) şi o legătură directă cu actul deciziei.

organizaţională. Miller arată că în mod normal capacităţile cognitive ale unui om nu pot înţelege simultan mai mult de 5-9 informaţii noi . accentuarea complexităţii căutării şi selecţiei datelor. Faza de selecţie presupune înţelegerea comportamentului sistemului informatic financiar-contabil. După părerea mea soluţia apelării la experţii din exterior nu este întotdeauna cea mai bună deoarece ei se interesează mai mult de analiza disfuncţionalităţilor decât de efectele declanşate de comportamentul sistemului.Pentru o evaluare corectă şi completă a contabilităţii informatizate consider că se impune să se cunoască foarte bine contextul. B.A. utilizând şi facilităţile procesoarelor de tabele. A. depăşirea unui nivel al costurilor dificil de suportat.hw.ac. plecând de la tendinţele existente în cadrul lui. practicile existente. dar şi „cultura" sau istoricul. inteligenţa artificială (în special sistemele expert) pot aduce un ajutor substanţial în faza de selecţie. www. Procesul de evaluare a unui sistem presupune parcurgerea următoarelor faze: selecţia. În cadrul „acesteia în procesul de evaluare a contabilităţii informatizate pot apare probleme legate de: puterea simbolurilor. J. însă în unele situaţii consumă foarte mult timp cu această preocupare şi nu-i mai rămâne decât foarte puţin pentru activităţile de decizie efective (mai ales de tip strategic).macs. prin consultarea bazelor de cunoştinţe îmbogăţite cu experienţa trăită. 17 Associations – Links. Faza de interpretare. fluiditatea „catartică". Emery şi G. Faza de selecţie permite obţinerea unei imagini sistemică a situaţiei şi pentru a nu lua decizii cu consecinţe negative se stabilesc foarte clar factorii de tip selectiv. dinamica actului de evaluare. Managerul trebuie să obţină maxim de informaţii pentru a reduce incertitudinea în faţa căreia se află. tehnică.C.uk/ism/ug4 42 . precum şi de la liniile sale de forţă.„chunks”17. Consider că informatica. În acest fel se va evita creşterea sarcinilor administrative şi a efectelor. interpretarea şi decizia. Apare evidentă evaluarea strategică faţă de cea operaţională. Aceştia pot fi de natură economică. politică sau sociologică şi se referă la aspecte cantitative şi calitative între care apare o vie concurenţă.

astfel pentru unii indivizi reţelele de telecomunicaţie vor constitui punţi spre o nouă eră a comunicaţiei. • valorizarea soluţiilor prin implicarea noilor restricţii pentru sistem. autonomia şi creşterea productivităţii muncii. ignorată până 43 .3 Criteriile de analiză a unei situaţii Fluiditatea „catartică” este o noţiune care a fost pusă în evidenţă de cercetătorul Bruno Lussato şi se referă la „mobilitatea mai mult sau mai puţin importantă a transferului de rezonanţă a unei reprezentări R spre o reprezentare RI. Ei îşi construiesc diverse agregate simbolice legate de atuurile folosirii calculatorului pe propriul birou. Fiecare agregat va poseda un conţinut „catartic” specific.Puterea simbolurilor reprezintă pentru mulţi utilizatori decidenţi sinonimă cu descentralizarea. Orice metodologie de utilizare a unei anumite situaţii din cadrul contabilităţii informatizate. în schimb pentru alţii vor fi doar surse a numeroase pericole. Paradigmă Evaluare criterii cantitative Evaluare criterii calitative Valorizare soluţii decidenţi Parametrii obiectivi Gândire decidenţi Restricţii Figura 2. inclusiv stabilirea unui diagnostic corespunzător va implica un demers riguros cu trei laturi: • evaluarea criteriilor ce determină parametrii obiectivi ai unei anumite reprezentări (de tip cantitativ). • evaluarea criteriilor care duc la stabilirea ordinii congruenţelor în gândirea contabilului şef şi a utilizatorilor decidenţi.

Aceasta din urmă este dificil de stabilit. putând dobândi caracter ireversibil. În figura 2. o greşită definire (structurare). deoarece fiecare utilizator decident. Valorizarea scenariilor va avea un caracter relativ dacă se opreşte doar la aspectul pur informatic şi dacă nu va urmări şi noţiunea de utilitate.atunci". Dinamica actului de evaluare reliefează „cultura” sistemului mai ales „slăbiciunile” vizibile sau ascunse. Uneori aceste minusuri pot fi imaginare. o varietate (incoerenţă) exagerată.4 am redat aplicarea metodei scenariilor asupra elementului structural financiar-contabil. plasat în faţa unei aceleiaşi situaţii. importante (exemple: posibilităţile de adaptare la nou. 44 . Fluiditatea parametrilor de interpretare a elementelor structurale ale contabilităţii informatizate va fi influenţată de faptul că. Uneori decizia finală este sinteza rezultatelor diferitelor decizii intermediare luate. eliminate din evaluare (exemple: compatibilitatea mărcilor de echipamente. compatibilitatea resurselor). Vom putea distinge în zona contabilă informatizată trei tipuri de criterii: primordiale (exemple: mărimea intervalelor de timp. datorită modificării punctelor de vedere şi a mediului. capacitatea de a evita hipertrofierea configuraţiilor informatice. posibilitatea de autoformare a utilizatorilor decidenţi). Unele decizii admise în trecut nu mai puteau fi înţelese la un moment dat. de sisteme decizionale şi repartizarea pe roluri (stabilirea responsabilităţilor). fiind vorba de fapt de lacune ale criteriilor. valorizarea acestora. inclusiv alinierea acestora la obiectivele urmărite). interpretarea nu poate avea valoare decât într-un spaţiu temporal definit prealabil. Faza de decizie – apare ca rezultat al unei cooperări şi a unui limbaj comun între diferiţii „actori” din sistemul informatic financiar–contabil. va avea obiective şi scopuri diferite. o percepţie eronată. alegerea soluţiei care este considerată ca fiind cea mai bună. C. Fluiditatea determină stabilirea unei anumite ponderi pentru fiecare criteriu evaluat la un moment dat. A imagina un „scenariu” presupune construirea de structuri. Apreciez că evaluarea elementelor componente ale compartimentului financiar–contabil prin metoda „scenariilor” va avea în vedere. de fiecare dată trei mari etape: stabilirea scenariilor şi evaluarea efectelor previzibile.

4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor Valorizarea va ţine cont de natura informaţiei (operaţională. 2. ele fiind în fapt carteziene. totul depinde de sistemul de referinţă (referenţialul) ales. unui ansamblu unitar în interacţiune având fiecare o funcţie clar definită. metode sistemice. metode orientate obiect. nu există alegeri bune sau rele.Figura 2. JSD 45 .2. Cele mai cunoscute metode aparţinând acestei prime generaţii sunt: SADT (Structured Analisys and Design Technique). dacă aceasta se schimbă rezultatele evaluării se vor modifica. Concepţia constă în crearea. tactică. pornind de la specificaţiile. Apreciez că. strategică) şi va impune exprimarea utilităţii producţiei şi difuzării acesteia. Diagramele de fluxuri de date descriu prelucrările logice ale datelor şi arată maniera în care datele intrate sunt modificate printr-o suită de transformări funcţionale pentru a ajunge la datele de ieşire. Metodele de concepţie şi de realizare a unui sistem informatic Metodele de concepţie se pot clasifica în trei mari categorii: metode structurate. Metodele structurate folosesc descompunerea progresivă descendentă „top-down”. Optimul soluţiei nu este obligatoriu cel mai bun raport performanţă/preţ (o sumă la nivel operaţional nu va avea aceeaşi valoare cu cea de la nivelul strategic).

B. descrierea programului sau a unui modul fiind stabilite pe mai multe niveluri. ceea ce determină concentrarea efortului de analiză şi proiectare asupra prelucrărilor în condiţiile în care acestea sunt cele mai supuse modificări în timp. modelarea datelor căzând pe un plan secund.G.5 Diagrama fluxurilor de date pentru Clienţi Avantajele metodelor ierarhice constau în simplitate şi o bună adaptare la cerinţele formulate de utilizator. Proliferarea aplicaţiilor creează propriile lor fişiere ducând la redundanţe şi mai ales incoerenţă a datelor în sistemele de informare a organizaţiilor. prin limbajul de descriere a datelor. Dezavantajele pornesc de la conceperea sistemelor informatice conform cerinţelor analizei funcţionale. Diagramele de structură permit vizualizarea structurii ierarhice.D. prin rafinări succesive.(Jackson System Development). datele şi prelucrările sunt examinate împreună definindu-se actigrame (sau diagrama activităţilor) şi datagrame (diagrama datelor). Toate au la bază analiza funcţională a întreprinderii. În cazul metodei SADT. Figura 2. sau ca o diagramă – fiu (dezvoltare a unei părţi a celei părinte). Metodele structurate au fost integrate în S. Yourdon etc. Metoda SADT propune un ansamblu de diagrame ordonate ierarhic în care fiecare poate fi considerată fie ca o diagramă – părinte (sinteză a diagramelor sale fiu). 46 .

Astfel apar diferenţe de viteză dictate de recurgerea la un mijloc de stocare (tampon). Două metode constituie referinţa de reprezentare semantică: metoda individuală18 care va fi integrată Merise şi metoda entitate–relaţie19. 1. În această calitate ele constituie formalisme lizibile în cadrul specificaţiilor de nevoi. Sistemul este organizat după modelul producător–consumator cu mecanisme de excludere mutuală. de remarcat fiind cele din reţele Petri pentru aspectul dinamic care au fost dezvoltate de formalizări specifice.. . Majoritatea permite definirea de restricţii descriind aspectele statice. International WorkShop on Data Structure Models for Informations Systems 19 Chen P. de la recepţia unui stimul. stabilite între acestea.The entity-relationship model. Se disting două clase active în timp real: • sistemele de urmărire-control. • sistemele de cumulare de date. Atunci când 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. mars 1976 18 47 . Acestea reprezintă oarecum un sistem de stimuli/răspuns. în acelaşi timp. Tardieu H. Amintesc printre metodele sistemice pe cele de concepţie în timp real care asigură funcţionarea corectă în funcţie de rezultatele produse prin sistem şi de momentul la care ele sunt produse. stimulii fiind generaţi de captatori sau de acţionari. şi col. Aceste metode se compun din abstractizări care prezintă lumea reală ca pe o colecţie de entităţi şi de legături. declanşează acţiuni care eficientizează acţionarii (de exemplu sistemele de alarmă antifurt din imobile).Metodele sistemice permit vizualizarea şi înţelegerea organizării datelor. 1. Perioadele procesului de achiziţie şi cele ale procesului de procesare nu sunt în armonie. dinamice sau chiar temporare ale entităţilor. ALM transaction of database systems. Sistemele de urmărire şi control cercetează în permanenţă numărul de captatori.The individual model. pentru a evita cazul unde producătorul şi consumatorul de date acced. Aceste metode recurg la diverse formalisme. Sistemele de cumulare de date culeg datele captate pentru procesare şi analiză. la elementul tampon. şi în funcţie de valoarea lor.

comunicările. Toate celelalte concepte: funcţii. unitar de-a lungul întregului ciclu de viaţă. Nivelul organizaţional exprimă alegerile întreprinderii legate de resurse umane şi materiale. când şi cum? 3. Spre deosebire de metodele ierarhice. Nivelul fizic este reprezentat prin alegerile tehnice urmărind specificitatea lor. logic şi fizic”21. şi col. Metoda orientată obiect este caracterizată prin atenţia deosebită acordată concomitent structurii datelor şi structurii funcţionale. Reprezentative sunt metodele Information Engeneering.Proiectarea sistemelor informatice. Se integrează la acest nivel noţiunile de timp. La fiecare nivel de abstractizare sistemul de informare este reprezentat prin trei modele: datele. . Apropierea se realizează la nivel conceptual20 şi se disting patru nivele de abstractizare.Metodele sistemice cuprind de o manieră globală sistemul informaţional şi reprezintă a doua generaţie a metodelor de proiectare. . Această viziune permite construirea unei baze stabile în procesul de dezvoltare a modelului şi utilizarea conceptului obiect. metodele sistemice acordă „prioritate datelor faţă de prelucrări şi respectă cele trei nivele de abstractizare introduse de raportul ANSI/SPARC: conceptual. Nivelul conceptual exprimă opţiunile de gestiune. loc de actori şi se pun următoarele întrebări: cine. Metoda orientată obiect se caracterizează prin definirea a trei modele: 20 21 Nanci D. Editura Dual Tech. Sybex Stanciu V. Avantajele metodelor sistemice apar din promovarea tehnologiei bazelor de date. datele şi prelucrările analizate-modelate independent cu reunirea lor cât mai târziu posibil.Ingénierie des systèmes d’information avec Merise. Sistemul informatic este abordat sub două aspecte complementare. unde. şi col. Bucureşti 48 . evenimente gravitează în jurul obiectelor. formulând întrebarea: Ce facem? 2. AXIAL etc. Ceea ce este specific acestor metode este utilizarea teoriei sistemelor în analiza întreprinderii. prelucrările. MERISE. astfel încât nu este necesară trecerea la alte notaţii sau interpretări de semantică în diferite etape de dezvoltare. asocieri. Nivelul logic permite alegerea mijloacelor şi a resurselor informatice făcând abstracţie de caracteristicile lor tehnice precizate. 4. Dezavantajele sunt datorate deficienţelor care pot apărea în modelarea prelucrărilor şi a discordanţelor posibile între modelele datelor şi prelucrărilor. 1.

ce se întâmplă de-a lungul său şi cum este influenţat obiectul. clienţi. precum şi a legăturilor şi a relaţiilor dintre ele. Modelul funcţional prezintă transformările valorilor datelor precizând sursa şi destinaţia lor. • Modelul dinamic are rolul de a descrie stările pe care le poate avea un obiect şi evenimentele la trecerea dintr-o structură în alta. a operaţiilor şi atributelor. • Modelul funcţional are rolul de a descrie prelucrările şi fluxurile de date. urmând astfel evoluţia organismului economic. Majoritatea metodelor orientate obiect utilizează reguli sau operaţii semantice: generalizarea/specializarea. Modelul dinamic descrie interacţiunea dintre obiecte şi este focalizat pe aspecte ce se schimbă în timp. bancar. deoarece orice obiect are un ciclu de viaţă cu un punct de pornire şi unul de sfârşit. financiar pe care îl deserveşte. Informaţia gestionată în cadrul unui sistem informatic are tendinţa de creştere în complexitate. agregarea/descompunerea. • Sistemele informatice evoluează spre abordări multimedia care combină text cu foi de calcul.• Modelul obiectelor are rolul de a descrie obiectele care intervin în problema de rezolvat şi relaţiile dintre ele. Modelul dinamic descrie acest ciclu de viaţă. claselor de obiecte. etc. Modelul obiectual reprezintă descrierea structurii statice a obiectelor. • Sistemele informatice realizate trebuie să fie flexibile în raport cu modificarea structurilor de date şi trebuie să evolueze natural în timp. produse. animaţie şi voce. combinate cu moştenirea şi încapsularea. 49 . servicii. grafice. iar manipularea ei trebuie să fie într-o formă uşor de perceput de către utilizatorul final. Avantajele oferite de metoda OMT sunt valorificate pe deplin în proiectarea şi realizarea de sisteme informatice care trebuie să răspundă unor noi cerinţe şi anume: • • Reprezentarea complexă a realităţii (firmă.).

Consider necesară corelaţia fluxurilor de intrare-ieşire cu sistemul de pilotaj al agenţilor economici fapt materializat prin acţiunea în timp real a sistemului informaţional.sourceforge..5 prezint implicarea sistemului de management şi a sistemului informaţional. Caracterizarea metodei Merise Metoda MERISE asigură proiectarea de sisteme de gestiune ambiţioase permiţând dualitatea între tratamentul evenimentelor trecute şi furnizarea elementelor de previziune aplicabile centrelor de responsabilitate. a oferit garanţia stabilităţii şi evoluţiei metodei.1. se numea teoria sistemelor.decizi” constituie al doilea „suport” al filosofiei MERISE.pentru a acţiona mai bine”. în ultimă instanţă soluţia pentru informatizarea unui domeniu dat este în realitate o problemă de luare a unei decizii adecvate.2.. pe parcursul însuşirii metodelor sistemice se poate asocia figurativ enunţul următor: „a se ridica pentru a vedea mai bine. http://nextojects. pentru că. Practica în acest domeniu a evoluat considerabil traversând un curent de gândire numit sistemică sau. Acest curent de gândire care a cuprins şi alte discipline de cercetare.. „A înţelege nu este suficient pentru a acţiona.net 50 . ceea ce altă dată. Din raţiuni didactice. Utilizarea metodei MERISE trebuie să facă posibilă descompunerea problemelor de organizare a muncii. 22 Merise Method Standard. Fundamentul metodei constă în utilizarea mijloacelor de reprezentare cumulativă a structurii organismelor economice corelată cu domeniile de activitate proprii.a înţelege.. Ea dispune de toate instrumentele care să permită realizarea etapizată a unui sistem informatic cu grad mare de integrabilitate. de cele mai multe ori. fiind baza filosofiei MERISE22 iar toate conceptele operatorilor sistemici pentru ştiinţa organizării sunt asimilaţi şi în cadrul acestei metode. În figura 2. trebuie şi să...2. Pot fi consecinţe importante legate de acest demers. pornind de la localizarea unui subansamblu reprezentativ. Numele metodei este abrevierea de la „Methode d’Etude et de Realisation Informatique par le Sous – Ensemble representatif”.

Figura 2. Sistemul operant urmăreşte producerea rezultate pe baza intrărilor din mediul extern adaptându-şi activitatea în funcţie de deciziile specifice primite.6 Reprezentarea domeniilor unui organism economic Apare evidentă activitatea de pilotaj cu sarcini de coordonare şi decizie corelată cu obiectivele fixate. 51 . Ansamblul activităţilor sistemului operant formează imaginea dinamică de nivel „acţiune”. aplicate asupra intrărilor pentru a produce ieşirile dorite. În acest context apare evidentă implicarea metodei MERISE în fixarea descrierii activităţii sistemului operant şi a implicării sistemului informatic. Este evidentă descrierea activităţii sistemului operant orientată pe baza regulilor de funcţionare. Implicarea sistemului informaţional apare evidentă prin necesitatea de fuziune a datelor exprimată de pilotaj şi execuţia operaţiunilor productive. datele şi prelucrările sunt studiate şi modelate împreună.permite alcătuirea unor magistrale de circulaţie prioritară cu scopuri de actualizare a deciziei şi de dezagregare pe centre de responsabilitate. Corelând elementele prezentate anterior constat invariaţia funcţiilor sistemului operant care determină activităţi bine delimitate. Elementul nodal . În cadrul proiectării unui sistem informatic.sistemul informaţional . stabilite prin sistemul de management. Se va avea în vedere faptul că vor fi necesare mutaţii la nivelul cerinţelor ca reacţii la fluxurile de intrare-ieşire în şi din sistem.

Identificarea acestui ansamblu reprezentativ este unul dintre paşii de bază pentru utilizarea metodei Merise. coordonării unui proiect de informatizare într-un organism. analiza. Responsabilitatea conducerii.7 am disociat ansamblul activităţilor sistemului operant faţă de mulţimea funcţiilor sale. că există multe metode de concepţie şi punere în exploatare curentă rezultă că cele mai multe dintre ele se pot folosi în mod combinat sau complementar. Proiectarea şi realizarea unui sistem informatic sunt operaţiuni dificile pentru că obligă la luarea în considerare a tuturor factorilor sistemului om–maşină. 52 .7 Funcţii şi activităţi într-un sistem operant În figura 2. • decelarea problemelor legate de organizare şi informatizare necesită o anumită „filozofie”. că sunt nenumărate mijloace de documentare. urmărind detalierea fiecărei etapă de studiu şi aplicarea unor instrumente specifice. Ea are la bază o filosofie proprie a derulării întregului proiect. Dacă acceptăm ideile că sunt mai multe modalităţi de delimitare a domeniilor de studiu. • existenţa mijloacelor care să permită localizarea şi rezolvarea problemelor. concepe şi realiza un proiect care acoperă activitatea unui domeniu bine definit.Figura 2. Subansamblu reprezentativ în cadrul unui sistem operant este format din reuniunea de funcţii care pune în evidenţă cel mai bine comportamentul întregului sistem operant. MERISE este o metodă cu ajutorul căreia se poate defini. ne situează în faţa realităţii următoare: • termenele cuprinse în studiul de proiect trebuie respectate.

Această viziune consideră că un anumit domeniu este compus din părţi corelate între ele şi cu legături cu exteriorul. Paris 53 . În această privinţă interesează totalitatea problemelor înainte de a da o soluţia globală. MERISE poate realiza sisteme informatice din mai multe perspective: • MERISE perspectivă sistemică. şi col. subsisteme informatice independente.23 Abordarea descendentă constă în a coborî. abordate într-o maniere globală. decât să se încerce a se integra a posteriori. – Systèmes d’Information dynamique et organisation. astfel spus întregul este altceva decât suma părţilor. Este mai bine să se creeze şi să se realizeze din start un sistem informatic care să ţină cont de obiectivele planificate. Apărătorii acestei abordări avansează argumentul că este mai bine să acţionezi progresiv. filosofia MERISE se poate constitui sub forma unui ghid de abordare a unui sistem informatic pus în evidenţă sub forma sintetică utilizând o semantică bazată pe cuvinte cheie cât mai sugestive. Abordarea ascendentă are ca punct de plecare nivelul operaţional (aflat la baza piramidei ierarhice) şi prin realizarea informatizării la fiecare nivel în parte. se ajunge la un sistem informatic care poate atinge nivelul punctul extrem al piramidei. 23 Marciniak R. Este deci o consolidare a unui proiect care ne permite să avem în faza finală. pe scara piramidei ierarhice. decât să mizezi pe ipoteza nerealistă că un proiect global poate fi ţinut permanent la zi.Reamintesc în acest context două mari viziuni de concepţie a sistemelor informatice: abordarea ascendentă cunoscută mai simplu sub numele de bottom-up şi abordarea descendentă sau top–down. Editura Economica. până la bază şi realizând totodată şi o analiză. În esenţă. caracteristică pentru toate sistemele informaţionale. informatizarea completă a unui sistem informaţional–organizaţional specific unui organism economic supus analizei. MERISE este o metodă de concepţie de sisteme informatice care se poate înscrie în această abordare descendentă.

Editura Vuilbert. Paris Merise Method and knowledge. opţiunii organizaţionale la nivel logic şi a celei tehnice la nivel fizic. www. Subansamblu reprezentativ (SREP) este soluţia oferită de metoda MERISE pentru a concilia aceste două nuanţe contradictorii. realizarea şi punerea în lucru. Subansamblu reprezentativ presupune cu necesitate un studiu prealabil. În cadrul metodei MERISE. MERISE ţine cont în aceeaşi măsură de date şi de prelucrări. • MERISE viziune globală asupra unui subansamblu reprezentativ. • MERISE din perspectiva externă.fr 54 . Nivelele de abstracţie sunt ierarhizate pornind de la situaţia conceptuală sau fizică până la cea organizaţională sau logică. sunt deseori contradictorii. Această „reconciliere” dintre date şi prelucrări se face prin intermediul modelelor externe24. Faţă de alte metode care tratează în mod privilegiat datele sau prelucrările. Datele sunt elementele stabile într-o organizaţie fiind luate în calcul într-o „optică statică” iar prelucrările sunt întotdeauna dinamice şi sunt reprezentate în MERISE prin instrumentele de sincronizare. studiu detaliat.univ-mrs. 24 25 Reix R. – Systemes d’information et management des organisations.• MERISE perspectivă paralelă date–prelucrări. În majoritatea cazurilor vederea de ansamblu poate considera un domeniu ca fiind cel mai important. Această viziune permite fixarea opţiunii gestiunii la nivel conceptual. Există în cadrul metodei nivele de abstracţie care corespund domeniilor de preocupare şi care. la rândul lor. • MERISE perspectivă orientată pe nivele. determină viziuni descriptive. Grija de a nu lungi prea mult studiul domeniul respectiv şi pretenţia acestui studiu de fi exhaustiv. Demersul metodei este în concordanţă cu definiţia acestui cuvânt din zona de provenienţă a metodei (Larousse–Franţa) care semnifică: „O manieră de a conduce un raţionament. Abordare date–prelucrări se simte la moment dat de la debutul proiectului evidenţiind obligaţia verificări coerenţei dintre date şi prelucrări. O etapă poate fi la rândul ei descompusă în subetape fiecare terminându-se cu luarea unei decizii apărând vizibilă o selecţie a posibilităţilor. de a progresa spre un scop”25. există o descompunere în etape precum: studiul prealabil.cmi.

Figura 2. STUDIU Studiu prealabil Studiu FUNCŢIUNI Studiu situaţiei actuale REZULTAT DECIZIA după studiu o Dosar de opţiuni conţinând Decizia Degajarea unui mijloacele de punere în pentru soluţie lucru subansamblu reprezentativ Studierea detaliată a Specificaţii 55 funcţionale Acordul .Demersul metodei se poate reprezenta sintetic astfel: Ce trebuie făcut? – Cum se face? Etape Subetape (Legături. Sub formă tabelară prezint etapele acestei metodei sintetizând rezultatele fiecărui stadiu. interne şi fundamentale. Reguli) (Participanţi) Cu cine se face? - În figura 2.8 am reprezentat cerinţele la care răspunde metoda MERISE constatând interdependenţele externe.8 MERISE – Ce-cum-cu cine se realizează? Realizarea studiului prealabil şi a celui de detaliu nu presupun neapărat crearea de elemente noi. singurele eforturi fiind acelea de a adapta metodele de realizare deja folosite la etapele propuse.

tehnice şi restricţii financiare definite înainte de studiul prealabil. Punerea în Studiul de ansamblu al lucru problemelor legate de utilizarea noilor funcţiuni automate În momentul descompunerii subansamblul reprezentativ (SREP) pe subproiecte apare evidentă soluţia chiar înainte de a se studia adecvarea „specificaţiilor funcţionale pentru nevoile utilizatorilor” cu compatibilitatea „întregului” alcătuit din specificaţii funcţionale.9 reprezint iniţierea şi derularea paşilor care privesc studiul prealabil.9 Studiu prealabil în cadrul metodei Merise Metoda MERISE în contextul unei unităţi bancare pentru un subansamblu reprezentativ pune în evidenţă unul sau mai multe subproiecte care vor intra sub incidenţa studiului prealabil. În cadrul studiului prealabil se pot distinge mai multe subetape26: » iniţializare. În figura 2.STUDIU detaliat Realizarea FUNCŢIUNI REZULTAT generale diferitelor domenii pentru „externe” soluţia reţinută detaliate Studiul tehnic Realizarea programelor DECIZIA după studiu şi utilizatorilor Sistem de criterii de piaţă Recepţia privind „jocul” de probă al provizorie utilizatorilor Sistem implantat în Recepţia ambientul real şi definitivă funcţionând în regim normal.html 56 . Figura 2.uk/simt/im251/eumeths.ac.unl. 26 Euromethod. www.

situaţie în care nu apare contextul informatic. cu ce şi când?“ din punct de vedere 57 .» » » » » studiul existent. Instrumentele specifice MERISE sunt utilizate pentru reprezentarea sistemelor informaţionale şi a diferitelor nivele de modele de date şi prelucrări după cum se deduce din sinteza supusă atenţiei în continuare: Alegere Ce se GESTIUNE doreşte să se facă în fond Obiect descris Date Nivel de abstracţie CONCEPTUAL Exemplu de modele MODELUL CONCEPTUAL AL DATELOR Cine face Cu ce şi Când Relaţii Reguli de gestiune Înlănţuiri de prelucrări ORGANIZAŢIONAL Oameni Maşini Reţele diferite Repartiţie geografică Entităţi Programe Proceduri (invariant static) MODELUL CONCEPTUAL AL PRELUCRĂRILOR (invariant dinamic) LOGIC SAU ORGANIZAŢIONAL MODELUL LOGIC DE DATE MODELUL LOGIC DE PRELUCRARE Cum face se TEHNIC FIZIC SAU OPERAŢIONAL MODELUL FIZIC AL DATELOR MODELUL FIZIC AL PRELUCRĂRILOR Pot concluziona că la întrebarea „cum se face?” din punct de vedere tehnic prin modelul fizic al datelor. concluziile studiului prealabil. La întrebarea „cine. În metoda MERISE se regăsesc instrumente generale (interviul. concepţia. Metoda se utilizează pentru toate proiectele de organizare a unui domeniu de activitate chiar dacă nu conţin elemente de informatizare. ancheta) cât şi proprii (formalizări individuale şi ale prelucrărilor). modelul fizic al prelucrărilor pot răspunde prin entităţi programe proceduri. Se poate constitui într-un instrument al metodei orice mijloc „care permite să se execute un lucru: o muncă. organizarea punerii în lucru. bilanţul cantitativ şi calitativ. o operaţie” (Larousse).

relaţiile. modelele rezultate.maşină .Traducerea în SGBD Corelând figura 2. 58 . deduc şi prezint următoarele expresii: Viziunea exterioară: model extern=o vedere a unui utilizator = Ansamblul informaţiilor operaţionale pentru o prelucrare FORMALISM = Model individual Conceptele adecvate pentru fiecare nivel al modelării datelor şi prelucrărilor sunt caracterizate printr-un grad mare de generalitate.Concepte fundamentale .Integrarea alegerii opţiunii .Relaţii semantice LOGIC Modelul logic de date MLD Integrarea organizare entitate relaţie instanţă (realizare) FIZIC Modelul fizic al datelor MFD Descrierea bazelor de date Noţiuni de înregistrare Modelul fizic al prelucrărilor MFP Descrierea programelor Descrierea procedurilor restricţiilor MCP . regulile de gestiune.Descrierea macroscopică (noţiunea de proces) Modelul logic al prelucrărilor MLP de .Timp real – timp diferit Desfacerea proceselor Faze sarcini proceduri PRELUCRĂRI Modelul conceptual al prelucrărilor .organizaţional răspunde modelul logic al datelor şi cel al prelucrărilor.Repartiţia om .8 referitoare la „Merise Ce-cum-cu cine se realizează?”. DATE CONCEPTUAL Modelul conceptual al datelor MCD . nivelurile de abstracţie. La interogarea „ce se doreşte a se realiza?” datele. În continuare supun atenţiei sintetiza nivelelor de abstractizare corelate cu ansamblul date-prelucrări. dar în acelaşi timp şi de relevanţă surprinzând aspecte semnificative din realitatea supusă modelării. înlănţuirile de prelucrări apar ca răspuns dedus din modelul conceptual al datelor şi al prelucrărilor.

Modelul conceptual al datelor este un ansamblu de concepte şi reguli de combinare care permit reprezentarea realităţii circumscrise domeniului supus informatizării. Pentru definirea modelului conceptual al datelor se apelează la modele intermediare care sunt folosite ca suport al unei metodologii de proiectare. . Inspirat din reţelele Petri. aceste relaţii trebuie să fie pertinente în raport de sistemul informatic studiat. . Modelul conceptual utilizează o abstractizare prin relaţie.identificatorul permite modelarea unui ansamblu de obiecte concrete sau abstracte. . modelul conceptual al prelucrărilor (MCP) are menirea ca în funcţie de domeniul investigat să răspundă la întrebarea: Ce prelucrări se realizează? Fluxurile. Evenimentele şi rezultatele pot fi externe sau interne. Elementele din acest ansamblu sunt ocurente.relaţia între mai mulţi indivizi este un ansamblu de produse carteziene de ocurenţă a acestora. manager”. 28 ani. Regulile de pertinenţă.proprietatea este o modelare a informaţiei elementare. de verificare şi omogenitate conduc la modelizarea termenilor identificării. Cele externe provin sau sunt destinate unui actor extern. De exemplu produsul cartezian vânzător * client reprezentat prin toate cuplurile vânzător/client. de exemplu în cazul salariatului ocurenţa este exprimată astfel: „Georgescu. recunoscută de ISO fiind o apropiere de modelul entitate-relaţie. receptorii (stimulii) şi emiţătorii (reacţii) prin domeniu sunt modelări ale evenimentelor şi rezultatelor. de evidenţiere. de identificare. percepute ca fiind pertinente pentru sistemul informatic studiat.cardinalitatea reprezintă cuplul entitate–relaţie. contabil. În spatele cardinalităţilor se găsesc reguli de gestiune reale. va fi modelat prin ansamblul de legături care exprimă aceeaşi natură între mai mulţi indivizi. Bineînţeles. iar cele interne rămân în 59 . de exemplu funcţia exercitată de un salariat: vânzător. de exemplu identificatorul salariatului sau identificatorul produsului. informatician etc. Mai multe concepte de bază caracterizează acest model: .

Operaţia descrie comportamentul domeniului la declanşarea produsă prin mai multe evenimente. Un mesaj este trecerea de informaţii între domenii sau între un partener (factorul extern) al întreprinderii şi un domeniu. în retur rezultate în funcţie de condiţiile traduse prin expresii logice. reprezentând materializarea sub formă de acţiuni a regulilor de gestiune specifice activităţii întreprinderii. Asocierea MCP ↔ eveniment indică faptul că ceva anume s-a întâmplat şi în consecinţă sistemul trebuie să reacţioneze. numite domenii. Domeniile privesc marile funcţiuni sau procese majore din întreprindere. Modelul conceptual de comunicaţie (MCC) are drept scop reprezentarea fluxurilor de informaţii sau mesaje între diferitele subsisteme omogene ale întreprinderii. Regulile de sintaxă şi de funcţionare permit verificarea coerenţei MCP. Prelucrările reprezintă partea dinamică a sistemului informaţional. înlăturând posibilitatea de generare a evenimentelor intermediare între acţiunile ce aparţin operaţiei. urmărind satisfacerea sistemului de pilotaj. În reprezentarea acestei înlănţuiri de operaţii şi evenimente declanşatoare în cadrul modelului. MCP urmăreşte reprezentarea înlănţuirii operaţiilor cu definirea condiţiilor necesare pentru declanşare dar şi consecinţele derulării operaţiilor respective.domeniu pentru a asigura continuitatea procesului. Operaţia emite. emiţător) şi recepţionat de alt element structural (receptorul). Mesajul este emis de o parte (partener sau domeniu. . Sincronizarea se traduce prin expresii logice.sincronizarea reprezintă o condiţie prealabilă a unui flux de operaţii în care mai multe evenimente participă la declanşare. 60 . se impune respectarea unor cerinţe determinate de regulile de gestiune. Ea este o secvenţă continuă de acţiuni elementare producătoare de evenimente care se execută neîntrerupt din momentul declanşării acesteia de către unul sau mai multe evenimente. Ele descriu acţiunile exercitate asupra datelor cu scopul obţinerii informaţiilor dorite. Operaţia constituie un bloc de prelucrare cuprinzând acţiuni elementare generatoare de evenimente interne.

hw.cee.Caracterizarea sarcinilor: posturile raportate.Construcţia modelelor organizaţionale 27 reprezintă o etapă delicată şi deseori complexă datorită varietăţii şi interacţiunii parametrilor de luat în consideraţie: organizarea intrărilor. „date”.Securitate Problematica MOD Modelarea priveşte sistemul de informaţii organizaţional care se finalizează prin confruntarea modelelor.Repartizarea prelucrărilor pe centre. gradul de automatizare. Continuarea studiului presupune modelarea sistemului şi se 27 28 Nextobjects is based on the Merise Method. frecvenţa.10 Traseul „sarcini-prelucrări”. unităţi şi posturi de lucru . www.Volumetrie . machetare şi validarea MCD – modele externe. În figura 2. tehnice). sociale. „date” şi „mesaje”. durata.ac.net Information Systems Group UG2. unităţi şi mesaje între centre posturi de lucru . mesaje” Problematica modelului organizaţional este sintetizată în tabelul următor: Problematica MOP . Totodată poate fi considerată ca o etapă accesibilă. www.uk/ism/ug2/ass3 61 .Istoric . abordarea printr-o grilă de coerenţă MCD – MOP – MOD. aplicând următoarele tehnici: abordarea participativă. criterii de evaluare (economice. termenul de răspuns. ergonomice. regulile şi procedurile aplicabile.nextobjects. deoarece nu apar dificultăţi induse de abstractizare. varietatea soluţiilor organizaţionale posibile.Repartizarea datelor: . capacitatea Problematica MOC . Figura 2. Modelele externe28 privesc datele drept mesajele legate la evenimente–rezultate.10 vă supun atenţiei reprezentarea cumulată a MOP-MOD-MOC care încearcă să evidenţieze circuitul „sarcini-prelucrări”.sourceforge. modul de funcţionare.Schimburile de pe centre.

afirm că utilizarea metodei MERISE în contextul cadrului metodologic al conducerii proiectelor informatice este oportună deoarece: • • determină limitele nivelelor de preocupare (conceptual. comunicaţiei. 2.Repartizarea prelucrărilor informatizate: centre. Se poate afirma că este o metodă „deschisă”. Problematica MLP şi al MFP Problematica MLD şi al MFD . logic. În cele ce urmează supun atenţiei sinteza reunirii modelelor logice şi fizice ale datelor.Optimizarea Concluzionând ideile prezentate pe parcursul acestui subcapitol. • propune un plan de lucru detaliat pentru derularea fiecărei etape pentru a facilita conducerea proiectelor în concepţia sistemelor informatice. unităţi logice de prelucrare. fizic).2.Transformare MOD .surprind în acest moment delimitările de modele care apar utilizând percepţia de gestionare (modele organizaţionale) şi viziunea specialistului informatic (modelele logice şi fizice). susceptibilă să se integreze într-un cadru metodologic mai larg.Dimensiunea MLD . Metoda OMT de proiectare a sistemelor informatice OMT – Object Modeling Tehnique – este bazată pe modele ca abstracţii ale problemelor din lumea reală.Mesaje între centre prin magistrale după tipul SGBD informatice . care urmăresc focalizarea aspectelor importante ale 62 .Modularizare Problematica MLC şi al MFC .2. • furnizează documentele tip ISO pentru constituirea documentaţiei aferente fiecărei etape. permite exprimarea unor concepte complementare legate de conducerea studiilor detaliate. prelucrărilor. .

Comparativ cu metodele tradiţionale. CLOS (Common Lisp Object System). spre deosebire de modelarea datelor separată de a funcţiilor. În fapt. abordarea orientată-obiect mută centrul de greutate al soluţionării problemei în faza de analiză.com Ayache R. Obiectul reprezintă o entitate (reală sau abstractă) a lumii supuse modelării. . Această metodă are în vedere trei aspecte importante: • abstractizarea realităţii. ceea ce înseamnă că pentru aceeaşi problemă se pot crea mai multe modele care să focalizeze diferite aspecte. Metodele orientate obiect propun modelarea concomitentă a datelor şi a funcţiilor obţinând ierarhii de clase de obiecte care înglobează atât datele cât şi comportamentul. N.The management control function. caracterizată prin identitate. Un sistem informatic este privit ca un ansamblu de obiecte care cooperează între ele şi tratează obiectele ca instanţe ale unei clase în interiorul unei ierarhii. Boston: the Harvard Business School Press 63 . caracterizat prin structură. 29 30 Rational whitepaper. O bună înţelegere a cerinţelor problemei reale va conduce la construirea unui model fiabil. Noţiunea de „obiect” 29 este dependentă de implementarea metodei în limbajele de nivel înalt cum ar fi: ADA. fapt compensat printr-un minim de efort necesar a fi depus în faza de implementare. element structural al metodelor tradiţionale. www. MODULA. Metodele obiect integrează modelarea de structură cu cea comportament30. stare şi comportament. adaptabil. Această metodă a fost creată de James Rumbaugh şi este cea mai cunoscută şi utilizată metodă de proiectare orientată obiect (POO).rational. obiectul reprezintă un element identificabil. comunicarea între membrii echipei de analiză-proiectare şi între utilizatori. SMALLTALK. atributele şi metode proprii. C++. • • scopul modelului este să se focalizeze ceva cunoscut. concret sau abstract.problemei şi omisiunea celor irelevante. care suportă uşor modificările ulterioare.

Fiecare model în OMT poate fi reprezentat prin diagrame distincte32: Rumbaugh's Method. interacţiuni. Metoda OMT. • reutilizarea componentelor soft existente. dinamic şi funcţional pentru scopuri şi descrieri diferite de obiecte. Supun atenţiei câteva dintre avantajele acestei abordări: • software-ul este asamblat (construit) din componente care au o calitate probată în implementările anterioare.Corespunzător metodologiei31 se parcurg următorii paşi: • • definirea problemei. 1. .html Castellani X. OMT propune trei tipuri de modele. Cele trei tipuri de modele sunt de fapt proiecţii ale unei singure informaţii. L’ingénierie des besoins. operaţiilor asupra obiectelor. Masson 32 31 64 . • formalizarea strategiei prin identificarea obiectelor şi atributelor. transformări. rezultând că software-ul construit modular poate fi modificat şi dezvoltat cu eforturi minime.Méthodologie générale d’analyse et de conception des systèmes d’objects. Această metodă de proiectare susţine strategia prototipizări de structurare a procesului de realizare a produselor informatice.iconixsw. stabilirea instanţelor şi implementarea operaţiilor. tehnologie care asigură realizarea de aplicaţii într-un timp scurt şi la costuri reduse.com/Rumbaugh. fiecare prezentând un anumit specific. www. elaborarea unei modalităţi informale de identificare a datelor şi a funcţiilor relevante corespunzătoare problemei. Existenţa şi necesitatea acestor modele solicită şi realizează o strânsă conexiune între ele. obiect. • obiectele individuale pot fi modificate fără a le afecta pe celelalte. 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.

Modelul „în cascadă”. 65 . iar flexibilitatea modelelor orientate–obiect permite armonizarea cerinţelor utilizatorului cu soluţiile propuse de echipa de realizatori. chiar în varianta care cuprinde iterarea fazelor. dar flexibilitatea metodelor orientate-obiect permite lucrul într-un ciclu de viaţă „spirală”. • pentru modelul funcţional se apelează la DFD (Diagrama de Flux de Date Data Flow Diagram). Aceasta înseamnă că versiunii parţiale ale sistemului pot fi livrate în timp scurt. proiectantul realizând extrem de rapid analiza pentru completarea modelelor. permite detectarea şi corectarea erorilor înainte de trecerea la faza următoare şi impune ca în fiecare fază să se producă un document şi produse valide.• pentru modelul de obiecte – CAD (Class Association Diagram sau DAC Diagrama de Asociere a Claselor).MGD Message Generalization Diagram). presupune faptul că doar o parte a modelului trebuie să fie finalizat înainte de a trece la faza următoare. În reprezentarea ciclului de viaţă al unui proiect se utilizează mai multe modele. aducând importante prejudicii prin faptul că utilizatorul trebuie să aştepte până la sfârşitul implementării pentru a vedea dacă sistemul corespunde necesităţilor exprimate. • pentru modelul dinamic – ETD (Event Trace Diagram sau DTE Diagrama de Trasare a Evenimentelor). DGM (Diagrama de Generalizare a Mesajelor . specific metodelor structurate. Feed-back-ul permite găsirea de soluţii convenabile. evaluate şi validate de către utilizator. CCD Class Comunication Diagram). efort). Ciclul de viaţă spirală sau modelul spirală. Corectarea erorilor în fazele următoare celei în care s-au produs este foarte costisitoare (timp. DCC (Diagrama de Comunicare a Claselor. spre deosebire de modelul în cascadă. precum şi STD (State Transition Diagram) sau DTS (Diagrama de Tranziţie a Stărilor).

2. Figura 2. Finalizarea etapei analiză-modelare (figura 2. Analiza are drept obiectiv modelarea problemei din lumea reală sau definirea Domeniului Aplicaţiei (Application Domain).1. În figura 2.2.12) se materializează prin definirea unui model precis.11 am reprezentat o secvenţă a activităţi analizei şi modelării evenimentului studiat. 66 . 11 Circuitul analiză-modelare evenimente Modelul de analiză trebuie înţeles şi validat de utilizator. modelul obiectual. dar apar şi elemente specifice. Această etapă are ca rezultat formularea problemei. realizării conexiunii beneficiar-producător bazată pe înţelegere. Analiza este utilă clarificării cerinţelor. reprezentând în acelaşi timp cadrul pentru proiectarea ulterioară şi implementare.2. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect Etapele ciclului de realizare în abordarea orientată – obiect sunt în mare parte comune cu viziunea Merise. concis. inteligent şi corect al viitorului sistem. modelul dinamic şi cel funcţional. Proiectantul creează modele de obiecte şi funcţii fără a lua în considerare aspectele de implementare.

1. Analiza şi modelarea evenimentelor Scrierea declaraţiei 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. Definirea modelului Diagrama de Tranziţie a Modelul dinamic (DTS) pentru clase dinamic Stărilor (DTS) importante şi modelul de obiecte care încorporează rezultate din DTS Definirea modelului Diagrama de Flux de Modelul funcţional cu funcţional Date (DFD) funcţionalitatea operaţiilor complexe şi completarea lor în DAC Reiterarea şi Verificări Se completează modelul de obiecte verificarea din celelalte iteraţii şi se verifică consistenţa 67 . Construirea modelului de analiză Definirea modelului Diagrama de Asociere a Model de obiecte cu clasele obiectual Claselor (DAC) aplicaţiei atributele.2. operaţiile şi asocierile lor.Figura 2. 12 Obţinerea modelului de analiză O reprezentare sintetică a activităţilor şi rezultatelor este supusă atenţiei în tabelul următor: Faze şi activităţi Mod de reprezentare Descriere Declaraţia problemei (de către client sau elaborator) Scenarii de evenimente pentru evenimentele complexe ale aplicaţiei Diagrama de Comunicare între Clase cu mesaje şi interacţiunile dintre clase Diagrama de Generalizare a Mesajelor specifică interacţiunii între clase A.

Se creează aşa numitele clase container organizate pe sistem. Proiectarea de sistem presupune două mari faze şi anume: construirea arhitecturii sistemului. Suma acestora reprezintă soluţia generală de organizare. uşor de înţeles şi construieşte arhitectura sistemului prin identificarea subsistemelor şi transpunerea lor pe hardware-ul disponibil. Scopul acestei etape este transpunerea declaraţiei problemei aşa cum a fost definită în etapa de analiză într-o arhitectură adecvată. interfaţa grafică de conexiune cu utilizatorul. Se poate spune că. rafinarea şi extinderea celor trei modele până la nivelul de detaliu care să permită implementarea. până la etapa de proiectare obiectuală care să permită implementarea propriu-zisă. bazată pe divizarea în subsisteme precum şi decizii de implementare la nivel global. În a doua fază se modelează în detaliu fiecare sistem individual. În faza de construire a arhitecturii sistemului se dezvoltă aşa numitele clase de bază. optimizează şi extinde cele trei modele preluate din etapa de analiză. Rezultatul este un concept de implementare care rafinează. modelarea detaliilor subsistemelor. Sintetizarea fazelor şi activităţilor etapei de proiectare de sistem este relevată de tabelul de mai jos: 68 . Proiectarea de sistem porneşte de la domeniul aplicaţiei şi ia în considerare conceptele de implementare adică optimizarea. Rezultatul acestei etape este realizarea arhitecturii de bază a sistemului şi adoptarea deciziilor privind strategia la nivel global. analiza descrie problema iar proiectarea de sistem descrie soluţia. clasele de acces la bazele de date.Proiectarea de sistem – împarte modelul de analiză în părţi mai mici. pe seama cărora se studiază funcţionalitatea sistemului şi se decide privitor la configuraţia sistemului hardware-software. sistemul de gestiune al bazelor de date. accentul pus pe diferitele modele fiind diferit de la un tip de sistem la altul. Soluţia de sistem proiectată va include pe lângă clasele de bază şi clasele de interfeţe grafice.

8.1. Identificarea obiectelor Text active concurente şi exclusive 1. Definirea interfeţelor Text DGM DCC Faze şi activităţi Descriere Se utilizează din etapa de analiză DCC şi DAC Se stabileşte arhitectura sistemului În DAC din etapa de analiză.3. Modelarea detaliilor de subsistem 2.5. proiectându-se algoritmi şi implementându-se asocierile. Completarea modelului de comunicare a claselor la nivel de proiect cu mesajele compuse nou definite Identificarea obiectelor care sunt active în acelaşi timp şi a celor care au un comportament exclusiv Se alocă subsistemele la procesoare. 1.Modalităţi de reprezentare 1.2. actorii vor fi înlocuiţi cu subiecţi. fişierele sau bazele de date corespunzătoare Identifică resursele globale şi determină mecanismele pentru controlarea accesului 1.1 Definirea modelului de DCC comunicare a claselor 2.6 Identificarea resurselor Text globale şi determinarea mecanismelor pentru asigurarea accesului la date. Alegerea variantei de Text implementare a controlului 1. 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 acelaşi nume. 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. Alocarea Text subsistemelor pe procesoare şi task-uri Text 1. Stabilire priorităţi 2. Stabilirea condiţiilor Text limită 1. Alegerea strategiei de bază pentru implementarea datelor memorate 1. 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ă.4. astfel încât să asigure satisfacerea cerinţelor de performanţă şi minimizarea comunicării Se aleg structurile de date.2. Se realizează 69 .9.7. Construirea arhitecturii sistemului 1.

Deciziile de proiectare luate trebuie susţinute de o documentaţie adecvată care alcătuieşte o extensie a cerinţelor de documentaţie realizate în etapa de analiză. Structura de control a programului derivă din acest model. Rezultatul final al acestei etape îl constituie modelul obiectual. atributele şi asocierile sunt implementate în structuri de date specifice. http://citeseer. Scopul etapei este de a adăuga la modelul obiectual rezultat al etapelor de analiză şi proiectare de sistem. Când se trece la etapa de implementare prin generare automată de cod.nj. diferenţa constând în faptul că acum clasele sunt descrise din punct de vedere al implementării33. fie implicit (alegând algoritmii care realizează operaţiile în ordinea specificată de modelul dinamic). 33 Object-Oriented Development Interactive Systems. una din activităţile etapei de proiectare obiectuală Plecând de la aceste obiective în etapa de proiectare obiectuală operaţiile identificate în etapa de analiză sunt transpuse în algoritmi iar clasele. • modelul funcţional va descrie operaţiile pe care proiectantul trebuie să le implementeze. care recunoaşte evenimentele şi le transformă în apeluri de proceduri). Astfel: • modelul obiectelor determinat în etapa de analiză va fi acum rafinat prin introducerea de noi clase (care păstrează rezultatele intermediare ale calculului). detaliile de implementare necesare fie pentru generarea automată de cod. fie pentru dezvoltarea ulterior fără generare automată.htm 70 .nec. În urma acestei etape se obţin: modelul obiectual detaliat. atunci modelul obiect este singurul utilizat. modelul dinamic detaliat şi modelul funcţional detaliat. Modelele utilizate sunt identice cu cele din etapa de analiză.com/aalto94objectoriented. operaţii (descoperite abia acum) şi atribute.gruparea claselor în superclase pentru uşurarea implementării şi pentru îmbunătăţirea performanţelor. În timpul proiectării acesta va alege algoritmii de implementare a unei operaţii şi va descompune operaţiile mai complexe în operaţii mai simple. Fluxul de control din cadrul unui program trebuie realizat fie explicit (printr-un planificator intern. modelul dinamic şi modelul funcţional rafinate şi detaliate. • modelul dinamic descrie felul în care sistemul răspunde stimulilor externi.

Nume_Clasă NumeAtribut[:tip=valoare_implicită] Obiectele se diferenţiază între ele prin valorile atributelor la un moment dat. pentru o aplicaţie de evidenţă a facturilor pentru fiecare document utilizat se defineşte un obiect care conţine caracteristicile facturii relevante pentru aplicaţia informatică. NumeClasa /Nume atribut $Nume_atribut .. O categorie specială de atribute sunt cele ale clasei. 2. De exemplu.2. fiind menţionat numele atributului şi opţional tipul său şi o valoare implicită. apoi în etapa de proiectare (de sistem obiectuală) când sunt detaliate şi completate şi până la implementarea de cod. 71 . În OMT atributele sunt reprezentate sub numele clasei. Un atribut al clasei. simbolizat prin „$” are o valoare comună clasei de obiecte şi nu unei instanţe specifice.2.Se poate concluziona că deciziile de proiectare trebuie documentate pornind de la modelul de analiză. care constituie starea obiectului în acel moment. Modelul obiect în metodologia OMT Cele trei tipuri de modele recomandate de OMT sunt utilizate începând din etapa de analiză când se realizează o prima versiune a acestora.. În acest scop se vor folosi construcţii specifice de implementare: pointeri (pentru modelul obiectual) pseudocod structurat (pentru modelul dinamic) şi expresii funcţionale (pentru modelul funcţional).. prin adăugarea de detalii modelelor obiectual. dinamic şi funcţional. Simbolul utilizat în metodologia OMT pentru reprezentarea unei clase de obiecte este: Nume_Clasă Atribute Operaţii Numele clasei trebuie să fie sugestiv în contextul aplicaţiei şi să identifice clasa în mod unic.2.

Atributul unei clase va descrie o proprietate comună a tuturor obiectelor din clasă şi nu proprietatea unei clase instanţe. O aceeaşi operaţie poate fi implementată în mod variat în clase diferite.. El apare ca atribut al obiectelor din clasă având pentru fiecare aceeaşi valoare.. lista de argumente şi tipul returnat). O operaţie este recunoscută după semnătura sa (numele.. O categorie aparte de atribute sunt cele derivate a căror valoare se calculează. sub partea destinată atributelor. Această proprietate se numeşte polimorfism. O modificare a unui obiect al unei clase acţionează asupra stării obiectului prin transformarea/consultarea acesteia. Dacă operaţia poate fi accesată din afara clasei semnătura acesteia este publică spre deosebire de implementare care nu are acest caracter. reprezentate prin caracterul „/” plasat în faţa numelui.. urmat opţional de parametrii şi de tipul rezultatului returnat. Fiecare operaţie care se aplică unui anumit obiect devine parametru implicit.. NumeAtribut_m:tip_m=valoare_implicită_m NumeOperaţie_1(lista_argumente_1):tip_rezultat_1 NumeOperaţie_2(lista_argumente_2):tip_rezultat_2 . Toate aceste elemente sunt trecute în partea inferioară a simbolului clasei. De exemplu clasa „Comandă_marfă” are operaţia „Emite”. care va fi implementată în mod diferit faţă aceeaşi operaţie care aparţine clasei „Factură”. NumeOperaţie_n(lista_argumente_n):tip_rezultat_n 72 . asupra altui obiect aparţinător clasei sau asupra obiectelor incluse altei clase. NumeOperaţie(lista_argumente):tip_rezultat $Numeoperaţie O operaţie este o funcţie sau o transformare aplicată obiectelor unei clase. Implementarea operaţiilor unei clase se numeşte metodă. Operaţia clasei utilizează simbolul „$” în faţa numelui şi are forma generală: NumeClasă NumeAtribut_1:tip_1=valoare_implicită_1 NumeAtribut_2:tip_2=valoare_implicită_2 .. Reprezentarea operaţiilor unei clase se face prin specificarea numelui operaţiei. NumeClasă .

13 Forma generală de reprezentare a unei asocieri modelate ca o clasă Atunci când legăturile devin subiecţi ai unor operaţii apare asocierea modelată ca o clasă. Asocierea claselor se realizează printr-un verb înscris deasupra liniei de conectare. Este indicat să se modeleze asocierile dintre clase şi nu legăturile dintre obiectele acestora. motivat prin faptul că obiectele reprezintă instanţe ale asocierii claselor. „unu la unu sau mai mulţi”.14 care exemplifică asocierea modelată ca o clasă. Nume_client preluate. 73 . identificată prin reprezentarea: Figura 2. În cazul în care se apelează la reprezentarea cu trei regiuni se menţionează numele clasei. atributele şi operaţiile clasei. În cazul în care se realizează asocierea între „Client”-„Bancă” apare evidentă asocierea „Împrumut” modelată ca o clasă având în structură atributele Nume_bancă. apare „Suma_împrumutat” care nu aparţine clasei „Client” şi nici „Bancă”. „unu la zero sau unu”.caracteristică a asocierii. Multiplicitatea poate fi: „unu la unu”. „unu la zero sau mai mulţi”.reprezintă numărul de instanţe ale unei clase care poate avea legături cu o instanţa a altei clase asociată. În figura 2.Conform metodologiei OMT pentru reprezentarea grafică a unei clase se utilizează o formă dreptunghiulară având una sau trei regiuni. Deoarece obiectele sunt abstractizate în clase atunci legăturile vor consta în asocieri. Există situaţii în care este necesar ca o asociere să fie modelată drept clasă. Reprezentarea cu o singură regiune conţine doar numele clasei. Corespunzător unei asocieri apare o valoare ataşată fiecărei legăturii. Spre exemplificare clasele „Factură” şi „Furnizor” vor fi conectate prin intermediul asocierii „Emisă_de” care indică şi sensul acesteia: Factură Emisă_de Furnizor Multiplicitatea .

15 Asociere „Client”-„Bancă”-„Investiţie” Se observă că asocierea „Împrumută” nu poate fi divizată fără pierderi de informaţii între clase. Presupunând intervenţia clasei „Investiţie”. 14 Asociere „Împrumut” modelată ca o clasă Operaţiile efectuate de „Împrumut” sunt de restituire sau amânare.15 se sintetizează acordarea împrumutului de către bancă unui client pentru anumite investiţii. Nume de rol reprezintă un concept prin care se identifică capetele unei asocieri. Un calificator distinge seturile de 74 . Figura 2. cu siguranţă că va avea roluri diferite faţă de fiecare dintre acestea. utilajul achiziţionat de o societate reprezintă pentru ea un mijloc de producţie. Pot exista şi asocieri calificate reprezentate sub forma unu–mulţi sau mulţi–mulţi la care calificatorul reduce multiplicitatea efectivă. În figura 2. Spre exemplificare. dar din punct de vedere al băncii care acordă creditul constituie o garanţie. În cazul în care o clasă are mai mult de o asociere.Figura 2. apare evidentă asocierea ternară „Împrumută”.

geocities. Moştenirea în OMT este un mecanism care dă posibilitatea partajării atributelor şi operaţiilor utilizând relaţia de generalizare. cu o acţiune opusă celui de generalizare. standardizarea reprezentată prin specificarea unică a aspectelor comune şi obţinerea unei calităţi superioare a proiectului deoarece reutilizarea aduce avantajele oferite de testarea anterioară. Avantajele utilizării generalizării sunt: reutilizarea claselor create în cadrul altor proiecte. Clasele constituite special pentru a fi moştenite se numesc abstracte fiind lipsite de instanţe şi conţinând cel puţin o operaţie abstractă care va fi transmisă claselor descendente. Opusă generalizării apare specializarea claselor care are ca punct de plecare superclasa adăugând noi atribute relevante numai pentru anumite obiecte din clasă. creând astfel subclasele.obiecte de la capătul „mulţi” al unei asocieri.16 am realizat reprezentarea generală a moştenirii. observându-se că intervine şi mecanismul de specializare descendent. Se utilizează termenul de superclasă . Atributele şi operaţiile superclasei nu mai apar în cadrul subclaselor ataşate. subclasă cu elementele specifice operaţii şi atribute. Asocierea calificativă este exprimată sub forma: Nume_clasă1 Calificator Nume_clasă2 Generalizarea 34 sub OMT presupune identificarea atributelor şi/sau a operaţiilor comune claselor şi crearea superclase. clasă.htm 75 . Influenţa generalizării apare evidentă prin preluarea atributelor şi operaţiilor elementare intersectate obţinându-se atribute şi operaţii comune. În cazul în care o clasă este construită pentru a avea instanţe apare noţiunea clasă concretă.com/siliconvalley/9219/resume. În clase se descriu numai atributele şi/sau operaţiile specifice fiecăreia dintre ele. Subclasele şi clasele pot fi exprimate prin relaţia părinţi/copii sau strămoşi/descendenţi. 34 Doc’s submitted to World Scientific. dar aparţin acestora prin moştenire. www. Moştenirea poate fi ierarhizată pe mai multe nivele. În figura 2.

(figura 2. 76 . 16 Reprezentarea generală a „moştenirii” Reprezentare modelului de obiecte se exprimă prin Diagrama de Asociere a Claselor (DAC) ale cărei noduri sunt clasele de obiecte iar legăturile între clasele de obiecte sunt reprezentate prin asocieri. comenzilor şi a stocurilor Este evidentă agregarea client_cash client_virament în superclasa „client” care execută operaţia „Achită”.Figura 2. Pot prezenta spre exemplificare.17) diagrama de asociere între clase pentru „problema” de urmărire a clienţilor. Figura 2. comenzilor şi stocurilor. Agregarea este un tip special de asociere între clasa „întreg” şi una sau mai multe clase „parte”. 17 Monitorizarea simultană a clienţilor.

„citeşte client”. Utilizând spre exemplificare (figura 2. Evenimentul reprezintă o situaţie de moment care precede sau succede logic unui alt eveniment. până la „cost total al comenzii” se reprezintă DTE aferentă aplicaţiei Clienţi. Interpretarea DTE se produce de la bază spre partea superioară şi de la stânga la dreapta. pe lângă acesta se mai pot modela mai multe scenarii alternative. Pentru un eveniment al aplicaţiei se poate modela un singur scenariu. Figura 2. Scenariul este secvenţă care include evenimentele care apar în timpul execuţiei sistemului. tranziţie. iar dacă evenimentul aplicaţiei este complex. obiectele şi reunirea acestora în scenarii.3. Conceptele utilizate sunt: eveniment.2. scenariu. stare. Rolul diagramei este de a indica actorii. Modelul dinamic în accepţiunea metodei OMT Evidenţierea temporală a succesiunii operaţilor este redată în modelul dinamic.2. condiţie. receptoare specifice fiecărui eveniment.18) actorul „Client” şi obiectele „Comandă” până la ”Element_in_stoc” prin evenimentele „creează comanda”.2. Scenariul identifică obiectele emiţătoare. operaţie. evenimentele. Două evenimente care nu au efect unul asupra altuia sunt concurente. Evenimentele similare pot fi grupate în clase de evenimente caracterizate printr-un nume care indică structură şi un comportament comun. Reprezentarea cumulativă a secvenţei de evenimente şi obiecte se realizează prin Diagrama de Trasare a Evenimentelor (DTE). 18 DTE a aplicaţiei Clienţi 77 . numit principal.

Generalizarea permite aranjarea structurii stărilor şi evenimentelor într-o ierarhie care să permită moştenirea structurii şi a comportamentului comun. aşa cum partajează şi aceleaşi caracteristici ale claselor. de sfârşit şi eventual eveniment intermediar). Activităţile – reprezintă operaţii care necesită timp pentru a se executa şi sunt asociate unei stări care o controlează până când un eveniment o întrerupe şi se produce o tranziţie a stării. Unei stări i se asociază un element valoric al obiectului care satisface o anumită condiţie. 78 . Operaţia este ataşată stării şi tranziţiei şi descrie comportamentul unui obiect ca răspuns la eveniment.Se observă că evenimentele sunt trimise de la un obiect emiţător la un obiect receptor şi că obiectul care startează evenimentul este iniţiator. Starea este răspunsul unui obiect la un eveniment şi în acelaşi timp abstractizarea valorilor atributelor şi a legăturilor unui obiect. Diagramele de Tranziţie a Stărilor pot fi structurate pentru a descrie sisteme complexe. Condiţia este o funcţie booleană bazată pe valorile obiectului. iar arcele sunt tranziţii datorate unor evenimente. Corelând stare-tranziţie-condiţie-operaţie se obţine Diagrama de Tranziţie a Stărilor (DTS) pentru obiectele din sistem cu comportament dinamic. Toate tranziţiile din aceeaşi stare trebuie să corespundă la evenimente diferite. Toate realizările unei clase partajează aceeaşi DTS. Operaţiile pot fi de două feluri: activităţi sau acţiuni. asociată unui eveniment. Tranziţia reprezintă modificarea stării printr-un eveniment. Structurarea se face prin generalizare şi agregare. a cărei structură internă nu este interesantă (nu este modelată ca o activitate cu eveniment de început. Diagrama de Tranziţie a Stărilor este un graf în care nodurile sunt stări. validată pe o perioadă de timp dacă apare evenimentul şi dacă tranziţia este adevărată. Acţiunea este o operaţie instantanee. echivalentă cu concurenţa stărilor.

4. 20 DTS pentru clasa de obiecte „Element_în_stoc” Diagrama de Tranziţie a Stărilor poate fi privită în mod dinamic.2.2. 2. Modelul funcţional al metodei OMT Modelul funcţional are ca scop descrierea algoritmilor sistemului evidenţiind modul în care sunt obţinute ieşirile pe baza intrărilor şi a altor valori intermediare. Modalitatea grafică de reprezentare a modelului funcţional este Diagrama de Flux a Datelor (DFD). Specific acestui model se folosesc termenii: proces. descriind structura de control a sistemului şi unde stările interacţionează unele cu altele prin evenimente partajate.edu/~pbiggs/survey. 35 A Survey of OO Methods. depozit de date35.Figura 2. flux de control. 19 Forma generală a unei DTS Diagrama de Tranziţie a Stărilor pentru clasa de obiecte „element-în_stoc” este reprezentată ca în figura 2.cs. http://students.20 în care punctul iniţial îl reprezintă stocul sub nivel minim (este recomandabil a se reaproviziona) iar starea finală mesajul „cantitate insuficientă” pentru a onora comanda. actor.html 79 . flux de date. Figura 2.byu.

Diagramele de flux de date evidenţiază pe lângă fluxurile de date dintre terminatori. numit terminator ataşat intrării sau ieşirii DFD-ului Depozitul de date este materializat ca fişier ce îndeplineşte funcţia de stocare urmărind o accesare ulterioară. Operaţiile din modelul obiectual corespund evenimentelor din modelul dinamic şi funcţiilor din modelul funcţional. Modelul funcţional conectează modelul static şi dinamic afectând valorile atributelor din modelul obiect şi evidenţiind restricţiile. Modelul funcţional este format din DFD-uri. Actorul constă într-un obiect care produce sau consumă date.Procesul corespunde unei operaţii care indică „ce date de intrare sunt transformate” şi „ce date de ieşire se obţin”. ecuaţiile intrări-ieşiri. 2. 3. tabele de decizie. relaţiile între cele trei modele sunt: 1. adică din grafuri ale căror noduri sunt procesele. tabele de corespondenţă intrări-ieşiri. Fluxul de date permite conectarea proceselor la intrarea unui alt obiect sau proces. 36 N. on Asia-Pacific Design Language 80 . putând fi transmis în mai multe locuri. Actorii şi depozitele de date au comportament şi utilitate diferită. Object-Oriented Extension for Reuse of Models. Fluxul de control apare în diagrama de comunicare printr-un mesaj. pseudocod şi limbaj structurat. Operaţiile se regăsesc în: funcţiile matematice. procesele şi depozitele de date (interfaţa sistemului modelat cu mediul respectiv) şi efectul proceselor asupra datelor care afectează execuţia unui proces36. Modelul static descrie structura datelor pe care se va baza modelul dinamic şi funcţional. iar arcele fluxurile de date şi de control. Procesele din DFD trebuie implementate ca operaţii ale obiectelor. Yoshida. Modelul dinamic descrie structura de control şi evidenţiază deciziile care determină acţiuni. 6-th Conf. În concluzie. apelează funcţii şi schimbă valorile obiectelor.

Jacobson. notaţiile asociate acestora şi documentaţia necesară pentru dezvoltarea unui sistem informatic. • UML este un limbaj pentru specificarea. mai mult o artă. Rumbaugh. prin care se asigură definiţia semanticii conceptelor utilizate. Astfel la întrebarea fundamentală “Ce este programarea. acest limbaj fiind o colecţie omogenă de practici engineering utilizabile pentru modelarea şi realizarea sistemelor complexe. s-a răspuns prin primordialitatea explicită a arhitecturii sistemului. • UML nu conţine limitări impuse de metodologia/metoda de proiectare. Coad. construcţia şi documentaţia sistemelor software. sau mai mult o ştiinţă”.org/news/meetings/worksshops/presentations 81 . 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 proiectării.3 Unified Modeling Language – cale de reunire a conceptelor orientate-obiect Arhitectura sistemelor informatice complexe a fost revăzută sub incidenţa unui curent privind formalizarea unui limbaj standard de modelare datorat unor personalităţi (Meyer. implementarea fiind privită ca o activitate secundară.37) care propun structuri ale sistemului în raport cu implementarea acestuia. 37 Usige UML-based Framework. domeniul de activitate unde este utilizat sau mediul utilizat pentru dezvoltare • UML realizează unificarea conceptelor orientate-obiect sub forma unui standard de proiectare.omg. vizualizarea.2. manipulării şi vizualizarea componentelor sistemului informaţional. www. Aceste considerente au condus la apariţia unui “Limbaj unificat de modelare” denumit UML:Unified Modeling Language caracterizat prin: • UML este un limbaj “universal” dedicat construirii. Mellor etc. • UML asigură înţelegerea semanticii sistemului prin materializarea deciziilor. Booch.

proiectare şi implementare. Bucureşti 82 . Vederile(Views) asigură prezentarea diferitelor aspecte ale sistemului modelat sub forma unor abstractizări ce constau într-o secvenţă de diagrame38. vederi şi diagrame utilizate de UML 38 Davidescu N. vederi şi diagrame asigurând „viaductul” modele vederi diagrame fişiere de cod sursă date/cazuri de test. o posibilitatea includerii unor generatoare de rapoarte. o posibilitatea prezenţei instrumentelor de tip reverse engineering etc. prin care se poate asigura Figura 2. UML permite dezvoltarea ierarhiei de modele. • UML utilizează elemente de modelare vizuale sub forma unor instrumente CASE. care pot asigura următoarele funcţii: o generarea modelelor de analiză. 21 Ierarhia de modele.• UML este folosit pentru modelarea sistemelor informatice de tip discret. diagramelor specifice vederilor. Editura ALL Back. o generarea vederilor asociate modelelor de mai sus. – Proiectarea Sistemelor Informatice prin limbajul UML. o posibilitatea utilizării unor generatoare de cod implementarea sistemului realizat.

Modelare optimală a arhitecturii sistemelor prin UML îşi propune următoarele scopuri: • asigurarea modelării sistemelor de orice tip. 2.• UML permite dezvoltarea şi utilizarea modelării vizuale asigurând înţelegerea semanticii sistemelor lumii reale cu participarea actorilor (analişti. design-eri.1 Avantajele oferite de UML Modelarea prin UML are următoarele avantaje • permite construirea de modele complexe prin intermediul unui limbaj riguros de modelare standard. • UML foloseşte în etapa de modelare abordarea obiectuală care asigură optimizarea realizării programelor. 83 . • acest limbaj este considerat lingua franca pentru modelarea sistemelor informatice.).3. • UML utilizează termenul de model care realizează abstractizări ce descriu problemele complexe specifice. implementatori etc. inclusiv a sistemelor software orientate-obiect.3. • limbajul UML nu asigură în mod automat succesul în realizarea sistemelor informatice însă permite ameliorarea şi îmbunătăţirea multor elemente specifice modelării. experţi. programatori. 2.2 Obiectivele fundamentale ale UML UML are un spectru larg de utilizare putând fi utilizat în toate fazele de dezvoltare şi pentru toate tipurile de sisteme. • acest limbaj de modelare conţine elementele modelului (model elements) notaţiile modelului şi modul de utilizare expresia idiomatică în interiorul tranzacţiilor.

În figura 2. în timp-real. Se va descrie prin intermediul aspectelor: funcţionale care au în vedere structura statică. • asigură definirea unui limbaj de modelare utilizat atât de factorul uman cât şi de suportul fizic utilizat în realizarea sistemului. dinamică şi interacţiunile. Mai mult. inclusiv vederea particulară a aspectelor sistemului. • descrierea oricărui tip de sistem prin intermediul diagramelor orientate obiect • realizează specificaţii pentru domeniul Business Engineering prin care procesele de afaceri pot fi analizate. Fiecare aspect particular specific sistemului realizat va fi reflectat separat printr-o diagramă/schemă aferentă sistemului construit. fără ambiguităţi. software sau de “business”). distribuite. Consider că orice sistem poate fi descris printr-un set de vederi. mezo sau macroeconomic. în care fiecare va reprezenta o proiecţie completă a descrierii sistemului. • permite definirea unor soluţii pentru diferite tipuri de sisteme (sisteme informatice. fiabilitate. Modelarea unui sistem este o sarcină extensivă şi de aceea acesta nu poate fi descris printr-un singur graf definit integral. simplu şi inteligibil. amplasament. îmbunătăţite şi implementate prin tehnici adecvate (TQM-Total Quality Management. nonfuncţionale legate de coordonare/sincronizare. fiecare vedere particulară va fi descrisă printr-un număr de diagrame care conţin informaţii şi diferite aspecte particulare ale sistemului. organizaţionale legate de specificul activităţii.• fundamentează explicit „binomul” conceptual-soluţia operaţională. BPR-Business Process Reengineering) realizând sisteme informatice la nivel micro. tehnice. 84 . Aceste vederi vor asigura legături cu limbajul de modelare specific UML.22 am reprezentat vederile specifice cazului de utilizare (Use-Case VIEWS) fiind o descriere generică a utilizării sistemului prin intermediul funcţiilor.

specifică orientării obiect. 22 Proiecţia viziunilor cazului Use Case Vederile au rolul de a descrie sistemul prin intermediul percepţiei actorilor externi (client al sistemului. 2. Totodată proprietatea de încapsulare. Actorul extern intracţionează cu sistemul fiind un utilizator sau un sistem extern. 85 . organizarea sistemului în jurul obiectelor acordă o mare stabilitate de-a lungul întregului ciclu de dezvoltare.4. cât şi interfeţele care ascund implementările interne ale obiectelor. design-eri. aplicaţiilor cât şi relaţiile dintre acestea sunt mult mai puţin vulnerabile la schimbarea. Comparaţii între metodele de proiectare Având în vedere faptul că structura datelor. constituie un înalt nivel de protecţie oferit sistemului astfel modelat. dezvoltatori şi personal de testare) particularizându-se prin intermediul diagramelor cazului de utilizare (use-case diagrams) şi eventual diagrama activităţilor (activity diagrams).Figura 2. comparativ cu funcţiunile.

date. www. comportament.Object-Oriented Software Engineering 86 . fiecare iteraţie adăugând sau clarificând anumite detalii. Deoarece metodologia orientată-obiect defineşte din primele faze obiectele pe care continuă să le folosească şi să le extindă de-a lungul întregului proces. Această liniaritate permite reluarea procesului de modelare iterativ.uiowa.wikipedia. separarea dintre fazele ciclului de viaţă este mai puţin perceptibilă.html 41 OMT Object Modelling Technique 42 OOD Object Oriented Design 43 OOSE. 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.Un alt avantaj oferit de abordarea orientată obiect îl constituie liniaritatea procesului de dezvoltare a sistemului. unde este rafinat şi extins progresiv 39 .icaen. obţinându-se în final un model consistent. În Object Modeling Technique obiectul modelat în timpul fazei de analiză este utilizat şi în fazele de proiectare şi implementare.edu/~softeng/SElinks. www.org/wiki/Booch Project management. din punct de vedere al conceptelor utilizate. cu grad redus de eroare. Deosebiri substanţiale între diversele metodologii orientate-obiect nu există. Procesul este liniar pentru că nu există discontinuităţi a notaţiilor utilizate pe tot parcursul derulării activităţii. majoritatea celor utilizate în prezent fiind mai mult o colecţie de tehnici şi convenţii grafice de reprezentare care au ca obiectiv principal îmbunătăţirea sistemelor complexe40 plecând de la funcţie. O comparaţie între OMT şi unele dintre cele mai răspândite metode orientate obiect.

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 Restricţii pentru atribut Cheie candidată * * * * * * Cheie Câmp * * * * Se poate concluziona că metodologiile orientate-obiect analizate nu se deosebesc substanţial. 87 . ele prezintă de fapt aceleaşi concepte văzute din puncte de vedere diferite şi cu notaţii diferite. OMT comparativ cu celelalte metode orientate-obiect prezintă avantajul că utilizează aceleaşi notaţii pentru modelare în întregul ciclu de viaţă. astfel încât nu este necesară o trecere brutală la alte notaţii sau interpretări ale semanticii în etapele următoare ale proiectării. Principalul dezavantaj este acela că nu oferă o ghidare metodologică încă din etapele timpurii ale procesului de dezvoltare.

........1 Avantajele oferite de UML................. 16 Reprezentarea generală a „moştenirii”................................................................... 83 2..................................................1.................. 77 Figura 2......................... 41 Figura 2.................................... 41 2..................................................3 Criteriile de analiză a unei situaţii........................................ vederi şi diagrame utilizate de UML......... comenzilor şi a stocurilor.... 79 2......... 34 2...6 Reprezentarea domeniilor unui organism economic.....................2...........2.... 79 Figura 2.......2...... 21 Ierarhia de modele.....................................2.................................................2.......................................... 73 Figura 2..2............................................ 19 Forma generală a unei DTS................. 20 DTS pentru clasa de obiecte „Element_în_stoc” ................ „date”. 66 2. 85 Figura 2...............................2................. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect ......... 18 DTE a aplicaţiei Clienţi..... 45 2...2..4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor ........................1 Compartimentul financiar-contabil prin prisma costului........................................2........5 Diagrama fluxurilor de date pentru Clienţi .............4......... 11 Circuitul analiză-modelare evenimente.......................3.............. 74 Figura 2.... Modelul funcţional al metodei OMT.......... 43 Figura 2..3 Unified Modeling Language – cale de reunire a conceptelor orientate-obiect...........................................10 Traseul „sarcini-prelucrări”...............................2................... 51 Figura 2............. 36 2...CAPITOL 2... 85 88 .......... 34 METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC ...... Modelul dinamic în accepţiunea metodei OMT....... 17 Monitorizarea simultană a clienţilor.......1................ 82 Figura 2.........1........................................1.............4.......... 12 Obţinerea modelului de analiză...................2 Legăturile aferente actului decizie ..................... profitului.............................3.............................................. 77 2.............2.............................................. Parametrii specifici de performanţă pentru sistemele informatice ................... 50 2............................... 61 Figura 2..2..... 13 Forma generală de reprezentare a unei asocieri modelate ca o clasă......1.... 67 Figura 2............9 Studiu prealabil în cadrul metodei Merise .................2 Obiectivele fundamentale ale UML ............................... 76 Figura 2.....................................................8 MERISE – Ce-cum-cu cine se realizează?........ Comparaţii între metodele de proiectare ......... 83 2........... 34 2..................... 15 Asociere „Client”-„Bancă”-„Investiţie” ..........................7 Funcţii şi activităţi într-un sistem operant............................................... 76 Figura 2..........2........... Caracterizarea metodei Merise ................................................... Necesitatea şi structura procesului de evaluare a contabilităţii informatizate............................3.............. 55 Figura 2........................................ 71 2. 22 Proiecţia viziunilor cazului Use Case ......................... Modelul obiect în metodologia OMT.......................................... 66 Figura 2.................... 45 Figura 2...... 62 2..... mesaje”............ 46 Figura 2................... 14 Asociere „Împrumut” modelată ca o clasă.................. 79 Figura 2.2. 81 2........................... Cerinţe generale în utilizarea unei metode de proiectare a sistemului informatic... 74 Figura 2.................. 56 Figura 2.....1.................................. Metoda OMT de proiectare a sistemelor informatice........ 52 Figura 2........... investiţiei 36 Figura 2................................................ Metodele de concepţie şi de realizare a unui sistem informatic ..........

Sign up to vote on this title
UsefulNot useful