34

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.

35

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 Le Nouveau Petit Le Robert, Edition 1993 15 O’Brien J. - Systèmes d’information de gestion, De Boeck Université

36

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

37

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;

38

♦ 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 financiar-

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

39

- standardizare - măsura în care sunt stabilite reguli şi proceduri generale pentru a

defini sarcinile de executat şi a controla aplicarea lor. Informatizarea contabilităţii

duce la crearea de noi proceduri, le elimină pe cele redundante sau neutilizate.

- formalizarea - nu este legată implicit de noile tehnologii, depinzând uneori de

gradul de pregătire al utilizatorilor decidenţi.

- centralizarea - vizează importanţa acordată luării deciziilor de către manager,

urmărindu-se să nu se accentueze fenomenul birocratic. Î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. În

acelaşi timp este importantă şi cunoaşterea atitudinii utilizatorilor decidenţi, în

vederea anticipării unei eventuale reacţii de respingere (putându-se folosi în acest

sens metodologia CRIG).

c) criteriile economice - utilizarea lor are în vedere tipul proiectului şi etapa

procesului de decizie. 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).

Consider că, pentru zona contabilităţii informatizate, putem pune în evidenţă mai

multe praguri şi măsurări ale eficienţei:

♦ coeficientul eficienţei globale a sistemului informatic financiar-contabil

(Keg):

Keg = (Ec + As) / (Chi + Che) unde:

Ec - economii rezultate prin introducerea tehnologiilor informatice şi de

comunicaţie.

As - acumulările suplimentare;

Chi - cheltuieli de implementare;

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

40

Che – cheltuieli de exploatare a sistemului.

Calea principală de creştere a eficienţei sistemelor informatice este reducerea

cheltuielilor prin:

• utilizarea de elemente standardizate şi tipizate;

• elaborarea bugetului informatic şi controlul realizării indicatorilor prevăzuţi;

• îmbunătăţirea parametrilor de exploatare a aplicaţiilor informatice.

Cu cât durata de recuperare a cheltuielilor cu caracter informatic (ce privesc

echipamentele, programele, reţelele) este mai mică, cu atât standardele vor fi mai

mari şi se vor înregistra acumulări suplimentare (implicit profit net).

♦ durata de recuperare a cheltuielilor este invers proporţională faţă de

coeficientul eficienţei globale.(Dr):

Dr = 1/Keg

Se va avea în vedere totalitatea cheltuielilor (de investiţie, de exploatare) iar

sistemul informatic se va aprecia ca fiind eficient dacă Keg >1, iar Dr <5.

Performanţele sunt direct legate şi de dimensionarea optimă a sistemului informatic

financiar – contabil aşa cum este prezentat mai jos:

Caracteristicile sistemului Efectele economice

Abordare orientată client Efect de anvergură (eficienţa partajării resurselor şi eficacitatea utilizatorilor decidenţi)

Bază comună a prelucrărilor şi comunicaţiei

Efect de anvergură (cost al sistemului integrat < 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: - optimizarea prelucrărilor - optimizare traficului

Efect de anvergură (diminuarea costului de prelucrare şi transmitere)

Remarc anumite „forţelor motrice” care ajută la formarea rezultatului sistemului

informatic financiar–contabil: producţia informaţională şi modalităţile de

41

valorificare a acesteia; preţurile de aprovizionare cu diferite materiale; evoluţia

salariilor utilizatorilor decidenţi şi/sau a managementului; costul de întreţinere şi

reparare al reţelei sau echipamentelor etc. 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.

2.1.2. 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. Există o raportare permanentă a contabilităţii

informatizate la un sistem de referinţă (referenţial) şi o legătură directă cu actul

deciziei, fapt ilustrat în figura 2.2.

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ă;

• raporturile de putere;

• referenţialul.

42

Pentru o evaluare corectă şi completă a contabilităţii informatizate consider că se

impune să se cunoască foarte bine contextul, practicile existente, dar şi „cultura" sau

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

Procesul de evaluare a unui sistem presupune parcurgerea următoarelor faze:

selecţia, interpretarea şi decizia.

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

Aceştia pot fi de natură economică, tehnică, organizaţională, politică sau

sociologică şi se referă la aspecte cantitative şi calitative între care apare o vie

concurenţă. În acest fel se va evita creşterea sarcinilor administrative şi a efectelor,

accentuarea complexităţii căutării şi selecţiei datelor, depăşirea unui nivel al

costurilor dificil de suportat.

Managerul trebuie să obţină maxim de informaţii pentru a reduce incertitudinea în

faţa căreia se află, î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). J.C. Emery şi G.A. 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 - „chunks”17.

Faza de selecţie presupune înţelegerea comportamentului sistemului informatic

financiar-contabil, plecând de la tendinţele existente în cadrul lui, precum şi de la

liniile sale de forţă. Apare evidentă evaluarea strategică faţă de cea operaţională.

Consider că informatica, inteligenţa artificială (în special sistemele expert) pot

aduce un ajutor substanţial în faza de selecţie, prin consultarea bazelor de cunoştinţe

îmbogăţite cu experienţa trăită, utilizând şi facilităţile procesoarelor de tabele.

B. Faza de interpretare. În cadrul „acesteia în procesul de evaluare a

contabilităţii informatizate pot apare probleme legate de: puterea simbolurilor,

fluiditatea „catartică", dinamica actului de evaluare.

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

43

Puterea simbolurilor reprezintă pentru mulţi utilizatori decidenţi sinonimă cu

descentralizarea, autonomia şi creşterea productivităţii muncii. Ei îşi construiesc

diverse agregate simbolice legate de atuurile folosirii calculatorului pe propriul

birou. Fiecare agregat va poseda un conţinut „catartic” specific, astfel pentru unii

indivizi reţelele de telecomunicaţie vor constitui punţi spre o nouă eră a

comunicaţiei, în schimb pentru alţii vor fi doar surse a numeroase pericole.

Orice metodologie de utilizare a unei anumite situaţii din cadrul contabilităţii

informatizate, 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;

• valorizarea soluţiilor prin implicarea noilor restricţii pentru sistem.

Figura 2.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, ignorată până

Paradigmă

Evaluare criterii

cantitative

Evaluare criterii

calitative

Valorizare soluţii

decidenţi

Parametrii obiectivi

Gândire decidenţi

Restricţii

44

atunci". Fluiditatea parametrilor de interpretare a elementelor structurale ale

contabilităţii informatizate va fi influenţată de faptul că, interpretarea nu poate avea

valoare decât într-un spaţiu temporal definit prealabil. Fluiditatea determină

stabilirea unei anumite ponderi pentru fiecare criteriu evaluat la un moment dat.

Vom putea distinge în zona contabilă informatizată trei tipuri de criterii:

primordiale (exemple: mărimea intervalelor de timp, compatibilitatea resurselor);

importante (exemple: posibilităţile de adaptare la nou, capacitatea de a evita

hipertrofierea configuraţiilor informatice, inclusiv alinierea acestora la obiectivele

urmărite); eliminate din evaluare (exemple: compatibilitatea mărcilor de

echipamente, posibilitatea de autoformare a utilizatorilor decidenţi).

Dinamica actului de evaluare reliefează „cultura” sistemului mai ales „slăbiciunile”

vizibile sau ascunse. Uneori aceste minusuri pot fi imaginare, fiind vorba de fapt de

lacune ale criteriilor, o greşită definire (structurare), o percepţie eronată, o varietate

(incoerenţă) exagerată.

C. Faza de decizie – apare ca rezultat al unei cooperări şi a unui limbaj comun între

diferiţii „actori” din sistemul informatic financiar–contabil. Unele decizii admise în

trecut nu mai puteau fi înţelese la un moment dat, datorită modificării punctelor de

vedere şi a mediului, putând dobândi caracter ireversibil. 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; valorizarea acestora; alegerea soluţiei care este

considerată ca fiind cea mai bună. În figura 2.4 am redat aplicarea metodei

scenariilor asupra elementului structural financiar-contabil.

A imagina un „scenariu” presupune construirea de structuri, de sisteme decizionale

şi repartizarea pe roluri (stabilirea responsabilităţilor). Uneori decizia finală este

sinteza rezultatelor diferitelor decizii intermediare luate.

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. Aceasta din urmă este

dificil de stabilit, deoarece fiecare utilizator decident, plasat în faţa unei aceleiaşi

situaţii, va avea obiective şi scopuri diferite.

45

Figura 2.4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor

Valorizarea va ţine cont de natura informaţiei (operaţională, tactică, strategică) şi va

impune exprimarea utilităţii producţiei şi difuzării acesteia. 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).

Apreciez că, nu există alegeri bune sau rele, totul depinde de sistemul de referinţă

(referenţialul) ales, dacă aceasta se schimbă rezultatele evaluării se vor modifica.

2.2. Metodele de concepţie şi de realizare a unui sistem informatic

Metodele de concepţie se pot clasifica în trei mari categorii: metode structurate;

metode sistemice; metode orientate obiect.

Metodele structurate folosesc descompunerea progresivă descendentă „top-down”;

