34

CAPITOL 2
METODE MODERNE DE PROIECTARE A UNUI
SISTEM INFORMATIC


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

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

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

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

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

37
a) centru de costuri unde utilizatorii decideni i managerul i asum
responsabiliti sporite n gestionarea a costurilor, iar performanele vor fi judecate
prin capacitatea de a micora ecarturile raportate la costurile previzionale, de a
sporii productivitatea i de a propune soluii (aciuni) generatoare de profit.
b) centru de profit scoate n relief faptul c dei profitul obinut de contabilitatea
informatizat nu este autentificabil n sine, trebuie s considerm c ea este un
prestator de servicii ce se adreseaz unor beneficiari bine identificai.
Opinia mea este c profitul mediului contabil este indus de beneficiile obinute de
celelalte segmente ale firmei sau de aceasta ca urmare a folosirii produselor
informatice. Rezultatele obinute pot fi apreciate, extrem de clar prin relaia:
numr de lucrri (aspect cantitativ), timp coninut lucrare (aspect calitativ).
c) centru de investiie vizeaz contabilitatea informatizat care trebuie s ctige
autonomie n efectuarea investiiilor (informatice) i apoi se impune s le justifice.
Pentru zona contabil informatizat putem vorbi de reliefarea unor plusuri
cantitative (economice) i calitative (politice). n legtur cu primul aspect consider
c viteza de circulaie a informaiei, dar i capacitatea ei de adaptare se pot constitui
n resurse importante. Remarc dou faete ale acestui tip de performan:
Ctigurile directe de productivitate permit executarea unei aceleiai
atribuii (decizii), cu mijloace reduse. De exemplu: o suprafa ocupat mai
mic, utilizatorii decideni mai puini, costuri ale hardului, softului sau reelei
mult diminuate.
Creterea volumul activitilor financiar-contabile, unde informaia
suplimentar poate avea un impact pozitiv asupra domeniului contabil
informatizat, dar numai n msura n care are desfacerea asigurat.
Performanele politice (calitative) sunt mult mai greu de evideniat sau mai
ales de comensurat.
Consider c cele mai importante obiective ale unei metode sunt:
flexibilitatea sistemului;

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

39
- standardizare - msura n care sunt stabilite reguli i proceduri generale pentru a
defini sarcinile de executat i a controla aplicarea lor. Informatizarea contabilitii
duce la crearea de noi proceduri, le elimin pe cele redundante sau neutilizate.
- formalizarea - nu este legat implicit de noile tehnologii, depinznd uneori de
gradul de pregtire al utilizatorilor decideni.
- centralizarea - vizeaz importana acordat lurii deciziilor de ctre manager,
urmrindu-se s nu se accentueze fenomenul birocratic. n categoria criteriilor
organizaionale de apreciere a performanelor segmentului financiarcontabil
informatizat cred c se impune a fi inclus i msurarea gradului de schimbare. n
acelai timp este important i cunoaterea atitudinii utilizatorilor decideni, n
vederea anticiprii unei eventuale reacii de respingere (putndu-se folosi n acest
sens metodologia CRIG).
c) criteriile economice - utilizarea lor are n vedere tipul proiectului i etapa
procesului de decizie. Dup prerea mea exist dou mari categorii de repere n
stabilirea dimensiunii contabilitii informatizate: unele ce i propun s urmreasc
costurile i avantajele (metode a posteriori) i altele care doresc s efectueze
demersuri pentru o analiz complex n vederea alegerii investiiei (metode a
priori).
Consider c, pentru zona contabilitii informatizate, putem pune n eviden mai
multe praguri i msurri ale eficienei:
coeficientul eficienei globale a sistemului informatic financiar-contabil
(Keg):
Keg = (Ec + As) / (Chi + Che) unde:
Ec - economii rezultate prin introducerea tehnologiilor informatice i de
comunicaie.
As - acumulrile 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 cretere a eficienei sistemelor informatice este reducerea
cheltuielilor prin:
utilizarea de elemente standardizate i tipizate;
elaborarea bugetului informatic i controlul realizrii indicatorilor prevzui;
mbuntirea parametrilor de exploatare a aplicaiilor informatice.
Cu ct durata de recuperare a cheltuielilor cu caracter informatic (ce privesc
echipamentele, programele, reelele) este mai mic, cu att standardele vor fi mai
mari i se vor nregistra acumulri suplimentare (implicit profit net).
durata de recuperare a cheltuielilor este invers proporional fa de
coeficientul eficienei globale.(Dr):
Dr = 1/Keg
Se va avea n vedere totalitatea cheltuielilor (de investiie, de exploatare) iar
sistemul informatic se va aprecia ca fiind eficient dac Keg >1, iar Dr <5.
Performanele sunt direct legate i de dimensionarea optim a sistemului informatic
financiar contabil aa cum este prezentat mai jos:
Caracteristicile sistemului Efectele economice
Abordare orientat client Efect de anvergur (eficiena partajrii resurselor i
eficacitatea utilizatorilor decideni)
Baz comun a prelucrrilor i
comunicaiei
Efect de anvergur (cost al sistemului integrat <
costurile a dou neintegrate)
Evoluie progresiv Reducerea efectului de complexitate
Portabilitate Efect de anvergur (partajarea aplicaiilor pe
platforme mai eficiente)
Convivialitate Efecte de nvare i experien (reducerea costului
de pregtire)
Performana sistemului:
- optimizarea prelucrrilor
- optimizare traficului
Efect de anvergur (diminuarea costului de
prelucrare i transmitere)
Remarc anumite forelor motrice care ajut la formarea rezultatului sistemului
informatic financiarcontabil: producia informaional i modalitile de

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