ele fiind în fapt carteziene. Concepţia constă în crearea, pornind de la specificaţiile,

unui ansamblu unitar în interacţiune având fiecare o funcţie clar definită.

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. Cele mai cunoscute metode aparţinând acestei

prime generaţii sunt: SADT (Structured Analisys and Design Technique), JSD

46

(Jackson System Development), Yourdon etc. Toate au la bază analiza funcţională a

întreprinderii. Diagramele de structură permit vizualizarea structurii ierarhice,

descrierea programului sau a unui modul fiind stabilite pe mai multe niveluri, prin

rafinări succesive.

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), sau

ca o diagramă – fiu (dezvoltare a unei părţi a celei părinte). În cazul metodei SADT,

datele şi prelucrările sunt examinate împreună definindu-se actigrame (sau

diagrama activităţilor) şi datagrame (diagrama datelor).

Figura 2.5 Diagrama fluxurilor de date pentru Clienţi

Avantajele metodelor ierarhice constau în simplitate şi o bună adaptare la cerinţele

formulate de utilizator. Dezavantajele pornesc de la conceperea sistemelor

informatice conform cerinţelor analizei funcţionale, 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.

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.

Metodele structurate au fost integrate în S.G.B.D. prin limbajul de descriere a

datelor.

47

Metodele sistemice permit vizualizarea şi înţelegerea organizării datelor. Aceste

metode se compun din abstractizări care prezintă lumea reală ca pe o colecţie de

entităţi şi de legături, stabilite între acestea. Majoritatea permite definirea de

restricţii descriind aspectele statice, dinamice sau chiar temporare ale entităţilor. În

această calitate ele constituie formalisme lizibile în cadrul specificaţiilor de nevoi.

Două metode constituie referinţa de reprezentare semantică: metoda individuală18

care va fi integrată Merise şi metoda entitate–relaţie19.

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. Acestea reprezintă oarecum un sistem de stimuli/răspuns;

stimulii fiind generaţi de captatori sau de acţionari. 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, de la

recepţia unui stimul. Se disting două clase active în timp real:

• sistemele de urmărire-control;

• sistemele de cumulare de date.

Sistemele de urmărire şi control cercetează în permanenţă numărul de captatori, şi

în funcţie de valoarea lor, declanşează acţiuni care eficientizează acţionarii (de

exemplu sistemele de alarmă antifurt din imobile).

Sistemele de cumulare de date culeg datele captate pentru procesare şi analiză.

Perioadele procesului de achiziţie şi cele ale procesului de procesare nu sunt în

armonie. Astfel apar diferenţe de viteză dictate de recurgerea la un mijloc de stocare

(tampon). Sistemul este organizat după modelul producător–consumator cu

mecanisme de excludere mutuală, pentru a evita cazul unde producătorul şi

consumatorul de date acced, în acelaşi timp, la elementul tampon. Aceste metode

recurg la diverse formalisme, de remarcat fiind cele din reţele Petri pentru aspectul

dinamic care au fost dezvoltate de formalizări specifice.

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

48

Metodele sistemice cuprind de o manieră globală sistemul informaţional şi

reprezintă a doua generaţie a metodelor de proiectare. Reprezentative sunt metodele

Information Engeneering, MERISE, AXIAL etc. Apropierea se realizează la nivel

conceptual20 şi se disting patru nivele de abstractizare.

1. Nivelul conceptual exprimă opţiunile de gestiune; formulând întrebarea: Ce facem?

2. Nivelul organizaţional exprimă alegerile întreprinderii legate de resurse umane şi materiale. Se integrează la acest nivel noţiunile de timp, loc de actori şi se pun următoarele întrebări: cine, unde, când şi cum?

3. Nivelul logic permite alegerea mijloacelor şi a resurselor informatice făcând

abstracţie de caracteristicile lor tehnice precizate.

4. Nivelul fizic este reprezentat prin alegerile tehnice urmărind specificitatea

lor. La fiecare nivel de abstractizare sistemul de informare este reprezentat

prin trei modele: datele, prelucrările, comunicările.

Ceea ce este specific acestor metode este utilizarea teoriei sistemelor în analiza

întreprinderii. Sistemul informatic este abordat sub două aspecte complementare,

datele şi prelucrările analizate-modelate independent cu reunirea lor cât mai târziu

posibil. Spre deosebire de metodele ierarhice, metodele sistemice acordă „prioritate

datelor faţă de prelucrări şi respectă cele trei nivele de abstractizare introduse de

raportul ANSI/SPARC: conceptual, logic şi fizic”21. Avantajele metodelor sistemice

apar din promovarea tehnologiei bazelor de date. Dezavantajele sunt datorate

deficienţelor care pot apărea în modelarea prelucrărilor şi a discordanţelor posibile

între modelele datelor şi prelucrărilor.

Metoda orientată obiect este caracterizată prin atenţia deosebită acordată

concomitent structurii datelor şi structurii funcţionale. Această viziune permite

construirea unei baze stabile în procesul de dezvoltare a modelului şi utilizarea

conceptului obiect, unitar de-a lungul întregului ciclu de viaţă. Toate celelalte

concepte: funcţii, asocieri, evenimente gravitează în jurul obiectelor, astfel încât nu

este necesară trecerea la alte notaţii sau interpretări de semantică în diferite etape de

dezvoltare. Metoda orientată obiect se caracterizează prin definirea a trei modele:

20 Nanci D. şi col. - Ingénierie des systèmes d’information avec Merise, Sybex 21 Stanciu V. şi col. - Proiectarea sistemelor informatice, Editura Dual Tech, Bucureşti

49

• Modelul obiectelor are rolul de a descrie obiectele care intervin în problema

de rezolvat şi relaţiile dintre ele. Modelul obiectual reprezintă descrierea

structurii statice a obiectelor, claselor de obiecte, a operaţiilor şi atributelor,

precum şi a legăturilor şi a relaţiilor dintre ele.

• 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. Modelul dinamic descrie

interacţiunea dintre obiecte şi este focalizat pe aspecte ce se schimbă în timp,

deoarece orice obiect are un ciclu de viaţă cu un punct de pornire şi unul de

sfârşit. Modelul dinamic descrie acest ciclu de viaţă, ce se întâmplă de-a

lungul său şi cum este influenţat obiectul.

• Modelul funcţional are rolul de a descrie prelucrările şi fluxurile de date.

Modelul funcţional prezintă transformările valorilor datelor precizând sursa

şi destinaţia lor.

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ă, clienţi, produse, servicii, etc.);

• Informaţia gestionată în cadrul unui sistem informatic are tendinţa de creştere

în complexitate, iar manipularea ei trebuie să fie într-o formă uşor de perceput

de către utilizatorul final;

• Sistemele informatice realizate trebuie să fie flexibile în raport cu modificarea

structurilor de date şi trebuie să evolueze natural în timp, urmând astfel

evoluţia organismului economic, bancar, financiar pe care îl deserveşte;

• Sistemele informatice evoluează spre abordări multimedia care combină text

cu foi de calcul, grafice, animaţie şi voce.

Majoritatea metodelor orientate obiect utilizează reguli sau operaţii semantice:

generalizarea/specializarea, agregarea/descompunerea, combinate cu moştenirea şi

încapsularea.

50

2.2.1. 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. Ea dispune de toate

instrumentele care să permită realizarea etapizată a unui sistem informatic cu grad

mare de integrabilitate, pornind de la localizarea unui subansamblu reprezentativ.

Numele metodei este abrevierea de la „Methode d’Etude et de Realisation

Informatique par le Sous – Ensemble representatif”.

Utilizarea metodei MERISE trebuie să facă posibilă descompunerea problemelor de

organizare a muncii. Practica în acest domeniu a evoluat considerabil traversând un

curent de gândire numit sistemică sau, ceea ce altă dată, se numea teoria sistemelor.

Din raţiuni didactice, pe parcursul însuşirii metodelor sistemice se poate asocia

figurativ enunţul următor: „a se ridica pentru a vedea mai bine...a înţelege...pentru a

acţiona mai bine”. Acest curent de gândire care a cuprins şi alte discipline de

cercetare, a oferit garanţia stabilităţii şi evoluţiei metodei, fiind baza filosofiei

MERISE22 iar toate conceptele operatorilor sistemici pentru ştiinţa organizării sunt

asimilaţi şi în cadrul acestei metode. „A înţelege nu este suficient pentru a acţiona,

trebuie şi să...decizi” constituie al doilea „suport” al filosofiei MERISE. Pot fi

consecinţe importante legate de acest demers, pentru că, de cele mai multe ori, în

ultimă instanţă soluţia pentru informatizarea unui domeniu dat este în realitate o

problemă de luare a unei decizii adecvate.

Fundamentul metodei constă în utilizarea mijloacelor de reprezentare cumulativă a

structurii organismelor economice corelată cu domeniile de activitate proprii.

Consider necesară 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. În figura 2.5 prezint implicarea sistemului de management şi a

sistemului informaţional.

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

51

Figura 2.6 Reprezentarea domeniilor unui organism economic