2.1.2. Necesitatea i structura procesului de evaluare a contabilitii
informatizate

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

Figura 2.2 Legturile aferente actului decizie
Operaia de evaluare n cadrul sistemului informatic financiar-contabil va ine cont
de trei elemente fundamentale:
resursa uman;
raporturile de putere;
referenialul.

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

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

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

Figura 2.3 Criteriile de analiz a unei situaii
Fluiditatea catartic este o noiune care a fost pus n eviden de cercettorul
Bruno Lussato i se refer la mobilitatea mai mult sau mai puin important a
transferului de rezonan a unei reprezentri R spre o reprezentare RI, ignorat pn
Paradigm
Evaluare
criterii
cantitative
Evaluare
criterii
calitative
Valorizare
soluii
decideni
Parametrii
obiectivi
Gndire
decideni
Restricii

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

45


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

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

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

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

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

47
Metodele sistemice permit vizualizarea i nelegerea organizrii datelor. Aceste
metode se compun din abstractizri care prezint lumea real ca pe o colecie de
entiti i de legturi, stabilite ntre acestea. Majoritatea permite definirea de
restricii descriind aspectele statice, dinamice sau chiar temporare ale entitilor. n
aceast calitate ele constituie formalisme lizibile n cadrul specificaiilor de nevoi.
Dou metode constituie referina de reprezentare semantic: metoda individual
18

care va fi integrat Merise i metoda entitaterelaie
19
.
Amintesc printre metodele sistemice pe cele de concepie n timp real care asigur
funcionarea corect n funcie de rezultatele produse prin sistem i de momentul la
care ele sunt produse. Acestea reprezint oarecum un sistem de stimuli/rspuns;
stimulii fiind generai de captatori sau de acionari. Atunci cnd stimulii sunt
aperiodici se poate concepe un sistem ca un ansamblu de procese paralele care
coopereaz de o manier n care transfer controlul componentei apropiate, de la
recepia unui stimul. Se disting dou clase active n timp real:
sistemele de urmrire-control;
sistemele de cumulare de date.
Sistemele de urmrire i control cerceteaz n permanen numrul de captatori, i
n funcie de valoarea lor, declaneaz aciuni care eficientizeaz acionarii (de
exemplu sistemele de alarm antifurt din imobile).
Sistemele de cumulare de date culeg datele captate pentru procesare i analiz.
Perioadele procesului de achiziie i cele ale procesului de procesare nu sunt n
armonie. Astfel apar diferene de vitez dictate de recurgerea la un mijloc de stocare
(tampon). Sistemul este organizat dup modelul productorconsumator cu
mecanisme de excludere mutual, pentru a evita cazul unde productorul i
consumatorul de date acced, n acelai timp, la elementul tampon. Aceste metode
recurg la diverse formalisme, de remarcat fiind cele din reele Petri pentru aspectul
dinamic care au fost dezvoltate de formalizri specifice.

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

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