Apare evidentă activitatea de pilotaj cu sarcini de coordonare şi decizie corelată cu

obiectivele fixate. Se va avea în vedere faptul că vor fi necesare mutaţii la nivelul

cerinţelor ca reacţii la fluxurile de intrare-ieşire în şi din sistem.

Elementul nodal - sistemul informaţional - permite alcătuirea unor magistrale de

circulaţie prioritară cu scopuri de actualizare a deciziei şi de dezagregare pe centre

de responsabilitate. 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. Î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, stabilite prin sistemul de management, aplicate asupra intrărilor pentru

a produce ieşirile dorite. Ansamblul activităţilor sistemului operant formează

imaginea dinamică de nivel „acţiune”.

Implicarea sistemului informaţional apare evidentă prin necesitatea de fuziune a

datelor exprimată de pilotaj şi execuţia operaţiunilor productive. În cadrul

proiectării unui sistem informatic, datele şi prelucrările sunt studiate şi modelate

împreună.

Corelând elementele prezentate anterior constat invariaţia funcţiilor sistemului

operant care determină activităţi bine delimitate.

52

Figura 2.7 Funcţii şi activităţi într-un sistem operant

În figura 2.7 am disociat ansamblul activităţilor sistemului operant faţă de mulţimea

funcţiilor sale. 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. Identificarea acestui ansamblu reprezentativ este unul

dintre paşii de bază pentru utilizarea metodei Merise.

Responsabilitatea conducerii, coordonării unui proiect de informatizare într-un

organism, ne situează în faţa realităţii următoare:

• termenele cuprinse în studiul de proiect trebuie respectate;

• decelarea problemelor legate de organizare şi informatizare necesită o anumită

„filozofie”;

• existenţa mijloacelor care să permită localizarea şi rezolvarea problemelor.

MERISE este o metodă cu ajutorul căreia se poate defini, analiza, concepe şi realiza

un proiect care acoperă activitatea unui domeniu bine definit. Ea are la bază o

filosofie proprie a derulării întregului proiect, urmărind detalierea fiecărei etapă de

studiu şi aplicarea unor instrumente specifice.

Proiectarea şi realizarea unui sistem informatic sunt operaţiuni dificile pentru că

obligă la luarea în considerare a tuturor factorilor sistemului om–maşină. Dacă

acceptăm ideile că sunt mai multe modalităţi de delimitare a domeniilor de studiu,

că sunt nenumărate mijloace de documentare, 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.

53

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.

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.

Este deci o consolidare a unui proiect care ne permite să avem în faza finală,

informatizarea completă a unui sistem informaţional–organizaţional specific unui

organism economic supus analizei. Apărătorii acestei abordări avansează

argumentul că este mai bine să acţionezi progresiv, decât să mizezi pe ipoteza

nerealistă că un proiect global poate fi ţinut permanent la zi.23

Abordarea descendentă constă în a coborî, pe scara piramidei ierarhice, până la bază

şi realizând totodată şi o analiză. Această viziune consideră că un anumit domeniu

este compus din părţi corelate între ele şi cu legături cu exteriorul, caracteristică

pentru toate sistemele informaţionale.

Este mai bine să se creeze şi să se realizeze din start un sistem informatic care să

ţină cont de obiectivele planificate, abordate într-o maniere globală, decât să se

încerce a se integra a posteriori, subsisteme informatice independente. MERISE este

o metodă de concepţie de sisteme informatice care se poate înscrie în această

abordare descendentă.

În esenţă, filosofia MERISE se poate constitui sub forma unui ghid de abordare a

unui sistem informatic pus în evidenţă sub forma sintetică utilizând o semantică

bazată pe cuvinte cheie cât mai sugestive. MERISE poate realiza sisteme

informatice din mai multe perspective:

• MERISE perspectivă sistemică. În această privinţă interesează totalitatea

problemelor înainte de a da o soluţia globală, astfel spus întregul este altceva

decât suma părţilor.

23 Marciniak R. şi col. – Systèmes d’Information dynamique et organisation, Editura Economica, Paris

54

• MERISE perspectivă paralelă date–prelucrări. Faţă de alte metode care tratează

în mod privilegiat datele sau prelucrările, MERISE ţine cont în aceeaşi măsură de

date şi de prelucrări. 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.

• MERISE perspectivă orientată pe nivele. Există în cadrul metodei nivele de

abstracţie care corespund domeniilor de preocupare şi care, la rândul lor,

determină viziuni descriptive. Nivelele de abstracţie sunt ierarhizate pornind de

la situaţia conceptuală sau fizică până la cea organizaţională sau logică. Această

viziune permite fixarea opţiunii gestiunii la nivel conceptual, opţiunii

organizaţionale la nivel logic şi a celei tehnice la nivel fizic.

• MERISE viziune globală asupra unui subansamblu reprezentativ. În majoritatea

cazurilor vederea de ansamblu poate considera un domeniu ca fiind cel mai

important. Grija de a nu lungi prea mult studiul domeniul respectiv şi pretenţia

acestui studiu de fi exhaustiv, sunt deseori contradictorii. Subansamblu

reprezentativ (SREP) este soluţia oferită de metoda MERISE pentru a concilia

aceste două nuanţe contradictorii. Subansamblu reprezentativ presupune cu

necesitate un studiu prealabil.

• MERISE din perspectiva externă. 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. Această „reconciliere” dintre date şi prelucrări se face prin

intermediul modelelor externe24.

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, de a progresa spre un scop”25. În cadrul metodei MERISE, există o

descompunere în etape precum: studiul prealabil, studiu detaliat, realizarea şi

punerea în lucru. 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.

24 Reix R. – Systemes d’information et management des organisations, Editura Vuilbert, Paris 25 Merise Method and knowledge, www.cmi.univ-mrs.fr

55

Demersul metodei se poate reprezenta sintetic astfel:

Ce trebuie făcut? – Etape Subetape

Cum se face? - (Legături, Reguli) Cu cine se face? - (Participanţi)

În figura 2.8 am reprezentat cerinţele la care răspunde metoda MERISE constatând

interdependenţele externe, interne şi fundamentale.

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

Sub formă tabelară prezint etapele acestei metodei sintetizând rezultatele fiecărui

stadiu.

STUDIU FUNCŢIUNI REZULTAT DECIZIA după studiu

Studiu prealabil

Studiu situaţiei actuale

Degajarea unui subansamblu reprezentativ

Dosar de opţiuni conţinând mijloacele de punere în lucru

Decizia pentru o soluţie

Studiu Studierea detaliată a Specificaţii funcţionale Acordul

56

STUDIU FUNCŢIUNI REZULTAT DECIZIA după studiu

detaliat diferitelor domenii pentru soluţia reţinută

„externe” generale şi detaliate

utilizatorilor

Realizarea Studiul tehnic

Realizarea programelor

Sistem de criterii de piaţă privind „jocul” de probă al utilizatorilor

Recepţia provizorie

Punerea în lucru

Studiul de ansamblu al problemelor legate de utilizarea noilor funcţiuni automate

Sistem implantat în ambientul real şi funcţionând în regim normal.

Recepţia definitivă

Î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, tehnice şi restricţii financiare definite înainte de studiul

prealabil.

În figura 2.9 reprezint iniţierea şi derularea paşilor care privesc studiul prealabil.

Figura 2.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;

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

57

» studiul existent; » concepţia; » organizarea punerii în lucru; » bilanţul cantitativ şi calitativ; » concluziile studiului prealabil.

Metoda se utilizează pentru toate proiectele de organizare a unui domeniu de

activitate chiar dacă nu conţin elemente de informatizare, situaţie în care nu apare

contextul informatic. Se poate constitui într-un instrument al metodei orice mijloc

„care permite să se execute un lucru: o muncă, o operaţie” (Larousse).

În metoda MERISE se regăsesc instrumente generale (interviul, ancheta) cât şi

proprii (formalizări individuale şi ale prelucrărilor). 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 Obiect descris

Nivel de abstracţie

Exemplu de modele

Ce se doreşte să se facă în fond

GESTIUNE Date

Relaţii Reguli de gestiune Înlănţuiri de prelucrări

CONCEPTUAL MODELUL CONCEPTUAL AL DATELOR (invariant static) MODELUL CONCEPTUAL AL PRELUCRĂRILOR (invariant dinamic)

Cine face Cu ce şi Când

ORGANIZAŢIONAL Oameni Maşini Reţele diferite Repartiţie geografică

LOGIC SAU ORGANIZAŢIONAL

MODELUL LOGIC DE DATE

MODELUL LOGIC DE PRELUCRARE

Cum se face

TEHNIC Entităţi

Programe

Proceduri

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, modelul fizic al prelucrărilor pot răspunde prin entităţi

programe proceduri. La întrebarea „cine, cu ce şi când?“ din punct de vedere

58

organizaţional răspunde modelul logic al datelor şi cel al prelucrărilor. La

interogarea „ce se doreşte a se realiza?” datele, relaţiile, regulile de gestiune,

înlănţuirile de prelucrări apar ca răspuns dedus din modelul conceptual al datelor şi

al prelucrărilor.

În continuare supun atenţiei sintetiza nivelelor de abstractizare corelate cu

ansamblul date-prelucrări.

DATE PRELUCRĂRI

CONCEPTUAL Modelul conceptual al datelor

MCD

- Concepte fundamentale

- Relaţii semantice

Modelul conceptual al prelucrărilor

MCP

- Descrierea macroscopică (noţiunea de proces)

LOGIC Modelul logic de date

MLD

Integrarea restricţiilor de organizare

- Traducerea în SGBD

entitate

relaţie

instanţă (realizare)

Modelul logic al prelucrărilor

MLP

- Integrarea alegerii opţiunii

- Repartiţia om - maşină

- Timp real – timp diferit

Desfacerea proceselor proceduri Faze sarcini

FIZIC Modelul fizic al datelor

MFD

Descrierea bazelor de date

Noţiuni de înregistrare

Modelul fizic al prelucrărilor

MFP

Descrierea programelor

Descrierea procedurilor

Corelând figura 2.8 referitoare la „Merise Ce-cum-cu cine se realizează?”,

nivelurile de abstracţie, modelele rezultate, 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, dar în acelaşi timp şi de relevanţă

surprinzând aspecte semnificative din realitatea supusă modelării.

59

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

utilizează o abstractizare prin relaţie, recunoscută de ISO fiind o apropiere de

modelul entitate-relaţie. Mai multe concepte de bază caracterizează acest model:

- proprietatea este o modelare a informaţiei elementare, de exemplu funcţia

exercitată de un salariat: vânzător, contabil, informatician etc.

- identificatorul permite modelarea unui ansamblu de obiecte concrete sau abstracte,

percepute ca fiind pertinente pentru sistemul informatic studiat, de exemplu

identificatorul salariatului sau identificatorul produsului. Elementele din acest

ansamblu sunt ocurente, de exemplu în cazul salariatului ocurenţa este exprimată

astfel: „Georgescu, 28 ani, manager”.

Regulile de pertinenţă, de identificare, de evidenţiere, de verificare şi omogenitate

conduc la modelizarea termenilor identificării.

- relaţia între mai mulţi indivizi este un ansamblu de produse carteziene de ocurenţă

a acestora. De exemplu produsul cartezian vânzător * client reprezentat prin toate

cuplurile vânzător/client, va fi modelat prin ansamblul de legături care exprimă

aceeaşi natură între mai mulţi indivizi. Bineînţeles, aceste relaţii trebuie să fie

pertinente în raport de sistemul informatic studiat.

- cardinalitatea reprezintă cuplul entitate–relaţie. În spatele cardinalităţilor se găsesc

reguli de gestiune reale.

Inspirat din reţelele Petri, 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, receptorii (stimulii) şi emiţătorii (reacţii) prin domeniu sunt modelări ale

evenimentelor şi rezultatelor. Evenimentele şi rezultatele pot fi externe sau interne.

Cele externe provin sau sunt destinate unui actor extern, iar cele interne rămân în

60

domeniu pentru a asigura continuitatea procesului, urmărind satisfacerea sistemului

de pilotaj.

Operaţia descrie comportamentul domeniului la declanşarea produsă prin mai multe

evenimente. 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. Operaţia constituie un bloc de prelucrare

cuprinzând acţiuni elementare generatoare de evenimente interne, înlăturând

posibilitatea de generare a evenimentelor intermediare între acţiunile ce aparţin

operaţiei. Operaţia emite, în retur rezultate în funcţie de condiţiile traduse prin

expresii logice.

Prelucrările reprezintă partea dinamică a sistemului informaţional. Ele descriu

acţiunile exercitate asupra datelor cu scopul obţinerii informaţiilor dorite,

reprezentând materializarea sub formă de acţiuni a regulilor de gestiune specifice

activităţii întreprinderii. 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. În reprezentarea acestei înlănţuiri de operaţii şi evenimente

declanşatoare în cadrul modelului, se impune respectarea unor cerinţe determinate

de regulile de gestiune. Asocierea MCP ↔ eveniment indică faptul că ceva anume

s-a întâmplat şi în consecinţă sistemul trebuie să reacţioneze.

- sincronizarea reprezintă o condiţie prealabilă a unui flux de operaţii în care mai

multe evenimente participă la declanşare. Sincronizarea se traduce prin expresii

logice. Regulile de sintaxă şi de funcţionare permit verificarea coerenţei MCP.

Modelul conceptual de comunicaţie (MCC) are drept scop reprezentarea fluxurilor

de informaţii sau mesaje între diferitele subsisteme omogene ale întreprinderii,

numite domenii. Domeniile privesc marile funcţiuni sau procese majore din

întreprindere. Un mesaj este trecerea de informaţii între domenii sau între un

partener (factorul extern) al întreprinderii şi un domeniu. Mesajul este emis de o

parte (partener sau domeniu, emiţător) şi recepţionat de alt element structural

(receptorul).

61

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, varietatea soluţiilor organizaţionale posibile, criterii de

evaluare (economice, sociale, ergonomice, tehnice). Totodată poate fi considerată ca

o etapă accesibilă, deoarece nu apar dificultăţi induse de abstractizare.

În figura 2.10 vă supun atenţiei reprezentarea cumulată a MOP-MOD-MOC care

încearcă să evidenţieze circuitul „sarcini-prelucrări”, „date” şi „mesaje”.

Figura 2.10 Traseul „sarcini-prelucrări”, „date”, mesaje”

Problematica modelului organizaţional este sintetizată în tabelul următor:

Problematica MOP Problematica MOD Problematica MOC

- Repartizarea prelucrărilor pe centre, unităţi şi posturi de lucru - Caracterizarea sarcinilor: posturile raportate, gradul de automatizare, termenul de răspuns, modul de funcţionare, regulile şi procedurile aplicabile, frecvenţa, durata, capacitatea

- Repartizarea datelor: pe centre, unităţi şi posturi de lucru - Volumetrie - Istoric - Securitate

- Schimburile de mesaje între centre

Modelarea priveşte sistemul de informaţii organizaţional care se finalizează prin

confruntarea modelelor; aplicând următoarele tehnici: abordarea participativă,

abordarea printr-o grilă de coerenţă MCD – MOP – MOD, machetare şi validarea

MCD – modele externe. Modelele externe28 privesc datele drept mesajele legate la

evenimente–rezultate. Continuarea studiului presupune modelarea sistemului şi se

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

62

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

În cele ce urmează supun atenţiei sinteza reunirii modelelor logice şi fizice ale

datelor, prelucrărilor, comunicaţiei.

Problematica MLP şi al MFP Problematica MLD şi

al MFD

Problematica MLC şi

al MFC

- Repartizarea prelucrărilor informatizate: centre, unităţi logice de prelucrare. - Modularizare

- Transformare MOD după tipul SGBD - Dimensiunea MLD - Optimizarea

- Mesaje între centre prin magistrale informatice

Concluzionând ideile prezentate pe parcursul acestui subcapitol, afirm că utilizarea

metodei MERISE în contextul cadrului metodologic al conducerii proiectelor

informatice este oportună deoarece:

• determină limitele nivelelor de preocupare (conceptual, logic, fizic);

• permite exprimarea unor concepte complementare legate de conducerea

studiilor detaliate;

• propune un plan de lucru detaliat pentru derularea fiecărei etape pentru a

facilita conducerea proiectelor în concepţia sistemelor informatice;

• furnizează documentele tip ISO pentru constituirea documentaţiei aferente

fiecărei etape.

Se poate afirma că este o metodă „deschisă”, susceptibilă să se integreze într-un

cadru metodologic mai larg.

2.2.2. Metoda OMT de proiectare a sistemelor informatice

OMT – Object Modeling Tehnique – este bazată pe modele ca abstracţii ale

problemelor din lumea reală, care urmăresc focalizarea aspectelor importante ale

63

problemei şi omisiunea celor irelevante. Această metodă a fost creată de James

Rumbaugh şi este cea mai cunoscută şi utilizată metodă de proiectare orientată

obiect (POO). Un sistem informatic este privit ca un ansamblu de obiecte care

cooperează între ele şi tratează obiectele ca instanţe ale unei clase în interiorul unei

ierarhii. Noţiunea de „obiect” 29 este dependentă de implementarea metodei în

limbajele de nivel înalt cum ar fi: ADA, MODULA, SMALLTALK, C++, CLOS

(Common Lisp Object System).

Această metodă are în vedere trei aspecte importante:

• abstractizarea realităţii, ceea ce înseamnă că pentru aceeaşi problemă se pot

crea mai multe modele care să focalizeze diferite aspecte;

• scopul modelului este să se focalizeze ceva cunoscut;

• comunicarea între membrii echipei de analiză-proiectare şi între utilizatori.

Metodele orientate obiect propun modelarea concomitentă a datelor şi a funcţiilor

obţinând ierarhii de clase de obiecte care înglobează atât datele cât şi

comportamentul, spre deosebire de modelarea datelor separată de a funcţiilor,

element structural al metodelor tradiţionale.