49
Modelul obiectelor are rolul de a descrie obiectele care intervin n problema
de rezolvat i relaiile dintre ele. Modelul obiectual reprezint descrierea
structurii statice a obiectelor, claselor de obiecte, a operaiilor i atributelor,
precum i a legturilor i a relaiilor dintre ele.
Modelul dinamic are rolul de a descrie strile pe care le poate avea un obiect
i evenimentele la trecerea dintr-o structur n alta. Modelul dinamic descrie
interaciunea dintre obiecte i este focalizat pe aspecte ce se schimb n timp,
deoarece orice obiect are un ciclu de via cu un punct de pornire i unul de
sfrit. Modelul dinamic descrie acest ciclu de via, ce se ntmpl de-a
lungul su i cum este influenat obiectul.
Modelul funcional are rolul de a descrie prelucrrile i fluxurile de date.
Modelul funcional prezint transformrile valorilor datelor preciznd sursa
i destinaia lor.
Avantajele oferite de metoda OMT sunt valorificate pe deplin n proiectarea i
realizarea de sisteme informatice care trebuie s rspund unor noi cerine i anume:
Reprezentarea complex a realitii (firm, clieni, produse, servicii, etc.);
Informaia gestionat n cadrul unui sistem informatic are tendina de cretere
n complexitate, iar manipularea ei trebuie s fie ntr-o form uor de perceput
de ctre utilizatorul final;
Sistemele informatice realizate trebuie s fie flexibile n raport cu modificarea
structurilor de date i trebuie s evolueze natural n timp, urmnd astfel
evoluia organismului economic, bancar, financiar pe care l deservete;
Sistemele informatice evolueaz spre abordri multimedia care combin text
cu foi de calcul, grafice, animaie i voce.
Majoritatea metodelor orientate obiect utilizeaz reguli sau operaii semantice:
generalizarea/specializarea, agregarea/descompunerea, combinate cu motenirea i
ncapsularea.


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

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

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

52

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

53
Reamintesc n acest context dou mari viziuni de concepie a sistemelor
informatice: abordarea ascendent cunoscut mai simplu sub numele de bottom-up
i abordarea descendent sau topdown.
Abordarea ascendent are ca punct de plecare nivelul operaional (aflat la baza
piramidei ierarhice) i prin realizarea informatizrii la fiecare nivel n parte, se
ajunge la un sistem informatic care poate atinge nivelul punctul extrem al piramidei.
Este deci o consolidare a unui proiect care ne permite s avem n faza final,
informatizarea complet a unui sistem informaionalorganizaional specific unui
organism economic supus analizei. Aprtorii acestei abordri avanseaz
argumentul c este mai bine s acionezi progresiv, dect s mizezi pe ipoteza
nerealist c un proiect global poate fi inut permanent la zi.
23

Abordarea descendent const n a cobor, pe scara piramidei ierarhice, pn la baz
i realiznd totodat i o analiz. Aceast viziune consider c un anumit domeniu
este compus din pri corelate ntre ele i cu legturi cu exteriorul, caracteristic
pentru toate sistemele informaionale.
Este mai bine s se creeze i s se realizeze din start un sistem informatic care s
in cont de obiectivele planificate, abordate ntr-o maniere global, dect s se
ncerce a se integra a posteriori, subsisteme informatice independente. MERISE este
o metod de concepie de sisteme informatice care se poate nscrie n aceast
abordare descendent.
n esen, filosofia MERISE se poate constitui sub forma unui ghid de abordare a
unui sistem informatic pus n eviden sub forma sintetic utiliznd o semantic
bazat pe cuvinte cheie ct mai sugestive. MERISE poate realiza sisteme
informatice din mai multe perspective:
MERISE perspectiv sistemic. n aceast privin intereseaz totalitatea
problemelor nainte de a da o soluia global, astfel spus ntregul este altceva
dect suma prilor.

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

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

24
Reix R. Systemes dinformation 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 fcut? Etape
Subetape
Cum se face? - (Legturi, Reguli)
Cu cine se face? - (Participani)
n figura 2.8 am reprezentat cerinele la care rspunde metoda MERISE constatnd
interdependenele externe, interne i fundamentale.

Figura 2.8 MERISE Ce-cum-cu cine se realizeaz?
Realizarea studiului prealabil i a celui de detaliu nu presupun neaprat crearea de
elemente noi, singurele eforturi fiind acelea de a adapta metodele de realizare deja
folosite la etapele propuse.
Sub form tabelar prezint etapele acestei metodei sintetiznd rezultatele fiecrui
stadiu.
STUDIU FUNCIUNI REZULTAT DECIZIA
dup studiu
Studiu
prealabil
Studiu situaiei actuale
Degajarea unui
subansamblu reprezentativ
Dosar de opiuni coninnd
mijloacele de punere n
lucru
Decizia
pentru o
soluie
Studiu Studierea detaliat a Specificaii funcionale Acordul

56
STUDIU FUNCIUNI REZULTAT DECIZIA
dup studiu
detaliat diferitelor domenii pentru
soluia reinut
externe generale i
detaliate
utilizatorilor
Realizarea Studiul tehnic
Realizarea programelor
Sistem de criterii de pia
privind jocul de prob al
utilizatorilor
Recepia
provizorie
Punerea n
lucru
Studiul de ansamblu al
problemelor legate de
utilizarea noilor funciuni
automate
Sistem implantat n
ambientul real i
funcionnd n regim
normal.
Recepia
definitiv
n momentul descompunerii subansamblul reprezentativ (SREP) pe subproiecte
apare evident soluia chiar nainte de a se studia adecvarea specificaiilor
funcionale pentru nevoile utilizatorilor cu compatibilitatea ntregului alctuit
din specificaii funcionale, tehnice i restricii financiare definite nainte de studiul
prealabil.
n figura 2.9 reprezint iniierea i derularea pailor care privesc studiul prealabil.