Comparativ cu metodele tradiţionale, abordarea orientată-obiect mută centrul de

greutate al soluţionării problemei în faza de analiză, fapt compensat printr-un minim

de efort necesar a fi depus în faza de implementare. O bună înţelegere a cerinţelor

problemei reale va conduce la construirea unui model fiabil, adaptabil, care suportă

uşor modificările ulterioare.

Metodele obiect integrează modelarea de structură cu cea comportament30. Obiectul

reprezintă o entitate (reală sau abstractă) a lumii supuse modelării, caracterizată prin

identitate, stare şi comportament. În fapt, obiectul reprezintă un element

identificabil, concret sau abstract, caracterizat prin structură, atributele şi metode

proprii.

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

64

Corespunzător metodologiei31 se parcurg următorii paşi:

• definirea problemei;

• elaborarea unei modalităţi informale de identificare a datelor şi a funcţiilor

relevante corespunzătoare problemei;

• formalizarea strategiei prin identificarea obiectelor şi atributelor, operaţiilor

asupra obiectelor, stabilirea instanţelor şi implementarea operaţiilor.

Metoda OMT, folosită pentru proiectarea software-lui contează pe mijloacele de

reprezentare: diagrama de flux de date pentru surprinderea comportamentului

dinamic şi diagrama modulară (arhitectura produsului) pentru surprinderea

comportamentului static. Această metodă de proiectare susţine strategia

prototipizări de structurare a procesului de realizare a produselor informatice.

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;

• obiectele individuale pot fi modificate fără a le afecta pe celelalte, rezultând

că software-ul construit modular poate fi modificat şi dezvoltat cu eforturi

minime;

• reutilizarea componentelor soft existente, tehnologie care asigură realizarea

de aplicaţii într-un timp scurt şi la costuri reduse.

OMT propune trei tipuri de modele, obiect, dinamic şi funcţional pentru scopuri şi

descrieri diferite de obiecte, interacţiuni, transformări. Cele trei tipuri de modele

sunt de fapt proiecţii ale unei singure informaţii, fiecare prezentând un anumit

specific. Existenţa şi necesitatea acestor modele solicită şi realizează o strânsă

conexiune între ele. Fiecare model în OMT poate fi reprezentat prin diagrame

distincte32:

31 Rumbaugh's Method, www.iconixsw.com/Rumbaugh.html 32 Castellani X. - Méthodologie générale d’analyse et de conception des systèmes d’objects. 1. L’ingénierie des besoins, Masson

65

• pentru modelul de obiecte – CAD (Class Association Diagram sau DAC

Diagrama de Asociere a Claselor);

• pentru modelul dinamic – ETD (Event Trace Diagram sau DTE Diagrama de

Trasare a Evenimentelor), precum şi STD (State Transition Diagram) sau

DTS (Diagrama de Tranziţie a Stărilor);

• pentru modelul funcţional se apelează la DFD (Diagrama de Flux de Date -

Data Flow Diagram); DCC (Diagrama de Comunicare a Claselor, CCD

Class Comunication Diagram); DGM (Diagrama de Generalizare a

Mesajelor - MGD Message Generalization Diagram).

În reprezentarea ciclului de viaţă al unui proiect se utilizează mai multe modele, dar

flexibilitatea metodelor orientate-obiect permite lucrul într-un ciclu de viaţă

„spirală”. Ciclul de viaţă spirală sau modelul spirală, spre deosebire de modelul în

cascadă, specific metodelor structurate, presupune faptul că doar o parte a

modelului trebuie să fie finalizat înainte de a trece la faza următoare. Aceasta

înseamnă că versiunii parţiale ale sistemului pot fi livrate în timp scurt, evaluate şi

validate de către utilizator, proiectantul realizând extrem de rapid analiza pentru

completarea modelelor.

Feed-back-ul permite găsirea de soluţii convenabile, iar flexibilitatea modelelor

orientate–obiect permite armonizarea cerinţelor utilizatorului cu soluţiile propuse de

echipa de realizatori. Modelul „în cascadă”, chiar în varianta care cuprinde iterarea

fazelor, permite detectarea şi corectarea erorilor înainte de trecerea la faza

următoare şi impune ca în fiecare fază să se producă un document şi produse valide.

Corectarea erorilor în fazele următoare celei în care s-au produs este foarte

costisitoare (timp, efort), 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.

66

2.2.2.1. 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, dar apar şi elemente specifice.

Analiza are drept obiectiv modelarea problemei din lumea reală sau definirea

Domeniului Aplicaţiei (Application Domain). Proiectantul creează modele de

obiecte şi funcţii fără a lua în considerare aspectele de implementare. În figura 2.11

am reprezentat o secvenţă a activităţi analizei şi modelării evenimentului studiat.

Figura 2. 11 Circuitul analiză-modelare evenimente

Modelul de analiză trebuie înţeles şi validat de utilizator. Această etapă are ca

rezultat formularea problemei, modelul obiectual, modelul dinamic şi cel funcţional.

Analiza este utilă clarificării cerinţelor, realizării conexiunii beneficiar-producător

bazată pe înţelegere, reprezentând în acelaşi timp cadrul pentru proiectarea

ulterioară şi implementare. Finalizarea etapei analiză-modelare (figura 2.12) se

materializează prin definirea unui model precis, concis, inteligent şi corect al

viitorului sistem.

67

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 A.1. Analiza şi modelarea evenimentelor Scrierea declaraţiei problemei (formularea problemei)

Text liber Declaraţia problemei (de către client sau elaborator)

Analiza evenimentelor problemei

Diagrama de Trasare a Evenimentelor (DTE)

Scenarii de evenimente pentru evenimentele complexe ale aplicaţiei

Modelarea evenimentelor

Diagrama de Comunicare între Clase (DCC) Diagrama de Generalizare a Mesajelor (DGM)

Diagrama de Comunicare între Clase cu mesaje şi interacţiunile dintre clase Diagrama de Generalizare a Mesajelor specifică interacţiunii între clase

A.2. Construirea modelului de analiză Definirea modelului obiectual

Diagrama de Asociere a Claselor (DAC)

Model de obiecte cu clasele aplicaţiei atributele, operaţiile şi asocierile lor.

Definirea modelului dinamic

Diagrama de Tranziţie a Stărilor (DTS)

Modelul dinamic (DTS) pentru clase importante şi modelul de obiecte care încorporează rezultate din DTS

Definirea modelului funcţional

Diagrama de Flux de Date (DFD)

Modelul funcţional cu funcţionalitatea operaţiilor complexe şi completarea lor în DAC

Reiterarea şi verificarea

Verificări Se completează modelul de obiecte din celelalte iteraţii şi se verifică consistenţa

68

Proiectarea de sistem – împarte modelul de analiză în părţi mai mici, uşor de

înţeles şi construieşte arhitectura sistemului prin identificarea subsistemelor şi

transpunerea lor pe hardware-ul disponibil. Proiectarea de sistem porneşte de la

domeniul aplicaţiei şi ia în considerare conceptele de implementare adică

optimizarea, rafinarea şi extinderea celor trei modele până la nivelul de detaliu care

să permită implementarea. Se poate spune că, analiza descrie problema iar

proiectarea de sistem descrie soluţia. Rezultatul acestei etape este realizarea

arhitecturii de bază a sistemului şi adoptarea deciziilor privind strategia la nivel

global.

Scopul acestei etape este transpunerea declaraţiei problemei aşa cum a fost definită

în etapa de analiză într-o arhitectură adecvată, bazată pe divizarea în subsisteme

precum şi decizii de implementare la nivel global. Rezultatul este un concept de

implementare care rafinează, optimizează şi extinde cele trei modele preluate din

etapa de analiză, până la etapa de proiectare obiectuală care să permită

implementarea propriu-zisă.

Proiectarea de sistem presupune două mari faze şi anume: construirea arhitecturii

sistemului; modelarea detaliilor subsistemelor.

În faza de construire a arhitecturii sistemului se dezvoltă aşa numitele clase de

bază, 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;

interfaţa grafică de conexiune cu utilizatorul.

Soluţia de sistem proiectată va include pe lângă clasele de bază şi clasele de

interfeţe grafice, clasele de acces la bazele de date. Suma acestora reprezintă soluţia

generală de organizare.

În a doua fază se modelează în detaliu fiecare sistem individual, accentul pus pe

diferitele modele fiind diferit de la un tip de sistem la altul. Se creează aşa numitele

clase container organizate pe sistem.

Sintetizarea fazelor şi activităţilor etapei de proiectare de sistem este relevată de

tabelul de mai jos:

69

Faze şi activităţi Modalităţi de reprezentare

Descriere

1. Construirea arhitecturii sistemului 1.1. Organizarea sistemului în subsisteme a) Importul sistemului claselor de bază

DCC DAC

Se utilizează din etapa de analiză DCC şi DAC

b) Alegerea unei arhitecturi Text Se stabileşte arhitectura sistemului c) Crearea unui Model de Comunicare între Clase de Nivel de Proiect

DCC la nivel de proiect