Figura 2.9 Studiu prealabil n cadrul metodei Merise
Metoda MERISE n contextul unei uniti bancare pentru un subansamblu
reprezentativ pune n eviden unul sau mai multe subproiecte care vor intra sub
incidena studiului prealabil.
n cadrul studiului prealabil se pot distinge mai multe subetape
26
:
iniializare;

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

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

Alegere Obiect
descris
Nivel de
abstracie
Exemplu de
modele
Ce se
dorete
s se fac
n fond
GESTIUNE Date
Relaii
Reguli de
gestiune
nlnuiri
de
prelucrri
CONCEPTUAL MODELUL
CONCEPTUAL AL
DATELOR
(invariant static)
MODELUL
CONCEPTUAL AL
PRELUCRRILOR
(invariant dinamic)
Cine face
Cu ce i
Cnd
ORGANIZAIONAL
Oameni
Maini
Reele
diferite
Repartiie
geografic
LOGIC SAU
ORGANIZAIONAL
MODELUL LOGIC
DE DATE
MODELUL LOGIC
DE PRELUCRARE
Cum se
face
TEHNIC Entiti
Programe
Proceduri
FIZIC
SAU
OPERAIONAL
MODELUL FIZIC
AL DATELOR
MODELUL FIZIC
AL
PRELUCRRILOR
Pot concluziona c la ntrebarea cum se face? din punct de vedere tehnic prin
modelul fizic al datelor, modelul fizic al prelucrrilor pot rspunde prin entiti
programe proceduri. La ntrebarea cine, cu ce i cnd? din punct de vedere

58
organizaional rspunde modelul logic al datelor i cel al prelucrrilor. La
interogarea ce se dorete a se realiza? datele, relaiile, regulile de gestiune,
nlnuirile de prelucrri apar ca rspuns dedus din modelul conceptual al datelor i
al prelucrrilor.
n continuare supun ateniei sintetiza nivelelor de abstractizare corelate cu
ansamblul date-prelucrri.
DATE PRELUCRRI
CONCEPTUAL Modelul conceptual al datelor
MCD
- Concepte fundamentale
- Relaii semantice
Modelul conceptual al prelucrrilor
MCP
- Descrierea macroscopic (noiunea
de proces)
LOGIC Modelul logic de date
MLD
Integrarea restriciilor de
organizare
- Traducerea n SGBD
entitate
relaie
instan (realizare)
Modelul logic al prelucrrilor
MLP
- Integrarea alegerii opiunii
- Repartiia om - main
- Timp real timp diferit
Desfacerea proceselor proceduri
Faze sarcini
FIZIC Modelul fizic al datelor
MFD
Descrierea bazelor de date
Noiuni de nregistrare
Modelul fizic al prelucrrilor
MFP
Descrierea programelor
Descrierea procedurilor
Corelnd figura 2.8 referitoare la Merise Ce-cum-cu cine se realizeaz?,
nivelurile de abstracie, modelele rezultate, deduc i prezint urmtoarele expresii:
Viziunea exterioar: model extern=o vedere a unui utilizator
=
Ansamblul informaiilor operaionale pentru o prelucrare
FORMALISM
=
Model individual
Conceptele adecvate pentru fiecare nivel al modelrii datelor i prelucrrilor sunt
caracterizate printr-un grad mare de generalitate, dar n acelai timp i de relevan
surprinznd aspecte semnificative din realitatea supus modelrii.

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

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

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