În DAC din etapa de analiză, actorii vor fi înlocuiţi cu subiecţi, clasele de bază vor fi grupate, se adaugă şi se conectează subiectul „Clase de Interfaţă”

d) Crearea sistemelor pentru fiecare subiect

Text Fiecare subiect din diagramă va fi descompus într-un sistem cu acelaşi nume.

1.2. Definirea interfeţelor DGM DCC

Completarea modelului de comunicare a claselor la nivel de proiect cu mesajele compuse nou definite

1.3. Identificarea obiectelor active concurente şi exclusive

Text Identificarea obiectelor care sunt active în acelaşi timp şi a celor care au un comportament exclusiv

1.4. Alocarea subsistemelor pe procesoare şi task-uri

Text Se alocă subsistemele la procesoare, astfel încât să asigure satisfacerea cerinţelor de performanţă şi minimizarea comunicării

1.5. Alegerea strategiei de bază pentru implementarea datelor memorate

Text Se aleg structurile de date, fişierele sau bazele de date corespunzătoare

1.6 Identificarea resurselor globale şi determinarea mecanismelor pentru asigurarea accesului la date.

Text Identifică resursele globale şi determină mecanismele pentru controlarea accesului

1.7. Alegerea variantei de implementare a controlului

Text

1.8. Stabilirea condiţiilor limită

Text

1.9. Stabilire priorităţi 2. Modelarea detaliilor de subsistem 2.1 Definirea modelului de comunicare a claselor

DCC Definirea modelului de comunicare între clase la nivel de sistem din modelul de comunicare la nivel de proiect

2.2. Detalierea modelului obiect

DAC Detalierea modelului obiectual din faza de analiză

Proiectarea obiectuală – are drept scop alegerea modului de implementare pentru

fiecare clasă, proiectându-se algoritmi şi implementându-se asocierile. Se realizează

70

gruparea claselor în superclase pentru uşurarea implementării şi pentru

îmbunătăţirea performanţelor. În urma acestei etape se obţin: modelul obiectual

detaliat, modelul dinamic detaliat şi modelul funcţional detaliat.

Scopul etapei este de a adăuga la modelul obiectual rezultat al etapelor de analiză şi

proiectare de sistem, detaliile de implementare necesare fie pentru generarea

automată de cod, fie pentru dezvoltarea ulterior fără generare automată. Când se

trece la etapa de implementare prin generare automată de cod, atunci modelul obiect

este singurul utilizat, 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, atributele şi

asocierile sunt implementate în structuri de date specifice. Modelele utilizate sunt

identice cu cele din etapa de analiză, diferenţa constând în faptul că acum clasele

sunt descrise din punct de vedere al implementării33. Astfel:

• modelul obiectelor determinat în etapa de analiză va fi acum rafinat prin

introducerea de noi clase (care păstrează rezultatele intermediare ale calculului),

operaţii (descoperite abia acum) şi atribute.

• modelul funcţional va descrie operaţiile pe care proiectantul trebuie să le

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

• modelul dinamic descrie felul în care sistemul răspunde stimulilor externi.

Structura de control a programului derivă din acest model. Fluxul de control din

cadrul unui program trebuie realizat fie explicit (printr-un planificator intern, care

recunoaşte evenimentele şi le transformă în apeluri de proceduri), fie implicit

(alegând algoritmii care realizează operaţiile în ordinea specificată de modelul

dinamic).

Rezultatul final al acestei etape îl constituie modelul obiectual, modelul dinamic şi

modelul funcţional rafinate şi detaliate. 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ă.

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

71

Se poate concluziona că deciziile de proiectare trebuie documentate pornind de la

modelul de analiză, prin adăugarea de detalii modelelor obiectual, dinamic şi

funcţional. Î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).

2.2.2.2. 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, apoi în etapa de proiectare

(de sistem obiectuală) când sunt detaliate şi completate şi până la implementarea de

cod. 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. De exemplu, 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ă.

În OMT atributele sunt reprezentate sub numele clasei, fiind menţionat numele

atributului şi opţional tipul său şi o valoare implicită.

Nume_Clasă NumeAtribut[:tip=valoare_implicită]

Obiectele se diferenţiază între ele prin valorile atributelor la un moment dat, care

constituie starea obiectului în acel moment. O categorie specială de atribute sunt

cele ale clasei. Un atribut al clasei, simbolizat prin „$” are o valoare comună clasei

de obiecte şi nu unei instanţe specifice.

NumeClasa /Nume atribut $Nume_atribut ....

72

Atributul unei clase va descrie o proprietate comună a tuturor obiectelor din clasă şi

nu proprietatea unei clase instanţe. El apare ca atribut al obiectelor din clasă având

pentru fiecare aceeaşi valoare. O categorie aparte de atribute sunt cele derivate a

căror valoare se calculează, reprezentate prin caracterul „/” plasat în faţa numelui.

Reprezentarea operaţiilor unei clase se face prin specificarea numelui operaţiei,

urmat opţional de parametrii şi de tipul rezultatului returnat. Toate aceste elemente

sunt trecute în partea inferioară a simbolului clasei, sub partea destinată atributelor.

NumeClasă ... NumeOperaţie(lista_argumente):tip_rezultat $Numeoperaţie

O operaţie este o funcţie sau o transformare aplicată obiectelor unei clase. O

modificare a unui obiect al unei clase acţionează asupra stării obiectului prin

transformarea/consultarea acesteia, asupra altui obiect aparţinător clasei sau asupra

obiectelor incluse altei clase.

Implementarea operaţiilor unei clase se numeşte metodă. O aceeaşi operaţie poate fi

implementată în mod variat în clase diferite. Această proprietate se numeşte

polimorfism. 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ă”.

Fiecare operaţie care se aplică unui anumit obiect devine parametru implicit. O

operaţie este recunoscută după semnătura sa (numele, lista de argumente şi tipul

returnat). Dacă operaţia poate fi accesată din afara clasei semnătura acesteia este

publică spre deosebire de implementare care nu are acest caracter.

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 ... 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 ... NumeOperaţie_n(lista_argumente_n):tip_rezultat_n

73

Conform metodologiei OMT pentru reprezentarea grafică a unei clase se utilizează

o formă dreptunghiulară având una sau trei regiuni. În cazul în care se apelează la

reprezentarea cu trei regiuni se menţionează numele clasei, atributele şi operaţiile

clasei. Reprezentarea cu o singură regiune conţine doar numele clasei.

Deoarece obiectele sunt abstractizate în clase atunci legăturile vor consta în asocieri.

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.

Asocierea claselor se realizează printr-un verb înscris deasupra liniei de conectare.

Spre exemplificare clasele „Factură” şi „Furnizor” vor fi conectate prin intermediul

asocierii „Emisă_de” care indică şi sensul acesteia:

Emisă_de Factură

Furnizor

Multiplicitatea - caracteristică a asocierii- reprezintă numărul de instanţe ale unei

clase care poate avea legături cu o instanţa a altei clase asociată. Multiplicitatea

poate fi: „unu la unu”, „unu la zero sau mai mulţi”, „unu la zero sau unu”, „unu la

unu sau mai mulţi”.

Corespunzător unei asocieri apare o valoare ataşată fiecărei legăturii. Există situaţii

în care este necesar ca o asociere să fie modelată drept clasă, identificată prin

reprezentarea:

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

Atunci când legăturile devin subiecţi ai unor operaţii apare asocierea modelată ca o

clasă. Î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ă, Nume_client preluate.

În figura 2.14 care exemplifică asocierea modelată ca o clasă, apare

„Suma_împrumutat” care nu aparţine clasei „Client” şi nici „Bancă”.

74

Figura 2. 14 Asociere „Împrumut” modelată ca o clasă

Operaţiile efectuate de „Împrumut” sunt de restituire sau amânare.

Presupunând intervenţia clasei „Investiţie”, apare evidentă asocierea ternară

„Împrumută”.

În figura 2.15 se sintetizează acordarea împrumutului de către bancă unui client

pentru anumite investiţii.

Figura 2. 15 Asociere „Client”-„Bancă”-„Investiţie”

Se observă că asocierea „Împrumută” nu poate fi divizată fără pierderi de informaţii

între clase.

Nume de rol reprezintă un concept prin care se identifică capetele unei asocieri. În

cazul în care o clasă are mai mult de o asociere, cu siguranţă că va avea roluri

diferite faţă de fiecare dintre acestea.

Spre exemplificare, utilajul achiziţionat de o societate reprezintă pentru ea un mijloc

de producţie, dar din punct de vedere al băncii care acordă creditul constituie o

garanţie.

Pot exista şi asocieri calificate reprezentate sub forma unu–mulţi sau mulţi–mulţi la

care calificatorul reduce multiplicitatea efectivă. Un calificator distinge seturile de

75

obiecte de la capătul „mulţi” al unei asocieri. Asocierea calificativă este exprimată

sub forma:

Nume_clasă1 Calificator Nume_clasă2

Generalizarea34 sub OMT presupune identificarea atributelor şi/sau a operaţiilor

comune claselor şi crearea superclase. 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.