Figura 2.10 Traseul sarcini-prelucrri, date, mesaje
Problematica modelului organizaional este sintetizat n tabelul urmtor:
Problematica MOP Problematica MOD Problematica
MOC
- Repartizarea prelucrrilor pe centre,
uniti i posturi de lucru
- Caracterizarea sarcinilor: posturile
raportate, gradul de automatizare,
termenul de rspuns, modul de
funcionare, regulile i procedurile
aplicabile, frecvena, durata, capacitatea
- Repartizarea datelor:
pe centre, uniti i
posturi de lucru
- Volumetrie
- Istoric
- Securitate
- Schimburile de
mesaje ntre centre
Modelarea privete sistemul de informaii organizaional care se finalizeaz prin
confruntarea modelelor; aplicnd urmtoarele tehnici: abordarea participativ,
abordarea printr-o gril de coeren MCD MOP MOD, machetare i validarea
MCD modele externe. Modelele externe
28
privesc datele drept mesajele legate la
evenimenterezultate. 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 delimitrile de modele care apar utiliznd percepia de
gestionare (modele organizaionale) i viziunea specialistului informatic (modelele
logice i fizice).
n cele ce urmeaz supun ateniei sinteza reunirii modelelor logice i fizice ale
datelor, prelucrrilor, comunicaiei.
Problematica MLP i al MFP Problematica MLD i
al MFD
Problematica MLC i
al MFC
- Repartizarea prelucrrilor
informatizate: centre, uniti
logice de prelucrare.
- Modularizare
- Transformare MOD
dup tipul SGBD
- Dimensiunea MLD
- Optimizarea
- Mesaje ntre centre
prin magistrale
informatice
Concluzionnd ideile prezentate pe parcursul acestui subcapitol, afirm c utilizarea
metodei MERISE n contextul cadrului metodologic al conducerii proiectelor
informatice este oportun deoarece:
determin limitele nivelelor de preocupare (conceptual, logic, fizic);
permite exprimarea unor concepte complementare legate de conducerea
studiilor detaliate;
propune un plan de lucru detaliat pentru derularea fiecrei etape pentru a
facilita conducerea proiectelor n concepia sistemelor informatice;
furnizeaz documentele tip ISO pentru constituirea documentaiei aferente
fiecrei etape.
Se poate afirma c este o metod deschis, susceptibil s se integreze ntr-un
cadru metodologic mai larg.

2.2.2. Metoda OMT de proiectare a sistemelor informatice

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

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 instane ale unei clase n interiorul unei
ierarhii. Noiunea de obiect
29
este dependent de implementarea metodei n
limbajele de nivel nalt cum ar fi: ADA, MODULA, SMALLTALK, C++, CLOS
(Common Lisp Object System).
Aceast metod are n vedere trei aspecte importante:
abstractizarea realitii, ceea ce nseamn c pentru aceeai problem se pot
crea mai multe modele care s focalizeze diferite aspecte;
scopul modelului este s se focalizeze ceva cunoscut;
comunicarea ntre membrii echipei de analiz-proiectare i ntre utilizatori.
Metodele orientate obiect propun modelarea concomitent a datelor i a funciilor
obinnd ierarhii de clase de obiecte care nglobeaz att datele ct i
comportamentul, spre deosebire de modelarea datelor separat de a funciilor,
element structural al metodelor tradiionale.
Comparativ cu metodele tradiionale, abordarea orientat-obiect mut centrul de
greutate al soluionrii problemei n faza de analiz, fapt compensat printr-un minim
de efort necesar a fi depus n faza de implementare. O bun nelegere a cerinelor
problemei reale va conduce la construirea unui model fiabil, adaptabil, care suport
uor modificrile ulterioare.
Metodele obiect integreaz modelarea de structur cu cea comportament
30
. Obiectul
reprezint o entitate (real sau abstract) a lumii supuse modelrii, caracterizat prin
identitate, stare i comportament. n fapt, obiectul reprezint un element
identificabil, concret sau abstract, caracterizat prin structur, atributele i metode
proprii.

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

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

31
Rumbaugh's Method, www.iconixsw.com/Rumbaugh.html
32
Castellani X. - Mthodologie gnrale danalyse et de conception des systmes dobjects. 1. Lingnierie
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 Tranziie a Strilor);
pentru modelul funcional se apeleaz la DFD (Diagrama de Flux de Date -
Data Flow Diagram); DCC (Diagrama de Comunicare a Claselor, CCD
Class Comunication Diagram); DGM (Diagrama de Generalizare a
Mesajelor - MGD Message Generalization Diagram).
n reprezentarea ciclului de via al unui proiect se utilizeaz mai multe modele, dar
flexibilitatea metodelor orientate-obiect permite lucrul ntr-un ciclu de via
spiral. Ciclul de via spiral sau modelul spiral, spre deosebire de modelul n
cascad, specific metodelor structurate, presupune faptul c doar o parte a
modelului trebuie s fie finalizat nainte de a trece la faza urmtoare. Aceasta
nseamn c versiunii pariale ale sistemului pot fi livrate n timp scurt, evaluate i
validate de ctre utilizator, proiectantul realiznd extrem de rapid analiza pentru
completarea modelelor.
Feed-back-ul permite gsirea de soluii convenabile, iar flexibilitatea modelelor
orientateobiect permite armonizarea cerinelor utilizatorului cu soluiile propuse de
echipa de realizatori. Modelul n cascad, chiar n varianta care cuprinde iterarea
fazelor, permite detectarea i corectarea erorilor nainte de trecerea la faza
urmtoare i impune ca n fiecare faz s se produc un document i produse valide.
Corectarea erorilor n fazele urmtoare celei n care s-au produs este foarte
costisitoare (timp, efort), aducnd importante prejudicii prin faptul c utilizatorul
trebuie s atepte pn la sfritul implementrii pentru a vedea dac sistemul
corespunde necesitilor exprimate.

66

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

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

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

67

Figura 2. 12 Obinerea modelului de analiz
O reprezentare sintetic a activitilor i rezultatelor este supus ateniei n tabelul
urmtor:
Faze i activiti Mod de reprezentare Descriere
A.1. Analiza i modelarea evenimentelor
Scrierea declaraiei
problemei (formularea
problemei)
Text liber Declaraia problemei (de ctre client
sau elaborator)
Analiza evenimentelor
problemei
Diagrama de Trasare a
Evenimentelor (DTE)
Scenarii de evenimente pentru
evenimentele complexe ale aplicaiei
Modelarea
evenimentelor
Diagrama de Comunicare
ntre Clase (DCC)
Diagrama de
Generalizare a Mesajelor
(DGM)
Diagrama de Comunicare ntre Clase
cu mesaje i interaciunile dintre
clase
Diagrama de Generalizare a
Mesajelor specific interaciunii
ntre clase
A.2. Construirea modelului de analiz
Definirea modelului
obiectual
Diagrama de Asociere a
Claselor (DAC)
Model de obiecte cu clasele
aplicaiei atributele, operaiile i
asocierile lor.
Definirea modelului
dinamic
Diagrama de Tranziie a
Strilor (DTS)
Modelul dinamic (DTS) pentru clase
importante i modelul de obiecte
care ncorporeaz rezultate din DTS
Definirea modelului
funcional
Diagrama de Flux de
Date (DFD)
Modelul funcional cu
funcionalitatea operaiilor complexe
i completarea lor n DAC
Reiterarea i
verificarea
Verificri Se completeaz modelul de obiecte
din celelalte iteraii i se verific
consistena

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

69

Faze i activiti Modaliti 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 stabilete 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
nlocuii cu subieci, 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 acelai nume.
1.2. Definirea interfeelor 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
acelai 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 nct
s asigure satisfacerea cerinelor de performan
i minimizarea comunicrii
1.5. Alegerea strategiei de
baz pentru implementarea
datelor memorate
Text Se aleg structurile de date, fiierele sau bazele
de date corespunztoare
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 condiiilor
limit
Text
1.9. Stabilire prioriti
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, proiectndu-se algoritmi i implementndu-se asocierile. Se realizeaz

70
gruparea claselor n superclase pentru uurarea implementrii i pentru
mbuntirea performanelor. n urma acestei etape se obin: modelul obiectual
detaliat, modelul dinamic detaliat i modelul funcional detaliat.
Scopul etapei este de a aduga la modelul obiectual rezultat al etapelor de analiz i
proiectare de sistem, detaliile de implementare necesare fie pentru generarea
automat de cod, fie pentru dezvoltarea ulterior fr generare automat. Cnd se
trece la etapa de implementare prin generare automat de cod, atunci modelul obiect
este singurul utilizat, una din activitile etapei de proiectare obiectual
Plecnd de la aceste obiective n etapa de proiectare obiectual operaiile
identificate n etapa de analiz sunt transpuse n algoritmi iar clasele, atributele i
asocierile sunt implementate n structuri de date specifice. Modelele utilizate sunt
identice cu cele din etapa de analiz, diferena constnd n faptul c acum clasele
sunt descrise din punct de vedere al implementrii
33
. Astfel:
modelul obiectelor determinat n etapa de analiz va fi acum rafinat prin
introducerea de noi clase (care pstreaz rezultatele intermediare ale calculului),
operaii (descoperite abia acum) i atribute.
modelul funcional va descrie operaiile pe care proiectantul trebuie s le
implementeze. n timpul proiectrii acesta va alege algoritmii de implementare a
unei operaii i va descompune operaiile mai complexe n operaii mai simple.
modelul dinamic descrie felul n care sistemul rspunde stimulilor externi.
Structura de control a programului deriv din acest model. Fluxul de control din
cadrul unui program trebuie realizat fie explicit (printr-un planificator intern, care
recunoate evenimentele i le transform n apeluri de proceduri), fie implicit
(alegnd algoritmii care realizeaz operaiile n ordinea specificat de modelul
dinamic).
Rezultatul final al acestei etape l constituie modelul obiectual, modelul dinamic i
modelul funcional rafinate i detaliate. Deciziile de proiectare luate trebuie
susinute de o documentaie adecvat care alctuiete o extensie a cerinelor de
documentaie realizate n etapa de analiz.

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