Avantajele utilizării generalizării sunt: reutilizarea claselor create în cadrul altor

proiecte; 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ă.

Moştenirea în OMT este un mecanism care dă posibilitatea partajării atributelor şi

operaţiilor utilizând relaţia de generalizare. Se utilizează termenul de superclasă ,

clasă, subclasă cu elementele specifice operaţii şi atribute. Atributele şi operaţiile

superclasei nu mai apar în cadrul subclaselor ataşate, dar aparţin acestora prin

moştenire. Î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. 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.

În cazul în care o clasă este construită pentru a avea instanţe apare noţiunea clasă

concretă. Moştenirea poate fi ierarhizată pe mai multe nivele. Influenţa generalizării

apare evidentă prin preluarea atributelor şi operaţiilor elementare intersectate

obţinându-se atribute şi operaţii comune. În figura 2.16 am realizat reprezentarea

generală a moştenirii, observându-se că intervine şi mecanismul de specializare

descendent, cu o acţiune opusă celui de generalizare.

34 Doc’s submitted to World Scientific, www.geocities.com/siliconvalley/9219/resume.htm

76

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

Agregarea este un tip special de asociere între clasa „întreg” şi una sau mai multe

clase „parte”. Pot prezenta spre exemplificare, (figura 2.17) diagrama de asociere

între clase pentru „problema” de urmărire a clienţilor, comenzilor şi stocurilor.

Figura 2. 17 Monitorizarea simultană a clienţilor, comenzilor şi a stocurilor

Este evidentă agregarea client_cash client_virament în superclasa „client” care

execută operaţia „Achită”.

77

2.2.2.3. Modelul dinamic în accepţiunea metodei OMT

Evidenţierea temporală a succesiunii operaţilor este redată în modelul dinamic.

Conceptele utilizate sunt: eveniment, scenariu, stare, tranziţie, condiţie, operaţie.

Evenimentul reprezintă o situaţie de moment care precede sau succede logic unui

alt eveniment. Evenimentele similare pot fi grupate în clase de evenimente

caracterizate printr-un nume care indică structură şi un comportament comun. Două

evenimente care nu au efect unul asupra altuia sunt concurente.

Scenariul este secvenţă care include evenimentele care apar în timpul execuţiei

sistemului. Scenariul identifică obiectele emiţătoare, receptoare specifice fiecărui

eveniment. Reprezentarea cumulativă a secvenţei de evenimente şi obiecte se

realizează prin Diagrama de Trasare a Evenimentelor (DTE). Rolul diagramei este

de a indica actorii, evenimentele, obiectele şi reunirea acestora în scenarii.

Interpretarea DTE se produce de la bază spre partea superioară şi de la stânga la

dreapta. Pentru un eveniment al aplicaţiei se poate modela un singur scenariu, numit

principal, iar dacă evenimentul aplicaţiei este complex, pe lângă acesta se mai pot

modela mai multe scenarii alternative. Utilizând spre exemplificare (figura 2.18)

actorul „Client” şi obiectele „Comandă” până la ”Element_in_stoc” prin

evenimentele „creează comanda”, „citeşte client”, până la „cost total al comenzii”

se reprezintă DTE aferentă aplicaţiei Clienţi.

Figura 2. 18 DTE a aplicaţiei Clienţi

78

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. Unei stări i se asociază un element

valoric al obiectului care satisface o anumită condiţie.

Tranziţia reprezintă modificarea stării printr-un eveniment.

Condiţia este o funcţie booleană bazată pe valorile obiectului, validată pe o

perioadă de timp dacă apare evenimentul şi dacă tranziţia este adevărată.

Operaţia este ataşată stării şi tranziţiei şi descrie comportamentul unui obiect ca

răspuns la eveniment. Operaţiile pot fi de două feluri: activităţi sau acţiuni.

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.

Acţiunea este o operaţie instantanee, asociată unui eveniment, a cărei structură

internă nu este interesantă (nu este modelată ca o activitate cu eveniment de

început, de sfârşit şi eventual eveniment intermediar).

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

Tranziţie a Stărilor este un graf în care nodurile sunt stări, iar arcele sunt tranziţii

datorate unor evenimente. Toate tranziţiile din aceeaşi stare trebuie să corespundă la

evenimente diferite. Toate realizările unei clase partajează aceeaşi DTS, aşa cum

partajează şi aceleaşi caracteristici ale claselor.

Diagramele de Tranziţie a Stărilor pot fi structurate pentru a descrie sisteme

complexe. Structurarea se face prin generalizare şi agregare. Generalizarea permite

aranjarea structurii stărilor şi evenimentelor într-o ierarhie care să permită

moştenirea structurii şi a comportamentului comun, echivalentă cu concurenţa

stărilor.

79

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

Figura 2. 20 DTS pentru clasa de obiecte „Element_în_stoc”

Diagrama de Tranziţie a Stărilor poate fi privită în mod dinamic, descriind structura

de control a sistemului şi unde stările interacţionează unele cu altele prin

evenimente partajate.

2.2.2.4. 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, flux de date,

flux de control, actor, depozit de date35.

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

80

Procesul corespunde unei operaţii care indică „ce date de intrare sunt transformate”

şi „ce date de ieşire se obţin”.

Fluxul de date permite conectarea proceselor la intrarea unui alt obiect sau proces,

putând fi transmis în mai multe locuri.

Fluxul de control apare în diagrama de comunicare printr-un mesaj.

Actorul constă într-un obiect care produce sau consumă date, numit terminator

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ă. Actorii şi depozitele de date au comportament şi

utilitate diferită.

Diagramele de flux de date evidenţiază pe lângă fluxurile de date dintre terminatori,

procesele şi depozitele de date (interfaţa sistemului modelat cu mediul respectiv) şi

efectul proceselor asupra datelor care afectează execuţia unui proces36.

Procesele din DFD trebuie implementate ca operaţii ale obiectelor. Operaţiile se

regăsesc în: funcţiile matematice; ecuaţiile intrări-ieşiri; tabele de corespondenţă

intrări-ieşiri; tabele de decizie; pseudocod şi limbaj structurat.

Modelul funcţional este format din DFD-uri, adică din grafuri ale căror noduri sunt

procesele, iar arcele fluxurile de date şi de control.

În concluzie, relaţiile între cele trei modele sunt:

1. Modelul static descrie structura datelor pe care se va baza modelul dinamic şi

funcţional. Operaţiile din modelul obiectual corespund evenimentelor din

modelul dinamic şi funcţiilor din modelul funcţional.

2. Modelul dinamic descrie structura de control şi evidenţiază deciziile care

determină acţiuni, apelează funcţii şi schimbă valorile obiectelor.

3. Modelul funcţional conectează modelul static şi dinamic afectând valorile

atributelor din modelul obiect şi evidenţiind restricţiile.

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

81

2.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, Rumbaugh, Jacobson, Booch, Coad, Mellor etc.37) care propun

structuri ale sistemului în raport cu implementarea acestuia, implementarea fiind

privită ca o activitate secundară. Astfel la întrebarea fundamentală “Ce este

programarea, mai mult o artă, sau mai mult o ştiinţă”, s-a răspuns prin

primordialitatea explicită a arhitecturii sistemului. S-au dezvoltat

mecanisme/şabloane de proiectare(design patterns) şi diferite instrumente CASE

(Computer Aided Software Engeneering) de natură să asigure construirea unor

“modele” necesare proiectării. 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, manipulării şi vizualizarea

componentelor sistemului informaţional;

• UML este un limbaj pentru specificarea, vizualizarea, construcţia şi

documentaţia sistemelor software, acest limbaj fiind o colecţie omogenă de

practici engineering utilizabile pentru modelarea şi realizarea sistemelor

complexe.

• UML asigură înţelegerea semanticii sistemului prin materializarea deciziilor;

• UML nu conţine limitări impuse de metodologia/metoda de proiectare,

domeniul de activitate unde este utilizat sau mediul utilizat pentru dezvoltare

• UML realizează unificarea conceptelor orientate-obiect sub forma unui

standard de proiectare, prin care se asigură definiţia semanticii conceptelor

utilizate, notaţiile asociate acestora şi documentaţia necesară pentru

dezvoltarea unui sistem informatic;

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

82

• UML este folosit pentru modelarea sistemelor informatice de tip discret;

UML permite dezvoltarea ierarhiei de modele, vederi şi diagrame asigurând

„viaductul” modele vederi diagrame fişiere de cod sursă date/cazuri de

test. Vederile(Views) asigură prezentarea diferitelor aspecte ale sistemului modelat

sub forma unor abstractizări ce constau într-o secvenţă de diagrame38.

• UML utilizează elemente de modelare vizuale sub forma unor instrumente

CASE, care pot asigura următoarele funcţii:

o generarea modelelor de analiză, proiectare şi implementare;

o generarea vederilor asociate modelelor de mai sus, diagramelor specifice

vederilor;

o posibilitatea utilizării unor generatoare de cod prin care se poate asigura

implementarea sistemului realizat;

o posibilitatea includerii unor generatoare de rapoarte;

o posibilitatea prezenţei instrumentelor de tip reverse engineering etc.

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

38 Davidescu N. – Proiectarea Sistemelor Informatice prin limbajul UML, Editura ALL Back, Bucureşti

83

• UML permite dezvoltarea şi utilizarea modelării vizuale asigurând înţelegerea

semanticii sistemelor lumii reale cu participarea actorilor (analişti, programatori,

experţi, design-eri, implementatori etc.);

• UML utilizează termenul de model care realizează abstractizări ce descriu

problemele complexe specifice.

• UML foloseşte în etapa de modelare abordarea obiectuală care asigură

optimizarea realizării programelor.

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

• acest limbaj este considerat lingua franca pentru modelarea sistemelor

informatice;

• limbajul UML nu asigură în mod automat succesul în realizarea

sistemelor informatice însă permite ameliorarea şi îmbunătăţirea

multor elemente specifice modelării;

• acest limbaj de modelare conţine elementele modelului (model

elements) notaţiile modelului şi modul de utilizare expresia idiomatică

în interiorul tranzacţiilor.

2.3.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. Modelare optimală a arhitecturii sistemelor prin

UML îşi propune următoarele scopuri:

• asigurarea modelării sistemelor de orice tip, inclusiv a sistemelor software

orientate-obiect;

84

• fundamentează explicit „binomul” conceptual-soluţia operaţională;

• asigură definirea unui limbaj de modelare utilizat atât de factorul uman cât şi de

suportul fizic utilizat în realizarea 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, îmbunătăţite şi implementate prin tehnici adecvate

(TQM-Total Quality Management, BPR-Business Process Reengineering)

realizând sisteme informatice la nivel micro, mezo sau macroeconomic.

• permite definirea unor soluţii pentru diferite tipuri de sisteme (sisteme

informatice, tehnice, în timp-real, distribuite, software sau de “business”).

Fiecare aspect particular specific sistemului realizat va fi reflectat separat printr-o

diagramă/schemă aferentă sistemului construit. Aceste vederi vor asigura legături cu

limbajul de modelare specific UML.

Modelarea unui sistem este o sarcină extensivă şi de aceea acesta nu poate fi descris

printr-un singur graf definit integral, fără ambiguităţi, simplu şi inteligibil. Se va

descrie prin intermediul aspectelor: funcţionale care au în vedere structura statică,

dinamică şi interacţiunile; nonfuncţionale legate de coordonare/sincronizare,

fiabilitate, amplasament; organizaţionale legate de specificul activităţii.

Consider că orice sistem poate fi descris printr-un set de vederi, în care fiecare va

reprezenta o proiecţie completă a descrierii sistemului, inclusiv vederea particulară

a aspectelor sistemului. Mai mult, fiecare vedere particulară va fi descrisă printr-un

număr de diagrame care conţin informaţii şi diferite aspecte particulare ale

sistemului. În figura 2.22 am reprezentat vederile specifice cazului de utilizare

(Use-Case VIEWS) fiind o descriere generică a utilizării sistemului prin intermediul

funcţiilor.

85

Figura 2. 22 Proiecţia viziunilor cazului Use Case

Vederile au rolul de a descrie sistemul prin intermediul percepţiei actorilor externi

(client al sistemului, design-eri, dezvoltatori şi personal de testare) particularizându-se prin

intermediul diagramelor cazului de utilizare (use-case diagrams) şi eventual

diagrama activităţilor (activity diagrams). Actorul extern intracţionează cu sistemul

fiind un utilizator sau un sistem extern.

2.4. Comparaţii între metodele de proiectare

Având în vedere faptul că structura datelor, aplicaţiilor cât şi relaţiile dintre acestea

sunt mult mai puţin vulnerabile la schimbarea, comparativ cu funcţiunile,

organizarea sistemului în jurul obiectelor acordă o mare stabilitate de-a lungul

întregului ciclu de dezvoltare. Totodată proprietatea de încapsulare, specifică

orientării obiect, cât şi interfeţele care ascund implementările interne ale obiectelor,

constituie un înalt nivel de protecţie oferit sistemului astfel modelat.

86

Un alt avantaj oferit de abordarea orientată obiect îl constituie liniaritatea

procesului de dezvoltare a sistemului. 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, separarea dintre fazele ciclului de viaţă este mai puţin

perceptibilă.

În Object Modeling Technique obiectul modelat în timpul fazei de analiză este

utilizat şi în fazele de proiectare şi implementare, unde este rafinat şi extins

progresiv 39 . Procesul este liniar pentru că nu există discontinuităţi a notaţiilor

utilizate pe tot parcursul derulării activităţii. Această liniaritate permite reluarea

procesului de modelare iterativ, fiecare iteraţie adăugând sau clarificând anumite

detalii, obţinându-se în final un model consistent, cu grad redus de eroare.

Deosebiri substanţiale între diversele metodologii orientate-obiect nu există,

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, comportament, date.

O comparaţie între OMT şi unele dintre cele mai răspândite metode orientate obiect,

din punct de vedere al conceptelor utilizate, este prezentată în continuare:

Concepte OMT41

Rumbaugh OOAD42 Booch OOSE43

Jacobson Clasă * * Obiect

Clasă abstractă * * * Clasă concretă * * * Metaclasă * * *

Clasă generică Clasă parametrizată Obiect * * *

Obiect activ *

Obiect pasiv *

Obiect entitate *

Obiect de interfaţă *

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

87

Concepte OMT41

Rumbaugh OOAD42 Booch OOSE43

Jacobson

Obiect de control *

Obiect de interfaţă central

*

Cheie/identificator Cheie candidată Cheie

Atribut * Câmp *

Atribut derivat * *

Atribut al asocierii * *

Atribut calificator *

Atribut discriminator *

Restricţii pentru atribut * *

Se poate concluziona că metodologiile orientate-obiect analizate nu se deosebesc

substanţial, 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.

88

CAPITOL 2...................................................................................................................... 34 METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC............................................................................................................................................. 34

2.1. Cerinţe generale în utilizarea unei metode de proiectare a sistemului informatic.... 34 2.1.1. Parametrii specifici de performanţă pentru sistemele informatice .................... 36 2.1.2. Necesitatea şi structura procesului de evaluare a contabilităţii informatizate... 41

2.2. Metodele de concepţie şi de realizare a unui sistem informatic ............................... 45 2.2.1. Caracterizarea metodei Merise .......................................................................... 50 2.2.2. Metoda OMT de proiectare a sistemelor informatice........................................ 62

2.2.2.1. Etapele ciclului de realizare a unui proiect în abordarea orientată–obiect . 66 2.2.2.2. Modelul obiect în metodologia OMT......................................................... 71 2.2.2.3. Modelul dinamic în accepţiunea metodei OMT......................................... 77 2.2.2.4. Modelul funcţional al metodei OMT.......................................................... 79

2.3 Unified Modeling Language – cale de reunire a conceptelor orientate-obiect.......... 81 2.3.1 Avantajele oferite de UML................................................................................. 83 2.3.2 Obiectivele fundamentale ale UML ................................................................... 83

2.4. Comparaţii între metodele de proiectare .................................................................. 85

Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiţiei 36 Figura 2.2 Legăturile aferente actului decizie ..................................................................... 41 Figura 2.3 Criteriile de analiză a unei situaţii...................................................................... 43 Figura 2.4 Evaluarea compartimentului financiar–contabil prin metoda scenariilor .......... 45 Figura 2.5 Diagrama fluxurilor de date pentru Clienţi ........................................................ 46 Figura 2.6 Reprezentarea domeniilor unui organism economic.......................................... 51 Figura 2.7 Funcţii şi activităţi într-un sistem operant.......................................................... 52 Figura 2.8 MERISE – Ce-cum-cu cine se realizează?......................................................... 55 Figura 2.9 Studiu prealabil în cadrul metodei Merise ......................................................... 56 Figura 2.10 Traseul „sarcini-prelucrări”, „date”, mesaje”................................................... 61 Figura 2. 11 Circuitul analiză-modelare evenimente........................................................... 66 Figura 2. 12 Obţinerea modelului de analiză....................................................................... 67 Figura 2. 13 Forma generală de reprezentare a unei asocieri modelate ca o clasă.............. 73 Figura 2. 14 Asociere „Împrumut” modelată ca o clasă...................................................... 74 Figura 2. 15 Asociere „Client”-„Bancă”-„Investiţie” ......................................................... 74 Figura 2. 16 Reprezentarea generală a „moştenirii”............................................................ 76 Figura 2. 17 Monitorizarea simultană a clienţilor, comenzilor şi a stocurilor..................... 76 Figura 2. 18 DTE a aplicaţiei Clienţi................................................................................... 77 Figura 2. 19 Forma generală a unei DTS............................................................................. 79 Figura 2. 20 DTS pentru clasa de obiecte „Element_în_stoc” ............................................ 79 Figura 2. 21 Ierarhia de modele, vederi şi diagrame utilizate de UML............................... 82 Figura 2. 22 Proiecţia viziunilor cazului Use Case ............................................................. 85