71
Se poate concluziona c deciziile de proiectare trebuie documentate pornind de la
modelul de analiz, prin adugarea de detalii modelelor obiectual, dinamic i
funcional. n acest scop se vor folosi construcii specifice de implementare:
pointeri (pentru modelul obiectual) pseudocod structurat (pentru modelul dinamic)
i expresii funcionale (pentru modelul funcional).

2.2.2.2. Modelul obiect n metodologia OMT
Cele trei tipuri de modele recomandate de OMT sunt utilizate ncepnd din etapa de
analiz cnd se realizeaz o prima versiune a acestora, apoi n etapa de proiectare
(de sistem obiectual) cnd sunt detaliate i completate i pn la implementarea de
cod. Simbolul utilizat n metodologia OMT pentru reprezentarea unei clase de
obiecte este:
Nume_Clas
Atribute
Operaii
Numele clasei trebuie s fie sugestiv n contextul aplicaiei i s identifice clasa n
mod unic. De exemplu, pentru o aplicaie de eviden a facturilor pentru fiecare
document utilizat se definete un obiect care conine caracteristicile facturii
relevante pentru aplicaia informatic.
n OMT atributele sunt reprezentate sub numele clasei, fiind menionat numele
atributului i opional tipul su i o valoare implicit.
Nume_Clas
NumeAtribut[:tip=valoare_implicit]
Obiectele se difereniaz ntre ele prin valorile atributelor la un moment dat, care
constituie starea obiectului n acel moment. O categorie special de atribute sunt
cele ale clasei. Un atribut al clasei, simbolizat prin $ are o valoare comun clasei
de obiecte i nu unei instane specifice.
NumeClasa
/Nume atribut
$Nume_atribut
....

72
Atributul unei clase va descrie o proprietate comun a tuturor obiectelor din clas i
nu proprietatea unei clase instane. El apare ca atribut al obiectelor din clas avnd
pentru fiecare aceeai valoare. O categorie aparte de atribute sunt cele derivate a
cror valoare se calculeaz, reprezentate prin caracterul / plasat n faa numelui.
Reprezentarea operaiilor unei clase se face prin specificarea numelui operaiei,
urmat opional de parametrii i de tipul rezultatului returnat. Toate aceste elemente
sunt trecute n partea inferioar a simbolului clasei, sub partea destinat atributelor.
NumeClas
...
NumeOperaie(lista_argumente):tip_rezultat
$Numeoperaie
O operaie este o funcie sau o transformare aplicat obiectelor unei clase. O
modificare a unui obiect al unei clase acioneaz asupra strii obiectului prin
transformarea/consultarea acesteia, asupra altui obiect aparintor clasei sau asupra
obiectelor incluse altei clase.
Implementarea operaiilor unei clase se numete metod. O aceeai operaie poate fi
implementat n mod variat n clase diferite. Aceast proprietate se numete
polimorfism. De exemplu clasa Comand_marf are operaia Emite, care va fi
implementat n mod diferit fa aceeai operaie care aparine clasei Factur.
Fiecare operaie care se aplic unui anumit obiect devine parametru implicit. O
operaie este recunoscut dup semntura sa (numele, lista de argumente i tipul
returnat). Dac operaia poate fi accesat din afara clasei semntura acesteia este
public spre deosebire de implementare care nu are acest caracter.
Operaia clasei utilizeaz simbolul $ n faa numelui i are forma general:
NumeClas
NumeAtribut_1:tip_1=valoare_implicit_1
NumeAtribut_2:tip_2=valoare_implicit_2
...
NumeAtribut_m:tip_m=valoare_implicit_m
NumeOperaie_1(lista_argumente_1):tip_rezultat_1
NumeOperaie_2(lista_argumente_2):tip_rezultat_2
...
NumeOperaie_n(lista_argumente_n):tip_rezultat_n

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

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

Figura 2. 13 Forma general de reprezentare a unei asocieri modelate ca o clas
Atunci cnd legturile devin subieci ai unor operaii apare asocierea modelat ca o
clas. n cazul n care se realizeaz asocierea ntre Client-Banc apare evident
asocierea mprumut modelat ca o clas avnd n structur atributele
Nume_banc, Nume_client preluate.
n figura 2.14 care exemplific asocierea modelat ca o clas, apare
Suma_mprumutat care nu aparine clasei Client i nici Banc.

74

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

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

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

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

76

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

Figura 2. 17 Monitorizarea simultan a clienilor, comenzilor i a stocurilor
Este evident agregarea client_cash client_virament n superclasa client care
execut operaia Achit.


77
2.2.2.3. Modelul dinamic n accepiunea metodei OMT

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

Figura 2. 18 DTE a aplicaiei Clieni

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

79

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

Figura 2. 20 DTS pentru clasa de obiecte Element_n_stoc
Diagrama de Tranziie a Strilor poate fi privit n mod dinamic, descriind structura
de control a sistemului i unde strile interacioneaz unele cu altele prin
evenimente partajate.

2.2.2.4. Modelul funcional al metodei OMT

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

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

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

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

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

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

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

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

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

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

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

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

85

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

2.4. Comparaii ntre metodele de proiectare

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

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

Concepte OMT
41
Rumbaugh
OOAD
42
Booch OOSE
43

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 OMT
41
Rumbaugh
OOAD
42
Booch OOSE
43

Jacobson
Obiect de control *
Obiect de interfa
central
*
Cheie/identificator Cheie candidat Cheie
Atribut * Cmp *
Atribut derivat * *
Atribut al asocierii * *
Atribut calificator *
Atribut discriminator *
Restricii pentru atribut * *
Se poate concluziona c metodologiile orientate-obiect analizate nu se deosebesc
substanial, ele prezint de fapt aceleai concepte vzute din puncte de vedere
diferite i cu notaii diferite.
OMT comparativ cu celelalte metode orientate-obiect prezint avantajul c
utilizeaz aceleai notaii pentru modelare n ntregul ciclu de via, astfel nct nu
este necesar o trecere brutal la alte notaii sau interpretri ale semanticii n etapele
urmtoare ale proiectrii. Principalul dezavantaj este acela c nu ofer o ghidare
metodologic nc din etapele timpurii ale procesului de dezvoltare.

88

CAPITOL 2...................................................................................................................... 34
METODE MODERNE DE PROIECTARE A UNUI SISTEM INFORMATIC
............................................................................................................................................. 34
2.1. Cerine generale n utilizarea unei metode de proiectare a sistemului informatic.... 34
2.1.1. Parametrii specifici de performan pentru sistemele informatice .................... 36
2.1.2. Necesitatea i structura procesului de evaluare a contabilitii informatizate... 41
2.2. Metodele de concepie i de realizare a unui sistem informatic............................... 45
2.2.1. Caracterizarea metodei Merise .......................................................................... 50
2.2.2. Metoda OMT de proiectare a sistemelor informatice........................................ 62
2.2.2.1. Etapele ciclului de realizare a unui proiect n abordarea orientatobiect . 66
2.2.2.2. Modelul obiect n metodologia OMT......................................................... 71
2.2.2.3. Modelul dinamic n accepiunea metodei OMT......................................... 77
2.2.2.4. Modelul funcional al metodei OMT.......................................................... 79
2.3 Unified Modeling Language cale de reunire a conceptelor orientate-obiect.......... 81
2.3.1 Avantajele oferite de UML................................................................................. 83
2.3.2 Obiectivele fundamentale ale UML ................................................................... 83
2.4. Comparaii ntre metodele de proiectare .................................................................. 85

Figura 2.1 Compartimentul financiar-contabil prin prisma costului, profitului, investiiei 36
Figura 2.2 Legturile aferente actului decizie ..................................................................... 41
Figura 2.3 Criteriile de analiz a unei situaii...................................................................... 43
Figura 2.4 Evaluarea compartimentului financiarcontabil prin metoda scenariilor .......... 45
Figura 2.5 Diagrama fluxurilor de date pentru Clieni ........................................................ 46
Figura 2.6 Reprezentarea domeniilor unui organism economic.......................................... 51
Figura 2.7 Funcii i activiti ntr-un sistem operant.......................................................... 52
Figura 2.8 MERISE Ce-cum-cu cine se realizeaz?......................................................... 55
Figura 2.9 Studiu prealabil n cadrul metodei Merise ......................................................... 56
Figura 2.10 Traseul sarcini-prelucrri, date, mesaje................................................... 61
Figura 2. 11 Circuitul analiz-modelare evenimente........................................................... 66
Figura 2. 12 Obinerea modelului de analiz....................................................................... 67
Figura 2. 13 Forma general de reprezentare a unei asocieri modelate ca o clas.............. 73
Figura 2. 14 Asociere mprumut modelat ca o clas...................................................... 74
Figura 2. 15 Asociere Client-Banc-Investiie ......................................................... 74
Figura 2. 16 Reprezentarea general a motenirii............................................................ 76
Figura 2. 17 Monitorizarea simultan a clienilor, comenzilor i a stocurilor..................... 76
Figura 2. 18 DTE a aplicaiei Clieni................................................................................... 77
Figura 2. 19 Forma general a unei DTS............................................................................. 79
Figura 2. 20 DTS pentru clasa de obiecte Element_n_stoc ............................................ 79
Figura 2. 21 Ierarhia de modele, vederi i diagrame utilizate de UML............................... 82
Figura 2. 22 Proiecia viziunilor cazului Use Case ............................................................. 85